Comments on: Squashed and Compiled

By: rainman

rainman — Sun, 03 Jun 2007 04:44:09 +0000

Hi,
can any one tell me how can i modify AST in Elsa and print the modified AST as pretty print?

i have been trying to use Elsa, for a project in which i have to modify some statements which uses global variables and pretty print/regenerate the source code.

But Elsa prints always from the main source even i change the AST at runtime.
Authors email is bouncing from the main site.

Thanks.

By: Yoric

Yoric — Tue, 30 Jan 2007 13:06:20 +0000

Quick comment about the ML rant: I would *love* to be able to write actual code for the Mozilla platform in OCaml or Haskell. I don’t mean XPCom-related stuff, for which I consider Python and JS2 will be more appropriate.

What I do mean is the actual implementation of JS or my upcoming project related to static analysis of JS code. Do you think there’s any chace this might happen in any discernable future ?

By: Anders

Anders — Fri, 05 Jan 2007 17:50:28 +0000

I’m sorry, I did not mean to imply a criticism of Taras work. My skepticisms was solely based on my ignorance of the Mozilla code base. And I was curious as to what had changed since, some bright people, I assume, have chosen to use xpcom. But it sound as if, the clarity of hindsight have revealed unnecessary use in a specific module.

I didn’t suggest that the wrappers would be created by hand. I just wondered if it was feasible to extend Taras work to the entire code base for added speed, less bugs and less verbose code while wrappers could maintain backwards compatibility with the outside world. I assumed, while speaking of things I have no knowledge, that the wrappers could be generated from the idl.

By: Brendan Eich

Brendan Eich — Fri, 05 Jan 2007 05:06:24 +0000

In the interest of not reinventing wheels and maximizing leverage, could GNU indent do a decent job cleaning up patched files, even with the pretty-printer’s flaws? From what I hear there will be p-p fixes for Oink, but perhaps we don’t need to reinvent indent? It has lots of options.

/be

By: Brendan Eich

Brendan Eich — Fri, 05 Jan 2007 04:54:08 +0000

Anders, XPCOM’s best use-case is for APIs exposed by dynamically linked libraries that evolve independently. Its overhead is negligable given low relative inter-DLL call counts.

In Gecko, XPCOM or a primordial form of it was overused inside Gecko, where there are (or should be) no DLL boundaries, for private APIs that are not usable by other, independently evolving code. The overhead here in code space and runtime is significant (we will quantify it as we go), and deCOMtamination consists of getting rid of this bogus COM-like glue.

Sure, it’s possible to implement code using canonical C++ forms and synthesize APIs “on the outside” — that’s an explicit goal of Mozilla 2 (see my blog). But we don’t want to do it by hand, since we have some suitable public APIs already, and too many unsuitable private COMtaminated ones, plus hundreds of thousands of lines of internal code that calls the latter private APIs.

Hence Taras’s fine work based on the Oink framework.

(Taras, are you filing Elsa bugs as you go? Let me know.)

/be

By: Anders

Anders — Thu, 04 Jan 2007 12:26:15 +0000

In the presentation, you posted in your “Static Analysis” post on Dec 5th, there are a lot of reasons why you would want to *not* use xpcom. But I would guess that there also are some reasons why you *would* want to use xpcom. I guess you would use xpcom if you expected the runtime to be changed from out under you and wanted your app to continue running with no recompilation. Now it apparently have been decided that at least in some cases this separation isn’t needed. But are there some sort of published policy or list of objects that should or should not use xpcom?

Wouldn’t it be possible to implement all classes using C++ features (ie. with exceptions, namespaces and without xpcom refcounting, but perhaps with GC) and just have some auto generated wrappers that would add the backwards compatible xpcom facade (eg. by inheriting from both the xpcom interface and the implementation, catching the exceptions and return error codes instead). That way you wouldn’t need to deCom and all usages in one monolithic patch, but the object could be deComed first and the implementations later as needed. Also in this way every class could be deComed leaving no risk of overdeComification.

But since I don’t quite know the justification or use case for xpcom in mozilla, I find this decomification quite scary.