Hi,
Up to at least version 0.40.1, [list length] used to output the number of arguments of a list or message (exactly as documented), which means that [walk the dog( had length 2, not 3.
Now, in 0.41-2, it treats the message as a list and outputs the length of the list, that is [walk the dog( has length 3 which is the same as [list walk the dog(
Just compare how the help patch for [list length] behaves in version 0.40.1 and in 0.41.2 (not sure where the change happened).
This new behaviour may perhaps be "better" than the old one (it is more coherent with the behaviour of all other [list] objects which always convert any message to a list), however:
1 - this is DISASTROUS for backward compatibility. Patches written for older versions will behave differently on the new version! 2 - the documentation (help patch) is unchanged, and there is no ambiguity in it: it describes the old behaviour.
Was this change intentional? Is there a reason so good to be worth such a huge break in backward compatibility?
If so, the help patch should be updated.
matteo sisti sette wrote:
Hi,
Was this change intentional? Is there a reason so good to be worth such a huge break in backward compatibility?
afair, this has been discussed on the list. the result of the discussion was: the new behaviour is more consistent with the general behaviour of the [list] object, and it is compatibile with similar objects that made this functionality available, e.g. zexy's [length]
obviously it is incompatible. the reason to nevertheless do change it was, that [list length] was not introduced before 0.40, which keeps the potential number of victims low (esp. since Pd-extended has not yet made it so far); if the behaviour ever needs to be changed, better do it NOW than later.
btw, in Pd's long history, i can only remember two (2!) objectclasses that have changed their behaviour (without changing the interface): [list length] and [atan2]. the latter was indeed disastrous, as [atan2] had been long introduced before, something [list length] is fortunately not yet.
If so, the help patch should be updated.
definitely.
fgmadsr. IOhannes
IOhannes m zmoelnig wrote:
obviously it is incompatible. the reason to nevertheless do change it was, that [list length] was not introduced before 0.40, which keeps the potential number of victims low (esp. since Pd-extended has not yet made it so far); if the behaviour ever needs to be changed, better do it NOW than later.
which reminds me: i think it would be good if Pd-extended-0.40 would have a fixed version of [list length].
fgmadsr. IOhannes
Even smarter might be to skip Pd-extended 0.40 and go straight from 0.39 to 0.41.
cheers Miller
On Wed, Feb 20, 2008 at 05:44:54PM +0100, IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
obviously it is incompatible. the reason to nevertheless do change it was, that [list length] was not introduced before 0.40, which keeps the potential number of victims low (esp. since Pd-extended has not yet made it so far); if the behaviour ever needs to be changed, better do it NOW than later.
which reminds me: i think it would be good if Pd-extended-0.40 would have a fixed version of [list length].
fgmadsr. IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Except that 0.41 has cross-platform font/pixel size issues while 0.40
accepts the 0.39.3-extended patches cleanly. Plus the pd-extended
v0-40 branch already has the font/pixel size fixes included and
working in it.
As for [list length], I am fine with using the newer version. Feel
free to commit the necessary changes to the branch, or file a bug
report and I'll do it when I get to it (I don't really know what the
issues are right now).
.hc
On Feb 20, 2008, at 11:52 AM, Miller Puckette wrote:
Even smarter might be to skip Pd-extended 0.40 and go straight from 0.39 to 0.41.
cheers Miller
On Wed, Feb 20, 2008 at 05:44:54PM +0100, IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
obviously it is incompatible. the reason to nevertheless do
change it was, that [list length] was not introduced before 0.40, which
keeps the potential number of victims low (esp. since Pd-extended has not
yet made it so far); if the behaviour ever needs to be changed, better do
it NOW than later.which reminds me: i think it would be good if Pd-extended-0.40 would have a fixed version of [list length].
fgmadsr. IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
I spent 33 years and four months in active military service and
during that period I spent most of my time as a high class muscle man
for Big Business, for Wall Street and the bankers. - General
Smedley Butler
Hallo, matteo sisti sette hat gesagt: // matteo sisti sette wrote:
Up to at least version 0.40.1, [list length] used to output the number of arguments of a list or message (exactly as documented), which means that [walk the dog( had length 2, not 3.
Now, in 0.41-2, it treats the message as a list and outputs the length of the list, that is [walk the dog( has length 3 which is the same as [list walk the dog(
Just compare how the help patch for [list length] behaves in version 0.40.1 and in 0.41.2 (not sure where the change happened).
This new behaviour may perhaps be "better" than the old one (it is more coherent with the behaviour of all other [list] objects which always convert any message to a list), however:
1 - this is DISASTROUS for backward compatibility. Patches written for older versions will behave differently on the new version!
This has already been discussed in the past. The old behaviour was considered wrong. All [list] variants first convert their input to a proper list and all of them except [list trim] also output a proper list. Being able to rely on this makes patching with [list] objects much less error prone: When doing stuff with [list], there are no meta-message issues to consider. [list length] was breaking this rule, now it's fixed.
Also it was considered to be confusing to have the length operator count a message "one two three" as having length 2 instead of 3. 3 is the better result in every usecase I can think of.
The backward compatibility issue of course is there, but as 0.39 didn't have [list length], only one version of Pd (0.40) was affected by the wrong counting, so rather then wait any longer, the change was made as soon as possible.
If there will be a pd-extended 0.40 I'd suggest to let "list length" count as the one in 0.41 immediatly.
Note that [list-len] from [list]-abs, one of the alternatives to get the list's length for 0.39, always counted all elements including the selector.
2 - the documentation (help patch) is unchanged, and there is no ambiguity in it: it describes the old behaviour.
You may have a different help patch than I: Mine doesn't describe this issue at all. However mine does say the following:
"In general, inlets that take lists (two each for append/prepend, and one each for split and trim) will convert non-list messages (such as "set 5") to lists (such as "list set 5" automatically."
Applied to [list length] this means, that 0.40 was buggy, 0.41 has the bug fixed.
Ciao
Frank Barknecht _ ______footils.org__
-
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
matteo sisti sette -
Miller Puckette