[PD-dev] packaging loaders for Debian

IOhannes m zmoelnig zmoelnig at iem.at
Wed Sep 8 09:32:05 CEST 2010


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20100908/8c9b19a6/attachment.bin>


More information about the Pd-dev mailing list