[swift-build-dev] Feature request: Scripting support for Swift

[Jason Dusek]

For the interpreter, it's acceptable since it's got the debugger in there;
but for the scripting mode it's a real obstruction.

Keith Smiley <k at keith.so> schrieb am Mo. 20. Feb. 2017 um 11:25:

> A related issue that's worth mentioning is the overhead of running a
> Swift script in general. Here's the simplest of examples of Swift vs
> Python:
>
> ```
> $ cat helloworld
> print("Hello World")
>
> Cold:
>
> $ time swift helloworld
> Hello World
> swift helloworld  0.06s user 0.44s system 67% cpu 0.746 total
> $ time python helloworld
> Hello World
> python helloworld  0.01s user 0.01s system 22% cpu 0.095 total
>
> Warm:
>
> $ time swift helloworld
> Hello World
> swift helloworld  0.04s user 0.01s system 22% cpu 0.212 total
> $ time python helloworld
> Hello World
> python helloworld  0.02s user 0.01s system 84% cpu 0.035 total
> ```
>
> While we're thinking about this for scripting, I think it's tangentially
> related that the repl has a similar difference in overhead:
>
> ```
> $ time swift <<< ":quit"
> Welcome to Apple Swift version 3.0.2 (swiftlang-800.0.63
> clang-800.0.42.1). Type :help for assistance.
> swift <<< ":quit"  1.88s user 0.23s system 86% cpu 2.459 total
>
> $ time python <<< "quit()"
> python <<< "quit()"  0.01s user 0.01s system 81% cpu 0.030 total
> ```
>
>
> --
> Keith Smiley
>
> On 02/19, Jason Dusek via swift-build-dev wrote:
> > One issue with compiling the dependencies is that script startup would be
> > slow. Maybe there should be a per-user or system level cache? System
> level
> > is better from a disk usage perspective but some thought must be given to
> > security.
> >
> > With Ruby and Python, it is not expected that a script's dependencies are
> > installed when it is run but rather they have already been installed via
> > the package manager, although it does seem useful for single files to
> > contain all the relevant information.
> >
> > Here is another idea: a Swift script can be run from a project directory
> > with Sources/, Packages/, &c. In that environment, build products are
> > already cached. If the script is symlinked into /usr/local/bin/ it will
> be
> > on the path but xcrun will still be able to find the project. It is kind
> of
> > like a source-level .app bundle.
> >
> > Maxim Veksler via swift-build-dev <swift-build-dev at swift.org> schrieb am
> > Sa. 18. Feb. 2017 um 11:28:
> >
> > > Hi,
> > >
> > > Ayaka Nonaka gave a talk[1] about basic scripting[2] support in Swift.
> > >
> > > The gist of the idea is to use #!/usr/bin/env xcrun swift
> > >
> > > Therefor it seems the basic building blocks for allowing a swift file
> to
> > > "execute itself" are always laid out and proved to be applicable.
> > >
> > > What's missing IMHO is a better support for dependencies, the suggested
> > > solutions in the talk are using the -F for including frameworks that
> were
> > > built using Carthage or CocoaPods. That's not idle because a script I
> think
> > > should be self contained, meaning that you can "just run it" and it
> works.
> > >
> > > So, I'm wondering what if it was possible to include the dependencies
> > > inside the swift file itself? Probably using the same format as the
> > > Package.swift syntax. The the swift binary would "detect" that it's a
> self
> > > contained file, it could make this distinction because import
> > > PackageDescription is defined by the user.
> > >
> > > Then it would follow a 3 step process:
> > > 1. It should download and build the dependencies
> > > 2. then compile the code inside the file
> > > 3. and then run it.
> > >
> > > Having everything happening behind the scenes, so the "script user"
> simply
> > > calls ./MyScript.swift or swift MyScript.swift and it "just works".
> > >
> > > Wondering what the community thinks.
> > >
> > > [1] https://realm.io/news/swift-scripting/
> > > [2] https://github.com/ayanonagon/talks/tree/master/2015-swiftsummit/2
> > > _______________________________________________
> > > swift-build-dev mailing list
> > > swift-build-dev at swift.org
> > > https://lists.swift.org/mailman/listinfo/swift-build-dev
> > >
>
> > _______________________________________________
> > swift-build-dev mailing list
> > swift-build-dev at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-build-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20170220/7c9bd4b7/attachment.html>