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