I understand that watches aren’t supported yet in Water. However, some locals are being listed as ‘Value was optimized out’. I’m running a debug build.
We’d need a test case for that. Island/Windows, i assume?
Yes. I’ll see if I can put a small test case together.
Here is a small test case. Put breakpoints on both lines with CloseHandle and you should observe the following issues:
- Inside someFunc: most variables get optimized out
- At the global scope: some exception message and no locals displayed
TestLocals.zip (3.1 KB)
1 Like
Thanks, logged as bugs://79900
1 Like
I’m getting this (inside Somefunc):
| + | self | {<77549560>} | TestLocals.SomeClass | |
|---|---|---|---|---|
| + | sem2 | {204} | UnsafePointer | |
| k | 1 | Int64 |
and in Main:
| + | __args | {<77533104>} | gt2a_RemObjects_d_Elements_d_System_d_Array_t_1s | |
|---|---|---|---|---|
| Result | 0 | Integer |
Looks like I accidentally fixed this already.
1 Like
bugs://79900 got closed with status fixed.
I’m still seeing this (using Water 2273), although not all the time. Sometimes the “Locals” section of the Watch variables does not contain all local values, either.
Here is a minimalistic wrapper class for the UWP Buffer type:
Is this something that might work better in VS2017 as opposed to Water?
it shouldn’t. sounds like this just was t fully fixed.
Assuming I’d ever get the SSH link to work, it would still behave the same way as well? I’m just trying to pick the best option for debugging my Island (Windows) DLL as it’s somewhat tedious at this time.
Yes, this is unrelated to Fire vs Water, and would be the same.
Also, Carlo tells me even if SSH would work, remote debugging for Island/Windows is actually not supported yet.
1 Like
As for figuring out why the SSH itself doesn’t work, we figured we’d wait til it’s out of beta?
That’s fine - especially since you’re saying it won’t really behave differently (aside from the advantage of doing this from your preferred platform).
I’m just debugging my Silver/Island project the old fashioned way - breakpoints, console logging and commenting out stuff. It’s not efficient (and at times painful) but I’m confident it will improve along the way. The advantages of using a single language outweigh most of the inconvenients for now.
Edit: And I’ll add that debugging my original UWP DLL (C++/CX) in VS2017 wasn’t always “fun” either - although the debugger seemed more reliable.
bugs://79900 got reopened.
I’ve tweaked the logic for this again, you think you can try this whne we release the build later today (and if it doesn’t work, give me a testcase I can use?)
1 Like
bugs://79900 got closed with status fixed.
Just tested with 2275. This is night and day: locals do show up properly (at least in my initial testing) and the debugger behaves much more predictably.
Cheers.
1 Like