Re: How to use C-land variable from Cmm-land?
On 09.12.2012, at 00:12, Yuras Shumovich shumovi...@gmail.com wrote: It looks wrong for me: the highest part of %rax remains uninitialized. When 32 bits are assigned to any of the standard registers, the upper 32 bits are implicitly set to zero. Intel is weird. Axel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to use C-land variable from Cmm-land?
When 32 bits are assigned to any of the standard registers, the upper 32 bits are implicitly set to zero. Intel is weird. Didn't AMD invent the 64-bit extensions? -- Kim-Ee On Sun, Dec 9, 2012 at 3:07 PM, Axel Simon axel.si...@in.tum.de wrote: On 09.12.2012, at 00:12, Yuras Shumovich shumovi...@gmail.com wrote: It looks wrong for me: the highest part of %rax remains uninitialized. When 32 bits are assigned to any of the standard registers, the upper 32 bits are implicitly set to zero. Intel is weird. Axel ___ 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
building GHC for Slackware/Salix
I'm making a GHC package for Salix 14 (which is backwards-compatible with Slackware, so this will be a Slackware package, too). The main thing I'd be grateful for advice on is the overall approach I'm taking to the package. Others I've seen (such as the Arch package) just assume GHC is already present. My build script unpacks the binary distribution for unknown linux and builds GHC against that. (Both are version 7.4.2.) I have avoided installing anything else (such as the Haskell Platform) so as to keep as close as possible to the ideal of a package as a transparent, reproducible process that only depends on the source. As far as I can tell from the build prerequisites http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Tools the only consequence is that documentation is only created as html, not pdf and ps as well. Though everything seems to work ok, the build as it stands fails three tests: Unexpected failures: lib/Time T5430 [bad stdout] (normal) perf/compiler parsing001 [stat not good enough] (normal) simplCore/should_compile spec-inline [stderr mismatch] (optasm) That is after running the fast version of the test suite, which the documentation says should pass 100%. My second question is, do these results suggest anything as to where the problem may lie, and how important it is? When I then installed the new package and built the Haskell Platform against it (using the build script at http://slackbuilds.org), although the installation nonetheless appeared to be succesful, the build script failed at the very end where it tries to do ghc-pkg recache When I did this manually, I discovered root permissions were needed. Is that normal? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
cabal-install use multiple config files?
I don't see a command-line switch to ask cabal-install to use a different config file. Is there an environment variable for it or something? I want to use the same cabal-install binary with three different installs of ghc and ghc-pkg to allow me to maintain my cross-compiler packages as well. -- Stephen Paul Weber, @singpolyma See http://singpolyma.net for how I prefer to be contacted edition right joseph ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: cabal-install use multiple config files?
* Stephen Paul Weber singpol...@singpolyma.net [2012-12-09 21:20:34+] I don't see a command-line switch to ask cabal-install to use a different config file. Is there an environment variable for it or something? I want to use the same cabal-install binary with three different installs of ghc and ghc-pkg to allow me to maintain my cross-compiler packages as well. There's a '--config-file' option, see https://github.com/haskell/cabal/issues/1113 Roman ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ANNOUNCE: GHC 7.6.2 Release Candidate 1
We are pleased to announce the first release candidate for GHC 7.6.2: http://www.haskell.org/ghc/dist/7.6.2-rc1/ This includes the source tarball, installers for Windows, and bindists for Windows, Linux, OS X and FreeBSD, on x86 and x86_64. We plan to make the 7.6.2 release early in 2013. Please test as much as possible; bugs are much cheaper if we find them before the release! Thanks Ian, on behalf of the GHC team ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
building GHC for antique OSX
Hello all, I'm one of those curmudgeons still working on OSX 10.5.8. Recently I finally got around to building the latest GHC and, FWIW, everything seems to have worked out fine. I did get a few failed tests in the testsuite though, and I'm curious what they mean or if they're actually cause for concern? OVERALL SUMMARY for test run started at Fri Dec 7 10:49:39 EST 2012 3402 total tests, which gave rise to 14436 test cases, of which 0 caused framework failures 11364 were skipped 2985 expected passes 47 had missing libraries 34 expected failures 0 unexpected passes 6 unexpected failures Unexpected failures: ../../libraries/directory/tests T4113 [bad stdout] (normal) concurrent/should_runconc070 [bad stdout or stderr] (ghci) ghci/should_run 3171 [bad stdout] (normal) perf/haddock haddock.Cabal [stat too good] (normal) perf/haddock haddock.base [stat too good] (normal) perf/haddock haddock.compiler [stat too good] (normal) -- Live well, ~wren ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: building GHC for antique OSX
On Sun, Dec 09, 2012 at 05:45:17PM -0500, wren ng thornton wrote: I'm one of those curmudgeons still working on OSX 10.5.8. Recently I finally got around to building the latest GHC and, FWIW, everything seems to have worked out fine. I did get a few failed tests in the testsuite though, and I'm curious what they mean or if they're actually cause for concern? Unexpected failures: ../../libraries/directory/tests T4113 [bad stdout] (normal) concurrent/should_runconc070 [bad stdout or stderr] (ghci) ghci/should_run 3171 [bad stdout] (normal) perf/haddock haddock.Cabal [stat too good] (normal) perf/haddock haddock.base [stat too good] (normal) perf/haddock haddock.compiler [stat too good] (normal) stat too good is definitely not a cause for concern. It just means that haddock's performance was better than expected. For the others, you'd have to look at why they failed (add TEST=T4113 conc070 3171 to the testsuite make command you ran if you want to rerun only those tests). Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHCi + FFI + global C variables
I'm currently working with a C library that needs to use/modify global C
variables, for example:
igraph_bool_t igraphhaskell_initialized = 0;
int igraphhaskell_initialize()
{
if (igraphhaskell_initialized != 0)
{
printf(C: Not initializing. igraphhaskell_initialized = %i\n,
igraphhaskell_initialized);
return 1;
}
// initialization
}
If I compile an example programm using this library everything works
fine, but if I try to run the same program in GHCi it dies with the message
C: Not initializing. igraphhaskell_initialized = -90
The value (and apparently the adress of the global variable) is
completly off, and I have no idea what is causing this or how to solve
this issue and make the library GHCi-friendly. Is it possible to run
this code in GHCi at all? Also, since it's a foreign library I obviously
cannot just change the C code to simply not use any global variables at all.
- Nils
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: cabal-install use multiple config files?
Somebody claiming to be Roman Cheplyaka wrote: * Stephen Paul Weber singpol...@singpolyma.net [2012-12-09 21:20:34+] I don't see a command-line switch to ask cabal-install to use a different config file. There's a '--config-file' option, see https://github.com/haskell/cabal/issues/1113 Sweet! I've got my environment working using this shell wrapper: #!/bin/sh export PATH=$HOME/src/ghc/inplace:$PATH case $1 in install) shift cabal --config-file=$HOME/.cabal-nto-qnx-i486/config install --with-gcc=i486-pc-nto-qnx8.0.0-gcc --configure-option=--target=i486-pc-nto-qnx8.0.0 --configure-option=--build=i686-linux-gnu --configure-option=--host=i486-pc-nto-qnx8.0.0 --hsc2hs-option=--cross-safe --hsc2hs-option=--cross-compile $@ ;; *) cabal --config-file=$HOME/.cabal-nto-qnx-i486/config $@ ;; esac Can I move any/all of those switches into the config file? None of them really seem to fit in the listed config options. -- Stephen Paul Weber, @singpolyma See http://singpolyma.net for how I prefer to be contacted edition right joseph ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
