Hello, earlier this day I posted a mail with a list of bugs that I think should be fixed before we close 3.7. For one of these bugs, no fix has been proposed so far.
I am therefore really happy to offer a problem analysis and a fix for the bug that is registered under BFAV archive ID 14350, posted at Nov 26, 2003. For quite a time, I was only able to hack around a problem that I did not understand, but now I think I have found was goes wrong. Here is the bug description again: ( from the cited bug report)
In an MVC project, open a file list and select a text file. Place the cursor into the text view (at the beginning of the text) and scroll down with the down arrow. When you reach the end of the text, you will get a notifier with the message as soon as you release the 'arrow down' key:
MessageNotUnderstood: UndefinedObject>>first
This comes from ParagraphEditor>>sameColumn:newLine:forward:,
And here is an analysis of the bug:
In method
ParagraphEditor>>sameColumn: start newLine: lineBlock forward: isForward
we read:
targetLineNumber _ ((lineBlock value: currentLineNumber) max: 1) min: lines size.
where lines is a temporary variable of the method. Under some circumstances, the method fetches the lines from the paragraph that is edited. (The paragraph is an instance of Paragraph in MVC and an instance of NewParagraph in Morphic) Under different circumstances, sameColumn:lineBlock:forward: computes an array of lines (this is done by ParagraphEditor>>lines).
In NewParagraph, 'lines' is used under an exact fit policy: For a paragraph that is composed to be displayed in n lines, the size of the array is n .
In a Paragraph, 'lines' is an array of TextLineIntervals. In Paragraph, the array 'lines' is used under a "keep additional space" policy and the correct number of lines is stored in instance variable 'lastLine' and can be accessed with the method Paragraph>>numberOfLines
When sameColumn:lineBlock:forward: computes an array of lines, it can use 'lines size' to obtain the number of lines, but when it uses the lines from the paragraph, it has to use 'paragraph numberOfLines' to obtain the number of lines.
Solution:
To handle both cases, I use an additional instance variable to keep the number of lines.
I would be glad to see this fix in the final 3.7 (if that is still possible), so can some fellow with an interest in MVC please review my proposal?
Thank you a lot! Boris
Hi Boris and all!
I am a bit swamped privately right now - but I really think your work here should not go unnoticed. I especially liked your summary that you posted. I will see if I can lend a hand, unfortunately my next few days look very booked.
But as long as good FIXes are around and people are engaged in working with them I don't really see why we shouldn't go through them before declaring victory. Sure, we can't do it forever - but hey, we can do whatever we like - so postponing a little bit in order to do some reviewing/harvesting and get some solid FIXes in is good IMHO. It is not like we have some manager jumpingup and down screaming for a release. :)
regards, Göran
goran.krampe@bluefish.se wrote:
Hi Boris and all!
I am a bit swamped privately right now - but I really think your work here should not go unnoticed. I especially liked your summary that you posted. I will see if I can lend a hand, unfortunately my next few days look very booked.
But as long as good FIXes are around and people are engaged in working with them I don't really see why we shouldn't go through them before declaring victory. Sure, we can't do it forever - but hey, we can do whatever we like - so postponing a little bit in order to do some reviewing/harvesting and get some solid FIXes in is good IMHO. It is not like we have some manager jumpingup and down screaming for a release. :)
True enough. :) By the way, according to our current schedule, we will move to gamma in two weeks, on May 14th. If there are still important fixes being made at that time, we could postpone a bit longer, maybe a week or two. (With Ned's and Boris' recent fix posts, it looks like we should be able to fix most of the problems on Boris' list before then.)
I don't want to get in the mode of postponing indefinitely, though, unless there's a huge problem which needs to be fixed. Also, we do want to open the 3.8alpha stream sometime soon so that the 3.8/4.0 work can begin in earnest...
- Doug
Doug Way dway@mailcan.com wrote:
True enough. :) By the way, according to our current schedule, we will move to gamma in two weeks, on May 14th. If there are still important fixes being made at that time, we could postpone a bit longer, maybe a week or two. (With Ned's and Boris' recent fix posts, it looks like we should be able to fix most of the problems on Boris' list before then.)
I don't want to get in the mode of postponing indefinitely, though, unless there's a huge problem which needs to be fixed. Also, we do want to open the 3.8alpha stream sometime soon so that the 3.8/4.0 work can begin in earnest...
I'd quite like to see 3.7 buttoned up Real Soon Now so a clean release can be included in the Foundation Risc User CD magazine issue I'm doing a small article for.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim No one is listening until you make a mistake.
Dear Smalltalkers,
I'll give at SmalltalkSolutions 2004 a short presentation of a set of open source classes I developed wich help me on moving between Smalltalk Dialect. (Dialect portability, May 3, 2.45 PM)
The classes are available for VW, Dolphin, VSE and I have an old version for VA somewhere. There is also some documentation! (if you can survive my english:-) )
The work try to give support on fields like -a minimum of user interaction (showing dialog asking confirm, Yes/no, etc) -interface with the compiler -file system intraction -etc
these items, for what I know, are currently non included on the major interoperability projects currently open, like Rosetta, XIF, ANSI Compatibility.
I'm interested on finding help on improving the work both in supporting more dialect and on supporting more functionality.
Anyone interested please contact me at SS or send me e-mail.
I can mantain and evolve the VW and VSE stuff, and the Dolphin too if necessary, but I would like to have friends helping on squeak, VA, MT, /X, ObjectStudio, etch.
Having more portability could only improve to make our language more usable and used. And, please, no war on wich dialect is better; choose the one you like, but choose Smalltalk!
giorgio ferraris
mail at giorgioxxferrarisxx@yyelevensoft.xxit (please remove all xx and yy before sending).
Fixes the specified scrolling problem in MVC.
There is a little bit of risk with this, since Morphic uses this method too. But the fix itself looks reasonable.
- Doug
On Thursday, April 29, 2004, at 08:10 AM, Boris Gaertner wrote:
Hello, earlier this day I posted a mail with a list of bugs that I think should be fixed before we close 3.7. For one of these bugs, no fix has been proposed so far.
I am therefore really happy to offer a problem analysis and a fix for the bug that is registered under BFAV archive ID 14350, posted at Nov 26, 2003. For quite a time, I was only able to hack around a problem that I did not understand, but now I think I have found was goes wrong. Here is the bug description again: ( from the cited bug report)
In an MVC project, open a file list and select a text file. Place the cursor into the text view (at the beginning of the text) and scroll down with the down arrow. When you reach the end of the text, you will get a notifier with the message as soon as you release the 'arrow down' key:
MessageNotUnderstood: UndefinedObject>>first
This comes from ParagraphEditor>>sameColumn:newLine:forward:,
And here is an analysis of the bug:
In method
ParagraphEditor>>sameColumn: start newLine: lineBlock forward: isForward
we read:
targetLineNumber _ ((lineBlock value: currentLineNumber) max: 1) min: lines size.
where lines is a temporary variable of the method. Under some circumstances, the method fetches the lines from the paragraph that is edited. (The paragraph is an instance of Paragraph in MVC and an instance of NewParagraph in Morphic) Under different circumstances, sameColumn:lineBlock:forward: computes an array of lines (this is done by ParagraphEditor>>lines).
In NewParagraph, 'lines' is used under an exact fit policy: For a paragraph that is composed to be displayed in n lines, the size of the array is n .
In a Paragraph, 'lines' is an array of TextLineIntervals. In Paragraph, the array 'lines' is used under a "keep additional space" policy and the correct number of lines is stored in instance variable 'lastLine' and can be accessed with the method Paragraph>>numberOfLines
When sameColumn:lineBlock:forward: computes an array of lines, it can use 'lines size' to obtain the number of lines, but when it uses the lines from the paragraph, it has to use 'paragraph numberOfLines' to obtain the number of lines.
Solution:
To handle both cases, I use an additional instance variable to keep the number of lines.
I would be glad to see this fix in the final 3.7 (if that is still possible), so can some fellow with an interest in MVC please review my proposal?
Thank you a lot! Boris<MVCCursorDownFix.1.cs>
squeak-dev@lists.squeakfoundation.org