http://bugs.llvm.org/show_bug.cgi?id=32362
Bug ID: 32362
Summary: LLDB master fails to compile with linker error
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
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 h
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
> wrote:
>
> AFAICT this is all dead code. Unless some
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
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 wrote:
>
> Thanks, I had a suspicion it might be used in Swift.
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
There's no reason why you couldn't do a C REPL, so having the framework for it
in llvm.org seems reasonable. Just the generic part is enough trickery it is
worth sharing.
I'm not sure why you care about the fact that Repl.h includes something from
Command, but if you do then probably the easie
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.
Jim
> On Mar 21, 2017, at 6:44 PM, Zachary
On Tue, Mar 21, 2017 at 7:02 PM Jim Ingham wrote:
> There's no reason why you couldn't do a C REPL, so having the framework
> for it in llvm.org seems reasonable. Just the generic part is enough
> trickery it is worth sharing.
>
> I'm not sure why you care about the fact that Repl.h includes som
> On Mar 21, 2017, at 6:58 PM, Jim Ingham wrote:
>
> There's no reason why you couldn't do a C REPL, so having the framework for
> it in llvm.org seems reasonable. Just the generic part is enough trickery it
> is worth sharing.
>
> I'm not sure why you care about the fact that Repl.h include
On Tue, Mar 21, 2017 at 7:07 PM Jim Ingham 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 differe
On Tue, Mar 21, 2017 at 7:10 PM Jim Ingham wrote:
>
> > On Mar 21, 2017, at 6:58 PM, Jim Ingham wrote:
> >
> > There's no reason why you couldn't do a C REPL, so having the framework
> for it in llvm.org seems reasonable. Just the generic part is enough
> trickery it is worth sharing.
> >
> > I
> On Mar 21, 2017, at 7:16 PM, Zachary Turner wrote:
>
>
> On Tue, Mar 21, 2017 at 7:10 PM Jim Ingham wrote:
>
> > On Mar 21, 2017, at 6:58 PM, Jim Ingham wrote:
> >
> > There's no reason why you couldn't do a C REPL, so having the framework for
> > it in llvm.org seems reasonable. Just th
> On Mar 21, 2017, at 7:14 PM, Zachary Turner wrote:
>
>
> On Tue, Mar 21, 2017 at 7:07 PM Jim Ingham 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 tha
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
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 express
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 . There are a handful
of other instances where a generic component includes directly from the
tree of a specific plugin,
17 matches
Mail list logo
