@mflatt right now, @cadr and I are thinking about how to support bytecode or something like it in Pycket. I see a few options 1. Write a bunch of RPython code to implement bytecode reading and writing (this doesn’t seem to be part of the current read implementation in the expander linklet 2. Port the relevant C code to Racket code, and integrate that into the expander linklet (or a separate linklet) 3. Implement something like the compiled-load handler from expander/run inside Pycket 4. Do something like whatever the Racket-on-Chez code does, which I don’t fully understand Our preference is to do something that’s most likely to be usable long-term, which sort of depends on your thoughts on bytecode going forward. Is that something you want to move to Racket code? Do you have other thoughts on the options here?

I think you want to do something like Racket-on-Chez, which doesn’t try to deal with the old bytecode format (so it initializes current-compiled-file-paths differently). Is there some reason that fasled linklet S-expressions isn’t the right format?

@mflatt that sounds reasonable, and linklet s-expressions seem fine, but I don’t know where to find the relevant Racket-on-Chez code. In particular, current-compiled-file-paths doesn’t appear in the “racket/src/cs” code.

Should have been use-compiled-file-paths

Ok, I see that now. But I’m still confused. Does the expander automatically manage the files in “compiled/cs/” when that is the value of (use-compiled-file-paths)? Where is the decision about caching and serialization of compiled code made? In expander/run.rkt, that’s in the current-load parameter, but the CS code seems not to set current-load (or current-load/use-compiled).

The linklet-implementation layer determines how #~ is parsed by supplying read-compiled-linklet. So, for example, “linklet.sls” is where Racket-on-Chez knows about reading Chez machine code (usually wrapped in an interpreter layer) or JIT-compiled S-expressions, depending on the Racket-on-Chez mode. The expander/reader/module layer calls read-compiled-linklet when it sees #~. And it looks in places specified by use-compiled-file-paths, which are normally the places that have #~.

raco make and raco setup similarly decide where to put “bytecode” based on use-compiled-file-paths.

Ok. The one other piece that I see is that serialization is handled by calling write on a linklet-bundle or a linklet-directory

@cadr so what we need to do is implement most of what’s in linklet.sls

@samth agreed

lots of it is already implemented in pycket, but we just need to implement serialization and deserialization as part of write/read-compiled-linklet

One other thing to note is that we could re-use racket/fasl by extracting it to a linklet (that requires playing a little with ++knot arguments and removing keywords from the exports)