woosh...............................................
Yes, that's what makes it interesting!
It is because of the fact that variables are always passed by reference so typically you never get a copy. Even when you assign a variable to another, you don't get a new variable, only a new pointer. Not really an async issue in this case.
No-one ever told me that!
[edit] They probably have - its just I keep forgetting[/edit]
I just assumed Marquis of Queensbury rules applied - only big objects to be passed by ref - all others by value
Doesn't really explain why things change when you stick another node on the output though does it????
One of the great discussions is whether this Blockly node should stick to JS concepts or whether it should try and abstract/disguise them.
For instance , when @BartButenaers adds some more list manipulation - should it use more general word like append vs JS specific push
Ah, but the problem is that they don't change! In other words, while it looks like the output msg is a different object, it really isn't. That then flows through multiple nodes! It is only different when it really needs to be thanks to the magic of the excellent Node-RED base code.
It keeps things really efficient - BUT - causes confusion like this.
Well, since arrays are already called lists, I'd stick with the blockly terms. Deal with it through the help.
[bug] in other news but related, I tried doing this
but it gives this JS
var i, clonedMsg;
for (i = 1; i <= 5; i++) {
clonedMsg = R;
clonedMsg['payload'] = i;
node.send([clonedMsg]);
}
You say magic I might say something else .......
(I don't doubt that Node-RED is doing magic - I just wish magic wasn't necessary to deal with JS in the first place )
Think I introduced (during refactoring) a bug in the code generator of the node_clone block:
for (i = 1; i <= 5; i++) {
clonedMsg = R;
clonedMsg['payload'] = i;
node.send([clonedMsg]);
}
Second line is wrong now ...
Wil read through all your posts this evening, and try to fix this problem. Although I promised Julian to keep my fingers away from the coding ...
bug fixes are allowed
I also would like to give my congratulation to this fantastic and beautiful enhancement! I have followed the discussion and it has been very informative, I learned new things on the way which is great
There are sometimes when you recognize milestones. When we got the Dashboard was such a one. I think this is another one, the Blockly node. Maybe we can borrow an old statement, modify it a bit,
"That's one big step for Node-RED, one giant leap for users."
Personally I always try to use as many "standard" nodes that I can or know about when I create my flows. But where would I stand if the Function node was not there? Sometimes I find out later, hey there is a Node available doing exactly that! On the other hand, I have worked a bit with javascript, so I learned something on the way anyway, so far so good
At this moment, I am not sure yet, if I will use Blockly since I am rather happy writing javascript now a days. But it is looking fantastic, tempting...
One thing just came to my mind; what if the reverse would work? I mean, think of a Function node with it's javascript. I copy & paste it's code into the "Generated Javascript" tab, switch to the Editor and, as magic, find a compatible configuration for a Blockly node. Maybe this works already? Easy Migration of Function nodes to Blockly...
[idea]BUT ONLY FOR AFTER NPM LAUNCH
Could we have a config flag that is used to dictate whether the output does cloning automatically?
So that non-advanced programmers (like me) could use the original block syntax of a simple loop
Then this could be translated into blocks using cloned messages
Feasible????
Never received on a single day so many feedback. Apparently a few bottles of champagne can do miracles...
Thanks. But most of the credits go the Blockly team at Google, which did a magnificent job ...
Perhaps this can comfort you: I'm also not going to use it. But I have some acquaintances that will have lots of benefits from it. So let's hope it can persuade a lot of new users to start enjoying the magic world of Node-RED ...
Well you are not the first one (of the two of us) that started thinking about that However I don't have time at the moment to investigate such functionality. But if somebody wants to analyse it, you can start by have a look at those links: 1, 2, 3. The last link contains responses from the Blockly team members, so it seems this is only experimental stuff...
That could be an option, but we tried to avoid having checkboxes for all kind of configurations...
Julian, perhaps you should start a new discussion for new feature requests in the next version. Otherwise we might forget it. Perhaps you can quickly draw a scetch and put the mockup in the discussion...
Ok the gates are open again
There is a new version on Github available with following changes:
-
The code generator of the node_clone block is fixed, since a bug was introduced during refactoring. It now again returns a value (i.e. a clone of the message) instead of a (clone) statement:
-
Three blocks have now by default an empty string input instead of no input.
P.S. When no input was available, my code generators generated already an empty string by default. However it is indeed better that the user sees immediately that an empty string is the default. -
About the whole cloning discussion between @cymplecy and @TotallyInformation: that is indeed something very confusing, especially when you are new to Node-RED. I explained this kind of problems already some time ago in the readme of my resend node. But is not something that I cannot detect in blockly, since I have no clue if the same message is being resend multiple times. However I have added now a warning for every node_send block that is being used in a loop:
Not a perfect solution, but then at least you know that you 'could' run into troubles. I can also add a link to the corresponding wiki tutorial in the warning bubble?
P.S. I doesn't matter how deep the node_send is nested inside the loop, since I search upwards through ALL levels until any kind of loop is found.
Have fun with it !
Excellent feature
Updated 4 Pi and my Win10 - all seem OK
Simon
I think (in the next version) the issues should be reported in a more consistent way to the user. Let's compare the blockly node to the function node:
FUNCTION NODE
In the function code, you can write any kind of horrible code. However the user gets a lot of feedback about his mistakes:
- The ACE editor will display a lot of syntax errors
- When the 'Done' is pressed anyway, the node will get a red circle
- When you still haven't noticed anything, a popup will be displayed when the 'Deploy' button is pressed
An image says more than thousand words:
BLOCKLY NODE
When I started my Blockly contribution, I had lots of syntax errors in my generated code due to:
- Problems in my code generators
- Mandatory inputs in my blocks which were emtpy
So I added the same mechanism (as the function node) to my original Blockly node: syntax errors were detected (via the ACE editor) and reported to the user.
However both types of problems were fixed afterwards:
- The code generators were fixed (like the node_clone block this evening )
- Shadow blocks were added to make sure that (at least mandatory) inputs always have a default value
Summarized: the generated code should always be syntax error free, since we cannot expect a non-technical user to start looking at errors in the generated Javascript (which is readonly anyway ...). Since the error reporting mechanism became obsolete again, I removed it (some versions later) again from my node.
But now I'm wondering what is the best way to report warnings and errors to the user? The current node has already different ways to do this:
- When e.g. a send_node sends a msg to output "3", and then the number of available outputs is lowered to "2". Then a popup displays a non-blocking warning and a 'node-red.error(...)' statement will be included in the generated code.
- When a node_send block is put inside a loop, a warning bubble/icon is displayed on that Block.
- When you have a Node-RED version below 0.19, a 'Tip' form is displayed below the editor to give a warning.
Does anybody have feedback of how to make a uniform way of working. Think the function node does a very good job in this matter ...
Can I suggest that we now move issues to the Issues log on GitHub?
This will make it a lot easier to follow each issue and let you manage them a lot better.