Discuss Scratch
- Discussion Forums
- » Advanced Topics
- » Snap! user discussion
- dimasik5472
-
2 posts
Snap! user discussion
Has anyone done tic-tac-toe? I can not and I want to see the script
- bharvey
-
1000+ posts
Snap! user discussion
Would you like to share what you've tried? You can find lots of tic-tac-toe programs in Scratch, but it's best if you get your own working. Has anyone done tic-tac-toe? I can not and I want to see the script
- gdpr533f604550b2f20900645890
-
1000+ posts
Snap! user discussion
Am I able to restrict the scope of an upvar to the custom block?
Can I have a variadic sequence of tokens in the custom block?
Can I have a variadic sequence of tokens in the custom block?
{(upvar) = [] would be repeated.
} where (foo) = [] (bar) = []@delInput@addInput ::variables
- bharvey
-
1000+ posts
Snap! user discussion
Short answer: no and no. Am I able to restrict the scope of an upvar to the custom block?
Can I have a variadic sequence of tokens in the custom block?
The scope of an upvar was one of the arguments Jens won. His view is that an upvar is a kind of script variable, and so its scope extends to the end of the script in which it appears. He compromised by agreeing that a later declaration of a script var/upvar with the same name makes a new, distinct variable, which is important if you export a lambda using the upvar.
As for a variadic grouping, we both want that, but haven't worked out a notation we're happy with. One of those things on the “after OOP is done” list.
- Programaster20
-
99 posts
Snap! user discussion
Im trying to import a game i made in scratch to snap but it won't work. can someone help?
- TruDev
-
80 posts
Snap! user discussion
I'm sorry if this question has been asked before, but when Scratch 3.0, which will also be HTML5, happens, where will Snap! go? Will it stay Morphic.js? Or will it be a pure Scratch 3.0 mod based on the blockly architecture?
Also, should we share Snap! projects on this thread? Like, XML?
Also, should we share Snap! projects on this thread? Like, XML?
- bharvey
-
1000+ posts
Snap! user discussion
Our development is independent from Scratch. I can't imagine Jens ever abandoning Morphic! I'm sorry if this question has been asked before, but when Scratch 3.0, which will also be HTML5, happens, where will Snap! go? Will it stay Morphic.js? Or will it be a pure Scratch 3.0 mod based on the blockly architecture?
Also, should we share Snap! projects on this thread? Like, XML?If you have a project you think will be generally useful, sure. People have done it. But if you're just pining for a social-media site, it's coming, likely this summer if the back end mods are on schedule.
Also, bump please.What, you went two minutes without an answer and you're feeling neglected?

- BookOwl
-
1000+ posts
Snap! user discussion
If he did it would probably decrease its battery usage. Running Snap! in Firefox will run my laptop's battery from 100% to 30% in a couple hours.Our development is independent from Scratch. I can't imagine Jens ever abandoning Morphic! I'm sorry if this question has been asked before, but when Scratch 3.0, which will also be HTML5, happens, where will Snap! go? Will it stay Morphic.js? Or will it be a pure Scratch 3.0 mod based on the blockly architecture?

- bharvey
-
1000+ posts
Snap! user discussion
Noted. If he did it would probably decrease its battery usage. Running Snap! in Firefox will run my laptop's battery from 100% to 30% in a couple hours.
- _nix
-
1000+ posts
Snap! user discussion
For what it's worth, that's somewhat true here; maybe not to as huge of an extent, though. It still sucks battery power noticeably more than simply browsing Scratch forums or any other non-news website, but that's probably to be expected when you're working with a whole block-based programming environment.. (Scratch 2.0 definitely eats battery power more than Snap!, mind you!Noted. If he did it would probably decrease its battery usage. Running Snap! in Firefox will run my laptop's battery from 100% to 30% in a couple hours.

- bharvey
-
1000+ posts
Snap! user discussion
!, mind you!Ah. So, is there some reason to think that Blockly would do better? (Scratch 2.0 definitely eats battery power more than Snap)
- BookOwl
-
1000+ posts
Snap! user discussion
It's using native SVG and HTML instead of canvas or Flash, so hopefully the browser can do a better job at rendering it fast without using too much energy than JS could. This is all just speculation on my part though, so take it with a grain of salt.!, mind you!Ah. So, is there some reason to think that Blockly would do better? (Scratch 2.0 definitely eats battery power more than Snap)
- frodewin
-
500+ posts
Snap! user discussion
Also, should we share Snap! projects on this thread? Like, XML?If you have a project you think will be generally useful, sure. People have done it. But if you're just pining for a social-media site, it's coming, likely this summer if the back end mods are on schedule.
Awesome, looking very much forward to this! I think this will greatly push development of Snap! projects.
- BookOwl
-
1000+ posts
Snap! user discussion
Feature request: Whenever an error happens while executing a block, the block editor for that block should pop up and the primitive that caused the error should be highlighted.
Last edited by BookOwl (June 14, 2017 18:36:57)
- bharvey
-
1000+ posts
Snap! user discussion
Yeah, I know. We need a lot of work on debugging support. Feature request: Whenever an error happens while executing a block, the block editor for that block should pop up and the primitive that caused the error should be highlighted.
Jens has expressed some reservations about popping up editor windows because the sprite that caused the error may not be the sprite you're looking at, so it could be complicated and/or confusing. But we'll find a way to meet that objection if necessary.
- bharvey
-
1000+ posts
Snap! user discussion
Quoth Jens, if it responds in a lively manner to things that happen, then the scheduler is running all the time. It's using native SVG and HTML instead of canvas or Flash, so hopefully the browser can do a better job at rendering it fast without using too much energy than JS could. This is all just speculation on my part though, so take it with a grain of salt.
It's not the drawing that keeps the processor busy, which keeps it hot, which drains the battery, I think.
(Edited to make it more clear where my paraphrase of Jens stops and my own blathering starts.)
(2nd edit: Jens also says that if you don't use the generic hat block, Snap! can sometimes recognize that nothing is running and just redisplay once in a while.)
Last edited by bharvey (June 15, 2017 14:00:17)
- TruDev
-
80 posts
Snap! user discussion
Our development is independent from Scratch. I can't imagine Jens ever abandoning Morphic!
Well, Morphic was abandoned by the ST about 4 years ago, so why did Jens port it to JS? If Morphic were better, the ST would have ported it to Flash. Also, We should do a Snap! (Morphic.js) vs. blockly efficiency test.
If you have a project you think will be generally useful, sure. People have done it. But if you're just pining for a social-media site, it's coming, likely this summer if the back end mods are on schedule.
Great!
What, you went two minutes without an answer and you're feeling neglected?
No, I just wanted to make Snap! more popular by using a bump.

- TruDev
-
80 posts
Snap! user discussion
Also, I had an idea…
Short answer: no and no. Am I able to restrict the scope of an upvar to the custom block?
Can I have a variadic sequence of tokens in the custom block?
The scope of an upvar was one of the arguments Jens won. His view is that an upvar is a kind of script variable, and so its scope extends to the end of the script in which it appears. He compromised by agreeing that a later declaration of a script var/upvar with the same name makes a new, distinct variable, which is important if you export a lambda using the upvar.
As for a variadic grouping, we both want that, but haven't worked out a notation we're happy with. One of those things on the “after OOP is done” list.
(variadic grouping ((a↑) = (b) ...) :: grey stack) :: control hat //sorry about the red, didn't cooperatewhere a and b would be lists of inputs. But a list of upvars…?