- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40370 Home: https://github.com/pharo-project/pharo-core

Nov. 14, 2014

[pharo-project/pharo-core] 75cde1: 40370

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 75cde181a36c777a7c2996ee8228cc2183e687cd https://github.com/pharo-project/pharo-core/commit/75cde181a36c777a7c2996ee… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-11-14 (Fri, 14 Nov 2014) Changed paths: M ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/versions/version202_.st M ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/versions/version202_.st M ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/versions/version302_.st A ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version124_.st R Glamour-Morphic-Renderer.package/GLMMorphicAccumulatorRenderer.class/instance/as yet unclassified/removePage_.st A Glamour-Morphic-Renderer.package/GLMMorphicAccumulatorRenderer.class/instance/private/removePage_.st M Glamour-Morphic-Renderer.package/GLMMorphicPharoCodeRenderer.class/instance/callbacks/evaluateAndPopPrintSelection.st R Glamour-Morphic-Renderer.package/GLMMorphicPharoMethodRenderer.class/instance/as yet unclassified/methodBindingsStrategy.st R Glamour-Morphic-Renderer.package/GLMMorphicPharoMethodRenderer.class/instance/as yet unclassified/modelFor_.st R Glamour-Morphic-Renderer.package/GLMMorphicPharoMethodRenderer.class/instance/as yet unclassified/morph.st A Glamour-Morphic-Renderer.package/GLMMorphicPharoMethodRenderer.class/instance/private/methodBindingsStrategy.st A Glamour-Morphic-Renderer.package/GLMMorphicPharoMethodRenderer.class/instance/rendering/modelFor_.st A Glamour-Morphic-Renderer.package/GLMMorphicPharoMethodRenderer.class/instance/rendering/morph.st R Glamour-Morphic-Renderer.package/GLMMorphicPharoPlaygroundRenderer.class/instance/as yet unclassified/actOnVariableBindingsUpdated_.st R Glamour-Morphic-Renderer.package/GLMMorphicPharoPlaygroundRenderer.class/instance/as yet unclassified/modelFor_.st R Glamour-Morphic-Renderer.package/GLMMorphicPharoPlaygroundRenderer.class/instance/as yet unclassified/morph.st R Glamour-Morphic-Renderer.package/GLMMorphicPharoPlaygroundRenderer.class/instance/as yet unclassified/registerEventsForPresentation_.st R Glamour-Morphic-Renderer.package/GLMMorphicPharoPlaygroundRenderer.class/instance/as yet unclassified/workspaceBindingsStrategy.st A Glamour-Morphic-Renderer.package/GLMMorphicPharoPlaygroundRenderer.class/instance/callbacks/actOnVariableBindingsUpdated_.st A Glamour-Morphic-Renderer.package/GLMMorphicPharoPlaygroundRenderer.class/instance/private/registerEventsForPresentation_.st A Glamour-Morphic-Renderer.package/GLMMorphicPharoPlaygroundRenderer.class/instance/private/workspaceBindingsStrategy.st A Glamour-Morphic-Renderer.package/GLMMorphicPharoPlaygroundRenderer.class/instance/rendering/modelFor_.st A Glamour-Morphic-Renderer.package/GLMMorphicPharoPlaygroundRenderer.class/instance/rendering/morph.st R Glamour-Morphic-Renderer.package/GLMMorphicRubricHighlightedTextRenderer.class/instance/as yet unclassified/morph.st A Glamour-Morphic-Renderer.package/GLMMorphicRubricHighlightedTextRenderer.class/instance/rendering/morph.st M Glamour-Morphic-Renderer.package/GLMMorphicSmalltalkCodeRenderer.class/instance/callbacks/evaluateAndPrintSelection.st R Glamour-Morphic-Renderer.package/GLMMorphicSpecRenderer.class/instance/as yet unclassified/actOnPresentationUpdated_.st R Glamour-Morphic-Renderer.package/GLMMorphicSpecRenderer.class/instance/as yet unclassified/render_.st A Glamour-Morphic-Renderer.package/GLMMorphicSpecRenderer.class/instance/rendering/actOnPresentationUpdated_.st A Glamour-Morphic-Renderer.package/GLMMorphicSpecRenderer.class/instance/rendering/render_.st R Glamour-Morphic-Renderer.package/GLMMorphicTableRenderer.class/instance/as yet unclassified/newTreeMorph.st R Glamour-Morphic-Renderer.package/GLMMorphicTableRenderer.class/instance/as yet unclassified/render_.st A Glamour-Morphic-Renderer.package/GLMMorphicTableRenderer.class/instance/private/newTreeMorph.st A Glamour-Morphic-Renderer.package/GLMMorphicTableRenderer.class/instance/rendering/render_.st M Glamour-Morphic-Widgets.package/GLMMorphTreeColumn.class/instance/column drawing/rowMorphFor_.st R Glamour-Morphic-Widgets.package/GLMPaginatedResizableMorphTreeMorph.class/instance/as yet unclassified/toggleExpandedState_event_.st R Glamour-Morphic-Widgets.package/GLMPaginatedResizableMorphTreeMorph.class/instance/as yet unclassified/updateColumnMorphs.st A Glamour-Morphic-Widgets.package/GLMPaginatedResizableMorphTreeMorph.class/instance/events-processing/toggleExpandedState_event_.st A Glamour-Morphic-Widgets.package/GLMPaginatedResizableMorphTreeMorph.class/instance/updating/updateColumnMorphs.st M Rubric.package/RubAbstractTextArea.class/instance/event handling/keyStroke_.st A Rubric.package/RubSHTextStylerST80.class/class/accessing/styleTable.st A Rubric.package/RubSHTextStylerST80.class/class/accessing/styleTable_.st A Rubric.package/RubSHTextStylerST80.class/class/accessing/textAttributesByPixelHeight.st A Rubric.package/RubSHTextStylerST80.class/class/initialization/initialize.st A Rubric.package/RubSHTextStylerST80.class/class/style table/initialTextAttributesForPixelHeight_.st R Rubric.package/RubSHTextStylerST80.class/instance/as yet unclassified/addLinkAttributesFor_in_to_.st A Rubric.package/RubSHTextStylerST80.class/instance/private/addLinkAttributesFor_in_to_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script370.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40370.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40370 14473 GTools version 2.0.2 - bug fixes https://pharo.fogbugz.com/f/cases/14473 http://files.pharo.org/image/40/40370.zip

Nov. 14, 2014

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

by Andreas Wacknitz

Am 14.11.14 um 15:13 schrieb Sven Van Caekenberghe: > Hi Andreas, > > I tried a precompiled VM, where are those instructions ? I was referring the readme you had in your original post. Eliot already sent you the answer. Being able to raise the thread priority above normal needs to be allowed. In Solaris you need to do it on a per-user basis (with usermod -K defaultpriv=basic,proc_priocntl <username>). Linux has another way of doing this which is explained in the readme for the cog vm. Alternatively you could try to run the vm as root. Of course this is not recommended for production. Regards Andreas > 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 Markus Fritsche

On 11/14/2014 03:17 PM, Esteban A. Maringolo wrote: > What are the benefits of running a Pharo server in the cloud on ARM > architecture? My blog is actually running on a colocated raspberry pi - it is unlikely to be linked by slashdot soon and is enough for the limited readership. So far I'm not running pharo on it, but if I ever come around to implement "the next big thing" in it, that would probably the first spot to put the test image on... Kind regards, Markus

Nov. 14, 2014

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