My Tech Notes

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:

• Input/Output;
• Charsets/Unicode;
• Regular expressions;
• Strings/Formats;
• Network/Sockets;

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:

• C++ language structure: The C++ resources network; good explanation of basic language constructs with source code examples. Look, for instance, at their page explaining templates;
• GNU libc has official documentation .While it isn't bad, it's not perfect either. Many pieces of GNU libc can be better documented somewhere else; see for example very detailed UNIX sockets in C FAQ; there is also a good UNIX reference here.
• STL is the most difficult thing to find a good documentation for. C/C++ Reference is good but very very brief; there is also somewhat outdated but still very much useful SGI STL documentation; See also A Tour of the Standard Library from Bjarne Stroustrup.
• There is also GNU libstd++ documentation which is not really a documentation but a collection of pretty much random remarks that deal with some specifics of GNU implementation of ISO C++ standard as well as with other issues of interest;
• The official C++ page of the language creator and standardizer Bjarne Stroustrup must be mentioned here;
• Very classical C++ FAQ is very much up-to-date and has a bit of everything.

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

Well, I am not impressed.

Very brief list of main problems I see is:

• There is no simple and safe way to call C functions. Most libraries that C++ programmer is using are C libraries, and while calling C functions isn't difficult it often presents challenges copying between std::string and char* "strings", dealing with const, etc.;
• Code tends to be tedious and hard to read. Things like that: std::vector<std::string>::iterator ii=my_arr.begin() do not cause me any pleasure to read or to write;
• Lack of Java-style interfaces is killing me. Hasn't polymorphism always been considered part of OO programming paradigm?
• At least with GNU g++ error messages are often meaningless and extremely long with plenty of reference to internal include files that I have no interest in;
• In principle, wring in C++ you might not worry about memory allocations (unless you are explicitly calling new, which is rarely needed in small programs, why would you call delete?) but this might create a false sense of security; unlike all other relatively high-level language, you are writing programs without a protection of a garbage collector, and I am reasonably sure many programs are in fact leaking memory;
• STL is often a poor replacement of complex data types from other languages. E.g., functors do in principle exist but are rarely usable; number of functions is very limited. Try, for example, to print a map sorted by value (trivial in Perl or Python) and see how much code you'll have to write to execute this quite trivial and not at all uncommon task. Or, how do you like testing whether map a has key key with this code: a.find(key)==a.end() ?
• I may be stupid, but I fail to see how iostream-style formatted output is better that printf. How is this std::cout << std::hex << std::setw(8) << std::setfill('0') << ii << std::endl; easier than this: printf ( "%08X\n", ii ); (Well, actually C++ FAQ mentioned above has a direct response to that)

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: C++, STL

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: linux, software review, torrent

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.

Labels: acrobat reader

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 msvccompiler.py, 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 msvccompiler.py 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: python, SOAP, visual studio, 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: software review, windows