RubyConnectors - Get Names

[chackl]

Hello!

Is there any way to get all names of the Ruby-Input-Connectors within one RubyEdit?

Regards
C.Hackl

[trogluddite]

Doesn't seem to be - I've been trying to do this too, to build a nice little 'preferences' file with all the name. I've tried all of the Ruby tricks for peeking into what methods and variables the objects have, but haven't turned up anything that looks like a list of names.

The nearest that I've managed is this...
It assumes that you are using code with methods (i.e. 'event' etc.) - you could put this code at the very start of the 'init' method...

Code: Select all

def init
  default_variables = [:@in, :@ins, :@outs, :@this]
  temp_inputs = @this.instance_variables - default_variables
  @input_names = temp_inputs.map{|var| var.to_s.delete('@') }
end

This builds an Array '@input_names' by looking for their '@' variables, removing the variable names from the list that are defined as standard. However this has two problems...
- It assumes that the list of 'default' variables will never change, which we can't guarantee, as DSPr might add new features that set some new variables before 'init' gets called.
- It only works once at startup - fine in an export, but you're inside FS and do any editing of the Ruby code, 'init' gets called again, and all the other '@' variables you used in your code will get added to the list.

[trogluddite]

Hmm, been playing with this, and I'm not so sure that code is completely reliable - sometimes I don't see a full list returned, only the first few inputs.
This alternative works better - using a 'blacklist' of your known variables names, so that they are excluded too - then you're able to call the 'get_input_names' method during run-time, after all the initialisation stuff has settled down.

Code: Select all

def get_input_names
  default_variables = [ :@in, :@ins, :@outs, :@this ]
  my_variables = [ :@input_names, :@var1, :@var2, :@var3 ]
  var_list = @this.instance_variables - default_variables - my_variables
  @input_names = var_list.map{|var| var.to_s.delete('@') }
end

But, of course, you'd have to be very careful to keep the 'blacklist' up to date whenever you updates the code!

[chackl]

Thank you this brings me a bit more to finish

Well this may be no Problem - because i will now Need it once - As you said to pack up all connectors to one object to read them out in the next rubymodule

Regards

[trogluddite]

This seems to work reliably...

Pack Inputs.fsm

(744 Bytes) Downloaded 916 times

[chackl]

You are using those ":strings" with '.to_sym' - could you just give me some instructions to that?
I saw it in your scripts realy often - but i dod not understand it.

Regards
Chackl

[trogluddite]

I use the Symbols just because it makes the code run faster.

Everything in Ruby is an object with a unique ID code - which is just an Integer number. Most object then have some data content (e.g. the ASCII characters within a String object), and a pointer to their class so that Ruby knows what methods they can use.

A Symbol is a special class of object that is nothing but a unique name - they don't DO anything, but just act as labels for things. For example, all of the names of variables, methods and classes are held as Symbols. For this reason, Symbols can never be edited, otherwise you could start changing the names of all sorts of things while the code was running, and Ruby would get very confused.
That's why symbols don't really have any methods - you can turn them into String form, edit the String, and make a new Symbol with a new ID code; but the original Symbol will always still be there with its original name and code. Also, when I say that Symbol names are unique, that applies to the whole Ruby parser - not just one RubyEdit instance (like with variables) - the whole schematic. Anywhere that you mention the same Symbol name, it refers to exactly the same ID number.

When Ruby parses your code, it speeds things up by turning all the code words, class and method names etc. into "byte code" (numbers!)- that way, when it runs the code again, it can just look up the ID numbers without having to parse the text all over again. User-defined Symbols are in the same "library" as all the other 'special' words, so this "byte-code" conversion applies to them too - the Symbols are replaced by their unique ID code.

So when you test a Hash key, or do '==' etc. using Symbols, it becomes just a simple comparison of two ID codes - "Integer == Integer"; very fast!. For Strings, Ruby has to go inside the String objects to look at the contents and then compare each character one at a time - which is much slower!

Of course, that means that you can't always use Symbols - sometimes you do just need to use strings because a value might need to be dynamic - e.g. if it comes from a green String input. But anywhere that a Hash lookup can be written directly into the code, my_hash[:my_symbol] will always be quicker than my_hash["my string"].