Re: a better workflow?

Hi Richard, I think it's been around two years since I last built GHC, but back in the days I could get a full build time around 17 minutes on my laptop. Not sure how much the build times have increased since then but I suspect you should be able to build GHC faster than in 45 minutes. The

Re: Convenient URL alias for Trac tickets

One can also create bookmark with a keyword, as described on GHC wiki: https://ghc.haskell.org/trac/ghc/wiki/FirefoxTips Janek --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej

Re: Dataflow analysis for Cmm

> I don't entirely agree. I personally find it very hard to review large > patches as the amount of mental context generally seems to grow > super-linearly in the amount of code touched. Moreover, I think it's > important to remember that the need to read patches does not vanish the > moment the

Re: Dataflow analysis for Cmm

> (did you intend to send two identical links?) No :-) The branches should be js-hoopl-cleanup-v1 and js-hoopl-cleanup-v2 > Yes, the end result would be the same - I'm merely asking what would be > preferred by GHC devs (i.e., I don't know how fine grained patches to GHC > usually are). I don't

Re: Dataflow analysis for Cmm

Michał, Dataflow module could indeed use cleanup. I have made two attempts at this in the past but I don't think any of them was merged - see [1] and [2]. [2] was mostly type-directed simplifications. It would be nice to have this included in one form or another. It sounds like you also have

Re: Suggesting RankNTypes for ill-formed types

It doesn't really matter whether we suggest ExplicitForAll, ScopedTypeVariables or RankNTypes. The code in question is plainly wrong and should be a parse error. I skimmed the parser code and I see no easy way of doing this without breaking the fix for #3155 at the same time. What I would

Re: GHC HEAD (built with itself) blows allocation stats :-(

Sanity check: was the stage0 compiler built using "perf" settings? Janek Dnia poniedziałek, 30 maja 2016, Gabor Greif napisał: > Hi devs, > > I get some pretty bad allocation statistics when testing GHC HEAD. Not sure > why, but this is with a stage-0 compiler that is also GHC HEAD. (I doubt >

Re: 8.0.1 source tarballs available (yet again)

This time my build went through without problems on openSUSE 11.4. Janek Dnia wtorek, 17 maja 2016, Ben Gamari napisał: > tl;dr: We are giving this release another attempt. Cross your fingers >and try building again. > > Hello GHC packagers, > > Thanks for your help in the last few days

Re: [ANNOUNCE] GHC 8.0.1 source tarball available

I did `pip install alabaster` but keep getting the same error. Unless I need to rebuild everything from scratch (in which case I'll probably disable the docs). Janek Dnia sobota, 14 maja 2016, Ben Gamari napisał: > Jan Stolarek <jan.stola...@p.lodz.pl> writes: > > I am gettin

Re: [ANNOUNCE] GHC 8.0.1 source tarball available

I am getting a build error under openSUSE 11.4: make -C utils/haddock/doc html SPHINX_BUILD=/usr/bin/sphinx-build /usr/bin/sphinx-build -b html . .build-html Running Sphinx v1.2.3 loading translations [en]... done loading pickled environment... not yet created Theme error: no theme named

Re: Potentially confusing syntax for injective type families

te bike-shedding. I just made this > message to make sure the fact had been considered before release. > > Matt > > On Sun, Feb 14, 2016 at 9:28 AM, Jan Stolarek <jan.stola...@p.lodz.pl> wrote: > >> 2. Without the infectivity annotation, this declares an associate type >

Re: Potentially confusing syntax for injective type families

> 2. Without the infectivity annotation, this declares an associate type > synonym default. This isn't valid because Ht is not declared as an > associated type before hand and r is not mentioned on the LHS. > > class Hcl a b where > type Ht a b = r Indeed, this is invalid and GHC rejects this,

GHC performance dashboard question

Joachim, what do I need to do to have my wip/ branch picked up by the performance dashboard? I'm thinking about branch wip/js-hoopl-cleanup, which was pushed yesterday but still hasn't been measured for performance. Janek --- Politechnika Łódzka Lodz University of Technology Treść tej

Re: Dropping bzip2 release tarballs?

> it appears that essentially everyone uses the xz distributions. If this > really is the > case, then I would ask why are we spending the disk space, effort, > bandwidth, and complexity preparing the bzips. I stayed quite in this discusion so far, but I am one of the people still using bz2

Re: Best practices for merging?

> If there are multiple commits then a merge commit can serve to logically > group them. The cost of this is non-linear history. But I am still not sure what the actual benefit is? If the commits come one after another they are still logically grouped, with or without a merge commit. I also

Re: Best practices for merging?

> rebase onto master, and then merge with an empty merge commit, i..e, *not* > fast-forward. I was under the impression - perhaps incorrect - that it is our policy to avoid merge commits, ie. do only fast-forward merges. And when I look at git history I see very few merge commits. > This

Re: Special treatment of family and role in the parser

I'll take a look at the parser, see if we can do better. > I also suggest that keywords introduced by GHC extensions should be lexed as > keywords regardless > of whether extension is enabled or not: this way users won't get spurious > errors if they > suddenly enable extension and it turns

Re: Special treatment of family and role in the parser

On 21 Jan 2016 4:50 PM, "Jan Stolarek" <jan.stola...@p.lodz.pl> wrote: > > I'll take a look at the parser, see if we can do better. > > > > > I also suggest that keywords introduced by GHC extensions should be > > > > lexed as keywords regardless >

Re: Phab failing to apply patches

> * you validate locally (in a different build directory, so you can keep > using build flavour = devel2 in your development directory) > * fork the ghc github repository, push your branch there, and let Travis > validate it: https://ghc.haskell.org/trac/ghc/wiki/TestingPatches#Travis > * ask

Re: Phab failing to apply patches

> If you are working from an old base commit, either rebase your patch before > submitting to Phabricator (painful? you will have to do it before pushing > anyway, might as well do it now), or ignore the Harbormaster validate > result. I am typically working on some non-trivial features (ie.

Re: Phab failing to apply patches

napisał: > It changed some time last year. > > Before, Harbormaster would sometimes try to build some bizarro intermediate > mix of base commit + patch + master. See > https://ghc.haskell.org/trac/ghc/ticket/9855. > > > On Fri, Jan 15, 2016 at 7:06 PM, Jan Stolarek <jan.st

Phab failing to apply patches

It seems that Phab is once again failing to apply patches (eg. D1778, which built perfectly fine until latest update). Is anyone else experiencing this? Janek --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli

Re: Phab failing to apply patches

ll notice > there are indeed merge problems. > > > On Fri, Jan 15, 2016 at 6:49 PM, Jan Stolarek <jan.stola...@p.lodz.pl> > > wrote: > > It seems that Phab is once again failing to apply patches (eg. D1778, > > which built perfectly fine > >

Re: Injective type families

> I'm joining this conversation late, but I favor TypeFamilyDependencies over > InjectiveTypeFamilies. We use the annotations for things other than > injectivity! For example, > > > type family Plus a b = r | r a -> b, r b -> a > > is not injective under any common understanding of the word. But

Re: Injective type families

Ben, > 1. Should this feature be placed behind a LANGUAGE pragma? No, I don't think it should. I consider it a tiny addition to TypeFamilies that is not worth having its separate pragma. Injective TFs are fully backwards compatible, so no existing code will be broken. > 2. Could you

Re: Injective type families

> If I actually want to write backward-compatible type family code using > GHC-8.0, I'd prefer > to be able to enable TypeFamilies yet not InjectiveTypeFamilies, and have GHC > check that I am in > the common subset. Good point. I wonder if others agree. Janek --- Politechnika Łódzka Lodz

Re: Injective type families

> Is "InjectiveTypeFamilies" a good name for this? Or > "TypeFamilyDependencies"? Or what? My vote for "InjectiveTypeFamilies". Janek --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo

Re: Open data kinds

e-2 type synonyms that refer to namespace-1 > data constructors. And it's quite straightforward to ensure that `T` is > never present at runtime -- it's just a straightforward check in the > typechecker. > > Thus, according to general Principle B, `T` should be in namespace 1. > > Wha

Re: Open data kinds

> There is no language support to define a > "closed datatype" but it is possible to do so by not exporting any of > the constructors used to make the datatype. Data types are closed in a sense that if you define data Foo = MkFoo1 then you cannot add new data constructor, say MkFoo2, that will

Open data kinds

Devs, I plan to work on implementing open data kinds (#11080). The idea is that users will be allowed to declare open kinds and then populate them with member types. Perhaps I will also implement closed data kinds. This is already possible using DataKinds, but the idea is to declare a data

Re: Unused type variables with non-linear patterns

> Is there a ticket? #10982 Janek --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej

Re: GHC 8.0 feature freeze imminent

I would love to land my fix for #10828, but now that the wildcard refactor and no-kinds have been merged it will require a substantial rewrite. I'll try to do that on Wednesday and hopefully there will be enough time for a review before feature freeze. Janek --- Politechnika Łódzka Lodz

Unused type variables with non-linear patterns

An intersting thing came up when implementing warnings for unused type variables in type family patterns (#10982 / D1576): type family X a b where X a a = Int Should we emit a warning that `a` is unused? It does not appear in the RHS but it is actually used because of non-linear pattern.

Re: A GHC Library

> How do you suggest getting around copyright issues? LIke Eric said - by posting pre-prints. I think this should be legal. Note also these two clauses in the ACM Copyright Agreement: 1. "Copyright to the Work (...) is hereby transferred to the ACM (...) effective as of the date of this

Re: A GHC Library

I know this is a bit old, but I just had a thought that perhaps we could archive GHC papers on arxiv.org? This should be permanent and with a bit of effort we can get around copyright issues (I think). Surprisingly little Haskell research can be found on arXiv and perhaps it is time we

Wildcards in type functions vs. named wild cards

Simon, One of my students (Michał, CCd) is hacking on #10982 and he noticed a rather unexpected behaviour. If I say: {-# LANGUAGE TypeFamilies #-} module T10982 where type family F a where F _t = Int Then everything is fine. But if I enable NamedWildCards extension then suddenly this

Re: Wildcards in type functions vs. named wild cards

> If F _a = .. is allowed at all, I guess it should mean just the same as an > ordinary type variable. Yes, exactly. I want type-level behaviour to mimic term level here. > Would you like to implement that, and document it? Michał is working on that. Janek --- Politechnika Łódzka Lodz

Can't build current HEAD

I am unable to build current HEAD. I'm getting a build error in Outputable module: compiler/utils/Outputable.hs:1046:28: Not in scope: type constructor or class ‘CallStack’ compiler/utils/Outputable.hs:1047:23: Not in scope: ‘showCallStack’ The most likely culprit is

Re: Can't build current HEAD

I just verified this does not happen when building with GHC 7.8.4, so if our build machines (harbormaster, travis) are building using 7.8.4 this might not show up in the logs. Janek Dnia piątek, 13 listopada 2015, Jan Stolarek napisał: > I am unable to build current HEAD. I'm getting a bu

Pretty-printing TH data types

Devs, Module Language.Haskell.TH.Ppr defines Ppr instances for Template Haskell data types. What is the fastest way of testing these instances, ie. pretty-printing TH data types? I want to make sure that the instances I added print the data type in the way that I expect. Janek ---

Re: Pretty-printing TH data types

H.Ppr > > import Language.Haskell.TH > > > > $( do expr <- [| \x -> case x of True -> not; False -> id |] > > runIO $ putStrLn $ pprint expr > > return [] ) > > Richard > > On Nov 11, 2015, at 6:14 AM, Jan Stolarek <jan.stola...@p.lodz.p

Re: Building stage1 only

> it's very easy to end up in a state where `make` simply can't build, and only > easy fix is a `make clean` Out of sheer curiosity: in what situations does that happen for you? *If* you are working on a single branch, ie. you're not switching back and forth between master and your feature

Re: is this change in TH error message intentional?

Ömer, can you show us the source of Main.hs? Janek Dnia poniedziałek, 19 października 2015, Ömer Sinan Ağacan napisał: > Hi all, > > I realized this change in TH error messages: > > GHC 7.10.2: > > ➜ th-test ghc --make Main.hs > [1 of 1] Compiling Main ( Main.hs, Main.o ) >

Re: Unlifted data types

> Top-level variables may not have an unlifted type Ah, that makes much more sense now. Thanks. Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Unlifted data types

I think the wiki page is imprecise when it says: > data unlifted UBool = UTrue | UFalse > > Intuitively, if you have x :: UBool in scope, you are guaranteed to have > UTrue or UFalse, and > not bottom. But I still can say: foo :: UBool foo = foo and now foo contains bottom. I know that any

Re: D1182: Implement improved error messages for ambiguous type variables (#10733)

> In general we shouldn't commit anything that breaks validate, because > this causes problems for other developers. The right thing to do would > be to mark it expect_broken before committing. Sorry for that. I was actually thinking about marking the test as expect_broken, but then the problem

HEADS UP: interface file format change, full rebuild required

I just pushed injective type families patch, which changes interface file format. Full rebuild of GHC is required after you pull. Jan ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: A GHC Library

I have thus started a wiki page here: https://ghc.haskell.org/trac/ghc/wiki/Library Oh no... we aleady have such a page: https://ghc.haskell.org/trac/ghc/wiki/ReadingList And, actually, we used to have two: https://ghc.haskell.org/trac/ghc/wiki/GhcPapers But I made an effort last year and

Re: Adding location information to derived code

injectivity. Janek Thanks for spotting this. Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Jan | Stolarek | Sent: 10 June 2015 14:12 | To: ghc-devs@haskell.org | Subject: Adding location information to derived code | | Hi devs

Adding location information to derived code

Hi devs, say I have: class C a where type F a type F a = a instance C Int During compilation of instance C Int GHC will derive a default associated type instance F Int = Int. That instance has no location information and so any errors that it might cause will have a very

Re: RFC: Native -XCPP Proposal

One thing to keep in mind is that while cpphs will solve some problems of system-cpp, it will also bring problems of its own. I, for one, have run into problems with it when installing Agda. There is a very long thread here: https://lists.chalmers.se/pipermail/agda/2014/006975.html and twice

Re: RFC: Native -XCPP Proposal

recall someone else reported being affected by the same problem. So, until that problem is solved I would say it is a blocker as it would essentialy make development of GHC impossible for some people. Janek On 6 May 2015 at 06:38, Jan Stolarek jan.stola...@p.lodz.pl wrote: One thing to keep

Tracking bugs for libraries

I just noticed that bugs for several of our libraries can either be tracked on Trac (there is a corresponding entry in the Component field) or on github (issue tracking for that library is enabled in the repo). These libraries are: directory, hoopl, old-time, pretty, process, random and

Re: Tracking bugs for libraries

As of a couple of months ago, we updated https://wiki.haskell.org/Library_submissions to include the definitive source for where issues should be tracked on a package by package basis for all of the core libraries. As we spread maintainership of these packages around, we found more and more

Re: Hoopl question

Also Ning Wang and Andreas Voellmy have taken over maintainership of Hoopl Sadly, this is not what Hackage says. Janek , so they would be good people to talk to. Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Michal Terepeta Sent: 02 May 2015 14:21 To:

Re: Hoopl question

Which reminds me about another question I had -- the main reason to have the specialized module in GHC (instead of relying on the Hoopl one) is performance, right? Yes. If you're interested you might look at ghc-devs archives from July and August 2013 - I was doing MSR internship at that

Re: Hoopl question

Michał, one of my students is currently working on this: https://ghc.haskell.org/trac/ghc/wiki/Hoopl/Cleanup as his BSc thesis (see #8315). It might turn out that he will also have enough time to focus on performance issues in Hoopl but at this point it is hard to tell. Janek Dnia sobota, 2

Building patches that change format of interface files

GHC Devs, Once I compile GHC I use the cd ghc; make 2 trick to re-compile any changes. That however does not work if my code changes modify the format of interface files - the resulting compiler is unusable. In fact the only way to get a working compiler after interface format change that I

Re: Phabricator as bug tracker system (off topic)

we need to move Agda's bug tracker system from Google Code to something else. Finally! I disliked Google Code so much that if I found a bug in Agda I either mailed it to the discussion list or did not report it at all. And now on topic: - the only project I've been using Trac for is GHC. It

Re: Phabricator as bug tracker system (off topic)

I'm using Trac for managing 5 independent internal projects without a problem and this is a single installation. It looks like I'm not up to date with latest administrative Trac features. Sorry. Janek --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera

Re: ANNOUNCE: GHC version 7.10.1

Austin, links to x86_64 linux versions for CentOS don't work. Janek Dnia piątek, 27 marca 2015, Austin Seipp napisał: == The (Interactive) Glasgow Haskell Compiler -- version 7.10.1

Extracting kind variables from LHsTyVarBndr

forall hi, is there a function somewhere in the source code that extracts kind variable names from LHsTyVarBndr? I couldn't find anything. Writing one seems a bit scary given the fact that not all fields in HsType constructors are obvious to me. Janek --- Politechnika Łódzka Lodz University

Re: Hoopl advice: How to extend the graph?

What function I should reach for when I want to look at each block (or each Last node) in an CmmGraph, possibly modifying it and possibly adding auxillary nodes on the way? Take a look at Compiler.Hoopl.Block in hoopl library - it has some useful functions for working on blocks.

Re: Arrow Development

There was a rewrite mentioned here [2]. The deSugar/DsArrows.hs [3] looks convoluted. Any progress or work needed? Take a look at #7828 ticket. There was an intention to rewrite arrow desugarer and I worked on it for some time but eventually abandoned it. Sophie Taylor was planning to take up

Building vector with GHC HEAD

Devs, I'm not sure if this is the best place to ask this question but I'm almost certain someone here will have the answer. I want to build upstream master branch of vector library using GHC HEAD and cabal 1.22. Alas my attempts have failed: $ git clone g...@github.com:haskell/vector.git $

Re: Put Error: before error output

error is not always shown last on multi-core build. Somewhat related: #9219 Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Re: vectorisation code?

:47 AM, Herbert Valerio Riedel hvrie...@gmail.com mailto:hvrie...@gmail.com wrote: On 2015-01-20 at 09:37:25 +0100, Jan Stolarek wrote: Here's an alternate suggestion: in SimplCore, keep the call to vectorise around, but commented out Yuck. Carter and Brandon

Re: vectorisation code?

Here's an alternate suggestion: in SimplCore, keep the call to vectorise around, but commented out Yuck. Carter and Brandon are right here - we have git, let it do the job. I propose that we remove vectorization code, create a Trac ticket about vectorization DPH needing love and record the

Re: vectorisation code?

Out of curiosity I removed vectorisation code and did a devel2 build. Build time on my laptop went down from 25 minutes to 24 minutes - a modest 4% improvement. Of course there is more to be gained by avoiding recompilations later during development. I would obviously prefer to leave the

API Annotations question

Alan, devs, since API annotations were added some data types in the source code have extra comments related to these annotations, eg. -- | A type or class declaration. data TyClDecl name = -- | @type/data family T :: *-*@ -- -- - 'ApiAnnotation.AnnKeywordId' :

Re: API Annotations question

I am not sure what the best way is to add an internal source code link to it too without disturbing the haddock. I am open for suggestions. For me as a developer the most important thing is when and how do I need to add/modify these comments when working with the source code? First place where

Re: API Annotations question

and error because I still don't know how to use all annotation functions in the parser. I'm struggling to understand this but haddock comments in the parser don't suffice for me. Janek Alan On Thu, Jan 15, 2015 at 3:48 PM, Jan Stolarek jan.stola...@p.lodz.pl wrote: I am not sure what the best

Re: vectorisation code?

I share Richard's opinion. Janek Dnia wtorek, 13 stycznia 2015, Richard Eisenberg napisał: Hi devs, There's a sizable number of modules in the `vectorise` subdirectory of GHC. I'm sure these do all sorts of wonderful things. But what, exactly? And, does anyone make use of these wonderful

Re: Deprecating functions

I agree. You'll get rid of the redundancy in the library by removing it but you're users will have to live with (...) That's why I want to deprecate them first and give users one release cycle to switch to new functions. I assumed that's enough but we could make this two or three release

Deprecating functions

I want to deprecate some Template Haskell functions in GHC 7.12 and then remove them in GHC 7.14 (or whatever version that comes after 7.12). Do we have any workflow for remembering these kind of things? I was thinking about adding a conditional error: #if __GLASGOW_HASKELL__ 712 #error

Re: Deprecating functions

functions that can do the same thing (and more), so we have redundancy. Janek On Fri, Jan 9, 2015 at 10:22 AM, Jan Stolarek jan.stola...@p.lodz.pl wrote: I want to deprecate some Template Haskell functions in GHC 7.12 and then remove them in GHC 7.14 (or whatever version that comes

Re: Deprecating functions

I think Java's (!) policy for deprecation is good I think it's not. It keeps the library code a mess and many times I have seen users using functions that have been deprecated for years just because it's easier to suppress a warning than change the code. I don't want Haskell to go down that

Re: Bash completion in GHC 7.10

Reported this as #9963. Janek Dnia sobota, 3 stycznia 2015, Sergei Trofimovich napisał: On Wed, 10 Dec 2014 16:43:57 +0400 Lennart Kolmodin kolmo...@gmail.com wrote: Hi everybody! TL;DL GHC 7.10 will have better bash completion, try it out! I'd like your help to verify the

How do I investigate parser conflicts?

I noticed that changes I made to the Parser on my branch increase the number of reduce/reduce conflicts. Are there any tools/techniques/etc I can use to investigate this? Or do I just have to use trial and error (possibly guided with some knowledge of parsing)? Specifically, is there any way

Re: How do I investigate parser conflicts?

Yes, that's probably what I was looking for. Thanks. Janek PS. Only 55K lines of log to analyze... ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Fatal: Reference is not a tree

That's because I updated haddock submodule but that update was not pushed to Phab. I was able to do a quick build of my patch without updating haddock so it should only be a problem if you try to validate. That said, is there a way I can push changes in a submodule to a phab revision? Janek

Re: Fatal: Reference is not a tree

Haddock is on Phabricator and has an .arcconfig file. All you need to do is submit a revision like normally, just run 'arc diff' in the Haddock directory. But this will create a separate revision for haddock, right? My changes in haddock are related to revision I am working on. What I would

Re: Can we rename completion to autocomplete

Done. I moved completion/ directory to utils/ Janek Dnia czwartek, 18 grudnia 2014, Austin Seipp napisał: I'd say just move it under utils/. We really need to organize the top-folder more, but that's for another day. On Thu, Dec 18, 2014 at 11:18 AM, Jan Stolarek jan.stola...@p.lodz.pl wrote

Re: Can we rename completion to autocomplete

Bump. Any decisions on this one? If not then I'll move that folder somewhere else because it's getting in the way. Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

RFC: Remove -fwarn-unticked-promoted-constructors from -Wall

We recently got a new warning -fwarn-unticked-promoted-constructors (see #9778 and D534). This warning is enabled with -Wall but I think that this is not a good idea. I strongly propose to remove it with -Wall. Rationale: 1. I feel that ticks add unnecessary noise: prDictOfPReprInstTyCon ::

Understanding DsMeta module

I'm implementing Template Haskell support for injective type families and I'm struggling to understand DsMeta module. It seems that all functions in that module delegate their calls to functions in Language.Haskell.TH.Lib via wired-in names and the `DsMeta.rep2` function. I'm puzzled by this

Re: Understanding DsMeta module

Thanks. That helps but I still don't understand why the calls are delegated to template-haskell library. Couldn't all of this be done locally? Janek Dnia środa, 17 grudnia 2014, Richard Eisenberg napisał: On Dec 17, 2014, at 12:29 PM, Jan Stolarek jan.stola...@p.lodz.pl wrote: Why

Re: performance regressions

Using this combinator instead of writing the algorithm directly cost me 30% allocation overhead! What does your algorithm look like when you write it directly? Something like this: flatten_many fmode roles tys = unzip `liftM` mapM go (zip roles tys) where go (Nominal,ty) =

Customizing Phab

After working with Phab for a while I realize I'd like to customize layout of a revision. When I work with a revision I most often read comments and source code and write my replies (often based on comments). The problem is that comments are located at the top of a page whereas the text

Re: Customizing Phab

Not a direct answer to your question, but have you tried the 'z' hotkey (or keyboard shortcut) while in a revision? It cycles comment panel haunting modes (see '?' hotkey for a list of other useful hotkeys). I wasn't aware of that. This helps to some extent. Being able to hide unused panels

Re: Reachable modules from DynFlags out of date

I suspect you need to add all of I believe Simon needs to figure out the diff, ie. which modules are displayed in the dependency list but are missing in the compiler/ghc.mk file. I recall I had to done the same in one of my commits:

Re: -O/-O2 causes program to run too slow

While I don't know how to help with your problem I encourage you to attach your code example to #1168. This will certainly be helpful in working on that bug. Janek Dnia niedziela, 7 grudnia 2014, David Spies napisał: Ok, so I found that it was an instance of this:

Re: ghc.haskell.org slow?

Works fine for me. Janek Dnia poniedziałek, 8 grudnia 2014, Simon Peyton Jones napisał: Is it just me, or is access to ghc.haskell.org and git.haskell.org very slow? I guess it could be at my end; I don't know how to tell. But git pull and Trac access takes tens of seconds, even minutes

Re: HEADS UP: I'm removing the remaining .lhs files in compiler/ soon

me and Herbert really really wanted to remove all the .lhs files in the compiler. I'll only say one thing: FINALLY ! Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Possible error with strict_mark in Parser.y

Looking at the source code comments it seems that you're right: data HsBang = HsUserBang -- The user's source-code request (Maybe Bool) -- Just True{-# UNPACK #-} -- Just False {-# NOUNPACK #-} -- Nothing no pragma

Re: Performance regression on typechecking type families?

I personally have run into exponential compile times with type families. Unfortunately I have not had the time yet to reduce my test case to something tractable. Janek Dnia sobota, 29 listopada 2014, Dr. ERDI Gergo napisał: Hi, Prompted by this question:

Re: Back-porting pattern synonym type signature syntax for GHC 7.8.4 [Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1]

My instinct is that (a)-(c) overwhelm (d); i.e. let sleeping dogs lie. These arguments look convincing. I suppose the relevant section in the User's Guide should inform about changes planned for 7.10? To a limited extent this would address (d). Janek

Re: More flexible literate Haskell extensions (Trac #9789), summary on wiki

.lhs = Literate Haskell So maybe .mhs = Markdown Haskell instead of .lhs+md? Jan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Error handling in the renamer

I'm improving my patch for injective type families and I have a question about error handling in the renamer. If I write this incorrect definition: type family F a b = r | r - c I get these errors: T6018rnfail.hs:36:1: Not in scope: type variable ‘c’ T6018rnfail.hs:36:26:

HEADS UP: Keeping the Newcomers wiki page alive

HEADS UP: if you see a ticket that is easy enough to be tackled by a newcomer please tag it using newcomer keyword. I already added newcomer keyword to tickets that were listed on the Newcomers page and replaced the static list with dynamicaly generated one. I decided to filter out tickets

  1   2   3   >