search

digego / extempore

A cyber-physical programming environment
1.41k stars 127 forks source link

ipc:load borked? #267

Closed benswift closed 8 years ago

benswift commented 8 years ago

ipc:load seems to be broken on OSX? haven't had time to look into it, or test on other platforms.

This is here to remind me to look into it when I get a chance.

JimKuhn commented 8 years ago

I think I have the load problem is addressed in de8a219c6aad2ee40f9d86054ba7f488da0dcfad. The IR generated for ipc is different from what is generated in the primary process (?) and required a tweak to a regex for some globals. Can you verify that it fixes the problem?

JimKuhn commented 8 years ago

I'm confused, however. What is supposed to be accessible from a non-primary process? I can't seem to access any xtlang values, functions or macros... Is it because all of these constructs store something in the local Scheme process?

I do see how ipc:define/call/load etc. make things happen. I guess I was just not assuming a special subset of functionality.

benswift commented 8 years ago

Hi Jim

Looks like it's still borked. To answer your question - the multi-process stuff is obviously just a separate scheme world, but that's useful for e.g. musicmaking, where I often run my scheme temporal recursions in the utility process so that the don't get delayed by long xtlang compiles in the primary process.

Having said that, I can't remember why ipc:load was implemented in the FFI and not just as a scheme function which calls ipc:call. I've got a patch here which fixes that (and gets rid of ipcLoad entirely). This is old code, so there might be some reason this won't work which I'm forgetting (Andy?). If there isn't, I'll push up this change, and we're all good.

benswift commented 8 years ago

b6c3a58 seems to fix it. I removed the stuff in the .inc file, since this scheme-only solution works fine. There may be edge cases, but we'll fix them if they pop up.