From duncan.coutts at worc.ox.ac.uk Fri Jun 1 05:23:05 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Jun 1 05:18:46 2007 Subject: [C2hs] patch applied (c2hs): Don't include the CHeader in the AttrC Message-ID: <20070601092305.GA21503@cvs.haskell.org> Thu May 31 10:09:38 PDT 2007 Duncan Coutts * Don't include the CHeader in the AttrC AttrC should be accumulated from a sequence of external definitions rather than containing the whole CHeader from the beinning. This should make processing partial translation units easier. M ./c2hs/c/C.hs -6 +4 M ./c2hs/c/CAttrs.hs -17 +10 M ./c2hs/c/CNames.hs -9 +8 M ./c2hs/c/CTrav.hs -7 +2 From duncan.coutts at worc.ox.ac.uk Fri Jun 1 05:23:07 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Jun 1 05:18:46 2007 Subject: [C2hs] patch applied (c2hs): Remove CVS $Revision and $Date tags Message-ID: <20070601092307.GA21524@cvs.haskell.org> Thu May 31 10:25:06 PDT 2007 Duncan Coutts * Remove CVS $Revision and $Date tags they are not used by darcs so are out of date and are thus useless M ./base/errors/Errors.hs -2 M ./base/general/Position.hs -2 M ./base/general/UNames.hs -2 M ./base/state/CIO.hs -2 M ./base/state/State.hs -2 M ./base/state/StateBase.hs -2 M ./base/state/StateTrans.hs -2 M ./base/state/tests/Main.hs -2 M ./base/syms/Attributes.hs -2 M ./base/syms/Idents.hs -2 M ./base/syms/NameSpaces.hs -2 M ./base/syms/tests/Main.hs -2 M ./base/syntax/Lexers.hs -2 M ./c2hs/c/C.hs -2 M ./c2hs/c/CAST.hs -2 M ./c2hs/c/CAttrs.hs -2 M ./c2hs/c/CBuiltin.hs -2 M ./c2hs/c/CLexer.x -2 M ./c2hs/c/CNames.hs -2 M ./c2hs/c/CPretty.hs -2 M ./c2hs/c/CTokens.hs -2 M ./c2hs/c/CTrav.hs -2 M ./c2hs/chs/CHS.hs -2 M ./c2hs/chs/CHSLexer.hs -2 M ./c2hs/examples/libghttpHS/Ghttp.chs -2 M ./c2hs/examples/libghttpHS/Makefile -2 M ./c2hs/gen/CInfo.hs -2 M ./c2hs/gen/GBMonad.hs -2 M ./c2hs/gen/GenHeader.hs -2 M ./c2hs/state/C2HSState.hs -2 M ./c2hs/state/Switches.hs -2 M ./c2hs/toplevel/C2HSConfig.hs -2 M ./c2hs/toplevel/c2hs_config.c -2 M ./c2hs/toplevel/c2hs_config.h -2 From duncan.coutts at worc.ox.ac.uk Fri Jun 1 12:42:28 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Jun 1 12:38:08 2007 Subject: [C2hs] patch applied (c2hs): Simplify Ident representation and construction Message-ID: <20070601164228.GA3003@cvs.haskell.org> Fri Jun 1 08:01:55 PDT 2007 Duncan Coutts * Simplify Ident representation and construction The ambiguousness resolving number was not being utilised at all in c2hs so I have removed it. Similarly the parsing of lexemes was unnecessary for C identifiers and simplifying it makes the parser >10% faster. Also removed all the unused functions (of which there were many). M ./base/syms/Idents.hs -238 +18 From bringert at cs.chalmers.se Fri Jun 1 12:43:00 2007 From: bringert at cs.chalmers.se (=?ISO-8859-1?Q?Bj=F6rn_Bringert?=) Date: Fri Jun 1 12:38:11 2007 Subject: [C2hs] Passing extra arguments to marshalling functions Message-ID: <46604C94.4000008@cs.chalmers.se> I have a function for checking return values of functions: checkResult :: String -> CInt -> IO () checkResult _ 0 = return () checkResult f n = fail $ f ++ " failed (" ++ show n ++ ")" Now, I want to call that on the exit value of lots of functions, like this: {#fun foo {} -> `()' `checkResult "foo"'*- #} {#fun bar {} -> `()' `checkResult "bar"'*- #} ... However, the marshallers can only be function names, not arbitrary expressions. Wouldn't it be a useful generalization to allow arbitrary expressions as marshallers? That way you could even have one-off marshallers as lambda expressions. /Bj?rn From bringert at cs.chalmers.se Sat Jun 2 12:18:11 2007 From: bringert at cs.chalmers.se (=?ISO-8859-1?Q?Bj=F6rn_Bringert?=) Date: Sat Jun 2 12:13:12 2007 Subject: [C2hs] Trac ticket spam Message-ID: <46619843.1060809@cs.chalmers.se> The c2hs Trac seems to have a lot of spam in it, for example http://hackage.haskell.org/trac/c2hs/ticket/11 /Bj?rn From bringert at cs.chalmers.se Sat Jun 2 12:31:48 2007 From: bringert at cs.chalmers.se (=?ISO-8859-1?Q?Bj=F6rn_Bringert?=) Date: Sat Jun 2 12:26:49 2007 Subject: [C2hs] Feature request: #pointer should add Storable instance Message-ID: <46619B74.3050904@cs.chalmers.se> I'll just keep spamming this list with features I'm missing. I use #pointer to create newtypes, but I'm missing Storable instances for the produced newtypes. It's very nice to be able to use alloca, peek etc for passing pointers around. Even GHC can't derive Storable since the type is recursive, but it's easy to write the instance. Here's what I do now: {#pointer *SWIrecRecognizer as RecRecognizer newtype #} instance Storable RecRecognizer where sizeOf (RecRecognizer r) = sizeOf r alignment (RecRecognizer r) = alignment r peek p = fmap RecRecognizer (peek (castPtr p)) poke p (RecRecognizer r) = poke (castPtr p) r c2hs could easily produce that Storable instance, and I can't see any reason not to. /Bj?rn From chak at cse.unsw.edu.au Sun Jun 3 23:40:50 2007 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sun Jun 3 23:36:26 2007 Subject: [C2hs] Passing extra arguments to marshalling functions In-Reply-To: <46604C94.4000008@cs.chalmers.se> References: <46604C94.4000008@cs.chalmers.se> Message-ID: <466389C2.20707@cse.unsw.edu.au> Bj?rn, > I have a function for checking return values of functions: > > checkResult :: String -> CInt -> IO () > checkResult _ 0 = return () > checkResult f n = fail $ f ++ " failed (" ++ show n ++ ")" > > Now, I want to call that on the exit value of lots of functions, like this: > > {#fun foo > {} > -> `()' `checkResult "foo"'*- #} > > {#fun bar > {} > -> `()' `checkResult "bar"'*- #} > > ... > > However, the marshallers can only be function names, not arbitrary > expressions. Wouldn't it be a useful generalization to allow arbitrary > expressions as marshallers? That way you could even have one-off > marshallers as lambda expressions. Yes I thought about having something like that. On the other hand, its also quite easy to just follow the fun hook with a where clause that introduces a name for the marshalling expression, but I admit that if its just a partial application, as in your case, even a where clause is somewhat tedious in comparison. Do you want to try adding this to c2hs? I'd be happy to include a suitable patch. Cheers, Manuel From duncan.coutts at worc.ox.ac.uk Mon Jun 4 06:39:40 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Jun 4 06:34:23 2007 Subject: [C2hs] Feature request: #pointer should add Storable instance In-Reply-To: <46619B74.3050904@cs.chalmers.se> References: <46619B74.3050904@cs.chalmers.se> Message-ID: <1180953580.6210.71.camel@localhost> On Sat, 2007-06-02 at 18:31 +0200, Bj?rn Bringert wrote: > I'll just keep spamming this list with features I'm missing. I use > #pointer to create newtypes, but I'm missing Storable instances for the > produced newtypes. It's very nice to be able to use alloca, peek etc for > passing pointers around. > > Even GHC can't derive Storable since the type is recursive, but it's > easy to write the instance. Here's what I do now: > > {#pointer *SWIrecRecognizer as RecRecognizer newtype #} > > instance Storable RecRecognizer where > sizeOf (RecRecognizer r) = sizeOf r > alignment (RecRecognizer r) = alignment r > peek p = fmap RecRecognizer (peek (castPtr p)) > poke p (RecRecognizer r) = poke (castPtr p) r > > c2hs could easily produce that Storable instance, and I can't see any > reason not to. So this gives it a storable instance that interprets the newtype as a pointer, but not as the thing pointed to? (which would be the usual interpretation right?) I'm not sure I understand why you would want this, and even if you did it'd prevent people doing the more normal Storable instance for the thing pointed to. I'm clearly missing something here. Duncan From bringert at cs.chalmers.se Mon Jun 4 07:31:21 2007 From: bringert at cs.chalmers.se (=?UTF-8?B?QmrDtnJuIEJyaW5nZXJ0?=) Date: Mon Jun 4 07:26:06 2007 Subject: [C2hs] Feature request: #pointer should add Storable instance In-Reply-To: <1180953580.6210.71.camel@localhost> References: <46619B74.3050904@cs.chalmers.se> <1180953580.6210.71.camel@localhost> Message-ID: <4663F809.4070304@cs.chalmers.se> Duncan Coutts wrote: > On Sat, 2007-06-02 at 18:31 +0200, Bj?rn Bringert wrote: >> I'll just keep spamming this list with features I'm missing. I use >> #pointer to create newtypes, but I'm missing Storable instances for the >> produced newtypes. It's very nice to be able to use alloca, peek etc for >> passing pointers around. >> >> Even GHC can't derive Storable since the type is recursive, but it's >> easy to write the instance. Here's what I do now: >> >> {#pointer *SWIrecRecognizer as RecRecognizer newtype #} >> >> instance Storable RecRecognizer where >> sizeOf (RecRecognizer r) = sizeOf r >> alignment (RecRecognizer r) = alignment r >> peek p = fmap RecRecognizer (peek (castPtr p)) >> poke p (RecRecognizer r) = poke (castPtr p) r >> >> c2hs could easily produce that Storable instance, and I can't see any >> reason not to. > > So this gives it a storable instance that interprets the newtype as a > pointer, but not as the thing pointed to? (which would be the usual > interpretation right?) I'm not sure I understand why you would want > this, and even if you did it'd prevent people doing the more normal > Storable instance for the thing pointed to. I'm clearly missing > something here. My main motivation for this is to be able to work with out-parameters which return these pointers. For example, I want to use a function like this one: int SWIrecRecognizerCreate (SWIrecRecognizer **rec); This function returns a pointer to the abstract type SWIrecRecognizer, by using an out-parameter. I want to be able to use this #fun declaration for it: {#fun recRecognizerCreate { alloca- `RecRecognizer' peek*} -> `Int' #} Without the Storable instance, I would have to do something like this (not tested): {#fun recRecognizerCreate { allocaRecRecognizer- `RecRecognizer' peekRecRecognizer*} -> `Int' #} where allocaRecRecognizer = allocaBytes {#sizeof RecRecognizer} peekRecRecognizer = liftM (RecRecognizer . castPtr) . peek My interpretation was that #pointer is used for abstract types whose internals you don't mess with from Haskell, but just pass around. Thus, the only thing you want to do with them is to store and retrieve the pointers, not the pointed-to objects. Maybe that's not always true, and in that case, producing a Storable instance like the above is wrong. It would be nice to have the option to do it though. /Bj?rn From bringert at cs.chalmers.se Mon Jun 4 09:59:28 2007 From: bringert at cs.chalmers.se (=?UTF-8?B?QmrDtnJuIEJyaW5nZXJ0?=) Date: Mon Jun 4 09:54:11 2007 Subject: [C2hs] Feature request: #pointer should add Storable instance In-Reply-To: <4663F809.4070304@cs.chalmers.se> References: <46619B74.3050904@cs.chalmers.se> <1180953580.6210.71.camel@localhost> <4663F809.4070304@cs.chalmers.se> Message-ID: <46641AC0.2090002@cs.chalmers.se> Bj?rn Bringert wrote: > Duncan Coutts wrote: >> On Sat, 2007-06-02 at 18:31 +0200, Bj?rn Bringert wrote: >>> I'll just keep spamming this list with features I'm missing. I use >>> #pointer to create newtypes, but I'm missing Storable instances for >>> the produced newtypes. It's very nice to be able to use alloca, peek >>> etc for passing pointers around. >>> >>> Even GHC can't derive Storable since the type is recursive, but it's >>> easy to write the instance. Here's what I do now: >>> >>> {#pointer *SWIrecRecognizer as RecRecognizer newtype #} >>> >>> instance Storable RecRecognizer where >>> sizeOf (RecRecognizer r) = sizeOf r >>> alignment (RecRecognizer r) = alignment r >>> peek p = fmap RecRecognizer (peek (castPtr p)) >>> poke p (RecRecognizer r) = poke (castPtr p) r >>> >>> c2hs could easily produce that Storable instance, and I can't see any >>> reason not to. >> >> So this gives it a storable instance that interprets the newtype as a >> pointer, but not as the thing pointed to? (which would be the usual >> interpretation right?) I'm not sure I understand why you would want >> this, and even if you did it'd prevent people doing the more normal >> Storable instance for the thing pointed to. I'm clearly missing >> something here. > > My main motivation for this is to be able to work with out-parameters > which return these pointers. For example, I want to use a function like > this one: > > int SWIrecRecognizerCreate (SWIrecRecognizer **rec); > > This function returns a pointer to the abstract type SWIrecRecognizer, > by using an out-parameter. I want to be able to use this #fun > declaration for it: > > {#fun recRecognizerCreate > { alloca- `RecRecognizer' peek*} -> `Int' #} > > Without the Storable instance, I would have to do something like this > (not tested): > > {#fun recRecognizerCreate > { allocaRecRecognizer- `RecRecognizer' peekRecRecognizer*} -> `Int' #} > where allocaRecRecognizer = allocaBytes {#sizeof RecRecognizer} > peekRecRecognizer = liftM (RecRecognizer . castPtr) . peek > > > My interpretation was that #pointer is used for abstract types whose > internals you don't mess with from Haskell, but just pass around. Thus, > the only thing you want to do with them is to store and retrieve the > pointers, not the pointed-to objects. Maybe that's not always true, and > in that case, producing a Storable instance like the above is wrong. It > would be nice to have the option to do it though. > > /Bj?rn Hmm, I may be silly. Sometimes you want to allocate space for abstract objects in Haskell code, and pass that to C code. Then you need a sizeOf for the pointed-to object, not the pointer. I'll have to get back to you on this. /Bj?rn From duncan.coutts at worc.ox.ac.uk Mon Jun 4 11:02:20 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Jun 4 10:57:51 2007 Subject: [C2hs] patch applied (c2hs): Change the interpretation of --output and --output-dir slightly Message-ID: <20070604150220.GA31202@cvs.haskell.org> Mon Jun 4 07:56:52 PDT 2007 Duncan Coutts * Change the interpretation of --output and --output-dir slightly To make it work better with Cabal. It's best explained by example: For --output=Foo/Bar.hs --output-dir=dist, the final file name is now dist/Foo/Bar.hs rather than dist/Bar.hs as before. Also, the .h file referred to in Bar.hs is now just "Foo/Bar.chs.h". That is, it is relative to the output file name, not with the extra output-dir prefix. This works much better with Cabal's build scheme, where generated files go into dist, and the root of the build tree is not searched for .h files instead we only have to -Idist, ie search the dir where we generated all the .chs.h files. M ./c2hs/toplevel/Main.hs -17 +10 From bringert at cs.chalmers.se Sun Jun 10 18:53:56 2007 From: bringert at cs.chalmers.se (Bjorn Bringert) Date: Sun Jun 10 18:47:34 2007 Subject: [C2hs] Storable (Maybe a) leaks memory? Message-ID: <5B0F661A-B63C-4370-89D8-86BCF8CFA334@cs.chalmers.se> In the C2HS.hs which is generated by 'c2hs -l', I found this code: instance Storable a => Storable (Maybe a) where sizeOf _ = sizeOf (undefined :: Ptr ()) alignment _ = alignment (undefined :: Ptr ()) peek p = do ptr <- peek (castPtr p) if ptr == nullPtr then return Nothing else liftM Just $ peek ptr poke p v = do ptr <- case v of Nothing -> return nullPtr Just v' -> new v' poke (castPtr p) ptr In the poke implementation, 'Foreign.Marshal.Utils.new' is used. 'new' uses malloc, and would thus most likely lead to memory leaks, since the user of this instance probably doesn't know that he needs to free the block pointed to by the written value. Or did I miss something clever here? The best alternative I can see is to restrict it to Storable a => Storable (Maybe (Ptr a)), and skip the call to 'new', but that requires extensions. /Bj?rn From duncan.coutts at worc.ox.ac.uk Wed Jun 13 20:32:18 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Jun 13 20:28:27 2007 Subject: [C2hs] Storable (Maybe a) leaks memory? In-Reply-To: <5B0F661A-B63C-4370-89D8-86BCF8CFA334@cs.chalmers.se> References: <5B0F661A-B63C-4370-89D8-86BCF8CFA334@cs.chalmers.se> Message-ID: <1181781139.5026.34.camel@localhost> On Mon, 2007-06-11 at 00:53 +0200, Bjorn Bringert wrote: > In the C2HS.hs which is generated by 'c2hs -l', I found this code: I'm inclined to remove C2HS.hs completely. Currently c2hs does generate code that uses things in C2HS.hs however it only uses a small subset and those are really simple things that could just be included inline. Duncan