[lldb-dev] Is anything using the REPL?

Tue Mar 21 19:53:09 PDT 2017

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).

Anyway, it's not related to this immediate problem as you said
On Tue, Mar 21, 2017 at 7:47 PM Jim Ingham <jingham at apple.com> wrote:

> That seems reasonable, but I don't think it would solve your immediate
> problem.
>
> 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.
>
> Not suggesting you do that work, but that seems like the actually correct
> solution here.
>
> Jim
>
>
> > On Mar 21, 2017, at 7:34 PM, Zachary Turner <zturner at google.com> wrote:
> >
> > 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
> > On Tue, Mar 21, 2017 at 7:24 PM Jim Ingham <jingham at apple.com> wrote:
> >
> > > On Mar 21, 2017, at 7:14 PM, Zachary Turner <zturner at google.com>
> wrote:
> > >
> > >
> > > On Tue, Mar 21, 2017 at 7:07 PM Jim Ingham <jingham at apple.com> wrote:
> > > ScriptInterpreters are about providing a way to script lldb.
> > >
> > > 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.
> > >
> > > The two seem fairly different concepts.
> > > 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.
> >
> > 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.
> >
> > Jim
> >
> >
> > >
> > >
> > >
> > >
> > > Jim
> > >
> > >
> > > > On Mar 21, 2017, at 6:44 PM, Zachary Turner via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
> > > >
> > > > 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
> > > > On Tue, Mar 21, 2017 at 6:37 PM Jason Molenda <jmolenda at apple.com>
> wrote:
> > > > 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.
> > > >
> > > > J
> > > >
> > > > > On Mar 21, 2017, at 6:34 PM, Zachary Turner <zturner at google.com>
> wrote:
> > > > >
> > > > > 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?
> > > > >
> > > > > 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).
> > > > >
> > > > > On Tue, Mar 21, 2017 at 6:24 PM Jason Molenda <jmolenda at apple.com>
> wrote:
> > > > > It's used in the swift lldb, https://github.com/apple/swift-lldb
> > > > >
> > > > > The idea is to have any non-swift specific code in llvm.org; the
> github repository for swift specific additions.
> > > > >
> > > > >
> > > > > > On Mar 21, 2017, at 6:19 PM, Zachary Turner via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
> > > > > >
> > > > > > 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.
> > > > > >
> > > > > > 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.
> > > > > >
> > > > > > That said, if it's actually being used in tree somewhere and I'm
> just overlooking it, let me know.
> > > > > > _______________________________________________
> > > > > > lldb-dev mailing list
> > > > > > lldb-dev at lists.llvm.org
> > > > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> > > > >
> > > >
> > > > _______________________________________________
> > > > lldb-dev mailing list
> > > > lldb-dev at lists.llvm.org
> > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> > >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170322/41d467b5/attachment.html>