Looking through some of them they are somewhat similar to the Foundation APIs,
but there are a few improvements that I think would make them more compelling
for generalized use. I don’t think that it is out of the question to perhaps
merge the two concepts and reduce to Foundation as the place t
> On Dec 1, 2017, at 6:28 AM, Ian Partridge via swift-corelibs-dev
> wrote:
>
> Hi Nick,
>
> You might be interested in the new Utility project that the Package
> Manager team have published. It has a bunch of Foundation-esque
> features including subprocess support, temporary file, progress
Hi Nick,
You might be interested in the new Utility project that the Package
Manager team have published. It has a bunch of Foundation-esque
features including subprocess support, temporary file, progress bars
and more.
There's a good blog post about it here:
https://www.hackingwithswift.com/art
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 Willia
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
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 i
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
> On Nov 28, 2017, at 8:00 AM, Tony Parker 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 usi
on behalf of William Dillon via
swift-corelibs-dev
Reply-To: William Dillon
Date: Friday, November 17, 2017 at 11:39 AM
To: Tony Parker
Cc: "swift-corelibs-dev@swift.org"
Subject: Re: [swift-corelibs-dev] Better integration with UNIX tools
I, to, have wished for such an API.
I think th
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?
In general we have been discouraging the use of synchronous and blocking API
for many years now. It’s conve
> On Nov 27, 2017, at 11:01 PM, Brent Royal-Gordon
> wrote:
>
> We aren't today
Sorry, this part of the sentence got mangled in editing. What I meant to say
is, script-style programs currently don't run under a runloop, so if this API
is being designed for scripting use, a completion handler
> On Nov 27, 2017, at 3:50 PM, Tony Parker via swift-corelibs-dev
> wrote:
>
> I was thinking of perhaps a completion handler version, with the expectation
> that once async/await style completions land it would be pretty easy to use
> in a kind of straight-line mechanism.
A completion handle
Hi Nick,
Thanks for this survey of other languages, it’s very useful.
I think if we were to add something, I would prefer to keep it simple. Just one
class method on Process which is a fairly straightforward wrapper of the other
functionality already there.
I was thinking of perhaps a completi
I cosign all of this. Nice work, Brent.
> On Nov 17, 2017, at 4:47 PM, Brent Royal-Gordon via swift-corelibs-dev
> wrote:
>
>> On Nov 17, 2017, at 11:34 AM, Tony Parker via swift-corelibs-dev
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>>
>> It does seem like there is a possibility of so
Looking at what Python (subprocess) and Go (os.exec) do, it looks like they
agree on the following:
- executable and arguments are merged in one array
- they don't require full path for the executable
- they don't expand tildes
- blocking calls are the default
- they are more explicit about st
> On Nov 19, 2017, at 7:01 PM, Abhi Beckert wrote:
>
> First of all, I disagree with Brent's assessment that we shouldn't have a
> variant that "simply shells out". Even though this use case is "discouraged"
> in other languages, I think in practice it definitely has a place.
If you really wan
> Any ideas on what form it would take? A class method on Process that
> returns the output, maybe?
I think there are two solutions, and I'd like to see both of them taken.
First of all, I disagree with Brent's assessment that we shouldn't
have a variant that "simply shells out". Even though this u
> On Nov 17, 2017, at 11:34 AM, Tony Parker via swift-corelibs-dev
> wrote:
>
> It does seem like there is a possibility of some better convenience API here.
>
> Any ideas on what form it would take? A class method on Process that returns
> the output, maybe?
`Process.run(_:arguments:terminat
I, to, have wished for such an API.
I think that would be a very welcome addition.
> On Nov 17, 2017, at 11:34 AM, Tony Parker via swift-corelibs-dev
> wrote:
>
> Hi Abhi,
>
> It does seem like there is a possibility of some better convenience API here.
>
> Any ideas on what form it would ta
Hi Abhi,
It does seem like there is a possibility of some better convenience API here.
Any ideas on what form it would take? A class method on Process that returns
the output, maybe?
- Tony
> On Nov 16, 2017, at 3:34 PM, Abhi Beckert via swift-corelibs-dev
> wrote:
>
> Swift is a great shel
20 matches
Mail list logo
