@samth @cadr I’m experimenting with a “machine-independet bytecode” mode that is built into the expander. It’s aimed at improving the build process. The implementation takes over most of the code currently in “linklet/read.ss” and “linklet/write.ss”. Instead of duplicating that code, the expander layer exports functions that any backend could use to read and write the linklet-directory part of the bytecode format (i.e., the part that all implementations have to follow) while supplyinh a backend-specific linklet-bundle serializer and unserializer. Pycket could use those functions too… In fact, it occurs to now that I’ve probably implemented exactly the bytecode format that you have for Pycket, since it’s the fasled linklet S-expression (more precisely: correlated object). Thanks for fixing those racket/fasl bugs! More in a day or a few, probably, but I thought a heads-up now might be useful.

@mflatt That sounds great! Just today we merged our fasl branch to Pycket master, we’re able to use compiled code for racket/base and beyond using fasl. I imagine it would be pretty easy for us to adopt that implementation and give you feedback very quickly, since things like linklet-bundle serializer are really simple on pycket (it just serializes the hash table and puts it in a pair with a ’B in the car)

@mflatt the one thing we haven’t implemented is handling submodules

So if what you’re adding will make that work automatically then it would be especially valuable

Yes, pretty much that. I may want to change the linklet interface (that the expander sees) to make it more automatic, but I’m not sure yet.

Ok we’ll not try to implement that this week