I'd be happy to mentor anyone on either of these. The CI part is going to
be grueling demotivatinal work with very long pauses in between, which is
why I didn't propose it yet.
I agree with John, that I'm a bit skeptical about a Student being able to
help/pull anything off in the current state
Yes, see
https://gitlab.haskell.org/ghc/ghc/-/wikis/Plan-for-increased-parallelism-and-more-detailed-intermediate-output
where we (Obsidian) and IOHK have been planning together.
I must saw, I am a bit skeptical about a GSOC being able to take this on
successfully. I thought Fendor did a
Yes there is also John resumable compilation ideas. And the current
performance work obsidian systems does.
On Sat, 13 Mar 2021 at 6:21 AM, Cheng Shao wrote:
> I believe Josh has already been working on 2 some time ago? cc'ing him
> to this thread.
>
> I'm personally in favor of 2 since it's
Thanks Richard
This MR is a huge change, and hard to digest. But it is also a step
function, in that we cannot have the old way of using API Annotations for
exact printing and the new way at the same time.
So I have focused on making sure that it can actually do what I believe is
required,
After a consult with Simon, I've updated the relevant wiki page at
https://gitlab.haskell.org/ghc/ghc/-/wikis/api-annotations with a sketch of a
design description for this new feature, along with lots of questions. Both
Simon and I agree that it may be more sensible to merge first and ask
I believe Josh has already been working on 2 some time ago? cc'ing him
to this thread.
I'm personally in favor of 2 since it's also super useful for
prototyping whole-program ghc backends, where one can just read all
the CgGuts from the .hi files, and get all codegen-related Core for
free.
Hi all,
This is following up on this recent discussion on the list concerning fat
interface files:
https://mail.haskell.org/pipermail/ghc-devs/2020-October/019324.html
Now that we have been accepted as a GSOC organisation, I think
it would be a good project idea for a sufficiently motivated
Ah, sorry, I thought it was just curiosity about what has changed.
I am not sure whether there will be future 8.10 releases; but you can open a
ticket asking Ben to backport the fix (which you have found) to 8.10, if there
is to be such a release.
Simon
| -Original Message-
| From:
On Fri, 12 Mar 2021, Simon Peyton Jones wrote:
I'm not sure... you could investigate, but I'm inclined just to declare victory!
That's easy for you to say, but here I am stuck with Stack not supporting
GHC 9.0... https://github.com/commercialhaskell/stack/issues/5486
| I wonder why that is? What changed between GHC 8.10.3 and 9.0.1? Was
| the definition of `elem` changed in `base`?
I'm not sure... you could investigate, but I'm inclined just to declare victory!
S
| -Original Message-
| From: ÉRDI Gergő
| Sent: 12 March 2021 10:02
| To: Simon
On Fri, 12 Mar 2021, ÉRDI Gergő wrote:
I wonder why that is? What changed between GHC 8.10.3 and 9.0.1? Was the
definition of `elem` changed in `base`?
Oh, I've found this commit:
```
commit f10d11fa49fa9a7a506c4fdbdf86521c2a8d3495
Author: Andreas Klebinger
Date: Wed Jan 29 15:25:07 2020
On Thu, 11 Mar 2021, Simon Peyton Jones wrote:
With HEAD, and -O, I get the exact same (good code) for these two functions:
f x = any (x ==) [1, 5, 7::Int]
g x = elem x [2, 6, 9 :: Int]
Maybe this is fixed? If you think not, maybe open a ticket?
OK, so initially I tried it
12 matches
Mail list logo
