On Tue, 2006-03-28 at 01:37 +0100, Brian Hulley wrote:
> Hi Duncan -
> I just declared duma_vertex3f (in another module) by:
>
> foreign import ccall duma_vertex3f :: Float -> Float -> Float -> IO ()
>
> I thought this means that the C function prototype must be:
>
> void duma_vertex3f
On Mon, Mar 27, 2006 at 08:14:40PM +0100, Brian Hulley wrote:
> However I'm wondering if I can rely on all this monad stuff being optimized
> out at compile time. A sample monad is below:
>
> newtype VertexM a = VertexM (IO a)
>
in GHC you can actually guarentee there is no overhead with the
Chris Kuklewicz wrote:
Brian Hulley wrote:
Hi,
I'm designing an API for a simple graphics window, and am trying to
[snip]
There should be no overhead for a newtype. The above can be
shortened to one line:
newtype VertexM a = VertexM (IO a) deriving (Functor,Monad,MonadIO)
Thanks - that cer
Brian Hulley wrote:
> Hi,
> I'm designing an API for a simple graphics window, and am trying to make
> the correct usage of the API functions explicit and visible to the type
> system by using different monads which ultimately just wrap the IO
> monad. For example, in a callback for rendering stuff
Hi,
I'm designing an API for a simple graphics window, and am trying to make the
correct usage of the API functions explicit and visible to the type system
by using different monads which ultimately just wrap the IO monad. For
example, in a callback for rendering stuff to the screen, only opera
C -> adjustor -> stub -> Haskell -> stub -> adjustor -> CIt could be the case that the adjustor tail-jumps to the stub, but this is not guaranteed to be the case for all platforms.Hmmm, I thought it was.Well, the FFI addendum is rather vague on this point; this seems to be all it says about free
Sven Panne wrote:
[snip]
being executed. The technical reason for this is that after returning
from Haskell land, the adjustor code might need to do some cleanup:
C -> adjustor -> stub -> Haskell -> stub -> adjustor -> C
It could be the case that the adjustor tail-jumps to the stub, but
this
Michael Marte wrote:
Yes, I synced my working copy of ghc 6.5 yesterday with darcs pull.
Are there any requirements as to which exact version of ghc 6.4 I am
supposed to use?
I am using the plain 6.4 release but I am able to build the head of the
6.4 branch.
BTW. Am I supposed to run configu
Hello Simon,
Monday, March 27, 2006, 2:57:47 PM, you wrote:
> quotInteger2Expzh_fast is the function you are adding to PrimOps.cmm to
Thorkil, i can't understand why you can't just use FFI to import
functions you required? why you need to patch the PrimOps list?
--
Best regards,
Bulat
Am Montag, 27. März 2006 14:27 schrieb Brian Hulley:
> [...] For example, in:
>
>foreign import ccall "wrapper" mkIO :: IO () -> IO (FunPtr (IO ()))
>foreign import ccall set_callback :: FunPtr (IO ()) -> IO ()
>foreign import ccall run :: IO ()
>
>foo1 :: IO ()
>foo1 = do
>
Simon Marlow wrote:
Michael Marte wrote:
Hello *,
when building ghc 6.5 with ghc 6.4 and alex 2.0.1, the build fails as
follows:
make -C ghc/compiler stage=2
make[2]: Entering directory `/home/marte/fptools/ghc/compiler'
../../ghc/compiler/ghc-inplace -H16m -O -istage2/utils
-istage2/ba
Sven Panne wrote:
Am Samstag, 25. März 2006 20:00 schrieb Brian Hulley:
I've found a workaround to the problem below: instead of trying to
use hs_free_fun_ptr, I instead pass a FunPtr to the Haskell function
freeHaskellFunPtr into my DLL, and use this to free everything,
finally using it to free
Krasimir Angelov wrote:
Hi Brian,
The problem is that hs_free_fun_ptr is defined in a static library
(the Haskell RTS) while you have declared it with
__declspec(dllimport). In this case the compiler is tring tp optimize
the call and it is using __imp__hs_free_fun_ptr instead of
hs_free_fun_ptr.
Thorkil Naur wrote:
Thanks a lot, that removed some obstacles. Unfortunately, not all. Following
successful "make clean" and "make all" in "ghc/compiler" and
"libraries/base", a "make all" in the top-level directory reported:
../../ghc/compiler/stage1/ghc-inplace -o stage2/ghc-6.4.1 -H16m -
Michael Marte wrote:
Hello *,
when building ghc 6.5 with ghc 6.4 and alex 2.0.1, the build fails as
follows:
make -C ghc/compiler stage=2
make[2]: Entering directory `/home/marte/fptools/ghc/compiler'
../../ghc/compiler/ghc-inplace -H16m -O -istage2/utils
-istage2/basicTypes -istage2/type
Sven Panne wrote:
Am Samstag, 25. März 2006 20:00 schrieb Brian Hulley:
I've found a workaround to the problem below: instead of trying to use
hs_free_fun_ptr, I instead pass a FunPtr to the Haskell function
freeHaskellFunPtr into my DLL, and use this to free everything, finally
using it to fre
16 matches
Mail list logo
