[PD] symbolatom: why does it not allow to type spaces?

Hans-Christoph Steiner hans at eds.org
Mon Dec 17 06:08:45 CET 2007

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  

If a patch doesn't work on desire data and works on Pd or vice versa,  
that's not compatible.


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

More information about the Pd-list mailing list