Re: [Pharo-dev] Pharo 3.0 on Raspberry Pi - Yes/No
Thanks for this update!!! Keep pushing Stef On 23 Jan 2014, at 17:04, Jean Baptiste Arnaud 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 wrote: > >> Hi Jean Baptiste, >> >> On 20 Jan 2014, at 21:51, Jean Baptiste Arnaud >> wrote: >> >>> >>> On 20 Jan 2014, at 19:32, Sven Van Caekenberghe 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.arn...@gmail.com >>> >>> >>> >>> >>> >>> >>> >> >> > > Best Regards > Jean Baptiste Arnaud > jbaptiste.arn...@gmail.com > > > > > > >
Re: [Pharo-dev] Pharo 3.0 on Raspberry Pi - Yes/No
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 wrote: > Hi Jean Baptiste, > > On 20 Jan 2014, at 21:51, Jean Baptiste Arnaud > wrote: > >> >> On 20 Jan 2014, at 19:32, Sven Van Caekenberghe 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.arn...@gmail.com >> >> >> >> >> >> >> > > Best Regards Jean Baptiste Arnaud jbaptiste.arn...@gmail.com
Re: [Pharo-dev] Pharo 3.0 on Raspberry Pi - Yes/No
On 20 Jan 2014, at 23:56, Sven Van Caekenberghe wrote: > Hi Jean Baptiste, > > On 20 Jan 2014, at 21:51, Jean Baptiste Arnaud > wrote: > >> >> On 20 Jan 2014, at 19:32, Sven Van Caekenberghe 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-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.arn...@gmail.com >> >> >> >> >> >> >> > > Best Regards Jean Baptiste Arnaud jbaptiste.arn...@gmail.com
Re: [Pharo-dev] Pharo 3.0 on Raspberry Pi - Yes/No
Hi Jean Baptiste, On 20 Jan 2014, at 21:51, Jean Baptiste Arnaud wrote: > > On 20 Jan 2014, at 19:32, Sven Van Caekenberghe 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.arn...@gmail.com > > > > > > >
Re: [Pharo-dev] Pharo 3.0 on Raspberry Pi - Yes/No
On 20 Jan 2014, at 19:32, Sven Van Caekenberghe 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-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.arn...@gmail.com
