- Pharo-dev - lists.pharo.org

Jenkins build is back to stable : Pharo-2.0-Tests Â» run 1,vm,linux #285

by no-reply＠ci.inria.fr

See <https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/Run=run%201,VM=vm,label=linux…>

April 7, 2014

Re: [Pharo-dev] ghost windows

by Ben Coman

April 7, 2014

Jenkins build is unstable: Pharo-2.0 #359

by no-reply＠ci.inria.fr

See <https://ci.inria.fr/pharo/job/Pharo-2.0/359/>

April 7, 2014

Re: [Pharo-dev] MC diffs are seriously broken in Pharo2.0

by Stefan Marr

Hi: On 07 Apr 2014, at 13:28, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > ps: afaik, vmmaker was loading in 3.0 with some fixes, but there is still not configuration released for it. This requires the use of the old compiler I think. The whole source code generation does not yet work is Opal. The simulators however work in Pharo 3.0. Best regards Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/

April 7, 2014

Re: [Pharo-dev] MC diffs are seriously broken in Pharo2.0

by Esteban Lorenzano

On 07 Apr 2014, at 08:28, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > Sorry but I do not have *any* of this problems (and I use same things as you all the time for the vm stuff). > I wonder what happened to you to get this kind of behaviour. > Can I have your image to test it? forget to say that I will check it later on the weekâ¦ now I have an plane to take :) > > Esteban > > ps: afaik, vmmaker was loading in 3.0 with some fixes, but there is still not configuration released for it. > > On 06 Apr 2014, at 12:36, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> I'm trying to fix some Pharo VM issues (11330), but have awfully bad experience with Pharo2.0 tools. >> >> The autocompletion stuff is a joke, it moves the input cursor randomly and spoils my input. That's the first thing I disable. >> >> The pharo's PolyMorphDiffTool is good looking but awfully sloooow >> It clearly does not scale (10 minutes or so to diff Eliot's branch) so I reverted to the old diff tool. >> But of course, someone broke MCMethodDefinition>>summary (gratuitously?) and I had to revert this method to have class names displayed again. >> >> But worse than all, there are insane caches operating in MCVersion that drove me crazy. >> Here is the scenario: >> 1) I diff working copy against package.branchA-version.mcz >> 2) I cherry pick and install a few methods >> 3) I diff against package.branchA-version.mcz again to check if I missed smthing >> 4) Huh? it looks like my cherry pick have not been installed??? >> Yes they were installed, but the completePackageSnapshot has been cached in MCVersion!!! >> What a mistake! The working copy is going to evolve, caching a snapshot of it is a DUMB thing.It means that methods that I further change in the working copy will NEVER be taken into account next time I'll do a diff. >> So I had to change MCVersion>>changes >> ^ self completeSnapshot patchRelativeToBase: self loadCompletePackageSnapshot >> >> This is so broken that I have to report here. >> Note that I did not check if symptoms are still in Pharo 3.0, but the working copy scnapshot cache still is for sure! >> >> Guys, it makes me wonder, who is eating the dog food? >> Did anyone progress into developing VM in Pharo 3.0, because if I must eat it, I'd prefer the freshest ;) >> Or if I fix some more bug, I'd like my efforts to not apply to an obsolete version. >

April 7, 2014

Re: [Pharo-dev] MC diffs are seriously broken in Pharo2.0

by Esteban Lorenzano

Hi, Sorry but I do not have *any* of this problems (and I use same things as you all the time for the vm stuff). I wonder what happened to you to get this kind of behaviour. Can I have your image to test it? Esteban ps: afaik, vmmaker was loading in 3.0 with some fixes, but there is still not configuration released for it. On 06 Apr 2014, at 12:36, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > I'm trying to fix some Pharo VM issues (11330), but have awfully bad experience with Pharo2.0 tools. > > The autocompletion stuff is a joke, it moves the input cursor randomly and spoils my input. That's the first thing I disable. > > The pharo's PolyMorphDiffTool is good looking but awfully sloooow > It clearly does not scale (10 minutes or so to diff Eliot's branch) so I reverted to the old diff tool. > But of course, someone broke MCMethodDefinition>>summary (gratuitously?) and I had to revert this method to have class names displayed again. > > But worse than all, there are insane caches operating in MCVersion that drove me crazy. > Here is the scenario: > 1) I diff working copy against package.branchA-version.mcz > 2) I cherry pick and install a few methods > 3) I diff against package.branchA-version.mcz again to check if I missed smthing > 4) Huh? it looks like my cherry pick have not been installed??? > Yes they were installed, but the completePackageSnapshot has been cached in MCVersion!!! > What a mistake! The working copy is going to evolve, caching a snapshot of it is a DUMB thing.It means that methods that I further change in the working copy will NEVER be taken into account next time I'll do a diff. > So I had to change MCVersion>>changes > ^ self completeSnapshot patchRelativeToBase: self loadCompletePackageSnapshot > > This is so broken that I have to report here. > Note that I did not check if symptoms are still in Pharo 3.0, but the working copy scnapshot cache still is for sure! > > Guys, it makes me wonder, who is eating the dog food? > Did anyone progress into developing VM in Pharo 3.0, because if I must eat it, I'd prefer the freshest ;) > Or if I fix some more bug, I'd like my efforts to not apply to an obsolete version.

April 7, 2014

Re: [Pharo-dev] Package tags for extensions

by Esteban Lorenzano

Hi Yuri, is no-issue and no-work in progress: is like that by design. extensions are package related and not tag related. soâ¦ you can name an extension MyPackage-B, but it will still be going to rpackage extensions. one of the things we need to continue improving is protocolsâ¦ now they are objects (before they were just strings), but extensions are still name matching conventions, and they should be also objects (like ExtensionProtocol) or something like that. but wellâ¦ future stuff. Esteban On 07 Apr 2014, at 05:54, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi guys, > > Now we have tags for packages in Pharo 3, and itâs very cool. So if I select a tag âAâ in âMyPackageâ I will see all classes from category âMyPackage-Aâ. On the other hand if Iâm extending another class with a protocol â*MyPackage-Bâ I canât see that class under the âBâ tag. Is this some kind of issue or itâs still a work in progress. > > Cheers. > Uko

April 7, 2014

Re: [Pharo-dev] [Vm-dev] Pharo VM bug 11130

by Nicolas Cellier

2014-04-07 8:13 GMT+02:00 Pharo4Stef <pharo4Stef(a)free.fr>: > > On 06 Apr 2014, at 23:08, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > 2014-04-06 22:29 GMT+02:00 Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com>: > >> Good news, >> I've managed to make your issue apparently vanish in Pharo3.0 VM. >> For this, I: >> - cleaned up unecessary differences with Eliot's VMMaker.oscog branch, >> - removed unecessary changes ahead of VMMaker.oscog-eem.333 version >> (those stamped LucFabresse) >> - carefully applied changes from VMMaker.oscog-eem.333 that were not >> applied >> Note that this version was marked as merged, which it was obviously not >> Please, if you do not fully merge, but just cherry pick some changes, >> it's better to not merge. >> - upgraded to (merged) VMMaker.oscog-eem.335 because it fixes a snafu >> - integrated the issues for which I emitted a pull request >> >> All this work can be found publicly at >> https://github.com/nicolas-cellier-aka-nice/pharo-vm/compare/fixMergeWithEl… >> >> I cannot tell which missing change exactly was the root cause, and I >> cannot dissect either, but I saw several + LiteralStart missing... Or it >> could be related to cogit method/block native code generation... >> The changes are most probably here >> >> https://github.com/nicolas-cellier-aka-nice/pharo-vm/commit/af718618eee516d… >> >> Bad news, >> the structures at beginning of src/cm/cogit.c are generated out of order, >> and I didn't find the cause yet. >> Once solved, I think my branch should be carefully reviewed and >> integrated. >> >> > Haha! this is Class class>>superclassOrder: which break things... > The order of structures passed on input was mostly good but ruined on > output... > > The Squeak ChangeSet class>>superclassOrder: does not convert the list of > classes asSet, thus somehow preserves provided order. > The Pharo version does not take so much care it seems... > Apparently the method was changed again in Pharo3.0, but neither does it > preserve order. > > > Can you publish the change for the superclassOrder: as a bug entry? > we should add a test > > Yes, I did: https://pharo.fogbugz.com/f/cases/13180/Class-class-superclassOrder-should-… Of course, those kind of expectations should be asserted by a test (I didn't). > After fixing it, compilation went well... > > >> >> 2014-04-03 4:13 GMT+02:00 Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com>: >> >> >>> >>> >>> 2014-04-02 23:59 GMT+02:00 Stephan Eggermont <stephan(a)stack.nl>: >>> >>> >>>> Nicolas wrote: >>>> >Hmm, don't waste too much time. >>>> >All these methods are unchanged in github pharo-vm head revision >>>> (VMMaker-oscog-StefanMarr.313) >>>> >The cause must be completely different in latest pharo vms. >>>> >>>> Uhm, why? They haven't changed. >>>> >>> >>> Sorry, haven't changed means that there's no diff with the corrected >>> version. >>> IOW, the fixes from Eliot have been integrated for a long time already. >>> You are seeing another symptom, probably another bug impacting the same >>> code. >>> There are many diffs between pharo's and Eliot's branch, but not where >>> you're looking at. >>> >>> Pharo vms 105 and later no longer crash, but all reliably show the bug. >>>> And 236 is the last Squeak one to show the problem. >>>> >>>> I might take a look at Esteban's versions from the same time, >>>> 228 and 229 >>>> >>>> Stephan >>> >>> >>> >> > >

April 7, 2014

Re: [Pharo-dev] MC diffs are seriously broken in Pharo2.0

by Henrik Johansen

On 06 Apr 2014, at 5:36 , Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > I'm trying to fix some Pharo VM issues (11330), but have awfully bad experience with Pharo2.0 tools. > > The autocompletion stuff is a joke, it moves the input cursor randomly and spoils my input. That's the first thing I disable. > > The pharo's PolyMorphDiffTool is good looking but awfully sloooow > It clearly does not scale (10 minutes or so to diff Eliot's branch) so I reverted to the old diff tool. > But of course, someone broke MCMethodDefinition>>summary (gratuitously?) and I had to revert this method to have class names displayed again. > > But worse than all, there are insane caches operating in MCVersion that drove me crazy. > Here is the scenario: > 1) I diff working copy against package.branchA-version.mcz > 2) I cherry pick and install a few methods > 3) I diff against package.branchA-version.mcz again to check if I missed smthing > 4) Huh? it looks like my cherry pick have not been installed??? > Yes they were installed, but the completePackageSnapshot has been cached in MCVersion!!! > What a mistake! The working copy is going to evolve, caching a snapshot of it is a DUMB thing.It means that methods that I further change in the working copy will NEVER be taken into account next time I'll do a diff. > So I had to change MCVersion>>changes > ^ self completeSnapshot patchRelativeToBase: self loadCompletePackageSnapshot > > This is so broken that I have to report here. > Note that I did not check if symptoms are still in Pharo 3.0, but the working copy scnapshot cache still is for sure! > > Guys, it makes me wonder, who is eating the dog food? > Did anyone progress into developing VM in Pharo 3.0, because if I must eat it, I'd prefer the freshest ;) > Or if I fix some more bug, I'd like my efforts to not apply to an obsolete version. Not only that, the simplest possible merge operation is broken: https://pharo.fogbugz.com/f/cases/12776/Cancelling-Previous-Contents-in-a-W… As it stands, MC in Pharo is nothing but a fancy change set applier, not a version control system. Cheers, Henry

April 7, 2014

Package tags for extensions

by Yuriy Tymchuk

Hi guys, Now we have tags for packages in Pharo 3, and itâs very cool. So if I select a tag âAâ in âMyPackageâ I will see all classes from category âMyPackage-Aâ. On the other hand if Iâm extending another class with a protocol â*MyPackage-Bâ I canât see that class under the âBâ tag. Is this some kind of issue or itâs still a work in progress. Cheers. Uko

April 7, 2014