Patcher inlet name mangling bug 1.0.12

#1

I think there might be a bug in the patcher. For the audio rate sample buffer type frac32buffer, the patcher mangles the patch source (build/xpatch.cpp) when an audio rate input has a name that ends in a number with more than 2 digits. Other inlet types work as expected.

In the object "drj/mux/mux 12" :

  <inlets>
     ...
     <frac32buffer name="i10" description="input 10"/>
     <frac32buffer name="i11" description="input 11"/>
     ...
  </inlets>

  <code.srate><![CDATA[   switch(inlet_s>0?inlet_s:0){
  ... 
// in 1.0.12 this code:

  case 10: outlet_o= inlet_i10;break;
  case 11: outlet_o= inlet_i11;break;
  default: outlet_o= inlet_i11;break;

// gets mangled to (note the breaking up of the number "10" and "11"):

  case 10: outlet_o[buffer_index]= inlet_i1[buffer_index]0;break;
  case 11: outlet_o[buffer_index]= inlet_i1[buffer_index]1;break;
  default: outlet_o[buffer_index]= inlet_i1[buffer_index]1;break;
  ...
}
]]></code.srate>

To trigger the bug, make a new patch with just the "mux 12" audio rate object and start the patch compilation. The bug manifests itself on another user's Apple system as well as on my Windows system.

Edit to add: The "mux 12" object was made and tested on May 5, 2016 and left alone since then, except for some testing today.

I made a temporary workaround for a fellow Axoloti user by making a "mux 12b" object, replacing the two digit numbering 10 and 11 with A and B. I will deprecate that object when this bug gets fixed.

#2

I get this occasionally also and was not really able to find a pattern to why it did it. But it has to do with numbers in the names of the outlets, I think I only had the issue on S-rate outputs.

#3

if you name the inlets with a 0 prefix it should work: i00 i01 i02 i03 ... i10

I think that @thetechnobear works on the Axoloti editor, maybe he has more information.

I think the problem is that "inlet_i1" is a substring of 'inlet_i10" that confuses some replace algorithm that insert the [buffer_index].
Maybe it is possible to fix the bug with some regex used in the String.replaceAll

newString = oldString.replaceAll(
     "(?<![a-zA-Z0-9_])"
   + "inlet_"+inletName
   + "(?![a-zA-Z0-9_])"
);

.

(?![a-zA-Z0-9_])

means "not followed" by any of the a to z A to Z 0 to 9 or _ characters

(?<![a-zA-Z0-9_])

means "not preceded" by such characters (if somebody is vicious enough to name a variable T_inlet_i1 it won't cause trouble).

I tested this regex here:
https://regex101.com/

regex:

  (?<![a-zA-Z0-9_])inlet_i1(?![a-zA-Z0-9_])

test string:

int32_t x = inlet_i1>>5;  // found
int32_t x =inlet_i1>>5;   // found
int32_t y = inlet_i10>>5; // not found
int32_t y = Tinlet_i1>>5; // not found

it found inlet_i1 only where it is intended.