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-Cross-Compilation/
https://ci.inria.fr/pharo-contribution/view/RaspberryPi/job/RaspberryPi-Cross-Compilation-FastBltBit/
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-Compilation/40/artifact/results.tar.gz

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