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
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
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
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.
fgmasd.r
IOhannes
Hallo,
Frank Barknecht hat gesagt: // Frank Barknecht wrote:
Similar things are possible with luax, ...
Correction 2: luax is a loader as well, I confused it with lua~ here.
Ciao
--
Frank Barknecht _ __footils.org__
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
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
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
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
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
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
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
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
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?
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
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
Hallo,
Frank Barknecht hat gesagt: // Frank Barknecht wrote:
problem, as you specify the filename in the object name. If you don't
Correction: I meant to write specify the filename in the object
box. As an argument, that is.
Ciao
--
Frank Barknecht _
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
(())_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
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
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
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
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
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
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
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
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
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
28 matches
Mail list logo
