Re: [lldb-dev] [RFC] Supporting Lua Scripting in LLDB

2019-12-10 Thread Pavel Labath via lldb-dev
On 09/12/2019 18:27, Jonas Devlieghere wrote:
> On Mon, Dec 9, 2019 at 1:55 AM Pavel Labath  wrote:
>>
>> I think this would be a very interesting project, and would allow us to
>> flesh out the details of the script interpreter interface.
>>
>> A lot of the complexity in our python code comes from the fact that
>> python can be (a) embedded into lldb and (b) lldb can be embedded into
>> python. It's been a while since I worked with lua, but from what I
>> remember, lua was designed to make (a) easy., and I don't think (b) was
>> ever a major goal (though it can always be done ways, of course)..
>>
>> Were you intending to implement both of these directions or just one of
>> them ((a), I guess)?
> 
> Thanks for pointing this out. Indeed, my goal is only to support (a)
> for exactly the reasons you brought up.
> 
>> The reason I am asking this is because doing only (a) will definitely
>> make lua support simpler than python, but it will also mean it won't be
>> a "python-lite".
>>
>> Both of these options are fine -- I just want to understand where you're
>> going with this. It also has some impact on the testing strategy, as our
>> existing python tests are largely using mode (b).
> 
> That's part of my motivation for *not* doing (b). I really don't want
> to create/maintain another (Lua driven) test suite.

I certainly see where you're coming from, but I'm not sure if this will
actually achieve the intended effect. The thing is, not doing (b) does
not really reduce the testing surface that much -- it just makes the
tested APIs harder to reach. If Python didn't have (b), we wouldn't be
able to do "import lldb" in python, but that's about it. The full lldb
python api would still be reachable by starting lldb and typing "script".

What this means is that if lua doesn't support (b) then the lua bindings
will need to be tested by driving lldb from within the lua interpreter
embedded within lldb -- which doesn't exactly sound like a win. I'm not
saying this means we *must* implement (b), or that the alternative
solution will be more complex than testing via (b) (though I'm sure we
could come up with something way simpler than dotest), but I think we
should try to come up with a good testing story very early on.

Speaking of testing, will there be any bot configured to build&test the
lua code?

> 
>> Another question I'm interested in is how deeply will this
>> multi-interpreter thing go? Will it be a build time option, will it be
>> selectable at runtime, but we'll have only one script interpreter per
>> SBDebugger, or will we be able to freely mix'n'match scripting languages?
> 
> There is one script interpreter per debugger. As far as I can tell
> from the code this is already enforced.
> 
>> I think the last option would be best because of data formatters
>> (otherwise one would have a problem is some of his data formatters are
>> written in python and others in lua), but it would also create a lot
>> more of new api surface, as one would have to worry about consistency of
>> the lua and python views of lldb, etc.
> 
> That's an interesting problem I didn't think of. I'm definitely not
> excited about having the same data formatter implemented in both
> scripting languages. Mixing scripting languages makes sense for when
> your LLDB is configured to support both Python and Lua, but what do
> you do for people that want only Lua? They might still want to
> re-implement some data formatters they care about...

Well, if they really have a lldb build which only supports one scripting
language, then yes, they'd have to reimplement something -- there isn't
anything else that can be done. But it'd be a pitty if someone had lldb
which supports *both* languages and he is forced to choose which data
structures he wants pretty-printed.

> Anyway, given
> that we don't maintain/ship data formatters in Python ourselves, maybe
> this isn't that big of an issue at all?

Hard to say without this thing actually being used. I certainly don't
think this is something that we need to solve right now, though I think
it something that we should be aware of, and not close the door on that
possibility completely.

And BTW we do ship python data formatters right now. The libc++ and
libstdc++ have some formatters written in python -- with the choice of
formatters being pretty arbitrary.

pl
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Re: [lldb-dev] [10.0.0 Release] Release schedule

2019-12-10 Thread Hans Wennborg via lldb-dev
> Hello everyone,
>
> I know 9.0.1 is still in full swing, and 10.0.0 isn't due for some
> time, but I'd like to get the schedule settled well before we start.
>
> Below is my proposed timeline. It's essentially the same as last time.
>
> - 15 January 2020: Create the release branch, Release Candidate 1
> ships soon after
>
> - 5 February 2020: Release Candidate 2
>
> - 26 February 2020: Final (this usually slips a little, but let's try not to).
>
> Please let me know what you think.

I've put the schedule up on the web page.

Thanks,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


[lldb-dev] [Bug 44262] New: variable templates in expressions cause lldb to crash

2019-12-10 Thread via lldb-dev
https://bugs.llvm.org/show_bug.cgi?id=44262

Bug ID: 44262
   Summary: variable templates in expressions cause lldb to crash
   Product: lldb
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: lab...@google.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

(lldb) expr --top-level -- template T aaa = 1;
(lldb) expr -- aaa
lldb: clang/lib/AST/Type.cpp:2106: bool clang::Type::isConstantSizeType()
const: Assertion `!isDependentType() && "This doesn't make sense for dependent
types"' failed.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Re: [lldb-dev] [RFC] Supporting Lua Scripting in LLDB

2019-12-10 Thread Jim Ingham via lldb-dev


> On Dec 10, 2019, at 3:11 AM, Pavel Labath via lldb-dev 
>  wrote:
> 
> On 09/12/2019 18:27, Jonas Devlieghere wrote:
>> On Mon, Dec 9, 2019 at 1:55 AM Pavel Labath  wrote:
>>> 
>>> I think this would be a very interesting project, and would allow us to
>>> flesh out the details of the script interpreter interface.
>>> 
>>> A lot of the complexity in our python code comes from the fact that
>>> python can be (a) embedded into lldb and (b) lldb can be embedded into
>>> python. It's been a while since I worked with lua, but from what I
>>> remember, lua was designed to make (a) easy., and I don't think (b) was
>>> ever a major goal (though it can always be done ways, of course)..
>>> 
>>> Were you intending to implement both of these directions or just one of
>>> them ((a), I guess)?
>> 
>> Thanks for pointing this out. Indeed, my goal is only to support (a)
>> for exactly the reasons you brought up.
>> 
>>> The reason I am asking this is because doing only (a) will definitely
>>> make lua support simpler than python, but it will also mean it won't be
>>> a "python-lite".
>>> 
>>> Both of these options are fine -- I just want to understand where you're
>>> going with this. It also has some impact on the testing strategy, as our
>>> existing python tests are largely using mode (b).
>> 
>> That's part of my motivation for *not* doing (b). I really don't want
>> to create/maintain another (Lua driven) test suite.
> 
> I certainly see where you're coming from, but I'm not sure if this will
> actually achieve the intended effect. The thing is, not doing (b) does
> not really reduce the testing surface that much -- it just makes the
> tested APIs harder to reach. If Python didn't have (b), we wouldn't be
> able to do "import lldb" in python, but that's about it. The full lldb
> python api would still be reachable by starting lldb and typing "script".
> 
> What this means is that if lua doesn't support (b) then the lua bindings
> will need to be tested by driving lldb from within the lua interpreter
> embedded within lldb -- which doesn't exactly sound like a win. I'm not
> saying this means we *must* implement (b), or that the alternative
> solution will be more complex than testing via (b) (though I'm sure we
> could come up with something way simpler than dotest), but I think we
> should try to come up with a good testing story very early on.
> 
> Speaking of testing, will there be any bot configured to build&test the
> lua code?
> 
>> 
>>> Another question I'm interested in is how deeply will this
>>> multi-interpreter thing go? Will it be a build time option, will it be
>>> selectable at runtime, but we'll have only one script interpreter per
>>> SBDebugger, or will we be able to freely mix'n'match scripting languages?
>> 
>> There is one script interpreter per debugger. As far as I can tell
>> from the code this is already enforced.
>> 
>>> I think the last option would be best because of data formatters
>>> (otherwise one would have a problem is some of his data formatters are
>>> written in python and others in lua), but it would also create a lot
>>> more of new api surface, as one would have to worry about consistency of
>>> the lua and python views of lldb, etc.
>> 
>> That's an interesting problem I didn't think of. I'm definitely not
>> excited about having the same data formatter implemented in both
>> scripting languages. Mixing scripting languages makes sense for when
>> your LLDB is configured to support both Python and Lua, but what do
>> you do for people that want only Lua? They might still want to
>> re-implement some data formatters they care about...
> 
> Well, if they really have a lldb build which only supports one scripting
> language, then yes, they'd have to reimplement something -- there isn't
> anything else that can be done. But it'd be a pitty if someone had lldb
> which supports *both* languages and he is forced to choose which data
> structures he wants pretty-printed.
> 
>> Anyway, given
>> that we don't maintain/ship data formatters in Python ourselves, maybe
>> this isn't that big of an issue at all?
> 
> Hard to say without this thing actually being used. I certainly don't
> think this is something that we need to solve right now, though I think
> it something that we should be aware of, and not close the door on that
> possibility completely.
> 
> And BTW we do ship python data formatters right now. The libc++ and
> libstdc++ have some formatters written in python -- with the choice of
> formatters being pretty arbitrary.

This is an aside, but...  We originally wrote all the data formatters in Python 
for dog fooding purposes.  Then most of the ones relevant to macOS were 
replaced with C++ ones quite a while ago - partly so that there would be 
formatters for crucial objects that didn't depend on having Python around and 
partly as an experiment in the cost of C++ vrs. Python data formatters.  The 
former purpose was obviated when ALL data formatters got errantly put unde