Greetings Everyone, I am trying to make a gaggle of objects and some of them have spun out with rather long names ([renderDepthSelector] is one example). It seems helpful to keep that name for the object (as it may make the thing more self explanatory), but I would also like to make an option for it to form with an abbreviation (say [rds]) analogous to the way [trigger] and [t] function. Do any of you brilliant minds know how to do that by any chance? Many many thanks in advance for your advice, as always, Sonia Yuditskaya ] yuditskaya.com [
Hi,
On Sat, Apr 24, 2010 at 09:35:19PM -0400, sonia yuditskaya wrote:
I am trying to make a gaggle of objects and some of them have spun out with rather long names ([renderDepthSelector] is one example).
Just a quick note: as operating systems treat upper- and lowercase in filenames differently (Linux is picky and will not load renderDepthSelector.pd for an object called [renderdepthselector], while Windows and OS-X will do), I try to avoid uppercase in abstraction names.
It seems helpful to keep that name for the object (as it may make the thing more self explanatory), but I would also like to make an option for it to form with an abbreviation (say [rds]) analogous to the way [trigger] and [t] function. Do any of you brilliant minds know how to do that by any chance?
I assume that you talk of abstractions here. You could do wrapper abstractions. For example rds.pd would just look like
[inlet] | [renderDepthSelector $1 ...] | [outlet]
Or you go with operating system features: On *nix systems you could use a symbolic link like "ln -s renderDepthSelector.pd rds.pd". Of course this is machine-dependent.
Ciao
Frank
On Sun, 25 Apr 2010, Frank Barknecht wrote:
Just a quick note: as operating systems treat upper- and lowercase in filenames differently (Linux is picky and will not load renderDepthSelector.pd for an object called [renderdepthselector], while Windows and OS-X will do), I try to avoid uppercase in abstraction names.
On Windows and OSX, [renderdepthselector] won't create either, though the file will be open. GetProcAddress and dlsym are case-sensitive. Then after that, class_new is case-sensitive too (because selectors are case-sensitive).
Or you go with operating system features: On *nix systems you could use a symbolic link like "ln -s renderDepthSelector.pd rds.pd".
Only on filesystems that support it. I say that because FAT is becoming *more* common on those operating systems; so when you transmit the file using flash-memory formatted the default way, you have to tar it or zip it.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On 2010-04-25 15:04, Mathieu Bouchard wrote:
On Sun, 25 Apr 2010, Frank Barknecht wrote:
Just a quick note: as operating systems treat upper- and lowercase in filenames differently (Linux is picky and will not load renderDepthSelector.pd for an object called [renderdepthselector], while Windows and OS-X will do), I try to avoid uppercase in abstraction names.
On Windows and OSX, [renderdepthselector] won't create either, though the file will be open. GetProcAddress and dlsym are case-sensitive. Then after that, class_new is case-sensitive too (because selectors are case-sensitive).
all true, but GetProcAddress will never be called for a file called "renderDepthSelector.pd".
anyhow, i (personally) don't think that CamelCase objectnames are bad. just make sure that you really use them throughout, both on the filesystem level and on the patching level. (or even better: switch to a case sensitive filesystem in the first place :-))
Or you go with operating system features: On *nix systems you could use a symbolic link like "ln -s renderDepthSelector.pd rds.pd".
Only on filesystems that support it. I say that because FAT is becoming *more* common on those operating systems; so when you transmit the file using flash-memory formatted the default way, you have to tar it or zip it.
i didn't know that zip would handle symbolic links. (never tried though) thanks for the idea.
fgmasdr IOhannes
Hi,
On Mon, Apr 26, 2010 at 09:07:30AM +0200, IOhannes m zmoelnig wrote:
anyhow, i (personally) don't think that CamelCase objectnames are bad. just make sure that you really use them throughout, both on the filesystem level and on the patching level. (or even better: switch to a case sensitive filesystem in the first place :-))
The problem is that unfortunatly not all users are that disciplined. Linux users are very trained to be anal about case in filenames because their default filesystem is case sensitive. But elsewhere too many people tend ignore the issue or are not even aware of it: for them a patch using UPPERCASE.pd works with [uppercase] in the patch as well, so why should they care?
So the reason I like to play it safe for abstractions I release into the wild is not so much technical, but social.
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
On Mon, 26 Apr 2010, IOhannes m zmoelnig wrote:
all true, but GetProcAddress will never be called for a file called "renderDepthSelector.pd".
Indeed, that was quite a mistake.
anyhow, i (personally) don't think that CamelCase objectnames are bad.
I don't think that they are bad either, there's just not much precedent for uppercase in Pd, and not much of a reason to deviate from the tradition.
i didn't know that zip would handle symbolic links. (never tried though) thanks for the idea.
Well, I had to double-check and it didn't work, using Info-ZIP (unix). Then I found an option in Info-ZIP to get it to work, but I don't know whether that can be recognised by all other relevant ZIP decoders. Surely not the ones on Windows, unless it's a recent addition. I'd be more curious about OSX... if I used ZIP on OSX.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
although creating objects with variable case works fine on all plattforms,
what doesn't work is the help patches - at least on windows. for example,
if you look for help from [Line~], you'll get [line~] instead. would it be
possible to correct this to make it more cohese? or is the help search
plattform dependent, and thus impossible to fix?
On 2010-04-25 15:04, Mathieu Bouchard wrote:
On Sun, 25 Apr 2010, Frank Barknecht wrote:
Just a quick note: as operating systems treat upper- and lowercase in filenames differently (Linux is picky and will not load renderDepthSelector.pd for an object called [renderdepthselector], while Windows and OS-X will do), I try to avoid uppercase in abstraction names.
On Windows and OSX, [renderdepthselector] won't create either, though the file will be open. GetProcAddress and dlsym are case-sensitive. Then after that, class_new is case-sensitive too (because selectors are case-sensitive).
all true, but GetProcAddress will never be called for a file called "renderDepthSelector.pd".
anyhow, i (personally) don't think that CamelCase objectnames are bad. just make sure that you really use them throughout, both on the filesystem level and on the patching level. (or even better: switch to a case sensitive filesystem in the first place :-))
Or you go with operating system features: On *nix systems you could use a symbolic link like "ln -s renderDepthSelector.pd rds.pd".
Only on filesystems that support it. I say that because FAT is becoming *more* common on those operating systems; so when you transmit the file using flash-memory formatted the default way, you have to tar it or zip
it.i didn't know that zip would handle symbolic links. (never tried though) thanks for the idea.
fgmasdr IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
João Pais wrote:
although creating objects with variable case works fine on all plattforms, what doesn't work is the help patches - at least on windows. for example, if you look for help from [Line~], you'll get [line~] instead. would it be possible to correct this to make it more cohese? or is the help search plattform dependent, and thus impossible to fix?
i guess the fix is simple: don't use case-insensitive filesystems (or even better: don't use w32)
seriously, the problem comes from the fact that Pd searches for a file "Line~-help.pd" (with capital "L") and w32 returns a hit for "line~-help.pd".
mfgasdr IOhannes
i guess the fix is simple: don't use case-insensitive filesystems (or even better: don't use w32)
seriously, the problem comes from the fact that Pd searches for a file "Line~-help.pd" (with capital "L") and w32 returns a hit for "line~-help.pd".
that's a fix, but it's not simple.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
João Pais wrote:
i guess the fix is simple: don't use case-insensitive filesystems (or even better: don't use w32)
seriously, the problem comes from the fact that Pd searches for a file "Line~-help.pd" (with capital "L") and w32 returns a hit for "line~-help.pd".
that's a fix, but it's not simple.
?? i didn't post a fix, rather the problem description...
gfsdr IOhannes
about the abbreviation, I would think twice. only because there are already lots of objects around, and it might happen that you double some name already used by someone. since there is no system to look at which names are being used and developers don't look much around to prevent it, nameclashes do occur. the good point about the big names (with or without capitals, makes no difference) is that your objects won't be confused with anyone else's.
or you use some individual abbreviation technique, like [r_d_s], etc.
or you ignore this message.
João Pais
Greetings Everyone, I am trying to make a gaggle of objects and some of them have spun out
with rather long names ([renderDepthSelector] is one example). It seems
helpful to keep that name for the object (as it may make the thing more self explanatory), but I would also like to make an option for it to form
with an abbreviation (say [rds]) analogous to the way [trigger] and [t] function. Do any of you brilliant minds know how to do that by any chance? Many many thanks in advance for your advice, as always, Sonia Yuditskaya ] yuditskaya.com [
Well...that got me thinking. I've often wondered how to avoid nameclashes. If each object has a prefix then this could be avoided.
So, jmmmp externs could be called jmmmp.prepend or jmmmp.rds etc (or jmmmp_rds - whatever flavour suits your tongue!)
Otherwise there are nameclashes that can seriously screw up a collection of abstractions. So, for example, the latest Metastudio objects have a phasevocoder~ abstraction (using pvoc~ from the bsaylor objects) but a lot of the other objects use the svf~ from cyclone (not bsaylor/svf~). Once bsaylor is imported into Pd-extended, the svf~ will always default to the bsaylor one (that has a denormal error, although I think I fixed this - anyone for testing?)
I got round this by setting the objects in PD to cycone/svf~ and bsaylor/pvoc~ (in case anyone else makes a pvoc~ object). But many PD users, especially those used to Mac or Windowze, will not know that you can access the directory structure of the extra folder directly within PD.
I think I might have to rename all my abstractions now...or maybe I'm too lazy until it becomes a problem.
Ed
Metastudio 3 for Pure Data - Free download at: http://sharktracks.co.uk/puredata
----- Original Message ---- From: João Pais jmmmpais@googlemail.com To: pd-list@iem.at; sonia yuditskaya marysghost@gmail.com Sent: Sun, 25 April, 2010 18:08:03 Subject: Re: [PD] naming objects
about the abbreviation, I would think twice. only because there are already lots of objects around, and it might happen that you double some name already used by someone. since there is no system to look at which names are being used and developers don't look much around to prevent it, nameclashes do occur. the good point about the big names (with or without capitals, makes no difference) is that your objects won't be confused with anyone else's.
or you use some individual abbreviation technique, like [r_d_s], etc.
or you ignore this message.
João Pais
Greetings Everyone, I am trying to make a gaggle of objects and some of them have spun out with rather long names ([renderDepthSelector] is one example). It seems helpful to keep that name for the object (as it may make the thing more self explanatory), but I would also like to make an option for it to form with an abbreviation (say [rds]) analogous to the way [trigger] and [t] function. Do any of you brilliant minds know how to do that by any chance? Many many thanks in advance for your advice, as always, Sonia Yuditskaya ] yuditskaya.com [
--Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmpais@googlemail.com | skype: jmmmpjmmmp
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 2010-04-26 03:25, Ed Kelly wrote:
Well...that got me thinking. I've often wondered how to avoid nameclashes. If each object has a prefix then this could be avoided.
So, jmmmp externs could be called jmmmp.prepend or jmmmp.rds etc (or jmmmp_rds - whatever flavour suits your tongue!)
when doing things like that, why not just use a libdir approach and use [jmmmp/prepend]? this way the library layout can be reflected both in the patch (object name) and on the filesystem.
fgmasdr IOhannes
I got round this by setting the objects in PD to cycone/svf~ and
bsaylor/pvoc~ (in case anyone else makes a pvoc~ object). But many PD
users, especially those used to Mac or Windowze, will not know that you
can access the directory structure of the extra folder directly within
PD.I think I might have to rename all my abstractions now...or maybe I'm
too lazy until it becomes a problem.
using folder (library) names might be the best solution, because it's the
way pd works - and has no issues with any os.
if you open your files in a text editor, you can rename them faster. just
rename your "object" to "blabla/object". Or ask someone for a script to do
it, that should be easy.
Ed Kelly wrote:
Otherwise there are nameclashes that can seriously screw up a collection of abstractions.
(Key paragraph wrapped in ****** below)
One way of fixing this once and for all would be to have a separate [objectmaker] for each canvas (including abstractions, but not subpatches, ie, those canvases that have a t_canvasenvironment attached to them - at least that is how I understand that part of Pd's code).
HCS's [import], as far as I understand the code, just adds canvas-local paths, but the single global [objectmaker] lets externals clash unless you use qualified names everywhere you use objects. A canvas-local [objectmaker] really would provide the necessary separation to allow abstractions from different worlds not to collide in a horribly crunch.
I have a vague sketch of an implementation like this already, but it's quite brutal to the core of Pd so I doubt the changes would be accepted by anyone without me cleaning it up a lot and providing a clean .diff to a current development version of Pd... Currently the *only* object that can be instantiated in an empty canvas in my implementation is [import]. [import foo] will load the foo library's manifest into a new [objectmaker] and store it in a map (so importing libraries multiple times doesn't do more work), and objects defined by the library are only setup() at most once too (on demand at first creation).
It's a pain in the arse to use at the moment though, as it's not instinctive to type [import vanilla] as the first thing in a patch, and abstraction support is broken completely at the moment. The manifest is a bit of a wart, too - it explicitly lists all file names and the classes that are provided by them (in place of hardcoded hexmangling etc, but this also allows for multi-object libraries and eventually a "[fu] not found, you might try [import karate] or [import sumo]" useful message).
BUT: the "killer application" of this canvas-local [objectmaker] mechanism is already apparent: you can have one patch massive.pd that loads an external like [import foo-library],[snazzy-filter] and another patch (or abstraction) bonanza.pd in the same Pd instance can do [import bar-library],[snazzy-filter] and each will get only the [snazzy-filter] that it desires.
I'm still undecided about what would be best to do if kerplunk.pd does [import foo-library bar-library],[snazzy-filter] - probably some qualified naming could work for that, either at point of import like [import foo-library/snazzy-filter bar-library] in which case the most-qualified version takes precedence (like CSS) or at point of use like [import foo-library bar-library],[foo-library/snazzy-filter] - the first would make patches shorter but the second would still be necessary in some cases too. Verbose and useful messages about what is going on would be the first priority, in any case.
Claude
On Mon, 26 Apr 2010, Claude Heiland-Allen wrote:
One way of fixing this once and for all would be to have a separate [objectmaker] for each canvas (including abstractions, but not subpatches, ie, those canvases that have a t_canvasenvironment attached to them - at least that is how I understand that part of Pd's code).
Thanks for bringing back the topic. There was a thread about that on pd-dev in september 2006, e.g. :
http://lists.puredata.info/pipermail/pd-dev/2006-09/007591.html http://lists.puredata.info/pipermail/pd-dev/2006-09/007605.html http://lists.puredata.info/pipermail/pd-dev/2006-09/007607.html http://lists.puredata.info/pipermail/pd-dev/2006-09/007608.html http://lists.puredata.info/pipermail/pd-dev/2006-09/007609.html etc
I have a vague sketch of an implementation like this already, but it's quite brutal to the core of Pd so I doubt the changes would be accepted by anyone without me cleaning it up a lot and providing a clean .diff to a current development version of Pd...
cleanliness is in the eye of the beholder... if you spend a lot of time cleaning, you can realise that it doesn't look any cleaner to the people you want to please, or else it can look dirtier.
apart from that, I think that you deserve good luck with this project and I am happy to learn that you succeeded.
but how does «t_pd *pd_newest» work in that context ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Mathieu Bouchard wrote:
On Mon, 26 Apr 2010, Claude Heiland-Allen wrote:
One way of fixing this once and for all would be to have a separate [objectmaker] for each canvas (including abstractions, but not subpatches, ie, those canvases that have a t_canvasenvironment attached to them - at least that is how I understand that part of Pd's code).
Thanks for bringing back the topic. There was a thread about that on pd-dev in september 2006, e.g. :
http://lists.puredata.info/pipermail/pd-dev/2006-09/007591.html http://lists.puredata.info/pipermail/pd-dev/2006-09/007605.html http://lists.puredata.info/pipermail/pd-dev/2006-09/007607.html http://lists.puredata.info/pipermail/pd-dev/2006-09/007608.html http://lists.puredata.info/pipermail/pd-dev/2006-09/007609.html etc
Thanks for the references.
I have a vague sketch of an implementation like this already, but it's quite brutal to the core of Pd so I doubt the changes would be accepted by anyone without me cleaning it up a lot and providing a clean .diff to a current development version of Pd...
cleanliness is in the eye of the beholder... if you spend a lot of time cleaning, you can realise that it doesn't look any cleaner to the people you want to please, or else it can look dirtier.
True...
apart from that, I think that you deserve good luck with this project and I am happy to learn that you succeeded.
Still got abstraction support to re-enable, hopefully it will work as planned - then I can claim success :-) Thanks :-)
but how does «t_pd *pd_newest» work in that context ?
newest is set when typedmess() sees that (target == pd_objectmaker). So the default pd_objectmaker defers to the canvas-local objectmaker, which sets pd_objectmaker to itself (before retrying after any ondemand load) or a child (for imported libraries) objectmaker before calling typedmess() and inspecting newest. So it's just another layer of baroque hackery, with special behaviour needed in [bang] [float] [symbol] and probably a couple of others
some names changed for no good reason other than to see what would break in the rest of Pd:
----8<---- /* called when no more-specific method is found, happily this happens at the top level canvas-local factory, so we can switch the default td_legacy_objectmaker before too much damage is done... */ static void td_objectfactory_anything(td_objectfactory *of, t_symbol *s, int argc, t_atom *argv) { newest = 0; td_list *n; td_ondemand *od = td_map_lookup(of->ondemand, s); if (od) { /* push object factory */ td_objectfactory *old = td_legacy_objectmaker; td_legacy_objectmaker = of; /* load on demand */ td_map_delete(of->ondemand, s); td_ondemand_load(od); td_ondemand_free(od); /* retry creation */ /* typedmess tests for td_legacy_objectmaker */ typedmess(&td_legacy_objectmaker->pd, s, argc, argv); /* pop object factory */ td_legacy_objectmaker = old; if (newest) { return; } } for (n = of->children; n; n = n->next) { td_objectfactory *c = n->p; td_objectfactory *old = td_legacy_objectmaker; td_legacy_objectmaker = c; /* typedmess tests for td_legacy_objectmaker */ typedmess(&td_legacy_objectmaker->pd, s, argc, argv); td_legacy_objectmaker = old; if (newest) { return; } } } ----8<----
Claude
On Apr 26, 2010, at 12:59 PM, Claude Heiland-Allen wrote:
Mathieu Bouchard wrote:
On Mon, 26 Apr 2010, Claude Heiland-Allen wrote:
One way of fixing this once and for all would be to have a
separate [objectmaker] for each canvas (including abstractions,
but not subpatches, ie, those canvases that have a
t_canvasenvironment attached to them - at least that is how I
understand that part of Pd's code).Thanks for bringing back the topic. There was a thread about that
on pd-dev in september 2006, e.g. : http://lists.puredata.info/pipermail/pd-dev/2006-09/007591.html http://lists.puredata.info/pipermail/pd-dev/2006-09/007605.html http://lists.puredata.info/pipermail/pd-dev/2006-09/007607.html http://lists.puredata.info/pipermail/pd-dev/2006-09/007608.html http://lists.puredata.info/pipermail/pd-dev/2006-09/007609.html etcThanks for the references.
I have a vague sketch of an implementation like this already, but
it's quite brutal to the core of Pd so I doubt the changes would
be accepted by anyone without me cleaning it up a lot and
providing a clean .diff to a current development version of Pd...cleanliness is in the eye of the beholder... if you spend a lot of
time cleaning, you can realise that it doesn't look any cleaner to
the people you want to please, or else it can look dirtier.True...
apart from that, I think that you deserve good luck with this
project and I am happy to learn that you succeeded.Still got abstraction support to re-enable, hopefully it will work
as planned - then I can claim success :-) Thanks :-)but how does «t_pd *pd_newest» work in that context ?
newest is set when typedmess() sees that (target ==
pd_objectmaker). So the default pd_objectmaker defers to the canvas- local objectmaker, which sets pd_objectmaker to itself (before
retrying after any ondemand load) or a child (for imported
libraries) objectmaker before calling typedmess() and inspecting
newest. So it's just another layer of baroque hackery, with special
behaviour needed in [bang] [float] [symbol] and probably a couple of
otherssome names changed for no good reason other than to see what would
break in the rest of Pd:----8<---- /* called when no more-specific method is found, happily this happens at the top level canvas-local factory, so we can switch the default td_legacy_objectmaker before too much damage is done... */ static void td_objectfactory_anything(td_objectfactory *of, t_symbol
*s, int argc, t_atom *argv) { newest = 0; td_list *n; td_ondemand *od = td_map_lookup(of->ondemand, s); if (od) { /* push object factory */ td_objectfactory *old = td_legacy_objectmaker; td_legacy_objectmaker = of; /* load on demand */ td_map_delete(of->ondemand, s); td_ondemand_load(od); td_ondemand_free(od); /* retry creation */ /* typedmess tests for td_legacy_objectmaker */ typedmess(&td_legacy_objectmaker->pd, s, argc, argv); /* pop object factory */ td_legacy_objectmaker = old; if (newest) { return; } } for (n = of->children; n; n = n->next) { td_objectfactory *c = n->p; td_objectfactory *old = td_legacy_objectmaker; td_legacy_objectmaker = c; /* typedmess tests for td_legacy_objectmaker */ typedmess(&td_legacy_objectmaker->pd, s, argc, argv); td_legacy_objectmaker = old; if (newest) { return; } } } ----8<----
This is some really interesting work, I am looking forward to trying
it out. I haven't really thought much about the implementation, but I
like the idea that the canvas-local namespace is blank until loading
something. We might consider having a library that loads by default,
something like how python loads a default library.
.hc
"A cellphone to me is just an opportunity to be irritated wherever you
are." - Linus Torvalds
-
Claude Heiland-Allen -
Ed Kelly -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
João Pais -
Mathieu Bouchard -
sonia yuditskaya