- Glasgow-haskell-users

RE: GHC 6.4 release candidates available [GHCi reloads incorrectly]
by Simon Marlow 14 Feb '05

14 Feb '05

On 11 February 2005 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> Thanks, good bug. Now fixed. Cheers, Simon

1 0

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

14 Feb '05

On 12 February 2005 08:13, John Meacham wrote: > System.Posix.Types.CClock and > System.Posix.Types.CTime > seem to be missing instances for 'Integral' as they used to have. Yes, these aren't guaranteed to be integral types according to the C99 spec. See revision 1.22 of libraries/base/Foreign/C/Types.hs for details. Cheers, Simon

1 0

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

14 Feb '05

On 12 February 2005 07:32, John Meacham wrote: > On Fri, Feb 11, 2005 at 10:49:56AM -0000, Simon Marlow wrote: >> 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? > > Ah, changing some code to use the hierarchical libraries and getting > rid of my other package imports seems to have fixed things. cool. > Does this mean I have been getting silent brokeness in the past due > to the nameing conflict? Probably not, but you've been walking on thin ice. Cheers, Simon

1 0

Problem when compiling ghc-6.4 with itself
by Alain Cremieux 12 Feb '05

12 Feb '05

When compiling ghc-6.4.20050211 with itself, I get : /usr/local/bin/ghc -M -optdep-f -optdep.depend -osuf o -H16m -O -i../../lib/compat -Rghc-timing -Wall Main.hs ../../lib/compat/Compat/RawSystem.hs:19: ../../includes/ghcconfig.h: No such file or directory I verified the version of ghc : /usr/local/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 6.4.20050211 Alain

1 0

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 11 Feb '05

11 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