Re: Disabling Travis?

2017-08-20 Thread Richard Eisenberg 
Indeed I wrote and then deleted an email to you asking to update the Travis 
script to work again. I deleted it because I realized that fixing this myself 
was easy. So, at least one person cares about Travis. :)

Why do I care? Because I find it easier to validate with Travis than with Phab, 
for these reasons:

- I don't have to go through the process of creating a new diff -- no arc, no 
diff #, no reviewers that I don't care for (as I just want validation).

- Phab does advanced Sorcerer's-apprentice-level wizardry in applying my patch. 
If it's not rebased to a current master, Strange Things happen. And sometimes, 
I'm not ready to rebase (as I just want validation).

One might ask these questions at this point:

Q: Shouldn't I *always* create a diff for a change I'm making?

A: Perhaps I should. But sometimes a fix is very straightforward and I simply 
don't have the cycles to go through a review process for every patch. As any 
committer has learned, SPJ reviews every commit that goes by anyway, and it 
seems more agile just to commit what seem like simple patches and then commit 
tweaks.

Q: Why don't I just validate locally?

A: Because I'm on a Mac laptop. There are frequently tests that fail on Mac 
that aren't my fault, and sometimes I'm about to need to move the laptop -- and 
I don't want this to interrupt validation.

The big minus to Travis, as I see it, are that only committers can use it. (A 
forked repo just doesn't work because of the way that submodules are checked 
out, IIRC.) This minus doesn't affect me, however.

Thanks,
Richard

> On Aug 20, 2017, at 12:11 PM, Joachim Breitner  
> wrote:
> 
> Hi,
> 
> I wasn’t looking for a while I notice that the travis CI build of GHC
> has not been succeeding for two months, partly because build time
> exceeded the already much extended limits we have, partly because
> support for booting with 7.10 was dropped, but the .travis file was not
> used.
> 
> A CI system that is not normally succeeding is pretty pointless, and
> will only confuse people who submit pull requests over GitHub who see
> failures.
> 
> So if noone complains now I will soon disable building on Travis.
> 
> Greetings,
> Joachim
> 
> 
> -- 
> Joachim “nomeata” Breitner
>  m...@joachim-breitner.de
>  https://www.joachim-breitner.de/
> ___
> 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

Disabling Travis?

2017-08-20 Thread Joachim Breitner 
Hi,

I wasn’t looking for a while I notice that the travis CI build of GHC
has not been succeeding for two months, partly because build time
exceeded the already much extended limits we have, partly because
support for booting with 7.10 was dropped, but the .travis file was not
used.

A CI system that is not normally succeeding is pretty pointless, and
will only confuse people who submit pull requests over GitHub who see
failures.

So if noone complains now I will soon disable building on Travis.

Greetings,
Joachim


-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de
  https://www.joachim-breitner.de/


signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Crossreferenced GHC 8.0.2

2017-08-20 Thread Robin Palotai 
Sorry for the delay - added it, see for example
http://stuff.codereview.me/#../logs/Control.Monad.Skeleton.core?corpus=core-kythe=41
.

Note that the Haskell sources (reachable by following the 'generates'
reverse edge from the Core) seem to have the empty corpus (for example
http://stuff.codereview.me/#F.hs?corpus=1).

(Also, one of the example entries had a serialization error, omitted that
one).

Looks interesting!

2017-08-17 19:22 GMT+02:00 Matthew Pickering :

> Hi all,
>
> If anyone is interested in this and using it further I have been
> working on two improvements.
>
> 1. A cross-referencer in the same style for the output of -ddump-simpl
> (which also links to the source code which produced the core).
>
> 2. A nix function which builds and references all dependencies.
>
> They are both found in my core-kythe repo with instructions about how
> to use them.
>
> https://github.com/mpickering/core-kythe
>
> You will need nix in order to use either of them but if you do it
> should be straightforward (albeit long in the first case!)
>
> I don't have a server to post examples to but Robin said he would when
> he got the chance.
>
> Matt
>
>
> On Tue, Jul 4, 2017 at 6:44 AM, Robin Palotai 
> wrote:
> > FYI I added GHC 8.2.1-rc2 source to the index. Please tell if some source
> > you would be interested in is obviously missing. Thanks!
> >
> > 2017-06-30 22:41 GMT+02:00 Robin Palotai :
> >>
> >> Hello Matthew,
> >>
> >> Please see inline
> >>
> >> 2017-06-30 11:57 GMT+02:00 Matthew Pickering
> >> :
> >>>
> >>> Hi Robin,
> >>>
> >>> This looks really useful for developers.
> >>>
> >>> 1. Would it be possible to provide a script which allows developers to
> >>> build this index for themselves easily?
> >>
> >>
> >> First, build and install the `ghc_kythe_wrapper` (instructions at
> >> https://github.com/google/haskell-indexer).
> >>
> >> Then build GHC with `make`, and capture the build log. Here's the hacky
> >> script I used:
> >> https://gist.github.com/robinp/222cf3a39cc19178ec8691522056d7fe
> >>
> >> It filters the log and replaces GHC calls to call the wrapper, which
> emits
> >> Kythe entries.
> >>
> >> Finally run `serve.sh` of the repo to postprocess and serve the entries
> >> through HTTP.
> >>
> >> This is all pretty new, so feedback or questions welcome. If the method
> >> distills, could try to write a more formal guide.
> >>
> >>>
> >>> 2. Is it possible to use this tool to detect dead code? Functions
> >>> which are not used anywhere in the compiler.
> >>
> >>
> >> We'll get there eventually, but for now the emitted data is not
> >> fine-grained enough. The main missing piece is recording what are
> exported
> >> entities of a module (Kythe schema discussion in progress). Without
> this,
> >> unused locals (which anyway surface with -Wall) would be presented and
> >> noisy.
> >>
> >> Also, one would probably need to postprocess the data a bit for this,
> like
> >> loading into a graph database or other ways.
> >>
> >> Did you see https://github.com/ndmitchell/weeder by the way? Might
> work.
> >>
> >>>
> >>> 3. How are you pretty printing the output whilst retaining the source
> >>> formatting? I had a quick look at the source but I couldn't see where
> >>> the output was being produced.
> >>>
> >>
> >> The haskell-indexer-frontend-kythe emits Kythe (http://kythe.io) schema
> >> data. We just export the source offsets, and it's the Kythe
> postprocessing /
> >> serving pipeline that does all the formatting.
> >>
> >>>
> >>> Cheers,
> >>>
> >>> Matt
> >>>
> >>> On Fri, Jun 30, 2017 at 8:55 AM, Robin Palotai <
> palotai.ro...@gmail.com>
> >>> wrote:
> >>> > Hello GHC devs,
> >>> >
> >>> > I ran haskell-indexer [1] on the GHC 8.0.2 tarball, partly because I
> >>> > find
> >>> > myself reading GHC source from time to time while working on the
> >>> > indexer,
> >>> > and partly since it's fun.
> >>> >
> >>> > First, here you can click around [2] and find where beloved functions
> >>> > are
> >>> > called from:
> >>> >
> >>> > http://stuff.codereview.me/#ghc/compiler/hsSyn/HsBinds.hs?
> corpus
> >>> > (scroll down a bit, imports are not linked yet).
> >>> >
> >>> > Second, the way I indexed was pretty simple. I took the output of
> >>> > `make`,
> >>> > replaced the ghc used with the ghc_kythe_wrapper, and filtered the
> >>> > lines
> >>> > which included '-c', since I noticed that those duplicate previous
> >>> > large
> >>> > compile lines. This only indexes the stage1 compilation AFAIU.
> >>> >
> >>> > Feel free to suggest a better way to tap into the compilations to get
> >>> > everything properly indexed (and possibly only once).
> >>> >
> >>> > Any comments welcome!
> >>> > Robin
> >>> >
> >>> > [1]: https://github.com/google/haskell-indexer
> >>> >
> >>> > [2]: TLDR UI quirks:
> >>> >   - Click the :: in top-left to navigate file tree
> >>> >   - Ctrl-Click (on linux) to go directly