I think it would be very useful to package up some of the handy loaders for Debian. I for one am planning on making a package for the libdir loader. The big question is how to package them. Should they be packaged up like a normal library? It would be nice if there was some kind of mechanism for having Pd automatically load the installed loaders if they are in a given folder. Something like /etc/apache/ sites-enabled.
.hc
----------------------------------------------------------------------------
"Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you." - Richard M. Stallman
On 2010-09-05 05:47, Hans-Christoph Steiner wrote:
I think it would be very useful to package up some of the handy loaders for Debian. I for one am planning on making a package for the libdir loader. The big question is how to package them. Should they be packaged up like a normal library? It would be nice if there was some kind of mechanism for having Pd automatically load the installed loaders if they are in a given folder. Something like /etc/apache/sites-enabled.
i think the puredata package in debian should follow the pd-vanilla package as closely as possible [*]. adding functionality for an autoloaded directory is definitely something that is beyond that (imho).
so i'd say: get the autoload-directory stuff into upstream.
in the meantime, loaders should be loaded like any other libraries (which they are).
if autoload-directory makes it into upstream, we can start talking about putting loaders into that. personally i think it's a bad idea (and i would probably not want to use that package myself then)
please remember that no package installs anything directly into /etc/apache/sites-enabled, it's the user who puts their configuration into it.
fgmasdr IOhannes
[*] if you package pd-extended for debian, then you are of course free to apply whatever patches you want to...
On Sep 6, 2010, at 3:11 AM, IOhannes m zmoelnig wrote:
On 2010-09-05 05:47, Hans-Christoph Steiner wrote:
I think it would be very useful to package up some of the handy loaders for Debian. I for one am planning on making a package for the libdir loader. The big question is how to package them. Should they be packaged up like a normal library? It would be nice if there was some kind of mechanism for having Pd automatically load the installed loaders if they are in a given folder. Something like /etc/apache/sites- enabled.
i think the puredata package in debian should follow the pd-vanilla package as closely as possible [*]. adding functionality for an autoloaded directory is definitely something that is beyond that (imho).
so i'd say: get the autoload-directory stuff into upstream.
in the meantime, loaders should be loaded like any other libraries (which they are).
if autoload-directory makes it into upstream, we can start talking about putting loaders into that. personally i think it's a bad idea (and i would probably not want to use that package myself then)
please remember that no package installs anything directly into /etc/apache/sites-enabled, it's the user who puts their configuration into it.
Why do you think having the ability to autoload loaders is a bad idea? I can't see a disadvantage, but I am not saying there couldn't be one. I would like to see it be possible to write Pd objects in a bunch of different langauges, then transparently use them as if they were any Pd object. Here's how I see it:
- there is a library of nice GUI objects using tclpd - that gets packaged up Pd-extended, Debian, pure:dyne, etc. - someone else goes looking for GUI objects and finds the niceGUIobjects lib - they [import niceGUIobjects] and try making objects - they get lots of errors in the Pd window and no GUI objects
Seems to me that for users, tclpd should already be loaded.
.hc
----------------------------------------------------------------------------
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
On 2010-09-06 17:41, Hans-Christoph Steiner wrote:
Why do you think having the ability to autoload loaders is a bad idea? I can't see a disadvantage, but I am not saying there couldn't be one.
i can't think of one, but that doesn't mean that there is none.
my main point was, that in pd-vanilla there is currently no autoloader functionality, so i don't see a reason to add it to debian packages.
I would like to see it be possible to write Pd objects in a bunch of different langauges, then transparently use them as if they were any Pd object. Here's how I see it:
- there is a library of nice GUI objects using tclpd
- that gets packaged up Pd-extended, Debian, pure:dyne, etc.
- someone else goes looking for GUI objects and finds the niceGUIobjects
lib
- they [import niceGUIobjects] and try making objects
- they get lots of errors in the Pd window and no GUI objects
Seems to me that for users, tclpd should already be loaded.
aye.
i fully understand what you are saying, but i still would prefer if addons would not enable themselves without user choice. (e.g. apache-modules get installed into /etc/apache2/mods-available/ and the admin selectively can put them into /etc/apache2/mods-enabled/)
so even if there was autoloading, it would be nice of the package to ask on installation (via debconf) whether these packages should be enabled (put into the autoloading directory).
but this could be done even without autoloading a directory, but just adding a system-wide pdrc which is read at startup (a long standing feature-requirest in the tracker)
fmgasdr IOhannes
On 2010-09-06 17:41, Hans-Christoph Steiner wrote:
Why do you think having the ability to autoload loaders is a bad idea? I can't see a disadvantage, but I am not saying there couldn't be one. I would like to see it be possible to write Pd objects in a bunch of different langauges, then transparently use them as if they were any Pd object. Here's how I see it:
- there is a library of nice GUI objects using tclpd
- that gets packaged up Pd-extended, Debian, pure:dyne, etc.
- someone else goes looking for GUI objects and finds the niceGUIobjects
lib
- they [import niceGUIobjects] and try making objects
- they get lots of errors in the Pd window and no GUI objects
Seems to me that for users, tclpd should already be loaded.
actually i think that it is [import]'s job to make sure that all the dependencies are fullfilled in order to actually use that library.
so i believe that niceGUIobjects-meta.pd should have a "require tclpd" equivalent (which of course has the scope of the patch containing the [import] object)
having inter library dependencies, is not only a problem with loaders (though loaders illustrate it nicely). e.g. if i do [import GridFlow] without having Gem loaded, this will eventually fail, because GF uses Gem's symbols but the dlinker has no way of finding out that it is Gem.pd_linux that provides these symbols.
fmgasdr IOhannes
On Sep 8, 2010, at 3:32 AM, IOhannes m zmoelnig wrote:
On 2010-09-06 17:41, Hans-Christoph Steiner wrote:
Why do you think having the ability to autoload loaders is a bad idea? I can't see a disadvantage, but I am not saying there couldn't be one. I would like to see it be possible to write Pd objects in a bunch of different langauges, then transparently use them as if they were any Pd object. Here's how I see it:
- there is a library of nice GUI objects using tclpd
- that gets packaged up Pd-extended, Debian, pure:dyne, etc.
- someone else goes looking for GUI objects and finds the
niceGUIobjects lib
- they [import niceGUIobjects] and try making objects
- they get lots of errors in the Pd window and no GUI objects
Seems to me that for users, tclpd should already be loaded.
actually i think that it is [import]'s job to make sure that all the dependencies are fullfilled in order to actually use that library.
so i believe that niceGUIobjects-meta.pd should have a "require tclpd" equivalent (which of course has the scope of the patch containing the [import] object)
having inter library dependencies, is not only a problem with loaders (though loaders illustrate it nicely). e.g. if i do [import GridFlow] without having Gem loaded, this will eventually fail, because GF uses Gem's symbols but the dlinker has no way of finding out that it is Gem.pd_linux that provides these symbols.
fmgasdr IOhannes
I agree that it should work something like this, but I think its going to take us a while to get there. You can ask Claudius about the complexity of this stuff, since he's been working on the local namespace stuff.
First off, I don't think the dependency should be in the library, but in the object. With objects that need a loader, you have a catch-22: the object needs a loader in order to be loaded, and the object needs to be loaded so that [import loader] runs. So loaders aren't really the same as libraries.
.hc
----------------------------------------------------------------------------
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
-
Hans-Christoph Steiner -
IOhannes m zmoelnig