Re: [PD] symbolatom: why does it not allow to type spaces?
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 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 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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list ¡El pueblo unido jamás será vencido! ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbolatom: why does it not allow to type spaces?
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 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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbolatom: why does it not allow to type spaces?
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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbolatom: why does it not allow to type spaces?
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. --- http://mccormick.cx ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbolatom: why does it not allow to type spaces?
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbolatom: why does it not allow to type spaces?
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
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbolatom: why does it not allow to type spaces?
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbolatom: why does it not allow to type spaces?
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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbolatom: why does it not allow to type spaces?
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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbolatom: why does it not allow to type spaces?
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbolatom: why does it not allow to type spaces?
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!
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbolatom: why does it not allow to type spaces?
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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbolatom: why does it not allow to type spaces?
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___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbolatom: why does it not allow to type spaces?
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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbolatom: why does it not allow to type spaces?
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! ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbolatom: why does it not allow to type spaces?
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. --- http://mccormick.cx ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list PGP.sig Description: Signierter Teil der Nachricht ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbolatom: why does it not allow to type spaces?
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. --- http://mccormick.cx ___ 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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbolatom: why does it not allow to type spaces?
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbolatom: why does it not allow to type spaces?
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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbolatom: why does it not allow to type spaces?
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
Re: [PD] symbolatom: why does it not allow to type spaces?
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
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbolatom: why does it not allow to type spaces?
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. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] symbolatom: why does it not allow to type spaces?
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbolatom: why does it not allow to type spaces?
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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbolatom: why does it not allow to type spaces?
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbolatom: why does it not allow to type spaces?
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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbolatom: why does it not allow to type spaces?
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbolatom: why does it not allow to type spaces?
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
