- User Since
- Jan 31 2016, 7:15 AM (304 w, 3 d)
Mon, Nov 29
I'm assuming the logic to find the actual packages is the same (I didn't check in detail). Splitting this into separate Find-modules is definitely the way to go and that part of this patch LGTM.
Makes sense. LGTM.
I can't speak to the correctness of the Windows parts, but all the utility function stuff looks sane to me. LGTM if Pavel has no outstanding objections.
Fri, Nov 19
Nice cleanup. LGTM.
Thu, Nov 18
Wed, Nov 17
@labath Do you know what the status is of removing RenderScript altogether?
LGTM modulo the inline comment.
Tue, Nov 16
LGTM if the Windows bot is happy :-)
Thu, Nov 11
Wed, Nov 10
Hi David, this looks really comprehensive. As far as the code is concerned, it has all the parts that we'd want to support another scripting language in LLDB. That leaves us with the last remaining questions:
A few small nits but I'm very happy with the approach. Thanks Larry!
Some of the formatting in the Python tests seems a little off (can you run it through something like yapf?). Other than that this LGTM with the inline comments addressed.
Tue, Nov 9
Thanks. This LGTM!
Rather than percolating up a JSON string, we should use StructuredData (and SBStructuredData at the SB API layer) and only convert it to JSON at the very last moment.
Looks like there's an easier way to test this, so no need to add another SB API.
Mon, Nov 8
Sun, Nov 7
Fri, Nov 5
@david: Yes, I considered it, but I think this is slightly more readable.
Thu, Nov 4
Wed, Nov 3
Tue, Nov 2
I was talking to Jim about this offline and one potential solution would be to have a flag that asks the current script interpreter for some of this relevant information. What that means would be different for every language, so the output would have to be able to define its own keys and values. (JSON could be a good candidate for this?) For Python, this would include the python path and the prefix, while for lua this might be something totally different. Both could include a version.
Address code review feedback
Mon, Nov 1
I feel like this puts too much Python specific logic in the driver compared to the convenience it brings. Even though we already leak python details (like --python-path), LLDB has always been designed to support several scripting languages. I'm not convinced this use case is compelling enough to make the situation worse.
Oct 29 2021
Without this change, you get something like:
Print a status message about the deprecation of the xar file format and corresponding cmake variable.
Oct 28 2021
Thanks everyone. LGTM!
Alright, sounds reasonable. LGTM.
I understand the need for something like this to make some of the statistics more meaningful, but this is stretching the notion of statistics. Conceptually, this is approaching something like a dump of the debugger for issue/performance analysis. I think that idea is really exciting, and from that perspective there's a lot more useful information we could add to it. Long term, I can see this output be something that we ask users to include in every bug report.
Oct 27 2021
Skip the environment if it's empty and avoid a TypeError when concatenating 'NoneType' and 'str'.