February 2005 - Glasgow-haskell-users

RE: GHC as a package
by Simon Marlow 12 Feb '05

12 Feb '05

On 08 February 2005 12:43, Lennart Kolmodin wrote: > I'm working on an IDE for Haskell, written in Haskell. > Currently, I'm looking for a way to parse .hs-files for a module > browser and I recall that Simon Marlow was going to release GHC as a > package "soon". > We could also use that package to compile source code without > invoking ghc as a separate process. > > What is the status of the package and where can I get it? > I can't find it in the CVS or in any of the snapshots. You can currently compile GHC as a package, but the part that is missing is a well-thought-out API to access the facilities of GHC. We'd like to do this, and indeed it will probably emerge as part of the work we're doing on a Visual Studio plug-in, but currently other things have higher priority. We plan to get back to work on Visual Studio during March. To compile GHC as a package, get a recent GHC source tree and set 'BuildPackageGHC=YES' in your mk/build.mk. You should also set $(GHC_PKG) to point to your ghc-pkg command. Then build ghc as normal, and in ghc/compiler say 'make install-inplace-pkg' to register the package (this won't do any actual installation, just register the package with your installed GHC). Cheers, Simon

2 1

RE: GHC 6.4 release candidates available
by Simon Marlow 12 Feb '05

12 Feb '05

On 11 February 2005 02:19, John Meacham wrote: > There seems to have been a change in how packages are found which is > biting me. > > I have a module called PackedString, which used to be fine, as ghc's > packedstring was called Data.PackedString. however with ghc 6.4 I am > getting the error: > > Atom.hs:3:0: > Failed to load interface for `PackedString': > Could not find module `PackedString': > it is a member of package lang-1.0, which is hidden > > If not using -package foo doesn't allow you to reuse the names in foo > then I must wonder what the point is of hiding the package in the > first place :) GHC has warned you about a module clash, for which you should be grateful :-) This could have lead to strange link-time errors, or even crashes, if you had used a library module which depended on the other PackedString. The golden rule is (from the new section on packages in the GHC User's Guide): There must be no overlaps in the modules provided by all of the exposed packages, and the packages they depend on, and so on. PackedString (not Data.PackedString) is indeed a member of the lang-1.0 package. This normally wouldn't be a problem, because lang is hiden. However, if lang is a dependency of some other exposed package, then it becomes part of your program, and hence its modules cannot overlap with any others. What other packages are you using? Cheers, Simon

2 1

Haddock chokes on '#'
by Peter Simons 11 Feb '05

11 Feb '05

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

1 0

RE: GHC 6.4 release candidates available
by Simon Marlow 11 Feb '05

11 Feb '05

On 11 February 2005 13:17, Malcolm Wallace wrote: > "Simon Marlow" <simonmar(a)microsoft.com> 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 2>&1 > ./configure: line 4517: 1799 Segmentation fault > $XsltprocCmd ${fp_var}/html/docbook.xsl conftest.xml >/dev/null 2>&1 > no [....] Wow, your system's in even worse shape than mine! You might try updating xsltproc to a newer vesrion. Cheers, Simon

1 0

RE: Bug#294481: ghci -lpthread fails
by Simon Marlow 11 Feb '05

11 Feb '05

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

2 1

RE: GHC 6.4 release candidates available
by Simon Marlow 11 Feb '05

11 Feb '05

On 11 February 2005 11:07, Malcolm Wallace wrote: > "Simon Marlow" <simonmar(a)microsoft.com> 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

2 1

RE: GHC 6.4 release candidates available
by Simon Marlow 11 Feb '05

11 Feb '05

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

2 1

RE: Unregistering a package
by Simon Marlow 11 Feb '05

11 Feb '05

On 10 February 2005 22:29, Peter Simons wrote: > Simon Marlow writes: > > > The general syntax of package ids is: > > > pkgid ::= pkg ('-' version)? > > pkg ::= (alphanum|'-')+ > > version ::= (digit+) ('.' digit+)* ('-' alphanum+)* > > Thanks. I gave my package the version "hsdns-0.0-2005-02-10" > and that fixed the problem. You should be aware that the version tags (i.e. -2005-02-10) are ignored by Cabal when determining whether dependencies are satisfied. That is, the ordering on versions ignores the tags. > > Perhaps we should change the syntax of package ids > > though? > > In my humble opinion, GHC shouldn't try to guess what > version identifiers mean; I would treat them as a literal > strings without any parsing. But that's probably just me. Mostly they are ignored, only parsed. Cabal is the only part of the systen that actually imposes a meaning, in terms of an ordering, on versions. Cheers, Simon

1 0

RE: GHC 6.4 release candidates available
by Simon Marlow 11 Feb '05

11 Feb '05

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

1 0

RE: GHC 6.4 release candidates available
by Simon Marlow 11 Feb '05

11 Feb '05

On 10 February 2005 16:12, Malcolm Wallace wrote: > "Simon Marlow" <simonmar(a)microsoft.com> 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

1 0