Re: [swift-evolution] [Proposal] Random Unification

[Susan Cheng via swift-evolution]

Hello,

I have an implementation for reference
https://github.com/SusanDoggie/Doggie/blob/master/Sources/Doggie/Foundation/Random.swift

It's easy to remind that what's the range of random floating point number

Double.random(includeOne: true)
Double.random(includeOne: false)

2017-09-09 0:52 GMT+08:00 Alejandro Alonso via swift-evolution
:
> Hello swift evolution, I would like to propose a unified approach to
> `random()` in Swift. I have a simple implementation here
> https://gist.github.com/Azoy/5d294148c8b97d20b96ee64f434bb4f5. This
> implementation is a simple wrapper over existing random functions so
> existing code bases will not be affected. Also, this approach introduces a
> new random feature for Linux users that give them access to upper bounds, as
> well as a lower bound for both Glibc and Darwin users. This change would be
> implemented within Foundation.
>
> I believe this simple change could have a very positive impact on new
> developers learning Swift and experienced developers being able to write
> single random declarations.
>
> I’d like to hear about your ideas on this proposal, or any implementation
> changes if need be.
>
> - Alejando
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Concurrency] async/await + actors

[Howard Lovatt via swift-evolution]

Not really certain what async/await adds, using this library (note self
promotion) which is built on top of GCD:

https://github.com/hlovatt/Concurrency-Utilities


You can write:

func doit() {
AsynchronousFuture { // Executes in background and therefore does
not block main
let dataResource  = loadWebResource("dataprofile.txt") //
Returns a future and therefore runs concurrently in background.
let imageResource = loadWebResource("imagedata.dat") // Future
therefore concurrent.
let imageTmp  = decodeImage(dataResource.get ??
defaultText, imageResource.get ?? defaultData) // Handles errors with
defaults easily, including timeout.
let imageResult   = dewarpAndCleanupImage(imageTmp)

Thread.executeOnMain {
self.imageResult = imageResult
}
}
}

So why bother with async/await?

PS I also agree with the comments that there is no point writing the 1st
two lines of the example with async and then calling them with await - you
might as well write serial code.

  -- Howard.

On 10 September 2017 at 10:33, Wallacy via swift-evolution <
swift-evolution@swift.org> wrote:

> This is the only part of the proposal that i can't concur!
>
> ^async^ at call side solve this nicely! And Pierre also showed how common
> people are doing it wrong! And will make this wrong using Futures too.
>
> func doit() async {
> let dataResource = async loadWebResource("dataprofile.txt”)
> let imageResource = async loadWebResource("imagedata.dat”)
> let imageTmp = await decodeImage(dataResource, imageResource)
> self.imageResult = await dewarpAndCleanupImage(imageTmp)
> }
>
> Anyway, we have time to think about it.
>
>
>
> Em sáb, 9 de set de 2017 às 20:30, David Hart via swift-evolution <
> swift-evolution@swift.org> escreveu:
>
>> On 10 Sep 2017, at 00:40, Kenny Leung via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Then isn’t the example functionally equivalent to:
>>
>> func doit() {
>> DispatchQueue.global().async {
>> let dataResource  = loadWebResource("dataprofile.txt")
>> let imageResource = loadWebResource("imagedata.dat")
>> let imageTmp  = decodeImage(dataResource, imageResource)
>> let imageResult   = dewarpAndCleanupImage(imageTmp)
>> DispatchQueue.main.async {
>> self.imageResult = imageResult
>> }
>> }
>> }
>>
>> if all of the API were synchronous? Why wouldn’t we just exhort people to
>> write synchronous API code and continue using libdispatch? What am I
>> missing?
>>
>>
>> There are probably very good optimisations for going asynchronous, but
>> I’m not the right person for that part of the answer.
>>
>> But I can give another answer: once we have an async/await pattern, we
>> can build Futures/Promises on top of them and then we can await on multiple
>> asynchronous calls in parallel. But it won’t be a feature of async/await in
>> itself:
>>
>> func doit() async {
>> let dataResource  = Future({ loadWebResource("dataprofile.txt”) })
>> let imageResource = Future({ loadWebResource("imagedata.dat”) })
>> let imageTmp = await decodeImage(dataResource.get, imageResource.get)
>> self.imageResult = await dewarpAndCleanupImage(imageTmp)
>> }
>>
>> -Kenny
>>
>>
>> On Sep 8, 2017, at 2:33 PM, David Hart  wrote:
>>
>>
>> On 8 Sep 2017, at 20:34, Kenny Leung via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Hi All.
>>
>> A point of clarification in this example:
>>
>> func loadWebResource(_ path: String) async -> Resourcefunc decodeImage(_ r1: 
>> Resource, _ r2: Resource) async -> Imagefunc dewarpAndCleanupImage(_ i : 
>> Image) async -> Image
>> func processImageData1() async -> Image {
>> let dataResource  = await loadWebResource("dataprofile.txt")
>> let imageResource = await loadWebResource("imagedata.dat")
>> let imageTmp  = await decodeImage(dataResource, imageResource)
>> let imageResult   = await dewarpAndCleanupImage(imageTmp)
>> return imageResult
>> }
>>
>>
>> Do these:
>>
>> await loadWebResource("dataprofile.txt")
>>
>> await loadWebResource("imagedata.dat")
>>
>>
>> happen in in parallel?
>>
>>
>> They don’t happen in parallel.
>>
>> If so, how can I make the second one wait on the first one? If not, how
>> can I make them go in parallel?
>>
>> Thanks!
>>
>> -Kenny
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
> 

Re: [swift-evolution] [Concurrency] async/await + actors

[Thorsten Seitz via swift-evolution]

First off, I’m still catching up with all those (very welcome :-) threads about 
concurrency, so bear with me if I’m commenting on topics that have been settled 
in the meantime.


> Am 18.08.2017 um 17:13 schrieb Johannes Weiß via swift-evolution 
> :
> 
> Hi Chris & swift-evo,
> 
> (Given the already lengthy thread I tried to separate my points and keep them 
> reasonably short to allow people to skip points they don't care about. I'm 
> very happy to expand on the points.)
> 
> Thanks very much for writing up your thoughts/proposal, I've been waiting to 
> see the official kick-off for the concurrency discussions :).
> 
> I) Let's start with the async/await proposal. Personally I think this is the 
> right direction for Swift given the reality that we need to interface with 
> incredibly large existing code-bases and APIs. Further thoughts:
> 
> - ❓ GCD: dispatching onto calling queue, how?
> GCD doesn't actually allow you to dispatch back to the original queue, so I 
> find it unclear how you'd achieve that. IMHO the main reason is that 
> conceptually at a given time you can be on more than one queue (nested 
> q.sync{}/target queues). So which is 'the' current queue?
> 
> - ⊥ first class coroutine model => async & throws should be orthogonal
> given that the proposal pitches to be the beginning of a first class 
> coroutine model (which I think is great), I think `async` and `throws` do 
> need to be two orthogonal concepts. I wouldn't want automatically throwing 
> generators in the future ;). Also I think we shouldn't throw spanner in the 
> works of people who do like to use Result types to hold the errors or 
> values. I'd be fine with async(nothrow) or something though.

I, too, would like to keep async & throws orthogonal for these reasons. Even in 
the case of async meaning asynchronous or parallel execution I would expect 
that throwing is not implied as long as we are not using distributed execution 
or making things cancellable. As long as I am on the same machine just 
executing something in parallel on another CPU (but within the same runtime) 
does not make it failable, does it?


> - what do we do with functions that invoke their closure multiple times? Like 
> DispatchIO.read/write.
> 
> 
> II) the actor model part
> 
> -  Erlang runtime and the actor model go hand in hand 
> I really like the Erlang actor model but I don't think it can be separated 
> from Erlang's runtime. The runtime offers green threads (which allow an actor 
> to block without blocking an OS thread) and prevents you from sharing memory 
> (which makes it possible to kill any actor at any point and still have a 
> reliable system). I don't see these two things happening in Swift. To a 
> lesser extend these issues are also present in Scala/Akka, the mitigate some 
> of the problems by having Akka Streams. Akka Streams are important to 
> establish back-pressure if you have faster producers than consumers. Note 
> that we often can't control the producer, they might be on the other side of 
> a network connection. So it's often very important to not read the available 
> bytes to communicate to the kernel that we can't consumes bytes that fast. If 
> we're networking with TCP the kernel can then use the TCP flow-control to 
> signal to the other side that they better slow down (or else packets will be 
> dropped and then need to be resent later).
> 
> -  regarding fatal failure in actors
> in the server world we need to be able to accept hundreds of thousands 
> (millions) of connections at the same time. There are quite a few cases where 
> these connections are long-lived and paused for most of the the time. So I 
> don't really see the value in introducing a 'reliable' actor model where the 
> system stops accepting new connections if one actor fatalError'd and then 
> 'just' finishes up serving the existing connections. So I believe there are 
> only two possible routes: 1) treat it like C/C++ and make sure your code 
> doesn't fatalError or the whole process blows up (what we have right now) 2) 
> treat it like Erlang and let things die. IMHO Erlang wouldn't be successful 
> if actors couldn't just die or couldn't be linked. Linking propagates 
> failures to all linked processes. A common thing to do is to 1) spawn a new 
> actor 2) link yourself to the newly spawned actor 3) send a message to that 
> actor and at some point eventually await a reply message sent by the actor 
> spawned earlier. As you mentioned in the writeup it is a problem if the actor 
> doesn't actually reply which is why in Erlang you'd link them. The effect is 
> that if the actor we spawned dies, any linked actor will die too which will 
> the propagate the error to an appropriate place. That allows the programmer 
> to control where an error should propagate too. I realise I'm doing a poor 
> job in explaining what is best explained by documentation around Erlang: 
> supervision [1] and the 

Re: [swift-evolution] [Concurrency] async/await + actors

[Thorsten Seitz via swift-evolution]

> Am 21.08.2017 um 22:09 schrieb Karim Nassar via swift-evolution 
> :
> 
> Thought about it in more depth, and I’m now firmly in the camp of: 
> ‘throws’/‘try' and ‘async’/‘await' should be orthogonal features. I think the 
> slight call-site reduction in typed characters ('try await’ vs ‘await’) is 
> heavily outweighed by the loss of clarity on all the edge cases.

+1

-Thorsten


> 
> —Karim
> 
>> On Aug 21, 2017, at 1:56 PM, John McCall > > wrote:
>> 
>>> 
>>> On Aug 20, 2017, at 3:56 PM, Yuta Koshizawa >> > wrote:
>>> 
>>> 2017-08-21 2:20 GMT+09:00 John McCall via swift-evolution 
>>> >:
 On Aug 19, 2017, at 7:17 PM, Chris Lattner via swift-evolution 
 > wrote:
> On Aug 19, 2017, at 8:14 AM, Karim Nassar via swift-evolution 
> > wrote:
> 
> This looks fantastic. Can’t wait (heh) for async/await to land, and the 
> Actors pattern looks really compelling.
> 
> One thought that occurred to me reading through the section of the 
> "async/await" proposal on whether async implies throws:
> 
> If ‘async' implies ‘throws' and therefore ‘await' implies ‘try’, if we 
> want to suppress the catch block with ?/!, does that mean we do it on the 
> ‘await’ ? 
> 
> guard let foo = await? getAFoo() else {  …  }
 
 Interesting question, I’d lean towards “no, we don’t want await? and 
 await!”.  My sense is that the try? and try! forms are only occasionally 
 used, and await? implies heavily that the optional behavior has something 
 to do with the async, not with the try.  I think it would be ok to have to 
 write “try? await foo()” in the case that you’d want the thrown error to 
 turn into an optional.  That would be nice and explicit.
>>> 
>>> try? and try! are quite common from what I've seen.
>>> 
>>> As analogous to `throws` and `try`, I think we have an option that `await!` 
>>> means blocking.
>>> 
>>> First, if we introduce something like `do/catch` for `async/await`, I think 
>>> it should be for blocking. For example:
>>> 
>>> ```
>>> do {
>>>   return await foo()
>>> } block
>>> ```
>>> 
>>> It is consistent with `do/try/catch` because it should allow to return a 
>>> value from inside `do` blocks for an analogy of `throws/try`.
>>> 
>>> ```
>>> // `throws/try`
>>> func foo() -> Int {
>>>   do {
>>> return try bar()
>>>   } catch {
>>> ...
>>>   }
>>> }
>>> 
>>> // `async/await`
>>> func foo() -> Int {
>>>   do {
>>> return await bar()
>>>   } block
>>> }
>>> ```
>>> 
>>> And `try!` is similar to `do/try/catch`.
>>> 
>>> ```
>>> // `try!`
>>> let x = try! foo()
>>> // uses `x` here
>>> 
>>> // `do/try/catch`
>>> do {
>>>   let x = try foo()
>>>   // uses `x` here
>>> } catch {
>>>   fatalError()
>>> }
>>> ```
>>> 
>>> If `try!` is a sugar of `do/try/catch`, it also seems natural that `await!` 
>>> is a sugar of `do/await/block`. However, currently all `!` in Swift are 
>>> related to a logic failure. So I think using `!` for blocking is not so 
>>> natural in point of view of symbology.
>>> 
>>> Anyway, I think it is valuable to think about what `do` blocks for 
>>> `async/await` mean. It is also interesting that thinking about combinations 
>>> of `catch` and `block` for `async throws` functions: e.g. If only `block`, 
>>> the enclosing function should be `throws`.
>> 
>> Personally, I think these sources of confusion are a good reason to keep the 
>> feature separate.
>> 
>> The idea of using await! to block a thread is interesting but, as you say, 
>> does not fit with the general meaning of ! for logic errors.  I think it's 
>> fine to just have an API to block waiting for an async operation, and we can 
>> choose the name carefully to call out the danger of deadlocks.
>> 
>> John.
>> 
>>> 
>>> That aside, I think `try!` is not so occasional and is so important. Static 
>>> typing has limitations. For example, even if we has a text field which 
>>> allows to input only numbers, we still get an input value as a string and 
>>> parsing it may fail on its type though it actually never fails. If we did 
>>> not have easy ways to convert such a simple domain error or a recoverable 
>>> error to a logic failure, people would start ignoring them as we has seen 
>>> in Java by `catch(Exception e) {}`. Now we have `JSONDecoder` and we will 
>>> see much more `try!` for bundled JSON files in apps or generated JSONs by 
>>> code, for which decoding fails as a logic failure.
>>> 
>>> --
>>> Yuta
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution