Nice! It may help me rewriting my automatic memoizer (in which I found a bug recently). However, I mentioned it as an example of several new (and even older) blocks that don't come with online help.
My idea was there must be more or less stable modules, but perhaps that's not how you work. Like @cymplecy says: it's not my project.
Almost. The developer of Beetle 3D still wants to add collision, and without collision blocks here yet, it will be more difficult to make with correct collsision.
i cant find that block in beetle 3d. where is it?
The right way to think about it is that "beta testing" is a quite late stage in the development of a project. When you start seeing version numbers such as "10.0-rc1" in dev, the "rc" stands for "release candidate," and that's when we're in beta.
The restricted environment library (the one everyone else on the team calls "microworlds" even though it's quite the opposite of real microworlds) is still very much in active development. There will be documentation when there's a stable iibrary to document.
That block must have been a custom block, and not from the library. Where do you get this from?
My guess is that it was renamed to (beetle view).
Dragging it into the Snap! editor just makes things a bit weird.
but how do you even drag it into the editor? (if you are talking about the REAL current scene block.)
I have a question about the new Lisp parsing feature.
If I make a custom block, is there any way to change the label it uses in Lisp? (E.G. a block like [scratchblocks] (get $file [/bin/bash] ::list) [/scratchblocks] would be ("get $file _" /bin/bash), but I would like to be able to change it to (get /bin/bash).)
Nope. Ideally all blocks would just use their labels, and might end up doing so in a future version when we find another way to avoid name conflicts with primitives. The idea of the Lisp syntax is to help us write Snap in itself and to interface to AI models. If you want to design your own text based language, use codification instead.
Okay. Thanks. (I'll just write a conversion layer.)
This works:
I would, but I'm too lazy.
Oh, by the way, I noticed that there are some issues with variadic inputs (that still make it impossible to count how many inputs are in variadic inputs (without editing the definition of course)).
Yes, I know I'm not supposed to do bug reports yet, but I feel like this is something that should be fixed early on, at least if you're going to be using the lisp code to define the primitives.
you can have as many variadic inputs in a block as you want. However, if you want to reason about them and use meta-programming, please only ever use one per block. That has been the convention since the beginning of BYOB.
I personally think that if you're going to provide metaprogramming, you should at least make it so that the information I get, matches the block, and I'm able to use that information to build a copy of the original block without relying on the hope that users will use only 1 variadic input at the end of the block (because that's not the case).
Uhhh, I opened the Dev editor, then picked up the block and dragged it in.
Huh? We didn't have metaprogramming in the beginning of BYOB.
but we did have the rule that a block should only have at most one variadic input and that it should be the last one, because when used inside call _ with inputs and collapsed it gets assigned all the arguments.
Hmm. I am so losing my memory of our BYOB 3 design discussions. But I guess you're right about CALL WITH INPUTS.
I like that song it’s a good one
Song?
