[swift-corelibs-dev] Better integration with UNIX tools

[Nick Keets]

In that case I think the discussion is kind of moot, scripts are
fundamentally different than apps, being terse is important and almost
always you want to block.

If better scripting support is a non-goal for Foundation then `Process` is
mostly fine as it is. My only wish would be to somehow make it easier to
read and write `Data` to stdin/stdout/stderr.


On Tue, Nov 28, 2017 at 11:30 PM, Tony Parker <anthony.parker at apple.com>
wrote:

> Of course, Foundation API has no way of distinguishing if the caller is
> considered a script or not.
>
> If the API is a bad idea for other kinds of apps then we simply wouldn’t
> add it. So, I think this proposed convenience API needs to consider all of
> the varied clients of Foundation.
>
> - Tony
>
>
> On Nov 28, 2017, at 12:24 PM, Brent Royal-Gordon <brent at architechies.com>
> wrote:
>
> On Nov 28, 2017, at 8:00 AM, Tony Parker <anthony.parker at apple.com> wrote:
>
> Why does it imply a run loop rather than one of many multithreading
> possibilities (dispatch queue, starting one more thread, etc)? And even if
> it did use run loops, why is that a problem?
>
>
> The problem is simply that we're discussing using this feature in Swift
> *scripts*. Swift scripts don't typically invoke `RunLoop.run()` or
> `dispatch_main()`, and without changing the way they generate main()
> functions to intrinsically do so (and then schedule main.swift's body on
> the main runloop/queue), I don't see a good way for it to do so. So an
> async API would be inconvenient to use from a Swift script.
>
> --
> Brent Royal-Gordon
> Architechies
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20171130/d8300866/attachment.html>