Stuff Michael Meeks is doing

Older items: 2015: ( J F M ), 2014: ( J F M A M J J A S O N D ), 2013, 2012, 2011, 2010, 2009, 2009, 2008, 2007, 2006, 2005, 2004, 2003, 2002, 2001, 2000, 1999, legacy html

Up early, now Apache have some code available, I did a quick analysis of the LibreOffice diff to Apache's codebase - which is fairly large and growing: looking only at C++ files ( *.?xx ) we have: We removed ~678 files (though some small proportion of these are simple movements to improve encapsulation and/or re-use). A hundred or so of the removals are obsolete binfilter pieces, 55 from OS/2 code, 50 from adabas and evo1 connectors, 38 from soldep, 36 from killing vos, but many more bits of unused cruft gone. We added ~914 new files modulo movements the single biggest chunk is : 380 files is (IBM's) lotuswordpro filter (forward-ported by us), then it gets bitty: VBA improvements, the re-written RTF import filter, the ODMA and KDE file pickers, OpenXML filter work, new unit tests, gtk3 pieces, AIX UNO bridge, svg filter and lots more. These numbers compare with 21.5k common files overall. As a reasonably useless statistic - but perhaps one that points helpfully to the likelihood of merging conflicts we have ~2 million lines of diff -u output over 7.7 million newlines of code. More concretely, having elided the code changes from the (automated) emacs & vi modelines (to make editing much easier) which touched each file, and looking only at common files we have: minus 526k lines - always good to measure the negatives first: we ripped and replaced a lot of cruft. And then we added 290k lines back again. Naturally, lots of feature work was done in the new files we added, so the net work input is much larger, the above number is only looking at the common files; to gague the degree of code-change. raw data (11Mb). What does that all mean ? well it is a lot of code-change and cleanup. It is also a lot of scope for conflict when merging changes. Seemingly there is an assumption, that code committed to Apache OpenOffice will inevitably and automatically appear in LibreOffice. This looks increasingly unlikely. Instead I suspect we will end up cherry-picking and porting only those things that justify the effort, as/when/if there is any such thing.

files ( ) we have: What does that all mean ? well it is a lot of code-change and cleanup. It is also a lot of scope for conflict when merging changes. Seemingly there is an assumption, that code committed to Apache OpenOffice will inevitably and automatically appear in LibreOffice. This looks increasingly unlikely. Instead I suspect we will end up cherry-picking and porting only those things that justify the effort, as/when/if there is any such thing. Pain in jaw (again) - an annoying intermittent wetware bug. Re-based feature/gtk3 branch and built it. Did some hacking on windows to try to unwind some unit test breakage, remembered again why I hate using that thing. File URLs that look like file:///c:/foo/baa which inevitably break when ported from unix Incremental (no action) re-make time of the order of a minute instead of a handful of seconds - amazing. OS Hardware incremental 'sc' make with glob fix incremental tail_build same with glob fix Linux (openSUSE11.4) 2.5GHz Core2 Duo 6.8 seconds 4.5 seconds 32 seconds 22 seconds Windows 2008R2 2GHz Dual core Xeon 118 seconds 14.8 seconds 597 seconds 80 seconds Of course, no doubt cygwin has a lot to do with the slowness, but wow life is painful without that glob fix (which saves a ton of un-necessary I/O). It -really- looks as if we should be building with our own make snapshot on windows.

branch and built it. Did some hacking on windows to try to unwind some unit test breakage, remembered again why I hate using that thing. File URLs that look like which inevitably break when ported from unix Incremental (no action) re-make time of the order of a minute instead of a handful of seconds - amazing. Of course, no doubt cygwin has a lot to do with the slowness, but wow life is painful without that glob fix (which saves a ton of un-necessary I/O). It -really- looks as if we should be building with our own make snapshot on windows. Tested Moggi's nice merged cells movement / undo/redo fix - lovely. Poked at Bjoern's nice gerrit instance - looks easy to get going at least.

Poked at the GTS library to see if it could be used for 3D shrinking / slicing for repsnapper, looks rather impressive (though apparently sadly unmaintained).

My content in this blog and associated images / data under images/ and data/ directories are (usually) created by me and (unless obviously labelled otherwise) are licensed under the public domain, and/or if that doesn't float your boat a CC0 license. I encourage linking back (of course) to help people decide for themselves, in context, in the battle for ideas, and I love fixes / improvements / corrections by private mail.

In case it's not painfully obvious: the reflections reflected here are my own; mine, all mine ! and don't reflect the views of Collabora, SUSE, Novell, The Document Foundation, Spaghetti Hurlers (International), or anyone else. It's also important to realise that I'm not in on the Swedish Conspiracy. Occasionally people ask for formal photos for conferences or fun.

Michael Meeks (michael.meeks@collabora.com)