[L2Ork-dev] commit message clarification

[Jonathan Wilkes]

One possibility might be to use the "-legacy" flag to revert back 
to the Vanilla behavior of no mixed arguments.
But I'll definitely test/read the code some more to make sure there 
isn't any weirdness that crept in.
-Jonathan



 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>
 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
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 
 
      
  
 _______________________________________________
L2Ork-dev mailing list
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/59257f1d/attachment-0001.html>