Stuff Michael Meeks did to 2006-08 |
Personally, and Corporately, I have no particular axe to grind here, ( Groupwise/ODMA/COM/Win32 ? ). However, I am concerned about the long term attractivenes of, and re-use of OO.o. As Fred Brooks infers - if there is a silver bullet out there, it is code re-use. Thus I applaud Sun's wisdom in sticking with the LGPL.
Of course - in terms of actually working together with Sun, (and/or the collab.net infrastructure) life can be incredibly painful, turgid, littered with (seemingly) arbitrary barriers, conflict and so on, all of which need fixing (and in many areas things are improving), but licensing is (currently) the least of my concerns
"Every reader of Scripture should know, wrote [William] Cowper
That souls have no discriminating hue,
Alike important in their Maker's view;
That none are free from blemish since the fall,
And love divine has paid one price for all."
RSS SHR Real
old: 92m 55m 37
new: 84m 56m 28
So a saving of 9Mb or so. For 10 writer
windows, it seems we save 4m or so: good; of course,
as you use more icon-filled menus / dialogs that will
creep up, scaling better.
~/.recently-used XML file corruption bug in OO.o -
horay for Kelli actually filing the bug.
time acroread -toPostScript /demo/a.pdf /tmp/a.ps
a couple of times then do echo "3" > /proc/sys/vm/drop_caches,
look for the amazing vanishing time:
time acroread -toPostScript /demo/a.pdf /tmp/a.ps:
1st time: 2nd time:
real 0m32.221s 0m1.586s
user 0m1.684s 0m1.108s
sys 0m1.080s 0m0.464s
explaining the gap between 2.6 seconds and 32 seconds is
(perhaps) the idea of reading every font on the system, twice (in
2 separate passes) - the strace -ttt shows 32 seconds for that.
Gratifying to see that other people have sillier problems than
OO.o, will try to poke them: surely .pcf.gz fonts aren't worth
playing with anymore(?).
__cxa_eh_globals*
get_global() throw()
{
static __thread __cxa_eh_globals global;
return &global;
}
can return NULL - then either someone is lying to me
(gdb, gcc etc.) or (perhaps) someone stole all the tls slots
(is that a limited resource on Linux ?).
Jun 3 12:42:29 t60p kernel: usb-storage: waiting for device to settle before scanning Jun 3 12:42:34 t60p kernel: Vendor: OMNI Model: MP3 Player Rev: 0100oh, and of course a few 100s of milliseconds to get the HAL / nautilus / banshee to agree it's there & re-render.
linux/drivers/usb/storage/usb.c:
static unsigned int delay_use = 5;
module_param(delay_use, uint, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(delay_use, "seconds to delay before using a new device");
Of course, testing with a delay_use of 0 yields no perceptable
problems, and a > 2 speed increase. Naturally the cheap mp3 player is
(seemingly) 50% faster than the iPod (at 2 secs) to notice it's plugged
in and advertise itself [ all timings guestimated ]. Still - it's nice
to go from 7 to 2 seconds, or from 8 to 3 with just:
modprobe -r usb_storage
modprobe usb_storage delay_use=0
ipw3945: Radio Frequency Kill Switch is On: Kill switch must be turned off for wireless networking to work.. After re-booting to Win32 to get the same effect, discovered a tiny H/W switch hidden under the chamfered front-left, simple.
Hello testers you are in test portal This is the https portCleary an amazing service. Loading without the magic authentication goodness (cf. link), you get a beautiful login page instead. Curious.
Not enough storage is available to process this command.
not massively encouraging wrt. the fidelity of the whole process.
unresolvable R_386_GOTOFF relocation against symbol `com::sun::star::uno::RuntimeException::~RuntimeException()'
but why use a GOTOFF relocation ?
no unique final overrider for... g++ errors;
fair enough. Unfortunately, (it seems) one can't use this pattern
without touching the base class; something that can't be done.
FooClass() : major(0) { }; the error ?
error: class 'FooClass’ does not have any field named ‘gnu_dev_major’
nice - and I thought it was only libbonobo that had these problems.
File->Templates->Addressobook Source->Administrate.
OOO_FORCE_SYSALLOC=1 like all good developers do.
xrandr -s 0 -
turns out there were several mis-matched views about what size the
screen is.
After all, who would question that Islam is a religion of peace & love with a high commitment to honesty & integrity, open debate & discussion of contentious issues and letting the truth speak for itself ? I guess at least the Danish Bacon industry will be unaffected."If you are a Muslim and your faith is strong and you believe in God and in your prophet then I don't think you should be remotely frightened of what some ludicrous infidel says or does about your religion or any depiction he produces."
"I think we've got to move away from this hysterical and rather patronising idea that we have got to treat the Muslim religion with kid gloves and not subject it to all the same rough and tumble that we subject other faiths to."
glad I don't have to report to 2 people.Nigel Nicholson, a professor of organisational behavior at the London Business School, called the matrix structure "one of the most difficult and least successful organisational forms."
Messrs Ghosal and Bartlett wrote in the past tense, suggesting that companies had escaped from the matrix corset. But 15 years after the article was published, many are still trying to struggle free.
~/.gnome2/session contains all manner of obsolete &
unusual things. Fixed an file / argument handling issue with the
quickstarter, 2 conference calls.
I only open my mouth to change feet.
gecko-sdk package; finally got things building.
Wrote column. Tested video output, everything beautiful in
NLD10, lovely cloned output. Left OO.o building.
cp -lR today: and to think of
all those years of ignorance. Posted my .suse.hashvals patch to
the binutils list - got a response which was nice. Re-worked the
-Bdirect patches to use the new OS specific SUSE tags &
renamed sections to '.suse' variants.
Section size breakdown:
symbols 57450kb - 30% [ a non-stripped build ]
code 53676kb - 28%
linking 43092kb - 23%
data 14248kb - 7.5%
exceptions 11978kb - 6.3%
data relocs 5769kb - 3% ...
Of which:
Symbol entry counts:
~total .dynsym entries: 724251
.dynstr size:
def: 42969100
undef: 3999841
(avg len): 65
So by adding a .suse.hashvals section with the pre-computed
hashes we add ~3Mb, but then during linking we wander across only
~6Mb of hash/chain/hashvals instead of 43Mb as now; hopefully with
some nicer cache usage effects.
undef $fh; beforehand; unexpected and
unpleasant. Got the tool extending user-dicts in the new format though.
In one particularly odd case, a Najran judge sentenced a 16-year-old Ismaili schoolboy to death for blasphemy. This was commuted on appeal to 14 years in prison and 4,000 lashes, to be administered publicly in 80 weekly sessions of 50 blows. Most Saudis are unaware of such injustices...Thank God Jesus' kingdom is not of this world; critical to keep that in view.
export VCSID=<account>
before creating a cws; worked with 'rfc821' who fixed it nicely.
Interviewer: So - it's great that you're willing to sacrifice a day's pay to strike & make your voice heard in government.
Striker: Oh no, I don't loose any pay, it's my civil right to strike, the government continue to pay me.
Interviewer: oh - but, of course you have to pay the train fair of course, that's some sacrifice
Striker: Oh no, the Union pay the train fair.
Interviewer: but of course, you pay that through higher union dues effectively ?
Striker: Oh no, the government pay my Union membership dues. ...
pipe & then a
socketpair not returning from poll (G_IO_HUP)
when the forked child closed their end of the pipe; I could swear it
should do that; fine on remote process death though. After writing some
dummy data to the socket, and using shutdown I got the
expected behavior, odd.
One evening during our prayer and Bible study, Mrs Weidema came running from the hospital. "Njonja, please come and pray for my baby," she pleaded. She had been going regularly to nurse the baby, but her milk had dried up and the baby was not responding to the rice water they were using as a substitute. I went back with her my heart torn by that limp and lifeless bit of humanity. We bowed our heads together, and I prayed that the Lord would spare her baby.
Returning to the barracks I was met by another young mother from our barracks, Lennie Ripassa. She had an infant and was nursing. "Meurouw Deibler, I have more milk than I need," she volenteered. "I would be willing to breast-feed the other baby too." Which is exactly what she did, feeding the sick starving baby until he regained strength and both babies were weaned. This was God's answer to prayer. Both of the newborns from our barracks survived.
readelf -s -W -D -I foo.so output.
Never mind that any half-breed monkey with the brain of a flea that has ever programmed an office suite since Microsoft captured the marketplace has bent over backwards to ensure the highest level of compatibility with MS Office they could offer.He should clearly be more careful whom he offends.
Before: ==27907== D refs: 98,069,403 (73,455,788 rd + 24,613,615 wr) ==27907== D1 misses: 3,963,722 ( 3,943,112 rd + 20,610 wr) ==27907== L2d misses: 179,710 ( 178,441 rd + 1,269 wr) ==27907== D1 miss rate: 4.0% ( 5.3% + 0.0% ) ==27907== L2d miss rate: 0.1% ( 0.2% + 0.0% ) After: ==27871== D refs: 98,067,932 (73,454,588 rd + 24,613,344 wr) ==27871== D1 misses: 1,916,141 ( 1,911,775 rd + 4,366 wr) ==27871== L2d misses: 175,893 ( 174,620 rd + 1,273 wr) ==27871== D1 miss rate: 1.9% ( 2.6% + 0.0% ) ==27871== L2d miss rate: 0.1% ( 0.2% + 0.0% )And of course - that doesn't require any glibc changes, which is nice. Some patch cleanup needed. Conf call with the Intel lads.
elf_hash % bucketcount - [within the
global/local distinction] ensuring that collisions are as adjacent
in memory for conflicts as possible.
http://red-carpet.go-oo.org/,
and grab
hypocycloid-demo.xls. In fact, although this is quite a simple, but good
looking macro, we can do way more useful things too, development help appreciated
though.
-z interpose linker
feature a "ld-preload this library" type flag; might be useful for
the glibc pthreads bits. Installed some development stuff on the slow
laptop with yast2 - there's another app that needs some profiling love -
to speedprof to be compiled. Upgraded to the latest evo. snapshot to get
a different set of bugs: a change is as good as a rest.
get_string, slen, free_list,
list_size, reference even better than that - in case of a single
instance failing - they're defined by multiple libraries. Mailed Glynn a
list of obvious problems - when you look closer it just gets worse.
Mailed the CDDB author too, and the cdparanoia chap, mailed Dick Porter
about Mono too; gave up - too tiresome; all bugs.
/usr/lib/browser-plugins/libflashplayer.so export
'strchr', 'strrchr' and 'strlen' symbols ? hopefully Macromedia
know.
/opt/gnome/lib/gaim/docklet.so /opt/gnome/lib/tomboy/libtomboy.so /opt/gnome/lib/evolution/2.4/libeutil.so.0.0.0 implement:
egg_tray_icon_new_for_screen egg_tray_icon_cancel_message egg_tray_icon_send_message egg_tray_icon_get_orientation egg_tray_icon_get_type egg_tray_icon_new
. Mailed the gstreamer guys too. So far not found a single
genuine/deliberate use of interposing in the whole of Gnome / OO.o:
clearly not that critical a linker feature.
echo "foo" >> /share/NLD-10-DVD-i386-Alpha2a.iso File size limit exceededAfter some more poking turns out the user-space NFS thing was installed, got the
nfs-utils package instead of
nfs-server & tried again.
L2 read misses are the most costly issue there and 83% of these misses
are in the dynamic linker. 77% are caused by symbol lookup for
relocation and runtime resolving.
12% L2read misses for elf_hash buckets
14% L2read misses for walking the elf_hash chain
24% L2read misses for looking up the symbol entry
strcmp:
23% L2read misses for comparing symbol name
...
Solving the L2 cache thrashing would also benefit the cold performance
considerably because a lot of the page faults there would not happen.
<Oooluver> <Oooluver> Hi9 Michael <Oooluver> Do you know anything about OpenOffice.org's performance? <Oooluver> Why do you blame glibc, gcc, the kernel, the phase of the moon, ad nauseum -- when there are plenty of examples of fast apps under Linux? <Oooluver> Why keep pointing the blame like a mardy infant? <Oooluver> OpenOffice.org is a vast, kludgy, overgrown, dilapidated codebase, and no amount of finger-pointing will correct that <Oooluver> When MS Office under WINE on Linux is faster than OO.o, you know you have a problem <Oooluver> I have some benchmarks here: http://benchmarks.on.nimp.org/ooo/ <Oooluver> They show MS Office load times in Windows, WINE on Linux, WINE on FreeBSD, and OOo native respectivelyWhen anonymous cowards are annoyed enough to send you personalised discouraging spam - with links to popup-bombs, something must be going right. Of course the fact that OO.o starts faster under WINE than Linux on the same machine seems not to feature. The more I read of the OO.o code, the more sense much of it makes, but its true - slower than 'ls', though
ls -R /usr is pretty turgid.
set mark-symlinked-directories On to my
/etc/inputrc solved my bash tab completion problems.
There are a number of patches floating around that are intended to accelerate cold time startup of eg. the GNOME desktop, that seem attractive but are rather unhelpful for real world use
The premise of them is that if (as you mmap a shared library) you force the kernel to load it all, then you will get vastly better I/O behavior as it is linked & as the app starts up, since the mapped files (DSOs) are accessed fairly randomly. The premise is correct.
Where this all breaks down of course is that - what is optimal on a 1st / cold start (with lots of memory) is often extremely sub-optimal on a 2nd start
eg. after 2 hours of evolution use, lots of the code which is never touched will be paged out - to make space for other more live data. If we insist on paging that code back in - we have an evil situation - where now we have lots of scattered missing fragments. ie. by forcing 'everything' into memory we necessarily have to seek the missing [seldom used] pieces, seek, read them at great cost.
This phenomenon also bites OO.o where we do a similar trick, and causes pain on loaded / small memory machines on 2nd start. However - since this is in our app we can fix this.
Of course - again, only the kernel can know that this library has already been mmapped & that we don't now want to force page it all in. Only the kernel knows (during cold boot) that we have shed-loads of pristine, unused pages sitting around - and thus we should be aggressively pre-loading mmapped files. Only the kernel (ideally) knows what happened wrt. I/O last time during the execve of this app, what it mapped, and what it used. So - basically we're back to the old axiom for anyone comparing Linux with Win32 I/O performance: Linux I/O scheduling sucks - try to work around it.
Unfortunately this can't be worked around efficiently outside the kernel.
Furthermore, it is acutely unfortunate that the kernel hackers are just amazingly reluctant to provide sharp tools to examine how bad the I/O situation is. It being ~impossible to reliably simulate a cold-start without a hard re-boot. There being no quick way to drop all caches, file backed pages etc.
mincore syscall that
could be used to determine if a shlib was mapped by someone else -
I guess it could be useful for glibc. Of course - one might want to
guess how sane the kernel will be wrt. seeks if you ask for pages
1,2,3, 5, 7,8 to be read. Either way - writing a separate
application that renders the OO.o splash seems the only way to
go here.
Old glibc: 3968, 3978, 3983 Avg: 3980 Just new glibc: 4224, 4238, 4250 Avg: 4240 [260ms slower - hmm] all -Bdirected: 2148, 2168, 2215 Avg: 2180 [1800ms faster - 45%]
before: 2.693, 2.721, 2.714 Avg: 2.709 after: 0.675, 0.679, 0.682 Avg: 0.679 [75% faster]
-U --replacepkgs
--oldpackage it then worked fine.
Old glibc: 3968, 3978, 3983 Avg: 3980 Just new glibc: 4224, 4238, 4250 Avg: 4240 [260ms slower - hmm] many -Bdirected: 2378, 2387, 2389 Avg: 2385 [1600ms faster - 40%]
before: 2.693, 2.721, 2.714 Avg: 2.709 after: 0.970, 0.968, 0.956 Avg: 0.965 [65% faster]
NSP_Sleep(5);
// try to connect to background SO, thus judge if it is ready
while(0 > connect(my_sock, (struct sockaddr *)&dst_addr, sizeof(dst_addr)))
...
NSP_CloseSocket(my_sock);
NSP_Sleep(5);
etc.
fprintf (stderr, "Is '%s' %c%c%c vague (%d)\n", symbol, symbol[0], symbol[1], symbol[2], ret);outputs:
Is 'typeinfo for BaseClass' _ZT vague (1)etc. More interestingly, after pre-processing it's still calling 'fprintf'; deep magic.
export LD_DEBUG=bindings:symbols:direct we get:
8375: dynamic symbol index 602 from 'libbasegfx680li.so' for _ZTIN7basegfx29B2DPolyPolygonRasterConverterE
8375: dynamic symbol offset 65534
8375: vague symbol
8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=./soffice.bin
8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=./libvcl680li.so
8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=./libsvl680li.so
8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=./libsvt680li.so
8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=./libutl680li.so
... omit 10 other OO.o libs ...
8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=/usr/X11R6/lib/libSM.so.6
8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=/usr/X11R6/lib/libICE.so.6
8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=/usr/X11R6/lib/libX11.so.6
8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=/opt/gcc/lib/libdl.so.2
8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=/opt/gcc/lib/libpthread.so.0
8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=./libstlport_gcc.so
8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=/usr/lib/libstdc++.so.6
8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=/opt/gcc/lib/libm.so.6
8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=/lib/libgcc_s.so.1
8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=/opt/gcc/lib/libc.so.6
... omit 5 other OO.o / system libs ...
8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=/lib/libz.so.1
8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=/usr/lib/libjpeg.so.62
8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=./libjvmfwk.so.3
8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=./libuno_salhelpergcc3.so.3
8375: symbol=_ZTIN7basegfx29B2DPolyPolygonRasterConverterE; lookup in file=./libbasegfx680li.so
8375: binding file ./libbasegfx680li.so to ./libbasegfx680li.so: normal symbol `_ZTIN7basegfx29B2DPolyPolygonRasterConverterE'
8375: dynamic symbol index 525 from './libbasegfx680li.so' for _ZN7basegfx29B2DPolyPolygonRasterConverterD1Ev
8375: dynamic symbol offset 0
8375: symbol=_ZN7basegfx29B2DPolyPolygonRasterConverterD1Ev; lookup in file=./libbasegfx680li.so
8375: direct lookup ...
8375: binding file ./libbasegfx680li.so to ./libbasegfx680li.so: normal symbol `_ZN7basegfx29B2DPolyPolygonRasterConverterD1Ev'
ie. 1 lookup instead of 30 (and this is early in the OO.o startup
process, before many libs are loaded). Still poking at a few issues though;
switched the system back; need to re-build glibc with
make install_root=/foo install
/lib/ld-linux.so <app> is best. Added
some basic
vague symbol tagging / pruning and got something nicer:
$ readelf -y libfixup.so
Direct relocations for image:
Num: Index Binding Symbol
14: [0x0000] <self> _DYNAMIC
17: [0x0000] <self> _Z12simpleMethodP9BaseCla
18: [0x0000] <self> _init
19: [0xfffe] <vague> _ZTS11MyException
20: [0x0005] libc.so.6 stderr
23: [0x0002] libstdc++.so.6 __cxa_allocate_exception
42: [0xffff] <unknown> __gmon_start__
readelf -y
now showing my some nice direct linking information:
$ readelf -y libfixup.so
Direct relocations for image:
Num: Index Binding Symbol
12: [0x00] <unknown> _DYNAMIC
13: [0x01] libdl.so.2 dlsym
14: [0x02] libc.so.6 fprintf
15: [0x00] <unknown> __vt_fixup
16: [0x00] <unknown> _init
17: [0x02] libc.so.6 malloc
18: [0x02] libc.so.6 stderr
with a little more tweaking, it's onto the ld.so piece.
chkconfig --add spamd + manual start; after
much chasing discovered it's a silly internal bug. Quested for recent
evo. / snapshot build for SL10.0, no joy; bother. More ooo-build poking.
unset LIB INSTALL seemed to cure the problem
very nicely. Wrote another LXF column.
ssh -X localhost xprop -root
dies with: X Error of failed request: BadAtom (invalid Atom parameter) Major opcode of failed request: 20 (X_GetProperty) _MOTIF_CLIP_FORMAT_ACROBAT_SELECTION Atom id in failed request: 0x25c Serial number of failed request: 11 Current serial number in output stream: 11. OTOH
ssh -Y localhost works just as you would expect. Of course,
OO.o's gtk+ integration dies horribly in the 1st situation.
(gdb) p *pStg virtual baseclass botch (gdb)- most helpful.
$ cd /usr/lib/ooo-2.0/program $ MONO_PATH=. mono SpreadsheetSample.exe
error in rsync protocol data stream
(code12) at io.c (342) - a neat rsync feature obviously.
Switched to wgetting individual ISOs.
xhost +SI:localhost:michael - which is nice.