So the [fiddle~] bug is fixed, here's a new one (from OSX):
Launch Pd:
hans@sla:darwin_app > build/Pd.app/Contents/Resources/bin/pd -verbose -stderr
Try to use included [mtx_*]:
tried /Users/hans/cvs/pure-data/packages/darwin_app/mtx_*.pd_darwin and failed tried /Users/hans/cvs/pure-data/externals/build/darwin/mtx_*.pd_darwin and failed tried build/Pd.app/Contents/Resources/extra/mtx_*.pd_darwin and failed tried /Users/hans/cvs/pure-data/packages/darwin_app/mtx_*/mtx_*.pd_darwin and failed tried /Users/hans/cvs/pure-data/externals/build/darwin/mtx_*/mtx_*.pd_darwin and failed tried build/Pd.app/Contents/Resources/extra/mtx_*/mtx_*.pd_darwin and failed tried /Users/hans/cvs/pure-data/packages/darwin_app/mtx_0x2a.pd_darwin and failed tried /Users/hans/cvs/pure-data/externals/build/darwin/mtx_0x2a.pd_darwin and succeeded tried /Users/hans/cvs/pure-data/packages/darwin_app/mtx_*/mtx_*/ mtx_0x2a.pd_darwin and failed tried /Users/hans/cvs/pure-data/externals/build/darwin/mtx_*/mtx_*/ mtx_0x2a.pd_darwin and failed tried build/Pd.app/Contents/Resources/extra/mtx_*/mtx_*/mtx_0x2a.pd_darwin and failed tried /Users/hans/cvs/pure-data/packages/darwin_app/mtx_*.pd and failed tried /Users/hans/cvs/pure-data/externals/build/darwin/mtx_*.pd and failed tried build/Pd.app/Contents/Resources/extra/mtx_*.pd and failed tried /Users/hans/cvs/pure-data/packages/darwin_app/mtx_0x2a.pd and failed tried /Users/hans/cvs/pure-data/externals/build/darwin/mtx_0x2a.pd and failed tried build/Pd.app/Contents/Resources/extra/mtx_0x2a.pd and failed tried /Users/hans/cvs/pure-data/packages/darwin_app/mtx_*.pat and failed tried /Users/hans/cvs/pure-data/externals/build/darwin/mtx_*.pat and failed tried build/Pd.app/Contents/Resources/extra/mtx_*.pat and failed mtx_* ... couldn't create
It is indeed there:
hans@sla:darwin_app > ls -l build/Pd.app/Contents/Resources/extra/mtx_0x2a.pd_darwin -rwxr-xr-x 1 hans staff 48792 Nov 22 00:05 build/Pd.app/Contents/Resources/extra/mtx_0x2a.pd_darwin*
But it never looks for:
build/Pd.app/Contents/Resources/extra/mtx_0x2a.pd_darwin
It does look for:
build/Pd.app/Contents/Resources/extra/mtx_*.pd_darwin build/Pd.app/Contents/Resources/extra/mtx_0x2a.pd
.hc
________________________________________________________________________ ____
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
Hans-Christoph Steiner wrote:
So the [fiddle~] bug is fixed, here's a new one (from OSX):
Launch Pd:
hans@sla:darwin_app > build/Pd.app/Contents/Resources/bin/pd -verbose -stderr
Try to use included [mtx_*]:
tried /Users/hans/cvs/pure-data/packages/darwin_app/mtx_*.pd_darwin and failed tried /Users/hans/cvs/pure-data/externals/build/darwin/mtx_*.pd_darwin and failed tried build/Pd.app/Contents/Resources/extra/mtx_*.pd_darwin and failed tried /Users/hans/cvs/pure-data/packages/darwin_app/mtx_*/mtx_*.pd_darwin and failed tried /Users/hans/cvs/pure-data/externals/build/darwin/mtx_*/mtx_*.pd_darwin and failed tried build/Pd.app/Contents/Resources/extra/mtx_*/mtx_*.pd_darwin and failed tried /Users/hans/cvs/pure-data/packages/darwin_app/mtx_0x2a.pd_darwin and failed tried /Users/hans/cvs/pure-data/externals/build/darwin/mtx_0x2a.pd_darwin and succeeded
so it succeeds here to find the external. however it fails to load the setup function. it then stops to search for more mtx_0x2a.pd_darwin files.
why? because the setup-function is not "mtx_0x2a_setup()" but rather "setup_mtx_0x2a()". in build/mtx_0x2a.c the wrong setup-function is defined.
tried /Users/hans/cvs/pure-data/packages/darwin_app/mtx_*/mtx_*/ mtx_0x2a.pd_darwin and failed
this is weird. i think it should try to search for mtx_0x2a/mtx_0x2a.pd_darwin instead of mtx_*/mtx_*/mtx_0x2a.pd_darwin.
It is indeed there:
hans@sla:darwin_app > ls -l build/Pd.app/Contents/Resources/extra/mtx_0x2a.pd_darwin -rwxr-xr-x 1 hans staff 48792 Nov 22 00:05 build/Pd.app/Contents/Resources/extra/mtx_0x2a.pd_darwin*
But it never looks for:
build/Pd.app/Contents/Resources/extra/mtx_0x2a.pd_darwin
see above: since it already found a mtx_0x2a.pd_darwin it stops looking for another one.
mfg.asdr IOhannes
On Nov 22, 2005, at 4:54 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
So the [fiddle~] bug is fixed, here's a new one (from OSX): Launch Pd: hans@sla:darwin_app > build/Pd.app/Contents/Resources/bin/pd -verbose -stderr Try to use included [mtx_*]: tried /Users/hans/cvs/pure-data/packages/darwin_app/mtx_*.pd_darwin and failed tried /Users/hans/cvs/pure-data/externals/build/darwin/mtx_*.pd_darwin and failed tried build/Pd.app/Contents/Resources/extra/mtx_*.pd_darwin and failed tried /Users/hans/cvs/pure-data/packages/darwin_app/mtx_*/mtx_*.pd_darwin and failed tried /Users/hans/cvs/pure-data/externals/build/darwin/mtx_*/ mtx_*.pd_darwin and failed tried build/Pd.app/Contents/Resources/extra/mtx_*/mtx_*.pd_darwin and failed tried /Users/hans/cvs/pure-data/packages/darwin_app/mtx_0x2a.pd_darwin and failed tried /Users/hans/cvs/pure-data/externals/build/darwin/mtx_0x2a.pd_darwin and succeeded
so it succeeds here to find the external. however it fails to load the setup function. it then stops to search for more mtx_0x2a.pd_darwin files.
why? because the setup-function is not "mtx_0x2a_setup()" but rather "setup_mtx_0x2a()". in build/mtx_0x2a.c the wrong setup-function is defined.
Ah, thanks... it was a long day. Did you get the other bug report? That one is a bug in the patch... really! ;)
I have a question, why did you reverse the order of the original stantard setup function?
i.e. original = mtx_+_setup() altname = setup_mtx_0x2a()
I think that just makes things confusing and causes bugs, well, like the one we just talked about.
.hc
tried /Users/hans/cvs/pure-data/packages/darwin_app/mtx_*/mtx_*/ mtx_0x2a.pd_darwin and failed
this is weird. i think it should try to search for mtx_0x2a/mtx_0x2a.pd_darwin instead of mtx_*/mtx_*/mtx_0x2a.pd_darwin.
It is indeed there: hans@sla:darwin_app > ls -l build/Pd.app/Contents/Resources/extra/mtx_0x2a.pd_darwin -rwxr-xr-x 1 hans staff 48792 Nov 22 00:05 build/Pd.app/Contents/Resources/extra/mtx_0x2a.pd_darwin* But it never looks for: build/Pd.app/Contents/Resources/extra/mtx_0x2a.pd_darwin
see above: since it already found a mtx_0x2a.pd_darwin it stops looking for another one.
mfg.asdr IOhannes
________________________________________________________________________ ____
"If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it." - Thomas Jefferson
Hans-Christoph Steiner wrote:
in build/mtx_0x2a.c the wrong setup-function is defined.
Ah, thanks... it was a long day. Did you get the other bug report? That one is a bug in the patch... really! ;)
yes, i know though i haven't made any steps to commit a fixed patch yet...
I have a question, why did you reverse the order of the original stantard setup function?
i.e. original = mtx_+_setup() altname = setup_mtx_0x2a()
I think that just makes things confusing and causes bugs, well, like the one we just talked about.
yes it is confusing but: i want to have a different setup-function for the alternative names; otherwise it would forbid to make an object that is really called "mtx_0x2a". on 2nd thought, this is _almost_ impossible now too, because it is hard (though possible) to have 2 mtx_0x2a.pd_linux lying around (one for the [mtx_*] and one for [mtx_0x2a])
what is more important is, that you cannot start function names with numbers (at least in C) so the [<<<] object (which would expand to "0x3c0x3c0x3c") cannot have a valid setup-function "0x3c0x3c0x3c_setup()"; however "setup_0x3c0x3c0x3c()" is fine.
so i really think, that there should be 2 separate names (if we agree, that it would be a bad idea to rename the standard setupfun-name to setup_***()
mfg.a.r IOhannes
On Nov 22, 2005, at 10:43 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
in build/mtx_0x2a.c the wrong setup-function is defined.
Ah, thanks... it was a long day. Did you get the other bug report? That one is a bug in the patch... really! ;)
yes, i know though i haven't made any steps to commit a fixed patch yet...
I have a question, why did you reverse the order of the original stantard setup function? i.e. original = mtx_+_setup() altname = setup_mtx_0x2a() I think that just makes things confusing and causes bugs, well, like the one we just talked about.
yes it is confusing but: i want to have a different setup-function for the alternative names; otherwise it would forbid to make an object that is really called "mtx_0x2a". on 2nd thought, this is _almost_ impossible now too, because it is hard (though possible) to have 2 mtx_0x2a.pd_linux lying around (one for the [mtx_*] and one for [mtx_0x2a])
what is more important is, that you cannot start function names with numbers (at least in C) so the [<<<] object (which would expand to "0x3c0x3c0x3c") cannot have a valid setup-function "0x3c0x3c0x3c_setup()"; however "setup_0x3c0x3c0x3c()" is fine.
What about alt_0x3c0x3c0x3c_setup()? That would highlight that its an alternate name, rather than just having an seemingly arbitrary reversal of the "setup" placement. And the function is called sys_load_lib_alt(). That makes more sense in terms of the API.
so i really think, that there should be 2 separate names (if we agree, that it would be a bad idea to rename the standard setupfun-name to setup_***()
Yes, that is more trouble than its worth.
.hc
________________________________________________________________________ ____
¡El pueblo unido jamás será vencido!
Hans-Christoph Steiner wrote:
What about alt_0x3c0x3c0x3c_setup()? That would highlight that its an
but this really makes and object called [alt_0x3c0x3c0x3c] impossible!
alternate name, rather than just having an seemingly arbitrary reversal of the "setup" placement. And the function is called sys_load_lib_alt(). That makes more sense in terms of the API.
well calling it sys_load_lib_alt() was a very fast decision (so i am not proud of it). i still think that the alternative setup function should be called fundamentally differently, so that it is impossible to make an object with a normal setup-function that is named like the alternative function of another object.
but probably it would be nice to hear somebody else's opinion on this (at least from those who are not entirely bored of this thread)
mfg.ads.r IOhannes
On Tue, 22 Nov 2005, IOhannes m zmoelnig wrote:
but probably it would be nice to hear somebody else's opinion on this (at least from those who are not entirely bored of this thread)
Not an opinion,but an alternative proposal would be to use something non-numeric instead of 0x, like "$" for example.
Guenter
mfg.ads.r IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
gÃŒnter geiger wrote:
On Tue, 22 Nov 2005, IOhannes m zmoelnig wrote:
but probably it would be nice to hear somebody else's opinion on this (at least from those who are not entirely bored of this thread)
Not an opinion,but an alternative proposal would be to use something non-numeric instead of 0x, like "$" for example.
looking into kernighan-ritchie it says (if i read the c-syntax-graph correctly) that the function-name is an identifier which in turn has to match the regular expression "[_A-Za-z]{[_A-Za-z0-9]}*" (transcription to regex done by me, so it might be erroneous)
it doesn't say anything about non-alphanumeric characters (except for the underscore), so i am a bit afraid of that.
mfg.adr IOhannes
On Tue, 22 Nov 2005, IOhannes m zmoelnig wrote:
günter geiger wrote:
On Tue, 22 Nov 2005, IOhannes m zmoelnig wrote:
but probably it would be nice to hear somebody else's opinion on this (at least from those who are not entirely bored of this thread)
Not an opinion,but an alternative proposal would be to use something non-numeric instead of 0x, like "$" for example.
looking into kernighan-ritchie it says (if i read the c-syntax-graph correctly) that the function-name is an identifier which in turn has to match the regular expression "[_A-Za-z]{[_A-Za-z0-9]}*" (transcription to regex done by me, so it might be erroneous)
it doesn't say anything about non-alphanumeric characters (except for the underscore), so i am a bit afraid of that.
Well, a bad example then, what about "x0" instead of "0x", or whatever doesnt start as a numeric value.
Günter
mfg.adr IOhannes
geiger wrote:
it doesn't say anything about non-alphanumeric characters (except for the underscore), so i am a bit afraid of that.
Well, a bad example then, what about "x0" instead of "0x", or whatever doesnt start as a numeric value.
nice idea. (but wouldn't that be even more confusing than having an arbitrary prefix?)
probably it would be easiest to just prepend "_" and keep the 0x notation.
mfg.asdr. IOhannes
On Nov 23, 2005, at 10:46 AM, IOhannes m zmoelnig wrote:
geiger wrote:
it doesn't say anything about non-alphanumeric characters (except for the underscore), so i am a bit afraid of that.
Well, a bad example then, what about "x0" instead of "0x", or whatever doesnt start as a numeric value.
nice idea. (but wouldn't that be even more confusing than having an arbitrary prefix?)
probably it would be easiest to just prepend "_" and keep the 0x notation.
Yes, that sounds good. So then you couldn't have an object named _0x2a for example. I think that is a livable comprimise.
.hc ________________________________________________________________________ ____
"Computer science is no more related to the computer than astronomy is related to the telescope." -Edsger Dykstra
Hans-Christoph Steiner wrote:
probably it would be easiest to just prepend "_" and keep the 0x notation.
or even simpler: use "x" instead of "0x" (of course this is not the conventional C-way of encoding hex-values)
Yes, that sounds good. So then you couldn't have an object named _0x2a for example. I think that is a livable comprimise.
the best thing (which i tried to explain last time) is, that you _can_ have both [_0x2a] and [*], _if_ the setup-function and the filename do not adhere to the very same logic! (it was just me who was thinking into the wrong direction). filenames don't have the "do not start with numbers" restriction. so the [*]-external can live in a "0x2a.dll" with a setup-function "_0x2a_setup()", while the [_0x2a] external would live in a "_0x2a.dll" (with the same setup-function! but the entry point to the library is on a per-file basis so we don't have to care). the only remaining problem is the [0x2a] object....which we forgot and which still cannot be loaded.
but in theory it looks like that (with "*" being an invalid character, and X being the escape-sequence of this character)
[X] X.dll X_setup() [*] X.dll _X_setup() [_X] _X.dll _X_setup()
_if_ we guarantee that X starts with a valid character (not a number), this does not necessarily help us, since then we can do: [*] X.dll X_setup() which really is the same as for [X].
if X does not start with a valid character (e.g. "0"), then we have a problem anyhow with [X].
so what's the conclusion of all this?
probably it would be simplest to use tg's external loader hook and just write a "hexsetup" external and a "zexsetup" external and ... ;-)
fmg.asdr. IOhannes
On Nov 23, 2005, at 10:38 AM, geiger wrote:
On Tue, 22 Nov 2005, IOhannes m zmoelnig wrote:
günter geiger wrote:
On Tue, 22 Nov 2005, IOhannes m zmoelnig wrote:
but probably it would be nice to hear somebody else's opinion on this (at least from those who are not entirely bored of this thread)
Not an opinion,but an alternative proposal would be to use something non-numeric instead of 0x, like "$" for example.
looking into kernighan-ritchie it says (if i read the c-syntax-graph correctly) that the function-name is an identifier which in turn has to match the regular expression "[_A-Za-z]{[_A-Za-z0-9]}*" (transcription to regex done by me, so it might be erroneous)
it doesn't say anything about non-alphanumeric characters (except for the underscore), so i am a bit afraid of that.
Well, a bad example then, what about "x0" instead of "0x", or whatever doesnt start as a numeric value.
0x was chosen since it is the way that C declares hex values. Instead of creating some arbitrary syntax, why don't we stick to the well known ones and save the brain space for other details. HTML/XML style &entities; won't work, nor will emacs style \201 characters.
.hc
________________________________________________________________________ ____
If you are not part of the solution, you are part of the problem.
- Eldridge Cleaver
On Wed, 23 Nov 2005, Hans-Christoph Steiner wrote:
Well, a bad example then, what about "x0" instead of "0x", or whatever doesnt start as a numeric value.
0x was chosen since it is the way that C declares hex values. Instead of creating some arbitrary syntax, why don't we stick to the well known ones and save the brain space for other details. HTML/XML style &entities; won't work, nor will emacs style \201 characters.
Yes, I know. I just thought that if you need give away some possible names for externals (like all those with 0x in the current solution), then it seems a bit strange that you give away even more names (all alt_.. whatever) just to work around the problem that the sequence you where choosing in the first place doesn't fit all cases.
You could also say that everything with x[0..9,a..f,A..F][0..9,a..f,A..F], or hex[0..9,a..f,A..F][0..9,a..f,A..F], or .. Starting the escape sequence with a number seems to generate a problem.
The C tradition is a strong argument, but the functionality is not obvious so you would have to document it in any case. At the end its a question of taste, ... I dont have a really strong opinion, but I disklike the setup switching as well as the additional prefix solution because they complicate the loading and introduce additional paradigms (which have to be documented too).
Guenter
.hc
If you are not part of the solution, you are part of the problem.
- Eldridge Cleaver
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Nov 22, 2005, at 11:39 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
What about alt_0x3c0x3c0x3c_setup()? That would highlight that its an
but this really makes and object called [alt_0x3c0x3c0x3c] impossible!
The setup function would then be alt_alt_0x3c0x3c0x3c_setup(), so it would be possible.
alternate name, rather than just having an seemingly arbitrary reversal of the "setup" placement. And the function is called sys_load_lib_alt(). That makes more sense in terms of the API.
well calling it sys_load_lib_alt() was a very fast decision (so i am not proud of it). i still think that the alternative setup function should be called fundamentally differently, so that it is impossible to make an object with a normal setup-function that is named like the alternative function of another object.
How about sys_load_lib_hex() and hex_blahblah_setup()
but probably it would be nice to hear somebody else's opinion on this (at least from those who are not entirely bored of this thread)
Definitely!
.hc
mfg.ads.r IOhannes
________________________________________________________________________ ____
"The arc of history bends towards justice." - Dr. Martin Luther King, Jr.
Hans-Christoph Steiner wrote:
On Nov 22, 2005, at 11:39 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
What about alt_0x3c0x3c0x3c_setup()? That would highlight that its an
but this really makes and object called [alt_0x3c0x3c0x3c] impossible!
The setup function would then be alt_alt_0x3c0x3c0x3c_setup(), so it would be possible.
the alternative setup-function of [<<<] is "alt_0x3c0x3c0x3c_setup()" the primary setup function of [alt_0x3c0x3c0x3c] is "alt_0x3c0x3c0x3c_setup()" (the same!) the secondary setup function of [alt_0x3c0x3c0x3c] is "alt_alt_0x3c0x3c0x3c_setup()"
How about sys_load_lib_hex() and hex_blahblah_setup()
i like these names. however, sys_load_lib_alt() does not no anything about the encoding of the alternative classname (whether it is hex or some base62 or whatever)
after rethinking the setup-name, you are probably right. the setup-functions are really only called within the given library-file. so pd will be able to call the correct setup function in the correct library. (i do this so seldomly...) the only important thing is, that the file for [<<<] is NOT called alt_0x3c0x3c0x3c.dll but just 0x3c0x3c0x3c.dll
and finally (just one more rant ;-)) i still don't understand the real drawback of setup_XXX() vs hex_XXX_setup(). imo, this just makes unneccessary typing. in both cases you have to be aware that you are making a non-standard setup-function, and i tend to want to type less than necessary (otoh, i have typed quite a lot on this topic; most likely more than i ever will by using the hex_ prefix)
mfg.gadr IOhannes
On Nov 23, 2005, at 5:10 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
On Nov 22, 2005, at 11:39 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
What about alt_0x3c0x3c0x3c_setup()? That would highlight that its an
but this really makes and object called [alt_0x3c0x3c0x3c] impossible!
The setup function would then be alt_alt_0x3c0x3c0x3c_setup(), so it would be possible.
the alternative setup-function of [<<<] is "alt_0x3c0x3c0x3c_setup()" the primary setup function of [alt_0x3c0x3c0x3c] is "alt_0x3c0x3c0x3c_setup()" (the same!) the secondary setup function of [alt_0x3c0x3c0x3c] is "alt_alt_0x3c0x3c0x3c_setup()"
How about sys_load_lib_hex() and hex_blahblah_setup()
i like these names. however, sys_load_lib_alt() does not no anything about the encoding of the alternative classname (whether it is hex or some base62 or whatever)
after rethinking the setup-name, you are probably right. the setup-functions are really only called within the given library-file. so pd will be able to call the correct setup function in the correct library. (i do this so seldomly...) the only important thing is, that the file for [<<<] is NOT called alt_0x3c0x3c0x3c.dll but just 0x3c0x3c0x3c.dll
and finally (just one more rant ;-)) i still don't understand the real drawback of setup_XXX() vs hex_XXX_setup(). imo, this just makes unneccessary typing. in both cases you have to be aware that you are making a non-standard setup-function, and i tend to want to type less than necessary (otoh, i have typed quite a lot on this topic; most likely more than i ever will by using the hex_ prefix)
How long does it really take you to type 4 characters? Compare that to how long is takes to figure out an arbitrarily defined API. Or how long it takes to debug something because you forgot whether you are supposed to put the setup first or last.
With a good API, you can tell what each function does by its name alone. Looking at these names, what is the difference: setup_receive() vs receive_setup()
.hc
________________________________________________________________________ ____
"If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it." - Thomas Jefferson
Hans-Christoph Steiner wrote:
How long does it really take you to type 4 characters? Compare that to how long is takes to figure out an arbitrarily defined API. Or how long it takes to debug something because you forgot whether you are supposed to put the setup first or last.
the API is of course always arbitrary. just imagine how long it will take you to figure out what goes wrong when you forgot the (arbitrary!) "alt_" (or whatever) prefix. i think it is just the same.
With a good API, you can tell what each function does by its name alone. Looking at these names, what is the difference: setup_receive() vs receive_setup()
i don't know: does "receive_setup()" mean "setup a receive-class" and "setup_receive()" means "receive a setup"? what does this tell us??
mfg.asdr. IOhannes
On Nov 23, 2005, at 11:53 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
How long does it really take you to type 4 characters? Compare that to how long is takes to figure out an arbitrarily defined API. Or how long it takes to debug something because you forgot whether you are supposed to put the setup first or last.
the API is of course always arbitrary. just imagine how long it will take you to figure out what goes wrong when you forgot the (arbitrary!) "alt_" (or whatever) prefix. i think it is just the same.
With a good API, you can tell what each function does by its name alone. Looking at these names, what is the difference: setup_receive() vs receive_setup()
i don't know: does "receive_setup()" mean "setup a receive-class" and "setup_receive()" means "receive a setup"? what does this tell us??
You seem hell bent on winning obfuscated C contest. I prefer readable code. I guess we'll have to agree to disagree.
.hc
________________________________________________________________________ ____
"Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies."
- Amy Smith
Hi all,
What about alt_0x3c0x3c0x3c_setup()? That would highlight that its an
but this really makes and object called [alt_0x3c0x3c0x3c] impossible!
alternate name, rather than just having an seemingly arbitrary reversal of the "setup" placement. And the function is called sys_load_lib_alt(). That makes more sense in terms of the API.
well calling it sys_load_lib_alt() was a very fast decision (so i am not proud of it). i still think that the alternative setup function should be called fundamentally differently, so that it is impossible to make an object with a normal setup-function that is named like the alternative function of another object.
but probably it would be nice to hear somebody else's opinion on this (at least from those who are not entirely bored of this thread)
using my loader patch the naming of the loader function would be irrelevant since it's just including in a chain of loader functions, starting with the classic (now called sys_loader_lib_internal) PD loader.
Concerning the setup function naming - how about xyz_altsetup ? it's true that it should be distinguished from the old naming, but should not have a prefix that excludes some object names.
best greetings, Thomas
Thomas Grill wrote:
using my loader patch the naming of the loader function would be irrelevant since it's just including in a chain of loader functions, starting with the classic (now called sys_loader_lib_internal) PD loader.
so this basically means, we could write an external that provides the character escaping loader (and would not have to patch pd-core)
Concerning the setup function naming - how about xyz_altsetup ? it's true that it should be distinguished from the old naming, but should not have a prefix that excludes some object names.
again the problem with this is, that the current escaping does (for "readability" replace "invalid" characters by "0x??" where "??" is the hex-value of the character. starting a function-name with numbers is generally a bad idea, if you want a compiler to read it. so that's why we thought of a prefix that guarantees a valid indentifier. prefixing "setup_" (which i still think is nice ,-)) would solve both the problem with valid id's and establish a distinct naming scheme (which, as hans pointed out, could also be seen as a problem)
mfg.asd.r IOhannes
IOhannes m zmoelnig schrieb:
Thomas Grill wrote:
using my loader patch the naming of the loader function would be irrelevant since it's just including in a chain of loader functions, starting with the classic (now called sys_loader_lib_internal) PD loader.
so this basically means, we could write an external that provides the character escaping loader (and would not have to patch pd-core)
exactly
Concerning the setup function naming - how about xyz_altsetup ? it's true that it should be distinguished from the old naming, but should not have a prefix that excludes some object names.
again the problem with this is, that the current escaping does (for "readability" replace "invalid" characters by "0x??" where "??" is the hex-value of the character. starting a function-name with numbers is generally a bad idea, if you want a compiler to read it. so that's why we thought of a prefix that guarantees a valid indentifier. prefixing "setup_" (which i still think is nice ,-)) would solve both the problem with valid id's and establish a distinct naming scheme (which, as hans pointed out, could also be seen as a problem)
oh right.... i don't really care about the exact naming scheme
Thomas
-
geiger -
günter geiger
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Thomas Grill