Validating with Haddock

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Validating with Haddock

Mateusz Kowalczyk
Greetings,

I'm trying to validate HEAD and I care that Haddock is built alongside
it (so --no-haddock is not an option). I get the following errors listed
at the bottom of this e-mail. How can I validate so that it all builds?

>From what I understand, to validate I should:
* Have a stable compiler in my PATH (7.6.3)
* go to top level directory
* run ?sh validate?

Am I missing steps?

== Start post-build package check
Timestamp 2013-12-28 05:00:55 UTC for
/home/shana/.ghc/i386-linux-7.7.20131227/package.conf.d/package.cache
Timestamp 2013-12-28 05:00:55 UTC for
/home/shana/.ghc/i386-linux-7.7.20131227/package.conf.d (same as cache)
using cache:
/home/shana/.ghc/i386-linux-7.7.20131227/package.conf.d/package.cache
Timestamp 2013-12-28 05:22:27 UTC for
/home/shana/programming/ghc/inplace/lib/package.conf.d/package.cache
Timestamp 2013-12-28 05:22:27 UTC for
/home/shana/programming/ghc/inplace/lib/package.conf.d (same as cache)
using cache:
/home/shana/programming/ghc/inplace/lib/package.conf.d/package.cache
There are problems in package xhtml-3000.2.1:
  dependency "base-4.7.0.0-578628bf142f9304d05ce5581b5f8d76" doesn't exist
There are problems in package ghc-paths-0.1.0.9:
  dependency "base-4.7.0.0-578628bf142f9304d05ce5581b5f8d76" doesn't exist

The following packages are broken, either because they have a problem
listed above, or because they depend on a broken package.
xhtml-3000.2.1
ghc-paths-0.1.0.9

--
Mateusz K.

Reply | Threaded
Open this post in threaded view
|

Validating with Haddock

Mateusz Kowalczyk
On 28/12/13 16:53, Mateusz Kowalczyk wrote:

> Greetings,
>
> I'm trying to validate HEAD and I care that Haddock is built alongside
> it (so --no-haddock is not an option). I get the following errors listed
> at the bottom of this e-mail. How can I validate so that it all builds?
>
> From what I understand, to validate I should:
> * Have a stable compiler in my PATH (7.6.3)
> * go to top level directory
> * run ?sh validate?
>
> Am I missing steps?
>
> == Start post-build package check
> Timestamp 2013-12-28 05:00:55 UTC for
> /home/shana/.ghc/i386-linux-7.7.20131227/package.conf.d/package.cache
> Timestamp 2013-12-28 05:00:55 UTC for
> /home/shana/.ghc/i386-linux-7.7.20131227/package.conf.d (same as cache)
> using cache:
> /home/shana/.ghc/i386-linux-7.7.20131227/package.conf.d/package.cache
> Timestamp 2013-12-28 05:22:27 UTC for
> /home/shana/programming/ghc/inplace/lib/package.conf.d/package.cache
> Timestamp 2013-12-28 05:22:27 UTC for
> /home/shana/programming/ghc/inplace/lib/package.conf.d (same as cache)
> using cache:
> /home/shana/programming/ghc/inplace/lib/package.conf.d/package.cache
> There are problems in package xhtml-3000.2.1:
>   dependency "base-4.7.0.0-578628bf142f9304d05ce5581b5f8d76" doesn't exist
> There are problems in package ghc-paths-0.1.0.9:
>   dependency "base-4.7.0.0-578628bf142f9304d05ce5581b5f8d76" doesn't exist
>
> The following packages are broken, either because they have a problem
> listed above, or because they depend on a broken package.
> xhtml-3000.2.1
> ghc-paths-0.1.0.9
>

Ping. I need GHC to validate. Here's what I'm trying to achieve: as you
might know, I worked on Haddock over summer, rewriting the whole parser,
adding tests, fixing bugs, adding features. As Haddock ships with GHC
however (and is technically a GHC HQ package), we can not merge it
without making sure that GHC can build and validate with the changes.

This has been a problem for me and Simon Hengel for quite a while. We
now have a branch with preliminary changes on
https://github.com/sol/haddock/tree/new-parser . We can not even begin
to try to merge the new features if the parser they are built upon is
not merged. With the recent calls to push out a 7.8 release candidate, I
think we're running out of time to get this in (or is it too late
already?). It is not the first time we've been asking for help here!

Can someone say what are the steps I should take to get an OK from the
GHC HQ that we can push new-parser onto master? If we miss 7.8, the next
opportunity will be 7.10, because to get a new Haddock version you also
need a new compiler, which people only get during stable releases.
There's still a lot of work to be done on Haddock and I think it's
understandable that I don't want to do work on what effectively is an
?outdated version?. I'm fine with changes being rejected because they
are deemed not good enough for some specific reason, but I'd hate the
changes to not make it because I can't get a confirmation from GHC HQ
that it's safe to do so.

Thanks, hope to hear from someone soon.

--
Mateusz K.

Reply | Threaded
Open this post in threaded view
|

Validating with Haddock

Carter Schonwald
Well said points.
1) perhaps opening a ticket on ghc trac for your problem is a good next
step. That way folks who are better at reading trac than email can help!
2) if the pattern synonyms branch gets merged in, you'll have to upstream
the associated changes to haddock too right?

On Monday, January 6, 2014, Mateusz Kowalczyk wrote:

> On 28/12/13 16:53, Mateusz Kowalczyk wrote:
> > Greetings,
> >
> > I'm trying to validate HEAD and I care that Haddock is built alongside
> > it (so --no-haddock is not an option). I get the following errors listed
> > at the bottom of this e-mail. How can I validate so that it all builds?
> >
> > From what I understand, to validate I should:
> > * Have a stable compiler in my PATH (7.6.3)
> > * go to top level directory
> > * run ?sh validate?
> >
> > Am I missing steps?
> >
> > == Start post-build package check
> > Timestamp 2013-12-28 05:00:55 UTC for
> > /home/shana/.ghc/i386-linux-7.7.20131227/package.conf.d/package.cache
> > Timestamp 2013-12-28 05:00:55 UTC for
> > /home/shana/.ghc/i386-linux-7.7.20131227/package.conf.d (same as cache)
> > using cache:
> > /home/shana/.ghc/i386-linux-7.7.20131227/package.conf.d/package.cache
> > Timestamp 2013-12-28 05:22:27 UTC for
> > /home/shana/programming/ghc/inplace/lib/package.conf.d/package.cache
> > Timestamp 2013-12-28 05:22:27 UTC for
> > /home/shana/programming/ghc/inplace/lib/package.conf.d (same as cache)
> > using cache:
> > /home/shana/programming/ghc/inplace/lib/package.conf.d/package.cache
> > There are problems in package xhtml-3000.2.1:
> >   dependency "base-4.7.0.0-578628bf142f9304d05ce5581b5f8d76" doesn't
> exist
> > There are problems in package ghc-paths-0.1.0.9:
> >   dependency "base-4.7.0.0-578628bf142f9304d05ce5581b5f8d76" doesn't
> exist
> >
> > The following packages are broken, either because they have a problem
> > listed above, or because they depend on a broken package.
> > xhtml-3000.2.1
> > ghc-paths-0.1.0.9
> >
>
> Ping. I need GHC to validate. Here's what I'm trying to achieve: as you
> might know, I worked on Haddock over summer, rewriting the whole parser,
> adding tests, fixing bugs, adding features. As Haddock ships with GHC
> however (and is technically a GHC HQ package), we can not merge it
> without making sure that GHC can build and validate with the changes.
>
> This has been a problem for me and Simon Hengel for quite a while. We
> now have a branch with preliminary changes on
> https://github.com/sol/haddock/tree/new-parser . We can not even begin
> to try to merge the new features if the parser they are built upon is
> not merged. With the recent calls to push out a 7.8 release candidate, I
> think we're running out of time to get this in (or is it too late
> already?). It is not the first time we've been asking for help here!
>
> Can someone say what are the steps I should take to get an OK from the
> GHC HQ that we can push new-parser onto master? If we miss 7.8, the next
> opportunity will be 7.10, because to get a new Haddock version you also
> need a new compiler, which people only get during stable releases.
> There's still a lot of work to be done on Haddock and I think it's
> understandable that I don't want to do work on what effectively is an
> ?outdated version?. I'm fine with changes being rejected because they
> are deemed not good enough for some specific reason, but I'd hate the
> changes to not make it because I can't get a confirmation from GHC HQ
> that it's safe to do so.
>
> Thanks, hope to hear from someone soon.
>
> --
> Mateusz K.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org <javascript:;>
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140106/57bec7fa/attachment-0001.html>

Reply | Threaded
Open this post in threaded view
|

Validating with Haddock

Mateusz Kowalczyk
On 07/01/14 04:17, Carter Schonwald wrote:
> Well said points.
> 1) perhaps opening a ticket on ghc trac for your problem is a good next
> step. That way folks who are better at reading trac than email can help!

I'll do so tomorrow if I don't get any replies with tips.

> 2) if the pattern synonyms branch gets merged in, you'll have to upstream
> the associated changes to haddock too right?

It's not a show-stopper if Haddock can't document something. In fact
there are many things it can't document already (GADT type constructors
are an easy one). If someone writes the pattern synonym stuff for
existing Haddock it's not a problem. The proposed changes from
new-parser don't touch the parts that pattern synonyms would and if they
did, it'd be easy to merge. Usually GHC HQ folk patch up Haddock when
they change API so that it can still compile but everything extra tends
to be a ?if we can get it to document the new bleeding-edge feature,
then great, if not, someone will make a ticket later?.

I actually attempted to make Haddock work with some extra stuff that it
currently can't document but because it so heavily depends on GHC, I
need my GHC tree validating for that too.

--
Mateusz K.

Reply | Threaded
Open this post in threaded view
|

Validating with Haddock

Carter Schonwald
i'd really recommend asking on #ghc and filing a ticket on trac
preemptively. Different people reply better on different channels



On Tue, Jan 7, 2014 at 12:23 AM, Mateusz Kowalczyk
<fuuzetsu at fuuzetsu.co.uk>wrote:

> On 07/01/14 04:17, Carter Schonwald wrote:
> > Well said points.
> > 1) perhaps opening a ticket on ghc trac for your problem is a good next
> > step. That way folks who are better at reading trac than email can help!
>
> I'll do so tomorrow if I don't get any replies with tips.
>
> > 2) if the pattern synonyms branch gets merged in, you'll have to upstream
> > the associated changes to haddock too right?
>
> It's not a show-stopper if Haddock can't document something. In fact
> there are many things it can't document already (GADT type constructors
> are an easy one). If someone writes the pattern synonym stuff for
> existing Haddock it's not a problem. The proposed changes from
> new-parser don't touch the parts that pattern synonyms would and if they
> did, it'd be easy to merge. Usually GHC HQ folk patch up Haddock when
> they change API so that it can still compile but everything extra tends
> to be a ?if we can get it to document the new bleeding-edge feature,
> then great, if not, someone will make a ticket later?.
>
> I actually attempted to make Haddock work with some extra stuff that it
> currently can't document but because it so heavily depends on GHC, I
> need my GHC tree validating for that too.
>
> --
> Mateusz K.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140107/4d0f5f7a/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Validating with Haddock

Simon Peyton Jones
In reply to this post by Mateusz Kowalczyk
I get a different bunch of "post-build package check" complaints.  Does anyone else have a clue what is going on? I do not.

Mine are reproduced below. They appear to be non-fatal warnings.  I bet it's because I have HADDOCK_DOCS=NO, but if so that should surely suppress all these warnings?

It would be great if someone could figure out what the post-build package check is doing and why it isn't working for Mateusz.

Simon

== Start post-testsuite package check
Timestamp Mon Jan  6 17:45:05 GMT 2014 for /5playpen/simonpj/HEAD-2/inplace/lib/package.conf.d/package.cache
Timestamp Mon Jan  6 17:45:05 GMT 2014 for /5playpen/simonpj/HEAD-2/inplace/lib/package.conf.d (same as cache)
using cache: /5playpen/simonpj/HEAD-2/inplace/lib/package.conf.d/package.cache
Warning: haddock-interfaces: /5playpen/simonpj/HEAD-2/libraries/dph/dph-lifted-vseg/dist-install/doc/html/dph-lifted-vseg/dph-lifted-vseg.haddock doesn't exist or isn't a file
Warning: haddock-interfaces: /5playpen/simonpj/HEAD-2/libraries/dph/dph-lifted-copy/dist-install/doc/html/dph-lifted-copy/dph-lifted-copy.haddock doesn't exist or isn't a file
Warning: haddock-interfaces: /5playpen/simonpj/HEAD-2/libraries/dph/dph-lifted-boxed/dist-install/doc/html/dph-lifted-boxed/dph-lifted-boxed.haddock doesn't exist or isn't a file
...etc


| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
| Mateusz Kowalczyk
| Sent: 07 January 2014 03:13
| To: ghc-devs at haskell.org
| Subject: Re: Validating with Haddock
|
| On 28/12/13 16:53, Mateusz Kowalczyk wrote:
| > Greetings,
| >
| > I'm trying to validate HEAD and I care that Haddock is built alongside
| > it (so --no-haddock is not an option). I get the following errors
| > listed at the bottom of this e-mail. How can I validate so that it all
| builds?
| >
| > From what I understand, to validate I should:
| > * Have a stable compiler in my PATH (7.6.3)
| > * go to top level directory
| > * run 'sh validate'
| >
| > Am I missing steps?
| >
| > == Start post-build package check
| > Timestamp 2013-12-28 05:00:55 UTC for
| > /home/shana/.ghc/i386-linux-7.7.20131227/package.conf.d/package.cache
| > Timestamp 2013-12-28 05:00:55 UTC for
| > /home/shana/.ghc/i386-linux-7.7.20131227/package.conf.d (same as
| > cache) using cache:
| > /home/shana/.ghc/i386-linux-7.7.20131227/package.conf.d/package.cache
| > Timestamp 2013-12-28 05:22:27 UTC for
| > /home/shana/programming/ghc/inplace/lib/package.conf.d/package.cache
| > Timestamp 2013-12-28 05:22:27 UTC for
| > /home/shana/programming/ghc/inplace/lib/package.conf.d (same as cache)
| > using cache:
| > /home/shana/programming/ghc/inplace/lib/package.conf.d/package.cache
| > There are problems in package xhtml-3000.2.1:
| >   dependency "base-4.7.0.0-578628bf142f9304d05ce5581b5f8d76" doesn't
| > exist There are problems in package ghc-paths-0.1.0.9:
| >   dependency "base-4.7.0.0-578628bf142f9304d05ce5581b5f8d76" doesn't
| > exist
| >
| > The following packages are broken, either because they have a problem
| > listed above, or because they depend on a broken package.
| > xhtml-3000.2.1
| > ghc-paths-0.1.0.9
| >
|
| Ping. I need GHC to validate. Here's what I'm trying to achieve: as you
| might know, I worked on Haddock over summer, rewriting the whole parser,
| adding tests, fixing bugs, adding features. As Haddock ships with GHC
| however (and is technically a GHC HQ package), we can not merge it
| without making sure that GHC can build and validate with the changes.
|
| This has been a problem for me and Simon Hengel for quite a while. We
| now have a branch with preliminary changes on
| https://github.com/sol/haddock/tree/new-parser . We can not even begin
| to try to merge the new features if the parser they are built upon is
| not merged. With the recent calls to push out a 7.8 release candidate, I
| think we're running out of time to get this in (or is it too late
| already?). It is not the first time we've been asking for help here!
|
| Can someone say what are the steps I should take to get an OK from the
| GHC HQ that we can push new-parser onto master? If we miss 7.8, the next
| opportunity will be 7.10, because to get a new Haddock version you also
| need a new compiler, which people only get during stable releases.
| There's still a lot of work to be done on Haddock and I think it's
| understandable that I don't want to do work on what effectively is an
| 'outdated version'. I'm fine with changes being rejected because they
| are deemed not good enough for some specific reason, but I'd hate the
| changes to not make it because I can't get a confirmation from GHC HQ
| that it's safe to do so.
|
| Thanks, hope to hear from someone soon.
|
| --
| Mateusz K.
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs

Reply | Threaded
Open this post in threaded view
|

Validating with Haddock

Simon Peyton Jones
In reply to this post by Mateusz Kowalczyk
| Ping. I need GHC to validate. Here's what I'm trying to achieve: as you
| might know, I worked on Haddock over summer, rewriting the whole parser,
| adding tests, fixing bugs, adding features. As Haddock ships with GHC
| however (and is technically a GHC HQ package), we can not merge it
| without making sure that GHC can build and validate with the changes.
|
| This has been a problem for me and Simon Hengel for quite a while. We
| now have a branch with preliminary changes on
| https://github.com/sol/haddock/tree/new-parser . We can not even begin
| to try to merge the new features if the parser they are built upon is
| not merged. With the recent calls to push out a 7.8 release candidate, I
| think we're running out of time to get this in (or is it too late
| already?). It is not the first time we've been asking for help here!

Actually I didn't know that you were asking to get something into 7.8.  Haddock is maintained by David Waern and Simon Marlow, so the question of when to merge your changes into the main Haddock HEAD is up to them, not GHC HQ.  We'll simply ship whatever Haddock we have when we cut the release candidate.  (I know there is still some fuzz about when that will be; Austin is figuring that out now.)

I'm copying David and Simon.

Simon

Reply | Threaded
Open this post in threaded view
|

Validating with Haddock

Mateusz Kowalczyk
On 07/01/14 09:41, Simon Peyton Jones wrote:

> | Ping. I need GHC to validate. Here's what I'm trying to achieve: as you
> | might know, I worked on Haddock over summer, rewriting the whole parser,
> | adding tests, fixing bugs, adding features. As Haddock ships with GHC
> | however (and is technically a GHC HQ package), we can not merge it
> | without making sure that GHC can build and validate with the changes.
> |
> | This has been a problem for me and Simon Hengel for quite a while. We
> | now have a branch with preliminary changes on
> | https://github.com/sol/haddock/tree/new-parser . We can not even begin
> | to try to merge the new features if the parser they are built upon is
> | not merged. With the recent calls to push out a 7.8 release candidate, I
> | think we're running out of time to get this in (or is it too late
> | already?). It is not the first time we've been asking for help here!
>
> Actually I didn't know that you were asking to get something into 7.8.  Haddock is maintained by David Waern and Simon Marlow, so the question of when to merge your changes into the main Haddock HEAD is up to them, not GHC HQ.  We'll simply ship whatever Haddock we have when we cut the release candidate.  (I know there is still some fuzz about when that will be; Austin is figuring that out now.)
>
> I'm copying David and Simon.
>
> Simon
>

David stepped down and Simon Marlow has a long time ago too! It is now
Simon Hengel who maintains it.

The issue is that Simon could not get the tree to validate properly on
his machine either so I'm here seeking help so that we can push up with
confidence. Simon has e-mailed Austin on 22/11/2013 about it but we have
been unable to verify that all is fine.

Is it by now too late for 7.8? I'm afraid Simon H is away without much
access to technology until the 20th.

Un-CC'ing Simon M and David W and CC'ing Simon H.

--
Mateusz K.

Reply | Threaded
Open this post in threaded view
|

Validating with Haddock

Simon Peyton Jones
| David stepped down and Simon Marlow has a long time ago too! It is now
| Simon Hengel who maintains it.

OK, well perhaps you can immediately push a change to haddock.cabal to reflect this?  That's how we know.

| Is it by now too late for 7.8? I'm afraid Simon H is away without much
| access to technology until the 20th.

Realistically that would push 7.8 RC to the end of Jan.  Why would that be better than pushing to head just after the 7.8 release?  Will 7.8 users see a big improvement if it was in?  What do others think?

S

Reply | Threaded
Open this post in threaded view
|

Validating with Haddock

Mateusz Kowalczyk
On 07/01/14 10:20, Simon Peyton Jones wrote:
> | David stepped down and Simon Marlow has a long time ago too! It is now
> | Simon Hengel who maintains it.
>
> OK, well perhaps you can immediately push a change to haddock.cabal to reflect this?  That's how we know.

I will try later but I think I don't have permissions. I can at best
push to Simon's branch where he would periodically push to the GHC
hosted repository (or perhaps it would get pulled from, I do not know).

>
> | Is it by now too late for 7.8? I'm afraid Simon H is away without much
> | access to technology until the 20th.
>
> Realistically that would push 7.8 RC to the end of Jan.  Why would that be better than pushing to head just after the 7.8 release?  Will 7.8 users see a big improvement if it was in?  What do others think?

The changes were mostly there for user benefit. The markup can now be
escaped much better. If we can validate what's on Simon's new-parser
branch reasonably quickly, we might even be able to push in the new
features: new mark up, nested paragraphs, better lists, headers? I'm
trying to push for 7.8 because Haddock ships with GHC and 7.8 is the
stable release that everyone will be using in couple of months time. If
the changes don't get into 7.8, we'll have to wait for the next stable
release for the users to benefit. Is this incorrect? I was always under
the impression that the only Haddock releases we can reasonably make are
with stable GHC releases. Of course, anyone can compile HEAD and
generate the docs for their own viewing but for example, Hackage will
run stable compiler and all the docs will still be using old Haddock.

I'd love to hear that I'm wrong about this and that Haddock releases
separate from GHC are possible but I don't think that's the case.

>
> S
>


--
Mateusz K.

Reply | Threaded
Open this post in threaded view
|

Validating with Haddock

Austin Seipp-5
Hi Mateusz,

I remember your email and I believe I responded with the OK at the
time - my impression was that it was ready to be merged and would
shortly be done after that, but I didn't hear anything back about it.
I apologize for my dropping the ball.

As for your actual error - ghc-paths is only used in Haddock when it's
not built in the GHC tree (as per the cabal file,) so I find it very
suspicious that your package check is mentioning it at all (it's not
mentioned anywhere else in any GHC sources.) Can you verify that it's
there with `./inplace/bin/ghc-pkg list`? I'm not even sure how it
could possibly get involved.

Finally, can you be more specific about exactly how you tested these
changes with your modified Haddock? I presume it was something like:

$ ... clone ghc source ...
$ cd ghc
$ ... get extra stuff with ./sync-all ...
$ cd utils/haddock
$ ... use git to grab your code from github ...
$ cd ../..
$ sh ./validate

But I'd like to make sure I know exactly what's going on. I can try
testing your branch later today.

On Tue, Jan 7, 2014 at 4:29 AM, Mateusz Kowalczyk
<fuuzetsu at fuuzetsu.co.uk> wrote:

> On 07/01/14 10:20, Simon Peyton Jones wrote:
>> | David stepped down and Simon Marlow has a long time ago too! It is now
>> | Simon Hengel who maintains it.
>>
>> OK, well perhaps you can immediately push a change to haddock.cabal to reflect this?  That's how we know.
>
> I will try later but I think I don't have permissions. I can at best
> push to Simon's branch where he would periodically push to the GHC
> hosted repository (or perhaps it would get pulled from, I do not know).
>
>>
>> | Is it by now too late for 7.8? I'm afraid Simon H is away without much
>> | access to technology until the 20th.
>>
>> Realistically that would push 7.8 RC to the end of Jan.  Why would that be better than pushing to head just after the 7.8 release?  Will 7.8 users see a big improvement if it was in?  What do others think?
>
> The changes were mostly there for user benefit. The markup can now be
> escaped much better. If we can validate what's on Simon's new-parser
> branch reasonably quickly, we might even be able to push in the new
> features: new mark up, nested paragraphs, better lists, headers? I'm
> trying to push for 7.8 because Haddock ships with GHC and 7.8 is the
> stable release that everyone will be using in couple of months time. If
> the changes don't get into 7.8, we'll have to wait for the next stable
> release for the users to benefit. Is this incorrect? I was always under
> the impression that the only Haddock releases we can reasonably make are
> with stable GHC releases. Of course, anyone can compile HEAD and
> generate the docs for their own viewing but for example, Hackage will
> run stable compiler and all the docs will still be using old Haddock.
>
> I'd love to hear that I'm wrong about this and that Haddock releases
> separate from GHC are possible but I don't think that's the case.
>
>>
>> S
>>
>
>
> --
> Mateusz K.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



--
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

Reply | Threaded
Open this post in threaded view
|

Validating with Haddock

Mateusz Kowalczyk
On 07/01/14 14:42, Austin Seipp wrote:
> Hi Mateusz,
>
> I remember your email and I believe I responded with the OK at the
> time - my impression was that it was ready to be merged and would
> shortly be done after that, but I didn't hear anything back about it.
> I apologize for my dropping the ball.

We contacted you because we thought it wouldn't be this much trouble
to get an OK from the validate process. The code was technically more
or less ready months ago, although Simon has been making some changes
here and there.

> As for your actual error - ghc-paths is only used in Haddock when it's
> not built in the GHC tree (as per the cabal file,) so I find it very
> suspicious that your package check is mentioning it at all (it's not
> mentioned anywhere else in any GHC sources.) Can you verify that it's
> there with `./inplace/bin/ghc-pkg list`? I'm not even sure how it
> could possibly get involved.
>
> Finally, can you be more specific about exactly how you tested these
> changes with your modified Haddock? I presume it was something like:

I had ran it on a as-is tree so that I could compare the results from
before and after I put my changes in. I had just ran validate
yesterday again (after sync-all) and I no longer get this package failure!

> $ ... clone ghc source ...
> $ cd ghc
> $ ... get extra stuff with ./sync-all ...
> $ cd utils/haddock
> $ ... use git to grab your code from github ...
> $ cd ../..
> $ sh ./validate

As I mention, it was on unchanged tree but this is how I'll do it when
testing the changes.

> But I'd like to make sure I know exactly what's going on. I can try
> testing your branch later today.

I think the original issue is now gone. I do get 8 unexpected failures
and about 11000+ skipped tests! Is this normal? Should I be filing
bugs? Should I create a separate thread? Can someone look at my log?
You can download it from [1], it's about 8MB. If GHC itself compiles
the test information into some files you'd prefer, please let me know,
I simply redirected all output from the validate script into a log.

[1]: http://fuuzetsu.co.uk/misc/validatelog

--
Mateusz K.

Reply | Threaded
Open this post in threaded view
|

Validating with Haddock

Austin Seipp-5
Yes, the skipped tests are normal. The testsuite has a concept of
tests being built a certain 'way' - for example, you might test a
piece of code by making sure it works compiled with -threaded,
non-threaded, profiling, the LLVM backend, or any combination of
those, etc. So a single *test* gives rise to multiple *test cases*.

When you run validate, it runs it in a 'fast' mode by default as
opposed to the slow mode. The fast mode only runs a subset of the
overall test cases - it runs the most basic tests per file, which
generally gives a pretty good indication as to what is going on.

Also, the performance failures you're seeing are (I speculate) due to
out of date performance numbers. Sometimes these numbers go up or down
just due to code churn, but they're sometimes finnicky, because they
may depend on the exact time a major GC happens or something. So a
small wibble can cause them to sometimes occasionally fail.

In any case, these results seem to indicate your branch looks quite
OK, so I can try to merge this soon, if you think it is actually
complete and ready.

On Tue, Jan 7, 2014 at 12:13 PM, Mateusz Kowalczyk
<fuuzetsu at fuuzetsu.co.uk> wrote:

> On 07/01/14 14:42, Austin Seipp wrote:
>> Hi Mateusz,
>>
>> I remember your email and I believe I responded with the OK at the
>> time - my impression was that it was ready to be merged and would
>> shortly be done after that, but I didn't hear anything back about it.
>> I apologize for my dropping the ball.
>
> We contacted you because we thought it wouldn't be this much trouble
> to get an OK from the validate process. The code was technically more
> or less ready months ago, although Simon has been making some changes
> here and there.
>
>> As for your actual error - ghc-paths is only used in Haddock when it's
>> not built in the GHC tree (as per the cabal file,) so I find it very
>> suspicious that your package check is mentioning it at all (it's not
>> mentioned anywhere else in any GHC sources.) Can you verify that it's
>> there with `./inplace/bin/ghc-pkg list`? I'm not even sure how it
>> could possibly get involved.
>>
>> Finally, can you be more specific about exactly how you tested these
>> changes with your modified Haddock? I presume it was something like:
>
> I had ran it on a as-is tree so that I could compare the results from
> before and after I put my changes in. I had just ran validate
> yesterday again (after sync-all) and I no longer get this package failure!
>
>> $ ... clone ghc source ...
>> $ cd ghc
>> $ ... get extra stuff with ./sync-all ...
>> $ cd utils/haddock
>> $ ... use git to grab your code from github ...
>> $ cd ../..
>> $ sh ./validate
>
> As I mention, it was on unchanged tree but this is how I'll do it when
> testing the changes.
>
>> But I'd like to make sure I know exactly what's going on. I can try
>> testing your branch later today.
>
> I think the original issue is now gone. I do get 8 unexpected failures
> and about 11000+ skipped tests! Is this normal? Should I be filing
> bugs? Should I create a separate thread? Can someone look at my log?
> You can download it from [1], it's about 8MB. If GHC itself compiles
> the test information into some files you'd prefer, please let me know,
> I simply redirected all output from the validate script into a log.
>
> [1]: http://fuuzetsu.co.uk/misc/validatelog
>
> --
> Mateusz K.
>



--
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

Reply | Threaded
Open this post in threaded view
|

Validating with Haddock

Mateusz Kowalczyk
On 07/01/14 18:21, Austin Seipp wrote:

> Yes, the skipped tests are normal. The testsuite has a concept of
> tests being built a certain 'way' - for example, you might test a
> piece of code by making sure it works compiled with -threaded,
> non-threaded, profiling, the LLVM backend, or any combination of
> those, etc. So a single *test* gives rise to multiple *test cases*.
>
> When you run validate, it runs it in a 'fast' mode by default as
> opposed to the slow mode. The fast mode only runs a subset of the
> overall test cases - it runs the most basic tests per file, which
> generally gives a pretty good indication as to what is going on.
>
> Also, the performance failures you're seeing are (I speculate) due to
> out of date performance numbers. Sometimes these numbers go up or down
> just due to code churn, but they're sometimes finnicky, because they
> may depend on the exact time a major GC happens or something. So a
> small wibble can cause them to sometimes occasionally fail.
>
> In any case, these results seem to indicate your branch looks quite
> OK, so I can try to merge this soon, if you think it is actually
> complete and ready.
>

These are the numbers from the clean tree. I will now merge in my
changes, validate again, run Haddock test suite and let you know how it
went. If I see similar results, I'll assume it's fine.

I greatly appreciate the help I've been getting on this thread.

@Simon H.
Do you think that the new features could be merged fairly soon too, if
the basic parser stuff checks out? Does anything extra need doing?


--
Mateusz K.

Reply | Threaded
Open this post in threaded view
|

Validating with Haddock

Austin Seipp-5
It's worth mentioning that Gergo's Pattern Synonym work lightly
touches Haddock as well, so perhaps it's worth ensuring nothing
conflicts there as well: https://github.com/gergoerdi/ghc-haddock -
I'm not sure which should be merged first (Gergo's patch has some
validate failures that need to be fixed up, so I imagine yours might
make it first.)

On Tue, Jan 7, 2014 at 12:39 PM, Mateusz Kowalczyk
<fuuzetsu at fuuzetsu.co.uk> wrote:

> On 07/01/14 18:21, Austin Seipp wrote:
>> Yes, the skipped tests are normal. The testsuite has a concept of
>> tests being built a certain 'way' - for example, you might test a
>> piece of code by making sure it works compiled with -threaded,
>> non-threaded, profiling, the LLVM backend, or any combination of
>> those, etc. So a single *test* gives rise to multiple *test cases*.
>>
>> When you run validate, it runs it in a 'fast' mode by default as
>> opposed to the slow mode. The fast mode only runs a subset of the
>> overall test cases - it runs the most basic tests per file, which
>> generally gives a pretty good indication as to what is going on.
>>
>> Also, the performance failures you're seeing are (I speculate) due to
>> out of date performance numbers. Sometimes these numbers go up or down
>> just due to code churn, but they're sometimes finnicky, because they
>> may depend on the exact time a major GC happens or something. So a
>> small wibble can cause them to sometimes occasionally fail.
>>
>> In any case, these results seem to indicate your branch looks quite
>> OK, so I can try to merge this soon, if you think it is actually
>> complete and ready.
>>
>
> These are the numbers from the clean tree. I will now merge in my
> changes, validate again, run Haddock test suite and let you know how it
> went. If I see similar results, I'll assume it's fine.
>
> I greatly appreciate the help I've been getting on this thread.
>
> @Simon H.
> Do you think that the new features could be merged fairly soon too, if
> the basic parser stuff checks out? Does anything extra need doing?
>
>
> --
> Mateusz K.
>



--
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

Reply | Threaded
Open this post in threaded view
|

Validating with Haddock

Ian Lynagh
In reply to this post by Mateusz Kowalczyk
On Tue, Jan 07, 2014 at 06:39:36PM +0000, Mateusz Kowalczyk wrote:
> On 07/01/14 18:21, Austin Seipp wrote:
> >
> > Also, the performance failures you're seeing are (I speculate) due to
> > out of date performance numbers. Sometimes these numbers go up or down
> > just due to code churn, but they're sometimes finnicky, because they
> > may depend on the exact time a major GC happens or something. So a
> > small wibble can cause them to sometimes occasionally fail.
>
> These are the numbers from the clean tree.

The haddock perf numbers look pretty bad, especially the
peak_megabytes_allocated:

=====> haddock.base(normal) 429 of 3855 [0, 0, 0]
peak_megabytes_allocated value is too high:
    Expected    peak_megabytes_allocated: 139 +/-1%
    Actual      peak_megabytes_allocated: 180

=====> haddock.Cabal(normal) 430 of 3855 [0, 1, 0]
peak_megabytes_allocated value is too high:
    Expected    peak_megabytes_allocated:  89 +/-1%
    Actual      peak_megabytes_allocated: 150

=====> haddock.compiler(normal) 431 of 3855 [0, 2, 0]
max_bytes_used value is too high:
    Expected    peak_megabytes_allocated: 663 +/-1%
    Actual      peak_megabytes_allocated: 794

I think it would be worth working out what's going on before merging
more haddock changes.


Thanks
Ian


Reply | Threaded
Open this post in threaded view
|

Validating with Haddock

Mateusz Kowalczyk
On 07/01/14 20:15, Ian Lynagh wrote:

> On Tue, Jan 07, 2014 at 06:39:36PM +0000, Mateusz Kowalczyk wrote:
>> On 07/01/14 18:21, Austin Seipp wrote:
>>>
>>> Also, the performance failures you're seeing are (I speculate) due to
>>> out of date performance numbers. Sometimes these numbers go up or down
>>> just due to code churn, but they're sometimes finnicky, because they
>>> may depend on the exact time a major GC happens or something. So a
>>> small wibble can cause them to sometimes occasionally fail.
>>
>> These are the numbers from the clean tree.
>
> The haddock perf numbers look pretty bad, especially the
> peak_megabytes_allocated:
>
> =====> haddock.base(normal) 429 of 3855 [0, 0, 0]
> peak_megabytes_allocated value is too high:
>     Expected    peak_megabytes_allocated: 139 +/-1%
>     Actual      peak_megabytes_allocated: 180
>
> =====> haddock.Cabal(normal) 430 of 3855 [0, 1, 0]
> peak_megabytes_allocated value is too high:
>     Expected    peak_megabytes_allocated:  89 +/-1%
>     Actual      peak_megabytes_allocated: 150
>
> =====> haddock.compiler(normal) 431 of 3855 [0, 2, 0]
> max_bytes_used value is too high:
>     Expected    peak_megabytes_allocated: 663 +/-1%
>     Actual      peak_megabytes_allocated: 794
>
> I think it would be worth working out what's going on before merging
> more haddock changes.
>
>
> Thanks
> Ian
>

Hi Ian,

Is there any guidance on how these tests are performed? More
importantly, is there any log of how the performance changed over time?
Is it Haddock's fault that it has become slower or is it the cause of
GHC changes?

PS: If there's no performance over time log, it might be worth
introducing something!
--
Mateusz K.

Reply | Threaded
Open this post in threaded view
|

Validating with Haddock

Austin Seipp-5
For the record and other people reading - after a quick discussion on
IRC, it simply looks like the 32-bit peak_megabytes_allocated numbers
for those tests probably weren't updated at the same time as the 64bit
ones, leaving them out of date.

On Tue, Jan 7, 2014 at 3:07 PM, Mateusz Kowalczyk
<fuuzetsu at fuuzetsu.co.uk> wrote:

> On 07/01/14 20:15, Ian Lynagh wrote:
>> On Tue, Jan 07, 2014 at 06:39:36PM +0000, Mateusz Kowalczyk wrote:
>>> On 07/01/14 18:21, Austin Seipp wrote:
>>>>
>>>> Also, the performance failures you're seeing are (I speculate) due to
>>>> out of date performance numbers. Sometimes these numbers go up or down
>>>> just due to code churn, but they're sometimes finnicky, because they
>>>> may depend on the exact time a major GC happens or something. So a
>>>> small wibble can cause them to sometimes occasionally fail.
>>>
>>> These are the numbers from the clean tree.
>>
>> The haddock perf numbers look pretty bad, especially the
>> peak_megabytes_allocated:
>>
>> =====> haddock.base(normal) 429 of 3855 [0, 0, 0]
>> peak_megabytes_allocated value is too high:
>>     Expected    peak_megabytes_allocated: 139 +/-1%
>>     Actual      peak_megabytes_allocated: 180
>>
>> =====> haddock.Cabal(normal) 430 of 3855 [0, 1, 0]
>> peak_megabytes_allocated value is too high:
>>     Expected    peak_megabytes_allocated:  89 +/-1%
>>     Actual      peak_megabytes_allocated: 150
>>
>> =====> haddock.compiler(normal) 431 of 3855 [0, 2, 0]
>> max_bytes_used value is too high:
>>     Expected    peak_megabytes_allocated: 663 +/-1%
>>     Actual      peak_megabytes_allocated: 794
>>
>> I think it would be worth working out what's going on before merging
>> more haddock changes.
>>
>>
>> Thanks
>> Ian
>>
>
> Hi Ian,
>
> Is there any guidance on how these tests are performed? More
> importantly, is there any log of how the performance changed over time?
> Is it Haddock's fault that it has become slower or is it the cause of
> GHC changes?
>
> PS: If there's no performance over time log, it might be worth
> introducing something!
> --
> Mateusz K.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



--
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

Reply | Threaded
Open this post in threaded view
|

Validating with Haddock

Mateusz Kowalczyk
On 07/01/14 21:20, Austin Seipp wrote:
> For the record and other people reading - after a quick discussion on
> IRC, it simply looks like the 32-bit peak_megabytes_allocated numbers
> for those tests probably weren't updated at the same time as the 64bit
> ones, leaving them out of date.
>

I have now validated GHC with the new Haddock stuff in place. You can
see the new log at [1]. The end result is the same as validation on a
tree without changes: same 8 tests failing.

I have also built and ran Haddock's own tests with HEAD and they now all
check out. The branch at [2] should now be ready to be merged into
upstream Haddock. If someone could merge that in, that'd be great. This
is the new parser which contains few bug fixes. We have more changes
than this which include user-visible features and new documentation.

I'll prepare and validate those for you tomorrow and bother you some more.

Let me know if anything needs changing.

Thanks!

[1]: http://fuuzetsu.co.uk/misc/validateloghaddock
[2]: https://github.com/sol/haddock/tree/new-parser

--
Mateusz K.

Reply | Threaded
Open this post in threaded view
|

Validating with Haddock

Austin Seipp-5
Excellent, thank you. We should really fix the 32bit performance
numbers too I think, based on what we discussed on IRC earlier. Would
you like to submit a patch for that too please? You can find the
numbers in testsuite/tests/perf/haddock/all.T.

Also, is there any new documentation we should need for this? Is all
the new stuff properly documented somewhere? Etc.

On Tue, Jan 7, 2014 at 6:20 PM, Mateusz Kowalczyk
<fuuzetsu at fuuzetsu.co.uk> wrote:

> On 07/01/14 21:20, Austin Seipp wrote:
>> For the record and other people reading - after a quick discussion on
>> IRC, it simply looks like the 32-bit peak_megabytes_allocated numbers
>> for those tests probably weren't updated at the same time as the 64bit
>> ones, leaving them out of date.
>>
>
> I have now validated GHC with the new Haddock stuff in place. You can
> see the new log at [1]. The end result is the same as validation on a
> tree without changes: same 8 tests failing.
>
> I have also built and ran Haddock's own tests with HEAD and they now all
> check out. The branch at [2] should now be ready to be merged into
> upstream Haddock. If someone could merge that in, that'd be great. This
> is the new parser which contains few bug fixes. We have more changes
> than this which include user-visible features and new documentation.
>
> I'll prepare and validate those for you tomorrow and bother you some more.
>
> Let me know if anything needs changing.
>
> Thanks!
>
> [1]: http://fuuzetsu.co.uk/misc/validateloghaddock
> [2]: https://github.com/sol/haddock/tree/new-parser
>
> --
> Mateusz K.
>



--
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

12