On Thu, 8 Jul 2004, John Kozak wrote:
The root problem is that random number generation is inherently
stateful, and so the familiar imperative idioms don't translate
directly into a pure functional language. In a C-like language, each
invocation of rand() mutates a secret piece of state lurking
Hi,
Ralf Wildenhues wrote a patch ANSIfying hp2ps, which included a fix that
could avoid a bug. See:
bugs.kde.org/show_bug.cgi?id=82098
N
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
Hi,
The following patch fixes a bug in hp2ps that causes silly numbers like
84,762,122,-646
to appear in the heading. The problem was that 'n' is (can be) a 64-bit
type, and converting to an int before doing the modulo gives rounding
errors.
The fix is courtesy of Ralf Wildenhues ([EMAIL
On Tue, 30 Mar 2004, Simon Marlow wrote:
The upshot of what he found is that we could benefit from some
prefetching, perhaps on the order of 10-20%. Particularly prefetching
in the allocation area during evaluation, to ensure that memory about to
be written to is in the cache, and similar
On Sat, 27 Mar 2004, Adrian Hey wrote:
Also, I have a hunch that not only is eager evaluation inherently
more efficient (in terms of the raw number of operations that need
to be performed), it's probably more cache friendly too (you probably
end up with code that looks far more like a
On Sat, 29 Nov 2003, Graham Klyne wrote:
Following this debate, I find myself wondering if this is not something
that might be optimized behind the scenes as a common case, rather than
changing the computational model presented.
Argh, please, no! I find this kind of implicit optimisation can
On Wed, 12 Nov 2003, Tom Pledger wrote:
Hal Daume III writes:
:
| *all* i care about is being able to quickly calculate the size of
| the intersection of two sets. these sets are, in general, very
| sparse, which means that the intersections tend to be small.
|
| for example, i
On Wed, 1 Oct 2003, Robert Ennals wrote:
Haskell is a good language, pureness is good, type classes are good,
monads are good - but laziness is holding it back.
Hear hear.
I have often wondered how much simpler the various Haskell implementations
would be if they used strict evaluation. It
On Thu, 2 Oct 2003, Wolfgang Jeltsch wrote:
Yes, but I think that the reason for laziness is not to make compiler
constructors' lifes easier but language users'.
I appreciate the prefer-users'-ease-over-compiler-writers' idea. For
example, syntactic sugar can be a great thing. But I think
On Thu, 2 Oct 2003, Nicholas Nethercote wrote:
I appreciate the prefer-users'-ease-over-compiler-writers' idea. For
example, syntactic sugar can be a great thing. But I think there's a
point where it becomes too much. Haskell has arguably passed that point.
Sorry, this was ambiguous; when
On Thu, 2 Oct 2003, Thomas Johnsson wrote:
I'm convinced that if laziness (or call by name) were the norm in
languages in general, then there would be similar traffic
in lists like this one about the problems of strict evaluation -- and
there would be a lot more of it,
since strictness
On Wed, 30 Jul 2003, Simon Peyton-Jones wrote:
Interesting. We're clueless about hp2ps here at GHC home base. Would
you (or any else) like to fix this? We'd be happy to apply a patch,
needless to say!
The following seems to do the trick.
N
*** Marks.bad.c 2003-07-30 18:00:12.0
Hi,
I found a bug in hp2ps: if you use MARKs, it seems to assume the x-axis
starts at zero. So if your x-axis starts at, say, 5, then all the marks
get shifted to the right by 5 x-units. See attached file for an example.
This is with GHC 5.04.2, but judging from CVS most of hp2ps hasn't been
.
And if that doesn't scare you off, maybe this will:
Nicholas Nethercote. The Analysis Framework of HAL. Master's Thesis,
University of Melbourne, September 2001.
www.cl.cam.ac.uk/~njn25/pubs/masters2001.ps.gz
(Chapter 7)
It's more specific (describes a particular implementation) and goes into more
On Wed, 13 Mar 2002, Manuel M. T. Chakravarty wrote:
Depends where you are, I guess. In Sydney, it would be
easy. We are teaching Haskell to about 1500 first-year
students every year.
I know that there are a number of schools in Germany and the
UK who teach functional programming on a
Hi,
When I compile a HEAD version from this morning with GHC 5.02.2, there is
a deprecated warning for the use of 'tryAllIO' by
compiler/rename/RnHiFiles.lhs.
But when I compile it with a HEAD version, it gives an error and says that
Exception doesn't export 'tryAllIO' any more. When I replace
Hi,
I tried building the standard library in libraries/ with gcc 3.0.4; it
grinds to a halt at this point:
Data/Array/Base.hs:1162:
Warning: foreign declaration uses deprecated non-standard syntax
ghc-asm: (mangler) still have jump involving %edi!
srRN_ret:
movl%esi, %eax
On Fri, 22 Feb 2002, Simon Marlow wrote:
| srRN_ret:
| movl%esi, %eax
| andl8(%ebp), %eax
| cmpl4(%ebp), %eax
| setne %al # al = eax==4(ebp) ? 1 :
0
| movzbl %al, %edi # edi is 0 or
On Wed, 13 Feb 2002, Simon Marlow wrote:
../../ghc/utils/ghc-pkg/ghc-pkg-inplace --update-package
lang.conf.inplace
Reading package info from stdin... done.
Expanding embedded variables...done.
dependency `base' doesn't exist
make[2]: *** [boot] Error 1
make[1]: *** [boot] Error 1
On Wed, 13 Feb 2002, Nicholas Nethercote wrote:
That's what I did. It made ghc ok, but then when it tries the 'make
boot' in hslibs it falls over. The same happens if I change into
$(BUILD)/hslibs and do 'make boot'...
Ok, I've worked out the problem: I just checked out the modules ghc
Hi,
I'm having trouble adjusting the stack size, viz:
+ cacheprof +RTS -K8M -RTS gcc -I. -I. -c /tmp/ghc5664.s -o PrelTup.c_o
Stack space overflow: current size 1048576 bytes.
Use `+RTS -Ksize' to increase it.
I'm trying to increase it! The program was compiled with GHC 5.02.2. Any
On Tue, 29 Jan 2002, Simon Marlow wrote:
If you want to build GHC in different ways, eg. with
ticky-ticky profiling
on, you can do it by setting GhcLibWays=t. This make two
versions of
all the library .o files and .a files, a normal one, and a ticky-ticky
one.
My question is:
Hi,
If you want to build GHC in different ways, eg. with ticky-ticky profiling
on, you can do it by setting GhcLibWays=t. This make two versions of
all the library .o files and .a files, a normal one, and a ticky-ticky
one.
My question is: can you stop it from making the normal one?
Thanks
Hi,
I just installed GHC 5.02.2 (actually, the latest version from CVS), and
had a strange problem. My first attempt worked ok, but I screwed something
up, so I junked it and started again from scratch.
This time, it died part-way through the make boot step for ghc
itself, because
On Fri, 25 Jan 2002, Simon Marlow wrote:
Nothing springs to mind, unless you had explicitly set
$(ProjectsToBuild) in your build.mk, and left out glafp-utils. It
usually isn't necessary to set $(ProjectsToBuild) as it defaults to
building all the projects in the current tree.
Aha, that
On Fri, 25 Jan 2002, Nicholas Nethercote wrote:
Also, when I try to compile for ticky-ticky profiling...
Further in the ticky-ticky adventure...
Having compiled the libraries and RTS and other bits for ticky-ticky, when
I try the -ticky option with ghc I get loads of messages like
Hi,
User Guide section 4.12.1 Replacing the program for one or more phases
(haskell.org/ghc/docs/latest/set/options-phases.html#REPLACING-PHASES) is
missing the actual options. They are given in section 4.19.21, however
(haskell.org/ghc/docs/latest/set/flag-reference.html#AEN5804).
--
Nick
Hi,
I think there's a bug in the reporting of GC stats. For example, when
running the nofib program imaginary/x2n1, I get this output:
41,864,696 bytes allocated in the heap
1,688,656 bytes copied during GC
764,280 bytes maximum residency (2 sample(s))
155 collections in
Hi,
The Vim syntax file for literate Haskell programs handles code lines that
begin with a '' character fine. But in GHC much of the code is defined
between \begin{code} and \end{code} pairs, and that shows up as one
giant comment.
Does anybody know where I might be able to obtain a Vim syntax
29 matches
Mail list logo
