[PD-dev] [ pure-data-Bugs-1459776 ] weird bug: dot in comment disappears

SourceForge.net noreply at sourceforge.net
Fri May 9 21:15:06 CEST 2008


Bugs item #1459776, was opened at 2006-03-28 00:10
Message generated for change (Settings changed) made by eighthave
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1459776&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: Later
Priority: 5
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Nobody/Anonymous (nobody)
Summary: weird bug: dot in comment disappears

Initial Comment:
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 and Miller's 0.39-2 on Mac OS X.


----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2006-03-30 20:44

Message:
Logged In: YES 
user_id=27104



>From Matju:

> 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.


----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2006-03-30 20:43

Message:
Logged In: YES 
user_id=27104

from Matju:

> 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.


----------------------------------------------------------------------

Comment By: Frank Barknecht (fbar)
Date: 2006-03-28 03:23

Message:
Logged In: YES 
user_id=569446

This bug works differently, 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.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1459776&group_id=55736




More information about the Pd-dev mailing list