James Carlson (Aug 10 2021 at 18:10): 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
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"
Folkert de Vries (Aug 10 2021 at 19:16):did you compile the roc compiler in release or debug mode (debug is the default)?
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.
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
so that says that evalTest is not in scope
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
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!
James Carlson (Aug 10 2021 at 21:21):Will do!
Folkert de Vries (Aug 10 2021 at 21:22):it would give one if we didn't panic later in mono
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
Folkert de Vries (Aug 10 2021 at 21:22):but the mono machinery assumes that function does exist
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
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.
Anton (Aug 11 2021 at 09:40):#1569
Folkert de Vries (Aug 11 2021 at 10:02):taking a look. segfaults are bad
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)
Folkert de Vries (Aug 11 2021 at 10:32):likely something bad in our stack size calculation
James Carlson (Aug 11 2021 at 13:19):What is the syntax for running cargo run examples/benchmarks/ParseApp.roc with RUST_BACKTRACE=1?
Folkert de Vries (Aug 11 2021 at 13:25):I usually just set that variable in my current shell
Folkert de Vries (Aug 11 2021 at 13:25):so depends on the shell you use
Anton (Aug 11 2021 at 13:39):I usually do RUST_BACKTRACE=1 cargo run ....
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?
Richard Feldman (Aug 12 2021 at 02:35):it should mean that foo typechecks
Richard Feldman (Aug 12 2021 at 02:35):whenever you import an interface module, it gets fully type-checked just like whatever imported it!
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
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?
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?
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
Folkert de Vries (Aug 12 2021 at 11:33):and that panic is probably caused by a type error earlier in the pipeline
James Carlson (Aug 12 2021 at 11:44):Thanks, I'll make that folder and investigate my types
James Carlson (Aug 12 2021 at 11:50):I've moved all my code in the jim branch to examples/parser
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 _ -> [ ]
it might be that the result not being used is a problem here
Folkert de Vries (Aug 12 2021 at 14:29):oneOfResult is dead code eliminated
Folkert de Vries (Aug 12 2021 at 14:30):because I don't see a type error when i run the code
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?
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.
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?
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
Folkert de Vries (Aug 12 2021 at 16:33):thanks for all your testing btw!
James Carlson (Aug 12 2021 at 16:33):Thanks Folkert, good luck!
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.
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
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
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.
Folkert de Vries (Aug 12 2021 at 19:37):yea this will actually exit early
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.
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!)
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.
Anton (Aug 13 2021 at 14:53):Cool stuff :)
James Carlson (Aug 13 2021 at 14:53):Thanks Anton!
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!!!
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:
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.
James Carlson (Aug 13 2021 at 14:57):Haha! Thanks!! It is a stopgap pending the real thing.
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!
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.
Richard Feldman (Aug 13 2021 at 14:59):if it's a panic or segfault, it's definitely a compiler bug :big_smile:
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
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
Richard Feldman (Aug 13 2021 at 15:01):so definitely please file issues for any of those that you see! :smiley:
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)"
Just posted an issue, #1581, https://github.com/rtfeldman/roc/issues/1581, regarding a panic when calling function Test.failures
Folkert de Vries (Aug 13 2021 at 18:07):huh, that's an old one
Folkert de Vries (Aug 13 2021 at 18:07):fix should be simple there
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
does that happen consistently?
Folkert de Vries (Aug 13 2021 at 22:30):that one is usually a race condition somewhere
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.
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:
James Carlson (Aug 13 2021 at 23:29):Will do
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.
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
excellent, thanks!
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
@James Carlson I created #1589 for this, thanks for the find :)
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}
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
Feel free to create a PR to add this test framework to trunk! Perhaps a folder named testframework under examples?
James Carlson (Aug 15 2021 at 12:59):Will do!
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
sorry what is the typo?
Folkert de Vries (Aug 15 2021 at 13:03):"3" instead of "q3"?
James Carlson (Aug 15 2021 at 13:03):Yes
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?
James Carlson (Aug 15 2021 at 13:07):Utility.concatStrListWithSeparator, Utility.strRepeat, Utility.concatStrList, Utility.filterList
Yeah sure, sounds good!
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"
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!!)
Richard Feldman (Aug 16 2021 at 00:03):indeed! :big_smile:
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.
Anton (Aug 16 2021 at 09:16):Hmm that does look like it should work
Anton (Aug 16 2021 at 09:18):@James Carlson can you try simplifying the types further and check if the error still occurs?
Folkert de Vries (Aug 16 2021 at 10:28):in your case Parser is just a type alias, not a tag union
Folkert de Vries (Aug 16 2021 at 10:29):so you can remove the Parser in Parser (Loop s2)
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
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 ]
well turning raw bytes into utf8 is an operation that can fail
Folkert de Vries (Aug 17 2021 at 12:37):in this case you can probably do |> Result.withDefault ""
James Carlson (Aug 17 2021 at 12:50):Ah yes, thanks!
James Carlson (Aug 17 2021 at 14:11):Demo of interface Console in branch jim, folder examples/parser:
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
oh, very fancy
James Carlson (Aug 17 2021 at 14:13):Just Richard's Elm library ported to Richard's language :big_smile:
James Carlson (Aug 17 2021 at 14:15):Followed his API word-for-word
Folkert de Vries (Aug 17 2021 at 14:18):but we can actually print to the console :smile:
Lucas Rosa (Aug 17 2021 at 15:43):that's very cool
Richard Feldman (Aug 17 2021 at 16:48):that's awesome! :heart_eyes_cat:
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)
James Carlson (Aug 18 2021 at 00:48):That's good to know ("\u(001B)[32m"). Meanwhile, just for fun:
Richard Feldman (Aug 18 2021 at 01:00):so cool!!!
Richard Feldman (Aug 18 2021 at 01:00):also that's a nice sub-millisecond runtime on that test suite :joy:
James Carlson (Aug 18 2021 at 22:55):Sub-millisecond is soooo good!
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.
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?
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:
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.
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.
James Carlson (Aug 19 2021 at 14:13):((If I can't easily fix it))
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
putline should be putLine
James Carlson (Aug 20 2021 at 09:07):My goodness! I need better glasses and more sleep!! Thanks.
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
I fixed a common cause of the "symbol/layout {:?} {:?} combo must be in DeclarationToIndex" style error here https://github.com/rtfeldman/roc/pull/1609
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
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:
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!(),
}
}
lmk if that works!
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?
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.
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);
}
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)
James Carlson (Aug 22 2021 at 06:05):@Richard Feldman Never mind -- all running just fine now. Thankyou!
Richard Feldman (Aug 22 2021 at 12:11):sweet, glad it's working!
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
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
can you get some sort of error message out of the failing parser?
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)
I'll see what I can do. But I can't understand why adding one test causes the other to fail.
Folkert de Vries (Aug 22 2021 at 19:54):no that sounds like a bug
Folkert de Vries (Aug 22 2021 at 19:55):but knowing what the code thinks went wrong could be helpful tracking the problem down
James Carlson (Aug 22 2021 at 19:55):I'll work on it now. I can probably get something out.
Folkert de Vries (Aug 22 2021 at 19:58):alternatively if you can get it into one file I can take a look
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!
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
Brian Hicks (Aug 27 2021 at 11:40):(deleted)
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
James Carlson (Sep 11 2021 at 16:42):Test (6) passes in one test and fails in the other.
James Carlson (Sep 11 2021 at 16:47):Is it possible to import modules in the repl?
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:
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?
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.
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!
Zeljko Nesic (Sep 12 2021 at 21:28):@James Carlson Brilliant is brilliant!
May I ask what were you working there? :)
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)
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.
James Carlson (Sep 12 2021 at 22:21):@Zeljko Nesic what is your connection with Brilliant? Did you do any of their courses?
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.
James Carlson (Sep 13 2021 at 14:39):Good for you and your son ! :tada:
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!
James Carlson (Sep 14 2021 at 05:52):@Richard Feldman It is fixed!! Fantastic!
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
Screen-Shot-2021-09-14-at-11.28.09-AM.png
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.
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
James Carlson (Sep 14 2021 at 16:46):Thanks Folkert!
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
James Carlson (Sep 15 2021 at 04:49):Thanks Folkert, you folks are doing an amazing job!
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
Folkert de Vries (Sep 17 2021 at 23:12):the full thing should now run with that PR
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.
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
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.
Anton (Sep 18 2021 at 12:24):Hi @Luiz de Oliveira , can you tell me what OS you are using?
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).
Anton (Sep 18 2021 at 12:34)::+1: thanks, can you also give me your nix version (nix --version)?
Luiz de Oliveira (Sep 18 2021 at 12:50):nix version: 2.3.15
Anton (Sep 18 2021 at 13:19):I will give that a try myself and will let you know once I find a fix!
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.
Richard Feldman (Sep 18 2021 at 15:19):@Ju Liu any ideas? :sweat_smile:
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
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.
Anton (Sep 18 2021 at 16:23):I'll make note to improve the cannot find str.zig error message.
Luiz de Oliveira (Sep 18 2021 at 16:26):I get a quick black window that crashes and vanishes and this error message:
Somehow I'm breaking a lot of stuff idk.
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 =(
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.
Richard Feldman (Sep 18 2021 at 17:01):wow, yeah that error is coming from the lower-level graphics library we're using
Richard Feldman (Sep 18 2021 at 17:03):https://hg.mozilla.org/releases/mozilla-release/rev/73891d5902058892b221f10ea1ba7f6bbc8b2c4f#l106.32
Luiz de Oliveira (Sep 18 2021 at 19:19):This is the backtrace in case it's useful:
Looks like the last line of code ran before getting into the lib is this call: image.png
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
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.
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:
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:
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.
Luiz de Oliveira (Sep 18 2021 at 19:55):Well, I'll learn more rust hahaha idk how to do it yet.
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 !
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?
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
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
is it consistent?
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
it doesn't explain :point_up: but one thing that'll need to change is not using RocCallResult anymore
Richard Feldman (Sep 22 2021 at 12:19):@James Carlson is the branch that reproduces this pushed somewhere?
James Carlson (Sep 22 2021 at 12:19):Yes, it is jim-parser
James Carlson (Sep 22 2021 at 12:20):Just pushed the branch with the latest merge of trunk
James Carlson (Sep 22 2021 at 12:21):I am doing cargo run ... from ./examples
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
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
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.
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:
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
Folkert de Vries (Sep 24 2021 at 13:38):I think it works if you do it from the top-level
Folkert de Vries (Sep 24 2021 at 13:39):the path to zig.str is currently relative to the root of the repository
Luiz de Oliveira (Sep 24 2021 at 13:39):You are correct. It works.
Folkert de Vries (Sep 24 2021 at 13:39):nice!
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.
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)'
Richard Feldman (Oct 04 2021 at 18:33):hmm, what commit is that on?
Richard Feldman (Oct 04 2021 at 18:33):and what OS?
Brendan Hansknecht (Oct 04 2021 at 19:49):Does that just mean zig is missing? Or one of the llvm utils, like llvm-as?
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.
Giles Bowkett (Oct 05 2021 at 00:22):facepalm.gif
forgot to add the llvm path to PATH
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!
Giles Bowkett (Oct 05 2021 at 20:15):done: https://github.com/rtfeldman/roc/issues/1766
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
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
Brendan Hansknecht (Oct 05 2021 at 20:30):That specifically looks to just be a warning, does the test actually run?
Giles Bowkett (Oct 05 2021 at 20:31):nope, 21 out of 21 failed in cli_run
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.
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
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.
Brendan Hansknecht (Oct 05 2021 at 20:35):I guess you could more explicitly do: echo "4" | cargo run examples/benchmarks/NQueens.roc
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
Cool, so it is working, just printing an extra warning that the test is flagging as a failure.
Brendan Hansknecht (Oct 05 2021 at 20:46):I guess that is an arg that we should maybe be specifying on macos.
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:
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'
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
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.
Giles Bowkett (Oct 05 2021 at 20:57):for now I just did #[cfg(not(target_os = "macos"))] around the stderr.is_empty()
Giles Bowkett (Oct 05 2021 at 20:57):I'm not sure how to figure out which test's throwing the malloc error
Folkert de Vries (Oct 05 2021 at 21:11):can you run cargo test -p test_gen
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
Folkert de Vries (Oct 05 2021 at 21:12):(there may be no arguments actually in this case)
Folkert de Vries (Oct 05 2021 at 21:12):then, with llvm you should have lldb on your system now
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
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
Folkert de Vries (Oct 05 2021 at 21:14):then, type bt (for "backtrace")
Folkert de Vries (Oct 05 2021 at 21:14):and that would give us the name of the test case that fails
Folkert de Vries (Oct 05 2021 at 21:14):(yes this is rather complicated and I wish it were easier than that)
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.
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
Richard Feldman (Oct 10 2021 at 17:15):thanks to @Folkert de Vries for making that one happen! :grinning:
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.
Luiz de Oliveira (Oct 24 2021 at 00:40):Now it's worse. Send help.
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...
Lucas Rosa (Oct 24 2021 at 01:34):there may be an issue with your include path. What distro are you on?
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
Lucas Rosa (Oct 24 2021 at 03:22):omg lol you’re right
Lucas Rosa (Oct 24 2021 at 03:22):I’m sorry
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
Lucas Rosa (Oct 24 2021 at 03:23):I was on fedora though
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
Luiz de Oliveira (Oct 24 2021 at 03:39):Hahaha np I'll look into that then. Thanks o/
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.
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?
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.
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:
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
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)
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?
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
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.
Luke Boswell (Oct 02 2024 at 07:16):Where test-app.roc is your example to reproduce the erro
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
@Luke Boswell i only have a silicon mac
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?
Luke Boswell (Oct 02 2024 at 22:25):@Chloe Bai would you be free at ?
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)!
Chloe Bai (Oct 03 2024 at 04:06):or within the next couple of hours i am also free!!
Luke Boswell (Oct 03 2024 at 04:25):Sent you a DM
Last updated: Jul 26 2025 at 12:14 UTC