diku-dk / futhark

:boom::computer::boom: A data-parallel functional programming language
http://futhark-lang.org
ISC License
2.36k stars 165 forks source link

Repl on Ubuntu does not respect Break points #2098

Closed Woogachaka closed 5 months ago

Woogachaka commented 5 months ago

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:

let a = 0...10
let b = #[break] 1...30
let c = 2...60

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

athas commented 5 months ago

I think the problem is just that breakpoints don't work in top level constants. They should work fine in functions.

Woogachaka commented 5 months ago

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.

Woogachaka commented 5 months ago

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

athas commented 5 months ago

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.

Woogachaka commented 5 months ago

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.