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

Re: [Pharo-dev] Suggested Syntax Highlighting Features for Beginners

by J.F. Rick

On Fri, Apr 4, 2014 at 8:28 PM, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > Did you also see that what I like is to make a distinction between a > possible selector and a wrong one? because this is nice. > Yes, that is nice. My guess is that for beginning programmers (rather than programmers new to Pharo), it might be nice to prioritize certain messages or even limit the messages to a subset initially, especially in a Microworld environment. Cheers, Jeff -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

April 7, 2014

Re: [Pharo-dev] Fogbugz simple review voting

by Damien Cassou

On Sun, Apr 6, 2014 at 4:16 AM, Ben Coman <btc(a)openinworld.com> wrote: > Just musing over a simple voting system for Fogbugz, perhaps just the > addition of statuses: > * Resolved (Reviewed by 1) > * Resolved (Reviewed by 2) > > and also useful might be: > * Working On (Feedback Requested) why not -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

April 7, 2014

Re: [Pharo-dev] Package tags for extensions

by GOUBIER Thierry

Hi Esteban, Yuri, It's really nice to hide extensions as objects and not anymore as protocols. I have been working with that for more than a year now, and it's very nice not to have to write anymore *Name-Of-Package to create extensions. Thierry ________________________________________ De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de Esteban Lorenzano [estebanlm(a)gmail.com] EnvoyÃ© : lundi 7 avril 2014 13:21 Ã : Pharo Development List Objet : Re: [Pharo-dev] Package tags for 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] Package tags for extensions

by Yuriy Tymchuk

Hi Esteban, thanks for explanation. Uko On 07 Apr 2014, at 13:21, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > 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

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