Stream: beginners

Topic: error messages


view this post on Zulip James Carlson (Aug 10 2021 at 18:10):

Anyone spot my error below?

app "Tester"
    packages { base: "platform" }
    imports [base.Task,  Test]
    provides [ main ] to base

main : Task.Task {} []
main =
    t1 = { name : "1 + 1 = 2", test: 1 + 1 == 2 }
    t2 = { name : "2 + 2 = 5", test: 2 + 2 == 5 }
    #
    # The first three lines below succeed, the last one fails: emitted runtime error ...
    # Test.evalTest t1
    # Test.evalTest t2
    # Test.strListToStr ["a", "b", "c"] ","
    List.map [t1,t2] evalTest |> Test.strListToStr ","
       |> Task.putLine

The code is in the jim branch: see Tester.roc and Test.roc

view this post on Zulip James Carlson (Aug 10 2021 at 19:12):

In the above code, fail on List.map [t1,t2] evalTest |> Test.strListToStr ",", no useful error messages, just "error"

view this post on Zulip Folkert de Vries (Aug 10 2021 at 19:16):

did you compile the roc compiler in release or debug mode (debug is the default)?

view this post on Zulip James Carlson (Aug 10 2021 at 19:23):

Probably debug: target/debug/roc examples/benchmarks/Tester.roc. I don't remember how I installed it.

view this post on Zulip James Carlson (Aug 10 2021 at 19:31):

Here is the full error message:

➜  roc git:(jim) vr test
    Finished dev [unoptimized + debuginfo] target(s) in 1.02s
     Running `target/debug/roc examples/benchmarks/Tester.roc`
emitted runtime error LookupNotInScope(|L 17-17, C 21-29| Ident(IdentStr { is_small_str: true, string: "evalTest", elements: [101, 118, 97, 108, 84, 101, 115, 116] }), {"U8", "F64", "Binary32", "Integer", "Nat", "I128", "Decimal", "Dec", "Signed8", "Dict", "Str", "Binary64", "Result", "I64", "U64", "FloatingPoint", "F32", "Float", "Unsigned8", "Natural", "Signed16", "Signed64", "main", "Int", "Num", "U16", "Set", "t2", "I32", "t1", "Unsigned32", "Signed128", "List", "Unsigned16", "Signed32", "Unsigned64", "Unsigned128", "U32", "Bool", "I16", "I8", "U128"})
thread '<unnamed>' panicked at 'index out of bounds: the len is 0 but the index is 0', compiler/mono/src/ir.rs:7649:35
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

view this post on Zulip Folkert de Vries (Aug 10 2021 at 19:38):

so that says that evalTest is not in scope

view this post on Zulip James Carlson (Aug 10 2021 at 19:44):

Good to know that I can extract info from those messages. Thanks!

I put in the missing Test. so as to have List.map [t1,t2] Test.evalTest |> Test.strListToStr ","

Alas, I still get an error:

➜  roc git:(jim) ✗ vr test
    Finished dev [unoptimized + debuginfo] target(s) in 0.69s
     Running `target/debug/roc examples/benchmarks/Tester.roc`
error: Failed at the test script

The script is cargo run examples/benchmarks/Tester.roc

view this post on Zulip Richard Feldman (Aug 10 2021 at 21:18):

@James Carlson it would be awesome if you could post an issue with a .roc file that reproduces that LookupNotInScope error, so we can make sure it gives a proper compile-time error!

view this post on Zulip James Carlson (Aug 10 2021 at 21:21):

Will do!

view this post on Zulip Folkert de Vries (Aug 10 2021 at 21:22):

it would give one if we didn't panic later in mono

view this post on Zulip Folkert de Vries (Aug 10 2021 at 21:22):

the real reason I think is that we don't make specializations when we know the function will blow up when we call it

view this post on Zulip Folkert de Vries (Aug 10 2021 at 21:22):

but the mono machinery assumes that function does exist

view this post on Zulip James Carlson (Aug 11 2021 at 07:08):

This message illustrates the use of a small testing framework (LOL!) in interface Test of the jim branch (examples/benchmarks). It is for the parser project I'm working on. Here is an example (code is in ParseApp).

➜  roc git:(jim) ✗ cargo run examples/benchmarks/ParseApp.roc
    Finished dev [unoptimized + debuginfo] target(s) in 0.27s
     Running `target/debug/roc examples/benchmarks/ParseApp.roc`
Pass :: run "abcd any => "a"
Pass :: run "abcd" satisfy (\u -> u == 97)) => "a"
Pass :: Use 'second' to recognize "a" then "b" returning "b"
Pass :: Use 'first' to recognize "a" then "b" returning "a"
Pass :: Use map to shift output of parser: run "abcd" (map any (\u -> u + 25)) == "z"
Pass :: Use andThen to recognize strings beginning with two repeated letters (succeed on input "aaxyz")
runtime: 0.380ms

Of course you can also get Fail ::

Tests look like this:

p4 = {name : "Use 'first' to recognize \"a\" then \"b\" returning \"a\"", test : run "abcd" (first  satisfyA satisfyB) == "a"}

A "suite" of tests is run like this:

[Test.eval p1, Test.eval p2, Test.eval p3, Test.eval p4, Test.eval p5, Test.eval p6]
    |> Test.strListToStr "\n"
          |> Task.putLine

For some reason, the more beautiful yet seemingly equivalent code below gives an error:

 List.map [p1, p2, p3, p4, p5, p6] Test.eval
       |> Test.strListToStr "\n"
       |> Task.putLine

The error message is not informative:

➜  roc git:(jim) vr parser
    Finished dev [unoptimized + debuginfo] target(s) in 0.88s
     Running `target/debug/roc examples/benchmarks/ParseApp.roc`
error: Failed at the parser script

Here vr parser == cargo run examples/benchmarks/ParseApp.roc

view this post on Zulip Anton (Aug 11 2021 at 09:27):

I get a segmentation fault for the code with List.map, as expected there are some valgrind errors. I'll make an issue.

view this post on Zulip Anton (Aug 11 2021 at 09:40):

#1569

view this post on Zulip Folkert de Vries (Aug 11 2021 at 10:02):

taking a look. segfaults are bad

view this post on Zulip Folkert de Vries (Aug 11 2021 at 10:32):

interesting, filling a list with these p1 = {name : "test1", test: 1 } values is fine (the test field is an i64) but p1 = {name : "test1", test: 1 == 1 } is not (test field is a bool)

view this post on Zulip Folkert de Vries (Aug 11 2021 at 10:32):

likely something bad in our stack size calculation

view this post on Zulip James Carlson (Aug 11 2021 at 13:19):

What is the syntax for running cargo run examples/benchmarks/ParseApp.roc with RUST_BACKTRACE=1?

view this post on Zulip Folkert de Vries (Aug 11 2021 at 13:25):

I usually just set that variable in my current shell

view this post on Zulip Folkert de Vries (Aug 11 2021 at 13:25):

so depends on the shell you use

view this post on Zulip Anton (Aug 11 2021 at 13:39):

I usually do RUST_BACKTRACE=1 cargo run ....

view this post on Zulip James Carlson (Aug 12 2021 at 01:18):

Suppose that one has an interface exposing foo and an app importing that interface. Suppose that the app compiles. Does that mean that foo was successfully compiled? Weaker: can one assume that foo typechecks?

view this post on Zulip Richard Feldman (Aug 12 2021 at 02:35):

it should mean that foo typechecks

view this post on Zulip Richard Feldman (Aug 12 2021 at 02:35):

whenever you import an interface module, it gets fully type-checked just like whatever imported it!

view this post on Zulip James Carlson (Aug 12 2021 at 10:01):

I see that the "map over list of records" bug has been fixed. (Yay!). So one can now do things like this in ParserApp.roc to run tests

    Test.run [p1, p2, p3, p4, p5, p6, p7, p8]
      |> Task.putLine

For example:

➜  roc git:(jim) vr parser
    Finished dev [unoptimized + debuginfo] target(s) in 0.90s
     Running `target/debug/roc examples/benchmarks/ParseApp.roc`

Pass :: run "abcd any => "a"
Pass :: run "abcd" satisfy (\u -> u == 97)) => "a"
Pass :: Use 'second' to recognize "a" then "b" returning "b"
Pass :: Use 'first' to recognize "a" then "b" returning "a"
Pass :: Use map to shift output of parser: run "abcd" (map any (\u -> u + 25)) == "z"
Pass :: Use andThen to recognize strings beginning with two repeated letters (succeed on input "aaxyz")
Pass :: is successful (positive)
Pass :: is successful (negative)

runtime: 0.460ms

view this post on Zulip James Carlson (Aug 12 2021 at 10:10):

QUESTION. would it not be better if I made sister directory of benchmarks for the parser etc code?
E.g., directory parser.

The number of files is growing:

Loop.roc
Pair.roc
ParseApp.roc
Parser.roc
Test.roc
Tester.roc
Utility.roc

If I did this, would cargo run examples/parser/ParseApp.roc work properly?

view this post on Zulip James Carlson (Aug 12 2021 at 11:02):

The following line in ParserApp.roc causes a panic:

oneOfResult = (oneOf [satisfyA, satisfyB]) [97, 98, 99, 100]

Here is the definition of oneOf (in file Parser.roc):

oneOf : List (Parser a) -> Parser a
oneOf = \parserList ->
          \input -> when List.first parserList is
              Ok p ->
                output = p input
                if List.len output == 1 then output else (oneOf (List.drop parserList 1)) input
              Err _ -> [ ]

The error message with RUST_BACKTRACE=1 is rather long, but it begins like this:

     Running `target/debug/roc examples/benchmarks/ParseApp.roc`
thread 'main' panicked at 'internal error: entered unreachable code: symbol/layout combo must be in DeclarationToIndex', compiler/mono/src/borrow.rs:223:9
stack backtrace:
   0: rust_begin_unwind
             at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/panicking.rs:515:5
   1: core::panicking::panic_fmt
             at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/core/src/panicking.rs:92:14
   2: roc_mono::borrow::DeclarationToIndex::get_param_offset
             at ./compiler/mono/src/borrow.rs:223:9
   3: roc_mono::borrow::ParamMap::get_param_offset

QUESTION: is the cause of the panic my code or the compiler?

view this post on Zulip Folkert de Vries (Aug 12 2021 at 11:33):

should be possible to have a parser folder. just make sure to also copy the platform folder

view this post on Zulip Folkert de Vries (Aug 12 2021 at 11:33):

and that panic is probably caused by a type error earlier in the pipeline

view this post on Zulip James Carlson (Aug 12 2021 at 11:44):

Thanks, I'll make that folder and investigate my types

view this post on Zulip James Carlson (Aug 12 2021 at 11:50):

I've moved all my code in the jim branch to examples/parser

view this post on Zulip James Carlson (Aug 12 2021 at 12:09):

@Folkert de Vries , I'm trying to see where my code for the oneOf parser is going wrong. I asked Richard about type-checking:

James Carlson: Suppose that one has an interface exposing foo and an app importing that interface. Suppose that the app compiles. Does that mean that foo was successfully compiled? Weaker: can one assume that foo typechecks?

Richard Feldman: it should mean that foo typechecks

Richard Feldman: whenever you import an interface module, it gets fully type-checked just like whatever imported it!

So on the basis of this, I would think that the code for oneOf in examples/Parser.roc is correct .... ????

ASSUMING that is the case, then the culprit has to be

oneOfResult = (oneOf [satisfyA, satisfyB]) [97, 98, 99, 100]

Here the parser oneOf : List (Parser a) -> Parser a is applied to a list of parsers, so it returns a parser. That parser is then applied to a list of U8, which is as it should be:

Parser a : List U8 -> List ([Pair a (List U8)])

There must be an error somewhere, but I don't see it.

The files are parser/Parser.roc and parser/ParserTest.roc where

oneOf : List (Parser a) -> Parser a
oneOf = \parserList ->
          \input -> when List.first parserList is
              Ok p ->
                output = p input
                if List.len output == 1 then output else (oneOf (List.drop parserList 1)) input
              Err _ -> [ ]

view this post on Zulip Folkert de Vries (Aug 12 2021 at 14:29):

it might be that the result not being used is a problem here

view this post on Zulip Folkert de Vries (Aug 12 2021 at 14:29):

oneOfResult is dead code eliminated

view this post on Zulip Folkert de Vries (Aug 12 2021 at 14:30):

because I don't see a type error when i run the code

view this post on Zulip James Carlson (Aug 12 2021 at 16:21):

Hmm ... I ran ParserTest.roc with

p9 = {name: "test of oneOf combinator", test: List.len oneOfResult == 1}
...
...
Test.run [p1, p2, p3, p4, p5, p6, p7, p8, p9]
      |> Task.putLine

This produced a long error message. So that argues against dead-code elimination being the problem. How do we assure ourselves that both oneOf and oneOfResult type-check? I think Richard's comment takes care of the first. Is there a way of type-checking an interface or app with running the code?

view this post on Zulip James Carlson (Aug 12 2021 at 16:26):

Something interesting: I moved oneOfResult from ParserTest to Parser on the theory that this way we could verify whether oneOfResult type checks. This configuration ran without error. I'm relieved, but still puzzled.

view this post on Zulip James Carlson (Aug 12 2021 at 16:32):

Hmm ... something really weird is going on. Consider the following tests:

    p9 = {name: "test of oneOf combinator", test: List.len oneOfResult == 1}
    p10 = {name: "test (2) of oneOf combinator", test: List.len ((oneOf [satisfyA, satisfyB]) [97, 98, 99, 100]) == 1}

where

oneOfResult = (oneOf [satisfyA, satisfyB]) [97, 98, 99, 100]

Including p10 in the tests causes a crash. But this is a violation of referential transparency, since the difference between p9 and p10 is a substitution. Could there be a problem with the compiler?

view this post on Zulip Folkert de Vries (Aug 12 2021 at 16:33):

took a deeper look and there is a bug somewhere, will try to track it down

view this post on Zulip Folkert de Vries (Aug 12 2021 at 16:33):

thanks for all your testing btw!

view this post on Zulip James Carlson (Aug 12 2021 at 16:33):

Thanks Folkert, good luck!

view this post on Zulip James Carlson (Aug 12 2021 at 16:34):

Ah ... the testing is good for me also. Finding the boundary between my errors and the compiler bugs is the hard part.

view this post on Zulip Folkert de Vries (Aug 12 2021 at 16:53):

btw you can also write oneOf as

oneOf = \parserList ->
    \input ->
        List.walkUntil parserList
            (\p, accum ->
                output = p input
                if List.len output == 1 then
                    Stop output

                else
                    Continue accum
            )
            []

triggers the same problem, but it's a lot more efficient because you're not dropping items from a list one-by-one

view this post on Zulip Folkert de Vries (Aug 12 2021 at 17:30):

well I made some issues https://github.com/rtfeldman/roc/issues/1576 and https://github.com/rtfeldman/roc/issues/1575 the problem seems to be that different function types (specifically different closure, so functions that capture things) in the same list causes some problems when generating code

view this post on Zulip James Carlson (Aug 12 2021 at 19:36):

Mmm ... very nice! I will use that code. Didn't know about walkUntil, but can see it is really handy. I was going to rig up something with loop and Step as in Elm, but this is much better.

view this post on Zulip Folkert de Vries (Aug 12 2021 at 19:37):

yea this will actually exit early

view this post on Zulip James Carlson (Aug 12 2021 at 19:40):

I'm fairly close to being able to interesting things: oneOf, andThen, and map are the most important combinators. Once I get something barebones but interesting, I will go back and add some error handling. Nonexistent at present.

view this post on Zulip Richard Feldman (Aug 12 2021 at 22:03):

(FYI, I moved the above conversations from #beginners > strings and #beginners > syntax to give error messages their own topic!)

view this post on Zulip James Carlson (Aug 13 2021 at 14:50):

I have a simple testing interface that may be of some use to folks just working with roc code. Here is an example. In file examples/parser/Pair.roc, I have the following:

## TESTS

inc = \x -> x + 1
p1 = Pair 1 0

t1 = {name: "mapFirst, first", test: (Pair.mapFirst p1 inc |> Pair.first) == 2 }
t2 = {name: "mapSecond, second", test: (Pair.mapSecond p1 inc |> Pair.second) == 1 }
t3 = {name: "map2, first coordinate", test: (Pair.map2 p1 inc inc|> Pair.first) == 2 }
t4 = {name: "map2, second coordinate", test: (Pair.map2 p1 inc inc|> Pair.second) == 1 }

tests = [t1, t2, t3, t4]

Of all this, only tests is exposed. Then, in examples/parser/TestRunner.roc, there is

app "testRunner"
     packages { base: "platform" }
     imports [base.Task, Test, Pair]
     provides [ main ] to base

main : Task.Task {} []
main =

    Test.run Pair.tests
    |> Task.putLine

The command cargo run parser/TestRunner.roc, executed from examples, yields the following:

Pass :: mapFirst, first
Pass :: mapSecond, second
Pass :: map2, first coordinate
Pass :: map2, second coordinate

A feature of this approach is that (a) the tests reside in the file whose code is tested (b) the test code is very compact, as is the test runner.

view this post on Zulip Anton (Aug 13 2021 at 14:53):

Cool stuff :)

view this post on Zulip James Carlson (Aug 13 2021 at 14:53):

Thanks Anton!

view this post on Zulip Richard Feldman (Aug 13 2021 at 14:55):

wow, very nice! I have a design in mind for a roc test command, but it's a ways off from being implemented, so this is great!!!

view this post on Zulip Richard Feldman (Aug 13 2021 at 14:56):

Jim, I think you just created Roc's first-ever genuinely useful programming tool written entirely in Roc :smiley:

view this post on Zulip James Carlson (Aug 13 2021 at 14:56):

I plan to add

showFailures : List Test -> Str

but atm am blocked by

Utility.filterList : List a, (a -> Bool) -> List a

which creates panic.

view this post on Zulip James Carlson (Aug 13 2021 at 14:57):

Haha! Thanks!! It is a stopgap pending the real thing.

view this post on Zulip Richard Feldman (Aug 13 2021 at 14:57):

is there a bug report for that one? Folkert and I are planning to pair on bugfixes this weekend!

view this post on Zulip James Carlson (Aug 13 2021 at 14:58):

I will make one. I always struggle with the question: is it my code, or something else.

view this post on Zulip Richard Feldman (Aug 13 2021 at 14:59):

if it's a panic or segfault, it's definitely a compiler bug :big_smile:

view this post on Zulip Richard Feldman (Aug 13 2021 at 15:00):

well, or a platform bug - but I assume you're not making changes to the platform haha

view this post on Zulip Richard Feldman (Aug 13 2021 at 15:00):

the compiler should never panic or segfault, or generate application code that panics (in the Rust sense) or segfaults

view this post on Zulip Richard Feldman (Aug 13 2021 at 15:01):

so definitely please file issues for any of those that you see! :smiley:

view this post on Zulip James Carlson (Aug 13 2021 at 15:44):

@Richard Feldman good news (see below in the code, filterList) — it is running fine now. Will file issues going forward when I see them.

# Test of examples/parser/Utility.roc

cargo run parser/TestUtility.roc

Pass :: concatStrList ["a", "b", "c"] == "abc"
Pass :: concatStrListWithSeparator ["a", "b", "c"] "." == "a.b.c"
Pass :: isEven 4 == True
Pass :: isEven 5 == False
Pass :: filterList [1,2,3,4,5,6] isEven == [2,4,6]
Pass :: showU8 97 == "a"
Pass :: showU8Pair (Pair 97 [98, 99]) == "(a, bc)"

view this post on Zulip James Carlson (Aug 13 2021 at 17:43):

Just posted an issue, #1581, https://github.com/rtfeldman/roc/issues/1581, regarding a panic when calling function Test.failures

view this post on Zulip Folkert de Vries (Aug 13 2021 at 18:07):

huh, that's an old one

view this post on Zulip Folkert de Vries (Aug 13 2021 at 18:07):

fix should be simple there

view this post on Zulip James Carlson (Aug 13 2021 at 22:22):

What does this one mean?

thread 'main' panicked at 'There were still outstanding Arc references to module_ids', /Users/jxxcarlson/dev/roc/roc/compiler/load/src/file.rs:1576:33

view this post on Zulip Folkert de Vries (Aug 13 2021 at 22:29):

does that happen consistently?

view this post on Zulip Folkert de Vries (Aug 13 2021 at 22:30):

that one is usually a race condition somewhere

view this post on Zulip James Carlson (Aug 13 2021 at 22:41):

I know at least one way to produce it (have made an issue for this, #1574: https://github.com/rtfeldman/roc/issues/1574 -- I can't remember what produced the one above, but I will keep my eye out for such things and raise issues where I already have not.

view this post on Zulip Richard Feldman (Aug 13 2021 at 22:47):

honesty the next time you see it, if you could just share what code caused it, that would help even if it doesn't reproduce consistently - that way we can run the command in a loop until it reproduces :big_smile:

view this post on Zulip James Carlson (Aug 13 2021 at 23:29):

Will do

view this post on Zulip James Carlson (Aug 13 2021 at 23:31):

Just filed ##1583, https://github.com/rtfeldman/roc/issues/1583, re panic when trying to test the manyAux combinator.

view this post on Zulip James Carlson (Aug 13 2021 at 23:46):

Panic 1 (I'll post simple versions of these as I find them)

Interface (note the missing comma after baz)

interface Panic exposes [foo, bar, baz
  yada] imports [ ]

foo = 1
bar = 2
baz = 3
yada = 4

app:

app "test"
    packages { base: "platform" }
    imports [base.Task, Panic]
    provides [ main ] to base

main : Task.Task {} []
main =

    Str.fromInt Panic.foo |>
       Task.putLine

view this post on Zulip Richard Feldman (Aug 13 2021 at 23:53):

excellent, thanks!

view this post on Zulip James Carlson (Aug 15 2021 at 09:19):

Panic2: note the missing comma in the definition of foo. Put it back in => no Panic

app "panic"
    packages { base: "platform" }
    imports [base.Task]
    provides [ main ] to base

main : Task.Task {} []
main =

    foo = {a: 1 b: 2}


    foo.a + foo.b |>  Str.fromInt |>
       Task.putLine

view this post on Zulip Anton (Aug 15 2021 at 09:41):

@James Carlson I created #1589 for this, thanks for the find :)

view this post on Zulip James Carlson (Aug 15 2021 at 12:33):

A new version of the Test interface in examples/parser of the jim branch.

The code

[t1,t2,t3] |> Test.run "Test of test interface"  |> Task.putLine

produces this:

Test of test interface
----------------------
Pass :: isEven
Pass :: filterList
Fail :: Bozo

where for example

    filteredList = Utility.filterList [1,2,3,4,5,6] Utility.isEven
    t2 = {name : "filterList", test: List.len filteredList == 3}

view this post on Zulip James Carlson (Aug 15 2021 at 12:35):

There is also a way to show failures only:

Test of test interface, failures only
-------------------------------------
Fail :: Bozo

using

t1,t2,t3] |> Test.runF "Test of test interface, failures only"  |> Task.putLine

view this post on Zulip Anton (Aug 15 2021 at 12:56):

Feel free to create a PR to add this test framework to trunk! Perhaps a folder named testframework under examples?

view this post on Zulip James Carlson (Aug 15 2021 at 12:59):

Will do!

view this post on Zulip James Carlson (Aug 15 2021 at 13:01):

Ridiculous code below, but it does cause panic:

app "panic"
    packages { base: "platform" }
    imports [base.Task]
    provides [ main ] to base

main : Task.Task {} []
main =

    q1 = "a"
    q2 = "b"
    foo = [q1, q2, 3]  # <== Oops, typo!

    List.len foo |>  Str.fromInt |>
       Task.putLine

view this post on Zulip Folkert de Vries (Aug 15 2021 at 13:02):

sorry what is the typo?

view this post on Zulip Folkert de Vries (Aug 15 2021 at 13:03):

"3" instead of "q3"?

view this post on Zulip James Carlson (Aug 15 2021 at 13:03):

Yes

view this post on Zulip James Carlson (Aug 15 2021 at 13:05):

@Anton , the test code depends on several functions in parser/Utility.roc. For the PR, shall I incorporate those functions in the code for testing?

view this post on Zulip James Carlson (Aug 15 2021 at 13:07):

Utility.concatStrListWithSeparator, Utility.strRepeat, Utility.concatStrList, Utility.filterList

view this post on Zulip Anton (Aug 15 2021 at 13:07):

Yeah sure, sounds good!

view this post on Zulip James Carlson (Aug 15 2021 at 13:35):

PR request #1590: https://github.com/rtfeldman/roc/pull/1590 --- adds Test.roc , a bare-bones testing "framework"

view this post on Zulip James Carlson (Aug 15 2021 at 23:54):

Did I see a remark on being able to write code with holes -- so that the type checker can help out the poor struggling programmer? That would be truly awesome! (or a dream!!)

view this post on Zulip Richard Feldman (Aug 16 2021 at 00:03):

indeed! :big_smile:

view this post on Zulip James Carlson (Aug 16 2021 at 05:56):

QUESTION: I have the types

Step state a : [ Loop state, Done a ]
Parser a : List U8 -> List [Pair a (List U8)]

Now consider Parser (Step state a). I get the error message below in code like this:

loop : (state -> Parser (Step state a)), state -> Parser a
loop = \nextState, s ->
  \input ->
      ps =  (nextState s)                 # Parser (Step state a))
      when ps is
          Parser (Loop s2) ->
            ...

          Parser (Done aa) ->
       ...

ERROR MESSAGE

The 1st pattern in this when is causing a mismatch:

85│            Parser (Loop s2) ->
               ^^^^^^^^^^^^^^^

The first pattern is trying to matchParser values of type:

    [ Parser [ Loop a ]b ]c

But the expression between when and is has the type:

    List U8 -> List [ Pair (Step state a) (List U8) ]

But I would argue that

(1)   List U8 -> List [ Pair (Step state a) (List U8) ] == Parser (Step state a)

and that

(2) Parser (Loop s2).

is one of the two variants of type Step state a so that there is no type error in this code. I must be missing something, but I don't see what it is.

view this post on Zulip Anton (Aug 16 2021 at 09:16):

Hmm that does look like it should work

view this post on Zulip Anton (Aug 16 2021 at 09:18):

@James Carlson can you try simplifying the types further and check if the error still occurs?

view this post on Zulip Folkert de Vries (Aug 16 2021 at 10:28):

in your case Parser is just a type alias, not a tag union

view this post on Zulip Folkert de Vries (Aug 16 2021 at 10:29):

so you can remove the Parser in Parser (Loop s2)

view this post on Zulip James Carlson (Aug 17 2021 at 12:24):

I am trying to port Richard's console package (Elm) to roc. But I get this:

3│  greenColor : Str
4│  greenColor = Str.fromUtf8 [27, 91, 51, 50, 109]
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This fromUtf8 call produces:

    Result Str [ BadUtf8 Utf8ByteProblem Nat ]b

view this post on Zulip James Carlson (Aug 17 2021 at 12:33):

The idea is to imitate code like this:

green : String -> String
green str =
    String.join "" [ "\u{001B}[32m", str, "\u{001B}[39m" ]

where greenColor replaces "\u{001B}[32m" and I say

green : Str -> Str
green = \str ->
    Utility.concatStrList [ greenColor, str, clearColor ]

view this post on Zulip Folkert de Vries (Aug 17 2021 at 12:36):

well turning raw bytes into utf8 is an operation that can fail

view this post on Zulip Folkert de Vries (Aug 17 2021 at 12:37):

in this case you can probably do |> Result.withDefault ""

view this post on Zulip James Carlson (Aug 17 2021 at 12:50):

Ah yes, thanks!

view this post on Zulip James Carlson (Aug 17 2021 at 14:11):

Demo of interface Console in branch jim, folder examples/parser:

image.png

Run with

app "foo"
    packages { base: "platform" }
    imports [base.Task,  Console, StrExtra]
    provides [ main ] to base


main : Task.Task {} []
main =
  StrExtra.concat [
       Console.bgCyan (Console.black "This is a test:"),
       Console.green " The grass is green, but ",
       Console.red "roses are red."
    ] |> Task.putLine

view this post on Zulip Folkert de Vries (Aug 17 2021 at 14:12):

oh, very fancy

view this post on Zulip James Carlson (Aug 17 2021 at 14:13):

Just Richard's Elm library ported to Richard's language :big_smile:

view this post on Zulip James Carlson (Aug 17 2021 at 14:15):

Followed his API word-for-word

view this post on Zulip Folkert de Vries (Aug 17 2021 at 14:18):

but we can actually print to the console :smile:

view this post on Zulip Lucas Rosa (Aug 17 2021 at 15:43):

that's very cool

view this post on Zulip Richard Feldman (Aug 17 2021 at 16:48):

that's awesome! :heart_eyes_cat:

view this post on Zulip Richard Feldman (Aug 17 2021 at 16:48):

incidentally, in Roc you can do "\u(001B)[32m" for unicode escapes (the \u(...) is equivalent to \u{...} in Elm)

view this post on Zulip James Carlson (Aug 18 2021 at 00:48):

That's good to know ("\u(001B)[32m"). Meanwhile, just for fun:

image.png

view this post on Zulip Richard Feldman (Aug 18 2021 at 01:00):

so cool!!!

view this post on Zulip Richard Feldman (Aug 18 2021 at 01:00):

also that's a nice sub-millisecond runtime on that test suite :joy:

view this post on Zulip James Carlson (Aug 18 2021 at 22:55):

Sub-millisecond is soooo good!

view this post on Zulip James Carlson (Aug 19 2021 at 13:36):

The many combinator,

many : Parser a -> Parser (List a)

now type-checks, as does a test for it:

q3 = {name: "many lowerCase", test: Parser.run [97, 99, 100, 0] (many lowerCase) == [Pair [97, 98, 99] [0]] }

I'll be able to run this test (and the one for oneOf) as soon as some panic issues are resolved.

view this post on Zulip Folkert de Vries (Aug 19 2021 at 13:50):

you are up to date with latest trunk? if yes, can you get the panic down to just a single file, then put the source of that file in an issue?

view this post on Zulip James Carlson (Aug 19 2021 at 14:11):

Interesting! I had pulled trunk earlier this morning, IIRC. But now there are changes. I first ran the old tests:

image.png

Looks like andThen (used by first and second needs some attention. Then I ran the tests for oneOf and many individually. They created panics.

The "missing-comma-in-exposes-list" error still causes a panic.

I will make a distilled one-file version of the 'oneOf' panic and also of the 'many' panic.

view this post on Zulip James Carlson (Aug 19 2021 at 14:12):

Interesting that andThen now fails when it didn't before. I'll make a one-file version of this also.

view this post on Zulip James Carlson (Aug 19 2021 at 14:13):

((If I can't easily fix it))

view this post on Zulip James Carlson (Aug 19 2021 at 14:49):

Hmmm, having trouble composing even the simplest file today. The below panics, but I can't see why.

app "oneOfPanic"
     packages { base: "platform" }
     imports [base.Task]
     provides [ main ] to base

main : Task.Task {} []
main =
   "hello" |> Task.putline

view this post on Zulip Anton (Aug 20 2021 at 08:45):

putline should be putLine

view this post on Zulip James Carlson (Aug 20 2021 at 09:07):

My goodness! I need better glasses and more sleep!! Thanks.

view this post on Zulip James Carlson (Aug 20 2021 at 15:39):

Got this error a moment ago after pulling trunk and merging into jim:

➜  examples git:(jim) ✗ cargo run parser/ParserTest.roc
    Finished dev [unoptimized + debuginfo] target(s) in 0.66s
     Running `/Users/jxxcarlson/dev/roc/roc/target/debug/roc parser/ParserTest.roc`
Undefined symbols for architecture x86_64:
  "_roc_panic", referenced from:
      l_Num_add_3fc76dac52173e2f6971f0328553dc78618dec1a96b6375eceeb2fe9a98a3a0 in roc_app0elG65.o
ld: symbol(s) not found for architecture x86_64

view this post on Zulip Folkert de Vries (Aug 20 2021 at 20:58):

I fixed a common cause of the "symbol/layout {:?} {:?} combo must be in DeclarationToIndex" style error here https://github.com/rtfeldman/roc/pull/1609

view this post on Zulip Richard Feldman (Aug 20 2021 at 21:45):

@James Carlson the roc_panic error is because we just added a new requirement for hosts to expose a function with that name

view this post on Zulip Richard Feldman (Aug 20 2021 at 21:51):

if your platform is using Rust, here's what you'd need to add to its lib.rs:

https://github.com/rtfeldman/roc/blob/19d56fa7d4ec256b7e8fff28f3af50f6017d62e6/examples/hello-rust/platform/src/lib.rs#L34

view this post on Zulip Richard Feldman (Aug 20 2021 at 21:51):

#[no_mangle]
pub unsafe fn roc_panic(c_ptr: *mut c_void, tag_id: u32) {
    match tag_id {
        0 => {
            let slice = CStr::from_ptr(c_ptr as *const c_char);
            let string = slice.to_str().unwrap();
            eprintln!("Roc hit a panic: {}", string);
            std::process::exit(1);
        }
        _ => todo!(),
    }
}

view this post on Zulip Richard Feldman (Aug 20 2021 at 21:53):

lmk if that works!

view this post on Zulip James Carlson (Aug 21 2021 at 04:09):

Looks like my platform is zig-based:

➜  examples git:(jim) ✗ ls parser/platform
Package-Config.roc Task.roc           host.o             host.zig           zig-cache

Should I be using something different?

view this post on Zulip James Carlson (Aug 21 2021 at 04:32):

I found that there is rust-based platform in examples/hello-rust I moved the zig-based in parser to another name, moved a copy of the rust-based platform in to parser, and ran cargo run parser/ParserTest.roc. This resulted in the error message

I am looking for this file, but it's not there:

    /Users/jxxcarlson/dev/roc/roc/examples/parser/platform/Task.roc

Is the file supposed to be there? Maybe there is a typo in the file
name?%

I made a copy of the Task.roc file in the rust platform and moved it to the root of my platform. More errors alas. I'm afraid that my home-made solution will not work. (Oh, lib.rs in the copied code already had the #[no_mangle] you cite above.

view this post on Zulip Richard Feldman (Aug 21 2021 at 13:31):

ah! so for a Zig host, here's the equivalent code to add to host.zig:

export fn roc_panic(c_ptr: *c_void, tag_id: u32) callconv(.C) void {
    const stderr = std.io.getStdErr().writer();
    const msg = @ptrCast([*:0]const u8, c_ptr);
    stderr.print("Application crashed with message\n\n    {s}\n\nShutting down\n", .{msg}) catch unreachable;
    std.process.exit(0);
}

view this post on Zulip James Carlson (Aug 21 2021 at 21:00):

Hi @Richard Feldman , I got a little further this time, getting a different error message:

     Running `/Users/jxxcarlson/dev/roc/roc/target/debug/roc parser/ParserTest.roc`
Undefined symbols for architecture x86_64:
  "_roc_fx_putLine", referenced from:
      l_Effect_effect_closure_putLine_76152341861df334f796e7048579cd151e7d5d5ce546b36a28afd44760b25b in roc_appTryVVG.o
ld: symbol(s) not found for architecture x86_64

(I put your zig code at then end of host.zig and the compiler seemed to like that)

view this post on Zulip James Carlson (Aug 22 2021 at 06:05):

@Richard Feldman Never mind -- all running just fine now. Thankyou!

view this post on Zulip Richard Feldman (Aug 22 2021 at 12:11):

sweet, glad it's working!

view this post on Zulip James Carlson (Aug 22 2021 at 19:48):

Some Really Weird Stuff:

I've been pulling my hair out because parser code that previously passed tests no longer does. I've tried rebuilding the parser code in interface Parser2.roc, adding a few lines of code and testing it as I go. The next two images show the nature of the problem. In the first, Parser.map passes its test. In the second, I add Parser.andThen. The two functions share no parser code directly or indirectly. By adding the andThen test, the map test now fails! This should not happen. Alas, I have no idea of where to begin.

Screen-Shot-2021-08-22-at-3.42.07-PM.png

Screen-Shot-2021-08-22-at-3.42.28-PM.png

view this post on Zulip James Carlson (Aug 22 2021 at 19:50):

Here is the code for the two functions in question:

## MAP

map : Parser a, (a -> b) -> Parser b
map =
  \p, f -> \input -> p input |> List.map (\pair -> Pair.mapFirst pair f)


## AND_THEN, FIRST, SECOND

andThen : Parser a, (a -> Parser b) -> Parser b
andThen = \p, q ->
            \input -> p input |> List.map (\(Pair a input2) -> (q a) input2) |> List.join

view this post on Zulip Folkert de Vries (Aug 22 2021 at 19:50):

can you get some sort of error message out of the failing parser?

view this post on Zulip James Carlson (Aug 22 2021 at 19:51):

And here is the test code:

mapT = {name : "Use map to shift output of parser: run \"abcd\" (map any (\\u -> u + 25)) == \"z\"", test : runU8 "abcd" (map any (\u -> u + 25)) == "z"  }

andThenT = { name: "andThen", test: runToString Utility.showU8 "aaxyz" (andThen any satisfyWhatCameBefore) == "a"}

satisfyWhatCameBefore = \u2 -> satisfy (\u3 -> u3 == u2)

view this post on Zulip James Carlson (Aug 22 2021 at 19:54):

I'll see what I can do. But I can't understand why adding one test causes the other to fail.

view this post on Zulip Folkert de Vries (Aug 22 2021 at 19:54):

no that sounds like a bug

view this post on Zulip Folkert de Vries (Aug 22 2021 at 19:55):

but knowing what the code thinks went wrong could be helpful tracking the problem down

view this post on Zulip James Carlson (Aug 22 2021 at 19:55):

I'll work on it now. I can probably get something out.

view this post on Zulip Folkert de Vries (Aug 22 2021 at 19:58):

alternatively if you can get it into one file I can take a look

view this post on Zulip James Carlson (Aug 22 2021 at 20:20):

Interesting. I had to change

runU8 : Str, Parser a-> Str
runU8 = \input, parser -> runToString Utility.showU8 input parser

to

runU8 : Str, Parser U8 -> Str

Now andThen always fails in this test suite, though it succeeds in a one-file version that tests only andThen. We are about to leave for a dinner, so I have to stop now. I'll work on this a bit more tomorrow, maybe in the evening, and send you something.

Thankyou Folkert!

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

interesting. We have a couple more fixes in the works, so maybe things will also just work when those are merged

view this post on Zulip Brian Hicks (Aug 27 2021 at 11:40):

(deleted)

view this post on Zulip James Carlson (Sep 11 2021 at 16:41):

Hi @Folkert de Vries , finally have some time to get back to roc (yay!). Here is my current problem. As you can see from the image below, the result of running my parser tests depends on their order. Since we are running pure functions, this shouldn't happen, no? I'm baffled.

Screen-Shot-2021-09-11-at-12.35.02-PM.png

view this post on Zulip James Carlson (Sep 11 2021 at 16:42):

Test (6) passes in one test and fails in the other.

view this post on Zulip James Carlson (Sep 11 2021 at 16:47):

Is it possible to import modules in the repl?

view this post on Zulip Richard Feldman (Sep 11 2021 at 21:45):

@James Carlson welcome back, Jim! :smiley:

it's not possible to import modules in the repl yet...I looked into it, and there are a few prerequisites that will take a bit. I thought it might be a weekend project, but seems like more than that. :big_smile:

view this post on Zulip Richard Feldman (Sep 11 2021 at 21:45):

is the code to reproduce the order-dependent tests pushed somewhere we can take a look at it?

view this post on Zulip James Carlson (Sep 12 2021 at 17:56):

Hi @Richard Feldman , yes, glad to be back! My contract with Brilliant.org ends next Friday, so I will soon have more time for roc and other projects. (But Brilliant has been a really good experience — accomplished a lot, learned a lot, and worked with some really great people.)

In the jim branch, file ParserTest.roc of examples/parser, you will find some code re the weirdness that I mentioned. Begin by cd'ing to examples, then run the below (ignoring warnings)

cargo run parser/ParserTest.roc

You will see three test successes. Next, look at the end of the file, where you will see this:

Test.runSuites [suite3]         # tests a, b, c,
# Test.runSuites [suite4]      # tests a, b, c, d
# Test.runSuites [suite5]      # tests a, b, c, d, e
# Test.runSuites [suite6]      # tests a, b, c, d, e, f
   |> Task.putLine

Now comment out the test [suite3] and uncomment the test [suite 4]. You will find that test (b), which formerly succeeded, now fails. Why? No idea. All we did was add test (d). The saga continues. With [suite5], (d) fails and the others succeed. With [suite ], (c) and (d) fail.

PS. I modified the code in examples/parser/Test.roc so as to be able to run "suites" of tests (just a named list of tests) and, more usefully, lists of suites.

Seems like a compiler bug to me, but who knows. I have an uncanny ability to write code with all sorts of bugs.

view this post on Zulip Richard Feldman (Sep 12 2021 at 18:13):

gotcha! Yeah this actually looks like a compiler bug @Folkert de Vries and I were looking into this morning...if so, there's a fix in progress!

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

@James Carlson Brilliant is brilliant!
May I ask what were you working there? :)

view this post on Zulip James Carlson (Sep 12 2021 at 22:06):

I was working on their Camperdown Parser ( https://gallant-einstein-0694e1.netlify.app/ ) including open-sourcing a somewhat simplified version of it, developing a pretty-printer for Camperdown documents and various tests for them to make sure that the pretty-printer doesn't change the source text semantics. The pretty-printer runs the parser on a document, then re-renders it in somewhat transformed form from the AST.

A dialect of Camperdown is an in-house markup language they use for their courses.

It was really interesting work. I loved it. (All Elm)

view this post on Zulip James Carlson (Sep 12 2021 at 22:07):

I did part of one of Brilliant's courses on quantum mechanics before signing up. It was very high quality, judging from what I remember of my physics courses. Not the usual stuff one finds in ed-tech.

view this post on Zulip James Carlson (Sep 12 2021 at 22:21):

@Zeljko Nesic what is your connection with Brilliant? Did you do any of their courses?

view this post on Zulip Zeljko Nesic (Sep 13 2021 at 13:30):

I play with it with a 3-yo son from time to time, as a part of "better screen time" initiative that am enforcing on my self. They and Duolingo are my go-to places to have nerdy-fun with a kid :)

I couldn't but to feel that there is something like Camperdown behind all those interactive cources and examples. It would be pain in the neck to maintain them by JS hand.

view this post on Zulip James Carlson (Sep 13 2021 at 14:39):

Good for you and your son ! :tada:

view this post on Zulip Richard Feldman (Sep 13 2021 at 23:50):

@James Carlson The "order matters but it shouldn't" problem should be fixed on trunk now - see if you can still reproduce it!

view this post on Zulip James Carlson (Sep 14 2021 at 05:52):

@Richard Feldman It is fixed!! Fantastic!

view this post on Zulip James Carlson (Sep 14 2021 at 06:57):

parser code situation MUCH improved (thanks all!). However, I'm blocked with a misbehavingoneOf combinator. Please see the file attached below. There are also directions for producing a truly wild panic!

# FILE: OneOfTest.roc

# My latest travails with parser code (though the situation is now MUCH better.  Thanks all!)
# See the remarks just before the tests.
# This file is self-contained.

app "app"
     packages { base: "platform" }
     imports [base.Task]
     provides [ main ] to base



## PARSER

Parser a : List U8 -> List [Pair a (List U8)]


## ANY

# If succcessful, the any parser consumes one character

any: Parser U8
any = \inp ->
   when List.first inp is
     Ok u -> [Pair u (List.drop inp 1)]
     _ -> [ ]



## SATISFY

satisfy : (U8 -> Bool) -> Parser U8
satisfy = \predicate ->
    \input -> when List.first (any input) is
        Ok (Pair u rest) ->  if predicate u then List.single (Pair u rest) else []
        _ -> [ ]


oneOf : List (Parser a) -> Parser a
oneOf = \parserList ->
          \input -> when List.first parserList is
              Ok p ->
                output = p input
                if List.len output == 1 then output else (oneOf (List.drop parserList 1)) input
              Err _ -> [ ]


satisfyA = satisfy (\u -> u == 97) # recognize 97
satisfyB = satisfy (\u -> u == 98) # recognize 98


# In all the below, the given parser supposedly recognize sequence beginning with 97 or 98
# The return value of a parser in this case has type 'List [Pair U8 (List U8)]'
# Thus parse results can be empty (failure), of length 1 (succes), or of length
# greater than 1 (multi-valued, failure).  The parse result is the first element of Pair
#
# In theory, all of the below should succeed, but tests 2 and 3 fail.
# Maybe it is my code ?? Or maybe the compiler.  Dunno.  The code for the
# oneOf combinator is pretty straightforward.

# For a fascinating panic and error message, replace (for example) 'satisfyB' by 'any'

test1 = if List.len ((oneOf [satisfyA, satisfyB]) [97, 98, 99, 100] ) == 1  then "PASS" else "FAIL"
test2 = if List.len ((oneOf [satisfyA, satisfyB]) [98, 99, 100, 97] ) == 1  then "PASS" else "FAIL"
test3 = if List.len ((oneOf [satisfyB , satisfyA]) [98, 99, 100, 97] ) == 1  then "PASS" else "FAIL"
test4 = if List.len ((oneOf [satisfyA, satisfyB]) [99, 100, 101] ) == 0  then "PASS" else "FAIL"


main : Task.Task {} []
main =
  [test1, test2, test3, test4] |> Str.joinWith ", "
   |> Task.putLine

view this post on Zulip James Carlson (Sep 14 2021 at 15:28):

Screen-Shot-2021-09-14-at-11.28.09-AM.png

view this post on Zulip James Carlson (Sep 14 2021 at 15:30):

The above image is the panic message generated by running the file above (OneOfTest.roc) with any in place of satisfyB in test3. I've tested all of the functions in another file using my test framework. There is one failure (not with any) and there are no panics.

view this post on Zulip Folkert de Vries (Sep 14 2021 at 15:37):

this is likely the case because some fold or map function is used internally. I'll have a fix tonight

view this post on Zulip James Carlson (Sep 14 2021 at 16:46):

Thanks Folkert!

view this post on Zulip Folkert de Vries (Sep 14 2021 at 22:16):

it's something different. The code mixes "normal" functions with closures, in ways what we just don't handle currently. So this'll be a very interesting test case (thanks!) but now I have to figure out how to solve this properly

view this post on Zulip James Carlson (Sep 15 2021 at 04:49):

Thanks Folkert, you folks are doing an amazing job!

view this post on Zulip Folkert de Vries (Sep 17 2021 at 21:00):

this https://github.com/rtfeldman/roc/pull/1706 will make it run with any, but the ordering problem is still there, I'll look at that next

view this post on Zulip Folkert de Vries (Sep 17 2021 at 23:12):

the full thing should now run with that PR

view this post on Zulip James Carlson (Sep 18 2021 at 03:56):

@Richard Feldman , @Folkert de Vries after pulling and merging the latest changes to trunk, all of the tests to my various parser combinators pass. Hooray! :tada: :tada: :tada: — time now to push forward on this project.

view this post on Zulip James Carlson (Sep 18 2021 at 04:55):

@Richard Feldman , @Folkert de Vries, another panic found (part of new combinator). See attached, self-contained code (problem is with manyAux near very end.)

# File: ManyTest.roc
#
# The saga continues! Try `cargo run` on `ManyTest.roc` from a place in which
# you have a suitable platform.  You will get the following panic message, where the line
# beginning with "thread" extends far to the right.
#
# ➜  examples git:(jim-parser) ✗ cargo run parser/ManyTest.roc
#    Finished dev [unoptimized + debuginfo] target(s) in 1.01s
#     Running `/Users/jxxcarlson/dev/roc/roc/target/debug/roc parser/ManyTest.roc`
# thread 'main' panicked at 'internal error: entered unreachable code: symbol/layout `#UserApp.0` ProcLayout { arguments: [Builtin(List(Builtin(Int8))), LambdaSet(LambdaSet { set: [(`#UserApp.0`, [Union(NonRecursive([[Builtin(List(Builtin(Int8)))], [Builtin(List(Builtin(Int8)))]]))]), (`#UserApp.6`, [LambdaSet(LambdaSet { set: [(`#UserApp.3`, [LambdaSet(LambdaSet { set: [(`#UserApp.isLowerCaseAlpha`, [])], representation: Struct([]) })])], representation: Struct([LambdaSet(LambdaSet { set: [(`#UserApp.isLowerCaseAlpha`, [])], representation: Struct([]) })]) }), LambdaSet(LambdaSet { set: [(`#UserApp.10`, [Builtin(List(Builtin(Int8)))])], representation: Struct([Builtin(List(Builtin(Int8)))]) })])], representation: Union(NonRecursive([[Union(NonRecursive([[Builtin(List(Builtin(Int8)))], [Builtin(List(Builtin(Int8)))]]))], [LambdaSet(LambdaSet { set: [(`#UserApp.10`, [Builtin(List(Builtin(Int8)))])], representation: Struct([Builtin(List(Builtin(Int8)))]) }), LambdaSet(LambdaSet { set: [(`#UserApp.3`, [LambdaSet(LambdaSet { set: [(`#UserApp.isLowerCaseAlpha`, [])], representation: Struct([]) })])], representation: Struct([LambdaSet(LambdaSet { set: [(`#UserApp.isLowerCaseAlpha`, [])], representation: Struct([]) })]) })]])) })], result: Builtin(List(Struct([Union(NonRecursive([[Builtin(List(Builtin(Int8)))], [Builtin(List(Builtin(Int8)))]])), Builtin(List(Builtin(Int8)))]))) } combo must be in DeclarationToIndex', compiler/mono/src/borrow.rs:227:9
# : run with `RUST_BACKTRACE=1` environment variable to display a backtrace
#
# Sorry for the length of this file but there are quite a few prerequisites for the definition of the `manyAux` function.
# All the functions up the "## MANY" section have passed their tests (which now seem reliable).  Therefore the
# code causing the panic is almost certainly in function `manyAux`.
#


app "app"
     packages { base: "platform" }
     imports [base.Task]
     provides [ main ] to base



## PARSER

Parser a : List U8 -> List [Pair a (List U8)]


## SUCCEED

# succeed: succeed without consuming input
succeed : a -> Parser a
succeed = \v -> (\inp -> [Pair v inp])


## ANY

# If succcessful, the any parser consumes one character

any: Parser U8
any = \inp ->
   when List.first inp is
     Ok u -> [Pair u (List.drop inp 1)]
     _ -> [ ]



## SATISFY

satisfy : (U8 -> Bool) -> Parser U8
satisfy = \predicate ->
    \input -> when List.first (any input) is
        Ok (Pair u rest) ->  if predicate u then List.single (Pair u rest) else []
        _ -> [ ]


## ONE_OF

oneOf : List (Parser a) -> Parser a
oneOf = \parserList ->
          \input -> when List.first parserList is
              Ok p ->
                output = p input
                if List.len output == 1 then output else (oneOf (List.drop parserList 1)) input
              Err _ -> [ ]


## AND_THEN

andThen : Parser a, (a -> Parser b) -> Parser b
andThen = \p, q ->
            \input -> p input |> List.map (\(Pair a input2) -> (q a) input2) |> List.join


## MANY


Step state a : [ Loop state, Done a ]


manyAux : Parser a, List a -> Parser (Step (List a) (List a))
manyAux = \p, list ->
    \input -> (if input == []
              then
                succeed (Done (List.reverse list))
              else
                p1 = andThen p ( \a -> succeed (Loop (List.prepend list a)))
                p2 = succeed (Done (List.reverse list))
                (oneOf [ p1, p2 ])) input


## TEST

isLowerCaseAlpha : U8 -> Bool
isLowerCaseAlpha = \u -> u >= 97 && u <= 122
lowerCase = satisfy isLowerCaseAlpha

dummyTest = 1 + 1 == 2
manyAuxTest =  (manyAux lowerCase [ ]) [97,98,99] == [Pair (Loop [97]) [98,99]]

runTest = \t -> if t then "PASS" else "FAIL"

main : Task.Task {} []
main =
  runTest manyAuxTest
   |> Task.putLine

view this post on Zulip Luiz de Oliveira (Sep 18 2021 at 12:16):

Ahm, I'm getting these errors on going to the project's directory and when trying to run nix-shell. I tried to look into GLIBC but didn't find a way to fix it yet.

image.png

view this post on Zulip Anton (Sep 18 2021 at 12:24):

Hi @Luiz de Oliveira , can you tell me what OS you are using?

view this post on Zulip Luiz de Oliveira (Sep 18 2021 at 12:28):

Anton said:

Hi Luiz de Oliveira , can you tell me what OS you are using?

Oh of course, I'm in popOS 20.04 (so pretty much ubuntu 20.04).

view this post on Zulip Anton (Sep 18 2021 at 12:34):

:+1: thanks, can you also give me your nix version (nix --version)?

view this post on Zulip Luiz de Oliveira (Sep 18 2021 at 12:50):

nix version: 2.3.15

view this post on Zulip Anton (Sep 18 2021 at 13:19):

I will give that a try myself and will let you know once I find a fix!

view this post on Zulip Anton (Sep 18 2021 at 15:02):

@Luiz de Oliveira I tried many different revisions of nixos-unstable but could not get any to work. I recommend that you install without nix as explained in BUILDING_FROM_SOURCE.

view this post on Zulip Richard Feldman (Sep 18 2021 at 15:19):

@Ju Liu any ideas? :sweat_smile:

view this post on Zulip Luiz de Oliveira (Sep 18 2021 at 16:15):

Oh I have it installed, but it seems I can't run the editor without nix? But I can run some examples, but not all. I have something wrong regarding zig image.png

view this post on Zulip Anton (Sep 18 2021 at 16:20):

You should be able to run the editor without nix using cargo run edit from the root of the repo. For examples you should also start from the root of the repo, so then it is cargo run examples/hello-zig/Hello.roc.

view this post on Zulip Anton (Sep 18 2021 at 16:23):

I'll make note to improve the cannot find str.zig error message.

view this post on Zulip Luiz de Oliveira (Sep 18 2021 at 16:26):

I get a quick black window that crashes and vanishes and this error message:

image.png

Somehow I'm breaking a lot of stuff idk.

view this post on Zulip Luiz de Oliveira (Sep 18 2021 at 16:27):

I thought this was due to nix, but if it should run without it then it's something else. I can't really understand this error message =(

view this post on Zulip Anton (Sep 18 2021 at 16:40):

Sorry about this, we'll make sure to try to improve the "building from source" experience in the future.
I've never seen this error message for the editor before.. btw in its current state the editor still has very limited functionality, so for now you are better off using your regular favorite editor.

view this post on Zulip Richard Feldman (Sep 18 2021 at 17:01):

wow, yeah that error is coming from the lower-level graphics library we're using

view this post on Zulip Richard Feldman (Sep 18 2021 at 17:03):

https://hg.mozilla.org/releases/mozilla-release/rev/73891d5902058892b221f10ea1ba7f6bbc8b2c4f#l106.32

view this post on Zulip Luiz de Oliveira (Sep 18 2021 at 19:19):

This is the backtrace in case it's useful:

image.png

Looks like the last line of code ran before getting into the lib is this call: image.png

view this post on Zulip Luiz de Oliveira (Sep 18 2021 at 19:26):

I changed this line from let instance = wgpu::Instance::new(wgpu::BackendBit::all()); to let instance = wgpu::Instance::new(wgpu::BackendBit::VULKAN); and it runs!
image.png

image.png

I have no clue what that means hahahaha, just found someone with the same problem here https://github.com/gfx-rs/wgpu/issues/1492. I wonder if I'm forcing Vulkan where it should work for other graphics libs too.

view this post on Zulip Richard Feldman (Sep 18 2021 at 19:33):

yeah Vulkan is the one on Linux, but macOS wants to use Metal - but maybe we can give it hints about preferences, or like if all fails fall back on trying Vulkan? :thinking:

view this post on Zulip Richard Feldman (Sep 18 2021 at 19:34):

but congrats on getting it working, and this is a good clue towards finding a fix we could merge without breaking others - thanks so much for investigating it @Luiz de Oliveira! :tada:

view this post on Zulip Luiz de Oliveira (Sep 18 2021 at 19:45):

Say we want to fall back to Vulkan (or maybe have a list of libs to try if all fails) we could use something like the ? operator inside a closure, log the error and then try Vulkan (or the next item in a list)? Also, it seems like they have worked on it already https://github.com/gfx-rs/wgpu/pull/1656 but I don't know if it is released (I'm guessing it isn't) or when it will be.

view this post on Zulip Luiz de Oliveira (Sep 18 2021 at 19:55):

Well, I'll learn more rust hahaha idk how to do it yet.

view this post on Zulip Anton (Sep 19 2021 at 08:28):

I think the fix PR is in wgpu 10, we're currently using 9. I added upgrading to my TODO list. Thanks for the investigation @Luiz de Oliveira !

view this post on Zulip Anton (Sep 21 2021 at 11:09):

@Luiz de Oliveira can you try running the editor on the wgpu-10 branch to check if the upgrade fixes your issue?

view this post on Zulip Anton (Sep 21 2021 at 11:24):

I have also improved the zig str error message and added a warning to the nix section of our BUILDING_FROM_SOURCE.md

view this post on Zulip James Carlson (Sep 21 2021 at 19:04):

Hmmm just got the error below ... this code has been running fine for the last week or so and has had no changes for that time period.

    [1]    39948 segmentation fault  cargo run parser/ParserTest.roc

view this post on Zulip Folkert de Vries (Sep 21 2021 at 19:09):

is it consistent?

view this post on Zulip James Carlson (Sep 22 2021 at 12:17):

Not consistent in the sense that today I merged with the latest commit of trunk but got a different error message (panic instead of segmentation fault):

   Finished dev [unoptimized + debuginfo] target(s) in 26.24s
     Running `/Users/jxxcarlson/dev/roc/roc/target/debug/roc parser/ParserTest.roc`
thread 'main' panicked at 'internal error: entered unreachable code: symbol/layout `fx.Effect.map` ProcLayout { arguments: [LambdaSet(LambdaSet { set: [(`fx.Effect.effect_closure_putLine`, [Builtin(Str)])], representation: Struct([Builtin(Str)]) }), LambdaSet(LambdaSet { set: [(`base.Task.6`, [])], representation: Struct([]) })], result: LambdaSet(LambdaSet { set: [(`fx.Effect.effect_map_inner`, [LambdaSet(LambdaSet { set: [(`fx.Effect.effect_closure_putLine`, [Builtin(Str)])], representation: Struct([Builtin(Str)]) }), LambdaSet(LambdaSet { set: [(`base.Task.6`, [])], representation: Struct([]) })])], representation: Struct([LambdaSet(LambdaSet { set: [(`fx.Effect.effect_closure_putLine`, [Builtin(Str)])], representation: Struct([Builtin(Str)]) }), LambdaSet(LambdaSet { set: [(`base.Task.6`, [])], representation: Struct([]) })]) }) } combo must be in DeclarationToIndex', compiler/mono/src/borrow.rs:227:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

view this post on Zulip Richard Feldman (Sep 22 2021 at 12:19):

it doesn't explain :point_up: but one thing that'll need to change is not using RocCallResult anymore

view this post on Zulip Richard Feldman (Sep 22 2021 at 12:19):

@James Carlson is the branch that reproduces this pushed somewhere?

view this post on Zulip James Carlson (Sep 22 2021 at 12:19):

Yes, it is jim-parser

view this post on Zulip James Carlson (Sep 22 2021 at 12:20):

Just pushed the branch with the latest merge of trunk

view this post on Zulip James Carlson (Sep 22 2021 at 12:21):

I am doing cargo run ... from ./examples

view this post on Zulip Folkert de Vries (Sep 22 2021 at 19:34):

I just updated the platform on that branch. for me the ParserTest file run and all tests pass

view this post on Zulip Folkert de Vries (Sep 22 2021 at 19:35):

oh btw it's best to run examples from the top level directory, so cargo run examples/parser/ParserTest.roc

view this post on Zulip James Carlson (Sep 23 2021 at 03:07):

Wonderful + Thanks! I pulled jim-parser and cargo run examples/parser/ParserTest.roc ran with all tests passing. Progress.

view this post on Zulip Luiz de Oliveira (Sep 24 2021 at 13:27):

Anton said:

Luiz de Oliveira can you try running the editor on the wgpu-10 branch to check if the upgrade fixes your issue?

Yup! It works fine :tada:

view this post on Zulip Luiz de Oliveira (Sep 24 2021 at 13:38):

But I still can't run some examples due to the "str.zig" error. This is the error message with RUST_BACKTRACE=1 image.png

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

I think it works if you do it from the top-level

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

the path to zig.str is currently relative to the root of the repository

view this post on Zulip Luiz de Oliveira (Sep 24 2021 at 13:39):

You are correct. It works.

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

nice!

view this post on Zulip Anton (Sep 24 2021 at 14:01):

@Luiz de Oliveira the latest trunk has a better error message but does not use wgpu-10 yet.

view this post on Zulip Giles Bowkett (Oct 04 2021 at 18:06):

curious if anybody's seen this one:

error: failed to run custom build command for 'roc_builtins v0.1.0 (/Users/giles/code/roc/compiler/builtins)'

view this post on Zulip Richard Feldman (Oct 04 2021 at 18:33):

hmm, what commit is that on?

view this post on Zulip Richard Feldman (Oct 04 2021 at 18:33):

and what OS?

view this post on Zulip Brendan Hansknecht (Oct 04 2021 at 19:49):

Does that just mean zig is missing? Or one of the llvm utils, like llvm-as?

view this post on Zulip Giles Bowkett (Oct 05 2021 at 00:13):

@Richard Feldman fa4875da8 on macOS. I actually got it on both 10.14.6 (using Intel) and 11.6 (M1). @Brendan Hansknecht I've got zig installed, but I'll check re the llvm utils.

view this post on Zulip Giles Bowkett (Oct 05 2021 at 00:22):

facepalm.gif

forgot to add the llvm path to PATH

view this post on Zulip Richard Feldman (Oct 05 2021 at 00:44):

glad it worked out! Can you open an issue about that error message? We should improve it so it's easier to troubleshoot in the future!

view this post on Zulip Giles Bowkett (Oct 05 2021 at 20:15):

done: https://github.com/rtfeldman/roc/issues/1766

view this post on Zulip Giles Bowkett (Oct 05 2021 at 20:21):

btw I installed it on Ubuntu 20 just now. smoother experience, but maybe because I'd had more practice at that point. I'm getting a bunch of "unsupported architecture" errors on my M1 MBP but I imagine that's NBD. on my Intel machine I'm seeing errors like this for the cli_run tests:

---- cli_run::nqueens stdout ----
thread 'cli_run::nqueens' panicked at 'ld: warning: No version-min specified on command line
ld: warning: -macosx_version_min not specified, assuming 10.11
', cli/tests/cli_run.rs:56:13

view this post on Zulip Giles Bowkett (Oct 05 2021 at 20:28):

I'm probably going to have a ton of these because my non-M1 machine is a 2012 Mac Pro from eBay with a (very non-standard) modern CPU and GPU. so maybe unsupported architectures on two out of three systems

view this post on Zulip Brendan Hansknecht (Oct 05 2021 at 20:30):

That specifically looks to just be a warning, does the test actually run?

view this post on Zulip Giles Bowkett (Oct 05 2021 at 20:31):

nope, 21 out of 21 failed in cli_run

view this post on Zulip Giles Bowkett (Oct 05 2021 at 20:32):

sorry, that's wrong. 2 passed, 19 failed. cli_run::hello_web and cli_run::quicksort_app were the ones that passed.

view this post on Zulip Giles Bowkett (Oct 05 2021 at 20:33):

I got similar ld: warning strings in a ton of repl_eval tests which passed, but without the "thread panicked" part

view this post on Zulip Brendan Hansknecht (Oct 05 2021 at 20:35):

May not be a real failure since I believe the cli run tests will fail if they see anything on std err. Can you try explicitly running the test:
cargo run examples/benchmarks/NQueens.roc. You will have to give a number to standard in.

view this post on Zulip Brendan Hansknecht (Oct 05 2021 at 20:35):

I guess you could more explicitly do: echo "4" | cargo run examples/benchmarks/NQueens.roc

view this post on Zulip Giles Bowkett (Oct 05 2021 at 20:39):

that seems to work. just responded with the number 2 and a bit of timing info.

❯ echo 4 | cargo run examples/benchmarks/NQueens.roc
    Finished dev [unoptimized + debuginfo] target(s) in 0.42s
     Running `target/debug/roc examples/benchmarks/NQueens.roc`
ld: warning: No version-min specified on command line
ld: warning: -macosx_version_min not specified, assuming 10.11
2
runtime: 0.093ms

view this post on Zulip Brendan Hansknecht (Oct 05 2021 at 20:41):

Cool, so it is working, just printing an extra warning that the test is flagging as a failure.

view this post on Zulip Brendan Hansknecht (Oct 05 2021 at 20:46):

I guess that is an arg that we should maybe be specifying on macos.

view this post on Zulip Giles Bowkett (Oct 05 2021 at 20:46):

yup, I found the "bail if stderr" line in the CLI tests, took it out, they pass. :+1:

view this post on Zulip Giles Bowkett (Oct 05 2021 at 20:50):

I'm new to Rust but specifying an arg like that sounds like a fun, tiny change to dig into.

I got a different fail in test_gen btw:

test_gen-d11c5b1776e1be63(6961,0x700010b71000) malloc: *** error for object 0x7fe11e7d3dc0: pointer being freed was not allocated
test_gen-d11c5b1776e1be63(6961,0x700010b71000) malloc: *** set a breakpoint in malloc_error_break to debug
error: test failed, to rerun pass '-p test_gen --lib'

view this post on Zulip Folkert de Vries (Oct 05 2021 at 20:53):

oh fun, that might be genuine. we don't check test_gen for memory safety specifically, and on CI/linux it does not segfault, but there still may be memory safety issues

view this post on Zulip Brendan Hansknecht (Oct 05 2021 at 20:54):

Giles Bowkett said:

I'm new to Rust but specifying an arg like that sounds like a fun, tiny change to dig into.

Yeah, should be a super minor change to link.rs Though I am not sure what version we should set it to.

view this post on Zulip Giles Bowkett (Oct 05 2021 at 20:57):

for now I just did #[cfg(not(target_os = "macos"))] around the stderr.is_empty()

view this post on Zulip Giles Bowkett (Oct 05 2021 at 20:57):

I'm not sure how to figure out which test's throwing the malloc error

view this post on Zulip Folkert de Vries (Oct 05 2021 at 21:11):

can you run cargo test -p test_gen

view this post on Zulip Folkert de Vries (Oct 05 2021 at 21:12):

that will crash, but should report at the very bottom the name of the actual executable it ran plus the arguments you gave it

view this post on Zulip Folkert de Vries (Oct 05 2021 at 21:12):

(there may be no arguments actually in this case)

view this post on Zulip Folkert de Vries (Oct 05 2021 at 21:12):

then, with llvm you should have lldb on your system now

view this post on Zulip Folkert de Vries (Oct 05 2021 at 21:13):

so then you'd run lldb /path/to/the/executable -- arguments if any. this will open something like a repl

view this post on Zulip Folkert de Vries (Oct 05 2021 at 21:14):

there, type run, this will start running the tests. after a while this will then crash

view this post on Zulip Folkert de Vries (Oct 05 2021 at 21:14):

then, type bt (for "backtrace")

view this post on Zulip Folkert de Vries (Oct 05 2021 at 21:14):

and that would give us the name of the test case that fails

view this post on Zulip Folkert de Vries (Oct 05 2021 at 21:14):

(yes this is rather complicated and I wish it were easier than that)

view this post on Zulip Brendan Hansknecht (Oct 05 2021 at 21:25):

Another option should be: cargo test -p test_gen -- --test-threads 1. That will make is run one test at a time. Then the last printed test name will be the test that was running when it failed.

view this post on Zulip Richard Feldman (Oct 10 2021 at 17:12):

@all as of current trunk, you can now do roc check Whatever.roc (or cargo run check Whatever.roc) to run just parsing, naming, and type checks.

This should dodge most (if not all) of the panics that currently happen after type checking when there are type mismatches, so I recommend using it instead of directly running Whatever.roc for normal development!

check also exits with 0 if there were no errors and 1 if there were errors, so you can do && at the command line to have it run once there are no more errors

view this post on Zulip Richard Feldman (Oct 10 2021 at 17:15):

thanks to @Folkert de Vries for making that one happen! :grinning:

view this post on Zulip Luiz de Oliveira (Oct 24 2021 at 00:09):

I'm getting this message when trying to evaluate anything on the repl or running code from the editor with ctrl-R. Weird thing is "cannot find -lc" I do have libc6-dev installed (build-essentials installed). I'm trying to run things on update-arch branch because I'm having the -arch problem on trunk.

image.png

view this post on Zulip Luiz de Oliveira (Oct 24 2021 at 00:40):

Now it's worse. Send help.

image.png

Apparently I broke llvm installation somehow but now I fixed it and I'm back to the first image. I'll leave it here because I'm totally clueless...

view this post on Zulip Lucas Rosa (Oct 24 2021 at 01:34):

there may be an issue with your include path. What distro are you on?

view this post on Zulip Luiz de Oliveira (Oct 24 2021 at 02:31):

Lucas Rosa said:

Luis Gutierrez there may be an issue with your include path. What distro are you on?

I think you replied to the wrong Lui(s/z)? I'm on PopOS 20.04

view this post on Zulip Lucas Rosa (Oct 24 2021 at 03:22):

omg lol you’re right

view this post on Zulip Lucas Rosa (Oct 24 2021 at 03:22):

I’m sorry

view this post on Zulip Lucas Rosa (Oct 24 2021 at 03:23):

So on Linux I’ve had issues around symlinks in usr/lib64 and usr/lib

Sometimes I would even have to delete them and manually add them back

view this post on Zulip Lucas Rosa (Oct 24 2021 at 03:23):

I was on fedora though

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

but from what I see in the first screenshot, the linker doesn’t know where those things are. Which means they actually aren’t on your computer or the include path is messed up somehow

view this post on Zulip Luiz de Oliveira (Oct 24 2021 at 03:39):

Hahaha np I'll look into that then. Thanks o/

view this post on Zulip Shritesh Bhattarai (Oct 24 2021 at 15:55):

I ran cargo test on a M1 and all the cli tests fail :sweat_smile:because this gets printed to stderr:

'-use-aa' is not a recognized feature for this target (ignoring feature)
'+zcz-fp' is not a recognized feature for this target (ignoring feature)
'-use-aa' is not a recognized feature for this target (ignoring feature)
'+zcz-fp' is not a recognized feature for this target (ignoring feature)

The warning originates from inkwell / llvm at https://github.com/rtfeldman/roc/blob/8cf62464c344794da74c0f57d5a7ed223f8b5ff1/compiler/build/src/link.rs#L836-L838. I've tried messing with the targets / triplets / features without any luck.

view this post on Zulip Richard Feldman (Oct 24 2021 at 16:00):

interesting! Can you run things manually? e.g. if you do cargo run examples/hello-world/Hello.roc does it work?

view this post on Zulip Shritesh Bhattarai (Oct 24 2021 at 16:01):

(whoops wrong topic, still getting the hang of Zulip). Everything works as far as I've tested. It just prints those warnings every time.

view this post on Zulip Richard Feldman (Oct 24 2021 at 16:03):

oh you posted in this topic originally - I just moved the other messages about the false interpeter test failure into their own topic, since that one seems like it'll take some time to resolve :big_smile:

view this post on Zulip Chloe Bai (Oct 02 2024 at 06:32):

hi, i'm new here, i'm trying to contribute to issue #6812 (make nicer error message when todo! is hit). i keep getting this error instead of the one listed on the issue:
thread 'main' panicked at crates/reporting/src/error/parse.rs:3937:14:
not yet implemented: unhandled exposes parsing error ListStart(@7)
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
does anybody know what's wrong?? for reference this is the code in my file that im running:

module Main

main =
let
a = 5000
b = 30000
in
a - b

view this post on Zulip Nathan Kramer (Oct 02 2024 at 07:03):

Hi Chloe,
I think you've stumbled on a parser bug. That code seems to break the parser.

Ideally you'll need some code that reproduces the todo! case from that issue.
I'm not sure I can help you there unfortunately, maybe someone else will have some ideas.

But to get you started, something like this will get the parsing working:

module [main]

main =
    a = 5000
    b = 30000
    a - b

Note that in Roc there is no let/in syntax, you can basically just get rid of the let/in and it works without it.

Sorry I can't be more helpful than that!

(also, if you want to run the code you'll need a platform. See https://www.roc-lang.org/examples/HelloWorld/README.html if you need a reference)

view this post on Zulip Luke Boswell (Oct 02 2024 at 07:14):

For that issue, you need to use the dev backend so try running your app with --dev, also the linked issue was identified on a apple silicon mac. @Chloe Bai do you have an aaarch64 mac?

view this post on Zulip Luke Boswell (Oct 02 2024 at 07:15):

It may be unimplemented on all of the dev backends, so the mac thing may not be relevant

view this post on Zulip Luke Boswell (Oct 02 2024 at 07:16):

I would suggest using cargo run -- --dev test-app.roc so you know you are using the debug build of the compiler, and also targeting the dev backend for roc.

view this post on Zulip Luke Boswell (Oct 02 2024 at 07:16):

Where test-app.roc is your example to reproduce the erro

view this post on Zulip Anton (Oct 02 2024 at 10:29):

@Chloe Bai I had trouble hitting a todo with cargo run -- --dev test-app.roc, but this code triggers one with the repl:

elemsApproxEq = \values, index1, index2 ->
    val1 = List.get? values index1
    val2 = List.get? values index2
    Ok (Num.isApproxEq val1 val2 {})

Full process:

$ cargo build --release --bin roc
$ ./target/release/roc repl

  The rockin' roc repl
────────────────────────

Enter an expression, or :help, or :q to quit.

» elemsApproxEq = \values, index1, index2 ->
…     val1 = List.get? values index1
…     val2 = List.get? values index2
…     Ok (Num.isApproxEq val1 val2 {})
thread 'main' panicked at crates/compiler/gen_dev/src/generic64/mod.rs:1333:18:
not yet implemented: NumAbs: layout, Builtin(Decimal)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

view this post on Zulip Chloe Bai (Oct 02 2024 at 19:52):

@Luke Boswell i only have a silicon mac

view this post on Zulip Chloe Bai (Oct 02 2024 at 19:53):

i've been trying to use both of your advice, but it's not working. i think it might be something with set up on my computer or permissions, but could i potentially set up a discord call for some help sometime within the next 24 hrs please?

view this post on Zulip Luke Boswell (Oct 02 2024 at 22:25):

@Chloe Bai would you be free at ?

view this post on Zulip Chloe Bai (Oct 03 2024 at 04:05):

@Luke Boswell oh shoot im sorry i didnt see this!! i had meetings during that time sorry. i will be free from 12pm-5pm Thu Oct 3rd (EST)!

view this post on Zulip Chloe Bai (Oct 03 2024 at 04:06):

or within the next couple of hours i am also free!!

view this post on Zulip Luke Boswell (Oct 03 2024 at 04:25):

Sent you a DM


Last updated: Jul 05 2025 at 12:14 UTC