From ross at soi.city.ac.uk Sun Sep 3 07:26:47 2006 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sun Sep 3 07:14:24 2006 Subject: cvs commit: hugs98/tests/rts enum.output Message-ID: <200609031126.k83BQlTo012035@monk.galois.com> ross 2006/09/03 04:26:47 PDT Removed files: tests/rts enum.output Log: remove used file From ross at soi.city.ac.uk Tue Sep 5 06:04:28 2006 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Sep 5 05:51:57 2006 Subject: cvs commit: hugs98 Makefile RPM.mk hugs98/libraries/tools convert_libraries Message-ID: <200609051004.k85A4Sma020533@monk.galois.com> ross 2006/09/05 03:04:28 PDT Modified files: . Makefile RPM.mk libraries/tools convert_libraries Log: drop HaXml (no longer builds) Revision Changes Path 1.80 +1 -3 hugs98/Makefile 1.53 +0 -1 hugs98/RPM.mk 1.44 +1 -1 hugs98/libraries/tools/convert_libraries From Malcolm.Wallace at cs.york.ac.uk Tue Sep 5 06:35:03 2006 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Sep 5 06:26:54 2006 Subject: cvs commit: hugs98 Makefile RPM.mk hugs98/libraries/tools convert_libraries In-Reply-To: <200609051004.k85A4Sma020533@monk.galois.com> References: <200609051004.k85A4Sma020533@monk.galois.com> Message-ID: <20060905113503.108886d8.Malcolm.Wallace@cs.york.ac.uk> Ross Paterson wrote: > Modified files: > . Makefile RPM.mk > libraries/tools convert_libraries > Log: > drop HaXml (no longer builds) In what way does HaXml fail to build for Hugs? Is it easily fixable? Regards, Malcolm From ross at soi.city.ac.uk Tue Sep 5 06:58:31 2006 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Sep 5 06:46:02 2006 Subject: cvs commit: hugs98 Makefile RPM.mk hugs98/libraries/tools convert_libraries In-Reply-To: <20060905113503.108886d8.Malcolm.Wallace@cs.york.ac.uk> References: <200609051004.k85A4Sma020533@monk.galois.com> <20060905113503.108886d8.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <20060905105831.GA10006@soi.city.ac.uk> On Tue, Sep 05, 2006 at 11:35:03AM +0100, Malcolm Wallace wrote: > Ross Paterson wrote: > > > Modified files: > > . Makefile RPM.mk > > libraries/tools convert_libraries > > Log: > > drop HaXml (no longer builds) > > In what way does HaXml fail to build for Hugs? Is it easily fixable? There's the use of the cpp symbol VERSION, fixable by adding cc-options: -DVERSION="1.16" or putting the definition in an include file, and there's the famous Data.FiniteMap. From Malcolm.Wallace at cs.york.ac.uk Tue Sep 5 07:12:00 2006 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Sep 5 07:02:19 2006 Subject: cvs commit: hugs98 Makefile RPM.mk hugs98/libraries/tools convert_libraries In-Reply-To: <20060905105831.GA10006@soi.city.ac.uk> References: <200609051004.k85A4Sma020533@monk.galois.com> <20060905113503.108886d8.Malcolm.Wallace@cs.york.ac.uk> <20060905105831.GA10006@soi.city.ac.uk> Message-ID: <20060905121200.1ff93533.Malcolm.Wallace@cs.york.ac.uk> > > > HaXml (no longer builds) > > > > In what way does HaXml fail to build for Hugs? Is it easily > > fixable? > > ... and there's the famous Data.FiniteMap. So does anyone have any objections if I go ahead and commit the replacement (compatibility) implementation of Data.FiniteMap to the main repository for packages/base? Regards, Malcolm From ross at soi.city.ac.uk Tue Sep 5 07:19:01 2006 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Sep 5 07:06:42 2006 Subject: cvs commit: hugs98 Makefile RPM.mk hugs98/libraries/tools convert_libraries In-Reply-To: <20060905121200.1ff93533.Malcolm.Wallace@cs.york.ac.uk> References: <200609051004.k85A4Sma020533@monk.galois.com> <20060905113503.108886d8.Malcolm.Wallace@cs.york.ac.uk> <20060905105831.GA10006@soi.city.ac.uk> <20060905121200.1ff93533.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <20060905111901.GB10006@soi.city.ac.uk> On Tue, Sep 05, 2006 at 12:12:00PM +0100, Malcolm Wallace wrote: > > > > HaXml (no longer builds) > > > > > > In what way does HaXml fail to build for Hugs? Is it easily > > > fixable? > > > > ... and there's the famous Data.FiniteMap. > > So does anyone have any objections if I go ahead and commit the > replacement (compatibility) implementation of Data.FiniteMap to the main > repository for packages/base? I'd rather see HaXml updated to use Data.Map, perhaps with a compatibility layer for older GHCs. From ross at soi.city.ac.uk Tue Sep 5 08:35:13 2006 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Sep 5 08:22:51 2006 Subject: cvs commit: hugs98 Makefile RPM.mk hugs98/libraries/tools convert_libraries In-Reply-To: <1157458891.5127.9.camel@localhost> References: <200609051004.k85A4Sma020533@monk.galois.com> <20060905113503.108886d8.Malcolm.Wallace@cs.york.ac.uk> <20060905105831.GA10006@soi.city.ac.uk> <20060905121200.1ff93533.Malcolm.Wallace@cs.york.ac.uk> <20060905111901.GB10006@soi.city.ac.uk> <1157458891.5127.9.camel@localhost> Message-ID: <20060905123512.GA10633@soi.city.ac.uk> On Tue, Sep 05, 2006 at 02:21:31PM +0200, Duncan Coutts wrote: > On Tue, 2006-09-05 at 12:19 +0100, Ross Paterson wrote: > > On Tue, Sep 05, 2006 at 12:12:00PM +0100, Malcolm Wallace wrote: > > > So does anyone have any objections if I go ahead and commit the > > > replacement (compatibility) implementation of Data.FiniteMap to the main > > > repository for packages/base? > > > > I'd rather see HaXml updated to use Data.Map, perhaps with a > > compatibility layer for older GHCs. > > Using a compatibility layer is not that easy at the moment. It's not that hard. Cabal itself does it for several packages, including Data.Map. From Malcolm.Wallace at cs.york.ac.uk Tue Sep 5 09:13:33 2006 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Sep 5 09:01:50 2006 Subject: FiniteMap In-Reply-To: <20060905111901.GB10006@soi.city.ac.uk> References: <200609051004.k85A4Sma020533@monk.galois.com> <20060905113503.108886d8.Malcolm.Wallace@cs.york.ac.uk> <20060905105831.GA10006@soi.city.ac.uk> <20060905121200.1ff93533.Malcolm.Wallace@cs.york.ac.uk> <20060905111901.GB10006@soi.city.ac.uk> Message-ID: <20060905141333.5bf57766.Malcolm.Wallace@cs.york.ac.uk> > > So does anyone have any objections if I go ahead and commit the > > replacement (compatibility) implementation of Data.FiniteMap to the > > main repository for packages/base? > > I'd rather see HaXml updated to use Data.Map, perhaps with a > compatibility layer for older GHCs. OK, I've looked more closely at all uses of Data.FiniteMap in HaXml, and they are far from critical, so have reverted them to using simpler lookup structures. As far as I can tell, none of my other software now depends on FiniteMap either, so I withdraw the threat to resuscitate it. (Sorry Duncan!) Regards, Malcolm From ross at soi.city.ac.uk Tue Sep 5 09:35:11 2006 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Sep 5 09:22:50 2006 Subject: FiniteMap In-Reply-To: <20060905141333.5bf57766.Malcolm.Wallace@cs.york.ac.uk> References: <200609051004.k85A4Sma020533@monk.galois.com> <20060905113503.108886d8.Malcolm.Wallace@cs.york.ac.uk> <20060905105831.GA10006@soi.city.ac.uk> <20060905121200.1ff93533.Malcolm.Wallace@cs.york.ac.uk> <20060905111901.GB10006@soi.city.ac.uk> <20060905141333.5bf57766.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <20060905133510.GB10633@soi.city.ac.uk> On Tue, Sep 05, 2006 at 02:13:33PM +0100, Malcolm Wallace wrote: > > > So does anyone have any objections if I go ahead and commit the > > > replacement (compatibility) implementation of Data.FiniteMap to the > > > main repository for packages/base? > > > > I'd rather see HaXml updated to use Data.Map, perhaps with a > > compatibility layer for older GHCs. > > OK, I've looked more closely at all uses of Data.FiniteMap in HaXml, and > they are far from critical, so have reverted them to using simpler > lookup structures. Why not do it the other way round: #if __GLASGOW_HASKELL__ >= 604 || __NHC__ >= 118 || defined(__HUGS__) -- Data.Map, if it is available import Prelude hiding (lookup) import Data.Map (Map, lookup, fromList) #else -- otherwise, a very simple and inefficient implementation of a finite map type Map k a = [(k,a)] fromList :: [(k,a)] -> Map k a fromList = id -- Prelude.lookup :: k -> Map k a -> Maybe a #endif From Malcolm.Wallace at cs.york.ac.uk Tue Sep 5 09:59:21 2006 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Sep 5 09:46:56 2006 Subject: FiniteMap In-Reply-To: <20060905133510.GB10633@soi.city.ac.uk> References: <200609051004.k85A4Sma020533@monk.galois.com> <20060905113503.108886d8.Malcolm.Wallace@cs.york.ac.uk> <20060905105831.GA10006@soi.city.ac.uk> <20060905121200.1ff93533.Malcolm.Wallace@cs.york.ac.uk> <20060905111901.GB10006@soi.city.ac.uk> <20060905141333.5bf57766.Malcolm.Wallace@cs.york.ac.uk> <20060905133510.GB10633@soi.city.ac.uk> Message-ID: <20060905145921.7b04879e.Malcolm.Wallace@cs.york.ac.uk> Ross Paterson wrote: > Why not do it the other way round: > > #if __GLASGOW_HASKELL__ >= 604 || __NHC__ >= 118 || defined(__HUGS__) > -- Data.Map, if it is available > import Prelude hiding (lookup) > import Data.Map (Map, lookup, fromList) > #else Fair enough. Like I say, these lookup structures are not critical. For many simple XML documents, ordinary lists might actually be faster for lookups, despite their worse asymptotic complexity... Does this mean you can re-instate HaXml as a package built by default with Hugs? Regards, Malcolm From ross at soi.city.ac.uk Tue Sep 5 13:56:27 2006 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Sep 5 13:43:56 2006 Subject: cvs commit: hugs98 Makefile RPM.mk hugs98/libraries/tools convert_libraries Message-ID: <200609051756.k85HuRei029508@monk.galois.com> ross 2006/09/05 10:56:27 PDT Modified files: . Makefile RPM.mk libraries/tools convert_libraries Log: reinstate HaXml Revision Changes Path 1.81 +3 -1 hugs98/Makefile 1.54 +1 -0 hugs98/RPM.mk 1.45 +1 -1 hugs98/libraries/tools/convert_libraries From ross at soi.city.ac.uk Tue Sep 5 18:39:20 2006 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Sep 5 18:26:49 2006 Subject: FiniteMap In-Reply-To: <20060905145921.7b04879e.Malcolm.Wallace@cs.york.ac.uk> References: <200609051004.k85A4Sma020533@monk.galois.com> <20060905113503.108886d8.Malcolm.Wallace@cs.york.ac.uk> <20060905105831.GA10006@soi.city.ac.uk> <20060905121200.1ff93533.Malcolm.Wallace@cs.york.ac.uk> <20060905111901.GB10006@soi.city.ac.uk> <20060905141333.5bf57766.Malcolm.Wallace@cs.york.ac.uk> <20060905133510.GB10633@soi.city.ac.uk> <20060905145921.7b04879e.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <20060905223920.GB25881@soi.city.ac.uk> On Tue, Sep 05, 2006 at 02:59:21PM +0100, Malcolm Wallace wrote: > Fair enough. Like I say, these lookup structures are not critical. For > many simple XML documents, ordinary lists might actually be faster for > lookups, despite their worse asymptotic complexity... > > Does this mean you can re-instate HaXml as a package built by default > with Hugs? Done, though only in the kitchen sink version. Since the May 2006 release the minimal version has had only the base, haskell98 and Cabal packages. From ross at soi.city.ac.uk Tue Sep 5 18:43:44 2006 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Sep 5 18:31:12 2006 Subject: cvs commit: hugs98/src printer.c hugs98/docs/users_guide miscellaneous.xml options.xml hugs98/tests/rts infix.output print1.output print2.output Message-ID: <200609052243.k85Mhihl002405@monk.galois.com> ross 2006/09/05 15:43:44 PDT Modified files: src printer.c docs/users_guide miscellaneous.xml options.xml tests/rts infix.output print1.output print2.output Log: Make the built-in printer less verbose: * don't qualify with class and type names * hide dictionary arguments * hide fromInt/fromDouble applied to constants The main effect is that pattern match exceptions become more readable, though they still show things like _SEL. Define VERBOSE_PRINTER in printer.c to get the old behaviour. Revision Changes Path 1.15 +50 -11 hugs98/src/printer.c 1.21 +14 -0 hugs98/docs/users_guide/miscellaneous.xml 1.25 +1 -1 hugs98/docs/users_guide/options.xml 1.6 +1 -1 hugs98/tests/rts/infix.output 1.6 +6 -6 hugs98/tests/rts/print1.output 1.6 +6 -6 hugs98/tests/rts/print2.output From ndmitchell at gmail.com Thu Sep 7 09:03:51 2006 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Sep 7 08:51:12 2006 Subject: cvs commit: hugs98/src input.c Message-ID: <200609071303.k87D3p5v007354@monk.galois.com> neil 2006/09/07 06:03:51 PDT Modified files: src input.c Log: Let WinHugs notice $$ repeat characters. Fixes bug #29 Revision Changes Path 1.90 +6 -5 hugs98/src/input.c From brianlsmith at gmail.com Sat Sep 9 01:51:15 2006 From: brianlsmith at gmail.com (Brian Smith) Date: Sat Sep 9 01:38:31 2006 Subject: Fwd: Unexpected signal when buliding hugs98 CVS HEAD In-Reply-To: References: Message-ID: The current CVS HEAD fails to bulid--there is an unexpected signal encountered when running runhugs. I attached the end of my build log below. This failure occurs on both platforms I tried: Ubuntu 6.06 and Windows XP. It seems the recent change to input.c is to blame: * If any valid Haskell module (I tried A.hs containing [ main = putStrLn "hello" ] ) is substituted for hapax.hs on the command line, the unexpected signal still occurs. The problem is not specific to Cabal or hapax.hs. * If a module with a syntax or typechecking error is substituted for hapax.hs, runhugs correctly reports the error and exits. * If I check out the sources as of 2006-09-06 and then build Hugs, the build succeeds. * If I then "cvs update -A," which gives me the new input.c, and then "make" the build succeeds * If I "make clean" after running "cvs update -A," and before rebuilding, the same unexpected signal error stops the build. Regards, Brian .... Preprocessing Network/Hackage/CabalInstall/Install Preprocessing Network/Hackage/CabalInstall/List Preprocessing Network/Hackage/CabalInstall/Main Preprocessing Network/Hackage/CabalInstall/Setup Preprocessing Network/Hackage/CabalInstall/TarUtils Preprocessing Network/Hackage/CabalInstall/Types Preprocessing Network/Hackage/CabalInstall/Update Preprocessing Network/Hackage/Client Preprocessing Network/Hackage/Interface Preprocessing Network/Hackage/Version echo timestamp for bootlib >bootlib/.stamp cd ../cpphs; HUGSFLAGS=-P../libraries/bootlib HUGSDIR=../hugsdir ../src/runhugs -98 ../packages/Cabal/examples/hapax.hs configure --verbose --hugs --prefix='/us r/local' --scratchdir='../hugsdir/packages/cpphs' --with-compiler=../src/ffihugs Unexpected signal make[1]: *** [../hugsdir/programs/cpphs/Main.hs] Error 1 make[1]: Leaving directory `/home/brian/hugs98/libraries' make: *** [all] Error 2 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org//pipermail/cvs-hugs/attachments/20060909/34d59e5e/attachment.htm From ross at soi.city.ac.uk Sat Sep 9 05:37:48 2006 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sat Sep 9 05:25:04 2006 Subject: cvs commit: hugs98/src input.c Message-ID: <200609090937.k899bmCV013710@monk.galois.com> ross 2006/09/09 02:37:48 PDT Modified files: src input.c Log: don't try to use repeatStr if it's undefined (fixes bug reported by Brian Smith) Revision Changes Path 1.91 +3 -3 hugs98/src/input.c From ross at soi.city.ac.uk Sat Sep 9 06:25:38 2006 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sat Sep 9 06:12:57 2006 Subject: Fwd: Unexpected signal when buliding hugs98 CVS HEAD In-Reply-To: References: Message-ID: <20060909102538.GA3986@soi.city.ac.uk> On Sat, Sep 09, 2006 at 12:51:15AM -0500, Brian Smith wrote: > The current CVS HEAD fails to bulid--there is an unexpected signal > encountered when running runhugs. I attached the end of my build log below. > This failure occurs on both platforms I tried: Ubuntu 6.06 and Windows XP. Thanks for the report. I think it's fixed now. From brianlsmith at gmail.com Sat Sep 9 19:48:26 2006 From: brianlsmith at gmail.com (Brian Smith) Date: Sat Sep 9 19:35:40 2006 Subject: Fwd: Unexpected signal when buliding hugs98 CVS HEAD In-Reply-To: <20060909102538.GA3986@soi.city.ac.uk> References: <20060909102538.GA3986@soi.city.ac.uk> Message-ID: Ross, Thanks. But, now I get an error "No rule to make target '../hsc2hs/Main.hs'... It only happens with a fresh tree. If you already have build hugs once successfully, then the error doesn't occur. See this log: Configuring cpphs-1.2... configure: looking for package tool: hugs near compiler in ..\src\ffihugs configure: found package tool in ..\src\hugs.exe configure: Using install prefix: C:\haskell-toolchain-a\msys-mingw\local configure: Binaries installed in: C:\haskell-toolchain-a\msys-mingw\local\Haskel l\bin configure: Libraries installed in: C:\haskell-toolchain-a\msys-mingw\local\Haske ll\hugs\packages\cpphs configure: Private binaries installed in: C:\haskell-toolchain-a\msys-mingw\loca l\cpphs-1.2 configure: Data files installed in: C:\Program Files\Common Files\cpphs-1.2 configure: Using compiler: ..\src\ffihugs configure: Compiler flavor: Hugs configure: Compiler version: configure: Using package tool: ..\src\hugs.exe configure: Using ar found on system at: C:\haskell-toolchain-a\msys-mingw\mingw\ bin\ar.exe configure: Using haddock found on system at: c:\haskell-toolchain-A\haddock- 0.7\ haddock.exe configure: No pfesetup found configure: Using ranlib found on system at: C:\haskell-toolchain-a\msys-mingw\mi ngw\bin\ranlib.exe configure: Using runghc found on system at: c:\haskell-toolchain-A\ghc- 6.4.2\bin \runghc.exe configure: Using runhugs found on system at: c:\projects\hugs98\src\runhugs.exe configure: Using happy: c:\haskell-toolchain-A\happy-1.15\happy.exe configure: Using alex: c:\haskell-toolchain-A\alex-2.0.1\alex.exe configure: Using hsc2hs: c:\haskell-toolchain-A\ghc-6.4.2\bin\hsc2hs.exe configure: No c2hs found configure: No cpphs found configure: No greencard found cd ../cpphs; HUGSFLAGS=-P../libraries/bootlib HUGSDIR=../hugsdir ../src/runhugs -98 ../packages/Cabal/examples/hapax.hs build --verbose Preprocessing library cpphs-1.2... Preprocessing executables for cpphs-1.2... Building cpphs-1.2... /bin/rm -f -r ../hugsdir/packages/cpphs/autogen mkdir -p ../hugsdir/programs mv ../hugsdir/packages/cpphs/programs/cpphs ../hugsdir/programs rmdir ../hugsdir/packages/cpphs/programs (echo '@echo off'; \ echo "set rootdir=`cd ..; src/runhugs -Plibraries/bootlib libraries/pwd.hs`"; \ echo '%rootdir%/src/runhugs -P%rootdir%/libraries/bootlib %rootdir%/hugsdir/pro grams/cpphs/Main.hs %*') >tools/cpphs.bat make[1]: *** No rule to make target `../hsc2hs/Main.hs', needed by `../hugsdir/p rograms/hsc2hs/Main.hs'. Stop. make[1]: Leaving directory `/c/projects/hugs98/libraries' make: *** [all] Error 2 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org//pipermail/cvs-hugs/attachments/20060909/f4d13166/attachment.htm From ross at soi.city.ac.uk Sat Sep 9 20:09:12 2006 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sat Sep 9 19:56:27 2006 Subject: Fwd: Unexpected signal when buliding hugs98 CVS HEAD In-Reply-To: References: <20060909102538.GA3986@soi.city.ac.uk> Message-ID: <20060910000912.GC3986@soi.city.ac.uk> On Sat, Sep 09, 2006 at 06:48:26PM -0500, Brian Smith wrote: > Thanks. But, now I get an error "No rule to make target > '../hsc2hs/Main.hs'... > > It only happens with a fresh tree. If you already have build hugs once > successfully, then the error doesn't occur. > > [...] > make[1]: *** No rule to make target `../hsc2hs/Main.hs', needed by > `../hugsdir/p > rograms/hsc2hs/Main.hs'. Stop. > make[1]: Leaving directory `/c/projects/hugs98/libraries' > make: *** [all] Error 2 How odd. hsc2hs (including hugs98/hsc2hs/Main.hs) should be fetched by the top-level Makefile when it fetches the libraries and cpphs. Are you starting from a fresh CVS checkout, or are you using a local copy of the libraries? From brianlsmith at gmail.com Sat Sep 9 20:21:10 2006 From: brianlsmith at gmail.com (Brian Smith) Date: Sat Sep 9 20:08:23 2006 Subject: Fwd: Unexpected signal when buliding hugs98 CVS HEAD In-Reply-To: <20060910000912.GC3986@soi.city.ac.uk> References: <20060909102538.GA3986@soi.city.ac.uk> <20060910000912.GC3986@soi.city.ac.uk> Message-ID: Ross, The problem is that an empty hsc2hs directory gets created when we do a CVS checkout. When we darcs pull hsc2hs, then darcs sees the existing hsc2hs directory and puts everything into hsc2hs_0 instead. Actually, this was happening yesterday too, but I didn't mention it because I was trying to get around the unexpected signal problem. Here are the exact command I executed: rm -Rf hugs98 cvs co hugs98 cd hugs98 make On 9/9/06, Ross Paterson wrote: > > On Sat, Sep 09, 2006 at 06:48:26PM -0500, Brian Smith wrote: > > Thanks. But, now I get an error "No rule to make target > > '../hsc2hs/Main.hs'... > > > > It only happens with a fresh tree. If you already have build hugs once > > successfully, then the error doesn't occur. > > > > [...] > > make[1]: *** No rule to make target `../hsc2hs/Main.hs', needed by > > `../hugsdir/p > > rograms/hsc2hs/Main.hs'. Stop. > > make[1]: Leaving directory `/c/projects/hugs98/libraries' > > make: *** [all] Error 2 > > How odd. hsc2hs (including hugs98/hsc2hs/Main.hs) should be fetched > by the top-level Makefile when it fetches the libraries and cpphs. > Are you starting from a fresh CVS checkout, or are you using a local > copy of the libraries? > > _______________________________________________ > Cvs-hugs mailing list > Cvs-hugs@haskell.org > http://www.haskell.org/mailman/listinfo/cvs-hugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org//pipermail/cvs-hugs/attachments/20060909/d04e8d9c/attachment-0001.htm From ross at soi.city.ac.uk Sat Sep 9 20:29:48 2006 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sat Sep 9 20:17:03 2006 Subject: cvs commit: hugs98 Makefile Message-ID: <200609100029.k8A0TmFo030258@monk.galois.com> ross 2006/09/09 17:29:48 PDT Modified files: . Makefile Log: Ensure that directories are removed before fetching them with darcs (which avoids existing directories). Revision Changes Path 1.82 +2 -1 hugs98/Makefile From ross at soi.city.ac.uk Sat Sep 9 20:35:35 2006 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sat Sep 9 20:22:51 2006 Subject: Fwd: Unexpected signal when buliding hugs98 CVS HEAD In-Reply-To: References: <20060909102538.GA3986@soi.city.ac.uk> <20060910000912.GC3986@soi.city.ac.uk> Message-ID: <20060910003535.GA17005@soi.city.ac.uk> On Sat, Sep 09, 2006 at 07:21:10PM -0500, Brian Smith wrote: > The problem is that an empty hsc2hs directory gets created when we do a CVS > checkout. When we darcs pull hsc2hs, then darcs sees the existing hsc2hs > directory and puts everything into hsc2hs_0 instead. > > Actually, this was happening yesterday too, but I didn't mention it because > I was trying to get around the unexpected signal problem. > > Here are the exact command I executed: > > rm -Rf hugs98 > cvs co hugs98 > cd hugs98 > make Ah, I have "checkout -P" in my .cvsrc, so I wasn't getting this. The Makefile now removes the darcs directories before fetching, which should fix it. From brianlsmith at gmail.com Mon Sep 11 00:04:20 2006 From: brianlsmith at gmail.com (Brian Smith) Date: Sun Sep 10 23:51:38 2006 Subject: What tool versions (MinGW, MSYS, automake, etc.) do I need to build GHC on Windows? In-Reply-To: <036EAC76E7F5EC4996A3B3C3657D411606732752@EUR-MSG-21.europe.corp.microsoft.com> References: <036EAC76E7F5EC4996A3B3C3657D411606732752@EUR-MSG-21.europe.corp.microsoft.com> Message-ID: On 9/8/06, Simon Peyton-Jones wrote: > > I do recommend using MSYS as the environment, though. I find that GHC > builds much, much faster using MSYS than using Cygwin. > I always use MSYS, not Cygwin, when building GHC and Hugs. (MSYS is pretty slow too--I can build GHC faster in Ubuntu 6.06 in VMWare than I can when building it using MinGW.) But, I still need Cygwin because the tests require Cygwin python for some reason. The tools needed to build GHC, Hugs, and Darcs take about 575MB of disk space. Cygwin takes Do you know what tool versions are used for the automated builds? Re -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org//pipermail/cvs-hugs/attachments/20060910/a45ef378/attachment.htm From brianlsmith at gmail.com Mon Sep 11 00:20:41 2006 From: brianlsmith at gmail.com (Brian Smith) Date: Mon Sep 11 00:07:57 2006 Subject: What tool versions (MinGW, MSYS, automake, etc.) do I need to build GHC on Windows? In-Reply-To: References: <036EAC76E7F5EC4996A3B3C3657D411606732752@EUR-MSG-21.europe.corp.microsoft.com> Message-ID: Sorry, My message got sent prematurely. I was saying that the whole suite of tools needed to build GHC, Hugs, and Darcs on MSYS takes about 575MB; Cygwin is about 115MB of that and GHC 6.4.2 is 300MB of it. I have managed to get the binaries, HTML documentation (not DVI, PS, or PDF), and tests to build/run for GHC HEAD and Hugs HEAD. I am still working on Darcs HEAD. The versions of the tools I am using are: MinGW/MSYS Current: binutils 2.15.91-20040904 bison 2.0 gcc-core 3.4.2.20040916-1 gcc-g++ 3.4.2.20040916-1 mingw-runtime 3.9 mingw-utils 0.3 MSYS 1.0.10 MSYS DTK 1.0.1 libtool 1.5 w32api-3.6 automake 1.8.2 autoconf 2.59 CVS 1.11.22 DocBook XML 4.2 DocBook XSL 1.71.0 iconv 1.9.2 libcurl 7.15.4 libxml2 2.6.26 libxslt 1.1.17 zlib 1.2.3 Darcs 1.0.7 OpenSSL 0.9.8c Haddock 0.8 (HEAD as of today, the latest release, 0.7, will not build the GHC HEAD unmodified) Alex 2.0.1 Happy 1.15 GHC 6.4.2 Cygwin (latest as of today TODO: need version numbers) Regards, Brian On 9/10/06, Brian Smith wrote: > > On 9/8/06, Simon Peyton-Jones wrote: > > > I do recommend using MSYS as the environment, though. I find that GHC > > builds much, much faster using MSYS than using Cygwin. > > > > I always use MSYS, not Cygwin, when building GHC and Hugs. (MSYS is pretty > slow too--I can build GHC faster in Ubuntu 6.06 in VMWare than I can when > building it using MinGW.) But, I still need Cygwin because the tests require > Cygwin python for some reason. > > The tools needed to build GHC, Hugs, and Darcs take about 575MB of disk > space. Cygwin takes > > Do you know what tool versions are used for the automated builds? > > > > Re > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org//pipermail/cvs-hugs/attachments/20060910/4f0cf7c8/attachment.htm From ross at soi.city.ac.uk Tue Sep 19 20:15:36 2006 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Sep 19 20:02:19 2006 Subject: cvs commit: hugs98/docs/users_guide miscellaneous.xml Message-ID: <200609200015.k8K0FaAw006181@monk.galois.com> ross 2006/09/19 17:15:36 PDT Modified files: docs/users_guide miscellaneous.xml Log: ready for release Revision Changes Path 1.22 +6 -1 hugs98/docs/users_guide/miscellaneous.xml From ross at soi.city.ac.uk Thu Sep 21 11:44:46 2006 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Sep 21 11:31:32 2006 Subject: cvs commit: www/Hugs/pages downloading-Sep2006.htm Message-ID: <200609211544.k8LFikG7009371@monk.galois.com> ross 2006/09/21 08:44:46 PDT Added files: Hugs/pages downloading-Sep2006.htm Log: new release From ross at soi.city.ac.uk Thu Sep 21 12:06:57 2006 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Sep 21 11:53:34 2006 Subject: cvs commit: www/Hugs/pages downloading-Sep2006.htm Message-ID: <200609211606.k8LG6vdp009882@monk.galois.com> ross 2006/09/21 09:06:57 PDT Modified files: Hugs/pages downloading-Sep2006.htm Log: libraries notes Revision Changes Path 1.2 +13 -1 www/Hugs/pages/downloading-Sep2006.htm From ross at soi.city.ac.uk Thu Sep 21 17:35:56 2006 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Sep 21 17:22:34 2006 Subject: cvs commit: www/Hugs/pages downloading-Sep2006.htm Message-ID: <200609212135.k8LLZuxC015406@monk.galois.com> ross 2006/09/21 14:35:56 PDT Modified files: Hugs/pages downloading-Sep2006.htm Log: fix URLs Revision Changes Path 1.3 +2 -2 www/Hugs/pages/downloading-Sep2006.htm From ross at soi.city.ac.uk Sat Sep 23 10:07:47 2006 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sat Sep 23 09:54:18 2006 Subject: cvs commit: www/Hugs/pages latest.htm Message-ID: <200609231407.k8NE7l2b011042@monk.galois.com> ross 2006/09/23 07:07:47 PDT Modified files: Hugs/pages latest.htm Log: mention Sep 2006 release Revision Changes Path 1.15 +7 -1 www/Hugs/pages/latest.htm From duncan.coutts at worc.ox.ac.uk Tue Sep 5 08:02:44 2006 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Sep 26 07:33:41 2006 Subject: cvs commit: hugs98 Makefile RPM.mk hugs98/libraries/tools convert_libraries In-Reply-To: <20060905121200.1ff93533.Malcolm.Wallace@cs.york.ac.uk> References: <200609051004.k85A4Sma020533@monk.galois.com> <20060905113503.108886d8.Malcolm.Wallace@cs.york.ac.uk> <20060905105831.GA10006@soi.city.ac.uk> <20060905121200.1ff93533.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <1157458510.5127.1.camel@localhost> On Tue, 2006-09-05 at 12:12 +0100, Malcolm Wallace wrote: > > > > HaXml (no longer builds) > > > > > > In what way does HaXml fail to build for Hugs? Is it easily > > > fixable? > > > > ... and there's the famous Data.FiniteMap. > > So does anyone have any objections if I go ahead and commit the > replacement (compatibility) implementation of Data.FiniteMap to the main > repository for packages/base? I certainly would not object. It should still be marked deprecated of course, producing suitable warnings. As I said before, I'm happy for it to die by the time of GHC 6.8. Duncan From duncan.coutts at worc.ox.ac.uk Tue Sep 5 08:09:15 2006 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Sep 26 07:33:55 2006 Subject: cvs commit: hugs98 Makefile RPM.mk hugs98/libraries/tools convert_libraries In-Reply-To: <20060905111901.GB10006@soi.city.ac.uk> References: <200609051004.k85A4Sma020533@monk.galois.com> <20060905113503.108886d8.Malcolm.Wallace@cs.york.ac.uk> <20060905105831.GA10006@soi.city.ac.uk> <20060905121200.1ff93533.Malcolm.Wallace@cs.york.ac.uk> <20060905111901.GB10006@soi.city.ac.uk> Message-ID: <1157458891.5127.9.camel@localhost> On Tue, 2006-09-05 at 12:19 +0100, Ross Paterson wrote: > On Tue, Sep 05, 2006 at 12:12:00PM +0100, Malcolm Wallace wrote: > > > > > HaXml (no longer builds) > > > > > > > > In what way does HaXml fail to build for Hugs? Is it easily > > > > fixable? > > > > > > ... and there's the famous Data.FiniteMap. > > > > So does anyone have any objections if I go ahead and commit the > > replacement (compatibility) implementation of Data.FiniteMap to the main > > repository for packages/base? > > I'd rather see HaXml updated to use Data.Map, perhaps with a > compatibility layer for older GHCs. Using a compatibility layer is not that easy at the moment. There is a feature which will likely go into some upcoming version of Cabal that will make it easier to depend on different packages (eg a compat-finitemap) depending on what packages versions we are building against. For example you'd put something like the following in the .cabal file: configuration: package(base >= 2.0) build-depends: compat-finitemap However since this feature is not available yet it's rather hard to add a compatibility layer. Generating the .cabal file is a no-no. Duncan From simonmarhaskell at gmail.com Tue Sep 5 10:39:09 2006 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Sep 26 07:33:56 2006 Subject: cvs commit: hugs98 Makefile RPM.mk hugs98/libraries/tools convert_libraries In-Reply-To: <1157458891.5127.9.camel@localhost> References: <200609051004.k85A4Sma020533@monk.galois.com> <20060905113503.108886d8.Malcolm.Wallace@cs.york.ac.uk> <20060905105831.GA10006@soi.city.ac.uk> <20060905121200.1ff93533.Malcolm.Wallace@cs.york.ac.uk> <20060905111901.GB10006@soi.city.ac.uk> <1157458891.5127.9.camel@localhost> Message-ID: <44FD8EFC.3090800@microsoft.com> Duncan Coutts wrote: > On Tue, 2006-09-05 at 12:19 +0100, Ross Paterson wrote: > >>On Tue, Sep 05, 2006 at 12:12:00PM +0100, Malcolm Wallace wrote: >> >>>>>> HaXml (no longer builds) >>>>> >>>>>In what way does HaXml fail to build for Hugs? Is it easily >>>>>fixable? >>>> >>>>... and there's the famous Data.FiniteMap. >>> >>>So does anyone have any objections if I go ahead and commit the >>>replacement (compatibility) implementation of Data.FiniteMap to the main >>>repository for packages/base? >> >>I'd rather see HaXml updated to use Data.Map, perhaps with a >>compatibility layer for older GHCs. > > > Using a compatibility layer is not that easy at the moment. There is a > feature which will likely go into some upcoming version of Cabal that > will make it easier to depend on different packages (eg a > compat-finitemap) depending on what packages versions we are building > against. For example you'd put something like the following in > the .cabal file: > > configuration: package(base >= 2.0) > build-depends: compat-finitemap > > However since this feature is not available yet it's rather hard to add > a compatibility layer. Generating the .cabal file is a no-no. No problem - compat-finitemap can provide Compat.Data.Map with a Data.Map-like interface, which it implements either in terms of Data.Map or Data.FiniteMap. Then you *unconditionally* depend on compat-finitemap, and use Compat.Data.Map everywhere. Later, when you're ready to drop support for GHC 6.2.x, you drop the dependency on compat-finitemap and change every import Compat.Data.Map to Data.Map. Alternatively, compat-finitemap can provide a FiniteMap-like interface. This puts off the inevitable refactoring of the code to use the Data.Map-like interface until a later date. Cheers, Simon From brianlsmith at gmail.com Sat Sep 9 01:35:18 2006 From: brianlsmith at gmail.com (Brian Smith) Date: Tue Sep 26 07:33:57 2006 Subject: Unexpected signal when buliding hugs98 CVS HEAD Message-ID: The current CVS HEAD fails to bulid--there is an unexpected signal encountered when running runhugs. I attached the end of my build log below. This failure occurs on both platforms I tried: Ubuntu 6.06 and Windows XP. It seems the recent change to input.c is to blame: * If any valid Haskell module (I tried A.hs containing [ main = putStrLn "hello" ] ) is substituted for hapax.hs on the command line, the unexpected signal still occurs. The problem is not specific to Cabal or hapax.hs. * If a module with a syntax or typechecking error is substituted for hapax.hs, runhugs correctly reports the error and exits. * If I check out the sources as of 2006-09-06 and then build Hugs, the build succeeds. * If I then "cvs update -A," which gives me the new input.c, and then "make" the build succeeds * If I "make clean" after running "cvs update -A," and before rebuilding, the same unexpected signal error stops the build. Regards, Brian .... Preprocessing Network/Hackage/CabalInstall/Install Preprocessing Network/Hackage/CabalInstall/List Preprocessing Network/Hackage/CabalInstall/Main Preprocessing Network/Hackage/CabalInstall/Setup Preprocessing Network/Hackage/CabalInstall/TarUtils Preprocessing Network/Hackage/CabalInstall/Types Preprocessing Network/Hackage/CabalInstall/Update Preprocessing Network/Hackage/Client Preprocessing Network/Hackage/Interface Preprocessing Network/Hackage/Version echo timestamp for bootlib >bootlib/.stamp cd ../cpphs; HUGSFLAGS=-P../libraries/bootlib HUGSDIR=../hugsdir ../src/runhugs -98 ../packages/Cabal/examples/hapax.hs configure --verbose --hugs --prefix='/us r/local' --scratchdir='../hugsdir/packages/cpphs' --with-compiler=../src/ffihugs Unexpected signal make[1]: *** [../hugsdir/programs/cpphs/Main.hs] Error 1 make[1]: Leaving directory `/home/brian/hugs98/libraries' make: *** [all] Error 2 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/cvs-hugs/attachments/20060909/3ba600f3/attachment.htm From ross at soi.city.ac.uk Thu Sep 28 19:26:04 2006 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Sep 28 18:32:09 2006 Subject: cvs commit: hugs98 RPM.mk hugs98/libraries/tools make_bootlib test_libraries Message-ID: <200609282326.k8SNQ4LS007526@monk.galois.com> ross 2006/09/28 16:26:04 PDT Modified files: . RPM.mk libraries/tools make_bootlib test_libraries Log: ignore Setup scripts Revision Changes Path 1.55 +1 -1 hugs98/RPM.mk 1.15 +1 -1 hugs98/libraries/tools/make_bootlib 1.10 +1 -1 hugs98/libraries/tools/test_libraries