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

Re: [Pharo-dev] Spec support for GT-Inspector

by Serge Stinckwich

On Mon, Sep 22, 2014 at 10:55 AM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > Hi Serge, > > There is no preview tab because the code just creates a model of the > browser; it does not actually create it's graphical representation. > Inspecting the code below in the latest moose image should show a preview > tab. We do not do this by default as then inspecting a spec > model could have a lot of side effects. > > (MessageBrowser > browseMessages: Object methods > refreshingBlock: [] > named: '') > buildWithSpec; > yourself Thank you for the explanation Andrei. Apparently there is a DNU when i click on preview. This is the side effect, you are talking about ? Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Sept. 22, 2014

Re: [Pharo-dev] Fixed case 11996 -- exception handler search bug

by Ben Coman

Sept. 22, 2014

Re: [Pharo-dev] Spec support for GT-Inspector

by Andrei Chis

Hi Serge, There is no preview tab because the code just creates a model of the browser; it does not actually create it's graphical representation. Inspecting the code below in the latest moose image should show a preview tab. We do not do this by default as then inspecting a spec model could have a lot of side effects. (MessageBrowser browseMessages: Object methods refreshingBlock: [] named: '') buildWithSpec; yourself Cheers, Andrei On Sun, Sep 21, 2014 at 7:36 PM, Serge Stinckwich < serge.stinckwich(a)gmail.com> wrote: > I try to open a Spec model in Playground like : > > MessageBrowser > browseMessages: Object methods > refreshingBlock: [] > named: '' > > but there is no preview tab apparently. > > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ > >

Sept. 22, 2014

Re: [Pharo-dev] AbstractNautilusUI "error, should not happen" from LayoutEmptyScope(LayoutAbstractScope)>>rebase:to:

by Nicolai Hess

Yes, this holds me be back for further refactorings on Nautilus. I was able to add a InstVar on NautilusUI and after that you can add and remove instvars again even on AbstractNautilusUI. But then you can not add this changes as a slice, I tried this but it failed: 13739 <https://pharo.fogbugz.com/default.asp?13739> Nautilus Refactoring 5: intermediate code cleanup (remove unused methods) btw this happens even before build 40147 I'll try to figure out what is needed to solve this issue. 2014-09-20 15:53 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > In build 40239, if I try to add an instance variable (e.g. 'xx') to > AbstractNautilusUI, I get "Error: should not happen" from LayoutEmptyScope( > LayoutAbstractScope)>>rebase:to: A tried a few other classes and they are > okay. I've tracked this down to occur since build 40147... > > 13697 Yet another cleanup of MessageBrowser API > https://pharo.fogbugz.com/f/cases/13697 > > 13698 Small cleanup of Model and the UI package > https://pharo.fogbugz.com/f/cases/13698 > > 13696 Nautilus Refactoring 1: Classlist widget > https://pharo.fogbugz.com/f/cases/13696 > > Is this a known problem? I can't identify a ticket on the tracker. > > cheers -ben > > >

Sept. 22, 2014

Re: [Pharo-dev] I'm confused about Process>>isTerminated

by Max Leske

On 22.09.2014, at 09:47, Max Leske <maxleske(a)gmail.com> wrote: > Thanks for the pointer. > > On 18.09.2014, at 22:52, Bob Westergaard <bwestergaard(a)gmail.com> wrote: > >> Why not use #waitTimeoutMsecs:? Something like: >> >> greenLight := Semaphore new. >> process := >> [started := true. >> [Semaphore new wait] ensure: > > I think that should be â[greenLight wait]â, shouldnât it? Sorry, youâre right. I should have thoroughly read Eliotâs e-mail first :) > >> [terminator := Processor activeProcess. >> unwound := true]. >> greenLight signal] forkAt: Processor activeProcess priority -1. >> >> expired := greenLight waitTimeoutMSecs: 1000. "or whatever suits you" >> deny: expired. >> assert: process isTerminated. >> " and so on" >> >> -- Bob >> >

Sept. 22, 2014

Re: [Pharo-dev] I'm confused about Process>>isTerminated

by Max Leske

Thanks for the pointer. On 18.09.2014, at 22:52, Bob Westergaard <bwestergaard(a)gmail.com> wrote: > Why not use #waitTimeoutMsecs:? Something like: > > greenLight := Semaphore new. > process := > [started := true. > [Semaphore new wait] ensure: I think that should be â[greenLight wait]â, shouldnât it? > [terminator := Processor activeProcess. > unwound := true]. > greenLight signal] forkAt: Processor activeProcess priority -1. > > expired := greenLight waitTimeoutMSecs: 1000. "or whatever suits you" > deny: expired. > assert: process isTerminated. > " and so on" > > -- Bob >

Sept. 22, 2014

Re: [Pharo-dev] Fixed case 11996 -- exception handler search bug

by Marcus Denker

On 22 Sep 2014, at 09:21, Max Leske <maxleske(a)gmail.com> wrote: > > On 22.09.2014, at 09:12, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On 22 Sep 2014, at 07:30, Martin McClure <martin(a)hand2mouse.com> wrote: >> >>> Andres and I developed a fix at ESUG for case 11996. The search for exception handlers was not taking into account the general case of exception handlers established or exceptions signaled while already in a handler block, so could find the wrong handler. >>> >>> I put the slices for this fix in the inbox a while back, but neglected to let the list know. >>> >>> Is there anything else I need to do to get this integrated into 4.0? >>> >> >> it is important to notify about it. There are >600 issues in the tracker, that means that just solving something but not telling will only lead to action if >> by chance someone looks a the issue tracker entry. (which means, it is very very unlikely). >> >> There are two ways to notify: >> >> 1) putting the issue to âfix review neededâ > > I noticed that I canât do that (at least not for the issues I havenât opened myself). Donât know if thatâs a deliberate choice but if you want to delegate a bit of work (and if the behaviour can be changed of course) I suggest that everyone should be able to set that status. I will have a look how to configure that. Marcus

Sept. 22, 2014

Re: [Pharo-dev] Fixed case 11996 -- exception handler search bug

by Max Leske

On 22.09.2014, at 09:12, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 22 Sep 2014, at 07:30, Martin McClure <martin(a)hand2mouse.com> wrote: > >> Andres and I developed a fix at ESUG for case 11996. The search for exception handlers was not taking into account the general case of exception handlers established or exceptions signaled while already in a handler block, so could find the wrong handler. >> >> I put the slices for this fix in the inbox a while back, but neglected to let the list know. >> >> Is there anything else I need to do to get this integrated into 4.0? >> > > it is important to notify about it. There are >600 issues in the tracker, that means that just solving something but not telling will only lead to action if > by chance someone looks a the issue tracker entry. (which means, it is very very unlikely). > > There are two ways to notify: > > 1) putting the issue to âfix review neededâ I noticed that I canât do that (at least not for the issues I havenât opened myself). Donât know if thatâs a deliberate choice but if you want to delegate a bit of work (and if the behaviour can be changed of course) I suggest that everyone should be able to set that status. > 2) send a mail to the list > > (the second option is good for complex cases) > > Marcius > >

Sept. 22, 2014

Re: [Pharo-dev] [issue tracker] back porting 4 to 3

by Marcus Denker

On Sun, Sep 21, 2014 at 3:42 AM, Ben Coman <btc(a)openinworld.com> wrote: > Marcus Denker wrote: > > On 11 Jun 2014, at 14:59, Sean P. DeNigris <sean(a)clipperadams.com> <sean(a)clipperadams.com> wrote: > > > > Marcus Denker-4 wrote > > > When there are issues that people wan to have back ported... > > > We should save this procedure in a more permanent place... > > > > > Indeedâ¦ I will put it somewhere. > > > > > I think this is a really good idea, but there is some complexity in that > an application uses those methods backported into the latest Pharo 3 will > not be compatible with the Pharo 3 "release". Is ConfigurationOfPharo3 > something that an application can depend on to bring these backported > methods into an existing Pharo3 image ? Perhaps that should be mentioned > in that procedure. And maybe also that should be part of a default > template in Versioneer? > We should do something that is not too complex. Marcus

Sept. 22, 2014

Re: [Pharo-dev] [issue tracker] back porting 4 to 3

by Marcus Denker

Yes, this is why https://pharo.fogbugz.com/f/cases/13606/testSlotScopeParallelism-is-failing is faling, too. There is a root cause for this that in some cases when changing classes that the layout gets not updated correctly... On 21 Sep 2014, at 03:42, Ben Coman <btc(a)openInWorld.com> wrote: > In build 40239, if I try to add an instance variable (e.g. 'xx') to AbstractNautilusUI, I get "Error: should not happen" from LayoutEmptyScope(LayoutAbstractScope)>>rebase:to: A tried a few other classes and they are okay. I've tracked this down to occur since build 40147... > > 13697 Yet another cleanup of MessageBrowser API > https://pharo.fogbugz.com/f/cases/13697 > > 13698 Small cleanup of Model and the UI package > https://pharo.fogbugz.com/f/cases/13698 > > 13696 Nautilus Refactoring 1: Classlist widget > https://pharo.fogbugz.com/f/cases/13696 > > Is this a known problem? I can't identify a ticket on the tracker. > > cheers -ben > >

Sept. 22, 2014