I need a hint. I’d like to experiment with linklets. I have compiled both chez and racket7 from mflatt’s repos. It seems to work. In the expander/ directory, racket run.rkt and racket bootstrap-demo.rkt works.

I can’t get racket run.rkt -c <dir> —linklets -l <module-path> to work though.

I made a directory l to store the linklets. Wrote a fact.rkt and attempted to run: ../racket7/racket/bin/racket ../racket7/pkgs/expander/run.rkt -c l —linklets -l fact.rkt

I get: standard-module-name-resolver: collection not found for module path: (lib “fact.rkt”) collection: “mzlib”

@soegaard2 You’d get the same error with racket -l fact.rkt. Try ... -t fact.rkt

mbp:ur soegaard$ ../racket7/racket/bin/racket ../racket7/pkgs/expander/run.rkt -c l —linklets -t fact.rkt compile: /Users/soegaard/Dropbox/GitHub/racket7/ur/fact.rkt …during /Users/soegaard/Dropbox/GitHub/racket7/ur/fact.rkt… standard-module-name-resolver: collection not found for module path: (submod racket/base reader) collection: “racket” in collection directories: context…:

You usually don’t have to use -t, and just write racket fact.rkt, so that’s probably the confusion

Does ... -l racket/base work?

racket -t fact.rkt works (but I was interested in the linklets)

Looking more, I think I’ve probably changed things so that you need -k for now

-k ?

../racket7/racket/bin/racket ../racket7/pkgs/expander/run.rkt -k ../racket7/racket -c l --linklets -t fact.rkt

Okay. That compiles and stores a load of tiles in l/ . They are have hashes as names and seems to have a binary encoding?

Yes, they’re bytecode unless you also use -s

The -s flag doesn’t seem to affect the files. (I deleted l/ before running with the -s flag)

I’m stumped. The file names are still hashes, but the content shouldn’t be bytecode

../racket7/racket/bin/racket ../racket7/pkgs/expander/run.rkt -s -k ../racket7/racket -c l —linklets -t fact.rkt

For context: I am working on a Racket to JavaScript compiler. The next natural step is to add modules. So, as this is a long term project, I thought it would be a good idea to look into linklets.

@soegaard2 ooh!

you should definitely look into linklets

Good to hear.

one thing you might be interested in, although it’s not directly what you want longest-term, is the linklet extractor, which can take an (almost) arbitrary racket source file and produce a 0-dependency single linklet as output

@samth out of curiosity, why “almost”? what sort of source files does it not handle?

It makes a few assumptions, and I don’t know that it handles all of racket — the relevant linklets all use #lang racket/base

The linklet extractor sounds as an ideal starting point.

but @mflatt might be able to be precise about the limitations

also, it definitely doesn’t work if you use dynamic-require

the extractor doesn’t work on a module whose run-time code references something implemented by the expander

So it doesn’t work with #lang racket eval or #lang racket #'x

But #lang racket (begin-for-syntax eval) is ok

so no run-time syntax objects allowed? makes sense

right

I should have written #lang racket/base in those examples. I don’t think #lang racket could work

would there be a point to a #lang racket/something which is like base but omits everything that’s implemented by the expander?

I don’t know. The extractor is primarily meant to extract the expander itself and a couple of other layers, but it may be useful for more in the end

The extraction mechanism is really just a bootstrapping thing currently — I suggested it to @soegaard2 because it’s probably a good place to start

@soegaard2 I remember now: -s only works with “bootstrap-run.rkt” instead of “run.rkt”

Ok. I’ll try that!

I’m seeing a segfault, which I’ll investigate

Ditto. But the cache now contains linklets in source format.

repair pushed

fast as always!

Works as a charm.