August 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] PharoCore 1.3: Transcript Ctrl+S broken

by Mariano Martinez Peck

Lukas, which version are you using? I am in Pharo1.3 Latest update: #13293 and I cannot reproduce it On Mon, Aug 8, 2011 at 10:22 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Thanks we will add that in the bug tracker later. > > The debugger got shaked because of my idea to change for a better > implementation. Sorry about that. > > Stef > > On Aug 8, 2011, at 9:56 PM, Lukas Renggli wrote: > > > Another problem I just noticed right now is that pressing Ctrl+S in > > the Transcript opens a debugger: > > > > SubscriptOutOfBounds: 0 > > > > Ctrl+S used to clear the transcript, what I found quite useful in the > past. > > > > Again, I am reporting this here to not forget, because the bug tracker > > is currently in read-only mode. > > > > Lukas > > > > -- > > Lukas Renggli > > www.lukas-renggli.ch > > > > > -- Mariano http://marianopeck.wordpress.com

Aug. 8, 2011

Re: [Pharo-project] Recursive calls hang image

by Igor Stasenko

Another thing, which i think we should try is to put interrupt handler ahead of event sensor handler (because it should take priority above anything else), so InputEventFetcher default eventHandlers should read: an OrderedCollection(an UserInterruptHandler an InputEventSensor ) but not > an OrderedCollection(an InputEventSensor an UserInterruptHandler) On 8 August 2011 22:42, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 8 August 2011 22:17, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> Igor Stasenko wrote: >>> >>> the problem is that you cannot interrupt >>> it, by pressing Alt-. (or Cmd-. on macs)? >>> >> >> Right, smart ass ;-) > > Well, it works for me, if i press it multiple times :) > > InputEventFetcher default eventHandlers > > an OrderedCollection(an InputEventSensor an UserInterruptHandler) > > So, all logic whether interrupt the process or not, is in #handleUserInterrupt > > i think we should change it: > > Â Â Â Â Â Â Â Â Â Â Â Â toInterrupt := Processor preemptedProcess. > Â Â Â Â Â Â Â Â Â Â Â Â "Only interrupt processes which are potentially blocking the UI" > Â Â Â Â Â Â Â Â Â Â Â Â toInterrupt priority < Â UIManager default uiProcess priority > ifTrue: [toInterrupt := Project uiProcess]. > > Â Â Â Â Â Â Â Â Â Â Â Â "Fork at lower priority to avoid interrupting system-critical processes" > Â Â Â Â Â Â Â Â Â Â Â Â toInterrupt debugWithTitle: 'User Interrupt'] > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â forkAt: Processor activeProcess priority -1 > > the #preemptedProcess is not works, because it actually tries to > guess, which process was preempted, instead of knowing it exactly. > > What i think we should do is to extend the UserInterruptHandler to > > Â a) have a registry of system-critical processes , which should never > be interrupted: this is Delay, Event fetcher, interrupt handler, > Â weak finalizer, idle process > All those facilities should register themselves in > UserInterruptHandler whenever they deciding to start or restart their > process. > > > Â b) interrupt the first process, not found in (a), going from higher > priority to lower. > Then if you press the cmd-. multiple times, you will be able to > interrupt anything which is not system-critical. > > Because there is no reliable way to detect a processor hog process, > unless you running CPU watcher and gather statistics on CPU > consumption rates. > Stopping a process which was running just before current one is like > shooting in the clear sky in hope that duck will teleport right on the > path of your bullet :) > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Aug. 8, 2011

Re: [Pharo-project] Recursive calls hang image

by Igor Stasenko

On 8 August 2011 22:17, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Igor Stasenko wrote: >> >> the problem is that you cannot interrupt >> it, by pressing Alt-. (or Cmd-. on macs)? >> > > Right, smart ass ;-) Well, it works for me, if i press it multiple times :) InputEventFetcher default eventHandlers an OrderedCollection(an InputEventSensor an UserInterruptHandler) So, all logic whether interrupt the process or not, is in #handleUserInterrupt i think we should change it: toInterrupt := Processor preemptedProcess. "Only interrupt processes which are potentially blocking the UI" toInterrupt priority < UIManager default uiProcess priority ifTrue: [toInterrupt := Project uiProcess]. "Fork at lower priority to avoid interrupting system-critical processes" toInterrupt debugWithTitle: 'User Interrupt'] forkAt: Processor activeProcess priority -1 the #preemptedProcess is not works, because it actually tries to guess, which process was preempted, instead of knowing it exactly. What i think we should do is to extend the UserInterruptHandler to a) have a registry of system-critical processes , which should never be interrupted: this is Delay, Event fetcher, interrupt handler, weak finalizer, idle process All those facilities should register themselves in UserInterruptHandler whenever they deciding to start or restart their process. b) interrupt the first process, not found in (a), going from higher priority to lower. Then if you press the cmd-. multiple times, you will be able to interrupt anything which is not system-critical. Because there is no reliable way to detect a processor hog process, unless you running CPU watcher and gather statistics on CPU consumption rates. Stopping a process which was running just before current one is like shooting in the clear sky in hope that duck will teleport right on the path of your bullet :) -- Best regards, Igor Stasenko AKA sig.

Aug. 8, 2011

Re: [Pharo-project] GUI failing apart

by Nicolas Cellier

2011/8/8 Igor Stasenko <siguctua(a)gmail.com>: > 2011/8/8 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> I also noted this: (Array does notUnderstand: #nextPut:) and it comes from: >> >> MouseOverHandler>>handleAsMouseEnter: anEvent >> Â Â Â Â | asMouseEnterEvent | >> Â Â Â Â asMouseEnterEvent := anEvent asMouseEnter. >> Â Â Â Â enteredMorphs := enteredMorphs contents. >> Â Â Â Â enteredMorphs reverseDo: [ :anEnteredMorph | >> Â Â Â Â Â Â Â Â self inform: asMouseEnterEvent to: anEnteredMorph originatedFrom: >> anEvent ifNotFocusedDo: [] ] >> >> enteredMorphs is changing indead from WriteStream -> Array. >> IMHO mutating an inst var is very bad behaved >> This should be corrected ASAP >> > > This class is really confusing.. > According to its use (see senders to #mouseOverHandler) > it actually handling more than just mouse over events. > I would say it should be named MouseEventHander :) > > But still , its hard to say, why it is so complex.. and what its purpose. > Yeah, Squeak version of this class was worse, even the comments are cryptic like : enteredMorphs ifNil: [ "inform: was called in handleEvent:" ^self initializeTrackedMorphs ]. Squeak already broke the enteredMorph ivar, but reset it at the end of the method with a self initializeTrackedMorphs OK, some clean up was required, but you see, you can make things worse when cleaning... It's like Pharo cleaning removed the antidote, but forgot to remove the poison... Now, of course, instead of a local polishing, it would be possible to rewrite all. But please, don't do it blindly and loose 2 third of features like the new implementors window :( Nicolas > -- > Best regards, > Igor Stasenko AKA sig. > >

Aug. 8, 2011

[Pharo-project] exciting master topics with us :)

by StÃ©phane Ducasse

Hi guys if you are interested we have a nice list of ideas for license and master topics. Let us know. We will publish them soon. Fuel was one of them and we are writing a really excellent paper on it and we will use it in Pharo for real :). Stef

Aug. 8, 2011

Re: [Pharo-project] PharoCore 1.3: Transcript Ctrl+S broken

by StÃ©phane Ducasse

Thanks we will add that in the bug tracker later. The debugger got shaked because of my idea to change for a better implementation. Sorry about that. Stef On Aug 8, 2011, at 9:56 PM, Lukas Renggli wrote: > Another problem I just noticed right now is that pressing Ctrl+S in > the Transcript opens a debugger: > > SubscriptOutOfBounds: 0 > > Ctrl+S used to clear the transcript, what I found quite useful in the past. > > Again, I am reporting this here to not forget, because the bug tracker > is currently in read-only mode. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

Aug. 8, 2011

Re: [Pharo-project] Recursive calls hang image

by Sean P. DeNigris

Igor Stasenko wrote: > > the problem is that you cannot interrupt > it, by pressing Alt-. (or Cmd-. on macs)? > Right, smart ass ;-) -- View this message in context: http://forum.world.st/Recursive-calls-hang-image-tp3728055p3728159.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 8, 2011

Re: [Pharo-project] Summary with UUID not so unique.

by Igor Stasenko

On 8 August 2011 20:29, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Mon, Aug 8, 2011 at 1:13 AM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: >> >> Hi guys. Can someone do a summary of the problem of UUID not so unique? >> because I have been bitten again. >> In my image, primMakeUUID is still calling the primitive: >> >> primMakeUUID >> Â Â Â <primitive: 'primitiveMakeUUID' module: 'UUIDPlugin'> >> Â Â Â UUIDGenerator default generateBytes: self forVersion: 4. >> >> By my VM is still broken with this aspect. So....how should we deal with >> it? > > Update your VM. +1 and run UUID tests which actually has test case which detecting this problem. > >> >> a) Change/Commmit/IntegrateÂ Â this: >> >> primMakeUUID >> Â Â Â UUIDGenerator default generateBytes: self forVersion: 4. >> >> b) there are new Cog VMs somewhere that I can use with this problem fixed? > > Yes. Â See Â http://www.mirandabanda.org/files/Cog/VM/VM.r2485/ or one of those: https://ci.lille.inria.fr/pharo/view/Cog/ :) -- Best regards, Igor Stasenko AKA sig.

Aug. 8, 2011

Re: [Pharo-project] Recursive calls hang image

by Igor Stasenko

Hangs? Well it is normal, since it is busy evaluating an infinite recursion, right? :) So, as far as i understand the problem is that you cannot interrupt it, by pressing Alt-. (or Cmd-. on macs)? Because there's little what could be done with code which goes into recursion, actually only one thing - fix it. :) On 8 August 2011 21:47, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > My image hung after executing: > Â categoryName := $- asParser negate plus flatten, ($- asParser, #any > asParser star flatten) optional star. > Â categoryName parse: 'SuperMe'. > > On the Moose list [1], Lukas pointed out the bug in my code which led to > direct recursion, and that hanging under this circumstance was a bug in > Pharo. Is this a known bug, or shall I file an issue? > > [1] http://forum.world.st/PetitParser-crash-td3725129.html > > -- > View this message in context: http://forum.world.st/Recursive-calls-hang-image-tp3728055p3728055.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Best regards, Igor Stasenko AKA sig.

Aug. 8, 2011

Re: [Pharo-project] PharoCore 1.3: Implementors browser broken

by StÃ©phane Ducasse

Thanks > I just noticed that the implementors browser in Pharo Core 1.3 does > not show any kind of warning if a variable is not declared. I know that I fixed a bug in 1.4 when executing a comment. > Also parse errors result in the fatal SyntaxError window. Yes I want kill that one too. Marcus told me that he has fun with petitparser and made a lot of progress for the decompiler. So opal is getting closer and closer... I should continue to work on Rpackage argh. > > I thought I report it here before I forget it again, because the bug > tracker is in read-only mode right now. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

Aug. 8, 2011