I sent a patch to yhc@haskell.org, but triggered the moderation system for the message being too long. The patch can be found by pulling from my alternate repo at http://www.downstairspeople.org/darcs/yhc_clanehin Note that this repo is inconsistent with what it was yesterday, if you pulled from that, as though by unrecord. So pull freshly if needed. Please advise as needed. --Lane
Hi Lane, Fantastic! How close to the base libraries are these? Ideally we would have the patches go to the base library, and flip to using the base library repo instead. So, as it stands there are several choices: 1) Keep accumulating patches into the Yhc project repo, then at some point in the future, try and merge the patches back into the base libs. 2) Move to the base libraries almost now, and try and send the patches to the base libraries. 3) Do 1, but keep trying to get the patches into the base libraries so the diff between our libs and their's remains nothing. Personally I favour 3 - it seems like least work, but whichever one you want, its your choice. I have committed this patch, and done a small sample with Data.Map, and am very impressed! I ran into one dependancy ordering issue - these vary with machine - and had to fix that. Well done! Neil
Thanks Neil! Let's do #1 for now. All the major yhc specific work is under YHC/, so I don't expect a very large diff at the end. In the time since I started, there was one moderately sized patch to the libraries, but it changed a file that isn't in yhc yet. If I start seeing patches to the libraries that conflict with my diffs in ways that make me do work, I'll change my mind very fast. :) --Lane On Fri, 12 Jan 2007, Neil Mitchell wrote:
Hi Lane,
Fantastic!
How close to the base libraries are these? Ideally we would have the patches go to the base library, and flip to using the base library repo instead. So, as it stands there are several choices:
1) Keep accumulating patches into the Yhc project repo, then at some point in the future, try and merge the patches back into the base libs.
2) Move to the base libraries almost now, and try and send the patches to the base libraries.
3) Do 1, but keep trying to get the patches into the base libraries so the diff between our libs and their's remains nothing.
Personally I favour 3 - it seems like least work, but whichever one you want, its your choice.
I have committed this patch, and done a small sample with Data.Map, and am very impressed! I ran into one dependancy ordering issue - these vary with machine - and had to fix that.
Well done!
Neil
Hi Lane,
Let's do #1 for now. All the major yhc specific work is under YHC/, so I don't expect a very large diff at the end.
One other thing, if when you do change things like commenting out typeable, you were to use #ifdef's, that would probably aid the reintegration part. I don't think the reintegration will be too hard, since it can be done on a per-file basis - it doesn't need to work on haskell.org all at once, as long as we don't break it for everyone else. Thanks Neil
Hi YHC, I'm trying to do a make_tuple of 11 elements. Is the correct structure to do: MAKE_NODE(ret, G_infoTuple, N_NORMAL); ... node->args[0] = thing0 node->args[1] = thing1 node->args[2] = thing2 node->args[3] = thing3 ... node->args[10] = thing10 Then, how does the garbage collector know the number of elements? I would have thought that it would basically have been make_array, but make array uses data, not args; how does data help the situation? Finally, I would think that I would nead to heap_pushGlobal any time I call anything that calls heap_alloc, but not all functions do this: Node* _primIntegerQuotRem(Node* node){ Node* quot = _primIntegerQuot(node); Node* rem = _primIntegerRem(node); return make_tuple(quot, rem); } Could the GC not be called during _primIntegerRem, and collect quot? Thanks, --Lane
Hi,
Hi YHC,
I'm trying to do a make_tuple of 11 elements.
Is the correct structure to do:
MAKE_NODE(ret, G_infoTuple, N_NORMAL);
...
node->args[0] = thing0 node->args[1] = thing1 node->args[2] = thing2 node->args[3] = thing3 ... node->args[10] = thing10
Then, how does the garbage collector know the number of elements?
I would have thought that it would basically have been make_array, but make array uses data, not args; how does data help the situation?
My first question is to ask why you need to make an 11 tuple from the C code. I guess you must be adding support for some library, but the normal way to do that is using the FFI. Only one or two specialised things in the prelude are coded directly using the C interface. In any case I've just pushed a patch that makes it much easier to make tuples from the C code. You can now use Node* make_nTuple(int num, ...); To make a tuple of any size (including 0). So now you can do return make_nTuple(3, a, b, c);
Finally, I would think that I would nead to heap_pushGlobal any time I call anything that calls heap_alloc, but not all functions do this:
Node* _primIntegerQuotRem(Node* node){ Node* quot = _primIntegerQuot(node); Node* rem = _primIntegerRem(node); return make_tuple(quot, rem); }
Could the GC not be called during _primIntegerRem, and collect quot?
Oops, yes that's a bug. This is partly why we've moved to using the FFI for primitives where possible. It's so easy to make mistakes. Thanks Tom
participants (3)
-
Christopher Lane Hinson -
Neil Mitchell -
Tom Shackell