Stream: beginners

Topic: Good first issues


view this post on Zulip Folkert de Vries (Sep 24 2021 at 13:05):

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.

view this post on Zulip Fergal Byrne (Sep 27 2021 at 21:05):

Added a few comments/questions to the issue before hunting down the code where the issue might be.

view this post on Zulip Fergal Byrne (Sep 27 2021 at 23:57):

Thanks Folkert - https://github.com/rtfeldman/roc/pull/1747

view this post on Zulip Zeljko Nesic (Sep 28 2021 at 12:14):

Welcome all! :)

view this post on Zulip Anton (Sep 29 2021 at 17:43):

There is a new "good first issue", see link

view this post on Zulip Dan G Knutson (Oct 01 2021 at 22:21):

I'll take a stab at #1750 this weekend.

view this post on Zulip Folkert de Vries (Oct 01 2021 at 22:26):

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

view this post on Zulip Folkert de Vries (Oct 01 2021 at 22:26):

still, there are many similarities here, so just copying the existing drop implementation and renaming the copy to dropAt should be a good start

view this post on Zulip Dan G Knutson (Oct 03 2021 at 14:36):

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?

view this post on Zulip Dan G Knutson (Oct 03 2021 at 14:38):

Which I guess is a timid way of saying; would anyone be free to answer my questions today or sometime this week?

view this post on Zulip Folkert de Vries (Oct 03 2021 at 14:42):

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

view this post on Zulip Lucas Rosa (Oct 03 2021 at 14:49):

review comments at the line level on GitHub work well generally speaking. Especially for simpler clarification questions

view this post on Zulip Lucas Rosa (Oct 03 2021 at 14:49):

good job btw :)

view this post on Zulip Dan G Knutson (Oct 03 2021 at 15:09):

I added questions on the PR; some of them are more general 'whats going on' than clarification. :sweat_smile:

view this post on Zulip Luiz de Oliveira (Oct 06 2021 at 19:33):

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.

view this post on Zulip Luiz de Oliveira (Oct 06 2021 at 21:19):

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.

view this post on Zulip Richard Feldman (Oct 06 2021 at 21:41):

wow, nicely done! :smiley:

view this post on Zulip Anton (Oct 07 2021 at 08:14):

Awesome @Luiz de Oliveira :muscle: I'm always available for any questions you might have :)

view this post on Zulip Luiz de Oliveira (Oct 08 2021 at 00:49):

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_sizeinstead? It makes sense right?
Also, maybe DEFAULT_FONT_SIZE should go in favor of UITheme.default_font_size.

view this post on Zulip Luiz de Oliveira (Oct 08 2021 at 00:59):

Not a WIP anymore I'm ready for a review :tada: https://github.com/rtfeldman/roc/pull/1768

view this post on Zulip Richard Feldman (Oct 08 2021 at 02:33):

amazing, congrats @Luiz de Oliveira! :smiley:

view this post on Zulip Anton (Oct 08 2021 at 11:42):

I have reviewed and merged the PR, thanks again @Luiz de Oliveira :rock_on:

view this post on Zulip Anton (Oct 08 2021 at 11:55):

I can create more "guided" issues if you'd like. I'd say the main issue categories for the editor are:

There are no obligations and I'm happy to assist you in working on anything that interests you :)

view this post on Zulip Luiz de Oliveira (Oct 08 2021 at 21:22):

@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.

view this post on Zulip Anton (Oct 09 2021 at 10:43):

:+1: happy to help :)

view this post on Zulip Michael Downey (Nov 08 2021 at 18:30):

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.

view this post on Zulip Folkert de Vries (Nov 08 2021 at 19:15):

right, we have an EmptyList layout variant specifically for this case

view this post on Zulip Folkert de Vries (Nov 08 2021 at 19:16):

but generally unresolved type variables are usually a signal that there is a bug somewhere

view this post on Zulip Folkert de Vries (Nov 08 2021 at 19:16):

eventually we will just monomorphize them to the empty tag union

view this post on Zulip Michael Downey (Nov 08 2021 at 19:38):

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?

view this post on Zulip Folkert de Vries (Nov 08 2021 at 20:21):

yes

view this post on Zulip Folkert de Vries (Nov 08 2021 at 20:22):

and that is (kinda) by design, for now

view this post on Zulip Michael Downey (Nov 08 2021 at 20:34):

Folkert de Vries said:

and that is (kinda) by design, for now

Awesome, thanks for the details!

view this post on Zulip Theo Felippe (Nov 11 2021 at 19:38):

I'm trying to implement Result.IsOk but ran into some challenges where I could use some pointers from you clever people :)

view this post on Zulip Theo Felippe (Nov 11 2021 at 19:38):

https://github.com/rtfeldman/roc/pull/1958 I've added a comment with my thoughts

view this post on Zulip Folkert de Vries (Nov 11 2021 at 19:40):

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

view this post on Zulip Folkert de Vries (Nov 11 2021 at 19:42):

the withDefault example shows how to set up the pattern match

view this post on Zulip Folkert de Vries (Nov 11 2021 at 19:45):

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:

view this post on Zulip Folkert de Vries (Nov 11 2021 at 19:48):

You 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![],
};

view this post on Zulip Folkert de Vries (Nov 11 2021 at 19:48):

I think you can puzzle the rest together, but let me know if you get stuck!

view this post on Zulip Theo Felippe (Nov 11 2021 at 21:08):

Great, that is very helpful.. thanks!

view this post on Zulip Richard Feldman (Nov 20 2021 at 21:11):

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:

view this post on Zulip Lucas Rosa (Nov 20 2021 at 22:16):

if anyone needs help getting started on those feel free to ping me

view this post on Zulip Shahn Hogan (Nov 29 2021 at 20:25):

@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

view this post on Zulip Lucas Rosa (Nov 29 2021 at 20:31):

yes please do @Shahn Hogan

view this post on Zulip Lucas Rosa (Nov 29 2021 at 20:32):

good catch, it's probably frustrating to have apt-get yell at you cause you copied a command with a typo :p

view this post on Zulip Shahn Hogan (Nov 29 2021 at 20:48):

Done. https://github.com/rtfeldman/roc/pull/2102

view this post on Zulip Folkert de Vries (Dec 05 2021 at 19:59):

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