Closed Woogachaka closed 5 months ago
I think the problem is just that breakpoints don't work in top level constants. They should work fine in functions.
Good to know, but this was meant as a demonstrator for a much more complex context. I was attempting to use on in the midst of a much larger project and it was not functioning there either (in that case in the midst of a function). I'll quickly write a test script with a function and breakpoint to confirm if it works or not outside of that project.
Ok, I've now run this futhark file in the repl
let a = 0...10
let b = 1...30
let c = 2...60
def breakTest (arr: []i32) : i32 = #[break] (reduce (+) 0 arr)
let d = breakTest a
let e = breakTest b
let f = breakTest c
and no breakpoints were utilized here either.
in the repl, the command used was :load breakTest.fut
, the load gave a few warnings about ambiguous types, and then I was simply able to access the results of d, e, and f
It's the same situation: those breakpoints occur while evaluating top level constants, where they are ignored. They work just fine if you type breakTest a
at the REPL.
I don't remember whether there was a very good reason we ignore breakpoints during initialisation.
Ok, thank you for the clarification, I have been able to utilize a breakpoint now by simply manually running the line of interest after the load statement. Just had to do a change in workflow.
I'm using version 0.25.12 (from brew) and am having difficulties in that the repl does not seem to utilize breakpoints in any way.
This is being run on an Ubuntu 22.04 WSL2 instance, futhark 0.25.12 installed via brew, in a python 3.10.12 virtual environment.
Even just loading the following test code, break points are not being respected:
this is making troubleshooting very challenging.
EDIT: an additional note, trace and #[trace] seem to work properly.
EDIT: further update, attempting to replicate the same environment on a virtual machine (also Ubuntu 22.04), the same break point test also fails