Simon & Simon away
The reason that Simon and I are quiet this week is that Simon is on holiday and I'm at PLDI. We'll be back in action next week. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-users- | [EMAIL PROTECTED] On Behalf Of John Meacham | Sent: 10 June 2004 01:15 | To: [EMAIL PROTECTED] | Subject: GMP | | I was curious what the best way would be to access the various useful | GMP functions which are not exported for Integers. I was thinking of | making my own (strict) Integer type, but it would be much easier if I | can just use the FFI to import the required functions and get at the | mpz_t inside Integers somehow. | | I am not positive, but it looks like ghc seems to have primitives which | call the gmp functions internally rather than using the FFI.. At least I | didn't see an obvious example poking around in the library. | | Has someone already done this? a Math.Integer.Advanced (or something) | library would be quite a useful addition to ghc. | John | -- | John Meacham - ârepetae.netâjohnâ | ___ | Glasgow-haskell-users mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Finalizers and FFI
On 10-jun-04, at 17:33, Gracjan Polak wrote: foreign import stdcall "windows.h &UnmapViewOfFile" funptrUnmapViewOfFile :: FunPtr (Ptr a -> IO ()) [...] finview <- newForeignPtr funptrUnmapViewOfFile view return finview Strangely enough my finalizer run always this time, no need to say performGC or yield'ing at the end of main. But it crashes my program :( That's why I stopped using the newForeignPtr from Foreign.ForeignPtr. It also crashed. I wrote: foreign import ccall "..." finaliserCreator :: IO (FunPtr (Ptr a -> IO ())) and then finaliser <- finaliserCreator That's why I wrote: "I don't know how to make a FunPtr". I thought I knew, but then it crashed. Any ideas where to go now? Sorry. As I said before, the Concurrent ForeignPtr works for me. On Windows. But it may be so that the finalisers are not called at the end of the program but only at GC time. For my application this is no problem. Arjan ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Finalizers and FFI
On Thursday 10 June 2004 12:07, MR K P SCHUPKE wrote: > I don't see why GHC can't have a 'callAllOutstandingFinalizers' call > as part of _exit() or something... You can do that if your finalizers are written in C (and don't call back into Haskell) but if they are written in Haskell then you potentially finalize an object before its last use because one of the other finalizers uses it. To fix this, you have to run the finalizers in the "right order" but how can you tell what the right order is? -- Alastair Reid ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Finalizers and FFI
> BUT: This can make some people unhappy. Isn't there a more deterministic > way to schedule finalizers? I wrote the Hugs version which does try to be more deterministic so I'm probably not the best qualified to write about what's wrong with GHC :-) But, I think part of the problem is that GHC gives the 'main' thread special status: the whole program quits when the main thread quits even if there are other threads that are runnable. There'd be less of a problem if the whole program quit only when there were no runnable threads _and_ garbage collection did not create any runnable threads. I think there's a reason why GHC gives the main thread special status though. They certainly went to some effort to give it special status so I guess there must be a good reason that they did so? -- Alastair Reid ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Finalizers and FFI
Alastair Reid wrote: import Foreign.ForeignPtr I couldn't get finalisers to work either with the newForeignPtr from this module. I didn't know how to create a proper FunPtr. You create a FunPtr using foreign import: foreign import ccall "malloc.h &free" free_ptr :: FunPtr (Ptr a -> IO ()) foreign import stdcall "windows.h &UnmapViewOfFile" funptrUnmapViewOfFile :: FunPtr (Ptr a -> IO ()) Basically I'd love to do (in Windows world): mapTheFileToMemory = do handle <- winOpenFile(...) mapping <- winCreateFileMapping(...) view<- winMapViewOfFile(...) finview <- newForeignPtr funptrUnmapViewOfFile view return finview Strangely enough my finalizer run always this time, no need to say performGC or yield'ing at the end of main. But it crashes my program :( Warnings in compilation are also strange: $ ghc -package win32 --make interlvIO.hs -o interlvIO.exe Chasing modules from: interlvIO.hs Compiling Main ( interlvIO.hs, interlvIO.o ) Linking ... Warning: resolving _UnmapViewOfFile by linking to [EMAIL PROTECTED] Use --enable-stdcall-fixup to disable these warnings Use --disable-stdcall-fixup to disable these fixups I did not find any of those flags. Searching sources downloaded from website today also does not say anything about stdcall fixups. Changing calling convention from stdcall to ccall in import clause did not help either. At the end of (correct) run my program dies with: interlvIO.exe: internal error: resumeThread: thread not found Please report this as a bug to [EMAIL PROTECTED], or http://www.sourceforge.net/projects/ghc/ So basically I have no idea how to make finalizer out of UnmapViewOfFile :( Any ideas where to go now? -- Gracjan ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GMP
On Wed, Jun 09, 2004 at 05:14:45PM -0700, John Meacham wrote: > I was curious what the best way would be to access the various useful > GMP functions which are not exported for Integers. I was thinking of > making my own (strict) Integer type, but it would be much easier if I > can just use the FFI to import the required functions and get at the > mpz_t inside Integers somehow. > > I am not positive, but it looks like ghc seems to have primitives which > call the gmp functions internally rather than using the FFI.. At least I > didn't see an obvious example poking around in the library. > > Has someone already done this? a Math.Integer.Advanced (or something) > library would be quite a useful addition to ghc. > Yes, advanced algebra library for Integer should be very useful. It is a very mathematical and complex piece of Computation. For example, my DoCon library for CA suffers of a very slow method for factoring large integers greater than 10^10. I cannot just study-do-implement all the algorithmic mathematics myself, it is better to port pieces from some good open-source library. They say, there exist libraries (maybe, GMP is one of them) for Integer, and generally, for Algebraic numbers (also important). Open source libraries written in C, algorithms developed by great experts, like Lenstra. The idea is just arrange an interface to GHC and join to GHC library. I had not looked into such possibilities, so far, because deal with other tasks. - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Finalizers and FFI
I don't see why GHC can't have a 'callAllOutstandingFinalizers' call as part of _exit() or something... Keean. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Finalizers and FFI
Alastair Reid wrote: You could give the finalizer thread a chance to run by calling Control.Concurrent.yield before exiting: Thanks, it worked. This is ok for me, because my finalizer only closes some handles. Those are closed at program end anyway, so in this case I can live with it. BUT: This can make some people unhappy. Isn't there a more deterministic way to schedule finalizers? I've read about MVars etc, but this seems like an ugly hack around GC deficiency. Do weak references have same problem? Also documentation about newForeignPtr (in Control.Concurrent and in Foreign.ForeignPtr) is lying: "The only guarantee is that the finaliser runs before the program terminates." Currently there is no guarantee :) -- Gracjan ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Finalizers and FFI
> [program deleted] > > So, this basically means that my finalizer did not get run :( > [...] > It should run, in separate thread or not, it doesn't matter here. > > Any ideas why doesn't it work? Hopefully the GHC folk will correct me if I'm wrong but I think what happens is: - you allocate object with finalizer - the object becomes inaccessible - performGC causes the object to be freed by the garbage collector - the garbage collector schedules a thread to run your finalizer BUT - before the finalizer thread has a chance to be scheduled, your program exits. You could give the finalizer thread a chance to run by calling Control.Concurrent.yield before exiting: http://etudiants.insia.org/~jbobbio/pafp/docs/base/Control.Concurrent.html#v% 3Ayield That is, call yield just after calling performGC. -- Alastair Reid ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Finalizers and FFI
For a finalizer to run - the program must be around long enough for GC to happen. I think your program just exits and deallocates everything, without any GC. Keean. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Finalizers and FFI
Arjan van IJzendoorn wrote:
> I couldn't get finalisers to work either with the newForeignPtr from
> this module. I didn't know how to create a proper FunPtr. In
> Foreign.Concurrent there is a newForeignPtr that is easier to use:
> [deleted]
So here is the new code:
{-# OPTIONS -fglasgow-exts #-}
module Main where
import Foreign.Ptr
import Foreign.ForeignPtr hiding (newForeignPtr)
import Foreign.Marshal.Alloc
import Foreign.Concurrent
import System.Mem
myFinalizer = putStrLn "My finalizer"
subproc = do
(ptr :: Ptr Int) <- malloc
finptr <- newForeignPtr ptr myFinalizer
putStrLn "End of subproc"
main = do
subproc
performGC
putStrLn "End of program"
This program compiled under GHC 6.2 gives follwing output:
$ ./finalizers
End of subproc
End of program
So, this basically means that my finalizer did not get run :( Strange
thing to me. Spec says
(http://www.haskell.org/ghc/docs/latest/html/libraries/base/Foreign.Concurrent.html):
"The finalizer will be executed after the last reference to the foreign
object is dropped. Note that there is no guarantee on how soon the
finalizer is executed after the last reference was dropped; this depends
on the details of the Haskell storage manager. The only guarantee is
that the finalizer runs before the program terminates."
It should run, in separate thread or not, it doesn't matter here.
Any ideas why doesn't it work?
--
Gracjan
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
