easily adapt
to than Haskell.
Sengan
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
of the data out to C++, so that the heap only contains things
soon to be freed. I know generational garbage collection is supposed to help,
but it doesn't seem to. Is there a pure Haskell solution to this problem?
Sengan
___
Haskell mailing list
[EMAIL
http://www.catb.org/~esr/writings/taoup/html/ch01s06.html
states that debugging often occupies three-quarters or more of development time.
I don't think that is my experience in Haskell... more like 1/4 at most. I was
wondering what others felt.
Sengan
Has anyone written a binding to the BSD libdb ?
Sengan
---
There's a limit to all things, and everything that passes its limit destroys itself.
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman
assume the new native threads stuff could be used here.
Sengan
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
of
effort to change all those APIs and dependent code
for this 1 change.
Sengan
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
.
Thanks a lot,
Sengan
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
be trying it out. Thanks.
Sengan
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
clearer than its equivalent using
(++) etc. I've noticed this notation doesn't work with
hugs, so I might be violating the Haskell 98 spec.
Sengan
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow
a debugger: allow the user
to associate regions of code (or instructions from the instruction
stream) with displaying of the FPU registers on the screen.
-- saving/restoring the layout of the app as customized by the
user.
Sengan
___
Haskell mailing
you've finished renaming stdin/stdout.
Instead use the Windows functions.
Sengan
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
http://www.paulgraham.com/paulgraham/avg.html
I wonder how Haskell compares in this regard.
Any comment from Haskell startups? (eg Galois Connections)
Sengan
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
be a completely different way of generating the list, which took much less
processing. Had I had a means of measuring profiling burn-rate, I'm guessing that
it would have brought this to my attention earlier. I only found it because of a
guess that I checked with Ghood.
Sengan
_
ling currently gives us
only the first dimension not the second, if I understand it correctly.
Sengan
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
suggestions on how to find out where stack's being used?
Thanks
Sengan
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
ghc -c -fglasgow-exts -cpp -O2 -fvia-C -O2-for-C -syslib data -syslib lang -syslib
concurrent MonadErr.lhs
panic! (the `impossible' happened):
TcTyClsDecls:get_sig
Please report it as a compiler bug to [EMAIL PROTECTED]
As soon as I add inlining I get:
Without inlining I get
bly using daVinci) how it gets evaluated:
Lazyness behaviour is not always obvious, I'd like to see it.
I've been wanting to code one of these myself, but have had no time. Try and see
if stg-hugs is useable yet since that would be a much better environment to do
it in.
Sengan
___
) whereever possible.
Agreed?
Sengan
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
otice that ghc does not seem
to use mapM except in 2 modules.
Another odd thing is that hp2ps says that a b are the culprits, but the
-p and -px options say p is. Why?
Sengan
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
[EMAIL PROTECTED] (Sengan Baring-Gould) wrote:
mapM seems to be a memory hog (and thus also concatMapM).
In the following eg:
main = mapM print ([1..102400] :: [Integer])
memory usage climbs to 1.6M with ghc and needs -K20M
As a guess: since 'mapM print ([1..102400
[EMAIL PROTECTED] (Sengan Baring-Gould) wrote:
mapM seems to be a memory hog (and thus also concatMapM).
In the following eg:
main = mapM print ([1..102400] :: [Integer])
memory usage climbs to 1.6M with ghc and needs -K20M
As a guess: since 'mapM print ([1..102400
program is not being sufficiently lazy? Are there
papers on such things I could read?
Sengan
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
t too. Non deterministic is not
that important. Worst time is.
Sengan
I'm writing a program that involves the use of an interaction
Monad. However it seems to be insufficiently lazy to provide
any interaction. The following code is derived from my original
but highly simplified. Why is "works" lazy, but "main" is not?
Thanks for any help
Senga
"S.M.Kahrs" wrote:
newtype Inftype b = A (b,Inftype)
newtype Alist a = B (Either () (a,Alist a))
infy = A (1,infy)
onetwothree = B (Right(1,B(Right(2,B(Right(3,Left ()))
The following works with hugs.
newtype Inftype b = A (b,Inftype b)
newtype Alist a = B (Either () (a,Alist a))
http://www.debian.org/Lists-Archives/debian-devel-announce-0003/msg7.html
Sorry if this has already been mentionned. It's not in
http://www.dcs.gla.ac.uk/mail-www/haskell/
Sengan
26 matches
Mail list logo
