Thread: [Freemind-developer] 0.9.0 for testing
A premier mind-mapping software written in Java
Brought to you by:
christianfoltin,
danielpolansky
From: Christian F. (GMX) <chr...@gm...> - 2009-11-28 22:31:01
|
Hi, as there weren't reported any servere problems with 0.9.0RC6 after a month, I've placed the final version 0.9.0 for final testing in the directory: web.sourceforge.net:/home/groups/f/fr/freemind/htdocs/testversions/ (Currently, it is still under way). (How to access this directory from outside?) Please, have a short look at it and report any new things to me, if you can admit some time. Otherwise, I would release this in a reasonable time (a week or so). TIA, Chris |
From: Christian F. (GMX) <chr...@gm...> - 2010-11-06 22:02:07
|
Dear Dan, according to 16. Scripts do not work if file operations are not permitted[5] <http://sourceforge.net/tracker/index.php?func=detail&aid=2789907&group_id=7118&atid=107118> (/http://sourceforge.net/tracker/index.php?func=detail&aid=2789907&group_id=7118&atid=107118/) - no progress so far I tried it out with ="Hello", and it worked without file permissions. Could you try, please? TIA, Chris |
From: Dan P. <dan...@gm...> - 2010-11-08 14:12:14
|
Hello Chris, regarding 16. Scripts do not work if file operations are not permitted (http://sourceforge.net/tracker/index.php?func=detail&aid=2789907&group_id=7118&atid=107118): I have tried to run the script '="Hello"', and it gave me an exception, as described in the bug report. My testing environment: FreeMind 0.9.0 RC10, Java version "1.6.0_21", Windows Vista. The bug was originally reported by Dimitry, who I think also used some version of MS Windows. In the email "Scripts do not work if file operations are not permitted" from 11.5.2009, you yourself have written: "The problem is known, but AFAIK this is only valid for the first time a script is executed as the class files are then hold inside the cache, or the like." Thus, back then you must have been able to reproduce the bug, right? Could it have been that you have tested the issue on Windows rather than on Mac OS X, back then? In the same email thread from 11.5.2009, Dimitry has proposed some sort of fix for the bug. >From a web interface, the thread is available here: http://sourceforge.net/mailarchive/forum.php?thread_name=4A089EEB.1080207%40gmx.de&forum_name=freemind-developer Best regards, Dan On Sat, Nov 6, 2010 at 11:01 PM, Christian Foltin (GMX) <chr...@gm...> wrote: > Dear Dan, > > according to > > 16. Scripts do not work if file operations are not > permitted[5] (http://sourceforge.net/tracker/index.php?func=detail&aid=2789907&group_id=7118&atid=107118) > - no progress so far > > I tried it out with ="Hello", and it worked without file permissions. > > Could you try, please? > > TIA, Chris |
From: Dan P. <dan...@gm...> - 2010-11-08 14:52:47
Attachments:
Notes and encryption after conversion.mm
|
Hello Chris, as regards 18. "Conversion from 0.8.0 to 0.9.0 drops indentation in notes" and the proposed bug fix by adjusting the file "freemind_version_updater.xslt": I have downloaded the XSLT, placed it into freemind.jar, and tested the result. It seems to do what it should, with one exception. What is does correctly: It converts indentation in notes correctly, and it converts "a b" as "a b" instead of "a b", as it should. What is does erroneously: I have a test mind map "Notes and encryption after conversion", which it fails to load; it gives the exception "Error while parsing file:java.io.IOException: Stream closed" placed to a root node. I attach the test mind map "Notes and encryption after conversion" to this email. In 0.9.0 RC9, the test mind map gets opened without a failure, albeit with conversion mistakes such as missing newlines in notes. In 0.9.0 RC10 with the new XSLT, the mind map does not get opened at all. Best regards, Dan |
From: Christian F. (GMX) <chr...@gm...> - 2010-11-27 12:45:35
|
Dear Dan, recently, I published 0.9.0 RC11. IMHO, it solves every issue from http://freemind.sourceforge.net/wiki/index.php/Finishing_0.9.0 Regarding the problem you described: the stack size is too small to let the replacement function work properly (there are too many recursions, that can't be reduced inside XSLT due to the nature of this language). So, the map gets converted correctly, if you start the .bat (this includes -Xss8M) or on a Mac. Otherwise, it is now opened without conversion, but with a loss of data and an error message in the status bar. Can you integrate the stack option into the freemind.c? TIA, Chris Am 08.11.10 15:52, schrieb Dan Polansky: > Hello Chris, > > as regards 18. "Conversion from 0.8.0 to 0.9.0 drops indentation in > notes" and the proposed bug fix by adjusting the file > "freemind_version_updater.xslt": > > I have downloaded the XSLT, placed it into freemind.jar, and tested > the result. It seems to do what it should, with one exception. > > What is does correctly: It converts indentation in notes correctly, > and it converts "a b" as "a b" instead of "a b", as it should. > > What is does erroneously: I have a test mind map "Notes and encryption > after conversion", which it fails to load; it gives the exception > "Error while parsing file:java.io.IOException: Stream closed" placed > to a root node. I attach the test mind map "Notes and encryption after > conversion" to this email. In 0.9.0 RC9, the test mind map gets opened > without a failure, albeit with conversion mistakes such as missing > newlines in notes. In 0.9.0 RC10 with the new XSLT, the mind map does > not get opened at all. > > Best regards, > Dan > > > ------------------------------------------------------------------------------ > The Next 800 Companies to Lead America's Growth: New Video Whitepaper > David G. Thomson, author of the best-selling book "Blueprint to a > Billion" shares his insights and actions to help propel your > business during the next growth cycle. Listen Now! > http://p.sf.net/sfu/SAP-dev2dev > > > _______________________________________________ > Freemind-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemind-developer |
From: Dan P. <dan...@gm...> - 2010-11-30 20:28:03
|
Hello Chris, I have just closed three bugs, out of the five listed in Finishing 0.9.0. Regarding the note conversion and the stack size: Increasing the stack size of a thread to get the thing working makes me really nervous. It seems it would be much better to implement the part that converts notes in Java, and call the Java method from XSLT. If XSLT is not up to the task, it should better get a little help from Java I think. Regarding the bug with scripting, I can still reproduce problems. I have posted a description of the latest behavior to the bug: ------------------------------------ 16. Scripts do not work if file operations are not permitted http://sourceforge.net/tracker/index.php?func=detail&aid=2789907&group_id=7118&atid=107118 In 0.9.0 RC11, an attempt has been made to fix the problem. But the problem persists, albeit in a slightly different form. I have a mind map with a script '="hello"'. When I press Alt + F8 the first time after loading the mind map, the script gets correctly executed: the text of the node with the script gets overwritten with "hello". This is an improvement over 0.9.0 RC10. Then I rewrite the text of the node with "world", to be able to see the effect of the script again. Then I press Alt + F8 again, and the script does nothing; in addition, I see the hourglass cursor signifying waiting, as if the operation were still in progress. When I repeatedly press Alt + F8, I get the same result: nothing happens. Then, I cannot close FreeMind normally and have to end it using the task manager instead, which means something got quite wrong. I emphasize that I am on Windows Vista. ------------------------------------ What do you think causes the problems with scripting? What is the solution that you are trying to implement? Best regards, Dan On Sat, Nov 27, 2010 at 1:45 PM, Christian Foltin (GMX) <chr...@gm...> wrote: > Dear Dan, > > recently, I published 0.9.0 RC11. IMHO, it solves every issue from > > http://freemind.sourceforge.net/wiki/index.php/Finishing_0.9.0 > > Regarding the problem you described: the stack size is too small to > let the replacement function work properly (there are too many recursions, > that can't be reduced inside XSLT due to the nature of this language). > So, the map gets converted > correctly, if you start the .bat (this includes -Xss8M) or on a Mac. > Otherwise, it is now opened without conversion, but with a loss of data and > an error message in the status bar. > Can you integrate the stack option into the freemind.c? > > TIA, Chris > > Am 08.11.10 15:52, schrieb Dan Polansky: > > Hello Chris, > > as regards 18. "Conversion from 0.8.0 to 0.9.0 drops indentation in > notes" and the proposed bug fix by adjusting the file > "freemind_version_updater.xslt": > > I have downloaded the XSLT, placed it into freemind.jar, and tested > the result. It seems to do what it should, with one exception. > > What is does correctly: It converts indentation in notes correctly, > and it converts "a b" as "a b" instead of "a b", as it should. > > What is does erroneously: I have a test mind map "Notes and encryption > after conversion", which it fails to load; it gives the exception > "Error while parsing file:java.io.IOException: Stream closed" placed > to a root node. I attach the test mind map "Notes and encryption after > conversion" to this email. In 0.9.0 RC9, the test mind map gets opened > without a failure, albeit with conversion mistakes such as missing > newlines in notes. In 0.9.0 RC10 with the new XSLT, the mind map does > not get opened at all. > > Best regards, > Dan > > > ------------------------------------------------------------------------------ > The Next 800 Companies to Lead America's Growth: New Video Whitepaper > David G. Thomson, author of the best-selling book "Blueprint to a > Billion" shares his insights and actions to help propel your > business during the next growth cycle. Listen Now! > http://p.sf.net/sfu/SAP-dev2dev > > _______________________________________________ > Freemind-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemind-developer > > ------------------------------------------------------------------------------ > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! > Tap into the largest installed PC base & get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev > _______________________________________________ > Freemind-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemind-developer > > |
From: Dan P. <dan...@gm...> - 2010-11-30 21:28:33
|
Hello Chris, I have discovered another regression bug and have posted a bug fix to the bug report: 19. Find next fails to end the search http://sourceforge.net/tracker/?func=detail&aid=3123873&group_id=7118&atid=107118 It is quick to fix and does not require any investigation on your side. Best regards, Dan |
From: Dan P. <dan...@gm...> - 2010-11-30 23:24:12
|
Hello Chris, I have had a look at the scripting bug, and have proposed a bug fix, one that you need to review, though. I have posted the fix to the bug report: Scripts do not work if file operations are not permitted http://sourceforge.net/tracker/index.php?func=detail&aid=2789907&group_id=7118&atid=107118 The last comment to the bug report, for your convenience: I get the undesirable behavior described with 0.9.0 RC11 removed by performing the following change in ScriptingEngine.executeScript method: // setting the same security manager the second time causes it to be // removed. //securityManager.setFinalSecurityManager(scriptingSecurityManager); // Commented out. --Dan securityManager.setFinalSecurityManager(null); // Inserted: be explicit about setting it to null. --Dan At that location, the security manager should be disabled; if it is not, it causes problems with loading of some classes later. Setting an object two times to disable something seems like a bug-prone idea. I am setting the final security manager as null, as that is the intended effect. I am not the author of the code, so I am not sure whether it matches the intention. As regards the method securityManager.setFinalSecurityManager, I do not understand why it is implemented the way it is: public void setFinalSecurityManager(SecurityManager pFinalSecurityManager) { if(pFinalSecurityManager == mFinalSecurityManager) { mFinalSecurityManager = null; return; } if(mFinalSecurityManager != null) { throw new SecurityException("There is a SecurityManager installed already."); } mFinalSecurityManager = pFinalSecurityManager; } I would implement the method as follows: public void setFinalSecurityManager(SecurityManager pFinalSecurityManager) { mFinalSecurityManager = pFinalSecurityManager; } The method should not worry about whether there is already a security manager set. When the caller wants to get the security manager removed, the caller should be very explicit about it, by passing "null". --Dan |
From: Dan P. <dan...@gm...> - 2010-12-01 08:06:03
|
Hello Chris, scripting: I have updated the bug report with a further comment: Further comment to my previous comment: It seems that the thing with setting the security manager two times to get it removed is intentional; there is a note to that effect at the top of FreeMindSecurityManager class. The key thing is that, after the recent bug fix, the security manager is being removed twice (as it should not): once in the method "evaluate", and once before the line "System.setOut(oldOut)". It seems that it should suffice that the line "securityManager.setFinalSecurityManager(scriptingSecurityManager);" before "System.setOut(oldOut)" is commented out. http://sourceforge.net/tracker/index.php?func=detail&aid=2789907&group_id=7118&atid=107118 Best regards, Dan On Wed, Dec 1, 2010 at 12:24 AM, Dan Polansky <dan...@gm...> wrote: > Hello Chris, > > I have had a look at the scripting bug, and have proposed a bug fix, > one that you need to review, though. I have posted the fix to the bug > report: > > Scripts do not work if file operations are not permitted > http://sourceforge.net/tracker/index.php?func=detail&aid=2789907&group_id=7118&atid=107118 > > The last comment to the bug report, for your convenience: > > I get the undesirable behavior described with 0.9.0 RC11 removed by > performing the following change in ScriptingEngine.executeScript method: > > // setting the same security manager the second time causes it to be > // removed. > //securityManager.setFinalSecurityManager(scriptingSecurityManager); // > Commented out. --Dan > securityManager.setFinalSecurityManager(null); // Inserted: be explicit > about setting it to null. --Dan > > At that location, the security manager should be disabled; if it is not, > it causes problems with loading of some classes later. Setting an object > two times to disable something seems like a bug-prone idea. I am setting > the final security manager as null, as that is the intended effect. I am > not the author of the code, so I am not sure whether it matches the > intention. > > As regards the method securityManager.setFinalSecurityManager, I do not > understand why it is implemented the way it is: > > public void setFinalSecurityManager(SecurityManager > pFinalSecurityManager) { > if(pFinalSecurityManager == mFinalSecurityManager) { > mFinalSecurityManager = null; > return; > } > if(mFinalSecurityManager != null) { > throw new SecurityException("There is a SecurityManager installed > already."); > } > mFinalSecurityManager = pFinalSecurityManager; > } > > I would implement the method as follows: > > public void setFinalSecurityManager(SecurityManager pFinalSecurityManager) > { > mFinalSecurityManager = pFinalSecurityManager; > } > > The method should not worry about whether there is already a security > manager set. When the caller wants to get the security manager removed, the > caller should be very explicit about it, by passing "null". > > --Dan > |
From: Christian F. (GMX) <chr...@gm...> - 2010-12-04 21:38:14
|
Hi Dan, recently, I published 0.9.0 RC12 which solves every known issue (IMHO). Even the string conversion has been moved from XSLT to a java method without memory problems. Moreover, commons-lang was removed. I hope, that you are able to test it, soon. Best regards, Chris Am 01.12.10 09:05, schrieb Dan Polansky: > Hello Chris, > > scripting: I have updated the bug report with a further comment: > > Further comment to my previous comment: It seems that the thing with > setting the security manager two times to get it removed is intentional; > there is a note to that effect at the top of FreeMindSecurityManager class. > > The key thing is that, after the recent bug fix, the security manager is > being removed twice (as it should not): once in the method "evaluate", and > once before the line "System.setOut(oldOut)". It seems that it should > suffice that the line > "securityManager.setFinalSecurityManager(scriptingSecurityManager);" before > "System.setOut(oldOut)" is commented out. > > http://sourceforge.net/tracker/index.php?func=detail&aid=2789907&group_id=7118&atid=107118 > > Best regards, > Dan > > > On Wed, Dec 1, 2010 at 12:24 AM, Dan Polansky <dan...@gm...> wrote: >> Hello Chris, >> >> I have had a look at the scripting bug, and have proposed a bug fix, >> one that you need to review, though. I have posted the fix to the bug >> report: >> >> Scripts do not work if file operations are not permitted >> http://sourceforge.net/tracker/index.php?func=detail&aid=2789907&group_id=7118&atid=107118 >> >> The last comment to the bug report, for your convenience: >> >> I get the undesirable behavior described with 0.9.0 RC11 removed by >> performing the following change in ScriptingEngine.executeScript method: >> >> // setting the same security manager the second time causes it to be >> // removed. >> //securityManager.setFinalSecurityManager(scriptingSecurityManager); // >> Commented out. --Dan >> securityManager.setFinalSecurityManager(null); // Inserted: be explicit >> about setting it to null. --Dan >> >> At that location, the security manager should be disabled; if it is not, >> it causes problems with loading of some classes later. Setting an object >> two times to disable something seems like a bug-prone idea. I am setting >> the final security manager as null, as that is the intended effect. I am >> not the author of the code, so I am not sure whether it matches the >> intention. >> >> As regards the method securityManager.setFinalSecurityManager, I do not >> understand why it is implemented the way it is: >> >> public void setFinalSecurityManager(SecurityManager >> pFinalSecurityManager) { >> if(pFinalSecurityManager == mFinalSecurityManager) { >> mFinalSecurityManager = null; >> return; >> } >> if(mFinalSecurityManager != null) { >> throw new SecurityException("There is a SecurityManager installed >> already."); >> } >> mFinalSecurityManager = pFinalSecurityManager; >> } >> >> I would implement the method as follows: >> >> public void setFinalSecurityManager(SecurityManager pFinalSecurityManager) >> { >> mFinalSecurityManager = pFinalSecurityManager; >> } >> >> The method should not worry about whether there is already a security >> manager set. When the caller wants to get the security manager removed, the >> caller should be very explicit about it, by passing "null". >> >> --Dan >> > > ------------------------------------------------------------------------------ > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! > Tap into the largest installed PC base & get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev > _______________________________________________ > Freemind-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemind-developer > |
From: Dan P. <dan...@gm...> - 2010-12-05 10:57:31
|
Hello Chris, I have closed two bugs fixed in 0.9.0 RC12. There is still at least one issue with the conversion, newly so: Each converted note now starts with the following text: <html xmlns:HtmlTools="xalan://freemind.main.HtmlTools"><head/> This seems to be a side effect, which should be removed. This was not there in 0.9.0 RC10 and seems undesirable. This "xalan" text is not only shown in the source code pane but also saved to the mind map file. http://sourceforge.net/tracker/index.php?func=detail&aid=3096369&group_id=7118&atid=107118 Another thing: in RC11 you have introduced some quiet failure when some issues occur duing the conversion. This failure is really quiet and inconspicuous, which is not good. The behavior of RC10 was much better IMHO: when there was a conversion problem, FreeMind failed as conspicuously as possible without crashing. In RC11, FreeMind says in the status line "Error on conversion. Continue without conversion. Some elements may be lost!", but this is really easy to overlook; at first, I have overlooked this message and only wondered why a converted mind map has missing notes. The thing is, the status line is quickly erased: it suffices that I select another node and the status line gets erased. I think it would really be much better to revert to RC10 behavior in this regard. The conspicuousness of the conversion problem in RC10 was good: it helped me discover a problem that I would otherwise be much more likely to overlook. The conversion problem was due to the stack problem, one that should no longer be there. Best regards, Dan On Sat, Dec 4, 2010 at 10:38 PM, Christian Foltin (GMX) <chr...@gm...> wrote: > Hi Dan, > > recently, I published 0.9.0 RC12 which solves every known issue (IMHO). > Even the string conversion has been moved from XSLT to a java method > without memory problems. > Moreover, commons-lang was removed. > > I hope, that you are able to test it, soon. > > Best regards, Chris |
From: Dan P. <dan...@gm...> - 2010-12-05 11:09:17
|
Hello Chris, when we are at the HTML text of converted notes, a minor issue that I estimate is easy to fix: The text of notes contains '<p align="left">' instead of '<p>'. What is this good for? Can this be removed so that the notes contain plain "<p>"? I do not see any visible difference of adding 'align="left"'; it seems to be needless cruft. If this is risky or difficult to fix, then just forget this email. I just thought this could be handled in one batch of work with the removal of 'xmlns:HtmlTools="xalan://freemind.main.HtmlTools"'. Best regards, Dan On Sun, Dec 5, 2010 at 11:57 AM, Dan Polansky <dan...@gm...> wrote: > Hello Chris, > > I have closed two bugs fixed in 0.9.0 RC12. > > There is still at least one issue with the conversion, newly so: > > Each converted note now starts with the following text: > > <html xmlns:HtmlTools="xalan://freemind.main.HtmlTools"><head/> > > This seems to be a side effect, which should be removed. This was not > there in 0.9.0 RC10 and seems undesirable. This "xalan" text is not > only shown in the source code pane but > also saved to the mind map file. > > http://sourceforge.net/tracker/index.php?func=detail&aid=3096369&group_id=7118&atid=107118 > > Another thing: in RC11 you have introduced some quiet failure when > some issues occur duing the conversion. This failure is really quiet > and inconspicuous, which is not good. The behavior of RC10 was much > better IMHO: when there was a conversion problem, FreeMind failed as > conspicuously as possible without crashing. In RC11, FreeMind says in > the status line "Error on conversion. Continue without conversion. > Some elements may be lost!", but this is really easy to overlook; at > first, I have overlooked this message and only wondered why a > converted mind map has missing notes. The thing is, the status line is > quickly erased: it suffices that I select another node and the status > line gets erased. I think it would really be much better to revert to > RC10 behavior in this regard. The conspicuousness of the conversion > problem in RC10 was good: it helped me discover a problem that I would > otherwise be much more likely to overlook. The conversion problem was > due to the stack problem, one that should no longer be there. > > Best regards, > Dan > > > On Sat, Dec 4, 2010 at 10:38 PM, Christian Foltin (GMX) > <chr...@gm...> wrote: >> Hi Dan, >> >> recently, I published 0.9.0 RC12 which solves every known issue (IMHO). >> Even the string conversion has been moved from XSLT to a java method >> without memory problems. >> Moreover, commons-lang was removed. >> >> I hope, that you are able to test it, soon. >> >> Best regards, Chris > |
From: Christian F. (GMX) <chr...@gm...> - 2010-12-09 20:51:05
|
Hi Dan, the <p align...> comes from the way, SimplyHTML stores everything. Here, there is a note with content "bla" stored: <node CREATED="1291927734954" ID="ID_1326457101" MODIFIED="1291927740859" POSITION="left" TEXT="asdfadsf"> <richcontent TYPE="NOTE"><html> <head> </head> <body> <p> bla </p> </body> </html> </richcontent> </node> In order to have the same in the converted notes, the align was added by me. Best regards, Chris Am 05.12.10 12:09, schrieb Dan Polansky: > Hello Chris, > > when we are at the HTML text of converted notes, a minor issue that I > estimate is easy to fix: The text of notes contains '<p align="left">' > instead of '<p>'. What is this good for? Can this be removed so that > the notes contain plain "<p>"? I do not see any visible difference of > adding 'align="left"'; it seems to be needless cruft. If this is risky > or difficult to fix, then just forget this email. I just thought this > could be handled in one batch of work with the removal of > 'xmlns:HtmlTools="xalan://freemind.main.HtmlTools"'. > > Best regards, > Dan > > > On Sun, Dec 5, 2010 at 11:57 AM, Dan Polansky <dan...@gm...> wrote: >> Hello Chris, >> >> I have closed two bugs fixed in 0.9.0 RC12. >> >> There is still at least one issue with the conversion, newly so: >> >> Each converted note now starts with the following text: >> >> <html xmlns:HtmlTools="xalan://freemind.main.HtmlTools"><head/> >> >> This seems to be a side effect, which should be removed. This was not >> there in 0.9.0 RC10 and seems undesirable. This "xalan" text is not >> only shown in the source code pane but >> also saved to the mind map file. >> >> http://sourceforge.net/tracker/index.php?func=detail&aid=3096369&group_id=7118&atid=107118 >> >> Another thing: in RC11 you have introduced some quiet failure when >> some issues occur duing the conversion. This failure is really quiet >> and inconspicuous, which is not good. The behavior of RC10 was much >> better IMHO: when there was a conversion problem, FreeMind failed as >> conspicuously as possible without crashing. In RC11, FreeMind says in >> the status line "Error on conversion. Continue without conversion. >> Some elements may be lost!", but this is really easy to overlook; at >> first, I have overlooked this message and only wondered why a >> converted mind map has missing notes. The thing is, the status line is >> quickly erased: it suffices that I select another node and the status >> line gets erased. I think it would really be much better to revert to >> RC10 behavior in this regard. The conspicuousness of the conversion >> problem in RC10 was good: it helped me discover a problem that I would >> otherwise be much more likely to overlook. The conversion problem was >> due to the stack problem, one that should no longer be there. >> >> Best regards, >> Dan >> >> >> On Sat, Dec 4, 2010 at 10:38 PM, Christian Foltin (GMX) >> <chr...@gm...> wrote: >>> Hi Dan, >>> >>> recently, I published 0.9.0 RC12 which solves every known issue (IMHO). >>> Even the string conversion has been moved from XSLT to a java method >>> without memory problems. >>> Moreover, commons-lang was removed. >>> >>> I hope, that you are able to test it, soon. >>> >>> Best regards, Chris >> > > ------------------------------------------------------------------------------ > What happens now with your Lotus Notes apps - do you make another costly > upgrade, or settle for being marooned without product support? Time to move > off Lotus Notes and onto the cloud with Force.com, apps are easier to build, > use, and manage than apps on traditional platforms. Sign up for the Lotus > Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d > _______________________________________________ > Freemind-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemind-developer |
From: Christian F. (GMX) <chr...@gm...> - 2010-12-09 20:53:12
|
Dear Dan, both is fixed in CVS. The first, you can verify by exchanging the xslt script. Best regards, Chris Am 05.12.10 11:57, schrieb Dan Polansky: > Hello Chris, > > I have closed two bugs fixed in 0.9.0 RC12. > > There is still at least one issue with the conversion, newly so: > > Each converted note now starts with the following text: > > <html xmlns:HtmlTools="xalan://freemind.main.HtmlTools"><head/> > > This seems to be a side effect, which should be removed. This was not > there in 0.9.0 RC10 and seems undesirable. This "xalan" text is not > only shown in the source code pane but > also saved to the mind map file. > > http://sourceforge.net/tracker/index.php?func=detail&aid=3096369&group_id=7118&atid=107118 > > Another thing: in RC11 you have introduced some quiet failure when > some issues occur duing the conversion. This failure is really quiet > and inconspicuous, which is not good. The behavior of RC10 was much > better IMHO: when there was a conversion problem, FreeMind failed as > conspicuously as possible without crashing. In RC11, FreeMind says in > the status line "Error on conversion. Continue without conversion. > Some elements may be lost!", but this is really easy to overlook; at > first, I have overlooked this message and only wondered why a > converted mind map has missing notes. The thing is, the status line is > quickly erased: it suffices that I select another node and the status > line gets erased. I think it would really be much better to revert to > RC10 behavior in this regard. The conspicuousness of the conversion > problem in RC10 was good: it helped me discover a problem that I would > otherwise be much more likely to overlook. The conversion problem was > due to the stack problem, one that should no longer be there. > > Best regards, > Dan > > > On Sat, Dec 4, 2010 at 10:38 PM, Christian Foltin (GMX) > <chr...@gm...> wrote: >> Hi Dan, >> >> recently, I published 0.9.0 RC12 which solves every known issue (IMHO). >> Even the string conversion has been moved from XSLT to a java method >> without memory problems. >> Moreover, commons-lang was removed. >> >> I hope, that you are able to test it, soon. >> >> Best regards, Chris > > ------------------------------------------------------------------------------ > What happens now with your Lotus Notes apps - do you make another costly > upgrade, or settle for being marooned without product support? Time to move > off Lotus Notes and onto the cloud with Force.com, apps are easier to build, > use, and manage than apps on traditional platforms. Sign up for the Lotus > Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d > _______________________________________________ > Freemind-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemind-developer |
From: Dan P. <dan...@gm...> - 2010-12-10 18:55:12
|
Hello Chris, I have tested your changes by updating my version of FreeMind 0.9.0 in Eclipse from CVS, and running FreeMind from Eclipse. Re removing of the "Xalan" string: works fine. Re conspicous failure: it works. I have tested the thing by placing "throw new Exception("Artificial exception");" before the line "successful = true" in the class "TransformerRunnable" in Tools.java. Re '<p align="left">': I do not understand your explanation. There is no '<p align="left">' in the HTML source of rich text long nodes, so I do not see why there should be '<p align="left">' in the HTML source of notes. When you create a long plain text node, then switch it to rich text, and then look at the HTML source, there is no 'align="left"'; and that is how it should be, if you ask me. I do not see any useful function that 'align="left"' serves, nor do I see any technical necessity for it being there. I have looked at HTML paragraph tags generated by MediaWiki, and they are plain ones, having no 'align="left"'. So no matter how I think about it, I do not understand the need. Best regards, Dan |
From: Christian F. (GMX) <chr...@gm...> - 2010-12-17 20:51:48
|
Hi Dan, to end up this discussion, I've removed the align=left in the CVS version of the updater script. I you don't mind, I'm going to release the 0.9.0 version. Do you have any important objections? Best regards, Chris Am 10.12.10 19:55, schrieb Dan Polansky: > Hello Chris, > > I have tested your changes by updating my version of FreeMind 0.9.0 in > Eclipse from CVS, and running FreeMind from Eclipse. > > Re removing of the "Xalan" string: works fine. > > Re conspicous failure: it works. I have tested the thing by placing > "throw new Exception("Artificial exception");" before the line > "successful = true" in the class "TransformerRunnable" in Tools.java. > > Re '<p align="left">': I do not understand your explanation. There is > no '<p align="left">' in the HTML source of rich text long nodes, so I > do not see why there should be '<p align="left">' in the HTML source > of notes. When you create a long plain text node, then switch it to > rich text, and then look at the HTML source, there is no > 'align="left"'; and that is how it should be, if you ask me. I do not > see any useful function that 'align="left"' serves, nor do I see any > technical necessity for it being there. I have looked at HTML > paragraph tags generated by MediaWiki, and they are plain ones, having > no 'align="left"'. So no matter how I think about it, I do not > understand the need. > > Best regards, > Dan > > ------------------------------------------------------------------------------ > Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, > new data types, scalar functions, improved concurrency, built-in packages, > OCI, SQL*Plus, data movement tools, best practices and more. > http://p.sf.net/sfu/oracle-sfdev2dev > _______________________________________________ > Freemind-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemind-developer > |
From: Dan P. <dan...@gm...> - 2010-12-18 06:54:28
|
Hello Chris, thank you for your removing align=left. >From the point of view of a clean process, there should IMHO better be a version 0.9.0 RC13. Then I can close the bugs in the bug tracker against this version, and after a week or so after the release of 0.9.0 RC13, a final version can be released that is identical to 0.9.0 RC13. My understanding of a good process of final release is that the the final release should be identical to the last published RC version. As our recent experience shows, an RC version sometimes contains bugs that were thought to be fixed in the RC version, or contains new bugs or issues. I do not really think that there are going to be any problems with RC13, but my estimation can turn wrong, hence it would be better to keep this process, I think. Best regards, Dan On Fri, Dec 17, 2010 at 9:51 PM, Christian Foltin (GMX) <chr...@gm...> wrote: > Hi Dan, > > to end up this discussion, I've removed the align=left in the CVS > version of the updater script. > > I you don't mind, I'm going to release the 0.9.0 version. > Do you have any important objections? > > Best regards, > > Chris > > Am 10.12.10 19:55, schrieb Dan Polansky: >> Hello Chris, >> >> I have tested your changes by updating my version of FreeMind 0.9.0 in >> Eclipse from CVS, and running FreeMind from Eclipse. >> >> Re removing of the "Xalan" string: works fine. >> >> Re conspicous failure: it works. I have tested the thing by placing >> "throw new Exception("Artificial exception");" before the line >> "successful = true" in the class "TransformerRunnable" in Tools.java. >> >> Re '<p align="left">': I do not understand your explanation. There is >> no '<p align="left">' in the HTML source of rich text long nodes, so I >> do not see why there should be '<p align="left">' in the HTML source >> of notes. When you create a long plain text node, then switch it to >> rich text, and then look at the HTML source, there is no >> 'align="left"'; and that is how it should be, if you ask me. I do not >> see any useful function that 'align="left"' serves, nor do I see any >> technical necessity for it being there. I have looked at HTML >> paragraph tags generated by MediaWiki, and they are plain ones, having >> no 'align="left"'. So no matter how I think about it, I do not >> understand the need. >> >> Best regards, >> Dan |
From: Christian F. (GMX) <chr...@gm...> - 2010-12-19 21:09:23
|
Hi Dan, done, although ... Best regards, Chris Am 18.12.10 07:54, schrieb Dan Polansky: > Hello Chris, > > thank you for your removing align=left. > > From the point of view of a clean process, there should IMHO better be > a version 0.9.0 RC13. Then I can close the bugs in the bug tracker > against this version, and after a week or so after the release of > 0.9.0 RC13, a final version can be released that is identical to 0.9.0 > RC13. > > My understanding of a good process of final release is that the the > final release should be identical to the last published RC version. As > our recent experience shows, an RC version sometimes contains bugs > that were thought to be fixed in the RC version, or contains new bugs > or issues. I do not really think that there are going to be any > problems with RC13, but my estimation can turn wrong, hence it would > be better to keep this process, I think. > > Best regards, > Dan > |
From: Dan P. <dan...@gm...> - 2010-12-22 19:21:36
|
Hello Chris, unfortunately, I have discovered a conversion bug that was already fixed in 0.9.0 RC5 and reappeared in 0.9.0 RC11, and persist in 0.9.0 RC13 (the bug is not there in 0.9.0 RC10). I am sorry I did not discover the bug earlier; possibly, I have failed to notice the problem because of the too quiet failure on conversion to 0.9.0 that was introduced in 0.9.0 RC11 and removed in 0.9.0 RC13. 21. Byte-order mark for UTF-8 (BOM) produces failure to load http://sourceforge.net/tracker/?func=detail&aid=3141875&group_id=7118&atid=107118 Best regards, Dan On Sun, Dec 19, 2010 at 10:09 PM, Christian Foltin (GMX) <chr...@gm...> wrote: > Hi Dan, > > done, although ... > > Best regards, Chris > > Am 18.12.10 07:54, schrieb Dan Polansky: >> Hello Chris, >> >> thank you for your removing align=left. >> >> From the point of view of a clean process, there should IMHO better be >> a version 0.9.0 RC13. Then I can close the bugs in the bug tracker >> against this version, and after a week or so after the release of >> 0.9.0 RC13, a final version can be released that is identical to 0.9.0 >> RC13. >> >> My understanding of a good process of final release is that the the >> final release should be identical to the last published RC version. As >> our recent experience shows, an RC version sometimes contains bugs >> that were thought to be fixed in the RC version, or contains new bugs >> or issues. I do not really think that there are going to be any >> problems with RC13, but my estimation can turn wrong, hence it would >> be better to keep this process, I think. >> >> Best regards, >> Dan >> > > ------------------------------------------------------------------------------ > Lotusphere 2011 > Register now for Lotusphere 2011 and learn how > to connect the dots, take your collaborative environment > to the next level, and enter the era of Social Business. > http://p.sf.net/sfu/lotusphere-d2d > _______________________________________________ > Freemind-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemind-developer > |
From: Dan P. <dan...@gm...> - 2010-12-22 19:27:42
|
An afterthought: my error: I have failed to notice the problem because I have failed to test Cars.mm in the first place. When I open Cars.mm in 0.9.0 RC11, the failure is conspicuous. I have no clue why I have omitted Cars.mm from the test. --Dan On Wed, Dec 22, 2010 at 8:21 PM, Dan Polansky <dan...@gm...> wrote: > Hello Chris, > > unfortunately, I have discovered a conversion bug that was already > fixed in 0.9.0 RC5 and reappeared in 0.9.0 RC11, and persist in 0.9.0 > RC13 (the bug is not there in 0.9.0 RC10). I am sorry I did not > discover the bug earlier; possibly, I have failed to notice the > problem because of the too quiet failure on conversion to 0.9.0 that > was introduced in 0.9.0 RC11 and removed in 0.9.0 RC13. > > 21. Byte-order mark for UTF-8 (BOM) produces failure to load > http://sourceforge.net/tracker/?func=detail&aid=3141875&group_id=7118&atid=107118 > > Best regards, > Dan > > > On Sun, Dec 19, 2010 at 10:09 PM, Christian Foltin (GMX) > <chr...@gm...> wrote: >> Hi Dan, >> >> done, although ... >> >> Best regards, Chris >> >> Am 18.12.10 07:54, schrieb Dan Polansky: >>> Hello Chris, >>> >>> thank you for your removing align=left. >>> >>> From the point of view of a clean process, there should IMHO better be >>> a version 0.9.0 RC13. Then I can close the bugs in the bug tracker >>> against this version, and after a week or so after the release of >>> 0.9.0 RC13, a final version can be released that is identical to 0.9.0 >>> RC13. >>> >>> My understanding of a good process of final release is that the the >>> final release should be identical to the last published RC version. As >>> our recent experience shows, an RC version sometimes contains bugs >>> that were thought to be fixed in the RC version, or contains new bugs >>> or issues. I do not really think that there are going to be any >>> problems with RC13, but my estimation can turn wrong, hence it would >>> be better to keep this process, I think. >>> >>> Best regards, >>> Dan >>> >> >> ------------------------------------------------------------------------------ >> Lotusphere 2011 >> Register now for Lotusphere 2011 and learn how >> to connect the dots, take your collaborative environment >> to the next level, and enter the era of Social Business. >> http://p.sf.net/sfu/lotusphere-d2d >> _______________________________________________ >> Freemind-developer mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freemind-developer >> > |
From: Christian F. (GMX) <chr...@gm...> - 2010-12-23 23:08:59
|
Dear Dan, we've encountered a long known java bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4508058 I've fixed it the usual way and, currently, RC14 is publishing on SF. (By the way, now some other (UTF) encodings should be supported, too.) HTH, Chris PS: Mery christmas! Am 22.12.10 20:21, schrieb Dan Polansky: > Hello Chris, > > unfortunately, I have discovered a conversion bug that was already > fixed in 0.9.0 RC5 and reappeared in 0.9.0 RC11, and persist in 0.9.0 > RC13 (the bug is not there in 0.9.0 RC10). I am sorry I did not > discover the bug earlier; possibly, I have failed to notice the > problem because of the too quiet failure on conversion to 0.9.0 that > was introduced in 0.9.0 RC11 and removed in 0.9.0 RC13. > > 21. Byte-order mark for UTF-8 (BOM) produces failure to load > http://sourceforge.net/tracker/?func=detail&aid=3141875&group_id=7118&atid=107118 > > Best regards, > Dan > > > On Sun, Dec 19, 2010 at 10:09 PM, Christian Foltin (GMX) > <chr...@gm...> wrote: >> Hi Dan, >> >> done, although ... >> >> Best regards, Chris >> >> Am 18.12.10 07:54, schrieb Dan Polansky: >>> Hello Chris, >>> >>> thank you for your removing align=left. >>> >>> From the point of view of a clean process, there should IMHO better be >>> a version 0.9.0 RC13. Then I can close the bugs in the bug tracker >>> against this version, and after a week or so after the release of >>> 0.9.0 RC13, a final version can be released that is identical to 0.9.0 >>> RC13. >>> >>> My understanding of a good process of final release is that the the >>> final release should be identical to the last published RC version. As >>> our recent experience shows, an RC version sometimes contains bugs >>> that were thought to be fixed in the RC version, or contains new bugs >>> or issues. I do not really think that there are going to be any >>> problems with RC13, but my estimation can turn wrong, hence it would >>> be better to keep this process, I think. >>> >>> Best regards, >>> Dan >>> >> >> ------------------------------------------------------------------------------ >> Lotusphere 2011 >> Register now for Lotusphere 2011 and learn how >> to connect the dots, take your collaborative environment >> to the next level, and enter the era of Social Business. >> http://p.sf.net/sfu/lotusphere-d2d >> _______________________________________________ >> Freemind-developer mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freemind-developer >> > > ------------------------------------------------------------------------------ > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Freemind-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemind-developer |
From: Dan P. <dan...@gm...> - 2010-12-24 09:47:45
|
Hello Chris, thank you for the rapid bug fix! I have tested 0.9.0 RC14 against all the mind maps that I use to test the conversion from 0.8.1 to 0.9.0, and everything looks good, ready for the final release. Nonetheless, please give me some more time to once more thoroughly test 0.9.0 RC14; this test that I have made has been hasty and without my full attention, performed under time pressure. Merry Christmas! Best regards, Dan On Fri, Dec 24, 2010 at 12:08 AM, Christian Foltin (GMX) <chr...@gm...> wrote: > Dear Dan, > > we've encountered a long known java bug: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4508058 > > I've fixed it the usual way and, currently, RC14 is publishing on SF. > (By the way, now some other (UTF) encodings should be supported, too.) > > HTH, Chris > > PS: Mery christmas! > > Am 22.12.10 20:21, schrieb Dan Polansky: >> Hello Chris, >> >> unfortunately, I have discovered a conversion bug that was already >> fixed in 0.9.0 RC5 and reappeared in 0.9.0 RC11, and persist in 0.9.0 >> RC13 (the bug is not there in 0.9.0 RC10). I am sorry I did not >> discover the bug earlier; possibly, I have failed to notice the >> problem because of the too quiet failure on conversion to 0.9.0 that >> was introduced in 0.9.0 RC11 and removed in 0.9.0 RC13. >> >> 21. Byte-order mark for UTF-8 (BOM) produces failure to load >> http://sourceforge.net/tracker/?func=detail&aid=3141875&group_id=7118&atid=107118 >> >> Best regards, >> Dan >> >> >> On Sun, Dec 19, 2010 at 10:09 PM, Christian Foltin (GMX) >> <chr...@gm...> wrote: >>> Hi Dan, >>> >>> done, although ... >>> >>> Best regards, Chris >>> >>> Am 18.12.10 07:54, schrieb Dan Polansky: >>>> Hello Chris, >>>> >>>> thank you for your removing align=left. >>>> >>>> From the point of view of a clean process, there should IMHO better be >>>> a version 0.9.0 RC13. Then I can close the bugs in the bug tracker >>>> against this version, and after a week or so after the release of >>>> 0.9.0 RC13, a final version can be released that is identical to 0.9.0 >>>> RC13. >>>> >>>> My understanding of a good process of final release is that the the >>>> final release should be identical to the last published RC version. As >>>> our recent experience shows, an RC version sometimes contains bugs >>>> that were thought to be fixed in the RC version, or contains new bugs >>>> or issues. I do not really think that there are going to be any >>>> problems with RC13, but my estimation can turn wrong, hence it would >>>> be better to keep this process, I think. >>>> >>>> Best regards, >>>> Dan >>>> >>> >>> ------------------------------------------------------------------------------ >>> Lotusphere 2011 >>> Register now for Lotusphere 2011 and learn how >>> to connect the dots, take your collaborative environment >>> to the next level, and enter the era of Social Business. >>> http://p.sf.net/sfu/lotusphere-d2d >>> _______________________________________________ >>> Freemind-developer mailing list >>> Fre...@li... >>> https://lists.sourceforge.net/lists/listinfo/freemind-developer >>> >> >> ------------------------------------------------------------------------------ >> Learn how Oracle Real Application Clusters (RAC) One Node allows customers >> to consolidate database storage, standardize their database environment, and, >> should the need arise, upgrade to a full multi-node Oracle RAC database >> without downtime or disruption >> http://p.sf.net/sfu/oracle-sfdevnl >> _______________________________________________ >> Freemind-developer mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freemind-developer > > ------------------------------------------------------------------------------ > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Freemind-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemind-developer > |
From: Dan P. <dan...@gm...> - 2010-12-27 09:33:17
|
Hello Chris, I have found two more bugs related to data loss, by extending a test mind map with even more cases in which something could go wrong in conversion from 0.8.0 to 0.9.0. 22. Conversion from 0.8.0 to 0.9.0 drops encrypted arrow links http://sourceforge.net/tracker/?func=detail&aid=3145871&group_id=7118&atid=107118 23. Drag and drop of two connected nodes drops arrow link http://sourceforge.net/tracker/?func=detail&aid=3145900&group_id=7118&atid=107118 I am sorry, again, that I did not discover these bug earlier. Unfortunately, my brain seems to be much more eager to think about what can go wrong when there are no more bugs on the list to be fixed. Best regards, Dan |
From: Christian F. (GMX) <chr...@gm...> - 2010-12-27 16:53:33
|
Hi Dan, sorry, if we continue like this, we'll never publish 0.9.0. IMHO, these bugs are not that dramatic. Let's postpone them. Best regards, Chris Am 27.12.10 10:33, schrieb Dan Polansky: > Hello Chris, > > I have found two more bugs related to data loss, by extending a test > mind map with even more cases in which something could go wrong in > conversion from 0.8.0 to 0.9.0. > > 22. Conversion from 0.8.0 to 0.9.0 drops encrypted arrow links > http://sourceforge.net/tracker/?func=detail&aid=3145871&group_id=7118&atid=107118 > > 23. Drag and drop of two connected nodes drops arrow link > http://sourceforge.net/tracker/?func=detail&aid=3145900&group_id=7118&atid=107118 > > I am sorry, again, that I did not discover these bug earlier. > Unfortunately, my brain seems to be much more eager to think about > what can go wrong when there are no more bugs on the list to be fixed. > > Best regards, > Dan > > ------------------------------------------------------------------------------ > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Freemind-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemind-developer > |
From: Dan P. <dan...@gm...> - 2010-12-27 19:22:44
|
Hello Chris, the ultimate decision is up to you, as you are the project director. Whatever I decide or propose, you can override it. Nonetheless, within the constrained and subordinate role of the unofficial quality manager of FreeMind, I feel uncomfortable giving go ahead to a version that contains known bugs that lead to data loss. Both bugs 22 and 23 are related to data loss. Especially bug 22 is rather insidious, easy to be overlooked by the affected user. Bug 23 is rather unlikely to be overlooked by the user, so it could really be postponed for 0.9.1, but it is a data loss bug nonetheless. I am fully aware of the time pressure to release final FreeMind 0.9.0, which is why I do not report here some regression bugs that are less serious. From where I am standing, we seem to be really close to final release. Best regards, Dan On Mon, Dec 27, 2010 at 5:53 PM, Christian Foltin (GMX) <chr...@gm...> wrote: > Hi Dan, > > sorry, if we continue like this, we'll never publish 0.9.0. > > IMHO, these bugs are not that dramatic. > Let's postpone them. > > Best regards, Chris > > Am 27.12.10 10:33, schrieb Dan Polansky: >> Hello Chris, >> >> I have found two more bugs related to data loss, by extending a test >> mind map with even more cases in which something could go wrong in >> conversion from 0.8.0 to 0.9.0. >> >> 22. Conversion from 0.8.0 to 0.9.0 drops encrypted arrow links >> http://sourceforge.net/tracker/?func=detail&aid=3145871&group_id=7118&atid=107118 >> >> 23. Drag and drop of two connected nodes drops arrow link >> http://sourceforge.net/tracker/?func=detail&aid=3145900&group_id=7118&atid=107118 >> >> I am sorry, again, that I did not discover these bug earlier. >> Unfortunately, my brain seems to be much more eager to think about >> what can go wrong when there are no more bugs on the list to be fixed. >> >> Best regards, >> Dan |