GSoC Ideas for Basic
Apologies, but I am having trouble accessing my wiki account: it has been a long while. So, I am delivering this via email. If there is no ESC veto or rework demand in the next few days I will get these into the GSoC Idea page even if I have to re-register. The lexer idea came from elsewhere (dev or qa list, I think) but immediately appealed to me after seeing many bugs in the editing functions of the current BASIC IDE and looking at fixing them. Similarly the user guide request is in bugzilla as an enhancement request. So... Here are a couple ideas for Libre Office BASIC [*LOB*]: *Project 1: BUG - BASIC User's Guide (a dev guide for LOB) *Starting from outline work up an accurate description and usage samples for every element of LOB on the TDF Wiki. Starts with the existing help so is easy level but is fat book length. Offers: Immediate contribution Skills: LOB programming, documentation Results: -- Internal: clarity and completeness of LOB IDE issue reports, -- Int/Ext : at least a good start on the BUG as wiki, -- External: better user experience, easier transition from MSO/VBA to LibreOffice Extra/2nd project: UNO description/examples in BASIC Extra/2nd project: all examples in Python *Project 2: Lexer and folder for LOB in scintilla *Get scintilla to understand LOB well enough to support syntax highlighting, folding, annotation, auto-indent and maybe autocompletion. The idea is to bring LOB to scintilla, not to integrate scintilla into current IDE. The concept of the lexer is straightforward, but the BASIC syntax is not simple. Many elements have alternate forms and usage: Built-ins can be used as expression or statement; Arrays have option base, dim and redim, Array() and issues as function argument; There is VBA support (or not); Etc. Each element treated by the lexer could use one or more of 1) syntax highlighting of correct form, 2) error/warn on incorrect or risky usage, 3) hint/suggested fix [annotation]. Autoindent and autocompletion could be implemented within (or more properly alongside?) the lexer/folder. Wrapping the editor as a useful extension would require delving into the integration issues around loading and saving Basic from odt/ods documents. Skill Level: Medium Offers: experience in developing developer tools Skills: C++ programming Results: the best LOB editor ever -- Internal: -- Int/Ext : wrap the results as an extension -- External: code editor extension ( free-standing) Extra: Autocomplete Extra/2nd project: UNO support in lexer (introspection) = end of GSoc ideas Context for the 2d project and many more potential projects: The overarching idea is to replace the current BASIC only IDE with an open source multi-language IDE. Current IDE is old-school stuff unlike most of LibO: it is fragile and has few possible maintainers and those that are active are already booked up. The open source projects *potentially* added to LibO code base include scintilla, GTk, Glade, Geany, Anjuta Fixing the raft of issues with the action of the current IDE is a nice side effect but is a minor result compared to the amount of effort in integrating a new IDE . The project of replacing the whole IDE is far beyond the scope of GSoC. Consequently, only a few of the sub-projects may produce an immediately visible effect on LibreOffice like the ones above. Different paths available: Path A: Rebuild existing IDE Replace editor with scintilla and move windowing to GTk. + lessens Runtime/IDE integration issues - will still be LOB only Path B: Replace existing IDE with code editor (Geany) and plugins (Glade) Step-by-step might be the best path ... could also be slowest and most work - needs to work through ~all Runtime/IDE integration issues to succeed - needs Glade integration to support dialog boxes Path C: Replace existing IDE with tailored full-featured IDE (Anjuta) + minimizes IDE development, so might be fastest path - needs to work through ~all Runtime/IDE integration issues to succeed + could end up with an IDE in LibO that can be used to develop anything, including LibO -- View this message in context: http://nabble.documentfoundation.org/GSoC-Ideas-for-Basic-tp4139212.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Wrong indentation which leads to segfault in sc/source/ui/docshell/docfunc.cxx
Julien,
Looks to me like a very nice catch ...
Here is the version as of 2011.06.15 showing braces on the for loops in both
then and else blocks...
from open grok --
http://opengrok.libreoffice.org/xref/core/sc/source/ui/docshell/docfunc.cxx?r=1b363f632110e80ead67ff376e92e4487556ca55
3735
3736 if (bSize)
3737 {
3738 SCCOLROW nCols[2] = { nStartCol, nEndCol };
3739 SCCOLROW nRows[2] = { nStartRow, nEndRow };
3740
3741 for (SCTAB nTab=0; nTabnTabCount; nTab++)
3742 if (aMark.GetTableSelect(nTab))
3743 {
3744 SetWidthOrHeight( sal_True, 1,nCols, nTab,
SC_SIZE_VISOPT, STD_EXTRA_WIDTH, false, sal_True);
3745 SetWidthOrHeight( false,1,nRows, nTab,
SC_SIZE_VISOPT, 0, false, false);
3746 rDocShell.PostPaint( 0,0,nTab,
MAXCOL,MAXROW,nTab,
3747 PAINT_GRID | PAINT_LEFT |
PAINT_TOP );
3748 }
3749 }
3750 else
3751 {
3752 for (SCTAB nTab=0; nTablt;nTabCount; nTab++)
3753 if (aMark.GetTableSelect(nTab))
3754 {
3755 sal_Bool bAdj = AdjustRowHeight(
ScRange(nStartCol, nStartRow, nTab,
3756 nEndCol,
nEndRow, nTab), false );
3757 if (bAdj)
3758 rDocShell.PostPaint( 0,nStartRow,nTab,
MAXCOL,MAXROW,nTab,
3759 PAINT_GRID | PAINT_LEFT
);
3760 else
3761 rDocShell.PostPaint( nStartCol, nStartRow,
nTab,
3762 nEndCol, nEndRow, nTab,
PAINT_GRID );
3763 }
3764 }
The next version (2011.07.05)
http://opengrok.libreoffice.org/xref/core/sc/source/ui/docshell/docfunc.cxx?r=2b88f6d32f572792597ccbb15276b9db52db7d10
is a commit labelled quot;change remaining manual loops to
ScMarkData::iterator quot; and the braces disappear on just one of the
loops. Because the braces were once there and, especially because the else
block has ~ same action within the braces, I say that they should definitely
come back. Even though, I am not at all clear what this code is doing
(whilst autoformatting selected cells in Calc)... this is an obvious oopsie
within a greater code cleanup that should be corrected.
This is not fdo# 47466 -- that crash gets close but doesn't quite get to
this code: that non-reproducible crash occurred inside the AutoFormat
function called just above the missing braces.
After some more looking at the code, it appears to be applying widths and
heights... Some testing shows that if one selects a tabular area and apply a
non-default width and height (Format-Rows/Columns-Height/Width) then and
uncheck AutoFormat Width and Height under AutoFormat... - More. Doing the
AutoFormat then forgets the width (doesn't loop) but not the height (still
loops).
The block of code in question starts to look like maybe it is fix code that
corrects an overactive AutoFormat function called just above.
This here bug -- https://bugs.freedesktop.org/show_bug.cgi?id=51524
Shows similar loss-of-width behavior in collapse/uncollapse (as opposed to
straight up AutoFormat)
There are also several reports of loss of height information (including
self-healing upon edit) - most of them are closed /or related to file
open/close. Maybe this block of W/H fix code is missing elsewhere, maybe it
is not needed here anymore, maybe the open save fix the values better than
this now, maybe this simply is the width/height portion of the AutoFormat
... h
I will check to see if inserting braces in the code fixes whatever
loss-of-width/height behavior that I can reproduce or find.
My 2cents... and now a couple more:
I note that, for all its type mushiness, BASIC will not allow this kind of
mistake. The then-clause must either be all on one line (can do IF test
THEN StmtA : StmtB : StmtC) and a multi-line then-clause must be terminated
with End If or Else.
Julien, I think you should get the patch credit - this is your find.
However, if it will help you continue to run cppchecks and find more of
these interesting puzzles, I would be happy to patch a pair of braces for
you and mark the appropriate bugs as resolved by you ;-D
Sweet catch,
LeMoyne
--
View this message in context:
http://nabble.documentfoundation.org/Wrong-indentation-which-leads-to-segfault-in-sc-source-ui-docshell-docfunc-cxx-tp4026726p4026751.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Wrong indentation which leads to segfault in sc/source/ui/docshell/docfunc.cxx
If only I could *always* read well ... and I didn't second guess myself so easily ... The stack trace from 47466 - Crash occurring in Windows 64bit versions... msvcr90!_invalid_parameter_noinfo+0xc sclo!std::_Treestd::_Tset_traitslt;short,std::lesslt;short,std::allocatorshort,0 ::const_iterator::operator*+0x35 [c:\program files\microsoft visual studio 9.0\vc\include\xtree @ 264] sclo!std::_Treestd::_Tset_traitslt;short,std::lesslt;short,std::allocatorshort,0 ::iterator::operator*+0xf [c:\program files\microsoft visual studio 9.0\vc\include\xtree @ 466] sclo!ScDocFunc::AutoFormat+0x520 [d:\losrc\3553\sc\source\ui\docshell\docfunc.cxx @ 3739] sclo!ScViewFunc::AutoFormat+0x70 [d:\losrc\3553\sc\source\ui\view\viewfun2.cxx @ 1575] Is almost identical to yours. You HAVE reproduced fdo#47466. The iterator functions appear to paper over the access at itr.end() everywhere except 1) Windows 64bit where it crashes and 2) your cppcheck which has replaced the standard iterator with a safe iterator, if I am not mistaken. But really the unasked for width adjustments people see could be the result of an uncaught exception shortcutting all the rest of the width/height fix, etc so format does not get restored to fixed width and height during the AutoFormat. Bubbling exception from this could also help explain the report of related undo failures after the errant width/height change as in fdo# 34552 EDITING: Calc loses row height value when modifying a cell https://bugs.freedesktop.org/show_bug.cgi?id=34552 -- if it skips out from the point of the missing braces then it will fail to record the undo info for the width height change and that could cause the behavior there And maybe even other bugs if calls to this AutoFormat function are involved there ... Like https://bugs.freedesktop.org/show_bug.cgi?id=57176 Undo of delete of Conditional Formatting works for one cell but fails for multi-cell (cf. if (bSize) ...) On final note, I don't think that bool ScDocFunc::AutoFormat( const ScRange rRange, ... will return bSuccess = true under any circumstances. Just sayin' ;-) I will seek more bugs and test them before and after the brace insert in the next few days ... Again... looks like a real good catch here. Gratz and thank you for the puzzle. Happy New Year !!! LeMoyne -- View this message in context: http://nabble.documentfoundation.org/Wrong-indentation-which-leads-to-segfault-in-sc-source-ui-docshell-docfunc-cxx-tp4026726p4026757.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH]: Fix for rtfexport subsequenttest - now [ONGERRIT]
With help from Norbert was able to get my ssh client straightened out and submit this patch through gerrit: https://gerrit.libreoffice.org/#/c/1464/ Thanks for your speed and patience Norbert. FWIW, I am back in the pool! LeMoyne -- View this message in context: http://nabble.documentfoundation.org/PATCH-Fix-for-rtfexport-subsequenttest-tp4025719p4025745.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Fix for fdo#30550 Character count without spaces
Hi Korrawit, My take is: -- you (and others) cannot reproduce fdo#37584 (redlined text disappears) in 3-3 or 3-3-3 because my patch referenced in your original post [OP] is not in the 3-3 branches. -- you and others cannot reproduce 'leading quote as word' in your 3-3 build because the patch you submitted with OP has fixed that problem in 3-3 since 2011-06-21. Your OP patch is not yet in 3-3-3 official build so the leading quote problem still exists there. A word count problem that may still exist in 3-3(-3) is that the count may be off when a selection ends in the middle of a word. Given that all of 3-3(-3) is supposed to be stable and the case where selection ends in mid-word is an edge case (not the common use case of count doc or entire section)... I think that your elegant clipping=true fix already in 3-3 is the most that should go into 3-3-3. I repeat, *IF* my patch referenced in the OP goes into the 3-3(-3) area then Cedric's fix should follow immediately. (That patch was intended as a fix of the selection ends in mid-word issue and code cleanup.) I think that the two patches given in your last message are already in 3-3(-3). The Thomas Lange patch http://cgit.freedesktop.org/libreoffice/libs-gui/commit/?id=cb9aa439fbb0a85829b1e61e292b1553512b0cb5 is already in 3.3(-3) and this is the patch that removed the deep copy at the SwScanner level so that the deep copy in Cedric's fix is now required at the outer CountWords (sp?) level. From following branch lines in QGit I think this tl patch (dated 2010-12-08) got merged into 3-4 in late winter ~Feb 2011 and that's when redlining went south in 3-4. Or so I think after following the link you posted and searching 'word count' and switching branches and scrolling past hundreds of commits in QGit and ... I hope this is clearer than my last post. I am *NOT* an expert in configuration or even in word count but I have been studying the question of 'what is where? and when did it get there?' with an eye for both qa and dev. I have tried to expose my thinking here in the hopes that it may help you and that I will get corrected as needed, *not* because it is expert opinion. Again, I hope this helps, LeMoyne -- View this message in context: http://nabble.documentfoundation.org/PATCH-Fix-for-fdo-30550-Character-count-without-spaces-tp3092043p3103177.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Michael @ OP - awesome set of notes! Cor @ I only can point to my favourite page: http://wiki.documentfoundation.org/Installing_in_parallel Even though I have two build configs (3.4 and master), OOo3.2 and the 3.4 release installed, I have been frustrated in doing full triage/testing and other qa by no access to 3.3 - I can see why that is your favorite page and now I can see why you (and others) are able to test issues in any version. Thank you so much! LeMoyne -- View this message in context: http://nabble.documentfoundation.org/minutes-of-tech-steering-call-tp3100951p3103230.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Fix for fdo#30550 Character count without spaces
Hi Korrawit, Cedric, all ... A first, quick reply is that this patch of mine contains the dread redline wipeout: + // make a copy of the text + String rTextCopy = const_castlt;Stringamp;gt;(m_Text); The latter needs to be modified to include (or be immediately followed by) Cedric's fix: - String rTextCopy = const_castlt;Stringamp;gt;(m_Text); + String rTextCopy = m_Text.Copy( ); which is reattached here from an earlier post on dev-list -- [REVIEW] fix for fdo#37584 [(Redlines Erased By Word Count) == 3.4 Blocker] http://nabble.documentfoundation.org/file/n3093766/0001-fdo-37584-Make-a-real-copy-of-the-text-where-to-coun.patch 0001-fdo-37584-Make-a-real-copy-of-the-text-where-to-coun.patch I distinctly recall thinking that the word count process was making an extra copy of the string in this upper word count level and the lower text node/iterator levels. It was my stupid mistake to do this 'optimization' in word count where no effect on the document text is a mandatory requirement -- in fact my 'extra copy' idea may have been a misreading of what went on further down in the code. Very much better to not do the shallow copy, thereby keeping redlined and hidden text. I also note that the shallow copy was already in place at the time of the particular patch attached to the OP. There is no deep copy in the lines replaced by the OP patch dated 2010.11.02: - String aOldStr( m_Text ); - String rCastStr = const_castlt;Stringamp;gt;(m_Text); There were a few other commits in the word count area in late October - early November 2010. Perhaps there is another missing patch? I will use this area as a case for practice with git log/rev-list and lo-commit-stat.pl At the very least, I will search commit logs for patches by myself and Mattias Johnsson. Many thanks for bringing this up Korrawit. LeMoyne -- jlc -- View this message in context: http://nabble.documentfoundation.org/PATCH-Fix-for-fdo-30550-Character-count-without-spaces-tp3092043p3093766.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Fix for fdo#30550 Character count without spaces
Attached is another patch (in libs-gui repo) that is in 3.4 but not in 3.3
found with lo-commit-stat using:
root/bin $perl lo-commit-stat --log-dir='./' --log-suffix='mjWCRL-3.3'
--rev-list ../ --until='2010-12-01' --author='Johnsson'
origin/libreoffice-3-4 ^origin/libreoffice-3-3
and shown more directly by rev-list using:
root/clone/libs-gui $ git rev-list --after='2010-10-01'
--before='2011-01-01' --pretty=medium origin/libreoffice-3-4
^origin/libreoffice-3-3 ../../bin/libs-gui-rev3.4to3.3.log
A search through the result for 'Mattias' gives:
commit cb9aa439fbb0a85829b1e61e292b1553512b0cb5
Author: Mattias Johnsson lt;m.t.johns...@gmail.comgt;
Date: Thu Nov 4 23:25:02 2010 +1100
An opening quote should not be counted as a word by word count tool
Patch file:
http://nabble.documentfoundation.org/file/n3094191/0001-An-opening-quote-should-not-be-counted-as-a-word-by-.patch
0001-An-opening-quote-should-not-be-counted-as-a-word-by-.patch
There is only one change in the patch:
+++ b/i18npool/source/breakiterator/breakiteratorImpl.cxx
...
+{UBLOCK_GENERAL_PUNCTUATION, UBLOCK_GENERAL_PUNCTUATION,
ScriptType::LATIN},
...
This addition to the (character class definitions?) stuff used by the break
iterator elegantly fixes the leading quote as separate word problem. The
power of that single line left me:
-- wondering why only the leading quote and not the trailing quote went as
a separate word (breakIterator wouldn't tell me ;-), and
-- wondering about any other effects that this insertion may have.
That said, if the symptom you are trying to fix is the 'leading quote as
separate word' then AFAIK this patch by Mattias Johnsson fixed that in the
master of late last year and in 3.4 from its birth to today.
From a similar progression in clone/writer, it *looks like* all of Mattias'
word count patches have been applied to 3.3. Since, 3.3 is counting with
and wthout spaces then Mattias writer patch was applied there (and I do
believe there is just one in writer ==
339eee93fd2a888b541eac4e7576d7091dfd1639). I do not have a code config
pointed at 3.3 so I cannot look directly at the word count routines there.
I am still at a loss as to why the redlining doesn't erase in 3.3 and does
in 3.4, given that the shallow copy + whiting out redlined text appears to
predate my patch and it appears to be present in 3.3 from looking at the
patches in 3.4. Perhaps 3.4 contains other changes or my testing is off or
there is a later deep/full copy or ...
Whatever else happens,
1-- If my patch attached to the OP goes into 3.3 then it should
***definitely be followed by Cedric's fix*** attached to my first response.
2-- Mattias' patch inserted above fixes the 'leading quote as word' problem.
Hope this helps
LeMoyne
--
View this message in context:
http://nabble.documentfoundation.org/PATCH-Fix-for-fdo-30550-Character-count-without-spaces-tp3092043p3094191.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Hackfest - September 9th, Ohio Linux Fest
Drew, I appreciate your position and your moderate, thoughtful questions and responses all across the several boards I have seen them on. I am still attracted to Apache and their OO project, but I finally balked on the proposal so clearly NOT written by a community or its representatives. My late and non-binding vote -- http://www.mail-archive.com/general@incubator.apache.org/msg29462.html Back to the subject of this thread, I am interested in participating in a HackFest and maybe even more interested if it has a QA focus. Distributed devlopment is tough, distributed QA needs definition and a lot of eyes on it. Sadly, I do not see a way to attend. From the mountain west, Ohio is only one order of magnitude closer than Europe and my car croaked last year. Please let me know of any virtual attendance or way to work in parallel that you devise. A distributed hackfest may pique more interest by the later LFs as well. Best Wishes, LeMoyne -- View this message in context: http://nabble.documentfoundation.org/Hackfest-September-9th-Ohio-Linux-Fest-tp3069282p3078108.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSOC] Report #3: Wizards
Caolan, Thanks for the potential shortcut. Sadly it did not work - I got the same failure (at least in terminal output). My master repo hasn't built yet this month and has suffered multiples of several different unit test failures and almost as many partial builds. I can see why the tests that die fail to clean up after themselves. Even though Xisco is on a different branch, I am ready to flush it all out and do a fresh build to eliminate the possibility of some unmanaged dependency tripping me up. Will do that later when I plan to be away from the computer. Thanks again, jlc -- View this message in context: http://nabble.documentfoundation.org/GSOC-Report-3-Wizards-tp3060259p3066951.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSOC] Report #3: Wizards
HI Bjoern, Xisco and all, =After smoketest fails in master like so: officeconnection.cxx:140:Assertion Test name: N12_GLOBAL__N_14TestE::test setUp() failed - equality assertion failed - Expected: 2 - Actual : 0 Failures !!! Run: 1 Failure total: 1 Failures: 1 Errors: 0 (which looks like failure to connect to soffice) * * with additional message (from gdb) in a message box: * * The application cannot be started. loading component library failed: file:///home/jlcastle/LibOdev/skky/solver/350/unxlngi6.pro/installation/opt/program/../basis-link/program/liboffaccli.so * =attempt to run soffice from solver fails like so: (no root/install symlink available) ~/LibOdev/skky/solver/350/unxlngi6.pro/installation/opt/program$ ./soffice LibreOffice: Using system memory allocator. LibreOffice: This is for debugging only. To disable, LibreOffice: unset the environment variable G_SLICE. LibreOffice: Using system memory allocator. LibreOffice: This is for debugging only. To disable, LibreOffice: unset the environment variable G_SLICE. terminate called after throwing an instance of 'com::sun::star::loader::CannotActivateFactoryException' * From bug 37290, this commit http://cgit.freedesktop.org/libreoffice/components/commit/?h=feature/gsoc2011_wizardsid=264c9ed93f3d338f6aee84310135569710705783 seems to be in master as well (from switching branch selector at cgit.freedesktop) Will keep working to get ure symbols into the gdbtrace.log for specifics from connector.uno.so, uuresolver.uno.so, unoexceptionprotector.so, etc. smoketest gdb log in pastebin -- http://pastebin.com/bKt0Uvnv -- jlc -- View this message in context: http://nabble.documentfoundation.org/GSOC-Report-3-Wizards-tp3060259p3064225.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSOC] Report #3: Wizards
Actually not at all sure where to clean+build to get missing uno symbols in the log Looks like an assortment of dirs may be involved Help would be appreciated as it is ~necessary for me to proceed here. -- jlc -- View this message in context: http://nabble.documentfoundation.org/GSOC-Report-3-Wizards-tp3060259p3064324.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] development summary: year 2011, week 23
Hi Petr, I was thinking about cranking through the past emails like this one and generating Development Summary pages on the wiki by hand. Then I discovered the related easy hack -- http://wiki.documentfoundation.org/Development/Easy_Hacks_Complete_List#Weekly_summary_.2F_Release_summary I am now looking at adding a -w=-ww (weekly wikify) option to lo-commit-stat that would generate a suitable weekly wiki page entire. Then only the page creation is manual labor that I can look forward to. I see from the wiki that the bug number handling could be more powerful, there may be ways to look more deeply at the commits and the resulting bug numbers on the Wiki should be links back to the related bug @ xxx. There is also the extraction of commits common to all repos. I assume that you wrote lo-commit-stat... Anything else that should go into -wikify? Any internal tips? What is standard week boundary here (i.e. Monday-Sunday)? Can I put a (c) TDF header on it? Thanks, LeMoyne -- View this message in context: http://nabble.documentfoundation.org/development-summary-year-2011-week-23-tp3058199p3060991.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] QA-hints ? - question for devs !
Hi Cor, I think the Weekly Development Summary might do what u want. It tends to slide by unnoticed because no one replies to it as they are all plowing straight ahead. Here is an easy way to find it... Go to top/thread view of dev list in Nabble -- http://nabble.documentfoundation.org/Dev-f1639786.html Enter 'development summary' (quotes not needed) into Search field (upper right) and click Search. In search result page switch view to 'last week' and click Go The one and only result is thus: http://nabble.documentfoundation.org/development-summary-year-2011-week-22-td3029190.html Download the attachment(s) for the build you want to test from Petr's summary. Here are the 3.4 bug fixes for 2011 week 22: + artwork + replace OOo icon to LibO icon (fdo#33229) [Andras Timar] + replace OOo icons to LibO icons in Tools - Options dialog (fdo#33229) [Andras Timar] + calc + fix for Insert sheets in a protected spreadsheet document (fdo#37772) [Markus Mohrhard] + fixed selection by arrow keys around merged cells. (fdo#34214) [Kohei Yoshida] + components + fix for Keyboard navigation broken in tools - options (fdo#37761) [Andre Schnabel] + extras + replace StarOffice icons to LibreOffice icons in Web Wizard (fdo#33229) [Andras Timar] + impress + add sanity check before dereference, (bnc#694119) [Tor Lillqvist] + libs-core + fix for bug (fdo#37590) [Noel Power] + replace seagull icons to LibreOffice icons (fdo#37617) [Andras Timar] + libs-extern-sys + update: Brazilian portuguese spelling dictionary hyphenation (fdo#37671) [Andras Timar] + writer + band-aid for immediate crash in IsAlignPossible (rhbz#710004) [Caolán McNamara] + fix one of the crashes in wizards (fdo#36306) [Jan Holesovsky] Hope that helps... LeMoyne -- View this message in context: http://nabble.documentfoundation.org/QA-hints-question-for-devs-tp3051408p3054159.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Master build Seg faults in starmath test
Caolan, I saw your related posts here and on bug 37668. You have an amazing eye to spot that very not obvious sign extension error as the difference between 64 bit OK and 32 not OK. Thanks for making the connection explicit here. My first attempt failed (later?) in tail_build within cppucheck for filters. After going back to num-cpus=1 the build completes just fine. Now smoketest fails in dev-install which is clearly a separate issue with a simple workaround. I understand that I can actually build and test forward looking work in master now. \o/ yay \o/ I have multiple projects going ATM but I look forward to looking at the smoketest failure in particular and the cppu unit tests in general as well. - tysm -- jlc -- View this message in context: http://nabble.documentfoundation.org/Master-build-Seg-faults-in-starmath-test-tp3020219p3050224.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] fix for fdo#37584
Cedric, I apologize for the time cost for you to dig this up. I do remember removing a string copy (or maybe two?). I should have clearly seen the need for a full copy after digging into the counting process and seeing the changes it made to the string in order to count excluding hidden or redlined, Definitely my bad for not testing more use cases (redlining). I will go back and review my work in this area. I see that this is marked as a regression against 3.3.2 and yet the word count work was well over 6 months ago. I had thought that word count w/ and w/out spaces had rolled out prior to 3.3.2 Perhaps the problem exists (undiscovered) in 3.3.2 as well. jlc -- View this message in context: http://nabble.documentfoundation.org/REVIEW-fix-for-fdo-37584-tp3038258p3039644.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] fix for fdo#37584
Test with LibreOffice 3.3.2
OOO330m19 (Build:202)
tag libreoffice-3.3.2
shows that Changes-Record does not produce redlining there either
I feel sick
jlc=={*-P}
--
View this message in context:
http://nabble.documentfoundation.org/REVIEW-fix-for-fdo-37584-tp3038258p3039788.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Master build Seg faults in starmath test
here is entire log of output in pastebin - I apologize for inlining it earlier http://pastebin.com/E4XuVt0M jlc -- View this message in context: http://nabble.documentfoundation.org/Master-build-Seg-faults-in-starmath-test-tp3020219p3020979.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Work Flow Inquiry
Hi all, I did some work on LibreOffice in late 2010. Returning now I see that the timed release schedule has created several branches that correspond to the various release configurations. All well and good. The issue I am experiencing is related to the various issues with standard functionality in the Basic IDE: https://bugs.freedesktop.org/buglist.cgi?cmdtype=runnamednamedcmd=Basic%20IDE [Search for bugs with component BASIC ann Summary contains Ctrl OR IDE] The fixes in this area seem to be done and applied only in 3.4 rc2. From looking in other areas of work on rc2, I think I am seeing the same patching pattern where the rc is ahead of master. And AFAIK they are all about to roll back to master. This leaves me with a bit of a quandary: Do I switch to 3.4 rc branch because that's where the action is? Or do I patch my version of master so I can work there? Or do I make a request through the list for patching back to origin/master? Or should I just wait for the merge? I know that I often make things more difficult than they really are, but I am at a loss as to which is best/recommended way to proceed here and now. *** It seems that just about any patch applied to the current release candidate branch should also be applied to master, except where the patch is a workaround in an area that is under active and related development in master. *** A drawback is more work for those who push the patches. I am quite willing to resubmit existing rc patches in my area(s) of interest but this is ad hoc and prone to omission and still extra work for those who push patches. A benefit is something I read on the list a while back that said the rc merge back to master essentially becomes a no-op(less work at merge). Another real benefit is that people who are uncertain enough not to patch the rc can follow along in master, learn and maybe contribute effectively sooner. As someone who is still new to open-source development, AFAIK the usual work flow is to work in dev master unless specifically trying to fix critical+high importance in the release candidate. The current divergence leaves the master behind the rc branch in various ways/areas which feels odd to me and appears to create extra work for 'somebody', i.e. everyone. Please advise LeMoyne -- View this message in context: http://nabble.documentfoundation.org/Work-Flow-Inquiry-tp2999412p2999412.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSOC] Java Python, problem with uno.invoke
Hi Xisco, I think your Java-Python porting project is awesome. My experience is thin on many counts here: Java, Python, pyuno and LibreOffice, but I have been curious about them all, so I dove in a little on your question. My short answer of encouragement: Yes, you can solve it! One question is how are you treating PropertyValue? If PropertyValue can still be either boolean or a list of strings (in your Python as in the Java) then your initial test If PropertyValue: may prevent setting *any* property to false. I think this safety check is moot anyway: Python will complain and quit before calling the setControlProperty function with nothing as the third argument object. I see that the invoke call is new - nice to see the setControlProperty function actually setting the property on the control ;-) I think the path that call takes is through the extern C static invoke at: http://opengrok.libreoffice.org/xref/ure/pyuno/source/module/pyuno_module.cxx#596 through PYUNO_invoke at: http://opengrok.libreoffice.org/xref/ure/pyuno/source/module/pyuno.cxx#335 where it seems that the Any wrapper is optional (!!). If you do pass PYUNO_invoke a tuple of Anys it just unpacks them before making a call like: object.name(tuple of args) I see that the Any wrapper is required to make calls through the Adapter::invoke here: http://opengrok.libreoffice.org/xref/ure/pyuno/source/module/pyuno_adapter.cxx#194 --- but I'm sure you are not calling that invoke as it has a very different signature. The extern C static invoke function requires the third arg to be a tuple, so I think it is sufficient to test for tuple type and then make the singletons a tuple of 1 before the invoke call. Finally, from the way PYUNO_invoke turns the ControlName and PropertyName into the callable function object, I think that passing the PropertyName as the second argument is sufficient - it doesn't need to go in the tuple as well. My understanding is that Java needs the Any foo to pass both simple types and objects as generic objects whereas everything in Python is an object so ... your Python glue code may often be simpler than the original Java. Please remember I'm no expert -- I just spent a few hours on this to start to dig into pyuno while doing a full LibreOffice build ... Hope This Helps, LeMoyne -- View this message in context: http://nabble.documentfoundation.org/GSOC-Java-Python-problem-with-uno-invoke-tp2994887p2995406.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Crazy Ideas] Discuss
I like the idea of replacing the internal regexp in favor of a more fully developed regexp evaluator. The goal should be to get rid of the weaker regexp module. A question I don't know how to answer is which is the best replacement. As Thorsten points out, ideally the replacement should be enabled for localization and transliteration - again more stuff I don't understand well at all. However, looking at textsearch.cxx in Open Grok -- http://opengrok.go-oo.org/xref/libs-gui/i18npool/source/search/textsearch.cxx#165 -- can see this comment before the various types of calls to a search routine: // use transliteration here, but only if not RegEx, which does it different One can also see other exclusion of the regexp search algorithm from the transliteration search prep and search result code in textsearch.cxx around the calls to the search routines, but I'm not absolutely sure that exclusion is complete. If the regexp search truly *never* uses transliteration then the swap out will be simpler and the change-over may actually enable transliteration. I haven't looked at the internal code of the regexp - perhaps it 'does it's own thing' internally for transliteration... -- View this message in context: http://nabble.documentfoundation.org/Crazy-Ideas-Discuss-Replace-regexp-parser-with-std-library-tp1974632p1989646.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [all PUSHED] Re: [PATCH 7/7] remove shadowing warnings in binfilter - sw_sw3npool.cxx
Pierre, One thing to look out for in longer subroutines is that a variable will be setup at the top of a subroutine and some one will later duplicate its declaration and initialization near the end. In that case, the second vars decl and init can simply be deleted. -- LeMoyne -- View this message in context: http://nabble.documentfoundation.org/PATCH-1-7-warning-cleaing-binfilter-sw3io-tp1981476p1981939.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] More links inherited from OOo
Thanks for giving Libre Office it's very own readme. One thing that popped
out at me from the Getting Involved section was this: familiarize yourself
with many of the topics covered since the ${PRODUCTNAME} source code was
released back in October 2000. I dunno if you want OpenOffice for a
product there or a 2010 date on LibreOffice code release.
Tried it in a browser and the links don't work -- yet. Looks good - thanks
again.
LeMoyne
--
View this message in context:
http://nabble.documentfoundation.org/More-links-inherited-from-OOo-tp1909555p1958085.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] script providers as extensions
Hi David, Just a few notes: -- The BeanShell, Javascript and Python options have disappeared cleanly from the Tools-Macros-Organize menu. -- I expect that the Help will need updating to reflect the fact that these are now options and to explain how to bring them back for people that 1) have established macros in these languages and 2) want to migrate to LibO. -- I have been having app crashes from those menu options and from Macros-Run (building on Ubuntu 10.04) and I have been trying to stop the boo-boos using the --without-system-python option. I am now thinking that you caused the compilation/linking that I needed to have the crashes stop because the menu is now safe for me Thanks -- LeMoyne -- View this message in context: http://nabble.documentfoundation.org/script-providers-as-extensions-tp1874992p1876675.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Fix bug where an opening quote mark is treated as a word
Noel Power wrote: No, I don't mean setting up an OOO build ;-) but just checking against a OOO330m13 dev build ( that can downloaded from openoffice.org ) OIC, I was making it too hard - rooted around at OOo and found the debs... Thanks -- LeMoyne -- View this message in context: http://nabble.documentfoundation.org/PATCH-Fix-bug-where-an-opening-quote-mark-is-treated-as-a-word-tp1841260p1868658.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Fix bug where an opening quote mark is treated as a word
Noel Power wrote: I wonder if the recent rebase to OOO330m13 is the culprit, would be interesting if you could test against the corresponding oracle dev build Yes, I see that test would be useful. Not about to setup an OOO build, but will consider it if you think that would be useful with the VBA work. Cedric Bosdonnat wrote: Just some random thought here: would you be able to write some unit tests for this? Not yet but I will gain that ability (maybe soon)... Cedric Bosdonnat wrote: As a separate potential issue: In a fresh current dev build with AutoCorrect on for single double quotes the Apply While Typing modified them into the selected special symbols (Tools-AutoCorrect-Localized Options Tab). But I could not get the Format-AutoCorrect-Apply to change either the whole doc or a selection. ... Did you try erasing the user settings folder to reinit the options there? I did not try 'erasing the user settings folder' - it's on the list now. Does testing potential bugs in 1) dev master, 2) OO3.2 (for Ubuntu Lucid) and 3) LibO Beta 2 seem useful or overkill? Of course, it depends... -- LeMoyne -- View this message in context: http://nabble.documentfoundation.org/PATCH-Fix-bug-where-an-opening-quote-mark-is-treated-as-a-word-tp1841260p1868528.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Fix bug where an opening quote mark is treated as a word
Hi all, Ok, after getting over a short-term dislike of Word Count - with a new found appreciation for some of the developer comments in OOo issuezilla - I had a new idea for a test plan. Perhaps turning on the Scanner clipping has *accidentally* fixed the quote problem as well. Although I intended to make no changes within the SwScanner -- the two changes at issue are small: Mattias fix of specifying the ScriptType for the fancy punctuation is one initializer in an array, and the Scanner clipping on/off is a Boolean true/false parameter on the SwScanner constructor. So hoping for quick clarity, I backed out both changes. Of course the plan fell apart at step 1) - can see the packaging of core-04 involving libswli.so and core-05 involving new i18npool.so - also did full rm-Rf install and make dev-install to make sure I get the new stuff. - both changes removed - Still no 'leading special quote extra word' [LSQEW] problem with quotes from an existing file or quotes newly inserted into a doc. Get LSQEW on Oracle OOo 3.2 Linux on Lucid. Get LSQEW on LibO Beta2 on Win Vista. I can not recreate it in dev. In case some other change in CountWords fixed it I tried rolling the history back. After a bunch of git diff HEAD~dozens -- ./txtedt.cxx including a binary search to pin down the point just before our changes - a few weeks ago - I rolled CountWords back -40 with: git checkout -f HEAD~40 ./txtedt.cxx Saw the code as it was before any of our changes. Built soffice and ran but still no LSQEW. Know I built the old version txtedt.cxx because Char excl spaces was always zero. And selections across a leading special quote still always gave the 'correct' MSWord count. Looked further back ~200-500 and very few changes in CountWords (nParaAll++ insertion; 2 changes in TxtNode member names; change in ParaDataImpl_ WrongList type) . Did similar look back in history for the breakiterator file and few changes there as well. *Maybe a closer look at the scanner or the iterator will turn up something -- but further back than the copyright change not likely to help since it shows as broken in Beta 2 and in current OOo for Lucid from Ubuntu. If you try the 'go back machine' you may need to search a further back than 40 because of any commits to origin/master since my test (11/5). In this search it helped to step back partway before the last larger set of changes to be able to see the earlier changes. Easy to see far enough because the new field in ParaDataImplwhatever showed at the bottom of the diff. When done 'cleaned up' the local config with git checkout -f origin/master ./txtedt.cxx Still new to git but I am sure I saw and built and ran the old txtedt.cxx and still no LSQEW. Feelin' a bit lost ... I can think of some other options for trying to find what fixed the LSQEW but I feel like I'm chasing ghosts where they aren't. Maybe I have a magic bug eating build setup. I hope not -- that would make troubleshooting impossible ;-) Puzzled but not daunted -- LeMoyne -- View this message in context: http://nabble.documentfoundation.org/PATCH-Fix-bug-where-an-opening-quote-mark-is-treated-as-a-word-tp1841260p1851684.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Some hints about git please...
I'am very new to git (only have used sometimes 'git clone' before) , and I
don't get it very well...
I am brand new to git and I felt confused alot until I found this --
http://wiki.documentfoundation.org/Development#Using_Git_for_LibreOffice_development
-- this ref explains many things and gives the base reference for git --
http://git-scm.com/ -- Go there. The Quick Start workflow there is how
git is supposed to work. See the big tree eat all the little trees - cute
and incredibly effective. Git is source control but it is different: git
follows content not files - git produces a tree of different codebase
versions - other scms do something more like slices and versions on a single
branch. Old scm branch is work and a big deal - branching built into git.
1) I update the 'clone' directory often. No problem with that.
The rawbuild directory is almost entirely symlinks back to clone so even if
the code is accessed through rawbuild it is still the code under clone. Or
by update did you mean pull? I apologize if I offend or am no help. I am
replying to you because I feel that I have started to be able to use git and
I remember well my recent confusion. Probably the best I can do is refer
you to Dev wiki and scm workflow: they helped me get git in focus.
2) I've read that when updating 'clone', 'bin/g' must be run.I don't
find any 'g' in ./bin/.
The Development wiki page above gives the ga script. Get the scripts from
there into your bin directory. Then you can run ga checkout branch, hack
away here and there in modules, build, test, get happy then do ga status,
ga branch, ga commit - all from rawbuild and subdirs. ga lets you do the
git stuff for preparing/making a commit across the entire code base from
anywhere in the source tree. The ga command lets you do each git action
once for all - 'ga' is an all version of 'g' further improved by find-lo-bin
to work within any of several copies of the whole LibO multi-project source
tree.
3) I don't know how to update easily the source in
'build/libreoffice-3.2.99.2'
There are parts of three plans for work and build flow + working directory
in the LibO tree: past, present and future. It is being sorted out so
expect it to change (soon?) - but for now rawbuild is the intended home
base.
4) I edit code in 'clone/module' and 'git diff' from there but, for
building, I have to go to 'build/libreoffice-3.2.99.2/submodule' where I
have done a local git, modify the patch (paths are too long in it eg :
a/module/submodule -- a/submodule), 'apply' it, 'build', 'apply -R', and if
it's ok, get back to clone/module and undo my work (with the editor or with
'apply -R')
I am not sure what you are doing here - preparing a commit and then
pulling?. I am sure there is an easier way. Look at the basic workflow on
the scm site: it will work for you in LibO. When you can't pull because of
changes then either commit them if they are keepers or in the (sub)module do
git checkout rel-path-to-file to erase the changes or rest a touched file
that needed no change.
Doing ga checkout branch or ga checkout master can give you different
versions of the codebase. I have barely started to learn about and use
branches but already I like being on a branch better than working in master.
From a bug/brokestuff branch, with ga checkout master you can get right back
to a clean slate where you can checkout a codecleanup or feature/project
branch. Freedom to have Fun.
I see now that branches can be used to manage various sets of commits that
are in different development phases
('improve'/build/test/debug/rework/prepare/commit). I used to wonder why
there was not more info on managing a mixture of commits from different
projects: finally I get that branches keep them sorted so there is only a
local mess for a particular project to clean up at commit time. I should've
read more...
I hope this helps and is not too far off. Really - use the Dev wiki and scm
workflow. Another way git is different is that git was made by an excellent
developer for the purpose of organizing collaboration instead of being the
brainchild of packaging, qa or management to restrict the movement of code.
I know git should be easy and helpful when I git it down. I am just
starting to get git to work for me - but I am old and slow. I will be
reading/re-reading and reading further into the git man for some time yet.
Havin' a blast...
LeMoyne
JLCastle
--
View this message in context:
http://nabble.documentfoundation.org/Some-hints-about-git-please-tp1831160p1833798.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] regression tests - for word count ...
-Original Message- From: Michael Meeks [via Document Foundation Mail Archive] [ml-node +1834110-443277665-232...@n3.nabble.com] Sent: 11/3/2010 4:19:16 AM ... Wrt. re-doing the dialog layout - can you hold off on that - Ricardo is working now on some awesome new VCL layout capabilities, and will use the word-count as a first test-case of them. These fixes should help translators, and give us a prettier looking UI in due course, but worth not conflicting with him. Oh, gladly. You know I view word count as important: certainly it is valuable to those who use it to do basic project planning from estimation through assessment of progress to billing (translators, journalists, authors, medical coders, etc.). I want to see this done and done well. There are several small/med projects within a full, more competitive Word Count and the LibO UI is still pretty much a mystery to me - the newest is then the rumour of a mystery. I would have been iteratively changing point values in files for hours and gotten nowhere near the tabbed frame I think the count needs (controls; results + go btn). No problem at all. In fact, now I can look forward to learning the best way forward! Other elements of LibO have called me from (before) the start and I want to work on them (someday). A basic million-to-one shot will have to do for no elp right now. Here in counting there is still a stub/sketch back end and a start on gathering the best of all user input left ... oh yes and a regression/unit test framework at least -lol -like a dang tar baby - I touched it now I'm stuck! LeMoyne JLCastle PS No conflict ever intended or sought - clarity, coherence, effective collaboration are more rewarding and fun. span id=m2wTlpfont face=Arial, Helvetica, sans-serif size=2 style=font-size:13.5px___BRGet the Free email that has everyone talking at a href=http://www.mail2world.com target=newhttp://www.mail2world.com/abr font color=#99Unlimited Email Storage #150; POP3 #150; Calendar #150; SMS #150; Translator #150; Much More!/font/font/span -- View this message in context: http://nabble.documentfoundation.org/PATCH-Fix-for-bug-feature-request-30550-Character-count-without-spaces-tp1778667p1834365.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] Fix for OO Basic Million-to-one bug #i76852#
Adds '=' to edge test in sbxscan.cxx ImpCvtNum so exponent prints and 1 million is 1e+6 instead of just 1 for singles. Same one char change does similar fix for OO Basic doubles and 1e+14. When I saw #i76852# -- http://qa.openoffice.org/issues/show_bug.cgi?id=76852 -- describe how and when OOBasic prints as single with value 1 000 000 as 1 (with no million) I thought right off: edge case == missing equals. Using OpenGrok, I drilled in through the basic interface for the CStr() function. CStr() is implicitly called by print in the OOBasic interpreter when it needs to print a number. Straight away found these two lines in sbxscan.cxx ImpCvtNum method: double dMaxNumWithoutExp = (nPrec == 6) ? 1E6 : 1E14; myftoa( nNum, p, nPrec,( nNum ( nNum 1E-1 || nNum dMaxNumWithoutExp ) ) ? 4:0, The top line gives the two problem cases identified in #i76852 . The double type fails at the other number 100 000 000 000 000 = 1e+14. I added the equals to make the boolean clause true at 1 000 000 - (as: nNum = dMaxNumWithoutExp ) and OO Basic prints 1e+6 instead of just the one. Built and ran and now CSng(CStr(100)) = 100. Relative error down from ~1 (utter fail) to 1 ppm (as good as it gets for single). Absolute error down from 9 to 1 - a million to one reduction. Thought it was too easy and so reviewed the code to understand what that parameter exponent width = ( ( nNum ( nNum 1E-1 || nNum dMaxNumWithoutExp ) ) ? 4:0 ) was all about -- for numbers w/ abs value 1 or abs value = dMaxNumWithoutExp a non zero exponent width of four is passed to myftoa. In myftoa if zero width then no exp prints : hence 1 million became 1 (no million) without the equals. Grokked *some* of parser logic in myftoa. Wanted to check that nearby numbers (within round/trunc for single precision limit) weren't messed up so wrote macro in attached spreadsheet. In ods is macro M2one - does a check on all the numbers in the A column of singles sheet and generates (clobbers) values into cols B,C,D... Tested against OOo 3.2 (fail). Did not complete the double test at 1e14 in 2nd sheet+macro, but tested doubles with previous print macro and tested single and double against LibO dev yesterday (fail at 1e+14). If you try it and need to enable macros then re-load the worksheet after your settings change. Seems that the OO issue zilla is a good source of bugs to fix... Have fun, LeMoyne JLCastle http://nabble.documentfoundation.org/file/n1839430/0001-OO-Basic-Million-to-One-bug-i76852-fixed.patch 0001-OO-Basic-Million-to-One-bug-i76852-fixed.patch http://nabble.documentfoundation.org/file/n1839430/Million-to-one_SingleOnly_OOo3.2.ods Million-to-one_SingleOnly_OOo3.2.ods -- View this message in context: http://nabble.documentfoundation.org/PATCH-Fix-for-OO-Basic-Million-to-one-bug-i76852-tp1839430p1839430.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
