Copia

Sanjay Velamparambil's message

The best part of building 4Suite has always been the community. That goes way back to when Mike Olson and I were chuffed to hear from folks who'd stumbled across our inchoate DOM implementation (about 6 generations of the code ago), or our initial stabs at XPath and XSLT (about 4 generations in that case). Now the 4Suite community is a loud, thriving bazaar (100 messages to the user's list in a slow month), with all timbres of voices and all sorts of agendas. it's always pleasing to me as a developer to hear a voice ring out from the noise clearly appreciating the value of the work we've done. Thanks, Sanjay, for a very nice note.

[Uche Ogbuji]

As I've mentioned I added friendlier mutation API to Amara. Deletion didn't come up in the original discussion, but I just got around to addressing that as well. Now checked in are enhancements that support the following use cases:

Use case 10:

Source doc: spameggs
Code: del doc.a.b
Result: doc mutated to eggs

Use case 11:

Source doc: spameggs
Code: del doc.a.b[0]
Result: doc mutated to eggs

Use case 12:

Source doc: spameggs
Code: del doc.a.b[1]
Result: doc mutated to spam

Use case 13:

Source doc: spameggs
Code: del doc.a.b[2]
Result: IndexError

Use case 14:

Source doc: spam
Code: del doc.a.b
Result: doc mutated to spam

Of course there are oddities to go with the new convenience. Check out the following:

>>> from amara import binderytools
>>> doc = binderytools.bind_string("spamspam")
>>> unicode(doc.a.b)
u'spam'
>>> doc.a.b
<amara.bindery.b object at 0x685b2c>
>>> del doc.a.b
>>> unicode(doc.a.b)
u'spam'
>>> #Eh?  Still there, are ye?
...
>>> doc.a.b
<amara.bindery.b object at 0x685b8c>

Perfectly consistent with what the users seem to be saying, I think, but I'll be amazed if this doesn't trip up the odd fellow.

[Uche Ogbuji]

So the title of my last entry was "Holy trésor retrouvé!". Well, that's how you find yet another bug in xmlrpc_metaweblog.py. My first clue something was amiss when I clicked the "Post Entry" button in BloGTK was that I didn't get the usual, annoying pop-up to tell me the entry had been posted. I looked at the console from which I'd launched BloGTK and I saw:

Traceback (most recent call last):   File "/usr/bin/BloGTK", line 664, in prepPost
    post.getPostInfo(self.url, self.user, self.passwd, self.system, blogID, catID, title, body, checkPublish, self.mainGlade, self.useUTF, extended, excerpt, keywords, trackbackURLS, breaks, commentsAllow, pingsAllow)
  File "/usr/lib/blogtk/post.py", line 90, in getPostInfo
    metaweblogPost(url, user, passwd, blogID, title, body, publish, mainGlade, excerpt, extended, keywords)
  File "/usr/lib/blogtk/post.py", line 167, in metaweblogPost
    confirmPost(post, mainGlade)
  File "/usr/lib/blogtk/post.py", line 184, in confirmPost
    postLabel = gtk.Label("Entry Posted. ID = " + post)
TypeError: cannot concatenate 'str' and 'bool' objects

Which usually means xmlrpc_metaweblog.py got confused and reported its confusion with an XML-RPC response of 1. I checked the Copia site and found that the result was an empty file for the entry. I didn't find any useful tracebacks server-side, and I'm out of steam for the night, so no further debugging. I just pasted the entry into vi over ssh and all was well again.

P.S. Same problem with this entry when I tried to post it. WTF? xmlrpc_metaweblog.py should be stateless, so the presumed non-ASCII in title bug shouldn't have affected further posting, should it?

[Uche Ogbuji]

Via SlashDot: "Decoded at last: the 'classical holy grail' that may rewrite the history of the world"

Living on the edges of the Classics world as I do, I've heard of the Oxyrhynchus, but I must say I'd never really appreciated its magnitude. Maybe people despaired of deciphering the papyri, and thus never raised their excitement about it. But this is really amazing news.

I do think that the "second Renaissance" bit is hyperbolic to the point of absurdity. The Dark Age Europeans might have needed the Irish-preserved classics for their own flowering, but we are well past that point. We'll learn a great deal if the corpus lives up to the promise, and I'll be as eager as any to learn from it, but let's not start talking rubbish in our excitement.

[Uche Ogbuji]

In the previous entry I discussed changes to Amara's mutation API. In the original discussion one of the things that came up was the old element/attribute conundrum. Take the following document:

y

Users like to be able to access both elements and attributes using friendly Python idiom, but here we have a name clash on the resulting a object.Right now Amara exposes the attribute as a.b and the element as a.b_, using name mangling to disambiguate.

The important thing to remember, however, is that such clashes are quite rare in practice, even when you throw in namespaces, so such mangling is rarely necessary, and I personally think Amara's current behavior makes sense. But I may just have a blind spot, so I've been paying attention to suggestions from others.

Jeremy Kloth suggested just always using different idioms. a.[u"b"] for the attribute and a.b for the element. This is not a bad idea, but I feel that given that clashes are rare, that it complicates the common case just to aid the rare case.

Luis Miguel Morillas had an idea I consider almost the opposite. Rather than completely separate element/attribute idioms, Luis suggests embracing how Amara has unified them. Right now Amara rolls up multiple elements of the same name in a convenient way:

yz

Works such that a.b or a.b[0] yields the element with y and a.b[1] yields the element with z. Luis thinks that the following case should just be an extension of this:

yz

And then a.b or a.b[0] would yields the attribute value (u"x"), a.b[1] would yield the element with y, and a.b[2] would yield the element with z. I kinda think of this idea as "so crazy it almost makes perfect sense", but it's way too big a change to introduce before Amara 1.0. I'd be curious to hear what others think of it. Luis actually brings it up in the context of mutation--see his original post (scroll to the bottom)--but I figure that the mutation API will follow naturally from the access API, so I'm focusing my thoughts a bit.

[Uche Ogbuji]

Tom Lazar asked for a friendlier idiom for mutating elements in Amara. I was reluctant at first because the simpler-on-the-surface idioms he wanted would require rather untidy idioms in the code. I relented to the argument that user convenience comes even before clean code. I finally got around to making and committing the changes today. I'd planned to release Amara 1.0b2 as soon as I'd made these changes, and the timing seems perfect since we've just released 4Suite 1.0b1, but the changes are intrusive enough that I think I'll give folks a chance to try things out from CVS and first see whether it craters for anyone. Please give it a go and give me feedback here or on the mailing list. Thanks.

Here are use cases illustrating the new idioms for Amara. I have added them to the test file mutation.py:

Use case 1:

Source doc: spam
Code: doc.a.b = u"eggs"
Result: doc mutated to eggs

Use case 2:

Source doc: spam
Code: doc.a.b[0] = u"eggs"
Result: doc mutated to eggs

Use case 3:

Source doc:
Code: doc.a.b = u"eggs"
Result: doc mutated to

Use case 4:

Source doc: spamspam
Code: doc.a.b = u"eggs"
Result: doc mutated to eggsspam

Use case 5:

Source doc: spamspam
Code: doc.a.b[0] = u"eggs"
Result: doc mutated to eggsspam

Use case 5:

Source doc: spamspam
Code: doc.a.b[1] = u"eggs"
Result: doc mutated to spameggs

Use case 6:

Source doc: spamspam
Code: doc.a.b[2] = u"eggs"
Result: IndexError

Use case 7:

Source doc: spam
Code: doc.a.b = u"eggs"
Result: doc mutated to spam

Note: attributes take precedence over same name elements in binding. See next use case.

Use case 8:

Source doc: spam
Code: doc.a.b_ = u"eggs"
Result: doc mutated to eggs

In a follow-up entry I'll talk about some other suggestions I've received on this matter.

[Uche Ogbuji]

Managing XML data: A look ahead

IBM developerWorks has done well to corral Elliotte Rusty Harold for a column, Managing XML data, on tools and techniques for working with large collections of XML documents. The first article prepares the overall topic, summarizing likely subtopics and examining some history.

It's as good an opening as any for me to plug my own developerWorks article "Manage XML collections with XAPI". XAPI is a simple but well-considered community spec for XML database collection API.

Elliotte is one of the best writers for explaining XML technologies, right up there with Jeni Tennison. I think developerWorks is a greatly overlooked source of great materials on XML and other technologies. Maybe I'm biased because I write a great deal for them, but they also feature a lot of other very good writers and I you'd do well to check the site regularly, especially the XML zone, run very diligently by John Swanson.

[Uche Ogbuji]

Update: How could I have forgotten --enable-unicode=ucs4 in the Python build instructions?

Just gathering up some details on how to install 4Suite as non-root (i.e. in a user's home directory). This is based on experience installing on Red Hat and Fedora Core, but should work for most POSIX environments.

If you don't have Python installed (or want your own copy):

Grab Python-2.3.x.tgz or Python-2.4.x.tgz and unpack:

tar zxvf ~/dl/Python-2.3.5.tgz
cd Python-2.3.5/
./configure --prefix=$HOME/lib --enable-unicode=ucs4

Pick whatever prefix works for you. --enable-unicode=ucs4 is essential IMO if you're doing XML processing.

make && make install
ln -s $HOME/lib/bin/python $HOME/bin

The last step is to put the Python exe you just built into your $PATH, presumably before any other Python exe in the system.

Now for 4Suite

Grab 4Suite 1.0b1

cd $DOWNLOADS
tar zxvf 4Suite-1.0b1.tar.gz
cd 4Suite-1.0b1
python setup.py config --prefix=$HOME/lib
python setup.py install

Notice the extra "setup.py config" step. This is the key to the whole thing. The "setup.py config" sets the location for all the files installed by 4Suite except for the Python library files, which are installed to the location determined by the Python executable used to invoke the setup script. For more on where 4Suite puts things, see Mike Brown's excellent document "4Suite Installation Locations".

There is also a --home option to setup.py config, but do not use this unless you really know what you're doing. Stick to --prefix.

Finally you may want to make a link for all the 4suite commands to your home's bin directory

ln -s $HOME/lib/bin/4* $HOME/bin

Now you can run the tests.

cd $HOME/lib/lib/4Suite

Remember that this is beta software, and some test failures are to be expected (heck, I'd be amazed if there weren't some test failures with the full 1.0 release).

[Uche Ogbuji]

Just like that, Hasina was the son of all man
Type blood. He a realer fighter, super fro.
Bust it. The beast may want a war in the summer;
Thus, I rock my camoflage playing corners
Represents kites, while they pimp hip hop
I strategize my joints; you know it don't shtop
And it don't pop son, its p-ject 'round together
For beats, and concrete, when I'm creamy with my stilleto
got 16, for the imperial fascist
Bomb beats brothers, and honeys we 'bouts to set it
Domino theory, 'cause they stalled our flow
Collecting pitchforks, till they free Geronimo
Why you blaze up. Right on. I say my fist raise up.
While you bent, I represent... what!...
Uptown, Downtown, across; wherever
Meet me at the Crooklyn, we can piece it all together.

--Butterfly of Digable Planets--"Dial 7 (Axioms of Creamy Spies)", Blowout Comb

Hasina is a Swahili name, meaning "good" but I never figured out just what Butterfly meant there. I do know that Butterfly must have built up quite the pitchfork collection before Johnnny Cochran finally sprang Geronimo Pratt from jail.

But anyway, sing it like that Ladybug and Sara Webb: "Heeeeeeeeeeeeeey. Heeeeeeeeeeeeeey." Lori informed me that not only have Digable Planets reunited, but they'll be in Boulder in June (Fox Theatre). I'm not sure how I missed the news that they're back and working on an album, but I'm amped on the prospect. I loved their frank use of classic Jazz samples on Reachin' and I loved their Black Panther Funk on Blowout Comb (including the sublime "For Corners" and the cool, playful "Borough Check"). Most importantly, I love Mecca/Ladybug and Ishmael/Butterfly's mega-hip, abstract metaphors and laid back flow. Many of their lines are timeless quotables for Lori and me. Just from Reachin':

"What is really what when the supreme court is, like, all in my uterus"

"They harassed me at the clinic and called me a murderer. Now that's hate."

"In the scheme of things time is unreal. We're just babies. We're just babies, man."

"Hanging out, relax, ain't nothing to fo. Checking out some Frome, some Sartre, Camus."

"As bosoms float by keeping Doodlebug in heat"

"Hit it like a Dig Planet, god dammit!"

and of course

"You down with Digable Planets, you's a hipster. Shit."

The Digable Planets were also one of my first concert experiences with Lori (can't remember whether we saw them before we saw Me'Shell Ndegeocello). We were walking to the venue, at Marquette University in Milwaukee, and another black guy happened to be walking with another white girl in front of us. Some students riding by in a bus yelled out the window. "Hey, you black guys better stop stealing all our dates". The girl in front of us, unfazed, said to her companion "you'd almost think we were back in Philly". I've never been able to figure out exactly what she meant. Anyway, the concert was the bomb, especially the explosion that occurred when Ladybug shushed the crowd so we'd get the full effect of the killer Art Blakey sample that forms the backbone of "Rebirth of Slick (Cool Like Dat)".

I guess we'll see if they still have that magic June 13th. "We groove like dat. We smooth like dat. We funk like that. We out."

[Uche Ogbuji]

Just saw an announcement for:

The Linux Enterprise Cluster by Karl Kopper

Nothing demonstrates our dependence on technology more than when a server goes down and office productivity comes to a screeching halt. Author Karl Kopper's real-world response to this scenario is outlined in "The Linux Enterprise Cluster" (No Starch Press, April '05). The book describes how he put several inexpensive computers on a network, installed free software and made the individual machines operate as one big server called a cluster, thus saving his company time, money and resources. "The Linux Enterprise Cluster" goes through every step needed from start to finish to build a cluster of Linux computers capable of supporting an entire enterprise reliably and cost-effectively.

Sounds very interesting, especially the focus on using software and hardware within the reach of most organizations.

[Uche Ogbuji]