One of my failure until 2006 is this one:
I did not managed to release it, so at least I post the screenshot :-)
The full story/download/editor/code will be in 2007, or rather When It's Done (tm).
One of my failure until 2006 is this one:
I did not managed to release it, so at least I post the screenshot :-)
The full story/download/editor/code will be in 2007, or rather When It's Done (tm).
Warsaw Almond Cookies: taste fantastic and need only eggs, sugar, almond and two hours of baking (see the recipe). Use couverture chocolate to decorate. Of course, you still live under the rock if you can't find our beloved three letters in the picture.
Surprisingly, Google does not give anything. Is there any official English name for that? I know only Warschauer Mandelgebäck.
When Bob found out he was going to inherit a fortune when his sickly father died, he decided he needed a woman to enjoy it with. So one evening he went to a singles bar where he spotted the most beautiful woman he had ever seen.
Her natural beauty took his breath away. "I may look like just an ordinary man," he said as he walked up to her, "but in just a week or two my father will die, and I'll inherit 20 million dollars."
Impressed, the woman went home with him that evening.
Three days later, she became his stepmother.
(always from jokes4all.net)
This metric is debatable, there are duplicated and imported code, the result is different to sloccount and KOffice 2.0 is still in heavy development, but what Ohloh at the moment says about KOffice: it's worth USD 14,053,618 (256 Person Years) and its activity is still increasing:
BTW, for comparisons, KDE itself is "only" $10,750,392, Amarok is $2,405,217, Firefox is $2,173,769 and OpenOffice is at $94,036,902.
This is the follow-up to the first part of my writing on memory efficient DOM implementation for KOffice. Now my intention is to find out whether real-time compression can help to further reduce the memory consumption.
XML compression is a whole field of research. There are a bunch of compressor available, from XMill, XMLZip, XMLPPM, XGrind, XML-Xpress, Exalt, TREECHOP and many others. Since I'm not a scholar in this field (I already have my own graduate research to take care of), I have chosen a direct and brutal approach: just compress the packed nodes representation and decompress them on-the-fly. While iteration is very common, simple cache buffer for decompressed neighbouring nodes is implemented so there is no need to always decompress every single node. This method easily fulfills the requirements that I set: no need to load the whole XML (because it intercepts SAX events), allows queries and iteration (due to the QDom-like wrapper), and can be conveniently tested with the compression switched off.
There are many algorithms suitable for fast compression and decompression. Byte-aligned Lempel-Ziv is a logical and obvious choice. Again, I have very much zero knowledge about data compression. There are Ross Williams's LZRW1, Herman Vogt's LZV, Markus Oberhumer's LZO, Marc Lehmann's LZF and many others. LZRW1 is well-known although probably covered by patents. LZV has the poorest compression ratio so it goes out of the list. LZO's compression is the best, at the price of a bit more complicated state-machine, but my own implementation (since the reference implementation is GPL only) is not so fast and well debugged. LZF, the successor to LZV, is a good contender and already used (among others) in suspend2 project. On fairly modern machine with large CPU cache and reasonable branch predictor, liblzf (the reference implementation of LZF) is much slower than LZRW1. So what I did is to recreate the compressor. Armed with Valgrind's Cachegrind, my new implementation is finally faster than LZRW1.
What I am really eager to try (but no time for that yet) is Wilson-Kaplan algorithm. At least the WK4x4 and WKdm variants have been implemented for Linux compressed caching project. And since the compression/decompression inside KoXmlReader is actually involving in-memory data, this fast and low-overhead WK algorithm should be a good candidate. There are assorted patent applications for such cache compression, but I wonder whether the algorithm per se is patented.
Now on to the result, starting with the worst test document: Frequencies.ods. Just to remind you, loading and iterating this document (19 MB XML) takes 250 MB if we're using QDom but only 40 MB with KoXmlReader. Here what Valgrind/Massif reported when the compact form of the DOM is compressed and decompressed on the fly. At most, this barely consumes 8 MB. Compared to 250 MB, 40 MB is good enough, but 8 MB is great, isn't it?
Interesting is, during the parsing phase, the heap allocation increases only (almost) linearly.
The full comparison with other documents is shown below. Amazing to see how short the violet bars are.
As for speed, regardless the lightning fast packing and unpacking, there's some penalty. This graph below summarizes the timing required for parsing (light bars) and iterating (dark bars). Compare to what was shown in part 1, I only added the result for KoXmlReader with compression. Small documents are omitted because processing time is short anyway.
Of course, all these graphs must be taken with a grain of salt. But my objective is only to find out whether this all makes sense, not to write a full-brown research paper. So far I'm quite happy with the result.
It can be seen that KoXmlReader is a feasible alternative for QDom (in KOffice) as it does not incur any significant performance penalty yet the memory footprint in the worst case (Frequencies.ods) can only be one sixth (40 MB) compared to that of QDom (250 MB). We also see the additional benefit of using real-time compression. Compared to plain KoXmlReader, although in the worst case it is 1/5 slower (and there is still room for further improvements here), the allocated heap is only one fifth (8 MB vs 40 MB). Or even 1/30 if you bravely compare it against QDom (8 MB vs 250 MB).
I guess we should empirically find out how large the average documents that most people are working with. If these are less than the worst case that I tested, then enabling compression by default is a good thing because the performance penalty won't be noticable. If not, even without compression it is already much more better than using QDom.
Other than that, my aim now is to fully integrate KoXmlReader in KOffice. Hopefully someday bug #59510 can really be closed.
The November edition of LinuxUser features, among others, a review of six alternatives to OpenOffice: Applixware, Siag Office, Softmaker Office, Thinkfree Office, Gnome Office and of course our beloved KOffice.
KOffice is praised for the perfect KDE integration, its resource friendliness, the comprehensive functionalities and the outlook of its future development.
Granted, it was for KOffice 1.5.2 (although we already have 1.6 and even 1.6.1 soon), probably because KOffice 1.6 was not released yet at the time of the review. Nevertheless, that does not stop the good closing words:
Für Privateanwender bietet einzig KOffice eine echte Alternative zu OpenOffice.
A known problem with KOffice applications is the inability to cope with very large data (e.g. bug #59510). This is often related to filters, e.g. when you are importing Excel documents (see bug #85372). Fortunately, as I wrote there, this has been solved already as the filter now can produce large documents without causing the machine to consume every single bytes of RAM.
Still, a very large file can force the application to use hundred MB memory. One of the reason is because we use QDom to hold some DOMs associated with the document. Unfortunately, once the DOM gets very big, QDom would take too much memory space. And once some parts are paged out to swap, performance will degrade significantly. So when people claimed that opening 1 MB file (which is actually the compressed size, not the actual size of the XML document) consumes more than 300 MB memory, it is not exaggerated. After looking at some colorful charts below, you would hardly be astonished.
When the document is loaded, we do not need the DOMs anymore and these can be destroyed. Thus, although loading takes quite some time, once the loading process is finished, the application won't take so much memory anymore.
This topic has been discussed couple of times in the past. Last year, I started to work on a memory efficient implementation of DOM, designed to be used in KOffice. After some attempts, looks like it may after all work. And quite promising indeed.
So, how can this DOM thing be improved?
First, it's likely that we do not need to modify any elements once they are loaded from the file. The way it works is always like this: get the document, load some XML files from the storage (e.g. content.xml, settings.xml, styles.xml, ...), parse them and construct the application-specific objects from those XML files. For example, for a spreadsheet this means that we create all the sheets, rows, columns, cells, and other objects. When the application saves the document, it creates the DOM from scratch and write it to the file. Thus, when opening a file, the corresponding DOMs are not modified at all.
Second, many namespace URIs, attribute names and element values are duplicated. That alone is already a very good reason to cache common strings. For example, in OpenDocument spreadsheet, almost every cell have attributes named table:style-name and office:value-type so we do not need to duplicate them for every single cells.
The replacement for QDom, dubbed as KoXmlReader, is using these tricks. The whole DOM tree is stored in a very compact form (where the overhead per node is minimized and all duplicated strings are stored efficiently), not using all instances of nodes, elements, texts, etc. However, there are KoXmlNode, KoXmlElement, KoXmlDocument classes which correspond to their QDom counterparts. The key is, those DOM nodes are created (from the compact representation) only when we need it and afterwards they can be destroyed again. In short: it's constructed only on-demand. This way, compatibility with QDom classes is preserved (otherwise we need to modify and test thousand lines of code) while the memory requirement can be kept to minimum.
(Side note: yes, we considered using a SAX parser directly. But that means changing a lot of code and is prone to mistakes. And seems nobody is willing to do that. My personal feeling is that the gained performance is not worth the hassle, though but I'm not so sad if I'm wrong here).
How can this help? Say we're dealing with a spreadsheet. When we parse the first sheet we need all the nodes and elements belong to this sheet, but we don't care for nodes and elements associated for the other sheets. So we just load what we need (this loading even happens automagically). After we finish with it, we can move to the next sheet and at the same purge everything from the first sheet (cause we don't bother with it anymore).
I tried to make the API for node, element, text etc very much compatible to QDom. There is even a compiler define so that it just wraps all those QDom classes (to ease transition), which allowed Stefan to change all QDom references with KoXml in one amazing sweep. Unit tests - with more than 1000 checks - provide (hopefully) almost 100% coverage and should help catching bugs or incompatibilities as early as possible (also, I notice that I have one more example of what I wrote some time ago: the whole test suite is longer than code itself).
So how does it perform?
Obviously this is not a scientifically correct benchmark, but just to give some illustrations, here are few spreadsheet documents that I tested (actually I have tried many many documents, these are just some of them). The column Content specifies the size of the content.xml of each document. As you can see, once it's uncompressed, the file can be very big. Other columns are self-explained, I hope.
|permfall.ods||18 KB||92 KB||4||271|
|test.ods||18 KB||144 KB||13||1138|
|Customer_Solution.ods||90 KB||1478 KB||18||11735|
|Financial_Report.ods||143 KB||2947 KB||24||8913|
|bug85372.ods||247 KB||4754 KB||81||347193|
|Frequencies.ods||627 KB||18952 KB||3||185334|
So what happen if we load each of this document, give it to our XML parser, construct the DOM tree and iterate every single cell in the document? We won't load it into KSpread, and we won't create any data from that. We would just treat it like a plain DOM representation of a spreadsheet.
Using Valgrind's Massif, here what I got when I processed one of them using all QDom classes (QDomDocument, QDomElement, etc). As you witness, the memory consumption skyrocketed to around 250 MB although the compressed ODS file is not even 1 MB. In reality (i.e. within KOffice), of course the situation is much worse because KOffice needs also some more megabytes for its own code and data.
And this is how it looks like when I patch QDom so that the strings are cached (get the simple patch, if you're curious). It does not seem to help too much in this case.
However, using KoXmlReader stuff (KoXmlDocument, KoXmlElement, etc), at most we need only around 40 MB (see the vertical axis).
And follows is the complete comparison chart for other documents. Note that I omit Frequencies.ods - which you can already enjoy from the graphs above - because the bars for that file would be very very long compared to the others.
(There are perhaps better ways to instrument memory usage, so please take my lame attempt above with a grain of salt).
So we can see that the family of KoXml classes can be useful. But, what are the catches? For sure, we can't change the DOM tree. That is quite clear. However, as I write in the beginning, this does not matter a lot for KOffice. In other words, you can't just simply substitute your QDom with this KoXmlReader. It is designed and implemented for a very specific use case. It's not even a fully compliant implementation.
Another disadvantage is that iterating over nodes is a bit slower than QDom. The good news: parsing is faster. This is because the whole process is likely memory bound. True, KoXmlReader has some processing overhead while packing and unpacking the nodes (i.e. constructing them on-the-fly). But it definitely also accesses only a fraction of RAM compared to QDom, and we all know how slow memory operation is.
A few runs on P4 1.8 GHz gives the following chart. The light color is for parsing, the darker is for iterating. Looks like KoXmlReader does not really lag behind.
This also makes me rather excited, I wonder whether my next attempt (using additional real-time compression, wait for the Part II of this writing) would still give an acceptable performance in term of speed.
There are still few issues which must be solved before this stuff can be fully utilized in the upcoming KOffice 2.0. I'm working on that. But just for appetizer, here is the memory chart running KSpread and opening one of the test document (Customer_Solution.ods). Using QDom, the peak was about 110 MB before it settled down to around 80 MB when the loading is completed. I have no idea what caused the deep spike in the middle, this must be investigated (Is it really from KSpread? Or possibly Valgrind?).
However, when KoXmlReader stuff is used instead of QDom, the heap allocation (during the parsing and iterating) touched just about 90 MB, as evidenced below:
Please do not assume that 80 MB is what KSpread 2.0 needs to work with such simple document. What I am using is a rather work-in-progress version, so it has lots of extra stuff. KOffice 2.0 is still very far from its release date and there are still lots of on-going work on optimizations.
To be continued...
(the beauty of configurable desktop environment)
Just for fun, I told one guy:
You know what? The number of CVS commits from KDE developers has dropped to zero since months.
And surely he was surprised:
Ah, really? I thought they are working hard for KDE 4 or something like that...
This bloke apparently did not get it :-)
Another visually appealed style I would like to feature is Polyester from mart. It joins another interesting KDE styles with also interesting names (remember Liquid, Keramik, Plastik?). Polyester has a matching window decoration and some choices of color schemes.
The distinct look of this style is the glass rendering of push buttons, combo box, tab bar, menu bar, list view header, and even window titlebar. Nice, isn't it?
Tagliatelle with Bolognese sauce and parmesan cheese? C'mon, that you can get easily in a ristorante next door. Let's make something new. Here is tagliatelle with orak-arik or scrambled vegetables.
This dish can be prepared easily. Basically just stir fry chopped vegetables (use anything you can imagine) in medium heated oil with onions, shallots, garlic, chilli and quite amount of pepper. Then scramble the eggs (leave out for the pure vegetarian version). Add Italian-style tomato sauce and then serve everything together. For the European version, of course you can still have the parmesan cheese.
And happy birthday KDE!
Another interesting point in this style is some different variants of the progress bar:
If you're on SUSE, use Smart to install Serenity from standard Guru channel.
No doubt I love fish. Since many Europeans will eat fish on Friday, here is another one: ikan bumbu kecap or fish in soy sauce.
The irresistible sauce is an ancient secret. Long time ago it was revealed to me by my mother, who got it from her grandmother, who somehow (so I was told) got it from her ancestor. Basically you heat a little amount of oil, throw in lots of fresh garlic slices and after some time, add the sweet soy sauce until you get the unmistakable smell. Add some chili, chopped onions, and ginger to taste. Beware though (very much like coding), the algorithm looks ridiculously trivial but the implementation can be horrible.
The fish is simply fried. When it is ready, pour over the prepared sauce. Few additional drops of tomate sauce is also harmless. Make sure this makes your mouth water, and then serve!
Still not bored with my cuisine mumbo-jumbo? Here is another one: pisang goreng or banana fritters. This lovely snack can be found virtually anywhere in my country with virtually zero effort. But, it is also easy to make, probably with virtually no skill at all.
Na, isst du noch oder kochst du schon? :-)
Agar-agar - made from algae - is always good for dessert. For the European readers (from planetkde.org), in case you don't know it yet, you can get this from most asian shops or order it online. A small package of 9 g agar powder should be enough for the whole family. Add slices of fruits, pour some milk and few drops of honey to taste. In hot days (like fews weeks ago in Germany), put some ice cubes. Enjoy!
Still have some vegetables in the fridge? Then prepare gado-gado (something you'd miss it quickly when you're abroad), vegetable salad served with peanut sauce. It does not follow a strict recipe, so should be very easy. If you are really in hurry, peanut butter may even help. And for the vegetarian version, just leave out the boiled eggs.
So here is another 80r1n6 c00k1n6: mi goreng spesial pakai tahu+ayam+telur, roughly means fried noodles with tofu, chicken and egg. So easy to prepare you can do it blindfolded :-)
This is just like any other mi goreng recipes, except that I tend to add lots of garlic (vampires, if you read this, it is not recommended for you!) so that it smells fantastic, put few grated lemon peels, scramble the egg before frying the noodles, prepare the chicken with extra ginger and use melinjo crackers (instead of prawn ones). The sweet boiled corn perhaps does not belong to it, but since I like it, well there it is...
LyX 1.4.3 has been released. This is the third in 1.4 series and contains some bug fixes. I've been using 1.3 for some time but recently decided to jump to 1.4.
One of the interesting LyX 1.4's new features is change tracking. This is very helpful if you collaborate with other people. You can easily merge (accept or reject) the changes. Deleted texts are marked in red, modified texts are in blue. For each change, who makes it and when it is made are also recorded:
For SUSE users, I found that the easiest way to install it is by using Smart, just follow this easy-to-follow step-by-step instructions if you don't have Smart yet. From there, you just need to pick up lyx 1.4.3 from Guru's RPM channel, available since yesterday. Couldn't be easier.
If you compile from source and you are on AMD 64-bit processor, you may face a configure error. After fiddling around for hours, I found out that the solution is quite simple (and very obvious): run configure like this
./configure --with-qt-libraries=/usr/lib/qt3/lib64 --with-qt-includes=/usr/lib/qt3/include --with-frontend=qt
Alternatively you can try the CMake-based build system (yes, it's CMake!). Use directory development/cmake/ in the source tree as the argument to cmake.
Still stuck with Windows? Get the LyX installer. As I type this, version 1.4.3 is not available yet (hopefully soon, the latest is still 1.4.2). This installer will - surprisingly - install LyX and when necessary also MikTeX, aspell, ImageMagick and Ghostview. After few easy steps, you'll have a ready to use LyX system.
Update (9/28/2006): LyX 1.4.3 installer for Windows is already available.
So why are you still there? Grab it while it's still fresh.
A philosophy professor walks in to give his class their final. Placing his chair on his desk the professor instructs the class, "Using every applicable thing you've learned in this course, prove to me that this chair DOES NOT EXIST."
So, pencils are writing and erasers are erasing, students are preparing to embark on novels proving that this chair doesn't exist, except for one student. He spends thirty seconds writing his answer, then turns his final in to the astonishment of his peers.
Time goes by, and the day comes when all the students get their final grades ... and to the amazement of the class, the student who wrote for thirty seconds gets the highest grade in the class.
His answer to the question: "What chair?"
(always from jokes4all.net)
Update: finally I settle with a Motorola w205, a simple mobile phone without any unnecessary gimmicks.
I already have a black RAZR, but I don't feel that it's my dream phone. So here is a list of requirements for a mobile phone that someday I would like to own (oh, how old fashioned I am!):
1. No camera. Not a single pixel. I don't need such a built-in camera. I'm not a photographer anyway. And if I need to take pictures, I still have (and love) my digital camera. In case I forgot to bring my camera while witnessing a beautiful moment, I choose to let this moment lives in my mind.
2. No ring tone. I don't like customizable ring tones. And I prefer to have my phone just vibrates so that I wouldn't accidentally shock and annoy somebody else due to an incoming call. For alarm purpose, I still have a cheap radio-synchronized clock (with a very annoying alarm, which is important) at my disposal.
3. No music player. I hardly have time to listen to music from a normal MP3 player, let alone from a mobile phone. If I travel, I prefer to read books. Or to think about anything. If I really really need to have some music, the basic USB-memory player is usually sufficient. My music collection is very limited anyway.
4. No radio. Same reason as above.
5. No Bluetooth. At home, the only device which has Bluetooth support is this RAZR. So what's the point of having it if I could not exchange anything with any other gadgets?
6. No advanced connectivity, either hardware or software. No WAP, GPRS, UMTS or any other cryptic abbreviations that laymen hardly can understand. Except for trying WAP for the first time (back then in 2001) and just out of curiosity, I never touched it anymore. I have no urgent need to always have latest access to any web sites or my e-mails. I'm not a road warrior.
7. No Java. No games. No entertainment stuff. If I really really need to kill time by playing something, I could still practise e.g. chess in my mind (I'm a very bad player, but you get the idea).
8. No PIM applet. I am not a busy manager. My schedule is very simple and I seldom forget anything important. A simple clock and a normal monthly calendar could still be useful, but not more.
9. No color display, if that reduces both the price and the current consumption.
In exchange for the above, I'd expect these:
(a) Decent battery, and thus less often to be charged. Ideally even only once a month. In this modern world, we can have lots of different types of chargers. It would be too hassle to even deal with these chargers every now and then.
(b) Usable interface. No endless items in the menu. No flashing but useless animations. No need to tap some buttons hundred times just to start writing an SMS. No automatic default to T9 or some other text prediction system that can't be turned off.
(c) Excellent form factor. Not too small and not a large as a brick. Something physically similar to RAZR is not too bad. I prefer clamshell model because I like it and I think it's more practical to use.
(d) Can be used to place and receive a call :-)
With this no-music, no-web, no-fancy-stuff, no-singing-and-dancing requirements, I guess I have to go back to an old model. But which one then? What would you recommend?
Normally we tend to admire those who can spot the small details that others will not even bother to notice. But sometimes it can be a different situation:
A: So to prevent the copy, here I define a copy constructor but I place it in the private section of the class.
B: (after carefully analyzing the implementation line by line) But you don't implement this copy constructor at all. It's in your class declaration but I can't find it in your .cpp file.
A: No need to do that. I don't want to implement it. I just want to ensure that it won't be called because it's private.
B: (again reading the implementation code) Is there a reason why you won't implement it?
A: (already slightly upset) No specific reason. You can implement an empty construct for that copy constructor in the .cpp file, if you want.
B: Then you'd better write that empty construct. What's so difficult about it? It's better to do that rather than taking the easy way out not to implement the copy constructor.
A: (decides that it is useless to argue) OK.
A ends up being annoyed for the whole day. Not only he wastes his time with this unnecessary hyped drama, he is accused of taking "the easy way out".
This case could also possibly explains why some untrained eyes file a compliant because you did optimize part X of the program but simply skipped part Y. The same eyes did not watch you as you spent few sleepless nights with the profiler.
Update: don't fancy compiling/testing the code? See the short video clip.
I found one piece of code which I wrote a very long long time ago.
Remember the original Quake? When you submerge, the software renderer performs a simple but interesting effect. The view is somehow warped periodically. It turned out that you just need only few lines of code to achieve such effect. Just see the code if you're curious.
Of course, looking only at the above screenshot is not enough. You must see it in action.
This could be another example of bad usability.
An optical attenuator is - without doubt - a useful device in lab works. A variable one is suitable for many practical tasks. One of the variable optical attenuator from a well-known vendor has a front panel like this (I know, this sketch is lame):
The seven-segment display shows current attenuation level in dB. It can be changed using the three buttons next to the display (under the label VERNIER).
The INPUT and OUTPUT ports are very clear, they are where you plug the fiber connectors. The light coming out from the output port has less power (as it is attenuated) compared to when it enters the input port.
The POWER switch (it's toggled switch BTW) has a red LED. The meaning of this LED is also quite clear. If it is on, then the device is powered on (which just makes sense).
It is the DISABLE switch that is quite of a question. This switch has also a red LED attached to it. However the meaning of this LED can't be deduced easily, or you may need to consult the handbook to confirm your understanding. For example, if we take it that when the LED on the POWER switch is on than the unit is powered, does that also mean that if the LED on the DISABLE switch is on than the unit is disabled? Or is the other way around, an active indicator (like the LED) means that the unit is actually enabled?
And what does disabled actually mean? Does it mean that no light is coming out from the OUTPUT port, i.e output is fully blocked? Or does it mean no attenuation takes place (i.e. the output power is the same as the input power?
This looks simple, but consider that the light might end up in a sensitive (and possibly also expensive) photo detector. Yes, people shall read the handbook first, but such simple matter should be straightforward anyway.
It's been in the news since one month, but only recently I got that message when using Google:
If the API is made open, it will be interesting to integrate this into open-source browser (Konqueror and Firefox) so that the URLs which typed in by the users (not only the URLs given by Google) can be checked for badware as well. Of course, there's a privacy issue here to be taken seriously.
To spark again my interest on 3-d programming, I decided to buy some games. Since I know a bit about the Quake engine, I wanted then to try something not based on it. And it doesn't need to be new. I am not a gamer, I just enjoy the technologies behind a game.
So when I looked around in a consumer electronic shop, I spotted Raven Shield, the third installment of Rainbow Six, that is using the Unreal engine. It was sold at a very cheap price. Looks perfect. Ghost Recon was also available at a special discount, but then I thought two might be too many. So I happily grabbed Raven Shield, went home and gave it a try. I found that it is very similar indeed to Counter-Strike, so no difficulty so far. The characters are also familiar, since for quite some time ago I finished almost all Tom Clancy's novels.
A few days later, while shopping in a big supermarket, I stumbled to a corner where old games were offered. The price was even more unbelievable, half of what I paid for Raven Shield. I doubt that it can even cover the CD and packaging cost. So I searched for something interesting and finally got Vietcong and Splinter Cell. Just before I left, (to my surprise) a box which looked very familiar caught my attention. It is nothing but that Raven Shield! So, if I can wait a few days, I'd get it cheaper. What a coincidence.
But it did not stop there. Last week when I searched for some reading, a game magazine looked quite interesting to me. I wanted to buy it until I realized that this magazine includes a full version of Raven Shield and Ghost Recon! These are exactly what I wanted the week before. It took couple of minutes until I could decide not to buy that magazine. I somehow believe that in few weeks, there will be another magazine which includes only Ghost Recon.
After all, perhaps all I need is just a magazine subscription.
If you learn enough German but then need to write or speak in English, you may often be tempted to use the following words (at least, in my case):
trainer. It looks like a perfect English word, except that it will confuse people. What is usually meant is actually coach.
mother language, because the German word is
die Müttersprache die Muttersprache, but it should be either native language or mother tongue.
I read a roman, and yet difficult to catch because Roman is likely something or someone from Rome. It should be then a novel.
make a picture while the word make here should be take instead.
I was late to realize that the legendary Turbo products will be back in 13 days. So far Turbo Delphi, Turbo C++, Turbo Delphi .NET and Turbo C# will be offered, with the EXP edition that can be downloaded and used for free. Although this is surely interesting, especially for the hobbyists, I reckon many would be very happy if the Linux version is also available (either "pure" or through Wine). Even better when Borland/Devco can as well decide to create Turbo Python or Turbo Ruby :-)
If you're feeling nostalgic and can't wait, even today you can already perfectly run the free downloadable Turbo C++ 1.01 in a Dosbox session (try it in fullscreen!). Of course this version is considered ancient, but it works well and it is still useful to quickly try new stuff (or cross-compile for DOS).
BTW, that Delphi Oktoberfest video is quite original. Try not to read the subtitle :-)
Recently I got WordPerfect 7 suite from ebay (which apparently can only be installed in Windows 95, but I don't really bother to install it) which comes with over 5000 clip-arts in WordPerfect Graphics (WPG) format. The total size is over 200 MB. This is a ideal test for libwpg and its tools (wpg2svg and wpg2odg). So far, the conversion tools do not crash handling all of them. I let it run also under Valgrind, and it is still running as I write this...
BTW, thanks to klik technology, the easiest way to check libwpg-based WPG support in Inkscape (what I wrote before) is by klik://inkscape-latest. Details can be found in http://inkscape-latest.klik.atekon.de. A very convenient way to check those old WPG collections.
Meanwhile wpg2odg starts to reach the same support level as wpg2svg, except where some complex gradients which can't be handled properly in OpenDocument Graphics format. It does not matter, as such uses of gradients are very rare anyway (from what I observed on those clip-art files).
Compare what OpenOffice.org shows below against what Inkscape renders (ignore the different proportion as I resized the whole picture in OpenOffice.org already). I really hope that future version of OpenOffice.org supports anti-aliased painting.
Back to those 5000 clip-arts. Now I have thousands of SVG and ODG files as well as a very long Valgrind log to analyze...
I just tried it on SUSE 10.1 and it works flawlessly. It is also reported to work on Kubuntu, Ubuntu and Kanotix. If you do not have klik yet, it's very easy to prepare. For other details, check also http://speedcrunch.klik.atekon.de.
Just one verse of Juste Avant Toi and you can't mistake it. I wouldn't be surprised if this latest single from Anggun will be a hit. The video is also good, apparently shot in Indonesia.
The English version is I'll Be Alright, but somehow Juste Avant Toi feels better.
The next KDE 4 is expected to be available also for Windows. But even now we can see already a trace of KDE technologies on this platform: Swift the web browser. It's based on Webkit, which is based on KDE's very own KHTML and KJS.
The alpha release itself is not ready yet for prime time. It has bugs and rough edges and many stuff necessary for modern web browsing are not yet fully functional. But it's indeed a start.
Like its name, it's simply very fast.
Winter is about seemingly complex conflicts around a family drama. With the background of Germany, in particular Berlin, in the first 50 years of the last century, the two central characters Paul and Peter Winter took a different route for their lives and yet they must once a while cross their paths, the last being the most tragic one. The story also involved many of their relatives, with quite some twists, intrigues and entanglements.
All in all, it's just dark but fascinating, involves all things about love, hate, horror, pain and suffer. What I like most is that the characters are not simply "black" or "white", almost everybody is portrayed as "grey". The details are amazing, as with typical Len Deighton's novels. It's hard to put, it's unforgettable and simply worth to read.
Bomber is, to put it mildly, Len Deighton's narration of Murphy's Law. A large RAF raid carefully planned to bomb Krefeld in the Ruhr area, mistakenly placed almost every single bomb in a (fictionalised) small country city named Altgarten. In this damned event in the last day (which was, 31st [sic]) of June 1943, both sides took big casualties. There is no single main characters, with lots of Britons and Germans both affected the main story.
Again everything is rich and super detailed, from the price of one RAF's Lancaster to the operation of the German radar array. The storyline is pretty much linear albeit with many (but relevant) flashback. In the beginning perhaps it feels rather slow, but up to the vivid minutes in the dogfighting, it is just awesome. Don't expect a happy end, though.
Shogun, set in Japan around 400 years ago, is the first of James Clavell's Asian Saga. Blackthorne and the crew of Erasmus had to land in Japan and soon he was trapped in the conflict between two great daimyos Toranaga and Ishido. Blackthorne supported with Toranaga. He adopted Japanese culture and life style and was quick to learn the language. He was later known as his Japanese name Anjin and (quite predictably) he felt in love with a Japanese woman. There are surprises but the story is indeed touching.
The characters are strong and living. Obviously here Blackthorne is depicted as someone who is willing to see the new strange culture as the Japanese see it, not from the view of a westerner. It is fascinating to see the his transformation from "the barbarian", a meat eater who seldom took a bath and did not appreciate cleanliness to someone who later on knew well and lived the style of a Japanese. Not Musashi, but as amazing as it could be.
Fast forward two and a half centuries: Tai-Pan. This second part is about Dirk Struan, a Scotsman which lead the Noble House during the years Hong Kong for the first time became a colony of England. He's smart but ruthless, seem to have a full bag of tricks in order to save his life and protect those he cared. He manipulated almost every persons in the book, most critically Tyler Brock, his number one competitor and enemy.
Just like in Shogun (one can see Clavell's pattern here), Tai-Pan's Dirk Struan moved away from a filthy barbarian and respected and enjoyed the local customs. He had a Chinese mistress which taught him many peculiar aspects of Chinese's way of life. Dirk Struan's life story is simply impressive. Page turner, without doubt. And although this book took many hours of my sleeping time, by the last page, I really hate that it must end.
Epilog: still, many other novels from Len Deighton and James Clavell are still in my stack.
As I wrote before, finally I manage to correctly handle the stroke and fill in wpg2odg. The result can be witnessed in the following screenshot:
The two landscape pictures opened inside OpenOffice.org are in OpenDocument Graphics (ODG) format, converted from the corresponding WPGs (which are shown in Corel Presentation on the left side).
There are still bugs on some corner cases. When I clean this up, then I'll commit everything so that it's ready for public testing.
pool poll at kde-look is very hilarious! As I write this, the result (from the most voted one) is like this:
Interesting suggestions from the comments are:
So, cast your vote!
Jambi is the next Qt technology for integrating Qt and Java. When I saw the name for the first time, I couldn't stop wondering. Why is it Jambi? For those who do not know yet, it's also the name of a province in Indonesia, but that province is in Sumatra, not Java.
There are still good places in Java which may make a good name (Jakarta is already taken by Apache), for example Jepara, Jogya (old spelling), Jombang, Jember and perhaps couple of more that I couldn't remember.
At least, it's not Jampi :-)
I hope I don't bore the readers with another Whiskey-Papa-Golf goodies.
So far, at least I make some steady progress with the wpg2odg. Yes, this is a command-line tool which will convert WordPerfect Graphics into OpenDocument Graphics. From perfection to openness, so to speak. The corresponding UNO service (for seamless import from within OpenOffice.org) is planned, but I can't say when I could finish it.
As style handling in ODG is more complicated than SVG, my work with respect to stroke and fill properties of the objects isn't very fast. However, at least the outlines/paths are already imported properly. Shown in the screenshot below is OpenOffice.org opening eiffel.odg, which is the result of running "wpg2odg eiffel.wpg eiffel.odg". Compare it to the rendering in Corel Presentation and Inkscape as in my previous blog entry. So, it's like Eiffel in wireframe mode.
Of course, it's rather boring. But given couple of more days, I hope all the wonderful colors will be there.
Since libwpg is designed to be portable, I checked its status in non-Linux environment. So far I have tried to compile it on Win32 (not necessarily as dynamic library, lack of knowledge from my side) and it works well. At least with Microsoft, Borland, and GCC (Mingw) compilers. I am going to give it a try with Digital Mars and OpenWatcom later on, but I don't foresee any serious problem with the code.
I used the chance also to verify Perfectspot, another toy of mine which uses libwpg to show WPG files. So basically it's a stand-alone WPG viewer. I'll perhaps release it when it's fully polished, not sure yet whether there is a demand for such tool. Perfectspot is Qt4-based and using Arthur to render the graphics onto the screen. Screenshot can be seen below. The beautiful Earth is drawn by Marcelo Staudt (available in from Open Clip Art library). I just imported his SVG file into Corel Presentation X3 and then save it as WPG. Perfectspot opens and displays the WPG file just fine. Note how smooth is Perfectspot's rendering due to the antialiasing feature in Qt4, compared to that of Presentation's.
Since this blog got anothers hits from someone at microsoft.com with respect to WPG stuff, I decided to find out how good is the support for WPG in Microsoft Office. I inserted my favorite windmill picture (see the entry on gradient support) in PowerPoint 2002 and this is what I got:
Seems that the importer and/or PowerPoint has problem with compound polygons or grouped objects. Look at the blade in the middle (which consists of some sub paths), it should be transparent just like the other blades. Compare it to what our wonderful Karbon14 renders:
Also notice the lack of antialiasing in PowerPoint. Strangely enough, this is only for imported pictures. When I clicked and converted the inserted picture into Office drawing, then it was smoothly painted.
Alas, I saw another problem with the gradients. Instead of creating polygon with gradient fill, the import filter of PowerPoint splits the polygon into smaller polygon and fills it with solid color, as can be seen below (I select couple of those polygons to show that they are many many small objects indeed). You can quickly spot it if your eyes have native Sobel filter :-)
Is it only the case with Microsoft Office 2002? To verify it, I gave Office 2007 Beta a try. Despite its brand new user interface, it is just the same case: one blade is not transparent and gradient is converted to color bands:
Conclusion: when I am finally finished with all this endeavour, it is likely that applications like OpenOffice.org, Karbon14, and Inkscape can handle WPG files better than Microsoft Office. Or should we ask Microsoft to just use libwpg?