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

Re: [Pharo-dev] [squeak-dev] Spur Identity Hash [was: The Trunk: System-cmm.689.mcz]

by Levente Uzonyi

On Fri, 14 Nov 2014, Chris Muller wrote: >>> Anyway, something to be aware of -- anywhere we have true, false or >>> nil used in a hash calculation, now has a different hash in Spur vs. >>> Cog. Maybe we should think about separating those objects' logical >>> "value" hash from their identityHash in trunk..? That could be useful >>> when we move to 64-bit someday.. >> >> Remember that Spur has a common header format for both 32-bit and 64-bit >> versions, so in both there is a 22-bit identityHash and hence the >> identityHashes of all objects in a 64-bit Spur image bootstrapped from a >> 32-bit Spur image will be _unchanged_. Convenient. So no need to worry. >> And it should be the case that a freshly bootstrapped 64-bit Spur image does >> not need to be rehashed to function properly. > > Suprising that their identityHash needs to change for Spur but not to > go to 64-bit.. > > Wait, I thought one of the benefits of 64-bit was to finally increase > that small identityHash? 22 is already a lot more than the current 12. Current hashed collections should give excellent performance up to 4 million elements with a 22-bit identity hash. Insertion and lookup performance should be good up to 60 million elements, and removal performance should be good up to 20 million. And you'll still be able to use hashed collections optimized for large sizes[1][2] if you want to store more objects. Levente [1] http://leves.web.elte.hu/LargeIdentityDictionary/ [2] http://leves.web.elte.hu/LargeIdentityDictionary/LargeIdentityDictionary2.p… P.S.: With a primitive I suggested long ago, the blue line on the picture (#at:) could be as flat as the red (#includesKey:).

Nov. 14, 2014

Re: [Pharo-dev] [squeak-dev] Spur Identity Hash [was: The Trunk: System-cmm.689.mcz]

by Chris Muller

>> Anyway, something to be aware of -- anywhere we have true, false or >> nil used in a hash calculation, now has a different hash in Spur vs. >> Cog. Maybe we should think about separating those objects' logical >> "value" hash from their identityHash in trunk..? That could be useful >> when we move to 64-bit someday.. > > Remember that Spur has a common header format for both 32-bit and 64-bit > versions, so in both there is a 22-bit identityHash and hence the > identityHashes of all objects in a 64-bit Spur image bootstrapped from a > 32-bit Spur image will be _unchanged_. Convenient. So no need to worry. > And it should be the case that a freshly bootstrapped 64-bit Spur image does > not need to be rehashed to function properly. Suprising that their identityHash needs to change for Spur but not to go to 64-bit.. Wait, I thought one of the benefits of 64-bit was to finally increase that small identityHash?

Nov. 14, 2014

Re: [Pharo-dev] ValueHolder analysis

by Igor Stasenko

On 14 November 2014 16:25, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > > On 14 Nov 2014, at 12:01 , 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 > > > > 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 > > I'd argue the window and additionalKeyBindings' whenChangedDo: > implementations are unnecessary bloat as well. > Why on earth would you limit yourself to a an API where you have to use > seperate methods to register for every single announcement type? > > To me, > myObject additionalKeyBindings when: ValueChanged do: aBlock > is just as easy, if not easier to read compared to > myObject whenShortCutsChanged: [] > > Not to mention, it easily lets you do unsubscription when you expect not > to outlive the source (through the 3rd block parameter, whose *main purpose > for even being there* is enabling easy unsubscription), rather than > discarding it during useless indirection and leaving the task harder to do > later on? > > +1 in general, i would prefer to see: myModel propertyXYZ whenChangedDo: [...] or myModel properyXYZ whenChangedSend: #foo to: bar . - you don't have to know that it uses ValueChanged announcement. In this regard, such information is excessive, since it is standard ValueHolder. - once you learned how to access/use single property, you can use any other, because it will have same API, and so you don't have to remember numerous 'whenPropertyXYZChanged:...' hoping it is there and spelled correctly. 1. because, how i see it, the idea is , that your model exposes certain _public_ property, which application can read or change (using value/value: accessors ) or wants to be notified when it changed by others. And this can be done by simply exposing the accessor to its ValueHolder to outside. 2. the extra API is just a source of confusion. And the above example clearly illustrates why: while internally, property is named 'additionalKeyBindings', but the method for subscribing to its changes named 'whenShortcutsChanged:' . One might expect that to access such property, there should be 'shortcuts' accessor, right? No! That would be too easy. It is additionalKeyBindings! P.S. The Demeter law is not a dogma. Cheers, > Henry > -- Best regards, Igor Stasenko.

Nov. 14, 2014

Re: [Pharo-dev] Pharo Launcher for Windows

by Thierry Goubier

2014-11-14 16:05 GMT+01:00 Damien Cassou <damien.cassou(a)gmail.com>: > please install from this link > > > https://ci.inria.fr/pharo-contribution/job/PharoLauncher-Win-Package/lastSu… > This is the one I am talking about :( Doesn't work. But I may be doing something wrong with Windows :( Just, Pharo-Win works on the same machine. Thierry > > On Fri, Nov 14, 2014 at 9:29 AM, Thierry Goubier > <thierry.goubier(a)gmail.com> wrote: > > 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 give any error > message > > at all. > > > > (Note: Pharo3 windows distribution did work). > > > > Thanks, > > > > Thierry > > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill > >

Nov. 14, 2014

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

by Sebastian Sastre

sounds like following this strategy will have a deep influence in programming more functionally and use immutability a lot more. > On Nov 14, 2014, at 12:31 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> 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] [squeak-dev] [DEV] Systemd socket activation patch for the VM

by GastÃ³n Dall' Oglio

Hello all. Has anyone tried this in recent stable Pharo? If anyone can tell me which combinations of image / vm versions would work fine... I have in a Centos 7 vps an 1.4 image and latest stable vm running fine, but when I try to load systemd.cs I get an MNU receiver of "methodsFor:stamp:" is nil because there is no TcpListener class in this image... Regards.. 2014-07-08 11:08 GMT-03:00 Max Leske <maxleske(a)gmail.com>: > Hi folks > > As promised a long time ago my colleague Nik Lutz has finalized the patch > for the VM that enables socket activation with Systemd. I will quickly go > over what the patch is supposed to achieve, how we plan to use socket > activation and what (minimal) changes are necessary. > > > Systemd Socket Activation: > Systemd opens a (network-) socket and waits for connections. When the > first client connects the assotiated service (VM) is started. Systemd > indicates via environment variable (LISTEN_FDS) that it opened a network > socket. > > Detailed documentation on socket activation with Systemd can be found > here: http://0pointer.de/blog/projects/socket-activation.html > > > Our scenario for socket activation: > At Cmsbox we have hundereds of images running on a server, all of which > listen on a dedicated network port for incoming connections. The server is > powerful enough to run all these processes concurrently, especially since > not every image receives requests all the time. > With socket activation we could further lower the server load and free up > resources for images with a high request rate. Images that donât receive > any requests for a specified amount of time can be suspended automatically > and reactivated when a request comes in. > > > > The VM Patch: > The attached patch tries hard to be minimal. It defines a new socket type > (ProvidedTCPSocketType) which you will also find in the image > (Socket>>newSystemd). ProvidedTCPSocketType is special in that it can refer > to an existing TCPSocket and does not necessarily entail the creation of a > new socket. > > > The changes in the image: > - Socket>>newSystemd tries to open a new Systemd socket. > - TCPListener>>haveSystemdAssignedPort tests if the LISTEN_FDS environment > variable has been set by Systemd for the current process. > - TCPListener>>primEnvironmentAtSymbol is a utility method that we need to > check for the environment variable (IMPORTANT: copied from OSProcess; uses > the OSProcess plugin) > - TCPListener>>pvtNewListener: has been modified to include the check for > the Systemd port. If the socket has been assigned by Systemd, use a Systemd > socket, a TCP socket otherwise > > Quick Howto: > - Adapt path to vm and image in pharo@.service > - Take a Seaside image and FileIn systemd.cs (tested with > http://seaside.st/distributions/Seaside-2.8.4.zip) > - Save as 9999.image > - Copy pharo@.service and pharo@.socket to /etc/systemd/system > - As root run: > systemctl daemon-reload > systemctl start pharo(a)9999.socket > - Open http://localhost:9999/seaside/config > > [- systemctl stop pharo(a)9999.socket] > > -> Upon connection pharo(a)9999.socket starts: pharo(a)9999.service (which > would start .../9999.image) > > You can see this in action in the following screencast: > http://youtu.be/MVPLZNKg5j8 > > > We hope that this patch (or some version of it) will find its way into the > VM. If you have any questions please feel free to ask. > > > Cheers, > Max (on behalf of Nik and the rest of Netstyle.ch) > > > > > > > > > > >

Nov. 14, 2014

Re: [Pharo-dev] ValueHolder analysis

by Henrik Johansen

> On 14 Nov 2014, at 12:01 , 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 > > 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 I'd argue the window and additionalKeyBindings' whenChangedDo: implementations are unnecessary bloat as well. Why on earth would you limit yourself to a an API where you have to use seperate methods to register for every single announcement type? To me, myObject additionalKeyBindings when: ValueChanged do: aBlock is just as easy, if not easier to read compared to myObject whenShortCutsChanged: [] Not to mention, it easily lets you do unsubscription when you expect not to outlive the source (through the 3rd block parameter, whose *main purpose for even being there* is enabling easy unsubscription), rather than discarding it during useless indirection and leaving the task harder to do later on? Cheers, Henry

Nov. 14, 2014

Re: [Pharo-dev] Pharo Launcher for Windows

by Damien Cassou

please install from this link https://ci.inria.fr/pharo-contribution/job/PharoLauncher-Win-Package/lastSu… On Fri, Nov 14, 2014 at 9:29 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > 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 give any error message > at all. > > (Note: Pharo3 windows distribution did work). > > Thanks, > > Thierry -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Nov. 14, 2014

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

by Eliot Miranda

Sven, do you not see the error message? > pthread_setschedparam failed: Operation not permitted > Read e.g. http://www.mirandabanda.org/files/Cog/VM/VM.r3126/README.3126 If you read the read me it will explain what you need to do to get it to work. Eliot (phone) On Nov 14, 2014, at 3:00 AM, 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

Thank you Sven. I didn't know about this alternative. I guess it's worth using it if your horizontal scale is relevant, or if there is a particular set of use cases (high I/O, low cpu?). Regards! El Fri Nov 14 2014 at 11:31:27 AM, Sven Van Caekenberghe <sven(a)stfx.eu> escribiÃ³: > > > 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-to-take-on-aws-digitalocean/ > > http://armservers.com > >

Nov. 14, 2014