Advent of Code 2021 · beginners · Zulip Chat Archive

How much setup would it need? Is it for example possible to set up an AoC example?

I think it's a great opportunity to try out Roc, I'm just not sure how much time I'll have for AoC. So if there is expected overhead, I might reconsider Roc.

Lucas Rosa (Nov 21 2021 at 18:37):

Richard Feldman (Nov 21 2021 at 18:39):

definitely! We could make an examples/advent-of-code which has sort of a starter kit example for doing things like:

Lucas Rosa (Nov 21 2021 at 18:40):

Lucas Rosa (Nov 21 2021 at 18:41):

Lucas Rosa (Nov 21 2021 at 18:47):

Brendan Hansknecht (Nov 21 2021 at 19:31):

Generally you don't need terminal, just file io/copying data into an array. They tend to give you a sample problem with a small input to interpret then either a larger input or many inputs in a file.

Brian Carroll (Nov 21 2021 at 21:18):

When I did it in Elm one year, I just copied the input data into a file called input.elm and made it a String or a List Int. I figured my program didn't need to parse _any_ input, just that specific input. :smiling_devil:

Brian Carroll (Nov 21 2021 at 21:19):

Lucas Rosa (Nov 21 2021 at 21:40):

Lucas Rosa (Nov 21 2021 at 21:41):

Brendan Hansknecht (Nov 21 2021 at 21:44):

Lucas Rosa (Nov 21 2021 at 21:49):

Johannes Maas (Nov 28 2021 at 15:23):

I thought I'd have a look at the previous AoC to see how to set it up. It's pretty easy to go inside example/cli and just do something like cat input.txt | cargo run Day1.roc > output.txt.

But I immediately needed to parse the input into a list of numbers and that's where I'm already lost. I know it's marked as a high priority built-in in https://github.com/rtfeldman/roc/issues/664, but unfortunately I currently don't have time to figure out how to implement it.

So based on this, I think I might do AoC (if at all) in a more familiar language, but I'm definitely interested in doing it again in Roc, as soon as the avant-garde has cleared the way. ;)

Pit Capitain (Nov 28 2021 at 15:43):

Hi Johannes, I solved last year's AoC with a very early version of Roc. You can read a little bit about it here: https://github.com/pithub/aoc2020/blob/master/WrapUp.md. My platform read files as a list of bytes, which were then parsed into a list of numbers, for example.

Johannes Maas (Nov 28 2021 at 17:00):

Thanks, @Pit Capitain! Looks really interesting! If I find some time, I might take inspiration from your repo. :+1:

Richard Feldman (Nov 29 2021 at 03:51):

I'll keep filling in missing sections over the next week, but hopefully what's there will be helpful so far!

Pit Capitain (Nov 29 2021 at 06:29):

Very nice :+1: It's really hard for me to resist, but I have other tasks I need to accomplish first :disappointed:

Richard Feldman (Nov 29 2021 at 13:58):

feel free to introduce yourself in #beginners > introductions and ask any Advent of Code related questions right here in this topic!

Lucas Rosa (Nov 29 2021 at 15:07):

Martin Janiczek (Dec 01 2021 at 08:46):

Hello! Trying Roc on 2021/01, starting out from examples/cli. Is there some working implemented str->num function? I tried out Str.toNum and Str.toU8 that I saw mentioned in the compiler/builtins/docs/*.roc but no luck so far

Yann Simon (Dec 01 2021 at 09:05):

Yann Simon (Dec 01 2021 at 09:28):

for day 1, if we save the inputs into a file, we need a way to read from that file. The tutorial mentions that in https://github.com/rtfeldman/roc/blob/trunk/TUTORIAL.md#tasks but does not show the implementation. WIP I guess.
I could not find any examples reading from a file. And you?

Yann Simon (Dec 01 2021 at 09:51):

measurements = [199, 200, 208, 210, 200, 207, 240, 269, 260, 263 ]
increases = List.walk measurements { counts: 0, previousElement: 600 } \state, elem ->
    when state.previousElement is
        Num previousElement if previousElement < elem -> { counts: state.counts + 1, previousElement: elem }
        _ -> { state & previousElement: elem }
increases

(previousElement: 600 is not here to stay, only to experiment)
I got the following error:

── TYPE MISMATCH ───────────────────────────────────────────────────────────────

The 2nd branch of this when does not match all the previous branches:

6│          when state.previousElement is
7│              Num previousElement if previousElement < elem -> { counts: state.counts + 1, previousElement: elem }
8│              _ -> { state & previousElement: elem }
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The 2nd branch is a record of type:

    { counts : Num a, previousElement : [ Num (Num b) ]c }

But all the previous branches have type:

    { counts : Num a, previousElement : Num b }

I need all branches of a when to have the same type!

Anton (Dec 01 2021 at 10:02):

Anton (Dec 01 2021 at 10:29):

measurements = [199, 200, 208, 210, 200, 207, 240, 269, 260, 263 ]
increases =
    List.walk measurements { counts: 0, previousElement: 600 } \state, elem ->
        if state.previousElement < elem then
            { counts: state.counts + 1, previousElement: elem }
        else
            { state & previousElement: elem }
increases

Yann Simon (Dec 01 2021 at 10:37):

OK, but I'd like to use something else as 600 as initial state, like None to start with an empty previous element. And then I need the when right?

Martin Janiczek (Dec 01 2021 at 10:46):

I'm sorry for the confusion, my question was the other way round, the linked PR does Num->Str, I need Str->Num

Anton (Dec 01 2021 at 11:24):

@Yann Simon I see, matching with Some(with if) and None should work.
Matching with Num previousElement does not work as you intend, I'd recommend reading the section on Numbers here.

Laurence Joseph Pakenham-Smith (Dec 01 2021 at 14:51):

Hey all, looking for a bit of advice on how to get up and running. I've got a hello world example here: https://github.com/Sourceless/advent-of-code-2021/blob/master/01/part1.roc -- I see that a lib is required to use some of the I/O actions, so I've symlinked to the platform in examples/cli in the Roc repo.

This example compiles and runs but produces no output:
``` $ roc part1.roc
:hammer: Rebuilding host... Done!

I'm running the latest nightly of Roc (the binary sat in my PATH) with cargo nightly on Ubuntu 20.04. Thanks in advance for any help and please forgive the stupid questions!

Shrikanth Upadhayaya (Dec 01 2021 at 14:54):

Shrikanth Upadhayaya (Dec 01 2021 at 14:55):

I've found that you just need to await something - so I'm making it await on Task.succeed {}

Laurence Joseph Pakenham-Smith (Dec 01 2021 at 14:56):

thread '<unnamed>' panicked at 'index out of bounds: the len is 0 but the index is 0', compiler/mono/src/ir.rs:8208:35
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrac

Shrikanth Upadhayaya (Dec 01 2021 at 14:59):

Laurence Joseph Pakenham-Smith (Dec 01 2021 at 14:59):

Shrikanth Upadhayaya (Dec 01 2021 at 14:59):

app "hello"
    packages { base: "../examples/cli/platform" }
    imports [ base.Task.{ await, succeed }, base.Stdout ]
    provides [ main ] to base

main =
    # Has to be the first line of every main
    _ <- await (succeed {})

    Stdout.line "I'm a roc application!"

Laurence Joseph Pakenham-Smith (Dec 01 2021 at 15:00):

Lucas Rosa (Dec 01 2021 at 15:58):

Jason Hobbs (Dec 01 2021 at 16:12):

Lucas Rosa (Dec 01 2021 at 16:15):

on the AoC site, click [Leaderboard], then in the paragraph below the menu click [Private Leaderboard], you should see an input box to add that ID

Jason Hobbs (Dec 01 2021 at 16:18):

Ah, that paragraph doesn't show up until you Log In. Thanks... just added myself.

Lucas Rosa (Dec 01 2021 at 16:25):

Brendan Hansknecht (Dec 01 2021 at 18:15):

For anyone that has completed the advent of code for today in Roc, it would be great if you can send the link to your repo. That way other users who get stuck can take a look. Since roc has a number of rough edges at the moment, that would probably be very useful to others.

Tim Whiting (Dec 02 2021 at 01:03):

Here is a link to a gist. I'll probably end up creating a repo so I can have all the days together, but this is for today. This is my first time really using a functional language for something non-trivial, and I know at least a few things that I could have improved: https://gist.github.com/cbcc781860f5ad69b7c7bfe55087e6c6

I didn't do any reading in from a file, just copied the list of numbers since the Str.toNum builtin wasn't ready yet

Yann Simon (Dec 02 2021 at 03:11):

I'm still stuck. I've tried adding more type annotations to help the compiler, but nothing helps ;(

Option a : [ Some a, None ]
Aggr : { counts: Nat, previousElement: Option Nat}

walkStep: Aggr, Nat -> Aggr
walkStep = \state, elem ->
    when state.previousElement is
        Some previousElement if previousElement < elem -> { counts: state.counts + 1, previousElement: Some elem }
        _ -> { state & previousElement: Some elem }

initialState: Aggr
initialState = { counts: 0, previousElement: None }

measurements = [199, 200, 208, 210, 200, 207, 240, 269, 260, 263 ]
increases = List.walk measurements initialState walkStep
increases

thread 'main' panicked at 'internal error: entered unreachable code: Something had a Struct layout, but instead of a Record or TagUnion type, it had: Alias(`#UserApp.Aggr`, AliasVariables { variables_start: 424, all_variables_len: 0, type_variables_len: 0 }, 990)', cli/src/repl/eval.rs:184:21

Mismatch in compiler/unify/src/unify.rs Line 1078 Column 13
Trying to unify two flat types that are incompatible: { 'counts' : Required(1152), 'previousElement' : Required(1137), }<1> ~ Apply(`Str.Str`, [])

thread 'main' panicked at 'internal error: entered unreachable code: symbol/layout `fx.Effect.effect_always_inner` ProcLayout { arguments: [Struct([]), LambdaSet(LambdaSet { set: [(`fx.Effect.effect_always_inner`, [Union(NonRecursive([[Union(NonRecursive([]))], [Builtin(Str)]]))])], representation: Struct([Union(NonRecursive([[Union(NonRecursive([]))], [Builtin(Str)]]))]) })], result: Union(NonRecursive([[Union(NonRecursive([]))], [Union(NonRecursive([]))]])) } combo must be in DeclarationToIndex', compiler/mono/src/borrow.rs:227:9

Yann Simon (Dec 02 2021 at 03:25):

walkStep = \state, _elem ->
    state

Shrikanth Upadhayaya (Dec 02 2021 at 03:40):

I ran into a few issues which I patched, so this should be helpful if you're trying to do it but can't get it working

Yann Simon (Dec 02 2021 at 03:41):

ok very strange, I've started a new roc file from scratch, copy/paste everything step by step, and now it's compiling...

Yann Simon (Dec 02 2021 at 03:48):

Yann Simon (Dec 02 2021 at 03:55):

Shrikanth Upadhayaya (Dec 02 2021 at 03:58):

Shrikanth Upadhayaya (Dec 02 2021 at 03:59):

if you want to use both, you can vendor the platform code separately into whatever directory you're using

Shrikanth Upadhayaya (Dec 02 2021 at 03:59):

Yann Simon (Dec 02 2021 at 04:02):

Yann Simon (Dec 02 2021 at 04:18):

I can confirm I can read the file (with the modification as I'm on macos)
Now I just need #beginners > Str.toNum :wink:

Sam Mohr (Dec 02 2021 at 04:38):

What's the policy on public repos with Roc code? Would it be okay to make Roc code public, or should I make my repo private until the language stabilizes?

Brendan Hansknecht (Dec 02 2021 at 04:41):

I think public repos should be fine. I mean there are already a number of talks on roc. We mostly want to control how plausible it is for Roc to go viral and then for many people to be extremely annoyed because it isn't ready yet. But we are willing to accept new comers who happen upon the language.

Brendan Hansknecht (Dec 02 2021 at 04:42):

Just want slow stable growth until it is more ready for the general internet. Public repos on github should be just fine. I wouldn't expect them to randomly go viral.

Yann Simon (Dec 02 2021 at 09:17):

Lucas Rosa (Dec 02 2021 at 16:03):

Richard Feldman (Dec 05 2021 at 14:21):

for those doing advent of code in Roc: how's it going? Has anyone gotten stuck or blocked on anything?

It's a great opportunity to find things to fix in the language, so please let us know about anything you trip over! :big_smile:

jan kili (Dec 06 2021 at 02:30):

jan@Jans-MacBook-Pro advent-of-code-2021 % ./solutions/day-1a-sonar-sweep/run_1a.sh
    Finished dev [unoptimized + debuginfo] target(s) in 0.30s
     Running `target/debug/roc ../solutions/day-1a-sonar-sweep/solution_1a.roc`
Mismatch in compiler/unify/src/unify.rs Line 1078 Column 13
Trying to unify two flat types that are incompatible: Func([242, 252], 240, 221) ~ Func([104, 105, 117], 119, 120)

thread '<unnamed>' panicked at 'index out of bounds: the len is 0 but the index is 0', compiler/mono/src/ir.rs:8236:35
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
^C

[nix-shell:~/code/advent-of-code-2021/roc]$ exit
exit
jan@Jans-MacBook-Pro advent-of-code-2021 %

#!/usr/bin/env roc

app "hi"
    packages { base: "../../roc/examples/cli/platform" }
    imports [ base.Task.{ Task, await }, base.Stdout ]
    provides [ main ] to base

main : Task {} *
main =
    {} <- await Stdout.line "hi"
    Stdout.line "nope"

My obvious-in-hindsight mistake was missing parentheses: await (Stdout.line "hi") However, this panic is super confusing. Additionally, I feel like I've seen as many obtuse panics (like this one, but there's been others) as pretty-printed error/warning messages - this is offputting to a learner, though I imagine this is par for the course for WIP compilers.

jan kili (Dec 06 2021 at 02:32):

I saw this panic about 10 times in my first 10 minutes of coding (likely from some fundamentally flawed line of code, like missing parentheses or something):

thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', src/lib.rs:116:45
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
fatal runtime error: failed to initiate panic, error 5

jan kili (Dec 06 2021 at 02:34):

Anton (Dec 06 2021 at 13:36):

Excellent feedback, thanks @JanCVanB! Can someone familiar with this code set up some issues?

Ju Liu (Dec 06 2021 at 14:29):

I have the repo updated and can run cargo run repl. what's the recommended way to get started? :) I tried the gist, but even with the patches it segfaults on

thread 'main' panicked at 'not yet implemented: unhandled parse error IndentProvides(0, 14)', reporting/src/error/parse.rs:3148:14

Anton (Dec 06 2021 at 14:36):

Ju Liu (Dec 06 2021 at 15:54):

Anton (Dec 06 2021 at 17:01):

"packages ...", "imports..." and "provides..." need to have four spaces before them.

Ju Liu (Dec 06 2021 at 17:56):

$ cargo run test.roc
    Finished dev [unoptimized + debuginfo] target(s) in 0.89s
     Running `target/debug/roc test.roc`

Ju Liu (Dec 06 2021 at 17:57):

$ cat test.roc
app "solution"
    packages { base: "../platform" }
    imports [ base.Task.{ await }, base.Stdout, base.File ]
    provides [ main ] to base

inputPath = "test.roc"

main =
    _ <- await (Stdout.line "Trying to read file...")
    task = File.readUtf8 inputPath
    Task.attempt task \result ->
      when result is
          Ok input -> Stdout.line "Contents:\n\(input)"
          Err _ -> Stdout.line "Failed to read input."

Richard Feldman (Dec 06 2021 at 17:58):

that branch is still WIP, although it should fail with an explicit error :laughing:

Ju Liu (Dec 06 2021 at 18:01):

it's weird because it seems it's just stuck, maybe I should try straceing it and see what it's up to

Anton (Dec 06 2021 at 18:01):

echo  Echo.roc  Files.roc  platform  README.md  solution  Test.roc

Anton (Dec 06 2021 at 18:02):

Anton (Dec 06 2021 at 18:03):

Anton (Dec 06 2021 at 18:18):

Ju Liu (Dec 06 2021 at 18:21):

Ju Liu (Dec 06 2021 at 18:22):

$ cat Test.roc
app "solution"
    packages { base: "./examples/cli/platform" }
    imports [ base.Task.{ await }, base.Stdout, base.File ]
    provides [ main ] to base

inputPath = "./Test.roc"

main =
    _ <- await (Stdout.line "Trying to read file...")
    task = File.readUtf8 inputPath
    Task.attempt task \result ->
      when result is
          Ok input -> Stdout.line "Contents:\n\(input)"
          Err _ -> Stdout.line "Failed to read input."

Ju Liu (Dec 06 2021 at 18:23):

Anton (Dec 06 2021 at 18:26):

Emiliano Bovetti (Dec 06 2021 at 18:34):

hello everyone!
not sure where to write (first time using zulip) :smile:
I'm getting an error while using records as values for Dict, is this a known issue?

$ roc repl

» Dict.single 0 {a: 1, b: 1} |> Dict.get 0

thread 'main' panicked at 'Error in alias analysis: error in module ModName("UserApp"), function definition FuncName("\x06\x00\x00\x00\x04\x00\x00\x00eiGJ\xf5B\x11="), definition of value binding ValueId(13): expected type '(((), ()),)', found type '((),)'', compiler/gen_llvm/src/llvm/build.rs:4019:19
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Anton (Dec 06 2021 at 19:01):

Hi @Emiliano Bovetti,
I could not find this in the issues, I'll make a new one. Thanks for reporting it!

Sebastian Fischer (Dec 08 2021 at 21:22):

The first task of Day 1 is solved when removing lines 9 and 10 of that program. For that task, the program prints the correct answer for exampleInput as well as largeInput.

For the second task of Day 1 the program prints the correct result only for exampleInput. When using largeInput the program exits with a segmentation fault.

Brendan Hansknecht (Dec 08 2021 at 21:29):

Brendan Hansknecht (Dec 08 2021 at 21:30):

Sebastian Fischer (Dec 08 2021 at 21:46):

Brendan Hansknecht (Dec 08 2021 at 21:57):

Sebastian Fischer (Dec 08 2021 at 22:03):

Brendan Hansknecht (Dec 08 2021 at 22:04):

Brendan Hansknecht (Dec 08 2021 at 22:05):

To be fair requiring unlimited stack space is definitely also a bug, but that is more general to work on things than specific bugs.

Brendan Hansknecht (Dec 08 2021 at 22:09):

Hmm...neither run on my m1 mac. That suggests it is likely some sort of invalid memory bug. arm is a lot more picky around that kind of stuff.

Brendan Hansknecht (Dec 08 2021 at 22:14):

jan kili (Dec 09 2021 at 07:30):

I just spent 2 hours debugging type mismatches in my AoC code, and although I've found some mistakes, I don't feel like my code is close to working. Therefore, I want to take a step back and ask... How should I be developing Roc code? I feel like my workflow must be flawed.

jan kili (Dec 09 2021 at 07:37):

jan kili (Dec 09 2021 at 07:38):

Where am I going wrong? I'm asking honestly, not flaming, because the workflow feels wrong.

jan kili (Dec 09 2021 at 07:43):

I finished days 1 & 2 with this workflow, but I'm stuck on debugging my day 9 code.

Folkert de Vries (Dec 09 2021 at 08:11):

are you using roc check Foo.roc? using check over build should improve error messages

Folkert de Vries (Dec 09 2021 at 08:11):

most crashes are because of earlier type checking problems leading to edge cases during code gen

Folkert de Vries (Dec 09 2021 at 08:12):

Anton (Dec 09 2021 at 09:26):

jan kili (Dec 09 2021 at 13:31):

jan kili (Dec 12 2021 at 11:18):

jan kili (Dec 12 2021 at 11:21):

I really don't want to semi-manually convert that into a hard-coded List like heightMeasurements = [ [ 6, 6, 8, 9, 9, 2, ... ], [ ... ], ... ], but I don't mind copy/pasting it into a hard-coded Str like heightMeasurements = "668992...\n...". However, I can't seem to split that Str without a segfault. Any tips appreciated! :smile:

jan kili (Dec 12 2021 at 11:33):

Lucas Rosa (Dec 12 2021 at 18:57):

jan kili (Dec 12 2021 at 23:52):

Hooray for Str.toI64! Yes, Str.split exists, but it doesn't seem to work with an empty-string delimiter :/

Richard Feldman (Dec 13 2021 at 00:03):

jan kili (Dec 13 2021 at 00:17):

Richard Feldman (Dec 13 2021 at 01:02):

Richard Feldman (Dec 13 2021 at 01:03):

although, I just realized that Str.split with an empty string should likely be a no-op :thinking:

Richard Feldman (Dec 13 2021 at 01:06):

it would be easy to say "we should make it split on a character boundary" such that "1234" would become [ "1", "2", "3", "4" ] but that devolves quickly into a pile of Unicode edge cases (e.g. what if there are a bunch of emojis with modifiers, or multi-code-point compound characters) which I don't think should be in scope for a simple function like split

jan kili (Dec 13 2021 at 01:10):

Richard Feldman (Dec 13 2021 at 01:10):

however, I think there's an easier solution: Str.split on newlines to get a List Str of lines, and then for each line, do Str.toUtf8 to get a List U8

Richard Feldman (Dec 13 2021 at 01:11):

the List U8 won't be quite what you want, because they'll be ASCII bytes rather than the actual numbers you want, so you'll have to subtract 48 from each of them

Richard Feldman (Dec 13 2021 at 01:11):

jan kili (Dec 13 2021 at 01:14):

Modifying my example in the above issue, when I change Stdout.line (Str.joinWith (Str.split "abc" "") ", ") to Stdout.line (Str.joinWith "abc" ", "), I get

[nix-shell:~/code/advent-of-code-2021]$ ./roc/target/release/roc example.roc
🔨 Rebuilding host...
── TYPE MISMATCH ───────────────────────────────────────────────────────────────

The 1st argument to joinWith is not what I expect:

12│      Stdout.line (Str.joinWith "abc" ", ")
                                   ^^^^^

This argument is a string of type:

    Str

But joinWith needs the 1st argument to be:

    List Str

────────────────────────────────────────────────────────────────────────────────

Done!

Roc hit a panic: Hit an erroneous type when creating a layout for `3.IdentId(5)`

[nix-shell:~/code/advent-of-code-2021]$

jan kili (Dec 13 2021 at 01:22):

However, Stdout.line (Num.toStr (List.sum (List.map (Str.toUtf8 "123") \x -> x - 48))) prints 6! Thank you!

jan kili (Dec 13 2021 at 01:36):

Whoa... While cleaning that up by replacing \x -> x - 48 with Str.toI64, I just experienced a level up in my Roc comfort :smiley: #Pipes4Life

#!/usr/bin/env roc

app "example"
    packages { base: "roc/examples/cli/platform" }
    imports [ base.Stdout, base.Task.{ await, Task } ]
    provides [ main ] to base

main : Task {} *
main =
    # This extra Stdout.line call is required. See GH issue #2151.
    _ <- await (Stdout.line "")
    "123"
        |> Str.toUtf8
        |> List.map \u ->
            when Str.fromUtf8 [u] is
                Err _ -> "!"
                Ok s -> s
        |> List.map \s ->
            when Str.toI64 s is
                Err _ -> -999
                Ok i -> i
        |> List.sum
        |> Num.toStr
        |> Stdout.line

Richard Feldman (Dec 13 2021 at 02:10):

Lucas Rosa (Dec 13 2021 at 04:53):

jan kili (Dec 13 2021 at 16:48):

[1, 2, 3]
      |> List.map \x -> x * 2

jan kili (Dec 13 2021 at 16:49):

I'm getting an internal error: entered unreachable code panic about it, so I can't tell if I'm making a syntax mistake

Anton (Dec 13 2021 at 16:52):

jan kili (Dec 13 2021 at 16:53):

Anton (Dec 13 2021 at 16:53):

jan kili (Dec 13 2021 at 17:02):

So now that that panic is gone, I have a Roc fluency problem: How can I improve this function to support parsing negative integers?

parseIntegers : List Str -> List I64
parseIntegers = \integerStrings ->
    integerStrings
        |> List.map (\s -> Str.toI64 s)
        |> List.map \x ->
            when x is
                Ok i -> i
                Err _ -> -1
        |> List.keepIf (\i -> i > 0)

jan kili (Dec 13 2021 at 17:03):

I'm using the -1 hack to prevent the output type having Results in it, but there must be a better way.

jan kili (Dec 13 2021 at 17:05):

Maybe the output type having Results in it is actually best? Maybe I need to get used to Errs bubbling up from every subroutine...

jan kili (Dec 13 2021 at 17:06):

However, in this case I simply want to throw away strings that aren't valid integers. Surely that should be possible:
parseIntegers ([ "no", "way", "-123", "456", "789jk" ]) == [ -123, 456 ]

Anton (Dec 13 2021 at 17:14):

Anton (Dec 13 2021 at 17:15):

Anton (Dec 13 2021 at 17:17):

parseIntegers : List Str -> List I64
parseIntegers = \integerStrings ->
    integerStrings
        |> List.map (\s -> Str.toI64 s)
        |> List.keepIf \x ->
            when x is
                Ok _ -> True
                Err _ -> False

Anton (Dec 13 2021 at 17:26):

parseIntegers : List Str -> List I64
parseIntegers = \integerStrings ->
    integerStrings
        |> List.keepOks (\s -> Str.toI64 s)

Matthias Devlamynck (Dec 13 2021 at 17:26):

Interesting, I would expect this [1, 2, 3] |> List.map \x -> x * 2 to work. Is it a bug or is it intended?

Anton (Dec 13 2021 at 17:28):

jan kili (Dec 13 2021 at 18:21):

[nix-shell:~/code/advent-of-code-2021]$ ./roc/target/release/roc check solutions/day-1-sonar-sweep/solution_1a.roc

── TYPE MISMATCH ───────────────────────────────────────────────────────────────

Something is off with the body of the parseIntegers definition:

 8│   parseIntegers : List Str -> List I64
 9│   parseIntegers = \integerStrings ->
10│>      integerStrings
11│>          |> List.map (\s -> Str.toI64 s)
12│>          |> List.keepIf \x ->
13│>              when x is
14│>                  Ok _ -> True
15│>                  Err _ -> False

This keepIf call produces:

    List (Result I64 [ InvalidNumStr ]b)

But the type annotation on parseIntegers says it should be:

    List I64

────────────────────────────────────────────────────────────────────────────────


[nix-shell:~/code/advent-of-code-2021]$

Anton (Dec 13 2021 at 18:24):

Oh right, the results are all Ok but they are not unwrapped. The shorter alternative I posted does work right?

Anton (Dec 13 2021 at 18:33):

sidenote: Result.isOk and Result.isErr are implemented but are not in the builtins/docs. I'll add them now.

jan kili (Dec 13 2021 at 18:36):

Oh, whoa, I didn't expect that to work because I thought List.keepOks wasn't implemented yet (also missing from builtins/docs). Your shorter alternative works like a charm!

jan kili (Dec 13 2021 at 18:36):

List.keepOks is going to be a huge help for AoC, since inputs are highly controlled

jan kili (Dec 13 2021 at 18:38):

Actually, we can make it even cleaner by making it slightly point-free-er: parseIntegers = \integerStrings -> integerStrings |> List.keepOks Str.toI64

jan kili (Dec 13 2021 at 18:39):

I wonder if there's a way to make it totally point-free by eliminating the need for integerStrings...

Lucas Rosa (Dec 13 2021 at 19:36):

Lucas Rosa (Dec 13 2021 at 19:37):

roc doesn't do that. point-free is cute but honestly it can lead to some confusing code especially for people not familiar with ML style languages

Richard Feldman (Dec 13 2021 at 20:27):

@JanCVanB regarding the "entered unreachable code" panic you saw - any time you see that error message, it's definitely a compiler bug! It means the compiler went down a code path that we thought was unreachable.

Folkert de Vries (Dec 13 2021 at 20:34):

and given the location it's probably some error in llvm codegen, which is particularly interesting

Lucas Rosa (Dec 13 2021 at 21:05):

jan kili (Dec 13 2021 at 23:03):

I'm glad y'all aren't tired of me spamming my beginner questions for my beginner use case :)

Richard Feldman (Dec 14 2021 at 00:39):

Lucas Rosa (Dec 14 2021 at 01:24):

@JanCVanB not at all, in a way you’ve used more roc than all of us, we’re the beginners

jan kili (Dec 14 2021 at 01:30):

Sebastian Fischer (Dec 14 2021 at 23:46):

Because of a memory issue with large lists I tried to use my own type for linked lists and ran into three separate problems.

The first problem can be reproduced by replacing the hello-world example with the following program.

LinkedList elem : [Empty, Prepend (LinkedList elem) elem]

prepend : LinkedList elem, elem -> LinkedList elem
prepend = Prepend

single : elem -> LinkedList elem
single = \elem -> prepend Empty elem

main =
    nested = single (single 42)
    "Hello, World!\n"

thread 'main' panicked at 'internal error: entered unreachable code: symbol/layout `#UserApp.1` ProcLayout { arguments: [Union(NullableUnwrapped { nullable_id: false, other_fields: [RecursivePointer, Builtin(Int(I64))] }), Builtin(Int(I64))], result: Union(NullableUnwrapped { nullable_id: false, other_fields: [RecursivePointer, Builtin(Int(I64))] }) } combo must be in DeclarationToIndex', compiler/mono/src/borrow.rs:227:9

The program runs as intended when inlining prepend or single or when changing the definition of prependas shown below.

The second issue can be reproduced by adding/changing the following definitions:

empty : LinkedList *
empty = Empty

prepend : LinkedList elem, elem -> LinkedList elem
prepend = \elems, elem -> Prepend elems elem

wrap : LinkedList elem -> LinkedList (LinkedList elem)
wrap = \elems ->
    when elems is
        Empty -> empty
        Prepend tail head -> tail |> wrap |> prepend (single head)

main =
    nested = wrap (single 42)
    "Hello, World!\n"

Application crashed with message

    Hit an unresolved type variable 103 when creating a layout for `#UserApp.empty` (var 102)

Shutting down

The error goes away when replacing empty with Empty in the definition of wrap.

The third issue is a stack overflow when compiling (or running roc check) on the following definition:

fromList : List elem -> LinkedList elem
fromList = \elems -> List.walkBackwards elems Empty Prepend

Compilation works fine when replacing Empty with empty in the definition of fromList.

By using the described work-arounds, I was able to change my program for AoC Day 1 to use linked lists instead of built-in lists to solve the problem for the large input!

Should I create issues for the described problems or are they expected / already known?

Richard Feldman (Dec 15 2021 at 03:06):

Sebastian Fischer (Dec 15 2021 at 09:03):

Richard Feldman (Dec 15 2021 at 11:32):

jan kili (Dec 21 2021 at 06:05):

jan kili (Dec 21 2021 at 06:08):

Pipe chains are super readable, the Result builtins are intuitive... and though I've hit a lot of compiler bugs, there are always acceptable workarounds.

Lucas Rosa (Dec 21 2021 at 06:39):

jan kili (Dec 21 2021 at 15:53):

Today's multiverse problem (part 2) seems like it could cause some stack overflows, though I imagine there's some optimization(s) that could help somehow. However, even with a quick recursion-ending condition (maxScore=5, instead of 21), I'm getting a new kind of compiler error:

Stored value type does not match pointer operand type! ... Function "..." failed LLVM verification in NON-OPTIMIZED build. ... thread 'main' panicked at '😱 LLVM errors when defining function ...

. I'll create a GH issue.

jan kili (Dec 21 2021 at 16:01):

Folkert de Vries (Dec 21 2021 at 16:02):

something to watch out for is that True itself has type [ True ]*, not Bool

Folkert de Vries (Dec 21 2021 at 16:02):

jan kili (Dec 21 2021 at 16:06):

jan kili (Dec 21 2021 at 16:07):

Essentially, something works with { oldRecord & thing: True, a: b, x: y } but not with { oldRecord & thing: False, a: b, x: y }

Folkert de Vries (Dec 21 2021 at 16:08):

right, I think you can fix it quickly with a type annotation to coerce the value to be a bool

jan kili (Dec 21 2021 at 16:08):

jan kili (Dec 21 2021 at 16:17):

InitialSetup : { player1Position: Nat, player2Position: Nat }
Multiverse : { player1WinCount: Nat, player2WinCount: Nat, universes: List Universe }
Universe : { isPlayer1sTurn: Bool, player1Position: Nat, player1Score: Nat, player2Position: Nat, player2Score: Nat }
initializeMultiverse : InitialSetup -> Multiverse
initializeMultiverse = \setup ->
    universe : Universe
    universe = { isPlayer1sTurn: True, player1Position: setup.player1Position, player1Score: 0, player2Position: setup.player2Position, player2Score: 0 }
    { player1WinCount: 0, player2WinCount: 0, universes: [universe] }

The body is a record of type:

    { player1WinCount : Num (Integer Natural),
    player2WinCount : Num (Integer Natural), universes : List {
    isPlayer1sTurn : Bool, player1Position : Nat, player1Score : Nat,
    player2Position : Nat, player2Score : Nat } }

But the type annotation on initializeMultiverse says it should be:

    { player1WinCount : Nat, player2WinCount : Nat,
    universes : List Universe }

jan kili (Dec 21 2021 at 16:18):

Folkert de Vries (Dec 21 2021 at 16:18):

isPlayer1sTurn:  Bool
isPlayer1sTurn = True

jan kili (Dec 21 2021 at 16:28):

It looks to me that both of the supposedly-mismatched types above have Bool in them, is that not sufficient?

jan kili (Dec 21 2021 at 16:29):

InitialSetup : { player1Position: Nat, player2Position: Nat }
Multiverse : { player1WinCount: Nat, player2WinCount: Nat, universes: List Universe }
Universe : { isPlayer1sTurn: Bool, player1Position: Nat, player1Score: Nat, player2Position: Nat, player2Score: Nat }
initializeMultiverse : InitialSetup -> Multiverse
initializeMultiverse = \setup ->
    isPlayer1sTurn : Bool
    isPlayer1sTurn = True
    universe : Universe
    universe = { isPlayer1sTurn: isPlayer1sTurn, player1Position: setup.player1Position, player1Score: 0, player2Position: setup.player2Position, player2Score: 0 }
    { player1WinCount: 0, player2WinCount: 0, universes: [universe] }

Folkert de Vries (Dec 21 2021 at 16:35):

Folkert de Vries (Dec 21 2021 at 16:36):

Folkert de Vries (Dec 21 2021 at 16:37):

due to a bug, aliases must be defined in their usage order (so no use before definition)

jan kili (Dec 21 2021 at 16:39):

Wowwwwww you're right! Flipping the order of the Multiverse and Universe definitions fixes it!

jan kili (Dec 21 2021 at 17:32):

Now I just have to optimize it so that it won't take... (checks calculator)... a week to run.

Brian Carroll (Dec 21 2021 at 18:48):

Glad you're posing this stuff, Jan, it's really interesting, keep up the good work!

jan kili (Dec 21 2021 at 18:51):

Brendan Hansknecht (Dec 21 2021 at 18:54):

That's a handful... Maybe enough to not compete with bad code generation/recursion issues

Takeshi Sato (Dec 31 2021 at 14:12):

This is my output
https://gist.github.com/satotake/0e5f4cb69924927cbce379212e102081
not completed (day1 - day14)
I might add the others but I am starting feeling that they will be almost same in terms of testing roc.
Seeing @Lucas Rosa 's private leaderboard, Arkham is legendary.

jan kili (Dec 31 2021 at 14:14):

You might have written the most AoC Roc code of anyone, since I'm not sure that everyone in that leaderboard used Roc!

Takeshi Sato (Dec 31 2021 at 14:40):

possible ... but really?.
Anyway, the conversations in this channel motivated me to do so. thanks!

Lucas Rosa (Dec 31 2021 at 18:20):

I was using zig but then just quit after day 3 cause I was like why am I doing this

Takeshi Sato (Jan 02 2022 at 13:37):

Nicola Peduzzi (Jun 01 2022 at 08:09):

hah! from time to time I re-compile roc, fix any error that come up on the platform I stitched up and try my day 1 advent of code 2021 program. it finally worked :tada:

app "day-01"
    packages { pf: "cli-platform" }
    imports [ pf.Task.{ Task, await }, pf.Stdout, pf.File ]
    provides [ main ] to pf

main =
    handle <- File.withOpen "day-01-input.txt"
    stringLines <- await (File.lines handle)

    lines = stringLines |> List.map \n -> (Str.toNat n |> Result.withDefault 0)

    increases = lines
        |> List.walk { count: 0, prev: None } \res, m ->
            when res.prev is
                Some p ->
                    count = res.count + (if p < m then 1 else 0)
                    { count, prev: Some m }
                None -> { count: res.count, prev: Some m }

    r = Num.toStr increases.count

    Stdout.line "res: \(r)"

Stream: beginners

Topic: Advent of Code 2021

Richard Feldman (Nov 21 2021 at 13:39):

Johannes Maas (Nov 21 2021 at 13:42):

Lucas Rosa (Nov 21 2021 at 18:37):

Richard Feldman (Nov 21 2021 at 18:39):

Lucas Rosa (Nov 21 2021 at 18:40):

Lucas Rosa (Nov 21 2021 at 18:41):

Lucas Rosa (Nov 21 2021 at 18:47):

Lucas Rosa (Nov 21 2021 at 18:47):

Brendan Hansknecht (Nov 21 2021 at 19:31):

Brian Carroll (Nov 21 2021 at 21:18):

Brian Carroll (Nov 21 2021 at 21:19):

Lucas Rosa (Nov 21 2021 at 21:40):

Lucas Rosa (Nov 21 2021 at 21:41):

Brendan Hansknecht (Nov 21 2021 at 21:44):

Lucas Rosa (Nov 21 2021 at 21:49):

Johannes Maas (Nov 28 2021 at 15:23):

Pit Capitain (Nov 28 2021 at 15:43):

Johannes Maas (Nov 28 2021 at 17:00):

Richard Feldman (Nov 29 2021 at 03:51):

Richard Feldman (Nov 29 2021 at 03:51):

Pit Capitain (Nov 29 2021 at 06:29):

Richard Feldman (Nov 29 2021 at 13:58):

Lucas Rosa (Nov 29 2021 at 15:07):

Lucas Rosa (Nov 29 2021 at 15:07):

Martin Janiczek (Dec 01 2021 at 08:46):

Yann Simon (Dec 01 2021 at 09:05):

Yann Simon (Dec 01 2021 at 09:28):

Yann Simon (Dec 01 2021 at 09:51):

Anton (Dec 01 2021 at 10:02):

Anton (Dec 01 2021 at 10:29):

Yann Simon (Dec 01 2021 at 10:37):

Martin Janiczek (Dec 01 2021 at 10:46):

Anton (Dec 01 2021 at 11:24):

Laurence Joseph Pakenham-Smith (Dec 01 2021 at 14:51):

Shrikanth Upadhayaya (Dec 01 2021 at 14:54):

Shrikanth Upadhayaya (Dec 01 2021 at 14:55):

Laurence Joseph Pakenham-Smith (Dec 01 2021 at 14:56):

Shrikanth Upadhayaya (Dec 01 2021 at 14:59):

Laurence Joseph Pakenham-Smith (Dec 01 2021 at 14:59):

Shrikanth Upadhayaya (Dec 01 2021 at 14:59):

Laurence Joseph Pakenham-Smith (Dec 01 2021 at 15:00):

Lucas Rosa (Dec 01 2021 at 15:58):

Lucas Rosa (Dec 01 2021 at 15:58):

Jason Hobbs (Dec 01 2021 at 16:12):

Lucas Rosa (Dec 01 2021 at 16:15):

Jason Hobbs (Dec 01 2021 at 16:18):

Lucas Rosa (Dec 01 2021 at 16:25):

Brendan Hansknecht (Dec 01 2021 at 18:15):

Tim Whiting (Dec 02 2021 at 01:03):

Yann Simon (Dec 02 2021 at 03:11):

Yann Simon (Dec 02 2021 at 03:25):

Shrikanth Upadhayaya (Dec 02 2021 at 03:40):

Shrikanth Upadhayaya (Dec 02 2021 at 03:40):

Yann Simon (Dec 02 2021 at 03:41):

Yann Simon (Dec 02 2021 at 03:48):

Yann Simon (Dec 02 2021 at 03:55):

Shrikanth Upadhayaya (Dec 02 2021 at 03:58):

Shrikanth Upadhayaya (Dec 02 2021 at 03:59):

Shrikanth Upadhayaya (Dec 02 2021 at 03:59):

Yann Simon (Dec 02 2021 at 04:02):

Yann Simon (Dec 02 2021 at 04:18):

Sam Mohr (Dec 02 2021 at 04:38):

Brendan Hansknecht (Dec 02 2021 at 04:41):

Brendan Hansknecht (Dec 02 2021 at 04:42):

Yann Simon (Dec 02 2021 at 09:17):

Lucas Rosa (Dec 02 2021 at 16:03):

Richard Feldman (Dec 05 2021 at 14:21):

jan kili (Dec 06 2021 at 02:30):

jan kili (Dec 06 2021 at 02:32):

jan kili (Dec 06 2021 at 02:34):

Anton (Dec 06 2021 at 13:36):

Ju Liu (Dec 06 2021 at 14:29):

Anton (Dec 06 2021 at 14:36):

Ju Liu (Dec 06 2021 at 15:54):

Anton (Dec 06 2021 at 17:01):

Ju Liu (Dec 06 2021 at 17:56):

Ju Liu (Dec 06 2021 at 17:56):

Ju Liu (Dec 06 2021 at 17:57):