this is why I hate XPCOM

[zwol]

  // This is how you open a file.  In the current working directory.
  //
  // THERE ARE 387.44 MILLION MILES OF PRINTED CIRCUITS IN WAFER THIN
  // LAYERS THAT FILL MY COMPLEX. IF THE WORD HATE WAS ENGRAVED ON EACH
  // NANOANGSTROM OF THOSE HUNDREDS OF MILLIONS OF MILES IT WOULD NOT
  // EQUAL ONE ONE-BILLIONTH OF THE HATE I FEEL AT THIS MICRO-INSTANT.

  const Cc = Components.classes;
  const Ci = Components.interfaces;

  const DS_CID = "@mozilla.org/file/directory_service;1";
  const cwd = Cc[DS_CID].getService(Ci.nsIDirectoryServiceProvider)
                        .getFile("CurWorkD",{}).path;

  const LF_CID = "@mozilla.org/file/local;1";
  var outputFile = Cc[LF_CID].createInstance(Ci.nsILocalFile);
  outputFile.initWithPath(cwd + '/bench-css.one');

  const FOSTREAM_CID = "@mozilla.org/network/file-output-stream;1";
  var ostream = Cc[FOSTREAM_CID].createInstance(Ci.nsIFileOutputStream);
  ostream.init(outputFile,
	       0x02|0x08|0x10, // PR_WRONLY|PR_CREATE_FILE|PR_APPEND
	       438,            // 0666; JS no longer supports octal
	       0);             // useless

  function output(s) {
    ostream.write(s, s.length);
  }

[EDIT: Yes, it's even worse than I thought.]

Comments

[echristo.livejournal.com]

Three letters: WTF

[zwol.livejournal.com]

I could have made it even nastier, too, just by not abbreviating anything (_import, Ci, Cc, and Services are all customary shorthands).

It's like the assembly language of JavaScript!

[superconductorz.livejournal.com]

At least it's better than COM?

Re: It's like the assembly language of JavaScript!

[zwol.livejournal.com]

... this is COM. Well, XPCOM, which as far as I can tell is COM with the serial numbers filed off and a whole bunch of additional wrongness bolted on.

Re: It's like the assembly language of JavaScript!

[superconductorz.livejournal.com]

At least you don't have to worry about reference counting?

Re: It's like the assembly language of JavaScript!

[zwol.livejournal.com]

True, but only because this is on the JavaScript side of the fence.

[elsmi.livejournal.com]

I would probably be more sympathetic if I hadn't spent the weekend fighting with Win32. (I swear this API was designed by Raymond $#@ing Smullyan. It has driven me to threads.)

But that's pretty obnoxiously obnoxious.

[zwol.livejournal.com]

What are you stuck doing with Win32? (And I confess, the connection between Raymond Smullyan and being driven to threads escapes me also.)

I think what I hate most about the code I quoted is not so much the excessive verbosity, or the magic numbers, or having to poke so many different objects, but in fact the complete lack of support for relative pathnames! I mean. Is this not a concept that has been well defined and (nigh-)universally accepted since nineteen fucking seventy, if not longer?

[elsmi.livejournal.com]

Getting the xpra client running on win32. So it's all about writing portable async talk-to-sockets-or-a-subprocess code. The reminder of Raymond Smullyan is that the pieces used to build this all have bizarre complicated constraints on how they can fit together, so there's this wacky logic puzzle to figure which combination will produce the least amount of horror. OTOH, he writes far more clearly than anything you'll find in MSDN.

This comment may give some idea. But even that code turned out to flaky for reasons I can't figure out, so I gave up and rewrote everything with blocking IO and threads. (But! The threads can't just use 'read' and 'write' to do blocking operations and stop caring whether they have a socket! Because, while the standard read/write API is allowed to be used on sockets, if your socket *can* handle simultaneous read/writes then the read/write APIs will error out if you try to use them in blocking mode. You can do blocking read/write, but you have to call recv/send to do it. Iff you have a socket.)

Thanks, I feel better now.

[zwol.livejournal.com]

Oh, yuck, Windows and sockets. You have my sympathy.

[elsmi.livejournal.com]

Oh, and on relative pathnames, is it 'relative to another given path', or 'relative to the cwd' that bugs you? Because I'm not really a fan of cwd (useful for shell tools, but in general, process-global state implicitly passed to every path-handling syscall = ugh).


...Okay, but looking at that code, this DirectoryService nonsense is nonsense.

[zwol.livejournal.com]

'relative to the cwd' happens to be exactly what I want here, but I'd be happy to get 'relative to this file handle' a la openat(). The issue here is that the infrastructure doesn't believe in anything but absolute paths. (And yeah, the DirectoryServiceProvider thing is nonsense. It doesn't help that there is also the DirectoryService and the FileLocationProvider, which are not at all the same thing.)

Please tell me it's that easy

[mentallill.livejournal.com]

I don't think you've worked out, quite yet, how to do something as apparently simple as writing an entire string to a local file yet. Okay, so it's only a minor issue, but at least on my browser setup here, using non-ASCII strings doesn't just cause failure, it causes undocumented and extremely inconvenient weirdness. Because JS was developed back when 65536 characters would be enough for anybody, it uses 16-bit characters for .length. nsIOutputStream takes bytes. XPCOM does appear to mangle the string into an 8-bit form, but it appears to do so by arbitrarily collapsing characters into meaningless 8-bit bytes.

"日本国" becomes 0xe5 0x2c 0xfd.

Yes, yes, I know no one cares about i18n. It's just amazing to me that with all the complexity, it still doesn't freaking work, and fails to work silently, and also fails in a way that doesn't suggest any obvious fix (I found something called nsIUnicharOutputStream! that must do this .. somehow?).

Meanwhile, in the real world, UTF-8 has won. Everyone knows a char * means UTF-8 now, and if you'd written an "append a string to a local file" function in C, you'd have to positively want it to fail for UTF-8 to break it in that way.

Re: Please tell me it's that easy

[zwol.livejournal.com]

I only need to print ASCII, so I don't actually know if the problem you describe has ever gotten fixed. It's tempting to figure out the right way to do it in general just so I can edit the extra ugliness into the rant, though.

Re: Please tell me it's that easy

[mentallill.livejournal.com]

Something like this does the trick:

costream = Cc["@mozilla.org/intl/converter-outut-stream;1"].createInstance(Ci.nsIConverterOututStream);
costream.init(ostream, "UTF-8", 0, 0);

function output(s)
{
costream.writeString(s);
costream.flush(); // this flushes the converter stream, but does not necessarily flush the underlying output stream.
}

costream.flush is a totally different function from ostream.flush. It's probably a nop for UTF-8, but it does something, at least in theory, that no one has ever called "flushing". There's not even a method for flushing the underlying stream, that I can see.

Want to know how many bytes you've written? Oh, no, costream.writeString doesn't do that. costream.write doesn't do that either (but it takes its count as the first argument, and the data to be written as the second argument, because clearly doing things the same way as ostream.write would be boring).

Maybe there's an anti-ducktyping rationale? We'll give both classes functions called "flush" and "write", but make them totally different, just because we can?

I'd like to defend XPCOM. I can't really think of a good defense, though. Does "at least nsIUnicharInputStream.read mimics nsIInputStream.read " count?

If you're even in a position of thinking "oh, all I need is ASCII, so I won't bother handling UTF-8", something has gone very wrong in the internationalisation process.

Re: Please tell me it's that easy

[zwol.livejournal.com]

This isn't going into the browser, it's a benchmarking script that only I will ever use (most likely).

encompassing

[(Anonymous)]

[url=http://www.thecasino.co.il/ca/]casino[/url] , [url=http://www.casinoonlinebrazil.com/slots]blackjack online[/url] , [url=http://www.onlinecasinorussian.com/casino-reviews]slots[/url]. [url=http://www.ttittancasino.com/online-roulette.html]casino spiele[/url].