Even as the author of some parts of Adjustor.c and some parts of
Hugs' FFI
implementation I have to admit that it isn't clear to me at all if
tail-calls
are used everywhere. %-)
Hugs uses tail-jumps or static return code on all supported
platforms, GHC on all platforms except IA64.
And
Am Montag, 27. März 2006 20:56 schrieb Wolfgang Thaller:
> >C -> adjustor -> stub -> Haskell -> stub -> adjustor -> C
> >
> > It 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.
> [...]
>
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
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
>
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.
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
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. You have to remove the dl
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
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 itself (!) w
Hi -
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 itself (!) which I assume should be safe.
Thus there is no need
12 matches
Mail list logo
