From kyagrd at gmail.com Sat Sep 5 12:08:13 2009 From: kyagrd at gmail.com (Ahn, Ki Yung) Date: Sat Sep 5 11:47:48 2009 Subject: ghc --help displays obsolete URL Message-ID: $ ghc --help ... The User's Guide has more information about GHC's *many* options. An online copy can be found here: http://www.haskell.org/ghc/documentation.html ------------------------------------------------------------------------ The above URL does not exist! Hope it gets fixed in 6.12.x From pjdennis at gmail.com Sat Sep 5 12:38:26 2009 From: pjdennis at gmail.com (Phil Dennis) Date: Sat Sep 5 12:17:37 2009 Subject: ghc --help displays obsolete URL In-Reply-To: References: Message-ID: <441dad160909050938m27972d5bqe3cd689e41a7a1d1@mail.gmail.com> Or... someone could put the URL back up as a redirect to the current location of the documentation :) 2009/9/5 Ahn, Ki Yung > $ ghc --help > > ... > > The User's Guide has more information about GHC's *many* options. An > online copy can be found here: > > http://www.haskell.org/ghc/documentation.html > > ------------------------------------------------------------------------ > > > The above URL does not exist! Hope it gets fixed in 6.12.x > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090905/b7a80a8d/attachment.html From phercek at gmail.com Mon Sep 7 06:05:27 2009 From: phercek at gmail.com (Peter Hercek) Date: Mon Sep 7 05:44:57 2009 Subject: few questions about GHC RTS In-Reply-To: <4A8BE03B.4020001@gmail.com> References: <4A8BE03B.4020001@gmail.com> Message-ID: <4AA4DAE7.30900@gmail.com> Simon Marlow wrote: > On 19/08/2009 10:18, Peter Hercek wrote: >> Why is stg_nofoceIO_info added as last argument to IO actions in >> unregistered mode? Do I still need to pass it in even when (I think) my >> IO action does not need it? E.g. is it required for every IO action by >> some stack walking code or something? > > The comment in Interpreter.c says > > // Note [unreg]: in unregisterised mode, the return > // convention for IO is different. The > // stg_noForceIO_info stack frame is necessary to > // account for this difference. > > However, the return convention for IO is now the same under both > registerised and unregisterised builds (I made the change becuase of > the proliferation of obscure conditional RTS code like the above), so > I'm guessing the stg_noforceIO_info hack, and the above comment, are > now redundant. It needs testing though. Just for your information. I was curious and tried to remove the additional stg_noforceIO_info argument. Breakpoints stopped to be called but otherwise ghci seemed to work fine. It was surprising. It looked like the call to rts_breakpoint_io_action was somehow optimized away but I would not expect any optimizations at this level. Maybe I did not do it correctly. The patch I used is at the end of this email. Thanks, Peter. hunk ./rts/Interpreter.c 879 // in a reasonable state for the GC and so that // execution of this BCO can continue when we resume ioAction = (StgClosure *) deRefStablePtr (rts_breakpoint_io_action); - Sp -= 9; - Sp[8] = (W_)obj; $ - Sp[7] = (W_)&stg_apply_interp_info; - Sp[6] = (W_)&stg_noforceIO_info; // see [unreg] below + Sp -= 8; + Sp[7] = (W_)obj; $ + Sp[6] = (W_)&stg_apply_interp_info; Sp[5] = (W_)new_aps; // the AP_STACK Sp[4] = (W_)BCO_PTR(arg3_freeVars); // the info about local vars of the breakpoint Sp[3] = (W_)False_closure; // True <=> a breakpoint hunk ./rts/Interpreter.c 885 - Sp[2] = (W_)&stg_ap_pppv_info; + Sp[2] = (W_)&stg_ap_ppp_info; Sp[1] = (W_)ioAction; // apply the IO action to its two arguments above Sp[0] = (W_)&stg_enter_info; // get ready to run the IO action hunk ./rts/Interpreter.c 888 - // Note [unreg]: in unregisterised mode, the return - // convention for IO is different. The - // stg_noForceIO_info stack frame is necessary to - // account for this difference. // set the flag in the TSO to say that we are now // stopping at a breakpoint so that when we resume From g.schwanen at gmail.com Mon Sep 7 14:12:24 2009 From: g.schwanen at gmail.com (Gabriel Schwanen) Date: Mon Sep 7 13:51:30 2009 Subject: no backspace, delete or arrow keys in ghci Message-ID: <4AA54D08.3040902@gmail.com> Hello to everybody, I'm currently working with Haskell via the ghc interpreter (version 6.10.4 on Ubuntu 9.10). The problem, if it is really a problem and not a normal comportement, happens when I try, as example, to enter some characters after having execute getLine. Actually, if I make a mistake when typing the string, I can't use neither backspace, delete or even arrow keys to correct it before hitting enter to finish input. In fact, as example, if I hit backspace, I get "^?" in place of deleting the previous character ... :^( As I wrote above, I don't know if it is a "bug" or not. Maybe it is normal. Can someone help me ? Thanks in advance, Gabriel From judah.jacobson at gmail.com Mon Sep 7 14:24:47 2009 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Mon Sep 7 14:04:11 2009 Subject: no backspace, delete or arrow keys in ghci In-Reply-To: <4AA54D08.3040902@gmail.com> References: <4AA54D08.3040902@gmail.com> Message-ID: <6d74b0d20909071124h6a5bcebmeca425f7b93a9ab2@mail.gmail.com> On Mon, Sep 7, 2009 at 11:12 AM, Gabriel Schwanen wrote: > Hello to everybody, > > I'm currently working with Haskell via the ghc interpreter (version 6.10.4 > on Ubuntu 9.10). > > The problem, if it is really a problem and not a normal comportement, > happens when I try, as example, to enter some characters after having > execute getLine. Actually, if I make a mistake when typing the string, I > can't use neither backspace, delete or even arrow keys to correct it before > hitting enter to finish input. In fact, as example, if I hit backspace, I > get "^?" in place of deleting the previous character ... :^( > > As I wrote above, I don't know if it is a "bug" or not. Maybe it is normal. > > Can someone help me ? > I'm not sure I understand. Are you saying that you can't use backspace/arrows/etc when the getLine command itself is waiting for input? But otherwise at the "Prelude>" prompt, where you type in the commands, everything behaves fine? If so, that is normal behavior for the getLine function. For a better input interface I'd recommend either the haskeline or readline packages, both available from hackage.haskell.org. Best, -Judah From g.schwanen at gmail.com Mon Sep 7 14:50:37 2009 From: g.schwanen at gmail.com (Gabriel Schwanen) Date: Mon Sep 7 14:29:44 2009 Subject: no backspace, delete or arrow keys in ghci In-Reply-To: <6d74b0d20909071124h6a5bcebmeca425f7b93a9ab2@mail.gmail.com> References: <4AA54D08.3040902@gmail.com> <6d74b0d20909071124h6a5bcebmeca425f7b93a9ab2@mail.gmail.com> Message-ID: <4AA555FD.9010709@gmail.com> Yes, it is when getLine is waiting for input. Everything is fine in the prompt. I didn't know that getLine behaves like that. I surely missed something. Trully sorry for, at the end, a so dumb question ! I'll follow your advices and try haskeline or readline :-) Anyway, many thanks for your so quick reply. Best regards, Gabriel Judah Jacobson a ?crit : > On Mon, Sep 7, 2009 at 11:12 AM, Gabriel Schwanen wrote: > >> Hello to everybody, >> >> I'm currently working with Haskell via the ghc interpreter (version 6.10.4 >> on Ubuntu 9.10). >> >> The problem, if it is really a problem and not a normal comportement, >> happens when I try, as example, to enter some characters after having >> execute getLine. Actually, if I make a mistake when typing the string, I >> can't use neither backspace, delete or even arrow keys to correct it before >> hitting enter to finish input. In fact, as example, if I hit backspace, I >> get "^?" in place of deleting the previous character ... :^( >> >> As I wrote above, I don't know if it is a "bug" or not. Maybe it is normal. >> >> Can someone help me ? >> >> > > I'm not sure I understand. Are you saying that you can't use > backspace/arrows/etc when the getLine command itself is waiting for > input? But otherwise at the "Prelude>" prompt, where you type in the > commands, everything behaves fine? > > If so, that is normal behavior for the getLine function. For a better > input interface I'd recommend either the haskeline or readline > packages, both available from hackage.haskell.org. > > Best, > -Judah > From marlowsd at gmail.com Tue Sep 8 06:53:10 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Sep 8 06:32:19 2009 Subject: ghc --help displays obsolete URL In-Reply-To: <441dad160909050938m27972d5bqe3cd689e41a7a1d1@mail.gmail.com> References: <441dad160909050938m27972d5bqe3cd689e41a7a1d1@mail.gmail.com> Message-ID: <4AA63796.2010905@gmail.com> On 05/09/2009 17:38, Phil Dennis wrote: > Or... someone could put the URL back up as a redirect to the current > location of the documentation :) Done. Simon From duncan.coutts at worc.ox.ac.uk Tue Sep 8 15:13:51 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Sep 8 14:58:35 2009 Subject: no backspace, delete or arrow keys in ghci In-Reply-To: <6d74b0d20909071124h6a5bcebmeca425f7b93a9ab2@mail.gmail.com> References: <4AA54D08.3040902@gmail.com> <6d74b0d20909071124h6a5bcebmeca425f7b93a9ab2@mail.gmail.com> Message-ID: <1252437231.5266.3455.camel@localhost> On Mon, 2009-09-07 at 11:24 -0700, Judah Jacobson wrote: > I'm not sure I understand. Are you saying that you can't use > backspace/arrows/etc when the getLine command itself is waiting for > input? But otherwise at the "Prelude>" prompt, where you type in the > commands, everything behaves fine? > > If so, that is normal behavior for the getLine function. For what it's worth, while ghci has behaved this way for a long time (since at least 6.4), hugs seems to work more nicely in this regard. In hugs when you getLine it seems to switch into cooked mode so you at least get backspace etc. Duncan From mechvel at botik.ru Wed Sep 9 07:46:04 2009 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Wed Sep 9 07:33:31 2009 Subject: fromEnum (c :: Char) Message-ID: <20090909114604.GA21401@scico.botik.ru> People, I need to convert Char <-> Int in a possibly _standard_ way for Haskell -- and also in an efficient way. In particular, it must not spend 100 comparisons in a look through the listing of Char. I use ord :: Char -> Int and chr :: Int -> Char. Is this all right? Thank you in advance for advice, ----------------- Serge Mechveliani mechvel@botik.ru From dons at galois.com Wed Sep 9 08:10:43 2009 From: dons at galois.com (Don Stewart) Date: Wed Sep 9 07:52:15 2009 Subject: fromEnum (c :: Char) In-Reply-To: <20090909114604.GA21401@scico.botik.ru> References: <20090909114604.GA21401@scico.botik.ru> Message-ID: <20090909121043.GA3390@whirlpool.galois.com> mechvel: > People, > I need to convert Char <-> Int in a possibly _standard_ way for > Haskell -- and also in an efficient way. In particular, it must not > spend 100 comparisons in a look through the listing of Char. > > I use ord :: Char -> Int and chr :: Int -> Char. ord and chr are correct, yes. ord :: Char -> Int ord (C# c#) = I# (ord# c#) chr :: Int -> Char chr (I# i#) | int2Word# i# `leWord#` int2Word# 0x10FFFF# = C# (chr# i#) | otherwise = error "Prelude.chr: bad argument" unsafeChr :: Int -> Char unsafeChr (I# i#) = C# (chr# i#) These are usually resolved at compile time as casts. -- Don From stefan at cs.uu.nl Wed Sep 9 09:37:55 2009 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Wed Sep 9 09:16:58 2009 Subject: Resolving overloading loops for circular constraint graph Message-ID: <74E497E9-3AF7-43CF-B48E-7052134112D4@cs.uu.nl> Manuel, Simon, I've spotted a hopefully small but for us quite annoying bug in GHC's type checker: it loops when overloading resolving involves a circular constraint graph containing type-family applications. The following program (also attached) demonstrates the problem: {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE TypeFamilies #-} type family F a :: * type instance F Int = (Int, ()) class C a instance C () instance (C (F a), C b) => C (a, b) f :: C (F a) => a -> Int f _ = 2 main :: IO () main = print (f (3 :: Int)) My guess is that the loop is caused by the constraint C (F Int) that arises from the use of f in main: C (F Int) = C (Int, ()) <= C (F Int) Indeed, overloading can be resolved successfully by "black-holing" the initial constraint, but it seems like the type checker refuses to do so. Can you confirm my findings? I'm not sure whether this is a known defect. If it isn't, I'd be more than happy to issue a report. Since this problem arises in a piece of very mission-critical code, I would be pleased to learn about any workarounds. Thanks in advance, Stefan From mechvel at botik.ru Wed Sep 9 12:45:52 2009 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Wed Sep 9 12:33:10 2009 Subject: Functor Message-ID: <20090909164552.GA21487@scico.botik.ru> People, I have data DBit = Bit0 | Bit1 deriving (Eq, Ord, Enum) data BNatural = BNat [DBit] deriving (Eq) and want to apply things like fmap reverse (bn :: BNatural). GHC reports an error on this usage of fmap. It also does not allow instance Functor BNatural where fmap f (BNat ds) = BNat $ f ds, -- it reports that a type constructor for Functor must have kind * -> *. Probaly, GHC agrees with Haskell at this point (?). Now, I deceive the compiler by declaring instead newtype BNatAux a = BNat a deriving (Eq) type BNatural = BNatAux [DBit] instance Functor BNatAux where fmap f (BNat ds) = BNat $ f ds So, a parasitic BNatAux is introduced. I wonder: is there a simpler way to have fmap for BNatural ? Thank you in advance for advice, ----------------- Serge Mechveliani mechvel@botik.ru From p.k.f.holzenspies at utwente.nl Wed Sep 9 13:15:06 2009 From: p.k.f.holzenspies at utwente.nl (=?ISO-8859-1?Q?=22Philip_K.F._H=F6lzenspies=22?=) Date: Wed Sep 9 12:54:36 2009 Subject: Functor In-Reply-To: <20090909164552.GA21487@scico.botik.ru> References: <20090909164552.GA21487@scico.botik.ru> Message-ID: <1DB232EF-47A1-4EA7-9F19-E3C5EB67BB5F@utwente.nl> Dear Serge, If you want the type checker to know what type is "inside" your BNatural, no there isn't. You use reverse in your example, which has type [a] -> [a], so the type of what is in your BNatural doesn't change when you fmap reverse onto it. In general, however, you can't guarantee this. What if you fmap length? fmap length (BNat [Bit0,Bit0]) -->> BNat 2 Obviously, this violates the declaration of BNat. In this case specific case, you could maybe reason that the type checker should just reduce that only [DBit] -> [DBit] functions are allowed. However, the Functor class is set up to be more general; it allows a -> b functions. When your data type can not be instantiated as Functor this way, then it "isn't a functor" (at least, in the Haskell interpretation of functor). There is nothing to stop you from defining your own alternative map: bmap :: ([DBit] -> [DBit]) -> BNatural -> BNatural bmap f (BNat bs) = BNat $ f bs I hope this makes some sense. Regards, Philip On Sep 9, 2009, at 6:45 PM, Serge D. Mechveliani wrote: > People, > > I have data DBit = Bit0 | Bit1 deriving (Eq, Ord, Enum) > data BNatural = BNat [DBit] deriving (Eq) > > and want to apply things like fmap reverse (bn :: BNatural). > > GHC reports an error on this usage of fmap. > It also does not allow > instance Functor BNatural where fmap f (BNat ds) = BNat $ f > ds, > > -- it reports that a type constructor for Functor must have kind * - > > *. > Probaly, GHC agrees with Haskell at this point (?). > > Now, I deceive the compiler by declaring instead > > newtype BNatAux a = BNat a deriving (Eq) > type BNatural = BNatAux [DBit] > instance Functor BNatAux where fmap f (BNat ds) = BNat $ f ds > > So, a parasitic BNatAux is introduced. > I wonder: is there a simpler way to have fmap for BNatural ? > Thank you in advance for advice, > > ----------------- > Serge Mechveliani > mechvel@botik.ru > > > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From martin.sulzmann.haskell at googlemail.com Wed Sep 9 14:57:13 2009 From: martin.sulzmann.haskell at googlemail.com (Martin Sulzmann) Date: Wed Sep 9 14:36:13 2009 Subject: [Haskell-cafe] Resolving overloading loops for circular constraint graph In-Reply-To: <74E497E9-3AF7-43CF-B48E-7052134112D4@cs.uu.nl> References: <74E497E9-3AF7-43CF-B48E-7052134112D4@cs.uu.nl> Message-ID: <4bb51c60909091157u4efe6e62mdf32af7a449c404@mail.gmail.com> Your example must loop because as you show below the instance declaration leads to a cycle. By "black-holing" you probably mean co-induction. That is, if the statement to proven appears again, we assume it must hold. However, type classes are by default inductive, so there's no easy fix to offer to your problem. In any case, this is not a bug, you simply play with fire once type functions show up in the instance context. There are sufficient conditions to guarantee termination, but they are fairly restrictive. -Martin 2009/9/9 Stefan Holdermans > Manuel, Simon, > > I've spotted a hopefully small but for us quite annoying bug in GHC's type > checker: it loops when overloading resolving involves a circular constraint > graph containing type-family applications. > > The following program (also attached) demonstrates the problem: > > {-# LANGUAGE FlexibleContexts #-} > {-# LANGUAGE TypeFamilies #-} > > type family F a :: * > type instance F Int = (Int, ()) > > class C a > instance C () > instance (C (F a), C b) => C (a, b) > > f :: C (F a) => a -> Int > f _ = 2 > > main :: IO () > main = print (f (3 :: Int)) > > My guess is that the loop is caused by the constraint C (F Int) that arises > from the use of f in main: > > C (F Int) = C (Int, ()) <= C (F Int) > > Indeed, overloading can be resolved successfully by "black-holing" the > initial constraint, but it seems like the type checker refuses to do so. > > Can you confirm my findings? > > I'm not sure whether this is a known defect. If it isn't, I'd be more than > happy to issue a report. > > Since this problem arises in a piece of very mission-critical code, I would > be pleased to learn about any workarounds. > > Thanks in advance, > > Stefan > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090909/213e5261/attachment.html From stefan at cs.uu.nl Wed Sep 9 15:35:55 2009 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Wed Sep 9 15:15:06 2009 Subject: [Haskell-cafe] Resolving overloading loops for circular constraint graph In-Reply-To: <4bb51c60909091157u4efe6e62mdf32af7a449c404@mail.gmail.com> References: <74E497E9-3AF7-43CF-B48E-7052134112D4@cs.uu.nl> <4bb51c60909091157u4efe6e62mdf32af7a449c404@mail.gmail.com> Message-ID: Dear Martin, > Your example must loop because as you show below > the instance declaration leads to a cycle. > By "black-holing" you probably mean co-induction. That is, > if the statement to proven appears again, we assume it must hold. > However, type classes are by default inductive, so there's no > easy fix to offer to your problem. Yes, I meant coinductive resolving of overloading. By that line of reasoning, the following should loop as well, but doesn't: {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE UndecidableInstances #-} class C a instance C () instance (C (a, ()), C b) => C (a, b) f :: C (a, ()) => a -> Int f _ = 2 main :: IO () main = print (f (3 :: Int)) Note: here I would accept looping behaviour as this program requires undecidable instances. > In any case, this is not a bug, you simply play with fire > once type functions show up in the instance context. > There are sufficient conditions to guarantee termination, > but they are fairly restrictive. I disagree: it is a bug. I think the original program should require undecidable instances as well: indeed, the presence of the type family makes that the constraint is possibly no smaller than the instance head. However, without the undecidable-instance requirement (i.e., as it is now), I expect type checking to terminate. Cheers, Stefan From stefan at cs.uu.nl Wed Sep 9 15:48:08 2009 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Wed Sep 9 15:27:13 2009 Subject: Resolving overloading loops for circular constraint graph In-Reply-To: <4bb51c60909091157u4efe6e62mdf32af7a449c404@mail.gmail.com> References: <74E497E9-3AF7-43CF-B48E-7052134112D4@cs.uu.nl> <4bb51c60909091157u4efe6e62mdf32af7a449c404@mail.gmail.com> Message-ID: Dear Martin, > By "black-holing" you probably mean co-induction. That is, > if the statement to proven appears again, we assume it must hold. > However, type classes are by default inductive, so there's no > easy fix to offer to your problem. A propos: are there fundamental objections to coinductive resolving, i.e., constructing recursive dictionaries. I suppose termination is hard to guarantee then: is it enough to require constraints to be productive w.r.t. instance heads? Cheers, Stefan From simonpj at microsoft.com Thu Sep 10 04:55:29 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Sep 10 04:35:30 2009 Subject: Resolving overloading loops for circular constraint graph In-Reply-To: <74E497E9-3AF7-43CF-B48E-7052134112D4@cs.uu.nl> References: <74E497E9-3AF7-43CF-B48E-7052134112D4@cs.uu.nl> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C363F9B9EBA9@EA-EXMSG-C334.europe.corp.microsoft.com> Stefan You are trying to do something quite delicate here. The whole idea of solving constraints in a co-inductive way (building a recursive group of dictionary definitions) relies on spotting something we've seen before to "tie the knot". To date, the main application I knew for this fairly exotic idea was described in the SYB3 paper [1]. So I'm curious about your application (and that of anyone else) that relies on this recursive-dictionary-solving mechanism. Returning to your problem, this "loop spotting" mechanism is rather syntactic at the moment, whereas your application needs something more refined, involving equality modulo type function reductions. Alas, the constraint solving machinery for type classes and for type functions is not properly integrated. I'm amazed it works as well as it does, actually. We [Manuel, Dimitrios, and I] are (slowly, slowly) working on a complete rewrite of GHC's constraint-solving mechanism. I'm pretty sure that it'll solve this problem among many others. But don't hold your breath. It'll be months not weeks. But not years! sorry not to be able to solve your problem sooner. I'll open a ticket. Simon [1] http://research.microsoft.com/~simonpj/papers/hmap | -----Original Message----- | From: Stefan Holdermans [mailto:stefan@cs.uu.nl] | Sent: 09 September 2009 14:38 | To: Manuel M T Chakravarty; Simon Peyton-Jones | Cc: glasgow-haskell-users; haskell-cafe; Jos? Pedro Magalh?es; Thomas van Noort; | Johan Jeuring | Subject: Resolving overloading loops for circular constraint graph | | Manuel, Simon, | | I've spotted a hopefully small but for us quite annoying bug in GHC's | type checker: it loops when overloading resolving involves a circular | constraint graph containing type-family applications. | | The following program (also attached) demonstrates the problem: | | {-# LANGUAGE FlexibleContexts #-} | {-# LANGUAGE TypeFamilies #-} | | type family F a :: * | type instance F Int = (Int, ()) | | class C a | instance C () | instance (C (F a), C b) => C (a, b) | | f :: C (F a) => a -> Int | f _ = 2 | | main :: IO () | main = print (f (3 :: Int)) | | My guess is that the loop is caused by the constraint C (F Int) that | arises from the use of f in main: | | C (F Int) = C (Int, ()) <= C (F Int) | | Indeed, overloading can be resolved successfully by "black-holing" the | initial constraint, but it seems like the type checker refuses to do so. | | Can you confirm my findings? | | I'm not sure whether this is a known defect. If it isn't, I'd be more | than happy to issue a report. | | Since this problem arises in a piece of very mission-critical code, I | would be pleased to learn about any workarounds. | | Thanks in advance, | | Stefan From martin.sulzmann.haskell at googlemail.com Thu Sep 10 14:54:50 2009 From: martin.sulzmann.haskell at googlemail.com (Martin Sulzmann) Date: Thu Sep 10 14:33:55 2009 Subject: Resolving overloading loops for circular constraint graph In-Reply-To: References: <74E497E9-3AF7-43CF-B48E-7052134112D4@cs.uu.nl> <4bb51c60909091157u4efe6e62mdf32af7a449c404@mail.gmail.com> Message-ID: <4bb51c60909101154i57685c64mf0e7f60355951155@mail.gmail.com> 2009/9/9 Stefan Holdermans > Dear Martin, > > By "black-holing" you probably mean co-induction. That is, >> if the statement to proven appears again, we assume it must hold. >> However, type classes are by default inductive, so there's no >> easy fix to offer to your problem. >> > > A propos: are there fundamental objections to coinductive resolving, i.e., > constructing recursive dictionaries. I suppose termination is hard to > guarantee then: is it enough to require constraints to be productive w.r.t. > instance heads? > > Yes, you need instances to be productive, otherwise, you get bogus cyclic proofs like instance Foo a => Foo a dictFooa = dictFooa You could call this a bug, or simply blame the programmer for writing down a 'bogus' instance. Under co-inductive type class solving more (type class) programs will terminate (my guess). Here are some references: Satish R. Thatte: Semantics of Type Classes Revisited. LISP and Functional Programming 1994: 208-219 As far as I know, the first paper which talks about co-induction and type classes. I myself and some co-workers explored this idea further in some unpublished draft: AUTHOR = {M. Sulzmann and J. Wazny and P. J. Stuckey}, TITLE = {Co-induction and Type Improvement in Type Class Proofs}, NOTE = {Manuscript}, YEAR = {2005}, MONTH = {July}, PS = {http://www.cs.mu.oz.au/~sulzmann/manuscript/coind-type-class-proofs.ps } I'm quite fond of co-induction because it's such an elegant and powerful proof technique. However, GHC's co-induction mechanism is fairly limited, see Simon's reply, so I'm also curious to see what's happening in the future. -Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090910/c259bd76/attachment.html From igloo at earth.li Fri Sep 11 12:20:19 2009 From: igloo at earth.li (Ian Lynagh) Date: Fri Sep 11 11:59:20 2009 Subject: Libraries in the repo In-Reply-To: <4A979E1C.6060309@gmail.com> References: <4A955F9B.904@gmail.com> <52f14b210908270325h31b53bcay7494b141d0ca94f6@mail.gmail.com> <4A979E1C.6060309@gmail.com> Message-ID: <20090911162019.GA13741@matrix.chaos.earth.li> On Fri, Aug 28, 2009 at 10:06:36AM +0100, Simon Marlow wrote: > On 27/08/2009 11:25, Jos? Pedro Magalh?es wrote: >> Hello, >> >> On Wed, Aug 26, 2009 at 18:15, Simon Marlow > > wrote: >> >> >> * Boot libraries are of several kinds: >> - INDEPENDENT: Independently maintained (e.g. time, haskeline) >> - COUPLED: Tightly coupled to GHC, but used by others (base) >> - SPECIFIC: Totally specific to GHC (e.g. template-haskell, DPH) >> >> >> Does syb fall under INDEPENDENT or COUPLED? >> >> In any case, as the syb maintainer, I'd favor (1) too. > > I'd say at this stage it's INDEPENDENT. I think that once we move rebase3-compat (in the next few days, in the HEAD), the only thing that needs syb is extcore. Is that sufficient that it is worth keeping it as a core lib? Thanks Ian From catamorphism at gmail.com Fri Sep 11 12:47:55 2009 From: catamorphism at gmail.com (Tim Chevalier) Date: Fri Sep 11 12:26:46 2009 Subject: Libraries in the repo In-Reply-To: <20090911162019.GA13741@matrix.chaos.earth.li> References: <4A955F9B.904@gmail.com> <52f14b210908270325h31b53bcay7494b141d0ca94f6@mail.gmail.com> <4A979E1C.6060309@gmail.com> <20090911162019.GA13741@matrix.chaos.earth.li> Message-ID: <4683d9370909110947p75fba0ddx95866b21d5f686b7@mail.gmail.com> 2009/9/11 Ian Lynagh : > On Fri, Aug 28, 2009 at 10:06:36AM +0100, Simon Marlow wrote: >> On 27/08/2009 11:25, Jos? Pedro Magalh?es wrote: >>> Hello, >>> >>> On Wed, Aug 26, 2009 at 18:15, Simon Marlow >> > wrote: >>> >>> >>> ? ? ? * Boot libraries are of several kinds: >>> ? ? ? ?- INDEPENDENT: Independently maintained (e.g. time, haskeline) >>> ? ? ? ?- COUPLED: Tightly coupled to GHC, but used by others (base) >>> ? ? ? ?- SPECIFIC: Totally specific to GHC (e.g. template-haskell, DPH) >>> >>> >>> Does syb fall under INDEPENDENT or COUPLED? >>> >>> In any case, as the syb maintainer, I'd favor (1) too. >> >> I'd say at this stage it's INDEPENDENT. > > I think that once we move rebase3-compat (in the next few days, in the > HEAD), the only thing that needs syb is extcore. Is that sufficient that > it is worth keeping it as a core lib? > I've meant for a long time to split off the ext-core library and put it on Hackage, since it isn't required to build GHC. I'll be doing that in the immediate future, so then, ext-core won't be a reason to keep syb coupled. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc/ * Often in error, never in doubt "an intelligent person fights for lost causes,realizing that others are merely effects" -- E.E. Cummings From igloo at earth.li Fri Sep 11 12:57:38 2009 From: igloo at earth.li (Ian Lynagh) Date: Fri Sep 11 12:36:29 2009 Subject: Libraries in the repo In-Reply-To: <4A955F9B.904@gmail.com> References: <4A955F9B.904@gmail.com> Message-ID: <20090911165738.GB13741@matrix.chaos.earth.li> I don't think the current situation has worked well, due to people forgetting to push/send to the upstream repos, but if we use a prehook script to stop people accidentally breaking the rules then (1) is probably the best solution for the HEAD. For stable branches, in order to avoid releasing with random darcs versions, I think that it would be best to use released tarballs (2). In order to migrate from GHC's bytestring fork, back to a repo compatible with the upstream repo, we can't just switch the repos, as you can't pull the new repo into an old checkout. There are some additional complications, such as people who pull from local repos rather than the darcs.haskell.org repos, which make this a little fiddly. I think we should: * switch HEAD to use a released tarball of bytestring * make darcs-all complain if libraries/bytestring is a checked out copy of the old repo (i.e. check to see if a particular patch ID is in it) * wait a couple of months * switch to using a darcs repo containing a subset of the upstream repo again Hopefully during the couple of months everyone will update and use all the repos they have lying around at least once, and thus will remove the old checkout. Thanks Ian From igloo at earth.li Fri Sep 11 16:24:46 2009 From: igloo at earth.li (Ian Lynagh) Date: Fri Sep 11 16:03:39 2009 Subject: Build error in users guide in HEAD of today In-Reply-To: References: Message-ID: <20090911202446.GA20559@matrix.chaos.earth.li> On Thu, Aug 20, 2009 at 11:43:40PM +0200, "Philip K.F. H?lzenspies" wrote: > > latex failed Where is your latex from? I think I use tetex from cygwin, but I've seen build failures with another one (miktex, possibly). Thanks Ian From igloo at earth.li Sun Sep 13 07:25:03 2009 From: igloo at earth.li (Ian Lynagh) Date: Sun Sep 13 07:03:50 2009 Subject: GHCi can't see 'atexit', can't load module In-Reply-To: References: Message-ID: <20090913112502.GA27750@matrix.chaos.earth.li> On Tue, Aug 25, 2009 at 11:20:17PM -0300, Maur??cio CA wrote: > > I just checked it seems not to be possible to load any module in > GHCi that uses FFI to wrap the standard C function 'atexit'. When > trying that, we get a message saying the symbol 'atexit' can't be > found. (This is not a problem when building an executable with > ghc, though.) It looks like the problem is that atexit is defined in the static library /usr/lib/libc_nonshared.a. I think you'll have to make a C wrapper for it in your package. Thanks Ian From marlowsd at gmail.com Mon Sep 14 04:07:28 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Sep 14 03:46:18 2009 Subject: How to move code from GHC to libraries? In-Reply-To: <20090911230213.C5161B130F@lakeland.eecs.harvard.edu> References: <4A955F9B.904@gmail.com> <4A9685D1.2000008@gmail.com> (sfid-H-20090827-091706-+154.15-1@multi.osbf.lua) <20090911230213.C5161B130F@lakeland.eecs.harvard.edu> Message-ID: <4AADF9C0.20506@gmail.com> On 12/09/2009 00:02, Norman Ramsey wrote: > > Incedentally, the reason I'd like us to make a decision on this now is > > because I'm about to add two new boot libraries... > > While we're on this topic, I've had several requests to pull HOOPL > (the new dataflow optimization code) out as a library so that we can > make it into a Hackage package. I'd like to do this, but the > situation is complicated because HOOPL depends on UniqFM, which is > GHC-specific. I thought that there was a similar implementation out > in the wild (based on Okasaki-Gill rather than Adams), but I can't > find it on hackage. Isn't Data.IntMap ~= UniqFM? > Is there an established procedure for moving a part of GHC into a > library without breaking everybody's build? If so, where will I find > it on the developers' wiki? If not, who can advise me so I can create > a page on the developers' wiki? :-) The architecture of our library setup is here: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Libraries Basically you'd be adding a new zero-boot package (that terminology isn't used in the build system, where they're called "boot packages"). The best way to find out how to add another one is to grep for an existing zero-boot package (e.g. Cabal) in the top-level ghc.mk to see the various things you need to add. The new package would need to have a repository created on darcs.haskell.org, and you'd need to add it to $(TOP)/packages too. When the changes are pushed, everyone has to "./darcs-all get" to get the new repository. Cheers, Simon From paolo.losi at gmail.com Mon Sep 14 04:33:05 2009 From: paolo.losi at gmail.com (Paolo Losi) Date: Mon Sep 14 04:11:56 2009 Subject: C++ libraries and GHCI Message-ID: <2af4014d0909140133m26691c98p4f1466ab897e89b2@mail.gmail.com> Hi all, I'm working on a tentative implementation of haskell binding to libsvm [1]: http://hackage.haskell.org/package/HSvm The package includes libsvm C++ sources. While it works perfectly with ghc --make (try to install the package and compile http://bitbucket.org/pao/hsvm/raw/6cf7ca91f1e5/test/test.hs), it fails with ghci: (hsvm)(env)paolo@moltrasio:~/trash$ ghci test.hs GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Ok, modules loaded: Main. Prelude Main> main Loading package syb ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package containers-0.2.0.1 ... linking ... done. Loading package HSvm-0.1.0.2.89 ... linking ... : /home/paolo/trash/hsvm/lib/HSvm-0.1.0.2.89/ghc-6.10.4/HSHSvm-0.1.0.2.89.o: unknown symbol `_ZTV6Kernel' ghc: unable to load package `HSvm-0.1.0.2.89' Please note that the symbol is available in libHSHSvm-0.1.0.2.89.a $ nm HSHSvm-0.1.0.2.89.o |grep _ZTV6Kernel 00000000 V _ZTV6Kernel $ nm libHSHSvm-0.1.0.2.89.a |grep _ZTV6Kernel 00000000 V _ZTV6Kernel Can anyone give a look to the problem? Thanks Paolo [1] http://www.csie.ntu.edu.tw/~cjlin/libsvm/ From leather at cs.uu.nl Tue Sep 15 07:50:45 2009 From: leather at cs.uu.nl (Sean Leather) Date: Tue Sep 15 07:31:19 2009 Subject: Malformed class assertion with GHCi's output (a -> a ~ T a) Message-ID: <3c6288ab0909150450u836b6ebpb152813b41fa4ed9@mail.gmail.com> I queried (:t) the type of something in GHCi, and it told me the value should have the constraint (a -> a ~ T a) among others. When I tried to use this in code, I got a "malformed class assertion." So, I put parentheses around the function type, ((a -> a) ~ T a), and everybody is happy again. Is there something off about the precedence of (~) vs. (->)? Should GHCi print the parentheses? I'm using GHC 6.10.1, so this might already be fixed. Regards, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090915/684357e3/attachment.html From karel.gardas at centrum.cz Tue Sep 15 10:56:01 2009 From: karel.gardas at centrum.cz (Karel Gardas) Date: Tue Sep 15 10:34:43 2009 Subject: How to solve ghc-stage2: mkTextEncoding: invalid argument (Invalid argument) issue. Message-ID: <4AAFAB01.4070504@centrum.cz> Hello, recently I've found out that my solaris-based GHC buildbot is completely unusable since it always (when it get to, which means it does not fail with usual magic number mismatch: old/corrupt interface file?) fails with: "inplace/bin/ghc-stage2" -H32m -O -DNEW_GHC_LAYOUT -hide-all-packages -i -iutils/haddock/src -iutils/haddock/dist/build -iutils/haddock/dist/build/autogen -Iutils/haddock/dist/build -Iutils/haddock/dist/build/autogen -optP-DIN_GHC_TREE -optP-include -optPutils/haddock/dist/build/autogen/cabal_macros.h -package Cabal-1.7.4 -package array-0.2.0.1 -package base-4.2.0.0 -package containers-0.2.0.1 -package directory-1.0.0.2 -package filepath-1.1.0.1 -package ghc-6.11.20090915 -package pretty-1.0.1.0 -funbox-strict-fields -O2 -Wall -XForeignFunctionInterface -XCPP -XPatternGuards -XDeriveDataTypeable -XScopedTypeVariables -XMagicHash -odir utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir utils/haddock/dist/build -hisuf hi -osuf o -hcsuf hc -c utils/haddock/src/Haddock/GhcUtils.hs -o utils/haddock/dist/build/Haddock/GhcUtils.o ghc-stage2: mkTextEncoding: invalid argument (Invalid argument) make[1]: *** [utils/haddock/dist/build/Haddock/GhcUtils.o] Error 1 make: *** [all] Error 2 I've even tried to update my building GHC from 6.8.3 to 6.10.4, but it still does not help. Since I would really like to resurrect my GHC buildbot, do you have any idea how to fix this issue? Thanks, Karel PS: for reference, please have a look at http://darcs.haskell.org/buildbot/all/builders/kgardas%20head From duncan.coutts at worc.ox.ac.uk Tue Sep 15 14:21:26 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Sep 15 15:11:47 2009 Subject: How to solve ghc-stage2: mkTextEncoding: invalid argument (Invalid argument) issue. In-Reply-To: <4AAFAB01.4070504@centrum.cz> References: <4AAFAB01.4070504@centrum.cz> Message-ID: <1253038886.19215.1892.camel@localhost> On Tue, 2009-09-15 at 16:56 +0200, Karel Gardas wrote: > Hello, > > recently I've found out that my solaris-based GHC buildbot is completely > unusable since it always (when it get to, which means it does not fail > with usual magic number mismatch: old/corrupt interface file?) fails with: > ghc-stage2: mkTextEncoding: invalid argument (Invalid argument) So that's when it calls iconv_open with the names of some text encodings. Apparently that is failing. You should be able to confirm this with some tracing. > I've even tried to update my building GHC from 6.8.3 to 6.10.4, but it > still does not help. No, it wouldn't. > Since I would really like to resurrect my GHC buildbot, do you have any > idea how to fix this issue? Dig into base/GHC/IO/Encoding/Iconv.hs mkTextEncoding function where it calls iconv_open, see what it's being called with. In particular check if HAVE_LANGINFO_H is getting defined. If it's not then the code assumes GNU iconv. > PS: for reference, please have a look at > http://darcs.haskell.org/buildbot/all/builders/kgardas%20head See also the http://darcs.haskell.org/buildbot/head/builders/sparky%20head Which is running Solaris 10 on sparc and seems to be working fine. Duncan From karel.gardas at centrum.cz Wed Sep 16 04:23:58 2009 From: karel.gardas at centrum.cz (Karel Gardas) Date: Wed Sep 16 04:02:39 2009 Subject: How to solve ghc-stage2: mkTextEncoding: invalid argument (Invalid argument) issue. In-Reply-To: <1253038886.19215.1892.camel@localhost> References: <4AAFAB01.4070504@centrum.cz> <1253038886.19215.1892.camel@localhost> Message-ID: <4AB0A09E.8040700@centrum.cz> Before going to trace anything I've compared sparky and my setup and it seems I've had forgotten libiconv library in /usr/local/lib and LD_LIBRARY_PATH contained this lib. So I've modified LD_LIBRARY_PATH to exclude /usr/local/lib and now surprisingly base configure fails with: checking for library containing iconv... no configure: error: iconv is required on non-Windows platforms make[1]: *** [libraries/base/dist-install/package-data.mk] Error 1 make: *** [all] Error 2 see: http://darcs.haskell.org/buildbot/all/builders/kgardas%20head/builds/205/steps/compile/logs/stdio When I've seen the code it's not so surprising that it fails in this way, what's in fact surprising to me is that sparky passes belong this point: checking for library containing iconv... none required configure: creating ./config.status config.status: creating base.buildinfo config.status: creating include/HsBaseConfig.h [...] See: http://darcs.haskell.org/buildbot/head/builders/sparky%20head/builds/91/steps/compile/logs/stdio I'm sorry for starting this #91 build on sparky, but I'd like verify that it does not build older source-code than my buildbot. So now, the question is: is GNU iconv really required or if it's not, how to make my buildbot ignoring it as sparky's buldbot seems to be doing? Thanks, Karel Duncan Coutts wrote: > > Dig into base/GHC/IO/Encoding/Iconv.hs mkTextEncoding function where it > calls iconv_open, see what it's being called with. > > In particular check if HAVE_LANGINFO_H is getting defined. If it's not > then the code assumes GNU iconv. > >> PS: for reference, please have a look at >> http://darcs.haskell.org/buildbot/all/builders/kgardas%20head > > See also the > > http://darcs.haskell.org/buildbot/head/builders/sparky%20head > > Which is running Solaris 10 on sparc and seems to be working fine. > > Duncan > > > From kili at outback.escape.de Wed Sep 16 05:35:06 2009 From: kili at outback.escape.de (Matthias Kilian) Date: Wed Sep 16 05:14:46 2009 Subject: How to solve ghc-stage2: mkTextEncoding: invalid argument (Invalid argument) issue. In-Reply-To: <4AB0A09E.8040700@centrum.cz> References: <4AAFAB01.4070504@centrum.cz> <1253038886.19215.1892.camel@localhost> <4AB0A09E.8040700@centrum.cz> Message-ID: <20090916093505.GA18521@petunia.outback.escape.de> On Wed, Sep 16, 2009 at 10:23:58AM +0200, Karel Gardas wrote: > Before going to trace anything I've compared sparky and my setup and it > seems I've had forgotten libiconv library in /usr/local/lib and > LD_LIBRARY_PATH contained this lib. So I've modified LD_LIBRARY_PATH to > exclude /usr/local/lib and now surprisingly base configure fails with: > > checking for library containing iconv... no > configure: error: iconv is required on non-Windows platforms > make[1]: *** [libraries/base/dist-install/package-data.mk] Error 1 > make: *** [all] Error 2 Running the build bot with ICONV_INCLUDE_DIRS=/usr/local/include ICONV_LIB_DIRS=/usr/local/lib in the environment fixes the iconv problems, at least on OpenBSD. (I need some more environment tweaks but that's really related to my OS) Ciao, Kili -- Manch Massenm?rder macht auch immer mal gern einen Abstecher. -- Dieter Br?gmann in dtjd, 20.2.2001 From Christian.Maeder at dfki.de Wed Sep 16 06:33:08 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Sep 16 06:11:47 2009 Subject: How to solve ghc-stage2: mkTextEncoding: invalid argument (Invalid argument) issue. In-Reply-To: <4AB0A09E.8040700@centrum.cz> References: <4AAFAB01.4070504@centrum.cz> <1253038886.19215.1892.camel@localhost> <4AB0A09E.8040700@centrum.cz> Message-ID: <4AB0BEE4.801@dfki.de> I've experienced a similar problem under i386 solaris, see http://www.haskell.org/pipermail/glasgow-haskell-users/2009-June/017376.html The problem seems to be the file /usr/local/include/iconv.h without a corresponding library. HTH Christian Karel Gardas wrote: > Before going to trace anything I've compared sparky and my setup and it > seems I've had forgotten libiconv library in /usr/local/lib and > LD_LIBRARY_PATH contained this lib. So I've modified LD_LIBRARY_PATH to > exclude /usr/local/lib and now surprisingly base configure fails with: > > checking for library containing iconv... no > configure: error: iconv is required on non-Windows platforms > make[1]: *** [libraries/base/dist-install/package-data.mk] Error 1 > make: *** [all] Error 2 > > see: > http://darcs.haskell.org/buildbot/all/builders/kgardas%20head/builds/205/steps/compile/logs/stdio > > When I've seen the code it's not so surprising that it fails in this > way, what's in fact surprising to me is that sparky passes belong this > point: > > checking for library containing iconv... none required > configure: creating ./config.status > config.status: creating base.buildinfo > config.status: creating include/HsBaseConfig.h > [...] > > See: > http://darcs.haskell.org/buildbot/head/builders/sparky%20head/builds/91/steps/compile/logs/stdio > > I'm sorry for starting this #91 build on sparky, but I'd like verify > that it does not build older source-code than my buildbot. > > So now, the question is: is GNU iconv really required or if it's not, > how to make my buildbot ignoring it as sparky's buldbot seems to be doing? > > Thanks, > Karel > > Duncan Coutts wrote: >> Dig into base/GHC/IO/Encoding/Iconv.hs mkTextEncoding function where it >> calls iconv_open, see what it's being called with. >> >> In particular check if HAVE_LANGINFO_H is getting defined. If it's not >> then the code assumes GNU iconv. >> >>> PS: for reference, please have a look at >>> http://darcs.haskell.org/buildbot/all/builders/kgardas%20head >> See also the >> >> http://darcs.haskell.org/buildbot/head/builders/sparky%20head >> >> Which is running Solaris 10 on sparc and seems to be working fine. >> >> Duncan >> >> >> From karel.gardas at centrum.cz Wed Sep 16 10:06:38 2009 From: karel.gardas at centrum.cz (Karel Gardas) Date: Wed Sep 16 09:45:19 2009 Subject: How to solve ghc-stage2: mkTextEncoding: invalid argument (Invalid argument) issue. In-Reply-To: <4AB0BEE4.801@dfki.de> References: <4AAFAB01.4070504@centrum.cz> <1253038886.19215.1892.camel@localhost> <4AB0A09E.8040700@centrum.cz> <4AB0BEE4.801@dfki.de> Message-ID: <4AB0F0EE.9070304@centrum.cz> Thanks to Christian note I solved the issue. Also thanks to Matthias' advice I've been able to configure ghc to use GNU iconv in /usr/local, but the result was still the same. I later used Christian advice to force ghc not to use /usr/local's iconv and this really configured correctly (like sparky's: checking for library containing iconv... none required) and now finally my buildbot is working even for head. Note the provided /usr/local iconv is probably from package provided by sunfreeware.com and is there from the old SXDE 1/08 installation. Now I'm using OpenSolaris 2009.06 and trying to get rid of such additions which are no longer needed. Thanks for all the help provided! Karel Christian Maeder wrote: > I've experienced a similar problem under i386 solaris, see > http://www.haskell.org/pipermail/glasgow-haskell-users/2009-June/017376.html > > The problem seems to be the file /usr/local/include/iconv.h without a > corresponding library. > > HTH Christian > > Karel Gardas wrote: >> Before going to trace anything I've compared sparky and my setup and it >> seems I've had forgotten libiconv library in /usr/local/lib and >> LD_LIBRARY_PATH contained this lib. So I've modified LD_LIBRARY_PATH to >> exclude /usr/local/lib and now surprisingly base configure fails with: >> >> checking for library containing iconv... no >> configure: error: iconv is required on non-Windows platforms >> make[1]: *** [libraries/base/dist-install/package-data.mk] Error 1 >> make: *** [all] Error 2 >> >> see: >> http://darcs.haskell.org/buildbot/all/builders/kgardas%20head/builds/205/steps/compile/logs/stdio >> >> When I've seen the code it's not so surprising that it fails in this >> way, what's in fact surprising to me is that sparky passes belong this >> point: >> >> checking for library containing iconv... none required >> configure: creating ./config.status >> config.status: creating base.buildinfo >> config.status: creating include/HsBaseConfig.h >> [...] >> >> See: >> http://darcs.haskell.org/buildbot/head/builders/sparky%20head/builds/91/steps/compile/logs/stdio >> >> I'm sorry for starting this #91 build on sparky, but I'd like verify >> that it does not build older source-code than my buildbot. >> >> So now, the question is: is GNU iconv really required or if it's not, >> how to make my buildbot ignoring it as sparky's buldbot seems to be doing? >> >> Thanks, >> Karel >> >> Duncan Coutts wrote: >>> Dig into base/GHC/IO/Encoding/Iconv.hs mkTextEncoding function where it >>> calls iconv_open, see what it's being called with. >>> >>> In particular check if HAVE_LANGINFO_H is getting defined. If it's not >>> then the code assumes GNU iconv. >>> >>>> PS: for reference, please have a look at >>>> http://darcs.haskell.org/buildbot/all/builders/kgardas%20head >>> See also the >>> >>> http://darcs.haskell.org/buildbot/head/builders/sparky%20head >>> >>> Which is running Solaris 10 on sparc and seems to be working fine. >>> >>> Duncan >>> >>> >>> > > From marlowsd at gmail.com Thu Sep 17 04:17:35 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Sep 17 03:56:13 2009 Subject: How to solve ghc-stage2: mkTextEncoding: invalid argument (Invalid argument) issue. In-Reply-To: <4AB0F0EE.9070304@centrum.cz> References: <4AAFAB01.4070504@centrum.cz> <1253038886.19215.1892.camel@localhost> <4AB0A09E.8040700@centrum.cz> <4AB0BEE4.801@dfki.de> <4AB0F0EE.9070304@centrum.cz> Message-ID: <4AB1F09F.6010900@gmail.com> On 16/09/2009 15:06, Karel Gardas wrote: > > Thanks to Christian note I solved the issue. Also thanks to Matthias' > advice I've been able to configure ghc to use GNU iconv in /usr/local, > but the result was still the same. I later used Christian advice to > force ghc not to use /usr/local's iconv and this really configured > correctly (like sparky's: checking for library containing iconv... none > required) and now finally my buildbot is working even for head. > > Note the provided /usr/local iconv is probably from package provided by > sunfreeware.com and is there from the old SXDE 1/08 installation. Now > I'm using OpenSolaris 2009.06 and trying to get rid of such additions > which are no longer needed. > > Thanks for all the help provided! Glad you got it going. I notice there are a few test failures, many of which could be fixed easily, e.g. --- ./lib/IO/hClose002.stdout.normalised Wed Sep 16 14:08:09 2009 +++ ./lib/IO/hClose002.run.stdout.normalised Wed Sep 16 14:08:09 2009 @@ -1,4 +1,4 @@ -Left hClose002.tmp: hClose: invalid argument (Bad file descriptor) +Left hClose002.tmp: hClose: invalid argument (Bad file number) Right () Right () Right () *** unexpected failure for hClose002(normal) that just needs a platform-specific expected output file (hClose002.stdout-i386-unknown-solaris2). Cheers, Simon From marlowsd at gmail.com Thu Sep 17 04:29:30 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Sep 17 04:08:09 2009 Subject: How to move code from GHC to libraries? In-Reply-To: <20090917034337.6A0FEB1310@lakeland.eecs.harvard.edu> References: <4A955F9B.904@gmail.com> <4A9685D1.2000008@gmail.com> (sfid-H-20090827-091706-+154.15-1@multi.osbf.lua) <20090911230213.C5161B130F@lakeland.eecs.harvard.edu> <4AADF9C0.20506@gmail.com> (sfid-H-20090914-041708-+149.25-1@multi.osbf.lua) <20090917034337.6A0FEB1310@lakeland.eecs.harvard.edu> Message-ID: <4AB1F36A.4080103@gmail.com> On 17/09/2009 04:43, Norman Ramsey wrote: > > > While we're on this topic, I've had several requests to pull HOOPL > > > (the new dataflow optimization code) out as a library so that we can > > > make it into a Hackage package. I'd like to do this, but the > > > situation is complicated because HOOPL depends on UniqFM, which is > > > GHC-specific. I thought that there was a similar implementation out > > > in the wild (based on Okasaki-Gill rather than Adams), but I can't > > > find it on hackage. > > > > Isn't Data.IntMap ~= UniqFM? > > Yes, thanks --- I couldn't remember the module name, and search did > not help. > > > > Is there an established procedure for moving a part of GHC into a > > > library without breaking everybody's build? ... > > > > The architecture of our library setup is here: > > > > http://hackage.haskell.org/trac/ghc/wiki/Commentary/Libraries > > > You'd be adding a new zero-boot package... > > OK, I would like to propose that I put Data.IntMap into a new > zero-boot package, and that I replace the existing UniqFM with a > compatibility layer over Data.IntMap, with the eventual goal of > expunging UniqFM from the GHC sources. > > Any comments or objections? You can assume that the bootstrapping compiler already has Data.IntMap, no need to put it in a 0-boot package. So in principle using Data.IntMap is a good thing, I wholeheartedly support using the standard libraries instead of in-house duplicates where possible. The only potential problem is performance: we rely heavily on UniqFM in GHC, so we'd have to make sure that any replacement is at least as fast. The only time to measure it is when making the changeover, when you can measure the change in isolation. Cheers, Simon From karel.gardas at centrum.cz Thu Sep 17 04:44:51 2009 From: karel.gardas at centrum.cz (Karel Gardas) Date: Thu Sep 17 04:23:29 2009 Subject: How to solve ghc-stage2: mkTextEncoding: invalid argument (Invalid argument) issue. In-Reply-To: <4AB1F09F.6010900@gmail.com> References: <4AAFAB01.4070504@centrum.cz> <1253038886.19215.1892.camel@localhost> <4AB0A09E.8040700@centrum.cz> <4AB0BEE4.801@dfki.de> <4AB0F0EE.9070304@centrum.cz> <4AB1F09F.6010900@gmail.com> Message-ID: <4AB1F703.3040609@centrum.cz> Hi, indeed, I know that and I expect to submit patches later this month. Thanks, Karel Simon Marlow wrote: > Glad you got it going. I notice there are a few test failures, many of > which could be fixed easily, e.g. > > --- ./lib/IO/hClose002.stdout.normalised Wed Sep 16 14:08:09 2009 > +++ ./lib/IO/hClose002.run.stdout.normalised Wed Sep 16 14:08:09 2009 > @@ -1,4 +1,4 @@ > -Left hClose002.tmp: hClose: invalid argument (Bad file descriptor) > +Left hClose002.tmp: hClose: invalid argument (Bad file number) > Right () > Right () > Right () > *** unexpected failure for hClose002(normal) > > > that just needs a platform-specific expected output file > (hClose002.stdout-i386-unknown-solaris2). > > Cheers, > Simon > > From kili at outback.escape.de Thu Sep 17 17:20:42 2009 From: kili at outback.escape.de (Matthias Kilian) Date: Thu Sep 17 16:59:44 2009 Subject: How to solve ghc-stage2: mkTextEncoding: invalid argument (Invalid argument) issue. In-Reply-To: <4AB1F09F.6010900@gmail.com> References: <4AAFAB01.4070504@centrum.cz> <1253038886.19215.1892.camel@localhost> <4AB0A09E.8040700@centrum.cz> <4AB0BEE4.801@dfki.de> <4AB0F0EE.9070304@centrum.cz> <4AB1F09F.6010900@gmail.com> Message-ID: <20090917212042.GA5526@petunia.outback.escape.de> On Thu, Sep 17, 2009 at 09:17:35AM +0100, Simon Marlow wrote: > Glad you got it going. I notice there are a few test failures, many of > which could be fixed easily, e.g. > > --- ./lib/IO/hClose002.stdout.normalised Wed Sep 16 14:08:09 2009 > +++ ./lib/IO/hClose002.run.stdout.normalised Wed Sep 16 14:08:09 2009 > @@ -1,4 +1,4 @@ > -Left hClose002.tmp: hClose: invalid argument (Bad file descriptor) > +Left hClose002.tmp: hClose: invalid argument (Bad file number) > Right () > Right () > Right () > *** unexpected failure for hClose002(normal) > > > that just needs a platform-specific expected output file > (hClose002.stdout-i386-unknown-solaris2). BTW: is there an easy way to do some general output filtering on *all* tests for different platforms? It may not be helpful for the above test, but for some differences (like stderr in case of several types of core dumps on different operating systems, or the typical linker warnings about strcat(3), strcpy(3) etc. on OpenBSD) it may be less maintainance work to filter or modify the output on specific platforms. Ciao, Kili From c at functionx.org Sun Sep 20 18:00:31 2009 From: c at functionx.org (Christopher Lewis) Date: Sun Sep 20 17:38:56 2009 Subject: runghc failing sometimes on Linux/ppc? Message-ID: <7133a2c20909201500g41ee5c7bs294029b6a3c3f183@mail.gmail.com> > On Sun, May 03, 2009 at 03:02:50PM +1000, Jens Petersen wrote: > > 2009/5/2 Jens Petersen : > > > So I tried doing an unregisterised ppc build with: > > > > > > echo "GhcUnregisterised=YES" >> mk/build.mk > > > echo "GhcWithNativeCodeGen=NO" >> mk/build.mk > > > echo "SplitObjs=NO" >> mk/build.mk > > > > Are these the right build config settings? > > Yes. > > > > but this failed with: > > : > > > Linking dist-stage2/build/ghc/ghc ... > > : > > > (.text+0x20): relocation truncated to fit: R_PPC_REL24 against symbol > > > `__libc_start_main@@GLIBC_2.0' defined in .glink section in > > > /usr/lib/gcc/ppc64-redhat-linux/4.4.0/../../../../lib/crt1.o > > > /usr/lib/gcc/ppc64-redhat-linux/4.4.0/crtbegin.o:(.fini+0x0): > > > relocation truncated to fit: R_PPC_REL24 against `.text' > > Does using -mlongcall help? e.g.: > > SRC_CC_OPTS += -mlongcall > SRC_HC_OPTS += -optc-mlongcall > > (you can probably get away with something rather more specific, but > hopefully this will work). I haven't seen a message confirming if the suggested solution worked, but I am experiencing a similar problem---failure to link GHC due to relocation truncation errors---on a different environment (Ubuntu, PowerPC 32 bit). I have tried the above workaround, but it did not solve my problem. Furthermore, based on this (http://osdir.com/ml/bug-binutils-gnu/2009-08/msg00068.html) binutils thread (sorry, there is probably a better source to reference), it appears this problem was not fixed until very recently. Any additional information or suggested workarounds would be much appreciated. {c} From marlowsd at gmail.com Mon Sep 21 07:50:13 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Sep 21 07:28:41 2009 Subject: How to solve ghc-stage2: mkTextEncoding: invalid argument (Invalid argument) issue. In-Reply-To: <20090917212042.GA5526@petunia.outback.escape.de> References: <4AAFAB01.4070504@centrum.cz> <1253038886.19215.1892.camel@localhost> <4AB0A09E.8040700@centrum.cz> <4AB0BEE4.801@dfki.de> <4AB0F0EE.9070304@centrum.cz> <4AB1F09F.6010900@gmail.com> <20090917212042.GA5526@petunia.outback.escape.de> Message-ID: <4AB76875.3060003@gmail.com> On 17/09/2009 22:20, Matthias Kilian wrote: > On Thu, Sep 17, 2009 at 09:17:35AM +0100, Simon Marlow wrote: >> Glad you got it going. I notice there are a few test failures, many of >> which could be fixed easily, e.g. >> >> --- ./lib/IO/hClose002.stdout.normalised Wed Sep 16 14:08:09 2009 >> +++ ./lib/IO/hClose002.run.stdout.normalised Wed Sep 16 14:08:09 2009 >> @@ -1,4 +1,4 @@ >> -Left hClose002.tmp: hClose: invalid argument (Bad file descriptor) >> +Left hClose002.tmp: hClose: invalid argument (Bad file number) >> Right () >> Right () >> Right () >> *** unexpected failure for hClose002(normal) >> >> >> that just needs a platform-specific expected output file >> (hClose002.stdout-i386-unknown-solaris2). > > > BTW: is there an easy way to do some general output filtering on > *all* tests for different platforms? It may not be helpful for the > above test, but for some differences (like stderr in case of several > types of core dumps on different operating systems, or the typical > linker warnings about strcat(3), strcpy(3) etc. on OpenBSD) it may > be less maintainance work to filter or modify the output on specific > platforms. This is slightly ad-hoc at the moment and could do with generalising a bit. Look at the various functions beginning with normalise_ in testsuite/driver/testlib.py. There's also a way to specify a per-test output normalisation function: normalise_fun(). Cheers, Simon From donn at avvanta.com Tue Sep 22 10:34:53 2009 From: donn at avvanta.com (Donn Cave) Date: Tue Sep 22 10:13:13 2009 Subject: no-Haddock GHC build References: <20080528152033.GA6188@matrix.chaos.earth.li> Message-ID: <20090922143453.509B7F3939@mail.avvanta.com> I'm thinking it would be expedient to omit Haddock while building a ghc 6.11 snapshot, per bug ticket #3531 >From my basic understanding of its purpose there, that ought to work out fine - I mean, not to undervalue documentation, but the compiler should be able to function without it. But not well versed in the intricacies of the GHC build, so please set me straight if I'm about to waste a lot of time untangling it in the makefiles. thanks! Donn Cave, donn@avvanta.com From kili at outback.escape.de Tue Sep 22 14:04:58 2009 From: kili at outback.escape.de (Matthias Kilian) Date: Tue Sep 22 13:43:48 2009 Subject: no-Haddock GHC build In-Reply-To: <20090922143453.509B7F3939@mail.avvanta.com> References: <20080528152033.GA6188@matrix.chaos.earth.li> <20090922143453.509B7F3939@mail.avvanta.com> Message-ID: <20090922180458.GA27898@petunia.outback.escape.de> On Tue, Sep 22, 2009 at 07:34:53AM -0700, Donn Cave wrote: > I'm thinking it would be expedient to omit Haddock while building a > ghc 6.11 snapshot, per bug ticket #3531 > > >From my basic understanding of its purpose there, that ought to work out > fine - I mean, not to undervalue documentation, but the compiler should > be able to function without it. But not well versed in the intricacies > of the GHC build, so please set me straight if I'm about to waste a lot > of time untangling it in the makefiles. I sent a patch for this to cvs-ghc@: http://www.haskell.org/pipermail/cvs-ghc/2009-September/050255.html I wasn't even aware of that ticket ;-) Ciao, Kili From barney_stratford at fastmail.fm Wed Sep 23 06:24:20 2009 From: barney_stratford at fastmail.fm (Barney Stratford) Date: Wed Sep 23 06:02:40 2009 Subject: Snow Leopard GHC Message-ID: <73212E12-0F8B-4D85-A61E-9E02995AEFC1@fastmail.fm> I've been trying to get GHC working for x86_64 on Snow Leopard, with a certain amount of success, but have got stuck. Maybe one of you could point me in the right direction. I now have a working compiler, but the linker in the runtime system seems to be missing some stuff. Specifically, in rts/Linker.c, there are references to X86_64_RELOC_UNSIGNED, X86_64_RELOC_SIGNED and so on, but it simply barfs when faced with a X86_64_RELOC_SIGNED_1 etc. I'd thought it would be a matter of adding a few lines of code, but everything I've tried has ended in tears. Trouble is, none of the documentation mentions X86_64_RELOC_SIGNED_1, although it does appear in C headers. It occurs only rarely in source examples, and it really isn't clear to me how I should proceed. Any ideas? Cheers, Barney. From donnie at darthik.com Wed Sep 23 15:24:05 2009 From: donnie at darthik.com (Donnie Jones) Date: Wed Sep 23 15:02:28 2009 Subject: [Haskell-cafe] Status of GHC as a Cross Compiler In-Reply-To: References: Message-ID: Hello John, glasgow-haskell-users is a more appropriate list... http://www.haskell.org/mailman/listinfo/glasgow-haskell-users I went ahead and cc'd your message to the list. Any replies please include John's email address as I don't think he is subscribed to the list. Hope that helps... -- Donnie Jones On Wed, Sep 23, 2009 at 1:50 PM, John Van Enk wrote: > Hi, > > This may be more appropriate for a different list, but I'm having a hard > time figuring out whether or not we're getting a cross compiler in 6.12 or > not. Can some one point me to the correct place in Traq to find this > information? > > /jve > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From barney_stratford at fastmail.fm Thu Sep 24 04:55:59 2009 From: barney_stratford at fastmail.fm (Barney Stratford) Date: Thu Sep 24 04:34:16 2009 Subject: Snow Leopard GHC In-Reply-To: <73212E12-0F8B-4D85-A61E-9E02995AEFC1@fastmail.fm> References: <73212E12-0F8B-4D85-A61E-9E02995AEFC1@fastmail.fm> Message-ID: <5463A776-A661-42C8-9DA8-2FEDD7041E6D@fastmail.fm> Latest update on getting GHC working 64-bit on Snow Leopard. I've been building 6.8.3, simply because it was the version I had running before so might give fewer problems. To get the compiler working, apply this patch (which I borrowed from the Darcs repository): diff -uit a/compiler/cmm/CLabel.hs b/compiler/cmm/CLabel.hs --- a/compiler/cmm/CLabel.hs +++ b/compiler/cmm/CLabel.hs @@ -816,6 +816,10 @@ pprDynamicLinkerAsmLabel :: DynamicLinkerLabelInfo -> CLabel -> SDoc #if x86_64_TARGET_ARCH && darwin_TARGET_OS +pprDynamicLinkerAsmLabel CodeStub lbl + = char 'L' <> pprCLabel lbl <> text "$stub" +pprDynamicLinkerAsmLabel SymbolPtr lbl + = char 'L' <> pprCLabel lbl <> text "$non_lazy_ptr" pprDynamicLinkerAsmLabel GotSymbolPtr lbl = pprCLabel lbl <> text "@GOTPCREL" pprDynamicLinkerAsmLabel GotSymbolOffset lbl Make sure you have a working 32-bit GHC as well as libraries (libgmp, etc).for both 32 and 64-bit architectures. Then say ./configure --build=x86_64-apple-darwin --host=x86_64-apple-darwin -- target=x86_64-apple-darwin make It will compile an x86_64 GHC for you, happily unaware that the GHC you're using for the build is a 32-bit one. The stage1 compiler is, of course, a 32-bit binary that produces 64-bit binaries. I found that the resulting compiler can build itself (stage3) and can say Hello World, so it looks like it works correctly. I've still not got GHCi working, though. I've managed to narrow down the source of the trouble with the linker in GHCi, and it looks like there are some bugs as well as missing parts, which is why it kept launching itself to the moon. Still working on that one: patch to follow. For now, you can at least compile your code and run it non-interactively. Barney. From marlowsd at gmail.com Thu Sep 24 05:28:51 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Sep 24 05:07:13 2009 Subject: Snow Leopard GHC In-Reply-To: <5463A776-A661-42C8-9DA8-2FEDD7041E6D@fastmail.fm> References: <73212E12-0F8B-4D85-A61E-9E02995AEFC1@fastmail.fm> <5463A776-A661-42C8-9DA8-2FEDD7041E6D@fastmail.fm> Message-ID: <4ABB3BD3.8050002@gmail.com> On 24/09/2009 09:55, Barney Stratford wrote: > Latest update on getting GHC working 64-bit on Snow Leopard. I've been > building 6.8.3, simply because it was the version I had running before > so might give fewer problems. > > To get the compiler working, apply this patch (which I borrowed from the > Darcs repository): > > diff -uit a/compiler/cmm/CLabel.hs b/compiler/cmm/CLabel.hs > --- a/compiler/cmm/CLabel.hs > +++ b/compiler/cmm/CLabel.hs > @@ -816,6 +816,10 @@ > pprDynamicLinkerAsmLabel :: DynamicLinkerLabelInfo -> CLabel -> SDoc > > #if x86_64_TARGET_ARCH && darwin_TARGET_OS > +pprDynamicLinkerAsmLabel CodeStub lbl > + = char 'L' <> pprCLabel lbl <> text "$stub" > +pprDynamicLinkerAsmLabel SymbolPtr lbl > + = char 'L' <> pprCLabel lbl <> text "$non_lazy_ptr" > pprDynamicLinkerAsmLabel GotSymbolPtr lbl > = pprCLabel lbl <> text "@GOTPCREL" > pprDynamicLinkerAsmLabel GotSymbolOffset lbl > > Make sure you have a working 32-bit GHC as well as libraries (libgmp, > etc).for both 32 and 64-bit architectures. Then say > > ./configure --build=x86_64-apple-darwin --host=x86_64-apple-darwin > --target=x86_64-apple-darwin > make > > It will compile an x86_64 GHC for you, happily unaware that the GHC > you're using for the build is a 32-bit one. The stage1 compiler is, of > course, a 32-bit binary that produces 64-bit binaries. > > I found that the resulting compiler can build itself (stage3) and can > say Hello World, so it looks like it works correctly. I've still not got > GHCi working, though. > > I've managed to narrow down the source of the trouble with the linker in > GHCi, and it looks like there are some bugs as well as missing parts, > which is why it kept launching itself to the moon. Still working on that > one: patch to follow. For now, you can at least compile your code and > run it non-interactively. Nice going - sounds like you've got the furthest so far. Others have been going via an unregisterised build, which seems to be more problematic (though it shouldn't be). It should be possible to use your 6.8.3 to bootstrap your way to 6.12.1, have you tried that? I doubt it will fix your GHCi problems, though. But it should be possible to then make a distribution for others to try. Cheers, Simon From Ben.Lippmeier at anu.edu.au Thu Sep 24 05:31:23 2009 From: Ben.Lippmeier at anu.edu.au (Ben Lippmeier) Date: Thu Sep 24 05:09:41 2009 Subject: [Haskell-cafe] Status of GHC as a Cross Compiler In-Reply-To: References: Message-ID: No, GHC won't be a native cross compiler in 6.12. There are #ifdefs through the code which control what target architecture GHC is being compiled for, and at the moment it doesn't support the host architecture being different from the target architecture. I did some work on the native code generator this year which cleans up some of this, but it still needs several more weeks put into it to make it a real cross compiler. Cheers, Ben. On 24/09/2009, at 5:24 AM, Donnie Jones wrote: > Hello John, > > glasgow-haskell-users is a more appropriate list... > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > I went ahead and cc'd your message to the list. Any replies please > include John's email address as I don't think he is subscribed to the > list. > > Hope that helps... > -- > Donnie Jones > > On Wed, Sep 23, 2009 at 1:50 PM, John Van Enk > wrote: >> Hi, >> >> This may be more appropriate for a different list, but I'm having a >> hard >> time figuring out whether or not we're getting a cross compiler in >> 6.12 or >> not. Can some one point me to the correct place in Traq to find this >> information? >> >> /jve >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From barney_stratford at fastmail.fm Thu Sep 24 18:54:33 2009 From: barney_stratford at fastmail.fm (Barney Stratford) Date: Thu Sep 24 18:32:47 2009 Subject: Snow Leopard GHC In-Reply-To: <4ABB3BD3.8050002@gmail.com> References: <73212E12-0F8B-4D85-A61E-9E02995AEFC1@fastmail.fm> <5463A776-A661-42C8-9DA8-2FEDD7041E6D@fastmail.fm> <4ABB3BD3.8050002@gmail.com> Message-ID: Only limited success with GHCi, I'm afraid. The problem seems to be that Snow Leopard is much stricter about security than Leopard was. (Caveat - I don't really know what I'm talking about.) In particular, I don't think it will let you execute code outside of the __TEXT segment, which is exactly what GHCi tries to do - hence the bus errors. I've tried just letting the dynamic linker (dyld) sort everything out for us, but this failed because not all symbols are dynamically linked, and the statically linked ones are invisible to it. One change that will be necessary in any case: towards the end of rts/ Linker.c, change case X86_64_RELOC_SIGNED: ASSERT(reloc->r_pcrel); thing += value - baseValue; break; to case X86_64_RELOC_SIGNED: case X86_64_RELOC_SIGNED_1: case X86_64_RELOC_SIGNED_2: case X86_64_RELOC_SIGNED_4: ASSERT(reloc->r_pcrel); thing += value - baseValue; break; I won't be able to hack on this any more for a few days, as I'm off to the mountains. Maybe someone else can try. Barney. From marlowsd at gmail.com Fri Sep 25 04:26:09 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Sep 25 04:04:25 2009 Subject: Snow Leopard GHC In-Reply-To: References: <73212E12-0F8B-4D85-A61E-9E02995AEFC1@fastmail.fm> <5463A776-A661-42C8-9DA8-2FEDD7041E6D@fastmail.fm> <4ABB3BD3.8050002@gmail.com> Message-ID: <4ABC7EA1.7000603@gmail.com> On 24/09/2009 23:54, Barney Stratford wrote: > Only limited success with GHCi, I'm afraid. The problem seems to be that > Snow Leopard is much stricter about security than Leopard was. (Caveat - > I don't really know what I'm talking about.) In particular, I don't > think it will let you execute code outside of the __TEXT segment, which > is exactly what GHCi tries to do - hence the bus errors. We had similar problems with SELinux, which we worked around by using libffi to allocate our memory; it handles the multiple-mmapping trick that you need to do to avoid having memory that is both writable and executable. You might need to enable this for Darwin too: look in rts/sm/Storage.c:allocateExec(), and change the #ifdef so that the libffi version is used for darwin too. > I've tried just letting the dynamic linker (dyld) sort everything out > for us, but this failed because not all symbols are dynamically linked, > and the statically linked ones are invisible to it. > > One change that will be necessary in any case: towards the end of > rts/Linker.c, change > case X86_64_RELOC_SIGNED: > ASSERT(reloc->r_pcrel); > thing += value - baseValue; > break; > > to > > case X86_64_RELOC_SIGNED: > case X86_64_RELOC_SIGNED_1: > case X86_64_RELOC_SIGNED_2: > case X86_64_RELOC_SIGNED_4: > ASSERT(reloc->r_pcrel); > thing += value - baseValue; > break; Manuel, maybe you could validate and push this one? Cheers, Simon From barney_stratford at fastmail.fm Fri Sep 25 05:56:54 2009 From: barney_stratford at fastmail.fm (Barney Stratford) Date: Fri Sep 25 05:35:07 2009 Subject: Snow Leopard GHC In-Reply-To: <4ABC7EA1.7000603@gmail.com> References: <73212E12-0F8B-4D85-A61E-9E02995AEFC1@fastmail.fm> <5463A776-A661-42C8-9DA8-2FEDD7041E6D@fastmail.fm> <4ABB3BD3.8050002@gmail.com> <4ABC7EA1.7000603@gmail.com> Message-ID: OK, I'm trying to get a more-recent GHC working that has that #ifdef that you mentioned. Specifically, 6.10.4. I've said: ./configure --build=x86_64-apple-darwin --host=x86_64-apple-darwin -- target=x86_64-apple-darwin --with-gmp-includes='/sw/include' --with- gmp-libraries='/sw/lib' make and it fails, saying it can't find libgmp, even though I've just told it where gmp is. I've copied my mk/build.mk straight from my 6.8.3 build, and it says ReadlineIncludePath=/sw/include SRC_CC_OPTS += -I/sw/include -L/sw/lib SRC_HC_OPTS += -I/sw/include -L/sw/lib EXTRA_HSC2HS_OPTS += -I/sw/include EXTRA_LD_OPTS += -L/sw/lib The resulting error message is: [51 of 51] Compiling Distribution.Simple ( Distribution/Simple.hs, dist-bootstrapping/build/Distribution/Simple.o ) ar: creating archive dist-bootstrapping/build/libHSCabal-1.6.0.3.a cd Cabal && /Users/bjs/Desktop/GHC_Build/ghc-6.10.4/libraries/cabal- bin /Users/bjs/Desktop/GHC_Build/install/bin/ghc /Users/bjs/Desktop/ GHC_Build/ghc-6.10.4/libraries/bootstrapping.conf 1.6.0.3 install -- distpref=dist-bootstrapping --inplace Installing library in /Users/bjs/Desktop/GHC_Build/ghc-6.10.4/libraries/Cabal/dist- bootstrapping/install/usr/local/lib/Cabal-1.6.0.3/ghc-6.8.3 Registering Cabal-1.6.0.3... Reading package info from "dist-bootstrapping/inplace-pkg-config" ... done. Saving old package config file... done. Writing new package config file... done. cd hpc && /Users/bjs/Desktop/GHC_Build/ghc-6.10.4/libraries/cabal- bin /Users/bjs/Desktop/GHC_Build/install/bin/ghc /Users/bjs/Desktop/ GHC_Build/ghc-6.10.4/libraries/bootstrapping.conf 1.6.0.3 clean -- distpref=dist-bootstrapping cleaning... cd hpc && /Users/bjs/Desktop/GHC_Build/ghc-6.10.4/libraries/cabal- bin /Users/bjs/Desktop/GHC_Build/install/bin/ghc /Users/bjs/Desktop/ GHC_Build/ghc-6.10.4/libraries/bootstrapping.conf 1.6.0.3 configure -- distpref=dist-bootstrapping --with-compiler=/Users/bjs/Desktop/ GHC_Build/install/bin/ghc --with-hc-pkg=/Users/bjs/Desktop/GHC_Build/ install/bin/ghc-pkg --package-db=/Users/bjs/Desktop/GHC_Build/ ghc-6.10.4/libraries/bootstrapping.conf.tmp Configuring hpc-0.5.0.3... : warning: "__PIC__" redefined : warning: this is the location of the previous definition cd hpc && /Users/bjs/Desktop/GHC_Build/ghc-6.10.4/libraries/cabal- bin /Users/bjs/Desktop/GHC_Build/install/bin/ghc /Users/bjs/Desktop/ GHC_Build/ghc-6.10.4/libraries/bootstrapping.conf 1.6.0.3 build -- distpref=dist-bootstrapping Preprocessing library hpc-0.5.0.3... ld: library not found for -lgmp collect2: ld returned 1 exit status linking dist-bootstrapping/build/Trace/Hpc/Reflect_hsc_make.o failed command was: /usr/bin/gcc -L/Users/bjs/Desktop/GHC_Build/install/lib/ ghc-6.8.3/lib/directory-1.0.0.1 -L/Users/bjs/Desktop/GHC_Build/install/ lib/ghc-6.8.3/lib/filepath-1.1.0.0 -L/Users/bjs/Desktop/GHC_Build/ install/lib/ghc-6.8.3/lib/old-time-1.0.0.0 -L/Users/bjs/Desktop/ GHC_Build/install/lib/ghc-6.8.3/lib/old-locale-1.0.0.0 -L/Users/bjs/ Desktop/GHC_Build/install/lib/ghc-6.8.3/lib/containers-0.1.0.2 -L/ Users/bjs/Desktop/GHC_Build/install/lib/ghc-6.8.3/lib/array-0.1.0.0 -L/ Users/bjs/Desktop/GHC_Build/install/lib/ghc-6.8.3/lib/base-3.0.2.0 -L/ Users/bjs/Desktop/GHC_Build/install/lib/ghc-6.8.3 -lm -lgmp -ldl dist- bootstrapping/build/Trace/Hpc/Reflect_hsc_make.o -o dist-bootstrapping/ build/Trace/Hpc/Reflect_hsc_make make[1]: *** [bootstrapping.conf] Error 1 make: *** [stage1] Error 2 [~/Desktop/GHC_Build/ghc-6.10.4] bjs$ As you can see, it doesn't even attempt to tell gcc where to find libgmp. This has the feeling of an RTM question, and if it is then I apologise. I've not seen anything about this in the M, though. Cheers, Barney. From daniel.is.fischer at web.de Fri Sep 25 06:15:55 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Fri Sep 25 05:59:06 2009 Subject: Snow Leopard GHC In-Reply-To: References: <73212E12-0F8B-4D85-A61E-9E02995AEFC1@fastmail.fm> <4ABC7EA1.7000603@gmail.com> Message-ID: <200909251215.55609.daniel.is.fischer@web.de> Am Freitag 25 September 2009 11:56:54 schrieb Barney Stratford: > As you can see, it doesn't even attempt to tell gcc where to find ? > libgmp. > > This has the feeling of an RTM question, and if it is then I ? > apologise. I've not seen anything about this in the M, though. > > Cheers, > Barney. As a workaround, you might try to set the appropriate enironment variables (check with man gcc which ones are required) to include /sw/include resp. /sw/lib From barney_stratford at fastmail.fm Fri Sep 25 06:28:19 2009 From: barney_stratford at fastmail.fm (Barney Stratford) Date: Fri Sep 25 06:06:32 2009 Subject: Snow Leopard GHC In-Reply-To: <200909251215.55609.daniel.is.fischer@web.de> References: <73212E12-0F8B-4D85-A61E-9E02995AEFC1@fastmail.fm> <4ABC7EA1.7000603@gmail.com> <200909251215.55609.daniel.is.fischer@web.de> Message-ID: <318B6841-BEE2-4636-AF74-25C3854B7DE9@fastmail.fm> > As a workaround, you might try to set the appropriate enironment > variables Setting LIBRARY_PATH seems to help, but there must be a better way! Thanks. Barney. From chak at cse.unsw.edu.au Sun Sep 27 07:38:53 2009 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sun Sep 27 07:17:08 2009 Subject: Snow Leopard GHC In-Reply-To: <4ABC7EA1.7000603@gmail.com> References: <73212E12-0F8B-4D85-A61E-9E02995AEFC1@fastmail.fm> <5463A776-A661-42C8-9DA8-2FEDD7041E6D@fastmail.fm> <4ABB3BD3.8050002@gmail.com> <4ABC7EA1.7000603@gmail.com> Message-ID: <36179667-AECA-4CAE-94B7-410ABA15F5EE@cse.unsw.edu.au> Simon Marlow: > On 24/09/2009 23:54, Barney Stratford wrote: >> I've tried just letting the dynamic linker (dyld) sort everything out >> for us, but this failed because not all symbols are dynamically >> linked, >> and the statically linked ones are invisible to it. >> >> One change that will be necessary in any case: towards the end of >> rts/Linker.c, change >> case X86_64_RELOC_SIGNED: >> ASSERT(reloc->r_pcrel); >> thing += value - baseValue; >> break; >> >> to >> >> case X86_64_RELOC_SIGNED: >> case X86_64_RELOC_SIGNED_1: >> case X86_64_RELOC_SIGNED_2: >> case X86_64_RELOC_SIGNED_4: >> ASSERT(reloc->r_pcrel); >> thing += value - baseValue; >> break; > > Manuel, maybe you could validate and push this one? I am happy to take care of funnelling Barney's changes into the main repo. However, I think there was at least one more mentioned in another email. Barney, do you have a comprehensive set of the changes that you made (ideally against the HEAD repo, or a nightly snapshot, but if that's difficult, then against 6.10)? And did you try to run the testsuite http://darcs.haskel.org/testsuite with the compiler that you generated? Manuel From marlowsd at gmail.com Mon Sep 28 08:49:12 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Sep 28 08:27:19 2009 Subject: Snow Leopard GHC In-Reply-To: <318B6841-BEE2-4636-AF74-25C3854B7DE9@fastmail.fm> References: <73212E12-0F8B-4D85-A61E-9E02995AEFC1@fastmail.fm> <4ABC7EA1.7000603@gmail.com> <200909251215.55609.daniel.is.fischer@web.de> <318B6841-BEE2-4636-AF74-25C3854B7DE9@fastmail.fm> Message-ID: <4AC0B0C8.9010002@gmail.com> On 25/09/2009 11:28, Barney Stratford wrote: >> As a workaround, you might try to set the appropriate enironment >> variables > Setting LIBRARY_PATH seems to help, but there must be a better way! Thanks. This is supposed to work, as far as I know: ./configure --with-gmp-libraries= --with-gmp-includes= Cheers, Simon From dons at galois.com Tue Sep 29 16:46:46 2009 From: dons at galois.com (Don Stewart) Date: Tue Sep 29 16:27:04 2009 Subject: Intel's Concurrent Collections for Haskell Message-ID: <20090929204646.GZ17961@whirlpool.galois.com> http://softtalkblog.wordpress.com/2009/09/29/more-about-haskell-and-intel-concurrent-collections/ Intel involved in work to port Concurrent Collections to Haskell. Might be interesting for benchmarks on 6.12 -- Don From luca_ciciriello at hotmail.com Wed Sep 30 07:35:01 2009 From: luca_ciciriello at hotmail.com (Luca Ciciriello) Date: Wed Sep 30 07:12:57 2009 Subject: which difference... Message-ID: Hi all. I've recently changed my home machine (MacOS X 10.5.8 intel) and I've installed the GHC 6.10.4 using the pakage: GHC-6.10.4-i386.pkg. All works fine and I can continue all my research projects on my new machine. Then I've noticed that exists another kind of installation using the package: haskell-platform-2009.2.0.2-i386.dmg. What diferences exists between these two pakages? Am I missing something using the first pakage instead using the dmg distribution? Thanks in advance for any answer. Luca. Upgrade to Internet Explorer 8 Optimised for MSN. Download Now _________________________________________________________________ With Windows Live, you can organise, edit, and share your photos. http://clk.atdmt.com/UKM/go/134665338/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090930/44cd580b/attachment.html From batterseapower at hotmail.com Wed Sep 30 08:29:38 2009 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Wed Sep 30 08:07:33 2009 Subject: [Haskell-cafe] Ghci dynamic linking (Was: C++ libraries and GHCI) In-Reply-To: <2af4014d0909290736l110908f4vaf058c6efdfd0f86@mail.gmail.com> References: <2af4014d0909290736l110908f4vaf058c6efdfd0f86@mail.gmail.com> Message-ID: <9d4d38820909300529r4deb4a98j6a669c4ba1b6a4ce@mail.gmail.com> (Moving to ghc-users) I'd never seen V in nm output before: """ The symbol is a weak object. When a weak defined symbol is linked with a normal defined symbol, the normal defined symbol is used with no error. When a weak undefined symbol is linked and the symbol is not defined, the value of the weak symbol becomes zero with no error. On some systems, uppercase indicates that a default value has been specified. """" Perhaps support needs to be added for this symbol type to the GHCi dynamic linker? (It would work in compiled programs b/c we call down to the system static linker in that case). Cheers, Max 2009/9/29 Paolo Losi : > Hi all, > > I would really appreciate if anyone could > give a look to the following problem. > > Thanks in advance!!! > Paolo > > > ---------- Forwarded message ---------- > From: Paolo Losi > Date: Mon, Sep 14, 2009 at 10:33 AM > Subject: C++ libraries and GHCI > To: glasgow-haskell-users@haskell.org > > > Hi all, > > I'm working on a tentative implementation of haskell binding to libsvm [1]: > > http://hackage.haskell.org/package/HSvm > > The package includes libsvm C++ sources. > While it works perfectly with ghc --make (try to install the package and > compile http://bitbucket.org/pao/hsvm/raw/6cf7ca91f1e5/test/test.hs), > it fails with ghci: > > (hsvm)(env)paolo@moltrasio:~/trash$ ghci test.hs > GHCi, version 6.10.4: http://www.haskell.org/ghc/ ?:? for help > Loading package ghc-prim ... linking ... done. > Loading package integer ... linking ... done. > Loading package base ... linking ... done. > Ok, modules loaded: Main. > Prelude Main> main > Loading package syb ... linking ... done. > Loading package array-0.2.0.0 ... linking ... done. > Loading package containers-0.2.0.1 ... linking ... done. > Loading package HSvm-0.1.0.2.89 ... linking ... : > /home/paolo/trash/hsvm/lib/HSvm-0.1.0.2.89/ghc-6.10.4/HSHSvm-0.1.0.2.89.o: > unknown symbol `_ZTV6Kernel' > ghc: unable to load package `HSvm-0.1.0.2.89' > > Please note that the symbol is available in libHSHSvm-0.1.0.2.89.a > > $ nm HSHSvm-0.1.0.2.89.o |grep _ZTV6Kernel > 00000000 V _ZTV6Kernel > $ nm libHSHSvm-0.1.0.2.89.a |grep _ZTV6Kernel > 00000000 V _ZTV6Kernel > > Can anyone give a look to the problem? > > Thanks > Paolo > > [1] http://www.csie.ntu.edu.tw/~cjlin/libsvm/ > > > > -- > Paolo Losi > e-mail: paolo@enuan.com > mob: ? +39 348 7705261 > > ENUAN Srl > Via XX Settembre, 12 - 29100 Piacenza > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From byorgey at seas.upenn.edu Wed Sep 30 10:02:52 2009 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Wed Sep 30 09:40:47 2009 Subject: which difference... In-Reply-To: References: Message-ID: <20090930140252.GA30464@seas.upenn.edu> On Wed, Sep 30, 2009 at 12:35:01PM +0100, Luca Ciciriello wrote: > > Hi all. > I've recently changed my home machine (MacOS X 10.5.8 intel) and I've installed the GHC 6.10.4 using the pakage: GHC-6.10.4-i386.pkg. > All works fine and I can continue all my research projects on my new machine. > > Then I've noticed that exists another kind of installation using the package: > haskell-platform-2009.2.0.2-i386.dmg. > > What diferences exists between these two pakages? Am I missing something using the first pakage instead using the dmg distribution? GHC is just a Haskell compiler. The Haskell Platform includes GHC, but also a collection of "blessed" libraries and tools. See hackage.haskell.org/platform/ You probably want to be using the platform unless you have a specific reason to not want all the library and tool goodness that comes bundled with it. -Brent