[Announce] Yhc Bytecode library 0.3
[Please direct disccusion to the yhc list] Fellow Haskellers, I am pleased to announce the release of the Yhc Bytecode library, version 0.3. The major differences from version 0.2 are: * Updated to work with the current Yhc development branch as of 2006-10-13 * API modified to fully handle the string table so that it is no longer exposed to the user * Added support for the 'Ext' and 'Prim' object types * Slightly improved some error messages Source and Haddock documentation downloads are avaliable from: http://www.eecs.tufts.edu/~rdocki01/yhc-bytecode.html Direct access to the darcs repository from: http://www.eecs.tufts.edu/~rdocki01/yhc-bytecode/ Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG
Hi Robert,
I am pleased to announce the release of the Yhc Bytecode library, version 0.3.
Cool :) Do you think now is a good time to move it into the main Yhc repo? I've now created a separate libraries directory which has Yhc.Core in it and Yhc.General. I am also working on having the scons install command install the libraries using Cabal. Plus scons push works well for everyone now. It also makes it easier for Yhc to use the ByteCode library, when we decide to do that. I was also thinking of moving the binary interface bits of Bytecode into either Yhc.Binary or Yhc.General (not sure yet), so that Yhc.Core can share the binary low level layer from Yhc.ByteCode - currently it uses something a bit hacky. What are your thoughts on this? Thanks Neil
* Updated to work with the current Yhc development branch as of 2006-10-13 * API modified to fully handle the string table so that it is no longer exposed to the user * Added support for the 'Ext' and 'Prim' object types * Slightly improved some error messages
Source and Haddock documentation downloads are avaliable from:
http://www.eecs.tufts.edu/~rdocki01/yhc-bytecode.html
Direct access to the darcs repository from: http://www.eecs.tufts.edu/~rdocki01/yhc-bytecode/
Rob Dockins
Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG
_______________________________________________ Yhc mailing list Yhc@haskell.org http://www.haskell.org/mailman/listinfo/yhc
On Oct 29, 2006, at 3:45 PM, Neil Mitchell wrote:
Hi Robert,
I am pleased to announce the release of the Yhc Bytecode library, version 0.3.
Cool :)
Do you think now is a good time to move it into the main Yhc repo? I've now created a separate libraries directory which has Yhc.Core in it and Yhc.General. I am also working on having the scons install command install the libraries using Cabal. Plus scons push works well for everyone now. It also makes it easier for Yhc to use the ByteCode library, when we decide to do that.
Now seems as fine a time as any. It is certainly better than a few days ago when it was broken ;-) As far as I know, it is now completely compatible with the C runtime.
I was also thinking of moving the binary interface bits of Bytecode into either Yhc.Binary or Yhc.General (not sure yet), so that Yhc.Core can share the binary low level layer from Yhc.ByteCode - currently it uses something a bit hacky. What are your thoughts on this?
That seems fine to me. That stuff is tricky to get right, and it's better to have it in one place. One caveat, though. Right now, I'm doing a bunch of truly ugly hacks (such as assuming that Char is basically a Word8) because Yhc didn't have support for Data.Bits, Data.Int and Data.Word when I started the project (self-hosting concerns). If Yhc had those libraries, we could get rid of that crap and do it the right way.
Thanks
Neil
* Updated to work with the current Yhc development branch as of 2006-10-13 * API modified to fully handle the string table so that it is no longer exposed to the user * Added support for the 'Ext' and 'Prim' object types * Slightly improved some error messages
Source and Haddock documentation downloads are avaliable from:
http://www.eecs.tufts.edu/~rdocki01/yhc-bytecode.html
Direct access to the darcs repository from: http://www.eecs.tufts.edu/~rdocki01/yhc-bytecode/
Rob Dockins
Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG
Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG
Hi,
Now seems as fine a time as any. It is certainly better than a few days ago when it was broken ;-) As far as I know, it is now completely compatible with the C runtime.
Do you want to take on that job, or shall I? I guess we have no choice but to loose the history in your repo?
I was also thinking of moving the binary interface bits of Bytecode into either Yhc.Binary or Yhc.General (not sure yet), so that Yhc.Core can share the binary low level layer from Yhc.ByteCode - currently it uses something a bit hacky. What are your thoughts on this?
That seems fine to me. That stuff is tricky to get right, and it's better to have it in one place.
Indeed, for Float's I just use outString (show x) - so having something proper would be good!
One caveat, though. Right now, I'm doing a bunch of truly ugly hacks (such as assuming that Char is basically a Word8) because Yhc didn't have support for Data.Bits, Data.Int and Data.Word when I started the project (self-hosting concerns). If Yhc had those libraries, we could get rid of that crap and do it the right way.
Do you actually have Yhc.ByteCode compiling with Yhc? If its only a future self-hosting concern I'd just say use Data.Int now, and when we need to self-host we'll make sure we add it. If its an active issue, I'll talk to Tom and see what we can do. Thanks Neil
On Oct 29, 2006, at 4:03 PM, Neil Mitchell wrote:
Hi,
Now seems as fine a time as any. It is certainly better than a few days ago when it was broken ;-) As far as I know, it is now completely compatible with the C runtime.
Do you want to take on that job, or shall I? I guess we have no choice but to loose the history in your repo?
I think it would be better if you did it. I'm not familiar with scons at all, and I don't have time to get up to speed just now. As to the history, I'm not sure. I don't know of a way to merge separate darcs repositories, but that doesn't mean there isn't one. Either way, there isn't a tremendous amount of history, so I don't think it would be a great loss.
I was also thinking of moving the binary interface bits of Bytecode into either Yhc.Binary or Yhc.General (not sure yet), so that Yhc.Core can share the binary low level layer from Yhc.ByteCode - currently it uses something a bit hacky. What are your thoughts on this?
That seems fine to me. That stuff is tricky to get right, and it's better to have it in one place.
Indeed, for Float's I just use outString (show x) - so having something proper would be good!
One caveat, though. Right now, I'm doing a bunch of truly ugly hacks (such as assuming that Char is basically a Word8) because Yhc didn't have support for Data.Bits, Data.Int and Data.Word when I started the project (self-hosting concerns). If Yhc had those libraries, we could get rid of that crap and do it the right way.
Do you actually have Yhc.ByteCode compiling with Yhc?
I actually haven't tested it. I always meant to get around to it, but I just haven't. No cabal support just made the barrier a little to high for me to take time to do it. I expect that it would work (you have Data.Map now right?)
If its only a future self-hosting concern I'd just say use Data.Int now, and when we need to self-host we'll make sure we add it. If its an active issue, I'll talk to Tom and see what we can do.
Thanks
Neil
Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG
participants (2)
-
Neil Mitchell -
Robert Dockins