Re: RFC: changes to -i flag for finding source files
On 28 April 2014 18:40, Roman Cheplyaka r...@ro-che.info wrote: * Simon Marlow marlo...@gmail.com [2014-04-28 09:26:23+0100] No, the idea would be to use hs-source-dirs like this: hs-source-dirs: A.B.C=src Cabal just passes this in a -i option to GHC, so it almost Just Works, except that Cabal needs to preprocess some source files so it needs to find them, and also sdist needs to find source files. In that case, I'm in favour of this proposal. Please consider the reversed syntax instead: hs-source-dirs: src=A.B.C I find it more intuitive, because A.B.C becomes sort of an optional parameter, the empty prefix being its default value. src=A.B.C implies a 1-1 mapping between a srcdir and a module root, whereas A.B.C=src allows different modules (eg. all a project) to live in the same dir: Graphics.UI.Gtk=src System.IO.EEG=src Game.Flappy2048=src Conrad. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Release plans
On 20 March 2013 18:58, John Wiegley jo...@fpcomplete.com wrote: Ian Lynagh i...@well-typed.com writes: Would a 7.7.x recommended snapshot be useful to you? Tell us if you want one. I think that could very useful, sort of like what the Linux kernel did before they stopped. I'm never sure if building from HEAD will produce a compiler I should use for getting real work done, but I wouldn't have the same reservations concerning a 7.7.x interim developer release. likewise. I'd be happy with just a git tag and an email to this list every month or two indicating that there's a probably-ok version that could do with some testing. This could happen whenever a feature lands and the dust has settled a bit. Conrad. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Building on android - compiled program segfaults
On 11 January 2013 19:36, Nathan Hüsken nathan.hues...@posteo.de wrote: Hi, I was succesfull in building ghc (pulled from git) to compile for arm-linux-androideabi! Now using inplace/bin/ghc-stage1 -dcore-lint -debug I compiler this Main.hs: main = putStrLn Hello, World I get an executable, which I can run on my android device. Unfortantly it segfaults. Running it with ./Main +RTS -DS gives: cap 0: initialised Now I am trying to debug this in gdb. When I try to display the stack (which should be in r13 on arm of I understand correctly, I get); (gdb) p8 $r13 0xbef00a74: 0x0 0xbef00a70: 0x0 0xbef00a6c: 0x3c2e74 0xbef00a68: 0x530350 0xbef00a64: 0x0 0xbef00a60: 0x0 0xbef00a5c: 0x0 0xbef00a58: 0x0 And now I am clueless. So I tried the good old printf debugging in the rts. Using this, I see that it gets before the call to scheduleWaitThread in the function rts_evalLazyIO (in RtsAPI.c). But when I put a printf in the beginning of scheduleWaitThread (in Schedule.c) it is not shown. What else can I do to find out more? can you strace it? Conrad. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Should ghc -msse imply gcc -msse
On 11 January 2013 06:10, Johan Tibell johan.tib...@gmail.com wrote: Hi all, You can turn on e.g. SSE 4.1 by passing -msse4.2 to ghc. This doesn't currently imply that we compile any C code with -msse4.2 turned on, so if someone really want to use SSE4.2, they have to do: ghc -msse4,2 -optc-msse4.2 Do we want to change this so it's enough to pass -msse4.2 to ghc? +1, I'd expect the flag to affect all compiled code (I'd be passing -msse4.2 to make it go faster). If anyone really wanted the C code to be compiled without (perhaps for debugging the code generator), they could run something like: ghc -msse4,2 -optc-no-msse4.2 Conrad. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: build failures when hiding non-visible imports
On 21 August 2012 07:36, John Lato jwl...@gmail.com wrote: From: Brandon Allbery allber...@gmail.com On Sat, Aug 18, 2012 at 9:10 PM, Carter Schonwald carter.schonw...@gmail.com wrote: meaning: flags for treating it as a warning vs as an error? (pardon, i'm over thinking ambiguity in phrasing). if thats the desired difference, that sounds good to me! I would expect it means that, having demoted it to a warning, we would have -fwarn-hiding-no-target / -fno-warn-hiding-no-target (or whatever we call it) as with all other warnings. For warning vs. error, it seems to me that should be more general: perhaps taking any of the -f[no-]warn-* options and replacing warn with err. Yes. To be concrete, this is what I would like to see. In a statement of the form: import Module hiding (x) where Module doesn't export x, ghc should report a warning instead of an error This warning would be enabled/disabled by the usual flags (I like -fwarn-unused-import-hiding, but -fwarn-hiding-no-target is good too). The warning would be on by default. If a user wants this to be an error, I think -Werror should be sufficient. I am unable to think of any case where hiding a non-visible symbol would lead to errors on its own, and any errors likely to occur in tandem with this issue already have their own, more helpful, error conditions (e.g. symbols not in scope, symbols in a qualified import list not visible). I agree with Ganesh's point that it would be beneficial to have this available for ghc-7.6.1 if possible. +1 and it must be a warning (not error) by default, or else we will need to tell everyone to use cabal install --ghc-option=-fwarn-unused-import-hiding to install lots of packages on hackage (currently including things like HTTP and gtk2hs-buildtools, which are pulled in by many packages). Also, if this remains an error by default then it will become a sensible coding style to simply avoid using import hiding, to avoid build errors that will occur when some other library removes an interface (that you have explicitly marked as unused ...) Conrad. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
parallel build fixes for 7.4.2
Hi, recently we've been tweaking our internal build system at Tsuru to handle parallel builds of both cabal packages via 'cabal-sort --makefile' and our local code tree via 'ghc -M'. In addition to the recompilation checker fixes of #5878, the following would be great to have in 7.4.2: 1) http://hackage.haskell.org/trac/ghc/ticket/5891 -- the patch fixes a race condition in creating parent directories for built object files 2) master commit b6f94b5 Compile link .note section separately from main.c -- I think this is the patch that fixes link errors we've seen during parallel builds (via ghc -M) with 7.4.1, such as: /x/y/z.o: file not recognized: File truncated and: /usr/bin/ld: BFD (GNU Binutils for Ubuntu) 2.20.51-system.20100908 internal error, aborting at ../../bfd/merge.c line 872 in _bfd_merged_section_offset Will everything currently in master already be included in the next release or is it a separate branch? (If it's a separate branch I'll do some more testing to confirm that b6f94b5 is the patch that fixes the link error). Conrad. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: recompilation on --main-is
Hi Simon, I've tested with current master (commit 6f4a073) and the link time is back down. In fact the compile time seems fast in general, and an unrelated ld error which I hadn't yet tracked down has disappeared too. Thanks for the quick patch! Conrad. On 16 February 2012 19:45, Simon Marlow marlo...@gmail.com wrote: Will be fixed in 7.4.2: http://hackage.haskell.org/trac/ghc/ticket/5878 Cheers, Simon On 16/02/2012 05:10, Evan Laforge wrote: Thanks for bringing this up. I've been having the same problem and was thinking there was something wrong with my system. I have 3 main files and one util that they all import. Every build recompiles every file, even if there were no changes. On Feb 15, 2012 8:39 PM, Conrad Parker con...@metadecks.org mailto:con...@metadecks.org wrote: Hi, We have a project with around 200 Haskell source files, and around 20 executables which import these (as well as importing third-party libraries). We first build all the non-main files using a makefile generated with ghc -M. We then build the executables using a separate invocation of ghc --make --main-is foo.hs, for each foo.hs. This worked fine with ghc-7.2.1; each final ghc --make would simply link the pre-built object files -- but with ghc-7.4.1 all these files are recompiled for each target executable. As a result our full build takes around 10-20x longer with ghc-7.4.1 than ghc-7.2.1. Looking at compiler/iface/FlagChecker.hs, it seems that the --main-is flag is used as an input to the recompilation checker. It would make sense that --main-is should force recompilation of the particular file that exports 'main', but it also forces recompilation of its dependencies. Is this a bug or is there a good reason to recompile everything? Conrad. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org mailto: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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
recompilation on --main-is
Hi, We have a project with around 200 Haskell source files, and around 20 executables which import these (as well as importing third-party libraries). We first build all the non-main files using a makefile generated with ghc -M. We then build the executables using a separate invocation of ghc --make --main-is foo.hs, for each foo.hs. This worked fine with ghc-7.2.1; each final ghc --make would simply link the pre-built object files -- but with ghc-7.4.1 all these files are recompiled for each target executable. As a result our full build takes around 10-20x longer with ghc-7.4.1 than ghc-7.2.1. Looking at compiler/iface/FlagChecker.hs, it seems that the --main-is flag is used as an input to the recompilation checker. It would make sense that --main-is should force recompilation of the particular file that exports 'main', but it also forces recompilation of its dependencies. Is this a bug or is there a good reason to recompile everything? Conrad. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
