I have confusion in the way raco exe works. Now supposing I want to make a standalone executable for this file test.rkt: #lang racket (require portaudio) (displayln "This is a test") Will running raco exe test.rkt suffice, or do I have to somehow tell raco exe about its dependency on a lib, in this case portaudio .

What ends up happening for me when I run the executable is (./test) in collection directories: context...: /Applications/Racket v7.7/collects/racket/private/collect.rkt:26:58: fail '#%embedded:portaudio/portaudio:: [running body] Now, here I am trying to figure what may be the issue, portaudio or my use of raco. Any pointers? Btw, on Mac OS.

Can you try also using raco distribute after raco exe?

You mean just a raco distribute test.rkt?

I forget the command line, but you can use it with the results of raco exe

Yeah, saw docs, am trying. Will update

So I ran raco distribute test-dir test This resulted in a directory containing a bin, and a lib folder. I tried running ./test from the bin folder, same result :/

Ok, then the problem is likely in portaudio

Hmm okay, time to do some digging then. I was hoping I was using raco wrong.

What could be the issue, certain libs can’t work standalone using raco exe?

It might be that reporting a bug on portaudio is the right thing. Also, I think @jbclements doesn’t use slack much, so using the mailing list might be more successful

The issue is likely that portaudio is constructed in such a way that raco exe doesn’t work

portaudio uses FFI which brings all sort of weird things

Actually… I think this might be a simple bug

Let me take a quick look

So, you can see that in the source code of portaudio, (define-runtime-path lib "lib/") appears everywhere

According to the doc at https://docs.racket-lang.org/raco/exe.html

you probably should include the ++lib flag

with an appropriate argument

Hmm, I see. I am going to try this and get back here.

Though it looks like the variables defined via define-runtime-path are not really used

Instead, collection-file-path is used directly

I don’t know how these things work too, but:

(collection-file-path "libportaudio.2.dylib" "portaudio" "lib") Seems to indicate that one should be able to (require portaudio/lib), but it’s not. I think this is the crux of the problem.

Right, that’s not a good way to do things, and won’t work with raco exe

It might be possible to make things work now using ++lib, as you suggested

I tried that, but it didn’t work. Perhaps I also did something wrong :confused:

raco exe ++lib /Users/advait/Library/Racket/7.7/pkgs/portaudio/ test.rkt I tried this, but I get a contract violation create-embedding-executable: contract violation

You would need to supply the things it is missing using ++lib

Ah okay, so these would not be limited to racket files right?

The argument to ++lib should be stuff like portaudio/lib I think.

Not full path iiuc

Would be really nice if the doc at https://docs.racket-lang.org/raco/exe.html gives some examples for how ++lib is used

raco exe ++lib portaudio/lib test.rkt This results in get-module-code: no such file: #<path:/Users/advait/Library/Racket/7.7/pkgs/portaudio/portaudio/lib.rkt> So, it is expecting a racket file it looks like :thinking_face:

After trying to pass all sorts of permutations of the portaudio library in ++lib, there is no change whatsoever in the error. This is some other issue it looks like

If I were you, I would follow @samth’s advice to send an email to , since @jbclements is likely to see your message there more than here.

(Typed Racket) Is there a way to write tests that check for a certain type signature, or verify that a certain call does or does not check? I’m going change a type signature in existing code so that it is more restrictive, and I would prefer to write a unit test to go along with this change. All of the existing uses are supposed to already obey the more restrictive signature.

I am aware that code will fail to typecheck if my change causes an error. Still, I would prefer to have a test to accompany my change.

I saw assert-typecheck-fail and also the turnstile package (prefer not to bring in this heavyweight just for testing).

You could just write an expression that uses ann to explicitly write the type down.