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

[pharo-project/pharo-core] 9f93fb: 40337

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 9f93fb79ae236951a375d96790976deb6346e070 https://github.com/pharo-project/pharo-core/commit/9f93fb79ae236951a375d967… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-10-29 (Wed, 29 Oct 2014) Changed paths: M SUnit-Core.package/TestCase.class/class/initialize - event/initialize.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script337.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40337.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40337 14349 announcement subscription in TestCase class>>#initialize should be weak https://pharo.fogbugz.com/f/cases/14349 http://files.pharo.org/image/40/40337.zip

Oct. 29, 2014

Re: [Pharo-dev] Roassal2 in Pharo GTInspector

by Tudor Girba

Hi, You should load the default group of the ConfigurationOfGTInspector. This will load Roassal2, the binding with Glamour and the inspector extensions that use Roassal2. Cheers, Doru On Wed, Oct 29, 2014 at 11:31 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi, > > What should I do to be able to use roassal2 representation on Pharo? > Because Iâve tried to load Roassal2 group form ConfigurationOfGlamour, but > then it loads newer version of glamour which breaks in some way the > inspector. > > Uko > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 29, 2014

Re: [Pharo-dev] AioPlugin is back in linux VMs

by Damien Cassou

On Wed, Oct 29, 2014 at 4:09 AM, David T. Lewis <lewis(a)mail.msen.com> wrote: > For testing and examples, see class AioEventHandlerExample in package OSProcess, it works! Thanks Esteban and David. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Oct. 29, 2014

Re: [Pharo-dev] Roassal2 in Pharo GTInspector

by stepharo

This why slowly we should meta data in the image so that we can manage better loaded configurations and the rest. Christophe should have a beta soon. On 29/10/14 05:31, Yuriy Tymchuk wrote: > Hi, > > What should I do to be able to use roassal2 representation on Pharo? Because Iâve tried to load Roassal2 group form ConfigurationOfGlamour, but then it loads newer version of glamour which breaks in some way the inspector. > > Uko >

Oct. 29, 2014

**Important** PharoDays Preparation

by stepharo

Hi guys We will organize at Lille the 29 and 30 of January PharoDays. Now to help us building a budget I would like to know if you already know that you plan to attend the conference. Could you fill up the doodle http://doodle.com/icxtazwfq76caxf8 Stef

Oct. 29, 2014

Roassal2 in Pharo GTInspector

by Yuriy Tymchuk

Hi, What should I do to be able to use roassal2 representation on Pharo? Because Iâve tried to load Roassal2 group form ConfigurationOfGlamour, but then it loads newer version of glamour which breaks in some way the inspector. Uko

Oct. 29, 2014

Re: [Pharo-dev] Super fast delay

by Norbert Hartl

I have a report that it doesn't work on a linux desktop either. So at least there is one case where it does not work in a non-virtualized environment. Maybe interesting: root@2d-misc:/opt/mock-server# time pharo-vm-nox ./Pharo.image eval "(Delay forSeconds: 5) wait. (Delay forSeconds: 10) wait" a Delay(10000 msecs) real 0m10.185s user 0m0.268s sys 0m0.040s Norbert > Am 28.10.2014 um 22:56 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > I am pretty sure that it is related to virtual hardware, it seems to work reliably on my mac: > > prometheus:pharo4 sven$ ./pharo Pharo.image printVersion > [version] 4.0 #40322 > > prometheus:pharo4 sven$ time ./pharo Pharo.image eval '5 seconds asDelay wait' > a Delay(5000 msecs) > > real 0m5.504s > user 0m0.491s > sys 0m0.440s > > prometheus:pharo4 sven$ time ./pharo Pharo.image eval '5 seconds asDelay wait' > a Delay(5000 msecs) > > real 0m5.539s > user 0m0.408s > sys 0m0.166s > > prometheus:pharo4 sven$ time ./pharo Pharo.image eval '5 seconds asDelay wait' > a Delay(5000 msecs) > > real 0m6.022s > user 0m0.647s > sys 0m0.442s > > prometheus:pharo4 sven$ time ./pharo Pharo.image eval '5 seconds asDelay wait' > a Delay(5000 msecs) > > real 0m5.539s > user 0m0.518s > sys 0m0.440s > > But how it can work so completely bogus on virtual hardware beats me. > >> On 28 Oct 2014, at 20:21, phil(a)highoctane.be wrote: >> >> VMWare Workstation 10 on Win8.1 Pro >> PharoVM compiled on CentOS6.5 >> >> [philippeback@CENTOSDEV zeroconf-centos]$ time ./pharo-vm/pharo -vm-display-null Pharo.image eval '5 asSeconds asDelay wait' >> a Delay(5000 msecs) >> >> real 0m0.473s <-- not much... >> user 0m0.285s >> sys 0m0.140s >> [philippeback@CENTOSDEV zeroconf-centos]$ time ./pharo-vm/pharo -vm-display-null Pharo.image eval '5 asSeconds asDelay wait' >> a Delay(5000 msecs) >> >> real 0m0.360s <-- not much either >> user 0m0.257s >> sys 0m0.095s >> [philippeback@CENTOSDEV zeroconf-centos]$ time ./pharo-vm/pharo -vm-display-null Pharo.image eval '5 asSeconds asDelay wait' >> a Delay(5000 msecs) >> >> real 0m0.374s >> user 0m0.269s >> sys 0m0.103s >> [philippeback@CENTOSDEV zeroconf-centos]$ time ./pharo-vm/pharo -vm-display-null Pharo.image eval '5 asSeconds asDelay wait' >> >> a Delay(5000 msecs) >> >> real 0m5.324s >> user 0m0.338s >> sys 0m0.067s >> [philippeback@CENTOSDEV zeroconf-centos]$ >> [philippeback@CENTOSDEV zeroconf-centos]$ ^C <--- FROZEN!!!! >> >> >> [philippeback@CENTOSDEV zeroconf-centos]$ time ./pharo-vm/pharo -vm-display-null Pharo.image eval '5 asSeconds asDelay wait' >> a Delay(5000 msecs) >> >> real 0m0.468s >> user 0m0.287s >> sys 0m0.171s >> [philippeback@CENTOSDEV zeroconf-centos]$ time ./pharo-vm/pharo -vm-display-null Pharo.image eval '5 asSeconds asDelay wait' >> a Delay(5000 msecs) >> >> real 0m0.639s >> user 0m0.281s >> sys 0m0.233s >> [philippeback@CENTOSDEV zeroconf-centos]$ time ./pharo-vm/pharo -vm-display-null Pharo.image eval '5 asSeconds asDelay wait' >> a Delay(5000 msecs) >> >> real 0m0.331s >> user 0m0.260s >> sys 0m0.066s >> [philippeback@CENTOSDEV zeroconf-centos]$ time ./pharo-vm/pharo -vm-display-null Pharo.image eval '5 asSeconds asDelay wait' >> a Delay(5000 msecs) >> >> real 0m0.493s >> user 0m0.265s >> sys 0m0.210s >> [philippeback@CENTOSDEV zeroconf-centos]$ time ./pharo-vm/pharo -vm-display-null Pharo.image eval '5 asSeconds asDelay wait' >> a Delay(5000 msecs) >> >> real 0m0.343s >> user 0m0.258s >> sys 0m0.073s >> [philippeback@CENTOSDEV zeroconf-centos]$ time ./pharo-vm/pharo -vm-display-null Pharo.image eval '5 asSeconds asDelay wait' >> a Delay(5000 msecs) >> >> real 0m0.352s >> user 0m0.314s >> sys 0m0.035s >> [philippeback@CENTOSDEV zeroconf-centos]$ time ./pharo-vm/pharo -vm-display-null Pharo.image eval '5 asSeconds asDelay wait' >> a Delay(5000 msecs) >> >> real 0m0.303s >> user 0m0.266s >> sys 0m0.032s >> >> >> Completely un[reliable|predictable]... >> >> Phil >> >> # time ./pharo Pharo.image eval '5 asSeconds asDelay wait' >> a Delay(5000 msecs) >> >> real 0m0.696s >> user 0m0.580s >> sys 0m0.060s >> >> # time ./pharo Pharo.image eval '5 asSeconds asDelay wait' >> a Delay(5000 msecs) >> >> real 0m5.755s >> user 0m0.812s >> sys 0m0.080s >> >> Weird ! >> >> Must have something todo with virtual hardware ... >> >>> On 28 Oct 2014, at 18:24, Norbert Hartl <norbert(a)hartl.name> wrote: >>> >>> I just recognized that Delay is working in a strange way on my linux box >>> >>> $ time pharo-vm-nox ./Pharo.image eval "(Delay forSeconds: 5) wait" >>> a Delay(5000 msecs) >>> >>> real 0m0.158s >>> user 0m0.136s >>> sys 0m0.020s >>> >>> I use the vm from the ppa. What do you get when you execute it? >>> >>> Norbert >>> >> >> >> > >

Oct. 29, 2014

Re: [Pharo-dev] Unpackaged code

by Marcus Denker

> On 29 Oct 2014, at 09:54, Max Leske <maxleske(a)gmail.com> wrote: > > >> On 29.10.2014, at 09:45, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >> >>>> >>>> @free.fr <http://free.fr/>> >>>> We need the concept of âthis is code that is automatically generated, it is not part of any package and this is meant to be like thatâ. >>> >>> Nautilus (or RPackage?) does provide the âUnpackagedâ category. Wouldnât that be âgood enoughâ for now? >>> >> People would emmediatly report bugs that there is unpackaged code. > > True. > >> We need to concept of âthis is ok that there is no packageâ. > > But we donât have that right now. And the problem with nil as category remains. How about replacing a nil category with âUnpackagedâ implicitly for the time being? It would at least âfixâ one problem. > Ok. Marcus

Oct. 29, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] dd006c: 40336

by Thierry Goubier

2014-10-29 9:30 GMT+01:00 Max Leske <maxleske(a)gmail.com>: > > On 29.10.2014, at 08:22, Marcus Denker <marcus.denker(a)gmail.com> wrote: > > > > > > > On Wednesday, Oct 29, 2014 at 8:18 am, Max Leske <maxleske(a)gmail.com>, > wrote: > >> > On 29.10.2014, at 01:17, stepharo wrote: >> >> > >> >> > Good question :). >> >> > I do not know I would say that having the package Unpackaged would be >> better than nil >> @free.fr> > > >> So maybe the bug is that it should not be allowed to pass nil as category? >> >> >> @free.fr> > > We need the concept of "this is code that is automatically generated, it > is not part of any package and this is meant to be like that". > > > Nautilus (or RPackage?) does provide the 'Unpackaged' category. Wouldn't > that be "good enough" for now? > RPackage :) Thierry > > (there is now code in a package Generated-code-non-existing-package that > is of that kind, but the problem is that this package is always dirty of > code gets generated). > > > https://pharo.fogbugz.com/f/cases/14097/generated-code-non-existing-package… > > Would be nice if someone would implement a solution for this. > > > For libgit2 I simply sublassed NB and put the auto-generated methods into > the protocols I choose. Of course that's not a general solution. > > >> > >> >> > On 28/10/14 16:26, Max Leske wrote: >> >> >> I just fixed a couple of Fuel tests that failed because it is possible >> to create a trait with the category set to nil. When creating a new trait >> with the same name this results in an exception being signaled. Should we >> consider this a bug? It's not cool to create a trait in category nil but >> since it's possible... Should I open an issue? >> >> >> >> >> >> Cheers, >> >> >> Max >> >> >> >> >> >> >> >> >>> On 28.10.2014, at 20:42, Max Leske wrote: >> >> >>> >> >> >>> Oh yeah! Maybe now the Fuel tests will be back to green :) >> >> >>> >> >> >>>> On 28.10.2014, at 20:23, stepharo wrote: >> >> >>>> >> >> >>>> Thanks esteban! >> >> >>>> I'm unstuck :) >> >> >>>> >> >> >>>> On 28/10/14 07:41, GitHub wrote: >> >> >>>>> 40336 >> >> >>>>> 14337 Removing a trait usage raises an exception (2nd attempt) >> >> >>>>> https://pharo.fogbugz.com/f/cases/14337 >> >> >>>> >> >> >> >> >> >> >> >> >> >> >> > >> >> > >> >> >> >> >> >> @free.fr>@gmail.com>@free.fr> > > >

Oct. 29, 2014

Re: [Pharo-dev] Unpackaged code

by Max Leske

> On 29.10.2014, at 09:45, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >>> >>> @free.fr <http://free.fr/>> >>> We need the concept of âthis is code that is automatically generated, it is not part of any package and this is meant to be like thatâ. >> >> Nautilus (or RPackage?) does provide the âUnpackagedâ category. Wouldnât that be âgood enoughâ for now? >> > People would emmediatly report bugs that there is unpackaged code. True. > We need to concept of âthis is ok that there is no packageâ. But we donât have that right now. And the problem with nil as category remains. How about replacing a nil category with âUnpackagedâ implicitly for the time being? It would at least âfixâ one problem. Max > > Marcus >

Oct. 29, 2014