GUI failing apart

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

GUI failing apart

Janko Mivšek
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

Reply | Threaded
Open this post in threaded view
|

Re: GUI failing apart

Gary Chambers-4
Your PharoDebug.log may have some clues...

Regards, Gary

----- Original Message -----
From: "Janko Mivšek" <[hidden email]>
To: <[hidden email]>
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
>


Reply | Threaded
Open this post in threaded view
|

Re: GUI failing apart

Janko Mivšek
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" <[hidden email]>
> To: <[hidden email]>
> 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

PharoDebug.log.zip (241K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GUI failing apart

Gary Chambers-4
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" <[hidden email]>
To: <[hidden email]>
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"
>> <[hidden email]>
>> To: <[hidden email]>
>> 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
>


Reply | Threaded
Open this post in threaded view
|

Re: GUI failing apart

Nicolas Cellier
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 <[hidden email]>:

> 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" <[hidden email]>
> To: <[hidden email]>
> 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"
>>> <[hidden email]>
>>> To: <[hidden email]>
>>> 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
>>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: GUI failing apart

Nicolas Cellier
2011/8/8 Nicolas Cellier <[hidden email]>:

> 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.

s/indead/indeed/

> IMHO mutating an inst var is very bad behaved
> This should be corrected ASAP
>
> Nicolas
>
> 2011/8/8 Gary Chambers <[hidden email]>:
>> 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" <[hidden email]>
>> To: <[hidden email]>
>> 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"
>>>> <[hidden email]>
>>>> To: <[hidden email]>
>>>> 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
>>>
>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: GUI failing apart

Igor Stasenko
In reply to this post by Nicolas Cellier
2011/8/8 Nicolas Cellier <[hidden email]>:

> 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.

Reply | Threaded
Open this post in threaded view
|

Re: GUI failing apart

Stéphane Ducasse
In reply to this post by Nicolas Cellier
I'm confused. Is there a bug in pharo, or janko loaded a strange package?

Stef

On Aug 8, 2011, at 9:16 PM, Nicolas Cellier wrote:

> 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 <[hidden email]>:
>> 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" <[hidden email]>
>> To: <[hidden email]>
>> 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"
>>>> <[hidden email]>
>>>> To: <[hidden email]>
>>>> 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
>>>
>>
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: GUI failing apart

Stéphane Ducasse
In reply to this post by Igor Stasenko
you mean that this method could be nicer :)
We will continue to work on the rewrite of the events. It just takes time.

handleEvent: anEvent
        | evt ofs |
        owner ifNil:[^self].
        evt := anEvent.

        EventStats ifNil:[EventStats := IdentityDictionary new].
        EventStats at: #count put: (EventStats at: #count ifAbsent:[0]) + 1.
        EventStats at: evt type put: (EventStats at: evt type ifAbsent:[0]) + 1.

        evt isMouseOver ifTrue:[^self sendMouseEvent: evt].

ShowEvents == true ifTrue:[
        Display fill: (0@0 extent: 250@120) rule: Form over fillColor: Color white.
        ofs := (owner hands indexOf: self) - 1 * 60.
        evt printString displayAt: (0@ofs) + (evt isKeyboard ifTrue:[0@30] ifFalse:[0@0]).
        self keyboardFocus printString displayAt: (0@ofs)+(0@45).
].
        "Notify listeners"
        self sendListenEvent: evt to: self eventListeners.

        evt isWindowEvent ifTrue: [
                self sendEvent: evt focus: nil.
                ^self mouseOverHandler processMouseOver: lastMouseEvent].
       

        evt isKeyboard ifTrue:[
                self sendListenEvent: evt to: self keyboardListeners.
                self sendKeyboardEvent: evt.
                ^self mouseOverHandler processMouseOver: lastMouseEvent].

        evt isDropEvent ifTrue:[
                self sendEvent: evt focus: nil.
                ^self mouseOverHandler processMouseOver: lastMouseEvent].

        evt isMouse ifTrue:[
                self sendListenEvent: evt to: self mouseListeners.
                lastMouseEvent := evt].

        "Check for pending drag or double click operations."
        mouseClickState ifNotNil:[
                (mouseClickState handleEvent: evt from: self) ifFalse:[
                        "Possibly dispatched #click: or something and will not re-establish otherwise"
                        ^self mouseOverHandler processMouseOver: lastMouseEvent]].

        evt isMove ifTrue:[
                self position: evt position.
                self sendMouseEvent: evt.
        ] ifFalse:[
                "Issue a synthetic move event if we're not at the position of the event"
                (evt position = self position) ifFalse:[self moveToEvent: evt].
                "Drop submorphs on button events"
                (self hasSubmorphs)
                        ifTrue:[self dropMorphs: evt]
                        ifFalse:[self sendMouseEvent: evt].
        ].
        ShowEvents == true ifTrue:[self mouseFocus printString displayAt: (0@ofs) + (0@15)].
        self mouseOverHandler processMouseOver: lastMouseEvent.







On Aug 8, 2011, at 9:44 PM, Igor Stasenko wrote:

> 2011/8/8 Nicolas Cellier <[hidden email]>:
>> 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.
>


Reply | Threaded
Open this post in threaded view
|

Re: GUI failing apart

Nicolas Cellier
In reply to this post by Igor Stasenko
2011/8/8 Igor Stasenko <[hidden email]>:

> 2011/8/8 Nicolas Cellier <[hidden email]>:
>> 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.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: GUI failing apart

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.
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: GUI failing apart

Benjamin Van Ryseghem (Pharo)

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.
>>>
>>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: GUI failing apart

Igor Stasenko
One thing about UI is that nobody dares to enter this area.
Because its scares the shit out of most of people, once they take a
look at code and realizing how much things they need to learn about it
to at least do not do any harm, not saying about making a small
improvement.
Because you can easily get lost in this maze of code (especially when
some code paths lead to limbo/nowhere).

So, if you take the above into account, it says more than enough about
Benjamin :)


--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: GUI failing apart

Nicolas Cellier
In reply to this post by Stéphane Ducasse
2011/8/8 Stéphane Ducasse <[hidden email]>:

>>
>>
>> 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.
>>>
>>>
>>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: GUI failing apart

Igor Stasenko
On 9 August 2011 13:43, Nicolas Cellier
<[hidden email]> wrote:

> 2011/8/8 Stéphane Ducasse <[hidden email]>:
>>>
>>>
>>> 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, it would help if you mention what exactly you missing instead of 2/3 :)

--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: GUI failing apart

Stéphane Ducasse
In reply to this post by Nicolas Cellier
>>
>>
>
> 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.
>>>>
>>>>
>>>
>>
>>
>>
>