Sounds good!
Remember that the memory-allocation mechanism is crucial. How does BN
do that?
| (3) I have been looking at how to implement a dual-constructor-in-a-
| pointer for Integer (i.e., merge constructors of small Integers and
| big Integers into the Int#). Would that solution be
On 10 August 2006 06:32, Peter Tanski wrote:
for the Makefile in ghc/rts, in lines 300-346,
GC_HC_OPTS += -optc-O3
--isn't this problematic? gcc, from -O2 on includes
-fgcse which
may *reduce* runtime performance in programs using
Please, what is the matter with Map.lookup ?
In ghc-6.4.1, I try
---
ghci -package base
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.4.1, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
Hi Serge,
Prelude Data.Map.singleton 'a' 'b'
{'a':='b'}
Prelude Data.Map.lookup 'a' $ Data.Map.singleton 'a' 'b'
Prelude
---
Must not it print Just 'b' instead of printing emptyness?
Further:
--
Prelude Data.Map.lookup 'b' $
Chris Kuklewicz wrote:
For the allocation functions in Foreign.Marshall.Alloc, are the function
contracts that return new pointers such that the pointers are never
nullPtr, or is it prudent to always check the new ptr?
Yes, the result of mallocBytes (for example) is never NULL. If the
Chris Kuklewicz wrote:
Your question has prompted me to go back into my PosixRE wrapping code
and compare it to the PCRE code. I have made some changes which ought
to enhance the performance of the PosixRE code. Let us see the new
bechmarks on 10^6 bytes:
PosixRE
Serge D. Mechveliani schrieb:
Please, what is the matter with Map.lookup ?
Map.lookup results in any monad. At the ghci prompt that is the IO monad
(and not Maybe).
Prelude :t Data.Map.lookup
Data.Map.lookup :: forall a (m :: * - *) k.
(Ord k, Monad m) =
k
simonmarhaskell:
Chris Kuklewicz wrote:
Your question has prompted me to go back into my PosixRE wrapping code
and compare it to the PCRE code. I have made some changes which ought
to enhance the performance of the PosixRE code. Let us see the new
bechmarks on 10^6 bytes:
PosixRE
Donald Bruce Stewart wrote:
simonmarhaskell:
Chris Kuklewicz wrote:
Your question has prompted me to go back into my PosixRE wrapping code
and compare it to the PCRE code. I have made some changes which ought
to enhance the performance of the PosixRE code. Let us see the new
bechmarks on
Dear [EMAIL PROTECTED] (and others),
This is relating to the problems we're experiencing with GHC's threaded
runtime on FreeBSD (see context below).
GHC itself, which is a Haskell program, when compiled with itself and
linked against GHC's threaded runtime, sometimes hangs eating 100% CPU.
This
Einar,
In my previous email I wrote something potentially confusing (really
a typo):
For developers (commercial or open source), the OpenSSL license
only mentions redistribution of the OpenSSL code in binary form
(paragraph 2). In this context binary form means the complete
program
On 10.08 11:16, Peter Tanski wrote:
Paragraph 6 of the OpenSSL (1998-2005) license states that:
* 6. Redistributions of any form whatsoever must retain the following
*acknowledgment:
*This product includes software developed by the OpenSSL Project
*for use in the OpenSSL
Einar,
*This product includes software developed by the OpenSSL Project
*for use in the OpenSSL Toolkit (http://www.openssl.org/).
All developers would have to do is include the acknowledgment stated
above.
I think this is not bad for specific applications, but forcing this
upon all
Did you try GHC's heap profiler?
Or simply running your program with +RTS -Sstderr will give you a clue
about the shape of the heap usage - each line is a single GC, and it
includes the amount of live data at that point.
If your program has a flat heap profile and yet is still grabbing
The latest cygwin version of make, 3.81, no longer supports the use of
DOS pathnames in makefiles, as has been the subject of much recent
discussion on the cygwin mailing list. The suggested quick fix is to
revert to the previous version 3.80.
___
There's one thing I don't entirely understand about the GMP problem. I understand that there are some limitations on GHC's ability to generate relocatable (and therefore dynamically linkable) code on x86 (a register allocation problem related to the mangler if I recall the comments in the code
Reilly Hayes on 2006-08-10 18:36:49 -0700:
There's one thing I don't entirely understand about the GMP problem.
I understand that there are some limitations on GHC's ability to
generate relocatable (and therefore dynamically linkable) code on x86
(a register allocation problem related
Reilly,
... this shouldn't prohibit linking
GMP in dynamically, should it? It's just a C library and GCC should
happily generate relocatable code. As a dynamically linked library,
there should be no tainting issues to worry about even if the
dynamically linked code is shipped with the
18 matches
Mail list logo
