- Pharo-dev - lists.pharo.org

Re: [Pharo-project] GUI failing apart

by Benjamin

On Aug 8, 2011, at 11:27 PM, StÃ©phane Ducasse wrote: >> >> >> OK, some clean up was required, but you see, you can make things worse >> when cleaning... > > Yes but in average this is really not the case. > >> It's like Pharo cleaning removed the antidote, but forgot to remove >> the poison... > > Ok that kinds of things happens in ugly, undocumented, obsolete systems. > >> Now, of course, instead of a local polishing, it would be possible to >> rewrite all. > > I'm starting to write tests for the events. Now since you are at it, I guess that you read this wonderful code > full of hypothesis and other subtle strange behavior. So I'm quite sure that they will be problems. > But we will fix them. Else we should stop now and do Javascript because at least we will look cool. > >> But please, don't do it blindly and loose 2 third of features like the >> new implementors window :( > > We are not doing things blindly: > > First it costs us money, time and we should all the lucky that Ben was really good and enjoy rewriting us boring UI > without a decent widgets set (because he fixed them also the multiselection and others). > Benjamin I publicly thank you for all the good stuff you did!!!! Thanks you very much ;) > > > Second, what are these 2 thirds that we lost? Because two third is a lot. I'm dreaming to throw away two third of the stringHolder hierarCrap > Please hightlight me. > > Sorry but I do not like this kind of statements because there are false and because we work hard to bring to life > a system full of shit. Shit that was accumulated and of course stable because it did not move since years. > In addition if everytime a guy spend 4 months to build a new tools we all complain (without constructive points to help him fixing that) > better say to students that they are idiots and that we do not need their help. But in that case be ready to be with the same ugly system > in the future. And we do not accept that. So there will be some glitches but we are stronger than them and we will fix them. > > Nicolas I'm quite sure that you would not say that around a beer to benjamin because I know you so pay attention because > Ben is also one of the coolest students we got recently and we really liked his spirit and atttitude. Jumping in StringHolder and broken/duplicated widgets > is not easy, nor it is to work on bootstrapping Pharo. > > Stef About implementors we have decided, Stef and I, that at some points, things have to move to be better. I know and I assume not to be a perfect coder nor a Smalltalk expert, but at least, I think that when I am directed in the good direction I can do some good stuffs. Moreover we are fully aware that we are providing tools for a large community which do not want to be disturbed in its work, but we strongly believe in our community, and I think (and I guess Stef too) that we are all smart enough to understand that we will go further all together. To come back to Implementors, I could complain and say that the code was a mess, with no tests to cover expected behaviors, but the point is that I really want to move on. So I have done my best, I am proud it was integrated, and at the same time, I am a bit sad that some users are not fully convinced by this new version (and I know how boring it could be to loose a useful behavior). I have experimented this version for weeks before it was integrating but as every one knows, I am still a newby here, and probably I do not used to use all the behaviors of the old Implementors. The problem is that we can't ask each Pharoer if the new version is good enough to be integrated. At some point, we have to integrate stuff, get a lot of feedbacks, fix the tools, and improve the system. It's not a perfect system, there is a chaotic state, but we are a community. It's the best way we have found to get people involved, but it's clearly not perfect. And here, it seems that we have missed a step. Where is your feedback ? Ok it's the first step to say that some crucial things are missing (and I apologize for that) but if we want things to be better, I please you to open clear and detailed bugs entries, like that I could (or someone else) fix this tool. As far as I know, when I see a bug entry about one of my tools, I try to fix it asap :) So my answer is a bit long, but I hope it will be clear :) Ben > > >> >> Nicolas >> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> >> > >

Aug. 8, 2011

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

by StÃ©phane Ducasse

Indeed it works also in 14078 I would prefer to have Action-C (for clear) than S because I could have never guess it (since it makes me think about save). Stef On Aug 8, 2011, at 10:45 PM, Mariano Martinez Peck wrote: > 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 StÃ©phane Ducasse

igor I like the idea. It provides a solution not depending on the scheduler strategy. We should implement it :) Stef On Aug 8, 2011, at 10:42 PM, Igor Stasenko 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. >

Aug. 8, 2011

Re: [Pharo-project] GUI failing apart

by StÃ©phane Ducasse

> > > OK, some clean up was required, but you see, you can make things worse > when cleaning... Yes but in average this is really not the case. > It's like Pharo cleaning removed the antidote, but forgot to remove > the poison... Ok that kinds of things happens in ugly, undocumented, obsolete systems. > Now, of course, instead of a local polishing, it would be possible to > rewrite all. I'm starting to write tests for the events. Now since you are at it, I guess that you read this wonderful code full of hypothesis and other subtle strange behavior. So I'm quite sure that they will be problems. But we will fix them. Else we should stop now and do Javascript because at least we will look cool. > But please, don't do it blindly and loose 2 third of features like the > new implementors window :( We are not doing things blindly: First it costs us money, time and we should all the lucky that Ben was really good and enjoy rewriting us boring UI without a decent widgets set (because he fixed them also the multiselection and others). Benjamin I publicly thank you for all the good stuff you did!!!! Second, what are these 2 thirds that we lost? Because two third is a lot. I'm dreaming to throw away two third of the stringHolder hierarCrap Please hightlight me. Sorry but I do not like this kind of statements because there are false and because we work hard to bring to life a system full of shit. Shit that was accumulated and of course stable because it did not move since years. In addition if everytime a guy spend 4 months to build a new tools we all complain (without constructive points to help him fixing that) better say to students that they are idiots and that we do not need their help. But in that case be ready to be with the same ugly system in the future. And we do not accept that. So there will be some glitches but we are stronger than them and we will fix them. Nicolas I'm quite sure that you would not say that around a beer to benjamin because I know you so pay attention because Ben is also one of the coolest students we got recently and we really liked his spirit and atttitude. Jumping in StringHolder and broken/duplicated widgets is not easy, nor it is to work on bootstrapping Pharo. Stef > > Nicolas > >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> >

Aug. 8, 2011

Re: [Pharo-project] [Vm-dev] Cog VMMaker.oscog-eem.114/r2485

by Igor Stasenko

On 8 August 2011 07:55, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi All, > Â Â please find new VMs in http://www.mirandabanda.org/files/Cog/VM/VM.r2485/. Â These fix a couple of long-standing bugs. Â One is a rare crash in GC on copying a compiled method, caused by the VM not making sure that a copy of a method that has been compiled to machine code is an independent copy. Â The other is a potential bug in GC with become where a become causes some machine code methods to gain references to young objects but the VM forgets to include these methods in the young referrers (those machine code methods that refer to young objects). Yes, and i think this would be a first version(s) of Cog VMs, which could be titled as 'stable'. Because the bug, which Eliot fixed are really vicious and were plagued us for more than half of year. (i preparing an update on jenkins build server, we will see how well it goes after the fix). Because now we having a test jobs on jenkins which running tests for newly built VMs (but i will write more details in separate post). -- Best regards, Igor Stasenko AKA sig.

Aug. 8, 2011

Re: [Pharo-project] [Vm-dev] Re: Cog VMMaker.oscog-eem.114/r2485

by Igor Stasenko

On 8 August 2011 22:49, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi All, > Â Â and nowÂ http://www.mirandabanda.org/files/Cog/VM/VM.r2486Â includes Igor's rule 41 code in the BitBltPlugin, and includes a real multi-threaded linux VM. Â The one in r2485 is only single-threaded due to a regression in a build script. Correction: rule 41 code in the BitBltPlugin is not mine. :) I just took an effort to integrate already existing work made by other(s). I had to change the methods in order to replace _ with := for assignments and also use annotations <..foo.. > instead of 'self foo:..' that's why those methods stamped by my name. But i didn't changed any semantics, just made sure it works. > > On Sun, Aug 7, 2011 at 10:55 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> Hi All, >> Â Â please find new VMs in http://www.mirandabanda.org/files/Cog/VM/VM.r2485/. Â These fix a couple of long-standing bugs. Â One is a rare crash in GC on copying a compiled method, caused by the VM not making sure that a copy of a method that has been compiled to machine code is an independent copy. Â The other is a potential bug in GC with become where a become causes some machine code methods to gain references to young objects but the VM forgets to include these methods in the young referrers (those machine code methods that refer to young objects). >> -- >> best, >> Eliot > > > > -- > best, > Eliot > > -- Best regards, Igor Stasenko AKA sig.

Aug. 8, 2011

Re: [Pharo-project] Cog VMMaker.oscog-eem.114/r2485

by Eliot Miranda

Hi All, and now http://www.mirandabanda.org/files/Cog/VM/VM.r2486 includes Igor's rule 41 code in the BitBltPlugin, and includes a real multi-threaded linux VM. The one in r2485 is only single-threaded due to a regression in a build script. On Sun, Aug 7, 2011 at 10:55 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > Hi All, > > please find new VMs in > http://www.mirandabanda.org/files/Cog/VM/VM.r2485/. These fix a couple of > long-standing bugs. One is a rare crash in GC on copying a compiled method, > caused by the VM not making sure that a copy of a method that has been > compiled to machine code is an independent copy. The other is a potential > bug in GC with become where a become causes some machine code methods to > gain references to young objects but the VM forgets to include these methods > in the young referrers (those machine code methods that refer to young > objects). > -- > best, > Eliot > > -- best, Eliot

Aug. 8, 2011

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