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

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

by Ben Coman

Sept. 22, 2014

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

by Camille Teruel

On 22 sept. 2014, at 09:14, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 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... Yes it's been a while that we suffer from this bug. Now that we found a way to reproduce it I could post a fix to review (https://pharo.fogbugz.com/f/cases/13606/testSlotScopeParallelism-is-failing) To reproduce create two class, one subclass of the other. Then add a class variable or a shared pool in the superclass. Then, you can see that the slot scope of the subclass is not correctly updated: TheSubclass layout slotScope parentScope == TheSubclass superclass layout slotScope. ---> false > > 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] [issue tracker] back porting 4 to 3

by Ben Coman

Sept. 22, 2014

Re: [Pharo-dev] Implementing lazy loading for expandable collections

by Max Leske

On 19.09.2014, at 21:45, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Fri, Sep 19, 2014 at 2:35 AM, Max Leske <maxleske(a)gmail.com> wrote: > Iâve written an implementation of lazily initialized expandable collections (for OrderedCollection and subclasses only for now), inspired by Alexandreâs talk at ESUG (http://www.youtube.com/watch?v=x0YJ2dsZdKg&list=UUO-vBhaKVZf0al-ISMMPvRw) The implementation is pretty much straight forward but there are a couple of culprits I want to point out in case anybody else wants to do this: > > - my implementation requires an extra instance variable in OrderedCollection to store the requested size. This extra instance variable will break Monticello (and possibly other tools) because Monticello uses OrderedCollections to load code and the particular way it uses them makes it impossible to change the number of instance variables on OrderedCollection. Also, all .mcz files written after the change will not be loadable by images without the new instance variable (same reason). > - the above means that you have to modify the code in the image manually and save a new âbase image" > - read only messages should obviously not initialize the array. The âfirstIndexâ and âlastIndexâ variables are quite handy for that. I initialize those variables to 1 and 0 respectively which makes most things work already (e.g. #size, #isEmpty etc.). > - when trying to implement the same for HashedCollection I couldnât. The image didnât just stop working, there was no output at all on the console, not even when using a debug VM. The problem seems to be MethodDictionary, at least thatâs the only subclass of Dictionary for which adding an instance variable doesnât work. > > Yes, alas the shape of MethodDIctionary is baked into the VM's method lookup code. It would be straight-forward to fix it, but it is still work and one would have to wait for people to update their VMs. When you say âfixâ, do you mean a hard coded change of the number of fields in MethodDictionary or do you mean a change that would allow one to change the number of fields in the future? In the former case someone wiser than me will have to make a decision, in the latter I would promote that change (if it doesnât affect performance of course). Max > > Iâll share some memory monitoring as soon as I have something significant (only just rolled it out). > > > Big thanks to Alex for his talk and the cool work he and his students did! > > Cheers, > Max > > > > -- > best, > Eliot

Sept. 22, 2014

Re: [Pharo-dev] Implementing lazy loading for expandable collections

by Max Leske

On 20.09.2014, at 14:27, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi Max! > > Thanks! This is something I wanted to push to Pharo for a long time. A simpler approach, would be to initialize the internal array to #() when initialized per default. This will provide pretty much the same benefits, and will not break the existing tools. > > Does this make sense to you? I think that would work well for standard use cases with #new. However, it wouldnât work for explicit size requests. The question of course is, how often will a collection be created with an explicit size and *still* stay empty. I guess you would know that better than me. I opted for the other solution because I didnât want to change the meaning of #new (which is to request a default size of 10) and because I simply assumed that even collections with explicitly requested size could stay empty. In terms of simplicity I like youâre idea far better of course :) It also makes a lot of changes moot that are necessary to initialize the array when required, because the array will simply be grown. What do your measurements say? Cheers, Max > > Alexandre > >> Le 19-09-2014 Ã 2:35, Max Leske <maxleske(a)gmail.com> a Ã©crit : >> >> Iâve written an implementation of lazily initialized expandable collections (for OrderedCollection and subclasses only for now), inspired by Alexandreâs talk at ESUG (http://www.youtube.com/watch?v=x0YJ2dsZdKg&list=UUO-vBhaKVZf0al-ISMMPvRw) The implementation is pretty much straight forward but there are a couple of culprits I want to point out in case anybody else wants to do this: >> >> - my implementation requires an extra instance variable in OrderedCollection to store the requested size. This extra instance variable will break Monticello (and possibly other tools) because Monticello uses OrderedCollections to load code and the particular way it uses them makes it impossible to change the number of instance variables on OrderedCollection. Also, all .mcz files written after the change will not be loadable by images without the new instance variable (same reason). >> - the above means that you have to modify the code in the image manually and save a new âbase image" >> - read only messages should obviously not initialize the array. The âfirstIndexâ and âlastIndexâ variables are quite handy for that. I initialize those variables to 1 and 0 respectively which makes most things work already (e.g. #size, #isEmpty etc.). >> - when trying to implement the same for HashedCollection I couldnât. The image didnât just stop working, there was no output at all on the console, not even when using a debug VM. The problem seems to be MethodDictionary, at least thatâs the only subclass of Dictionary for which adding an instance variable doesnât work. >> >> Iâll share some memory monitoring as soon as I have something significant (only just rolled it out). >> >> >> Big thanks to Alex for his talk and the cool work he and his students did! >> >> Cheers, >> Max >

Sept. 22, 2014

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

by Max Leske

â¦ *rolling my eyes*â¦ *facepalm*â¦ On 22.09.2014, at 11:55, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 22 Sep 2014, at 11:21, Ben Coman <btc(a)openInWorld.com> wrote: > >> Max Leske 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've never had a problem with that, and I don't think anything special was ever done to my account. btw, You do need to click the <Resolve> button to get those choices. >> cheers -ben > > yes, there are no special configsâ¦ you probably are not pressing âresolveâ :) > > Esteban

Sept. 22, 2014

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

by Max Leske

Hi Eliot, Thanks a lot for those explanations. On 18.09.2014, at 20:53, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Max, > > phhh, time zone differences suck ;-) > > On Thu, Sep 18, 2014 at 3:50 AM, Max Leske <maxleske(a)gmail.com> wrote: > Hi Eliot, > > On 18.09.2014, at 01:18, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > >> Hi Max, >> >> On Wed, Sep 17, 2014 at 1:59 PM, Max Leske <maxleske(a)gmail.com> wrote: >> Hi Eliot >> >> >> On 16.09.2014, at 20:18, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >>> Hi Max, >>> >>> On Tue, Sep 16, 2014 at 11:05 AM, Max Leske <maxleske(a)gmail.com> wrote: >>> Hi >>> >>> As always when I want to check if a process has died I get very confused by #isTerminated and Iâm wondering if I just donât get how itâs supposed to work or if there are others that share my confusion. >>> >>> Old implementation: >>> >>> isTerminated >>> >>> self isActiveProcess ifTrue: [^ false]. >>> ^suspendedContext isNil >>> or: ["If the suspendedContext is the bottomContext it is the block in Process>>newProcess. >>> If so, and the pc is greater than the startpc, the bock has alrteady sent and returned >>> from value and there is nothing more to do." >>> suspendedContext isBottomContext >>> and: [ suspendedContext pc > suspendedContext startpc ] ] >>> >>> >>> Pharo 4 implementation: >>> >>> isTerminated >>> self isActiveProcess ifTrue: [^ false]. >>> ^suspendedContext isNil >>> or: ["If the suspendedContext is the bottomContext it is the block in Process>>newProcess. >>> If so, and the pc is greater than the startpc, the bock has alrteady sent and returned >>> from value and there is nothing more to do.â >>> suspendedContext isBottomContext >>> and: [ suspendedContext isDead not â<âââââââââââââââââââââââââ new" >>> and: [ suspendedContext pc > suspendedContext startpc ] ] ] >>> >>> >>> The old implementation would break if the suspended context was dead (i.e. the pc was nil) because the send of #> would produce an MNU. >>> The new implementation doesnât fix that, even though it looks like it at first glance: if the pc is nil, the #> send will still happen -> MNU. >>> >>> Off the top of my head it would seem that it should be isDead or: [] not isDead not and: >>> >>> isTerminated >>> self isActiveProcess ifTrue: [^ false]. >>> ^suspendedContext isNil >>> or: ["If the suspendedContext is the bottomContext it is the block in Process>>newProcess. >>> If so, and the pc is greater than the startpc, the bock has alrteady sent and returned >>> from value and there is nothing more to do.â >>> suspendedContext isBottomContext >>> and: [ suspendedContext isDead >>> or: [ suspendedContext pc > suspendedContext startpc ] ] ] >> >> Phew. Glad you see that the same way. >> >>> isDead >>> ^ pc isNil >>> >>> and maybe (suspendedContext pc ifNil: [true] ifNotNil: [:pc| pc > suspendedContext startpc]) is more obvious. >>> >>> Anyway, neither implementation will reliably tell me if the process has been terminated: >>> - an inactive process will be suspended when #terminate is sent and report that it has not been terminated (#isSuspended -> true, #isTerminated -> false) >>> >>> except that it *hasn't* been terminated, it is merely in the process of termination. It isn't terminated until all unwind blocks have run, right? >> >> True. Easy to forget when you can just kill -9 on the consoleâ¦ :) >> >>> >>> - a properly terminated process will raise an MNU (although apparently not alwaysâ¦?) >>> >>> but that's a bug the change I suggested will fix. >>> >>> - all the states in between: no clue >>> >>> I would like to know two things: >>> 1. how can I check if a process has already *received* a #terminate? (I would then assume that the process will die eventually) >>> >>> I don't think you can without putting a critical section around terminate and adding some process-specific variable that is set when you send terminate. termination is not instantaneous (unwind blocks have to be run), so it is potentially interruptible. >> >> Iâve thought about this a bit. I wouldnât really care if I donât get a correct answer about the termination status immediately but I want to have it before the process terminates. In case of something like the following: >> >> ([ 10 seconds asDelay wait ] forkAt: 11) terminate >> >> it can (potentially) take a very long time for the process to terminate. So if I have to poll 3 or 4 times thatâs ok but I donât want to wait for minutes. >> One solution would be to take your idea of the variable, but without the critical block: >> >> terminate >> "Stop the process that the receiver represents forever. Unwind to execute pending ensure:/ifCurtailed: blocks before terminating." >> >> | ctxt unwindBlock oldList | >> terminating := true. â<âââââââââââââââââââââââââââââââââââ changed" >> self isActiveProcess >> ifTrue: [ >> ctxt := thisContext. >> [ ctxt := ctxt findNextUnwindContextUpTo: nil. >> ctxt isNil ] whileFalse: >> [ (ctxt tempAt: 2) ifNil: >> [ ctxt tempAt: 2 put: nil. >> unwindBlock := ctxt tempAt: 1. >> thisContext terminateTo: ctxt. >> unwindBlock value ]]. >> thisContext terminateTo: nil. >> self suspend ] >> ifFalse: [ >> "Always suspend the process first so it doesn't accidentally get woken up" >> oldList := self suspend. >> suspendedContext ifNotNil:[ >> "Figure out if we are terminating the process while waiting in Semaphore>>critical: >> In this case, pop the suspendedContext so that we leave the ensure: block inside >> Semaphore>>critical: without signaling the semaphore." >> (oldList class == Semaphore and:[ >> suspendedContext method == (Semaphore compiledMethodAt: #critical:)]) ifTrue:[ >> suspendedContext := suspendedContext home.]. >> >> "If we are terminating a process halfways through an unwind, try to complete that unwind block first." >> (suspendedContext findNextUnwindContextUpTo: nil) ifNotNil: [ :outer | >> (suspendedContext findContextSuchThat: [ :c | c closure == (outer tempAt: 1)]) >> ifNotNil: [ :inner | >> "This is an unwind block currently under evaluation" >> suspendedContext runUntilErrorOrReturnFrom: inner ]]. >> ctxt := self popTo: suspendedContext bottomContext. >> ctxt == suspendedContext bottomContext ifFalse: [ >> self debug: ctxt title: 'Unwind error during termination']] ]. >> >> >> >> isTerminating >> ^ terminating ifNil: [ ^ false ] >> >> >> With this small modification I can run the example from above and immediately see that it will die eventually. >> >> Iâm aware that one process might not see the change to the variable immediately but as I said, I wouldnât really care. >> >> >> What do you think? >> >> Yes that looks good. But given that branches are atomic (ifTrue: is not a send) why not do >> >> Process>>initialize >> terminating := false. >> >> terminate >> "Stop the process that the receiver represents forever. Unwind to execute pending ensure:/ifCurtailed: blocks before terminating." >> >> | ctxt unwindBlock oldList | >> terminating >> ifTrue: [self error: 'Process is already terminated, or being terminated'] >> ifFalse: [terminating := true]. >> self isActiveProcess >> ifTrue: >> ... >> >> ? >> >> I would suggest a status inst var, as in >> >> Process>>initialize >> status := nil >> >> terminate >> "Stop the process that the receiver represents forever. Unwind to execute pending ensure:/ifCurtailed: blocks before terminating." >> >> | ctxt unwindBlock oldList | >> status == #terminating >> ifTrue: [self error: 'Process is already terminated, or being terminated'] >> ifFalse: [status := terminating]. >> self isActiveProcess >> ifTrue: >> ... >> >> but the temptation then is to have lots of different status values and I'm leery of introducing that kind of complication without a strong justification. > > > Iâve worked a bit on an implementation along your suggestions. I wrote a test which looks like this: > > testIsTerminated > | proc | > proc := [ Semaphore new wait ] forkAt: 30. > self deny: proc isSuspended. > self deny: proc isTerminating. > self deny: proc isTerminated. > > proc terminate. > self deny: proc isTerminated. > self assert: proc isSuspended. > self assert: proc isTerminating. > > [ proc isTerminated ] whileFalse: [ 1 second asDelay wait ]. â<âââââââââââ ???" > > self assert: proc isTerminated. > self assert: proc isTerminating > > The test works AFAICT (apart from the loopâ¦) but I want to also have a check after the process has terminated. Is there some reliable way to wait for a process to die? I tried something like this for example: > > proc run. > self assert: proc isTerminated. > > But that locks up the active process (obviously) until I interrupt it manually. If there is such a way, I could also add a method that lets a process x wait for the completion of a process y for example (or not, depending on how difficult it is :) ) > > I can't see anything to do other than waiting. One thing is to run the process at as close to user priority as possible, so I would say > > proc := [ Semaphore new wait ] forkAt: Processor activePriority - 1. > > Another important thing is that you're not giving your process a chance to run before you test for it not terminating. So adding a yield after the first set of asserts and then repeating them is good: > > started := false. proc := [ started := true. Semaphore new wait ] forkAt: 30. > self deny: proc isSuspended. > self deny: proc isTerminating. > self deny: proc isTerminated. > > (Delay forMilliseconds: 10) wait. self assert: started. > self deny: proc isSuspended. > self deny: proc isTerminating. > self deny: proc isTerminated. > > > Another thing might be to boost its priority to make sure it finishes (except that that'll probably have no effect because IIRC right now the terminator runs the termination). So you could say > > proc terminate. > self deny: proc isTerminated. > self assert: proc isSuspended. > self assert: proc isTerminating. > > process priority: Processor activePriority + 1. > > [ proc isTerminated ] whileFalse: [ 1 second asDelay wait ]. > > Further I'd want to test that unwind blocks have been run so I'd say > > testIsTerminated > | proc started unwound terminator | > unwound := false. proc := [ started := true. [Semaphore new wait] > ensure: [terminator := Processor activeProcess. > unwound := true] ] > forkAt: Processor activePriority - 1. > self deny: proc isSuspended. > self deny: proc isTerminating. > self deny: proc isTerminated. > > (Delay forMilliseconds: 10) wait. "Alloc proc to run; there shouldnt be too much else going on so this delay should suffice" > > self assert: started. > self deny: proc isSuspended. > self deny: proc isTerminating. > self deny: proc isTerminated. > > proc terminate. > proc priority: Processor activePriority + 1. "This may have no effect; termination may be executed by the terminator rather than the terminatee; ys, this is a bug" > self deny: proc isTerminated. > self assert: proc isSuspended. > self assert: proc isTerminating. > > (Delay forMilliseconds: 10) wait. "Allow proc to terminate; there shouldnt be too much else going on so this delay should suffice" > > self assert: proc isTerminated. > self assert: proc isTerminating. > self assert: unwound. > self assert: terminator == proc. "But this should be made an expected failure; I don't know how to do that in SUnitâ¦" >From your comments I expected this last statement to fail but actually it doesnât. I guess thatâs a good sign (?). > > and google's mail text editor *SUCKS*!!!! lol :p I noticed something else regarding terminated processes that have never run and Iâm not sure if thatâs not a bug: When I suspend a process (that has never run) that is not the active process, I can reliably reproduce that the entire #terminate method is being executed. The processâ suspendedContext is the bottom context (as it should be). However, the pc is equal to the startpc, since that process never had a chance to to anything. The result is that #isTerminated will answer false, even though the process is technically terminated. One side effect of this is that itâs impossible to do something like â[ proc isTerminated ] whileFalse: [ 1 second asDelay wait ].â because that will not terminate for all processes. Luckily those processes can be garbage collected regardless of what #isTerminated says. One obvious fix would be to set the pc of the suspendedContext to nil but Iâm not sure thatâs a good idea. What do you think? Cheers, Max > > Cheers, > Max >> Cheers, >> Max >>> 2. how can I check if a process is *actually* dead? (in case a âhalf deadâ process will still unwind or whatever) >>> >>> see above. >>> >>> What would be necessary to make those tests (or better ones) possible (rewrite the whole process implementation?)? >>> >>> Cheers, >>> Max >>> -- >>> best, >>> Eliot >> -- >> best, >> Eliot > -- > best, > Eliot

Sept. 22, 2014

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

by Serge Stinckwich

ok thank you. Works now. On Mon, Sep 22, 2014 at 12:05 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > > On Mon, Sep 22, 2014 at 11:42 AM, Serge Stinckwich > <serge.stinckwich(a)gmail.com> wrote: >> >> 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 ? > > > Have you tried in in the latest Moose image? I committed earlier a fix. > You need the latest version of this package Glamour-Morphic-Renderer > (Glamour-Morphic-Renderer-AndreiChis.269) > > > > Andrei > > >> >> >> Regards, >> -- >> Serge Stinckwich >> UCBN & UMI UMMISCO 209 (IRD/UPMC) >> Every DSL ends up being Smalltalk >> http://www.doesnotunderstand.org/ >> > -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Sept. 22, 2014

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

by Andrei Chis

On Mon, Sep 22, 2014 at 11:42 AM, Serge Stinckwich < serge.stinckwich(a)gmail.com> wrote: > 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 ? > Have you tried in in the latest Moose image? I committed earlier a fix. You need the latest version of this package Glamour-Morphic-Renderer (Glamour-Morphic-Renderer-AndreiChis.269) Andrei > > 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 Esteban Lorenzano

On 22 Sep 2014, at 11:21, Ben Coman <btc(a)openInWorld.com> wrote: > Max Leske 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've never had a problem with that, and I don't think anything special was ever done to my account. btw, You do need to click the <Resolve> button to get those choices. > cheers -ben yes, there are no special configsâ¦ you probably are not pressing âresolveâ :) Esteban

Sept. 22, 2014