AbiWord, or, I’ve given you a couple of days
By now, everyone seeing this post though P.A.C or Advogato or some mystery aggregator should have upgraded/installed AbiWord 2.4.2. It’s pretty slick, isn’t it?

Programming Languages, or, Python meets C++ STL
I was chosen to work on a research project at my college involving shape approximation and other things. It’s a mathematical as well as a computational problem, and as one of the two students on the project, I’m the “computer science guy”. However, this is probably more background than strictly necessary. Yes, this is the main point of my post, I just felt obligated to plug AbiWord above

It’s probably no secret that I’m a fan of the Python programming language. Some slick list tricks, the incredible efficiency with which I can whip out short programs, classes, and even slightly trickier stuff means that when I’m not programming for class (then the required language is C++), I will at least seriously consider using Python. I did so for this project, because at the early stage that I started pushing code, I decided it was best to figure out the proper algorithm than get it completely maximized speed-wise. Fair enough - I cranked out a mostly-working program (just mainly one bug in the algorithm which I knew the solution to). However, because others have to deal with this code, I was asked to convert it to C++. Not an unreasonable request by any means, but it did mean that I’d have to enhance my knowledge of C++ to get away with what I was doing in Python.

I immediately decided against using a homemade list template from class, as I knew of the existence of STL and decided whoever wrote that code certainly was a better programmer than I. Cracking open the book and Google, I went ahead and looked at the STL container classes. Since I was using the features of Python’s lists extensively, I decided to go ahead and use the STL list template.

One particular feature I liked (usually ) in Python was the fact that “for” was actually more of a “for each” which iterated over a list. Since I had to do some “item-by-item” (and segment (two items) by segment) processing, I used this extensively. Unfortunately, the section in the book that I read about the iterators was not rather clear. Initially I found myself using a boolean flag (to say if we’ve gone though the loop once) and a do-while loop to ensure that I processed each item. I had missed the sentence the first time through that said that list::End() returned an iterator past the end of the list (rather than the last item in the list).

Since I had to do segment processing (on a list of points in a polygon), I also realized that (hopefully) the easiest way to do so is to ++ a second iterator started at ::Begin() and incremented once before the loop. To circularize this iterator, I test at the top of the loop to see if it2==mylist.End(), and if so, reset it to .Begin(). In theory this ought to work, but because my code is still about half Python, I haven’t actually compiled and tested it yet. If someone knows of a decent way to implement a circular linked list with STL (more elegantly) aside from writing a circular list myself, an email at the account listed in Advogato would be greatly appreciated. However, assuming that this trick actually works, I’m not terribly dissatisfied.

I went into this Python to C++ conversion project with a bit of trepidation, but it’s pleasantly surprising me. STL lists are actually fairly understandable, despite mutterings I had heard to the contrary. We’ll see if I still am singing the same tune after I try to insert points into a segment without losing all semblence of sanity (and more importantly position in the loop). Might have to do what I did in one version of my Python program - return a new Polygon instead of modifying the current one.

Wish me luck! Until next time, may Abi the Ant be with you!

AbiWord, or Pity the Foo running 2.4.1
All of you folks running AbiWord 2.4.1 or earlier, now is a great time to upgrade. 2.4.2 includes completed OpenDocument export and a lot of fixes for memory leaks. All of you running OpenOffice.org - now is a great time to upgrade from Writer to AbiWord. Give AbiWord a shot! www.abisource.com

Joke
Normally, I like treating everyone equally, but really, this joke is rich. Greatest Blonde Joke Ever

AbiWord, or Progress mixed with “Isn’t That Strange…”

So as 2.4.2 is prepared for release sometime soon, I found it necessary to reboot over into Windows and do my duty with the compiling. I don’t have a CVS-STABLE tree checked out, so I rely on only gentle changes occuring to stable (which is generally just fine), and in case of some major problem surfacing at a tagging point, we can just fix it and re-tag, since tag comes before release.

So this time, as I’m getting the binaries completed, the notorious “hang during documentation build” occurs, and the matching “cause random processes in Windows to run away with CPU” symptom surfaces. Through some careful priority management, I get the build to run again, and correctly. Alright. Log off, and log back on, time to install. The install works great, and aside from a strange plugin conflict (now resolved with a stop-gap measure), it all looks good.

Well, almost all. For some strange, strange reason, the background color of the drop down boxes on the toolbars (style, font, size, and zoom) is grey, rather than white as expected. It all works fine, but the boxes look almost disabled, even though they aren’t.

I have no idea what caused this, where it came in during development, or how to fix it. I don’t recall it occurring in 2.4.1, but neither do I recall any commits that would affect the Windows front end’s coloring of drop-down boxes. Go figure.

So there’s my mystery. Any ideas?

(Yes, I’ll file a bug next time I boot into Windows.)

PS. I <3 VMWare, and as soon as it’s financial feasible and sensible, I will get Workstation instead of installing Windows on top of an installation of Fedora Core in VMPlayer. Qemu has been officially been blown right out of the metaphorical water.