Re: Decorating exceptions with backtrace information
Thanks so much for making a proposal for this, Ben!! It's great to see progress here. I'm also glad that there is now a proposal process. I made a fairly similar proposal almost exactly 5 years ago to the libraries list - https://mail.haskell.org/pipermail/libraries/2015-April/025471.html - but without the subtlety of particular backtrace representations. Skimming the ensuing thread may still be informative. In particular, there is one thing I would like to highlight from that old proposal. I think it'd be good to have a standard way to represent a chain of exceptions, and build this into `catch` and `finally`. Python and Java both have a mechanism for this, and both refer to it as a "cause" exception. When an exception is thrown during exception handling, the exception being handled is preserved as its "cause". I find this mechanism to be incredibly useful in Java, it has made the underlying issue much clearer in many cases, and in other cases at least provides helpful context. I have no doubt such a mechanism would have saved me many hours of debugging exceptions in Haskell systems I've worked on in the past. I considered commenting about that directly on the proposal, but I figure this is a better place to suggest expanding the scope of the change :) . Totally understandable if you want to keep this proposal focused on stacktraces, but I think it'd be good to consider this as a potential future improvement. -Michael On Thu, May 7, 2020 at 3:55 PM Ben Gamari wrote: > > Hi everyone, > > After a nice discussion on IRC about the unfortunate state of error > reporting in Haskell, I felt compelled to write down some long-lingering > thoughts regarding backtraces on exceptions. The result is GHC proposal > #330 [1]. I think the approach is viable and perhaps even > straightforward. I have the sketch of an implementation here [2]. > > Please have a look at the proposal and leave your comments. If there is > consensus it is possible that we could have this done for 8.12. > > Cheers, > > - Ben > > > [1] https://github.com/ghc-proposals/ghc-proposals/pull/330 > [2] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3236 > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: New and improved ghc-in-ghci target
Cool! That's very nice that it only takes a few minutes from a clean tree. I sometimes find it useful to also be able to run code from the repl. Might be good to support both usage modes via hadrian. Though, perhaps it's sufficient to have both this and `utils/ghc-in-ghci/run.sh` -Michael On Tue, Mar 12, 2019 at 6:31 AM Matthew Pickering wrote: > > Hi all, > > My patch to improve the ghc-in-ghci target just got merged a few > minutes ago. Now from a clean tree it only takes a few minutes to > launch the target. You can now load ghc into ghci by running the > following script: > > ./hadrian/ghci.sh > > https://gitlab.haskell.org/ghc/ghc/tree/master/hadrian#fast-feedback-using-ghci > > Please try it out and open tickets if there are any issues on your system. > > Matt > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: git clone https://gitlab.haskell.org/ghc/ghc.git on travis doesn't work
Ah, probably so, thanks! On Sat, Mar 9, 2019 at 6:05 PM Brandon Allbery wrote: > > I think the public name is pointed to the staging site because the main one > is down for the trac to github migration. > > On Sat, Mar 9, 2019 at 8:59 PM Michael Sloan wrote: >> >> Whoah, I can't get https://ghc.haskell.org/ to load at all - it's also >> trying to use the gitlab.staging.haskell.org cert. I can't get chrome >> to ignore the cert error because it's using HSTS - HTTP Strict >> Transport Security. >> >> On Sat, Mar 9, 2019 at 5:53 PM Michael Sloan wrote: >> > >> > I just encountered this when doing a "git pull" on my Ubuntu 18.04.1 >> > machine: >> > >> > > fatal: unable to access 'https://gitlab.haskell.org/ghc/ghc/': server >> > > certificate verification failed. CAfile: >> > > /etc/ssl/certs/ca-certificates.crt CRLfile: none >> > >> > Chrome also believes that the certificate of >> > https://gitlab.haskell.org/ghc/ghc is invalid and I have to click the >> > "Proceed to ... (unsafe)" link. Chrome's certificate viewer shows >> > that the certificate is for "gitlab.staging.haskell.org" whereas the >> > domain is "gitlab.haskell.org", so I'm guessing that's the problem. >> > I'm not very experienced with such cert stuff, but perhaps a wildcard >> > cert like "*.haskell.org" could allow using the same cert regardless >> > of whether it's on staging vs prod. >> > >> > For now I've just done "git config --global http.sslverify false" >> > temporarily to do the pull. Perhaps this is Shayne Fletcher's cheeky >> > workaround? :) >> > >> > -Michael >> > >> > On Fri, Mar 8, 2019 at 10:23 PM Ben Gamari wrote: >> > > >> > > Shayne Fletcher via ghc-devs writes: >> > > >> > > > I appreciate this isn't really "our" problem :) Nonetheless, if >> > > > there's any >> > > > config we can do on the repo on gitlab, that would be cool. Other URLs >> > > > (like github) for example are fine - something specific to gitlab. >> > > > >> > > I feel like I'm missing something here. I recall you mentioned this in >> > > your previous message but there I'm still lacking crucial context. Can >> > > you offer any additional details? How exactly does it fail? >> > > >> > > In principle there is no reason why cloning from gitlab.haskell.org from >> > > Travis shouldn't work. I'd be happy to fix the issue if there is one but >> > > without knowing more I'm pretty powerless to change the situation. >> > > >> > > Cheers, >> > > >> > > - Ben >> > > >> > > ___ >> > > ghc-devs mailing list >> > > ghc-devs@haskell.org >> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > -- > brandon s allbery kf8nh > allber...@gmail.com ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: git clone https://gitlab.haskell.org/ghc/ghc.git on travis doesn't work
Whoah, I can't get https://ghc.haskell.org/ to load at all - it's also trying to use the gitlab.staging.haskell.org cert. I can't get chrome to ignore the cert error because it's using HSTS - HTTP Strict Transport Security. On Sat, Mar 9, 2019 at 5:53 PM Michael Sloan wrote: > > I just encountered this when doing a "git pull" on my Ubuntu 18.04.1 machine: > > > fatal: unable to access 'https://gitlab.haskell.org/ghc/ghc/': server > > certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt > > CRLfile: none > > Chrome also believes that the certificate of > https://gitlab.haskell.org/ghc/ghc is invalid and I have to click the > "Proceed to ... (unsafe)" link. Chrome's certificate viewer shows > that the certificate is for "gitlab.staging.haskell.org" whereas the > domain is "gitlab.haskell.org", so I'm guessing that's the problem. > I'm not very experienced with such cert stuff, but perhaps a wildcard > cert like "*.haskell.org" could allow using the same cert regardless > of whether it's on staging vs prod. > > For now I've just done "git config --global http.sslverify false" > temporarily to do the pull. Perhaps this is Shayne Fletcher's cheeky > workaround? :) > > -Michael > > On Fri, Mar 8, 2019 at 10:23 PM Ben Gamari wrote: > > > > Shayne Fletcher via ghc-devs writes: > > > > > I appreciate this isn't really "our" problem :) Nonetheless, if there's > > > any > > > config we can do on the repo on gitlab, that would be cool. Other URLs > > > (like github) for example are fine - something specific to gitlab. > > > > > I feel like I'm missing something here. I recall you mentioned this in > > your previous message but there I'm still lacking crucial context. Can > > you offer any additional details? How exactly does it fail? > > > > In principle there is no reason why cloning from gitlab.haskell.org from > > Travis shouldn't work. I'd be happy to fix the issue if there is one but > > without knowing more I'm pretty powerless to change the situation. > > > > Cheers, > > > > - Ben > > > > ___ > > ghc-devs mailing list > > ghc-devs@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: git clone https://gitlab.haskell.org/ghc/ghc.git on travis doesn't work
I just encountered this when doing a "git pull" on my Ubuntu 18.04.1 machine: > fatal: unable to access 'https://gitlab.haskell.org/ghc/ghc/': server > certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt > CRLfile: none Chrome also believes that the certificate of https://gitlab.haskell.org/ghc/ghc is invalid and I have to click the "Proceed to ... (unsafe)" link. Chrome's certificate viewer shows that the certificate is for "gitlab.staging.haskell.org" whereas the domain is "gitlab.haskell.org", so I'm guessing that's the problem. I'm not very experienced with such cert stuff, but perhaps a wildcard cert like "*.haskell.org" could allow using the same cert regardless of whether it's on staging vs prod. For now I've just done "git config --global http.sslverify false" temporarily to do the pull. Perhaps this is Shayne Fletcher's cheeky workaround? :) -Michael On Fri, Mar 8, 2019 at 10:23 PM Ben Gamari wrote: > > Shayne Fletcher via ghc-devs writes: > > > I appreciate this isn't really "our" problem :) Nonetheless, if there's any > > config we can do on the repo on gitlab, that would be cool. Other URLs > > (like github) for example are fine - something specific to gitlab. > > > I feel like I'm missing something here. I recall you mentioned this in > your previous message but there I'm still lacking crucial context. Can > you offer any additional details? How exactly does it fail? > > In principle there is no reason why cloning from gitlab.haskell.org from > Travis shouldn't work. I'd be happy to fix the issue if there is one but > without knowing more I'm pretty powerless to change the situation. > > Cheers, > > - Ben > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Reproducing bugs without Stack
I don't have a good answer to your overall question, particularly when reproducing the issue necessarily requires a large set of build dependencies. However, one thing that may be helpful is to use `stack build --cabal-verbose`. This will pass `--verbose` when running Setup.hs, and ghc invocations are included in its verbose output. Assuming your terminal's current dir is the package that the ghc invocation is building, and the dependencies are built, you can run paste the ghc invocation after `stack exec -- ` and it should work. So, for example: ``` stack exec -- /home/mgsloan/.stack/programs/x86_64-linux/ghc-8.6.3/bin/ghc --make -no-link -fbuilding-cabal-package ... ``` Then, perhaps you can try removing arguments of the ghc invocation to attempt to arrive at a more minimal reproduction. -Michael On Sat, Jan 19, 2019 at 9:08 PM Eric Crockett wrote: > > Devs, > > I use Stack for all of my Haskell development. I recently ran into several > bugs, which I suspected to be GHC bugs. In the process of creating new > tickets, I noticed a banner reading "Please try to provide reproduction > instructions which do not require "Stack"." The request is reasonable to help > weed out bugs in Stack itself, but I could use some advice on how to do that. > > In particular, I'm having trouble reproducing bugs related to profiling. For > example, #16182 is about runtime crashes with the -hr profiling option. This > was clearly a GHC bug rather than a problem with stack, yet I have so far > been unable to produce the bug without Stack. Similarly, for #16166, I filed > the ticket, then after failing to reproduce the bug with cabal, assumed it > must be a stack bug. Fortunately, RyanGlScott noticed and was able to confirm > that it is in fact a GHC bug. Ryan explained that my problem reproducing with > cabal is due to differences in the profiling options used by stack and cabal. > > In summary, it would be helpful to have some instructions on how to take a > bug produced using Stack to one produced without. For example, if `stack > build [--profile] foo` produces a compile bug, how should I use cabal to > definitively determine if the bug is a problem with Stack or GHC? Presumably > it would begin with `cabal sandbox init`. Are there special options to put in > the cabal.config file so that cabal uses the same profiling options as stack? > Will those options be used when building all dependencies? > > Thanks, > Eric Crockett > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Understanding bind in template haskell
Hi Yotam, Template Haskell expression quotes must start with either `[|` or `[e|`, but instead these start with `[e |` - note the space. They are list comprehensions which filter to just the elements of `es` that match the `(dL -> L _ (Present _ e))`. Also, the `dL -> ...` portion is a view pattern that is equivalent to `id`, since since the arguments are already wrapped in `L`. For something like `runQ [| Foo b <- Foo 1 |]` to work, there'd need to be a quotation for `Stmt`, but there are only quotations for `Exp` / `[Dec]` / `Type` / `Pat`. I hope that's helpful! -Michael On Sat, Dec 8, 2018 at 3:30 AM Yotam Ohad wrote: > > Hi, > In the function DsMeta.repE there is a format being repeated: > For example in: > > repE e@(ExplicitTuple _ es boxed) > | not (all tupArgPresent es) = notHandled "Tuple sections" (ppr e) > | isBoxed boxed = do { xs <- repLEs [e | (dL->L _ (Present _ e)) <- es] >; repTup xs } > | otherwise = do { xs <- repLEs [e | (dL->L _ (Present _ e)) <- es] >; repUnboxedTup xs } > > There is `(dL->L _ (Present _ e)) <- es`. I don't understand how this type > checks correctly. > If I'll try to do > > data Foo a = Foo a > runQ [| Foo b <- Foo 1 |] > > in ghciI get an error. What is the difference? > > Yotam > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: ghc-in-ghci memory usage
Great, I'm glad it's working well for you! I've realized that when working on ghc-in-ghci, I didn't know about freezing stage 1 to speed up GHC builds. For me the primary motivation was that otherwise builds took quite long. Of course, ghc-in-ghci is still quite useful, due to being able to use the repl, avoiding static link times, etc. I'm not sure what the best way would be to effectively communicate with newcomers about freezing stage 1, but it seems important for build times. It may be easy to get dissuaded if every development iteration involves a ton of waiting for the build. Perhaps hadrian can be more intelligent about avoiding stage 1 rebuilds? I realize that's likely to be tricky from a correctness perspective. One thing I'm keen on for ghc-in-ghci is getting it to load without -fobject-code. This would often mean a much longer initial start (no use of stored object files), but should make reloads quite a lot faster, since it's generating bytecode instead. The main tricky bit there is the use of unboxed tuples, since ghci cannot bytecode-compile code that uses them. So, this either means adding support for unboxed tuples to bytecode, which seems quite challenging, or having something clever that only uses object-code compilation where needed. -Michael On Tue, Oct 30, 2018 at 7:56 AM Matthew Pickering wrote: > > I just tried using the ghc-in-ghci script again and it appears that > the memory usage problems have been resolved. Probably thanks to Simon > Marlow who fixed a lot of space leaks in ghc. > > A reminder of how to use it: > > ./utils/ghc-in-ghci/run.sh -j > > will load ghc into ghci so you can `:r` to recompile when you make a change. > > Cheers, > > Matt > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Scripts merged for easily loading and running GHC in GHCi, for fast development iterations
Good point, I have added a note about it to the wiki page. Surprising that it would be hard to kill. Do you have swap setup? For me it takes ~2.7GB initially and 3.5GB after the first reload. In the past I've seen it get all the way up to 9GB so there may be some memory leakage. I have 40GB of ram in my laptop, so I don't notice this much. I highly recommend investing in more memory if it's within your financial means. The productivity boon of being able to use GHCi on large projects, or run multiple concurrent docker containers or VMs, is huge. A bit off topic, but sometimes folks are surprised that I spend hundreds of dollars on keyboards like the kinesis advantage 2 (which is fantastic, btw) or the keyboard.io (really nice too!). My answer is that if I'm using some equipment many hours per day, the cost amortizes out. I ask myself "Would I pay 3 cents to use this keyboard for an hour?", in the case of those keyboards, my answer is an emphatic YES! I apply similar reasoning to my main computer hardware, though people are used to that being $$$ vs the surprise of $350 keyboards. -Michael On Wed, Aug 8, 2018 at 3:31 PM, Matthew Pickering wrote: > In practice, how much memory does this use? > > I find that with 4gb of memory that it is unusable and hard to kill. > Perhaps we should add some sort of warning to the page about this. > > Cheers > > Matt > > On Wed, Aug 8, 2018 at 11:12 PM, Michael Sloan wrote: >> Now that [D5015] is merged (thanks, monoidal!), -fobject-code no >> longer needs to be provided manually. This also means that you can >> run [ghcid] directly in the root of the repo without any arguments. I >> have updated https://ghc.haskell.org/trac/ghc/wiki/Building/InGhci to >> use the simpler invocations. >> >> [D5015]: https://phabricator.haskell.org/D5015 >> [ghcid]: https://github.com/ndmitchell/ghcid >> >> On Mon, Aug 6, 2018 at 1:03 AM, Michael Sloan wrote: >>> Thanks a bunch for updating the wiki page, Artem! It was on my todo >>> list, but it's been a rather busy week. I've added an update >>> mentioning that it will be possible to run "ghcid" directly without >>> args once D5105 is merged. >>> >>> On Mon, Aug 6, 2018 at 12:55 AM, Artem Pelenitsyn >>> wrote: >>>> I added this to the wiki. It would be nice to have a wrapper similar to >>>> `run.sh` but for starting ghcid, I believe. >>>> >>>> -- >>>> Best wishes, >>>> Artem >>>> >>>> On Sun, 29 Jul 2018 at 10:41 Matthew Pickering >>>> >>>> wrote: >>>>> >>>>> Can you please update the wiki page? >>>>> >>>>> https://ghc.haskell.org/trac/ghc/wiki/Building/InGhci >>>>> >>>>> Matt >>>>> >>>>> On Sun, Jul 29, 2018 at 6:18 AM, Michael Sloan wrote: >>>>> > Hello GHC developers! >>>>> > >>>>> > Now that D4904 and D4986 are merged, if you have recently built GHC >>>>> > then you can use "./utils/ghc-in-ghci/run.sh -fobject-code" to load >>>>> > GHC into GHCi (throwing on a "-j8" helps too). For me, this makes >>>>> > development far more pleasant, as often I can make a change and try it >>>>> > out in only 15 or 20 seconds. Thanks to Csongor Kiss for writing the >>>>> > initial ghci script, and Matthew Pickering for posting about it to the >>>>> > mailinglist, as otherwise I probably wouldn't have known about it. >>>>> > >>>>> > I wrote a blog post about the topic on my new blog: >>>>> > http://www.mgsloan.com/posts/ghcinception/ >>>>> > >>>>> > Once D5015 is merged, the explicit "-fobject-code" won't be needed. >>>>> > Once https://ghc.haskell.org/trac/ghc/ticket/15454 is addressed, it >>>>> > might not be needed at all, leading to even faster loading ;) >>>>> > >>>>> > Happy ghci-ing! >>>>> > -Michael >>>>> > ___ >>>>> > ghc-devs mailing list >>>>> > ghc-devs@haskell.org >>>>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>>> ___ >>>>> ghc-devs mailing list >>>>> ghc-devs@haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Scripts merged for easily loading and running GHC in GHCi, for fast development iterations
Now that [D5015] is merged (thanks, monoidal!), -fobject-code no longer needs to be provided manually. This also means that you can run [ghcid] directly in the root of the repo without any arguments. I have updated https://ghc.haskell.org/trac/ghc/wiki/Building/InGhci to use the simpler invocations. [D5015]: https://phabricator.haskell.org/D5015 [ghcid]: https://github.com/ndmitchell/ghcid On Mon, Aug 6, 2018 at 1:03 AM, Michael Sloan wrote: > Thanks a bunch for updating the wiki page, Artem! It was on my todo > list, but it's been a rather busy week. I've added an update > mentioning that it will be possible to run "ghcid" directly without > args once D5105 is merged. > > On Mon, Aug 6, 2018 at 12:55 AM, Artem Pelenitsyn > wrote: >> I added this to the wiki. It would be nice to have a wrapper similar to >> `run.sh` but for starting ghcid, I believe. >> >> -- >> Best wishes, >> Artem >> >> On Sun, 29 Jul 2018 at 10:41 Matthew Pickering >> wrote: >>> >>> Can you please update the wiki page? >>> >>> https://ghc.haskell.org/trac/ghc/wiki/Building/InGhci >>> >>> Matt >>> >>> On Sun, Jul 29, 2018 at 6:18 AM, Michael Sloan wrote: >>> > Hello GHC developers! >>> > >>> > Now that D4904 and D4986 are merged, if you have recently built GHC >>> > then you can use "./utils/ghc-in-ghci/run.sh -fobject-code" to load >>> > GHC into GHCi (throwing on a "-j8" helps too). For me, this makes >>> > development far more pleasant, as often I can make a change and try it >>> > out in only 15 or 20 seconds. Thanks to Csongor Kiss for writing the >>> > initial ghci script, and Matthew Pickering for posting about it to the >>> > mailinglist, as otherwise I probably wouldn't have known about it. >>> > >>> > I wrote a blog post about the topic on my new blog: >>> > http://www.mgsloan.com/posts/ghcinception/ >>> > >>> > Once D5015 is merged, the explicit "-fobject-code" won't be needed. >>> > Once https://ghc.haskell.org/trac/ghc/ticket/15454 is addressed, it >>> > might not be needed at all, leading to even faster loading ;) >>> > >>> > Happy ghci-ing! >>> > -Michael >>> > ___ >>> > ghc-devs mailing list >>> > ghc-devs@haskell.org >>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> ___ >>> ghc-devs mailing list >>> ghc-devs@haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Scripts merged for easily loading and running GHC in GHCi, for fast development iterations
Thanks a bunch for updating the wiki page, Artem! It was on my todo list, but it's been a rather busy week. I've added an update mentioning that it will be possible to run "ghcid" directly without args once D5105 is merged. On Mon, Aug 6, 2018 at 12:55 AM, Artem Pelenitsyn wrote: > I added this to the wiki. It would be nice to have a wrapper similar to > `run.sh` but for starting ghcid, I believe. > > -- > Best wishes, > Artem > > On Sun, 29 Jul 2018 at 10:41 Matthew Pickering > wrote: >> >> Can you please update the wiki page? >> >> https://ghc.haskell.org/trac/ghc/wiki/Building/InGhci >> >> Matt >> >> On Sun, Jul 29, 2018 at 6:18 AM, Michael Sloan wrote: >> > Hello GHC developers! >> > >> > Now that D4904 and D4986 are merged, if you have recently built GHC >> > then you can use "./utils/ghc-in-ghci/run.sh -fobject-code" to load >> > GHC into GHCi (throwing on a "-j8" helps too). For me, this makes >> > development far more pleasant, as often I can make a change and try it >> > out in only 15 or 20 seconds. Thanks to Csongor Kiss for writing the >> > initial ghci script, and Matthew Pickering for posting about it to the >> > mailinglist, as otherwise I probably wouldn't have known about it. >> > >> > I wrote a blog post about the topic on my new blog: >> > http://www.mgsloan.com/posts/ghcinception/ >> > >> > Once D5015 is merged, the explicit "-fobject-code" won't be needed. >> > Once https://ghc.haskell.org/trac/ghc/ticket/15454 is addressed, it >> > might not be needed at all, leading to even faster loading ;) >> > >> > Happy ghci-ing! >> > -Michael >> > ___ >> > ghc-devs mailing list >> > ghc-devs@haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Scripts merged for easily loading and running GHC in GHCi, for fast development iterations
Hello GHC developers! Now that D4904 and D4986 are merged, if you have recently built GHC then you can use "./utils/ghc-in-ghci/run.sh -fobject-code" to load GHC into GHCi (throwing on a "-j8" helps too). For me, this makes development far more pleasant, as often I can make a change and try it out in only 15 or 20 seconds. Thanks to Csongor Kiss for writing the initial ghci script, and Matthew Pickering for posting about it to the mailinglist, as otherwise I probably wouldn't have known about it. I wrote a blog post about the topic on my new blog: http://www.mgsloan.com/posts/ghcinception/ Once D5015 is merged, the explicit "-fobject-code" won't be needed. Once https://ghc.haskell.org/trac/ghc/ticket/15454 is addressed, it might not be needed at all, leading to even faster loading ;) Happy ghci-ing! -Michael ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Loading GHC into GHCi (and ghcid)
Here is the diff adding ghci scripts and some related code changes: https://phabricator.haskell.org/D4904 This has made development iterations drastically quicker for me, which for me really lowers the friction to contribution. All of my diffs in the past week were developed by using ghc-in-ghci. -Michael On Wed, Jun 27, 2018 at 10:48 PM Michael Sloan wrote: > > Wow! This is an absolute game changer for me with regards to ghc > development. My usual workflow on large haskell projects is to use > GHCI as much as possible for quick iterations. I'm really glad > Csongor figured this out and that you sent an email about it. > > I've been messing with this for a bit today, and after a few code > changes, I can to load GHCI into GHCI!! For example, I can modify > "ghciWelcomeMessage", reload, and enter into the nested ghci: > > λ :r > [491 of 492] Compiling GHCi.UI ( ../ghc/GHCi/UI.hs, tmp/GHCi/UI.o ) > Ok, 492 modules loaded. > λ :main -ignore-dot-ghci --interactive > GHCi inception, version 8.7.20180627: http://www.haskell.org/ghc/ :? for help > Prelude> unwords ["it", "works!"] > "it works!" > Prelude> :q > Leaving GHCi. > λ Prelude.unwords ["now,", "in", "outer", "GHCi"] > "now, in outer GHCi" > > I will be opening up a PR soon that makes this convenient, once I've > polished it up. > > -Michael > On Wed, May 30, 2018 at 1:43 PM Matthew Pickering > wrote: > > > > Hi all, > > > > Csongor has informed me that he has worked out how to load GHC into > > GHCi which can then be used with ghcid for a more interactive > > development experience. > > > > 1. Put this .ghci file in compiler/ > > > > https://gist.github.com/mpickering/73749e7783f40cc762fec171b879704c > > > > 2. Run "../inplace/bin/ghc-stage2 --interactive -odir tmp -hidir tmp" > > from inside compiler/ > > > > It may take a while and require a little bit of memory but in the end > > all 500 or so modules will be loaded. > > > > It can also be used with ghcid. > > > > ghcid -c "../inplace/bin/ghc-stage2 --interactive -odir tmp -hidir tmp" > > > > Hopefully someone who has more RAM than I. > > > > Can anyone suggest the suitable place on the wiki for this information? > > > > Cheers, > > > > Matt > > ___ > > ghc-devs mailing list > > ghc-devs@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Phab is unhealthy
I asked about this on #ghc IRC and bgamari said that he's going to be working on it tomorrow. I'm guessing that his comment of "man, mariadb's treatment of full disks is abysmal" is related to the problem. I've been writing down the actions I'll take once it's back up. On Mon, Jul 2, 2018 at 1:50 AM Simon Peyton Jones via ghc-devs wrote: > > I’m getting the stuff below from Phabricator, e.g. > https://phabricator.haskell.org/D4909 > > What should I do? > > Simon > > > > Error 503 Backend is unhealthy > > Backend is unhealthy > > Guru Mediation: > > Details: cache-lcy19226-LCY 1530521354 1115923518 > > > > Varnish cache server > > > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Loading GHC into GHCi (and ghcid)
Wow! This is an absolute game changer for me with regards to ghc development. My usual workflow on large haskell projects is to use GHCI as much as possible for quick iterations. I'm really glad Csongor figured this out and that you sent an email about it. I've been messing with this for a bit today, and after a few code changes, I can to load GHCI into GHCI!! For example, I can modify "ghciWelcomeMessage", reload, and enter into the nested ghci: λ :r [491 of 492] Compiling GHCi.UI ( ../ghc/GHCi/UI.hs, tmp/GHCi/UI.o ) Ok, 492 modules loaded. λ :main -ignore-dot-ghci --interactive GHCi inception, version 8.7.20180627: http://www.haskell.org/ghc/ :? for help Prelude> unwords ["it", "works!"] "it works!" Prelude> :q Leaving GHCi. λ Prelude.unwords ["now,", "in", "outer", "GHCi"] "now, in outer GHCi" I will be opening up a PR soon that makes this convenient, once I've polished it up. -Michael On Wed, May 30, 2018 at 1:43 PM Matthew Pickering wrote: > > Hi all, > > Csongor has informed me that he has worked out how to load GHC into > GHCi which can then be used with ghcid for a more interactive > development experience. > > 1. Put this .ghci file in compiler/ > > https://gist.github.com/mpickering/73749e7783f40cc762fec171b879704c > > 2. Run "../inplace/bin/ghc-stage2 --interactive -odir tmp -hidir tmp" > from inside compiler/ > > It may take a while and require a little bit of memory but in the end > all 500 or so modules will be loaded. > > It can also be used with ghcid. > > ghcid -c "../inplace/bin/ghc-stage2 --interactive -odir tmp -hidir tmp" > > Hopefully someone who has more RAM than I. > > Can anyone suggest the suitable place on the wiki for this information? > > Cheers, > > Matt > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Allow top-level shadowing for imported names?
On Wed, Oct 5, 2016 at 7:05 PM, Brandon Allbery wrote: > > On Wed, Oct 5, 2016 at 10:02 PM, Michael Sloan wrote: >> >> What if instead we re-framed this as a "top-level where clause", like >> this: >> >> main :: IO () >> main = putStrLn ("Hi" <> "There") >> >> other-function :: IO () >> other-function = putStrLn ("I can " <> "also use it") >> >> -- NOTE: 0 indent! >> >> where >> (<>) :: String -> String -> String >> (<>) = (++) > > > This would actually be slightly odd parse-wise, as we're already *in* an > unindented where clause (module ... where) Ahh, of course! Good point, that makes this idea rather unappealing - it is indeed inconsistent. Just throwing ideas out there! > -- > 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://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Allow top-level shadowing for imported names?
It is really good to think in terms of a cleverness budget. Every additional feature is not only implementation work, but also maintenance, extra cognitive overhead when adding new features, an extra thing for tooling outside of GHC to support. Personally, I'm on the wall on this one. Here are the things I see in favor of this proposal: 1) It is common practice to use -Wall. Infact, I think it should be a default, and should include more warnings than -Wall (-fwarn-tabs -fwarn-incomplete-uni-patterns -fwarn-incomplete-record-updates -fwarn-identities) 2) It lets us do things that are otherwise quite inconvenient. We can now easily shadow a bunch of identifiers without explicitly hiding them. Things I see against it: 1) It feels like a complicated way to avoid needing a "hiding ()" clause on your imports. 2) There is no good way to use this feature without creating a warning. I would like to be explicit in my name shadowing I'm thinking a pragma like {-# NO_WARN myFunction #-}, or, better yet, the more specific {-# SHADOWING myFunction #-} orso. What if instead we re-framed this as a "top-level where clause", like this: main :: IO () main = putStrLn ("Hi" <> "There") other-function :: IO () other-function = putStrLn ("I can " <> "also use it") -- NOTE: 0 indent! where (<>) :: String -> String -> String (<>) = (++) I would also like to see this extension enabling other top level declarations in where clauses, except not typeclasses. I have discussed this before, IIRC, with Richard, and there was some complexity getting local data types playing well with scoped type variables. It seems like a very worthwhile extension in its own right. I like this top-level where clause, because it riffs on existing syntax. Also, there isn't very much danger in someone accidentally dedenting their where clause to 0 level and not realizing it. The only danger there is if they were also simultaneously relying on scope shadowing (and somehow the types still work out). -Michael On Wed, Oct 5, 2016 at 9:35 AM, Christopher Allen wrote: > I agree with Tom on this. This isn't a good way to spend the cleverness > budget. > > On Wed, Oct 5, 2016 at 11:34 AM, wrote: >> I'm weakly against this proposal. I may compile with -Wall, but I read code >> by many people who don't. When I'm browsing a file and see e.g. >> >> import Network.Socket >> >> and then later in the file, I see a reference to "recvFrom", I currently >> know exactly what function is being called. I don't want to have to search >> around every time to make sure a function wasn't redefined in some dark >> corner of the module. >> >> This allows too much "sneakiness" for my taste. >> >> Tom >> >> >>> On Oct 3, 2016, at 04:29, Herbert Valerio Riedel wrote: >>> >>> Hi *, >>> >>> I seem to recall this was already suggested in the past, but I can't >>> seem to find it in the archives. For simplicity I'll restate the idea: >>> >>> >>>foo :: Int -> Int -> (Int,Int) >>>foo x y = (bar x, bar y) >>> where >>>bar x = x+x >>> >>> results merely in a name-shadowing warning (for -Wall): >>> >>>foo.hs:4:9: warning: [-Wname-shadowing] >>>This binding for ‘x’ shadows the existing binding >>> bound at foo.hs:2:5 >>> >>> >>> However, >>> >>>import Data.Monoid >>> >>>(<>) :: String -> String -> String >>>(<>) = (++) >>> >>>main :: IO () >>>main = putStrLn ("Hi" <> "There") >>> >>> doesn't allow to shadow (<>), but rather complains about ambiguity: >>> >>>bar.hs:7:23: error: >>>Ambiguous occurrence ‘<>’ >>>It could refer to either ‘Data.Monoid.<>’, >>> imported from ‘Data.Monoid’ at bar.hs:1:1-18 >>> or ‘Main.<>’, defined at bar.hs:4:1 >>> >>> >>> This is of course in line with the Haskell Report, which says in >>> https://www.haskell.org/onlinereport/haskell2010/haskellch5.html#x11-1010005.3 >>> >>> | The entities exported by a module may be brought into scope in another >>> | module with an import declaration at the beginning of the module. The >>> | import declaration names the module to be imported and optionally >>> | specifies the entities to be imported. A single module may be imported >>> | by more than one import declaration. Imported names serve as top level >>> | declarations: they scope over the entire body of the module but may be >>> | shadowed by *local non-top-level bindings.* >>> >>> >>> However, why don't we allow this to be relaxed via a new language >>> extensions, to allow top-level bindings to shadow imported names (and >>> of course emit a warning)? >>> >>> Unless I'm missing something, this would help to keep existing and >>> working code compiling if new versions of libraries start exporting new >>> symbols (which happen to clash with local top-level defs), rather than >>> resulting in a fatal name-clash; and have no major downsides. >>> >>> If this sounds like a good idea, I'll happily
Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion
On Wednesday, September 28, 2016, Eric Seidel wrote: > On Wed, Sep 28, 2016, at 18:37, Ben Gamari wrote: > > Moritz Angermann > writes: > > > > > All that arc essentially does is, compute the diff from an offset > > > (e.g. master) to the current HEAD and upload that to a new or existing > > > (--update) differential. It also adds some meta information about the > > > range, such that arc patch supposedly knows into which commit to apply > > > the patch to. > > > > > Sure, but this leads to generally unreviewable patches IMHO. In order to > > stay sane I generally split up my work into a set of standalone patches > > with git rebase and then create a Diff of each of these commits. > > Phabricator supports this by having a notion of dependencies between > > Diffs, but arcanist has no sensible scheme for taking a branch and > > conveniently producing a series of Diffs. > > I completely understand how this would be frustrating for core > contributors (more specifically for people submitting large patches), > but for new or casual contributors it's actually quite freeing. I don't > have to worry about how messy my local history gets, because arc will > throw it all away regardless! It absolves me of an extra responsibility, > and lowers the barrier to contributing. I dislike this workflow because I am already used to doing a lot of git rebasing / amending / auto squashing. So using arc means taking away my ability to write multi commit stories of how the change was crafted. For large changes there are often multiple logical inter related steps. Squashing them into one big commit makes it much harder to review. I can easily do that myself by marking everything as squash in a rebase. It feels like arcanist is just taking away power, not giving it (note i have not used it much - voice of a newbie here) I am beginning to change my feelings on this, away from thinking of GitHub as an auxilliary source of didferentials. Instead perhaps GitHub's new review system may be the way forward for GHC. It allows you to easily use git in the way it's meant to be used. -Michael > > It would be nice to support both workflows though :) > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion
On Wed, Sep 28, 2016 at 9:06 AM, Ben Gamari wrote: > That being said, I ultimately decided it would be easier to just > continue carrying out this workflow by hand considering I don't post > large series of patches *that* often. I'm also a bit more eager to > squash now than I used to be, in part due to the pain of submitting > fine-grained patch sets. On the whole I do wish that Phabricator were > more Git-like. Indeed, I do not know the details of phab / arc, but when encountering them, the workflow seemed unlike ordinary git workflows. It felt like it is working hard to implement an atypical git workflow, and learning this new workflow takes work. From the perspective of a contributor, it seemed strange since git's usual workflows are wildly successful and popular. Granted, it is easy for people to screw those up too, such as by using "git pull" instead of "git pull --rebase" orso. -Michael ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion
Exactly! So we will be using Phabricator for the review process, but with the github PRs you can use plain git. This means that new contributors will only need to learn about phabricator, and arc will be non-mandatory though probably recommended. Glad you like the idea :) -Michael On Tue, Sep 27, 2016 at 6:47 PM, Richard Eisenberg wrote: > So you're suggesting that GitHub would function as a sort of alternate > front-end to Phab. While I've grown to enjoy Phab quite a bit, I still > strongly dislike arc, which tries to be too clever for my tastes. Provided > the integration works smoothly, I quite like this idea. > > Richard > >> On Sep 27, 2016, at 5:32 PM, Michael Sloan wrote: >> >> You're welcome Richard! I look forward to helping make it happen. In >> the other thread, Alexander Vershilov mentioned that we might instead >> consider the following more straightforward workflow: >> >> 0) Have a bot that watches github for PRs. >> 1) Submit whatever you want to github as a PR. >> 2) It will be automatically closed and migrated to Phabricator. I >> would like it to automatically create a Phabricator account if you do >> not already have one. The message from the bot will tell you about >> this action, and explain how to log in, perhaps even linking to >> resources about Phabricator. >> >> Is this worth it? I think it is for the one-off cases. However, you >> will have to be prepared that this means that people won't have >> arcanist setup, and therefore are less likely to actually iterate on >> their PR. Perhaps we should extend this to the following: >> >> 3) Subsequent pushes to the branch for the PR will update the >> Phabricator differential as if you had pushed via Arcanist. I think >> with this in place, we would have a fully streamlined system that >> allows people to use their familiar GitHub workflows, without needing >> to learn Arcanist. Interactions would then still occur on , of >> course. >> >> This way, GHC HQ doesn't even need to learn to use this new "ghc-hub" >> tool! Could name the bot that, though! >> >> Thoughts? I think it would be great for this to be proposed formally >> soon so that we can make it happen. I am eager to be able to use my >> normal git workflows, as my little experience with Arcanist induced >> some head-scratching. Not the fault of the tool, just a result of >> lack of familiarity. >> >> -Michael >> >> On Tue, Sep 27, 2016 at 8:46 AM, Richard Eisenberg >> wrote: >>> To sum up, this proposes the following: >>> >>> 1. Allow PRs on GitHub. >>> >>> 2. Michael Sloan to write a new utility, ghc-hub, which automates tasks >>> interfacing between GitHub and Phab. This utility would be used only by GHC >>> HQ and not by contributors. >>> >>> 3. Small GitHub PRs can be merged directly, by ghc-hub. >>> >>> 4. Larger GitHub PRs can be migrated to Phab by ghc-hub. The contributor >>> would be issued a polite email explaining how to set up a Phab account to >>> continue to follow their contribution. >>> >>> Have I captured this accurately? If so, a resounding +1 from me. I’ve >>> wanted exactly this for a while. >>> >>> Is this worth sending through ghc-proposals? >>> >>> Thanks for volunteering item (2), Michael! >>> >>> Richard >>> >>> -=-=-=-=-=-=-=-=-=-=- >>> Richard A. Eisenberg >>> Asst. Prof. of Computer Science >>> Bryn Mawr College >>> Bryn Mawr, PA, USA >>> cs.brynmawr.edu/~rae >>> >>>> On Sep 26, 2016, at 11:09 PM, Manuel M T Chakravarty >>>> wrote: >>>> >>>> Sounds like a great idea to me and might alleviate SimonM’s concerns about >>>> fragmentation of dev attention. >>>> >>>> Manuel >>>> >>>>> Michael Sloan : >>>>> >>>>> Argh, sent too soon. The first paragraph, revised: >>>>> >>>>> This sounds like an ideal solution, Ben! As has been discussed many >>>>> times before, GitHub has many users familiar with its interface. By >>>>> allowing GitHub PRs, the initial contribution barrier will be lowered. If >>>>> there is an easy and straightforward process for shifting big patches >>>>> to Phabricator, then people who are regularly contributing via GitHub >>>>> PRs can be incrementally on-boarded to the Phabricator / Arcanist >>>>
Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion
On Tue, Sep 27, 2016 at 6:49 PM, Moritz Angermann wrote: > Hi, > > I think it would be great if this was proposed formally. If we could > integrate this with the improved ghc development proposal[1], this > would be great! Or turn it into a separate proposal and remove the > similar parts from the one mentioned. Cool! Should I do the integration? I wouldn't mind if someone else took these thoughts and integrated them, though I'd like to see how they get integrated! > However, on the topic, I’d like to share a few thoughts: > > Do we know how many of these GitHub Pull Requests we will actually > receive? If we migrate *everything* over to phabricator, isn’t that > just going to increase complexity for most of the minor pull request? We don't know how many, hopefully lots, right? What's the usual complexity for a minor patch to GHC - does it just skip differential and end up getting committed directly to master? In that case, yes this would cause there to be a lot more differentials. Is that a bad thing? We could certainly consider something more like the "ghc-hub" tool I've described elsewhere. This would give more direct control of what happens to GitHub PRs, but would also require manual oversight of incoming GitHub PRs. > If someone fixes a spelling mistake or adds a short comment to > explain something in more detail, I see no reason why we need to employ > any heavy machinery and duplication across different tools. These, so > I would hope, would be trivially merged by a small team of ghc devs > watching the GitHub PR, especially if we don’t even know how much PRs > we will receive through GitHub. > > On the other hand, if a PR is non-trivial (yes this is a bit of an > ambiguous term), I’m in favor of asking the person who issued the PR > to open an account with Phabricator[2], and run `$ arc diff origin/master` > on his branch, or let us know that he considers this too much effort > (and is willing to have someone else take over, should there be interest). > The reasoning behind this is the following: first of all it’s the persons > work, and unless someone else is willing to take it through the review > process, this is going to end up being a dead diff in phabricator which > adds additional overhead there. If there is not enough interest to follow > a simple few steps document on how to push a non-trivial patch to > phabricator, can we expect there to be sufficient interest in actually > following up on the review process? > > I see this more as an onboarding problem than a continuous development > issue. Those who are in the phabricator workflow, will likely just > continue using it, no? I certainly would! However I might be browsing > ghc source on GH just because I don’t have that code locally available > right now and stumble on a spelling mistake, quickly use the editor > provided by GH and submit one of these trivial PRs. Exactly! GH has great support for creating trivial PRs. It is also a workflow people are familiar with. As soon as you ask people to install a piece of software and learn to use it (arcanist), there is immediately a cognitive barrier. Even if the software is easy to learn. I recall being confused about arcanist squashing, for example. I haven't used it in a long time, so I don't recall details. I can see the attitude of "Well, if you're hacking on GHC, you are probably capable of learning some new tools." This is true, but this stuff is adding cognitive load atop the existing cognitive load of creating a patch for GHC. > Those who haven’t used phabricator yet, but are accustomed to the GH > PR Flow, would start there and then be gently guided towards using > phabricator and arc. We can do much better at explaining and showing > the phabricator and arc workflow. Yup! That's how I see this as well. It is leveraging GH PRs as an easy way to attract contribution, but also guiding people towards Phabricator. As things stand, you need to learn both Phabricator and Arcanist at the same time. This way, we can start with onboarding people with phabricator, and later get them to start using archanist directly. Some won't make it to that stage, but it will still be valuable to get GH PRs from them! > In essence I’d like us see accepting GH Pull Requests and then do > more data-driven on-demand incremental improvements, instead of trying > to go all out with excessive tooling. This is a wise approach! I think it makes sense to try the manual labor version of this process before automating it. Automation should be on the minds of those doing the work, though, and they can be reassured that it will get easier once automation is in place. > Cheers, > Moritz > > > [1]: > https://github.com/ghc-megacorp/ghc-proposals/blob/improved-ghc-devel
Re: How, precisely, can we improve?
On Tue, Sep 27, 2016 at 9:18 AM, Eric Seidel wrote: > On Tue, Sep 27, 2016, at 09:06, Richard Eisenberg wrote: >> Yes, I agree with Michael’s observations in the blog post. However, one >> thing that’s easier about a wiki is that the editing process is much more >> lightweight than making a PR. >> >> But GitHub has a wonderful feature (that I have rarely used) that >> mitigates this problem. Viewing a file in GitHub offers a little pencil >> icon in the top-right. It allows you to make arbitrary changes in the >> file and then automates the construction of a PR. The owner of the file >> can then accept the PR very, very easily. If the editor has commit >> rights, you can make your edits into a commit right away. No need to >> fork, pull and push. > > Indeed, GitHub also supports git-backed wikis, so you can have nicely > rendered and inter-linked pages *and* have the option for web-based or > git-based editing. Though, based on my limited experience with GitHub > wikis, I wonder if they would scale to the size of GHC's wiki.. I agree, I don't think GitHub wikis are sufficient for GHC. We've tried using GitHub wikis, and found that they were clunkier than just having wiki / docs in your repo. GHC would probably want to have a separate docs repo, as otherwise the commit history will get filled with commits related to proposals, etc. It may be worth considering a similar approach with the GHC documentation. We've had great success in stack with using https://readthedocs.org/ . The way this works is that you have a branch that readthedocs points at ("stable"), which provides the current version to display. I realize that ghc would want to have multiple versions of the docs up, but I'm sure that's feasible. Github itself has pretty nice markdown rendering, and the ability to edit directly. Note that there is no GitHub lock-in here - it is just a collection of markdown files, organized however you like them. The risk with such a migration is that the old wiki(s?) don't get fully migrated and shut down. If that happens, then information will be even more spread out and hard to find. Perhaps we can use pandoc to automatically migrate much of the wiki content to markdown? It probably will not be a lossfree conversion. > There's also a tool called gitit (https://github.com/jgm/gitit) that > seems to offer the same set of features, but apparently with a more > traditional (and I assume customizable) layout. > > I think having the option for simple, immediate edits or peer-reviewed > edits (the peer-review is much more important to me than having an > explicitly file-based system) would be a big win. Perhaps there's even a > trac module that implements something like this? Then we could decouple > it from the question/task of migrating the existing content elsewhere. > > Eric > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion
You're welcome Richard! I look forward to helping make it happen. In the other thread, Alexander Vershilov mentioned that we might instead consider the following more straightforward workflow: 0) Have a bot that watches github for PRs. 1) Submit whatever you want to github as a PR. 2) It will be automatically closed and migrated to Phabricator. I would like it to automatically create a Phabricator account if you do not already have one. The message from the bot will tell you about this action, and explain how to log in, perhaps even linking to resources about Phabricator. Is this worth it? I think it is for the one-off cases. However, you will have to be prepared that this means that people won't have arcanist setup, and therefore are less likely to actually iterate on their PR. Perhaps we should extend this to the following: 3) Subsequent pushes to the branch for the PR will update the Phabricator differential as if you had pushed via Arcanist. I think with this in place, we would have a fully streamlined system that allows people to use their familiar GitHub workflows, without needing to learn Arcanist. Interactions would then still occur on , of course. This way, GHC HQ doesn't even need to learn to use this new "ghc-hub" tool! Could name the bot that, though! Thoughts? I think it would be great for this to be proposed formally soon so that we can make it happen. I am eager to be able to use my normal git workflows, as my little experience with Arcanist induced some head-scratching. Not the fault of the tool, just a result of lack of familiarity. -Michael On Tue, Sep 27, 2016 at 8:46 AM, Richard Eisenberg wrote: > To sum up, this proposes the following: > > 1. Allow PRs on GitHub. > > 2. Michael Sloan to write a new utility, ghc-hub, which automates tasks > interfacing between GitHub and Phab. This utility would be used only by GHC > HQ and not by contributors. > > 3. Small GitHub PRs can be merged directly, by ghc-hub. > > 4. Larger GitHub PRs can be migrated to Phab by ghc-hub. The contributor > would be issued a polite email explaining how to set up a Phab account to > continue to follow their contribution. > > Have I captured this accurately? If so, a resounding +1 from me. I’ve wanted > exactly this for a while. > > Is this worth sending through ghc-proposals? > > Thanks for volunteering item (2), Michael! > > Richard > > -=-=-=-=-=-=-=-=-=-=- > Richard A. Eisenberg > Asst. Prof. of Computer Science > Bryn Mawr College > Bryn Mawr, PA, USA > cs.brynmawr.edu/~rae > >> On Sep 26, 2016, at 11:09 PM, Manuel M T Chakravarty >> wrote: >> >> Sounds like a great idea to me and might alleviate SimonM’s concerns about >> fragmentation of dev attention. >> >> Manuel >> >>> Michael Sloan : >>> >>> Argh, sent too soon. The first paragraph, revised: >>> >>> This sounds like an ideal solution, Ben! As has been discussed many >>> times before, GitHub has many users familiar with its interface. By >>> allowing GitHub PRs, the initial contribution barrier will be lowered. If >>> there is an easy and straightforward process for shifting big patches >>> to Phabricator, then people who are regularly contributing via GitHub >>> PRs can be incrementally on-boarded to the Phabricator / Arcanist >>> workflow. >>> >>> On Mon, Sep 26, 2016 at 12:07 PM, Michael Sloan wrote: >>>> This sounds like an ideal solution, Ben! As has been discussed many >>>> times before, GitHub has many users familiar with its interface. By >>>> allowing GitHub PRs, the initial contribution >>>> >>>> I think it would be acceptable for larger GitHub PRs to have some >>>> automated boilerplate response. Ideally this would look like: >>>> >>>> """ >>>> Thanks for making this patch! I've turned this into a Phab >>>> Differential xxx and closed this PR. Please create a differential >>>> account associated with your email address ..." >>>> """ >>>> >>>> The email address can be automatically pulled from commit metadata. >>>> If one is absent, then this automated process isn't possible. If it >>>> is present and >>>> >>>> So, I'm imagining a utility that interfaces between both GitHub and >>>> Phab,allowing the following commands: >>>> >>>> * "ghc-hub migrate https://github.com/ghc/ghc/pull/1"; - migrates the >>>> patch to differential. It may attempt to migrate body and title of >>>> the initial post, but lets
Re: Notes from Ben's "contribute to ghc" discussion
On Tue, Sep 27, 2016 at 8:20 AM, Alexander V Vershilov wrote: > > About GitHub based contribution. It looks great for me for *all > types* of the patches. But.. bot (or for some time person) should > migrate *all* the patches to Phab, closing the threads for comments. > Bot should write some welcome message than with a link to Phab > request and intruction how to allow Phab to use github account > and read email if there is no account yet. > This way when review had happened author will automatically receive > all review comments with links to Phab, I'll hardly get that following > a link to github is any harder than following link to Phab (assuming > Phab to login using github account). If user addressed comment > he should be able to just force-push/update his branch and new revision > should be created by bot. PR on github should be closed whenever Phab > request will be closed, so it would be trackable using GitHub only. I think this could make a great deal of sense. This will allow us to use the familiar GitHub interface for creating PRs, but all PRs will be maintained within phabricator. Creating a PR should automatically cause the user to create an account on Phabricator, if possible. I've done a quick search to see if a tool exists for this, and all I found was this abandoned patch in the phabricator project itself. https://secure.phabricator.com/D8775 Unfortunately (or fortunately, hah!), I do not know PHP. However, if phabricator has a RESTful API it seems imminently feasible to implement this as a bot written in Haskell. > This way github-ish users could use tool that they used to, but also > reviewers to use the tool they also used to. All the review > comments will be stored in the single place, no revisions will be lost. > This way could be automated and there will be no strange questions > about what is large patch and what is not. The only people who use > are ones that doesn't use email to receive review comments and can > use only GitHub interface to read that, but I doubt that such users exists. > > -- > Alexander > > On 24 September 2016 at 04:44, Simon Peyton Jones via ghc-devs > wrote: >> Friends >> >> >> >> Here are the notes I took from session 2 of the Haskell Implementors >> Meeting. The bolding is my choice of emphasis. >> >> >> >> Simon >> >> >> >> ·Doc bugs.Two kinds >> >> o Typos. Friction stops me >> >> o Explanations needed e.g. read/show >> >> ·Lightweight pushes >> >> ·Make user manual into its own repo, to make it easier to take pull >> requests. But that makes it harder when making synchronised changes to GHC >> and user manual. >> >> ·Auto-push: Ability to push to Phab and have it committed >> automatically if it validates. >> >> ·Style guides. Is having a defined style solving a problem we don’t >> really have? One piece of guidance: adhere to the style of the surrounding >> code. Low priority. >> >> ·Docker images. We should have one. >> >> ·Remove old documentation! >> >> ·Cross compilation is difficult. >> >> ·Have a GHC StackOverflow on haskell.org (Jacob Zalewski >> jakz...@gmail.com offers to do this! – thank you). It has a useful new >> Documentation feature. Eg this would be good for “how do I look up a >> RdrName to get a Name… there seem to be six different functions that do >> that”. >> >> >> ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > > > -- > Alexander > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Notes from Ben's "contribute to ghc" discussion
On Mon, Sep 26, 2016 at 12:40 PM, Simon Marlow wrote: > On 26 September 2016 at 20:13, Ben Gamari wrote: >> >> Simon Marlow writes: >> >> > I would rather we *didn't* accept contributions via github, even for >> > small >> > patches, and instead put more effort into streamlining the Phabricator >> > workflow. >> > >> > >> >- Adding another input method complicates the workflow, users have to >> >decide which one to use >> > >> I think we would want to try to sell the GitHub route as "if you would >> like to contribute then we would strongly prefer you use Phabricator, >> but if you must and it's a small patch, we will accept it via GitHub." > > > But this is opening the floodgates a crack... how do we know what a "small" > patch is? What happens when someone submits a patch that's too large? The > patches will get larger, we'll have to do code reviews on two different > tools, and it will be really hard to go back. I just have a bad feeling > about this. I agree that this would certainly happen - people would get used to the new workflow and want to use it for large patches. I've said similar things in a post I made to Carter's thread about a ghc-simple-patch-propose list. Please consider this approach: If a patch requires substantial revision, move it to Phabricator. How do we know when it requires substantial revision? There are two conditions for this: 1) When it is clear to the reviewer that it will take multiple iterations 2) After a single iteration of review has occurred on GitHub, and there is still more to do. This way, any substantial review process will be captured as a differential. We need a way to make this as easy and efficient as possible for maintainers and contributors alike. In particular, maintainer / reviewer time is very valuable. As such, I propose the following: 1) A tool called "ghc-hub", which supports "ghc-hub migrate URL", to migrate a PR to a Differential, without migrating any review metadata (to keep the implementation simple). It would also support "ghc-hub merge URL", . Using PR URLs on the commandline like this is inspired by github's hub tool - https://github.com/github/hub . 2) Eventually, have a GitHub bot which does the following: * Notices if a patch is particularly large, and recommends using the "ghc-hub" tool to perform the migration. * Notices if a patch has already gone through a review and hasn't been merged for a while, and automatically migrates it to a differential. Note that having these tools ready is not necessary to begin this new workflow, but I think they will be helpful for making this new workflow a sustainable approach. If you guys are on board with this approach, I would enjoy writing the initial version of "ghc-hub". Though I cannot at this time guarantee that I would be willing to entirely champion / maintain it - I'll need some help. >> >- Github is not integrated with our other infrastructure, while >> >Phabricator is >> > >> True, but I suspect for the small documentation patches that we are >> currently consider this shouldn't matter so much. >> >> >- Mutliple sources of contributions makes life harder for maintainers >> > >> It does certainly put yet another task on our plates, but I would argue >> that it's actually easier than accepting patches via Trac, which we >> already do. > > > We should stop accepting patches via Trac too :) > > Cheers > Simon > > > >> >> >- I also like the idea of auto-push if validate succeeds. Or a >> > button >> >that you can press on the diff that would do the same thing, so you >> > can get >> >code review first. >> > >> To be clear, I'm a bit weary of opening up the auto-push feature to new >> contributors. While regular contributors know what changes can be safely >> pushed and which require review, we have no guarantee that a new >> contributor has developed these sensibilities. >> >> >- +1 to making the manual easier to build. The same goes for >> > Haddocks; >> >it's really hard to make a simple patch to the docs and test it right >> > now. >> > >> The users guide should be quite possible to do. >> >> I don't believe there is any reliable way to allow a contributor to >> build the haddocks without having built GHC (since you need GHC master to >> parse `base`, et al.); that being said, we could have Harbormaster >> upload built documentation somewhere and then leave a link to it on the >> Diff. >> >> > One other thing that came up but wasn't mentioned in the notes: let's be >> > more prompt about reverting patches that break validate, even if they >> > only >> > break a test. Now that we have better CI support, we can easily >> > identify >> > breaking patches and revert them. >> > >> Agreed. >> >> Cheers, >> >> - Ben >> > > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-d
Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion
Argh, sent too soon. The first paragraph, revised: This sounds like an ideal solution, Ben! As has been discussed many times before, GitHub has many users familiar with its interface. By allowing GitHub PRs, the initial contribution barrier will be lowered. If there is an easy and straightforward process for shifting big patches to Phabricator, then people who are regularly contributing via GitHub PRs can be incrementally on-boarded to the Phabricator / Arcanist workflow. On Mon, Sep 26, 2016 at 12:07 PM, Michael Sloan wrote: > This sounds like an ideal solution, Ben! As has been discussed many > times before, GitHub has many users familiar with its interface. By > allowing GitHub PRs, the initial contribution > > I think it would be acceptable for larger GitHub PRs to have some > automated boilerplate response. Ideally this would look like: > > """ > Thanks for making this patch! I've turned this into a Phab > Differential xxx and closed this PR. Please create a differential > account associated with your email address ..." > """ > > The email address can be automatically pulled from commit metadata. > If one is absent, then this automated process isn't possible. If it > is present and > > So, I'm imagining a utility that interfaces between both GitHub and > Phab,allowing the following commands: > > * "ghc-hub migrate https://github.com/ghc/ghc/pull/1"; - migrates the > patch to differential. It may attempt to migrate body and title of > the initial post, but lets not bother with migrating any review data. > > * "ghc-hub merge https://github.com/ghc/ghc/pull/1"; - merges the > patch. This is used for merging small patches. It would not do an > automated push. Maybe have "--push" also perform the push? So like > if you are on master, then "ghc-hub merge > https://github.com/ghc/ghc/pull/1 --push" would merge the patches and > push to master. > > How does this sound? I like the idea a lot, and would enjoy helping > with implementation, time permitting. I could possibly start hacking > on it if others give the go ahead of "Yes, lets do that". > > -Michael > > On Mon, Sep 26, 2016 at 11:45 AM, Ben Gamari wrote: >> Carter Schonwald writes: >> >>> In writing the following huge wall of text, I had and idea that I think >>> many folks would find palatable: >>> >>> What if simple small patches (such as hypothetical drive by doc patches ) >>> had a mailing list where folks could email the simple / small patches as >>> email attachments plus a body text that summarizes the patch, what it does, >>> and why it's simple! >>> >> I completely agree that for small (e.g. documentation) patches our >> current system is quite heavy. For this reason I suggested at ICFP that >> we simply begin accepting small patches via GitHub pull requests. >> Frankly, this is less work for me than merging patches from a mailing >> list and I believe many users feel that GitHub is more accessible than a >> mailing list. >> >> The problem of course is what subset of patches do we want to allow to >> be taken via GitHub. My suggested answer to that is any patch which, if >> I were to write it myself, I would feel comfortable pushing directly to >> the tree. >> >> Then there is the question of what do we do with pull requests opened >> which do not satisfy this criterion. In this case I would likely open a >> Phabricator Differential with the pull request and close the pull >> request with a link to the Diff. In the ideal case this will inspire the >> contributor to join the review process on Phabricator; in the worst case >> review turns up issues in the patch and the user gives up. Either way, at >> least the contributor feels his patch has been seen and given the >> attention it deserves. >> >> Cheers, >> >> - Ben >> >> ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion
This sounds like an ideal solution, Ben! As has been discussed many times before, GitHub has many users familiar with its interface. By allowing GitHub PRs, the initial contribution I think it would be acceptable for larger GitHub PRs to have some automated boilerplate response. Ideally this would look like: """ Thanks for making this patch! I've turned this into a Phab Differential xxx and closed this PR. Please create a differential account associated with your email address ..." """ The email address can be automatically pulled from commit metadata. If one is absent, then this automated process isn't possible. If it is present and So, I'm imagining a utility that interfaces between both GitHub and Phab,allowing the following commands: * "ghc-hub migrate https://github.com/ghc/ghc/pull/1"; - migrates the patch to differential. It may attempt to migrate body and title of the initial post, but lets not bother with migrating any review data. * "ghc-hub merge https://github.com/ghc/ghc/pull/1"; - merges the patch. This is used for merging small patches. It would not do an automated push. Maybe have "--push" also perform the push? So like if you are on master, then "ghc-hub merge https://github.com/ghc/ghc/pull/1 --push" would merge the patches and push to master. How does this sound? I like the idea a lot, and would enjoy helping with implementation, time permitting. I could possibly start hacking on it if others give the go ahead of "Yes, lets do that". -Michael On Mon, Sep 26, 2016 at 11:45 AM, Ben Gamari wrote: > Carter Schonwald writes: > >> In writing the following huge wall of text, I had and idea that I think >> many folks would find palatable: >> >> What if simple small patches (such as hypothetical drive by doc patches ) >> had a mailing list where folks could email the simple / small patches as >> email attachments plus a body text that summarizes the patch, what it does, >> and why it's simple! >> > I completely agree that for small (e.g. documentation) patches our > current system is quite heavy. For this reason I suggested at ICFP that > we simply begin accepting small patches via GitHub pull requests. > Frankly, this is less work for me than merging patches from a mailing > list and I believe many users feel that GitHub is more accessible than a > mailing list. > > The problem of course is what subset of patches do we want to allow to > be taken via GitHub. My suggested answer to that is any patch which, if > I were to write it myself, I would feel comfortable pushing directly to > the tree. > > Then there is the question of what do we do with pull requests opened > which do not satisfy this criterion. In this case I would likely open a > Phabricator Differential with the pull request and close the pull > request with a link to the Diff. In the ideal case this will inspire the > contributor to join the review process on Phabricator; in the worst case > review turns up issues in the patch and the user gives up. Either way, at > least the contributor feels his patch has been seen and given the > attention it deserves. > > Cheers, > > - Ben > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion
I like this solution a lot, Carter! Mailing patches directly to the ghc-devs list could be intimidating for newcomers. Having a list specific to patch review could make the process less intimidating. From a perspective of overall contribution intimidation, these 2 pages make it seem like a ton of extra work to contribute to GHC: 1) https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/FixingBugs 2) https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/AddingFeatures Of course, I understand that these exist for a reason. Contributing to GHC isn't easy, and it does need processes, and those processes should be followed! However, for documentation patches and minor fixes, these pages make it seem like you really have to put in quite a bit to get started, and that the process is bureaucratic. Atop getting accounts setup and figuring out how to get ghc compiled, the amount of time investment to get in a simple patch already seems like it is on the order of hours, if not a full days worth of work. At the risk of accumulating spam, perhaps the list shouldn't even require membership? Just have it filter based on containing an attachment (perhaps even require a "*.patch" attachment?) I also think that there should be an easy way to put a stop to iterating via email and sending .patch files, and escalate to a phabricator review. Perhaps this could be scripted? Is there any way for people to use phabricator without using archanist? Not a criticism of the tech, but it is more to learn, and foreign to most. One thing I've learned from maintaining stack, is that it can be really helpful to accept patches that are imperfect. Here's how this works: 1) Some user wants to fix something, and doesn't quite nail it. Maybe makes some style mistakes, spelling errors in comments, or perhaps writes some part of the code in a less direct way than possible 2) If the overall change is an improvement and the fixes are easy, I go ahead and merge the imperfect patch, and then commit my own fixes to the issues I saw. I then say something like "Thanks for the patch!! I fixed a few things in e5cbda" I feel like this is a highly valuable approach. The contributor appreciates being thanked, and also appreciates directly seeing the ways that their patch could have been better. This is antithetical to the "google style" of code review, where every single thing is nit-picked and the author must fix it. I think that approach only works well when you already have an established membership to that culture of code review (particularly if you are getting paid for it). With that approach, all of the bad behaviors get beaten out of contributors, and they eventually learn their lesson, and either leave or become good contributors. I think this can scare some people off, that might otherwise become regular contributors. Who knows if this will work out, but I think it is really worth a shot! Especially if the wiki is updated to indicate that there is now an "easy mode" for contributing to ghc. -Michael On Sun, Sep 25, 2016 at 3:02 PM, Carter Schonwald wrote: > In writing the following huge wall of text, I had and idea that I think many > folks would find palatable: > > What if simple small patches (such as hypothetical drive by doc patches ) > had a mailing list where folks could email the simple / small patches as > email attachments plus a body text that summarizes the patch, what it does, > and why it's simple! > > What's even nice about this is its future proof and even agnostic to how the > contributor made the change set locally! They could use mercurial or fossil > for all we care. Or github. Or whatever! > > > > My personal stance is that ghc already way easier to contribute to / get > involved with than it was 2-5 years ago. This is even more impressive when > you consider the number of contributors (who aren't students) that focus on > ghc work full time has actually DECREASED over that period. > > Community engagement / management is a totally orthogonal skill from > contributing. Both take effort. Guiding new contributors requires both. > > My personal stance is that ghc keeps on getting better and getting more > contributors. And occasionally chatting about ways to make things better > that we have the bandwidth to do is something that should happen every year > or so. Like a health checkup. > > I suspect one funnel for improvement may be figuring out how to make it more > visible how many contributors / how actively deved various subsystems are. > I feel like many new folks veer towards subsystems that are already actively > worked on, which are often the ones that are both the most mature and thus > hardest to easily contribute to! Perhaps I should see if there's an easy way > to quantify that in a way that's easy to communicate to new contributors. > There's an interesting data presentation challenge in that! > > I've definitely found that for new potential contributors that orienting > them to f
Notes from Ben's "contribute to ghc" discussion
Ideally, sure, having Mozilla backing would be great and thoroughly appreciated! I understand that change takes effort. I think the core problem is participant psychology. How do we encourage people to take ownership for these problems? Perhaps more importantly, how does power get delegated such that things get done by new enthusiastic contributors? I am not very involved in GHC development (yet! we'll see - I've got a lot to do elsewhere), so I don't have a very concrete proposal. To me, seems imminently reasonable to directly emulate the approach of similar opensource projects,which have healthy, inspiring participation. I am not saying that GHC dev is sickly - we all appreciate the massive amount of effort you guys undertake on a regular basis. I am saying that we should strive to reduce participation friction and lower the barrier to entry. Lowering the barrier to entry is not trivial, it can also be accompanied by a reduction in quality. However, I think in the long run having many more contributors, many more eyes on the code, will be a net boon, even if individual contribution quality is initially lower than the current high bar of excellence. Directly emulating projects like Rust can cut through the indecision and give a direct way to reuse the efforts that community has already undertaken to solve these systemic issues. On the code review side of things, I have my preferences (github), due to its popularity and my personal familiarity with it, but I also understand that there is a lot of momentum and expertise around phabricator. If we can knock down these barriers without a herculean effort, why not give it a try? -Michael Sloan On Sat, Sep 24, 2016 at 6:56 PM, Brandon Allbery > wrote: > > On Sat, Sep 24, 2016 at 9:44 PM, Michael Sloan > wrote: >> >> It is irrelevant why Rust has an advantage. Lets please emulate their >> successful strategies instead of in-fighting. > > > Does that include having Mozilla Corp. backing them? What is your suggestion > for this? > > I understand that you think this is an important cause for the dearth of > contributors --- I've watched enough would-be contributors bounce off the > code base (long before even considering the tooling) and give up to have > major doubts, as underlined by Richard's recent message --- but throwing > everything out and building a new infrastructure is not something that > happens by itself. It needs *people* and it needs *time*. And it's harder > (and needs more people and more time) when you have a couple decades' worth > of history (which Rust did not). If you have a solution to this problem, I'm > sure people would like to hear it. > > -- > 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://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Notes from Ben's "contribute to ghc" discussion
Sorry, but I see little sense in what you are bringjng to this discussion. Chris's points sre explaining some systemic reasons WHY there is a dearth of contributors, and attempting to make a constructive plan to address them. Why should GHC not try to emulate a community that has fantasic cohesion, unity, and participation? It is irrelevant why Rust has an advantage. Lets please emulate their successful strategies instead of in-fighting. To me it seems you are just attacking his view with bluster and ad hominem, with undertones of a personal vendetta against Rust. On Saturday, September 24, 2016, Brandon Allbery wrote: > > On Sat, Sep 24, 2016 at 9:08 PM, Manuel M T Chakravarty < > c...@justtesting.org > > wrote: > >> Why are you so hostile to Chris? I don’t think that this is an >> appropriate way to treat somebody who is making a suggestion in good faith. > > > It may be in good faith. but it's not in good sense. There is a lot in the > background that made Rust's setup possible, and he's not bringing that to > the table, just assuming it'll somehow happen or that everyone else will > drop everything for the next few months and make it happen. And I feel like > he's being really pushy about committing already overworked people to this > --- and insisting that anyone opposed must have a hidden agenda or > otherwise cannot possibly have good reason to be opposed. It's not helpful > at all; it's basically a good way to stall ghc for the next few months at > least. > > -- > 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://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Notes from Ben's "contribute to ghc" discussion
As a side observer, I find Christopher's comments to be spot on. My lack of familiarity with phab has definitely de-railed my in-flight patch, adding implicit parameter and recursive do support to Template Haskell. Certainly my own fault, but also induced by friction that feels unnecessary. On Sat, Sep 24, 2016 at 5:40 PM, Brandon Allbery wrote: > > On Sat, Sep 24, 2016 at 8:38 PM, Christopher Allen > wrote: >> >> This is so short-sighted and wrong that I don't think there's any >> point in my saying more. You've made it clear you don't care. > > > And --- note that I am not a ghc developer --- have made it clear that you > do not care how much extra work you make for already massively overworked > ghc developers. > You're not contributing. You're not helping. You're derailing. > > -- > 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://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Custom warning suppression
Interesting ideas! What if #1 was implemented as a new declaration type that is allowed in where clauses? f x = SomeConstant where { unused x } For #2, I would love to have a general system for declaring new types of warnings that come with a way to dispatch the specific warning. So, picking some random new names for these: {-# NEW_VALUE_WARNING partial "This function is partial, and so should be used with care" #-} {-# VALUE_WARNING partial unsafePerformIO #-} -- Additional detail text is optional!! Lots of potential for bike shedding, a variety of choices in the tradeoff between complexity and boilerplate. On Wed, Sep 7, 2016 at 7:39 AM, David Feuer wrote: > Currently, the only way to suppress custom warnings and deprecations is with > -fno-warn-warnings-deprecations, which is a rather large hammer. I see two > ways we can improve this, and I propose that we should do both. > > 1. Per-binding suppression > > Add -fno-warn-binding, -fno-deprecate-binding, -fwarn-binding options, and > -fdeprecate-binding options. These would take the (optionally qualified) > name of a binding and control warnings tied to it. So if you invoked > -fno-warn-binding "sillyFunction", then GHC would not warn you about the > silliness of anything named sillyFunction. -fno-warn-binding > "Data.Silly.sillyFunction" would limit the suppression to the silly function > in Data.Silly. -fno-deprecate-binding would refrain from emitting > deprecation warnings for the binding in question. -fno-deprecate-binding > would presumably imply no-warn-binding, since someone who doesn't care that > a function is going to be removed probably also doesn't care what else is > wrong with it. > > 2. Named warning classes > > I'd like to add an optional "warning class" to the WARNING pragma, preceding > the warning description. This would be a short string indicating what sort > of warning is involved. This would be totally free-form, but the > documentation would suggest a few conventional options such as "partial" and > "slow". Then whole warning classes could be controlled with -fno-warn-class > and -first-class. > > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Template Haskell determinism
Also, revisiting this issue, I don't think it is worth solving, just worth documenting. Why? Because TH already lets you do lots of incorrect things. TH already allows you to shoot yourself in the foot all over the place, and that's ok. I'd much rather it be a dangerous power tool than a weak safe tool. When writing TH, you are writing something that's part of the compiler, and the code can often resemble the sort of involved in the middle bits of a compiler. For the cases where stable Ord on Name matters even for local names, you're definitely writing something that's a fairly fancy, nearly compiler-like transformation. Concerns like the stability of Names should be handled by the TH user. -Michael On Wed, Jun 29, 2016 at 10:41 AM, Michael Sloan wrote: > No, NameU and NameL both lack package key / package id. > > -Michael > > On Wed, Jun 29, 2016 at 7:34 AM, Edward Z. Yang wrote: >> No, nameBase is not the right thing to use here; you also need the >> unit ID (in GHC 8.0 parlance; package key in GHC 7.10; package id >> in GHC 7.8 and before). If you have that information, then >> GHC establishes an invariant that if two names compare stably equal, >> then the uniques associated with them are the same. >> >> Edward >> >> Excerpts from Michael Sloan's message of 2016-06-10 17:16:44 -0400: >>> Hey, sorry for not getting back to this sooner! >>> >>> Perhaps I should have added the following to my list of goals in contention: >>> >>> (3) (==) shouldn't yield True for Names that have different unique ids. >>> >>> We can only have stable comparisons if goal (3) isn't met, and two >>> different unique Names would be considered to be equivalent based on the >>> nameBase. This is because Ord is a total order, not a partial order. As >>> described in my prior email, PartialOrd could be added, but it'd be >>> inconvenient to use with existing Ord based containers. >>> >>> -Michael >>> >>> On Sun, Jun 5, 2016 at 10:15 AM, Edward Z. Yang wrote: >>> >>> > I must admit, I am a bit confused by this discussion. >>> > >>> > It is true that every Name is associated with a Unique. But you don't >>> > need the Unique to equality/ordering tests; the names also contain >>> > enough (stable) information for stable comparisons of that sort. So >>> > why don't we expose that instead of the Unique? >>> > >>> > Edward >>> > >>> > Excerpts from Michael Sloan's message of 2016-06-04 18:44:03 -0700: >>> > > On Thu, Jun 2, 2016 at 4:12 AM, Simon Peyton Jones < >>> > simo...@microsoft.com> >>> > > wrote: >>> > > >>> > > > If names get different ordering keys when reified from different >>> > modules >>> > > > (seems like they'd have to, particularly given ghc's "-j"), then we >>> > end up >>> > > > with an unpleasant circumstance where these do not compare as equal >>> > > > >>> > > > >>> > > > >>> > > > The I believe that global, top level names (NameG) are not subject to >>> > this >>> > > > ordering stuff, so I don’t think this problem can occur. >>> > > > >>> > > >>> > > True, top level names are NameG. The reified Info for a top level Dec >>> > may >>> > > include NameU, though. For example, the type variables in 'Maybe' are >>> > > NameU: >>> > > >>> > > $(do TyConI (DataD _ _ [KindedTV (Name _ nf) _] _ _ _) <- reify ''Maybe >>> > > lift (show nf)) >>> > > >>> > > The resulting expression is something like "NameU 822083586" >>> > > >>> > > > This is a breaking change and it doesn't fix the problem that >>> > NameFlavour >>> > > > is >>> > > > >>> > > > not abstract and leaks the Uniques. It would break at least: >>> > > > >>> > > > >>> > > > >>> > > > But why is NameU exposed to clients? GHC needs to know, but clients >>> > > > don’t. What use are these packages making of it? >>> > > > >>> > > >>> > > It's being leaked in the public inteface via Ord. The Eq instance is >>> > fine, >>> >
Re: Template Haskell determinism
No, NameU and NameL both lack package key / package id. -Michael On Wed, Jun 29, 2016 at 7:34 AM, Edward Z. Yang wrote: > No, nameBase is not the right thing to use here; you also need the > unit ID (in GHC 8.0 parlance; package key in GHC 7.10; package id > in GHC 7.8 and before). If you have that information, then > GHC establishes an invariant that if two names compare stably equal, > then the uniques associated with them are the same. > > Edward > > Excerpts from Michael Sloan's message of 2016-06-10 17:16:44 -0400: >> Hey, sorry for not getting back to this sooner! >> >> Perhaps I should have added the following to my list of goals in contention: >> >> (3) (==) shouldn't yield True for Names that have different unique ids. >> >> We can only have stable comparisons if goal (3) isn't met, and two >> different unique Names would be considered to be equivalent based on the >> nameBase. This is because Ord is a total order, not a partial order. As >> described in my prior email, PartialOrd could be added, but it'd be >> inconvenient to use with existing Ord based containers. >> >> -Michael >> >> On Sun, Jun 5, 2016 at 10:15 AM, Edward Z. Yang wrote: >> >> > I must admit, I am a bit confused by this discussion. >> > >> > It is true that every Name is associated with a Unique. But you don't >> > need the Unique to equality/ordering tests; the names also contain >> > enough (stable) information for stable comparisons of that sort. So >> > why don't we expose that instead of the Unique? >> > >> > Edward >> > >> > Excerpts from Michael Sloan's message of 2016-06-04 18:44:03 -0700: >> > > On Thu, Jun 2, 2016 at 4:12 AM, Simon Peyton Jones < >> > simo...@microsoft.com> >> > > wrote: >> > > >> > > > If names get different ordering keys when reified from different >> > modules >> > > > (seems like they'd have to, particularly given ghc's "-j"), then we >> > end up >> > > > with an unpleasant circumstance where these do not compare as equal >> > > > >> > > > >> > > > >> > > > The I believe that global, top level names (NameG) are not subject to >> > this >> > > > ordering stuff, so I don’t think this problem can occur. >> > > > >> > > >> > > True, top level names are NameG. The reified Info for a top level Dec >> > may >> > > include NameU, though. For example, the type variables in 'Maybe' are >> > > NameU: >> > > >> > > $(do TyConI (DataD _ _ [KindedTV (Name _ nf) _] _ _ _) <- reify ''Maybe >> > > lift (show nf)) >> > > >> > > The resulting expression is something like "NameU 822083586" >> > > >> > > > This is a breaking change and it doesn't fix the problem that >> > NameFlavour >> > > > is >> > > > >> > > > not abstract and leaks the Uniques. It would break at least: >> > > > >> > > > >> > > > >> > > > But why is NameU exposed to clients? GHC needs to know, but clients >> > > > don’t. What use are these packages making of it? >> > > > >> > > >> > > It's being leaked in the public inteface via Ord. The Eq instance is >> > fine, >> > > because these are Uniques, so the results should be consistent. >> > > >> > > There are two goals in contention here: >> > > >> > > 1) Having some ordering on Names so that they can be used in Map or Set >> > > 2) Having law-abiding Eq / Ord instances. We'd need a 'PartialOrd' to >> > > really handle these well. In that case, the ordering would be based on >> > > everything but the NameU int, but 'Eq' would still follow it >> > > >> > > A few ideas for different approaches to resolving this: >> > > >> > > 1) Document it. Less appealing than fixing it in the API, but still >> > would >> > > be good. >> > > >> > > 2) Remove the 'Ord' instance, and force the user to pick 'NamePartialOrd' >> > > newtype (partial ord on the non-unique info), or 'UnstableNameOrd' >> > newtype >> > > (current behavior). A trickyness of this approach is tha
Re: Template Haskell determinism
Hey, sorry for not getting back to this sooner! Perhaps I should have added the following to my list of goals in contention: (3) (==) shouldn't yield True for Names that have different unique ids. We can only have stable comparisons if goal (3) isn't met, and two different unique Names would be considered to be equivalent based on the nameBase. This is because Ord is a total order, not a partial order. As described in my prior email, PartialOrd could be added, but it'd be inconvenient to use with existing Ord based containers. -Michael On Sun, Jun 5, 2016 at 10:15 AM, Edward Z. Yang wrote: > I must admit, I am a bit confused by this discussion. > > It is true that every Name is associated with a Unique. But you don't > need the Unique to equality/ordering tests; the names also contain > enough (stable) information for stable comparisons of that sort. So > why don't we expose that instead of the Unique? > > Edward > > Excerpts from Michael Sloan's message of 2016-06-04 18:44:03 -0700: > > On Thu, Jun 2, 2016 at 4:12 AM, Simon Peyton Jones < > simo...@microsoft.com> > > wrote: > > > > > If names get different ordering keys when reified from different > modules > > > (seems like they'd have to, particularly given ghc's "-j"), then we > end up > > > with an unpleasant circumstance where these do not compare as equal > > > > > > > > > > > > The I believe that global, top level names (NameG) are not subject to > this > > > ordering stuff, so I don’t think this problem can occur. > > > > > > > True, top level names are NameG. The reified Info for a top level Dec > may > > include NameU, though. For example, the type variables in 'Maybe' are > > NameU: > > > > $(do TyConI (DataD _ _ [KindedTV (Name _ nf) _] _ _ _) <- reify ''Maybe > > lift (show nf)) > > > > The resulting expression is something like "NameU 822083586" > > > > > This is a breaking change and it doesn't fix the problem that > NameFlavour > > > is > > > > > > not abstract and leaks the Uniques. It would break at least: > > > > > > > > > > > > But why is NameU exposed to clients? GHC needs to know, but clients > > > don’t. What use are these packages making of it? > > > > > > > It's being leaked in the public inteface via Ord. The Eq instance is > fine, > > because these are Uniques, so the results should be consistent. > > > > There are two goals in contention here: > > > > 1) Having some ordering on Names so that they can be used in Map or Set > > 2) Having law-abiding Eq / Ord instances. We'd need a 'PartialOrd' to > > really handle these well. In that case, the ordering would be based on > > everything but the NameU int, but 'Eq' would still follow it > > > > A few ideas for different approaches to resolving this: > > > > 1) Document it. Less appealing than fixing it in the API, but still > would > > be good. > > > > 2) Remove the 'Ord' instance, and force the user to pick 'NamePartialOrd' > > newtype (partial ord on the non-unique info), or 'UnstableNameOrd' > newtype > > (current behavior). A trickyness of this approach is that you'd need > > containers that can handle (PartialOrd k, Eq k) keys. In lots of cases > > people are using the 'Ord' instance with 'Name's that are not 'NameU', so > > this would break a lot of code that was already deterministic. > > > > 3) Some approaches like this ordering key, but I'm not sure how it will > > help when comparing NameUs from different modules? > > > > > S > > > > > > > > > > > > > > > > > > *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of > *Michael > > > Sloan > > > *Sent:* 02 June 2016 02:07 > > > *To:* Bartosz Nitka > > > *Cc:* ghc-devs Devs > > > *Subject:* Re: Template Haskell determinism > > > > > > > > > > > > +1 to solving this. Not sure about the approach, but assuming the > > > following concerns are addressed, I'm (+1) on it too: > > > > > > > > > > > > This solution is clever! However, I think there is some difficulty to > > > determining this ordering key. Namely, what happens when I construct > the > > > (Set Name) using results from multiple reifies? > > > > > &
Re: Why upper bound version numbers?
Right, part of the issue with having dependency solving at the core of your workflow is that you never really know who's to blame. When running into this circumstance, either: 1) Some maintainer made a mistake. 2) Some maintainer did not have perfect knowledge of the future and has not yet updated some upper bounds. Or, upper bounds didn't get retroactively bumped (usual). 3) You're asking cabal to do something that can't be done. 4) There's a bug in the solver. So the only thing to do is to say "something went wrong". In a way it is similar to type inference, it is difficult to give specific, concrete error messages without making some arbitrary choices about which constraints have gotten pushed around. I think upper bounds could potentially be made viable by having both hard and soft constraints. Until then, people are putting 2 meanings into one thing. By having the distinction, I think cabal-install could provide much better errors than it does currently. This has come up before, I'm not sure what came of those discussions. My thoughts on how this would work: * The dependency solver would prioritize hard constraints, and tell you which soft constraints need to be lifted. I believe the solver even already has this. Stack's integration with the solver will actually first try to get a plan that doesn't override any snapshot versions, by specifying them as hard constraints. If that doesn't work, it tries again with soft constraints. * "--allow-soft" or something would ignore soft constraints. Ideally this would be selective on a per package / upper vs lower. * It may be worth having the default be "--allow-soft" + be noisy about which constraints got ignored. Then, you could have a "--pedantic-bounds" flag that forces following soft bounds. I could get behind upper bounds if they allowed maintainers to actually communicate their intention, and if we had good automation for their maintenance. As is, putting upper bounds on everything seems to cause more problems than it solves. -Michael On Wed, Jun 8, 2016 at 1:31 AM, Ben Lippmeier wrote: > > On 8 Jun 2016, at 6:19 pm, Reid Barton wrote: > > Suppose you maintain a library that is used by a lot of first year uni >> students (like gloss). Suppose the next GHC version comes around and your >> library hasn’t been updated yet because you’re waiting on some dependencies >> to get fixed before you can release your own. Do you want your students to >> get a “cannot install on this version” error, or some confusing build error >> which they don’t understand? >> > > This is a popular but ultimately silly argument. First, cabal dependency > solver error messages are terrible; there's no way a new user would figure > out from a bunch of solver output about things like "base-4.7.0.2" and > "Dependency tree exhaustively searched" that the solution is to build with > an older version of GHC. > > > :-) At least “Dependency tree exhaustively searched” sounds like it’s not > the maintainer’s problem. I prefer the complaints to say “can you please > bump the bounds on this package” rather than “your package is broken”. > > Ben. > > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Template Haskell determinism
On Thu, Jun 2, 2016 at 4:12 AM, Simon Peyton Jones wrote: > If names get different ordering keys when reified from different modules > (seems like they'd have to, particularly given ghc's "-j"), then we end up > with an unpleasant circumstance where these do not compare as equal > > > > The I believe that global, top level names (NameG) are not subject to this > ordering stuff, so I don’t think this problem can occur. > True, top level names are NameG. The reified Info for a top level Dec may include NameU, though. For example, the type variables in 'Maybe' are NameU: $(do TyConI (DataD _ _ [KindedTV (Name _ nf) _] _ _ _) <- reify ''Maybe lift (show nf)) The resulting expression is something like "NameU 822083586" > This is a breaking change and it doesn't fix the problem that NameFlavour > is > > not abstract and leaks the Uniques. It would break at least: > > > > But why is NameU exposed to clients? GHC needs to know, but clients > don’t. What use are these packages making of it? > It's being leaked in the public inteface via Ord. The Eq instance is fine, because these are Uniques, so the results should be consistent. There are two goals in contention here: 1) Having some ordering on Names so that they can be used in Map or Set 2) Having law-abiding Eq / Ord instances. We'd need a 'PartialOrd' to really handle these well. In that case, the ordering would be based on everything but the NameU int, but 'Eq' would still follow it A few ideas for different approaches to resolving this: 1) Document it. Less appealing than fixing it in the API, but still would be good. 2) Remove the 'Ord' instance, and force the user to pick 'NamePartialOrd' newtype (partial ord on the non-unique info), or 'UnstableNameOrd' newtype (current behavior). A trickyness of this approach is that you'd need containers that can handle (PartialOrd k, Eq k) keys. In lots of cases people are using the 'Ord' instance with 'Name's that are not 'NameU', so this would break a lot of code that was already deterministic. 3) Some approaches like this ordering key, but I'm not sure how it will help when comparing NameUs from different modules? > S > > > > > > *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Michael > Sloan > *Sent:* 02 June 2016 02:07 > *To:* Bartosz Nitka > *Cc:* ghc-devs Devs > *Subject:* Re: Template Haskell determinism > > > > +1 to solving this. Not sure about the approach, but assuming the > following concerns are addressed, I'm (+1) on it too: > > > > This solution is clever! However, I think there is some difficulty to > determining this ordering key. Namely, what happens when I construct the > (Set Name) using results from multiple reifies? > > > > One solution is to have the ordering key be a consecutive supply that's > initialized on a per-module basis. There is still an issue there, though, > which is that you might store one of these names in a global IORef that's > used by a later TH splice. Or, similarly, serialize the names to a file > and later load them. At least in those cases you need to use 'runIO' to > break determinism. > > > > If names get different ordering keys when reified from different modules > (seems like they'd have to, particularly given ghc's "-j"), then we end up > with an unpleasant circumstance where these do not compare as equal. How > about having the Eq instance ignore the ordering key? I think that mostly > resolves this concern. This implies that the Ord instance should also > yield EQ and ignore the ordering key, when the unique key matches. > > > > One issue with this is that switching the order of reify could > unexpectedly vary the behavior. > > > > Does the map in TcGblEnv imply that a reify from a later module will get > the same ordering key? So does this mean that the keys used in a given > reify depend on which things have already been reified? In that case, then > this is also an issue with your solution. Now, it's not a big problem at > all, just surprising to the user. > > > > > > If the internal API for Name does change, may as well address > https://ghc.haskell.org/trac/ghc/ticket/10311 too. I agree with SPJ's > suggested solution of having both the traditional package identifier and > package keys in 'Name'. > > > > -Michael > > > > On Tue, May 31, 2016 at 6:54 AM, Bartosz Nitka wrote: > > Template Haskell with its ability to do arbitrary IO is non-deterministic > by > > design. You could for examp
Re: Template Haskell determinism
+1 to solving this. Not sure about the approach, but assuming the following concerns are addressed, I'm (+1) on it too: This solution is clever! However, I think there is some difficulty to determining this ordering key. Namely, what happens when I construct the (Set Name) using results from multiple reifies? One solution is to have the ordering key be a consecutive supply that's initialized on a per-module basis. There is still an issue there, though, which is that you might store one of these names in a global IORef that's used by a later TH splice. Or, similarly, serialize the names to a file and later load them. At least in those cases you need to use 'runIO' to break determinism. If names get different ordering keys when reified from different modules (seems like they'd have to, particularly given ghc's "-j"), then we end up with an unpleasant circumstance where these do not compare as equal. How about having the Eq instance ignore the ordering key? I think that mostly resolves this concern. This implies that the Ord instance should also yield EQ and ignore the ordering key, when the unique key matches. One issue with this is that switching the order of reify could unexpectedly vary the behavior. Does the map in TcGblEnv imply that a reify from a later module will get the same ordering key? So does this mean that the keys used in a given reify depend on which things have already been reified? In that case, then this is also an issue with your solution. Now, it's not a big problem at all, just surprising to the user. If the internal API for Name does change, may as well address https://ghc.haskell.org/trac/ghc/ticket/10311 too. I agree with SPJ's suggested solution of having both the traditional package identifier and package keys in 'Name'. -Michael On Tue, May 31, 2016 at 6:54 AM, Bartosz Nitka wrote: > Template Haskell with its ability to do arbitrary IO is non-deterministic > by > design. You could for example embed the current date in a file. There is > however one kind of non-deterministic behavior that you can trigger > accidentally. It has to do with how Names are reified. If you take a look > at > the definition of reifyName you can see that it puts the assigned Unique > in a > NameU: > > reifyName :: NamedThing n => n -> TH.Name > reifyName thing > | isExternalName name = mk_varg pkg_str mod_str occ_str > | otherwise = TH.mkNameU occ_str (getKey (getUnique name)) > ... > NameFlavour which NameU is a constructor of has a default Ord instance, > meaning > that it ends up comparing the Uniques. The relative ordering of Uniques is > not > guaranteed to be stable across recompilations [1], so this can lead to > ABI-incompatible binaries. > > This isn't an abstract problem and it actually happens in practice. The > microlens package keeps Names in a Set and later turns that set into a > list. > The results have different orders of TyVars resulting in different ABI > hashes > and can potentially be optimized differently. > > I believe it's worth to handle this case in a deterministic way and I have > a > solution in mind. The idea is to extend NameU (and potentially NameL) with > an > ordering key. To be more concrete: > > - | NameU !Int > + | NameU !Int !Int > > This way the Ord instance can use a stable key and the problem reduces to > ensuring the keys are stable. To generate stable keys we can use the fact > that > reify traverses the expressions in the same order every time and > sequentially > allocate new keys based on traversal order. The way I have it implemented > now > is to add a new field in TcGblEnv which maps Uniques to allocated keys: > > +tcg_th_names :: TcRef (UniqFM Int, Int), > > Then the reifyName and qNewName do the necessary bookkeeping and translate > the > Uniques on the fly. > > This is a breaking change and it doesn't fix the problem that NameFlavour > is > not abstract and leaks the Uniques. It would break at least: > > - singletons > - th-lift > - haskell-src-meta > - shakespeare > - distributed-closure > > I'd like to get feedback if this is an acceptable solution and if the > problem > is worth solving. > > Cheers, > Bartosz > > [1] > https://ghc.haskell.org/trac/ghc/wiki/DeterministicBuilds#NondeterministicUniques > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Reification of out-of-scope variables?
I have considered how to add this capability some in the past, it's something I'd also like to have. Collecting the type info in the module finalizer is an interesting idea! This may well be the cheapest way to get the info necessary for this usecase. As far as I understand it, currently we're in the middle of typechecking when quasiquotes get run, so we don't yet have concrete. The types of reified variables may well depend upon the type of the expression generated by the quasi-quote. There seems to be a straightforward-ish way to resolve this - run typechecking twice. The first typechecking pass uses quasi-quotes substituted with stub versions of their output. For this example, it'd be (undefined :: IO double). To support this, we'd add a (Maybe ExpQ) field to QuasiQuoter, hopefully doing this in a way that preserves backwards compatibility (via pattern syns, or adding a new constructor to QuasiQuoter). For consistency, we would want to ensure that the stub unifies with the expression that actually gets used. To enforce this, we'd typecheck something equivalent to case True of True -> ... -- generated code False -> (undefined :: IO Double) -- stub My particular use case is similar, in that it's related to FFI. What I want to do is have quasiquoters for typescript in GHCJS code. Since GHCJS already runs TH in node, we can actually load up the typescript compiler and do the typechecking directly at the quasi-quote location. For the first-pass stubs, we pretend like all the captured variables are the "Any" type, and ask typescript what it thinks the overall type is. For the second pass, we have the types of the anti-quotes, and so can typecheck the whole expression. It'd also be really cool if we could generated code + typecheck anti-quotes during the first pass. This would make it possible to use anti-quotes which are more complicated than just a variable. -Michael On Fri, Apr 8, 2016 at 6:48 AM, Boespflug, Mathieu wrote: > Hi all, > > the community is increasingly using quasiquotation as a means to > interoperate with foreign languages. E.g. language-c-inline, inline-c > and inline-r allow calling foreign functions using foreign language > syntax, rather than "foreign import" declarations. There are efforts > underway for Java, Javascript and other languages too. The pattern > common to most of these libraries is: > > * collect the content of all quasiquotes that appear in a module, > generate a compilable foreign source file based on that, and then link > the object code resulting from compiling that. > > When the foreign language is itself statically typed, we need to make > sure we generate code with proper type annotations, including for any > antiquotation variables. In older versions of GHC, we could derive the > type annotations from the inferred Haskell types, but this is not > possible since 7.8 because the types of any variable in the current > "declaration group" are not made available. So libraries like inline-c > ask for some extra verbosity from the user: > > mycossin1 :: Double -> IO Double > mycossin1 somex = [cexp| double { cos($(double somex)) * sin($(double > somex)) } |] > > The type annotations inside the quasiquote are redundant with the > explicitly provided type signature. C types are typically short > enough, but other languages (e.g. C++, Java), have really long fully > qualified type names, so the extra annotations are a cost. > > The are good reasons why types aren't available from within a > declaration group (it was possible to observe the order in which type > inference works), hence why the extra annotations are necessary. But > by the time type checking of the whole module is finished, types are > fixed once and for all. So the question is: > > * Could we make it possible to query the types of local variables at > the end of type checking? > > The reason I ask is: with 'addModFinalizer' and friends that TH > provides, we're tantalizingly close to being able to generate foreign > code wrappers that have the right types that match those of the > antiquotation variables present in a module. > > Template Haskell already provides 'addModFinalizer'. You feed it a Q > action, which will run once the whole module is type checked. If at > that point we could ask, "what's the type of somex (above)?", then we > could let the user write > > mycossin2 :: Double -> IO Double > mycossin2 somex = [cexp| cos($somex) * sin($somex) |] > > and yet still generate a C file capturing the content of above > quasiquote with the right types: > > double module_foo_qq1(double v1) > { > return (cos(v1) * sin(v1)); > } > > since we know that somex :: Double and that the Haskell type "Double" > corresponds to C's "double" primitive type. > > Bound variables have a unique name associated to them, which we can > get hold of in Template Haskell using the 'var syntax, but > > f x = $(let name = 'x in addModFinalizer (reify name >>= \info -> > runIO (print info)) >> [| x |]
Re: Initial compile time benchmarks
Great! Thanks for y'all putting effort towards performance. It really is crucial for developer productivity. In the particular case of haskell-src-exts, I found that removing many of the more complicated typeclasses from deriving (Data, Generics, etc) brought the compilation time way down. IIRC it was pretty drastic, like 40 seconds vs 10 seconds (that could be just the timing for that one types module though, I don't recall). Could be valuable to investigate exactly what's going on there. -Michael On Tue, Mar 29, 2016 at 2:00 PM, Ömer Sinan Ağacan wrote: > Hi all, > > Using Ben's timing patch [^1], Cabal, and a Haskell program to parse > generated > logs [^2], I generated some tables that show compile times of modules in > hxt, > haskell-src-exts, lens, and all of their dependencies: > > > https://gist.githubusercontent.com/osa1/fd82335181a584679c9f3200b7b0a8a5/raw/5d46b0e7006c7ef9fae913f7d6932b74c83835f1/gistfile1.txt > > Some notes: > > - Modules and passes in modules are sorted. > > - At the end of the file you can see the cumulative numbers for the > passes. In > fact, that's a small table so I'm just going to paste it here: > > ==Total== > CodeGen41.32% > Simplifier 34.83% > Renamer/typechecker12.22% > Desugar 2.11% > CorePrep1.90% > Demand analysis 1.44% > CoreTidy1.35% > Called arity analysis 1.10% > Float inwards 0.96% > Common sub-expression 0.87% > Parser 0.75% > SpecConstr 0.57% > Specialise 0.30% > Worker Wrapper binds0.17% > Liberate case 0.12% > ByteCodeGen 0.00% > Simplify0.00% > > I don't know how to make use of this yet, but I thought ghc-devs may find > it > useful. > > As a next thing I'm hoping to add some more `withTiming` calls. The analyze > program can handle nested `withTiming` calls and renders passes as a tree > (GHC > HEAD doesn't have nested `withTiming`s so we don't see it in the file > above), > so we can benchmark things in more details. I also want to experiment a > little > bit with different `force` parameters to `withTiming`. If anyone has any > other > ideas I can also try those. > > --- > > [^1]: https://phabricator.haskell.org/D1959 > [^2]: https://github.com/osa1/analyze-ghc-timings > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Unused type variables with non-linear patterns
I definitely think this should be considered a usage. Ideally, you should always be able to resolve warnings, but there'd be no straightforward way to do so if LHS-only usages cause warnings. Also, It's quite useful to use type variables only on the LHS. Usage example: https://hackage.haskell.org/package/base-4.8.1.0/docs/src/Data.Type.Equality.html#EqStar -Michael On Thu, Dec 10, 2015 at 6:48 AM, Jan Stolarek wrote: > 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. We can fix this by prefixing both > appearances of `a` with an > underscore - this silences the warning and maintains semantics. > Nevertheless, if a variable is > unused it should be perfectly valid to replace it with an underscore - > that is not the case in > this example. Thoughts? > > 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 usunięcie. > > This email contains information intended solely for the use of the > individual to whom it is addressed. > If you are not the intended recipient or if you have received this message > in error, > please notify the sender and delete it from your system. > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Plugins: How to determine ghc vs ghci
The executable-path package wraps this up nicely with its `getScriptPath` function: https://hackage.haskell.org/package/executable-path-0.0.3/docs/System-Environment-Executable.html#v:getScriptPath Probably best to use this existing function. Then, if a less fragile solution comes along, getScriptPath can do that instead. -Michael On Tue, Nov 24, 2015 at 5:58 PM, Levent Erkok wrote: > Thanks! That indeed does work. > > I'm a bit surprised though that there isn't already an internal boolean > set somewhere; checking for a string in the arguments sounds a bit fragile. > > On Tue, Nov 24, 2015 at 12:28 AM, Aycan İrican > wrote: > >> How about `GHC.Environment.getFullArgs` which includes “—interactive” >> when you’re in GHCi? >> >> >> > On 24 Nov 2015, at 09:37, Levent Erkok wrote: >> > >> > I'm working on a plugin, and would like to be able to tell if it's GHC >> or GHCi that's running. >> > >> > I tried: >> > >> >df <- getDynFlags >> >let isGHCi = ghcMode df == CompManager >> > >> > Alas, while that correctly tells apart "ghci" from "ghc -c", it also >> returns True when ghc is called without the "-c" argument. >> > >> > Is there a better/more robust way of figuring out whether we're in an >> interactive session? >> > >> > -Levent. >> > ___ >> > ghc-devs mailing list >> > ghc-devs@haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [Haskell-cafe] Anonymous FFI calls
It works, cool! So at least this ought to address Francesco's use-case. Is there anything wrong with my code? It definitely looks like a GHC bug. Yes, I've successfully generated instance declarations from the top-level. I may as well describe the usecase: pretty printing a value of any type in GHCI. While this feature list isn't the main point here, it'd be very cool to do things like: * Look up the value of mutable references such as IORefs * Print out functions as just their type * Be able to evaluate particular subtrees of the pretty print output (like present [1]) * Select a subportion of the output and get a variable out of it Usage would look like "$(pretty 'x)". This would reify the type of x and transitively generate `Pretty` instances for things, by using my th-reify-many package [2]. It then generates an expression which invokes `pretty` on `x`, using these new instances. This instance generation can do clever things like check if a type has a "Data" instance, and use it if available. In this way, we can construct a pretty printer for ghci which will work for any type. Certainly, this is still possible without instance generation, but it'd be quite clever to not need to re-generate the pretty printing code for every invocation. -Michael [1] https://github.com/chrisdone/present [2] https://github.com/mgsloan/th-reify-many On Wed, Feb 11, 2015 at 6:51 PM, Geoffrey Mainland wrote: > Hi Michael, > > Try this out: > > https://gist.github.com/mainland/f18cf3827c4b0b64b835 > > Have you had success generating instance declarations from top-level > splices? > > Geoff > > On 02/11/2015 07:41 PM, Michael Sloan wrote: >> Hi! >> >> I don't mean to be accusatory with the whole documentation thing - I >> totally understand that most folks have a lot going on! In this >> particular case, I got very excited when I initially saw addTopDecls, >> because it says it allows you to "Add additional top-level >> declarations". After implementing something to use it, I got rather >> disappointed as it couldn't add instances. >> >> So, when I say "not implemented", it's just that the docs say it >> allows you to add additional top-level decls, when you can really only >> add functions, variable bindings, and foreign import decls. >> >> I didn't realize that not re-exporting these functions is due to their >> experimental status. That makes sense! I'm glad it was a conscious >> decision. I just tried writing a demo of addTopDecls, but >> unfortunately using it to add a function and referencing this function >> causes a GHC internal error: >> https://gist.github.com/mgsloan/53d7fa50338c696e5c80 . I haven't >> tried it with a foreign import yet. >> >> -Michael >> >> On Wed, Feb 11, 2015 at 3:51 PM, Geoffrey Mainland >> wrote: >>> Typed Template Haskell happened at the end of my tenure at MSR, and >>> there was a mad rush to get it in to the compiler in time for 7.8.3 at >>> the same time I was starting a new job. I'm afraid the documentation is >>> indeed wanting, but the alternative was no typed Template Haskell. >>> >>> One side-effect was that the functions you note as present only in >>> Language.Haskell.TH.Syntax were not thoroughly vetted, so we didn't >>> re-export them from Language.Haskell.TH. >>> >>> I am willing to help with documentation if people want to use this >>> functionality. Has anyone attempted to use addTopDecls? Michael, when >>> you say "it's not implemented," what do you mean? What, exactly, is not >>> implemented? >>> >>> Cheers, >>> Geoff >>> >>> On 2/11/15 6:32 PM, Michael Sloan wrote: >>>> I'd love for the implementation to be as powerful as the documentation >>>> suggests it is :D >>>> >>>> However, yes, in the meantime, fixing the documentation would be great! >>>> >>>> Also, I meant to say that addTopDecls is only exported by >>>> "Language.Haskell.TH.Syntax". While this is a digression, there are a >>>> few other handy functions that are oddly left out of >>>> "Language.Haskell.TH": addDependentFile, addModFinalizer, and possibly >>>> more. >>>> >>>> -Michael >>>> >>>> On Wed, Feb 11, 2015 at 3:25 PM, Simon Peyton Jones >>>> wrote: >>>>> I would LOVE someone to improve the documentation for addTopDecls. >>>>> Manuel Chakravarty and Geoff Mainland were responsible for
Re: [Haskell-cafe] Anonymous FFI calls
Hi! I don't mean to be accusatory with the whole documentation thing - I totally understand that most folks have a lot going on! In this particular case, I got very excited when I initially saw addTopDecls, because it says it allows you to "Add additional top-level declarations". After implementing something to use it, I got rather disappointed as it couldn't add instances. So, when I say "not implemented", it's just that the docs say it allows you to add additional top-level decls, when you can really only add functions, variable bindings, and foreign import decls. I didn't realize that not re-exporting these functions is due to their experimental status. That makes sense! I'm glad it was a conscious decision. I just tried writing a demo of addTopDecls, but unfortunately using it to add a function and referencing this function causes a GHC internal error: https://gist.github.com/mgsloan/53d7fa50338c696e5c80 . I haven't tried it with a foreign import yet. -Michael On Wed, Feb 11, 2015 at 3:51 PM, Geoffrey Mainland wrote: > Typed Template Haskell happened at the end of my tenure at MSR, and > there was a mad rush to get it in to the compiler in time for 7.8.3 at > the same time I was starting a new job. I'm afraid the documentation is > indeed wanting, but the alternative was no typed Template Haskell. > > One side-effect was that the functions you note as present only in > Language.Haskell.TH.Syntax were not thoroughly vetted, so we didn't > re-export them from Language.Haskell.TH. > > I am willing to help with documentation if people want to use this > functionality. Has anyone attempted to use addTopDecls? Michael, when > you say "it's not implemented," what do you mean? What, exactly, is not > implemented? > > Cheers, > Geoff > > On 2/11/15 6:32 PM, Michael Sloan wrote: >> I'd love for the implementation to be as powerful as the documentation >> suggests it is :D >> >> However, yes, in the meantime, fixing the documentation would be great! >> >> Also, I meant to say that addTopDecls is only exported by >> "Language.Haskell.TH.Syntax". While this is a digression, there are a >> few other handy functions that are oddly left out of >> "Language.Haskell.TH": addDependentFile, addModFinalizer, and possibly >> more. >> >> -Michael >> >> On Wed, Feb 11, 2015 at 3:25 PM, Simon Peyton Jones >> wrote: >>> I would LOVE someone to improve the documentation for addTopDecls. Manuel >>> Chakravarty and Geoff Mainland were responsible for the implementation. >>> >>> Simon >>> >>> | -Original Message- >>> | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Michael >>> | Sloan >>> | Sent: 11 February 2015 23:19 >>> | To: Francesco Mazzoli >>> | Cc: ghc-devs@haskell.org; haskell >>> | Subject: Re: [Haskell-cafe] Anonymous FFI calls >>> | >>> | It seems like addTopDecls[1] will able to help here. Unfortunately, >>> | the function is not well documented and not very discoverable because >>> | it's only exported by Language.Haskell.TH. >>> | >>> | The documentation doesn't mention that it can only be used to create >>> | new top level functions and FFI imports[2]. I think that adding FFI >>> | imports was the main motivation for implementing it. In the past >>> | I've wanted to generate instances via this function, but unfortunately >>> | it's not implemented.. >>> | >>> | Hope that helps! >>> | -Michael >>> | >>> | [1] http://hackage.haskell.org/package/template-haskell- >>> | 2.9.0.0/docs/Language-Haskell-TH-Syntax.html#v:addTopDecls >>> | >>> | [2] >>> | https://github.com/ghc/ghc/blob/1d982ba10f590828b78eba992e73315dee33f78a/ >>> | compiler/typecheck/TcSplice.hs#L818 >>> | >>> | On Wed, Feb 11, 2015 at 2:26 AM, Francesco Mazzoli wrote: >>> | > Hi, >>> | > >>> | > I am in a situation where it would be very useful to call C functions >>> | > without an explicit FFI import. For example, I'd like to be able to do >>> | > >>> | > (foreign import ccall "cadd" :: CInt -> CInt -> CInt) 1 2 >>> | > >>> | > instead of declaring the foreign import explicitely at the top level. >>> | > >>> | > Is there a way to do this or to achieve similar results in some other >>> | > way? >>> | > >>> | > If not, I imagine it would be easy to implement such a facility in GHC, >>> | > given that the code implementing calling to C functions must already be >>> | > present to implement "proper" FFI imports. I think such an addition >>> | > would be useful in many cases. >>> | > >>> | > Thanks, >>> | > Francesco >>> | > ___ >>> | > Haskell-Cafe mailing list >>> | > haskell-c...@haskell.org >>> | > http://www.haskell.org/mailman/listinfo/haskell-cafe >>> | ___ >>> | 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: [Haskell-cafe] Anonymous FFI calls
I'd love for the implementation to be as powerful as the documentation suggests it is :D However, yes, in the meantime, fixing the documentation would be great! Also, I meant to say that addTopDecls is only exported by "Language.Haskell.TH.Syntax". While this is a digression, there are a few other handy functions that are oddly left out of "Language.Haskell.TH": addDependentFile, addModFinalizer, and possibly more. -Michael On Wed, Feb 11, 2015 at 3:25 PM, Simon Peyton Jones wrote: > I would LOVE someone to improve the documentation for addTopDecls. Manuel > Chakravarty and Geoff Mainland were responsible for the implementation. > > Simon > > | -Original Message- > | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Michael > | Sloan > | Sent: 11 February 2015 23:19 > | To: Francesco Mazzoli > | Cc: ghc-devs@haskell.org; haskell > | Subject: Re: [Haskell-cafe] Anonymous FFI calls > | > | It seems like addTopDecls[1] will able to help here. Unfortunately, > | the function is not well documented and not very discoverable because > | it's only exported by Language.Haskell.TH. > | > | The documentation doesn't mention that it can only be used to create > | new top level functions and FFI imports[2]. I think that adding FFI > | imports was the main motivation for implementing it. In the past > | I've wanted to generate instances via this function, but unfortunately > | it's not implemented.. > | > | Hope that helps! > | -Michael > | > | [1] http://hackage.haskell.org/package/template-haskell- > | 2.9.0.0/docs/Language-Haskell-TH-Syntax.html#v:addTopDecls > | > | [2] > | https://github.com/ghc/ghc/blob/1d982ba10f590828b78eba992e73315dee33f78a/ > | compiler/typecheck/TcSplice.hs#L818 > | > | On Wed, Feb 11, 2015 at 2:26 AM, Francesco Mazzoli wrote: > | > Hi, > | > > | > I am in a situation where it would be very useful to call C functions > | > without an explicit FFI import. For example, I'd like to be able to do > | > > | > (foreign import ccall "cadd" :: CInt -> CInt -> CInt) 1 2 > | > > | > instead of declaring the foreign import explicitely at the top level. > | > > | > Is there a way to do this or to achieve similar results in some other > | > way? > | > > | > If not, I imagine it would be easy to implement such a facility in GHC, > | > given that the code implementing calling to C functions must already be > | > present to implement "proper" FFI imports. I think such an addition > | > would be useful in many cases. > | > > | > Thanks, > | > Francesco > | > ___ > | > Haskell-Cafe mailing list > | > haskell-c...@haskell.org > | > http://www.haskell.org/mailman/listinfo/haskell-cafe > | ___ > | 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: [Haskell-cafe] Anonymous FFI calls
It seems like addTopDecls[1] will able to help here. Unfortunately, the function is not well documented and not very discoverable because it's only exported by Language.Haskell.TH. The documentation doesn't mention that it can only be used to create new top level functions and FFI imports[2]. I think that adding FFI imports was the main motivation for implementing it. In the past I've wanted to generate instances via this function, but unfortunately it's not implemented.. Hope that helps! -Michael [1] http://hackage.haskell.org/package/template-haskell-2.9.0.0/docs/Language-Haskell-TH-Syntax.html#v:addTopDecls [2] https://github.com/ghc/ghc/blob/1d982ba10f590828b78eba992e73315dee33f78a/compiler/typecheck/TcSplice.hs#L818 On Wed, Feb 11, 2015 at 2:26 AM, Francesco Mazzoli wrote: > Hi, > > I am in a situation where it would be very useful to call C functions > without an explicit FFI import. For example, I'd like to be able to do > > (foreign import ccall "cadd" :: CInt -> CInt -> CInt) 1 2 > > instead of declaring the foreign import explicitely at the top level. > > Is there a way to do this or to achieve similar results in some other > way? > > If not, I imagine it would be easy to implement such a facility in GHC, > given that the code implementing calling to C functions must already be > present to implement "proper" FFI imports. I think such an addition > would be useful in many cases. > > Thanks, > Francesco > ___ > Haskell-Cafe mailing list > haskell-c...@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Redundant constraints
One option for avoiding the warning without runtime overhead would be to do something like this:  f :: Ord a => a -> a -> Bool f x y = True where _ = x < y On Wed, Jan 7, 2015 at 7:27 AM, Johan Tibell wrote: > I think this probably makes sense, especially since you can silence the > warning when you intend to add an unnecessary constraint. > > I had one thought though: consider an abstract data type with functions that > operates over it. I might want to require e.g Ord in the definition of a > function so I have freedom to change my implementation later, even though > the current implementation doesn't need Ord. Think of it as separating > specification and implementation. An example is 'nub'. I initially might > implement it as a O(n^2) algorithm using only Eq, but I might want to leave > the door open to using Ord to create something better, without later having > to break backwards compatibility. > > On Wed, Jan 7, 2015 at 4:19 PM, Simon Peyton Jones > wrote: >> >> Friends >> >> I’ve pushed a big patch that adds –fwarn-redundant-constraints (on by >> default). It tells you when a constraint in a signature is unnecessary, >> e.g. >> >> f :: Ord a => a -> a -> Bool >> >> f x y = True >> >> I think I have done all the necessary library updates etc, so everything >> should build fine. >> >> Four libraries which we don’t maintain have such warnings (MANY of them in >> transformers) so I’m ccing the maintainers: >> >> o containers >> >> o haskeline >> >> o transformers >> >> o binary >> >> >> >> Enjoy! >> >> >> >> Simon >> >> >> ___ >> 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