tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (working)
[personal profile] tim

Months ago, my overlords and I decided that I was going to spend some time working on something besides Rust. That something ended up involving generators and IonMonkey. It might seem strange for me to work on a JavaScript engine, since I've barely written a line of JavaScript in my life. (Unless you count a job I used to have once where I wrote a little bit of ActionScript. It was better than you might think.) And it is; that's why I eventually decided not to continue working on this project.

(I wasn't familiar with generators before this. It turns out they're what you do when you want to write functions that operate over aggregate data without actually building up intermediate data structures -- such as when you're working in a language whose compiler doesn't do deforestation, such as almost all of them. Rather than relying on the compiler to do shortcut deforestation like you might do in Haskell, generators let you write producers and consumers without the pesky intermediate data structures in between. Or at least that's how I understand them.)

But, I did want to submit the code I'd written so far as a patch, and not just throw it away. What I accomplished so far is a very tiny change: previously, the compiler inferred what functions were generators by marking any function containing the yield keyword as a generator. Generators can effectively return multiple times, so a yield is like a return, except that if the callee calls the generator's next method, it'll resume executing up to the next yield. To comply with Harmony, the next JavaScript-standard-in-progress, generator functions will have to be syntactically distinguished, so that instead the compiler will reject yield outside of a function that was declared to be a generator. So my change requires generators to be declared with function* instead of function. Not a big deal, but since I wasn't familiar with IonMonkey at all (or JavaScript, or -- really -- C++...) it took me quite a while to get something working, and when I left off (a few months ago), a few tests still failed.

I didn't want to be a big jerk who just copied/pasted the patch I had so far into Bugzilla and left the cleanup for other people, so today I embarked upon the task of producing a patch against HEAD for IonMonkey, or at least a newer revision than March 2012. This involved remembering how to use Mercurial, resolving many merge conflicts (not surprisingly, code bit-rots when you don't pull from the repo for a few months), and finally, running make on something I knew was probably wrong (some of the existing generator code had changed out from under me -- for the better, but it still required updates) but where I hoped the compiler would tell me why. The first bit of fun I had was that the makefile wouldn't let me build with llvm-gcc, which was the only gcc installed on my Mac. I tried clang, which worked like a charm (and has way better error messages than gcc!) all the way up till linking, where I got mysterious errors about undefined symbols beginning with _cxa. So I investigated what it takes to build a non-LLVM gcc, and, well, that's still building on my other machine back in my office.

I'd hoped I could just devote a day to this and be done with it, but life isn't that easy. Hopefully, though, the non-LLVM gcc will work and I can sort out the rest by running tests.

Profile

tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
Tim Chevalier

November 2021

S M T W T F S
 123456
78 910111213
14151617181920
21222324252627
282930    

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags