From naesten at gmail.com Mon Jul 2 20:52:09 2007 From: naesten at gmail.com (Samuel Bronson) Date: Tue Jul 3 05:29:51 2007 Subject: [jhc] darcs patch: Add foreign import "dynamic" support Message-ID: Mon Jul 2 20:47:22 EDT 2007 Samuel Bronson * Add foreign import "dynamic" support -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 7312 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20070702/f0136007/attachment.bin From naesten at gmail.com Fri Jul 6 12:11:43 2007 From: naesten at gmail.com (Samuel Bronson) Date: Fri Jul 6 12:07:05 2007 Subject: [jhc] darcs patch: Remove E/FromHs.hs~ from repo Message-ID: Fri Jul 6 12:11:13 EDT 2007 Samuel Bronson * Remove E/FromHs.hs~ from repo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 41600 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20070706/baf78176/attachment-0001.bin From john at repetae.net Fri Jul 6 19:23:35 2007 From: john at repetae.net (John Meacham) Date: Fri Jul 6 19:17:23 2007 Subject: [jhc] darcs patch: Add foreign import "dynamic" support In-Reply-To: References: Message-ID: <20070706232335.GB18430@momenergy.repetae.net> On Mon, Jul 02, 2007 at 08:52:09PM -0400, Samuel Bronson wrote: > Mon Jul 2 20:47:22 EDT 2007 Samuel Bronson > * Add foreign import "dynamic" support Thanks! I finally got a chance to look at this. looks good! I am thinking that a regression test that tests all the aspects of the FFI is in order... hopefully just using things from the standard libc so no external C file would be needed. John -- John Meacham - ?repetae.net?john? From naesten at gmail.com Fri Jul 6 19:28:16 2007 From: naesten at gmail.com (Samuel Bronson) Date: Fri Jul 6 19:23:28 2007 Subject: [jhc] darcs patch: Line LetRecs up nicer (and 1 more) Message-ID: Fri Jul 6 15:46:49 EDT 2007 Samuel Bronson * Line LetRecs up nicer Fri Jul 6 17:01:23 EDT 2007 Samuel Bronson * Add "return" to the functions known to the compiler -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 1051 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20070706/9b0caf1c/attachment.bin From naesten at gmail.com Fri Jul 6 19:28:52 2007 From: naesten at gmail.com (Samuel Bronson) Date: Fri Jul 6 19:24:08 2007 Subject: [jhc] darcs patch: Add foreign import "dynamic" support (and 4 more) Message-ID: Mon Jul 2 20:47:22 EDT 2007 Samuel Bronson * Add foreign import "dynamic" support Fri Jul 6 12:11:13 EDT 2007 Samuel Bronson * Remove E/FromHs.hs~ from repo Fri Jul 6 15:46:49 EDT 2007 Samuel Bronson * Line LetRecs up nicer Fri Jul 6 17:01:23 EDT 2007 Samuel Bronson * Add "return" to the functions known to the compiler Fri Jul 6 18:56:11 EDT 2007 Samuel Bronson * Get pure foreign exports through E... Grin forgets them though -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 55270 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20070706/eba33b21/attachment-0001.bin From john at repetae.net Fri Jul 6 19:45:47 2007 From: john at repetae.net (John Meacham) Date: Fri Jul 6 19:39:39 2007 Subject: [jhc] darcs patch: Add foreign import "dynamic" support (and 4 more) In-Reply-To: References: Message-ID: <20070706234547.GC18430@momenergy.repetae.net> On Fri, Jul 06, 2007 at 07:28:52PM -0400, Samuel Bronson wrote: > Fri Jul 6 12:11:13 EDT 2007 Samuel Bronson > * Remove E/FromHs.hs~ from repo I don't have a E/FromHs.hs~ in my repo so this patch can't apply, perhaps something odd is going on? > > Fri Jul 6 18:56:11 EDT 2007 Samuel Bronson > * Get pure foreign exports through E... Grin forgets them though Could you explain a little more about this patch? thanks. John -- John Meacham - ?repetae.net?john? From naesten at gmail.com Fri Jul 6 21:56:10 2007 From: naesten at gmail.com (Samuel Bronson) Date: Fri Jul 6 21:49:53 2007 Subject: [jhc] darcs patch: Add foreign import "dynamic" support (and 4 more) In-Reply-To: <20070706234547.GC18430@momenergy.repetae.net> References: <20070706234547.GC18430@momenergy.repetae.net> Message-ID: On 7/6/07, John Meacham wrote: > On Fri, Jul 06, 2007 at 07:28:52PM -0400, Samuel Bronson wrote: > > Fri Jul 6 12:11:13 EDT 2007 Samuel Bronson > > * Remove E/FromHs.hs~ from repo > > I don't have a E/FromHs.hs~ in my repo so this patch can't apply, > perhaps something odd is going on? Have you removed yours in your working branch? I'm working against http://repetae.net/john/repos/jhc > > Fri Jul 6 18:56:11 EDT 2007 Samuel Bronson > > * Get pure foreign exports through E... Grin forgets them though > > Could you explain a little more about this patch? thanks. Well, I've got "foreign export ccall" generating E that typechecks and gets translated into grin for pure functions... but it isn't yet added to grinEntryPoints. Also, somehow "f"s are getting stuck on the beginning of the names... For example: import Jhc.Int import Jhc.Enum foreign export increment :: Int -> Int foreign export succ :: Int -> Int But don't try: import Jhc.IO import Jhc.Num foreign export foo :: IO Int foo :: Num a => IO a foo = returnIO 1 -- because I haven't figured out how to generate the code for those quite yet. I think I might need unsafePerformIO? P.S. sorear (stefanor) and dons say that we'd be interested in hearing about what FunctorM has that Control.Applicative lacks. libraries@haskell.org recieves library complaints, questions, and comments *very* well. Basically, we want to know what the problem is so we can fix it ;-). From naesten at gmail.com Sat Jul 7 14:20:49 2007 From: naesten at gmail.com (Samuel Bronson) Date: Sat Jul 7 14:14:31 2007 Subject: [jhc] some FFI questions Message-ID: First of all, I'm wondering what the intended uses of the lookupCType and lookupCType' functions are. It seems like lookupCType tells you the type that should be used in marshalling a type, and lookupCType tells you the primitive type that is used in the representation of a type as well as how to extract the value from it. I'm not sure how to go from there to actually converting to/from the correct primitive type to use in interfacing with C code... Another question is: what sort of E type should an imperative foreign export use? Consider: foreign export hello :: Int -> IO () hello n = putStrLn ("Hello, "++show n) foreign export foo :: IO Int foo :: Num a => IO a foo = return 1 Should they just use IO? I guess that's what main does... From naesten at gmail.com Sat Jul 7 14:21:23 2007 From: naesten at gmail.com (Samuel Bronson) Date: Sat Jul 7 14:16:40 2007 Subject: [jhc] darcs patch: Make "make ghci" an alias for "make i" Message-ID: Sat Jul 7 14:19:50 EDT 2007 Samuel Bronson * Make "make ghci" an alias for "make i" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 550 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20070707/ffe3844a/attachment.bin From naesten at gmail.com Sat Jul 7 23:56:50 2007 From: naesten at gmail.com (Samuel Bronson) Date: Sat Jul 7 23:52:12 2007 Subject: [jhc] darcs patch: Add foreign import "dynamic" support (and 8 more) Message-ID: Okay, I think it would be working now if the "unsafeCoerce" primitive would work. Not quite sure, though. Guidance welcome ;-). Sorry about the dupes -- darcs ought to have a "dot graph of pending patches" function... Mon Jul 2 20:47:22 EDT 2007 Samuel Bronson * Add foreign import "dynamic" support Fri Jul 6 12:11:13 EDT 2007 Samuel Bronson * Remove E/FromHs.hs~ from repo Fri Jul 6 18:56:11 EDT 2007 Samuel Bronson * Get pure foreign exports through E... Grin forgets them though Sat Jul 7 14:19:32 EDT 2007 Samuel Bronson * Get foreign exports through Grin, yay! Sat Jul 7 14:19:50 EDT 2007 Samuel Bronson * Make "make ghci" an alias for "make i" Sat Jul 7 16:11:43 EDT 2007 Samuel Bronson * Add unsafePerformIO to wired-in functions Sat Jul 7 16:43:26 EDT 2007 Samuel Bronson * Implement foreign exports returning IO () (clumsily) Sat Jul 7 16:47:23 EDT 2007 Samuel Bronson * tag things to make Grin happyier about my 'c' functions. I don't really understand this, which is why I made a seperate patch... Sat Jul 7 23:51:40 EDT 2007 Samuel Bronson * Not-quite-working attempt to use unsafeCoerce to get the right type... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 60130 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20070707/b79675fa/attachment-0001.bin From naesten at gmail.com Sun Jul 8 00:25:40 2007 From: naesten at gmail.com (Samuel Bronson) Date: Sun Jul 8 00:20:59 2007 Subject: [jhc] darcs patch: FFI test case: exercises import, export, and import dy... Message-ID: Sun Jul 8 00:24:26 EDT 2007 Samuel Bronson * FFI test case: exercises import, export, and import dynamic -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 1130 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20070708/4d9e840e/attachment.bin From naesten at gmail.com Mon Jul 9 17:00:33 2007 From: naesten at gmail.com (Samuel Bronson) Date: Mon Jul 9 16:54:10 2007 Subject: [jhc] hmm. this approach to FFI export's types isn't working :-(. Message-ID: It seems that the types that would be appropriate for the arguments of an FFI-exported function are not really allowed to exist in E or Grin :-(. What should I do about this? Perhaps the marshalling should be saved for the very end, and done in C.FromGrin2 or thereabouts? From naesten at gmail.com Mon Jul 9 20:05:22 2007 From: naesten at gmail.com (Samuel Bronson) Date: Mon Jul 9 19:59:11 2007 Subject: [jhc] darcs patches with working "foreign export" Message-ID: This is everything you need for it to work ... and some things you don't need. Conflicts with that patch that tried to use unsafeCoerce. I changed the Info item of type FfiExport to be of type (FfiExport,([ExtType],ExtType)). This can probably be cleaned up somehow. I also don't think that the 'x' and 'X' tags in Grin names should be needed, but I'm not sure how to get rid of them. FromGrin2.convertFunc uses the type info to generate a function of the appropriate type by making new variables for the arguments and assigning the values of those to the old variables. (Which for some reason magically get declared now.) For the return type, it just hopes for the best right now... Mon Jul 2 20:47:22 EDT 2007 Samuel Bronson * Add foreign import "dynamic" support Fri Jul 6 12:11:13 EDT 2007 Samuel Bronson * Remove E/FromHs.hs~ from repo Fri Jul 6 18:56:11 EDT 2007 Samuel Bronson * Get pure foreign exports through E... Grin forgets them though Sat Jul 7 14:19:32 EDT 2007 Samuel Bronson * Get foreign exports through Grin, yay! Sat Jul 7 14:19:50 EDT 2007 Samuel Bronson * Make "make ghci" an alias for "make i" Sat Jul 7 16:11:43 EDT 2007 Samuel Bronson * Add unsafePerformIO to wired-in functions Sat Jul 7 16:43:26 EDT 2007 Samuel Bronson * Implement foreign exports returning IO () (clumsily) Sat Jul 7 16:47:23 EDT 2007 Samuel Bronson * tag things to make Grin happyier about my 'c' functions. I don't really understand this, which is why I made a seperate patch... Sun Jul 8 00:24:26 EDT 2007 Samuel Bronson * FFI test case: exercises import, export, and import dynamic Mon Jul 9 19:38:11 EDT 2007 Samuel Bronson * Yay! "foreign export", really working! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 61496 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20070709/a2b1e508/attachment-0001.bin From john at repetae.net Mon Jul 9 20:59:56 2007 From: john at repetae.net (John Meacham) Date: Mon Jul 9 20:53:31 2007 Subject: [jhc] some FFI questions In-Reply-To: References: Message-ID: <20070710005956.GD18430@momenergy.repetae.net> On Sat, Jul 07, 2007 at 02:20:49PM -0400, Samuel Bronson wrote: > First of all, I'm wondering what the intended uses of the lookupCType > and lookupCType' functions are. It seems like lookupCType tells you > the type that should be used in marshalling a type, and lookupCType > tells you the primitive type that is used in the representation of a > type as well as how to extract the value from it. I'm not sure how to > go from there to actually converting to/from the correct primitive > type to use in interfacing with C code... A lot of this is due to history and a very major rewrite of jhc internals, switching everything from a C based view of the world to a c-- (or assembly) one. It used to be that raw haskell types (basic numeric types) were associated with a specific C type, such as 'int' and all that entails, so things like 'int', 'unsigned', 'wchar_t', etc were all independent types, treated as opaque by jhc threading their way all through the system from source to code generation and the actual operations performed such as unsigned multiply vs signed were affected by the type. Also, when this system was in place, first class unboxed values did not exist, requiring the creation of data/primitives.txt to provide a mapping of C primitive types to haskell types so it can build the proper instances constructors etc as appropriate. In addition, this type determined the C calling convention used. so the then aptly named 'lookupCType' functions basically took a name, and looked up the info in the appropriate primitive tables and whatnot. needless to say, this situation although nice and straightforward at first, was quite problematic, there were lots of things like casting from 'wchar_t' to 'int' inhibiting optimizations. you would have to cast a value explicity in order to do a signed operation on it instead of an unsigned one. You could not vary the calling convention used in FFI calls independent of the type, for instance, you mich want 'Char' to translate to a 'wchar_t' calling convention, even though you don't want 'wchar_t' to be the representation used for 'Char'. Thus C/Op.hs and friends were born. now, primitive types are fully specified and all operations are spelt out explicitly. rawTypes no longer coorespond to C types, but rather a well defined internal format such as 'bits32' and all operations are fully specified (signed multiply and unsigned multiply are independent operations, as are floating point vs non floating point, etc) however, rather than change the E representation of types, a rawtype now _must_ contain a serialized version of a C-- type, not a C type like they used to have in them. The mapping of names used in foreign declarations to the calling convention is now indpendent of the haskell representation of the type, this is very nice for when a type is a newtype of another and actually represents a different C value. however, this change is very recent and there is still a lot of code around that refers to C types, and old tables for looking up properties of C types that arn't used anymore. the lookupCType functions will be replaced by nicer more explicit querying operations. The C type used in the calling convention is what is actually stored in the ExtType parameter in C/Prim and is completly independent of the E or Grin type and only comes up again in code generation. explicit casts are not needed because the code generator knows how to do so and there may be no analog of the C type in grin or E (in fact, C may never come into play if using a native code generator) > Another question is: what sort of E type should an imperative foreign > export use? Consider: > > foreign export hello :: Int -> IO () > hello n = putStrLn ("Hello, "++show n) > > foreign export foo :: IO Int > foo :: Num a => IO a > foo = return 1 > > Should they just use IO? I guess that's what main does... I am not sure what you mean. foreign exports are 'metainfo' and need not affect anything at all until code generation when a proper alias or exported symbol is emitted by the code generator. (gcc provides a way to create explicit aliases, but gcc inlining should make that moot) for that case, since you can't export 'foo' directly (having a different type), a placeholder function should be generated in the compiler private namespace. something like F@.fMain.foo = foo Int then F@.fMain.foo would be annotated with the proper foreign export declaration. I don't think IO ever needs to be treated specially other than setting the IOLike flag properly and making sure the world argument is added in the right spot. John -- John Meacham - ?repetae.net?john? From john at repetae.net Mon Jul 9 21:14:57 2007 From: john at repetae.net (John Meacham) Date: Mon Jul 9 21:08:51 2007 Subject: [jhc] hmm. this approach to FFI export's types isn't working :-(. In-Reply-To: References: Message-ID: <20070710011457.GE18430@momenergy.repetae.net> On Mon, Jul 09, 2007 at 05:00:33PM -0400, Samuel Bronson wrote: > It seems that the types that would be appropriate for the arguments of > an FFI-exported function are not really allowed to exist in E or Grin > :-(. What should I do about this? Yes, this is done specifically on purpose now (see my other post). the foreign calling convention is fully and only specified by the 'ExtType' fields in the C Primitive. these need not (and likely won't) coorespond to E or Core types. the proper ExtType is determined by the name used in the foreign export, _not_ its type, so you can't just expand all newtypes away then look at the result, you peel off newtypes in layers until you get a valid translation to a C calling convention and store that in the C.Prim field and then forget about it until C/FromFoo John -- John Meacham - ?repetae.net?john? From naesten at gmail.com Tue Jul 10 13:24:01 2007 From: naesten at gmail.com (Samuel Bronson) Date: Tue Jul 10 13:17:57 2007 Subject: [jhc] darcs patch: Allow empty import lists Message-ID: Mon Jul 9 22:55:32 EDT 2007 Samuel Bronson * Allow empty import lists -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 805 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20070710/ef9c17ff/attachment.bin From naesten at gmail.com Tue Jul 10 13:24:07 2007 From: naesten at gmail.com (Samuel Bronson) Date: Tue Jul 10 13:17:59 2007 Subject: [jhc] darcs patch: Make Foreign.StablePtr not depend on Prelude Message-ID: Mon Jul 9 23:43:49 EDT 2007 Samuel Bronson * Make Foreign.StablePtr not depend on Prelude -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 956 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20070710/d03f5268/attachment.bin From john at repetae.net Tue Jul 10 15:38:36 2007 From: john at repetae.net (John Meacham) Date: Tue Jul 10 15:32:07 2007 Subject: [jhc] darcs patch: Make Foreign.StablePtr not depend on Prelude In-Reply-To: References: Message-ID: <20070710193836.GA20864@momenergy.repetae.net> On Tue, Jul 10, 2007 at 01:24:07PM -0400, Samuel Bronson wrote: > Mon Jul 9 23:43:49 EDT 2007 Samuel Bronson > * Make Foreign.StablePtr not depend on Prelude Thanks, patch applied. John -- John Meacham - ?repetae.net?john? From john at repetae.net Tue Jul 10 15:38:55 2007 From: john at repetae.net (John Meacham) Date: Tue Jul 10 15:32:31 2007 Subject: [jhc] darcs patch: Allow empty import lists In-Reply-To: References: Message-ID: <20070710193855.GB20864@momenergy.repetae.net> Thanks! patch applied. John -- John Meacham - ?repetae.net?john? From naesten at gmail.com Tue Jul 10 18:10:58 2007 From: naesten at gmail.com (Samuel Bronson) Date: Tue Jul 10 18:04:48 2007 Subject: [jhc] darcs patch: Dump dependancy graph to scc_graph.dot with -dscc-modules Message-ID: Tue Jul 10 18:06:35 EDT 2007 Samuel Bronson * Dump dependancy graph to scc_graph.dot with -dscc-modules This probably isn't the best option or the best filename or anything, but it seems like it would be handy for untangling Prelude (and user code) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 1851 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20070710/a0c77158/attachment.bin From naesten at gmail.com Tue Jul 10 18:25:29 2007 From: naesten at gmail.com (Samuel Bronson) Date: Tue Jul 10 18:18:59 2007 Subject: [jhc] Jhc's tangled base Message-ID: Jhc's Prelude seems to be at the center of a giant tangle (SCC) of modules. This tangle of modules takes a *lot* of resources to compile -- I might possibly have gotten it to typecheck once. What's the plan for dealing with it? It almost makes me like GHC's way :-(. It seems like a lot of code would need to be moved to remove more than a couple of modules from the SCC... One problem is that the code to implement Read and Show pulls in Numeric and the list functions currently in Prelude, which pull in a whole bunch of other stuff... including Foreign.Marshal.Utils, Foreign.Marshal.Alloc, Foreign.Ptr, and lots more... Actually, I think the list functions from Prelude could escape the tangle if Maybe didn't derive Read... From john at repetae.net Tue Jul 10 18:56:01 2007 From: john at repetae.net (John Meacham) Date: Tue Jul 10 18:49:33 2007 Subject: [jhc] Jhc's tangled base In-Reply-To: References: Message-ID: <20070710225601.GA31206@momenergy.repetae.net> On Tue, Jul 10, 2007 at 06:25:29PM -0400, Samuel Bronson wrote: > Jhc's Prelude seems to be at the center of a giant tangle (SCC) of > modules. This tangle of modules takes a *lot* of resources to compile > -- I might possibly have gotten it to typecheck once. What's the plan > for dealing with it? It almost makes me like GHC's way :-(. It seems > like a lot of code would need to be moved to remove more than a couple > of modules from the SCC... Yes, this is a known issue and has been getting better with each release. I don't want to make major changes just yet, as the complete rewrite of how numerics will work will change everything. (and has already started to) > One problem is that the code to implement Read and Show pulls in > Numeric and the list functions currently in Prelude, which pull in a > whole bunch of other stuff... including Foreign.Marshal.Utils, > Foreign.Marshal.Alloc, Foreign.Ptr, and lots more... > > Actually, I think the list functions from Prelude could escape the > tangle if Maybe didn't derive Read... Yeah, it is a little subtle how to rearrange things properly. another thing is I eventually want to create a smaller 'core' library jhc-foo which will just have the minimum required to compile anything with jhc. which is a lot less than it used to be actually, now that I am getting rid of 'magic' names known by the compiler and actually doing things in the source code. In any case, I don't want to tackle this until separate compilation is working as that will likely change the issues and I don't want to work on two major changes to the same subsystem at once. Also, on a philosophical note, ideally I would just make jhc compile things a whole lot faster rather than try to give it less to compile :) John -- John Meacham - ?repetae.net?john? From naesten at gmail.com Tue Jul 10 19:18:27 2007 From: naesten at gmail.com (Samuel Bronson) Date: Tue Jul 10 19:11:58 2007 Subject: [jhc] Jhc's tangled base In-Reply-To: <20070710225601.GA31206@momenergy.repetae.net> References: <20070710225601.GA31206@momenergy.repetae.net> Message-ID: On 7/10/07, John Meacham wrote: > On Tue, Jul 10, 2007 at 06:25:29PM -0400, Samuel Bronson wrote: > > Jhc's Prelude seems to be at the center of a giant tangle (SCC) of > > modules. This tangle of modules takes a *lot* of resources to compile > > -- I might possibly have gotten it to typecheck once. What's the plan > > for dealing with it? It almost makes me like GHC's way :-(. It seems > > like a lot of code would need to be moved to remove more than a couple > > of modules from the SCC... > > Yes, this is a known issue and has been getting better with each > release. I don't want to make major changes just yet, as the complete > rewrite of how numerics will work will change everything. (and has > already started to) > > > One problem is that the code to implement Read and Show pulls in > > Numeric and the list functions currently in Prelude, which pull in a > > whole bunch of other stuff... including Foreign.Marshal.Utils, > > Foreign.Marshal.Alloc, Foreign.Ptr, and lots more... > > > > Actually, I think the list functions from Prelude could escape the > > tangle if Maybe didn't derive Read... > > Yeah, it is a little subtle how to rearrange things properly. another > thing is I eventually want to create a smaller 'core' library jhc-foo > which will just have the minimum required to compile anything with jhc. > which is a lot less than it used to be actually, now that I am getting > rid of 'magic' names known by the compiler and actually doing things in > the source code. > > In any case, I don't want to tackle this until separate compilation is > working as that will likely change the issues and I don't want to work > on two major changes to the same subsystem at once. I'm not quite sure how better seperate compilation will help to compile such a gigantic "module" as this... I suppose it can't hurt, though ;-). > Also, on a philosophical note, ideally I would just make jhc compile > things a whole lot faster rather than try to give it less to compile :) It doesn't really matter what algorithm you use if you spend all your time waiting for swapping ;-). Though, I suppose you could maybe find an algorithm with good enough locality of reference that it would be nice and snappy. From naesten at gmail.com Fri Jul 13 17:03:27 2007 From: naesten at gmail.com (Samuel Bronson) Date: Fri Jul 13 16:57:44 2007 Subject: [jhc] darcs patch: Get pure foreign exports through E... Gr... (and 6 more) Message-ID: Fri Jul 6 18:56:11 EDT 2007 Samuel Bronson * Get pure foreign exports through E... Grin forgets them though Sat Jul 7 16:43:26 EDT 2007 Samuel Bronson * Implement foreign exports returning IO () (clumsily) Mon Jul 9 19:38:11 EDT 2007 Samuel Bronson * Yay! "foreign export", really working! Fri Jul 13 13:56:44 EDT 2007 Samuel Bronson * Rollback Grin.Val.convertName Fri Jul 13 13:57:31 EDT 2007 Samuel Bronson * Document lookupCType/lookupCType' Fri Jul 13 16:34:35 EDT 2007 Samuel Bronson * Fix up "foreign export" support in E.FromHs Fri Jul 13 16:48:22 EDT 2007 Samuel Bronson * Excorcize trace calls -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 15215 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20070713/322292a0/attachment.bin From naesten at gmail.com Fri Jul 13 23:03:51 2007 From: naesten at gmail.com (Samuel Bronson) Date: Fri Jul 13 22:57:58 2007 Subject: [jhc] darcs patch: Document lookupCType/lookupCType' (and 1 more) Message-ID: Fri Jul 13 13:57:31 EDT 2007 Samuel Bronson * Document lookupCType/lookupCType' Fri Jul 13 23:00:50 EDT 2007 Samuel Bronson * Implement "foreign export" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 8467 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20070713/dc77b394/attachment-0001.bin From naesten at gmail.com Sun Jul 15 13:01:58 2007 From: naesten at gmail.com (Samuel Bronson) Date: Sun Jul 15 12:55:12 2007 Subject: [jhc] foreign import "wrapper" Message-ID: On IRC, you (JohnMeacham) (what -- there is someone else who reads this list?) said something about region inference and foreign import "wrapper". It just occured to me earlier today that you probably can't do much of that at all. You can basically do as much as you can do for a StablePtr. I remind you that the C functions made by a wrapper stub can be passed to C code and held there indefinately, just like a StablePtr, and can only be deallocated when the Haskell program calls freeHaskellFunPtr on them. We also talked about how a nice way to implement these wrapper stubs, by generating tiny thunks that would redirect calls to an evaluation routine after adding the closure to be called as an additional argument. (Actually, I suppose the evaluation routine would need a wrapper, like a foreign export does...). What I'm not sure about is how to refer to the address of the (wrapper around the) evaluation routine in the code for the "wrapper stub" (the function that is actually declared by the 'foreign import "wrapper"' declaration). From isaacdupree at charter.net Sun Jul 15 15:02:53 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Sun Jul 15 14:57:34 2007 Subject: [jhc] foreign import "wrapper" In-Reply-To: References: Message-ID: <469A6F5D.1050401@charter.net> Samuel Bronson wrote: > On IRC, you (JohnMeacham) (what -- there is someone else who reads > this list?) Yes! I find myself a little busy with GoboLinux, other haskell development, and real-life things (if you can call preparing for college "real life"!), but this is the one mailing list for which I have read every message ever posted in it ;-) Isaac From naur at post11.tele.dk Sun Jul 15 15:05:14 2007 From: naur at post11.tele.dk (Thorkil Naur) Date: Sun Jul 15 15:01:58 2007 Subject: [jhc] foreign import "wrapper" In-Reply-To: <469A6F5D.1050401@charter.net> References: <469A6F5D.1050401@charter.net> Message-ID: <200707152105.18389.naur@post11.tele.dk> Hello, On Sunday 15 July 2007 21:02, Isaac Dupree wrote: > ... this is the one mailing list for which I have read > every message ever posted in it ;-) > ... Ditto ... And with this avalanche of messages, I guess we will start discussing how to limit the volume, split into various sub-lists etc. (Just Joking.) Best regards Thorkil From john at repetae.net Mon Jul 16 17:37:34 2007 From: john at repetae.net (John Meacham) Date: Mon Jul 16 17:30:46 2007 Subject: [jhc] foreign import "wrapper" In-Reply-To: References: Message-ID: <20070716213734.GA3517@momenergy.repetae.net> On Sun, Jul 15, 2007 at 01:01:58PM -0400, Samuel Bronson wrote: > On IRC, you (JohnMeacham) (what -- there is someone else who reads > this list?) said something about region inference and foreign import > "wrapper". It just occured to me earlier today that you probably can't > do much of that at all. You can basically do as much as you can do for > a StablePtr. I remind you that the C functions made by a wrapper stub > can be passed to C code and held there indefinately, just like a > StablePtr, and can only be deallocated when the Haskell program calls > freeHaskellFunPtr on them. Yes, the region inference algorithm would have to do an 'escape analysis' to deterime which references escape the current frame. luckily, this is already inherent to the analysis, data stored in stableptrs or foreign wrapper imports will be noticed at this point. > We also talked about how a nice way to implement these wrapper stubs, > by generating tiny thunks that would redirect calls to an evaluation > routine after adding the closure to be called as an additional > argument. (Actually, I suppose the evaluation routine would need a > wrapper, like a foreign export does...). What I'm not sure about is > how to refer to the address of the (wrapper around the) evaluation > routine in the code for the "wrapper stub" (the function that is > actually declared by the 'foreign import "wrapper"' declaration). here is what I am thinking foreign import wrapper mkFoo :: (Int -> Int) -> IO (FunPtr (Int -> Int)) will create the following: > -- this just translates a haskell function into an unboxed version. > -- nothing tricky here. > unboxMkFoo :: (Int -> Int) -> (Int__ -> Int__) > unboxMkFoo fn = \x -> unbox (fn (box x)) > > > -- psuedo-import of real C function, note we take a function as > -- an argument, which is not legal haskell, but is fine, we will > -- just expect the C function to take a pointer to a haskell heap > -- object. > > foreign import ccall c_mkFoo :: (Int__ -> Int__) -> IO Addr__ > > -- this is the final user visible mkFoo function > mkFoo fn = c_mkFoo (unboxMkFoo fn) > > -- and generate a c_mkFoo as follows > > HsFunPtr c_mkFoo(node_t *n) { > char *code = asm ("push n; call apply_int_int"); > return (HsFunPtr)code; > } I hope this is clear, I used some constructs in ways that arn't legal haskell, but are expressible in core and grin so the meaning should be clear. you should call the appropriate 'apply' routine, but these are already generated, if you need to use a special calling convention (like passing the node in a register) then another stub might be needed rather than calling apply directly. John -- John Meacham - ?repetae.net?john? From naesten at gmail.com Mon Jul 16 18:17:43 2007 From: naesten at gmail.com (Samuel Bronson) Date: Mon Jul 16 18:12:04 2007 Subject: [jhc] darcs patch: Be more specific about monadic imports, for compatibil... Message-ID: Mon Jul 16 18:15:45 EDT 2007 Samuel Bronson * Be more specific about monadic imports, for compatibility (especially 6.6/6.6.1) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 2471 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20070716/d7512e5d/attachment.bin From naesten at gmail.com Mon Jul 16 18:36:08 2007 From: naesten at gmail.com (Samuel Bronson) Date: Mon Jul 16 18:29:19 2007 Subject: [jhc] foreign import "wrapper" In-Reply-To: <20070716213734.GA3517@momenergy.repetae.net> References: <20070716213734.GA3517@momenergy.repetae.net> Message-ID: On 7/16/07, John Meacham wrote: > here is what I am thinking > > foreign import wrapper mkFoo :: (Int -> Int) -> IO (FunPtr (Int -> Int)) > > will create the following: > > > -- this just translates a haskell function into an unboxed version. > > -- nothing tricky here. > > unboxMkFoo :: (Int -> Int) -> (Int__ -> Int__) > > unboxMkFoo fn = \x -> unbox (fn (box x)) > > > > > > -- psuedo-import of real C function, note we take a function as > > -- an argument, which is not legal haskell, but is fine, we will > > -- just expect the C function to take a pointer to a haskell heap > > -- object. > > > > foreign import ccall c_mkFoo :: (Int__ -> Int__) -> IO Addr__ > > > > -- this is the final user visible mkFoo function > > mkFoo fn = c_mkFoo (unboxMkFoo fn) > > > > -- and generate a c_mkFoo as follows > > > > HsFunPtr c_mkFoo(node_t *n) { > > char *code = asm ("push n; call apply_int_int"); > > return (HsFunPtr)code; > > } > > > I hope this is clear, I used some constructs in ways that arn't legal > haskell, but are expressible in core and grin so the meaning should be > clear. you should call the appropriate 'apply' routine, but these are > already generated, if you need to use a special calling convention (like > passing the node in a register) then another stub might be needed rather > than calling apply directly. And apply_* is okay with having a return address between it's first and second arguments? Also... how am I supposed to name the C function safely? Just underscore-encode "c_"++show n (where n is the name being imported to)? and ... the all-important issue of where to *put* the C function, keeping in mind that cDecl returns a list of triples that represents toplevel bindings in the E program? From naesten at gmail.com Tue Jul 17 18:20:01 2007 From: naesten at gmail.com (Samuel J.J.Bronson) Date: Tue Jul 17 18:18:14 2007 Subject: [jhc] Typechecker hiccup? Message-ID: I just tried to compile this program (based on figure one in "The GRIN Project: A Highly Optimising Back End for Lazy Functional Languages"): {-# OPTIONS_JHC -N -fffi #-} import Jhc.Basics import Jhc.Int import Jhc.Num import Jhc.Order default (Integer, Double) main = sum (upto 1 10) upto m n | m > n = [] | otherwise = m : upto (m+1) n sum [] = 0 sum (x:xs) = x + sum xs And I got a stupid error about a missing "put" method for IORef. It seems that the typechecker isn't getting rid of all the MetaVars in this program... From john at repetae.net Tue Jul 17 18:32:44 2007 From: john at repetae.net (John Meacham) Date: Tue Jul 17 18:25:51 2007 Subject: [jhc] Typechecker hiccup? In-Reply-To: References: Message-ID: <20070717223244.GA19427@momenergy.repetae.net> On Tue, Jul 17, 2007 at 10:20:01PM +0000, Samuel J. J. Bronson wrote: > I just tried to compile this program (based on figure one in "The GRIN Project: > A Highly Optimising Back End for Lazy Functional Languages"): > > > {-# OPTIONS_JHC -N -fffi #-} > > import Jhc.Basics > import Jhc.Int > import Jhc.Num > import Jhc.Order > > default (Integer, Double) > > main = sum (upto 1 10) > > upto m n | m > n = [] > | otherwise = m : upto (m+1) n > > sum [] = 0 > sum (x:xs) = x + sum xs > > > And I got a stupid error about a missing "put" method for IORef. It seems that > the typechecker isn't getting rid of all the MetaVars in this program... hmm.. main not being an actual IO action doesn't behave too well with overloading. (I really should make it just fail without an explicit option saying you want to evaluate an expression) what if you change main to main = print (sum (upto 1 10)) it would be nice if main were specialized to IO foo also. like main = return () will fail because it doesn't know to unify it with 'IO a'. though, I wouldn't want to do this in the typechecker, but rather when the entry point is created after E conversion. John -- John Meacham - ?repetae.net?john? From naesten at gmail.com Wed Jul 18 10:45:19 2007 From: naesten at gmail.com (Samuel Bronson) Date: Wed Jul 18 10:38:24 2007 Subject: [jhc] Typechecker hiccup? In-Reply-To: <20070717223244.GA19427@momenergy.repetae.net> References: <20070717223244.GA19427@momenergy.repetae.net> Message-ID: On 7/17/07, John Meacham wrote: > On Tue, Jul 17, 2007 at 10:20:01PM +0000, Samuel J. J. Bronson wrote: > > I just tried to compile this program (based on figure one in "The GRIN Project: > > A Highly Optimising Back End for Lazy Functional Languages"): > > > > > > {-# OPTIONS_JHC -N -fffi #-} > > > > import Jhc.Basics > > import Jhc.Int > > import Jhc.Num > > import Jhc.Order > > > > default (Integer, Double) > > > > main = sum (upto 1 10) > > > > upto m n | m > n = [] > > | otherwise = m : upto (m+1) n > > > > sum [] = 0 > > sum (x:xs) = x + sum xs > > > > > > And I got a stupid error about a missing "put" method for IORef. It seems that > > the typechecker isn't getting rid of all the MetaVars in this program... > > hmm.. main not being an actual IO action doesn't behave too well with > overloading. (I really should make it just fail without an explicit > option saying you want to evaluate an expression) I don't really want the code to work... I just want it to get a proper error. Also it's taking forever to compile the Prelude -- it's been compiling all night and it's still on the same line of output as when I went to bed... (I suspect that it would be on a different character if I hadn't piped it through tee and less, though). I'd be happy with an error from the typechecker, an error from E.FromHs, an error from an E pass... pretty much anything before it's trying to write an .ho file ;-). From john at repetae.net Wed Jul 18 18:48:32 2007 From: john at repetae.net (John Meacham) Date: Wed Jul 18 18:41:37 2007 Subject: [jhc] Typechecker hiccup? In-Reply-To: References: <20070717223244.GA19427@momenergy.repetae.net> Message-ID: <20070718224832.GA8506@momenergy.repetae.net> On Wed, Jul 18, 2007 at 09:45:19AM -0500, Samuel Bronson wrote: > On 7/17/07, John Meacham wrote: > >On Tue, Jul 17, 2007 at 10:20:01PM +0000, Samuel J. J. Bronson wrote: > >> I just tried to compile this program (based on figure one in "The GRIN > >Project: > >> A Highly Optimising Back End for Lazy Functional Languages"): > >> > >> > >> {-# OPTIONS_JHC -N -fffi #-} > >> > >> import Jhc.Basics > >> import Jhc.Int > >> import Jhc.Num > >> import Jhc.Order > >> > >> default (Integer, Double) > >> > >> main = sum (upto 1 10) > >> > >> upto m n | m > n = [] > >> | otherwise = m : upto (m+1) n > >> > >> sum [] = 0 > >> sum (x:xs) = x + sum xs > >> > >> > >> And I got a stupid error about a missing "put" method for IORef. It > >seems that > >> the typechecker isn't getting rid of all the MetaVars in this program... > > > >hmm.. main not being an actual IO action doesn't behave too well with > >overloading. (I really should make it just fail without an explicit > >option saying you want to evaluate an expression) > > I don't really want the code to work... I just want it to get a proper > error. Oh, yeah. that is what I meant to say. I just got sidetracked. In general, a lot of things that should be errors are not checked for. this can lead to badness later in the compilation process. It is unfortunate that there are still some user errors that are reported via a pattern match failure somewhere in the front end :) (but it is much better than it used to be) >Also it's taking forever to compile the Prelude -- it's been > compiling all night and it's still on the same line of output as when > I went to bed... (I suspect that it would be on a different character > if I hadn't piped it through tee and less, though). Hmm.. this sounds wrong. it is possible there is an infinite loop somewhere. if you compile with some combination of -dcore -dcore-mini -dcore-steps -dcore-pass then you can usually find the culprit in these cases. you will see the same optimizations repeating over and over again. That is usually the cause. Also, 'Show' and 'Read' instances for large data types tickle the simplifer in a way that makes it take way way too long. quadratic or even exponential behavior is sneaking in somewhere. > I'd be happy with an error from the typechecker, an error from > E.FromHs, an error from an E pass... pretty much anything before it's > trying to write an .ho file ;-). yes. certainly. John -- John Meacham - ?repetae.net?john? From naesten at gmail.com Wed Jul 18 19:59:43 2007 From: naesten at gmail.com (Samuel Bronson) Date: Wed Jul 18 19:52:48 2007 Subject: [jhc] Typechecker hiccup? In-Reply-To: <20070718224832.GA8506@momenergy.repetae.net> References: <20070717223244.GA19427@momenergy.repetae.net> <20070718224832.GA8506@momenergy.repetae.net> Message-ID: On 7/18/07, John Meacham wrote: > >Also it's taking forever to compile the Prelude -- it's been > > compiling all night and it's still on the same line of output as when > > I went to bed... (I suspect that it would be on a different character > > if I hadn't piped it through tee and less, though). > > Hmm.. this sounds wrong. it is possible there is an infinite loop > somewhere. if you compile with some combination of -dcore -dcore-mini > -dcore-steps -dcore-pass then you can usually find the culprit in these > cases. you will see the same optimizations repeating over and over > again. That is usually the cause. No, it wasn't an infinite loop. It eventually finished (though it sure took it's time writing the .ho file...). I think basically it has poor locality of reference compiling such a large "module". > Also, 'Show' and 'Read' instances for large data types tickle the > simplifer in a way that makes it take way way too long. quadratic or > even exponential behavior is sneaking in somewhere. That doesn't surprise me.