billy wrote:What about the whole code in general Trog....?
Well, there's a few things I might do differently, but first there's maybe something else to look into...
The problem that you started out with - the array not updating - could have a simpler solution. I'm not totally sure without looking at the original, but there's a known problem when feeding string arrays from file/preset data.
Very often, the cure is just to insert a string primitive just before the 'set array' input of the sting array primitive - very often that seems to 'rebuild' the string formatting so that it gets read correctly.
Now that I think of it, maybe this odd "inconsistent line terminator" thing is what causes that problem?
As for the code - here's a few tips...
One object - Many referencesWhat do I mean by that?
Well, when you do something like...
...the variable 'a' won't contain a new array with a copy of the array '@b' data. Variables in Ruby in fact don't contain very much at all - just a reference to an 'object'. This little demo will explain better than words can...
For this reason, your code has many duplicate references - @b, output 0, and 'a' are often just acting like "Windows shortcuts" to exactly the same array.
There's nothing especially "wrong" about that, it's just how Ruby works (and saves a lot of memory!). But, it can lead to a lot of accidental bugs - you try to change a single array entry, or edit a string, and all of a sudden, a load of other variables change that you didn't expect!
The trick is to know that there are two kinds of Ruby method...
The first kind is most common, you call a method, and the method gives you back a nice, shiny new object - no problem there because that breaks the link with the old object - no duplicate references.
The second kind of method takes an object, does something to it, and gives you back the same object - changing a single element of an array is probably the single most common example of this. It would be wasteful to make a whole new array just because you wanted to change one element, but it means that all other reference to that array also see the same change.
Just to be confusing, this second kind goes by several different names! - but when you're looking at the Ruby documents, look out for phrases like "modifies the receiver", "returns self". It's often indicated by a '!' ("bang") at the end of a method name - but usually that's only if there's a "non-bang" version with the same name.
So how does knowing this help simplify your code?Well, firstly there are quite a few places where you are "copying" the array, but Ruby isn't really making a copy - now that we know that there is only really one array, we don't need those at all.
Also, because variables are just "references" to objects, we can lose many "Array.new" lines - Ruby only cares about the object's "ID code", and doesn't care what kind of object it is, so there's no need to tell it in advance what you're going to use a variable for - it's not like 'green' where the Integer/Float etc. data types are set in stone and you must set connector types accordingly.
But the biggest cleanup is that we can now get by with far fewer variables - the less the better, to make it clear in the code that there's only one array.
But there's a problem...Ruby doesn't have "types" of Array - they can contain a mix of any old kind of objects. So what happens if we make the array bigger, so that there are empty 'slots' with no string in them? Or accidentally put a number in there instead if a string?
...Oh, wait, no there isn't!Malc thought of that one - just like the "auto translate" between green numbers/strings etc., when you send the array to the output, it gets auto-converted into a valid string array. Numbers get converted into their string equivalent, and empty slots are filled with empty strings.
The 'auto-translate' isn't totally infallible, because many types of Ruby object don't convert to 'green' types in an obvious way - but Malc seems to have done a pretty good job of handling it to minimise any errors.
...OK, maybe a little problem...You said that for large arrays, things were going a little slowly. Well that isn't totally surprising - a string array primitive will be made from super-fast compiled C++ code, and there's just no way that Ruby can compete with that. Also, imagine what that "auto-translate" routine must be doing - every time the output changes, it has to check every single entry in the Array to see if it is a valid string, and then deal with anything that needs replacing.
Lean Green MachineThat's why I suggested to check whether the problem was due to the old SM string array problem - because this is one of those cases where Ruby doesn't have any advantages over 'green'. Unless there are some new array functions that you really need to add, or there really is no other way around your bug, the primitive is always going to be a much better performer.
(tester will be pleased!
)
But just for completeness, I'll knock up a "Ruby String Array", so that you can contrast and compare with your version - to follow shortly...
....but why this behaviour...??? 
