- Pharo-dev - lists.pharo.org

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

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

by Marcus Denker

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â 2) send a mail to the list (the second option is good for complex cases) Marcius

Sept. 22, 2014

Re: [Pharo-dev] [Issue Tracker] Call for CleanUp of the issue tracker

by Marcus Denker

On 21 Sep 2014, at 17:09, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Nicolai Hess wrote >> There are open issues without any action on our part - for months. And >> that does not mean "we don't care" > > Please give issues which are closed simply because they are "stale" the > "postponed" status so they can be more easily found later (per > http://forum.world.st/Issue-Tracker-input-of-submitters-bug-fixers-needed-t…) > Maybe we should add a special close status for thoseâ¦ But for me it is important that they are âclosed* in the sense that they do not take any brain power when looking at the issue tracker. If the original submitter does not care after e.g. 1 year, I want to have the OK officially to be allowed to not care, either. Marcus

Sept. 22, 2014

Re: [Pharo-dev] [SO] Pharo 3 on 64-bit CentOS

by Nicolai Hess

2014-09-22 7:24 GMT+02:00 Martin McClure <martin(a)hand2mouse.com>: > On 09/21/2014 09:55 PM, Max Leske wrote: > >> http://stackoverflow.com/questions/25966652/cannot- >> even-install-pharo-3-on-centos-6-5 >> >> > It looks like Pharo 3.0 ships with a VM compiled against glibc 2.15, and > therefore requires glibc 2.15 or newer??? If so, that means that it won't > run on CentOS 6.5 at all. > > Older glibc versions are in use in a number of popular distributions that > are still supported -- at least CentOS 5, CentOS 6, and Ubuntu 10.04 are > still supported and have glibcs older than 2.15. > > Could the official VMs be built against older glibc, or is there some > feature in the newer glibc that we require? > a newer glibc version is not needed, it is just what is used on newer platforms. AFAIK Esteban will setup a build slave for this. ( http://forum.world.st/installing-pharo-3-0-on-Debian-wheezy-td4759635.html) > > Regards, > > -Martin > >

Sept. 22, 2014