Re: *BSD support in 6.8.3
Simon Marlow [EMAIL PROTECTED] schrieb: So, try the patch to get the patch to compile against ghc 6.8.3-snapshot, and see if it works on OpenBSD? It's not just a case of testing the patch, there are a couple of issues to address: - it has a couple of wired-in addresses: one place to load object files, another to put jump tables at. This is necessary because *BSD doesn't have the MAP_32BIT flag for mmap(). However, the particular wired-in addresses needed will probably vary on the different *BSDs. Someone needs to look at the memory map and make sure we're picking sensible addresses. It is not very likely that the adresses change between *BSDs because they are resulting from simple hardware-related constraints. Though, a test is necessary. OTOH, has anybody from the GHC team asked the *BSD developers to add a MAP_32BIT flag already? I know that these people are very reluctant to change requests, this one may find their mercy if the right persons ask for it. - the patch doesn't #ifdef its changes, so it'll break other platforms (easy to fix). I looked into the patch, and it doesn't look as if it would break other platforms, as the changed code is inside proper ifdefs mostly. Some parts may be superfluous. The easiest check is to compile the FreeBSD-patched code under one of the other platforms (are there other than Linux and OSX?). In any case, the ifdef'ing can be automated using diff with -D__FreeBSD__ option. Also the code has changed in HEAD, and we need a completely different patch there (although the same idea applies, pick an address and use MAP_FIXED). This is, of course, the most significant problem for GHC, but probably not relevant to this special release process. It is better to include the patch than to leave it out (provided that I am right resp. to the breaking of otherplatforms). -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-373 PGP: http://vestein.arb-phys.uni-dortmund.de/~wb/mypublic.key ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell-cafe] Re: floating point operations and representation
Jacob Schwartz [EMAIL PROTECTED] schrieb: I have two questions about using the Double data type and the operations in the Floating typeclass on a computer that uses IEEE floating point numbers. I notice that the Floating class only provides log (presumably log base 'e') and logBase (which, in the latest source that I see for GHC is defined as log y / log x). However, in C, the math.h library provides specific log2 and log10 functions, for extra precision. A test on IEEE computers (x86 and x86-64), shows that for a range of 64-bit double values, the answers in C do differ (in the last bit) if you use log2(x) and log10(x) versus log (x) / log(2) and log(x) / log(10). This is to be expected in about 25% of cases, as the GHC definition rounds two times, whereas the implementation provided in the SUN math library (file lib/msun/src/e_log10.c on FreeBSD) uses a representation in two doubles for log(10) to avoid one of the rounding errors: * Return the base 10 logarithm of x * * Method : * Let log10_2hi = leading 40 bits of log10(2) and * log10_2lo = log10(2) - log10_2hi, * ivln10 = 1/log(10) rounded. * Then * n = ilogb(x), * if(n0) n = n+1; * x = scalbn(x,-n); * log10(x) := n*log10_2hi + (n*log10_2lo + ivln10*log(x)) -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 PGP: http://vestein.arb-phys.uni-dortmund.de/~wb/mypublic.key ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: A question about monad laws
[EMAIL PROTECTED] [EMAIL PROTECTED] schrieb: G'day all. Richard A. O'Keefe wrote: Hmm. Personally, I've never seen an algorithm where comparing for exact equality was algorithmically necessary. One trick I've occasionally used is to avoid the need for a discriminated union of floating point and integer types by just using a floating point number. IMHO it is a perfectly good idea to use the FP processor for integer computations. You can use the Inexact Trap as Overflow Exception, a service you don't get from i386 (and most other) hardware for int operations. Of course your integers are limited to 24bit+sign in single precision and 54bit+sign in double. In i387 extended precision you get 64bit+sign. I would consider a good idea if ghc would provide language support to this sort of integers. -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 PGP: http://vestein.arb-phys.uni-dortmund.de/~wb/mypublic.key ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: A question about monad laws
Ben Franksen [EMAIL PROTECTED] schrieb:
Wilhelm B. Kloke wrote:
[EMAIL PROTECTED] [EMAIL PROTECTED] schrieb:
I would consider a good idea if ghc would provide language support to
this sort of integers.
No need, you can do that for yourself:
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
newtype DInt = DInt Double deriving (Eq, Ord, Enum, Num)
instance Show DInt where show (DInt x) = show (truncate x :: Integer)
Probably you missed the point I wanted to make. This works only properly,
if you can catch the Inexact Trap which indicates the overflow. The problem
whith normal Ints is that the hardware does not support overflow detection.
You get silent wrong results if you use an Int type which maps to
C int, but not if it maps to C float or double with Inexact trap enabled.
Therefore you need add runtime checks to be sure that you notice
a possible overflow condition.
--
Dipl.-Math. Wilhelm Bernhard Kloke
Institut fuer Arbeitsphysiologie an der Universitaet Dortmund
Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257
PGP: http://vestein.arb-phys.uni-dortmund.de/~wb/mypublic.key
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why purely in haskell?
Wolfgang Jeltsch [EMAIL PROTECTED] schrieb: However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking. It doesn?t adhere to any meaningful axiom set for Eq. So I think that this behavior should be changed. Think of a set implementation which uses (==) to compare set elements for equality. The NaN behavior would break this implementation since it would allow for sets which contain NaN multiple times. You forget, that the intention of NaN is denial of membership of any set of numbers. -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 PGP: http://vestein.arb-phys.uni-dortmund.de/~wb/mypublic.key ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: GHC 6.8.1 port on FreeBSD-amd64?
Matthias Kilian [EMAIL PROTECTED] schrieb: On Sun, Jan 06, 2008 at 05:20:18PM +, Ian Lynagh wrote: Prologue junk?: .type s32x_ret, @function s32x_ret: pushl %ebp movl%esp, %ebp I see nearly the same problem with ghc-6.8.2 on OpenBSD, using the gcc-3.3.5 included in its base system. Presumably this also happens if you do a normal build with -fvia-C, i.e. it's not specific to building from an HC file bundle? That's right, it's just -fvia-C that triggers the bug. This is not quite the case. I compiled even with -fvia-C without errors on FreeBSD-amd64. This bug is specific for the bootstrap with crosscompiling i386 - amd64 vi .hc-bundle. -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 PGP: http://vestein.arb-phys.uni-dortmund.de/~wb/mypublic.key ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
New woes regarding ghc-6.8.1 on FreeBSD-amd64
Some days ago I announced having success in porting ghc-6.8.1 to FreeBSD-7.0-amd64. As the compiler seemed to be able to compile itself, I was confident to make the binary package available to the public. Now I have found out that the port is rooten in a very weird way. From the files in testsuite (6.6.1) it has 4707 expected passes vs. 669 unexpected failures. Among the most unexpected of these is the failure of arith003 (conversions between Int and Integer near 64bit boundary). It seems there is still some 32/64-bit confusion left from the building process. Still worse is, that any attempt to use the partially usable compiler as bootstrap tool fails for some reasons. On a freshly configure 6.8.1 tree (with ./configure --with-gmp-includes=/usr/local/include --with-gmp-libraries=/usr/local/lib ) the build process fails at libraries/base/Control/Concurrent.hs because gmp.h is not found by ghc-inplace I fixed this by copying /usr/local/include/gmp.h to ghc-6.8.1/includes. This is, of course, a risk of confusing the 32/64bit version of this library. Anyway, the resulting compiler in stage2/ghc-6.8.1 dumps core. Perhaps I can get better results, if I use the most conservative settings possible for stage1 build, but I have no idea what they are. The recommended porting process (via .hc files) fails, too. I am going to make a separate bug report about this. -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 PGP: http://vestein.arb-phys.uni-dortmund.de/~wb/mypublic.key ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC porting to FreeBSD-amd64 progress report
Simon Marlow [EMAIL PROTECTED] schrieb: Wilhelm B. Kloke wrote: However, you might want to wait for 6.8.2 in the next few days, as we fixed several important bugs. I have found a couple of small bugs regarding FreeBSD. Changing the configure process would be helpful. FreeBSD-amd64 is identified as x86_64-unknown-freebsd, but the entry in configure uses amd64-*-freebsd*r; this should be made consistent. The FreeBSD cc needs -L/usr/local/lib and -I/usr/local/lib to find the native gmp (and possibly others, too) library. I tried to find out a way to use the FreeBSD-i386 ghc, which runs fine on FreeBSD-amd64, for bootstrap. The problem in this case is to substitute the 32bit assembler and linker instead of the 64bit versions. In case of the assembler the script as32 was usable like this one: #!/bin/sh /usr/bin/cc -Xassembler -32 $* But I failed to figure out the right ld32 script. -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 PGP: http://vestein.arb-phys.uni-dortmund.de/~wb/mypublic.key ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC porting to FreeBSD-amd64 progress report
Simon Marlow [EMAIL PROTECTED] schrieb: Perhaps you compiled mkDerivedConstants as a 32-bit executable? Yes. I was not attentive enough. But now I have got a working compiler on FreeBSD-amd64-7.0. If anybody is interested, I shall prepare a package of the installed binaries. The compiler is good enough to compile itself now. Though there are problems remaining. One the programs I tested the computation of Meertens numbers from Bird/Wadler's book. This program segfaults on amd64, but not on i386. Here it is: module Main(main,primes,sieve,meertens) where -- a Meertens number is one whose decimal representation conincides with -- its Gödel number -- The 1st is 81312000 = 2^8*3*5^3*7*11^2 main :: IO() main = do putStr ( show ( meertens 8 ) ) -- putStr ( show ( meertens 9 ) ) primes= sieve [2..] sieve (p : nos) = p: sieve(remove (multsof p) nos ) where multsof p n = n `rem` p == 0 remove p= filter (not.p) powers p= iterate (p*) 1 meertens k = [n| (n,g) - candidates (0,1),n == g ] where candidates= concat . map ( search pps ) . tail . labels ps ps : pps = map powers ( take k primes ) search [] x = [x] search (ps : pps) x = concat ( map ( search pps ) (labels ps x )) labels ps (n,g) = zip ( map (m+) ds)(chop(map(g*)ps)) where m = 10 * n chop = takeWhile( 100) ds= [0..9] -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 PGP: http://vestein.arb-phys.uni-dortmund.de/~wb/mypublic.key ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC 6.8.1 port on FreeBSD-amd64?
As I have got an amd64 machine again, I am returning to my previous porting effort. When I try to build to .hc files on i386 system, I get the following error: ... gmake[2]: Entering directory `/usr/home/wb/ghc-6.8.1/libraries/unix' ../../compiler/stage1/ghc-inplace -package-name unix-2.2.0.0 -hide-all-packages -i -idist/build/autogen -idist/build -i. -Idist/build -Iinclude -#include HsUnix.h -#include execvpe.h -odir dist/build -hidir dist/build -stubdir dist/build -package base-3.0.0.0 -package directory-1.0.0.0 -O -XCPP -XForeignFunctionInterface -idist/build -H32m -O0 -fasm -Rghc-timing -keep-hc-files -O -c dist/build/System/Posix/Process.hs -o dist/build/System/Posix/Process.o -ohi dist/build/System/Posix/Process.hi Prologue junk?: .type s32x_ret, @function s32x_ret: pushl %ebp movl%esp, %ebp ghc: 114363808 bytes, 9 GCs, 2951168/5799936 avg/max bytes residency (2 samples), 33M in use, 0.00 INIT (0.00 elapsed), 0.78 MUT (2.33 elapsed), 0.20 GC (0.23 elapsed) :ghc gmake[2]: *** [dist/build/System/Posix/Process.o] Fehler 255 gmake[2]: Leaving directory `/usr/home/wb/ghc-6.8.1/libraries/unix' gmake[1]: *** [make.library.unix] Fehler 2 gmake[1]: Leaving directory `/usr/home/wb/ghc-6.8.1/libraries' gmake: *** [stage1] Fehler 2 which I don't understand at all. The build of ghc-6.8.1 for native use on a FreeBSD-6.2 i386 did not cause any problems. Perhaps someone else has done the porting work already. Please give me a note, if anybody is able to provide me a set of files to get the bootstrap further. -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 PGP: http://vestein.arb-phys.uni-dortmund.de/~wb/mypublic.key ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell-cafe] Re: recursive matrix computations
Andrew U. Frank [EMAIL PROTECTED] schrieb: it appears possible to define matrix operations like LU-decomposition, SVD, inverse etc. in a recursive fashion (see transpose in the prelude). is this possible? has anybody code in haskell which does this (not asking for high performance here, more instructive value). I would like to see this, too. Myself I did some experiments in trying to implement the transformation to upper diagonal form by rational Givens transforms. The following code fragment does this recursively: -- rationalGivens :: Fractional a = a - [a] - [[a]] - [[a]] -- marginal cases first rationalGivens qq [x] ((pp:[]):[]) = ( pp + qq * x * x : [] ) : [] rationalGivens _ [] [[]] = [[]] rationalGivens qq xy pmat | qq == 0 = pmat rationalGivens qq (x:y) (ppr:pmat) | x == 0 = ppr:rationalGivens qq y pmat rationalGivens qq (x:y) [[]] = ( qq * x * x : (1/x).*y ) : [] -- main case rationalGivens qq (x:y) ((pp:r):pmat) = let pp' = pp + qq * x * x qq' = pp * qq / pp' s = x * qq / pp' y' = y - x .* r r' = r + s .* y' in ( pp' : r' ) : rationalGivens qq' y' pmat -- rationalGivens 1 [2,1] [[1,0],[1]] == [[5.0,0.4],[1.2]] Arrays are double lists in this code, q a scale factor (starting with 1) xy a row vector to be added to the u.t. matrix pmat. The diagonal elements of pmat contain the square of the scale factor of the row, i.E. the matrix [[5.0,0.4],[1.2]] is to be interpreted as the product (sqrt(5) 0 ) ( 1 0.4 ) ( 0sqrt(1.2)) ( 0 1 ) -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: GHC-6.4.1 on FreeBSD-amd64 port progress
Simon Marlow [EMAIL PROTECTED] schrieb: Are you building GHC in a fresh tree now? I'd recommend doing that. Now I am using a *really* fresh tree. Formerly the compilation of Apply.cmm did not render an instructive error message, just failed for some sort of memory access exception. Now I have: ../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -H16m -O -O2 -static -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include RtsUtils.h -#include StgRun.h -#include Schedule.h -#include Printer.h -#include Sanity.h -#include STM.h -#include Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h -#include Apply.h -fvia-C -dcmm-lint -c parallel/RBH.c -o parallel/RBH.o ../../ghc/compiler/ghc-inplace -H16m -O -O2 -static -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include RtsUtils.h -#include StgRun.h -#include Schedule.h -#include Printer.h -#include Sanity.h -#include STM.h -#include Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h -#include Apply.h -fvia-C -dcmm-lint -c Apply.cmm -o Apply.o ghc-asm: don't know how to mangle assembly language for: x86_64-unknown-freebsd gmake[2]: *** [Apply.o] Fehler 1 gmake[1]: *** [all] Fehler 1 gmake[1]: Leaving directory `/data/home/wb/Haskell/ghc-6.4.1-amd64/ghc' gmake: *** [build] Fehler 1 I am looking myself how to add this info, but quick help by an informed person is welcome, too, as usual. -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC-6.4.1 on FreeBSD-amd64 port progress
Simon Marlow [EMAIL PROTECTED] schrieb: On 15 October 2005 23:10, Wilhelm B. Kloke wrote: Don't forget to delete Linker.c (for ghci). The stage on teh host system where the process fails jsut now is $MAKE -C libraries boot all because Fake happy is not happy! You mean on the target system? Can you give more details? Yes. Sorry for any confusion. The happy error messages was an easy one, because I have a working 32bit happy on the system. But ghc-inplace seems to work pretty good now on amd64. I reached the end of hc-build successfully. Now there is a new problem. I tried (as root) make install at this point. This fails with error messages related to missing stage2 subdirectories. So I tried gmake stage=2 boot This fails with messages ... cmm/CmmLex.hs:28: unterminated #if cmm/CmmLex.hs:20: unterminated #if ghc: 55123864 bytes, 6 GCs, 160600/160600 avg/max bytes residency (1 samples), 16M in use, 0.00 INIT (0.00 elapsed), 0.12 MUT (0.41 elapsed), 0.01 GC (0.05 elapsed) :ghc gmake: *** [depend] Fehler 1 This error is due to indented preprocessor lines #else #endif I removed the indentation of these 2 lines. Then this file compiled, but there are more of them, the next being parser/Lexer.hs Is there a recommended way to handle this? -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC-6.4.1 on FreeBSD-amd64 still not ported
John Hornkvist [EMAIL PROTECTED] schrieb:
Simon Marlow simonmar at microsoft.com writes:
SIZEOF_mp_limb_t comes from DerivedConstants.h, and SIZEOF_VOID_P comes
from ghcautoconf.h (both in ghc/includes). Both of these files should
be from the target system for a cross-compile; I strongly suspect that
one of them has been overwritten by the host version in your tree.
Those files got overwritten several times for me, too, despite following the
instructions... I ended up watching for them to get overwritten and copying
them back whenever that happened.
This is not really sufficient. I use chflags uchg to protect these
files. At least you you will be noticed, when the overwrite tries to happen.
I've been trying to crosscompile for amd64-freebsd from Mac OS X, but
although I seem to get all the hc files, the ghc-pkg-inplace crashes, and
Are you sure? The recommended procedure has a serious bug, which I
discovered about 30 minutes ago. You need to do make boot in the rebuilding
of ghc/lib/compat with the same flags as make all, because libghccompat.a
is built in make boot and you won't get the .hc files otherwise.
Just look into ghc/lib/Compat subdirectories for .hc files.
so does ghc-inplace, with the following backtrace:
#0 0x014f3ed0 in StgRun ()
#1 0x014f09b5 in schedule ()
#2 0x014f1386 in waitThread_ ()
#3 0x014f12aa in scheduleWaitThread ()
#4 0x014ee421 in rts_evalLazyIO ()
#5 0x014edccf in main ()
Should I try to build again with debug symbols, or is that pointless for ghc
output?
This is pointless, and typical for the sort of errors SM mentioned.
I have got dozens of these in the process.
Now let me report real progress. I have got it on FreeBSD-6.0-amd64 at last.
Here are the steps on the host system, which are needed IIRC:
cp
../../fptools-amd64/ghc-6.4.1/ghc/includes/{ghcautoconf.h,DerivedConstants.h,GHCConstants.h}
ghc/includes
touch
ghc/includes/{ghcautoconf.h,DerivedConstants.h,GHCConstants.h,mkDerivedConstants.c}
touch
ghc/includes/{mkDerivedConstantsHdr,mkDerivedConstants.o,mkGHCConstants,mkGHCConstants.o}
touch ghc/includes/{ghcautoconf.h,DerivedConstants.h,GHCConstants.h}
chflags uchg ghc/includes/{ghcautoconf.h,DerivedConstants.h,GHCConstants.h}
(cd glafp-utils gmake boot gmake)
(cd ghc gmake boot gmake)
(cd libraries gmake boot gmake)
(cd ghc/compiler gmake boot stage=2 gmake stage=2)
(cd ghc/lib/compat gmake clean; rm .depend; gmake boot UseStage1=YES
EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files'; gmake -k UseStage1=YES
EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files')
(cd ghc/rts gmake -k UseStage1=YES EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files')
(cd ghc/utils gmake clean; gmake -k UseStage1=YES EXTRA_HC_OPTS='-O -fvia-C
-keep-hc-files')
gmake hc-file-bundle Project=Ghc
Don't forget to delete Linker.c (for ghci). The stage on teh host system
where the process fails jsut now is
$MAKE -C libraries boot all
because
Fake happy is not happy!
But ghc-inplace seems to work pretty good now on amd64.
--
Dipl.-Math. Wilhelm Bernhard Kloke
Institut fuer Arbeitsphysiologie an der Universitaet Dortmund
Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC-6.4.1 on FreeBSD-amd64 still not ported
Simon Marlow [EMAIL PROTECTED] schrieb: On 25 September 2005 18:54, Wilhelm B. Kloke wrote: bash-2.05b$ (cd ghc/rts; gmake PrimOps.o ) ../../ghc/compiler/ghc-inplace -H16m -O -H32m -keep-hc-files -static -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include RtsUtils.h -#include StgRun.h -#include Schedule.h -#include Printer.h -#include Sanity.h -#include STM.h -#include Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h -#include Apply.h -fvia-C -dcmm-lint -c PrimOps.cmm -o PrimOps.o In file included from PrimOps.cmm:28: /home/wb/Haskell/fptools-i386amd64/ghc-6.4.1/ghc/includes/Cmm.h:288:2: #error mp_limb_t != StgWord: assumptions in PrimOps.cmm are now false gmake: *** [PrimOps.o] Fehler 1 Similar messages for attemps to make other of the failing .hc files. Perhaps crossporting from a 64bit system is easier. I presume that once a working ghc is available, life is much easier, as Fedora Linux-64 does not report problems. GHC is correctly generating the .hc file from the .cmm file, and then attempting to compile the .hc file using gcc. This latter step fails, as expected, because the .hc code is intended to be compiled on the target system. We just need to get those .hc files and take them to the target. Just doing 'make -k' in ghc/rts should leave all the .hc files behind, because you already have the -keep-hc-files flag in your command line, so GHC won't delete the intermediate .hc files even when the subsequent compilation stage fails. This doesn't work. The commands don't leve a .hc file behind, even with make -k. I ieven tried using the command line alonei for Appy.hc. This did not work either. The I commented out the #error in line 288 of Cmm.h. After this I got the following error: ~/Haskell/fptools-i386amd64/ghc-6.4.1/ghc/rts 0$ ../../ghc/compiler/ghc-inplace -H16m -O -H32m -keep-hc-files -static -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include RtsUtils.h -#include StgRun.h -#include Schedule.h -#include Printer.h -#include Sanity.h -#include STM.h -#include Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h -#include Apply.h -fvia-C -dcmm-lint-O -fvia-C -keep-hc-files -c Apply.cmm -o Apply.o Cmm lint error: in proc stg_ap_0_ret in basic block c2 in assignment: R1 = I32[R1 + 8 + 0]; Compilation had errors so it looks as if there is a more severe problem remaining. -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC-6.4.1 on FreeBSD-amd64 still not ported
Though I have reported some sort of success on this in the last days, I was too early. The ghc-inplace does not work on the target system. It compiled because I have been too lax in following the instructions. Here is the report, where the crossport fails on the i386host system: tar czf ghc-6.4.1-x86_64-unknown-freebsd-hc.tar.gz `cat hc-files-to-go` tar: ghc-6.4.1/ghc/rts/PrimOps.hc: Cannot stat: No such file or directory tar: ghc-6.4.1/ghc/rts/StgStartup.hc: Cannot stat: No such file or directory tar: ghc-6.4.1/ghc/rts/StgStdThunks.hc: Cannot stat: No such file or directory tar: ghc-6.4.1/ghc/rts/Updates.hc: Cannot stat: No such file or directory tar: ghc-6.4.1/ghc/rts/Apply.hc: Cannot stat: No such file or directory tar: ghc-6.4.1/ghc/rts/Exception.hc: Cannot stat: No such file or directory tar: ghc-6.4.1/ghc/rts/HeapStackCheck.hc: Cannot stat: No such file or directory tar: ghc-6.4.1/ghc/rts/StgMiscClosures.hc: Cannot stat: No such file or directory tar: ghc-6.4.1/libraries/haskell-src/Language/Haskell/Parser.hs: Cannot stat: No such file or directory gmake: *** [hc-file-bundle] Fehler 1 bash-2.05b$ (cd ghc/rts; gmake PrimOps.o ) ../../ghc/compiler/ghc-inplace -H16m -O -H32m -keep-hc-files -static -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include RtsUtils.h -#include StgRun.h -#include Schedule.h -#include Printer.h -#include Sanity.h -#include STM.h -#include Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h -#include Apply.h -fvia-C -dcmm-lint -c PrimOps.cmm -o PrimOps.o In file included from PrimOps.cmm:28: /home/wb/Haskell/fptools-i386amd64/ghc-6.4.1/ghc/includes/Cmm.h:288:2: #error mp_limb_t != StgWord: assumptions in PrimOps.cmm are now false gmake: *** [PrimOps.o] Fehler 1 Similar messages for attemps to make other of the failing .hc files. Perhaps crossporting from a 64bit system is easier. I presume that once a working ghc is available, life is much easier, as Fedora Linux-64 does not report problems. -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
progress on Freebsd-amd64 (Was: .hc files for building ghc-6.4.1 on amd64 ?)
Simon Marlow [EMAIL PROTECTED] schrieb: Int64# primitive type (it's the same as Int#). You might want to make sure that ghc/includes/ghcautoconf.h on the host machine is the right one - it should have been copied from the target machine. Yes. ghcautoconf.h had been rebuilt accidentally. Now I have an unregisterised ghc-inplace. What is the fastest way to test its usability? The next failure is at Control/Arrow.hc after reconfiguration in hc-build: ==fptools== gmake all -wr; in /data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries/base gcc -x c Control/Arrow.hc -o Control/Arrow.raw_s -S -O -D__GLASGOW_HASKELL__=604 -O -I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/ghc/includes -I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries/base/include -I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries/unix/include -I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries/parsec/include -I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries/readline/include -I. `echo | sed 's/^$/-DSTOLEN_X86_REGS=4/'` Control/Arrow.hc: In function `s39r_entry': Control/Arrow.hc:25: error: `stg_ap_p_ret' undeclared (first use in this function) Control/Arrow.hc:25: error: (Each undeclared identifier is reported only once Control/Arrow.hc:25: error: for each function it appears in.) Control/Arrow.hc: In function `s39v_entry': Control/Arrow.hc:46: error: `stg_ap_p_ret' undeclared (first use in this function) ... -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: .hc files for building ghc-6.4.1 on amd64 ?
Wilhelm B. Kloke [EMAIL PROTECTED] schrieb: Simon Marlow [EMAIL PROTECTED] schrieb: On 17 September 2005 22:05, Wilhelm B. Kloke wrote: I tried to go back to ghc/rts to build more files following the ipattern of the last steps before, but this destroys genapply. Don't quite understand this - could you elaborate? I tried (cd ghc/rts ; gmake all) after (cd ghc/compiler ; gmake stage=2 ) Small, but possibly essential, correction: after completion of the whole other stuff. I have further information now. When compiling Linker.c, the compilation fails, because there is no MAP_32BIT in FreeBSD-amd64. Perhaps just removing this could make it work. I have no idea why it is needed on linux-x86_64. Deletion of Linker.c and manual build of some AutoApply files make the crossbuild work on i386 side. I have a copy of the resulting hc-bundle ready. If anybody wants them, send me a mail. They don't work on the amd64 side, though. Here is the error message: gcc -x c GHC/Int.hc -o GHC/Int.o -c -O -DNO_REGS -DUSE_MINIINTERPRETER -D__GLASGOW_HASKELL__=604 -O -I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/ghc/includes -I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries/base/include -I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries/unix/include -I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries/parsec/include -I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries/readline/include -I. `echo | sed 's/^$/-DSTOLEN_X86_REGS=4/'` GHC/Int.hc: In function `s83O_ret': GHC/Int.hc:2522: error: `int64ToIntegerzh_fast' undeclared (first use in this function) GHC/Int.hc:2522: error: (Each undeclared identifier is reported only once GHC/Int.hc:2522: error: for each function it appears in.) GHC/Int.hc: In function `s83J_ret': GHC/Int.hc:2583: error: `int64ToIntegerzh_fast' undeclared (first use in this function) gmake[1]: *** [GHC/Int.o] Fehler 1 gmake: *** [all] Fehler 1 gmake: Leaving directory `/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries' I notices that the evil mangler was replaced after my build. I don't have an idea whether this would make it work. BTW. FreeBSD-amd64 does not seem to support small memory model. Is this essential? -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: .hc files for building ghc-6.4.1 on amd64 ?
Simon Marlow [EMAIL PROTECTED] schrieb: On 17 September 2005 22:05, Wilhelm B. Kloke wrote: I tried it again today. One of my problems was related to gmake version. The configure script should warn, if gmake is older than 3.80 (I had 3.78). I'm using 3.79.1. I do vaguely remember a problem with older versions of gmake - what goes wrong for you? The old gmake does not get the dependencies right. The building of the .hc bundle fails wirth the following messages: ... tar czf ghc-6.4.1-x86_64-unknown-freebsd-hc.tar.gz `cat hc-files-to-go` tar: ghc-6.4.1/ghc/rts/PrimOps.hc: Cannot stat: No such file or directory ... Cannot stat: No such file or directory gmake: *** [hc-file-bundle] Fehler 1 Yes, you do actually need to generate these .hc files on the host system. What happened to the build in ghc/rts - could you post the error message? Possibly a 'make -k' in ghc/rts will be enough to get these files. I tried to go back to ghc/rts to build more files following the ipattern of the last steps before, but this destroys genapply. Don't quite understand this - could you elaborate? I tried (cd ghc/rts ; gmake all) after (cd ghc/compiler ; gmake stage=2 ) I have further information now. When compiling Linker.c, the compilation fails, because there is no MAP_32BIT in FreeBSD-amd64. Perhaps just removing this could make it work. I have no idea why it is needed on linux-x86_64. there is no rule to build those files. Also, I needed to have happy and alex on the target system, because make boot fails without them (catch 22). When things are working properly, you don't need Happy or Alex on the target system. I suspect things have gone wrong earlier. Probably. But this is in a very early stage. It even happens when using gmake -n boot (for finding the cause I wanted to know the commands which may have failed), that two command using $(HAPPY) and $(ALEX) are executed. I was not able to locate the point better. Perhaps you could try the first stages of the crossbuild on suitable system, where these two variable from mk/config.mk are defined empty (as was the case on my system after configure). A final glitch is that (at least, my) FreeBSD-amd64-6.0 gcc does not include -I/usr/local/include and -L/usr/local/lib in the search path. So libgmp is not found. Ok. You can use the libgmp in the tree (this should happen automatically), or you can add the -I/-L flags to the relevant places. This was not possible, as x86_64 does not seem supported in ghc's gmp. The other solution (exporting LDFLAGS=-L/usr/local/lib) works. -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
.hc files for building ghc-6.4 on amd64 ?
I have a FreeBSD box running FreeSD-amd64-6.0. Is there anybody who can give me a set of .hc files (probably from linux x86_64) to build GHC? I tried to follow the instructions to crossbuild from FreeBSD-i386, but my attempts failed for reasons I don't understand. -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] Re: ANNOUNCE: GHC version 6.4
Sebastian Sylvan [EMAIL PROTECTED] schrieb: I'm having trouble building this. I download the source, go to my source dir and run ./configure (which seems to run to completion without problems), then I run make and get the following: ./mk/config.mk, line 554: Need an operator ./mk/config.mk, line 554: Need an operator . Error expanding embedded variable This is on freeBSD 5.3 It looks like you have had more luck than me. I could not get configure finish correctly till now. The above error indicates the wrong make program. Try gmake (GNU make) instead. -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Eliminating Array Bound Checking through Non-dependent types
In article [EMAIL PROTECTED], Bjorn Lisper [EMAIL PROTECTED] wrote: ( A really interesting post on static elimination of array bounds checking by Oleg...) Some questions and suggestions: Am I right suspecting, that this method also solves the problem of assuring the right p in p-modular arithmetic (as complained by Sergei Mechveliani in his Basic Algebra proposal)? -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Jan Skibinski's lhs modules ?
As the site www.numeric-quest.com does not respond to my queries, I would like to ask the community, where I can find a collection of the modules QuantumVector.lhs etc. ? -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Fuzzy.hs
Hi, I am trying to reproduce the fuzzy oscillator example by Jan Skibinski. ( http://www.numeric-quest.com/haskell/Fuzzy_oscillator.html ) I am having problems to compile the module Fuzzy.hs. As I am just in an early learning stage, I need help to understand the error. hugs98 e.g. says: Reading file "/usr/local/share/hugs/lib/Prelude.hs": Reading file "Fuzzy_oscillator.lhs": Reading file "Fuzzy.hs": Type checking ERROR "Fuzzy.hs" (line 76): Cannot build superclass instance *** Instance: Num (a - b) *** Context supplied: Num b *** Required superclass : Show (a - b) Similar with hbc: Errors: "Fuzzy.hs", line 0, [76] Instance context does not imply class context (Prelude.Show b, Prelude.Show c) = Prelude.Show (b - c), Prelude.Show in (Num c) = Num (b - c) nhc98 and ghc4.06 show a different message: Fuzzy.hs:188: Variable not in scope: `fromInt' Perhaps this error masks the same problem in these compilers. Do you have any hint ready?
Re: Haskell mailing list
In article ifado.list.haskell/[EMAIL PROTECTED], Keith Wansbrough [EMAIL PROTECTED] wrote: Ralf Muschall writes: [EMAIL PROTECTED] wrote: set up comp.lang.haskell? I agree with the above. This is IMHO the best solution for a lot of reasons: I disagree. One major reason is the spam problem: a post to a newsgroup essentially guarantees putting your name on a spam mailing list, and receiving large quantities of Make Money Fast postings. How do you come to think that mailing lists do not receive spam? Mailing lists are evil except for a very limited (or restricted) public ( 100 p ersons). 2. The decision problem (high volume list without the important people or having to hesitate before every article) goes away. Many "important people" have a policy of no longer reading Usenet. A lot of important people are in error otherways also. I redirect any mailing list I happen to subscribe to into a local newsgroup. I am glad of any such local group disappearing by converting the mail list into a regular news group. This happened in comp.compilers.lcc, e.g. BTW: The correct thing to do about SPAM is neither to leave Usenet nor to try antispammed adresses (this is just to promote evolution of better (worse) spammers). Spammers have to be prosecuted, legally and socially.
Which GUI on X11R6 ?
Hi, has anybody there an idea which GUI is usable with Haskell 98 on a Unix/X11R6 system (FreeBSD to be complete)? It seems that all GUI stuff develepmont (Fudgets, Haggis ...) has been stalled since some years. Some of the links in the Haskell libraries and tools page are not even accessible any more. If the Win32 API is in better condition, will it be possible to use this with either Wine or TWIN? -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 montags und dienstags
