Re: download all of Hackage?

[Kostiantyn Rybnikov]

Stack tool has an option of a docker image with everything compiled. I
think they claim whole image is 8 or 10 GB, please check (and don't forget
that's with GHC and other tools inside).
14 вер. 2015 22:57 "Mike Izbicki"  пише:

> Does anyone know approximately how much disk space all of hackage
> takes up when compiled?  And about how long it takes to compile
> everything?
>
> On Mon, Sep 14, 2015 at 11:37 AM, John Wiegley 
> wrote:
> >> Brandon Allbery  writes:
> >
> >> There's hackage-mirror, but I note it says it mirrors to S3.
> >
> > It mirrors into a directory as well:
> >
> > hackage-mirror --from="http://hackage.haskell.org; --to="/some/dir"
> >
> > Further, it can incrementally update very quickly.
> >
> > John
> > ___
> > 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: SV: Abstract FilePath Proposal

[Kostiantyn Rybnikov]

Because new api already exists in libraries, but FilePath from base is
still being used, which makes things worse (now your programs have all
those conversions all over).

I like the idea with gradual deprecation warning, but it's not clear if
it's feasible to implement.
27 черв. 2015 12:33 Niklas Larsson metanik...@gmail.com пише:

 Hi!

 Instead of trying to minimally patch the existing API and still breaking
 loads of code, why not make a new API that doesn't have to compromise and
 depreciate the old one?

 Niklas
 --
 Från: Herbert Valerio Riedel h...@gnu.org
 Skickat: ‎2015-‎06-‎26 18:09
 Till: librar...@haskell.org; ghc-devs@haskell.org
 Ämne: Abstract FilePath Proposal

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hello *,

 What?
 =

 We (see From:  CC: headers) propose, plain and simple, to turn the
 currently defined type-synonym

   type FilePath = String

 into an abstract/opaque data type instead.

 Why/How/When?
 =

 For details (including motivation and a suggested transition scheme)
 please consult

   https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath



 Suggested discussion period: 4 weeks
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQIcBAEBAgAGBQJVjXkZAAoJELo8uj/+IrV0WXUP/0romoKazwLbQpaMAKgCNZon
 BsY8Di44w6rkbdBXoky0xZooII8LJJyQfexH0BLRYEVLZFy0+LB8XzpPt8Ekg526
 YlY4x0qFm9oiJbJDMqHUnb6z6Lr2KxzBcV37drTPbltUA+HB49DUVkkPbvHimpL2
 28SIyhAr4fN6fLpGcFAkv6Rcs0mkvnTp7vsC0HNyshmGi6qQ+C+eB4mklQzWOPcn
 koHZ2wtI8AJmyTdHKcXKAIFM0r+xl4MJ5445IvDjvIuGXZCzybXMw9Ss/4wSG3VN
 qSIJVEDGZXrBCc12fPxPEB0Bqx9MIVytjplXKIo8rFrk93h3at9t9kDM26z+9PZ5
 KYnEdjRKF4KL4j+3xqJDOEJT15GVRbGRRzb9A8xH0YIQ0S3Q3pt1PAfla1Hss75+
 NRQgfowZYryL9dfCkAj2XNfdQ+pUk25N3bNig11se+zjk2JO77QRM0u3GOYZ9+CU
 tSlwhtIMF32xnjgQyWE5yBBiEg3/Y+S+809tVaPseUEzkQJXMGq5TFxBrN6bj1Vm
 awr6QghThKjeoRwky5bmFn/gept/lbYN6VV5B6gNznGP5xgFrmvVtmjbQJBRMYCv
 aEUnrYqxkkbIddJjD5gl771/LWH4M2F1yBgJjfiZw2paEVAXKxEr327LsbOQaPdb
 HjIPRrJbVK9AABo4AZ/Y
 =lg0o
 -END PGP SIGNATURE-
 ___
 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: expanding type synonyms in error messages

[Kostiantyn Rybnikov]

Great, thanks for doing this! I'm afraid even if you succeed with patch we
would still need more real-world examples that show the need for this
feature, and I think this is separate from GHC tests, as they don't need to
be realistic, but of course please continue and hopefully more examples
will come.
19 черв. 2015 16:19 Ömer Sinan Ağacan omeraga...@gmail.com пише:

 Done: https://ghc.haskell.org/trac/ghc/ticket/10547

 2015-06-19 9:12 GMT-04:00 Richard Eisenberg e...@cis.upenn.edu:
  Don't forget to make a Feature Request on Trac (
 https://ghc.haskell.org/trac/ghc/newticket) with a link to the wiki page.
 Trac is really the only way things like this don't get lost.
 
  Thanks!
 
  Richard
 
 
  On Jun 19, 2015, at 9:07 AM, Ömer Sinan Ağacan omeraga...@gmail.com
 wrote:
 
  Great, thanks Kostiantyn! I'm looking for simple examples that we can
  add to GHC testsuite, if I find something I'll update the wiki page
  also.
 
  I made some progress on the patch, I think I can hopefully submit
  something this weekend for reviews.
 
  2015-06-19 5:16 GMT-04:00 Kostiantyn Rybnikov k...@k-bx.com:
  Created some initial wiki-page with just one example, will keep it in
 mind
  to add more as seen.
 
 
 https://wiki.haskell.org/Expanding_type_synonyms_in_error_messages_proposal
 
  On Fri, Jun 19, 2015 at 10:42 AM, Simon Peyton Jones 
 simo...@microsoft.com
  wrote:
 
  On this thread, a representative collection of *reproducible examples*
  with the actual error message and the desired one, would be
 tremendously
  helpful.  Lacking that, it’s hard to know where to begin.   (Creating
 the
  examples takes a bit of work, I know.)
 
 
 
  Start a wiki page!  Stuff in email threads gets lost
 
 
 
  Simon
 
 
 
  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
  Christopher Allen
  Sent: 19 June 2015 04:27
  To: Ömer Sinan Ağacan
  Cc: ghc-devs
  Subject: Re: expanding type synonyms in error messages
 
 
 
  Just to add my own +1, having this when working with streaming
 libraries
  (I've needed it less with lens, oddly) would be a tremendous help for
 people
  learning them I think. I think I've run into the same thing as
 Kostiantyn in
  the past.
 
 
 
  On Thu, Jun 18, 2015 at 9:42 PM, Ömer Sinan Ağacan 
 omeraga...@gmail.com
  wrote:
 
  It's good to see that I'm not the only one who wants this. I'm doing
  some GHC hacking nowadays and I'll give it a try.
 
 
  2015-06-18 4:41 GMT-04:00 Kostiantyn Rybnikov k...@k-bx.com:
  I wanted to add that synonym expansion would be especially helpful in
  error-messages like:
 
  Expected type: non-expanded, small type, like Producer a m ()
  Actual type: your type, like Proxy a a' b b' m v
 
  I would be glad if we could have an expansions enabling flag in GHC,
 and
  could consider turning it on by default if it will look good for
 that.
 
  16 черв. 2015 22:44 Richard Eisenberg e...@cis.upenn.edu пише:
 
  GHC tries hard to preserve type synonyms where possible, but of
 course,
  it
  can't preserve all of them. The general rule it tries to follow is:
  preserve
  vanilla type synonyms; expand type families. This is true both in
  expected
  types and actual types.
  If you have a case where you believe that GHC could preserve a type
  synonym in an expected type, submit a bug report. (Note that
 constraint
  synonyms are particularly hard to preserve!)
 
  It would be very easy to report both the synonym-preserving form and
  the
  expanded form in an error report, at the cost of making error
 reports
  even
  more verbose. You're welcome to submit a feature request, and this
  would
  likely make a good first patch to GHC if you want to get your hands
  dirty.
  I'd personally prefer the feature to be protected behind a flag (to
  avoid
  seeing that `String` expands to `[Char]` everywhere, for example),
 but
  others may feel differently here.
 
  Richard
 
  On Jun 16, 2015, at 11:20 AM, Ömer Sinan Ağacan 
 omeraga...@gmail.com
  wrote:
 
  Hi all,
 
  While working with complex types with lots of arguments etc. errors
  are
  becoming annoying very fast. For example, GHC prints errors in this
  way:
 
Expected type: type without any synonyms
  Actual type: type with synonyms
 
  Now I have to expand that synonym in my head to understand the
 error.
 
  I was wondering if implementing something like this is possible:
 
  In type error messages, GHC also prints types that are cleaned from
  type
  synonyms. Maybe something like this:
 
 Expected type: type1
(without synonyms): type1, synonyms are expanded
   Actual type: type2
(without synonyms): type2, synonyms are expanded
 
  If this is not always desirable for some reason, we can hide this
  behavior
  behind a flag.
 
  What do GHC devs think about this? Is this, in theory, possible to
  do?
  How hard
  would it be to implement this?
 
  Thanks.
  ___
  ghc-devs mailing list
  ghc-devs@haskell.org
  http

Re: expanding type synonyms in error messages

[Kostiantyn Rybnikov]

Created some initial wiki-page with just one example, will keep it in mind
to add more as seen.

https://wiki.haskell.org/Expanding_type_synonyms_in_error_messages_proposal

On Fri, Jun 19, 2015 at 10:42 AM, Simon Peyton Jones simo...@microsoft.com
wrote:

  On this thread, a representative collection of **reproducible* *examples**
 with the actual error message and the desired one, would be tremendously
 helpful.  Lacking that, it’s hard to know where to begin.   (Creating the
 examples takes a bit of work, I know.)



 Start a wiki page!  Stuff in email threads gets lost



 Simon



 *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of 
 *Christopher
 Allen
 *Sent:* 19 June 2015 04:27
 *To:* Ömer Sinan Ağacan
 *Cc:* ghc-devs
 *Subject:* Re: expanding type synonyms in error messages



 Just to add my own +1, having this when working with streaming libraries
 (I've needed it less with lens, oddly) would be a tremendous help for
 people learning them I think. I think I've run into the same thing as
 Kostiantyn in the past.



 On Thu, Jun 18, 2015 at 9:42 PM, Ömer Sinan Ağacan omeraga...@gmail.com
 wrote:

  It's good to see that I'm not the only one who wants this. I'm doing
 some GHC hacking nowadays and I'll give it a try.


 2015-06-18 4:41 GMT-04:00 Kostiantyn Rybnikov k...@k-bx.com:
  I wanted to add that synonym expansion would be especially helpful in
  error-messages like:
 
  Expected type: non-expanded, small type, like Producer a m ()
  Actual type: your type, like Proxy a a' b b' m v
 
  I would be glad if we could have an expansions enabling flag in GHC, and
  could consider turning it on by default if it will look good for that.
 
  16 черв. 2015 22:44 Richard Eisenberg e...@cis.upenn.edu пише:
 
  GHC tries hard to preserve type synonyms where possible, but of course,
 it
  can't preserve all of them. The general rule it tries to follow is:
 preserve
  vanilla type synonyms; expand type families. This is true both in
 expected
  types and actual types.
  If you have a case where you believe that GHC could preserve a type
  synonym in an expected type, submit a bug report. (Note that constraint
  synonyms are particularly hard to preserve!)
 
  It would be very easy to report both the synonym-preserving form and the
  expanded form in an error report, at the cost of making error reports
 even
  more verbose. You're welcome to submit a feature request, and this would
  likely make a good first patch to GHC if you want to get your hands
 dirty.
  I'd personally prefer the feature to be protected behind a flag (to
 avoid
  seeing that `String` expands to `[Char]` everywhere, for example), but
  others may feel differently here.
 
  Richard
 
  On Jun 16, 2015, at 11:20 AM, Ömer Sinan Ağacan omeraga...@gmail.com
  wrote:
 
   Hi all,
  
   While working with complex types with lots of arguments etc. errors
 are
   becoming annoying very fast. For example, GHC prints errors in this
 way:
  
  Expected type: type without any synonyms
Actual type: type with synonyms
  
   Now I have to expand that synonym in my head to understand the error.
  
   I was wondering if implementing something like this is possible:
  
   In type error messages, GHC also prints types that are cleaned from
 type
   synonyms. Maybe something like this:
  
   Expected type: type1
  (without synonyms): type1, synonyms are expanded
 Actual type: type2
  (without synonyms): type2, synonyms are expanded
  
   If this is not always desirable for some reason, we can hide this
   behavior
   behind a flag.
  
   What do GHC devs think about this? Is this, in theory, possible to do?
   How hard
   would it be to implement this?
  
   Thanks.
   ___
   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





 --

 Chris Allen

 Currently working on http://haskellbook.com

 ___
 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: expanding type synonyms in error messages

[Kostiantyn Rybnikov]

I wanted to add that synonym expansion would be especially helpful in
error-messages like:

Expected type: non-expanded, small type, like Producer a m ()
Actual type: your type, like Proxy a a' b b' m v

I would be glad if we could have an expansions enabling flag in GHC, and
could consider turning it on by default if it will look good for that.
16 черв. 2015 22:44 Richard Eisenberg e...@cis.upenn.edu пише:

 GHC tries hard to preserve type synonyms where possible, but of course, it
 can't preserve all of them. The general rule it tries to follow is:
 preserve vanilla type synonyms; expand type families. This is true both in
 expected types and actual types.
 If you have a case where you believe that GHC could preserve a type
 synonym in an expected type, submit a bug report. (Note that constraint
 synonyms are particularly hard to preserve!)

 It would be very easy to report both the synonym-preserving form and the
 expanded form in an error report, at the cost of making error reports even
 more verbose. You're welcome to submit a feature request, and this would
 likely make a good first patch to GHC if you want to get your hands dirty.
 I'd personally prefer the feature to be protected behind a flag (to avoid
 seeing that `String` expands to `[Char]` everywhere, for example), but
 others may feel differently here.

 Richard

 On Jun 16, 2015, at 11:20 AM, Ömer Sinan Ağacan omeraga...@gmail.com
 wrote:

  Hi all,
 
  While working with complex types with lots of arguments etc. errors are
  becoming annoying very fast. For example, GHC prints errors in this way:
 
 Expected type: type without any synonyms
   Actual type: type with synonyms
 
  Now I have to expand that synonym in my head to understand the error.
 
  I was wondering if implementing something like this is possible:
 
  In type error messages, GHC also prints types that are cleaned from type
  synonyms. Maybe something like this:
 
  Expected type: type1
 (without synonyms): type1, synonyms are expanded
Actual type: type2
 (without synonyms): type2, synonyms are expanded
 
  If this is not always desirable for some reason, we can hide this
 behavior
  behind a flag.
 
  What do GHC devs think about this? Is this, in theory, possible to do?
 How hard
  would it be to implement this?
 
  Thanks.
  ___
  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: Can we fix our Trac that doesn't lose new ticket text

[Kostiantyn Rybnikov]

Not related to issue, but generally for Firefox I suggest an addon Form
History Control (UI is not superb, but it does what it should do)
https://addons.mozilla.org/uk/firefox/addon/form-history-control/

For Chrome, Lazarus Form Recovery used to work, but I'm not sure it still
does, since it seemed abandoned.

On Fri, Apr 24, 2015 at 4:54 PM, Edward Z. Yang ezy...@mit.edu wrote:

 Steps to reproduce:

 1. Click New Ticket
 2. Type some text into the box
 3. Press Back in your browser
 4. Press Forward in your browser

 If you try this with an official Trac this doesn't happen, so either
 this was fixed in a new version, or we have a plugin installed which
 is causing this to happen.

 Current version of Trac is 1.0.5, we're currently running 1.0.1

 Thanks,
 Edward
 ___
 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: Trac is soul-extinguishingly slow

[Kostiantyn Rybnikov]

Hi.

I will soon (today or early tomorrow) get back to Herbert with two things:

- profiling instructions
- possible solution

Also, he mentioned today in irc that he's going to add a tmp fix by
restarting apache periodically, since problem starts after an hour of its
work (not sure if I was supposed to talk about this :)).
16 квіт. 2015 17:42 Richard Eisenberg e...@cis.upenn.edu пише:

 Trac is bac.

 But is there anything we can do to improve reliability?

 Thanks!
 Richard

 On Apr 16, 2015, at 10:19 AM, Richard Eisenberg e...@cis.upenn.edu wrote:

  Hi devs,
 
  Trac isn't working again. In an entirely unscientific study, 4 out of
 the last 5 sessions where I tried to access Trac, I was unable to.
 
  If ghc.haskell.org is getting slammed, is it possible to disconnect
 Trac from that name and instead just publish some IP address until we have
 things working better? (Apologies if that sentence doesn't make any sense
 at all. I've dealt very little with these sorts of issues.)
 
  Thanks,
  Richard
  ___
  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: GHC Trac down

[Kostiantyn Rybnikov]

Yes, we started conversation in #haskell-infrastructure channel now, thank
you.

On Tue, Apr 14, 2015 at 3:38 AM, Kim-Ee Yeoh k...@atamo.com wrote:


 On Mon, Apr 13, 2015 at 9:41 PM, Kostiantyn Rybnikov k...@k-bx.com
 wrote:

 I recall someone asked for volunteers to help with trac problems and
 optimization. If this is still valid, I'd volunteer to help. Who should I
 contact?


 Herbert Valerio Riedel did some work installing the new spam filter on
 trac. Perhaps you might start with him?

 -- Kim-Ee

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

Re: GHC Trac down

[Kostiantyn Rybnikov]

It's down (well, timeouts) currently also.

I recall someone asked for volunteers to help with trac problems and
optimization. If this is still valid, I'd volunteer to help. Who should I
contact?

Thanks.

On Mon, Apr 13, 2015 at 9:50 AM, Simon Peyton Jones simo...@microsoft.com
wrote:

  Is GHC’s Trac down again?  It’s not working for me.

 Simon

 ___
 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