Re: 7.4.1-cand for docon
Hello Serge, On Fri, Dec 30, 2011 at 07:55:05PM +0400, Serge D. Mechveliani wrote: > ... > Has the status of the module Random changed in ghc-7.4.1 ? Between ghc-7.0.4 and ghc-7.4.1, we find http://www.haskell.org/ghc/docs/7.2.1/html/users_guide/release-7-2-1.html that says: 1.5.12.22. random * GHC no longer includes the random library > ... This seems to answer at least one of your questions. Best regards Thorkil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: build-depends
Hello Serge, On Thu, Dec 22, 2011 at 10:03:45PM +0400, Serge D. Mechveliani wrote: > ... > This leads to > > DExport.hs:28:8: > Could not find module `System.Random' System.Random can be found in http://hackage.haskell.org/package/random. Best regards Thorkil > ... ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Using CPP in Cmm
Hello, On Thu, Jun 09, 2011 at 03:44:43PM +0200, Johan Tibell wrote: > ... > I initially > tried to use the CPP ## string concatenation operator to create unique > names (tedious, but works) but GHC runs CPP in traditional mode so > that doesn't work. One -traditional way that I have used to concatenate pieces of C code is demonstrated by: > $ cat t.c > #define s(z) z > s(a)s(b) > $ gcc t.c -E > # 1 "t.c" > # 1 "" > # 1 "" > # 1 "t.c" > > a b > $ gcc t.c -E -traditional > # 1 "t.c" > # 1 "" > # 1 "" > # 1 "t.c" > > ab > $ > ... Best regards Thorkil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: link problem under macosx
Hello, On Tue, Nov 02, 2010 at 01:03:04PM +0100, Christian Maeder wrote: > ... > Are there better workarounds? I am not sure about that, I assume that you have looked at http://hackage.haskell.org/trac/ghc/ticket/4068? > ... Best regards Thorkil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1
Hello, On Thursday 19 March 2009 18:03, Ian Lynagh wrote: > On Wed, Mar 18, 2009 at 12:35:01PM +0100, Thorkil Naur wrote: > ... > > 1. An important property of such installers is that you are told, right from > > the start, that all the information you are presented with during the > > installation process can be accessed at any time, after completion of the > > installation, and you are told how. In case of GHC, something like a > > reference to a suitable spot, given as part of the output from ghc --help. I > > don't see any trace of such a facility on the introduction screen. (I know > > that other installers don't do this either, which is part of the reason why I > > try to avoid them.) > > I didn't follow that; can you say exactly what text you want where, > please? The point of this item is to avoid the uneasiness that I often feel when running though such a sequence of screens, that some piece of information that I am given is not available anywhere else and that it is forever gone, once the screen that contains it has been replaced by the next in the sequence. Hence also my interest in being able to copy and paste the contents of these screens. A suggested way to reduce this uneasiness would be: 1a. Add this text to the Introduction screen: "The complete text of the installation session will be available after installation at /usr/share/doc/ghc/INSTALL_SESSION_MACOSX.txt [say]. Invoking the command 'ghc --help' in a Terminal window will mention the location of this file." So, all I have to remember now is 'ghc --help'. 1b. And, of course, now we have to produce this file INSTALL_SESSION_MACOSX.txt, somehow, and include it in the installation. I am not sure what this file should be, but let me say first that I am not thinking of an installation log or something like that, I am thinking of something that can be produced statically, as part of producing the installation package. Ideally, if the package is produced by some tool, it would be possible to extract the contents of various screens in text form and use that. Or perhaps there is some script for generating the installation package that could be used directly or with a few edits. In any case, the file should contain, in text form, whatever text is presented to the user during installation. So a list of header, contents, in the order used during installation. 1c. And 'ghc --help' should be extended to mention the INSTALL_SESSION_MACOSX.txt file. Not necessarily a trivial change, I admit, but I would consider it very useful. > ... Best regards Thorkil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Under OS X 10.5.6: GHC 6.10.1 Release Candidate 1
Hello Thomas, On Wednesday 18 March 2009 15:03, Thomas Schilling wrote: > There should be a file called testlog somewhere, either at the > toplevel or within the tests directory. Could you search for > "apirecomp001" and send me the test output from running that test. I > can't reproduce this failure when running it manually even though I'm > on OS X, too. Several of the buildbot slaves fail the apirecomp001(normal) test as well. For eaxmple, here is the output from http://darcs.haskell.org/buildbot/all/builders/tnaur%20x86%20Linux%20head/builds/333/steps/runtestsuite/logs/unexpected for that test: => apirecomp001(normal) cd ./ghc-api/apirecomp001 && $MAKE -s --no-print-directory apirecomp001 apirecomp001.run.stdout 2>apirecomp001.run.stderr Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: make[1]: myghc: Command not found make[1]: *** [apirecomp001] Error 127 *** unexpected failure for apirecomp001(normal) > > On 18 Mar 2009, at 10:51, Gregory Wright wrote: > > > > > I built ghc-6.10.1.20090314 on OS X 10.5.6 (Intel) using ghc 6.8.2 as > > a bootstrap compiler. The build was done using the MacPorts > > infrastructure. > > > > Summary test results: > > > > OVERALL SUMMARY for test run started at Tue Mar 17 15:31:38 EDT 2009 > >2334 total tests, which gave rise to > > 12487 test cases, of which > > 0 caused framework failures > >2460 were skipped > > > >9709 expected passes > > 258 expected failures > > 0 unexpected passes > > 60 unexpected failures > > > > Unexpected failures: > > 2469(ghci) > > apirecomp001(normal) > > > > bits > > (normal > > ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) > > conc049(hpc) > > conc068(normal) > > derefnull(profc,profthreaded) > > divbyzero(profc,profthreaded) > > > > genUpTo > > (normal > > ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) > > length001(optc,hpc,optasm,profc,profasm,threaded2,profthreaded) > > > > num009 > > (normal > > ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) > > > > num012 > > (normal > > ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) > > signals002(ghci) > > signals004(ghci,threaded1,threaded2,profthreaded) > > > > > > I haven't looked at the errors in detail, but generally the release > > candidate > > seems OK. > > > > BTW, a test target will be added to MacPorts's portfile for the > > 6.10.2 release, which will > > let you run the test suite by typing > > > > > sudo port test ghc > > > > and if you then install the tested build, a record of the test will > > be saved in > > $PREFIX/share/ghc-/. > > > > Best Wishes, > > Greg > > > > ___ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users@haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > / Thomas > -- > Push the envelope. Watch it bend. > > > > Best regards Thorkil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1
Hello, On Sunday 15 March 2009 16:51, Ian Lynagh wrote: > > We are pleased to announce the first release candidate for GHC 6.10.2: > ... > Please test as much as possible; bugs are much cheaper if we find them > before the release! > ... I have tried the Intel Mac installer and the source package on both FreeBSD and PPC Mac OS X. Some comments follow, first on GHC-6.10.1.20090314-i386.pkg: 1. An important property of such installers is that you are told, right from the start, that all the information you are presented with during the installation process can be accessed at any time, after completion of the installation, and you are told how. In case of GHC, something like a reference to a suitable spot, given as part of the output from ghc --help. I don't see any trace of such a facility on the introduction screen. (I know that other installers don't do this either, which is part of the reason why I try to avoid them.) 2. The introduction screen says "This package must be installed on the system volume" which seems to imply that there is some kind of choice involved at a later stage. But I don't recall having to perform any choice that related to this. So perhaps this should be "This package will be installed on the system volume" instead. 3. I can copy and paste the text of the introduction screen, excellent. I cannot copy and paste the header. 4. On the License screen, GMP is denoted "GNU MP Bignum Library" in two places. I suggest using "GNU Multiple Precision Arithmetic Library" (from http://gmplib.org/) instead. 5. On the License screen, replace "licence" by "license", twice. 6. The License screen explains "that by default the GMP will be statically linked into any binary produced by GHC. Software with a non-GPL compatible licence [sic] will have to ensure that the conditions of the LGPL are met; for example, by forcing GMP to link dynamically instead." Some details or a reference to an explanation of how to do this would be nice. Also, shouldn't "non-GPL compatible" be plain "non-GPL"? 7. I may very well be wrong, but as far as I have been able to tell, the ghc executable itself that is distributed (/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1.20090314/ghc) contains GMP, statically linked. For example: > thorkil-naurs-intel-mac-mini:~/tn/test/GHC/release/GHC-6.10.2-rc1 thorkilnaur$ DYLD_PRINT_LIBRARIES=YES /usr/bin/ghc --version > dyld: loaded: /bin/sh > dyld: loaded: /usr/lib/libncurses.5.4.dylib > dyld: loaded: /usr/lib/libiconv.2.dylib > dyld: loaded: /usr/lib/libSystem.B.dylib > dyld: loaded: /usr/lib/libgcc_s.1.dylib > dyld: loaded: /usr/lib/system/libmathCommon.A.dylib > dyld: loaded: /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1.20090314/ghc > dyld: loaded: /usr/lib/libedit.2.dylib > dyld: loaded: /usr/lib/libncurses.5.4.dylib > dyld: loaded: /usr/lib/libSystem.B.dylib > dyld: loaded: /usr/lib/libgcc_s.1.dylib > dyld: loaded: /usr/lib/system/libmathCommon.A.dylib > The Glorious Glasgow Haskell Compilation System, version 6.10.1.20090314 > thorkil-naurs-intel-mac-mini:~/tn/test/GHC/release/GHC-6.10.2-rc1 thorkilnaur$ where I fail to observe anything that seems to relate to GMP. This is in contrast to the corresponding information for an earlier GHC installation > thorkil-naurs-intel-mac-mini:~/tn/test/GHC/release/GHC-6.10.2-rc1 thorkilnaur$ DYLD_PRINT_LIBRARIES=YES ghc --version > dyld: loaded: /bin/sh > dyld: loaded: /usr/lib/libncurses.5.4.dylib > dyld: loaded: /usr/lib/libiconv.2.dylib > dyld: loaded: /usr/lib/libSystem.B.dylib > dyld: loaded: /usr/lib/libgcc_s.1.dylib > dyld: loaded: /usr/lib/system/libmathCommon.A.dylib > dyld: loaded: /Users/thorkilnaur/tn/install/ghc-6.8.3/lib/ghc-6.8.3/ghc-6.8.3 > dyld: loaded: /opt/local/lib/libreadline.5.2.dylib > dyld: loaded: /opt/local/lib/libncurses.5.dylib > dyld: loaded: /usr/lib/libSystem.B.dylib > dyld: loaded: /opt/local/lib/libgmp.3.dylib > dyld: loaded: /usr/lib/libgcc_s.1.dylib > dyld: loaded: /usr/lib/system/libmathCommon.A.dylib > The Glorious Glasgow Haskell Compilation System, version 6.8.3 > thorkil-naurs-intel-mac-mini:~/tn/test/GHC/release/GHC-6.10.2-rc1 thorkilnaur$ where one observes the presence of "dyld: loaded: /opt/local/lib/libgmp.3.dylib" that loads the separately installed dynamic GMP library. I am no expert in these matters, but this seems to activate requirement d) 0) under section "4. Combined Works" of the LGPL "GNU LESSER GENERAL PUBLIC LICENSE Version 3, 29 June 2007" (http://www.fsf.org/licensing/licenses/lgpl.html) which talks about providing material and giving instructions about how to re-link with a new version of the library and all that. If this material and the instructions are present in the installation package, I have failed to notice it. Alternatively, if the ghc executable links to GMP dynamically, requirement d) 1) of the LGPL comes into effect and that talks about a "mechanism ...that ... uses at run time
Re: Can't compile GHC 6.8.2
Hello, On Monday 24 November 2008 23:48, Barney Stratford wrote: > > The heading seems to be: Your build is missing it's required GMP (GNU > > Multiple Precision) library > No, I have GMP installed, and it's correctly compiling against it. The > issue isn't that these symbols are missing altogether, but rather that > there's something wrong with them. It looks to me like it's identical to > this bug afflicting 6.9: http://hackage.haskell.org/trac/ghc/ticket/2262 Yes, you are right, I didn't address the real issue. Sorry, I don't really know what to do about this. > > Cheers, > Barney. > I notice, however, that the workaround for the issue that you referrred to (#2262) was to remove a line saying -fvia-C. That would, in most circumstances, be roughly the same as saying -fasm (http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html#options-codegen). I suggest that you look at http://hackage.haskell.org/trac/ghc/wiki/Building and in particular http://hackage.haskell.org/trac/ghc/wiki/Building/Hacking for some inspiration. Best regards Thorkil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Can't compile GHC 6.8.2
Hello, On Monday 24 November 2008 23:15, Barney Stratford wrote: > There's good news and bad news. The good news is that the compilation of > my shiny almost-new GHC is complete. The bad news is, it won't link. > It's grumbling about > > ld: > /System/Fink/src/fink.build/ghc-6.8.2-1/ghc-6.8.2/rts/libHSrts.a(PrimOps.o) > has external relocation entries in non-writable section (__TEXT,__text) > for symbols: > ___gmpn_cmp > ___gmpn_gcd_1 > ___gmpz_fdiv_qr > ___gmpz_init > ___gmpz_tdiv_qr > ___gmpz_com > ___gmpz_xor > ___gmpz_ior > ___gmpz_and > ___gmpz_divexact > ___gmpz_tdiv_r > ___gmpz_tdiv_q > ___gmpz_gcd > ___gmpz_mul > ___gmpz_sub > ___gmpz_add > > Looking through the archives, it seems like this is an old favourite bug > rearing its ugly head again. The suggested remedy of commenting out the > line reading "SRC_HC_OPTS += -fvia-C" in the Makefile won't work, as > that line isn't there anyway. The manpage for ld has an option > "-read_only_relocs warning" that looks like it might suppress this > problem, but I don't fully understand what it's doing. > > What would you suggest? The heading seems to be: Your build is missing it's required GMP (GNU Multiple Precision) library which is used for the Haskell Integer type. Whether this information is enough to get you going again, I cannot tell, as I have no experience with your particular circumstances: There may be additional problems ahead getting this library installed and making sure that it gets referred from all the right places. But that seems to be the answer: Get GMP, install it, and make sure that linking and running Haskell code (not least GHC itself) have access. > > Cheers, > Barney. > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > Best regards Thorkil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - MacOS installer
Hello Greg, On Friday 21 November 2008 15:56, Gregory Wright wrote: > ... > ppc/ > Leopard still > fails, but I now have an account on a machine that I can use to test > and debug. And if you need such an access (now or in the future), please just say the word and you can get access to my PPC Mac OS X 10.5 Leopard machine. > ... Best regards Thorkil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.1 beta
Hello,
On Sunday 28 September 2008 19:27, humasect wrote:
> Ah, indeed it does! Then, more about GHC API:
> "Shell: Shell: missing -B option"
>
> I can't find any information of what this -B is, it is not in GHC sources or
> anything helpful from google.
The -B is used from a ghc shell script to identify where the rest of the GHC
installation resides. An example with a GHC 6.8.2 installed in
$HOME/tn/install/ghc-6.8.2:
> [EMAIL PROTECTED]:~> cat tn/install/ghc-6.8.2/bin/ghc
> #!/bin/sh
> GHCBIN=/home/tn/tn/install/ghc-6.8.2/lib/ghc-6.8.2/ghc-6.8.2
> TOPDIROPT=-B/home/tn/tn/install/ghc-6.8.2/lib/ghc-6.8.2
> exec $GHCBIN $TOPDIROPT ${1+"$@"}
> [EMAIL PROTECTED]:~>
There is likely some designation for this option that I cannot recall. If it
is documented anywhere, I haven't noticed.
> ...
Best regards
Thorkil
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Making GHC work on BSD
Hello, On Monday 08 September 2008 14:22, Simon Peyton-Jones wrote: > Dear BDS hackers > > We'd like GHC to be buildable on BSD, but at the moment it isn't. We support GHC on Linux, Windows, Mac, but we really need help with BSD. I would like to do something about this. I have (a number of) x86s that either have some FreeBSD version installed or could get such an installation without too much trouble. The easiest one has an (admittedly old) 5.4 FreeBSD installed, that machine is running at the moment, it has actually managed to build > [EMAIL PROTECTED] compiler/stage2/ghc-inplace --version > The Glorious Glasgow Haskell Compilation System, version 6.9.20080517 using > [EMAIL PROTECTED] ghc --version > The Glorious Glasgow Haskell Compilation System, version 6.4.1 and > [EMAIL PROTECTED] compiler/stage2/ghc-inplace --interactive > GHCi, version 6.9.20080517: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer ... linking ... done. > Loading package base ... linking ... done. > Prelude> 2+2 > 4 works sometimes, but validate is a catastrophy (this is a dormant project). Another machine has some FreeBSD 6.x (I haven't checked), but I don't think it has any GHC running on it at the moment. A third possibility would be to take the latest (7.0) FreeBSD and install that. So, it would be useful to know, which FreeBSD version would you prefer to use for this? > ... Best regards Thorkil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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 enough to write a compiler like ghc? You probably know about this, but just to make sure: Did you take a look at http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes? > > Cheers Christian > ... Best regards Thorkil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: bindist for Intel MacOS X 10.4 (Tiger) with static libs
Hello, On Thursday 17 January 2008 05:24, Manuel M T Chakravarty wrote: > Thorkil Naur: > > Hello, > > > > On Tuesday 08 January 2008 15:07, Christian Maeder wrote: > >> Hi, > >> > >> I've succeeded in building a binary distribution that uses static > >> libraries for gmp and readline. libreadline.a, libncurses.a and > >> libgmp.a > >> with corresponding header files are included. (For license issues ask > >> someone else.) > > > > On http://gmplib.org/ we find: > > > > "GMP is distributed under the GNU LGPL. This license makes the > > library free to > > use, share, and improve, and allows you to pass on the result. The > > license > > gives freedoms, but also sets firm restrictions on the use with non- > > free > > programs." > > > > I have not attempted to check whether your distribution fulfills the > > requirements of the LGPL. > > It does fullfil them. The source code of all components of the system > is available enabling users to build the same software with a > different version of GMP. That's all that the LGPL requires of > software linked against a LGPL library. > > > > Further, on http://cnswww.cns.cwru.edu/php/chet/readline/rltop.html: > > > > "Readline is free software, distributed under the terms of the GNU > > General > > Public License, version 2. This means that if you want to use > > Readline in a > > program that you release or distribute to anyone, the program must > > be free > > software and have a GPL-compatible license." > > > > For your distribution to adhere to this, it appears to require GHC > > to have a > > GPL-compatible license. Sorry, my use of the term "GPL-compatible" here is wrong. What I should have written was that "it appears to require GHC to be distributed under the GPL". > > I don't believe it does. > > It does. GHC's codebase is a mix of BSD3, LGLP, and GPL. They are > perfectly compatible. See <http://www.fsf.org/licensing/licenses/index_html > >. > > Manuel > Best regards Thorkil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
Hello, On Wednesday 16 January 2008 22:05, Judah Jacobson wrote: > Hi all, > > I have managed to build ghc using the initial release of the editline package: > > Hackage link: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/editline-0.1 > Haddock: http://code.haskell.org/editline/dist/doc/html/editline/ > > As I've mentioned before, there are two independent modules: > - System.Console.Editline is a very basic (and experimental) interface > to the native editline APIs. > - System.Console.Editline.Readline contains the readline APIs provided > by the editline library (mostly a cut/paste of > System.Console.Readline). Excellent! > > Currently I'm using just the latter as a drop-in replacement for > System.Console.Readline in ghci. I have added a --with-editline flag > to ghc's configure script, which has no effect if it's not specified, > and otherwise does the following: > > - Throw an error (at configure time) if editline isn't present (as > $hardtop/libraries/editline) That's the way. > - Use the editline package instead of readline when building ghc stage 2 > - Use CPP to make InteractiveUI.hs (the main ghci loop) import > System.Console.Editline.Readline instead of System.Console.Readline. > > Does that sound like the right way to handle this? If so, I'll send a > darcs patch. An alternative that would make the GHC configure script more symmetric with respect to command line editor would be to have --with-line-editor=editline, --with-line-editor=readline and also, perhaps, --with-line-editor=none (or even --with-line-editor=). All of these with, hopefully, obvious meanings. On top of this, one could have --with-edit-line=automatic with some automatic selection taking place. And the default? I'm sure that my favorite --with-line-editor=none will not be considered practical, so I will leave this most difficult choice to others. > > Also, should editline be made a boot-package or an extra-package (or neither)? > > Thanks, > -Judah > ... Thanks a lot again. Best regards Thorkil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: bindist for Intel MacOS X 10.4 (Tiger) with static libs
Hello, On Tuesday 08 January 2008 15:07, Christian Maeder wrote: > Hi, > > I've succeeded in building a binary distribution that uses static > libraries for gmp and readline. libreadline.a, libncurses.a and libgmp.a > with corresponding header files are included. (For license issues ask > someone else.) On http://gmplib.org/ we find: "GMP is distributed under the GNU LGPL. This license makes the library free to use, share, and improve, and allows you to pass on the result. The license gives freedoms, but also sets firm restrictions on the use with non-free programs." I have not attempted to check whether your distribution fulfills the requirements of the LGPL. Further, on http://cnswww.cns.cwru.edu/php/chet/readline/rltop.html: "Readline is free software, distributed under the terms of the GNU General Public License, version 2. This means that if you want to use Readline in a program that you release or distribute to anyone, the program must be free software and have a GPL-compatible license." For your distribution to adhere to this, it appears to require GHC to have a GPL-compatible license. I don't believe it does. > ... Best regards Thorkil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip
Hello, On Friday 04 January 2008 12:03, Christian Maeder wrote: > ... Thanks a lot for this response. > I'm not happy about this framework hick-hack either. I am glad we agree about that. > I've only pushed > it, because we needed a readline solution on macs. I understand that there are problems in this area, but I am not convinced that they could not be solved without the renamed and/or modified readline library. I am sorry if you have done that already elsewhere, but I don't recall having seen any details about your difficulties. Would you be kind enough to supply some details? Thanks a lot. > The alternative is to use static linking of gmp (as suggested by chak) > _and_ readline (version 5), so that user programs are also statically > linked with these libs. Again, I am not convinced that this is the only alternative. > ... > Regarding this actual GNUreadline-framework.zip replacement, this is > harmless and seems to matter only for those who build ghc with > frameworks (as only the inclusion of header files changed) It is perhaps without any practical consequences, but I have seen many cases where circumstances managed to create the most glorious confusion out of the most innocently looking changes. So I would maintain that replacing something that you have published with something different is not a good idea. > > In any case we should strive to fix the frameworks issues _and_ add > support for static linking of gmp, readline and possibly other libs > (plus license issues). I fully agree with this. Ideally, the plan would be to, first, figure out what the ideal solution looks like. And then work towards that ideal solution. Making sure that what we introduce on the way as short-term hacks are clearly marked as such, to ensure that they don't impress themselves on people's minds as part of the final solution. I have every intention to work out some ideal (or perhaps more modestly: better) solution. But whether it will emerge in time to make any difference, remains to be seen. > > HTH Christian Thanks and best regards Thorkil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Building GHC 6.6.1 on Leopard/PPC
Hello, On Thursday 20 December 2007 20:15, Jerry Charumilind wrote: > ... > Besides getting a working compiler, my other goal is to get contribute > a working build process on Leopard back to MacPorts, since they > continue to have no solution right now (http://trac.macports.org/projects/macports/ticket/13039 > ). You may wish to consult http://hackage.haskell.org/trac/ghc/ticket/1540 and, more generally, the GHC trac tickets with Operating System = Mac OS X. > The bootstrap compiler that they used in Tiger (http://www.haskell.org/ghc/dist/6.4/MacOSX/ghc-6.4-darwin-bootstrap-tiger.tar.bz2 > ) does not seem to work in Leopard. I have been unable to find the > origin of this bootstrap build. However, it has no dependencies on > GMP.framework or GNUreadline.framework, which are nice properties. I tend to agree with this. > ... Best regards Thorkil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Building GHC 6.6.1 on Leopard/PPC
Hello,
First of all: Welcome to the club. I hope you will find it enjoyable. And then
to your questions:
I have never tried to bootstrap GHC from C, so I am not really able to help
with your specific problem. However, if you just want a running GHC, the
binary distributions should provide an easy path.
I have installed several binary GHC packages on various PPC Mac OS X machines
and, generally, they work. You should, however, be aware of several,
relatively recent, problems that have popped up that seem connected with GHC
6.8.1 and Leopard. See for example
http://hackage.haskell.org/trac/ghc/ticket/1958.
For example, I have a GHC 6.6.1 running on both 10.4 (Tiger) and 10.5
(Leopard) that I installed from
http://haskell.org/ghc/dist/6.6.1/ghc-6.6.1-powerpc-apple-darwin.tar.bz2 (see
http://haskell.org/ghc/download_ghc_661.html#macosxppc).
Once you have a running binary GHC, you can start building (newer) GHC's from
source distributions or darcs repositories.
Feel free to write back, if this is not the right answer to your questions.
Best regards
Thorkil
On Wednesday 19 December 2007 23:25, jcharum wrote:
>
> I've been trying to get a working GHC 6.6.1 build on my Leopard box with
> little success. I am trying to follow the "Booting/porting from C (.hc)
> files" instructions here:
>
> http://hackage.haskell.org/trac/ghc/wiki/Building/Porting
>
> When I build the HC file bundle, I get errors about rts/AutoApply_* stuff,
> but I've read that they are not necessary fatal.
>
> When I try to build on the target system after unpacking the HC files
> ('distrib/hc-build --prefix='), I get the following error:
>
>
> == make boot -f Makefile;
> in /Users/jjc/Downloads/ghc-6.6.1/libraries/readline
>
> make[1]: *** No rule to make target `System/Console/Readline_hsc.c', needed
> by `depend'. Stop.
> Failed making boot in readline: 1
> make: *** [boot] Error 1
>
> Any help is much appreciated. Not only would I like to get this building
> for myself, but I would also like to contribute a bootstrap build for other
> Leopard/MacPorts/PPC users. Let me know if I can provide any more
> information to help diagnose the problem.
> --
> View this message in context:
http://www.nabble.com/Building-GHC-6.6.1-on-Leopard-PPC-tp14426649p14426649.html
> Sent from the Haskell - Glasgow-haskell-users mailing list archive at
Nabble.com.
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Is "-O currently also implies -fvia-C." still true?
Hello, The GHC User's Guide, Versio 6.6.1 (http://www.haskell.org/ghc/docs/latest/html/users_guide/options-optimise.html) says: -O currently also implies -fvia-C. I seem to remember some communication a while back that seemed to imply that this is no longer the case. So my question is: Is the quoted statement still true? Thanks and best regards Thorkil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.6.1 Release Candidate
Hello, On Tuesday 10 April 2007 16:41, Ian Lynagh wrote: > > We are pleased to announce the Release Candidate phase for GHC 6.6.1. > ... A few comments to the source bundles http://www.haskell.org/ghc/dist/stable/dist/ghc-6.6.20070410-src.tar.bz2 http://www.haskell.org/ghc/dist/stable/dist/ghc-6.6.20070410-src-extralibs.tar.bz2 1. There are binary (.p_o and .p_hi) files present in libraries/HGL/Graphics/HGL/X11 and below. 2. On my PPC Mac OS X 10.4, configure reports checking for DocBook XSL stylesheet directory... no configure: WARNING: cannot find DocBook XSL stylesheets, you will not be able to build the documentation Some time ago, I installed docbook-xsl from mac/darwinports and this complaint disappeared from the HEAD, but not from the 6.6 branch. The relevant HEAD change is this: diff ghc-6.6-for-buildbot-20070221_1000/ghc/configure.ac ghc-HEAD-for-669-20070324_1621/ghc/configure.ac ... 931c976 < FP_DIR_DOCBOOK_XSL([/usr/share/xml/docbook/stylesheet/nwalsh/current /usr/share/xml/docbook/stylesheet/nwalsh /usr/share/sgml/docbook/docbook-xsl-stylesheets* /usr/share/sgml/docbook/xsl -stylesheets* /opt/kde?/share/apps/ksgmltools2/docbook/xsl /usr/share/docbook-xsl /usr/share/sgml/docbkxsl /usr/local/share/xsl/docbook /sw/share/xml/xsl/docbook-xsl]) --- > FP_DIR_DOCBOOK_XSL([/usr/share/xml/docbook/stylesheet/nwalsh/current /usr/share/xml/docbook/stylesheet/nwalsh /usr/share/sgml/docbook/docbook-xsl-stylesheets* /usr/share/sgml/docbook/xsl -stylesheets* /opt/kde?/share/apps/ksgmltools2/docbook/xsl /usr/share/docbook-xsl /usr/share/sgml/docbkxsl /usr/local/share/xsl/docbook /sw/share/xml/xsl/docbook-xsl /opt/local/share/xsl/d ocbook-xsl]) ... I suppose it would be useful for this change to be merged to 6.6.1. Best regards Thorkil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Failed to load interface for `Prelude'
Hello, I'm afraid that this is outside my direct experience. However, looking at http://lists.apple.com/archives/xcode-users/2006/Oct/msg00578.html that google was kind enough to find for me, some assembler code generation error seems indicated. I can see that you use -O2, but not whether -fasm or -fvia-C (if any) is used. As I recall, the default selection between -fasm and -fvia-C at some point depended on the -O level, but also has changed recently. I would therefore suggest that you experiment with -O2 versus -O0 and -fasm versus -fvia-C to see if some combination will not carry you through. Also: 1. It would probably be useful to give us the exact version of ghc that you are using and also the version you are building. (Sorry if you reported it and I missed it, but I cannot find it right now.) 2. The report that you give contains what seems to be fragments of command lines. It would be useful to have the complete command lines. 3. In #1195, igloo reports that he has included some code to provide additional information in case of ignored errors (which seems involved here). Some additional context that surrounds the first error report would therefore also be useful, I guess. Best regards Thorkil On Thursday 05 April 2007 21:46, Joel Reymont wrote: > I think this is the reason. What's my next step? > > This is Mac OSX 10.4.9 Intel. > > == make all -r -f Makefile; in /Users/joelr/work/haskell/ghc/ > libraries/ > base > ../../compiler/ghc-inplace -H32m -O2 -fglasgow-exts -cpp - > Iinclude -"#include" HsBase.h -funbox-strict-fields -package-name > base-2.0 -fgenerics -split-objs-c GHC/Err.lhs-boot -o GHC/Err.o- > boot -ohi GHC/Err.hi-boot../../compiler/ghc-inplace -H32m -O2 - > fglasgow-exts -cpp -Iinclude -"#include" HsBase.h -funbox-strict- > fields -package-name base-2.0 -fgenerics -split-objs-c GHC/ > PrimopWrappers.hs -o GHC/PrimopWrappers.o -ohi GHC/ > PrimopWrappers.higcc -O-c System/CPUTime_hsc.c -o System/ > CPUTime_hsc.ogcc -O-c System/Time_hsc.c -o System/Time_hsc.o../../ > compiler/ghc-inplace -H32m -O2 -fglasgow-exts -cpp -Iinclude > -"#include" HsBase.h -funbox-strict-fields -package-name base-2.0 - > fgenerics -split-objs-c GHC/Base.lhs -o GHC/Base.o -ohi GHC/ > Base.hi/tmp/ghc4826_0/ghc4826_0.split__178.s:unknown:missing indirect > symbols for section (__TEXT,__symbol_stub)make[2]: *** [GHC/ > PrimopWrappers.o] Error 1make[2]: *** > > > -- > http://wagerlabs.com/ > > > > > > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Failed to load interface for `Prelude'
Hello, A long shot, but perhaps worth looking into: The reaction that you report here seems similar to the one reported in trac #1195 Build error on MacOSX (Intel) 10.4.8 for HEAD from 2007-03-05 when compiling with ghc-6.6: http://hackage.haskell.org/trac/ghc/ticket/1195 That ticket reports two cases where some error was apparently ignored, leading to a sequence of error reports like the one you quote. But the first error, which is probably the interesting one, is buried somewhere earlier in the output and needs to be found "manually", somehow. If you find your problem related to #1195, please attach any additional details that may be relevant to that ticket. Best regards Thorkil On Thursday 05 April 2007 15:26, Joel Reymont wrote: > Pepe already told me that I need SplitObj=NO on Mac OSX. > > Can someone tell me why? > > Is the error below due to split objs? > > Thanks, Joel > > -- > ../compiler/stage1/ghc-inplace -H32m -O2 -istage2/utils -istage2/ > basicTypes -istage2/types -istage2/hsSyn -istage2/prelude - > istage2/rename -istage2/typecheck -istage2/deSugar -istage2/ > coreSyn -istage2/specialise -istage2/simplCore -istage2/stranal - > istage2/stgSyn -istage2/simplStg -istage2/codeGen -istage2/main - > istage2/profiling -istage2/parser -istage2/cprAnalysis -istage2/ > ndpFlatten -istage2/iface -istage2/cmm -istage2/nativeGen - > istage2/ghci -Istage2 -DGHCI -package template-haskell -DDEBUGGER - > DGHCI_TABLES_NEXT_TO_CODE -threaded -package readline -DUSE_READLINE - > cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package > unix -package Cabal -package regex-compat -ignore-package lang - > recomp -Rghc-timing -H16M '-#include "cutils.h"' -package-name > ghc-6.7.20070404 -fgenerics-c basicTypes/OccName.lhs-boot -o > stage2/basicTypes/OccName.o-boot -ohi stage2/basicTypes/OccName.hi-boot > ../compiler/stage1/ghc-inplace -H32m -O2 -istage2/utils -istage2/ > basicTypes -istage2/types -istage2/hsSyn -istage2/prelude - > istage2/rename -istage2/typecheck -istage2/deSugar -istage2/ > coreSyn -istage2/specialise -istage2/simplCore -istage2/stranal - > istage2/stgSyn -istage2/simplStg -istage2/codeGen -istage2/main - > istage2/profiling -istage2/parser -istage2/cprAnalysis -istage2/ > ndpFlatten -istage2/iface -istage2/cmm -istage2/nativeGen - > istage2/ghci -Istage2 -DGHCI -package template-haskell -DDEBUGGER - > DGHCI_TABLES_NEXT_TO_CODE -threaded -package readline -DUSE_READLINE - > cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package > unix -package Cabal -package regex-compat -ignore-package lang - > recomp -Rghc-timing -H16M '-#include "cutils.h"' -package-name > ghc-6.7.20070404 -fgenerics -O -c utils/Encoding.hs -o stage2/ > utils/Encoding.o -ohi stage2/utils/Encoding.hi > > basicTypes/OccName.lhs-boot:1:0: > Failed to load interface for `Prelude': >Use -v to see a list of the files searched for. > < (1 samples), 16M in use, 0.01 INIT (0.00 elapsed), 0.03 MUT (0.10 > elapsed), 0.02 GC (0.02 elapsed) :ghc>> > make[2]: *** [stage2/basicTypes/OccName.o-boot] Error 1 > make[2]: *** Waiting for unfinished jobs > > utils/Encoding.hs:1:0: > Failed to load interface for `Prelude': >Use -v to see a list of the files searched for. > < (1 samples), 16M in use, 0.01 INIT (0.00 elapsed), 0.03 MUT (0.12 > elapsed), 0.02 GC (0.02 elapsed) :ghc>> > make[2]: *** [stage2/utils/Encoding.o] Error 1 > make[1]: *** [stage2] Error 2 > make: *** [bootstrap2] Error 2 > > -- > http://wagerlabs.com/ > > > > > > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Parsing GHC Core
Hello, The GHC repository ghc/utils/ext-core contains a parser and an (incomplete?) interpreter, apparently for some earlier version of GHC core. Best regards Thorkil On Thursday 08 March 2007 15:58, Neil Mitchell wrote: > Hi, > > I would like to parse GHC Core to an abstract syntax tree, as the old > GHC Core library used to allow the user to do. I do not want to depend > on the GHC API (too big), but don't mind depending on a small and > separately available .cabal'd package. I also don't mind copying a few > modules into my program. The types are of no interest to me, if that > makes it any easier > > Does anyone have the code/library to do this sitting around? > > Thanks > > Neil > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc 6.6 for mac os x (intel)
Hello, On Tuesday 06 February 2007 16:15, Ariel Apostoli wrote: > but when I try installing ghc from that page it seems to install fine > but when I invoke /usr/local/bin/ghc i get: > > dyld: Library not loaded: /opt/local/lib/libreadline.5.1.dylib > Referenced from: /usr/local/lib/ghc-6.6/ghc-6.6 > Reason: image not found > Trace/BPT trap > ... On my Mac OS X 10.4, I get the same reaction when the readline that I installed from darwin ports is deactivated. So perhaps readline isn't installed? Or is deactivated? In that case, the suggested cure is sudo port install readline (The readline that comes with Mac OS X 10.4 is no good, as noted by several.) Best regards Thorkil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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 function--imagine the code bloat. > ... Just a quick adjustment: I have suggested writing raw operations in (hopefully) portable C. And although I would consider eliminating some of the levels of calls (from the compiled Haskell code via Num.lhs and the handcoded PrimOps.cmm to the specific C function implementing the desired operation), I agree that inlining the entire function implementing the operation would be excessive. Best regards Thorkil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: HEAD ghci crash on ppc OS X
Hello, I get a similar reaction starting ghci built from a ghc-HEAD pulled 2007-Jan-12 on a PPC Mac OS X 10.4. Best regards Thorkil On Tuesday 16 January 2007 03:03, David Kirkman wrote: > > I just built ghc from HEAD on OS X (ppc), and get the following error > when starting ghci: > > ---start > [15:15:[EMAIL PROTECTED] compiler/stage2/ghc-inplace --interactive > ___ ___ _ >/ _ \ /\ /\/ __(_) > / /_\// /_/ / / | | GHC Interactive, version 6.7, for Haskell 98. > / /_\\/ __ / /___| | http://www.haskell.org/ghc/ > \/\/ /_/\/|_| Type :? for help. > > ghc-6.7(9972,0xa000ed88) malloc: *** error for object 0x3807ff8: > pointer being reallocated was not allocated > ghc-6.7(9972,0xa000ed88) malloc: *** set a breakpoint in szone_error > to debug > malloc: failed on request for 11359964 bytes; message: > ocAllocateJumpIslands > ---end > > despite the suggestion, a breakpoint in szone_error catches nothing. > But a breakpoint in malloc_printf (both szone_error and malloc_printf > in the OS, not ghc) gives the following backtrace for an rts compiled > with the -g flag: > > --start > Breakpoint 1, 0x9012bb94 in malloc_printf () > (gdb) bt > #0 0x9012bb94 in malloc_printf () > #1 0x90018388 in szone_realloc () > #2 0x90018098 in realloc () > #3 0x00e6f5c4 in stgReallocBytes (p=0x901a4df4, n=11359964, > msg=0xfd9704 "ocAllocateJumpIslands") at RtsUtils.c:209 > #4 0x00e97cbc in ocAllocateJumpIslands (oc=0x2b005d0, count=372, > first=14502) at Linker.c:1598 > #5 0x00e98954 in loadObj (path=0x2e63268 "/Network/Sid/Users/david/ > ghc-crap/ghc/libraries/base/HSbase.o") at Linker.c:3743 > #6 0x005b660c in s1wt_info () > #7 0x00e8a220 in schedule (initialCapability=0x901a4df4, > task=0x2e63268) at Schedule.c:608 > #8 0x00c60e18 in main (argc=-1877324300, argv=0x3807ff8) at Main.c:105 > (gdb) > --end > > > The call to failing call to stgReallocBytes occurs at line 1598 of > Linker.c, in the following context: > > --start Linker.c, lines 1597 --> 1602 > oc->image -= misalignment; > oc->image = stgReallocBytes( oc->image, > misalignment + > aligned + sizeof (ppcJumpIsland) * > count, > "ocAllocateJumpIslands" ); > oc->image += misalignment; > --end > > oc->image is allocated at line 1326 of Linker.c (listing below), and > then never modified until misalignment is subtracted from it at line > 1598. Both the comment in the code fragment below, and the actual > code in the fragment above seem to indicate that oc->image should be > offset by misalignment. > > --start Linker.c, lines 1315 --> 1327 > # elif defined(darwin_HOST_OS) > // In a Mach-O .o file, all sections can and will be misaligned > // if the total size of the headers is not a multiple of the > // desired alignment. This is fine for .o files that only serve > // as input for the static linker, but it's not fine for us, > // as SSE (used by gcc for floating point) and Altivec require > // 16-byte alignment. > // We calculate the correct alignment from the header before > // reading the file, and then we misalign oc->image on purpose so > // that the actual sections end up aligned again. > oc->misalignment = machoGetMisalignment(f); > oc->image = stgMallocBytes(oc->fileSize + oc->misalignment, > "loadObj(image)"); > # else > ---end > > The comment above seems to be begging for a > > oc->image += oc->misalignment; > > statement right after the call to stgMallocBytes. But I'm assuming it > must normally be done someplace else -- I just can't figure out where. > Anyway, I've verified that os->image is still pointing to the value > returned from stgMallocBytes when misalignment (non-zero) is > subtracted from it just before the call to stgReallocBytes. So in > my build at least, the execution path is not hitting whatever part > of the code that should be applying the misalignment offset to > oc->image. > > Let me know if there is any more information I can give. > > -david k. > > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Building GHC on Mac OS 10.2.1
Hello, Sometimes, ghc complains about '#' for me when the C preprocessor has not been run and there is an unexpected #include or #define in the way. Also, as I read ifeq "$(ghc_ge_603)" "YES" # These modules are provided in GHC 6.3+ EXCLUDED_SRCS += \ System/Directory/Internals.hs ... endif in compat/Makefile, the particular compilation that you are stuck on here should be excluded if you were using ghc-6.3 or newer. I am using a ghc-6.4.1 and building ghc-6.6 does not involve building compat/System/Directory/Internals.o. Best regards Thorkil On Saturday 30 December 2006 07:56, Kirsten Chevalier wrote: > The latest is that while I was able to successfully install gcc 3.3, > it made no difference at all. I was able to make some progress by > running configure with --disable-threaded-rts. But, now I get: > > > == make boot -r; > in /Users/krc/ghc-head/ghc/compat > > ../utils/mkdependC/mkdependC -f .depend-I. -Iinclude -I../includes > -- -O -I. -Iinclude -D__GHC_PATCHLEVEL__=1 -I../libraries/base/cbits > -I../libraries/base/include--\ > cbits/directory.c cbits/rawSystem.c cbits/unicode.c > /usr/local/bin/ghc -M -optdep-f -optdep.depend -osuf o-H16m -O > -I. -Iinclude -Rghc-timing -I../libraries -fglasgow-exts -no-recomp > Compat/Directory.hs Compat/RawSystem.h\ > s Compat/Unicode.hs Distribution/Compat/FilePath.hs > Distribution/Compat/ReadP.hs Distribution/Compiler.hs > Distribution/GetOpt.hs Distribution/InstalledPackageInfo.hs Distribu\ > tion/License.hs Distribution/Package.hs Distribution/ParseUtils.hs > Distribution/Version.hs Language/Haskell/Extension.hs > System/Directory/Internals.hs > < samples), 15M in use, 0.02 INIT (0.01 elapsed), 0.13 MUT (0.95 > elapsed), 0.03 GC (0.05 elapsed) :ghc>> > make all > /usr/local/bin/ghc -H16m -O -I. -Iinclude -Rghc-timing -I../libraries > -fglasgow-exts -no-recomp-c System/Directory/Internals.hs -o > System/Directory/Internals.o -ohi Sys\ > tem/Directory/Internals.hi > System/Directory/Internals.hs:1: parse error on input `#' > < samples), 16M in use, 0.02 INIT (0.02 elapsed), 0.06 MUT (0.22 > elapsed), 0.04 GC (0.05 elapsed) :ghc>> > make[2]: *** [System/Directory/Internals.o] Error 1 > make[1]: *** [boot] Error 2 > make: *** [stage1] Error 1 > > My /usr/local/bin/ghc is ghc 6.0.1, which... *should* recognize > OPTIONS (or any other pragma), right? Various documentation claims you > should be able to bootstrap with anything newer than 5.0.4. I'm not > *entirely* sure where the existing old version of ghc I have installed > came from. But I think it's a standard build. Can anyone tell what's > up? I've built ghc I-don't-know-how-many-times now and I'm *still* > mystified by this. > > Thanks, > Kirsten > > -- > Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt > "Of the seven deadly sins, lust is definitely the pick of the litter." > -- Tom Robbins > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Replacement for GMP: Update
Hello,
Thanks a lot for your reply. Here are some comments to this. As is customary,
I must apologise for the late reply (the response time for this conversation
seems to increase exponentially with time) which also may very well make some
of the comments totally out-dated.
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 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 4096? In addition, for "Powers", the markings on the
horizontal axis ("256 pow(n,3)", "512 pow(n,4)", "1024 pow(n5)" (missing a
"," here?), ...) on your graph seem to indicate that you are changing two
different variables (the bit size and the exponent) at the same time. I would
suggest that you also quoted the original measurements directly. And perhaps
(especially in case of the "Powers" and "Division") some more details about
what was actually measured.
It is distinctly odd that squaring seems to be more expensive than
multiplication for some bit sizes in 3 of the 4 measured cases. Also, I
wonder what divisions these libraries are capable of carrying out so much
faster than comparable multiplications. For the division measurements, I may
again simply be presuming something about your experiments that simply isn't
true.
> ...
> I keep talking about ARPREC--why? For three reasons:
> (1) I trust its level of precision--this has been tested, see FFTW's
> benchmark page for accuracy: http://www.fftw.org/accuracy/G4-1.06GHz-
> gcc4/
I am not sure I understand here: With respect to Haskell Integers, I would not
say that there is any concept of a "level of precision": If Integer
computations are not accurate, they are wrong.
> (2) if you look at the charts, although ARPREC is bad in division it
> simply blows GMP, OpenSSL and LibTomMath away: at 4096 bits (85
> doubles--each double has conservatively only 48.3 or so bits of
> integer precision), ARPREC can take a full random number to pow(n,7)
> in .98 seconds, compared to 77.61 or so seconds for the leader of the
> Integer-based libraries, GMP. (I ran the tests many times to make
> sure readings weren't flukes.)
Again, some additional details about these measurements would be most welcome.
> (3) of all the FFT-based arbitrary precision libraries available,
> ARPREC is the only BSD-licensed one--Takuya Ooura's library (used in
> MAPM) is only a FFT algorithm and not necessarily either fast or
> accurate. The rest of the FFT libraries available are essentially
> GMP-licensed.
>
> So I am in an unenviable position: I intend to fulfill my promise and
> get a replacement for GHC (and maybe more), but I have to essentially
> build better functionality into the front-runner, ARPREC. At present
> I have been working with vector-based algorithms that would enable me
> to use hardware-tuned code for Single Instruction Multiple Data
> (SIMD) chipsets. Currently I am researching algorithms based on
> operating-system supplied vector libraries. Part of this
> modification involves a fast transformation between a vector of large
> integers and an array of doubles, without loss of precision (although
> vectors of doubles are also working well, they do not have the same
> library support.) I am also working on enhancing ARPREC's division
> algorithm.
>
I looked briefly at ARPREC: It seems that it works with an explicitly set
maximum bound on the number of digits desired. Although it also appears that
it is possible to change this bound as computations proceed, such additional
administration seems difficult to embrace.
> This is the problem I face: GHC unfortunately does not use Integer as
> a mathematical operation but as a primitive type, complete with
> bitwise operations.
I do not understand what problem you are referring to here.
> ...
> On Aug 24, 2006, at 2:39 PM, Thorkil Naur wrote:
>
> > I am truly unable to tell what I would consider the ideal
> > situation. On the
> > one hand, I value greatly the freedom of choosing my circumstances
> > without
> > restraints. And I appreciate the desire of noble people like the GHC
> > developers to be equally free of such restraints. This would point
> > in the
> > direction of basing Integer computations on a fairly generic
> > implem
Re: Building GHC on Mac OS 10.2.1
Hello, Not much help, I'm afraid, but for what it's worth: I have built GHC-6.6 and some HEAD-ish version successfully on a PowerBook G4 with Mac OS X 10.3 (Panther?) and also after upgrading to 10.4 Tiger. I have never tried with 10.2. To assist in your difficult decisions, here are some details about the machinery: Hardware Overview: Machine Name: PowerBook G4 Machine Model:PowerBook3,2 CPU Type: PowerPC G4 (11.3) Number Of CPUs: 1 CPU Speed:400 MHz L2 Cache (per CPU): 1 MB Memory: 384 MB Bus Speed:100 MHz ... Macintosh HD: Capacity: 9.36 GB Available:1.6 GB ... As you can probably see, this is also quite an old machine, but 10.4 runs comfortably here. Not much disc space left, though: I had to be rather selective when installing. And thanks for the priceless account of your arduous journey. Best regards Thorkil On Friday 29 December 2006 09:37, Kirsten Chevalier wrote: > Hi all, > I'm trying to build the HEAD on a somewhat old PowerBook G4 running > Mac OS 10.2.1. It would seem that I don't have a new enough version of > gcc: > % gcc --version > gcc (GCC) 3.1 20020420 (prerelease) > and I can't seem to build a newer version of gcc (3.3) due to missing > system include files which I assume (though that assumption may be > wrong) are due to running 10.2 instead of 10.4. (For the full tale of > woe, see http://hackage.haskell.org/trac/ghc/wiki/KirstenSandbox). Am > I right in thinking that building GHC on Mac OS 10.2.1 is more or less > impossible, or has anyone managed to do it? I'm pretty close to just > giving up and buying a PC (various things make it difficult for me to > upgrade to Tiger). > > Thanks, > Kirsten > > -- > Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt > "Are you aware that rushing toward a goal is a sublimated death wish? It's no > coincidence we call them 'deadlines'." -- Tom Robbins > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Network.Socket endian problem?
Hello,
It appears that you already got an answer to your question that I hope you can
use. So just for completeness: On my PPC Mac OS X 10.4, both ghc-6.4.1 and
ghc-6.6 produce results similar to the one you report for OSX. And on my Suse
Linux, both ghc-6.4.1 and ghc-6.6 produce results ("wrong") similar to the
one you report for your Linux/i386. So nothing indicates that this is a
problem caused by differences between ghc versions.
Best regards
Thorkil
On Wednesday 13 December 2006 22:04, Rich Neswold wrote:
> ...
> If you run the program on OSX, you can check the bound address while
> it's waiting for a keystroke. Type "netstat -an -f inet | grep 6802"
> to see. I get:
>
> udp4 0 0 127.0.0.1.61704127.0.0.1.6802
>
> which is correct. When I run this program on Linux/i386, I get:
>
> udp0 0 (anonymized):334121.0.0.127:6802
> ESTABLISHED
...
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Network.Socket endian problem?
Hello, I am not an expert on sockets, but I have both a Linux installation and a PPC Mac OS X 10.4 with both ghc-6.4.1 and ghc-6.6. So if you allow me some additional details (such as complete program texts), perhaps I can perform some useful experiments under your conductance. Best regards Thorkil On Wednesday 13 December 2006 19:29, Rich Neswold wrote: > ... > I've written a program that uses UDP as its communication with other > processes. It was built with GHC 6.4.1 on MacOS 10.4 (PowerPC) and > works fine. When I moved the code to a Linux box (i386) and built it > with GHC 6.6, it didn't work. > ... > I don't have access to GHC 6.4.1 on a Linux box to determine whether > this is a regression in 6.6 or simply an overlooked detail. Should I > file a PR? Am I doing something wrong? > ... ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-testsuite-6.6 on Macs
Hello, On Tuesday 14 November 2006 11:34, Simon Marlow wrote: > Thorkil Naur wrote: > > ... I have > > produced an experimental darcs patch that solves some problems, while > > possibly introducing others: > > http://thorkilnaur.dk/~tn/GHC/testsuite/patch/barton_mangler_bug_patch_1.patch . > > Comments to this would be most welcome. > > For those who haven't looked at Thorkil's patch: he proposes adding some code to > the testsuite driver to allow sample output specific to a particular way, and > used this to give sample output for one test (barton-mangler-bug) specific to > the 'opt' way on PPC. > > I would like it to be the case that any differences at all in the output from > one way to another are bugs, including floating point differences. It is a basic question of what varying circumstances we believe should be handled by the test framework. I tend to agree with you and, hence, to reject my own suggestion of extending the testsuite driver to allow different output for different ways.. > On x86_64, > we always generate the same results regardless of -fvia-C or -fasm, for example. > However, it might be that this isn't practical on all platforms. I feel rather sure that it isn't. > The question > is whether we should consider it a *bug* if a test doesn't give consistent > floating-point answers or not. Anyone have any thoughts on this? Let me put it in this way: It is well known that it is almost always bad to test whether two floating point numbers are exactly equal. So in this sense, a test whose outcome depends on testing whether two floating point numbers are exactly equal is a bad test. (Converting floating point numbers to decimal strings and comparing the strings which is what really happens seems to make matters even worse.) To be sure, if we are really testing the floating point operations, we are of course entitled to test equality. But if a test does not deal with floating point operations as such, but merely includes floating point numbers in its output incidentally, the test is probably bad. I cannot see that the Haskell report specifies precise properties of the floating point support, so even implementations that conform to the standard (Haskell 98) can be expected to differ. Hence, any test that involves output of floating point numbers might produce different output for reasons that are entirely unrelated to the test, not a particularly appetizing situation. Whether difference in floating point results between different ways should be considered a bug in GHC, I cannot say. I would tend towards "no", but that is probably because I don't have any particular intense interest in floating point numbers. Getting finally to something more specific, my impression until your question here had been that the barton-mangler-bug test involved floating point numbers incidentally: I imagined that someone (named Barton, perhaps?) ran this program at some point in time, discovered some unfortunate behaviour (such as the program crashing or producing wild results), that this behaviour was traced down to an error in some mangler (the gcc assembler language output "post processor"), and that the test was included and maintained in the testsuite to ensure that this bug was thouroughly stamped out. Based on your question, I realised that my impression could be entirely false and that the central property tested was precisely the floating point differences observed for some ways. I am still in doubt, so if anyone knows the story behind the barton-mangler-bug, I would be delighted to hear it. > > If it's a bug, then we just declare these tests to be expected failures. If > it's not a bug, then we have to allow per-way sample output, as per Thorkil's patch. > As I have already mentioned, I think my patch is a mistake. Depending on what anyone can tell me about the barton-mangler-bug, additional work would seem to go in one of two directions: If the floating point numbers are involved incidentally and the mangler bug still threatens, work should attempt to remove the floating point numbers from the output and produce a test case that exposes the bug more succinctly. I would certainly need some additional help to do this. On the other hand, if the floating point difference between, e.g., opt and normal is the real issue, it would still seem advantageous and quite possible to reduce the size of the test case, to make it easier to figure out the cause of the difference. > Cheers, > Simon > Best regards Thorkil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-testsuite-6.6 on Macs
Hello, This is an attempt to address (a very small part of) this: On my PowerPC Mac OS X 10.3 (Panther, I think, not Tiger as I have written elsewhere), I have built the ghc-6.6 branch (of about 2006-Nov-07 19.00 UTC) using GHC-6.4.1.pkg.zip (The Glorious Glasgow Haskell Compilation System, version 6.4.1) that I got from http://haskell.org/ghc/download_ghc_641.html. I haven't studied the details of Cabal yet, so to work around an X11 problem (http://www.haskell.org/pipermail/cvs-ghc/2006-November/032492.html), I did (1) darcs get of the ghc-6.6 branch; (2) sh darcs-all get (without --extra); (3) got through gmake of everything without failing; (4) sh darcs-all --extra get (to get the extra libraries, some of which (e.g. QuickCheck) are needed for some of the tests); and finally (5) repeated gmake of everything, failing at the X11 build, but getting through the QuickCheck build. Then I "darcs got" the ghc-6.6/testsuite and ran the tests. My hope was that I would be able to reproduce something similar to http://www.haskell.org/pipermail/glasgow-haskell-users/2006-October/011457.html, although under different circumstances. So far, I have only analysed the barton-mangler-bug test in detail. I have produced an experimental darcs patch that solves some problems, while possibly introducing others: http://thorkilnaur.dk/~tn/GHC/testsuite/patch/barton_mangler_bug_patch_1.patch . Comments to this would be most welcome. Best regards Thorkil On Tuesday 07 November 2006 12:39, Christian Maeder wrote: > Simon Marlow schrieb: > >>ghcpkg01(normal) > >>ghcpkg03(normal) > > > > Any idea why these are failing for you? > > Maybe rather than using my installed ghc-pkg (that lists haskell-src) > some inplace ghc-pkg was used: > > ghc-pkg: dependency haskell-src doesn't exist (use --force to override) > make[2]: *** [ghcpkg01] Fehler 1 > > >> I thought the failure signals002(ghci) was related to > >> http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/10947 > >> In fact, I needed to kill the ghc-process to continue the tests. > >> > >> The test files cc004.hs and ffi012.hs failed with several messages of > >> the form: > >> > >> calling convention not supported on this architecture: stdcall > >> When checking declaration: > >> foreign import stdcall safe "wrapper" > >> wrap_f :: F -> IO (FunPtr F) > >> > >> However, they did not make it into the summary > > > > They are probably expected failures for you. > > Yes they are indeed, but should these really be "expected failures"? > > > some of those could be floating-point differences. In any case, it > > would be good to investigate all of them and get any expected failures > > registered properly in the testsuite. Can you (or someone else) take a > > look and find out why each of them is failing? > > Yes, I hope someone else joins in. > Christian > > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC on MacOS
Hello, Let me make that offer, then, that I would like to help investigate and fix GHC on MacOS. The obstacles that I have mentioned earlier are ones that I would eventually have removed in any case, so don't worry, I will not be wasting any time. Regards Thorkil On Monday 02 October 2006 09:31, Simon Peyton-Jones wrote: > Thanks -- in fact we've had a few helpful offers of access (which is v > helpful). We may still yet take you up, but meanwhile don't do too much > work. > > So far, no one has offered to help investigate/fix GHC on MacOS, so > progress may be slow. We'd love to hear from keen MacOS users who are > willing to roll their sleeves up! > > Simon > ... ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC on MacOS
Hello, Nobody seems to have reacted on this. I own a Mac that I don't use particularly much. It seems within reach that I could use it to assist you with both of your questions. As a side effect of having great fun myself, of course. There are several obstacles that need to be removed, however, but I will initiate that and see where it leads. Best regards Thorkil On Thursday 28 September 2006 12:01, Simon Peyton-Jones wrote: > Folks > > Quite a few of you are using GHC on MacOS -- for example, there were > lots of Macs at the GHC Hackathon earlier this month. However, we don't > have access to a machine running MacOS, so it's pretty difficult for us > to deal with bug reports. > > So this message is to ask: > > a) Can anyone give us remote access to a Mac? > > b) Does anyone feel able to help look after GHC's Mac port? > > Simon, Simon, and Ian > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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 uncertain where the matter stands right now. Nevertheless, I wish to thank you for your reply. Clearly, you have done a lot of work, not least to investigate alternatives. You write > I hope I have answered a few of your points; some of them have given > me more work but that is all right, I guess. ... And you most certainly have, much more detailed than I could have hoped for. And hopefully, this additional work that you mention is not something that you considered a waste of time. I am also most happy to read that > Before I actually bind any library with GHC, I will thoroughly test > it as a stand-alone library ... since "correctness" of Integer computation is by far its most important property. (I would say that "performance" comes second, then what could be termed "interoperability" as third.) The support for Integer computation is a messy subject: On the one hand, even children out of the first few years of school are capable of understanding the basic functionality involved. On the other hand, providing efficient support of this functionality, especially if required in a wide selection of circumstances, requires a surprising amount of hard work and insight. I would say, if only really large integers were routinely required in actual, real-world computations, our CPUs would support these computations and there would be no need to consider the question in the, admittedly, fairly limited context of GHC. The situation seems to be that the functionality is perhaps considered obviously available, but the reality is that it can only be attained at significant cost (either real money or honest sweat). I am truly unable to tell what I would consider the ideal situation. On the one hand, I value greatly the freedom of choosing my circumstances without restraints. And I appreciate the desire of noble people like the GHC developers to be equally free of such restraints. This would point in the direction of basing Integer computations on a fairly generic implementation. Which insightful consideration would then force us to admit would probably cost a factor of, say, 2 or more in performance in some cases. On the other hand, the existence of libraries like GMP seems to offer an economic path out of this jungle. However, as the discussion over the past couple of weeks illustrates, the path may be unacceptably thorny. Let me quote some additional statements from this debate: On Thursday 10 August 2006 19:00, Simon Peyton-Jones wrote: ... > OK so you are talking of taking a copy of the BN code, changing the > function names, and statically linking its allocator to GHC's RTS. > > If someone wants to make a program that uses BN for some other purpose, > they get the original BN, whose function names don't clash, and which > uses malloc. > > Sounds ok to me. > > Simon ... Two problems seem to be lurking here: The first is that, although taking a copy of some existing library and massaging it to become working under some presently available circumstances may be fine, what is really needed is something that keeps on working, even under changing and future circumstances. The second is that if I wish to mix Haskell and non-Haskell code that processes the same data, I may find myself in need of a way to convert between whatever is required by this copy of some existing library that has been created and the presently available, but potentially quite different, version of that same library. No offence is meant here: I know that I am simply re-iterating what I have said earlier. However, I believe that this is sufficiently important to risk being ridiculed for pointing out the obvious. Then you ask > ... If you have the time, would you > be able to find any programs you might have that displayed poor > Integer performance or possibly bottlenecks in the current system? Let me say first that I have not experienced any really surprisingly poor performance of the current system. To be sure, I have seen programs similar to my own and not written in Haskell that performed better on comparable tasks. But I have not been able to say specifically that this poorer performance of my program was caused by some inadequacy in the Haskell (with GMP) implementtion. I better be specific here: What I do is integer factorization (splitting integers into their prime factors). And, for example, I have implemented a version of the ECM (Elliptic Curve Method) in Haskell. Having done that (independently and mainly to learn what it was about), I eventually compared it in performance to GMP-ECM which Paul Zimmermann wrote. And I was initially disappointed to find that GMP-ECM was about 7 times faster t
Re: Replacement for GMP: Update
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 be the best, all things considered. 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. I have looked briefly at the OpenSSL Bignum library and in the areas of memory management, but also error handling, it seems clearly intertwined to some extent with OpenSSL in ways which would appear to rule out the direct use of this library for GHC Integers. However, considering the advantages of using an existing library unchanged, we might consider another possibility: Working with the OpenSSL people to modify their library to allow the sort of interfacing that is needed for its direct and efficient use in GHC. While, of course, retaining its value as part of OpenSSL. (And way further back: Have we tried to discuss the LGPL licence of GMP with the authors? I am not really into all these matters, sorry if this doesn't make sense.) Failing that, I would suggest considering the development of the modified library to a form that would allow independent use, apart from its use in GHC. This would add valuable possibilities to your options when choosing the precise mixture of Haskell and, perhaps, raw C code that best balances your performance desires and needs for convenience. I wish you the best of luck with your work. Regards Thorkil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Message "GHC/PrimopWrappers.hs:133:29: Not in scope: `GHC.Prim.quotInteger2Exp#'" building GHC with additional primitive operation
On Wednesday 29 March 2006 01:35, Bulat Ziganshin wrote: > primitives work with just the same internal structures. i thinl that > only real advantage of adding primop instead of adding FFI import is > that PrimOps.cmm contains already implemented wrappers for calling GMP > functions while for FFI you should implement them from scratch Hello, You could very well be right. In fact, the main advantage that I see of solving my problem by adding a new GHC primitive operation is simply that this solution worked for me. I have so far not been able to concoct another solution that uses FFI. Quite possibly for simple lack of insight. But the "adding a new primitive operation"-method is not, of course, without its disadvantages. For example, now I have some additional work whenever I wish to use a new GHC version. And I also have to become fluent in generating GHC for Windows, because I also use the Windows version. All in all, I have not at all given up the idea of solving my problem of interfacing directly with the GMP functions using the FFI. But, as I have said, I have not been able to come up with such a solution. But perhaps you can help me out here. Suppose, for the example, that I wish to call the mpz_gcdext function. That function takes two integers as input and returns three. Here are some questions: 1. How should I declare the C (wrapper) function in Haskell? 2. What would a call of this function look like? 3. What circumstances would the implementing C (wrapper) function have to deal with? In particular, how would it access the two Integer input parameters? And how would it return the resulting three Integer results? I should tell you that I have studied the FFI document "The Haskell 98 Foreign Function Interface 1.0 An Addendum to the Haskell 98 Report (Release Candidate 14)" in detail, not finding it particularly easy going. I am also familiar with the properties of the FFI as implemented by GHC. In fact, I have tried to call a (very simple) C function from Haskell and it actually worked. Unfortunately, the solution to the main problem, that of passing Haskell Integer typed values back and forth between Haskell and C, still eludes me. (I have also seen Simon Marlow's comments to your letter. The sort of things that he talks about there ring bells, sure, but the details are completely unknown to me.) Thank you very much for any help that you provide in this matter. Regards Thorkil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Message "GHC/PrimopWrappers.hs:133:29: Not in scope: `GHC.Prim.quotInteger2Exp#'" building GHC with additional primitive operation
On Monday 27 March 2006 16:33, Bulat Ziganshin wrote: > Thorkil, i can't understand why you can't just use FFI to import > functions you required? why you need to patch the PrimOps list? Hello, As I wrote earlier, using FFI is also a candidate for getting access to additional GMP functions. However, presently, I am not aware of a method of doing this that does not involve some potentially significant additional overhead. After all, Haskell Integers are not directly supported in C, so some sort of marshalling and/or intricate access to internal GHC Haskell structures would seem to be required. But, as you have perhaps seen (my reply to Simon Marlow a few minutes ago on the same matter), adding primitive operations turned out to be easy (at least if you know exactly what you are doing). In addition, I have found that this method with very little effort allows me to continue to write code that can be used both via Hugs and GHC without change. Thanks and regards Thorkil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Message "GHC/PrimopWrappers.hs:133:29: Not in scope: `GHC.Prim.quotInteger2Exp#'" building GHC with additional primitive operation
On Monday 27 March 2006 12:57, Simon Marlow wrote: > quotInteger2Expzh_fast is the function you are adding to PrimOps.cmm to > implement the primop. The patch in your original message indicated that > you had added a stub for this function, so it should link ok. I don't > understand what has gone wrong. > > You could check that indeed ghc/rts/PrimOps.o contains a definition for > this symbol (nm ghc/rts/PrimOps.o), and also check that the symbol is > defined in ghc/rts/libHSrts.a. Hello, The symbol quotInteger2Expzh_fast was indeed not defined in ghc/rts/PrimOps.o. It turned out that simply adding some "real" code to the body of quotInteger2Expzh_fast and recompiling caused a definition of the symbol to be added to PrimOps.o. So, apparently, the definition of a symbol for an empty Cmm body is (sometimes?) discarded. In any case, I managed to define suitable new primitive operations for my Haskell programs. Thanks a lot for your generous help. Best regards Thorkil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Message "GHC/PrimopWrappers.hs:133:29: Not in scope: `GHC.Prim.quotInteger2Exp#'" building GHC with additional primitive operation
n/TidyPgm.o stage2/nativeGen/AsmCodeGen.o stage2/nativeGen/MachCodeGen.o stage2/nativeGen/MachInstrs.o stage2/nativeGen/MachRegs.o stage2/nativeGen/NCGMonad.o stage2/nativeGen/PositionIndependentCode.o stage2/nativeGen/PprMach.o stage2/nativeGen/RegAllocInfo.o stage2/nativeGen/RegisterAlloc.o stage2/ndpFlatten/FlattenInfo.o stage2/ndpFlatten/FlattenMonad.o stage2/ndpFlatten/Flattening.o stage2/ndpFlatten/NDPCoreUtils.o stage2/ndpFlatten/PArrAnal.o stage2/parser/Ctype.o stage2/parser/LexCore.o stage2/parser/Lexer.o stage2/parser/Parser.o stage2/parser/ParserCore.o stage2/parser/ParserCoreUtils.o stage2/parser/RdrHsSyn.o stage2/prelude/ForeignCall.o stage2/prelude/PrelInfo.o stage2/prelude/PrelNames.o stage2/prelude/PrelRules.o stage2/prelude/PrimOp.o stage2/prelude/TysPrim.o stage2/prelude/TysWiredIn.o stage2/profiling/CostCentre.o stage2/profiling/SCCfinal.o stage2/rename/RnBinds.o stage2/rename/RnEnv.o stage2/rename/RnExpr.o stage2/rename/RnHsSyn.o stage2/rename/RnNames.o stage2/rename/RnSource.o stage2/rename/RnTypes.o stage2/simplCore/CSE.o stage2/simplCore/FloatIn.o stage2/simplCore/FloatOut.o stage2/simplCore/LiberateCase.o stage2/simplCore/OccurAnal.o stage2/simplCore/SAT.o stage2/simplCore/SATMonad.o stage2/simplCore/SetLevels.o stage2/simplCore/SimplCore.o stage2/simplCore/SimplEnv.o stage2/simplCore/SimplMonad.o stage2/simplCore/SimplUtils.o stage2/simplCore/Simplify.o stage2/simplStg/SRT.o stage2/simplStg/SimplStg.o stage2/simplStg/StgStats.o stage2/specialise/Rules.o stage2/specialise/SpecConstr.o stage2/specialise/Specialise.o stage2/stgSyn/CoreToStg.o stage2/stgSyn/StgLint.o stage2/stgSyn/StgSyn.o stage2/stranal/DmdAnal.o stage2/stranal/SaAbsInt.o stage2/stranal/SaLib.o stage2/stranal/StrictAnal.o stage2/stranal/WorkWrap.o stage2/stranal/WwLib.o stage2/typecheck/Inst.o stage2/typecheck/TcArrows.o stage2/typecheck/TcBinds.o stage2/typecheck/TcClassDcl.o stage2/typecheck/TcDefaults.o stage2/typecheck/TcDeriv.o stage2/typecheck/TcEnv.o stage2/typecheck/TcExpr.o stage2/typecheck/TcForeign.o stage2/typecheck/TcGenDeriv.o stage2/typecheck/TcHsSyn.o stage2/typecheck/TcHsType.o stage2/typecheck/TcInstDcls.o stage2/typecheck/TcMType.o stage2/typecheck/TcMatches.o stage2/typecheck/TcPat.o stage2/typecheck/TcRnDriver.o stage2/typecheck/TcRnMonad.o stage2/typecheck/TcRnTypes.o stage2/typecheck/TcRules.o stage2/typecheck/TcSimplify.o stage2/typecheck/TcSplice.o stage2/typecheck/TcTyClsDecls.o stage2/typecheck/TcTyDecls.o stage2/typecheck/TcType.o stage2/typecheck/TcUnify.o stage2/types/Class.o stage2/types/FunDeps.o stage2/types/Generics.o stage2/types/InstEnv.o stage2/types/Kind.o stage2/types/TyCon.o stage2/types/Type.o stage2/types/TypeRep.o stage2/types/Unify.o stage2/utils/Bag.o stage2/utils/Binary.o stage2/utils/BitSet.o stage2/utils/Digraph.o stage2/utils/FastMutInt.o stage2/utils/FastString.o stage2/utils/FastTypes.o stage2/utils/FiniteMap.o stage2/utils/IOEnv.o stage2/utils/ListSetOps.o stage2/utils/Maybes.o stage2/utils/OrdList.o stage2/utils/Outputable.o stage2/utils/Panic.o stage2/utils/Pretty.o stage2/utils/PrimPacked.o stage2/utils/StringBuffer.o stage2/utils/UnicodeUtil.o stage2/utils/UniqFM.o stage2/utils/UniqSet.o stage2/utils/Util.o stage2/parser/hschooks.o /home/tn/tn/Haskell/ghc/unpack/ghc-6.4.1/ghc/rts/libHSrts.a(Linker.o): (.data+0x41c): undefined reference to `quotInteger2Expzh_fast' collect2: ld returned 1 exit status <> make[2]: *** [stage2/ghc-6.4.1] Error 1 make[2]: Leaving directory `/home/tn/tn/Haskell/ghc/unpack/ghc-6.4.1/ghc/compiler' make[1]: *** [stage2] Error 2 make[1]: Leaving directory `/home/tn/tn/Haskell/ghc/unpack/ghc-6.4.1' make: *** [bootstrap2] Error 2 And that message persisted, even when I tried "make clean" and "make all" in the top-level directory. I have tried a few things, groping in the darkness I would call it, trying to get around this. And I was actually able produce a compiler by temporarily removing the quotInteger2Expzh_fast reference in ghc/rts/Linker.c. But the produced compiler (including GHCi) complained about missing the symbol quotInteger2Expzh_fast. The file libraries/base/GHC/Base.lhs contains the tantalizing remarks GHC.PrimHas no implementation. It defines built-in things, and by importing it you bring them into scope. The source file is GHC.Prim.hi-boot, which is just copied to make GHC.Prim.hi but I have not been able to find anything that relates to this. So I am again at a loss, aksing for help to proceed. Thanks a lot in advance. Best regards Thorkil Naur ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Message "GHC/PrimopWrappers.hs:133:29: Not in scope: `GHC.Prim.quotInteger2Exp#'" building GHC with additional primitive operation
cord: [EMAIL PROTECTED]:~/tn/tmp/Haskell/work> gcc -v Using built-in specs. Target: i586-suse-linux Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,f95,java,ada --disable-checking --with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-java-awt=gtk --disable-libjava-multilib --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit --without-system-libunwind --host=i586-suse-linux Thread model: posix gcc version 4.0.2 20050901 (prerelease) (SUSE Linux) [EMAIL PROTECTED]:~/tn/tmp/Haskell/work> ghc --version The Glorious Glasgow Haskell Compilation System, version 6.2 [EMAIL PROTECTED]:~/tn/tmp/Haskell/work> Best regards Thorkil Naur ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
