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 built-in # 1 command-line # 1 t.c a b $ gcc t.c -E -traditional # 1 t.c # 1 built-in # 1 command-line # 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: [Haskell] Woes on MacOS 10.6 - linking issues
Hello, Concerning the undefined iconv symbols, take a look at http://hackage.haskell.org/trac/ghc/ticket/4068, it seems to be about something similar. Best regards Thorkil On Thu, Jun 10, 2010 at 08:53:13PM -0600, Brett Giles wrote: Hi Folks I seem to have Gtk2HS 0.11 installed, but not quite working. Interestingly, I can run a demo, such as the hello/World.hs example, directly in ghci. However, when I try to do a ghc --make on any code containing gtk2hs I get a link error like this: Undefined symbols: _iconv_close, referenced from: _hs_iconv_close in libHSbase-4.2.0.0.a(iconv.o) (maybe you meant: _hs_iconv_close) _iconv, referenced from: _hs_iconv in libHSbase-4.2.0.0.a(iconv.o) (maybe you meant: _hs_iconv_open, _hs_iconv , _hs_iconv_close ) _iconv_open, referenced from: _hs_iconv_open in libHSbase-4.2.0.0.a(iconv.o) (maybe you meant: _hs_iconv_open) ld: symbol(s) not found I do have libiconv installed as a universal library via macports. gtk, glade etc., are also universal installed via macports. I downloaded the OSX Haskell Platform package and am running ghc 6.12.1 Other programs seem to be having some issues as well though, For instance, a command line program seems to compile fine, but when it runs I get the message: $ emlqpl (--- My successfully compiled program - batch only, no gtk items) dyld: Library not loaded: /opt/local/lib/libgtk-quartz-2.0.0.dylib Referenced from: /usr/local/bin/emlqpl Reason: image not found Trace/BPT trap Does anyone have any suggestions? Brett Giles Grad Student, Formal Methods, Category Theory, University of Calgary brett.gi...@ucalgary.ca ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: hpc-strobe-0.1: Hpc-generated strobes for a running Haskell program
I am pleased to announce the initial release of hpc-strobe: Hpc-generated strobes for a running Haskell program. hpc-strobe is a rudimentary library that demonstrates the possibility of using Hpc (Haskell Program Coverage) to inspect the state of a running Haskell program. hpc-strobe-0.1 has been uploaded to hackage: http://hackage.haskell.org/packages/archive/hpc-strobe/0.1/hpc-strobe-0.1.tar.gz In ordinary use of Hpc, a single so-called tix file is produced at the end of a run. The tix file records how many times each expression has been used during the run. This can be used to mark up the source code, identifying expressions that have not been used. hpc-strobe uses the basic machinery provided by Hpc to produce multiple tix files, also called strobes, representing the coverage at different times while the program is running. By subtracting such two tix files, again using Hpc machinery, a tix file representing the expressions used between the times of recording the subtracted tix files is produced. This may be used, for example, to get a better idea of what a long-running program is doing. It could also be used as a profiling tool, getting information about how many times individual expressions are used. A program is included whose strobe differences produce a crude rendering of an analog clock when they are used to mark up the source code using Hpc. Please see the attached example (gunzip the file, point you browser to it, scroll down to view the canvas function). Use of the library involves a simple change of the main function and also requires the program to be enabled for hpc. At the time of writing, this means using a fairly recent version of GHC and compiling the Haskell code with the -fhpc option. For additional details, see the README included in the package. Best regards Thorkil Main.hs.html.gz Description: GNU Zip compressed data ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] ANNOUNCE: hpc-strobe-0.1: Hpc-generated strobes for a running Haskell program
I am pleased to announce the initial release of hpc-strobe: Hpc-generated strobes for a running Haskell program. hpc-strobe is a rudimentary library that demonstrates the possibility of using Hpc (Haskell Program Coverage) to inspect the state of a running Haskell program. hpc-strobe-0.1 has been uploaded to hackage: http://hackage.haskell.org/packages/archive/hpc-strobe/0.1/hpc-strobe-0.1.tar.gz In ordinary use of Hpc, a single so-called tix file is produced at the end of a run. The tix file records how many times each expression has been used during the run. This can be used to mark up the source code, identifying expressions that have not been used. hpc-strobe uses the basic machinery provided by Hpc to produce multiple tix files, also called strobes, representing the coverage at different times while the program is running. By subtracting such two tix files, again using Hpc machinery, a tix file representing the expressions used between the times of recording the subtracted tix files is produced. This may be used, for example, to get a better idea of what a long-running program is doing. It could also be used as a profiling tool, getting information about how many times individual expressions are used. A program is included whose strobe differences produce a crude rendering of an analog clock when they are used to mark up the source code using Hpc. Please see the attached example (gunzip the file, point you browser to it, scroll down to view the canvas function). Use of the library involves a simple change of the main function and also requires the program to be enabled for hpc. At the time of writing, this means using a fairly recent version of GHC and compiling the Haskell code with the -fhpc option. For additional details, see the README included in the package. Best regards Thorkil Main.hs.html.gz Description: GNU Zip compressed data ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Announce] primes
Hello, On Thursday 16 April 2009 17:22, Sebastian Fischer wrote: ... Thanks! Feel free to incorporate ideas from NaurPrimes.hs. I don't understand them yet. NaurPrimes.hs is derived from the EratoS.hs that you get from unpacking thorkilnaur.dk/~tn/Haskell/EratoS/T64_20070303_1819.tar.gz. EratoS.hs is explained in thorkilnaur.dk/~tn/Haskell/EratoS/EratoS2.txt. Please don't hesitate to ask questions about this. I'll do my best to answer. ... Best regards Thorkil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
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: 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 a copy of the Library already present on the user's computer
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 /dev/null apirecomp001.run.stdout 2apirecomp001.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-version/. 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: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
Hello, On Thursday 15 January 2009 19:59, Peter Verswyvelen wrote: It is rather funny. When we are young kids, we learn weird symbols like A B C a b c 1 2 3 which we accept after a while. Then we get to learn more complex symbols like ! ? + - / and that takes some time to get used to, but eventually, that works too. But Functor, Monoid or Monad, that we cannot accept anymore. Why, because these are not intuitive? Are the symbols above intuitive? I think there is a simple explanation of this: Consider the amount of time you spent, as a young kid, to learn to get used to these funny 1, 2, a, b, x, y, +, - and so on. I haven't got the exact schedules from school, but my impression is that we are talking about hours and hours of drill and practice, over weeks, months, years. I mean, do you show your small children (say, 5 years old) how to write numbers to represent, say, the number of oranges in a bowl and then they comprehend after, say, a couple of minutes? Or half an hour? No. Learning to get used to such things, let alone use them effectively to solve common problems, takes time. And also, of course, intense and qualified guidance, in some form. So, to learn to become familiar and effective in using new and complex concepts, we should just accept that it sometimes may take a while. And that's it. It is all a matter of practice, exposure, and guidance. ... Best regards Thorkil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Recursive modules, GHC /= Report?
Hello, On Wednesday 14 January 2009 12:59, Mauricio wrote: Hi, Here: http://www.haskell.org/onlinereport/modules.html I read: Modules may reference other modules via explicit import declarations, each giving the name of a module to be imported and specifying its entities to be imported. Modules may be mutually recursive. However, I get this from GHC: --- Module imports form a cycle for modules: main:Main imports: Control.Concurrent.MVar GtkMostrarConfig GtkLerECG Graphics.UI.Gtk main:GtkMostrarConfig imports: Control.Concurrent.MVar Graphics.UI.Gtk Main --- Aren't cycles of modules just recursive modules? Why wasn't that allowed? Have you looked at http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilation.html#mutual-recursion ? I never tried this myself, but it seems to explain some important details about how to compile mutually recursive modules using GHC. Thanks, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Best regards Thorkil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Help : data concurrent packages
Hello, On Tuesday 13 January 2009 18:26, bft wrote: Hi ! Can someone tell me where to download the *data* and *concurrent *packages. I recall data and concurrent packages from some years back, but I would assume that they are merged into the base package nowadays where GHC-6.10.1 is the latest release of GHC. I suggest that you just remove these package dependencies (in case they happen to bother, somehow) and, if any name turns out to be undefined, try http://haskell.org/hoogle/ to search for it. Packages are usually located via http://hackage.haskell.org/packages/hackage.html . ... Best regards Thorkil ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] How to think about this? (profiling)
Hello, On Tuesday 16 December 2008 13:19, Felipe Lessa wrote: 2008/12/16 Magnus Therning mag...@therning.org: That is, where each value depends on _all_ preceding values. AFAIK list access is linear, is there a type that is a more suitable state for this changed problem? I realise this particular function can be written using scanl: [...] but I guess it's not always that easy to construct a solution based on scanl. You can always write something like foo :: Int - Int foo = (vals !!) where vals = map foo' [0..] foo' 0 = 0 foo' 1 = 1 foo' 2 = 2 foo' n = sum $ map foo [0..n-1] which doesn't prevent you from using whatever recursive case you want. Note that if your recursive case depends on all preceding values, then you can't do better than using a linear access data structure like a list unless you need random access. Another possibility would be: g n = t!n where t = array (0,max 2 n) $ (0,0):(1,1):(2,2):[ (i,t!(i-3) + t!(i-2) + t!(i-1)) | i - [3..n] ] using your original example. As noted in the Haskell 98 report, section 16.1 Array Construction, the array function is non-strict in the values of the association list, making this recurrence possible. ... Best regards Thorkil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
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: 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: 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 -Bdir 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: [Haskell-cafe] Meaning of ribbonsPerLine at Text.PrettyPrint.HughesPJ ?
Hello, On Wednesday 18 June 2008 22:13, Alfonso Acosta wrote: Hi, Can anyone give a good explanation of what ribbonsPerLine means? Maybe it would be better to simply ask for the meaning of ribbon in this context. The documentation is totally meaningless to me: reibbonsPerLine: Ratio of ribbon length to line length. In the paper The Design of a Pretty-printing Library by John Hughes (http://www.cs.chalmers.se/~rjmh/Papers/pretty.ps) that introduced this pretty printing library, the ribbon concept is introduced like this (apologies for the layout, please use the original .ps file for accuracy): 7.4 Choosing a Pretty Layout Now that we have designed combinators for constructing documents with many possible layouts, it is time to discuss choosing among those alternatives. Many prettyprinters aim simply to avoid exceeding a given page width. However, we found that using this criterion alone tends to produce layouts such as for i = 1 to 100 do for j = 1 to 100 do for k = 1 to 100 do a[i,j,k] := 0 which fits on a page, but cannot be described as pretty. We therefore impose an additional constraint limiting the number of characters on each line (excluding indentation) to a smaller number. The idea is to avoid placing too much information on a line -- even a line that begins at the left margin. Under this constraint the example above might instead be laid out as for i = 1 to 100 do for j = 1 to 100 do for k = 1 to 100 do a[i,j,k] := 0 In general a pretty layout will consist of a ribbon of text snaking across the page. To see that this is reasonable, ask yourself: `is the prettiest layout on an infinitely wide page really to place everything on one line?' So pretty printing is guided by two lengths: The line length and the (smaller) ribbon length. The ribbons per line ratio that you can specify is simply a way of specifying the ribbon length relative to the line length. So, for example, if the line length is 80 and the ratio is 1.5, the ribbon length would be 80/1.5 which is rounded to 53. ... Best regards Thorkil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: ANN: ghc 6.8.2 from MacPorts
Hello Christian, On Monday 17 March 2008 12:31, Christian Maeder wrote: Thanks Chris! This should fix http://hackage.haskell.org/trac/ghc/ticket/1958 http://hackage.haskell.org/trac/ghc/ticket/2117 Thorkil, you called your patch illustrative only. I suggest to commit it. Any objections? Thanks for the patch, anyway. No objections at all, since the patch does appear to solve some real problems. But I would suggest that we keep at least #1958 open, until we have understood the problem better. As described in #1958, the patch is what I would call a lucky guess, based on several experiments with different versions of very small assembly language programs that triggered the linker error message. I, at least, would not claim to understand what goes on in detail. I have not head from Apple since reporting the problem. I checked a few weeks ago and currently I am actually unable to access the bug reporter. I have a plan eventually to try to figure out what the real problem is (that is, debugging the linker), but haven't gotten around to it so far. Cheers Christian My built can be found at: http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/mac/ghcs/ghc-6.8.2-powerpc-apple-darwin-static-libs.tar.bz2 It uses static libs for gmp, ncurses and readline, but should run on tiger and leopard ppc. (#1845, #2031 are still problems) C.M.Brown wrote: Hi Christian, The build went without any problems, the log can be found here: http://www.cs.kent.ac.uk/people/rpg/cmb21/inst.log.gz kind regards, Chris. Thanks to you all for working on this matter. Best regards Thorkil ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [Haskell-cafe] Re: A question about monad laws
Hello, On a tangent, probably: On Thursday 14 February 2008 10:24, Roman Leshchinskiy wrote: ... Hmm. Personally, I've never seen an algorithm where comparing for exact equality was algorithmically necessary. Sometimes (rarely) it is acceptable but necessary? Do you know of one? Finding the machine epsilon, perhaps, that is, the smallest (floating point, surely) number for which 1.0+machine_eps==1.0 would be a candidate? ... Best regards Thorkil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] fast integer base-2 log function?
Hello, If the standard libraries provide such a function, I haven't found it. I must admit that I haven't studied your code in detail. I usually do as follows for integer logarithms, shamelessly stolen from the Haskell report: -- Integer log base (c.f. Haskell report 14.4): imLog :: Integer-Integer-Integer imLog b x = if x b then 0 else let l = 2 * imLog (b*b) x doDiv x l = if x b then l else doDiv (x`div`b) (l+1) in doDiv (x`div`(b^l)) l Best regards Thorkil On Monday 11 February 2008 07:15, Uwe Hollerbach wrote: Hello, haskellers, Is there a fast integer base-2 log function anywhere in the standard libraries? I wandered through the index, but didn't find anything that looked right. I need something that's more robust than logBase, it needs to handle numbers with a few to many thousands of digits. I found a thread from a couple of years ago that suggested there was no such routine, and that simply doing length (show n) might be the best. That seems kind of... less than elegant. I've come up with a routine, shown below, that seems reasonably fast (a few seconds of CPU time for a million-bit number, likely adequate for my purposes), but it seems that something with privileged access to the innards of an Integer ought to be even much faster -- it's just a simple walk along a list (array?) after all. Any pointers? Thanks! Uwe powi :: Integer - Integer - Integer powi b e | e == 0= 1 | e 0 = error negative exponent in powi | even e= powi (b*b) (e `quot` 2) | otherwise = b * (powi b (e - 1)) ilog2 :: Integer - Integer ilog2 n | n 0 = ilog2 (- n) | n 2 = 1 | otherwise = up n (1 :: Integer) where up n a = if n (powi 2 a) then bin (quot a 2) a else up n (2*a) bin lo hi = if (hi - lo) = 1 then hi else let av = quot (lo + hi) 2 in if n (powi 2 av) then bin lo av else bin av hi (This was all properly aligned when I cut'n'pasted; proportional fonts might be messing it up here.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Ancient, but still having fun
Young Man, On Saturday 19 January 2008 00:07, Simon Peyton-Jones wrote: Friends, It's Friday 18 January 2008, which makes it my 50th birthday. Congratulations! ... Ancient or not, I'm still having a terrific time in this community. When I first became addicted to functional programming, as a result of Arthur Norman's 4-lecture course, and David Turner's SK-combinator papers, I never dreamt of what a wild and fascinating ride it would turn out to be. Thank you all! Simon ... Rest assured that there are many of us having a terrific time too. And not least because of your in many ways fabulous presence. Thank you Simon. Best regards Thorkil ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
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: 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: 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: http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip
Hello, Thanks everybody. However, I believe that using a modified readline library is debatable, mainly because it adds the burden of keeping this library up-to-date to the GHC maintenance process. Having a renamed library is one thing and it does not seem that also modifying the contents of the library is an improvement. For me to consider this idea, it should be the very last solution, every other stone having been turned. And I certainly believe that stones remain to be turned in this case. I would very much like to hear your comments to this. In addition, if you must replace this framework with another with different contents, I would suggest the use of some versioning scheme. Otherwise is seems that a lot of confusion could result. Thanks and best regards Thorkil On Thursday 03 January 2008 16:18, Ian Lynagh wrote: Hi Christian, On Thu, Jan 03, 2008 at 02:41:56PM +0100, Christian Maeder wrote: Judah's framework (2342543 Bytes) http://www.math.ucla.edu/~jjacobson/ghc/GNUreadline-framework.zip should replace (my old one) http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip Done! Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
readline problems building GHC on Mac OS X (was: Re: [Haskell-cafe] Re: ANNOUNCE: GHC version 6.8.2)
Hello, Although I have been building various GHC versions on various PPC Mac OS X systems for a while now, I'm afraid that I don't really have a good answer for your questions. However, your questions provide an excellect opportunity to discuss this, so that is what I am going to do. There are several questions here: (1) Which readline do we use? (2) Where do we store it? (3) What do we call it? (4) How do we make the Haskell readline library build process select the right one? And perhaps (5) How do we persuade the GHC build process to make the Haskell readline build that happens as part of building GHC select the right one? One at a time: 1. Which readline do we use? GNU readline, of course. As opposed to the readline installed as /usr/include/readline/*.h and /usr/lib/libreadline.dylib on our PPC Mac OS X machines which are said to be (and can even be observed to be) symbolic links to something called libedit and which, to me, never has managed to provide something suitable for use by GHC. But what is GNU readline, then? I don't exactly know, but my best guess is something like ftp://ftp.cwru.edu/pub/bash/readline-5.2.tar.gz. I never tried to install GNU readline directly from this file. On some occasions, I have installed readline from mac ports. Although I am fairly confident that what was installed was some version of the GNU readline, I am not sure. On other occasions, I have installed GNU readline from various sources related to GHC, some times known to me, at other times not. 2.Where do we store readline? I don't know where a readline based on the GNU download ftp://ftp.cwru.edu/pub/bash/readline-5.2.tar.gz would become installed (by default). The mac ports version installs by default at /opt/local/include/readline/*.h and /opt/local/lib/libreadline.*. Various readlines related to GHC have installed themselves (or were requested to become installed) as frameworks, this new and different Mac OS X mechanism for referring to a set of header files and corresponding library. So they have gone into /Library/Frameworks. 3. What do we call it? Here is where the interesting things start to happen: A central problem has been the ambiguity caused by Apple's decision to install symbolic links to the edit headers and edit library called readline. And various mechanisms have been used to work around this problem: (a) If you have installed a mac ports readline at /opt/local/..., with GHC 6.6 at least, you were able to use the --with-readline-* options to direct GHC/the library build process to look in these directories first and thereby avoid the edit library; (b) At some point, a (possibly modified) version of the GNU readline library appeared, intended to be installed as a framework by the name of GNUreadline (as opposed to the bare readline name used earlier). This avoids the name clash caused by the Apple linking of readline to edit. The problem that the Haskell readline library now needs to refer to a framework GNUreadline rather than ... (whatever it is that it refers to in a more Unix'y setting) is solvable. In addition, however, the readline library (or rather: The GNUreadline library derived from the readline library) refers to itself using the bare readline name, so that has to be changed also, leading to a need to maintain a complete and slightly modified version (GNUreadline) of the readline library. It seems to me that this situation is less than ideal. I mean, in theory, somebody may come along at some point with some library calling itself GNUreadline and then we would have to adapt, doing the whole thing all over again. This manner of avoiding the name clash problem does not seem tenable in the long run. Instead, what we should be able to do, is to specify, directly and to the point, that readline, wherever we stored it, is what we want. That possibility does not exist, unfortunately, so we will have to make the best use that we can of the existing mechanisms, as far as we can figure out what they are, to get the desired effect. And if it turns out that the existing mechanisms do not allow us to do what we want, we need to request extensions and modifications of the mechanisms, until they are able to support our requirements. I am not quite sure that I am done with this subject, but let me go on with 4. How do we make the Haskell readline library build process select the right one? This is where I believe we can do something useful, making the Haskell readline library more capable in selecting its foundation readline library. I haven't worked out the details, some discussion is at http://hackage.haskell.org/trac/ghc/ticket/1395 and related tickets, but I am quite sure that methods can be found to select the desired readline library, without resorting to reissuing that library in a changed form and under a new name. And if this turns out to be absolutely impossible, I would much prefer pressing for the introduction of
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=dir'), 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
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: Data.HashTable.hashInt seems somewhat sub-optimal
Hello, On Monday 20 August 2007 13:15, Ian Lynagh wrote: ... I'm also suspicious of this, though: -- | A sample hash function for Strings. We keep multiplying by the -- golden ratio and adding. -- -- Note that this has not been extensively tested for reasonability, -- but Knuth argues that repeated multiplication by the golden ratio -- will minimize gaps in the hash space. hashString :: String - Int32 hashString = foldl' f 0 where f m c = fromIntegral (ord c + 1) * golden + mulHi m golden should this be where f m c = (fromIntegral (ord c + 1) + m) * golden ? Does Knuth (TAOCP?) say? In the 2nd edition of Knuth's The Art of Computer Programming, Vol 3, Sorting and Searching there is a discussion of hash functions on pp. 514-520. One of the techniques suggested for hashing a one-word (i.e. essentially fixed-size) key is the following multiplicative scheme: h(K) = floor ( M*(((A/w)*K)) mod 1) ) where w is the word-size (say, 2^32), M is the desired limit of the hash function (for efficiency, probably a suitable power of 2) and, finally, A is some integer constant. What happens here is that we consider the (word) K as a fraction with the binary point at the left end of the word rather than at the right, thus getting a fraction with a value between 0 and 1. This value we then multiply by A and cut off the integer part, once again getting a fractional value between 0 and 1. And finally, we multiply by M and cut away the fractional part to get an integer value between 0 and M-1. And, sure, Knuth suggests various variants of selecting the multiplier A related to the golden ratio (sqrt(5)-1)/2 = 0.6180... to gain suitable spreading of hashes for keys in arithmetic progressions. (K, K+d, K+2d, ...). But what we are dealing with in the hashString function is what Knuth would call a multiword or variable-length key. Such cases, Knuth suggests, can be handled by multiple-precision extensions of [e.g. the multiplicative scheme] above, but it is generally adequate to speed things up by combining the individual words together into a single word, then doing a single multiplication ... as above. Neither of the above definitions of f implement a multiple-precision extension of the multiplicative hashing scheme that involves the golden ration. And none of the methods suggested by Knuth for combining multiple words into single words or otherwise compute hashes for multiword keys involve the golden ration. So I cannot find obvious traces of Knuth having anything at all to say about either of the f's. ... Best regards Thorkil ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [Haskell-cafe] Re: Code and Perf. Data for Prime Finders (was: Genuine Eratosthenes sieve)
Hello, On Wednesday 25 July 2007 01:42, Thorkil Naur wrote: Hello Melissa, On Tuesday 24 July 2007 19:09, Melissa O'Neill wrote: ... (See ONeillPrimes.hs in http://www.cs.hmc.edu/~oneill/code/haskell- primes.zip for the complete code. I've also added Thorkil Naur's code from March, which is also a good performer, Do you have detailed measurements that you wish to share? I would be most interested, I assure you. although its another case where most readers would find a detailed explanation of the code instructive.) I'll do my very best to provide such an explanation within, say, the next couple of weeks. ... And now that time has come, so brace yourselves. For your convenience, my code from March is thorkilnaur.dk/~tn/T64_20070303_1819.tar.gz See also a preliminary description in http://www.haskell.org/pipermail/haskell-cafe/2007-March/023095.html. The new explanation is here: thorkilnaur.dk/~tn/Haskell/EratoS/EratoS2.txt Best regards Thorkil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [GHC] #1563: -Onot is not described in the GHC User's Guide, Version 6.6.1
Hello, To get some help with Haskell, it is probably best to write to the [EMAIL PROTECTED] mailing list. I also suggest that you include some details of what your difficulties seem to be. Best regards Thorkil On Saturday 28 July 2007 02:44, Paulo Silva wrote: Hi I have a dificult how to write a fuction haskell; could you please help me to do that ? Best ragard Paulo Silva GHC [EMAIL PROTECTED] escreveu: #1563: -Onot is not described in the GHC User's Guide, Version 6.6.1 +--- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown +--- The GHC optimization option -Onot is not described in the current (Version 6.6.1) GHC User's Guide, but it is nevertheless used, for example in mk/build.mk.sample in the GHC darcs repository. I would expect some description of -Onot in http://www.haskell.org/ghc/docs/latest/html/users_guide/options- optimise.html and a summary in http://www.haskell.org/ghc/docs/latest/html/users_guide/flag- reference.html. Interestingly, I have found this description in an earlier version of the User's Guide (http://www.haskell.org/ghc/docs/2.10/users_guide/user_26.html): `-Onot': This option will make GHC forget any -Oish options it has seen so far. Sometimes useful; for example: `make all EXTRA_HC_OPTS=-Onot'. But what this really means, I am not sure. -- Ticket URL: GHC The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs Alertas do Yahoo! Mail em seu celular. Saiba mais. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[Haskell-cafe] Re: Using Gtk2Hs version 0.9.12 on a PPC Mac
Hello, On Saturday 28 July 2007 14:22, Duncan Coutts wrote: On Sat, 2007-07-28 at 12:16 +0200, Thorkil Naur wrote: Hello, (From the archives:) [Haskell] ANNOUNCE: Gtk2Hs version 0.9.12 released Duncan Coutts duncan.coutts at worc.ox.ac.uk Fri Jul 27 15:20:57 EDT 2007 Gtk2Hs - A GUI Library for Haskell based on Gtk+ Version 0.9.12 is now available from: ... Duncan (on behalf of the Gtk2Hs team) Following the advice of nominolo_ from #haskell yesterday, I added -L/opt/local/lib to my ghc command and then the helloworld demo of Gtk2Hs worked. The problem seems to be the order in which the two library directories /usr/X11R6/lib and /opt/local/lib appear on the link command: For the GTK+ example that worked, /opt/local/lib comes first. For the Gtk2Hs demo that failed, /usr/X11R6/lib comes first. That's very interesting. I compared these two directories and found these common files: [...] Since some of these (Xrender, fontconfig, and freetype) are actually used in GTK+ (and therefore also Gtk2Hs) applications, there is clearly a potential for conflict here. Certainly and if I recall correctly, the gdb backtrace you got showed that it was failing in a call to a fontconfig function. A good guess: (gdb) run Starting program: /Users/thorkilnaur/tn/Gtk2Hs/gtk2hs-0.9.12/demo/hello/helloworld Reading symbols for shared libraries .++...++...+.+. +.... done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x0001 FcFontSetSort (config=0x0, sets=0xbfffba50, nsets=2, p=0x2114fb0, trim=1, csp=0x0, result=0xbfffbb18) at fcmatch.c:696 ... In any case, adding -L/opt/local/lib to the ghc command makes this library appear before /usr/X11R6/lib on the link command and this seems to solve the problem. Subsequently, I have tried a handful of the other demos, and as far as they didn't require something that wasn't available (glade, for example), they seemed to work. So what I wonder is how we can make this work reliably. We use the flags that pkg-config tells us to use, I'd rather not add platform-specific hacks if we can get the pkg-config settings fixed. So I presume when you run pkg-config --libs gtk+-2.0 it does not list -L/opt/local/lib, or if it does it lists it after -L/usr/X11R6/lib. Is that the case? For the GTK+ tutorial helloworld.c program: $ pkg-config --libs gtk+-2.0 -L/Users/thorkilnaur/tn/install/gtk+-2.10.14/lib -L/opt/local/lib -L/usr/X11R6/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lpango-1.0 -lcairo -lSM -lICE -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -liconv -lfreetype -lz -lfontconfig -lpng12 -lXrender -lX11 $ gcc -v -Wall -g helloworld.c -o helloworld `pkg-config --cflags gtk+-2.0` `pkg-config --libs gtk+-2.0` ... /usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/collect2 -dynamic -arch ppc -weak_reference_mismatches non-weak -o helloworld -lcrt1.o /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/crt2.o -L/Users/thorkilnaur/tn/install/gtk+-2.10.14/lib -L/opt/local/lib -L/usr/X11R6/lib -L/usr/lib/gcc/powerpc-apple-darwin8/4.0.1 -L/usr/lib/gcc/powerpc-apple-darwin8/4.0.1 -L/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../.. /var/tmp//cctkdfsu.o -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lpango-1.0 -lcairo -lSM -lICE -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -liconv -lfreetype -lz -lfontconfig -lpng12 -lXrender -lX11 -lgcc -lSystemStubs -lSystem $ Scrutinizing the link arguments output by gcc, it appears that the -Ls and the -ls specified on the gcc command have been separated and inserted between other -Ls and -ls supplied by gcc. But the order of the -Ls produced by pkg-config is retained and, as mentioned, this is the case that works without change. For the Gtk2Hs demo World.hs program, the matter is more complex, especially since the link arguments generated by ghc presumably goes via ghc-pkg that I have never studied in detail before. But let me venture a guess anyway. First we look at the gtk package and its dependents: $ for p in gtk-0.9.12 glib-0.9.12 cairo-0.9.12; do echo $p: `ghc-pkg field $p depends`; done gtk-0.9.12: depends: base-2.0 mtl-1.0 glib-0.9.12 cairo-0.9.12 glib-0.9.12: depends: base-2.0 cairo-0.9.12: depends: base-2.0 mtl-1.0 glib-0.9.12 $ Further: $ for p in gtk-0.9.12 glib-0.9.12 cairo-0.9.12; do echo $p: `ghc-pkg field $p library-dirs`; done gtk-0.9.12: library-dirs: /Users/thorkilnaur/tn/install/gtk+-2.10.14/lib /usr/X11R6/lib /Users/thorkilnaur/tn/install/gtk2hs-0.9.12/lib/gtk2hs glib-0.9.12: library-dirs: /opt/local/lib /Users/thorkilnaur/tn/install/gtk2hs-0.9.12/lib/gtk2hs cairo-0.9.12: library-dirs: /opt/local/lib /usr/X11R6/lib /Users/thorkilnaur/tn/install/gtk2hs-0.9.12/lib/gtk2hs $ The actual link arguments constructed
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: [Haskell-cafe] Re: Code and Perf. Data for Prime Finders (was: Genuine Eratosthenes sieve)
Hello Melissa, On Tuesday 24 July 2007 19:09, Melissa O'Neill wrote: apfelmus wrote: After some pondering, the List a data structure for merging is really ingenious! :) Here's a try to explain how it works: Thanks apfelmus! A detailed explanation of this code is really helpful for anyone trying to understand what is going on. The VIP/ Crowd analogy is also very nice. I think that this approach has the potential to outperform O'Neill's (old?) code because it doesn't incorporates another prime number to the sieve mechanism until it really has to. I mean the following: in the 1st, 2nd, 3rd, 4th, ... step, O'Neill's code adds the multiples 2*2, 3*3, 5*5, 7*7, ... to the priority queue and uses them to sieve for potential prime numbers from then on. Yeah, that's (only) what the code in my paper does -- it's good enough for explicative purposes, but all recent versions have used a slightly augmented priority queue. It's a priority queue coupled with a feeder list that provides entries to add to the queue (in increasing order). They are only admitted to the heap data structure only once when the root of the heap gets there. The two most important bits are: type HybridQ k v = (PriorityQ k v, [(k,v)]) -- postRemoveHQ is called when the min element of the heap has changed postRemoveHQ :: Ord k = HybridQ k v - HybridQ k v postRemoveHQ mq@(pq, []) = mq postRemoveHQ mq@(pq, (qk,qv) : qs) | qk minKeyPQ pq = (insertPQ qk qv pq, qs) | otherwise= mq (See ONeillPrimes.hs in http://www.cs.hmc.edu/~oneill/code/haskell- primes.zip for the complete code. I've also added Thorkil Naur's code from March, which is also a good performer, Do you have detailed measurements that you wish to share? I would be most interested, I assure you. although its another case where most readers would find a detailed explanation of the code instructive.) I'll do my very best to provide such an explanation within, say, the next couple of weeks. the approach here adds 5*5=25 to the heap only after considering the 9th prime 23. Yep, that's what mine does too. Best Regards, Melissa. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Thanks a lot and the best regards Thorkil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Installation Problem GHC 6-6
Hello, Can you tell us exactly which package you have attempted to install? That would be very useful, thanks. Also, if you could make the exact sequence of commands used and the output somehow available, that would also help a lot to figure out what has happened. (A quick shot at a possible solution would be to say sudo make install rather than just make install to install as root. Unfortunately, the error messages you quote don't really indicate that lack of permissions is the problem, so I am not really sure that this suggestion would work.) Thanks and best regards Thorkil On Thursday 19 July 2007 22:41, Cornelius Nevrinceanu wrote: Hello: I tried to install GHC 6-6 on my Mac PowerBook G4, under system 10.4.10. I followed the instructions that came with the download. The Makefile phase seemed to work correctly however make install did not find things in order (see further down). What did I do incorrectly? Thanks, Cornelius Nevrinceanu Trace of make install faber:~ Faber$ make install Configuring ghc, version 6.6, on powerpc-apple-darwin ... Creating a configured version of ghcprof .. /bin/sh: line 1: bin/powerpc-apple-darwin/ghcprof: No such file or directory /bin/sh: line 1: bin/powerpc-apple-darwin/ghcprof: No such file or directory /bin/sh: line 1: bin/powerpc-apple-darwin/ghcprof: No such file or directory /bin/sh: line 1: bin/powerpc-apple-darwin/ghcprof: No such file or directory /bin/sh: line 1: bin/powerpc-apple-darwin/ghcprof: No such file or directory /bin/sh: line 1: bin/powerpc-apple-darwin/ghcprof: No such file or directory /bin/sh: line 1: bin/powerpc-apple-darwin/ghcprof: No such file or directory /bin/sh: line 1: bin/powerpc-apple-darwin/ghcprof: No such file or directory chmod: bin/powerpc-apple-darwin/ghcprof: No such file or directory Done. Creating a configured version of ghc-asm .. /bin/sh: line 1: lib/powerpc-apple-darwin/ghc-asm: No such file or directory /bin/sh: line 1: lib/powerpc-apple-darwin/ghc-asm: No such file or directory /bin/sh: line 1: lib/powerpc-apple-darwin/ghc-asm: No such file or directory /bin/sh: line 1: lib/powerpc-apple-darwin/ghc-asm: No such file or directory /bin/sh: line 1: lib/powerpc-apple-darwin/ghc-asm: No such file or directory /bin/sh: line 1: lib/powerpc-apple-darwin/ghc-asm: No such file or directory /bin/sh: line 1: lib/powerpc-apple-darwin/ghc-asm: No such file or directory /bin/sh: line 1: lib/powerpc-apple-darwin/ghc-asm: No such file or directory chmod: lib/powerpc-apple-darwin/ghc-asm: No such file or directory Done. Creating a configured version of ghc-split .. /bin/sh: line 1: lib/powerpc-apple-darwin/ghc-split: No such file or directory /bin/sh: line 1: lib/powerpc-apple-darwin/ghc-split: No such file or directory /bin/sh: line 1: lib/powerpc-apple-darwin/ghc-split: No such file or directory /bin/sh: line 1: lib/powerpc-apple-darwin/ghc-split: No such file or directory /bin/sh: line 1: lib/powerpc-apple-darwin/ghc-split: No such file or directory /bin/sh: line 1: lib/powerpc-apple-darwin/ghc-split: No such file or directory /bin/sh: line 1: lib/powerpc-apple-darwin/ghc-split: No such file or directory /bin/sh: line 1: lib/powerpc-apple-darwin/ghc-split: No such file or directory chmod: lib/powerpc-apple-darwin/ghc-split: No such file or directory Done. Creating a configured version of ghc-6.6 .. /bin/sh: line 1: bin/powerpc-apple-darwin/ghc-6.6: No such file or directory /bin/sh: line 1: bin/powerpc-apple-darwin/ghc-6.6: No such file or directory /bin/sh: line 1: bin/powerpc-apple-darwin/ghc-6.6: No such file or directory /bin/sh: line 1: bin/powerpc-apple-darwin/ghc-6.6: No such file or directory /bin/sh: line 1: bin/powerpc-apple-darwin/ghc-6.6: No such file or directory /bin/sh: line 1: bin/powerpc-apple-darwin/ghc-6.6: No such file or directory /bin/sh: line 1: bin/powerpc-apple-darwin/ghc-6.6: No such file or directory /bin/sh: line 1: bin/powerpc-apple-darwin/ghc-6.6: No such file or directory chmod: bin/powerpc-apple-darwin/ghc-6.6: No such file or directory Done. Creating a configured version of ghci-6.6 .. /bin/sh: line 1: bin/powerpc-apple-darwin/ghci-6.6: No such file or directory /bin/sh: line 1: bin/powerpc-apple-darwin/ghci-6.6: No such file or directory /bin/sh: line 1: bin/powerpc-apple-darwin/ghci-6.6: No such file or directory /bin/sh: line 1: bin/powerpc-apple-darwin/ghci-6.6: No such file or directory /bin/sh: line 1: bin/powerpc-apple-darwin/ghci-6.6: No such file or directory /bin/sh: line 1: bin/powerpc-apple-darwin/ghci-6.6: No such file or directory /bin/sh: line 1: bin/powerpc-apple-darwin/ghci-6.6: No such file or directory /bin/sh: line 1: bin/powerpc-apple-darwin/ghci-6.6: No such file or directory chmod: bin/powerpc-apple-darwin/ghci-6.6: No such file
Re: [Haskell-cafe] Maintaining the community
Hello, On Friday 13 July 2007 16:45, Ian Lynagh wrote: ... * At any point, create [EMAIL PROTECTED] This would have the advantage that people might not be so intimidated at making their first post here, and posts wouldn't be answered with category theory or scary type extensions. The disadvantages are that it makes an artificial barrier (when is someone ready to post to haskell@ instead?) Just an idea: How about haskell-first-post@ to encourage the second post to go to [EMAIL PROTECTED] Or is that too dictator-like? ... I'm not sure if this is a good idea. I'm not sure either ... ... Best regards Thorkil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maintaining the community
Hello, On Friday 13 July 2007 17:08, Neil Mitchell wrote: Hi * At any point, create [EMAIL PROTECTED] This would have the advantage that people might not be so intimidated at making their first post here, and posts wouldn't be answered with category theory or scary type extensions. The disadvantages are that it makes an artificial barrier (when is someone ready to post to haskell@ instead?) Just an idea: How about haskell-first-post@ to encourage the second post to go to [EMAIL PROTECTED] Or is that too dictator-like? Why not [EMAIL PROTECTED], for people who aren't using Haskell to do things, but are working through tutorials. The idea with haskell-first-post@ would be to make it extremely easy for people to select which list to post to. For example, with a learning list, I would be uncertain myself. Whether it would also be easy for answerers to figure out how to behave, I don't know. In any case, it is important (as others have also said) not to lose the situation that mixes new-comers with experts. A number of questions relate directly to books such as SOE, and these could be easily answered there. Thanks Neil Best regards Thorkil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: The Glasgow-haskell-bugs Archives seems to end at April 2007
Hello, On Sunday 08 July 2007 19:59, Ian Lynagh wrote: On Sun, Jul 08, 2007 at 06:46:10PM +0200, Thorkil Naur wrote: The Glasgow-haskell-bugs Archives http://www.haskell.org/pipermail/glasgow-haskell-bugs/ seem to end at April 2007. Other archives (like http://www.haskell.org/pipermail/glasgow-haskell-users/) seem to extend to the present time of writing. Hmm, I can't see anything obviously wrong in the settings. I've just re-applied them so let's see if this appears in the archives. It didn't, as far as I can tell ... Thanks Ian Best regards Thorkil ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [Haskell-cafe] Literate Priority Queue, plus question
Hello, On Saturday 16 June 2007 14:53, Michael T. Richter wrote: I'm trying my hand at making an improved, more efficient, Sieve of Eratosthenes implementation based on Melissa O'Neil's paper (http://www.cs.hmc.edu/~oneill/papers/Sieve-JFP.pdf) to augment the inefficient not-Sieve I've documented at http://en.literateprograms.org/Sieve_of_Eratosthenes_(Haskell). ... Surely you know this already, but to make absolutely sure: There was a lot of discussion on this subject on this mailing list a while back. Melissa O'Neill's own entry into this is http://www.haskell.org/pipermail/haskell-cafe/2007-February/022666.html as far as I can tell and you can go both forwards and backwards from there. Best regards Thorkil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Haskell install error
Hello, You may find these details useful: http://www.haskell.org/pipermail/glasgow-haskell-users/2007-May/012576.html (This is referred from the ghc 6.6.1 download page http://haskell.org/ghc/download_ghc_661.html.) Best regards Thorkil On Thursday 31 May 2007 14:06, schulzy wrote: Hello I am a relativly new Mac user and need to use the Haskell 6.6 for a project. I downloaded the binary install file from the Haskell download site unpakaged it, ran the ./configure, and the make install both as admin and they both were sucessful. When i then try and run the ghci compiler i get the following error: dyld: Library not loaded: /usr/local/lib/libreadline.5.2.dylib Referenced from: /usr/local/lib/ghc-6.6/ghc-6.6 Reason: image not found Trace/BPT trap I was hoping someone could walk me through a solution. I currently have the haskell 6.4 compiler on my computer. Sincerly Schulzy -- View this message in context: http://www.nabble.com/Haskell-install-error-tf3846179.html#a10892594 Sent from the Haskell - Glasgow-haskell-bugs mailing list archive at Nabble.com. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[Haskell-cafe] How to selectively export internal entities from a module for testing?
Hello, It is common practice to export only selected entities from a Haskell module and refrain from exporting other entities so that they are only available for internal use. There are many reasons for wanting to do this, such as reducing the number of importable entities, avoiding the exposure of internal details that may therefore more easily be changed, and to enable certain optimizations (http://haskell.org/haskellwiki/Performance/Modules). However, for one particular use, namely automated testing, it often seems useful, even necessary, to allow even entities considered internal to be exported: If internal entities cannot be imported by the testing code, they can only be tested indirectly, via the exported entities, and that may turn out to be troublesome. A possibility would be to include the testing code in the module itself, but that seems clumsy and wasteful. For possible guidance, I have looked at http://darcs.haskell.org/packages/filepath and System/FilePath/Internal.hs contains -- Note: leave this section to enable some of the tests to work #ifdef TESTING -- * Drive methods splitDrive, joinDrive, takeDrive, replaceDrive, hasDrive, dropDrive, isDrive, #endif precisely to allow automated testing. And that, of course, solves the problem. But I am wondering whether other solutions to this problem could be found, perhaps even solutions that stay within the limits of the Haskell language itself? If anybody know of alternative solutions, I would very much like to hear about them. Thanks and best regards Thorkil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] k-minima in Haskell
Hello, My Hugs tells me this: Prelude let sort [] = []; sort l@(x:_) = filter (x) l ++ filter (==x) l ++ filter (x) l in sort [1,3,2] [1,3,2] Prelude So, no, this is not a working sorting function. Inserting the few missing recursive calls: Prelude let sort [] = []; sort l@(x:_) = sort ( filter (x) l ) ++ filter (==x) l ++ sort ( filter (x) l ) in sort [1,3,2] [1,2,3] Prelude Best regards Thorkil On Friday 13 April 2007 11:38, Thomas Hartman wrote: And for reference, here is again stefan's stable quicksort from his earlier post. sort [] = [] sort l@(x:_) = filter (x) l ++ filter (==x) l ++ filter (x) l (A stable quicksort, btw) This is the code whose legitimacy I am requesting confirmation of. 2007/4/13, Thomas Hartman [EMAIL PROTECTED]: You may be missing a few recursive calls there :-) Indeed. ... ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
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. ghc: 19113508 bytes, 4 GCs, 123616/123616 avg/max bytes residency (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. ghc: 25147464 bytes, 4 GCs, 123268/123268 avg/max bytes residency (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: [Haskell] Generator Function for Prime Numbers
Hello, On Tuesday 13 March 2007 00:40, Jacques Carette wrote: And yet Taral would be wrong and Dave Feustel correct: http://mathworld.wolfram.com/Prime-GeneratingPolynomial.html I wouldn't say that a polynomium applies as using only addition and subtraction. There is a polynomial (of degree 25) in 26 variables which generates only primes whenever it is positive. Surprising, yes it is. Note that this polynomial is actually rarely positive! Yes, and as noted in the Prime-GeneratingPolynomial reference, it is really a set of diophantine equations (equations where only integer/natural/rational solutions qualify) in disguise. In fact, if I remember correctly, one of the variables that you have to stick into the polynomium is one less (or some such) than the prime that you get out. So as a prime generating device, it is rather useless. The idea of defining sets of numbers by diophantine equations was used in 1970, to prove one of the 10th of Hilberts famous 23 problems from 1900 impossible. See http://en.wikipedia.org/wiki/Matiyasevich's_theorem Jacques Taral wrote: Not bloody likely. On 3/12/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I have heard that a generator function has been found that generates prime numbers directly using only addition and subtraction. There purportedly have been presentations of this information to selected mathematicians who have verified that the generator function works. But I haven't found any confirmation by googling. Has anyone got wind of this? Thanks, Dave Feustel ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell Best regards Thorkil ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Bug: --make non-functional on GHC compiler
Hello, Try to change the line module CutParse(main) where in Main.hs to module Main(main) where Best regards Thorkil On Saturday 10 March 2007 18:08, Samuel A. Falvo II wrote: Required Information: 1. What kind of machine are you running on, and exactly what version of the operating system are you using? (on a Unix system, uname -a or cat /etc/motd will show the desired information.) $ uname -a Linux aldeberan 2.6.16.13-3c95x #3 PREEMPT Tue May 2 23:16:59 PDT 2006 i686 unknown unknown GNU/Linux 2. What version of GCC are you using? gcc -v will tell you. bash-2.05b$ gcc -v Reading specs from /usr/lib/gcc-lib/i486-slackware-linux/3.3.4/specs Configured with: ../gcc-3.3.4/configure --prefix=/usr --enable-shared --enable-threads=posix --enable-__cxa_atexit --disable-checking --with-gnu-ld --verbose --target=i486-slackware-linux --host=i486-slackware-linux Thread model: posix gcc version 3.3.4 3. Run the sequence of compiles/runs that caused the offending behaviour, capturing all the input/output in a script (a UNIX command) or in an Emacs shell window. We'd prefer to see the whole thing. bash-2.05b$ cat Main.hs module CutParse(main) where main :: IO () main = do putStr Hello world! bash-2.05b$ ghc --make -v Main Glasgow Haskell Compiler, Version 6.4.1, for Haskell 98, compiled by GHC version 6.2.2 Using package config file: /usr/local/lib/ghc-6.4.1/package.conf Hsc static flags: -static *** Chasing dependencies: Chasing modules from: Main Stable modules: *** Compiling CutParse ( Main.hs, interpreted ): compile: input file Main.hs *** Checking old interface for CutParse: Compiling CutParse ( Main.hs, Main.o ) *** Parser: *** Renamer/typechecker: *** Desugar: Result size = 30 *** Simplify: Result size = 6 *** Tidy Core: Result size = 6 *** CorePrep: Result size = 8 *** Stg2Stg: *** CodeGen: *** CodeOutput: *** Assembler gcc -I. -c /tmp/ghc11833.s -o Main.o *** Deleting temp files Deleting: /tmp/ghc11833.s Upsweep completely successful. *** Deleting temp files Deleting: link(batch): upsweep (partially) failed OR Main.main not exported; not linking. *** Deleting temp files Deleting: bash-2.05b$ ls Main.hi Main.hs Main.o NOTE: I have verified this problem exists with both the GHC 6.2.2 and 6.4.1 compilers. I do not yet have 6.6.x due to the hours it takes to compile on my box. 5. What is the program behaviour that is wrong, in your opinion? According to two sources: * http://haskell.org/ghc/docs/6.4/html/users_guide/modes.html#make-mode * ghc --help I should be able to simply invoke the --make option to have it build a complete program. The program was reduced to a simple Hello world program for the sake of demonstration in this bug. However, nothing I do convinces GHC to produce an executable, as per provided documentation. Folks on IRC also suggested using the --main-is= flag, as follows: bash-2.05$ ghc --make -v --main-is=Main.main Main however, this also produces the same result -- no executable binary. 6. If practical, please send enough source files for us to duplicate the problem. See attached file. I should point out that, in all honesty, I think this is a bug with the documentation more than a bug with GHC itself; clearly, GHC 6.2.2 was used to *build* GHC 6.4.1, so it MUST be possible to emit binaries. The trick is giving it the right options to do so. My thinking is that the documentation is not correct in this area. Alternatively, --make itself may be buggy, and that GHC 6.4.1 was built without using it. Either way, there is a fundamental disconnect between docs and reality. :) Thank you. -- Samuel A. Falvo II ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [Haskell-cafe] Re: Code and Perf. Data for PrimeFinders(was:Genuine Eratosthenes sieve)
Hello all felllow primefinders, I have followed this discussion of Haskell programs to generate small primes with the greatest interest. The thing is, I have been running my Haskell implementation of the so-called Elliptic Curve Method (ECM) of factoring for a number of years. And that method uses a sequence of small primes, precisely like the one discussed here. I have been using the method of trial division to generate primes for the ECM. I have been aware that sieving would very likely be more efficient, but since the amount of time spent generating small primes is, after all, not an extremely large part of running the ECM program, I have postponed the task of looking into this. So this discussion of Eratostenes' sieve has provided a most wonderful opportunity to do something about this. Initially, I wanted to establish some sort of base line for generating small primes. This I did by writing my own C program for generating small primes, both using sieving and trial division. The result was most sobering: Finding primes with sieving with a C program is much faster than finding them with trial division. The speed advantage factor of sieving over trial division for small numbers (say, finding the first couple of hundred thousand primes) is around 5 and it gets larger with larger numbers. (I will not quote specific measurements here, only rough tendencies. Details clutter and Melissa is much better at this anyway. I would like to state, however, that I am, in fact, measuring performance accurately, but I use ancient machinery that runs slowly: Measuring performance on fast equipment often tends to cloud significant issues, in my experience.) So there is my goal now: Find a Haskell program that generates small primes that is around 5 times faster than the one I have already that uses trial division. And I mean a Haskell program, not a C program that gets called from Haskell. Sure, if I wanted ultimate performance, I could perhaps just call some C code from Haskell. But the insistance on pure Haskell widens the perspective and makes it more likely that the programmer or the language designer and implementer learn something valuable. The C sieving program uses an array to attain its impressive performance, so let us try that in Haskell as well. Something like this has been on my mind for a long time: accumArray (\x -\y -False) True (m,n) [(q,()) | q-ps ] Haskell arrays, like every other value, cannot be changed, but accumArray provides a facility that we just might manage to use for our purpose. The particular array computed by the above expression using accumArray requires a low and high limit (m,n) of the numbers to be sieved as well as a list of sieving values - ps - numbers that need to be crossed out as composite in the interval (m,n) given. [The overhead involved in evaluating this expression with its unused () value and an indicator that is changed from True to False through throwing away two dummy values seems excessive. Any suggestion to write this up in a way that is more in agreement with the small amount of work that is actually required to do this would be most welcome. Or perhaps GHC (which is the compiler I use when I want things to run fast) takes care of things for me? In any case, this is my inner loop and even small improvements will matter.] When I tried this initially, I was actually not particularly surprised to find that it performed rather worse than trial division. Although I am unable to give a precise explanation, the GHC profiling runs indicated that, somehow, too much memory was accumulating before it was used, leading to thrashing and perhaps also a significant amount of overhead spent administering this excessive amount of memory. The initial sieve that I used had a fixed size that covered all the numbers that I wanted to test. An improvement might come about by splitting this sieve into smaller pieces that were thrown away when no longer needed. OK, what pieces? Well, a possibility would be to use the splitting of all integers into subsequences that matched the interval between squares of consecutive primes, because that would match the entry of a new prime into the set of primes that needs to be taken into consideration. And this actually worked rather well. In addition, the problem solved was now the one of expressing the generation of an infinite sequence of primes, not just the primes within some predetermined interval. Further (yes, you will get the code eventually, but be patient, I don't want to have to present more than the final version), there was the wheel idea also used by Melissa of somehow eliminating from consideration all the numbers divisible by a few of the smallest primes: If we, for example, could get away with considering only the odd numbers as candidates for being primes, this would potentially save half the work. This I didn't find to be an easy idea to implement. Essentially what I
Re: [GHC] #1171: GHC doesn't respect the imprecise exceptions semantics
Hello, The code in YHC is roughly if some list is empty then error No files found else error Many files found. If this code were changed to the equivalent of error (if some list is empty then No files found else Many files found), would there still be circumstances where the actual output produced could vary? Thanks and best regards Thorkil On Wednesday 28 February 2007 12:31, Simon Marlow wrote: Neil Mitchell wrote: Hi In response to Neil: why use `unsafePerformIO` rather than IO exceptions here? I think you're asking for more trouble... Are you referring to ioError? My knowledge of exceptions in Haskell is limited. The error architecture is often a long way from the IO monad, so whatever we do can't require the IO monad. Yes - the example was in the IO monad so I thought you could use IO exceptions. In any case, I don't recommend using 'error' (or indeed 'unsafePerformIO') for errors you report to the user, purely because of its non-deterministic semantics. If you use a suitable error monad or IO exceptions, you can be sure that you'll get the same behaviour regardless of compiler or optimisation settings. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [Haskell] Checking out the whole source tree
Hello, On Tuesday 13 February 2007 08:09, Donald Bruce Stewart wrote: hoelz: I recently checked out the X11 package from darcs.haskell.org, and I'd like to check out more of the source from the darcs repository. I'm still unfamiliar with darcs; how do I check out the whole source tree? Thanks, Rob Hoelz ... for GHC and a base set of libraries, you can get that source directly by following these instructions: http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources Other libraries and tools can be picked up as needed. You'll find links to these things on hackage, http://hackage.haskell.org/packages/archive/pkg-list.html and on haskell.org's libraries page. -- Don ... For Hugs, follow the instructions here: http://hackage.haskell.org/trac/hugs/wiki/GettingTheSource You will need cvs instead of darcs, however. For Yhc, follow: http://haskell.org/haskellwiki/Yhc/Building In each case, various tool are needed in case you wish to build the respective tool, but they are mentioned in the instructions and at least I have managed to fumble my way through. There are additional Haskell implementations mentioned on http://haskell.org/haskellwiki/Implementations Best regards Thorkil ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Fractional sqrt
Hello, On Friday 19 January 2007 16:48, [EMAIL PROTECTED] wrote: ... sqrtApprox' :: Integer - Rational sqrtApprox' n | n 0 = error sqrtApprox' | otherwise = approx n 1 where approx n acc | n 256 = (acc%1) * approxSmallSqrt (fromIntegral n) | otherwise = approx (n `div` 256) (acc*16) ... In the Haskell report section 14.4 (and also e.g. in GHC.Float), we find -- Compute the (floor of the) log of i in base b. -- Simplest way would be just divide i by b until it's smaller then b, but that would -- be very slow! We are just slightly more clever. integerLogBase :: Integer - Integer - Int integerLogBase b i | i b = 0 | otherwise = doDiv (i `div` (b^l)) l where -- Try squaring the base first to cut down the number of divisions. l = 2 * integerLogBase (b*b) i doDiv :: Integer - Int - Int doDiv x y | x b = y | otherwise = doDiv (x `div` b) (y+1) Something like this could probably be used to find a suitable sqrt approximation for an Integer: sqrtApproxViaLog i = 2^(integerLogBase 2 i `div`2) Best regards Thorkil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
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 ghc: 8975060 bytes, 3 GCs, 9280/9280 avg/max bytes residency (1 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 `#' ghc: 5250952 bytes, 3 GCs, 5688/5688 avg/max bytes residency (1 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: 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: 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 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. The problem I face is: performance at which level? The low-bit-size (low precision) range or the high precision range? Two problems seem to be lurking here: The first is that, although taking a copy of some
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: 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: [Haskell-cafe] Mozart versus Beethoven (was: Writing Haskell For Dummies ...)
Hello, In the spring of 1978, I wrote a (circa) 700-word microprogram for multiprecision integer arithmetic on paper, typed it into a computer, had it cleaned of syntax errors by the micro-code assembler, printed it, and spent much of the summer in my mother's summer house debugging this program text by hand, without the use of any automated computing device of any kind. I found lots of errors, corrected them, rechecked the result by hand, found additional errors, corrected those and, finally, (in the autumn of 1978) ran the program for the first time. Every multiprecision integer operation but division worked. After some debugging, a single (rather silly) error was found in the division routine. I never found additional errors in this code. This is not intended to imply that I am a Mozart rather than a Beethoven (most likely neither!) in the field of programming. Rather, it is an attempt to point out that the development environments that we use these days encourage a completely different mode of work than what was used some 20-30 years ago. Thus, today, I do like I have the impression most programmers do, compile and run (tests) as often as possible, even every very few keystrokes of code changes. I am not an expert in the difference between composers like Mozart and Beethoven, but my expert father tells me that Mozart, reputedly, had a phenomenal musical memory that allowed him both to recall large sequences of music played to him and, undoubtably also, work with long sequences of hypothetical music, that is, music being composed, for prolonged periods, in his head, without the need to make any notes on paper etc. It seems that such differences in modes of work does not imply any similar interesting or usefully utilizable difference in the way we should produce our programs. The analogy seems irrelevant, in other words. Best regards Thorkil On Tuesday 12 December 2006 12:07, Kirsten Chevalier wrote: ... I've been thinking about this. Are there really any programmers who are like Mozart in the way you describe? Donald Knuth might be one, or at least, he wrote that he wrote and debugged all of TeX on paper before entering it into a computer and only found 13 more bugs (or something like that), once he did. I don't remember if it was 13 exactly, but 13 more bugs might be the closest that any programmer gets to Mozart, or at least any programmer in the 20th or early 21st century. ... Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt What is research but a blind date with knowledge? -- Will Henry ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Fix ghc-6.6 darcs-all for Mac OS X 10.4
Hello,
The following patch fixes ghc-6.6 darcs-all for Mac OS X 10.4.
Best regards
Thorkil
New patches:
[Fix darcs-all for Mac OS X
Thorkil Naur [EMAIL PROTECTED]**20061123125539
The regular exporession /\? which is used by darcs-all to stand for zero or one /'s
seems to be a GNU extension of basic regular expressions. In any case, it is not
supported by sed on Mac OS X 10.4.
The patched darcs-all works on Max OS X and (SuSE) Linux.
] {
hunk ./darcs-all 13
-default_extra_repo_root=`echo $default_repo_root | sed 's!/ghc-6.6/\?$!!'`
+default_extra_repo_root=`echo $default_repo_root | sed 's!/ghc-6.6/\{0,1\}$!!'`
}
Context:
[cas(): modify assembly syntax to make it work everywhere (hopefully)
Simon Marlow [EMAIL PROTECTED]**20061121132646]
[Fix printf$LDBLStub workaround for Darwin
[EMAIL PROTECTED]
Apparently, the original fix never really worked due to typos and oversights.
]
[Add ppr for the MKPAP case, and rearrange the other cases to match the datatype
Ian Lynagh [EMAIL PROTECTED]**20061120155352]
[Avoid problems with unaligned loads on alpha/mips/mipsel/arm
Ian Lynagh [EMAIL PROTECTED]**20061120154914
This is overly conservative, but it works.
]
[Add a C++ phase. Fixes bug #800
Lemmih [EMAIL PROTECTED]**20060727080023]
[Don't force -static on mips
Ian Lynagh [EMAIL PROTECTED]**20061120122305]
[MERGE: Don't make ghc threaded if GhcNotThreaded is YES
Ian Lynagh [EMAIL PROTECTED]**20061120121855]
[Cope with big endian float word order on little endian machines
Ian Lynagh [EMAIL PROTECTED]**20061120121309]
[Fix unregisterised alpha builds
Ian Lynagh [EMAIL PROTECTED]**20061004125857]
[use lock cmpxchg instead of lock/cmpxchg
Simon Marlow [EMAIL PROTECTED]**20061117114429
I'm not sure where the latter version came from, but it apparently
doesn't generate a legal instruction on Solaris.
]
[MERGE: Fix (yet another) odd interaction between selector thunks and compacting GC
Ian Lynagh [EMAIL PROTECTED]**20061115135020
Tue Nov 14 12:31:57 GMT 2006 Simon Marlow [EMAIL PROTECTED]
* Fix (yet another) odd interaction between selector thunks and compacting GC
This should fix errors of the form
internal error: scavenge_mark_stack: unimplemented/strange closure
type 28 @ 0x2b92e5f79960
But since it's quite difficult to reproduce the error, I can't be 100%
certain it's gone. I certainly can't reproduce it again after the
fix, anyway.
]
[Fix compilation problems
Ian Lynagh [EMAIL PROTECTED]**20061115015300]
[Default the kind of unconstrained meta-type variables before tcSimplifyTop
[EMAIL PROTECTED]
This patch fixes a long standing bug, Trac #179,
and a recently reported one, Trac #963.
The problem in both cases was an unconstrained type variable 'a', of kind
argTypeKind (printed ??) or openTypeKind (?). At top level we now default
the kind of such variables to liftedTypeKind (*). This is important because
then instance declarations can match it. The defaulting function is called
TcMType.zonkTopTyVar, and is commented. (Most of the extra lines in the
patch are comments!)
]
[MERGE: Fix error reporting for contexts during deriving (Trac 958)
Ian Lynagh [EMAIL PROTECTED]**20061115005551
[EMAIL PROTECTED]
When doing the fixpoint iteration for 'deriving' we have to be careful
not to end up in a loop, even if we have -fallow-undecidable-instances.
Test is tcfail169
]
[Improve error message (push to 6.6 branch)
[EMAIL PROTECTED]
[Improve handling of unused imports (test is mod75)
[EMAIL PROTECTED]
[Remove STANDALONE_PACKAGE bits that had escaped the removal
Ian Lynagh [EMAIL PROTECTED]**20061110182050]
[use the right $(HC) for stage 3
Simon Marlow [EMAIL PROTECTED]**20061109101753]
[remove unused STANDALONE_PACKAGE stuff
Simon Marlow [EMAIL PROTECTED]**20061109101729]
[Do not filter the type envt after each GHCi stmt
[EMAIL PROTECTED]
Fixes Trac #925
A new comment in TcRnDriver in tcRnStmt reads thus:
At one stage I removed any shadowed bindings from the type_env;
they are inaccessible but might, I suppose, cause a space leak if we leave them there.
However, with Template Haskell they aren't necessarily inaccessible. Consider this
GHCi session
Prelude let f n = n * 2 :: Int
Prelude fName - runQ [| f |]
Prelude $(return $ AppE fName (LitE (IntegerL 7)))
14
Prelude let f n = n * 3 :: Int
Prelude $(return $ AppE fName (LitE (IntegerL 7)))
In the last line we use 'fName', which resolves to the *first* 'f'
in scope. If we delete it from the type env, GHCi crashes because
it doesn't expect that.
]
[MERGE: Figure out where the rest of the repositories are, based on defaultrepo
Ian Lynagh [EMAIL PROTECTED]**2006141531]
[move newSpark() prototype to RtsExternal.h to avoid warnings
Simon Marlow [EMAIL PROTECTED]**20061107115430]
[In hashExpr, use Word32 rather than relying on wrapping behaviour of Int
Simon Marlow [EMAIL PROTECTED]**20061020153925
Fixes #952
Re: [GHC] #1004: ghci-6.6 crash on PPC
Hello,
I tried to reproduce this. Here is the result:
Thorkil-Naurs-Computer:~/tn/tmp/GHC/trac/#1004: ghci-6.6 crash on
PPC/ghc-6.4.1
thorkilnaur$
/Users/thorkilnaur/tn/GHCDarcsRepository/ghc-6.6/ghc/compiler/stage2/ghc-inplace
--interactive Checksum.hs
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\/\/ /_/\/|_| Type :? for help.
Loading package base ... linking ... done.
Checksum.hs:12:8:
Could not find module `Utils':
Use -v to see a list of the files searched for.
Failed, modules loaded: none.
Prelude :q
Leaving GHCi.
After editing Checksum.hs to remove import Utils:
Thorkil-Naurs-Computer:~/tn/tmp/GHC/trac/#1004: ghci-6.6 crash on
PPC/ghc-6.4.1
thorkilnaur$
/Users/thorkilnaur/tn/GHCDarcsRepository/ghc-6.6/ghc/compiler/stage2/ghc-inplace
--interactive Checksum.hs
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\/\/ /_/\/|_| Type :? for help.
Loading package base ... linking ... done.
[1 of 1] Compiling Main ( Checksum.hs, interpreted )
Checksum.hs:82:36: Not in scope: `splitWord'
Failed, modules loaded: none.
Prelude
Could something be missing from your report?
Best regards
Thorkil
On Tuesday 14 November 2006 15:23, GHC wrote:
#1004: ghci-6.6 crash on PPC
+---
Reporter: [EMAIL PROTECTED] | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: GHCi | Version: 6.6
Severity: normal |Keywords:
Difficulty: Unknown |Testcase:
Architecture: powerpc | Os: MacOS X
+---
During a long (10 to 15 minute) run of a communication system simulation,
I noticed had occasional crashes of ghci with the output
{{{
interactive: internal error: interpretBCO: unknown or unimplemented
opcode 1028
(GHC version 6.6 for powerpc_apple_darwin)
Please report this as a GHC bug:
http://www.haskell.org/ghc/reportabug
Abort trap
gregory-wrights-powerbook-g4-17
}}}
or
{{{
interactive: internal error: interpretBCO: unknown or unimplemented
opcode 1033
(GHC version 6.6 for powerpc_apple_darwin)
Please report this as a GHC bug:
http://www.haskell.org/ghc/reportabug
Abort trap
a83-245-238-133
}}}
or
{{{
interactive: internal error: interpretBCO: unknown or unimplemented
opcode 1040
(GHC version 6.6 for powerpc_apple_darwin)
Please report this as a GHC bug:
http://www.haskell.org/ghc/reportabug
Abort trap
a83-245-238-133
}}}
The same code when compiled would run to completion.
I could not post the original code because it contained proprietary
customer information. However, I have been able to isolate a much smaller
case which also fails.
The module below, which computes a 16 bit checksum function, fails when
run under
ghci with
{{{
[9,120,46,192,248,87,242,122,183,2,96,217,164,46]
85:
[203,223,98,240,74,91,106]
86:
[78,239,201,3,74,238,146,170,71]
87:
[46,128,19,27,218,48,10,148test aborted: loop
*Main
}}}
The same code runs to completion when compiled:
{{{
[15,76,203,225,63,86,10,21,39,140,91,244,38,101,10,197,212,24,242,50,105,139,139,210,108,79,185,171,127,232,57,37,77,234,164,47,175,91,78,198,237,253,153,83,159,7,11,30,138,150,19,68,10,234,46,101,39,146,46,164,52,54,109,163,46,174,22,46,61,43,234,125,148,182,188,19,4,48,84,227,57,156,152,55,235,211,204,10,104,170,40,209,174,238,200,16,82,204,203,133,196,42,146,8,66,171,67,142,208,67,67,37,237,48,249,99,212,152,79,52,136,104,187,218,6,73,174,244,146,118,202,141,26,79,34,91,10,167,41,244,151,47,28,35,181,199,244,233,221,118,64,53,59,245,245,166,255,86,124,37,192,175,203,184,52,155,141,66,247,227,51,40,154,150,9,121,215,237,21,23,60,83,31,27,23,128,18,83,17,119,136,73,46,60,242,79,190,189,56,154,229,47,92,242,81,157,251,51,27,4,93,213,103,176,144,43,12,187,5,85,109,42,194,214,30,110,129,129,197,97,239,210,133,201,180,207,123,120,62,106,47,30,1,207,30,213,219,210,158,67,101,164,149,85,6,138,52,55,64,160,85,119,132,247,226,255,29,3,122,235,217,228,83,197,157,41,208,138,23,152,48,93,53,223,40,168,17,129,29,48,250,31,136,4,213,136,178,70,10,207,43,48,69,157,71,31,119,137,137]
997:
[48,92,91,80,79,62,248,169,156,171,156,102,154,114]
998:
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 than my ECM code.
Generalized Su Doku solver (was: [Haskell-cafe] Polymorphic Sudoku solver)
Hello, Inspired by this, I have added my Su Doku solver to http://www.haskell.org/haskellwiki/Sudoku. Regards Thorkil Naur On Wednesday 31 May 2006 18:32, Chris Kuklewicz wrote: A while back there was a long thread about Sudoku solvers (some of which ended up on http://haskell.org/haskellwiki/Sudoku ). I contributed my brute-force dancing links solver at the time, and mentioned that I had a by-logic solver that, while a bit slow, was as good as most of those being discussed. At the time the code for my solver was too ugly to post. Attached is a cleaned up version. ... Chris Kuklewicz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] String to binary tree
Hello, Both my Hugs and my GHCi report a type error when presented with this. A possible repaired version looks like this: calc :: String - Float calc = g . foldl f [] . words where f (x:y:zs) + = y+x:zs f (x:y:zs) - = y-x:zs f (x:y:zs) * = y*x:zs f (x:y:zs) / = y/x:zs f xs y = read y : xs g [r] = r Not as small, but still quite nice. Regards Thorkil On Tuesday 30 May 2006 15:10, Sebastian Sylvan wrote: A bit OT perhaps, but I'd just like to point out this wonderful little code snippet from the Haskell wiki-page that I've always liked, in case nobody's seen it: calc :: String - Float calc = foldl f [] . words where f (x:y:zs) + = y+x:zs f (x:y:zs) - = y-x:zs f (x:y:zs) * = y*x:zs f (x:y:zs) / = y/x:zs f xs y = read y : xs That's it. An RPN evaluator in a couple of lines. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] String to binary tree
Hello, It seems that what you need is the technique of evaluating an expression in reverse polish notation by using a stack. This technique is well known in subjects related to compiler construction. Basically, the expression (list of operands and operators) is processed sequentially from left to right. If an operand (in your case: A character c for which isNumber c is true) is encountered, it is pushed onto the stack. If an operator (in your case: A character c for which isLetter is true) is enountered, it pops its operands (one or more) from the top of the stack and pushes the result of applying the operator to the operands back onto the stack. The following code sketch uses this idea: ... import Char ... isNumber = isDigit isLetter = isAlpha cvBase stack c | isNumber c = Folha c:stack cvBase (tr:tl:stack) c | isLetter c = Node c tl tr : stack cv s = let [t] = foldl cvBase [] s in t Example using Hugs: Main cv 12H3V Node 'V' (Node 'H' (Folha '1') (Folha '2')) (Folha '3') Main Regards Thorkil Naur On Monday 29 May 2006 20:53, Nuno Santos wrote: Hi, I have this type which represents polish expressions (floorplan representation): data PeAux a = Folha Char | Nodo Char (PeAux a) (PeAux a) deriving Show The reverse polish expression are the result of doing a post order visit to the tree One example of this reverse polish expression is 12H3V and a example of tree is pe5 = Node 'V' (Node 'H' (Folha '1') (Folha '2')) (Folha '3') the tree above is the same as the expression 12H3V What i need and i cant do is turn the expression a tree again... I have done the following: converteAux [] (x,y) = (x,y) converteAux (a:t) (x,y) | ((length (a:t))3) = converteAux [] (x,y ++ (a:t)) converteAux (a:b:t) (x,y) | ((length (a:b:t))3) = converteAux [] (x,y ++ (a:b:t)) converteAux (a:b:c:t) (x,y) | (isNumber a) (isNumber b) (isLetter c) = converteAux t (x ++ [(Nodo c (Folha a) (Folha b))],y) | otherwise = converteAux (b:c:t) (x,y++[a]) The strategy followed is to recognize operand, operand, operator and then put it as a basic element in a list, for instance, 12H - Node 'H' (Folha '1') (Folha '2') And at the end put it togheter in one tree. ( not done yet) But i'm getting to the conclusion that it doesnt cover every case... Can anybody give me a light here? Many thx, Best regards, Nuno Santos ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
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 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
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
/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 ghc: 14519528 bytes, 3 GCs, 172816/172816 avg/max bytes residency (1 samples), 15M in use, 0.01 INIT (0.00 elapsed), 0.01 MUT (36.43 elapsed), 0.02 GC (0.02 elapsed) :ghc 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
. For the record: [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
