How do I install it?
Is there a particular exception that’s thrown to running code if the “Run” or “Stop” buttons are pressed in DrRacket while a script is currently running that I could catch (in the running script) so it terminates nicely?
I think “stop” sends a “break”.
ty
ok, catching the break is easy enough, but still not sure how to handle Run. It doesn’t seem to throw any exceptions.
I don’t think the run button does anything if the your program is running already?
well, for example, if I run a script that opens a frame. I make some code changes, click ‘run’ and the frame goes away, it recompiles and re-launches the frame. I’m opening an OpenGL window and I’d like the same behavior. But, instead, when I click run the GL window stays open and becomes unresponsive and the code controlling it is no longer running. Then a new GL window opens up with the new code active
I’m imagining that - like exn:break - I can catch something and terminate gracefully, but I’m not finding that clicking “run” does anything I can break on
So in this situation, where the module-path-index of a module doesn’t yet have a name, and (resolved-module-path-name (module-path-index-resolve mpi)) is '\|expanded module\|? In Rackets older than 7.0, if I try to check for that using eq?, that symbol is not eq? to my own literal '\|expanded module\|. :eyes: I have to check via something like (equal? (symbol->string sym) "expanded module"). e.g. If I do this in Racket 6.5.
That’s older versions of Racket, pre 7.0, and I am happy to use the pragmatic work-around I just mentioned, and the slower compare won’t matter in this context. And I don’t want to go down a rabbit hole. But part of me wants to know the answer to this WAT.
So @mflatt if you happen to know, or have a quick guess, I’d love to know. But you’re busy and it really doesn’t matter so I don’t want to distract you for more than 5 seconds. :smile:
Again, in newer Rackets 7.0 the symbol is simply eq? as expected. I just try to keep Racket Mode working with older Rackets until it’s impractical.
To detect “the current module,” it’s better to detect that module-path-index-split returns two #fs than to look for a specific symbol. Is that workable in your context?
I don’t remember whether it was important that the way '\|expanded module\| is picked changed in the new expander.
There’s no exception-like signal for a custodian-based shutdown (which is what the Run button does). But at the ffi/unsafe level, you can register custodian shutdown operations. See ffi/unsafe/custodian.
ty sir
I felt the same way and switched to using module-path-index-split -> #f #f for awhile — but it turned out to match other situations. i.e. There are “self” modules for more than just the expanded module case.
If that tickles you as weird or wrong I can try to dig up the details from a couple days ago.
(As for the old versions, I was just surprised that two symbols could be not eq? when symbol->string of each is equal.)
The symbols aren’t eq? because one of them is uninterned. I am interested in the details on how you ended up withe multiple “self” MPIs.
Oh. Interning. I “knew” about that, but it’s never mattered in so many years of Racket programming, I forgot about that. Thanks!
I’ll rewind in the git history and try to dig up an example for the “self” #f #f that’s not a expanded-but-not-evaluated module and let you know….
@mflatt OK here it is. When current-namespace is from module->namespace, and, you do something like (identifier-binding (namespace-symbol->identifier 'some-id-defined-in-that-module)) — then the mpi’s are '(#<module-path-index:()> describe #<module-path-index:()> describe 0 0 0).
Having said that, I think I can use the self-module? test combined with another test, to avoid the business of matching on the '\|expanded module\| symbol. I agree the latter seems smelly, which is why I tried to move away from it. I just need to try harder. :slightly_smiling_face:
@aymano.osman It’s not quite ready to install unless you’re brave like @popa.bogdanp. Hopefully a few more days.
So if you replace '\|expanded module\| someday with '\|the module that shall not yet be named\| or 'voldemort I should be :ok_hand:
I want to ask folks for some Friday pick-a-name bike-shedding but will put that in a thread below this. :smile:
“racket-check-syntax-mode” is too long. “racket-check-syntax-” is too long a prefix for names of commands for users. (Not to mention in source code. Although I’ve already done all that typing, I could make it better for future typing and reading).
Also, “checking syntax” isn’t really the full scope. Really, it’s about “static analysis” of expanded-but-not-evaluated module forms. Sure, if there is a syntax error, you get a message. But the bulk of of the benefit is what you get when there is not a syntax error: Rich information about bindings, imports, and more. This enables you to explore and navigate code, understand the use (or non-use) of bindings, rename bindings, and more.
So what would a better name be?
Something to do with: - analyze - annotate - expand - explore - explicate
Maybe racket-an-mode — i.e. an{alyze notate} ?? Meh.
Maybe racket-exp-mode — i.e. exp{and lore licate} ?? Better?
Or racket-xp-mode ?? Better?
To force Slack to do a “poll” I’ll put a little reaction next to each of those, you can click to +1. Write-in candidates also welcome.
can these names be autocompleted? (I don’t know anything about emacs)
Yes, autocompleted, and bound to keys. Even so, a bad name is bad, and a long name is long. :smile: Seriously it doesn’t help when writing Emacs Lisp to have identifiers like noise-noise-noise-noise-signal. Or reading documentation about Racket Mode. etc.
“To customize how blah-blah-blah-blah-blah-mode shows this, change blah-blah-blah-blah-blah-face to…” and so on. :slightly_smiling_face:
How about abbreviating racket? rkt-analysis-mode
I figure if somebody is going to use such a mode probably already knows *.rkt files pretty well
The OO system has object-method-arity-includes? which mirrors procedure-arity-includes?, so is there also an an analog for procedure-keywords? That is, is there any way to dynamically determine the keywords a method takes?