Something very odd is going on. GHC does not generate programs than run
3x faster between GHC versions.
If, perhaps, you compiled both without -O, no cross-module inlining
takes place. That would account for a big slow down when using separate
compilation. I see you use -O2 this time.
I
At 08:44 31/07/03 +0100, Simon Peyton-Jones wrote:
I don't know why the all in one version might go slower though
Virtual memory thrashing? (Hal did say something about needing lots of RAM.)
#g
---
Graham Klyne
[EMAIL PROTECTED]
PGP: 0FAA 69FF C083 000B A2E9 A131 01B9 1C7A DBCA
Simon Peyton-Jones wrote:
| I don't know why the all in one version might go
| slower though.
How about some (artificial) cut-offs during optimization
phases? Optimizing a hugs module could lead to some kind of
combinatorial explosion (which gets cut off by the
optimizer) which does not happen
John Peterson recently handed over control of the Haskell Merchandise
area of haskell.org to me and, in celebration, I've created a bunch of
provisional designs for new Haskell, FP and types-related swag.
The logos include the original and new haskell.org logos and about
15 others, designed
I seldom post things here, but Fritz, you are a genius!
/David
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
=
The (Interactive) Glasgow Haskell Compiler -- version 6.0.1
=
A Mac OS X package id now available at:
http://www.uni-graz.at/imawww/haskell/GHC.6.0.1.dmg
Cheers,
i've noticed in a lot of my imperative-looking monadic code, i have lots
of stuff that looks like:
... = do
q - some test
if q
then return some constant
else do
major code body here
lots of these things embedded makes the code hard to read and introduces
way too much
On Thu, 31 Jul 2003 13:18:40 -0700
Hal Daume [EMAIL PROTECTED] wrote:
so, my questions are: does this exist in some other form I'm not aware
of? is there something fundamentally broken about this (sorry for the
pun)? any other comments, suggestions?
This looks like a bizarre rendition of
[Crossposted to Haskell and Libraries. Replies to Libraries.]
-- More comments, please. Bad names? Important missing functionality?
-- Still unimplementable?
module System.RawIOSecondDraft (...) where
data File -- now essentially a file handle
data InputChannel -- renamed
This looks like a bizarre rendition of the Error/Exception monad.
Yes, of course. *Hal slaps himself*
Thanks.
Also, your motivating example is ambiguous. I think you mainly care
about the case where the test is testing for some exceptional
condition. I personally wouldn't want to use
[Crossposted to Haskell and Libraries. Replies to Libraries.]
{-
Good things about this text library design:
* Efficient implementation should be straightforward
* Character coder interface is public, so users can supply their own
encodings, or write coder transformers (there are some
Hi Ben,
Bad things:
* There's no way to implement fgetpos/fsetpos type functionality,
because coders don't expose their internal state. (In fact, there
would need to be a way to explicitly copy the state, since it may
well include IORefs, Ptrs, etc.) Is this a serious
presumably if you are doing random access on the file, it is in a known
nonarbitrary text encoding (like utf8). in which case you can
read/access the file with the binary routines and just use the
appropriate text conversions to get data out.
John
On Thu, Jul 31, 2003 at 03:55:44PM
This message describes functions safeCast and sAFECoerce implemented
in Haskell98 with common, pure extensions. The functions can be used
to 'escape' from or to existential quantification and to make
existentially-quantified datatypes far easier to deal with. Unlike
Dynamic, the present approach
Ben Rudiak-Gould wrote:
module System.TextIOFirstDraft (...) where
-- A BlockRecoder takes source and destination buffers and does some sort
-- of translation between them. It returns the number of values (not
-- bytes!) consumed and the number of values produced. It does not have to
--
Throughout this message you imply, if not outright state, that Dynamics
requires unsafeCoerce/unsafePerformIO. This is simply not the case.
GHC implements Dynamics with unsafeCoerce, or did last time I checked,
but it can easily be implemented using only existentials. (I presume
that this
Hi all,
I recently switched to ghc 6.0.1 running on a debian linux box.
When compiling a program using
ghc --make -O
or
ghc --make -O2
I get lots of errors while linking.
The linker concerns about undefined references to Data.FiniteMap, which I
frequently use.
For example, the linker says:
I recently switched to ghc 6.0.1 running on a debian linux box.
When compiling a program using
ghc --make -O
or
ghc --make -O2
I get lots of errors while linking.
The linker concerns about undefined references to
Data.FiniteMap, which I
frequently use.
For example, the linker
I haven't investigated in detail, but I believe your problem might be
caused by a known bug in the implementation of forkProcess, namely that
when forking from a child thread it doesn't kill the main thread. The
workaround is to fork (in your case call popen) from the main thread,
not a child
On Wed, 30 Jul 2003 18:01:22 +0100, you wrote:
GHCziBase_True_closure is a symbol that should be coming from the base
package, the GHC.Base module in particular. You could check that
libraries/base/libHSbase.a looks reasonable: it should be on the order
of 17Mb. Try 'nm' on it, look for some of
On Wed, 30 Jul 2003 18:01:22 +0100, you wrote:
GHCziBase_True_closure is a symbol that should be coming
from the base
package, the GHC.Base module in particular. You could check that
libraries/base/libHSbase.a looks reasonable: it should be on
the order
of 17Mb. Try 'nm' on it, look
On Thu, Jul 31, 2003 at 08:55:01AM +0200, Jan Scheffczyk wrote:
Hi all,
I recently switched to ghc 6.0.1 running on a debian linux box.
When compiling a program using
ghc --make -O
or
ghc --make -O2
I get lots of errors while linking.
The linker concerns about undefined references
On Thu, 31 Jul 2003 13:57:02 +0100, you wrote:
What is odd is that ghc-inplace is invoked by the make process several
times before this big one (which appears to be the start of stage 2?)
and works fine...
Do the errors really refer to GHCziBase_True_Closure, or is it
GHCziBase_True_closure?
Hi Ian,
If you are not already using them then you could try the debs from the
Haskell Experimental repository. Both stable and unstable debs are
available (unfortunately they are awaiting manual intervention before
going into the Debian archive as there are a couple of new package
names):
=
The (Interactive) Glasgow Haskell Compiler -- version 6.0.1
=
A Mac OS X package id now available at:
http://www.uni-graz.at/imawww/haskell/GHC.6.0.1.dmg
Cheers,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sorry,
I've worked it out. Didn't read the docs properly as usual.
Tom
On Thu, 31 Jul 2003 04:20 pm, Thomas L. Bevan wrote:
Here is a copy of all the files I am using to try to export a Haskell
function.
This compiles but produces a executable
In attempting to improve the CSV parser based on comments, I have the
following code that's attached. I'm having a heck of a time getting the
double quotes = an escaped quote thing to work. There is some commented out
code which was my last attempt. As it stands the code works, minus the
(moved to haskell cafe -- hopefully the other threads will follow)
I don't know why the all in one version might go slower though
Virtual memory thrashing? (Hal did say something about
needing lots of RAM.)
only to compile. i haven't measured, but the resulting executable
shouldn't
(haskell-cafe now)
Interesting. I've stripped them and they are exactly the same size.
diff says they differ though. pre-stripping, the normal nhc (non ai1)
is marginally larger (6.8m versus 7.0m).
I'll try to measure memory usage if someone tells me how :)
- Hal
--
Hal Daume III
(cafe)
This seems like a reasonable hypothesis. Is there a way to get GHC to keep trying,
despite the enormity of the input file?
Specifically, I expect it to do a better job of (a) inlining and (b) specialization.
Is there a way to hint to it to try a bit harder? :)
- Hal
--
Hal Daume
30 matches
Mail list logo
