[racket-users] Re: preview of a cross-compilation tool

2021-05-14 Thread schle...@gmail.com
This is like being a child, waking up and realizing its christmas (and easter at the same time), thank you for working on this, I will test out this shiny new toy/gift (meant in the best possible way). Because I am on linux, I will try to cross compile to windows (time to dust off my windows

Re: [racket-users] Redirecting shared lib stdout

2021-05-14 Thread Sage Gerard
Ah, you're right. I'm still acclimated to BC here. Disregard! On 5/14/21 7:30 AM, Paulo Matos wrote: > > Sage Gerard writes: > >> I ran into this issue with rsound. I'm not sure how standard output can >> be directly captured from a lower-level language in a Racket context >> when that language

Re: [racket-users] Help in understanding 'letrec' example

2021-05-14 Thread Utkarsh Singh
Hi David, On 2021-05-13, 13:12 -0400, David Storrs wrote: > Incidentally, a more concise way of doing this would be: > > (define target (build-path "tarzan")) ; convert to path only once > (for/or ([item (in-directory "/tmp/test")]) ; or whatever directory > you want to start in > (equal?

Re: [racket-users] Redirecting shared lib stdout

2021-05-14 Thread Paulo Matos
Sage Gerard writes: > I ran into this issue with rsound. I'm not sure how standard output can > be directly captured from a lower-level language in a Racket context > when that language can freely ignore the Racket printer and write > directly to STDOUT within the same operating system process.

Re: [racket-users] Redirecting shared lib stdout

2021-05-14 Thread Paulo Matos
Jon Zeppieri writes: > Can you use BinaryenModuleWriteText instead? It looks like it was > added to address your use case. -J Good point and nice catch. Although it doesn't solve the issue with racket it does provide a way out for me to create a safe binding for this function that works