Ketil Malde wrote:
Ketil Malde [EMAIL PROTECTED] writes:
18580 ketil 18 0 1762m 945m 256 D 3.0 93.5 33:52.81 rbr
So it used more than double the amount of memory.
I can provide the source, but perhaps I should mention that the
program basically just builds a large Map Int Int.
Simon Marlow [EMAIL PROTECTED] writes:
So it used more than double the amount of memory.
Is it reproducible? I expect that the -M value might be exceeeded by
a small amount sometimes, but double is surprising.
Yes. That is, I was running multiple instances on different CentOS
computers,
Thanks a lot for the sugestions!
I am going to try them...
pedro
On 4/5/06, Björn Bringert [EMAIL PROTECTED] wrote:
Benjamin Franksen wrote: On Wednesday 05 April 2006 20:32, Pedro Miguel Duarte wrote:I am writing a Java program with a call to aHaskell module
M.hs,in order to evaluate some
I was curious if ghc could support the following basic types, they will
likely just be aliases of existing types.
WordPtr uintptr_t
WordMax uintmax_t
IntPtr intptr_t
IntMax intmax_t
all these C types are defined by ISO C so should be available,
otherwise, they are easy enough to generate in
On Thu, Apr 06, 2006 at 04:28:01PM -0700, John Meacham wrote:
I was curious if ghc could support the following basic types, they will
likely just be aliases of existing types.
WordPtr uintptr_t
WordMax uintmax_t
IntPtr intptr_t
IntMax intmax_t
all these C types are defined by ISO C so
I am rewriting my Debian From Scratch (DFS/dfsbuild) system using
Haskell. As part of this effort, I've been making improvements in
MissingH, and have release 0.14.0.
API changes include:
* Logger handlers now are passed the calling logger name.
* When a new logger must be spontaneously
Hello minh,
Wednesday, April 5, 2006, 10:41:02 PM, you wrote:
but in 1/, i have to choose between different kind of array
representation (and i dont know which one is better) and it seems to
me that the resulting code (compiled) would have to be the same.
no, the code will be slightly
thanks a lot !
the code you give in the mail is +/- what i thought about ... is-it
the fastest way ?
thank you also for your lib, i will read it later in the day.
when i said would have to be the same in previous mail, it's because
i like to see haskell as a really high-level abstraction where
Hello minh,
Thursday, April 6, 2006, 12:41:32 PM, you wrote:
the code you give in the mail is +/- what i thought about ... is-it
the fastest way ?
if you will say about your task and speed requirements, i will say how
you can do it. the fastest way is to use asm :)
thank you also for your
I came up with a system of coloring -- you'll have to view this message as html to see it. You start with the input parameters -- those are green. Anything defined in terms of green is blue. Anything defined in terms of green blue is purple. Anything defined in terms of green, blue, and purple is
On Apr 5, 2006, at 4:51 PM, John Meacham wrote:
On Wed, Apr 05, 2006 at 10:34:09AM -0500, Spencer Janssen wrote:
How about an implementation that sets the deepSeq'd bit *after* each
field has been successfully deepSeq'd? deepSeq'ing a cyclic
structure
would behave just like an infinite
On Wed, Apr 05, 2006 at 03:41:55PM +0100, Simon Marlow wrote:
I have been giving signals some thought, and resarching what other
languages do, and have a semi-proposal-maybe.
We should be careful here: the Haskell standard has so far remained
platform-independent, and I think it would be
Simon Marlow [EMAIL PROTECTED] writes:
I think it's unnecessary to treat signals in the way you do - you're
assuming that a signal interrupts the current thread and runs a new
computation (the signal handler) on the same stack, completely blocking
the interrupted thread until the signal
Michael Goodrich wrote:
Also I know what strict means, but why are you saying that baz is strict?
Because otherwise the loop would be OK. For instance if baz were
baz x = 100 -- lazy
then the equations could be evaluated starting from
c0 = baz z0 = 100
rd0 = c0*c0*m = 100*100*m
-- etc.
Thanks so much for your help. I should have made clear that I was aware
that the definitions were mutually dependent. What I was hoping
was that Haskell could solve this for me without my having to resort to
effectively finessing any sequencing considerations.
Perhaps I am really asking it to do
On 2006-04-06 at 11:25EDT Michael Goodrich wrote:
Thanks so much for your help. I should have made clear that I was aware that
the definitions were mutually dependent. What I was hoping was that Haskell
could solve this for me without my having to resort to effectively finessing
any
Thanks so much for your help. I should have made clear that I was aware that
the definitions were mutually dependent. What I was hoping was that Haskell
could solve this for me without my having to resort to effectively finessing
any sequencing considerations.
Haskell is a functional
Hello David,
Wednesday, April 5, 2006, 9:30:33 PM, you wrote:
Since there is some interest in my EnumSet module, I am reposting it
here with a BSD license in anticipation of its rebirth as Data.Set.Enum.
pair of comments:
1) wordLength = bitSize (undefined::Word)
2) your library will not
On Apr 6, 2006, at 11:25 AM, Michael Goodrich wrote:
Thanks so much for your help. I should have made clear that I was
aware that the definitions were mutually dependent. What I was
hoping was that Haskell could solve this for me without my having
to resort to effectively finessing any
Curry does not have a constraint solver of its own. It
simply delegates all constraints to the FD solver of SICStus Prolog.
or that of SWI Prolog (which prompted my attempt to install Curry).
which was implemented by..hi, again!-) (*)
The all_different constraint subsumes the rules that
On Thu, 6 Apr 2006, Claus Reinke wrote:
Curry does not have a constraint solver of its own. It simply delegates all
constraints to the FD solver of SICStus Prolog.
or that of SWI Prolog (which prompted my attempt to install Curry).
which was implemented by..hi, again!-) (*)
The
Thank you all for your excellent comments.
I was aware of Hughe's technique and the 'whyfp' paper.
I had often thought that some kind of iteration would be necessary to
reolve this, and to overcome initially this I was cheating and using
one of the values one step late in order to break the
Hi -
I've been wondering for a long time if there is a reason why Ord should
inherit from Eq and not vice versa, or whether in fact there is any
justification for making either Ord or Eq inherit from the other one.
For example, Ord and Eq could alternatively be defined as:
class Ord a where
On Thu, Apr 06, 2006 at 09:31:24PM +0100, Brian Hulley wrote:
I've been wondering for a long time if there is a reason why Ord should
inherit from Eq and not vice versa, or whether in fact there is any
justification for making either Ord or Eq inherit from the other one.
The problem is that
On Apr 6, 2006, at 10:35 AM, Bulat Ziganshin wrote:
1) wordLength = bitSize (undefined::Word)
How'd I miss that one? Thanks.
2) your library will not work with Hugs 2003, what is the latest
official (non-beta) version. Portability : portable ?
Fixed by changing portable to non-portable
On Thu, 6 Apr 2006 21:31:24 +0100, you wrote:
I've been wondering for a long time if there is a reason why Ord should
inherit from Eq and not vice versa, or whether in fact there is any
justification for making either Ord or Eq inherit from the other one.
Support for the concept of
John Meacham wrote:
On Thu, Apr 06, 2006 at 09:31:24PM +0100, Brian Hulley wrote:
I've been wondering for a long time if there is a reason why Ord
should inherit from Eq and not vice versa, or whether in fact there
is any justification for making either Ord or Eq inherit from the
other one.
Am Mittwoch, 5. April 2006 15:09 schrieb Chris Kuklewicz:
Henning Thielemann wrote:
On Mon, 3 Apr 2006, Jared Updike wrote:
or ambiguously) with your Sudoku solver? A rough mesaure of the
difficulty of the unsolved puzzle could be how long the solver took to
solve it (number of steps)
On Thu, Apr 06, 2006 at 10:52:52PM +0100, Brian Hulley wrote:
in haskell classes _do_ define interfaces, not concrete
representations so the problems with inherentence of non-abstract
classes in OO languages don't apply.
What I was trying to argue was that inheritance of classes in Haskell
On Thursday 06 April 2006 06:44 pm, John Meacham wrote:
On Thu, Apr 06, 2006 at 10:52:52PM +0100, Brian Hulley wrote:
[snip a question about Eq and Ord classes]
well, there are a few reasons you would want to use inheritance in
haskell, some good, some bad.
1. one really does logically
On Apr 6, 2006, at 6:05 PM, Daniel Fischer wrote:I've also written a version using David F. Place's EnumSet instead of [Int], that takes less MUT time, but more GC time, so is slower on the 36,628 test, but faster for a single puzzle. That's a curious result. Did you compile with optimization?
John Meacham wrote:
On Thu, Apr 06, 2006 at 10:52:52PM +0100, Brian Hulley wrote:
[snip]
The problem of allowing classes (in Haskell) to inherit is that you
end up with heirarchies which fix the design according to some
criteria which may later turn out to be invalid, whereas if there
were no
On 4/6/06, Brian Hulley [EMAIL PROTECTED] wrote:
What about:
class Eq a where (==), (/=) :: ...
class PartialOrd a where
(), () :: a-a-Bool
x y = y x
class (PartialOrd a) = TotalOrd a where x = y = not (y x)
-- = not meaning inheritance but just a restriction on a for
Brian Hulley wrote:
John Meacham wrote:
[snip]
1. one really does logically derive from the other, Eq and Ord are
like this, the rules of Eq says it must be an equivalance relation
and that Ord defines a total order over that equivalance relation.
this is a good thing, as it lets you write code
G'day all.
Quoting Robert Dockins [EMAIL PROTECTED]:
Eww! Be careful how far you depend on properties of typeclasses, and make
sure you document it when you do.
The behaviour of NaN actually makes perfect sense when you realise that
it is Not a Number. Things that are not numbers are
35 matches
Mail list logo
