Fading Memories

So KDE is over the four million lines of code mark... Well... KOffice by now has about 700,000 lines of code -- although 70,000 of them are import of external projects for Krita. And OpenOffice has 5,209,395 lines of code. So OpennOffice is bigger than KDE and KOffice put together. That must account for some of the startup delay of OpenOffice.

As per sloccount:

SLOCCount for KOffice

SLOC    Directory       SLOC-by-Language (Sorted)
173612  filters         cpp=168841,ansic=3646,python=600,yacc=227,lex=157,
                        sh=141
157433  kexi            cpp=78876,ansic=74190,yacc=2307,python=1147,sh=565,
                        lex=286,awk=62
107505  lib             cpp=105615,python=1155,ansic=425,perl=157,sh=153
79549   kspread         cpp=79490,sh=59
72106   krita           cpp=67997,ansic=3668,python=289,sh=87,perl=65

Holy thingummy -- we've been adding code to Krita at a fair clip!

 51159   kpresenter      cpp=50893,perl=142,sh=124
48190   kword           cpp=48103,sh=68,perl=19
32750   karbon          cpp=27516,ansic=5175,sh=59
30073   kchart          cpp=30073
25880   kivio           cpp=25853,perl=27
19583   kplato          cpp=19583
14530   admin           sh=9851,perl=4679
12019   kdgantt         cpp=12019
8484    kugar           cpp=8484
2323    tools           cpp=1901,perl=261,sh=161
1887    kformula        cpp=1828,sh=59
1251    koshell         cpp=1251
230     example         cpp=230
180     kounavail       cpp=180
152     top_dir         sh=152
72      plugins         cpp=72
70      interfaces      cpp=70
30      doc             sh=30
22      templates       sh=22
0       autocorrect     (none)
0       autom4te.cache  (none)
0       debian          (none)
0       mimetypes       (none)
0       pics            (none)
0       servicetypes    (none)


Totals grouped by language (dominant language first):
cpp:         728875 (86.86%)
ansic:        87104 (10.38%)
sh:           11531 (1.37%)
perl:          5350 (0.64%)
python:        3191 (0.38%)
yacc:          2534 (0.30%)
lex:            443 (0.05%)
awk:             62 (0.01%)




Total Physical Source Lines of Code (SLOC)                = 839,090
Development Effort Estimate, Person-Years (Person-Months) = 234.98 (2,819.75)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months)                         = 4.26 (51.17)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 55.10
Total Estimated Cost to Develop                           = $ 31,742,461
 (average salary = $56,286/year, overhead = 2.40).
SLOCCount, Copyright (C) 2001-2004 David A. Wheeler
SLOCCount is Open Source Software/Free Software, licensed under the GNU GPL.
SLOCCount comes with ABSOLUTELY NO WARRANTY, and you are welcome to
redistribute it under certain conditions as specified by the GNU GPL license;
see the documentation for details.
Please credit this data as "generated using David A. Wheeler's 'SLOCCount'."

OpenOffice:

 SLOC    Directory       SLOC-by-Language (Sorted)
951595  binfilter       cpp=951322,awk=256,asm=10,perl=7
550631  sw              cpp=550082,ansic=505,awk=44
383523  svx             cpp=383440,sh=73,asm=10
365804  sc              cpp=363582,java=1269,lisp=798,perl=155
192673  vcl             cpp=188641,ansic=2769,objc=702,java=544,asm=17
172907  svtools         cpp=172712,ansic=195
156925  sd              cpp=156662,perl=184,php=79
120534  xmloff          cpp=120534
114964  qadevOOo        java=114964
110217  sal             cpp=70872,ansic=36235,perl=2866,asm=212,csh=20,sh=12
101860  sfx2            cpp=101269,java=591
100550  dbaccess        cpp=100008,java=542
91611   connectivity    cpp=86029,yacc=3044,java=1803,lex=735
88306   framework       cpp=84366,java=3940
62593   tools           cpp=60439,ansic=2098,awk=56
61603   extensions      cpp=59289,ansic=2238,java=76
56653   configmgr       cpp=55840,java=764,sh=49
56291   sch             cpp=56291
53943   setup2          cpp=49845,ansic=2272,objc=1039,sh=760,perl=27
53068   ucb             cpp=51890,java=1160,python=18
49881   odk             java=40793,cpp=5055,cs=1580,perl=989,ansic=638,pascal=397,
                        sh=236,csh=193
46307   goodies         cpp=46307
44462   basic           cpp=44326,asm=136
43922   i18npool        cpp=43546,awk=376
41627   bridges         cpp=35086,java=5640,asm=901
40778   chart2          cpp=40146,java=524,perl=108
38196   autodoc         cpp=38196
37336   wizards         java=37336
37309   toolkit         cpp=29971,java=7338
37047   solenv          perl=33728,sh=3011,ansic=242,awk=66
34870   forms           cpp=31696,java=3174
30401   stoc            cpp=30278,java=123
29871   std2            ansic=29829,sh=42
28979   scripting       java=20327,cpp=7979,python=673
26308   xmerge          java=21501,perl=2296,cpp=1726,sh=785
25315   filter          cpp=19383,java=5563,python=369
25194   dmake           ansic=19994,sh=4387,asm=759,awk=54
23797   desktop         cpp=23142,sh=383,ansic=272
23702   starmath        cpp=23702
21836   slideshow       cpp=21239,perl=578,sh=19
20322   xmlsecurity     cpp=17254,java=3068
19236   codemaker       cpp=18832,java=404
19089   so3             cpp=19089
18734   psprint         cpp=14057,ansic=4677
18269   basctl          cpp=18269
18081   hwpfilter       cpp=18081
16862   XmlSearch       java=16862
16713   package         cpp=12658,java=4055
16462   rsc             cpp=11865,ansic=3647,yacc=950
15446   comphelper      cpp=15217,java=229
15158   automation      cpp=15078,perl=80
14695   sim2            cpp=14695
14202   canvas          cpp=10189,java=4013
13954   xmlhelp         cpp=8082,java=5741,sh=131
13495   cppu            cpp=11768,ansic=1727
13412   sip             cpp=13365,sh=47
13255   fpicker         cpp=13255
12875   embeddedobj     cpp=10856,java=1911,ansic=108
12473   unotools        cpp=12473
12137   basegfx         cpp=12137
12075   dtrans          cpp=12075
11774   transex3        cpp=10217,perl=830,lex=718,sh=9
11404   writer2latex    java=11404
11346   idlc            cpp=5215,ansic=3340,yacc=2791
11335   lingucomponent  cpp=9652,ansic=1600,perl=83
11330   registry        cpp=11330
11276   ucbhelper       cpp=11276
11248   sot             cpp=11248
10708   cppuhelper      cpp=10520,perl=188
9944    linguistic      cpp=9682,java=262
9465    jurt            java=9068,ansic=397
9413    soltools        ansic=5731,cpp=2675,lex=1007
9172    shell           cpp=8476,sh=538,ansic=125,awk=33
8610    xmlscript       cpp=8610
8242    testshl2        cpp=6984,java=780,perl=435,csh=43
8209    accessibility   java=7984,cpp=225
8065    idl             cpp=8065
7992    testtools       cpp=4375,cs=1787,java=1281,python=549
7942    odfilter        cpp=7942
7901    javaunohelper   java=7351,cpp=550
7250    io              cpp=7250
6983    store           cpp=6983
6712    cppcanvas       cpp=6712
5750    jvmfwk          cpp=5695,java=55
5483    regexp          ansic=3808,cpp=1675
5412    scptools        cpp=5281,yacc=131
5060    cli_ure         cpp=2626,cs=2377,java=57
4799    avmedia         cpp=3537,java=1262
4737    setup_native    cpp=4040,sh=572,ansic=91,perl=34
4538    jtools          java=4538
4522    scaddins        cpp=4522
4362    embedserv       cpp=4362
4212    sax             cpp=4212
4145    padmin          cpp=4145
4119    pyuno           cpp=3287,python=745,sh=59,csh=16,ansic=12
3859    i18nutil        cpp=3859
3843    crashrep        cpp=3829,sh=14
3785    bean            java=3555,ansic=230
3733    unodevtools     cpp=3733
3579    unoxml          cpp=3579
3327    xml2cmp         cpp=3327
3273    bonobo          cpp=2904,ansic=281,sh=55,sed=33
3093    uui             cpp=3093
2977    UnoControls     cpp=2977
2906    ie              cpp=2906
2806    vos             cpp=2806
2567    mkdepend        ansic=2567
2545    cosv            cpp=2545
2482    smoketest       perl=1156,java=1111,cpp=215
2437    chart           cpp=2437
2407    sandbox         java=2407
2343    ridljar         java=2343
2324    sj2             java=1622,cpp=702
2275    unixODBC        ansic=2275
2154    rdbmaker        cpp=2154
2018    cpputools       cpp=1932,sh=86
1930    config_office   perl=1930
1910    remotebridges   cpp=1910
1900    animations      cpp=1900
1698    writerperfect   cpp=1698
1513    udm             cpp=1513
1390    twain           ansic=1390
1352    sysui           cpp=733,perl=385,sh=187,ansic=43,sed=4
1351    smoketestoo_native perl=1351
1039    officecfg       java=1038,sed=1
952     devmanual       perl=952
913     udkwww          python=913
830     jut             java=830
790     virgule         cpp=747,ansic=43
740     fileaccess      cpp=740
676     eventattacher   cpp=676
625     helpcontent2    perl=625
617     x11_extensions  ansic=617
616     testshl         cpp=616
525     ure             cpp=381,java=137,sh=7
509     jvmaccess       cpp=453,java=56
477     postprocess     perl=477
474     sdk_oo          perl=474
465     salhelper       cpp=465
400     product         cpp=400
323     apiwww          perl=321,sh=2
241     scp2            perl=241
173     sane            ansic=173
133     helpcontent     perl=133
110     external        sh=64,ansic=37,cpp=9
76      readlicense     perl=76
65      dictionaries    perl=65
25      ooo_custom_images php=25
21      res             sh=21
4       stlport         sh=4
3       instsetoo_native sh=3
2       offapi          sed=2
0       DocumentProperties (none)
0       MathMLDTD       (none)
0       apache-java     (none)
0       apache_java     (none)
0       api             (none)
0       aspell          (none)
0       beanshell       (none)
0       berkeleydb      (none)
0       bitstream_vera_fonts (none)
0       boost           (none)
0       boot            (none)
0       curl            (none)
0       default_images  (none)
0       dlcompat        (none)
0       epm             (none)
0       expat           (none)
0       ext_log4j       (none)
0       extras          (none)
0       freetype        (none)
0       hsqldb          (none)
0       icu             (none)
0       instsetoo       (none)
0       jpeg            (none)
0       libwpd          (none)
0       libxml2         (none)
0       libxmlsec       (none)
0       lingu           (none)
0       mdbtools        (none)
0       moz             (none)
0       msfontextract   (none)
0       nas             (none)
0       neon            (none)
0       netbeans_integration (none)
0       np_sdk          (none)
0       offmgr          (none)
0       offuh           (none)
0       portaudio       (none)
0       pspell          (none)
0       psprint_config  (none)
0       python          (none)
0       readlicense_oo  (none)
0       rhino           (none)
0       rvpapi          (none)
0       sablot          (none)
0       sndfile         (none)
0       so_berkeleydb   (none)
0       top_dir         (none)
0       udkapi          (none)
0       unoil           (none)
0       xalan           (none)
0       xmlwww          (none)
0       zlib            (none)


Totals grouped by language (dominant language first):
cpp:        4630794 (88.89%)
java:        361396 (6.94%)
ansic:       130206 (2.50%)
perl:         50774 (0.97%)
sh:           11556 (0.22%)
yacc:          6916 (0.13%)
cs:            5744 (0.11%)
python:        3267 (0.06%)
lex:           2460 (0.05%)
asm:           2045 (0.04%)
objc:          1741 (0.03%)
awk:            885 (0.02%)
lisp:           798 (0.02%)
pascal:         397 (0.01%)
csh:            272 (0.01%)
php:            104 (0.00%)
sed:             40 (0.00%)




Total Physical Source Lines of Code (SLOC)                = 5,209,395
Development Effort Estimate, Person-Years (Person-Months) = 1,598.29 (19,179.53)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months)                         = 8.84 (106.03)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 180.89
Total Estimated Cost to Develop                           = $ 215,907,773
 (average salary = $56,286/year, overhead = 2.40).
SLOCCount is Open Source Software/Free Software, licensed under the FSF GPL.
Please credit this data as "generated using David A. Wheeler's 'SLOCCount'.

I tend to give GNUStep a try now and then -- not because I'm not quite happy with KDE (although I seem to remember that alt-up moved to the parent directory in our file dialog before 3.5, or am I mistaken?) -- but because I've always wanted a NextStep machine and never could afford one. It's kind of misplaced, but there you are. And GNUStep is coming along quite nicely, not so much of the "we are not a desktop environment, we are a cross-platform development environment that allows you to create apps that only work together well in their own desktop environment that you're not gonna get" anymore, but it's nowhere near polished or even usable yet.

But that's not important: what is important is Riccardo's blog, the Art is Long. Because the GNUStep guys aren't constantly pushed to make something that's more like Windows, more like OS X (okay, there's some of that, but not too much, I feel), more like Gnome or more like KDE, they have some leasure time to look around.

So, and that's the point: Riccardo pointed me at a lecture by Alan Kay [ part 1 ] part 2 ] that was pretty mind boggling. From Doug Engelbart who had a cooperative office suite where two people, each with their own mouse pointer ("bug" he called them) are working on the same document, miles apart, with a live video link in a corner of the screen, to eleven year old kids who write a ham radio circuit design app, to the slightly tubby woman who learns to play tennis in twenty minutes.

And all along really good advise about designing software and computers for users.

No, apidocs writing is not less interesting, I never said that. I like writing api documentation, but I start with it. It's part of the design phase. I like it. Unfortunately as code changes, the documentation doesn't change automatically. And since a simple code change can hit many classes, Adriaan will have many reasons to get angry because writing documentation while coding breaks the flow. And breaking the flow is bad.

And Benjamin -- I work on KMyBigApp and am not interested in working on kdelibs; in fact I promised myself I never would. Not because of any lack of professionalism, of which I have oodles, but because I believe that KMyBigApps are quite essential. It's after all why the library exists.

Anyway api documentation and unittests are not the same thing; and while I haven't figured out how to write unittests for classes in a six year old application that's had four maintainers and where everything depends on everything, I'm at least working on un-tangling the knot so I can start making unittests for new classes.

In bullet points:

• Unittests are the single biggest improvement to a development process you can introduce.
• Apidox are part of the specification of a class and are written before the code is written.
• Our tools should help us keep the documentation up to date, not badgering, nagging or annoying developers who may some ting better to do at any given moment.
• Talking about apidox and unittests in the same breath is silly. They are different things, as anyone knows who has seem hundreds of unit-tests for uncommented classes and reams of javadoc for untested libraries.
• It's not pleasing to a tidy mind, but even tidy minds have to accept that work in progress means that there may be temporary breakage.

Adriaan de Groot writes about apidox and defect reports -- not that I think the two have much to do with each other: unittests and defect rates, yes, and swiss finishing schools and quality of defect reports, there's a causal connection, definitely. But that's not important: what's important is that the api documentation is never going to be complete, perfect or even moderately useful.

And this is why: a reasonable hacker will write his code, and never document the API -- and his code will work. A decent hacker will come back and document the API even when not paid for it. An good hacker will write the API documentation first, and then start coding. (A truly excellent hacker will write the API documentation first, then the unit test and only then the code. But he's on the job full-time.)

But what happens then: the specification phase over, the dox are written, the header file looks fine. Time for the code to be written. And that means stuff changes. Code is plastic -- not rigid. But there's no automated system in KDevelop to update the parameter list in the apidox and there's no way someone who's in the flow is even able to break his concentration to update the documentation by hand. It's not a matter of resources, it's a matter of doing something that belongs to a different part of the brain, that's a different activity. Coding is not the same thing is writing prose; any suggestion that people should learn to see these activities as the same thing is ridiculous. Brains don't work that way.

(And keep in mind: doing A needs B as a prerequisite, which needs C, which needs D, which needs the rest of the alphabet: all the while the code for A is unfinished and quite probably breaks the apidox, which doesn't matter at all as long as the application isn't broken.)

And afterwards, when the flow stops and there's time to reflect, there's something else that needs attention now -- people yelling for a feature, yelling about a bug, yelling because something needs to be done. There isn't even time in an average day to check whether the apidox are broken: there's not even time enough to answer all koffice-related mail in a day.

And then, yes, I'm sorry to say, apidox don't count. There's stuff that's more important. And between a working feature that helps someone do his work with my application and a polished API documentation for an unfinished and as yet unused class file -- even if the dox will prevent my name from being bandied about... I'll choose the feature and bear the scorn.

Features cannot be synthesized by users, bugs cannot be solved by users, but developers can read the source and divine the meaning of a class -- even if that's a horrible prospect and should be the last resort.

In short: forcing folks to fix the apidox by badgering them with channel-polluting irc bots won't work. What will work is fix KDevelop to automatically write and update the apidox during code in an efficient, unobtrusive matter. Whoever cares about apidox -- fire up your editor and start coding!

Neil Gaiman

Buy this book at Amazon

Oh dear... Someone has been reading Frazer's Golden Bough again, And where Wrede and Stevermer's The Grand Tour is fun with dark edges, American Gods is weirdness with leaden edges.

It's the kind of book you open, and then suddenly find that you've read sixty, maybe a hundred pages without the text leaving much of an impression. Fluent wordwooze, was my impression. And then it starts to get seriously weird and complicated.

Not to mention philosophical, but you need to bring a lot more than rehashed nineteenth century scholarly superstitions to faze me (fortunately the book has a happy ending, even if the bit just before the ending is just as unsatisfying as the ending to Cryptonomicon.) But I'm not impressed by a comparison between a television and an altar. That's been done before, on Dutch television, too, or so I am told, not having one of the machines myself.

But in the end, a well-constructed story with some very interesting people in it -- it's just that I wish that these books would have an ending that was as good as the middle.

Well, I've learned a lot, being the release dude for the KOffice 1.4.2 release. I think that I've dropped every ball I could possibly drop, but we got the release out in the end. And I know better what to do for the 1.5 release that's for end of January 2006.

However, what during this release became clearer than ever is that we need to find a way to thoroughly do a functionality test of all of KOffice before releasing. Now we release without even having tested the most basic functionality, just kind of hoping it will work because it worked in the previous release.

Which doesn't meant that this isn't the best KOffice release ever, especially Karbon and KWord are now much better and much more stable.

However, it means, of course, that Carsten Lohrke found a crash in Krita within 24 hours of the release... Aargh!

Today, trains got delayed and rerouted around Amsterdam because some silly person spotted someone with wires hanging about and around their backpack.... As if, in this iPod era, wires are a surefire sign of a bomb.

I mean... I don't want to go all Schneier, haven't got the credentials, but it's almost like this story, that has been blogged about enough.

Look, there are plenty of ways, I'm sure, although I deny any active or direct knowledge and wouldn't be able to make a bomb to save the world from certain doom, but it's just hacking, anyway -- if I were to make a bomb, it wouldn't involve wires. Wires are so -- fifties James Bond, you know.

By the way, in the discussions in Parliament about the national ID, we were told that it was a great success: many tens of thousands of fines have been collected for the serious offense of not carrying your ID -- something that became only an offense January 1st, 2005.

However, nowhere have I been able to find an answer to the really important question: how many terrorists have been arrested because of the national ID -- nor answers to the secondary question, how many ordinary criminals have been arrested because of same. The first was ostentatiously the goal of the national ID, the second was advertised as a nice side-effect.

But everyone who is asked for his ID who isn't a terrorist or a criminal is a false positive, like an email that's flagged as spam when it isn't, and everyone who's fined is like an email that gets the "respond to this challenge then I'll know you're real" response, sort of like. So, what's the success rate? How many terrorists got caught? More importantly, would SpamAssassin have caught on with the success rate of this measure?

By the sidewalk, how many people think the data traffic retention law that's being pushed because we need that data to catch terrorists, is actually motivated and intended to catch music and movie swappers?

Trolltech favoured me with a t-shirt as a token of appreciation for the articles on Qt I used to write, like Visual Development with Qt 3.0 and a baker's dozen other articles on Qt and PyQt. Did give me a little the feeling I wasn't an objective journalist, but a shill who took presents for positive articles -- but then, I never intended to be an objective journalist, just an enthusiast who tried to tell people about the stuff he got excited about.

But although it was a veyr nice t-shirt, and though I'm though not all that stout, really, I'm not quite medium-sized. It never fit me.

Anyway, years passed by and my eldest daughter, Naomi, grew up to like black and to prefer to wear things that her peers in the grammar school she went to this year haven't seen before. I lost a t-shirt, but it Trolltech has gained a grass-roots supporter:

I just discovered that Kicker has a lovely new feature in 3.5. I always have a menubar-on-top with pager, systray, bookmarks and clock configuration, which goes well with an auto-hiding panel with some icons, taskbar and trashcan at the bottom.

However, until now, this arrangement made it quite hard to do something near the bottom of the screen, because up would the autohiding kicker pop whenever I wanted to grab the bottom of a window or click on XEmacs command line. Not handy.

Something close to this feature already was available in KDE 3.4, but there it wasn't usable with an autohiding kicker. Take a look at the 3.4 screenshot and spot the essential difference:

Of course, it would be even nicer if I could add two corners, instead of just one. But, well, I have to say that I'm very happy already.

Can wifi pcmcia cards actually break? Like, not from actual physical abuse, but with age? I've got a wireless lan at home that used to work pretty well. Six laptops, six wifi pcmcia cards. Four are Lucent Technologies Silver Wavelan cards, two are a different brand. But all of a sudden, the Lucent cards only give us a very intermittent connection.

About as bad as I had in Malaga, in fact -- and this time it's my own fault and I don't know what to do! Are the cards broken? Should the access point be dusted more often? Why do three out of six cards exhibit the broken behavior, but two others never?

Hardware, I'll never understand it. Especially when it works with funny invisible waves.

(I'd post a comment to Anders' blog, only his blogging software doesn't allow me to login. I believe it's a known problem with Drupal -- I never can login on www.kdedevelopers.org either.)

It's true -- the tables implementation in KWord is completely and fundamentally broken. There are other bits of fundamental brokenness in KWord, too. Little bits of the frames and text engine implementation.

Invite Thomas Zander for dinner and a beer, and you'll learn all about it. Bad, I know. Good news is, it's certainly fixable. The bad news is, nobody currently has the time to do that. Fixing the table implementation is a job that would take a few weeks or a month of connected hacking time. There's only so much that can be done in the wee hours between putting the kids to bed and turning oneself in for the eight hours that are so essential to keep the bloom of youth on ones face.

On the other hand, when I had the occasion to write a couple of big, complex KWord documents the other week, KWord did crash about four times a day when writing the first document. About six bug reports later, I had apparently provoked David too much. The next day, most crashes were fixed and the second document didn't pose any problems.

Except when trying to load a KWord OpenDocument document into OpenOffice: there I ran into an infamous OpenOffice bug: OpenOffice cannot load OpenDocument bulleted lists. Yes, that's an OpenOffice problem, not a KWord problem. See this bug: http://www.openoffice.org/issues/show_bug.cgi?id=52127. In short: when OpenDocument doc exchange between KOffice and OpenOffice fails, don't blithely assume it's our fault -- it may be the big guys' fault, too.

Although there's plenty to do for us, too.

And in, fact, there's plenty being done. The next KOffice release, 1.4.2, which I hope to finally create tomorrow, will include a lot of OpenDocument fixes, and the 1.5.0 release, slated for end of January, which was going to be just a Krita and Kexi feature release, is going to include even more OpenDocument fixes. In fact, for many KOffice applications, it's going to be the native file format with 1.5.0.

But all that doesn't help with our poor table feature...