Hello Peter,
Friday, August 11, 2006, 4:00:40 AM, you wrote:
> OpenSSL's BN library is primarily tuned to support cryptography,
> particularly the generation of very large primes for public key
> cryptosystems. It is possible to separate the BN library out (I am
> having some success there a
I have a Mac as well, but it is an intel one. GHC does NOT support dynamic linking of Haskell libraries on intel macs, but C libraries like readline & GMP dynamically link just fine. For example:$ otool -L /usr/local/ghc/lib/ghc-6.5/ghc-6.5/usr/local/ghc/lib/ghc-6.5/ghc-6.5: /usr/local/lib
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 executa
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 relat
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 cor
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.
___
G
Thorkil,
I would like to mention a few things that I have not seen
discussed: Clearly,
using an existing library unmodified would be preferable: New
developments,
error corrections, documentation, wide exposure, all of these
things would be
available.
Agreed. Unfortunately for us it see
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 more
Hello,
On Thursday 10 August 2006 07:31, Peter Tanski wrote:
...
> Summary: I finally settled on modifying OpenSSL, since that would be
...
Being a heavy user of Haskell Integers, I have followed this development with
great interest. Although your decision has its drawbacks, it could very well
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
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,
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
Einar,
Summary: I finally settled on modifying OpenSSL, since that would be
the easiest to work with under GHC's hood (plain C code, not C++). I
have to:
Does this cause license problems?
I think OpenSSL license had the advertising clause which means
problems if Haskell programs want to link
Remember that the memory-allocation mechanism is crucial. How does BN
do that?
BN uses a structure called "CTX"--OpenSSL calls all such structures
"CTX"--to hold the local static variables for reentrancy. CTX
structures do not affect memory allocation, though they *do* require
malloc'd m
Simon,
Possibly, yes. IIRC, -O3 was mainly to get some loop unrolling. This
is a performance-critical part of the system though, and when
making any
changes we like to measure things to make sure we haven't pessimised
performance.
I will try to test it both ways, then. Also, -optc-O3 is
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 h
On Thu, 2006-08-10 at 11:32 +0100, Simon Marlow wrote:
> So I still don't understand why PCRE should be 40 times faster than PosixRE.
> Surely this can't be just due to differences in the underlying C library?
Read Ville's papers. Includes comparisons of GNU regex
and PCRE.
--
John Skaller
F
hello @ all,
I tried to install wxhaskell for my ghc6.4.2, but not everything went
properly...
I used the newest version of cygwin, wxWidgets 2.6.3, wxHaskell 0.9.4 and gcc
3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)
I didn't have any problems by installing and compiling wxWidgets, eve
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 1
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:
> >
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) =>
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
(102363,["bcdcd","cdc"],["
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 allocat
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' $
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/
\__
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
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 workab
27 matches
Mail list logo
