Hi,
in our (latest) installation (ghc-5.02.3 on solaris) the module Pretty
(from the package text) did not export Style-related functions due to an
(old/wrong) interface file ../imports/text/Pretty.hi (with size 10909).
When translating Pretty.lhs ourselves it seems to work correctly (and
the
The following error message just contains a typo before existential
context.
Cheers Christian
Compiling Syntax ( Syntax.hs, ./Syntax.o )
Syntax.hs:56:
Could not deduce (Institution id1 basic_spec1 local_env1,
Institution id basic_spec local_env)
on http://haskell.org/ghc/docs/latest/set/book-hslibs.html
The requested URL /ghc/docs/latest/set/book-hslibs.html was not found on
this server.
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
Hi,
ghci seems to use a lot of cpu-time without doing something at the
prompt.
Furthermore ghc -O2 ... still creates binaries that yield a Bus
Error with gcc-3.1.
Can't that be fixed?
Cheers, Christian
___
Glasgow-haskell-bugs mailing list
[EMAIL
On http://www.haskell.org/ghc/
the link to the Users' Guide is missing.
Cheers Christian
GHC Features
This is a summary of GHC's main features. They are all described in more
detail in the Users' Guide.
The requested URL
/ghc/docs/latest/html/users_guide/book-users-guide.html was not found
How is it possible that an unused import warning is not always emitted?
Below I get a warning when I recompile everything, but no warning when I
only recompile the Main module (that contains the unused import). In
fact Main.hi changes.
Cheers Christian
Compiling GUI.ConvertDevToAbstractGraph
Despite some changes in various parts of the cvs tree, the bug is still
reproducable:
do the following (on a linux machine with a bash):
export
CVSROOT=:pserver:[EMAIL PROTECTED]:/repository
cvs checkout uni
cvs checkout HetCATS
cd uni
./configure
make boot
make all
cd ../HetCATS
make
make
This happens when partially recompiling with -O (I thing I've send a
similar bug-report that was kept in the moderator's queue because it was
to slightly too large - over 40K )
Christian
Thomas Hallgren wrote:
Hi,
I managed to distill my program into to the following small example that
still
Simon Peyton-Jones wrote:
Should be fixed now -- can you try with the HEAD?
yes, it work now! Thanks
Christian
| ghc-6.4.20050220: panic! (the `impossible' happened, GHC version
| 6.4.20050220):
| eval_data2tag
| GHCziPrim.dataToTagzh{(w) v 95f}
| @ (Bug.S{tc r14v}
Hi,
I also have (a rather large) program (not included) that segfaults when
compiled with profiling. I use the ghc-6.4 linux binary distribution
from the web.
It is not even necessary to call the program with +RTS -p -RTS. There is
no problem with ghc-6.2.2, except that the old version uses its
Axel Simon wrote:
gcc -O -Wall -I../../../ghc/includes -I../../../ghc/rts
-I/core/include-c env.c -o env.p_o
cc1: /core/include: Not a directory
My gcc does not complain about that missing directory. I was able to
create a working installation under solaris with:
./configure
Axel Simon wrote:
Warning: retaining unknown function `getgrnam_r' in output from C compiler
I haven't overridden anything in build.mk, so I assume SplitObjs=YES.
When would I observe these warnings?
the first time when the inplace compiler translates System/Posix/Resour
ce.hs
I just see
If that's any confort? I get a similar error (with ghc-5.04.2 and the
ghc-6.4.1.20050517 sources)
Cheers Christian
stage1/nativeGen/AsmCodeGen.o(.text+0xc2b6): In function `smsr_ret':
: undefined reference to `GHCziPrim_zdwZ2H_entry'
stage1/nativeGen/AsmCodeGen.o(.text+0x8472): In function
Axel Simon wrote:
I'm using gcc 2.95.4, maybe that's the oddity. ld is
GNU ld version 2.12.90.0.1 20020307 Debian/GNU Linux
I have:
gcc (GCC) 3.3.4 (pre 3.3.5 20040809)
GNU ld version 2.15.91.0.2 20040727 (SuSE Linux)
and my config.log and gmake.log files can be found at:
this bug is fixed in ghc-6.4.1 (see my attached profile)
Christian
Daniel Fischer wrote:
Hello,
I have encountered some strange behaviour with David Tweeds LaTeX-preprocessor
(slightly modified code attached).
When I compile it for profiling (-prof -auto-all) and run it on a .tex-file
Mirko Rahn wrote:
I've found a way to speed up your code for ghc-6.4.1.
Replace the where with a case in PCP.Suc.suc_rules (see below)
Okay, thanks, that works fine.
Yes, It's even quite fast without optimization (I did not check with
ghc-6.4, though)
(Maybe that is a good idea in
Hi Baltasar,
maybe it's GHC's inliner. See
http://www.haskell.org/ghc/docs/latest/html/users_guide/bugs.html#bugs-ghc
and the russel example is similar enough to yours. (I have not
checked, though.)
I apologize, again, for the wrong spelling, It must be Russell with
two l!
Cheers
Chris Kuklewicz wrote:
Greg Buchholz wrote:
True. But there are some tests like fasta that appear to have a
laziness induced space leak that presumably could be fixed.
http://shootout.alioth.debian.org/benchmark.php?test=fastalang=all
Already the following bit exhibits unexpected
Tomasz Zielonka wrote:
On Tue, Dec 27, 2005 at 08:12:20PM +0100, Christian Maeder wrote:
Already the following bit exhibits unexpected memory consumption:
main = mapM_ print $ take (n * 5) $ drop (n * 3) [1..]
n = 10
I think it's the (succ (succ (succ ...))) thunk. When you change
Simon Peyton-Jones wrote:
Just to let you know, I can reproduce this problem nicely (thank you for
setting up the repro case). It turns out to be caused by the
simplifier's inlining policy which goes if not exponential then
something very like it. It's made dramatically worse by the fact that
139828 2006-01-26 19:58 HasCASL/PrintLe.o
Christian Maeder wrote:
P.S. I've changed infixl to infixr
infixr 6
infixr 6 +
infixr 5 $$, $+$
Not much difference in code size but a bit faster compared to the
numbers I've posted before:
http://hackage.haskell.org/trac/ghc/ticket/490
Linking ...
real
-rwxr-xr-x 1 maeder wimi 6213885 2006-01-26 20:11 a.out
-rw-r--r-- 1 maeder wimi 1762784 2006-01-26 20:09 HasCASL/PrintLe.o
Christian Maeder wrote:
Sorry, I forgot to save my changes. The numbers are much better with
infixr:
Linking ...
real5m30.666s
user4m56.950s
sys 0m9.262s
[EMAIL
The attached 4 files compile with ghc-6.4.1 and fail with
ghc-6.5.20060201 (see below).
Also, if I delete the Int and Integer instances in
Common/ATerm/Conversion.hs the error remains the same for ghc-6.5
whereas ghc-6.4.1 correctly complains about
No instance for (ShATermConvertible Int)
Christopher Brown wrote:
Christian,
Did you try the switch -fallow-overlapping-instances when compiling?
Yes, but it doesn't seem to make much difference.
Maybe a couple of more library files have not been translated with the
above flag.
Simon Marlow wrote:
The best way to proceed would be to run the testsuite with the stage 1
compiler. Grab the test suite from here:
http://www.haskell.org/ghc/dist/6.4.2/ghc-testsuite-6.4.2.tar.gz
unpack it into your 6.4.2 build tree, cd testsuite, make boot, cd
tests/ghc-regress, make 21 |
Simon Marlow wrote:
In GHC 6.4.2, the stage 2 compiler is built with -threaded, this is a
change from previous versions. If -threaded isn't working properly,
then the stage 2 compiler will be affected - that seems to be the case
on Solaris.
To get going, you could just disable -threaded in
Simon Marlow wrote:
I've fixed the cause of the hangs on Solaris, I believe. Also, the
ctime_r() and -lrt problems are both fixed. If you grab the
ghc-6-4-branch from CVS you'll get the code with these fixes.
I'd be interested to know if it works for you, and if you could do a
testsuite
Simon Marlow wrote:
I've fixed the cause of the hangs on Solaris, I believe. Also, the
ctime_r() and -lrt problems are both fixed. If you grab the
ghc-6-4-branch from CVS you'll get the code with these fixes.
This problem still exists:
RtsUtils.c: In function 'time_str':
RtsUtils.c:197:
Simon Marlow wrote:
I've fixed the cause of the hangs on Solaris, I believe.
Yes, hanging is gone, but the binary segfaults now immediately (with
hello.hs)
Also, the
ctime_r() and -lrt problems are both fixed.
Only the -lrt problem is fixed.
I'd be interested to know if it works for
Hi Florian,
it seems, that you fall over the same problems I had under solaris.
GHC-6.4.2 does not work under solaris, currently.
I've build a binary distribution (without -threaded) that seems to work
at least as good as the ghc-6.4.1 version did.
You may try out:
Christian Maeder wrote:
I'm currently running the ghc-regression test (with stage1/ghc-inplace),
but that does not look good (although it does not hang)
here is the frustrating summary:
OVERALL SUMMARY for test run started at Mon May 22 18:30:30 CEST 2006
1365 total tests, which gave rise
Simon Marlow wrote:
It looks like every GHCi test failed (the TH tests use GHCi internally,
so they failed too).
Does GHCi fail? If so, in what way?
simply doing gmake in tests/ghc-regress is no good idea, because the
stage1 compiler is used.
the stage2 compiler is unusable:
Cheers
Duncan Coutts wrote:
file /usr/lib/ghc-6.4.2/HSbase.o
/usr/lib/ghc-6.4.2/HSbase.o: ELF 32-bit MSB relocatable, SPARC32PLUS, V8
+ Required, version 1 (SYSV), not stripped
I don't think that is my problem. Possibly my stage1 compiler isn't that
bad (as it only lacked ghci support), whereas my
Hi Simon,
I've recompiled ghc-6.4.2 from cvs again without -threaded. The
regression test looks much better now (below). The conc-cases go through
now, but the following problems do still exist:
cc04 (and ffi012) reported: 'calling convention not supported on this
architecture: stdcall'
Simon Marlow wrote:
Do you know if the stage2 compiler works with -threaded? Or does it
still crash?
The stage2 compiler created with -threaded seg-faulted even for a simple
hello.hs. That's the reason I've switched off -threaded.
That needs to be investigated.
I've no clue how to go
Christian Maeder wrote:
Well. at least Florenz reported independently the same ctime_r problem
under Solaris 10 in http://hackage.haskell.org/trac/ghc/ticket/775
Ok, he used the original 6.4.2 sources that did not have your fix. What
file was supposed to fix the problem?
C
Simon Marlow wrote:
Ach, my fault. Somehow I forgot to merge that fix into the 6.4 branch.
Sorry :-( It should be there now. The file RtsUtils.c has changed.
Ok, I'm recompiling and RtsUtils.c has been compiled by ghc-inplace now
(so your fix works)
C.
Simon Marlow wrote:
Looks like the file OSMem.o is missing from your RTS build somehow. It
should be in ghc/rts/posix.
Ah, posix is a new directory that I did not check out.
C.
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
The stage2 compiler non-deterministically crashes with segmentation
fault (and even works some times)
C.
-bash-3.00$ ghc/compiler/stage2/ghc-inplace --interactive
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.4.2, for Haskell 98.
/ /_\\/ __ /
Duncan Coutts schrieb:
Try SRC_HC_OPTS = -optc-mcpu=ultrasparc -opta-mcpu=ultrasparc
With this I've produced a binary saying:
-bash-3.00$ ghc --version
ghc-6.6: schedule: re-entered unsafely.
Perhaps a 'foreign import unsafe' should be 'safe'?
Yes! I get exactly the same under sparc
1. The VERSION = 5.2 in libraries/fgl/Makefile
does not correspond to libraries/fgl/fgl.cabal
version:5.3
Probably VERSION should always be extracted from the .cabal file.
2. When installing libraries/network via cabal (under solaris) the
'extraLibraries = [nsl,socket]' have not been
Bulat Ziganshin schrieb:
may be this will be useful:
-- This equalizer routine required because MArray interface was changed in
GHC 6.6
#if defined(__GLASGOW_HASKELL__) (__GLASGOW_HASKELL__ = 605)
getMBounds arr = getBounds arr
#else
getMBounds arr = return (bounds arr)
#endif
usage
Indeed, that avoided the immediate crash. I'll try a completely new
ghc-6.6 build now.
GHC schrieb:
#993: threaded RTS under pc-solaris does not work
+---
Reporter: [EMAIL PROTECTED] | Owner:
Claus Reinke schrieb:
#1002: ghc-6.6 sometimes hangs under Solaris
After compiling 643 modules (in 5 minutes) ghc-6.6 did not finish its
batch job.
..
I have often seen problems like this with the Solaris linker. (I
suspect it must have a super-linear algorithm for resolving symbol
How did you call ghci? Maybe some *.hi files build on another platform
were lying around.
Cheers Christian
Loading IO works for me (on the same machine):
Loading package base ... linking ... done.
Prelude :m IO
Prelude IO
[EMAIL PROTECTED] schrieb:
___ ___ _
/ _ \ /\ /\/ __(_)
try gmake instead of make
GHC schrieb:
#1116: Error building ghc on Solaris 9
-+--
Reporter: [EMAIL PROTECTED] | Owner:
Type: bug | Status: new
Priority:
Winfried, could you also try my binary distribution?
http://www.haskell.org/ghc/download_ghc_66.html#sparcsolaris
Ian, could you remove the out-dated first line from this page?
cite
NOTE: you must use GCC 2.95 or 3.4+ on Sparc. There is a known bug with
GCC versions between 3.0-3.3 which causes
Christian Maeder schrieb:
http://www.haskell.org/ghc/download_ghc_66.html#sparcsolaris
Ian, could you remove the out-dated first line from this page?
cite
NOTE: you must use GCC 2.95 or 3.4+ on Sparc. There is a known bug with
GCC versions between 3.0-3.3 which causes incorrect code
Winfried Kung schrieb:
I also had to set explicitely
SRC_HC_OPTS = -optc-mcpu=ultrasparc -opta-mcpu=ultrasparc
as Duncan Coutts already pointed out.
I did nothing special. My build.mk (in mk/) says:
BIN_DIST=1
Project=Ghc
SRC_HC_OPTS += -optc-mcpu=ultrasparc -opta-mcpu=ultrasparc
Note
For some reason I cannot login using guest guest
http://hackage.haskell.org/trac/ghc/ticket/955
I only want to suggest to change the milestone to 6.8.
Although the code-bloat is not nice, we could live with it.
Christian
___
Glasgow-haskell-bugs
Could it be documented at:
http://www.haskell.org/ghc/download_ghc_66.html#macosxppc
that at least gcc 3.3.1 is required
GHC schrieb:
#1157: hxt cannot be compiled with optimization level 2 (-O2)
---+
Reporter: [EMAIL
When making a binary distribution from the official ghc-6.6.1 sources, I
get the latex error below for core.tex. I have to skip this error by
typing ^D (EOF) explicitly. (I did not find out how to fix this error on
line 528 of core.tex, though)
The final documentation lacks a core.ps file. But
Christian Maeder schrieb:
I can only offer to make a rebuild with any options that might help. May
it be a problem with the GMP framework? The one for downloading
(gmp-4.2.1) might be different from the one that's globally installed
here (gmp-4.2).
GMP (v7) used by ghc
$ otool -L ghc-6.6.1
Deborah Goldsmith schrieb:
I'm also going to try building on 10.4.x to see if this is 10.5-specific.
Yes, do so.
One more variable is that the build on 10.5 was done on a machine with
an Intel Core 2 Duo processor. I don't know if that's relevant.
No idea, the GMP framework should be ok,
Deborah Goldsmith schrieb:
OK, I was able to build 6.6.1 successfully on 10.4 (Intel Core Duo) with
both the standard configuration and with SplitObjs = NO. The build was
done with the same binary 6.6.1 release, GMP, and GNU readline as on
10.5. So this is definitely something about 10.5 (not
Deborah Goldsmith schrieb:
I kind of doubt this is the problem, but I could try it. I assume I can
fiddle with the configuration variables and have it use gcc-3.3 instead
of gcc?
I usually make a link to another gcc and let it find first in the path.
ln -s /usr/bin/gcc-3.3 ~/bin
export
Rod Evans schrieb:
If this solves your problem ghc has a problem with object splitting
under some solaris linkers
Are you talking about the size issue we're presently discussing, or
another issue in which the Solaris linkers fail you? We'd be happy to
work with you directly to investigate
Simon Marlow schrieb:
The only reason we keep the .size directives around at all is because
certain tools (like Valgind for example) don't work without .size
information. GHC itself, including our dynamic linker, works fine
without it.
I can't tell exactly what has gone wrong in this
Simon Marlow schrieb:
Christian Maeder wrote:
[...]
In PrimOps.s it looks (wrongly mangled?) like this:
.text
.align 4
.type GHC_ZCCReturnable_static_info, @object
.size GHC_ZCCReturnable_static_info, 4
.zero 4
.globl GHC_ZCCReturnable_static_info
Simon Marlow schrieb:
Christian Maeder wrote:
Simon Marlow schrieb:
[...]
I guess we should just eliminate the .size directives if the linker is
going to be picky about them. In ghc-asm.lprl you'll find
$T_COPY_DIRVS = '^\s*\.(globl|type|size|local)';
if you change
Stefan Parvu schrieb:
This is with the original linker from S11 and it *works*
[EMAIL PROTECTED]env LD_LIBRARY_PATH=/opt/csw/lib ghc --make hello.hs
[1 of 1] Compiling Main ( hello.hs, hello.o )
Linking hello ...
Great, the problem is gone. I could confirm Simon's fix using
Hi,
I've created a ticket on this matter:
http://hackage.haskell.org/trac/ghc/ticket/1437
(Add further comments as you think fit)
Deborah Goldsmith schrieb:
2. Move in mk/build.mk to work around splitter incompatibility with Leopard
Does mk/build.mk only contain SplitObjs = NO?
I suggest to
Rich Collins schrieb:
It was a problem with the linking for ghc. I hacked LD_LIBRARY_PATH for
my user account and it worked. You might want to add /opt/csw/lib/ when
compiling ghc.
Setting LD_LIBRARY_PATH only helps to find missing libs like libgmp.so
(or libreadline.so). But the directory
Hal Perkins schrieb:
One suggestion (request?) for the future: would it be possible to fix
the pre-built os-x packages so they are self-contained, as they were for
GHC 6.6?
The problem with the ghc-6.6 binary dist was, that it required root
rights and also installed libreadline.so for you
I'm currently confused if it must be plural or singular (or any)
http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilation.html#keeping-intermediates
shows plural options whereas
http://www.haskell.org/ghc/docs/latest/html/users_guide/flag-reference.html#id3131928
shows
Christian Maeder schrieb:
I'm currently confused if it must be plural or singular (or any)
http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilation.html#keeping-intermediates
shows plural options whereas
http://www.haskell.org/ghc/docs/latest/html/users_guide/flag
GHC wrote:
#1609: spurious gcc warnings with non-english language setting
---+
Reporter: [EMAIL PROTECTED] |Owner:
Type: bug | Status: new
Priority: low
manu wrote:
hello,
has anybody managed to build hdbc-sqlite3 with ghc 6.8.2 ?
I get the following error :
Macintosh:HDBC-sqlite3-1.1.3.0 manu$ runhaskell Setup.lhs build
Preprocessing library HDBC-sqlite3-1.1.3.0...
ghc-6.8.2: unrecognised flags: -F/Users/manu/Library/Frameworks
with different
contents, I would suggest the use of some versioning scheme. Otherwise is
seems that a lot of confusion could result.
Thanks and best regards
Thorkil
On Thursday 03 January 2008 16:18, Ian Lynagh wrote:
Hi Christian,
On Thu, Jan 03, 2008 at 02:41:56PM +0100, Christian Maeder
Brian Park wrote:
Hi,
I was installing various haskell packages from hackage.
When I was installing HaXml, I think it was complaining about
Text.PrettyPrint.HughesPJ not installed or something. (can't remember
the specific message and I can't reproduce now...)
HaXml-1.13.2 needs pretty
Malcolm Wallace wrote:
I think I am persuaded that this is the most important goal: stability
of the API and package interface, for existing clients of readline. If
individual projects would like to migrate from using readline to using
editline, then those are the ones that should pay the
Hi Simon,
could you please supply a testsuite.tgz for ghc-6.8.2 so that I can test
it? (Or say how to easily get the testsuite only).
I hope ghc-6.8.2 is sufficient for testing.
Cheers Christian
see also
http://hackage.haskell.org/trac/ghc/ticket/2025
GHC wrote:
#1015:
Chad Scherrer wrote:
Hello,
I'm trying to compile stream-fusion-0.1.1 with profiling enabled, and it's
overflowing the stack.
$ runghc Setup.lhs configure -pO
Configuring stream-fusion-0.1.1...
$ runghc Setup.lhs build
Preprocessing library stream-fusion-0.1.1...
Building
Thanks Chris!
This should fix
http://hackage.haskell.org/trac/ghc/ticket/1958
http://hackage.haskell.org/trac/ghc/ticket/2117
Thorkil, you called your patch illustrative only. I suggest to commit
it. Any objections? Thanks for the patch, anyway.
Cheers Christian
My built can be found at:
Changes (by igloo):
* milestone: 6.10.1 = 6.12 branch
Comment:
I don't think we're likely to fix this before -fvia-C is removed in 6.12.
The workaround is just to use `-fasm`, of course.
I wonder how porting to other platforms will be achieved in the future
without going via C.
Serge D. Mechveliani wrote:
Dear GHC team,
let me answer as a plain ghc user.
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
Hi,
was someone able to compile ghc-6.12.3 on PowerPC / MacOS X?
My attempt failed with:
/usr/bin/ld -r -o compiler/stage2/build/HSghc-6.12.3.o
... `/usr/bin/find compiler/stage2/build -name *_stub.o -print`
ld: scattered reloc r_address too large for inferred architecture ppc
make[1]: ***
77 matches
Mail list logo
