Re: FFI Bindings to Libraries using GMP

Hello Benedikt, I apologise for the late reply. I am travelling tomorrow but I will try to get something an alpha implementation out by this Wednesday. For now here are some preliminary answers: On Sep 28, 2007, at 7:41 AM, Benedikt Huber wrote: Am 18.09.2007 um 05:49 schrieb Peter

Re: FFI Bindings to Libraries using GMP

The combination keeps meaning that at GHC HQ we work on things that affect more people. I doubt we can spare effort to design and implement a fix in the near future -- we keep hoping someone else step up and tackle it! Peter Tanski did exactly that (he's the author of the ReplacingGMPNo

Re: problem compiling an older Haskell program with GHC 6.6.1

On Fri, 6 Jul 2007 09:59:41 -0400 Scott Stoller wrote: I am trying to compile paradox 1.0, an older (GHC 5) Haskell program, with GHC 6.6.1 (the Solaris 10 / x86 binary distribution). Set.hs:26:7: Could not find module `Data.FiniteMap': locations searched: Data/FiniteMap.hs

Re: 64-bit windows version?

On Jun 26, 2007, at 4:59 AM, Simon Marlow wrote: Peter Tanski wrote: I keep on referring to this as temporary because there are two different builds here: (1) the build using the old mingw-GHC, without option support for CL; and, (2) the build using the new Windows-native GHC. Yes. And

Build Systems (was: Re: 64-bit windows version?)

Gour wrote: Have you seen Aap (http://www.a-a-p.org/) ? I have A-A-P (or Aap) but I only did the basic hello-world build and read the manual. It has in fact been updated as late as Febuary 2007. The Make-like syntax is elegant. Maybe someone else could look at this and see if they want

Re: 64-bit windows version?

On Jun 25, 2007, at 3:34 PM, skaller wrote: On Mon, 2007-06-25 at 13:35 -0400, Peter Tanski wrote: Maybe some gcc mimicing cl wrapper tailored specifically for GHC building system could help? One more layer of indirection, but could leave ghc driver relatively intact. That's a good

Re: 64-bit windows version?

On Jun 25, 2007, at 12:55 PM, kyra wrote: Certainly doable but it does present a conundrum: for the old GHC (without builtin cl-support) the order for compilation seems to be: object files> while for cl running link.exe or link.exe, it is better to put all the files at the end of the comm

Re: 64-bit windows version?

On Jun 25, 2007, at 12:06 PM, skaller wrote: On Mon, 2007-06-25 at 11:43 -0400, Peter Tanski wrote: It would be much better to have a single build system. I would gladly replace the whole thing ... I am thinking of starting a new project (possibly as sourceforge) to implement a new build

Re: 64-bit windows version?

On Jun 25, 2007, at 5:19 AM, Simon Marlow wrote: Yes it is easy but now all Makefiles must be changed to use $ (osuf), such as this line in rts/Makefile: 378: %.$(way_)o : %.cmm $(H_FILES), for what will be a (hopefully) temporary Windows build. I bet there are only a few makefiles that expli

Re: 64-bit windows version?

On Jun 22, 2007, at 11:42 AM, Simon Marlow wrote: Peter Tanski wrote: A bit invasive (it involves modifying the make rules so they take an object-suffix variable). Instead of the current suffix.mk: $(odir_)%.$(way_)o : %.hc it should be: $(odir_)%.$(way_)$(obj_sfx) : %.hc or some such

Re: 64-bit windows version?

On Jun 22, 2007, at 7:03 AM, Simon Marlow wrote: In fact, to build a source distribution on Windows, there are only 3 dependencies: GHC, Mingw and (either MSYS or Cygwin). To build from darcs, you also need: darcs, Happy, and Alex. To build docs, you also need Haddock. To run the testsuit

Re: 64-bit windows version?

On Jun 22, 2007, at 9:45 AM, Simon Marlow wrote: skaller wrote: On Fri, 2007-06-22 at 12:03 +0100, Simon Marlow wrote: Ok, you clearly have looked at a lot more build systems than I have. So you think there's a shift from autoconf-style "figure out the configuration by running tests" to h

Re: 64-bit windows version? (Haskell is a scripting language too!)

Brian Hulley wrote: To port GHC to a completely new platform, you'd of course need a Haskell compiler or interpreter already. However to bootstrap the process only a slow interpreter would be needed so as long as a portable pre-built bytecode version was available for download the only thing

Re: 64-bit windows version?

On Jun 21, 2007, at 11:48 AM, Simon Marlow wrote: Peter Tanski wrote: If I could change one feature of the current system ... for known systems use autoconf only to determine what the $(build) system is and to ensure those programs are available, then jump into make which would call pre

Re: 64-bit windows version?

On Jun 21, 2007, at 4:16 AM, Simon Marlow wrote: Peter Tanski wrote: skaller wrote: Why do you need mingw? What's wrong with MSVC++? The largest problem is the build system: GHC uses autoconf with custom makefiles. So autoconf won't work with MSVC++, that is indeed a problem.

Re: 64-bit windows version?

Simon Marlow wrote: GHC *developers* wouldn't be any better off either. You'd still need either Cygwin or MSYS for the build environment. There's no way I'm using MS build tools, ugh. The way I have it set up (so far) is as simple as running configure and make--all from the command line

Re: 64-bit windows version?

skaller wrote: On Tue, 2007-06-19 at 12:23 +0100, Simon Marlow wrote: Bulat Ziganshin wrote: Hello glasgow-haskell-users, are you plan to implement 64-bit windows GHC version? The main thing standing in the way of this is the lack of a 64- bit port of mingw. Why do you need mingw?

Re: Locating shared libraries

On Jun 19, 2007, at 4:05 AM, Simon Marlow wrote: Peter Tanski wrote: Now each GHC-Haskell-based program installer would search /usr/ local/lib for, say, libHSrts_dyn-6.6.1.dylib and install that version if necessary. What happens on uninstall?... That is why I think your idea was good: put

Re: Locating shared libraries

On Jun 18, 2007, at 6:06 PM, Stefan O'Rear wrote: On Mon, Jun 18, 2007 at 11:56:57AM -0400, Peter Tanski wrote: Now each GHC-Haskell-based program installer would search /usr/local/ lib for, say, libHSrts_dyn-6.6.1.dylib and install that version if necessary. What happens on unin

Re: Locating shared libraries

skaller wrote: On Fri, 2007-06-15 at 19:40 -0500, Spencer Janssen wrote: On Sat, 16 Jun 2007 08:21:50 +1000 skaller <[EMAIL PROTECTED]> wrote: One way to measure this is: if you removed GHC and applications, and there are (necessarily) no users of the remaining library package .. the library p

Re: Locating shared libraries

Spencer Janssen wrote: On Sat, 16 Jun 2007 08:21:50 +1000 skaller <[EMAIL PROTECTED]> wrote: One way to measure this is: if you removed GHC and applications, and there are (necessarily) no users of the remaining library package .. the library package shouldn't be in the global public place (/us

local ByteArrays: performGC do any good?

That would be a sketchy move--even for testing-- because Integer ByteArrays are local (not pinned). Do you think doing a performGC just before grabbing the Addr# would help? There doesn't seem to be another primitive for marshalling a pointer from a ByteArray. Cheers, Pe

Re: GHC on Cray XMT?

form (http://hackage.haskell.org/trac/ghc/wiki/Building/ Porting#PortingGHCtoanewplatform) and see what problems you run into. Cheers, Peter Tanski ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: status of GreenCard support

the old _casm_ ffi bindings back into the source code practically from scratch (perhaps grabbing an archive of 6.1 would give you a better start). Cheers, Peter Tanski ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http

Re: Replacement for GMP: Update

On Tue, 23 Jan 2007, John Meacham wrote: 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/subtracti

Re: HEAD ghci crash on ppc OS X

= misalignment; - +# else + oc->image = stgMallocBytes(oc->fileSize, "loadObj(image)"); +# endif + but did not add your change back in. Cheers, Peter Tanski ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

rfc: colorized Haskell on GHC-Trac

to do this is: demarcate a code block: {{{ #!html topLevelFunction ... }}} Thanks, Peter Tanski ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Problems building GHC

other library. (I am working on that but for lack of time I am running a bit late.) Cheers, Peter Tanski ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

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 users list

Re: Replacement for GMP: Update

On Dec 29, 2006, at 8:32 AM, Thorkil Naur wrote: On Friday 01 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

Re: bignums, gmp, bytestring, .. ?

On Nov 22, 2006, at 8:39 PM, Donald Bruce Stewart wrote: p.tanski: to my knowledge, that would be the first Haskell implementation for PalmOS... Pretty sure Tony Sloane et al at Macquarie have had nhc98 running on the palm for quite a while. They've recently moved to YHC though, iirc. Don

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, .. ?

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 to non-unix

Re: bignums, gmp, bytestring, .. ?

Hi Neil, On Nov 17, 2006, at 7:44 PM, Neil Mitchell wrote: - do all those who want to distribute binaries, but not dynamically linked, need bignums? - it would be nice to know just how far off a good haskell version would be performance-wise.. - what would be a killer for numerical progr

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 that a has

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 GMP for spe

Re: Change Data.Bits.rotate to rotate Integer (unbounded) types

On Sep 19, 2006, at 3:28 PM, Neil Mitchell wrote: Hi, Welcome back! Since Data.Bits is not defined in the Haskell 1998 standard, are we free to change the implementation of Data.Bits? No! If you do things like this, randomly changing the semantics of functions, people will come round to you

Re: Change Data.Bits.rotate to rotate Integer (unbounded) types

On Sep 19, 2006, at 3:38 PM, Lemmih wrote: On 9/19/06, Peter Tanski <[EMAIL PROTECTED]> wrote: I don't have a particular implementation in mind but as a general idea it would make the treatment of Integers the same as the treatment of the standard-size bounded ints. A possible imp

Re: Change Data.Bits.rotate to rotate Integer (unbounded) types

ation I can think of is to make it behave like shift. On Sep 18, 2006, at 23:46 , Peter Tanski wrote: Welcome back! Since Data.Bits is not defined in the Haskell 1998 standard, are we free to change the implementation of Data.Bits? if we are free to change the implementation of Data.Bits,

Change Data.Bits.rotate to rotate Integer (unbounded) types

Welcome back! Since Data.Bits is not defined in the Haskell 1998 standard, are we free to change the implementation of Data.Bits? if we are free to change the implementation of Data.Bits, would it be all right to change the operation of rotate, rotateL and rotateR over unbounded types (to

Help with unregisterised build

Hello Jeremy,I don't know if anyone has gotten back to you on this yet.  I have not myself done an unregisterised build of GHC before, but I thought you should at least hear something.  The people who know about this all seem to be at the ICFP programme that has been going on since Thursday; they s

Re: Replacement for GMP: Update

Hello Thorkil, I am very sorry for the late reply. I have been extremely busy and I wanted to give you a coherent answer. 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

Re: Re[4]: Packages in GHC 6.6

Hi Bulat, sorry, but you miscitated me and seems to misinterpret whole idea: Sorry about that. I put the emphasis on your mention of "fundamental," almost to the exclusion of compiler-builds. My point was that there are two design considerations when you are designing a compiler system

Re: Packages in GHC 6.6

Simon, ... At the moment, the only packages you can add in this way are: ALUT, HGL, HUnit, OpenAL, OpenGL, QuickCheck, X11, cgi, fgl, haskell-src, html, mtl, network, parsec, time, xhtml ... instead include smaller and more "fundamental" packages: ByteString, regexps, Collect

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: 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: 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

picky, though: Simon Marlow, Simon Peyton-Jones and the rest of the GHC Team are primarily interested in performance and the integrity of the RTS (no one would be happy if the RTS broke for bad FFI calls). Thanks for the encouragement. Best regard

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

Simon PJ and Bulat, [the] ForeignPtr solution [has] gotten a lot cheaper in GHC 6.6 than it used to be, so it's worth trying. A merit of the approach is that is avoids fiddling with the bignum allocator at all. I actually did not know that until today; I have tried to keep up with the rapid

Re: Replacement for GMP: Update

Florian, 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 software written by * Eric Young ([EMAIL PROTECTED])" *The word 'cryptograph

Re: Replacement for GMP: Update

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

Re: Replacement for GMP: Update

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

Re: Replacement for GMP: Update

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

Re: Replacement for GMP: Update

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

Re: Replacement for GMP: Update

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

Re: Replacement for GMP: Update

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

Re: Replacement for GMP: Update

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

Replacement for GMP: Update

Simon PJ, Simon, Esa and John, Here is an update on what I have been doing so far in making a grand attempt to replace GMP. (1) evaluate replacement libraries LibTomMath: Pros- * has all the operators GMP offered Cons- *

Re: Re[4]: Replacement for GMP

Hi Bulat, the same binary that also wants to use GMP. (Of course, we could *copy* GMP, changing all the function names. That would eliminate the problem!) isn't it rather easy task for some automated tool? i think that even existing tools may be found I know copyrights are weak compared t

Re: Replacement for GMP

Simon, (1) We'd be delighted to use a BSD-licensed alternative to GMP in GHC. It's been a long-standing issue, just never quite important enough to get done. If either or both of you are willing to put in the legwork, and emerge with an implementation that we understand and can maintain, we'd b

Re: Re[2]: Replacement for GMP

Hi Bulat, don't forget about speed/memory efficiency of any programs that use Integer "just for case" but really most of their numbers fit in 32/64 bits. i have one particular program of this type - it builds list of all files on disk and Integers are used to save filesizes. i will be glad if, v

Re: Replacement for GMP

Hey Esa, Another great instructive email! Thanks again! I will keep this response short because I am sure you are busy and you have been more than helpful so far. I also need to get back to working through the code... I hope my answer helps, but if it gets you more confused, maybe it'

Re: Replacement for GMP

Esa, What I have written here might not be the most useful guide to start with, but maybe it is of help for other interested souls. Many thanks for the notes; it would probably be better if more than one programmer worked on it. * The memory handling: The idea on most bignum libs is

Replacement for GMP

Esa, In the July thread, (Repost) Replacement for GMP as Bignum: ARPREC? Haskell?; OS X and OpenSSL, you wrote: In past, I tried to get rid of GMP by replacing it with libtommath http://math.libtomcrypt.com/ But I have given up for now - because of related and unrelated problems. Since I

Re: GHC runtime DLLs

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:// cvs.haskell.org/cgi-bin/c