the case of the missing Cabal doc
In times of yore (prior to 7.8), when GHC build a bindist, it included the generated HTML manual for Cabal. As of 7.8, this seems to have gone missing-in-action. Anyone know where it went? - Mark ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: HEADS-UP: Git submodule conversion imminent
Herbert, all, I just pulled the new HEAD and have a question which I believe was not addressed so far. In my work on the GHC tree I never pulled the dph subrepo because the only thing it adds for me is extra build time (of course I pull it for my validation tree because I have no choice). Now it seems that getting rid of dph is not that simple. If I `rm -df libraries/dph` then it gets restored after `./sync-all pull`. Running `rm -df libraries/dph/*` seems to prevent that but I imagine there will be problems if the dph submodule actually gets modified and I try to pull the latest version. Moreover in both cases `git status` lists the submodule content as modified, which I see as noise. So is there a good way of removing dph from the source tree? The only solution I see is to remove library/dph from the build tree (I use the lndir trick). This means I have DPH in the source tree but not in the symlinked build tree, which is not perfect, but acceptable. Janek Dnia sobota, 28 czerwca 2014, Gabor Greif napisał: On 6/28/14, Herbert Valerio Riedel hvrie...@gmail.com wrote: On 2014-06-28 at 14:19:15 +0200, Gabor Greif wrote: Hmm, I guess this was the reason, when I did that, I got fatal: Needed a single revision Unable to find current revision in submodule path 'libraries/parallel' so the other submodules were not initialized. What might be wrong with 'libraries/parallel' ? Tbh, not sure, but if you know you have nothing important in libraries/parallel, rm -rf libraries/parallel and retry a 'git submodule update --init' This is essentially the suggested course of action according to http://www.gostai.com/downloads/urbi-sdk-2.0/doc/urbi-sdk.htmldir/faq.htm l#x22-10400014.1.4 and other results you may get if you google for that error Great, that helped! Cheers, Gabor ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Overlapable pragmas for individual instances (#9242) (6290eea)
Hi,
Fyi, this changeset seems to have broken ./validate:
utils/haddock/src/Haddock/Interface/Rename.hs:449:11: Warning:
Fields of ‘ClsInstDecl’ not initialised: cid_overlap_mode
In the first argument of ‘return’, namely
‘(ClsInstDecl
{cid_poly_ty = ltype', cid_binds = emptyBag, cid_sigs = [],
cid_tyfam_insts = lATs', cid_datafam_insts = lADTs'})’
In a stmt of a 'do' block:
return
(ClsInstDecl
{cid_poly_ty = ltype', cid_binds = emptyBag, cid_sigs = [],
cid_tyfam_insts = lATs', cid_datafam_insts = lADTs'})
In the expression:
do { ltype' - renameLType ltype;
lATs' - mapM (mapM renameTyFamInstD) lATs;
lADTs' - mapM (mapM renameDataFamInstD) lADTs;
return
(ClsInstDecl
{cid_poly_ty = ltype', cid_binds = emptyBag, cid_sigs = [],
cid_tyfam_insts = lATs', cid_datafam_insts = lADTs'}) }
no location info:
Failing due to -Werror.
make[1]: *** [utils/haddock/dist/build/Haddock/Interface/Rename.dyn_o] Error 1
make: *** [all] Error 2
On 2014-06-30 at 02:37:52 +0200, git-4Dsf34iY/nkouohngz6...@public.gmane.org
wrote:
Repository : ssh://g...@git.haskell.org/ghc
On branch : master
Link :
http://ghc.haskell.org/trac/ghc/changeset/6290eeadf61a40f2eb08d0fd7ef1f3b7f9804178/ghc
---
commit 6290eeadf61a40f2eb08d0fd7ef1f3b7f9804178
Author: Iavor S. Diatchki iavor.diatc...@gmail.com
Date: Sun Jun 29 17:22:16 2014 -0700
Overlapable pragmas for individual instances (#9242)
Programmers may provide a pragma immediately after the `instance` keyword
to control the overlap/incoherence behavior for individual instances.
For example:
instance {-# OVERLAP #-} C a where ...
I chose this notation, rather than the other two outlined in the ticket
for these reasons:
1. Having the pragma after the type looks odd, I think.
2. Having the pragma after there `where` does not work for
stand-alone derived instances
I have implemented 3 pragams:
1. NO_OVERLAP
2. OVERLAP
3. INCOHERENT
These correspond directly to the internal modes currently supported by
GHC. If a pragma is specified, it will be used no matter what flags are
turned on. For example, putting `NO_OVERLAP` on an instance will mark
it as non-overlapping, even if `OVERLAPPIN_INSTANCES` is turned on for the
module.
---
6290eeadf61a40f2eb08d0fd7ef1f3b7f9804178
compiler/hsSyn/Convert.lhs| 2 +-
compiler/hsSyn/HsDecls.lhs| 24
compiler/parser/Lexer.x | 6 +
compiler/parser/Parser.y.pp | 21 +-
compiler/rename/RnSource.lhs | 7 --
compiler/typecheck/TcDeriv.lhs| 46
+--
compiler/typecheck/TcInstDcls.lhs | 5 -
7 files changed, 82 insertions(+), 29 deletions(-)
Diff suppressed because of size. To see it, use:
git diff-tree --root --patch-with-stat --no-color --find-copies-harder
--ignore-space-at-eol --cc 6290eeadf61a40f2eb08d0fd7ef1f3b7f9804178
--
Elegance is not optional -- Richard O'Keefe
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Resolved+new Q: TypeLits question, how to build a Type Application with Symbol index
You'll need to give a lot more info than this before I can help Gabor.
Currently I have only the vaguest idea about what you are trying to accomplish.
Is there a wiki page that describes the design (user's eye view) in detail?
I see you have a branch. If you are stuck, and give me repro instructions, I
can attempt to help.
Simon
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Gabor
| Greif
| Sent: 27 June 2014 17:51
| To: ghc-devs
| Subject: Resolved+new Q: TypeLits question, how to build a Type
| Application with Symbol index
|
| I succeeded to solve all of them :-)
|
| But now I am blocked on on a panic
|
| not in scope during type checking, but it passed the renamer.
|
| I suspect that while deriving Generic some instances are defined in
| some empty TcEnv, which does not contain my definition in context.
|
| Is there a way to inject some type constructor into the TcEnv?
|
| Thanks,
|
| Gabor
|
| On 6/27/14, Gabor Greif ggr...@gmail.com wrote:
| Hello devs,
|
| I have
|
| {{{
| data D (n :: Symbol)
| }}}
|
| in my module, and I want to obtain a type
|
| {{{
| D YAY!
| }}}
|
| programmatically. Where can I find code that performs this (or
| something similar)?
|
| 1) I have to look up |D| in the current TyEnv (what if it is in a
| specific module?),
| 2) I have to build the type index (of kind Symbol), this involves
| FastString, looks non-trivial,
| 3) Apply 1) on 2), this is easy.
|
| Any hints welcome!
|
| Thanks and cheers,
|
| Gabor
|
|
| PS: some morsels I have so far:
|
| for 1)
| compiler/prelude/PrelNames.lhs:gHC_GENERICS= mkBaseModule (fsLit
| GHC.Generics)
|
| ___
| ghc-devs mailing list
| ghc-devs@haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Cleanup of RnExpr, RnEnv and RnSource
Or better still use do-notation like the rest of the compiler. That'd be great
thatnks.
You could de-tabify and remove white space at the same time
SImon
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Jan
| Stolarek
| Sent: 30 June 2014 10:28
| To: ghc-devs@haskell.org
| Subject: Cleanup of RnExpr, RnEnv and RnSource
|
| Dear all,
|
| RnExpr, RnEnv and RnSource (in compiler/renamer) declare locally:
|
| \begin{code}
| -- XXX
| thenM :: Monad a = a b - (b - a c) - a c thenM = (=)
|
| thenM_ :: Monad a = a b - a c - a c
| thenM_ = ()
| \end{code}
|
| and then use these aliases instead of = and . These were introduced
| by Ian in
| 6c7b41cc2b24f533697a62bf1843507ae043fc97 in 2008 and later partially
| cleaned up by Simon in
| f0c99958649b8909612b1b9c9b48aad970dfce05 in 2009. Would there be
| objections if I cleand this up (ie. remove thenM and thenM_ and use =
| and )? Is anyone doing any substantial changes on any of these files
| and suspects that this could introduce merge conflicts for him? I'm at
| the moment changing some things in RnExpr, so doing this will only add
| little extra work for me and I'd like to take this oportunity to have
| cleaner code.
|
| Janek
| ___
| ghc-devs mailing list
| ghc-devs@haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Resolved+new Q: TypeLits question, how to build a Type Application with Symbol index
Thanks, Simon!
Yes I have a branch, and it works! A bunch of things is still missing
(notably record selectors), but I have a proof-of-concept with a gdiff
library hooked up to GHC.Generics, and by appealing to type-level
reasoning I can obtain a difference tree from True to False (which
looks good) by using the reflection (i.e. class Generic) only, no need
for TH or hand-coding. Comparing bigger trees (and then 'patch'ing
them) appears to be SMOP from here.
My current obstacle is that for each
instance Datatype (Dat MyModule Foo) ...
I get an 'orphan instance' warning. I believe that these are harmless,
so is there a way to suppress them? Since I never insert tyvars in the
instance head, there should never be any overlap too.
Cheers,
Gabor
On 6/30/14, Simon Peyton Jones simo...@microsoft.com wrote:
You'll need to give a lot more info than this before I can help Gabor.
Currently I have only the vaguest idea about what you are trying to
accomplish. Is there a wiki page that describes the design (user's eye
view) in detail?
I see you have a branch. If you are stuck, and give me repro instructions,
I can attempt to help.
Simon
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Gabor
| Greif
| Sent: 27 June 2014 17:51
| To: ghc-devs
| Subject: Resolved+new Q: TypeLits question, how to build a Type
| Application with Symbol index
|
| I succeeded to solve all of them :-)
|
| But now I am blocked on on a panic
|
| not in scope during type checking, but it passed the renamer.
|
| I suspect that while deriving Generic some instances are defined in
| some empty TcEnv, which does not contain my definition in context.
|
| Is there a way to inject some type constructor into the TcEnv?
|
| Thanks,
|
| Gabor
|
| On 6/27/14, Gabor Greif ggr...@gmail.com wrote:
| Hello devs,
|
| I have
|
| {{{
| data D (n :: Symbol)
| }}}
|
| in my module, and I want to obtain a type
|
| {{{
| D YAY!
| }}}
|
| programmatically. Where can I find code that performs this (or
| something similar)?
|
| 1) I have to look up |D| in the current TyEnv (what if it is in a
| specific module?),
| 2) I have to build the type index (of kind Symbol), this involves
| FastString, looks non-trivial,
| 3) Apply 1) on 2), this is easy.
|
| Any hints welcome!
|
| Thanks and cheers,
|
| Gabor
|
|
| PS: some morsels I have so far:
|
| for 1)
| compiler/prelude/PrelNames.lhs:gHC_GENERICS= mkBaseModule (fsLit
| GHC.Generics)
|
| ___
| ghc-devs mailing list
| ghc-devs@haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Resolved+new Q: TypeLits question, how to build a Type Application with Symbol index
| Yes I have a branch, and it works! A bunch of things is still missing
| (notably record selectors), but I have a proof-of-concept with a gdiff
| library hooked up to GHC.Generics, and by appealing to type-level
| reasoning I can obtain a difference tree from True to False (which
| looks good) by using the reflection (i.e. class Generic) only, no need
| for TH or hand-coding. Comparing bigger trees (and then 'patch'ing
| them) appears to be SMOP from here.
Do you have a wiki page explaining what it is (the thing that works).
| instance Datatype (Dat MyModule Foo) ...
|
| I get an 'orphan instance' warning. I believe that these are harmless,
The downside of orphan instances is that GHC must visit every .hi file that has
an orphan instance, just in case it contains a relevant instance decl. That
slows down *every* compilation, whether or not it uses the instance.
The best way to get rid of it is to declare something local that is from this
module. Something like
data MyModule_Foo
instance DataType (Dat MyModule_Foo) where ...
Now MyModule_Foo is a data type from the module currently being compiled. That
tells GHC which .hi file to look in, and means the instance isn't orphan.
Simon
| so is there a way to suppress them? Since I never insert tyvars in the
| instance head, there should never be any overlap too.
|
| Cheers,
|
| Gabor
|
| On 6/30/14, Simon Peyton Jones simo...@microsoft.com wrote:
| You'll need to give a lot more info than this before I can help Gabor.
| Currently I have only the vaguest idea about what you are trying to
| accomplish. Is there a wiki page that describes the design (user's eye
| view) in detail?
|
| I see you have a branch. If you are stuck, and give me repro
| instructions,
| I can attempt to help.
|
| Simon
|
| | -Original Message-
| | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
| Gabor
| | Greif
| | Sent: 27 June 2014 17:51
| | To: ghc-devs
| | Subject: Resolved+new Q: TypeLits question, how to build a Type
| | Application with Symbol index
| |
| | I succeeded to solve all of them :-)
| |
| | But now I am blocked on on a panic
| |
| | not in scope during type checking, but it passed the renamer.
| |
| | I suspect that while deriving Generic some instances are defined in
| | some empty TcEnv, which does not contain my definition in context.
| |
| | Is there a way to inject some type constructor into the TcEnv?
| |
| | Thanks,
| |
| | Gabor
| |
| | On 6/27/14, Gabor Greif ggr...@gmail.com wrote:
| | Hello devs,
| |
| | I have
| |
| | {{{
| | data D (n :: Symbol)
| | }}}
| |
| | in my module, and I want to obtain a type
| |
| | {{{
| | D YAY!
| | }}}
| |
| | programmatically. Where can I find code that performs this (or
| | something similar)?
| |
| | 1) I have to look up |D| in the current TyEnv (what if it is in a
| | specific module?),
| | 2) I have to build the type index (of kind Symbol), this involves
| | FastString, looks non-trivial,
| | 3) Apply 1) on 2), this is easy.
| |
| | Any hints welcome!
| |
| | Thanks and cheers,
| |
| | Gabor
| |
| |
| | PS: some morsels I have so far:
| |
| | for 1)
| | compiler/prelude/PrelNames.lhs:gHC_GENERICS= mkBaseModule
| (fsLit
| | GHC.Generics)
| |
| | ___
| | ghc-devs mailing list
| | ghc-devs@haskell.org
| | http://www.haskell.org/mailman/listinfo/ghc-devs
|
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Help needed: parsing pattern synonym contexts
Gergo
It's just a question of chasing down the reduce/reduce errors. You can give a
flag to Happy that makes it dump a file with all the info about it parsing
states, and where the reduce/reduce errors come from, and you can go from there.
If you don't know how to interpret that file, just commit your best try to your
wip/ branch and maybe some other ghc devs will help you. Maybe me. But
without being able to reproduce it, it's hard to help.
Simon
| -Original Message-
| From: Dr. ERDI Gergo [mailto:ge...@erdi.hu]
| Sent: 25 June 2014 14:20
| To: Simon Peyton Jones
| Cc: GHC Devs
| Subject: RE: Help needed: parsing pattern synonym contexts
|
| On Tue, 24 Jun 2014, Simon Peyton Jones wrote:
|
| In the latter case, what happened to the shift/reduce and
| reduce/reduce errors reported by Happy? Esp the latter. If you are
| getting more you need to track them down.
|
| I think I've figured out what might be causing the problem.
|
| First, a couple figures. With these rules:
|
| pattern_synonym_decl
| : 'pattern' con vars0 patsyn_token pat
| | 'pattern' varid conop varid patsyn_token pat
|
| pattern_synonym_sig
| : 'pattern' patsyn_stuff '::' ctype
|
| patsyn_stuff
| : constr_stuff
|
| I'm getting 112 new reduce/reduce conflicts.
|
| If I add the context like you recommended:
|
| pattern_synonym_sig
| : 'pattern' patsyn_context patsyn_stuff '::' ctype
|
| patsyn_context :: { LHsContext RdrName }
| : forall
| | forall context '='
|
|
| then I get 54 new shift/reduce conflicts and no (new) reduce/reduce
| conflicts.
|
| My feeling is the problem is that patterns don't need any special
| parentheses around type annotations, which means the following is a
| legal pattern synonym definition:
|
| pattern Single x = [x] :: [Int]
|
| and I think that the difference (the '=' or '-') is too 'deep' between
| this and something like
|
| pattern Single a :: [a]
|
| Unfortunately, I still have no idea how to solve this problem...
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Proposal: require Haddock comment for every new top-level function and type in GHC source code
Thanks, Johan, for starting this discussion. I mostly agree with the proposal. However, one (at times, serious) drawback to using Haddock is that it means that editing comments can cause parse failures. The way the GHC build works, these failures may not be detected until the end of a hacking session (if I'm using, say, `make 2`, as I tend to do) and then can be hard to diagnose. I've actually been bitten by this when working on GHC. So, I have to ask: why use Haddock? Do folks read the Haddock docs for GHC? (I don't, but perhaps that's because the docs aren't so good right now.) Would it be acceptable to change this proposal not to require Haddock docs? Even if we decide to keep this proposal about Haddock docs specifically, I would strongly request that correct rendering of the Haddock docs not be scrutinized. At the end of a hacking session (which is hard enough to find time for, as is), I don't want to be expected to look through the generated HTML to make sure that my typewriter font and italics are rendering correctly. This is something of a corollary to Simon's comment about wanting to refer to Notes from Haddock comments -- I would want the Haddock output to be quite secondary to the proper documentation in the source code. (Note that this demotion of the role of Haddock is certainly not my practice in released libraries! But, Haddock is much less useful in an application like GHC than in a library.) All that said, I do agree with the intent of this proposal and am happy to take on my part of the burden of documenting new (and perhaps some old) functions as I work. I have been very guilty of the broken window effect in not documenting new code. Thanks, Richard On Jun 27, 2014, at 5:51 AM, Johan Tibell johan.tib...@gmail.com wrote: Hi! I found myself exploring new parts of the GHC code base the last few weeks (exciting!), which again reminded me of my biggest frustration when working on GHC: the lack of per-function/type (Haddock) comments. GHC code is sometimes commented with notes, which are great but tend to (1) mostly cover the exceptional cases and (2) talk about the implementation of a function, not how a caller might use it or why. Lack of documentation, in GHC and other software projects, usually has (at least) two causes: Programmers comment code they think is complex enough to warrant a comment. The problem is that the author is usually a poor judge of what's complex enough, because he/she is too familiar with the code and tends to under-document code when following this principle. Documenting is boring and tends to have little benefit the person writing to documentation. Given lack of incentives we tend to document less than we ought to. I've only seen one successful way to combat the lack of documentation that stems from the above: have the project's style guide mandate that top-level functions and types (or at least those that are exported) have documentation. This works well at Google. Anecdote: we have one code base inside Google that was until recently exempt from this rule and documentation is almost completely absent in that code base, even though hundreds of engineers work on and need to understand it every day. This breeds institutional knowledge problems i.e. if the author of a core piece of code leaves, lots of knowledge is lost. Proposal: I propose that we require that new top-level functions and types have Haddock comments, even if they start out as a single, humble sentence. I've found that putting even that one sentence (1) helps new users and (2) establishes a place for improvements to be made. There's a strong broken window effect to lack of comments, in that lack of comments breeds more lack of comments as developers follow established practices. We should add this requirement to the style guide. Having it as a written down policy tends to prevent having to re-hash the whole argument about documentation over and over again. This has also helped us a lot at Google, because programmers can spend endless amount of time arguing about comments, placement of curly braces, etc. and having a written policy helps cut down on that. To give an idea of how to write good comments, here are two examples of undocumented code I ran into in GHC and how better comments would have helped. First example In compiler/nativeGen/X86/Instr.hs there's a (local) function called mkRUR, which is a helper function use when computing instruction register usage. The first question that I asked upon seeing uses of that function was what does RUR stand for? Given the context the function is in, I guessed it stands for read-update-read, because R is used to mean read in the enclosing function and updating is related to reading so that must be what U stands for. It turns out that it stands for RegUsageReadonly. Here's a comment that would have captured, in a single sentence, what
Re: Proposal: require Haddock comment for every new top-level function and type in GHC source code
On Fri, Jun 27, 2014 at 11:11 AM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: On 06/27/2014 03:26 PM, David Fox wrote: I would counter propose a place on hackage for people to type in or modify the documentation for functions, designed in such a way that the documentation would easily find its way back into the project's source code (with developer approval.) This way the documentation can be generated by people who only recently came to understand the function, so the questions a newcomer has are fresh in their mind. Are you asking for a wiki-like thing for documentation? There were a few times where this has been proposed such as https://github.com/haskell/haddock/issues/72 but in general it turns out that there's not enough interest for anyone to sit down and implement it and make sure it all works properly. Patches should be going straight to upstream rather than lingering on Hackage until someone notices them (even with automated tools, it's a pain). I doubt many people would use it for anything but typos because if you have enough knowledge about a function to document it, you're likely to already be involved with the project in some way and have means to report it properly. My thought was that it would end up in the library's source code, not that it would reside in a wiki. The question is whether anyone has the motivation to write a sufficiently smooth mechanism to achieve this. If I was editing a package that I normally upload to hackage and I could look at a nice presentation of alternative documentation strings people have suggested for the different functions in my library, I would be happy to cut and paste them into the source code. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Proposal: require Haddock comment for every new top-level function and type in GHC source code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey list, I am strongly in favour of the proposal. As a pedestrian-level GHC contributor, the *vast* majority of my time is spent trying to figure out what certain things do, when the answer could be found in a one- or two-line comment above a definition. As for Richard's remark, So, I have to ask: why use Haddock? Do folks read the Haddock docs for GHC? (I don't, but perhaps that's because the docs aren't so good right now.) I find Haddock very useful for one major reason: it allows me an HTML overview over all exported definitions (in the index), which is a big plus when you're searching for things. Greetings, David/quchen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTsYVUAAoJELrQsaT5WQUsKawIAIMHt9Ha4qTWtJO6qwOjN5RD JOx1MnuPlDLosbyE9+BlkEV1tRnnG/snyxwFTgmtFSO9fAV2FPZEbtzZ2AZd4xbb VgORhTAeL1n1aBitGNaAzT1T60tS2JNict2S0pUWa0Qt3nYWwoRw1B+OOaZRuuaR cHkOFKMbzU5knmeD/RyDIE+oRxZvjAKdAaaQ0vJ70ovNUptjtfDeX6Nxto65qFis sKsWjsL++TgeOscejw7DNLeCei/cwrzjOSNOB6xFGAxPHUHZFvSkbuVAMNWIgbic 55tbDIog/l9P/N8RoUQh4PLjh3TG3xT3vsM5iiTKl3UZ7eTMpzmzAKhvikoHGOU= =w6S7 -END PGP SIGNATURE- ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Two days old build breakage on i386.
I fixed the x86 issue and re-commited my work as 4ee4ab01c1d97845aecb7707ad2f9a80933e7a49. On Fri, Jun 27, 2014 at 1:27 PM, Simon Marlow marlo...@gmail.com wrote: On 27/06/2014 12:23, Johan Tibell wrote: On Fri, Jun 27, 2014 at 1:14 PM, Simon Marlow marlo...@gmail.com wrote: The problem is that this instruction requires three separate registers, but cmpxchgl already reads and writes %eax leaving only two free registers (%ecx and %edx). You'll need to arrange to not use the complicated addressing modes with cmpxchg on i386, and keep the number of free regs required = 2. Where's the best place to arrange for that? If I switch from using getAmode to computing the address into a temp register in StgCmmPrim will that ensure that the address is simple, or could some optimization replace my temp register computation with a complex address again? There aren't any optimisations that happen on the instructions after codegen, and if there were, they would have to respect the same rule. So using a register is the right thing, yes. Cheers, Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Proposal: require Haddock comment for every new top-level function and type in GHC source code
Richard, Not requiring contributors to check that the Haddock render well is OK. As long as the comments are there someone with free time on their hands can always tidy up the rendering. I'm looking forward to the day I can browse the GHC Haddocks and make sense of them. I tried in the past but the generated docs aren't accessible enough without any actual comments. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Proposal: require Haddock comment for every new top-level function and type in GHC source code
Left hold off one more week to give more contributors a change to voice their thoughts. If no one protests I will announce the new policy next Monday. Sounds good? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: the case of the missing Cabal doc
On Sun, Jun 29, 2014 at 11:04:20PM -0700, Mark Lentczner wrote: In times of yore (prior to 7.8), when GHC build a bindist, it included the generated HTML manual for Cabal. As of 7.8, this seems to have gone missing-in-action. Anyone know where it went? It was converted to markdown, and GHC's build system doesn't know how to build markdown docs. It's in libraries/Cabal/Cabal/doc/. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Overlapable pragmas for individual instances (#9242) (6290eea)
Sorry about this. It would appear that I am not allowed to push to the
`haddock` repo, so I've attached a patch, for someone with permissions to
apply.
Also, could I be given permissions to modify haddock, since GHC and haddock
are closely related changes like the one I made often need to be propagated
in both.
-Iavor
On Mon, Jun 30, 2014 at 1:23 AM, Herbert Valerio Riedel hvrie...@gmail.com
wrote:
Hi,
Fyi, this changeset seems to have broken ./validate:
utils/haddock/src/Haddock/Interface/Rename.hs:449:11: Warning:
Fields of ‘ClsInstDecl’ not initialised: cid_overlap_mode
In the first argument of ‘return’, namely
‘(ClsInstDecl
{cid_poly_ty = ltype', cid_binds = emptyBag, cid_sigs = [],
cid_tyfam_insts = lATs', cid_datafam_insts = lADTs'})’
In a stmt of a 'do' block:
return
(ClsInstDecl
{cid_poly_ty = ltype', cid_binds = emptyBag, cid_sigs = [],
cid_tyfam_insts = lATs', cid_datafam_insts = lADTs'})
In the expression:
do { ltype' - renameLType ltype;
lATs' - mapM (mapM renameTyFamInstD) lATs;
lADTs' - mapM (mapM renameDataFamInstD) lADTs;
return
(ClsInstDecl
{cid_poly_ty = ltype', cid_binds = emptyBag, cid_sigs =
[],
cid_tyfam_insts = lATs', cid_datafam_insts = lADTs'}) }
no location info:
Failing due to -Werror.
make[1]: *** [utils/haddock/dist/build/Haddock/Interface/Rename.dyn_o]
Error 1
make: *** [all] Error 2
On 2014-06-30 at 02:37:52 +0200, git-4Dsf34iY/
nkouohngz6...@public.gmane.org wrote:
Repository : ssh://g...@git.haskell.org/ghc
On branch : master
Link :
http://ghc.haskell.org/trac/ghc/changeset/6290eeadf61a40f2eb08d0fd7ef1f3b7f9804178/ghc
---
commit 6290eeadf61a40f2eb08d0fd7ef1f3b7f9804178
Author: Iavor S. Diatchki iavor.diatc...@gmail.com
Date: Sun Jun 29 17:22:16 2014 -0700
Overlapable pragmas for individual instances (#9242)
Programmers may provide a pragma immediately after the `instance`
keyword
to control the overlap/incoherence behavior for individual instances.
For example:
instance {-# OVERLAP #-} C a where ...
I chose this notation, rather than the other two outlined in the
ticket
for these reasons:
1. Having the pragma after the type looks odd, I think.
2. Having the pragma after there `where` does not work for
stand-alone derived instances
I have implemented 3 pragams:
1. NO_OVERLAP
2. OVERLAP
3. INCOHERENT
These correspond directly to the internal modes currently supported
by
GHC. If a pragma is specified, it will be used no matter what flags
are
turned on. For example, putting `NO_OVERLAP` on an instance will
mark
it as non-overlapping, even if `OVERLAPPIN_INSTANCES` is turned on
for the
module.
---
6290eeadf61a40f2eb08d0fd7ef1f3b7f9804178
compiler/hsSyn/Convert.lhs| 2 +-
compiler/hsSyn/HsDecls.lhs| 24
compiler/parser/Lexer.x | 6 +
compiler/parser/Parser.y.pp | 21 +-
compiler/rename/RnSource.lhs | 7 --
compiler/typecheck/TcDeriv.lhs| 46
+--
compiler/typecheck/TcInstDcls.lhs | 5 -
7 files changed, 82 insertions(+), 29 deletions(-)
Diff suppressed because of size. To see it, use:
git diff-tree --root --patch-with-stat --no-color
--find-copies-harder --ignore-space-at-eol --cc
6290eeadf61a40f2eb08d0fd7ef1f3b7f9804178
--
Elegance is not optional -- Richard O'Keefe
From 1dbcb1e9e26e6b742557bf3b0e5449979af2298e Mon Sep 17 00:00:00 2001
From: Iavor S. Diatchki diatc...@galois.com
Date: Mon, 30 Jun 2014 13:19:09 -0700
Subject: [PATCH] Propagate overloading-mode for instance declarations in
haddock (#9242)
---
src/Haddock/Interface/Rename.hs | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/Haddock/Interface/Rename.hs b/src/Haddock/Interface/Rename.hs
index 748e021..2eb2cc0 100644
--- a/src/Haddock/Interface/Rename.hs
+++ b/src/Haddock/Interface/Rename.hs
@@ -442,11 +442,15 @@ renameInstD (DataFamInstD { dfid_inst = d }) = do
return (DataFamInstD { dfid_inst = d' })
renameClsInstD :: ClsInstDecl Name - RnM (ClsInstDecl DocName)
-renameClsInstD (ClsInstDecl { cid_poly_ty =ltype, cid_tyfam_insts = lATs, cid_datafam_insts = lADTs }) = do
+renameClsInstD (ClsInstDecl { cid_overlap_mode = omode
+, cid_poly_ty =ltype, cid_tyfam_insts = lATs
+, cid_datafam_insts = lADTs }) = do
ltype' - renameLType ltype
lATs' - mapM (mapM renameTyFamInstD) lATs
lADTs' - mapM
Re: Proposal: require Haddock comment for every new top-level function and type in GHC source code
I think that's a good idea, as long as we do enforce it as social policy rather than a script. In other words, we should encourage folks to add comments documenting functions, but not necessarily require them *everywhere*, and leave it I also share Richard's concern about using Haddock notation, and the possibility of introducing build-failures due to typos in the documentation. -Iavor On Mon, Jun 30, 2014 at 1:18 PM, Johan Tibell johan.tib...@gmail.com wrote: Left hold off one more week to give more contributors a change to voice their thoughts. If no one protests I will announce the new policy next Monday. Sounds good? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Proposal: require Haddock comment for every new top-level function and type in GHC source code
David Luposchainsky dluposchain...@googlemail.com writes: Hey list, I am strongly in favour of the proposal. As a pedestrian-level GHC contributor, the *vast* majority of my time is spent trying to figure out what certain things do, when the answer could be found in a one- or two-line comment above a definition. I'd like to second this. As an occassional contributor, I find myself wading through a lot of code to deduce functions' purpose. While I'm often pleasantly surprised by the quality of the notes scattered about the code, per-definition Haddocks would fill in the many remaining gaps and provide a nice overview of each module. I agree that enforcing the quality of the rendered Haddocks is unnecessary. Once the language has been written there are many contributors (such as myself) who can further clean up the formatting. Cheers, - Ben pgpnP8AxgwTf_.pgp Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Proposal: require Haddock comment for every new top-level function and type in GHC source code
Given the examples provided with this proposal it looks like this change is targeted mostly at compiler hackers, and not at library/package developers. For the latter community it would be nice to establish a policy for libraries and packages that encourages (nudges) developers to include comments and examples, something more useful than type signatures or pointers to the literature on type theory. For example, the R stats system encourages package developers to include examples, and these examples are run as part of the package checking process, thus encouraging developers to keep the examples up-to-date. This kind of change might help Haskell move beyond its current role as a research and teaching tool, and an incubator for new programming ideas that are eventually implemented and popularized in other programming languages... Cheers, Dominick On Fri, Jun 27, 2014 at 6:17 AM, Simon Peyton Jones simo...@microsoft.com wrote: I'd be OK with this, (it's a bit like requiring signatures on all top level functions) but I don't know how we'd enforce it. Do you think the requirement should be for all top-level functions or just exported ones? I agree that Notes have a different purpose. But it should be OK style to refer to a Note from a top-level function comment, even though Haddock won't be able to make much sense of it. Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Johan Tibell Sent: 27 June 2014 10:51 To: ghc-devs@haskell.org Subject: Proposal: require Haddock comment for every new top-level function and type in GHC source code Hi! I found myself exploring new parts of the GHC code base the last few weeks (exciting!), which again reminded me of my biggest frustration when working on GHC: the lack of per-function/type (Haddock) comments. GHC code is sometimes commented with notes, which are great but tend to (1) mostly cover the exceptional cases and (2) talk about the implementation of a function, not how a caller might use it or why. Lack of documentation, in GHC and other software projects, usually has (at least) two causes: Programmers comment code they think is complex enough to warrant a comment. The problem is that the author is usually a poor judge of what's complex enough, because he/she is too familiar with the code and tends to under-document code when following this principle. Documenting is boring and tends to have little benefit the person writing to documentation. Given lack of incentives we tend to document less than we ought to. I've only seen one successful way to combat the lack of documentation that stems from the above: have the project's style guide mandate that top-level functions and types (or at least those that are exported) have documentation. This works well at Google. Anecdote: we have one code base inside Google that was until recently exempt from this rule and documentation is almost completely absent in that code base, even though hundreds of engineers work on and need to understand it every day. This breeds institutional knowledge problems i.e. if the author of a core piece of code leaves, lots of knowledge is lost. Proposal: I propose that we require that new top-level functions and types have Haddock comments, even if they start out as a single, humble sentence. I've found that putting even that one sentence (1) helps new users and (2) establishes a place for improvements to be made. There's a strong broken window effect to lack of comments, in that lack of comments breeds more lack of comments as developers follow established practices. We should add this requirement to the style guide. Having it as a written down policy tends to prevent having to re-hash the whole argument about documentation over and over again. This has also helped us a lot at Google, because programmers can spend endless amount of time arguing about comments, placement of curly braces, etc. and having a written policy helps cut down on that. To give an idea of how to write good comments, here are two examples of undocumented code I ran into in GHC and how better comments would have helped. First example In compiler/nativeGen/X86/Instr.hs there's a (local) function called mkRUR, which is a helper function use when computing instruction register usage. The first question that I asked upon seeing uses of that function was what does RUR stand for? Given the context the function is in, I guessed it stands for read-update-read, because R is used to mean read in the enclosing function and updating is related to reading so that must be what U stands for. It turns out that it stands for RegUsageReadonly. Here's a comment that would have captured, in a single sentence, what this function is for: -- | Create register usage info for instruction that only -- reads registers. mkRUR src = src' `seq` RU src' [] where src' = filter (interesting
Re: Proposal: require Haddock comment for every new top-level function and type in GHC source code
On Mon, Jun 30, 2014 at 11:22 PM, Dominick Samperi djsamp...@gmail.com wrote: Given the examples provided with this proposal it looks like this change is targeted mostly at compiler hackers, and not at library/package developers. Yes, this discussion is only about documenting the GHC modules. -- Johan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
