You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Comments don't appear in SDK files when debugging #178
This is an artifact of debugging dart: files. We download the dart: source from the VM when we debug; these are regenerated by the VM from the tokenized format the VM stores the sources files in (the snapshot format). That format doesn't preserve comments -
This seems like a poor user experience (not just because of the huge numbers of blank lines, but because when debugging the dartdoc comments on a method might be important - you might have misunderstood what a method does).
Is there a way around it? If not, I think it might be worth raising a case in sdk for discussion?
It's not perfect, but it is nice that the sources are exactly matched to the ones the VM is running. There are a few different implementations of some of the dart: libraries, and some custom patch files for different runtimes and embedders. So, it is useful to download the dart: sources from the VM, even w/ some of the drawbacks.
If we can determine that we're synced w/ the VM in terms of the SDK version we have on disk and what the VM is running, and we can ensure that we select the right version of the dart: implementation, we could choose to read the dart: from disk (/lib). Right now it is the debugger clients choice as to where to get the dart: sources from (the sdk or d/l'ed from the VM).
If we can determine that we're synced w/ the VM in terms of the SDK version we have on disk and what the VM is running
We're launching the VM from the SDK path, so I think it's safe to assume they match? *
If someone has modified the files in their SDK install I don't think it's unexpected they'd see the wrong source during debugging. We're already sending them to the raw SDK path (I think) when they hit F12, so if the sources are out then breakpoints would be messed up too.
I really want to avoid things that look like bugs to the end user (and this looked like a bug to me). I've seen a lot of people with complaints about their current editor and I don't want Dart Code to be another on that list. If someone takes time to try out Dart Code, I want to try my hardest to make sure they don't want to go back! :D
* I'm assuming a release SDK snapshots will match the dart files on disk; I don't know if that's true though? If it's possible (without the user modifying them) then I think we have an issue with Go to Def possibly resulting in in-SDK breakpoints being bad :-(
When launching a CLI app from an sdk, the dart: sources will match what's in the VM (they're all built against the same commit in the sdk repo). I'm more worried about corner cases, where you're trying to connect to a remotely running VM, or debugging a Flutter app (a separate VM embedder). And if I recall correctly, the sources in the VM have been concatenated - you won't easily be able to map the line locations the VM is reporting with the files in the sdk/lib dir. I'd be worth poking around those files a bit, and look at the sources send back by the VM, to get a sense for it's its possible to map from what the VM reports to the files on disk.
It's worth experimenting with, yup. But you'd be fixing the comment issue, and possibly taking on other, separate issues :)
I'm more worried about corner cases, where you're trying to connect to a remotely running VM, or debugging a Flutter app (a separate VM embedder).
I actually know almost nothing about Flutter (I'm desperate to try it but there's still no Windows support!) so not really sure of the implications - do they start dart:?
If the sources don't match, this is going to mean you can't Go to Def and insert breakpoints :-(
And if I recall correctly, the sources in the VM have been concatenated - you won't easily be able to may the line locations the VM is reporting with the files in the sdk/lib dir.
Looking at my screenshot at the top of this case, it shows 'dart:core/uri.dart' and the line numbers match 'uri.dart' in the SDK, so I think this might not be an issue (I think the import statement is importing them all, but looks like the debugger is giving the individual path?)
It's worth experimenting with, yup. But you'd be fixing the comment issue, and possibly taking on other, separate issues :)
Obviously I don't want that; but I'd really like to have no issues! :) If I "fix" this on a branch, is it possible to run flutter apps via Dart Code to test these possible issues? (I'm not familiar with what you need to run Flutter stuff).
My 0.02 is that this is a higher-risk fix for a less serious issue, but happy to be proved wrong. W/ Flutter (and with remote debugging), there's the possibility that the dart sdk on disk is out of sync with the VM you're debugging, so the dart: sources may be slightly different.
You might want to do some validation against as many of the dart: libraries you can load into the standard command-line VM
Re: flutter, you debug it with the same vm service protocol we're using here. How you start the apps are slightly different - you use the flutter command-line tool to launch the app on your phone, and it sets up whatever port forwarding is necessary to communicate from the host machine.
IDEs generally use this protocol: https://github.com/flutter/flutter/wiki/The-flutter-daemon-mode to talk to the flutter tool (starting the flutter tools up via flutter daemon). It can notify the IDE when a device is available, and the IDE can use the protocol to start and stop apps on the target device.
My 0.02 is that this is a higher-risk fix for a less serious issue
I understand this, but now you've said they might not match I'm concerned there is another issue - pressing F12 may give the wrong thing, so you might put breakpoints there and they don't work. It feels like there should be some sort of solution to this.
I don't think it's unreasonable to expect:
F12 on a method takes you to the one that will be executed when you run
F12 on an method doesn't take you to a version with all the comments stripped (and loads of blank lines)
Pressing F12 on a method and then putting a breakpoint in it will work
Currently it seems like no solutions will provide all of those, so I think it would be a valid request to raise for some support for all of this in some form?
I don't know a lot of about the internals of this, so I don't know how complicated/realistic it is, I'm just just thinking about the best user experience... if there are technical complications to providing the best use experience I think we should at least have a go at having them resolved.
I'm gonna close this because I don't think anyone is that bothered by it. I tend to run with debugSdkLibraries: false since I'd prefer to treat the SDK as a black box that has no bugs and just see my own code, so I don't see it often.
If the request comes up again, we can review some of the ideas above (like checking if the sources are "the same").
In v2.2.1 of Dart this is all working great, the sources are available again and they include comments! I've re-enabled the tests for downloading source and added a check for comments (gated in v2.2.1). Thanks @bkonyi!
Activity
devoncarew commentedon Sep 10, 2016
This is an artifact of debugging dart: files. We download the dart: source from the VM when we debug; these are regenerated by the VM from the tokenized format the VM stores the sources files in (the snapshot format). That format doesn't preserve comments -
DanTup commentedon Sep 11, 2016
This seems like a poor user experience (not just because of the huge numbers of blank lines, but because when debugging the dartdoc comments on a method might be important - you might have misunderstood what a method does).
Is there a way around it? If not, I think it might be worth raising a case in sdk for discussion?
devoncarew commentedon Sep 11, 2016
It's not perfect, but it is nice that the sources are exactly matched to the ones the VM is running. There are a few different implementations of some of the
dart:libraries, and some custom patch files for different runtimes and embedders. So, it is useful to download the dart: sources from the VM, even w/ some of the drawbacks.If we can determine that we're synced w/ the VM in terms of the SDK version we have on disk and what the VM is running, and we can ensure that we select the right version of the dart: implementation, we could choose to read the dart: from disk (/lib). Right now it is the debugger clients choice as to where to get the dart: sources from (the sdk or d/l'ed from the VM).
DanTup commentedon Sep 11, 2016
We're launching the VM from the SDK path, so I think it's safe to assume they match? *
If someone has modified the files in their SDK install I don't think it's unexpected they'd see the wrong source during debugging. We're already sending them to the raw SDK path (I think) when they hit
F12, so if the sources are out then breakpoints would be messed up too.I really want to avoid things that look like bugs to the end user (and this looked like a bug to me). I've seen a lot of people with complaints about their current editor and I don't want Dart Code to be another on that list. If someone takes time to try out Dart Code, I want to try my hardest to make sure they don't want to go back! :D
* I'm assuming a release SDK snapshots will match the dart files on disk; I don't know if that's true though? If it's possible (without the user modifying them) then I think we have an issue with Go to Def possibly resulting in in-SDK breakpoints being bad :-(
DanTup commentedon Sep 11, 2016
Maybe it's worth trying out on a branch. Is it correct that
dart:just maps directly to{sdk}/lib?devoncarew commentedon Sep 11, 2016
When launching a CLI app from an sdk, the dart: sources will match what's in the VM (they're all built against the same commit in the sdk repo). I'm more worried about corner cases, where you're trying to connect to a remotely running VM, or debugging a Flutter app (a separate VM embedder). And if I recall correctly, the sources in the VM have been concatenated - you won't easily be able to map the line locations the VM is reporting with the files in the sdk/lib dir. I'd be worth poking around those files a bit, and look at the sources send back by the VM, to get a sense for it's its possible to map from what the VM reports to the files on disk.
It's worth experimenting with, yup. But you'd be fixing the comment issue, and possibly taking on other, separate issues :)
DanTup commentedon Sep 11, 2016
I actually know almost nothing about Flutter (I'm desperate to try it but there's still no Windows support!) so not really sure of the implications - do they start
dart:?If the sources don't match, this is going to mean you can't Go to Def and insert breakpoints :-(
Looking at my screenshot at the top of this case, it shows 'dart:core/uri.dart' and the line numbers match 'uri.dart' in the SDK, so I think this might not be an issue (I think the import statement is importing them all, but looks like the debugger is giving the individual path?)
DanTup commentedon Sep 11, 2016
Obviously I don't want that; but I'd really like to have no issues! :) If I "fix" this on a branch, is it possible to run flutter apps via Dart Code to test these possible issues? (I'm not familiar with what you need to run Flutter stuff).
devoncarew commentedon Sep 13, 2016
My 0.02 is that this is a higher-risk fix for a less serious issue, but happy to be proved wrong. W/ Flutter (and with remote debugging), there's the possibility that the dart sdk on disk is out of sync with the VM you're debugging, so the dart: sources may be slightly different.
You might want to do some validation against as many of the
dart:libraries you can load into the standard command-line VMRe: flutter, you debug it with the same vm service protocol we're using here. How you start the apps are slightly different - you use the
fluttercommand-line tool to launch the app on your phone, and it sets up whatever port forwarding is necessary to communicate from the host machine.IDEs generally use this protocol: https://github.com/flutter/flutter/wiki/The-flutter-daemon-mode to talk to the flutter tool (starting the flutter tools up via
flutter daemon). It can notify the IDE when a device is available, and the IDE can use the protocol to start and stop apps on the target device.DanTup commentedon Sep 13, 2016
I understand this, but now you've said they might not match I'm concerned there is another issue - pressing
F12may give the wrong thing, so you might put breakpoints there and they don't work. It feels like there should be some sort of solution to this.I don't think it's unreasonable to expect:
Currently it seems like no solutions will provide all of those, so I think it would be a valid request to raise for some support for all of this in some form?
I don't know a lot of about the internals of this, so I don't know how complicated/realistic it is, I'm just just thinking about the best user experience... if there are technical complications to providing the best use experience I think we should at least have a go at having them resolved.
DanTup commentedon May 3, 2018
I'm gonna close this because I don't think anyone is that bothered by it. I tend to run with
debugSdkLibraries: falsesince I'd prefer to treat the SDK as a black box that has no bugs and just see my own code, so I don't see it often.If the request comes up again, we can review some of the ideas above (like checking if the sources are "the same").
4 remaining items
DanTup commentedon Feb 25, 2019
This may be fixed in SDK now, we should test!
DanTup commentedon Mar 20, 2019
In v2.2.1 of Dart this is all working great, the sources are available again and they include comments! I've re-enabled the tests for downloading source and added a check for comments (gated in v2.2.1). Thanks @bkonyi!