One more Racket-on-Chez status report: https://blog.racket-lang.org/2020/02/racket-on-chez-status.html

I have been avoiding generator in my code due to its inefficiency. I’m glad that Racket CS has significantly improved it. Thank you!

Thanks muchly :+1:

When building portaudio via a rsound installation using CS, it builds shared objects in a 3m directory. My runtime therefore cannot find the libraries

sage@localhost sgcom]$ find ~/.racket/7.6 -name callbacks.so /home/sage/.racket/7.6/pkgs/portaudio/portaudio/lib/i386-linux/3m/callbacks.so /home/sage/.racket/7.6/pkgs/portaudio/portaudio/lib/x86_64-linux/3m/callbacks.so Is it a good precedent to symlink these files in a cs directory?

A heartfelt thanks for all the work you, and others, have put into this! My professional future becomes more closely tied to Racket each day :)

@mflatt On Racket 7.6 CS, I noticed that compiling (raco make) a let loop makes the program slower than not compiling it. for/fold doesn’t seem to be affected though (details below). Edit: It’s GC time, and not specific to the let loop. Swapping the order makes the for/fold loop slower by the same amount instead. So compiling makes the GC less efficient?

Not compiled: cpu time: 102 real time: 102 gc time: 0 99999999 cpu time: 103 real time: 103 gc time: 0 99999999 cpu time: 488 real time: 488 gc time: 0 99999999

Compiled: cpu time: 134 real time: 134 gc time: 30 99999999 cpu time: 104 real time: 104 gc time: 0 99999999 cpu time: 489 real time: 489 gc time: 0 99999999 cpu time: 45522 real time: 45524 gc time: 471 99999999

Timings are consistent over multiple runs

I’m also a little surprised that the let loop is not optimized to a constant. Is that on the radar?

I think you’re seeing the effect of a shifting GC. When not compiled, a GC happens not to be scheduled during the first loop. When already compiled, a GC happens to be scheduled during the loop. Note the different “gc time:” output.

It’s often a good idea to put (collect-garbage) before a time form.

I don’t think the loop is likely to be optimized into a constant anytime soon. It’s tricky to determine when that’s possible (as opposed to running something that will loop forever), and I don’t think programs commonly contain long loops that turn into constants. Short loops sometimes turn into constants through inlining and constant propagation/folding.

Thanks!

Ok, great, thank you.

I’m searching through some XML using xml/path. <eventCode> <valueName>PROFILE_VERSION</valueName> <value>2.1</value> </eventCode> <eventCode> <valueName>LICENSE</valueName> <value>Geobasisdaten: Copyright Bundesamt für Kartographie und Geodäsie, Frankfurt am Main, 2017</value> </eventCode> <eventCode> <valueName>II</valueName> <value>70</value> </eventCode> <eventCode> <valueName>GROUP</valueName> <value>SNOWFALL</value> </eventCode> <eventCode> <valueName>AREA_COLOR</valueName> <value>255 255 0</value> </eventCode> using (se-path*/list '(eventCode) elem) I get: '("\n " (valueName () "PROFILE_VERSION") "\n " (value () "2.1") "\n " "\n " (valueName () "LICENSE") "\n " (value () "Geobasisdaten: Copyright Bundesamt für Kartographie und Geodäsie, Frankfurt am Main, 2017") "\n " "\n " (valueName () "II") "\n " (value () "70") "\n " "\n " (valueName () "GROUP") "\n " (value () "SNOWFALL") "\n " "\n " (valueName () "AREA_COLOR") "\n " (value () "255 255 0") "\n ") Using xmlstarlet from the command line I can get the 70 and SNOWFALL using: xml sel -T -t ... \ -m "_:alert/_:info/_:eventCode[_:valueName='II']" -o "eventType=" -v _:value -n \ -m "/_:alert/_:info/_:eventCode[_:valueName='GROUP']" -o "weather=" -v _:value -n \ ... but the output of se-path*/list loses the nesting of valueName and value within each eventCode. I can deal with this, but I’m wondering if there is a better way.

@mflatt I used to see people do (for ([_ 3]) (collect-garbage)) before timings (maybe to force a major collection??). Is that still valid (if it ever was)?

Wow, the improvements to indirect function calls are a huge deal

That makes things like generic interfaces (and Rebellion’s transducers and reducers) way more viable

It depends. That’s overkill for many cases, where even the second (collect-garbage) is won’t catch more than a single (collect-garbage), which is already a major collection. But it’s not enough in a setting where finalizers are run in a background thread, in which case alternating (collect-garbage) with (sync (system-idle)) may be needed. There’s no good answer for all cases. When in doubt, at least try a single (collect-garbage).

I really think Racket should include a (collect-garbage-for-testing) function so people don’t have to do the whole collect-three-times-plus-await-idle thing. It’s way too magic.

But… what if I like the magic of clicking my heels and saying “there’s no place like collect-garbage” three times in a row?

@deactivateduser60718 I haven’t looked at rsound’s code, but, in the happy case, you can do the same thing as the last few commits to bcrypt: https://github.com/samth/bcrypt.rkt/commits/master It’s more complicated if the existing code uses the “Racket BC’s” C API: in that case you would need to change the code to do what you need through the FFI.

I like the name “Racket BC”

That was @ryanc’s great idea.

@philip.mcgrath The root cause is actually in portaudio, which ships with pre-built .so files https://github.com/jbclements/portaudio/tree/master/portaudio/lib

If I’m understanding this right, these are files organized in anticipation for use in 3m. Do the commits you mentioned account for that?

I didn’t read too deeply into bcrypt, but I’m guessing that system-library-subpath becomes relevant when you want raco setup to build the C libraries too

I see. The right solution is to: 1. Make the foreign libraries not depend on a specific VM/GC; then 2. Put them in the right directory for VM-independent files, which is based on (system-library-subpath #f)—essentially, just by leaving out the 3m directory from the current paths. I think part 1 is almost true: the PortAudio foreign library itself certainly doesn’t depend on the Racket VM, and the callbacks.c helper doesn’t, either. I’m not sure, but it looks like mini-mzrt.c (for Windows) might not work for Racket CS: even if that’s the case, though, I think relatively recently added capabilities at the FFI layer, like unsafe-file-descriptor->semaphore and unsafe-poller, should be enough to implement that functionality in a portable way.

You will also need to modify portaudio.rkt to find the libraries in their VM-independent locations. There may be fancier things you could do with the lib variant of define-runtime-path or copy-foreign-libs in info.rkt, but I’m less sure about those.

invalid memory reference. Some debugging context lost context...: condition->exn do-raise dynamic-wind winder-dummy do-raise dynamic-wind /home/sage/Code/sgcom/build/xexpr.rkt:30:14 .../polyglot/txexpr.rkt:154:6 I have no idea why this happened. How would I debug this?

Ah, actually it was due to me passing a symbol to string->symbol. Is that error CS-specific?

That’s the Racket CS spelling of “seg fault”. Thanks for the report!

That error is a sign of a bug in Racket (or a misuse of unsafe code somewhere)