I think I ran into a bug in zexy's lister, or at least a surprising behavior that should perhaps be documented. It seems that its output is reevaluated for each inlet it is connected to (ie if the left inlet of the lister has changed in between because of the depth-first traversal, its output will change). I suppose it's a bug because the [f] object doesn't behave this way. I'm not sure my explanations are very clear, so I attached a small patch to demonstrate the issue.
Hallo, Cyrille.Damez@laposte.net hat gesagt: // Cyrille.Damez@laposte.net wrote:
I think I ran into a bug in zexy's lister, or at least a surprising behavior that should perhaps be documented. It seems that its output is reevaluated for each inlet it is connected to (ie if the left inlet of the lister has changed in between because of the depth-first traversal, its output will change). I suppose it's a bug because the [f] object doesn't behave this way. I'm not sure my explanations are very clear, so I attached a small patch to demonstrate the issue.
Yes, looks like a bug in [lister], and there seem to be more: Replace [list-rot] with [list prepend 10] and you will get other issues. However I think, [lister] can be savely deprecated now that we have [list].
Frank Barknecht _ ______footils.org_ __goto10.org__
On Thursday 27 September 2007 16:38:22 Frank Barknecht wrote:
Yes, looks like a bug in [lister], and there seem to be more: Replace [list-rot] with [list prepend 10] and you will get other issues. However I think, [lister] can be savely deprecated now that we have [list].
Maybe it would be safer to have the shortcut [l] be used for [list] instead of [lister], or at least correct the doc for [lister] to mention that it's better to use [list]. Instead, the help for [lister] actually deters people from using [list] by saying: "of course, this should be named "list", but there already appears to be a "list" object, though i don't see any use in it" I suppose it's a leftover from an era when lists weren't implemented yet in vanilla.
Hallo, Cyrille.Damez@laposte.net hat gesagt: // Cyrille.Damez@laposte.net wrote:
On Thursday 27 September 2007 16:38:22 Frank Barknecht wrote:
Yes, looks like a bug in [lister], and there seem to be more: Replace [list-rot] with [list prepend 10] and you will get other issues. However I think, [lister] can be savely deprecated now that we have [list].
Maybe it would be safer to have the shortcut [l] be used for [list] instead of [lister]
Yes, I think so, too. [l] for [list] would be (almost) in sync with [f] and [symbol] (only that [l] then actually should be for [list append], not just for [list] without method).
I suppose it's a leftover from an era when lists weren't implemented yet in vanilla.
Yes, I'm sure it is. If you want, you could file some bug reports on the Souceforge site for [lister], so these aren't forgotten.
Frank Barknecht _ ______footils.org_ __goto10.org__
On Fri, 28 Sep 2007, Frank Barknecht wrote:
Cyrille.Damez@laposte.net hat gesagt: // Cyrille.Damez@laposte.net wrote:
Maybe it would be safer to have the shortcut [l] be used for [list] instead of [lister]
Yes, I think so, too. [l] for [list] would be (almost) in sync with [f] and [symbol] (only that [l] then actually should be for [list append], not just for [list] without method).
Two questions:
[pointer] have one?
of favour? It can't be exactly the same because the bang required by [f] is confused with the empty list that would have to be stored in [l] so that [l] behaves like [f]. In other words, a [f] or [symbol] or [pointer] is like a single-inlet [pack] plus an extra cold inlet that behaves like a set-method of the hot inlet (except that [pack] doesn't have a set-method, contrary to most objects that are pack-like! consistency!)
PS: i'm looking for adjectives to say "pack-like" and "pack-like-with-set", in a less cumbersome way. Any ideas?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
Two questions:
- why does list deserve a shortcut like that when neither [symbol] nor
[pointer] have one?
Oh, seems I just was confusing things a big.
Frank Barknecht _ ______footils.org_ __goto10.org__
On Friday 28 September 2007 03:10:53 Mathieu Bouchard wrote:
- why does list deserve a shortcut like that when neither [symbol] nor
[pointer] have one?
Because [s] is already taken and pointers aren't used that often ? I don't really understand where you're getting at. Do you suggest to remove it ?
- how much should [list append] be like [f] in order to deserve that kind
of favour?
I don't see that [list] needs to behave at all like [float] to "deserve" a shortcut: [trigger] and [send] are nothing like [float]. However, I'd rather not have a one character shortcut point to a deprecated/buggy object.
On Fri, 28 Sep 2007, Cyrille.Damez@laposte.net wrote:
I don't see that [list] needs to behave at all like [float] to "deserve" a shortcut: [trigger] and [send] are nothing like [float].
indeed. (there are also shortcuts for [bang] and [receive]).
However, I'd rather not have a one character shortcut point to a deprecated/buggy object.
right.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Cyrille.Damez@laposte.net wrote:
However, I'd rather not have a one character shortcut point to a deprecated/buggy object.
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...
fgmasd.r IOhannes
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. 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). However, in this particular case, since we know there are a couple issues with [lister] 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.
Cyrille.Damez@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:
corrupts the output.
and then there is another "bug" which has not been filed to the tracker yet:
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:
object has to provide the (bug-free) functionality of [l], in order to not break existing patches
[lister] (or [l]) _abstraction_ with built-in objects:
| | [route bang] | | | | | [t b a] | +----------+ | | | +--+ [list append ] |
of [lister] to the [list append] replacement.
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
IOhannes m zmoelnig wrote:
- [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
what i mean is: you can replace [l] with the above code. but you cannot simply make an abstraction [l] containing the above code and expect it to behave identically.
fgmad.r IOhannes