Mirah Hackathon

[Ryan Brown]

I'm going to spend two weeks working on Mirah in April. Doing it alone
is no fun so I'm organizing a hackathon at Google for anyone who wants
to work on Mirah or related libraries. Usually these are for employees
only, but since Mirah is open source I'm trying to see about making it
public. If you'd be interested in attending the hackathon from April
9-20, or in participating remotely please fill out this form:
http://goo.gl/zi1Qh

Thanks,

-- Ryan Brown

[Charles Oliver Nutter]

I'm definitely in. I don't think I'll be able to make the trip to CA,
but I'll be online as much as possible and will focus as much of my
time as I can.

I'll toss out a few broad goals.

* Codebase cleanup

The codebase needs to be more approachable. Some of this can start
ahead of time, but we're kinda between two branches right now. The
"newast" branch moves a lot of AST and compiler logic into Mirah code.
That branch is the future, but it's a little difficult to work with
right now.

* Specification writing

Mirah has a large complement of features already that have little to
no documentation. And writing up those features and expanding from
there will start to call out areas we need to solidify, things we're
missing, and so on. It's not hard at all to start writing up
features...anything is better than nothing.

* Codebase usability, command-line usability

The codebase is sometimes challenging to build. The command-line tools
are primitive at best. There's a lot of improvement possible here
without touching parser, compiler, or anything wacky.

I think this is a prime time to make Mirah really go. I'm excited to
get back into Mirah dev :)

- Charlie

[Daniel Lucraft]

Hi Ryan

Just responded. How does a hackathon work? From a long distance participant?

best

Dan

[Ryan Brown]

Thanks. The idea with the hackathon is that we can be more productive and accomplish more in a short period of time by working together.  I think what Charles said is the basic idea for remote participation: Try be online and focus on Mirah as much as possible.  Maybe we can use a hangout to meet each other and get more of the in-person feeling? We'll also need to work on co-ordinating tasks so we make sure people don't end up duplicating effort. Should we use the github issue tracker for this?

[Andres Almiray]

If I may offer a couple of suggestions, I'd like to see the following
features provided by the Mirah compiler

1. Accept multiple src elements (like Javac's Ant task)
2. Allow file encoding to be specified

#1 has to do with the fact that mirah source files depend on the path
to determine the actual package IIRC. We have create a Mirah plugin
for Griffon (http://artifacts.griffon-framework.org/plugin/mirah)
which at the moment lets you write helper classes in Mirah. It's also
possible to write artifact classes (Controllers, Models, Views, etc)
in Mirah as shown by https://gist.github.com/2de9e2fade879eac8181
however the problem is that these artifact live in different
directories. Considering that Controllers may refer to Models, and
that other artifacts may refer to other artifacts too it's hard to
figure out the compilation order with just a single source dir per
compile session.
With this feature in place it will be possible to write an almost 100%
Mirah based Griffon application (some config files have to remain in
Groovy source though).

#2 We currently have many users from Germany, Russia and Japan, I'm
sure some of them would love to write Mirah code using their own
alphabet.

Finally, I don't remember If the Mirah compiler already supports joint
compilation of Java sources or not. If not, is this a feature in the
roadmap?

Cheers,
Andres