You heard me right! After some struggling with the use of a message-only window to integrate the TCP asynchronous IO into the single-threaded Abi mainloop, as well as some bughunting in the cross-platform parts of the code, it works!

First message sent over AbiCollab on Win32: “Mr. Watson, come here. I want to see you.” I thought it was prudent from a historical standpoint.

With the initial document sent over, I proceeded to test: with only intermittent ASSERTs, two-way editing of a document over AbiCollab on Win32 works! I also tested it across the real Internet, with Marc (instead of with Localhost), and it also works there!

Once I got it working, I went ahead and cleaned up some portions of the code and fixed some bugs - it is much easier to test things when you know how much is working. My schedule for the rest of the Summer of Code is as follows: Fix bugs until it feels “polished”, then, with any remaining time, work on the Gremlin to allow automated testing. The cooperative collision resolving will come later, when everything else is more stable.

For the daring or crazy, I have nightly builds which now include AbiCollab. To ensure that nobody thinks this is a real release (THIS IS NOT A REAL RELEASE!), I will only tell you that they are on my web site (Ryan Pavlik - Code Art Life on ClearDefinition), and that you should wait until Friday the 10th since they build late at night. (For the rest of you crazy enough to use a dev release but not crazy enough to use a nightly build, 2.5.2 will be coming down the Intertubes soon enough.) Have fun!

Yes, I’m writing about somebody else’s project (not Sum1’s project - just his student). This is mostly because I don’t have a screen shot for what I’ve done since my last update. (I have brought the Account and Add Account dialogs into feature parity with their Unix counterparts, which means a little bit of poking on the backend side, a “Join” dialog, and a Windows message-based synchronizer, and Windows collaborates!)

PhilM has been working hard on the MS Office OpenXML format support, and has built an importer for it. Always the advocate for feature parity, I’ve been watching the development and poking at the Windows makefiles for the plugin as I had moments to do so, with the goal of letting Phil release simultaneously on Linux and Windows at the conclusion of SoC. I had been stumped for a little while by a weird compiler error - I was in fact segfaulting G++, and I very nearly congratulated Phil on this accomplishment. Turns out, though the Makefiles for that plugin were consistent with themselves, not looking at them along side those for other projects had permitted me to overlook a vital detail: each include path should have been (but was not) prepended with -I. After figuring that out tonight, fixing it, then upgrading the LibGSF in my build environment (which I could have sworn I did before, but clearly had neglected to do), the OpenXML plugin built without a problem! Here’s a pretty screenshot of the second result on Google for “filetype:docx“, along with the first successful compiler message.

(PS. Phil - The third one on google (”THE_BRONX_PUERTO_RICAN_DAY_PARADE_2007″) has what appear to be formatting commands (”centertop”) as part of the text. May be a useful test document. Congratulations on getting accented characters to import, by the way - the rest of that doc looks nice! )

Summer of Code is so cool!

I’ve been really buckling down and working hard on the Win32 port of AbiCollab recently. I’ve made some very large (at least, for me) commits without even posting ridiculously long blog posts about them, so you should either be a) proud I’m reforming my writing style or b) disappointed at the apparent lack of progress.

Last blog, all we had was a single, non-functional dialog. Well, now that dialog has a properly hooked-up “Add” button that really does bring up the Add Account dialog. This was a bit of a process: turns out the MinGW resource compiler doesn’t like compiling more than one resource file. After considering some Makefile-foo to call it repeatedly, I settled instead on a single over-arching resource file including each of the dialogs. (Which, by the way, are all completely designed and have functional resource files - I just can’t “get to them” in the UI yet so I haven’t copied and pasted the standard code behind them yet).

Dialog #2 - Date of Birth: July 20, 2007 

Furthermore, we have an account backend (the TCP Backend) that is at least being registered and responding to our requests - it even draws (ugly-looking) controls in the Add Account dialog when it is selected from the drop down. And, even though it would be easier to not do so, I’ve implemented load and unload for the backend controls: even though only TCP realistically will run on WIndows for now, the dialog knows no such thing, and willingly destroys and re-creates the controls each time I select TCP. Exciting!

Tonight: Beauty only the programmer who was confused for quite some time by a non-standard definition of “height” could love.  (Yes, the TCP backend builds and loads!) 

(Note to others: the height of a ComboBox DropDownList control determines the maximum extent of the drop down menu, not the height of the edit control! Don’t let this fool you!)

So what’s next? Well, I’m considering adding a function to the AbiWord core (GASP!) to allow me to set the dialog handle manually in a DialogHelper, so I don’t have to essentially duplicate those functions. (This gets back to the instance thing I mentioned before: since we’re in a seperate executable image and need to use our own instance calling Win32 directly, we don’t use the DialogHelper’s tools to do that which would also initialize the hDlg in that class)

Furthermore, I’d like to figure out why the controls I’m painting in the TCP backend are both a) ugly and b) the wrong size. Hopefully from here on out, now that I have a useful amount of Win32 API experience, implementation will be reduced to just plugging the gaps between the WinFE and the cross-platform goodies Marc already wrote. (The second and a half dialogs went way quicker than the first…) I also need to work on some sort of signalling mechanism since the TCP backend uses an async/threaded system for handling packets. It looks like a message-only Win32 window is the way to go: fortunately I found a good tutorial.

Well, I must not have reformed my writing much - this is still really long! Oh well, it corresponds with a lot of progress. Keep on hacking, ants!

Hot on the tails of the midterm survey for Summer of Code, I achieve a breakthrough on the Win32 implementation of AbiCollab. I’ve made a few medium-size commits working to get the Win32 API and dialog resources in external executable images working. I had what seemed to be correct code, but I was getting a bogus (actually, 0) handle from Windows. One brief email to the Dev list later, and Dom suggests that perhaps the define for the DllMain function should be wrapped in an extern “C”. (That’s a 12-character patch, for those of you who are counting.)

Anyway, that was in fact the last piece needed: immediately after adding that and compiling, I got the following screenshot! As you can see, my very simple dialog primarily based off of the Tabs dialog is being displayed! In this shot (and SVN), none of the buttons are actually hooked up to anything, so once the dialog comes up your AbiWord fun is over until you kill the process, but I fixed that too, along with working on some code cleanups. Now that I have something workable that I can play with, development should go much more rapidly.

Thanks go to Sum1 who helped me debug my dialog code, and Dom for the missing piece, and Uwog for being a great mentor!

Keep hacking, ants!

(Please excuse my cheesy attempt to link the two topics of this blog post.)
First off - the Windows nightly builds (graciously hosted by Marc) have been fixed. I changed the scripts pretty severely recently when I moved them to look at SVN instead of CVS. The result is a lot nicer, more modular build scripts. However, it hadn’t been actually seeing the updates, and I had been so busy working on Summer of Code stuff that I hadn’t had a chance to figure out why. Well, it turns out I was specifying a relative path to one of my scripts, from the wrong directory. The script was the one that does the updating. Oops. Fixed that with a fully qualified path (absolute), fixed a similar issue with the location of files being uploaded to FTP, et voila - it works! While I was at it, I updated the version of LibGSF to 1.14.4 in anticipation of the progressing OpenXML support (Thanks to TML for the libgsf binaries and PhilM for the SoC OpenXML work!), so do test these builds and see if they work for you.

Now to my second topic - paths to solutions. My progress on Summer of Code has brought me into some rarely-explored bits of code in AbiWord: displaying dialogs from plugins on Windows. One plugin did this (Aiksaurus) but I am told it hasn’t compiled in a while, and its dialog code looks very little like the other dialog code in AbiWord. The failure mode is amusing, at least before you spend a good deal of time trying to figure out why it happens (Windows compilation is slow….): The Collaboration Accounts menu item brings up the Change Case dialog. I’ve tossed some debugging lines in there, and I’m told the ID that the SessionManager (in charge of registering the dialogs) is getting okay IDs, AbiWord core is just returning/displaying the wrong dialog. I’ve emailed the AbiWord developer’s list to try to figure out what is going on from someone with more experience in these parts of the code: hopefully a solution can be found soon so that my work on the Win32 part of the project can move forward.

On the other part of my project, I’ve worked on some “thinking and documenting” parts, which are showing up at my Summer of Code page. Marc has been doing some pretty serious work on the conflict resolution for OLPC, and so I’m waiting on the code part of this project component until that seems to settle a bit, giving me time to analyze the situation without being keyboard-addicted. I’ve also started working on a “gremlin” plugin which will eventually be used to run fully-automated torture testing of AbiCollab and its conflict resolution by making random changes to the document. After hurdling a few difficulties (who knew that nextgen.sh and autotools would have such a hard time with DOS line endings?) the basics of that plugin compile and run on Windows and Linux, inserting a one-off secret message into your document upon execution.

If anybody has any ideas or advice to offer based on what I’ve talked about, please feel free to email me. My username is abiryan, and the domain name is that of my company, ryand.net. I’ll let you figure that out, so I minimize spam… (In a pinch, I have a spammy address listed on my company page…)

Till next time, keep hacking, ants!

Thanks to the wonderful help of my mentor Marc (uwog) and the help of Hub who was productively loitering in #abiword at the time, I am proud to announce the following:ABICOLLAB BUILDS AND LOADS ON WINDOWS! Because I’m in favor of eliminating black magic, the build instructions are on my web site, http://www.cleardefinition.com/  for the enjoyment of anyone with some free time and a Windows computer.  I’ve definitely got a ways to go still (the dialogs are just stubbed in, etc), but this is a major milestone.  Enjoy the screenshot!

Well, we’re now a bit over a week into the Summer of Code program, and I figured it would be time for an update.  Over the last week, I’ve been working on getting AbiCollab to build on Windows.  Now that I have makefiles somewhat figured out (see my last post for more about that), I went ahead and created a diving make buildsystem for AbiCollab.  This may sound easy, but there was one minor complication: it looked like my include paths were being ignored!  Marc even tried hardcoding them once (instead of using $(shell pwd) ) and it still didn’t work.  Nevermind that other plugins had nearly identical makefiles with fully functioning include paths…

Ahh, but they weren’t quite identical.  I tried to shuffle around the build order for directories, and this gave me an important clue: I could get one source file to build to an object file, but only that one file.  With my spirit renewed (when your mentor is confused/stumped and everybody else says makefiles are black magic, it can be a bit difficult to push ahead), I compared the makefile from the functioning folder with the one from a problematic folder.  The only difference I could see was that in the “broken” makefile, some of the include paths (all except $(shell pwd) itself, I think) had trailing slashes, and there were no trailing slashes in the functioning one.  It seemed like too simple, but yet, perfectly logical, since the makefiles were otherwise identical and identical with functioning ones in other plugins.

After removing them and attempting a make (which was mostly successful: definitely proceeding past where it had before), I was ecstatic and shouted for joy (IN ALL CAPS) in #abiword - the weird problem that had held back my progress was now resolved!

Mind you, there are still a few more problems, but if this was easy, Google wouldn’t be sponsoring me :)  I’m definitely having a blast so far, and I’m totally pumped with how awesome AbiCollab will be.  An advantage of being stuck for a few days on a problem is that I skimmed a bunch of the files trying to figure out the problem, so I have familiarity that will definitely be handy.  So that’s where I am right now - working on more compilation fixes, currently wrestling with getting the TCP backend (with asio and boost) to build.

Till next time, keep hacking, ants!

So today was the official start of the Google Summer of Code, which I am thrilled to be a part of. My first task is to get the AbiCollab collaboration plugin running on Windows, and getting a GUI on it. There has been no work on AbiCollab on any platform except Unix (and Sugar/OLPC), so with regard to building, I had to create Makefiles from scratch. As our Windows build uses a “diving Make” system instead of Autoconf/Automake like the other platforms, I have to figure out how exactly those makefiles work and how to create new ones to build AbiCollab properly.

This is a little bit of a challenge, since the problem is actually dual: we both have a new/untested build system, and code that might not actually even build at all on Windows in its state. As I was working on cleaning up my build instructions, I realized that some time ago, I had disabled the Psiconv (Psion Word) plugin since it was causing some problems, not working very well, and used the old “peer libs” mechanism for compiling. I figured I may as well get that going again (providing a binary distribution for ease of use), and I unknowingly got myself into a bigger project than I anticipated. (I hadn’t remembered it ran as a peer lib, and so I installed it as a system library in MinGW) That was alright, though, because it provided an exercise in Makefile-fu necessary to proceed in the AbiCollab project. I had to change bits of the makefile from the old peer lib setup to a new system installed setup using pkg-config (and I made the pkg-config file for psiconv). The cool part is, I was successful! If I comment out a debug message (since there’s something telling it to be a debug library even though I want just a regular version), the plugin builds and runs, and even imports the sample file that came with Psiconv!

An unusual start, perhaps, resurrecting an old plugin, but useful to some end users and definitely useful to me as an exercise. Thanks, Google!

For anyone who wants to get their feet wet with building an AbiWord binary or even installer packages on Win32, I’ve updated my build instructions to include how to check out the latest version from Subversion!  I’ll be updating my own nightly builder (on Uwog’s VM) soon so that those who don’t feel like following the instructions can nevertheless have a clean, bleeding-edge build to test with.  Get the instructions at http://cleardefinition.com/page/Windows_Build_Instructions/

This summer, I’ll be working on AbiWord for the Google Summer of Code, in the AbiCollab project (”Systematically breaking and fixing AbiCollab”). Though the Summer of Code doesn’t officially start for another week, I thought I’d ease into it with a brief evaluation of the current state of AbiCollab. I had worked with the plugin a while ago (before the big rewrite), but hadn’t gotten it built recently.

Well, I can proudly announce that that’s changed. Thanks in part to the joy of virtualization (running both a Jabber server and the second AbiWord instance), I have the latest AbiWord (from SVN Trunk) compiled and running with the XMPP (Jabber) backend of the AbiCollab plugin. As the screen shot shows, it does work! I did run across a few issues already, but I definitely feel more capable and comfortable with the code now. And, I’m sure my mentor (master?) uwog will be glad to oblige my requests for explanation