REPL questions


(Todd Fiala) #1

Hi all,

Thanks for the questions on the REPL.

With respect to incorporating a REPL into another program, the text-based
Swift REPL is available in and implemented via LLDB. As Swift LLDB is
implemented on top of LLDB, there are two projects involved with regards to
the source. The source code for the core of LLDB (as available via llvm.org)
is available according to the terms of the license as spelled out at
llvm.org. The Swift-specific parts (i.e. any files not in the llvm.org
LLDB source base) are available according to the license as specified at
swift.org. I would direct you to those licenses to see if they are
compatible with your desired usage.

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.

···

--
-Todd


(Gage Morgan) #2

If we had a language binding for gtk, and entered code to create a window, would REPL running the Swift command be able to respond interactively from CLI? Thanks,MGage Morgan

···

Sent from Outlook

On Sat, Dec 5, 2015 at 4:33 PM -0800, "Todd Fiala via swift-lldb-dev" <swift-lldb-dev@swift.org> wrote:

Hi all,

Thanks for the questions on the REPL.

With respect to incorporating a REPL into another program, the text-based
Swift REPL is available in and implemented via LLDB. As Swift LLDB is
implemented on top of LLDB, there are two projects involved with regards to
the source. The source code for the core of LLDB (as available via llvm.org)
is available according to the terms of the license as spelled out at
llvm.org. The Swift-specific parts (i.e. any files not in the llvm.org
LLDB source base) are available according to the license as specified at
swift.org. I would direct you to those licenses to see if they are
compatible with your desired usage.

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


(Perry E. Metzger) #3

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

Perry

···

On Sat, 5 Dec 2015 16:33:54 -0800 Todd Fiala via swift-lldb-dev <swift-lldb-dev@swift.org> wrote:
--
Perry E. Metzger perry@piermont.com


(Gage Morgan) #4

The Swift-specific parts (i.e. any files not in the llvm.org LLDB source base) are > available according to the license as specified at swift.org. I would direct you to > those licenses to see if they are compatible with your desired usage.

Let me rephrase that, I think that was a response to asking what Apple says you can or cannot do with REPL. I meant "Has Apple stated possible uses for REPL other than from the CLI-only interface?"
I'm looking to develop GUIs with it, but am unsure how.
Thanks,--MGage--

···

Sent from Outlook

    _____________________________
From: Todd Fiala via swift-lldb-dev <swift-lldb-dev@swift.org>
Sent: Saturday, December 5, 2015 7:33 PM
Subject: [swift-lldb-dev] REPL questions
To: <swift-lldb-dev@swift.org>

       Hi all,
          Thanks for the questions on the REPL.
          With respect to incorporating a REPL into another program, the text-based Swift REPL is available in and implemented via LLDB. As Swift LLDB is implemented on top of LLDB, there are two projects involved with regards to the source. The source code for the core of LLDB (as available via llvm.org) is available according to the terms of the license as spelled out at llvm.org. The Swift-specific parts (i.e. any files not in the llvm.org LLDB source base) are available according to the license as specified at swift.org. I would direct you to those licenses to see if they are compatible with your desired usage.
          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. --
                   -Todd


(Todd Fiala) #5

Hi Gage,

The REPL does let you import Swift modules. If you wanted to make or find
a GTK binding, load it into the REPL, and drive that via the REPL, you
certainly could do that. Using the REPL to do this would allow you to
explore the binding at runtime, as many REPL-based languages afford. Is
that the kind of thing you're after?

The last comment makes me think you may be asking more about a graphical
REPL, though. Xcode has Playgrounds, but that doesn't exist in Open Source
Swift. I don't see what would stop somebody from trying to write something
similar against GTK or any other GUI library.

Hope that helps!

-Todd

···

On Sun, Dec 6, 2015 at 6:12 PM, Gage Morgan <gagemorgan@outlook.com> wrote:

> The Swift-specific parts (i.e. any files not in the llvm.org LLDB
source base) are > available according to the license as specified at
swift.org. I would direct you to > those licenses to see if they are
compatible with your desired usage.

Let me rephrase that, I think that was a response to asking what Apple
says you can or cannot do with REPL. I meant "Has Apple stated possible
uses for REPL other than from the CLI-only interface?"

I'm looking to develop GUIs with it, but am unsure how.

Thanks,
--MGage--

Sent from Outlook <http://aka.ms/Ox5hz3>

_____________________________
From: Todd Fiala via swift-lldb-dev <swift-lldb-dev@swift.org>
Sent: Saturday, December 5, 2015 7:33 PM
Subject: [swift-lldb-dev] REPL questions
To: <swift-lldb-dev@swift.org>

Hi all,

Thanks for the questions on the REPL.

With respect to incorporating a REPL into another program, the text-based
Swift REPL is available in and implemented via LLDB. As Swift LLDB is
implemented on top of LLDB, there are two projects involved with regards to
the source. The source code for the core of LLDB (as available via
llvm.org) is available according to the terms of the license as spelled
out at llvm.org. The Swift-specific parts (i.e. any files not in the
llvm.org LLDB source base) are available according to the license as
specified at swift.org. I would direct you to those licenses to see if
they are compatible with your desired usage.

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

--
-Todd


(Todd Fiala) #6

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


(Gage Morgan) #7

That was what I was looking for. Just one more question: For any project, how is a C to Swift function binding created? I'd like to know how to import C functions to Swift. Once I can do this successfully, I'll be all set.

Hi Gage,

The REPL does let you import Swift modules. If you wanted to make or find
a GTK binding, load it into the REPL, and drive that via the REPL, you
certainly could do that. Using the REPL to do this would allow you to
explore the binding at runtime, as many REPL-based languages afford. Is
that the kind of thing you're after?

The last comment makes me think you may be asking more about a graphical
REPL, though. Xcode has Playgrounds, but that doesn't exist in Open Source
Swift. I don't see what would stop somebody from trying to write something
similar against GTK or any other GUI library.

Hope that helps!

-Todd

···

Sent from Outlook
On Sun, Dec 6, 2015 at 10:39 PM -0800, "Todd Fiala" <todd.fiala@gmail.com> wrote:

On Sun, Dec 6, 2015 at 6:12 PM, Gage Morgan <gagemorgan@outlook.com> wrote:

> The Swift-specific parts (i.e. any files not in the llvm.org LLDB
source base) are > available according to the license as specified at
swift.org. I would direct you to > those licenses to see if they are
compatible with your desired usage.

Let me rephrase that, I think that was a response to asking what Apple
says you can or cannot do with REPL. I meant "Has Apple stated possible
uses for REPL other than from the CLI-only interface?"

I'm looking to develop GUIs with it, but am unsure how.

Thanks,
--MGage--

Sent from Outlook <http://aka.ms/Ox5hz3>

_____________________________
From: Todd Fiala via swift-lldb-dev <swift-lldb-dev@swift.org>
Sent: Saturday, December 5, 2015 7:33 PM
Subject: [swift-lldb-dev] REPL questions
To: <swift-lldb-dev@swift.org>

Hi all,

Thanks for the questions on the REPL.

With respect to incorporating a REPL into another program, the text-based
Swift REPL is available in and implemented via LLDB. As Swift LLDB is
implemented on top of LLDB, there are two projects involved with regards to
the source. The source code for the core of LLDB (as available via
llvm.org) is available according to the terms of the license as spelled
out at llvm.org. The Swift-specific parts (i.e. any files not in the
llvm.org LLDB source base) are available according to the license as
specified at swift.org. I would direct you to those licenses to see if
they are compatible with your desired usage.

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

--
-Todd


(Jim Ingham) #8

That was what I was looking for. Just one more question: For any project, how is a C to Swift function binding created? I'd like to know how to import C functions to Swift. Once I can do this successfully, I'll be all set.

That's a question that is more appropriate for swift-users. You want the place where some compiler folks hang out...

Jim

···

On Dec 7, 2015, at 6:19 PM, Gage Morgan via swift-lldb-dev <swift-lldb-dev@swift.org> wrote:

Sent from Outlook

On Sun, Dec 6, 2015 at 10:39 PM -0800, "Todd Fiala" <todd.fiala@gmail.com> wrote:

Hi Gage,

The REPL does let you import Swift modules. If you wanted to make or find a GTK binding, load it into the REPL, and drive that via the REPL, you certainly could do that. Using the REPL to do this would allow you to explore the binding at runtime, as many REPL-based languages afford. Is that the kind of thing you're after?

The last comment makes me think you may be asking more about a graphical REPL, though. Xcode has Playgrounds, but that doesn't exist in Open Source Swift. I don't see what would stop somebody from trying to write something similar against GTK or any other GUI library.

Hope that helps!

-Todd

On Sun, Dec 6, 2015 at 6:12 PM, Gage Morgan <gagemorgan@outlook.com> wrote:
> The Swift-specific parts (i.e. any files not in the llvm.org LLDB source base) are > available according to the license as specified at swift.org. I would direct you to > those licenses to see if they are compatible with your desired usage.

Let me rephrase that, I think that was a response to asking what Apple says you can or cannot do with REPL. I meant "Has Apple stated possible uses for REPL other than from the CLI-only interface?"

I'm looking to develop GUIs with it, but am unsure how.

Thanks,
--MGage--

Sent from Outlook

_____________________________
From: Todd Fiala via swift-lldb-dev <swift-lldb-dev@swift.org>
Sent: Saturday, December 5, 2015 7:33 PM
Subject: [swift-lldb-dev] REPL questions
To: <swift-lldb-dev@swift.org>

Hi all,

Thanks for the questions on the REPL.

With respect to incorporating a REPL into another program, the text-based Swift REPL is available in and implemented via LLDB. As Swift LLDB is implemented on top of LLDB, there are two projects involved with regards to the source. The source code for the core of LLDB (as available via llvm.org) is available according to the terms of the license as spelled out at llvm.org. The Swift-specific parts (i.e. any files not in the llvm.org LLDB source base) are available according to the license as specified at swift.org. I would direct you to those licenses to see if they are compatible with your desired usage.

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

--
-Todd

_______________________________________________
swift-lldb-dev mailing list
swift-lldb-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-lldb-dev


(Perry E. Metzger) #9

The Swift REPL works by injecting code into a separate Swift
process.

[...]

Thanks for this and the rest of the technical information you've
provided here. It is quite useful.

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.

"Interpreting" can be read as "executing user provided extension
language source code at run time". A JIT is just as useful for this
purpose as a "true" interpreter (whatever that might be).

I presume questions about the JIT stuff in the LLDB codebase should go
to this list?

Hope that helps!

It is very helpful! Thank you!

Perry

···

On Mon, 07 Dec 2015 08:29:39 -0800 Todd Fiala <tfiala@apple.com> wrote:
--
Perry E. Metzger perry@piermont.com