Hi Claude and list,
I'm thinking if a custom file extension for pdlua classes would make sense? Currently pdlua loads all *.lua files, which complicates working with *.lua modules not intended to be used as pd classes: Those would have to be in a directory outside of Pd's search path to not pollute Pd's namespace.
So my suggestion would be to use something like *.pd_lua, *.pdlua or *.l_lua as extension. What do you think? The same question may become an issue for other loaders as well, so a standard solution would be nice.
Ciao
Frank Barknecht _ ______footils.org__
Frank Barknecht wrote:
Hi Claude and list,
I'm thinking if a custom file extension for pdlua classes would make sense? Currently pdlua loads all *.lua files, which complicates working with *.lua modules not intended to be used as pd classes: Those would have to be in a directory outside of Pd's search path to not pollute Pd's namespace.
Ah, true.
So my suggestion would be to use something like *.pd_lua, *.pdlua or *.l_lua as extension. What do you think? The same question may become an issue for other loaders as well, so a standard solution would be nice.
Ok, expect this change in the next release (sometime in March). I'm leaning towards *.pd_lua personally, to match *.pd_linux and *.pd_darwin, but if anyone has strong objections let me know.
Claude
On Feb 10, 2008, at 8:43 AM, Claude Heiland-Allen wrote:
Frank Barknecht wrote:
Hi Claude and list,
I'm thinking if a custom file extension for pdlua classes would make sense? Currently pdlua loads all *.lua files, which complicates working with *.lua modules not intended to be used as pd classes: Those would have to be in a directory outside of Pd's search path to not pollute Pd's namespace.
Ah, true.
So my suggestion would be to use something like *.pd_lua, *.pdlua or *.l_lua as extension. What do you think? The same question may become an issue for other loaders as well, so a standard solution would be nice.
Ok, expect this change in the next release (sometime in March). I'm leaning towards *.pd_lua personally, to match *.pd_linux and *.pd_darwin, but if anyone has strong objections let me know.
I think that we'd probably be better off not adding any more arcane
file extensions. That just adds one more hurdle to getting things
working. (I actually think that pd binaries should use the native
extensions too, like .so, .bundle, .dll).
An easy way to avoid this is to have pdlua look for a setup function
in the .lua it is trying to open. If there is no setup function,
then it wouldn't load that file. That's really the key technique for
loading pd binaries. The differing file extensions aren't really
necessary.
.hc
"It is convenient to imagine a power beyond us because that means we
don't have to examine our own lives.", from "The Idols of
Environmentalism", by Curtis White
Hans-Christoph Steiner wrote:
An easy way to avoid this is to have pdlua look for a setup function in the .lua it is trying to open.
If it's easy, submit a patch.
pdlua just runs scripts, it doesn't inspect them.
If there is no setup function, then it wouldn't load that file.
You can't see what's in a file without loading it.
You can't see which class(es) a Lua script registers without running it.
Example: the name of the class could be stored in the file in rot13 encoding and decoded at runtime, before it is registered with Pd.
That's really the key technique for loading pd binaries.
Lua scripts are not binaries.
Not all Lua scripts are related to Pd.
Not all binaries with name_setup() symbols exported are related to Pd.
The differing file extensions aren't really necessary.
*all* file naming is arbitrary. Henceforth I'll name my patches in unary by order of creation date, incrementing the letter once my filesystem complains of file names being too long.
Claude
http://claudiusmaximus.goto10.org
a.pd aa.pd aaa.pd aaaa.pd aaaaa.pd aaaaaa.pd aaaaaaa.pd aaaaaaaa.pd aaaaaaaaa.pd aaaaaaaaaa.pd aaaaaaaaaaa.pd aaaaaaaaaaaa.pd aaaaaaaaaaaaa.pd aaaaaaaaaaaaaa.pd aaaaaaaaaaaaaaa.pd aaaaaaaaaaaaaaaa.pd aaaaaaaaaaaaaaaaa.pd aaaaaaaaaaaaaaaaaa.pd aaaaaaaaaaaaaaaaaaa.pd aaaaaaaaaaaaaaaaaaaa.pd aaaaaaaaaaaaaaaaaaaaa.pd aaaaaaaaaaaaaaaaaaaaaa.pd aaaaaaaaaaaaaaaaaaaaaaa.pd aaaaaaaaaaaaaaaaaaaaaaaa.pd aaaaaaaaaaaaaaaaaaaaaaaaa.pd aaaaaaaaaaaaaaaaaaaaaaaaaa.pd aaaaaaaaaaaaaaaaaaaaaaaaaaa.pd aaaaaaaaaaaaaaaaaaaaaaaaaaaa.pd
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I think that we'd probably be better off not adding any more arcane
file extensions.
Lua scripts don't have a required file extension, the .lua is just a convention in the lua world, but as an embedded language, you will fine lua scripts with all kinds of other extensions. *.lua however is kind of required when you import modules using "require", but as pdlua scripts aren't modules, we'd better avoid to use it as well.
An easy way to avoid this is to have pdlua look for a setup function
in the .lua it is trying to open. If there is no setup function,
then it wouldn't load that file. That's really the key technique for
loading pd binaries. The differing file extensions aren't really
necessary.
I don't know much about it, but aren't loaders in Pd registered for file endings? I guess it may slow down things a lot if python, rt-scheme, Q, lua or whatever loader would first need to inspect all files to find out that most aren't loadable.
Ciao
Frank Barknecht _ ______footils.org__
hi
I like *.lua because editors recognize them as lua and are able to
parse the magic. What I was having problems with pdlua is that I have
to restart PD whenever I change my script. Reloading the pd patch
doesn't even do it. Could there be some autowatch flag read from the
scripts that then checks to see if the file is changing and reloads
it? If there is such a flag or method to reload the scripts without
restarting PD please tell me. I have Pd-0.40.3-extended-20080203 on
leopard.
cheers + thanks!
(())_n
On Feb 11, 2008, at 3:14 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I think that we'd probably be better off not adding any more arcane file extensions.
Lua scripts don't have a required file extension, the .lua is just a convention in the lua world, but as an embedded language, you will fine lua scripts with all kinds of other extensions. *.lua however is kind of required when you import modules using "require", but as pdlua scripts aren't modules, we'd better avoid to use it as well.
An easy way to avoid this is to have pdlua look for a setup function in the .lua it is trying to open. If there is no setup function, then it wouldn't load that file. That's really the key technique for loading pd binaries. The differing file extensions aren't really necessary.
I don't know much about it, but aren't loaders in Pd registered for file endings? I guess it may slow down things a lot if python, rt-scheme, Q, lua or whatever loader would first need to inspect all files to find out that most aren't loadable.
Ciao
Frank Barknecht _
______footils.org__
(())_n wrote:
I like *.lua because editors recognize them as lua and are able to
parse the magic.
You should be able to manually choose a highlight mode in any decent editor, regardless of extension, and some you should be able to add a default mode for extra extensions.
It would be confusing if .pd files were called .txt, I think....
What I was having problems with pdlua is that I have to restart PD whenever I change my script.
Try the [luax scriptname argument1 argument2 a b 1 2] object. That reloads the script on each object creation, but the scripts have to have a slightly different format.
Claude
On Feb 11, 2008, at 1:27 PM, Claude Heiland-Allen wrote:
(())_n wrote:
I like *.lua because editors recognize them as lua and are able to parse the magic.
You should be able to manually choose a highlight mode in any decent editor, regardless of extension, and some you should be able to add a default mode for extra extensions.
It would be confusing if .pd files were called .txt, I think....
It would be. But .pd seems good enough, we get along fine
without .pd_abstraction, .pd_patch, etc. And Max/MSP's mxj seems to
work fine only using .java. pyext seems to work well using
only .py. There is nothing stopping anyone from making a .dll on
Windows with a setup function and sticking it in pd/extra. If
someone tried to load it, Pd would make it's best effort, and the
setup function won't create any inlets or outlets, so it would just
sit there.
The reason why Pd has so many extensions for binaries is to deal with
binary incompatibility (i.e. an object compiled for PowerPC won't
work on Intel). If you want to make support classes in a separate
lua file, I would recommend a subdir, like support/myfile.lua. That
would make things clear without having to create custom file
extensions, which will break all sorts of other things, like
automatic detection in editors, as well as creating an extra arcane
detail unique to Pd that someone has to learn in order to use pdlua.
.hc
What I was having problems with pdlua is that I have to restart PD whenever I change my script.
Try the [luax scriptname argument1 argument2 a b 1 2] object. That reloads the script on each object creation, but the scripts have to
have a slightly different format.Claude
http://claudiusmaximus.goto10.org
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
If you are not part of the solution, you are part of the problem.
Hans-Christoph Steiner wrote:
There is nothing stopping anyone from making a .dll on
Windows with a setup function and sticking it in pd/extra. If
someone tried to load it, Pd would make it's best effort, and the
setup function won't create any inlets or outlets, so it would just
sit there.
this of course is plain wrong.
the "setup"-function _never_ creates any inlets and outlets, or even an object. it is the "new"-function (aka creator) that handles instantiation.
it is perfectly possible to create a dll that does not provide any objectclasses (and is still "loaded" by Pd). it is not possible to instantiate such a nonexistant objectlass though - it would always "just sit there" in dashed lines...
fgmadsr. IOhannes
On Feb 12, 2008, at 4:03 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
There is nothing stopping anyone from making a .dll on Windows
with a setup function and sticking it in pd/extra. If someone
tried to load it, Pd would make it's best effort, and the setup
function won't create any inlets or outlets, so it would just sit
there.this of course is plain wrong.
the "setup"-function _never_ creates any inlets and outlets, or
even an object. it is the "new"-function (aka creator) that handles instantiation.it is perfectly possible to create a dll that does not provide any
objectclasses (and is still "loaded" by Pd). it is not possible to
instantiate such a nonexistant objectlass though - it would always
"just sit there" in dashed lines...
Yes, you're right, I didn't go into detail. Without the setup
function being called, the new function will never be called, and
therefore no inlets and outlets would be created. But this is
orthogonal to the thread.
The point remains, even though Pd objectclasses on Windows use the
same file extension as generic libraries (dll), it is not causing
problems.
.hc
The arc of history bends towards justice. - Dr. Martin Luther
King, Jr.
Hans-Christoph Steiner wrote:
The point remains, even though Pd objectclasses on Windows use the same file extension as generic libraries (dll), it is not causing problems.
Didn't you yourself have issues with your hid external? I seem to recall you had to rename it to hidio because of conflicts with Windows' own hid.dll or something? That is the same kind of conflict that will be avoided by naming the Lua scripts .pd_lua instead of .lua alone.
http://lists.puredata.info/pipermail/pd-dev/2006-01/005721.html
Thanks,
Claude
On Feb 12, 2008, at 12:57 PM, Claude Heiland-Allen wrote:
Hans-Christoph Steiner wrote:
The point remains, even though Pd objectclasses on Windows use the
same file extension as generic libraries (dll), it is not causing
problems.Didn't you yourself have issues with your hid external? I seem to
recall you had to rename it to hidio because of conflicts with
Windows' own hid.dll or something? That is the same kind of
conflict that will be avoided by naming the Lua scripts .pd_lua
instead of .lua alone.http://lists.puredata.info/pipermail/pd-dev/2006-01/005721.html
That is true, but the issue that started this thread was about
mistakenly loading lua files that were not meant to be Pd
objectclasses, no? That's a different issue. I don't think that the
OS would prevent loading different myobject.lua files, but Windows
has surprised me with its stupidity more than once. Plus that
applied to Windows' loader. The Pd loader is separate, which is what
pdlua is using.
I think this kind of thing should be caused by a real world problem
rather than a hypothetical. mxj uses .java and it has been used a
lot. People could also write java classes that are not intended to
be loaded by Max and stick them in the same folder. So far, it
doesn't seem to be a problem, AFAIK.
.hc
There is no way to peace, peace is the way. -A.J. Muste
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I think this kind of thing should be caused by a real world problem
rather than a hypothetical. mxj uses .java and it has been used a
lot. People could also write java classes that are not intended to
be loaded by Max and stick them in the same folder. So far, it
doesn't seem to be a problem, AFAIK.
It's *not* a hypothetical problem at all. Please test it first before jumping to wrong conclusions, see below for how. Claude and I are already running Lua a lot and at least I have run into the problem of nameclashes.
First: mxj for Pd (pdj) is not a loader, so it doesn't have the problem, as you specify the filename in the object name. If you don't specify a certain filename because it's a module, pdj won't load it. Similar things are possible with luax, also [pyext ...] works that way. We aren't talking about this kind of external here.
However for the pdlua loader, lua scripts shadow e.g. abstractions. Here's how to test it: Make a lua file with this content only:
print("Hey, I shouldn't load at all")
This is not a valid Pd class written in Lua. Then make it nameclash with any abstraction in your path by naming it e.g. "list-drip.lua" and putting it before the abstraction into your path. Then try to create a [list-drip]. pdlua will run the lua file instead of list-drip.pd and print "Hey, I shouldn't load at all". The wrong [list-drip] will remain dashed.
All of this is *trivial* to fix with a special file ending, whereas every other solution suggested so far is either completely impractical ("move modules outside of Pd's search path"), doesn't fix anything ("keep the status quo") or is overcomplicated and a possible performance drain ("add code which tries to load every *.lua file but goes on, if the file doesn't register a class properly").
Ciao
Frank Barknecht _ ______footils.org__
what about a special pdlua_path variable? (don't know how easy this would be to implement). pdlua would then only search in the exlicitely given folders. that would speed up loading process, too. marius.
Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I think this kind of thing should be caused by a real world problem
rather than a hypothetical. mxj uses .java and it has been used a
lot. People could also write java classes that are not intended to
be loaded by Max and stick them in the same folder. So far, it
doesn't seem to be a problem, AFAIK.It's *not* a hypothetical problem at all. Please test it first before jumping to wrong conclusions, see below for how. Claude and I are already running Lua a lot and at least I have run into the problem of nameclashes.
First: mxj for Pd (pdj) is not a loader, so it doesn't have the problem, as you specify the filename in the object name. If you don't specify a certain filename because it's a module, pdj won't load it. Similar things are possible with luax, also [pyext ...] works that way. We aren't talking about this kind of external here.
However for the pdlua loader, lua scripts shadow e.g. abstractions. Here's how to test it: Make a lua file with this content only:
print("Hey, I shouldn't load at all")
This is not a valid Pd class written in Lua. Then make it nameclash with any abstraction in your path by naming it e.g. "list-drip.lua" and putting it before the abstraction into your path. Then try to create a [list-drip]. pdlua will run the lua file instead of list-drip.pd and print "Hey, I shouldn't load at all". The wrong [list-drip] will remain dashed.
All of this is *trivial* to fix with a special file ending, whereas every other solution suggested so far is either completely impractical ("move modules outside of Pd's search path"), doesn't fix anything ("keep the status quo") or is overcomplicated and a possible performance drain ("add code which tries to load every *.lua file but goes on, if the file doesn't register a class properly").
Ciao
On Feb 12, 2008, at 6:44 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I think this kind of thing should be caused by a real world problem rather than a hypothetical. mxj uses .java and it has been used a lot. People could also write java classes that are not intended to be loaded by Max and stick them in the same folder. So far, it doesn't seem to be a problem, AFAIK.
It's *not* a hypothetical problem at all. Please test it first before jumping to wrong conclusions, see below for how. Claude and I are already running Lua a lot and at least I have run into the problem of nameclashes.
First: mxj for Pd (pdj) is not a loader, so it doesn't have the problem, as you specify the filename in the object name. If you don't specify a certain filename because it's a module, pdj won't load it. Similar things are possible with luax, also [pyext ...] works that way. We aren't talking about this kind of external here.
However for the pdlua loader, lua scripts shadow e.g. abstractions. Here's how to test it: Make a lua file with this content only:
print("Hey, I shouldn't load at all")
This is not a valid Pd class written in Lua. Then make it nameclash with any abstraction in your path by naming it e.g. "list-drip.lua" and putting it before the abstraction into your path. Then try to create a [list-drip]. pdlua will run the lua file instead of list-drip.pd and print "Hey, I shouldn't load at all". The wrong [list-drip] will remain dashed.
All of this is *trivial* to fix with a special file ending, whereas every other solution suggested so far is either completely impractical ("move modules outside of Pd's search path"), doesn't fix anything ("keep the status quo") or is overcomplicated and a possible performance drain ("add code which tries to load every *.lua file but goes on, if the file doesn't register a class properly").
This is not something that is exclusive to lua or pdlua. This is
just a classic nameclash issue, but triggered in a new way. All of
the normal techniques of dealing with nameclashes in Pd would also
work. I think we are much better off using one generalized technique
for handling name clashes that works everywhere, than many domain-
specific techniques, like .pd_lua.
A naming convention could be one way to help the situation. For
example, how about making non-objectclass lua files have a specific
name prefix, like "lib" (i.e. libsupport.lua). Yes, this would be a
name clash with anything named 'libsupport', but I think a prefix
could be chosen that would really be rarely a problem. Then you get
all of the niceness of having the file called .lua, and very few name
clashes.
I am not arguing this for some arcane reason. All of the new Pd
binary extensions (.pd_imac, .l_i386, .m_i386, etc.) that have been
added have ended up causing me a lot of extra work in Pd-extended
with no real benefit that I could see. Even the
standard .pd_darwin/.pd_linux has created extra work.
.hc
Mistrust authority - promote decentralization. - the hacker ethic
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I am not arguing this for some arcane reason. All of the new Pd
binary extensions (.pd_imac, .l_i386, .m_i386, etc.) that have been
added have ended up causing me a lot of extra work in Pd-extended
with no real benefit that I could see. Even the
standard .pd_darwin/.pd_linux has created extra work.
This reason doesn't apply here: There still would be only one file ending for pdlua files (two with luax), so nothing at all would change for pd-extended or any installer besides switching "install *.lua" to "install *.pdlua" or similar where necessary.
If a pdlua class uses sperate modules, it would needed to be handled individually anway much like any other external, that needs some kind of supplementary material (like fonts or textures for Gem).
Ciao
Frank Barknecht _ ______footils.org__
On Feb 13, 2008, at 3:44 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
I think this kind of thing should be caused by a real world
problem rather than a hypothetical.i think this discussion _is_ triggered by a real world problem, and
you seem to try making it hypothetical.
I guess I missed it then, where was it described? Here's how the
thread started:
"Currently pdlua loads all *.lua files, which complicates working
with *.lua modules not intended to be used as pd classes: Those would
have to be in a directory outside of Pd's search path to not pollute
Pd's namespace. "
So how about using Pd's normal tools for handling name clashes and
additionally, using a naming prefix like "lib" for the lua files that
are not intended to be Pd objectclasses (as I described earlier)?
Another possibility is using a subdir for these files.
Then we would not have to break the .lua naming convention and still
solve the problem easily. And people wouldn't have to learn a new
detail to get things working. They would then need good style once
they get things working, which I think is a preferrable to having to
learn naming conventions in order to get things working.
.hc
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, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I guess I missed it then, where was it described? Here's how the
thread started:"Currently pdlua loads all *.lua files, which complicates working
with *.lua modules not intended to be used as pd classes: Those would
have to be in a directory outside of Pd's search path to not pollute
Pd's namespace. "So how about using Pd's normal tools for handling name clashes and
additionally, using a naming prefix like "lib" for the lua files that
are not intended to be Pd objectclasses (as I described earlier)?
Another possibility is using a subdir for these files.
The reason to solve the nameclash with a much simpler solution like the seperate suffix is that unlike for abstractions, here such a much simpler solution is available! Nothings forces pdlua to rely on .lua as an ending, except that we'd miss an opportunity to complicate things by having to educate users to move files into allowed directories or give them unusual prefixes.
There are many general purpose lua modules already written, which end in *.lua, and I wouldn't like to have to rename them and edit them to use a "lib" or other artificial prefixes. It is much more against the Lua conventions to require general purpose modules to follow a certain naming style just to avoid our problem with nameclashes in a very special case.
And then: When a special prefix should be allowed, why not a special suffix? Especially when Pd discerns filetypes by suffix in this case?
Ciao
Frank Barknecht _ ______footils.org__
On Wed, Feb 13, 2008 at 02:29:31PM -0500, Hans-Christoph Steiner wrote:
"Currently pdlua loads all *.lua files, which complicates working
with *.lua modules not intended to be used as pd classes: Those would
have to be in a directory outside of Pd's search path to not pollute
Pd's namespace. "So how about using Pd's normal tools for handling name clashes and
additionally, using a naming prefix like "lib" for the lua files that
are not intended to be Pd objectclasses (as I described earlier)?
Another possibility is using a subdir for these files.
The problem is Hans, that this is not a nameclash issue at all. The problem is that *all* .pd_linux and .pd files are meant to be read by Pd as instantiable objects. This is not true for all .lua files. It's obvious that the way around this is to make a new prefix which is always treated by pd-lua like .pd and .pd_linux files are (as an instantiable object), and keep .lua files completely separate and ignored by Pure Data.
The existing Pd mechanism and convention for knowing what is instantiable is to use the file extension, which is a perfectly widespread method across many programs and operating systems ('.exe', '.so', etc. etc.). Sure, as yout pointed out earlier, you could put a .dll in a directory and instantiate it in Pd if you want, but nobody in their right mind does that because it's not the convention and causes more problems without fixing any.
Adding a lib prefix or moving .lua files into a subdirectory do not solve the fundemental problem which is that currently pd-lua thinks that all lua files are instantiable, when they are quite simply not. It makes no sense whatsoever to have Pd able to load a file type which it's not supposed to be able to load.
Sorry to add more noise,
Chris.
On Feb 13, 2008, at 8:47 PM, Chris McCormick wrote:
On Wed, Feb 13, 2008 at 02:29:31PM -0500, Hans-Christoph Steiner
wrote:"Currently pdlua loads all *.lua files, which complicates working with *.lua modules not intended to be used as pd classes: Those would have to be in a directory outside of Pd's search path to not pollute Pd's namespace. "
So how about using Pd's normal tools for handling name clashes and additionally, using a naming prefix like "lib" for the lua files that are not intended to be Pd objectclasses (as I described earlier)? Another possibility is using a subdir for these files.
The problem is Hans, that this is not a nameclash issue at all. The problem is that *all* .pd_linux and .pd files are meant to be read by Pd as instantiable objects. This is not true for all .lua files. It's obvious that the way around this is to make a new prefix which is
always treated by pd-lua like .pd and .pd_linux files are (as an instantiable object), and keep .lua files completely separate and ignored by
Pure Data.The existing Pd mechanism and convention for knowing what is
instantiable is to use the file extension, which is a perfectly widespread method across many programs and operating systems ('.exe', '.so', etc. etc.). Sure, as yout pointed out earlier, you could put a .dll in a directory and instantiate it in Pd if you want, but nobody in their right
mind does that because it's not the convention and causes more problems without fixing any.Adding a lib prefix or moving .lua files into a subdirectory do not solve the fundemental problem which is that currently pd-lua thinks
that all lua files are instantiable, when they are quite simply not. It
makes no sense whatsoever to have Pd able to load a file type which it's not supposed to be able to load.Sorry to add more noise,
The part of this whole equation that is the problem is the name
clash. That's how this thread started. Frank said that if he had a
support lib with the same name as another Pd objectclass, then there
was a name clash.
Loading a file that is not meant to be an objectclass is not really
problem, AFAIK, it just won't create an object. Oftentimes people
use this as a hack to load libraries.
Since the core of this problem is name clashes, then why not use the
existing techniques for dealing with that? I think this discussion
is getting too abstract... I just this there already are far too many
file extensions in Pd, I have had to do extra work because of them,
and have yet to see the benefit. That's my two bits...
.hc
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
Hans-Christoph Steiner wrote:
The part of this whole equation that is the problem is the name
clash. That's how this thread started. Frank said that if he had a
support lib with the same name as another Pd objectclass, then there
was a name clash.Loading a file that is not meant to be an objectclass is not really
problem, AFAIK, it just won't create an object. Oftentimes people
use this as a hack to load libraries.Since the core of this problem is name clashes, then why not use the
existing techniques for dealing with that? I think this discussion
is getting too abstract... I just this there already are far too many
file extensions in Pd, I have had to do extra work because of them,
and have yet to see the benefit. That's my two bits....hc
what I found out from reading franks emails is, that to run one lua script in pd, he sometimes also has lua scripts that are maybe included or referenced or needed to run that one script. and when he gives away a bundle which includes these scripts, then these additional scripts pollute the pd naming scheme. this is not so different to images that are shipped with a patch, you just don't expect that pd would try to open them. and according to franks mail, it obviously *is* a problem that externals don't open correctly anymore, but instead lua spits out an error that it can't load the object correctly (and does not try to look for another file with a *.pd extension instead). there are several suggested solutions right now:
- restrict the lua loader to certain directories only (different than
the pd searchpatchs)
- conventions for search order: first libs, then pd patches, then lua
files. but then you search the tree 3 times.
- change file extension so that pdlua will never try to open *.lua
scripts, just as pd does not try to load *.jpg files I think the pdlua programmer has to look at the pdlua specs anyway if she wants to write her own scripts, so the learning curve is not much steeper if the user has to learn "name the script in the following way so that it is accepted by pdlua. or you tell every user that in order to run a patch, she has to drag the lua files to a special lua-directory. marius.
Claude Heiland-Allen wrote:
Ah, true.
So my suggestion would be to use something like *.pd_lua, *.pdlua or *.l_lua as extension. What do you think? The same question may become an issue for other loaders as well, so a standard solution would be nice.
Ok, expect this change in the next release (sometime in March). I'm leaning towards *.pd_lua personally, to match *.pd_linux and *.pd_darwin, but if anyone has strong objections let me know.
i too think that "*.pd_lua" would be the best choice, even though *.pd_linux" seems to be deprecated in feavour of *.l_i386/*.l_ia64; since the lua-scripts are supposed to be platform&architecture independent the "l" and "${arch}" part so not make much sense, so i guess *.pd_lua is the best choice.
(the point of this email is mainly, that *.pd_linux,... is not necessarily the best template to build on, even though in this case it is)
fmgasd.r IOhannes
I am not sure if I agree with your (frank's) point. wouldn't it be easier keep your pd searchpaths clean of non-pd related lua scripts than to put a fancy file extension on every script? anyway, I think 3 letters of file extension should be enough, *.pdl is shorter. or add an obligatory description statement somewhere in the first lines of the script so that pdlua recognizes it as a pd loadable lua script. marius.
Frank Barknecht wrote:
Hi Claude and list,
I'm thinking if a custom file extension for pdlua classes would make sense? Currently pdlua loads all *.lua files, which complicates working with *.lua modules not intended to be used as pd classes: Those would have to be in a directory outside of Pd's search path to not pollute Pd's namespace.
So my suggestion would be to use something like *.pd_lua, *.pdlua or *.l_lua as extension. What do you think? The same question may become an issue for other loaders as well, so a standard solution would be nice.
Ciao
Hallo, marius schebella hat gesagt: // marius schebella wrote:
I am not sure if I agree with your (frank's) point. wouldn't it be easier keep your pd searchpaths clean of non-pd related lua scripts than to put a fancy file extension on every script?
Not really: As soon as you start distributing things, you'd have to bundle your helper modules anway and explain everyone to not put them in their Pd paths. This would be even worse for Pd-extended: Where should the non-pdlua Lua files go? How to add and manage Lua search paths? It's a can of worms.
anyway, I think 3 letters of file extension should be enough, *.pdl is shorter.
You need to use bittorrent more often. ;)
or add an obligatory description statement somewhere in the first lines of the script so that pdlua recognizes it as a pd loadable lua script.
See my other mail why I don't think this is a good solution. And actually it's already in effect: When a Lua file doesn't register itself with Pd, it's not loaded. But Pd still tries to do so, which is one thing I'm trying to avoid.
Ciao
Frank Barknecht _ ______footils.org__
I don't know how short file extension and bittorrent relate, because I really do not use bt often. but I think I got your point. btw, in max/msp when you add new files to the max-search path you have to restart max to make the changes effective. I think max caches the files somehow, and that probably makes the loading process of new objects faster. but I like the pd way more (although I think at some point (with thousands of folders to search this might slow down the system...) marius.
Frank Barknecht wrote:
Hallo, marius schebella hat gesagt: // marius schebella wrote:
I am not sure if I agree with your (frank's) point. wouldn't it be easier keep your pd searchpaths clean of non-pd related lua scripts than to put a fancy file extension on every script?
Not really: As soon as you start distributing things, you'd have to bundle your helper modules anway and explain everyone to not put them in their Pd paths. This would be even worse for Pd-extended: Where should the non-pdlua Lua files go? How to add and manage Lua search paths? It's a can of worms.
anyway, I think 3 letters of file extension should be enough, *.pdl is shorter.
You need to use bittorrent more often. ;)
or add an obligatory description statement somewhere in the first lines of the script so that pdlua recognizes it as a pd loadable lua script.
See my other mail why I don't think this is a good solution. And actually it's already in effect: When a Lua file doesn't register itself with Pd, it's not loaded. But Pd still tries to do so, which is one thing I'm trying to avoid.
Ciao
Hi,
On Sun, 2008-02-10 at 14:03 +0100, Frank Barknecht wrote:
I'm thinking if a custom file extension for pdlua classes would make sense? Currently pdlua loads all *.lua files, which complicates working with *.lua modules not intended to be used as pd classes: Those would have to be in a directory outside of Pd's search path to not pollute Pd's namespace.
So my suggestion would be to use something like *.pd_lua, *.pdlua or *.l_lua as extension. What do you think? The same question may become an issue for other loaders as well, so a standard solution would be nice.
How about *.pd.lua? This has the advantage keeping the standard .lua extension whilst providing a standardised suffix which indicates that this is a special Pd Lua script...
Just a thought.
Jamie
Hallo, Jamie Bullock hat gesagt: // Jamie Bullock wrote:
How about *.pd.lua? This has the advantage keeping the standard .lua extension whilst providing a standardised suffix which indicates that this is a special Pd Lua script...
This would be better than it currently is, but would still put a restriction on how external modules are named.
CIao
Frank Barknecht _ ______footils.org__
-
(())_n -
Chris McCormick -
Claude Heiland-Allen -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Jamie Bullock -
marius schebella