- ghc-devs - Haskell.org

RE: lambda mining
by Simon Peyton-Jones 19 Aug '13

19 Aug '13

(devs: this thread is about adding useful new benchmarks to nofib.) Oh bother. I'd forgotten about dependencies. I don't want to make building nofib depend on libraries other those in GHC anyway (bytestring, unix ok, asynch perhaps not). If that makes it tricky, maybe we should give up on the idea. S From: José Pedro Magalhães [mailto:jose.pedro.magalhaes@cs.ox.ac.uk] Sent: 05 August 2013 08:41 To: Simon Peyton-Jones Subject: Re: lambda mining I'm not entirely sure how to do that, though. Do I just add it to the "real" subset? How about dependencies (e.g. bytestring >= 0.9, unix >= 2.5.0, async >= 2.0.0.0, ...) Cheers, Pedro On Fri, Aug 2, 2013 at 9:02 AM, Simon Peyton-Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: great! Just add it :-) simon From: José Pedro Magalhães [mailto:jpm@cs.ox.ac.uk<mailto:jpm@cs.ox.ac.uk>] Sent: 30 July 2013 07:48 To: Simon Peyton-Jones Cc: Nicolas Wu; Wouter Swierstra; Jeroen Bransen Subject: Re: lambda mining Hi Simon, (CC-ing co-authors) Yes, I think it might work fine. Its running time can also be adjusted easily, depending on the maps given as input and some internal parameters. How would we go about adding it to nofib? Thanks, Pedro On Tue, Jul 30, 2013 at 7:04 AM, Simon Peyton-Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: Pedro Wandering past your home page I took a look at your "lambda mining" paper. Would it be suitable as a nofib benchmark? Moderate size, authentic code... Would you be interested? Simon

3 4

Non-parallel version of GC
by Edward Z. Yang 19 Aug '13

19 Aug '13

Hello all, How would people feel about an alternate GC implementation in GHC which is not parallel? A GC like this would be simpler to understand, maybe a little faster when parallel collection is not being used, and (most importantly for my case) easier to extend with interesting features. In particular, this implementation would not have gen_workspace or gc_thread; these would either be unnecessary or folded directly into the actual generation object. Thanks, Edward

2 3

Literal overflow test fails
by Simon Peyton-Jones 19 Aug '13

19 Aug '13

On 32 bit Windows I get this (with HEAD). libraries\Win32\Graphics\Win32\GDI\HDC.hs:145:14: Warning: Literal 2147483648 of type Int overflows The offending code is: setTextCharacterExtra dc extra = failIf (== 0x80000000) "SetTextCharacterExtra" $ c_SetTextCharacterExtra dc extra The new literal-overflow test objects to 0x80000000 :: Int. I'm not sure if it should object; in this case we are deliberately using the bit-pattern for minBound. Also what happens on a 64-bit architecture? What should the behaviour here be? - should we use minBound here? - what should the new literal-overlflow code do for 0xblah constants? This is currently breaking the HEAD build. Simon

4 4

Wired-in type class
by Joachim Breitner 19 Aug '13

19 Aug '13

Dear List, I have some questions about the inner parts of GHC, where I need to learn a lot. This is related to my attempts on newtype casting, but should probably be kept separate from the conceptual discussions. Say I need to create a wired-in type class, because it cannot be represented in Haskell. The Core type constructor that will come out of it will have one field of type ~R#, which is the reason why I cannot write it in Haskell. It seems that defining something wired-in is not a very local operation that affects, at least primops.txt.pp and TysPrim.lhs. Does it affect more? It seems that there is not precedent of a wired-in type class. Is that possible without touching too many parts of the compiler? Or is it saner to just have "class NT a b" in a module in ghc-prim without the constraint and use special magic when compiling that file to add the required field to the data constructor representing the class? (Similar to how the kind of ~ is adjusted during compilation?) Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata(a)debian.org

4 7

RE: [GHC] #7901: Bad error message when using UnicodeSyntax ∀ without ExplicitForall
by Simon Peyton-Jones 19 Aug '13

19 Aug '13

Don't forget to update the "Test case" field of the ticket. Generally we name the test cases the same as the ticket (eg T7901 in this case), but the test case field * is a quick check that there IS a regression test * works even if the test is named differently (in this case ParserNoForallUnicode) * works if there are multiple tests * tells which directory to look in (in this case parser/should_fail) I've updated http://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/BugTracker to add these comments Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf Of | GHC | Sent: 19 August 2013 05:17 | Cc: ghc-tickets(a)haskell.org | Subject: Re: [GHC] #7901: Bad error message when using UnicodeSyntax ∀ | without ExplicitForall | | #7901: Bad error message when using UnicodeSyntax ∀ without | ExplicitForall | -------------------------------------------------+---------------------- | --- | Reporter: exbb2 | Owner: | ajp | Type: bug | Status: | patch | Priority: normal | Milestone: | Component: Compiler | Version: | 7.6.2 | Resolution: | Keywords: | Operating System: Unknown/Multiple | Architecture: | Type of failure: Incorrect warning at | Unknown/Multiple | compile-time | Difficulty: | Test Case: | Unknown | Blocking: | Blocked By: | | Related Tickets: | -------------------------------------------------+---------------------- | --- | | Comment (by Austin Seipp <aseipp@…>): | | In [changeset:5535416500167a1167bf8b375acf999ad4b20924/testsuite]: | {{{ | #!CommitTicketReference repository="testsuite" | revision="5535416500167a1167bf8b375acf999ad4b20924" | Test case for #7901. | | Signed-off-by: Austin Seipp <aseipp(a)pobox.com> | }}} | | -- | Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7901#comment:7> | GHC <http://www.haskell.org/ghc/> | The Glasgow Haskell Compiler | | _______________________________________________ | ghc-tickets mailing list | ghc-tickets(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-tickets

1 0

Question about `compileToCoreModule`
by Daniel F 19 Aug '13

19 Aug '13

Hi, everyone, I have a question about `compileToCoreModule` function from the GHC module. I noticed that the following code not just outputs the Core code, but also produces object files and a linked executable (in case when 'test.hs' is a program): --------------------------- module Main where import DynFlags import GHC import GHC.Paths import MonadUtils import Outputable main = defaultErrorHandler defaultFatalMessager defaultFlushOut $ do runGhc (Just libdir) $ do dflags <- getSessionDynFlags setSessionDynFlags dflags cm <- compileToCoreModule "test.hs" output cm -- | Outputs any value that can be pretty-printed using the default style output :: (GhcMonad m, MonadIO m) => Outputable a => a -> m () output a = do dfs <- getSessionDynFlags let style = defaultUserStyle let cntx = initSDocContext dfs style liftIO $ print $ runSDoc (ppr a) cntx ----------------------------- I thought this was strange and looked up the source of 'compileToCoreModule', and indeed, it calls 'load LoadAllTargets'. So my question is, why is it necessary to do so? I had the impression that compiling Haskell to Core is a step that precedes compiling to the actual binary. NB: I tried setting `ghcLink' and `hscTarget' options in dynflags to `NoLink' and `HscNothing' respectively, but that resulted in somewhat weird Core: $ cat test.hs module Test (test) where test :: Int test = 123 test2 :: String test2 = "Hi" $ ./testcore %module main:Test (Safe-Inferred) [(reF, Identifier `Test.test')] Test.test :: GHC.Types.Int [LclIdX] Test.test = GHC.Types.I# 123 $ ./testcore-nolinknothing %module main:Test (Safe-Inferred) [] Thanks. -- Sincerely yours, -- Daniil Frumin

1 0

Committer list [was: Re: NOTICE: Gitolite migration is complete.]
by Austin Seipp 19 Aug '13

19 Aug '13

Sounds good to me. I've found the same info useful. In fact, just yesterday I had added the list of committers I assembled to the Contributors page: http://ghc.haskell.org/trac/ghc/wiki/Contributors I've gone ahead and created a Committers page with more info. It also lets people know who to contact (me) if they would like access, and should help people find out who to talk to when they need help. http://ghc.haskell.org/trac/ghc/wiki/Committers I went ahead and filled out most of the details on the people I'm aware of, except for email. I'm not sure what you'd like to publicly put out there on Trac. Developers - If you'd like, please take the time to fill in your email and amend anything I got wrong (e.g. I just put pretty much everyone's "committer date" as this month.) (Also, forgive me for looking into most peoples affiliations and listing them here, but it does help individual identification - and it's a decently diverse set of places, which is neat in its own right!) On Fri, Aug 16, 2013 at 5:54 AM, Simon Peyton-Jones <simonpj(a)microsoft.com> wrote: > > Herbert, Austin, Simon > > Thanks for taking charge of our git repos. Very very helpful! > > On the question of committers, there's always the danger that we give people commit permission, and several years later they've gone silent and we can barely remember who or why. I wonder if we should have a "Committers" wiki page, with a bullet for each person in this format: > > * Simon Peyton Jones, Microsoft Research, Cambridge, UK. Trac: simonpj; email: simonpj(a)microsoft.com. Added as a committer June 2013. Main areas of interest: renamer, type checker, optimiser. > > I often have trouble connecting people's Trac identity with their email; and it's quite helpful to know which country people are in and where they work. > > Do you think that would make sense? We could also establish the convention that if you don’t commit for a year you'll lose commit access; though it can be re-activated on request. > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Austin > | Seipp > | Sent: 09 August 2013 23:20 > | To: ghc-devs(a)haskell.org > | Subject: NOTICE: Gitolite migration is complete. > | > | All, > | > | Push access is now restored and Gitolite is in place! This brings some > | nice updates: > | > | * There's now access to the 'git' protocol for cloning anonymously. > | This lets you clone even the biggest repos extremely quickly, and is > | the fastest method for getting a copy of the tree. > | * Firewalled? Cloning over HTTP now uses Smart HTTP support for Git, > | meaning it should be faster too! > | * We will soon have Gitweb available, once our git.haskell.org CNAME > | is in place. Eventually we'd like something akin to > | https://git.kernel.org/cgit/ possibly. > | * None of you have shell access to ghc.haskell.org anymore (well, > | this is a nice update for us administrators :) > | > | The following people have had their keys re-added, and should be able > | to push and pull from the new setup. > | > | * Andreas Voellmy > | * Austin Seipp > | * Ben Lippmeier > | * Iavor Diatchki > | * David Terei > | * David Waern > | * Dimitrios Vytiniotis > | * Duncan Coutts > | * Edsko de Vries > | * Erik de Castro Lopo > | * Edward Yang > | * Geoffrey Mainland > | * Gabor Greif > | * Herbert Valerio Riedel > | * Ian Lynagh > | * Ilya Sergey > | * Johan Tibell > | * José Pedro Magalhães > | * Jan Stolarek > | * Manuel Chakravarty > | * Max Bolingbroke > | * Nicholas Frisby > | * Paolo Capriotti > | * Richard Eisenberg > | * Roman Leshchinskiy > | * Ross Patterson > | * Simon Hengel > | * Simon Marlow > | * Simon Peyton Jones > | * Thomas Schilling > | > | The following people still have shell access for any administrative > | needs: > | > | * Austin Seipp (and the remaining haskell.org infrastructure team.) > | * Herbert Valerio Riedel > | * Ian Lynagh > | > | I have undoubtedly missed some people. Please talk to me and we'll get > | you set up! > | > | If you're a developer, please read about developer changes here: > | > | * http://ghc.haskell.org/trac/ghc/wiki/GitolitePlan#Developerchanges > | > | TL;DR: if you have an old tree, run the following four commands from > | the root to fix the push/pull URLs. > | > | $ git checkout master > | $ git pull https://github.com/ghc/ghc.git master > | $ ./sync-all -r ssh://git@ghc.haskell.org remote set-url origin > | $ ./sync-all -r ssh://git@ghc.haskell.org remote set-url --push origin > | > | The reason you must get the latest-copy of ./sync-all is because > | Herbert made some last minute bug fixes. Technically, you could just > | download the latest copy and run it directly, but this is easier and > | fairly straight forward. > | > | Please direct any concerns to me, like if you need something off the > | server, need your shell account back, or need commit access. Over the > | next few days, I'll be cleaning up the wiki - updating references and > | guides on how to check out the source for users and developer. I also > | might be sending out some emails with questions while we refine the > | new setup in the next few days (there were some Trac integration > | changes.) > | > | Also, a gigantic applause for Herbert, who did a lot of the work here! > | > | -- > | Regards, > | Austin - PGP: 4096R/0x91384671 > | > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs(a)haskell.org > | http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin - PGP: 4096R/0x91384671

3 6

runghc on 32bit
by Kazu Yamamoto 19 Aug '13

19 Aug '13

Hi, The following code should print string anyway. https://gist.github.com/kazu-yamamoto/6265119/raw/1da32b8740222076e612373a7… But if I execute it with "runghc" on 32 bit Mac and 32 bit Linux, it terminates silently. If complied, it works. If I execute it with "runghc" on 64 bit Linux, it works. Does anyone reproduce this? I'm using GHC 7.7.20130814. --Kazu

1 0

Help needed: exporting pattern synonyms
by Dr. ERDI Gergo 16 Aug '13

16 Aug '13

Hi, As you can see in http://ghc.haskell.org/trac/ghc/ticket/5144#comment:18, my implementation of pattern synonyms is now feature complete for the first two sections of http://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms, namely, simple pattern synonyms and pattern-only synonyms. Bidirectional pattern synonyms using 'where' will also be easy to add and will be part of my initial submission. The current version of my code is at https://github.com/gergoerdi/ghc/compare/pattern-synonyms However, the one part I am struggling with is implementing exporting of pattern synonyms. The pipeline is pretty clear to get the pattern synonym definitions to the ModGuts, but I get lost there. Since they are a completely compile-time thing, there's nothing to put in the CgGuts (well, I guess the wrapper (i.e. the patsyn-in-an-expression-context) should be put there). However, when I look at existing stuff in ModIface/ModDetails, I don't really see a pattern for storing actual definitions there. Could someone help me with this part please? Would it make sense to put something like https://raw.github.com/gergoerdi/ghc/pattern-synonyms/compiler/basicTypes/P… in the interface? Or put the "psPatDef" and the "fmap snd psWrapper" parts in the CgGuts and the rest in the interface? Thanks, Gergo -- .--= ULLA! =-----------------. \ http://gergo.erdi.hu \ `---= gergo(a)erdi.hu =-------'

1 0

FW: Building GHC on Mac stops
by Simon Peyton-Jones 16 Aug '13

16 Aug '13

Austin This looks like a make-system bug, based on a cursory read. Worth a ticket? Do you know enough about the build system to fix it? It's clearly annoying! Simon Marlow and/or Ian Lynagh may well be able to help Simon -----Original Message----- From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Kazu Yamamoto Sent: 06 August 2013 13:00 To: ghc-devs(a)haskell.org Subject: Re: Building GHC on Mac stops Hi Nicolas, My guess is here: libraries/integer-gmp/configure generates "gmp.h". Building mkGmpDerivedConstants starts in parallel. Since "configure" takes time, "mkGmpDerivedConstants" is build before "gmp.h" is created. How can we ensure that these two jobs are carried out sequentially? --Kazu > I never determined how to fix this. Here's the notes I developed: > > tl;dr For some reason, it seems gmp.h is not recognized as a dependency of > mkGmpDerivedConstants.o > > HTH > > ----- > > If I run > > $ perl boot; ./configure; make -j4 > > I tend to see a build failure. Immediately running make -j4 again succeeds. > > In the following snippet from the log, > FILE=libraries/integer-gmp/mkGmpDerivedConstants/mkGmpDerivedConstants.c > > {{{ > "/usr/bin/gcc" -m64 -fno-stack-protector > -Ilibraries/integer-gmp/gmp > -Ilibraries/integer-gmp/mkGmpDerivedConstants/dist > -c FILE -o > libraries/integer-gmp/mkGmpDerivedConstants/dist/build/mkGmpDerivedConstants.o > > FILE:15:17: error: gmp.h: No such file or directory > FILE: In function ¡main¢: > FILE:68: error: ¡MP_INT¢ undeclared (first use in this function) > FILE:68: error: (Each undeclared identifier is reported only once > FILE:68: error: for each function it appears in.) > FILE:69: error: expected expression before ¡)¢ token > FILE:69: error: expected expression before ¡)¢ token > FILE:70: error: expected expression before ¡)¢ token > FILE:70: error: expected expression before ¡)¢ token > FILE:71: error: expected expression before ¡)¢ token > FILE:71: error: expected expression before ¡)¢ token > make[1]: *** > [libraries/integer-gmp/mkGmpDerivedConstants/dist/build/mkGmpDerivedConstants.o] > Error 1 > make[1]: *** Waiting for unfinished jobs.... > }}} > > Some 1677 lines later, I see the line > >> cp libraries/integer-gmp/gmp/gmpbuild/gmp.h libraries/integer-gmp/gmp/ > > Which is I suppose why make -j4 succeeds the second time around. > > I also see > >> libraries/integer-gmp/mkGmpDerivedConstants/ghc.mk:20: > libraries/integer-gmp/mkGmpDerivedConstants/dist/build/.depend.c_asm: No > such file or directory > > many lines above. > > On Mon, Aug 5, 2013 at 9:26 PM, Kazu Yamamoto <kazu(a)iij.ad.jp> wrote: > >> Hi, >> >> I'm using GHC head (32bit) on Mac. Recently, building GHC head >> stops: >> >> ---- >> % make maintainer-clean; perl boot; ./configure --prefix=/ghc-head; make >> -j3 >> ranlib: file: .libs/libgmp.a(mp_clz_tab.o) has no symbols >> ranlib: file: .libs/libgmp.a(obprintf.o) has no symbols >> ranlib: file: .libs/libgmp.a(obvprintf.o) has no symbols >> ranlib: file: .libs/libgmp.a(obprntffuns.o) has no symbols >> ranlib: file: .libs/libgmp.a(repl-vsnprintf.o) has no symbols >> libtool: link: rm -fr .libs/libgmp.lax >> libtool: link: ( cd ".libs" && rm -f "libgmp.la" && cp -p "../libgmp.la" " >> libgmp.la" ) >> cp libraries/integer-gmp/gmp/gmpbuild/gmp.h libraries/integer-gmp/gmp/ >> cp libraries/integer-gmp/gmp/gmpbuild/.libs/libgmp.a >> libraries/integer-gmp/gmp/ >> inplace/bin/mkdirhier libraries/integer-gmp/gmp/objs >> cd libraries/integer-gmp/gmp/objs && /usr/bin/ar x ../libgmp.a >> ranlib libraries/integer-gmp/gmp/libgmp.a >> ranlib: file: libraries/integer-gmp/gmp/libgmp.a(mp_clz_tab.o) has no >> symbols >> ranlib: file: libraries/integer-gmp/gmp/libgmp.a(obprintf.o) has no symbols >> ranlib: file: libraries/integer-gmp/gmp/libgmp.a(obvprintf.o) has no >> symbols >> ranlib: file: libraries/integer-gmp/gmp/libgmp.a(obprntffuns.o) has no >> symbols >> ranlib: file: libraries/integer-gmp/gmp/libgmp.a(repl-vsnprintf.o) has no >> symbols >> make: *** [all] Error 2 >> % >> ---- >> >> One more "make -j3" finishes the building. I'm sure that this does not >> happen before. >> >> Are there any guys who get this problem? >> >> --Kazu >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs(a)haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

3 3