Yea, i was sort of extrapolating for a general solution to "how can we best isolate implementation specific functionality in plugins from implementation agnostic functionality in <not-plugins>.  There are a handful of other instances where a generic component includes directly from the tree of a specific plugin, so centralizing to a single plugin library seems like a starting point for solving it generally, while also serving as good documentation for the various types of plugins that exist (ie, just look in the folder at each header file).<br><br>Anyway, it's not related to this immediate problem as you said <br><div class="gmail_quote"><div dir="ltr">On Tue, Mar 21, 2017 at 7:47 PM Jim Ingham <<a href="mailto:jingham@apple.com">jingham@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That seems reasonable, but I don't think it would solve your immediate problem.<br class="gmail_msg">
<br class="gmail_msg">
The problem here is that the REPL has two parts, the part that is extensible to support the actual language you want to write a REPL for, and a part that is "any particular REPL is just an extension of the expression command."  These two roles are currently filled by the same class, and the latter half of the REPL's nature properly relies on details of the expression command that you probably don't want to plugin-ize.  The correct solution to that problem is to tease apart the "runner" part of the REPL, which doesn't need a Plugin interface and can live in source/Commands, and the language adaptor part which is properly a plugin.  Then the language adaptor could go in ExpressionParser plugin directory.<br class="gmail_msg">
<br class="gmail_msg">
Not suggesting you do that work, but that seems like the actually correct solution here.<br class="gmail_msg">
<br class="gmail_msg">
Jim<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
> On Mar 21, 2017, at 7:34 PM, Zachary Turner <<a href="mailto:zturner@google.com" class="gmail_msg" target="_blank">zturner@google.com</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> Long term I wonder if we should have a plugin library that contains headers and registration interfaces for every type of plugin lldb supports, but no actual implementations. All the specific plugins could link against it, and everything else in lldb could too to get interface definitions for each type of plugin. Then, than would be a natural place to put this, and specific implementations could live in Plugins/REPL<br class="gmail_msg">
> On Tue, Mar 21, 2017 at 7:24 PM Jim Ingham <<a href="mailto:jingham@apple.com" class="gmail_msg" target="_blank">jingham@apple.com</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> > On Mar 21, 2017, at 7:14 PM, Zachary Turner <<a href="mailto:zturner@google.com" class="gmail_msg" target="_blank">zturner@google.com</a>> wrote:<br class="gmail_msg">
> ><br class="gmail_msg">
> ><br class="gmail_msg">
> > On Tue, Mar 21, 2017 at 7:07 PM Jim Ingham <<a href="mailto:jingham@apple.com" class="gmail_msg" target="_blank">jingham@apple.com</a>> wrote:<br class="gmail_msg">
> > ScriptInterpreters are about providing a way to script lldb.<br class="gmail_msg">
> ><br class="gmail_msg">
> > The REPL in lldb is about giving users an interactive way to play with a compiled language with no requirement that it bind to lldb in particular.<br class="gmail_msg">
> ><br class="gmail_msg">
> > The two seem fairly different concepts.<br class="gmail_msg">
> > Sure, but isn't that just a side effect of the fact that we only have 1, and that's what it happens to do?  It still enters a REPL when you type "script", the fact that it manipulates lldb itself seems like just an implementation detail.<br class="gmail_msg">
><br class="gmail_msg">
> They have sufficiently different purposes that requiring the ScriptInterpreter to be a good "fool around with a supposedly compiled language interactively" or the "REPL" to be good at programming lldb seems like it would hamstring both to no clear purpose.<br class="gmail_msg">
><br class="gmail_msg">
> Jim<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> ><br class="gmail_msg">
> ><br class="gmail_msg">
> ><br class="gmail_msg">
> ><br class="gmail_msg">
> > Jim<br class="gmail_msg">
> ><br class="gmail_msg">
> ><br class="gmail_msg">
> > > On Mar 21, 2017, at 6:44 PM, Zachary Turner via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" class="gmail_msg" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br class="gmail_msg">
> > ><br class="gmail_msg">
> > > Not having written or debugged swift before, what does it give you that a ScriptInterpreter plugin doesn't? It seems like ScriptInterpreterPython is, in fact, just a kind of REPL, albeit one that interacts with the debugger itself rather a particular target. I'm wondering if anyone who wanted this kind of thing in the future could just do it as a ScriptInterpreter plugin<br class="gmail_msg">
> > > On Tue, Mar 21, 2017 at 6:37 PM Jason Molenda <<a href="mailto:jmolenda@apple.com" class="gmail_msg" target="_blank">jmolenda@apple.com</a>> wrote:<br class="gmail_msg">
> > > I don't follow REPL issues very closely but I think some people may have hopes of doing a repl in a language other than swift in the future which is why it was upstreamed to llvm.<br class="gmail_msg">
> > ><br class="gmail_msg">
> > > J<br class="gmail_msg">
> > ><br class="gmail_msg">
> > > > On Mar 21, 2017, at 6:34 PM, Zachary Turner <<a href="mailto:zturner@google.com" class="gmail_msg" target="_blank">zturner@google.com</a>> wrote:<br class="gmail_msg">
> > > ><br class="gmail_msg">
> > > > Thanks, I had a suspicion it might be used in Swift.  Given that swift seems to be the only consumer, and there are no plans for support for any other languages, would it be reasonable to say that it's a swift-specific addition and could be in the swift repo?<br class="gmail_msg">
> > > ><br class="gmail_msg">
> > > > If not, I will need to come up with a good way to get REPL.h to not #include code from the source tree (and ideally, not #include code from Commands at all).<br class="gmail_msg">
> > > ><br class="gmail_msg">
> > > > On Tue, Mar 21, 2017 at 6:24 PM Jason Molenda <<a href="mailto:jmolenda@apple.com" class="gmail_msg" target="_blank">jmolenda@apple.com</a>> wrote:<br class="gmail_msg">
> > > > It's used in the swift lldb, <a href="https://github.com/apple/swift-lldb" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/apple/swift-lldb</a><br class="gmail_msg">
> > > ><br class="gmail_msg">
> > > > The idea is to have any non-swift specific code in <a href="http://llvm.org" rel="noreferrer" class="gmail_msg" target="_blank">llvm.org</a>; the github repository for swift specific additions.<br class="gmail_msg">
> > > ><br class="gmail_msg">
> > > ><br class="gmail_msg">
> > > > > On Mar 21, 2017, at 6:19 PM, Zachary Turner via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" class="gmail_msg" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br class="gmail_msg">
> > > > ><br class="gmail_msg">
> > > > > AFAICT this is all dead code.  Unless someone is using it out of tree?  There is a way to register repl support for various languages, but no code in tree is actually doing this.  It's possible I'm just not finding the code though.<br class="gmail_msg">
> > > > ><br class="gmail_msg">
> > > > > It appears this code was all added about 18 months ago, and if it hasn't found any use in that time frame, it would be great to remove it to reduce technical debt.<br class="gmail_msg">
> > > > ><br class="gmail_msg">
> > > > > That said, if it's actually being used in tree somewhere and I'm just overlooking it, let me know.<br class="gmail_msg">
> > > > > _______________________________________________<br class="gmail_msg">
> > > > > lldb-dev mailing list<br class="gmail_msg">
> > > > > <a href="mailto:lldb-dev@lists.llvm.org" class="gmail_msg" target="_blank">lldb-dev@lists.llvm.org</a><br class="gmail_msg">
> > > > > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br class="gmail_msg">
> > > ><br class="gmail_msg">
> > ><br class="gmail_msg">
> > > _______________________________________________<br class="gmail_msg">
> > > lldb-dev mailing list<br class="gmail_msg">
> > > <a href="mailto:lldb-dev@lists.llvm.org" class="gmail_msg" target="_blank">lldb-dev@lists.llvm.org</a><br class="gmail_msg">
> > > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br class="gmail_msg">
> ><br class="gmail_msg">
><br class="gmail_msg">
<br class="gmail_msg">
</blockquote></div>