Scratch

@Jens &bharvey
Snap! computes 360 values of sin x with Cordic algorithm. This needs to calculate for each value a matrix of 3 columns + 24 lines.
1st case - The 360 values are calculated "one by one" and displayed with a graph. It takes 144 s.(5.3 s with warp)
Then these 360 values are stored into a list (each item is a list of sin+cos).
2 - The 360 sine values are extracted from this list as to display the with the same method as before. Then the time is 114 s ! The time to only extract 360 values from one list is 80% the time needed to calculate these values...It seems surprising and need further investigation .

bharvey wrote:

roijac wrote:

how does he actually implement saving?

Umm.  We have code already to take one Snap! value and turn it into text.  Next thing is to take a list of starting points (all the global variables plus some system things) and serialize (turn into text) all of them.  Finally, a way to direct this either to a URL for uploading or to a Javascript sandboxed local file.  (We'll provide a separate program you can use to run a server on your machine that connects only to your local Snap! process and turns URLs into filenames, so people who aren't worried about security can save to real files.)

n?  You want to say more?

Right now we're using JSON, so I convert all the morphs into their representations as plain objects, then serialize that using the built-in JSON.stringify(). To load, I convert the representations serialized in JSON into the real objects (this gets complicated because some initialization methods rely on the morph already being in the world...) and swap the stage (the base object which is saved) with the one currently in the world. People with modern(ish) browsers get the feature that they can load projects directly from URLs, i.e.,  every time they save the project the URL is updated to include a long hash part with the project in it. They can then just copy-paste the URL to share their projects.

Last edited by nXIII (2011-12-06 19:59:15)

bharvey wrote:

nXIII wrote:

a long hash part with the project in it.

"Long" is definitely the word for it!  Will this really work once we have multiple sprites, costumes, and all that?

I believe so, because the hash part is used only by the client (it doesn't have to be sent to the server, which can really limit the URL length) so there is no real limit on its size.

Super...

roijac wrote:

why not integrate a bitly as saving process? 

Maybe as an option, but most of the time when I save something it's not really ready to share with the world.  And we privacy fanatics don't like building automatic sharing of information with advertising scrapers into systems.

xly wrote:

"It doesn't have to be sent to the server, which can really limit the URL length, so there is no real limit on its size."

Why have we to send our application to a server. As far as I know I can already use Snap! off-line (which may be useful if I must spend some time in a remote place were the web is not available) ? Why not create, run and save our application locally ?

You can use it offline (the color sensing throws some security errors, but hopefully we'll fix that), in which case nothing is sent to any server. However, if you use a version hosted somewhere, the hash part of the URL isn't limited in length (like the query string or the URL itself)

iTweak0r wrote:

i'm trying the BYOB thing in Snap! and i cant get pass the block spec dialog (it does not let me press OK).

It's not done yet.  Watch this space for announcement.

Ooh... custom blocks! 

Now waiting for the OK button to do something. 
(In case it's just my browser's fault, at the moment it just puts the window-let into a drag mode.)

OK button works now. 

ff worked 

So, my mom got a Kindle Fire for her birthday, and I thought I'd report how it runs Snap! 

For the most part, its dual-core processor has no trouble with it. However, the tablet doesn't have the touch-precision of an iPad, and therefore, I had great difficulties with simple tasks like selecting the variable in the "set" block. Zooming in and out definitely slows down the Fire, but it doesn't have any problems with scrolling through the block panes or touch and drag. I have yet to try running a project, but I'll get to that later.

Just so you know, it doesn't use the default Android web browser. Instead, Amazon opted for a new one called "Silk", which uses Amazon's servers to do the web page lifting.

Oh, one more thing. The 1024x600 can't really fit all of Snap!'s content, and I was forced to switch between portrait and landscape mode occasionally.

I'm really happy about all those dual (and soon to be quad) core tablets coming out! They really maximize HTML/JavaScript potential and value. 

Try making a block with a one letter name.