I think fixing this one https://github.com/rtfeldman/roc/issues/1708 is a great way to get started with some compiler development. The compiler crashes (giving us an exact line number) when creating an error message for that example: that particular case is just not implemented yet. There should be enough code around there to write an implementation.
Added a few comments/questions to the issue before hunting down the code where the issue might be.
Thanks Folkert - https://github.com/rtfeldman/roc/pull/1747
Welcome all! :)
There is a new "good first issue", see link
I'll take a stab at #1750 this weekend.
I think that issue is now a little out of date. We instead want a dropAt : List a, Nat -> List a
that drops the element at the index. the drop
function keeps its current "drop x elements from the front" behavior
still, there are many similarities here, so just copying the existing drop
implementation and renaming the copy to dropAt
should be a good start
I've got a version of List.dropAt from 1750 implemented on the 'giesch' branch, but I still have questions about docs and variable uniqueness. Should I ask those here or do a call?
Which I guess is a timid way of saying; would anyone be free to answer my questions today or sometime this week?
absolutely, I could do it on a call in ~ 2 hours, can do it here or you can open a PR and add some review comments inline
review comments at the line level on GitHub work well generally speaking. Especially for simpler clarification questions
good job btw :)
I added questions on the PR; some of them are more general 'whats going on' than clarification. :sweat_smile:
I want to tackle https://github.com/rtfeldman/roc/issues/1281 as a first issue, it seems simple enough to get started. Because the CONTRIBUTING.md
guide says it's a good idea I'm saying it here and assigning myself to the task. Any tips would be appreciated since I've never done any rust development at all haha.
Got this WIP PR https://github.com/rtfeldman/roc/pull/1768. I'll try and fix the popup with the expression type too so I'll take a look at that later.
wow, nicely done! :smiley:
Awesome @Luiz de Oliveira :muscle: I'm always available for any questions you might have :)
I see default_font_size
defined in the UITheme
struct but also in a constant DEFAULT_FONT_SIZE
at editor/src/graphics/style.rs
. At the same time, we have code_font_size
in the Config
struct. The code_font_size
is used to calculate the size of the glyphs, glyph_dim_rect
, which is used to calculate the size of the rect drawn behind the tooltip text. The actual tooltip text though, is drawn using UITheme.default_font_size
.
Should we draw the tooltip using code_font_size
instead? It makes sense right?
Also, maybe DEFAULT_FONT_SIZE
should go in favor of UITheme.default_font_size
.
Not a WIP anymore I'm ready for a review :tada: https://github.com/rtfeldman/roc/pull/1768
amazing, congrats @Luiz de Oliveira! :smiley:
I have reviewed and merged the PR, thanks again @Luiz de Oliveira :rock_on:
I can create more "guided" issues if you'd like. I'd say the main issue categories for the editor are:
Expr2
and Def2
, so language related interactioneditor/editor_ideas.md
or make a suggestion yourself!There are no obligations and I'm happy to assist you in working on anything that interests you :)
@Anton If this will not add much overhead to your work I appreciate it. It was a breeze to do that one because the issue was like that. With time I'll need it less and less, but for new contributors that don't know the codebase at all this really speeds things up. I'll look at these possibilities.
:+1: happy to help :)
I was taking a look at https://github.com/rtfeldman/roc/issues/1702. Is this something to work on as a good first issue or will it get a bit deeper into types? Looking for something to get my feet wet a bit and learn more. It seems to happen on builtins that use flex on the tvars in compiler/builtins/src/std.rs but doesn't when the tvar is wrapped in something like list_type etc.
right, we have an EmptyList
layout variant specifically for this case
but generally unresolved type variables are usually a signal that there is a bug somewhere
eventually we will just monomorphize them to the empty tag union
Folkert de Vries said:
eventually we will just monomorphize them to the empty tag union
Ah understood. So it seems the cause of this bug as of now is that these are not yet being monomorphized and are getting to specialization with an unresolved type if I understand it correctly?
yes
and that is (kinda) by design, for now
Folkert de Vries said:
and that is (kinda) by design, for now
Awesome, thanks for the details!
I'm trying to implement Result.IsOk
but ran into some challenges where I could use some pointers from you clever people :)
https://github.com/rtfeldman/roc/pull/1958 I've added a comment with my thoughts
The other idea was to copy the implementation of Result.withDefault but return a bool on the value in the ok/err branches (https://github.com/rtfeldman/roc/blob/trunk/compiler/can/src/builtins.rs#L3950), but I'm not sure how to do that yet. Would I have to create a new Expr to represent a Bool? Also, I'm not yet convinced this would be the best way to go..
That is the way to go
the withDefault
example shows how to set up the pattern match
The goal here is to implement
isOk = \result ->
when result is
Ok _ -> True
Err _ -> False
And we're starting with
withDefault = \result, default ->
when result is
Ok x -> x
Err _ -> default
So compared to the `withDefault example:
Ok
pattern should have an underscore instead of a symbolTrue
and False
expressionsYou can make a True
value with
let tag_name = TagName::Global("True".into());
// ok branch
let ok = Tag {
variant_var: var_store.fresh(),
ext_var: var_store.fresh(),
name: tag_name,
arguments: vec![],
};
I think you can puzzle the rest together, but let me know if you get stuck!
Great, that is very helpful.. thanks!
there are two builtins that are likely to come up in Advent of Code in about a week - I've added a :star: to them on https://github.com/rtfeldman/roc/issues/664 - if anyone wants to work on adding them to the language, let me know! :smiley:
if anyone needs help getting started on those feel free to ping me
@Lucas Rosa Hi, it looks like there is a typo in the Linux x86 Getting Started Guide on Step 3 for C build tools -- "build-essentials" should be "build-essential". Would it be OK for me to submit a PR for this?
https://github.com/rtfeldman/roc/blob/trunk/getting_started/linux_x86.md
yes please do @Shahn Hogan
good catch, it's probably frustrating to have apt-get yell at you cause you copied a command with a typo :p
Done. https://github.com/rtfeldman/roc/pull/2102
I think tackling the nonrecursive case specifically of this issue https://github.com/rtfeldman/roc/issues/2138 will be reasonably straightforward. The error points to line 464 in cli/src/repl/eval.rs
. There is already single_tag_union_to_ast
in that file, we now just need a general tag_union_to_ast
Last updated: Jul 06 2025 at 12:14 UTC