Snap! user discussion

Jonathan50

Oh, I asked earlier if you could clone an object without it being deleted when you click the stop button and have it show in the sprite library. The answer (I think) is to enable inheritance support create a new sprite and then right click on the sprite in the library -> parent, or run something like

Not yet a Knight of the Mu Calculus.

PullJosh

bharvey wrote:
PullJosh wrote:
Is this a worthwhile use of my time? (And if so, am I looking for help in the right place?)
Yes and yes!

You might find Unit 1 and maybe Unit 2 a little easy, but hang in there for Units 3, 6, and 7. (Use the http://bjc.edc.org version.) Units 4 and 5 are stuff that have to be in the course to make the College Board happy, and aren't yet up to the standard of the rest of the course.

Awesome! I think I'll skim through 1, 2, 4, and 5, and then take it slow for 3, 6, and 7. Can't wait!

(I think reading through and understanding all of this will be my project for the summer.)

Convert your Scratch projects to JavaScript automatically with Leopard!

bharvey

joefarebrother wrote:
Any tips for optimising Snap! projects?

Avoid using "touching [color]“ blocks; try ”prefer smooth animations." Beyond that, it'd help to know what kind of projects.

Last edited by bharvey (June 8, 2016 15:03:31)

bharvey

Jens wrote:
Making the *computer* do something fast is different from writing something for others to read or reuse.

This is much less true, I think, in a compiled language, which can often generate the kind of code you're advocating from quite abstract source code. The problem of elegance vs. speed arises mainly with interpreters.

Also, in defense of abstraction, in the real world speed is not the only consideration. If the program does something important, it has to run correctly. Abstraction helps with that. This is why human beings aren't entrusted with memory management any more.

Talk with you in a few minutes!

Last edited by bharvey (June 8, 2016 17:55:57)

Jens

Oh, I'm totally in love with abstraction, and I've heard Alan say “fast enough for our neurons” a few times :-) To me personally expressivity trumps raw computing speed almost every time. I'm just sayin' that when people complain about “lagginess” it's often a trade-off between beautiful and fast. You're right about compilers, of course, although getting interactive “liveness” right requires a lot of fine-tuning.

Last edited by Jens (June 8, 2016 21:32:05)

joefarebrother

I just spent hours attempting to optimise and bugfixing some a thing (largely unsuccessfully) then Snap! crashed and I don't know when I last saved

Gonna take a break now until tomorrow…

And it was delicious! Play TBGs! Check out my Scheme Interpreter!
;

bharvey

joefarebrother wrote:
I just spent hours attempting to optimise and bugfixing some a thing (largely unsuccessfully) then Snap! crashed and I don't know when I last saved

Oh no! We were just saying how that's the worst problem we can have, if people can't rely on Snap!. I don't suppose you remember what you were doing when it crashed?

Anyway, I'm sorry.

roynes2012

Is there any tutorials for Codification Support?

I can't seem to find a way to make my codification support work.

I have a block name “move forward” and a variable of code
When I assigned the code to move forward and try it on code of block it just returns a blank.

any help would be most welcome and appreciated

joefarebrother

bharvey wrote:
joefarebrother wrote:
I just spent hours attempting to optimise and bugfixing some a thing (largely unsuccessfully) then Snap! crashed and I don't know when I last saved
Oh no! We were just saying how that's the worst problem we can have, if people can't rely on Snap!. I don't suppose you remember what you were doing when it crashed?

Anyway, I'm sorry.

I think I was trying to work out how slow a particular part of the code was by adding reset timer and add timer to list blocks, and the list got really long and that's when the crash happened.

And it was delicious! Play TBGs! Check out my Scheme Interpreter!
;

bharvey

roynes2012 wrote:
Is there any tutorials for Codification Support?

All there is right now is the Codification project in Open>Examples.

bharvey

joefarebrother wrote:
and the list got really long and that's when the crash happened.

OK, so, it ran out of memory. We probably can't prevent that entirely but maybe we can catch it and fail the operation without crashing. I bet doing that would be browser-specific.

joefarebrother

In Scratch I managed to make a list with about a million items. The Snap! list that crashed my browser was only about 250,000 items I think. On the other hand, some of the items in that list were other lists, and some were sprites, so that might affect it.

And it was delicious! Play TBGs! Check out my Scheme Interpreter!
;

bharvey

joefarebrother wrote:
In Scratch I managed to make a list with about a million items. The Snap! list that crashed my browser was only about 250,000 items I think.

Did you construct it with IN FRONT OF or with ADD/INSERT?

joefarebrother

With ADD

And it was delicious! Play TBGs! Check out my Scheme Interpreter!
;

bharvey

joefarebrother wrote:
With ADD

Ah, then there shouldn't be any difference in size. If you were making a linked list, I'd understand running out of memory sooner. I'll put it on the discuss-with-Jens-Saturday list.

joefarebrother

I also noticed that, prior to even making that list, the IDE was being slow - It was hard to drag blocks properly.

And it was delicious! Play TBGs! Check out my Scheme Interpreter!
;

joefarebrother

I also noticed that a list that was constructed with the LIST block, then called .becomeList() on, doesn't seem to preserve across save/load cycles - An extra element, null, is added. (I haven't tested whether or not it remains linked too)

And it was delicious! Play TBGs! Check out my Scheme Interpreter!
;

bharvey

joefarebrother wrote:
I also noticed that a list that was constructed with the LIST block, then called .becomeList() on, doesn't seem to preserve across save/load cycles - An extra element, null, is added. (I haven't tested whether or not it remains linked too)

If you can make a small project that demos this, it'd be great. File a github issue. Thanks.

joefarebrother

bharvey wrote:
joefarebrother wrote:
I also noticed that a list that was constructed with the LIST block, then called .becomeList() on, doesn't seem to preserve across save/load cycles - An extra element, null, is added. (I haven't tested whether or not it remains linked too)
If you can make a small project that demos this, it'd be great. File a github issue. Thanks.

Sure - http://snap.berkeley.edu/snapsource/snap.html#present:Username=jfb1337&ProjectName=list%20tests

Turns out it affects all linked lists, not just ones that were made linked via .becomeLinked()

GH issue

Last edited by joefarebrother (June 9, 2016 23:09:33)

And it was delicious! Play TBGs! Check out my Scheme Interpreter!
;

edward789121

i need help with the custom reporter

do ::operators cstart

end
for (reporter) ::operators

where it will do something and then report the reporter you put in.

when I receive [Scratch joined v]
cringe
wait ((pick random (0) to (4)) * ((((60) * (60)) * (12)) * (365.25))) secs
leave
wait ((pick random (0) to (4)) * ((((60) * (60)) * (12)) * (365.25))) secs
broadcast [Scratch joined v]

Discuss Scratch