Re: Gitlab workflow

[Elliot Cameron]

Could Marge change the target branch of an MR before merging it? Perhaps
this would convince GitLab to show the right info.

On Fri, Jul 5, 2019, 6:18 AM Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> |  You believe the one which marge posts telling you that the patch is
> |  merged, the commit it links to is on master so you can clearly see the
> |  patch has been committed.
>
> OK.  The earlier one, also from Marge, not the Discussion stream but
> rather in the panel at the top, says
>
> Closed by Marge Bot 8 hours ago
> The changes were not merged into master
>
> So that is an outright lie?   Yes it is closed, but contrary to the
> statement it _has_ been merged.
>
> It's unfortunate that this misleading display is right at top, in the
> summary material, while the truth (that it has been merged) is buried in
> the Discussion stream.
>
> Alas.  But thank you for clarifying.
>
> Is this something we can raise with the Gitlab folk?  It seems so
> egregiously wrong.
>
> Simon
>
>
> |  -Original Message-
> |  From: Matthew Pickering 
> |  Sent: 05 July 2019 10:55
> |  To: Simon Peyton Jones 
> |  Cc: ghc-devs 
> |  Subject: Re: Gitlab workflow
> |
> |  It's not possible to make the MR status merged and also have a reliable
> |  merge bot. We used to try to make the status merged but it caused too
> |  much instability.
> |
> |  Merge trains might eventually work but the current iteration is not
> |  suitable as it doesn't work with forks.
> |
> |  You believe the one which marge posts telling you that the patch is
> |  merged, the commit it links to is on master so you can clearly see the
> |  patch has been committed.
> |
> |  Matt
> |
> |  On Fri, Jul 5, 2019 at 10:43 AM Simon Peyton Jones
> |   wrote:
> |  >
> |  > |  No it is not possible due to the use of Marge to merge patches.
> |  > | Gitlab
> |  >
> |  > By "it" is not possible, you mean that it's not possible to make the
> MR
> |  status into "Merged". Worse, I think you are saying that some MRs will
> |  say "Merged" and some will say "Closed" in some random way depending on
> |  Marge batching.  Sigh.
> |  >
> |  > Maybe this will get better with Gitlab's new merge-train feature.
> |  >
> |  > Meanwhile, my original message also asked why the MR shows two
> |  contradictory messages about whether the MR has landed.  Is that also
> un-
> |  fixable?   And if so how do I figure out which one to believe?
> |  >
> |  > Thanks
> |  >
> |  > Simon
> |  >
> |  >
> |  >
> |  > |  -Original Message-
> |  > |  From: Matthew Pickering 
> |  > |  Sent: 05 July 2019 10:39
> |  > |  To: Simon Peyton Jones 
> |  > |  Cc: ghc-devs 
> |  > |  Subject: Re: Gitlab workflow
> |  > |
> |  > |  Hi Simon,
> |  > |
> |  > |  No it is not possible due to the use of Marge to merge patches.
> |  > | Gitlab  automatically chooses the merged status as follows:
> |  > |
> |  > |  Consider two MRs both which target HEAD.
> |  > |
> |  > |  MR 1: HEAD <- A
> |  > |  MR 2: HEAD <- B
> |  > |
> |  > |  Marge creates a batch which contains both MR 1 and MR 2. Once the
> |  > | batch  succeeds, firstly MR 1 is merged.
> |  > |
> |  > |  HEAD <- A
> |  > |
> |  > |  MR 1 is closed with the *merged* status because A was merged
> |  > | directly  into HEAD and it matches the state of MR 1.
> |  > |
> |  > |  Then patch B gets merged and now master looks like:
> |  > |
> |  > |  HEAD <- A <- B
> |  > |
> |  > |  MR 2 is closed with closed status because B was merged into master
> |  > | after  A, not directly onto HEAD (as the original MR was).
> |  > |
> |  > |  There is no option to change this status in the gitlab API.
> |  > |
> |  > |  Cheers,
> |  > |
> |  > |  Matt
> |  > |
> |  > |  On Fri, Jul 5, 2019 at 8:38 AM Simon Peyton Jones via ghc-devs
> |  > |  wrote:
> |  > |  >
> |  > |  > Ben
> |  > |  >
> |  > |  > Still trying to understand GitLab.  Look at MR 1352  >
> |  > | https://gitl  >
> |  > | ab.haskell.org
> %2Fghc%2Fghc%2Fmerge_requests%2F1352&data=02%7C01%
> |  > | 7C  >
> |  > | simonpj%40microsoft.com
> %7Ce03ba07f29c447c1252e08d7012c9b59%7C72f988b
> |  > | f8  >
> |  > | 6f141af91ab2d7cd011db47%7C1%7C0%7C636979163409361534&sdata=xZZiF
> |  > | zO  > CRNpEskjO1MVSONbDvug9dyGEQtaHHSpGeCk%3D&reserved=0
> |  > |  >
> |  > |  > It clearly says on the first page “The changes were not merged
> |  > | into  master”
> |  > |  > But lower down (at the end) it says “Merged in 80af...”
> |  > |  >
> |  > |  > What should I believe? Merged or not merged?
> |  > |  >
> |  > |  > Also
> |  > |  >
> |  > |  > It would be really helpful if a MR status, displayed prominently
> |  > | at the  top, had “Merged” as a status, not just “Closed”.  If I’m
> |  > | trying to check  if my has landed, and I see “Closed”, that could
> |  > | mean that someone has  (doubtless for good reasons) closed it
> |  > | manually, and that it will never  land.
> |  > |  >
> |  > |  > Would that be possible?
> |  > |  >
> |  > |  > Thanks
> |  > |  >
> |  > |  

Re: Guarded Impredicativity

[Elliot Cameron]

Sorry meant to reply all:

I ran into the error recently here:
https://github.com/monadfix/named/issues/24

trying to use a fun named arguments library. I can't immediately tell if
these changes to GHC are sufficient to help. This library is using a
newtype with phantom arguments.

On Fri, Jun 28, 2019, 8:20 AM Alejandro Serrano Mena 
wrote:

> No, up to now the only changes are in the type checking of applications
> and variables.
> However, I guess that it would be possible to give [| id |] the type Code
> (forall a. a -> a) with a explicit type signature (the system always allows
> impredicative instantiation is explicitly marked), but without the
> annotation it would the usual type forall a. Code (a -> a).
>
> El vie., 28 jun. 2019 a las 14:17, Matthew Pickering (<
> matthewtpicker...@gmail.com>) escribió:
>
>> Have you modified how typed quotations are type checked? For example,
>> with your patch I would hope that
>>
>> [| id |] :: Code (forall a . a -> a)
>>
>> would be accepted?
>>
>> I'll try it out. This patch will have big ramifications for the typed
>> template haskell community.
>>
>> Matt
>>
>> On Fri, Jun 28, 2019 at 1:12 PM Alejandro Serrano Mena
>>  wrote:
>> >
>> > Dear all,
>> >
>> > We are trying to bring back `ImpredicativeTypes` into GHC by using the
>> ideas in the "Guarded Impredicative Polymorphism" paper [
>> https://www.microsoft.com/en-us/research/publication/guarded-impredicative-polymorphism/
>> ].
>> >
>> > For now I have produced a first attempt, which lives in
>> https://gitlab.haskell.org/trupill/ghc. It would be great if those
>> interested in impredicative polymorphism could give it a try and see
>> whether it works as expected or not.
>> >
>> > The main idea behing "guarded impredicativity" is that you can infer an
>> impredicative instantiation for a type variable in a function call if you
>> have at least one given argument where that type variable appears under a
>> type constructor different from (->).
>> > For example, consider the call `(\x -> x) : ids`, where `ids :: [forall
>> a. a -> a]`. Since in the type of `(:)`, namely `forall a. a -> [a] ->
>> [a]`, the variable `a` appears under the `[]` constructor and that second
>> argument is given, we are allowed to instantiate `a := forall a. a -> a`.
>> On the other hand, if we try to do `ids <> ids`, where `(<>)` is monoid
>> concatenation with type `forall m. Monoid m => m -> m -> m`, we are forced
>> to instantiate `m` with a not-polymorphic type because at no point the
>> variable appears under a type constructor.
>> >
>> > Just for reference, the best to get a working clone is to follow these
>> steps:
>> > > git clone --recursive https://gitlab.haskell.org/ghc/ghc
>> impredicative-ghc
>> > > cd impredicative-ghc
>> > > git remote add trupill g...@gitlab.haskell.org:trupill/ghc.git
>> > > git fetch trupill
>> > > git checkout trupill master
>> >
>> > Thanks very much in advance,
>> > Alejandro
>> >
>> > ___
>> > 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: Spectre mitigation

[Elliot Cameron]

This may be relevant: https://support.google.com/faqs/answer/7625886

Note that both GCC and LLVM will be learning this Ratpoline technique.

On Thu, Jan 4, 2018 at 1:55 PM, Carter Schonwald  wrote:

> With the caveat of that I maybe have no clue what I’m talking about ;) :
>
> It’s a pretty epic attack/ side channel, but it still requires code
> execution.
>
> The kernel side channel more of an issue for vm providers
>
> And the spectre one probably will most heavily impact security conscious
> organizations that might be considering using tools like moby/ docker /
> Linux containers / kubernetes / mesos/ etc which depend on OS level process
> isolation etc for security.
>
> My fuzzy understanding is that one  fix would be hardware support for per
> process isolation of memory even in the context users / processes ... which
> isn’t in any kit afaik.
>
> I do like my code not being slow.  So it’s a dilemma :/
>
> On Thu, Jan 4, 2018 at 11:51 AM Thomas Jakway  wrote:
>
>> I'm gonna start reading through the spectre paper in a few minutes but...
>> is this really the death knell for speculative execution on x86/64...? If
>> so, GHC getting patched is going to be pretty low on everyone's list of
>> priorities.
>>
>> On Jan 4, 2018 6:36 AM, "Carter Schonwald" 
>> wrote:
>>
>>> The only impacted code is the code which should already be engineered to
>>> be  side channel resistant... which already need to be written in a way
>>> that has constant control flow and memory lookup.
>>>
>>> This is just a new and very powerful side channel attack.  It would be
>>> interesting and possibly useful to explore fascilities that enable marked
>>> pieces of code to be compiled in ways that improve side channel
>>> resistance.  But there’s so many different approaches that it’d be
>>> difficult to protect against all of them at once for general programs.
>>>
>>> I could be totally wrong, and I should read the spectre paper :)
>>>
>>> I guess I just mean that vulnerable Data should be hardened, but only
>>> when the cost makes sense.  Every security issue has some finite cost. The
>>> sum of those security events cost must be weighed against the sum of the
>>> costs of preventing them
>>>
>>> On Thu, Jan 4, 2018 at 9:08 AM Demi Obenour 
>>> wrote:
>>>
 The recent “Spectre” bug requires that speculative execution of
 indirect branches be disabled.  For GHC, this will require passing a flag
 to LLVM and fixing the NCG to emit suitable calling sequences.

 This will be a disaster for the STG execution model, because it
 disables CPU branch prediction for indirect calls and jumps.  This is a big
 argument in favor of doing a CPS→SSA conversion in the backend.
 ___
 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
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Removing core-spec.pdf from repository?

[Elliot Cameron]

The only loss is the ability to look at changes over time. If that's an
important feature, you could write the files with a commit hash in the
name. But that may not be worth it.

On Tue, Mar 14, 2017 at 4:38 AM, Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> It's very helpful to have a live, up to date PDF.  Not everyone has OTT,
> which is required to make it.  And OTT isn't available on Windows at all :-(
>
> Simon
>
> |  -Original Message-
> |  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Phil
> |  Ruffwind
> |  Sent: 14 March 2017 00:14
> |  To: ghc-devs@haskell.org
> |  Subject: Re: Removing core-spec.pdf from repository?
> |
> |  > I also dislike generated files in repos, but would like to point out
> |  > that there are a few pages out there that reference the link
> |  > https://github.com/ghc/ghc/blob/master/docs/core-spec/core-spec.pdf
> |  > directly; these would brake. But there is probably nothing we can
> |  > easily do about that.
> |
> |  Could replace it with a plain text file that says: "MOVED to
> |  https://XXX";
> |  The build system could then be tweaked to output the .pdf somewhere
> |  else so it would not overwrite this dummy file.
> |  ___
> |  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: Attempt at a real world benchmark

[Elliot Cameron]

I'd imagine that "opt-in" could even mean you have to install a separate
program/package to send data that's been collected. If it were very
separate from the compiler itself, would these security concerns still be a
problem? I for one would go through the effort of opting in since I want
the ecosystem to improve and I have the luxury not to be dealing with
high-security code bases.
ᐧ

On Fri, Dec 9, 2016 at 4:48 PM, George Colpitts 
wrote:

> I would opt-in. I also agree with Simon that privacy is no longer a big
> deal although I do believe that most companies do telemetry with an opt in
> policy. If it's opt-in why would anyone have a problem with telemetry?
>
> On Fri, Dec 9, 2016 at 1:46 PM Tom Murphy  wrote:
>
>> On Fri, Dec 9, 2016 at 4:50 AM, Simon Peyton Jones via ghc-devs <
>> ghc-devs@haskell.org> wrote:
>>
>> I have wanted telemetry for years.  ("Telemetry" is the term Microsoft,
>> and I think others, use for the phone-home feature.)
>>
>> It would tell us how many people are using GHC; currently I have
>> literally no idea.
>>
>>
>> In practice I think the best data we could get is "how many people are
>> using GHC && are willing to opt into phone-home," which seems like a
>> rougher number than e.g. downloads of ghc/HP or number of downloads of
>> base/containers or something similar. I also would not opt in.
>>
>> Tom
>> ___
>> 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: Testsuite and Python 3

[Elliot Cameron]

The Python community is heavily pushing to get Python 2 out of normal use,
so the only reason I can imagine of trying to maintain Python 2
compatibility is if people have written scripts atop GHC's test suites. I
sort of doubt that's common.
ᐧ

On Wed, Nov 30, 2016 at 2:46 PM, Ben Gamari  wrote:

> Hello everyone,
>
> Note that yesterday I flipped the switch in the build system to use the
> Python 3 interpreter by default when invoking the testsuite driver. The
> motivation for this is the fact that Python 2.7 is quite buggy on
> Windows, which resulted in spurious testsuite failures (see #12554).
>
> The question remains, however, of how much we care to preserve
> compatibility with Python 2. From what little I've seen so far I think
> it would be easier for everyone involved if we just let Python 2 pass
> into the sunset. Afterall, Python 3 is no less available than 2 at this
> point. Thoughts?
>
> 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: Allow top-level shadowing for imported names?

[Elliot Cameron]

I second Herbert's concern. Giving semantics to import order is one of the
greatest plagues of C, C++, Python, etc. It is worth avoiding at all costs.
Herbert's suggestion re: explicitly enumerated names seems to hold promise,
however.

On Tue, Oct 4, 2016 at 7:50 AM, Herbert Valerio Riedel 
wrote:

> Hi,
>
> On 2016-10-04 at 13:12:54 +0200, Yuras Shumovich wrote:
> > On Tue, 2016-10-04 at 04:48 -0400, Edward Kmett wrote:
> >
> >> It makes additions of names to libraries far less brittle. You can
> >> add a
> >> new export with a mere minor version bump, and many of the situations
> >> where
> >> that causes breakage can be fixed by this simple rule change.
> >
> > It would be true only if we also allow imports to shadow each other.
> > Otherwise there will be a big chance for name clash yet.
> >
> > Can we generalize the proposal such that subsequent imports shadow
> > preceding ones?
>
> IMO, that would be lead to fragile situations with hard to detect/debug
> problems unless you take warnings serious.
>
> With the original proposal, the semantics of your code doesn't change if
> a library starts exposing a name it didn't before. There is a clear
> priority of what shadows what.
>
> However, when we allow the ordering of import statements to affect
> shadowing, it gets more brittle and surprising imho:
>
> For one, we have tooling which happily reorders/reformats import
> statements which would need to be made aware that the reordering
> symmetry has been broken.
>
> Moreover, now we get into the situation that if in
>
>   import Foo -- exports performCreditCardTransaction
>   import Bar
>
>   main = do
>  -- ..
>  performCreditCardTransaction ccNumber
>  --
>
> 'Bar' suddenly starts exporting performCreditCardTransaction as well
> (and doing something sinister with the ccNumber before handing it over
> to the real performCreditCardTransaction...), it can effectively change
> the semantics of a program and this would merely emit a warning which
> imho rather deserves to be a hard error.
>
> However, iirc there is a different idea to address this without breaking
> reordering-symmetry, e.g. by allowing explicitly enumerated names as in
>
>   import Foo (performCreditCardTransaction)
>   import Bar
>
> to shadow imports from other modules which didn't explicitly name the
> same import; effectively introducing a higher-priority scope for names
> imported explicitly.
>
> > In that case you may e.g. list local modules after libraries' modules,
> > and be sure new identifies in libraries will not clash with local
> > ones. Obviously shadowing should be a warning still.
>
> ___
> 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: Request for feedback: deriving strategies syntax

[Elliot Cameron]

With the "stock option" might I also suggest "OEM"? ;)

+1 stock

On Tue, Sep 27, 2016 at 10:06 PM, Richard Eisenberg 
wrote:

> +1 on `stock` from me. Though I was all excited to get my class next
> semester jazzed for PL work by explaining that I had slipped a new keyword
> `bespoke` into a language. :)
>
> Richard
>
> On Sep 27, 2016, at 7:55 PM, Ryan Scott  wrote:
>
> > This wouldn't eat up Stock as a data type or type classes  or stock in
> any other syntactic context right?
>
> A valid concern! Rest assured, you'd still be able to use "stock" as, say,
> a variable in a function, since GHC's parser has a production just for IDs
> that have meanings in special contexts. (If you want to win at Haskell
> trivia night, the current special IDs are "as", "qualified", "hiding",
> "export", "label", "dynamic", "stdcall", "ccall", "capi", "prim",
> "javascript", and "group" [1]). In my implementation, I make "stock" and
> "anyclass" special IDs, so they only become keywords when used after
> "deriving".
>
> Ryan S.
> -
> [1] http://git.haskell.org/ghc.git/blob/f897b7427a4804e3285144f5767657
> 4d338be1f5:/compiler/parser/Parser.y#l3054
> [2]
>
> On Wed, Sep 28, 2016 at 8:49 AM, Carter Schonwald <
> carter.schonw...@gmail.com> wrote:
>
>> This wouldn't eat up Stock as a data type or type classes  or stock in
>> any other syntactic context right?
>>
>> While this term in the finance context hasn't come up in my own work this
>> past year, just want to make sure it won't eat a key word piece of name
>> space in value or types land
>>
>> Otherwise : standard or stock all sound good to me.
>>
>> On Sep 27, 2016 7:14 PM, "Ryan Scott"  wrote:
>>
>>> Sorry to keep changing my mind on this topic, but I'd like to make one
>>> last alternate suggestion, which I think surpasses all the previous ones.
>>> Joachim proposed that what was called "bespoke", "standard", or "builtin"
>>> in the past be called "stock" instead [1]. I like this idea since:
>>>
>>> 1. "Stock" is a short, instantly recognizable English word, no matter
>>> where you live (I think).
>>> 2. It conveys the right meaning, as "stock" indicates something
>>> straightforward or normal (in contrast to GND and DAC, which do something a
>>> bit more novel). "Stock" has other meanings, but in this context I believe
>>> it's clear what it indicates.
>>> 3. It doesn't have the disadvantages of the other suggestions. Besides
>>> the points already covered, Joachim noted that "bespoke" has connotations
>>> of giving instances that would be tailor-fit for a datatype (e.g., "ignore
>>> field x in the Eq instance, because it is just a cached value that depends
>>> on the other"), when in reality, the strategy is far more mechanical than
>>> that!
>>>
>>> Thoughts?
>>>
>>> Ryan S.
>>> -
>>> [1] https://ghc.haskell.org/trac/ghc/ticket/10598?replyto=50#comment:50
>>>
>>> On Fri, Aug 26, 2016 at 4:49 AM, Ryan Scott 
>>> wrote:
>>>
 Hello, everyone! Sorry for not being able to respond to some of the
 recent feedback.

 Well, it seems I'm at a bit of an impasse again. I originally changed
 "builtin" to "bespoke" because enough GHC devs voiced their
 displeasure (ranging from moderate to severe) with "builtin". I hoped
 that choosing "bespoke" would strike a happy medium where we could
 have a term that (1) reasonably describes its intended purpose, (2)
 wouldn't be highly misleading upon an initial glance, and (3) wouldn't
 be too off-putting to use as a reserved keyword.

 Unfortunately, I over-estimated how well "bespoke" meets criterion 3,
 since several people have _also_ voiced their displeasure with it!
 (Again, ranging from moderate to severe.) So we're back to square one,
 it seems. I don't want to push this patch without a general feeling of
 community consensus, but the patch is complete after all, with the
 exception of bikeshedding, so I'd like to try and come up with a
 colo(u)r that folks will be happy with so we can proceed and I can
 work on other things that need this feature.

 So, instead of "builtin" and "bespoke", I propose reconsidering an
 earlier suggestion of Elliot Cameron's: "standard". I had previously
 expressed reservations about "standard" before, since I felt it might
 be miscontrued as meaning "a Haskell standard" (e.g., the Haskell
 Report). But upon further thought, I have actually come to like the
 word "standard". Here's why:

 1. It's simple. "Standard" is recognizable whether you speak American
 English, British English, or pretty much any other variant that I'm
 aware of.
 2. It has precedent. A GHC error message already uses the phrase
 "standard derivable classes" to refer to Eq, Ord, Functor, etc. If we
 adopt "standard" as our keyword, then we could endow this phrase with
 a more precise meaning.
 3. It reflects history. This deriving strategy (that I'm proposing to
 name "standard")

Re: Notes from Ben's "contribute to ghc" discussion

[Elliot Cameron]

Oh how the chatroom hath slain its thousands, and email its ten thousands!
Flattening real, hard-working, deep-thinking people into a few paragraphs
of letters does such injustice to propinquity that it's a wonder it ever
works at all!

It's for that very reason I want to voice my approval of the idea of
mentors. The thing that IRC cannot give you is a (real) name and a real
face. The true fabric underlying any process or system is the people that
make it happen. If the relationships of the people are broken, no virtual
system will ever be able to recover the loss. I can't help but believe that
the best way to improve the community of contributors is to improve the
relationships of the people in it. Therefore, having a process of providing
mentorship could be the most effective way to address the myriad technical
difficulties of contributing to GHC. Love covers a multitude of wrongs. A
friendly helper could easily make up for the technical infelicities or
inexperience. In the long term, the improved strength of community could
begin to address any technical issues as well.

That said, I am not sure if mentorship is a burden the current "in-crowd"
would be able to bear. But even with minimal hand-holding the improvement
to propinquity could have significant effect.

Lastly, as one who is building his business, in part, on the advantage of
Haskell, I want to express my deep gratitude to both sides of the debate.
Chris, your efforts to improve the "on-boarding" process are truly
herculean and a massive investment to the community. Thank you! Matthew,
and other core devs, your hard work and world-class insight make Haskell
the technology that it is today and I cannot thank you enough.

Elliot Cameron

On Sun, Sep 25, 2016 at 4:35 AM, Matthew Pickering <
matthewtpicker...@gmail.com> wrote:

> If we loop this discussion back to the original post. There is a
> suggestion in there which seems to be what you are looking for.
>
> >  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”.
>
> It is also probably lost that I said there was a phabricator module
> 'ponder' which gives this kind of functionality so it should be quick
> and easy to setup.
>
> Matt
>
> On Sun, Sep 25, 2016 at 9:23 AM, Harendra Kumar
>  wrote:
> >
> >
> > On 25 September 2016 at 12:48, Joachim Breitner <
> m...@joachim-breitner.de>
> > wrote:
> >>
> >> Hi,
> >>
> >> > It will be great to have something like that. Something that you
> >> > figure out digging at ghc trac wiki pages, mailing lists, google
> >> > search etc will be a few minutes job for a mentor. It may be a bit
> >> > taxing on the mentors but they can limit how many newbies they are
> >> > mentoring and also breed new mentors to keep the cycle going.
> >>
> >> I hope and assume that already now that every possible contributor who
> >> has questions like this and asks (e.g. on irc) will get a helpful
> >> answer. Is that insufficient?
> >
> >
> > Maybe. Though irc seems to be quite popular among Haskell community and
> > other open source communities I have never been able to utilize it
> somehow.
> > I don't know if there is something wrong with it or with me. I installed
> an
> > irc client logged into it once or twice but never got hooked to it. Such
> > questions on ghc-devs maybe a nuisance for a lot of other people or at
> least
> > that's what I felt as a newbie. I usually tend to do a lot of homework
> > before sending a question to ghc-devs. Maybe a ghc-newbies like mailing
> list
> > (one more list!) can give the impression of a lower barrier for sending
> > stupid or operational questions.
> >
> > -harendra
> >
> > ___
> > 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: Custom warning suppression

[Elliot Cameron]

I would love this. Especially if we then added "partial" warnings to the
many Prelude/base functions that fit this description.

On Wed, Sep 7, 2016 at 11:09 AM, Richard Eisenberg 
wrote:

> Seems reasonable and useful to me. Is this a good use of the process here?
> https://github.com/ghc-proposals/ghc-proposals
>
> On Sep 7, 2016, at 10: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
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Request for feedback: deriving strategies syntax

[Elliot Cameron]

Given the prevalence of spellings like "normalise" in common Haskell
packages, we might just be settling on British English. Being American
makes that a tad difficult on my end, but personally I can make peace with
it.

On Thu, Aug 18, 2016 at 3:19 PM, Matthew Pickering <
matthewtpicker...@gmail.com> wrote:

> I also like 'bespoke' but then it seems to be a much more common in
> British English than American English.
>
> On Thu, Aug 18, 2016 at 7:46 PM, Ryan Scott 
> wrote:
> > Bardur,
> >
> > Since you don't like "bespoke", would you mind suggesting an
> > alternative, or advocating for a previously mentioned idea? From [1],
> > the ideas I've seen tossed around are:
> >
> > * builtin
> > * standard (Elliot Cameron suggested it here [2])
> > * wiredin (Cater Schonwald suggested it here [3])
> > * magic (Andres Löh suggested it here [4])
> > * native
> > * original
> > * specialized (the above three are ad hoc suggestions I came up with in
> a hurry)
> >
> > Ryan S.
> > -
> > [1] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/
> DerivingStrategies#Alternativesyntax
> > [2] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012448.html
> > [3] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012450.html
> > [4] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012453.html
> > ___
> > 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: Request for feedback: deriving strategies syntax

[Elliot Cameron]

Just a quick thought: The term "built-in" seems a bit myopic IMO since all
these extensions are in a sense built-in, and especially if any of them
make it into Haskell 2020. I wonder if "standard" would be better or
something similar.

On Jul 17, 2016 08:57, "Ryan Scott"  wrote:

> Ben,
>
> > I think it would be a great idea. That being said, given that it's not
> > be approved yet, I'm in no position to require it. Ryan, I'll leave this
> > call up to you. If you would like to write up a proposal using the
> > template in the repository then by all means let's give it a try.
> > If not, then no worries; we can continue here.
>
> I hadn't thought of using ghc-proposals for this, and since it's still
> in a nascent state, I'll opt to continue using the GHC devs mailing
> list for this dicussion.
>
>
> Alexey,
>
> > I can't see how this doesn't require changes to Template Haskell.
>
> You are correct, I got my wires crossed when trying to recall the
> details. I think what I (sloppily) remembered was that in an earlier
> revision of https://phabricator.haskell.org/D2280, I had implemented a
> pragma-based approach that didn't require a language extension. But I
> now consider that a mistake, so I've introduced the
> -XDerivingStrategies extension, which should be required regardless of
> what syntax we decide to adopt.
>
> Ryan S.
>
> On Sun, Jul 17, 2016 at 6:36 AM, Ben Gamari  wrote:
> > Oleg Grenrus  writes:
> >
> >> Should we test drive https://github.com/ghc-proposals/ghc-proposals
> >>  on this proposal?
> >>
> > I think it would be a great idea. That being said, given that it's not
> > be approved yet, I'm in no position to require it. Ryan, I'll leave this
> > call up to you. If you would like to write up a proposal using the
> > template in the repository then by all means let's give it a try.
> > If not, then no worries; we can continue here.
> >
> > 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: Planning for the 7.12 release

[Elliot Cameron]

I'm going by my rather poor memory for this. Frankly, I don't really care where 
the option sits, as long as I don't need a separate build of GHC to avoid LGPL.

From: Ben Gamari 
Sent: Friday, August 28, 2015 5:48 AM
To: Elliot Cameron; GHC developers
Cc: Herbert Valerio Riedel
Subject: Re: Planning for the 7.12 release

Elliot Cameron  writes:

> I can't seem to find the exact trac ticket, but the ability to swap
> out "Integer" implementations at link time would be a huge relief on
> Windows, which suffers from various problems with dynamic linking. I
> believe it was originally slated for 7.12. Can someone find it? Here's
> what I did find:
> https://ghc.haskell.org/trac/ghc/wiki/ReplacingGMPNotes
>
> A related discussion:
> https://github.com/commercialhaskell/stack/issues/399
>
> As it stands, we've been trying hard to find good ways to provide
> custom GHC variants more easily to end users.
>
Hmm, interesting. I'm not sure how realistic it is to make this a
link-time option, however, considering that we may inline bindings from
whatever integer package we compile against into the user's program.

Herbert, do you have any thoughts on this?

Cheers,

- Ben

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

Re: Planning for the 7.12 release

[Elliot Cameron]

I can't seem to find the exact trac ticket, but the ability to swap out 
"Integer" implementations at link time would be a huge relief on Windows, which 
suffers from various problems with dynamic linking. I believe it was originally 
slated for 7.12. Can someone find it? Here's what I did find: 
https://ghc.haskell.org/trac/ghc/wiki/ReplacingGMPNotes

A related discussion: https://github.com/commercialhaskell/stack/issues/399

As it stands, we've been trying hard to find good ways to provide custom GHC 
variants more easily to end users.


From: ghc-devs  on behalf of Ben Gamari 

Sent: Thursday, August 27, 2015 11:38 AM
To: GHC developers
Subject: Planning for the 7.12 release

Hello everyone!

With the 7.10.1 release nearly six months behind us and 7.10.2 out of the
way, now is a good time to begin looking forward to 7.12. In keeping
with the typical release pace, we are aiming to have a release
candidate ready in mid-December 2015 and a final release in January
2016.

The items that that we currently believe have a good chance of making it
in to 7.12 are listed on the release status page [1], which I've
summarized below (in no particular order),


* Support for implicit parameters providing callstacks and source
  locations

* Support for wildcards in data and type family instances

* A new, type-indexed type representation, data TTypeRep (a :: k).

* Introduction of visible type application

* Support for reasoning about kind equalities

* Support for Injective Type Families

* Support for the Strict language extension

* Support for Overloaded Record Fields, allowing multiple uses of
  the same field name and a form of type-directed name resolution.

* A huge improvement to pattern matching (including much better
  coverage of GADTs)

* Backpack is chugging along; we have a new user-facing syntax which
  allows multiple modules to be defined a single file, and are
  hoping to release at least the ability to publish multiple "units"
  in a single Cabal file.

* Support for Applicative Do, allowing GHC to desugar do-notation to
  Applicative where possible.

* Improved DWARF based debugging support including backtraces from
  Haskell code

* An Improved LLVM Backend that ships with every major Tier 1 platform.


These items are a bit less certain but may make it in if the authors
push forward quickly enough,


* Support for Type Signature Sections, allowing you to write (:: ty)
  as a shorthand for (\x -> x :: ty).

* A (possible) overhaul of GHC's build system to use Shake instead
  of Make.

* A DEPRECATED pragma for exports


Is your pet project missing from this list? If you have a patch that you
believe is on-track to make it in for 7.12, please let us know.

Moreover, if you have an issue that you urgently need fixed in 7.12,
please express you interest on the appropriate ticket. User feedback
helps us immensely in figuring out how to best place our priorities.

Cheers,

- Ben


[1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.12.1
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Help Building GHC on Windows to avoid LGPL

[Elliot Cameron]

Thank you very much for the help.

So far I have been able to get a 32-bit build to finish, but it is unable to 
compile anything (I get incorrect register errors). I'll try option #2 that you 
suggested.

In the meantime, would anyone be willing to build 32-bit versions of 7.8.4 and 
7.10.1 using integer-simple (for Windows, of course)? Someone has already 
provided 64-bit builds for both of those releases.

It will take me some time to get the hang of this. Once I do, I can start 
building older and newer versions, although it seems (hopefully!) that the next 
release might not need this special treatment to get away from integer-gmp.

Elliot Cameron


-Original Message-
From: Edward Z. Yang [mailto:ezy...@mit.edu] 
Sent: Wednesday, July 1, 2015 12:52 AM
To: Elliot Cameron
Cc: ghc-devs@haskell.org
Subject: Re: Help Building GHC on Windows to avoid LGPL

Excerpts from Elliot Cameron's message of 2015-06-30 20:19:40 -0700:
> "inplace/bin/ghc-cabal.exe" check libraries/bytestring
> 'ghc-options: -O2' is rarely needed. Check that it is giving a real benefit 
> and not just imposing longer compile times on your users.
> libraries/bytestring/ghc.mk:4: recipe for target 
> 'libraries/bytestring/dist-install/package-data.mk' failed
> make[1]: *** [libraries/bytestring/dist-install/package-data.mk] Error 
> 1
> Makefile:71: recipe for target 'all' failed
> make: *** [all] Error 2

We fixed this error (it was ghc-cabal not being sufficiently updated to handle 
some new Cabal behavior) but I'm surprised your build is failing because of it, 
because 7.10.1's shipped Cabal should not be tickling this bug.

You have a few options:

1. Try again with a source distribution, since I suspect your
   submodules are not in order, or
2. Cherry pick 14652b519eca12411e92c28cd06de32612b0973a onto your
   branch, which fixes the bug.

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