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
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
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
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
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:
[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 is
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
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 (!)
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
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
Hi -
I have the following declaration and code in part of a DLL I'm writing:
extern C {
typedef void (*HsFunPtr)();
extern __declspec(dllimport) void hs_free_fun_ptr(HsFunPtr fp);
}
enum ECallback { ECallback_Render, ECallback_COUNT};
HsFunPtr callback[ECallback_COUNT];
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
12 matches
Mail list logo
