November 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pharo on Online Labs ARM cloud server ?

by Sven Van Caekenberghe

> On 14 Nov 2014, at 15:17, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > What are the benefits of running a Pharo server in the cloud on ARM architecture? Basically there are two server schools: the classic old school is only interested in raw performance at any cost, a newer, alternative school thinks that cheaper, massive parallel and more efficient (performance per watt) CPUs can have advantages. This of course assumes the workload scales horizontally, like in web applications and services. Here is the article where I learned about the Online Labs initiative: http://techcrunch.com/2014/11/13/online-labs-designed-its-own-arm-servers-t… http://armservers.com > Thank you! > El Fri Nov 14 2014 at 11:14:02 AM, Sven Van Caekenberghe <sven(a)stfx.eu> escribiÃ³: > Hi Andreas, > > I tried a precompiled VM, where are those instructions ? > Are they relevant for ARM ? > BTW, the problem on the Raspberry Pi was the glibc version (2.5 required). > > Sven > > > On 14 Nov 2014, at 14:52, Andreas Wacknitz <A.Wacknitz(a)gmx.de> wrote: > > > > Am 14.11.14 um 12:00 schrieb Sven Van Caekenberghe: > >> pthread_setschedparam failed: Operation not permitted > > Did you follow the instructions from the readme file to allow for increased thread priorities? > > The heartbeat thread needs to run at a higher priority than the working thread. > > In Solaris I have to add priocntl privileges to users for this, where Linux seem to have another way > > described in the readme... > > > > Regards, > > Andreas > >

Nov. 14, 2014

Re: [Pharo-dev] Pharo on Online Labs ARM cloud server ?

by Norbert Hartl

> Am 14.11.2014 um 15:06 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > I tried the ARM VMs published at http://www.mirandabanda.org but they failed, even on a standard RaspberryPi running Rasbian (wrong libc) - these seem to be compiled statically for a too specific range of machines/OSes. > > But then I tried the JB ones and they worked fine ! > > I used this link: https://ci.inria.fr/pharo-contribution/job/RaspberryPi-Cross-Compilation-JB… > > After adding PharoV30.sources I got Pharo 3 running on the command line including a normally functioning Zn HTTP server. On the Online Labs machines I had to install libasound2 as well. > > The Online Labs machines seem pretty fast: > > ubuntu@c1-10-1-14-179:~$ ./jb-vm/PharoS -vm-display-null Pharo.image eval '1 tinyBenchmarks' > '39975015 bytecodes/sec; 2174908 sends/sec' > > vs a Raspberry Pi: > > pi@raspberrypi ~/pharo $ ./jb-vm/PharoS -vm-display-null Pharo.image eval '1 tinyBenchmarks' > '13377926 bytecodes/sec; 719200 sends/sec' > > That looks like a factor 3 to 4 faster. > > But it is way slower than the regular VM on my machine: > > prometheus:pharo4 sven$ ./pharo Pharo.image eval '1 tinyBenchmarks' > '985563041 bytecodes/sec; 160902758 sends/sec' > > Probably the plain stack VM vs the Cog JIT is a factor too. > There is big difference between StackVM and Cog. Try using RFB on the pi to access the image. That's pretty unusable and that would be ok (I guess) with a Cog vm. > Thanks JB ! > > Is this VM production ready (so to speak) ? > I worked a few days with it and never encountered a problem. I've compiled a VM including a dbus plugin and so I can say the image plus ffi worked quite well. Can't wait to proceed with the project :) Norbert > Sven > > PS: We still need easier access to this + better instructions. >> On 14 Nov 2014, at 12:00, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> >>> On 14 Nov 2014, at 01:02, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>> >>> Hi Sven, >>> >>> On Thu, Nov 13, 2014 at 2:34 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> Hi, >>> >>> I just saw this: http://labs.online.net which offers real ARM cloud servers (15 minutes for free to try out) [they're French]. This is Ubuntu 14.10 on ARMv7. >>> >>> Naturally I wanted to try Pharo on such a machine. >>> >>> The base question is, where do I get the latest and best VM to try this ? >>> >>> Doug McPherson is building Stack VMs for ARMv6 and ARMv7 for both Cog and Spur and uploading them to my site. These VMs should run Pharo. See e.g. http://www.mirandabanda.org/files/Cog/VM/VM.r3126/ >> >> I tried that and it does not seem to work: >> >> ubuntu@c1-10-1-16-102:~$ ls >> Pharo.changes Pharo.image PharoV30.sources stklinuxhtARM stklinuxhtARMv7-14.45.3126.tgz >> >> ubuntu@c1-10-1-16-102:~$ ./stklinuxhtARM/bin/squeak -vm-display-null Pharo.image printVersion >> pthread_setschedparam failed: Operation not permitted >> Read e.g. http://www.mirandabanda.org/files/Cog/VM/VM.r3126/README.3126 >> >> Maybe their system is special, I don't know, it feels pretty standard, running the latest Ubuntu. >> >> I noticed the 'ht' in the VM name, is there no 'normal' one ? >> >> I will try on a Raspberry Pi as well. >> >>> Maybe a complete & easy to use source tree that can be compiled locally ? >>> >>> That's the case for http://www.squeakvm.org/svn/squeak/branches/Cog. See http://www.squeakvm.org/svn/squeak/branches/Cog/build.linux32ARM >>> >>> And would it make sense to add some ARM option to get.pharo.org ? >>> >>> Thx, >>> >>> Sven >>> >>> >>> >>> -- >>> best, >>> Eliot > >

Nov. 14, 2014

Re: [Pharo-dev] Pharo on Online Labs ARM cloud server ?

by Esteban A. Maringolo

What are the benefits of running a Pharo server in the cloud on ARM architecture? Thank you! El Fri Nov 14 2014 at 11:14:02 AM, Sven Van Caekenberghe <sven(a)stfx.eu> escribiÃ³: > Hi Andreas, > > I tried a precompiled VM, where are those instructions ? > Are they relevant for ARM ? > BTW, the problem on the Raspberry Pi was the glibc version (2.5 required). > > Sven > > > On 14 Nov 2014, at 14:52, Andreas Wacknitz <A.Wacknitz(a)gmx.de> wrote: > > > > Am 14.11.14 um 12:00 schrieb Sven Van Caekenberghe: > >> pthread_setschedparam failed: Operation not permitted > > Did you follow the instructions from the readme file to allow for > increased thread priorities? > > The heartbeat thread needs to run at a higher priority than the working > thread. > > In Solaris I have to add priocntl privileges to users for this, where > Linux seem to have another way > > described in the readme... > > > > Regards, > > Andreas > > >

Nov. 14, 2014

Re: [Pharo-dev] Pharo on Online Labs ARM cloud server ?

by Sven Van Caekenberghe

Hi Andreas, I tried a precompiled VM, where are those instructions ? Are they relevant for ARM ? BTW, the problem on the Raspberry Pi was the glibc version (2.5 required). Sven > On 14 Nov 2014, at 14:52, Andreas Wacknitz <A.Wacknitz(a)gmx.de> wrote: > > Am 14.11.14 um 12:00 schrieb Sven Van Caekenberghe: >> pthread_setschedparam failed: Operation not permitted > Did you follow the instructions from the readme file to allow for increased thread priorities? > The heartbeat thread needs to run at a higher priority than the working thread. > In Solaris I have to add priocntl privileges to users for this, where Linux seem to have another way > described in the readme... > > Regards, > Andreas

Nov. 14, 2014

Re: [Pharo-dev] Pharo on Online Labs ARM cloud server ?

by Sven Van Caekenberghe

I tried the ARM VMs published at http://www.mirandabanda.org but they failed, even on a standard RaspberryPi running Rasbian (wrong libc) - these seem to be compiled statically for a too specific range of machines/OSes. But then I tried the JB ones and they worked fine ! I used this link: https://ci.inria.fr/pharo-contribution/job/RaspberryPi-Cross-Compilation-JB… After adding PharoV30.sources I got Pharo 3 running on the command line including a normally functioning Zn HTTP server. On the Online Labs machines I had to install libasound2 as well. The Online Labs machines seem pretty fast: ubuntu@c1-10-1-14-179:~$ ./jb-vm/PharoS -vm-display-null Pharo.image eval '1 tinyBenchmarks' '39975015 bytecodes/sec; 2174908 sends/sec' vs a Raspberry Pi: pi@raspberrypi ~/pharo $ ./jb-vm/PharoS -vm-display-null Pharo.image eval '1 tinyBenchmarks' '13377926 bytecodes/sec; 719200 sends/sec' That looks like a factor 3 to 4 faster. But it is way slower than the regular VM on my machine: prometheus:pharo4 sven$ ./pharo Pharo.image eval '1 tinyBenchmarks' '985563041 bytecodes/sec; 160902758 sends/sec' Probably the plain stack VM vs the Cog JIT is a factor too. Thanks JB ! Is this VM production ready (so to speak) ? Sven PS: We still need easier access to this + better instructions. > On 14 Nov 2014, at 12:00, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 14 Nov 2014, at 01:02, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> Hi Sven, >> >> On Thu, Nov 13, 2014 at 2:34 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> Hi, >> >> I just saw this: http://labs.online.net which offers real ARM cloud servers (15 minutes for free to try out) [they're French]. This is Ubuntu 14.10 on ARMv7. >> >> Naturally I wanted to try Pharo on such a machine. >> >> The base question is, where do I get the latest and best VM to try this ? >> >> Doug McPherson is building Stack VMs for ARMv6 and ARMv7 for both Cog and Spur and uploading them to my site. These VMs should run Pharo. See e.g. http://www.mirandabanda.org/files/Cog/VM/VM.r3126/ > > I tried that and it does not seem to work: > > ubuntu@c1-10-1-16-102:~$ ls > Pharo.changes Pharo.image PharoV30.sources stklinuxhtARM stklinuxhtARMv7-14.45.3126.tgz > > ubuntu@c1-10-1-16-102:~$ ./stklinuxhtARM/bin/squeak -vm-display-null Pharo.image printVersion > pthread_setschedparam failed: Operation not permitted > Read e.g. http://www.mirandabanda.org/files/Cog/VM/VM.r3126/README.3126 > > Maybe their system is special, I don't know, it feels pretty standard, running the latest Ubuntu. > > I noticed the 'ht' in the VM name, is there no 'normal' one ? > > I will try on a Raspberry Pi as well. > >> Maybe a complete & easy to use source tree that can be compiled locally ? >> >> That's the case for http://www.squeakvm.org/svn/squeak/branches/Cog. See http://www.squeakvm.org/svn/squeak/branches/Cog/build.linux32ARM >> >> And would it make sense to add some ARM option to get.pharo.org ? >> >> Thx, >> >> Sven >> >> >> >> -- >> best, >> Eliot

Nov. 14, 2014

Re: [Pharo-dev] Pharo on Online Labs ARM cloud server ?

by Andreas Wacknitz

Am 14.11.14 um 12:00 schrieb Sven Van Caekenberghe: > pthread_setschedparam failed: Operation not permitted Did you follow the instructions from the readme file to allow for increased thread priorities? The heartbeat thread needs to run at a higher priority than the working thread. In Solaris I have to add priocntl privileges to users for this, where Linux seem to have another way described in the readme... Regards, Andreas

Nov. 14, 2014

Re: [Pharo-dev] Pharo Launcher for Windows

by kilon alios

ConfigurationBrowser is how I use PharoLauncher on windows 7 myself, it works On Fri, Nov 14, 2014 at 1:50 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2014-11-14 11:47 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > >> Thierry Goubier wrote: >> >>> >>> >>> 2014-11-14 9:57 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de <mailto: >>> nicolaihess(a)web.de>>: >>> >>> 2014-11-14 9:29 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com >>> <mailto:thierry.goubier@gmail.com>>: >>> >>> Hi all, >>> >>> does anybody knows if the Pharo Launcher is working in Windows? >>> I tried on different Windows 7 machines, but it would work nor >>> >> >> >> I presume you meant... >> I tried on different Windows 7 machines, but it would NOT work nor >> :) >> > > Yes :) > > >> >> give any error message at all. >>> >>> (Note: Pharo3 windows distribution did work). >>> >>> Thanks, >>> >>> Thierry >>> >>> >>> >>> I use pharolauncher on windows. At home I used the pharolauncher >>> windows installer once. I don't remember if this >>> still works. Currently I use the a normal pharo vm and the >>> pharolauncher image. >>> >>> >>> Yes, I would suspect this would work (using a normal Pharo vm and the >>> PharoLauncher image) but I would have liked to use the PharoLauncher as the >>> gateway to install a specific Pharo image from Jenkins, and it won't work >>> that way. >>> >>> I basically have an issue for installing Pharo for the lecture I do >>> (configuration management in both places I teach is rather poor) and I was >>> trying windows for a change :( >>> >>> Thierry >>> >>> >> I also have no problem using PharoLauncher on Windows - but I installed >> it a long time ago. I'll try to find a clean OS to try it on. >> >> btw, Have you tried loading PharoLauncher from ConfigurationBrowser? >> (not that I've tried it) >> > > No. I'll try (or run the pharo launcher with another pharo VM). > > Thierry > > >> >> cheers -ben >> >> >

Nov. 14, 2014

Re: [Pharo-dev] Pharo Launcher for Windows

by Thierry Goubier

2014-11-14 11:47 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > Thierry Goubier wrote: > >> >> >> 2014-11-14 9:57 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de <mailto: >> nicolaihess(a)web.de>>: >> >> 2014-11-14 9:29 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com >> <mailto:thierry.goubier@gmail.com>>: >> >> Hi all, >> >> does anybody knows if the Pharo Launcher is working in Windows? >> I tried on different Windows 7 machines, but it would work nor >> > > > I presume you meant... > I tried on different Windows 7 machines, but it would NOT work nor > :) > Yes :) > > give any error message at all. >> >> (Note: Pharo3 windows distribution did work). >> >> Thanks, >> >> Thierry >> >> >> >> I use pharolauncher on windows. At home I used the pharolauncher >> windows installer once. I don't remember if this >> still works. Currently I use the a normal pharo vm and the >> pharolauncher image. >> >> >> Yes, I would suspect this would work (using a normal Pharo vm and the >> PharoLauncher image) but I would have liked to use the PharoLauncher as the >> gateway to install a specific Pharo image from Jenkins, and it won't work >> that way. >> >> I basically have an issue for installing Pharo for the lecture I do >> (configuration management in both places I teach is rather poor) and I was >> trying windows for a change :( >> >> Thierry >> >> > I also have no problem using PharoLauncher on Windows - but I installed it > a long time ago. I'll try to find a clean OS to try it on. > > btw, Have you tried loading PharoLauncher from ConfigurationBrowser? > (not that I've tried it) > No. I'll try (or run the pharo launcher with another pharo VM). Thierry > > cheers -ben > >

Nov. 14, 2014

Re: [Pharo-dev] ValueHolder analysis

by Guillermo Polito

On Fri, Nov 14, 2014 at 12:01 PM, stepharo <stepharo(a)free.fr> wrote: > I checked a bit deeper > > > Nautilus is not implemented in Spec. But senders and implementors are and > they also leak memory. Around 400 Announcers after each > opening and closing. > > Now > > whenChangedDo: aBlock > > | block | > block := [:announcement :ann | aBlock cull: announcement newValue > cull: announcement oldValue cull: announcement cull: ann ]. > announcer when: ValueChanged do: block > > Stef, maybe for a quick test and see if the situation changes because of it, you can change that to whenChangedDo: aBlock | block subscription | block := [:announcement :ann | aBlock cull: announcement newValue cull: announcement oldValue cull: announcement cull: ann. *subscription subscriber removeSubscription: subscription* ]. *subscription := *announcer when: ValueChanged do: block. modulo error handling :) > can also be part of the cause of some of our problems. > > There are 146 senders and many of them could just be replaced by > whenChanged:send:to: and whenChanged:send:to:with: > > > Finally we were discussing with igor about the general API of spec model: > We are thinking that the following patterns > are bloating the interface for an not obvious gain. > > whenWindowChanged: aBlock > > window whenChangedDo: aBlock > > > whenShortcutsChanged: aBlock > <api: #event> > "Set a block to value when the shortcuts block has changed" > > additionalKeyBindings whenChangedDo: aBlock > > > > > > > > > > > > > >

Nov. 14, 2014

Re: [Pharo-dev] ValueHolder analysis

by stepharo

I checked a bit deeper Nautilus is not implemented in Spec. But senders and implementors are and they also leak memory. Around 400 Announcers after each opening and closing. Now whenChangedDo: aBlock | block | block := [:announcement :ann | aBlock cull: announcement newValue cull: announcement oldValue cull: announcement cull: ann ]. announcer when: ValueChanged do: block can also be part of the cause of some of our problems. There are 146 senders and many of them could just be replaced by whenChanged:send:to: and whenChanged:send:to:with: Finally we were discussing with igor about the general API of spec model: We are thinking that the following patterns are bloating the interface for an not obvious gain. whenWindowChanged: aBlock window whenChangedDo: aBlock whenShortcutsChanged: aBlock <api: #event> "Set a block to value when the shortcuts block has changed" additionalKeyBindings whenChangedDo: aBlock

Nov. 14, 2014