is a block programming language inspired by Scratch but extended with first class procedures, first class lists, and other capabilities designed to support the teaching and learning of computer science. This topic is for Snap! users to post questions, comments, and general discussion of the language.

This topic is obsolete – we now have our own forum at
https://forum.snap.berkeley.edu

Learn more about Snap!.

Try Snap! in your browser.

Report (or fix!) bugs at https://github.com/jmoenig/Snap--Build-Your-Own-Blocks.

Snap! is developed by Jens Mönig with the help of Brian Harvey and an ever-expanding team of Scratchers. It is sponsored by the University of California, Berkeley, with support from the National Science Foundation and SAP.

Yay, we're back! Do we get a “BYOB discussion thread”, too?

blob8108 wrote:

Yay, we're back! Do we get a “BYOB discussion thread”, too?

What for? Downloading is sooo obsolete. xP

Hey, gang, this thread is for users!

This other thread is for us to chat.

bharvey wrote:

Hey, gang, this thread is for users!

This other thread is for us to chat.

Um… I'm not a Snap! dev…
BTW, your link is messed up.

Oops. Fixed.

You're an old friend, and chatting – that sort of counts. Maybe I should have said “this other thread is for meta-discussion about Snap!-related threads.”

Just as a matter of interest (and to while away the time while waiting for this site to come back up) I tried Snap on my Note 2 Chrome browser and it seemed to stand some chance of working!

I could drag a couple of blocks out and made the arrow spin

But the display was very very zoomed out ,like it was assuming I had a large 1380x960 type desktop, and it wouldn't let me zoom in so it made life very difficult (especially since I wasn't wearing any glasses!

Are there any plans to male Snap functional on Android phones?

Simon

SimpleScratch wrote:

Are there any plans to make Snap functional on Android phones?

Oh, absolutely. It works pretty well on my Nexus 7 tablet (zoom and all) except for an annoying Android bug that results in Snap! getting some characters but not others from the virtual keyboard. (Works fine with hardware keyboard.) And it works fine on iOS devices.

What we've barely thought about yet is a phone-specific UI for tiny screens, such as separating the stage view from the script view. Right now we're just depending on zoom. Maybe later.

Do you know about Catroid? It's a phone-specific Scratch-inspired language.

EDIT: Also, presentation mode (just the stage) works, and you can program a phone app on your computer, save it to our cloud server, and one-click start it in presentation mode on your phone (with a desktop URL shortcut).

bharvey wrote:

SimpleScratch wrote:

Are there any plans to make Snap functional on Android phones?

Oh, absolutely. It works pretty well on my Nexus 7 tablet (zoom and all) except for an annoying Android bug that results in Snap! getting some characters but not others from the virtual keyboard. (Works fine with hardware keyboard.) And it works fine on iOS devices.

What we've barely thought about yet is a phone-specific UI for tiny screens, such as separating the stage view from the script view. Right now we're just depending on zoom. Maybe later.

Do you know about Catroid? It's a phone-specific Scratch-inspired language.

EDIT: Also, presentation mode (just the stage) works, and you can program a phone app on your computer, save it to our cloud server, and one-click start it in presentation mode on your phone (with a desktop URL shortcut).

its really slow on htc explorer (although its probably because there's hardly any RAM)

joefarebrother wrote:

really slow

On my phone, too. But all that will change since we sent Jens an Android tablet.

@ bharvey & Jens
The sprite Paint Editor is implemented.
What the new “yellow” message block is used for ?

xly wrote:

@ bharvey & Jens
The sprite Paint Editor is implemented.
What the new “yellow” message block is used for ?

https://github.com/jmoenig/Snap--Build-Your-Own-Blocks/commit/d267b696af1e7a429c4b31dc87b46dc638c3509f
It reports the most recently broadcast message.

I don't really see why we need it—broadcasts are events, not variables. If you're using this a lot, you're probably doing something wrong.

EDIT: Hehe, the past participle of “broadcast” is “broadcast”

nXIII wrote:

https://github.com/jmoenig/Snap–Build-Your-Own-Blocks/commit/d267b696af1e7a429c4b31dc87b46dc638c3509f

The forums messed up the – in your link

Yeah, you should do something like -[]- for dash-dash (prays BBCode works right).

you can use the new “message” reporter to build the notorious “I receive ___” block.

The new feature I'm experimenting with is the “any message” choice in the “When I receive” hat block's drop-down menu. This will trigger the attached script in the event of any message regardless what the message is. You can then use the new “message” reporter to let your script find out more. Another use case is for the “message” reporter to be inside loop conditions, so you can let a script do something until a certain message happens (but remember this is tricky if messages get fired rapidly).
BTW messages can be strings, but they can also be anything else, lists, blocks, numbers, so this might be something fun to play with, too.

the Paint Editor has been contributed by our very own Hardmath123 and builds in part on pioneering done by nXIII.
Isn't it awesome?!!

nXIII wrote:

xly wrote:

@ bharvey & Jens
The sprite Paint Editor is implemented.
What the new “yellow” message block is used for ?

https://github.com/jmoenig/Snap–Build-Your-Own-Blocks/commit/d267b696af1e7a429c4b31dc87b46dc638c3509f
It reports the most recently broadcast message.

I don't really see why we need it—broadcasts are events, not variables. If you're using this a lot, you're probably doing something wrong.

EDIT: Hehe, the past participle of “broadcast” is “broadcast”

Now I understand how “message” can be used :
If message = A do A
If message = B do B
etc
If the two IF instructions are included inside a FOREVER loop, message acts like a trigger.
It is a significant improvement compared to the “hat” instruction “WHEN A is received” which can't be inserted into a script

Jens wrote:

you can use the new “message” reporter to build the notorious “I receive ___” block.

The new feature I'm experimenting with is the “any message” choice in the “When I receive” hat block's drop-down menu. This will trigger the attached script in the event of any message regardless what the message is. You can then use the new “message” reporter to let your script find out more. Another use case is for the “message” reporter to be inside loop conditions, so you can let a script do something until a certain message happens (but remember this is tricky if messages get fired rapidly).
BTW messages can be strings, but they can also be anything else, lists, blocks, numbers, so this might be something fun to play with, too.

Very funny ! (Snap! for fun ….). For example …
SET lisa TO LIST (x position, y position)
BROADCAST lisa

WHEN I RECEIVE any message
SAY Hello FOR 2 SECS
GOTO (50 + ITEM 1 of MESSAGE , 50 + ITEM 2 OF MESSAGE)

But…messages are events. If you want to pass arguments or blocks or switch on values or whatever, use custom blocks or LAUNCH (depending on which evaluation model you want).

<I receive ___?> isn't what broadcasts are for, either. For example, the SAY block will (confusingly) never run here:

when ⚑ clicked
forever
broadcast a
broadcast b

when clicked
forever
if <I receive [a]?>
say [This will never run]

However, if you use an event hat block, it will work as expected:

when ⚑ clicked
forever
broadcast a
broadcast b

when I receive [a]
say [This will run]

There do seem to be some performance issues. Sometimes block dragging will mess up. Other than that, it's awesome! I love how I can finally use something like this on my ipad!