On Fri, Dec 21, 2012 at 01:45:04PM +, Simon Peyton-Jones wrote:
> OK, do this
>
> * {-# LANGUAGE ScopedTypeVariables, MonoLocalBinds #-}
>
> * import Categs( Domains1 )
>
> * Add type sig for dP'
> dP' :: (LinSolvRing (Pol a), CommutativeRing a) => Domains1 (Pol a)
>
> Then it compiles.
r report,
if this is essential, and if you still need docon2.12-pre,
then you could change things in it according to the corresponding
points in d212-pre-asBug.
But I hoope d212-pre-asBug will do.
The responsible module is Pol3_.hs.
Regards,
--
Sergei
> | -Original Message
On Fri, Dec 21, 2012 at 11:26:30AM +, Simon Peyton-Jones wrote:
> I think you need to remove the 'forall a' on the type signature for dP'.
> The 'a' you mean is the 'a' from the instance declaration, not a
> completely fresh 'a'.
This looks reasonable.
> Moreover I don't think you need the
On Fri, Dec 21, 2012 at 10:12:38AM +, Simon Peyton-Jones wrote:
> I would not use -XMonoLocalBinds for all modules -- that will force you to do
> more work.
> Instead use it just for the offending Pol3_ module, via {-# LANGUAGE
> MonoLocalBinds #-}
>
> Or, probably better, give a type signat
On Wed, Jun 20, 2012 at 04:56:01PM +, Simon Peyton-Jones wrote:
> Serge
>
> I hope you are well.
>
> I'm making a significant simplification to the type inference engine,
> which will have a small knock-on effect in DoCon.
>
> I implemented a VERY DELICATE HACK to solve your problem before,
On Thu, Dec 20, 2012 at 07:57:45PM +, Simon Peyton-Jones wrote:
> | It looks like http://hackage.haskell.org
> |
> | is not valid now. Is this due to the recently announced e-mail lists
> | reorganization?
>
> It's working fine for me. No reorganisation there.
>
> Simon
>
Today it i
On Wed, Jun 20, 2012 at 04:56:01PM +, Simon Peyton-Jones wrote:
> Serge
>
> I hope you are well.
>
> I'm making a significant simplification to the type inference engine,
> which will have a small knock-on effect in DoCon.
>
> I implemented a VERY DELICATE HACK to solve your problem before,
On Wed, Jun 20, 2012 at 04:55:59PM -, GHC wrote:
> #4361: Typechecker regression
> -+--
> Reporter: igloo | Owner: simonpj
>
> Type: bug |
Simon,
thank you.
Currently, DoCon works under ghc-7.0.1.
And as I understand, the next release which is going to support DoCon
(with its heavy use of overlapping instances) will be ghc-7.2.
Regards,
Serge Mechveliani, mech...@botik.ru
On Wed, Jun 22, 2011 at 11:01:53AM -, GHC
Dear GHC team,
I am testing the 7.02 candidate of ghc-7.0.1.20110217
-- compiled from source, compiled by itself, on Debian Linux,
i386-family.
On my DoCon program, it reports the following.
1. It requires `-fcontext-stack=_' to increase a certain stack:
...
[67 of 83] Compiling Pfact__
Dear GHC developers,
I am testing this fresh ghc-7.0.0.20101028
on Debian Linux, i386-family.
Making it from source by ghc-6.12.3 is all right.
Then, making it from source by itself reports
(here I abbreviate the messages by inserting `...')
--
Simon P. Jones wrote recently about that ghc-6.12 takes in
account the elliplis in MkT {t1 = x, ..} when reporting about
unused bindings.
Now, here is the example:
module TT where
data T = T {t1, t2 :: Int}
f d = x where
T {t1 = x, ..} = d
ghc-6.12.2 warns about unuse
Dear GHC developers,
http://botik.ru/pub/local/Mechveliani/ghcBugs/ghc701preBug.zip
contains a bug report on ghc-7.0.0.20100924
tested on Debian Linux, i386-family.
Its essence is as follows. At the fragment of
-
To my
> >>>It looks like ghc-6.12.1 reports erroneous time profiling --
> >>>when the Main module of the project is made under -O.
> >>>[..]
> >>>This is for ghc-6.12.1 made from source for Debian Linux and
> >>>i386-like.
> >>> []
> >The key combination
> >ghc $dmCpO
Dear GHC team,
It looks like ghc-6.12.1 reports erroneous time profiling --
when the Main module of the project is made under -O.
This is for ghc-6.12.1 made from source for Debian Linux and
i386-like.
Main.main calls for Complete.complete, `complete' calls for
eLoop inside its sourc
Dear GHC team,
I have tested ghc-6.12.0.20091121
by
1) installing its binary and making and running the DoCon and Dumatel
programs,
2) making it from source by its binary,
making and running on it the DoCon and Dumatel programs.
It looks all right.
I skipped profiling.
Regards,
--
Dear GHC team,
I tried ghc-6.12.0.20091010-src.tar.bz2
on Linux, Debian, i386-*
And it cannot compile my Dumatel project. It fails at the segment:
module Bug where compose :: [a -> a] -> a -> a
compose = foldr (.) id
class Compose a where compose1
Dear GHC team,
I withdraw my last bug report.
It was about processing a long list on a 64 bit machine оn GHC-6.10.2.
First, I cannot reproduce (?) this bug report invitation from GHC on
using +RTS -M4000m
Second, I have found that the process interruption only occurs when
this test program r
Dear GHC team,
I am trying ghc-6.10.2 оn a 64-bit matchine:
[mech...@node-1 t]$ uname -a
Linux node-1.localdomain 2.6.18-hpc-alt1.M41.1.mm1 #1 SMP
Mon Dec 8 14:58:04 MSK 2008 x86_64 GNU/Linux
,
16 Gb RAM machine, Intel(R) Xeon(R) CPU E5472, 3 GHz.
First we have installed there ghc-6.
Dear GHC team,
I `make' my (large) project in ghc-6.10.1, Linux Debian, i386-unknown,
run the executable, and obtain
Segmentation fault.
Then, I noted that in a few places the compiler warned about skipping
some class member implementations in some instances.
I added these implementations,
People,
ghc-6.10.1 says it provides a `sugar' syntax for records:
wild-card patterns, punning, and field disambiguation.
For example, I write fam {opAttrs = cp $ opAttrs fam}
to map the function cp to the field opAttrs in the record fam.
The best expression for this could be
The ghc-6.10.1 doc writes about -fdisambiguate-record-fields,
the compiler does not recognize it,
also it does not recognize -XDisambiguate-record-fields,
and it does recognize -XDisambiguateRecordFields.
Also is not it better to uniformly use an upper case letter instead of
dash everyw
On Wed, Jun 18, 2008 at 02:38:40PM +0100, Ian Lynagh wrote:
>
> Hi Serge,
>
> On Wed, Jun 18, 2008 at 04:39:57PM +0400, Serge D. Mechveliani wrote:
> >
> > But as ghc-6.8.2 handles DoCon all right, why do not you
> > investigate this difference in 6.8.3 ?
&g
Dear GHC developers,
I wonder whether ghc-6.8.3 is better than 6.8.2.
Because 6.8.2 makes DoCon-2.11 under -M400m.
And 6.8.3 does not suffice -M500m.
It breaks with the heap exhaustion at the module RsePol_.
--
Moreover, repeated make
About the 6.8.3 candidate of May 27,
there remains the question:
why it builds DoCon-2.11 considerably slower than ghc-6.8.2
(3 times, as I recall)
and needs larger -M memory to build this DoCon
?
Regards,
-
Serge Mechveliani
[EMAIL PROTECTED]
,
-
Serge Mechveliani
[EMAIL PROTECTED]
On Thu, May 29, 2008 at 03:10:07PM +0100, Ian Lynagh wrote:
> On Thu, May 29, 2008 at 03:48:36PM +0400, Serge D. Mechveliani wrote:
> >
> > Main: fromInteger to (Pol ..): use fromi
>
> OK, I can reproduce this, but as we
In addition to the bug report of DoCon-2.11:
making docon with -Onot is fast enough,
but running the test shows the same error as with -O.
---
Mechveliani
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haske
Dear GHC developers,
ghc-6.8.2 compiles {-# SCC "ab cd" #-} as all right.
And the GHC candidate of May 27, 2008 reports the error:
"spaces are not allowed in SCC".
Do you think that this latter has more sense?
Is not this a matter of the programmer to give string names to SCC
points
On Mon, Jan 07, 2008 at 04:37:16PM +, Ian Lynagh wrote:
>
> Hi Serge,
>
> On Mon, Jan 07, 2008 at 06:56:13PM +0300, Serge D. Mechveliani wrote:
> >
> > In many situations, GHC reports first what namely is the type
> > disagreement between *.hs and *.h
Dear GHC developers,
This is about possibile bug in ghc-6.8.2 related to types in hs-boot.
I have a project with module import loop, in which the module Split
imports the source of Reduce.
Now, I changed the type of the function Reduce.evaluate_c
and forgotten to change it in Reduce.hs-
On Fri, Oct 19, 2007 at 01:25:27AM +0100, Duncan Coutts wrote:
> On Thu, 2007-10-18 at 11:02 +0400, Serge D. Mechveliani wrote:
> > On Oct 17, 2007, Don Stewart and Duncan Coutts wrote:
> >
> > > > [..]
> > > > By default cabal uses ghc -O
Dear GHC developers,
I have tested ghc-6.8.0.20071015-src.tar.bz2 on DoCon and on
Dumatel.
It looks all right
(except the bug-candidate for -O which is common to all GHC versions
and which I recently reported
).
On DoCon, ghc-6.8.0.20071015
1) builds the project 2-3 times faster than gh
Dear GHC developers,
The point (1) below looks like a bug (in all GHC versions!).
(1) -O for demo-test.
Take (the public) docon-2.10 build it under -O, install,
and build also under -O its test program by
cd demotest
ghc $doconCpOpt -O --make Main
Either the latter compilation wi
On Oct 17, 2007, Don Stewart and Duncan Coutts wrote:
> > [..]
> > By default cabal uses ghc -O to build projects, so you won't see any
> > difference if you comment it out of the cabal file. You will however
> > if you explicitly turn off optimisations:
> >
> > ghc-options: -Onot
>
> or:
>
To my question about -O in ghc-6.8.1-candidate
Don Stewart wrote on Wed, Oct 17
> By default cabal uses ghc -O to build projects, so you won't see any
> difference if you comment it out of the cabal file. You will however
> if you explicitly turn off optimisations:
I see now, thank you.
> I
Dear GHC developers,
Has -O any meaning in ghc-6.8.1-candidate ?
I build docon under ghc-6.8.1-candidate under -O and
with skipping it (the line of -O commented out in docon.cabal).
And it installs the .a library of the same size,
and the test running takes the same time.
Regards,
People,
here is a more precise report about empty _export_ in
ghc-6.8.1-candidate:
I use
module M1 (f, module M2)
where
import M2 ()
f = ...
in the situation when M1 imports some instances from M2 and
reexports
On Wed, Oct 17, 2007 at 12:35:08PM +0100, Simon Peyton-Jones wrote:
> Serge
>
> I've just compiled docon-2.10 with the current 6.8 branch.
> It compiles fine. Log is below
> [..]
Thank you.
I looked into the log that you have enclosed.
1. Instance import.
You see that GHC warns about a cou
Simon P. Jones wrote he would go for ghc-6.8.0.20070914.
I tried to `make' it by ghc-6.8.0.20070928:
./configure --prefix=..
make >& makeLog
It reports
...
cbits/unicode.c:1:63:
error: floating constant in preprocess
ild-depends in
source/docon.cabal.
---
Mechveliani
On Mon, Oct 15, 2007 at 04:47:09PM +0100, Simon Peyton-Jones wrote:
> I'd go for 20070914
> http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.0.20070914-src.tar.bz2
>
> S
>
> | -Original Message-
On Mon, Oct 15, 2007 at 02:47:37PM +0100, Simon Peyton-Jones wrote:
> | But it'd be better still to check with the 6.8 branch, but I can see you
> can't do that. IAN, are we
> | dumping snapshots of the 6.8 branch for people to try? Can you help Serge
> (and perhaps others) have a
> | snapshot
On Fri, Oct 12, 2007 at 05:39:51PM +0100, Simon Peyton-Jones wrote:
> Serge
>
> Thank you so much for reporting your problems with DoCon 2.11.
> I believe I have fixed them.
>
> Would you like to try again? As of now, the fixes are in the HEAD,
> so you'll have to pull from there. In a day or
Dear GHC developers,
this is again on the `panic' bug in ghc-6.8.1-candidate.
The archive
http://botik.ru/pub/local/Mechveliani/ghcBugs/bug2-6.8.0-sep28.zip
presents one more report on this bug. Unzip and see install.txt.
The project is built, but the test program Test.hs cannot build,
g
Dear GHC developers,
this is a bug report on ghc-6.8.1-candidate.
The archive
http://botik.ru/pub/local/Mechveliani/ghcBugs/bug-6.8.0-sep28.zip
contains a project for which `making' under ghc-6.8.0.20070928-src
produces a report of kind
.
Dear GHC developers,
I am preparing a bug report for the compiler of ghc-6.8.0.20070928-src:
--
GBasFld_.hs:387:45: Warning: Defined but not used: `t'
ghc-6.8.0.20070928: panic! (the 'impossible' happened)
(GHC version 6.8.0.20070928 for i386-unknown-linux):
initC: srt_
Dear GHC developers,
this is on the future ghc-6.8.1.
The DoCon-2.10 distribution uses the command runhaskell
in its Makefile.
This works in ghc-6.6.1 but does not work in ghc-6.8.0.20070928-src.
Because the latter provides only runghc.
Can you can put runhaskell next to runghc ?
What
I tried to `make'
http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.20070912-src.tar.bz2
under Debian Linux, i386-unknown, and it stopped with
---
[...]
[...]
../compiler/stage1/ghc-inplace -H16m -O -istage2/utils -istage2/basicTypes
-\ist
Dear GHC developers,
Recently I submitted a bug report #1452 for ghc-6.6.1
of undefined references at the stage of linking executable,
and also of ignoring un-existing module import.
Now I discovered the following strange effect
(see the report source modules) which, probably, explains much.
Dear GHC developers,
ghc-6.6.1 does not report about unknown module import in boot-modules.
For example, let us haveFoo.hs and Foo.hs-boot,
and add to Foo.hs-boot the line
import M
, where M is not a name of any existing module.
ghc `makes' the project without any repor
On Mon, Jan 08, 2007 at 07:14:32PM -, GHC wrote:
> #945: `waitForProcess' report in `install' in ghc-6.6
> --+-
> Reporter: guest | Owner:
> Type: bug | Status: new
> Priority: normal
Dear GHC developers,
I have `made' ghc-6.4.1.20050801
by its binary, on Linux Debian, and tested on DoCon and Dumatel
application.
The first `make' crashed (I do not know, maybe, indeed, a hardware
fail). The second (by new) succeeded.
It looks all right -- except `making' with profiling.
W
On Wed, Aug 03, 2005 at 11:57:07AM +0100, Simon Marlow wrote:
> On 03 August 2005 10:38, Serge D. Mechveliani wrote:
>
> > ../../ghc/compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude
> > -"#include" HsBase.h -funbox-strict-fields -ignore-package base -O
I have installed ghc-6.4.1.20050801-i386-unknown-linux
to Debian Linux.
( > uname -m
i686
> uname -r
2.4.27-2-686-smp
)
and am trying to make it (ghc-6.4.1.20050801-src)
from source by itself.
It reports
-
...
...
../../ghc/compiler/ghc-inplace -H16m -
There appears some package conflict problem in re-making
ghc-6.4.1-pre with itself
(under Debian Linux).
On July 12, 9.00 GMT, I downloaded ghc-6.4.1-pre of CVS
and `made' it with ghc-6.4.1-pre-June-14.
It looks working all right.
Then I downloaded ghc of 5 hours later:
ghc-6.
It still cannot make.
I have downloaded ghc-6.4.1-pre of CVS July 11 2005
(this is the date of the act of downloading)
and am trying to make it with ghc-6.4.1-pre of June 15
under Debian Linux.
It reports
-
...
...
/home/mechvel/ghc/cvs/instJune14/bin/ghc -H16m -O -i
I have sent a report to this bug list about failing
to make ghc-6.4.1-pre.
But it included the 300 Kb log archive, and I have forgotten that the
list may not like large letters.
I am sorry.
So, I cancelled this posting and resent the report to Simon Marlow
personally.
-
Serge
Who knows, please, how to work with the program of
main = interact (\ s -> shows (read s :: Bool) "\n")
in the interpreter ghci ?
This is on ghc-cvs-6-4-branch-June-15-2005
under Debian Linux, i386-uknown.
When compiled, it works: > ghc --make ReadBug
Dear GHC developers,
I am testing packages in ghc-6.4.
I set
docon.cabal,
which declares dependence on `data': build-depends: data
The attempt to build docon by
cd $doconSource
runhaskell Setup.hs configure --ghc --prefix=$doconSource/inst
runhaskell Setup.hs build
produ
Dear GHC developers,
I am testing Cabal in ghc-6.4.
Consider a project of the modulesU1.hs, subdir/V1.hs
put to the source root of$(HOME)/user1/
Provide some simplest source for U1, V1,
and the package description
-- u1.cabal -
name:u1
ver
Dear GHC developers,
ghc-6.4 seems to fail in processing the RTS options set in a package:
name:dumatel
version: 1.0.2.6.4
synopsis:term rewriting system and prover
description: term rewriting system and prover
build-depend
Dear GHC team,
There were several cases when make space=-M... docon
revealed a new bug report.
Generally, it is useful for the testing to `make' some small thing
under several different -M values, preferably, small
(garbage collector, and such).
For example, you have now docon-2.08-pre which
Yes, please, withdraw my last `bug' report on ghc-6.2.2.
The next day after I sent a `bug report' I also discovered that the
program behavior looks natural.
Because most of the functions in the presented module call each
other in a complex recursive way.
But there remains another one: a DoCon `m
Dear GHC team,
My investigation of why a certain list field in a record
does not print lazily has lead to something like a bug report
for ghc-6.2.2.
The program example of kind
let f = ...
mbPair = ...
in
f $ case mbPair of Just _ -> error "Lemma found\n"
Dear GHC team,
I have got this when compile DoCon-2.08 with
ghc-6.2.2 -Onot -M40m
(on RedHat Linux, i386-unknown, ghc-6.2.2 built from source) :
**
INTERFACE HAS CHANGED
Thank you.
I helps.
I was trying /distrib, /distr instead of /dist.
On Sat, Oct 16, 2004 at 05:06:59PM +1000, Donald Bruce Stewart wrote:
> > My (old) brouser takes www.haskell.org but is not able
> > to get the picture of www.haskell.org/ghc
>
> http://www.haskell.org/ghc
Dear GHC team,
I needed to download ghc-6.2.2.
My (old) brouser takes www.haskell.org but is not able
to get the picture of www.haskell.org/ghc
, just gets aborted.
Several months ago this page became readable, and now again changed.
Please, how to reach GHC in a regular way (www or an
t; still using the old erroneous definition.
>
> Could this fix be merged into the 6.2 branch, please?
>
> /Josef
>
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:glasgow-haskell-
> > [EMAIL PROTECTED] On Behalf Of Johannes Waldmann
>
Dear GHC developers,
the function let ns = [1 .. 10^6] :: [Int]
p = partition even ns
in
take 2 $ fst p
computes too long in ghc-6.2.2-September-26
and needs several megabyte of stack.
What might be the reason?
-
S
Dear GHC developers,
I continue to test ghc-6.2.2-pre of September 26.
At the first attempt, `make' failed after certain ghc ... -M
command in an ununderstandable manner.
The second command of `make' has succeeded.
Meanwhile and for any occasion, can you make sure that this
version, for example,
Simon Marlow <[EMAIL PROTECTED]> writes on 19 Jul 2004
about release plans:
> We are currently planning two new releases around the end of August:
> one from the STABLE branch and one from the HEAD.
>
> STABLE: 6.2.2
> -
>
> This will be the final release from the 6.2 branch, contai
Dear GHC team,
In my previous letter I wrote about a bug-like message in
cvs ghc-6-2-branch of May 24
(the fragments of this letter are appended).
And in this situation GHC also responds badly if the user forgets
to include a package.
> cd foo
foo> gh
Dear GHC team,
I have tested (on somewhat 90%) the cvs ghc-6-2-branch of May 24.
It looks almost correct for DoCon.
Still I pretend to report the two bugs, so far.
1: (wrote earlier) is on negative number of bytes shown by
`:set +s'.
2: follows below, it also contains questions about organi
Dear GHC team,
My DoCon test under ghc-6-2-branch performs like this
ghc $pcpdocon --make T_
...
ghci $pcpdocon T_ ...
...
Prelude T_> :set +s
Prelude T_> test "log"
...
*** Test FIN
Dear GHC team,
It occurs problematic for me to build correct cvs ghc-6-2-brach.
Now, I have built cvs ghc-6-2-branch first in
/home/mechvel/ghc/cvs/6-2-branch/inst
,
then, after cd fptools
make clean
rebuild ghc-6-2-branch by /home/mechvel
Dear GHC team,
I keep on trying to build a correct ghc-6-2-branch
from cvs source.
This is a pain. Spent a week to this, and no success.
Just
"Internal error ..."
The last experience was on computer under Debian linux,
with
no ghc, no alex, no happy anywhere.
I installed there
Simon P. Jones writes
> There is a known bug in the one-space compacting garbage collector for
> GHC 6.2.1. It is fixed in the 6.2 branch.
>
> This bug is shown up by your "space=XXX" choice. If you omit =
> space=xxx
> you won't use the one-space collector, and the bug will probably vanish.
>
Dear GHC developers,
I have built the cvs update -r 6-2-branch in my home dir.
It was compiled by ghc-6.2.1 official and istalled in
.../ghcCVS/inst
It worked in some examples, but as I wrote you, some errors appear.
Now I am trying to rebuild 6-
Addition to my 2 previous letters:
When `making' 6-2-branch it stayed long on PrimOp.lhs,
and I interrupted it.
And just restarted make allfrom .../myfptools
Maybe, due to this failure it had `made' with some trace of old
RTS ?
-
Serge Mechveliani
[EMAIL PROTECTE
It also appears when a particular instance in Pol3_
is replaced with what ghc required earlier.
> test "log"
>
ghc-6.2.1: internal error: scavenge:
unimplemented/strange closure type 64 @ 0x40603330
---
It also appears under -Onot
> :set +srem
Addition to my previous two reports:
* this "internal error" also happens in the test ghci
when docon is compiled under -Onot too.
* But I tried > :set +s
before> test "log"
, and with this, the test completed successfully.
-
Serge Mechveliani
[EMAIL P
And it also appears at the run-time.
`Making' docon-2.08-pre (like in previous report enclosed)
under -O,
making the test by cd $(s)/demotest
ghc $pcpdocon --make T_
and running the test byghci $pcpdocon T_ +RTS any space -RTS
Dear GHC developers,
I have `made' GHC of cvs update -r ghc-6-2-branch(about May 14)
by ghc-6.2.1 on RedHat Linux (about version 8) libc-2.2, i686.
Now, you have the docon-2.08-pre
test, with Pol3_.hs containing
instance (LinSolvRing (Pol a), CommutativeRing a) =
On Mon, May 17, 2004 at 04:07:56PM +1000, Donald Bruce Stewart wrote:
> mechvel:
> > Dear GHC developers,
> > `Making' GHC of cvs update -r ghc-6-2-branch
> > with ghc-6.2.1
> > on RedHat Linux (about version 8) libc-2.2, i686
> > seems to meet a problem:
> >
> > ***
Dear GHC developers,
`Making' GHC of cvs update -r ghc-6-2-branch
with ghc-6.2.1
on RedHat Linux (about version 8) libc-2.2, i686
seems to meet a problem:
**
... myfptools ...
...
> cd myfptools
> ./configure --pr
To my
On Mon, May 10, 2004 at 12:06:32PM +0100, Simon Marlow wrote:
> > I have tested ghc-6.2.1
> > ...
> > But it seems to have a space leak in the compiler.
> > make space=-M30m docon
> > (involving ghc --make ... +RTS -M30m -RTS)
> >
> > leads to
Dear GHC developers,
ghci seems not to work in ghc-6.2.1
(installed from (maybe) RPM on RedHat Linux (maybe) 8).
The interpreter does not find some instances
> ghci $pcpdocon
> ...
Loading package base ... linking ... done.
Loading package haskell98 ... linking ...
Dear GHC developers,
I have tested ghc-6.2.1
(installed from (maybe) RPM on RedHat Linux (maybe) 8)
on my DoCon-2.08 application. It works, mainly.
But it seems to have a space leak in the compiler.
make space=-M30m docon
(involving ghc --ma
Dear GHC developers,
What about compiler's warning of repeated import of items?
For the large import lists this may be useful,
and ghc-6.01 seems to lack this:
--
module T where
import Maybe (isJust, isJust)
f = isJust
--
ghc -c T.hs
On Tue, Oct 21, 2003 at 01:56:38PM +0100, Simon Marlow wrote:
> > I suspect that ghc-pkg -g
> > may help to replace the messy line
> > ld -r -x --whole-archive $(e)/libHSdocon.a -o $(e)/HSdocon.o
> >
> > in the above Makefile, but cannot guess how to use here this
> > g
I wrote recently about `strange' package management in
ghc-6.0.1.
I thank Swenn Pan, who explained the effect to me:
about List from haskell98 package and data depending on
haskell98.
I missed the point because I am a bit stupid and also because the
package treating changes rapidy from ver
I suspect that may previous bug report on interactive interpreter
should be replaced with the following one, which is simple to
analyse.
This is on
ghc-6.0.1
installed from RPM on Red Hat Linux release 7.3 (Valhalla),
i-386 unknown.
Probably, you can reduce the example several times mor
addition to the previous bug report on
: internal error: scavenge
:
when the project is made under -O, this bug is not revealed
(but it may, for example, appear under different memory options,
who knows).
___
Glasgow-haskell-bugs mailing list
[EMA
Dear GHC team,
ghc-6.0.1
installed from RPM on Red Hat Linux release 7.3 (Valhalla)
i-386 unknown
runs into the following bug after `making' of my large project and
when running the test
T_.test "log"
from Interpreter:
...
finds gs' = Groebner basis gs,
tests
Please, what is the matter with the packages in ghc-6.0.1 ?
(ghc-6.0.1
installed from RPM on Red Hat Linux release 7.3 (Valhalla),
i-386 unknown
)
It does not find the library items, say List.sort,
when it `makes' under the user package in the user project
importing standard li
Dear ghc-5.02.2,
ghc -c -fwarn-unused-matches
says
Warning: Defined but not used: x
when compiling the function
f :: Eq a => [(a, a)] -> (a, a) -> [(a, a)]
fps (x, y) = [(z, y) | (z, x) <- ps]
Is it a bug?
Answer, please, to [EMAIL PROTECTED]
--
95 matches
Mail list logo
