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]
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
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
addition to the previous bug report on
interactive: 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
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
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
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
ghc-pkg -g.
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
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
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,
`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
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:
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
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 +sremoves
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
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
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
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.
I am not
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
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
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, containing
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?
-
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
Sent: den 14 oktober 2004 10:30
To: Serge D. Mechveliani
Cc
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
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
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
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
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
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
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
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
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
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
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
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:
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 -O
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
-Rghc-timing -fgeneri\cs -fgenerics
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.
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,
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
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
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
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 ?
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:
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,
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,
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 two
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 they
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-
| From: Serge D. Mechveliani [mailto:[EMAIL
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
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 couple
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.
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'd
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
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
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 to build projects, so you won't see any
difference if you
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
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 *.hs-boot.
We can't look for differences between
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?
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
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]
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
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 ?
We did investigate it - the details
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
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
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,
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
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
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 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,
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
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 $dmCpOpt -prof --make Main
shows
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
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
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 `...')
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__
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 -,
On Wed, Jun 20, 2012 at 04:55:59PM -, GHC wrote:
#4361: Typechecker regression
-+--
Reporter: igloo | Owner: simonpj
Type: bug |
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, but it
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 is
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, but it
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 signature
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
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-
| From: Serge D. Mechveliani [mailto:mech...@botik.ru]
| Sent: 21 December 2012 11:48
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.
You
85 matches
Mail list logo
