Since a lot of people were at POPL last week, I think it's worth pinging this list again.
Does anyone have a solution to the problem stated in the previous email? Namely, is there a way to either create a top-level variable that persists until the VM dies, get a list of all dynamically linked libraries, or require a module implemented in C who's module name differs from it's file name? Thank you. Thank you. ~Leif Andersen On Tue, Jan 19, 2016 at 3:20 PM, John Clements <cleme...@brinckerhoff.org> wrote: > >> On Jan 19, 2016, at 11:14 AM, Leif Andersen <l...@leifandersen.net> wrote: >> >> Is it possible to either create a variable that persists until the >> Racket VM shuts down or get a list of all of the libraries that are >> shared libraries that are currently being linked against the racket >> vm? > > I can’t help you. But! This reminds me of a closely related problem that > occurs with the `rsound` library. > > The rsound library contains shared libraries. Running rsound programs > performs dynamic linking against these libraries. > > When students try to upgrade the package, terrible things happen; the update > tries to replace the file, and the OS won’t allow it, because the dynamic > library is still linked. This leaves things in a half-installed state from > which (IIRC) it’s difficult to recover. If there were a way to enumerate > currently-linked shared libraries, the update could simply refuse to run, > which would be a substantial improvement. > > CAVEAT: I haven’t tested this in the last two years. Please forgive me if > this problem has already been resolved. > > Thanks! > > John > > > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
