- Pharo-dev - lists.pharo.org

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

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

by Marcus Denker

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. Marcus

Oct. 1, 2013

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

by phil＠highoctane.be

Still, why does it occur ? Normal ? I experienced that on a class with quite a number of instVars.

Oct. 1, 2013

Re: [Pharo-dev] SlotVirus

by Marcus Denker

On Oct 1, 2013, at 9:23 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Oct 1, 2013, at 9:07 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> And we should not forget to do these cleanups: we now have nearly everything double in the system: >> -> Compiler >> -> Inspector >> -> Debugger >> -> ClassBuilder >> -> ClassOrganizer >> -> Browserâ¦. > > -> Rpackage vs PackaInfo vs. SystemCategory > -> Ring vs. PseudeClass&co vs. RBClass > -> AST vs RB AST -> Url vs. ZnUrl -> ZnMimeType vs MimeType -> NewList vs whichever-of-the 30 classes with "List" in its name -> FreeType vs. Bitmap fonts -> TreeInspector vs. ObjectExplorer We should really clean up. Marcus

Oct. 1, 2013

Re: [Pharo-dev] SlotVirus

by Marcus Denker

On Oct 1, 2013, at 9:07 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > And we should not forget to do these cleanups: we now have nearly everything double in the system: > -> Compiler > -> Inspector > -> Debugger > -> ClassBuilder > -> ClassOrganizer > -> Browserâ¦. -> Rpackage vs PackaInfo vs. SystemCategory -> Ring vs. PseudeClass&co vs. RBClass -> AST vs RB AST -> I am sure I am forgetting many othersâ¦ Marcus

Oct. 1, 2013

Re: [Pharo-dev] unexpected lack of Method Version History (due to CI process?)

by Goubier Thierry

Le 30/09/2013 17:51, Marcus Denker a Ã©crit : > > On Sep 30, 2013, at 5:40 PM, btc(a)openinworld.com wrote: > >> In the process of reviewing a fix to an issue [1] that I reported with PharoLauncher, I downloaded the latest CI result and browsed to the method I knew had changed [2]. I wanted to directly observe the change in the version history, but was surprised that there was no version history for the method. My uninformed intuition is this relates to some 'clean up for release' run as part of the build process to strip out old versions to compact the image delivered by the CI process, but does it make sense to do this for every build? >> I can understand not wanting this to grow indefinitely to bloat the image - but perhaps this compaction would be better only for major releases? I guess the downside is that you are then not exercising the 'full release' process every build. However having in image Version History extending a fair way back in time has always seemed to me to be one of the very cool (i.e. useful features of Pharo/Smalltalk). Without this, it feels like 'something' has been lost. The ultimate solution would seem to be linking the method version history to a network resource for the full history only as required per method. Any chance anyone is working on something like that? >> > > Keep in mind that the .changes history and monticello are completely separate. When you load a mc version, you just load *that version*. > > We really need to have the "versions" of the method go and ask the repo. Now the problem is that Monticello is not really nice: it has complete snapshots per commit in a zip file. > Getting version out there of a method is not possibleâ¦ without building infrastructure for it. gitfiletree repositories have that capability, i.e. querying the repo to get all versions of a method (but I didn't write the code which merges both the changes history and the package repo history in the same version browser). Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Oct. 1, 2013