Technobabble

“Dancing Dude at Skyfire” – Hello World

5 Comments

Original video and YouTube

Yeah, that’s me. You’d think I’d burned through my fifteen minutes of fame already…

Yes, I wore the Mozilla shirt deliberately. My role at Skyfire is to basically customize Mozilla Firefox for our needs. So it seemed fitting to combine the shirt and the little Skyfire badge.

As for the dancing itself… I think I can hold my own. 🙂 I’ll say this much – at that level, it is a workout in addition to a whole lot of fun. I don’t care about being alone out there either. I basically make it up on the spot (or I used to, anyway…)

Verbosio

Replacing JSLib in Verbosio

1 Comment

I came to an unpleasant decision last week. While working on reorganizing Verbosio’s source code, I realized that JSLib should not survive the transition.

I didn’t really like this very much. JSLib has been useful to me in the past. But when I thought about it, the only thing I used JSLib for was its file I/O utilities. These utilities should be used from chrome (and I abused that in my file search components).

Plus, I’m a much more experienced developer than when I first started with Abacus over four years ago. The Mozilla code base has similarly improved, and I just felt I could do the same job I was asking JSLib to do, with less (and cleaner) code.

I’m not saying JSLib is a bad library or a bad idea – far from it. I’m saying what I needed from JSLib is too small to justify having it around. Libraries for Mozilla are a popular idea – FUEL, STEEL, and JavaScript modules (.jsm) come to mind.

Besides, if you’re going to replace a library with one of your own, you should add value (not just cut costs).

I decided to write a library that, in theory, would be able to read and write to flat files, zip archives… and zip archives within zip archives. Think JAR files inside a XPI. Then, to make sure that I did it right, I decided to write a xpcshell test case for the module. (Yes, you can do that. The test harness doesn’t care whether you’re testing components or a .jsm file.) After a couple of days, I came up with FileCommon.jsm and test_FileCommon.js.

(The key is in FileCommon.getFile(), near the end. It takes multiple arguments, beginning with the path to a zip archive in the operating system, then an entry inside the zip (which is also a zip), then an entry inside the second zip archive, and so on.)

I’m sure there are bugs in this implementation. Right now no code in Verbosio uses it yet, and as I work on replacing JSLib with FileCommon.jsm, I’ll continue to add to the module. Eventually, I may make it a standard components module with new interfaces. Like so much else in Verbosio, it’s right now a proof-of-concept.

With JSLib, the time has come to move on. XUL Widgets will also fade, as I absorb its efforts into the Verbosio project directly. XUL Widgets (and Verbosio) doesn’t have any other customers, anyway, so centralizing under one roof makes sense.

Thanks for getting me started, Pete.

Uncategorized

Gecko 1.9.1, TraceMonkey and Venkman?

10 Comments

I admit, I’m pretty blown away by the TraceMonkey announcement. I’m envious. I’m still trying to get my company onto Mozilla Firefox 3 code…

That said, one of the biggest questions with JIT compilation of JavaScript that I’ve had for months is, “How are we going to debug JavaScript now?”.

It probably doesn’t help that Venkman didn’t make it into hg.mozilla.org. I think that was intentional, and I don’t dispute it. Still, with Gijs Kruitbosch on vacation, there’s not a lot of people to maintain Venkman (we’ve been down this road before).

Perhaps the right answer with TraceMonkey is to let Venkman die.

Note that I don’t suggest this lightly. Venkman nearly died once with 1.9, and has been on life support for years anyway. With Mozilla 2 breaking backwards compatibility in interfaces – and Venkman left in the dust, not even having automated tests for it (any tests at all?) – by the time we get around to bringing it up to 1.9.1, we may find it simply cannot work with TraceMonkey.

So I’d like to start a general discussion on what sort of JavaScript debugging tools we can craft for Mozilla 2.0. I really, really do care about this – without a good JS debugger, I may be dead in the water for a lot of what I do. (If I’m forced to use and learn DTrace for debugging JavaScript, I’d really like to apply it to a XUL app that can do the work for me.)

Comments are open. Please serious commentary only, not “I want this feature!”. I’m trying to find (and join, and participate in!) a group of people who can spend the time on researching & implementing a solution.

Verbosio

Regular expressions: Editing in a grid

1 Comment

This is for you, glazou, and your Diavolo editor. (Though I wrote it for Verbosio as well – I need it too.)

As I started my vacation, I was thinking, “I’d like to edit regular expressions in Mozilla. But I don’t want to edit one at a time. I want to edit a bunch, and see what they all do to a bunch of text.”

So in four late-night hours, I put together a simple XBL binding to help me do just that:

Each keystroke updates the table. When a regular expression is not well-formed, it disappears (and the results fields under it). When text and regular expression don’t match, the cell they share goes blank. The rest of the UI is, I hope, fairly self-explanatory for anyone familiar with JS regexps.

Yes, I know it’s not localized, and it’s not pretty. It’s functional, though, and for proof-of-concept code, that’s all I care about.

You may also notice this is on the new hg.mozdev.org repository. I’m in the process of converting over from CVS to Mercurial, and doing some other clean-up as well.

Technobabble

Cool tip of the day: Where in the DOM is your mouse?

1 Comment

What, elementFromPoint isn’t good enough for you? Well, in my case, no. For Verbosio, it would help a great deal to convert a mouse point to a DOM range point (think scripted selections, drag & drop like Pencil does, etc.). DOM ranges form, among other things, the basis for Mozilla’s selection algorithms.

Fortunately, there’s a way to figure it out. Just ask the mouse event for the range coordinates. Literally.

window.addEventListener("mousemove", {
handleEvent: function(aEvt) {
this.rangeParent = aEvt.rangeParent;
this.rangeOffset = aEvt.rangeOffset;
}
}, true);

This comes to us courtesy of the nsIDOMNSUIEvent interface.

The funny thing is, I knew about this back in 2002, when I was writing my book for Sams Publishing. I forgot about it sometime over the past six years (and I admit now that the book’s been only partially useful since then, missing certain bits of info I would’ve liked to know then).

Now, imagine using this to give a visual indicator where a given element you’re dragging will be dropped in a HTML or XML document…

Technobabble

Over Washington (west of the Cascades, anyway)

1 Comment

I’m planning a vacation in Washington State from August 14-24, back to Seattle and Vancouver. So if there are any Mozilla developers or fans in the Seattle or Portland, Oregon areas that want to meet up during that time, drop me a line in the comments section.

  • August 14-17: Seattle
  • August 17-20: Vancouver
  • August 21-23: Seattle
  • August 24: Back in San Jose
Technobabble

Hardware ups and downs, part 3: Setting up your build on Windows Vista 64-bit

Success! After my previous attempts, I have finally figured out how to build Mozilla Firefox 3.0 on my Windows Vista 64-bit operating system. It involves doing a couple things you may not have thought of.

As for the RAM disk part, I haven’t attempted that yet. Read on in the extended entry for details.

Continue reading Hardware ups and downs, part 3: Setting up your build on Windows Vista 64-bit →

Alex Vincent’s ramblings about Mozilla technology, authoring, and whatever he feels like.