Jack Unrue's blog

Deconstruction

2011-03-26T23:18:00.000-06:00

Inspired by this video.

Hungry ants climb onto the helpless hulk,
the ocean-going hull towering over the beach.
Showers of sparks fall to drown in the water below,
the ants' work is reflected in dispassionate eyes.
Gears turning, cables tensing, chains pulling,
the ants wisely step back from the seam
as the last joints pop free and the deck sags.
Tons of sharp metal tilts, spins, and crashes.
Displaced ocean reclaims its rightful place,
sunlight finds its way into a rusting cathedral.
Waves still lapping at the remnants of the last,
the ants invite the next victim onto the sand.

I'm fed up

2011-02-22T22:17:00.001-07:00

I'm fed up with poorly implemented, poorly tested, poorly understood software. I'm fed up with Best Buy and their laughable, so-called "technical expertise." I'm fed up with the miserable dreck that passes for most of what's on TV these days. I'm fed up with having to dodge bad drivers on the road or in parking lots, and I'm really fed up with that special category of idiot who partially blocks our driveway at home. I'm fed up with Big Content, Big Banks, the Telecoms, Oil Companies, and Drug Companies. I'm fed up with politics, and I'm fed up with our dysfunctional government. I'm fed up with the revolving door between government and industry. I'm fed up with people who take unfair advantage at every opportunity. I'm fed up with people who make excuses, shift blame, or otherwise dodge personal responsibility. I'm fed up with wasting my free time on Facebook.

Now I feel a little better, thanks.

IBM Watson

2011-02-20T22:32:00.001-07:00

What a terrific accomplishment IBM Watson is! The managers and engineers on that team must be proud to see how well the system did on Jeopardy. I think it's great for someone besides Google to demonstrate such innovation, and to do so in a way that the average person can get excited about.

We shouldn't have been surprised to find out that as impressive as Watson is, the system nevertheless is not yet perfect. For instance, Watson's designers didn't anticipate the need to receive and interpret answers from other players.

This is an exciting development and I'm curious to see which direction IBM will go from here.

So Dark at This Hour

2010-05-09T22:44:00.000-06:00

Late at night, a man stands on the sidewalk at the edge of his neighborhood. He's looking towards the lake across the road from the houses. Lightning flashes pierce the clouds on the horizon. Down the street, a lamp shines overhead. The man stands on the fringes of its illumination. The world is hushed, sleeping, but he's raging inside, angrier than he can remember being in a long time. He's stopped clenching his jaw, but his jaw muscles are still throbbing.

The man has a new car with a powerful engine. He hasn't yet dared drive as fast as it's capable of going. He's thinking about that car, and about a particular road. The road is on the outskirts of town, in one of few remaining undeveloped areas around. There's a stretch where you can build up plenty of speed if you want, and a beautiful curve that sweeps around in a lazy arc. Where the curve starts to straighten out again, the road passes under a highway. He thinks the highway is one of those privately-owned toll roads. He's not sure.

He visualizes the concrete supports and embankment of the overpass. He considers making a trip out there, just to scout out the angles and rehearse how the whole scenario would play out. He runs through it several times in his mind. Then another part of his mind says, in a voice that only he can hear, "Guess what, your gas tank is almost empty anyway." That's true, he concedes. The man shudders.

The street light chooses this moment to flicker out. Now it's pitch dark. Just as abruptly, the light buzzes and comes back to life. The man stares as a fox comes into view, trotting along the sidewalk on the far side of the lamp. It slows down and stops at the pole, about 25 feet or so away. The fox looks around, turning this way and that, hardly giving the man a passing glance. Then it lowers itself into a familiar resting pose, not quite on its stomach yet not completely on its side either, with its paws stretched out in front, like a dog. It's facing the lake and seems to be focused on the low-lying scrubby grass between the sidewalk and the lake.

The man hears some rustling behind him. He looks over his shoulder, and sees a slender form settling down outside the second floor bedroom window of a nearby house. He can see smooth bare legs and shorts, but the rest of the figure is hidden in the shadows. It's one of the neighbors' girls. OK, the man thinks, if the three of them are to share this quiet evening for a while, he won't mind at all.

The sound of an engine like a heavy-duty truck perturbs the night-time calm. The streets of this neighborhood twist and turn, so much that approaching vehicles are usually heard long before they are seen. The engine sound gets closer, and closer still. Illumination from headlights appears around a bend. It's coming down the street towards the three of them. Bemused, the man watches a truck roar past him and turn left around a corner into the neighborhood. It's a tow truck. Brake lights come on and the truck eases to a halt just a couple houses in on the side street. Sitting in the driveway that the truck now blocks is a fancy car, perhaps a BMW.

The truck idles for a minute. Then, the man hears the engine rev and the truck turns to block the street, headlights swinging around with a harsh glare. It slowly backs up onto the driveway just in front of the car. "Holy crap!" he blurts out loud, laughing. A stocky figure hops out of the cab, runs to the back of the tow truck, and pushes a lever. There is a noticeable whirring sound. The driver drops down and reaches underneath the front of the car. He fiddles around for a moment or two, then jumps up and darts (who knew a stocky man could be so agile?) back to the cab of the truck. He jumps in, and the truck engine revs hard. The car is yanked off the driveway and down the street, making a loud tire screech that surely wakes up everybody in the vicinity. The tow truck swerves back onto the main street, its quarry hanging precariously off the wheel-lift. Meanwhile, a light flickers to life upstairs in the house, and then the front porch light comes on. The tow truck driver jumps out of the cab and steps back to the car, fumbles around but gets the car door open, then reaches inside. He closes the door again and places some portable brake lights on the roof. The repo man jogs back to his cab, gets in, and the whole production rolls off into the night.

The man chuckles to himself in amused disbelief, but the grin on his face fades as he looks down at the sidewalk. The fox is gone. It probably snuck away at the first sign of trouble. Back across the street, he hears a dull metallic sliding sound and a thump. Looking up where the girl had been sitting, he sees that she is gone, too. The man glances out across the lake. What used to be a starry sky with flashing clouds on the horizon is now completely overcast. The man's inner voice speaks up again: "You need to get up for work tomorrow." He sighs. A few hours' sleep is better than none at all.

A story fragment

2010-02-13T20:56:00.000-07:00

A full moon faintly illuminated the faces of seven men, each drawn with pain and exhaustion. They stood in a rough semi-circle near a log that was once a mighty tree. A cool breeze rustled leaves in the forest overhead. Tree branches swayed with the breeze, revealing and then hiding patches of starlit sky. The men stared blankly at each other, or at nothing in particular.

Finally, one of the men lifted his head to gaze at the sky, and said,

   "We can't stay here."

Another voice asked,

   "What about the others? We can't leave them here."

A man with a graying beard and wrinkled face took a step forward, and answered,

   "We will have to leave them where they are."

He paused, then said,

   "Joshua, take your men west to the river and follow it downstream. There is a good chance you'll find a road, or perhaps a town. From there you can make your way home. Don't wait for us."

Joshua had turned away from the rest of the group, but spun around to ask,

   "What do you mean? Aren't you and Henry coming with us?"

The older man simply stared back at Joshua. The man named Henry smiled grimly and replied,

   "Don't worry, we'll catch up with you soon enough."

What's on my mind

2009-11-14T00:15:00.001-07:00

I was planning to write about my computer Go project, but tonight I just feel like letting out some random thoughts.

I'm listening to Radio Zero again (that is, the Zero Hedge podcast). Because of RZ, I got interested in trance, which is a style of techno dance music. No, I am not dancing. Get that out of your head! I have discovered that trance is good for programming. I can't explain why, yet, but it's good to have the trance stuff going in the background while I work. I'm starting to appreciate a good mix, too. A seamless flow, smoothly transitioning from one tune to the next.

On a sidenote, I used to listen to Rush a lot. It's amazing how Red Barchetta gets you fired up. It's good driving music, funnily enough. I prefer the era prior to Hold Your Fire. With few exceptions, I'm just not thrilled by the later material.

The biggest reason I got into programming is that it's a way for me to create things. We can debate how tangible a program is. I'm not good mechanically, or artistically, or any number of other ways that one might build things. But I do have a bit of a knack for programming, so that's what I do.

Maintaining other people's software can be a chore, sometimes downright painful. I strongly resist the urge to rewrite it all, because I know that's a crutch. When there are other stakeholders involved, such as at my employer, rewrites are not usually an option anyway.

Last random thought for now. People with blogs, especially my friends, should keep writing. Yeah, OK, you might not think your day was interesting. Or maybe you don't think you have anything to say. You should take a risk anyway, get something written down, and let it go.

Today's workout

2009-11-09T21:16:00.001-07:00

I have been remiss in posting my workout results. Today, our warmup was to alternate 200m rowing and 1 minute of double-unders, for 5 rounds. Danielle and I got there a little late, so I ended up only doing three rounds. But it was a good start. Rowing is one of my strengths, and I'm getting better and better at double-unders.

The WOD was called Eva, and it was 5 rounds of:

800m run
30 kettle bell swings (75lbs was prescribed, ha ha)
30 pullups

I learned first-hand why this WOD is considered really tough. I scaled the kb swings to 35lbs and then dropped down to 26lbs. And I am still doing jumping pullups. My time was 46:30 (plus or minus some seconds, I didn't write my time down before I left -- /me dummy). It felt really good to finish!

The exact time is not actually the main thing for me right now. My goal in the near term is to get to the point where I don't have to be taking breaks in between sets, and more importantly, to not be the last or next to last in results every workout. If I can solve that, then I'll know I've reached the next level.

Today's workout

2009-10-15T20:17:00.000-06:00

Today we had to do 5 rounds of the following:

- 10 Ring Pushups
- 5 Squat Cleans
- 250 m Row

I got mine done in 15:09, and was exhausted at the end, although my squat cleans were just using the 40lb bar. I haven't quite got the hang of the squat cleans yet, but I'm getting closer. Practice, practice, practice. Then we worked on ring dips and renegade rows.

I am happy to say that I am up-to-date with my burpees for the burpee challenge. We have to do an ever increasing number, increasing by one each day, until Jan 8th when a total of 100 burpees will be required. But for tomorrow, it's just 16 of them. I think doing them in the morning before I head out is working pretty well.

Today's workout

2009-10-13T20:06:00.002-06:00

Today at the gym, Robyn had us do the "Filthy Fifty". Don't you love all these nifty CrossFit named workouts? In this case, you are asked to do 50 reps each of:

- Box Jump 24"/20"
- Jumping Pullup
- KB Swing 1 pood
- Walking Lunge 50 steps
- KTE
- Push Press 45#
- Back Ext.
- Wall Ball 20#/14#
- Burpee
- Double Under

What is a "pood", you ask? The main CrossFit site says it is a "Russian measure used for kettlebells; common ones: 1 pood =36 lbs; 1.5 pood = 54 lbs; 2 pood = 72 lbs. Approx db equivalents are 35, 55, 70". I chose a half-pood, or 18lbs.

KTE stands for "knees to elbows," and as Robyn said today, "from the bar is preferred." But some of us (i.e., me) had to substitute with a few crunches on the floor on our backs. The Back Extension is supposed to be done with weight, but I had to scale down to a very light bar because I don't yet have the flexibility to get my arms back enough to have the bar resting on my back muscles. I had to substitute a bunch of push-ups for half of my burpees. And finally, I substituted x3 single-unders for the double-under jump roping. And then I tossed in a run around the building, which is not quite 400m unless you keep going to the next warehouse entrance and come back.

And that's not counting the 25 burpees I did this morning (with real push-ups) to stay up-to-date with the burpee challenge! Man, I am wiped out now, but feeling good.

Random incoherent thoughts

2009-10-08T20:06:00.000-06:00

Had another kick-ass workout at the gym today, but I'm too tired to write about it much. Plus I need to get back to debugging some stuff for work. I was at work by 7:15am today and yet I still need to put more time into the project. I will be joining a number of my co-workers in presenting our projects company-wide tomorrow in the early afternoon.

Well, that wasn't so good

2009-10-05T19:58:00.001-06:00

I got a little carried away (heh heh) with my deadlift weight today, and strained my back a bit. I did 21 reps @ 160lbs, then 21 kettle bell snatches on each arm, and 21 box jumps. I started the next round which was going to be 15 reps, but had to quit early because of my back and I don't think I'll be doing my burpees for the day. Darn it.

Today's workout

2009-10-03T11:23:00.000-06:00

Robyn held her Saturday workout in the usual place today, Parfet Park in Golden, CO. It was a beautiful, sunny morning. We had to start with 50 kettle bell swings and 10 ball slams, followed by 50m of burpee broad-jumps, then 40 kb swings and 20 ball slams, another 50m of burpee broad-jumps, and so on until we finished with 10 kb swings and 50 ball slams. I was not in the best place mentally for this -- I hate burpees. But Danielle and the other folks provided lots of encouragement, and helped me get through it. Thanks you guys!

And Robyn is challenging us to do burpees every day -- 1 on Oct. 1st, 2 on Oct. 2nd, and so on. I missed the first couple days worth, so I have to do 6 today, and then it will be 4 tomorrow, 5 on Monday, etc. The end goal is to do 100 burpees for time on Jan 8th. Oh man, that's gonna suck.

Today's workout

2009-10-01T21:34:00.000-06:00

The workout at the gym today was called "The Bear". You had to do the following:

- Power Clean
- Front Squat
- Push Press
- Back Squat
- Push Press

7 times to count as one round, without putting the bar down. Then you could rest as much as you wanted before starting the next round. And you had to do a total of 5 rounds. And it was hard. I started with a 40lb bar and then added 10lbs for subsequent rounds, and it was still hard. I don't even want to say how long it took me to get through it (hint: more than 45 minutes). Part of the challenge is I'm still working on my form, but most of it is that I have a lot of work to do yet to get strong. It was a great workout even so.

Today's workout

2009-09-30T22:42:00.000-06:00

Rowing: 6525 meters in 30 minutes

Today's workout

2009-09-28T22:07:00.000-06:00

The workout today at the gym was:

1 mile run
100 pullups
100 pushups
100 situps
100 squats
1 mile run

I substituted jumping pullups, and half-pushups plus kettle bell swings. My total time was 52:08. I got the first mile done in 8:48 which is pretty good for me at this point.

Fight Gone Bad results

2009-09-26T12:49:00.001-06:00

Fight Gone Bad is one of the standard named workouts in CrossFit, and today's workout at my gym was part of a fundraising event that lots of gyms participated in. You spend one minute at each of five stations after which you get a one-minute break, and then you go again. The stations are:

   1. Wall-ball, 10 ft target (Reps)
   2. Sumo deadlift high-pull (Reps)
   3. Box jump (Reps)
   4. Push-press (Reps)
   5. Row (Calories)

You have to do three rounds and the clock does not stop until the three rounds are done. Then you add up your reps (and calories from the rowing machine), and that's your score. There are four divisions, and I was in the one called "Class B: Modified Men/Standard Women" which means that the weights are lower than in Class A.

I got a score of 206. I anticipate moving up to class A next time, but until then I need to work on having perfect form at each station and be able to keep going without any short breathers. Anyway, it was a lot of fun, especially that so many people showed up to participate!

Edit: full disclosure -- I only did step-ups for the box jump (20") so that means my score was in reality lower, but I don't know what the proper scaling factor would be.

unboxing videos

2009-09-19T11:16:00.000-06:00

I'm wondering who it is that actually likes watching "unboxing" videos? E.g., 5 minutes of someone tearing the packaging off their new iPhone or whatever. There are hundreds of them on YouTube. Is it living vicariously, or do people just really enjoy new product packaging?

New music

2009-09-12T21:49:00.002-06:00

Here are some bands I've recently discovered via iTunes. Check 'em out:

What am I getting myself into?

2009-07-26T17:46:00.004-06:00

I'm joining a CrossFit gym. I went to a free workout yesterday with my wife Danielle to check out the gym I will be joining. She has taken me to Saturday workouts at the gym she goes to. I like her gym, but MBS is closer both to home and to work, so it's more practical for me to get there regularly. This is the start of some really tough workouts for me, but if I can make it through the first month, I'll be OK.

8/28/09 Update: I moved to the gym Danielle has been going to after all. MBS is great, but for various reasons I like Foothills Crossfit better. And I signed up for the Fight Gone Bad IV fundraiser that will happen in late September.

First day of summer

2009-06-21T16:19:00.004-06:00

Smells like it's going to rain, again. We can't seem to get out of this weather pattern. In recent years, it had become common for June in Colorado to be hot, hot, hot, and everything not getting regular watering would already be turning brown. Not this year, and the constant rain has had its pluses. But the tornadoes and hail definitely fall on the minus side. This is coming from someone who lives west of I-25 in Colorado snuggled right up against the Front Range, which is to say that we don't have near as much 'fun' as people east of I-25 have, where the real bad stuff comes out of the sky with alarming regularity.

Man, our lawn needs a whole lotta work.

A quick message

2009-05-10T13:53:00.000-06:00

If you really want something from me, please try being more direct.

Net profiles

2009-05-09T10:04:00.006-06:00

From time to time, I indulge in a little bit of ego-surfing to see what other people see if they search for me. Of course, many of the results reflect my involvement in programming projects on the Net. But I also have noticed various social networking sites that have a default profile set up for me. These sites seem to spring up like mushrooms. It's funny to see what little snippets of my Net presence each of these sites picked up.

I never felt very motivated to go around and update these profiles until recently, but I did a little of that today -- ZoomInfo, Spoke, LinkedIn. And I updated my Google Profile.

9/12/09 update: I'm on Facebook now, if you couldn't already guess.

ladders

2009-02-09T21:44:00.007-07:00

Here's a completely random thought. Is a ladder in Go an instance of Irrational Escalation? They are considered to be easily read out, so what is gained by even playing one more stone? I wonder if experienced players quickly recognize the development of a ladder before it gets past even a couple stones.

And then, what implications are there, if any, for a strong Go program? I mean, as far as dispensing with the play-out, if that's what good players do?

Go from a set theoretic perspective

2008-06-25T23:07:00.010-06:00

As I work on Dakengo (my Go playing engine written in Common Lisp), I'm constantly trying to think in terms of abstractions. Consequently, one of the ideas that popped into my head recently is to try to build a set theoretic model of Go and see if I can derive anything useful. So starting with this entry, I'm going to write down these ideas as they develop.

Some definitions are in order. I'm going to use the term position to refer to a board configuration with zero or more black and/or white stones placed on the intersections, as they would be in a game of Go.

I'm going to use the term size to refer to the dimensions of a square board. I'm going to restrict myself to board sizes that are actually played in the real world: 9x9, 13x13, and 19x19. Of course, I can add more to the list (for example, some people toss around 25x25 as the next largest board size that anyone might consider playing). The important point is at the end of the day my goal is to write code that runs on actual machines, so I'm not interested in mathematical infinity. It's tough enough that the number of possible positions is so large as to be practically infinite, even if technically finite.

Also, I'm going to assume some other basic attributes of a game of Go, such as there being two players, one playing white stones and the other black, that each player alternates in placing a single stone (possibly removing prisoners), and that there are mutually-agreed conditions under which the game will end. I'm not going to consider non-traditional variations derived from Go.

Let's consider sets of positions. One such set to contemplate is that which contains all possible unique positions. Let's call it P. This set is finite because on any given Go board there are finitely many possible configurations of black stones, white stones, and empty intersections. And as I mentioned above, I'm restricting myself to a finite number of possible board sizes.

Right off the bat, I want to partition P into subsets. This is because when we want to start a game of Go, we have to make some choices before the first stone gets placed. Those choices then reduce the kinds of positions that we need to reason about as the game proceeds. And reasoning about positions is what this effort is all about.

With some simplification, the choices boil down to:

the size of the board
which scoring rule is in effect
which ko rule is in effect
whether suicide moves are allowed

For the time being, I won't drill down into what the different superko rules are, or how territory scoring compares to area scoring, or what the end game protocol is, or any other such details. That stuff doesn't matter at this point and will just muddy the waters. What's important is that choices from those areas have to be made in order to play.

Let's use Pnr as the name for the subset of P whose members, which I'll often refer to as p or q or some other lowercase letter, are constrained to those that are valid based on the rules listed above. Here n is one of the board sizes (9, 13, 19, etc) and r is a selection from the other choices. I think much of the time, I won't specify r in any detail, but I think it will be helpful to be explicit about n in most cases.

Next time, I want to talk about interesting subsets of Pnr, and even more interesting than that, I want to define relations between elements of these sets.

A new blog and a clean slate

2008-06-15T18:24:00.001-06:00

Welcome to my new blog. I'm retiring Step Away from the REPL in favor of this one, which will be more free-form in the sense that I will write about anything that comes to mind, rather than only Lisp or programming. That being said, I won't stay away from programming topics on purpose and probably will still jabber about it quite a bit, like for example in this very blog entry.

So yes, I still do a lot of programming in my free time. I'm working on a computer-go engine which I call Dakengo. I don't have a webpage for it yet, but that will be addressed. There is a backend written in Common Lisp (specifically SBCL) where all of the decision-making is implemented, as well as support for SGF and GTP and various other bits of infrastructure. And there are some pieces, such as the GUI, implemented in other languages. I'll write more about Dakengo in the future.

Anyway, there it is. Thanks for reading this stuff.

GNU CLISP 2.42 has been released

2007-10-16T22:08:00.000-06:00

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.

new burden on sites hosting open-source projects

2007-09-04T10:46:00.000-06:00

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.

clim-graphic-forms event handling still broken

2007-08-25T01:50:00.000-06:00

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.

Graphic-Forms version 0.8.0

2007-08-20T23:28:00.000-06:00

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:
http://prdownloads.sourceforge.net/graphic-forms/graphic-forms-0.8.0.zip?download

The project website is:
http://common-lisp.net/project/graphic-forms/

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

doc authoring system

2007-08-05T19:40:00.000-06:00

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">
<syntax>
  <arguments>
    <argument name="coords">
      <description>
        One of:
        <itemizedlist mark="bullet" spacing="compact">
          <listitem>
            A <refclhs>list</refclhs> of alternating x/y coordinate values.
          </listitem>
          <listitem>
            An <refclhs>integer</refclhs> x coordinate value.
          </listitem>
        </itemizedlist>
      </description>
    </argument>
    <notarg name="&optional"/>
    <argument name="y-coord">
      <description>
        An <refclhs>integer</refclhs> y coordinate value.
      </description>
    </argument>
  </arguments>
  <return>
    <refclhs>vector</refclhs>
  </return>
</syntax>
<description>
  This function returns a <refclhs>vector</refclhs> representing one or
  more points.
</description>
<seealso>
  <reftopic>lpc:point-x</reftopic>
  <reftopic>lpc:point-y</reftopic>
  <reftopic>lpc:point-elt</reftopic>
</seealso>
</function>

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:

http://lispwidgets.net/make-point-doc.png

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.

8 July 2007

2007-07-08T23:13:00.000-06:00

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.

arbitrary precision decimal library

2007-05-26T20:03:00.000-06:00

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.

1 April 2007

2007-04-01T19:11:00.000-06:00

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.

a small Graphic-Forms fix that helps SLIME users

2007-03-19T08:22:00.000-06:00

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.

17 March 2007

2007-03-17T13:57:00.000-06:00

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.

research topics followup

2007-01-19T23:33:00.000-07:00

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.

research topics

2007-01-01T21:09:00.000-07:00

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.

shell extensions gotcha

2006-12-18T21:07:00.000-07:00

Jeff Shrager posed this question back in September regarding his desire to create a Windows Explorer shell extension using Lisp (not specifically CL). I replied thusly and he later indicated that he'd had success.

It didn't occur to me at the time, but I've just now discovered that implementing shell extensions via certain implementations of Lisp, or any other single-instance runtime environment for that matter, might not be such a good idea. This thread has discussion of a similar idea, in this case involving the CLR. As a couple knowledgeable people point out in the ensuing discussion, the problem is that every application that does a mundane thing like invoking the common file dialog suddenly gets the runtime you used for your extension (Lisp or CLR or whatever) injected into it. Chaos could ensue for several reasons, for example if your runtime needs to reserve large chunks of virtual address space for itself that the host application isn't expecting and/or can't satisfy. Not to mention the potential inability of two such runtimes to co-exist in the same process, such as when you develop a GUI app that uses the same (or different!) version of said runtime.

There are easy-to-find examples and shareware floating around the Net for doing this. Nonetheless, I'd take Jesse Kaplan's and Raymond Chen's opinions at face value and think really hard about which Lisp I was using before venturing down such a path.

AllegroCL 8.0 port

2006-12-16T20:48:00.000-07:00

On the spur of the moment, I decided to try porting Graphic-Forms to AllegroCL 8.0. After a few hours work, I got all of the test programs running. It was fairly straightforward. These days, it seems that the main complication in porting Graphic-Forms is translating stdcall callback definitions into the vendor's particular FFI vocabulary. A CL whose dynamic FFI is a second-class citizen is likely to be a troublesome porting target, though.

new job

2006-12-03T14:50:00.000-07:00

Tomorrow, I'm starting a new job that is mostly Java programming but may also involve some C++ and C#. At least in the beginning, I'll be working on non-graphical library code. The problem domain is pretty interesting and (for me) brand new.

Does this mean the end of my Lisp hacking days? Not at all. Throughout my career, I've consistently worked on projects in my free time -- I tell people that if programming wasn't my job, it would be my hobby. And I know there are lots of people who feel the same way. Lisp multiplies the fun by 10x (or whatever factor you want to plug in, it's large). I am and will continue to be an enthusiastic member of the Lisp community.

I am returning to the so-called commercial software development world armed with a broader view of how to solve problems. I also have a pragmatic view of Java programming as a technology, and Java/C++ programmers as highly capable and intellectually stimulating folks with whom to work. It will be nice to collaborate with folks on a face-to-face basis.

Meanwhile, I continue to work on Graphic-Forms and look forward to making the next release available (I'm thinking January is likely). My McCLIM backend project continues as well. I salute the SBCL developers for getting to the 1.0 stage and hope to find ways of contributing to the Win32 port. I continue to be one of the binary package maintainers for CLISP. And there are some other projects that I have cooking.

If only there were more hours in each day!

Graphic-Forms version 0.7.0

2006-12-01T17:54:00.000-07:00

Release 0.7.0 of Graphic-Forms, a Common Lisp library for Windows GUI programming, is now available. This is an alpha release, meaning that the feature set and API have not yet stabilized.

Here is what's new in this release:

. Implemented cursor support. Applications can choose from the system-defined cursors or load them from external files. Also provided are convenience macros GFW:WITH-CURSOR and GFW:WITH-WAIT-CURSOR.

. Implemented a new layout manager called GFW:BORDER-LAYOUT which allows applications to assign children to regions around the perimeter of a window or the center.

. Implemented GFS:OBTAIN-SYSTEM-METRICS as a higher-level interface to the Win32 GetSystemMetrics() API. It returns a hash table containing slightly post-processed system metrics values.

. Implemented the function GFW:PROCESS-EVENTS to help applications flush the event queue of pending events.

. GFW:APPEND-ITEM now accepts an optional classname argument so that applications can use custom item classes.

. Implemented a new macro GFW:WITH-ROOT-WINDOW which manages the lifetime of an instance of GFW:ROOT-WINDOW for use within the macro body.

. Fixed ASDF loading problems.

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

Download the release zip file here:
http://prdownloads.sourceforge.net/graphic-forms/graphic-forms-0.7.0.zip?download

The project website is:
http://common-lisp.net/project/graphic-forms/

my McCLIM restart

2006-11-19T20:15:00.000-07:00

After realizing I had tried to absorb too much too fast in terms of McCLIM and backend implementation, and after taking a break from it, this weekend I pressed the Reset button. Not that I've thrown any code away, but rather, I'm going to spend some time working with McCLIM in its natural habitat -- that is to say, via SBCL on Linux and the CLX backend (maybe I'll experiment with gtkairo too, we'll see). I'll get some practical experience with it in an environment where it works, then return to my Win32 backend implementation.

[Update: well, my Gentoo install is old enough that GTK+ 2.8.19 fails to build. So it's back to CLX on Win32 after all. I really should upgrade my Linux, though.]

releases rant follow-up

2006-11-17T00:43:00.000-07:00

I can't seem to add a reply to either of Greg's blog entries concerning my "releases" rant (or else there will be duplicate comments showing up, oops!) so I'll respond here and hope that he sees it.

As Dave mentioned in his comment on your blog, and after considering your more recent ideas, I suspect you're still tackling a different problem (and that's OK, I acknowledge that you may have a different perspective). I think you're assuming a certain state of mind that translates into critical thinking about what exactly a release tag corresponds to, whereas my concern is with developers who have been explicit about their decision not to spend mental energy on that. The result is that I can't justify adding their code as a dependency for my users.

"we don't do releases"

2006-11-15T15:59:00.000-07:00

I have encountered several CL libraries whose dev teams are either indifferent about doing official releases or have an explicit statement on their project website(s) notifying the world that they don't plan to spend time on such activities. One project in particular observes that formal releases are a lot of work and they can be troublesome, and hey installation is as easy as typing `darcs get blah...'

What these developers fail to recognize (or maybe don't care about) is that this attitude puts the next developer down the foodchain in a difficult position. Here's my perspective -- every dependency of my project is automatically a dependency for my users. When the current source control version doesn't work or whose API/behavior is changing dramatically from day to day, this becomes my problem. I am in a much better position to debug such an issue or look for a substitute, so I don't think it's fair to ask my users to do it. Obviously, I prefer to have some control over the situation, such as being able to say "the version of foobar I have tested for use with my project is 0.x.y patchlevel z". But when a project's release procedure consists of telling people to check out the latest from source control, I have little or no control over which version my users actually get.

So when I see a library that looks useful but doesn't do official releases, I have to decide amongst three choices: a) move on in the hopes of finding an equal or better alternative, b) bundle a snapshot of the library inside my own project, or c) nag the developers to make snapshots available that others can depend on being available (for some useful amount of time). None of those are good choices, frankly.

One last comment...I'm not complaining about brand new projects whose websites are barely a week old. In cases like that, one generally either sees a statement like 'this stuff is brand new and we haven't done any release yet' or it's just easy to tell. Every project has to start somewhere. My beef is with projects that have been around and whose developers really ought to know better -- this is basic configuration management.

12 Nov 2006

2006-11-12T13:49:00.000-07:00

The last two weeks have been a disaster as far as productivity goes. I've had some distractions (of the good kind) and I guess have been feeling somewhat burned out. But forward progress has not completely ground to a halt, and so here is what I've been up to lately.

I haven't made much progress on a McCLIM backend work since those first few days after I announced the start of that project. This is not due to lack of interest! I think I was pushing a little too hard in my efforts to simultaneously understand the CLIM spec, and the existing codebase, and write backend code at the same time. This resulted in signficant burnout, so I decided to put this aside for a bit.

I was embarrassed to discover basic problems with loading the Graphic-Forms system, which I briefly mentioned in my previous blog entry. Who knows how many folks downloaded recent releases and gave up because of this. Well, at least there are fixes available (posted to the mailing list and checked in). Serves me right for not actually using the documented procedure myself. That too has been fixed.

My research into broader layout management functionality has continued. I have spent significant time investigating MiG Layout, which is a monster all-encompassing layout engine in Java. I don't intend to clone that thing, I'll just use it as a rich source of ideas to go along with the many other layout managers that are out there (in different languages). In a related vein, I've always recognized the importance of constraint-based layouts, so I've been on the lookout for constraint engines. A new project called computed-class has caught my eye. The project page advertises simplicity relative to some of the competition.

As for actual coding, I've been working on something called border-layout, which organizes a container window into 5 regions, each of which may be assigned a child component. I anticipate finishing coding and testing of this new layout class within the next several days.

note to self: when releasing software, test the build process

2006-11-01T15:56:00.000-07:00

Please see the following posting to graphic-forms-devel concerning fixes for loading Graphic-Forms:

http://common-lisp.net/pipermail/graphic-forms-devel/2006-November/000022.html

delving into McCLIM

2006-10-28T13:25:00.000-06:00

I've taken the plunge and started working on a new backend for McCLIM using Graphic-Forms as the substrate. Thus, the result will be a native Win32 backend. Realistically, some time will have to pass before I've got enough functionality working that at least the standard demos can run. It's OK to make quick-and-dirty hacks just to see something pop up on the screen, but if I'm going to propose adding this backend to McCLIM for real at some point, then it needs to play by the rules.

There are plenty of good reasons to take this project on, but for me the most compelling argument is that CLIM represents a much higher-level way of thinking about GUI building. Since I think of myself as somewhat of a specialist in GUI development, this is very important. After I've climbed the somewhat steep learning curve, digesting new concepts along the way (like what the heck `flipping ink' is all about), I'll be that much stronger in my GUI-fu. I can take some of these concepts back to my design of Graphic-Forms -- not necessarily with the intention of directly incorporating CLIM concepts like presentation types, but as a way to take a fresh look at the services that GF provides. After all, GF is itself an abstraction layer over the Win32 User/GDI APIs and does some translation of raw Win32 concepts to Lisp-y abstractions.

A secondary benefit of this will be more code that uses Graphic-Forms, and maybe more users (albeit indirectly).

By the way -- hooray for open-source and Lisp and learning new things and having the ability to spend as much time as I want on this stuff!

Graphic-Forms version 0.6.0

2006-10-22T13:08:00.000-06:00

Release 0.6.0 of Graphic-Forms, a Common Lisp library for Windows GUI programming, is now available. This is an alpha release, meaning that the feature set and API have not yet stabilized.

Here is what's new in this release:

. CFFI snapshot 060925 or later is now required if you are running CLISP 2.40 or later (due to a change in the argument list of CLISP's FFI:FOREIGN-LIBRARY-FUNCTION).

. Completely revamped the Programming Reference. DocBook/XSL is now used for help authoring, and the manual is delivered in HTML Help format.

. Implemented scrolling protocol and related helper objects and functions to facilitate scrolling functionality in applications:

* window styles :horizontal-scrollbar and :vertical-scrollbar

* functions to retrieve window scrollbars

* GFW:EVENT-SCROLL function for handling low-level scrolling events

* GFW:SCROLLING-HELPER for automatic management of a scrollable child panel and window scrollbars (works in combination with GFW:HEAP-LAYOUT)

* integral scrolling and resizing for step sizes greater than 1

. Initial list box control functionality implemented:

* three selection modes (none / multiple / extend)

* list item data comprised by arbitrary application-defined data

* application defined sorting predicates

* querying and programmatic control of item selection states

* customizability of vertical scrollbar mode and keyboard input

Additional list box features are planned for a future release.

. Implemented stand-alone scrollbar and slider control types.

. Renamed functions that query the standard color, file, and font dialogs to make their naming scheme more consistent.

. Implemented GFW:EVENT-PRE-RESIZE function so that applications can customize the behavior of a window's size drag rectangle.

. Implemented GFW:EVENT-PRE-MOVE function so that applications can customize the behavior of a window's move drag rectangle.

. Improved GFW:HEAP-LAYOUT such that it obeys the top child's minimum and maximum sizes, if any such sizes are set.

. Added GFG:FONT method for querying the current font selected for a window.

. Did some housecleaning of the item-manager protocol and heavily refactored the implementation of item-manager base functionality.

. Implemented GFW:ENABLE-REDRAW to enable applications to temporarily disable (and later re-enable) drawing of widget content.

. Fixed a bug in GFW:CHECKED-P (and GFW:SELECTED-P) for checkbox and radio button -style buttons.

. Fixed a bug in the initialization of the paint rectangle in the WM_PAINT message handling method; the correct rectangle is now passed to
GFW:EVENT-PAINT

. Fixed a bug in the SETF functions for GFW:MAXIMUM-SIZE and GFW:MINIMUM-SIZE for windows whereby the size value was not being set in the appropriate slot if there were no layout set for the window.

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

Download the release zip file here:
http://prdownloads.sourceforge.net/graphic-forms/graphic-forms-0.6.0.zip?download

The project website is:
http://common-lisp.net/project/graphic-forms/

Jack Unrue
jdunrue (at) gmail (dot) com
22 October 2006

new FAQ page

2006-10-01T15:06:00.000-06:00

I posted a new FAQ page for Graphic-Forms here. As much as this is intended to advocate my project, hopefully it also helps advocate in favor of GUI programming in Common Lisp on Windows. Comments and suggestions are welcome.

DEFSETF misadventure

2006-09-08T00:31:00.000-06:00

While working through some new unit-tests for Graphic-Forms, I happened to discover an assertion failure in an existing test occurring when I run the test more than once. Strangely, it happens on LispWorks and SBCL, but not CLISP. -- Drat! -- The failing assertion validates an attribute value set on a test layout manager (which is created anew every time the test runs), then a bit further on the test sets this attribute to a different value and checks it again. The failure scenario is on the second run. Right now, it looks like the 2nd value from the first run has persisted and that's why the assertion fails.

The culprit appears to be a `short form' DEFSETF defined in Graphic-Forms so application code can SETF attributes on layout managers. Or perhaps the culprit is an attribute setter function upon which the DEFSETF is implemented?

These layout manager attributes are stored in per-object lists; there is no global state in my code where these attributes are concerned. Perhaps there is some memoization being done behind the scenes? It's very puzzling.

my copy of AMOP arrived

2006-09-03T11:14:00.000-06:00

A few days ago, I received a used copy of AMOP ordered through Amazon. This was getting to be a long-overdue stage in my development as a Lisper, because while I have written some MOP-using code (portably, thanks to Pascal Costanza's excellent Closer to MOP library), I had not yet actually studied the MOP from end to end.

One little suggestion for my fellow used-book shoppers: when a seller describes a used-copy's condition as "acceptable -- light underlining and notes in blue pen throughout," I heartily recommend moving on to the next seller. Because even though this copy arrived exactly as described, I had no idea how completely annoying it is to try to read text on the page when the previous owner has underlined nearly every single line, even in the code samples, and added little squiggles and extra notes because apparently the underlining wasn't enough! And in blue pen, which nicely stands out! Aargghh.

Anyway. Obviously, this book demystifies what the MOP is all about. Reading it gets one to thinking "hey, I could do that." Sort of the same feeling one gets while taking an operating system class in college -- getting into the nuts and bolts, one realizes that a lot of what makes up a kernel is just record-keeping (yes yes yes, there are nasty details, too). Implementing a layered architecture with good performance while preserving extensibility is a neat trick, though. This book gives me much to think about.

Mr. Interesting-Problems-To-Solve

2006-08-30T20:37:00.000-06:00

I had to laugh a while back when I read through one of the now semi-recent threads on comp.lang.lisp, wherein a certain old-timer boasted about how many of us ought to send him our resumes. Although he had his hands full with interesting problems to solve, he allowed as to there being possibly a month or two of boring code to be dealt with afterwards; and we knuckle-draggers who spend most of our time slogging through the muck might be able to handle that (pending credentials review, of course). OK, he didn't write anything about "knuckle-draggers," that part was my invention.

Getting the boring code done -- the stuff about to drive you bonkers because it's so boring -- is a thankless job, but you'll hear about it when you actually get users and they find out you've skimped on certain details. The boring code stops some people from getting their projects past a certain, how shall I say it, critical juncture. Everybody prefers the interesting problems (the 20%), but some folks can't grind out the rest of the project (the 80%), and they move on to greener pastures. I don't think Mr. Interesting-Problems-To-Solve is one of those folks; I'll bet his work is good and thorough. But I laughed because I've seen that attitude for real.

Now where was I? Ah yes, list box notification messages. Oh goody.

Graphic-Forms version 0.5.0 released

2006-08-22T18:08:00.000-06:00

Release 0.5.0 of Graphic-Forms, a Common Lisp library for Windows GUI
programming, is now available. This is an alpha release, meaning that
the feature set and API have not yet stabilized.

Here is what's new in this release:

. SBCL is now supported (specifically version 0.9.15). Graphic-Forms
includes a small patch provided to the SBCL community by
Alastair Bridgewater to enable the stdcall calling convention for
alien callbacks. Please see src/external-libraries/sbcl-callback-patch

. Implemented a plugin mechanism for integrating graphics libraries. This
means that ImageMagick is now optional -- if your application can get
by with just BMP and ICO formats, then the default plugin (which has no
external dependencies) may be used. This feature also allows applications
to integrate other graphics libraries of their choice.

. In addition to ImageMagick now being optional, external library
dependencies have been further simplified. Several small libraries
are now directly bundled with the Graphic-Forms. Cells is no longer
used in the library proper nor in the demos (but may return at a
later point).

. Implemented a class called icon-bundle which may be populated with
multiple images and then used to set icon data for window frames.
This includes the concept of there being 'large' and 'small' icon
sizes.

. Simplified the argument lists for the event-*** generic functions.
Provided gfw:obtain-event-time as a substitute for passing a time
argument to every function (for which the vast majority of methods
had no use).

. Defined the following new generic functions:

* event-session GF so applications can participate in the
WM_QUERYENDSESSION / WM_ENDSESSION protocol.

* event-activate and event-deactivate GFs so applications can respond
to window activation state changes.

* GFs for querying undo and redo state. Implemented corresponding
methods for edit controls.

* GFs for configuring auto-scrolling and scrollbar visibility. Implemented
corresponding methods for edit controls.

* GFs representing text clipboard data convenience functionality.
Implemented corresponding methods for edit controls.

. Made other miscellaneous improvements to flesh out edit control
support.

. Implemented the standard color chooser dialog and associated
convenience macro 'with-color-dialog'.

. Added the macro 'with-graphics-context' as a convenience for code that
needs to instantiate a context outside of event-paint.

. Heavily revised internal layout manager code in preparation for
supporting more sophisticated layouts. A new class called layout-managed
has been created to serve as a mix-in when defining objects (not
necessarily only windows) that have children to be sized and positioned.

. Implemented a new demo program called textedit which is essentially
a Notepad clone. Its purpose is to show off the multi-line edit
control and the standard Find/Replace dialog.

. Upgraded to the latest lisp-unit and changed test loading code so that
unit-tests are no longer compiled.

. Wrote more documentation and reorganized existing content a bit.
Added discussion of certain naming convention choices.

. Made a variety of bug fixes.

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

Download the release zip file here:
http://prdownloads.sourceforge.net/graphic-forms/graphic-forms-0.5.0.zip?download

The project website is:
http://common-lisp.net/project/graphic-forms/

porting code is good!

2006-08-19T20:41:00.000-06:00

A long time ago, I used to work at a company called XVT Software, whose main product during that time was a C-language-based user interface portability toolkit. (Yes, we had other products, but the C toolkits were the bread-and-butter). For those of us on the development team, the mantra was 'port early, port often.' We had to deal with lots and lots of environments, and as anyone in the biz back then knows, even within (or especially within!) the Unix-like family tree, the differences between vendor implementations were huge. So you saved yourself a lot of trouble by following our mantra.

Even though as a complete Lisp newbie I knew there were differences between CL implementations, I have only recently started to understand at a deep level how much our old mantra from XVT applies to the CL world. I now have code running well on LispWorks, CLISP, and SBCL. And what I've discovered is that code porting, rather than being a negative, is actually very healthy. In my experience, it has been a process of fine-tuning and improvement, as each new compiler points out bad habits, opportunities for cleanup, etc. In fact, I would go so far as to recommend folks with single-vendor codebases to make some effort at porting to at least one other implementation -- no matter how good your current compiler is (or how good you *think* it is), there will almost always be new/useful tidbits that another compiler will point out. If you try it, I think you'll be glad that you did.

2006-08-18T14:04:00.000-06:00

Just testing Writely integration with my blog. Move along, nothing to see here.

graphics library plugin mechanism

2006-08-13T22:04:00.000-06:00

I've recently implemented a neat abstraction in Graphic-Forms. For quite a while now, it has been possible to load image files from disk so that they may be displayed. Until recently, I required the use of ImageMagick to handle the file loading task. It's a very nice library, and I have a small binding implemented for the MagickCore API which is the low-level C-based API. But it's also heavyweight -- your process ends up loading quite a large number of DLLs due to interdependencies in their code, and what's possibly worse is that you pretty much have to do a 'real' install because their code expects certain registry entries and directory structures to exist.

What I've done is to create a simple plugin mechanism, the key aspect of which is implementation of a bit of code in each plugin to translate from library-specific representation of image formats to the Graphic-Forms IMAGE-DATA class. The latter is then what the main library code consumes for image creation and attribute querying. When an image file is to be loaded, each registered plugin is given a chance and the first to succeed wins.

Based on that mechanism, I've now implemented an ImageMagick plugin that you can use if you need to handle more formats besides BMP and ICO. Or if those two formats are all you need, you can load the 'default' plugin which has Lisp code that understands those two formats directly. You can implement additional plugins in application code if you want to use some other graphics library; I plan to document how to do this in the next release.

By the way, another benefit of this strategy is that you can write pixel processing code in terms of IMAGE-DATA or in terms of the external library of your choice, and then create IMAGE instances using IMAGE-DATA as input to display the result.

SBCL port

2006-08-10T00:52:00.000-06:00

Just a quick update. Among the various things I'm working on for the next release, I've now got a significant part of Graphic-Forms up and running on SBCL/Win32. Woot!

input requested: adding a Lisp listener

2006-07-10T17:38:00.000-06:00

I'm thinking about adding a Lisp listener to Graphic-Forms, and was
hoping to get some input. Do you think it is:

a) a "must have" feature if GF is to be taken seriously

b) a "nice-to-have" feature that you could live without
(note -- thinking of the availability of SLIME or
commercial IDEs as I write this)

c) more important to make sure apps built with GF have
the right building blocks for a listener, rather than
bundling one directly with the library proper

d) a complete waste of time

???

a lesson in CLOS-based interface fine-tuning

2006-07-10T12:05:00.000-06:00

I recently made a fine-tuning pass through the argument lists for event-handling functions in Graphic-Forms and had an interesting experience.

First a bit of background. In Graphic-Forms, applications handle each event type by implementing the associated generic function. E.g., one implements EVENT-SELECT to handle a button press or menu item click. Prior to this past weekend, every event function included a time argument, which was a system-generated timestamp for the event. Other UI libraries have included that information (such as SWT's TypedEvent, which has a time instance variable) so I had figured it would be a good idea to include it in my library. Going ahead with this design choice without thinking harder was my first mistake: events in SWT are objects that are passed to interface methods, thus they can carry any amount of ancillary information with little added cost (from the standpoint of an application implementing those interface methods).

Instead of realizing the design error, I made the narrower observation that an event timestamp is needed in only a few special circumstances -- and in all of the test code I have written so far, I was writing a (declare (ignore time)) form everywhere. That gave me some empirical evidence to justify changing the API. I wanted to alleviate the need for application code to worry about that argument, yet still have access to it in the rare cases where it is needed.

So, my first inclination was to make the time argument &optional. oops! In CLOS, optional arguments in methods have to be congruent in their number just like required arguments, so event method implementors are not saved any work this way.

Then I considered making time a keyword argument, so method implementors could specify &allow-other-keys when they don't need the timestamp. But that adds more clutter than it saves; in other words, a symptom of this being the wrong reason to use keyword arguments.

Finally, the light bulb above my head flickered on, and I decided to remove the time argument completely. As a substitute, I decided to provide a separate access function. Problem solved.

I took away a couple conclusions from this. First, CLOS not only has powerful features, but there are easy-to-see signs that you're misusing them if you just pay attention. And more importantly, it's a mistake to copy a feature without thinking hard.

Graphic-Forms version 0.4.0 released

2006-07-03T18:04:00.000-06:00

Release 0.4.0 of Graphic-Forms, a Common Lisp library for Windows GUI
programming, is now available. This is an alpha release, meaning that
the feature set and API have not yet stabilized.

Here is what's new in this release:

. CFFI snapshot 060606 or later is required in order to benefit from a
bugfix for a problem when running on LispWorks where foreign structure
contents could be corrupted; the most obvious symptom of this was a
Win32 error encountered when attempting to create a window.

. A new layout manager called `heap-layout' has been implemented. Its
purpose is to align all the children of a container in a single
Z-orderwise stack and allow the application to select which of the
children are top-most at any given time. This is useful when
implemnenting windows with panels containing related functionality,
where only one such panel should be visible at a time (e.g., property
sheets or wizard dialogs).

. This release provides access to the standard font dialog, and
integrates with the previously-defined font and font-data classes.

. Application-defined modal and modeless dialogs are now fully
supported, including keyboard navigation (tab traversal, default
button invocation via the ENTER key, and cancel button invocation via
the ESC key).

. In this release, the flow-layout manager gets a new style called
:normalize which instructs the manager to size children equally using
the maximum dimension of the children's preferred sizes opposite to
the dimension in which the layout is oriented.

. Applications may set minimum size and/or maximum size constraints
for top-level windows. Setting both constraints to the same size
implicitly disables resizing by the user.

. It is also possible to explicitly disable resizabilty, which not
only results in a fixed window size but also causes window decorations
to be updated appropriately (no maximize box and no resize handles in
the window frame).

. The button class has been expanded to support checkboxes, radio
buttons, toggle buttons, and tri-state button controls.

. There is now basic support for instantiating single-line and
multi-line edit controls. Edit controls participate in the focus gain
/ focus loss protocol; they also provide notification when contents
change via the event-modify generic function.

. Implemented event-focus-gain and event-focus-loss to allow applications
to response to changes in focus.

. It is now possible to customize the background color, foreground
color, and font of label controls. Infrastructure to support similar
customizations for other controls is in place.

. Functions capture-mouse and release-mouse are available to implement
mouse capturing behavior.

. Added a function to programmatically append separators to menus;
this was already possible via DEFMENU but not yet supported for
dynamic menu management.

. Rewrote timer event processing such that the library no longer uses
the TimerProc callback technique, but instead each call to the Win32
SetTimer function is made with the handle to a hidden utility window
managed by the library code.

. Changed the rectangle type to be a structure; it was a class before.

. Started work on infrastructure required to support a new layout
manager called `group-layout' which will appear in a subsequent
release. The infrastructure developed this time includes definition of
a text-baseline method that widgets implement to help layout managers
align text appropriately.

. Also started work on infrastructure needed to enable WinXP-themed
controls.

. Continued work on the UnBlocked demo game.

The above list is in addition to documentation enhancements and
bug fixes. The README.txt file in the release zip file also has
additional important information about this release.

Download the release zip file here:
http://prdownloads.sourceforge.net/graphic-forms/graphic-forms-0.4.0.zip?download

The project website is:
http://common-lisp.net/project/graphic-forms/

WGA WTF???

2006-06-27T23:01:00.000-06:00

I have been somewhat tolerant of Microsoft's flaws and missteps, especially compared to many in the Lisp community. It seemed to me in the last couple of years that MS dialed down their aggressive/monopolistic tendencies somewhat and revisited their attitudes/strategies towards open-source, standards organizations, communication with the outside world, etc. For instance, the reality of Windows Activation for XP turned out to be pretty reasonable -- certainly a lot less draconian than some thought back when XP was approaching its ship date.

Lately, Microsoft has been getting some bad press about Windows Genuine Advantage, e.g., here and here. Not a very good track record so far! I myself have not encountered any severe problems, so I was willing to believe that this stuff would eventually get sorted out and all would be well.

But I just read this, which is speculation that in the future MS may require legally-licensed Windows users to install WGA or risk having their system disabled. The reply Ed Bott received from MS when he asked for official confirmation is a red flag. It would be very hard for me to rationalize continuing onward as a Windows developer if this speculation becomes reality. WGA is more intrusive than Activation was, it has a poor track record, and I'm not as inclined to give MS the benefit of the doubt as I might have been in the past. So as I continue work on Graphic-Forms, I'm keeping an eye on this situation, as should all Windows users.

Common Lisp and Windows Vista

2006-06-25T22:05:00.000-06:00

The other day, I installed Windows Vista Beta 2 from DVD into a dedicated partition on my PC (the other partition is WinXP SP2). Beta 2 is the first Vista pre-release available to anybody and everybody, as opposed to the technical Betas available to MSDN subscribers and other similarly-connected folks. The only install hiccup that I encountered was that there is currently no driver for my sound system available though Microsoft Update. No biggy. By now, there are probably a dozen reviews of Vista Beta 2 out there, and this blog entry will not be another one. Just in case it helps somebody, here are a few review links:

Paul Thurrot's SuperSite for Windows

Ars Technica: A tour of Windows Vista Beta 2

AnandTech: Windows Vista: Beta 2 Preview

Naturally, I'm looking at Vista from the perspective of a Common Lisp programmer. So in addition to wanting to poke around the new system and see for myself what it's like, my intention is to get started working with CL implementations on this new version of Windows. In particular, I want to test Graphic-Forms and think about where GF should go, taking into consideration the ways in which the GUI subsystems are changing for Vista and beyond (e.g. some info about that here).

away from the REPL for a week

2006-06-09T11:54:00.000-06:00

Next week, I'll be in Maine on vacation and then attending my brother's wedding, so Graphic-Forms work will be interrupted briefly.

There are yet loose ends needing to be tied up before I can make the next release. I might spend some more time on preparations (which are already underway) for implementing the equivalent of GroupLayout that is going to be part of the next JDK/NetBeans release. There are some folks implementing this for SWT as well. And so I want something like it in Graphic-Forms, too. I want to revamp my existing layout-tester program to look and feel more like a GUI layout tool, as a more scalable and robust way of testing the layout managers I've written. Maybe layout-tester ought to evolve into such a tool for real instead of just being happy as a test program. Continuing down my todo list, there are some remaining issues with keyboard navigation in dialogs. I'd also like to implement at least one more common dialog and some controls (especially the edit control). And I'd like to change the graphics package to depend on ImageMagick only if the app developer explicitly chooses to.

The 0.2.0 and 0.3.0 releases saw a decent number of downloads, certainly more than I expected, which is really cool. Unfortunately for me as the lead developer, there has been practically no feedback on the dev mailing list. I'm not working very hard at building `community' around this code, for one thing. I suspect not many folks are getting past the `open the tarball and look at the code' stage. And maybe there aren't that many folks interested in a Windows-only UI library for Common Lisp.

Another possibility is that people are reluctant to invest time and effort in a brand new API that has no appreciable mindshare. I can sympathize with that and every day I think about what the best solution is. Forget about Graphic-Forms for a second, and consider my personal requirements for a UI library: must support Windows as a first-class target, must leverage platform-specific features wherever possible as opposed to compromising in the name of platform portability, must not have too many intermediate layers (especially not some toolkit in another language), and must (eventually, if not already) support multiple Lisp implementations. Right now, I'm not aware of any other UI library for CL that meets those requirements, aside from what I can build myself.

I just hope somebody gets some value out of the code besides me.

a slight detour

2006-05-27T18:39:00.000-06:00

My wife is a professional trombonist who also teaches private lessons in a variety of brass instruments. Her beginner students are especially in need of repeated drills on fingering / positions on their instruments. There are several training programs out there, and while each has useful features, my wife wasn't completely happy with any of them. Since she is married to a programmer :-) she figured she could acquire a program that had exactly the features she has been looking for.

So I've been working on this, and doing it in Common Lisp. I've been spending the majority of my time on it especially recently as a final push to get the first version out. While this has taken time away from direct work on Graphic-Forms, it has given me the chance to use GF as an application developer. That's a perspective that every library developer should take periodically; I believe "dogfooding" is a popular phrase these days :-) And this fingering training program has served as a good testcase.

So, this has been a slight detour in my work, but it's a worthy cause and a lot of fun, too.

pre-0.4.0 status report

2006-05-14T12:54:00.000-06:00

For those who are following progress on Graphic-Forms, here's another status report.

One of the major themes for 0.4.0 will be support for custom dialogs, and that is where most of my effort have been devoted since 0.3.0. One of the reasons why this feature has taken so long to appear in GF is that I put a lot of thought into whether to reuse the built-in dialog manager and dialog template mechanisms that Win32 provides.

A discussion of the tradeoffs could occupy a whole separate blog entry, which I think I will indeed write up and post sometime. I'll cut to chase for now and state that I'm using low-functionality to implement proper dialog behavior.

Some other miscellaneous development:

• implemented a layout manager called `heap-layout' whose behavior is to align all the children of a container in a single Z-order-wise column and allow the application to select which of the children are top-most at any given time. This kind of layout is useful when implementing windows with panels containing related functionality, where only one such panel should be visible at a time (think property sheets or wizard dialogs). The user can then flip between panels based on some gesture such as clicking on a tab control.

• implemented event-focus-gain/event-focus-loss for reacting to changes in focus

• fixed some bugs in key event processing that prevented repeated events for untranslateable keys (e.g., function keys F1-F12) from being delivered

• implemented background/foreground color and font customization for labels, with infrastructure put into place for other controls

• added a method to programmatically append separators to menus; this was already possible via DEFMENU but not yet supported for dynamic menu management

• rewrote timer event processing such that GF no longer uses the TimerProc callback technique, but instead each call to the Win32 SetTimer function is made with the handle to a non-visible utility window that the library creates

• fixed some problems with timer initial delays

That's it for now. Happy coding!

Graphic-Forms 0.3.0 released

2006-04-26T11:38:00.000-06:00

The next release of Graphic-Forms (version 0.3.0), a CL library for Windows GUI programming, is now available. This is definitely pre-alpha code, so be prepared for missing features, bugs, and API changes in subsequent releases.

Download a release tarball from here:

http://prdownloads.sourceforge.net/graphic-forms/graphic-forms-0.3.0.tar.gz?download

The primary changes in this release are as follows:

implemented graphics-context methods for the typical drawing operations and pen attributes; see the new test program invoked by (gft::run-drawing-tester)

implemented a representation of fonts and font data, including an API for looking up fonts based on font data

implemented font metrics and text metrics querying

expanded image drawing operations to support double-buffering

expanded the classes representing different window types: top-level represents primary application windows, panel represents child-windows, and the root-window class represents the desktop

formalized the window parent and owner concepts with documentation and functions

implemented the display class to represent the monitor attached to the system

implemented new window style attributes to help applications choose whether the system should automatically repaint the background

provided maximum-size and minimum-size functions to allow applications to constrain window sizes

revised label controls to support either text or images

implemented the file-dialog class which encapsulates the standard open/save dialog

made other bug fixes and resource usage cleanup

Please consult README.txt for other details about this release.

The main project website is:

http://common-lisp.net/project/graphic-forms/

Graphic-Forms progress report

2006-04-07T18:20:00.000-06:00

I’m making progress towards the next Graphic-Forms release. Here is a brief status update:

implemented graphics-context methods for the common drawing operations and pen attributes; there is a new test program invoked via (gft:run-drawing-tester) that exercises these operations

implemented a representation of fonts as well as font data and fleshed out the API for creating fonts from font data as well as obtaining font metrics; the aforementioned drawing tester program does exercise fonts

expanded the representation of windows, such that there are now classes representing top-level windows and child windows (the latter are called ‘panels’ in GF), as well as a root-window class representing the desktop and a display class representing the system’s monitor

also added new window style attributes to help applications choose whether the system should automatically repaint the background or not

did some testing and tracked down some embarrassing GDI handle leaks

currently developing a simple blocks game as a more complete demo and as a test bed for me to learn how Cells works

filed a bug with CLISP concerning stdcall callbacks, which impacts a couple of important functional areas in GF (the test case I submitted might be further reducible and I will work on that)

I’d like to get some more basic infrastructure done before the 0.3.0 release, such as:

in particular, complete my research of Cells and decide how/where to integrate that (in particular, I consider this a prerequisite for any further work on layout managers)

also more controls

at least a couple of the common dialogs

and of course more testing

Also, a short while after 0.2.0 went out, I entered ~70 bugs into the tracker at SourceForge. At this early stage, I view most of those as ToDo entries because they are missing features rather than unanticipated problems. Just today, Erik Enge announced that common-lisp.net now has Trac available, and I will certainly investigate further and perhaps decide to migrate issue tracking away from SourceForge.

Ideas for a Lisp FFI wiki

2006-03-29T20:03:00.000-07:00

A person named “Sacha” recently made the following comment on c.l.l in a thread entitled “CLISP and win32 clipboard access”:

> I've been recently working a lot with .NET, and found
> http://www.pinvoke.net/ to be very usefull.
> This web site is providing the .NET world equivalent to FFI for win32 calls.
> Wouldn't it be very nice to have such a wiki for FFIs ?

Yeah, I think there are several features of pinvoke.net that could/should be replicated in a Lisp FFI wiki:

entries for

data structures and immediate types

function signatures

consistent structure across each entry

summary

complete FFI definition that you can copy&paste

perhaps for just CFFI?

usage notes or gotchas

example code

alternatives, if any, for the current entry

pointer to relevant doc in the native library (e.g., ImageMagick manual, Gtk+ manual, MSDN, etc)

pros and cons of the various FFIs

address SWIG, Verrazano, and other automation tools

a search engine that has a decent syntax and the ability to constrain the search to specific areas (e.g., Google's group: modifier)

In other words, not a jumble of info thrown together, but an organized format that has had some thought put into it. To be useful, this wiki would have to be fairly extensive.

One other crazy thought I had about this is if the wiki was organized via tags a la del.icio.us rather than (or in addition to) a hierarchy. I’d bet that would be especially handy for folks implementing portability layers. E.g., you could search on the combination of “window” and “creation” tags to see FFI definitions for window creation functions in the various UI libraries.

Graphic-Forms 0.2.0 released

2006-03-21T17:59:00.000-07:00

The first release of Graphic-Forms (version 0.2.0), a CL library for Windows GUI programming, is now available. This is definitely pre-alpha code, so be prepared for missing features, bugs, and API changes in subsequent releases.

Download a release tarball from here:
http://prdownloads.sourceforge.net/graphic-forms/graphic-forms-0.2.0.tar.gz?download

Please consult README.txt for specific details about this release.

The main project website is:
http://common-lisp.net/project/graphic-forms/

Screenshots

2006-03-19T23:47:00.000-07:00

In preparation for releasing version 0.2.0 of Graphic-Forms, I’ve uploaded screenshots:

http://sourceforge.net/project/screenshots.php?group_id=163034

A couple more items

2006-03-18T15:14:00.000-07:00

Following up on the prior entry, here are a couple more motivations for library implementers:
printing
menu accelerator key tables

Motivation for GUI Library development

2006-03-18T11:23:00.000-07:00

One of the jobs of a GUI library is to enhance programmer productivity. Any such library having pretensions of being useful for real-world applications necessarily has to provide abstractions over system-level APIs. The system provides building blocks that the library organizes.

With that in mind, I think a GUI library for the MS Windows environment (Win32) has to tackle issues including but not limited to:

graphics:

bitmap transparency

manipulation of non-native image formats

scrolling

facilitation of multi-threaded applications

providing mechanisms for worker threads to safely communicate with event threads

construction and inspection of complex structures (e.g., child window hierarchies, menus, and table and tree controls)

structure definition

efficient modification (especially minimizing redrawing/flashing)

tab traversal in non-dialog windows

layout management

internationalization

resource externalization (e.g., strings and data formatting)

layout management comes into play here as well

smoothing over inconsistencies, bugs, or misfeatures

in particular, exposing functionality in a way that makes for the target programming language

Obviously, all of the above can be accomplished by writing directly to the Win32 APIs (since that is how such a library is implemented). But the above features are not directly enabled by Win32, so the application programmer without any GUI library has to implement them or go without.

I would claim that if you’re serious about GUI development, then the above is a subset of the functionality with which you need to be concerned.

UI Layout Management, redux

2006-02-21T22:55:00.000-07:00

I got a little ahead of myself with the previous entry. Having gotten my first (simple) layout manager working the traditional way, at this point, I think that geometry management in a UI toolkit might be too narrow an application for a generalized constraint solving framework. One of the ideas I might salvage from that last entry is the notion of providing an extended set of layout management primitives with a abstraction over it. That might happen after I’ve done some refactoring. As it stands now, I’ve got a workable interface between layout managers, the containers that rely on layout, and widgets organized via the layouts.

UI Layout Management

2006-02-14T20:41:00.000-07:00

I’m planning a series of blog entries that discuss the design and implementation of Graphic-Forms layout managers via a constraint-solving engine. In a nutshell, GUI layout management is an abstraction for UI composition whose purpose is to handle the messy details of organizing screen display based on attributes of UI elements plus policies selected by the application programmer. On top of the library usability aspect, layout management is a key enabler for I18n. It seems to me that constraint solving is a powerful but also natural foundation on which to build a layout engine. Check out this tutorial for some background reading on geometric constraint solving.

While I am not claiming that this combination is a novel idea, I do feel confident that it makes sense, given the kind of job that a layout manager needs to accomplish. And as an algorithmic solution, it leverages one of the fundamental strengths of Lisp-based languages.

It’s important to keep the target audience in mind when designing features. The core layout manager can be built with as much generality as desired, such that it understands a broad range of possible layout strategies, and that is definitely a goal. But for usability’s sake, Graphic-Forms should provide pre-defined layout schemes that are each focused on a particular behavior that the developer needs to accomplish. So while the underlying engine may provide enough flexibility to define arbitrary layout schemes, the canned schemes are built on top of the general mechanism and these are what the average developer deals with. But there is an added benefit – advanced developers can use the same mechanism to extend the toolkit’s layout functionality without needing to reinvent the core primitives.

One other preliminary comment: this is an area of the toolkit that is sensitive to performance issues, because

real-world application windows and dialogs are often stuffed to the gills with components (usability be damned)

the end user will definitely notice repainting performance problems

In an ideal world, the creation/resizing/reorganization of windows and dialogs is near instantaneous as far as the end user can perceive. The reality of course is that overhead is an inescapable factor. Everyone has seen at least one GUI application which exhibited jerkiness or obnoxious flashing in painting as windows are moved and resized. Visual artifacts like that leave a bad impression. Therefore, one of Graphic-Forms’ goals is to strike a balance between power/generality in implementation vs. snappy responsiveness on the screen. I anticipate having to make some hard choices.

For next time, I’m planning an overview of design issues and maybe some discussion of layout manager features available in other UI libraries.

Graphic-Forms, a new UI toolkit

2006-02-05T19:29:00.000-07:00

I’ve been making progress on a Windows-only toolkit for CL, called Graphic-Forms, which I had intended to use for my own projects. But this weekend, I decide to take the plunge and get a project set up at common-lisp.net (still waiting on the reply to my project creation request, though). I hope this code ends up being useful for other people besides me.

2005-12-08T18:24:00.000-07:00

Use Lisp because it's a good language, not because people say it is.

comp.lang.lisp can be a great resource if one needs help (and has made an honest up-front effort); replies are usually detailed and extensive. That newsgroup can also be a huge distraction. There is a temptation to read too much into the opinions of the regulars there. There is also a temptation to feel validated using Lisp because therefore one no longer feels like target of mostly unstated but sometimes explicit derision; that's a poor rationale for any decision, including choice of programming language.

I felt disappointed by the recent decision by the reddit guys, because I have become a Lisp enthusiast and it was cool to see somebody doing brand new things with Lisp. But that's as far as it went for me; I didn't feel the need to try to prove them wrong, unlike many on c.l.l. Desire to show somebody up is also a poor rationale for making a decision.

Personally, it would be easier to fall back to Java because my comfort level is so high. But I keep working with Lisp because I want to learn new things, and yes, maybe reinvent some wheels along the way. Lisp is great for what I want to do, and to heck with what anyone else thinks.

2005-12-06T22:54:00.000-07:00

First post! OK, with that out of the way...

I decided this past summer to explore Common Lisp as the vehicle for my non-work-related programming. I bought and read a copy of "Practical Common Lisp" by Peter Seibel, discovered websites like common-lisp.net and planet.lisp.org, downloaded and started reading "On Lisp" by Paul Graham, and even posted a silly beginner's exercise to comp.lang.lisp. Since then, I have contributed to a couple Lisp-related projects. Most recently, I've embarked on an effort to implement a UI toolkit directly on top of the Win32 API.

Writing about this stuff will be, if nothing else, a way to step back and think.