On Windows 7 sp1, 64-bit en-US with Version: 4.4.0.0.alpha0+ Build ID: 7f900e2e2f5faa0a568209791c57cb024f14fe33 TinderBox: Win-x86@42, Branch:master, Time: 2014-10-10_00:12:03 Calc suddenly having issues with drawing its screen--background, foreground and borders of cells are being painted black as cells on sheet are traversed with cursor movements. Data entered seems to be present, and renders as a Thumbnail view. An existing spreadsheet will open and can be manipulated.
Created attachment 107641 [details] newly created spreadsheet having drawing issues
Where did you find 10-10? I can only find 2014-10-06
Cannot reproduce: W7 w/ http://dev-builds.libreoffice.org/daily/master/win-x86@39/current/master~2014-10-06_01.02.02_LibreOfficeDev_4.4.0.0.alpha0_Win_x86.msi
(In reply to Joel Madero from comment #2) > Where did you find 10-10? I can only find 2014-10-06 http://dev-builds.libreoffice.org/daily/master/Win-x86@42/2014-10-10_00.12.03/ And yes everything was fine on the last TB39 build... Version: 4.4.0.0.alpha0+ Build ID: 9177329a425cf70b515d1f266132838894fe54c6 TinderBox: Win-x86@39, Branch:master, Time: 2014-10-06_01:02:02
On Windows Vista, I tried Version: 4.4.0.0.alpha0+ Build ID: 86a3fe47a66950e26d23d7d7f2680fa7d4fb0839 TinderBox: Win-x86@39, Branch:master, Time: 2014-10-05_02:45:20 Version: 4.4.0.0.alpha0+ Build ID: 7f900e2e2f5faa0a568209791c57cb024f14fe33 TinderBox: Win-x86@42, Branch:master, Time: 2014-10-10_00:12:03 Version: 4.4.0.0.alpha0+ Build ID: 276a046d5256b14478ab283f420654df6ae76b55 TinderBox: Win-x86@42, Branch:master, Time: 2014-10-08_00:21:52 with no visible problem. In each I created a new spreadsheet, ehntered data in a few cells, saved the file, closed the file, and opened the file. Stuart, Can you attach a spreadsheet for which you have rendering problem? Terry.
Created attachment 107668 [details] simple calc ODS document Calc is generating an ODS document, and calculating cell values--it has just lost its drawing interface for the actual table view.
Created attachment 107669 [details] screen clip of attachment 107668 [details] open in Calc
Created attachment 107670 [details] screen clip of Start Center -- showing the thumbnail of the ODS
Did a removal and fresh download, MD5/SHA256 hashes on both downloads match as libo-master~2014-10-10_00.12.03_LibreOfficeDev_4.4.0.0.alpha0_Win_x86.msi MD5 c733ba5e829c6354e0ecd6b89a8884df SHA-256 21211271e06f43c7e6696a4bd6c4d876265ffba343a46d9ea884a4e0495fdfa2 Performed another /A administrative install, and configured in parallel. Exactly same results if creating a new ODS, or working with test ODS posted. Everything else seems OK, but just the drawing of the Spreadsheet elements are not refreshing with this build on Windows 7 sp1, 64-bit en-US. Something affection Calc only, so it is weird.
Thanks for the link V Stuart Foote: Confirmed: Windows 7 Version: 4.4.0.0.alpha0+ Build ID: 7f900e2e2f5faa0a568209791c57cb024f14fe33 TinderBox: Win-x86@42, Branch:master, Time: 2014-10-10_00:12:03 Reproducible steps: Open LibreOffice Create new sheet. Immediately notice black boxes, inability to use spreadsheet correctly. Adding to 4.4 mab.
Andrzej - have we merged our calc / tiled rendering goodness yet ? =)
Not reproducible for me with Version: 4.4.0.0.alpha0+ Build ID: 96adec2fd56d1ca09d679c0966567c674d812dfb updated few hours ago and built at home under Ubuntu 14.04 x86-64 Best regards. JBF
On Windows 7 sp1, 64-bit en-US with today's TB42 build Version: 4.4.0.0.alpha0+ Build ID: 7dc6c9af4ba313f054331f5130470d83d875bc16 TinderBox: Win-x86@42, Branch:master, Time: 2014-10-11_13:41:48 http://dev-builds.libreoffice.org/daily/master/Win-x86@42/current/ Issue reproducible for repainting the display of the spreadsheet table which seems to otherwise be functional.
With Windows Vista running Version: 4.4.0.0.alpha0+ Build ID: 7f900e2e2f5faa0a568209791c57cb024f14fe33 TinderBox: Win-x86@42, Branch:master, Time: 2014-10-10_00:12:03 and file "Loss-management-benchmarking Rev 1 (2).xlsx" attached to bug 94024 <https://bugs.freedesktop.org/attachment.cgi?id=107727>, the program blacks out each cell as it is selected. The blackness remains as the selection moves on. As before, I still see no problem with the .ods attached to this bug report. Terry.
I can confirm these issues too under both Linux and Windows. I've narrow it down to: Move this one to a common place too. http://cgit.freedesktop.org/libreoffice/core/commit/?id=9aa36a1ad39e37c372cc833a44fba450b8cc30cd - Good vcl, sd: fix some TempFile leaks from vcl Graphic in cppunit tests http://cgit.freedesktop.org/libreoffice/core/commit/?id=7f900e2e2f5faa0a568209791c57cb024f14fe33 - BAD
On Windows 7 sp1, 64-bit en-US TB39 off line from 6th (which was correct), checked TB42 and no drawing issue through the 2014-10-09 build, so a regression somewhere in http://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=9aa36a1ad39e37c372cc833a44fba450b8cc30cd..7f900e2e2f5faa0a568209791c57cb024f14fe33 -=OK=- Version: 4.4.0.0.alpha0+ Build ID: 276a046d5256b14478ab283f420654df6ae76b55 TinderBox: Win-x86@42, Branch:master, Time: 2014-10-08_00:21:52 Version: 4.4.0.0.alpha0+ Build ID: 9aa36a1ad39e37c372cc833a44fba450b8cc30cd TinderBox: Win-x86@42, Branch:master, Time: 2014-10-09_03:25:27 -=Goes Bad, loss of calc table rendering=- Version: 4.4.0.0.alpha0+ Build ID: 7f900e2e2f5faa0a568209791c57cb024f14fe33 TinderBox: Win-x86@42, Branch:master, Time: 2014-10-10_00:12:03 Version: 4.4.0.0.alpha0+ Build ID: 7dc6c9af4ba313f054331f5130470d83d875bc16 TinderBox: Win-x86@42, Branch:master, Time: 2014-10-11_13:41:48 Terry E.'s linked attachement 107727 .XLSX opens without issue with the TB42 builds from 2014-10-08 & 09, but then has the same drawing issue with TB42 builds for 2014-10-10 & 11. So issue is not affecting just .ODS format. Also, existing .ODS documents render correctly through the TB42 build on the 9th, but fail for build from 10th or 11th.
I've further narrowed it down to: As of JDK version 1.5, show() and hide() in Dialog have been deprecated http://cgit.freedesktop.org/libreoffice/core/commit/?id=14cccfab8111c61bf6707eef423abe79e95f5572 - BAD So the new range is http://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=9aa36a1ad39e37c372cc833a44fba450b8cc30cd..14cccfab8111c61bf6707eef423abe79e95f5572
Remains an issue with TB42 builds of master, and TB39 is off line. Version: 4.4.0.0.alpha0+ Build ID: c967872d46a7cfd7c52063068313d5ec0356453e TinderBox: Win-x86@42, Branch:master, Time: 2014-10-13_00:02:37
I have tracked down the first bad commit to "fdo#81356: convert Fraction to boost::rational<long> - wip" http://cgit.freedesktop.org/libreoffice/core/commit/?id=47a2d7642d249d70b5da0c330a73f3a0032e4bba Juan, can you please look into this?
(In reply to Luke from comment #15) > I can confirm these issues too under both Linux and Windows. I've narrow it > down to: So, what are the exact steps / settings / etc. to reproduce this? I see no problem with my Linux build.
Literally 1: start libreoffice 2: Start calc 3: Try doing anything Immediately black is seen and the black grows. I've only confirmed on Windows with the link provided in comment 4
Well, it is affecting TB39 debug builds as well. Version: 4.4.0.0.alpha0+ Build ID: c862be08158f502c42752f025d5cc6384285c688 TinderBox: Win-x86@39, Branch:master, Time: 2014-10-13_14:55:05
Created attachment 107787 [details] WinDbg StackTrace -- ~* k of Calc session launch On Windows 7 sp1, 64-bit en-US Stack Trace for WinDbg (6.3.96000.16384 x86) of TB39 debug build Version: 4.4.0.0.alpha0+ Build ID: c862be08158f502c42752f025d5cc6384285c688 TinderBox: Win-x86@39, Branch:master, Time: 2014-10-13_14:55:05 Launch of LO from soffice.exe, attach to soffice.bin and issue WinDbg command: sxe -c "!pe;g" clr Open a new Calc document. Cursor R movement A1 -> A2 Then capture trace of all threads with WinDbg command: ~* k
Created attachment 107788 [details] WinDbg stack trace after LO session end Just tail end of WinDbg session following
Created attachment 107789 [details] Stack Trace of sb xstor call assertion fail Sorry for the noise of attaching another Stack Trace, but guess there is some chance that bug 84911 and this bug are related. I just got another stack trace that looks very similar to crash of Draw when sidebar view is open. Get an Assertion failed in xstor.dll reference.h at line 402 sblo!basic::SfxLibraryContainer::init_Impl --namecont.cxx-- See attached WinDbg trace... Coincidence, or maybe just being attached to the Debug session? http://cgit.freedesktop.org/libreoffice/core/commit/?id=fca62934f492125ea6728fd6d09f0c66c9e4fa69
(In reply to V Stuart Foote from comment #25) > Sorry for the noise of attaching another Stack Trace, but guess there is > some chance that bug 84911 and this bug are related. They are not. The description of bug 84911 says it happenewithon build from Oct 8 already. The Fraction->boost::rational change that caused this bug has been pushed on Oct 9.
Created attachment 107816 [details] Non trivial changes in "fdo#81356 .." 47a2d764
Hi! Due that the commit "fdo#81356: convert Fraction to boost::rational<long> - wip" http://cgit.freedesktop.org/libreoffice/core/commit/?id=47a2d7642d249d70b5da0c330a73f3a0032e4bba is a long one, i attach a file with the non trivial modifications ( https://bugs.freedesktop.org/attachment.cgi?id=107816 ) I did a visual inspection of changes under sc module and only found trivial replacements. Note that due the old Fraction class allows the use of invalid rational values the problems can exists in another places than the listed in the attach
Saw that David T. had poked at the fraction rational code, unfortunately thus far that is not the issue for the screen drawing with calc... Still an issue on Windows 7 sp1, 64-bit en-US with Version: 4.4.0.0.alpha0+ Build ID: defa080e585fb351bc4049b2f280d2e7e5256f6e TinderBox: Win-x86@39, Branch:master, Time: 2014-10-15_00:35:53
I need to use a build after 10/11, because of Bug 84647, but Calc has been hosed by this issue. If you don't have a fix in the pipeline (I see nothing in gerrit), please undo commit 47a2d7642d249d70b5da0c330a73f3a0032e4bba so the rest of us can use Calc again. Confirmed on Win 7 32 bit Version: 4.4.0.0.alpha0+ Build ID: defa080e585fb351bc4049b2f280d2e7e5256f6e TinderBox: Win-x86@42, Branch:master, Time: 2014-10-15_01:10:51 AND my own build on 10/14 on Ubuntu 14.10 hardware: dual core P4 3Ghz with ATI Radeon HD 4250
...we're not going to make special accommodations so a single user can use daily builds. http://joelmadero.wordpress.com/2014/10/11/user-expectations-and-the-reality-of-our-community/
Joel, How are QA members supposed to do their job if developers commit patches that make major components unusable without even a fix in the pipeline? How long should any single developer be allowed to break master? We're going on a week now. A month, a year? Your blog is about demands. I did not demand. I made a suggestion with a "please" saying IF they did not "have a fix in the pipeline". How is this unreasonable? I have now reproduced this bug on a Win 8 laptop, Win 7 desktop, and Ubuntu 14.10 desktop. In addition, it seems this bug is reproducible by everyone here once they started using builds after 10/10, except oddly the commiter. And by the way, this includes you. See Comment 10 So, NO, this is NOT about special accommodations for a SINGLE USER. This is about everyone, including the entire QA team of volunteers who can't do their job, because a major component is completely broken.
(In reply to Joey Reid from comment #32) > [...] In addition, it seems this bug is reproducible by everyone > here once they started using builds after 10/10, except oddly the commiter. I do not reproduce the problem on my own build under Ubuntu 14.04 x86-64. even when I install my build on another PC under Xubuntu 14.04 x86-64 with a Unity session. Best regards. JBF
Can anyone reproduce this with 64-bit build? And reciprocally, is there anyone who does not reproduce it with 32-bit build?
I can reproduce this bug with a core T2400 CPU and ATI X1400 laptop under both Win 7, Mint 16, and Ubuntu 14.4. What GPUs do people who can reproduce this have? Could this be an ATI/AMD issue? For those with Linux who can't reproduce it, what happens when you test it from a 32-bit install such as a bootable USB flash or VM?
I reproduce it under Win7x64 with a NVidia GeForce 9300M GS GPU NB9M
Ubuntu 14.04 x64 with Intel graphics card
David T., *, Reproducible on On 32-bit Fedora20 (VMWare Workstation 10.3, nVidia Quadro K2000) Version: 4.4.0.0.alpha0+ Build ID: 3b6ee58652d99accd610425264114d1d5b3330df TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:master, Time: 2014-10-15_21:41:26 Not reproducible on 64-bit Fedora20 (VMWare Workstation 10.3, nVidia Quadro K2000) Version: 4.4.0.0.alpha0+ Build ID: 7f71e99e3f35e7b94aa426f588276d05bf86bf09 TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-10-16_07:55:06 So, always producible on 32-bit, not producible on 64-bit. GPU for 32-bit no impact (Intel, AMD, nVIDIA), all fail.
On Fedora 20, 32-bit with LXDE DE spin (VMWare Workstation 10.0.2, nVidia GTX260) Prepped with a yum install of libreoffice 4.2.6.3 for any dependencies. Confirmed issues with this DE and build for Calc window repainting with prior TB45 builds Version: 4.4.0.0.alpha0+ Build ID: 3b6ee58652d99accd610425264114d1d5b3330df TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:master, Time: 2014-10-15_21:41:26 A test of today's 32-bit build from TB45 (with David T's additional work on the 32-bit Long and BigInt). No joy--the Calc screen paint issues remain. Version: 4.4.0.0.alpha0+ Build ID: c68642d535f2ebb7f1cd866ad19b1fd018e7cd6d TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:master, Time: 2014-10-18_23:03:32
*** Bug 85226 has been marked as a duplicate of this bug. ***
I had noticed this last week and thought i'd leave it and see if it gets fixed itself but didnt, so i reported a duplicate bug. :) From my linux testing on the available daily builds, it is fine in Version: 4.4.0.0.alpha0+ Build ID: ce5cc7afb0f1c99237d04e0c754527c725d8491c TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:master, Time: 2014-10-06_19:35:48 and broken in Version: 4.4.0.0.alpha0+ Build ID: 227ca23324fabd77abae1b7eb6186ba11d519fae TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:master, Time: 2014-10-09_14:20:58 Unfortunately, there isnt any 7th and 8th october builds to track it down more.
bibisected (comment 17 comment 19)
The 4.4 bibisect should be out late next week to early the week after that. It would be fantastic if we could get a bibisect as soon as that comes out (assuming this isn't fixed in the meantime)
Not reproducible on OSX 10.10 Version: 4.4.0.0.alpha0+ Build ID: d807cba9ee60cb1404b54addf9cd3e54de89f331
*** Bug 85288 has been marked as a duplicate of this bug. ***
Jphilips and Joel, There is no need to track anything down or bibisect. I manually, commit by commit, tracked this down to "fdo#81356: convert Fraction to boost::rational<long> - wip" http://cgit.freedesktop.org/libreoffice/core/commit/?id=47a2d7642d249d70b5da0c330a73f3a0032e4bba A major component, Calc, has been unusable for almost 2 weeks now in all Windows builds and 32-bit Linux builds. May I respectfully request that we revert the patch so we can all use Calc again? Once this extremely critical bug has been resolved on a private branch, they can always reintroduce it.
Luke, *, (In reply to Luke from comment #46) > Jphilips and Joel, > There is no need to track anything down or bibisect. I manually, commit by > commit, tracked this down to > > "fdo#81356: convert Fraction to boost::rational<long> - wip" > http://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=47a2d7642d249d70b5da0c330a73f3a0032e4bba Guess I was not clear enough regards comment 17 and comment 19 bisect identification of the issue. Sorry Joel. > > A major component, Calc, has been unusable for almost 2 weeks now in all > Windows builds and 32-bit Linux builds. May I respectfully request that we > revert the patch so we can all use Calc again? Once this extremely critical > bug has been resolved on a private branch, they can always reintroduce it. At this point, David and Juan have been on task and look to be closing in on the issue with SC drawing layer http://cgit.freedesktop.org/libreoffice/core/commit/?id=166eaf213b3d43e54f2f5206d9680f75f720847f Suggest we see how that goes before any serious consideration of reverting things, Juan's boost::rational work will result in more stable and maintainable code going forward--this impact on 32-bit builds has been just an annoying hiccup.
This issue is still reproducible on Version: 4.4.0.0.alpha1+ Build ID: d0be09322d127e7d517851db38c764d57fbab2dc http://cgit.freedesktop.org/libreoffice/core/commit/?id=d0be09322d127e7d517851db38c764d57fbab2dc comes after David's last patch and the issue is still not resolved. Could we please start the discussion over the pros and cons of reverting commit 47a2d7642d249d70b5da0c330a73f3a0032e4bba? If Juan and David can't get this resolved soon, I think it's best for them to work off of a private branch.
@Luke, noticed the summary change, so where can one get a 64-bit Windows build of LibreOffice? ;) This issue affects only 32-bit builds--done for Windows and Linux. And if we were still rolling 32-bit builds of master for OS X (TB 49) suspect it would be present there as well. FWIW yes still with us in todays TB39 32-bit debug build for Windows Version: 4.4.0.0.alpha1+ Build ID: 9ecac3874d179b1d7aa6b45337001b1def06a9dd TinderBox: Win-x86@39, Branch:master, Time: 2014-10-22_06:32:56
Confirmed on : Version: 4.4.0.0.alpha1+ Build ID: a8c24b25fd9fb21097a08a22797bf61b59099ea1 TinderBox: Win-x86@42, Branch:master, Time: 2014-10-21_06:31:17 Bernard
I just discovered this today on Windows. Calc looks fine when you set the zoom level at 82% or below. Anything above that and the repaint starts to behave whacky.
(In reply to Kohei Yoshida from comment #51) > Calc looks fine when you set the zoom level at 82% or below. Actually change 82 to 75. at 75% zoom level Calc looks normal & scrolling appears to repaint correctly, though it still does wrong repaint here and there...
(In reply to Kohei Yoshida from comment #52) > > > Calc looks fine when you set the zoom level at 82% or below. > > Actually change 82 to 75. at 75% zoom level Calc looks normal & scrolling > appears to repaint correctly, though it still does wrong repaint here and > there... Similar result with an affected 32-bit Linux build, at 75% the screen drawing is close to normal. But still glitches--like opening the Help --> About LibreOffice dialog which leaves residuals. Version: 4.4.0.0.alpha0+ Build ID: c68642d535f2ebb7f1cd866ad19b1fd018e7cd6d TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:master, Time: 2014-10-18_23:03:32
Created attachment 108271 [details] capture of 1024x768 screen, after zooming from 65% to 95% With the mention of zoom factors in comments 51, 52, and 53, I see something that I find interesting. On my Toshiba Satellite model P200D-FT6 running Windows Vista SP2 32-bit, the system tray has an icon with initials "ATI" and mouseover text "1440 x 900, (0<degree symbol>), Color:32 Bpp)", running LibreOffice Version: 4.4.0.0.alpha1+ Build ID: 9ecac3874d179b1d7aa6b45337001b1def06a9dd TinderBox: Win-x86@39, Branch:master, Time: 2014-10-22_06:32:56 I opened fdo_84854_testCalc.ods with the LibreOffice window "restored", and here is what I see: (1) At zoom factor 65%, approached from either direction, the display looks good. (2) I selected cell D3. (3) I clicked on the "+" in the zoom control three times, increasing the zoom factor to 95%. The row and column headings expand and the heavy outline of cell D3 expands and moves to stay aligned with the headings. The rest of the data area is not resized; without that rezising the data area still shows fragments of the cell-selection-box from smaller zoom factors. The cell borders from the smaller zoom factor are visible within the resized cell-selection-box of cell D3. (4) Another "+" in the zoom control increases the zoom factor to 100%. The data area looks good in every respect. (5) Another "+" in the zoom control increases the zoom factor to 110%. Again, the row and column headers expand, and the cell-selection-box is positioned and sized in accord with the new zoom factor. The rest of the data area remains at 100%, and it shows a fragment of the cell-selection-box as it was at 100%. (6) I dragged the About box around and closed it. Unlike the result that Stuart reports in comment 53, the data area was unchanged. When I changed the desktop area to 800 x 600 and then to 1024 by 768, results are unchanged. With the daily dbgutil bibisect version 2014-10-22, which is of course 64-bit, I of course see no rendering artifacts. However, there is a visible lag (125 ms., at a guess) between painting the dark border around the selected cell and painting the rest of the data area. You get to choose whether this observation is enlightening or merely amusing <grin />. HTH, Terry.
I can confirm this bug on the build machines of LHM (Ubuntu 12.04 32bit). I also confirm the bisected commit 47a2d7642d249d70b5da0c330a73f3a0032e4bba Bisect Report and Log: http://pastebin.com/tW8MU60f Screenshot of the error: http://imgur.com/kHKVBw5 I am adding these to the attachements as well.
Created attachment 108278 [details] git-bisect log
Created attachment 108279 [details] Screenshot on Ubuntu 12.04 LHM 32bit
Created attachment 108282 [details] Buttons invisible in 4.4 alpha I believe the issues with buttons and charts being invisible are related to this screen drawing issue. File used taken from this bug report: https://bugs.freedesktop.org/show_bug.cgi?id=60673
Created attachment 108283 [details] Chart invisible in 4.4 alpha File source: https://bugs.freedesktop.org/show_bug.cgi?id=51671
@Beluga, *, (In reply to Beluga from comment #58) > I believe the issues with buttons and charts being invisible are related to > this screen drawing issue. As you'd mentioned during yesterdays QA IRC meeting. Yes I'd agree it is likely that screen painting issues caused by this regression are impacting import filters for both the XLS and OOXML spreadsheets referenced. On Windows 7 sp1 64-bit en-US with Version: 4.4.0.0.alpha1+ Build ID: 9ecac3874d179b1d7aa6b45337001b1def06a9dd TinderBox: Win-x86@39, Branch:master, Time: 2014-10-22_06:32:56 Likely a manifestation of the drawing issues, the buttons do render, at grotesque size (still absent their diacritics on the text labels) when zoom is set to 65%. Likewise the chart is present (with legend items incorrect) but also far oversize. As if they can't identify an anchor and a scaling factor for placement.
Thank you all for helping with this, and for finding out the exact commit that caused this! I have reverted the change, and the follow-up work there, Calc again works for me on Windows. The plan now is to use boost::rational in a less invasive way :-) The patches that fix this are: http://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=0bab8aee77cfc2ffdbc6d3ef6a869284bc12dff4..31af61ea091cc895b893c849f2130aa35792b7db
Yup. I can verify that it's all working again. :-)
Fix verified for Ubuntu 12.04 LHM 32bit
Both files where I reported problems before are rendered correctly by LibreOffice: Version: 4.4.0.0.alpha1+ Build ID: 0a82645c360158f9cc0fdabe2a52f1ff8f981bed TinderBox: Win-x86@39, Branch:master, Time: 2014-10-24_06:59:23
With reversion verified fixed on Windows 7 sp1, 64-bit en-US with Version: 4.4.0.0.alpha1+ Build ID: 0a82645c360158f9cc0fdabe2a52f1ff8f981bed TinderBox: Win-x86@39, Branch:master, Time: 2014-10-24_06:59:23
Jan, On behalf of everyone with 32-bit systems and everyone on Windows, I want to thank you for taking the time to fix this issue. I can now get back to triaging bug reports.
(In reply to Joey Reid from comment #66) > Jan, > On behalf of everyone with 32-bit systems and everyone on Windows, I want to > thank you for taking the time to fix this issue. I can now get back to > triaging bug reports. No, quite the contrary--the decision to revert was the ESC's, the issue is not "fixed" and if anything an apology is due to David T. and Juan P. from the community for not hanging in there while the issues with the refactoring were resolved. The boost::rational refactoring for Fraction is a nice piece of code--it just needs a bit more work and review to make it right on 32-bit implementations. It is no different than the work Kohei did with the calc refactoring at 4.3--just a little more apparent to users of 32-bit builds. The price of QA and early adopters being intolerant of regressions caused by substantive rework of the code in master is stagnation of the project, and discouragement of talented developers to attempt any of the many things that could be improved in the code. I have no doubt that given a few more build cycles, the regression would have been resolved--and we'd have the Fraction structures implemented with more robust boost::rational methods. That is a shame. Stuart
*** Bug 85637 has been marked as a duplicate of this bug. ***
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]