Re[4]: ANNOUNCE: GHC version 6.6.1
Hello Duncan, Sunday, April 29, 2007, 8:00:56 PM, you wrote: java/c# libs can't be used with current ghc, so 99% of Making it possible to use Haskell in mixed language projects with C++ and Java how ghc/mingw can be used with java? :) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re[4]: ANNOUNCE: GHC version 6.6.1
On Mon, 2007-04-30 at 10:05 +0400, Bulat Ziganshin wrote: Hello Duncan, Sunday, April 29, 2007, 8:00:56 PM, you wrote: java/c# libs can't be used with current ghc, so 99% of Making it possible to use Haskell in mixed language projects with C++ and Java how ghc/mingw can be used with java? :) I expect it's quite tricky! :-) I'm not claiming it works or is easy, I was just commenting that making it possible or easier to use Haskell in larger mixed language projects is a good goal. Of course I've never tried it but I'd probably start by looking at the haskell-jvm-bridge (http://sourceforge.net/projects/jvm-bridge/) and seeing if that can be made to work with Sun Java on windows or perhaps GNU gcj works on mingw these days. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re[6]: ANNOUNCE: GHC version 6.6.1
Hello Duncan, Monday, April 30, 2007, 10:11:09 AM, you wrote: how ghc/mingw can be used with java? :) I expect it's quite tricky! :-) I'm not claiming it works or is easy, I was just commenting that making so, you agree that 99% of foreign-language libs that can be used with ghc/mingw are written either in C or C++? -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re[6]: ANNOUNCE: GHC version 6.6.1
On Mon, 2007-04-30 at 11:02 +0400, Bulat Ziganshin wrote: Hello Duncan, Monday, April 30, 2007, 10:11:09 AM, you wrote: how ghc/mingw can be used with java? :) I expect it's quite tricky! :-) I'm not claiming it works or is easy, I was just commenting that making so, you agree that 99% of foreign-language libs that can be used with ghc/mingw are written either in C or C++? But if you're using this to argue that we should ship a C++ compiler then it's just a circular argument. If we only ship a C compiler then 99% of foreign language libs that are easily usable with ghc/mingw are written in C. If we ship perl and python and whatever compilers then the foreign language libs that are easily usable would be in a wider range of languages. Remember that you don't even need a C compiler for ghc to be able to use C apis (or C apis exported from C++ libs). It's just not modular to bundle them all together. You can quite easily install a C, C++, Java or Pascal compiler and use that to build libs that export C apis and then use ghc (or any other Haskell impl) to use those apis. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Re[2]: ANNOUNCE: GHC version 6.6.1
| Making it possible to use Haskell in mixed language projects with C++ | and Java is obviously a good thing, but it's not really a scalable | solution to distribute them all together. We should look at how to | improve cabal+ghc to make it easier to use them as a component of a | larger system. One example of this would be not requiring that ghc is | used to do a final link, we should be able to make static libs and then | link them using ordinary gcc. Indeed. I don't think there is any reason in principle why one should not use GHC and C++ together, and there is certainly some customer demand for this to be smooth and easy. But it's not at the moment, and we lack a motivated colleague to help make it happen It needs someone who is familiar with C++ and its various strange naming, calling, and linking conventions; and who is willing to learn a bit about GHC's strange naming, calling, and linking conventions (with help from us). We are ready to spend time explaining the GHC end. But we really need someone to figure out what happens in the GHC/C++ link step, and make it all work smoothly. Please do volunteer! Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Release plans
David Waern wrote: Here's a quick summary of the major developments that we already have in the 6.8 codebase: - Associated data types, and the new FC intermediate language - GHCi debugger (although there's an overhaul of the breakpoint support almost ready to go in) - Coverage (HPC) - GADTs + typeclasses - more packages moved from core to extralibs - GHC API changes, compile to object code inside GHCi - performance improvements: simplifier rewrite, and SpecConstr improvements - standalone deriving declarations - left-to-right impredicative instantiation: runST $ foo It also has the Haddock comment support, so we could do a release of Haddock-GHC. Ah yes, I thought we were forgetting something. Thanks David. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghci module load path
Folks, Suppose I have a cabalized project where the source is under src/ and the generated code goes into dist/build/test/test-tmp/. How can I load modules from the generated code directory when I'm in the parent of both src and dist? If I do :set -idist/build/test/test-tmp then ghci tries to look for source files there but they are in src. If I :set -isrc then ghci doesn't look for the already compiled code and just interprets the source files. I'm looking to load the pre-compiled files. Thanks, Joel -- http://wagerlabs.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci module load path
Joel Reymont wrote: Folks, Suppose I have a cabalized project where the source is under src/ and the generated code goes into dist/build/test/test-tmp/. How can I load modules from the generated code directory when I'm in the parent of both src and dist? If I do :set -idist/build/test/test-tmp then ghci tries to look for source files there but they are in src. If I :set -isrc then ghci doesn't look for the already compiled code and just interprets the source files. I'm looking to load the pre-compiled files. Take a look at how Cabal invokes GHC, by running 'setup build -v'. The main options you need are -odir and -hidir, which tell GHC to look for object files and interface files somewhere other than next to the source files. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci module load path
On Apr 30, 2007, at 10:38 AM, Simon Marlow wrote: The main options you need are -odir and -hidir, which tell GHC to look for object files and interface files somewhere other than next to the source files. Should I assume that the same work for ghci? -- http://wagerlabs.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci module load path
Joel Reymont wrote: On Apr 30, 2007, at 10:38 AM, Simon Marlow wrote: The main options you need are -odir and -hidir, which tell GHC to look for object files and interface files somewhere other than next to the source files. Should I assume that the same work for ghci? Yes. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC on ia64
Hi again. Ok, we migrated our modifications to 6.6.1, compiled it on the ia64 architecture and it worked :). Ian, thank you very much for your help. Currently we're experiencing another problem: we are not able to use -Nx option even though we compile our program with -threaded option. Find the log at the end of this message (notice that -N doesn't appear as one RTS available option). Thank you very much in advance for the replies. Regards. Cristian Perfumo ../../ghc-6.6.1/compiler/ghc-inplace ./Main.hs -threaded --make [1 of 1] Compiling Main ( ./Main.hs, ./Main.o ) Linking ./Main ... ./Main 100 16 1 +RTS -N5 unknown RTS option: -N5 Usage: prog args [+RTS rtsopts | -RTS args] ... --RTS args +RTSIndicates run time system options follow -RTSIndicates program arguments follow --RTSIndicates that ALL subsequent arguments will be given to the program (including any of these RTS flags) The following run time system options are available: -? Prints this message and exits; the program is not executed -Ksize Sets the maximum stack size (default 8M) Egs: -K32k -K512k -ksize Sets the initial thread stack size (default 1k) Egs: -k4k -k2m -Asize Sets the minimum allocation area size (default 256k) Egs: -A1m -A10k -Msize Sets the maximum heap size (default unlimited) Egs: -M256k -M1G -Hsize Sets the minimum heap size (default 0M) Egs: -H24m -H1G -mnMinimum % of heap which must be available (default 3%) -GnNumber of generations (default: 2) -TnNumber of steps in younger generations (default: 2) -cnAuto-enable compaction of the oldest generation when live data is at least n% of the maximum heap size set with -M (default: 30%) -c Enable compaction for all major collections -Isec Perform full GC after sec idle time (default: 0.3, 0 == off) -tfile One-line GC statistics (default file: program.stat) -sfile Summary GC statistics (with -Sstderr going to stderr) -Sfile Detailed GC statistics -Z Don't squeeze out update frames on stack overflow -B Sound the bell at the start of each garbage collection -Csecs Context-switch interval in seconds. 0 or no argument means switch as often as possible. Default: 0.02 sec; resolution is set by -V below. -Vsecs Master tick interval in seconds. This sets the resolution for -C and the profile timer -i. Default: 0.02 sec. -vs Trace scheduler events (see also -Ds with -debug) -vt Time-stamp trace messages --install-signal-handlers=yes|no Install signal handlers (default: yes) -esize Size of spark pools (default 100) -en Maximum number of outstanding local sparks (default: 4096) RTS options may also be specified using the GHCRTS environment variable. Other RTS options may be available for programs compiled a different way. The GHC User's Guide has full details. On 4/29/07, Ian Lynagh [EMAIL PROTECTED] wrote: Hi Cristian, On Wed, Apr 25, 2007 at 07:00:51PM +0200, Cristian Perfumo wrote: We've been trying to compile GHC 6.6 on ia64, and although we have applied the patch on http://hackage.haskell.org/trac/ghc/ticket/1150 , we still get some mangler errors with nop 0s. As well as the patch attached to that bug report, there were a couple more patches for IA64 that went in recently. All the patches are in 6.6.1, so you might have more luck with that. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
