- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [for testing] speeding up code loading

by Esteban A. Maringolo

2014-10-20 12:50 GMT-03:00 Marcus Denker <marcus.denker(a)inria.fr>: > Hi, > > [Object compileSilently: 'foo ^ 1' classified: 'testing'] bench > > -- 267 per second > > Load from inbox: > SLICE-Issue-14242-Installing-a-method-is-slow-MarcusDenker.3 > > run bench again ==> 2320 per second. > > This will work as long the .changes is small enough so that it uses a > normal > (not extended) source pointer. What is "small enough"? How can I compress the changes file? Regards!

Oct. 20, 2014

Re: [Pharo-dev] Spec Understandability

by Eliot Miranda

Hi Ralph, On Mon, Oct 20, 2014 at 9:08 AM, Ralph Boland <rpboland(a)gmail.com> wrote: > > Besides error intractability, there is also a cost to understanding the > > system via exploration - a glorious benefit of Morphic. In the past, one > > only had to bring up halos on and inspect a button to see how to > duplicate > > its action. Now, to see what happens when one presses Versionner's > "Commit > > the project" button, you have to drill down in the inspector from > > aButtonXyzMorph -> model -> actionHolder -> value, a tedious and opaque > > process. > > > Of course, I'm not in any way against Spec or its goals, just sharing my > > unfolding experience using it. > > I'm running Squeak 4.0 but I assume my question still applies. If not, > other > Pharo users might want to know. > I would upgrade to 4.5 asap. That's ancient. Are you still using the interpreter VM? If so, you can change to the JIT. It's a lot faster. And to the Spur VM which is faster still. > I am not in the habit of using halos, not really sure what they are for. > But your description > implies they are quite useful. > What does "bring up halos on and inspect a button to see how to duplicate > > its action" mean? Could you please describe in step by step detail. > Right click on any window. Then grab the Swirl halo (dark blue) and tug it. Quite useful I'd say ;-) [image: Inline image 1] The rotation halo might be only for fun, but many of the others are really useful, allowing you to move, delete, inspect, take an image, copy, etc, etc, etc. -- best, Eliot

Oct. 20, 2014

Re: [Pharo-dev] pharo works fine on yosemite

by Esteban Lorenzano

> On 20 Oct 2014, at 18:42, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 20 Oct 2014, at 17:47, kilon alios <kilon.alios(a)gmail.com> wrote: >> >> Just upgrade to Yosemite, Pharo seems to work fine so far. As usually it does not full screen properly with the new green window icon, but it does fullscreen properly when fullscreen is chosen at pharo settings. > > Both Yosemite and the full screen option using the new (green|expand) button work perfectly for me. > > Maybe it depends on the VM ? I tried with the latest VM: no, it depends on retina/non retina, and some other wizardry that I still do not fully understand :P Esteban > > Image > ----- > /Users/sven/Develop/git/IntegrationScripts/current/Pharo.image > Pharo4.0 > Latest update: #40313 > Unnamed > > Virtual Machine > --------------- > /Users/sven/tmp/pharo-vm/Pharo.app/Contents/MacOS/Pharo > NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 > NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 > https://github.com/pharo-project/pharo-vm.git Commit: ed4a4f59208968a21d82fd2406f75c2c4de558b2 Date: 2014-05-15 18:23:04 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14826 > > Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< > VMMaker versionString https://github.com/pharo-project/pharo-vm.git Commit: ed4a4f59208968a21d82fd2406f75c2c4de558b2 Date: 2014-05-15 18:23:04 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14826 > NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 > NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 > > But an older one worked fine as well. > > Sven

Oct. 20, 2014

Re: [Pharo-dev] pharo works fine on yosemite

by Sven Van Caekenberghe

> On 20 Oct 2014, at 17:47, kilon alios <kilon.alios(a)gmail.com> wrote: > > Just upgrade to Yosemite, Pharo seems to work fine so far. As usually it does not full screen properly with the new green window icon, but it does fullscreen properly when fullscreen is chosen at pharo settings. Both Yosemite and the full screen option using the new (green|expand) button work perfectly for me. Maybe it depends on the VM ? I tried with the latest VM: Image ----- /Users/sven/Develop/git/IntegrationScripts/current/Pharo.image Pharo4.0 Latest update: #40313 Unnamed Virtual Machine --------------- /Users/sven/tmp/pharo-vm/Pharo.app/Contents/MacOS/Pharo NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 https://github.com/pharo-project/pharo-vm.git Commit: ed4a4f59208968a21d82fd2406f75c2c4de558b2 Date: 2014-05-15 18:23:04 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14826 Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< VMMaker versionString https://github.com/pharo-project/pharo-vm.git Commit: ed4a4f59208968a21d82fd2406f75c2c4de558b2 Date: 2014-05-15 18:23:04 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14826 NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 But an older one worked fine as well. Sven

Oct. 20, 2014

Re: [Pharo-dev] Spec Understandability

by Ralph Boland

> Besides error intractability, there is also a cost to understanding the > system via exploration - a glorious benefit of Morphic. In the past, one > only had to bring up halos on and inspect a button to see how to duplicate > its action. Now, to see what happens when one presses Versionner's "Commit > the project" button, you have to drill down in the inspector from > aButtonXyzMorph -> model -> actionHolder -> value, a tedious and opaque > process. > Of course, I'm not in any way against Spec or its goals, just sharing my > unfolding experience using it. I'm running Squeak 4.0 but I assume my question still applies. If not, other Pharo users might want to know. I am not in the habit of using halos, not really sure what they are for. But your description implies they are quite useful. What does "bring up halos on and inspect a button to see how to duplicate > its action" mean? Could you please describe in step by step detail. Ralph Boland

Oct. 20, 2014

[for testing] speeding up code loading

by Marcus Denker

Hi, Â [Object compileSilently: 'foo ^ 1' classified: 'testing'] bench Â Â -- 267 per second Â Â Load from inbox: Â SLICE-Issue-14242-Installing-a-method-is-slow-MarcusDenker.3 Â Â run bench again ==> 2320 per second. Â Â This will work as long the .changes is small enough so that it uses a normal (not extended) source pointer. Â Â Â Marcus

Oct. 20, 2014

Re: [Pharo-dev] pharo works fine on yosemite

by kilon alios

Just upgrade to Yosemite, Pharo seems to work fine so far. As usually it does not full screen properly with the new green window icon, but it does fullscreen properly when fullscreen is chosen at pharo settings. Unfortunately installing Yosemite has not been a smooth ride. My late 2013 iMac got stuck to "About a minute remaining" for over 40 minutes and from what I have read here http://osxdaily.com/2014/10/17/os-x-yosemite-installation-stuck/ Some got stuck to this stage for up to 72 hours (WTF). Apparently from firing up the console (CMD+L) even though the installation appears to finish on time it takes extra time to move back your files which may explain the long time. I have even seen smoke get out of my iMac ( o_O ) during reboot, or maybe it was dust because the fans got crazy-speed (o_O) , first time it happened to me. So I cant recommend upgrading. Anyway everything seems to work fine now, Yosimite is slow to boot (around 50 seconds but I dont have a flash drive) but overall it looks like it works fine. On Sun, Oct 19, 2014 at 5:46 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > thats great news, i am in the process of downloading Yosemite and I have > my fingers crossed for many apps as this is the first time I install a new > macos version so quickly after its release. Most likely I will be fine > though. > > On Sun, Oct 19, 2014 at 2:16 PM, Max Leske <maxleske(a)gmail.com> wrote: > >> Iâve been developing with Yosemite for the last two weeks. There seems to >> be one issue with older VMs that can lock up from time to time. Other than >> that I havenât experienced any difference to Mavericks (except for the >> nicer full screen view :) ) >> >> Cheers, >> Max >> >> On 19.10.2014, at 12:57, phil(a)highoctane.be wrote: >> >> Cool. I am still on Lion and was considering moving to the new shiny one. >> >> Thx for the report. >> >> Phil >> Le 19 oct. 2014 12:49, "Tudor Girba" <tudor(a)tudorgirba.com> a Ã©crit : >> >>> Hi, >>> >>> I just installed OS X Yosemite (10.10), and it looks like Pharo works >>> just fine. >>> >>> Cheers, >>> Doru >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >> >> >

Oct. 20, 2014

Re: [Pharo-dev] [Pharo-users] new Pharo Success story

by Pablo R. Digonzelli

Great! Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 Email: pdigonzelli(a)softsargentina.com pdigonzelli(a)gmail.com Cel: 5493815982714 De: "Tudor Girba" <tudor(a)tudorgirba.com> Para: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> CC: "Pharo Development List" <pharo-dev(a)lists.pharo.org> Enviados: Lunes, 20 de Octubre 2014 6:59:33 Asunto: Re: [Pharo-dev] [Pharo-users] new Pharo Success story +100 Doru On Mon, Oct 20, 2014 at 11:41 AM, Sven Van Caekenberghe < sven(a)stfx.eu > wrote: > On 19 Oct 2014, at 09:44, stepharo < stepharo(a)free.fr > wrote: > > Hi > > we just published a new success story: Pharo at CSOB > > http://pharo.org/success > > And yes we are interested in your sucess stories > > Stef > > PS: big thanks to Tomas and CSOB for letting us making this public. Beautiful! Great work. It is a lot of work to do a project inside such a big bank, let alone make a success of it. Congratulation to Tomas and the rest of his team. Sven -- www.tudorgirba.com "Every thing has its own flow"

Oct. 20, 2014

Re: [Pharo-dev] Use Komitter in MC Browser?

by stepharo

> I hacked the MC Browser to open up a Changes window along-side my commit > dialog. Then I realized we already have this (and a bit more) with Komitter. > What if we just plug Komitter into the "Save" operation? We should pay attention that Komitter is sometimes a bit fragile and having string back doors is nice. May be we should have Save (K) and Save ?

Oct. 20, 2014

Re: [Pharo-dev] Image Segment semantics and weakness

by stepharo

While I as a big fan of imageSegment and proposed to mariano to work on imageSegment2 (it was the original idea for his phd) he convinced us that imagesegment were not worth their complexity. So why do you want to have imageSegment? Stef On 20/10/14 03:01, Eliot Miranda wrote: > Hi All, > > I want to check my understanding of reference semantics for image > segments as I'm close to completing the Spur implementation. > Specifically the question is whether objects reachable only through > weak pointers should be included in an image segment or not. > > Remember that an image segment is created from the transitive closure > of an Array of root objects, the /segment roots/. i.e. we can think of > an image segment as a set of objects created by tracing the object > graph from the segment roots. > > The segment always includes the segment roots. Except for the roots, > objects are excluded from the segment that are also reachable form the > roots of the system (the /system roots/, effectively the root > environment, Smalltalk, and the stack of the current process). > > Consider a weak array in the transitive closure that is not reachable > from the system roots, and hence should be included in the segment. > Objects referenced from that weak array may be in one of three categories > > - reachable from the system roots (and hence not to be included in the > segment) > - /not/ reachable form the system roots, but reachable from the > segment roots via strong pointers (and hence to be included in the > segment) > - /not/ reachable form the system roots, /not/ reachable from the > segment roots via strong pointers > > Should this last category be included or excluded from the segment? I > think that it makes no difference, and excluding them is only an > optimization. The argument is as follows. Imagine that immediately > after loading the image segment there is a garbage collection. That > garbage collection will collect all the objects in the last category > as they are only reachable from the weak arrays in the segment. Hence > we are free to follow weak references as if they are strong when we > create the image segment, leaving it to subsequent events to reclaim > those objects. > > An analogous argument accounts for objects reachable from ephemerons. > Is my reasoning sound? > -- > best, > Eliot

Oct. 20, 2014