Building GHC for BB10 (QNX)
Hey all, I'm interesting in trying to get an initial port for BlackBerry 10 (QNX) going. It's a POSIXish environment with primary interest in two architechtures: x86 (for simulator) and ARMv7 (for devices). I'm wondering if <http://hackage.haskell.org/trac/ghc/wiki/Building/Porting> is fairly up-to-date or not? Is there a better place I should be looking? One big difference (which may turn out to be a problem) is that the readily-available QNX compilers (gcc ports) are cross-compilers. I realise that GHC has no good support to act as a cross-compiler yet, and anticipate complications arising from trying to build GHC using a cross-compiler for bootstrapping (since that implies GHC acting as a cross-compiler at some point in the bootstrapping). Any suggestions would be very welcome. -- 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: Dynamic libraries by default and GHC 7.8
Somebody claiming to be Ian Lynagh wrote: GHC HEAD now has support for using dynamic libraries by default (and in particular, using dynamic libraries and the system linker in GHCi) for a number of platforms. The various issues are described in a wiki page here: http://hackage.haskell.org/trac/ghc/wiki/DynamicByDefault IIRC, one of the problems with dynamic linking in GHC is that when the GHC version is different, the ABI can often be different enough to making such shared libraries incompatible with each other / binaries made on different GHCs. This makes distribution a potential nightmare (where you have to package all the *.so files and send them along with your binary, which is essentially the same as static linking, but more pain). Is this no longer the case, or am I completely misremembering this? Also, you say "for a number of platforms" and that wiki page says "Currently, we don't know how to do dynamic-by-default on Windows in a satisfactory way." So I assume Windows is not one of the platforms that would be seeing this change? -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
Somebody claiming to be Ian Lynagh wrote: On Tue, Nov 27, 2012 at 10:22:12AM -0500, Stephen Paul Weber wrote: IIRC, one of the problems with dynamic linking in GHC is that when the GHC version is different, the ABI can often be different enough to making such shared libraries incompatible with each other / binaries made on different GHCs. This makes distribution a potential nightmare (where you have to package all the *.so files and send them along with your binary, which is essentially the same as static linking, but more pain). That is still the case. However, if you want to distribute binaries then you will still be able to build with -static if you don't want to have ot bundle a load of DLLs. It's only the default that will change. If the default changes, though, that would mean that before distribution I would have to re-build all my cabal packages with -static? And if I change my default so that cabal builds with -static GHCI would no longer work for me? -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
Somebody signing messages as Joachim Breitner wrote: Given the current sensitivity of the ABI hashes we really do not want to have Programs written in Haskell have a runtime dependency on all the included Haskell libraries. So I believe we should still link Haskell programs statically in Debian. This is also a concern I have. Hence, Debian will continue to provide its libraries built the static way. Right. Building them also in the dynamic way for the sake of GHCi users seems possible. Perhaps Debian could just ship a GHCi that uses the RTS linker, as now? The change is to be made for "some platforms", we could opt to have Debian not be such a platform. -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: proposal: separate lists for ghc-cvs commits and ghc-dev chatter
Somebody claiming to be Erik de Castro Lopo wrote: This is a good idea, one that I have solved at my end using Procmail. I was planning to do this soon (as I get deeper into GHC hacking because of my port, but don't want the high-email-volume of the comitt and build emails). Procmail is awesome. -- 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
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?
Somebody claiming to be Roman Cheplyaka wrote: * Stephen Paul Weber [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
Re: (mips64el) Cross-building GHC
Somebody claiming to be jug...@lavabit.com wrote: I would like to port GHC to mips64el. I have never tried cross-building before. So I will probably post more questions later. Awesome. I have a MIPS-based netbook (lemote yeelong thing) and got the GHC port from Debian on it, but of course it's a just-barely-works build :) -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: (mips64el) Cross-building GHC
Somebody signing messages as Joachim Breitner wrote: Awesome. I have a MIPS-based netbook (lemote yeelong thing) and got the GHC port from Debian on it, but of course it's a just-barely-works build :) What do you mean by barely-just-works? Anything besides: * no GHCi support and * bad performance due to the lack of a native code generator is probably a bug that we (the GHC maintainers in Debian) would like to know about. Sorry, I did not mean that to sound so negative. I'm really glad you guys have a build for my esoteric machine at all :) I was, in fact, referring to the lack of GHCi/TH/DPH support, and IIRC it uses the old via-C instead of LLVM, but I could be wrong about that. More eyeballs on porting to the architecture would certainly not be a bad thing. I haven't experience any actual bugs yet in my yeeloong GHC. Thanks for providing it. -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
make install failing
I just did a clean build of my cross-compiling GHC with --prefix set in the top-level ./configure call. When I run `make install` I get: "/home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/lib/ghc-7.7.20130112/bin/ghc-pkg" --force --global-package-db "/home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/lib/ghc-7.7.20130112/package.conf.d" update rts/package.conf.install /bin/sh: 1: /home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/lib/ghc-7.7.20130112/bin/ghc-pkg: not found make[1]: *** [install_packages] Error 127 make: *** [install] Error 2 Grepping the output for pkg: $ make install 2>&1 | grep pkg "rm" -f "/home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/bin/i486-pc-nto-qnx8.0.0-ghc-pkg" ln -s i486-pc-nto-qnx8.0.0-ghc-pkg-7.7.20130112 "/home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/bin/i486-pc-nto-qnx8.0.0-ghc-pkg" "/home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/lib/ghc-7.7.20130112/bin/ghc-pkg" --force --global-package-db "/home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/lib/ghc-7.7.20130112/package.conf.d" update rts/package.conf.install /bin/sh: 1: /home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/lib/ghc-7.7.20130112/bin/ghc-pkg: not found /bbndk/host_10_0_9_404/linux/x86/usr/bin/i486-pc-nto-qnx8.0.0-ghc-pkg is a symlink to i486-pc-nto-qnx8.0.0-ghc-pkg-7.7.20130112 which does not exist (and I see no attempt to make it exist), and either way it seems that we are installing with a cross-compile prefix, but not invoking with that. -- 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
Pin a package?
Is there a way to tell cabal to refuse to upgrade a package? I'd like to pin my `bytestring` to the version that shipped with my GHC. I just had a weird experience. When I try to `cabal install iconv` (with my settings) it tried to downgrade my `bytestring`, when I download and do the configure+build by hand, it works, but when I try to install the local version it again begins to try to downgrade my bytestring. If I just `register --inplace` it works fine. Wut? -- 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
Environment variables in cabal config?
Is there any way to set the paths in my cabal-install config relative to $HOME or similar? I tried ~ and $HOME and neither of those worked. -- 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: Newtype wrappers
Somebody claiming to be Simon Peyton-Jones wrote: I'd like to propose a way to "promote" newtypes over their enclosing type. Here's the writeup http://hackage.haskell.org/trac/ghc/wiki/NewtypeWrappers The high-level idea, I love. I always wondered about `map MkAge blah`. Any comments? Below is the problem statement, taken from the above page. -1 to the unsoundness, but as you say, this is an existing problem. Also, instead of: newtype wrap somefun :: [Int] -> [Age] foo = somefun [12,14] Maybe: foo = ([12, 14] :: newtype wrap [Age]) I don't know how feasible this syntax is, but I like it a lot better, and it makes it more clear (to me) that this is purely type-level syntax. -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Newtype wrappers
Somebody claiming to be Simon Peyton-Jones wrote: * For x1 we can write map MkAge x1 :: [Age]. But this does not follow the newtype cost model: there will be runtime overhead from executing the map at runtime, and sharing will be lost too. Could GHC optimise the map somehow? My friend pointed out something interesting: If GHC can know that MkAge is just id (in terms of code, not in terms of type), which seems possible, and if the only interesting case is a Functor, which seems possible, then a RULE fmap id = id would solve this. No? -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
Somebody claiming to be Nathan Hüsken wrote: Was that an registerised or unregisterised build? Did anyone succesfully build ghc on an arm system which produces non crashing executables? Just finally got a BB10 device set up so I can test my cross-compiler on the ARM and I get: Process 26726597 (Main) terminated SIGSEGV code=2 fltno=11 ip=08bbf4c0(/accounts/1000/appdata/net.singpolyma.haskades_headlines.testDev_s_headlinesc1f463d0/app/native/Main@MD5Update+0xcc8d7) ref=e59d0040 Memory fault (core dumped) This seems related. I'm about to try a configuration with --enable-unregisterised to see if that helps. -- 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: any successfull ghc registerised builds on arm?
Somebody claiming to be Stephen Paul Weber wrote: Somebody claiming to be Nathan Hüsken wrote: Was that an registerised or unregisterised build? Did anyone succesfully build ghc on an arm system which produces non crashing executables? Just finally got a BB10 device set up so I can test my cross-compiler on the ARM I'm about to try a configuration with --enable-unregisterised to see if that helps. make -r --no-print-directory -f ghc.mk phase=final all "inplace/bin/ghc-stage1" -static -H64m -O0 -fasm-package-name integer-simple-0.1.1.0 -hide-all-packages -i -ilibraries/integer-simple/. -ilibraries/integer-simple/dist-install/build -ilibraries/integer-simple/dist-install/build/autogen -Ilibraries/integer-simple/dist-install/build -Ilibraries/integer-simple/dist-install/build/autogen -Ilibraries/integer-simple/. -optP-include -optPlibraries/integer-simple/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -package-name integer-simple -Wall -XHaskell98 -XCPP -XMagicHash -XBangPatterns -XUnboxedTuples -XForeignFunctionInterface -XUnliftedFFITypes -XNoImplicitPrelude -O -fasm -no-user-package-db -rtsopts -odir libraries/integer-simple/dist-install/build -hidir libraries/integer-simple/dist-install/build -stubdir libraries/integer-simple/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/integer-simple/./GHC/Integer/Type.hs -o libraries/integer-simple/dist-install/build/GHC/Integer/Type.o when making flags consistent: Warning: Compiler unregisterised, so compiling via C /tmp/ghc25891_0/ghc25891_0.hc: In function 'c2pA_entry': /tmp/ghc25891_0/ghc25891_0.hc:3691:1: warning: this decimal constant is unsigned only in ISO C90 [enabled by default] /tmp/ghc25891_0/ghc25891_0.hc:3691:17: error: expected ')' before numeric constant make[1]: *** [libraries/integer-simple/dist-install/build/GHC/Integer/Type.o] Error 1 make: *** [all] Error 2 I think I can configure it to use unregistered LLVM, so I'm off to try that, but this seems like a bug. -- 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: any successfull ghc registerised builds on arm?
Somebody claiming to be Stephen Paul Weber wrote: Somebody claiming to be Stephen Paul Weber wrote: Somebody claiming to be Nathan Hüsken wrote: Was that an registerised or unregisterised build? Did anyone succesfully build ghc on an arm system which produces non crashing executables? Just finally got a BB10 device set up so I can test my cross-compiler on the ARM I'm about to try a configuration with --enable-unregisterised to see if that helps. I think I can configure it to use unregistered LLVM, so I'm off to try that, but this seems like a bug. Trying that gives me: [ 1 of 68] Compiling Distribution.Compat.Exception ( libraries/Cabal/Cabal/Distribution/Compat/Exception.hs, bootstrapping/Distribution/Compat/Exception.o ) Warning: Couldn't figure out LLVM version! Make sure you have installed LLVM ghc: could not execute: opt-3.0 make[1]: *** [utils/ghc-cabal/dist/build/tmp/ghc-cabal] Error 1 make: *** [all] Error 2 I'm using LLVM 3.1. This errors makes no sense to me, because when I just use "quick" and not unregistered, it falls back to LLVM and works fine, but now I've selected "quick-llvm" and unregistered and it can't find it? -- 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: any successfull ghc registerised builds on arm?
Somebody claiming to be Ben Gamari wrote: Stephen Paul Weber writes: Trying that gives me: Warning: Couldn't figure out LLVM version! Make sure you have installed LLVM ghc: could not execute: opt-3.0 I'm using LLVM 3.1. Are you certain the opt-3.0 is in $PATH? It isn't installed. I'm using LLVM 3.1, and GHC correctly uses opt-3.1 when I try the registered build. -- 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: any successfull ghc registerised builds on arm?
Somebody claiming to be Karel Gardas wrote: I just build 7.6.1 release on my ubuntu 12.04.1 LTS which is hard-float ABI distro. I used distro provided LLVM 3.0 and configured GHC with: Please keep in mind that GHC HEAD is completely different beast as there is new codegen put on by defaul there and LLVM codegen is not working correctly with it yet. Oh? If LLVM codegen is broken in HEAD, that would explain why it's not working for ARM :) Hopefully I can get it working soon with at least an unregistered build. I have to build HEAD, since I'm doing cross-compiling. -- 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 and cross compilation
Somebody claiming to be Nathan Hüsken wrote: For that I changed cabal so that it recognizes android as a OS. But cabal seems to get its os information from System.Info.os, and from what I can tell this always returns the host os and not the target os. <https://github.com/haskell/cabal/issues/1184> -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
Somebody claiming to be Nathan Hüsken wrote: Hey, For me thinks have changed. With the current ghc HEAD and llvm version 3.2 I am able to do a registerised build for android! Do you think it is specifically the 3.2 that made it work? -- 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: any successfull ghc registerised builds on arm?
Somebody claiming to be Nathan Hüsken wrote: On 01/24/2013 03:58 PM, Stephen Paul Weber wrote: Somebody claiming to be Nathan Hüsken wrote: With the current ghc HEAD and llvm version 3.2 I am able to do a registerised build for android! Do you think it is specifically the 3.2 that made it work? Yes. With llvm version 3.1 I was only able to get an unregisterised build to work. Did you have to hack the source ala <http://hackage.haskell.org/trac/ghc/attachment/ticket/7621/unregistered-arm-llvm-hack.patch> ? Stephen Blackheath found that out, see here: http://www.haskell.org/pipermail/iphone/2013-January/000212.html From that post, it seems like llvm-3.0 might also work? -- 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: any successfull ghc registerised builds on arm?
Somebody claiming to be Nathan Hüsken wrote: On 01/24/2013 04:28 PM, Stephen Paul Weber wrote: Do you think it is specifically the 3.2 that made it work? Yes. With llvm version 3.1 I was only able to get an unregisterised build to work. <http://hackage.haskell.org/trac/ghc/attachment/ticket/7621/unregistered-arm-llvm-hack.patch> ? Not exactly, see the patch here: http://www.haskell.org/pipermail/ghc-devs/2013-January/000118.html and the changes to compiler/llvmGen/LlvmCodeGen/Ppr.hs Oh, man, the fact that I don't have that setting for QNX is probably not doing me any favours... How the heck am I supposed to figure out what that string should be? :( That said... how did you get an unregisterised build to work with an LLVM backend? Everything I've seen in the code implied that the moment you are unregisteried, it uses via-C... Which is what my above patch is primarily about. -- 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: any successfull ghc registerised builds on arm?
Somebody claiming to be Stephen Paul Weber wrote:
Somebody claiming to be Nathan Hüsken wrote:
On 01/24/2013 04:28 PM, Stephen Paul Weber wrote:
Do you think it is specifically the 3.2 that made it work?
Yes. With llvm version 3.1 I was only able to get an unregisterised
build to work.
<http://hackage.haskell.org/trac/ghc/attachment/ticket/7621/unregistered-arm-llvm-hack.patch>
?
Not exactly, see the patch here:
http://www.haskell.org/pipermail/ghc-devs/2013-January/000118.html
and the changes to compiler/llvmGen/LlvmCodeGen/Ppr.hs
Oh, man, the fact that I don't have that setting for QNX is probably
not doing me any favours...
I tried the following:
diff --git a/compiler/llvmGen/LlvmCodeGen/Ppr.hs
b/compiler/llvmGen/LlvmCodeGen/Ppr.hs
index 218870a..a583ffc 100644
--- a/compiler/llvmGen/LlvmCodeGen/Ppr.hs
+++ b/compiler/llvmGen/LlvmCodeGen/Ppr.hs
@@ -58,6 +58,9 @@ moduleLayout = sdocWithPlatform $ \platform ->
Platform { platformArch = ArchARM {}, platformOS = OSLinux } ->
text "target datalayout =
\"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:64:128-a0:0:64-n32\""
$+$ text "target triple = \"arm-unknown-linux-gnueabi\""
+Platform { platformArch = ArchARM {}, platformOS = OSQNXNTO } ->
+text "target datalayout =
\"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:64:128-a0:0:64-n32\""
+$+$ text "target triple = \"arm-unknown-nto-qnx8.0.0eabi\""
_ ->
-- FIX: Other targets
empty
Doing a registered build with llvm-3.0 I eventually get:
"inplace/bin/ghc-stage1" -o utils/hsc2hs/dist-install/build/tmp/hsc2hs -static -H64m -O0 -fllvm-hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist-install/build -iutils/hsc2hs/dist-install/build/autogen -Iutils/hsc2hs/dist-install/build -Iutils/hsc2hs/dist-install/build/autogen -optP-include -optPutils/hsc2hs/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package containers-0.5.0.0 -package directory-1.2.0.1 -package filepath-1.3.0.2 -package process-1.2.0.0 -XHaskell98 -XCPP -XForeignFunctionInterface -no-user-package-db -rtsopts -odir utils/hsc2hs/dist-install/build -hidir utils/hsc2hs/dist-install/build -stubdir utils/hsc2hs/dist-install/build -hisuf hi -osuf o -hcsuf hc utils/hsc2hs/dist-install/build/Main.o utils/hsc2hs/dist-install/build/HSCParser.o utils/hsc2hs/dist-install/build/DirectCodegen.o utils/hsc2hs/dist-install/build/CrossCodegen.o utils/hsc2hs/dist-install/build/UtilsCodegen.o utils/hsc2hs/dist-install/build/Common.o utils/hsc2hs/dist-install/build/C.o utils/hsc2hs/dist-install/build/Flags.o utils/hsc2hs/dist-install/build/Paths_hsc2hs.o
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/unix/dist-install/build/libHSunix-2.6.1.0.a(Signals.o): In function `c4Uj_info':
ghc23292_0.c:(.text+0x20d4): undefined reference to `__aeabi_memcpy'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/unix/dist-install/build/libHSunix-2.6.1.0.a(Signals.o):
In function `c4XO_info':
ghc23292_0.c:(.text+0x248c): undefined reference to `__aeabi_memcpy'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Buffer.o):
In function `c2Xe_info':
/tmp/ghc20698_0/ghc20698_0.bc:(.text+0x2558): undefined reference to
`__aeabi_memmove'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Internals.o):
In function `c7HG_info':
/tmp/ghc21290_0/ghc21290_0.bc:(.text+0x5e70): undefined reference to
`__aeabi_memmove'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Text.o):
In function `base_GHCziIOziHandleziText_zdwccall_info':
/tmp/ghc21310_0/ghc21310_0.bc:(.text+0x378): undefined reference to
`__aeabi_memcpy'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Text.o):
In function `c7s6_info':
/tmp/ghc21310_0/ghc21310_0.bc:(.text+0x4c4): undefined reference to
`__aeabi_memcpy'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Text.o):
In function `c9cs_info':
/tmp/ghc21310_0/ghc21310_0.bc:(.text+0x7588): undefined reference to
`__aeabi_memcpy'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Text.o):
In function `c9nS_info':
/tmp/ghc21310_0/ghc21310_0.bc:(.text+0x8318): undefined reference to
`__aeabi_memcpy'
/tmp/ghc21310_0/ghc21310_0.bc:(.text+0x83e4): undefined reference to
`__aeabi_memcpy'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Text.o):/tmp/ghc21310_0/ghc21310_0.bc:(.text+0xa2ec):
more undefined references to `__aeabi_memcpy' follow
/home/singpolyma/src/ghc-qnx-nto-arm/librar
Re: any successfull ghc registerised builds on arm?
Somebody claiming to be Nathan Hüsken wrote: On 01/24/2013 05:51 PM, Stephen Paul Weber wrote: (...) So... it can't find memcpy for some reason? I'm about to try with llvm-3.2 to see if that's different. The solution for me was to wrap mkfifo (in a function I called __mkfifo) and used that one from the ffi instead. Right, I see things around on the web about people doing similar stuff. But the symbol not found is __aeabi_memcpy, not memcpy itself ... I can not find __aeabi_memcpy in the ghc source ... Maybe it is not linking some required library? I'm not sure. Most curious is that this has not come up before in any of my other ARM-build attempts (which produced less-than-working code, but suceeded in compiling). -- 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: any successfull ghc registerised builds on arm?
Somebody claiming to be Stephen Paul Weber wrote: Somebody claiming to be Nathan Hüsken wrote: But the symbol not found is __aeabi_memcpy, not memcpy itself ... I can not find __aeabi_memcpy in the ghc source ... Maybe it is not linking some required library? I'm not sure. Most curious is that this has not come up before in any of my other ARM-build attempts (which produced less-than-working code, but suceeded in compiling). This seems to be a general ARM thing: <http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3934.html> ... so not sure why I'm getting it and no one else is. -- 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: any successfull ghc registerised builds on arm?
Somebody claiming to be Karel Gardas wrote: On 01/24/13 05:51 PM, Stephen Paul Weber wrote: Doing a registered build with llvm-3.0 I eventually get: In function `c58Y_info': /tmp/ghc21061_0/ghc21061_0.bc:(.text+0x42d4): undefined reference to `__aeabi_memcpy' collect2: ld returned 1 exit status make[1]: *** [utils/hsc2hs/dist-install/build/tmp/hsc2hs] Error 1 make: *** [all] Error 2 This is purely linker issue. Somehow you link with different set of libraries probably. Anyway it looks like: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3934.html -- this function is part of common ARM EABI so it should be implemented by your C compiler tool-chain. You just need to find out where it is and how you may use it. So, not sure on the right solution, but when I add -lcapsthen the linker errors go away and I can build executables. Unfortunately, when I try to run any of them on a device, I get a segfault, just as I always did with registerised cross-builds for ARM... this with both llvm-3.0 and llvm-3.2 :( -- 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: any successfull ghc registerised builds on arm?
Somebody claiming to be Nathan Hüsken wrote: On 01/24/2013 07:00 PM, Stephen Paul Weber wrote: Somebody claiming to be Karel Gardas wrote: On 01/24/13 05:51 PM, Stephen Paul Weber wrote: :( Can you run it in gdb and loock what the backtrace looks like? I can maybe get a core file and load it into gdb. I may try that soon. -- 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: any successfull ghc registerised builds on arm?
Somebody claiming to be Nathan Hüsken wrote: On 01/24/2013 07:00 PM, Stephen Paul Weber wrote: Somebody claiming to be Karel Gardas wrote: On 01/24/13 05:51 PM, Stephen Paul Weber wrote: So, not sure on the right solution, but when I add -lcapsthen the linker errors go away and I can build executables. Unfortunately, when I try to run any of them on a device, I get a segfault, just as I always did with registerised cross-builds for ARM... this with both llvm-3.0 and llvm-3.2 :( Can you run it in gdb and loock what the backtrace looks like? [New pid 14037182 tid 1] Program terminated with signal 11, Segmentation fault. #0 0x08502000 in ?? () (gdb) bt #0 0x08502000 in ?? () #1 0x082ce4c4 in ?? () #2 0x082ce4c4 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) -- 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: any successfull ghc registerised builds on arm?
Somebody claiming to be Nathan Hüsken wrote: On 01/24/2013 07:26 PM, Stephen Paul Weber wrote: Somebody claiming to be Nathan Hüsken wrote: Can you run it in gdb and loock what the backtrace looks like? Did you compile with -debug? I remember I got a stack trace with gdb like this (when doing remote debugging) and got it cleaned up by loading the exectuable with "file". Maybe you have to do something like that to? $ ntoarm-gdb --core=Main.core Main ... copyright and such ... [New pid 14336138 tid 1] warning: .dynamic section for "/home/singpolyma/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/libEGL.so.1" is not at the expected address (wrong library or version mismatch?) warning: .dynamic section for "/home/singpolyma/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/libGLESv2.so.1" is not at the expected address (wrong library or version mismatch?) Program terminated with signal 11, Segmentation fault. #0 0x08402000 in ?? () (gdb) bt #0 0x08402000 in ?? () #1 0x082de978 in stg_ap_p_fast () #2 0x082de978 in stg_ap_p_fast () Backtrace stopped: previous frame identical to this frame (corrupt stack?) -- 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: Size of crosscompiled exectuable
Somebody claiming to be Simon Marlow wrote: On 25/01/13 13:58, Nathan Hüsken wrote: A simple hello world application has 1Mb in by 64 bit ubunut machine. When I stript it, is has about 750kb. When I build a cross compiler for android (arm), the executable has a asize of about 10MB, stripped about 5MB. That is huge, five times the size on my linux sysem. Not sure what you mean by "five times the size on my linux system". What is 5 times larger than what? He's saying that the size of the android executable (made by his cross compiler) is five time the sive of the equivalent Ubuntu executable (made by, I assume, his system's GHC). The problem is not the size, but the size ratio. -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: base package (was: GHC 7.8 release?)
Somebody claiming to be Roman Cheplyaka wrote: * Simon Marlow [2013-02-13 09:00:15+] It's feasible to split base, but to a first approximation what you end up with is base renamed to ghc-base, and then the new base contains just stub modules that re-export stuff from ghc-base. It would be great to have a portable base, without any GHC-specific stuff in it. After all, modules like Control.Monad or Data.Foldable are pure Haskell2010. +1 -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: base package (Was: GHC 7.8 release?)
Somebody signing messages as Joachim Breitner wrote: I have started a wikipage with the list of all modules from base, for a first round of shuffling, grouping and brainstorming: http://hackage.haskell.org/trac/ghc/wiki/SplitBase Looks like a good start! Here's an idea: why not use the `haskell2010` package as one of the groupings? It seems like this sort of reorganisation could help solve the problem we currently have where one cannot using any of the features of `base` along with the `haskell2010` modules. -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: base package -- goals
Somebody claiming to be Ian Lynagh wrote: On Mon, Feb 25, 2013 at 02:31:56PM +0100, Joachim Breitner wrote: In any case there is still the problem: What and where is the Prelude... but maybe let’s postpone this. I'd put it in its own package for now, and then look at whether/what it should be merged with later. Why shouldn't Prelude (and other really stable, standard modules) just live in the `haskell2010` package? -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: base package -- goals
Somebody claiming to be Roman Cheplyaka wrote: * Stephen Paul Weber [2013-02-25 11:29:42-0500] Why shouldn't Prelude (and other really stable, standard modules) just live in the `haskell2010` package? Because then we can't make changes to it without producing a new language standard. That sounds like a good thing. Very in line with the goal of making stable modules more stable. -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overloaded record fields
Somebody claiming to be Simon Peyton-Jones wrote: It is kind of weird that f . g means\x. f (g x) but f.gmeansg f Anything that makes f.g mean something different from f . g just makes the code soup. F . g being different from F.g is already *very* unfortunate. The capital-letter makes it normally not too crazy, but sometimes you want to compose data constructors, and then it's a big issue. Making this issue worse in order to solve something else does not seem like a good trade-off. Why not use a different character? There are lots of them :) -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overloaded record fields
Somebody claiming to be Dominique Devriese wrote:
I would prefer to have dot notation for a
general, very tightly-binding reverse application, and the type of the record
selector for a field f changed to "forall r t. r { f :: t } => r -> t"
instead of
"SomeRecordType -> t". Such a general reverse application dot would
allow things like "string.toUpper"
If that's even possible, then we do not need the `.` at all, and can just
use perfectly normal function application.
If people want to create YetAnotherFunctionApplicationOperator, we can't
stop them, but no reason to include one (especially that overlaps with an
existing, more useful, operator)
--
Stephen Paul Weber, @singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph
signature.asc
Description: Digital signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Installing GHC and libgmp.so
Somebody claiming to be harry wrote: all of this stems from GHC looking for libgmp.so, instead of libgmp.so.3 Most systems symlink libgmp.so to the default version installed. On Debian stable it's libgmp.so.10 ... so it may work for you, but you may want to upgrade. -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Installing GHC and libgmp.so
Somebody claiming to be harry wrote: Stephen Paul Weber wrote Somebody claiming to be harry wrote: I also need to install GHC on systems where I don't have root access, so I can't create the link. You can create the link somewhere else, and use LD_LIBRARY_PATH I have done this before. If your version of libgmp is compatible, it should work. -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: bundled libraries in ghc
Somebody claiming to be Jens Petersen wrote: The libraries in question here are haskeline, terminfo, and xhtml. Are those libraries needed by GHCI? Could we just statically link those ones into GHC? -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overlapping and incoherent instances
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
>instance {-# OVERLAPPABLE #-} Show a => Show [a] where ...
>
>instance {-# OVERLAPPING #-} Show [Char] where ...
This, to me, is an admission that developers are not going to want to turn
overlapping on globally in general, and so the current language extensions
would not make sense to get adopted into the core language at any point.
I agree with this idea, and so would second the proposal mentioned at
<http://www.reddit.com/r/haskell/comments/2c136i/xoverlappinginstances_and_xincoherentinstances_to/cjb4jmr>
that a language extension that adds actual keywords to tag instances that
should be allowed to overlap be added, instead of resorting to pragmas.
This seems like an approach that could be useful in general and one could
imagine moving "past" an extension to the core language at some point,
potentially.
- --
Stephen Paul Weber, @singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAEBCAAGBQJT2DFBAAoJENEcKRHOUZzemmIQAJEbSjPyx745UI6mkuhBVhKl
LQWJlpu0/kzBHaFJl/mWcghKxoBFWwU+pCTh/Pr2oj0rp/KGskBLlplIqB4btZTA
ov2MpPrsHm1M37MuGyMtiBhs57UJE+saKKuvcH3qzLZyBCHorE3lFcKAFbNupBrL
e/vgNblQ70KGmDRAKqbAQHm9anoGeZUJPgQ9ylVEH4nBYLDo0YSNo/zTeB7fK2yv
xBE+Ul3YGfhzf82cLJhYNQOpi5wJ3JEDBevKXcGRzr4Mhzn2Lke+26tu0tx6sOSN
snPX2REoeQD1AfXvuNKSxV7BL+CQeyAOOmm2Isj3vW/oO3gkqpfRjCFc+ZSPEjlG
XQ3S7L7cgNB34rd6sOFzTv83PXvsH0a0d5RqKUM2kN/qGEjSbAQ1FVyJEUcaEmzr
jBnVnWq+abCOSOBg4joGfTxjq0zufdjxkzScEJVDVZ4pIXoxej7HJBi8UfIvo3Jo
EDMGGsLSedt4tR2LzYf/5up7GPfuBsFQQzuIcdgMG8/zYca7zWPJgyunlXAPcbzr
RvM/gf63SCBuVaQjrtv2Zhzp3PucWOL94NEmLYONU3uuEmo6bq1VO42fOUcl7X/1
UyhFbtoV7s/7PVClxdD4Ag9PumtSfl/CSvN0BA8AzDwTuHWNOPdThAHFqfAtRsD0
GyNzVRNOGuze9SqkLc4T
=YeKu
-END PGP SIGNATURE-
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overlapping and incoherent instances
Somebody signing messages as Felipe Lessa wrote: OTOH, the pragma is mostly harmless for older GHC versions, while the keyword approach needs a preprocessor. Only if *both* the old LANGUAGE pragma and the new pragma were employed, which will generate a deprecation warning for awhile and then eventually (likely) be rejected by newer GHCs, thus requiring a prepropcessor in either case. -- 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: Overlapping and incoherent instances
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 >I suppose that -XOverlappingInstances could mean "silently honour >OVERLAPPABLE/OVERLAPPING pragmas", while lacking it would mean "honour >OVERLAPPABLE/OVERLAPPING pragmas, but emit noisy warnings" or even "don't >honour them and warn". > >But that is different to the behaviour today, so we'd need a new LANGUAGE >pragma. Perhaps -XHonourOverlappingInstances or something. This would be a reasonable alternative to the keyword-based solution. At least for now. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJT45F5AAoJENEcKRHOUZzewwwQALUiK60sbIC6j5nbXHPCeau8 bN80pmhUL11lAyI7OCSQyV8S9AU7ikgaUPyKwk/cx/TtKQGLwghWFZlRCoCRrplk dmGsSCw2LN4GElHL22EcyELPcx74lknz3tmQuZg4oAUXm1h2w8774L3iHOE4Ompg 9gYzuOo8Ii3oHJ6fjIL0DwGWp92F8NrTPeQmziBOPHAgQYVFO8QMncXcOGtdIZUb PQr0szr9HLkcwKSrYoxvvZBqEj6AM0xj+KhX87NEnQ08EaY6FO/Dhm4mi7X/A5Ca khwsjwId0qR6C4vs7QyYnaK3yiUFlZMUlXdUhpRG3wWFHseb3m9tX2a2ewE30jPl TgnoU5NYphijMWXpc3p06D5Zj0lT6L++Y3Ez8CS+0QpBPG9c0CJnLqXFQ5CNbl+9 Ryzpg7ltg5vhtq7BLwcz+V87lzc4KYm/tyqEVvxN59W6XLuLLe4tW6NL9vLDl9Rg /3vMRYKZBa+0we7jAi/wYbdks7g+9sqpiLqke5m73a5F2j/TTl4BrkIj2vG0KrP+ G9eJC1aieUbfPXXwXWSJh8binJNp//qWs7rILDsx4r0o1QR245uT5WzwkwapXmE8 ZYuXsVcc1/mS1ZneOP6zn0QOlRcUJ0A5dFxQg69hsXpD+MM226r/57P3eI9XhLRN W+DNBoXbr9mp8eNGjl6O =CFkA -END PGP SIGNATURE- ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: The future of the Haskell98 and Haskell2010 packages
RebindableSyntax I thought this would work, but people seemed pretty sure we would need to do more work than RebindableSyntax to get everything in place. -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: "Found hole"
The leading underscore invokes the typed holes extension. If you want to
use such names, you'll need {-# LANGUAGE NoTypedHoles #-} as the first line
of the source file. (I am not sure why this extension was enabled by
default.)
This is very concening for me. Extensions should *never* be enabled by
default! When the TypedHoles discussion originally came up there was
definitely talk of using a switch to enable them (in fact, IIRC, they
weren't originally really quite an extension, just a compiler mode, but that
may have been a misinterpretation on my part).
Having them on by default mean that valid Haskell2010 programs might get
rejected by GHC by default, which is a pretty bad state of affairs.
--
Stephen Paul Weber, @singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph
signature.asc
Description: Digital signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: "Found hole"
Typed holes is not an extension, because it's considered a warning/error. The reason for this is that code with typed holes is NOT valid haskell to begin with, therefore the behaviour doesn't conflict with any description in the report. Well, now I feel very silly about my last email to this list. This is what I understood. I'm glad to see this is indeed the case. signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
