Snap! user discussion

s_federici

bharvey wrote:
Snap! 4.1 is now installed

Cool release! I think I'm going to love first-class costumes

I noticed that in Chrome I can't make the Snap window go back to normal window (with tabs) if I go fullscreen. Going back to normal window works fine instead in FireFox and Edge.

bharvey

The manual is finally done! Now to sleep for a month.

xly

bharvey wrote:
The manual is finally done! Now to sleep for a month.

While you are going to sleep…for us much grain to grid..
Just to start with find attached a project inspired by famous Byob egg-chaser ants projects proposed by Jens 6 years ago .
It shows that Snap! OOP has been considerably improved and simplified particularly thanks to the powerful MYXXXX concept.
Just to start with :
https://snap.berkeley.edu/snapsource/snap.html#present:Username=xleroy&ProjectName=00-ancdrop

ps - I've not found any help or comment concerning “INHERIT” block ???

Last edited by xly (Oct. 23, 2017 16:31:19)

bharvey

xly wrote:
ps - I've not found any help or comment concerning “INHERIT” block ???

Yeah, I have to make the help screens for INHERIT and MY, the last remaining task, I hope. But it's on page 55 of the manual – but somehow it's not in the index. Groan.

xly

bharvey wrote:
xly wrote:
ps - I've not found any help or comment concerning “INHERIT” block ???
Yeah, I have to make the help screens for INHERIT and MY, the last remaining task, I hope. But it's on page 55 of the manual – but somehow it's not in the index. Groan.

OK, Thanks. In fact it is self-explanatory as soon as you make one test application. Then the down-list menu appears and you can play with this instruction. It opens wide areas of applications.

ps - about clone : if you clone a sprite, its clone appears neither in MY CLONES and nor in MY OTHER CLONES.
But if it is released , it leaves the script area and then is visible as a clone…

bharvey

xly wrote:
ps - about clone : if you clone a sprite, its clone appears neither in MY CLONES and nor in MY OTHER CLONES.
But if it is released , it leaves the script area and then is visible as a clone…

Yeah, the naming of those options leaves something to be desired. MY CLONES reports only temporary clones; MY CHILDREN reports all of them. Jens and I have different views about which are more real clones, the temporary ones or the permanent ones. And about whether it's more important to be compatible with Scratch 2.0 or with BYOB 3.1. We'll work it out, and maybe soonish, with luck, there'll be a 4.1.1.

CatIsFluffy

I can't find the upload dialog for costumes or sounds.

djdolphin

CatIsFluffy wrote:
I can't find the upload dialog for costumes or sounds.

You can just drag and drop the files into the editor.

!

bharvey

CatIsFluffy wrote:
I can't find the upload dialog for costumes or sounds.

In the File menu there's an “Import…” option that lets you import anything: a project, a block library, a picture, or a sound.

dieuai30101991

I was having this issue a while ago (I only got notifications for a few topics), but then it starting working again… How could do I fix it ???

Nothing here

Last edited by dieuai30101991 (Oct. 26, 2017 04:01:26)

xly

Coming back again to the discussion on the sprite made by selecting “clone” in the sprite choice list..
It would be preferable to name it “child” rather “clone” for the following reasons :
Words “parent” and “children” are already used elsewhere by Snap! in “MY children” and in many places of the sprite corral.
This sprite has a “parent”
The “child” sprite is not considered by the “parent sprite” as a clone - it does not appear in its “MY clones” but as a child listed in “MY children”…
On top of that its properties are much nearer to independent Sprites than to dependent Clones.
One remark : the list of all children of a same parent (MY Children) is not sorted according to the name of children, if this name is “ordered” (a1,a2,a3..) . I understand the reason as the child name can be anything and not necessary ordered.
It's not a problem for the user as this can be easily“turned around”, (this issue does not exist with clones as they are by nature created “sequentially” ).

Last edited by xly (Oct. 29, 2017 09:11:42)

bharvey

xly wrote:
Coming back again to the discussion on the sprite made by selecting “clone” in the sprite choice list..
It would be preferable to name it “child” rather “clone” for the following reasons

Yes, we've been talking about this issue. It's hard to decide. Here are a couple of arguments on the other side:

1. A clone can be switched back and forth between temporary and permanent. (Right now only from the GUI. I'm for sure going to add a library block that can switch from permanent to temporary. Jens and I are still disagreeing about whether I'm allowed to add a block that can switch the other way.)

2. Most of what the user has to understand about cloning, i.e., the inheritance mechanism, is the same for temporary and permanent clones.

We know the option list in the MY block is incoherent. That'll be fixed, one way or the other.

Jens started out arguing against calling them parent and children because children don't inherit from a parent until the parent dies, so the metaphor is wrong. But it's a universally used metaphor for OOP, and we really couldn't find another one that was nearly as evocative. (For example, if children are called clones, what is the parent called? There's no word anteclone (sic). Arguably the right word is “prototype” but that has so many meanings already it'd be confusing.)

xly

@bharvey

“1. A clone can be switched back and forth between temporary and permanent. ”

When a child sprite of a parent is released, it is no more visible in the sprite corral.OK
But it is still visible on the stage and you can act on it like before (move it for example)
The parent sprite sees the released sprite as a clone in MYclones but also as a “child” in MYchildren.
When the sprite is converted to clone (released) there is no more possibility to update its command scripts (existing scripts are still active)

My question is : how to convert back this released sprite from clone to child sprite with the same parent ?
That means "how to make it again visible in the sprite corral ?

bharvey

xly wrote:
how to convert back this released sprite from clone to child sprite with the same parent?

Right-click on it on the stage, and choose “edit.”

I know, “release” and “edit” are terrible names. “Release” comes from the metaphor of that area at the lower right as a corral, and so you're releasing the clone from the corral. It works once you have it explained to you, I guess. “Edit,” which also works for non-clones, makes that sprite be the one whose scripts are visible in the scripting area, so you can edit its properties. I think there should be a context menu item for all clones “◻︎temporary” (so you'll never see it checked in the sprite corral, but you will onstage).

xly

An example showing how to use NEWCLONE jointly with PEN TRAILS. Credits to Jens…
https://snap.berkeley.edu/snapsource/snap.html#present:Username=xleroy&ProjectName=00-pentrails

Thanks for the means to revert sprite/clone release and by the way to know that a sprite-clone has this right-click menu.
The naming of functionalities is not an issue as soon as you start using them !

Last edited by xly (Oct. 30, 2017 15:03:14)

xly

Slightly more complicated as far as PEN TRAILS is concerned …

https://snap.berkeley.edu/snapsource/snap.html#present:Username=xleroy&ProjectName=140-flowerain

Comparing the 2 projects one can see the difference between CREATE A CLONE OF MYSELF which is a command instruction with NEW COSTUME which is a reporter one, this allowing to put the clone in a script variable with SET !!! Clever.

bharvey

xly wrote:
this allowing to put the clone in a script variable with SET !!!

… or anything:

Basically, reporters are just always better. This is the most unSchemely thing about Snap!, that it even has command blocks.

xly

@ bharvey said “Basically, reporters are just always better. This is the most unSchemely thing about Snap!, that it even has command blocks.”

Brian, don't forget your inheritance !
As soon as graphic interface + “turtle” + Logo (“Lisp disguised in Basic” ), was invented in the early 80' , by brilliant CS teachers like you and others, none could continue with these LIsts of Insipid and Stupid Parenthesis“ (=LISP) and ignore the graphics commands of ”turtle" like MOVE, TURN …

Last edited by xly (Oct. 31, 2017 11:46:19)

bharvey

xly wrote:
As soon as graphic interface + “turtle” + Logo (“Lisp disguised in Basic” ), was invented in the early 80' … none could … ignore the graphics commands of “turtle” like MOVE, TURN …

Oh, we can do turtle graphics in Scheme, but the procedures still return values, even if the value isn't the reason you're using the procedure. It's having two different kinds of procedure that's unSchemely, not having side effects. So, we shouldn't have to have both CALL and RUN, or both ASK and TELL, or (really just for historical reasons) the two CLONE blocks, or the two IF/ELSE blocks, etc.

P.S. As for parentheses, please note that all block languages are, in fact, fully parenthesized. It's just that you don't type the parentheses on the keyboard; you make them by dragging blocks into each other.

tcrass

Hi there,

on the last forum pages I've learned that Snap! is not primarily about speed, but I keep wondering if it was – already today? – possible to increase Snap!'s performance on a Raspberry Pi 3. My kids and me have about a dozen sprites moving around, doing collision detection between one of them and all the others each round, and the animation speed is an estimated 2 fps. It wasn't all that bad before we introduced collision detection, so I guess this is a real bottleneck.

So… any advice on how to speed things up would be appreciated.

Cheers –

– Torsten

Discuss Scratch