Baroquebobcat

I took last week off, I was a little busy vacationing and all. I had a very nice time and enjoyed not having internet or cell service. But this last Sunday I was back at it, hacking away on Mirah.

Getting Started

I started by pulling latest, because there had been some changes since the last time I checked out Mirah. Immediately I went from having 2 test failures to having 200 some errors with the message NativeException: java.lang.ClassNotFoundException: mirah.impl.Map$Extension4.

This had something to do with the bootstrap jar being upgraded, but I wasn’t sure what.
I tried updating my local Java from 1.6.0_22 to 1.6.0_24, that didn’t work–but it changed the error to RuntimeError: Compilation error.

I also ran rake clean and rake clobber and poked around for other stale files. It was weird because if I checked out the jar from before the change everything worked again.

Finally, I tried making a fresh clone of the repo and that worked–which I found a little strange. My suspicion is that somewhere I missed some build files that were screwing things up on the path, but I’m really not sure.

Somewhere in there I also blew away my rvm JRuby install and reinstalled it. When I did that, I also chmoded .rvm/hooks/after_use_jruby so nailgun wouldn’t cause issues like it did before.

Actually doing stuff

I looked at pull request #95, and couldn’t reproduce the issue it solved, so I left a comment to that effect.

On StackOverflow, I answered a question about Mirah’s metaprogramming support. I think I should work up a page like that to put in the wiki, so there is a canonical place to look for macro and metaprogramming information.

test reorg continues
I finished teasing apart the bytecode and javac jvm tests. Now, they run the same suite but use different helpers instead of sharing through subclassing. This means we can start to break apart the big test_jvm_compiler.rb file(2876 lines!) into more focused test files, which I think will be a big win for helping new people find a place to put new tests.

The only problem with the current implementation is that the rake test task is dependent on the sub tasks instead of calling them inside itself. This is a problem because the task stops at the last suite to fail, instead of doing like Rails does and running them all and telling you error in test:units or whatever.

I continued poking at the main method thing I’ve been working on, and managed to completely hose the test suite–clearly I’m doing something wrong somewhere. So I think I’ll take another crack at it next weekend. I think I was trying too hard to decompose the compile helper methods, rather than getting it working and then decomposing it.

Scoping Thoughts

I read the scoping discussion about macro scoping and formed an opinion about it.

The discussion boils down to how to handle scoping within macros. For macros to be useful, you need to be able to refer to variables from the outer scope. The problem is that just dropping the code the macro generates into the outer scope can be problematic when the code the macro generates has its own variables. Hmm, that explanation wasn’t great–how ’bout an example:

Here, if we use the outer scope without making temporary variables for the variables in the macro, we’ll get as output 4, which is probably not what we expected.

My Scoped Opinion

My thought is that anything assigned/declared to in the quote block in a macro should be turned into a variable local to the macro–eg foo’s bar becomes bar_1, or something. But, unquoted elements within the quote should use the outer scoping and not create temporary variables, so that when the macro is put in place, the function baz looks like:

That gets you the ability to reference things outside the macro, letting you manipulate them within it, but does not bleed temporary variables from the macro into the outer scope. Now, how to implement that, I don’t really have a good idea. An exercise for the reader.

I think it was a pretty productive four hours. See you next week!

This time I tried to tackle the improperly generated main bug that’s been a problem with java source generation for a while. It took me a couple of hours to figure out where the relevant code was because I’m not as familiar with that part of the compiler.

The problem was that when the main method was generated for a file with the same name as a class in it, the source for the class’s source code would be generated before the main method’s body.

huh? Lets see some examples

Say we have a file test.mirah that looks like this:

When we run mirahc -j test.mirah, we get this Test.java out:

Notice anything funny? The main method isn’t finished. This is because when we generate the main method, we compile the whole script–which includes the class. The problem is that we finish generating the class’s source code before we get to Test.new.a, leaving the main we added to the class unfinished.

My hackish solution to this was to check if we were generating a main or not in the class source builder, and not finish the class until the main method was finished. I did this by checking to see if we were in a main method generation in the class generator and not finishing the class source generation until after the main method was generated if that’s true. But of course, that by itself added new problems because you can have multiple classes in a .mirah file. So I added a klass method on the Mirah::JavaSource::MethodBuilder so I could check both whether we are in a main method and whether it is the main method of the current class.

After doing that, the generated code looks like this:

Much better

Since I haven’t written tests specifically for this yet, I put it on a branch on my fork of Mirah so I can get some other eyeballs on it. I’m also sure there’s a better approach than the one I took.

One other thing I found is that if the name of the .mirah file is different than any of the classes in it, it compiles correctly even w/o the patch. Which makes sense because in that case there is no class body for the class with the same name as the file.

I had my regular Mirah office hours on Sunday.

This week I focused on getting all the tests passing for the patches that were merged earlier in the week, which were among the things that fell out of this big thread on the mailing list. One of the other things was that a number of people became collaborators on the repository (like me ).

When trying to get tests working, I ran into some issues with JRuby and NailGun. RVM latest starts up a nailgun server by default when using JRuby, which is cool because it’s faster, but I had some problems. Essentially, Mirah’s compile scripts were attempting to run in NailGun’s home directory, which didn’t work very well…

I fixed it by setting JRUBY_OPT=”", which told JRuby not to send requests to NailGun. Better would be to chmod -x .rvm/hooks/after_use_jruby, which would additionally avoid starting a NailGun server. The best thing would be to figure out what happened and fix it in JRuby’s NailGun integration. Unfortunately, after I got Mirah’s test suite working, I couldn’t reproduce the issue with NailGun reenabled.

In the end, I got all the tests passing except the one for the new loop macro, which still has an inference error.

The new addition of a top_level? method on AST nodes cleaned things up pretty nicely by not requiring a script class unless there are things defined in the top level scope. Most of my changes dealt with that–fewer classes were generated out of the compiled code (commit).

I had fun fixing things, even though it was frustrating that I couldn’t get to the more interesting things I wanted to work on (closures, Dubious, Shatner). Maybe I’ll get to them on my next set of office hours.