Re: Compiling Elisp to a native code with a GCC plugin

[Tom Tromey <tromey@redhat.com>]

Tom> For the concurrency stuff, we did two kinds of automated rewriting.

Wojciech> If you could point me out with the tools you used for this
Wojciech> job, I would be grateful, any points to git?

It is in the concurrency branch in Emacs bzr.  I assume this is mirrored
in git, but I'm not sure.

I can email you the two .el scripts if you like, plus the little GCC
patch I had to use to get the right location for the -> tokens.  Just
let me know.

If you check out the concurrency branch, the files are
src/hack-buffer-objfwd.el and src/rewrite-globals.el.

Wojciech> However clang error messages are currently are more precise
Wojciech> than GCC (yes, we can match-replace regex, and it will work
Wojciech> fine in most cases).

Recent versions of GCC are a lot better about marking the correct token
when emitting an error.  Red Hat put some work into this.

What hack-buffer-objfwd.el actually does is go to the location of the
error, then go backwards over sexps doing some pattern matching to see
where the left-hand-side of the -> operator starts.  Then it rewrites.
This is rather hacky and IIRC there are some Emacs-specific heuristics
in there.

Tom> My advice is to try to do this bulk rewriting work on head, so that it
Tom> doesn't rot.  I think that's been a problem for the concurrency work
Tom> :-(

Wojciech> Any chances to get it back to life?

I have zero (really negative) free time.  But yes, it can be
resurrected.  One starting point would be doing a merge from trunk.
Giuseppe did this but ran into problems... I still don't really know the
details, just that things changed on trunk in some conflicting way.

Wojciech> Shall we setup a public repo somewhere then?

We had one on gitorious.  But I think if you are going to try to work on
trunk you should just use bzr.  Or at least use the semi-official git
mirror when preparing patches.

Tom