Here it is, in attachment, there actually are some GUI related exceptions captured. Troubles started an hour or so ago. Thanks for your time and best regards Janko S, Gary Chambers piše:

Your PharoDebug.log may have some clues...

Regards, Gary

----- Original Message ----- From: "Janko Mivšek" <janko.mivsek@eranova.si> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, August 08, 2011 6:04 PM Subject: [Pharo-project] GUI failing apart

...

Hi guys,

Strange things start happening to my 1.3 image. When edited some method it suddenly became covered with red, yellow crossed. Now other windows also have trouble to recreate when they come in focus. Not to mention many other such problems I cannot even describe. I somehow still manage to work with this image but with such trouble all the time.

Is there a way to recover this image from such troubles?

Best regards Janko

-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

-- Janko Mivšek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565

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 Nicolas 2011/8/8 Gary Chambers <gazzaguru2@btinternet.com>:

Looks like you may have changed one of the following methods:

CharacterBlockScanner buildCharacterBlockIn: {private} CharacterBlockScanner characterBlockAtPoint:index:in: {scanning} NewParagraph defaultCharacterBlock {selection}

since getting a CharacterBlockScanner back instead of a CharacterBlock in MultiNewParagraph>>buildSelectionBlocksFrom:to:

Regards, Gary

----- Original Message ----- From: "Janko Mivšek" <janko.mivsek@eranova.si> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, August 08, 2011 6:29 PM Subject: Re: [Pharo-project] GUI failing apart

...

Here it is, in attachment, there actually are some GUI related exceptions captured. Troubles started an hour or so ago.

Thanks for your time and best regards Janko

S, Gary Chambers piše:

...

Your PharoDebug.log may have some clues...

Regards, Gary

----- Original Message ----- From: "Janko Mivšek" <janko.mivsek@eranova.si> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, August 08, 2011 6:04 PM Subject: [Pharo-project] GUI failing apart

...

Hi guys,

Strange things start happening to my 1.3 image. When edited some method it suddenly became covered with red, yellow crossed. Now other windows also have trouble to recreate when they come in focus. Not to mention many other such problems I cannot even describe. I somehow still manage to work with this image but with such trouble all the time.

Is there a way to recover this image from such troubles?

Best regards Janko

-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

-- Janko Mivšek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel:  01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565

2011/8/8 Nicolas Cellier <nicolas.cellier.aka.nice@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. -- Best regards, Igor Stasenko AKA sig.

2011/8/8 Igor Stasenko <siguctua@gmail.com>:

2011/8/8 Nicolas Cellier <nicolas.cellier.aka.nice@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.

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.

2011/8/8 Stéphane Ducasse <stephane.ducasse@inria.fr>:

...

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.

Oh, If your goal is to remain popular, then indeeed, you should keep away from changing such parts of the system which are not shining ;). The obvious reason is that multilayer hacks with obfuscated contracts are not maintanable... so it's inevitable to create bugs in the transition and harvest complaints... Of course, if your goal is to make the system more simple and maintanable, I'm with you (and I know it is). But don't forget to extract the positive part of complaints that will help you making the system better. Personnally, the finite state machine logic in Squeak/MouseOverHandler is well beyond my understanding. So I could not clean it easily myself, A cosmetic cleaning was attempted in Pharo.I have nothing against that. I just pointed a problem in current cleaning, so it just have to be finished. The stincky ivar mutation already was in Squeak. I just said that it should raise an alarm in coder's eyes in the future and I hope this helps. Otherwise I can also shut up. The second approach suggested by Igor is more involving, consist in a full rewrite, probably with these stages: - gather description of the features to be supported, - an inventory of third party interested in this kind of features, - and from there, decline a new definition of contracts.

...

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

Sure, I don't want to restrain goodwill. But as a user of the service I don't see all the sweat the hardworkers put into the system, I just see a regression that makes my life harder (I simply cannot track the messages with the new windows). And obviously, comparing the length of old menu with new one, two third does not seem exagerated to me. But maybe you don't work with those tools and install OB/RB after each update... Nicolas

...

Nicolas

...

-- Best regards, Igor Stasenko AKA sig.

...

Oh, If your goal is to remain popular, then indeeed, you should keep away from changing such parts of the system which are not shining ;). The obvious reason is that multilayer hacks with obfuscated contracts are not maintanable... so it's inevitable to create bugs in the transition and harvest complaints...

Of course, if your goal is to make the system more simple and maintanable, I'm with you (and I know it is).

Yes and this is excellent :)

But don't forget to extract the positive part of complaints that will help you making the system better.

Personnally, the finite state machine logic in Squeak/MouseOverHandler is well beyond my understanding.

:) me too but we will learn it. I started to read the code of the event handler last year and regularly I take notes and slowly I understand better.

So I could not clean it easily myself,

A cosmetic cleaning was attempted in Pharo.I have nothing against that. I just pointed a problem in current cleaning, so it just have to be finished. The stincky ivar mutation already was in Squeak. I just said that it should raise an alarm in coder's eyes in the future and I hope this helps.

Yes of course. My remark was not on that part of your message :) So can you open a bug entry so that we do not forget to change it.

Otherwise I can also shut up.

The second approach suggested by Igor is more involving, consist in a full rewrite, probably with these stages: - gather description of the features to be supported, - an inventory of third party interested in this kind of features, - and from there, decline a new definition of contracts.

Yes we will attack from all angles and slowly but steadily do it. For example, there is in a image a check to reduce event but this is not clear that the VM generate them. so we will check that first.

...

...

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

Sure, I don't want to restrain goodwill. But as a user of the service I don't see all the sweat the hardworkers put into the system, I just see a regression that makes my life harder (I simply cannot track the messages with the new windows).

Explain us. Because we want the tools to be excellent.

And obviously, comparing the length of old menu with new one, two third does not seem exagerated to me. But maybe you don't work with those tools and install OB/RB after each update...

No I always use the core image with no tool loaded. What was on the menu? What is useful? I never use the menus?

Nicolas

...

...

Nicolas

...

-- Best regards, Igor Stasenko AKA sig.