RE: GHC 6.4 release candidates available
| If you could specify overlapping on a per-instance basis, then that | would be a way around the problem. Yes, that's the solution I prefer. The only question is when to action it | This worked in all GHCi before 6.4 - so something has broken the (in mu | opinion) correct | behavior. Was this a deliberate decision - or has something just changed | without anyone realising? I explained in an earlier message in this thread why the new behaviour was an accidental consequence of lazy reporting of overlapping instances. 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
Simon Peyton-Jones wrote:
I explained in an earlier message in this thread why the new behaviour
was an accidental consequence of lazy reporting of overlapping
instances.
So,
{-# OPTIONS -fanything except overlapping instances #-} works as expected,
only overlapping instances is affected.
I don't see why it requires a per-instance fix (although that would be
nice).
If I start ghci with multiple source files:
ghci A.hs B.hs C.hs
we get:
*C
as the prompt - in this case why not just let the options pragma's from
'C.hs' be
in force in the interpreter. This fix is quick, and intuitive as the
interpreter is telling
you what it thinks is the context.
Consider the situation where ghci is used as an embedded interpreter in
another project. In the case where we do not know what options a given
script may require.
The only other solution I can think of is to have a wrapper script:
#!/bin/csh
if (`grep '^{-# OPTIONS -fallow-overlapping-instances #-} $1` != )
then
ghci_real -fallow-overlapping-instances $1
else
ghci_real $1
endif
I suppose you could check all top level .hs files given on the command
line for a more thorough check.
Keean.
___
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 04 March 2005 20:49, Keean Schupke wrote: Further to my last point, what if the top level module is Main... ghci Main.hs and that includes a main function, and pragmas, so that main runs when ghci is finished loading (automatically). GHCi doesn't run anything automatically. Could you elaborate? 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
Simon Marlow wrote: On 04 March 2005 20:49, Keean Schupke wrote: Further to my last point, what if the top level module is Main... ghci Main.hs and that includes a main function, and pragmas, so that main runs when ghci is finished loading (automatically). GHCi doesn't run anything automatically. Could you elaborate? My mistake... It seems fine to call 'main' in a .hs file which calls overlapping instances, so there appears to only be an issue with interactive execution. I guess this is not as serious as I thought, as runghc (which is ghci that automatically calls Main.main right?) works fine. Keean. ___ 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
I think GHC's behaviour is right here. To use the flag settings from
the source module on the command-line would be wrong: for example, when
the module is compiled, its implementation (and therefore flag settings)
must be hidden.
Also, as Simon pointed out, there might be multiple modules in scope at
the prompt, so how do you resolve the flag settings if they're
contradictory?
In general, flag settings affect the current source file only. The flag
settings at the GHCi prompt are those given on the command line and from
:set - it's simple, no worrying about where did that option come from?
I don't want overlapping instances!.
Cheers,
Simon
On 02 March 2005 18:33, Keean Schupke wrote:
Erm, what is the module context of GHCi? I thought ghci
used the context of the loaded module:
ghci Test.hs
*Test
I though the 'Test' in the prompt indicated you were in the context of
the Test module. In which case the pragma at the top of the test
module should be in force?
Keean.
Simon Peyton-Jones wrote:
Ah, yes. In 6.2, overlap errors were checked and reported eagerly
at the instance declaration. So instance C Int a
instance C b Bool
was rejected. Now it isn't. Instead the program is only rejected
if a constraint arises that matches two instance decls, and neither
is more specific. For example (C Int Bool)
But many constraints are fine e.g. C Int Char
However this does have the consequence that the overlapping-instance
flag must be on in the module that calls the function rather than the
one that defines the instances. It'd be better if the info
travelled with the instance decl, but it doesn't (yet). A good
feature request.
Simon
-Original Message-
From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-users- [EMAIL PROTECTED] On Behalf Of
Keean Schupke
Sent: 02 March 2005 17:20
To: Simon Peyton-Jones
Cc: glasgow-haskell-users@haskell.org
Subject: Re: GHC 6.4 release candidates available
In the past having:
{-# OPTIONS -fallow-overlapping-instances #-}
in a module was enough to get ghci to allow the overlaps.
so we do:
ghci Test.hs
now it does not work (but it did in 6.3), but:
ghci -fallow-overlapping-instances Test.hs
does... Even it Test.hs is the top level module.
Keean.
Simon Peyton-Jones wrote:
Ralf
You have a pragma -fallow-overlapping-instances in Test.hs, and
indeed it is honoured when compiling Test.hs. But it's not taken
into account when compiling top-level expressions, or, indeed, if
you were to import Test into another module.
If you say :set -falllow-overlapping-instances it'll work fine.
Now, maybe you'd like the flag to attach permanently to the
*instance*, so that if an instance decl is compiled with
-fallow-overlapping-instances, then no complaint will ever be
issued for its overlaps, even if it is imported into a module that
doesn't have -fallow-overlapping-instances. That would make
sense, I think, but it's not implemented and never has been.
Simon
-Original Message-
From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-users- [EMAIL PROTECTED] On Behalf Of
Ralf Lammel
Sent: 02 March 2005 08:45
To: glasgow-haskell-users@haskell.org
Subject: RE: GHC 6.4 release candidates available
I think this is an old bug,
or at least I have seen it months back.
The overlapping instances directive does not make it to the
top-level. See attached sample with the offending session.
Thanks for fixing.
Ralf
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
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
There can only be one top level module in ghci (there can only be one module name before the '' prompt - that modules options should be in effect. The whole point of putting options at the top of the source file is so that the user/compiler of the code does not need to know which specific options are required. If the code specifies overlapping instances, I don't expext to have to specify it on the command line as well. Simon Marlow wrote: I think GHC's behaviour is right here. To use the flag settings from the source module on the command-line would be wrong: for example, when the module is compiled, its implementation (and therefore flag settings) must be hidden. Requiring options on the command line exposes the implementation I do not expect the GHCi user to be required to know which flags to apply to get my code to run. Also, as Simon pointed out, there might be multiple modules in scope at the prompt, so how do you resolve the flag settings if they're contradictory? Only the flags from the top level (the one named before the prompt) would be in scope. If I type: ghci Test.hs Then I would expect the options pragma in Test.hs to be in effect. In general, flag settings affect the current source file only. The flag settings at the GHCi prompt are those given on the command line and from :set - it's simple, no worrying about where did that option come from? I don't want overlapping instances!. I really don't like GHCi users needing to know what flags they must use to get code to work. There must be some way of code asserting top level options. If the options pragma cannot be used for this purpose I suggest there should be another way for code to assert top level options of ghci... this method should be in the source file so that extra options files are not required... Keean. ___ 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 04 March 2005 12:58, Keean Schupke wrote: There can only be one top level module in ghci (there can only be one module name before the '' prompt - that modules options should be in effect. No, you can have multiple top-level module scopes in effect. See the GHCi documentation. Simon Marlow wrote: I think GHC's behaviour is right here. To use the flag settings from the source module on the command-line would be wrong: for example, when the module is compiled, its implementation (and therefore flag settings) must be hidden. Requiring options on the command line exposes the implementation I do not expect the GHCi user to be required to know which flags to apply to get my code to run. Why not? You're providing a library which exports some instances. If overlapping instance resolution is required to resolve overloading in code that uses the library, I want to know about it, and I don't want the compiler to turn on overlapping instance resolution behind my back. Importing a library should *not* affect how the code that imports it is compiled, except in the ways you expect (bringing names and instances into scope). If you could specify overlapping on a per-instance basis, then that would be a way around the problem. 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 (breakage on x86-64)
On 02 March 2005 05:08, Brian Strand wrote: Donald Bruce Stewart wrote: bstrand: Donald Bruce Stewart wrote: bstrand: Simon Marlow wrote: Just to let you know, there are a number of open bug reports for GHC on the x86_64 platform, which seem to indicate some kind of occasional memory/GC problem. I'm probably not going to be able to track this down until after the 6.4 release, but we'll put out a patch as soon as we have one. Here's an error building ghc-6.4.20050224ghc-6.4.20050224 via Anders' Debian x86-64 ghc, although it doesn't look like a memory/GC problem to my untrained eye: ==fptools== make boot - --no-print-directory -r; in /home/bstrand/src/ghc-6.4.20050224/ghc/lib/compat ../../../glafp-utils/mkdependC/mkdependC -f .depend -I../../includes -- -O-- cbits/directory.c cbits/rawSystem.c /usr/bin/ghc -M -optdep-f -optdep.depend -osuf o-H16m -O -H64m -O -I. -Rghc-timing -I../../../libraries -fglasgow-exts -no-recomp Compat/Directory.hs Compat/RawSystem.hs Distribution/Compat/ReadP.hs Distribution/Extension.hs Distribution/GetOpt.hs Distribution/InstalledPackageInfo.hs Distribution/License.hs Distribution/Package.hs Distribution/ParseUtils.hs Distribution/Setup.hs Distribution/Version.hs System/Directory/Internals.hs ghc: 15653112 bytes, 5 GCs, 73168/73168 avg/max bytes residency (1 samples), 63M in use, 0.00 INIT (0.00 elapsed), 0.12 MUT (5.14 elapsed), 0.03 GC (0.57 elapsed) :ghc make all rm -f System/Directory/Internals.o; if [ ! -d System/Directory/Internals_split ]; then mkdir System/Directory/Internals_split; else /usr/bin/find System/Directory/Internals_split -name '*.o' -print | xargs rm -f __rm_food; fi; /usr/bin/ghc -H16m -O -H64m -O -I. -Rghc-timing -I../../../libraries -fglasgow-exts -no-recomp -split-objs-c System/Directory/Internals.hs-o System/Directory/Internals.o -ohi System/Directory/Internals.hi warning: don't know how to split object files on this architecture ghc: 76094368 bytes, 11 GCs, 2187736/4575048 avg/max bytes residency (3 samples), 66M in use, 0.00 INIT (0.00 elapsed), 0.87 MUT (13.77 elapsed), 0.14 GC (1.40 elapsed) :ghc ( cd System/Directory/Internals_split; rm -f ld.script; touch ld.script; echo INPUT( *.o ) ld.script; /usr/bin/ld -r -x -o ../Internals.old.script; ); /usr/bin/ld:ld.script: file format not recognized; treating as linker script /usr/bin/ld:ld.script:1: syntax error make[4]: *** [System/Directory/Internals.o] Error 1 make[3]: *** [boot] Error 2 make[2]: *** [boot] Error 1 make[1]: *** [boot] Error 1 make[1]: Leaving directory `/home/bstrand/src/ghc-6.4.20050224/ghc' make: *** [build] Error 1 Can you try building with SplitObjs=NO ? Wolfgang, Ryan - that looks like a splitter problem, no? (The splitter is more of a dark art than the evil mangler, I propose we name it the diabolical splitter from now on.) -- Don Using SplitObjs=NO gives out many warnings then finally dies with: ../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -H16m -O -H64m -O -O2 -static -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include RtsUtils.h -#include StgRun.h -#includeSchedule.h -#include Printer.h -#include Sanity.h -#include STM.h -#include Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h-#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h -#include Apply.h -fvia-C -dcmm-lint -c StgCRun.c -o StgCRun.o In file included from ../includes/Stg.h:149, from StgCRun.c:67: ../includes/Regs.h:213: warning: call-clobbered register used for global register variable ../includes/Regs.h:342: warning: call-clobbered register used for global register variable /tmp/ghc13908.s: Assembler messages: /tmp/ghc13908.s:20: Error: suffix or operands invalid for `jmp' make[2]: *** [StgCRun.o] Error 1 make[1]: *** [all] Error 1 make[1]: Leaving directory `/home/bstrand/src/ghc-6.4.20050224/ghc' make: *** [build] Error 1 Are you building unregisterised? Those messages about global register variables (I think) imply that you are not -- and we haven't yet got x86_64 (terrible name, I much prefer amd64) registerised. Looks like you might even have found the point where registerisation breaks. Try building unregisterised: GhcUnregisterised=YES just as the .hc bootstrap compiler was built. -- Don Well, I don't know much about how the bootstrap compiler was built (I just downloaded it from http://debian-amd64.alioth.debian.org/pure64/pool/unstable/main/amd64/g/ ghc6/), but building with GhcUnregisterised=YES and SplitObjs=NO died with: ==fptools== make all -wr; in
Re: GHC 6.4 release candidates available
Simon Marlow wrote: On 04 March 2005 12:58, Keean Schupke wrote: There can only be one top level module in ghci (there can only be one module name before the '' prompt - that modules options should be in effect. No, you can have multiple top-level module scopes in effect. See the GHCi documentation. But I can also have just one top level module ... Simon Marlow wrote: I think GHC's behaviour is right here. To use the flag settings from the source module on the command-line would be wrong: for example, when the module is compiled, its implementation (and therefore flag settings) must be hidden. Requiring options on the command line exposes the implementation I do not expect the GHCi user to be required to know which flags to apply to get my code to run. Why not? You're providing a library which exports some instances. If overlapping instance resolution is required to resolve overloading in code that uses the library, I want to know about it, and I don't want the compiler to turn on overlapping instance resolution behind my back. But what if it is an application and not a library... you definitely do not wantr to have to explain in the user manual that ghci needs to be started with: ghci -fglasgow-exts -fallow-overlapping-instances ... Further more it is the _importing_ module that needs to have overlapping instances defined, therefore there is absolutely no chance of them being turned on behind your back. Importing a library should *not* affect how the code that imports it is compiled, except in the ways you expect (bringing names and instances into scope). It would not... All I am saying is if the top level module in GHCi (the one named in the prompt) has OPTIONS pagmas these should be in effect. If you could specify overlapping on a per-instance basis, then that would be a way around the problem. This worked in all GHCi before 6.4 - so something has broken the (in mu opinion) correct behavior. Was this a deliberate decision - or has something just changed without anyone realising? Keean. ___ 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
Further to my last point, what if the top level module is Main... ghci Main.hs and that includes a main function, and pragmas, so that main runs when ghci is finished loading (automatically). If main runs automatically then the context of ghci must be the Main module, so why would the options pragmas not be in effect? for example: ghc -o test Main.hs needs no flags and I can then run test with no flags (./test). But: ghci Main.hs Now all of a sudden you are telling me I need to provide command line flags to get it to run (in the interpreter) but I do not need to if I use the compiler... (remember this worked fine in 6.3 and 6.3 included the new lazy instance overlap detection) This seems very inconsistant to me... I really like the ability to put any flags code might need into the source using the OPTIONS pragmas... but it seems to undermine the usefulness of this if ghci ignores the flags. Keean ___ 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
There may be many loaded modules... What if they have contradictory
flags
And in fact GHC doesn't remember in interface files the flag settings
with which was compiled. Perhaps it should, but it doesn't at the
moment.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of Keean Schupke
| Sent: 02 March 2005 18:33
| To: Simon Peyton-Jones
| Cc: glasgow-haskell-users@haskell.org
| Subject: Re: GHC 6.4 release candidates available
|
| Erm, what is the module context of GHCi? I thought ghci
| used the context of the loaded module:
|
| ghci Test.hs
|
| *Test
|
| I though the 'Test' in the prompt indicated you were in the context of
| the Test module. In which case the pragma at the top of the test
| module should be in force?
|
| Keean.
|
| Simon Peyton-Jones wrote:
|
| Ah, yes. In 6.2, overlap errors were checked and reported eagerly
at
| the instance declaration. So
| instance C Int a
| instance C b Bool
| was rejected. Now it isn't. Instead the program is only rejected if
a
| constraint arises that matches two instance decls, and neither is
more
| specific. For example (C Int Bool)
|
| But many constraints are fine e.g. C Int Char
|
| However this does have the consequence that the overlapping-instance
| flag must be on in the module that calls the function rather than the
| one that defines the instances. It'd be better if the info
travelled
| with the instance decl, but it doesn't (yet). A good feature
request.
|
| Simon
|
| | -Original Message-
| | From: [EMAIL PROTECTED]
| [mailto:glasgow-haskell-users-
| | [EMAIL PROTECTED] On Behalf Of Keean Schupke
| | Sent: 02 March 2005 17:20
| | To: Simon Peyton-Jones
| | Cc: glasgow-haskell-users@haskell.org
| | Subject: Re: GHC 6.4 release candidates available
| |
| | In the past having:
| |
| | {-# OPTIONS -fallow-overlapping-instances #-}
| |
| | in a module was enough to get ghci to allow the overlaps.
| |
| | so we do:
| |
| | ghci Test.hs
| |
| | now it does not work (but it did in 6.3), but:
| |
| | ghci -fallow-overlapping-instances Test.hs
| |
| | does... Even it Test.hs is the top level module.
| |
| | Keean.
| |
| | Simon Peyton-Jones wrote:
| |
| | Ralf
| |
| | You have a pragma -fallow-overlapping-instances in Test.hs, and
| indeed
| | it is honoured when compiling Test.hs. But it's not taken into
| account
| | when compiling top-level expressions, or, indeed, if you were to
| import
| | Test into another module.
| |
| | If you say :set -falllow-overlapping-instances it'll work fine.
| |
| | Now, maybe you'd like the flag to attach permanently to the
| *instance*,
| | so that if an instance decl is compiled with
| | -fallow-overlapping-instances, then no complaint will ever be
issued
| for
| | its overlaps, even if it is imported into a module that doesn't
have
| | -fallow-overlapping-instances. That would make sense, I think,
but
| it's
| | not implemented and never has been.
| |
| | Simon
| |
| | | -Original Message-
| | | From: [EMAIL PROTECTED]
| | [mailto:glasgow-haskell-users-
| | | [EMAIL PROTECTED] On Behalf Of Ralf Lammel
| | | Sent: 02 March 2005 08:45
| | | To: glasgow-haskell-users@haskell.org
| | | Subject: RE: GHC 6.4 release candidates available
| | |
| | | I think this is an old bug,
| | | or at least I have seen it months back.
| | |
| | | The overlapping instances directive does not make it to the
| | top-level.
| | | See attached sample with the offending session.
| | |
| | | Thanks for fixing.
| | | Ralf
| |
| | ___
| | Glasgow-haskell-users mailing list
| | Glasgow-haskell-users@haskell.org
| | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
| |
| |
| |
| | ___
| | Glasgow-haskell-users mailing list
| | Glasgow-haskell-users@haskell.org
| | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|
|
|
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
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
I think this is an old bug, or at least I have seen it months back. The overlapping instances directive does not make it to the top-level. See attached sample with the offending session. Thanks for fixing. Ralf Test.hs Description: Test.hs ___ 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
Ian Lynagh [EMAIL PROTECTED] writes: ghc-6.4.20050228-src.tar.bz2 I think you have unswapped the first two lines of ghc -v 21 | head -2 but not changed Reading back to Using, so old hmakes are still broken (old includes the latest release, I believe). There are a couple of other configuration changes needed in hmake to support ghc-6.4 as well, so there will be a new release shortly. Regards, Malcolm ___ 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 02 March 2005 02:10, Benjamin Franksen wrote: I haven't followed this thread too closely so please excuse me if this has already been mentioned (or even fixed). After I installed the latest binary package (20050228) the documentation was not correctly linked from the main documentation page. 'Hierarchical Libraries' on the main page points to /usr/local/share/ghc-6.4.20050228/html/libraries/index.html, but in this directory there is no index.html, only subdirectories. The link named 'Cabal' is also dead: file:/usr/local/share/ghc-6.4.20050228/html/Cabal/index.html does not exist). This is clearly non-critical, but it would be nice if it could be fixed in the final version. These should be fixed in last night's snapshot. There were some problems with building the docs, and some of the docs didn't get included in the tarball. 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
Ralf You have a pragma -fallow-overlapping-instances in Test.hs, and indeed it is honoured when compiling Test.hs. But it's not taken into account when compiling top-level expressions, or, indeed, if you were to import Test into another module. If you say :set -falllow-overlapping-instances it'll work fine. Now, maybe you'd like the flag to attach permanently to the *instance*, so that if an instance decl is compiled with -fallow-overlapping-instances, then no complaint will ever be issued for its overlaps, even if it is imported into a module that doesn't have -fallow-overlapping-instances. That would make sense, I think, but it's not implemented and never has been. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-users- | [EMAIL PROTECTED] On Behalf Of Ralf Lammel | Sent: 02 March 2005 08:45 | To: glasgow-haskell-users@haskell.org | Subject: RE: GHC 6.4 release candidates available | | I think this is an old bug, | or at least I have seen it months back. | | The overlapping instances directive does not make it to the top-level. | See attached sample with the offending session. | | Thanks for fixing. | Ralf ___ 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
In the past having:
{-# OPTIONS -fallow-overlapping-instances #-}
in a module was enough to get ghci to allow the overlaps.
so we do:
ghci Test.hs
now it does not work (but it did in 6.3), but:
ghci -fallow-overlapping-instances Test.hs
does... Even it Test.hs is the top level module.
Keean.
Simon Peyton-Jones wrote:
Ralf
You have a pragma -fallow-overlapping-instances in Test.hs, and indeed
it is honoured when compiling Test.hs. But it's not taken into account
when compiling top-level expressions, or, indeed, if you were to import
Test into another module.
If you say :set -falllow-overlapping-instances it'll work fine.
Now, maybe you'd like the flag to attach permanently to the *instance*,
so that if an instance decl is compiled with
-fallow-overlapping-instances, then no complaint will ever be issued for
its overlaps, even if it is imported into a module that doesn't have
-fallow-overlapping-instances. That would make sense, I think, but it's
not implemented and never has been.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of Ralf Lammel
| Sent: 02 March 2005 08:45
| To: glasgow-haskell-users@haskell.org
| Subject: RE: GHC 6.4 release candidates available
|
| I think this is an old bug,
| or at least I have seen it months back.
|
| The overlapping instances directive does not make it to the
top-level.
| See attached sample with the offending session.
|
| Thanks for fixing.
| Ralf
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
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
Ah, yes. In 6.2, overlap errors were checked and reported eagerly at
the instance declaration. So
instance C Int a
instance C b Bool
was rejected. Now it isn't. Instead the program is only rejected if a
constraint arises that matches two instance decls, and neither is more
specific. For example (C Int Bool)
But many constraints are fine e.g. C Int Char
However this does have the consequence that the overlapping-instance
flag must be on in the module that calls the function rather than the
one that defines the instances. It'd be better if the info travelled
with the instance decl, but it doesn't (yet). A good feature request.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of Keean Schupke
| Sent: 02 March 2005 17:20
| To: Simon Peyton-Jones
| Cc: glasgow-haskell-users@haskell.org
| Subject: Re: GHC 6.4 release candidates available
|
| In the past having:
|
| {-# OPTIONS -fallow-overlapping-instances #-}
|
| in a module was enough to get ghci to allow the overlaps.
|
| so we do:
|
| ghci Test.hs
|
| now it does not work (but it did in 6.3), but:
|
| ghci -fallow-overlapping-instances Test.hs
|
| does... Even it Test.hs is the top level module.
|
| Keean.
|
| Simon Peyton-Jones wrote:
|
| Ralf
|
| You have a pragma -fallow-overlapping-instances in Test.hs, and
indeed
| it is honoured when compiling Test.hs. But it's not taken into
account
| when compiling top-level expressions, or, indeed, if you were to
import
| Test into another module.
|
| If you say :set -falllow-overlapping-instances it'll work fine.
|
| Now, maybe you'd like the flag to attach permanently to the
*instance*,
| so that if an instance decl is compiled with
| -fallow-overlapping-instances, then no complaint will ever be issued
for
| its overlaps, even if it is imported into a module that doesn't have
| -fallow-overlapping-instances. That would make sense, I think, but
it's
| not implemented and never has been.
|
| Simon
|
| | -Original Message-
| | From: [EMAIL PROTECTED]
| [mailto:glasgow-haskell-users-
| | [EMAIL PROTECTED] On Behalf Of Ralf Lammel
| | Sent: 02 March 2005 08:45
| | To: glasgow-haskell-users@haskell.org
| | Subject: RE: GHC 6.4 release candidates available
| |
| | I think this is an old bug,
| | or at least I have seen it months back.
| |
| | The overlapping instances directive does not make it to the
| top-level.
| | See attached sample with the offending session.
| |
| | Thanks for fixing.
| | Ralf
|
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|
|
|
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
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
Erm, what is the module context of GHCi? I thought ghci
used the context of the loaded module:
ghci Test.hs
*Test
I though the 'Test' in the prompt indicated you were in the context of
the Test module. In which case the pragma at the top of the test
module should be in force?
Keean.
Simon Peyton-Jones wrote:
Ah, yes. In 6.2, overlap errors were checked and reported eagerly at
the instance declaration. So
instance C Int a
instance C b Bool
was rejected. Now it isn't. Instead the program is only rejected if a
constraint arises that matches two instance decls, and neither is more
specific. For example (C Int Bool)
But many constraints are fine e.g. C Int Char
However this does have the consequence that the overlapping-instance
flag must be on in the module that calls the function rather than the
one that defines the instances. It'd be better if the info travelled
with the instance decl, but it doesn't (yet). A good feature request.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of Keean Schupke
| Sent: 02 March 2005 17:20
| To: Simon Peyton-Jones
| Cc: glasgow-haskell-users@haskell.org
| Subject: Re: GHC 6.4 release candidates available
|
| In the past having:
|
| {-# OPTIONS -fallow-overlapping-instances #-}
|
| in a module was enough to get ghci to allow the overlaps.
|
| so we do:
|
| ghci Test.hs
|
| now it does not work (but it did in 6.3), but:
|
| ghci -fallow-overlapping-instances Test.hs
|
| does... Even it Test.hs is the top level module.
|
| Keean.
|
| Simon Peyton-Jones wrote:
|
| Ralf
|
| You have a pragma -fallow-overlapping-instances in Test.hs, and
indeed
| it is honoured when compiling Test.hs. But it's not taken into
account
| when compiling top-level expressions, or, indeed, if you were to
import
| Test into another module.
|
| If you say :set -falllow-overlapping-instances it'll work fine.
|
| Now, maybe you'd like the flag to attach permanently to the
*instance*,
| so that if an instance decl is compiled with
| -fallow-overlapping-instances, then no complaint will ever be issued
for
| its overlaps, even if it is imported into a module that doesn't have
| -fallow-overlapping-instances. That would make sense, I think, but
it's
| not implemented and never has been.
|
| Simon
|
| | -Original Message-
| | From: [EMAIL PROTECTED]
| [mailto:glasgow-haskell-users-
| | [EMAIL PROTECTED] On Behalf Of Ralf Lammel
| | Sent: 02 March 2005 08:45
| | To: glasgow-haskell-users@haskell.org
| | Subject: RE: GHC 6.4 release candidates available
| |
| | I think this is an old bug,
| | or at least I have seen it months back.
| |
| | The overlapping instances directive does not make it to the
| top-level.
| | See attached sample with the offending session.
| |
| | Thanks for fixing.
| | Ralf
|
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|
|
|
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
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
It also worked in 6.2
Before that I don't remember.
It is a very sensible thing to do
simply because the mere ghci prompt suggests that
we are in the scope of the top-level module.
So one would really expect that ghci honors the
directives of the top-level module.
Ralf
-Original Message-
From: Keean Schupke [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 02, 2005 9:20 AM
To: Simon Peyton-Jones
Cc: Ralf Lammel; glasgow-haskell-users@haskell.org
Subject: Re: GHC 6.4 release candidates available
In the past having:
{-# OPTIONS -fallow-overlapping-instances #-}
in a module was enough to get ghci to allow the overlaps.
so we do:
ghci Test.hs
now it does not work (but it did in 6.3), but:
ghci -fallow-overlapping-instances Test.hs
does... Even it Test.hs is the top level module.
Keean.
Simon Peyton-Jones wrote:
Ralf
You have a pragma -fallow-overlapping-instances in Test.hs, and
indeed
it is honoured when compiling Test.hs. But it's not taken into
account
when compiling top-level expressions, or, indeed, if you were to
import
Test into another module.
If you say :set -falllow-overlapping-instances it'll work fine.
Now, maybe you'd like the flag to attach permanently to the
*instance*,
so that if an instance decl is compiled with
-fallow-overlapping-instances, then no complaint will ever be issued
for
its overlaps, even if it is imported into a module that doesn't have
-fallow-overlapping-instances. That would make sense, I think, but
it's
not implemented and never has been.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of Ralf Lammel
| Sent: 02 March 2005 08:45
| To: glasgow-haskell-users@haskell.org
| Subject: RE: GHC 6.4 release candidates available
|
| I think this is an old bug,
| or at least I have seen it months back.
|
| The overlapping instances directive does not make it to the
top-level.
| See attached sample with the offending session.
|
| Thanks for fixing.
| Ralf
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
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 Thu, Feb 10, 2005 at 01:11:48PM -, Simon Marlow wrote:
We are finally at the release candidate stage for GHC 6.4. Snapshots
with versions 6.4.20050209 and later should be considered release
candidates for 6.4.
Source and Linux binary distributions are avaiable here:
http://www.haskell.org/ghc/dist/stable/dist/
Please test if you're able to, and give us feedback.
All the below with
2c7ed0ee7a11f2eae159d073c29b4fe6 ghc-6.4.20050228-src.tar.bz2
The following files in the tarball look like they shouldn't be there
(and should be cleaned by at least distclean):
* ghc/includes/mkGHCConstants (an x86 ELF binary)
* ghc/driver/package.conf.inplace.old
* ghc/driver/package.conf.old
* A large number of ld.script files and the _split directories they are in
* libraries/{OpenAL,X11,base,network,unix}/config.status
* libraries/config.status
After building, then doing make distclean, I'm additionally left with:
* A ghc/compiler/stage1 directory tree including a number of
.hi-boot-5 and .hi-boot-6 files.
* A ghc/compiler/stage2 directory tree including a number of
.hi-noot and .o-boot files.
* A complete libraries/html directory
* libraries/libraries.txt
* mk/config.h
* mk/config.mk
* mk/stamp-h
but Building from source / Standard Targets says:
distclean
Delete all files from the current directory that are created by
configuring or building the program. If you have unpacked the source
and built the program without creating any other files, make
distclean should leave only the files that were in the distribution.
I think you have unswapped the first two lines of
ghc -v 21 | head -2 but not changed Reading back to Using, so
old hmakes are still broken (old includes the latest release, I
believe).
Is there an equivalent of this (the no-OpenGL bit):
$(MAKE) prefix=`pwd`/debian/tmp/usr install GhcLibsWithOpenGL=NO
GhcLibsWithGLUT=NO
that still works or do I have to do it by hand?
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
I haven't followed this thread too closely so please excuse me if this has already been mentioned (or even fixed). After I installed the latest binary package (20050228) the documentation was not correctly linked from the main documentation page. 'Hierarchical Libraries' on the main page points to /usr/local/share/ghc-6.4.20050228/html/libraries/index.html, but in this directory there is no index.html, only subdirectories. The link named 'Cabal' is also dead: file:/usr/local/share/ghc-6.4.20050228/html/Cabal/index.html does not exist). This is clearly non-critical, but it would be nice if it could be fixed in the final version. Ben ___ 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 (breakage on x86-64)
Donald Bruce Stewart wrote: bstrand: Donald Bruce Stewart wrote: bstrand: Simon Marlow wrote: Just to let you know, there are a number of open bug reports for GHC on the x86_64 platform, which seem to indicate some kind of occasional memory/GC problem. I'm probably not going to be able to track this down until after the 6.4 release, but we'll put out a patch as soon as we have one. Here's an error building ghc-6.4.20050224ghc-6.4.20050224 via Anders' Debian x86-64 ghc, although it doesn't look like a memory/GC problem to my untrained eye: ==fptools== make boot - --no-print-directory -r; in /home/bstrand/src/ghc-6.4.20050224/ghc/lib/compat ../../../glafp-utils/mkdependC/mkdependC -f .depend-I../../includes -- -O-- cbits/directory.c cbits/rawSystem.c /usr/bin/ghc -M -optdep-f -optdep.depend -osuf o-H16m -O -H64m -O -I. -Rghc-timing -I../../../libraries -fglasgow-exts -no-recomp Compat/Directory.hs Compat/RawSystem.hs Distribution/Compat/ReadP.hs Distribution/Extension.hs Distribution/GetOpt.hs Distribution/InstalledPackageInfo.hs Distribution/License.hs Distribution/Package.hs Distribution/ParseUtils.hs Distribution/Setup.hs Distribution/Version.hs System/Directory/Internals.hs ghc: 15653112 bytes, 5 GCs, 73168/73168 avg/max bytes residency (1 samples), 63M in use, 0.00 INIT (0.00 elapsed), 0.12 MUT (5.14 elapsed), 0.03 GC (0.57 elapsed) :ghc make all rm -f System/Directory/Internals.o; if [ ! -d System/Directory/Internals_split ]; then mkdir System/Directory/Internals_split; else /usr/bin/find System/Directory/Internals_split -name '*.o' -print | xargs rm -f __rm_food; fi; /usr/bin/ghc -H16m -O -H64m -O -I. -Rghc-timing -I../../../libraries -fglasgow-exts -no-recomp -split-objs-c System/Directory/Internals.hs-o System/Directory/Internals.o -ohi System/Directory/Internals.hi warning: don't know how to split object files on this architecture ghc: 76094368 bytes, 11 GCs, 2187736/4575048 avg/max bytes residency (3 samples), 66M in use, 0.00 INIT (0.00 elapsed), 0.87 MUT (13.77 elapsed), 0.14 GC (1.40 elapsed) :ghc ( cd System/Directory/Internals_split; rm -f ld.script; touch ld.script; echo INPUT( *.o ) ld.script; /usr/bin/ld -r -x -o ../Internals.old.script; ); /usr/bin/ld:ld.script: file format not recognized; treating as linker script /usr/bin/ld:ld.script:1: syntax error make[4]: *** [System/Directory/Internals.o] Error 1 make[3]: *** [boot] Error 2 make[2]: *** [boot] Error 1 make[1]: *** [boot] Error 1 make[1]: Leaving directory `/home/bstrand/src/ghc-6.4.20050224/ghc' make: *** [build] Error 1 Can you try building with SplitObjs=NO ? Wolfgang, Ryan - that looks like a splitter problem, no? (The splitter is more of a dark art than the evil mangler, I propose we name it the diabolical splitter from now on.) -- Don Using SplitObjs=NO gives out many warnings then finally dies with: ../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -H16m -O -H64m -O -O2 -static -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include RtsUtils.h -#include StgRun.h -#includeSchedule.h -#include Printer.h -#include Sanity.h -#include STM.h -#include Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h-#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h -#include Apply.h -fvia-C -dcmm-lint -c StgCRun.c -o StgCRun.o In file included from ../includes/Stg.h:149, from StgCRun.c:67: ../includes/Regs.h:213: warning: call-clobbered register used for global register variable ../includes/Regs.h:342: warning: call-clobbered register used for global register variable /tmp/ghc13908.s: Assembler messages: /tmp/ghc13908.s:20: Error: suffix or operands invalid for `jmp' make[2]: *** [StgCRun.o] Error 1 make[1]: *** [all] Error 1 make[1]: Leaving directory `/home/bstrand/src/ghc-6.4.20050224/ghc' make: *** [build] Error 1 Are you building unregisterised? Those messages about global register variables (I think) imply that you are not -- and we haven't yet got x86_64 (terrible name, I much prefer amd64) registerised. Looks like you might even have found the point where registerisation breaks. Try building unregisterised: GhcUnregisterised=YES just as the .hc bootstrap compiler was built. -- Don Well, I don't know much about how the bootstrap compiler was built (I just downloaded it from http://debian-amd64.alioth.debian.org/pure64/pool/unstable/main/amd64/g/ghc6/), but building with GhcUnregisterised=YES and SplitObjs=NO died with: ==fptools== make all -wr; in /home/bstrand/src/ghc-6.4.20050224/libraries/base
Re: GHC 6.4 release candidates available
Ian Lynagh wrote: [...] Is there an equivalent of this (the no-OpenGL bit): $(MAKE) prefix=`pwd`/debian/tmp/usr install GhcLibsWithOpenGL=NO GhcLibsWithGLUT=NO that still works or do I have to do it by hand? The OpenGL/GLUT/OpenAL packages (and a few others) are enabled automatically if the right headers/libs are found during the configuration stage, otherwise they are disabled. If you don't want these packages to be built, even if the right headers/libs are available on the build platform, just give --disable-opengl/--disable-glut/--disable-openal options to configure. Cheers, S. ___ 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 Peyton-Jones [EMAIL PROTECTED] writes: I think I've fixed this (on the head anyway; simon will merge to branch shortly). Care to try again? Yup, the toplevel rigid type-variable problem seems to have been fixed, thanks. nhc98 now builds as expected with ghc-6.4. BTW, there seems to be a small documentation-packaging fault in the linux binary distribution. You may be aware of it already. $ make install ... if test -d share/html; \ then cp -r share/html/* /usr/malcolm/local/share/ghc-6.4.20050227/html; \ fi for i in share/*.ps; do \ cp $i /usr/malcolm/local/share/ghc-6.4.20050227 ; \ done cp: cannot stat `share/*.ps': No such file or directory $ Regards, Malcolm ___ 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 (breakage on x86-64)
Donald Bruce Stewart wrote: bstrand: Simon Marlow wrote: Just to let you know, there are a number of open bug reports for GHC on the x86_64 platform, which seem to indicate some kind of occasional memory/GC problem. I'm probably not going to be able to track this down until after the 6.4 release, but we'll put out a patch as soon as we have one. Here's an error building ghc-6.4.20050224ghc-6.4.20050224 via Anders' Debian x86-64 ghc, although it doesn't look like a memory/GC problem to my untrained eye: ==fptools== make boot - --no-print-directory -r; in /home/bstrand/src/ghc-6.4.20050224/ghc/lib/compat ../../../glafp-utils/mkdependC/mkdependC -f .depend-I../../includes -- -O-- cbits/directory.c cbits/rawSystem.c /usr/bin/ghc -M -optdep-f -optdep.depend -osuf o-H16m -O -H64m -O -I. -Rghc-timing -I../../../libraries -fglasgow-exts -no-recomp Compat/Directory.hs Compat/RawSystem.hs Distribution/Compat/ReadP.hs Distribution/Extension.hs Distribution/GetOpt.hs Distribution/InstalledPackageInfo.hs Distribution/License.hs Distribution/Package.hs Distribution/ParseUtils.hs Distribution/Setup.hs Distribution/Version.hs System/Directory/Internals.hs ghc: 15653112 bytes, 5 GCs, 73168/73168 avg/max bytes residency (1 samples), 63M in use, 0.00 INIT (0.00 elapsed), 0.12 MUT (5.14 elapsed), 0.03 GC (0.57 elapsed) :ghc make all rm -f System/Directory/Internals.o; if [ ! -d System/Directory/Internals_split ]; then mkdir System/Directory/Internals_split; else /usr/bin/find System/Directory/Internals_split -name '*.o' -print | xargs rm -f __rm_food; fi; /usr/bin/ghc -H16m -O -H64m -O -I. -Rghc-timing -I../../../libraries -fglasgow-exts -no-recomp -split-objs-c System/Directory/Internals.hs-o System/Directory/Internals.o -ohi System/Directory/Internals.hi warning: don't know how to split object files on this architecture ghc: 76094368 bytes, 11 GCs, 2187736/4575048 avg/max bytes residency (3 samples), 66M in use, 0.00 INIT (0.00 elapsed), 0.87 MUT (13.77 elapsed), 0.14 GC (1.40 elapsed) :ghc ( cd System/Directory/Internals_split; rm -f ld.script; touch ld.script; echo INPUT( *.o ) ld.script; /usr/bin/ld -r -x -o ../Internals.old.script; ); /usr/bin/ld:ld.script: file format not recognized; treating as linker script /usr/bin/ld:ld.script:1: syntax error make[4]: *** [System/Directory/Internals.o] Error 1 make[3]: *** [boot] Error 2 make[2]: *** [boot] Error 1 make[1]: *** [boot] Error 1 make[1]: Leaving directory `/home/bstrand/src/ghc-6.4.20050224/ghc' make: *** [build] Error 1 Can you try building with SplitObjs=NO ? Wolfgang, Ryan - that looks like a splitter problem, no? (The splitter is more of a dark art than the evil mangler, I propose we name it the diabolical splitter from now on.) -- Don Using SplitObjs=NO gives out many warnings then finally dies with: ../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -H16m -O -H64m -O -O2 -static -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include RtsUtils.h -#include StgRun.h -#includeSchedule.h -#include Printer.h -#include Sanity.h -#include STM.h -#include Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h-#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h -#include Apply.h -fvia-C -dcmm-lint -c StgCRun.c -o StgCRun.o In file included from ../includes/Stg.h:149, from StgCRun.c:67: ../includes/Regs.h:213: warning: call-clobbered register used for global register variable ../includes/Regs.h:342: warning: call-clobbered register used for global register variable /tmp/ghc13908.s: Assembler messages: /tmp/ghc13908.s:20: Error: suffix or operands invalid for `jmp' make[2]: *** [StgCRun.o] Error 1 make[1]: *** [all] Error 1 make[1]: Leaving directory `/home/bstrand/src/ghc-6.4.20050224/ghc' make: *** [build] Error 1 Brian ___ 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 (breakage on x86-64)
bstrand: Donald Bruce Stewart wrote: bstrand: Simon Marlow wrote: Just to let you know, there are a number of open bug reports for GHC on the x86_64 platform, which seem to indicate some kind of occasional memory/GC problem. I'm probably not going to be able to track this down until after the 6.4 release, but we'll put out a patch as soon as we have one. Here's an error building ghc-6.4.20050224ghc-6.4.20050224 via Anders' Debian x86-64 ghc, although it doesn't look like a memory/GC problem to my untrained eye: ==fptools== make boot - --no-print-directory -r; in /home/bstrand/src/ghc-6.4.20050224/ghc/lib/compat ../../../glafp-utils/mkdependC/mkdependC -f .depend-I../../includes -- -O-- cbits/directory.c cbits/rawSystem.c /usr/bin/ghc -M -optdep-f -optdep.depend -osuf o-H16m -O -H64m -O -I. -Rghc-timing -I../../../libraries -fglasgow-exts -no-recomp Compat/Directory.hs Compat/RawSystem.hs Distribution/Compat/ReadP.hs Distribution/Extension.hs Distribution/GetOpt.hs Distribution/InstalledPackageInfo.hs Distribution/License.hs Distribution/Package.hs Distribution/ParseUtils.hs Distribution/Setup.hs Distribution/Version.hs System/Directory/Internals.hs ghc: 15653112 bytes, 5 GCs, 73168/73168 avg/max bytes residency (1 samples), 63M in use, 0.00 INIT (0.00 elapsed), 0.12 MUT (5.14 elapsed), 0.03 GC (0.57 elapsed) :ghc make all rm -f System/Directory/Internals.o; if [ ! -d System/Directory/Internals_split ]; then mkdir System/Directory/Internals_split; else /usr/bin/find System/Directory/Internals_split -name '*.o' -print | xargs rm -f __rm_food; fi; /usr/bin/ghc -H16m -O -H64m -O -I. -Rghc-timing -I../../../libraries -fglasgow-exts -no-recomp -split-objs-c System/Directory/Internals.hs-o System/Directory/Internals.o -ohi System/Directory/Internals.hi warning: don't know how to split object files on this architecture ghc: 76094368 bytes, 11 GCs, 2187736/4575048 avg/max bytes residency (3 samples), 66M in use, 0.00 INIT (0.00 elapsed), 0.87 MUT (13.77 elapsed), 0.14 GC (1.40 elapsed) :ghc ( cd System/Directory/Internals_split; rm -f ld.script; touch ld.script; echo INPUT( *.o ) ld.script; /usr/bin/ld -r -x -o ../Internals.old.script; ); /usr/bin/ld:ld.script: file format not recognized; treating as linker script /usr/bin/ld:ld.script:1: syntax error make[4]: *** [System/Directory/Internals.o] Error 1 make[3]: *** [boot] Error 2 make[2]: *** [boot] Error 1 make[1]: *** [boot] Error 1 make[1]: Leaving directory `/home/bstrand/src/ghc-6.4.20050224/ghc' make: *** [build] Error 1 Can you try building with SplitObjs=NO ? Wolfgang, Ryan - that looks like a splitter problem, no? (The splitter is more of a dark art than the evil mangler, I propose we name it the diabolical splitter from now on.) -- Don Using SplitObjs=NO gives out many warnings then finally dies with: ../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -H16m -O -H64m -O -O2 -static -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include RtsUtils.h -#include StgRun.h -#includeSchedule.h -#include Printer.h -#include Sanity.h -#include STM.h -#include Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h-#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h -#include Apply.h -fvia-C -dcmm-lint -c StgCRun.c -o StgCRun.o In file included from ../includes/Stg.h:149, from StgCRun.c:67: ../includes/Regs.h:213: warning: call-clobbered register used for global register variable ../includes/Regs.h:342: warning: call-clobbered register used for global register variable /tmp/ghc13908.s: Assembler messages: /tmp/ghc13908.s:20: Error: suffix or operands invalid for `jmp' make[2]: *** [StgCRun.o] Error 1 make[1]: *** [all] Error 1 make[1]: Leaving directory `/home/bstrand/src/ghc-6.4.20050224/ghc' make: *** [build] Error 1 Are you building unregisterised? Those messages about global register variables (I think) imply that you are not -- and we haven't yet got x86_64 (terrible name, I much prefer amd64) registerised. Looks like you might even have found the point where registerisation breaks. Try building unregisterised: GhcUnregisterised=YES just as the .hc bootstrap compiler was built. -- Don ___ 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 (breakage on x86-64)
Simon Marlow wrote: Just to let you know, there are a number of open bug reports for GHC on the x86_64 platform, which seem to indicate some kind of occasional memory/GC problem. I'm probably not going to be able to track this down until after the 6.4 release, but we'll put out a patch as soon as we have one. Here's an error building ghc-6.4.20050224ghc-6.4.20050224 via Anders' Debian x86-64 ghc, although it doesn't look like a memory/GC problem to my untrained eye: ==fptools== make boot - --no-print-directory -r; in /home/bstrand/src/ghc-6.4.20050224/ghc/lib/compat ../../../glafp-utils/mkdependC/mkdependC -f .depend-I../../includes -- -O-- cbits/directory.c cbits/rawSystem.c /usr/bin/ghc -M -optdep-f -optdep.depend -osuf o-H16m -O -H64m -O -I. -Rghc-timing -I../../../libraries -fglasgow-exts -no-recomp Compat/Directory.hs Compat/RawSystem.hs Distribution/Compat/ReadP.hs Distribution/Extension.hs Distribution/GetOpt.hs Distribution/InstalledPackageInfo.hs Distribution/License.hs Distribution/Package.hs Distribution/ParseUtils.hs Distribution/Setup.hs Distribution/Version.hs System/Directory/Internals.hs ghc: 15653112 bytes, 5 GCs, 73168/73168 avg/max bytes residency (1 samples), 63M in use, 0.00 INIT (0.00 elapsed), 0.12 MUT (5.14 elapsed), 0.03 GC (0.57 elapsed) :ghc make all rm -f System/Directory/Internals.o; if [ ! -d System/Directory/Internals_split ]; then mkdir System/Directory/Internals_split; else /usr/bin/find System/Directory/Internals_split -name '*.o' -print | xargs rm -f __rm_food; fi; /usr/bin/ghc -H16m -O -H64m -O -I. -Rghc-timing -I../../../libraries -fglasgow-exts -no-recomp -split-objs-c System/Directory/Internals.hs-o System/Directory/Internals.o -ohi System/Directory/Internals.hi warning: don't know how to split object files on this architecture ghc: 76094368 bytes, 11 GCs, 2187736/4575048 avg/max bytes residency (3 samples), 66M in use, 0.00 INIT (0.00 elapsed), 0.87 MUT (13.77 elapsed), 0.14 GC (1.40 elapsed) :ghc ( cd System/Directory/Internals_split; rm -f ld.script; touch ld.script; echo INPUT( *.o ) ld.script; /usr/bin/ld -r -x -o ../Internals.old.script; ); /usr/bin/ld:ld.script: file format not recognized; treating as linker script /usr/bin/ld:ld.script:1: syntax error make[4]: *** [System/Directory/Internals.o] Error 1 make[3]: *** [boot] Error 2 make[2]: *** [boot] Error 1 make[1]: *** [boot] Error 1 make[1]: Leaving directory `/home/bstrand/src/ghc-6.4.20050224/ghc' make: *** [build] Error 1 ___ 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 (breakage on x86-64)
bstrand: Simon Marlow wrote: Just to let you know, there are a number of open bug reports for GHC on the x86_64 platform, which seem to indicate some kind of occasional memory/GC problem. I'm probably not going to be able to track this down until after the 6.4 release, but we'll put out a patch as soon as we have one. Here's an error building ghc-6.4.20050224ghc-6.4.20050224 via Anders' Debian x86-64 ghc, although it doesn't look like a memory/GC problem to my untrained eye: ==fptools== make boot - --no-print-directory -r; in /home/bstrand/src/ghc-6.4.20050224/ghc/lib/compat ../../../glafp-utils/mkdependC/mkdependC -f .depend-I../../includes -- -O-- cbits/directory.c cbits/rawSystem.c /usr/bin/ghc -M -optdep-f -optdep.depend -osuf o-H16m -O -H64m -O -I. -Rghc-timing -I../../../libraries -fglasgow-exts -no-recomp Compat/Directory.hs Compat/RawSystem.hs Distribution/Compat/ReadP.hs Distribution/Extension.hs Distribution/GetOpt.hs Distribution/InstalledPackageInfo.hs Distribution/License.hs Distribution/Package.hs Distribution/ParseUtils.hs Distribution/Setup.hs Distribution/Version.hs System/Directory/Internals.hs ghc: 15653112 bytes, 5 GCs, 73168/73168 avg/max bytes residency (1 samples), 63M in use, 0.00 INIT (0.00 elapsed), 0.12 MUT (5.14 elapsed), 0.03 GC (0.57 elapsed) :ghc make all rm -f System/Directory/Internals.o; if [ ! -d System/Directory/Internals_split ]; then mkdir System/Directory/Internals_split; else /usr/bin/find System/Directory/Internals_split -name '*.o' -print | xargs rm -f __rm_food; fi; /usr/bin/ghc -H16m -O -H64m -O -I. -Rghc-timing -I../../../libraries -fglasgow-exts -no-recomp -split-objs-c System/Directory/Internals.hs-o System/Directory/Internals.o -ohi System/Directory/Internals.hi warning: don't know how to split object files on this architecture ghc: 76094368 bytes, 11 GCs, 2187736/4575048 avg/max bytes residency (3 samples), 66M in use, 0.00 INIT (0.00 elapsed), 0.87 MUT (13.77 elapsed), 0.14 GC (1.40 elapsed) :ghc ( cd System/Directory/Internals_split; rm -f ld.script; touch ld.script; echo INPUT( *.o ) ld.script; /usr/bin/ld -r -x -o ../Internals.old.script; ); /usr/bin/ld:ld.script: file format not recognized; treating as linker script /usr/bin/ld:ld.script:1: syntax error make[4]: *** [System/Directory/Internals.o] Error 1 make[3]: *** [boot] Error 2 make[2]: *** [boot] Error 1 make[1]: *** [boot] Error 1 make[1]: Leaving directory `/home/bstrand/src/ghc-6.4.20050224/ghc' make: *** [build] Error 1 Can you try building with SplitObjs=NO ? Wolfgang, Ryan - that looks like a splitter problem, no? (The splitter is more of a dark art than the evil mangler, I propose we name it the diabolical splitter from now on.) -- Don ___ 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 (breakage on x86-64)
[...] warning: don't know how to split object files on this architecture [...] Wolfgang, Ryan - that looks like a splitter problem, no? Definitely. Looks like there is no splitter for x86-64. SplitObjs=NO is definitely required. (The splitter is more of a dark art than the evil mangler, I propose we name it the diabolical splitter from now on.) Hmmm, even 'diabolical' doesn't quite seem to capture it. While the Evil Mangler is Evil, it is not Entirely Evil. We have to ask ourselves, what would the world be like without the Evil Mangler? Can there be Good without Evil? Would the Noble Code Generator (NCG) still be Noble if there were no Evil Mangler? The Evil Mangler is the kind of Evil that still has honor. Years after the forces of Good have finally prevailed, the broken remains of the Evil Mangler will still be proudly displayed in the castle's repositories, and the descendants of the Knights who overcame It will utter Its name with respect for an honoured adversary. The Satanic Splitter however, or whatever that Nameless Nemesis should be called, is an enemy of a different kind. Instead of attacking directly and honestly, it relies on treachery to destroy its foes. It lurks in the shadow of its big brother, the Evil Mangler, and it seeks to make the unsuspecting world believe that it is relatively benign. It does nothing that is essential to The Cause, and it tells its unsuspecting victims that can say SplitObjs=NO at any time, but when they do, it punishes them with multi-megabyte executables. And it cannot even do its evil deeds by itself - without the help of a Traitor in the code generator who puts split markers into the Code, the Splitter would be helpless. And I'm quite convinced that the Splitter's agents infiltrated Apple to make sure that the dead-stripping code in Apple's linker runs really slow. If Apple's code was efficient, the Splitter would already be banished from the Land of Apples. So go ahead and call the Splitter any bad names you like :-). Cheers, Wolfgang ___ 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 (breakage on suse 9.2 x86 or x86-64)
Just a quick comment on a couple of things Brian Strand writes: Or is ghc/Haskell established enough that the existence of some Haskell compiler is taken for granted nowadays? Ghc is not written in pure Haskell - it is written in Ghc Haskell, i.e. it uses many extensions and internal libraries not available in all other Haskell implementations. Thus, you really need ghc to bootstrap ghc. Would it be unreasonable to include the unregisterised .hc files with a source distribution (or .hc files for popular platforms), so that a Haskell novice such as myself could do a ./configure make make install? If configure detected no ghc, perhaps it could do the bootstrap automagically. This is what nhc98 does - supplies platform independent .hc files for bootstrapping via gcc if no existing Haskell compiler is installed. However, nhc98 uses a bytecode VM, so it produces code that is 3x - 15x slower than ghc, (currently) lacks many of the lower-level libraries, and implements very few language extensions. Thus it has a smaller user base, and smaller maintainer base too (therefore not much ongoing development). Ideally, if ghc were implemented in something closer to Haskell'98, it would be possible to double-bootstrap up from gcc - nhc98 - ghc unregisterised - ghc registerised, on almost any new platform. But the amount of work required to 98-ify ghc is considerable (there are 148 kLoC to check), and it is hard to say whether it would be worthwhile. Maybe someone fancies tackling it as a medium-size project? Regards, Malcolm ___ 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 (breakage on suse 9.2 x86 or x86-64)
On 24 February 2005 11:12, Malcolm Wallace wrote: Ideally, if ghc were implemented in something closer to Haskell'98, it would be possible to double-bootstrap up from gcc - nhc98 - ghc unregisterised - ghc registerised, on almost any new platform. But the amount of work required to 98-ify ghc is considerable (there are 148 kLoC to check), and it is hard to say whether it would be worthwhile. Maybe someone fancies tackling it as a medium-size project? It's feasible, but unfortunately probably not practical. Not only would someone have to do the work, we'd have to maintain the Haskell 98 version too. That's yet another way to build GHC, and there are already too many variables for us to test them all. However, a more reasonable approach might be to remove the platform dependencies from GHC and the libraries it requires for bootstrapping. That is, make it so that unregisterised .hc files are platform-independent. I think we used to have this property in the distant past, but it got lost somewhere along the way. It would mean banishing platform differences into C code wherever necessary, which would result in more C code and less Haskell code, but it might be worthwhile. 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 (breakage on suse 9.2 x86or x86-64)
On 24 February 2005 02:38, Wolfgang Thaller wrote: So maybe x86-Linux needs a ghc binary with as few library dependencies as possible, to facilitate bootstrapping on different Linux distros? That's a good idea. GHCi doesn't work if the GHC binary is linked with -static, so we'll have to make a separate statically-linked binary distribution, though. 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 (breakage on suse 9.2 x86 or x86-64)
Jens Petersen wrote: Brian Strand wrote: Unfortunately I'm still stuck on x86-64, since there are no official binaries to bootstrap from on that platform. But at least I have a ghc to play with while waiting for x86-64 to become official. There is a x86_64 build already in Fedora Haskell. Perhaps you can try it? It may work for you. Jens I found some x86-64 binaries thanks to Anders' helpful suggestion (posted yesterday) at: http://debian-amd64.alioth.debian.org/pure64/pool/unstable/main/amd64/g/ghc6/ Thanks, Brian ___ 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 (breakage on suse 9.2 x86 or x86-64)
Wolfgang Thaller wrote: Brian Strand wrote: Not being intimately familiar with ghc internals, I don't know how much work this is, and whether the implementation cost exceeds the benefit (easier installation for Haskell novices like me). My guess is that for GHC, it won't work; the .hc files are really too low-level. Just about the only thing that's not already decided in the .hc files (that I can think of now) is the actual names of the libraries that the app links to. We'd need to supply .hc files for nearly as many platforms as we need binaries for. So maybe x86-Linux needs a ghc binary with as few library dependencies as possible, to facilitate bootstrapping on different Linux distros? That seems like a very good idea to me; for bootstrapping, one doesn't need ghci, readline, ncurses, etc. From ldd ghc-6.4.20050221, it looks like the only really essential non-libc library is libgmp (which I'm guessing is used for Integer operations at least, and these are hard to do without...). ___ 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 (breakage on suse 9.2 x86 or x86-64)
On Thu, Feb 24, 2005 at 11:12:06AM +, Malcolm Wallace wrote: Ideally, if ghc were implemented in something closer to Haskell'98, it would be possible to double-bootstrap up from gcc - nhc98 - ghc unregisterised - ghc registerised, on almost any new platform. But the amount of work required to 98-ify ghc is considerable (there are 148 kLoC to check), and it is hard to say whether it would be worthwhile. Maybe someone fancies tackling it as a medium-size project? It might be easier to extend nhc98 with some of the extensions needed by ghc. Actually, how difficult would it be to translate ghc core to something nhc could use? Then we could use the ghc front end with nhcs back end. I am not sure what nhcs intermediate language looks like, but ghc core is similar enough to desugared haskell that it seems like it should be possible. The main issue I can think of is a mismatch in the primitive operators, so one would probably have to use ghcs front end with nhcs prelude/other libraries. John -- John Meacham - repetae.netjohn ___ 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 (breakage on suse 9.2 x86 or x86-64)
Jens Petersen wrote: Brian Strand wrote: Hello, I'm having some serious issues getting GHC to run on Suse 9.2/x86 (or x86-64 for that matter, although I didn't really expect that to work without some pain and suffering). I've had no luck with 6.2.2, or any 6.4 release candidate. Here is a typical example: after doing a ./configure; make in-place, I get the following: /home/bstrand/haskell/ghc-6.4.20050221/lib/i386-unknown-linux/ghc-6.4.20050221: error while loading shared libraries: libreadline.so.4: cannot open shared object file: No such file or directory Fair enough; rpm -q readline gives me readline-5.0-1.2. How about just installing readline4 (or whatever package provides libreadline.so.4)? :) Jens I was trying to do the right thing and report whatever was broken in the ghc bootstrapping process :) But shortly after my post I broke down and installed readline-compat (which on Suse 9.2 luckily happens to have libreadline.so.4), which fixes my problem on x86. Unfortunately I'm still stuck on x86-64, since there are no official binaries to bootstrap from on that platform. But at least I have a ghc to play with while waiting for x86-64 to become official. Thanks for the assistance, Brian ___ 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 (breakage on suse 9.2 x86 or x86-64)
Brian Strand wrote: Jens Petersen wrote: Brian Strand wrote: Hello, I'm having some serious issues getting GHC to run on Suse 9.2/x86 (or x86-64 for that matter, although I didn't really expect that to work without some pain and suffering). I've had no luck with 6.2.2, or any 6.4 release candidate. Here is a typical example: after doing a ./configure; make in-place, I get the following: /home/bstrand/haskell/ghc-6.4.20050221/lib/i386-unknown-linux/ghc-6.4.20050221: error while loading shared libraries: libreadline.so.4: cannot open shared object file: No such file or directory Fair enough; rpm -q readline gives me readline-5.0-1.2. How about just installing readline4 (or whatever package provides libreadline.so.4)? :) Jens I was trying to do the right thing and report whatever was broken in the ghc bootstrapping process :) But shortly after my post I broke down and installed readline-compat (which on Suse 9.2 luckily happens to have libreadline.so.4), which fixes my problem on x86. Unfortunately I'm still stuck on x86-64, since there are no official binaries to bootstrap from on that platform. But at least I have a ghc to play with while waiting for x86-64 to become official. Thanks for the assistance, Brian There are some debian packages of ghc 6.2.2 and related stuff for amd64 located here: http://debian-amd64.alioth.debian.org/pure64/pool/unstable/main/amd64/g/ghc6/ Hopefully you can find some way to convert these to a format you can install (there are programs for converting debian packages to rpms I think, but I can't remember what they are called - google is your friend). After installing this binary, bootstrapping an (at least unregistered) amd64 ghc 6.4 should be possible. Cheers, Anders ___ 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 (breakage on suse 9.2 x86 or x86-64)
Anders Höckersten wrote: ... There are some debian packages of ghc 6.2.2 and related stuff for amd64 located here: http://debian-amd64.alioth.debian.org/pure64/pool/unstable/main/amd64/g/ghc6/ Hopefully you can find some way to convert these to a format you can install (there are programs for converting debian packages to rpms I think, but I can't remember what they are called - google is your friend). After installing this binary, bootstrapping an (at least unregistered) amd64 ghc 6.4 should be possible. Cheers, Anders Thanks a lot! For anyone who runs into the same problem, here is what I did: 1. Converted to an rpm via alien -r ghc6_6.2.2-3_amd64.deb 2. Installed the resulting rpm. 3. When I tried to run ghc6, I got /usr/lib/ghc-6.2.2 # /usr/bin/ghc6 ghc-6.2.2: Can't find package.conf as /usr/lib/ghc-6.2.2/ghc/driver/package.conf.inplace Other similar errors cropped up while trying to bootstrap. So, some crude symlink hackery: cd /usr/lib/ghc-6.2.2 ln -s . ghc ln -s . driver ln -s package.conf.shipped package.conf.inplace # now we have a /usr/lib/ghc-6.2.2/ghc/driver/package.conf.inplace mkdir utils ln -s .. utils/unlit # now we have a /usr/lib/ghc-6.2.2/utils/unlit/unlit ln -s ghc6 /usr/bin/ghc # so ./configure finds ghc This has gotten me quite a ways into the 6.2.2 compile; I'm still waiting to see if it completes successfully. Brian ___ 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 (breakage on suse 9.2 x86 or x86-64)
On 23 February 2005 11:01, Brian Strand wrote: Thanks a lot! For anyone who runs into the same problem, here is what I did: 1. Converted to an rpm via alien -r ghc6_6.2.2-3_amd64.deb 2. Installed the resulting rpm. 3. When I tried to run ghc6, I got /usr/lib/ghc-6.2.2 # /usr/bin/ghc6 ghc-6.2.2: Can't find package.conf as /usr/lib/ghc-6.2.2/ghc/driver/package.conf.inplace Other similar errors cropped up while trying to bootstrap. So, some crude symlink hackery: cd /usr/lib/ghc-6.2.2 ln -s . ghc ln -s . driver ln -s package.conf.shipped package.conf.inplace # now we have a /usr/lib/ghc-6.2.2/ghc/driver/package.conf.inplace mkdir utils ln -s .. utils/unlit # now we have a /usr/lib/ghc-6.2.2/utils/unlit/unlit ln -s ghc6 /usr/bin/ghc # so ./configure finds ghc This has gotten me quite a ways into the 6.2.2 compile; I'm still waiting to see if it completes successfully. Just to let you know, there are a number of open bug reports for GHC on the x86_64 platform, which seem to indicate some kind of occasional memory/GC problem. I'm probably not going to be able to track this down until after the 6.4 release, but we'll put out a patch as soon as we have one. 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 (breakage on suse 9.2 x86or x86-64)
On 22 February 2005 20:05, Brian Strand wrote: I'm having some serious issues getting GHC to run on Suse 9.2/x86 (or x86-64 for that matter, although I didn't really expect that to work without some pain and suffering). I've had no luck with 6.2.2, or any 6.4 release candidate. Here is a typical example: after doing a ./configure; make in-place, I get the following: /home/bstrand/haskell/ghc-6.4.20050221/lib/i386-unknown-linux/ghc-6.4.20 050221: error while loading shared libraries: libreadline.so.4: cannot open shared object file: No such file or directory Fair enough; rpm -q readline gives me readline-5.0-1.2. So off to the sources I go: cd ~/src/ghc-6.4.20050221 ./configure ... configure: error: GHC is required unless bootstrapping from .hc files. After reading through most of the GHC building guide (paying particular attention to section 10), I try: ./configure --enable-hc-boot You actually need the .hc source files too, which don't come with the source distribution because they have to be built for each target platform. That section of the Building Guide wasn't really clear enough on this issue, so sorry if that meant you wasted some time. We've since updated the instructions in the Building Guide. For compiling GHC on a platform for which you don't already have a GHC binary, the Approved Method is to go through the unregisterised bootstrap instructions in section 10.2. It's possible to do a registerised bootstrap, which would be shorter, but we haven't tested and documented the procedure. 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 (breakage on suse 9.2 x86 or x86-64)
Simon Marlow wrote: On 22 February 2005 20:05, Brian Strand wrote: [ snipped ] You actually need the .hc source files too, which don't come with the source distribution because they have to be built for each target platform. That section of the Building Guide wasn't really clear enough on this issue, so sorry if that meant you wasted some time. We've since updated the instructions in the Building Guide. For compiling GHC on a platform for which you don't already have a GHC binary, the Approved Method is to go through the unregisterised bootstrap instructions in section 10.2. It's possible to do a registerised bootstrap, which would be shorter, but we haven't tested and documented the procedure. Cheers, Simon Thanks, good to know; I'll read through 10.2 more carefully. I didn't think I'd need to cross-compile x86-linux to x86-linux. Would it be unreasonable to include the unregisterised .hc files with a source distribution (or .hc files for popular platforms), so that a Haskell novice such as myself could do a ./configure make make install? If configure detected no ghc, perhaps it could do the bootstrap automagically. Or is ghc/Haskell established enough that the existence of some Haskell compiler is taken for granted nowadays? Thanks again to everyone on the list for the helpful advice! Brian ___ 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 (breakage on suse 9.2 x86 or x86-64)
Thanks, good to know; I'll read through 10.2 more carefully. I didn't think I'd need to cross-compile x86-linux to x86-linux. You don't need to - the recommended way is to download a binary version. If you don't like using binary distributions, then use it for bootstrapping only, i.e. use it to build a ghc of your choice and then delete it again. This is just like what you usually do when you install gcc on your box for the first time. Would it be unreasonable to include the unregisterised .hc files with a source distribution (or .hc files for popular platforms), so that a Haskell novice such as myself could do a ./configure make make install? If configure detected no ghc, perhaps it could do the bootstrap automagically. Well, the contents of the .hc files heavily depend on the results of ./configure - so unregistered .hc files still have to be tailor-made for the target platform. As far as registerised .hc files for popular platforms go, I fail to see the point. In what way is bootstrapping from platform-specific .hc files superior to installing a binary (apart from the fact that it takes longer and looks cooler)? It would be like shipping GCC as a bunch of x86 .s files. Cheers, Wolfgang ___ 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 (breakage on suse 9.2 x86 or x86-64)
Wolfgang Thaller wrote: Thanks, good to know; I'll read through 10.2 more carefully. I didn't think I'd need to cross-compile x86-linux to x86-linux. You don't need to - the recommended way is to download a binary version. If you don't like using binary distributions, then use it for bootstrapping only, i.e. use it to build a ghc of your choice and then delete it again. This is just like what you usually do when you install gcc on your box for the first time. I originally tried the binary distribution but ran into library issues. That is of course the obvious path to try, and try it I did. Rather than going straight to installing deprecated libraries, I tried to provide some feedback on ghc (especially since 6.4 RCs are out). Would it be unreasonable to include the unregisterised .hc files with a source distribution (or .hc files for popular platforms), so that a Haskell novice such as myself could do a ./configure make make install? If configure detected no ghc, perhaps it could do the bootstrap automagically. Well, the contents of the .hc files heavily depend on the results of ./configure - so unregistered .hc files still have to be tailor-made for the target platform. As far as registerised .hc files for popular platforms go, I fail to see the point. In what way is bootstrapping from platform-specific .hc files superior to installing a binary (apart from the fact that it takes longer and looks cooler)? It would be like shipping GCC as a bunch of x86 .s files. Cheers, Wolfgang I have no concern whatsoever with the appearance of coolness (or lack thereof). As stated above, I have no problem with installing a binary, but that option didn't work out at first, so, ghc being free software, I tried to compile it for my platform. When that failed, I decided to report back on my difficulties, hopefully helping anyone who runs into (and googles for) the same problem. (In fact at the moment I am doing exactly as you suggested, making a clean build of ghc via the binaries, so as not to clutter up our many Oracle boxen with (otherwise useless) backwards-compatibility readline libraries.) Regarding gcc, gcc binaries ship with or are available for every commonly used platform (and most uncommonly used platforms too); ghc is not (yet) in this position. I was fully aware of the parallel between distributing .s files with gcc and .hc files with ghc when I made this suggestion. Not being intimately familiar with ghc internals, I don't know how much work this is, and whether the implementation cost exceeds the benefit (easier installation for Haskell novices like me). ___ 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 (breakage on suse 9.2 x86 or x86-64)
Brian Strand wrote: I originally tried the binary distribution but ran into library issues. That is of course the obvious path to try, and try it I did. Rather than going straight to installing deprecated libraries, I tried to provide some feedback on ghc (especially since 6.4 RCs are out). Well, it seems like I should have read your previous posts more attentively before mentioning the recommended way of doing things again - sorry. Not being intimately familiar with ghc internals, I don't know how much work this is, and whether the implementation cost exceeds the benefit (easier installation for Haskell novices like me). My guess is that for GHC, it won't work; the .hc files are really too low-level. Just about the only thing that's not already decided in the .hc files (that I can think of now) is the actual names of the libraries that the app links to. We'd need to supply .hc files for nearly as many platforms as we need binaries for. So maybe x86-Linux needs a ghc binary with as few library dependencies as possible, to facilitate bootstrapping on different Linux distros? Cheers, Wolfgang ___ 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 (breakage on suse 9.2 x86 or x86-64)
Brian Strand wrote: Unfortunately I'm still stuck on x86-64, since there are no official binaries to bootstrap from on that platform. But at least I have a ghc to play with while waiting for x86-64 to become official. There is a x86_64 build already in Fedora Haskell. Perhaps you can try it? It may work for you. Jens ___ 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 (breakage on suse 9.2 x86 or x86-64)
Hello, I'm having some serious issues getting GHC to run on Suse 9.2/x86 (or x86-64 for that matter, although I didn't really expect that to work without some pain and suffering). I've had no luck with 6.2.2, or any 6.4 release candidate. Here is a typical example: after doing a ./configure; make in-place, I get the following: /home/bstrand/haskell/ghc-6.4.20050221/lib/i386-unknown-linux/ghc-6.4.20050221: error while loading shared libraries: libreadline.so.4: cannot open shared object file: No such file or directory Fair enough; rpm -q readline gives me readline-5.0-1.2. So off to the sources I go: cd ~/src/ghc-6.4.20050221 ./configure ... configure: error: GHC is required unless bootstrapping from .hc files. After reading through most of the GHC building guide (paying particular attention to section 10), I try: ./configure --enable-hc-boot After a few minutes, this dies with: ==fptools== make boot -wr; in /home/bstrand/src/ghc-6.4.20050221/libraries/base touch GHC/PrimopWrappers.hs make[2]: *** No rule to make target `System/CPUTime_hsc.c', needed by `depend'. Stop. make[1]: *** [boot] Error 1 make[1]: Leaving directory `/home/bstrand/src/ghc-6.4.20050221/libraries' make: *** [build] Error 1 ./configure --enable-hc-boot --enable-hc-boot-unregisterised fails with the same error. Running distrib/hc-build runs for much longer, but then ends with the now familiar: ===fptools== Recursively making `boot' in base haskell98 template-haskell unix Cabal parsec readline ... PWD = /home/bstrand/src/ghc-6.4.20050221/libraries ==fptools== gmake boot -wr; in /home/bstrand/src/ghc-6.4.20050221/libraries/base gmake[1]: *** No rule to make target `System/CPUTime_hsc.c', needed by `depend'. Stop. gmake: *** [boot] Error 1 gmake: Leaving directory `/home/bstrand/src/ghc-6.4.20050221/libraries' Having spent about 10 hours on it over the weekend, I decided it was time to call in the pros. So, any advice on getting a working ghc on Suse 9.2 x86 and/or x86-64 would be greatly appreciated. ___ 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 (breakage on suse 9.2 x86 or x86-64)
Brian Strand wrote: Hello, I'm having some serious issues getting GHC to run on Suse 9.2/x86 (or x86-64 for that matter, although I didn't really expect that to work without some pain and suffering). I've had no luck with 6.2.2, or any 6.4 release candidate. Here is a typical example: after doing a ./configure; make in-place, I get the following: /home/bstrand/haskell/ghc-6.4.20050221/lib/i386-unknown-linux/ghc-6.4.20050221: error while loading shared libraries: libreadline.so.4: cannot open shared object file: No such file or directory Fair enough; rpm -q readline gives me readline-5.0-1.2. How about just installing readline4 (or whatever package provides libreadline.so.4)? :) Jens ___ 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 19 February 2005 16:40, Judah Jacobson wrote: Compiling on OS X 10.2.8 (using gcc 3.1, ghc-6.2.2) gave an error on ghc/rts/Linker.c. The tarball includes a bogus version of ghc/includes/ghcplatform.h, which from what I can tell ought to be generated by make. Deleting the file and re-making seemed to work for a while. (Also, should that file be removed by make clean? It doesn't seem to be...) Thanks, I've now fixed that. 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
2 issues (6.4.20050218):
Compiling on OS X 10.2.8 (using gcc 3.1, ghc-6.2.2) gave an error on
ghc/rts/Linker.c. The tarball includes a bogus version of
ghc/includes/ghcplatform.h, which from what I can tell ought to be
generated by make. Deleting the file and re-making seemed to work for
a while. (Also, should that file be removed by make clean? It
doesn't seem to be...)
Later on in the compilation, though, I got another error (pasted
below) on ghc/rts/Apply.cmm.
Thanks,
-Judah
../../ghc/compiler/ghc-inplace -H16m -O -O2 -static -I. -#include
Prelude.h -#include Rts.h -#include RtsFlags.h -#include RtsUtils.h
-#include StgRun.h -#include Schedule.h -#include Printer.h -#include
Sanity.h -#include STM.h -#include Storage.h -#include SchedAPI.h
-#include Timer.h -#include Itimer.h -#include ProfHeap.h -#include
LdvProfile.h -#include Profiling.h -#include Apply.h -fvia-C
-dcmm-lint -c Apply.cmm -o Apply.o
Apply.cmm:28: illegal external declaration, missing `;' after `section'
Apply.cmm:52: syntax error, found `1'
Apply.cmm:52: illegal method selector, found `*'
Apply.cmm:52: illegal method definition, missing `{' after `)'
Apply.cmm:53: illegal external declaration, missing `;' after `again'
Apply.cmm:53: illegal method definition, found `+'
Apply.cmm:53: illegal method definition, missing `{' after `]'
Apply.cmm:53: illegal external declaration, found `goto'
Apply.cmm:53: syntax error, found `0'
Apply.cmm:53: illegal method selector, found `*'
Apply.cmm:53: illegal method definition, missing `{' after `)'
Apply.cmm:53: illegal external declaration, found `default'
Apply.cmm:78: undefined type, found `bits32'
Apply.cmm:79: undefined type, found `bits32'
Apply.cmm:83: illegal expression, found `%'
Apply.cmm:90: illegal external declaration, found `if'
Apply.cmm:90: syntax error, found `Words'
Apply.cmm:90: illegal method selector, found `*'
Apply.cmm:96: undefined type, found `jump'
Apply.cmm:109: undefined type, found `bits32'
Apply.cmm:110: undefined type, found `bits32'
Apply.cmm:113: illegal external declaration, found `for'
Apply.cmm:115: syntax error, found `i'
Apply.cmm:115: illegal method selector, found `*'
Apply.cmm:115: illegal method definition, missing `{' after `]'
Apply.cmm:118: illegal external declaration, found `goto'
Apply.cmm:127: undefined type, found `bits32'
Apply.cmm:128: illegal expression, found `%'
Apply.cmm:129: undefined type, found `bits32'
Apply.cmm:130: illegal expression, found `%'
Apply.cmm:131: illegal external declaration, found `if'
Apply.cmm:132: illegal method selector, found `0'
Apply.cmm:132: illegal method definition, missing `{' after `)'
Apply.cmm:134: illegal external declaration, found `if'
Apply.cmm:135: illegal method selector, found `0'
Apply.cmm:135: illegal method definition, missing `{' after `)'
Apply.cmm:137: illegal external declaration, found `if'
Apply.cmm:138: syntax error, found `-'
Apply.cmm:138: illegal method selector, found `*'
Apply.cmm:138: illegal method definition, missing `{' after `)'
Apply.cmm:141: undefined type, found `jump'
Apply.cmm:143: undefined type, found `jump'
Apply.cmm:144: illegal expression, found `%'
Apply.cmm:157: syntax error, found `0'
Apply.cmm:157: illegal function definition, found `)'
Apply.cmm:159: undefined type, found `bits32'
Apply.cmm:160: undefined type, found `bits32'
Apply.cmm:164: illegal expression, found `%'
Apply.cmm:172: illegal function prototype, found `('
Apply.cmm:172: illegal function definition, found `)'
Apply.cmm:172: undefined type, found `SIZEOF_StgHeader'
Apply.cmm:172: syntax error, found `+'
Apply.cmm:172: illegal method selector, found `)'
Apply.cmm:172: illegal method definition, missing `{' after `)'
Apply.cmm:174: syntax error, found `-'
Apply.cmm:174: illegal function definition, found `)'
Apply.cmm:175: undefined type, found `SIZEOF_StgHeader'
Apply.cmm:175: syntax error, found `+'
Apply.cmm:175: illegal method selector, found `)'
Apply.cmm:175: illegal method definition, missing `{' after `)'
Apply.cmm:186: undefined type, found `bits32'
Apply.cmm:187: undefined type, found `bits32'
Apply.cmm:190: illegal external declaration, found `for'
Apply.cmm:192: syntax error, found `i'
Apply.cmm:192: illegal method selector, found `*'
Apply.cmm:192: illegal method definition, missing `{' after `]'
Apply.cmm:195: illegal external declaration, found `goto'
Apply.cmm:204: undefined type, found `bits32'
Apply.cmm:205: illegal expression, found `%'
Apply.cmm:206: undefined type, found `bits32'
Apply.cmm:207: illegal expression, found `%'
Apply.cmm:208: illegal external declaration, found `if'
Apply.cmm:209: illegal method selector, found `0'
Apply.cmm:209: illegal method definition, missing `{' after `)'
Apply.cmm:211: illegal external declaration, found `if'
Apply.cmm:212: illegal method selector, found `0'
Apply.cmm:212: illegal method definition, missing `{' after `)'
Apply.cmm:214: illegal external declaration, found `if'
Apply.cmm:215: syntax error, found `-'
Apply.cmm:215: illegal
Re: GHC 6.4 release candidates available
OK, never mind on the second count; it turned out that Apple's gcc v3.1 preprocessor can't handle c-- files. Switching to gcc v.3.3 fixed that issue. -Judah On Sat, 19 Feb 2005 11:40:23 -0500, Judah Jacobson [EMAIL PROTECTED] wrote: 2 issues (6.4.20050218): Compiling on OS X 10.2.8 (using gcc 3.1, ghc-6.2.2) gave an error on ghc/rts/Linker.c. The tarball includes a bogus version of ghc/includes/ghcplatform.h, which from what I can tell ought to be generated by make. Deleting the file and re-making seemed to work for a while. (Also, should that file be removed by make clean? It doesn't seem to be...) Later on in the compilation, though, I got another error (pasted below) on ghc/rts/Apply.cmm. Thanks, -Judah ___ 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
Hi, Compiling 6.4.20050217 on Windows according to the book fails pretty early: snippet /cygdrive/c/ghc/ghc-6.2.2/bin//ghc -H16m -O -I. -Rghc-timing -I../../../librari es -fglasgow-exts -no-recomp-c Compat/RawSystem.hs -o Compat/RawSystem.o -o hi Compat/RawSystem.hi c:/DOCUME~1/JOSEFS~1/LOKALA~1/Temp/ghc3868.hc: In function `s3SQ_entry': c:/DOCUME~1/JOSEFS~1/LOKALA~1/Temp/ghc3868.hc:109: too many arguments to functio n `rawSystem' /snippet Cheers, /Josef ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
The GHC.PArr module [Was: Re: GHC 6.4 release candidates available]
Remi Turk rturk at science.uva.nl writes: ... I just noticed that in GHC.PArr, productP is defined wrongly productP :: (Num a) = [:a:] - a productP = foldP (*) 0 in (the likely) case that PArr is deprecated, you may want to add a DEPRECATED-pragma. I have just discovered that module recently through the paper An Approach to Fast Arrays in Haskell at http://www.cse.unsw.edu.au/~chak/papers/CK03.html I have found a bug in enumFromToP from http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/ base/GHC/PArr.hs?rev=1.7 enumFromThenToP 6 5 1 == [:6,5,4:] enumFromThenToP 10 8 1 == [:10,8,6:] Mentioning this on the friendly #haskell channel got me this suggestion: TheHunter: hmm, i think enumFromThenToP = ... replicateP (((z - x) `div` delta) + 1) delta does the trick. Regards, Peter Eriksen ___ 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 Thu, Feb 10, 2005 at 01:11:48PM -, Simon Marlow wrote: We are finally at the release candidate stage for GHC 6.4. Snapshots with versions 6.4.20050209 and later should be considered release candidates for 6.4. Source and Linux binary distributions are avaiable here: http://www.haskell.org/ghc/dist/stable/dist/ Please test if you're able to, and give us feedback. Thanks! Simons the GHC team Hi, I just noticed that in GHC.PArr, productP is defined wrongly productP :: (Num a) = [:a:] - a productP = foldP (*) 0 in (the likely) case that PArr is deprecated, you may want to add a DEPRECATED-pragma. Groetjes, Remi -- Nobody can be exactly like me. Even I have trouble doing it. ___ 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 14 February 2005 17:23, Ross Paterson wrote: If a program calls exitWith, runghc produces an extra line of output: *** Exception: exit: ExitSuccess or *** Exception: exit: ExitFailure 3 and then exits with status 0. It should do what a ghc-compiled program does: silently exit with the appropriate status. Fixed, thanks. 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 12 February 2005 07:32, John Meacham wrote: On Fri, Feb 11, 2005 at 10:49:56AM -, 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 ___ 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 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 ___ 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]
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 ___ 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]
On 11 February 2005 14:10, Simon David Foster wrote: 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 Another good bug, now fixed. Keep em coming! 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 13 February 2005 21:30, Stephane Bortzmeyer wrote: On Thu, Feb 10, 2005 at 01:11:48PM -, Simon Marlow [EMAIL PROTECTED] wrote a message of 17 lines which said: We are finally at the release candidate stage for GHC 6.4. Snapshots with versions 6.4.20050209 and later should be considered release candidates for 6.4. One of my platforms is still not recognized: preston:~/tmp/ghc-6.4.20050212 % ./configure configure: loading site script /usr/local/etc/config.site configure: creating cache /usr/local/var/tmp/config.cache checking build system type... sparc64-unknown-netbsd2.0.1 checking host system type... sparc64-unknown-netbsd2.0.1 checking target system type... sparc64-unknown-netbsd2.0.1 Unrecognised platform: sparc64-unknown-netbsd2.0.1 Now, I understand that it is a rather uncommon platform but I would like to run darcs on it. ghc runs fine on my other UltraSparc 10, which runs Debian/GNU/Linux. hugs runs fine on the Sparc/NetBSD. I've read http://www.haskell.org/ghc/docs/latest/html/building/sec-porting-ghc.htm l#SEC-BOOTING-FROM-HC but it is still unclear for me. When I compile ghc on the Sparc / Debian, no .hc files are produced. You really need to go through the cross-compilation process to get GHC built on your platform. Follow the instructions in section 10.2 to get an unregisterised build, and from that you can build GHC again to get a registerised version. (in theory it's possible to cross-compile straight to a registerised version since your target architecture is already supported, but we haven't gone to the trouble of testing and documenting that process, so you'd be on your own). 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
If a program calls exitWith, runghc produces an extra line of output: *** Exception: exit: ExitSuccess or *** Exception: exit: ExitFailure 3 and then exits with status 0. It should do what a ghc-compiled program does: silently exit with the appropriate status. ___ 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
System.Posix.Types.CClock and System.Posix.Types.CTime seem to be missing instances for 'Integral' as they used to have. John -- John Meacham - repetae.netjohn ___ 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 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: 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: 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: 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: 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
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
GHC 6.4 release candidates available
We are finally at the release candidate stage for GHC 6.4. Snapshots with versions 6.4.20050209 and later should be considered release candidates for 6.4. Source and Linux binary distributions are avaiable here: http://www.haskell.org/ghc/dist/stable/dist/ Please test if you're able to, and give us feedback. Thanks! Simons the GHC team ___ 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: We are finally at the release candidate stage for GHC 6.4. Snapshots with versions 6.4.20050209 and later should be considered release candidates for 6.4. Using: ghc-6.4.20050209-i386-unknown-linux.tar.bz2 $ cat hello.hs main = putStrLn hello world $ ghc--6.4.20050209 -o hello hello.hs ld: cannot find -lHSbase_cbits collect2: ld returned 1 exit status $ Pretty much a show-stopper. Regards, Malcolm ___ 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 13:31, Malcolm Wallace wrote: Simon Marlow [EMAIL PROTECTED] writes: We are finally at the release candidate stage for GHC 6.4. Snapshots with versions 6.4.20050209 and later should be considered release candidates for 6.4. Using: ghc-6.4.20050209-i386-unknown-linux.tar.bz2 $ cat hello.hs main = putStrLn hello world $ ghc--6.4.20050209 -o hello hello.hs ld: cannot find -lHSbase_cbits collect2: ld returned 1 exit status $ Pretty much a show-stopper. Yes, I'm fixing this right now. Please hold off downloading until I can get a fixed distribution up... 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 13:40, Simon Marlow wrote: On 10 February 2005 13:31, Malcolm Wallace wrote: Simon Marlow [EMAIL PROTECTED] writes: We are finally at the release candidate stage for GHC 6.4. Snapshots with versions 6.4.20050209 and later should be considered release candidates for 6.4. Using: ghc-6.4.20050209-i386-unknown-linux.tar.bz2 $ cat hello.hs main = putStrLn hello world $ ghc--6.4.20050209 -o hello hello.hs ld: cannot find -lHSbase_cbits collect2: ld returned 1 exit status $ Pretty much a show-stopper. Yes, I'm fixing this right now. Please hold off downloading until I can get a fixed distribution up... New distributions are up now. 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
Simon Marlow [EMAIL PROTECTED] writes: We are finally at the release candidate stage for GHC 6.4. Please test if you're able to, and give us feedback. In versions 5.00 = ghc = 6.2.2, the result of ghc -v 21 | head -2 was something like Glasgow Haskell Compiler, Version 6.2.2, Using package config file: /grp/haskell/lib/ghc-6.2.2/package.conf whereas with 6.4, these two lines have been swapped: Reading package config file: /usr/malcolm/local/lib/ghc-6.4.20050209/package.conf Glasgow Haskell Compiler, Version 6.4.20050209, and the Using package config message has become Reading package config. These changes are minor and unnecessary: in particular they make the detection of configuration information (by hmake) rather more complicated than it ought to be. I know this is a pretty trivial complaint, but the -v behaviour has been stable for a few years now, so why change it arbitrarily? Regards, Malcolm ___ 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 15:13, Malcolm Wallace wrote: Simon Marlow [EMAIL PROTECTED] writes: We are finally at the release candidate stage for GHC 6.4. Please test if you're able to, and give us feedback. In versions 5.00 = ghc = 6.2.2, the result of ghc -v 21 | head -2 was something like Glasgow Haskell Compiler, Version 6.2.2, Using package config file: /grp/haskell/lib/ghc-6.2.2/package.conf whereas with 6.4, these two lines have been swapped: Reading package config file: /usr/malcolm/local/lib/ghc-6.4.20050209/package.conf Glasgow Haskell Compiler, Version 6.4.20050209, and the Using package config message has become Reading package config. These changes are minor and unnecessary: in particular they make the detection of configuration information (by hmake) rather more complicated than it ought to be. I know this is a pretty trivial complaint, but the -v behaviour has been stable for a few years now, so why change it arbitrarily? Ok, fixed. The right way to get the location of the package.conf file is to ask ghc-pkg, BTW. In fact, the right way is not to know the location of package.conf at all, but to use ghc-pkg to query its contents. The contents of package.conf is proprietary :-) 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 15:36, Malcolm Wallace wrote: Simon Marlow [EMAIL PROTECTED] writes: Ok, fixed. The right way to get the location of the package.conf file is to ask ghc-pkg, BTW. In fact, the right way is not to know the location of package.conf at all, but to use ghc-pkg to query its contents. The contents of package.conf is proprietary :-) And indeed hmake does use ghc-pkg, when it needs to find import directories etc. But the thing is, previous versions of ghc-pkg reported such directories as e.g. $libdir/base, and how do you find out what $libdir refers to...? ghc --print-libdir 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
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. Regards, Malcolm ___ 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
$ 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, ... Regards, Malcolm ___ 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 Thu, 2005-02-10 at 13:11 +, Simon Marlow wrote:
Please test if you're able to, and give us feedback.
I've noticed that running main of the attached code, using Proxy
data-types to simulate context parameters (see previous email) still
sends something into an infinite loop; is this my fault or GHCs?
-Si.
--
Simon David Foster [EMAIL PROTECTED]
{-# OPTIONS -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances #-}
module Test where
import Data.Typeable
-- Skeleton of the Data class
class (Typeable a, Sat (ctx a)) = Data ctx a
-- Our main class with 2 parameters
class (Data (DictClassA a) b, ClassB b) = ClassA a b where
func :: b - a - String
-- The class which contrains ClassA
class ClassB a where
func2 :: a - String
data DictClassA a b = DictClassA { funcD :: b - a - String, classBD :: DictClassB b, func2D' :: b - a - String }
data DictClassB a = DictClassB { func2D :: a - String }
class Sat a where
dict :: a
instance Sat (ctx String) = Data ctx String
instance Sat (ctx Int) = Data ctx Int
--instance ClassA a b = (Data (DictClassA a) b)
-- Trying to access any of functions in ClassA works fine, but trying to get at anything in ClassB causes and infinite loop.
instance (Data (DictClassA a) b, ClassA a b) = Sat (DictClassA a b) where
dict = DictClassA { funcD = func, classBD = dict, func2D' = func2' }
func2' :: ClassA a b = b - a - String
func2' x ctx = func2 x
instance ClassB a = Sat (DictClassB a) where
dict = DictClassB { func2D = func2 }
instance ClassA a String where
func _ _ = hello
instance ClassA Int Int where
func _ _ = hello
instance ClassB String where
func2 _ = bye
instance ClassB Int where
func2 _ = bye
main = do print $ func hello (5::Int)
print $ func2D' ((dict::DictClassA Int String)) hello 5
___
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
When -fglasgow-exts is on, (#) no longer seems to be recognized. (I get a parse error.) however # works fine as an infix operator. John -- John Meacham - repetae.netjohn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
