Scratch

I just downloaded the latest draft manual for Snap! I think that having to download new versions is clumsy. Would it be possible to publish the manual in the way O'Reilly books publish using the Open Books Project. This would mean the manual would allow direct feedback from readers and there would always be a current version available.

bharvey wrote:

blob8108 wrote:

...feature request: clicking noises!

It'd be cute for the first five minutes; then it'd drive you crazy.

When you put attach something directly to a hat block. 

Lucario621 wrote:

bharvey wrote:

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

Is that an insult to my signature?    I don't think I ever thought of it as coming "out" of my head! xD

No, maybe just going in. Ouch!

Jrocket97 wrote:

A lot of the blocks on toolsprite should be standard, quite frankly.

Yeah.  We're going to divide the toolsprite into categories, one of which will be loaded automatically.  So the user sees them all the time, but can still read the implementation if she wants.  FOR, FOREACH, MAP, KEEP, COMBINE, ASK, TELL are at the top of the list.

Another thing is, is there any chance stretch, pointillize, and other obsolete parts of the scratch code could be added to snap?

One of my goals is first class costumes with access to the bitmps, so Snap! users should be able to write graphics effects themselves.  So providing any particular effect as a primitive is less important on my list.  But neither will happen in 4.0; most likely, 4.0 will be like 3.0 and we'll need a 4.1 to get back to the stage of 3.1, let alone do new things.

Zooming in on the stage and panning would also be nice features.

Changing the stage size is in the works right now, but apparently it's hard to make it both fast and beautiful.  Perhaps fullmoon or Jens will want to elaborate on that answer?

OldCodger wrote:

Counting from 0 is mostly associated with immutable data structures like arrays, where you use an index to get at the elements. Lists are mutable data structures and the classic way to use lists is by recursion.

Don't be overinfluenced by the fact that Scratch calls them "lists."  Scratch lists are really dynamic (resizable) arrays, so indexing them is constant time.  So are BYOB lists.  But Snap! lists are hybrid; under the hood, we have both dynamic arrays and linked lists.  If you cons (IN FRONT OF) together a list, you get a linked list; if you build it imperatively (ADD TO LIST), you get a dynamic array.  You can cons onto a dynamic array and it works -- the user never has to know that there are two implementations -- but your program runs a lot faster if you are consistent about how you use any one list.

So the index origin issue does have to be settled. 

bharvey wrote:

Lucario621 wrote:

Is that an insult to my signature? 

Nah, the insult to your sig was a couple of pages back (#5207).  This was just explaining the joke to Scimonster.   

You could have linked instead of just giving the post/topic ID.

shadow_7283 wrote:

Will they be implemented with morphic? For loops can be pretty slow even when run "atomic".

Are you talking about BYOB speed, or Snap! speed?  I definitely want to make it so you can write a serious program in Snap! and have it run fast enough -- maybe not optimized C speed, but at least Lisp speed.  For example, I want you to be able to write your own sprite visual effects by manipulating the bitmap directly, pixel by pixel.  Already Snap! is way faster than BYOB, and over time it's going to get even better, compiling into JS for examp

le, and if that's not good enough, compiling into machine language (which would mean a standalone version, I guess, unless you can load Firefox plugins on the fly by then).

So, no, I don't want to add JS primitives for things that can be written in Snap! itself.  If anything, we might go the other way and turn redundant Scratch primitives (e.g. CHANGE var BY) into autoloaded, written-in-Snap! tools.

By the way, what do y'all think about WARP as a user interface?  It has the advantage of giving you finer control over which parts of the code are warp-speed, but on the other hand it loses the reporters-atomic-by-default behavior of BYOB.

@bharvey & Jens
I could no more Save my projects, even a simple and small one !
The message was " Save Failed error : quota_Exceeded_Error : Dom Exception 2"
But I still was able to Reload the xml copy of these projects.
I had several projects already saved, some rather big with their pictures.
So I've suspected that Snap! had not enough "room" to save additionnal projects.
I have deleted a large part of them.
Then I have reloaded the xml copy of some of them.
The projects which beforehand caused Save errors could be Uploaded with their xml copy and normally saved without errors with the Snap! Save feature.

xly, it sounds like Chrome (that's what you use now, right?) won't allot snap.berkeley.edu any more space in LocalStorage.

I just realized: one really useful feature that's been left out of snap!: Mesh!

joefarebrother wrote:

I just realized: one really useful feature that's been left out of snap!: Mesh!

Right, definitely on our list, but unlikely in the August release.
Right after that (which is hugely driven by what we need to teach
our course at Berkeley), we'll start on 4.1, which will recover all
the missing 3.1 features.  After that, to infinity and beyond. 

P.S.  Otoh, some sort of networking may be in by August because we'd like to have a more robust way for people to store projects.

Last edited by bharvey (2012-05-30 22:00:42)

joefarebrother wrote:

I just realized: one really useful feature that's been left out of snap!: Mesh!

Well I sent this off to the Snap! mailing list but I suppose you all will probably find this interesting too...I wrote a re-implementation of Mesh for Snap! using a WebSockets. It's not quite like Scratch's Mesh, since the server is an external program and not part of the IDE itself, but it's rather more flexible. These are the blocks I included:

join mesh at [host]
Attempts to connect to the Mesh server at the remote address host.

leave mesh
Disconnects from the current mesh

send [message] to [List|String clients]
Sends the message message to all clients in clients (may be an address or list of addresses). Currently this causes all clients that receive the message to broadcast [message], although when Jens invents hat blocks with upvars, this could get its own hat block.

set global [var] to [val] in mesh
The Mesh server keeps a hash of global variables that can be set by any client. This block sets the value of the global hash at var to val.

set my [var] to [val] in mesh
The Mesh server also keeps a hash of variables unique to each client that can be set by that client and queried by any other client. When a client disconnects, their local hash is destroyed and its contents are irretrievable even if they reconnect from the same address. This block sets the value of the client's hash at var to val.

global [var] in mesh
Returns the value of var in the global hash.

[var] of [client] in mesh
Returns the value of var in client's hash.

others in mesh
Returns the addresses of all clients connected to the mesh except for the local client.

my address
Returns the local client's address as seen by the Mesh server.

mesh status
Returns a string based on the value of the Mesh's webSocket's readyState property:

"connecting" if readyState == 0
"connected" if readyState == 1
"disconnecting" if readyState == 2
"disconnected" if readyState == 3

These strings correspond to the meanings of the readyState codes as described in the WebSocket specifications.

You can download the changeset here and include it in your local copy of Snap! by adding the following in the <head> tag of nasciturus.html:

<script type='text/javascript' src='mesh.js'></script>

This will add the mesh blocks to Snap! The server is Mesh.rb...if you're not sure how to run a Ruby file, see here. While the server is running, anyone who knows the IP address of the computer running the script can join the mesh.

Like Brian said, this is unlikely to make it into the August version...Jens is working hard on making Snap 4.0 look like BYOB 3.1 and I suspect that dealing with a horde of new blocks is the last thing he needs. However, it's certainly fun to use and I thought I'd leave it here for you guys to tinker with! 

Will Snap ever be offline?

xly wrote:

Rather spending cool holidays in south of France : -)

A short holiday.  Then back to the salt mines!