hi list, hi claude.
using the great pdlua extension it is easy to create object(classe)s in lua. however, the class is registered on loading and then kept in memory of pd.
for rapid prototyping it would sometimes be nice to be able to do a "volatile" load (just like abstractions) of an object: so when i change the code and re-instantiate the object, i will get a new version.
would this be easy to implement? (e.g. by just using another function to register as pd-object: volatile() instead of class() or whatever...)
fmga.dsr IOhannes
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Hallo, zmoelnig@iem.at hat gesagt: // zmoelnig@iem.at wrote:
using the great pdlua extension it is easy to create object(classe)s in lua. however, the class is registered on loading and then kept in memory of pd.
for rapid prototyping it would sometimes be nice to be able to do a "volatile" load (just like abstractions) of an object: so when i change the code and re-instantiate the object, i will get a new version.
pyext has this, but AFAIK it isn't using the loader functionality when used as [pyext ...]. I agree that some way to reload is very handy, especially when one is still learning Lua and pdlua. Also the need to restart Pd makes working with a scripting language not much faster than working with C directly. Maybe it can be done inside Lua, though, using the dofile/loadfile functions. But I don't know Lua enough yet.
Still, attached are my first three lua externals. ;)
Ciao
zmoelnig@iem.at wrote:
hi list, hi claude.
using the great pdlua extension it is easy to create object(classe)s in lua. however, the class is registered on loading and then kept in memory of pd.
The problem is Pd doesn't give loaders the chance to load a class if it is already loaded, but there is a way around it, I think.
for rapid prototyping it would sometimes be nice to be able to do a "volatile" load (just like abstractions) of an object: so when i change the code and re-instantiate the object, i will get a new version.
It's certainly possible, here's a quick hack method:
-- volatile.lua volatile = pd.Class:new():register("volatile")
function volatile:initialize(s, m) dofile(m[1] .. ".lua") -- note, only searches current dir! return run(self, m) end
-- volatile-test.lua function run(self, m) pd.post("just testing stuff") self.inlets = 0 self.outlets = 0 return true end
Sorta works, but not elegant. Should be possible to do it so that the volatile user code is minimally different from the normal user code. Something like
-- volatile-test.lua pd.volatile(function() -- normal class code here end)
where pd.volatile(f) would munge the environment before calling the function argument, then unmunge the environment afterwards. Munging would take the form of replacing pd.Class with pd.VolatileClass or so. All VolatileClass objects would have the same real class registered in Pd,, but the loader can keep reloading classes that are not found because no new classes are really registered.
would this be easy to implement?
Not too hard, hopefully, but not trivial either. It's a nice idea that would be useful, it's a pain having to restart Pd when testing.
Also I plan [lua] to have an inlet/method where you can send names of scripts to be executed, which could be useful for quickly modifying some classes/objects without having to restart Pd.
Claude
Claude Heiland-Allen wrote:
zmoelnig@iem.at wrote:
hi list, hi claude.
[snip]
would this be easy to implement?
Not too hard, hopefully, but not trivial either.
I found it rather harder than I expected (eg: what is the rationale behind the type of class_addcreator()?), so I wrote a dirty quick class (in Lua) that lets you load/reload scripts at object initialization time. Doesn't have a reload method because iolet counts may change. See "luax-help.pd".
Also I plan [lua] to have an inlet/method where you can send names of scripts to be executed, which could be useful for quickly modifying some classes/objects without having to restart Pd.
This is done, also quick and dirty, neither: "load foo"--[lua] (which runs 'foo.lua') nor: [luax foo] (which grabs an initialization function from 'foo.luax') use the pd path yet. Shouldn't be hard to fix.
Claude