Interesting. Has anyone ever blogged about the top level being hopeless? I’m hearing that for the first time. :slightly_smiling_face:

https://gist.github.com/samth/3083053

http://calculist.blogspot.com/2009/01/fexprs-in-scheme.html

Cc: @laurent.orseau

Another possibility is to use a special submodule that can be dynamic-required. This is what Quickscript uses.

The nice thing about submodules is that they can be required without even reading the rest of the program (once compiled), which can be particularly beneficial for a plugin in case the program file is large.

Is there a nice way to visualize the module dependency graph in a Racket project?

loggers are useful if you want the information to be available either before expansion finishes or when expansion errors

See the “module browser” in DrRacket (View menu)

can you communicate s-exps easily with loggers, or do you need to parse the text output?

you can communicate arbitrary values

although to communicate between the expansion and drracket they need to be sendable between places

Ah yeah, nice, I missed the make-log-receiver

The OP said ping @leif and @florence !ping!:table_tennis_paddle_and_ball::rolling_on_the_floor_laughing:

@samth if some info is logged during syntax expansion, does it mean that once compiled to a .zo you may not receive the same information?

right, although that’s a pretty different situation

That’s delightful!

Could https://docs.racket-lang.org/reference/stxops.html#%28def._%28%28quote._~23~25kernel%29._syntax-shift-phase-level%29%29\|syntax-shift-phase-level be used to implement a begin-for-template counterpart to begin-for-syntax?

No, it wouldn’t help. A begin-for-syntax doesn’t so much shift phases as use the bindings of a different phase to generate compile-time code. That is, begin-for-... needs to go to the other phase (in a sense) instead of moving the phase here (in a sense).

The problem with begin-for-template is that its compile time would correspond to the enclosing module’s run time, but the intent of the module system is to be able to compile a module without evaluating any of its run-time code.

is chez scheme ready for this months release?

Yes, we still expect to release v8.0 as Racket CS (with Racket BC still available through non-default routes).

glad there are no more delays

Would you say custodians are expensive to use or cheap (or in-between?)

I’m getting extremely strange behavior trying to install a package that includes a file that uses at-exp-lib in a Racket minimal installation. Sometimes, the build fails claiming that “syntax/readerr” is an unknown module. Sometimes, it does not. This seems to be determined by some cosmic variable, because it even happens in an apparently clean VM: https://github.com/wilbowma/test-setup-racket/runs/1654453141?check_suite_focus=true#step:4:43 https://github.com/wilbowma/test-setup-racket/runs/1654486000?check_suite_focus=true#step:4:45

Anyone have any insight?

Okay… I seem to be able to affect the bug: using raco pkg install -j 1 seems to make it disappear; raco pkg install -j 2 makes it appears frequently, and raco pkg install -j 8 makes it appear very infrequently. It seems to have to do with order of the threads that are building at-exp-lib and the package that uses at-exp-lib.

Seems to be some kind of race condition. The package requires at-exp-lib at build time, but when using minimal, that’s not built yet, so when raco installs and builds it as a dependency in parallel with the package that requires it at build time, something goes wrong depending on which thread finishes first.

Thank-you for clarifying this.

I agree with the race condition part, but the error message seems to suggest that this is a deeper concurrency problem involving namespaces and module loading (at Racket level), not about whether a file is built or not: instantiate: unknown module module name: #<resolved-module-path:"/usr/share/racket/collects/syntax/readerr.rkt"> compilation context...: /home/runner/work/test-setup-racket/test-setup-racket/foo/dummy-lib/foo/meow.rkt as far as I understand, this could happen when a module is supposed to be registered in a namespace (perhaps registered/loaded by the module name resolver), but later can’t actually be found. https://github.com/racket/racket/blob/17b7033402078038bca85b478243a19baba52f4f/racket/src/expander/namespace/module.rkt#L384