Should the Standard Library have a function similar to Elm's Dict.update
?
yes! We were just talking about that in another thread, and I think there's an issue for it now
Excellent! :raised_hands:
I link them here for reference: GitHub Issue and Zulip Topic
I implemented the Dict.update
function in this PR and I think it is fine. I followed the instructions to build from source yet when I run cargo run repl
and try to use Dict.update
, the REPL tells me that The Dict module does not expose update
.
Not sure what I'm missing. Am I editing the wrong file?
you’ll need to also add the symbol here: https://github.com/roc-lang/roc/blob/07ceabc9aa12c81792c33b98f7e45b9d05f903ca/crates/compiler/module/src/symbol.rs#L1413
Ayaz Hafiz said:
you’ll need to also add the symbol here: https://github.com/roc-lang/roc/blob/07ceabc9aa12c81792c33b98f7e45b9d05f903ca/crates/compiler/module/src/symbol.rs#L1413
What does this file do?
We have to treat builtins differently in the compiler, so this file defines the symbols (definition names, type names, etc) used in the builtin modules.
It worked! Thanks!
PR ready: https://github.com/roc-lang/roc/pull/4273
nice! I'd suggest adding an expect
test or two underneath it, just to verify it's working as expected :big_smile:
we don't have those for most of the stdlib because the stdlib existed way before expect
did, but I'd like to start a trend of including those tests with the implementations!
Done
Now that the PR has merged, I see that the Standard Library docs are outdated. I must have missed a step somewhere or misunderstand Roc's processes since I expected that the comments I added to the function would be used there. I also see that the CI only runs roc test
(through cargo run
) on the Str
module, so the tests I added are not contributing to the CI pipeline.
The website is deployed using the www branch, see the procedure here.
I also see that the CI only runs roc test (through cargo run) on the Str module...
Good catch! Can you update the step to include the other builtins?
Anton said:
The website is deployed using the www branch, see the procedure here.
The Standard Library is not found in that directory. Let me see if I can find it in the source code.
In case you haven't found it: https://github.com/roc-lang/roc/tree/main/crates/compiler/builtins/roc
Yup, I was able to generate the docs locally, and my changes appear there, so there must be something missing in the CD that deploys the website.
The procedure I linked earlier does not explicitly state that www
is a branch.
So you need to do a PR against the www branch instead of the main branch to update the website.
I need better reading comprehension skills :rolling_on_the_floor_laughing:
Not sure why we set this up with the separate www branch to deploy but I suspect it's for good reason :)
yeah it's that we get a limited number of Netlify build minutes per month
so we want to only use them when we know we have relevant changes to deploy :big_smile:
That makes sense. Should I create a PR from main
to www
then?
I'm updating CONTRIBUTING.md
with instructions on how to build the Standard Library docs locally. What is Roc's preferred local server? I used http-server
, but I can imagine that we don't want to assume that contributors have node installed locally.
Chris Duncan said:
That makes sense. Should I create a PR from
main
towww
then?
Yep that should be good
Chris Duncan said:
I'm updating
CONTRIBUTING.md
with instructions on how to build the Standard Library docs locally. What is Roc's preferred local server? I usedhttp-server
, but I can imagine that we don't want to assume that contributors have node installed locally.
We have a deploy preview for PRs to the www branch, so is it really necessary to build them locally?
Anton said:
We have a deploy preview for PRs to the www branch, so is it really necessary to build them locally?
If you don't want to clog or wait on the CI, yup.
Here's the PR to the www
branch:
https://github.com/roc-lang/roc/pull/4282
This also sounds like it may be a good use of weekly auto PR or something of that nature. Of course it would mean the docs have more lag, but it would not waist build minutes and would ensure they don't get forgotten.
@Richard Feldman would we have enough netlify build minutes for a weekly run?
apparently Netlify has an Open Source plan which gives you 25k build minutes per month (up from the current 300), as long as you put "powered by Netlify" on the homepage. So I'm gonna do that and apply for it! Then we can do nightly builds at the same time as generating the nightly binaries.
Oh that's great! I'm always forgetting to deploy things like web REPL fixes after merging to main
! So will we keep the www
branch but update it automatically? That way we can still do hot fixes if we break stuff.
that makes sense to me! :+1:
success! we've been approved
so now we can I guess just git reset --hard
the www
branch to main
every night, and should be good?
How about just trigger the nightly cron job to deploy main
and forget about the www
branch?
this way we don't need Netlify credentials in GitHub, Netlify can just pull from the already-public GH repo
Though I thought that main
is already public.
oh it is - just Netlify is set up to trigger on push to a particular branch, so if we set it to do that on main
, it would deploy main
on every PR merge
so now we can I guess just
git reset --hard
thewww
branch tomain
every night, and should be good?
I'll set up a workflow for that.
This latest commit should pass the CI
https://github.com/roc-lang/roc/pull/4289
Last updated: Jul 26 2025 at 12:14 UTC