[L2Ork-dev] commit message clarification

[Ivica Ico Bukvic]

Then it may be a regression.

Best,

Ico


On 3/26/2017 12:32 PM, Jonathan Wilkes wrote:
>
>
> > That was so long ago I honestly don't remember. What I do remember 
> is that I had to take several stabs at this until I got it right. So, 
> there may be another commit on top of this that does this the right 
> way. If Purr-Data's current behavior matches that of the latest 
> pd-l2ork, then this fix may have been superseded by another.
>
> They both set the "mode" based on the type of the first argument.  
> AFAICT the
> singular change was from using argv[n] to using argv[0].
>
> Because of this we can't mix float and symbol arguments in [select].  
> But you
> made changes to [route] that does allow to mix float and symbol 
> arguments.  That's
> essentially the same interface with a payload as output, so I'm not 
> sure why [select]
> mixed mode would have caused problems.
>
> -Jonathan
>
> On 3/25/2017 9:44 PM, Jonathan Wilkes wrote:
>> Hello,
>> I just noticed this:
>>
>> commit 5e18b837acd440ac4751c90c0c0b1e4a71623a2e
>> Author: Ivica Ico Bukvic <ico at vt.edu> <mailto:ico at vt.edu>
>> Date:   Thu Jul 18 16:41:53 2013 -0400
>>
>>     fixed regression in select due to 
>> 37c0cf150e42e0277a0496cb73d48a114c64f0e7 commit which made it behave 
>> inconsistently thus making it impossible for floats to be treated as 
>> symbols (in cases where first argument was a symbol). Also introduced 
>> similar fix to the route object, thus allowing for second inlet to 
>> receive either float or symbol
>>
>> ***
>>
>> What is the regression that this was meant to fix?  Basing the 
>> object's "mode" off of the type
>> of the first argument as this commit does will _not_ allow floats to 
>> be treated as symbols as the
>> commit message suggests.
>>
>> If the implication is that you want this to work:
>> [42(
>> |
>> [makefilename %d]
>> |
>> [select blah 42]
>>
>> Then the implication is wrong, because you don't get a match that way 
>> under any version of
>> [select] for any version of Pd.  Instead you get a match for the "42" 
>> slot on this:
>>
>> [symbol(
>> |
>> [select blah 42]
>>
>> That is, _any_ numeric argument will match an incoming empty symbol 
>> because that's what
>> the SETSYMBOL macro does when you feed it a floatarg.
>>
>> I'd like to revert back to my "mixed" mode algorithm so that the "42" 
>> slot matches on this:
>>
>> [42(
>> |
>> [select blah 42]
>>
>> and the "blah" slot matches on this:
>>
>> [symbol blah(
>> |
>> [select 42 blah]
>>
>> Mixing arg types isn't very common, but this is the only sane 
>> behavior I can think of (and it
>> shouldn't have broken any patches in all the time [select] behaved 
>> this way in Pd-l2ork).
>>
>> -Jonathan
>>
>>
>> _______________________________________________
>> L2Ork-dev mailing list
>> L2Ork-dev at disis.music.vt.edu <mailto:L2Ork-dev at disis.music.vt.edu>
>> http://disis.music.vt.edu/listinfo/l2ork-dev
>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu <mailto:L2Ork-dev at disis.music.vt.edu>
> http://disis.music.vt.edu/listinfo/l2ork-dev
>
>
>
>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> http://disis.music.vt.edu/listinfo/l2ork-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20170326/bf916c78/attachment.html>