Brendan Hansknecht (Dec 04 2023 at 16:31): Brendan Hansknecht (Dec 04 2023 at 16:31):Now they dbg us pretty of the platform, it can be enabled in more cases. It now compiled into applications so it could be added to roc build for example. What are our preferences about when it would be enabled?
I think as things currently stand we need it enabled with a separate flag from --dev cause I think it should be usable with the llvm backend as well.
My current thought it that dbg statements should be added to all dev and normal builds so anything without some sort of optimization flag.
Also, we should consider what packages it enables for. Right now, I think we attempt to restrict it to just the main application package, that said at times it is super useful to sprinkle dbg statements in the builtins or an imported packages. So we should consider if/how to support those workflows.
My current thought for this is that maybe we can have an explicit flag for enabling for other packages. Where you list which packages to enable dbg for. That or just an enable all flag.
Lastly, we now have a discrepancy with expect. Currently expect is still confined to running with the actual roc executable. Do we want to decouple enabling debug from expect? Do we want to support enabling expect through dbg, where if the expect fails it calls roc_dbg with a message? Do we also want an explicit roc_expect_failed for platforms to handle this printing?
Anton (Dec 04 2023 at 16:55):My current thought it that dbg statements should be added to all dev and normal builds so anything without some sort of optimization flag.
I agree!
Agus Zubiaga (Dec 04 2023 at 17:12):Brendan Hansknecht said:
Also, we should consider what packages it enables for. Right now, I think we attempt to restrict it to just the main application package, that said at times it is super useful to sprinkle dbg statements in the builtins or an imported packages. So we should consider if/how to support those workflows.
This seems even more important when you consider the upcoming changes to the module system. I think we can expect packages to be created that are only used from a single application, and therefore you might want to enable logging for them from the app.
Agus Zubiaga (Dec 04 2023 at 17:16):What if we enabled dbg always, but we just didn’t allow you to make a tarball bundle for a package with dbgs in them?
Agus Zubiaga (Dec 04 2023 at 17:17):Or another way to achieve the same is to skip every dbg from packages that were downloaded from a URL
Anton (Dec 04 2023 at 17:18):That does seem convenient, no need to mess with flags then
Agus Zubiaga (Dec 04 2023 at 17:19):The flag might still be useful to filter stuff in general or if you do want to enable it for a 3rd party package.
Richard Feldman (Dec 04 2023 at 17:30):Agus Zubiaga said:
Or another way to achieve the same is to skip every
dbgfrom packages that were downloaded from a URL
yeah this makes sense to me
Richard Feldman (Dec 04 2023 at 17:30):I'm on the fence about expect in packages
Richard Feldman (Dec 04 2023 at 17:31):on the one hand, it's potentially annoying to see failed expectations from a dependency
Richard Feldman (Dec 04 2023 at 17:31):on the other hand, it is actionable; if I see the error I can tell the author about it - and it might help them understand the problem if I'm getting a bug
Richard Feldman (Dec 04 2023 at 17:32):plus they all get removed from optimized builds anyway
Richard Feldman (Dec 04 2023 at 17:33):so overall I'd say probably we should do the experiment of having all expects enabled for dependencies
Agus Zubiaga (Dec 04 2023 at 17:34):If we do that, we should probably still have some flag to exclude certain packages
Richard Feldman (Dec 04 2023 at 17:34):also, we should probably report a warning when you roc bundle without --optimize (because you might have done that on purpose in order to share a debug build, but probably it's a mistake)
Richard Feldman (Dec 04 2023 at 17:34):I think it's worth doing the experiment of trying it without a flag and seeing how it feels in practice
Richard Feldman (Dec 04 2023 at 17:35):we can always add one later as a backwards compatible change, and I'd like to get the data points of how it feels!
Agus Zubiaga (Dec 04 2023 at 17:38):I'm a little confused about how this helps. If I have tests, I presumably want to make the all pass before cutting a release. If they all pass, why wouldn't they pass when used from an application? CPU Architecture differences?
Brendan Hansknecht (Dec 04 2023 at 17:39):You can put expect in a function and it will run at execution time of an application
Richard Feldman (Dec 04 2023 at 17:39):oh I'm just talking about inline expect
Richard Feldman (Dec 04 2023 at 17:39):yeah that :point_up:
Agus Zubiaga (Dec 04 2023 at 17:39):Ah, that makes more sense
Richard Feldman (Dec 04 2023 at 17:40):also, I think we can change the implementation of expect to use roc_dbg now
Agus Zubiaga (Dec 04 2023 at 17:40):Ok, yeah. I agree I'd probably want those to run in development.
Brendan Hansknecht (Dec 04 2023 at 17:42):What if we enabled dbg always, but we just didn’t allow you to make a tarball bundle for a package with dbgs in them?
One thing I don't like about this: As a package developer, I have to comment out or add and remove dbg statements that may regularly be useful to me. Might be nice to have roc automatically strip them when bundling (or just to ignore them when building a tarball. This avoids require the package author to purge all dbg statements from their package just to release. but still avoids the messages printing.
Agus Zubiaga (Dec 04 2023 at 17:42):I agree. Skipping them when compiling the application based on source (local vs downloaded), seems nicer for everyone.
Brendan Hansknecht (Dec 04 2023 at 17:43):also, I think we can change the implementation of expect to use roc_dbg now
I think this should be really nice, just may make the printing less pretty. Color and more complex messages may not play nice with the debug api. Cause dbg isn't guaranteed to stderr in a terminal.
Richard Feldman (Dec 04 2023 at 17:49):in the future we can make it do that though! (Syntax highlighting in dbg output I mean - by giving platforms a way to customize what Inspect output gets sent to the host)
Richard Feldman (Dec 04 2023 at 17:50):and in general I think we want the repl, expect, and dbg to all use Inspect so that users' custom Inspect implementations get used for opaques
Brendan Hansknecht (Dec 04 2023 at 18:01):That makes sense, but expect still probably wants a different printout than dbg
Brendan Hansknecht (Dec 04 2023 at 18:02):Custom inspect clarifies the types themselves. Like the data structure to represent them, but not the rest of the wrapper and message
Brendan Hansknecht (Dec 04 2023 at 18:04):── EXPECT FAILED ──────────────────────────────────── ../roc-aoc-2023/day4.roc ─
This expectation failed:
17│> expect
18│> res = part1 p1Sample
19│> res == 12
When it failed, these variables had these values:
res : U32
res = 13
I don't think a message like this can really fit into the inspect api of (location, sourceCode, someCustomTypeGeneratedByInspect). Notatably the custom type would be shared with the custom type used for dbg.
Brendan Hansknecht (Dec 04 2023 at 18:04):Also, expect really has a list of messages kinda. Cause it prints out every type stored to a variable
Brendan Hansknecht (Dec 04 2023 at 23:50):Thinking about this more, should we have something like:
fn roc_expect_failed(loc: *RocStr, src: *RocStr, variables: *RocList<{name: RocStr, value: RocStr}>)
maybe also add typname: RocStr, to the variables list?
That way when expect fails a platform can still build up a nice messege like the one we have above.
For our roc compiler internal testing platform, we can make the exit code be the total number of expects that failed such that we can make the final printout message: 0 failed and 1 passed in 554 ms.
...
Also, after adding this, we should be able to remove roc_shm_open, roc_mmap, and roc_getppid.
Richard Feldman (Dec 05 2023 at 04:41):that's a good point, I think a separate failed expectation function in the host sounds reasonable :+1:
Last updated: Jun 16 2026 at 16:19 UTC