Older blog entries for apply (starting at number 1)

Why Diaries Suck

Diaries are for the poster. You can post whatever you'd like, and they are nice for informal conversation. They also allow you to keep track of and organize thoughts for later.

However, these have got to be one of the most unfriendly formats for finding relevant information that I have come across in some time. Entries are not titled, indexed in any way, rated, or anything. It is just 2234509850907834 random posts to read through in a big pile. For now, Advogato is small, so the pile is almost of a managable size for those with too much spare time on their hands to sift through it all looking for the good stuff. But that trend won't continue for much longer. Besides, even now it is too much for the casual user to go read through all the diary entries looking for something good. In fact, I'd be suprised if more than a handful of people read this entry. Searching, indexing, and bidirectional annotations are desperately needed here.

It appears that certification entries could use short annotations when they are made. That way we can find out why ESR is a Dimwit, for instance, or why others like him. Then again, perhaps it will be meaningless information, as everyone will just lie or skip the annotations part anyway.

apply(Master) ;; Best sex I ever had.

Also, I'd like to respond to some things in the byte-order thread, but 1) I am apparently not qualified to, and 2) There doesn't appear to be any way to respond to other comments, so they seem disconnected. Anyway:

nether writes about an amazing type interface that handles everything and is powerful. Well, everything except functions and objects. It also doesn't appear that it will handle dynamic structures or symbols, but that's hard to say without an implementation. It's not that hard to make up yet another set of names for unsigned ints, the hard part is handling functions, objects, and dynamic structures. If you've designed an amazing type system without these things, you probably need a redesign.

Several people suggested using text files. Text is good for smallish things, but 1) It inflates most data types, 2) It's difficult to write real numbers precisely, and 3) It's slower to read and write if you have huge amounts of data (Conversion to strings is even slower than byte swapping and unpadding data).

My recommendation: Use whatever formats are already standardized, if you can. CORBA is big and clunky, XML is text and is big and clunky, etc. However, portability is more important in the long run than nearly all efficiency concerns. Also, my experience has been that if you start to implement a cool new type system, you will end up with all this cruft anyway.

As an aside, it might be useful to have a byte or wyrd or whatnot that describes the format of a binary file, particularly temporary ones. That way you can implement simple ones as:

memmap(file, somewhere);
if (NATIVE_FORMAT != fileformat) {
  maybe_swap_bytes(somewhere, scratch); 
  maybe_unpad(somewhere, scratch);
}
if (swizzling_needed_p(somewhere) {
  swizzle_pointers(somewhere);
}

Since most of the time you will be running the program locally, the formatting changes will fall through anyway. It's not clear where to stick this information though.. It should be out of band so you don't have to copy all your memory to make room for it before you blast a file out to disk or across a network. Also, not every object needs one, just one per file or group of files. NATIVE_FORMAT can be used for network connections.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!