November 2001 - Glasgow-haskell-users

RE: (no subject)
by Yu Chen 26 Nov '01

26 Nov '01

hi, i've found the reason with someone's help. it is because i used "%code" instead of "safecode" in the gc file where i did callback. thanks! ---- chenyu ---------- Original Message ---------------------------------- From: "Simon Marlow" <simonmar(a)microsoft.com> Date: Mon, 26 Nov 2001 09:42:39 -0000 > >> i use green-card with ghc's FFI export to sth like >> >> Haskell -----> C ------> Haskell >> >> the program is just arithmatic operations. the program "seg fault" >> in the callback from C to Haskell. anyone whether it is a bug? > >There aren't any known bugs, but there are many known pitfalls. You'll >need to give us more information, at least: the code that causes the >crash (preferably a small example), the exact GHC command lines used to >compile it, your GHC version, your machine and OS version. > >Cheers, > Simon >

1 0

RE: GHC garbage collector
by Simon Marlow 26 Nov '01

26 Nov '01

> I have some code that uses FFI capabilities to associate > previously allocated > memory with a structure akin to a ByteArray and allows > Haskell land to read > and write to the C side of things. > > I use ForeignPtr and associate a destructor to allow the GHC's garbage > collector to clean up after it figures out that the structure > is no longer > being used. I know I am in funny territory. > > In some instances (when benchmarking) GHC takes its time > getting around to > garbage collecting. Can someone suggest hooks to encourage > GHC to clean up > things? Or better still functions to instruct GHC to garbage > collect specific > structures (by calling relevant destructors)? Also comments > on how safe this > whole business is. IOExts.performGC will cause a full garbage collection to be performed. If you want to be sure the finalizer has run to completion, you'll need to set up some synchronisation between the main thread and the finalizer using MVars. Finalizers have no special scheduling properties; they just run concurrently with the other threads in the system. Cheers, Simon

1 0

RE: (no subject)
by Simon Marlow 26 Nov '01

26 Nov '01

> i use green-card with ghc's FFI export to sth like > > Haskell -----> C ------> Haskell > > the program is just arithmatic operations. the program "seg fault" > in the callback from C to Haskell. anyone whether it is a bug? There aren't any known bugs, but there are many known pitfalls. You'll need to give us more information, at least: the code that causes the crash (preferably a small example), the exact GHC command lines used to compile it, your GHC version, your machine and OS version. Cheers, Simon

1 0

(no subject)
by Yu Chen 24 Nov '01

24 Nov '01

hi, there, i use green-card with ghc's FFI export to sth like Haskell -----> C ------> Haskell the program is just arithmatic operations. the program "seg fault" in the callback from C to Haskell. anyone whether it is a bug? TIA! ------ chenyu

1 0

GHC garbage collector
by Rahul Bhargava 23 Nov '01

23 Nov '01

Hi, I have some code that uses FFI capabilities to associate previously allocated memory with a structure akin to a ByteArray and allows Haskell land to read and write to the C side of things. I use ForeignPtr and associate a destructor to allow the GHC's garbage collector to clean up after it figures out that the structure is no longer being used. I know I am in funny territory. In some instances (when benchmarking) GHC takes its time getting around to garbage collecting. Can someone suggest hooks to encourage GHC to clean up things? Or better still functions to instruct GHC to garbage collect specific structures (by calling relevant destructors)? Also comments on how safe this whole business is. Before I launch myself into making obscene calls to GHC's internals, I should know what I am dealing with. Cheers Rahul

1 0

RE: Existentials and newtype
by Simon Peyton-Jones 23 Nov '01

23 Nov '01

| Summarizing: without single-field existentially quantified | constructors in newtypes either my code gets less readable or | I have to pay a run-time price. Is it possible to relax the | restriction on newtypes in combination with existentials? Yes, that's a fair point. Unfortunately, newtype existentials are tricky in GHC, because GHC's intermediate language is strongly typed. At the moment, existentials show up in that intermediate language solely mediated through data constructors. Newtypes have gone away by the time we are in the intermediate language. So there's nowhere to 'hang' the existential for a newtype. Would be easy to add existentials to the intermediate language? Unfortunately, not very, unless I misunderstand and someone can help me out. Corresponding to the types, we have terms to introduce and elminate the type: Forall type Big lambda e.g. /\a. \x::a -> e Type application e.g. f Int 4 Existential type what? Well, it's well understood what you need for existentials: a sort of pair for introduction and a sort of case for elimination. But I am deeply reluctant to add two new constructors to the Core language data type, which only has 8 constructors right now, and which deals quite happily with data-constructor-mediated existentials. Adding extra forms of Core would complicate every single compiler pass. I've written at some length because I want first class existentials too; see the paper that Mark and I wrote http://research.microsoft.com/~simonpj/papers/first-class-modules But I'm a bit stuck at the moment about how to slip them into Core without making a big heap of work. Simon

1 0

Re: hsc: Passing -1 as CString/Ptr a?
by Marcin 'Qrczak' Kowalczyk 22 Nov '01

22 Nov '01

Thu, 22 Nov 2001 13:57:32 +0100, Volker Stolz <vs(a)foldr.org> pisze: > Hi, I want to invoke the C-function 'dlsym', which has three > possible options for a parameter of type (void*): > > - NULL > - void* to a string, i.e. CString in Haskell > - RTLD_NEXT = (void *)(-1) You can obtain the value from an embedded C function. foreign import unsafe rtldNext :: Ptr a #def inline void *rtldNext (void) {return RTLD_NEXT;} -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ QRCZAK

1 0

Existentials and newtype
by Arthur Baars 22 Nov '01

22 Nov '01

At glasgow-haskell-bugs(a)haskell.org I asked the following: > this works > > data Exists f = forall x . E ( f x) > > this doesn't work > > newtype Exists f = forall x . E ( f x) > > Hugs accepts both. > > It there a reason why existential quantification does not work with a > newtype, or is it just > a parser problem? This problem is clearly not a bug but a restriction imposed by the designers of GHC, as Keith Wansbrough pointed out to me: > >From the manual, section 7.12.3 "Restrictions": > > --8<-- > You can't use existential quantification for newtype declarations. So this is illegal: > newtype T = forall a. Ord a => MkT a > > Reason: a value of type T must be represented as a pair of a > dictionary for Ord t and a value of type t. That contradicts the idea > that newtype should have no concrete representation. You can get just > the same efficiency and effect by using data instead of newtype. If > there is no overloading involved, then there is more of a case for > allowing an existentially-quantified newtype, because the data because > the data version does carry an implementation cost, but single-field > existentially quantified constructors aren't much use. So the simple > restriction (no existential stuff on newtype) stands, unless there are > convincing reasons to change it. > --8<-- I perfectly understand why the use of class constraints in combination with newtype and existential quantification is illegal. In my opinion the restriction should only forbit this particular combination, instead of all uses of newtype with existentials. For me single-field existentially quantified constructors are quite useful: For example newtype Exists f = forall x . E (f x) data Object a = Object {value :: a , toString:: a -> String } data Thing a = Thing {val :: a , next :: a -> a, run :: a -> IO ()} -- Here I hide the type variables of Object and Thing using the type Exists: type EObject = Exists Object type EThing = Exists Thing without single-field existentially quantified constructors I would have to write: data EObject = forall a . EObject a (a -> String) data EThing = forall a . EThing a (a -> a) (a-> IO ()) or write the Exists type using data When using data I have to pay a (however small) run-time cost, that I would not have to pay when using a newtype. The other solution does not have this run-time cost, but it makes my code less readable: I have to invent new types and constructor names. I cannot use named fields. I cannot reuse polymorphic functions that work on Object on EObjects. Summarizing: without single-field existentially quantified constructors in newtypes either my code gets less readable or I have to pay a run-time price. Is it possible to relax the restriction on newtypes in combination with existentials? Cheers, Arthur

1 0

RE: Socket library ghc 5.02.1
by Simon Marlow 22 Nov '01

22 Nov '01

> Am 22. Nov 2001 um 16:22 MET schrieb Simon Marlow: > > I'm sad to say there was another bug in > SocketPrim.getSocketOption in > > 5.02.1. Please try the enclosed patch. > > How does this explain the two differing behaviours? > And why didn't it happen in a compiled version? Because the 'optlen' parameter to getsockopt was wrong (1 instead of sizeof(int)), which means that the other 3 bytes would be garbage. If the other 3 bytes happened to be zero, you probably wouldn't notice. Anyway, I've tested this with the latest sources and it seems to work, whereas I can repro the bug with 5.02.1 in GHCi. Cheers, Simon

1 0

RE: Socket library ghc 5.02.1
by Simon Marlow 22 Nov '01

22 Nov '01

> In local.glasgow-haskell-users, you wrote: > > It seems that the Socket library does still not work > > with ghc 5.02.1. > > [ghci clarification] > There, it crashes for me even on the 2nd invocation: > > connect(13, {sin_family=AF_INET, sin_port=htons(80), > sin_addr=inet_addr("137.226.194.33")}}, 16) = -1 EINPROGRESS > (Operation now in progress) > gettimeofday({1006436761, 219035}, NULL) = 0 > select(14, [], [13], NULL, {134, 217727}) = 1 (out [13], left > {134, 220000}) > getsockopt(13, SOL_SOCKET, SO_ERROR, [1835091456], [1]) = 0 > write(1, "*", 1) = 1 > > whereas on the first, succeeding call to 'connect' it says; > > select(14, [], [13], NULL, {134, 217727}) = 1 (out [13], left > {134, 210000}) > getsockopt(13, SOL_SOCKET, SO_ERROR, [0], [1]) = 0 I'm sad to say there was another bug in SocketPrim.getSocketOption in 5.02.1. Please try the enclosed patch. Cheers, Simon

2 1