The definition context problem could be solved by splitting the macro into an inner macro that does the actual logic and an outer macro that expands to the inner macro wrapped in #%expression.

that doesn’t really fix the problem that there isn’t any way to look this up in the first place…

You could implement it yourself with a custom #%module-begin that partially expands a module looking for calls to your local-bindings macro.

I’ve never tried anything like this and I don’t understand the details of bindings and scopes well enough to know if that would actually work and not have weird corner cases. I’ll defer to Sam on that one.

though text-field is able to receive it

Nice. Should the unprotected submodule be unchecked or unsafe? I think unsafe is more traditional, but it’s not really unsafe, just that the debug info will be hard to read.

I just learned about #:unprotected-submodule btw, thanks!

Why do you make an immutable string?

(it’s not part of the specs?)

Also, I think I’d like a matter#unchecked syntax for require to reference a submodule. This is similar to anchors in urls, but # may normally be allowed in paths?

Running through the whole sequence from AAA001 -> ZZZ999 takes about 11x longer in the contract version.

I thought I had came up with a clever solution but it runs 9x slower than Jack’s With contracts it’s only about 2x slower though.

@laurent.orseau I make immutable strings because mutable strings are evil, cursed objects

Just don’t mutate mutable strings :p

That partial expansion approach crossed my mind too, and it seems promising. And that #%expression technique does sound like it would come in handy a lot of the time as a way to get local definition contexts to play nicely with this.

I use completely separate clones for master and release. In fact, I usually just have a clone at master, and I create a clone at release if needed.

And if you are referring to having, say, an install of 7.7 while also working with the git repository, then I have totally separate installs for each

I use a nice collection of shell scripts for managing this

https://github.com/takikawa/racket-dev-goodies\|https://github.com/takikawa/racket-dev-goodies

I recommend a separate clone and build in that case

That tutorial was turned into a blog post

https://blog.racket-lang.org/2017/09/tutorial-contributing-to-racket.html\|https://blog.racket-lang.org/2017/09/tutorial-contributing-to-racket.html

I usually use a separate DrRacket

I’m looking at improving and streamlining the Racket CS build, especially making it work without first building Racket BC. As part of that, I’m wondering whether we should use submodules in the racket repo. Specifically: • racket/src/ChezScheme would be a submodule pointing to racket/ChezScheme at GitHub. The benefit here is that the racket history is correctly tied to the ChezScheme history, which is good for building past versions and for CI. • racket/src/bootstrapped (or something like that) would be a submodule pointing to a new racket/bootstrapped-1 repo, which would contain a single set of Chez Scheme boot files that work on all supported platforms (the new “portable bytecode” format). It would also contain the .scm files that are generated from racket sources in racket/src/thread, racket/src/io, and so on. For consistency, the generated racket/src/racket/src/startup.inc for BC (currently checked into the racket repo) would also move to bootstrapped. Boot files do not diff well, so the bootstrapped repo would get large over time and probably should get replaced by a new repo every once in a while, hence the 1 in bootstrapped-1. The benefit here is that BC doesn’t need to be built to get to CS — and, more generally, there’s a development path that doesn’t have to build BC ever again (even though BC isn’t going away anytime soon). All of the submodules would be bundled in a source distribution.

Does this sound like a good approach? Submodules have worked ok in the ChezScheme repo to pull in nanopass, zlib, lz4, and stex, so that’s part of what has reduced my hesitation (relative to trying to use submodules long ago).

Unlike boot files, the generated startup.inc and .scm files diff well, so it’s tempting to just check the .scm files into the racket repo like startup.inc. But if we’re going to have a separate repo for generated boot files, then there’s no need.

Personally, submodule is a pain for me, but that’s because I don’t know how to use git properly. If Makefile automates calling git submodule correctly, this problem would go away.

Yes, good point: I imagine that make would update submodules in the same way that make cs currently pulls from racket/ChezScheme for you.

Definitely having the various racket/ChezScheme Makefiles check for submodules and give a useful message would make that a fairly painless experience

I know that @spall had some issues building ChezScheme because she tried things without fetching submodules and they didn’t work with unhelpful messages

Sure, and instead of seatbelts, just don’t crash :p

Seatbelts don’t prevent crashes :p

Hold on while I put on my mutable string helmet :stuck_out_tongue:

@laurent.orseau re: matter#unchecked syntax: honestly I wish module paths were just urls

the fewer ad-hoc custom namespaces people have to learn how to navigate, the better

> honestly I wish module paths were just urls Add that to Rhombus Brainstorming?

Having experimented enough now to remember why Git submodules create problems, I’m ready to give up on that idea. The external bootstrapped repo still seems like a good idea, but probably managed differently.

Sigh

The right solution for the ChezScheme content may be a subtree, which I had not learned about before. After all, the reason to keep the ChezScheme repo separate was to facilitate the transfer of changes with the cisco/ChezScheme repo, but subtrees will do that.

For those who don’t know about subtrees, the short answer is that you don’t have to do anything. :slightly_smiling_face:

I hope subtrees also maintain history for that code

Subtrees are just the kind of splicing that we did (in a more custom way) when we split the old racket repo. But I imagine pulling in a subtree that omits all the bootfiles in the history, which would shift commit IDs (again, like our repo split).

Maybe. Doesn’t seem worth the trouble.