Re: Weird failure of ghc-7.0.2 on OS X 10.5 using the bindist tarball
It turns out that even an i386 build made on 10.6 won't work on 10.5: http://hackage.haskell.org/trac/ghc/ticket/4996 And even if this is fixable, it won't help, as we'll have to drop 10.5 support in order to support XCode 4: http://hackage.haskell.org/trac/ghc/ticket/5011 If you build GHC yourself then it should work, though. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: trac ticket spam
On Sat, Mar 12, 2011 at 10:13:07PM +, Simon Marlow wrote: On 12/03/11 09:00, Max Bolingbroke wrote: There is this plugin: https://software.sandia.gov/trac/fast/wiki/TicketModerator The TicketModerator plugin is an extension for the Trac project Possibly useful? Maybe. Before we look into that, I've also mentioned to Ian that I'm somewhat suspicious about the current spam plugin - I don't think it's actually working properly. The log is supposed to list every content submission, but it only has a paultry few, suggesting that most content submissions are not actually being piped through the spam filter. I was looking at this earlier today. Those that are in the monitor list have anonymous as the author (prsumably due to people getting logged out), so I wonder if comments from authenticated users are going via a different path. I fiddled with various things, and enabled logging, but am no further forward. The easiest way forward would probably be to upgrade to trac 0.12, except it's not packaged for Debian (even in unstable). Maybe installing trac from source is the best way forward. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
7.0.3
Hi all, Due to a number of issues in the 7.0.2 release, we plan to put out a 7.0.3 release before finally retiring the 7.0 branch. We intend to fix: * Doc install location on Windows * Doc building on OS X (#4997) * Object splitting on OS X (with XCode = 3.2) * Don't require the 10.5 SDK on OS X (should mean GHC works with XCode 4) We will also look into the problems with stripping and libHSghc.a (e.g. the issue building yesod #5004), and the ld warnings on OS X (#4984). We want to keep the changes in this release to a minimum, to minimise the chance of regressions, but if you think we've missed any critical issues please let us know. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 7.0.3
On Tue, Mar 15, 2011 at 10:17:24AM -0700, Don Stewart wrote: ETA? As soon as we can fix what we want to fix, and get the builds done. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 7.0.3
On Tue, Mar 15, 2011 at 02:46:37PM -0700, David Terei wrote: Could you merge my fix for this: http://hackage.haskell.org/trac/ghc/ticket/4995 So patch is: Wed Mar 9 13:53:46 PST 2011 David Terei davidte...@gmail.com * LLVM: Fix #4995, llvm mangler broken for large compiles Its a pretty small change and fixes an ugly issue with the LLVM backend on OSX. Done! Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: MacOS 10.5 was:Re: cabal install network was: ...
On Thu, Mar 17, 2011 at 02:03:15PM +0100, Christian Maeder wrote: Am 17.03.2011 12:49, schrieb Christian Maeder: Am 23.02.2011 15:41, schrieb Ian Lynagh: On Tue, Feb 22, 2011 at 05:17:35PM +0100, Christian Maeder wrote: Am 22.02.2011 14:47, schrieb Ian Lynagh: On Tue, Feb 22, 2011 at 09:59:20AM +0100, Christian Maeder wrote: Where does cabal get its flags from? (hardcoded?) From the C compiler flags, Gcc Linker flags and Ld Linker flags entries in ghc --info's output. Since the sdk flags will be gone in ghc-7.0.3, re-adding them via the command-line will not pass them to cabal. Should not more flags be passed to cabal? It still makes sense to pass these sdk flags, if one wants to produce portable binaries. We can't support both 10.5 and XCode 4: http://hackage.haskell.org/trac/ghc/ticket/5011 Building GHC on 10.5 still ought to work (but we can no longer support it as a tier 1 platform). Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Documentation build failure
On Sun, Mar 06, 2011 at 01:05:12AM +, Ian Lynagh wrote:
On Sat, Mar 05, 2011 at 01:20:03PM +0100, Malte Sommerkorn wrote:
Building the ps/pdf documentation works only with a specific, outdated
version of dblatex
I've just won a battle with dblatex to get the docs built on OS X. If
you're having problems then the attached may be of help.
Thanks
Ian
From http://www.tug.org/mactex/ downloaded and installed
http://mirror.ctan.org/systems/mac/mactex/MacTeX.mpkg.zip
From http://dblatex.sourceforge.net/ downloaded and built
http://prdownloads.sourceforge.net/dblatex/dblatex-0.3.tar.bz2?download
Now building users_guide.pdf will fail, as we generate things like:
ͱt\nolinkurl{ͰuC:\Documentsͱu}\texttt{\ }\nolin[...]
rather than:
ͱt\nolinkurl{ͰuC:\\Documentsͱu}\texttt{\ }\nolin[...]
(note number of backslashes). To fix this, patch param.xsl:
--- param.xsl 2011-03-18 18:10:23.0 +
+++ /usr/share/dblatex/xsl/param.xsl2010-10-27 08:56:16.0 +0100
@@ -16,7 +16,7 @@
xsl:param name=latex.class.articlearticle/xsl:param
xsl:param name=latex.class.bookreport/xsl:param
xsl:param name=latex.unicode.use0/xsl:param
-xsl:param name=texlive.version2010/xsl:param
+xsl:param name=texlive.version2009/xsl:param
This is a little odd. The Debian package has this patch applied, and on
Debian:
$ latex --version
pdfTeX 3.1415926-1.40.10-2.2 (TeX Live 2009/Debian)
[...]
but on OS X:
$ latex --version
pdfTeX 3.1415926-1.40.11-2.2 (TeX Live 2010)
[...]
so it doesn't seem like it should be needed. But anyway...
Now the PDF will fail to build with:
makeindex: Not writing to /private/tmp/tmpw4xTzV/users_guide.ind
(openout_any = p).
Can't create output index file /private/tmp/tmpw4xTzV/users_guide.ind.
So we put
openout_any = r
in /usr/local/texlive/2010/texmf.cnf
And the docs will finally build!
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: testing 7.02-candidate
Hi Serge, [ 3 of 17] Compiling T_cubeext( T_cubeext.hs, T_cubeext.o ) T_cubeext.hs:143:9: Overlapping instances for LinSolvRing (UPol k) arising from a use of `ct' Matching instances: instance [overlap ok] EuclideanRing a = LinSolvRing (UPol a) -- Defined in docon-2.12:Pol2_ instance [overlap ok] (LinSolvRing (Pol a), CommutativeRing a) = LinSolvRing (UPol (Pol a)) -- Defined in docon-2.12:Pol3_ (The choice depends on the instantiation of `k' To pick the first instance above, use -XIncoherentInstances when compiling the other instance declarations) In the first argument of `(.)', namely `ct unE' In the expression: ct unE . kToB In an equation for `kToE': kToE = ct unE . kToB Thanks for the report. I've taken a look, but it'll need someone like Simon or Dimitrios to give a definitive answer as to which behaviour is right and which is wrong. I've put a cut-down (but not standalone) version of the offending module below. I believe the relevant steps are then: The ct application means we need an instance for: Cast (ResidueI (Pol (ResidueE (UPol k (Pol (ResidueE (UPol k))) Need: Cast (ResidueI (Pol (ResidueE (UPol k (Pol (ResidueE (UPol k))) Have: instance LinSolvRing a = Cast (ResidueI a) a Now need: LinSolvRing (Pol (ResidueE (UPol k))) Have: instance EuclideanRing a = LinSolvRing (Pol a) Now need: EuclideanRing (ResidueE (UPol k)) Have: instance (EuclideanRing a, Ring (ResidueE a) ) = EuclideanRing (ResidueE a) Now need: EuclideanRing (UPol k) Have: instance Field a = EuclideanRing (UPol a) Now need: LinSolvRing (UPol k)(from the EuclideanRing class constraints) Have: instance EuclideanRing a = LinSolvRing (UPol a) (Pol2_.hs:95) And: instance (LinSolvRing (Pol a), CommutativeRing a) = LinSolvRing (UPol (Pol a)) A different instance should be used depending on whether or not k = Pol x (for some x). module T_cubeext (cubicExt) where import Prelude (undefined) import DPrelude (ct) import Categs (ResidueE) import SetGroup () import RingModule (Field, FactorizationRing) import VecMatr () import Fraction () import Pol (Pol, UPol) import Residue (ResidueI) import GBasis () cubicExt :: forall k . (Field k, FactorizationRing (UPol k)) = k - () cubicExt _ = undefined where unE :: ResidueI (Pol (ResidueE (UPol k))) unE = undefined kToE :: Pol (ResidueE (UPol k)) - ResidueI (Pol (ResidueE (UPol k))) kToE = ct unE Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Issue with SrcSpan of AbsBinds
Hi JP, On Fri, Mar 18, 2011 at 02:51:36PM +0100, JP Moresmau wrote: And the TypecheckedSource gives me something like (using the ghc-syb-utils package to dump it:) Can you file a ticket with complete reproduction instructions please? Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ANNOUNCE: GHC version 7.0.3
= The (Interactive) Glasgow Haskell Compiler -- version 7.0.3 = The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a handful of bugfixes relative to 7.0.2, so we recommend upgrading. The release notes are here: http://www.haskell.org/ghc/docs/7.0.3/html/users_guide/release-7-0-3.html How to get it ~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 7.0.3
On Tue, Mar 29, 2011 at 10:12:15PM -0400, wren ng thornton wrote:
2695 total tests, which gave rise to
14978 test cases, of which
0 caused framework failures
12589 were skipped
2302 expected passes
74 expected failures
0 unexpected passes
13 unexpected failures
The number of things skipped is remarkably high compared to ghc
6.12.{1,3}. I don't have the 7.0.2 testsuite results on hand though.
Hmm, with a full testsuite run for the HEAD (validate, so no profiling)
on OS X i386 I get:
OVERALL SUMMARY for test run started at Wed Mar 30 19:06:13 BST 2011
2710 total tests, which gave rise to
9066 test cases, of which
0 caused framework failures
1701 were skipped
7070 expected passes
242 expected failures
0 unexpected passes
53 unexpected failures
The fast testsuite gave:
OVERALL SUMMARY for test run started at Wed Mar 30 13:54:50 BST 2011
2710 total tests, which gave rise to
9062 test cases, of which
0 caused framework failures
6662 were skipped
2313 expected passes
84 expected failures
0 unexpected passes
3 unexpected failures
(the testsuite may have changed slightly between the two runs)
So I don't think there's any problem in HEAD, at least.
Thanks
Ian
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Rebuilding ghc changes interface hashes?
On Tue, Apr 05, 2011 at 08:51:52PM +0100, Simon Marlow wrote: On 05/04/11 17:51, Matthias Kilian wrote: On Tue, Apr 05, 2011 at 09:59:23PM +0530, Joachim Breitner wrote: Also, the initial upload was built using ghc-6.12.1, while the upload now is build with ghc-7.0.2. Given that it is a two-stage compiler, I assume that the output should be identical, but it seems not to be the case. Changing the bootstrapping compiler changes the ABIs. The same can happen if you interrupt and restart the build. In general changes can creep in randomly, there's no direct link between changing the bootstrap compiler and getting different compilation results (as far as I know) compiler/stage2/build/Config.hs includes cBooterVersion, so if you boot with a different version then you get different code = different ABI. We could just remove this. In theory, stage2 won't be affected by the bootstrapping compiler at all anyway. Alternatively, if we make a config file (as we were discussing for putting the paths to gcc and ar in) then it could go in there, and then wouldn't be part of the ABI. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Broken ghc-7.0.3/vector combination?
On Wed, Apr 20, 2011 at 05:02:50PM +0200, Daniel Fischer wrote: So, is it possible that some change in ghc-7.0.3 vs. the previous versions Very little changed between 7.0.2 and 7.0.3. The only thing that jumps out to me as possibly being relevant is: diff -ur 7.0.2/ghc-7.0.2/compiler/nativeGen/X86/Instr.hs 7.0.3/ghc-7.0.3/compiler/nativeGen/X86/Instr.hs --- 7.0.2/ghc-7.0.2/compiler/nativeGen/X86/Instr.hs 2011-02-28 18:10:06.0 + +++ 7.0.3/ghc-7.0.3/compiler/nativeGen/X86/Instr.hs 2011-03-26 18:10:04.0 + @@ -734,6 +734,7 @@ where p insn r = case insn of CALL _ _ - GFREE : insn : r JMP _- GFREE : insn : r +JXX_GBL _ _ - GFREE : insn : r _- insn : r Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Head does not build on OS X
On Fri, Apr 22, 2011 at 08:53:44AM +0200, Johan Tibell wrote: Here's the error. I've run make clean, but it didn't help: It sounds like you need to run perl boot. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ANNOUNCE: GHC 7.0.4 Release Candidate 1
We are pleased to announce the first release candidate for GHC 7.0.4: http://www.haskell.org/ghc/dist/7.0.4-rc1/ This includes the source tarball, installers for OS X and Windows, and bindists for amd64/Linux, i386/Linux, amd64/FreeBSD and i386/FreeBSD. Please test as much as possible; bugs are much cheaper if we find them before the release! Release notes: * A floating point regression in 7.0.3 affecting x86 has been fixed (#5149). * The GHCi linker now handles partially stripped object files (#5004). This fixes loading the ghc package in ghci when it's been stripped, which is often the case in Linux distribution packages. * A runtime system bug with large heaps has been fixed (#5086). * A runtime system bug when heap profiling has been fixed (#5127). * A runtime system bug when heap profiling has been fixed (#5127). * A runtime system bug, which caused incorrect results and segfaults when using FFI callbacks, has been fixed. * A runtime system bug, which occasionally caused parallel programs to loop when using -feager-blackholing, has been fixed (#5226). * Incorrect directory permissions when installing have been fixed (#4982). * Some improvements have been made to the new Cabal testsuite support. * Cabal is now 1.10.2.0 (was 1.10.1.0). 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
Re: Compiling 32-bit GHC on a 64-bit Mac
On Sun, Jun 05, 2011 at 02:10:39PM +0200, Johan Tibell wrote: I need to reproduce a bug that only appears on 32-bit machines. I don't own such a machine but I was hoping I could compile a 32-bit GHC on my Mac and debug using that. What changes do I need to make (e.g. to build/mk) to build a 32-bit GHC? Install http://www.haskell.org/ghc/dist/7.0.3/ghc-7.0.3-i386-apple-darwin.tar.bz2 and make sure its ghc is first in your path. Then build as normal. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to install GhC on a Mac without registering?
On Mon, Jun 06, 2011 at 03:47:57PM +0100, Malcolm Wallace wrote: On 6 Jun 2011, at 13:49, Lyndon Maydwell wrote: I would be fantastic if XCode wasn't a dependency. ... Not to detract at all from the work of the wonderful GHC and Haskell Platform contributors in any way. For me it would just make it that much easier to convince mac-using friends to give Haskell a try. The ghc team already bundle a copy of gcc in their Windows distribution, precisely because it can be fiddly to get a working copy of gcc for that platform otherwise. I wonder if they would consider the possibility of shipping gcc on Mac too? (There may be good reasons not to do that, but let's have the discussion.) I'm pretty sure we aren't allowed to redistribute XCode. As well as gcc and friends, I think XCode also includes various headers and/or libraries that we need. If there is an alternative - especially one that allows us to support multiple versions of OS X more easily - then using it may make sense. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ANNOUNCE: GHC version 7.0.4
= The (Interactive) Glasgow Haskell Compiler -- version 7.0.4 = The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a handful of bugfixes relative to 7.0.3, so we recommend upgrading. The release notes are here: http://www.haskell.org/ghc/docs/7.0.4/html/users_guide/release-7-0-4.html How to get it ~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC and Haskell 98
On Mon, Jun 20, 2011 at 12:43:37PM +0100, Paterson, Ross wrote: Simon Peyton-Jones writes: (Plan A) Add a module 'Prelude' to package 'haskell98'. Now you can compile a pure H98 program thus: ghc -c Main.hs -hide-all-packages -package haskell98 (Cabal puts the -hide-all-packages in for you.) And this will continue to work even if later iterations of Haskell change the Prelude. So Plan A also involves hiding the haskell98 package by default? Yes. This puts it in the same category as haskell2010, which is already hidden by default in GHC 7.0. Also, note that hiding makes no difference when using Cabal. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ANNOUNCE: GHC 7.2.1 Release Candidate 1
We are pleased to announce the first release candidate for GHC 7.2.1: http://www.haskell.org/ghc/dist/7.2.1-rc1/ This includes the source and testsuite tarballs, installers for OS X and Windows, and bindists for amd64/Linux, i386/Linux, amd64/FreeBSD and i386/FreeBSD. 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
Re: integer-simple
On Fri, Jul 29, 2011 at 05:51:23PM +0100, Chris Dornan wrote: But when I repeat with INTEGER_LIBRARY = integer-simple (on quick test) GHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help Note that 6.12.3 is quite old now, and neither that branch or the 7.0 branch are still being developed. By quick test do you mean the quickest build flavour from mk/build.mk.sample? I've just validated HEAD with INTEGER_LIBRARY=integer-simple and the build went through fine, and ghci works. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC API output files options problem
Hi Marianna,
On Sun, Jul 17, 2011 at 12:11:57PM +0200, Marianna Rapoport wrote:
Thus, test_ghc.sh and test_my.sh should do the same, but the first works
correctly while the latter puts use.o and use.hi to the src folder.
I'm no expert on the GHC API, but replacing doWalk with this seems to do
what you want:
import GhcMonad
import GHC
import HscTypes
import DriverPhases
import DriverPipeline
doWalk :: [String] - String - Ghc ()
doWalk cmdFlags file = do
flg - getSessionDynFlags
(flg, _, _) - parseDynamicFlags flg (map noLoc cmdFlags)
setSessionDynFlags flg { ghcLink = NoLink, ghcMode = OneShot }
hsc_env - GHC.getSession
let srcs = [(file, Nothing)]
liftIO $ oneShot hsc_env StopLn srcs
Thanks
Ian
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: possible strictness bug in profiled version of a program
On Mon, Jul 25, 2011 at 06:21:16PM +0200, Peter Hercek wrote: Is it a bug? Should it be reported to the ghc trac database? Please report it and we'll take a look. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: hsc2hs and #include
On Sat, Jul 30, 2011 at 09:10:21PM +, Evan Laforge wrote: On Sat, Jul 30, 2011 at 8:32 PM, Edward Z. Yang ezy...@mit.edu wrote: This is supposed to get defined as a command line argument to the preprocessor, see compiler/main/DriverPipeline.hs. Are you saying you don't see it when you run hsc2hs? Maybe someone else is calling a preprocessor but missing some of these arguments... Yes, I don't see it when I run hsc2hs. I don't see how a define from ghc is going to make it into the hsc2hs generated C file, since it just compiles the c file with no special flags. I think the right thing to do would be to have all the #if __GLASGOW_HASKELL__ ... lines be printf'd by the C program, so they end up in the generated Haskell file. But I also think we may as well just remove most of these conditionals. The GHC 4.09 tests can surely be removed, and likewise the GHC 6.3 tests. Personally I'd remove the GHC 6.10 test too, but perhaps that will be more contentious. Any opinions? Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCJS
On Wed, Aug 03, 2011 at 11:44:10AM +0100, Simon Marlow wrote: On 03/08/2011 11:09, Victor Nazarov wrote: On Wed, Aug 3, 2011 at 11:30 AM, Simon Peyton-Jones simo...@microsoft.com wrote: So perhaps that's the problem. parseDynamicFlags could perfectly well simply return any un-recognised flags. Indeed, I thought it did just that -- it certainly returns a list of un-consumed arguments. If it doesn't perhaps that's a bug. parseDynamicFlags returns un-consumed arguments if they are something like filenames, but it throws error if un-consumed argument starts with dash. So then parseDynamicFlags should be split into two layers, the lower layer returning unused flags, and the upper layer generating errors. It's not that simple. In ghcjs -O -someflag something -Wall is something an argument to someflag, or a file to be compiled? I think the best approach is to make a variant parseDynamicFlagsAnd which takes an extra argument of type [Flag (CmdLineP DynFlags)] which it prepends to dynamic_flags. Otherwise there's Edward's suggestion, but it would be a bit depressing to have to use -- even for the simplest invocations, e.g. ghcjs -- -O foo.hs although I guess you could mirror the most common GHC flags as ghcjs flags. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.2.1 Release Candidate 1
On Thu, Aug 04, 2011 at 12:51:01PM +0100, Simon Marlow wrote: On 04/08/2011 05:35, Jens Petersen wrote: On 3 August 2011 19:01, Jens Petersenj...@community.haskell.org wrote: Unexpected failures: [...] ffi/should_run fed001 [bad exit code] (normal) [...] from http://koji.fedoraproject.org/koji/getfile?taskID=3251249name=build.log . The packages can be downloaded and installed as described in the previous mail from http://kojipkgs.fedoraproject.org/scratch/petersen/task_3251246 This looks like breakage in foreign import wrapper. That's pretty serious - please open a ticket, and include as many details as possible. The build log says: = fed001(normal) 634 of 2894 [0, 0, 0] cd ./ffi/should_run '/builddir/build/BUILD/ghc-7.2.0.20110728/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts -o fed001 fed001.hsfed001.comp.stderr 21 cd ./ffi/should_run ./fed001/dev/null fed001.run.stdout 2fed001.run.stderr /bin/sh: line 1: 32288 Segmentation fault ./fed001 /dev/null fed001.run.stdout 2 fed001.run.stderr Wrong exit code (expected 0 , actual 139 ) Stdout: Stderr: *** unexpected failure for fed001(normal) but it works fine for me on x86/Linux. Note the Fedora build is patched to use system libffi. Hmm. What happens if you don't patch it? Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.2.1 Release Candidate 1
On Sat, Jul 30, 2011 at 10:57:40PM +1000, Manuel M T Chakravarty wrote: The RC unfortunately doesn't build on Lion (OS X 10.7). I've put the latest 7.2 source here, along with OS X builds: http://www.haskell.org/ghc/dist/7.2.1-rc2/ My guess is that the bindists will work on Lion, but that the installers will use the wrong gcc. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 7.2.1-rc1 fails to build on kfreebsd-*, mips*, s390 and sparc
On Sun, Aug 07, 2011 at 01:34:41PM +0200, Joachim Breitner wrote: The causes seem to be different. On kfreebsd, we get: ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.2.0.20110728 for i386-unknown-kfreebsdgnu): Don't know if OSUnknown is elf This might be something that is easy to fix in compiler/utils/Platform.hs, but you will know better if one should add a new OS value, or reuse OSFreeBSD. I think using OSFreeBSD is probably best. We can always add another one later. I'll add a case for it to Platforms. On the other architectures there are complaints about static declarations following non-static declaration that I do not understand. I hope you do :-) This should already be fixed: http://hackage.haskell.org/trac/ghc/ticket/5357 Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.2.1 Release Candidate 1
On Mon, Aug 08, 2011 at 11:20:18PM +1000, Manuel M T Chakravarty wrote: Ian Lynagh: On Sat, Jul 30, 2011 at 10:57:40PM +1000, Manuel M T Chakravarty wrote: The RC unfortunately doesn't build on Lion (OS X 10.7). I've put the latest 7.2 source here, along with OS X builds: http://www.haskell.org/ghc/dist/7.2.1-rc2/ My guess is that the bindists will work on Lion, but that the installers will use the wrong gcc. I tested the 64-bit bindists and compiled the source from scratch on Lion. It all works. Great, thanks! You are right that the bindists use the default gcc (i.e., the one with the LLVM backend). That is ok, though, as GHC supplies the stack unwinding linker option. Do you really mean the bindists (i.e. the .tar.bz2 files), rather than the installers (.pkg)? Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: hsc2hs and #include
On Mon, Aug 08, 2011 at 06:44:29PM -0700, Evan Laforge wrote: So... remove it all? I've done so. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.2.1 Release Candidate 1
On Tue, Aug 09, 2011 at 10:52:39AM +1000, Manuel M T Chakravarty wrote: Ian Lynagh: On Mon, Aug 08, 2011 at 11:20:18PM +1000, Manuel M T Chakravarty wrote: Ian Lynagh: You are right that the bindists use the default gcc (i.e., the one with the LLVM backend). That is ok, though, as GHC supplies the stack unwinding linker option. Do you really mean the bindists (i.e. the .tar.bz2 files), rather than the installers (.pkg)? Yes, I mean the tar.bz2 file. When I unpack it on Lion and run ./configure, configure picks '/usr/bin/gcc' and not '/usr/bin/gcc-4.2' as the C compiler. (I can force it to use gcc-4.2 with '--with-gcc=/usr/bin/gcc-4.2'.) Hmm, odd. I've filed #5397 and I'll investigate later. P.S.: The .pkg package uses a bindist internally. (At least, that was how my original implementation of the packaging worked.) So, the two should usually behave the same. It uses an installed bindist, I believe, so configure was run on my Mac (XCode 4) rather than yours (XCode = 4). Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ANNOUNCE: GHC version 7.2.1
= The (Interactive) Glasgow Haskell Compiler -- version 7.2.1 = The GHC Team is pleased to announce a new major release of GHC, 7.2.1. The 7.2 branch is intended to be more of a technology preview than normal GHC stable branches; in particular, it supports a significantly improved version of DPH, as well as new features such as compiler plugins and safe Haskell. The design of these new features may evolve as we get more experience with them. See the release notes for more details of what's new and what's changed. We are also using this branch as an opportunity to work out the best workflows to use with git. We expect the 7.2 branch to be short-lived, with 7.4.1 coming out shortly after ICFP as normal. Full release notes are here: http://www.haskell.org/ghc/docs/7.2.1/html/users_guide/release-7-2-1.html How to get it ~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: With every new GHC release, also released any new versions of libraries
On Thu, Aug 25, 2011 at 01:36:13PM +0200, Johan Tibell wrote: On Thu, Aug 25, 2011 at 11:28 AM, Daniel Fischer daniel.is.fisc...@googlemail.com wrote: On Thursday 25 August 2011, 10:39:29, Johan Tibell wrote: P.S. Could someone please remind me why containers ships with GHC? Some other packages shipped with GHC depend on containers, e.g. hoopl, template-haskell, haskeline, binary. So GHC uses some packages in its implementation, but that shouldn't have to mean that it also needs to export these. Is this a technical issue? GHC needs to ship with anything that ghc-the-library transitively depends on, yes. As a thought experiment lets consider what would happen if GHC would like to use unordered-containers in its implementation. Should GHC now be making releases to unordered-containers? That doesn't sound like a good thing. There are certainly disadvantages to making GHC use a library. yes. We have to weigh them up against the advantages we get from using the library. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: With every new GHC release, also released any new versions of libraries
On Thu, Aug 25, 2011 at 10:39:29AM +0200, Johan Tibell wrote: I suggest that with each GHC release the new library releases should be uploaded to Hackage. They normally are, but in this case I ran out of time before disappearing for 2 weeks. They're now uploaded. Sorry for any inconvenience. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
On Thu, Sep 15, 2011 at 08:47:30AM +, Simon Peyton-Jones wrote: Provoked the (very constructive) Yesod blog post on Limitations of Haskell, and the follow up discussion, I've started a wiki page to collect whatever ideas we have about the name spacing issue for record fields. http://hackage.haskell.org/trac/ghc/wiki/Records As Simon M said on Reddit, this is something we'd like to fix; but we need a consensus on how to fix it. Re TypeDirectedNameResolution, I would actually prefer it if it were less general. i.e. if you were to write x.f then f would be required to be a record selector. Then there's no need for the If there is exactly one f whose type matches that of x unpleasantness. Instead, the type of x must be inferred first (without any knowledge about the type of f), and then we know immediately which f is being referred to. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
--make et al not in flags.sgml?
Hi, Is there a reason --make and friends aren't in flags.sgml? This means they don't end up in the man page I generate. I've attached a patch that adds an entry for them, text mostly stolen from elsewhere in the docs. Thanks Ian --- ghc6-6.2.2.orig/ghc/docs/users_guide/flags.sgml +++ ghc6-6.2.2/ghc/docs/users_guide/flags.sgml @@ -117,6 +117,55 @@ /sect2 sect2 + titleAlternative modes of operation (xref linkend=modes)/title + + informaltable + tgroup cols=3 align=left colsep=1 rowsep=1 + thead + row + entryFlag/entry + entryDescription/entry + entryStatic/Dynamic/entry + entryReverse/entry + /row + /thead + tbody + row + entryoption--interactive/option/entry + entryInteractive mode - normally used by just running commandghci/command/entry + entrystatic/entry + entry-/entry + /row + row + entryoption--make/option/entry + entryBuild a multi-module Haskell program, automatically figuring out dependencies. Likely to be much easier, and faster, than using commandmake/command./entry + entrystatic/entry + entry-/entry + /row + row + entryoption-e replaceableexpr/replaceable/option/entry + entryEvaluate replaceableexpr/replaceable/entry + entrystatic/entry + entry-/entry + /row + row + entryoption-M/option/entry + entryGenerate dependency information suitable for use in a filenameMakefile/filename./entry + entrystatic/entry + entry-/entry + /row + row + entryoption--mk-dll/option/entry + entryDLL-creation mode (Windows only)/entry + entrystatic/entry + entry-/entry + /row + /tbody + /tgroup + /informaltable +/sect2 + +sect2 titleRedirecting output (xref linkend=options-output)/title informaltable ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
happy and OPTIONS pragmas
Hi,
If I have this at the start of a .x file:
{
{-# OPTIONS -w #-}
module Lexer (lex_tok) where
}
then the generated .hs file starts:
{-# OPTIONS -cpp #-}
{-# LINE 2 Lexer.x #-}
{-# OPTIONS -w #-}
module Lexer (lex_tok) where
and the warnings are suppressed when I compile my program with
ghc -Wall --make
However, if a .y file starts:
{
{-# OPTIONS -w #-}
-- Foo
{-# OPTIONS -w #-}
module Parser (parse) where
}
then the generated .hs file starts:
-- parser produced by Happy Version 1.14
-- Foo
{-# OPTIONS -w #-}
module Parser (parse) where
so the pragma before my comment has been eaten and the 2 comments mean
that ghc doesn't see the pragma, so gives me all the warnings anyway.
Can happy be changed so my pragma gets through please?
Thanks
Ian, with happy 1.14
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
readline fun
Hi all, The Debian ghc6 package curently has both a build-dependency and a normal dependency on libreadline4-dev. The former is so the readline library (and ghci) can be built, and the latter so compiling programs with the readline package behaves correctly. Now I want to move over to libreadline5-dev instead. Clearly, to build the new ghc6, I need the old ghc6 installed, and thus need libreadline4-dev installed (as it's a dependency). However, libreadline4-dev and libreadline5-dev can't be installed simultaneously. I believe this isn't a /real/ problem because the readline package of the old GHC isn't actually needed to compile a new GHC, so libreadline4-dev isn't actually needed. Thus I can solve this problem by doing a build by hand on each arch. However, it would make my life a lot easier if things weren't so entangled in the first place. While I could just split the readline package off into a separate ghc6-readline package for Debian, I fear this may cause confusion for users, and it would mean satisfying cabal package deps was not necessarily sufficient for Debian systems. So what would be really useful for me is if the split were done by ghc itself, in much the same way as how the opengl libraries can be split off. Then, in particular, cabal packages using readline would have to explicit state it rather than assuming it'll be there by default. Does that sounds reasonable? Of course, I still have the same problem with libgmp, but I can't see any way around that one :-( Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bug#294481: ghci -lpthread fails
On Wed, Feb 09, 2005 at 11:13:36PM +0100, Juliusz Chroboczek wrote: Package: ghc6 Version: 6.2.2-2 /usr/lib/libpthread.so (comes from libc6-dev 2.3.2.ds1-20) is a GNU linker script, not a shared object. This breaks ghci. Known problem: http://www.haskell.org/pipermail/glasgow-haskell-users/2004-May/006671.html What is your particular problem? CCing glasgow-haskell-users@haskell.org as someone there may have an answer, or be interested to know the problem exists if not. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bug#294481: ghci -lpthread fails
On Thu, Feb 10, 2005 at 07:00:47PM +0100, Juliusz Chroboczek wrote: Hi Ian, What is your particular problem? Running Darcs under ghci. This seems to work for me (at least in as much as ghci loads and FastPackedString.lengthPS (FastPackedString.packString Foo) says 3): rm -rf .libs rm *ghcidarcsfoo* touch ghcidarcsfoo.c libtool --mode=compile gcc -g -O -c ghcidarcsfoo.c libtool --mode=link gcc -g -O -o libghcidarcsfoo.la ghcidarcsfoo.lo -lpthread -rpath /usr/lib libtool --mode=install cp libghcidarcsfoo.la `pwd`/libghcidarcsfoo.la libtool --finish /usr/lib ghci -cpp -package unix -package parsec -O -funbox-strict-fields -Werror -package util -I. -DHAVE_CURSES -optl-lcurses -optl-lz -L`pwd` -optl-lghcidarcsfoo darcs.lhs compat.o fpstring.o zlib_helper.o c_context.o Is there a problem with this? Could something along these lines be done when -lfoo (as opposed to -optl-lfoo, which for consistency should probably be left alone) is given on the ghci command-line? I'm no library expert, so there may be a cleaner/simpler/more portable equivalent to the above. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bug#294481: ghci -lpthread fails
On Fri, Feb 11, 2005 at 11:27:21AM -, Simon Marlow wrote: On 10 February 2005 23:35, Ian Lynagh wrote: I'm no library expert, so there may be a cleaner/simpler/more portable equivalent to the above. I'm not that familiar with libtool, but I guess what you're doing here is creating a dummy shared library which is linked against -lpthread, and linking that into GHCi? Yup. I don't see any reason why we couldn't automate the process, except that getting all the fiddly details right would probably be a nightmare. Like I say, I'm no expert either :-( And would you require libtool to be installed? What about other platforms - Mac OS X? If the necessary bits aren't available then you can fall back to acting like -optl-foo and are no worse off than currently. I think libtool is supposed to take care of the portability side for you, so hopefully lots of special casing won't be necessary. I don't know how well that works in practice, though. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4 release candidates available
On Thu, Feb 10, 2005 at 01:11:48PM -, Simon Marlow wrote:
We are finally at the release candidate stage for GHC 6.4. Snapshots
with versions 6.4.20050209 and later should be considered release
candidates for 6.4.
Source and Linux binary distributions are avaiable here:
http://www.haskell.org/ghc/dist/stable/dist/
Please test if you're able to, and give us feedback.
All the below with
2c7ed0ee7a11f2eae159d073c29b4fe6 ghc-6.4.20050228-src.tar.bz2
The following files in the tarball look like they shouldn't be there
(and should be cleaned by at least distclean):
* ghc/includes/mkGHCConstants (an x86 ELF binary)
* ghc/driver/package.conf.inplace.old
* ghc/driver/package.conf.old
* A large number of ld.script files and the _split directories they are in
* libraries/{OpenAL,X11,base,network,unix}/config.status
* libraries/config.status
After building, then doing make distclean, I'm additionally left with:
* A ghc/compiler/stage1 directory tree including a number of
.hi-boot-5 and .hi-boot-6 files.
* A ghc/compiler/stage2 directory tree including a number of
.hi-noot and .o-boot files.
* A complete libraries/html directory
* libraries/libraries.txt
* mk/config.h
* mk/config.mk
* mk/stamp-h
but Building from source / Standard Targets says:
distclean
Delete all files from the current directory that are created by
configuring or building the program. If you have unpacked the source
and built the program without creating any other files, make
distclean should leave only the files that were in the distribution.
I think you have unswapped the first two lines of
ghc -v 21 | head -2 but not changed Reading back to Using, so
old hmakes are still broken (old includes the latest release, I
believe).
Is there an equivalent of this (the no-OpenGL bit):
$(MAKE) prefix=`pwd`/debian/tmp/usr install GhcLibsWithOpenGL=NO
GhcLibsWithGLUT=NO
that still works or do I have to do it by hand?
Thanks
Ian
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: readline fun
Sorry it took me so long to reply. On Mon, Feb 07, 2005 at 11:57:58AM -, Simon Marlow wrote: On 02 February 2005 15:51, Ian Lynagh wrote: I bet the old GHC will work fine with the new readline. You might be right, but I'd much rather not have to check it really does before relaxing the dependency (which would also mean it couldn't be automatically generated). You want us to ship the readline package separately, say as a Cabal package? That's a possibility, but we like to keep the GHC sources as self-contained as possible, I don't necessarily want /you/ to, I just want to be able to myself without anything breaking. In fact, having thought about this a bit more I think this already is the case, as nowadays a cabal package using the readline package will have to specify it explicitly rather than GHC noticing it uses an appropriate module and pulling it in automatically. Thus an automated tool would generate a dependency on a suitably named package and it would all work fine. Well, that was easy :-) Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc-pkg too happy to create ~/.ghc
Hi, The Debian autobuilders don't let you write to ~ (which seems reasonable, as they are only compiling the software, not running it), so my builds are failing with -- ==fptools== /usr/bin/make boot -wr; in /build/buildd/ghc6-6.4/ghc/rts [...] ../utils/ghc-pkg/ghc-pkg-inplace --force --update-package package.conf.inplace Creating user package database in /org/buildd/.ghc/sparc-linux-6.4/package.conf Fail: createDirectory: permission denied (Permission denied) -- The patch below fixes it. I'm not sure I understand why the code is written as it is, though. It looks to me like if any config file given by a FlagConfig is missing then the readFile in readParseDatabase is going to fall over. I don't know what should happen when modifying if there are -f options, so can't suggest a complete replacement. Thanks Ian --- ghc6-6.4.orig/ghc/utils/ghc-pkg/Main.hs +++ ghc6-6.4/ghc/utils/ghc-pkg/Main.hs @@ -269,10 +269,6 @@ archdir = appdir `joinFileName` subdir user_conf = archdir `joinFileName` package.conf b - doesFileExist user_conf - when (not b) $ do - putStrLn (Creating user package database in ++ user_conf) - createDirectoryIfMissing True archdir - writeFile user_conf emptyPackageConfig let -- The semantics here are slightly strange. If we are @@ -281,20 +277,23 @@ -- If we are not modifying (eg. list, describe etc.) then -- the user database is included by default. databases - | modify = foldl addDB [global_conf] flags - | not modify = foldl addDB [user_conf,global_conf] flags + | modify || not b = foldl addDB [global_conf] flags + | not modify = foldl addDB [user_conf,global_conf] flags -- implement the following rules: -- --user means overlap with the user database -- --global means reset to just the global database -- -f file means overlap with file - addDB dbs FlagUser = if user_conf `elem` dbs - then dbs - else user_conf : dbs + addDB dbs FlagUser +| (modify || b) (user_conf `notElem` dbs) = user_conf : dbs addDB dbs FlagGlobal = [global_conf] addDB dbs (FlagConfig f) = f : dbs addDB dbs _ = dbs + when (not b user_conf `elem` databases) $ do + putStrLn (Creating user package database in ++ user_conf) + createDirectoryIfMissing True archdir + writeFile user_conf emptyPackageConfig db_stack - mapM readParseDatabase databases return db_stack ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
alpha problems with ghc 6.4
Hi,
An alpha build of ghc 6.4 quickly fails because of the
#if alpha_TARGET_ARCH
import PrimRep ( getPrimRepSize, isFloatingRep )
import Type ( typePrimRep )
#endif
in ghc/compiler/typecheck/TcForeign.lhs which no longer exist.
Fortunately, the imported functions aren't used either.
Unfortunately, the build then fails when it comes to try to compile this
same file as the typeMachRepRep function, used in this piece of code:
\begin{code}
#include nativeGen/NCG.h
#if alpha_TARGET_ARCH
checkFEDArgs arg_tys
= check (integral_args = 32) err
where
integral_args = sum [ machRepByteWidth rep
| (rep,hint) - map typeMachRepRep arg_tys,
hint /= FloatHint ]
err = ptext SLIT(On Alpha, I can only handle 4 non-floating-point
arguments to foreign export dynamic)
#else
checkFEDArgs arg_tys = returnM ()
#endif
\end{code}
doesn't exist. Is this fixable?
Thanks
Ian
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Inlining question
Hi all, With foo.hs below, if I compile normally then it takes about 70 seconds to run: $ rm -f *.o *.hi foo $ ghc -cpp -Wall -O2 foo.hs -o foo $ time ./foo real1m10.266s user1m9.698s sys 0m0.521s If I turn up the inlining threshold then it takes only about 13 seconds: $ rm -f *.o *.hi foo $ ghc -cpp -Wall -O2 foo.hs -o foo -funfolding-use-threshold=20 $ time ./foo real0m13.313s user0m12.838s sys 0m0.450s However, if I copy the definition of shift from base/GHC/Word.hs then it also takes around 13 seconds: $ rm -f *.o *.hi foo $ ghc -cpp -Wall -O2 foo.hs -o foo -DCOPY -fglasgow-exts $ time ./foo real0m13.394s user0m12.843s sys 0m0.454s Why does it matter whether the definition is in the current file or is imported from the standard libraries? Thanks Ian module Main (main) where import Foreign.Ptr (Ptr) import Foreign.Marshal.Array (mallocArray, advancePtr) import Foreign.Storable (peek, poke) import Data.Bits ((.|.)) #ifdef COPY import Prelude hiding (Int) import GHC.Exts (shiftRL#, shiftL#) import GHC.Word (Word32(W32#)) import GHC.Base (Int(I#), narrow32Word#, negateInt#, (=#)) #else import Data.Word (Word32) import Data.Bits (shift) #endif main :: IO () main = do p - mallocArray 104857600 mapM_ (\_ - foo p 104857600) [1..10 :: Int] foo :: Ptr Word32 - Int - IO () foo p i | p `seq` i `seq` False = undefined foo _ 0 = return () foo p n = do x - peek p poke p (shift x (-1) .|. shift x (-2) .|. shift x (-3) .|. shift x (-4)) foo (p `advancePtr` 1) (n - 1) #ifdef COPY -- Defn from libraries/base/GHC/Word.hs shift :: Word32 - Int - Word32 shift (W32# x#) (I# i#) | i# =# 0# = W32# (narrow32Word# (x# `shiftL#` i#)) | otherwise = W32# (x# `shiftRL#` negateInt# i#) #endif ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: switching off let-floating
On Thu, Jul 28, 2005 at 04:37:40PM +0200, Wolfgang Jeltsch wrote: Related question: Can anybody tell me when there will be Debian packages of GHC 6.4 available? There are 6.4 packages in unstable. They aren't installable in unstable, but I think they should be installable on a stable system. Shortly after 6.4.1 is released ghc6 should be installable in unstable again. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: more on GHC 6.4 Debian packages
On Thu, Jul 28, 2005 at 10:56:40PM +0200, Wolfgang Jeltsch wrote: Am Donnerstag, 28. Juli 2005 20:46 schrieb Iavor Diatchki: I am using the testing distribution, which appears to have something called ghc-cvs and ghc 6.2 but not ghc 6.4. I didn't know about ghc-cvs so far. The idea of ghc-cvs looks a bit ugly. Why would the Debian project want to have an unstable GHC version in stable? In addition I wonder why ghc-cvs from stable is one year old. ghc-cvs runs the testsuite while building, so if any of the tests don't terminate (and some of them don't on at least some arches) then the package doesn't build. Thus there is a timeout program that kills tests if they take too long. However, the timeout program tickles known bugs in Linux 2.4 on hppa (and possibly unknown bugs on ia64, as discussed briefly on ghc-cvs). So the upshot is that I haven't been able to get a new ghc-cvs built recently. I hope to look into this again after sorting out everything we've already talked about :-) Hopefully by then more of the relevant machines will be on 2.6, too. I am confused as to why ghc 6.4 is considered less stable then ghc-cvs which presumably is changing more or less all the time. If you install a package called ghc-cvs then you should expect things to not necessarily work, regardless of whether it came from stable, testing or unstable. A package called ghc6 from stable should actually work, though. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.4.1 release candidate testing
On Mon, Aug 01, 2005 at 03:07:16PM +0100, Simon Marlow wrote: This is to announce that testing for 6.4.1 has begun. Snapshots from 20050730 onwards are release candidates - please test if you can. Snapshots are available from here: http://www.haskell.org/ghc/dist/stable/dist/ we have source snapshots, and binaries for Linux/x86 (RH 9.1 era), Linux/x86_64 (FC3 era), and Windows. 20050801 looks OK so far here on x86 Debian Linux, apart from the building.xml issue already mentioned. debs for i386 unstable are in Haskell Unsafe: http://haskell-unsafe.alioth.debian.org/haskell-unsafe.html Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
C/Haskell speed comparisons
Hi all, Quite often in darcs we want to do a simple loop over a chunk of memory, looking for the first whitespace character or somesuch. Historically this has been done by writing a small snippet of C, but this has a number of downsides (less type safety in the C code, Int/int/HsInt/CInt mismatches, code artificially separated, complicates the Makefiles, have to write C code), so I'd like to replace them with little bits of Haskell. However, it would be easier to convince people that this is the right thing to do if there was no slow-down involved, so I've put some benchmarks together. Hopefully this will help find some cases where ghc is generating poor code, and perhaps help to spot regressions (although it's hard to spot that automatically currently). Essentially each test has n modules, each of which (are supposed to) do the same thing, and it compares certain pairs and it works out how much slower one is than the other on various test sizes. I arbitrarily declared x1.1 to be too slow. The code is at http://urchin.earth.li/~ian/bench/ and the results I get for ghc 6.4.1 are at http://urchin.earth.li/~ian/bench/all.html (interestingly some of the slowdowns I was trying to measure turned out to be speed/ups/). Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Optimizations for mutable structures?
On Wed, Dec 07, 2005 at 02:15:24PM -, Simon Marlow wrote: On 07 December 2005 13:38, Malcolm Wallace wrote: Jan-Willem Maessen [EMAIL PROTECTED] writes: - Fetch elimination for imperative reads: writeIORef r e acts readIORef r === writeIORef r e acts return e This transformation is valid only on single-threaded systems. If there is any possibility of an IORef being shared across threads, you are out of luck. (assuming 'acts' doesn't modify 'r'). No, Jan's transformation is correct even in a multithreaded setting. It might eliminate some possible outcomes from a non-deterministic program, but that's ok. There's no requirement that all interleavings according to the semantics have to be implemented. This is a hard property to state precisely, indeed we gave up trying to in the concurrency/FFI paper: http://www.haskell.org/~simonmar/papers/conc-ffi.pdf, see Section 6.1. I don't think it's true for this program: import Data.IORef import Control.Concurrent main = do m1 - newEmptyMVar m2 - newEmptyMVar let e = 6 not_e = 7 acts = putMVar m1 () takeMVar m2 r - newIORef 5 forkIO $ do takeMVar m1 writeIORef r not_e putMVar m2 () writeIORef r e acts readIORef r = print Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: darcs switchover
On Sat, Jan 14, 2006 at 11:42:11AM -0600, T.C. Andrew wrote: After I completed the above procedure to get the source, and then $autoreconf $./configure $make the build always stuck at: ==fptools== make all -wr; in /login/haskell/public/ghc/ghc/compiler /bin/sh: line 0: test: 2.20051206: integer expression expected /bin/sh: line 0: test: 2.20051206: integer expression expected /bin/sh: line 0: test: 2.20051206: integer expression expected Any ideas? I am using Debian (testing). stuck as in make uses lots of CPU with no visible progress? If so, it sounds like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=346248 Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problem building on sparc/Linux
On Wed, Mar 01, 2006 at 12:24:17PM +, Simon Marlow wrote: There's a ticket open on this one: http://cvs.haskell.org/trac/ghc/ticket/470 The ticket does give more info (isSpace isn't working correctly). If you could track this down further, that would be great. Looks like a (fixed) gcc bug: [EMAIL PROTECTED]:/scratch/igloo/space$ rm *.o *.hi foo; ghc -Wall -O foo.hs -o foo ./foo [True,False,True,True,False,True] [EMAIL PROTECTED]:/scratch/igloo/space$ rm *.o *.hi foo; ghc -Wall -O foo.hs -o foo -pgmc /usr/bin/gcc-4.0 ./foo [True,True,True,True,True,True] [EMAIL PROTECTED]:/scratch/igloo/space$ gcc --version gcc (GCC) 3.3.6 (Debian 1:3.3.6-12) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [EMAIL PROTECTED]:/scratch/igloo/space$ /usr/bin/gcc-4.0 --version gcc-4.0 (GCC) 4.0.3 20060212 (prerelease) (Debian 4.0.2-9) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I'll get the default gcc upgraded and try the build again. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to find out the C type signature corresponding to a Haskell function type in FFI?
On Tue, Mar 07, 2006 at 07:57:50PM +0100, Tomasz Zielonka wrote: On Tue, Mar 07, 2006 at 04:35:27PM -, Brian Hulley wrote: A third point is, how would I pass an arbitrary monad instead of just using IO? What for? IO is the monad that most closely matches the imperative, C semantics. That's why FFI only supports the IO monad (and pure functions). Other monads (you say arbitrary) may use rather complicated machinery to implement their semantics (HOFs, laziness, algebraic data types). I don't think it's a good idea to try implementing their actions in C (if that's what you want). Why do you need that? I tend to wrap FFI imports with functions that can be called in any MonadIO monad. I sometimes think I should suggest the FFI should be able to do this itself, but given I'm generally needing to convert types, allocate memory etc in these functions too the gain would be fairly minimal. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Mixing registerised and unregisterised builds
Hi all, The attached e-mail seems to be about a problem using a library compiled with an unregisterised ghc with a registerised ghc. The linking step is giving many undefined reference to `stg_ap_p_ret's (with various numbers of 'p's) as well as a few to `GHCziIOBase_zdWIO_entry', and possible others I didn't spot, while compiling haskelldb with a registerised ghc 6.4.1, where haskelldb depends on hsql, which was compiled with an unregisterised ghc 6.4.1. Is this expected behaviour? i.e. should I just make sure I don't change which arches are registerised within a GHC version? If so, would a library compiled with a registerised ghc being used by an unregisterised ghc also cause problems? Or have I got the problem completely wrong? Based on a quick look at the GHC source, the missing symbols seem to be due to this, in ghc/rts/Linker.c : #ifdef TABLES_NEXT_TO_CODE #define RTS_RET_SYMBOLS /* nothing */ #else #define RTS_RET_SYMBOLS \ [...] SymX(stg_ap_p_ret)\ [...] #endif being toggled due to this, in ghc/includes/RtsConfig.h : #if !defined(USE_MINIINTERPRETER) !defined(ia64_HOST_ARCH) !defined (powerpc64_HOST_ARCH) #define TABLES_NEXT_TO_CODE #endif in turn due to this, in ghc/includes/Makefile : ifeq $(GhcUnregisterised) YES SRC_CC_OPTS += -DNO_REGS -DUSE_MINIINTERPRETER endif Thanks Ian ---BeginMessage--- Hi, haskelldb is failing on amd64 and ghc could possibly have a part in this. I think you should be informed as well, sorry I didn't think to CC the other emails. I hope that in case there's something wrong with ghc6, maybe you can easily guess :) In particular, reading haskelldb changelod I noticed Update dependencies for ghc6 6.4.1. Could it be something related to the last ghc6 uploads? However, could you please take a look below? Thanks, Roberto Messaggio Originale Bjorn Bringert ha scritto: Roberto Pariset wrote: Hello, haskelldb fails to build from source on debian-amd64, with a lot of errors like: undefined reference to `stg_ap_p_ret' , as shown at [1]. I have to say I have never heard of haskell before, so I was wondering if you could give me any hint to fix it. A good starting point would be pointing me where stg_ap_p_ret is defined, as I haven't been able to find out (am I unable to use google?). All the best, Roberto PS. please include me in your replies, don't just mail the list! [1] http://amd64.ftbfs.de/fetch.php?pkg=ghc6ver=6.4.1-2arch=amd64stamp=1141531193file=logas=raw Hi Roberto, the log that you link to seems to be for the GHC build, not HaskellDB, and it doesn't seem to contain the error messages that you mention. I did find the HaskellDB log with the errors at: http://amd64.ftbfs.de/fetch.php?pkg=haskelldbver=0.9.cvs.601-9arch=amd64stamp=1142372938file=logas=raw I think that the stg_ap_p_ret function belongs to the GHC run-time system, but I don't know what would cause the linker to not find it. /Björn (HaskellDB maintainer) Thanks a lot, Björn. I confirm I got the url wrong, sorry. Now, let's hope to hear some feedback from the GHC guys =) Rob ---End Message--- ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Mixing registerised and unregisterised builds
On Thu, Mar 16, 2006 at 10:05:44AM +, Simon Marlow wrote: That's right - registerised and unregisterised code are completely incompatible. OK, thanks. Its similar to the situation with profiled and unprofiled code. But in this case we get a warning: mismatched interface file ways: expected , found p Perhaps a similar warning could be given for the registerised case? Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.4.2 release plans
On Wed, Mar 15, 2006 at 04:24:14PM +, Simon Marlow wrote:
If you have anything else for 6.4.2, please let me know.
Just a small thing, but it looks like, while the HEAD has been changed
to send --help output to stdout, ghc-6.4.2.20060316 still has the
following in ghc/compiler/main/DriverFlags.hs
dump ('$':'$':s) = hPutStr stderr progName dump s
dump (c:s) = hPutChar stderr c dump s
Is this deliberate, or could it be changed to
dump ('$':'$':s) = putStr progName dump s
dump (c:s) = putChar c dump s
please?
Thanks
Ian
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Packages and modules
On Mon, Jun 26, 2006 at 04:20:16PM +0100, Brian Hulley wrote: I don't think this solves the whole problem. Suppose M1 needs to use A.B.C from P1 *and* A.B.C from P2 For a simple example of a case where this might arise, suppose M1 is the migration module for data (stored in a database, received over a network, or some other such case) in P version 1's format to P version 2's format. [from wiki] import Packages.Gtk-1_3_4.Widget.Button I'm also not a fan of this magic Packages.* hierarchy, nor the package name change hoops it makes us jump through. package gtk-1_3_4 as Gtk or package gtk as Gtk -- use the current version of gtk or if package directive is omitted an import Xyz/Mod is equivalent to: package xyz as Xyz -- initial letter capitalised import Xyz/Mod The package gtk as Gtk bit makes sense to me, but I'd expect then to use Gtk.Foo.Bar for module Foo.Bar in package Gtk. import gtk-1.3.4/Foo.Bar also makes sense, although personally I'd prefer the syntax from gtk-1.3.4 import Foo.Bar where either from packagename is an optional prefix to current import declaration syntax, or from packagename starts a block so we can say from gtk1 import Foo.Bar as Gtk1.Foo.Bar import Baz.Quux as Gtk1.Baz.Quux from gtk2 import Foo.Bar as Gtk2.Foo.Bar import Baz.Quux as Gtk2.Baz.Quux If we have gtk-1.something and gtk-2.something (rather than gtk1-version and gtk2-version as above) then we'd probably instead want the wiki's -package gtk-2.0.1=Gtk2 which could be generated due to a .cabal build-depends of gtk (= 2) as Gtk2 Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Packages and modules
On Wed, Jul 05, 2006 at 01:03:01AM +0100, Brian Hulley wrote:
Simon Peyton-Jones wrote:
Concerning other mail on this subject, which has been v useful, I've
revised the Wiki page (substantially) to take it into account.
http://hackage.haskell.org/trac/ghc/wiki/GhcPackages
Further input (either by email or by adding material to the Wiki)
would be welcome. (No guarantee Simon M agrees with what I've
written... I'm at home this afternoon :-)
I think the following is a non-question:
An open question: if A.B.C is in the package being compiled,
and in an exposed package, and you say import A.B.C,
do you get an error (ambiguous import), or does the current
package override.
because if the suggested syntax is used, import directives come in two
flavours: ones that use from to import from a different package and ones
that don't use from and therefore must refer to the current package.
FWIW this isn't what I actually intended when I was talking about using
from. I was imagining it would work similar to how foo unqualified
can refer to either an imported variable or a variable in the current
package, but we can still qualify Foo.foo should we wish to be
explicit. So you can import from any package, including the current
one, but qualify from package import should you wish to be explicit.
(modified to use quotes):
from base
I think I missed where the plan to use quotes came from. What's the
purpose? Package names already have a well-defined syntax with no spaces
or other confusing characters in them, so why do we need the quotes? Or
is it just so we can have packages with the same name as keywords? (if
so I think personally I'd prefer a slightly more context-sensitive
grammar, not entirely unlike the as/qualified/hiding semi-keywords in
import statements).
import Predude hiding(length)
import Control.Exception
import qualified Data.List as List
since otherwise it would soon become a bit of a pain to have to type 'from
base' everywhere (esp if the package name was some long URL). It would
also make it easier to quickly change to a different package without having
to modify multiple import directives, which might be especially useful in
the context of using a debug or release version of a package by putting C
pre-processor directives around the from part.
There is a minor open question about the exact indentation rule for the
above syntax since base is not a keyword and it would seem strange to
desugar it into from {base; import ... } so it looks like it would need a
special layout rule that would give a desugaring into from base {import
...}
It would only be slightly different to the current rules (it would be if
the second lexeme after from was not '{', rather than the first),
although now you mention it this would be an alternative possibility:
from base import
Prelude hiding (length)
Control.Exception
qualified Data.List as List
where import behaves much like of as far as the layout rule is
concerned.
Thanks
Ian
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Data.FiniteMap
On Mon, Sep 04, 2006 at 02:32:34PM +0200, Duncan Coutts wrote: * 6.4.1 is not even marked stable in debian yet (only 6.2.2 is stable) Debian doesn't have a concept of marked stable. 6.4.1 didn't exist when sarge was released, so it has not yet had a chance to be included in a stable release. FWIW, I'm in favour of removing FiniteMap. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: instance overlap in 6.6 candidate
On Mon, Sep 04, 2006 at 06:22:34PM +0400, Serge D. Mechveliani wrote: Here is an example of how I alayws was using overlaps with standard instances. data Equation = ... instance Show Equation where ... instance Show [Equation] where showsPrec _ eqs = certain program which prints a list of equation in a `nicer' way than by the default list printing This doesn't addrses the general issue, but in this case you can say data Equation = ... instance Show Equation where showsPrec _ eq = ... showList eqs = certain program which ... Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: more fixups for GHC docs
Hi Bulat, On Thu, Sep 07, 2006 at 07:26:38PM +0400, Bulat Ziganshin wrote: 1. section 7.11.6 contains small typo - both %note are %note foo while CORE pragmas use foo and bar 2. section 7.13 notes that generic classes was broken in GHC 5.02. afaik, they worked at least in GHC 6.4 Both fixed, thanks. also it will be great if each paragraph of Release Notes will link to corresponding section in documentation for further reading. now we don't have links for impredicative polymorphism, bang patterns, GC improvements (we can point to http://hackage.haskell.org/trac/ghc/ticket/650), -I RTS flag, -split-objs flag (and also it will be great to mention here that its using allows to reduce size of binaries) I've added links to these. i think that it should be mentioned here that parallel arrays support is omitted in 6.6 despite this support was never documented Done. and last question - i don't like inclusion of unix and win32 in a list of core libs. why they are here? may be it's possible to include small modules with functionality required for compiler itself in GHC.* hierarchy and then move the rest into extra libraries? This doesn't work well for any parts shared with the other compilers. core libs is possibly the wrong name for it - bootstrapping libs might be more appropriate. Note also that unix and win32 haven't been included in anything they weren't already, it's just that other libraries (those that are now called extra libs) have been taken out. We can always take more out for 6.8 if we want. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: compiler-independent core libraries infrastructure
Hi Bulat, Just a partial answer for now: On Wed, Sep 13, 2006 at 12:29:58PM +0400, Bulat Ziganshin wrote: Friday, September 8, 2006, 5:52:57 AM, you wrote: what is a 'base' library now? it is the library that implements common set of operations for latest versions of ghc, hugs and nhc. it contains low-level implementation for ghc, but relies on separate hugsbase package for hugs (the same for nhc, afaiu). so, first step is obvious - separate ghc-base library from the rest. hugsbase, ghc-base and nhc-base packages should provide common set of low-level operations, As it happens I was working on getting GHC to use cabal to build base et al on the plane the other day, and I had a brief look at this. Unfortunately there is a tangled web of dependencies, e.g. you need the low level Int# stuff in ghc-base, then Int in base, but then any other GHC-specific stuff can't use Int because it's in base. We could put everything into ghc-base and just re-export the common stuff in base, but then we can't share any code between ghc, hugs etc. I haven't looked in detail to see just how bad the problem is, but I agree it would be really good if we could split things up somehow so that base (or whatever base gets split into) is the same everywhere. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Help with unregisterised build
On Wed, Sep 13, 2006 at 09:43:03PM +1000, Jeremy Wazny wrote: I've attempted to build an installation of GHC which uses unregisterised libraries, but have not had much success. I am new to GHC's build system and would be grateful for some advice. I'm trying to build the 6.4.2 source distribution on an x86 linux machine, using GHC 6.4.2 (the Generic Linux with glibc2.3 version on the download page.) The target is the same machine. I've created a mk/build.mk file containing just the line: GhcUnregisterised = YES which, according to the comment in mk/config.mk, ought to build the unregisterised libraries that I'm after (and use them by default.) For my unregisterised builds I use: GhcUnregisterised=YES GhcWithNativeCodeGen=NO GhcWithInterpreter=NO SplitObjs=NO The SplitObjs=NO will solve the problem you are seeing. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: threadDelay not ending
Hi Rich, On Mon, Sep 18, 2006 at 09:23:52AM -0500, Rich Fought wrote: I've got some unit test code that forks off test processes using the 'system' function and then delays using 'threadDelay' to synchronize with the test process. This has worked fine until I upgraded to 6.4.2, now some of the 'threadDelay' calls never return - it's like they are stuck in limbo. Are you compiling with -threaded? Are you able to send us a small example demonstrating the problem? Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Year 2038 problem in GHC 6.4.2 runtime
On Fri, Sep 22, 2006 at 04:16:44PM +0200, Cyril Schmidt wrote: As far as I can see, the current (6.4.2) GHC runtime suffers the year 2038 problem; that is, the System.Time module does not support dates from 2038 onwards (the code below reproduces the problem). We inherit the problem from C's mktime, which returns a time_t, so this is not trivial to fix. As Bulat says, I don't think the new time package will suffer from this problem. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: internal error: asyncRead#, ghci and fps (windows) (trac 806)
On Tue, Sep 19, 2006 at 09:20:45PM +0200, Rene de Visser wrote: Is there anyway to turn off that ghci runs in threaded mode on windows? Only by recompiling, I'm afraid (for 6.4.2 comment out the line SRC_HC_OPTS += -threaded in ghc/compiler/Makefile; for 6.5 you need to also do so in ghc/compiler/Makefile.ghcbin). fps 0.8 (and software that uses fps) triggers trac error #806. This means that I cannot run such things interactively :-( I'll add a note about this to the bug. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: more extra-libs for ghc 6.6
On Tue, Sep 19, 2006 at 08:45:30PM +0400, Bulat Ziganshin wrote: Hello glasgow-haskell-users, how about adding to the list of extra libs the following very useful ones: I think we're too late in the release process to be adding libraries. Also, I think we would like to move towards distributing fewer libraries, not more. For 6.8 I hope we can do something like drop the extra-libs tarball, but have the build process do a topological sort of everything in libraries/ and build the lot. That way if you want to bundle a given set of libs in the Windows installer, or whatever, then you just instruct cabal-get to give you the source tarballs for those libs, and anything they depend on (would need to tell it you have the core libraries already somehow), put them in libraries/ and build in the normal way. This would neatly sidestep any arguments about what packages are important/common/small/... enough that they should go in extralibs. regex-* I'm not sure if you are refering to other packages, but regex-base, regex-compat and regex-posix are already core libraries. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: more fixups for GHC docs
Hi Bulat, Thanks for the suggestions! On Tue, Sep 19, 2006 at 05:52:53PM +0400, Bulat Ziganshin wrote: in GHC library paragraph - add a link to the API documentation. btw, my download (http://www.haskell.org/ghc/dist/current/dist/ghc-6.5.20060901-i386-unknown-mingw32.tar.gz) don't includes any library docs nor $(GHC)/doc/html/libraries/index.html can you please fix this? I'll probably look into this as part of the move to buildbot. In the meantime, the most recent docs should be available at http://www.haskell.org/ghc/dist/current/docs/ also, it will be great to use each library section heading as URL to the docs of corresponding library: 1.4.4.1 [[url://libraries/base/index.html base]] We don't have this, do we? All the library docs are combined in libraries/index.html. GHC.Exts now provides a function lazy which forces GHC to think that its argument is lazy in its first argument. - a copy-paste typo? Do you mean the double argument? If so, then no: In lazy f f is its argument, and f is lazy in f's first argument. This is a pain to explain clearly and concisely. Is this better?: GHC.Exts now provides a magic function /lazy/ such that GHC is forced to think that /lazy f/ is lazy in its first argument. Or am I misunderstanding your point completely? Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: compiler-independent core libraries infrastructure
On Fri, Sep 15, 2006 at 05:20:36PM +0100, Ian Lynagh wrote: As it happens I was working on getting GHC to use cabal to build base et al on the plane the other day, and I had a brief look at this. See my comment in http://hackage.haskell.org/trac/ghc/ticket/710 for the results of my longer look at this. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ANNOUNCE: GHC 6.6 Second Release Candidate
We are pleased to announce the Second Release Candidate phase for GHC 6.6. Snapshots beginning with 6.5.20061001 are release candidates for 6.6 We would be particularly interested to hear whether or not the 6.6 RC works for people who were having trouble with 6.4.2. Also, please note that the GHC API has changed since the last RC as a result of some feedback from the Hackathon, so you may want to check that any applications using it still work. Download snapshots from here: http://www.haskell.org/ghc/dist/current/dist/ Right now we have the source bundles: http://www.haskell.org/ghc/dist/current/dist/ghc-6.5.20061001-src.tar.bz2 http://www.haskell.org/ghc/dist/current/dist/ghc-6.5.20061001-src-extralibs.tar.bz2 Only the first of these is necessary. The extralibs package contains various extra packages that we normally supply with GHC (and a couple of new ones) - unpack the extralibs tarball on top of the source tree to add them, they will be included in the build automatically. There are also currently binary distributions for x86_64/Linux (Fedora Core 5), i386/Linux (RedHat 7(!)), and Windows. More may appear later. Please test as much as possible, bugs are much cheaper if we find them before the release! We expect to release in about a week's time. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Controlling -fno-unit-at-a-time
On Tue, Oct 03, 2006 at 04:59:58PM -0400, Ravi Nanavati wrote: If I understand the way things work, GHC decides whether or not to emit the -fno-unit-at-a-time flag in -fvia-C compilation based on whether or not the gcc used when compiling GHC supported the flag or not. I'm running into trouble using precompiled GHC snapshots (that were compiled on machines whose gcc supports -fno-unit-at-a-time) on a machine whose gcc doesn't support it (a gcc 3.2 version, I believe). Is there any way force GHC to not emit the flag (short of recompiling from source)? Not really. You could use a small gcc wrapper to remove it (you can point to it with -pgmc if you don't want to contaminate your path with it). You could probably also change the 'f' to a 'D' with a hex editor, but I'm not sure why anyone would prefer that solution. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Expecting more inlining for bit shifting
On Mon, Oct 09, 2006 at 10:33:47AM -0400, [EMAIL PROTECTED] wrote: On Mon, 9 Oct 2006, Simon Peyton-Jones wrote: Turns out that 'shift' is just too big to be inlined. (It's only called once, but you have exported it too.) You can see GHC's inlining decisions by saying -ddump-inlinings. To make GHC keener to inline, use an INLINE pragma, or increase the inlining size threshold e.g. -funfolding-threshold=12 Okay, when I force inlining for shift, (and I even need to do it for shiftR!) then the code is inlined in C. However this isn't the behaviour I want. Ideally the inlining should only happen when/because the second argument of shift is constant and the system knows that it can evaluate the case analysis away and that makes the function small. Am I being too naive on what to expect from my complier or is this reasonable? It might be possible, but it sounds tricky. I guess it would have to go something like try inlining this, run the simplifier, see if it got small enough, if not back out, which could waste a lot of work if it fails in lots of cases. PS, is there a way to mark an imported instance of a class function (Data.Bits.shift for Data.Word.Word32) to be inlined? You can use GHC.Exts.inline in 6.6: http://www.haskell.org/ghc/dist/current/docs/users_guide/special-ids.html#id3178018 but note the restriction in the final paragraph. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ANNOUNCE: GHC version 6.6
=== The (Interactive) Glasgow Haskell Compiler -- version 6.6 === The GHC Team is pleased to announce a new release of GHC. There have been many changes since the 6.4.2 release. For details, see the release notes here: http://haskell.org/ghc/docs/6.6/html/users_guide/release-6-6.html How to get it ~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998 and revised December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://www.haskell.org/ghc/docs/latest/html/building/building-guide.html Developers ~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6 under solaris
On Thu, Oct 12, 2006 at 03:28:37PM +0200, Christian Maeder wrote:
I've created ghc-6.6 under solaris.
[410 of 642] Compiling Proofs.HideTheoremShift (
Proofs/HideTheoremShift.hs, Proofs/HideTheoremShift.o )
ghc-6.6: panic! (the 'impossible' happened)
(GHC version 6.6 for sparc-sun-solaris2):
lookupDeprec main:GUI.ConsoleUtils.listBox{v r36Wf}
Do you know whether or not this compiles OK on other platforms with GHC
6.6?
Thanks
Ian
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6 on Ubuntu
On Fri, Nov 17, 2006 at 07:48:41AM -0800, Chad Scherrer wrote: Is there a preferred way of getting this going? I tried the GHC instructions for Debian, but this seems to depend on 6.6 already being in the repository, which it's not, in Ubuntu (why?). I like Debian/Ubuntu's install system, and I assume that 6.6 will eventually make it into Ubuntu. I want to be sure whatever I do now doesn't later confuse the system. I assume you're sending this to me as I'm listed as maintainer on the ubuntu packages, but I am not involved with ubuntu. You'd have to speak with the Ubuntu people for info about their plans for GHC 6.6 etc. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FW: GHC API: Problems with implementing :reload for ghc --make
Hi Brian, Sorry for the delayed response. My goal is to write a program GhcRemake that works like ghc --make. However, instead of terminating after compilation is done, I want the program to stay open and wait for me to hit ENTER. When I hit ENTER, GhcRemake rebuilds the project, just as if I had called ghc --make again with the same arguments. The benefit of such a program is that GhcRemake should be able to cache a lot of data in memory between invocations and hopefully be able to do the subsequent re-makes much faster. Nice idea! My program seems to work fine when run on itself and when run on Cabal. But, these two packages seem to be too small to notice any reduction of building time. So, I decided to test my program by building the GHC API with it. Unfortunately, it seems like every build after the first one in the session does the dependency analysis badly, and things get recompiled unnecessarily. It looks like the problem is caused by recursive module imports. I've added a bug (#1027) with a smaller example of it. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Using GHC API
Hi Chris,
On Fri, Nov 10, 2006 at 04:15:10PM +, C.M.Brown wrote:
I am currently in the process of porting some of the Haskell
Refactorer (HaRe) over to ghc 6.6. Part of HaRe requires the API and until
now I've been content with using th 6.5 API. However, since I've started
the switch I've noticed some strange problems and the latest is I am
getting the following error when trying to find the type of an expression:
interactive:1:0:
Can't find interface-file declaration for Main.main
Probable cause: bug in .hi-boot file, or inconsistent .hi file
Use -ddump-if-trace to get an idea of which file caused the error
Attached is a smaller module showing the same thing, along with the
(trivial) Main.hs I was testing with.
If I tell it to use Interactive mode then all is well:
$ ./hasktags Interactive Main.hs
Loading package base ... linking ... done.
[1 of 1] Compiling Main ( Main.hs, Main.o )
Just GHC.IOBase.IO ()
but if I tell it to use JustTypecheck mode then it breaks:
$ ./hasktags JustTypecheck Main.hs
[1 of 1] Compiling Main ( Main.hs, Main.o )
interactive:1:0:
Can't find interface-file declaration for variable Main.main
Probable cause: bug in .hi-boot file, or inconsistent .hi file
Use -ddump-if-trace to get an idea of which file caused the error
Nothing
(remove *.hi *.o between runs)
So it looks like using Interactive mode should allow you to get on for
now.
ghc --show-iface Main.hi gives
interface main:Main 1 6070 where
export main:Main main
module dependencies:
package dependencies: base
orphans: base:GHC.Base
family instance modules:
main :: GHC.IOBase.IO ()
main :: GHC.IOBase.IO ()
in the first case, but the last two lines are missing in the second.
This raises a few questions:
Are there meant to be two main :: GHC.IOBase.IO () lines when it works?
Should it work with JustTypecheck? It looks like the point of
JustTypecheck is that IDEs should be able to ask the type of something
actually written in the file, but would it actually be more expensive to
allow the information to be used to type other expressions?
Should JustTypecheck be generating a .hi and .o file at all? It seems
wrong to me.
Simons?
Thanks
Ian
{-
rm *.o *.hi hasktags
/home/ian/ghc/darcs2/build/compiler/stage2/ghc-inplace --make -package ghc
hasktags.hs
rm *.o *.hi
./hasktags Interactive Main.hs
rm *.o *.hi
./hasktags JustTypecheck Main.hs
-}
module Main (main) where
import System (getArgs)
import GHC
import DynFlags (defaultDynFlags)
import Outputable (Outputable, showSDoc, ppr)
ghcPath :: FilePath
ghcPath = /home/ian/ghc/darcs2/build/inst/lib/ghc-6.7
main :: IO ()
main = do
args - getArgs
case args of
Interactive :files - realMain Interactive files
JustTypecheck:files - realMain JustTypecheck files
realMain :: GhcMode - [FilePath] - IO ()
realMain mode files = defaultErrorHandler defaultDynFlags $ do
ses - GHC.newSession mode (Just ghcPath)
dflags0 - GHC.getSessionDynFlags ses
(dflags1,fileish_args) - GHC.parseDynamicFlags dflags0 []
GHC.setSessionDynFlags ses $ dflags1 {verbosity = 1}
targets - mapM (\a - GHC.guessTarget a Nothing ) files
mapM_ (GHC.addTarget ses) targets
res - GHC.load ses LoadAllTargets
ty - exprType ses Main.main
putStrLn $ showSDoc $ ppr ty
module Main (main) where
main :: IO ()
main = return ()
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Hacking on GHC interactively with GHCi
On Tue, Oct 17, 2006 at 09:54:26AM +, Clemens Fruhwirth wrote: *Main :main -B/usr/lib/ghc-6.6 --help ...[freeze here .. pressed C-c] *** Exception: exit: ExitFailure 1 *Main I could reproduce this with stage2/ghc-inplace --interactive :set -I. -Istage1 -cpp -fglasgow-exts -package ghc :load main/Main.hs :main -B/home/ian/ghc/6.6-branch/build --help -- sometimes more than once in an old 6.6 branch compiler/, but having updated it I no longer can. I can't reproduce it in the HEAD either. I haven't seen a reply to your message, but it looks like the problem is now fixed regardless. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: raw foregin imports - new backend for jhc: ghc
Hi John, On Mon, Nov 27, 2006 at 08:26:34PM -0800, John Meacham wrote: At the moment, I don't think I need anything, I was just misreading certain features. the ghc backend seems to be working fine with the following caveats: * all integral types (even Integer) are flattened to Int#. I'm not sure I follow this - if I do foreign import ccall static foo.h foo foo :: Integer - Integer then GHC tells me Unacceptable argument type in foreign declaration: Integer Unacceptable result type in foreign declaration: Integer Can you explain what you are doing that makes Integer get flattened, please? * ghc -O on my generated programs crashes with the following: ghc-6.6: panic! (the 'impossible' happened) (GHC version 6.6 for i386-unknown-linux): primRepHint:VoidRep Another bug, thanks! Again, this isn't something we claim should work, but it should definitely either work or give a nice error message. I've filed it in trac: #1037. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: TH - splicing with functions defined in the same source file
On Thu, Nov 30, 2006 at 02:12:48AM +, Simon Peyton-Jones wrote: 2. You have to compile all the code before your cut-point to byte-code, just in case it's invoked by a splice afterwards. This is in addition to compiling it to machine code (assuming that's what the main compilation does). Concerning (2), the thought of compiling all of every module to bytecode, on the off chance that a later splice might need it, seems unattractive to me (although it might work fine). To predict, instead, which definitions will be needed means looking at the free variables of later splices, and taking a kind of transitive closure. Possible but sounds like real work. This is probably the main reason I've never attempted it. I don't know if the code is currently structured in a way that would make this easy, but in principle laziness could take care of only byte-code compiling bits we need couldn't it? It would probably need an unsafeInterleaveIO for loading the compiled objects of imports used, but it doesn't seem like it should be impossible. Also, we'd only need to do the bytecode compilation when -fth is on, so it shouldn't be a performance hit for normal usage even if we did the bytecode compilation whether the splices need it or not. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: % of memory unit to heap-controlling RTS flags
On Mon, Dec 04, 2006 at 01:15:16PM +0300, Bulat Ziganshin wrote: Monday, December 4, 2006, 4:19:45 AM, you wrote: and -H to (say) 25% of physical RAM. i had exactly the same idea. in particular, i want to setup -c value as percentage of available RAM I've added these suggestions to trac #750: http://hackage.haskell.org/trac/ghc/ticket/750 Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6-src-extralibs.tar.bz2
On Fri, Dec 08, 2006 at 08:55:28AM +0100, Sven Panne wrote: Am Donnerstag, 7. Dezember 2006 11:37 schrieb Christian Maeder: The archive http://www.haskell.org/ghc/dist/6.6/ghc-6.6-src-extralibs.tar.bz2 does not contain the files ControlPoint.hs and Domain.hs from directory libraries/OpenGL/Graphics/Rendering/OpenGL/GL/ If I see things correctly, the 6.6 extralibs contain the version 2.1 of the OpenGL package, i.e. the stuff currently in http://hackage.haskell.org/packages/unstable/OpenGL/, at least I hope so. :-/ These files are listed by the binary distribution http://www.haskell.org/ghc/dist/6.6/ghc-6.6-i386-unknown-linux.tar.bz2 This will probably have been made with whatever OpenGL was in darcs when the build was done (the binary distributions come from the nightly builds). The extralibs are not part of the GHC release, they are just sometimes bundled to make users' lives easier, so the GHC release is not tied to any particular version of the extralibs. To be honest, I don't fully understand the workflow for building the official GHC distributions currently. In former times, the whole tree, including libraries, had a CVS tag, so things were crystal-clear. GHC and the core libraries all have a 6.6 release tag. One problem we do have is that if you get a library (core, extralibs or otherwise) from darcs on two different days then you might get two different libraries with the same version number. We should possibly do something like having only odd second components (e.g. version 2.3 but not version 2.4) in darcs repos so we can at least spot these unstable version numbers. Then to do a release you'd push the three patches Version=2.4; tag 2.4; Version=2.5 all at once. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: difficult profiling example
Hi Serge, On Sat, Dec 09, 2006 at 04:19:26PM +0300, Serge D. Mechveliani wrote: This is again on the time profiling in ghc-6.6. Who could, please, guess what is happening? Is it possible for you to make available a complete, small example showing the confusing behaviour please? Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: HEAD ghci crash on ppc OS X
On Tue, Jan 16, 2007 at 02:19:46PM -0800, David Kirkman wrote: http://cass166.ucsd.edu/~david/link-patch Applied, thanks! Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: hasktags - small patch
Hi Marc,
On Sat, Feb 17, 2007 at 05:12:13AM +0100, Marc Weber wrote:
154c154
let wordlines = map words aslines
---
let wordlines = map mywords aslines
161a162,174
-- my words is mainly copied from Data.List.
-- difference abc::def is split into three words instead of one.
mywords :: String - [String]
mywords (':':':':xs) = :: : mywords xs
I'm not familiar with the code, but this looks like it is just a quick
fix for this particular case, while a proper fix would involve something
like breaking lines into blocks of characters in the same class (i.e. a
weak form of lexing by the Haskell Report rules). Is that right, or does
it turn out that the :: case is the only thing we need to worry about?
Better still, of course, if anyone was interested in spending some time
on this, would be to either (portably) use Language.Haskell to do the
lexing or (GHC-only) use the GHC API to do the lexing. I think someone
might actually have been looking at doing the latter already?
Thanks
Ian
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problems with -caf-all
On Thu, Feb 22, 2007 at 09:00:01PM -0800, R Hayes wrote: I get the following error message when I try to compile with -caf-all. /tmp/ghc583_0/ghc583_0.s:6482:0: FATAL:Symbol _Mainmain_CAF_cc_ccs already defined. Any ideas as to what I'm doing wrong? Nothing, it's a bug: http://hackage.haskell.org/trac/ghc/ticket/249 It should work in 6.6.1 and 6.8, when they are released, or a recent build of the 6.6 branch or HEAD. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problem compiling GHC
On Mon, Feb 26, 2007 at 02:48:38PM +0100, Cristian Perfumo wrote: So, what I did, to be sure that the error had nothing to do with my modification, was to download GHC again and try to build the original version. But I still get the same error (that I paste below this message). So you're trying to build 6.6 from the release tarball? What version are you trying to compile it with? Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded broken with pipes forking
On Mon, Mar 05, 2007 at 08:36:29AM -0600, John Goerzen wrote: On Mon, Mar 05, 2007 at 12:59:17PM +, Simon Marlow wrote: There seems to be a common misconception that forkOS is necessary to get certain kinds of concurrency, and forkIO won't do. I don't know where this comes from: the documentation does seem to be quite clear to me. The only reason to use forkOS is for interacting with foreign code that uses thread-local state; everytyhing else can be done with forkIO (and it is usually better to use forkIO). From reading the docs, it sounds like forkIO keeps everything in a single OS thread/process. Doesn't this mean that a program that uses forkIO instead of forkOS loses out on SMP machines? You can use e.g. +RTS -N2 to use 2 OS threads. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Still trying to build unregisterised for FreeBSD/amd64
Hi Gregory, On Thu, Mar 08, 2007 at 11:25:39AM -0500, Gregory Wright wrote: I fixed up Linker.c by replacing the calls to mmap (which will need fixing up anyway on FreeBSD/amd64) with MAP_FAILED and copying the definitions of four relocation types for X86_64 from machine/elf.h on the target into do_Elf_Rela_relocations. (The build on the host complained that R_X86_64_64, R_X86_64_PC32, R_X86_64_32 and R_X86_64_32S were undefined.) Anything that compiles should be fine until you want to get ghci working. With this change, the build on the host was able to complete. Collecting the .hc files works too, but the Makefile is out of date and references a few files that no longer exist. That sounds right - a couple of variants (e.g. debug) of one of the cmm files (AutoApply possibly) and one or two files that are in extralibs, if I remember correctly. With a little hand editing, this is fixed and I have what I believe is a good set of .hc files. Over on the target, I unpack the fresh ghc-6.6-src.tar.bz2 and drop the .hc files on top of it. On FreeBSD, gmp is usually installed by the ports system in / usr/local/lib, so I preface invocations of configure in distrib/hc-build by CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib so that the installed gmp is picked up in the configuration. I also edit mk/bootstrap.mk to add -L/usr/local/lib to HC_LD_BOOT_OPTS, and also add -lHSregex-compat -lHSregex-posix -lHSregex-base to HC_BOOT_LIBS. This sounds like you are using the original 6.6? You're probably better off trying to start from the 6.6 darcs branch instead (make a tarball of a checkout (might as well run autoreconf first) so you can be sure you have the same source on both machines). You should then be able to use --with-gmp-includes=/usr/local/include --with-gmp-libraries=/usr/local/lib and the HC_BOOT_LIBS should already be fixed. I also have to delete cabal-setup from the SUBDIRS in libraries/Cabal/ Makefile. Otherwise the build fails complaining that there is no rule to make Cabal-setup.o. *nod* I also have to change libraries/base/Makefile to not try to build Prim.hs. Again, fixed in the branch. With these changes, distrib/hc-build is ready to roll. It chugs along happily until it tries to build Linker.c (which I have copied over from the host, so it has the changes that I made there) and then ghc-inplace segfaults: ../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 -optc-fno-strict-aliasing -H16m -O -optc-O2 - static -I. -#include HCIncludes.h -fvia-C -dcmm-lint -c Linker.c - o Linker.o Segmentation fault (core dumped) gmake: *** [Linker.o] Error 139 gmake: Leaving directory `/tmp/ghc-6.6/rts' ../compiler/ghc-inplace has successfully compiled other files by this point, right? It probably won't help, but what does it say if you add -v? I suspect the next step is to try gdb and see what it says, though. It might be necessary to repeat the build with -g -O0 in GhcHcOpts or other variables (be wary of hc-build trampling changes you make to mk/build.mk). It might even be useful to tweak the process so that you end up with a -debug ghc (in fact, this should probably be the default). I don't have instructions for how to do this, but I've done it in the past and don't remember any major difficulties. Basically stick SRC_HC_OPTS += -debug in compiler/Makefile and fix any problems that come up (you might need to do things like make WAY=debug in rts/, and modify the list of files that get put in the tarball). If you get stuck, please shout. I am wondering what to try next. Could ghc-inplace on the target be crashing because of differences in say, ptr sizes on the host versus the target? It's possible; the closer you can make the host and target the fewer problems you are likely to have. Any help would be appreciated. Especially useful would be any comments on which parts of the instructions can be trusted and which may be bitrotted and needing revision. I think they should pretty much work with the 6.6 branch, although I'm also not convinced by the Don't worry if the build falls over in the RTS, we don't need the RTS yet. comment. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Progress building unregisterised for FreeBSD/amd64
Hi Gregory, On Tue, Mar 13, 2007 at 05:18:42PM -0400, Gregory Wright wrote: The 6.4.2 build now runs successfully to the end of the hc-build script. Ah, good, that'll hopefully make getting 6.6 working less painful. The interesting thing is that out of the box using the 6.4.2 bootstrap compiler, 6.6 still crashes when compiling Linker.c. Not just a little crash; it hung the whole system. Hmm. Do you know if it was eating all your memory? As I said, I'm using out of the box 6.6. Should I try a 6.6 from darcs? Yes, that's probably the best way to go. Put: GhcUnregisterised=YES GhcWithNativeCodeGen=NO GhcWithInterpreter=NO SplitObjs=NO GhcWithSMP=NO in mk/build.mk before you start building. If that breaks in the same way then set the -debug flag as I described before, delete compiler/stage1/ghc-6.whatever.it.is, run make stage=1 in compiler/ (should relink ghc with -debug) and then try the failing command again. Assuming it still breaks, try gdb'ing it (note that it's a shell script that's being run, so you'll need to run the real binary and pass the extra args to it manually with gdb). Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: More on FreeBSD/amd64
On Sun, Apr 01, 2007 at 06:10:25PM -0400, Gregory Wright wrote: Ah, remove the #if/#endif around the definition of puts, its export, and the GHC.Pack import in libraries/base/GHC/Handle.hs No such luck. I even copied puts into libraries/base/GHC/ ForeignPtr.hs but I still get I cycle because I need withCString to define puts: Oh, the 6.4.2 definition is different to the 6.6 definition. Does the 6.6 one work with 6.4.2?: puts :: String - IO () puts s = do write_rawBuffer 1 (unsafeCoerce# (packCString# s)) 0 (fromIntegral (length s)) return () (packCString# come from GHC.Pack) Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Login problems with trac
On Tue, Apr 03, 2007 at 03:13:50PM +, C Rodrigues wrote: The wiki has edit links if I login as guest, but not if I login as heatsink. Should be fixed now. Is that also because of the spam issue? Yup; you weren't in the developer group, but you are now. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: distributed compilation by GHC
On Thu, Apr 05, 2007 at 10:47:39AM -0700, Bryan O'Sullivan wrote: Simon Marlow wrote: This is one reason I wrote the 'setup makefile' patch for Cabal[1] recently. I haven't seen that patch show up in the cabal tree yet. Do you plan to commit it? I'd love to see it in. Coincidentally, I just pushed it. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Failed to load interface for `Prelude'
On Sat, Apr 07, 2007 at 12:27:47PM +0200, Thorkil Naur wrote: 1. It would probably be useful to give us the exact version of ghc that you are using and also the version you are building. (Sorry if you reported it and I missed it, but I cannot find it right now.) Ditto. 3. In #1195, igloo reports that he has included some code to provide additional information in case of ignored errors (which seems involved here). Some additional context that surrounds the first error report would therefore also be useful, I guess. Yes, if you are building a GHC which includes this patch then a full build log would be useful. == make all -r -f Makefile; in /Users/joelr/work/haskell/ghc/ libraries/ base ../../compiler/ghc-inplace -H32m -O2 -fglasgow-exts -cpp - Iinclude -#include HsBase.h -funbox-strict-fields -package-name base-2.0 -fgenerics -split-objs-c GHC/Err.lhs-boot -o GHC/Err.o- boot -ohi GHC/Err.hi-boot../../compiler/ghc-inplace -H32m -O2 - fglasgow-exts -cpp -Iinclude -#include HsBase.h -funbox-strict- fields -package-name base-2.0 -fgenerics -split-objs-c GHC/ PrimopWrappers.hs -o GHC/PrimopWrappers.o -ohi GHC/ PrimopWrappers.higcc -O-c System/CPUTime_hsc.c -o System/ CPUTime_hsc.ogcc -O-c System/Time_hsc.c -o System/Time_hsc.o../../ compiler/ghc-inplace -H32m -O2 -fglasgow-exts -cpp -Iinclude -#include HsBase.h -funbox-strict-fields -package-name base-2.0 - fgenerics -split-objs-c GHC/Base.lhs -o GHC/Base.o -ohi GHC/ Base.hi/tmp/ghc4826_0/ghc4826_0.split__178.s:unknown:missing indirect symbols for section (__TEXT,__symbol_stub)make[2]: *** [GHC/ PrimopWrappers.o] Error 1make[2]: *** It's possible that this could be caused by a broken splitter, yes. Adding -v -keep-tmp-files to the above commandline should help clarify things, with the help of the command ouput and the intermediate file contents. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
On Sun, Apr 08, 2007 at 07:49:24PM -0400, Gregory Wright wrote:
I have ghc-6.6 (darcs version from 20070405) running registerized on
FreeBSD/amd64.
Excellent! Well done, and thanks for persevering!
It would be great if you could let us have a bindist and any necessary
patches.
The fix is to patch libraries/base/Text/Regex/Posix.hs on the amd64
target:
--- libraries/base/Text/Regex/Posix.hs.sav Thu Apr 5 12:05:22 2007
+++ libraries/base/Text/Regex/Posix.hs Thu Apr 5 12:05:45 2007
@@ -106,7 +106,7 @@
regexec (Regex regex_fptr) str = do
withCString str $ \cstr - do
withForeignPtr regex_fptr $ \regex_ptr - do
- nsub - ((\hsc_ptr - peekByteOff hsc_ptr 4)) regex_ptr
+ nsub - ((\hsc_ptr - peekByteOff hsc_ptr 8)) regex_ptr
{-# LINE 109 Posix.hsc #-}
let nsub_int = fromIntegral (nsub :: CSize)
allocaBytes ((1 + nsub_int) * (16)) $ \p_match - do
Aha! That makes sense: When generating .hc files on the host machine,
hsc2hs makes a C program which generates a .hs module (with the host's
sizes embedded in it) which is finally compiled down to .hc as normal.
So I think to do this in a way that is porting-friendly, hsc2hs would
have to convert
f = ... #peek regex_t, re_nsub ...
into something like
-- Haskell:
foreign import re_nsub_off :: Int
f = ... (\hsc_ptr - peekByteOff hsc_ptr re_nsub_off) ...
/* C */
#import HsFFI.h
HsInt re_nsub_off(void) { return ... }
Unfortunately I don't think we can do anything as nice with #type.
With this patch, we are pretty close. However, there still seems to be
something wrong with the splitter. I can make a working registerized
compiler if I set splitObjs=NO in build.mk, but it seems as if
whatever is
wrong with ghc-split shouldn't be too hard to fix.
I've glanced at ghc-split.lprl, but on what files is it invoked? Can
I run it from the command line on a file and see check what comes out?
If you compile a module with
ghc -v -keep-tmp-files
then you should see the commandline it is using, and it should leave the
files for you to examine, and rerun the commands on, afterwards.
Thanks
Ian
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ANNOUNCE: GHC 6.6.1 Release Candidate
We are pleased to announce the Release Candidate phase for GHC 6.6.1. Snapshots beginning with 6.6.20070409 are release candidates for 6.6.1 You can download snapshots from here: http://www.haskell.org/ghc/dist/stable/dist/ Right now we have the source bundles: http://www.haskell.org/ghc/dist/stable/dist/ghc-6.6.20070409-src.tar.bz2 http://www.haskell.org/ghc/dist/stable/dist/ghc-6.6.20070409-src-extralibs.tar.bz2 Only the first of these is necessary. The extralibs package contains various extra packages that we normally supply with GHC - unpack the extralibs tarball on top of the source tree to add them, and they will be included in the build automatically. There are also currently binary distributions for x86_64/Linux and i386/Linux. More may appear later. The Windows (mingw) binary distributions are currently broken, but we hope to have this resolved soon. Please test as much as possible; bugs are much cheaper if we find them before the release! We hope to release in a couple of weeks, but of course that may slip if problems are uncovered. 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
Re: FreeBSD/amd64 registerised running
On Thu, Apr 12, 2007 at 04:33:27PM +0100, Simon Marlow wrote: I'm confused. I thought we copied the configuration from the target to the host as part of the bootstrapping process, but now I can't see how this is supposed to happen for HsBaseConfig.h. It looks like following the instructions in the building guide will result in failure if you try to cross-compile between machines with different word sizes, but I know I've done this in the past :-/ Ian, any idea how this is supposed to work? I guess we've just been lucky. #define HTYPE_INT Int32 is probably true everywhere we've tried in recent years, and probably covers most of the potentially troublesome cases. Thanks Ian ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
On Thu, Apr 12, 2007 at 08:49:03PM +0100, Malcolm Wallace wrote: Simon Marlow [EMAIL PROTECTED] writes: Ah. I was about to checkin a replacement for System.Posix.Types (in base) that uses hsc2hs instead of autoconf. Anyway, to answer your question, using hsc2hs in System.Posix.Types will cause problems for bootstrapping GHC, yes, because we can't run hsc2hs on the target without GHC, but we can run configure. But it is only a problem for cross-compiling - yes? Yes. And no more of a problem than ghc already has? No, with the configure method we can run configure on the target and copy the files back to the host. The instructions at http://hackage.haskell.org/trac/ghc/wiki/Building/Porting do so for includes/ghcautoconf.h includes/DerivedConstants.h includes/GHCConstants.h and look like they ought to for libraries/base/include/HsBaseConfig.h too. But we can't run hsc2hs on the target without having a Haskell compiler there. Thanks Ian ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Buildng ghc-devel from macports
On Thu, Apr 12, 2007 at 11:07:03AM -0400, Gregory Wright wrote: configure: No cpphs found configure: No greencard found Setup: Unrecognised flags: --with-cc=gcc make[1]: *** [stamp/configure.library.build-profiling.base] Error 1 make: *** [stage1] Error 2 it to me directly (I maintain the macports ghc-devel port) if you'd like. It sounds like the port needs to be updated to run sh boot instead of autoreconf. Thanks Ian ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
