Pharo 3.0 on Raspberry Pi - Yes/No
Hi, Here is another step forward in getting Pharo 3.0 to run on a Raspberry Pi. Yes: pi@raspberrypi ~/Pharo-3.0 $ ../PharoRPi/PharoS -vm-display-null -vm-sound-null Pharo.image eval 'SystemVersion current' Pharo3.0 of 18 March 2013 update 30710 pi@raspberrypi ~/Pharo-3.0 $ ../PharoRPi/PharoS -vm-display-null -vm-sound-null Pharo.image eval 'ZTimestamp now' 2014-01-20T18:21:50Z No errors. No: When doing something more complex, like: pi@raspberrypi ~/Pharo-3.0 $ ../PharoRPi/PharoS -vm-display-null -vm-sound-null Pharo.image eval --no-quit 'ZnServer startDefaultOn: 1701' a ZnManagingMultiThreadedServer(running 1701) The HTTP Server does respond normally to one request and then seems to hang. When running with a UI, the image comes up, draws everything but remains unresponsive otherwise. No PharoDebug.log output. Events ? Multi-processing ? How ? Use Jean-Baptiste's VM from here: https://ci.inria.fr/pharo-contribution/view/RaspberryPi/job/RaspberryPi-Comp... Take a stock 3.0 image and apply Pavel's unloadNB.st script (see the thread with subject unload all). So, we're getting closer... If anyone is interested, I could make some kind of all in one download. Sven
On 20 Jan 2014, at 19:32, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi,
Here is another step forward in getting Pharo 3.0 to run on a Raspberry Pi.
Yes:
pi@raspberrypi ~/Pharo-3.0 $ ../PharoRPi/PharoS -vm-display-null -vm-sound-null Pharo.image eval 'SystemVersion current' Pharo3.0 of 18 March 2013 update 30710
pi@raspberrypi ~/Pharo-3.0 $ ../PharoRPi/PharoS -vm-display-null -vm-sound-null Pharo.image eval 'ZTimestamp now' 2014-01-20T18:21:50Z
No errors.
No:
When doing something more complex, like:
pi@raspberrypi ~/Pharo-3.0 $ ../PharoRPi/PharoS -vm-display-null -vm-sound-null Pharo.image eval --no-quit 'ZnServer startDefaultOn: 1701' a ZnManagingMultiThreadedServer(running 1701)
The HTTP Server does respond normally to one request and then seems to hang. Strange ...
When running with a UI, the image comes up, draws everything but remains unresponsive otherwise. I think it is because the UI is to slow and run in software only. The raspberry completely overcharged by the ui. I actually push fast bltbit, then we should have a slow but responsible UI .
No PharoDebug.log output. Because that do not crash just over lag. Due to the UI.
Events ? Multi-processing ?
How ?
Use Jean-Baptiste's VM from here:
https://ci.inria.fr/pharo-contribution/view/RaspberryPi/job/RaspberryPi-Comp...
Take a stock 3.0 image and apply Pavel's unloadNB.st script (see the thread with subject unload all).
So, we're getting closer...
If anyone is interested, I could make some kind of all in one download.
Sven
Best Regards Jean Baptiste Arnaud jbaptiste.arnaud@gmail.com
Hi Jean Baptiste, On 20 Jan 2014, at 21:51, Jean Baptiste Arnaud <jbaptiste.arnaud@gmail.com> wrote:
On 20 Jan 2014, at 19:32, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi,
Here is another step forward in getting Pharo 3.0 to run on a Raspberry Pi.
Yes:
pi@raspberrypi ~/Pharo-3.0 $ ../PharoRPi/PharoS -vm-display-null -vm-sound-null Pharo.image eval 'SystemVersion current' Pharo3.0 of 18 March 2013 update 30710
pi@raspberrypi ~/Pharo-3.0 $ ../PharoRPi/PharoS -vm-display-null -vm-sound-null Pharo.image eval 'ZTimestamp now' 2014-01-20T18:21:50Z
No errors.
No:
When doing something more complex, like:
pi@raspberrypi ~/Pharo-3.0 $ ../PharoRPi/PharoS -vm-display-null -vm-sound-null Pharo.image eval --no-quit 'ZnServer startDefaultOn: 1701' a ZnManagingMultiThreadedServer(running 1701)
The HTTP Server does respond normally to one request and then seems to hang. Strange ...
Yeah, I will retest tomorrow or so, the wireless adaptor on the Pi did act a bit up during testing, maybe that interfered, I don't know.
When running with a UI, the image comes up, draws everything but remains unresponsive otherwise. I think it is because the UI is to slow and run in software only. The raspberry completely overcharged by the ui. I actually push fast bltbit, then we should have a slow but responsible UI .
Hmm, it really didn't do anything, I try again.
No PharoDebug.log output. Because that do not crash just over lag. Due to the UI.
I just meant to say there were no errors ;-) Sending USR1 didn't reveal much either (no weird loops). I still think there is something wrong, does it work for you ? Sven
Events ? Multi-processing ?
How ?
Use Jean-Baptiste's VM from here:
https://ci.inria.fr/pharo-contribution/view/RaspberryPi/job/RaspberryPi-Comp...
Take a stock 3.0 image and apply Pavel's unloadNB.st script (see the thread with subject unload all).
So, we're getting closer...
If anyone is interested, I could make some kind of all in one download.
Sven
Best Regards Jean Baptiste Arnaud jbaptiste.arnaud@gmail.com
On 20 Jan 2014, at 23:56, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi Jean Baptiste,
On 20 Jan 2014, at 21:51, Jean Baptiste Arnaud <jbaptiste.arnaud@gmail.com> wrote:
On 20 Jan 2014, at 19:32, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi,
Here is another step forward in getting Pharo 3.0 to run on a Raspberry Pi.
Yes:
pi@raspberrypi ~/Pharo-3.0 $ ../PharoRPi/PharoS -vm-display-null -vm-sound-null Pharo.image eval 'SystemVersion current' Pharo3.0 of 18 March 2013 update 30710
pi@raspberrypi ~/Pharo-3.0 $ ../PharoRPi/PharoS -vm-display-null -vm-sound-null Pharo.image eval 'ZTimestamp now' 2014-01-20T18:21:50Z
No errors.
No:
When doing something more complex, like:
pi@raspberrypi ~/Pharo-3.0 $ ../PharoRPi/PharoS -vm-display-null -vm-sound-null Pharo.image eval --no-quit 'ZnServer startDefaultOn: 1701' a ZnManagingMultiThreadedServer(running 1701)
The HTTP Server does respond normally to one request and then seems to hang. Strange ...
Yeah, I will retest tomorrow or so, the wireless adaptor on the Pi did act a bit up during testing, maybe that interfered, I don't know. Here that can be a real issue.
When running with a UI, the image comes up, draws everything but remains unresponsive otherwise. I think it is because the UI is to slow and run in software only. The raspberry completely overcharged by the ui. I actually push fast bltbit, then we should have a slow but responsible UI .
Hmm, it really didn't do anything, I try again.
I integrate fast bltbit and after I will begin do really debug that. I fight against the continuous integration platform ^^.
No PharoDebug.log output. Because that do not crash just over lag. Due to the UI.
I just meant to say there were no errors ;-)
Sending USR1 didn't reveal much either (no weird loops).
I still think there is something wrong, does it work for you ?
If something do not work in headless mode, something going wrong. But in non-headless mode, I do not give any pronostic until I integrate Fast blt bit. I work on it ^^.
Sven
Events ? Multi-processing ?
How ?
Use Jean-Baptiste's VM from here:
https://ci.inria.fr/pharo-contribution/view/RaspberryPi/job/RaspberryPi-Comp...
Take a stock 3.0 image and apply Pavel's unloadNB.st script (see the thread with subject unload all).
So, we're getting closer...
If anyone is interested, I could make some kind of all in one download.
Sven
Best Regards Jean Baptiste Arnaud jbaptiste.arnaud@gmail.com
Best Regards Jean Baptiste Arnaud jbaptiste.arnaud@gmail.com
I made some advance and cleaning about the RaspberryPi, compilation. I cross compile from an unix slave, that is really faster and allow me easily to compile the fast bltbit file. Now I integrate the fastbltbit into the StackVM (there a job associated but at term It will be merged): https://ci.inria.fr/pharo-contribution/view/RaspberryPi/job/RaspberryPi-Cros... https://ci.inria.fr/pharo-contribution/view/RaspberryPi/job/RaspberryPi-Cros... We have a small bug on the git tracker now but once it will solve the job will automatically follow the update. The version downloadable should work. I try Sven you are right the UI seems always busy even with fast bltbit (at least on my RaspberryPi ). I will inspect that. If you have already clues about that, feel free to educate me :-). On 20 Jan 2014, at 23:56, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi Jean Baptiste,
On 20 Jan 2014, at 21:51, Jean Baptiste Arnaud <jbaptiste.arnaud@gmail.com> wrote:
On 20 Jan 2014, at 19:32, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi,
Here is another step forward in getting Pharo 3.0 to run on a Raspberry Pi.
Yes:
pi@raspberrypi ~/Pharo-3.0 $ ../PharoRPi/PharoS -vm-display-null -vm-sound-null Pharo.image eval 'SystemVersion current' Pharo3.0 of 18 March 2013 update 30710
pi@raspberrypi ~/Pharo-3.0 $ ../PharoRPi/PharoS -vm-display-null -vm-sound-null Pharo.image eval 'ZTimestamp now' 2014-01-20T18:21:50Z
No errors.
No:
When doing something more complex, like:
pi@raspberrypi ~/Pharo-3.0 $ ../PharoRPi/PharoS -vm-display-null -vm-sound-null Pharo.image eval --no-quit 'ZnServer startDefaultOn: 1701' a ZnManagingMultiThreadedServer(running 1701)
The HTTP Server does respond normally to one request and then seems to hang. Strange ...
Yeah, I will retest tomorrow or so, the wireless adaptor on the Pi did act a bit up during testing, maybe that interfered, I don't know.
When running with a UI, the image comes up, draws everything but remains unresponsive otherwise. I think it is because the UI is to slow and run in software only. The raspberry completely overcharged by the ui. I actually push fast bltbit, then we should have a slow but responsible UI .
Hmm, it really didn't do anything, I try again.
No PharoDebug.log output. Because that do not crash just over lag. Due to the UI.
I just meant to say there were no errors ;-)
Sending USR1 didn't reveal much either (no weird loops).
I still think there is something wrong, does it work for you ?
Sven
Events ? Multi-processing ?
How ?
Use Jean-Baptiste's VM from here:
https://ci.inria.fr/pharo-contribution/view/RaspberryPi/job/RaspberryPi-Comp...
Take a stock 3.0 image and apply Pavel's unloadNB.st script (see the thread with subject unload all).
So, we're getting closer...
If anyone is interested, I could make some kind of all in one download.
Sven
Best Regards Jean Baptiste Arnaud jbaptiste.arnaud@gmail.com
Best Regards Jean Baptiste Arnaud jbaptiste.arnaud@gmail.com
Thanks for this update!!! Keep pushing Stef On 23 Jan 2014, at 17:04, Jean Baptiste Arnaud <jbaptiste.arnaud@gmail.com> wrote:
I made some advance and cleaning about the RaspberryPi, compilation. I cross compile from an unix slave, that is really faster and allow me easily to compile the fast bltbit file.
Now I integrate the fastbltbit into the StackVM (there a job associated but at term It will be merged): https://ci.inria.fr/pharo-contribution/view/RaspberryPi/job/RaspberryPi-Cros... https://ci.inria.fr/pharo-contribution/view/RaspberryPi/job/RaspberryPi-Cros... We have a small bug on the git tracker now but once it will solve the job will automatically follow the update. The version downloadable should work.
I try Sven you are right the UI seems always busy even with fast bltbit (at least on my RaspberryPi ). I will inspect that. If you have already clues about that, feel free to educate me :-).
On 20 Jan 2014, at 23:56, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi Jean Baptiste,
On 20 Jan 2014, at 21:51, Jean Baptiste Arnaud <jbaptiste.arnaud@gmail.com> wrote:
On 20 Jan 2014, at 19:32, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi,
Here is another step forward in getting Pharo 3.0 to run on a Raspberry Pi.
Yes:
pi@raspberrypi ~/Pharo-3.0 $ ../PharoRPi/PharoS -vm-display-null -vm-sound-null Pharo.image eval 'SystemVersion current' Pharo3.0 of 18 March 2013 update 30710
pi@raspberrypi ~/Pharo-3.0 $ ../PharoRPi/PharoS -vm-display-null -vm-sound-null Pharo.image eval 'ZTimestamp now' 2014-01-20T18:21:50Z
No errors.
No:
When doing something more complex, like:
pi@raspberrypi ~/Pharo-3.0 $ ../PharoRPi/PharoS -vm-display-null -vm-sound-null Pharo.image eval --no-quit 'ZnServer startDefaultOn: 1701' a ZnManagingMultiThreadedServer(running 1701)
The HTTP Server does respond normally to one request and then seems to hang. Strange ...
Yeah, I will retest tomorrow or so, the wireless adaptor on the Pi did act a bit up during testing, maybe that interfered, I don't know.
When running with a UI, the image comes up, draws everything but remains unresponsive otherwise. I think it is because the UI is to slow and run in software only. The raspberry completely overcharged by the ui. I actually push fast bltbit, then we should have a slow but responsible UI .
Hmm, it really didn't do anything, I try again.
No PharoDebug.log output. Because that do not crash just over lag. Due to the UI.
I just meant to say there were no errors ;-)
Sending USR1 didn't reveal much either (no weird loops).
I still think there is something wrong, does it work for you ?
Sven
Events ? Multi-processing ?
How ?
Use Jean-Baptiste's VM from here:
https://ci.inria.fr/pharo-contribution/view/RaspberryPi/job/RaspberryPi-Comp...
Take a stock 3.0 image and apply Pavel's unloadNB.st script (see the thread with subject unload all).
So, we're getting closer...
If anyone is interested, I could make some kind of all in one download.
Sven
Best Regards Jean Baptiste Arnaud jbaptiste.arnaud@gmail.com
Best Regards Jean Baptiste Arnaud jbaptiste.arnaud@gmail.com
participants (3)
-
Jean Baptiste Arnaud -
Pharo4Stef -
Sven Van Caekenberghe