Making the database library able to store anything


Should be fixed now!

Does it work?

Since you are building a layer on top of the primitives, you can wrap values in such way that “false” as a Boolean can be discerned from “false” as an indication of a no-hit. Likewise you may want to discern the text “[2]” - note that quotation marks are NOT part of the text! - from “[2]” as a json-equivalent of a list with one element: the number “2”.

What you could do is prefix a type-indicator to each value. Positions within the following list indicate the type numbers as used e.g. by Snap! itself:

Since there’s over 10 types, you may want to code them, e.g. as a letter. In this scheme, “1” is stored as “A1”, “false” as “Bfalse” (or perhaps “B0”, with “true” as “B1”), a list with elements “1”, “2” and “apple” would be stored as “C[1,2,”apple”], and so on.

Adding to my post #43: considering a list may contain any combination of Snap! data types, while json only supports lists (including sub-lists) containing text, numbers and Booleans … the next step to a universal Snap! data storage facility would be recursive list processing.

Perhaps something like:

BTW in this example, lists are not preceded by a type indicator.

You fixed the error I reported, but there’s more errors in the code. I think you should do some proper testing by yourself first, then ask others.

If you use the json of and split by json, it automatically detects the difference between booleans and text.

The trick is, it doesn't put quotes around the booleans, only the text.

I'm also getting this error

True. But that works only when a Boolean is part of a list. Besides json doesn’t support all of Snap!’s data types.

Yeah, that's true.

I can actually do the custom block thing, but there is one thing I do need
Databasemore stuff script pic 3
This reports the index of each item where the booleen is true as a list
So for example let’s say I have a list of a bunch of booleens, if I did

This would report a list of the indexes of where each booleen set to true is inside the list
I kinda need someone else to write this, I could maybe but it would take a while

You mean, like this?

Yep! Thank you very much!

Update, I got the thing to kind of work ish?
It’s a start but it only works for blocks that have 1 stack block as their definition as it only reports the first block with whatever inputs are inside it

IT WORKS!!!!!!!

Databasemore stuff script pic 7
Almost.. as you can see the “with inputs” isnt kept, well it is but it gets erased there’s no way that I can tell to properly do that as “run” doesn’t work with “join”
Here’s a version what works “with inputs”

As you can see with these. join needs the block ringifyed

Does anyone know a way around this?

I’m not sure if it helps, but perhaps my recent observations may increase your insight as to how blocks are turned into lists and vice versa, and associated quirks.
I’ll have a look at your INTO DEFINITIONS block one of these days, that may help me understand as well :smirk:
Other than that, all I can say is: metaprogramming Snap! is mostly a matter of trial and error learning by doing.

Btw where can I find a working version of INTO DEFINITIONS ?

It’s actually inside the “databasemore stuff” project
I’m still working out a way to make the run stuff work

Currently stuck on getting the variables that need to be run to work with the blocks

So I found something interesting! It turns out for the run block to accept the blocks they need to be double ringifyed!

So now


It only took me like 3 hours

Shouldn't there be WITH INPUTS: (INPUT) in there somewhere?

@cookieclickerer33: When definition code is in list format, input parameters are either the final items of the list (if the code consists of a single block), or the final sub-items of item 1.
I don’t think this is officially documented for users.

Yeah I think the final implementation was about a day before the release so nothing is very well documented. I'm spozta fix that too, between now and Snap!Con. :~(