[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 

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


More information about the Pd-list mailing list