I found a very strange, very specific bug:
If have text in a comment that has a . in the second position, and a space in the third position, the . is not saved. But if you dynamically generate that comment, the dot is saved.
This is Pd-0.38.4-extended on Mac OS X
.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
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
If have text in a comment that has a . in the second position, and a space in the third position, the . is not saved. But if you dynamically generate that comment, the dot is saved.
This bug works different, however. Every number followed by a dot and a space is affected, however comments starting with a letter and a dot aren't. So this comment is okay:
a. something
but this isn't:
numbers: 1. 2. 3. 4.
Pd converts floating point numbers in comments if possible, so they don't contain floating points anymore.
Ciao
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
Pd converts floating point numbers in comments if possible, so they don't contain floating points anymore.
Or rather: Pd converts floating point numbers in comments as it convert floating point numbers everywhere else, that is, in a comment "10000000" will become "1e+07", too.
Ciao
On Mar 28, 2006, at 3:41 AM, Frank Barknecht wrote:
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
Pd converts floating point numbers in comments if possible, so they don't contain floating points anymore.
Or rather: Pd converts floating point numbers in comments as it convert floating point numbers everywhere else, that is, in a comment "10000000" will become "1e+07", too.
Right... I forgot about this. This is probably related to Pd not having a string type...
.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
On Tue, 28 Mar 2006, Hans-Christoph Steiner wrote:
Right... I forgot about this. This is probably related to Pd not having a string type...
Yeah, comments are parsed by pd exactly like objectboxes. it's just that no actual object is instantiated (binbuf_eval is not called). That was necessary to avoid having to introduce strings in pd and/or making a special case for comments.
For Miller it was important to have a stupid typesystem. Now, if you load 20 abstractions with 20 comments/abstr with 20 words/comment, then you may have up to 20*20*20=8000 new symbols in the symboltable, that have no purpose whatsoever at actual execution.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Mar 28, 2006, at 3:22 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
If have text in a comment that has a . in the second position, and a space in the third position, the . is not saved. But if you dynamically generate that comment, the dot is saved.
This bug works different, however. Every number followed by a dot and a space is affected, however comments starting with a letter and a dot aren't. So this comment is okay:
a. something
but this isn't:
numbers: 1. 2. 3. 4.
Pd converts floating point numbers in comments if possible, so they don't contain floating points anymore.
The weird thing is that if you auto-generate the comment with the 1., then it survives a copy-paste. Try the patch in the bug tracker, if you haven't already.
.hc
________________________________________________________________________ ____
News is what people want to keep hidden and everything else is publicity.
- Bill Moyers
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
The weird thing is that if you auto-generate the comment with the 1., then it survives a copy-paste. Try the patch in the bug tracker, if you haven't already.
Yes, that's indeed a bit weird. But I think, generating comments with internal messages is rather uncommon, most people use messages to only generate objects or data structures, not comments.
Ciao
On Mar 29, 2006, at 3:19 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
The weird thing is that if you auto-generate the comment with the 1., then it survives a copy-paste. Try the patch in the bug tracker, if you haven't already.
Yes, that's indeed a bit weird. But I think, generating comments with internal messages is rather uncommon, most people use messages to only generate objects or data structures, not comments.
Yeah, I am not saying that's the problem, I am just saying that it highlights some bizarre behavior...
.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
On Wed, 29 Mar 2006, Hans-Christoph Steiner wrote:
The weird thing is that if you auto-generate the comment with the 1., then it survives a copy-paste. Try the patch in the bug tracker, if you haven't already.
It's because you make it as a single symbol. In Pd, gensym() can turn any null-terminated string into a symbol. When you copy+paste, the contents of the comment don't change, they point to the same symbol. When you save to a file, however, it gets printed without quoting, because quoting is not supported (or not fully), so for a lot of possible symbols there's no syntax that you can use to produce them literally, you have to go thru gensym() explicitly instead (e.g. [sprintf]).
Copy+paste only copies a t_atom[] whereas saving/loading calls binbuf_save/binbuf_eval.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
-
Frank Barknecht -
Hans-Christoph Steiner -
Mathieu Bouchard