Re: DoCon and GHC
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 accessible for me two. And yesterday, I had access to http://haskell.org but not to http://hackage.haskell.org All right, may be sevaral middle servers where out. -- Sergei ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: DoCon and GHC
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
has become a significant problem to maintain the hack, so I'm taking it out.
See http://hackage.haskell.org/trac/ghc/ticket/4361, and the comments I
have added there, which tell you what change to make. It's very minor!
This will take effect from GHC 7.6 onwards. Thanks
Simon
This is on Ticket #4361 (closed bug: fixed)
about compiling DoCon.
Its story is as follows.
* 7.4.0 failed to compile the module Pol3_ in DoCon due to
1) a certain GHC manner of constraint simplification (as Simon wrote)
2) a due to complex enough constraints used in DoCon, in particular,
instance (LinSolvRing (Pol a), CommutativeRing a) =
LinSolvRing (UPol (Pol a))
set in Pol3_.hs
(I do not know how to simplify this constraint without loosing
generality).
* 7.4.1 does compile it, but, as Simon wrote, applies for this a very
specific and unstable compilation method.
* 7.6+ removes this latter method, and Simon P. Jones concludes
Happily, it's extremely easy to fix your source code in either of
these two ways:
* If you use -XMonoLocalBinds (which is in any case implied by -XGADTs
and -XTypeFamilies), then GHC won't generalise the definition of x
in the example, and all will be well.
* Alterantively, give a type signature for x, thus (in this case)
moduloBasisx p = let x :: ()
x = upLinSolvRing p
in ()
Now, I am trying ghc-7.6.1.20121207 built from source on Debian Linux.
I. I try adding -XMonoLocalBinds for compiling DoCon:
-- doco.cabal ---
...
ghc-options:
-fno-warn-overlapping-patterns -fwarn-unused-binds
-fwarn-unused-matches -fwarn-unused-imports -XMonoLocalBinds
-O
--
`make build' fails at the first module:
--
module Prelude_
where
...
instance (DShow a, DShow b) = DShow (a, b)
...
where
dShows opts (x, y) = showChar '(' . shows1 x . showString sep .
shows1 y . showChar ')' -- line 628
where
opts'= addToShowOptions (- 1) $ opts {parInShow = Parens}
sep = fieldSeparator opts
shows1 x = (case parInShow opts of Parens - id
_ - unparensUpper ())
. dShows opts' x
aShows (a, b) = showString (pair . aShows a . showChar ' ' .
aShows b . showChar ')'
--
The report is
runghc Setup.hs build
Building docon-2.12...
Preprocessing library docon-2.12...
[ 1 of 84] Compiling Prelude_ ( Prelude_.hs, dist/build/Prelude_.o )
Prelude_.hs:628:32:
Could not deduce (a ~ b)
from the context (DShow a, DShow b)
bound by the instance declaration at Prelude_.hs:622:10-43
`a' is a rigid type variable bound by
the instance declaration at Prelude_.hs:622:10
`b' is a rigid type variable bound by
the instance declaration at Prelude_.hs:622:10
In the first argument of `shows1', namely `y'
In the first argument of `(.)', namely `shows1 y'
In the second argument of `(.)', namely shows1 y . showChar ')'
...
---
The line 628 is marked in the code as -- line 628.
I suspect that besides -XMonoLocalBinds,
I need also to add some explicit type signatures,
for example,
dShows opts (x, y) = showChar '(' . shows1 (x :: DShow a = a) .
...
Because GHC, probably, finds some contradiction in applying shows1
to x :: a and to y :: b.
II. My another attempt will be removing -XMonoLocalBinds
(with this, it compiles many modules and stops at Pol3.hs)
and inserting a type signature in an appropriate place
(this will also need to add ScopedTypeVariables + `forall'
-- thanks to people for hints
).
If (II) works, then it will be, probably less restrictive than (I).
This is just the current report of my attempt to compile DoCon with GHC.
--
Sergei
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: DoCon and GHC
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 inside moduloBasisx, as suggested
in the http://hackage.haskell.org/trac/ghc/ticket/4361. The signature is
better because it also makes the program easier to understand!
Simon
[..]
| * Alterantively, give a type signature for x, thus (in this case)
|
|moduloBasisx p = let x :: ()
| x = upLinSolvRing p
| in ()
Now, I am trying ghc-7.6.1.20121207 built from source on Debian Linux.
-- docon.cabal -
...
extensions:
TypeSynonymInstances UndecidableInstances FlexibleContexts
FlexibleInstances MultiParamTypeClasses OverlappingInstances
RecordWildCards NamedFieldPuns DoAndIfThenElse
.
ghc-options:
-fno-warn-overlapping-patterns -fwarn-unused-binds
-fwarn-unused-matches -fwarn-unused-imports
-XRankNTypes -- new
-O
---
`make build' fails at Pol3_.hs, at compiling this instance
-- Pol3_.hs
...
{-# LANGUAGE ScopedTypeVariables #-}-- (1) **
instance forall a. (LinSolvRing (Pol a), CommutativeRing a) = -- (2) **
LinSolvRing (UPol (Pol a))
where
-- gxBasis in P[y], P = a[x1..xn].
-- Map to a[y,x1..xn] apply gxBasis there, return to P:
gxBasis [] = ([], [])
gxBasis fs@(f:_) = (map back gs, mapmap back mt)
where
UPol _ p y dP= f
(o, n) = (pPPO p, genLength $ pVars p)
(toLex, fromLex) = (reordPol $ lexPPO n, reordPol o)
p' = (toLex p) `asTypeOf` p -- (3) **
dP' :: forall a. (LinSolvRing (Pol a), CommutativeRing a) = -- (4) **
Domains1 (Pol a)
dP' = upLinSolvRing p' Map.empty
-- p needs lexPPO reordering, then,
-- its domain bundle needs change too
s' = cToUPol y dP' p'
-- sample for P'[y], P' = a[x1..xn] with lexComp
toOverP' = ct s' . map (\ (a, j) - (toLex a, j)) . upolMons
fromOverP' = ct f . map (\ (a, j) - (fromLex a, j)) . upolMons
-- P[y] -- P'[y]
back = fromOverP' . headVarPol dP
(gs, mt) = gxBasis $ map (fromHeadVarPol . toOverP') fs
-
What is newly added:
1) -XRankNTypes to docon.cabal -- in order to allow `forall' to
`instance'.
2) {-# LANGUAGE ScopedTypeVariables #-} -- to support explicit
polymorphic type signatures in the instance implementation,
3) asTypeOf for p',
4) Explicit signature for dP'.
The report is similar as the old one:
Pol3_.hs:328:25:
Could not deduce (a ~ a1)
from the context (CommutativeRing (UPol (Pol a)),
MulMonoid (UPol (Pol a)),
LinSolvRing (Pol a),
CommutativeRing a)
bound by the instance declaration at Pol3_.hs:(313,10)-(314,72)
or from (LinSolvRing (Pol a1), CommutativeRing a1)
bound by the type signature for
dP' :: (LinSolvRing (Pol a1), CommutativeRing a1) =
Domains1 (Pol a1)
at Pol3_.hs:327:12-71
`a' is a rigid type variable bound by
the instance declaration at Pol3_.hs:313:17
`a1' is a rigid type variable bound by
the type signature for
dP' :: (LinSolvRing (Pol a1), CommutativeRing a1) =
Domains1 (Pol a1)
at Pol3_.hs:327:12
Expected type: Pol a1
Actual type: Pol a
In the first argument of `upLinSolvRing', namely p'
In the expression: upLinSolvRing p' Map.empty
In an equation for dP': dP' = upLinSolvRing p' Map.empty
Pol3_.hs:331:20:
Could not deduce (EuclideanRing a) arising from a use of dP'
from the context (CommutativeRing (UPol (Pol a)),
MulMonoid (UPol (Pol a)),
LinSolvRing (Pol a),
CommutativeRing a)
bound by the instance declaration at Pol3_.hs:(313,10)-(314,72)
Possible fix:
add (EuclideanRing a) to the context of the instance declaration
In the second argument of `cToUPol', namely dP'
In the expression: cToUPol y dP' p'
In an equation for s': s' = cToUPol y dP' p'
-
ghc-7.4.1 compiles everything without additions.
Can
Re: DoCon and GHC
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 'forall' on the 'instance' declaration.
Just 'ScopedTypeVariables' should do it
All right, I try to follow both instructions:
-- docon.cabal -
...
extensions:
TypeSynonymInstances UndecidableInstances FlexibleContexts
FlexibleInstances MultiParamTypeClasses OverlappingInstances
RecordWildCards NamedFieldPuns DoAndIfThenElse
.
ghc-options:
-fno-warn-overlapping-patterns -fwarn-unused-binds
-fwarn-unused-matches -fwarn-unused-imports
-XRankNTypes -- ** probably, it spoils nothing
-O
---
-- Pol3_.hs
...
{-# LANGUAGE ScopedTypeVariables #-}-- (1) **
instance (LinSolvRing (Pol a), CommutativeRing a) =
LinSolvRing (UPol (Pol a))
where
gxBasis [] = ([], [])
gxBasis fs@(f:_) = (map back gs, mapmap back mt)
where
UPol _ p y dP= f
(o, n) = (pPPO p, genLength $ pVars p)
(toLex, fromLex) = (reordPol $ lexPPO n, reordPol o)
p' = (toLex p) `asTypeOf` p -- (2) **
dP' :: (LinSolvRing (Pol a), CommutativeRing a) = -- (3) **
Domains1 (Pol a)
dP' = upLinSolvRing p' Map.empty
s' = cToUPol y dP' p'
toOverP' = ct s' . map (\ (a, j) - (toLex a, j)) . upolMons
fromOverP' = ct f . map (\ (a, j) - (fromLex a, j)) . upolMons
back = fromOverP' . headVarPol dP
(gs, mt) = gxBasis $ map (fromHeadVarPol . toOverP') fs
-
This does not help:
-
Pol3_.hs:328:25:
Could not deduce (a ~ a1)
from the context (CommutativeRing (UPol (Pol a)),
MulMonoid (UPol (Pol a)),
LinSolvRing (Pol a),
CommutativeRing a)
bound by the instance declaration at Pol3_.hs:(313,10)-(314,72)
or from (LinSolvRing (Pol a1), CommutativeRing a1)
bound by the type signature for
dP' :: (LinSolvRing (Pol a1), CommutativeRing a1) =
Domains1 (Pol a1)
at Pol3_.hs:327:12-71
`a' is a rigid type variable bound by
the instance declaration at Pol3_.hs:313:10
`a1' is a rigid type variable bound by
the type signature for
dP' :: (LinSolvRing (Pol a1), CommutativeRing a1) =
Domains1 (Pol a1)
at Pol3_.hs:327:12
Expected type: Pol a1
Actual type: Pol a
In the first argument of `upLinSolvRing', namely p'
In the expression: upLinSolvRing p' Map.empty
In an equation for dP': dP' = upLinSolvRing p' Map.empty
Pol3_.hs:331:20:
Could not deduce (EuclideanRing a) arising from a use of dP'
from the context (CommutativeRing (UPol (Pol a)),
MulMonoid (UPol (Pol a)),
LinSolvRing (Pol a),
CommutativeRing a)
bound by the instance declaration at Pol3_.hs:(313,10)-(314,72)
Possible fix:
add (EuclideanRing a) to the context of the instance declaration
In the second argument of `cToUPol', namely dP'
In the expression: cToUPol y dP' p'
In an equation for s': s' = cToUPol y dP' p'
--
Regards,
--
Sergei
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
ticket/4361
Copying to the `bugs' list:
On Fri, Dec 21, 2012 at 12:12:09PM +, Simon Peyton-Jones wrote:
sigh. i suppose I have to reproduce it. I have only docon2.12-pre, and I get
make build
runghc Setup.hs build
Building docon-2.12...
Preprocessing library docon-2.12...
on the commandline: Warning:
-no-user-package-conf is deprecated: Use -no-user-package-db instead
DExport.hs:26:8:
Ambiguous module name `Prelude':
it was found in multiple packages: base haskell98-2.0.0.3
make: *** [build] Error 1
simonpj@cam-05-unx:~/tmp/docon-2.12-pre/docon/source$
How to fix?
http://botik.ru/pub/local/Mechveliani/ghcQuest/d212-pre-asBug.zip
Please, try to compile this d212-pre-asBug
-- as it is written there in install.txt.
I do not know, may be, this docon2.12-pre is a smaller 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-
| From: Serge D. Mechveliani [mailto:mech...@botik.ru]
| Sent: 21 December 2012 11:48
| To: Simon Peyton-Jones
| Cc: glasgow-haskell-bugs@haskell.org
| Subject: Re: DoCon and GHC
|
| 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 'forall' on the 'instance'
| declaration.
| Just 'ScopedTypeVariables' should do it
|
| [..]
| -- Pol3_.hs
| ...
| {-# LANGUAGE ScopedTypeVariables #-}-- (1)
| **
|
| instance (LinSolvRing (Pol a), CommutativeRing a) =
| [..]
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: DoCon and GHC
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 are very close to the edge of what can be done!
It works. Thank you.
There remains only a single unlucky module: T_cubeext.
The test demotest/Main works with exception of T_cubeext,
but I need T_cubeext.cubicExt to work.
Please, continue the test with
make install
cd demotest
ghc $doconCpOpt --make Main
(for $doconCpOpt =
-fwarn-unused-matches -fwarn-unused-binds -fwarn-unused-imports
-fno-warn-overlapping-patterns -XRecordWildCards -XNamedFieldPuns
-XFlexibleContexts -XMultiParamTypeClasses -XUndecidableInstances
-XTypeSynonymInstances -XFlexibleInstances -XOverlappingInstances
).
It reports
--
...
T_cubeext.hs:102:20:
Could not deduce (k ~ k1)
from the context (Field k, FactorizationRing (UPol k))
bound by the type signature for
cubicExt :: (Field k, FactorizationRing (UPol k)) =
k - k - Domains1 k - (Domains1 (E k), [E k], k
- E k)
at T_cubeext.hs:(79,13)-(80,69)
or from (Field k1, FactorizationRing (UPol k1))
bound by the type signature for
unA :: (Field k1, FactorizationRing (UPol k1)) = UPol k1
at T_cubeext.hs:101:9-56
`k' is a rigid type variable bound by
the type signature for
cubicExt :: (Field k, FactorizationRing (UPol k)) =
k - k - Domains1 k - (Domains1 (E k), [E k], k - E
k)
at T_cubeext.hs:79:13
`k1' is a rigid type variable bound by
the type signature for
unA :: (Field k1, FactorizationRing (UPol k1)) = UPol k1
at T_cubeext.hs:101:9
Expected type: Domains1 k1
Actual type: Domains1 k
In the second argument of `cToUPol', namely `dK'
In the expression: cToUPol d dK unK
In an equation for `unA': unA = cToUPol d dK unK
T_cubeext.hs:105:7:
Overlapping instances for LinSolvRing (UPol k1)
arising from a use of `upEucRing'
Matching instances:
instance [overlap ok] EuclideanRing a = LinSolvRing (UPol a)
-- Defined in `docon-2.12:Pol2_'
instance [overlap ok] (LinSolvRing (Pol a), CommutativeRing a) =
LinSolvRing (UPol (Pol a))
...
--
I tried {-# LANGUAGE ScopedTypeVariables, MonoLocalBinds #-},
and setting type signatures in various parts in cubicExt.
But this does not help.
There is another point. In
``cubicExt :: (Field k, FactorizationRing (UPol k)) = ...''
the part ``, FactorizationRing (UPol k)'' (1)
was always considered as parasitic. ghc-7.4.1 needs (1) to work,
and at least ghc-7.4.1 does compile the test.
I thought, may be, the future compilers will allow to omit this part.
At least it is desirable for ghc-7.6.2 to do the test in any variant,
with (1) or without it.
Regards,
--
Sergei
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: DoCon and GHC
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 has become a significant problem to maintain the hack, so I'm taking it out. See http://hackage.haskell.org/trac/ghc/ticket/4361, and the comments I have added there, which tell you what change to make. It's very minor! This will take effect from GHC 7.6 onwards. Thanks Simon It looks like http://hackage.haskell.org is not valid now. Is this due to the recently announced e-mail lists reorganization? How can I see these comments on ticket 4361 ? Regards, Sergei ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4361: Typechecker regression
On Wed, Jun 20, 2012 at 04:55:59PM -, GHC wrote:
#4361: Typechecker regression
-+--
Reporter: igloo | Owner: simonpj
Type: bug | Status: closed
Priority: high| Milestone: 7.0.1
Component: Compiler (Type checker) |Version: 7.1
Resolution: fixed | Keywords:
Os: Unknown/Multiple| Architecture:
Unknown/Multiple
Failure: None/Unknown| Difficulty: Unknown
Testcase: typecheck/should_compile/T4361 | Blockedby:
Blocking: |Related:
-+--
Changes (by simonpj):
* cc: mechvel@??? (added)
Comment:
With all the changes to type inference engine, it has become apparent that
the hack I put in to solve Serge's problem is indeed a GROSSLY UNSAVOURY
HACK.
* It is extremely fragile. It only solves the problem in a special case,
so the very same problem will arise again in a somewhat more complicated
program.
* It takes quite a bit of code.
* It has increasingly unpleasant knock-on effects. Eg `IPRun` has
started failing because a special case for implicit parameters has been
removed. But the special case itself was only needed because of the
GROSSLY UNSAVOURY HACK.
The hack is described in `Note [Avoid unecessary constraint
simplification]` above. I'm taking it out, which will make !DoCon fail to
compile. The culprit is local let generalisation (see
[http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7 my blog
post]). Happily, it's extremely easy to fix your source code in either of
these two ways:
* If you use `-XMonoLocalBinds` (which is in any case implied by
`-XGADTs` and `-XTypeFamilies`), then GHC won't generalise the definition
of `x` in the example, and all will be well.
* Alterantively, give a type signature for `x`, thus (in this case)
{{{
moduloBasisx p = let x :: ()
x = upLinSolvRing p
in ()
}}}
Doing so means that generalisation does not happen, and the constraints
are solved outside-in, as is really desired.
All right.
Later, I shall try your two way outs for DoCon and report the result.
Regards,
Sergei
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5051: Typechecker behaviour change
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 wrote: #5051: Typechecker behaviour change ---+ Reporter: igloo | Owner: simonpj Type: bug | Status: closed Priority: high | Milestone: 7.2.1 Component: Compiler |Version: 7.0.2 Resolution: fixed | Keywords: [..] GHC 7 indeed falls over on `DoCon` 2.12. It turns out to be a rather subtle interaction of overlapping instances with the ill-fated silent superclass parameters I introduced to solve a problem in the typechecker's constraint solver. [..] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
testing 7.02-candidate
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__( Pfact__.hs, dist/build/Pfact__.o ) [68 of 83] Compiling RsePol_( RsePol_.hs, dist/build/RsePol_.o ) RsePol_.hs:214:28: Context reduction stack overflow; size = 21 Use -fcontext-stack=N to increase stack size to N $dSet :: Set (UPol (ResidueE Integer)) $dAddSemigroup :: AddSemigroup (UPol (ResidueE Integer)) $dAddMonoid :: AddMonoid (UPol (ResidueE Integer)) ... $dCast :: Prelude_.Cast (ResidueE (UPol (Pfact__.RseUPolRse Integer))) (UPol (Pfact__.RseUPolRse Integer)) In the first argument of `(.)', namely `ct c1' In the expression: ct c1 . toOverK . resRepr In an equation for `toC': toC = ct c1 . toOverK . resRepr --- So, I add -fcontext-stack=30 to the ghc-options line in docon.cabal. Which one is better at this point, 7.0.1 or 7.0.1.20110217 ? 2. Then, DoCon is built, and the commands cd demotest ghc $doconCpOpt -O -rtsopts --make Main need to `make' the DoCon test under the DoCon library. This reports [ 1 of 17] Compiling T_detinterp ( T_detinterp.hs, T_detinterp.o ) [ 2 of 17] Compiling T_sphGeo ( T_sphGeo.hs, T_sphGeo.o ) [ 3 of 17] Compiling T_cubeext( T_cubeext.hs, T_cubeext.o ) T_cubeext.hs:143:9: Overlapping instances for LinSolvRing (UPol k) arising from a use of `ct' Matching instances: instance [overlap ok] EuclideanRing a = LinSolvRing (UPol a) -- Defined in docon-2.12:Pol2_ instance [overlap ok] (LinSolvRing (Pol a), CommutativeRing a) = LinSolvRing (UPol (Pol a)) -- Defined in docon-2.12:Pol3_ (The choice depends on the instantiation of `k' To pick the first instance above, use -XIncoherentInstances when compiling the other instance declarations) In the first argument of `(.)', namely `ct unE' In the expression: ct unE . kToB In an equation for `kToE': kToE = ct unE . kToB This looks like a bug of the kind appeared in a couple of earlier GHC versions. ghc-7.0.1 is free of both of these effects. What is your opinion about this? http://www.botik.ru/pub/local/Mechveliani/ghcBugs/702candBug.zip is the archive with the project to make and run under ghc-7.0.1, and ghc-7.0.1.20110217 (follow install.txt). Regards, - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
making 7.01-pre
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 `...') - + test -f mk/config.mk.old + cp -p mk/config.mk mk/config.mk.old ... ... inplace/bin/mkdirhier utils/ghc-cabal/dist/build/tmp//. inplace/bin/mkdirhier bootstrapping/. /home/mechvel/ghc/7.01pre/inst1/bin/ghc -H32m -O --make utils/ghc-cabal/ghc-cabal.hs -o utils/ghc-cabal/dist/build/tmp/ghc-cabal ... ... rm -f compiler/stage1/ghc_boot_platform.h Creating compiler/stage1/ghc_boot_platform.h... Done. /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -Iincludes -Irts -DGEN_HASKELL -c includes/mkDerivedConstants.c -o includes/dist-ghcconstants/build/mkDerivedConstants.o ... ... ... utils/genprimopcode/dist/build/Lexer.o: In function `s2yT_info': (.text+0x1e1d): undefined reference to `__stginit_arrayzm0zi3zi0zi2_DataziArray_' ... ... utils/genprimopcode/dist/build/Parser.o: In function `s4pK_info': (.text+0x5691): undefined reference to `__stginit_arrayzm0zi3zi0zi2_DataziArray_' collect2: ld returned 1 exit status make[1]: *** [utils/genprimopcode/dist/build/tmp/genprimopcode] Error 1 make: *** [all] Error 2 - Why cannot it make itself? Regards, - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
unused record fields
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 unused value of t2.
And forf (T {t1 = x, ..}) = x,
it does not warn about this.
Is this a bug?
I use
extensions: TypeSynonymInstances UndecidableInstances FlexibleContexts
FlexibleInstances MultiParamTypeClasses OverlappingInstances
RecordWildCards NamedFieldPuns
ghc-options: -fno-warn-overlapping-patterns -fwarn-unused-binds
-fwarn-unused-matches -fwarn-unused-imports
-O0
,
but the options can be simplified, of course.
Regards,
-
Serge Mechveliani
mech...@botik.ru
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
report on 7.01-pre
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 - instance (LinSolvRing (Pol a), CommutativeRing a) = -- (1) LinSolvRing (UPol (Pol a)) where gxBasis [] = ([], []) gxBasis fs@(f:_) = let UPol _ p y dP= f (o, n) = (pPPO p, genericLength $ pVars p) (toLex, fromLex) = (reordPol $ lexPPO n, reordPol o) p' = toLex p dP' = upLinSolvRing p' Map.empty s' = cToUPol y dP' p' ... - in the module Pol3_.hs, ghc-7.0.0.20100924 reports that the line of `s' =' needs (EuclideanRing a) and that it cannot deduce it. ghc-6.12.2 compiles this in a correct way: (EuclideanRing a) is not necessary here, while the context (1) is more generic and sufficient. For example, for a = DirectSum Integer Integer, `a' has the instances (1) and has not the instance of Euclidean, and the above code must work. This is the idea of the author of the application; this idea is supported by ghc-6.12.2 and not supported by ghc-7.0.0.20100924. There are the two questions. 1) Whether this intention with instances is correct in the meaning of Haskell + ghcExt (I hope, it is correct, at least, ghc-6.12.2 accepts it). 2) If it is correct, why ghc-7.0.0.20100924 requires (Euclidean a) ? Notices --- a) This application uses multiparametric classes and overlapping instances (see docon.cabal for language and other options). b) The example code can be reduced further, many times. But I may have time to reduce it maybe only in the middle of December 2010. Regards, - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: profiling,-O in 6.12.1
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 95% for eLoop, and adding -O to this line shows 0% for eLoop, independently on presence of -auto-all in this line (the whole library is made under -O -prof). Yes, I recall that the effect may be of inlining. Simon Marlow wrote on Thu, Feb 04, 2010 Inlining should not in general affect the shape of the profile. I can't say much else here without seeing the specific code. Finally, by setting -O0 -prof I have found who of top-levels takes most of time -- hopefully, the same functions will occur for -O. I do not know, maybe, this is a known bug (Simon writes, there exists some report). Anyway, it is important to debug profiling -- to making unnecessary any irregular tricks with -inline-not. Dear GHC team, if I put my project to a public place, would you find out what is the effect there about -O -prof ? Although the whole program is large, but probably, the very example with `main' + Complete.complete + a single SCC, is simple for you to detect the effect source. Regards, - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
profiling,-O in 6.12.1
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 source. eLoop must take almost all the time. My whole user library is made under -O -prof, and --enable-library-profiling. Main is compiled by ghc $dmCpOpt -prof --make Main and run by ./Main +RTS -M400m -pT -RTS For this key, the profiling report Main.prof looks natural and shows eLoop -- 97%. But forghc $dmCpOpt -O -prof --make Make, it shows a different thing: zero for eLoop and 99% for `main'. How could this additional -O mislead the compiler? Also, as I recall, -O is still by default -- ? Could you explain, please? Regards, - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
testing 6.12.1-pre
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, - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
bug in 6.12.1-pre
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 :: a - a - a ghc -c -O Bug.hs reports /tmp/ghc29984_0/ghc29984_0.s: Assembler messages: /tmp/ghc29984_0/ghc29984_0.s:23:0: Error: symbol `Bug_compose1_closure' is already defined /tmp/ghc29984_0/ghc29984_0.s:102:0: Error: symbol `Bug_compose1_info' is already defined `-O' is essential here. Regards, - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
my last letter
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 runs out of RAM. And personally, I would rather use +RTS -M15000m -RTS and not to consider at all the system effects after the RAM overflow. Third, I apply now a more clear example, whith [Int] instead of [Integer]: - import List (genericReplicate) main = putStr (shows res \n) where e = -- 22, 23 ... list = genericReplicate (2^e) 1 :: [Int] rList = reverse list res = myMin $ zipWith (+) list rList myMin [] = error \nmyMin []\n myMin [x]= x myMin (x: y: xs) = if x y then myMin (y: xs) else myMin (x: xs) -- ghc -O --make Test64 ./Test64 +RTS -M800m -RTS -- for 1 Gb 32 bit machine ./Test64 +RTS -M12000m -RTS -- for 16 Gb 64 bit machine The last possible e for the small machine (800 Mb) occurs 24, for the big machine (12000 Mb) occurs 27 -- which looks reasonable. The timing also looks reasonable. Regards, - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
testing 6.10.2 on X_64
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.8.3 (from Linux distribution). Then, I `made' ghc-6.10.2 from source by ghc-6.8.3: ./configure --prefix=/home/mechvel/ghc/6.10.2/inst0 make make install Everything looks all right. Then, I try processing long lists: -- Test64.hs main = putStr (shows res \n) where e = 30 list = [1 .. (2^e)] :: [Integer] rList = reverse list res = myMin $ zipWith (\ n m - rem (n+m) 3) list rList myMin [] = error \nmyMin []\n myMin [x]= x myMin (x: y: xs) = if x y then myMin (y: xs) else myMin (x: xs) --- For e = 20, it runs as [mech...@node-1 t]$ ./Test64 2 -- all right. For e = 30, it runs as [mech...@node-1 t]$ ./Test64 Killed Who has killed it? Is this by the local administrator's restriction ? Another attempt: [mech...@node-1 t]$ ./Test64 +RTS -M4000m -RTS Test64: internal error: get_threaded_info (GHC version 6.10.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted Qestion aside - List.minimum again, performs badly in ghc-6.10.2, so I used myMin. Is List.minimum (and similar functions) being compiled by default with -O0 ? Regards, - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
seg-fault in 6.10.1
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, and now it works correct. Are you interested in the bug report on the above part of Segmentation fault ? - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
mapRecordField
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
mapField opAttrs cp fam,
with an intended library function mapField -- which does not agree
with Haskell types.
But as GHC takes care to provide a language extension for records,
maybe it could introduce mapField as the language construct and
as a reserved word?
Also I do not know, maybe, something like fam {opAttrs = cp opAttrs}
is possible now?
Thank you in advance for your explanation,
-
Serge Mechveliani
[EMAIL PROTECTED]
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
-XDisambiguateRecordFields
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 everywhere in flags? Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
6.8.3 against DoCon
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 docon again breaks with the heap exhaustion for -M500m. So this memory is spent to compile a single current module. -- The last (difficult) module is RsePol_. And `make' is slower than in 6.8.2, at least at this module. I do not believe that a reasonable compiler may need more than 500 Mb for compiling this poor RsePol_. Second, for the candidate version I reported to the e-mail lists the two problems. The second one was about this memory and time strangeness in compiling RsePol_. Now, you issue an official release, without even considering the second problem. I do not know, maybe this RsePol_ is somehow too irregular (with overlapping instance, etc.), maybe, DoCon is guilty. But as ghc-6.8.2 handles DoCon all right, why do not you investigate this difference in 6.8.3 ? Actually, ghc-6.8.3 does not support DoCon. I wonder what to do. Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: 6.8.3 against DoCon
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 are in this trac ticket: http://hackage.haskell.org/trac/ghc/ticket/2328 but the conclusion was that overall it was best to leave things as they are. Unfortunately, this means that performance with GHC 6.8.3 is worse for DoCon; hopefully things will be better with 6.10.1! Yes, I see. Thank you for paying attention to this problem. I would like to add the following notes about comparison of ghc-6.8.2 and ghc-6.8.3. 1. As you already knew, abot 3 times slow down is visible in making a certain part of DoCon-2.11 -- due to the module RsePol_. 2. RsePol_.hs is only about 400 lines, together with comments. ghc-6.8.2 suffices -M80m to compile RsePol_.hs. ghc-6.8.3 needs more than -M600m for this. 7 times loss in space. There are many computers which have not 600 Mb RAM. So, DoCon remains with ghc-6.8.2 -- untill GHC fixes the problem. Hm ... a small module needs 600 Mb instead of 80 Mb to compile, and the release is considered as a progress. All right, this may occur correct -- if the developers know what namely must be fixed, and also know how to fix it. If so, then I could believe. By the way, not only 6.8.3 looks strange: even 80 Mb looks like an un-naturally large minimum for compiling this small RsePol_.hs. In symbolic computation, in the DoCon test running, in my Dumatel prover test, most examples take less than 40 Mb to perform, while I write all this in Haskell and do not care much for the code optimization. Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
test for 6.8.3-may27
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] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
SCC ab cd
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?
Regards,
-
Serge Mechveliani
[EMAIL PROTECTED]
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
bug in may27 candidate
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.haskell.org/mailman/listinfo/glasgow-haskell-bugs
hs-boot types in 6.8.2
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-boot. When GHC `makes' this project (under Cabal), it first processes Reduce[boot], and then gets to Split.hs: -- [16 of 45] Compiling Dumatel.Reduce[boot] ( Dumatel/Reduce.hs-boot, dist/build/Dumatel/Reduce.o-boot ) [17 of 45] Compiling Split( Split.hs, dist/build/Split.o ) Split.hs:393:58: Couldn't match expected type `Term' against inferred type `[a]' In the third argument of `evaluate_c', namely `[]' ... - -- and it only reports of several type mismatches in Split.hs. If the user guesses to fix the type in Reduce.hs-boot, the `make' improves. In many situations, GHC reports first what namely is the type disagreement between *.hs and *.hs-boot. But not in this situation. And here the report is misleading: the user looks into Reduce.hs and Splis.hs, and wonders what is wrong with types. Can this be fixed ? If you ask me, I would provide the source on www. Thank you in advance for your explanation. - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: hs-boot types in 6.8.2
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 Reduce.hs-boot and Reduce.hs until we have typechecked Reduce.hs, and we can't do that until we have compiled Split.hs. I see. Thank you. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: -O in 6.8.1-candidate
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 comment it out of the cabal file. You will however if you explicitly turn off optimisations: ghc-options: -Onot or: cabal-setup configure --disable-optimization since the default is --enable-optimization which with ghc uses -O For GHC, it is necessary for the .cabal file to provide the field `ghc-options:', and the optimization keys are of this field. Hence, is not this confusing to allow the optimization keys anywhere else? Also seeing `--enable-optimization' the user needs also to recall of what kind of optimization is it. The ghc-options field allows you to pass anything flags you like to ghc. That does not mean that you should! :-) Cabal is supposed to be portable between Haskell implementations and to allow packages to also be portable. Some Haskell implementations provide a notion of optimisation and so Cabal supports that with the --enable-optimization flag. There's an additional advantage here, we can let the user decide if they want to build with or without optimization. With the ghc-options field, only the developer gets to decide. So, in summary it's much better not* to use lines like: ghc-options: -O and to let the user manage that with Cabal's --enable-optimization flag (which is on by default). If you have specific ghc optimisations that you really need to be applied, then it's ok to use the ghc-options: field. For example we use that in bytestring. The --enable-optimization flag also applies to other things, like compiling C code and in principle could apply to other tools like happy/alex, though at the moment it does not. Duncan Currently, my DoCon application has the file docon.cabal, with the field ghc-options: many options ... -O +RTS -M400m -RTS -- -prof -- -auto-all This file defines how to build the DoCon library. And a DoCon user is invited to comment-out or un-comment, or change any of the last 4 lines in this field definition. By this, the user defines, for example, whether to compile the library with -O, with -O2, or with -Onot. The meaning of these options is explained in the GHC documentation. If it also aimed to build under, say, HBC tool, then, I would probably need to add the field hbc-options: ... and set there the keys according their meaning explained in the HBC documentation. This was my idea. I do not know ... Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
-O bug?
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 will loop forever or it will take an unnaturally large resource. Yes, the functions T_.test, T_tt are defined in rather a particular way (see them). I always build this test under -Onot, because compiling with optimization has not much sense for this part. But slill. (2) -O2 In my DoCon programs, -O2 was always worse than -O: the code is about 1.3 times larger and 1.2 times slower. There are some particular points in my programs. For example, almost everywhere I set Integer rather than Int, I do not recall others, now. In never complained on (1) and (2) because did not recall of them and because they do not bite me in practice, so far. - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
6.8.1-candidate tested
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 ghc-6.6.1, 2) its produced .a code is 1.6 times larger, 3) the test runs 1.4 times faster, 4) the minimal space (2500 Kb) for the test running remains. This looks all right. Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: bug in 6.8.1-candidate
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 of modules imported but not used. If I remove this import, it will report an error of not finding of a certain _instance_. May be, this warning message must be improved? 2. Running test. Some 6.8* versions can do make build for docon-2.10, but cannot `make' the test. According to install.txt, the test has to do a bit more. This log is only for make configure; make build And it is also needed to test this: make install cd demotest ghc $doconCpOpt --make Main-- making and ./Main +RTS -M60m -RTS -- running the DoCon test (see install.txt about $doconOpts). This test must report in the end of its log: no errors detected. 3. Making ghc by ghc (by 6.6.1 and then, by itself). This must work. 4. Space. It is desirable to test the space eagerness in comparison to ghc-6.6.1. For example, if this ./Main running does not succeed within -M50m, then this is suspicious. 5. -Onot As I recall, the default `make' for docon is under -O, and it is also desirable to test -Onot and repeat making and running ./Main. Because users often like to build things under -Onot. 6. Profiling is a usable tool. It is desirable to re-make DoCon under -O -prof -auto-all (at least) and print the pro-file for -pT for demotest/Main running. For example, if it breaks, at any stage, or shows some strange time per-centage, then GHC is buggy. Usually I do all this myself. - And I can do this now as well -- if I know precisely 1) where to take the needed 6.8-candidate in source 2) that ghc-6.6.1 can build this 6.8-candidate from source. But if the GHC developers do themself the points (1) - (6) for docon-2.10, I shall be grateful to them for saving my effort. Regards, --- Mechveliani I'm in docon-2.10/docon/source bash-2.05b$ make configure runhaskell Setup.hs configure --ghc \ --with-compiler=/playpen/ghc/nightly/STABLE-cam-02-unx/i386-unknown-linux/compiler/stage2/ghc-inplace \ ... [..] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
-O in 6.8.1-candidate
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, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: -O in 6.8.1-candidate
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 recommend using -O2 these days, particularly for a library like docon where performance matters. ghc-options: -O2 No, -O2 is worse than -O ! Build the public docon with ghc-6.8.1-candidate under -O and under -O2. Under -O2 1) it is 10% larger and 10% longer to build, 2) demotest/Main runs 10% slower. And the following is close to a bug report: cd demotest ghc $doconCpOpt -O --make Main-- building docon test compiles long and takes 900 Mb of RAM, and after this I kill the process. The same is for ghc $doconCpOpt -O2 --make Main I think, there is not any particular reason to compile the test under -O, usually I apply -Onot here. But still, this very long compilation and 900 Mb are suspicious. Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: bug in 6.8.1-candidate
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 Ian should have merged them to the 6.8 branch. It'd be great to hear back from you to know whether things are now ok. Please let us know -- meanwhile I'll file your messages about DoCon. Simon Thank you. Now, I search for `HEAD', looking into http://haskell.org/ghc/download.html, and it shows HEAD branch (development snapshots): * Download snapshot distributions I click at (*), and it is http://www.haskell.org/ghc/dist/current/dist/, and it keeps many ghc sources, but no 6.8* among them. Need I to take ghc-6.9.20071013-src.tar.bz2 of October 13 ? --- Mechveliani ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: bug in 6.8.1-candidate
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 can try. Actually, Serge, you can find STABLE (i.e. 6.8 branch) snapshots here: http://haskell.org/ghc/download.html There's no Windows installer in the last few days, for reasons Simon is looking into, but the source distributions should be fine. I'd wait until after tonight, to be sure Ian's merges have all gone in. Simon Do you mean that http://haskell.org/ghc/dist/stable/dist/ghc-6.8.0.20071013-src.tar.bz2 of October 13 will do? --- Mechveliani ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: bug in 6.8.1-candidate
ghc-6.8.0.20071013-src.tar.bz2 (October 13) is buggy, it cannot build the DoCon test module, starts to `panic'. Now, I shall try http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.0.20070914-src.tar.bz2 On the other hand, whatever GHC version the developers would like to test, they can easily take the public docon-2.10 and follow install.txt. The only two small points for porting from ghc-6.6.1 to 6.8* are * replacing runhaskell with runghc in source/Makefile, * adding ``, containers'' to the line of build-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- | From: Serge D. Mechveliani [mailto:[EMAIL PROTECTED] | Sent: 15 October 2007 15:41 | To: Simon Peyton-Jones | Cc: glasgow-haskell-bugs@haskell.org | Subject: Re: bug in 6.8.1-candidate | | 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 can try. | | Actually, Serge, you can find STABLE (i.e. 6.8 branch) snapshots here: | | http://haskell.org/ghc/download.html | | There's no Windows installer in the last few days, for reasons Simon is looking into, but the source | distributions should be fine. I'd wait until after tonight, to be sure Ian's merges have all gone in. | | Simon | | | Do you mean that | | http://haskell.org/ghc/dist/stable/dist/ghc-6.8.0.20071013-src.tar.bz2 | of October 13 | will do? | | --- | Mechveliani ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
ghc for docon-2.10
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 preprocessor expression ghc: 15634792 bytes, 4 GCs, 122880/122880 avg/max bytes residency (1 samples)\, 16M in use, 0.00 INIT (0.00 elapsed), 0.00 MUT (0.03 elapsed), 0.01 GC (0.01 \elapsed) :ghc make[2]: *** [cbits/unicode.o] error1 make[1]: *** [boot] error 2 make: *** [stage1] error 1 Dear GHC developers, please try any appropriate ghc-6.8* candidate for making the public docon-2.10 and running its test module. Porting to 6.8 is simple: 1) runhaskell -- runghc (in Makefile) 2) build-depends: + , containers (in docon.cabal). Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
bug in 6.8.1-candidate
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, ghc reports of `panic'. Further, return to the project build: in the file GBasFld.hs, comment-out the type declaration for the function b_criterion_ev, and re-build the project. Now, it reports of `panic' when compiling GBasFld. Simply speaking, docon-2.11 works under ghc-6.6.1 and does not work under ghc-6.8.0-sep28.zip. Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
bug in 6.8.1-candidate
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_lbl Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- This happens in the middle of the DoCon-2.11 `make'. Can you wait with ghc-6.8.1 ? Another point: the module Char_ exports several instances, and the module DPrelude has `module Char_' in its export list, and ghc-6.8.0.20070928-src reports that this latter decl exports nothing. Probably, it must report exports nothing, besides maybe, some instances ? Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
bug in 6.8.1-candidate
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 ... many modules compiled GBasFld_.hs: ... ghc-6.8.0.20070928: panic! (the 'impossible' happened) (GHC version 6.8.0.20070928 for i386-unknown-linux): initC: srt_lbl Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug unzip it, please, and see install.txt. Then, see GBasFld_.hs, it is small, and it looks like ghc cannot compile it. In ghc-6.6.1, this project works all right. The project can easily be reduced to the size of about a single GBasFld_.hs module (see install.txt). Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
runhaskell in 6.8
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 to you have against runhaskell ? Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
6.8 fails to make
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 -\istage2/types -istage2/hsSyn -istage2/prelude -istage2/rename -istage2/type\check -istage2/deSugar -istage2/coreSyn -istage2/vectorise -istage2/special\ise -istage2/simplCore -istage2/stranal -istage2/stgSyn -istage2/simplStg \-istage2/codeGen -istage2/main -istage2/profiling -istage2/parser -istage2/\cprAnalysis -istage2/ndpFlatten -istage2/iface -istage2/cmm -istage2/native\Gen -istage2/ghci -Wall -fno-warn-name-shadowing -fno-warn-orphans -Istage2 -p\ackage hpc -package bytestring -DGHCI -package template-haskell -DGHCI_TABLES_N\EXT_TO_CODE -package readline -DUSE_READLINE -cpp -fglasgow-exts -fno-generics \-Rghc-timing -I. -Iparser -package unix -package Cabal -ignore-package lang -re\comp -Rghc-timing -H16M '-#include cutils.h' -package-name ghc-6.8.20070912\ -fgenerics-c main/InteractiveEval.hs -o stage2/main/InteractiveEval.o -\ohi stage2/main/InteractiveEval.hi main/InteractiveEval.hs:349:16: parse error on input `Exception.throwIO' ghc: 20812448 bytes, 4 GCs, 128588/128588 avg/max bytes residency (1 samples)\, 16M in use, 0.00 INIT (0.00 elapsed), 0.01 MUT (0.04 elapsed), 0.02 GC (0.01 \elapsed) :ghc make[2]: *** [stage2/main/InteractiveEval.o] Ошибка 1 make[2]: Leaving directory `/home/mechvel/ghc/6.8-test/ghc-6.8.20070912/compile\r' make[1]: *** [stage2] Ошибка 2 make[1]: Leaving directory `/home/mechvel/ghc/6.8-test/ghc-6.8.20070912' make: *** [bootstrap2] Ошибка 2 -- Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
skipping module in .cabal
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. 1. (minor note) The file Match.hs-boot is not needed. All the effects preserve after its removal. 2. The name `Match' must be in the list `other-modules:' in the file dm.cabal,which describes the package. But it is not in dm.cabal ! Because I have forgotten to put it there. Further, make build still finds and compiles Match.hs. The only point where Match is needed is Reduce.hs: it imports `Match'. But why GHC finds Match.hs ? Probably, because it is in the current source directory. Then, make install succeeds. And further, the command ghc $dmCpOpt --make Main succeeds or not -- depending on whether `Match' is in dm.cabal or not! First, I think that there is my oversight here. But the GHC + Cabal system behaves strange in this example. Must not it give a plain report of what is wrong with modules or package setting ? Say, Error: `Match' is not in the package but is imported by Reduce.hs. Probably, this is the matter of Cabal. Further, if GHC still finds Match.hs and builds the package, why this undefined reference appears while linking executable ? Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
un-existing import in boot-module
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 report of this `M'. - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: #945: `waitForProcess'
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| Milestone: 6.6.1 Component: Compiler |Version: 6.6 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: Unknown Os: Linux | --- Changes (by igloo): * cc: = [EMAIL PROTECTED] Comment: Hi Serge, Do you have a testcase we can reproduce this with? Thanks Ian When reporting, I tried to write down some description by copying by mouse to the field 'comment' (as I recall) but, probably, misused the page interface. Probably, it visible only `waitForProcess' report in `install' in ghc-6.6. I somehow got used to this, changed something in the command sequence (do not recall what namely). So, this effect is visible very rarely now. Let us wait for next occasion. Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
profiling in Cabal in 6.4.1-aug-1
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. Without profiling, it `makes' and installs. For profiling, dm.cabal adds -prof -auto-all -hisuf p_hi -osuf p_o to its options. The commands runhaskell Setup configure --ghc --prefix=$dmSource/inst runhaskell Setup build seem to work all right. Then, runhaskell Setup install --user reports Installing: /home/mechvel/dm/1.03/dm/source/inst/lib/dumatel-1.3 /home/mechvel/dm/1.03/dm/source/inst/bin dumatel-1.3... Error: Could not find module: Dumatel with any suffix: [hi] And the directory $dmSource/dist/build/ contains Dumatel.p_hi, Dumatel.p_o among its files. dm.cabal is name:dumatel version: 1.3 build-depends: data exposed-modules: Dumatel Dumatel.Prelude Dumatel.Prelude5 Dumatel.TermComp Dumatel.Reduce Dumatel.CritPair Dumatel.KBC Dumatel.Bool Dumatel.BTerm Dumatel.ReduceBT Dumatel.UKBB Dumatel.Prover Dumatel.DemoTest.TestDumatel.DemoTest.T_kbcTrad Dumatel.DemoTest.T_ukb Dumatel.DemoTest.T_logicSimp Dumatel.DemoTest.T_nat Dumatel.DemoTest.T_list . other-modules: Prelude0 Prelude0_0 Prelude1 Prelude2 Prelude2_0 Prelude3 Prelude3_0 Prelude3_1 Prelude4 Bool0 BTerm0 BTerm1 Prover0 Parse1 Parse2 Parse3 Prover1 Prover2 Prover3 Dumatel.DemoTest.Test0 . ghc-options: -fglasgow-exts -fallow-undecidable-instances -fallow-overlapping-instances -fno-warn-overlapping-patterns -fwarn-unused-binds -fwarn-unused-matches -fwarn-unused-imports -O -prof -auto-all -hisuf p_hi -osuf p_o -- Who is in error, please, GHC or myself? - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
making 6.4.1-aug-1 with itself
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 -fglasgow-exts -cpp -Iinclude -#include HsBase.h -funbox-strict-fields -ignore-package base -O -Rghc-timing -fgeneri\cs -fgenerics -split-objs-c GHC/Dotnet.hs -o GHC/Dotnet.o -ohi GHC/Dotnet.hi ... ... ( cd GHC/Dotnet_split; rm -f ld.script; touch ld.script; echo INPUT( *.o ) ld.script; /usr/bin/ld -r -x -o ../Dotnet.o ld.script; ); rm -f GHC/PArr.o; if [ ! -d GHC/PArr_split ]; then mkdir GHC/PArr_split; else \usr/bin/find GHC/PArr_split -name '*.o' -print | xargs rm -f __rm_food; fi; ../../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 -split-objs-c GHC/PArr.hs -o GHC/PArr.o -ohi GHC/PArr.hi ghc-6.4.1.20050801: internal error: evacuate: strange closure type 2160 Please report this as a bug to glasgow-haskell-bugs@haskell.org, or http://www.sourceforge.net/projects/ghc/ make[2]: *** [GHC/PArr.o] Error 254 make[1]: *** [all] Error 1 make[1]: Leaving directory `/home/mechvel/ghc/6.4.1-aug-1/ghc-6.4.1.20050801/libraries' make: *** [build] Error 1 - If the GHC developers need the archive with config.log and make.log, let them give me the address to send it to. - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: making 6.4.1-aug-1 with itself
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 -split-objs-c GHC/Dotnet.hs -o GHC/Dotnet.o -ohi GHC/Dotnet.hi ... ... ( cd GHC/Dotnet_split; rm -f ld.script; touch ld.script; echo INPUT( *.o ) ld.script; /usr/bin/ld -r -x -o ../Dotnet.o ld.script; ); rm -f GHC/PArr.o; if [ ! -d GHC/PArr_split ]; then mkdir GHC/PArr_split; else \usr/bin/find GHC/PArr_split -name '*.o' -print | xargs rm -f __rm_food; fi; ../../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 -split-objs-c GHC/PArr.hs -o GHC/PArr.o -ohi GHC/PArr.hi ghc-6.4.1.20050801: internal error: evacuate: strange closure type 2160 Please report this as a bug to glasgow-haskell-bugs@haskell.org, or http://www.sourceforge.net/projects/ghc/ make[2]: *** [GHC/PArr.o] Error 254 make[1]: *** [all] Error 1 make[1]: Leaving directory `/home/mechvel/ghc/6.4.1-aug-1/ghc-6.4.1.20050801/libraries' make: *** [build] Error 1 - Hmm, another occurrence of the elusive GC bug. I can't repeat this one either. Can you check that it is repeatable for you: $ cd libraries/base $ rm GHC/PArr.o $ make GHC/PArr.o and let me know whether you get the same crash repeatedly. PArr.o was not there. I apply the above commands, and they report - rm -f GHC/PArr.o; if [ ! -d GHC/PArr_split ]; then mkdir GHC/PArr_split; else /usr/bin/find GHC/PArr_split -name '*.o' -print | xargs rm -f __rm_food; fi; ../../ghc/compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude -#include HsBase.h -funbox-strict-fields -ignore-package base -O -Rghc-timing -fgenerics -fgenerics -split-objs-c GHC/PArr.hs -o GHC/PArr.o -ohi GHC/PArr.hi ghc: 262247264 bytes, 48 GCs, 4479368/9051336 avg/max bytes residency (4 samples), 20M in use, 0.04 INIT (0.03 elapsed), 4.30 MUT (19.20 elapsed), 1.36 GC (2.90 elapsed) :ghc ( cd GHC/PArr_split; rm -f ld.script; touch ld.script; echo INPUT( *.o ) ld.script; /usr/bin/ld -r -x -o ../PArr.o ld.script; ); and stops, with PArr.o ready. It looks like we fail to repeat the crash. Could you also try this: $ rm GHC/PArr.o $ make GHC/PArr.o EXTRA_HC_OPTS=+RTS -C0 -RTS which might help to make it more repeatable (that disables the context switch timer). It reports rm -f GHC/PArr.o; if [ ! -d GHC/PArr_split ]; then mkdir GHC/PArr_split; else /usr/bin/find GHC/PArr_split -name '*.o' -print | xargs rm -f __rm_food; fi; ../../ghc/compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude -#include HsBase.h -funbox-strict-fields -ignore-package base -O -Rghc-timing -fgenerics -fgenerics -split-objs +RTS -C0 -RTS -c GHC/PArr.hs -o GHC/PArr.o -ohi GHC/PArr.hi ghc: 263003692 bytes, 57 GCs, 4518303/9088788 avg/max bytes residency (4 samples), 20M in use, 0.04 INIT (0.00 elapsed), 4.12 MUT (12.96 elapsed), 1.52 GC (1.54 elapsed) :ghc ( cd GHC/PArr_split; rm -f ld.script; touch ld.script; echo INPUT( *.o ) ld.script; /usr/bin/ld -r -x -o ../PArr.o ld.script; ); and stops, with PArr.o ready. - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
making 6.4.1-pre-July-12 by itself
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.4.1-pre of CVS of July 12, 14.00 GMT. I reset the path to the July-12 install place, and for more safety, move the installation directory of June-14 to other place. which ghc /home/mechvel/ghc/cvs/pre6.4.1/inst/bin/ghc which ghc-pkg /home/mechvel/ghc/cvs/pre6.4.1/inst/bin/ghc-pkg -- this is ghc-July12-9.00, as needed. Now, `making' ghc-July12-14.00 with ghc-July12-9.00 reports - ... ... /home/mechvel/ghc/cvs/pre6.4.1/inst/bin/ghc -H16m -O -I. -Iinclude -Rghc-timing -I../../../libraries -fglasgow-exts -no-recomp -c System/Directory/Internals.hs -o System/Directory/Internals.o -ohi System/Directory/Internals.hi System/Directory/Internals.hs:1:0: conflict: module `System.Directory.Internals' belongs to the current program/library and also to package base-1.0 ghc: 18868296 bytes, 5 GCs, 79280/79280 avg/max bytes residency (1 samples), 16M in use, 0.02 INIT (0.00 elapsed), 0.16 MUT (0.21 elapsed), 0.08 GC (0.10 elapsed) :ghc 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/mechvel/ghc/cvs/pre-6.4.1-July-12/fptools/ghc'make: *** [build] Error 1 --- What we have to do with this, please? - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
make fail for 6.4.1-pre-July-11
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 -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/c\odeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/compMan -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -istage1/ghci -Istage1 -DGHCI -package template-haskell -package ... ... ... rename/RnExpr.lhs:85:4: Couldn't match `IOEnv (Env TcGblEnv TcLclEnv) (a, FreeVars)' against `t - \t1' Expected type: IOEnv (Env TcGblEnv TcLclEnv) (a, FreeVars) Inferred type: t - t1 Expected type: a1 - b Inferred type: RnM (a, FreeVars) Probable cause: `rnPatsAndThen' is applied to too many arguments in the call (rnPatsAndThen ctxt True pats) ghc: 76871052 bytes, 21 GCs, 4067284/8625320 avg/max bytes residency (4 sampl\es), 19M in use, 0.02 INIT (0.00 elapsed), 0.97 MUT (1.10 elapsed), 0.90 GC (0.\90 elapsed) :ghc make[2]: *** [stage1/rename/RnExpr.o] Error 1 make[1]: *** [all] Error 1 make[1]: Leaving directory `/home/mechvel/ghc/cvs/pre6.4.1/fptools/ghc' make: *** [build] Error 1 --- ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
make fail for 6.4.1-pre
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 Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
reading in ghci-6-4-branch
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 ./a.out True press Enter press Control-d True And it does not work under ghci: -- ghci ReadBug.hs ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.4.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base-1.0 ... linking ... done. Compiling Main ( ReadBug.hs, interpreted ) Ok, modules loaded: Main. (0.08 secs, 3210432 bytes) *Main main True ^D*** Exception: Prelude.read: no parse *Main Is this a GHC bug? Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
source subdirectory in package
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 version: 0.0 build-depends: data exposed-modules: U1 V1 ghc-options: -isubdir - Then, runhaskell Setup.hs configure --ghc --prefix=$HOME/t/user1/inst and runhaskell Setup.hs build yield Preprocessing library u1-0.0... can't find source for V1 in [.] Why this is so? With kind regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
irrelevant package
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 produces configuring ... compiling ... ... DPrelude.hs:1:0: Module `DPrelude' is a member of package dumatel-1.2.6.4. To compile this module, please use -ignore-package dumatel-1.2.6.4. These does exist a package dumatel-1.2.6.4, and both the above packages have DPrelude among the module names. But why does Cabal look into irrelevant package? The dependence is set: only `data'. ghc-pkg -l shows /usr/lib/ghc-6.4/package.conf: rts-1.0, base-1.0, haskell98-1.0, template-haskell-1.0, unix-1.0, Cabal-1.0, parsec-1.0, haskell-src-1.0, network-1.0, QuickCheck-1.0, HUnit-1.1, mtl-1.0, fgl-5.2, X11-1.1, HGL-3.1, stm-1.0, readline-1.0, (lang-1.0), (concurrent-1.0), (posix-1.0), (util-1.0), (data-1.0), (text-1.0), (net-1.0), (hssource-1.0) /home/mechvel/.ghc/i386-linux-6.4/package.conf: dumatel-1.2.6.4 The package specification is -- name:docon version: 2.9 license-file:../../license.txt copyright: Serge Mechveliani (2005) author: Serge Mechveliani maintainer: [EMAIL PROTECTED] homepage:http://www.botik.ru/pub/local/Mechveliani/docon/ package-url: http://www.botik.ru/pub/local/Mechveliani/docon/ http://www.haskell.org/docon/distrib/ synopsis:computer algebra program written in Haskell tested-with: GHC build-depends: data exposed-modules: DExport DPrelude Categs SetGroup RingModule DPair Z Fraction VecMatr LinAlg Pol GBasis Residue Permut Partition AlgSymmF . other-modules: Iparse_ OpTab_ Categs_ DPair_ Matr0_ Ring0_ Semigr_ Vec1_ Char_ Fract_ Matr1_ Ring1_ Set_ Vec_ Common_ List_ Prelude_ Ring_ Vec0_ Det_ Stairc_ Todiag_ IdealSyz_ ResEuc0_ ResEuc_ ResRing__ RsePol0_ QuotGr_ ResEuc1_ ResPol_ ResRing_ RsePol_ EPol0_ Pgcd_ Pol_ RPol0_ EPol1_ FreeMonoid Pol1_ PolNF_ RPol_ EPol_ GBasEuc_ Pol2_ Polrel_ FAA0_ GBasFld_ Pol3_ PP_ UPol0_ FAANF_ GBas_ Pol__ RdLatP_ UPol_ Pfact0_ Pfact1_ Pfact2_ Pfact3_ Pfact__ Pfact_ HookBand_ Partit_ SymmFn0_ SymmFn1_ SymmFn_ Sympol_ . ghc-options: -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances -fno-warn-overlapping-patterns -fwarn-unused-binds -fwarn-unused-matches -fwarn-unused-imports --- With kind regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
possible real bug in 6.2.2
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
_ - ProofResult {field = abc}
never reaches the `Just' branch,
and replacing the `case' construct with (ProofResult ...)
changes the whole result greatly.
The effect is due to a complex code for mbPair,
its intensive work with memory, etc.;
and the `case' replacement avoids the mbPair computation.
(can all this happen without a bug?)
I am trying to reduce the example. The program is too complex.
I need greatly a reliable ghc-6.2.2.xx tool.
-
Serge Mechveliani
[EMAIL PROTECTED]
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: possible real bug in 6.2.2
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 `making' bug. If it occurs, for example, due to a bug in the garbage collection, then any computation is damaged. - Serge Mechveliani [EMAIL PROTECTED] On Tue, Oct 19, 2004 at 05:12:54PM +0100, Simon Peyton-Jones wrote: Serge I tried your example, and can reproduce what you see. But it doesn't seem surprising to me. The way in which you could get this behaviour is this: - the call to reduceInInitialAnyEquationInFormula indirectly calls proveRLiteral and evaluates the proofResTheoryExt part of its result which makes the program print debugTail thExt But if you don't evaluate mbPair, then the first call to proveRLiteral returns immediately, and its caller evalutes the proofResTrace part of the result. [..] ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
GHC page
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 anonymous ftp) ? With kind regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: GHC page
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/dist/6.2.2/ ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
memory error in 6.2.2
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 No old interface available Source file changed or recompilation check turned off FYI: cannot read old interface file: /home/mechvel/docon/2.08/docon/source/export/RsePol0_.hi: openBinaryFile: does not exist (No such file or directory) Compiling RsePol0_ ( residue/RsePol0_.hs, /home/mechvel/docon/2.08/docon/source/export/RsePol0_.o ) residue/RsePol0_.hs:14: Warning: Module `Pol2_' is imported, but nothing from it is used (except perhaps instances visible in `Pol2_') INTERFACE HAS CHANGED No old interface available ghc-6.2.2: internal error: scavenge_mark_stack: unimplemented/strange closure type 30 @ 0x40cd2d04 Please report this as a bug to [EMAIL PROTECTED], or http://www.sourceforge.net/projects/ghc/ make: *** [obj] Error 254 Then, I restart `make', and it builds. The test is all right. Also `making' with -M30m avoids this error, as well as making with -O -M60m. Probably, there is a bug in the memory management. In the next letter, I am sending docon-2.08.zip to Simon Marlow and Simon P. Jones, so that you could try to reproduce the effect. Follow install.txt and apply make space=-M40m docon (-Onot). But on other system, it may require different -M option to run into such error. - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
`partition'
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? - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: `partition'
Indeed, could it? For 6.2.2 is have not been released so far ... On Thu, Oct 14, 2004 at 12:02:20PM +0200, Josef Svenningsson wrote: A little browsing in the CVS reveals that partition is fixed in GHC's libraries but that it was done after the 6.2 branch. So the 6.2 branch is 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 Sent: den 14 oktober 2004 10:30 To: Serge D. Mechveliani Cc: [EMAIL PROTECTED] Subject: Re: `partition' 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. this has been noticed a few times, for example http://www.mail-archive.com/[EMAIL PROTECTED]/msg07508.html -- -- Johannes Waldmann, Tel/Fax: (0341) 3076 6479 / 6480 -- -- http://www.imn.htwk-leipzig.de/~waldmann/ - ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
making ghc of september 26
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, makes itself successfully under your RedHat Linux system? - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Reply on 6-2-2-branch
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 bugfixes
only relative to 6.2.1.
Please if you have any outstanding bugs in 6.2.1, drop us a note.
[..]
On July 20
I have downloaded by cvs co -r ghc-6-2-branch ghc hslibs libraries
the version of
CVSROOT :pserver:[EMAIL PROTECTED]:/cvs
and tested it.
It this for future ghc-6.2.2 ?
I have seen only one minor bug.
Here follow the reports and questions.
1. A bug of a negative number of bytes.
ghci ...
:set +s
test log
...
(58.68 secs, -989876700 bytes)
Probably this is due to using Int instead of Integer.
And as I recall, it was said fixed (!?)
2. It identifies itself as ghc-6.2.1.
How to distingush it from the official ghc-6.2.1, by what messages?
Could the CVS versions aiming at some ghc-XXX, respond,
for example, with
... GHC, pre-release XXX-pre of July 20, 2004
when calledghc --version
?
3. `make' produces several warnings about the data fields not
initialised:
---
typecheck/TcRnTypes.lhs:235:
Warning: Fields of `TopEnv' not initialised: top_nc
In the record construction: TopEnv
{top_mode = mode,
top_dflags = dflags,
top_hpt = hpt,
top_eps = ref,
top_us = us,
top_errs = top_errs top}
In the definition of `top'':
top' = TopEnv
---
With kind regards,
-
Serge Mechveliani
[EMAIL PROTECTED]
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
packages, :m command
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 organizing a
package.
Thank you in advance for the help,
-
Serge Mechveliani
[EMAIL PROTECTED]
--
Having docon-2.08-pre, build it under -O as install.txt
specifies.
And I write in DoCon Manual how to organize a package for the user
example program which links DoCon library and package.
1.
After installing DoCon, set the variables
setenv doconc.../docon/source/docon.conf
setenv pcdocon -package-conf ${doconc}
setenv pcpdocon ${pcdocon} -package docon
2.
Design Makefile for creating a user package foo
by compiling the modules
u/Root.hs
u/subdir/M.hs
and putting the interfaces and libraries to the directory u/lib/
Let the module Root import some entities from DoCon and from the
module M.
--
module Root where-- in file u/Root.hs
import DExport -- imports all entities of DoCon and many of GHC
import M (m) -- of the user project
f = (m,m)
intRoot :: Z - Maybe Z
intRootn = let (ps,exps) = unzip $ factor n
in
if any (not . even) exps then Nothing
else
let halfs = map (`quot` 2) exps
in
Just $ product $ zipWith power ps halfs
--
module M where m = True-- file u/subdir/M.hs
--
-- The Makefile in the directory u/ should be --
ghcBinDir = /home/mechvel/ghcCVS/inst/bin
#
# EDIT these four!
# $(doconc) is the path to the DoCon configuration file,
# $(s) is the user source directory,
# $(e) a directory the user library and interface to install to.
#
doconc = /home/mechvel/docon/2.08/docon/source/docon.conf
s = /home/mechvel/t/u
e = $(s)/lib
ghc= $(ghcBinDir)/ghc
ghcpkg = $(ghcBinDir)/ghc-pkg
pcdocon = -package-conf $(doconc)
pcpdocon = $(pcdocon) -package docon
RANLIB = ar -s
language = -fglasgow-exts -fallow-overlapping-instances \
-fallow-undecidable-instances
warnings = -fno-warn-overlapping-patterns -fwarn-unused-binds \
-fwarn-unused-matches -fwarn-unused-imports
idirs= subdir
HCFlags = $(language) $(warnings)\
-i$(idirs) -odir $(e) -hidir $(e) -ddump-hi-diffs \
+RTS $(space) -RTS $(extraHCOpts)
space = -M55m
extraHCOpts =
# -Oghcpkg=...
pack =Package {name= \foo\, \
import_dirs = [\$(e)\],\
source_dirs = [], \
library_dirs= [\$(e)\],\
hs_libraries= [\HSfoo\], \
extra_libraries = [], \
include_dirs= [], \
c_includes = [], \
package_deps= [], \-- ?
extra_ghc_opts = [$(extraPackOpts)], \
extra_cc_opts = [], \
extra_ld_opts = [] }
extraPackOpts = $(pwarnings), $(planguage)
# `backslash' copy of $(HCFlags)
#
planguage = \-fglasgow-exts\, \
\-fallow-overlapping-instances\, \
\-fallow-undecidable-instances\
pwarnings = \-fno-warn-overlapping-patterns\, \
\-fwarn-unused-binds\,\-fwarn-unused-matches\, \
\-fwarn-unused-imports\
obj:
if [ ! -d $(e) ]; then mkdir $(e); fi
$(ghc) $(HCFlags) $(pcpdocon) --make Root -package-name foo
foo:obj
rm -f $(e)/libHSfoo.a $(e)/HSfoo.o
ar -qc $(e)/libHSfoo.a $(wildcard $(e)/*.o)
$(RANLIB) $(e)/libHSfoo.a
echo $(pack) | $(ghcpkg) -f $(s)/foo.conf -u -g
$(ghcpkg) -f $(s)/foo.conf -l
#
# o. files can be extracted from the library by ar -x
clear:
$(ghcpkg) -f $(s)/foo.conf -r foo
rm -f $(s)/foo.conf.old
rm -rf $(e)
Questions:
* should it be set package_deps = [\docon\]
?
(it does not work)
* how to avoid above the ugly backslash copy of $(HCFlags) ?
* are the goals obj, foo done correct ?
Making foo: cd .../u
make foo
Similarly as for DoCon package, arrange the variables
setenv fooc/home/mechvel/t/u/foo.conf
setenv pcfoo -package-conf ${fooc}
setenv pcpfoo ${pcfoo} -package foo
To run intRoot from the separate
problems with 6-2-branch
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/ghc/cvs/6-2-branch/inst/bin , installed it to /home/mechvel/ghc/cvs/6-2-branch/inst2/bin , erased all ghc except /home/mechvel/ghc/cvs/6-2-branch/inst2/bin , tested: which ghc /home/mechvel/ghc/cvs/6-2-branch/inst2/bin/ghc which ghci /home/mechvel/ghc/cvs/6-2-branch/inst2/bin/ghci , `made' DoCon by the Makefile containing ghc = /home/mechvel/ghc/cvs/6-2-branch/inst2/bin/ghc ... `made' the test T_ by ghc $pcpdocon --make T_ , run the test by ghci $pcpdocon T_ and got ... [True,ghc-6.2.1: internal error: scavenge: unimplemented/strange closure type 64 @ 0x404033f0 Please report this as a bug to [EMAIL PROTECTED], Now there is no doubt that in this latter test ghc and ghci are of the same place. And it looks like you cannot reproduce the effect. Maybe, this is system specific? Have you tried this on Debian linux or RedHat linux? Maybe, you can provide me with correct ghc-6-2-branch-binary ? One is for Debian Linux .. 2.4.25 #2 Mon Apr 26 .. 2004 i686 unknown, libc-2.2.5.so (once ghc-6.2.1-binary was installled there). Another -- for RedHat linux 9, libc-2.3.2.so. -- Another question: how to build ghc-6-2-branch from source without using pre-installed GHC (as to Alex and Happy, OK, I think, let them be pre-installed) and to install it into my user chosen directory ? I tried `make' from various places, and it says you have not run ./configure. And ./configure searches for ghc installed, for Happy. I am sorry, can you tell me precisely what to do? With kind regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
making 6-2-branch
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 PROTECTED] `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 ... T_ :set +s T_ test log .. [ghc-6.2.1: internal error: scavenge: ... ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Segmentation fault in ghc-6-2-branch-in-place
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-2-branch from the same source by itself: cd myfptools ./configure --prefix=/home/mechvel/ghcCVS/inst2 GHC=/home/mechvel/ghcCVS/inst/bin/ghc make all And it reports *** make[1]: Entering directory `/disk2/home/mechvel/ghcCVS/myfptools/glafp-utils' ===fptools== Recursively making `boot' in mkdependC mkdirhier runstdtest docbook lndir ... PWD = /disk2/home/mechvel/ghcCVS/myfptools/glafp-utils ... ... /home/mechvel/ghcCVS/inst/bin/ghc -M -optdep-f -optdep.depend -osuf o -H16m -O HaskTags.hs -- the ghc-2-branch envoked, right? ... ... /home/mechvel/ghcCVS/inst/bin/ghc -H16m -O -cpp-c Config.hs -o Config.o -ohi Config.hi ... ... /home/mechvel/ghcCVS/inst/bin/ghc -o stage1/ghc-6.2.1 -H16m -O -istage1/utils ... -H16M '-#include hschooks.h'-no-link-chk stage1/absCSyn/AbsCSyn.o stage1/absCSyn/AbsCUtils.o - ==fptools== make all -wr; in /disk2/home/mechvel/ghcCVS/myfptools/ghc/rts - ../../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 -O2 -static -c Adjustor.c -o Adjustor.o -- the new ghc-inplace invoked, right? make[2]: *** [Adjustor.o] Segmentation fault make[1]: *** [all] Error 1 make[1]: Leaving directory `/disk2/home/mechvel/ghcCVS/myfptools/ghc' make: *** [build] Error 1 Please, advise, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
internal error in 6-2-branch
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 sure why you use it. [..] Generally, (Time*Space) cost for a given task is an important quality estimation for the system instrument + application. Naturally, the user needs to find out how this parameter evolves from version to version. If some task is known to be done within a small memory and when it takes large memory in some particular system, then this is a serious matter about the system to be investigated. Also I use -M in order (1) to prevent filling all the memory and going to the disk space (2) to prevent taking much of memory from other users ((1),(2) may occur, for example, when ghc has a buggy GC), (3) to test GHC and Application, because deliberately running task in small memory, and with different -M, often reveals a bug. Setting different (and small) -M is good for debugging. I believe that the bug is already fixed. To test the 6.2-branch compiler (which is what you are trying to do), you need to build the stage-2 compiler, else you'll be running a 6.2-branch compiler linked to a 6.2.1 run-time system, which has the bug. If you sat in fptools/ and typed 'make' you should have successfully built a stage2 compiler; it lives in ghc/compiler/stage2/ghc-inplace. If you use this compiler to compile docon you should be all right. Or, if not, we'd like to know. Something is wrong here. We have the pre-installed official /usr/bin/ghc 6.2.1 -- compiler and ghci. Then, using /usr/bin/ghc, I have built the 6.2-branch in my home: ... cd .../ghcCVS/myfptools ./configure --prefix=.../ghcCVS/inst make all make install cd myfptools ls ghc/compiler/stage2/ absCSyn ... ghci ... ghc-6.2.1 ... ghc-inplace cd ghcCVS/inst ls bin ghc ghc-pkg ghci ... ghc-6.2.1 ... ghc-pkg-6.2.1 ghci-6.2.1 ... -- this is the newly installed ghc-6-2-branch, this is different from what is in /usr/bin/ghc (despite that they write 6.2.1 in the headings), right? I set $path too: which ghc /home/mechvel/ghcCVS/inst/bin/ghc which ghci /home/mechvel/ghcCVS/inst/bin/ghci DoCon Makefile uses $(ghc) with ghc = /home/mechvel/ghcCVS/inst/bin/ghc And it compiles differently to /usr/bin/ghc-6.2.1 official, I see this because it * does not seg-fault, takes much smaller memory to build DoCon, * does not break at compliling Pol3_.hs (in both variants), ghci is also different, because it finds the needed instances afterghci .. :m DExport .. factor (10 :: Integer) and 6.2.1 official does not find them. And still ghc-6.2.1: internal error: scavenge_mark_stack: unimplemented/strange closure type 30 @ 0x41692598 occurs in various situations: in compiling and under ghci, under -Onot and under -O, and it vanishes in ghci after :set +s May it occur that with all the above ghc -c ... ghci ... use the old run-time support? Maybe, the `make' should be done twice to erase all trace of old 6.2.1 ? I'll ask sysadmin to hide the official 6.2.1 of /usr/bin/ and I'll rebuild ghc-6-2-branch by compiling it by itself, and then see. Would it self-make? Another question: as you have docon-2.08-pre, you can reproduce the test with DoCon under ghc-6-2-branch, as I wrote. For example, `make' DoCon with -O, `make' T_ with -Onot, load it and run ghci $doconpcp T_ +RTS -M..any -RTS ... test log And it is supposed to report internal error Have you tried this? - Serge Mechveliani [EMAIL PROTECTED] | Dear GHC developers, |=20 | I have `made' GHC of cvs update -r ghc-6-2-branch(about May 14) |=20 | by ghc-6.2.1 on RedHat Linux (about version 8) libc-2.2, i686. |=20 | Now, you have the docon-2.08-pre | test, with Pol3_.hs containing |=20 | instance (LinSolvRing (Pol a), CommutativeRing a) =3D | LinSolvRing (UPol (Pol a)) | ... |=20 | And make space=3D-M20m docon | (-Onot) | yields |... |... | /home/mechvel/docon/2.08/docon/source/export/Pfact3_.hi: | openBinaryFile: does not exist (No such file or directory) |Compiling Pfact3_ | ( pol/factor/Pfact3_.hs, |/home/mechvel/docon/2.08/docon/source/export/Pfact3_.o ) | |No old interface available |ghc-6.2.1: internal error: scavenge_mark_stack: |unimplemented/strange closure type 30 @ 0x41692598 | Please report this as a bug to [EMAIL PROTECTED], | or http://www.sourceforge.net/projects/ghc/ | | Repeating this command,
compiling PrimOp.lhs
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 --prefix=... ... make boot ... run it from ghc or ... -- OK, probably make boot not needed, right? make all make[1]: Entering directory `/disk2/home/mechvel/ghcCVS/myfptools/glafp-utils' --- ===fptools== Recursively making `boot' in mkdependC mkdirhier runstdtest docbook lndir ... PWD = /disk2/home/mechvel/ghcCVS/myfptools/glafp-utils ... ... e1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis ... -c basicTypes/NewDemand.lhs -o stage1/basicTypes/NewDemand.o -ohi stage1/basicTypes/NewDemand.hi ghc: 159979968 bytes, 32 GCs, 3950581/8666736 avg/max bytes residency (4 samples), 20M in use, 0.01 INIT (0.00 elapsed), 1.09 MUT (3.03 elapsed), 0.50 GC (0.55 elapsed) :ghc /usr/bin/ghc -H16m -O -istage1/utils -istage1/basicTypes ... fglasgow-exts -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -recomp -Rghc-timing -H16M '-#include hschooks.h' -no-recomp -H80m -c prelude/PrimOp.lhs -o stage1/prelude/PrimOp.o -ohi stage1/prelude/PrimOp.hi ./primop-tag.hs-incl:2: Warning: Pattern match(es) are overlapped In the definition of `tagOf_PrimOp': tagOf_PrimOp op = ... *** Now, it stayed at this point for about 50 minutes, no messages appear, ghc-6.2.1, cc1 keep on being re-envoked in turn. I have just interrupted it. This module does not look large, and is given -H80m ... What is the matter, please? - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: compiling PrimOp.lhs
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: ** make all make[1]: Entering directory `/disk2/home/mechvel/ghcCVS/myfptools/glafp-utils' ... /usr/bin/ghc -H16m -O -istage1/utils -istage1/basicTypes ... fglasgow-exts -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -recomp -Rghc-timing -H16M '-#include hschooks.h' -no-recomp -H80m -c prelude/PrimOp.lhs -o stage1/prelude/PrimOp.o -ohi stage1/prelude/PrimOp.hi ./primop-tag.hs-incl:2: Warning: Pattern match(es) are overlapped In the definition of `tagOf_PrimOp': tagOf_PrimOp op = ... *** Now, it stayed at this point for about 50 minutes, no messages appear, ghc-6.2.1, cc1 keep on being re-envoked in turn. I have just interrupted it. This module does not look large, and is given -H80m ... What is the matter, please? Do you have a very slow machine? Very low memory? It takes maybe 15-20 minutes to compiler PrimOp.lhs on a 150 MHz SPARCstation-20. Probably not the machine, though. Powerful intel-686 machine, much memory: cpu family : 6 model : 6 model name : AMD Athlon(TM) MP 2000+ stepping: 2 cpu MHz : 1666.742 cache size : 256 KB top --- 115 processes: 112 sleeping, 3 running, 0 zombie, 0 stopped CPU0 states: 7.2% user 92.2% system0.0% nice 0.0% iowait 0.0% idle CPU1 states: 99.1% user 0.4% system0.0% nice 0.0% iowait 0.0% idle Mem: 904512k av, 650588k used, 253924k free, 0k shrd, 60192k buff 234516k active, 108332k inactive Swap: 2048276k av,5936k used, 2042340k free219276k cached PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND 20751 niiks 16 0 2360 2360 1724 R99.9 0.2 5640m 0 vim 25220 mechvel9 0 29616 28M 7368 S84.8 3.2 0:04 1 ghc-6.2.1 25224 mechvel 14 0 10420 10M 2496 R14.5 1.1 0:00 1 cc1 24125 mechvel 11 0 1148 1148 800 R 0.3 0.1 0:00 1 top ... -- Maybe, ghc-6.2.1 has a memory leak ... Another reason may be that my GHC competes with other users programs, and they have higher priority (I do not know). Now, I restartedcd myfptools make all It advanced up to ../../ghc/compiler/ghc-inplace -H16m -O ... Text/ParserCombinators/Parsec/Token.hs ... and continues. Probably, this means that the compiler (and its PrimOp) has compiled, and now the `make' is dealing with the library? - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
cvs ghc-6.2.. internal error
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
...
T_ :set +s
T_ test log
yields
...
...
fromOverX: X[y,z] - K[x,y,z] is the canonical isomorphism.
--- RESULT:
[ghc-6.2.1: internal error: scavenge:
unimplemented/strange closure type 64 @ 0x403c20a4
Please report this as a bug to [EMAIL PROTECTED],
or http://www.sourceforge.net/projects/ghc/
Also the message fromOverX: X[y,z] - K[x,y,z] ...
shows that at this point it works certain particular instance declared
in Pol3_.hs.
Simon P. Jones wrote about this something like
you may so far use old ghc-6xx.
But:
* under -Onot the test runs successfully,
* it is desirable a DoCon-reliable official ghc-new (for -O too).
Please, advise,
-
Serge Mechveliani
[EMAIL PROTECTED]
-- previous report
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) =
LinSolvRing (UPol (Pol a))
...
And make space=-M20m docon
(-Onot)
yields
...
...
/home/mechvel/docon/2.08/docon/source/export/Pfact3_.hi:
openBinaryFile: does not exist (No such file or directory)
Compiling Pfact3_
( pol/factor/Pfact3_.hs,
/home/mechvel/docon/2.08/docon/source/export/Pfact3_.o )
INTERFACE HAS CHANGED
No old interface available
ghc-6.2.1: internal error: scavenge_mark_stack:
unimplemented/strange closure type 30 @ 0x41692598
Please report this as a bug to [EMAIL PROTECTED],
or http://www.sourceforge.net/projects/ghc/
Repeating this command, or `making' it from the start under -M30m
avoids this report.
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
internal error: scavenge:
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 it.
-
Serge Mechveliani
[EMAIL PROTECTED]
--
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) =
LinSolvRing (UPol (Pol a))
...
And make space=-M20m docon
(-Onot)
yields
...
...
/home/mechvel/docon/2.08/docon/source/export/Pfact3_.hi:
openBinaryFile: does not exist (No such file or directory)
Compiling Pfact3_
( pol/factor/Pfact3_.hs,
/home/mechvel/docon/2.08/docon/source/export/Pfact3_.o )
INTERFACE HAS CHANGED
No old interface available
ghc-6.2.1: internal error: scavenge_mark_stack:
unimplemented/strange closure type 30 @ 0x41692598
Please report this as a bug to [EMAIL PROTECTED],
or http://www.sourceforge.net/projects/ghc/
Repeating this command, or `making' it from the start under -M30m
avoids this report.
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
internal error
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 PROTECTED] ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: space leak in compiler?
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 tosegmentation fault after compling several modules. Repeating this command several times allows to build the program. I'm looking into the segmentation fault. But may I make some observations/suggestions first: - a space leak is when a program is using more space than it needs to. You haven't given any evidence that GHC has a space leak, only that it uses more space as it compiles modules. This isn't unreasonable. The DoCon application has many modules. In early versions `make' did the project with -Onot in less that 32Mb , and without restart. And ghc-6.2.1 needs more the 90Mb for this. Therefore I suspect a space leak due to GC work between compiling modules. Only suspect. Also, it isn't unreasonable for GHC to run out of space during --make, but then make more progress when restarted. It could be due to caches built up during compilation, for example. That's not to say that GHC doesn't have space leaks, just that you haven't given us any evidence that it does. (actually I've spent quite a bit of time squashing space leaks in GHC, and I know that 6.2 does have some small leaks left, but nothing major). - If you need to compile on small memory machines, I suggest you avoid --make, and use ordinary Makefiles or hmake instead. Both of these will restart the compiler for each module, and hence avoid the behaviour you're seeing. You might even get a speedup, because the compiler won't be forced to use the compacting GC all the time. No, `make' it is all right in any case. Simpler commands are preferable. It is was all right in earlier GHC, why should it become worse in fresh ones? It forces the user to repeat the `make' command. If so, then, evidently, the GHC driver can do such a repetition automatically, until it finishes making. With kind regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
space leak in compiler?
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 --make ... +RTS -M30m -RTS) leads tosegmentation fault after compling several modules. Repeating this command several times allows to build the program. I need to release an official docon-2.08 within a couple of days. And am going write in Installation guide Commandmake space=... docon If it reports segmentation fault, repeat the command, until it compliles everything (this is, probably, due to a bug in GHC, not vital for the work with DoCon and which will be fixed in future GHC versions). With kind regards, -- Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
repeated import warning
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 - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
package treating
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 version to version. I presumed that, as the ghci command loads all usable libraries, then ghci -package-conf myPackage.conf -package myPackage will load all that `ghci' loads + what is specified in myPackage.conf. But, probably, this is not (should not be?) so: the option -package-conf myPackage.conf fully replaces the configuration, and the package search is done only according to what is specified in myPackage.conf , right? The program needs to link module List. List is of haskell98 package (right?), and myPackage does not mention any package dependency which could lead haskell98. Therefore the linker does not find in the loaded libraries some needed item for List. Then, ghci reports of `panic'. Maybe, it should report instead library item Foo not found, List items are of haskell98 package, do you have it on package dependecies? , something like this. Also there remains a question about concrete usage of ghc-pkg -g . Please, explain this (to [EMAIL PROTECTED]). Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: user package blocks standard ones
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. Yes, that's exactly what ghc-pkg -g does. It's usage is straightforward. Could you elaborate on what you find unclear? Did you try just adding -g to the ghc-pkg command line? I tried earlier -- without success. And now it works. Probably, I confused something. I am sorry. My bug reports mostly turn false. But there remains the interpreter crash, let us see. Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
user package blocks standard ones
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 library.
This package is called docon, and it is for a contrived project
of a single small module.
Similarly, ghci -package-conf docon.conf
reports
Loading package docon ... linking ...
/home/mechvel/test/export/HSdocon.o: unknown symbol `__stginit_List_'
ghc-6.0.1: panic! (the `impossible' happened, GHC version 6.0.1):
can't load package `docon'
Please report it as a compiler bug to [EMAIL PROTECTED],
or http://sourceforge.net/projects/ghc/.
Either it loads the packages of GHC itself, or, if it deals with
the user package, the packages of GHC are somehow blocked out.
When the user project does not import List and the such, then
ghc --make -package-conf docon.conf
works
but ghci -package-conf docon.conf
still does not (probably, it still needs to load some ghc packages).
The user package is
Package {name= docon,
import_dirs = [$e],
source_dirs = [],
library_dirs= [$e],
hs_libraries= [HSdocon],
extra_libraries = [],
include_dirs= [],
c_includes = [],
package_deps= [],
extra_ghc_opts = [],
extra_cc_opts = [],
extra_ld_opts = []
}
, $e is the the path to user package .hi, .o, and library directory.
I struggled with it for two days.
Then, occasionally, tried to set package_deps = [data]
, even though my contrived user package does not use data.
And it started to work, to load everything needed!
Then I try package_deps = [base]
And here ghci -package-conf docon.conf
reports again the `panic'.
Here follows the precise data.
The file Head.hs in the `root' directory $(s) contains
module Head where import List (sort)
f = sort [1,2] :: [Int]
The file Makefile in the same directory is for creating the
package and `making' the project. So that the command
make docon
does the following in succession.
* creates a directory $(e) = $(s)/export
* makes a project by
$(ghc) $(HCFlags) --make Head -package-name docon
* creates the libraries $(e)/libHSdocon.a $(e)/HSdocon.o
with ar and ld
* creates a package docon referring to these libraries:
echo $(pack) | ghc-pkg -f $(s)/docon.conf -u
,
where $(pack) is a string for the package which Makefile sets
earlier.
The command make clear is for un-doing of all this.
Here is the precise Makefile:
ghc = /usr/bin/ghc
# edit these two ***
s = /home/mechvel/test
e = $(s)/export
RANLIB = ar -s
HCFlags = -odir $(e) -hidir $(e)
pack = Package {name= \docon\, \
import_dirs = [\$(e)\],\
source_dirs = [], \
library_dirs= [\$(e)\],\
hs_libraries= [\HSdocon\], \
extra_libraries = [], \
include_dirs= [], \
c_includes = [], \
package_deps= [], \
extra_ghc_opts = [], \
extra_cc_opts = [], \
extra_ld_opts = [] }
obj:
if [ ! -d $(e) ]; then mkdir $(e); fi
$(ghc) $(HCFlags) --make Head -package-name docon
docon: obj
rm -f $(e)/libHSdocon.a $(e)/HSdocon.o
ar -qc $(e)/libHSdocon.a $(wildcard $(e)/*.o)
$(RANLIB) $(e)/libHSdocon.a
ld -r -x --whole-archive $(e)/libHSdocon.a -o $(e)/HSdocon.o
ghc-pkg -f $(s)/docon.conf -l
echo $(pack) | ghc-pkg -f $(s)/docon.conf -u
ghc-pkg -f $(s)/docon.conf -l
clear:
ghc-pkg -f $(s)/docon.conf -r docon
rm -f $(s)/docon.conf.old
rm -rf $(e)
rm -f $(s)/log
To exclude the List library, comment out the line `import ..'
and replace the line `f = ...' with `f = True'.
Question on ghc-pkg -g
===
User guide for packages does not explain this precisely.
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.
Is it clear from the guide paragraph
interactive: internal error: scavenge:
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 the reduction of fs by gs, gs' by gs, gs by gs', tests the transformation matrix fs - gs --- RESULT: [True,interactive: internal error: scavenge: unimplemented/strange closure type 64 @ 0x4056c418 Please report this as a bug to [EMAIL PROTECTED], or http://www.sourceforge.net/projects/ghc/ The same test compiled to Main.main and --make-ed to a.out runs correct. The project is large, and the bug looks hard to locate. The archive of the source to install is about 900 Kb. I could send it to the GHC team on the subject of debugging GHC, if you tell me any appropriate personal address. - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
interactive: internal error: scavenge
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 mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
interactive: internal error, ghc-6.0.1
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 more. ghci Main +RTS -M1m -RTS .. : Main .. main ... (interactive: internal error: thread_stack: weird activation record found on stack: 1564 Please report this as a bug to [EMAIL PROTECTED] .. Probably, the interpreter manages memory in a wrong way. Can you reproduce the effect? Regards, - Serge Mechveliani [EMAIL PROTECTED] --- main = let xs = [1..9000] -- change this number -- and see the message from ghc (x's, s1) = sortE compare xs in putStr $ shows s1 \n type CompValue= Ordering type Comparison a = a - a - CompValue mergeE :: Comparison a - [a] - [a] - ([a],Char) -- Extended merge: -- the transposition sign '+' | '-' is also accumulated. mergeE cp xs ys = m xs ys $ evenL xs where m [] ys _ = (ys,'+') m xs [] _ = (xs,'+') m (x:xs) (y:ys) ev = case cp x y of GT - (y:zs, mulSign s ev) where (zs,s) = m (x:xs) ys ev _ - (x:zs, s) where (zs,s) = m xs (y:ys) (invSign ev) ortE :: Comparison a - [a] - ([a],Char) -- Extended sort: -- the permutation sign '+' | '-' also accumulates. sortE _ [] = ([] , '+') sortE _ [x] = ([x], '+') sortE cp xs = let (ys ,zs) = halve xs (ys',s1) = sortE cp ys (zs',s2) = sortE cp zs (us ,s3) = mergeE cp ys' zs' in (us, mulSign s3 $ mulSign s1 s2) halve :: [a] - ([a],[a]) halvexs = h [] xs xs where h ls (x:rs) (_:_:ys) = h (x:ls) rs ys h ls rs _= (reverse ls, rs) mulSign :: Char - Char - Char mulSignx y= if x==y then '+' else '-' invSign :: Char - Char invSign'+' = '-' invSign'-' = '+' evenL :: [a] - Char evenL [] = '+' evenL (_:xs) = invSign $ evenL xs --- ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
-fwarn-unused-matches
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] - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
