| 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
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
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
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
-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
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
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
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
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
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
]
[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
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
___
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
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
| 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
@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
| 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
@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
-
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
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:
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
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
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
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
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,
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
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
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
[...]
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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).
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?
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;
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
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
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
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
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
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
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:
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
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
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
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 (
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
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
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.
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
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
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
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
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
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
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
[]
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,
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
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
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
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
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
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
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:
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
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,
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
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
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
$ 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
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
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
83 matches
Mail list logo
