Hi,
A few months ago, I inquired about what sorts of "sharing" can be done between PD and Lua. One Idea I have for working with Lua and PD was to create the interface in PD, and use PD variables to pass the data to the Lua script running, and I was just wondering if this is now possible?
- Lua access to PD variables
- Lua access to PD tables
Another idea that I had was, instead, have my Lua script create a bunch of 'receive' objects, and just have the PD interface send the data to that receiver, rather than use a variable.
I am just wondering how each of these approaches would function, as I am going to be creating between 20 and 60 variable/receive connections within a single script.
Also, is there any sort of "coding standard" that has been established in pdlua? When I started to learn Lua, I wasn't using PD, and since I started with PD, I noticed that the Object system used by pdlua was different from what I had done. I have since gone back and reworked some of my things so they are more like what pdlua uses. Just curious about this, as I don't want to find some "gotcha" a few months from now.
Thanks,
Mike
Mike McGonagle wrote:
- Lua access to PD variables
Now on the TODO list.
- Lua access to PD tables
Now on the TODO list, after being in my virtual TODO list for ages.
Another idea that I had was, instead, have my Lua script create a bunch of 'receive' objects, and just have the PD interface send the data to that receiver, rather than use a variable.
Yes, that works - I use Lua quite a bit for collecting values from my (many) GUI objects and sending them to one outlet.
See for example:
https://devel.goto10.org/svn/maximus/2008/d012345/vast-array-of-numbers-guts...
For going the other way (sending values to one of many GUI objects), I generally use Pd [makefilename] [list prepend] "; $1 $2" and so on, although it would be equally possible to do it in Lua.
Also, is there any sort of "coding standard" that has been established in pdlua? When I started to learn Lua, I wasn't using PD, and since I started with PD, I noticed that the Object system used by pdlua was different from what I had done.
The object system in pdlua isn't particularly well-thought out or elegant, I'd be interested in what you had developed and how it differs
- maybe I could learn something from it.
Claude
On 5/6/08, Claude Heiland-Allen claudiusmaximus@goto10.org wrote:
Mike McGonagle wrote:
- Lua access to PD variables
Now on the TODO list.
- Lua access to PD tables
Now on the TODO list, after being in my virtual TODO list for ages.
Groovy!
Another idea that I had was, instead, have my Lua script create a bunch of 'receive' objects, and just have the PD interface send the data to that receiver, rather than use a variable.
Yes, that works - I use Lua quite a bit for collecting values from my (many) GUI objects and sending them to one outlet.
See for example:
https://devel.goto10.org/svn/maximus/2008/d012345/vast-array-of-numbers-guts...
Thanks, I will have a look...
The object system in pdlua isn't particularly well-thought out or elegant, I'd be interested in what you had developed and how it differs - maybe I could learn something from it.
Well, thanks for that vote of encouragement, but after studying the methods used in pdlua, it is actually a bit less verbose. Many of the things I had done my way were about a 1/3 longer. It was a method that I borrowed from a book I have.
One thing I am curious about pdlua is how much of the C code is intertwined with the Lua code. Meaning, how much of the interface between the two is done in C, and how much in Lua.
Thanks again,
Mike
Claude
Hallo, Mike McGonagle hat gesagt: // Mike McGonagle wrote:
On 5/6/08, Claude Heiland-Allen claudiusmaximus@goto10.org wrote:
The object system in pdlua isn't particularly well-thought out or elegant, I'd be interested in what you had developed and how it differs - maybe I could learn something from it.
Well, thanks for that vote of encouragement, but after studying the methods used in pdlua, it is actually a bit less verbose. Many of the things I had done my way were about a 1/3 longer. It was a method that I borrowed from a book I have.
Actually Lua itself doesn't have a preconfigured object system like C++ or Python, so you'd have to roll your own anyway. Pdlua uses a protype-based objects system.
Another interesting "object system" would be the Single Method approach: http://www.lua.org/pil/16.5.html where you use a closure to store the object's state.
I recently wrote a LOGO-style turtle using this idiom. Attached is a simplified version of it (removed typechecks etc).
Take special note of how seamlessly the single method turtle in smtut.lua can be included in the Pd object runturtle.lua using this primitive method:
function M:in_1(action, atoms)
self.t(action, atoms) -- selt.t is the single method turtle
end
It's even possible to convert smtut.lua to a proper module so that you can reload it luax-style while Pd is running.
Ciao
Frank Barknecht _ ______footils.org__
Hum, from what I see on this, pdlua uses one method of "object encapsulation", while pdluax uses this single method type of object.
I know that Lua itself doesn't have an object style, I am just curious how pdlua does this, so that I can at least follow along in the style being used.
I really like what I have seen with pdlua, and you are right, Frank, I also think this will help to open up PD. One of the things that I have had trouble with in PD (by itself) was having to go in and repatch things to make some sort of change in how I am generating the data, while using pdlua, I think that it will make these sorts of changes much easier to understand.
Mike
On 5/6/08, Frank Barknecht fbar@footils.org wrote:
Hallo,
Mike McGonagle hat gesagt: // Mike McGonagle wrote:
On 5/6/08, Claude Heiland-Allen claudiusmaximus@goto10.org wrote:
The object system in pdlua isn't particularly well-thought out or elegant, I'd be interested in what you had developed and how it differs - maybe I could learn something from it.
Well, thanks for that vote of encouragement, but after studying the methods used in pdlua, it is actually a bit less verbose. Many of the things I had done my way were about a 1/3 longer. It was a method that I borrowed from a book I have.
Actually Lua itself doesn't have a preconfigured object system like C++ or Python, so you'd have to roll your own anyway. Pdlua uses a protype-based objects system.
Another interesting "object system" would be the Single Method approach: http://www.lua.org/pil/16.5.html where you use a closure to store the object's state.
I recently wrote a LOGO-style turtle using this idiom. Attached is a simplified version of it (removed typechecks etc).
Take special note of how seamlessly the single method turtle in smtut.lua can be included in the Pd object runturtle.lua using this primitive method:
function M:in_1(action, atoms) self.t(action, atoms) -- selt.t is the single method turtle endIt's even possible to convert smtut.lua to a proper module so that you can reload it luax-style while Pd is running.
Ciao
-- Frank Barknecht _ ______footils.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Claude Heiland-Allen wrote:
Mike McGonagle wrote:
- Lua access to PD variables
Now on the TODO list.
Now implemented, check the [revalue] example. It seems to work here in Miller's pd-0.41-4 but your mileage may vary.
svn co https://devel.goto10.org/svn/maximus/pdlua pdlua
check the README for new or improved building instructions - and please let me know if the autoconf system works for you, and if you have to pass any flags to ./configure to get it to find Lua (it has different names on different distros, will try to accumulate checks for all of them).
Claude
On Tue, 6 May 2008, Claude Heiland-Allen wrote:
Yes, that works - I use Lua quite a bit for collecting values from my (many) GUI objects and sending them to one outlet.
Btw, GridFlow 0.9.4 introduces [receives], a tool for doing exactly that. Else, it makes the guts of such abstractions inanely repetitive. The help file isn't there yet, but you can see it in use in the new [#camera].
I made it because I was adding a grey-out feature in the [#camera] GUI (because it supports 4 camera types with different feature-sets), and thought that the guts subpatch was too full. On average, if a patch needs scrollbars, it's too full, IMHO. I hope to introduce more shortcuts like this in the future.
I haven't gotten into Lua yet, but whenever I have an external to make for which I'd really have loved to use Ruby, I'll use Lua. That language never got me excited, but then, I think I can enjoy it better than Python, and the languages that got me excited (Ruby and Tcl) shows me that getting excited is not so much a good sign.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Mike McGonagle wrote:
- Lua access to PD tables
Now implemented (lacking some things, like GUI refresh).
Check the [ltabdump] and [ltabfill] examples.
Still lacking some niceness, should be able to do:
local t = pd.Table:new():sync("mytable") t[123] = 456 local x = t[789] return #t
but that's not (currently) implemented. Instead you have to do:
local t = pd.Table:new():sync("mytable") t:set(123, 456) local x = t:get(789) return t:length()
also note that Pd tables are indexed from 0, unlike Lua's 1-based indexing. I'm not sure whether to have pd.Table have 1-based indexing like Lua or stick with the Pd-style 0-based indexing (which is what is currently implemented).
Work in progress, hopefully when I polish this up a bit I'll make a pdlua-0.5 release, at which point the table API will be relatively fixed. Comments welcome.
Claude
Claude, Thanks for the "speedy" turn around on these things. Unfortunately, I am not really in a position at the moment to learn how to compile pdlua. I pretty much depend on the extended version (thanks to Hans) for these things. Do your sources automatically update those things? If not, how long before it gets rolled into the extended stuff?
I will say, while I really like Lua, last night I got caught in a trap, thinking that I found "the best" way to implement something, but it turned out to be a dead end, and I lost a couple of hours playing with that stuff.
also note that Pd tables are indexed from 0, unlike Lua's 1-based indexing.
I'm not sure whether to have pd.Table have 1-based indexing like Lua or stick with the Pd-style 0-based indexing (which is what is currently implemented).
How do other implementations do this? Should we look to see how "Vessel" does it in Max? It could be one of those things that turns out to be a "gotcha" for new users who happen to miss that these tables are 0 based, instead of the Lua 1 based...
Work in progress, hopefully when I polish this up a bit I'll make a pdlua-0.5 release, at which point the table API will be relatively fixed. Comments welcome.
Thanks, again, Claude. I will have to see if I can get this up and running, maybe by the weekend.
Mike
Mike McGonagle wrote:
Unfortunately, I am not really in a position at the moment to learn how to compile pdlua.
Which platform are you on? If you're able to get on IRC, #dataflow on irc.freenode.net, I could try and help you get it compiled, and hopefully make it easier for others to compile it too.
I pretty much depend on the extended version (thanks to Hans) for these things. Do your sources automatically update those things?
After some discussion with Hans, we decided that as pdlua is still changing rapidly it would be better to have pdlua as a separate download. Hans, can you confirm that pdlua is no longer included in the pd-extended builds?
I think there is still an old version of pdlua in the pure-data svn repo, if someone can remove it I'd appreciate it, either that or convert it to an svn:external thing against the pdlua development version:
https://devel.goto10.org/svn/maximus/pdlua
[snip]
also note that Pd tables are indexed from 0, unlike Lua's 1-based indexing.
I'm not sure whether to have pd.Table have 1-based indexing like Lua or stick with the Pd-style 0-based indexing (which is what is currently implemented).
How do other implementations do this? Should we look to see how "Vessel" does it in Max? It could be one of those things that turns out to be a "gotcha" for new users who happen to miss that these tables are 0 based, instead of the Lua 1 based...
Good idea, I'll take a look.
Claude
On Wed, May 7, 2008 at 9:37 AM, Claude Heiland-Allen < claudiusmaximus@goto10.org> wrote:
Mike McGonagle wrote:
Unfortunately, I am not really in a position at the moment to learn how to compile pdlua.
Which platform are you on? If you're able to get on IRC, #dataflow on irc.freenode.net, I could try and help you get it compiled, and hopefully make it easier for others to compile it too.
I am running Mac OS X 10.4.9, but the real trouble is that I don't have a internet connection at home. It is more a matter of time, and yes, a little bit of apprehension in doing something more.
I pretty
much depend on the extended version (thanks to Hans) for these things. Do your sources automatically update those things?
After some discussion with Hans, we decided that as pdlua is still changing rapidly it would be better to have pdlua as a separate download. Hans, can you confirm that pdlua is no longer included in the pd-extended builds?
This is sad. While I understand that it is still not quite stable, how many people are using it? Is it causing major troubles with other things?
I am not really adverse to compiling this myself, as I do need to learn this, and as I said, it is more a matter of timing, than anything else. I will take a look this weekend, when things slow down.
Mike
Mike McGonagle wrote:
After some discussion with Hans, we decided that as pdlua is still changing rapidly it would be better to have pdlua as a separate download. Hans, can you confirm that pdlua is no longer included in the pd-extended builds?This is sad. While I understand that it is still not quite stable, how many people are using it? Is it causing major troubles with other things?
I think hans can set a flag that the autobuild proceeds even if the pdlua build fails, so it should not cause any troubles. but I think I can speak for hans, sayeing that it is always some work (time...) to get the autobuild for an external set up. I helped last time getting it compile on os x, but the autobuild scripts and management are still hans' domain. marius.
On Wed, May 7, 2008 at 10:29 AM, marius schebella < marius.schebella@gmail.com> wrote:
I think hans can set a flag that the autobuild proceeds even if the pdlua build fails, so it should not cause any troubles. but I think I can speak for hans, sayeing that it is always some work (time...) to get the autobuild for an external set up. I helped last time getting it compile on os x, but the autobuild scripts and management are still hans' domain.
My comment was not directed at Hans, I know there were a MILLION things to do to get Extended to be where it is... Just that it is sad that we can't use this right out of the box.
Mike
marius.
Claude Heiland-Allen wrote:
After some discussion with Hans, we decided that as pdlua is still changing rapidly it would be better to have pdlua as a separate download. Hans, can you confirm that pdlua is no longer included in the pd-extended builds?
an old version of pdlua (0.3) seems to be included, I had problems yesterday to open franks turtle example. but I would really like to see pdlua included in the nightly autobuilds! I think the only part missing is getting the latest svn snapshot from your repository every night.
marius.
Hallo, marius schebella hat gesagt: // marius schebella wrote:
an old version of pdlua (0.3) seems to be included, I had problems yesterday to open franks turtle example.
It should work, if you rename runturtle.pd_lua to the old format: runturtle.lua. I'm not using any of the recent pdlua features like clocks or values.
Ciao
Frank Barknecht _ ______footils.org__
Frank Barknecht wrote:
Hallo, marius schebella hat gesagt: // marius schebella wrote:
an old version of pdlua (0.3) seems to be included, I had problems yesterday to open franks turtle example.
It should work, if you rename runturtle.pd_lua to the old format: runturtle.lua. I'm not using any of the recent pdlua features like clocks or values.
Ciao
hi frank, I had problems with smtut.lua, first it was not found, then I got an error: lua: error loading `runturtle': /sw/share/lua/5.1/smtut.lua:1: loop or previous error loading module 'smtut' runturtle ... couldn't create I can't dig into this right now, I am sure there is an explanation, but I need some time to see which. marius.
On May 7, 2008, at 4:37 PM, Claude Heiland-Allen wrote:
Mike McGonagle wrote:
Unfortunately, I am not really in a position at the moment to learn how to compile pdlua.
Which platform are you on? If you're able to get on IRC, #dataflow
on irc.freenode.net, I could try and help you get it compiled, and
hopefully make it easier for others to compile it too.I pretty much depend on the extended version (thanks to Hans) for these
things. Do your sources automatically update those things?After some discussion with Hans, we decided that as pdlua is still
changing rapidly it would be better to have pdlua as a separate
download. Hans, can you confirm that pdlua is no longer included
in the pd-extended builds?
It'll be included in the branches/pd-extended/0.41 nightly builds
once that happens, and removed from the 0.40 release. I think there
is no harm in including it the test builds, and it makes it easier to
test. But since pdlua is still changing, it shouldn't be in a release.
.hc
I think there is still an old version of pdlua in the pure-data svn
repo, if someone can remove it I'd appreciate it, either that or
convert it to an svn:external thing against the pdlua development
version:https://devel.goto10.org/svn/maximus/pdlua
[snip]
also note that Pd tables are indexed from 0, unlike Lua's 1-based
indexing.I'm not sure whether to have pd.Table have 1-based indexing like
Lua or stick with the Pd-style 0-based indexing (which is what is currently implemented).How do other implementations do this? Should we look to see how
"Vessel" does it in Max? It could be one of those things that turns out to
be a "gotcha" for new users who happen to miss that these tables are 0
based, instead of the Lua 1 based...Good idea, I'll take a look.
Claude
Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish. -William Carlos Williams
Hallo, Claude Heiland-Allen hat gesagt: // Claude Heiland-Allen wrote:
Mike McGonagle wrote:
- Lua access to PD tables
Now implemented (lacking some things, like GUI refresh).
This requires pd-0.41 now, doesn't it? On my current 0.40 install pdlua complains about missing garray_getfloatwords, which seems to have been added to m_pd.h in 0.41
Ciao
Frank Barknecht _ ______footils.org__
Frank Barknecht wrote:
Hallo, Claude Heiland-Allen hat gesagt: // Claude Heiland-Allen wrote:
Mike McGonagle wrote:
- Lua access to PD tables
Now implemented (lacking some things, like GUI refresh).
This requires pd-0.41 now, doesn't it? On my current 0.40 install pdlua complains about missing garray_getfloatwords, which seems to have been added to m_pd.h in 0.41
Ciao
Argh, I didn't check earlier versions - I just cribbed from [tabread] in pd-0.41-4.
It should now detect (at compile time) which Pd version is used, and use the appropriate array API. Note that the old API is not 64-bit safe, so if you experience weird array issues with pdlua compiled against older Pd versions, it's not my fault, and you should upgrade first Pd then recompile pdlua against the new Pd.
I haven't tested this code thoroughly, I'm happy with my 0.41-4 install, let me know if you use older Pd versions and have trouble compiling.
There's also a return of Makefile.static, an alternative to the incomplete autoconf system. I think I'll abandon the autoconf system, as it's too painful (what with Lua having 10 different names on 10 different systems...).
Claude
Claude Heiland-Allen wrote:
Mike McGonagle wrote:
- Lua access to PD tables
Now implemented (lacking some things, like GUI refresh).
Now added: t:redraw(), see [ltabfill] example.
Still lacking some niceness, should be able to do:
local t = pd.Table:new():sync("mytable") t[123] = 456 local x = t[789] return #t
but that's not (currently) implemented.
And it looks like it won't be implemented for the foreseeable future:
"#t does not invoke the __len metamethod when t is a table." See end of: http://lua-users.org/wiki/GeneralizedPairsAndIpairs
This means pd.Table will remain ugly, with :length() :set() :get(), at least until Lua 5.2 (maybe).
Mike McGonagle also wrote:
I am running Mac OS X 10.4.9, but the real trouble is that I don't have a internet connection at home. It is more a matter of time, and yes, a little bit of apprehension in doing something more.
Ok, using the Makefile.static you should be able to download two tarballs:
https://devel.goto10.org/dl.php?repname=maximus&path=%2Fpdlua%2F&rev... http://www.lua.org/ftp/lua-5.1.3.tar.gz
Unpack pdlua.tar.gz, then put lua-5.1.3.tar.gz directly inside pdlua/
Then edit pdlua/Makefile.static to change the PLATFORM= line to macosx, and within pdlua/ run "make -f Makefile.static"
It should compile first Lua then pdlua, and then you can test it with "pd -path src/ -lib lua"
Hope this works, let me know if not.
Claude
On Fri, May 9, 2008 at 7:38 AM, Claude Heiland-Allen < claudiusmaximus@goto10.org> wrote:
It should compile first Lua then pdlua, and then you can test it with "pd -path src/ -lib lua"
Just so you know, Claude, this didn't work. But when I put both the lua.pd_darwin and pd.lua into the 'extras' folder of the application I compiled it against, everything appears to work fine.
Thanks for all your help on this, I will be doing some work this weekend, and hopefully will have something that could be "shared" next week...
Mike
-
Claude Heiland-Allen -
Frank Barknecht -
Hans-Christoph Steiner -
marius schebella -
Mathieu Bouchard -
Mike McGonagle