Older blog entries for dennissheil (starting at number 6)


So, I'm happy to have my jhbuild building poppler and its dependencies off their latest commit, and then epdfview and evince on top of that. Of course, if anything is broken anywhere down the chain, things fall apart. I've turned off a lot of the gobject introspection for now....

Epdfview is more lightweight than evince, with a few less dependencies, so I often use it when testing. Epdfview currently compiles against the latest of its dependencies (thankfully no big breakage in gtk+ or glib, as sometimes happens) and can load some PDFs. But a number of PDFs it crashes on. Gdb says:

Program received signal SIGSEGV, Segmentation fault.
__strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:31
31      ../sysdeps/x86_64/multiarch/../strlen.S: No such
file or directory.
        in ../sysdeps/x86_64/multiarch/../strlen.S
(gdb) bt
#0  __strlen_sse2 () at
#1  0x00007ffff772f502 in g_strdup (str=0x1 <Address 0x1 out
of bounds>)
    at gstrfuncs.c:101
#2  0x000000000040ad46 in
ePDFView::IDocument::setLinearized(char*) ()
#3  0x0000000000411680 in
ePDFView::PDFDocument::loadMetadata() ()

Hmmm. It took me a little time to figure out why this was breaking every now and then. I am compiled against the latest glib commit - is someone messing with g_strdup or something? Eventually, I tracked it down to a commit in poppler from September 17th. From the message I guess they knew it would break the API - "PopplerDocument:linearized is now a boolean value rather than string, so this commit breaks the API again."

So that's simple enough. I changed the gchar's to gboolean's, and made some other little changes, and sent a patch in to jordi at emmasoft, so maybe it will get applied. My version is working anyhow...

Using jhbuild

So, in the GNOME-and-fd.o(freedesktop.org)-verse, there are a few things I want to run from the latest updates - evince, poppler and cairo. Which means I want to run the latest versions of their dependencies as well. So I decided to use jhbuild to build it all. Last month, GNOME developer André Klapper wrote in his blog about how little fun it is to build GNOME from the latest commits via jhbuild. Perhaps, but I finally did it - a subset of GNOME anyhow.

The default jhbuild moduleset is gnome-3.0, but that builds some of the stuff I'm focused on from tarball's, which is supposed to be deprecated in jhbuild now anyhow. So I remove gnome-3.0 from my .jhbuildrc and put all of the devel modulesets into my .jhbuildrc. But some of the dependencies were missing - they were in the non-devel modules. So I put all of those into my own moduleset. As my moduleset is local, I set use_local_modulesets to True - even if thats not necessary, I git pull from jhbuild before I run a jhbuild, so why not do that? I also put

module_autogenargs['evince'] = autogenargs \
                             + ' --disable-nautilus '
into my .jhbuildrc to avoid those headaches with evince. I skip a number of modules people recommend to put in skip, like mozilla, although I don't believe they're dependencies in my chain. I also add a few pkgconfig path's to .jhbuildrc, on advice from the net. Of course, I also install the packages on Ubuntu that the jhbuild web site recommends for Ubuntu 10.10.

Incidentally, here are the jhbuild dependencies for evince (and epdfview):

Color code for nodes: green are packages in jhbuild "devel" modulesets, red are packages in jhbuild "non-devel" modulesets, brown (libgcrypt and libgpg-error) are also in jhbuild "non-devel" modulesets and they are tarballs there, purple are packages in jhbuild "devel" modulesets which other packages might have a hidden dependency to which is not shown in the current jhbuild modulesets. Finally blue are non-GNOME packages that no GNOME module is dependent on, but which are themselves dependent on some GNOME modules.

I made the above dependency tree with graphviz, a tool which makes doing such dependency charts really easy.

Everything went pretty swimmingly until I started to reach the top of the chain. Poppler busted on some GObject introspection stuff - I installed gobject-introspection as a jhbuild module and updated the poppler gir include from Gdk-2.0 to Gdk-3.0 and it went sailing along.

Next up - gtk+ 3.0 broke. This happened to me a few days before, when I was taking my first stab at jhbuild. At that time, I looked at the recent gtk+ code, saw the stuff breaking had changed recently, and did a hard git reset of gtk+ to a commit from 48 hours before - it installed fine. This time the commit done was the last one. I went on GNOME's IRC network and tracked down the developer who made the bad commit, he fixed it and I was sailing along again.

So now I get to evince. A few days ago I had some problems with deprecated combo box calls that had been removed from the dependency libraries, but there were patches for that in bugzilla. After patching that, this time I get an error that a set_scroll_adjustments call is failing. I look in gtk+ and see that they have been mucking with scrolling there recently, and figure it is due to that. I disable the call and compile. Evince comes up and I can look around, but it hangs on loading anything.

I check poppler's test programs and they are working. So I encapsulate a lightweight PDF viewer that depends on poppler and gtk+, epdfview, into my personal jhbuild moduleset and build it against these libraries. Epdfview comes up, and displays PDFs etc. fine. Ultimately, epdfview and evince are dependent upon almost entirely the same libraries, except evince depends on three more icon-related ones. And epdfview is working. So either evince is broken, or some library it depends on has changed, meaning... evince is broken, for the moment. But Epdfview works.

I just put my program suite Blunder online. Anyone who plays chess can check it out. It is LAMP (PHP, not Perl) based, and also uses the chess engine Crafty. I have to automate and simplify it more, but I was doing all of this manually in a notebook at one point and so Blunder is a lot simpler than that.

Most chess teachers will tell you there are a variety of ways to improve your chess game. One is to look over your tournament length games after they are played, and annotate them, and if possible to have your chess teacher annotate them as well and point out mistakes you made and opportunities you missed. Blunder is for people who don't have a chess teacher available. If someone wants to review a game they played so as to do better next time, they have Crafty annotate the game. Then using WINE and pgn2fen.exe, they pull the relevant moves (FENs) out of the game, where crafty notes they could have made a better move. I thought about rewriting pgn2fen.exe myself in PHP or Perl or something, but it already exists, and is usable with WINE, so I figured why reinvent the wheel? With the FEN and Crafty notation at hand, we now enter Blunder

First we enter the FEN via a web page and it gets a numerical ID and is put into the database. Then we enter the blunder information for that FEN - when the game was played, what move was originally played by us, what move Crafty says would have been better, and how many points Crafty gives to each move (if there is a one point difference in scores, I blundered away a pawn, or missed an opportunity to grab the opponent's pawn - if there is a three point difference, it is a knight or bishop which was squandered etc.) Now all the information is in the database.

So what I then do is go to the trainer, which is sorted by score difference, with my worst blunders at the top. I click on it and the board I was seeing when I made the mistake is displayed. I then ponder the move for a while, then click on the board. It pops up a window which shows what move I made, and what move Crafty advised. I continue revisiting the trainer page, which I am continually updating with bad moves I made from games played. After a while, I begin seeing the correct move, and the recognition gets quicker and quicker. Where I would have made a bad move before, now I am making the correct move. Soon, I start making the correct move in similar games I am playing, where before I may have made a bad move. My chess game improves. Reviewing your blunders like this is a long-time known method of improving your chess game. Psychologists have even done brain scans where they see chess grandmasters hitting the proper associative cerebral cortexes when considering moves.

When putting this together, I assumed there was some simple, free, public PHP program that when given FEN notation would display a chess board on a local web page. I was unable to find a program like that however, or at least one not tangled up in some massive program suite. I have a PHP displayfen() function in this program which will do just that, in case anyone wants to use just that part of the program for some reason.

Right now, the program suite for 0.1 only contains this one aspect of displaying blunders from ones own games. It could easily be modified to show two-to-mate problems or other such chess problems. But aside from that, I have begun writing an opening trainer that may become part of the Blunder suite. It is a little bit harder to do - in the first move of a game between white's opening move and black's, there are 400 possibilities. Chess teachers recommend students not memorize chess openings until they are at a high level anyhow (although they do say people should have a general understanding of openings). The opening component of the suite I have to think about some more - there is no way I can enter all of the opening book manually (although I may put something in for opening choices I favor).

My patch was committed to jEdit, cool.

I was looking through the source code for the latest version (23.0) of Crafty recently. It is a CPU and time sensitive program, so I ran gprof on it to see what it spent its time on. About 85% of the time was spent calling ValidatePosition(), which didn't seem to be doing anything of importance. I looked around a little bit and saw this was happening because the Makefile's -DDEBUG flag was on by default for a make linux, and that this was not well documented (it's not there by default for 22.9). I suspect that the flag was left in there by error before it was packaged for release. Anyhow, I sent them off a note.

1 Aug 2009 (updated 2 Aug 2009 at 16:44 UTC) »

I have been taking a Java class recently, but thus far had not really taken the step of rolling up my sleeves and doing some real coding other than the standard Hello world, Hanoi towers, Fibonacci sequence stuff. I finally settled on trying to take a wack at a bug in jEdit. Much of the problem was solved by the people posting in the thread, especially Denis Dzenskevich. This combined with a little bit of digging in Sun documents on the Pattern and Matcher classes and a good Javaworld article by Cristian Mocanu on regular expressions in Java pointed to the problem. First, I converted the long in-the-wild file this was freezing on to a simple and legal five line Perl program. After doing this, I saw the problem. jEdit was using a greedy quantifier in the regular expression where it should have been using a reluctant quantifier. I sent in a patch, notified the original bug poster and he mailed me that it fixes the jEdit freezing problem for him.

The problem still exists if the Perl code has malformed backslashes in the second field of a tr statement using curly brackets. However, the fixed bug is rare enough that it wasn't discovered until June, and unimportant enough that my patch hasn't been committed over the past week, so this rarer case is an even lower priority to look at. Which brings to mind a jEdit bug "FindBugs" brought to light - two uses of "Math.abs(new Random().nextInt())". Now on the 1 in 4 billion chance the random number is the absolute minimum possible, will Math.abs return a positive number? The answer is no (I tested it). Again, the odds of this happening are low enough that a patch is low priority.

My patch (#1556112) made it into the latest release of GOCR, cool.

Lately I have been working a few things. One of them is chess-related programs. I wrote a PHP program that takes a chess FEN and displays a chessboard based on it.

Right now I am working on a program, with a PHP frontend and MySQL backend, which instructs how to run through the opening properly. It will also have a section showing how often I have played this move.

I also have another program which will use a chess engine (Gnuchess, Crafty or the like) to annotate games, and then on the moves where I blunder (or miss an opportunity), it will save that move. Then it will display all the places I blunder, so that I can look at them and learn what the proper thing to do is.

5 Oct 2008 (updated 28 Aug 2009 at 02:06 UTC) »

Doing Perl programming. I am usually in a rush to do what I want so my usual practice is to throw everything together and just get it working, and then do cleanup later. Sometimes the cleanup is necessitated by things breaking, like it is now. This code interacts on the Internet, and as remote servers are always changing, I have to expect that my code will change due to that. Currently I am giving variables meaningful names and inserting comments. There is also duplicate code which is bothering me, although not hindering anything other than me having to make changes twice. Also, some of my functions are too long and have to be broken up. My C is better than my PERL, so I am more used to doing things in the good "Code Complete" style when programming in C, but my PERL programs are getting long enough, and are changing enough where I have to make sure it is not spaghetti code.

After working as a UNIX admin for ten years, I decided (with a friend's encouragement) two years ago to go to night school to get my bachelors. I took a lot of required courses for art and the like first, but my last two courses and current course are on the Computer Science major track. Aside from getting a cursory knowledge of C++ in my last class, I haven't learned much useful that I can apply yet, although my current class on assembly is supposed to go over processor registers, memory etc. So far we have only been learning addition in binary and the like.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!