I flag this just in case that it has been missed by the foundation and any Scratch fans in all the noise
I do not know the official process to get improvements in the distribution of Raspbian but I'd encourage the foundation and users to look at this:
and scroll down to the post at:
he has produced a new Scratch image that deals with some of the bugs that grind Scratch to a halt fairly quickly.
A major bug means displaying variables on the stage is hugely CPU intensive. One variable adds about 50% to the CPU even when not doing anything.
IMHO Scratch has about a life span of a day for bright kid on the PI in the standard image form before their games get too complicated etc. MathWizz's image prolongs Scratch on a Pi for a long long time.
Yes X acceleration would be great etc but using this is a really easy win for Pi Scratch users and the foundation.
The lack of volume of posts on this board represents the frustration of the community with Scratch on the PI.
All the best
Also Everybody Turbo your PI!
Yes, I reported it at http://scratch.mit.edu/forums/viewtopic ... 5#p1416155 - (my workaround is a post number 8 on that thread, and in post 9 I reported that the same problem occurs on other Linux builds but not Windows) - I don't know if there's a better way to report things to the Scratch people - things I've reported on the MIT forum have all fallen silent, although someone did assure me that people eventually pick things up on there.jamesh wrote:Have you posted that fix to the Scratch people for investigation?
Agreed. I did offer to help (I'm a C/C++ programmer by trade), but of course nothing is as simple as that: It's straight into Smalltalk, virtual machines, plugins, etc, etc. But the offer stands if there's anything a C++ programmer can do to help...jamesh wrote:It difficult as at least 2 out of three of the problems you describe are actually Scratch problems rather than Raspi problems, so should really be fixed by the Scratch people. Not sure about the sound issue though.
I belive (not sure how to verify) that I am using 2012-10-28-wheezy-raspbian from which I tried (Linux noobie here) to ensure it was the latest of everything by performing various apt-get commands all of which seem to succeed ok. My RPi is a 256Mb model. And the Scratch projects where very,very simple but still caused it to crash etc.simplesi wrote:@readiescards
Are you using a relative recent Raspbian image or one of the problematical older pre-installed squeeze images.
1. I don't think this is necessary - speed wise - I think a turbo mode RPi with the (already done but not officially blessed) slight modified image that cures the CPU hoggin variable display issue is actually fine for the job.a native code implementation is required to get performance up.
I agree (on your last point - I'm unavailable for the next week!). But as I understand it, we now have your fix (sorry, not sure, but I associate it with you anyway) for the variables issue, my strange "workaround" that makes the sticky keys problem go away (documented elsewhere), and the reported fix for the sound problems (also documented elsewhere) - with those three things in place, Scratch is entirely usable as it is, so some way of packaging it up like that would really help other people.simplesi wrote:I think what we(me and the other Scratch dabblers) need to do is to forget about waiting for "Them" (Scratch MIT/Foundation) to put together all the little mods we've come up with and try and make a simple installable script that setups up a Raspbian RPI with the best current working Scratch that we can do with our limited engine-room knowledge.
But TIME is the enemy for all of us.
The post is here http://www.h-online.com/open/features/E ... 72863.htmlEU: The nice thing is that almost all of the good CS teaching software already runs on Linux, so the bulk of the work is in making sure it works well on the Pi, rather than developing things from a standing start. MIT Scratch is actually a great example of this – it's built on top of the Squeak Smalltalk VM, and because this has generally only been run in anger on modern desktop hardware there hasn't previously been a case for heavy optimisation of its graphics routines, so it's a little sluggish on the Pi right now. We've commissioned a couple of pieces of work, the first of which involves porting it to use Pixman as its rendering backend, and the second involves optimising Pixman itself for the Pi's ARMv6 architecture (which will obviously pay dividends elsewhere in the system too).