Re: Avoiding the hazards of orphan instances without dependency problems
In the past I've spent some time thinking about the orphan instances problem. I
concluded that the
Right Thing to do is to turn instances into first-class citizens and allow them
to be explicitly
imported and exported. I think devising pragmas is a workaround, not a solution.
Janek
Dnia poniedziałek, 20 października 2014, David Feuer napisał:
OK, so first off, I don't have anything against your pragma; I just think
that something akin to mine would be good to have too. Mine was not
intended to require both class and type to be in scope; if one of them is
not, then it should be given its full name:
{-# InstanceIn Module Foo.Class Type #-}
{-# InstanceIn Module Class Bar.Type #-}
As Edward Kmett explained to me, there are reasons for module authors not
to want to include instances for lens stuff—in particular, they apparently
tend to use a lot of non-portable code, but even aside from that, they may
just not want to have to deal with maintaining that particular code. This
leads to a slew of instances being dumped into lens modules, forcing the
lens package to depend on a bunch of others. What I'm suggesting is that
sticking {-# InstanceIn Data.Text.Lens Strict Data.Text.Lazy.Text
Data.Text.Text #-} into Control.Lens.Iso (and so on) would allow
Data.Text.Lens to be broken off into a separate package, removing the text
dependency from lens.
Note also: I described a way to (try to) support overlapping instances for
mine, but I think it would be valuable to offer mine even without that
feature (dropping the context stuff), if it's just too complex.
On Sun, Oct 19, 2014 at 9:43 PM, John Lato jwl...@gmail.com wrote:
I fail to see how this doesn't help lens, unless we're assuming no buy-in
from class declarations. Also, your approach would require c*n pragmas
to be declared, whereas mine only requires c. Also your method seems to
require having both the class and type in scope, in which case one could
simply declare the instance in that module anyway.
On Mon, Oct 20, 2014 at 9:29 AM, David Feuer david.fe...@gmail.com
wrote:
I don't think your approach is flexible enough to accomplish the
purpose. For example, it does almost nothing to help lens. Even my
approach should, arguably, be extended transitively, allowing the named
module to delegate that authority, but such an extension could easily be
put off till later.
On Oct 19, 2014 7:17 PM, John Lato jwl...@gmail.com wrote:
Thinking about this, I came to a slightly different scheme. What if we
instead add a pragma:
{-# OrphanModule ClassName ModuleName #-}
and furthermore require that, if OrphanModule is specified, all
instances can *only* appear in the module where the class is defined,
the involved types are defined, or the given OrphanModule? We would
also need to add support for the compiler to understand that multiple
modules may appear under the same name, which might be a bit tricky to
implement, but I think it's feasible (perhaps in a restricted manner).
I think I'd prefer this when implementing orphan instances, and
probably when writing the pragmas as well.
On Mon, Oct 20, 2014 at 1:02 AM, David Feuer david.fe...@gmail.com
wrote:
Orphan instances are bad. The standard approach to avoiding the orphan
hazard is to always put an instance declaration in the module that
declares the type or the one that declares the class. Unfortunately,
this forces packages like lens to have an ungodly number of
dependencies. Yesterday, I had a simple germ of an idea for solving
this (fairly narrow) problem, at least in some cases: allow a
programmer to declare where an instance declaration must be. I have no
sense of sane syntax, but the rough idea is:
{-# InstanceIn NamedModule [Context =] C1 T1 [T2 ...] #-}
This pragma would appear in a module declaring a class or type. The
named module would not have to be available, either now or ever, but
attempting to declare such an instance in any module *other* than the
named one would be an error by default, with a flag
-XAllowForbiddenInstancesAndInviteNasalDemons to turn it off. The
optional context allows multiple such pragmas to appear in the
type/class-declaring modules, to allow overlapping instances (all of
them declared in advance).
___
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: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions
For the review process I updated the phabricator summary to capture the current implementation, I will move it on to the wiki too. The ExtraCommas have been removed as unworkable, they are an abandoned point in the design space. The lessons learned are being transferred to Alexander Berntsen for his record syntax extension proposal. I did consider bringing comments in directly, as being a natural part of things, but did not want to confuse the issue too much in one go. It should be possible to capture them in a similar process, and it will definitely help with round tripping. At the moment tooling has to access them via `getRichTokenStream` and then work them in to the correct place. In terms of haddock usage, I would have to discuss with them what they do/need, to find out if this will serve as a replacement. On Mon, Oct 20, 2014 at 9:55 AM, GHC ghc-devs@haskell.org wrote: #9628: Add Annotations to the AST to simplify source to source conversions -+- Reporter: alanz |Owner: alanz Type: feature | Status: new request|Milestone: Priority: normal | Version: 7.9 Component: Compiler| Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D297| -+- Comment (by simonpj): Well done for making progress. Some thoughts * If the patch is ready for review, is [wiki:GhcAstAnnotations] also fully up to date? Could you move any discussion of alternatives to the end, under Other possible design alternatives so that what remains is actually a description of the feature you propose, and a sketch of its implementation? I'm unsure about which bits of the wiki page are rejected ideas and which are the ones you adopted. * Floating around is also `ExtraCommas`. I think the two are somewhat orthogonal, right? * Does your design say where comments are? That is, can you really round-trip source code? In particular, an excellent criterion could be: can you do Haddock this way? Currently Haddock has a lot of Haddock-specific fields in HsSyn. Could they all be replaced with annotations in your style? If not, what would take to make that possible? It would be highly cool; after all, Haddock may be privileged, but the more we can make it possible for others to do Haddock-like things without changing GHC itself, the better. * You outlined a number of customers in an earlier post. Would it be worth adding them to the wiki page? Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9628#comment:30 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Help understanding Specialise.lhs
David, I’m unclear what you are trying to achieve with #9701. I urge you to write a clear specification that we all agree about before burning cycles hacking code. There are a lot of comments at the top of Specialise.lhs. But it is, I’m afraid, a tricky pass. I could skype. Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of David Feuer Sent: 20 October 2014 02:39 To: ghc-devs Subject: Help understanding Specialise.lhs I'm trying to figure out how to address #9701, but I'm having an awfully hard time figuring out what's going on in Specialise.lhs. I think I get the vague general idea of what it's supposed to do, based on the notes, but the actual code is a mystery to me. Is there anyone who might be able to help me get enough of a sense of it to let me do what I need? Many thanks in advance. David Feuer ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Help understanding Specialise.lhs
On Oct 20, 2014 5:05 AM, Simon Peyton Jones simo...@microsoft.com wrote: I’m unclear what you are trying to achieve with #9701. I urge you to write a clear specification that we all agree about before burning cycles hacking code. What I'm trying to achieve is to make specialization work in a situation where it currently does not. It appears that when the type checker determines that a GADT carries a certain dictionary, the specializer happily uses it *even once the concrete type is completely known*. What we would want to do in that case is to replace the use of the GADT-carried dictionary with a use of the known dictionary for that type. There are a lot of comments at the top of Specialise.lhs. But it is, I’m afraid, a tricky pass. I could skype. I would appreciate that. What day/time are you available? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Help understanding Specialise.lhs
To be super-clear about at least one aspect: I don't want Tidy Core to ever
contain something that looks like this:
GADTTest.potato
:: GHC.Types.Int - GADTTest.Silly GHC.Types.Int - GHC.Types.Int
GADTTest.potato =
\ (x_asZ :: GHC.Types.Int)
(ds_dPR :: GADTTest.Silly GHC.Types.Int) -
case ds_dPR of _ { GADTTest.Silly $dNum_aLV ds1_dPS -
GHC.Num.+ @ GHC.Types.Int $dNum_aLV x_asZ x_asZ
}
Here we see GHC.Num.+ applied to GHC.Types.Int and $dNum_aLV. We therefore
know that $dNum_aLV must be GHC.Num.$fNumInt, so GHC.Num.+ can eat these
arguments and produce GHC.Num.$fNumInt_$c+. But for some reason, GHC fails
to recognize and exploit this fact! I would like help understanding why
that is, and what I can do to fix it.
On Mon, Oct 20, 2014 at 7:53 AM, David Feuer david.fe...@gmail.com wrote:
On Oct 20, 2014 5:05 AM, Simon Peyton Jones simo...@microsoft.com
wrote:
I’m unclear what you are trying to achieve with #9701. I urge you to
write a clear specification that we all agree about before burning cycles
hacking code.
What I'm trying to achieve is to make specialization work in a situation
where it currently does not. It appears that when the type checker
determines that a GADT carries a certain dictionary, the specializer
happily uses it *even once the concrete type is completely known*. What we
would want to do in that case is to replace the use of the GADT-carried
dictionary with a use of the known dictionary for that type.
There are a lot of comments at the top of Specialise.lhs. But it is,
I’m afraid, a tricky pass. I could skype.
I would appreciate that. What day/time are you available?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Making GHCi awesomer?
Christopher You are doing very cool things. Thank you. What I’m puzzled about is this: the GHC API *is* a programmatic interface to GHC. Why not just use it? I can think of some reasons: · It’s not very clear just what’s in the GHC API and what isn’t, since you have access to all of GHC’s internals if you use –package ghc. And the API isn’t very well designed. (Answer: could you help make it better?) · You want some functionality that is currently in GHCi, rather than in the ‘ghc’ package. (Answer: maybe we should move that functionality into the ‘ghc’ package and make it part of the GHC API?) · You have to be writing in Haskell to use the GHC API, whereas you want a separate process you connect to via a socket. (Answer: Excellent: write a server wrapper around the GHC API that offers a JSON interface, or whatever the right vocabulary is. Sounds as if you have more or less done this.) · Moreover, the API changes pretty regularly, and you want multi-compiler support. (No answer: I don’t know how to simultaneously give access to new stuff without risking breaking old stuff.) My meta-point is this: GHC is wide open to people like you building a consensus about how GHC’s basic functionality should be wrapped up and exposed to clients. (Luite is another person who has led in this space, via GHCJS.) So please do go ahead and lay out the way it *should* be done, think about migration paths, build a consensus etc. Much better that than do fragile screen-scraping on GHCi’s textual output. Thanks for what you are doing here. Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Christopher Done Sent: 18 October 2014 16:49 To: ghc-devs@haskell.org Subject: Making GHCi awesomer? Good evening, So I’ve been working on Haskell user-facing tooling in general for some years. By that I mean the level of Emacs talking with Haskell tools. I wrote the interactive-haskell-mode (most functionality exists in this filehttps://github.com/haskell/haskell-mode/blob/master/haskell-process.el#L1). which launches a GHCi process in a pipe and tries very earnestly to handle input/output with the process reasonably. For Emacs fanciers: Written in Elisp, there’s a nice command queue that you put commands onto, they will all be run on a FIFO one-by-one order, and eventually you’ll get a result back. Initially it was just me using it, but with the help of Herbert Riedel it’s now a mode on equal footing with the venerable inferior-haskell-mode all ye Emacs users know and love. It’s part of haskell-mode and can be enabled by enabling the interactive-haskell-mode minor mode. For years I’ve been using GHCi as a base and it’s been very reliable for almost every project I’ve done (the only exceptions are things like SDL and OpenGL, which are well known to be difficult to load in GHCi, at least on Linux). I think we’ve built up a good set of functionalityhttps://github.com/haskell/haskell-mode/wiki/Haskell-Interactive-Mode purely based on asking GHCi things and getting it to do things. I literally use GHCi for everything. For type-checking, type info, I even send “:!cabal build” to it. Everything goes through it. I love my GHCi. Now, I’m sort of at the end of the line of where I can take GHCi. Here are the problems as I see them today: 1. There is no programmatic means of communicating with the process. I can’t send a command and get a result cleanly, I have to regex match on the prompt, and that is only so reliable. At the moment we solve this by using \4 (aka ‘END OF TRANSMISSION’). Also messages (warnings, errors, etc.) need to be parsed which is also icky, especially in the REPL when e.g. a defaulted Integer warning will mix with the output. Don’t get me started on handling multi-line prompts! Hehe. 2. GHCi, as a REPL, does not distinguish between stdout, stderr and the result of your evaluation. This can be problematic for making a smooth REPL UI, your results can often (with threading) be interspersed in unkind ways. I cannot mitigate this with any kind of GHCi trickery. 3. It forgets information when you reload. (I know this is intentional.) 4. Not enough information is exposed to the user. (Is there ever? ;) 5. There is a time-to-market overhead of contributing to GHCi — if I want a cool feature, I can write it on a locally compiled version of GHC. But for the work projects I have, I’m restricted to given GHC versions, as are other people. They have to wait to get the good features. 6. This is just a personal point — I’ve like to talk to GHCi over a socket, so that I can run it on a remote machine. Those familiar with Common Lisp will be reminded of SLIME and Swank. Examples for point 4 are: · Type of sub-expressions. · Go to definition of thing at point (includes local scope). · Local-scope completion. · A hoogle-like query (as seen in Idris recently). · Documentation
GHC Weekly News - 2014/10/20
Hi *, Here's a weekly news update covering the past several weeks, covering some of our discussions we've had - please let me know if I missed out on something important so I can update the post. https://ghc.haskell.org/trac/ghc/blog/edit/weekly20141020 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC Weekly News - 2014/10/20
On Mon, Oct 20, 2014 at 10:22 AM, Austin Seipp aus...@well-typed.com wrote: https://ghc.haskell.org/trac/ghc/blog/edit/weekly20141020 You might want to provide the ordinary mortals link instead of the edit link. :) -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC Weekly News - 2014/10/20
All you have to do is edit out /edit/ in the URL,.. On Mon, Oct 20, 2014 at 4:24 PM, Brandon Allbery allber...@gmail.com wrote: On Mon, Oct 20, 2014 at 10:22 AM, Austin Seipp aus...@well-typed.com wrote: https://ghc.haskell.org/trac/ghc/blog/edit/weekly20141020 You might want to provide the ordinary mortals link instead of the edit link. :) -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net ___ 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: GHC Weekly News - 2014/10/20
Good catch. That's what I get for copy-pasting without double checking :) https://ghc.haskell.org/trac/ghc/blog/weekly20141020 On Mon, Oct 20, 2014 at 9:24 AM, Brandon Allbery allber...@gmail.com wrote: On Mon, Oct 20, 2014 at 10:22 AM, Austin Seipp aus...@well-typed.com wrote: https://ghc.haskell.org/trac/ghc/blog/edit/weekly20141020 You might want to provide the ordinary mortals link instead of the edit link. :) -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC Weekly News - 2014/10/20
On Mon, Oct 20, 2014 at 10:26 AM, Alan Kim Zimmerman alan.z...@gmail.com wrote: All you have to do is edit out /edit/ in the URL Yes, I did that. It's still better to not require people to do that -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Warning on tabs by default (#9230) for GHC 7.10
I guess template-haskell should be also easy to detab immediately. It is the only thing in ./libraries that is not a git submodule. Best, Mateusz Lenik On Sat, Oct 18, 2014 at 05:48:26PM -0500, Austin Seipp wrote: The boot libraries have not been detabbed, and that's something we can't immediately fix. However, the warnings being on by default means people should feel the burn to fix it quickly, I hope, and we can just update all of our submodules accordingly. I did notice however in the diff that I missed the fact `hsc2hs` has also not been detabbed. That can be fixed immediately, however. On Sat, Oct 18, 2014 at 5:30 PM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: On 10/18/2014 01:25 AM, Austin Seipp wrote: Hi all, Please see here: https://phabricator.haskell.org/D255 and https://ghc.haskell.org/trac/ghc/ticket/9230 Making tabs warn by default has been requested many times before, and now that the compiler is completely detabbed, this should become possible to enable easily, and we can gradually remove warnings from everything else. Unless someone has huge complaints or this becomes a gigantic bikeshed/review (bike-review), please let me know - I would like this to go in for 7.10. On Phabricator I see a diff which adds a suppression for the warning to GHC. Is this necessary considering you say GHC is now fully detabbed? -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs pgpMdWYuPaY6M.pgp Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Making GHCi awesomer?
On Oct 20, 2014, at 09:14, Ben Gamari bgamari.f...@gmail.com wrote: Simon Peyton Jones simo...@microsoft.com writes: Christopher You are doing very cool things. Thank you. What I’m puzzled about is this: the GHC API *is* a programmatic interface to GHC. Why not just use it? One issue that sometimes bites me when trying to compile against GHC is that of dependencies. When compiling against GHC you are bound to use whatever dependency versions GHC was compiled with. In some cases these can be a bit dated which can lead to Cabal hell. I'm not really sure what can be done about this short of making Cabal/GHC more robust in the face of multiple dependency versions within the same build. I read recently that Rust has some sort of symbol-mangling in place to allow multiple versions of the same library to co-exist within a single build. How feasible would it be to add this feature to GHC? At a first glance it seems like it would help substantially. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Making GHCi awesomer?
Sure, but how often does the API deal with types that aren't defined by `ghc` or `base`? ByteString is one case I can think of, if you want to muck about with FastStrings without the overhead of Strings. On Oct 20, 2014, at 09:59, Brandon Allbery allber...@gmail.com wrote: On Mon, Oct 20, 2014 at 12:32 PM, Eric Seidel e...@seidel.io wrote: How feasible would it be to add this feature to GHC? At a first glance it seems like it would help substantially Only until you need to hand off data between them, sadly. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Making GHCi awesomer?
Excerpts from Eric Seidel's message of 2014-10-20 09:32:41 -0700: I read recently that Rust has some sort of symbol-mangling in place to allow multiple versions of the same library to co-exist within a single build. How feasible would it be to add this feature to GHC? At a first glance it seems like it would help substantially. GHC already has this feature (and in 7.10, it will be upgraded to allow multiple instances of the same version of a library, but with different dependencies). The problem here is that Cabal doesn't understand how to put dependencies together like this. Edward ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Making GHCi awesomer?
Sorry to bother everybody, but where is this documented? What happens if incompatible versions pass data between each other? On Mon, Oct 20, 2014 at 1:22 PM, Edward Z. Yang ezy...@mit.edu wrote: Excerpts from Eric Seidel's message of 2014-10-20 09:32:41 -0700: I read recently that Rust has some sort of symbol-mangling in place to allow multiple versions of the same library to co-exist within a single build. How feasible would it be to add this feature to GHC? At a first glance it seems like it would help substantially. GHC already has this feature (and in 7.10, it will be upgraded to allow multiple instances of the same version of a library, but with different dependencies). The problem here is that Cabal doesn't understand how to put dependencies together like this. Edward ___ 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
GADTs in implementation of Template Haskell
I'm doing a bunch of bug-fixes / improvements to Template Haskell. Two of these are to fix GHC bugs #8100 (add standalone-deriving support) and #9064 (add `default` method type signature support), both of which introduce new constructors for `Dec`. This got me thinking about `Dec` and the fact that different declaration forms are allowable in different contexts. (For example, datatype declarations are allowable only at the top level, and fixity declarations are allowable anywhere except in instance declarations.) How to encode these restrictions? With types, of course! Thus, I redesigned `Dec` to be a GADT. Having done so, I'm not 100% convinced that this is the right thing to do. I would love feedback on my full, concrete proposal available at https://ghc.haskell.org/trac/ghc/wiki/Design/TemplateHaskellGADTs Is this a change for the better or worse? Feel free either to comment on the wiki page or to this email. Thanks! Richard___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GitHub pull requests
Richard Eisenberg e...@cis.upenn.edu writes: I've just finished reading this: http://www.reddit.com/r/haskell/comments/2hes8m/the_ghc_source_code_contains_1088_todos_please/ For better or worse, I don't read reddit often enough to hold a conversation there, so I'll ask my question here: Is there a way we can turn GitHub pull requests into Phab code reviews? Since things have died down here a bit this might be a good time to review the points made and distill some conclusions, 1. There is a large number of people who maintain that arc poses a significant barrier to new contributions. 2. Even if it weren't a significant barrier, given the small (but growing!) size of our contributor pool we should be reducing friction wherever possible 2. Github's pull request mechanism has a great deal of mindshare, may cause confusion, and can't be disabled. 3. There are varying degrees of concern that using the Github PR process in addition to Phab will result in confusion. This comes in a few flavors, a) Confusion between Github issue numbers, Trac bug numbers, and Phabricator identifiers b) Accepting pull requests directly may result in some users falling into the habit of submitting pull requests instead of Phab differentials c) The revision and review features of the pull request mechanism are inferior to those of Phab and may cost reviewers time. Future steps = There are are few ways forward, 1. Do nothing, ignore pull requests as we do now 2. Monitor Github for new pull requests and close with a message requesting that the user opens a differential instead 3. Teach Phabricator to allow to submit a URL to a commit (or branch) in a forked github.com/ghc/ghc repo, and create a code-revision out of that. (suggested by hvr) 4. Monitor Github for new pull requests and use facility in (3) to open a differrential and close the pull request with a message pointing to it. 5. Start accepting pull requests in addition to differentials (suggested by Joachim) What do we think about these options? I'd lean towards (4) and would be willing to try implementing it assuming there is agreement that it's a reasonable way forward. Cheers, - Ben pgpQLFu41Mvbr.pgp Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Making GHCi awesomer?
different versions will be considered to have *different* types (albeit with the same name) On Mon, Oct 20, 2014 at 2:27 PM, Christopher Allen c...@bitemyapp.com wrote: Sorry to bother everybody, but where is this documented? What happens if incompatible versions pass data between each other? On Mon, Oct 20, 2014 at 1:22 PM, Edward Z. Yang ezy...@mit.edu wrote: Excerpts from Eric Seidel's message of 2014-10-20 09:32:41 -0700: I read recently that Rust has some sort of symbol-mangling in place to allow multiple versions of the same library to co-exist within a single build. How feasible would it be to add this feature to GHC? At a first glance it seems like it would help substantially. GHC already has this feature (and in 7.10, it will be upgraded to allow multiple instances of the same version of a library, but with different dependencies). The problem here is that Cabal doesn't understand how to put dependencies together like this. Edward ___ 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 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GitHub pull requests
Whoops, accidentally only addressed Ben instead of the list: On 20 Oct 2014, at 12:13 , Ben Gamari bgamari.f...@gmail.com wrote: a) Confusion between Github issue numbers, Trac bug numbers, and Phabricator identifiers It is possible to disable GitHub issues on a repository, would this not at least solve the issue number confusion? I only figured this out today when trying to *enable* issues on my personal fork of another project. Cheers, Merijn signature.asc Description: Message signed with OpenPGP using GPGMail ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: One-shot semantics in GHC event manager
Hi, Andreas - want me to go ahead and get you some hardware to test Ben's patch in the mean time? This way we'll at least not leave it hanging until the last moment... I will also try this with two 20-core machines connected 10G on Monday. I measured the performace of GHC head, 7.8.3 and 7.8.3 + Ben's patch set. Server: witty 8080 -r -a -s +RTS -Nn *1 Measurement tool: weighttp -n 10 -c 1000 -k -t 19 http://192.168.0.1:8080/ Measurement env: two 20 core (w/o HT) machines directly connected 10G Here is result (req/s): -Nn 1 24816 - head 92,855 155,957 306,813 498,613 527,034 7.8.3 86,494 160,321 310,675 494,020 510,751 7.8.3+ben 37,608 69,376 131,686 237,783 333,946 head and 7.8.3 has almost the same performance. But I saw significant performance regression in Ben's patch set. *1 https://github.com/kazu-yamamoto/witty/blob/master/README.md P.S. - Scalability is not linear as you can see. - prefork (witty -n n) got much better result than Mio (witty +RTS n) (677,837 req/s for witty 8080 -r -a -s -n 16) --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
