but it has issues with local blocks
That’s because they are the same blocks, and that’s all that item 1 is, the block itself, not the inputs
As do most things
It's a bug (post #1). Better have the Snap ! development team look into it.
Yea it’s a bug, but why does it happen?
From the looks of it it’s only evaluating the last item in the block stack
I think this is because as I said earlier, snap sees block stacks inside rings as a sort of list of all the blocks, so if a block isn’t intended to handle lists in this way than it just goes off the last item
I have just confirmed, it’s definitely only evaluating the last block in the stack and ignoring all others.
You can test it yourself it’s definitely the case or at least looks like it
Depending on what version this originates from I suspect it has something to do with the vardradicness of the equal to block
Oh, then its not useful
Actually it seems the equal to block has been Unhyperized in the update that did this
This could be the root cause of the problem
The grater than blocks work fine still
In my personal opinion every block in the library should be hyperized because it just makes more sense
Are you sure it ignores all others?
Looks like these blocks must be the same
I ment it only evaluates the inputs on the last block in the stack
okay, but that makes that bug useful again
It’s still a bug, there no reason the block shouldn’t be looking at the inputs
There’s really no use for this as the answer will always be the same because you cannot manipulate it
Block made using this bug. Useful for detecting local blocks from variables, because if you split a local block to reset its inputs and set it to variable the project wont be able to load, so with that we can put local block to variable without resetting its inputs, and then use that to detect local block
Made a block that temporary will fix that bug
I don’t quite understand the use case when you can still just use split by
There are a handful of blocks that already had meanings for lists as inputs before we had hyperblocks: =, ≠, identical to, is _ a _?, and join. For example, = applied to two lists checks whether the entire list is equal to the other entire list (apart from this bug). (JOIN (LIST A B) (LIST C D)) is (A B C D), not ((A C) (B D)). These are primitives, not in any library. The APL library provides scalar (hyperizable) versions of those blocks.
So you are confirming that this is how snap is coded? That stacked blocks inside rings behave as lists?
Adendum to this, I think that every data type should (when called as one) be a list with 1 element so you don’t need to convert it into a list
This basically would just convert any data type slotted into a list slot into a list no matter what
“Is a list” would report if it has more than 1 element
No. I was answering your suggestion that all blocks should be hyperized by explaining why some aren't.
imagine putting a block inside of other block using join, for split with 2 inputs it would be harder than for custom block with 1, also it just looks nice