Some bugs

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

Some bugs

Andrea Brühlmann-2
Hello,

I reported some bugs on the issue tracker and hope you can help me with them!


4681: Accepting with the enter key does not work
        http://code.google.com/p/pharo/issues/detail?id=4681

4682: Code completion makes strange cursor placements and too many spaces
        http://code.google.com/p/pharo/issues/detail?id=4682

4683: Code completion breaks some search fields (errors during typing)
        http://code.google.com/p/pharo/issues/detail?id=4683

4684: Missing ctrl+w (methodNamesContainingIt:)
        http://code.google.com/p/pharo/issues/detail?id=4684

4685: Merge dialog: cannot resolve conflict with removed method
        http://code.google.com/p/pharo/issues/detail?id=4685

4686: Method category change creates no new version
        http://code.google.com/p/pharo/issues/detail?id=4686

4687: Errors during coding (MessageNotUnderstood: receiver of "morph" is nil)
        http://code.google.com/p/pharo/issues/detail?id=4687

4688: Progress bar disappears on image save
        http://code.google.com/p/pharo/issues/detail?id=4688

4689: MessageTally bug
        http://code.google.com/p/pharo/issues/detail?id=4689

4690: Progress bar position
        http://code.google.com/p/pharo/issues/detail?id=4690

4691: Bad line breaks in code until window is resized (because of bold text?)
        http://code.google.com/p/pharo/issues/detail?id=4691

4692: Drop downs should select the default entry (topmost) instead of a middle one
        http://code.google.com/p/pharo/issues/detail?id=4692

4693: Line breaks in tooltips are wrong
        http://code.google.com/p/pharo/issues/detail?id=4693

4694: Debugger: stepping over an error can not open a new debugger until I hit cmd+.
        http://code.google.com/p/pharo/issues/detail?id=4694

4695: Time asString prints nanos unrounded
        http://code.google.com/p/pharo/issues/detail?id=4695


--
Andrea Brühlmann

Reply | Threaded
Open this post in threaded view
|

Re: Some bugs

Lukas Renggli
Wow, this is a very good collection.

In the same vein there are similar bugs that slow down my development:

4514: Resumable assertions and expected failures do not work together
       http://code.google.com/p/pharo/issues/detail?id=4514

4609: Syntax highlighting broken
       http://code.google.com/p/pharo/issues/detail?id=4609

4611: Implementors browser broken
       http://code.google.com/p/pharo/issues/detail?id=4611

4615: Text selection makes colors disappear
       http://code.google.com/p/pharo/issues/detail?id=4615

4642: FinderUI>>compileSource: aString notifying: aController
       http://code.google.com/p/pharo/issues/detail?id=4642

4643: Inspector>>fieldListMenu: aMenu
       http://code.google.com/p/pharo/issues/detail?id=4643

2404: Monticello and Subclasses of ProtoObject
       http://code.google.com/p/pharo/issues/detail?id=2404

2194: MCSnapshotBrowser and Traits
       http://code.google.com/p/pharo/issues/detail?id=2194

Now I think the subliminal message of this thread is that the Pharo
community should focus on making the existing images really stable
before hacking away on Pharo 1.4 and beyond ... :-)

Lukas

On 23 August 2011 09:54, Andrea Brühlmann <[hidden email]> wrote:

> Hello,
>
> I reported some bugs on the issue tracker and hope you can help me with
> them!
>
>
> 4681: Accepting with the enter key does not work
>        http://code.google.com/p/pharo/issues/detail?id=4681
>
> 4682: Code completion makes strange cursor placements and too many spaces
>        http://code.google.com/p/pharo/issues/detail?id=4682
>
> 4683: Code completion breaks some search fields (errors during typing)
>        http://code.google.com/p/pharo/issues/detail?id=4683
>
> 4684: Missing ctrl+w (methodNamesContainingIt:)
>        http://code.google.com/p/pharo/issues/detail?id=4684
>
> 4685: Merge dialog: cannot resolve conflict with removed method
>        http://code.google.com/p/pharo/issues/detail?id=4685
>
> 4686: Method category change creates no new version
>        http://code.google.com/p/pharo/issues/detail?id=4686
>
> 4687: Errors during coding (MessageNotUnderstood: receiver of "morph" is
> nil)
>        http://code.google.com/p/pharo/issues/detail?id=4687
>
> 4688: Progress bar disappears on image save
>        http://code.google.com/p/pharo/issues/detail?id=4688
>
> 4689: MessageTally bug
>        http://code.google.com/p/pharo/issues/detail?id=4689
>
> 4690: Progress bar position
>        http://code.google.com/p/pharo/issues/detail?id=4690
>
> 4691: Bad line breaks in code until window is resized (because of bold
> text?)
>        http://code.google.com/p/pharo/issues/detail?id=4691
>
> 4692: Drop downs should select the default entry (topmost) instead of a
> middle one
>        http://code.google.com/p/pharo/issues/detail?id=4692
>
> 4693: Line breaks in tooltips are wrong
>        http://code.google.com/p/pharo/issues/detail?id=4693
>
> 4694: Debugger: stepping over an error can not open a new debugger until I
> hit cmd+.
>        http://code.google.com/p/pharo/issues/detail?id=4694
>
> 4695: Time asString prints nanos unrounded
>        http://code.google.com/p/pharo/issues/detail?id=4695
>
>
> --
> Andrea Brühlmann
>
>



--
Lukas Renggli
www.lukas-renggli.ch

Reply | Threaded
Open this post in threaded view
|

Re: Some bugs

Marcus Denker-4
In reply to this post by Andrea Brühlmann-2

On Aug 23, 2011, at 9:23 AM, Lukas Renggli wrote:

>
>
> Now I think the subliminal message of this thread is that the Pharo
> community should focus on making the existing images really stable
> before hacking away on Pharo 1.4 and beyond ... :-)
>

And we need more people actually looking at the bug tracker... I sometimes
feel a bit lonely...

    Marcus

--
Marcus Denker -- http://marcusdenker.de


Reply | Threaded
Open this post in threaded view
|

Re: Some bugs

Luc Fabresse

Thanks for the reporting!
And yes, we should all help fixing these bugs entries.

Luc

2011/8/23 Marcus Denker <[hidden email]>

On Aug 23, 2011, at 9:23 AM, Lukas Renggli wrote:

>
>
> Now I think the subliminal message of this thread is that the Pharo
> community should focus on making the existing images really stable
> before hacking away on Pharo 1.4 and beyond ... :-)
>

And we need more people actually looking at the bug tracker... I sometimes
feel a bit lonely...

   Marcus

--
Marcus Denker -- http://marcusdenker.de



Reply | Threaded
Open this post in threaded view
|

Re: Some bugs

abergel
In reply to this post by Andrea Brühlmann-2
These issues are for 1.2.2. Who is maintaining it by the way?

Pharo 1.4 presents a significant number of improvements over Pharo 1.3. Whereas I found Pharo 1.3 almost unusable, I am quite happy with 1.4

Cheers,
Alexandre


On 23 Aug 2011, at 08:54, Andrea Brühlmann wrote:

> Hello,
>
> I reported some bugs on the issue tracker and hope you can help me with them!
>
>
> 4681: Accepting with the enter key does not work
> http://code.google.com/p/pharo/issues/detail?id=4681
>
> 4682: Code completion makes strange cursor placements and too many spaces
> http://code.google.com/p/pharo/issues/detail?id=4682
>
> 4683: Code completion breaks some search fields (errors during typing)
> http://code.google.com/p/pharo/issues/detail?id=4683
>
> 4684: Missing ctrl+w (methodNamesContainingIt:)
> http://code.google.com/p/pharo/issues/detail?id=4684
>
> 4685: Merge dialog: cannot resolve conflict with removed method
> http://code.google.com/p/pharo/issues/detail?id=4685
>
> 4686: Method category change creates no new version
> http://code.google.com/p/pharo/issues/detail?id=4686
>
> 4687: Errors during coding (MessageNotUnderstood: receiver of "morph" is nil)
> http://code.google.com/p/pharo/issues/detail?id=4687
>
> 4688: Progress bar disappears on image save
> http://code.google.com/p/pharo/issues/detail?id=4688
>
> 4689: MessageTally bug
> http://code.google.com/p/pharo/issues/detail?id=4689
>
> 4690: Progress bar position
> http://code.google.com/p/pharo/issues/detail?id=4690
>
> 4691: Bad line breaks in code until window is resized (because of bold text?)
> http://code.google.com/p/pharo/issues/detail?id=4691
>
> 4692: Drop downs should select the default entry (topmost) instead of a middle one
> http://code.google.com/p/pharo/issues/detail?id=4692
>
> 4693: Line breaks in tooltips are wrong
> http://code.google.com/p/pharo/issues/detail?id=4693
>
> 4694: Debugger: stepping over an error can not open a new debugger until I hit cmd+.
> http://code.google.com/p/pharo/issues/detail?id=4694
>
> 4695: Time asString prints nanos unrounded
> http://code.google.com/p/pharo/issues/detail?id=4695
>
>
> --
> Andrea Brühlmann
>

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






Reply | Threaded
Open this post in threaded view
|

Re: Some bugs

Lukas Renggli
In reply to this post by Marcus Denker-4
>> Now I think the subliminal message of this thread is that the Pharo
>> community should focus on making the existing images really stable
>> before hacking away on Pharo 1.4 and beyond ... :-)
>
> And we need more people actually looking at the bug tracker... I sometimes
> feel a bit lonely...

Yes, I feel guilty of not being able to contribute more fixes. You are
doing the excellent job of integrating submitted patches
instantaneous.

The problem is that the unstable versions are pushed extremely hard,
while the supposedly stable versions are still unstable. I don't see
how this can possibly work?

Subsequently, I hesitate to submit a patch for an old version because
I know it won't be possible to merge it into newer versions. This is a
vicious circle.

Lukas

--
Lukas Renggli
www.lukas-renggli.ch

Reply | Threaded
Open this post in threaded view
|

Re: Some bugs

Marcus Denker-4
In reply to this post by Andrea Brühlmann-2

On Aug 23, 2011, at 9:54 AM, Alexandre Bergel wrote:

> These issues are for 1.2.2. Who is maintaining it by the way?

We maintain the current released image. But when people provide easy to integrate, clear and useful
bug fixes for older versions, we integrate them.

(this was done for 1.1.2, it has all fixes that where added for 1.2.2)

Of course it would be possible (and I would prefer it), if a group of 1.2 users could take that
over (e.g. commercial users that are actually using 1.2)

The idea would not to actively develope it, but just make sure that all the fixes are added that
make sense (bug fixes, mostly). *And* make that driven and coordingated by actual users of
that version. This way we make sure that a release gets important fixes as long as it is used.

We could have such a group for just every version released: It gets "handed off" to the people
using the release. This group than of course, with time, gets smaller, and in the end fades
away.

The most important effect of this would be to not burn people maintaining old versions they
don't use themselves...

        Marcus


--
Marcus Denker -- http://marcusdenker.de


Reply | Threaded
Open this post in threaded view
|

Re: Some bugs

Adrian Lienhard
In reply to this post by abergel
Yes, the issues Andrea reported are all from 1.2.2. That's the version we are currently using besides 1.1.2.

Unfortunately, its not an option for us to move to new versions of Pharo too frequently. New Pharo versions can have unforeseen effects in production and hence can cause a lot of work for us and pain for our users (just an example is the semantic change of String>>asNumber).

On the other hand, we are working 8 hours a day with Pharo and hence a good IDE is very important. If things like the debugger do not reliably work, this is not fun.

Are other people just living with the issues? Are there any patches that could be backported?

Cheers,
Adrian

On Aug 23, 2011, at 10:54 , Alexandre Bergel wrote:

> These issues are for 1.2.2. Who is maintaining it by the way?
>
> Pharo 1.4 presents a significant number of improvements over Pharo 1.3. Whereas I found Pharo 1.3 almost unusable, I am quite happy with 1.4
>
> Cheers,
> Alexandre
>
>
> On 23 Aug 2011, at 08:54, Andrea Brühlmann wrote:
>
>> Hello,
>>
>> I reported some bugs on the issue tracker and hope you can help me with them!
>>
>>
>> 4681: Accepting with the enter key does not work
>> http://code.google.com/p/pharo/issues/detail?id=4681
>>
>> 4682: Code completion makes strange cursor placements and too many spaces
>> http://code.google.com/p/pharo/issues/detail?id=4682
>>
>> 4683: Code completion breaks some search fields (errors during typing)
>> http://code.google.com/p/pharo/issues/detail?id=4683
>>
>> 4684: Missing ctrl+w (methodNamesContainingIt:)
>> http://code.google.com/p/pharo/issues/detail?id=4684
>>
>> 4685: Merge dialog: cannot resolve conflict with removed method
>> http://code.google.com/p/pharo/issues/detail?id=4685
>>
>> 4686: Method category change creates no new version
>> http://code.google.com/p/pharo/issues/detail?id=4686
>>
>> 4687: Errors during coding (MessageNotUnderstood: receiver of "morph" is nil)
>> http://code.google.com/p/pharo/issues/detail?id=4687
>>
>> 4688: Progress bar disappears on image save
>> http://code.google.com/p/pharo/issues/detail?id=4688
>>
>> 4689: MessageTally bug
>> http://code.google.com/p/pharo/issues/detail?id=4689
>>
>> 4690: Progress bar position
>> http://code.google.com/p/pharo/issues/detail?id=4690
>>
>> 4691: Bad line breaks in code until window is resized (because of bold text?)
>> http://code.google.com/p/pharo/issues/detail?id=4691
>>
>> 4692: Drop downs should select the default entry (topmost) instead of a middle one
>> http://code.google.com/p/pharo/issues/detail?id=4692
>>
>> 4693: Line breaks in tooltips are wrong
>> http://code.google.com/p/pharo/issues/detail?id=4693
>>
>> 4694: Debugger: stepping over an error can not open a new debugger until I hit cmd+.
>> http://code.google.com/p/pharo/issues/detail?id=4694
>>
>> 4695: Time asString prints nanos unrounded
>> http://code.google.com/p/pharo/issues/detail?id=4695
>>
>>
>> --
>> Andrea Brühlmann
>>
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Some bugs

Michael Roberts-2
I think for the debugger, we all live with the bugs. I mean, we (I)
unfortunately made the situation worse with the introduction of the
closures around 1.0/1.1 and it has never been fixed. It is hard to fix
too, this stuff is not simple.  I contacted a few people quietly maybe
a year ago to see if we all lived with it, because a few times i
posted about the debugger and there was not a lot of response.  I
wondered if no one *actually* programmed in pharo. but no, we become
masters of interpreting the debugger highlight...

What can we do-
1) I have contacted Eliot (again). Historically he said it was fixed
(or better) in teleplace images but I need him to send us any patches.
He has also been helpful and highlighted the areas that need work like
the decompiler and how we could write some tests to protect against
unintended change

2) I have checked a recent Squeak, and it is bust there too.

3) I am writing some test cases. So that we can regression test the
debugger highlighting, and building an analyser class (@esug) to make
it easier to dig into the debugger.

4) carefully check Squeak class versions for merging changes into
Pharo. this is not easy.

5) We have to rebuild the debugger model based on the new compiler /
decompiler machinery. (This is a long term Pharo goal)

I am just chipping away at the analysis, and i will share my code when
i have something on the tracker.

Also would be great in a separate thread if someone could explain to
me the simulation guard primitive. i.e you can not step over process
creation, but you can halt after it e.g.

cheers,
Mike

Reply | Threaded
Open this post in threaded view
|

Re: Some bugs

Adrian Lienhard
Mike,

Thanks for the initiative and the update on this issue!

I hope other people have insights or can lend a helping hand...

Adrian

On Aug 23, 2011, at 14:25 , Michael Roberts wrote:

> I think for the debugger, we all live with the bugs. I mean, we (I)
> unfortunately made the situation worse with the introduction of the
> closures around 1.0/1.1 and it has never been fixed. It is hard to fix
> too, this stuff is not simple.  I contacted a few people quietly maybe
> a year ago to see if we all lived with it, because a few times i
> posted about the debugger and there was not a lot of response.  I
> wondered if no one *actually* programmed in pharo. but no, we become
> masters of interpreting the debugger highlight...
>
> What can we do-
> 1) I have contacted Eliot (again). Historically he said it was fixed
> (or better) in teleplace images but I need him to send us any patches.
> He has also been helpful and highlighted the areas that need work like
> the decompiler and how we could write some tests to protect against
> unintended change
>
> 2) I have checked a recent Squeak, and it is bust there too.
>
> 3) I am writing some test cases. So that we can regression test the
> debugger highlighting, and building an analyser class (@esug) to make
> it easier to dig into the debugger.
>
> 4) carefully check Squeak class versions for merging changes into
> Pharo. this is not easy.
>
> 5) We have to rebuild the debugger model based on the new compiler /
> decompiler machinery. (This is a long term Pharo goal)
>
> I am just chipping away at the analysis, and i will share my code when
> i have something on the tracker.
>
> Also would be great in a separate thread if someone could explain to
> me the simulation guard primitive. i.e you can not step over process
> creation, but you can halt after it e.g.
>
> cheers,
> Mike
>


Reply | Threaded
Open this post in threaded view
|

Re: Some bugs

Stéphane Ducasse
In reply to this post by Marcus Denker-4
+1

On Aug 23, 2011, at 10:42 AM, Marcus Denker wrote:

>
> On Aug 23, 2011, at 9:54 AM, Alexandre Bergel wrote:
>
>> These issues are for 1.2.2. Who is maintaining it by the way?
>
> We maintain the current released image. But when people provide easy to integrate, clear and useful
> bug fixes for older versions, we integrate them.
>
> (this was done for 1.1.2, it has all fixes that where added for 1.2.2)
>
> Of course it would be possible (and I would prefer it), if a group of 1.2 users could take that
> over (e.g. commercial users that are actually using 1.2)
>
> The idea would not to actively develope it, but just make sure that all the fixes are added that
> make sense (bug fixes, mostly). *And* make that driven and coordingated by actual users of
> that version. This way we make sure that a release gets important fixes as long as it is used.
>
> We could have such a group for just every version released: It gets "handed off" to the people
> using the release. This group than of course, with time, gets smaller, and in the end fades
> away.
>
> The most important effect of this would be to not burn people maintaining old versions they
> don't use themselves...
>
> Marcus
>
>
> --
> Marcus Denker -- http://marcusdenker.de
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Some bugs

Stéphane Ducasse
In reply to this post by Lukas Renggli
Don't feel guilty :)
But send fixes so that we can collect them for a given version.

And we will not get perfect systems. Imagine IBM payed during several year 100 engineers to build eclipse
and so far we got one engineer 8 months.

Stef


On Aug 23, 2011, at 9:57 AM, Lukas Renggli wrote:

>>> Now I think the subliminal message of this thread is that the Pharo
>>> community should focus on making the existing images really stable
>>> before hacking away on Pharo 1.4 and beyond ... :-)
>>
>> And we need more people actually looking at the bug tracker... I sometimes
>> feel a bit lonely...
>
> Yes, I feel guilty of not being able to contribute more fixes. You are
> doing the excellent job of integrating submitted patches
> instantaneous.
>
> The problem is that the unstable versions are pushed extremely hard,
> while the supposedly stable versions are still unstable. I don't see
> how this can possibly work?
>
> Subsequently, I hesitate to submit a patch for an old version because
> I know it won't be possible to merge it into newer versions. This is a
> vicious circle.
>
> Lukas
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>


Reply | Threaded
Open this post in threaded view
|

Re: Some bugs

Clara Allende
Imagine IBM paying engineers to maintain an smalltalk application during like 10 years, and I still find some really ugly bugs hehe

On 23 August 2011 14:12, Stéphane Ducasse <[hidden email]> wrote:
Don't feel guilty :)
But send fixes so that we can collect them for a given version.

And we will not get perfect systems. Imagine IBM payed during several year 100 engineers to build eclipse
and so far we got one engineer 8 months.

Stef


On Aug 23, 2011, at 9:57 AM, Lukas Renggli wrote:

>>> Now I think the subliminal message of this thread is that the Pharo
>>> community should focus on making the existing images really stable
>>> before hacking away on Pharo 1.4 and beyond ... :-)
>>
>> And we need more people actually looking at the bug tracker... I sometimes
>> feel a bit lonely...
>
> Yes, I feel guilty of not being able to contribute more fixes. You are
> doing the excellent job of integrating submitted patches
> instantaneous.
>
> The problem is that the unstable versions are pushed extremely hard,
> while the supposedly stable versions are still unstable. I don't see
> how this can possibly work?
>
> Subsequently, I hesitate to submit a patch for an old version because
> I know it won't be possible to merge it into newer versions. This is a
> vicious circle.
>
> Lukas
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>



Reply | Threaded
Open this post in threaded view
|

Re: Some bugs

Stéphane Ducasse
In reply to this post by Andrea Brühlmann-2
Thanks andrea

Welcome to the pharo mailing-list and community.

Now I think that this is important that inside netstyle you also consider that if pharo is important for you (which I imagine)
that you should also contribute. Bug reporting is already a contribution.  Pharo is an open-source software mainly supported by the free time of people, people that are often do not earning their money from their pharo work (I thank them for all that).
I also understand that people can get frustrated by changes but what can we do?

May be people can gather and check the fixes that are important to fix but we do not have the force to maintain.

Imagine well that we have one engineer full time since 8 months.

Stef


On Aug 23, 2011, at 8:54 AM, Andrea Brühlmann wrote:

> Hello,
>
> I reported some bugs on the issue tracker and hope you can help me with them!
>
>
> 4681: Accepting with the enter key does not work
> http://code.google.com/p/pharo/issues/detail?id=4681
>
> 4682: Code completion makes strange cursor placements and too many spaces
> http://code.google.com/p/pharo/issues/detail?id=4682
>
> 4683: Code completion breaks some search fields (errors during typing)
> http://code.google.com/p/pharo/issues/detail?id=4683
>
> 4684: Missing ctrl+w (methodNamesContainingIt:)
> http://code.google.com/p/pharo/issues/detail?id=4684
>
> 4685: Merge dialog: cannot resolve conflict with removed method
> http://code.google.com/p/pharo/issues/detail?id=4685
>
> 4686: Method category change creates no new version
> http://code.google.com/p/pharo/issues/detail?id=4686
>
> 4687: Errors during coding (MessageNotUnderstood: receiver of "morph" is nil)
> http://code.google.com/p/pharo/issues/detail?id=4687
>
> 4688: Progress bar disappears on image save
> http://code.google.com/p/pharo/issues/detail?id=4688
>
> 4689: MessageTally bug
> http://code.google.com/p/pharo/issues/detail?id=4689
>
> 4690: Progress bar position
> http://code.google.com/p/pharo/issues/detail?id=4690
>
> 4691: Bad line breaks in code until window is resized (because of bold text?)
> http://code.google.com/p/pharo/issues/detail?id=4691
>
> 4692: Drop downs should select the default entry (topmost) instead of a middle one
> http://code.google.com/p/pharo/issues/detail?id=4692
>
> 4693: Line breaks in tooltips are wrong
> http://code.google.com/p/pharo/issues/detail?id=4693
>
> 4694: Debugger: stepping over an error can not open a new debugger until I hit cmd+.
> http://code.google.com/p/pharo/issues/detail?id=4694
>
> 4695: Time asString prints nanos unrounded
> http://code.google.com/p/pharo/issues/detail?id=4695
>
>
> --
> Andrea Brühlmann
>


Reply | Threaded
Open this post in threaded view
|

Re: Some bugs

Nicolas Cellier
In reply to this post by Michael Roberts-2
Hi Michael, I did in recent past and can renew help with 4) which is
an immediate cheap solution compared to 5), but as you have seen in 2)
the solution is not universal.
On thing to remember with Decompiler, is that it sounds like a visitor
pattern, but some very important features are sometimes implemented on
the node side!
This does not help understanding the too much complicated code (simple
browsing is void, you often need debugging).

Nicolas

2011/8/23 Michael Roberts <[hidden email]>:

> I think for the debugger, we all live with the bugs. I mean, we (I)
> unfortunately made the situation worse with the introduction of the
> closures around 1.0/1.1 and it has never been fixed. It is hard to fix
> too, this stuff is not simple.  I contacted a few people quietly maybe
> a year ago to see if we all lived with it, because a few times i
> posted about the debugger and there was not a lot of response.  I
> wondered if no one *actually* programmed in pharo. but no, we become
> masters of interpreting the debugger highlight...
>
> What can we do-
> 1) I have contacted Eliot (again). Historically he said it was fixed
> (or better) in teleplace images but I need him to send us any patches.
> He has also been helpful and highlighted the areas that need work like
> the decompiler and how we could write some tests to protect against
> unintended change
>
> 2) I have checked a recent Squeak, and it is bust there too.
>
> 3) I am writing some test cases. So that we can regression test the
> debugger highlighting, and building an analyser class (@esug) to make
> it easier to dig into the debugger.
>
> 4) carefully check Squeak class versions for merging changes into
> Pharo. this is not easy.
>
> 5) We have to rebuild the debugger model based on the new compiler /
> decompiler machinery. (This is a long term Pharo goal)
>
> I am just chipping away at the analysis, and i will share my code when
> i have something on the tracker.
>
> Also would be great in a separate thread if someone could explain to
> me the simulation guard primitive. i.e you can not step over process
> creation, but you can halt after it e.g.
>
> cheers,
> Mike
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Some bugs

Stéphane Ducasse

On Aug 23, 2011, at 10:01 PM, Nicolas Cellier wrote:

> Hi Michael, I did in recent past and can renew help with 4) which is
> an immediate cheap solution compared to 5), but as you have seen in 2)
> the solution is not universal.

But Squeak has exactly the same problem that pharo to this respect
I tried in 43-11481









> On thing to remember with Decompiler, is that it sounds like a visitor
> pattern, but some very important features are sometimes implemented on
> the node side!
> This does not help understanding the too much complicated code (simple
> browsing is void, you often need debugging).
>
> Nicolas
>
> 2011/8/23 Michael Roberts <[hidden email]>:
>> I think for the debugger, we all live with the bugs. I mean, we (I)
>> unfortunately made the situation worse with the introduction of the
>> closures around 1.0/1.1 and it has never been fixed. It is hard to fix
>> too, this stuff is not simple.  I contacted a few people quietly maybe
>> a year ago to see if we all lived with it, because a few times i
>> posted about the debugger and there was not a lot of response.  I
>> wondered if no one *actually* programmed in pharo. but no, we become
>> masters of interpreting the debugger highlight...
>>
>> What can we do-
>> 1) I have contacted Eliot (again). Historically he said it was fixed
>> (or better) in teleplace images but I need him to send us any patches.
>> He has also been helpful and highlighted the areas that need work like
>> the decompiler and how we could write some tests to protect against
>> unintended change
>>
>> 2) I have checked a recent Squeak, and it is bust there too.
>>
>> 3) I am writing some test cases. So that we can regression test the
>> debugger highlighting, and building an analyser class (@esug) to make
>> it easier to dig into the debugger.
>>
>> 4) carefully check Squeak class versions for merging changes into
>> Pharo. this is not easy.


>>
>> 5) We have to rebuild the debugger model based on the new compiler /
>> decompiler machinery. (This is a long term Pharo goal)
>>
>> I am just chipping away at the analysis, and i will share my code when
>> i have something on the tracker.
>>
>> Also would be great in a separate thread if someone could explain to
>> me the simulation guard primitive. i.e you can not step over process
>> creation, but you can halt after it e.g.
>>
>> cheers,
>> Mike
>>
>>
>


Screen shot 2011-08-23 at 10.07.21 PM.pdf (52K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Some bugs

Nicolas Cellier
2011/8/23 Stéphane Ducasse <[hidden email]>:

>
> On Aug 23, 2011, at 10:01 PM, Nicolas Cellier wrote:
>
>> Hi Michael, I did in recent past and can renew help with 4) which is
>> an immediate cheap solution compared to 5), but as you have seen in 2)
>> the solution is not universal.
>
> But Squeak has exactly the same problem that pharo to this respect
> I tried in 43-11481
>

Yes, not universal just means that...

>
>
>
>
>
>> On thing to remember with Decompiler, is that it sounds like a visitor
>> pattern, but some very important features are sometimes implemented on
>> the node side!
>> This does not help understanding the too much complicated code (simple
>> browsing is void, you often need debugging).
>>
>> Nicolas
>>
>> 2011/8/23 Michael Roberts <[hidden email]>:
>>> I think for the debugger, we all live with the bugs. I mean, we (I)
>>> unfortunately made the situation worse with the introduction of the
>>> closures around 1.0/1.1 and it has never been fixed. It is hard to fix
>>> too, this stuff is not simple.  I contacted a few people quietly maybe
>>> a year ago to see if we all lived with it, because a few times i
>>> posted about the debugger and there was not a lot of response.  I
>>> wondered if no one *actually* programmed in pharo. but no, we become
>>> masters of interpreting the debugger highlight...
>>>
>>> What can we do-
>>> 1) I have contacted Eliot (again). Historically he said it was fixed
>>> (or better) in teleplace images but I need him to send us any patches.
>>> He has also been helpful and highlighted the areas that need work like
>>> the decompiler and how we could write some tests to protect against
>>> unintended change
>>>
>>> 2) I have checked a recent Squeak, and it is bust there too.
>>>
>>> 3) I am writing some test cases. So that we can regression test the
>>> debugger highlighting, and building an analyser class (@esug) to make
>>> it easier to dig into the debugger.
>>>
>>> 4) carefully check Squeak class versions for merging changes into
>>> Pharo. this is not easy.
>
>
>
>>>
>>> 5) We have to rebuild the debugger model based on the new compiler /
>>> decompiler machinery. (This is a long term Pharo goal)
>>>
>>> I am just chipping away at the analysis, and i will share my code when
>>> i have something on the tracker.
>>>
>>> Also would be great in a separate thread if someone could explain to
>>> me the simulation guard primitive. i.e you can not step over process
>>> creation, but you can halt after it e.g.
>>>
>>> cheers,
>>> Mike
>>>
>>>
>>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Some bugs

Michael Roberts-2
Nicolas thanks! super you have even a few minutes.

Even though Squeak has the problem, it is subtly different.  I will
post my little scaffolding class maybe the end of this week which just
helps to slowly step a debugger through. And do this in different
images.

What would be great, on a wiki page perhaps, is the list of important
classes that are involved in debugging. Then it makes it easier to
track changes (Debugger, InstructionStream and so on). It is also
somewhat educational, for me at least.

The other thing, which is more tricky, is to know what are the
highlights we want?  In VW i take it for granted it is correct, and
possibly in old Squeak images too.  Can we document this? Perhaps a
start could be png files of "correct" highlights? Then we can build a
test framework that asserts these intervals we can work out (1 to: 3)
(34 to: 45) etc for given simulations of #send and #doStep.  Any
thoughts on that appreciated. Perhaps this is not needed when we
finally figure out what is wrong.

Also as mentioned in the original bug list, there are other bugs with
the debugger not just highlighting. Just wanted to say I wasn't
ignoring those... ;-)

cheers,
Mike

Reply | Threaded
Open this post in threaded view
|

Re: Some bugs

Stéphane Ducasse

On Aug 24, 2011, at 9:09 AM, Michael Roberts wrote:

> Nicolas thanks! super you have even a few minutes.
>
> Even though Squeak has the problem, it is subtly different.  I will
> post my little scaffolding class maybe the end of this week which just
> helps to slowly step a debugger through. And do this in different
> images.

Ok I'm curious to know then.

> What would be great, on a wiki page perhaps, is the list of important
> classes that are involved in debugging. Then it makes it easier to
> track changes (Debugger, InstructionStream and so on). It is also
> somewhat educational, for me at least.
>
> The other thing, which is more tricky, is to know what are the
> highlights we want?  In VW i take it for granted it is correct, and
> possibly in old Squeak images too.  Can we document this? Perhaps a
> start could be png files of "correct" highlights? Then we can build a
> test framework that asserts these intervals we can work out (1 to: 3)
> (34 to: 45) etc for given simulations of #send and #doStep.  Any
> thoughts on that appreciated. Perhaps this is not needed when we
> finally figure out what is wrong.
>
> Also as mentioned in the original bug list, there are other bugs with
> the debugger not just highlighting. Just wanted to say I wasn't
> ignoring those... ;-)
>
> cheers,
> Mike
>


Reply | Threaded
Open this post in threaded view
|

Re: Some bugs

Michael Roberts-2

>
> Ok I'm curious to know then.

Here is a little trace from this example method:

toDoOutsideTemp
| temp collection |
collection := OrderedCollection new.
1 to: 5 do: [ :index |
temp := index.
collection add: [ temp ] ]

Trace is start,stop position of the highlight for each 'step over'.

Whilst the numbers are hard to visualise, below you can see how they slightly diverge.
Left Pharo  Right  Squeak

50, 73     71, 73       diff
71, 73     71, 73
50, 73     50, 73
108, 115   79, 121      diff
79, 121    79, 121
108, 115   108, 115
132, 144   132, 144
147, 146   146, 146     (diff negative size means no highlight)
146, 146   146, 146
79, 121    79, 121
108, 115   108, 115
132, 144   132, 144
147, 146   146, 146
146, 146   146, 146
79, 121    79, 121
108, 115   108, 115
132, 144   132, 144
147, 146   146, 146
146, 146   146, 146
79, 121    79, 121
108, 115   108, 115

etc...

For example the first difference is because Pharo shows the whole assignment of the first line as the first send, even though it is not.

The second difference is that Pharo shows the assignment inside the block as the first highlight of the loop even though the to:do should be highlighted....but both Pharo & Squeak get the to:do: wrong when they choose to show it.

hope you get the idea...

Mike 
123