SimpleScratch wrote:
" pasted it, selected it all, then right clicked on the text."
It was the selecting it that makes the difference - I hadn't done that. JFI Its clicking on my scroll wheel that seems to bring up things on my RPi in squeak.
Ta again
Yeah, on windows it is right clicking. On other operating systems it seems to be the mouse wheel.
SimpleScratch wrote:
"Every frame, the watcher resizes itself" - Ah - I wonder if there are any other objects (timer.xpos,ypos etc) that do the same?
Simon
I think there is one other thing that might be doing something similar...
Offline
MathWizz wrote:
SimpleScratch wrote:
" pasted it, selected it all, then right clicked on the text."
It was the selecting it that makes the difference - I hadn't done that. JFI Its clicking on my scroll wheel that seems to bring up things on my RPi in squeak.
Ta againYeah, on windows it is right clicking. On other operating systems it seems to be the mouse wheel.
SimpleScratch wrote:
"Every frame, the watcher resizes itself" - Ah - I wonder if there are any other objects (timer.xpos,ypos etc) that do the same?
SimonI think there is one other thing that might be doing something similar...
lists are also pretty heavy...
if the stage resizes itself it'd be hilarious
Offline
roijac wrote:
MathWizz wrote:
SimpleScratch wrote:
" pasted it, selected it all, then right clicked on the text."
It was the selecting it that makes the difference - I hadn't done that. JFI Its clicking on my scroll wheel that seems to bring up things on my RPi in squeak.
Ta againYeah, on windows it is right clicking. On other operating systems it seems to be the mouse wheel.
SimpleScratch wrote:
"Every frame, the watcher resizes itself" - Ah - I wonder if there are any other objects (timer.xpos,ypos etc) that do the same?
SimonI think there is one other thing that might be doing something similar...
lists are also pretty heavy...
if the stage resizes itself it'd be hilarious
Lol. List ARE heavy. Also, when saving, they save the whole morph including all the red readouts. That is why lists save so slowly. I was just dealing with this issue here: http://scratch.mit.edu/projects/MathWizz/2741707 It took 10 minutes to save. xD
Offline
MathWizz wrote:
Lol. List ARE heavy. Also, when saving, they save the whole morph including all the red readouts. That is why lists save so slowly. I was just dealing with this issue here: http://scratch.mit.edu/projects/MathWizz/2741707 It took 10 minutes to save. xD
You should try Kurt!
EDIT: not that I've implemented lists into the de/compiler yet...
Last edited by blob8108 (2012-08-22 15:55:49)
Offline
blob8108 wrote:
MathWizz wrote:
Lol. List ARE heavy. Also, when saving, they save the whole morph including all the red readouts. That is why lists save so slowly. I was just dealing with this issue here: http://scratch.mit.edu/projects/MathWizz/2741707 It took 10 minutes to save. xD
You should try Kurt!
EDIT: not that I've implemented lists into the de/compiler yet...
You mean I should edit the scripts with your exporter thing? You should make separate files for each list then. xD
Last edited by MathWizz (2012-08-22 16:05:23)
Offline
MathWizz wrote:
blob8108 wrote:
MathWizz wrote:
Lol. List ARE heavy. Also, when saving, they save the whole morph including all the red readouts. That is why lists save so slowly. I was just dealing with this issue here: http://scratch.mit.edu/projects/MathWizz/2741707 It took 10 minutes to save. xD
You should try Kurt!
EDIT: not that I've implemented lists into the de/compiler yet...You mean I should edit the scripts with your exporter thing? You should make separate files for each list then. xD
Yeah, that's the plan...
Offline
Oi - @blob8108 - don't distract MathWhizz from finding any other "watcher" thingies that need sorting out
Simon
Offline
SimpleScratch wrote:
Oi - @blob8108 - don't distract MathWhizz from finding any other "watcher" thingies that need sorting out
No worries
Offline
@MathWHizz
Members of the Scratch team have now got across the issue on the RaspberryPi forums - thanks once more for you efforts in getting this moving
Simon
http://www.raspberrypi.org/phpBB3/viewt … 66#p158166
Offline
The image probably won't work unless it's compiled to work with the ARM architecture as far as I know. Also, I'm not surprised that Scratch is slow, because RPi simply isn't a powerful machine
Offline
jji7skyline wrote:
The image probably won't work unless it's compiled to work with the ARM architecture as far as I know. Also, I'm not surprised that Scratch is slow, because RPi simply isn't a powerful machine
The image has nothing to do with the ARM architecture. The Squeak VM has to be compiled for different architectures though.
Offline
Also, I'm not surprised that Scratch is slow, because RPi simply isn't a powerful machine
Of course, Scratch runs slower on the RaspberryPi due to it being approx 1/2 the speed of a low power Windows netbook but that only affects fast moving type games - it doesn't really affect normal learning for youngsters
The "bug" that we've dealing with here has only surfaced due to Scratch being implemented on the RaspberryPi - the fix will actually be useful to projects running on low pwr Win Netbooks that have variables (scores etc) displayed on the screen.
Simon
PS One if things I'm working on with the RaspberryPi is to use Scratch to control its input and output pins so we can do stuff like mounting a RaspberrPi on couple of wheels and turning it into a wifi controlled robot.
Of course, if you've already got some Lego WeDo - I believe you can dive straight in and do this now
Last edited by SimpleScratch (2012-08-25 08:56:33)
Offline
Hello, Simon,
Updating variable watcher is high-cost operation, and Scratch do it every 100-150 ms.
So I made a patch to reduce update frequency to 1 sec.
http://dl.dropbox.com/u/1026229/reduceUpdateFrequency.1.cs
You can file in it from the "File List" tool after Shift-Click-R. To open "File List", click the background and choose "open..." from "World" menu then select "file list".
Cheers,
Kazuhiro Abe
P.S. I modified Scratch to handle GPIO of RasPi for controlling LEDs.
http://www.scratch.mit.edu/ext/youtube/?v=_Nf0Qh7tPCA
And I and my friends made a inexpensive sensor board named NanoBoardAG. It is compatible with PicoBoard and WeDo.
http://swikis.ddo.jp/WorldStethoscope/49
It works fine with RasPi.
Offline
@abee
Excellent work
Do you have a change file for your modification for controlling LEDs please?
regards
Simon
Offline
SimpleScratch wrote:
Do you have a change file for your modification for controlling LEDs please?
Here it is: RaspberryPiGPIO.cs
It enables to control a LED via GPIO of Raspberry Pi by motor blocks for WeDo.
It uses /sys/class/gpio/gpio4 pin for output.
You need to execute Scratch as a superuser.
No PWM support at the moment.
BTW, if continue this topic, it would be better to move to the following forum.
Connecting to the Physical World
Offline
This may Help, If you have a Model of Raspberry Pi that supports USB (Universal Serial Bus) Then try to run the Scratch Program you have got off of the USB Memory Stick (If you have got one) That is all I can suggest... Only, That Might not work because you will also need to tell it to save the RAM and CPU Data onto the Memory stick, Possible but tricky...
Offline
Both the mods here make a huge difference to the performance of scratch on the raspberry pi. To the extent it is now useable without lots of sighing from young children!
I am also trying to use Scratch with the PiFace board. This communicated with Scratch using Mesh. As soon as i run the custom python scratch_handler for piface the CPU usage shoots up, although performance isn't too bad. Does the mesh in scratch have the same issue with checking for changes very regularly and hence hog the CPU?
I have put some delays in the python scratch_handler with no effect making me think the CPU usage is by scratch rather than the python script.
Anyone clever able to shed any light?
Offline
dmurday wrote:
Both the mods here make a huge difference to the performance of scratch on the raspberry pi. To the extent it is now useable without lots of sighing from young children!
I am also trying to use Scratch with the PiFace board. This communicated with Scratch using Mesh. As soon as i run the custom python scratch_handler for piface the CPU usage shoots up, although performance isn't too bad. Does the mesh in scratch have the same issue with checking for changes very regularly and hence hog the CPU?
I have put some delays in the python scratch_handler with no effect making me think the CPU usage is by scratch rather than the python script.
Anyone clever able to shed any light?
I wouldn't be surprised if it's Scratch, considering it seems to have notoriously high CPU usage. Does disabling Mesh make a difference?
Offline
@dmurday - My scratch_gpio_handler.py code was originally taken from the pi-face handler back at end of July 2012.
The code then was quite a CPU hogger (one of the main culprits was jsut sitting waiting for ctrl-c to be pressed )
But remember - this was just proof-of-concept at the time and the pi-face has only been released as a development board and not one intended to public (never mind young scratchers) to actually dailiy use.
I don't know if the code you have has been updated but if you've a bit of time - you could maybe take my current code structure and try and graft the two together
regards
Simon (simplesi/cymplecy)
PS AFAIK Remote Sensor Connection is basically just Mesh and that doesn't actually seem to add in too much overhead
Last edited by SimpleScratch (2012-09-26 13:31:06)
Offline
New to Scratch and wondering does the doing the script thing give the same result as using the provided scratch.image or do I have to use the .image as well as the script?
Thanks,
Albert.
Offline
New to Scratch
This is the advanced section
But seriously, things have changed a lot in the last 6 months and Scratch has now been modified at source so nothing needed at the moment to adjust it
Simon
Offline