Older blog entries for follower (starting at number 8)

djcb asked:

lamento eroico. What the hell does 'lamento eroico' mean, btw?

Assuming this wasn't a rhetorical question, it appears to be Italian and the literal translation of the words is 'I complain' and 'heroic'.

Now, I know no Italian myself, but my completely uneducated guess would be "hero's lament" or something? Anyone who actually *knows* Italian care to advise?

What was the context?

As they say, "un poco babelfish è una cosa pericolosa". :-/

raph asked:

why the hell did Apple put a SODIMM socket in the iMac?

Don't quote me on it, but I *think* it's because it actually shares the same motherboard as the iBook.

Ilan says:

"It's amazing how PalmOS is close to 5 years old, yet in many ways the design of its user interface [...] is far more ahead of its time and more well thought-out than much of the crud that came out in the last year."

I don't think those who lived in the world of the Mac from 1989 to sometime in the late nineties will find this amazing at all. I certainly don't.

I have a theory about this which I think applies here:

A good UI is first designed in black and white.

This avoids the problem UIs designed in the post-black&white age suffer from, which is that colour is used gratiuously and not to enhance the interface. In black and white every pixel is significant.

Of course, this isn't to say that you can't still design a *bad* UI in black & white. :-)

It's amazing how much time a mere three or so lines of code can absorb...

When I was working on my nsIProcess patch for jslib I couldn't immediately see how to get return ('out') values from XPCOM interactions via JavaScript since JS does not support call by reference. The process id (PID) of the newly spawned process is supposed to be returned in this manner.

Yesterday I discovered the XPConnect FAQ and specifically section 3 "How do I use interface methods with 'out' parameters from JavaScript?". It helpfully told me I needed to:

1. create a new object,
2. supply the object as the required 'out' argument
3. then, after the call, retrieve the return value from the object via a newly created property named 'value'.

(If the parameter is 'inout' you supply an object with the 'value' property already set.)

I immediately tried implementing this for getting the PID back from the newly spawned process and... it didn't work. :-/ It appears most of the "extra" functionality of the nsIProcess interface isn't actually implemented.

I also couldn't discover much more information on its implementation status in the few web references to nsIProcess I could find. (Oddly enough my reference to nsIProcess from a couple of days ago appears as result #9 in Google's search results--which gives some indication of the amount of documentation on the interface!)

I got thinking about what it would take to implement the functionality and after much digging through source code macro indirection I found what appears to be the underlying process identifier structure '_MDProcess'. While this structure contains some sort of process id under Unix & Windows (well a handle at least) it doesn't for all operating systems.

The nsIProcess interface isn't consistently implemented for both Windows/Unix and Mac anyway so I guess it wouldn't matter if PID functionality wasn't initially implemented for both either.

After all that I submitted a Mozilla bug about the unimplemented state of nsIProcess so we'll see what happens. In some far off world I might even do something about it...

Interestingly I also tried out the kill() functionality but that didn't seem to work under Linux either, despite the fact it *does* appear to be implemented.

Final comment

Cross-referenced web-based source code repositories like lxr are very useful.

Submitted a patch to the jslib maintainers to make my workaround from yesterday unnecessary. It uses nsIProcess to provide the spawn functionality.

Update: Cool, the patch got accepted.

Got positive feedback from my first "I-wouldn't-know-them-from-a-bar-of-soap" (i.e. non-acquaintance) user today. My known user base now stands at 3, yay! :-) (Oh, and it appears NoteTaker! works fine with Windows '98 and Mozilla 1.0 Release Candidate 2.)

I also did some investigation into how to spawn/execute an external program from within Mozilla in response to a question my newest user asked.

[I should point out here that if you're developing any sort of extension to Mozilla using XUL & Javascript you should definitely head to http://jslib.mozdev.org/ and grab their JSlib library. It provides JavaScript wrappers around Mozilla's XPCOM technology to make it nicer for using with JS.]

Unfortunately, while there is code in JSlib that is supposed to allow you to spawn a new process it doesn't appear to currently work due to a change in the nsIFile interface. Turns out you need to use nsIProcess instead, which I did and put together an example which can be found linked from:

http://code.rancidbacon.com/mozilla.html

This is just to give some publicity to my Mozilla contextual menu extension that makes it easy to take notes while you're traversing the web:

"With NoteTaker! you simply select the text you want to keep, choose 'Take Note' from the context menu and your useful snippets are stored for posterity--complete with source URL and date stamp."

Visit the homepage of NoteTaker!

In addition to my successful testing with Linux I have had a report from one happy user who runs it on Windows '95.

Why not?

Well, I joined to add a comment to the disussion about HTML templates (http://advogato.org/article/350.html) but apparently I can't so I'll just make it here:

Re: Use of < and > in the language is problematic

I agree, and in fact I've semi-designed and semi- implemented (but never released) a couple of template processing systems (first in Perl, then C, with a side trip in VBA...) which specifically didn't use < and > because I wanted to be able to use (and see) the new tags in WYSIWIG editors.

Although it would be possible to use, say, { and } or [ and ], one problem with that approach is they are more likely to be used in content and thus you run into problems when parsing the templates correctly (if you take a multi- pass approach anyway).

My tag delimiters of choice are {! and !} which seem to tend not to occur naturally...

Of course the disadvantage to this approach (i.e. multi- character delimiters) is it can complicate the coding, but still I think that's a small price to pay...