Scratch

bharvey wrote:

EvilGenius wrote:

I was thinking about trying to implement one of my favorite programming constructs, call-with-current-continuation, in BYOB.

We're way ahead of you!

http://cs.berkeley.edu/~bh/callcc.png

It's a primitive in the coming Snap! 4.0.

But call⁄cc doesn't actually remember variable values; it remembers binding locations (environments), whose values can be changed by mutation (set!).  So our call⁄cc doesn't have to make copies of all the sprite variables; that's not part of its contract.  You could make an argument that it should remember which sprite it's talking to; I hadn't thought that through.  (Jens?  Will the currently active sprite be part of the environment when we have multiple sprites in Snap!?)

Great to find another Schemer here! 

Although I don't entirely understand call/cc yet it looks pretty cool 

roijac wrote:

http://i.imgur.com/8qcVN.png
3D! :DD
install rookwoods script to view this 

EDIT: two weeks without any changes - are you no longer working on the nasciturus, or just taking a break?

Why should Jens stop working on Snap! after so much work for him?

rookwood101 wrote:

I don't even understand what the warp does 

As in Scratch, each Snap! thread yields control so another script can run whenever it reaches the bottom of a loop.  This is why, for example, you can say

FOREVER
    TURN 15 DEGREES

FOREVER
    MOVE 10 STEPS

(those are two separate scripts running in parallel) and what you see is a perfect circle, because the first FOREVER runs its script once, then the second FOREVER runs its script once, etc.  (There's a lot more to be said about script synchronization in Scratch; it's one of the several amazing pieces of design work by the Scratch Team that you never notice because it does exactly the right thing.   But this is enough for our purposes right now.)

Frequent and controlled yielding by scripts in Scratch is absolutely the right thing in every situation, because you can't write reporters, and you generally want command scripts to pause pretty often not just for other scripts, but to allow the redisplay of sprites, so that they move smoothly instead of just jumping to wherever they belong at the end of your program without showing you the intermediate steps.

But in Snap! you can write very complicated reporter scripts (or, what comes to the same thing, very simple scripts that behave in complicated ways because of recursion) and you don't want pauses all through them; you want to compute the desired value as quickly as possible.

So, what WARP does is to make its enclosed script run all at once, without ever yielding.  (Well, actually, just in case it runs forever, we force it to yield every 10 seconds or so.  But that's a long time for a computer.)

Simple example if the above doesn't make sense:  Try

REPEAT 100
   MOVE 1 STEPS

and then try

WARP
   REPEAT 100
      MOVE 1 STEPS

The first one will glide across the stage; the second will just jump, even though supposedly the sprite is still taking 100 separate steps.  And this happens because the non-WARP version pauses after each time through the REPEAT to allow redrawing, while the second doesn't pause until it's all done.

PS  That picture-drawing script is awesome, besides finally getting me to download Greasemonkey. :-)

PPS  No, Jens hasn't stopped working on Snap!. but every once in a while he does have to pay attention to the rest of his life for a while!     Plus recently his computer died.

Lucario621 wrote:

why is the exclamation mark necessary?

Hi!  Long time no see.

Oh, I don't know, maybe nobody will like it except me, but "Snap" is such a generic name (try Googling it) and also this makes it kind of onomotopoetic.

WARP isn't really so new; it's just a way to get Scratch's turbo mode with more control over what's pause-free and what isn't.  And it's equivalent to the "atomic" check box in BYOB.  Jens invented it back before there was even a beginning of a block editor in Snap! so that people could run interesting programs fast without a new user interface feature.

bharvey wrote:

PPS  No, Jens hasn't stopped working on Snap!. but every once in a while he does have to pay attention to the rest of his life for a while!     Plus recently his computer died.

just wanted to know if he's just taking a break or working on alpha 

rookwood101 wrote:

bharvey wrote:

stuff

I thought it was going to be a very complicated programming concept (like call/cc) but it's just a very useful feature, so thanks!

PS thanks

PPS we can only hope it will be fixed/replaced soon!

?

ah, ok 

bharvey wrote:

rookwood101 wrote:

PS thanks

OTOH now when I go to a forum page Firefox says it's "not XSS secure."

Did you install his script, and then view some page that had code in it to do that?

@bharvey & Jens
In the good old days Byob had a "compile" feature.
It seems that it does not work with recent OOP extensions.
Anyhow, my question is now for Snap! : is it possible to compile one Javascript application into one executable *.exe ?

xly wrote:

@bharvey & Jens
In the good old days Byob had a "compile" feature.
It seems that it does not work with recent OOP extensions.
Anyhow, my question is now for Snap! : is it possible to compile one Javascript application into one executable *.exe ?

Snap! could save the project as an HTML page, and then you can open it in your browser. Not an .exe, but close enough. And you don't need to worry about compatibility between systems!

rookwood101 wrote:

you might have to update the script, the newer version is much more secure.

Ah, thanks, that fixed it.  You must have updated it really recently! 

I've made a cleaning of my "Byob Tutorial" and particularly the "egg ant cleaner" example which uses all OOP features of Byob.
See : http://www.xleroy.net/ByobTuto/thumbnails.html