Hello p,
Sunday, July 30, 2006, 7:21:07 AM, you wrote:
Leroy and even MLton uses GMP. Robert Dockins wrote a type-based
library for arbitrary that can (slowly) handle big numbers (up to
10^15), see http://www.eecs.tufts.edu/~rdocki01/typenats.html I don't
this don't have anything common
Hi
On 7/30/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
(Sorry for the repost: I needed to correct a few typos--thanks
Seth--and clarify a few things.)
GHC Task Ticket # 601 suggests replacing GMP with OpenSSL's Bignum library, BN.
I have two questions concerning this:
(1) Why not use the
[EMAIL PROTECTED] wrote:
GHC Task Ticket # 601 suggests replacing GMP with OpenSSL's Bignum
library, BN. I have two questions concerning this:
From the ticket, this looks very scary:
but its LGPL license is problematic for users of GHC
(it prohibits static linking of
On 7/30/06, Brian Hulley [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
GHC Task Ticket # 601 suggests replacing GMP with OpenSSL's Bignum
library, BN. I have two questions concerning this:
From the ticket, this looks very scary:
but its LGPL license is problematic for users of
On Sun, 2006-07-30 at 11:53 +0100, Brian Hulley wrote:
[EMAIL PROTECTED] wrote:
GHC Task Ticket # 601 suggests replacing GMP with OpenSSL's Bignum
library, BN. I have two questions concerning this:
From the ticket, this looks very scary:
but its LGPL license is problematic for
Esa Ilari Vuokko wrote:
On 7/30/06, Brian Hulley [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
GHC Task Ticket # 601 suggests replacing GMP with OpenSSL's Bignum
library, BN. I have two questions concerning this:
From the ticket, this looks very scary:
but its LGPL license
Duncan Coutts wrote:
On Sun, 2006-07-30 at 11:53 +0100, Brian Hulley wrote:
[EMAIL PROTECTED] wrote:
GHC Task Ticket # 601 suggests replacing GMP with OpenSSL's Bignum
library, BN. I have two questions concerning this:
From the ticket, this looks very scary:
but its LGPL license
Hi Duncan,
On 7/30/06, Duncan Coutts [EMAIL PROTECTED] wrote:
GHC only statically links Haskell code. It dynamically links to GMP and
the system C library and other C libs.
In Windows (mingw) GMP is linked in statically (even this dll-stuff is
bitrotted).
So you're fine.
On unix you can
Hi Brian,
On 7/30/06, Brian Hulley [EMAIL PROTECTED] wrote:
Still, a slight problem is that since there is one object file per source
file, the names of the object files give quite a lot of information away
about the structure of the program especially when they are arranged in a
module
Esa Ilari Vuokko wrote:
Hi Brian,
On 7/30/06, Brian Hulley [EMAIL PROTECTED] wrote:
Still, a slight problem is that since there is one object file per
source file, the names of the object files give quite a lot of
information away about the structure of the program especially when
they are
Brian,
The standard method of skirting the LGPL restriction and saving your
source code is to link dynamically in a separate step and then
distribute your program along with the dynamically linked LGPL'd
library. Compile with ghc -c (or with ghc -c -odir 'separate
directory where you want to
[EMAIL PROTECTED] wrote:
Brian,
The standard method of skirting the LGPL restriction and saving your
source code is to link dynamically in a separate step and then
distribute your program along with the dynamically linked LGPL'd
library. Compile with ghc -c (or with ghc -c -odir 'separate
On Sun, 2006-07-30 at 17:33 +0100, Brian Hulley wrote:
I think the main problem here is that I'm using Windows, so there is no way
to dynamically link with the runtime libraries - the GHC implementations
available for Windows only produce statically linked executables.
Perhaps Windows
Duncan Coutts wrote:
On Sun, 2006-07-30 at 17:33 +0100, Brian Hulley wrote:
I think the main problem here is that I'm using Windows, so there is
no way to dynamically link with the runtime libraries - the GHC
implementations available for Windows only produce statically linked
executables.
On Sun, 2006-07-30 at 19:03 +0100, Duncan Coutts wrote:
On Sun, 2006-07-30 at 17:33 +0100, Brian Hulley wrote:
I think part of the issue is that static linking is very convenient and
dynamic linking in this case would lead to some tricky administrative
problems.
Suppose for a moment that
Brian,
Sorry, I smash out emails without thinking and forgot GHC is
distributed with static archives in Windows. No more. Even if you
build the GHC runtime library from source as DLLs you will run into
another problem, as noted in the DLL-NOTES file (see http://
On Sun, 2006-07-30 at 20:02 +0100, Brian Hulley wrote:
Suppose for a moment that GHC did dynamically link gmp.dll, or indeed
HSbase.dll. Where exactly would these files go?
I'd install them in the same directory as ghc.exe because this directory has
to be on the %PATH% for the command
On Mon, 2006-07-31 at 05:00 +1000, skaller wrote:
On Sun, 2006-07-30 at 19:03 +0100, Duncan Coutts wrote:
On Sun, 2006-07-30 at 17:33 +0100, Brian Hulley wrote:
I think part of the issue is that static linking is very convenient and
dynamic linking in this case would lead to some tricky
Peter Tanski wrote:
[snip]
The advantage to free software is
that, like the Haskell language, you get to use some of the most
advanced programming available. So here I am, trying to figure out
what I can do to help GHC, since right now GHC is the only actively
maintained, current Haskell
Neil Mitchell wrote:
Hi Brian,
So here I am, trying to figure out
what I can do to help GHC, since right now GHC is the only actively
maintained, current Haskell compiler available.
nhc98 and Yhc are both compilers which are actively maintained.
(In any case, nhc98
uses GMP as well, so
Duncan Coutts wrote:
On Sun, 2006-07-30 at 20:02 +0100, Brian Hulley wrote:
[snip]
app. When the app runs, Windows will first look in the app's
directory and therefore find the correct set of DLLs.
Yes, it's fine for distributing applications but not much good for
libraries.
Hi Duncan -
21 matches
Mail list logo
