Re: Request for feedback: deriving strategies syntax

[Malcolm Wallace]

On 18 Aug 2016, at 06:34, Bardur Arantsson wrote:

> Not a native (British) English speaker, but I've consumed a *lot* of UK
> media over the last ~25-30 years and I can literally only recall having
> heard "bespoke" used *once* and that was in the term "bespoke suit"
> where you can sort-of guess its meaning from context. I believe this is
> also the only context in which it's actually really used in British
> English. (However, I'll let the native (British) English speakers chime
> in on that.)

"Bespoke" is a reasonably common British English word, used in all of the 
following phrases:

bespoke software
bespoke solution
bespoke furniture
bespoke kitchen
bespoke tailoring

The meaning is "specially and individually made for this client".  The opposite 
of standard, off-the-shelf, pre-packaged.  It implies the outcome was not 
automatable, even if the individual pieces being assembled were machine-cut.

"In the U.S., bespoke software is often called custom or custom-designed 
software." http://whatis.techtarget.com/definition/bespoke


Regards,
Malcolm

___
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

[Bardur Arantsson]

On 2016-08-12 20:31, Ryan Scott wrote:
> On the subject of alternative names, you may be interested in reading
> this section of the DerivingSyntax wiki page [2], which lists other
> names besides "bespoke" and "builtin" that have been tossed around as
> ideas. They include:
> 
> * magic
> * wiredin
> * standard
> * native
> * original
> * specialized
> 

Can we please just go with the obvious "builtin"? There's no need for
willful obscurity here.

Not a native (British) English speaker, but I've consumed a *lot* of UK
media over the last ~25-30 years and I can literally only recall having
heard "bespoke" used *once* and that was in the term "bespoke suit"
where you can sort-of guess its meaning from context. I believe this is
also the only context in which it's actually really used in British
English. (However, I'll let the native (British) English speakers chime
in on that.)

Regards,

___
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

[Richard Eisenberg]

> On Aug 12, 2016, at 2:31 PM, Ryan Scott  wrote:
> 
> I can understand your reaction to the word "bespoke". I certainly
> never use it in daily conversation, and it's only from Richard's
> assurance (and from consulting a dictionary) that I feel confident
> about using it in this context.

Oh dear. Please don't take my word for it. I (an American) do not use the word 
in my native lexicon but instead adopted it after living in England for several 
years. Would someone who uses this word natively (e.g., someone who has lived 
in England for more than several years) vouch for this usage?

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

Re: Suggesting RankNTypes for ill-formed types

[Richard Eisenberg]

I tend to agree with Oleg that suggesting `ScopedTypeVariables` may be more 
helpful to users, even though `ExplicitForAll` is more principled.

Richard

> On Aug 11, 2016, at 2:45 PM, Oleg Grenrus  wrote:
> 
> FWIW. Often when I encounter that error, I want `ScopedTypeVariables`,
> yet my code doesn’t always has the scoped type variable used.
> So even GHC could parse further and propose it to me, there isn’t anything 
> from to do it :(
> 
> I don’t know if many use /just/ `ExplicitForAll`...
> 
> - Oleg
> 
>> On 11 Aug 2016, at 20:30, Karolina Drobnik > > wrote:
>> 
>> Hello everyone,
>> 
>> I am working on my first ticket (#11669, linked below) 
>> and I have some doubts after a little bit of hacking.
>> 
>> There was a hint that an error message should be
>> changed from the one suggesting RankNTypes to ExplicitForall. 
>> In my opinion it would be quite confusing for the user, especially where
>> the type is ill-formed. A plain parse error should be shown here.
>> 
>> It is clear that it should be done in such a way after turning on one
>> of the extensions, but what about the situation where proposed
>> fix (suggesting RankNTypes/ExplicitForall) won't work?
>> We should be able to distinguish ill-formed type from the correct one,
>> even before the extension activation. To be honest - I don't know how to do 
>> it.
>> 
>> Additionally, I am not sure if we can assume that an user wants
>> to use arbitrary rank (which implies ExplicitForall) or just a forall 
>> keyword.
>> I am for the second one, but it is just my assumption.
>> 
>> And the last minor thing - a type formed in this way also rises an error
>> suggesting using RankNTypes (as we know that wouldn't solve the problem):
>> 
>> f :: a. -> Int
>> f = undefined
>> 
>> Maybe we could treat it as a typo (simple parse error) and propose
>> an extension activation only when forall was parsed earlier? 
>> That could be tricky.
>> 
>> I'd appreciate some thoughts on this issue because I felt a bit lost
>> after digging around the parser.
>> 
>> Best regards,
>> 
>> Karolina
>> -
>> #11669 - https://ghc.haskell.org/trac/ghc/ticket/11669 
>> 
>> ___
>> 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: Broken Build due to T1969

[Matthew Pickering]

Thanks for checking Omer. I reverted the patch for now and the build
is green. I'm not sure about the answers to your other questions, as
long as the build stays green then I don't mind :)

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

Back from move

[Ben Gamari]

Hello everyone!

If I have seemed quiet over the last few weeks it is because I was in
the middle of a trans-Atlantic move to the United States. Needless to
say, I am now somewhat settled again and will be working through my mail
backlog over the next day or so.

If you have sent something that you'd like a response from me on and I
don't reply within the next day don't hesitate to ping me.

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: Broken Build due to T1969

[Ömer Sinan Ağacan]

I can't reproduce it on my x86_64 Linux laptop when I boot GHC HEAD with GHC
7.10.2.

Anyway, feel free to revert 773e3aad (which disables the test) but I think
bumping the numbers a little bit is a better option here as that would at least
prevent things from getting worse.


I'm curious, does anyone know how much ram harbormaster has? I can't see from
the logs how many times GC is running during T1969, but maybe GC is running
less number of times which is causing the residency to increase.

I'm also wondering if there are more stable ways of testing residency. Can we
maybe do something like:

runMajorGC >> printResidency

In some specific locations in the compiler and only look for those in perf
tests? Or does anyone have any better ideas?

2016-08-17 18:05 GMT+00:00 Ömer Sinan Ağacan :
> Hmm, it seems to be a 64bit Linux. Interestingly peak_megabytes_allocated is
> also different than numbers I'm getting on my 64bit Linux laptop. Maybe this 
> is
> because harbormaster is booting with GHC 7.10.3 and I'm booting with GHC 
> 8.0.1.
> I'm currently validating with 7.10.3 to see if I'll get the same numbers.
>
> 2016-08-17 15:17 GMT+00:00 Matthew Pickering :
>> I am just seeing it on harbourmaster.
>>
>> https://phabricator.haskell.org/harbormaster/build/12730/?l=100
>>
>> Matt
>>
>>
>>
>> On Wed, Aug 17, 2016 at 3:59 PM, Ömer Sinan Ağacan  
>> wrote:
>>> Ugh. I validated that patch before committing and validated many times after
>>> that patch. Are you using a 32bit system? Maybe we should bump the numbers 
>>> for
>>> 32bit builds too.
>>>
>>> I'm hesitant to mark the test broken because I'm afraid that the numbers 
>>> will
>>> increase if we stop testing for allocations/residency completely. I think
>>> temporarily bumping numbers is better than temporarily disabling it.
>>>
>>> What are the numbers you're getting?
>>>
>>> 2016-08-17 14:16 GMT+00:00 Matthew Pickering :
 Hi all,

 https://phabricator.haskell.org/rGHC773e3aadac4bbee9a0173ebc90ffdc9458a2a3a9

 broke the build by re-enabling the test T1969

 The ticket tracking this is: https://ghc.haskell.org/trac/ghc/ticket/12437

 Omer: Is it best to revert this patch and mark the test broken again?

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

Re: Broken Build due to T1969

[Matthew Pickering]

I am just seeing it on harbourmaster.

https://phabricator.haskell.org/harbormaster/build/12730/?l=100

Matt



On Wed, Aug 17, 2016 at 3:59 PM, Ömer Sinan Ağacan  wrote:
> Ugh. I validated that patch before committing and validated many times after
> that patch. Are you using a 32bit system? Maybe we should bump the numbers for
> 32bit builds too.
>
> I'm hesitant to mark the test broken because I'm afraid that the numbers will
> increase if we stop testing for allocations/residency completely. I think
> temporarily bumping numbers is better than temporarily disabling it.
>
> What are the numbers you're getting?
>
> 2016-08-17 14:16 GMT+00:00 Matthew Pickering :
>> Hi all,
>>
>> https://phabricator.haskell.org/rGHC773e3aadac4bbee9a0173ebc90ffdc9458a2a3a9
>>
>> broke the build by re-enabling the test T1969
>>
>> The ticket tracking this is: https://ghc.haskell.org/trac/ghc/ticket/12437
>>
>> Omer: Is it best to revert this patch and mark the test broken again?
>>
>> Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Broken Build due to T1969

[Ömer Sinan Ağacan]

Ugh. I validated that patch before committing and validated many times after
that patch. Are you using a 32bit system? Maybe we should bump the numbers for
32bit builds too.

I'm hesitant to mark the test broken because I'm afraid that the numbers will
increase if we stop testing for allocations/residency completely. I think
temporarily bumping numbers is better than temporarily disabling it.

What are the numbers you're getting?

2016-08-17 14:16 GMT+00:00 Matthew Pickering :
> Hi all,
>
> https://phabricator.haskell.org/rGHC773e3aadac4bbee9a0173ebc90ffdc9458a2a3a9
>
> broke the build by re-enabling the test T1969
>
> The ticket tracking this is: https://ghc.haskell.org/trac/ghc/ticket/12437
>
> Omer: Is it best to revert this patch and mark the test broken again?
>
> Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

ghc command line arguments parsing

[Harendra Kumar]

Hi,

ghc accepts a flag and its argument as a single quoted or escaped argument
as well. For example all of the following are equivalent:

ghc -package foo
ghc "-package foo"
ghc -package\ foo

Is this by design or accidental?

This has a nice side effect to make passing ghc arguments via rughc simple.
For example runghc "-package foo" or runghc -package\ foo will pass
"-package foo" to ghc. The alternative and documented way to achieve the
same effect is runghc -package --ghc-arg=foo which is not that convenient.

My question is - can we rely on this way of parsing? If it is not by
design, does it make sense to legalize and therefore document this?

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

Broken Build due to T1969

[Matthew Pickering]

Hi all,

https://phabricator.haskell.org/rGHC773e3aadac4bbee9a0173ebc90ffdc9458a2a3a9

broke the build by re-enabling the test T1969

The ticket tracking this is: https://ghc.haskell.org/trac/ghc/ticket/12437

Omer: Is it best to revert this patch and mark the test broken again?

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