> Hence my suggestion for Lua, which doesn't have a GIL, as far as I can >> find. Nor does it need manual reference-keeping like is needed with Python >> or Perl. With Lua you can have as many evaluation environments as you want. >> Instantiating them when crossing a certain API boundary to be used by the >> library internals. >> > > I don't have direct experience with Lua, but have read/observed it for > many years. This is something that I could get behind as an embedded > *experimental* solution (to move "up" from lower-level C code), based on > what I've read. >
That would be the first step for any implementation, I take it -- we'd want to evaluate the benefits to be had. If we agree to start experimenting with Lua, the next step would be to create a high level design. Something I might be able to spend time on. @Julian, do you have a specific area of our code that would most benefit from "moving 'up' from C"? Preferably some part of code that's currently very much in flux? -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.
