I fixed my scheme code testing choose and it works (the problem was that call/cc delimits continuations at the top-level, effectively making every top-level call like a separate script in Snap!, so when fail was called it wasn't looping back on itself, which makes sense: otherwise it wouldn't be possible to capture the top-level continuation in files without also capturing the redefinition of everything below it, so I wrapped a let around the last 2 lines), and now works. The Snap! version is still broken.

Hi!
This project runs fine in both Scratch and phosphorus:
http://phosphorus.github.io/#74483112

However, when I convert it to snap using the converter linked to on the snap front page (http://djdolphin.github.io/Snapin8r2/) it is suuuuuper slow..like 0.5 FPS. It also thakes up 5 GB of memory when I run it!!

So…what kinda blocks or operations should I avoid to make it run smooth in Snap?

Im using the griffpatch approach and only have 1 loop which broadcasts a message, and all the other sprites uses this broadcast in stead of their own loops. Can this be the problem? This technique makes it run super smooth in scratch….but maybe Snap doesnt like this?

Also how do I get the java source code out of snap?

_Milamber_ wrote:

However, when I convert it to snap using the converter linked to on the snap front page (http://djdolphin.github.io/Snapin8r2/) it is suuuuuper slow..like 0.5 FPS.

Try clicking “prefer smooth animations” in the settings menu (the one with the gear icon) and see if that helps.

Also how do I get the java source code out of snap?

You mean Javascript. Click on the Snap! icon in the top left corner and choose “download source.”

_Milamber_ wrote:

Also how do I get the java source code out of snap?

firstly, it's JavaScript, not Java (big difference), and secondly, you can get it by right clicking the Snap! logo, or going to the Github page: https://github.com/jmoenig/Snap–Build-Your-Own-Blocks

bharvey wrote:

_Milamber_ wrote:

However, when I convert it to snap using the converter linked to on the snap front page (http://djdolphin.github.io/Snapin8r2/) it is suuuuuper slow..like 0.5 FPS.

Try clicking “prefer smooth animations” in the settings menu (the one with the gear icon) and see if that helps.

Also how do I get the java source code out of snap?

You mean Javascript. Click on the Snap! icon in the top left corner and choose “download source.”

Checking “prefer smooth animations” does not help. This is a large project, with close to 1000 costumes. Does snap have problem with a large number of small costumes maybe? Are there any known limitations as compared to scratch? and……WHY 5 Gigabytes of memory? Scratch projects cant be that large last I checked :O

Looks like you're cloning sprites with very many (a thousand) costumes. This is going to be very slow in Snap, because unlike Scratch Snap copies every costume every time you clone that sprite, because Snap lets you do some fun things with costumes under the hood. There might be other things in Snap that are slower than Scratch, too, because of all the heavy abstraction support. Not sure about he 5 Gigs, but yes, Snap's xml file format isn't the most efficient when it comes to saving pictures and sounds.

Jens wrote:

Looks like you're cloning sprites with very many (a thousand) costumes. This is going to be very slow in Snap, because unlike Scratch Snap copies every costume every time you clone that sprite, because Snap lets you do some fun things with costumes under the hood. There might be other things in Snap that are slower than Scratch, too, because of all the heavy abstraction support. Not sure about he 5 Gigs, but yes, Snap's xml file format isn't the most efficient when it comes to saving pictures and sounds.

Ah…that makes sense. Thank you for the explanation! Thats probably why it takes 5 gig of memory when running as well….it loads 1000 costumes 200 times into memory….instead of once…like scratch.

Jens wrote:

Snap copies every costume every time you clone that sprite

But that's wrong! Isn't it? If I clone a sprite it should share its wardrobe with the child, and the child should see any bit twiddling that the parent does. If the child wants to mess with a costume, that's when you copy it. No? Am I missing something?

That could sound weird out of context…

But anyway, as variables are inherited on cloning, where the child only needs to get its own copy when it changes, costumes should be the same.

_Milamber_ wrote:

Jens wrote:

Looks like you're cloning sprites with very many (a thousand) costumes. This is going to be very slow in Snap, because unlike Scratch Snap copies every costume every time you clone that sprite, because Snap lets you do some fun things with costumes under the hood. There might be other things in Snap that are slower than Scratch, too, because of all the heavy abstraction support. Not sure about he 5 Gigs, but yes, Snap's xml file format isn't the most efficient when it comes to saving pictures and sounds.

Ah…that makes sense. Thank you for the explanation! Thats probably why it takes 5 gig of memory when running as well….it loads 1000 costumes 200 times into memory….instead of once…like scratch.

bharvey wrote:

Jens wrote:

Snap copies every costume every time you clone that sprite

But that's wrong! Isn't it? If I clone a sprite it should share its wardrobe with the child, and the child should see any bit twiddling that the parent does. If the child wants to mess with a costume, that's when you copy it. No? Am I missing something?

It's the other way around, Scratch copies every costume, not snap.

miniepicness wrote:

It's the other way around, Scratch copies every costume, not snap.

That's not what Jens said.

Jens wrote:

This is going to be very slow in Snap, because unlike Scratch Snap copies every costume every time you clone that sprite…

I never realized how nice 60-frames-per-second user interfaces looked until I compared Scratch and Snap!.

Suggestion: Clones have references to costumes, and to manipulate them individually, the programmer must get the costume data and copy it, so that passing by value is only used when necessary.

liam48D wrote:

I never realized how nice 60-frames-per-second user interfaces looked until I compared Scratch and Snap!.

That's what “prefer smooth animations” does.

Chibi-Matoran wrote:

so that passing by value is only used when necessary.

Hi, good to see you again, you kind of disappeared for a while.

Value vs. reference isn't the problem here. (As in all Lisp dialects, Snap! uses call by value, but the values are pointers to the actual data. (But not pointers to variable bindings, as in call by reference.))

The question is whether manipulating a costume of one sprite should affect other sprites in its family. And the Snap!-ish answer is that a change made by a parent is visible to its children, but a change by a child copies whaatever the child is changing, so that its siblings and parent aren't affected.

bharvey wrote:

Jens wrote:

Snap copies every costume every time you clone that sprite

But that's wrong! Isn't it? If I clone a sprite it should share its wardrobe with the child, and the child should see any bit twiddling that the parent does. If the child wants to mess with a costume, that's when you copy it. No? Am I missing something?

IMO there are several answers to _Milamber_ question.
In general terms Snap! is like a double-face coin. One face is a high level new scheme-like programming language ideally done to learn and put in practice the toplevel principles of CS. This aspect is at core of present “topic” (Snap! user discussion) animated by “restless” Brian Harvey. The issue there is more “intellectual performance” than “processing performance”.
The other face, under-represented here up to now - is the Scratch like aspect with its billions of projects where kids can foster their creativity and artistic skills in many different fields while learning programming basics. Jens is the no debatable maestro with his incredible applications as illustrated in three recent papers : TablesInSnap, SnapExamples and FirstClassSpritesInSnap.
In both cases to create a Snap! project should give pleasure to his “composer”, all together interesting and instructive (docere ridendo). Compared to some usual languages, Snap! is probably not the “top dog”, But it is certainly the most clever. This being said the configuration of your PC is not indifferent. With my cheap chinese PC Box with a very limited 2 Gb RAM including Windows 10 (!!!) I can't set up less than one hundred clones where for the same project Jens uses at least 1000 ! . On the other hand Jens has demonstrated in several occasions that Snap ! performed better than Scratch.

xly wrote:

The other face, under-represented here up to now - is the Scratch like aspect with its billions of projects where kids can foster their creativity and artistic skills in many different fields while learning programming basics.

I agree that that's terribly important also. And I've often agreed to put up with theoretically suboptimal things for the sake of performance (e.g., the 100-items-at-a-time list watcher (now obsoleted by the table view)).

But in this case, I claim that the theoretically correct thing is also the efficient thing! Namely, not copying anything (except pointers) when cloning a sprite.

We need to hear from Jens about why he disagrees, if he does, as it sounds in his message above.

Jens wrote:

Thank you so much for the Indonesian translation!
I've just finalized the release and put in online. Please make sure to flush your browser caches and enjoy the new release.
http://snap.berkeley.edu/snapsource/FirstClassSpritesInSnap.pdf

Nice then

Yay, first-class sprites have been released!

Chibi-Matoran wrote:

Yay, first-class sprites have been released!

First class everything is the best