[PD] Bug in lister (zexy) ?
IOhannes m zmoelnig
zmoelnig at iem.at
Tue Oct 2 08:46:48 CEST 2007
Cyrille.Damez at laposte.net wrote:
> On Monday 01 October 2007 15:36:02 IOhannes m zmoelnig wrote:
>> appreciating that you found a bug in [lister] (which has been around for
>> quite a while and i do believe it was useful and used), i cannot follow
>> your arguing:
>> though shalt not use aliases for buggy objects
>> though shalt not use 1-character names for buggy objects
>> though shalt rename buggy objects to [buggy_<objectname>]
>> though shalt not use buggy objects
>> though shalt not write buggy objects
>>
>> not much left to use then...
>
> Did I write anything that could be interpreted as offensive ? If yes I'm
> sorry.
no no.
i was just saying that your consequence from a buggy object was a bit
too much for my taste.
> I'm not blaming anybody for the (arguably small) issue at hand, we were just
> discussing the reasons why one would expect certain objects to have shortcuts
> or not. Of course "bugginess" can't be a criterion as nobody knows a priori
> whether if his code is 100% error-proof (and nobody can honestly guarantee to
> write bug-free code).
right, that is what i was trying to say.
> However, in this particular case, since we know there
> are a couple issues with [lister]
how many issues do you have with lister. in all the years of its
existance, i remember exactly 3 bugs filed at the sf tracker:
- sending data to the 2nd inlet while the outlet is still sending
corrupts the output.
- the help file speaks of "a nonexistant [list] object"
- the object shouldn't be abbreviated [l]
and then there is another "bug" which has not been filed to the tracker yet:
- [lister] can be replaced by [list append]
so we have 4 issues, and honestly all but the first ones are not "bugs"
in a strict sense.
which leaves us at only 1 issue (which has been fixed in the CVS)
> and since I was told it could be deprecated
> in favor of [list append], my opinion is that maybe the shortcut should be
> assigned to the latter in order to prevent people unaware of pd's historical
> development to choose the former.
well, in theory this is correct.
in practice there are several issues:
- [l] is _not_ yet a shortcut for an internal list object. however, some
object has to provide the (bug-free) functionality of [l], in order to
not break existing patches
- [list append] is _not_ exactly the same as [lister]. you can make a
[lister] (or [l]) _abstraction_ with built-in objects:
| |
[route bang] |
| | |
| [t b a] |
+----------+ | |
| +--+
[list append ]
|
- afaik, this patchlet is 100% compatible, if you feed all the arguments
of [lister] to the [list append] replacement.
- this patchlet cannot be made into a 100% compatible _abstraction_ with
pd-internals, because there is no way to pass a variable number of
arguments to an abstraction. you would need my "$@" patch against Pd for
this.
these are the reasons why there still is a [lister]/[l] object in zexy
and why it is done as an external.
on the other side, a lot of objects in zexy are there only because they
aren't there in Pd yet (for instance, zexy had a [tabread4] object long
before Pd...)
i would love it, if Pd's [list] object (which is an alias to [list
append], would really behave in-line with the [float] and [symbol]
objects (see above patch)
i would love it, if this [list] object would have an alias [l].
fmg.asdr
IOhannes
More information about the Pd-list
mailing list