- ghc-devs - Haskell.org

ghc-7.8-rc2 in -O2 mode eats all stack and RAM on pandoc-citeproc / highlighting-kate
by Sergei Trofimovich 09 Apr '14

09 Apr '14

Hello! I have noticed the problem in ghc-7.6.3 first when tried to build all haskell userland with -O2 opt level. It led to amazing bugs! Here is one of those (highlighting-kate hackage package): > [281 of 452] Compiling Text.Highlighting.Kate.Syntax.Asp ( highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.hs, highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.o ) > stack overflow: use +RTS -K<size> to increase it How to reproduce it: 1. Download a bundled file (6.6MB): http://code.haskell.org/~slyfox/selfcontained-eater-ghc-7.8-rc2.tar.gz 2. Unpack and run there: ./mk.sh The script is designed to plug any built ghc version w/o external depends. Command will fail as: $ ./mk.sh ... [281 of 452] Compiling Text.Highlighting.Kate.Syntax.Asp ( highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.hs, highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.o ) stack overflow: use +RTS -K<size> to increase it On ghc-7.6.3 it will progress a bit more: down to 452 file and will crash there similar way. I've 'cabal unpack'-ed all sources and configured/de-.hsc-ed them manually/added needed -DWhatever / added {-# LANGUAGE CPP #-} around. Nothing else. It's very hard to shrink such large thing manually down to 2-3 files. Would be cool if ghc (and cabal) would be able to spit something self-sufficient (like 'gcc -i' does) for devs to reproduce. Adding '-v' shows such log: ... *** Simplifier: Result size of Simplifier iteration=1 = {terms: 21,973, types: 21,838, coercions: 1,842} Result size of Simplifier iteration=2 = {terms: 21,952, types: 21,819, coercions: 1,842} Result size of Simplifier = {terms: 21,950, types: 21,817, coercions: 1,842} *** SpecConstr: Result size of SpecConstr***<CRASH> Thanks! -- Sergei

2 3

Avoiding bumping the major version of base in every release
by Johan Tibell 09 Apr '14

09 Apr '14

Hi! Bumping the major version number of base creates a bunch of work for package maintainers. Some times this work is justified, when there were actual non-backwards compatible API changes and maintainers need to fix their code. Often the work is busy work, as there were no real breakages and maintainers need to update their version bounds and make a new release. When bumps to the major version leads to busy work, maintainers often express a desire to get rid of version bounds altogether. While that might be a natural reaction, I don't think that's actually a good idea and it will lead to more breakages in the end*. All this is to say, we should try to avoid major version bumps to base. Here's my suggestion *Short term* - Make sure we only bump the major version number when we actually make a breaking change. We don't need to bump base because the major GHC version number changed. - Try harder to not make breaking changes. Breaking changes has a very high cost to users and are seldom worth it to them. For example, avoid renaming functions just because the new name feels cleaner. Just add a new function and have the old function call the new function. All successful languages do this. *Medium term* - Break up base a bit. There are several other good reasons to do this, but having a monolithic base means that breaking changes to the most obscure modules cause a major version bump for the package as a whole. * But in the case of missing upper bounds, the breakages and extra work falls on the users of libraries, not on their maintainers. That's really bad as the users are not really in a position to deal with the breakages. -- Johan

4 6

Backward-compatible role annotations
by Richard Eisenberg 09 Apr '14

09 Apr '14

I spent some time thinking about what, precisely, can be done here to make folks happier. (See the thread beginning here: http://www.haskell.org/pipermail/libraries/2014-March/022321.html) And, the answer seemed to all be in the concrete syntax. The only logical alternative (that I could think of) to having roles is to disallow GND, and I don't think anyone is proposing that. And, it is impossible to infer an author's desired roles for a datatype. The heuristics mentioned here all seem far too fragile and hard to predict to become a lasting feature of GHC (in my opinion). What's left? Concrete syntax. So, I have written and uploaded no-role-annots-1.0, a backward-compatible alternative to role annotations -- no CPP required. It's not as principled as proper role annotations, but it should do the job for most users. Here are two examples: 1. Datatypes: > import Language.Haskell.RoleAnnots > > data Map k v = > (Nominal k, Representational v) => MkMap [(k,v)] The constraints (which need be put on only one data constructor, if there are many) will get the built-in role inference mechanism to do what the user requests. In this example, the `Representational v` is actually redundant, but causes no harm. Because these classes have universal instances ("instance Nominal a") and have no methods, they should have no run-time significance. The only downside I can see is that the code above needs -XGADTs or -XExistentialQuantification to work, though it is neither a GADT nor has existentials. (Pattern-matching on such a definition needs no extensions.) 2. Newtypes: Newtype constructors cannot be constrained, unfortunately. So, we have to resort to Template Haskell: > import Language.Haskell.RoleAnnots > > roleAnnot [NominalR, RepresentationalR] > [d| newtype Map k v = MkMap [(k, v)] |] This is clearly worse, but I was able to come up with no other solution that worked for newtypes. Note that, in the example, I used the fact that Template Haskell interprets a bare top-level expression as a Template Haskell splice. We could also wrap that line in $( ... ) to be more explicit about the use of TH. Also problematic here is that the code above requires -XRoleAnnotations in GHC 7.8. To get this extension enabled without using CPP, put it in a condition chunk in your .cabal file, like this: > if impl(ghc >= 7.8) > default-extensions: RoleAnnotations I hope this is helpful to everyone. Please feel free to post issues/pull requests to my github repo at github.com/goldfirere/no-role-annots. Thanks, Richard

3 6

cant post to trac!
by Carter Schonwald 08 Apr '14

08 Apr '14

I'm trying to comment on a ticket, and its unconditionally saying "nope, you're spam" can't we at least whitelist the 100+ known good user names?? -Carter heres the gem Submission rejected as potential spam - BotScout says this is spam (Y|MULTI|IP|0|MAIL|0|NAME|6) - Defensio says content is not allowed (spam, 0.99, none) - StopForumSpam says this is spam (username [99.44])

2 1

GHC section of the Haskell Communities and Activities Report, May 2014 edition
by Simon Peyton Jones 07 Apr '14

07 Apr '14

Austin, Mihai, GHC devs This is about the GHC section of the HCAR. Up to now, we have written a status report on the GHC Wiki (you can see them stretching back several years), and the HCAR team have generously done the conversion to Latex. Mihai, I hope that is still OK. Austin: you are the Managing Editor for the GHC status report. Could you * take a look at what has happened in the last six months (the 7.8 release notes would be a great start) * draft an outline for the report * delegate writing tasks to the rest of us By "writing task" I mean typically only a paragraph or two (see past reports), but specifically including pointers to further reading. Really every substantial item should have such a pointer. The status report should be a jumping off point for someone who wants to know more. There are technical things (eg pattern synonyms), but let's not forget the important process things (eg changes to the repository structure). All GHC devs: do feel free to add things that Austin omits. In particular, he may not be aware of "what's on the horizon" things that you are working on. Austin, do you think you could complete the sketch, and delegate tasks, as soon as the 7.8 release is out (which should only be hours away)? So it should be done by the end of this week. Thanks all Simon | -----Original Message----- | From: Haskell [mailto:haskell-bounces@haskell.org] On Behalf Of Mihai | Maruseac | Sent: 05 April 2014 15:28 | To: haskell; haskell(a)haskell.org | Subject: [Haskell] Call for Contributions - Haskell Communities and | Activities Report, May 2014 edition | | Dear all, | | I would like to collect contributions for the 24th edition of the | | ================================================================ | Haskell Communities & Activities Report | | http://www.haskell.org/haskellwiki/Haskell_Communities_and_Activities_Rep | ort | | Submission deadline: 1 May 2014 | | (please send your contributions to hcar at haskell.org, | in plain text or LaTeX format) | ================================================================ | | This is the short story: | | * If you are working on any project that is in some way related | to Haskell, please write a short entry and submit it. Even if | the project is very small or unfinished or you think it is not | important enough --- please reconsider and submit an entry anyway! | | * If you are interested in an existing project related to Haskell that | has not previously been mentioned in the HCAR, please tell me, so | that I can contact the project leaders and ask them to submit an | entry. | | * Feel free to pass on this call for contributions to others that | might be interested. | | More detailed information: | | The Haskell Communities & Activities Report is a bi-annual overview of | the state of Haskell as well as Haskell-related projects over the | last, and possibly the upcoming six months. If you have only recently | been exposed to Haskell, it might be a good idea to browse the | previous edition --- you will find interesting projects described as | well as several starting points and links that may provide answers to | many questions. | | Contributions will be collected until the submission deadline. They | will then be compiled into a coherent report that is published online | as soon as it is ready. As always, this is a great opportunity to | update your webpages, make new releases, announce or even start new | projects, or to talk about developments you want every Haskeller to | know about! | | Looking forward to your contributions, | | Mihai Maruseac and Alejandro Serrano Mena (current co-editors) | | | FAQ: | | Q: What format should I write in? | | A: The required format is a LaTeX source file, adhering to the template | that is available at: | | http://haskell.org/communities/05-2013/template.tex | | There is also a LaTeX style file at | | http://haskell.org/communities/05-2013/hcar.sty | | that you can use to preview your entry. If you do not know LaTeX, then | use plain text. If you modify an old entry that you have written for an | earlier edition of the report, you should already have received your old | entry as a template (provided I have your valid email address). Please | modify that template, rather than using your own version of the old | entry as a template. | | Q: Can I include Haskell code? | | A: Yes. Please use lhs2tex syntax | (http://people.cs.uu.nl/andres/lhs2tex/) | The report is compiled in mode polycode.fmt. | | Q: Can I include images? | | A: Yes, you are even encouraged to do so. Please use .jpg format, then. | | Q: Should I send files in .zip archives or similar? | | A: No, plain file attachements are the way. | | Q: How much should I write? | | A: Authors are asked to limit entries to about one column of text. A | general introduction is helpful. Apart from that, you should focus on | recent or upcoming developments. Pointers to online content can be given | for more comprehensive or "historic" overviews of a project. Images do | not count towards the length limit, so you may want to use this | opportunity to pep up entries. There is no minimum length of an entry! | The report aims for being as complete as possible, so please consider | writing an entry, even if it is only a few lines long. | | Q: Which topics are relevant? | | A: All topics which are related to Haskell in some way are relevant. We | usually had reports from users of Haskell (private, academic, or | commercial), from authors or contributors to projects related to | Haskell, from people working on the Haskell language, libraries, on | language extensions or variants. We also like reports about | distributions of Haskell software, Haskell infrastructure, books and | tutorials on Haskell. Reports on past and upcoming events related to | Haskell are also relevant. Finally, there might be new topics we do not | even think about. As a rule of thumb: if in doubt, then it probably is | relevant and has a place in the HCAR. You can also ask the editor. | | Q: Is unfinished work relevant? Are ideas for projects relevant? | | A: Yes! You can use the HCAR to talk about projects you are currently | working on. You can use it to look for other developers that might help | you. | | Q: If I do not update my entry, but want to keep it in the report, what | should I do? | | A: Tell the editor that there are no changes. The old entry will | typically be reused in this case, but it might be dropped if it is older | than a year, to give more room and more attention to projects that | change a lot. Do not resend complete entries if you have not changed | them. | | Q: Will I get confirmation if I send an entry? How do I know whether my | email has even reached the editor, and not ended up in a spam folder? | | A: Prior to publication of the final report, the editor will send a | draft to all contributors, for possible corrections. So if you do not | hear from the editor within two weeks after the deadline, it is safer | to send another mail and check whether your first one was received. | | | -- | Mihai Maruseac (MM) | "If you don't know, the thing to do is not to get scared, but to | learn." -- Atlas Shrugged. | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

1 0

SV: Trying to build 64 bit GHC on Windows with the 32 bit version
by Niklas Larsson 07 Apr '14

07 Apr '14

You need a 64-bit ghc and gcc to build a 64-bit ghc. If that's what you want instructions are here: https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2 Niklas ----- Ursprungligt meddelande ----- Från: "Niculae Ionita" <nicu(a)ionita.at> Skickat: ‎2014-‎04-‎06 12:27 Till: "GHC Dev List" <ghc-devs(a)haskell.org> Ämne: Trying to build 64 bit GHC on Windows with the 32 bit version Hi, I got yesterday the sources (HEAD) of GHC and configured with ./configure --target=amd64-unknown-mingw32 which finally succeeded. But when I start make, I get almost in the beginning this error message: ===--- building phase 0 make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds libraries/hpc/ghc.mk:3: libraries/hpc/dist-boot/package-data.mk: No such file or directory libraries/Cabal/Cabal/ghc.mk:3: libraries/Cabal/Cabal/dist-boot/package-data.mk: No such file or directory libraries/bin-package-db/ghc.mk:3: libraries/bin-package-db/dist-boot/package-data.mk: No such file or directory libraries/hoopl/ghc.mk:3: libraries/hoopl/dist-boot/package-data.mk: No such file or directory libraries/transformers/ghc.mk:3: libraries/transformers/dist-boot/package-data.mk: No such file or directory libraries/dph/ghc.mk:134: *** dph_th_deps(v): libraries/dph/dph-base_dist-install_GHCI_LIB not defined!. Stop. make: *** [all] Error 2 Is it really something wrong in the dph or am I do something wrong? I have currently the 32 bit Windows version of HP-2013.02.0.0 installed. Regards, Nicu _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

1 0

Perf tests failing
by Simon Peyton Jones 06 Apr '14

06 Apr '14

Several perf tests have started failing on 32-bit windows. (See below). Some of them have very small allocation anyway, so it may be a library issue. I'm wondering whether it might be a consequence of the new inline byte array stuff. I don't know which commit made this start happening, but it's pretty recent. Johan, did you test on 32 bit? Thanks Simon perf/should_run InlineByteArrayAlloc [stat not good enough] (normal) perf/should_run T4267 [stat not good enough] (normal) perf/should_run T5949 [stat not good enough] (normal) perf/should_run T7619 [stat not good enough] (normal)

2 2

Trac seems to think I'm a spambot...?
by Dr. ERDI Gergo 06 Apr '14

06 Apr '14

Hi, I tried changing #8961 to `merge`, referring to commit 60ec752. However, I keep getting rejected with this error message: Submission rejected as potential spam Akismet says content is spam BotScout says this is spam (Y|MULTI|IP|0|MAIL|0|NAME|3) I don't even get a ReCaptcha box to work around it. Can anyone help me understanding what's going on and how to change 8961 to merge? Thanks, Gergo

1 0

Trying to build 64 bit GHC on Windows with the 32 bit version
by Niculae Ionita 06 Apr '14

06 Apr '14

Hi, I got yesterday the sources (HEAD) of GHC and configured with ./configure --target=amd64-unknown-mingw32 which finally succeeded. But when I start make, I get almost in the beginning this error message: ===--- building phase 0 make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds libraries/hpc/ghc.mk:3: libraries/hpc/dist-boot/package-data.mk: No such file or directory libraries/Cabal/Cabal/ghc.mk:3: libraries/Cabal/Cabal/dist-boot/package-data.mk: No such file or directory libraries/bin-package-db/ghc.mk:3: libraries/bin-package-db/dist-boot/package-data.mk: No such file or directory libraries/hoopl/ghc.mk:3: libraries/hoopl/dist-boot/package-data.mk: No such file or directory libraries/transformers/ghc.mk:3: libraries/transformers/dist-boot/package-data.mk: No such file or directory libraries/dph/ghc.mk:134: *** dph_th_deps(v): libraries/dph/dph-base_dist-install_GHCI_LIB not defined!. Stop. make: *** [all] Error 2 Is it really something wrong in the dph or am I do something wrong? I have currently the 32 bit Windows version of HP-2013.02.0.0 installed. Regards, Nicu

1 0

Re: ANNOUNCE: GHC 7.8.1 Release Candidate 2
by Michał J Gajda 06 Apr '14

06 Apr '14

Hi, GHC 7.8 rc2 exhausts all memory on Bio.PDB.EventParser.PDBEventParser module in -O3 mode, but not in -O2 mode. The tail of -v3 input seems to indicate that it dies during SpecConstr phase. The module successfully compiled with relatively low memory use RAM since GHC 6.12, so I wonder why the memory use exploded with the most recent version. Since I am new to GHC core, may I have a hint what debugging information may help with this particular issue? *** SpecConstr: ==================== SpecConstr ==================== Result size of SpecConstr * I submitted the ticket: https://ghc.haskell.org/trac/ghc/ticket/8960 -- Best regards Michał

1 0