A C programmer can write C in any language, until he gets lazy and remembers Perls regular expressions still work at four thirty in the morning.

My laugh of the day….

Early Unix hackers struggled with this in many ways. In the languages of 1970 function calls were expensive, either because call semantics were complicated (PL/1. Algol) or because the compiler was optimizing for other things like fast inner loops at the expense of call time. Thus, code tended to be written in big lumps. Ken and several of the other early Unix developers knew modularity was a good idea, but they remembered PL/1 and were reluctant to write small functions lest performance go to hell.

Dennis Ritchie encouraged modularity by telling all and sundry that function calls were really, really cheap in C. Everybody started writing small functions and modularizing. Years later we found out that function calls were still expensive on the PDP-11, and VAX code was often spending 50% of its time in the CALLS instruction. Dennis had lied to us! But it was too late; we were all hooked…
— Steve Johnson

Hmm, I’ve always wondered why some really old programms written in C look so odd, as if the person had never heard of a function call (or macro) before. I’ve never been able to figure out if it was because many function calls were more expensive on the hardware back then, because the programmer was used to assembly, or loyality to some “style of the day”.

I guess that clears that up a bit more; if so, thank GOD he lied!

Strange behavior with this bit of C++

It has been a long time since I’ve had time to do anything in C++. So I figured it would be a useful way to limber up my memory, by implementing a little bit of my favorite Python classes/modules in C++. The only crazy thing, is the result this code has yielded.

// minimal program, using the code involved
#include
#include

extern "C" {
#include <sys/param.h>
#include <unistd.h>
}

namespace os {
bool link(const std::string& src, const std::string& dst);
}

bool
os::link(const std::string& src, const std::string& dst) {
if (link(src.c_str(), dst.c_str()) != 0) {
std::perror(NULL);
return false;
}
return true;
}

int
main() {
std::cout << "link()t" << std::endl;
os::link(std::string("./test"), std::string("/tmp/test"));
return 0;
}

compilation: /usr/bin/g++ -Wall -ggdb3 os.cpp test.cpp -o test

I compiled on FreeBSD 7 with the systems GCC 4.3.1 and get a segfault, then tried the code on my OpenBSD 4.4 machine. The OpenBSD 4.4 release has shipped with a patched GCC 3.5.3 (propolice) – on OpenBSD it ran perfectly! Trying to feed it through the debuger on FreeBSD wasn’t pretty either:

  • FreeBSD 7, system GCC 4.3.1 -> test program dies with a Segmentation Fault.
  • FreeBSD 7, system GDB 6.1.1 -> Endless stepping when used with a break point, or SIG SEGV in libc’s malloc() when run.
  • OpenBSD 4.4, system GCC 3.5.3 -> prints proper message from std::perror() as expected, when the program is executed.

If I change os::link to os::link_x and recompile on FreeBSD, it works the same as it does on OpenBSD, when unmodified that is. In a few tests on FreeBSD, When I run the program under GCC, it tells me

Program received signal SIGSEGV, Segmentation fault.
0x281fabc3 in malloc () from /lib/libc.so.7

if I set a break point in test.cpp on the os::link() call, and step through it into os::link() in os.cpp. If I keep stepping after the link(), I get returned to the os::link() call in main and can step through it all again. Like an endless loop of stepping into/out of the os::link() function call in test.cpp’s main(), and the if-conditional in os.cpp’s os::link(), geeze.

At least looking at the results I’ve had tonight, I know I’m not freaking nuts… lol. I still shouldn’t write code when I’m half asleep, but hey… It’s the only time I get :, Oh well… unless my family is late as usual, I need to be up in a few hour.

*head hits laptop, snores loudly until morning*

Ever wonder just what gcc does?

Terry@vectra-$ cat > test.c
#include <stdio.h>

int
main(int argc, char **argv) {

int i;

printf("%s ", argv[0]);
for (i=1; i < argc; ++i) {
if (argv[i][0] != '') {
printf("%s ", argv[i]);
}
}
return printf("n");
}

Terry@vectra-$ gcc -v test.c -o test-bin
Reading specs from /usr/lib/gcc-lib/i386-unknown-openbsd4.3/3.3.5/specs
Configured with:
Thread model: single
gcc version 3.3.5 (propolice)
/usr/lib/gcc-lib/i386-unknown-openbsd4.3/3.3.5/cc1 -quiet -v -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=5 test.c -quiet -dumpbase test.c -auxbase test -Wall -W -Wpointer-arith -Wbad-function-cast -std=c99 -version -o /tmp//ccj26536.s
GNU C version 3.3.5 (propolice) (i386-unknown-openbsd4.3)
compiled by GNU C version 3.3.5 (propolice).
GGC heuristics: --param ggc-min-expand=46 --param ggc-min-heapsize=30393
#include "..." search starts here:
#include <...> search starts here:
/usr/include
End of search list.
as -o /tmp//cca26536.o /tmp//ccj26536.s
/usr/lib/gcc-lib/i386-unknown-openbsd4.3/3.3.5/collect2 --eh-frame-hdr -e __start -Bdynamic -dynamic-linker /usr/libexec/ld.so -o test-bin /usr/lib/crt0.o /usr/lib/crtbegin.o -L/usr/lib/gcc-lib/i386-unknown-openbsd4.3/3.3.5 /tmp//cca26536.o -lgcc -lc -lgcc /usr/lib/crtend.o
Terry@vectra-$ ./test-bin arg1 arg2 arg3 arg4 arg5
./test-bin arg1 arg2 arg3 arg4 arg5
Terry@vectra-$

Days recap

Quite a full day, if not very productive :

I was up to around 0500 last night, I dunno why but I never seem to get much sleep lately lol. The other day, I thought I was getting to bed early, and it was 0430’ish, well.. an hour early then the two days before I guess hahaha. Tried to sleep in today, since work didn’t start until the afternoon — not much luck. At least though, Tuesdays job is more time consuming then strenuous, tomorrows job on the other hand… Is more so a pain in the ass, then it is time consuming.

One thing odd, I heard Amanda kicked Adam out and that he’s staying with his parents again. Not a good sign in my opinion. Especially since, as memory serves, in 2007 I’ve seen and heard of a lot more people getting divorced or dying. 2008, I had somewhat hopped would put that incremental stream of numbers to an end lol.

One of these days, I really ant to take some time to write up a review of Google Chrome — I love that freaking thing!!! And whether the V8 JavaScript engine is really THAT fast or Google is taking advantage, gmail is so snappy on loading + the seperate process per tab thing, means no more browser-locks when launching gmail. Google Chrome is enough of an improvement over Firefox 2.x, that I might actually be able to re-take control of my inbox, if I ever get a linux binary package to use on my FreeBSD box… or better still, a native binary ;-). Perhaps it would be more fair to compare it to Firefox 3, but I use Flock 1.x most of the time, which is based on Firefox 2.x. And in all honesty, I hate Firefox 2 when compared to Firefox 1.0,x-1.5.x, it’s just lost that feeling I guess… I just don’t like the changes, and Firefox 3’s alpha builds didn’t look like an improvement. Although, I do have FF3 installed on SAL1600 just in case, but more so because it’s a newer version.

Google Chrome, I think is perhaps the best thing since Lynx and HTTPS but who knows >_>

As far as my efforts to standardize myself around 1/2 languages + what we use on [SAS], has fallen back into deadlock. Every way I slice the pie, Python seems to be the best choice for all of my needs, hell… The only time I’ve had an interpreted language come out as to slow for jobs I’ve tried to use them on, is an oddity. A script had to invoke perl so many times to process text, that it was faster to invoke sed/awk instead, which could actually be considered interpreted languages I guess lol. Some of the things I’ve heard about Python 3000 alarm me in that regard, but I’m not very concerned. The real problem is, I prefer C, but I don’t have *time* for C. When it comes to using C++ for tasks, I look at it as a two edge sword. More time savers then C but they all go out the window, in situations where they are not helpful.

That and working with gtkmm on Windows will probably be a pain in the royal hind quarters when it comes time to link against stuff. Although, I rather think a combination of Boost, Qt, and libs used in gnome is a good idea. The odd thing? C++ is not actually a language that I like a lot, but hey… beats Java I guess :

Java would actually be a perfect tool for my needs, except I don’t want to have to write in Java that much loooool.

Of languages, libraries, and tools

I have been contemplating my standard language/library issue with care, although I’ve yet to finish most of the tests…. Courtesy of work, laziness, and to much work on the website lol.

So far, it seems to me that language wise my best thoughts:

Python, I don’t really ‘like’ python but I can do a tremendous amount of work in it compared to other languages, time wise. And it’s fairly easy to implement and test stuff — worst thing I can say about it is it’s interpreted and the regular expression support is done via a standard library module. Although jython (compile to byte code, but compares to a smaller version of an old CPython release) and ironpython (python for .net clr) should help the former, and the api for regex ain’t that bad, but sucks compared to Perl lol (like most languages seem to, that don’t steal Perls syntax or likewise make it a core element of the language syntax). Python also can handle interfacing with other languages well enough between the CPython, Jython, and IronPyhon implementations.

Java, great syntax and fairly logical. The byte code is portable enough between Sun JVMs and it even has the portable Swing GUI toolkit, although I’d probably end up using SWT or the WxWidgets bindings. The bad things about Java, although you can compile to native machine code, ya need to get the GNU Compiler for Java (GCJ) working first. Regular expressions are done via it’s libraries rather then syntax, and. Well the only _nice_ way of saying it, most of the tools with the JDK eventually piss me off, but I like the language aside from that. The only major con is it is as OOP-centric as I’ve ever seen, and it’s that way by design.

C++, lower level then any of the others and offering the best level of interface to C code of any of them around ;-). I personally prefer Java’s syntax over that of C++ but it still gets the job done. It’s just a question of how often you want to press Shift while typing… One of the best things, the STL is quite nice and well enough supported now to be worth using. Although, in my experience when working around C interfaces, the STLs value can go out the window, but maybe that’s just how long I went before using the STL. One plus, unlike Java or Python, you get a more traditional pointer, not to mention a few interesting things in the std::namespace and boost libraries. Not sure what shape exceptions support is like under various system compilers, but I don’t think that I’ve ever seen C++ code using exceptions outside of examples or perhaps the FAQ :.

Useful points of interest:

WxWidgets for the GUI — portable to target platforms of most interest and in all three of the above languages (and a few more too).

libxml2 for XML — portable to target platforms, but seems to only have C++ and Pyhon bindings easily available, libxmlj (for java) I think would need compiling and I haven’t tried that under FreeBSD or Windows yet.

Semi-Native Regular Expressions — Boost libraries for C++, Pythons own regular expression module, and ditto for Java (not that I like them).

std::string, str, and String classes — basic string handling in C++, Python, and Java. Boost and WxWidges also provides wxString.

MySQL bindings — database operations; quickly available for C++, Python, and Java (JDBC based). Using SQLite in C++/Python is also easy enough but I’m a bit leerly of Java-related connections for SQLite3.

As to the other stuff that was on my list:

C++ and Python provide suitable IPC systems, never have looked at Java in that light. Most of the stuff I need, is basically provided by the C libraries under POSIX systems and Windos, Python has a suitable interface to it, so I’m happy hehe.

Python has good enough built in support for common compression and archive formats. Whatever can’t be done via java.util.zip hopefully could be done via JZlib, I’m not familiar with anyhing ZLib under C++, but there is always the traditional interface ^_^.

I haven’t considered the network side that much. Although I sometimes find it a bit lengthly, I don’t really mind working with the C-style sockets library I’ve used here, using the windows sockets library shouldn’t be to far off from the ones used on *BSD and GNU for my needs (aside from headers/linking). Python has support for a number of protocols (and pwns Ruby on documenting the classes for most protocols IMHO), Java well enough out of the box, and both Python and Java provide usable interface to TCP/UDP. WxWidgets also has a few things as well but more limited, that might be worth looking at, since I’d rather like to use a similar interface in each language, while still leaving code that can be read.

As to the ease of use and deployment, that is always a tough question. Under FreeBSD and Debian at least, they are all ‘easy enough’. Windows of course, always has to be the pain in the ass. But for total portability this is an AoR where Python excels. When it comes to deploying stuff, it gets tricker. Windows lacks a package manager and you eventually have to draw a line between what you’re stuck bundling and what your stuck making a dependency. One of these days I need to look at py2exe and see how it would work out for what I’ve a mind to setup.

Big pluses:

Qt4 for C++ and (generally) Python is great and works on all my systems, QtJambi I’ve never tried on FreeBSD yet, but would be interesting if it works. The only thing I hate about Qt, the commercial license costs an arm and a leg :-(, but most of my needs fit within the (free) Open Source Editions license terms with a smile.

WxWidgets seems to be less painful then GTK+ under Windows while still supporting many languages, although GTK+ would probably be more fun to learn in my case. It also has nifty things, including string/regex classes.

MySQL and SQLite are generally portable and have bindings to other languages quick & easy enough. I’ve never used SQLite on a project, since I run MySQL on one of my own systems to service all my SQL-related needs 😉

When it is all said and done, I really think Pyhon is the best choice… I dunno why or how, but it seems that way! Hmm, to re-dive into using Python for most tasks, or to get C++ crazy… Or live with using both side by side? For my own sake, I think I should sake fuck Java! But it is a great language in it’s own right.

Oh well, maybe in a few months I’ll have figured out which path to take. I can always make use of other languages and tools, but I very much need to find a “primary” set to work with!

think:
switch(choice) {
case PYTHON_ONLY:
// Python becomes my primary language
break;
case CPP_ONLY:
// C++ becomes my primary language
break;
case PYTHON_AND_CPP:
// use both side by side
break;
default:
goto think;
}

Todo: Toolkit and Library madness

Examine for portability the following toolkits under these OSes: Windows NT, Mac OSX*, Unix-like.

*I sadly don’t have a Mac, although I would really love one. So a OSX binary of some form will have to pass.

GTK+ — C, C++, Perl, Python, Ruby, PHP, C#.NET (Java bindings also avail but seem to be gnome-centric)

Qt4 — C++, Perl, Python, Ruby, Java (C#.NET and PHP bindings seem to be questionable and only C++/Python and possibly Java bindings can be depended on).

WxWidgets — C++, Perl, Python, Ruby, Java, C#.NET

Swing and SWT would be considered if they were available under more languages !!!

Evaluate portable standard/add-on libraries to each language for the following capabilities:

String handling (they all do well in the language standard)
Regular Expressions (Only Perl and Ruby get this great imho)
XML Processing
Network programming — both sockets based API and protocol support (IMAP, POP, HTTP/S, FTP)
Database handling — must support MySQL, SQLite, and some form of flat file.
Basic compression and archive format support (e.g. tar; zip; gz; bz2; lzma)
Inter-Process Communication (IPC) methods and related process control (e.g. fork(), exec(), signal(), kill() type routine-families).
Ease of use and deployment

Goals:

Build up a standard frame work of toolkits/libraries/etc that are portable across both my general operating environment and the various languages I use

Attempt to standardize myself on few languages rather then rubber banding between various programming languages + sh/awk/sed/friends

Ensure full development environments are available to me under FreeBSD 7 and Windows NT 5.1 (e.g. I can code from either machine and not change tools)

At least one language for scripting/prototyping and one for more efficient execution when implemented in that language (e.g. 1 interpreted + 1 compiled)

and try to stay sane along the way without writing a few libraries in the process >_>

Something that has been on my mind of late

DRAFT POST

I very much need to start standardizing myself on a smaller set of tools. Maybe tools is not the best choice of ord, o much as it is a question of languages and libraries. It’s actually kind of ironic, I really would like to learn several more languages (Ada, Fortran, C#, Erlang, and I never did wrap my head around Scheme).

C++

Pro’s:

can do low level stuff

can interface well with C code and libraries

Qt is natively C++ and supports everything I need it to run on (in Qt4 OSE hehe)

Fairly portable and standardized (at least much of the 1998 standard…) with several compilers available.

Mainly toolkits and frame works available, both native and from C.

Widely used and my first language

Con’s:

having to dig into lower level interfaces is very error prone when doing it with a headache the size of California.

Often not my first choice for building a prototype *quickly* but good for final implementation.

Java

Pro’s:

Inheritable portable between JVMs of the same implementation (e.g. Sun JVM for Win and Sun VM for Mac can run same code).

Simpler OOP syntax then C++, imho

The Swing GUI toolkit is fairly portable and SWT sufficiently supports the platforms I want to avoid skipping.

I like the way it handles exceptions, and usually like checked exceptions — when a class is designed appropriately.

It’s well defined if not perfectly standardized and compliant implementations are fairly common enough (Sun’s)

Wildly used and my third language.

Well documented (if a bit boring)

Con’s:

Everything is OOP….

I prefer native code to waiting on java to load

Requires a suitable runtime

Conventions expected by some tools can occasionally be irksome (to me)

C# (C Sharp)

Pro’s:

It’s not Java

It’s similar to Java/C++

Core elements are standardized

Less resistance to shooting oneself in the foot / doing stupid things then Java but not as much as C++.

Gtk#, the binding of GTK+ to C# is available on the platforms I care about.

Con’s:

Most C# applications are probably tied to Microsoft Windows implementation via .NET or through Gnome related interfaces

Requires a runtime (e.g. .NET, Mono, or Dot GNU)

Requires just enough learning of it’s differences from Java, for me to use it.

PHP5

Pro’s:

Portable and interpreted

Widely used across the WWW for server side scripting.

GTK+ bindings to PHP available and portable’ish

Simple language and member of the CBF.

The OOP increasingly resembles Java syntax and is just “enough” syntax to be useful without cramming.

Well documented

Con’s:

Local php.ini files can cause problems (how much can you assume?)

Needs a run time (php) of the right version (5)

php4/php5 is less common off web servers or developers systems

Python

Pro’s:

Great for writing prototypes

Several toolkits available that are fairly portable

Easy to work with and quit portable (and issues of portability well noted in the docs)

Large standard library

Implementations for the Java Virtual Machine and Microsoft .NET framework are available (if not as current as CPython) as well as the standard (C)Python implementation.

Con’s:

Requires a run time

I *hate* it’s handling of regular expressions after being so used to Perl…

It’s slower then native code

Interfacing with C /or C++ code can, uhh… Get interesting, from a portability perspective.

The program is the source

Ruby

Pro’s:

Handy pure OOP language

Great handling of regular expressions within the language itself, as opposed through importing an object oriented interface (i.e. as in Python/Java/C++)

Usually very “comfortable” to write.

Large standard library

Con’s:

It requires a run time and alternative compilers (e.g. xruby, ironpython) may be lacking in reliability or cause some features to be unavailable

The program is the source

Wishing Ruby 2 would come sooner….

Documentation can be irksome at times

It’s slower then native code and even slower then Python (Ruby 1.8.x)