From AndreasSchropp at web.de Sun Sep 2 20:56:44 2007 From: AndreasSchropp at web.de (Andreas Schropp) Date: Sun Sep 2 20:38:21 2007 Subject: RULES and type classes Message-ID: <46DB5BCC.5000907@web.de> > // > In particular, it would be nice to be able to specialise based on the > instances, as we do for [a] --> [Int], e.g. > > RULES sum = sumInt :: [Int] -> Int > > is fine in the current system. So I could imagine some nice > specialisations based on say, the good old Ord: > > RULES nub = nubOrd :: (Eq a, Ord a) => [a] -> [a] > > which might use a Map, say. > > I don't know how costly this instance matching would be. > -- Don In principle I think you should be able to get constraint-specialized implementations right now, using Oleg's type-class overloaded (aka 2-polymorphic) functions (http://okmij.org/ftp/Haskell/poly2.txt). Some prototyping, not tested: import Poly2 {- -- from Poly2: (these can also be expressed as `TypeCls'-Membership-instance -> feasable with deriving machinery?) type Fractionals = Float :*: Double :*: HNil type Nums = Int :*: Integer :*: AllOf Fractionals :*: HNil type Ords = Bool :*: Char :*: AllOf Nums :*: HNil type Eqs = AllOf (TypeCl OpenEqs) :*: AllOfBut Ords Fractionals :*: HNil -} data NubLabel -- Ord-specialized instance, guarded by Membership-Predicate instance GFN Z NubLabel (Member Ords) instance (Ord a) => Apply (GFnA Z NubLabel) [a] [a] where -- we get here if Guard succeded apply _ = Map.tolist . Map.fromListWith const -- default instance instance TypeCast pred Otherwise => GFN n NubLabel pred instance (Eq a) => Apply (GFnA n NubLabel) [a] [a] where apply _ = List.nub nub_opt xs = apply (GFn NubLabel) xs But it probably needs some deriving-infrastructure for the `TypeCls' member-predicate to make it feasible. BTW: rewriting rules being turing-complete, I'm wondering if theres some "freaky hackery" to be discovered, or yet going on? :> From chak at cse.unsw.edu.au Mon Sep 3 03:40:14 2007 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Mon Sep 3 03:31:22 2007 Subject: Type Synonyms and termination checking In-Reply-To: References: Message-ID: <46DBBA5E.4090000@cse.unsw.edu.au> There is now also a draft paper that explains the rational for the restrictions described on the wiki page referenced by Lennart. You can eg find it at http://www.cse.unsw.edu.au/~chak/papers/SSPC07.html Manuel PS: I also just added a link to the paper to the wiki page. Lennart Augustsson wrote, > Look at the end of http://haskell.org/haskellwiki/GHC/Indexed_types > > -- Lennart > > On 8/31/07, * Jim Apple* > wrote: > > Regarding > > http://www.haskell.org/pipermail/cvs-ghc/2007-August/037655.html > > and > > Are type functions checked for termination? If so, where can I find > the details? > > Jim From simonpj at microsoft.com Mon Sep 3 05:59:22 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Sep 3 05:49:58 2007 Subject: RULES and type classes In-Reply-To: <46DB5BCC.5000907@web.de> References: <46DB5BCC.5000907@web.de> Message-ID: | > In particular, it would be nice to be able to specialise based on the | > instances, as we do for [a] --> [Int], e.g. | > | > RULES sum = sumInt :: [Int] -> Int | > | > is fine in the current system. So I could imagine some nice | > specialisations based on say, the good old Ord: | > | > RULES nub = nubOrd :: (Eq a, Ord a) => [a] -> [a] | > | > which might use a Map, say. This would be hard, because it'd mean that GHC's *rule rewrite engine* would need to be able to ask "is there an Ord instance for this type T?" Currently the rule rewrite engine performs simple syntactic matching, which is a much much easier thing. One could imagine a cleverer, type-class-aware optimisation pass, but I would suggest that it'd be cleaner to keep it separate from the nice simple rewrite engine. Simon From mechvel at botik.ru Tue Sep 4 04:27:34 2007 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Tue Sep 4 04:17:47 2007 Subject: 6.6.1 + DoCon on Mac OS Message-ID: <20070904082734.GA8919@scico.botik.ru> People, please, who can advise about ghc-6.6.1 + DoCon on Mac OS ? There exists the public release of DoCon-2.09 computer algebra application, which works under ghc-6.6.1 (http://haskell.org/docon). It was tested only under Linux. I hope that it will work under Unix too. But what about Mac OS ? (`Mac' means Mackintosh ?) Can you look into the files install.txt, source/Makefile, source/docon.cabal in DoCon-2.09 and tell whether this installation is likely to work under Mac OS ? How DoCon-2.09 + ghc-6.6.1 can be ported to Mac OS ? Thank you in advance for your explanation. ----------------- Serge Mechveliani mechvel@botik.ru From mechvel at botik.ru Tue Sep 4 05:44:10 2007 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Tue Sep 4 05:34:19 2007 Subject: 6.6.1 + docon on MacOS X Message-ID: <20070904094410.GA8981@scico.botik.ru> People, here is more detail to my last letter about ghc-6.6.1 + docon-2.09 on MacOS : the system is Mac OS X 10.4. Thank you in advance for your explanation. ----------------- Serge Mechveliani mechvel@botik.ru From Christian.Maeder at dfki.de Tue Sep 4 11:35:59 2007 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Sep 4 11:26:47 2007 Subject: 6.6.1 + DoCon on Mac OS In-Reply-To: <20070904082734.GA8919@scico.botik.ru> References: <20070904082734.GA8919@scico.botik.ru> Message-ID: <46DD7B5F.2030202@dfki.de> Have a look at http://en.wikipedia.org/wiki/Apple_Macintosh The underlying Darwin is Unix like, so Docon might well work under MacOS. One problem may be that file names are not case sensitive on Macs. > Can you look into the files install.txt, source/Makefile, > source/docon.cabal Most haskell stuff runs under MacOS. HTH Christian From g9ks157k at acme.softbase.org Tue Sep 4 17:45:37 2007 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Tue Sep 4 17:35:55 2007 Subject: configure option --oldincludedir Message-ID: <200709042345.38106.g9ks157k@acme.softbase.org> Hello, what is the option --oldincludedir of the configure script in the current 6.7 nightly snapshot for? ./configure --help says that its default is /usr/include. Is this directory used to install files into or is it just used for reading files? Best wishes, Wolfgang From mechvel at botik.ru Wed Sep 5 03:01:35 2007 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Wed Sep 5 02:51:52 2007 Subject: file name letters Message-ID: <20070905070135.GA9723@scico.botik.ru> Dear GHC users and developers, there has occured a curious case with file name letters. One user has built the docon library application (in Haskell) on MacOS X 10.4 + ghc-6.6.1. And making the test program has failed due to the presence of the file linalg.hs in the directory of the testing modules for DoCon. This file is not needed for this docon release, it is a reserve. I set its name in the lower case letters in order for GHC to ignore it. I test DoCon only in Linux, and have not access to MacOS. Thanks to Christian Maeder , he noticed that MacOS ignores the letter case in the file names! When the commands cd demotest ghc ... --make Main run on MacOS, ghc suddenly touches the file linalg.hs -- for some reason (and there also exists LinAlg in the library built). All right, I shall readily fix this `bug'. But out of curiosity, who's bug is this: of GHC, DoCon, or MacOS ? Is the file name letters a matter of Haskell-98 ? Do the GHC docs mention the question of the letter case in the file names? Regards, ----------------- Serge Mechveliani mechvel@botik.ru From arthurvl at cs.uu.nl Wed Sep 5 09:04:34 2007 From: arthurvl at cs.uu.nl (Arthur van Leeuwen) Date: Wed Sep 5 08:55:02 2007 Subject: file name letters In-Reply-To: <20070905070135.GA9723@scico.botik.ru> References: <20070905070135.GA9723@scico.botik.ru> Message-ID: On 5-sep-2007, at 9:01, Serge D. Mechveliani wrote: > Dear GHC users and developers, > > there has occured a curious case with file name letters. > One user has built the docon library application (in Haskell) > on > MacOS X 10.4 + ghc-6.6.1. > > And making the test program has failed due to the presence of the file > > linalg.hs > > in the directory of the testing modules for DoCon. > This file is not needed for this docon release, it is a reserve. I set > its name in the lower case letters in order for GHC to ignore it. > > I test DoCon only in Linux, and have not access to MacOS. > Thanks to Christian Maeder , > he noticed that MacOS ignores the letter case in the file names! > When the commands > cd demotest > ghc ... --make Main > > run on MacOS, ghc suddenly touches the file linalg.hs -- for some > reason > (and there also exists LinAlg in the library built). > > All right, I shall readily fix this `bug'. > > But out of curiosity, who's bug is this: of GHC, DoCon, or MacOS ? > Is the file name letters a matter of Haskell-98 ? > Do the GHC docs mention the question of the letter case in the file > names? Ouch, the well-known case-preserving but case-ignoring default behaviour of MacOS X's file system bites someone again. In short: Mac OS X's filesystem ignores case when opening a file, but preserves case when creating. Therefore, if you have a file linalg.hs and you wish to open LinAlg.hs then the file linalg.hs is going to be opened. Trying to create LinAlg.hs will fail, as linalg.hs already exists! Yes, this leads to stupid behaviour from time to time. The behaviour can be changed, but only on creation of the filesystem. WIth regards, Arthur. -- /\ / | arthurvl@cs.uu.nl | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt / \/__ | you can dare to be yourself | Dance like there's nobody watching From ndmitchell at gmail.com Wed Sep 5 09:30:57 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Sep 5 09:21:24 2007 Subject: file name letters In-Reply-To: References: <20070905070135.GA9723@scico.botik.ru> Message-ID: <404396ef0709050630q5ec8b10aofd844163580fb6db@mail.gmail.com> Hi > Ouch, the well-known case-preserving but case-ignoring default behaviour > of MacOS X's file system bites someone again. > > In short: Mac OS X's filesystem ignores case when opening a file, but > preserves > case when creating. FWIW, Windows has exactly the same behaviour. Technically you can change to case sensitive at format time, but I've never actually seen anyone running in this mode. Thanks Neil From gwright at comcast.net Wed Sep 5 15:33:43 2007 From: gwright at comcast.net (Gregory Wright) Date: Wed Sep 5 15:24:11 2007 Subject: 6.6.1 + DoCon on Mac OS In-Reply-To: <20070904082734.GA8919@scico.botik.ru> References: <20070904082734.GA8919@scico.botik.ru> Message-ID: Hi Serge, On Sep 4, 2007, at 4:27 AM, Serge D. Mechveliani wrote: > People, > > please, who can advise about ghc-6.6.1 + DoCon on Mac OS ? > > in DoCon-2.09 and tell whether this installation is likely to work > under Mac OS ? > How DoCon-2.09 + ghc-6.6.1 can be ported to Mac OS ? > I ported DoCon 2.09 to OS X using the MacPorts infrastructure several months ago. It built fine, and I was able to run a few simple tests. I didn't check it in for some reason --- I probably just forgot. I have fixed that. DoCon is now available from MacPorts. The build depends on having ghc from MacPorts. If ghc is not installed, it will be built from source. Best Wishes, Greg From igloo at earth.li Wed Sep 5 15:51:17 2007 From: igloo at earth.li (Ian Lynagh) Date: Wed Sep 5 15:41:43 2007 Subject: configure option --oldincludedir In-Reply-To: <200709042345.38106.g9ks157k@acme.softbase.org> References: <200709042345.38106.g9ks157k@acme.softbase.org> Message-ID: <20070905195117.GA11834@matrix.chaos.earth.li> Hi Wolfgang, On Tue, Sep 04, 2007 at 11:45:37PM +0200, Wolfgang Jeltsch wrote: > > what is the option --oldincludedir of the configure script in the current 6.7 > nightly snapshot for? ./configure --help says that its default > is /usr/include. Is this directory used to install files into or is it just > used for reading files? auto(re)conf makes the flag for us. We don't use the value. Thanks Ian From Christian.Maeder at dfki.de Thu Sep 6 05:13:10 2007 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Sep 6 05:03:46 2007 Subject: Mac GHC binary In-Reply-To: <6B108A10-84C1-472C-83A8-74CD99F4E532@galois.com> References: <6B108A10-84C1-472C-83A8-74CD99F4E532@galois.com> Message-ID: <46DFC4A6.3020407@dfki.de> Hi Jeff, I think, there's only a problem when the GNUreadline framework is only in your home directory and when you want to link your own binary. Correct me if you also have a problem if the framework is globally installed in /Library/Frameworks. Indeed a framework entry is missing in the package.conf. But I doubt if a generic entry using $HOME would work. So this entry could only be set at installation time for a single user (and I don't know how). In fact, for linking we use the additional ghc flags: -optl-F$HOME/Library/Frameworks -optl-framework -optlGNUreadline These flags could be put in top-level script for ghc (in bindir). Does anyone have a better idea? Cheers Christian P.S, I hope it's ok for you, if I forward this to glasgow-haskell-users@haskell.org, too Jeff Lewis wrote: > Hi Christian: > > A few people here have tried using your binary Mac OS X build of > GHC. There's one problem we've run into. The readline package doesn't > work out of the box. It seems to be necessary to add `-framework > GNUreadline'. This shouldn't be necessary. I'd guess that there's a > missing `frameworks' entry in the package description. > > --Jeff From mechvel at botik.ru Thu Sep 6 09:54:32 2007 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Thu Sep 6 09:44:31 2007 Subject: docon-2.10 Message-ID: <20070906135432.GA10814@scico.botik.ru> Announcement: I have put docon-2.10 instead of 2.09. What is new: two bugs fixed in installation. One of the fixes is for MacOS X, for its feature concerning the letter case in file names. Regards, ----------------- Serge Mechveliani mechvel@botik.ru From claus.reinke at talk21.com Fri Sep 7 21:30:37 2007 From: claus.reinke at talk21.com (Claus Reinke) Date: Fri Sep 7 21:20:59 2007 Subject: capturing ghci command output; :redir/:grep/:find Message-ID: <019901c7f1b7$dcd3dd90$b1098351@cr3lt> having only recently started to play with ghci's :def and :cmd, i'm still in the process of figuring out what is and what isn't possible, and i've been wondering what wonderful things other ghci users have in their .ghci files? to start with, here are my current favourites (definitions attached, this is using a recent ghc 6.7). i'm looking forward to seeing your gems and favourites:-) -- capturing command output in variables: *Main> :redir out :info Monad *Main> putStrLn out class Monad m where (>>=) :: m a -> (a -> m b) -> m b (>>) :: m a -> m b -> m b return :: a -> m a fail :: String -> m a -- Defined in GHC.Base instance Monad Maybe -- Defined in Data.Maybe instance Monad [] -- Defined in GHC.Base instance Monad IO -- Defined in GHC.IOBase -- filtering command output for lines matching pattern: *Main> :grep break :? :abandon at a breakpoint, abandon current computation :break [] [] set a breakpoint at the specified location :break set a breakpoint on the specified function :continue resume after a breakpoint :delete delete the specified breakpoint :delete * delete all breakpoints :step single-step after stopping at a breakpoint :trace trace after stopping at a breakpoint :trace trace into (remembers breakpoints for :history) :set stop set the command to run when a breakpoint is hit :show breaks show the active breakpoints :show context show the breakpoint context *Main> :grep class :browse Control.Monad class Monad m where class Functor f where fmap :: (a -> b) -> f a -> f b class (Monad m) => MonadPlus m where -- Hugs' :find , calling editor to open definition of *Main> :find main probably, there should be a wiki page collecting such :definitions, and other ways of improving the ghci usage experience. but i'm unsure whether to add to the haskell wiki http://haskell.org/haskellwiki/GHC/GHCi or to the ghc developer's wiki http://hackage.haskell.org/trac/ghc opinions? suggestions? tips? tricks?-) claus -------------- next part -------------- A non-text attachment was scrubbed... Name: cmds.ghci Type: application/octet-stream Size: 1836 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070908/1e6b1555/cmds-0001.obj From mnislaih at gmail.com Sat Sep 8 05:55:13 2007 From: mnislaih at gmail.com (Pepe Iborra) Date: Sat Sep 8 05:45:37 2007 Subject: capturing ghci command output; :redir/:grep/:find In-Reply-To: <019901c7f1b7$dcd3dd90$b1098351@cr3lt> References: <019901c7f1b7$dcd3dd90$b1098351@cr3lt> Message-ID: Neat! /me is going to love :grep and :redir All these are for playing with the debugger. -- running main in tracing mode *Main> :main arg1 arg2 ... *Main> :maintraced arg1 arg2 ... -- stepping into main *Main> :mainstep arg1 arg2 ... -- eval to whnf Prelude> let li = map Just [1..3] Prelude> :sp li li = _ Prelude> :eval li () Prelude> :sp li li = _ : _ -------------- next part -------------- A non-text attachment was scrubbed... Name: .ghci Type: application/octet-stream Size: 434 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070908/722851b0/ghci.obj -------------- next part -------------- On 08/09/2007, at 3:30, Claus Reinke wrote: > having only recently started to play with ghci's :def and :cmd, > i'm still in the process of figuring out what is and what isn't > possible, > and i've been wondering what wonderful things other ghci users have > in their .ghci files? > to start with, here are my current favourites (definitions > attached, this is using a recent ghc 6.7). i'm looking forward to > seeing your > gems and favourites:-) > > -- capturing command output in variables: > *Main> :redir out :info Monad > *Main> putStrLn out > class Monad m where > (>>=) :: m a -> (a -> m b) -> m b > (>>) :: m a -> m b -> m b > return :: a -> m a > fail :: String -> m a > -- Defined in GHC.Base > instance Monad Maybe -- Defined in Data.Maybe > instance Monad [] -- Defined in GHC.Base > instance Monad IO -- Defined in GHC.IOBase > > -- filtering command output for lines matching pattern: > *Main> :grep break :? > > :abandon at a breakpoint, abandon current > computation > :break [] [] set a breakpoint at the specified > location > :break set a breakpoint on the specified > function > :continue resume after a breakpoint > :delete delete the specified breakpoint > :delete * delete all breakpoints > :step single-step after stopping at a > breakpoint > :trace trace after stopping at a breakpoint > :trace trace into (remembers > breakpoints for :history) > :set stop set the command to run when a > breakpoint is hit > :show breaks show the active breakpoints > :show context show the breakpoint context > > *Main> :grep class :browse Control.Monad > > class Monad m where > class Functor f where fmap :: (a -> b) -> f a -> f b > class (Monad m) => MonadPlus m where > > -- Hugs' :find , calling editor to open definition of > *Main> :find main > > probably, there should be a wiki page collecting such :definitions, > and other ways of improving the ghci usage experience. but i'm > unsure whether to add to the haskell wiki > > http://haskell.org/haskellwiki/GHC/GHCi > > or to the ghc developer's wiki > > http://hackage.haskell.org/trac/ghc > > opinions? suggestions? tips? tricks?-) > claus_______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From benjovi at gmx.net Mon Sep 10 11:12:09 2007 From: benjovi at gmx.net (Benedikt Huber) Date: Mon Sep 10 11:02:15 2007 Subject: FFI and Libraries using GMP Message-ID: <53289F5B-39B6-41C5-9868-F4CC16BCEFDA@gmx.net> Hello, I've been struggling using FFI bindings to libraries which rely on the GNU Mp Bignum library (gmp) - this is apparently a well known problem (http://hackage.haskell.org/trac/ghc/ticket/311). I do want to use some of those libraries however and so I started to get them work on ghc-6.6.1/darwin_8_i368. But as no solution was close to being satisfactory, I'd like to ask for some advice. Those two options worked to some extend: (1) Create or modify the library in question, so gmp is statically linked and its symbols are hidden. When source code is available, this is relatively easy, altough it requires modification of the build process (which can be a hassle). If a static "ar" archive is available, it is cumbersome (at least on Mac Os X I ran into a lot of troubles using nmedit), but possible. Furthermore, the resulting libraries are bloated, as each of them contains a copy of the GMP; left alone portability issues. (2) As suggested in ticket#311, I tried switching the allocator functions when switching to FFI. It worked, but not in GHCi; also, doing it manually is a lot of work, because, as far as I could figure out, it is neccessary to write a wrapper function for every C-function (indirectly) using the gmp. Furthermore, most of the libraries expose gmp datatypes (mpz_t,mpq_t) in their API. I currently use a little haskell module working on GHC.Exts, but that's propably not a good option from a maintainer's point of view. There are certainly other possibilities, but I couldn't find one which is both maintainable and portable. I would be very grateful for any advice, or some information on plans for resolving ticket #311; I'm aware that there are long-term plans for replacing gmp, but I'd prefer a seperate short-term solution for the problems with the FFI. There are some great libraries (like the Parma Polyhedral Library, to pick an example) out there using gmp, and it would be nice if writing bindings to those libs could be simplified. Thanks, Benedikt From benjovi at gmx.net Mon Sep 10 09:39:53 2007 From: benjovi at gmx.net (benedikth) Date: Mon Sep 10 23:51:09 2007 Subject: FFI Bindings to Libraries using GMP Message-ID: Hello, I've been struggling using FFI bindings to libraries which rely on the GNU Mp Bignum library (gmp) - this is apparently a well known problem (http://hackage.haskell.org/trac/ghc/ticket/311, http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes). I do rely on using such libraries, and so started to get it work on MacOsX; no solution was close to being satisfactory however, so I'd like to ask for some advice. Those two options worked to some extend: (1) Create or modify the library in question, so gmp is statically linked and its symbols are hidden. When source code is available, this is relatively easy, altough it requires modification of the build process (which can be a hassle). If a static "ar" archive is available, it is cumbersome (at least on Mac Os X I ran into a lot of troubles using nmedit), but possible. Furthermore, the resulting libraries are bloated, as each of them contains a copy of the GMP; left alone portability issues. (2) As suggested in ticket#311, I tried switching the allocator functions when switching to FFI. It worked, but not in GHCi; also, doing it manually is a lot of work, because, as far as I could figure out, it is neccessary to write a wrapper function for every C-function (indirectly) using the gmp. Furthermore, most of the libraries expose gmp datatypes (mpz_t,mpq_t) in their API. I currently use a little haskell module working on GHC.Exts, but that's propably not a good option from a maintainer's point of view. There are certainly other possibilities, but I couldn't find one which is both maintainable and portable. I would be very grateful for any advice, or some information on plans for resolving ticket #311. There are some great libraries (like the Parma Polyhedral Library, to pick an example) out there using gmp, and it would be nice if writing bindings to those libs could be simplified. Thanks, Benedikt Huber From simonpj at microsoft.com Tue Sep 11 03:08:47 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Sep 11 02:58:58 2007 Subject: FFI Bindings to Libraries using GMP In-Reply-To: References: Message-ID: | I've been struggling using FFI bindings to libraries which rely on the | GNU Mp Bignum library (gmp) - this is apparently a well known problem | (http://hackage.haskell.org/trac/ghc/ticket/311, | http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes). | I do rely on using such libraries, and so started to get it work on | MacOsX; no solution was close to being satisfactory however, so I'd like | to ask for some advice. It's an issue that bites very few users, but it bites them hard. It's also tricky, but not impossible, to fix. The combination keeps meaning that at GHC HQ we work on things that affect more people. I doubt we can spare effort to design and implement a fix in the near future -- we keep hoping someone else step up and tackle it! Peter Tanski did exactly that (he's the author of the ReplacingGMPNotes above), but he's been very quiet recently. I don't know where he is up to. Perhaps someone else would like to join in? Meanwhile I've added your comments to #311 so they stay with the ticket. Simon | | Those two options worked to some extend: | (1) | Create or modify the library in question, so gmp is statically linked | and its symbols are hidden. | When source code is available, this is relatively easy, altough it | requires modification of the build process (which can be a hassle). If a | static "ar" archive is available, it is cumbersome (at least on Mac Os X | I ran into a lot of troubles using nmedit), but possible. Furthermore, | the resulting libraries are bloated, as each of them contains a copy of | the GMP; left alone portability issues. | (2) | As suggested in ticket#311, I tried switching the allocator functions | when switching to FFI. It worked, but not in GHCi; also, doing it | manually is a lot of work, because, as far as I could figure out, it is | neccessary to write a wrapper function for every C-function (indirectly) | using the gmp. | | Furthermore, most of the libraries expose gmp datatypes (mpz_t,mpq_t) in | their API. I currently use a little haskell module working on | GHC.Exts, but that's propably not a good option from a maintainer's | point of view. There are certainly other possibilities, but I couldn't | find one which is both maintainable and portable. | | I would be very grateful for any advice, or some information on plans | for resolving ticket #311. There are some great libraries (like the | Parma Polyhedral Library, to pick an example) out there using gmp, and | it would be nice if writing bindings to those libs could be simplified. | | Thanks, | Benedikt Huber | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From neubauer at informatik.uni-freiburg.de Tue Sep 11 17:04:22 2007 From: neubauer at informatik.uni-freiburg.de (Matthias Neubauer) Date: Tue Sep 11 16:54:29 2007 Subject: FFI Bindings to Libraries using GMP In-Reply-To: (Simon Peyton-Jones's message of "Tue, 11 Sep 2007 08:08:47 +0100") References: Message-ID: Simon Peyton-Jones writes: > Peter Tanski did exactly that (he's the author of the > ReplacingGMPNotes above), but he's been very quiet recently. I > don't know where he is up to. Perhaps someone else would like to > join in? Since I live only five minutes away from this year's Hackathon venue, I guess it would be kind of silly to have such an event in my neighborhood and not go to it! :) I would enjoy working on this during the hackathon. Is there a reason to not start with a simple, Haskell-only implementation? And later use techniques known from ByteStrings and stream fusion to improve on that. -Matthias -- Matthias Neubauer | Universit?t Freiburg, Institut f?r Informatik | tel +49 761 203 8060 Georges-K?hler-Allee 79, 79110 Freiburg i. Br., Germany | fax +49 761 203 8052 From dons at galois.com Tue Sep 11 18:27:45 2007 From: dons at galois.com (Don Stewart) Date: Tue Sep 11 18:18:04 2007 Subject: FFI Bindings to Libraries using GMP In-Reply-To: References: Message-ID: <20070911222745.GG21331@liouville.galois.com> neubauer: > Simon Peyton-Jones writes: > > > Peter Tanski did exactly that (he's the author of the > > ReplacingGMPNotes above), but he's been very quiet recently. I > > don't know where he is up to. Perhaps someone else would like to > > join in? > > Since I live only five minutes away from this year's Hackathon venue, > I guess it would be kind of silly to have such an event in my > neighborhood and not go to it! :) > > I would enjoy working on this during the hackathon. Is there a reason > to not start with a simple, Haskell-only implementation? And later use > techniques known from ByteStrings and stream fusion to improve on that. > > -Matthias Oh, Matthias: if you're coming to the hackathon, please register so we can get you a tshirt! :) Details on the hackathon page. http://www.haskell.org/haskellwiki/Hac_2007_II -- Don From trevion at gmail.com Wed Sep 12 01:13:00 2007 From: trevion at gmail.com (J. Garrett Morris) Date: Wed Sep 12 01:03:05 2007 Subject: getMBlocks: VirtualAlloc MEM_RESERVE 1 blocks failed Message-ID: <6cf91caa0709112213q13255482s4d596af7f9179c43@mail.gmail.com> Hello everyone, I've been running into the following error: Reproduction.exe: getMBlocks: VirtualAlloc MEM_RESERVE 1 blocks failed: Not enough storage is available to process this command. The confusing part to me is that when the error occurs, Task Manager reports that the process is using around 100K of memory, while I know that the machine has at least 2GB available. Reproduction case is attached. This runs against the Netflix prize training set, which is large enough that I haven't attached it. At the time that the error occurs, it's processed on the order of 15,500 files. Is it possible there's some other resource that I'm exhausting without realizing it? The compiler command line is: ghc --make -O2 -threaded -hidir obj -odir obj -o Reproduction Reproduction.hs /g -------------- next part -------------- A non-text attachment was scrubbed... Name: Reproduction.hs Type: text/x-haskell Size: 1909 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070911/d45e96bb/Reproduction-0001.bin From igloo at earth.li Wed Sep 12 20:07:18 2007 From: igloo at earth.li (Ian Lynagh) Date: Wed Sep 12 20:07:18 2007 Subject: ANNOUNCE: GHC 6.8.1 Release Candidate Message-ID: <20070913000718.GA16083@matrix.chaos.earth.li> We are pleased to announce the Release Candidate phase for GHC 6.8.1. Snapshots beginning with 6.8.20070909 are release candidates for 6.8.1 You can download snapshots from here: http://www.haskell.org/ghc/dist/stable/dist/ Right now we have the source bundles: http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.20070912-src.tar.bz2 http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.20070912-src-extralibs.tar.bz2 Only the first of these is necessary. The "extralibs" package contains various extra packages that we normally supply with GHC - unpack the extralibs tarball on top of the source tree to add them, and they will be included in the build automatically. There is also currently an installer for i386/Windows and binary distributions for x86_64/Linux and i386/Linux. More may appear later. Please test as much as possible; bugs are much cheaper if we find them before the release! We hope to release in a couple of weeks, but of course that may slip if problems are uncovered. Thanks Ian, on behalf of the GHC team From stefan at cs.uu.nl Thu Sep 13 01:55:21 2007 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Thu Sep 13 01:55:24 2007 Subject: ANNOUNCE: GHC 6.8.1 Release Candidate In-Reply-To: <20070913000718.GA16083@matrix.chaos.earth.li> References: <20070913000718.GA16083@matrix.chaos.earth.li> Message-ID: <912F7D86-0B6E-4ED5-81C5-BC4B6347A1DF@cs.uu.nl> Ian, > We are pleased to announce the Release Candidate phase for GHC 6.8.1. That's 6.8, right? Or have I missed something? Cheers, Stefan From tomasz.zielonka at gmail.com Thu Sep 13 04:55:31 2007 From: tomasz.zielonka at gmail.com (Tomasz Zielonka) Date: Thu Sep 13 04:55:34 2007 Subject: ANNOUNCE: GHC 6.8.1 Release Candidate In-Reply-To: <20070913000718.GA16083@matrix.chaos.earth.li> References: <20070913000718.GA16083@matrix.chaos.earth.li> Message-ID: <20070913085531.GC10584@lambda> On Thu, Sep 13, 2007 at 01:07:18AM +0100, Ian Lynagh wrote: > We are pleased to announce the Release Candidate phase for GHC 6.8.1. > > Snapshots beginning with 6.8.20070909 are release candidates for 6.8.1 > > You can download snapshots from here: > > http://www.haskell.org/ghc/dist/stable/dist/ > > Right now we have the source bundles: > > http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.20070912-src.tar.bz2 > http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.20070912-src-extralibs.tar.bz2 Seems there is a missing "do" in compiler/main/InteractiveEval.hs on line 334. Best regards Tomek From igloo at earth.li Thu Sep 13 08:26:05 2007 From: igloo at earth.li (Ian Lynagh) Date: Thu Sep 13 08:26:03 2007 Subject: ANNOUNCE: GHC 6.8.1 Release Candidate In-Reply-To: <912F7D86-0B6E-4ED5-81C5-BC4B6347A1DF@cs.uu.nl> References: <20070913000718.GA16083@matrix.chaos.earth.li> <912F7D86-0B6E-4ED5-81C5-BC4B6347A1DF@cs.uu.nl> Message-ID: <20070913122605.GA23688@matrix.chaos.earth.li> Hi Stefan, On Thu, Sep 13, 2007 at 07:55:21AM +0200, Stefan Holdermans wrote: > > >We are pleased to announce the Release Candidate phase for GHC 6.8.1. > > That's 6.8, right? Or have I missed something? No, it's 6.8.1: http://www.haskell.org/ghc/dist/current/docs/users_guide/version-numbering.html Thanks Ian From igloo at earth.li Thu Sep 13 08:26:42 2007 From: igloo at earth.li (Ian Lynagh) Date: Thu Sep 13 08:26:40 2007 Subject: ANNOUNCE: GHC 6.8.1 Release Candidate In-Reply-To: <20070913085531.GC10584@lambda> References: <20070913000718.GA16083@matrix.chaos.earth.li> <20070913085531.GC10584@lambda> Message-ID: <20070913122642.GB23688@matrix.chaos.earth.li> On Thu, Sep 13, 2007 at 10:55:31AM +0200, Tomasz Zielonka wrote: > > Seems there is a missing "do" in compiler/main/InteractiveEval.hs on > line 334. Thanks for the report! It will be fixed in the next snapshot. Thanks Ian From ahey at iee.org Thu Sep 13 10:24:42 2007 From: ahey at iee.org (Adrian Hey) Date: Thu Sep 13 10:24:49 2007 Subject: ANNOUNCE: GHC 6.8.1 Release Candidate In-Reply-To: <20070913000718.GA16083@matrix.chaos.earth.li> References: <20070913000718.GA16083@matrix.chaos.earth.li> Message-ID: <46E9482A.6030207@iee.org> Ian Lynagh wrote: > Please test as much as possible; bugs are much cheaper if we find them > before the release! With the windows build ghc-6.8.20070912-i386-unknown-mingw32.exe, when I try something like.. runghc Setup.hs build I get this error message.. ghc.exe: not built for interactive use Regards -- Adrian Hey From igloo at earth.li Thu Sep 13 10:48:27 2007 From: igloo at earth.li (Ian Lynagh) Date: Thu Sep 13 10:48:26 2007 Subject: ANNOUNCE: GHC 6.8.1 Release Candidate In-Reply-To: <46E9482A.6030207@iee.org> References: <20070913000718.GA16083@matrix.chaos.earth.li> <46E9482A.6030207@iee.org> Message-ID: <20070913144827.GA29908@matrix.chaos.earth.li> On Thu, Sep 13, 2007 at 03:24:42PM +0100, Adrian Hey wrote: > Ian Lynagh wrote: > >Please test as much as possible; bugs are much cheaper if we find them > >before the release! > > With the windows build ghc-6.8.20070912-i386-unknown-mingw32.exe, when > I try something like.. > > runghc Setup.hs build > > I get this error message.. > > ghc.exe: not built for interactive use Thanks for the report! This is a symptom of the stage2 build failure, meaning the installer is using the stage 1 compiler which can't do bytecode compilation. Therefore this should also be fixed in the next snapshot. Thanks Ian From simonpj at microsoft.com Thu Sep 13 11:40:25 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Sep 13 11:40:24 2007 Subject: FFI Bindings to Libraries using GMP In-Reply-To: References: Message-ID: I won't be at the hackathon I fear (and neither will Simon M) but I jotted down some notes about how to replace GMP with a Haskell library http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes/HaskellLibrary Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On | Behalf Of Matthias Neubauer | Sent: 11 September 2007 22:04 | To: Simon Peyton-Jones | Cc: glasgow-haskell-users@haskell.org; benedikth; Peter Tanski | Subject: Re: FFI Bindings to Libraries using GMP | | Simon Peyton-Jones writes: | | > Peter Tanski did exactly that (he's the author of the | > ReplacingGMPNotes above), but he's been very quiet recently. I | > don't know where he is up to. Perhaps someone else would like to | > join in? | | Since I live only five minutes away from this year's Hackathon venue, | I guess it would be kind of silly to have such an event in my | neighborhood and not go to it! :) | | I would enjoy working on this during the hackathon. Is there a reason | to not start with a simple, Haskell-only implementation? And later use | techniques known from ByteStrings and stream fusion to improve on that. | | -Matthias | | -- | Matthias Neubauer | | Universit?t Freiburg, Institut f?r Informatik | tel +49 761 203 8060 | Georges-K?hler-Allee 79, 79110 Freiburg i. Br., Germany | fax +49 761 203 8052 | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From jeremy.shaw at linspireinc.com Thu Sep 13 13:40:49 2007 From: jeremy.shaw at linspireinc.com (Jeremy Shaw) Date: Thu Sep 13 13:40:58 2007 Subject: ANNOUNCE: GHC 6.8.1 Release Candidate In-Reply-To: <20070913122605.GA23688@matrix.chaos.earth.li> References: <20070913000718.GA16083@matrix.chaos.earth.li> <912F7D86-0B6E-4ED5-81C5-BC4B6347A1DF@cs.uu.nl> <20070913122605.GA23688@matrix.chaos.earth.li> Message-ID: At Thu, 13 Sep 2007 13:26:05 +0100, Ian Lynagh wrote: > > > Hi Stefan, > > On Thu, Sep 13, 2007 at 07:55:21AM +0200, Stefan Holdermans wrote: > > > > >We are pleased to announce the Release Candidate phase for GHC 6.8.1. > > > > That's 6.8, right? Or have I missed something? > > No, it's 6.8.1: > > http://www.haskell.org/ghc/dist/current/docs/users_guide/version-numbering.html Seems like something is wrong with this version number though: Snapshots beginning with 6.8.20070909 are release candidates for 6.8.1 In many version numbering schemes, 6.8.20070909 would be a higher version than 6.8.1. According to policy: Stable snapshot releases are named x.y.z.YYYYMMDD. where YYYYMMDD is the date of the sources from which the snapshot was built, and x.y.z+1 is the next release to be made on that branch. For example, 6.8.1.20040225 would be a snapshot of the 6.8 branch during the development of 6.8.2. *Main> let version (x,y,z+1) date = concat [ show x, ".", show y, ".", show z, ".", date] *Main> version (6,8,1) "20070909" "6.8.0.20070909" ;) j. From igloo at earth.li Thu Sep 13 14:18:43 2007 From: igloo at earth.li (Ian Lynagh) Date: Thu Sep 13 14:18:43 2007 Subject: ANNOUNCE: GHC 6.8.1 Release Candidate In-Reply-To: References: <20070913000718.GA16083@matrix.chaos.earth.li> <912F7D86-0B6E-4ED5-81C5-BC4B6347A1DF@cs.uu.nl> <20070913122605.GA23688@matrix.chaos.earth.li> Message-ID: <20070913181843.GA955@matrix.chaos.earth.li> On Thu, Sep 13, 2007 at 10:40:49AM -0700, Jeremy Shaw wrote: > > Seems like something is wrong with this version number though: > > Snapshots beginning with 6.8.20070909 are release candidates for 6.8.1 You are right, thanks. I'll fix it. Ian From ahey at iee.org Fri Sep 14 02:50:47 2007 From: ahey at iee.org (Adrian Hey) Date: Fri Sep 14 02:52:51 2007 Subject: ANNOUNCE: GHC 6.8.1 Release Candidate In-Reply-To: <20070913144827.GA29908@matrix.chaos.earth.li> References: <20070913000718.GA16083@matrix.chaos.earth.li> <46E9482A.6030207@iee.org> <20070913144827.GA29908@matrix.chaos.earth.li> Message-ID: <46EA2F47.8030901@iee.org> Ian Lynagh wrote: > This is a symptom of the stage2 build failure, meaning the installer is > using the stage 1 compiler which can't do bytecode compilation. > > Therefore this should also be fixed in the next snapshot. OK. Meanwhile I've tried compiling setup.hs and building the 6.6 version of the collections package.. http://darcs.haskell.org/packages/collections-ghc6.6/ I get this error.. [29 of 53] Compiling Data.Tree.AVL.Join ( Data.Tree.AVL/Data/Tree/AVL/Join.hs, dist\build/Data/Tree/AVL/Join.o ) ghc.exe: panic! (the 'impossible' happened) (GHC version 6.8.20070912 for i386-unknown-mingw32): cgPanic a{v sMX} [lid] static binds for: collections-0.3:Data.Tree.AVL.Join.poly_go{v rse} [gid] collections-0.3:Data.Tree.AVL.Join.poly_$wlgo{v rsf} [gid] collections-0.3:Data.Tree.AVL.Join.flatConcat{v ryL} [gid] local binds for: SRT label collections-0.3:Data.Tree.AVL.Join.$LrMelvl{v rMe}_srt Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug BTW, if you want to reproduce this the cabal files needs this line.. build-depends: base >= 2.0, QuickCheck, bytestring >= 0.9, containers >= 0.1, array >= 0.1 Regards -- Adrian Hey From ahey at iee.org Fri Sep 14 04:46:11 2007 From: ahey at iee.org (Adrian Hey) Date: Fri Sep 14 04:46:16 2007 Subject: ANNOUNCE: GHC 6.8.1 Release Candidate In-Reply-To: <46EA2F47.8030901@iee.org> References: <20070913000718.GA16083@matrix.chaos.earth.li> <46E9482A.6030207@iee.org> <20070913144827.GA29908@matrix.chaos.earth.li> <46EA2F47.8030901@iee.org> Message-ID: <46EA4A53.2070806@iee.org> Adrian Hey wrote: > OK. Meanwhile I've tried compiling setup.hs and building the > 6.6 version of the collections package.. Also, there still seems to be a problem with building Haddock docs in windows. Although Haddock now seems to find the relevant base package haddock, it still doesn't link to it properly because the links are all missing the "file://" prefix. But I'm not sure if this is haddock-0.8 problem, a Cabal problem or a ghc distro problem. Regards -- Adrian Hey From p.k.f.holzenspies at utwente.nl Fri Sep 14 06:20:20 2007 From: p.k.f.holzenspies at utwente.nl (Philip =?utf-8?B?Sy5GLiBIw7ZsemVuc3BpZXM=?=) Date: Fri Sep 14 06:20:23 2007 Subject: ANNOUNCE: GHC 6.8.1 Release Candidate Message-ID: <20070914102020.GA30669@ewi1043.ewi.utwente.nl> Dear Ian, all, I'm getting a build error that I've seen before. I must be overlooking something. What I do: lzensp@ewi1043:~/local/src> curl http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.20070912-src.tar.bz2 | tar -xj % Total % Received % Xferd Average Speed Time Time Time % Current Dload Upload Total Spent Left Speed 100 6893k 100 6893k 0 0 682k 0 0:00:10 0:00:10 --:--:-- 743k holzensp@ewi1043:~/local/src> cd ghc-6.8.20070912 holzensp@ewi1043:~/local/src/ghc-6.8.20070912> ./boot Booting . Booting libraries/base Booting libraries/directory /usr/share/aclocal/progsreiserfs.m4:13: warning: underquoted definition of AC_CHECK_LIBREISERFS run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending-aclocal Booting libraries/old-time Booting libraries/process Booting libraries/readline Booting libraries/unix holzensp@ewi1043:~/local/src/ghc-6.8.20070912> ./configure && make [...] make[1]: *** No rule to make target `../includes/DerivedConstants.h', needed by `stage1/codeGen/CgProf.o'. Stop. make[1]: Leaving directory `/local/holzensp/src/ghc-6.8.20070912/compiler' make: *** [stage1] Error 1 Either this is a bugreport or a kind request for advice. Regards, Philip From benjovi at gmx.net Fri Sep 14 09:14:58 2007 From: benjovi at gmx.net (Benedikt Huber) Date: Fri Sep 14 09:14:50 2007 Subject: FFI Bindings to Libraries using GMP In-Reply-To: References: Message-ID: > | I've been struggling using FFI bindings to libraries which rely > on the > | GNU Mp Bignum library (gmp). > It's an issue that bites very few users, but it bites them hard. > It's also tricky, but not impossible, to fix. The combination > keeps meaning that at GHC HQ we work on things that affect more > people. I doubt we can spare effort to design and implement a fix > in the near future -- we keep hoping someone else step up and > tackle it! > > Peter Tanski did exactly that (he's the author of the > ReplacingGMPNotes above), but he's been very quiet recently. I > don't know where he is up to. Perhaps someone else would like to > join in? > Thank you for the information - I'm also willing to help, though I'm not too familiar with the GHC internals (yet). I do like the idea of optionally linking with a pure-haskell library, but I'm interested in a solution with comparable performance. Commenting solutions to ticket #311: (1) Creating a custom variant of the gmp lib by renaming symbols and possibly removing unneccessary functionality, as suggest by Simon Marlow in ticket #311 would be relatively straightforward; I've already tried this approach the other way round (i.e. recompile libraries to be used with the FFI). But it means that you'd have to maintain and ship another library, so I guess it is not an option for the GHC team. (2) Using the standard allocation functions for the gmp memory managment (maybe as compile flag) as suggested in http:// www.haskell.org/pipermail/glasgow-haskell-users/2006-July/010660.html would also resolve ticket #311. In this case at least the dynamic part of gmp integers has to be resized using external allocation functions, and a finalizer (mpz_clear) has to be called when an Integer is garbage collected. It seems that the performance loss by using malloc is significant [1], as lots of allocations and reallocations of very small chunks occur in a functional setting; some kind of (non garbage collected !) memory pool allocation would certainly help. I'm not sure what overhead is associated with calling a finalizer ? (3) So when replacing GMP with the BN library of OpenSSL (see http:// hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes/ PerformanceMeasurements), it would propably be neccessary to refactor the library, so custom allocation can be used as well. This does not seem too difficult at a first glance though. So I'd like to investigate the second or third option, as far as my knowledge and time permits it. Of course it would be wise to check first if Peter Tanski is already/ still working on a GMP replacement. Benedikt [1] Simple Performance Test on (ghc-darwin-i386-6.6.1): The haskell function (k was taken as 10M) > test k = (iterateT k (fromIntegral (maxBound ::Int))) :: Integer where > iterateT 0 v = v; iterateT k v = v `seq` iterateT (k-1) (v+10000) triggers around k allocations and k reallocations by the gmp library. The rough C equivalent, calling sequences of > malloc(3), mpz_init_set(gmp), mpz_add_ui(gmp), mpz_clear(gmp) and free(3), takes more than 2 times as long, with 25% of the time spend in allocating and freeing pointers to gmp integers (mpz_ptr) and 50% of the time spend in gmp allocator functions (i.e. resizing gmp integers = (re)allocating limbs). I also performed the test with the datatype suggested by John Meacham (using a gmp library with renamed symbols), > data FInteger = FInteger Int# (!ForeignPtr Mpz) but it was around 8x slower, maybe due to the ForeignPtr and FFI overhead, or due to missing optimizations in the code. From igloo at earth.li Fri Sep 14 09:42:03 2007 From: igloo at earth.li (Ian Lynagh) Date: Fri Sep 14 09:41:59 2007 Subject: ANNOUNCE: GHC 6.8.1 Release Candidate In-Reply-To: <20070914102020.GA30669@ewi1043.ewi.utwente.nl> References: <20070914102020.GA30669@ewi1043.ewi.utwente.nl> Message-ID: <20070914134203.GA2196@matrix.chaos.earth.li> Hi Philip, Thanks for the report! On Fri, Sep 14, 2007 at 12:20:20PM +0200, Philip K.F. H?lzenspies wrote: > > holzensp@ewi1043:~/local/src/ghc-6.8.20070912> ./boot > Booting . > Booting libraries/base > Booting libraries/directory This is running "autoreconf" in libraries/directory > /usr/share/aclocal/progsreiserfs.m4:13: warning: underquoted > definition of AC_CHECK_LIBREISERFS > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending-aclocal autoreconf seems to be complaining about its own library files here. I can't explain why you'd get this for directory but not for other libraries. Do you have multiple versions of autoreconf installed (will probably be part of an autoconf or autotools package, or similar)? Is this problem repeatable? > Booting libraries/old-time > Booting libraries/process > Booting libraries/readline > Booting libraries/unix > holzensp@ewi1043:~/local/src/ghc-6.8.20070912> ./configure && make > [...] > make[1]: *** No rule to make target `../includes/DerivedConstants.h', needed by `stage1/codeGen/CgProf.o'. Stop. > make[1]: Leaving directory > `/local/holzensp/src/ghc-6.8.20070912/compiler' > make: *** [stage1] Error 1 Earlier in the make process you should have something like: ------------------------------------------------------------------------ == make boot -r --jobserver-fds=3,4 -j; in /home/ian/ghc/darcs/val/includes ------------------------------------------------------------------------ Creating ghcautoconf.h... Done. Creating ghcplatform.h... Done. ../utils/mkdependC/mkdependC -f .depend -- -Werror -DTABLES_NEXT_TO_CODE -I. -I../rts -- mkDerivedConstants.c gcc -Werror -DTABLES_NEXT_TO_CODE -I. -I../rts -c mkDerivedConstants.c -o mkDerivedConstants.o gcc -o mkGHCConstants.o -Werror -DTABLES_NEXT_TO_CODE -I. -I../rts -c mkDerivedConstants.c -DGEN_HASKELL gcc -o mkDerivedConstantsHdr -Werror -DTABLES_NEXT_TO_CODE -I. -I../rts mkDerivedConstants.o ./mkDerivedConstantsHdr >DerivedConstants.h gcc -o mkGHCConstants -Werror -DTABLES_NEXT_TO_CODE -I. -I../rts mkGHCConstants.o ./mkGHCConstants >GHCConstants.h ------------------------------------------------------------------------ which creates DerivedConstants.h. Did this give any errors or anything? Can you check whether the file really does exist or not please? Thanks Ian From robert at gslt.hum.gu.se Fri Sep 14 10:33:20 2007 From: robert at gslt.hum.gu.se (Robert Andersson) Date: Fri Sep 14 10:33:15 2007 Subject: compiling on solaris 9 Message-ID: <18154.39856.339555.957367@mozart.gslt.hum.gu.se> Hello! When compiling ghc-6.6.1 on SunOS 5.9 I get the following error message > posix/OSMem.c:20:20: error: stdint.h: No such file or directory > gmake[1]: *** [posix/OSMem.o] Error 1 > gmake[1]: *** Waiting for unfinished jobs.... > > GC.c:1870:0: warning: 'regparm' attribute directive ignored > gmake: *** [stage1] Error 1 stdint.h seems to be unavailable on solaris 9. Looking at the rts/posix/OSMem.c file we find /* no C99 header stdint.h on OpenBSD? */ #if defined(openbsd_HOST_OS) typedef unsigned long my_uintptr_t; #else #include typedef uintptr_t my_uintptr_t; #endif so how would one go about not including the stdint.h for solaris? What would the typedef line look like, if one would e.g. do a check for defined(solaris2_HOST_OS)? yours, /robert PS. Fyi, I compiled with gcc 4.0.2 with CLFAGS="-O3 -mcpu=ultrasparc3 -m64" PPS. The binary distributed ghc-6.6.1 needs libm.so.2 which is not available prior to solaris 10. I also read ticket 1291 and no -- libm.so.2 is not available via Blastwave. -- Systems Administrator & IT-Coordinator Swedish National Graduate School of Language Technology Nordic Graduate School of Language Technology From kahl at cas.mcmaster.ca Fri Sep 14 16:46:09 2007 From: kahl at cas.mcmaster.ca (kahl@cas.mcmaster.ca) Date: Fri Sep 14 16:47:45 2007 Subject: ANNOUNCE: GHC 6.8.1 Release Candidate In-Reply-To: <20070913000718.GA16083@matrix.chaos.earth.li> (message from Ian Lynagh on Thu, 13 Sep 2007 01:07:18 +0100) References: <20070913000718.GA16083@matrix.chaos.earth.li> Message-ID: <20070914204609.11185.qmail@schroeder.cas.mcmaster.ca> > > We are pleased to announce the Release Candidate phase for GHC 6.8.1. > > Snapshots beginning with 6.8.20070909 are release candidates for 6.8.1 I encountered a case where compilation for nested type synonyms explodes --- this was no problem in 6.6.1. Wolfram -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/octet-stream Size: 2416 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070914/0ac82820/attachment.obj From sven.panne at aedion.de Sat Sep 15 05:05:53 2007 From: sven.panne at aedion.de (Sven Panne) Date: Sat Sep 15 05:05:47 2007 Subject: ANNOUNCE: GHC 6.8.1 Release Candidate In-Reply-To: <20070914134203.GA2196@matrix.chaos.earth.li> References: <20070914102020.GA30669@ewi1043.ewi.utwente.nl> <20070914134203.GA2196@matrix.chaos.earth.li> Message-ID: <200709151105.53402.sven.panne@aedion.de> On Friday 14 September 2007 15:42, Ian Lynagh wrote: > On Fri, Sep 14, 2007 at 12:20:20PM +0200, Philip K.F. H?lzenspies wrote: > [...] > > /usr/share/aclocal/progsreiserfs.m4:13: warning: underquoted > > definition of AC_CHECK_LIBREISERFS > > run info '(automake)Extending aclocal' > > or see > > http://sources.redhat.com/automake/automake.html#Extending-aclocal > > autoreconf seems to be complaining about its own library files here. I > can't explain why you'd get this for directory but not for other > libraries. Do you have multiple versions of autoreconf installed (will > probably be part of an autoconf or autotools package, or similar)? > Is this problem repeatable? Warnings like this can safely be ignored, you often get tons of them. At one point in time, the autoconf people decided to issue warnings for some things which have been documented as "don't do this", but it obviously takes ages until all packages obey these simple rules. The progreiserfs.m4 probably belongs to some badly maintained ReiserFS library which is installed on the system and gets included via arcane ways. Ugly, but nothing to worry about, as autoconf still does the same as before... Cheers, S. From sven.panne at aedion.de Sat Sep 15 05:09:44 2007 From: sven.panne at aedion.de (Sven Panne) Date: Sat Sep 15 05:09:38 2007 Subject: compiling on solaris 9 In-Reply-To: <18154.39856.339555.957367@mozart.gslt.hum.gu.se> References: <18154.39856.339555.957367@mozart.gslt.hum.gu.se> Message-ID: <200709151109.45120.sven.panne@aedion.de> On Friday 14 September 2007 16:33, Robert Andersson wrote: > stdint.h seems to be unavailable on solaris 9. Looking at the > rts/posix/OSMem.c file we find > > /* no C99 header stdint.h on OpenBSD? */ > #if defined(openbsd_HOST_OS) > typedef unsigned long my_uintptr_t; > #else > #include > typedef uintptr_t my_uintptr_t; > #endif Uh, oh... Using long doesn't look very 64bit-safe (it could be int, long, long long, who knows?). IIRC some systems without provide at least , so we should perhaps use this as a fallback? Cheers, S. From skaller at users.sourceforge.net Sat Sep 15 07:58:54 2007 From: skaller at users.sourceforge.net (skaller) Date: Sat Sep 15 07:58:50 2007 Subject: compiling on solaris 9 In-Reply-To: <200709151109.45120.sven.panne@aedion.de> References: <18154.39856.339555.957367@mozart.gslt.hum.gu.se> <200709151109.45120.sven.panne@aedion.de> Message-ID: <1189857534.10512.45.camel@rosella.wigram> On Sat, 2007-09-15 at 11:09 +0200, Sven Panne wrote: > On Friday 14 September 2007 16:33, Robert Andersson wrote: > > stdint.h seems to be unavailable on solaris 9. Looking at the > > rts/posix/OSMem.c file we find > > > > /* no C99 header stdint.h on OpenBSD? */ > > #if defined(openbsd_HOST_OS) > > typedef unsigned long my_uintptr_t; > > #else > > #include > > typedef uintptr_t my_uintptr_t; > > #endif > > Uh, oh... Using long doesn't look very 64bit-safe (it could be int, long, long > long, who knows?). IIRC some systems without provide at least > , so we should perhaps use this as a fallback? > The RIGHT way to do this is rather messy .. but there is only one right way to do it. 1. Measure the size (and alignment, while at it) of all the integer types. (trial execute and run). 2. Find out which headers are present (trial compilation) 3. For stdint.h if present, detect which typedefs are provided. (trial compilation) 4. For the ones provided, AND size_t, ptrdiff_t, check their size (and signedness). (trial execution) 5. For the fundamental types, write a set of C++ functions overloaded on the types, which print which one was chosen. Yes, this step is mandatory, and it must be done in C++. 6. Test what the typedefs found are actually aliased to using C++ (there is no other portable way to do this). (Trial execution) 7. NOW, define YOUR OWN typedefs and macros to model C99 types when available, otherwise whatever else you have otherwise pick something. There is a (usually valid) assumption that the C and C++ compilers agree (and you actually have a C++ variant). With that caveat, the processes above will work on a hosted environment (only), to determine the correct bindings for symbols without ANY knowledge of the underlying OS or C/C++ compiler: there's no #if rubbish involved based on the OS. You end up with 'my_int32_t' 'my_intptr_t' etc etc, which provide the guarantee that * they alias any related symbol actually provided by the system * they're always present * they're well defined even if there is no long long or long double (or _complex etc) types * the exact integers type my_(u)int_t are provided for N = 8,16,32,64 on all machines. To ensure the N=64 case, an emulation library may be needed. It is vital that application software DOES NOT define any of the standard symbols. NEVER NEVER define intptr_t for example, even if it is undefined. It's horrible. But the above is utterly essential and it is the ONLY correct solution. Prebuild configurations can of course be used .. the algorithm above can used to prepare them when possible. If you have cross compilation situation, only half the autoconfig process works (trial compilation, but not trial execution). This kind of test: #if defined(openbsd_HOST_OS) typedef unsigned long my_uintptr_t; is almost always wrong. Integers sizes are not determined by the host OS. They're also not determined by the processor. They're also not determined by the (generic) compiler kind either. Such tests are fine for guessing what to test, but don't replace actually doing the tests. Please *don't* make the mistake of trying to use #conditional compilation in C code based on supplied macros (_WIN32 etc) to make choices. Ocaml is currently broken on XP64 for that reason: the compiler works .. all the C libraries are bugged due to the wrong assumption 'long' was the size of a pointer. [In 64 bit Windows .. it's 'long long'] Don't make assumptions .. use type names defined by Haskell with specific semantics .. then calculate them in the config script. -- John Skaller Felix, successor to C++: http://felix.sf.net From sven.panne at aedion.de Sat Sep 15 08:42:26 2007 From: sven.panne at aedion.de (Sven Panne) Date: Sat Sep 15 08:42:19 2007 Subject: compiling on solaris 9 In-Reply-To: <1189857534.10512.45.camel@rosella.wigram> References: <18154.39856.339555.957367@mozart.gslt.hum.gu.se> <200709151109.45120.sven.panne@aedion.de> <1189857534.10512.45.camel@rosella.wigram> Message-ID: <200709151442.26255.sven.panne@aedion.de> On Saturday 15 September 2007 13:58, skaller wrote: > The RIGHT way to do this is rather messy .. but there is only > one right way to do it. [...] IMHO things are not that black or white: I think we have a tradeoff between almost 100% fool-proofness (which is basically the approach you describe) and the ability to do cross-compilation (use available headers and perhaps fail/guess if nothings sensible could be found). What is "right" has to be decided on a case-by-case basis. But of course you are totally right in one respect: OS-based tests when used in a context like our example are silly and should be replaced by feature-based tests (be it "Do we have ?" or "What is the result of compiling/running blah.c?"). Cheers, S. From sven.panne at aedion.de Sat Sep 15 09:42:39 2007 From: sven.panne at aedion.de (Sven Panne) Date: Sat Sep 15 09:42:32 2007 Subject: compiling on solaris 9 In-Reply-To: <1189857534.10512.45.camel@rosella.wigram> References: <18154.39856.339555.957367@mozart.gslt.hum.gu.se> <200709151109.45120.sven.panne@aedion.de> <1189857534.10512.45.camel@rosella.wigram> Message-ID: <200709151542.39639.sven.panne@aedion.de> On Saturday 15 September 2007 13:58, skaller wrote: > [...] > 1. Measure the size (and alignment, while at it) of all the > integer types. (trial execute and run). > [...] > 4. For the ones provided, AND size_t, ptrdiff_t, check > their size (and signedness). (trial execution) Small additional note: One can determine the size and alignment *without* always resorting to trial execution. Autoconf does this by an ingenious "evaluation by compilation" technique in case of cross-compilation, see the implementation of AC_CHECK_SIZEOF and AC_CHECK_ALIGNOF. > [...] > 6. Test what the typedefs found are actually aliased to > using C++ (there is no other portable way to do this). > (Trial execution) To be honest, I don't understand that point... Cheers, S. From zunino at di.unipi.it Sat Sep 15 09:56:19 2007 From: zunino at di.unipi.it (Roberto Zunino) Date: Sat Sep 15 09:56:14 2007 Subject: FFI Bindings to Libraries using GMP In-Reply-To: References: Message-ID: <46EBE483.7010702@di.unipi.it> Benedikt Huber wrote: > (3) So when replacing GMP with the BN library of OpenSSL Maybe the following license issues with OpenSSL should be taken into account: http://www.gnome.org/~markmc/openssl-and-the-gpl.html Regards, Zun. From zunino at di.unipi.it Sat Sep 15 10:00:56 2007 From: zunino at di.unipi.it (Roberto Zunino) Date: Sat Sep 15 10:00:55 2007 Subject: About ReplacingGMPNotes Message-ID: <46EBE598.7090907@di.unipi.it> I noticed the following on http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes === The LGPL licensing situation may be worse: even though The Glasgow Haskell Compiler License is essentially a "free software" license (BSD3), according to paragraph 2 of the LGPL, GHC must be distributed under the terms of the LGPL! === This seems to be inaccurate to me. The LGPLv2.1, section 6, states that, if you statically-link, it is enough to provide the GHC source (even under BSD), o re-linkable object code. I think the newer LGPL has a similar clause. Also: === (Dynamic libraries are currently distributed only for OS X.) === This is for Haskell libs, and does not affect the GMP issues in any way, AFAICS. GMP is indeed dynamically linked in my linux system. Regards, Roberto Zunino. From skaller at users.sourceforge.net Sat Sep 15 12:59:09 2007 From: skaller at users.sourceforge.net (skaller) Date: Sat Sep 15 12:59:05 2007 Subject: compiling on solaris 9 In-Reply-To: <200709151442.26255.sven.panne@aedion.de> References: <18154.39856.339555.957367@mozart.gslt.hum.gu.se> <200709151109.45120.sven.panne@aedion.de> <1189857534.10512.45.camel@rosella.wigram> <200709151442.26255.sven.panne@aedion.de> Message-ID: <1189875549.17723.7.camel@rosella.wigram> On Sat, 2007-09-15 at 14:42 +0200, Sven Panne wrote: > On Saturday 15 September 2007 13:58, skaller wrote: > > The RIGHT way to do this is rather messy .. but there is only > > one right way to do it. [...] > > IMHO things are not that black or white: I think we have a tradeoff between > almost 100% fool-proofness (which is basically the approach you describe) and > the ability to do cross-compilation (use available headers and perhaps > fail/guess if nothings sensible could be found). What is "right" has to be > decided on a case-by-case basis. Of course. > But of course you are totally right in one respect: OS-based tests when used > in a context like our example are silly and should be replaced by > feature-based tests (be it "Do we have ?" or "What is the result of > compiling/running blah.c?"). I think the key point is that if you need say int32_t or intptr_t you must not use them, but instead use my_int_32_t or my_intptr_t size_t is required by ISO C89, C99 and C++ Standards so can be used directly. This is annoying, but if you use these in interfaces defining your own is necessary to avoid conflicts. In implementations there's more freedom .. but no point not using the 'my_' versions. In effect, this removes the 'optional' status of the symbols and creates an in-house de-facto standard you can rely on. Pity ISO didn't do that originally .. -- John Skaller Felix, successor to C++: http://felix.sf.net From skaller at users.sourceforge.net Sat Sep 15 13:17:47 2007 From: skaller at users.sourceforge.net (skaller) Date: Sat Sep 15 13:17:43 2007 Subject: compiling on solaris 9 In-Reply-To: <200709151542.39639.sven.panne@aedion.de> References: <18154.39856.339555.957367@mozart.gslt.hum.gu.se> <200709151109.45120.sven.panne@aedion.de> <1189857534.10512.45.camel@rosella.wigram> <200709151542.39639.sven.panne@aedion.de> Message-ID: <1189876667.17723.25.camel@rosella.wigram> On Sat, 2007-09-15 at 15:42 +0200, Sven Panne wrote: > On Saturday 15 September 2007 13:58, skaller wrote: > > [...] > > 1. Measure the size (and alignment, while at it) of all the > > integer types. (trial execute and run). > > [...] > > 4. For the ones provided, AND size_t, ptrdiff_t, check > > their size (and signedness). (trial execution) > > Small additional note: One can determine the size and alignment *without* > always resorting to trial execution. Autoconf does this by an > ingenious "evaluation by compilation" technique in case of cross-compilation, > see the implementation of AC_CHECK_SIZEOF and AC_CHECK_ALIGNOF. Hmm .. I guess that's possible with some kind of type checking hack? .. (I don't use autoconf but thanks for that info .. I will have a look, it would be cool to get better cross-compilation support). > > [...] > > 6. Test what the typedefs found are actually aliased to > > using C++ (there is no other portable way to do this). > > (Trial execution) > > To be honest, I don't understand that point... The point is that on most systems knowing the size of say 'intptr_t' does NOT tell you which integer type it is aliased to if there are two of them, eg: // gcc, amd64, Linux: sizeof(intptr_t) == 8 sizeof(long) == 8 sizeof(long long)== 8 sizeof(int)=4 so intptr_t is aliased to long or long long .. which one? Short of examining the header file source code, the only way to find out is in C++ with overloading: void me(long){ printf("long"); } void me(long long) { printf("long long"); } me( (intptr_t)0 ); Unfortunately EVERY system I know of has at least one more integer type available than actual integer sizes: on Win64 int and long have the same size, and of course long long must be used for the "integer the size of a pointer". This is what bit the Ocaml library.. if you need such an animal it MUST be called 'my_intptr_t', since no other name is standard than one you define yourself. Yeah, this is a REAL pain .. but look at any 'professional' C library (OpenGL, GMP, etc etc) and they all do it. BTW: in C, it usually doesn't matter which of two integers types of the same size you use .. but in C++ it does, precisely because it affects overloading. But note C99 has 'overloading' of a kind, and consider using "C++ safe" C when possible, I think it is worth ensuring 'my_intptr_t' aliases the same type as 'intptr_t' if the latter is defined. -- John Skaller Felix, successor to C++: http://felix.sf.net From brianh at metamilk.com Sun Sep 16 07:00:48 2007 From: brianh at metamilk.com (Brian Hulley) Date: Sun Sep 16 07:00:34 2007 Subject: About ReplacingGMPNotes In-Reply-To: <46EBE598.7090907@di.unipi.it> References: <46EBE598.7090907@di.unipi.it> Message-ID: <46ED0CE0.1090305@metamilk.com> Roberto Zunino wrote: > I noticed the following on > http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes > > === > The LGPL licensing situation may be worse: even though The Glasgow > Haskell Compiler License is essentially a "free software" license > (BSD3), according to paragraph 2 of the LGPL, GHC must be distributed > under the terms of the LGPL! > === > > This seems to be inaccurate to me. The LGPLv2.1, section 6, states that, > if you statically-link, it is enough to provide the GHC source (even > under BSD), o re-linkable object code. I think the newer LGPL has a > similar clause. > > Well, I think that's what the quote you quoted says: when you distribute GHC, you have to distribute it under the restrictions imposed by the LGPL, namely to provide relinkable object code or source + permission for reverse engineering. This means that if you want to incorporate GHC into a proprietary product you would have to provide re-linkable object code for that product as well as permission to reverse engineer the code. This is of course not a problem for some people but it is nevertheless a restriction that could bite if other issues prevent you being able to release your code under such conditions. It also means that if you want to develop a proprietary app for Windows, the fact that GMP is hardwired into the runtime means that everything you build, even if it doesn't need Integer, has to be released with relinkable object code + reverse engineering permissions. All I'm saying is: please don't dissuade people from the effort to replace GMP with a BSD3 alternative, since I'm sure a lot of people would **love** this to happen as soon as possible. Thanks, Brian. From llp_yyz at hotmail.com Sun Sep 16 12:59:19 2007 From: llp_yyz at hotmail.com (David Schonberger) Date: Sun Sep 16 12:59:09 2007 Subject: Newbie problem: lexical error when compiling Message-ID: Hi, I'm new to GHC and am having a problem compiling a simple test program. I recently installed ghc 6.6.1 on my Windows Vista machine. I can ghci ok. For instance, I defined the factorial function and tested it on a few values. So the interpreter seems to work fine. As a next step I created a file called hello.hs (UTF-8 encoding) containing the single line: main = putStrLn "Hello world!" I opened a windows console, navigated to the folder containing this Haskell file and typed 'ghc -o hello hello.hs' and received the following error: hello.hs:1:0 lexical error at character '\65279'. If I type 'ghc -o hello.exe hello.hs' I get the same error. Anybody know what the problem is here and how to fix it? Thanks. Regards, David -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070916/d8ea9551/attachment.htm From wferi at niif.hu Sun Sep 16 16:05:53 2007 From: wferi at niif.hu (Wagner Ferenc) Date: Sun Sep 16 16:05:43 2007 Subject: Newbie problem: lexical error when compiling In-Reply-To: (David Schonberger's message of "Sun, 16 Sep 2007 11:59:19 -0500") References: Message-ID: <87myvmwf32.fsf@szonett.ki.iif.hu> David Schonberger writes: > 'ghc -o hello hello.hs' and received the following error: hello.hs:1:0 lexical > error at character '\65279'. See http://en.wikipedia.org/wiki/Byte_Order_Mark Somehow you'll have to persuade you editor not to use the BOM, or make GHC accept it... Neither of which I can help you. -- Regards, Feri. From wferi at niif.hu Sun Sep 16 16:29:07 2007 From: wferi at niif.hu (Wagner Ferenc) Date: Sun Sep 16 16:28:57 2007 Subject: Newbie problem: lexical error when compiling In-Reply-To: <87myvmwf32.fsf@szonett.ki.iif.hu> (Wagner Ferenc's message of "Sun, 16 Sep 2007 22:05:53 +0200") References: <87myvmwf32.fsf@szonett.ki.iif.hu> Message-ID: <87ejgywe0c.fsf@szonett.ki.iif.hu> Wagner Ferenc writes: > David Schonberger writes: > >> 'ghc -o hello hello.hs' and received the following error: hello.hs:1:0 lexical >> error at character '\65279'. > > See http://en.wikipedia.org/wiki/Byte_Order_Mark > Somehow you'll have to persuade you editor not to use the BOM, or make > GHC accept it... Neither of which I can help you. Or one thing, after all: since your source is pure ASCII, don't save is as UTF-8. 7-bit ASCII and UTF-8 are compatible. -- Feri. From llp_yyz at hotmail.com Mon Sep 17 00:46:11 2007 From: llp_yyz at hotmail.com (David Schonberger) Date: Mon Sep 17 00:46:00 2007 Subject: Another compilation problem Message-ID: Another newbie question. To recap, running 6.6.1 on Vista. Fixed the other problem--lexical error, apparently a BOM added by Notepad--by getting Xemacs. Now when I type 'ghc -o hello hello.hs' at the prompt I get gcc: installation problem, cannot exec 'as': no such file ro directory. Any idea what's going on here or how to fix? Thanks. David -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070916/00b8fce5/attachment.htm From asviraspossible at gmail.com Mon Sep 17 06:48:25 2007 From: asviraspossible at gmail.com (Victor Nazarov) Date: Mon Sep 17 06:48:12 2007 Subject: STG to JavaScript translation Message-ID: Hello. I'm working on the translation of GHC's STG language to JavaScript. I've started my implementation, but I've got stuck with the STG case statements. The problem is the binder in case expression. StgCase expr livevars liverhsvars bndr srt alttype alts Operationally, I need to save continuation and evaluate expr expression, but I have no idea what to do with the bndr. It seems to me that I need to build a closure binded by bndr with the body of expr evaluate it, update it, and use it in RHSs of alternatives. But It seems that this behavior isn't intended by GHC. Can you explain briefly how GHC implements this binder and what this binder points to. Here are some notes about Dmitries last year activity and my activity: http://haskell.org/haskellwiki/STG_in_Javascript -- vir http://vir.comtv.ru/ From ndmitchell at gmail.com Mon Sep 17 07:01:02 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Sep 17 07:00:49 2007 Subject: STG to JavaScript translation In-Reply-To: References: Message-ID: <404396ef0709170401y93e9be5g7ad52784e5ebcceb@mail.gmail.com> Hi Are you aware that Dimitry is still working on ycr2js - and has made great progress. There are details available in The Monad Reader, issue 7 (http://www.haskell.org/haskellwiki/The_Monad.Reader) Thanks Neil On 9/17/07, Victor Nazarov wrote: > Hello. > I'm working on the translation of GHC's STG language to > JavaScript. I've started my implementation, but I've got stuck with > the STG case statements. The problem is the binder in case expression. > > StgCase expr livevars liverhsvars bndr srt alttype alts > > Operationally, I need to save continuation and evaluate expr > expression, but I have no idea what to do with the bndr. It seems to > me that I need to build a closure binded by bndr with the body of > expr evaluate it, update it, and use it in RHSs of alternatives. > But It seems that this behavior isn't intended by GHC. Can you explain briefly > how GHC implements this binder and what this binder points to. > > Here are some notes about Dmitries last year activity and my activity: > http://haskell.org/haskellwiki/STG_in_Javascript > > -- > vir > http://vir.comtv.ru/ > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From simonmarhaskell at gmail.com Mon Sep 17 08:03:31 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Sep 17 08:03:22 2007 Subject: compiling on solaris 9 In-Reply-To: <1189857534.10512.45.camel@rosella.wigram> References: <18154.39856.339555.957367@mozart.gslt.hum.gu.se> <200709151109.45120.sven.panne@aedion.de> <1189857534.10512.45.camel@rosella.wigram> Message-ID: <46EE6D13.2050208@gmail.com> skaller wrote: > On Sat, 2007-09-15 at 11:09 +0200, Sven Panne wrote: >> On Friday 14 September 2007 16:33, Robert Andersson wrote: >>> stdint.h seems to be unavailable on solaris 9. Looking at the >>> rts/posix/OSMem.c file we find >>> >>> /* no C99 header stdint.h on OpenBSD? */ >>> #if defined(openbsd_HOST_OS) >>> typedef unsigned long my_uintptr_t; >>> #else >>> #include >>> typedef uintptr_t my_uintptr_t; >>> #endif >> Uh, oh... Using long doesn't look very 64bit-safe (it could be int, long, long >> long, who knows?). IIRC some systems without provide at least >> , so we should perhaps use this as a fallback? >> > > The RIGHT way to do this is rather messy .. but there is only > one right way to do it. > > 1. Measure the size (and alignment, while at it) of all the > integer types. (trial execute and run). We already do this. Incedentally, the GHC RTS does provide a full complement of explicitly-sized types: Stg{Int,Word}{8,16,32,64} which are correct on all the platforms we currently support. The header that defines them currently makes some assumptions (e.g. char is 8 bits), but that's only because we're a bit lazy; it wouldn't be hard to fix it if we need to port to a platform on which it isn't true. I've just fixed OSMem.c to use StgWord (the pointer-sized integral type) instead of my_uintptr_t, I'm validating the fix now. Cheers, Simon From simonmarhaskell at gmail.com Mon Sep 17 08:05:49 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Sep 17 08:05:40 2007 Subject: Another compilation problem In-Reply-To: References: Message-ID: <46EE6D9D.4090807@gmail.com> David Schonberger wrote: > Another newbie question. To recap, running 6.6.1 on Vista. Fixed the > other problem--lexical error, apparently a BOM added by Notepad--by > getting Xemacs. Now when I type 'ghc -o hello hello.hs' at the prompt I > get /gcc: installation problem, cannot exec 'as': no such file ro > directory/. Any idea what's going on here or how to fix? Thanks. This is a bug in version 6.6.1, fixed in 6.8.1 (out shortly). See: http://hackage.haskell.org/trac/ghc/ticket/1110 Cheers, Simon From simonmarhaskell at gmail.com Mon Sep 17 08:08:03 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Sep 17 08:07:53 2007 Subject: STG to JavaScript translation In-Reply-To: References: Message-ID: <46EE6E23.4040309@gmail.com> Victor Nazarov wrote: > Hello. > I'm working on the translation of GHC's STG language to > JavaScript. I've started my implementation, but I've got stuck with > the STG case statements. The problem is the binder in case expression. > > StgCase expr livevars liverhsvars bndr srt alttype alts > > Operationally, I need to save continuation and evaluate expr > expression, but I have no idea what to do with the bndr. It seems to > me that I need to build a closure binded by bndr with the body of > expr evaluate it, update it, and use it in RHSs of alternatives. > But It seems that this behavior isn't intended by GHC. Can you explain briefly > how GHC implements this binder and what this binder points to. It should be easy to implement: the value of expr is bound to bndr within the alternatives. Cheers, Simon From simonpj at microsoft.com Mon Sep 17 08:46:41 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Sep 17 08:46:29 2007 Subject: [Haskell] Blocked STM & GC question In-Reply-To: References: Message-ID: [Redirecting to GHC Users which is the right place for questions about GHC.] Yes, the garbage collector will (well, certainly should) find and kill such threads. By "kill" I mean that they get sent an asynchronous exception of some kind (I hope the documentation says which) so that the thread has a chance to clean up rather than being forcibly terminated. I'm not quite sure where this fact should be documented -- documentation for GHC itself, or for the STM library? -- but it surely should be somewhere. Simon | -----Original Message----- | From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] | On Behalf Of Ashley Yakeley | Sent: 15 September 2007 21:39 | To: haskell@haskell.org | Subject: [Haskell] Blocked STM & GC question | | If I have a thread that's blocked on an STM retry or TChan read, and | none of its TVars are referenced elsewhere, will it get stopped and | garbage-collected? | | I have in mind a pump thread that eternally reads off a TChan and | pushes | the result to some function. If the TChan is forgotten elsewhere, will | the permanently blocked thread still sit around using up some small | amount of memory, or will it be reaped by the garbage collector? | | -- | Ashley Yakeley | Seattle WA | | _______________________________________________ | Haskell mailing list | Haskell@haskell.org | http://www.haskell.org/mailman/listinfo/haskell From simonpj at microsoft.com Mon Sep 17 12:06:26 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Sep 17 12:06:12 2007 Subject: STG to JavaScript translation In-Reply-To: References: Message-ID: case e of b { pati -> rhsi } * evaluates 'e', * binds the resulting value to 'b', * performs case analysis on the result to find which alternative to choose * binds the variables of the pattern to the components of the value This is described in the GHC commentary: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/CoreSynType does that help? Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On | Behalf Of Victor Nazarov | Sent: 17 September 2007 11:48 | To: glasgow-haskell-users@haskell.org | Subject: STG to JavaScript translation | | Hello. | I'm working on the translation of GHC's STG language to | JavaScript. I've started my implementation, but I've got stuck with | the STG case statements. The problem is the binder in case expression. | | StgCase expr livevars liverhsvars bndr srt alttype alts | | Operationally, I need to save continuation and evaluate expr | expression, but I have no idea what to do with the bndr. It seems to | me that I need to build a closure binded by bndr with the body of | expr evaluate it, update it, and use it in RHSs of alternatives. | But It seems that this behavior isn't intended by GHC. Can you explain briefly | how GHC implements this binder and what this binder points to. | | Here are some notes about Dmitries last year activity and my activity: | http://haskell.org/haskellwiki/STG_in_Javascript | | -- | vir | http://vir.comtv.ru/ | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From skaller at users.sourceforge.net Mon Sep 17 12:14:04 2007 From: skaller at users.sourceforge.net (skaller) Date: Mon Sep 17 12:13:53 2007 Subject: compiling on solaris 9 In-Reply-To: <46EE6D13.2050208@gmail.com> References: <18154.39856.339555.957367@mozart.gslt.hum.gu.se> <200709151109.45120.sven.panne@aedion.de> <1189857534.10512.45.camel@rosella.wigram> <46EE6D13.2050208@gmail.com> Message-ID: <1190045644.6058.17.camel@rosella.wigram> On Mon, 2007-09-17 at 13:03 +0100, Simon Marlow wrote: > skaller wrote: > > 1. Measure the size (and alignment, while at it) of all the > > integer types. (trial execute and run). > > We already do this. Incedentally, the GHC RTS does provide a full > complement of explicitly-sized types: Stg{Int,Word}{8,16,32,64} which are > correct on all the platforms we currently support. The header that defines > them currently makes some assumptions (e.g. char is 8 bits), but that's > only because we're a bit lazy; All good programmers are lazy -- the whole point of computers is to automate things so we can be :) The algorithm I presented (crudely) goes further. What you're doing is enough for a language that doesn't have to bind to C and/or C++. Note that doesn't mean you can't generate C/C++, it means you don't need to bind to existing libraries. If you did, you need to do more work as described. For example if there is a C lib requiring a int* argument .. there's no way to tell which one of your types, if any, is aliased to it. Of course .. this only matters in glue logic, i.e. when you're actually writing C/C++ code, not if you're generating assembler/machine code and calling the library directly using the platform ABI based on registers. When writing glue logic the end user can fix this problem with platform specific casts, but platform *independent* casts would be better (e.g. you might cast StgInt32 pointer to long* on Win64.. but that would make a corey mess if the glue logic were compiled on Linux where long is 64 bits). In Felix, this is critical, because the compiler actually generates C++ which has to run on all platforms. I actually preferred the same model you're using: (u)int{8,16,32,64} but it just didn't fly because of the almost complete dependence on source code based binding (Felix is roughly a well typed souped up macro processor .. :) BTW: .. any thoughts on 128 bit integers? I mean, registers are now 64 bits on desktops. There really should be a double precision integer type.. -- John Skaller Felix, successor to C++: http://felix.sf.net From ndmitchell at gmail.com Mon Sep 17 12:23:40 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Sep 17 12:23:26 2007 Subject: STG to JavaScript translation In-Reply-To: References: Message-ID: <404396ef0709170923s43a5f0c9j367dd9b865af974d@mail.gmail.com> Hi > case e of b { pati -> rhsi } > > * evaluates 'e', > * binds the resulting value to 'b', > * performs case analysis on the result to find which alternative to choose > * binds the variables of the pattern to the components of the value The Yhc.Core translator converts this to: let b = e in case b of { pati -> rhsi } I'm not sure if that would be a clearer form for you to work with, as it is closer to standard Haskell. Thanks Neil From sven.panne at aedion.de Mon Sep 17 12:31:03 2007 From: sven.panne at aedion.de (Sven Panne) Date: Mon Sep 17 12:30:50 2007 Subject: compiling on solaris 9 In-Reply-To: <1190045644.6058.17.camel@rosella.wigram> References: <18154.39856.339555.957367@mozart.gslt.hum.gu.se> <46EE6D13.2050208@gmail.com> <1190045644.6058.17.camel@rosella.wigram> Message-ID: <200709171831.03269.sven.panne@aedion.de> On Monday 17 September 2007 18:14, skaller wrote: > [...] The algorithm I presented (crudely) goes further. > What you're doing is enough for a language that doesn't have to > bind to C and/or C++. [...] I think this is an exaggeration, we do bind to C and do this quite successfully. As long as C has variable argument lists, void* and char* (potentially aliasing *every* data type, this is explicit in the C standards) all over the place in tons of OS calls and library entries, your fine-grained distinction is a bit academic. Look e.g. at dlopen(): It returns a void*, even for functions, which is theoretically wrong, but this doesn't stop *nices from working. ;-) As long as things like this are the case (i.e. forever), C will never have some real overloading, because that would mean invalidating almost every SW out there. C is basically a slighty typed assembler language, nothing more. Granted, the story is different for languages like C++, where type signatures are even manifest in the object files, but we do not bind to C++. Cheers, S. From flippa at flippac.org Mon Sep 17 12:37:04 2007 From: flippa at flippac.org (Philippa Cowderoy) Date: Mon Sep 17 12:37:02 2007 Subject: STG to JavaScript translation In-Reply-To: <404396ef0709170923s43a5f0c9j367dd9b865af974d@mail.gmail.com> References: <404396ef0709170923s43a5f0c9j367dd9b865af974d@mail.gmail.com> Message-ID: On Mon, 17 Sep 2007, Neil Mitchell wrote: > Hi > > > case e of b { pati -> rhsi } > > > > * evaluates 'e', > > * binds the resulting value to 'b', > > * performs case analysis on the result to find which alternative to choose > > * binds the variables of the pattern to the components of the value > > The Yhc.Core translator converts this to: > > let b = e in case b of { pati -> rhsi } > > I'm not sure if that would be a clearer form for you to work with, as > it is closer to standard Haskell. > Definitely not, let allocates. -- flippa@flippac.org There is no magic bullet. There are, however, plenty of bullets that magically home in on feet when not used in exactly the right circumstances. From brg at clearspeed.com Tue Sep 18 05:21:35 2007 From: brg at clearspeed.com (Ben Gaster) Date: Tue Sep 18 05:21:22 2007 Subject: combination not supported: Threaded/Profiling when building NDP library Message-ID: Hello Having read the papers on Nested Data Parallelism in the Haskell I wanted to play around with the de-sugared implementation in the GHC library NDP. I have built GHC from source, on RHE5, and then installed the NDP library from the tar ball. Following the build instructions in the README I got to building the library which resulted in the following error being reported: ghc-6-6.1: combination not supported: Threaded/Profiling This seems to be down to the fact that -prof and -threaded have been specified on a particular build line, although I emit not to be completely sure about this. Looking through the GHC page on its SMP support it seems to imply that the option -threaded is not needed when building code, rather when linking a parallel program, but it is unclear if this is the case when building a library such as NDP. Having scanned through the GHC source tree it seems that -prof is referenced in numerous places such that it would be a bit of a pain to have to remove these over removing the single reference to -threaded in the ndp.mk file. Thanks for any help that you can provide on this. Many Regards, Ben Benedict R. Gaster S/W Architecture Team Lead ClearSpeed Technology Plc 3110 Great Western Court Hunts Ground Road Stoke Gifford Bristol BS34 8HP -- The contents of this email and any attachments are confidential and may be legally privileged. If you have received this email in error please notify the sender immediately and refrain from copying or disclosing the contents of the email to any third party. ClearSpeed accepts no liability for any viruses which may be transmitted by this email or its attachments. ClearSpeed Technology PLC is a company registered in England under company number 05159262 whose registered office is at 3110 Great Western Court, Hunts Ground Road, Bristol BS34 8HP, UK. ClearSpeed Technology INC is a wholly owned subsidiary of ClearSpeed Technology PLC and is incorporated in the United States of America, with its principle place of business at 3031 Tisch Way, Suite 200, San Jose, CA 95128, US. Additional Company information can be found at the following: http://www.clearspeed.com/aboutus/company/index.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070918/5d3ed81f/attachment.htm From mechvel at botik.ru Tue Sep 18 06:06:00 2007 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Tue Sep 18 06:04:55 2007 Subject: 6.8.1 from CVS Message-ID: <20070918100600.GA1957@scico.botik.ru> People, please, how to download from CVS the ghc-6.8 branch ? (I need the last version of 6.8.1, the "nightly built") I do the following. set $CVSROOT to :pserver:anoncvs@glass.cse.ogi.edu:/cvs cd $HOME/ghc/cvs cvs login Logging in to :pserver:anoncvs@glass.cse.ogi.edu:2401/cvs -- its reply CVS password: -- password: cvs -- entered password Unknown host glass.cse.ogi.edu. Thank you in advance for your help, ----------------- Serge Mechveliani mechvel@botik.ru From leaveye.guo at gmail.com Tue Sep 18 08:24:06 2007 From: leaveye.guo at gmail.com (L.Guo) Date: Tue Sep 18 08:23:54 2007 Subject: About PORT? GHC Message-ID: <200709182024037652750@gmail.com> Hi glasgow-haskell-users: I have a linux PC (Host) which already have a GHC and a embed mini-linux system (Target) which I want to build a usable GHC for it. Currently, for the target system, the only way to build a program which can run on it, is compile on host using toolchain, and then copy the product of compiling to the target to execute. I want to build a GHC which can run on the target system. As a result, I may compile, GHCi or runHaskell any .hs file. I have read Building/Porting for GHC[1]. Bcuz of ./configure command cannot run on target system, I couldn't follow the tips. How can I get a GHC like that ? Regards [1] http://hackage.haskell.org/trac/ghc/wiki/Building/Porting -------------- L.Guo 2007-09-18 From b.hilken at ntlworld.com Tue Sep 18 09:51:17 2007 From: b.hilken at ntlworld.com (Barney Hilken) Date: Tue Sep 18 09:51:03 2007 Subject: unique id for data types Message-ID: <84F067A6-C25F-4D76-91EF-D9FCE3EB66C0@ntlworld.com> In order to make my records system practically useable, I need a type family > type family NameCmp n m which totally orders datatypes. More precisely, it should return one of the following types: > data NameLT = NameLT > data NameEQ = NameEQ > data NameGT = NameGT for each pair of datatypes n & m, according to whether n < m, n = m, or n > m in some global ordering. This ordering needs to be independent of the context, so it can't be affected by whatever imports there are in the current module. What I want to know is: does GHC give datatypes any global id I could use to generate such an ordering? Would fully qualified names work? Secondly (assuming it's possible) how easy would it be for me to write a patch to add NameCmp to GHC? Where in the source should I start looking? Thanks, Barney. From simonpj at microsoft.com Tue Sep 18 11:21:14 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Sep 18 11:21:00 2007 Subject: unique id for data types In-Reply-To: <84F067A6-C25F-4D76-91EF-D9FCE3EB66C0@ntlworld.com> References: <84F067A6-C25F-4D76-91EF-D9FCE3EB66C0@ntlworld.com> Message-ID: You're asking for something tricky here. | > type family NameCmp n m | | which totally orders datatypes. More precisely, it should return one | of the following types: | | > data NameLT = NameLT | > data NameEQ = NameEQ | > data NameGT = NameGT Now, whenever you declare a new data type T, you want, magically, the following instances to spring to life type instance NameCmp T Int = NameLT type instance NameCmp T Bool = NameLT ..etc etc etc... Obviously there would be way too many instances. So you really want a built-in magic type family NameCmp, which does what you want. Furthermore, the behaviour should be predicatable across compilers; so you'd need to specify just what the result should be in a compiler-independent way. Well I suppose you might do that (via lexical comparison of fully-qualified names), but it's clearly An Extension. Type-families alone get nowhere near. Simon From b.hilken at ntlworld.com Tue Sep 18 11:41:33 2007 From: b.hilken at ntlworld.com (Barney Hilken) Date: Tue Sep 18 11:41:29 2007 Subject: unique id for data types In-Reply-To: References: <84F067A6-C25F-4D76-91EF-D9FCE3EB66C0@ntlworld.com> Message-ID: <1C37D786-654D-4B86-A6C8-A7BBD190866B@ntlworld.com> Hi Simon, thanks for the response. In fact I really only need NameCmp to be defined for datatypes of the form data T = T but it's still a lot, so I was expecting to need an extension. Lexical comparison of fully qualified names is what I had in mind, but I wanted some confirmation that such things exist! I could post a GHC feature request, but unless I get someone else interested in this, it would probably just sit in Trac indefinitely. Where should I look in the ghc source if I want to add it myself? Barney. From dons at galois.com Tue Sep 18 13:57:14 2007 From: dons at galois.com (Don Stewart) Date: Tue Sep 18 13:57:09 2007 Subject: 6.8.1 from CVS In-Reply-To: <20070918100600.GA1957@scico.botik.ru> References: <20070918100600.GA1957@scico.botik.ru> Message-ID: <20070918175714.GE2429@liouville.galois.com> mechvel: > People, > > please, how to download from CVS the ghc-6.8 branch ? > (I need the last version of 6.8.1, the "nightly built") > I do the following. > > set $CVSROOT to :pserver:anoncvs@glass.cse.ogi.edu:/cvs > > cd $HOME/ghc/cvs > cvs login > Logging in to :pserver:anoncvs@glass.cse.ogi.edu:2401/cvs -- its reply > CVS password: -- > password: > cvs -- entered password > > Unknown host glass.cse.ogi.edu. > > > Thank you in advance for your help, > > ----------------- Hello Serge, In the past year or so we've stopped using CVS. You can now get all the source via the 'darcs' revision control system. Instructions for how to do this are on the GHC developers wiki: http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources Good luck, Don From olivier.boudry at gmail.com Tue Sep 18 14:26:38 2007 From: olivier.boudry at gmail.com (Olivier Boudry) Date: Tue Sep 18 14:26:20 2007 Subject: GHC 6.8.1 RC debugger only breaking on first evaluation of a function Message-ID: Hi all, I just tried the new GHCi debugger. A great new feature of GHCi 6.8.1. When debugging a function, as for example the qsort function given as an example in the "3.5 The GHCi Debugger" documentation page, the debugger will only break on first function evaluation. As haskell is pure and lazy it's probably a normal behavior (reuse last result instead of recompute) but it's not very practical in a debugger. I tried to reload (:r) but it doesn't seems to help. Is there a way to force the function to be re-evalutated without quitting, starting, loading prog and setting breakpoints again, other than making the function part of the IO monad. ;-) Thanks, Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070918/8409e1b8/attachment.htm From mnislaih at gmail.com Tue Sep 18 15:07:19 2007 From: mnislaih at gmail.com (Pepe Iborra) Date: Tue Sep 18 15:07:15 2007 Subject: GHC 6.8.1 RC debugger only breaking on first evaluation of a function In-Reply-To: References: Message-ID: Olivier, On 18/09/2007, at 20:26, Olivier Boudry wrote: > Hi all, > > I just tried the new GHCi debugger. A great new feature of GHCi 6.8.1. > > When debugging a function, as for example the qsort function given > as an example in the "3.5 The GHCi Debugger" documentation page, > the debugger will only break on first function evaluation. > > As haskell is pure and lazy it's probably a normal behavior (reuse > last result instead of recompute) but it's not very practical in a > debugger. I tried to reload (:r) but it doesn't seems to help. Is > there a way to force the function to be re-evalutated without > quitting, starting, loading prog and setting breakpoints again, > other than making the function part of the IO monad. ;-) Definitely, there should be one such way. Could you paste a ghci session demonstrating the problem? Thanks in advance, we are heavily in need of feedback and bug reports reg. the debugger. pepe From olivier.boudry at gmail.com Tue Sep 18 15:20:49 2007 From: olivier.boudry at gmail.com (Olivier Boudry) Date: Tue Sep 18 15:20:32 2007 Subject: GHC 6.8.1 RC debugger only breaking on first evaluation of a function In-Reply-To: References: Message-ID: On 9/18/07, Pepe Iborra wrote: > > Could you paste a ghci session demonstrating the problem? > > Here is a very short and simple debug session showing the problem: ======================================= *Main> :l debug68.hs [1 of 1] Compiling Main ( debug68.hs, interpreted ) Ok, modules loaded: Main. *Main> :break qsort Breakpoint 1 activated at debug68.hs:(1,0)-(3,55) *Main> main Stopped at debug68.hs:(1,0)-(3,55) _result :: [a] = _ [debug68.hs:(1,0)-(3,55)] *Main> :delete * [debug68.hs:(1,0)-(3,55)] *Main> :continue [0,1,3,4,8,11,18,23] *Main> :break qsort Breakpoint 2 activated at debug68.hs:(1,0)-(3,55) *Main> main [0,1,3,4,8,11,18,23] ======================================= The code: ======================================= qsort [] = [] qsort (a:as) = qsort left ++ [a] ++ qsort right where (left,right) = (filter (<=a) as, filter (>a) as) main = do print $ qsort [8, 4, 0, 3, 1, 23, 11, 18] ======================================= The sequence is: 1: set a breakpoint at qsort 2: evaluate function main 3: execution stopped at qsort (as expected) 4: delete all breakpoints 5: set breakpoint at qsort again 6: evaluate function main 7: that lazy haskell show the result without stopping at the breakpoint Just for fun I wrote an IO qsort function: qsortIO :: (Ord a) => [a] -> IO [a] qsortIO [] = return [] qsortIO (a:as) = do l <- qsortIO left r <- qsortIO right return $ l ++ [a] ++ r where (left, right) = (filter (<=a) as, filter (>a) as) and this one gets debugged on each run thanks to it's IO signature. Hope this helps, Best regards, Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070918/c7bb52e5/attachment.htm From stefanor at cox.net Tue Sep 18 16:45:27 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Tue Sep 18 16:45:10 2007 Subject: unique id for data types In-Reply-To: <1C37D786-654D-4B86-A6C8-A7BBD190866B@ntlworld.com> References: <84F067A6-C25F-4D76-91EF-D9FCE3EB66C0@ntlworld.com> <1C37D786-654D-4B86-A6C8-A7BBD190866B@ntlworld.com> Message-ID: <20070918204527.GA3237@localhost.localdomain> On Tue, Sep 18, 2007 at 04:41:33PM +0100, Barney Hilken wrote: > Hi Simon, thanks for the response. > > In fact I really only need NameCmp to be defined for datatypes of the form > data T = T > but it's still a lot, so I was expecting to need an extension. Lexical > comparison of fully qualified names is what I had in mind, but I wanted > some confirmation that such things exist! > > I could post a GHC feature request, but unless I get someone else > interested in this, it would probably just sit in Trac indefinitely. Where > should I look in the ghc source if I want to add it myself? As usual, Oleg solved this problem long ago. I don't remember a citation, but the gist of the procedure is: data HCons a b data HNil type family TTypeOf a :: * type instance TTypeOf Int = ...ascii code for 'I' 'n' 't' represented using HCons/HNil... ... type family Combine a b :: * type instance Combine LT a = LT type instance Combine EQ a = a type instance Combine GT a = GT type family NumCmp a b :: * type instance NumCmp HNil HNil = EQ type instance NumCmp HNil (HCons a b) = LT type instance NumCmp (HCons a b) HNil = GT type instance NumCmp (HCons a b) (HCons c d) = Combine (NumCmp a c) (NumCmp b d) type family TypeCmp a b :: * type instance TypeCmp a b = NumCmp (TTypeOf a) (TTypeOf b) The O(n) remaining instances can be automated with my Data.Derive.TTypable, if you're willing to switch back to functional dependancies. (Simon, can a TF 'wrapper' for a fundep be meaningfully done?) Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070918/5095e12a/attachment.bin From stefanor at cox.net Tue Sep 18 16:51:34 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Tue Sep 18 16:51:15 2007 Subject: GHC 6.8.1 RC debugger only breaking on first evaluation of a function In-Reply-To: References: Message-ID: <20070918205134.GB3237@localhost.localdomain> On Tue, Sep 18, 2007 at 02:26:38PM -0400, Olivier Boudry wrote: > Hi all, > > I just tried the new GHCi debugger. A great new feature of GHCi 6.8.1. > > When debugging a function, as for example the qsort function given as an > example in the "3.5 The GHCi Debugger" documentation page, the debugger will > only break on first function evaluation. > > As haskell is pure and lazy it's probably a normal behavior (reuse last > result instead of recompute) but it's not very practical in a debugger. I > tried to reload (:r) but it doesn't seems to help. Is there a way to force > the function to be re-evalutated without quitting, starting, loading prog > and setting breakpoints again, other than making the function part of the IO > monad. ;-) There is a flag to do this, and it's even In The Manual! http://haskell.org/ghc/dist/current/docs/users_guide/ghci-set.html#id313085 3.8.1. GHCi options GHCi options may be set using :set and unset using :unset. The available GHCi options are: +r Normally, any evaluation of top-level expressions (otherwise known as CAFs or Constant Applicative Forms) in loaded modules is retained between evaluations. Turning on +r causes all evaluation of top-level expressions to be discarded after each evaluation (they are still retained during a single evaluation). This option may help if the evaluated top-level expressions are consuming large amounts of space, or if you need repeatable performance measurements. ... Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070918/a2e434b9/attachment.bin From olivier.boudry at gmail.com Tue Sep 18 17:04:07 2007 From: olivier.boudry at gmail.com (Olivier Boudry) Date: Tue Sep 18 17:03:50 2007 Subject: GHC 6.8.1 RC debugger only breaking on first evaluation of a function In-Reply-To: <20070918205134.GB3237@localhost.localdomain> References: <20070918205134.GB3237@localhost.localdomain> Message-ID: On 9/18/07, Stefan O'Rear wrote: > > There is a flag to do this, and it's even In The Manual! > > > http://haskell.org/ghc/dist/current/docs/users_guide/ghci-set.html#id313085 > > 3.8.1. GHCi options > > GHCi options may be set using :set and unset using :unset. > > The available GHCi options are: > > +r > > Thanks Stefan, I just tried the ":set +r" trick. It looked really promising but it doesn't seem to work as expected. The session with the ":set +r" is exactly the same as without it: Prelude> :l debug68.hs [1 of 1] Compiling Main ( debug68.hs, interpreted ) Ok, modules loaded: Main. *Main> :set +r *Main> :b qsort Breakpoint 0 activated at debug68.hs:(1,0)-(3,55) *Main> main Stopped at debug68.hs:(1,0)-(3,55) _result :: [a] = _ [debug68.hs:(1,0)-(3,55)] *Main> :del * [debug68.hs:(1,0)-(3,55)] *Main> :cont [0,1,3,4,8,11,18,23] *Main> :b qsort Breakpoint 1 activated at debug68.hs:(1,0)-(3,55) *Main> main [0,1,3,4,8,11,18,23] Best regards, Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070918/01907519/attachment-0001.htm From b.hilken at ntlworld.com Tue Sep 18 17:10:31 2007 From: b.hilken at ntlworld.com (Barney Hilken) Date: Tue Sep 18 17:10:18 2007 Subject: unique id for data types In-Reply-To: <20070918204527.GA3237@localhost.localdomain> References: <84F067A6-C25F-4D76-91EF-D9FCE3EB66C0@ntlworld.com> <1C37D786-654D-4B86-A6C8-A7BBD190866B@ntlworld.com> <20070918204527.GA3237@localhost.localdomain> Message-ID: <871AFD6E-743E-4767-9A49-6411C0CCD638@ntlworld.com> Hi Stefan, That's great! Where can I get hold of your TTypable? It's not in Hackage and Google didn't find it. I don't know where else to look... Barney. From stefanor at cox.net Tue Sep 18 17:16:06 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Tue Sep 18 17:15:48 2007 Subject: unique id for data types In-Reply-To: <871AFD6E-743E-4767-9A49-6411C0CCD638@ntlworld.com> References: <84F067A6-C25F-4D76-91EF-D9FCE3EB66C0@ntlworld.com> <1C37D786-654D-4B86-A6C8-A7BBD190866B@ntlworld.com> <20070918204527.GA3237@localhost.localdomain> <871AFD6E-743E-4767-9A49-6411C0CCD638@ntlworld.com> Message-ID: <20070918211606.GA3432@localhost.localdomain> On Tue, Sep 18, 2007 at 10:10:31PM +0100, Barney Hilken wrote: > Hi Stefan, > > That's great! Where can I get hold of your TTypable? It's not in Hackage > and Google didn't find it. I don't know where else to look... > > Barney. Start by fixing the typo, sorry. http://www.google.com/search?q=ttypeable My deriver is #1, and the original is page 34 of #7. Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070918/ef359ee0/attachment.bin From b.hilken at ntlworld.com Tue Sep 18 18:28:34 2007 From: b.hilken at ntlworld.com (Barney Hilken) Date: Tue Sep 18 18:28:20 2007 Subject: unique id for data types In-Reply-To: <20070918211606.GA3432@localhost.localdomain> References: <84F067A6-C25F-4D76-91EF-D9FCE3EB66C0@ntlworld.com> <1C37D786-654D-4B86-A6C8-A7BBD190866B@ntlworld.com> <20070918204527.GA3237@localhost.localdomain> <871AFD6E-743E-4767-9A49-6411C0CCD638@ntlworld.com> <20070918211606.GA3432@localhost.localdomain> Message-ID: <9A0E25BB-1644-4A20-9023-B84CD19C822D@ntlworld.com> Ah! your link lead me to the HList paper, where all questions are answered... Thanks, Barney. From simonpj at microsoft.com Wed Sep 19 03:14:02 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Sep 19 03:13:45 2007 Subject: unique id for data types In-Reply-To: <9A0E25BB-1644-4A20-9023-B84CD19C822D@ntlworld.com> References: <84F067A6-C25F-4D76-91EF-D9FCE3EB66C0@ntlworld.com> <1C37D786-654D-4B86-A6C8-A7BBD190866B@ntlworld.com> <20070918204527.GA3237@localhost.localdomain> <871AFD6E-743E-4767-9A49-6411C0CCD638@ntlworld.com> <20070918211606.GA3432@localhost.localdomain> <9A0E25BB-1644-4A20-9023-B84CD19C822D@ntlworld.com> Message-ID: Well done Stefan, for reminding us that it can be done today without the magic. Still it's kind-of-inefficient to encode the name of the type constructor that way. There's a case for adding some built in constants at the type level (numbers, strings) and operators over them. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On | Behalf Of Barney Hilken | Sent: 18 September 2007 23:29 | To: Stefan O'Rear | Cc: glasgow-haskell-users@haskell.org | Subject: Re: unique id for data types | | Ah! your link lead me to the HList paper, where all questions are | answered... | | Thanks, | | Barney. | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From tomasz.zielonka at gmail.com Wed Sep 19 04:05:12 2007 From: tomasz.zielonka at gmail.com (Tomasz Zielonka) Date: Wed Sep 19 04:04:58 2007 Subject: GHC 6.8.1 RC debugger only breaking on first evaluation of a function In-Reply-To: References: Message-ID: <20070919080512.GA5021@lambda> On Tue, Sep 18, 2007 at 02:26:38PM -0400, Olivier Boudry wrote: > Hi all, > > I just tried the new GHCi debugger. A great new feature of GHCi 6.8.1. > > When debugging a function, as for example the qsort function given as an > example in the "3.5 The GHCi Debugger" documentation page, the debugger will > only break on first function evaluation. > > As haskell is pure and lazy it's probably a normal behavior (reuse last > result instead of recompute) but it's not very practical in a debugger. I > tried to reload (:r) but it doesn't seems to help. Is there a way to force > the function to be re-evalutated without quitting, starting, loading prog > and setting breakpoints again, other than making the function part of the IO > monad. ;-) If you don't find a better solution, then at least you can make it easier to perform the above sequence: $ cat ~/.ghci :def . readFile $ cat script :l Module :b 236 $ ghci GHCi, version 6.8.20070912: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :. script [1 of 1] Compiling Module ( Module.hs, interpreted ) Ok, modules loaded: Module. Breakpoint 0 activated at Module.hs:236:20-45 *Module> _ It should be quite easy to go a step further and generate breakpoint locations from markers in comments in the source file. Best regards Tomek From simonmarhaskell at gmail.com Wed Sep 19 04:14:17 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Sep 19 04:14:03 2007 Subject: GHC 6.8.1 RC debugger only breaking on first evaluation of a function In-Reply-To: References: <20070918205134.GB3237@localhost.localdomain> Message-ID: <46F0DA59.7020709@gmail.com> Olivier Boudry wrote: > On 9/18/07, *Stefan O'Rear* > > wrote: > > There is a flag to do this, and it's even In The Manual! > > http://haskell.org/ghc/dist/current/docs/users_guide/ghci-set.html#id313085 > > > 3.8.1. GHCi options > > GHCi options may be set using :set and unset using :unset. > > The available GHCi options are: > > +r > > > Thanks Stefan, > > I just tried the ":set +r" trick. It looked really promising but it > doesn't seem to work as expected. Unfortunately not: http://hackage.haskell.org/trac/ghc/ticket/1400 Cheers, Simon From mnislaih at gmail.com Wed Sep 19 04:32:23 2007 From: mnislaih at gmail.com (Pepe Iborra) Date: Wed Sep 19 04:32:20 2007 Subject: GHC 6.8.1 RC debugger only breaking on first evaluation of a function In-Reply-To: <20070919080512.GA5021@lambda> References: <20070919080512.GA5021@lambda> Message-ID: On 19/09/2007, at 10:05, Tomasz Zielonka wrote: > > If you don't find a better solution, then at least you can make it > easier to perform the above sequence: > > $ cat ~/.ghci > :def . readFile > $ cat script > :l Module > :b 236 > $ ghci > GHCi, version 6.8.20070912: http://www.haskell.org/ghc/ :? for help > Loading package base ... linking ... done. > Prelude> :. script > [1 of 1] Compiling Module ( Module.hs, interpreted ) > Ok, modules loaded: Module. > Breakpoint 0 activated at Module.hs:236:20-45 > *Module> _ You could also touch the module file to force a full reload: GHCi, version 6.7.20070907: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 1] Compiling Main ( Qsort.hs, interpreted ) Ok, modules loaded: Main. *Main> :! touch Qsort.hs *Main> :r [1 of 1] Compiling Main ( Qsort.hs, interpreted ) Ok, modules loaded: Main. *Main> Cheers pepe From ahey at iee.org Wed Sep 19 06:59:49 2007 From: ahey at iee.org (Adrian Hey) Date: Wed Sep 19 06:59:57 2007 Subject: ANNOUNCE: GHC 6.8.1 Release Candidate In-Reply-To: <46EA2F47.8030901@iee.org> References: <20070913000718.GA16083@matrix.chaos.earth.li> <46E9482A.6030207@iee.org> <20070913144827.GA29908@matrix.chaos.earth.li> <46EA2F47.8030901@iee.org> Message-ID: <46F10125.10503@iee.org> Adrian Hey wrote: > I get this error.. > > [29 of 53] Compiling Data.Tree.AVL.Join ( > Data.Tree.AVL/Data/Tree/AVL/Join.hs, dist\build/Data/Tree/AVL/Join.o ) > ghc.exe: panic! (the 'impossible' happened) > (GHC version 6.8.20070912 for i386-unknown-mingw32): > cgPanic > a{v sMX} [lid] > static binds for: > collections-0.3:Data.Tree.AVL.Join.poly_go{v rse} [gid] > collections-0.3:Data.Tree.AVL.Join.poly_$wlgo{v rsf} [gid] > collections-0.3:Data.Tree.AVL.Join.flatConcat{v ryL} [gid] > local binds for: > SRT label collections-0.3:Data.Tree.AVL.Join.$LrMelvl{v rMe}_srt > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug I still get this error with 6.8.0.20070917 release, and the haddock problem with windows still seems to be there. Also, there doesn't seem to be a runHaskell command included (not sure if that's intentional). BTW, should I be reporting bugs with the release candidate on this list or via the usual trac? Regards -- Adrian Hey From b.hilken at ntlworld.com Wed Sep 19 07:49:30 2007 From: b.hilken at ntlworld.com (Barney Hilken) Date: Wed Sep 19 07:49:17 2007 Subject: unique id for data types In-Reply-To: References: <84F067A6-C25F-4D76-91EF-D9FCE3EB66C0@ntlworld.com> <1C37D786-654D-4B86-A6C8-A7BBD190866B@ntlworld.com> <20070918204527.GA3237@localhost.localdomain> <871AFD6E-743E-4767-9A49-6411C0CCD638@ntlworld.com> <20070918211606.GA3432@localhost.localdomain> <9A0E25BB-1644-4A20-9023-B84CD19C822D@ntlworld.com> Message-ID: <08514AA3-E630-4966-82E2-5D460B222970@ntlworld.com> Ok, I'm stuck. The Oleg stuff is great, and it looks like he did everything I've done long ago, without needing type functions or associated types. But I can't use the TTypeable stuff directly because you can't convert the "relational" style of Oleg's work (using functional dependencies) to the "functional" style I'm using (using type families). Rewriting all the basics in my style is no problem (especially as I only need a limited part of it) EXCEPT Derive depends on (at least the types of) Template Haskell, and TH can't define type family or associated type instances. So I'm back where I started. Barney. From v.dijk.bas at gmail.com Wed Sep 19 08:20:19 2007 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Wed Sep 19 08:19:59 2007 Subject: Unknown option -XPatternSig used in warning Message-ID: Hello, $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.7.20070915 When loading the following incorrect program in ghci: foo (x :: a) = x ghci rightly complains: Illegal signature in pattern: a Use -XPatternSigs to permit it OK so I follow the advice and load: {-# OPTIONS_GHC -XPatternSigs #-} foo (x :: a) = x Now ghci complains: unknown flags in {-# OPTIONS #-} pragma: -XPatternSigs ??? The following works though: {-# OPTIONS_GHC -fglasgow-exts #-} foo (x :: a) = x results in: A pattern type signature cannot bind scoped type variables `a' unless the pattern has a rigid type context In the pattern: x :: a In the definition of `foo': foo (x :: a) = x Which I expect. Should I file a bug report, or is there an easy fix? regards, Bas van Dijk From simonpj at microsoft.com Wed Sep 19 08:26:59 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Sep 19 08:26:39 2007 Subject: Unknown option -XPatternSig used in warning In-Reply-To: References: Message-ID: I believe this is a known problem with OPTIONS_GHC, and will work on the command line. I think Ian is working on it. Ian? Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On | Behalf Of Bas van Dijk | Sent: 19 September 2007 13:20 | To: glasgow-haskell-users@haskell.org | Subject: Unknown option -XPatternSig used in warning | | Hello, | | $ ghc --version | The Glorious Glasgow Haskell Compilation System, version 6.7.20070915 | | | When loading the following incorrect program in ghci: | | foo (x :: a) = x | | ghci rightly complains: | | Illegal signature in pattern: a | Use -XPatternSigs to permit it | | OK so I follow the advice and load: | | {-# OPTIONS_GHC -XPatternSigs #-} | | foo (x :: a) = x | | Now ghci complains: | | unknown flags in {-# OPTIONS #-} pragma: -XPatternSigs ??? | | The following works though: | | {-# OPTIONS_GHC -fglasgow-exts #-} | | foo (x :: a) = x | | results in: | | A pattern type signature cannot bind scoped type variables `a' | unless the pattern has a rigid type context | In the pattern: x :: a | In the definition of `foo': foo (x :: a) = x | | Which I expect. | | Should I file a bug report, or is there an easy fix? | | regards, | | Bas van Dijk | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From simonpj at microsoft.com Wed Sep 19 08:28:24 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Sep 19 08:28:05 2007 Subject: ANNOUNCE: GHC 6.8.1 Release Candidate In-Reply-To: <46F10125.10503@iee.org> References: <20070913000718.GA16083@matrix.chaos.earth.li> <46E9482A.6030207@iee.org> <20070913144827.GA29908@matrix.chaos.earth.li> <46EA2F47.8030901@iee.org> <46F10125.10503@iee.org> Message-ID: | BTW, should I be reporting bugs with the release candidate on this | list or via the usual trac? Via Trac please. Can you give instructions to reproduce, please? Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On | Behalf Of Adrian Hey | Sent: 19 September 2007 12:00 | To: glasgow-haskell-users@haskell.org | Subject: Re: ANNOUNCE: GHC 6.8.1 Release Candidate | | Adrian Hey wrote: | > I get this error.. | > | > [29 of 53] Compiling Data.Tree.AVL.Join ( | > Data.Tree.AVL/Data/Tree/AVL/Join.hs, dist\build/Data/Tree/AVL/Join.o ) | > ghc.exe: panic! (the 'impossible' happened) | > (GHC version 6.8.20070912 for i386-unknown-mingw32): | > cgPanic | > a{v sMX} [lid] | > static binds for: | > collections-0.3:Data.Tree.AVL.Join.poly_go{v rse} [gid] | > collections-0.3:Data.Tree.AVL.Join.poly_$wlgo{v rsf} [gid] | >