General store

I’m looking for a general method to store Snap! data in text format, as a layer upon the Database library. Functions in the Database library accept text and numbers only (and probably numbers are considered text as well).

A “general” method will support all of Snap!’s native data types (IMO a logical consequence of all data being 1st class). By “support” I mean:

  1. any data can be converted to a storable (text) format;
  2. recalled data can be restored without loss of information / accuracy.

Let’s have a look at each data type, and how it can be stored & restored:

  • number, text: trivial;
  • Boolean: would have to be characterized as a separate type;
  • list: JSON-conversion available in Snap! , both ways (but only for list containing numbers, text, Booleans, and sub-lists);
  • sprite (edit): (position, direction, rotation mode, shown?, size, color (?), graphic effects, … ?)
  • costume: fully defined (?) by: name, pixels (RGBA), width, height; available in Snap!.
  • sound: may be defined using a list of samples (?), sample frequency, and duration; but how can that be reported from an existing sound?
  • command, reporter, predicate: @joecooldoo made a converter to text, but the reverse conversion needs help from a library containing the very functions that are recalled; so I’m not sure how this will work.

Suggestions, anyone?

You can get the data, just like a costume, but with the of sound block
untitled script pic (26)

I can see that.

But how can the data this function reports be translated to inputs of
Programming tools DEVLAB script pic 20 ?

The list input is the samples, and the number input is the sample rate.

actually, vector costumes cannot be manipulated in Snap!, so they cannot be converted without loss of data.
(I don't think anyway)

somes examples in this project

Don't work for sprites and blocks

it's a start !

Snap!, of course, already has this capability internally; that's how we save and load projects. One tricky part is making sure to follow dependency chains, i.e., if you serialize a procedure, you have to also serialize any other procedures that the one you want calls.

So my point is, you shouldn't have to invent text formats for things; you can just use the formats that we already use.


first class projects when? /hj

I take the "h" in "hj" to mean that you actually do want an answer to that question, so here it is: Projects can't be first class in a project, because by definition there's only one project in a project. (Scenes are a fairly recent exception, and it would be theoretically possible to consider first class scenes, so a project could create a new scene in itself, but I don't think that actually makes sense either, because you can't edit a scene from within the project; you have to make the scene as its own project and then include it within the larger project.)

If the cloud provided a filesystem, like Google Drive etc., then the filesystem would have projects in it, and it'd be meaningful to ask what first class projects would mean in that context.