Simon Marlow wrote:
What version of gcc are you using?
I used gcc_2.95.3 until I discovered the warning:
LdvProfile.c:43: #error Please use gcc 3.0+ to compile this file with
DEBUG; gcc 3.0 miscompiles it
I've switched to gcc_3.4.3. Now the final linking of the stage2 compiler
fails (with
On 24 February 2005 20:11, Sven Panne wrote:
Simon Marlow wrote:
On 22 February 2005 19:37, Duncan Coutts wrote:
Excellent! Thanks a lot.
Any hint as to when the next Haddock release will be?
Maybe when I've got this GHC release out of the way and my hair has
grown back :-S
Before we do
On 25 February 2005 10:09, Christian Maeder wrote:
Simon Marlow wrote:
What version of gcc are you using?
I used gcc_2.95.3 until I discovered the warning:
LdvProfile.c:43: #error Please use gcc 3.0+ to compile this file
with DEBUG; gcc 3.0 miscompiles it
I've switched to
Ive fixed this to print the parens round the type constructor anyway.
But it won't print infix. Doing the right thing requires knowledge of
fixities, which isn't (yet) plumbed to the right place
S
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-users-
| [EMAIL
Well, it's a bug really, but not one that's easy to fix. Thanks for
pointing it out; I've added it as a SourceForge bug so we don't forget
it.
SImon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of Johan Glimming
| Sent: 24
Welcome to the club :-)
http://www.mail-archive.com/glasgow-haskell-users@haskell.org/msg06012.html
I tried Simon's version, but it throws a Fail: Ix{Int}.index: Index
(5) out of range ((0,4)) error. Haven't tracked down the cause yet.
So I guess that the upshot is just that GHC
From: Simon Marlow [mailto:[EMAIL PROTECTED]
PackedStrings are still slow in 6.x. I know there are various other
PackedString implementations out there, we just need to
incorporate one.
They certainly seem to be. Below are the profiles (compiled with -O2; ran
them twice; took the second
There's a real bug in the desugarer here, quite apart from the
programming question. I'll look into it
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of Akos Korosmezey
| Sent: 18 February 2005 20:05
| To: GHC-users
On 25 February 2005 13:46, Alson Kemp wrote:
Welcome to the club :-)
http://www.mail-archive.com/glasgow-haskell-users@haskell.org/msg06012.h
tml
I tried Simon's version, but it throws a Fail: Ix{Int}.index:
Index
(5) out of range ((0,4)) error. Haven't tracked down the cause yet.
Hi,
we used redirect output of ghc via tee (within a Makefile). With the
new ghc this randomly fails now. Does anyone have an explanation for this?
ghc omitted args 21 | tee log
yields:
Skipping Main ( hets.hs, hets.o )
Linking ...
tee: write error
The linked binary and the log
Simon Marlow wrote:
Just to let you know, there are a number of open bug reports for GHC on
the x86_64 platform, which seem to indicate some kind of occasional
memory/GC problem. I'm probably not going to be able to track this down
until after the 6.4 release, but we'll put out a patch as soon as
Here's your program, but a little slimmer. I think size counts for something
in the shootout. Still runs at the same speed though :-(
The program seems to spend about 50% reading the files, 22% building the
hash table (7% chopping input into lines, 11% inserting into table), 25%
spellchecking
Greetings fellow Haskellers and other readers,
During my ongoing research on doing whatever I feel like, I
discovered that using C++ libaries in GHCi (no problems with GHC)
wasn't as pleasant as I had hoped.
Apparently C++ sources requires to be linked with crtbegin.o and
crtend.o (and others?)
On Fri, 2005-02-25 at 19:05 +0100, Lemmih wrote:
Greetings fellow Haskellers and other readers,
During my ongoing research on doing whatever I feel like, I
discovered that using C++ libaries in GHCi (no problems with GHC)
wasn't as pleasant as I had hoped.
Apparently C++ sources requires to
During my ongoing research on doing whatever I feel like, I
discovered that using C++ libaries in GHCi (no problems with GHC)
wasn't as pleasant as I had hoped.
Apparently C++ sources requires to be linked with crtbegin.o and
crtend.o (and others?) and I was wondering how to solve this nicely.
Any
On Fri, 25 Feb 2005 18:27:03 +, Duncan Coutts
[EMAIL PROTECTED] wrote:
On Fri, 2005-02-25 at 19:05 +0100, Lemmih wrote:
Greetings fellow Haskellers and other readers,
During my ongoing research on doing whatever I feel like, I
discovered that using C++ libaries in GHCi (no problems
On Fri, 25 Feb 2005 13:58:52 -0500, Wolfgang Thaller
[EMAIL PROTECTED] wrote:
During my ongoing research on doing whatever I feel like, I
discovered that using C++ libaries in GHCi (no problems with GHC)
wasn't as pleasant as I had hoped.
Apparently C++ sources requires to be linked with
I've written a binding to a C++ library where I use a simple wrapper
file to overcome the name mangling (extern C functions calling C++,
nothing fancy). Is there a way to make that more GHCi friendly or
should I explore other options?
What exactly is going wrong?
Try wrapping your binding in a
Simon Marlow wrote:
They don't look too bad to me... a bit far to the right, perhaps, but
not too bad. Perhaps some lines in that table would help, or
alternating grey/white background for the rows? [...]
What I mean with drunk can be seen here:
https://aedion.de/haskell/haddock.png
It's
Wolfgang Thaller wrote:
[...] *) static constructors/destructors
Sometimes there are pieces of code that expect to be called before
main() or at program termination. The GHCi Linker doesn't support this,
so some code may crash because things haven't been initialised properly.
This will
bstrand:
Simon Marlow wrote:
Just to let you know, there are a number of open bug reports for GHC on
the x86_64 platform, which seem to indicate some kind of occasional
memory/GC problem. I'm probably not going to be able to track this down
until after the 6.4 release, but we'll put out a
Sorry if this is a RTFM type question - but what is the status of the
x86_64 port?
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
I've followed the instructions for building on the host for an
unregistered x86_64 build, but when I do:
cd glafp-utils/ make boot make
I get:
...
ls/Outputable.lhs utils/Panic.lhs utils/Pretty.lhs
utils/PrimPacked.lhs utils/StringBuffer.lhs utils/UnicodeUtil.lhs
utils/UniqFM.lhs
kip.macy:
Sorry if this is a RTFM type question - but what is the status of the
x86_64 port?
As it says on
http://www.haskell.org/ghc/docs/latest/html/building/sec-port-info.html
it currently works unregisterised (and is available in binary form on a
number of platforms). The registerised
kip.macy:
I've followed the instructions for building on the host for an
unregistered x86_64 build, but when I do:
cd glafp-utils/ make boot make
I get:
...
ls/Outputable.lhs utils/Panic.lhs utils/Pretty.lhs
utils/PrimPacked.lhs utils/StringBuffer.lhs utils/UnicodeUtil.lhs
number of platforms). The registerised port is being held up as none of
the developers have regular access to such a machine.
I'm new to Haskell but not to assembler - is the work required
something that someone in my position could contribute to?
___
kip.macy:
number of platforms). The registerised port is being held up as none of
the developers have regular access to such a machine.
I'm new to Haskell but not to assembler - is the work required
something that someone in my position could contribute to?
Certainly. Not much Haskell is
[...]
warning: don't know how to split object files on this architecture
[...]
Wolfgang, Ryan - that looks like a splitter problem, no?
Definitely. Looks like there is no splitter for x86-64. SplitObjs=NO is
definitely required.
(The splitter is more of a dark art than the evil mangler, I
28 matches
Mail list logo
