Brendan Hansknecht (Jan 02 2025 at 17:32): Brendan Hansknecht (Jan 02 2025 at 17:32):What is the current plan for some of the incoming breaking changes:
I assume there is more with everything in flux, but I am not sure what all there is.
Brendan Hansknecht (Jan 02 2025 at 17:33):I personally would like to avoid blocking these changes as much as possible and enable developers to just work on new changes.
Brendan Hansknecht (Jan 02 2025 at 17:37):I think it would be reasonable to anchor the current roc on main (probably the version before backpassing removal?) and make a new release of all the platforms. After the releases, we could let roc fall stale for larger chunk of time to let in these many breaking changes. Rip the band-aids off. Delete old syntax, etc. Attempt to keep the latest main of core platforms updated with the latest main of roc, but don't do another release until there is some stabilization.
Sam Mohr (Jan 02 2025 at 17:40):Task can be removed at any time once basic-(webserver|cli|ssg) make proper releases out of their prereleases. I wouldn't worry about this one too much. The only question is how much grace period do we give to users
Sam Mohr (Jan 02 2025 at 17:43):Renaming builtins and removing space calling convention don't concern anything backend-related really, so we should be able to just let Roc stale for a day or two and coordinate those platform releases without being too worried that we'll hit a big snag
Sam Mohr (Jan 02 2025 at 17:44):The refcounting changes and C-ABI changes are what I'm expecting we'll need to take our time with, since Murphy's law means we'll probably hit some stupid bug
Sam Mohr (Jan 02 2025 at 17:44):While trying to migrate the platforms
Brendan Hansknecht (Jan 02 2025 at 17:44):current refcounting change is super basic and should be super easy to migrate. Just requires changing a single constant
Brendan Hansknecht (Jan 02 2025 at 17:45):Anything with atomic refcount in the future is adding a feature, so no breaking change
Brendan Hansknecht (Jan 02 2025 at 17:45):So maybe all of these bandaids could actually be ripped off and fixed in a few days.
Sam Mohr (Jan 02 2025 at 17:45):Okay, then yeah, throw that in with space-calling and renaming
Brendan Hansknecht (Jan 02 2025 at 17:45):eventual c-abi changes when I simplify llvm generation
This on the other hand I expect will hit many bugs
Sam Mohr (Jan 02 2025 at 17:46):I'm free all day Sunday to help with these
Sam Mohr (Jan 02 2025 at 17:46):We could probably prepare basic-(cli|webserver) PRs in advance for those three changes
Brendan Hansknecht (Jan 02 2025 at 17:48):Yeah, if we want, I think we could rip off all of these bandaids pretty easily before the next release.
I think that this still needs some bigger updates (like we haven't updated all the tests in the repo yet):
This is not ready yet and will likely be more buggy and slow of a change so can be worried about in the future.
Sam Mohr (Jan 02 2025 at 17:49):Sounds right to me
Brendan Hansknecht (Jan 02 2025 at 18:08):I guess we should delay remove task until after the next release of all platforms. Just in case anyone finds bugs with PI.
Sam Mohr (Jan 02 2025 at 18:08):That's a good plan
Brendan Hansknecht (Jan 02 2025 at 18:08):So I guess I think we should do the first 3 and cut a new release of all the platforms for PI and these changes.
Brendan Hansknecht (Jan 02 2025 at 18:09):is basic_ssg updated to PI?
Sam Mohr (Jan 02 2025 at 18:09):Yep, at the pre-release stage
Luke Boswell (Jan 02 2025 at 19:56):We never finished the hyper upgrade, that's blocking badic-ssg full release.
Luke Boswell (Jan 02 2025 at 19:58):Builtins to snake case or builtins to PNC? What are referring to here?
I had a plan to upgrade those in a non breaking way. The reason wasnt the platforms, I was more concerned about all the packages downstream.
But if we're talkign PNC that may be an issue anyway if its not backwards compatible
Sam Mohr (Jan 02 2025 at 20:00):I presume builtins to snake_case
Sam Mohr (Jan 02 2025 at 20:00):bullet point 1 is snake_case, bullet point 3 is PNC
Luke Boswell (Jan 02 2025 at 20:01):We've removed all basic-cli from the roc repo now.. so we can move forwards with breaking changes without a release of basic-cli to pass CI.
Brendan Hansknecht (Jan 02 2025 at 20:03):good to know
Luke Boswell (Jan 02 2025 at 20:06):I'm thinking we fixup any issues preventing us promoting the platforms to full release, and then do as you suggest and make lots of changes for a couple of weeks, keeping basic-cli and basic-webserver mostly in sync.
We can cut TESTING releases of roc instead of nightlies during this time so the platforms can pass CI.
^^ just my ideas based on the current CI pipelines, @Anton might have iseas
Brendan Hansknecht (Jan 02 2025 at 20:07):Sure. can first get the new PI releases out then look at these other breaking changes after.
Brendan Hansknecht (Jan 02 2025 at 20:08):Just means another breaking release in a few days to weeks (due to snake_case and refcounting change)
Anton (Jan 03 2025 at 10:48):I'm thinking we fixup any issues preventing us promoting the platforms to full release
What still needs to happen is:
Let's come back to this discussion after that's done.
Anton (Jan 03 2025 at 11:00):If you want to try out breaking changes with basic-cli/basic-ws I recommend making a branch on the roc repo and a PR on basic-cli/basic-ws and test it with nix like this
Anton (Jan 03 2025 at 14:42):This examples PR's feedback needs to be addressed
Going to do this now
Brendan Hansknecht (Jan 03 2025 at 15:06):Anton said:
I'm thinking we fixup any issues preventing us promoting the platforms to full release
What still needs to happen is:
- an upgrade guide that explains purity inference and how to upgrade your code.
- This examples PR's feedback needs to be addressed
- Set up roc agent so it can upgrade roc projects to basic-cli 0.18 . This should be a lot faster than manually updating all the exercism solutions.
Let's come back to this discussion after that's done.
I don't think we should block release and breaking changes on any of those.
Task will still be around after the release. Guides and updated examples can come after the release. I think we should get the PI releases out for platforms that are ready.
Brendan Hansknecht (Jan 03 2025 at 15:07):By adding too much into scope, we are blocking the roc repo from progressing.
Brendan Hansknecht (Jan 03 2025 at 15:09):Basic CLI and basic webserver are both ready to cut a release. I think we should just release them.
Brendan Hansknecht (Jan 03 2025 at 15:10):Then I think we should split the roc release into a separate testing and latest such that we can start rolling in the breaking changes.
Brendan Hansknecht (Jan 03 2025 at 15:30):I will not that we should block specifically removing task on:
Brendan Hansknecht (Jan 03 2025 at 15:30):But I don't think other breaking changes should be stuck due to that
Anton (Jan 03 2025 at 16:02):The examples PR is done. I'll be done with all the rest by tomorrow evening. I think we can agree that a one day delay does not warrant a thorough discussion?
Brendan Hansknecht (Jan 03 2025 at 16:12):Oh, :scream:
Brendan Hansknecht (Jan 03 2025 at 16:12):This is way faster than I realized
Brendan Hansknecht (Jan 03 2025 at 16:14):Carry on.
Brendan Hansknecht (Jan 03 2025 at 16:17):Luke Boswell said:
We never finished the hyper upgrade, that's blocking badic-ssg full release.
I forget where this was left off. Any summary. Anything you specifically need help with?
Also, is it just a musl build problem or a general problem?
jan kili (Jan 03 2025 at 18:31):I propose we slap a big warning message at the top of the tutorial that foundational syntax is in flux, with large-scale tutorial updates coming soon.
jan kili (Jan 03 2025 at 18:32):Maybe atop the repo's README, too
Sam Mohr (Jan 03 2025 at 18:32):That's a good idea
Sam Mohr (Jan 03 2025 at 18:33):Optionally redirect people here for questions
Joshua Warner (Jan 04 2025 at 04:29):Random thought: we could make the snake_case no longer a breaking change by inserting a pass that normalizes all lowercase identifiers to snake_case prior to canonicalization. (temporarily, I mean)
Then it won't really matter if the built-ins and all of the other roc code out there migrates all at the same time.
Sam Mohr (Jan 04 2025 at 05:17):Gonna try this right now
Anton (Jan 04 2025 at 09:19):We support both styles right now, so we don't to migrate everything all at once, but if it is easy to do this normalization go ahead.
Anton (Jan 04 2025 at 09:24):After upgrading things to purity inference I have to say I really like it. Being able to get rid of the new concept of Task makes a big difference for Roc. I like our drive for simplicity :heart:
Sam Mohr (Jan 04 2025 at 12:07):I have done the work to upgrade all builtins to snake_case using PNC in this PR: https://github.com/roc-lang/roc/pull/7463. I also added auto snake_case-conversion in the manner Joshua Warner suggested for an easier transition.
It's in draft because I'm getting an infinite hang right now. This happens even with the auto case-conversion removed, so I presumably failed to update something in the compiler when renaming everything
Sam Mohr (Jan 04 2025 at 12:08):If anyone has any advice on how to debug hangs in roc_load build.rs, I'd love to hear it. It's tricky to debug since build.rs files don't show stdout until they finish (e.g. crash), meaning standard print debugging is very arduous
Sam Mohr (Jan 04 2025 at 12:09):I'll probably go to bed soon, but I'll try to have this ready by the end of the weekend
Anton (Jan 04 2025 at 12:16):Perhaps cargo build -v or -vv or -vvv can help?
Anton (Jan 04 2025 at 12:16):but I'll try to have this ready by the end of the weekend
No worries
Anton (Jan 04 2025 at 12:18):Checking if it happens with a single thread may also be useful: cargo build -j 1. I recommend doing cargo build (multithreaded) first and then cargo build -j 1 so you don't have to wait super long
Sam Mohr (Jan 04 2025 at 12:18):Lol, I thought that -vvv wouldn't help, but it totally did
Sam Mohr (Jan 04 2025 at 12:18):[roc_load 0.0.1] cargo:rerun-if-changed=../builtins/roc/Bool.roc
[roc_load 0.0.1] cargo:rerun-if-changed=../builtins/roc/Dict.roc
[roc_load 0.0.1] thread '<unnamed>' panicked at crates/compiler/can/src/abilities.rs:501:9:
[roc_load 0.0.1] Replacing existing declared impl: (ImplKey { opaque: `Inspect.IdentId(34)`, ability_member: `Inspect.i16` }, Some(Impl(`Inspect.IdentId(53)`)))
Okay, the main issue is fixed, but there's a remaining problem: if we convert every ident to snake case, then FFI breaks when roc_fx_stdoutLine gets converted to roc_fx_stdout_line. I can't find a way to avoid doing that without making the case conversion logic a good deal more complicated, since the names of effects are normal camelCase. If we start discriminating on which ident is where in the code, we'll pollute the can code with temporary code. Updating all the necessary FFI-relevant code in the Roc repo is 147 files already.
Sam Mohr (Jan 04 2025 at 14:33):So I'm leaning towards us not doing the case conversion and us trying to find the right time to do the conversion instead
Sam Mohr (Jan 04 2025 at 14:33):Okay, I'm off to bed, everything's in the PR: https://github.com/roc-lang/roc/pull/7463
Brendan Hansknecht (Jan 04 2025 at 14:41):Sam Mohr said:
Okay, the main issue is fixed, but there's a remaining problem: if we convert every ident to snake case, then FFI breaks when
roc_fx_stdoutLinegets converted toroc_fx_stdout_line.
I really think we should stop worrying and just rip the band-aid off
Brendan Hansknecht (Jan 04 2025 at 14:41):Get rid of the old naming convention and start moving everything over
Brendan Hansknecht (Jan 04 2025 at 14:42):It can be done after the PI release, like removing task, but my refcount change also requires updates to all platforms and is a breaking change.
Sam Mohr (Jan 04 2025 at 14:43):All that needs doing in theory for this PR is to remove the snake case conversion and update tests. Then we can get PRs ready with snake case builtins for the platforms and let it all rip
Sam Mohr (Jan 04 2025 at 14:44):We could release without the platforms, but it'd be better for users to have working platforms continuously
Anton (Jan 04 2025 at 14:54):but it'd be better for users to have working platforms continuously
Yes, we want to avoid having broken tests on platforms for many days. The longer that lasts, the harder it can be to investigate and revert something that we can't fix.
Brendan Hansknecht (Jan 04 2025 at 14:55):Today, we have a working version of each core platform with PI. Why don't we cut releases and switch roc over to having a separate lastest and testing build. Then we can start getting these breaking changes in.
Brendan Hansknecht (Jan 04 2025 at 14:57):I don't think this is a blocking change for the release: https://github.com/roc-lang/basic-cli/pull/292
Anton (Jan 04 2025 at 14:58):basic-cli and basic-ws will be released today
Anton (Jan 04 2025 at 15:01):Then we can start getting these breaking changes in.
For me the important thing is that we don't; get in multiple breaking changes in a short time, hit complex issues, and it's a pain to revert things.
Anthony Bullard (Jan 04 2025 at 15:02):Anton said:
basic-cli and basic-ws will be released today
Are they going to be released with just PI, or with migrations for snake_case and PNC?
Anton (Jan 04 2025 at 15:02):upgrading basic-cli and basic-ws with a specific branch for each breaking change looks like it has great trade-offs
Anton (Jan 04 2025 at 15:02):PI and snake_case
Brendan Hansknecht (Jan 04 2025 at 15:09):For me the important thing is that we don't; get in multiple breaking changes in a short time
For me, I am much more concerned about:
camelCase to snake_case). It isn't guaranteed to always be correct and we have roc format --migrate for that already.snake_case but builtins still in camelCase).As long as there are no releases yet, reverts should not be that big of a deal.
Also, grouping breaking changes avoids needing tons of releases (which is inconvenient for us and for users).
Brendan Hansknecht (Jan 04 2025 at 15:12):We should have enough tests in the main roc repo to defend against most concerns of getting multiple breaking changes in back to back. If not, we need to keep working to expand test coverage. I think that "hit complex issues, and it's a pain to revert things" is a symptom and not a reason to slow down.
Brendan Hansknecht (Jan 04 2025 at 15:16):Anyway /rant over. Sorry if this is overly strong or frustrated. @Anton, I totally trust whatever release processes you pick (and that you'll help shape the release process well going forward). You deal with so much stuff managing releases and I am ultra grateful :heart:. Please don't take any of my comments above as personal. They aren't. Just a collections of frustrations that are apparently getting to me.
Anton (Jan 04 2025 at 15:25):All good, very understandable concerns, it's hard to put a cost on all our concerns and compare them. I'd like to talk about this more later, I really want to get those releases in today.
Brendan Hansknecht (Jan 04 2025 at 15:26):Makes total sense.
Brendan Hansknecht (Jan 04 2025 at 15:36):Also, has anyone looked at updating the platforms in the roc repo to PI (benchmarks, cli tests). I plan to start doing it, just wasn't sure if someone is already done/half way done, but it isn't merged yet.
Anton (Jan 04 2025 at 19:30):status update: exercism is on basic-cli 0.18 and snake_case https://github.com/exercism/roc/pull/171
It was an enormous pain with the templates and the dynamic programming languages involved but it's done :tada:
Isaac Van Doren (Jan 04 2025 at 21:03):Wow great work! That does sound like a huge pain
Anton (Jan 04 2025 at 21:52):I'd like to talk about this more later
It's always easier to talk specifics. Let's get a list together of all the breaking changes that are ready to merge with a description of their priority; sensitivity to accumulating merge conflicts, if it fixes a common bug, expected work to basic-cli and basic-ws..
I'll start:
Brendan Hansknecht (Jan 04 2025 at 22:24):renaming builtins
+ sensitive to merge conflicts: Yes
+ expected changes to basic-cli/basic-ws: Multiple, but easy overall
+general priority: medium. Would be really nice to fully switch over to snake_case
removing space calling convention
+ sensitive to merge conflicts: Yes
+ expected changes to basic-cli/basic-ws: Multiple, but easy overall
+ general priority: medium. Same as above (less important for consistency than the naming)
Luke Boswell (Jan 05 2025 at 23:03):I think it's time we move forward with our new release management process.
I propose we cut a "nightly", give it a release version 0.0.1+123abc as we've discussed. @Anton
Then from this point we switch to roc compiler being free to move ahead of the platforms; we cut a new "testing" release periodically and promote it to the "supported" version when we get the platforms ready.
Luke Boswell (Jan 05 2025 at 23:06):(deleted)
Anthony Bullard (Jan 05 2025 at 23:07):I think we need to create org-wide milestones for each of the major breaking changes (grouped together as it makes sense)
Luke Boswell (Jan 05 2025 at 23:08):This is a new idea, and I'm not familiar with this workflow. Are you able to expand on that a little? Have you seen the previous discussion on release management, what are your thoughts on that?
Luke Boswell (Jan 05 2025 at 23:09):create org-wide milestones
Similar to the 0.1.0 in GH?
Luke Boswell (Jan 05 2025 at 23:11):One of the main goals we had is to really minimise the management and coordination overhead. We wanted a workflow that could give a "stable" experience if people use the latest supported/compatible version. But also accept that this version will change regularly and older code will certainly break between versions.
Anthony Bullard (Jan 05 2025 at 23:11):Yeah similar
Anthony Bullard (Jan 05 2025 at 23:12):The big thing is that the current stable of any org-owned platform works OOTB with the current stable of the compiler
Anthony Bullard (Jan 05 2025 at 23:13):And then we do our best to keep the nightlies in sync
Anthony Bullard (Jan 05 2025 at 23:13):But it's understood that the platforms may lag compiler on nightly
Luke Boswell (Jan 05 2025 at 23:14):It's a lot of (handraulic) work making a nightly release. I really want to move away from that and free up Anton's time a little.
Luke Boswell (Jan 05 2025 at 23:14):Ideally we can get most things automated... but there's a lot of CI wrangling
Anthony Bullard (Jan 05 2025 at 23:14):It would be _doubly_ nice if we could test stable and nightly of each platform against both stable and nightly of the compiler and have a little thing on the Repo that shows the status / last SHA it was built successfully with
Luke Boswell (Jan 05 2025 at 23:15):Yeah the idea was a daily CI run that grabbed the latest versions of everything and tested them all and reported compatibility.
Luke Boswell (Jan 05 2025 at 23:16):So we know when we have all the supported platforms/packages :check: and that's the signal for promoting a nightly/testing release to the latest/supported version.
Anthony Bullard (Jan 05 2025 at 23:16):Yeah, the same for "well-known" packages would be great. Especially if we could write up a GH action for it and ask the package authors to run it via GH using their own minutes
Luke Boswell (Jan 05 2025 at 23:19):So we always have a "supported" / latest release in roc that is known to work well with the "supported" / latest versions of the platforms and packages.
We periodically (weekly?) cut a new "testing" release of roc that will likely be ahead of the platforms and packages.
We test daily the "supported" & "testing" releases against the latest versions of everything in the wild, and when everything is :check: against the testing release it get's promoted.
Anthony Bullard (Jan 05 2025 at 23:20):That sounds great.
Anthony Bullard (Jan 05 2025 at 23:20):And we shouldn't go crazy worrying about a new stable/support version being cut on any sort of cadence
Anthony Bullard (Jan 05 2025 at 23:20):It'll get cut when we feel good about it
Luke Boswell (Jan 05 2025 at 23:37):I'm going to update my release proposal again to hopefully clarify some of the key terms and workflow.
Brendan Hansknecht (Jan 05 2025 at 23:45):Yeah, I would love to get something like this rolling. Then breaking changes are just incrementing a version number.
Brendan Hansknecht (Jan 05 2025 at 23:46):And the compatibility check will enable us to increment the version number if it is accidentally missed
Brendan Hansknecht (Jan 05 2025 at 23:46):And platforms at any point can be updated to a new breaking change number. No specific rush.
Brendan Hansknecht (Jan 05 2025 at 23:48):Will make it much easier to build an app by grabbing versions of each package and platform for a specific roc breaking change version. Then get stability.
Brendan Hansknecht (Jan 05 2025 at 23:50):I mostly care about keeping main in the roc repo working and even a basic form of breaking change versioning unlocks that.
Brendan Hansknecht (Jan 05 2025 at 23:51):If we want less overhead, the alternative would be to just have a dev and main branch and periodically move dev over to main, but that still leads to the stop the world updates when dev is promoted to made. A rolling version number with history is much more decoupled.
@Luke Boswell and/or @Anton let me know if there are any specific pieces that would really help get this in. I'm keen to help.
Luke Boswell (Jan 06 2025 at 04:29):New release management proposal
Anton (Jan 06 2025 at 10:18):It's a lot of (handraulic) work making a nightly release
I think I spend about 10 minutes on it per day if there are no test failures. I would estimate there is a test failure in 1 out 10 days.
Anton (Jan 06 2025 at 10:58):I think it's time we move forward with our new release management process
With everything we have going I think we should hold this off a little while longer, things are set up to test with TESTING but not with this new release approach. It doesn't seem like it would require a lot of changes but it feels risky based on my intuition.
Anton (Jan 06 2025 at 11:00):Based on Brendan's list I feel good about shifting to a TESTING release once a breaking PR is merged in Roc main.
Anton (Jan 06 2025 at 11:02):We should have enough tests in the main roc repo to defend against most concerns of getting multiple breaking changes in back to back. If not, we need to keep working to expand test coverage. I think that "hit complex issues, and it's a pain to revert things" is a symptom and not a reason to slow down.
I think this is a good diagnosis, I've given this some thought and will propose testing changes in ideas in the near future.
Anton (Jan 06 2025 at 13:06):I feel good about shifting to a TESTING release once a breaking PR is merged in Roc main.
We could start with "builtins to snake_case" PR#7463 ?
Luke Boswell (Jan 07 2025 at 20:29):I'm concerned that we currently have at least a few [DO NOT MERGE] breaking changes stacked up, and I worry that we are going to lose all this momentum. It's going to be challenging to keep all of these PR's fresh for more than a few days. Not to mention the work that we want to start but would potentially cause merge conflicts.
While contributors are active and working on new features it would be good to unlock this effort. I appreciate the intent to not break main, the nightlies, etc.
Maybe there is another way. Could we make a dev or breaking branch maybe and start merging these PRs in there? This way we know they are at least compatible with each other.
Sam Mohr (Jan 07 2025 at 20:38):That's a great idea, breaking is the right word
Luke Boswell (Jan 07 2025 at 20:41):The issue with my proposal here, is that it doesn't help us if we want to slow down and just test one breaking change with a release cycle at a time.
Brendan Hansknecht (Jan 07 2025 at 20:42):Would that just make rebasing on main more brittle? Cause some of these changes are pretty low chance of conflicts
Brendan Hansknecht (Jan 07 2025 at 20:43):Luke Boswell said:
The issue with my proposal here, is that it doesn't help us if we want to slow down and just test one breaking change with a release cycle at a time.
I really don't think we need to do this. The syntax changes are unlikely to be majorly broken. The refcounting change could be majorly broken but is trivial to revert. The utf-8 change is unlikely to be broken.
Brendan Hansknecht (Jan 07 2025 at 20:44):So I think merging is pretty low risk
Brendan Hansknecht (Jan 07 2025 at 20:44):Hardest to detangle would PNC + snake_case
Luke Boswell (Jan 07 2025 at 20:44):I'm not very experience with this level of managing software projects, with a beginner level of git foo, I'm concerned that we are intentionally slowing PR's down... at a time when we want to move fast and get to the next milestones.
Brendan Hansknecht (Jan 07 2025 at 20:44):I agree
Brendan Hansknecht (Jan 07 2025 at 20:45):I think if for now we make a separate testing and latest release (later switching to the new breaking change plan), we can merge everything into main right away.
Brendan Hansknecht (Jan 07 2025 at 20:45):I think that is the way to go
Luke Boswell (Jan 07 2025 at 20:47):So what should we do about all these breaking PR's that are sitting here ready to go?
Brendan Hansknecht (Jan 07 2025 at 20:48):Merge them all directly into main as a testing release is my proposal.
Sam Mohr (Jan 07 2025 at 20:48):I don't know if that's feasible to expect won't hit lots of merge conflicts or unexpected issues
Brendan Hansknecht (Jan 07 2025 at 20:49):Merge conflicts are an issue of stale prs. Merging prs sooner and more often fixes that.
Brendan Hansknecht (Jan 07 2025 at 20:49):Unexpected issues are fine
Brendan Hansknecht (Jan 07 2025 at 20:49):This is just a testing release
Luke Boswell (Jan 07 2025 at 20:49):My understanding is, the sooner we merge these the less impact they have on everyone elses PR's... you just make sure you're in sync with or rebasing on main.
Brendan Hansknecht (Jan 07 2025 at 20:50):As long as the issues that are arise are issues that we plan to forward fix and we think it is unlikely we want to revert the PRs (which I think is the case if we do a testing release), then I think they should all be good to merge.
Luke Boswell (Jan 07 2025 at 20:51):Maybe I'm just getting confused with something obvious, why aren't we merging these PR's then? They're labelled [DO NOT MERGE]
Brendan Hansknecht (Jan 07 2025 at 20:52):In my mind the only issue is not having a separate testing and latest release now. We have new releases for the core platforms with PI now. So I think we are good to move forward
Sam Mohr (Jan 07 2025 at 20:53):I put DO NOT MERGE on mine because it seemed to need platform coordination
Sam Mohr (Jan 07 2025 at 20:53):I can remove that from the title
Brendan Hansknecht (Jan 07 2025 at 20:53):Yeah, platforms will update later. So should be good to merge
Luke Boswell (Jan 07 2025 at 20:55):@Sam Mohr how do you feel about us merging https://github.com/roc-lang/roc/pull/7321 first?
Sam Mohr (Jan 07 2025 at 20:55):Do it now u wont
Luke Boswell (Jan 07 2025 at 20:55):I'm not sure if @shua is planning on making a separate PR
Sam Mohr (Jan 07 2025 at 21:00):You mean for the UTF-16 stuff?
Sam Mohr (Jan 07 2025 at 21:00):Probably
Brendan Hansknecht (Jan 07 2025 at 21:00):As a note, if no one else looks into the breaking change GitHub action work, I plan to look at it next. Not sure the best way to experiment with it, probably in another repo. That said, not exactly sure when I will next have time.
Luke Boswell (Jan 07 2025 at 21:01):I'm not sure what that is Brendan... is there an issue or something for that?
Luke Boswell (Jan 07 2025 at 21:02):Oh, the release management thing?
Brendan Hansknecht (Jan 07 2025 at 21:11):Yeah
Brendan Hansknecht (Jan 07 2025 at 21:11):Release management and testing for the new breaking change versioning
Brendan Hansknecht (Jan 07 2025 at 21:11):Hoping to automate a lot of it
shua (Jan 07 2025 at 21:14):Luke Boswell said:
I'm not sure if shua is planning on making a separate PR
I was leaning towards a separate PR
Sam Mohr (Jan 07 2025 at 21:20):Merged conflicts fixed for snek_ces
Anthony Bullard (Jan 07 2025 at 21:25):No step
Brendan Hansknecht (Jan 07 2025 at 21:29):Sam Mohr said:
Merged conflicts fixed for snek_ces
Gonna land it?
Sam Mohr (Jan 07 2025 at 21:29):Once Luke and I fix the basic-ssg dependency that we use to build the Roc site, yes
Sam Mohr (Jan 07 2025 at 21:30):Also updating Weaver in the meantime
Luke Boswell (Jan 07 2025 at 21:30):Working on basic-ssg now
Luke Boswell (Jan 08 2025 at 05:30):Brendan Hansknecht said:
current refcounting change is super basic and should be super easy to migrate. Just requires changing a single constant
Do you think we should tack this one onto the paired builtin / testing PRs in basic-cli etc?
Brendan Hansknecht (Jan 08 2025 at 05:37):That sounds fine
Brendan Hansknecht (Jan 08 2025 at 05:38):Should just require updating the version of roc-std after landing the refcounting pr. At most requires also updating any refcounting constants (but I don't think basic-cli directly sets any of those)
Luke Boswell (Jan 08 2025 at 09:34):Ok, so I imagine we land the builtin snake_case PR into main, and then follow that with your refcount PR and then that's probably enough scope for a testing release.
Luke Boswell (Jan 08 2025 at 09:35):We could remove Task, I skimmed through and theres a few tests/snapshots remaining, after we land the tutorial update.
Sam Mohr (Jan 08 2025 at 09:35):I'd vote for doing that
Luke Boswell (Jan 08 2025 at 09:35):Why is that? just cause we are close?
Sam Mohr (Jan 08 2025 at 09:36):Any code affected by this set of breaking changes must be updated by users for it to run again, even if most of that update can be handled by roc format --migrate
Sam Mohr (Jan 08 2025 at 09:36):We've been waiting for the Task removal to ensure people have time to migrate, but they're gonna have to migrate as soon as this release drops
Sam Mohr (Jan 08 2025 at 09:37):I've overloaded the work migrate there:
Luke Boswell (Jan 08 2025 at 09:37):The next major breaking change would be static dispatch right?
Sam Mohr (Jan 08 2025 at 09:37):We've been waiting for the Task removal to ensure people have time to migrate from Task to PI, but they're gonnna have to migrate everything else anyway as soon as this release drops
Sam Mohr (Jan 08 2025 at 09:38):Probably
Sam Mohr (Jan 08 2025 at 09:38):Actually no
Sam Mohr (Jan 08 2025 at 09:38):It'll be more syntax breaks
Sam Mohr (Jan 08 2025 at 09:38):I believe || func doesn't work fully with space calls
Sam Mohr (Jan 08 2025 at 09:39):So we'll need to break \args -> func to get that in
Sam Mohr (Jan 08 2025 at 09:39):And then for static dispatch, that's in a big bundle with the other compiler phases being updated
Luke Boswell (Jan 08 2025 at 09:40):I think I lean towards deprecating Task in this breaking change... and then removing it with the next.
Then PNC/syntax (functions, string interpolation etc...) in the next.
Then static dispatch, remove abilities, deprecate module params, deprecate default records fields etc...
Sam Mohr (Jan 08 2025 at 09:41):Aka lambda sets, mono, etc.
Sam Mohr (Jan 08 2025 at 09:41):Okay, we can do that
Luke Boswell (Jan 08 2025 at 09:41):I'm just spitballing here...
Sam Mohr (Jan 08 2025 at 09:41):I guess what we could do is add a deprecation warning on all function calls in the Task module?
Sam Mohr (Jan 08 2025 at 09:42):I'm not sure who gets helped by keeping Task in Roc, though
Luke Boswell (Jan 08 2025 at 09:42):I lean towards deprecating Task in this breaking change
Actually... with the snake_case builtins it makes no sense to keep it. All the packages need to be updated anyway
Sam Mohr (Jan 08 2025 at 09:43):Yep, all of the things will be broken
Luke Boswell (Jan 08 2025 at 09:43):How far are we from landing your builtins PR?
Sam Mohr (Jan 08 2025 at 09:43):The only thing left is to get the website building
Luke Boswell (Jan 08 2025 at 09:44):It's just the question around basic-cli docs right?
Sam Mohr (Jan 08 2025 at 09:44):Yep
Sam Mohr (Jan 08 2025 at 09:44):That's why I suggested we get @Anton 's blessing to do what basic-webserver does
Luke Boswell (Jan 08 2025 at 09:45):Yeah, so if we are happy with the static site / GH Pages thing, then we can land that, land the refcount, update the paired basic-cli PR (for refcount), and then remove Task and we're almost there.
Sam Mohr (Jan 08 2025 at 09:45):Which for the Antons reading this message is to generate the docs in basic-cli instead of in the Roc compiler repo
Sam Mohr (Jan 08 2025 at 09:45):I'll do the Task PR once snake_case is merged
Luke Boswell (Jan 08 2025 at 09:46):I have all day tomorrow I could work on that also... I might try and remove/update the tests and snapshots in a separate PR first
Sam Mohr (Jan 08 2025 at 09:46):Sure, works for me
Sam Mohr (Jan 08 2025 at 09:47):Should just be a case of removing:
Task.roc module Sam Mohr (Jan 08 2025 at 09:47):If you'd enjoy working on that, I have plenty of other stuff to do
Sam Mohr (Jan 08 2025 at 09:49):Also, update https://github.com/roc-lang/roc/blob/main/crates/compiler/can/src/effect_module.rs
Luke Boswell (Jan 08 2025 at 09:51):It's just find and replace on all files in the compiler right? :sweat_smile:
Sam Mohr (Jan 08 2025 at 09:51):My entire job is built upon ripgrep
Sam Mohr (Jan 08 2025 at 09:52):So kinda
Anton (Jan 08 2025 at 09:53):Sam Mohr said:
Which for the Antons reading this message is to generate the docs in
basic-cliinstead of in the Roc compiler repo
Sounds good :+1:
Sam Mohr (Jan 08 2025 at 09:55):Okay, great!
Sam Mohr (Jan 08 2025 at 09:58):https://github.com/roc-lang/basic-cli/pull/306
Sam Mohr (Jan 08 2025 at 09:58):I incorporated the docs statically added by Luke in https://github.com/roc-lang/basic-cli/pull/307
Luke Boswell (Jan 08 2025 at 09:59):But I also added a GH workflow in that PR
Luke Boswell (Jan 08 2025 at 09:59):I figured the two workflows would conflict, that's why I closed yours
Luke Boswell (Jan 08 2025 at 10:00):The hasnep/setup-roc@main action also builds the site but it doesn't load it into the right location for the GH Pages compatible with the new multi-version setup I included
Luke Boswell (Jan 08 2025 at 10:01):So I don't think these two PR's are compatible
Sam Mohr (Jan 08 2025 at 10:09):Oh, damn
Sam Mohr (Jan 08 2025 at 10:09):Let me update it, then
Sam Mohr (Jan 08 2025 at 10:10):Here's a 2 file one to remove basic-cli docs from the roc-lang.org website: https://github.com/roc-lang/roc/pull/7483
Luke Boswell (Jan 08 2025 at 10:11):Alg, just done it
Sam Mohr (Jan 08 2025 at 10:13):Thanks!
Luke Boswell (Jan 08 2025 at 10:14):Was there also basic-cli docs in the CI workflows? or was it just the www/build.sh script that was causing the issue?
Sam Mohr (Jan 08 2025 at 10:16):Seems like attempting to build basic-cli's docs in www/build.sh was the last issue in the workflow: https://github.com/roc-lang/roc/actions/runs/12660030240/job/35280434791
Sam Mohr (Jan 08 2025 at 10:16):I don't think that basic-cli docs are in the CI workflows, I'll double check
Sam Mohr (Jan 08 2025 at 10:17):There are workflows to build basic-cli for testing purposes, but those are all triggered manually
Sam Mohr (Jan 08 2025 at 10:18):Okay, in the basic_cli_build_release.yml action, we build and upload the docs. Good catch!
Sam Mohr (Jan 08 2025 at 10:18):Let me remove that
Sam Mohr (Jan 08 2025 at 10:20):@Luke Boswell could you re-approve when you get the chance?
Sam Mohr (Jan 08 2025 at 10:21):Once this passes CI and testing, we should be able to just merge, then merge in main into the snake_case branch, wait for CI, and merge that
Sam Mohr (Jan 08 2025 at 10:21):So just clicking buttons
Anton (Jan 08 2025 at 10:21):Sam Mohr said:
Okay, in the
basic_cli_build_release.ymlaction, we build and upload the docs. Good catch!
Hold on :p
Sam Mohr (Jan 08 2025 at 10:22):Okay
Anton (Jan 08 2025 at 10:22):What is being changed in basic_cli_build_release.yml?
Sam Mohr (Jan 08 2025 at 10:25): Luke Boswell (Jan 08 2025 at 10:25):We no longer need the env var ROC_DOCS_URL_ROOT
Sam Mohr (Jan 08 2025 at 10:25):The generation and upload of docs for basic-cli
Luke Boswell (Jan 08 2025 at 10:25):We should probably also remove that in your PR
Luke Boswell (Jan 08 2025 at 10:25):It's a fast follow up from mine earlier today, but I wasn't sure how long we would need it
Luke Boswell (Jan 08 2025 at 10:27):Also... we can probably remove the whole binary roc_docs_cli in crates/docs_cli
Luke Boswell (Jan 08 2025 at 10:28):@Anton -- can you confirm we only used that for basic-cli docs gen?
Anton (Jan 08 2025 at 10:28):The generation and upload of docs for basic-cli
Those are uploaded to the github workflow file storage so I can download them and add them to the release assets like docs.tar.gz in basic-cli 0.18.0.
Luke Boswell (Jan 08 2025 at 10:29):Can you use a link to the basic-cli GH Pages site now?
Anton (Jan 08 2025 at 10:29):Luke Boswell said:
Anton -- can you confirm we only used that for basic-cli docs gen?
I think that may brreak Hannes' github workflows
Luke Boswell (Jan 08 2025 at 10:29):Luke Boswell said:
Anton -- can you confirm we only used that for basic-cli docs gen?
I think I can answer my own question... we use it for the builtin docs
Luke Boswell (Jan 08 2025 at 10:30):Ok, let's just leave these docs things alone for a little while then.
Luke Boswell (Jan 08 2025 at 10:30):We don't need to remove that right now
Anton (Jan 08 2025 at 10:32):Can you use a link to the basic-cli GH Pages site now?
It's nice that users can easily download the docs with a single tar for offline use
Luke Boswell (Jan 08 2025 at 10:33):But the have the package from the URL? cant they just generate the docs locally?
Luke Boswell (Jan 08 2025 at 10:34):I agree with you that it's helpful... just thinking out loud
Luke Boswell (Jan 08 2025 at 10:34):Like, what if they could go roc docs --open http://...asdfaWEFWF.tar.br - that loads the modules from the local cache (or downloads if required) and generates the site fresh
Sam Mohr (Jan 08 2025 at 10:35):Since this discussion is happening and I need to go to bed, I'll do a single step of removing basic-cli from www/build.sh and updating the link in www/content/docs.md, and do that right in the snake_case PR
Sam Mohr (Jan 08 2025 at 10:35):And then this discussion can go in that PR I made, which I'll mark as draft for now
Luke Boswell (Jan 08 2025 at 10:37):It's ok... I don't plan on touching the env var or the doc-cli binary right now. For the short term we can have duplicate ways of generating docs to support the different workflows
Luke Boswell (Jan 08 2025 at 10:38):Your snake_case PR is ublocked by https://github.com/roc-lang/roc/pull/7483 though I guess
Sam Mohr (Jan 08 2025 at 10:38):Well it would be nice to get working, and also Anton seems concerned with the other stuff I removed in the docs PR
Sam Mohr (Jan 08 2025 at 10:38):So to avoid rushing a decision
Sam Mohr (Jan 08 2025 at 10:38):I fixed up the snake_case PR
Anton (Jan 08 2025 at 10:39):cant they just generate the docs locally?
No, the site generation code changes over time and will fail on old basic-cli releases
Luke Boswell (Jan 08 2025 at 10:39):Sam Mohr said:
Well it would be nice to get working, and also Anton seems concerned with the other stuff I removed in the docs PR
No I think I just confused things here... I don't think @Anton has any concerns with that PR (speaking on his behalf ofc)
Anton (Jan 08 2025 at 10:40):Can you link to the specific PR?
Sam Mohr (Jan 08 2025 at 10:40):https://github.com/roc-lang/roc/pull/7483
Sam Mohr (Jan 08 2025 at 10:40):I marked it as draft for now
Luke Boswell (Jan 08 2025 at 10:41):Ohk, maybe we should reset the change to .github/workflows/basic_cli_build_release.yml
Sam Mohr (Jan 08 2025 at 10:41):Anton said:
cant they just generate the docs locally?
No, the site generation code changes over time and will fail on old basic-cli releases
For basic-webserver, we do generate the docs in basic-webserver though. Is that a problem, then?
Luke Boswell (Jan 08 2025 at 10:42):It was just the www/build.sh script blocking things, and I was getting overly ambitious with wanting to remove things.
Sam Mohr (Jan 08 2025 at 10:43):Maybe we should just close that PR and make a new one for the env var stuff if we want to make those changes
Anton (Jan 08 2025 at 10:43):For
basic-webserver, we do generate the docs inbasic-webserverthough. Is that a problem, then?
We currently only make docs for main of basic-webserver
Sam Mohr (Jan 08 2025 at 10:43):I've already copied the relevant stuff to the snake_case PR: https://github.com/roc-lang/roc/pull/7463/files#diff-e772080787482bb78eeddd4d3c75a4ecd414c5e06674fde21d4383c1c3927735
Luke Boswell (Jan 08 2025 at 10:44):Oh, I see what your getting at I think... well I could if my browser would load that PR.
Luke Boswell (Jan 08 2025 at 10:44):It's probably best to keep it in the smaller PR
Luke Boswell (Jan 08 2025 at 10:45):Luke Boswell said:
Ohk, maybe we should reset the change to
.github/workflows/basic_cli_build_release.yml
Just this one file needs restoring I think
Luke Boswell (Jan 08 2025 at 10:45):I don't think we need to wait for a full CI run either
Sam Mohr (Jan 08 2025 at 10:46):Okay, I'll fix and you can override merge
Luke Boswell (Jan 08 2025 at 10:48):Done
Sam Mohr (Jan 08 2025 at 10:48):Thanks!
Sam Mohr (Jan 08 2025 at 10:48):I'm gonna set snake_case to auto-merge
Luke Boswell (Jan 08 2025 at 10:50):I can review it tomorrow if no-one else gets to it before me, but I'm heading off now
Luke Boswell (Jan 08 2025 at 10:50):Looks like a huge amount of mechanical :snake: changes
Sam Mohr (Jan 08 2025 at 10:50):Yep
Sam Mohr (Jan 08 2025 at 10:51):@Anthony Bullard said he'd jump on this grenade for me (bless his sweet heart)
Sam Mohr (Jan 08 2025 at 10:51):But if you also would like a belly full of shrapnel, be my guest
Luke Boswell (Jan 08 2025 at 10:51):Thank you for your sacrifice @Anthony Bullard
Anton (Jan 08 2025 at 12:52):TESTING releases are now available
Anthony Bullard (Jan 08 2025 at 15:52):Migration PR looks good to me @Sam Mohr
Anton (Jan 08 2025 at 17:03):Just for clarity, @Anthony Bullard you did a full review of https://github.com/roc-lang/roc/pull/7463 ?
Anthony Bullard (Jan 08 2025 at 19:57):As full as can possibly be done on such a large change
Sam Mohr (Jan 08 2025 at 19:58):Pretty much
Sam Mohr (Jan 08 2025 at 19:58):Are you able to give approvals? This thing will merge as soon as someone clicks approve
Anthony Bullard (Jan 08 2025 at 19:59):I thought I didβ¦
Sam Mohr (Jan 08 2025 at 20:05):Thanks for approving! I'll look at your PR now in return
Anthony Bullard (Jan 08 2025 at 20:48):Sam Mohr said:
Thanks for approving! I'll look at your PR now in return
Note that I just pushed up some changes that I forgot to add, and then rebased
Anthony Bullard (Jan 08 2025 at 20:52):And ... there are problems...
Anthony Bullard (Jan 08 2025 at 20:52):I think changing the precedence of PncApply to Term instead of Apply broke Pizza
Anthony Bullard (Jan 08 2025 at 20:53):Which is a sentence I just typed...
Sam Mohr (Jan 08 2025 at 20:53):Don't tell the state of New York
Anthony Bullard (Jan 08 2025 at 20:54):Gonna roll that back real quick and make sure
Anthony Bullard (Jan 08 2025 at 20:55):Nope, can you check main/HEAD?
Sam Mohr (Jan 08 2025 at 20:56):What would you like me to check?
Anthony Bullard (Jan 08 2025 at 20:57):Actually nevermind, checks wouldn't have passed if this was present there
Anthony Bullard (Jan 08 2025 at 21:05):Found the issue, pushing up
Anthony Bullard (Jan 08 2025 at 21:06):Three more hidden match cases due to use of _ ->
Anthony Bullard (Jan 08 2025 at 21:06):This time for Pizza desugaring
Sam Mohr (Jan 09 2025 at 19:20):Every time I see a camelCase variable in code outside of Roc, I think "gotta change that". I've been poisoned
Luke Boswell (Jan 10 2025 at 01:47):Luke Boswell said:
I think the only remaining syntax for this, once we land the staged breaking changes are;
|args|"string ${interpolation}"
How far off from this are we?
I've just upgraded or staged PR's for the following;
My feeling is that we should batch in the above syntax changes as well if we can.
Brendan Hansknecht (Jan 10 2025 at 01:48):I would assume string interpolation is trivial
Luke Boswell (Jan 10 2025 at 01:48):I feel like the later static dispatch changes would then be relatively minor and non-breaking from a syntax and package perspective
Luke Boswell (Jan 10 2025 at 01:49):As in ... we wouldn't be needing to upgrade all the packages with new releases too
Sam Mohr (Jan 10 2025 at 01:49):Aka, let's just make these last changes and be done with it? I'm down
Luke Boswell (Jan 10 2025 at 01:50):Well, I'm more getting at, let's not do the testing builds and uploading the pre-releases to GH until we have those changes. These can sit there until then... assuming they're not too far away
Luke Boswell (Jan 10 2025 at 01:51):Because the above seem like the only major syntax changes that would need a big change the world ecosystem update.
Sam Mohr (Jan 10 2025 at 01:51):If we pick up the syntax changes in parallel, I think we can do it quickly
Sam Mohr (Jan 10 2025 at 01:51):I can definitely do string interpolation since as Brendan points out, it should be pretty easy
Sam Mohr (Jan 10 2025 at 01:52):Not sure how much effort || will be
Sam Mohr (Jan 10 2025 at 01:52):I guess methods are also a big change, but no code looks like that today, so that won't break anything
Anthony Bullard (Jan 10 2025 at 01:53):Iβm about to do ||
Sam Mohr (Jan 10 2025 at 01:53):Well then
Anthony Bullard (Jan 10 2025 at 01:53):Gotta finish this PR
Luke Boswell (Jan 10 2025 at 01:54):I'm not wanting to rush us or anything... I'm just smashing through the upgrades for the packages etc while I have the free time now. Wanting to have a bit of a plan so everyone's on the same page.
I just want to confirm, there's no other breaking syntax changes on our horizon?
Sam Mohr (Jan 10 2025 at 01:54):Let's look at the realworld example
Luke Boswell (Jan 10 2025 at 01:56):I'll re-watch that now over lunch
Sam Mohr (Jan 10 2025 at 01:57):The code is in a GH repo: https://github.com/rtfeldman/roc-realworld/tree/main/src
Sam Mohr (Jan 10 2025 at 01:57):I'm reading it, which I think is much faster
Anthony Bullard (Jan 10 2025 at 01:58):Thereβs also ? ||
Sam Mohr (Jan 10 2025 at 01:59): Luke Boswell (Jan 10 2025 at 01:59):I'm looking for things that are out in the wild now (well in a post snake_case builtins and PNC world), that will no longer be valid
Sam Mohr (Jan 10 2025 at 01:59):These are all missing, but I don't think that's a problem, since I don't think anything will break existing syntax of these things
Anthony Bullard (Jan 10 2025 at 02:04):Custom types will no?
Luke Boswell (Jan 10 2025 at 02:05):Yeah removing @
Sam Mohr (Jan 10 2025 at 02:05):Ah
Sam Mohr (Jan 10 2025 at 02:05):Well, that one we might just have to accept as a second breaking change
Sam Mohr (Jan 10 2025 at 02:06):Unless we changed syntax now for opaques to be Opaque.{ value }
Sam Mohr (Jan 10 2025 at 02:06):Which I think isn't a good idea
Anthony Bullard (Jan 10 2025 at 02:08):I'd be against that
Luke Boswell (Jan 10 2025 at 02:14):Right, so we're thinking removing @ / custom types would better live with the static dispatch breaking change? sounds good :thumbs_up:
Anthony Bullard (Jan 10 2025 at 02:14):Yes, I think that would be perfect
Anthony Bullard (Jan 10 2025 at 02:14):Syntax Season is almost over guys
Sam Mohr (Jan 10 2025 at 02:15):Compiler Grunge Season is always so nice after Syntax Season
Sam Mohr (Jan 10 2025 at 02:15):Perfect for a light sweater
Anton (Jan 10 2025 at 09:44):let's not do the testing builds
Should I not upload any new TESTING releases?
Luke Boswell (Jan 10 2025 at 09:57):I dont think we need them yet
Luke Boswell (Jan 10 2025 at 09:57):If you want to then it's ok. It might be helpful to test the process is working ok? idk
Anton (Jan 10 2025 at 10:31):It might be helpful to test the process is working ok?
No, should be good :+1:
Sam Mohr (Jan 10 2025 at 11:45):Another breaking change could be the {} to () change. This isn't a syntax issue, but it is a change that will break statements, since we only allow statements that return {}. We should probably allow () in addition. Not sure if we want it long-term, but at least for now while all of our APIs use {} we should support both
Sam Mohr (Jan 10 2025 at 11:45):I don't think this needs to happen now during this rush of breaking changes, but maybe should happen soon?
Brendan Hansknecht (Jan 10 2025 at 18:00):Maybe it could be the first test for the new versioning/release management idea? (I say not having worked on the GitHub actions for releases at all yet and likely being busy this entire weekend)
Sam Mohr (Jan 10 2025 at 18:06):That's a good idea! It's not breaking syntax, but a lot of std library functions will change signature
Luke Boswell (Jan 10 2025 at 18:57):I'm glad you remembered that. Yeah the new default and also the sugar.
If it's not a big change to implement it, I'd definitely like to get that in with these ones too.
Sam Mohr (Jan 10 2025 at 18:57):I'll do it next
Luke Boswell (Jan 10 2025 at 18:59):My logic is we can do it now cleanly as a breaking change, so we don't need to support both.
Luke Boswell (Jan 10 2025 at 19:00):Also there are a lot of places with Args.list!({}) or similar that look a little odd right now.
Sam Mohr (Jan 10 2025 at 19:01):We'd maybe want to pair with the desugaring of (()) to ()?
Sam Mohr (Jan 10 2025 at 19:01):I'm free this whole weekend
Luke Boswell (Jan 10 2025 at 19:03):Yeah, that's what I was thinking. The whole from {} to () and related changes
Sam Mohr (Jan 10 2025 at 19:08):Well in that case, it's easier to to just move to () as the only unit type, unless we want to support both for some reason?
Sam Mohr (Jan 10 2025 at 19:08):They both compile to the same thing, but it's nice to force consistency
Sam Mohr (Jan 10 2025 at 19:09):So I'd vote only supporting () for statements
Luke Boswell (Jan 10 2025 at 21:39):@Sam Mohr upgrading the website to the new syntax is gonna be a whole thing. Like the interactive examples etc. Best to leave it until the dust settles and we have working pre-releases on the streets I think.
Sam Mohr (Jan 10 2025 at 21:39):Great
Luke Boswell (Jan 12 2025 at 07:13):So a bit of an update for everyone... we've got pretty much all the platforms & packages upgraded or staged and ready. All that remains now from what I can tell is
|args| for functions{} -> () for default type, plus the sugarThe only package with haven't upgraded yet is roc-lang/unicode -- it's used by one of the examples.
Luke Boswell (Jan 12 2025 at 07:31):Or visualized another way...
snek_cse |
PNC | "${str}" |
|args| |
unit() |
|
|---|---|---|---|---|---|
| :check: | :check: | :check: | basic-cli | ||
| :check: | :check: | :check: | basic-webserver | ||
| :check: | :check: | :check: | examples | ||
| :check: | :check: | roc-html | |||
| :check: | :check: | roc-random | |||
| :check: | :check: | :check: | roc-parser | ||
| :check: | :check: | :check: | roc-json | ||
| :check: | :check: | roc-ansi |
Sam Mohr (Jan 12 2025 at 08:01):I started on empty tuple support, heads up if someone else was planning on doing that
Sam Mohr (Jan 12 2025 at 08:01):If someone else is already working on it, I'll stop
Sam Mohr (Jan 12 2025 at 22:04):Should Break() desugar to Break(())?
Sam Mohr (Jan 12 2025 at 22:04):I'm presuming yes
Richard Feldman (Jan 12 2025 at 22:12):yeah
Richard Feldman (Jan 12 2025 at 22:12):same as functions
Anton (Jan 13 2025 at 17:56):I'll get started on upgrading roc-lang/unicode
jan kili (Jan 14 2025 at 00:48):JanCVanB said:
I propose we slap a big warning message at the top of the tutorial that foundational syntax is in flux, with large-scale tutorial updates coming soon.
I'm doing this now. I'll start by looking into what formatting tools our webpage renderer has for something like a "big warning message", unless someone already familiar with the renderer has a tip for me!
Update 1: nix: command not found :cry: I'm on a train with no WiFi and I've never ran nix on this laptop since re-imaging it. My hotspot bill is gonna hurt lol
Update 2: .banner { background-color: var(--gray-bg); :sunglasses: ayyy instead of nix developing, I just read the CSS file manually and found this existing class that's perfect for the message...
Screenshot_20250113_180856.png
... though I'm unsure yet why its current use isn't appearing on the site... :thinking:
Screenshot_20250113_181126.png
Update 3: :shrug: I'll revisit this with WiFi-installed nix dependencies tomorrow
Luke Boswell (Jan 14 2025 at 04:43):though I'm unsure yet why its current use isn't appearing on the site...Β :thinking:
Yeah, so I added the banner for warning about roc being WIP to the tutorial recently... but I couldn't figure out how to actually trigger the website to update
Luke Boswell (Jan 14 2025 at 04:44):So i think it's there in the source on main, but the new site hasn't been uploaded to Netlify
jan kili (Jan 14 2025 at 05:02):Gotcha, thanks! I can poke at it and expand upon it, if you'd like.
Anton (Jan 14 2025 at 10:00):The netlify build has been failing, I'll look into it
Anton (Jan 14 2025 at 12:13):Fixed :)
Anton (Jan 14 2025 at 15:20):snake_case, PNC and "${str}" is done for the unicode package https://github.com/roc-lang/unicode/pull/24
Notification Bot (Jan 14 2025 at 16:36):A message was moved from this topic to #beginners > Trouble updating roc by JanCVanB.
jan kili (Jan 14 2025 at 17:09):@Luke Boswell What do you think? https://github.com/roc-lang/roc/pull/7513 (tested with Firefox Web Developer Tools, not locally built)
Screenshot_20250114_101351.png
Update: tested locally; symmetrized
Screenshot_20250114_104607.png
Anton (Jan 14 2025 at 17:21):I have a strong desire for symmetric emoji's (same on both sides) :p
Anthony Bullard (Jan 14 2025 at 20:21):Should we put in some work to align the tutorial with the design language of the docs?
Sam Mohr (Jan 14 2025 at 20:21):I'd love that for the whole roc-lang.org
Anthony Bullard (Jan 14 2025 at 20:32):Yeah, if I got the sign off from Richard I would be happy to lead that effort
Anthony Bullard (Jan 14 2025 at 20:32):Might be a great v0.1.0 thing
Sam Mohr (Jan 14 2025 at 20:40):It'd be good to have then, but it'd also be useful now
Sam Mohr (Jan 14 2025 at 20:40):Not sure if it's important to wait to do this, but it would definitely be nice to have a Wow Factor for v0.1.0
Anthony Bullard (Jan 14 2025 at 20:53):Yeah the most important thing is getting the v0.1.0 checklist done. But having this done and ready for v0.1.0 would make for a coherent story
Richard Feldman (Jan 14 2025 at 21:09):Anthony Bullard said:
Yeah, if I got the sign off from Richard I would be happy to lead that effort
go for it! :thumbs_up:
Richard Feldman (Jan 14 2025 at 21:09):you did a great job with the docs :smiley:
Anthony Bullard (Jan 14 2025 at 21:10):Thanks Richard! After new lambda syntax that will be My Next
Ian McLerran (Jan 16 2025 at 01:11):Roc-ansi and roc-isodate are ready with everything but the new unit syntax (and a proper basic-cli uri for examples):
snek_cse |
PNC | "${str}" |
|args| |
unit()? |
|
|---|---|---|---|---|---|
| :check: | :check: | :check: | :check: | roc-ansi | |
| :check: | :check: | :check: | :check: | roc-isodate |
Luke Boswell (Jan 17 2025 at 21:10):Anton said:
Luke Boswell said:
Any chance we could sneak this in with the current batch of changes too?
Let's officially make this the last thing though
@Anton I think we may have to include the and/or as well so that we can also include zero args || -- depending on how that all resolves. I'm not 100% across the details of this, but it seems @Sam Mohr is working on that.
The alternative I guess is to roll back some of the changes we've staged, and slim the scope back to just snek_cse, PNC and"${str}".
I favour waiting a little longer to get the |args| and unit () (and possibly and/or), because it will be one less break-the-world change we need to coordinate across the ecosystem -- and these features were all designed to work nicely together.
The examples we've staged for the upgrade, are looking really nice. I think with all the changes discussed above we will have a solid foundation and future changes for SD will be much less of a breaking impact.
Sam Mohr (Jan 17 2025 at 21:12):Hmm, yeah, implementing and and or first might help
Sam Mohr (Jan 17 2025 at 21:20):I'll start on those today
Anton (Jan 18 2025 at 10:12):Sounds good
Sam Mohr (Jan 18 2025 at 10:13):In theory, and and or are finished, and || is basically done but I have lots of tests to update and maybe a couple quirks to iron out
Luke Boswell (Jan 20 2025 at 00:21):Started a WIP branch for the zero args () changes... https://github.com/roc-lang/basic-cli/pull/315
Luke Boswell (Jan 20 2025 at 00:22):Basically just removing all the tie fighters ({}) |{}|
Sam Mohr (Jan 20 2025 at 00:23):Awesome!
Luke Boswell (Jan 20 2025 at 08:31):I've upgraded roc-ray -- it's a WIP because we'll need releases of some deps to finish all the examples and pass CI, but it's working with the breaking changes :smile:
https://github.com/lukewilliamboswell/roc-ray/tree/snake_case_builtins
Oskar Hahn (Jan 20 2025 at 10:36):Could you give a short status update? Are all planned changes merged?
It is hard to keep up with all the changes.
Sam Mohr (Jan 20 2025 at 11:19):In Roc core, the following have been implemented/merged:
roc format --migrate snake_case supportroc format --migrate PNC support"${str}" interpolation in addition to the old "$(str)", with the plan to remove the old interpolation syntax eventually|args| ... in addition to the old \args -> ...roc format movement to new args syntaxThere are two breaking changes remaining that we'd like to get in to Roc core:
lazy_load = || File.read!(...))({}), but will break a lot of code as a result.{ x, y } to { x, y, ... }({}) to () change which is optional, but nice. Sam Mohr (Jan 20 2025 at 11:20):For the most part, the important packages and platforms in the ecosystem have been updated to snake_case, PNC, "${str}" interpolation, and somewhat to |args|. The last two have not been changed yet, except for maybe one or two by Luke
Luke Boswell (Jan 20 2025 at 11:21):Sorry, on my phone so it wont be a long one.
Just waiting for the last PR to land https://github.com/roc-lang/roc/pull/7529
Sam's fighting through some bugs with that.
Then we land the basic-cli staged changes for zero args. Cut a testing release.
Upgrade the last bit for all the staged package PRs, and make pre-releases.
And that's basically it... to get us to pre-releases. Then it's upgrade various things and look for any issues. Update the tutorial and website etc and when we're happy we can promote the prereleases to latest.
Sam Mohr (Jan 20 2025 at 11:21):We were hoping to get a release within a week or two, but I guess that just comes down to how successful I am with getting past this supposed mono issue for zero-arg functions
Sam Mohr (Jan 20 2025 at 11:25):I think in the meantime, a good task for anyone that has extra free time could be to update the tutorial for the above syntax. It's mostly untouched from all of these changes (though we again got some cleanup on it from Luke the Duke), so getting that ready for a new release with all of these changes would be a great help! Please just announce if you want to own that effort, so we don't have three different people try to do it at the same time
Anthony Bullard (Jan 20 2025 at 11:56):I'm going to try to find some time to help in some way on these tasks, so PLEASE if someone is picking up any of the above please let us know here in this thread!
Sam Mohr (Jan 20 2025 at 13:41):A draft PR for the .. spreads in record destructures feature: https://github.com/roc-lang/roc/pull/7534
Sam Mohr (Jan 20 2025 at 13:42):It's not finished, but most of the work is done (ignoring testing). An explanation of the remaining work is in the description
Sam Mohr (Jan 20 2025 at 13:42):Okay, off to bed. I can answer any questions in the morning!
Sam Mohr (Jan 20 2025 at 13:42):And by that, I mean the afternoon...
Anthony Bullard (Jan 20 2025 at 16:36):I spent about an hour doing some println debugging on your branch Sam, and really the only thing I learned is that the issue _seems_ to begin before even specialization
Anthony Bullard (Jan 20 2025 at 16:37):But that could be a gross misreading of the situation
Anthony Bullard (Jan 20 2025 at 17:22):Here's the PR if someone wants to look at my notes and see if I'm even close to tracking down the issue:
https://github.com/roc-lang/roc/pull/7529
Luke Boswell (Jan 23 2025 at 02:35):I'd like to throw the idea out there of taking what we have in current main, and cutting our plans back to this scope. So effectively pushing zero args () in the builtins and {..} spread operator for open-closed records back for another breaking change.
These changes are sounding like they're deeper than we thought with some unexpected issues and are more behavioural than simple syntax changes. So it may be beneficial to let them simmer longer for testing. I'm guessing we could probably push to have them finished some time this weekend or next week -- but we are putting extra pressure on ourselves to do that.
My thoughts are we could use our time today and tomorrow to cut testing/pre-releases of roc and basic-cli... and update all-the-things to land the staged changes and update things like the examples and tutorial etc.
What do people think?
Sam Mohr (Jan 23 2025 at 02:35):I'm on the same page. I don't want to up people from getting a release, and we don't know how much longer we are delaying things with these last two changes
Anthony Bullard (Jan 23 2025 at 02:36):I would LOVE to get PNC, snake case and other more stable things out the door
Anthony Bullard (Jan 23 2025 at 02:37):I think we should update the tutorial first though, right?
Sam Mohr (Jan 23 2025 at 02:37):We should prep a PR, at least
Anthony Bullard (Jan 23 2025 at 02:37):Ok, sounds good
Sam Mohr (Jan 23 2025 at 02:37):And then merge it when everything else goes out the door
Anthony Bullard (Jan 23 2025 at 02:37):Sounds like a winner
Anthony Bullard (Jan 23 2025 at 02:37):So letβs recap whatβs going out with this release then?
Anthony Bullard (Jan 23 2025 at 02:38):(Of course expecting this plan has consensus and BDFN sign off)
Anthony Bullard (Jan 23 2025 at 02:39):I think itβs this
Anthony Bullard (Jan 23 2025 at 02:39):In Roc core, the following have been implemented/merged:
roc format --migrate snake_case supportroc format --migrate PNC support"${str}" interpolation in addition to the old "$(str)", with the plan to remove the old interpolation syntax eventually|args| ... in addition to the old \args -> ...roc format movement to new args syntaxQuoting @Sam Mohr
Luke Boswell (Jan 23 2025 at 02:40):snek_cse |
PNC | "${str}" |
|args| |
zero-arg () |
open-closed {..} |
|---|---|---|---|---|---|
| :check: | :check: | :check: | :check: | :cross_mark: | :cross_mark: |
Anthony Bullard (Jan 23 2025 at 02:42):Iβll focus my energy on helping with this
Anthony Bullard (Jan 23 2025 at 02:42):Do we have a todo list?
Anthony Bullard (Jan 23 2025 at 02:42):Iβm happy to work on tutorial
Anthony Bullard (Jan 23 2025 at 02:43):Iβve been doing a lot of doc writing at work lately
Sam Mohr (Jan 23 2025 at 02:43):Validate that the important platforms and packages have been updated, including:
Sam Mohr (Jan 23 2025 at 02:43):Most of them are already updated
Anthony Bullard (Jan 23 2025 at 02:43):Do we have a list of top 10 packages?
Sam Mohr (Jan 23 2025 at 02:43):https://github.com/topics/roc-lang
Sam Mohr (Jan 23 2025 at 02:44):And also update roc-lang/examples and Exercism
Anthony Bullard (Jan 23 2025 at 02:45):I think at least roc-lang official packages, examples, exercism, and maybe the roc-lang contributor-owned packages all updated would be ideal
Anthony Bullard (Jan 23 2025 at 02:45):I think everything should just work with a roc format βmigrate
Luke Boswell (Jan 23 2025 at 02:46):(deleted)
Anthony Bullard (Jan 23 2025 at 02:46):Iβm so glad Iβve written the Roclings exercises to target this release (but not zero args or spread)
Anthony Bullard (Jan 23 2025 at 02:47):@Luke Boswell that link brings me back to the same message
Anthony Bullard (Jan 23 2025 at 02:47):Might be an issue on mobile
Luke Boswell (Jan 23 2025 at 02:47):I think this is the status
snek_cse |
PNC | "${str}" |
|args| |
|
|---|---|---|---|---|
| :check: | :check: | :check: | :check: | basic-cli |
| :check: | :check: | :check: | basic-webserver | |
| :check: | :check: | :check: | examples | |
| :check: | :check: | roc-html | ||
| :check: | :check: | roc-random | ||
| :check: | :check: | :check: | roc-parser | |
| :check: | :check: | :check: | roc-json | |
| :check: | :check: | roc-ansi |
Luke Boswell (Jan 23 2025 at 02:48):I'm missing a couple that @Ian McLerran has staged as well -- but the above are the minimum we need to execute a full upgrade including all the roc examples
jan kili (Jan 23 2025 at 05:11):Does that mean https://github.com/roc-lang/basic-cli/pull/315 no longer blocks cutting the basic-cli@0.19.0 release?
Oops yeah you said that. Yay!
Luke Boswell (Jan 23 2025 at 05:12):That is my proposal above... and it looks like there is pretty much consensus to do that.
Anton (Jan 23 2025 at 10:09):Sounds good! I think we can do Result.map > Result.map_ok as well?
Anton (Jan 23 2025 at 10:09):I'll do roc-unicode
Luke Boswell (Jan 23 2025 at 10:09):Oh yeah, I forgot that landed in main too. :grinning:
Anton (Jan 23 2025 at 10:11):I'll make a PR to weaver as well (for Result.map_ok) because it's used by the basic-webserver build.roc
Sam Mohr (Jan 23 2025 at 10:12):Thanks!
Anton (Jan 23 2025 at 12:54):basic-cli 0.19.0 pre-release is available
Anton (Jan 23 2025 at 13:07):I'm going to look at #7461, I'm hitting it with weaver
Anthony Bullard (Jan 23 2025 at 14:13):Just making it clear - I am working on the tutorial and homepage
Anthony Bullard (Jan 23 2025 at 14:49):An interesting observation on the interactive example on the homepage - everything is effectual:
Screenshot 2025-01-23 at 8.52.32 AM.png
Anthony Bullard (Jan 23 2025 at 14:51):That's a lot of ! and ?
Richard Feldman (Jan 23 2025 at 15:02):that was a goal!
Richard Feldman (Jan 23 2025 at 15:02):I want to show that this is a functional programming language where I/O is nice
Richard Feldman (Jan 23 2025 at 15:03):btw we should change the syntax highlighting there - ! should not be syntax-highlighted
Anthony Bullard (Jan 23 2025 at 15:04):Sure thing
Anthony Bullard (Jan 23 2025 at 15:04):I think I've updated all the syntax and explanations.
Anthony Bullard (Jan 23 2025 at 15:04):There was more to do here than I expected!
Anthony Bullard (Jan 23 2025 at 15:06):There we go!
Screenshot 2025-01-23 at 9.06.34 AM.png
Anthony Bullard (Jan 23 2025 at 15:06):I think that definitely looks better
Richard Feldman (Jan 23 2025 at 15:07):I think it'll look even better with snake_case
Anthony Bullard (Jan 23 2025 at 15:07):Shoot, I didn't even see that yet. Working on it
Anthony Bullard (Jan 23 2025 at 15:10):Screenshot 2025-01-23 at 9.10.15 AM.png
Anthony Bullard (Jan 23 2025 at 15:11):Should I call out the snake_case the first time we introduce it (line 2)?
Richard Feldman (Jan 23 2025 at 15:12):nah
Richard Feldman (Jan 23 2025 at 15:12):I don't think it's notable to people seeing the language for the first time
Richard Feldman (Jan 23 2025 at 15:13):also, I think we should consider changing the first line to not use |> anymore
Anthony Bullard (Jan 23 2025 at 15:13):Last question. Do I keep this formatting?
Screenshot 2025-01-23 at 9.13.34 AM.png
Richard Feldman (Jan 23 2025 at 15:14):it could now be:
store_email!(Path.from_str("url.txt")) ? handle_err!
Richard Feldman said:
also, I think we should consider changing the first line to not use
|>anymore
You want
store_email!(Path.to_str("url.txt"))
|> ....
Instead?
Anthony Bullard (Jan 23 2025 at 15:15):Oh!
Anthony Bullard (Jan 23 2025 at 15:15):Can ? take an effectful function?
Anthony Bullard (Jan 23 2025 at 15:16):I didn't think it could
Richard Feldman (Jan 23 2025 at 15:16):it can yeah
Richard Feldman (Jan 23 2025 at 15:16):because it desugars to a when
Richard Feldman (Jan 23 2025 at 15:16):so you can use whatever in there
Anthony Bullard (Jan 23 2025 at 15:17):As long as the return type unifies with the function
Anthony Bullard (Jan 23 2025 at 15:17):Ok
Anthony Bullard (Jan 23 2025 at 15:17):This is just to get people familiar with the new error handling, instead of |> which is going away?
Richard Feldman (Jan 23 2025 at 15:17):Anthony Bullard said:
Last question. Do I keep this formatting?
Screenshot 2025-01-23 at 9.13.34 AM.png
I'd probably put the close paren on the next line
Anthony Bullard (Jan 23 2025 at 15:19):I wonder if functional programmers will wonder where pipe is since we are in this intermediate state....
Richard Feldman (Jan 23 2025 at 15:19):yeah I'm okay with that
Richard Feldman (Jan 23 2025 at 15:20):the main thing is that I don't want to advertise it if we're planning to replace it :big_smile:
Richard Feldman (Jan 23 2025 at 15:24):as an aside, I wonder if after static dispatch we should just have the snippet be one line:
Screenshot 2025-01-23 at 10.23.29β―AM.png
this already tells you:
Richard Feldman (Jan 23 2025 at 15:24):it's a lot of info for one line!
Anthony Bullard (Jan 23 2025 at 15:25):I think seeing that right under the word functional could do two things:
Anthony Bullard (Jan 23 2025 at 15:26):Though I agree about the density of information making this beautiful and succinct
Richard Feldman (Jan 23 2025 at 15:26):doesn't quite fit on mobile, looks like it's 4 characters too long
Screenshot 2025-01-23 at 10.25.39β―AM.png
we could have songs display as s on mobile by having the rest of the word be display:none in css:
Screenshot 2025-01-23 at 11.21.21β―AM.png
Anthony Bullard (Jan 23 2025 at 15:27):Richard Feldman said:
doesn't quite fit on mobile, looks like it's 4 characters too long
I wonder if on mobile you could get away with bumping the code sample font size down a bit
Richard Feldman (Jan 23 2025 at 15:27):Anthony Bullard said:
I think seeing that right under the word functional could do two things:
- Tickle someones brain ("How does a functional language have methods?")
- Confuse someone ("A functional language doesn't have methods....what is songs here?")
yeah that's good though! The point of that initial code snippet is to:
Anthony Bullard (Jan 23 2025 at 15:28):Yeah, that's probably true.
Anthony Bullard (Jan 23 2025 at 15:28):But we have a ways to go before we get to this snippet being real :-)
Anthony Bullard (Jan 23 2025 at 15:28):It'll be a day to celebrate when it is though
Richard Feldman (Jan 23 2025 at 15:28):yep, just thinking ahead :big_smile:
Anthony Bullard (Jan 23 2025 at 15:30):It'd be nice if you could fit some new error handling stuff in there too, somehow
Anthony Bullard (Jan 23 2025 at 15:30):But maybe have map_try! and something that could fail would be too much
Anthony Bullard (Jan 23 2025 at 15:31):Something like:
songs.map_try!(|song| Http.get!("https://example.com/songs/${song.id}", Json.utf8)) ? SongFetchError
WIP PR with just homepage changes:
https://github.com/roc-lang/roc/pull/7544
Sam Mohr (Jan 23 2025 at 15:53):Would we actually format that first code example like that?
Sam Mohr (Jan 23 2025 at 15:53):Probably okay for now
Richard Feldman (Jan 23 2025 at 16:05):yeah I don't want to worry about it too much
Richard Feldman (Jan 23 2025 at 16:06):I think the closing paren being on its own line is a good idea because it's kind of strange otherwise
Richard Feldman (Jan 23 2025 at 16:06):but having both arguments on one line seems ok even though the formatter wouldn't do that
Richard Feldman (Jan 23 2025 at 16:06):but either way we're going to change it again when we get to static dispatch :big_smile:
Ian McLerran (Jan 23 2025 at 21:48):@Luke Boswell, roc-ansi should be good to go - has all syntax changes and examples are using the pre-release of basic-cli (v0.19.0)
@Sam Mohr I opened a PR into your snake_case branch of roc-json which completes the syntax upgrades and the adds basic-cli pre-release as well
Luke Boswell (Jan 23 2025 at 22:43):roc-json pre-release
I found a temporary issue with @Hannes bundle script... it doesn't use the TESTING release of roc so it can't build the bundle. I just did that manually using roc build --bundle .tar.gz package/main.roc and uploaded the gz.
Run hasnep/bundle-roc-library@v0.1.0
Running bundle command 'roc build --bundle .tar.br package/main.roc'.
thread 'main' panicked at crates/packaging/src/tarball.rs:294:9:
package/Json.roc failed to parse: NotEndOfFile(@3811)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Error: Command failed: roc build --bundle .tar.br package/main.roc
thread 'main' panicked at crates/packaging/src/tarball.rs:294:9:
package/Json.roc failed to parse: NotEndOfFile(@3811)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Ian McLerran said:
Luke Boswell, roc-ansi should be good to go - has all syntax changes and examples are using the pre-release of basic-cli (v0.19.0)
Thank you Ian... here is the published pre-release
Luke Boswell (Jan 23 2025 at 23:51):I'm posting as I go in here... but I'll make a summary post at the end of my day with where I get to.
Luke Boswell (Jan 24 2025 at 00:02):Actually I realised I can just make a GIST and update it as I go... to save on the spam. Here's the current status
https://gist.github.com/lukewilliamboswell/09ced1b2f606b05b1e74f8f6dfdd3f9d
Luke Boswell (Jan 24 2025 at 02:59):Hitting a snag with Weaver... @Sam Mohr and I are investigating
+ roc ./build.roc -- --roc roc
thread 'main' panicked at crates/compiler/mono/src/reset_reuse.rs:1244:42:
Expected symbol to have a layout. It should have been inserted in the environment already.
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
I'm about 70% of the way done with the Tutorial. Hopefully will be able to add that to my PR tomorrow morning before I go to work
Hannes (Jan 24 2025 at 04:03):Luke Boswell said:
I found a temporary issue with Hannes bundle script... it doesn't use the TESTING release of roc so it can't build the bundle.
If you're using the setup-roc action, then you can use the new testing option to install a testing version of Roc, like this. Then the bundle action should pick up the correct Roc version from the PATH.
Luke Boswell (Jan 24 2025 at 04:08):Thanks @Hannes I missed that... or at least forgot about it
Luke Boswell (Jan 24 2025 at 04:15):This is fun... lot's of places where this cleans the examples up
# Get current working directory
cwd = Result.map_err(
Env.cwd!({}),
|CwdUnavailable| Exit(1, "Unable to read current working directory"),
)?
# using the new spaced `?` operator
cwd = Env.cwd!({}) ? |CwdUnavailable| Exit(1, "Unable to read current working directory")
Here's the latest status update copied from my live gist -- leave a comment on the gist if you would like me to add anything.
snek_cse |
PNC | "${str}" |
pipe args |
PR / Release |
|---|---|---|---|---|
| :check: | :check: | :check: | :check: | basic-cli 0.19.0 |
| :check: | :check: | :check: | :check: | basic-webserver PR <br>READY for release |
| :check: | :check: | :check: | examples PR | |
| :check: | :check: | :check: | :check: | roc-html PR <br>awating Hasnep review, testing release |
| :check: | :check: | :check: | :check: | roc-random 0.5.0 |
| :check: | :check: | :check: | :check: | roc-parser 0.10.0 |
| :check: | :check: | :check: | :check: | roc-json 0.12.0 |
| :check: | :check: | :check: | :check: | roc-ansi 0.8.0 |
| :check: | :check: | :check: | :check: | roc-isodate 0.6.0 |
| :check: | :check: | :check: | roc-unicode PR | |
| :check: | :check: | :check: | :check: | roc-utils 0.3.0 |
| :check: | :check: | :check: | :check: | weaver 0.6.0 |
| :check: | :check: | :check: | :check: | plume 0.4.0 |
| :check: | :check: | :check: | :check: | rtl PR |
| :check: | :check: | :check: | :check: | roc-htmx-tailwindcss-demo <br>BROKEN -- looks like a basic-webserver issue |
I was hoping to get to the examples today... but that might have to wait until tomorrow or next week unless someone picks those up before me.
I've got an annoying bug in my roc-htmx-tailwind demo, that is probably basic-webserver related... but will require some effort to track down.
Sam Mohr (Jan 24 2025 at 05:54):I'll get examples
Sam Mohr (Jan 24 2025 at 06:24):Okay, the examples PR should have everything
Sam Mohr (Jan 24 2025 at 07:27):Unicode should also be good to go
Sam Mohr (Jan 24 2025 at 07:27):Including updating the codegen
Anton (Jan 24 2025 at 09:14):Luke Boswell said:
Hitting a snag with Weaver... Sam Mohr and I are investigating
+ roc ./build.roc -- --roc roc thread 'main' panicked at crates/compiler/mono/src/reset_reuse.rs:1244:42: Expected symbol to have a layout. It should have been inserted in the environment already. note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
This is what I was investigating too by the way but definitely can't hurt to have more eyes on it :)
Anton said:
I'm going to look at #7461, I'm hitting it with weaver
Luke Boswell (Jan 24 2025 at 09:17):We solved the issue and made a release for weaver... at least a workaround. It looks like a tag unification bug.
Anton (Jan 24 2025 at 09:22):Can you or Sam do a brief write up of your investigation and workaround in https://github.com/roc-lang/roc/issues/7461?
Anton (Jan 24 2025 at 09:23):I am going to keep looking at this issue, if we already hit it in wasm4, plume and weaver it's going to happen all over the place.
Luke Boswell (Jan 24 2025 at 09:46):The issue was from returning an Err with one of these tag unions. We think it may be related to the aliasing or unification of the tag union.
NameAtSubcommand : { name : Str, subcommand_path : List Str }
OptionAtSubcommand : { option : OptionConfig, subcommand_path : List Str }
ParamAtSubcommand : { param : ParameterConfig, subcommand_path : List Str }
## The types of errors that might be found in a misconfigured CLI.
CliValidationErr : [
OverlappingParameterNames { first : Str, second : Str, subcommand_path : List Str },
OverlappingOptionNames { left: OptionAtSubcommand, right: OptionAtSubcommand },
InvalidShortFlagName NameAtSubcommand,
InvalidLongFlagName NameAtSubcommand,
InvalidCommandName NameAtSubcommand,
InvalidParameterName NameAtSubcommand,
OptionMustHaveShortOrLongName { subcommand_path : List Str },
InvalidOptionValueType OptionAtSubcommand,
InvalidParameterValueType ParamAtSubcommand,
OverrodeSpecialHelpFlag OptionAtSubcommand,
OverrodeSpecialVersionFlag OptionAtSubcommand,
]
I'd say we're didn't get anywhere close to an underlying issue, but the symptom is what Luke pointed out
Anthony Bullard (Jan 24 2025 at 14:34):Tutorial is getting very close. Doing a review right now
Anthony Bullard (Jan 24 2025 at 14:47):Ok, I think it's mostly done. I have a single TODO:
try keyword? Anthony Bullard (Jan 24 2025 at 15:00):I'm going to push what I have, and check back at lunch for people's opinions
Anton (Jan 24 2025 at 15:02):
- Do we get rid of mentions of
trykeyword?
@Richard Feldman
Brendan Hansknecht (Jan 24 2025 at 16:02):I think we should remove mentions given it is deprecated now that we have PNC so ? is preferred.
Anthony Bullard (Jan 24 2025 at 18:14):Well only Brendan has responded....I think I'm just going to go for it. I'll promote the "Under construction" section for "?" postfix and put it in place of the section on "try"
Sam Mohr (Jan 24 2025 at 18:15):Kill try dead
Anthony Bullard (Jan 24 2025 at 18:16):I think we then should do some work to format try as ? then when we format all applys as PNC
Sam Mohr (Jan 24 2025 at 18:16):That's a good idea
Anthony Bullard (Jan 24 2025 at 18:17):There are semantically identical correct?
Sam Mohr (Jan 24 2025 at 18:17):Did we fix the ? + |> bug?
Anthony Bullard (Jan 24 2025 at 18:17):@Anton ? I think so..
Sam Mohr (Jan 24 2025 at 18:17):They literally desugar to the same thing, so yes
Anton (Jan 24 2025 at 18:19):I did not yet solve https://github.com/roc-lang/roc/issues/7530
Anton (Jan 24 2025 at 18:56):I think I know a decent workaround for the #7461 issue. Tomorrow I'll make a small investigative report for J.Teeuwissen, this part of the code is from his master thesis, he may know a proper fix. If not, we can ship my workaround.
Sam Mohr (Jan 24 2025 at 18:58):Awesome to have so many smart people at our disposal
Anthony Bullard (Jan 24 2025 at 19:01):I have push up what I think is the last of the website/tutorial changes to my PR. Will mark it as ready for review
Luke Boswell (Jan 24 2025 at 19:06):I could review in a few hours, if you need me :grinning:
Sam Mohr (Jan 24 2025 at 19:07):I should have it covered
Anthony Bullard (Jan 24 2025 at 19:52):I have addressed all review feedback
Sam Mohr (Jan 24 2025 at 19:57):There's a comment from Anton you didn't fix at the top of the PR comments
Luke Boswell (Jan 24 2025 at 19:59):I'm just building basic-ssg now... I forgot to upgrade that yesterday
Anthony Bullard (Jan 24 2025 at 20:03):Sorry, missed that. Fixed and pushed
Sam Mohr (Jan 24 2025 at 20:04):@Anthony Bullard 2 comments left from me, then we're good
Anthony Bullard (Jan 24 2025 at 20:07):The last thing is the comment in the Roc file, is this needed to ship?
Anthony Bullard (Jan 24 2025 at 20:08):If so, that's fine. It'll just make the logic for handling the space a little more complicated.
Sam Mohr (Jan 24 2025 at 20:08):These are both code cleanliness
Sam Mohr (Jan 24 2025 at 20:08):I'm happy to merge
Sam Mohr (Jan 24 2025 at 20:09):Approved, up to you when to merge
Anthony Bullard (Jan 24 2025 at 20:14):I'm trying to address that comment and dealing with some stupid compiler crash due to something deep in mono being unhappy about when branches being empty...
Sam Mohr (Jan 24 2025 at 20:16):Not worth the effort
Anthony Bullard (Jan 24 2025 at 20:18):Fixed
Anthony Bullard (Jan 24 2025 at 20:18):See if you are satisfied
Anthony Bullard (Jan 24 2025 at 20:18):If you see a when nested in an if-then-else, you know why
Sam Mohr (Jan 24 2025 at 20:20):Bellissimo
Sam Mohr (Jan 24 2025 at 20:20):re-approved
Anthony Bullard (Jan 24 2025 at 20:20)::tada:
Anthony Bullard (Jan 24 2025 at 20:21):That was a _LOT_ of work. Hopefully we can find a way to make that slightly less painful for zero-args and SD
Anthony Bullard (Jan 24 2025 at 20:21):If not for the Glory of VIM I may not have had the fortitude to get it done
Sam Mohr (Jan 24 2025 at 20:22):I expect we won't be doing nearly as much work for other syntax changes
Sam Mohr (Jan 24 2025 at 20:22):But the future path is for this to be in multiple files
Anthony Bullard (Jan 24 2025 at 20:22):Yeah, that'll help a bit
Sam Mohr (Jan 24 2025 at 20:22):Which should fall out of the rewrite?
Anthony Bullard (Jan 24 2025 at 20:23):I think so. Something more Rust Book-y would be nice
Luke Boswell (Jan 24 2025 at 20:23):I need to head out for a few hours... heres the pre-release for basic-ssg https://github.com/lukewilliamboswell/basic-ssg/releases/tag/0.8.0
Sam Mohr (Jan 24 2025 at 20:23):https://github.com/rust-lang/mdBook pretty nice
Anthony Bullard (Jan 24 2025 at 20:23):In terms of navigation/structure - not content
Luke Boswell (Jan 24 2025 at 20:23):I have a CI issue I didn't resolve so I haven't merged into main
Anthony Bullard (Jan 24 2025 at 20:24):It looks like from the table we just need to reformat examples and roc-unicode to have pipe args?
Anthony Bullard (Jan 24 2025 at 20:25):Oh no, looks like roc-unicode is good
Sam Mohr (Jan 24 2025 at 20:25):I already did those
Anthony Bullard (Jan 24 2025 at 20:25):The examples PR is draft...
Anthony Bullard (Jan 24 2025 at 20:26):So I guess we are just waiting on that PR to land
Anthony Bullard (Jan 24 2025 at 20:27):Are we happy with basic-ssg just having a pre-release compatible ?
Luke Boswell (Jan 24 2025 at 20:33):I'm not sure what you mean?
Anthony Bullard (Jan 24 2025 at 20:34):I mean are we blocked on shipping the nightly release until basic-ssg has a full release that is compatible with it
Luke Boswell (Jan 24 2025 at 20:36):I think we should make a release for basic webserver and have examples pass CI before we promote everything to latest.
We should be able to achieve that today, and then land your tutorial update with that.
Anthony Bullard (Jan 24 2025 at 20:36):Sounds like a plan!
Luke Boswell (Jan 24 2025 at 20:37):I'm not sure where we got to with webserver and examples overnight. I'll have a look later and make another summary post with everything.
Anthony Bullard (Jan 24 2025 at 20:37)::+1:
Luke Boswell (Jan 24 2025 at 20:37):Just out for a fun run and breakfast :smile:
Sam Mohr (Jan 24 2025 at 21:02):Once we merge all this stuff, we should move ahead with Luke's #ideas > roc release management plan
Sam Mohr (Jan 24 2025 at 21:02):It feels like the right time
Luke Boswell (Jan 24 2025 at 23:01):Luke Boswell said:
I have a CI issue I didn't resolve so I haven't merged into main
:man_facepalming: when you download a linux binary and try to run that in a macos CI...
Luke Boswell (Jan 25 2025 at 00:05):Luke Boswell said:
I need to head out for a few hours... heres the pre-release for basic-ssg https://github.com/lukewilliamboswell/basic-ssg/releases/tag/0.8.0
Bit of a fast follow up but heres a full release of basic-cli https://github.com/lukewilliamboswell/basic-ssg/releases/tag/0.9.0
I've restored the prebuilt Windows host binaries.
@Brendan Hansknecht -- I just removed the TCP/HTTP features from basic-ssg for now until we land that hyper upgrade. It was such a new feature, no-one could have possibly used it yet anyway.
Luke Boswell (Jan 25 2025 at 00:27):I've kicked-off CI for building basic-webserver 0.12.0
Luke Boswell (Jan 25 2025 at 00:34):Ok, so I've looked at everything now @Anthony Bullard and updated my
live gist
It looks like everything is ready, we have pre-releases for everything and all tests are passing everywhere.
All we need now is a new release of basic-webserver, then that will complete examples.
Assuming no new issues with those last steps, I recommend we mint a fresh nightly, promote all the releases, and merge the tutorial update PR to update the website.
:smiley:
Anthony Bullard (Jan 25 2025 at 00:38):LFG!
Anton (Jan 25 2025 at 09:02):Sam Mohr said:
But the future path is for this to be in multiple files
I think we should try to keep the code in the md file, make the snippets self contained and implement hidden roc line support (some discussion in) in basic-ssg and roc test file.md. Things are much more likely to stay in sync if the code and explanation do not live in separate files. Files getting out of sync has already proved to be a problem with the examples repo which uses the snippet transclusion.
Sam Mohr (Jan 25 2025 at 09:04):I'm talking about when Richard entirely redoes the tutorial. Until then, the current format is very convenient even if its annoying to update the whole thing in one go
Anton (Jan 25 2025 at 09:04):Oh like one file per chapter or something like that?
Sam Mohr (Jan 25 2025 at 09:04):Yep
Sam Mohr (Jan 25 2025 at 09:05):And we have markdown checking already at least somewhat working, we'd use that for validating embedded examples
Anton (Jan 25 2025 at 09:06):Assuming no new issues with those last steps, I recommend we mint a fresh nightly, promote all the releases, and merge the tutorial update PR to update the website.
A new nightly will break exercism, I'll update https://github.com/exercism/roc/pull/171 today so that's ready.
Sam Mohr (Jan 25 2025 at 09:07):Let me/us know if you would like some help with that
Anton (Jan 25 2025 at 09:07):Can someone make a minimal upgrade guide from current nightly to current TESTING?
Sam Mohr (Jan 25 2025 at 09:08):I'll look into it
Sam Mohr (Jan 25 2025 at 09:09):Do you know how to tell which commit the nightly is from? All I can see is the time of upload
Anton (Jan 25 2025 at 09:11):If you download it and extract it, the commit is in the folder name
Sam Mohr (Jan 25 2025 at 09:14):Thanks
Anthony Bullard (Jan 25 2025 at 11:42):Upgraded basic-ssg for www
Sam Mohr (Jan 25 2025 at 12:24):I made an upgrade guide for the changes and sent them to Anton
Anton (Jan 25 2025 at 12:35):basic-webserver pre-release is here
Anton (Jan 25 2025 at 12:51):All tests passed on the examples PR https://github.com/roc-lang/examples/pull/228
Anton (Jan 25 2025 at 13:12):I also hit https://github.com/roc-lang/roc/issues/7530 again in the exercism repo. It's easy to work around if you know what's up, but it's a bad upgrade experience. Can someone look into a fix?
Anton (Jan 25 2025 at 13:12):I'd like to hold the release until this issue is fixed but feel free to share your opinion.
Sam Mohr (Jan 25 2025 at 13:13):Let me look into it now
Anton (Jan 25 2025 at 16:11):I have to head off to go to my neighbor's birthday party.
It looks like my workaround for #7461 is the only major thing that remains.
I'm going to attempt the TESTING>nightly release on Monday.
Anthony Bullard (Jan 27 2025 at 11:03):Do we have a list of all changes going out in this nightly? I mean outside of the obvious syntax changes? Hopefully spanning the ecosystem?
Anton (Jan 27 2025 at 11:15):Sam made an upgrade guide
Anton (Jan 27 2025 at 16:10):Due to #7548 we may need to redo some of the pre-releases
Sam Mohr (Jan 27 2025 at 16:11):We should only need to do that for code that wasn't working without that PR, right?
Anton (Jan 27 2025 at 16:11):e.g. basic-cli will need this for sure https://github.com/roc-lang/basic-cli/pull/319
Sam Mohr (Jan 27 2025 at 16:12):How did basic-cli get to prerelease with this break?
Sam Mohr (Jan 27 2025 at 16:12):Just wondering
Anton (Jan 27 2025 at 16:12):Sam Mohr said:
We should only need to do that for code that wasn't working without that PR, right?
I'm not sure
Anton (Jan 27 2025 at 16:12):Sam Mohr said:
How did
basic-cliget to prerelease with this break?
Let me check
Anton (Jan 27 2025 at 16:15):Ok, looks like we did not test Path.read_utf8, only File.read_utf8
Anton (Jan 27 2025 at 16:15):That makes this more likely "We should only need to do that for code that wasn't working without that PR, right?"
Sam Mohr (Jan 27 2025 at 16:15):Great!
Anton (Jan 27 2025 at 16:30):Path.read_utf8 was tested in the examples repo (CommandLineArgsFile) so "We should only need to do that for code that wasn't working without that PR" does not apply unfortunately
Anton (Jan 27 2025 at 16:34):File.read_utf8 calls Path.read_utf8internally
Anton (Jan 27 2025 at 16:38):INVALID TRY TARGET is a compile error so fortunately if it roc checks with the latest TESTING no new release will need to be made.
Anton (Jan 27 2025 at 18:57):It looks like my workaround for #7461 is the only major thing that remains
My workaround did not suffice, I've sent a message to J.Teeuwissen :fingers_crossed:
Anton (Jan 27 2025 at 18:59):For those willing to help out for this breaking release, we need to check for roc check errors for all these repos (except basic-cli). Can you make an extra column on your gist for this @Luke Boswell?
Anton (Jan 27 2025 at 19:00):I'm going to attempt the TESTING>nightly release on Monday.
This is going to take some more time...
Luke Boswell (Jan 27 2025 at 19:50):I am sure I've ran roc check on all those repos already. What is the issue here?
Luke Boswell (Jan 27 2025 at 19:52):I think basic-cli path thing slipped through because we made the upgrade and landed that in basic-cli main before we removed/changed the try thing from roc. So all the others should be fine.
Luke Boswell (Jan 27 2025 at 20:21):Anton said:
For those willing to help out for this breaking release, we need to check for
roc checkerrors for all these repos (except basic-cli). Can you make an extra column on your gist for this Luke Boswell?
I just ran roc check on everything again with no issues. I didn't check every example.
Anton (Jan 28 2025 at 10:10):Luke Boswell said:
I am sure I've ran roc check on all those repos already. What is the issue here?
PR#7548 changed desugaring but it looks like it rarely breaks things.
Anton (Jan 28 2025 at 10:11):I just ran
roc checkon everything again with no issues.
What version of roc did you use?
Anton (Jan 28 2025 at 11:00):Anton said:
My workaround did not suffice, I've sent a message to J.Teeuwissen :fingers_crossed:
J.Teeuwissen is on the case :detective:
Anthony Bullard (Jan 28 2025 at 11:14):So what is the status of the new release?
Anton (Jan 28 2025 at 11:19):Once #7461 is fixed we're ready to go, except for minor things like release notes etc.
Anton (Jan 28 2025 at 11:23):The current basic-cli 0.19.0 link will need to be replaced as well, due to PR#7548. I'm about to build a new basic-cli release.
Anton (Jan 28 2025 at 12:36):The old 0.19.0 link is gone now, it's now https://github.com/roc-lang/basic-cli/releases/download/0.19.0/Hj-J_zxz7V9YurCSTFcFdu6cQJie4guzsPMUi5kBYUk.tar.br
Anton (Jan 28 2025 at 12:37):Also did someone change basic-cli 0.19.0 to a draft release earlier?
Anton (Jan 28 2025 at 12:41):I don't use draft releases because publishing changes the assets links
Anton (Jan 28 2025 at 14:41):Luke Boswell said:
I didn't check every example.
Searching examples for "?(" should show you the spots that need to be changed.
Anton (Jan 28 2025 at 14:48):I just ran
roc checkon everything again with no issues. I didn't check every example.
basic-webserver did hit an error:
+ roc check ./examples/dir.roc
ββ INVALID TRY TARGET in ./examples/../platform/Path.roc βββββββββββββββββββββββ
This expression cannot be tried with the ? operator:
310β |> Result.map_err?(|read_err| FileReadErr(path, InternalIOErr.handle_err(read_err)))
^^^^^^^^^^^^^^
I expected a Result, but it actually has type:
Result ok a, (a -> b) -> Result ok b
Hint: Did you forget to wrap the value with an Ok or an Err tag?
ββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
1 error and 0 warnings found in 25 ms.
I'll make a new tar.br for that one.
Anthony Bullard (Jan 28 2025 at 15:02):Was it formatted that way?
Anton (Jan 28 2025 at 15:06):As in, was this output from roc format --migrate?
Anthony Bullard (Jan 28 2025 at 15:24):Yes
Anton (Jan 28 2025 at 15:32):Indeed:
basic-webserver on ξ HEAD (db94e89) via π¦ v1.79.0
β― cat platform/Path.roc | rg read_err
|> Result.mapErr? \read_err -> FileReadErr path (InternalIOErr.handle_err read_err)
basic-webserver on ξ HEAD (db94e89) via π¦ v1.79.0
β― roc format --migrate platform/Path.roc
basic-webserver on ξ HEAD (db94e89) [!] via π¦ v1.79.0
β― cat platform/Path.roc | rg read_err
|> Result.map_err?(|read_err| FileReadErr(path, InternalIOErr.handle_err(read_err)))
basic-webserver on ξ HEAD (db94e89) [!] via π¦ v1.79.0
β― roc version
roc built from commit 0e35e33f85, committed at 2025-01-28 09:57:55 UTC
Damn
Anthony Bullard (Jan 28 2025 at 16:01):Ok definitely file an issue for that assigned to me
Anton (Jan 28 2025 at 16:14): Anton (Jan 28 2025 at 16:16):Anton said:
Also did someone change basic-cli 0.19.0 to a draft release earlier?
Looks like github does this automatically when the tag is changed
Anton (Jan 28 2025 at 18:27):@J.Teeuwissen was able to fix #7461 :tada:
Anton (Jan 28 2025 at 18:39):The current basic-cli 0.19.0 link will need to be replaced as well
I've replaced the old basic-cli link everywhere I could.
Anton (Jan 28 2025 at 18:47):I would like to wait on #7555 before the release, any objections?
Sam Mohr (Jan 28 2025 at 18:48):You're online tomorrow, right?
Sam Mohr (Jan 28 2025 at 18:48):I might be able to fix that in like 20 minutes
Anthony Bullard (Jan 28 2025 at 21:54):I can do it tonight
Anthony Bullard (Jan 29 2025 at 03:01):Whoever wants to review it: https://github.com/roc-lang/roc/pull/7557
Anthony Bullard (Jan 29 2025 at 03:05):Hopefully all is well with this change, gotta go to bed :-)
Luke Boswell (Jan 29 2025 at 03:06):It looks good to me, I can nurse it through most issues
Anthony Bullard (Jan 29 2025 at 03:35):Looks like youβll have to merge manually since the fuzzer check is still failing
Joshua Warner (Jan 29 2025 at 05:11):@Anthony Bullard FWIW that fuzzing failure appears to be new from your PR
Luke Boswell (Jan 29 2025 at 05:12):Formatting bug; formatting didn't reparse to the same AST (after removing spaces)
* * * Source code before formatting:
-na(n)?()n
* * * Source code after formatting:
-na(n)()? n
How would we handle this in our fuzzer? should this be only behind the --migrate flag?
Joshua Warner (Jan 29 2025 at 05:13):This PR unconditionally moves the ? for pnc calls
Joshua Warner (Jan 29 2025 at 05:14):That part should probably be behind a --migrate flag
Joshua Warner (Jan 29 2025 at 05:14):If we don't want to put that behind --migrate, we'd need to also change the impl of Normalize to account for that
Joshua Warner (Jan 29 2025 at 05:15):I'd assert that it should be behind --migrate in that it is actually a semantic change (but for admittedly strange code)
Joshua Warner (Jan 29 2025 at 05:15):In fact, I'd go as far as to say that particular transformation shouldn't live long at all
Joshua Warner (Jan 29 2025 at 05:16):I believe that's blatently incorrect - but necessary temporarily, in order to help migrate some code that was incorrectly partially migrated
Joshua Warner (Jan 29 2025 at 05:18):n?(1) does actually have a distinct meaning now - in that n is a Result (Num->b) e, and you're unwrapping that func first and then calling it
Luke Boswell (Jan 29 2025 at 08:25):https://github.com/lukewilliamboswell/roc-ray/pull/85
WIP roc-ray upgrade -- almost completed. Needs a pass over docs and fresh nightlies for CI. But otherwise should be gtg :smiley:
Luke Boswell (Jan 29 2025 at 08:27):Also completed the upgrade for the zig and rust platform templates
https://github.com/lukewilliamboswell/roc-platform-template-zig
https://github.com/lukewilliamboswell/roc-platform-template-rust
Anthony Bullard (Jan 29 2025 at 10:31):It was my understanding that the try suffix was only valid on Applys. Not results in general
Sam Mohr (Jan 29 2025 at 10:32):you can do ok = result? if that's what you're talking about
Anthony Bullard (Jan 29 2025 at 10:33):That is wild. Ok thatβs what I get for trying to help 10 minutes before bed :rolling_on_the_floor_laughing:
Anthony Bullard (Jan 29 2025 at 10:34):So should we merge this at all or should I close it?
Sam Mohr (Jan 29 2025 at 10:35):Your formatting change already got merged earlier
Anthony Bullard (Jan 29 2025 at 10:35):Because fmt canβt know for certain if this is correct
Anthony Bullard (Jan 29 2025 at 10:35):Oh! Youβre right
Sam Mohr (Jan 29 2025 at 10:36)::shrug: it's pretty minor anyway, it's maybe annoying if it formats incorrectly but you'll get a compiler warning
Sam Mohr (Jan 29 2025 at 10:36):I think we're good to go
Anthony Bullard (Jan 29 2025 at 10:37):Hmm
Anthony Bullard (Jan 29 2025 at 10:38):Like Joshua said this should probably be reverted after some time
Sam Mohr (Jan 29 2025 at 10:38):Agreed
Anthony Bullard (Jan 29 2025 at 10:40):Or should remain in only the WSA->PNC migration
Anthony Bullard (Jan 29 2025 at 10:41):You actually couldnβt possibly express the same thing as func?(arg1, arg2) in WSA. Only func(arg1, arg2)?
Sam Mohr (Jan 29 2025 at 10:48):Unless we make (func_result?)(arg1, arg2) valid
Anthony Bullard (Jan 29 2025 at 10:54):Oh yeah, in WSA I guess you (maybe?) could write (func?) arg1 arg2
Anthony Bullard (Jan 29 2025 at 10:54):If you are trying to call a function value after unwrapping
Anton (Jan 29 2025 at 19:15):Ok, now we just need to wait for a review from the good people at exercism for https://github.com/exercism/roc-test-runner/pull/22
Anton (Jan 29 2025 at 19:16):roc 0.0.0-alpha2 pre-release is available
Anton (Jan 29 2025 at 19:19):I'll check in tomorrow morning to flip the final switches :)
Joshua Warner (Jan 30 2025 at 05:39):The fuzzer issue discussed above is fixed in https://github.com/roc-lang/roc/pull/7560
Anton (Jan 30 2025 at 08:44):Anton said:
Ok, now we just need to wait for a review from the good people at exercism for https://github.com/exercism/roc-test-runner/pull/22
No review yet :( I've mentioned them again in a comment on the PR
Anton (Jan 31 2025 at 11:35):It's here :tada: :champagne: 
:rock_on:
Anthony Bullard (Jan 31 2025 at 12:03)::tada::tada::tada::tada::tada::tada::tada::tada::tada::tada::tada::tada::tada:
Anthony Bullard (Jan 31 2025 at 12:03):Thanks for your hard work with release management @Anton
Last updated: Jul 06 2025 at 12:14 UTC