-
Notifications
You must be signed in to change notification settings - Fork 276
Chore: bump to lts-20.0 #3642
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Chore: bump to lts-20.0 #3642
Conversation
Superficial HLS test seems okay. I do have to open the package containing the definitions I want to jump to before I can jump to them, which seems kind of pointless, but I'm not sure it didn't already work that way. |
Reminder to create corresponding PR for enlil. |
stack.yaml
Outdated
- lsp-1.5.0.0 | ||
- lsp-types-1.5.0.0 | ||
- text-rope-0.2@sha256:53b9b4cef0b278b9c591cd4ca76543acacf64c9d1bfbc06d0d9a88960446d9a7,2087 | ||
commit: 3b26f1e6c279e9bb5cd052c34c852aa8f8cfa17e |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sanity check: did you ensure color renders properly in a Windows terminal, or what commit is this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm testing it, but it will take a while.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This commit is morally the same: the PR that we were pointing at was rebased by the author atop the latest main so it continues to build. The PR still isn't merged :/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh. Sorry for making you do all of that, but I understand now.
I too went looking for "what is commit d6c2643b0d5c19be7e440615c6f84d603d4bc648
?" when trying to fix compiler errors with haskeline
due to the bump, and I saw it in the history of the open PR we were depending on:
But I got the history wrong. Looks like the author was not just force-pushing over their PR to keep it atop the main branch, they changed the implementation, too.
Meanwhile @ChrisPenner (maybe independently) discovered that the original approach was correct, so pointed us at d6c2643b0d5c19be7e440615c6f84d603d4bc648
.
So I believe the correct move is to grab haskeline
master (since it builds), and revert haskell/haskeline@f827f10 on top of it (which is how d6c2643b0d5c19be7e440615c6f84d603d4bc648
came to be).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@aryairani I've updated this dependency. Now it's pointing at our unisonweb/haskeline
fork, branch lts-20.0
. The contents of the branch are just judah/haskeline
HEAD, plus this commit, which is equivalent to the previous commit we were using (although now rebased on top of judah/haskeline
HEAD, because the old commit didn't build against lts-20.0
).
Some confusion: we have a unison branch (the default branch) in our unisonweb/haskeline
fork, 7 commits ahead and 13 commits behind aryairiani/haskeline
. I first tried merging judah/haskeline
HEAD into this, but got a ton of conflicts. Is this branch just dead code at this point?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this branch just dead code at this point?
I would guess so.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
screenshot of 20dacc9 courtesy of @tarikozkanli
@@ -166,7 +166,7 @@ authorSuggestion :: P.Pretty P.ColorText | |||
authorSuggestion = | |||
P.newline | |||
<> P.lines | |||
[ P.wrap "📜 🪶 You might want to set up your author information next.", | |||
[ P.wrap "📜 You might want to set up your author information next.", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we not use the 🖊️ character anymore?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't tested on GHC 9.2.4. On GHC 9.0.2, no, which was weird. But I didn't investigate too closely because I thought putting two emojis in a row here was a mistake, anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should I try putting it back?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I dunno, I guess it's supposed to be writing on paper, not sure if the paper alone makes sense. @rlmark ? :)
Has anything changed on the points listed from the last time I attempted moving to 9.2?
It's okay if we decide that's not a priority, but we should consider it I think 😄, I use the case-splitting feature very often. |
I think it's mostly up to you then whether we upgrade now or later. Personally I've never gotten that feature to work with any hls. |
Current status is:
|
The windows prompt seems important, as for wingman, I'll miss the pattern splitting, but it wouldn't kill be me to go without it, copilot can help fill that gap I suppose. I tried out the GHC 9.2.4 build and I was hoping it would speed up GHC compile times on M1 more than it actually did, so that's a bummer, but still probably good to keep relatively up to date with GHC 👍🏼 |
For what it's worth, I'm hoping that these memory changes in GHC 9.2 will help address some memory issues in Unison Cloud related to the GHC runtime using way more memory than the allotted heap. |
This PR is old and dead, which is a shame. It's sometimes quite a lot of work to bump the LTS, and we are on quite an old GHC at this point, so it would be good to upgrade. I do sometimes wonder if it's worth it for our small team to support Windows. If even basic libraries like |
I agree that we should find a way to upgrade soon, the longer we wait the further behind we get. It's likely worth a week of off-sprint time to figure out the haskeline thing at this point. |
We do want to support Windows, but yeah agree that the situation is pretty ridiculous. |
@mitchellwrosen Ok, when I build this PR with - github: judah/haskeline
commit: d6c2643b0d5c19be7e440615c6f84d603d4bc648 (same as on trunk), then UCM works with
I confirmed that rebasing our preferred Happy Windows commit onto the latest Haskeline, and building that with the new LTS is no longer happy on Windows, so I guess something else broke in Haskeline that breaks the proposed-and-then-retracted fix from @. this was what you had done too that also didn't work back in December (20dacc9) I guess we should just use the commit we know, put it on a branch to satisfy #3945, and bump the bounds ourself? |
superseded by #4008 |
Overview
Redoing #3631, this time landing on GHC 9.2.4