June 2004 - Glasgow-haskell-users

Finalizers and FFI
by Gracjan Polak 11 Jun '04

11 Jun '04

Hi all, I would like to attach finalizer (written in Haskell) to some pointer. When the pointer won't be needed any more, finalizer should run. So here is the code: module Main where import Foreign.Ptr import Foreign.ForeignPtr import Foreign.Marshal.Alloc foreign import stdcall "wrapper" mkFin :: (Ptr a -> IO ()) -> IO (FunPtr (Ptr a -> IO ())) finDoIt ptr = putStrLn "My finalizer" mkFinalizer = mkFin finDoIt main = do (ptr :: Ptr Int) <- malloc myFin <- mkFinalizer finptr <- newForeignPtr myFin ptr putStrLn "End of script" This script ends with following output: $ ./finalizers End of script Fail: <<loop>> Also it seems to me that I'm not freeing finalizer stub. Is this code leaking memory? How do I attach finalizer to object in the heap? -- Pozdrawiam, Regards, Gracjan

6 14

Open GL, GLUT
by Gracjan Polak 11 Jun '04

11 Jun '04

Hi all, I'd like to make some use of OpenGL with Haskell (under Win2000). Here is some code: module Main where import Graphics.Rendering.OpenGL.GL import Graphics.Rendering.OpenGL.GLU import Graphics.UI.GLUT main = do ver <- get gluVersion putStrLn ver getArgsAndInitialize fullScreen wnd <- createWindow "Hello World" vertex (Vertex2 (100::GLint) 100) return () Compilation (linking) fails with: $ ghc --make openglapp.hs -o openglapp.exe Chasing modules from: openglapp.hs Compiling Main ( openglapp.hs, openglapp.o ) Linking ... c:/ghc/ghc-6.2/libHSGLUT.a(Initialization__158.o)(.text+0x123):ghc16024.hc: unde fined reference to `glutInit@8' c:/ghc/ghc-6.2/libHSGLUT.a(Window__61.o)(.text+0x33):ghc14736.hc: undefined refe rence to `glutFullScreen@0' c:/ghc/ghc-6.2/libHSGLUT.a(Window__53.o)(.text+0x85):ghc14736.hc: undefined refe rence to `glutCreateWindow@4' Manually adding -lglut -lglut32 does not help. Libraries libglut32.a and libglut.a are there, they contain needed symbols but with '_' prepended, like _glutInit@8. Functions from GL and GLU link perfectly. They do even work correctly when run. Only GLUT ones do not :( Has anybody compiled anything for GL recently? Google pointed me only to some old, not relevant any more, material. Am I missing something obvious here? GHC 6.2, installer for Window taken from www.haskell.org, Win2000 Professional. -- Gracjan

1 0

Simon & Simon away
by Simon Peyton-Jones 10 Jun '04

10 Jun '04

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: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of John Meacham | Sent: 10 June 2004 01:15 | To: glasgow-haskell-users(a)haskell.org | 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 | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Re: Finalizers and FFI
by MR K P SCHUPKE 10 Jun '04

10 Jun '04

I don't see why GHC can't have a 'callAllOutstandingFinalizers' call as part of _exit() or something... Keean.

2 1

GMP
by John Meacham 10 Jun '04

10 Jun '04

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⑈

2 1

Re: Finalizers and FFI
by MR K P SCHUPKE 10 Jun '04

10 Jun '04

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.

1 0

Data.Dynamic and dynamically loaded code
by dons＠cse.unsw.edu.au 10 Jun '04

10 Jun '04

(lengthy) Hey, In the hs-plugins library I'm using Data.Dynamic to provide runtime type checking of plugin values when they are loaded. There is a problem, however: when using fromDyn/fromDynamic to check the type of the plugin's value against the type the application loading the plugin expects, they always report that types are unequal, even if they are the same type on both sides. So I'm reporting a limitation of the existing Data.Dynamic, and have a couple of questions about why this exists. The problem appears to be in the hash keys of the type representation used to compare to types for equality. A dynamic value in the (statically compiled) application never has the same key as its equivalent type in the dynamically loaded code. The type in the dynamically-loaded plugin code is never recognised as having the same type as in the application (static) code. The following comment from Data.Typeable seems to be relevant: -- In GHC we use the RTS's genSym function to get a new unique, -- because in GHCi we might have two copies of the Data.Typeable -- library running (one in the compiler and one in the running -- program), and we need to make sure they don't share any keys. -- -- This is really a hack. A better solution would be to centralise the -- whole mutable state used by this module, i.e. both hashtables. But -- the current solution solves the immediate problem, which is that -- dynamics generated in one world with one type were erroneously -- being recognised by the other world as having a different type. An example. The following code uses eval() to compile the string "7 + 8" to object code, and dynamically load the result. main = do i <- eval "7 + 8 :: Int" :: IO Int putStrLn $ show i When checking the dynamically loaded type using fromDynamic, we have <Int> /= <Int>, which is obviously wrong. Running the equivalent code in GHCi doesn't generate this error, nor does statically linked code. It is only if we loadObj the plugin and check it against a type statically compiled into the application doing the loading. I currently work around this with a reimplemented Data.Dynamic that compares the string representations of the types, which works mostly (so that "Int" == "Int", in the above code). However, when there is no explicit type declaration in the dynamically loaded code, for non-simple types, the *string* type representations differ. I.e. in the following code: main = do fn <- eval "\\(x::Int) -> (x,x)" :: IO (Int -> (Int,Int)) putStrLn $ show (fn 7) we have type "-> Int (Int,Int)" doesn't match "Int -> (Int,Int)" (which looks like a Core type in the first case). And for: i <- eval "map (+1) [0..10::Int]" :: [Int] we have "[] Int" /= "[Int]". So, the string comparison of types doesn't always work. So... for safe dynamically loaded plugins we need to fix Data.Dynamic to provide the a unique integer key for types across both static and dynamic code, I think. Does that seem like reasonable? And a question: why do we get different strings from TypeRep's when the type is inferred? I can see that we are getting Core type reps, but why? I would have thought that the TypeRep would still have to be constructed in the same way as in an explicit declaration. -- Don

1 0

Glasgow Haskell on different versions of Linux
by Christian Maeder 09 Jun '04

09 Jun '04

Dear Haskellers, since version 6.2 we have 2 binary distributions for (generic) linux: for glibc 2.2 and glibc 2.3 Unfortunately our network has machines with both of this glibc versions. The problem seems to be related with the inclusion of "ctype.h". Is it possible to produce a GHC binary for glibc 2.3 that does not depend on ctype.h? I think such a binary (produced under glibc 2.3) would be executable also under linux with glibc 2.2 Currently ctype.h triggers the error under glibc 2.2 (if the glibc 2.3 binarias are used): /lib/i686/libc.so.6: version `GLIBC_2.3' not found (required by lib/i386-unknown-linux/ghc-6.2.1) and prevents linking under glibc 2.3 (if the glibc 2.2 release is used) Cheers Christian

2 6

Re: Glasgow Haskell on different versions of Linux
by George Russell 09 Jun '04

09 Jun '04

Christian Maeder wrote: > What is "ctype.h" good for? A good question. Its only use seems to be in ghc/rts/RtsFlags.c where it is used for functions like isdigit and isspace for decoding the RTS flags. Maybe it should be retired altogether. I'm rather puzzled how this works if ctype.h isn't there at all, as it seems to.

3 3

Modelling Java Interfaces with Existential data types
by Mike Aizatsky 08 Jun '04

08 Jun '04

Hello, I'm in process of rewriting the old Java application. While this is for sure lots of fun, there're some problems in modeling the java interfaces. Here's the common Java scenario (it's actually the pattern, common for all OO-languages, so there should be no problems in understanding it): interface MyInterface { int foo(); } class MyImplementation1 implements MyInterface { int foo() {...} } class MyImplementation2 implements MyInterface { int foo() {...} } And, somewhere in the code: int bar(List<MyInterface> list) { .... sum up all foos & return .... } I've found quite an obvious translation of it to Haskell: module Ex where class MyInterface a where foo :: a -> Int data AnyMyInterface = forall a. (MyInterface a) => AnyMyInterface a instance MyInterface AnyMyInterface where foo (AnyMyInterface a) = foo a data MyImplementation1 = MyImplementation1 Int instance MyInterface MyImplementation1 where foo(MyImplementation1 i) = i data MyImplementation2 = MyImplementation2 Int instance MyInterface MyImplementation2 where foo(MyImplementation2 i) = i type MyList = [AnyMyInterface] list1 :: MyList list1 = [AnyMyInterface (MyImplementation1 10), AnyMyInterface (MyImplementation2 20)] bar :: MyList -> Int bar l = sum (map foo l) However there're some problems with this way to go: 1. It's quite verbose. I already have a dozen of such interfaces, and I'm a bit tired of writing all this AnyInterface stuff. I'm already thinking about writing the Template Haskell code to generate it. Is anything similar available around? 2. I don't like the fact that I need to wrap all implementations inside the AnyMyInterface when returning values (see list1). Any way to get rid of it? 3. The big problem. I can't make AnyMyInterface to be an instance of Eq. I write: data AnyMyInterface = forall a. (MyInterface a, Eq a) => AnyMyInterface a instance Eq AnyMyInterface where (==) (AnyMyInterface a1) (AnyMyInterface a2) = a1 == a2 And it gives me an error (ghc 6.2.1): Inferred type is less polymorphic than expected Quantified type variable `a1' is unified with another quantified type variable `a' When checking an existential match that binds a1 :: a a2 :: a1 The pattern(s) have type(s): AnyMyInterface AnyMyInterface The body has type: Bool In the definition of `==': == (AnyMyInterface a1) (AnyMyInterface a2) = a1 == a2 In the definition for method `==' Honestly, I don't understand what's going on. My guess is that the problem comes from the fact that a1 & a2 might be of different Implementations. Is it right? Any way to define the Eq instance of AnyMyInterface? So, it looks like that existential data types do allow you to mimic the polymorphic data structures, found in OO languages. But it results in much more verbose code. Are there any other ways to do the same stuff?

2 2