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

eGov Hackathon in Namur, Belgium, this friday and week end - takers?

by phil＠highoctane.be

There has been 4 people bailing out and having paid their space I am going to use Pharo as a showcase over there. Any takers to join me to hack for the common good and showcase Pharo's powers? (Additional perk: I've Pharo t-shirts ) Here is the info: http://hackathonegovwallonia.net/ Phil --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller

Oct. 1, 2013

[update 3.0] #30436

by Esteban Lorenzano

30436 ----- 11732 add NonInteractiveTranscript to kernel packages https://pharo.fogbugz.com/f/cases/11732 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-Support-EstebanLorenza…

Oct. 1, 2013

Re: [Pharo-dev] Primitives lookupEntryIn:index: fails on mac with the latest vm

by Esteban Lorenzano

yes, latest builds are unstable. I'm promoting a new stable version based in a previous commit soon. Esteban On Oct 1, 2013, at 11:16 AM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > It also happens on other machines. > > > On Mon, Sep 30, 2013 at 10:45 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > Might be something related to my particular machine but it happens consistently. > I'll try it tomorrow other laptops. > > > On Mon, Sep 30, 2013 at 10:37 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > That would be strange (but only related to the image) since the acceptance tests almost > pass... > > https://ci.inria.fr/pharo/view/3.0-VM/job/PharoVM-AcceptanceTest/SLAVE=rmod… > > > > > On 2013-09-30, at 17:33, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > > Ok I will try tomorrow with the latest. > > > > Stef > > > > On Sep 30, 2013, at 10:24 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > > >> You have the standard vm installed. I my case I get: > >> > >> 'NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 Sep 30 2013 > >> NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 Sep 30 2013 > >> https://github.com/pharo-project/pharo-vm.git Commit: 8252469192542b1adb17185e2d17178e08888903 Date: 2013-09-30 09:44:35 -0300 By: Camillo Bruni <camillobruni(a)gmail.com> Jenkins build #14724 > >> ' > >> > >> On Mon, Sep 30, 2013 at 10:17 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Hi andrei > >> > >> I never saw it and I could not reproduce it I tried 20 times on NB-win32 with the latest image and my vm is > >> > >> Smalltalk vm version > >> > >> 'NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 > >> NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 > >> git://gitorious.org/cogvm/blessed.git Commit: 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14535 > >> ' > >> > >> Stef > >> > >>> Hi, > >>> > >>> I was trying to merge a slice into the latest Pharo 3 image when I got a FileSystemError in MacStore(DiskStore)>>basicEntry:path:nodesDo:. This happens as 'Primitives lookupEntryIn:index:' returns #badDirectoryPath. The bad part is that it goes into an infinite loop and blocks the image. The same scenario works ok with the stable pharo vm. > >>> > >>> I can reproduce this by going to the PharoInbox choosing a package that is not merged (let's say NativeBoost-Win32-CamilloBruni.42) and hit merge. If no error appears the first time, close the merge window and select merge again. For almost all packages, after a few time I get the previous error. > >>> > >>> Has anyone encountered this before? Might it be related to https://pharo.fogbugz.com/f/cases/7559 ? > >>> > >>> Cheers, > >>> Andrei > >> > >> > > > > >

Oct. 1, 2013

I want to remove Pharo/XMLWriter since it is in PharoExtras/XMLWriter

by StÃ©phane Ducasse

Hi guys does anybody use Pharo/XMLWriter because the official repo is PharoExtras/XMLWriter And I want to remove Pharo/XMLWriter Stef

Oct. 1, 2013

SlotVirus

by Torsten Bergmann

>we now have nearly everything double in the system: > >We should really clean up. And introduce namespaces ;)

Oct. 1, 2013

Re: [Pharo-dev] Primitives lookupEntryIn:index: fails on mac with the latest vm

by Andrei Chis

It also happens on other machines. On Mon, Sep 30, 2013 at 10:45 PM, Andrei Chis <chisvasileandrei(a)gmail.com>wrote: > Might be something related to my particular machine but it happens > consistently. > I'll try it tomorrow other laptops. > > > On Mon, Sep 30, 2013 at 10:37 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > >> That would be strange (but only related to the image) since the >> acceptance tests almost >> pass... >> >> >> https://ci.inria.fr/pharo/view/3.0-VM/job/PharoVM-AcceptanceTest/SLAVE=rmod… >> >> >> >> >> On 2013-09-30, at 17:33, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> wrote: >> >> > Ok I will try tomorrow with the latest. >> > >> > Stef >> > >> > On Sep 30, 2013, at 10:24 PM, Andrei Chis <chisvasileandrei(a)gmail.com> >> wrote: >> > >> >> You have the standard vm installed. I my case I get: >> >> >> >> 'NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: >> acc98e51-2fba-4841-a965-2975997bba66 Sep 30 2013 >> >> NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: >> acc98e51-2fba-4841-a965-2975997bba66 Sep 30 2013 >> >> https://github.com/pharo-project/pharo-vm.git Commit: >> 8252469192542b1adb17185e2d17178e08888903 Date: 2013-09-30 09:44:35 -0300 >> By: Camillo Bruni <camillobruni(a)gmail.com> Jenkins build #14724 >> >> ' >> >> >> >> On Mon, Sep 30, 2013 at 10:17 PM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> >> Hi andrei >> >> >> >> I never saw it and I could not reproduce it I tried 20 times on >> NB-win32 with the latest image and my vm is >> >> >> >> Smalltalk vm version >> >> >> >> 'NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: >> a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 >> >> NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: >> a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 >> >> git://gitorious.org/cogvm/blessed.git Commit: >> 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 >> By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14535 >> >> ' >> >> >> >> Stef >> >> >> >>> Hi, >> >>> >> >>> I was trying to merge a slice into the latest Pharo 3 image when I >> got a FileSystemError in MacStore(DiskStore)>>basicEntry:path:nodesDo:. >> This happens as 'Primitives lookupEntryIn:index:' returns >> #badDirectoryPath. The bad part is that it goes into an infinite loop and >> blocks the image. The same scenario works ok with the stable pharo vm. >> >>> >> >>> I can reproduce this by going to the PharoInbox choosing a package >> that is not merged (let's say NativeBoost-Win32-CamilloBruni.42) and hit >> merge. If no error appears the first time, close the merge window and >> select merge again. For almost all packages, after a few time I get the >> previous error. >> >>> >> >>> Has anyone encountered this before? Might it be related to >> https://pharo.fogbugz.com/f/cases/7559 ? >> >>> >> >>> Cheers, >> >>> Andrei >> >> >> >> >> > >> >> >

Oct. 1, 2013

Re: [Pharo-dev] Weird issue with removing instance vars from class def: instance vars jumbled

by Marcus Denker

On Oct 1, 2013, at 10:13 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 01.10.2013 um 09:37 schrieb Marcus Denker <marcus.denker(a)inria.fr>: > >> >> On Oct 1, 2013, at 9:34 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >> >>> Still, why does it occur ? Normal ? I experienced that on a class with quite a number of instVars. >> >> This seems to be a bug. When you remove / add inst vars, the offset of all those behind need to change >> (and all in the subclass). >> This is done by the ClassBuilder by recompiling (there is code somewhere to do it more intelligently, >> by using bytecode level IR to patch the offsets, but this is not yet active). >> >> We need some reproducible case to fix the problemâ¦ because normally the class builder does the right thing, >> I wonder in which case there is a problem. >> > I have the same opinion that the behavior changed quite a bit. E.g. I can't remember that it was allowed to have shadowed instance variabels. Nowadays there is not even a warning. Yes, that was a mistake I introduced. In Pharo2 development phase, I merged some classes. For that the first step was to move ivars from the subclass to the superclass. The resulting change was not mergable, not even with a chagneset. (I think raising an Error in the ClassBuilder is wrong, it needed to be a Warning, I (wrongly) just removed it). This has been fixed in Pharo3 with the new class builder. As it's a complete reimplemenation, there is no back port. And doing that chagne again in Pharo2 did not seem that important, but if someone fixes it we of course will include it. Marcus

Oct. 1, 2013

Re: [Pharo-dev] Weird issue with removing instance vars from class def: instance vars jumbled

by phil＠highoctane.be

I think that I may have reordered some instVars as well in the process. They look like in alphabetical order when autogenerated from the refactorings menu (instvar accessors). Also, I regenerated them more than once and removed some manually. (Which makes me think that a "unselect all" from that menu would be welcome...) I'll look for a reproducable sample. Working on that tomorrow. Phil

Oct. 1, 2013

Re: [Pharo-dev] SlotVirus

by phil＠highoctane.be

And we were complaining about double hierarchies in morphs... I kind of agree that the Virus monicker isn't the best around. On Tue, Oct 1, 2013 at 9:07 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Oct 1, 2013, at 9:02 AM, btc(a)openinworld.com wrote: > > > > > I've just bumped into an interesting class named 'SlotVirus'. Thats a > cute name, but its not really business friendly. In business some people > in power get to be unreasonable about these things. They are the > gatekeepers > > and unfortunately we don't get to choose that they should be more > reasonable. Perhaps something like 'SlotPropagator' or 'SlotPropagation' > could be considered. > > > > This is a helper class that introduced meta-objects for instance variables > in all classes (that's why "Slot allInstances size" returns you the number > of ivars in the systemâ¦). > > When we remove the old class builder this class is removed, too. > > And we should not forget to do these cleanups: we now have nearly > everything double in the system: > -> Compiler > -> Inspector > -> Debugger > -> ClassBuilder > -> ClassOrganizer > -> Browserâ¦. > > > Marcus > >

Oct. 1, 2013

Re: [Pharo-dev] Weird issue with removing instance vars from class def: instance vars jumbled

by Norbert Hartl

Am 01.10.2013 um 09:37 schrieb Marcus Denker <marcus.denker(a)inria.fr>: > > On Oct 1, 2013, at 9:34 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > >> Still, why does it occur ? Normal ? I experienced that on a class with quite a number of instVars. > > This seems to be a bug. When you remove / add inst vars, the offset of all those behind need to change > (and all in the subclass). > This is done by the ClassBuilder by recompiling (there is code somewhere to do it more intelligently, > by using bytecode level IR to patch the offsets, but this is not yet active). > > We need some reproducible case to fix the problemâ¦ because normally the class builder does the right thing, > I wonder in which case there is a problem. > I have the same opinion that the behavior changed quite a bit. E.g. I can't remember that it was allowed to have shadowed instance variabels. Nowadays there is not even a warning. Norbert

Oct. 1, 2013