Figure 1: original problem

Maybe some smarter people can spot a better way of solving this one, but in my case I’m stuck for quite some time before realizing the next solvable cells can be determined using addition and subtraction of areas again. And finding these areas are definitely not easy:

Figure 2: step 1 (horizontal)

Figure 3: step 2 (vertical)

Subtracting red area (calculated vertically) from green area (calculated horizontally) gives A+B=17, therefore A=9 and B=8.

Is this the end? Not so soon! Two more cells can be determined with similar method and similar areas:

Figure 4: step 3 (horizontal)

Figure 5: step 4 (vertical)

After similar subtration (green area minus red area), we got A-C-D=1. As it was already found above that A=9, thus C=2 and D=6.

Probably this is the last post in the kakuro series until some more elegant strategies can be found, because I don’t have much info to add about subtraction of areas.

Immediately after registering and paying for Mup Music Publishing program around summer 2001, I was so fascinated with its ease of usage and simple syntax, so that Lilypond (at that time the only free software for music typesetting) was ditched with no second thought, and even wrote an article about Mup in LinuxHall magazine (disclaimer: I was an editor for the magazine). It was rare for me to prefer shareware to free software, but this was the rare case. With such great tool I saw a glimpse of hope for my wild ambition: getting Prokofiev’s second piano concerto done. Undoubtably it would be a daunting project, especially when considering the user-unfriendliness of Lilypond (it was/is programmers’ solution to typesetting, not musicians’ solution), but with Mup I could see the light of getting the beast done in a year or two: an almost 150 page of orchestral work, containing many obstacles not solvable with simplistic notation programs (though not as bad as contemporary music).

Cross-staff stem

Indeed, it turned out Mup was not that perfect at that moment: cross-staff stem was not doable. That implied giving up and waiting for Mup to implement the functionality. After a long wait, it’s finally there; so a happy user could continue the crusade, after maybe one year later.

That had become sort of a cycle: typesetting till a certain point, an obstacle was encountered, report and wait till Mup has support implemented, and go back to step 1. In these many years, Lilypond has grown a lot too. However, no matter how versatile it was, there were 2 major reasons I actively distant myself from Lilypond:

• In the old days vertical spacing between piano staves had to be defined manually using code! (also see what’s done in newer version). That’s RIDICULOUS. No notation program should be called ‘usable’ under such circumstance. To say bluntly, it’s perhaps better off using image editing program to fix the spacing afterwards.
• The constantly changing syntax made me really uncomfortable in using Lilypond for any serious purpose. Any major release, any minor release, and even any patch level contains incompatible changes, some as ‘trivial’ as changing plural form for settings (yes, same code wouldn’t work in later version unless using convert-ly to add or remove an ’s’). There was apparently no discussion about the names of settings used, and maintainers seemed to be toying with names arbitrarily at will.

The problem

Everything went on as usual up to a certain point: cross-bar beaming. To put it exactly, I was completely stuck typesetting this passage (from last movement):

While I could anticipate Mup fans introducing lots of hacks or manual drawings to attempt working around the problem, it’s no cure. Changing paper size, and BOOM! All hacks and manual drawings would be broken then. Despite being placed in feature request list (#280), Mup maintainer had not even attempted touching it, while Lilypond had this feature since history. The refusal (well, almost) of Unicode support also saddens me much, though I was well aware of the fact that with currently arcane and spaghetti structured code base it sounds immensely difficult to add Unicode support. Anyway, no cross-measure beaming means 3 straight years of abandoning the project, expecting it would never finish.

Yet the final blow comes recently. While checking out if Lilypond has any new feature, one particular line caught my eyes:

Vertical staff spacing using a skyline algorithm

It very much means an important blockade from using Lilypond was removed. Vertical distance between staffs are now automatically computed and adjusted. Though still maintaining my point of view as programmers’ user-unfriendly solution to typesetting and as the one I dislike most, I actually start to see the potential of finishing the whole thing with Lilypond now, despite taking much longer time than needed using Mup. That’s a great disappointment, because my favorite one failed to do the job while another has progressed far enough to overcome the problem it had. Maybe the definition of love and hate should be refined after all…

The point

Nothing is perfect. Perhaps using Finale and Sibelius, the de facto standard, would mean less headache and less complaining, yet also means people can’t easily modify it (my typesetting is certainly lousy). The reason of my insist on using text instead of point-and-click program is mainly a preference on speed — I feel working much faster this way. But still, completely rejecting GUI programs could be my fault. The persistence on ignoring other tools is, in the end, a hindrance.

The development models are significantly different between Lilypond and Mup:

• Mup is developed and maintained by (purportedly) 2 persons. Despite the open source nature, it’s actually a shareware. There’s a mailing list for discussion, but it’s not public. There’s not much discussion about development too, I’d say it’s a pure user discussion and announcement list.
• Lilypond is mainly developed by 2 persons too, though more helpers are willing to contribute, and development is more transparent, following free software paradigm.

Such difference decides their fate. Mup is completely user-oriented, so people attracted to it are mostly users who want to get the work done. This spells the pros and cons: easy to use, less tweaking (well, the way for extension is to embed PostScript directly), the wait-for-me-to-feed-you style of feature development.

OTOH, Lilypond is much more programmer oriented (usage of scheme as script language, programming-like TeX syntax), so the ones it attracted are more programmer-like minded. Almost all balanced reviews (NOT those written by fanboys) regard it as one of the most difficult to learn but most flexible.

The (dis)advantages of various development models have been discussed to death; I’m not going to even think about it anymore. The lesson I’ve learnt is, try to learn other tools, even the disliked ones. It is entirely possible that the disliked tools help accomplishing the task.

• An odd problem which seemed to affect earlier WordPress 2.8.x versions is just gone, for unknown reason.
• When trying to replace the category list retrieved from get_terms(), PHP simply segfaulted, at least on my machine. Failed to get any meaningful error message, nor can I deduce any reason so far.

So for now I just settled in showing empty categories in sidebar widgets, which should work as an internim solution (categories containing ONLY private posts are not shown by default, as the public post count is zero). Of course, the side effect is that even genuinely empty categories are shown as well. I’ll see what can be done later.

Even if a file with the same name and location gets trashed many times, each subsequent trashing must not overwrite a previous copy.

So what is this holy shit called GNOME doing? Originally, I expected those FreeDesktop people still don’t get it after the other most widely used OS have done that 12 years ago (maybe even longer), but it looks like the wrong people have been blamed all along. So lucky it’s not written down till now.

Even FreeDesktop Trash specification has the statement stressed in italic letters, yet GNOME freetards in their infinite wisdom are not follow it! Good job! Looking at how GNOME had implemented previous trash can (which was just yet another directory — an excellent topic for jokes), I didn’t expect much would be done in foreseeable future though.

其餘的時間，都接近是這位師奶的 solo performance：親戚的仔女如何被父母縱壞，菲傭好還是印傭好，諸如此類，都是生活上的鎖碎事。由於沒甚麼經驗，插不上嘴，唯有仔細聆聽。但本來日日如是、平凡悶蛋的早餐，變得有趣味多了。

香港人也許就是缺乏這種親和力。

While Google Webmaster tool does its job well (even Microsoft one too), Yahoo Site Explorer (interesting that it’s not named Webmaster tool like the others) simply adds no value to webmasters except confusion, impatience and disappointment. The reason?

• While Google and Microsoft one allows authentication of site using META tag, similar function by Yahoo simply fail. No idea, and no comprehensive error message. Yahoo just fails and tells you it would retry again later.
• Once Yahoo fails to validate your site, what’s next? Revalidate immediately? NO! Even if you choose alternative method (uploading a file into web root folder), it would just indicate that validation will be pending some time soon. How long? No idea.
• Therefore, for people impatient enough to demand immediate validation, one have to remove and readd the site, and revalidate afterwards using file upload method. No other choice.
• Once validated, can I just revert to previous site content? OK for Google, not for Microsoft and Yahoo. In Yahoo it is indicated clearly:
  

  We will revalidate your site ownership by checking this file regularly.

  We will revalidate your site ownership by checking this META tag regularly.

• Taiwan version of Site Explorer is equally stupid, one have to stick an image on web page for validation! Speechless. Can’t it just use some less intrusive method for validation?
• Too bad that Yahoo doesn’t accept any sort of XML sitemap.

For the functionalities after validation — well, my opinion is, no one is perfect (a combination of all 3 as a single website management tool is most desirable). However, if I were to pick one, I absolutely would not pick Yahoo. So far the only thing worth mentioning is, Yahoo allows removal of selected URLs containing certain substrings or GET parameters.

For example, such HTML is usually found in blog header:

<meta name="generator" content="WordPress 2.6.5" />

Broadcasting version is generally believed to be a sore point in blog security — it invited crackers to determine easily which blog is exploitable, thus the existance of such plugins. It reminds me about a plugin I have written for myself before, for similar purpose. But on second thought, I didn’t publish and advertise it. Why?

Version can be decided though other means

Since recent WordPress releases (not very recent though), WordPress also emit versions in javascript links. Take my own blog for example:

<script type='text/javascript' src='http://me.abelcheung.org/wp-includes/js/prototype.js?ver=1.6'></script>
<script type='text/javascript' src='http://me.abelcheung.org/wp-includes/js/scriptaculous/wp-scriptaculous.js?ver=1.8.0'></script>
<script type='text/javascript' src='http://me.abelcheung.org/wp-includes/js/scriptaculous/effects.js?ver=1.8.0'></script>
<script type='text/javascript' src='http://me.abelcheung.org/wp-includes/js/jquery/jquery.js?ver=1.2.6'></script>

With javascript versioning, WordPress version can be approximately determined. Even worse, these declarations can’t be disabled. That means just hiding WordPress version is not effective anymore, regardless of other reasons.

Exploits are generic enough to ignore any versioning

While WordPress fanboys are retarded enough to declare any security measure as “obscurity”, this one is probably right. Version hiding is very likely defenceless against most exploits, which simply tries every possible attack method. This renders version hiding pointless.

It affects functionality of other plugins

Some other plugins do check WordPress version in order to behave differently. Take a look at the comment of bs-wp-noversion plugin (which is yet another version hiding plugin). WordPress rendered broken is a possibility if version is changed or hidden.

Something is very wrong here. What happened? Is sed buggy?

$ cat xxx.csv
113.941112252,22.2889218875
113.941063733,22.288921817
113.941160771,22.2889219579

$ sed 's/,/e,/; s/$/n/' xxx.csv
n13.941112252e,22.2889218875
n13.941063733e,22.288921817
n13.941160771e,22.2889219579

If nobody can solve this mystery in this weekend, one more hint will be provided in the coming Tuesday.

中環渡輪碼頭外的是南中國海；

九龍和香港之間一條隧道都沒有；

彌敦道和旁邊的橫街是對等的存在；

香港從來沒有一間稱為「城市大學」的建築；

那麼還會不會這麼憤憤不平？就算要指出 Google Maps 的錯處，也不會像是 Google 負了大眾一樣的態度吧？固然 Google Maps 還有許多有待改善的地方，但它已經是全港僅有的兩個值得改善的地圖之一 (另一個要算是中原地圖)。真是身在福中不知福！