ghc, tls, gmp

Hi, in Debian, we have the (well-known) problem of linking against libraries using libgmp, in this case haskell-curl, which links against libcurl, which links against gnutls, which uses libgmp since the latest release: https://lists.debian.org/debian-haskell/2014/07/msg0.html Are there any vi

Re: renamed GMP symbols in GHC

l problem, I have been working with Dan Peebles on a nice set of MPFR bindings for my own purposes using custom foreign prims. I unpacked the main MPFR structures and let the ghc garbage collector move everything around, like it does with GMP itself. We've been able to get a version that AL

Re: renamed GMP symbols in GHC

Hi, Am Donnerstag, den 05.01.2012, 16:21 -0500 schrieb Brandon Allbery: > In any case, I am starting to approach the point of "so will Debian > allow ghc to remain compatible with non-Linux?", since so far I'm > getting the distinct impression that solutions that work on Linux are > all that mat

Re: renamed GMP symbols in GHC

* Simon Marlow: > One potential problem is that some Linux distributions really don't > like it if you bundle modified versions of external libraries. > However, I just don't see a way around this: GMP is inherently broken > because it has global state, so if you wa

Re: renamed GMP symbols in GHC

On Thu, Jan 5, 2012 at 16:15, Joachim Breitner wrote: > Am Donnerstag, den 05.01.2012, 14:14 -0500 schrieb Brandon Allbery: > > On Thu, Jan 5, 2012 at 13:53, Joachim Breitner > > wrote: > > (But I am really wondering why the linker cannot do something > > that has > > the

Re: renamed GMP symbols in GHC

e). Unfortunately, using dlopen does not not help if some other shared library loads gmp regularly; there is still only one global state. And statically linking gmp into the share object does not work, as Simon predicted, because the static gmp library is not compiled with PIC. The promising ld o

Re: renamed GMP symbols in GHC

On Thu, Jan 5, 2012 at 13:53, Joachim Breitner wrote: > (But I am really wondering why the linker cannot do something that has > the same effect as objcopy --prefix-symbols, but on the fly.) > Some of them can; notably the binutils ld, which comes from the same source as and uses the same mechan

Re: renamed GMP symbols in GHC

Hi, Am Mittwoch, den 04.01.2012, 22:00 +0100 schrieb Joachim Breitner: > And would dlopen make a difference? RTLD_LOCAL sounds interesting... it seems that some OSs provide a RTLD_PRIVATE which does exactly what we need: http://uw714doc.sco.com/en/man/html.3C/dlopen.3C.html But unfortunately, gl

Re: renamed GMP symbols in GHC

om name dropping here)? That would seem to be an elegant solution, > > as it makes the distro packers happy and you would not have to maintain > > a code copy. > > In the past, I've linked a C++ library that used gmpxx against a > Haskell program by renaming all sym

Re: renamed GMP symbols in GHC

On 04/01/2012 21:00, Joachim Breitner wrote: Would linking gmp statically help? E.g. is there a way to link libgmp into the RTS that the symbols are not visible to the linker any more? It has slightly more licensing complications - GMP is LGPL, which requires that the user of a program that

Re: renamed GMP symbols in GHC

On Thu, Jan 5, 2012 at 09:37, Simon Marlow wrote: > On 04/01/2012 21:00, Joachim Breitner wrote: > >> And would dlopen make a difference? RTLD_LOCAL sounds interesting... > > > Maybe, I haven't looked into that. > Beware of platform issues; IIRC RTLD_LOCAL doesn't do what one expects on Alphas.

Re: renamed GMP symbols in GHC

PIC (random name dropping here)? That would seem to be an elegant solution, as it makes the distro packers happy and you would not have to maintain a code copy. In the past, I've linked a C++ library that used gmpxx against a Haskell program by renaming all symbols starting with gmp to mygmp

Re: renamed GMP symbols in GHC

ge building infrastructure for debian or fedora, but for openbsd (where i'm doing a lot of haskell stuff), it would be enough if the ghc sources would include not only a (patched or unpatched) gmp source tree but also the ghc-specific patches to gmp. The rationale behind this polcicy (for

Re: renamed GMP symbols in GHC

om name dropping here)? That would seem to be an elegant solution, > > as it makes the distro packers happy and you would not have to maintain > > a code copy. > > In the past, I've linked a C++ library that used gmpxx against a > Haskell program by renaming all sym

Re: renamed GMP symbols in GHC

s the distro packers happy and you would not have to maintain > a code copy. In the past, I've linked a C++ library that used gmpxx against a Haskell program by renaming all symbols starting with gmp to mygmp using objcopy. Unfortunately, this is not portable and completely broke down o

Re: renamed GMP symbols in GHC

On Wed, Jan 4, 2012 at 11:50, Joachim Breitner wrote: > Now you might argue that gmp will never be the source of security > problems (although I woudn’t be too convinced about that). But even then > There's actually a patch for a (claimed to be minor potential) security issue ref

Re: renamed GMP symbols in GHC

patch the build > > system to use the system-provided libffi. > > I am curious about the precise definition of "bundled libraries". It > can be arranged that the GMP source is modified at GHC build time, so > the _source_ package contains the original unmodified

Re: renamed GMP symbols in GHC

2012/1/4 Michal Konečný > On Wednesday 04 January 2012 12:21:13 Simon Marlow wrote: > > GMP is inherently broken because it > > has global state, so if you want two use it from two clients in the same > > program, you need two copies of it. > > If this could be fi

Re: renamed GMP symbols in GHC

he system-provided libffi. I am curious about the precise definition of "bundled libraries". It can be arranged that the GMP source is modified at GHC build time, so the _source_ package contains the original unmodified tar of GMP (except without documentation). Nevertheless, the _binar

Re: renamed GMP symbols in GHC

[Fullquote for the benefit of those on the Debian Haskell list.] Dear Simon, Am Mittwoch, den 04.01.2012, 12:21 + schrieb Simon Marlow: > On 22/12/2011 22:58, Michal Konečný wrote: > > Several issues related to the way GMP is included in GHC were publicly > > discussed in th

Re: renamed GMP symbols in GHC

On 22/12/2011 22:58, Michal Konečný wrote: Several issues related to the way GMP is included in GHC were publicly discussed in the past with the goal of replacing GMP. As summarised in this wiki by Peter Tanski <http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes>, the main issue

renamed GMP symbols in GHC

Dear all, Several issues related to the way GMP is included in GHC were publicly discussed in the past with the goal of replacing GMP. As summarised in this wiki by Peter Tanski, the main issues were: (1) Licensing (2) Memory Structure; Simultaneous Access to GMP by Foreign (C) code in the

Re: Confusion about GHC and GMP

On Wed, Feb 17, 2010 at 04:04:16PM -0800, Greg Fitzgerald wrote: > > I was able to build GHC on Linux with no trouble. But on Windows, I go > down because (I think) the preprocessor is choking on ^M characters. > > I get errors like this: > libraries\haskeline\.\System\Console\Haskeline\Backend\W

Re: Confusion about GHC and GMP

> I assume you mean >http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes#CurrentStatus > in which case, yes. > >> I assume that "INTEGER_LIBRARY=integer-foo" is an option when >> compiling GHC itself and not when using GHC, correct? > > Yes. Great, thanks for your help Ian. Building GH

Re: Confusion about GHC and GMP

On Fri, Feb 12, 2010 at 01:17:13PM -0800, Greg Fitzgerald wrote: > I wonder if someone might be able to clear a few things up for me > about implementing Integer with GMP.  First, is the link below the > most up-to-date information regarding GHC's situation? > > http://hack

Confusion about GHC and GMP

I wonder if someone might be able to clear a few things up for me about implementing Integer with GMP.  First, is the link below the most up-to-date information regarding GHC's situation? http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes#BinaryDropinReplacementforGMP I assume

Re: Build of HEAD fails in integer-gmp

On Fri, Nov 27, 2009 at 8:09 AM, Simon Marlow wrote: > > This was temporary breakage, fixed a couple of days ago: > > http://www.haskell.org/pipermail/cvs-ghc/2009-November/051393.html > > Thanks. ___ Glasgow-haskell-users mailing list Glasgow-haskell-u

Re: Build of HEAD fails in integer-gmp

On 25/11/2009 21:20, Bryan O'Sullivan wrote: I get this error message, which suggests that the gmp-wrappers file should be compiled with -fPIC but isn't being: /usr/bin/ld: libraries/integer-gmp/dist-install/build/cbits/gmp-wrappers.dyn_o: relocation R_X86_64_PC32 against undefi

Build of HEAD fails in integer-gmp

I get this error message, which suggests that the gmp-wrappers file should be compiled with -fPIC but isn't being: /usr/bin/ld: libraries/integer-gmp/dist-install/build/cbits/gmp-wrappers.dyn_o: relocation R_X86_64_PC32 against undefined symbol `__gmpz_init' can not be used when makin

Re: gmp

chak: > Yitzchak Gale: > >OK for the time > >being, but it would be really, really good to be able to compile > >ghc without gmp. > > Well, just go ahead and write an alternative portable & high- > performance implementation of Integer. > > >This idea

Re: building against gmp in a nonstandard location

On Sun, Mar 30, 2008 at 03:37:35PM -0400, Paul Jarc wrote: > Ian Lynagh <[EMAIL PROTECTED]> wrote: > > the alternative would be to put the whole of $LDFLAGS into the Cabal > > buildinfo, but that feels wrong to me. > > Why so? By setting LDFLAGS, isn't the user asking for exactly that - > that th

Re: building against gmp in a nonstandard location

Ian Lynagh <[EMAIL PROTECTED]> wrote: > the alternative would be to put the whole of $LDFLAGS into the Cabal > buildinfo, but that feels wrong to me. Why so? By setting LDFLAGS, isn't the user asking for exactly that - that those flags be used when linking? paul

Re: building against gmp in a nonstandard location

On Fri, Mar 21, 2008 at 01:44:37AM -0400, Paul Jarc wrote: > > There are no --with-* flags for ncurses, so the only ways I can see to > say where ncurses is are the ones I'm already using, and which are > apparently insufficient - $CPPFLAGS/$LDFLAGS in the environment, and > SRC_HC_OPTS/SRC_HSC2HC

Re: building against gmp in a nonstandard location

Ian Lynagh <[EMAIL PROTECTED]> wrote: > Sorry, I meant --with-gmp-{includes,libraries}. Ah, ok. --with-gmp-* alone, without setting environment variables, creating mk/build.mk, or anything else, gives the same error as --with-gmp-* plus environment variables ("No rule to make

Re: building against gmp in a nonstandard location

On Thu, Mar 20, 2008 at 01:29:26PM -0400, Paul Jarc wrote: > Ian Lynagh <[EMAIL PROTECTED]> wrote: > > On Sun, Mar 16, 2008 at 12:05:03AM -0400, Paul Jarc wrote: > > >> Second attempt: CPPFLAGS, LDFLAGS and mk/build.mk as above, and I also > >> gave --with-gmp

Re: building against gmp in a nonstandard location

Ian Lynagh <[EMAIL PROTECTED]> wrote: > On Sun, Mar 16, 2008 at 12:05:03AM -0400, Paul Jarc wrote: >> make[1]: *** No rule to make target >> `stage1//package/host/code.dogmap.org/foreign/ghc-6.8.2+spf+0/conf/gmp/include/gmp.h', >> needed by `stage1/parser/cuti

Re: building against gmp in a nonstandard location

Hi Paul, On Sun, Mar 16, 2008 at 12:05:03AM -0400, Paul Jarc wrote: > > make[1]: *** No rule to make target > `stage1//package/host/code.dogmap.org/foreign/ghc-6.8.2+spf+0/conf/gmp/include/gmp.h', > needed by `stage1/parser/cutils.o'. Stop. Where is gmp.h actually i

building against gmp in a nonstandard location

I'm having some trouble building ghc against gmp installed in an unusual place. (Actually, I install every package in its own directory, but gmp seems to be the one causing trouble here.) First attempt: adding the necessary -I, -L, and -Xlinker -R options to CPPFLAGS/LDFLAGS when inv

RE: gmp

| > gmp is nice, it is really convenient. But someone needs | > to completely clarify the license issues in that case, and | > make it completely clear to all users. | | I completely agree that we need to document the situation clearly. Although I hate discussing licensing (which is why

Re: gmp

Yitzchak Gale: OK for the time being, but it would be really, really good to be able to compile ghc without gmp. Well, just go ahead and write an alternative portable & high- performance implementation of Integer. This idea of a Mac OS X binary with statically-linked gmp is nice, i

Re: gmp

Hello, On Thursday 17 January 2008 17:57, Christian Maeder wrote: > I understand that gmp is needed for the certain libraries like the > Prelude with Double and Integer. > > But I do not understand why gmp is so deeply buried in the rts. > Are the basic types Int and Pointer not

Re: gmp

Hi > What is the situation on Windows? Does the standard > GHC binary on Windows have dynamically linked gmp > for binaries produced by ghc? No, they are statically linked. (Please, can no one start discussing licensing, people already know there are issues with it, and I get plenty o

Re: gmp

Don Stewart wrote: > on any system where an external libgmp is available, it will > be dynamically linked into the generated haskell programs, > and in-tree gmp isn't used at all (or compiled, or installed) So on linux and *bsd, that should be fine. On Mac OS X (as a special cas

Re: gmp

phercek: > Christian Maeder wrote: > >I understand that gmp is needed for the certain libraries like the > >Prelude with Double and Integer. > > Why is GMP needed for Double? Based on the online report Double is > "double precision floating"; it does not

Re: gmp

gale: > Don Stewart wrote: > > However, its buried in the rts/distributed with the runtime, so that > > users may optionally use that version, rather than finding and > > installing their own external gmp package. On almost all platforms > > though, the distributed-with-

Re: gmp

Christian Maeder wrote: I understand that gmp is needed for the certain libraries like the Prelude with Double and Integer. Why is GMP needed for Double? Based on the online report Double is "double precision floating"; it does not need to represent arbitrary big numbers. I tho

Re: gmp

Don Stewart wrote: > However, its buried in the rts/distributed with the runtime, so that > users may optionally use that version, rather than finding and > installing their own external gmp package. On almost all platforms > though, the distributed-with-ghc gmp is unused. But doesn

Re: gmp

Christian.Maeder: > I understand that gmp is needed for the certain libraries like the > Prelude with Double and Integer. > > But I do not understand why gmp is so deeply buried in the rts. > Are the basic types Int and Pointer not enough to write a compiler like ghc? Integer

gmp

I understand that gmp is needed for the certain libraries like the Prelude with Double and Integer. But I do not understand why gmp is so deeply buried in the rts. Are the basic types Int and Pointer not enough to write a compiler like ghc? Cheers Christian

Re: FFI Bindings to Libraries using GMP

c/ghc/wiki/ReplacingGMPNotes/ PerformanceMeasurements. The statistics suggest that the OpenSSL BN has comparable performance to the GMP, especially for smaller numbers. Some note about the (very confusing) licensing issues regarding OpenSSL would also be nice. I will add this to the wiki.

Re: FFI Bindings to Libraries using GMP

ngGMPNotes/ PerformanceMeasurements. The statistics suggest that the OpenSSL BN has comparable performance to the GMP, especially for smaller numbers. Some note about the (very confusing) licensing issues regarding OpenSSL would also be nice. [1] Simple Performance Test on (ghc-darwin-i386-6.6.1):

Re: FFI Bindings to Libraries using GMP

Peter Tanski wrote: The one problem you will find with _all_ potential replacement libraries is incompatible behaviour for bitwise functions: they are implemented arithmetically in GMP but logically elsewhere (when they are implemented at all). I don't fully understand this... I made

Re: FFI Bindings to Libraries using GMP

On Sep 14, 2007, at 9:14 AM, Benedikt Huber wrote: | I've been struggling using FFI bindings to libraries which rely on the | GNU Mp Bignum library (gmp). It's an issue that bites very few users, but it bites them hard. It's also tricky, but not impossible, to fix.

Re: FFI Bindings to Libraries using GMP

Benedikt Huber wrote: > (3) So when replacing GMP with the BN library of OpenSSL Maybe the following license issues with OpenSSL should be taken into account: http://www.gnome.org/~markmc/openssl-and-the-gpl.html Regards, Zun. ___ Glasgow-hask

Re: FFI Bindings to Libraries using GMP

| I've been struggling using FFI bindings to libraries which rely on the | GNU Mp Bignum library (gmp). It's an issue that bites very few users, but it bites them hard. It's also tricky, but not impossible, to fix. The combination keeps meaning that at GHC HQ we work

RE: FFI Bindings to Libraries using GMP

I won't be at the hackathon I fear (and neither will Simon M) but I jotted down some notes about how to replace GMP with a Haskell library http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes/HaskellLibrary Simon | -Original Message- | From: [EMAIL PROTECTED] [m

Re: FFI Bindings to Libraries using GMP

neubauer: > Simon Peyton-Jones <[EMAIL PROTECTED]> writes: > > > Peter Tanski did exactly that (he's the author of the > > ReplacingGMPNotes above), but he's been very quiet recently. I > > don't know where he is up to. Perhaps someone else would like to > > join in? > > Since I live only five

Re: FFI Bindings to Libraries using GMP

Simon Peyton-Jones <[EMAIL PROTECTED]> writes: > Peter Tanski did exactly that (he's the author of the > ReplacingGMPNotes above), but he's been very quiet recently. I > don't know where he is up to. Perhaps someone else would like to > join in? Since I live only five minutes away from this yea

RE: FFI Bindings to Libraries using GMP

| I've been struggling using FFI bindings to libraries which rely on the | GNU Mp Bignum library (gmp) - this is apparently a well known problem | (http://hackage.haskell.org/trac/ghc/ticket/311, | http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes). | I do rely on using such libr

FFI Bindings to Libraries using GMP

Hello, I've been struggling using FFI bindings to libraries which rely on the GNU Mp Bignum library (gmp) - this is apparently a well known problem (http://hackage.haskell.org/trac/ghc/ticket/311, http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes). I do rely on using such libr

FFI and Libraries using GMP

Hello, I've been struggling using FFI bindings to libraries which rely on the GNU Mp Bignum library (gmp) - this is apparently a well known problem (http://hackage.haskell.org/trac/ghc/ticket/311). I do want to use some of those libraries however and so I started to get them work o

Re: Replacement for GMP: Update

Hello, On Wednesday 24 January 2007 16:30, Peter Tanski wrote: > ... > Thorkil Naur and others have suggested writing the whole > thing as small assembler operations and piece them together in > Haskell; I have been looking into that as well but it seems to entail > inlining every Integer f

Re: Replacement for GMP: Update

t even tested. I probably didn't clarify why I tested larger size operands. GHC should have something that is comparable to GMP, and that means speed (and precision) for medium-large operands as well as small operands. you are only benchmarking multiplicative or similar routines, giving A

Re: Replacement for GMP: Update

I think the benchmarks are flawed in an important way, I believe, (but am not positive) that ARPREC uses a special factorized form of representing numbers, which makes multiplicative type operations extremely fast, but simple things like addition/subtraction quite slow. you are only benchmarking m

Current GMP implementation

Hello Thorkil, I updated the wiki Replacing GMP/The Current GMP Implementation page with some introductory notes. I hope the pretty graphic cuts down on a lot of wording necessary. There is no discussion of the Cmm implementation as that is contained in Esa's posts to the GHC

Re: Replacement for GMP: Update

ARPREC, OpenSSL's BN, GMP and LibTomMath. ) I tested GMP and OpenSSL's BN for reference. I must confess that it took me a while to understand what you were doing here and I am still uncertain: For example, how many multiplications were actually performed for bit size 40

Re: Replacement for GMP: Update

September 2006 06:43, Peter Tanski wrote: > ... > > For a brief overview of the speed of the libraries I looked at > carefully, see > http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes > (I added a few charts to show the speed of ARPREC, OpenSSL's BN, GMP > and Li

Re[2]: bignums, gmp, bytestring, .. ?

Hello John, Tuesday, November 28, 2006, 4:52:09 AM, you wrote: >> The simple problem with Haskell and Integer is that, according to the >> Standard, Integer is a primitive: it is consequently implemented as >> part of the runtime system (RTS), > there is no requirement that Integer be a primit

Re: bignums, gmp, bytestring, .. ?

On Sat, Nov 18, 2006 at 04:46:24PM -0500, Peter Tanski wrote: > The simple problem with Haskell and Integer is that, according to the > Standard, Integer is a primitive: it is consequently implemented as > part of the runtime system (RTS), not the Prelude or any library > (though the interfac

Re: bignums, gmp, bytestring, .. ?

iirc. Donald, Thanks for tip! Have you seen any of this code yourself? Jeremy, Dr. Sloane would be a good person to contact. For reference, the last work on this seems to have been done in 2005. Tony Sloane (asloane -at- ics dot mq dot edu dot au). Patroklos Argyroundis did a port of GMP ve

Re: bignums, gmp, bytestring, .. ?

p.tanski: > On Nov 19, 2006, at 3:20 PM, Jeremy Shaw wrote: > >And, around this time, my interest in running yhi on PalmOS starts to > >wane. > > Awww... to my knowledge, that would be the first Haskell > implementation for PalmOS :) As I mentioned in a prior email, there > is a Haskell arbit

Re: bignums, gmp, bytestring, .. ?

On Nov 19, 2006, at 3:20 PM, Jeremy Shaw wrote: At Sun, 19 Nov 2006 13:46:10 -0500, Peter Tanski wrote: What is the problem building GMP for PalmOS? According to the GMP install documentation, it supports ARM and Motorola's m68k processors, so you would not be using generic C code. Yo

Re: bignums, gmp, bytestring, .. ?

At Sun, 19 Nov 2006 13:46:10 -0500, Peter Tanski wrote: > What is the problem building GMP for PalmOS? According to the GMP > install documentation, it supports ARM and Motorola's m68k > processors, so you would not be using generic C code. You are > probably also using P

Re: bignums, gmp, bytestring, .. ?

Hi Jeremy, On Nov 17, 2006, at 10:34 PM, Jeremy Shaw wrote: At Sat, 18 Nov 2006 00:44:32 +, Neil Mitchell wrote One advantage you probably haven't thought of is the size of the binary. ... On a related note -- dropping the gmp requirement would also make it easier to port yhc t

Re: bignums, gmp, bytestring, .. ?

programming, might still be quite acceptable for a substantial part of haskell uses? One advantage you probably haven't thought of is the size of the binary. Currently GMP adds about 50Kb on to the Yhc runtime, for what in the most cases is probably an occasional addition. If the bytecode

Re: bignums, gmp, bytestring, .. ?

On Nov 17, 2006, at 7:24 PM, Claus Reinke wrote: it seems that haskell versions of bignums is pretty much gone from more recent discussions of gmp replacements. now, I assume that there are lots of optimizations that keep gmp popular that one wouldn't want to have to reproduce, so t

Re: bignums, gmp, bytestring, .. ?

At Sat, 18 Nov 2006 00:44:32 +, Neil Mitchell wrote > One advantage you probably haven't thought of is the size of the > binary. Currently GMP adds about 50Kb on to the Yhc runtime, for what > in the most cases is probably an occasional addition. If the bytecode > for a b

Re: bignums, gmp, bytestring, .. ?

substantial part of haskell uses? One advantage you probably haven't thought of is the size of the binary. Currently GMP adds about 50Kb on to the Yhc runtime, for what in the most cases is probably an occasional addition. If the bytecode for a bignum library was less than this then there could

Re: bignums, gmp, bytestring, .. ?

claus.reinke: > it seems that haskell versions of bignums is pretty much gone from > more recent discussions of gmp replacements. now, I assume that > there are lots of optimizations that keep gmp popular that one wouldn't > want to have to reproduce, so that a haskell var

bignums, gmp, bytestring, .. ?

it seems that haskell versions of bignums is pretty much gone from more recent discussions of gmp replacements. now, I assume that there are lots of optimizations that keep gmp popular that one wouldn't want to have to reproduce, so that a haskell variant might not be competitive even if on

Update to Replacement GMP page

Hello all, I made another update to the notes on Replacing GMP, at http:// hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes . It's pretty basic and you'd probably find it shabby, but comments, modifications appreciated. I am still in the throes of trying to *portably* beat

Re: Replacement for GMP: Update

the speed of ARPREC, OpenSSL's BN, GMP and LibTomMath. I did not add speed tests for Crypto++ and Botan because they don't measure up. The original timings I obtained for them were based on their own benchmarks which are inadequate and (for Crypto++) based on tuned assembly

Re: Replacement for GMP: Update

Hello Peter, Sorry for the late reply. From your latest communication which seems to be Date: Sat, 12 Aug 2006 21:12:05 -0400 From: Peter Tanski <[EMAIL PROTECTED]> Subject: Re: OpenSSL License (was Replacement for GMP: Update) To: John Goerzen <[EMAIL PROTECTED]> I am a bit uncerta

RE: Re[2]: Replacement for GMP: Update

On 21 August 2006 16:20, Bulat Ziganshin wrote: > Hello Simon, > > Monday, August 21, 2006, 6:55:47 PM, you wrote: > >> Parallel major GC was worked on by Roshan James during his >> internship here this summer, and we have some working code, but it >> needs a lot more testing and tuning, and it m

Re[2]: Replacement for GMP: Update

Hello Simon, Monday, August 21, 2006, 6:55:47 PM, you wrote: >> is not exactly true. look at "Non-stop Haskell" > Simply because it adds overhead (both in runtime and code complexity), and the > benefits are relatively modest. i think that GC that don't stops the world is just a different produ

Re: Replacement for GMP: Update

Bulat Ziganshin wrote: Hello skaller, Sunday, August 13, 2006, 4:34:14 AM, you wrote: But the state of the art is then two stages behind the requirement: Haskell still has to 'world stop' threads to do a major collection. is not exactly true. look at "Non-stop Haskell" (http://www.haskell.o

Re[8]: Replacement for GMP: Update

Hello skaller, Sunday, August 13, 2006, 4:34:14 AM, you wrote: > I know very little about Haskell, let alone GHC internals me too. so it's better to wait for comments about your thoughts from GHC team than from me. but at least i can said that > But the state of the art is then two stages behin

Re: OpenSSL License (was Replacement for GMP: Update)

John, Have you carefully investigated the OpenSSL license? We in Debian have had repeated problems since the OpenSSL license is, as written, incompatible with the GPL (even linking to OpenSSL is incompatible with the GPL). I would hate to have a situation where all GHC-compiled programs c

Re: Re[6]: Replacement for GMP: Update

On Sat, 2006-08-12 at 16:58 +0400, Bulat Ziganshin wrote: > Hello skaller, hi .. :) > > The problem will occur if the 'stack' is aged: in that case > > the sweep can miss the mutation and reap a live object. > > well, i don't know how updatable vars in stack interoperate with GC. > let's someone

Re[6]: Replacement for GMP: Update

Hello skaller, Saturday, August 12, 2006, 12:34:54 PM, you wrote: >> > My point here is that actually this is a disastrous optimisation >> > in a multi-processing environment, because in general, the >> > assignment of a pointer means the store isn't write once. >> >> :) all the variables rewr

Re: Replacement for GMP: Update

Florian: On most systems, readline is GPLed. There is a non-copyleft reimplementation somewhere, but I don't think it's widely used. The non-copyleft implementation is an upgrade from BSD's lineedit, called libedit . Apple's OS X includes it as a version

Re: Replacement for GMP: Update

On 2006-08-10, Peter Tanski <[EMAIL PROTECTED]> wrote: > 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: Have you carefully investigated the OpenSSL license? We in Debian have had repeated

Re: Re[4]: Replacement for GMP: Update

On Sat, 2006-08-12 at 10:58 +0400, Bulat Ziganshin wrote: > Hello skaller, > > Saturday, August 12, 2006, 7:06:15 AM, you wrote: > > > My point here is that actually this is a disastrous optimisation > > in a multi-processing environment, because in general, the > > assignment of a pointer means

Re[4]: Replacement for GMP: Update

Hello skaller, Saturday, August 12, 2006, 7:06:15 AM, you wrote: > My point here is that actually this is a disastrous optimisation > in a multi-processing environment, because in general, the > assignment of a pointer means the store isn't write once. :) all the variables rewritten is local t

Re: Replacement for GMP: Update

* Peter Tanski: > Quite right; my mistake: under the OpenSSL license a developer cannot > mention features of the software in advertising materials, so the > license grant of the GPL-OpenSSL program to the developer is void. > The reason I mentioned "users" only was that in the particular > proble

Re: Re[2]: Replacement for GMP: Update

On Fri, 2006-08-11 at 18:56 -0400, Peter Tanski wrote: > John, > > > After all on the average call where an object of that > > size is free already it is a single array lookup, we have: > > > > (a) fetch pointer (one read) > > (b) fetch next (one read) > > (c) store next as current (one write) >

Re: Replacement for GMP: Update

On Fri, 2006-08-11 at 21:08 +0100, Brian Hulley wrote: > Florian Weimer wrote: > > This is the offending part: > > > > * 3. All advertising materials mentioning features or use of this > > software > > *must display the following acknowledgement: > > *"This product includes cryptographic so

Re: Re[2]: Replacement for GMP: Update

John, After all on the average call where an object of that size is free already it is a single array lookup, we have: (a) fetch pointer (one read) (b) fetch next (one read) (c) store next as current (one write) This is true for memory access; it is not true for memory allocation. I do not

Re: Replacement for GMP: Update

Brian, Therefore I'd recommend that licenses for code used by GHC runtime should be either BSD or public domain. I agree. I was working on a rewrite of OpenSSL's BN from scratch-- maybe a rewrite of GMP would be better--but that is a huge undertaking for no other reason than

Re: Re[2]: Replacement for GMP: Update

h the rapid changes going on but until Simon Marlow posted the FFI syntax patch on cvs-ghc-request I had not read into it that much. It won't be too much trouble for me to do a bare FFI binding to GMP or another library (people seem to be having problems with OpenSSL's license) but w

  1   2   >