Anthony Bullard (Nov 22 2024 at 16:43): Anthony Bullard (Nov 22 2024 at 16:43):I just created https://github.com/roc-lang/basic-cli/issues/270 when I found an issue doing some refactoring work in roc-lang/examples. When a platform is not compatible with the current version of the language (compiler) that you are using, what is the plan of action for a user?
In cases when this is the latest version, do you just roll back? It seems undesirable to have our examples not be able to compile OOTB when using the latest version of the compiler.
Anton (Nov 22 2024 at 16:44):0.17.0 of basic-cli pre-release is out
https://github.com/roc-lang/basic-cli/releases/tag/0.17.0
Anton (Nov 22 2024 at 16:45):Here is the up to date version of the examples
Anton (Nov 22 2024 at 16:45):https://github.com/roc-lang/examples/pull/220
Anton (Nov 22 2024 at 16:45):I'm still working on the next release of basic-webserver before we make everything full release
Anthony Bullard (Nov 22 2024 at 16:54):Sweet, thanks for that. But my question overall still stands. The developer experience around this is definitely disjointed. Luckily I have direct access to people like you here.
Anthony Bullard (Nov 22 2024 at 17:03):I wonder if having an unofficial platform registry that could help you find compatible versions of platforms for your compiler version would be helpful?
Thinking of system that hashes the builtins of each compiler commit and creates a member lookup table for each. Then when a registered platform creates a release it would extract builtins members used and check membership (probably would have to be a hash of the name and signature or such). I'm sure there is more that is required for compatibility in terms of runtime semantics, but I'd have to ask:
A) Does this sound feasible?
B) Does the sound valuable?
C) Would this existing create issues that we are looking to avoid at this point in the project's history?
jan kili (Nov 22 2024 at 17:04): Anthony Bullard (Nov 22 2024 at 17:04):Yeah, we'd really want all platforms to be API compatible with a 0.1.0 release on the day we cut the release
jan kili (Nov 22 2024 at 17:06):I expect it'd be okay for platforms to have a week-ish delay to polish their 0.0.X-rochash
Anton (Nov 22 2024 at 17:36):Once we have the 0.0.X-rochash releases we can include the version in the roc file. That should make it easy to get compatible versions for everything.
jan kili (Nov 27 2024 at 23:32):I'm sitting down now to test basic-cli@0.17.0 + roc@TESTING + tutorial snippets that touch effects.
Anton (Nov 28 2024 at 19:18):@JanCVanB I'd like to merge https://github.com/roc-lang/roc/pull/7262 tomorrow at , let me know if you find anything
jan kili (Nov 29 2024 at 00:45):@Anton @Luke Boswell Why does basic-cli@0.17.0 require main instead of main!?
Luke Boswell (Nov 29 2024 at 00:46):We have bugs on the purity inference PR, so it hasn't landed yet :sad:
jan kili (Nov 29 2024 at 00:47):Oh! Okie dokie, does that mean we now plan to not push purity-inference syntax to AoC learners?
Luke Boswell (Nov 29 2024 at 00:47):Yeah, I would say we've missed the window if we want people to have a good experience.
jan kili (Nov 29 2024 at 00:48):Dang, well y'all gave it a good try.
Richard Feldman (Nov 29 2024 at 00:48):what are the bugs? anything we could work around by intentionally removing features (temporarily, and then reintroducing them later)?
Luke Boswell (Nov 29 2024 at 00:50): Luke Boswell (Nov 29 2024 at 00:51):This issue strikes again https://github.com/roc-lang/roc/issues/6121
bad exit code/segfault on exit in rust platforms
Richard Feldman (Nov 29 2024 at 00:52):ahh that's unfortunate
Luke Boswell (Nov 29 2024 at 00:52):We definitely have some significant ABI bugs, which I've kind of worked around in places. Mostly with anything small that is passed by value instead of a pointer.
Luke Boswell (Nov 29 2024 at 00:52):Maybe that is also related
Luke Boswell (Nov 29 2024 at 00:53):I'd love to know if there was a way to fuzz this kind of thing. Our current tests don't really cover the ABI side of things, just that what we generate LLVM compiles and runs giving us the right answer
jan kili (Nov 29 2024 at 00:55):Given this, I feel that we should avoid exposing any AoC learners to post-Task syntax/tutorial/concepts/platforms, unless basic-cli can fully migrate within several hours from now. I expect some learners to start following the tutorial tomorrow.
jan kili (Nov 29 2024 at 00:56):That could require a bit of a top-down push to guide Zulip topics and postpone certain dev work.
Richard Feldman (Nov 29 2024 at 00:56):yeah let's not rush it out the door with known serious ABI issues :big_smile:
jan kili (Nov 29 2024 at 01:01):Okie dokie, I'll pivot my tutorial update to not introduce purity inference but still update language around operators. This may be better in another topic, but what's the latest language around !? (It's an "operator", not a "suffix"?) I assume try and the other updates aren't affected by purity inference postponement.
Richard Feldman (Nov 29 2024 at 01:13):in the purity inference world, I'd just say ! is a naming convention
Richard Feldman (Nov 29 2024 at 01:13):like "names end in !"
jan kili (Nov 29 2024 at 01:27):@Richard Feldman Totally. But what language would you use about it during purity-inference-less December? (Since the tutorial can't explain the key part about ! soon cascading upward, unless we want to say "but it stops at main.")
jan kili (Nov 29 2024 at 01:29):And do you want the tutorial to hint towards purity inference concepts coming in the near future, like "In an upcoming update, ..." style? I expect that would be additional mental overhead but perhaps tactically valuable as a teaser.
Richard Feldman (Nov 29 2024 at 01:31):I think it's probably worth noting, yeah
Richard Feldman (Nov 29 2024 at 01:32):mostly as a way to stave off questions :big_smile:
Richard Feldman (Nov 29 2024 at 01:36):could probably call it "the ! postfix operator" (as opposed to the ! prefix operator like !foo)
Brendan Hansknecht (Nov 29 2024 at 18:47):Luke Boswell said:
This issue strikes again https://github.com/roc-lang/roc/issues/6121
bad exit code/segfault on exit in rust platforms
I don't understand. This isn't a purity inference bug. This is a preexisting roc bug. We regularly disable and re-enable tests due to this bug
Brendan Hansknecht (Nov 29 2024 at 18:48):It was never gone
Luke Boswell (Nov 29 2024 at 20:04):Yeah, I just mean it's currently blocking the PR because I haven't found a way to get CI to pass.
Brendan Hansknecht (Nov 29 2024 at 23:24):How many examples are failing? Is it just some random cli run or glue test? If so, just disable the test
Last updated: Jul 05 2025 at 12:14 UTC