I am almost completely convinced of Guenter's argument that all externals should be individual files. I have two questions on that topic:
Are there any examples of a group of externals made up of individual files using a DLL for shared code? Would the DLL be a .pd_linux or a .so (or .pd_darwin / .dylib)?
Is there anyway to have aliases when using externals in separate files? (i.e. receive = r, prepend = pp, etc).
.hc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Le 7 Juin 2003 20:30, Hans-Christoph Steiner a écrit :
Would the DLL be a .pd_linux or a .so (or .pd_darwin / .dylib)?
I don't think a .pd_* can be used as a shared library.
Is there anyway to have aliases when using externals in separate files?
Probably not, because the class_addcreator method must be used within a setup function. But it would work if the externals are loaded at startup. - -- Marc
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Are there any examples of a group of externals made up of individual files using a DLL for shared code? Would the DLL be a .pd_linux or a .so (or .pd_darwin / .dylib)?
I think, what Guenther means are simply dynamically linked libraries. An example would my fluidsynth external, that links (statically or dynamiclly, just as you like) to fluidsynth.dll on W32, and libfluid.so on Linux.
ciao
On Sat, 7 Jun 2003, Hans-Christoph Steiner wrote:
I am almost completely convinced of Guenter's argument that all externals should be individual files. I have two questions on that topic:
Are there any examples of a group of externals made up of individual files using a DLL for shared code? Would the DLL be a .pd_linux or a .so (or .pd_darwin / .dylib)?
as frank said, with dll I meant dynamically linked library.
Is there anyway to have aliases when using externals in separate files? (i.e. receive = r, prepend = pp, etc).
yes,
link the file to an alias eg. ln -s prepend.pd_xxx pp.pd_xxx add a second setup function in prepend.c: void pp_setup() { prepend_setup(); }
then you are done. The danger of doing this is that if you copy pp.pd_xxx to some other place, be sure to move the prepend.pd_xxx too, otherwise you will get a dangling link.
Guenter
.hc
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The danger of doing this is that if you copy pp.pd_xxx to some other place, be sure to move the prepend.pd_xxx too, otherwise you will get a dangling link.
I'd rather make a new symbolic link than move the pd_* file. If the link is created with the absolute path of the pd_* file, then it can be moved or copied ("cp -d" for symbolic links).
- -- Marc
On Sunday, Jun 8, 2003, at 10:21 America/New_York, guenter geiger wrote:
On Sat, 7 Jun 2003, Hans-Christoph Steiner wrote:
Is there anyway to have aliases when using externals in separate files? (i.e. receive = r, prepend = pp, etc).
yes,
link the file to an alias eg. ln -s prepend.pd_xxx pp.pd_xxx add a second setup function in prepend.c: void pp_setup() { prepend_setup(); }
One last issue: Windows links/shortcuts. I tried a few experiments and I couldn't get it to work with Shortcuts. I know there is a way to do hard links in Windows NT/2k/XP but I don't remember how, and its basically never used. If Pd was running under Cygwin, then this would work since Cygwin supports Shortcuts as symlinks.
.hc
hi,
I used to play just the same trick in xeq-0.1 for linux.
However, the current xeq-0.2 is being loaded ``by stub''. Which means, all there is inside of e.g. xeq.parse.pd_linux, is just a call to (a kind of) sys_load_lib() for the main xeq.pd_linux (using -defsym linker option in order to mangle the generic 'setup' symbol into 'xeq.parse_setup' entry symbol). Still not perfect, perhaps, but I happen to prefer this to ln -s.
Krzysztof
guenter geiger wrote: ...
link the file to an alias eg. ln -s prepend.pd_xxx pp.pd_xxx add a second setup function in prepend.c: void pp_setup() { prepend_setup(); }
then you are done. The danger of doing this is that if you copy pp.pd_xxx to some other place, be sure to move the prepend.pd_xxx too, otherwise you will get a dangling link.
On Sunday, Jun 8, 2003, at 10:21 America/New_York, guenter geiger wrote:
On Sat, 7 Jun 2003, Hans-Christoph Steiner wrote:
Is there anyway to have aliases when using externals in separate files? (i.e. receive = r, prepend = pp, etc).
yes,
link the file to an alias eg. ln -s prepend.pd_xxx pp.pd_xxx add a second setup function in prepend.c: void pp_setup() { prepend_setup(); }
One last issue: Windows links/shortcuts. I tried a few experiments and I couldn't get it to work with Shortcuts. I know there is a way to do hard links in Windows NT/2k/XP but I don't remember how, and its basically never used. If Pd was running under Cygwin, then this would work since Cygwin supports Shortcuts as symlinks.
.hc
I am almost completely convinced of Guenter's argument that all externals should be individual files. I have two questions on that topic:
Are there any examples of a group of externals made up of individual files using a DLL for shared code? Would the DLL be a .pd_linux or a .so (or .pd_darwin / .dylib)?
There _will_ be some. I'm just testing flext to be a .dll or .dylib (or shortly .so), which looks very promising. All my externals can then optionally be built with shared flext. This has one major advantage: Attributes of any flext-based object in the system can be inspected from another one. Max-like inspectors are then possible.
By the way, as i'm a strong supporter of external libraries... what are the reasons why i would not want to use them?
best greetings, Thomas
By the way, as i'm a strong supporter of external libraries... what are the reasons why i would not want to use them?
- they are not automatically loaded, therefore if you want to use one external the whole library has to be loaded - you have to put a lib flag for every library you want to load - they are not as flexible for distribution - it is hard (if not impossible) to implement a system that allows for reloading. - they do not fit in the system for externals that we designed for the CVS. (which is based on single externals, actually I do not see any other way the idea could be implemented)
Add the advantages of single externals (we have been talking about here on the list) and you have some arguments why single externals are a better decision.
What are the arguments against single externals ?
Guenter
Hi Guenter,
By the way, as i'm a strong supporter of external libraries... what are
the
reasons why i would not want to use them?
- they are not automatically loaded, therefore if you want to use one external the whole library has to be loaded
- you have to put a lib flag for every library you want to load
Clearly there has to be a better solution than that. I'm really not satisfied with the current PD configuration functionality.
- they are not as flexible for distribution
why? I think they are easier on the contrary
- it is hard (if not impossible) to implement a system that allows for
reloading.
Why is it harder to reload a library than a single external? (to my mind for this there has to be some cooperation by the external anyhow)
- they do not fit in the system for externals that we designed for the CVS. (which is based on single externals, actually I do not see any other way the idea could be implemented)
Does flext and the derived externals fit into that system at all?
What are the arguments against single externals ?
I have no argument against single externals as i use them myself, but i'm pro using libraries if feasible. It's possibly only important for me so that may not be enough of an argument, but for all externals depending on a base class (via c++ inheritance) which is an important flext feature the usage of separate external binaries is hardly possible as it necessitates the usage of a shared library file with the base classes, which is even more difficult to handle. For all externals depending on shared code or data: why would the usage of an extra shared library be easier than the usage of a single external library file?
best greetings, Thomas
On Mon, 9 Jun 2003, Thomas Grill wrote:
- they are not as flexible for distribution
why? I think they are easier on the contrary
Ok, I have a patch that uses xx from xxlib, yx from xylib and zz from zzlib. In order to distribute this patch to my friends and not let them go through recompilation nightmares I have to include the whole libraries for win/lin/osx, whereas with single externals I just have to include the respective pd_linux files. (Additionally I do not even need to bother about externals and library conflicts that might occur on the others system, because the externals I have put there will be automtically loaded.)
Ok you say we could improve the configuration system, but why ?
- it is hard (if not impossible) to implement a system that allows for
reloading.
Why is it harder to reload a library than a single external? (to my mind for this there has to be some cooperation by the external anyhow)
Because for a library you have to search for all externals that are implemented and reload them, and you do not even know who they are.
- they do not fit in the system for externals that we designed for the CVS. (which is based on single externals, actually I do not see any other way the idea could be implemented)
Does flext and the derived externals fit into that system at all?
What are the arguments against single externals ?
I have no argument against single externals as i use them myself, but i'm pro using libraries if feasible. It's possibly only important for me so that may not be enough of an argument, but for all externals depending on a base class (via c++ inheritance) which is an important flext feature the usage of separate external binaries is hardly possible as it necessitates the usage of a shared library file with the base classes, which is even more difficult to handle.
So C++ libraries are hardly possible and if so very difficult to handle ?
For all externals depending on shared code or data: why would the usage of an extra shared library be easier than the usage of a single external library file?
Well, there would be some advantages to that approach at least. For example you can fix things in the library without requesting all flext external developers to recompile.
Anyhow, sometimes the shared code size is that small that it doesn't pay off to make a dll. I have the dream that the pd devlopers would in this case work on a common library of support functions that are probably missing fro pd, and which , based on this work can probably be moved into pd itself.
As a last word on this topic, I think single externals make it easier for the pd developers to work together. This is one of the main goals for the CVS too.
Greetings,
Guenter
best greetings, Thomas
On Mon, 9 Jun 2003, guenter geiger wrote:
Add the advantages of single externals (we have been talking about here on the list) and you have some arguments why single externals are a better decision. What are the arguments against single externals ?
tiresome when creating a family of very related externals
makes it more difficult to share code between related externals
may take more RAM
may take more filehandles
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, 9 Jun 2003, guenter geiger wrote:
What are the arguments against single externals ?
Mathieu Bouchard replied :
tiresome when creating a family of very related externals makes it more difficult to share code between related externals may take more RAM may take more filehandles
Building all externals as single files is not that important. What's important is to have and use the externals. I was able build most of the CVS externals, which is more than what is in the build/src directory. There should be maintainers for each platform (Mac,Windows,Linuxes), that would share information on difficult to build externals. This effort would help the community more than trying to fit all submitted externals into an ideal framework. - -- Marc
On Mon, 9 Jun 2003, Marc [iso-8859-1] Lavall�e wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, 9 Jun 2003, guenter geiger wrote:
What are the arguments against single externals ?
Mathieu Bouchard replied :
tiresome when creating a family of very related externals makes it more difficult to share code between related externals may take more RAM may take more filehandles
Building all externals as single files is not that important. What's important is to have and use the externals. I was able build most of the CVS externals, which is more than what is in the build/src directory.
Thats great, can this work be included in CVS ?
There should be maintainers for each platform (Mac,Windows,Linuxes), that would share information on difficult to build externals. This effort would help the community more than trying to fit all submitted externals into an ideal framework.
You are right. I volunter for linux, I will put the pd-externals package into Debian as soon as we are done with the work.
Can those people that want to have a lib instead of single externals tell me so ? Not that I am convinced by the arguments, but we have to go ahead :)
Guenter
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Le 10 Juin 2003 09:16, guenter geiger a écrit :
Thats great, can this work be included in CVS ?
It's in the form of a big rpm spec file. It doesn't build the single externals, only the original sources. It builds a single rpm package for (mostly) all of the CVS submissions, but I it should be redesigned to build specific packages. It'll take a couple of days to fix it, then I'll include it in the CVS.
You are right. I volunter for linux, I will put the pd-externals package into Debian as soon as we are done with the work.
I'd volunter for Mandrake, and my spec file should also work on RedHat.
- -- Marc
On Mon, 9 Jun 2003, Marc Lavallée wrote:
On Mon, 9 Jun 2003, guenter geiger wrote:
What are the arguments against single externals ?
Mathieu Bouchard replied :
tiresome when creating a family of very related externals makes it more difficult to share code between related externals may take more RAM may take more filehandles
Building all externals as single files is not that important. What's important is to have and use the externals. I was able build most of the CVS externals, which is more than what is in the build/src directory. There should be maintainers for each platform (Mac,Windows,Linuxes), that would share information on difficult to build externals. This effort would help the community more than trying to fit all submitted externals into an ideal framework.
agreed 100%.
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
On Mon, 9 Jun 2003, Mathieu Bouchard wrote:
On Mon, 9 Jun 2003, guenter geiger wrote:
Add the advantages of single externals (we have been talking about here on the list) and you have some arguments why single externals are a better decision. What are the arguments against single externals ?
tiresome when creating a family of very related externals
makes it more difficult to share code between related externals
may take more RAM
may take more filehandles
I understand that your point of view is gridflow centric, which is a completely different thing, because it introduces a new system on top of pd. Thats not what I would call pd externals in the standard sense. For the externals I am talking about the arguments don't hold.
Guenter
On Tue, 10 Jun 2003, guenter geiger wrote:
On Mon, 9 Jun 2003, Mathieu Bouchard wrote:
tiresome when creating a family of very related externals makes it more difficult to share code between related externals may take more RAM may take more filehandles
I understand that your point of view is gridflow centric, which is a completely different thing, because it introduces a new system on top of pd. Thats not what I would call pd externals in the standard sense. For the externals I am talking about the arguments don't hold.
Okay, my point of view is extremely gridflow centric, but the things I have listed also would hold for GEM, PDP, and so on, so generally it is also library-of-externals centric... those libraries introduce new subsystems on top of PD as well.
Therefore, arguments against small independent externals, when they come from a background in big systems of interrelated externals, are irrelevant, as your actual question was whether small independent externals are a good way of doing things from the perspective of small independent externals.
I would expect the paradigm of small independent externals to remain unchallenged, as long as all inappropriate answers are properly dismissed.
Have a nice day.
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
hi Thomas,
are you going to depend on having it installed in usr/lib, or do you know of another solution (via env. vars?), which would not be the cause of setup nightmares?
Krzysztof
Thomas Grill wrote: ...
There _will_ be some. I'm just testing flext to be a .dll or .dylib (or shortly .so), which looks very promising.
Hi Krzysztof,
are you going to depend on having it installed in usr/lib, or do you know of another solution (via env. vars?), which would not be the cause of setup nightmares?
for testing i installed it into /usr/local/lib, which seems to be a common place. As i'm not very intimate with the linux conventions i'm open for any better solutions (maybe to put the path into ld.so.conf).
best greetings, Thomas
-
Frank Barknecht -
guenter geiger -
Hans-Christoph Steiner -
Krzysztof Czaja -
Marc Lavallée -
Mathieu Bouchard -
Thomas Grill