That's OK for bug fixes but hides use/enhancement discussions from normal Node-REDers
- It would indeed be better to log issues (like the code generator bug from yesterday) from now on in Github. They don't provide extra information for anybody else on the forum.
- But new functionality or doubts should be discussed here first on the forum, like Simon suggests. For example the push/pop list blocks that were suggested. But I'm not sure we should start a new thread on this forum for every new functionality, or a thread for every release of the blockly node?
P.S. I was thinking about rewriting my readme file this weekend, and then publishing 1.0.0 already on npm (where the readme file will be visible). The wiki pages on Github can be reworked afterwards independently, since they are not published anyway.
I assume that there are not much votes against Julian's proposal?
+1
S i m o n
After I updated the readme file last night, I suddenly realised that the return-block is rather badly designed.
When e.g. the input was 'msg', it generated the following Javascript code:
return msg;
That will be sufficient if you want to send an output message, and if you have only a single output port. But sometimes you just want to return from your processing (without output message). And if your Blockly node has multiple outputs, an array should be generated like in the Node-RED documentation.
There is a new version available on Github:
- The help (on the info tab) is updated. E.g. a link to the wiki pages is added, and a caution message is added about Blockly being 1-based (in contradiction to the 0-based Javascript).
- There is now a return-block that doesn't have any inputs, since it just generates a 'return' statement: stop the processing, without sending a message.
- There is now a separate return_message-block that returns AND sends the specified message to a specified port. It is rather similar to the send-block: you can select in a dropdown all output ports, and the same popup will appear when the available output port number is decremented (since you are using suddenly a non-existing output). Difference with node_send block is that we don't need to show a warning when the return_message block is put inside a LOOP, since we cannot end up sending duplicate messages (since the return statement will exit from the loop anyway).
Summarized:
@cymplecy: you will need to replace all your return-blocks by the new return_message-blocks. Sorry my friend!
Would be nice to get some kind of sign from God, so I can hit the NPM publish button today ...
You just need to press GO!
Somethings will break even after launch but maybe we might be able to come up with little scripts to parse the flow.json files for them
Simon
OK - replaced all my returns with the new block and all seems to work fine
Simon
Hi folks,
Version 1.0.0 is published on NPM. I suggest we STOP DISCUSSING HERE, and continue for the next version in the new discussion.