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 |
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 |
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 |
Thanks for the reporting! And yes, we should all help fixing these bugs entries. Luc 2011/8/23 Marcus Denker <[hidden email]>
|
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
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 |
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 |
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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > |
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 |
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 > |
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 > > |
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 > |
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 :) |
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 > |
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 > > |
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 |
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 >>> >>> >> > > > |
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 |
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 > |
> > 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
|
Free forum by Nabble | Edit this page |