the (future SVN) repository a bit differently: A "default member" would just get write access to one (SVN) directory. Then e.g. Luke could put his abstractions and the mmonoplayer and whatever comes up there, pd-extended could still collect it. I guess this would be sufficient for a large number of developers. (Many people recently added as members, like Eric Lyon etc., "just" put their externals and abstractions there and all is fine.)
I agree strongly with this. As an externals developer, I have no need or desire to have access to the Pd core code except as a spectator. One benefit of two-tiered access (1 for people working on core code, 2 for people like me) is that there would not need to be major discussion about adding externals developers, since you would not need to worry about them wandering into the Pd code and accidentally turning into Microsoft Word :)
Cheers,
Eric
On Feb 17, 2007, at 5:32 PM, Eric Lyon wrote:
the (future SVN) repository a bit differently: A "default member" would just get write access to one (SVN) directory. Then e.g. Luke could put his abstractions and the mmonoplayer and whatever comes up there, pd-extended could still collect it. I guess this would be sufficient for a large number of developers. (Many people recently added as members, like Eric Lyon etc., "just" put their externals and abstractions there and all is fine.)
I agree strongly with this. As an externals developer, I have no need or desire to have access to the Pd core code except as a spectator. One benefit of two-tiered access (1 for people working on core code, 2 for people like me) is that there would not need to be major discussion about adding externals developers, since you would not need to worry about them wandering into the Pd code and accidentally turning into Microsoft Word :)
I think the ideal structure would be a smaller and carefully tailored distro (unlike Pd-extended). Then have a standard package format, and a way of managing many different packages, like Perl's CPAN, Eclipse plugins, or Debian package management.
Then each dev can manage their libs in their own repository, be in CVS, SVN, darcs, git, etc. etc. They would just need to make releases in the standard package format, and perhaps upload them to a central repository. That is why I have been working on the "libdir" format.
.hc
Cheers,
Eric
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------
All information should be free. - the hacker ethic
Another question that comes to mind is the name space issue. I have an external in LyonPotpourri called adsr~. So does MaxMSP. But there's no clash because all of my externals in MaxMSP are compiled with a prefix, in this case el.adsr~. If many different packages are to be coordinated, it would be nice to have a similar convention to address this issue in Pd. (Hopefully not an ugly one like making me change all my files to el_adsr~.c and so forth.)
Cheers,
Eric
On 2/21/07, Hans-Christoph Steiner hans@eds.org wrote:
I think the ideal structure would be a smaller and carefully tailored distro (unlike Pd-extended). Then have a standard package format, and a way of managing many different packages, like Perl's CPAN, Eclipse plugins, or Debian package management.
Then each dev can manage their libs in their own repository, be in CVS, SVN, darcs, git, etc. etc. They would just need to make releases in the standard package format, and perhaps upload them to a central repository. That is why I have been working on the "libdir" format.
.hc
Cheers,
Eric
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
All information should be free. - the hacker ethic
Hallo, Eric Lyon hat gesagt: // Eric Lyon wrote:
Another question that comes to mind is the name space issue. I have an external in LyonPotpourri called adsr~. So does MaxMSP. But there's no clash because all of my externals in MaxMSP are compiled with a prefix, in this case el.adsr~. If many different packages are to be coordinated, it would be nice to have a similar convention to address this issue in Pd. (Hopefully not an ugly one like making me change all my files to el_adsr~.c and so forth.)
If your externals as single files are installed into a directory "el" and if not this directory, but the its parent is in Pd's search path then the object can be used as [el/adsr~] etc. This solution is standard on Pd-extended, where every collection of abstractions or externals is installed as a subdirectory of "extra". "extra" automatically is part of the search path.
Although AFAIK there still are some problems with externals: Once [el/adsr~] is loaded, you can also create [adsr~] without directory prefix and it will load your external. But maybe this has been fixed in the meantime.
If you want to read some more about this in the archives: This kind of directory prefix sometimes also is called "Geiger namespace" because it was first suggested by Guenther Geiger.
Ciao
On Feb 21, 2007, at 4:54 PM, Frank Barknecht wrote:
Hallo, Eric Lyon hat gesagt: // Eric Lyon wrote:
Another question that comes to mind is the name space issue. I have an external in LyonPotpourri called adsr~. So does MaxMSP. But there's no clash because all of my externals in MaxMSP are compiled with a prefix, in this case el.adsr~. If many different packages are to be coordinated, it would be nice to have a similar convention to address this issue in Pd. (Hopefully not an ugly one like making me change all my files to el_adsr~.c and so forth.)
If your externals as single files are installed into a directory "el" and if not this directory, but the its parent is in Pd's search path then the object can be used as [el/adsr~] etc. This solution is standard on Pd-extended, where every collection of abstractions or externals is installed as a subdirectory of "extra". "extra" automatically is part of the search path.
Although AFAIK there still are some problems with externals: Once [el/adsr~] is loaded, you can also create [adsr~] without directory prefix and it will load your external. But maybe this has been fixed in the meantime.
If you want to read some more about this in the archives: This kind of directory prefix sometimes also is called "Geiger namespace" because it was first suggested by Guenther Geiger.
Also, this is bit is slowly being developed into a full-fledged namespace, like Java.
.hc
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------
Access to computers should be unlimited and total. - the hacker ethic
-
Eric Lyon -
Frank Barknecht -
Hans-Christoph Steiner