Monday, May 29, 2006



Well, I am now trying to learn a very new language for me... C++.

Let's make this clear: the notion of programming language has acquired a very new meaning in the last 10-15 years and now means much more than merely a language (which is more or less set of rules how to formally lay down the algorithm, like a human language is a way to semi-formally express one's thoughts). Rather, programming language must also have certain standard libraries, or standard bindings for number of important things such that:

and many more items like that.

Moreover, a language is to include some minimal native datatypes, such that arrays, lists, associative lists, etc.

In this sense, neither plain C or C++ are languages till we attach to them required libraries; one such library is GNU libc, which includes most, if not all, of items listed above.

Still, C+GNU libc is not a language since it does not possess all required datatypes which are either native or standard. That means that virtually any not-completely-trivial programming job in C must begin with writing some "utility" functions (such as expandable arrays) or at least adopting some 3rd-party external library. Good explanation of this problem with C (suggesting C++ as a better choice) could be seen here.

In this respect, C++ does possess a uniques feature that C does not: STL. (C++)+GNU libc+STL can be qualified as full-featured language and as such compared with Python, OCaml, Java, .NET, Haskell and other popular systems.

One immediate trouble that must be mentioned is the lack of central Internet resource documenting this (complete) language. Here is a list of most important resources available:

So, what do I think of C++ as a language?

Well, I am not impressed.

Very brief list of main problems I see is:

Of course, C++ does have certain advantages over other systems (e.g. usable debugger and calling C functions with ease) but that perhaps should be a subject of another post...

UPD. Found more C++ documentation, including the ISO standard as 776-page PDF file, here.

Labels: ,

Thursday, May 25, 2006


Bittorrent client software

Dug a little bit on reach selection of Bittorrent clients to choose a good one for my Linux box; finally decided that QTorrent will suit me best for the time being. It is written in Python (making it simple to install and very much platform-independent) and UI is detailed while not congested. On the negative side, it appears not to be actively developed since about 2004, so this might be a temporary stop.

Among available alternatives are :

Opera 9 with built-in Torrent client; arguably this could be the most convenient solution except that Opera 9 is still in beta and not very stable; white it works (mostly) when you browse torrent client hangs it in a few hours because of "too many open files";

KTorrent has a lot of promise, but unlike QTorrent it is too actively developed, so it bypassed my old SuSe 9.0 system (KDE 3.1) long, long ago; even much older version 0.9 is still too new for it;

Azureus is Java-based so it can be installed and it works, but it is way too advanced for a regular user like me, with a lot of pop-up notifications, red-blue-green signs, and even automatic updates! Interestingly, this applications serves as an example how well-behaved FOSS Java-based application should be written; it can work both with SUN Java as well as with free GCC-based Java implementations.

UPD(22-March-07). There is an interesting command-line bittorrent client ctorrent. It can be configured under OpenBSD, though to do so I had to use "export LDFLAGS=-lcrypto". Do not forget to also open ports 2106-2706 which it is using by default.

UPD(15-May-07). In fact, ctorrent does not work well, it apparently has some disk access problems, perhaps only if saving torrent with too many files, perhaps only on OpenBSD. In the meantime, Opera 9 is long out of "beta" and though some problems were addressed its torrent client is I think still unusable. At the same time, my prediction above on QTorrent materialized : now most trackers refuse to talk to it citing too old version of protocol. So, I am back to using Azureus, which appeared to be not all that bad, and though I have a new machine now and supposedly may try using KTorrent, I just may stay with Azureus for the time being.

Labels: , ,

Tuesday, May 23, 2006


Acrobat 7

I almost exclusively use Acrobat (editor) to nicely fill out PDF-based forms; in Acrobat, this is called "Text Box tool" and it often seems to me I am the only one using it for it is often very difficult to find it in otherwise exploding Acrobat menus.

It is even more difficult though to customize colors and fonts for inserted text. It used to be (in Acrobat 5) that font and color were part of "text box properties" (makes some sense, doesn't it?); since Acrobat 6 this is part of special "properties" toolbar; since Acrobat 7 this toolbar is no longer activated by default; you can search all you want for "font" and "color" in the menus but you will not see it anywhere till you activate this "properties" toolbar and select the text.

Very intuitive UI, isn't it? But then again, maybe I am the only one actually using it.


Wednesday, May 10, 2006


Installing Python + ZSI on Windows

Now, who could ever think that in setting up my new laptop the most difficult thing would be to set up Python?

To be sure, Python is a very nice language, completely dynamic and OO, which allows you to implement a fast prototype for a complex object interaction. Then, you might want to re-implement in more "static" language like Java or just leave it Python if speed and reliability isn't among your first priorities.

However, another very nice feature of Python is a very well-done and well-supported Windows port, including a native Windows installer. There is a price to pay for this beauty: each Python release is implemented in specific Visual Studio C++/.NET version; e.g. all 2.4.* releases (latest stable release at this moment) are done in Visual Studio .NET 2003 (internal version = "7.1"); whereas 2.3.* releases are done in Visual C++ 6.0 (internal version = "6.0"). That said, the latest suite from Microsoft (right now) is Visual Studio .NET 2005 (internal version = "8.0"), and this is exactly what I have (by default) installed on my new laptop.

Praises to Python Windows port above notwithstanding, file, part of standard Python distribution, does not do the best possible job at detecting user's Visual Studio environment. It has not occurred to the author that the latest version it knows about (7.1) will sooner or later be superseded with a newer one; as as result, on my laptop an attempt to install any Python extension that contains C code fails with dubious message "The .NET Framework SDK needs to be installed before building extensions for Python"; message sure to puzzle someone who knows damn well .NET SDK is installed on his machine...

As a final remark, I must say that I am using Python for (effectively) RPC calls via TCP/IP using SOAP and Python extension called ZSI (along with mod-python on the server). I was using version 1.7 of ZSI, which only worked for me after applying simple patch to the client code.

Anyway, let me without further adieu present my sequence of actions:
  1. Installed binary distribution of Python for Windows; latest stable release 2.4.3;
  2. Downloaded and installed latest ZSI build 2.0rc2 (no C code so installed flawlessly); I noticed that client code has changed dramatically since 1.7 so that my patch may be no longer required;
  3. Run test script. It appears to fail because the API (specifically function ZSI.client.Binding) changed in an incompatible way. What's more, there is no API to tell me version number, so there is no simple way to write client code compatible with both 1.7 and post-1.7 ZSI API. After a while, I solve this problem by parsing function documentation string Binding.__init__.__doc__;
  4. Run test script. It fails complaining that it cannot load "xml.dom.ext.reader";
  5. This is actually very peculiar, since Python is of course well-equipped with XML DOM parsers; but yes, I vaguely remember that indeed for some mysterious reasons ZSI depends on an external expat-based XML parser;
  6. OK, I go ahead and download the latest source release of PyXML (I mistakenly think binaries are not available for Python 2.4 since this version of PyXML is rather old, but in fact they are);
  7. Build fails with message "The .NET Framework SDK needs to be installed before building extensions for Python" (see above);
  8. I try to modify file to convince it to use my installed version of Visual Studio. After a while, it does work and installation of PyXML succeeds;
  9. Test script now crashes Python executable. This is perhaps related to incompatibilities of two dynamic runtimes that Python itself (7.1) and PyXML are trying to load;
  10. I download source distribution of Python (2.4) and try to compile it from source using Visual Studio 2005. It builds simple python.exe and it crashes on startup, invoking debugger and stalling build;
  11. I remove all previous installations of Python and install older Python version 2.3 from the scratch (binaries) along with Visual C++ 6.0 environment;
  12. Following the steps described above, both ZSI (2.0-rc2) and PyXML now install successfully;
  13. Test script fails somewhere in ZSI client code. An attempt to debug it reveals that function Binding::RPC is called from _Caller with (default) argument replytype=None, which then fails in parsing. An attempt to fix this (TC.Any()) improves the result a little bit, but not all that much. It appears that ZSI changed XML marshalling logic and thus I cannot have post-1.7 client and 1.7 server;
  14. I try to install older version of ZSI (1.7 + my patch) above the previously installed (Python extension installation mechanism does not give me any simple way to uninstall); this results in empty SOAP message being passed to the server;
  15. Desperate, I simply erase the sub-directory d:\Python23\Lib\site-packages\ZSI and reinstall ZSI 1.7;
  16. Run the test script; finally it works.

Labels: , , ,

Saturday, May 06, 2006


Clock screensavers for Windows

Spent a while today trying to find a good screensaver for my new (Windows XP) laptop (Dell Precision M60). My requirements are essentially very basic:
  1. Screensaver must show time, preferably date, and as little else as possible;
  2. Must be free to use and contain no AdWare of any kind;
  3. Majority of screen estate must remain black during work of screensaver (it is screen saver after all);
  4. Should take only minuscule amount of Windows resources.
Not all that much, ah? Yet hours of search only yielded two more or less reasonable options: Analog Clock Screensaver by Lunarmedia and Digital Clock Screen Saver by Xequte Software. Is there anything else I missed?

Labels: ,

This page is powered by Blogger. Isn't yours?