RE: GHC 6.4 release candidates available
On 10 February 2005 17:07, Malcolm Wallace wrote: $ ghc-pkg-6.4.20050209 --show-package=base --field=import_dirs [/usr/malcolm/local/lib/ghc-6.4.20050209/imports] yet $ ghc-pkg-6.4.20050209 --show-package=base-1.0 --field=import_dirs ghc-pkg: cannot find package base-1.0 $ ghc-pkg-6.4.20050209 --list-packages /usr/malcolm/local/lib/ghc-6.4.20050209/package.conf: rts-1.0, base-1.0, haskell98-1.0, template-haskell-1.0, ... Fixed, thanks. BTW, we recommend you migrate to using the new command-line syntax for ghc-pkg at some point. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC 6.4 release candidates available
On 10 February 2005 16:12, Malcolm Wallace wrote: Simon Marlow [EMAIL PROTECTED] writes: and how do you find out what $libdir refers to...? ghc --print-libdir Cool. Will fix hmake to use it. hmake just needs to know which modules are in which packages, right? It can find that out from ghc-pkg now without having to trawl through the import directories. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC 6.4 release candidates available
On 11 February 2005 01:22, John Meacham wrote: When -fglasgow-exts is on, (#) no longer seems to be recognized. (I get a parse error.) however # works fine as an infix operator. John With -fglasgow-exts, (# is the opening unboxed-tuple bracket. This has been true in GHC for a long time (at least as far back as 5.04, I don't have any earlier builds to test with). Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bug#294481: ghci -lpthread fails
Hi Ian, What is your particular problem? Running Darcs under ghci. Juliusz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Haddock issue
Hello everyone, I was getting the following error with 'make html' : /usr/bin/haddock -t Haskell Hierarchical Libraries (template-haskell package) -h -o html Language/Haskell/TH.raw-hs Language/Haskell/TH/Lib.raw-hs Language/Haskell/TH/Ppr.raw-hs Language/Haskell/TH/PprLib.raw-hs Language/Haskell/TH/Syntax.raw-hs \ --package=template-haskell \ --dump-interface=template-haskell.haddock \ --use-index=../doc-index.html --use-contents=../index.html \ --read-interface=../base,../base/base.haddock Language/Haskell/TH/Syntax.raw-hs:156:1: parse error in doc string: [TokString monad.\n,TokString Take care: you are guaranteed the ordering of calls to ,TokIdent [runIO]] make[2]: *** [html/haddock.css] Error 1 make[1]: *** [html] Error 1 make: *** [html] Error 1 Apparently haddock needs to see I\/O instead of I/O in the line 149 of libraries/template-haskell/Language/Haskell/TH/Syntax.hs . Anyone is aware of this problem? Cheers, ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4 release candidates available
Simon Marlow [EMAIL PROTECTED] writes: $ ghc-pkg-6.4.20050209 --show-package=base-1.0 --field=import_dirs ghc-pkg: cannot find package base-1.0 BTW, we recommend you migrate to using the new command-line syntax for ghc-pkg at some point. Documented where? The GHC user guide doesn't seem to be included in the download bundle. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Bug#294481: ghci -lpthread fails
On 10 February 2005 23:35, Ian Lynagh wrote: On Thu, Feb 10, 2005 at 07:00:47PM +0100, Juliusz Chroboczek wrote: Hi Ian, What is your particular problem? Running Darcs under ghci. This seems to work for me (at least in as much as ghci loads and FastPackedString.lengthPS (FastPackedString.packString Foo) says 3): rm -rf .libs rm *ghcidarcsfoo* touch ghcidarcsfoo.c libtool --mode=compile gcc -g -O -c ghcidarcsfoo.c libtool --mode=link gcc -g -O -o libghcidarcsfoo.la ghcidarcsfoo.lo -lpthread -rpath /usr/lib libtool --mode=install cp libghcidarcsfoo.la `pwd`/libghcidarcsfoo.la libtool --finish /usr/lib ghci -cpp -package unix -package parsec -O -funbox-strict-fields -Werror -package util -I. -DHAVE_CURSES -optl-lcurses -optl-lz -L`pwd` -optl-lghcidarcsfoo darcs.lhs compat.o fpstring.o zlib_helper.o c_context.o Is there a problem with this? Could something along these lines be done when -lfoo (as opposed to -optl-lfoo, which for consistency should probably be left alone) is given on the ghci command-line? I'm no library expert, so there may be a cleaner/simpler/more portable equivalent to the above. I'm not that familiar with libtool, but I guess what you're doing here is creating a dummy shared library which is linked against -lpthread, and linking that into GHCi? I don't see any reason why we couldn't automate the process, except that getting all the fiddly details right would probably be a nightmare. And would you require libtool to be installed? What about other platforms - Mac OS X? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC 6.4 release candidates available
On 11 February 2005 11:07, Malcolm Wallace wrote: Simon Marlow [EMAIL PROTECTED] writes: $ ghc-pkg-6.4.20050209 --show-package=base-1.0 --field=import_dirs ghc-pkg: cannot find package base-1.0 BTW, we recommend you migrate to using the new command-line syntax for ghc-pkg at some point. Documented where? The GHC user guide doesn't seem to be included in the download bundle. I'm having some trouble with the XML docbook formatting tools right now. If you have a source tree, 'make html' should work in ghc/docs/users_guide. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Restricted Types and Infinite Loops
Simon You've found an interesting case. First, you are skating on thin ice here. GHC's ability to build recursive dictionaries is quite experimental, and you are relying on it completely. But you're right: it should work. I can see why it isn't but I have not got it clear enough in my head to know the best way to fix it. Still less do I have a formal story about what should type-check (without loops) and what should not. So this is going to continue to fail in 6.4, but it's on my list to look at. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-users- | [EMAIL PROTECTED] On Behalf Of Simon David Foster | Sent: 27 January 2005 14:11 | To: GHC Users | Subject: Restricted Types and Infinite Loops | | Hi, | | (I've attached the full code for this problem) | | First I'll explain the problem description, I have two class ClassA and | ClassB, the former has two parameters and the latter has one. The second | parameter of ClassA is constrained by ClassB. | | class ClassB a where | class ClassB b = ClassA a b where | | Because I wish to effectively pass the context of ClassA around, I need | to create a pair of dictionary types (as in Restricted Data Types in | Haskell, Hughes 99), one to represent ClassA (DictClassA) and one to | represent ClassB (DictClassB). DictClassA also contains a term of type | DictClassB since ClassA is a subclass of ClassB. I should then be able | to call all the functions of ClassB via the appropriate term of | DictClassA, like so (assuming we want to use func2); | | *Test func2D (classBD (dict::DictClassA Int String)) hello | bye | | So far so good, but now suppose I want Class A to have the further | constraint | | class (Data (DictClassA a) b, ClassB b) = ClassA a b where | | (so as to make ClassA a subclass of Data) | | If we now try and do | | *Test func2D (classBD (dict::DictClassA Int String)) hello | | We go into an infinite loop. Why? The expression still type-checks ok | and I can't see what it is trying to do. All the functions of ClassA can | be accessed ok, but not ClassB. | | *Test funcD ((dict::DictClassA Int String)) hello 5 | hello | | Is it something to do with ClassB only having one parameter? | | I'm running GHC 20041231. | | -Si. | | -- | Simon David Foster [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4 release candidates available
Simon Marlow [EMAIL PROTECTED] writes:
I'm having some trouble with the XML docbook formatting tools right now.
If you have a source tree, 'make html' should work in
ghc/docs/users_guide.
Sadly, not.
$ cvs checkout ...
$ cd fptools
$ autoreconf
$ ./configure
[]
checking for xmllint... /usr/bin/xmllint
checking for DocBook DTD... ok
checking for xsltproc... /usr/bin/xsltproc
checking for DocBook XSL stylesheet directory... ./configure: line 4517:
1746 Segmentation fault $XsltprocCmd ${fp_var}/html/docbook.xsl
conftest.xml /dev/null 21
./configure: line 4517: 1799 Segmentation fault $XsltprocCmd
${fp_var}/html/docbook.xsl conftest.xml /dev/null 21
no
[]
Regards,
Malcolm
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bug#294481: ghci -lpthread fails
On Fri, Feb 11, 2005 at 11:27:21AM -, Simon Marlow wrote: On 10 February 2005 23:35, Ian Lynagh wrote: I'm no library expert, so there may be a cleaner/simpler/more portable equivalent to the above. I'm not that familiar with libtool, but I guess what you're doing here is creating a dummy shared library which is linked against -lpthread, and linking that into GHCi? Yup. I don't see any reason why we couldn't automate the process, except that getting all the fiddly details right would probably be a nightmare. Like I say, I'm no expert either :-( And would you require libtool to be installed? What about other platforms - Mac OS X? If the necessary bits aren't available then you can fall back to acting like -optl-foo and are no worse off than currently. I think libtool is supposed to take care of the portability side for you, so hopefully lots of special casing won't be necessary. I don't know how well that works in practice, though. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4 release candidates available [GHCi reloads incorrectly]
If I have two simple modules, Module1 and Module2 like this; module Module1 where f = hello module Module2 where import Module1 I load up Module2 in GHCi, and I can evaluate f in Module1; Compiling Module1 ( ./Module1.hs, interpreted ) Compiling Module2 ( Module2.hs, interpreted ) Ok, modules loaded: Module2, Module1. *Module2 f hello Now I change Module1 to module Module1 where f = hello2 and reload; this happens in the GHC 6.4 RC: *Module2 :r Compiling Module1 ( ./Module1.hs, interpreted ) Skipping Module2 ( Module2.hs, interpreted ) Ok, modules loaded: Module2, Module1. Prelude Module2 And I can no longer get at anything in Module1 (this is generally true of any imported modules), only stuff in Module2. Instead I have to do a full reload. In GHC 6.2, if you did this it reloaded both modules and everything was fine, so I'm guessing this is incorrect behaviour. -Si. -- Simon David Foster [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC 6.4 release candidates available
On 11 February 2005 13:17, Malcolm Wallace wrote:
Simon Marlow [EMAIL PROTECTED] writes:
I'm having some trouble with the XML docbook formatting tools right
now. If you have a source tree, 'make html' should work in
ghc/docs/users_guide.
Sadly, not.
$ cvs checkout ...
$ cd fptools
$ autoreconf
$ ./configure
[]
checking for xmllint... /usr/bin/xmllint
checking for DocBook DTD... ok
checking for xsltproc... /usr/bin/xsltproc
checking for DocBook XSL stylesheet directory... ./configure:
line 4517: 1746 Segmentation fault $XsltprocCmd
${fp_var}/html/docbook.xsl conftest.xml /dev/null 21
./configure: line 4517: 1799 Segmentation fault
$XsltprocCmd ${fp_var}/html/docbook.xsl conftest.xml /dev/null 21
no []
Wow, your system's in even worse shape than mine! You might try
updating xsltproc to a newer vesrion.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4 release candidates available [GHCi loads incorrectly]
And one other niggle, if you try and load a module which doesn't exist with :m, it doesn't load it, but it still appends it to command-line; Prelude :m + My.Module Top level: Failed to load interface for `My.Module': Could not find module `My.Module': use -v to see a list of the files searched for Prelude My.Module -Si. On Fri, 2005-02-11 at 13:50 +, Simon David Foster wrote: If I have two simple modules, Module1 and Module2 like this; module Module1 where f = hello module Module2 where import Module1 I load up Module2 in GHCi, and I can evaluate f in Module1; Compiling Module1 ( ./Module1.hs, interpreted ) Compiling Module2 ( Module2.hs, interpreted ) Ok, modules loaded: Module2, Module1. *Module2 f hello Now I change Module1 to module Module1 where f = hello2 and reload; this happens in the GHC 6.4 RC: *Module2 :r Compiling Module1 ( ./Module1.hs, interpreted ) Skipping Module2 ( Module2.hs, interpreted ) Ok, modules loaded: Module2, Module1. Prelude Module2 And I can no longer get at anything in Module1 (this is generally true of any imported modules), only stuff in Module2. Instead I have to do a full reload. In GHC 6.2, if you did this it reloaded both modules and everything was fine, so I'm guessing this is incorrect behaviour. -Si. -- Simon David Foster [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4 release candidates available
For commands other than register, ghc-pkg --user operates on both the user and global package databases, whereas the the docs and online help says it operates on the user database only. Also, ghc-pkg list queries only the system database (unless --user is given), but the the docs say it queries both. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4 release candidates available
Please test if you're able to, and give us feedback. It looks like GADTs (or something else new) conflict with normal Haskell'98 type inference. The following example used to compile just fine with all previous versions of ghc and nhc98. $ ghc-6.4.20050210 -package lang-c -o Parse.o Parse.hs Parse.hs:209:4: Couldn't match the rigid variable `a' against the rigid variable `a1' `a' is bound by the type signature for `parseValdef' `a1' is bound by the type signature for `parseWhere' Expected type: Parser (Decls TokenId) [PosToken] a1 Inferred type: Parser (Decls TokenId) [(Pos, Lex, Lexical.LexState, [LexPre.PosTokenPre])]a In the expression: lit L_where) `revChk` lcurl) `revChk` parseDecls) `chk` rcurl) `orelse` (parse (DeclsParse [])) In the definition of `parseWhere': parseWhere = lit L_where) `revChk` lcurl) `revChk` parseDecls) `chk` rcurl) `orelse` (parse (DeclsParse [])) The quoted expressions look a little bit hairy, but if you examine the explicit type signatures in question, it is very clear that there should be no error here. To reproduce the bug, just build the nhc98 compiler proper. $ wget ftp://ftp.cs.york.ac.uk/pub/haskell/nhc98/nhc98src-1.17.tar.gz $ tar zxf nhc98src-1.17.tar.gz $ ./configure --buildwith=ghc-6.4.20050210 $ make basic Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Haddock chokes on '#'
Processing the file module Test where -- |Haddock chokes on this. (#):: a - (a - b) - b a # f = f a with Haddock 0.6 gives an error: | haddock test.hs | test.hs:5:3: Parse error Since GHC deals with this code just fine, I suppose this is a bug. Peter ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4 release candidates available
So my hack to get ghc working on x86-64 is a bit trickier with the new version, all that is needed is to make sure -m32 is passed to gcc, as, and ld and everything works great with the i386 build of ghc. for earlier versions, I set extra_ghc_opts = [-optc-m32, -optl-m32, -opta-m32] for base in package.conf. However in 6.4 there no longer seems to be an extra_ghc_opts in package.conf. I was able to add -m32 to extraCcOpts and extraLdOpts, but there does not appear to be an extraAsOpts. perhaps this is an oversight? John It would be nice if ghc always passed -m32 when targeted to i386-*-* since it does not hurt when you are actually on a 32 bit system but would save us x86-64 people some hassle. -- John Meacham - repetae.netjohn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
