Alright - I missed some additional dependencies of the streams library that are now hidden. If you scroll to the bottom you can see my changes to blocks in the list, variable, and control categories.
@qw23 thank you for looking at my work with a careful eye - I have made way too many mistakes. I have reviewed my changes and if there are any more problems (other than the existing limitations like visible stepping on the generate stream block) I am a doofus and you probably shouldn't trust any of my suggestions .
Fair enough.
Right.
About that - could I convince you to change their category to other? That would solve the zebra colouring of the upvars .
I have added a cog icon to all the hidden blocks that I am aware of in other libraries - what do you think?
Just a final note. I would like to thank @qw23@bh and everyone else who contributed to this awesome library. Just yesterday I generated over 30 000 primes (note that the algorithm I used was similar to the one provided by the library, but it used hyperblocks), at which point the tab ran out of memory. It was fun! Did you know that the 29999th prime is a nice 350 351?
About the zebra colours: could you explain your issue? I really don't think we should use the "others" category (since the library is rather large), but perhaps we could change the colour scheme (@bh permitting).
I wonder what algorithm you used for generating primes. Would you share it?
(this is actually an updated version of the algorithm that uses linked lists to take up less memory. I got to 45,000 primes before stopping by accident). The script I have used to watch the program's progress is this:
Because this version uses hyperblocks, it is almost 10x faster than the original sieve. In a 50 second test, my version produced 6350 primes, while the original version produced 650 primes.
I have just published an update with the let blocks returned (manually so as to not mess up any other changes). The let blocks are now in the other category, and the newly changed blocks have been moved to the right. I have now hidden the comment blocks as well. There are a couple of things I still want to review with you before these updates are published:
Firstly, there are two blocks that do the same thing:
I personally prefer the latter. Once you choose which one you want to keep, I can find all uses of the other one and replace it. Then, the extra block can be deleted.
Secondly, these three blocks used let blocks which I chose not to return:
This code snippet from the definition confused me at first. Specifically, it was not immediately obvious to me that the two variables' values would be being changed every time the predicate was evaluated. To me, these blocks meant the same thing as:
I can see now that this isn't so, but I think that writing the code using the original method increases the chance of confusion and decreases readability. Moreover, the original method actually is creating a new variable over and over again - this will certainly reduce speed. For reference, here is my version:
As it turns out, there was a (sort of) good reason for why FOLLOWING existed - the order of inputs. In the block below, I had to add input parameters to ensure the order of inputs was correct with the FOLLOWED BY block:
Done! Some kind of glitch/issue (probably to do with importing my tests of the generate stream block) removed all instances of generate stream from the demos. I'd actually already discovered the issue before, but I only checked blocks that were shown or in the more stream blocks block (thinking that these would be the only ones with demos). Sorry!
PS: I have checked and they produce the same result as v2.0.
That seems a narrow use case. Many blocks have more than two inputs. I thought of this:
But this leaves no room for flexibility. What if you want the second input first, then the third, then the first? I'm not sure that such a block is actually something that would be useful in a library.
I agree that your proposed generalization would be hard to turn into a library block that would be flexible, fast, non-ugly, and generally useful. That's why my narrow two-input version is better! There are a lot of two-input functions, vs. hardly any with more than two inputs.
I’m generally happy with the result - once more: well done! I won’t fuss about the remaining substitutions of let (BTW perhaps the let label should be preceded by a “cog” icon, and the definition hidden). Just two more suggestions:
Within the definition window of map over keep over map used to be three functioning demos - please restore these;
In library v2.0, the blocks were carefully grouped and ordered (basics, generators, single-stream higher-order-functions, multi-stream mixers, selectors, debugging, demos). Would you restore this order? (if you know how?)
They are ... there? Perhaps you are confusing it with the definition of the keep from map block, which I did modify and thus was in the scripting area? Here is a screenshot of the map over keep over map block:
Whoah, that is weird. I'd imported the blocks from a different project where I'd originally started work on the library using a script pic. I guess that somehow messed up the order. I've fixed that now!
The blocks are already hidden, I'll add a cog.
Edit: I checked, and the declare and initialize script variables library doesn't have your blocks in them, so they don't need a cog per se. It's okay if you still want a cog though.
Yes, all things considered … I now think it’s better to make sure that any blocks that are not part of a library’s “functional domain” are both hidden (so as not to confuse users) and cogged (so as to make sure they don’t overwrite like-named blocks from a domain-specific library). This would pertain to some other blocks, too, such as
The forum won't let me attach the file, so here is the link: Snap! Build Your Own Blocks. You can export the blocks from the project; there aren't any extras.
.
.
