Gem cyclone zexy creb cxc iemlib list-abs mapping markex maxlib memento
mjlib motex oscx pddp pdogg pixeltango pmpd rradical sigpack smlib toxy unauthorized vbap pan freeverb hcs jmmmp ext13 ggee iem_anything flib ekext flatspace pdp pidip
I think it should be something like:
cyclone zexy creb iemlib ggee iem_anything flatspace
i don't understand the real goal of extended, wasn't it to include as much libraries as possible? ( and not to rewrite the gui ? )
second, i dunno why you made unauthorized into a lib, when it was really allright to have all objects separated in extra.. thus loaded when needed. you never asked my opinion about this neither...
and also people writing on the list saying you shouldn't use that external, i have a brilliant workaround, etc...
i see that the pd community if ever it existed is now getting a pyramidal structure where some people take decisions for all, cool..
xiaooo, sevy
well, as an ex-max only user , and a new Pd-extended user, I must say that I was quit happy to find already installed gem , pdp and an several other things.
it doesn't take time to load all the libraries, and I don't understand what would be the reason to change this (but maybe there is one that I don't see).
That's maybe true that it takes time to understand what to use because there's a lot of libraries, and some new structuring of the libraries may help, but not including gem (and particularly the pix_'object') and pdp by default will not be a good idea, I think . Also some more documentation may help too.
Finally, even if it is messy to understand what to use at the beginning, I still prefer to try things already in the extended distribution by default than to load things before to try.
one thing is that, if you compare to the source, some things are not working or not appearing on different platforms, but as I understand it is not related to the way to load libraries (by default or manually).
I would suggest to think about a new way to organize and document libraries instead of the stripping down option.
hope that help,
loic ---
On Feb 16, 2009, at 5:32 PM, ydegoyon@free.fr wrote:
Gem cyclone zexy creb cxc iemlib list-abs mapping markex maxlib memento
mjlib motex oscx pddp pdogg pixeltango pmpd rradical sigpack smlib toxy unauthorized vbap pan freeverb hcs jmmmp ext13 ggee iem_anything flib ekext flatspace pdp pidip
I think it should be something like:
cyclone zexy creb iemlib ggee iem_anything flatspace
i don't understand the real goal of extended, wasn't it to include as much libraries as possible? ( and not to rewrite the gui ? )
second, i dunno why you made unauthorized into a lib, when it was really allright to have all objects separated in extra.. thus loaded when needed. you never asked my opinion about this neither...
and also people writing on the list saying you shouldn't use that external, i have a brilliant workaround, etc...
i see that the pd community if ever it existed is now getting a pyramidal structure where some people take decisions for all, cool..
xiaooo, sevy
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Loic Kessous wrote:
Finally, even if it is messy to understand what to use at the beginning, I still prefer to try things already in the extended distribution by default than to load things before to try.
hmm, they would all remain in the distribution, they would just not be loaded by default. the patch-author would have to load libraries explicitly, which would make it (hopefully) more compatible with other distributions of Pd. most modern programming languages do not implicitly include 3rd (or even 1st) party libraries (even though they are included in the standard distro); see java, perl,...
fgmasdr IOhannes
To be clear, the libraries will all still be included in the package, they just won't be loaded by default. That means you'll have load them as part of the patch using either [declare] or [import], or using namespace prefixes like [cyclone/prepend]. This puts us further towards the goal of having all of the patch settings stored in the patch itself, making it more likely to work on more computers.
That said, you can still set your own preferences so that all of the libraries are loaded by default, and things continue to work how they do in previous version. But that means that your patches will likely not run on other people's computers.
Part of this effort is also pulling out as many objectclasses as possible from the core distribution, and making that a standalone library like the rest, like a 'vanilla' or 'extra' library. One immediate possibility created by doing that is the ability to have versions of this 'extra' library that are highly optimized for your CPU.
.hc
On Feb 16, 2009, at 12:39 PM, Loic Kessous wrote:
well, as an ex-max only user , and a new Pd-extended user, I must say that I was quit happy to find already installed gem , pdp and an several other things.
it doesn't take time to load all the libraries, and I don't understand what would be the reason to change this (but maybe there is one that I don't see).
That's maybe true that it takes time to understand what to use because there's a lot of libraries, and some new structuring of the libraries may help, but not including gem (and particularly the pix_'object') and pdp by default will not be a good idea, I think . Also some more documentation may help too.
Finally, even if it is messy to understand what to use at the beginning, I still prefer to try things already in the extended distribution by default than to load things before to try.
one thing is that, if you compare to the source, some things are not working or not appearing on different platforms, but as I understand it is not related to the way to load libraries (by default or manually).
I would suggest to think about a new way to organize and document libraries instead of the stripping down option.
hope that help,
loic
On Feb 16, 2009, at 5:32 PM, ydegoyon@free.fr wrote:
Gem cyclone zexy creb cxc iemlib list-abs mapping markex maxlib memento
mjlib motex oscx pddp pdogg pixeltango pmpd rradical sigpack smlib toxy unauthorized vbap pan freeverb hcs jmmmp ext13 ggee iem_anything flib ekext flatspace pdp pidip
I think it should be something like:
cyclone zexy creb iemlib ggee iem_anything flatspace
i don't understand the real goal of extended, wasn't it to include as much libraries as possible? ( and not to rewrite the gui ? )
second, i dunno why you made unauthorized into a lib, when it was really allright to have all objects separated in extra.. thus loaded when needed. you never asked my opinion about this neither...
and also people writing on the list saying you shouldn't use that external, i have a brilliant workaround, etc...
i see that the pd community if ever it existed is now getting a pyramidal structure where some people take decisions for all, cool..
xiaooo, sevy
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
If you are not part of the solution, you are part of the problem.
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
To be clear, the libraries will all still be included in the package, they just won't be loaded by default. That means you'll have load them as part of the patch using either [declare] or [import], or using namespace prefixes like [cyclone/prepend]. This puts us further towards the goal of having all of the patch settings stored in the patch itself, making it more likely to work on more computers.
How does minimizing the number of "loaded libraries" affect the goal of storing preferences in patches?
Ciao
On Feb 16, 2009, at 4:46 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
To be clear, the libraries will all still be included in the package, they just won't be loaded by default. That means you'll have load them as part of the patch using either [declare] or [import], or using namespace prefixes like [cyclone/prepend]. This puts us further towards the goal of having all of the patch settings stored in the patch itself, making it more likely to work on more computers.
How does minimizing the number of "loaded libraries" affect the goal of storing preferences in patches?
So people don't rely on the libraries being already loaded and explicitly set the libraries that the patch requires. This is how it works with C, PHP, Java, Python, C++, Tcl, etc. etc. etc. If you want to use a library, you need to include/declare/require/import it where you need it.
.hc
----------------------------------------------------------------------------
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Feb 16, 2009, at 4:46 PM, Frank Barknecht wrote:
How does minimizing the number of "loaded libraries" affect the goal of storing preferences in patches?
So people don't rely on the libraries being already loaded and explicitly set the libraries that the patch requires. This is how it works with C, PHP, Java, Python, C++, Tcl, etc. etc. etc. If you want to use a library, you need to include/declare/require/import it where you need it.
Changing the number of loaded libraries doesn't solve the problem of how to store preferences in patches.
Ciao
On Tue, 2009-02-17 at 07:12 +0100, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Feb 16, 2009, at 4:46 PM, Frank Barknecht wrote:
How does minimizing the number of "loaded libraries" affect the goal of storing preferences in patches?
So people don't rely on the libraries being already loaded and explicitly set the libraries that the patch requires. This is how it works with C, PHP, Java, Python, C++, Tcl, etc. etc. etc. If you want to use a library, you need to include/declare/require/import it where you need it.
Changing the number of loaded libraries doesn't solve the problem of how to store preferences in patches.
does it harm?
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Frank Barknecht wrote:
How does minimizing the number of "loaded libraries" affect the goal of storing preferences in patches?
depends on what you mean by "storing the preferences in patches". one part of the preferences is the libraries to be loaded. personally, i think it is a good thing to explicitely require libraries in patches that need them.
any other preferences are not affected by minimizing the number of autoloaded libs.
fmasdr IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Frank Barknecht wrote:
How does minimizing the number of "loaded libraries" affect the goal of storing preferences in patches?
depends on what you mean by "storing the preferences in patches". one part of the preferences is the libraries to be loaded. personally, i think it is a good thing to explicitely require libraries in patches that need them.
Yeah, but IMO one has nothing to do with the other. Just because a pd-extended user would be forced to manage preferences manually doesn't make [import] a builtin or makes everyone layout their patches and externals as Pd-extended does it neither lets it [declare] work in abstractions. So I don't see how a minimized set of libraries affects anything.
Personally I don't care what pd-extended loads and what not, but *if* minimizing libraries should be done, then I think no library should be loaded at all besides [import].
Ciao
On Tuesday 17 February 2009 22:29:10 Frank Barknecht wrote:
Hallo,
IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Frank Barknecht wrote:
How does minimizing the number of "loaded libraries" affect the goal of storing preferences in patches?
depends on what you mean by "storing the preferences in patches". one part of the preferences is the libraries to be loaded. personally, i think it is a good thing to explicitely require libraries in patches that need them.
Yeah, but IMO one has nothing to do with the other. Just because a pd-extended user would be forced to manage preferences manually doesn't make [import] a builtin or makes everyone layout their patches and externals as Pd-extended does it neither lets it [declare] work in abstractions. So I don't see how a minimized set of libraries affects anything.
Personally I don't care what pd-extended loads and what not, but *if* minimizing libraries should be done, then I think no library should be loaded at all besides [import].
Ciao
without having any real grasp of pd-extended (sorry, never used it), my understanding is that [declare] and [import] may load libraries/objects relative to the patch, but they are still loaded in memory and *will* override the functionality expected in any patch loaded consecutively. without an unload routine for external libs, or a method to restrict dynamic loading of libs to the parent patch, then pd will still suffer nameclashes and aliasing of default behaviour for any patch loaded thereafter.
i think this behaviour becomes even more confusing as the lib in question was never explicitly loaded by the user.
please correct me if I am wrong or misguided!
ciao,
dmotd
On Feb 17, 2009, at 11:14 AM, dmotd wrote:
On Tuesday 17 February 2009 22:29:10 Frank Barknecht wrote:
Hallo,
IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Frank Barknecht wrote:
How does minimizing the number of "loaded libraries" affect the goal of storing preferences in patches?
depends on what you mean by "storing the preferences in patches". one part of the preferences is the libraries to be loaded. personally, i think it is a good thing to explicitely require libraries in patches that need them.
Yeah, but IMO one has nothing to do with the other. Just because a pd-extended user would be forced to manage preferences manually doesn't make [import] a builtin or makes everyone layout their patches and externals as Pd-extended does it neither lets it [declare] work in abstractions. So I don't see how a minimized set of libraries affects anything.
Personally I don't care what pd-extended loads and what not, but *if* minimizing libraries should be done, then I think no library should be loaded at all besides [import].
Ciao
without having any real grasp of pd-extended (sorry, never used it), my understanding is that [declare] and [import] may load libraries/ objects relative to the patch, but they are still loaded in memory and *will* override the functionality expected in any patch loaded consecutively. without an unload routine for external libs, or a method to restrict dynamic loading of libs to the parent patch, then pd will still suffer nameclashes and aliasing of default behaviour for any patch loaded thereafter.
i think this behaviour becomes even more confusing as the lib in question was never explicitly loaded by the user.
please correct me if I am wrong or misguided!
ciao,
dmotd
First off, I just want to say, this doesn't only affect Pd-extended. [declare] is in vanilla, and these namespace prefixes existed before Pd-extended did. Pd-extended does use them as the main organizing structure of libraries, while Pd-vanilla is a free-for-all, you can use them, but you don't have to.
That said, you bring up a good point. For binaries, once they are loaded, they are in the global namespace. So yes, I think it will be confusing. But for abstractions, they are in effect only loaded into the canvas-local namespace because the path is consulted everytime you load an abstraction, AFAIK.
So perhaps for this release, only the libs made up of abstractions should be removed from the default load list (mapping, jmmmp, pixeltango, etc.)
The end goal is to have no libraries loaded by default, but it would be good if we can soften the transition. Maybe my idea doesn't soften the transition, in which case things should stay as they are. This thread has been very useful is bringing the issues to the surface. :)
.hc
----------------------------------------------------------------------------
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
-
dmotd -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Loic Kessous -
Roman Haefeli -
ydegoyon＠free.fr