@mflatt @robby Anecdotally, I’ve had a couple of times since upgrading to Racket 7 where DrRacket’s background expansion seems to get “stuck”—the dot in the corner stays blue indefinitely. Toggling background expansion off and on doesn’t seem to fix it, nor does closing and reopening the file. Restarting DrRacket solves the problem, but that’s it. I can’t reliably reproduce this, but it seems to happen sporadically. (I’m a few commits behind HEAD, so if a recent commit might have fixed this issue already, let me know, and I can pull and rebuild.)

@lexi.lambda Thanks for the report! So far, I’ve spent most of my time building and rebuilding Racket, so I haven’t spent much time observing DrRacket, but I’ll keep an look out for related issues.

@mflatt @lexi.lambda if you start DrRacket in the shell you might see some helpful output; it’s definitely the case that an unexpected exception in that code will wedge things. The drracket-background-compilation logger might be useful

@robby I didn’t see any output in the shell, but I can restart it with some logger output turned on. Should PLTSTDERR="error info@drracket-background-compilation" do the trick?

looks right

bummer

I’ll turn that on and let you know if I see any output if it gets stuck again.

Hello, all the recent buzz around language-oriented programming is very exciting. I have been reading about the topic for some time. Do people actively discuss LOP today?

I have a request for bikeshedding. In CLOS, specializers for dispatch in defmethod are specified inline with argument names, like this: (defmethod distance ((a point) (b point)) ...) …but this conflicts with Racket’s default argument syntax. Should a Racket-y CLOS use a keyword, like [a #: point%], an identifier, like [a : point%], a symbolic datum, also like [a : point%], or something else?

I would do it like syntax-parse

That’s an interesting idea. It would probably also need an escape syntax like syntax/parse’s ~var, then, as well. What would you envision that looking like?

is there any XSL Transformer in racket -> I need to reuse existing *.xsl files so the SXML/SXSLT approach wouldn’t work for me

it doesn’t seem like there is one… I’ve just found c libxslt so that should hopefully suffice

Although I haven’t had time to keep up with Racket 7 :cry:, today I encountered had my first Travis CI run against HEAD a.k.a. snapshot. IIUC Racket 7 adds the word “is” to an error message (“provided identifier is not defined or imported”), which breaks a check-exn using a regexp.

Travis: https://travis-ci.org/greghendershott/frog/jobs/347497352#L679

Code: https://github.com/greghendershott/frog/blob/master/frog/config/main.rkt#L46

Now, maybe it’s not a wonderful idea to use the regexp form of check-exn, because it can be fragile like this.

But I think I’ve seen it used a lot.

So I guess I’m wondering what that means wrt any “policy” about changing error messages?

(Sorry, not a fun topic)

it’s somewhat fun / amusing for me because internally at work there’s an explicit policy against writing tests that assert things about error message strings

I can understand that policy. OTOH I can understand people not wanting to create a bazillion exn sub-structs.

Anyway, I’ve seen it done in Racket code. Not just my own. :smile:

I’m happy to drop that “is” in that case. It doesn’t improve the message, and it wasn’t an intended change. More generally, though, I’d like to make this an opportunity to adjust some messages. Most notably, reader errors have changed to use the backquote…backquote form of talking about literal text, instead of the old backquote…quote form. The “unbound identifier” error message used to say “in module”. I haven’t restored the “in module”, so far, because it doesn’t seem helpful. (Where else could an identifier be? No… surely not… well, you have other problems in that case.) But I can put “in module” back if we want to avoid that change. In short: there’s not a clear policy so far, but I think we want something in between " no changes" and “anything goes”.

“No ‘gratuitous’ changes” might be a reasonable way to minimize miscellaneous breakage. I’m not proposing we end up with the equivalent of HTTP “Referer” headers. I’m not even proposing anything; just pointing it out and asking.

I mean, I might even be on board with deprecating the regexp variant of check-exn, and encouraging people to use Better Thing, whatever that is (IDK). At least that’s a clean break.

For this message, I see that the new one is actually “defined or required”, while the old one was “defined or imported”. In contrast to just dropping “is”, changing “imported” to “required” is the kind of terminology cleanup that I might have intended. (And maybe I added “is” if it was going to change, anyway; I don’t remember.) So, I’m less sure what to do in this case.

Clean sheet, I definitely prefer “required”, too.

Maybe it makes sense to punt this — just improve the messages, then later we get some package build evidence, and depending on how much/what breaks, decide. Maybe people just need to edit some regexps.

Some part of me prefers “imported” over “required” due to the way other #langs can use other names for imports/requires, and “import” seems to be more common and immediately understandable to me in the absence of a corresponding keyword, but it also makes me wonder if those error messages should be customizable or if languages are expected to do their own error reporting if they change those things.

(But that’s pretty tangential to the current conversation, I think.)

I think that’s an interesting problem, too. (The “easy” solution hasn’t worked, so far, in that I failed to convince various grad students to work on the problem.)

:)