Debug

One of the pointless projects I've been working on is porting PHP's MySQL interface to Guile. There is already a MySQL interface for Guile: Guile-DBI. It has recently fallen into decadence and is being unoficially updated through a series of patches pushed to the guile-user mailing list. Typical Scheme story: the miniscule developer community can't keep up with the maintenence of packages. If I were a good community citizen, I'd be helping maintain the Guile-DBI package, but, since it doensn't really have a home on the web, I'm a bit leery of digging in.

Anyway, the great fun and challenge I've had in porting php_mysql.c over as a Guile library has been how to step through the debuggers. Since I want them to be essentially identical in functionality, I write short PHP and Guile scripts that should accomplish the same thing, and then step through, making sure that the are doing identical actions.

Debuggin PHP is largely written in C. But my Guile-MySQL library is mostly scheme with a very thin layer of C code mostly involved in directly calling MySQL C API functions.

On the PHP side, I compiled a CGI version of PHP with the debugging symbols in. I use libtool to call gdb on the cgi php and set my breakpoints to catch its entry into the php_mysql.c. Debugging is mostly occurs in GDB.

The trick on the scheme side is running scheme code in GDS in EMACS from within a libtool --mode=execute call to gdb.

It is turtles all the way down.

Scheme/Guile Web Services

There are a few ways to call Guile webservices that I know.

• Any webserver can call a Guile script via CGI.


• mod-lisp can be used to pass CGI requests to an existing scheme process.


• Fastcgi could probably be used.


• serveez allows one to write generic servers in Guile.


• An all-scheme webservers is TTN's sizzweb. It descends from Martin Grabmueler's all-scheme webserver in his pers-scheme.

The best library for helping to parse a CGI request is Guile-WWW.
There are a few ways to gracefully generate HTML from scheme.

• Guile-lib has a copy of SSAX SXML, which can convert SXML to HTML.


• skribilo can convert from Skribe format to HTML.

There are a couple of ways to read information from the backend.

• mixp is an xml parser.


• Guile-lib, again, has a copy of SSAX SXML, which can parse XML.


• Guile-pg is a complete system for interfacing with PostgreSQL database


• guile-dbi is a simple system that interfaces with MySQL and Postgres

There are a couple of methods for on-the-fly plot generation.

• guile-charting generates plots via cairo


• There once was a gnuplot library. 1

Post-Linux

The never-ending discussion about future of desktop and end-user GNU/Linux has become a bit louder in recent days.

One large discussion throughout the blogosphere is about the future of GNOME. At issue is coder mindshare in a time when GNOME is largely complete. Hackers enjoy the creation of projects more than its maintaince, but, with GTK stagnating and desktop applications no longer being the brave new world that they once were, there are fewer hands to fight the bit rot in the enormous GNOME code base. Also, GNOME is attracting few new young hackers to pick up the load.

Another obstacle toward a final system is, of course, packaging. The problem with packaging is that there are just too many systems out in the wild: the existence of three different versions of RPM is a case in point.

It is a wake-up call to me, I guess, that after a decade of using GNU/Linux and BSD systems, that I just don't care about either of these arguments. For me, the desktop is unimportant.

For example, I remember before there was a GTK toolkit, when Motif ruled the world. GTK was created; GNOME followed; HIG flamewars broke out; millions of lines of code were written. And, in all that time, I never used either GNOME or KDE for anything. And now GNOME is decaying. It was born and now is dying, and I missed it.

Why does anyone care about the desktop for anything? In my world, the computer has only two functions. First, it should act as a web platform, and, second, it should allow easy access to the full power of the hardware for science programming or for games. Given that the computer is just a web platform, the huge difficulties that occur in packaging are irrelevant to me. If my machine was just Firefox, Apache, MySQL, EMACS, and GCC, that would be enough. I've never used RPM, apt-get, or YUM for anything either, as whatever base ISO I get from Slackware or RedHat has all these things on the first CDROM.

My Windows box is much the same story. I don't use anything beyond what came with the base install. I've never bought a Windows desktop program.

I think the best and most important emerging technology in the world right now is probably Microsoft Silverlight, with Mozilla's XUL and related technologies coming a close second. Java and AJAX are important because they showed us the way.

Despite advocating for free software, in the end, I don't care about operating systems, or the Linux kernel.

Unicode Characters for an Updated Nethack

Terrain

U+2668 HOT SPRINGS
U+2312 ARC looks like a hill
U+2248 ALMOST EQUAL TO rough water

Structures
U+2500 -- U+257F BOX DRAWING drawing walls and buildings
U+2302 HOUSE
U+265C BLACK CHESS ROOK could be a tower
U+271D CROSS or U+2671 EAST SYRIAC CROSS could represent a church or be a cross

Other cool things

U+2680 -- U+2685 DIE FACE roll them dice
U+231A WATCH
U+231B HOURGLASS
U+2744 SNOWFLAKE
U+2614 UMBRELLA WITH RAIN DROPS
U+2615 HOT BEVERAGE
U+263C WHITE SUN WITH RAYS
U+2388 HELM SYMBOL avast ye land lubbers
U+2639 WHITE FROWNING FACE
U+263A WHITE SMILING FACE have a nice day
U+2690 WHITE FLAG
U+2691 BLACK FLAG
U+2692 HAMMER AND PICK
U+2693 ANCHOR harbor (on maps)
U+2694 CROSSED SWORDS battleground (on maps)
U+2695 STAFF OF AESCULAPIUS medicine
U+2696 SCALES jurisprudence
U+2697 ALEMBIC chemistry
U+2698 FLOWER
U+2699 GEAR technology, tools
U+269A STAFF OF HERMES commerce

Cygwin NCurses Quirks

Whilst trying to push GuCu, my Guile/NCurses library, into something more like a first beta, I tried getting it to run on both my boxen: one Slackware, one Windows with Cygwin. It has been a challenge.

First, NCurses 5.6 won't build as a DLL on Cygwin out of the box. The proscriptive first step, upgrading the automake/autoconf toolchain is a no-go, since NCurses uses a private fork of autoconf and neglects automake altogether. I thought for a second to figure it out myself, but, it looked difficult to debug.

So, retreating to the distributed Cygwin/NCurses 5.5, I find that it doesn't have the wide curses functions installed, so I commence the annoying job of separating GuCu into a wide and narrow version, which begins the automake/autoconf difficulty.

Then, I find that, on Cygwin, the wide character C types, wchar_t and wint_t, are not identical, but, actually are 16 bit and 32 bit respectively. I know that the standard says that they can differ, but, I never though someone would actually do that. Some of the NCurses functions are wchar_t and others are wint_t, so I had to go back to my hacked FFI, which treated them as identical.

On top of that, the distributed Ncurses 5.5 has a bug w.r.t to the handling of the acs_map array. (I'd noticed the bug before, when trying to build libRUIN, but, I mistakenly thought that it was RUIN's fault.) The work-around is pretty simple. Just throw this into any file using the ACS_ constants.

#ifdef CYGWIN_CURSES_BUG_FIX
  /* work around bug in Cygwin's ancient NCurses */
  extern NCURSES_EXPORT_VAR(chtype*) _nc_acs_map(void);
  #define acs_map (_nc_acs_map())
#endif

And with that, make check is good to go. Distcheck fails hard, though, because of some mysterious texinfo.tex parsing problem that doesn't occur on GNU/Linux.

And here I thought I was just going to copy it over and "./configure && make".

Sigh.