Thanks for the questions on the REPL.
[...]
I would direct you to those licenses to see if they are
compatible with your desired usage.
Licensing isn't really what I'm worried about. I have a technical
issue.
There are at least a few apps that incorporate LLDB into their
IDEs, either via the SB API (the LLDB C++-based API), via the GDB
Remote protocol, and via the GDB mi protocol (via lldb-mi). It is
definitely possible to go the route of setting up an app that
communicates with LLDB to get a REPL experience that way.
I'll be able to comment more directly on questions this upcoming
week.
What I'm more looking for is this. Consider how Emacs uses elisp --
the application can be extended and altered by the end user at will
by adding new interpreted elisp code in the field.
Say I wanted to have a Swift based system that did more or less the
same thing, that is, which provided users with the ability to extend
the function of their program by writing Swift code which was loaded
and interpreted at run time and which interacted seamlessly with the
Swift code that makes up the body of the application.
I'm sure that given enough work this could be done, but I'm asking
if this is something that should be reasonably practical to do with
the REPL given the current architecture or if it would require an
unreasonable amount of work.
Note that I'm not trying to build an IDE. It is rather an application
where a sophisticated end user may have needs that are difficult for
the application programmer to fully anticipate.
(If there is some other way to do this that is more practical, say
somehow incorporating the compiler at runtime and compiling and
loading new code into the app, I'd be interested in knowing. However,
an interpreter seemed like the easier choice.)
Sorry I missed this yesterday. My normal gmail account is missing from the lists, so my last answer was made without seeing this first.
The Swift REPL works by injecting code into a separate Swift process. The code is JIT-ed and then run in the separate process by way of LLDB’s highly-specialized code used to control other processes (as one would expect to find in a debugger). It would be challenging to adapt that code as is to run in the same process (as it sounds like you want, for purposes of app customization along the lines of Python/Maya, elisp/Emacs, etc.) However, it certainly would act as a template on how to do it. I don’t think you’d want to try to build the app incorporating LLDB, because LLDB brings with it a whole lot of functionality that is likely not useful unless your app is a debugger.
The places to start looking would be any of the files with *Expression* to get a sense of how our expression engine works. The Swift specific ones will set up a context to compile, JIT and run code. The run part is what you would likely need to change, as instead of sending code over to another process, usurping a thread, and sending results back, your code will instead want to arrange to run the newly JIT-ed code in the local process.
I don’t think interpreting will be easier if you plan to base your code on what you find in LLDB. The JIT is all there, but I don’t think there is any existing interpreter code (Sean - please correct me if I’m wrong here). Unless that’s incorrect, I think you’d find that you need to write more code to handle interpreting rather than JIT-ing it.
Hope that helps!
-Todd
···
On Dec 6, 2015, at 6:48 AM, Perry E. Metzger via swift-lldb-dev <swift-lldb-dev@swift.org> wrote:
On Sat, 5 Dec 2015 16:33:54 -0800 Todd Fiala via swift-lldb-dev > <swift-lldb-dev@swift.org> wrote:
Perry
--
Perry E. Metzger perry@piermont.com
_______________________________________________
swift-lldb-dev mailing list
swift-lldb-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-lldb-dev