Given that the response so far has been positive, I've put up the patches for review:
https://reviews.llvm.org/D71232 https://reviews.llvm.org/D71234 https://reviews.llvm.org/D71235 Jonas On Mon, Dec 9, 2019 at 9:27 AM Jonas Devlieghere <jo...@devlieghere.com> wrote: > > On Mon, Dec 9, 2019 at 1:55 AM Pavel Labath <pa...@labath.sk> 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. > > > 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... Anyway, given > that we don't maintain/ship data formatters in Python ourselves, maybe > this isn't that big of an issue at all? > > > On 09/12/2019 01:25, Jonas Devlieghere via lldb-dev wrote: > > > Hi everyone, > > > > > > Earlier this year, when I was working on the Python script > > > interpreter, I thought it would be interesting to see what it would > > > take to support other scripting languages in LLDB. Lua, being designed > > > to be embedded, quickly came to mind. The idea remained in the back of > > > my head, but I never really got around to it, until now. > > > > > > I was pleasantly surprised to see that it only took me a few hours to > > > create a basic but working prototype. It supports running single > > > commands as well as an interactive interpreter and has access to most > > > of the SB API through bindings generated by SWIG. Of course it's far > > > from complete. > > > > > > Before I invest more time in this, I'm curious to hear what the > > > community thinks about adding support for another scripting language > > > to LLDB. Do we need both Lua and Python? > > > > > > Here are some of the reasons off the top of my head as to why the > > > answer might be > > > "yes": > > > > > > - The cost for having another scripting language is pretty small. The > > > Lua script interpreter is very simple and SWIG can reuse the existing > > > interfaces to generate the bindings. > > > - LLDB is designed to support multiple script interpreters, but in > > > reality we only have one. Actually exercising this property ensures > > > that we don't unintentionally break that design assumptions. > > > - The Python script interpreter is complex. It's hard to figure out > > > what's really needed to support another language. The Lua script > > > interpreter on the other hand is pretty straightforward. Common code > > > can be shared by both. > > > - Currently Python support is disabled for some targets, like Android > > > and iOS. Lua could enable scripting for these environments where > > > having all of Python is overkill or undesirable. > > > > > > Reasons why the answer might be "no": > > > > > > - Are our users going to use this? > > > - Supporting Python is an ongoing pain. Do we really want to risk > > > burdening ourselves with another scripting language? > > > - The Python API is very well tested. We'd need to add test for the > > > Lua bindings as well. It's unlikely this will match the coverage of > > > Python, and probably even undesirable, because what's the point of > > > testing the same thing twice. Also, do we want to risk fragmenting > > > tests across two scripting languages? > > > > > > There's probably a bunch more stuff that I didn't even think of. :-) > > > > > > Personally I lean towards "yes" because I feel the benefits outweigh > > > the costs, but of course that remains to be seen. Please let me know > > > what you think! > > > > > > If you're curious about what this looks like, you can find the patches > > > on my fork on GitHub: > > > https://github.com/JDevlieghere/llvm-project/tree/lua > > > > > > Cheers, > > > Jonas > > > _______________________________________________ > > > lldb-dev mailing list > > > lldb-dev@lists.llvm.org > > > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > > > > > > On 09/12/2019 09:33, Raphael “Teemperor” Isemann via lldb-dev wrote: > > > I think this is great, thanks for working on this! My only concern > > > is that I would prefer if we could limit the Lua tests to just the > > > Lua->C++ calling machinery (e.g., that we handle Lua strings > > > correctly and all that jazz) and not fragment our test suit. > > > Otherwise Lua seems to require far less maintenance work than > > > Python, so I am not worried about the technical debt this adds. > > I agree -- I think our position should be (at least until lua support is > > very mature) is that the primary api testing language should be python. > > I.e., every new api should have a python test, and a lua test can be > > added when there is something interesting lua-specific going on. > > > > pl _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
