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
In the above code, fail on List.map [t1,t2] evalTest |> Test.strListToStr ","
, no useful error messages, just "error"
did you compile the roc compiler in release or debug mode (debug is the default)?
Probably debug: target/debug/roc examples/benchmarks/Tester.roc
. I don't remember how I installed it.
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
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
@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!
Will do!
it would give one if we didn't panic later in mono
the real reason I think is that we don't make specializations when we know the function will blow up when we call it
but the mono machinery assumes that function does exist
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
I get a segmentation fault for the code with List.map
, as expected there are some valgrind errors. I'll make an issue.
#1569
taking a look. segfaults are bad
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)
likely something bad in our stack size calculation
What is the syntax for running cargo run examples/benchmarks/ParseApp.roc
with RUST_BACKTRACE=1
?
I usually just set that variable in my current shell
so depends on the shell you use
I usually do RUST_BACKTRACE=1 cargo run ....
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?
it should mean that foo
typechecks
whenever you import an interface module, it gets fully type-checked just like whatever imported it!
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?
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?
should be possible to have a parser
folder. just make sure to also copy the platform
folder
and that panic is probably caused by a type error earlier in the pipeline
Thanks, I'll make that folder and investigate my types
I've moved all my code in the jim
branch to examples/parser
@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
oneOfResult
is dead code eliminated
because I don't see a type error when i run the code
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?
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.
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?
took a deeper look and there is a bug somewhere, will try to track it down
thanks for all your testing btw!
Thanks Folkert, good luck!
Ah ... the testing is good for me also. Finding the boundary between my errors and the compiler bugs is the hard part.
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
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
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.
yea this will actually exit early
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.
(FYI, I moved the above conversations from #beginners > strings and #beginners > syntax to give error messages their own topic!)
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.
Cool stuff :)
Thanks Anton!
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!!!
Jim, I think you just created Roc's first-ever genuinely useful programming tool written entirely in Roc :smiley:
I plan to add
showFailures : List Test -> Str
but atm am blocked by
Utility.filterList : List a, (a -> Bool) -> List a
which creates panic.
Haha! Thanks!! It is a stopgap pending the real thing.
is there a bug report for that one? Folkert and I are planning to pair on bugfixes this weekend!
I will make one. I always struggle with the question: is it my code, or something else.
if it's a panic or segfault, it's definitely a compiler bug :big_smile:
well, or a platform bug - but I assume you're not making changes to the platform haha
the compiler should never panic or segfault, or generate application code that panics (in the Rust sense) or segfaults
so definitely please file issues for any of those that you see! :smiley:
@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
huh, that's an old one
fix should be simple there
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?
that one is usually a race condition somewhere
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.
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:
Will do
Just filed ##1583, https://github.com/rtfeldman/roc/issues/1583, re panic when trying to test the manyAux
combinator.
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!
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 :)
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?
Will do!
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?
"3" instead of "q3"?
Yes
@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?
Utility.concatStrListWithSeparator, Utility.strRepeat, Utility.concatStrList, Utility.filterList
Yeah sure, sounds good!
PR request #1590: https://github.com/rtfeldman/roc/pull/1590 --- adds Test.roc
, a bare-bones testing "framework"
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!!)
indeed! :big_smile:
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.
Hmm that does look like it should work
@James Carlson can you try simplifying the types further and check if the error still occurs?
in your case Parser
is just a type alias, not a tag union
so you can remove the Parser
in Parser (Loop s2)
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
in this case you can probably do |> Result.withDefault ""
Ah yes, thanks!
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
Just Richard's Elm library ported to Richard's language :big_smile:
Followed his API word-for-word
but we can actually print to the console :smile:
that's very cool
that's awesome! :heart_eyes_cat:
incidentally, in Roc you can do "\u(001B)[32m"
for unicode escapes (the \u(...)
is equivalent to \u{...}
in Elm)
That's good to know ("\u(001B)[32m"). Meanwhile, just for fun:
so cool!!!
also that's a nice sub-millisecond runtime on that test suite :joy:
Sub-millisecond is soooo good!
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.
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?
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.
Interesting that andThen
now fails when it didn't before. I'll make a one-file version of this also.
((If I can't easily fix it))
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
My goodness! I need better glasses and more sleep!! Thanks.
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
@James Carlson the roc_panic
error is because we just added a new requirement for hosts to expose a function with that name
if your platform is using Rust, here's what you'd need to add to its lib.rs
:
#[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!
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?
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.
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)
@Richard Feldman Never mind -- all running just fine now. Thankyou!
sweet, glad it's working!
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
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?
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.
no that sounds like a bug
but knowing what the code thinks went wrong could be helpful tracking the problem down
I'll work on it now. I can probably get something out.
alternatively if you can get it into one file I can take a look
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!
interesting. We have a couple more fixes in the works, so maybe things will also just work when those are merged
(deleted)
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
Test (6) passes in one test and fails in the other.
Is it possible to import modules in the repl?
@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:
is the code to reproduce the order-dependent tests pushed somewhere we can take a look at it?
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.
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!
@James Carlson Brilliant is brilliant!
May I ask what were you working there? :)
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)
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.
@Zeljko Nesic what is your connection with Brilliant? Did you do any of their courses?
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.
Good for you and your son ! :tada:
@James Carlson The "order matters but it shouldn't" problem should be fixed on trunk
now - see if you can still reproduce it!
@Richard Feldman It is fixed!! Fantastic!
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
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.
this is likely the case because some fold or map function is used internally. I'll have a fix tonight
Thanks Folkert!
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
Thanks Folkert, you folks are doing an amazing job!
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
the full thing should now run with that PR
@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.
@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.
Hi @Luiz de Oliveira , can you tell me what OS you are using?
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).
:+1: thanks, can you also give me your nix version (nix --version
)?
nix version: 2.3.15
I will give that a try myself and will let you know once I find a fix!
@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.
@Ju Liu any ideas? :sweat_smile:
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
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
.
I'll make note to improve the cannot find str.zig
error message.
I get a quick black window that crashes and vanishes and this error message:
Somehow I'm breaking a lot of stuff idk.
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 =(
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.
wow, yeah that error is coming from the lower-level graphics library we're using
https://hg.mozilla.org/releases/mozilla-release/rev/73891d5902058892b221f10ea1ba7f6bbc8b2c4f#l106.32
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
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.
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:
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:
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.
Well, I'll learn more rust hahaha idk how to do it yet.
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 !
@Luiz de Oliveira can you try running the editor on the wgpu-10 branch to check if the upgrade fixes your issue?
I have also improved the zig str error message and added a warning to the nix section of our BUILDING_FROM_SOURCE.md
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?
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
@James Carlson is the branch that reproduces this pushed somewhere?
Yes, it is jim-parser
Just pushed the branch with the latest merge of trunk
I am doing cargo run ...
from ./examples
I just updated the platform on that branch. for me the ParserTest
file run and all tests pass
oh btw it's best to run examples from the top level directory, so cargo run examples/parser/ParserTest.roc
Wonderful + Thanks! I pulled jim-parser
and cargo run examples/parser/ParserTest.roc
ran with all tests passing. Progress.
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:
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
I think it works if you do it from the top-level
the path to zig.str
is currently relative to the root of the repository
You are correct. It works.
nice!
@Luiz de Oliveira the latest trunk has a better error message but does not use wgpu-10 yet.
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)'
hmm, what commit is that on?
and what OS?
Does that just mean zig is missing? Or one of the llvm utils, like llvm-as?
@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.
facepalm.gif
forgot to add the llvm path to PATH
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!
done: https://github.com/rtfeldman/roc/issues/1766
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
That specifically looks to just be a warning, does the test actually run?
nope, 21 out of 21 failed in cli_run
sorry, that's wrong. 2 passed, 19 failed. cli_run::hello_web
and cli_run::quicksort_app
were the ones that passed.
I got similar ld: warning
strings in a ton of repl_eval
tests which passed, but without the "thread panicked" part
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.
I guess you could more explicitly do: echo "4" | cargo run examples/benchmarks/NQueens.roc
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.
I guess that is an arg that we should maybe be specifying on macos.
yup, I found the "bail if stderr" line in the CLI tests, took it out, they pass. :+1:
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
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.
for now I just did #[cfg(not(target_os = "macos"))]
around the stderr.is_empty()
I'm not sure how to figure out which test's throwing the malloc
error
can you run cargo test -p test_gen
that will crash, but should report at the very bottom the name of the actual executable it ran plus the arguments you gave it
(there may be no arguments actually in this case)
then, with llvm you should have lldb
on your system now
so then you'd run lldb /path/to/the/executable -- arguments if any
. this will open something like a repl
there, type run
, this will start running the tests. after a while this will then crash
then, type bt
(for "backtrace")
and that would give us the name of the test case that fails
(yes this is rather complicated and I wish it were easier than that)
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.
@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
thanks to @Folkert de Vries for making that one happen! :grinning:
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.
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...
there may be an issue with your include path. What distro are you on?
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
omg lol you’re right
I’m sorry
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
I was on fedora though
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
Hahaha np I'll look into that then. Thanks o/
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.
interesting! Can you run things manually? e.g. if you do cargo run examples/hello-world/Hello.roc
does it work?
(whoops wrong topic, still getting the hang of Zulip). Everything works as far as I've tested. It just prints those warnings every time.
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:
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
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)
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?
It may be unimplemented on all of the dev backends, so the mac thing may not be relevant
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.
Where test-app.roc
is your example to reproduce the erro
@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
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?
@Chloe Bai would you be free at ?
@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)!
or within the next couple of hours i am also free!!
Sent you a DM
Last updated: Jul 05 2025 at 12:14 UTC