DSP Robotics Support

you can put this array class methode in a module somewhere in your schematic, but it is important that you do this before adding any other ruby module inside!

You mean any other ruby module at all or any ruby module that uses this class? I ask, because I have some modules spread around here and there... Or just restarting the schematic is enough? I'm confused.

But as far I could read the manual - there should be (?) an easy way, to send this class data via "V" ruby connector, and only to modules I'd like to. Or?

tester wrote:

you can put this array class methode in a module somewhere in your schematic, but it is important that you do this before adding any other ruby module inside!

You mean any other ruby module at all or any ruby module that uses this class? I ask, because I have some modules spread around here and there... Or just restarting the schematic is enough? I'm confused.

But as far I could read the manual - there should be (?) an easy way, to send this class data via "V" ruby connector, and only to modules I'd like to. Or?

you dont need to send it if it is in the array class just put the module with the arrayclass methode (no module ins and no module outs) in the first level of your schematic (i think it should be in the first level but not shure about this maybe it also works when it is in a deeper level) and you can use the methode in any other ruby module, you also dont need to send any value because the methode returns the new sized array by itself..

thats the easiest way

its a very easy way when you extend the "ruby stock classes" like the array class, or string class, with methodes you write by yourself..

it is like this that ruby has some classes implemented like the arrayclass or the stringclass, you dont need to write the class by your self but you can extend the classes with your own methodes when the methode you need is not implemented..

see my "arrayclass methodes extension module" there i did exactly this
viewtopic.php?f=3&t=1760

but i`m not very good to explain things like this... but have a search about what methodes and class methodes are and how you use them

It looks that I have a problem that I don't understand...

If I redefine input into string array, then I get error, if it's just string, then it cuts values. I have no idea how to wire it.

i`ve no FS here in my work but if you use this

.split('/') makes arrayitems from string at every '/' so i think this will be the issue..

I still don't understand. I don't want to do the operation on buit-in "test data" that Trog made, but on input data. Problem occurs, when I try to provide an input. I don't know what is the reason of this confusion.

Still stuck :-/

I think it would be good if you could post an overview of how you're using this data in practice, and to define how/when the data needs to be in the special delimited string format (e.g. is that only used for loading/saving?).

If the string formatted data is only required for saving and loading as a text file, it would be better to build "convert to Ruby array" and "convert to text" modules, and then do as much as possible "internal" processing on the native Ruby arrays - with appropriate "convert to green" modules only where necessary.

The main advantage is speed - parsing strings is always a relatively slow process, so avoiding unnecessary string<->array conversions would make everything run much better.

It would also make many of the Ruby codes much smaller and potentially easier to understand and adapt. For example, for a true "nested array" format, it is much simpler to construct a set of modules to manipulate the data - e.g. "get row" module, "get column", "get cell", "parse from text"... etc...
Such modules would be useful for anyone who needed to use 2D arrays for any purpose, and only "string -> 2D array" and "2D array -> string" modules need to be customised for each application.

tester wrote:I don't know what is the reason of this confusion.

I think that this relates partly to the above comment. You are asking for solutions to small parts of the problem as you encounter each one, but it is hard to solve them fully without knowing the context. So, I think there is some confusion for the "helpers" too - at each step we are unsure if the input or output data should be Arrays, nested Arrays, delimited strings etc. We then post only partial solutions which do not work when placed into context, which probably then adds to your confusion - and so we go round in circles all confusing each other.

Another problem is that it's much easier to make the Ruby codes once things are in a native Ruby format. Ironically, trying to keep too much stuff in "green" (because you understand it better), is precisely what is making the Ruby stuff so complex (requiring even greater Ruby knowledge - for you and also for your "helpers").
So we should begin by identifying the places where "green" is necessary, to link up with other parts of the schematic - but other places, where "2D array" modules connect only with each other, where "white" Ruby links would be more simple.

I'm in the middle of how the project should work, so I can only predict 1 or 2 steps ahead in terms of what I need. I observe some behaviors when implementing greens, thus - I can say, that these situations require the thing I don't comprehend (due to multiple ambiguous behaviors, and differences in how it works comparing to the rest of FS) - ruby. On the other hand, the same concepts - are used in multiple points in various combinations, that why I'm portioning it.

Regarding the project itself - there is a split in multiple layers. Things user must have (editing), thigs user must see (display), things I must have/see (structures) in order to know whether it works correctly, and things that FS must calculate, load and save. There are dynamic amounts of certain things (textual/numeric data in use are defined and determined by user), thus - it can't be fixed to "5" or so. Besides I see other applications of the same concepts/modules, both in small and large scale operations.

To my view - things I seek for are rather simple (although as you said - surprisingly they are complicated). Dealing with X/Y/../Z matrixes of strings and numbers in various ways. Either some sort of (cross)randomization via associated indexes, or getting something from single/multiple columns or getting single/multiple things from rows, or both, reformatting, and so on. When is no need for ruby, or I know that ruby will "cheat" - I don't use it. But I found places, where without ruby - there is no way to get smooth operations. Small pieces of ruby code, no complex interactions with greenery. So you are telling nothing new.

I just don't know how to deal with these portions of ruby code. They don't behave in classic way, like visual, modular, dataflow FS/SM. I can't measure what I'm doing right or wrong. It's easier for me, to have a working module inside a schematic (that I can dig in while testing it and determining limitations), than having on-screen code, that may work or may not work due to my overlooking of something very simple yet deadly crucial to (only) ruby. And as far i can see - it's not only me having this problem.

p.s.: Did you went to the attachement? One of these small ruby portions you suggested seems to not work with me (although I thought it worked; maybe I did some little mistake I don't recognize?).

I too am very interested in learning more about Ruby and the handling of Arrays.

As I get deeper in FS ... I realize that 'due to what I understand at this moment', and the desired goal I have for a project ... the goal usually exceeds my knowledge. I expect that really. This motivates learning.

But during this process, I also find that [because of my limit], the design becomes more and more complex ... and I don't mean in a GOOD way

I like using the PRIMS ... it's the most familiar, and I can plug and play until I get something that gets me the next step along. But I've [very] slowly looking to RUBY to handle things that are more interactive.

To what extent is hard to say, because my 'limit' is enforcing how I go about it [whether Ruby or PRIMS].

When the experienced Members here share a coding technique, a light can go off showing a much better way to handle something ... too often, I've had to rewrite my project from the start, or at least certain sections. But the result is usually so worth it.

I keep mentioning my recent exposure to the 'Marshal' routine. For the type of projects I'm working, this technique has been golden ... the major rewrite I had to do showed just how overly complex my previous [working] concept was.

I thinking that I need to spend more time developing and understanding way to handle data [via Ruby] at the start. This way, when I go to design a project, I have a set of programming concepts/technique that I design FROM, instead of designing from 'painted into a corner'. True, can't know everything the project might develop into ... but there are always needs for data management/format.

These threads are so valuable to those like me just getting exposed to all this. I'm not comfortable to suggest much to programming technique or Ruby code ... and certainly appreciate what You guys bring to the forum !

Reading this 'things Array/Ruby' with much interest.