Friends! I have just released an alpha version of a library for reading and writing the YHC bytecode file format. It's not quite finished but currently quite usable. It reads and writes the entire bytecode set, version 1.9 (the one used by recent YHC builds). The project homepage is: http://www.eecs.tufts.edu/~rdocki01/yhc-bytecode.html From this page you can find tarballs, docs, and a darcs repository. Comments and suggestsions are welcome. Note that this library is currently GPL. I'm still considering my options on this front. If you have a strong opinion AND a convincing argument for some other license, email me. Thanks, and enjoy. -- Rob Dockins Talk softly and drive a Sherman tank. Laugh hard, it's a long way to the bank. -- TMBG
Yay!
I haven't downloaded it yet (I'll get to it in a few days :) ), but it looks pretty much exactly like what I was aiming for, which is very nice to see! There is only one really small and minor thing - we have decided to use the namespace Yhc instead of YHC, since the compiler is "officially" called Yhc. It would be nice if we could put this in the main Yhc, if thats ok by you. I'm not sure if we can give you commit access, but I'll look into it, and otherwise we can figure out a remote darcs repo and then pull from it as required. And also it would be nice for the back end of the compiler to use this as well. The only remaining this is the license, since none of the original nhc code made it to this side of the compiler, the only people with copyright on this stuff (or anything related to it) are you, me and Tom. Me and Tom both think that maybe LGPL would be more appropriate for this library, on the basis that then people can use the library from both a GPL program and a BSD program, and it seems that BSD is the prefered license for Haskell stuff, so it makes us more compatible. Thanks for this great work! Neil
Neil Mitchell wrote: <snip>
I'm not sure if we can give you commit access, but I'll look into it, and otherwise we can figure out a remote darcs repo and then pull from it as required.
Unfortunately I doubt that's possible, since it would require an account at the university. Thanks :-) Tom
On Jun 20, 2006, at 8:37 AM, Neil Mitchell wrote:
Yay!
I haven't downloaded it yet (I'll get to it in a few days :) ), but it looks pretty much exactly like what I was aiming for, which is very nice to see!
There is only one really small and minor thing - we have decided to use the namespace Yhc instead of YHC, since the compiler is "officially" called Yhc.
OK. That's easy enough to change. Is the namespace consumption otherwise acceptable?
It would be nice if we could put this in the main Yhc, if thats ok by you. I'm not sure if we can give you commit access, but I'll look into it, and otherwise we can figure out a remote darcs repo and then pull from it as required. And also it would be nice for the back end of the compiler to use this as well.
Well, I suppose that depends on what's meant by "in the main Yhc". I think its most valuable as a standalone library, so I'm not sure its a good idea to merge it into the Yhc compiler codebase, if that's what you mean. If you mean "in the Yhc darcs repo" that may still be problematic if I can't get commit access, because there are still a number of things I hope to do with this library. So, I guess I'm not really sure. Perhaps explicitly pulling from a remote repository is the best thing for now? The only other issue is that I don't think this library is 100% ready for production use. I'd really like to write a good test suite before I feel comfortable with Yhc relying on it. Unfortunately I'm not sure when I'll have time to do this :-(
The only remaining this is the license, since none of the original nhc code made it to this side of the compiler, the only people with copyright on this stuff (or anything related to it) are you, me and Tom. Me and Tom both think that maybe LGPL would be more appropriate for this library, on the basis that then people can use the library from both a GPL program and a BSD program, and it seems that BSD is the prefered license for Haskell stuff, so it makes us more compatible.
OK. I'll make the next release LGPL.
Thanks for this great work!
Neil
Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG
Hi Robert
OK. That's easy enough to change. Is the namespace consumption otherwise acceptable? Yep, pretty perfect I would say.
The only thing that slightly seems odd is the BinaryRead/BinaryWrite classes - I'm not sure if they are related to the "YHC.Bytecode.ModuleFormat.Version_1", or if they should be somewhere else in the namespace, or perhaps if they should be hidden altogether as an implementation detail. For the moment just leave them where they are though.
Well, I suppose that depends on what's meant by "in the main Yhc". I think its most valuable as a standalone library, so I'm not sure its a good idea to merge it into the Yhc compiler codebase, if that's what you mean. If you mean "in the Yhc darcs repo" that may still be problematic if I can't get commit access, because there are still a number of things I hope to do with this library. I just meant in the Yhc repo, as a separate and well defined library.
There are a few options to allow you to change the Yhc repo - you can set up your own darcs copy of yhc-devel and we can set up a cron script to pull every night, it might be possible to give you access (i remember reading something on the support pages once), or we might be best moving to darcs.haskell.org then everyone has an equal standing.
The only other issue is that I don't think this library is 100% ready for production use. I'd really like to write a good test suite before I feel comfortable with Yhc relying on it. Unfortunately I'm not sure when I'll have time to do this :-( Once Yhc relies on it you'll have a good testsuite automatically :) - it doesn't matter if it breaks Yhc for a few days in the meantime.
OK. I'll make the next release LGPL. Fantastic.
Thanks Neil
participants (3)
-
Neil Mitchell -
Robert Dockins -
Thomas Shackell