Hi Guys,

I have something super cool to show you that I've been working on with my team at Robotix: PHIRO is a LEGO® compatible robot that you can use Snap4Arduino to wirelessly control via bluetooth! Check this out–> https://www.youtube.com/watch?v=pYiVJjoEEPg

PHIRO can be programmed with Scratch2.0, Snap4Arduino, Pocket Code apps, Swish Cards and Sequential Keys!
More videos–>https://www.youtube.com/channel/UCF8eCeNdv-umX2b0ZUMoSKw

Want to see what else PHIRO is about? Find out more at www.robotixedu.com/phiro.aspx and Facebook.com/robotixedu

Deepti

That's pretty cool! I really like the idea of leveraging existing programming software (like Snap!) for new hardware instead of introducing a brand new programming environment for every new toy. :-)

bharvey wrote:

deeptirobotix wrote:

We are trying to bring awareness to our upcoming Kickstarter campaign.

Umm, I hate to be the bad guy in this conversation, but I'm guessing appeals for money aren't allowed in the Scratch forum.

Thank you. I am working on removing it. Hope it resolves.

Hello,

I am trying to add sounds to actions on Snap. Just like the “Click sounds” that plays the file, I would like to do the same when switching tabs or clicking or the like but have no clue.

How could I do this?

Thankful,
Nicolas Raga

NicolasRaga wrote:

I am trying to add sounds to actions on Snap.

You can of course put a PLAY SOUND block in the script for any programmable action, such as clicking on a sprite.

But if there isn't a hat block for the action, I don't think you can do it.

I've just started with Snap!, and I figured the thing to do was to try to implement prototyping OOP, as described in the Reference Manual (pp.43 and beyond), so I could use it in things I want to do. The first step was slavishly copying the counter example and getting it to work…

…Failed! Ah! I found the bug. The assoc function as written requires that for i = 1 to 0 skip the enclosed code. That may be how it used to work, but now you get iteration from 1 down to 0 and a failed function. OK, I fixed that…

… Still doesn't work! (what a let down!) Now the set method works but telling a counter to next raises an error complaining that “'self' does not exist in this context”. After breaking my head for far too long, I gave up and ran to this forum…

…where I learned that OOP used to be supported in BYOB and will be given what looks like a nice implementation in Snap! 4.1 (devoutly to be wished),… but where does that leave 4.0? Does the code in the reference manual not work for some reason? If not, how does it break?

Thanks,

Jeff

jelhai wrote:

…Failed!

Thanks for reporting this – I'll look into it this evening.

What isn't in 4.0 is sprite inheritance, but the lambda-based OOP implementation should work.

Hi all,

I'm using Snap! in my Intro CS class, and my students are suddenly seeing Snap! crash in Chrome a lot. It appears to be an issue with using too much memory, which I can understand, but it's happening more often than I'm used to, and I haven't been able to nail down a specific cause in the students' code.

So, I ask the following questions:

• Has anything in Snap! changed recently that would make it more succeptible to memory issues?
  
• Are there any known causes of regular memory issues that I could advise my students to work around or avoid?
  
• Any other advice for how to minimize memory issues (beyond the obvious like keeping code clean, not using too many costumes, etc.)?
  

Thanks!

brettwo wrote:

…my students are suddenly seeing Snap! crash in Chrome a lot.

I'm new here, so I don't know what normal is. I've experience freezing 2 or 3 times per day. By that I mean that it is no longer possible to execute blocks by clicking them, and the pull down menus on functions (e.g. set) don't work. Also, the list on the left side mysteriously lose many basic functions (not those in libraries – again set is an example). Refreshing the page did no good. I was surprised to find that despite these dire straits it was still possible to save the workspace. Once I left Chrome, started over, and brought the work space back in, the problem was cured. I don't believe I was doing anything that would have taxed memory, but I imagine Brian has access to logs that can address that point.

jelhai wrote:

brettwo wrote:

…my students are suddenly seeing Snap! crash in Chrome a lot.

I'm new here, so I don't know what normal is. I've experience freezing 2 or 3 times per day. By that I mean that it is no longer possible to execute blocks by clicking them, and the pull down menus on functions (e.g. set) don't work. Also, the list on the left side mysteriously lose many basic functions (not those in libraries – again set is an example). Refreshing the page did no good. I was surprised to find that despite these dire straits it was still possible to save the workspace. Once I left Chrome, started over, and brought the work space back in, the problem was cured. I don't believe I was doing anything that would have taxed memory, but I imagine Brian has access to logs that can address that point.

I'm not sure Brian has logs, since everything besides logging in/out occurs on the client..

brettwo wrote:

my students are suddenly seeing Snap! crash in Chrome a lot.

I forwarded these to Jens. I'm not aware of any recent change in Snap! that should be relevant to this, but Chrome has been changing lately too.

Is it better in Firefox? If so that's the simplest workaround.

Snap! certainly has not changed recently (and won't change really soon), but - as Brian has pointed out - Chrome has. Which OS and versions are we talking about here? What exactly do you mean when you say Snap is “freezing”? Basically the symptoms about Snap mysteriously losing certain functions but not others are technically implausible, i.e. either Snap works or it doesn't. I've been heavily using Snap in Chrome on both OSX and Windows 10 (thanks to Brian!) and while I *did* notice some annoying things in Chrome recently, it's mostly about fonts suddenly being more blurred than they used to, but no “freezes” or hang-ups in either OS.

Some quick things to check:

* Chrome is known to be a memory hog, even without Snap! Do exit and re-launch Chrome every couple of days
* Bandwidth can be a downer, Snap may not react while it opens library menus and imports libraries (as those are fetched synchronously)
* It's best to run Snap online from the UC Berkeley site. If you download Snap and run it offline, certain things will not work (but won't crash, either)
* Chrome *does* have an issue with exporting a lot of data into a new browser tab, i.e. projects, media, screenshots etc. We're currently working on a fix
* Clear you browser caches if you haven't used Snap for a long time (it may be holding on to outdated script versions)

Good luck!

Hey, I'm not sure, but if you see “the list on the left side mysteriously lose many basic functions” it might just be that you've switched to the stage instead of to a sprite?

Thanks, all. To clarify, my issue is that the tab is crashing completely (bringing up Chrome's ironically named “Aw, snap!” error page). I've had no unusual performance issues except the crashes (other than typical slow downs when a lot of scripts are running at the same time). I've checked both the Windows performance logs and the Chrome logs, and it definitely looks like a memory issue. Memory usage spikes right before the crash occurs. It's also possible that the plugin our school uses to monitor and restrict web uses could be partially to blame. I'm still investiating that.

This is all on Windows 7. We haven't tried Firefox, so we'll do that today and see if it's any better. Thanks for the suggestions– I'd be happy to have any other thoughts!

Jens wrote:

Hey, I'm not sure, but if you see “the list on the left side mysteriously lose many basic functions” it might just be that you've switched to the stage instead of to a sprite?

It's a good thing you mentioned that. In fact I hadn't realized that the function list is context dependent – obviously a good thing to know! However, my claim was that set was lost from the variables palette, and that shouldn't happen under any circumstances. On the other hand, I didn't take a picture of the offending screen, so we'll never know if I really lost set or maybe I lost the slider or maybe I lost my mind.

So never mind, unless it happens again and I can capture it.

Jens wrote:

Hey, I'm not sure, but if you see “the list on the left side mysteriously lose many basic functions” it might just be that you've switched to the stage instead of to a sprite?

OK, the resolution to the mystery turns out to be simple. I have come to rely on find blocks. I notice now for the first time that just below that in the right-click menu is hide primitives. No doubt I clicked that by accident, and it did what it's supposed to do.

So no problem (except with my aim).

Thanks.

jelhai wrote:

I have come to rely on find blocks

You can get that by typing control-F, you know. Since you're going to be typing anyway once the text box appears.

Hi.
I want to make a package to control addressable led strip from Snap! on Raspberry PI. What I need for that is a simple web-server on python and an example of a snap block which communicate with it (and also a place, where to insert this block). I can do it by my self but may be where is a developer who can easily show it to me. Thanks in advance.

Mayhem from cloning sprites (preface)

I'm having severe problems trying to manipulate clones of sprites. Before I go into that, let me briefly summarize what is my overall goal. I want to make simple games whose workings are transparent and open to change by elementary school teachers, who will generally have no programming experience and a limited desire to learn Snap!. Accordingly, the programs are built hierarchically. Each game will present almost the same top level, seen by teachers when they enter the game, something like the example below (for a game that invites players to pick multiples of a given number (taken from a progressively difficult set) on a hexagonal grid of random numbers).

[I can't post the promised Image because my status is merely “new scratcher”, but it's available here]

(by the way, I think truncated comments should be followed by “…”). Clicking set game parameters will take teachers to the innards of a function that allows them to tweak the settings of the game. Clicking play game (see below) will present the basic logic of the game. Further clicks get the teacher/user deeper and deeper into the nuts and bolts.

[Again, the promised image isn't here, but you can find it here (maybe it's too big for a forum anyway).]

Guiding principles (in theory):

1. Small blocks, easy to digest at the top level, more challenging at lower levels
   
2. Avoid variable clutter: reserve global variables just for those that may be interesting for users to monitor
   
3. Avoid screen clutter: only the green flag script plus whatever else can't be avoided
   
4. Flexible, powerful high-level tools (e.g. creating game boards)
   
5. Syntactic sugar whenever it aids comprehensibility by the target audience (e.g. …is a multiple of… replacing …mod… =)
   
6. Asynchronous execution shunned except when the logic of the game demands it
   

These are not easy guiding principles to adhere to (and I'd be delighted by your opinions as to the value of adhering to them!). I hope that the ease of making (logically) minor changes in games that are useful to pedagogic goals may entice teachers to explore the games more deeply as they feel ready.

I'll leave my immediate problem for a separate message (see Guiding Principle #1) (except that this message is already too long!).

Thanks.

jelhai wrote:

Mayhem from cloning sprites (preface)

I'm having severe problems trying to manipulate clones of sprites. Before I go into that, let me briefly summarize what is my overall goal. I want to make simple games whose workings are transparent and open to change by elementary school teachers, who will generally have no programming experience and a limited desire to learn Snap!. Accordingly, the programs are built hierarchically. Each game will present almost the same top level, seen by teachers when they enter the game, something like the example below (for a game that invites players to pick multiples of a given number (taken from a progressively difficult set) on a hexagonal grid of random numbers).



(by the way, I think truncated comments should be followed by “…”). Clicking set game parameters will take teachers to the innards of a function that allows them to tweak the settings of the game. Clicking play game (see below) will present the basic logic of the game. Further clicks get the teacher/user deeper and deeper into the nuts and bolts.



Guiding principles (in theory):

1. Small blocks, easy to digest at the top level, more challenging at lower levels
   
2. Avoid variable clutter: reserve global variables just for those that may be interesting for users to monitor
   
3. Avoid screen clutter: only the green flag script plus whatever else can't be avoided
   
4. Flexible, powerful high-level tools (e.g. creating game boards)
   
5. Syntactic sugar whenever it aids comprehensibility by the target audience (e.g. …is a multiple of… replacing …mod… =)
   
6. Asynchronous execution shunned except when the logic of the game demands it
   

These are not easy guiding principles to adhere to (and I'd be delighted by your opinions as to the value of adhering to them!). I hope that the ease of making (logically) minor changes in games that are useful to pedagogic goals may entice teachers to explore the games more deeply as they feel ready.

I'll leave my immediate problem for a separate message (see Guiding Principle #1) (except that this message is already too long!).

Thanks.

Fixed. New scratchers can't post links outside of Scratch either.