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 _______________________________________________ PD-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
