So, I was looking at the implementation of ForeignPtr's in an attempt to
determine why they were slow, and have an idea to speed them up..
right now we have:
ForeignPtr a
= ForeignPtr ForeignObj# !(IORef [IO ()])
| MallocPtr (MutableByteArray# RealWorld) !(IORef [IO ()])
and I think the i
You should compile the .c file using GHC itself. This guarantees that,
under the hood, you are using the right version of gcc.
I've never been able to get MS VC++ to work for compiling statically
linked C source - but it works great for building DLLs that you can then
reference from the Haskel
On Fri, Jul 16, 2004 at 10:43:58AM +0100, Simon Marlow wrote:
> > Also, in my tests, arrays implemented via ByteArray# or Ptr a seem to
> > be signifigantly faster than those implemented via ForeignPtr. Is this
> > expected?
>
> Yes, StorableArray suffers from this problem. Specialising the array
>Start GHCi with the following command line:
>ghci -fffi test.lhs project.o
>GHCi should just load the object file, and you shouldn't have a
problem.
Well, I certainly red the GHC Documentation and so I tried all that
things. Fortunately doest it work now.
First I compiled the *.c file with Micr
>Actually I lied. You need the -fglasgow-exts flag.
Yes, I should have tried it before I posted, I just remembered reading
in the manual that type synonyms were excluded... But on re reading
it actually said partial applications of type synonyms were excluded,
which does not affect what I wanted
Actually I lied. You need the -fglasgow-exts flag.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of Simon Peyton-Jones
| Sent: 16 July 2004 15:28
| To: MR K P SCHUPKE; [EMAIL PROTECTED]
| Subject: RE: type synonyms in in
It seems that GHC does this by default (which is technically wrong,
perhaps). I've just tried it.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of MR K P SCHUPKE
| Sent: 07 July 2004 11:34
| To: [EMAIL PROTECTED]
| Subje
--- Jérémy_Bobbio <[EMAIL PROTECTED]> wrote:
> memcpy is available in Foreign.Marshal.Utils:
>
> copyBytes :: Ptr a -> Ptr a -> Int -> IO ()
>
> Copies the given number of bytes from the
> second area (source)
> into the first (destination);the copied areas
> may not overlap
>
> H
On 15 July 2004 22:08, John Meacham wrote:
> On Thu, Jul 15, 2004 at 04:20:38PM +0200, Jérémy Bobbio wrote:
>> memcpy is available in Foreign.Marshal.Utils:
>>
>> copyBytes :: Ptr a -> Ptr a -> Int -> IO ()
>>
>> Copies the given number of bytes from the second area (source)
>> in
and compiled this. So I created a file named project.obj.
We normally use .o rather than .obj; I don't know if using .obj can
cause any problems with ghc.
After that I wrote ghc -fffi -c test.lhs. But when I call blah from
ghci I get the error message: "test.o unknown symbol '_test'
I think ghc
> After that I wrote ghc -fffi -c test.lhs. But when I call
> blah from ghci I get the error message: "test.o unknown symbol '_test'
>
> I think ghc doen't link test.o to projekt.obj. What do I have to do?
I don't know about linking object files I've created myself, but to link an
existing lib
11 matches
Mail list logo
