And besides that, it will only work on those frameworks that provide such functions.

I rewrote the object framework, only to discover than I have made it not generic enough for host objects. So in short I screwed it. *Again!* It seems that I will need to use O’Caml objects after all.

At least I was able to implement the basic Object and Function objects (with their prototypes and constructors), so I will maybe be able to implement function calls and object constructors with the current framework.

Everything else seems to be working, with caveats, for instance I convert exception’s objects to javascript strings, as I have not yet implemented these objects (but they are correctly throw / propagated / catched).

In the mean time, I managed to discover two bugs in SpiderMonkey. Brendan Eich being the incredible hacker he is, has already fixed one of them, and the other one seems to be in the pipeline.

I also discovered three bugs in the grammar published in mozilla’s site. I have yet to email Waldemar about them.

I think that I will take a rest for a few days to work on some Panoramio features. And maybe even take a rest to do nothing… you know, to rest

Cheers,

And happy holidays to you, too!

You are slightly overestimating gzip’s abilities, but otherwise I mostly agree. Again, a compressor / pretty printer is the only thing I could do with a javascript parser, and I need it anyway for other things. It also yields a 2x compression, which is not entirely irrelevant.

But, if we forget about the compressor, I hope we will agree the linker / memory leak detector / “issue warnings on compatibily problems” projects are worth it. All them need a previous javascript parser.

You said that stripped versions of libraries can be done offline. That’s the whole point (I don’t want to do it online), but to do it *correctly* you need a javascript engine.

You can do some quick hack in ruby, perl (or caml, btw) that will work most of the time, in the same sense than you can use some regular expressions to do a quick compressor. It will not however cover all cases, and as today toolkits keep growing, your chances of hitting a bug trying to prune dead code in each toolkit will grow.

For things like a leak memory detector, there is no way around doing a full javascript engine. A quick & dirty perl script will not cut it. And I don’t know about you, but I’m using a personalized version of Google Maps code due to all the leaks of the original version. Maybe they have improved in .28 / .29, but anyway if Google is having problems attacking this problem with tradicional tools, then it means everybody has a problem. (And unfortunately is not as easy as just disconnecting all your event handlers on unload.)

Johan, the ecmascript conformance bug in google maps is that they do a (I think it is two, in fact) function declarations inside an if block, something as:

if (foo) { function bar() { return “hi” } alert(bar()) }

Function declarations are only legal in toplevel and directly in the block of another function declaraction, so this is illegal. As everybody else is handling this case, I also added it to my parser. (Btw, I already pointed out this problem to Google Maps guys.)

Oh, and I may even follow Pablete’s advice and take some rest

Happy holidays guys!

I would have lots of use for a tool to do just custom formatting of code (and am a bit too lazy to hack any of the C parsers on offer today). An Ocaml first encounter for that would probably be lots of fun; it seems a very nice language to do really efficient code (my experience with the language mostly consists of the perspective given by Doug’s Great Computer Language Shootout, where the Ocaml implementations on several benchmarks beat most other languages with a margin, including Pike, which is home environments to me).

You peaked my curiosity about the ecmascript conformance bug you found; any more detailry available on that topic?

\2. also sounds an amazingly useful prospect. I hope you’ll post some notice about it, should you ever want co-developers on either of these “spin-off” projects.

By the way, your idea to make stripped versions of libraries you use for different cases (when you need only few functions) can be done offline just once, for particular cases, by some other simple languajes like ruby or perl. It’s very good idea actually.

Cheers,

As you can see, we are using mod_deflate (or mod_gunzip, I don’t remember) right now.
I see that you have seen now my reply to your previous comment, so that kind of replies your question about the goal of this work.

I have several goals, and each stage brings a little tool useful by itself. I did not want to attack the big problem of doing a javascript linker or a javascript leak detector first, because they are quite daunting, and I want to have something to show if my motivation fails.

These are the tools I’m thinking of:

\1. With a parser, I can compress a bit the output, until now in a fully recoverable way. The new renaming is not fully recoverable, and thus it will be optional. Actually, even the “compress spaces” will be optional, leaving the choice of pretty printer / compressor in the user. (In the future I will myself use it to compress spaces, let newlines in place, don’t rename.)

Given that I have not even compressed Panoramio’s code (except by using mod_deflate), even when my tool can parse and rewrite correctly both, Panoramio’s code and Google Maps’ code, it should be pretty clear that I’m not trying to obfuscate anything. (But as I said, when I finish the pretty printer I will remove extra spaces.)

Btw, I have discovered an ecmascript conformance bug in Google Maps that every browser parses and execute as Google Maps’ author expected.

\2. With a javascript engine, I can do extra tests in the code. For instance, I would love if it could say me “hey, here you are using foo, and that’s not supported in IE5. Do bar to make it compatible.”. Unfortunately I will have to clone the host objects to have useful warnings, and that will take a bit of time.

It’s also mandatory for a leak detector, but again, I will need to mirror host objects. The only tool to help diagnose leaks that I am aware of is Joel’s one, and it crashed when I tried to use it in Panoramio.

\3. Third tool will probably be the linker. I think the community has really a problem here. I’m always copying little functions like prototype’s $ to not impose the burden of prototype on light pages. Or cutting debug code, that may statically be proven as unreachable. But as you say, it’s not gonna be easy.

It is also an enjoyable learning experience. Last time I coded in O’Caml was years ago, and I’m rediscovering the language with this project. And even when I thought I mastered quite well javascript, I now have a much deeper understanding of it.

I hope this clears the “what are you trying to do here” question.

Cheers,

That said, I still find your work on a javascript linker theoretically interesting, even if it would need to be very advanced to do true dependency analysis on code putting the dynamic capabilities of ecmascript to good use. I believe most frameworks today are rather naïvely coded, though, by people who write code in the “smallest common denominator” (between PHP and javascript, for instance) fashion, so it might be of some use.

If you ever plan on releasing it, I hope any variable, property, object and function renaming will be optional.