Hey,
So what should be the core mission of the pure-data repository? It looks like it is time to have that discussion again. I see it as a gathering of code and docs that are intended to be built using a common build system (aka Pd-extended build system).
As for Pd-extended, I think it is a mistake (almost all my fault) including so many things in the package. It is now clear to me that makes more sense to have a distro that includes only the very stable libraries, then to make Pd fully support external libdirs, including shared libs, help patches, example patches, manuals, etc.
I think then there could be a simple distro system like Eclipse has for managing plugins. (Basically, there is a simple format for posting a library to a website. The user then adds the repo URL to the program, which then has a browser for all available installation options and updates).
I guess this was a bit vague and wandering, but it seems that there is a discussion that needs to be had.
.hc
------------------------------------------------------------------------ ----
Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom
Hans-Christoph Steiner wrote:
Hey,
So what should be the core mission of the pure-data repository? It looks like it is time to have that discussion again. I see it as a gathering of code and docs that are intended to be built using a common build system (aka Pd-extended build system).
As for Pd-extended, I think it is a mistake (almost all my fault) including so many things in the package. It is now clear to me that makes more sense to have a distro that includes only the very stable libraries, then to make Pd fully support external libdirs, including shared libs, help patches, example patches, manuals, etc.
I very very much like that idea! I think there should be a pd-distro where externals are only added if they are available on win, macos and linux and if they have manuals/helppatches support. and the whole distro comes with a toc and tutorials... count me in for that! marius.
I think then there could be a simple distro system like Eclipse has for managing plugins. (Basically, there is a simple format for posting a library to a website. The user then adds the repo URL to the program, which then has a browser for all available installation options and updates).
I guess this was a bit vague and wandering, but it seems that there is a discussion that needs to be had.
.hc
Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I think then there could be a simple distro system like Eclipse has for managing plugins. (Basically, there is a simple format for posting a library to a website. The user then adds the repo URL to the program, which then has a browser for all available installation options and updates).
Recently another metaphor came to my mind - and of course it has to be taken with a grain of salt like all metaphors: Mozilla vs. Firefox/Thunderbird/Sundbird, ...
pd-extended to me very much feels like Mozilla in that it tries to provide as much "apps" as possible crammed into a single-click installable suite. Compare that to Firefox, which is only a very basic browser with functionality stripped down so much, that the first thing everyone does is install some extenstions. Nevertheless Firefox took off in a big way and Mozilla is more or less dead.
I think, this had two reasons. First reason: People who liked the browser in Mozilla didn't care about the mail component at that time. They used Mutt, Outlook, or whatever. (Funnily now that it's a separate app, Thunderbird became popular as well.) The second reason is the extensions and theme system of Firefox which made it very easy to install only the updates, that a user is interested in, without all the bloat of Mozilla.
I don't know if something can be learned from that history, though.
Ciao
On Jun 21, 2008, at 1:26 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I think then there could be a simple distro system like Eclipse has for managing plugins. (Basically, there is a simple format for posting a library to a website. The user then adds the repo URL to the program, which then has a browser for all available installation options and updates).
Recently another metaphor came to my mind - and of course it has to be taken with a grain of salt like all metaphors: Mozilla vs. Firefox/Thunderbird/Sundbird, ...
pd-extended to me very much feels like Mozilla in that it tries to provide as much "apps" as possible crammed into a single-click installable suite. Compare that to Firefox, which is only a very basic browser with functionality stripped down so much, that the first thing everyone does is install some extenstions. Nevertheless Firefox took off in a big way and Mozilla is more or less dead.
I think, this had two reasons. First reason: People who liked the browser in Mozilla didn't care about the mail component at that time. They used Mutt, Outlook, or whatever. (Funnily now that it's a separate app, Thunderbird became popular as well.) The second reason is the extensions and theme system of Firefox which made it very easy to install only the updates, that a user is interested in, without all the bloat of Mozilla.
I don't know if something can be learned from that history, though.
I think it is a good example. Mozilla needed to happen in order to make Firefox, Thunderbird, etc. happen. But it then worked better to split them up. I think Pd-extended is a similar kind of thing. Gathering all known code at the time into one place need to happen to get the community to the next step. Now we are outgrowing that model, so I think it is time to split things up so that externals are as well supported as internals.
Then there is much less need for a 'gatekeeper', who has control over what is included (e.g. like Miller for vanilla, or me, mostly, for Pd- extended). If we make it easy to find, download, and manage externals, then we don't need a big central package. Something like CPAN is a great example, or the Eclipse plugins.
.hc
Ciao
Frank Barknecht _ ______footils.org__
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
Hans-Christoph Steiner wrote:
On Jun 21, 2008, at 1:26 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I think then there could be a simple distro system like Eclipse has for managing plugins. (Basically, there is a simple format for posting a library to a website. The user then adds the repo URL to the program, which then has a browser for all available installation options and updates).
Recently another metaphor came to my mind - and of course it has to be taken with a grain of salt like all metaphors: Mozilla vs. Firefox/Thunderbird/Sundbird, ...
pd-extended to me very much feels like Mozilla in that it tries to provide as much "apps" as possible crammed into a single-click installable suite. Compare that to Firefox, which is only a very basic browser with functionality stripped down so much, that the first thing everyone does is install some extenstions. Nevertheless Firefox took off in a big way and Mozilla is more or less dead.
I think, this had two reasons. First reason: People who liked the browser in Mozilla didn't care about the mail component at that time. They used Mutt, Outlook, or whatever. (Funnily now that it's a separate app, Thunderbird became popular as well.) The second reason is the extensions and theme system of Firefox which made it very easy to install only the updates, that a user is interested in, without all the bloat of Mozilla.
I don't know if something can be learned from that history, though.
I think it is a good example. Mozilla needed to happen in order to make Firefox, Thunderbird, etc. happen. But it then worked better to split them up. I think Pd-extended is a similar kind of thing. Gathering all known code at the time into one place need to happen to get the community to the next step. Now we are outgrowing that model, so I think it is time to split things up so that externals are as well supported as internals.
Then there is much less need for a 'gatekeeper', who has control over what is included (e.g. like Miller for vanilla, or me, mostly, for Pd- extended). If we make it easy to find, download, and manage externals, then we don't need a big central package. Something like CPAN is a great example, or the Eclipse plugins.
is this a proposal for a "package system"?
well, it would be a step forward just if only all extern will work ./configure && make && make install out-of-the box.
what I see lacking in the external repository is some kind of standard. most externals build with just a makefile, some others use automake, autoconf, others use the flext build system.
another problem is the install location: since the addition of namespaces/declare/import, things are changed. also, the standards are very low (I again advice to read the GNU coding standards book)
also, the install location of docs, it is a flat (bloated) directory (?)
also, externals/packages, lack versioning (I think). do we have the possibility to put metadata?
I'm not proposing a valuable solution, just spotting one problem.
I hardly see a user-friendly, plug-n-play system for extensions right now; tidying up things is required.
What if every external installs into his own prefix in ${ROOT}/usr/lib/pd ? example: /usr/lib/pd/zexy/lib/a2l.pd_linux /usr/lib/pd/zexy/lib/abs~.pd_linux ... /usr/lib/pd/zexy/doc/help-a2l.pd /usr/lib/pd/zexy/doc/help-abs~.pd ... /usr/lib/pd/zexy/package.xml ?metadata?
at this point the /pd/ is superfluous. the Tcl package system works by putting directories directly into /usr/lib, example:
/usr/lib/tktray1.1/ /usr/lib/tktray1.1/pkgIndex.tcl /usr/lib/tktray1.1/libtktray1.1.so
not bad, IMHO.
my 0.02€
On Jun 21, 2008, at 7:44 PM, mescalinum@gmail.com wrote:
Hans-Christoph Steiner wrote:
On Jun 21, 2008, at 1:26 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I think then there could be a simple distro system like Eclipse has for managing plugins. (Basically, there is a simple format for posting a library to a website. The user then adds the repo URL to the program, which then has a browser for all available installation options and updates).
Recently another metaphor came to my mind - and of course it has to be taken with a grain of salt like all metaphors: Mozilla vs. Firefox/Thunderbird/Sundbird, ...
pd-extended to me very much feels like Mozilla in that it tries to provide as much "apps" as possible crammed into a single-click installable suite. Compare that to Firefox, which is only a very basic browser with functionality stripped down so much, that the first thing everyone does is install some extenstions. Nevertheless Firefox took off in a big way and Mozilla is more or less dead.
I think, this had two reasons. First reason: People who liked the browser in Mozilla didn't care about the mail component at that time. They used Mutt, Outlook, or whatever. (Funnily now that it's a separate app, Thunderbird became popular as well.) The second reason is the extensions and theme system of Firefox which made it very easy to install only the updates, that a user is interested in, without all the bloat of Mozilla.
I don't know if something can be learned from that history, though.
I think it is a good example. Mozilla needed to happen in order to make Firefox, Thunderbird, etc. happen. But it then worked better to split them up. I think Pd-extended is a similar kind of thing. Gathering all known code at the time into one place need to happen to get the community to the next step. Now we are outgrowing that model, so I think it is time to split things up so that externals are as well supported as internals.
Then there is much less need for a 'gatekeeper', who has control over what is included (e.g. like Miller for vanilla, or me, mostly, for Pd- extended). If we make it easy to find, download, and manage externals, then we don't need a big central package. Something like CPAN is a great example, or the Eclipse plugins.
is this a proposal for a "package system"?
well, it would be a step forward just if only all extern will work ./configure && make && make install out-of-the box.
what I see lacking in the external repository is some kind of standard. most externals build with just a makefile, some others use automake, autoconf, others use the flext build system.
another problem is the install location: since the addition of namespaces/declare/import, things are changed. also, the standards are very low (I again advice to read the GNU coding standards book)
also, the install location of docs, it is a flat (bloated) directory (?)
also, externals/packages, lack versioning (I think). do we have the possibility to put metadata?
I'm not proposing a valuable solution, just spotting one problem.
I hardly see a user-friendly, plug-n-play system for extensions right now; tidying up things is required.
What if every external installs into his own prefix in ${ROOT}/usr/ lib/pd ? example: /usr/lib/pd/zexy/lib/a2l.pd_linux /usr/lib/pd/zexy/lib/abs~.pd_linux ... /usr/lib/pd/zexy/doc/help-a2l.pd /usr/lib/pd/zexy/doc/help-abs~.pd ... /usr/lib/pd/zexy/package.xml ?metadata?
at this point the /pd/ is superfluous. the Tcl package system works by putting directories directly into / usr/lib, example:
/usr/lib/tktray1.1/ /usr/lib/tktray1.1/pkgIndex.tcl /usr/lib/tktray1.1/libtktray1.1.so
not bad, IMHO.
my 0.02€
Federico Ferri
The idea is to use a common library (or 'package') format that includes binaries, abstractions, help files, examples, manuals, etc. in one folder. This is the basic idea of 'libdirs'. http:// puredata.info/docs/developer/Libdir
How people build them depends on their project.
.hc
------------------------------------------------------------------------ ----
kill your television
Hans-Christoph Steiner wrote:
Hey,
So what should be the core mission of the pure-data repository? It looks like it is time to have that discussion again. I see it as a gathering of code and docs that are intended to be built using a common build system (aka Pd-extended build system).
for me, the sourceforge project is still the place where the main development is meant to happen, rather than focusing on a common build system.
unfortunately the two ideas often do not go together so well, esp. when some new developments break the main build process - because they are, well, under development.
in my opinion, the versioning system was introduced to do code development rather than just accumulate all available libraries. for the latter, a simple ftp server would have been sufficient. also, it would have been a good idea to not have so many contributors added to the project, as each of them could potentially do development;-)
if these two sides cannot live together happily, i think it would be better to split the project into 2 seaparate ones: a project for development of the package, and a project (or several thereof) for the actual development of externals,...
a probably good example is the "pd-overlay" sf-project, that aims at creating a distribution package of various pd versions (pd, pdx, netpd) without actually touching the development side of these things. instead it is solely concentrating on creating the package.
fmasr.t IOhannes
On Fri, 20 Jun 2008, Hans-Christoph Steiner wrote:
So what should be the core mission of the pure-data repository? It looks like it is time to have that discussion again. I see it as a gathering of code and docs that are intended to be built using a common build system (aka Pd-extended build system).
The core mission of the repository is to be a repository, so that people can repose their code in it. All of the rest is bonus. Whether there are one or two or forty-twelve different build systems in the repository is not the question at all.
The core mission of the repository is what people do with it. If you want something to be part of the core mission, just do your stuff, but you're already doing that.
As for Pd-extended, I think it is a mistake (almost all my fault) including so many things in the package. It is now clear to me that makes more sense to have a distro that includes only the very stable libraries,
Then handle this at the level of your checkouts and/or branches. You don't need to meddle with mission-statements for that.
I guess this was a bit vague and wandering, but it seems that there is a discussion that needs to be had.
This is several discussions. It's a not a bit vague, it's a lot vague. The association of the repository's mission-statement with distro issues makes one wonder about how you think about it all. Do you want the trunk of the repo to be consisting of only the libraries that you like?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Jul 8, 2008, at 12:18 AM, Mathieu Bouchard wrote:
On Fri, 20 Jun 2008, Hans-Christoph Steiner wrote:
So what should be the core mission of the pure-data repository? It looks like it is time to have that discussion again. I see it as a gathering of code and docs that are intended to be built using a common build system (aka Pd-extended build system).
The core mission of the repository is to be a repository, so that people can repose their code in it. All of the rest is bonus. Whether there are one or two or forty-twelve different build systems in the repository is not the question at all.
The core mission of the repository is what people do with it. If you want something to be part of the core mission, just do your stuff, but you're already doing that.
This is an important question. If we organize things well, beyond just storing code, then it'll save us all work. So that's why we need to determine the "what people do with it".
As for Pd-extended, I think it is a mistake (almost all my fault) including so many things in the package. It is now clear to me that makes more sense to have a distro that includes only the very stable libraries,
Then handle this at the level of your checkouts and/or branches. You don't need to meddle with mission-statements for that.
I guess this was a bit vague and wandering, but it seems that there is a discussion that needs to be had.
This is several discussions. It's a not a bit vague, it's a lot vague. The association of the repository's mission-statement with distro issues makes one wonder about how you think about it all. Do you want the trunk of the repo to be consisting of only the libraries that you like?
I think that there should be a set of core libraries and documentation organized within a single SVN. These libraries should be organized around concepts, not authors. This SVN would include mostly just that, basically nothing else. Other libraries, projects, etc. could have their own repository or a separate section in the main SVN.
This isn't an original idea, this is common wisdom from many projects like python, ruby, perl, etc.
.hc
------------------------------------------------------------------------ ----
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.