hi
why does the symbolatom not allow the user to enter spaces? or in other words: why is there a restriction, if it can be circumvented by using [makefilename]? people do it anyway, so why prohibit it in the first place?
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Mon, 10 Dec 2007, Roman Haefeli wrote:
why does the symbolatom not allow the user to enter spaces? or in other words: why is there a restriction, if it can be circumvented by using [makefilename]? people do it anyway, so why prohibit it in the first place?
I don't know. In DesireData, if I connect a symbolbox to a [print], and type something, I get something like this in the console:
print: symbol real\ people\ want\ to\ use\ spaces!
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Mon, 2007-12-10 at 15:03 -0500, Mathieu Bouchard wrote:
print: symbol real\ people\ want\ to\ use\ spaces!
definitely. the first question i hear from people using netpd/pd the first time is: 'how can i type spaces?' yet i decided to not add another dependency for netpd just because of this rather silly restriction. but since it seems, that the lack of spaces is really troubling users, i am unsure, whether i should change that policy. since one can even open a file containing spaces in the path from pd, it would actually make sense, if symbolatom would support that. i can't think of a case, where supporting spaces would break anything (or am i overseeing something?). before i change my policy about using externals in netpd, i would like to ask (probably miller?), if there is a chance, that symbolatom is changed accordingly in the future?
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Mon, 10 Dec 2007, Roman Haefeli wrote:
since one can even open a file containing spaces in the path from pd, it would actually make sense, if symbolatom would support that. i can't think of a case, where supporting spaces would break anything (or am i overseeing something?).
It would only break externals that rely on lack of spaces in any way, and only if supposing that you weren't already using some other way of producing the spaces.
about spaces, those that break are: [netsend], [print], [textfile], ... anything using atom_string().
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Mon, 2007-12-10 at 16:34 -0500, Mathieu Bouchard wrote:
On Mon, 10 Dec 2007, Roman Haefeli wrote: (or am i
overseeing something?).
It would only break externals that rely on lack of spaces in any way, and only if supposing that you weren't already using some other way of producing the spaces.
about spaces, those that break are: [netsend], [print], [textfile], ... anything using atom_string().
ah, yes i am overseeing. thank you for mentioning them. to be added: labels in iemguis, when saved.
but these are things that already would break now and it is possible to create symbols containing spaces in pd, it's just not as easy as just using a symbolbox. fact is, that people do it anyway, so why trying to prevent them?
i didn't know that [print] would be affected. in what way is it affected? at least visually it doesn't seem to be.
i encounter that ' ' is treated in a non-comprehensibly special way, since other characters such as ';' or ',' are escaped by symbolatom (or by pd, i don't know) and can be used, atltough they have a meaning in pd as well (like 'space' has). wouldn't it be more consistent, if ' ', ',' and ';' would be treated the same way?
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Dec 10, 2007, at 6:48 PM, Roman Haefeli wrote:
On Mon, 2007-12-10 at 16:34 -0500, Mathieu Bouchard wrote:
On Mon, 10 Dec 2007, Roman Haefeli wrote: (or am i
overseeing something?).
It would only break externals that rely on lack of spaces in any
way, and only if supposing that you weren't already using some other way of producing the spaces.about spaces, those that break are: [netsend], [print],
[textfile], ... anything using atom_string().ah, yes i am overseeing. thank you for mentioning them. to be added: labels in iemguis, when saved.
but these are things that already would break now and it is
possible to create symbols containing spaces in pd, it's just not as easy as just using a symbolbox. fact is, that people do it anyway, so why trying to prevent them?i didn't know that [print] would be affected. in what way is it affected? at least visually it doesn't seem to be.
i encounter that ' ' is treated in a non-comprehensibly special way, since other characters such as ';' or ',' are escaped by symbolatom
(or by pd, i don't know) and can be used, atltough they have a meaning
in pd as well (like 'space' has). wouldn't it be more consistent, if ' ',
',' and ';' would be treated the same way?
A simple fix for allowing spaces is making the label be based on a
list rather than a symbol. This is what I am doing tkwidgets. But
for the iemguis, I'm not sure it would work since it might break
backwards compatibility.
.hc
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http:// messenger.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
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
On Mon, 10 Dec 2007, Hans-Christoph Steiner wrote:
A simple fix for allowing spaces is making the label be based on a list rather than a symbol.
So, how do you put a label inside of an argument list, if you can't know where it ends? And how do you put multiple spaces in a row?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Dec 11, 2007, at 3:33 PM, Mathieu Bouchard wrote:
On Mon, 10 Dec 2007, Hans-Christoph Steiner wrote:
A simple fix for allowing spaces is making the label be based on a
list rather than a symbol.So, how do you put a label inside of an argument list, if you can't
know where it ends? And how do you put multiple spaces in a row?
Simple answer: you don't put labels as arguments.
Full answer: you use the tcl flags to save the arguments. This works
fine in binbufs:
-text "this is my label" -font "Lucida Sans" 10 bold -fg black -bg green
Check tkwidgets/text.c for more info.
.hc
I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits. - Martin
Luther King, Jr.
On Wed, 12 Dec 2007, Hans-Christoph Steiner wrote:
Full answer: you use the tcl flags to save the arguments. This works fine in binbufs: -text "this is my label" -font "Lucida Sans" 10 bold -fg black -bg green Check tkwidgets/text.c for more info.
so, how do you put double-quotes within labels?
how do you put a literal dollarsign within labels?
what about open-bracket?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Dec 13, 2007, at 1:00 PM, Mathieu Bouchard wrote:
On Wed, 12 Dec 2007, Hans-Christoph Steiner wrote:
Full answer: you use the tcl flags to save the arguments. This
works fine in binbufs: -text "this is my label" -font "Lucida Sans" 10 bold -fg black -bg
green Check tkwidgets/text.c for more info.so, how do you put double-quotes within labels?
I should correct the above line, it's not quite right:
-text {this is my label} -font {"Lucida Sans" 10 bold} -fg black -bg
green
AFAIK, using the {} as quotes means it should had over everything
inside of those brackets. So {"} should show a double quote. If you
look at the code in externals/tkwidgets/text.c, you'll see I am just
letting Tcl format the strings using "text cget -text", then writing
that to a file via a binbuf.
how do you put a literal dollarsign within labels?
Donno, any suggestions?
what about open-bracket?
This one has stumped me, and I've asked a bit in #tcl, but no luck.
Any suggestions? Did you get it working? What is actually more
important, IMHO, is a way to insert a open-bracket into a text widget
using a message. Using [key 123( then lots of escaping in C hasn't
worked for me either.
.hc
¡El pueblo unido jamás será vencido!
On Thu, 13 Dec 2007, Hans-Christoph Steiner wrote:
I should correct the above line, it's not quite right: -text {this is my label} -font {"Lucida Sans" 10 bold} -fg black -bg green
AFAIK, using the {} as quotes means it should had over everything inside of those brackets. So {"} should show a double quote.
You can also backslash double-quotes instead.
how do you put a literal dollarsign within labels?
Donno, any suggestions?
backslash it!
what about open-bracket?
This one has stumped me, and I've asked a bit in #tcl, but no luck.
backslash it!
suggestions? Did you get it working? What is actually more important, IMHO, is a way to insert a open-bracket into a text widget using a message. Using [key 123( then lots of escaping in C hasn't worked for me either.
123 is not a bracket, it's a brace. But for either the solution is the same: backslash it!
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Dec 13, 2007, at 2:25 PM, Mathieu Bouchard wrote:
On Thu, 13 Dec 2007, Hans-Christoph Steiner wrote:
I should correct the above line, it's not quite right: -text {this is my label} -font {"Lucida Sans" 10 bold} -fg black - bg green
AFAIK, using the {} as quotes means it should had over everything
inside of those brackets. So {"} should show a double quote.You can also backslash double-quotes instead.
how do you put a literal dollarsign within labels?
Donno, any suggestions?
backslash it!
Pd doesn't support backslashes.
what about open-bracket?
This one has stumped me, and I've asked a bit in #tcl, but no luck.
backslash it!
If it was just a backslash, do you think I'd be asking?
suggestions? Did you get it working? What is actually more
important, IMHO, is a way to insert a open-bracket into a text
widget using a message. Using [key 123( then lots of escaping in
C hasn't worked for me either.123 is not a bracket, it's a brace. But for either the solution is
the same: backslash it!
Sorry, brackets "[]" work fine, and close curly bracket "}" works
fine, but I can't figure out how to send a open curly bracket "{" to
the text widget from Pd. And no, backslashes don't work.
.hc
kill your television
On Fri, 14 Dec 2007, Hans-Christoph Steiner wrote:
how do you put a literal dollarsign within labels?
Donno, any suggestions?
backslash it!
Pd doesn't support backslashes.
Because you have to make it support backslashes first.
what about open-bracket?
This one has stumped me, and I've asked a bit in #tcl, but no luck.
backslash it!
If it was just a backslash, do you think I'd be asking?
I don't know what's going in your mind. With what you just said, I'm sort of surprise that you don't just say again that Pd doesn't support backslashes.
The other bug is in t_tkcmd.c, because there Miller wrote in 656 lines of C what takes ~10 lines in pure Tcl, including trying to preemptively parse Tcl commands instead of asking Tcl to do it, and getting it wrong whenever braces are backslashed.
123 is not a bracket, it's a brace. But for either the solution is the same: backslash it!
Sorry, brackets "[]" work fine
In your original question I believe you said that you were using doublequotes, in which case [] need backslashes. They don't need them when inside braces.
and close curly bracket "}" works fine
I expect close-brace (as it is normally called) to fail at least sometimes, in the process of backslashing it, when using t_tkcmd.c, using certain combinations of backslashed and non-backslashed braces, but I'm not sure. I won't try it, but as long as you wish to keep using t_tkcmd.c, you will have to think about this.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Tue, Dec 18, 2007 at 06:32:00PM -0500, Mathieu Bouchard wrote:
The other bug is in t_tkcmd.c, because there Miller wrote in 656 lines of C what takes ~10 lines in pure Tcl, including trying to preemptively parse Tcl commands instead of asking Tcl to do it, and getting it wrong whenever braces are backslashed.
Hi Matju,
I am curious as to whether you have ever discussed this with Miller, or submitted a nice clean atomic patch to fix it and see if he accepts it into his version? Is it in the bug tracker anywhere? Or is the fix available in Desire Data for Miller to pull into his own version if he wants?
Not criticising you at all, just curious about whether we can make Pd development more constructive than it has been in the past. It would be wonderful to see some of your hard work get into Miller's Pd since that's the one I like to use the most. I know that you have been frustrated by this in the past, but my intentions are to have better software, not to annoy you.
Best,
Chris.
On Tue, 18 Dec 2007, Chris McCormick wrote:
On Tue, Dec 18, 2007 at 06:32:00PM -0500, Mathieu Bouchard wrote:
The other bug is in t_tkcmd.c, because there Miller wrote in 656 lines of C what takes ~10 lines in pure Tcl, including trying to preemptively parse Tcl commands instead of asking Tcl to do it, and getting it wrong whenever braces are backslashed.
I am curious as to whether you have ever discussed this with Miller,
Perhaps, perhaps not, I don't remember and it does not matter.
or submitted a nice clean atomic patch to fix it and see if he accepts it into his version?
You know that I haven't, you don't need to ask. I can't write nice and clean patches anyway.
Is it in the bug tracker anywhere?
I can't make my 6666 interdependent changes all into nice and clean atomic patches. It would take forever. You haven't thought about the logistics of it and then you think that it would really work. The diff submission process doesn't upscale.
Or is the fix available in Desire Data for Miller to pull into his own version if he wants?
Since when does Miller do that?...
Not criticising you at all,
Oh, you could do it all you like.
just curious about whether we can make Pd development more constructive than it has been in the past.
Then maybe you could look in the past and see what people said when they were thinking about how to make Pd development more constructive than it was in the past of that past.
It would be wonderful to see some of your hard work get into Miller's Pd
Lol.
I know that you have been frustrated by this in the past,
Yeah, but the past is the past, and nowadays I'm much more at peace with the facts, and I just understand that you're going to be frustrated in the future.
but my intentions are to have better software, not to annoy you.
It's ok.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Dec 19, 2007, at 1:17 AM, Mathieu Bouchard wrote:
On Tue, 18 Dec 2007, Chris McCormick wrote:
On Tue, Dec 18, 2007 at 06:32:00PM -0500, Mathieu Bouchard wrote:
The other bug is in t_tkcmd.c, because there Miller wrote in 656
lines of C what takes ~10 lines in pure Tcl, including trying to
preemptively parse Tcl commands instead of asking Tcl to do it, and getting it wrong
whenever braces are backslashed.I am curious as to whether you have ever discussed this with Miller,
Perhaps, perhaps not, I don't remember and it does not matter.
or submitted a nice clean atomic patch to fix it and see if he
accepts it into his version?You know that I haven't, you don't need to ask. I can't write nice
and clean patches anyway.Is it in the bug tracker anywhere?
I can't make my 6666 interdependent changes all into nice and clean
atomic patches. It would take forever. You haven't thought about
the logistics of it and then you think that it would really work.
The diff submission process doesn't upscale.
But you could submit some key ones, and they would be greatly
appreciated additions to Pd.
.hc
Or is the fix available in Desire Data for Miller to pull into his
own version if he wants?Since when does Miller do that?...
Not criticising you at all,
Oh, you could do it all you like.
just curious about whether we can make Pd development more
constructive than it has been in the past.Then maybe you could look in the past and see what people said when
they were thinking about how to make Pd development more
constructive than it was in the past of that past.It would be wonderful to see some of your hard work get into
Miller's PdLol.
I know that you have been frustrated by this in the past,
Yeah, but the past is the past, and nowadays I'm much more at peace
with the facts, and I just understand that you're going to be
frustrated in the future.but my intentions are to have better software, not to annoy you.
It's ok.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC
Canada_______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
¡El pueblo unido jamás será vencido!
On Tue, 11 Dec 2007, Roman Haefeli wrote:
ah, yes i am overseeing. thank you for mentioning them. to be added: labels in iemguis, when saved.
I just made this movie of it:
http://artengine.ca/desiredata/gallery/iemgui_labels.mpeg
DesireData will save them correctly because it uses the same code for sending to the GUI as for writing to a file. It also calls the same method for updating properties as is now used by the object creator to load an iemgui from a file.
but these are things that already would break now and it is possible to create symbols containing spaces in pd,
You could call those objects broken and adding this "feature" might amount to a bug fix. I don't know who would actually use this bug as a feature, but you can bet someone thought it could be a cool way to split a symbol into a list. ;)
it's just not as easy as just using a symbolbox. fact is, that people do it anyway, so why trying to prevent them?
Why? so that the implementation doesn't have to be changed. That way no-one has to go back on whatever they have said about pd not being for string processing.
i didn't know that [print] would be affected. in what way is it affected? at least visually it doesn't seem to be.
It adds backslashes which are not part of the symbol, because that's what's accepted by any version of pd as a way to have spaces within symbols. Any version of pd will load such symbols correctly, stripping the backslashes (unless you have double-backslashes, of course).
i encounter that ' ' is treated in a non-comprehensibly special way, since other characters such as ';' or ',' are escaped by symbolatom (or by pd, i don't know)
Symbolatom incorrectly backslashes those characters when printing them. Because it should display a symbol's content as-is, those backslashes should have been stripped on the way out. It has the opposite problem of [print]. [print] can print any number of atoms of different types, so it has to be printed in a way that atom boundaries are clear and that floats are distinguishable from symbols, which is why it shares some code with the way files are saved, and which is why it shares the same bug.
DesireData's symbolbox works correctly for semicolons commas and spaces, but has a bug with {} characters. This can happen because a symbolbox's value is not saved to file, so it has to upload it to the client another way than using the save function, and the bug is in that special code.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
It's nice to add those features, but by adding them to the pd-vanilla
objects, that means patches written in desiredata are not compatible
with pd-vanilla.
It seems a better solution would be to add new desiredata objects,
then keep the iemguis compatible.
.hc
On Dec 11, 2007, at 3:32 PM, Mathieu Bouchard wrote:
On Tue, 11 Dec 2007, Roman Haefeli wrote:
ah, yes i am overseeing. thank you for mentioning them. to be added: labels in iemguis, when saved.
I just made this movie of it:
http://artengine.ca/desiredata/gallery/iemgui_labels.mpeg
DesireData will save them correctly because it uses the same code
for sending to the GUI as for writing to a file. It also calls the
same method for updating properties as is now used by the object
creator to load an iemgui from a file.but these are things that already would break now and it is
possible to create symbols containing spaces in pd,You could call those objects broken and adding this "feature" might
amount to a bug fix. I don't know who would actually use this bug
as a feature, but you can bet someone thought it could be a cool
way to split a symbol into a list. ;)it's just not as easy as just using a symbolbox. fact is, that
people do it anyway, so why trying to prevent them?Why? so that the implementation doesn't have to be changed. That
way no-one has to go back on whatever they have said about pd not
being for string processing.i didn't know that [print] would be affected. in what way is it affected? at least visually it doesn't seem to be.
It adds backslashes which are not part of the symbol, because
that's what's accepted by any version of pd as a way to have spaces
within symbols. Any version of pd will load such symbols correctly,
stripping the backslashes (unless you have double-backslashes, of
course).i encounter that ' ' is treated in a non-comprehensibly special way, since other characters such as ';' or ',' are escaped by
symbolatom (or by pd, i don't know)Symbolatom incorrectly backslashes those characters when printing
them. Because it should display a symbol's content as-is, those
backslashes should have been stripped on the way out. It has the
opposite problem of [print]. [print] can print any number of atoms
of different types, so it has to be printed in a way that atom
boundaries are clear and that floats are distinguishable from
symbols, which is why it shares some code with the way files are
saved, and which is why it shares the same bug.DesireData's symbolbox works correctly for semicolons commas and
spaces, but has a bug with {} characters. This can happen because
a symbolbox's value is not saved to file, so it has to upload it to
the client another way than using the save function, and the bug is
in that special code._ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC
Canada_______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers
On Wed, 12 Dec 2007, Hans-Christoph Steiner wrote:
It's nice to add those features, but by adding them to the pd-vanilla objects, that means patches written in desiredata are not compatible with pd-vanilla.
No, pd-vanilla loads them fine, the patches are compatible. It's just about bugs that you don't consider to be bugs. A bug is a bug is a bug, and I consider the compatibility issue with bugs to be moot, because the bug is the fault of the software that has the bug in it, it's not the fault of the rest of the planet.
It's Pd's fault for both looking like it supports spaces in symbols using backslashes and then not supporting them properly. I don't care about your sustained bias in favour of Miller's bugs as if they were features to be supported.
It seems a better solution would be to add new desiredata objects, then keep the iemguis compatible.
It makes patches even less compatible because then *any* patches using the new objects are not compatible at all, and people have to choose between old vs new objects. Aren't you tired of choosing between floatatom and [nbx] ? why shouldn't everybody else be tired of it already? You want more of that crap? You want 10 times more of that crap, for all iemguis?
It's not the first time you suggest things like that. I will not provide new object classes when I can extend existing ones in "logical" ways. I understand what is the Liskov substitution principle and I apply it to the evolution of classes across versions. Either you don't understand it or you spit on it, and either way, I can't approve you.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
This is purely a practical issue. If your patches don't work across
Pd and Desiredata, then they are not compatible. It's that simple.
Compatibility is one goal that can get in the way of fixing bugs.
Why not just write separate bugfree versions and leave the existing
names to be compatible objects? Basically, unless desiredata is
compatible, it not very useful to Pd users.
.hc
On Dec 12, 2007, at 7:39 PM, Mathieu Bouchard wrote:
On Wed, 12 Dec 2007, Hans-Christoph Steiner wrote:
It's nice to add those features, but by adding them to the pd- vanilla objects, that means patches written in desiredata are not
compatible with pd-vanilla.No, pd-vanilla loads them fine, the patches are compatible. It's
just about bugs that you don't consider to be bugs. A bug is a bug
is a bug, and I consider the compatibility issue with bugs to be
moot, because the bug is the fault of the software that has the bug
in it, it's not the fault of the rest of the planet.It's Pd's fault for both looking like it supports spaces in symbols
using backslashes and then not supporting them properly. I don't
care about your sustained bias in favour of Miller's bugs as if
they were features to be supported.It seems a better solution would be to add new desiredata objects,
then keep the iemguis compatible.It makes patches even less compatible because then *any* patches
using the new objects are not compatible at all, and people have to
choose between old vs new objects. Aren't you tired of choosing
between floatatom and [nbx] ? why shouldn't everybody else be tired
of it already? You want more of that crap? You want 10 times more
of that crap, for all iemguis?It's not the first time you suggest things like that. I will not
provide new object classes when I can extend existing ones in
"logical" ways. I understand what is the Liskov substitution
principle and I apply it to the evolution of classes across
versions. Either you don't understand it or you spit on it, and
either way, I can't approve you._ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
¡El pueblo unido jamás será vencido!
On Wed, 12 Dec 2007, Hans-Christoph Steiner wrote:
This is purely a practical issue. If your patches don't work across Pd and Desiredata, then they are not compatible. It's that simple. Compatibility is one goal that can get in the way of fixing bugs. Why not just write separate bugfree versions and leave the existing names to be compatible objects? Basically, unless desiredata is compatible, it not very useful to Pd users.
It's not my job to force you to figure out what's the trouble that you want me to get into.
If you don't even look like you've read what I write and just restate the same thing, it's not communication.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Dec 13, 2007, at 12:58 PM, Mathieu Bouchard wrote:
On Wed, 12 Dec 2007, Hans-Christoph Steiner wrote:
This is purely a practical issue. If your patches don't work
across Pd and Desiredata, then they are not compatible. It's that
simple. Compatibility is one goal that can get in the way of
fixing bugs. Why not just write separate bugfree versions and
leave the existing names to be compatible objects? Basically,
unless desiredata is compatible, it not very useful to Pd users.It's not my job to force you to figure out what's the trouble that
you want me to get into.If you don't even look like you've read what I write and just
restate the same thing, it's not communication.
In the past you have said that you want to make DesireData compatible
with Pd. I am pointing out a possible incompatibility. If you don't
want to make it compatible, that is your choice.
.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
On Thu, 13 Dec 2007, Hans-Christoph Steiner wrote:
In the past you have said that you want to make DesireData compatible with Pd.
Yes, I want it!
I am pointing out a possible incompatibility.
You don't even know what compatibility is!
If you don't want to make it compatible, that is your choice.
I choose compatibility! This is why I don't want to do it your way!
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Wed, 2007-12-12 at 19:39 -0500, Mathieu Bouchard wrote:
On Wed, 12 Dec 2007, Hans-Christoph Steiner wrote:
It's nice to add those features, but by adding them to the pd-vanilla objects, that means patches written in desiredata are not compatible with pd-vanilla.
No, pd-vanilla loads them fine, the patches are compatible. It's just about bugs that you don't consider to be bugs. A bug is a bug is a bug, and I consider the compatibility issue with bugs to be moot, because the bug is the fault of the software that has the bug in it, it's not the fault of the rest of the planet.
when i learned pd, i didn't know any other progamming language, thus i just accepted the little 'inconveniences' of pd. i just assumed, there is a real reason for not having spaces in symbols, that i might not know. after having constructed symbols with spaces ten thousand times using [32(-[makefilename %c]-[list-l2s] constructs, i start to think about if there might be a good reason, that i have to do so. and i couldn't find one. i personally think, it is the wrong way to workaround such issues by - for example - allowing the 'label' message for iemguis to carry lists instead of symbols. why doing all that effort, for a solution, that is just an ugly hack, doesn't solve the original problem and, for me the most important point, doesn't stop people from asking, why symbolatom cannot create spaces.
in this respect i might have a 180° different opinion from yours, hans. i'd rather keep a silly thing like lacking space in symbolbox obvious, until it is fixed once forever, so that people stay aware of this bug, rather than workaround it. the workaround is a) more work (i assume) and hides the real problem. i didn't follow the psql very closely, but if i am not totally mistaken a lot of the discussion was about how to create proper sql syntax with pd's limited character set. iirc, this was not first discussion about this kind of issue in this list, and it won't be the last one. whenever someone writes an externals, that deals with a syntax that doesn't match pd's character set, a new solution has to be found -> a lot of discussion -> a lot of programmig effort to overcome the problem -> a lot of work to maintain the code -> similar code is written several times instead of only once -> probably different strategies are used to workaround the problem -> consistency problems, etc..... why not just simply fix it in pd? by 'simply' i don't want to say, that fix is a simple one (i actually don't have a clue about its level of difficulty), but it's the only and the one and logical solution. lets face the reality: people do not just use pd anymore to load some soundfiles with a symbol, they use also symbols and lists of symbols to talk http, displaying telugu characters with gem, sending blobs to a database etc. i highly doubt, that you (hans) fixing/workaround problems that are not solved in the first place (by miller) is the way to go. in the name of the church of consistency i claim the practice of fixing problems at the most low level stage as possible as the only meaningful one.
yo, that said, i'll go writing a bug report.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Yes, we should fix bugs in Pd. I am not saying that. All I am
saying is that Desire Data intends to remain compatible with Pd, then
it will have to be compatible with things that some people consider
bugs.
If a patch doesn't work on desire data and works on Pd or vice versa,
that's not compatible.
.hc
On Dec 15, 2007, at 12:10 AM, Roman Haefeli wrote:
On Wed, 2007-12-12 at 19:39 -0500, Mathieu Bouchard wrote:
On Wed, 12 Dec 2007, Hans-Christoph Steiner wrote:
It's nice to add those features, but by adding them to the pd- vanilla objects, that means patches written in desiredata are not
compatible with pd-vanilla.No, pd-vanilla loads them fine, the patches are compatible. It's just about bugs that you don't consider to be bugs. A bug is a bug is a
bug, and I consider the compatibility issue with bugs to be moot,
because the bug is the fault of the software that has the bug in it, it's not the fault of the rest of the planet.when i learned pd, i didn't know any other progamming language, thus i just accepted the little 'inconveniences' of pd. i just assumed, there is a real reason for not having spaces in symbols, that i might not know. after having constructed symbols with spaces ten thousand times using [32(-[makefilename %c]-[list-l2s] constructs, i start to think about if there might be a good reason, that i have to do so. and i couldn't find one. i personally think, it is the wrong way to
workaround such issues by - for example - allowing the 'label' message for
iemguis to carry lists instead of symbols. why doing all that effort, for a solution, that is just an ugly hack, doesn't solve the original
problem and, for me the most important point, doesn't stop people from asking, why symbolatom cannot create spaces.in this respect i might have a 180° different opinion from yours,
hans. i'd rather keep a silly thing like lacking space in symbolbox obvious, until it is fixed once forever, so that people stay aware of this bug, rather than workaround it. the workaround is a) more work (i
assume) and hides the real problem. i didn't follow the psql very closely, but
if i am not totally mistaken a lot of the discussion was about how to
create proper sql syntax with pd's limited character set. iirc, this was not first discussion about this kind of issue in this list, and it
won't be the last one. whenever someone writes an externals, that deals with a syntax that doesn't match pd's character set, a new solution has to be found -> a lot of discussion -> a lot of programmig effort to overcome the problem -> a lot of work to maintain the code -> similar code is written several times instead of only once -> probably different strategies are used to workaround the problem -> consistency problems, etc..... why not just simply fix it in pd? by 'simply' i don't
want to say, that fix is a simple one (i actually don't have a clue about its level of difficulty), but it's the only and the one and logical solution. lets face the reality: people do not just use pd anymore to load some soundfiles with a symbol, they use also symbols and lists of symbols to talk http, displaying telugu characters with gem, sending blobs to a database etc. i highly doubt, that you (hans) fixing/workaround problems that are not solved in the first place (by miller) is the way to go. in the name of the church of consistency i claim the practice of fixing problems at the most low level stage as possible as the only meaningful one.yo, that said, i'll go writing a bug report.
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http:// messenger.yahoo.de
There is no way to peace, peace is the way. -A.J. Muste
On Mon, 17 Dec 2007, Hans-Christoph Steiner wrote:
Yes, we should fix bugs in Pd. I am not saying that. All I am saying is that Desire Data intends to remain compatible with Pd, then it will have to be compatible with things that some people consider bugs. If a patch doesn't work on desire data and works on Pd or vice versa, that's not compatible.
No, what you are saying has the logical consequence is that you want to keep the bugs in pd and introduce new workarounds that each person will have to explicitly use whenever they want to use the non-buggy behaviour. You can't both fix bugs and not fix them. You have already asked me to make workarounds for bugs that _no-one_ ever relies on, and this is because of such a request that we are still talking about this now.
*Please* stop kidding me and most of all *please* stop kidding yourself.
It's for the good of pd-extended and of all things pd.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Dec 10, 2007, at 3:25 PM, Roman Haefeli wrote:
On Mon, 2007-12-10 at 15:03 -0500, Mathieu Bouchard wrote:
print: symbol real\ people\ want\ to\ use\ spaces!
definitely. the first question i hear from people using netpd/pd the first time is: 'how can i type spaces?' yet i decided to not add
another dependency for netpd just because of this rather silly restriction.
but since it seems, that the lack of spaces is really troubling users,
i am unsure, whether i should change that policy.
I think it would be awesome to have a real IRC or Jabber client in Pd
and use it in netpd. That's why I am writing the tkwidgets library,
so that we can have nice, familiar, OS-native widgets in Pd. netpd's
chat would be a great test case for the new [entry], which isn't
written yet, but wouldn't take long. You could try [tkwidgets/text]
it works pretty well now, and is quite customizable (there is still a
couple bugs tho).
.hc
since one can even open a file containing spaces in the path from
pd, it would actually make sense, if symbolatom would support that. i can't think of a case, where supporting spaces would break anything (or am i overseeing something?). before i change my policy about using externals in netpd, i would like to ask (probably miller?), if there is a chance, that symbolatom is changed accordingly in the future?roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http:// messenger.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
I spent 33 years and four months in active military service and
during that period I spent most of my time as a high class muscle man
for Big Business, for Wall Street and the bankers. - General
Smedley Butler
On Mon, Dec 10, 2007 at 09:25:56PM +0100, Roman Haefeli wrote:
before i change my policy about using externals in netpd, i would like to ask (probably miller?), if there is a chance, that symbolatom is changed accordingly in the future?
When I asked about spaces in symbols on the pd-dev list Miller's reply was: "1. spaces in symbols are a parsing/formatting problem, not a data type problem." So that would indicate that he sees it as a problem that must be fixed. Be good if someone could submit a nice clean patch to fix the parsing problem and see if he accepts it.
Another similar reply to the issue of symbol table saturation was "2. use arrays as strings as I proposed;" which isn't currently possible in your use-case because the symbol input box itself won't let you input spaces to even get them into an array.
Best,
Chris.
if the situation with the symbolatom doesn't change i'd like to make
a workaround where preferably [entry] is used, but if not available
it will fall back to the symbol atom. is it possible to detect
somehow if entry is loaded sucessfuly?
max
Am 11.12.2007 um 04:09 schrieb Chris McCormick:
On Mon, Dec 10, 2007 at 09:25:56PM +0100, Roman Haefeli wrote:
before i change my policy about using externals in netpd, i would
like to ask (probably miller?), if there is a chance, that symbolatom is changed accordingly in the future?When I asked about spaces in symbols on the pd-dev list Miller's reply was: "1. spaces in symbols are a parsing/formatting problem, not a
data type problem." So that would indicate that he sees it as a problem
that must be fixed. Be good if someone could submit a nice clean patch to fix the parsing problem and see if he accepts it.Another similar reply to the issue of symbol table saturation was
"2. use arrays as strings as I proposed;" which isn't currently possible in
your use-case because the symbol input box itself won't let you input
spaces to even get them into an array.Best,
Chris.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
You could use [hcs/version], if you don't get a response after a
bang, it's probably not loaded. Currently, that object only exists
in Pd-extended, unless someone compiles it themself, so no response
would mean not pd-extended, and therefore most likely won't have entry.
You might try [tkwidgets/text], it's a much enhanced version of Ben's
[entry]. It has some bugs but I want to find them and fix them now,
so bug reports would be much appreciated.
Also, I plan on making an object out of Tk's entry ([entry] is
actually based on Tk's text). Tk's entry is a one line text widget
meant for data entry.
.hc
On Dec 11, 2007, at 11:22 AM, Max Neupert wrote:
if the situation with the symbolatom doesn't change i'd like to
make a workaround where preferably [entry] is used, but if not
available it will fall back to the symbol atom. is it possible to
detect somehow if entry is loaded sucessfuly?max
Am 11.12.2007 um 04:09 schrieb Chris McCormick:
On Mon, Dec 10, 2007 at 09:25:56PM +0100, Roman Haefeli wrote:
before i change my policy about using externals in netpd, i would
like to ask (probably miller?), if there is a chance, that symbolatom is changed accordingly in the future?When I asked about spaces in symbols on the pd-dev list Miller's
reply was: "1. spaces in symbols are a parsing/formatting problem, not a
data type problem." So that would indicate that he sees it as a problem
that must be fixed. Be good if someone could submit a nice clean patch to fix the parsing problem and see if he accepts it.Another similar reply to the issue of symbol table saturation was
"2. use arrays as strings as I proposed;" which isn't currently possible
in your use-case because the symbol input box itself won't let you input
spaces to even get them into an array.Best,
Chris.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra
On Tue, 2007-12-11 at 13:53 -0500, Hans-Christoph Steiner wrote:
You could use [hcs/version], if you don't get a response after a
bang, it's probably not loaded.
interesting approach. but this would still cause an error, when [hcs/version] cannot be found, right?
it's kind of bad practice to introduce 'expectable' errors. that is something that annoys me personally the most about netpd right now. errors should really only appear, when they mean something.
Also, I plan on making an object out of Tk's entry ([entry] is
actually based on Tk's text). Tk's entry is a one line text widget
meant for data entry.
mhm.... sounds promising...;-)
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
-
Chris McCormick -
Hans-Christoph Steiner -
Mathieu Bouchard -
Max Neupert -
Roman Haefeli