Why did we give up so easily? I did not say that scripting support is somehow a non-goal. In fact, it is exactly the opposite.
I do not believe that somehow API that is useful for scripts is mutually exclusive with API that is useful for apps. - Tony > On Nov 30, 2017, at 9:26 AM, Jacob Williams <ponybo...@gmail.com> wrote: > > Since this isn’t going to be coming to Foundation any time…ever, I’d take a > look at the SwiftShell framework. It makes running command line utilities > from swift pretty easy. Chaining outputs from previous commands into > subsequent commands is also rather simple. It’s based on Process but gives a > lot of sugar that may be useful for you. I’ve been using it in one of my > projects on an Ubuntu machine and it is easy to work with. > > https://github.com/kareman/SwiftShell <https://github.com/kareman/SwiftShell> > >> On Nov 30, 2017, at 1:43 AM, Nick Keets via swift-corelibs-dev >> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote: >> >> 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.par...@apple.com >> <mailto:anthony.par...@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 <br...@architechies.com >>> <mailto:br...@architechies.com>> wrote: >>> >>>> On Nov 28, 2017, at 8:00 AM, Tony Parker <anthony.par...@apple.com >>>> <mailto:anthony.par...@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 >>> >> >> >> _______________________________________________ >> swift-corelibs-dev mailing list >> swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev >
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
