Tuesday, October 16, 2007

GNU CLISP 2.42 has been released

You can read the full announcement here. I have uploaded a MinGW build for Windows to SF.net and it should appear in the file releases section shortly. Other folks are working on binary distributions for their favorite platforms. And of course, you can get more information at the CLISP homepage.

Tuesday, September 4, 2007

new burden on sites hosting open-source projects

All the cool kids are registering themselves and their projects at Ohloh.net, which bills itself as 'the open source network'. I'll let the visionaries of the blogosphere weigh in with insightful commentary about what Ohloh should mean to us all.

I did want to make one observation, though. It doesn't take much poking around to notice that there is a bit of an issue with downloading project history. The connection between you and the meta-data from your project(s) is a big part of what drives up your KudoRank. So obviously, you'd like to see the meta-data downloaded and processed as soon as you register each of your projects. But download failures seem to be a common problem -- not with all projects, but enough of them to be noticeable.

I started wondering how much of an unexpected burden is being placed on the sites hosting open-source projects by the rise in popularity of Ohloh.net. Take common-lisp.net, for instance, which hosts the source repos for many Common Lisp projects. Until now, it looked like the level of donations was keeping pace with the regular bandwidth costs and other expenses. But is Ohloh driving bandwidth costs up? And, is some fraction of the download problems that are observed at Ohloh possibly due to site administrators taking counter-measures to try to mitigate this issue?

It will be interesting to see if this is a real issue. In any case, this is a good excuse to encourage everyone to support the sites that host our projects.

Saturday, August 25, 2007

clim-graphic-forms event handling still broken

Update 9/2/2007: in the time since I originally posted this entry, I figured out the problem. Every event dispatched to the McCLIM framework gets a timestamp, and these timestamps must be sane. Whereas before all currently queued events were getting their timestamps reset to the same value, I now make sure that each event is stamped using GFW:OBTAIN-EVENT-TIME. And so the annoying misbehaviors with decoration rendering, sizing, and moving of frames were resolved.

Original text follows:

Over the last several days, I made another attempt to fix event handling in clim-graphic-forms, which is a backend that I started for McCLIM using Graphic-Forms. The problem is hard to describe, but the most visible symptom is that top level windows act like non-client messages are only getting sporadically processed. For example, if I drag a top level window by its titlebar to a new location and let go, it becomes unresponsive to further mouse input until I deactivate and then reactivate the window. Or if I resize a window, the right and bottom frame decorations are not drawn -- even the titlebar doesn't resize. If I comment out the lines of code where I notify McCLIM via window configuration events, then of course McCLIM is prevented from doing what it needs to do, but the window frame starts to behave correctly.

The backend maintains an internal event queue which gets populated by various GFW:EVENT-*** methods and which is drained by CLIMI::GET-NEXT-EVENT. GET-NEXT-EVENT also has the job of retrieving each new message from Windows. I have experimented with several other approaches, including reimplementing CLIMI::SIMPLE-EVENT-LOOP to call GFW:MESSAGE-LOOP directly with a custom message filter that calls CLIMI::HANDLE-EVENT directly. The end result is the same.

I could work on filling in other missing functionality, but this event handling issue really bugs me to the point of extreme frustration. What is it about calling back into McCLIM during an event that causes such problems? I have no idea.

Monday, August 20, 2007

Graphic-Forms version 0.8.0

Release 0.8.0 of Graphic-Forms, a Common Lisp library for Windows GUI programming, is now available. The API and feature set is still evolving, so this is still another alpha release.

New in this release:

- Added a new macro GFW:DEFMENU2 and associated function GFW:MAKE-MENU to allow applications to create reusable menu factories.

- Latest CFFI is required to take advantage of built-in support for the stdcall calling convention as well as improved interface for defining foreign types and translators.

- Integrated patch submitted by Leon van Dyk that enables dialog-only applications. The GFT::STANDALONE-DIALOG function demonstrates this feature, but NOTE that when this is invoked from SLIME, an old problem reappears where the dialog is not initially visible; however, the same demo run directly from the REPL works OK.

- Ported the library to Allegro CL 8.0.

- Upgraded to LispWorks 5.0.1 (note: 4.4.6 is no longer supported)

- Implemented GFW:STATUS-BAR which currently allow a single text field. Multi-part status bars, and nested widget support, will be added in a future release.

- Implemented GFW:PROGRESS-BAR, which provides visual progress feedback. This control can be configured for horizontal or vertical orientation, and can display a segmented or continuous indicator.

- Simplified the mechanism for specifying fixed, non-resizable windows by adding a new GFW:TOP-LEVEL style called :FIXED-SIZE and enhancing GFW:PACK to do the right thing if that style flag has been specified.

- Greatly expanded the symbols for accessing predefined colors, and now provide access to system color settings in a similar manner.

- Implemented a new graphics context function GFG:CLEAR that is a convenient way to fill a window or image with a background color.

- GFS:OBTAIN-SYSTEM-METRICS now includes version information for comctl32.dll and shell32.dll.

The README.txt file in the release zip file also has additional important information about this release.

Download the release zip file here:

The project website is:

Jack Unrue
jdunrue (at) gmail (dot) com
20 August 2007

Sunday, August 5, 2007

doc authoring system

When I work on a project, I generally try to write documentation in parallel with the code, even for projects that I don't intend to open source. Firstly, having that resource available frees up my mental bandwidth for thinking about the current problem I'm trying to solve. Secondly, it's a substitute (some might say a bad substitute) for certain kinds of design documentation, although I try hard to write docs with the end user in mind. And third, it's a way to sanity check ideas, such as when I'm designing some protocol. Having that stuff written down helps me see the big picture for what I'm trying to do, and providing it right away in the reference manual seems beneficial.

A while ago, I settled on DocBook/XSL as my authoring system. I use an extension of DocBook that I wrote which makes my personal style of structuring a CL project reference guide easier to build. It also provides some conveniences for the particular way that the syntax of CL functions/macros/etc are shown. The extensions are a set of XSL templates implementing some higher-level constructs that go along with the DocBook stylesheets; these get transformed into the DocBook vocabulary for later processing.

Here's an example of the help source for a function called MAKE-POINT in a package called LPC, using the extension vocabulary that I mentioned above:
<function name="make-point">
<argument name="coords">
One of:
<itemizedlist mark="bullet" spacing="compact">
A <refclhs>list</refclhs> of alternating x/y coordinate values.
An <refclhs>integer</refclhs> x coordinate value.
<notarg name="&optional"/>
<argument name="y-coord">
An <refclhs>integer</refclhs> y coordinate value.
This function returns a <refclhs>vector</refclhs> representing one or
more points.
It's possible to mix tags from my extension vocabulary (e.g., function, syntax,
reftopic) with DocBook/XSL tags (e.g., itemizedlist, listitem).

This is what the end result looks like:


The output format is HTML Help, so the above screenshot shows part of the help viewer (it doesn't show the search/index tab nor the toolbar). My development platform is Windows XP. Not that there is anything wrong with portable solutions, and you know, raw HTML is often as good a choice as anything else. But HTML Help has features that I want, it's fairly customizable, and I can't think of many situations where a Windows user wouldn't have the viewer. Underlying this is the fact that I generally assume a Windows-based development environment for my work.

One future improvement I'd like to explore some day is to extract CL doc strings from the code and merge that in with other help content. I hear the SBCL developers do something along these lines to generate their manual, one difference being that I believe they are using texinfo or at least migrating in that direction, so I ought to take a look at what they do.

Sunday, July 8, 2007

8 July 2007

Miscellaneous bits of recent Graphic-Forms activity:

I read that the CFFI developers decided to merge their newtypes branch into mainline. Having created a corresponding branch in my svn repository a while back to track the newtypes changes, I went ahead and merged my newtypes-specific code into my project's mainline.

For a long time, I've had a DEFMENU macro that implements a DSL for creating menu hierarchies. I recently checked in a new feature that allows applications to create reusable menu factories. DEFMENU continues to return a menu tree (with fully instantiated HWNDs), but now folks can use DEFMENU2 to define a factory which can be used over and over again. I'm planning a similar (but broader in scope) DSL that will enable declarative window and dialog specifications, and this latter feature has a prerequisite for the menu functionality.

A nice person submitted a patch that enables dialog-only apps. I will merge that change shortly.

Saturday, May 26, 2007

arbitrary precision decimal library

A week or so ago, I realized that I needed a decimal arithmetic library, so I decided to start working on one. That is to say, I didn't look around very hard to see if there were any existing CL-based libraries or FFI wrappers, since I was itching to work on something new.

Common Lisp already defines a rich set of number types and operations, including unbounded precision for integers and ratios. But there is no standard type providing exact decimal fraction representation and rounding. As an example, if we have a file containing company financial data, and we want to read that in, then do some computation on the data with amounts rounded correctly, we need to write some code.

So after a few evenings of work, I now have basic arithmetic operations implemented, including decimal division. I have a reader macro #D defined for convenience. And of course, I implemented several equivalents of the CL functions like incf, decf, zerop, signum, etc. I currently only support half-even (also known as banker's) rounding, since my primary intended use is for finance, and from what I understand half-even rounding theoretically does the best job of minimizing cumulative errors. I do know about IBM's spec, but my requirements aren't that sophisticated (yet).

I'm happy to share this code, if anyone's interested.

Sunday, April 1, 2007

1 April 2007

Some of my recent development activity:

- Having brought Graphic-Forms more or less up-to-date with latest CFFI, I returned to work on the task of supporting status bars in top-level windows.
- I also spent some time poking at event handling in clim-graphic-forms.
- I responded to a couple help requests for CLISP on Windows; one of those problems appears to be a bug in the MinGW component that supplies the Win32 headers and libraries. It's one of those cases where some particular values are needed and these can't be extracted from the MS headers and libs for licensing reasons.

And that's not to mention the fun stuff I'm doing at work (not in Lisp, but still fun). I tried hard to ignore all the April Fool's silliness, but the Gmail Paper announcement was pretty well done if you ask me.

Monday, March 19, 2007

a small Graphic-Forms fix that helps SLIME users

Folks that have downloaded the 0.7.0 release, and who want to use SBCL / SLIME to develop Graphic-Forms apps, should apply the following patch.

In src/uitoolkit/widgets/top-level.lisp edit the INITIALIZE-INSTANCE method such that the INIT-WINDOW call is followed by a call to SHOW

< (init-window self classname register-func owner text)))
> (init-window self classname register-func owner text)
> (show self nil)))

Then reload or recompile top-level.lisp and try starting some apps. For me, this alleviates the hanging problem that occurs when running GF apps on SBCL / SLIME.

Saturday, March 17, 2007

17 March 2007

Here are some recent developments from my perspective in the Lisp world:
  • David Lichteblau very kindly imported the most recent snapshot of my work on a Graphic-Forms backend for McCLIM, and has subsequently invested significant time and effort to help move it forward. As he notes in his announcement, there is still a lot of work to do, so if you (gentle reader) are at all interested in supporting a native Windows backend for McCLIM, please grab the latest code and experiment with it, offer patches, etc.
  • The combination of SLIME, SBCL, and Graphic-Forms apps seems to be working now, and that's great! One of the SLIME developers must have made the right changes, so my thanks to whoever that was.
  • CFFI has acquired support for the stdcall calling convention, and also lots of enhancements are being made to support character encodings. I am currently in the process of catching up with this.
Good stuff all around.

Friday, January 19, 2007

research topics followup

Following up on my previous rambling, I can now report having accumulated real experience with C# and the .NET Framework. I feel the need to come up for some air and reflect a bit. First of all, I can see C# now as a nice upgrade over Java. That's a subject for a different forum, so I'll leave it at that.

The main goal of this diversion was to evaluate .NET, in particular the GUI frameworks, and ponder the benefit of continuing to build a Common Lisp library on top of User32/GDI, which of course is the classic Windows GUI foundation.

While I don't think anyone truly knows how much longer the classic APIs will truly survive (or be usable), there is certainly evidence that Vista is more unmanaged code than managed code; furthermore, this same fellow has found heavy use of those classic APIs in .NET up through version 2.0 (and hence Windows Forms). One can find empirical evidence just by looking at the WinForms documentation -- there are facilities for directly accessing underlying HWNDs. And despite rapidly entering deprecated status, WinForms itself will live on for a while since .NET 3.0 directly supports it.

As an aside, I noticed while doing some deployment testing on WinXP how installing .NET 3.0 on anything less than a brand new machine is s..l..o..w. It was hilarious to watch the installer progress bar reach its 100% mark and then start over, with the label updating to state "This process is taking longer than anticipated." At least one MS representative has acknowledged this problem (scroll down to the bottom of the thread).

So my conclusion is that it will absolutely make sense at some future point to rehost Graphic-Forms, but I can see the current implementation still being relevant 5 or 6 years from now, if not longer.

Monday, January 1, 2007

research topics

A couple of my current research topics:

1) Whether I should (and if the answer is yes, then how to) rehost Graphic-Forms on the .NET Framework, thus abandoning User32/GDI?

RDNZL is proof that Common Lisp and .NET integration is possible. Dr. Weitz certainly got people's attention with that project (which as he points out was heavily inspired by earlier work on an earlier Scheme-based project). I also discovered that the SWT folks have proposed doing a port of that Java-based GUI library. So feasability does not seem to be in doubt. The question is whether it makes sense for my project.

2) What is it really like to develop non-trivial applications with XAML and WPF?

I've experimented with toy examples using Visual Studio 2005 Express plus the extra components needed for .NET 3.0, and viewed tutorials such as this one. Is this an accidental reincarnation of CLIM? It certainly has a familiar feel in some ways, especially the ability to do incremental and interactive development. I'd much prefer a sexpr-based syntax, if not a full-blown Lisp dialect. Does Guile support .NET?

Anyway, I will be devoting a big slice of my free time over the near-term to answer these questions.