Stuff Michael Meeks is doing |
Older items: 2012: ( J F ), 2011: ( J F M A M J J A S O N D ), 2010: ( J F M A M J J A S O N D ), 2009, 2008, 2007, 2006, 2005, 2004, 2003, 2002, 2001, 2000, 1999, legacy html
ipp://.../ipp?waitjob=false&waitprinter=false
is a good idea.
eglQuerySurface(...EGL_BITMAP_POINTER..) - stymied
again. On to trying glTexImage2D - surely that
will get a lot of pixels to the screen fast, lots of error free
gl calls, with a blank screen to match; hmm.
ALooper - which causes
aforementioned lockup; nice - finally an up-side-down,
wrong color, no font VCL error dialog windows.
README.Android and no pixels yet of
course. Chat with Simon, then Charles.
tools/ - a duplicate system
abstraction that still malingers underneath LibreOffice. Hid a few more unused
locking methods in SvStream, and made the FSysRedirector more obviously a no-op.
There are big blocks of easy-to remove cruft in tools needing a beginner or two.
I have no wish for the ODF standard, like the US Constitution or the Bible, being used as an excuse to justify stupidity. ODF is a specification for document exchange. If you are using it in a way that decreases interoperability then you really need to step back and ask yourself if your literal interpretation really makes sense.Of course, amazingly the implication is that it would be 'stupidity' to follow the spec. and produce documents that are valid ODF 1.2 (as LibreOffice 3.5, and the Apache OpenOffice 3.4 pre-release builds do.
If a program does not meet user expectations then it is a bug. If you want to be compatible with Microsoft Office then you need to play by their rules. ...This is really a deep & rich lasagne of irony, I'm really trying to work out which bit is most tasty, could it be - first the aggressive, purist, open-standards champion advocating deliberatly writing non-conforming output, and making ODF 'play by' Microsoft's rules ? Or - could it be the fact that (apparently) the TC chair hadn't bothered to validate or test changes to his standard in 'real world' office suites, but rather prefers to deflect attention at 'woefully inadequate QA' to a single implementor: LibreOffice. Or finally could it be that he hasn't noticed that his own Apache OpenOffice implementation actually does the same thing. Hard to choose really; mystifying; checked colour of the moon to make sure: apparently not blue.
In any case Seeing responses like this from LibreOffice makes be very optimistic about the future of Apache OpenOffice. Whatever the cause, the fact that LibreOffice ships with this problem shows either a woefully inadequate QA program, or total indifference to real world requirements. Even testing a single LibreOffice document in Office 2007 would have shown this bug. Is that too much to expect?
One of the unfortunate things that LibreOffice inherited, as part
of the several decades worth of unpaid technical debt, is unused code that
has been left lying around indefinitely. This was particularly unhelpful
when mingled with the weight and depth of the useful code we have around
the place. Caolan McNamara of RedHat wrote a beautiful tool callcatcher that
identified these unused methods, and in recent times in LibreOffice we've had an unusedcode.easy
file in our toplevel with a list of methods that should be removed. It's pretty
easy to find and expunge a method or two, with a quick git grep,
and dropping a patch to the developers
mailing list. To escape from a pile of administration recently, I knocked up a pretty nasty
perl script to parse the git numstat output, to see how we're doing. That
produces a fun graph:
It seems that over half of our unused code has now bitten the dust. Uunfortunately as we remove more, more wasteage tends to be revealed, which explains some of the upward jumps in the graph, nevertheless the trend is clearly down. One of the side benefits of the unsung heros working at the conversion of our old-style macro driven generics to modern STL is that this looses us several unused methods per class converted.
If you want to get involved with LibreOffice development, it doesn't get much easier than this - please do check out the code and have a go. For the more adventurous finding an unused destructor, without a matching unused constructor is proof of a leak that needs chasing, of which there are a handful.
Failing that, why not run Caolan's callcatcher over your project to see which nooks and crannies are surplus to requirements.
rm -Rf /tmp/*
destroying the gnome-keyring socket in the process. In the meantime:
sudo systemctl disable systemd-tmpfiles-clean.timer sudo systemctl stop systemd-tmpfiles-clean.timerNo doubt just a mis-configuration that can be cleaned up; I wonder if it trashes ORBit2's sockets too - though perhaps it ignores sockets.
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 SUSE, Novell, The Lithuanian Gov't or Arnold Schwarzenegger. 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@novell.com)