Stream: beginners

Topic: early-user problems

Pit Capitain (Oct 29 2020 at 15:21):

This topic is not about compiler development, but to discuss problems writing Roc programs in this early stage.

Pit Capitain (Oct 29 2020 at 15:22):

One of the bugs I encountered and seemingly was able to fix concerns List.walkRight. Should I simply create a branch and a pull request? Are there any naming conventions?

Chad Stearns (Oct 29 2020 at 15:33):

Yeah I think a PR would be great. We made walkRight fairly recently. What was the problem?

Chad Stearns (Oct 29 2020 at 15:34):

I dont think we have any PR naming conventions right now

Pit Capitain (Oct 29 2020 at 16:47):

It doesn't work if the "accumulator" is not an Int, but for example a string or a record. PR created.

Pit Capitain (Oct 29 2020 at 20:05):

Maybe my biggest obstacle is not being able to split code into multiple files:

Pit Capitain (Oct 29 2020 at 20:06):

This doesn't work:

interface Dep exposes [ value ] imports []

value : Str
value = "Dep.value"

app Main provides [ main ] imports [ Dep ]

main : Str
main = Dep.value

Pit Capitain (Oct 29 2020 at 20:07):

This works:

interface Dep exposes [ value ] imports []

value : {} -> Str
value = \_ -> "Dep.value"

app Main provides [ main ] imports [ Dep ]

main : Str
main = Dep.value {}

Pit Capitain (Oct 29 2020 at 20:10):

This doesn't work:

interface Dep1 exposes [ value1 ] imports []

value1 : {} -> Str
value1 = \_ -> "Dep1.value1"

interface Dep2 exposes [ value2 ] imports []

value2 : {} -> Str
value2 = \_ -> "Dep2.value2"

app Main provides [ main ] imports [ Dep1, Dep2 ]

main : Str
main = Str.concat (Dep1.value1 {}) (Dep2.value2 {})

Pit Capitain (Oct 29 2020 at 20:13):

This doesn't work either:

interface Dep1 exposes [ value1 ] imports [ Dep2 ]

value1 : {} -> Str
value1 = \_ -> Dep2.value2 {}

interface Dep2 exposes [ value2 ] imports []

value2 : {} -> Str
value2 = \_ -> "Dep2.value2"

app Main provides [ main ] imports [ Dep1 ]

main : Str
main = Dep1.value1 {}

Pit Capitain (Oct 29 2020 at 20:15):

They all panic with different errors. It seems that currently I can only import functions from exactly one other file. BTW: I'm on MacOs.

Folkert de Vries (Oct 29 2020 at 20:32):

they all hit hard asserts though? Usually module loading problems result in a deadlock

Folkert de Vries (Nov 02 2020 at 23:32):

got this fixed in the PR. thanks for reporting/partially fixing!

Pit Capitain (Nov 12 2020 at 17:37):

Here's a stripped down version of another problem. It compiles but on running it reports a "pointer being freed was not allocated" error (on MacOs):

app Main provides [ main ] imports []

main : Str
main =
    addText = \addedText, oldText -> Str.concat oldText addedText
    List.walkRight [ "", "Very very long str" ] addText ""

It works if I use a short string, and works with the long string, too, if I switch the arguments of Str.concat. I tried to debug it in lldb, but haven't been able to find the culprit.

Pit Capitain (Dec 01 2020 at 11:00):

Today is the first day of the Advent of Code programming contest. I'd like to "participate" using Roc as my programming language. As always, the first problem is really simple: given a list of 200 integers, find a pair where the sum is 2020 and output their product. Unfortunately, I haven't been able yet to implement this with the current trunk of the compiler. No matter which way I chose, the compiler is always yelling at me.

Pit Capitain (Dec 01 2020 at 11:01):

I'd be grateful if someone more knowledgeable in Roc / the compiler could give this a try. Link to the contest page: https://adventofcode.com

Anton (Dec 01 2020 at 11:10):

Could you a share a minimal compiling example that is similar to the problem that you are trying to solve?

Pit Capitain (Dec 01 2020 at 11:28):

Thanks for the quick reply. Lunch break is over, so it'll be a couple of hours. Would you like a complete directory like in the examples folder or just a Roc file?

Anton (Dec 01 2020 at 11:30):

You're welcome :). The full directory would probably be the easiest.

Folkert de Vries (Dec 01 2020 at 13:12):

from a quick experiment, it's easy to trigger internal error: entered unreachable code: Invalid function basic value enum or layout for List.map. I'll see if I can fix that

Pit Capitain (Dec 01 2020 at 15:52):

Here's a repository I quickly setup: https://github.com/pithub/aoc2020. It assumes the Roc repository is in a parallel directory called "lang". So I have the directories "roc/lang" and "roc/aoc2020". I chose List (List Int) for the output format, because I had malloc/free problems with Strings, and wanted to output multiple values per test case.

Pit Capitain (Dec 01 2020 at 15:53):

Ah, I forgot to add the desired solution for the sample input:
"In this list, the two entries that sum to 2020 are 1721 and 299. Multiplying them together produces 1721 * 299 = 514579, so the correct answer is 514579."

Richard Feldman (Dec 01 2020 at 15:57):

btw thank you so much @Pit Capitain for being the first person to use Roc for Advent of Code...I'm really excited to see the bugs this will surface, and the resulting improvements to the compiler! :heart:

Pit Capitain (Dec 01 2020 at 16:02):

You're very welcome :smile: Unfortunately I haven't been able to fix some more problems - yet.

Richard Feldman (Dec 01 2020 at 16:05):

no worries! Finding out what they are is a major help on its own :big_smile:

Folkert de Vries (Dec 01 2020 at 16:25):

yea so I made some steps, and I can find the correct answer, but not print it correctly, because there is a bug in Str.concat

Pit Capitain (Dec 01 2020 at 18:57):

Cool, Folkert. Any branch you can share? What do you need Str.concatfor? At least for the first challenge, we'd only need an Int. (I also had problems using strings, so I switched to List (List Int) for the output.)

Folkert de Vries (Dec 01 2020 at 19:05):

well you need to get the result out . You could pass the result through the FFI boundary, but I wanted to print it to stdout immediately

Pit Capitain (Dec 01 2020 at 19:54):

Ah OK. I just use RocCallResult<RocList<RocList<i64>>> to return the results.

Pit Capitain (Dec 01 2020 at 19:55):

In the meantime, I found a working solution :rock_on: And it's your sample code, Folkert, that made it possible :muscle:
Now a little bit of cleaning up and then the next day's puzzle may come!

Folkert de Vries (Dec 01 2020 at 20:01):

nice!

Richard Feldman (Dec 01 2020 at 20:05):

cool! I'd love to see it, if you're comfortable sharing! :smiley:

Folkert de Vries (Dec 01 2020 at 20:30):

I made some improvements here https://github.com/rtfeldman/roc/pull/756

Folkert de Vries (Dec 01 2020 at 20:31):

besides all the noise of the zig formatter, it makes the compiler work again on my machine by only conditionally following the arch path, can print Result in the repl, and allows List.map to call closures

Folkert de Vries (Dec 01 2020 at 20:31):

other builtins cannot yet call closures in all circumstances though

Pit Capitain (Dec 02 2020 at 17:02):

Day 2 could also be solved with the current Roc, and I indeed used List.map with a closure, so thank you very much Folkert for this :handshake:

Pit Capitain (Dec 02 2020 at 17:12):

The repository currently is here: https://github.com/pithub/aoc2020. If there's interest, where and how should I write about my trials and errors? I could add some notes and create branches in this repository with the different variations I tried, but maybe there's a better way?

Lucas Rosa (Dec 02 2020 at 17:34):

nice very cool

Brendan Hansknecht (Dec 02 2020 at 19:27):

If you have variations that you thought should work but don't, putting them on a branch would be reasonable. Otherwise, comments or just a text log would probably be useful.

Richard Feldman (Dec 02 2020 at 20:29):

hahaha I love that you actually used our quicksort implementation for a real solution! :joy_cat:

Richard Feldman (Dec 02 2020 at 20:29):

brilliant!

Pit Capitain (Dec 02 2020 at 22:15):

I added a document describing what I tried today, what failed and what succeeded.

Richard Feldman (Dec 02 2020 at 22:28):

wow, super helpful!

Richard Feldman (Dec 03 2020 at 04:02):

ok the original countMember implementation should now work on trunk!

Richard Feldman (Dec 03 2020 at 04:05):

it was complaining about keepIf needing another argument in |> List.keepIf isGivenElement because under those particular circumstances it was parsing isGivenElement as an is keyword (from when / is) instead of an argument

Richard Feldman (Dec 03 2020 at 04:05):

fixed now!

Lucas Rosa (Dec 03 2020 at 14:17):

I think I’m jealous of all this AOC roc code being written :p lol

Pit Capitain (Dec 04 2020 at 04:32):

Just wanted to say thank you for all the work currently going on, some of which will be immediately helpful for the next puzzles. Yesterday I had a very long work day because of a production problem, so I hadn't enough time yet to write about the Day 3 experience. All puzzles could be solved yet :+1:

Pit Capitain (Dec 04 2020 at 04:35):

Concerning the long build times for long input data: if I have time, I'll try to change the platform code to read the puzzle input from a file and pass the List (List Int) data as a parameter to the Roc main function. This way I could avoid the long literals.

Pit Capitain (Dec 04 2020 at 04:41):

I think I’m jealous of all this AOC roc code being written :p lol

You can join the contest any time you like :smirk: Pull requests are always welcome, too...

Lucas Rosa (Dec 04 2020 at 18:53):

awesome

Folkert de Vries (Dec 06 2020 at 00:48):

@Pit Capitain I'll soon push a fix for the stack overflow for large literals. Just to check, were you building the compiler with --release mode? it really speeds up the compilation process on my machine (~7 seconds to < 1)

Richard Feldman (Dec 06 2020 at 03:41):

:point_up: this is now merged into trunk!

Pit Capitain (Dec 06 2020 at 04:37):

Thank you both. I always compiled without --release. Not knowing Rust very well, I assumed that using it would perform more optimisations and there fore would be even slower :face_palm:

Pit Capitain (Dec 06 2020 at 04:40):

Yesterday I added a file reader effect to my platform, so currently I'm not dependent on large literals anymore. But as soon as parsing the input wouldn't work or the test data gets bigger, I would need it. I'll definitely give it a go!

Richard Feldman (Dec 06 2020 at 12:30):

Yesterday I added a file reader effect to my platform, so currently I'm not dependent on large literals anymore.

wow, I think that makes you the first person to ever solve a problem in Roc by adding a new effect to the platform! :smiley:

Richard Feldman (Dec 06 2020 at 12:31):

glad to hear that solution worked!

Pit Capitain (Dec 06 2020 at 14:42):

Yeah, it worked almost flawlessly. There were some problems, but for my usecase all went well.

Pit Capitain (Dec 06 2020 at 14:49):

@Folkert de Vries I went back to debug mode, because in release mode effects didn't work for me. The effect example had the same problem. I think the compiler reported that it couldn't find the Effect.rocfile. Seems not too hard to fix, but I preferred to refactor my code from the last days in order to be better prepared for the next puzzles...

Folkert de Vries (Dec 06 2020 at 18:55):

if you have no imports in your app module (builtin modules don't count for this) you can comment out this section and --release should work

    // all the dependencies can be loaded
    for dep in dependencies {
        // TODO figure out how to "load" (because it doesn't exist on the file system) the Effect module
        if !format!("{:?}", dep).contains("Effect") {
            output.insert((*dep, LoadHeader));
        }
    }

Folkert de Vries (Dec 06 2020 at 18:55):

in load/src/file.rs line ~143

Lucas Rosa (Dec 06 2020 at 18:56):

https://github.com/rtfeldman/roc/pull/752
this might help with that once it's done?

Folkert de Vries (Dec 06 2020 at 18:56):

yup!

Lucas Rosa (Dec 06 2020 at 18:57):

I'm gonna show it some more love today. I have to admit it's been challenging but I make some progress every time I touch it

Pit Capitain (Dec 06 2020 at 19:34):

Thank you Folkert, I will try this eventually. Thank you too, Lucas, but please don't change your priorities jut because of my trials. So far it has been a nice experience overall. Let's see how far I'll get if the puzzles get harder to solve...

Pit Capitain (Dec 12 2020 at 07:05):

Just a short update from AoC 2020: I could solve all puzzles so far with Roc programs (a few times externally preprocessing the puzzle input text) :thumbs_up:

Pit Capitain (Dec 12 2020 at 07:06):

Unfortunately, I'm still stuck at commit 149d10ea. The effect examples don't work on my MacBook for newer commits. Here's a short summary of the examples in trunk ("r" means building with --release, "o" with --optimize:

Pit Capitain (Dec 12 2020 at 07:08):

example           ro   r-   -o   --
----------------  ---  ---  ---  ---
balance           fnf  fnf  fnf  fnf
closure           ok   ok   ok   ok
effect            tmm  hlt  tmm  hlt
hello-world       ok   ok   ok   ok
quicksort         ok   ok   ok   ok
shared-quicksort  ok   ok   ok   ok
task              gaa  ftr  gaa  ftr

fnf
  FileProblem { filename: "/Users/pit/Documents/work/roc/trunk/examples/balance/Effect.roc", error: NotFound, msg: "in `load_filename`" }
  compiler/load/src/file.rs:1261:46

ftr
  Failed to run app after building it: Os { code: 2, kind: NotFound, message: "No such file or directory" }
  cli/src/lib.rs:124:35

gaa
  TODO generate aa, ab, ac, ...
  compiler/types/src/types.rs:1457:9

hlt
  app builds but doesn't terminate

tmm
  Roc failed with message: Hit an erroneous type when creating a layout for `11.IdentId(3)`
  src/lib.rs:108:17

Folkert de Vries (Dec 12 2020 at 12:22):

I think you should try things without --optimize; the uniqueness analysis is not entirely reliable

Folkert de Vries (Dec 12 2020 at 12:23):

especially with effects, which are defined as a recursive tag union, type errors are almost guaranteed

Folkert de Vries (Dec 12 2020 at 12:23):

the FileProblem is something I've seen too, but it seems infrequent and hard to reproduce (I'm assuming the problem is a race condition in file.rs)

Richard Feldman (Dec 12 2020 at 12:42):

to elaborate on that, we had some regressions in the uniqueness analysis that we decided not to look into because there's a solid chance we'll end up overhauling that whole system in the near-ish future anyway :big_smile:

Pit Capitain (Dec 19 2020 at 17:27):

I got stuck on my AoC adventure. I'll write more about this soon. Currently I'm trying to update the compiler. Unfortunately, something seems to be wrong on my Mac running Catalina. For the task example the linker says: Undefined symbols for architecture x86_64: "start", referenced from: implicit entry/start for main executable. ld: symbol(s) not found for architecture x86_64

Pit Capitain (Dec 19 2020 at 17:28):

If i add the parameters "-e _main", it says: ld: targeted OS version does not support use of thread local variables in _std.debug.panicExtra for architecture x86_64

Pit Capitain (Dec 19 2020 at 17:28):

Any hint what I could do to make the examples run again?

Folkert de Vries (Dec 19 2020 at 17:40):

what language is your host written in?

Folkert de Vries (Dec 19 2020 at 17:40):

looks like it might be zig?

Pit Capitain (Dec 19 2020 at 18:11):

It is the task example. I also think it could be something with zig. My version is 0.7.0+391d81a38. Btw: thank you Folkert for the fast reply.

Folkert de Vries (Dec 19 2020 at 18:13):

yea its platform is written in zig, so you may have better luck with the effect examples as a foundation

Folkert de Vries (Dec 19 2020 at 18:13):

and I think we could update to the latest zig release

Pit Capitain (Dec 19 2020 at 18:14):

OK, I'll try that.

Folkert de Vries (Dec 19 2020 at 18:14):

so that would be 0.7.1 I think

Jared Ramirez (Dec 19 2020 at 18:46):

Yeah, I've been meaning to upgrade to the latest zig version since 0.7 came out

erichenry (Mar 13 2021 at 02:07):

Has anyone ever encountered this error when trying to run cargo clippy or cargo test locally? I am on ubuntu 20.04.2 LTS

thread 'main' panicked at 'Could not execute clang: Os { code: 2, kind: NotFound, message: "No such file or directory" }', roc_std/build.rs:36:10

I have clang++-10 installed is there another version that I should have?

erichenry (Mar 13 2021 at 02:07):

sorry if this isn't the right channel for this >.<

Folkert de Vries (Mar 13 2021 at 03:13):

we use clang there, by default the alias is clang-10 I think

Folkert de Vries (Mar 13 2021 at 03:13):

so a symlink should do the trick

Anton (Mar 13 2021 at 09:09):

general fyi for everyone, you can always check the Earthfile for the complete "installation from source procedure" for debian based operating systems that is always up to date. You may still need additional dependencies to run the editor. I'll add an issue for that.

erichenry (Mar 13 2021 at 11:21):

Thanks guys!

erichenry (Mar 13 2021 at 13:01):

Linking did the trick! also the Earth file was super helpful! ended up fixing a couple of things thanks to it :muscle:

Lucas Rosa (Mar 13 2021 at 19:25):

Nice. I'm on MacOS. I've downloaded a pre-built LLVM and then added this little function to my .zshrc. I use this function as a prefix before every cargo command when running roc.

rocx() {
  LLVM_SYS_100_PREFIX=~/Downloads/llvm PATH="$PATH:$PWD/nix/bin:~/Downloads/llvm:~/Downloads/llvm/bin" $@
}

Lucas Rosa (Mar 13 2021 at 19:25):

ex: rocx cargo run repl

Lucas Rosa (Mar 13 2021 at 19:27):

Although, I think I want to start using Linux for roc dev stuff. I'm on the fence between building a machine, buying a decent laptop, or dual booting on my MacBook. If anyone has any recommendations I'm open :D

Richard Feldman (Mar 13 2021 at 20:10):

in the past (last time I tried was...I think 5 years ago?) I've had problems with battery life when dual booting a MacBook to Linux - also the keyboard layout is kinda weird, because Linux wants all the keyboard shortcuts to be Ctrl- based, whereas Mac wants them all to be Cmd-based, and the MacBook keyboard doesn't have the Ctrl key in a particularly comfortable place imo

Richard Feldman (Mar 13 2021 at 20:11):

I have a Linux desktop and a Razer Blade 14" laptop, both dual booting Windows and Linux, and have been overall happy with both!

Lucas Rosa (Mar 13 2021 at 20:28):

Nice I'll look into that model thanks. By the time I graduated college I was running NixOS on Mac via dual boot. XMonad and no DE smh lol. Working on a contract using emacs and elixir, those where the days. Functional down to the OS lol

Anton (Mar 14 2021 at 08:50):

I really like my DIY desktop. The case, power supply, RAM and SSD are all things that can last several upgrade cycles and save you money this way. The form factor allows for much more powerful cooling than a laptop and thus a more powerful CPU and/or graphics card.

Chad Stearns (Apr 24 2021 at 17:42):

Whenever I run a program, I get a little message 'ld: framework not found Security'

Chad Stearns (Apr 24 2021 at 17:43):

But the program runs fine anyway.

Chad Stearns (Apr 24 2021 at 17:43):

Should I make an issue?

Lucas Rosa (Apr 24 2021 at 18:00):

It's mostly just so that the CLI example runs properly due to a dependency in the Rust platform that the CLI example uses @Chad Stearns

Lucas Rosa (Apr 24 2021 at 18:01):

long term we wouldn't be doing that anyways. On my mac ld also can't find the security framework so I just comment out those args

Last updated: Jul 05 2025 at 12:14 UTC