FWIW, I recently listened to a really entertaining presentation of a computer systems security expert and one thing he pointed out that IMHO is currently really bogging Pd development is legacy support.
If PD is currently undergoing a complete rewrite of the GUI this may be a good opportunity to also revisit external naming scheme. I understand that there has been a lot of work done by Hans and others to make pd-extended easier to use, yet many problems remain. What if we simply all agree to do fundamental changes to how externals work with the understanding that we are effectively breaking backwards compatibility (which is not that big of a deal, simply use your favorite editor and search/replace offending objects and you are done) and make the whole thing a lot simpler?
For instance, each external object could be simply retitled to cyclone_pow~ or iemlib_pow~ or whatever. We've been effectively doing this with DISIS objects and have had no problems whatsoever with trivial issues such as what folder they need to go into and where is their help file supposed to go (e.g. pd-extended still fails to load proper help files and has a myriad of other problems).
Of course, this is not as easy as it sounds:
What objects are considered a part of the vanilla pd-extended? I would simply say iem, gem, and pd are vanilla are it and everything else is renamed.
What about the trouble of remembering what object does what? Well, if 0.43 will have a nice right-click menu with all objects listed in there and if we do good cross-referencing documentation, this should not be as difficult and/or confusing (certainly no more than typing cyclone/pow~ or whatever).
etc. Basically, I think this would in the long run be a lot easier as we would simply end-up having only one folder for all help files and only one folder for all externals. No sub-folders, no complex paths, lost/mixed-up help files, no unusual workarounds within Pd.
Just my 1-cents worth...
Ico
I think its good to get to a point where we don't have to worry much
about backwards compatibility. IMHO, the easiest way to do that is
embed library and other settings in each patch rather than having
libraries loaded by default. The pow~ issue highlights that.
You can also already use naming schemes like cyclone/prepend, iemlib/ prepend, etc.
.hc
On Nov 12, 2009, at 9:55 AM, Ivica Ico Bukvic wrote:
FWIW, I recently listened to a really entertaining presentation of a computer systems security expert and one thing he pointed out that
IMHO is currently really bogging Pd development is legacy support.If PD is currently undergoing a complete rewrite of the GUI this may
be a good opportunity to also revisit external naming scheme. I
understand that there has been a lot of work done by Hans and others to make pd- extended easier to use, yet many problems remain. What if we simply all agree
to do fundamental changes to how externals work with the understanding
that we are effectively breaking backwards compatibility (which is not that big
of a deal, simply use your favorite editor and search/replace offending
objects and you are done) and make the whole thing a lot simpler?For instance, each external object could be simply retitled to
cyclone_pow~ or iemlib_pow~ or whatever. We've been effectively doing this with
DISIS objects and have had no problems whatsoever with trivial issues such
as what folder they need to go into and where is their help file supposed to
go (e.g. pd-extended still fails to load proper help files and has a
myriad of other problems).Of course, this is not as easy as it sounds:
What objects are considered a part of the vanilla pd-extended? I would simply say iem, gem, and pd are vanilla are it and everything else is renamed.
What about the trouble of remembering what object does what? Well,
if 0.43 will have a nice right-click menu with all objects listed in there
and if we do good cross-referencing documentation, this should not be as
difficult and/or confusing (certainly no more than typing cyclone/pow~ or
whatever).etc. Basically, I think this would in the long run be a lot easier
as we would simply end-up having only one folder for all help files and
only one folder for all externals. No sub-folders, no complex paths, lost/ mixed-up help files, no unusual workarounds within Pd.Just my 1-cents worth...
Ico
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
'You people have such restrictive dress for women,’ she said, hobbling
away in three inch heels and panty hose to finish out another pink-
collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
I think its good to get to a point where we don't have to worry much about backwards compatibility. IMHO, the easiest way to do that is embed library and other settings in each patch rather than having libraries loaded by default. The pow~ issue highlights that.
You can also already use naming schemes like cyclone/prepend, iemlib/ prepend, etc.
.hc
That however does not solve problems like help files not being found (at least no here) and/or not knowing which one is being loaded by default (e.g. scale object is by default from Gem lib, so when you load the maxlib version and right-click on its help, you still get Gem lib one).
Ico
On Nov 12, 2009, at 12:18 PM, Ivica Ico Bukvic wrote:
I think its good to get to a point where we don't have to worry much about backwards compatibility. IMHO, the easiest way to do that is embed library and other settings in each patch rather than having libraries loaded by default. The pow~ issue highlights that.
You can also already use naming schemes like cyclone/prepend, iemlib/ prepend, etc.
.hc
That however does not solve problems like help files not being found
(at least no here) and/or not knowing which one is being loaded by
default (e.g. scale object is by default from Gem lib, so when you load the maxlib
version and right-click on its help, you still get Gem lib one).Ico
In Pd-extended 0.41.4 and newer, and with libdirs, the help patches
should be found when using namespace prefixes. They are in all the
tests I've done.
As for loading by default, I personally think no libraries should be
loaded by default. We just need to figure out a transition plan.
.hc
All mankind is of one author, and is one volume; when one man dies,
one chapter is not torn out of the book, but translated into a better
language; and every chapter must be so translated.... -John Donne
In Pd-extended 0.41.4 and newer, and with libdirs, the help patches should be found when using namespace prefixes. They are in all the tests I've done.
As for loading by default, I personally think no libraries should be loaded by default. We just need to figure out a transition plan.
.hc
Could it be that mine is having issues because I've got Gem library loaded at startup?
Also, has the problem with [>~ ] and similar objects using special characters been fixed in 0.42.5 (IIRC 0.41.4 had issues with these so you had to invoke those objects using hex ascii values).
Ico
On Nov 14, 2009, at 1:41 PM, Ivica Ico Bukvic wrote:
In Pd-extended 0.41.4 and newer, and with libdirs, the help patches should be found when using namespace prefixes. They are in all the tests I've done.
As for loading by default, I personally think no libraries should be loaded by default. We just need to figure out a transition plan.
.hc
Could it be that mine is having issues because I've got Gem library
loaded at startup?
No, that works for me. Which help patch isn't working?
Also, has the problem with [>~ ] and similar objects using special characters been fixed in 0.42.5 (IIRC 0.41.4 had issues with these
so you had to invoke those objects using hex ascii values).
That's an issue with hexloader. If you want to use those names, you
need to load hexloader first. I think you could do it like [import
hexloader]
.hc
"Free software means you control what your computer does. Non-free
software means someone else controls that, and to some extent controls
you." - Richard M. Stallman
No, that works for me. Which help patch isn't working?
In that case it could be because I moved things around not knowing about hexloader and other interesting stuff.
Also, has the problem with [>~ ] and similar objects using special characters been fixed in 0.42.5 (IIRC 0.41.4 had issues with these so you had to invoke those objects using hex ascii values).
That's an issue with hexloader. If you want to use those names, you need to load hexloader first. I think you could do it like [import hexloader]
Didn't someone mention that hexloader was still buggy or has this been fixed?
Ico
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ivica Ico Bukvic wrote: #
Didn't someone mention that hexloader was still buggy or has this been fixed?
hexloader works perfectly for loading binaries (or everything that uses a sysloader to load). it has problems loading abstractions, because of the way abstraction-loading is implemented in Pd. nothing i can fix without changing the internals of Pd. (there is a patch in the patch-tracker that might do that)
therefore abstraction loading is disabled in hexloader by default.
fghmasdr IOhannes
Also, has the problem with [>~ ] and similar objects using special characters been fixed in 0.42.5 (IIRC 0.41.4 had issues with these
so you had to invoke those objects using hex ascii values).That's an issue with hexloader. If you want to use those names, you
need to load hexloader first. I think you could do it like [import
hexloader].hc
This is what I get when trying to do [import hexloader] and try to create [>~ ] object from zexy library. It seems to me that hexloader in its current form is clearly not the solution and hence the lingering questions are:
broken what can be done to circumvent this problem to make it usable until hexloader is fixed?
Ico
load_object: Symbol "0x3e0x7e_setup" not found error: BUG: hexloader not loading abstraction: /usr/lib/pd/extra/zexy/0x3e0x7e.pd (not yet implemented)
~
... couldn't create load_object: Symbol "0x3e0x7e_setup" not found error: BUG: hexloader not loading abstraction: /usr/lib/pd/extra/zexy/0x3e0x7e.pd (not yet implemented) zexy/>~ ... couldn't create
- if hexloader is buggy/incomplete what will it take to fix it?
- if you agree with me that in the interim pd-extended is effectively
broken what can be done to circumvent this problem to make it usable until hexloader is fixed?
I guess I owe everyone an apology. I've recompiled the external and now it for some reason works (perhaps I had a stale one lying around from a previous 0.41.4 version running against 0.42.5? If so, how could this have such an effect?)
This is what I get with the newly recompiled version:
hex loader $Revision: 1.5 $ written by IOhannes m zmölnig, IEM zmoelnig@iem.at compiled on Nov 17 2009 at 19:30:48 compiled against Pd version 0.42.5.extended load_object: Symbol "0x3e0x7e_setup" not found [>~] part of zexy-2.2.3 (compiled: Apr 29 2009)
Object still work ok, but is load_object: Symbol not found error something to worry about? Is this perhaps because zexy has been compiled potentially against a wrong version? Finally, how could I recompile it by hand to produce individual objects rather than a single library?
Once again, my apologies for the noise. I would greatly appreciate any insight on the newfound questions.
Many thanks!
Ico
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ivica Ico Bukvic wrote:
- if hexloader is buggy/incomplete what will it take to fix it?
mostly somebody who is willing to do the work. i have written and rewritten it several times, and frankly i don't care about it that much. i don't use it ever (since i use zexy.l_i386 rather than single-object externals). the problem with abstraction loading is to my knowledge non-fixable without touching Pd-code.
- if you agree with me that in the interim pd-extended is effectively
broken what can be done to circumvent this problem to make it usable until hexloader is fixed?
I guess I owe everyone an apology. I've recompiled the external and now it for some reason works (perhaps I had a stale one lying around from a previous 0.41.4 version running against 0.42.5? If so, how could this have such an effect?)
i stale version of what? [>~] or hexloader?
if it was hexloader, than the reason might be, that 0.42.5 has an almost-public API for loaders, whereas older version don't. if [hexloader] finds 0.42.5 at compile time, it will use this API, hence the workingness,
Object still work ok, but is load_object: Symbol not found error something to worry about? Is this perhaps because zexy has been compiled potentially against a wrong version?
no; it's a verbose message of hexloader, which tries several setup-routines (e.g. <name>_setup() and setup_<name>() and <setup_mangledname>() and whatelse), and informs you if it failed.
i guess the message should show up only in verbose mode.
Finally, how could I recompile it by hand to produce individual objects rather than a single library?
hexloader is only a single object. zexy can be configured with "--disable-library" to built as individual objects.
fgsadr IOhannes
On Thu, Nov 12, 2009 at 4:57 PM, Hans-Christoph Steiner hans@at.or.atwrote:
I think its good to get to a point where we don't have to worry much about backwards compatibility. IMHO, the easiest way to do that is embed library and other settings in each patch rather than having libraries loaded by default.
Sounds good to me. If we want to have backwards-compatibility AND to change things in a tabula-rasa way, we could establish a new "file type" (perhaps just a new filename extension eg.: .pd2) and then .pd files would be parsed with the old logic and .pd2 files with the brand new logic. Dunno if it actually makes sense, it just came to my mind now.
On Nov 12, 2009, at 1:04 PM, András Murányi wrote:
On Thu, Nov 12, 2009 at 4:57 PM, Hans-Christoph Steiner
hans@at.or.at wrote:I think its good to get to a point where we don't have to worry much
about backwards compatibility. IMHO, the easiest way to do that is
embed library and other settings in each patch rather than having
libraries loaded by default.Sounds good to me. If we want to have backwards-compatibility AND to change things in a
tabula-rasa way, we could establish a new "file type" (perhaps just
a new filename extension eg.: .pd2) and then .pd files would be
parsed with the old logic and .pd2 files with the brand new logic.
Dunno if it actually makes sense, it just came to my mind now.
That could work. That's how Max/MSP handles it. Here's their
extensions in rough order of introduction:
.pat
.mxt
.mxb
.help
.mxo
.maxpat
.maxhelp
That seems excessive to me tho. I think I'm missing some even.
.hc
kill your television