Re: ZuriHac 2018 GHC DevOps track - Request for Contributions

[Niklas Hambüchen]

On 08/04/2018 15.01, Michal Terepeta wrote:
> I'd be happy to help. :) I know a bit about the backend (e.g., cmm level), 
> but it might be tricky to find there some smaller/self-contained projects 
> that would fit ZuriHac.

Hey Michal,

that's great. Is there a topic you would like to give a talk about, or a pet 
peeve task that you'd like to tick off with the help of new potential 
contributors in a hacking session?

Other topics that might be nice and that you might know about are "How do I add 
a new primop to GHC", handling all the way from the call on the Haskell side to 
emitting the code, or (if I remember that correctly) checking out that issue 
that GHC doesn't do certain optimisations yet (such as emitting 
less-than-full-word instructions e.g. for adding two Word8s, or lack of some 
strength reductions as in [1]).

> You've mentioned performance regression tests - maybe we could also work on 
> improving nofib?

For sure!
Shall we run a hacking session together where we let attendees work on both 
performance regression tests and nofib? It seems these two fit well together.

Niklas

[1]: 
https://stackoverflow.com/questions/23315001/maximizing-haskell-loop-performance-with-ghc/23322255#23322255


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

Re: ZuriHac 2018 GHC DevOps track - Request for Contributions

[Niklas Hambüchen]

Hey Ömer,

On 09/04/2018 06.56, Ömer Sinan Ağacan wrote:
> I'd also be happy to help. At the very least I can be around as a mentor, but
> if I can find a suitable hask I may also host a hacking session.

That's awesome!

Do you have a topic that you'd be especially interested in for running as a 
hacking session?

In case not, mentoring help would also be very appreciated for other hacking 
sessions.
The tentative topics we have right now are:

* Adding performance regressions tests
* Finding and fixing Hadrian issues
* Back-end/Codegen
* CI infrastructure
* General mentoring & working on any GHC topic

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

505 Error on https://www.haskell.org/ghc/license.html

[Joachim Breitner]

Hi,

on https://www.haskell.org/ghc/license.html I see

   500 Internal Server Error nginx

before and after the text. I don’t expect many people to look there,
but still ugly.

Cheers,
Joachim


-- 
Joachim Breitner
  m...@joachim-breitner.de
  http://www.joachim-breitner.de/


signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Cannot compute type fingerprint in plugin, kinds/types are mixed

[alice]

Hello again. I’m trying to make a function in a type-checking plugin that takes 
TyCoRep#Type and makes its fingerprint that matches `typeRepFingerprint 
(typeRep :: TypeRep (type))`. As I understood the type’s fingerprint is made in 
DsBinds#dsEvTypeable by generating a code that makes the fingerprint, so I 
can’t reuse functions which are already written.

My goal is to write a function that makes fingerprints of types which are not 
type variables such as Int, Maybe Int, ‘[Int] etc. So I tried to follow 
`mkTrCon` and `mkTrApp` style, and I think I managed to process simple types 
like Int, Maybe Int — right now I’m processing TyConApp only. But when I tried 
to make promoted data fingerprint like ‘[Int] I faced some problems. 

For example, for making `’Just Int` fingerprint first I have to compute 'Just 
fingerprint by computing  'Just tyCon’s and * fingerprints, then combining them 
into one fingerprint. Then I have to apply ‘Just to Int. But when I try to do 
something like that while type checking I cannot separate two cases that match 
runtime’s`TypeRep (a b)` (a representation for a type application) and `TypeRep 
a` (a representation for a type constructor) because they are represented by 
TyConApp. Also I can’t separate tyCon kinds and types for type application 
because they are merged into one list which is stored in `TyConApp _ 
[KindOrType]`. [KindOrType] list for `’Just Int` is `[*, Int]`. Is there any 
way to separate this two cases and kinds/types?

Probably there is an easier way to make this function? If not, does type 
fingerprint function seem possible to make?

Any help would be appreciated,

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

Re: 505 Error on https://www.haskell.org/ghc/license.html

[Ben Gamari]

Joachim Breitner  writes:

> Hi,
>
> on https://www.haskell.org/ghc/license.html I see
>
>500 Internal Server Error nginx
>
> before and after the text. I don’t expect many people to look there,
> but still ugly.
>
Fixed. Thanks for letting me know.

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: Cannot compute type fingerprint in plugin, kinds/types are mixed

[Nicolas Frisby]

Hi Alice.

I'm having trouble following your question -- I'm not familiar with the
internals of fingerprint generation.

But, have you scoured the compiler/typecheck/TcTypeable.hs file? It seems
likely to have similar logic to what you seem to be seeking.

HTH. -Nick

On Tue, May 22, 2018, 06:38 alice  wrote:

> Hello again. I’m trying to make a function in a type-checking plugin that
> takes TyCoRep#Type and makes its fingerprint that matches
> `typeRepFingerprint (typeRep :: TypeRep (type))`. As I understood the
> type’s fingerprint is made in DsBinds#dsEvTypeable by generating a code
> that makes the fingerprint, so I can’t reuse functions which are already
> written.
>
> My goal is to write a function that makes fingerprints of types which are
> not type variables such as Int, Maybe Int, ‘[Int] etc. So I tried to follow
> `mkTrCon` and `mkTrApp` style, and I think I managed to process simple
> types like Int, Maybe Int — right now I’m processing TyConApp only. But
> when I tried to make promoted data fingerprint like ‘[Int] I faced some
> problems.
>
> For example, for making `’Just Int` fingerprint first I have to compute
> 'Just fingerprint by computing  'Just tyCon’s and * fingerprints, then
> combining them into one fingerprint. Then I have to apply ‘Just to Int. But
> when I try to do something like that while type checking I cannot separate
> two cases that match runtime’s`TypeRep (a b)` (a representation for a type
> application) and `TypeRep a` (a representation for a type constructor)
> because they are represented by TyConApp. Also I can’t separate tyCon kinds
> and types for type application because they are merged into one list which
> is stored in `TyConApp _ [KindOrType]`. [KindOrType] list for `’Just Int`
> is `[*, Int]`. Is there any way to separate this two cases and kinds/types?
>
> Probably there is an easier way to make this function? If not, does type
> fingerprint function seem possible to make?
>
> Any help would be appreciated,
>
> Alice.
> ___
> 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: abi-depends field

[Edward Z. Yang]

The unexpected failures are benign; they are what you'd expect
with the fix.  I recommend accepting all of the changes.

Edward

Excerpts from Ben Gamari's message of 2018-05-21 09:09:13 -0400:
> Simon Peyton Jones via ghc-devs  writes:
> 
> > Hello, anyone?
> > At the moment I am doing a manual-diff on this batch of unexpected 
> > failures, which is jolly annoying.
> > Should we just revert some patch for now?
> >
> Sigh, this is due to 1cdc14f9c014f1a520638f7c0a01799ac6d104e6, which I
> applied as a bug-fix for 8.4.3. We likely ought to revert it if it is
> causing trouble.
> 
> Edward, do you know why GHC's testsuite might be triggering this warning?
> 
> Cheers,
> 
> - Ben
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: 8.6.1 status

[Phyx]

I think I'll have to punt my changes for 8.8.1,

The I/O manager is mostly working but it's taking some time to iron out
the. Corner cases and ensure the behavior is not different than what people
expect with mio even though the model is quite different.

I have 12 failing tests but each take me a reasonable amount of time to
diagnose and fix without breaking other things and I still need to optimize
it all and add networking support.

The linker patches require some more extensive testing so I don't want to
rush those through either.

At this point, both patches are huge so they would take a considerable
amount of time to review anyway so they wouldn't stand much of a chance
even if I put them up tomorrow.

Thanks,
Tamar

On Sat, May 19, 2018, 18:56 Ben Gamari  wrote:

> Ben Gamari  writes:
>
> > Hi everyone,
> >
> > As noted a few weeks ago, the 8.6.1 fork is quickly approaching.
> > Currently the plan is to cut the branch on Friday, 1 May 2018.
>
> Silly me; the above is supposed to read "Friday, 1 June 2018".
>
> Sorry for the confusion!
>
> 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: 8.6.1 status

[Levent Erkok]

I wish I can offer more than just a request, but the following bug:

  https://ghc.haskell.org/trac/ghc/ticket/15105

is rendering some oft-used packages on Macs unusable. (doctest being the
prime example in my case.)

It would truly be awesome if it was fixed in the next release.

-Levent.

On Tue, May 22, 2018 at 5:39 PM, Phyx  wrote:

> I think I'll have to punt my changes for 8.8.1,
>
> The I/O manager is mostly working but it's taking some time to iron out
> the. Corner cases and ensure the behavior is not different than what people
> expect with mio even though the model is quite different.
>
> I have 12 failing tests but each take me a reasonable amount of time to
> diagnose and fix without breaking other things and I still need to optimize
> it all and add networking support.
>
> The linker patches require some more extensive testing so I don't want to
> rush those through either.
>
> At this point, both patches are huge so they would take a considerable
> amount of time to review anyway so they wouldn't stand much of a chance
> even if I put them up tomorrow.
>
> Thanks,
> Tamar
>
> On Sat, May 19, 2018, 18:56 Ben Gamari  wrote:
>
>> Ben Gamari  writes:
>>
>> > Hi everyone,
>> >
>> > As noted a few weeks ago, the 8.6.1 fork is quickly approaching.
>> > Currently the plan is to cut the branch on Friday, 1 May 2018.
>>
>> Silly me; the above is supposed to read "Friday, 1 June 2018".
>>
>> Sorry for the confusion!
>>
>> 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
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: 8.6.1 status

[Ben Gamari]

Phyx  writes:

> I think I'll have to punt my changes for 8.8.1,
>
Sad but understandable. Good luck and let us know how things go!

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: Cannot compute type fingerprint in plugin, kinds/types are mixed

[alice]

Yes, I’ve looked through this file, but it seems to me that I can't use 
anything there in my function.

> 22 мая 2018 г., в 18:52, Nicolas Frisby  написал(а):
> 
> Hi Alice.
> 
> I'm having trouble following your question -- I'm not familiar with the 
> internals of fingerprint generation.
> 
> But, have you scoured the compiler/typecheck/TcTypeable.hs file? It seems 
> likely to have similar logic to what you seem to be seeking.
> 
> HTH. -Nick
> 
> On Tue, May 22, 2018, 06:38 alice  > wrote:
> Hello again. I’m trying to make a function in a type-checking plugin that 
> takes TyCoRep#Type and makes its fingerprint that matches `typeRepFingerprint 
> (typeRep :: TypeRep (type))`. As I understood the type’s fingerprint is made 
> in DsBinds#dsEvTypeable by generating a code that makes the fingerprint, so I 
> can’t reuse functions which are already written.
> 
> My goal is to write a function that makes fingerprints of types which are not 
> type variables such as Int, Maybe Int, ‘[Int] etc. So I tried to follow 
> `mkTrCon` and `mkTrApp` style, and I think I managed to process simple types 
> like Int, Maybe Int — right now I’m processing TyConApp only. But when I 
> tried to make promoted data fingerprint like ‘[Int] I faced some problems. 
> 
> For example, for making `’Just Int` fingerprint first I have to compute 'Just 
> fingerprint by computing  'Just tyCon’s and * fingerprints, then combining 
> them into one fingerprint. Then I have to apply ‘Just to Int. But when I try 
> to do something like that while type checking I cannot separate two cases 
> that match runtime’s`TypeRep (a b)` (a representation for a type application) 
> and `TypeRep a` (a representation for a type constructor) because they are 
> represented by TyConApp. Also I can’t separate tyCon kinds and types for type 
> application because they are merged into one list which is stored in 
> `TyConApp _ [KindOrType]`. [KindOrType] list for `’Just Int` is `[*, Int]`. 
> Is there any way to separate this two cases and kinds/types?
> 
> Probably there is an easier way to make this function? If not, does type 
> fingerprint function seem possible to make?
> 
> Any help would be appreciated,
> 
> Alice.
> ___
> 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