
@minhnhat10bk has joined the channel

@iam704 has joined the channel

@mflatt What is the difference between stx.rktl
and syntax.rktl
in racket-test-core
?

stx.rktl
is supposed to be about syntax objects, and syntax.rktl
is supposed to be about core forms (originally “syntax”, but that word became overloaded)

Aha, that makes sense. Thanks.

sometimes feels like I should declare naming-things bankruptcy. instead use a PRNameG, or use digests / content-addressable source file names :)

I’m going to extend the arity on two groups of functions to bring them in line with Chez Scheme, since that direction seems better than working to hide the extra arities in Racket-on-Chez. One group is the comparison operators, like <
or string=?
, which currently accept 2 or more arguments. They’ll change to accept 1 or more arguments. (Racket’s 2-or-more choice originated with RnRS. I don’t know why RnRS made that choice, and I don’t know why Chez Scheme constrains them to 1-or-more instead of 0-or-more.) The other group is the fixnum and flonum arithmetic operations, like fx+
or flmin
, which Racket has provided only in 2-argument form. They’ll generalize to be like the generic operations, such as +
and min
, either 0-or-more or 1-or-more.

I have an editor%
subclass that calls various methods during initialization, but occasionally some of my method calls trigger an error if the editor is locked internally (as in locked-for-flow?
). Is there a way to queue these methods to be called once the editor is unlocked, or to get a synchronizable event, or something like that? Adding a retry/backoff loop to all of the right spots seems painful, even aside from the fact that when I’ve tried so far I’ve missed some spots.

@philip.mcgrath Are you using accessing editor in multiple threads?

No

I’m not clear on how you’d run into that error otherwise. Can you explain more?

With Racket 7.0 on Mac, raco setup often generates many “error for long-term poll set: unsupported; rktio_err=1” messages: is that worth isolating and filing an issue for?

And occasionally there’s “racket[77374:4038733] WARNING: nextEventMatchingMask should only be called from the Main Thread! This will throw an exception in the future.”

The long-term poll set issue does sound like a problem.

The main-thread issue sounds like a misbehaved library or test that is using racket/gui
in a non-main place.

@mflatt I’m not totally clear either, and it doesn’t happen consistently, which has been making it harder to get a minimal example, especially as the method named in the error message (set-max-width
) isn’t one I think I’m calling directly. The place where the error seems to be occurring: sends reflow-container
to the enclosing frame%
; uses get-extent
on the text%
instance; adjusts the min-height
of the editor-canvas%
instance based on the result; and sends reflow-container
to the enclosing frame%
again.

And, just to make sure, this isn’t a setup in a new eventspace (which would imply a new thread), right?

I recently started giving each instance of this frame%
its own dedicated eventspace. However, I believe (I am trying to confirm this in the git history now) that I was getting versions of this error before I started doing anything regarding eventspaces.

The error that you’re reporting now is usually fixed by moving GUI-creation work into the thread of the GUI’s eventspace by using queue-callback
.
If you try to set up a GUI in any other thread, including the one that created the eventspace, then you’ll definitely run into that kind of error.

Ok, that makes sense and at least I can rule that out. That means I should have something like this, yes? (parameterize ([current-eventspace (make-eventspace)])
(queue-callback
(lambda () (new frame% ...))))

Yes

ok, I’ll put it on my todos

Thanks, that seems to have cleared up a lot of the cases when I was getting those errors! It looks like the remaining cases are related to a delay/sync
promise I was using to avoid allocating unnecessary frames—when I replace delay/sync
with values
, the errors don’t happen. I was using queue-callback
inside the delay/sync
, so I’m not immediately sure what’s wrong, but I will investigate further.

I can understand what string=?
should produce with zero arguments, but what should <
produce?

To me, it makes sense for all comparison operators to return #t on 0 arguments, the same way that (and)
produces #t. I guess it’s because I would want to use (apply < nums)
to check whether nums
is sorted strictly increasing, and in that application, I’d almost certainly want to count an empty list as sorted.

https://docs.racket-lang.org/reference/reader.html#(idx._(gentag._4._(lib._scribblings%2Freference%2Freference..scrbl))) says that #%
reads a symbol and gives an example:
> #%Apple
reads equal to (string->symbol "#%Apple")
But that doesn’t seem true?
{I thought #%
is a valid start to an identifier, and things like #%kernel
or #%app
are normal identifiers and it’s “just” a naming convention for some Racket “core” things.]

It’s a symbol as far as read
is concerned, you might be thinking of read-syntax
. Each of those treat #%Apple
and Apple
“similarly”.

Oh right. Oops. I didn’t notice the context of the docs, and missed the typesetting of read
. I should have pasted here: > #%Apple
read
s equal to (string->symbol "#%Apple")

And indeed (equal? (read (open-input-string "#%Apple")) (string->symbol "#%Apple"))
is #t
.
