@mflatt I wonder if there’s a bug in the embedding process somewhere. I integrated your suggestions and compile time selection of backend into my system and create-embedding-executable successfully finished but when I try to execute it: read: bad syntax #<

If nothing comes to mind in the meantime, I will try to reproduce the process in the example I sent to the mailing list.

… and raco exe ... fails as well. This might be related to the use of define-runtime-module-path-index.

@mflatt I would really like to add tests for this PR: https://github.com/racket/racket/pull/2234 But I’d really like to use syntax/strip-context in that test code, which isn’t available in syntax.rktl. Is it worth moving the test somewhere in racket-test instead of racket-test-core, or should I just reimplement strip-context inside syntax.rktl?

Adding (require syntax/strip-context) to “syntax.rktl” should be fine.

Should I just put it at the top of that file?

Yes, that;’s what I would do

Okay, thanks. I’ll update the PR shortly.

My guess is that come path is going where a string is intended, so that the #< is starting #<path:. But I’m not sure where the path would have come from.

I traced my issue to a problem in the way the local catalog directory file:// url is handled in pkg/private/stage.rkt. When a package is resolved against the catalog, the initial catalog file:// url is extended with the package’s relative path and then converted to an absolute file:// url which is passed directly to check-strip-compatible function which isn’t equipped to cope with file urls. It expects to be given filesystem paths so when given the package file:// url it misinterprets it as a filesystem path which doesn’t exist leading to the default fallback code path being executed which results in erroring out with the package content state incompatible error.

The fix is to make sure file:// urls are actually converted to paths first. In fact in the relevant stage.rkt code section I see that conversion is already being done in (define pkg-path ...) but it’s not passed along to the check-strip-compatible function. When that’s corrected, raco pkg install works as expected.

I can open a P.R. with the fix and also include a regression test case if that’s fine with you.

@mflatt

That sounds great. Thanks for tracking down the problem!

I’m looking through racket-test/tests/pkg test files, what would be the best location to put the test in? I’m not seeing tests dealing with usage of local catalog directory and various combinations of package strip modes. Maybe worth adding a new test file dealing with those cases?

Though I haven’t yet looked through every file so I may haven’t found the right place

@mflatt: @michael.ballantyne and I noticed that cross phase modules don’t seem to work across module registries like the documentation says. Here is an example, and we were wondering if we were missing something obvious: https://gist.github.com/LeifAndersen/ecd749b25bdba5c59441c4dd4fa2091b

The docs are wrong/unclear. When you attach a module declaration from one namespace to another (that has a different registry), then the instance is shared, too. But there’s no global registry of cross-phase persistent modules.