Re: build fail with latest 8.1 sources

[Ben Gamari]

John Leo  writes:

> I just pulled again and picked up a more recent patch by Ben Gamari:
> https://github.com/ghc/ghc/commit/ca1b986074757efff755c33c7f9a62c7eae43c7f
>
> This seems to have fixed the problem.  The commit says 8 hours ago but for
> some reason I didn't pick it up 2 or 3 hours ago when I last pulled.
>
Right, sorry John, that was my fault. I bumped the template-haskell
version without bumping the bounds of the pacakges that depend upon it.
Yet another reason why no change is too small for CI :)

Cheers,

- Ben

> John
>
> On Sat, Nov 12, 2016 at 3:19 PM, John Leo  wrote:
>
>> That's exactly what I did--in fact clone a fresh GHC and try again, but no
>> luck.  I attached the full logs in my second message, which have the
>> details--let me know if the attachment is not readable.  Thanks very much
>> for your help.
>>
>> John
>>
>> On Sat, Nov 12, 2016 at 3:16 PM, Simon Peyton Jones > > wrote:
>>
>>> I’ve seen a very recent commit that mentioned bumping a TH bound.  Maybe
>>> pull, make clean and try again?
>>>
>>>
>>>
>>> Simon
>>>
>>>
>>>
>>> *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *John
>>> Leo
>>> *Sent:* 12 November 2016 22:48
>>> *To:* ghc-devs 
>>> *Subject:* build fail with latest 8.1 sources
>>>
>>>
>>>
>>> Hi everyone,
>>>
>>>
>>>
>>> I'm trying to build the latest 8.1 sources on a Mac running El Capitan.
>>> I'm getting an error I'd never seen before and wonder if anyone has any
>>> pointers of how I might fix things.  I blew away my GHC, re-cloned from
>>> github, reconfigured and I still get the same error.
>>>
>>>
>>>
>>> The following are the relevant output lines; the problem is that the
>>> template-haskell version doesn't seem to match.  I'm not sure whether this
>>> is coming from the template-haskell in 8.1 or in 8.0.1 (which I'm using to
>>> build 8.1), but checking the latter I have version 2.11.0.0 which I assume
>>> should be sufficient.
>>>
>>>
>>>
>>> John
>>>
>>>
>>>
>>> 
>>>
>>>
>>>
>>> Configuring ghc-pkg-6.9...
>>>
>>> Configuring ghc-8.1...
>>>
>>> ghc-cabal: Encountered missing dependencies:
>>>
>>> template-haskell ==2.11.* && ==2.12.0.0
>>>
>>> make[1]: *** [compiler/stage1/package-data.mk
>>> ]
>>> Error 1
>>>
>>> make[1]: *** Waiting for unfinished jobs
>>>
>>> make: *** [all] Error 2
>>>
>>>
>>>
>>> 
>>>
>>>
>>>
>>> internal-229:~/haskell/ghc> cabal update
>>>
>>> (git)-[master]
>>>
>>> Downloading the latest package list from hackage.haskell.org
>>> 
>>>
>>> Skipping download: local and remote files match.
>>>
>>> internal-229:~/haskell/ghc> cabal install template-haskell
>>>
>>> (git)-[master]
>>>
>>> Resolving dependencies...
>>>
>>> All the requested packages are already installed:
>>>
>>> template-haskell-2.11.0.0
>>>
>>> Use --reinstall if you want to reinstall anyway.
>>>
>>
>>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

OpenSearch with GHC manual

[Sylvain Henry]

Hi,

Search engines often reference old versions of the GHC user guide. For 
instance with Google and the request "ghc unboxed tuples" I get the 
manual for 7.0.3, 5.04.1 and 6.8.2 as first results. With DuckDuckGo I 
get 6.12.3 and then "latest" versions of the manual.


So I have made a custom search engine for the latest manual (using 
OpenSearch spec). You can install it from the following page: 
http://haskus.fr/ghc/index.html like any other search engine.


Sphinx supports automatic generation of OpenSearch spec: 
http://www.sphinx-doc.org/en/1.4.8/config.html#confval-html_use_opensearch

Maybe we should use this to make the search engine easier to find and use.

As a side note, would it be possible to have a nicer URI for the latest 
doc? Currently it is: 
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/index.html

Something like https://haskell.org/ghc/doc/index.html would be better IMO.

Sylvain

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Windows build broken -- again

[Ben Gamari]

Simon Peyton Jones via ghc-devs  writes:

> Sigh.  The Simon PJ Windows Buildbot reports
>
Yes, my apologies for this one. I'm currently in the process of getting
this one fixed in D2700. Unfortunately my own Windows machine is having
hardware issues so I progress has been a bit slow. I hope to have a
functional fix by the end of the day.

Cheers,

- Ben



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC pretty printer philosophy

[Alan & Kim Zimmerman]

Richard

Thanks for the support.  The major change in HsSyn since the pretty printer
was first written is that the parser now preserves parens in the original
source, which it did not used to, so this approach is now feasible.

And I am starting to bump into tests failing which require updating the
generic deriving code to add parens.

Alan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: data families syntax

[Harendra Kumar]

Answering my own question, which means I did not do enough research before
asking. I found two points that I missed earlier:

1) data families are open in contrast to value level functions i.e. you can
add more instances later on hence the family and instance keywords make
sense.

2) the syntax 'data family List :: * -> *' is actually already supported as
an alternative.

-harendra


On 13 November 2016 at 16:10, Harendra Kumar 
wrote:

> I am curious about why the data families syntax was chosen to be the way
> it is. For example a list can be defined as follows:
>
> data family List a
>
> data instance List Char = Empty | Cons Char (List Char)
>
> data instance List ()   = Count Int
>
>
> Instead why not define it as:
>
> data List :: * -> *
>
> data List Char = Empty | Cons Char (List Char)
>
> data List ()   = Count Int
>
>
> The latter form looks more intuitive and easy to remember to me since it
> is very similar to the way value level functions are defined (signature &
> pattern matching defs). Here we are just defining a type level function
> instead.
>
> -harendra
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

data families syntax

[Harendra Kumar]

I am curious about why the data families syntax was chosen to be the way it
is. For example a list can be defined as follows:

data family List a

data instance List Char = Empty | Cons Char (List Char)

data instance List ()   = Count Int


Instead why not define it as:

data List :: * -> *

data List Char = Empty | Cons Char (List Char)

data List ()   = Count Int


The latter form looks more intuitive and easy to remember to me since it is
very similar to the way value level functions are defined (signature &
pattern matching defs). Here we are just defining a type level function
instead.

-harendra
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs