Re: Advice on diagnosing segfaults?

On Mon, 2 Oct 2023, Adrian Cochrane wrote: I've got a segfault in one of the language bindings I'm developing (fontconfig-pure), and I'm struggling to locate it. I could solve some problems in my C library bindings using ltrace. It logs all calls to external C libraries together with the fun

Re: Most efficient way to decode large C array of 32bit words?

I couldn't stop thinking about this, so keeping a close on benchmarks I found my solution:clonePtr ptr l = do    ret <- mallocForeignPtrArray l    withForeignPtr ret $ \ptr' -> copyArray ptr ptr' l    return retpeekLazy fp 0 = []peekLazy fp l = x:peekLazy (fp `plusForeignPtr` 1) (pred l)  wher

Re: [Haskell-cafe] managing embedded structs

On Sun, 28 Aug 2016, Alexey Khudyakov wrote: On 27 August 2016 at 13:23, Henning Thielemann wrote: I want to write a Haskell interface to a C library that provides two data structures A and B, where B is contained in A. That is, if A is freed, then B is automatically freed, too. I don't qu

Re: non-ASCII filepaths in a C function

On Sat, 25 Jul 2015, Malcolm Wallace wrote: I believe the native representation for FilePaths on Windows should be UTF16 strings. Btw. I don't think that soxlib expects UTF16 filepath strings on Windows because it works for purely ASCII filepaths. __

Re: non-ASCII filepaths in a C function

I believe the native representation for FilePaths on Windows should be UTF16 strings. Regards, Malcolm > On 24 Jul 2015, at 22:52, Henning Thielemann > wrote: > > > In my 'soxlib' package I have written a binding to > > sox_format_t * sox_open_read( >char const * path,

Re: allocate memory to Char **

Thank a lot ! it works! Lamine. On 04/29/2014 03:52 PM, Sylvain Henry wrote: To create the [String] as in your example, you just have to write: let names = ["x"++ show i | i <- [0..w-1]] varnames <- mallocList names -Sylvain 2014-04-29 15:40 GMT+02:00 Lamine

Re: allocate memory to Char **

To create the [String] as in your example, you just have to write: let names = ["x"++ show i | i <- [0..w-1]] varnames <- mallocList names -Sylvain 2014-04-29 15:40 GMT+02:00 Lamine : > Hi Sylvain, > thank you for your response! I try to use this 2 lines > > allocaArray (w*n) $ \var -> do >

Re: allocate memory to Char **

Hi Sylvain, thank you for your response! I try to use this 2 lines allocaArray (w*n) $ \var -> do xs <- peekArray (w) var to code char **varnames = ccl_new_array (char *, w); but it return [CString] not a [String] On 04/29/2014 01:58 PM, Sylvain Henry wrote: Hi, "varnames" i

Re: allocate memory to Char **

I try pokeElemOff but i have same error "segmentation fault(core dumped)". Thank for your response! On 04/29/2014 01:30 PM, Henning Thielemann wrote: Am 29.04.2014 13:11, schrieb Lamine: I try this code unsing mallocList to (http://lpaste.net/report/712): mallocList :: [CString] -> IO (Ptr CSt

Re: allocate memory to Char **

Hi, "varnames" is an array of pointers, you cannot allocate it with mallocBytes (n*100). Try something like this (not tested): mallocList :: [String] -> IO (Ptr CString) mallocList xs = newArray =<< forM xs g where g x = do b <- mallocBytes 100 pokeCString b x 99 retur

Re: Foreign.StablePtr: nullPtr & double-free questions.

Excerpts from Remi Turk's message of Wed Mar 13 13:09:18 -0700 2013: > Thanks for your quick reply. Could you elaborate on what "a bit of > overhead" means? > As a bit of context, I'm working on a small library for working with > (im)mutable extendable > tuples/records based on Storable and Foreign

Re: Foreign.StablePtr: nullPtr & double-free questions.

On Sat, Mar 9, 2013 at 6:23 AM, Edward Z. Yang wrote: > Excerpts from Remi Turk's message of Fri Mar 08 18:28:56 -0800 2013: >> 1) The documentation suggests, but does not explicitly state, that >> castStablePtrToPtr `liftM` newStablePtr x >> will never yield a nullPtr. Is this guaranteed to be

Re: Foreign.StablePtr: nullPtr & double-free questions.

Excerpts from Remi Turk's message of Fri Mar 08 18:28:56 -0800 2013: > Good night everyone, > > I have two questions with regards to some details of the > Foreign.StablePtr module. [1] > > 1) The documentation suggests, but does not explicitly state, that > castStablePtrToPtr `liftM` newStableP

Re: Rationale of capi?

On Sun, Oct 07, 2012 at 03:34:45PM +0300, Lauri Alanko wrote: > > In fact, function-like > macros are (or should be) a rarity, since inline functions serve the > same purpose better. > > So to me "capi" seems to buy very little, and it only supports > strangely specific needs. In theory, perhaps

Re: addForeignPtrFinalizer - finalizers run in FIFO or LIFO order?

On Fri, 17 Aug 2012, Edward Z. Yang wrote: No. 1 question: do you have a reproduceable test case of both behaviors? Unfortunately I was not able to reduce it to a small test. Below a certain complexity the problem vanishes. Currently my example has many dependencies on external libraries (l

Re: addForeignPtrFinalizer - finalizers run in FIFO or LIFO order?

No. 1 question: do you have a reproduceable test case of both behaviors? Edward Excerpts from Henning Thielemann's message of Fri Aug 17 08:10:02 -0400 2012: > > The doc of base-4.5:Foreign.ForeignPtr.addForeignPtrFinalizer states: > "This function adds a finalizer to the given foreign objec

Re: addForeignPtrFinalizer - finalizers run in FIFO or LIFO order?

On Fri, 17 Aug 2012, Henning Thielemann wrote: On Fri, 17 Aug 2012, Henning Thielemann wrote: The doc of base-4.5:Foreign.ForeignPtr.addForeignPtrFinalizer states: "This function adds a finalizer to the given foreign object. The finalizer will run before all other finalizers for the same o

Re: addForeignPtrFinalizer - finalizers run in FIFO or LIFO order?

On Fri, 17 Aug 2012, Henning Thielemann wrote: The doc of base-4.5:Foreign.ForeignPtr.addForeignPtrFinalizer states: "This function adds a finalizer to the given foreign object. The finalizer will run before all other finalizers for the same object which have already been registered." I

Re: [FFI] interference of FFI with poll(3)?

Hello Edward, thanks a lot ... this resembles very much to what I am experiencing ... :-) A nice weekend, Nick 2012/4/29 Edward Z. Yang > Hello Nick, > > The GHC runtime system uses alarm signals for a variety of purposes, > and part of this means that your code needs to properly handle > EINT

Re: [FFI] interference of FFI with poll(3)?

Hello Nick, The GHC runtime system uses alarm signals for a variety of purposes, and part of this means that your code needs to properly handle EINTR. Please see: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Signals for more information. Cheers, Edward Excerpts from Nick Rudnick's m

Re: Marshalling C unions

On Wed, 13 Apr 2011, Nabil Alsharif wrote: instance Storable myUnion where size _ = #{size my_union} -- <-- hsc2hs shortcut alignment _ = alignment undefined::CInt -- <-- What should this really be? peek ptr = do -- <-- How are you supposed to know which element to extract? That's

Re: FFI, DLL Linking, Windows Haskell Platform 2010

Thank you very Mr. Thielemann. I got everything working under linux, ghc links to distorm and the library compiles and works. After a little investigation I found out that, under windows, distorm is compiled using MSVC and I had used MSVC to compile the test C program I had written to make sure

Re: don't get a correct memory address at a getter Method

On Fri, Aug 27, 2010 at 11:12 PM, Nick Rudnick wrote: > Hi, > > being new to the FFI, I hope this might have an easy solution: > > The following (GHC 6.12.1), > > -- C++ lib > class A { > public: >    B* getB(){ B* ptr= &b; cerr << "C: " << << endl; return ptr; } > private: >  

Re: Import, how to

I'm a beginner at haskell and ffi. I was trying to import and use is haskell one C function, but I can't manage to do that. Can someone show me an example how to create an import and a use example for such a C function: char functionName(char *, unsigned int, char *) {-# LANGUAGE ForeignFu

Re: Import, how to

On Sun, 18 Jul 2010, grzyb wrote: I'm a beginner at haskell and ffi. I was trying to import and use is haskell one C function, but I can't manage to do that. Can someone show me an example how to create an import and a use example for such a C function: char functionName(char *, unsigned int,

Re: addFinalizer to which object? (fwd from cafe)

On Tue, 19 Jan 2010, Henning Thielemann wrote: The documentation of System.Mem.Weak.addFinalizer suggests to me, that this function is very fragile, because the object we track, might be optimized away. ... After even more web search I found the bytestring-mmap package that brought my atten

Re: building and analysing C structs with Storable

On Sun, Oct 14, 2007 at 09:28:45PM +0200, Henning Thielemann wrote: > >You say "the system's C compiler" as if there was only one. It's quite > >common for UNIXoid systems to have several C compilers installed > >simultaneously; and if you use the module corresponding to the wrong > >compiler, you

Re: Force single evaluation?

Am Mittwoch, 20. Dezember 2006 16:10 schrieb Axel Jantsch: > [...] My simplified codes is as follows: > > f :: InparT -> IO CInt > f inPar = do > inP <- malloc > poke inP inPar > > r <- cfun inP > > free inP > return r This can be simplified to 'fl

Re: Force single evaluation?

I tried both alternatives: foreign import ccall originalFn :: Arg1T -> Arg2T -> IO ResultT foreign import ccall originalFn :: Arg1T -> Arg2T -> ResultT but in both cases the C function originalFn is called several times for the same arguments. And it is bound only in one place. I don't under

Re: Force single evaluation?

"Axel Jantsch" <[EMAIL PROTECTED]> wrote: > I call a C function from a Haskell program. I am using unsafePerformIO > to use it outside a monad. > > Even though the C function does not have any side effect, I absolutely > don't want to evaluate it more than once for performance reasons. But > my

Re: FFI docs

Simon, I started to collect all pending issues concerning the FFI spec on the H' wiki page for the FFI: http://hackage.haskell.org/trac/haskell-prime/wiki/ForeignFunctionInterface There is also another issue concerning newtypes that SimonM brought up a while ago. Manuel > A couple of commen

RE: Foreign type

On 18 May 2005 19:37, Peter Eriksen wrote: > Monique Louise <[EMAIL PROTECTED]> writes: > >> Hi all, >> >> does anyone know what package should be imported to make GHC accept >> a declaration like "foreign type dotnet "BigInteger" BigInteger" ? >> I've searched at Google, GHC and FFI documenta

Re: Foreign type

Monique Louise <[EMAIL PROTECTED]> writes: > Hi all, > > does anyone know what package should be imported to make GHC accept > a declaration like "foreign type dotnet "BigInteger" BigInteger" ? > I've searched at Google, GHC and FFI documentation but I haven't found > anything. Do you mean "fo

Re: Foreign type

I saw it for the first time in the code " foreign type dotnet "BigInteger" BigInteger " in module Num.lhs from GHC prelude. I think it defines a type to be "foreign": a way to say the type is not defined in Haskell, but in the foreign language. On 5/18/05, Lemmih <[EMAIL PROTECTED]> wrote: > On

Re: Foreign type

On 5/18/05, Monique Louise <[EMAIL PROTECTED]> wrote: > Hi all, > > does anyone know what package should be imported to make GHC accept > a declaration like "foreign type dotnet "BigInteger" BigInteger" ? > I've searched at Google, GHC and FFI documentation but I haven't found > anything. What

Re: Overloading and overlap

Thanks, Andre ! On 4/20/05, Andre Pang <[EMAIL PROTECTED]> wrote: > On 20/04/2005, at 8:49 AM, Monique Louise wrote: > > >> I don't know of any other solution , but you may want to read > >> Andre Pang's master thesis (under supervision of Manuel Chackravarty) > >> that might have some content ab

Re: Overloading and overlap

Monique Louise wrote: Hi, Daan, Note that "under the hood" even .NET and Java use different names for each method ("renaming") to distinguish them. perhaps the virtual machine or the JIT compiler use different names to resolve overloads, but the code in .NET MSIL, for

Re: Overloading and overlap

On 20/04/2005, at 8:49 AM, Monique Louise wrote: I don't know of any other solution , but you may want to read Andre Pang's master thesis (under supervision of Manuel Chackravarty) that might have some content about this. Do you know where I can find that thesis ? Here's a paper which is more-or-le

Re: Overloading and overlap

Hi, Daan, > Note that "under the hood" > even .NET and Java use different names for each method ("renaming") to > distinguish them. perhaps the virtual machine or the JIT compiler use different names to resolve overloads, but the code in .NET MSIL, for example, uses the same name. > I don't k

Re: Overloading and overlap

Monique Louise wrote: does anyone know about any existing extensions to FFI or even to GHC which incorporate access to overloaded methods, which are common in OO environments (.NET, Java), without using "renaming techniques" ? I think you refer here to "overloaded methods" in the sense of meth

Re: help on win32

James Mitchell wrote: I'm writing an interface to Berkeley DB, and, while I can link to my wrapper library fine from C, I can't seem to do it successfully from GHC. I think you are trying to link agains an Microsoft Visual C++ library. You need to convert it first to a mingw compatible library a

Re: help on win32

> You can also try the IRC channel #haskell at > irc.freenode.net for > real-time help. Thanks, I'll get an IRC client and give that a try. > I not sure now linking on done on a windows box but > aren't you > supposed to use '-lLibName'? No, if you do, it will complain, "can't find '-lLibName'".

Re: Strict arguments with foreign import

On 16/03/2005, at 8:27 PM, Marcin 'Qrczak' Kowalczyk wrote: I'm just wondering -- for "primitive" C types (int, float, char, etc), why was the decision made in the FFI to have function declarations look like e.g. foreign import ccall "math.h sin" sin :: CDouble -> CDouble rather than foreign im

Re: Strict arguments with foreign import

Andre Pang <[EMAIL PROTECTED]> writes: > I'm just wondering -- for "primitive" C types (int, float, char, etc), > why was the decision made in the FFI to have function declarations > look like e.g. > > foreign import ccall "math.h sin" sin :: CDouble -> CDouble > > rather than > > foreign impo

RE: mistake in definition of CFile?

On 22 January 2005 23:53, John Meacham wrote: > The FFI spec says (in section 6.2) that CFile represents the C type > 'FILE' and has Eq and Storable instances. > > Is this a mistake? FILE is opaque and AFAIK, you can't copy or > compare its contents and expect it to work. I can think of two > pos

Re: Using Haskell with Java

On Sat, 08 Jan 2005 00:59:10 +0100, Bjorn Bringert <[EMAIL PROTECTED]> wrote: > You could probably use the "foreign export" feature of the Haskell > Foreign Function Interface [1] to make your Haskell function(s) callable > from C, and then write a Java Native Interface [2] wrapper in C. I have fo

Re: Template GreenCard

On Wed, 17 Nov 2004, Rafael Martinez Torres wrote: > > I have no problems to interface such a function in C with the next > prototype: > > int foo(int a, int b); > > Problemas arise when dealing with variable-arguments prototypes like : > > int foo( int a, ...); > > How to solve it ? > This wha

Re: Calling Haskell from .Net application

Maybe you can take a look into: http://www.haskell.org/ghc/docs/papers/hep.ps.gz "Architecture of the Haskell Execution Platform" "The DietHEP component [...] allows us to view any Haskell module as an ordinary DLL". Hope to be usefull... On Thu, 28 Oct 2004, David Lo wrote: > Dear all, >

Re: Haskell and Maple FFI [RELASED 0.0.1]

> > Yes, now use Haskell's ffi to import all those OpenMaple calls you made in the > above. That is, MapleNumArgs, ToMapleExpressionSequence, etc. > > Having done that, translate the code into Haskell in the obvious way and check > it works. > Done !!! > After you've done a bunch of examples, s

Re: Haskell and Maple FFI

Rafael Martinez Torres wrote: Well, after reading some doc, I realised it may not be feasible without a FFI preprocessor. It's feasible without a FFI preprocessor, but probably not very portable. For the time beeing, as I don't want to access the internals of Kernel descriptor, but to deal with it

Re: Haskell and Maple FFI

> > > C) CInt, CDouble are available...but, concerning Storable class. > > Given: > typedef struct _foostruct { > int a; > double b; > } fooStruct, *fooStructPtr; > > How to do to marshall it to Haskell ? > > type CFooStruct = ??? > > instance Storable CFooStruct where >sizeOf _ = ??

Re: Haskell and Maple FFI

Rafael Martinez Torres wrote: Done. Upgrading ghc-6.0.1 solves it. Why not 6.2.2? 6.0.1 is relatively old... Still waiting for answer C) on how marshalling C structures... Perhaps a look at http://www.reid-consulting-uk.ltd.uk/docs/ffi.html and probably http://haskell.org/ghc/docs/latest/html

Re: Haskell and Maple FFI

> - > A) The H98 Foreign Function Interface remakrs the next example to import > from C. > > foreign import ccall "string.h strlen" cstrlen:: Ptr CChar -> IO CSize > > but trying > > foreign import ccall "maplec.h MapleKernelOptions" mapleKernelOptions :: > MKernelVector -> CString ->

Re: Haskell and Maple FFI

> > B) When passing char *string on C, should I use > the CString or the Ptr CChar marhalling type from FFI ? > Ok. I see. Definition for CSTring is type CString = Ptr CChar C) CInt, CDouble are available...but, concerning Storable class. Given: typedef struct _foostruct { int a; doub

Re: Haskell and Maple FFI

On Mon, 20 Sep 2004, Alastair Reid wrote: > > } > > ... > > /* return the pair */ > > return( ToMapleExpressionSequence(kv,2,mean,sd) ); > > } > > > > Is it what do you mean ? > > Yes, now use Haskell's ffi to import all those OpenMaple calls you made in the > above.

Re: Haskell PPL bug fix

Axel Simon <[EMAIL PROTECTED]> writes: > the Haskell compiler GHC replaces the memory allocator in GMP with > one that allocates from the Haskell heap. Pedro managed to link the > PPL with a private version of GMP but that is not a feasible > solution in the long term. I second this. I would like

RE: Haskell PPL bug fix

On 15 October 2004 10:25, Axel Simon wrote: > for Simon M: conceptually it would be nicer if GHC uses it's private > version of GMP. Yes. This has been discussed on the GHC User's list (recently I believe). Ideally we'd like to replace GMP with something else. > Alternatively, GHC could just u

Re: Haskell PPL bug fix

Roberto, Simon, this is a message is about a Haskell binding to the Parma Polyhedra Library. I had trouble with segfaults which were GC-related. Pedro figured out what I had done wrong: the Haskell compiler GHC replaces the memory allocator in GMP with one that allocates from the Haskell heap. Ped

Re: Haskell and Maple FFI

> Examples ( taken from Open Maple ) > > ALGEB M_DECL MyStats( MKernelVector kv, ALGEB *args ) > { > ALGEB mean, sd, f; > > if( 1 != MapleNumArgs(kv,(ALGEB)args) ) { > MapleRaiseError(kv,"one argument expected"); > return( NULL ); > } > ... >

Re: Haskell and Maple FFI

> > Making it possible to call Maple would be very cool. Can you give more detail > about Open Maple? > Description OpenMaple is a suite of functions that allows you to access Maple algorithms and data structures in your compiled C program. This is the reverse of ExternalCalling, which allows

Re: Haskell and Maple FFI

> I would like to implement a new "calling convention" for Maple > language, so that programers in Haskell may call for Maple routines. > Both languages are intereseting for cooperation, due to its symbolic > expresiveness. Making it possible to call Maple would be very cool. Can you give more d

Re: C.Types

On Monday 06 September 2004 14:10, "Daniel Müller" wrote: > I try to use a Function calc, which is written in C (CalcType = Int): > [...] > Unfortunately I got an error. What shall I do? Telling us what the error is (cut and paste from the terminal is best) would be a start. If the program compi

Re: C.Types

"Daniel Müller" <[EMAIL PROTECTED]> writes: > foreign import ccall calc :: CInt -> CInt -> CInt > > calculate :: Int -> Int -> CalcType > calculate a b > | ... > | ... > | otherwise = calc a b > > > Unfortunately I got an error. What shall I do? Use fromIntegral to convert between CInt and Int,

Re: PIC status

7) Devise a way of telling GHC that a foreign import is imported from a DLL (for Windows); something like __declspec(dllimport) in Windows C compilers. We should have thought of this before the FFI spec was finalized... [...] Can you explain point 7? How is a foreign import from DLL different from

Re: PIC status

[Redirected to [EMAIL PROTECTED] from [EMAIL PROTECTED] Wolfgang Thaller wrote: > [lots of stuff about dynamic linking/ghc/PIC deleted] > So what's left to do is the following: > [...] > 7) Devise a way of telling GHC that a foreign import is imported from a > DLL (for Windows); something like __d

RE: Fail: <> from finalizers and stuff

On 04 July 2004 23:54, Sven Moritz Hallberg wrote: > Dear Foreign Function Interface, > > why does a program like the following fail with a "<>" exception > (using GHC 6.2 on MacOS X)? > > -snip- > import Foreign > > main = > do > f <- mkFinPtr finalizer > fp

RE: atomicModifyIORef

On 25 June 2004 15:09, Daan Leijen wrote: > Ok, I never thought of that. However, isn't it the case > that I normally just want to get the old value back? > In that case, the current interface is not so friendly. > > Is anyone using this function to get something else than the > old/new value *an

RE: [Haskell] ANNOUNCING: The Haskell Bookstore

On 25 June 2004 11:30, Daan Leijen wrote: > Is there anyone who knows why "atomicModifyIORef" has type: > > IORef a -> (a -> (a, b)) -> IO b(1) > > Instead of: > > IORef a -> (a -> a) -> IO a (2) > > > It seems to me that returning the old value is always good

Re: [Haskell] ANNOUNCING: The Haskell Bookstore

W liście z pią, 25-06-2004, godz. 12:30 +0200, Daan Leijen napisał(a): > It seems to me that returning the old value is always good > enough right? Here is an implementation of "atomicModifyIORef" > with the current type in terms of a function "proposedModifyIORef" with > type (2). > > atomicMod

Re: [Haskell] ANNOUNCING: The Haskell Bookstore

Is there anyone who knows why "atomicModifyIORef" has type: IORef a -> (a -> (a, b)) -> IO b (1) Instead of: IORef a -> (a -> a) -> IO a (2) It seems to me that returning the old value is always good enough right? Here is an implementation of "atomicModifyIORef" wi

Re: [Fwd: cvs commit: fptools/libraries/base/Foreign/C Types.hs fptools/libraries/base/System CPUTime.hsc Directory.hs Time.hsc fptools/libraries/base/System/Posix Types.hs fptools/libraries/base/include CTypes.h]

I wrote: I've just commited a change to the fptools repository, proposing a minor change in the FFI spec, see below. Comments welcome. [...] My previous mail was a little bit terse, so I'd like to explain my proposal in more detail: A part of the FFI spec describes a mapping of some C types to Has

Re: Extension to the FFI to allow macro expansions to be avoided

I really like that the Haskell FFI is defined at the ABI level, and that it doesn't need to generate its own stub funtions or whatnot. I especially like that it doesn't require having a C compiler installed. it is a foreign function interface that supports the C calling convention. If you want a C

RE: Extension to the FFI to allow macro expansions to be avoided

W liście z pią, 16-04-2004, godz. 15:25 +0100, Simon Marlow napisał: > I wondered about that (while writing my last post) but it still seems > like a hefty price to pay for the small number of problematic cases we > have, and given that you can already write the C stubs by hand to get > the desire

RE: Extension to the FFI to allow macro expansions to be avoided

On 16 April 2004 11:33, Marcin 'Qrczak' Kowalczyk wrote: > Perhaps we should differentiate by a calling convention between > linking to a function directly and generating a source-level C call? > > The calling conventions we know would correspond to linking to them > directly. They would perform

Re: Extension to the FFI to allow macro expansions to be avoided

W liście z czw, 15-04-2004, godz. 18:14 -0700, Fergus Henderson napisał: > When using the "--target asm" option, which tells the Mercury compiler to > compile directly to assembler, the Mercury compiler will generate some > C glue code to handle the FFI interfacing pragmas. Which - in case it's a

Re: Extension to the FFI to allow macro expansions to be avoided

Sven Panne <[EMAIL PROTECTED]> writes: > Fergus Henderson wrote: > > [...] the Haskell FFI has sacrificed quality for easy of implementation. > > If this starts causing problems for users, I think the right solution > > is to raise the bar for implementations, not to lower it. [...] > > P.S. to M

Re: Extension to the FFI to allow macro expansions to be avoided

On 15-Apr-2004, Sven Panne <[EMAIL PROTECTED]> wrote: > Fergus Henderson wrote: > >I'd rather fix GHC so that interfacing with C macros works with ghc -fasm. > >The equivalent works fine with the Mercury implementation ("mmc --target > >asm" > >generates assembler for the Mercury code and C stubs

RE: Extension to the FFI to allow macro expansions to be avoided

> Fergus Henderson wrote: > > [...] the Haskell FFI has sacrificed quality for easy of > implementation. > > If this starts causing problems for users, I think the > right solution > > is to raise the bar for implementations, not to lower it. [...] > > I definitely support Fergus' point of vie

Re: Extension to the FFI to allow macro expansions to be avoided

Fergus Henderson wrote: [...] I the right way to solve this is to support some way for the Haskell user to tell the Haskell implementation what the right type is, for example perhaps something along the lines of data WINDOW foreign import ccall unsafe "static curses.h wstandend" wstandend

Re: Extension to the FFI to allow macro expansions to be avoided

Fergus Henderson wrote: [...] the Haskell FFI has sacrificed quality for easy of implementation. If this starts causing problems for users, I think the right solution is to raise the bar for implementations, not to lower it. [...] I definitely support Fergus' point of view, GHC and Hugs really rush

Re: Extension to the FFI to allow macro expansions to be avoided

Fergus Henderson wrote: I'd rather fix GHC so that interfacing with C macros works with ghc -fasm. The equivalent works fine with the Mercury implementation ("mmc --target asm" generates assembler for the Mercury code and C stubs for the FFI glue), so it's clearly possible. How does Mercury handle

Re: Extension to the FFI to allow macro expansions to be avoided

On 13-Apr-2004, Ross Paterson <[EMAIL PROTECTED]> wrote: > On Tue, Apr 13, 2004 at 11:55:47AM +0100, Simon Marlow wrote: > > > I'd favour turning off the > > > macro interface, preferably with #undef, at least by default. > > > > Agreed. Why is #undef to be preferred over adding parentheses aroun

Re: Extension to the FFI to allow macro expansions to be avoided

On 13-Apr-2004, Ross Paterson <[EMAIL PROTECTED]> wrote: > And Hugs too. The issue isn't extending the FFI but implementing it > more accurately and consistently. As you point out, systems compiling > via C have been extending the FFI to a function+macro interface, which is > incompatible with sy

Re: Extension to the FFI to allow macro expansions to be avoided

On 08-Apr-2004, Alastair Reid <[EMAIL PROTECTED]> wrote: > > Now that I understand the problem, my feeling is that the problem is not with > curses but with GHC's compilation method. GHC is using a shortcut by > pretending that the ffi is for interfacing to cpp+C whereas the ffi is quite > cle

Re: Extension to the FFI to allow macro expansions to be avoided

On 08-Apr-2004, Ian Lynagh <[EMAIL PROTECTED]> wrote: > > The problem > === > > Some C libraries (curses is the one I have to hand) provide macros in > addition to functions in some cases for efficiency reasons. That is a feature, not a problem. And it is not just for efficiency reasons

Re: Extension to the FFI to allow macro expansions to be avoided

On Tue, Apr 13, 2004 at 11:55:47AM +0100, Simon Marlow wrote: > > I'd favour turning off the > > macro interface, preferably with #undef, at least by default. > > Agreed. Why is #undef to be preferred over adding parentheses around > the function name as Ian originally suggested? It would also s

RE: Extension to the FFI to allow macro expansions to be avoided

> On Thu, Apr 08, 2004 at 10:18:24AM +0100, Alastair Reid wrote: > > Now that I understand the problem, my feeling is that the > problem is not with > > curses but with GHC's compilation method. GHC is using a > shortcut by > > pretending that the ffi is for interfacing to cpp+C whereas > t

Re: Extension to the FFI to allow macro expansions to be avoided

> And Hugs too. The issue isn't extending the FFI but implementing it > more accurately and consistently. As you point out, systems compiling > via C have been extending the FFI to a function+macro interface, which is > incompatible with systems compiling to native code. Having been bitten by >

Re: Extension to the FFI to allow macro expansions to be avoided

On Thu, Apr 08, 2004 at 10:18:24AM +0100, Alastair Reid wrote: > Now that I understand the problem, my feeling is that the problem is not with > curses but with GHC's compilation method. GHC is using a shortcut by > pretending that the ffi is for interfacing to cpp+C whereas the ffi is quite >

RE: Extension to the FFI to allow macro expansions to be avoided

> Alastair Reid wrote: > > [...] where the decision to insert parens is decided by a > command-line flag. [...] > > I'm still not convinced that any change is really necessary, > but I'd really > prefer a command-line flag over a change in the FFI syntax. > The latter will > lead to much more

Re: Extension to the FFI to allow macro expansions to be avoided

This is exactly the problem I ran into when using the FFI to interface with curses. I just created a my_curses.h with appropriate #undefs in it. John -- John Meacham - ârepetae.netâjohnâ ___ FFI mailing list [EMAIL PROTECTED] http://www.haskel

Re: Extension to the FFI to allow macro expansions to be avoided

Alastair Reid wrote: [...] where the decision to insert parens is decided by a command-line flag. [...] I'm still not convinced that any change is really necessary, but I'd really prefer a command-line flag over a change in the FFI syntax. The latter will lead to much more portability trouble than

Re: Extension to the FFI to allow macro expansions to be avoided

Ian Lynagh writes: > Some C libraries (curses is the one I have to hand) provide macros in > addition to functions in some cases for efficiency reasons. If you use > the FFI to import such a function thus: I was a bit confused by what Ian meant by this so, in case it helps others, here's an extr

RE: Request: withArrayLength

t a hierarchical library any more, and anyone wishing to use purely hirerarchical libraries in their code should avoid it. On one hand, this looks reasonable: Foreign already doesn't re-export Foreign.C. However, I do use it all the time. So if we ever decided to allow disabling of the h

Re: Request: withArrayLength

> the hierarchy. This would have been the better choice IMHO, but we > decided to do differently for legacy reasons, IIRC. Renaming "Foreign" > will probably wreak havoc, much more than simply adding 2 functions to > "Foreign.Marshal.Array", which get re-exported by &q

Re: Request: withArrayLength

gn" will probably wreak havoc, much more than simply adding 2 functions to "Foreign.Marshal.Array", which get re-exported by "Foreign". Cheers, S. ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi

Re: Request: withArrayLength

, though). > > (2) Add new modules only (not re-exported by Foreign) > > (3) Add new stuff to the hierarchical Foreign.XXX modules, but > not the non-hierarchical variants (and Foreign keeps the > same interface as the FFI spec). > > (4) Wait until w

Re: Request: withArrayLength

On Monday 29 Mar 2004 8:35 am, Sven Panne wrote: > I wrote: > > [...] So if nobody yells, I'll add > > > >withArrayLen :: Storable a => [a] -> (Ptr a -> Int -> IO b) -> > > IO b withArrayLen0 :: Storable a => a -> [a] -> (Ptr a -> Int -> IO b) -> > > IO b [...] > > After some thoughts, sw

Re: Request: withArrayLength

I wrote: [...] So if nobody yells, I'll add withArrayLen :: Storable a => [a] -> (Ptr a -> Int -> IO b) -> IO b withArrayLen0 :: Storable a => a -> [a] -> (Ptr a -> Int -> IO b) -> IO b [...] After some thoughts, swapping the order of the pointer and the length, i.e.: withArrayLen

Re: Request: withArrayLength

Simon Marlow wrote: We certainly want to be able to add new stuff to the FFI over time. There are several ways we might do this: (1) Just extend the existing interfaces (don't change semantics of existing functions, though). (2) Add new modules only (not re-exported by Foreign)

  1   2   3   4   5   6   7   8   9   10   >