13:36: Having a dog

Arthur is at the top of the stairs, whinging to be let into the bedroom so that he can curl up under the bed where my wife is sleeping. "Arthur!", I say, "Stop that! Come down here!". But he doesn't stop--he continues.

I said it too firmly. I said it out of frustration. I said it dominantly.

The interesting thing about Arthur is that he's such an excellent manifest example of how the way to get what you want is to make others want to give it to you. Arthur has a lot of... anxiety. He's nervous around new people, and he's even nervous around familiar people when they walk into the house after a day of absense. And, when left unoccupied, he whines and barks in hope that someone will just open the door so that he can find a hiding-space. Arthur has almost certainly been abused at some point, and has developed a sort of hyper-timidity that some people develop in response to the same sort of thing: if he's approached confrontationally, he shrinks away; if he can't find someplace to hide, he'll do laps around the available area, sounding as if he's got a klaxon attached to him.

He doesn't retort, he does what I guess would be `curling up in a foetal position and crying' if he was human. But his response is exaggerated in ways that human responses would virtually never be: if you yell at him, he'll cower and pee on your floor.

So I try to draw him down from the stair-top again, saying virtually the same thing, but with a higher-pitched, more-inflected voice. These things mean `love' and `enthusiasm'. These things work.

Learning to interact effectively with Arthur has tremendous potential to teach about interaction with human beings.

[Reply]

13:18: srcinst enlightenment

Yes, srcinst. Wow. Rockin'. Awesome.

srcinst FTW!

Hunh--it's written in Haskell. And it looks pretty short-and-sweet. Maybe I can use srcinst to help me finally get around to learning Haskell.

[Reply]

12:19: apt-get install enlightenment

In order to build libframeworkd-phonegui-efl, I need a native copy of edje_cc. It looks like Debian's starting to bring the whole EFL suite in, but at least some parts (include edje) are still restrained to the experimental distribution. All of the binaries in experimental' are, of course, build against theexperimentalversions of their requisite libraries, which means that the binary packages are *dependent* on experimental library-packages..., which would seem to mean that I basically have to upgrade an arbitrarily-wide swath of my otherwise-perfectly-finelennybox toexperimental--pulling inexperimentalversions of glibc, GTK+, GLib, and maybe even a few *applications* that can run only with the same version of a library as the one with which it was built..., and then upgrading more libraries to satisfy those applications... recursively until it all works out... And maybe it'll continue to \work out' after that, or maybe it won't--maybe something will break at some point and require time-consuming manual intervention.

The thing is, stable (lenny) and experimental are, by definition, not a single cohesive mass--they're two independent universes, and aren't really (really aren't) guaranteed to match up at all with each other in the long run. In other words, there's a reason why experimental is called "experimental". All bets are off.

Well, apt-build to the rescue. apt-build helps us get a source-package from one distribution, rebuild it against our own distribution (thusly replacing the foreign happenstance-dependencies with native happenstance-dependencies), and install it without having to upgrade arbitrarily-wide swaths.

Because, when installing from source, all we need is source-level compatibility, which is a lot easier to get than binary-level compatibility. Open Source FTW.

Actually, since I need to build and install several layers (edje -> evas -> embryo -> ecore ...) of library-packages, maybe I should be looking at srcinst....

[Reply]

00:23: Learning Etk... and why I can't sleep

So, I want to add VisualIDs to my FreeRunner. I've actually already built the base code and run-tested it on-device, and verified that it'll be plenty fast enough even without going through a round of optimisations (even the prototype real-time editor GUI seems sufficiently snappy), so I'm on to actually adding a UI-feature to the existing applications--similarly to how the desktop goal was getting VisualIDs implemented in Nautilus.

I've been running mainly SHR, and it looks like the best path to take is to hack on their libframeworkd-phonegui-efl package, which provides Etk-based GUIs for openmoko-dialer3, openmoko-contacts3, etc.; the alternative seems to be hacking on Zhone, which is a self-acknowledged nightmare and... more on that later..., maybe.

After having spent a day or so (spread out over the past week following receipt of my new, at-least-mostly buzzfixed FreeRunner) wrapping my head around how contacts-listing elements in a a GLib GHashTable could possibly be picked-up by something that appeared to be a native Enlightenment routine, I spent the bulk of today figuring out how to get an image from an image-file into the EtkTree contacts-list--what exactly an Etk_Tree_Model was, what the `image' variant was, and how the latter affected the requirements for arguments passed to etk_tree_row_append(). I think that I've got a grasp on all of this, now (add an Etk_Tree_Model_Image to the tree as a column-model with etk_tree_col_model_add(), and then argument the column-object with the image-file path and also NULL when calling etk_tree_row_append()--because the API really wants a theme-file with a follow-up `key' argument that selects the specific named image in the theme, but it will also accept a `NORMAL' image-file along with a NULL key and figure out that it can create an Etk_Image directly from the image-file. I guess this should actually be obvious from the arguments to etk_image_new_from_file()....

Now that it's late enough that it's not even `today' anymore, I think I've got enough of a grip on things to actually write code and verify my understanding..., but it's most definitely time for bed.

I always have my doubts about my ability to, after waking from a good night's sleep, remember what the hell I was doing before I went to sleep....

[Reply]

02:47: Hello, PyBlosxom

I switched the weblogs from Blosxom to PyBlosxom, today.

Now I guess I can get started on integrating Bazaar--I just need to read-up on (and read through) the architecture a little more.

I spent a while trying to figure out how to get the effect of Blosxom's `ISP plugin', until I realised that, at least when running in CGI mode, I can just query the CGI environment-variables in config.py and set datadir, flavourdir, base_url, and even blog_title accordingly.

I don't know how to handle this in WSGI mode (since I haven't really learnt anything about WSGI yet), but it's not clear that CGI is expensive enough for me to care, at this point.

Aside from that, the only real issue with the conversion was that PyBlosxom groups entries made on the same date, and Blosxom doesn't; so, timestamps work differently--I had to move the VisualIDs for my entries out of the timestamp-column and into the `story' header, and we still need to update Pam's templates so that the time is similarly moved (from being attached to the date, to being attached to the story per se).

Oh--we also (finally) got a way of walking back through historical posts, beyond the `front-page limit' (num_entries), courtesy of PyBlosxom's wbgpager plugin.

[Reply]