1658052360
FutureKit: A Swift based Future/Promises Library for IOS and OS X
FutureKit for Swift
A Swift based Future/Promises Library for IOS and OS X.
Note - The latest FutureKit is works 3.0
For Swift 2.x compatibility use version 2.3.0
FutureKit is a Swift implementation of Futures and Promises, but modified specifically for iOS/OSX programmers. You can ready the wikipedia article here: http://en.wikipedia.org/wiki/Futures_and_promises
FutureKit uses Swift generic classes, to allow you to easily deal with asynchronous/multi-threaded issues when coding for iOS or OSX.
- is 100% Swift. It currently supports Swift 2.x/3.0 and Xcode 8+. For Swift 2.x compatibility, use the version 2.3.0.
- is type safe. It uses Swift Generics classes that can automatically infer the type you wish to return from asynchronous logic. And supports both value and reference Swift types (Both 'Any' types, and 'AnyObject/NSObject' types.)
- Is Swift error handling friendly. All FutureKit handler methods can already catch and complete a Future using any ErrorType. So you don't need to wrap your code with 'do/try/catch'.
- FutureKit in Swift is designed to simplify error handling, allowing you to attach a single error handler that can catch any error that may occur. This can make dealing with composing async operations much easier and more reliable.
- uses simple to understand methods (onComplete/onSuccess/onFail etc) that let's you simplify complex asynchronous operations into clear and simple to understand logic.
- is highly composeable, since any existing Future can be used to generate a new Future. And Errors and Cancelations can be automatically passed through, simplifying error handling logic.
- Super easy cancelation composition (which is a fancy way to say cancel works when you want it to automatically). Future's are designed so there is never any confusion about whether an asynchronous operation completed, failed, or was canceled. And the consumer has full control over whether he needs to be notified that the operation was canceled or not. (0% confusion about whether your completion blocks will get called when the operation is cancelled).
- works well editing code within Xcode auto-completion. The combination of type-inference and code-completion makes FutureKit coding fast and easy.
- simplifies the use of Apple GCD by using Executors - a simple Swift enumeration that simplifies the most common iOS/OSX Dispatch Queues (Main,Default,Background, etc). Allowing you to guarantee that logic will always be executed in the context you want. (You never have to worry about having to call the correct dispatch_async() function again).
- is highly tunable, allowing you to configure how the primary Executors (Immediate vs Async) execute, and what sort Thread Synchronization FutureKit will use (Barriers - Locks, etc). Allowing you to tune FutureKit's logic to match what you need.
What the Heck is a Future?
So the simple answer is that Future is an object that represents that you will get something in the future. Usually from another process possible running in another thread. Or maybe a resource that needs to loaded from an external server.
let imageView : UIImageView = // some view on my view controller.
let imageFuture : Future<UIImage> = MyApiClass().getAnImageFromServer()There are few things that are interesting. This object represents both that an image will arrive, and it will give me universal way to handle failures and cancellation. It could be that MyApiClass() is using NSURLSessions, or AlamoFire, combined with some kinda cool image cache based on SDWebImage. But this viewController doesn't care. Just give me a Future<UIImage>. Somehow.
now I can do this:
imageFuture.onSuccess(.Main) { image in
imageView.image = image
}This is a quick way of saying "when it's done, on the MainQ, set the image to an ImageView.
Let's make things more interesting. Now your designer tell you he wants you to add a weird Blur effect to the image. Which means you have to add an UIImage effect. Which you better not do compute in the MainQ cause it's mildly expensive.
So know you have two asynchronous dependencies, one async call for the network, and another for the blur effect. In traditional iOS that would involve a lot of custom block handlers for different API, and handling dispatch_async calls.
Instead we are gonna do this.
let imageFuture : Future<UIImage> = MyApiClass().getAnImageFromServer()
let blurImageFuture = imageFuture.onSuccess(.UserInitiated) { (image) -> UIImage in
let blurredImage = doBlurEffect(image)
return blurredImage
}blurrImageFuture is now a NEW Future. That I have created from imageFuture. I also defined I want that block to run in the .UserInitiated dispatch queue. (Cause I need it fast!).
blurImageFuture.onSuccess(.Main) { (blurredImage) -> Void in
imageView.image = blurredImage;
}Or I could rewite it all in one line:
MyApiClass().getAnImageFromServer()
.onSuccess(.UserInitiated) { (image) -> UIImage in {
let blurredImage = doBlurEffect(image)
return blurredImage
}.onSuccess(.Main) { (blurredImage) -> Void in
imageView.image = blurredImage;
}.onError { error in
// deal with any error that happened along the way
}That's the QUICK 1 minute answer of what this can do. It let's you take any asynchronous operation and "map" it into a new one. So you can take all your APIs and background logic and get them to easily conform to a universal way of interacting. Which can let you get away with a LOT of crazy asynchronous execution, without giving up stability and ease of understanding.
Plus it's all type safe. You could use handler to convert say, an Future<NSData> from your API server into a Future<[NSObject:AnyObject]> holding the JSON. And than map that to a Future<MyDatabaseEntity> after it's written to a database.
It's a neat way to stitch all your Asynchronous issues around a small set of classes.
Then what is a Promise?
A promise is a way for you write functions that returns Futures.
func getAnImageFromServer(url : NSURL) -> Future<UIImage> {
let p = Promise<UIImage>()
dispatch_async(...) {
// do some crazy logic, or go to the internet and get a UIImageView. Check some Image Caches.
let i = UIImage()
p.completeWithSuccess(i)
}
return p.future
}A Promise is a promise to send something back a value (of type T) in the future. When it's ready.. A Promise has to be completed with either Success/Fail or Cancelled. Don't break your promises! Always complete them. And everyone will be happy. Especially your code that is waiting for things.
But it also means the API doesn't really need to bake a whole bunch of custom callback block handlers that return results. And worry about what dispatch_queue those callback handlers have to running in. Do you dispatch to mainQ before you call your callback handlers? Or after? Nobody seems to agree.
But the Future object already offers a lot of cool built ways to get told when data is ready and when it fails. And can handle which GCD queue is required for this reply.
The api just has to emit what he promised. The Future will take care of getting it to the consumer.
And since Futures can be composed from Futures, and Futures can be used to complete Promises, it's easy to integrate a number of complex Async services into a single reliable Future. Mixing things like network calls, NSCache checks, database calls.
It also "inverts" the existing dispatch_async() logic. Where first you call dispatch_async(some_custom_queue) and THEN you call some api call to start it working.
func oldwayToGetStuff(callback:(NSData) -> Void) {
dispatch_async(StuffMaker().custom_queue_for_stuff) {
// do stuff to make your NSData
let d = StuffMaker().iBuildStuff()
dispatch_async(dispatch_get_main()) {
callback(d)
}
}
}notice how I forgot to add error handling in that callback. What if iBuildStuff() times out? do I add more properties to the callback block? add more blocks? Every API wants to do it different and every choice makes my code less and less flexible.
class StuffMaker {
func iBuildStuffWithFutures() -> Future<NSData> {
let p = Promise<NSData>()
dispatch_async(self.mycustomqueue) {
// do stuff to make your NSData
if (SUCCESS) {
let goodStuff = NSData()
p.completeWithSuccess(goodStuff)
}
else {
p.completeWithFail(NSError())
}
}
return p.future()
}
}Notice we are now calling StuffMaker() directly, without having to dispatch first. And I'm not calling dispatch_async() AGAIN before I call the callback block. I will let the consumer of the Future decide where he wants his handlers to run.
Now you 100% guarantee that the code you want will ALWAYS run in the dispatch_queue you want. It just returns a Future object.
Documentation
FutureKit documentation is being written as Xcode Playgrounds. The best way to start is to open the FutureKit.workspace and then opening the Playground inside. (If you open the Playgrounds outside of the workspace, then FutureKit module may not import correctly). The Xcode Playgrounds probably require Xcode 6.3 (in order to see the Markup correctly)
Author: FutureKit
Source Code: https://github.com/FutureKit/FutureKit
License: MIT license
What is GEEK
Buddha Community
1665369120
CellularAutomata.jl: Cellular Automata Simulation toolkit for Julia
Cellular Automata
A cellular automaton is a collection of "colored" cells on a grid of specified shape that evolves through a number of discrete time steps according to a set of rules based on the states of neighboring cells. The rules are then applied iteratively for as many time steps as desired.
mathworld.wolfram.com/CellularAutomaton
Elementary CA
To generate an elementary cellular automaton, use
ca = CellularAutomaton(rule, init, gen)
where rule is the Wolfram code (integer), init is a vector containing the initial starting condition and gen is the number of generations to be computed. For a single starting cell in the middle just omit the init vector.
To generate 15 generations of elementary cellular automaton of rule 90 use
using CellularAutomata
ca90 = CellularAutomaton(90, 16)
#
# #
# #
# # # #
# #
# # # #
# # # #
# # # # # # # #
# #
# # # #
# # # #
# # # # # # # #
# # # #
# # # # # # # #
# # # # # # # #
# # # # # # # # # # # # # # # #
Totalistic CA
For a more complex cellular automaton you can change the number of states k the cell can be and the radius r of neighbors that can influence the states. If k is changed to be larger than 2, a totalistic CA is computed where only the average value of all neighbors count. This can be done like this
ca = CellularAutomaton(993, 15, k=3)
X
XXX
X# #X
X X
XXX XXX
X# #X X# #X
X # X
XXX ### XXX
X# #X # X # X# #X
X # X # X
XXX ## X ## XXX
X# #X # X # X# #X
X X### XXX ###X X
XXX X XX # # XX X XXX
X# #X XX###X## ##X###XX X# #X
2 dimensional CAs
Two dimensional cellular automaton (like Conway's Game of Life) can be created by
ca = CA2d(B, S, init, gen)
where B and S are vectors that have the numbers of neighboring cells that define when cell is born or survives, init (matrix) is the initial starting condition and gen is the number of generations the CA is to be computed.
Game of life is then run for 9 generations for e.g. a turbine pattern by typing
ca = CA2d([3], [2, 3], init, 9)
1st step
###### ##
###### ##
##
## ##
## ##
## ##
##
## ######
## ######
2nd
####
# # ##
# # #
## #
## # #
# # # #
# # ##
# ##
# # #
## # #
####
3rd
##
####
# ## ## #
## #
## ## ###
#### # ###
# # # #
### # ####
### ## ##
# ##
# ## ## #
####
##
4th
# #
#
##
# ## #
# # #
# # ###
# #
### # #
# # #
# ## #
##
#
# #
5th
##
#
### ##
### # #
# # ##
# #
## # #
# # ###
## ###
#
##
6th
##
#
# # ##
# # ### #
# ######
## ##
###### #
# ### # #
## # #
#
##
7th
# # #
## # ###
# #
## #
# ##
# #
### # ##
# # #
8th
## ## #
## ## ##
#
##
## ##
##
#
## ## ##
# ## ##
9th
###### ##
###### ##
##
## ##
## ##
## ##
##
## ######
## ######
Running Tests
To run tests, execute the following command from the root folder of the repository:
julia tests/run_tests.jlDownload Details:
Author: Natj
Source Code: https://github.com/natj/CellularAutomata.jl
License: MIT license
1658052360
FutureKit: A Swift based Future/Promises Library for IOS and OS X
FutureKit for Swift
A Swift based Future/Promises Library for IOS and OS X.
Note - The latest FutureKit is works 3.0
For Swift 2.x compatibility use version 2.3.0
FutureKit is a Swift implementation of Futures and Promises, but modified specifically for iOS/OSX programmers. You can ready the wikipedia article here: http://en.wikipedia.org/wiki/Futures_and_promises
FutureKit uses Swift generic classes, to allow you to easily deal with asynchronous/multi-threaded issues when coding for iOS or OSX.
- is 100% Swift. It currently supports Swift 2.x/3.0 and Xcode 8+. For Swift 2.x compatibility, use the version 2.3.0.
- is type safe. It uses Swift Generics classes that can automatically infer the type you wish to return from asynchronous logic. And supports both value and reference Swift types (Both 'Any' types, and 'AnyObject/NSObject' types.)
- Is Swift error handling friendly. All FutureKit handler methods can already catch and complete a Future using any ErrorType. So you don't need to wrap your code with 'do/try/catch'.
- FutureKit in Swift is designed to simplify error handling, allowing you to attach a single error handler that can catch any error that may occur. This can make dealing with composing async operations much easier and more reliable.
- uses simple to understand methods (onComplete/onSuccess/onFail etc) that let's you simplify complex asynchronous operations into clear and simple to understand logic.
- is highly composeable, since any existing Future can be used to generate a new Future. And Errors and Cancelations can be automatically passed through, simplifying error handling logic.
- Super easy cancelation composition (which is a fancy way to say cancel works when you want it to automatically). Future's are designed so there is never any confusion about whether an asynchronous operation completed, failed, or was canceled. And the consumer has full control over whether he needs to be notified that the operation was canceled or not. (0% confusion about whether your completion blocks will get called when the operation is cancelled).
- works well editing code within Xcode auto-completion. The combination of type-inference and code-completion makes FutureKit coding fast and easy.
- simplifies the use of Apple GCD by using Executors - a simple Swift enumeration that simplifies the most common iOS/OSX Dispatch Queues (Main,Default,Background, etc). Allowing you to guarantee that logic will always be executed in the context you want. (You never have to worry about having to call the correct dispatch_async() function again).
- is highly tunable, allowing you to configure how the primary Executors (Immediate vs Async) execute, and what sort Thread Synchronization FutureKit will use (Barriers - Locks, etc). Allowing you to tune FutureKit's logic to match what you need.
What the Heck is a Future?
So the simple answer is that Future is an object that represents that you will get something in the future. Usually from another process possible running in another thread. Or maybe a resource that needs to loaded from an external server.
let imageView : UIImageView = // some view on my view controller.
let imageFuture : Future<UIImage> = MyApiClass().getAnImageFromServer()There are few things that are interesting. This object represents both that an image will arrive, and it will give me universal way to handle failures and cancellation. It could be that MyApiClass() is using NSURLSessions, or AlamoFire, combined with some kinda cool image cache based on SDWebImage. But this viewController doesn't care. Just give me a Future<UIImage>. Somehow.
now I can do this:
imageFuture.onSuccess(.Main) { image in
imageView.image = image
}This is a quick way of saying "when it's done, on the MainQ, set the image to an ImageView.
Let's make things more interesting. Now your designer tell you he wants you to add a weird Blur effect to the image. Which means you have to add an UIImage effect. Which you better not do compute in the MainQ cause it's mildly expensive.
So know you have two asynchronous dependencies, one async call for the network, and another for the blur effect. In traditional iOS that would involve a lot of custom block handlers for different API, and handling dispatch_async calls.
Instead we are gonna do this.
let imageFuture : Future<UIImage> = MyApiClass().getAnImageFromServer()
let blurImageFuture = imageFuture.onSuccess(.UserInitiated) { (image) -> UIImage in
let blurredImage = doBlurEffect(image)
return blurredImage
}blurrImageFuture is now a NEW Future. That I have created from imageFuture. I also defined I want that block to run in the .UserInitiated dispatch queue. (Cause I need it fast!).
blurImageFuture.onSuccess(.Main) { (blurredImage) -> Void in
imageView.image = blurredImage;
}Or I could rewite it all in one line:
MyApiClass().getAnImageFromServer()
.onSuccess(.UserInitiated) { (image) -> UIImage in {
let blurredImage = doBlurEffect(image)
return blurredImage
}.onSuccess(.Main) { (blurredImage) -> Void in
imageView.image = blurredImage;
}.onError { error in
// deal with any error that happened along the way
}That's the QUICK 1 minute answer of what this can do. It let's you take any asynchronous operation and "map" it into a new one. So you can take all your APIs and background logic and get them to easily conform to a universal way of interacting. Which can let you get away with a LOT of crazy asynchronous execution, without giving up stability and ease of understanding.
Plus it's all type safe. You could use handler to convert say, an Future<NSData> from your API server into a Future<[NSObject:AnyObject]> holding the JSON. And than map that to a Future<MyDatabaseEntity> after it's written to a database.
It's a neat way to stitch all your Asynchronous issues around a small set of classes.
Then what is a Promise?
A promise is a way for you write functions that returns Futures.
func getAnImageFromServer(url : NSURL) -> Future<UIImage> {
let p = Promise<UIImage>()
dispatch_async(...) {
// do some crazy logic, or go to the internet and get a UIImageView. Check some Image Caches.
let i = UIImage()
p.completeWithSuccess(i)
}
return p.future
}A Promise is a promise to send something back a value (of type T) in the future. When it's ready.. A Promise has to be completed with either Success/Fail or Cancelled. Don't break your promises! Always complete them. And everyone will be happy. Especially your code that is waiting for things.
But it also means the API doesn't really need to bake a whole bunch of custom callback block handlers that return results. And worry about what dispatch_queue those callback handlers have to running in. Do you dispatch to mainQ before you call your callback handlers? Or after? Nobody seems to agree.
But the Future object already offers a lot of cool built ways to get told when data is ready and when it fails. And can handle which GCD queue is required for this reply.
The api just has to emit what he promised. The Future will take care of getting it to the consumer.
And since Futures can be composed from Futures, and Futures can be used to complete Promises, it's easy to integrate a number of complex Async services into a single reliable Future. Mixing things like network calls, NSCache checks, database calls.
It also "inverts" the existing dispatch_async() logic. Where first you call dispatch_async(some_custom_queue) and THEN you call some api call to start it working.
func oldwayToGetStuff(callback:(NSData) -> Void) {
dispatch_async(StuffMaker().custom_queue_for_stuff) {
// do stuff to make your NSData
let d = StuffMaker().iBuildStuff()
dispatch_async(dispatch_get_main()) {
callback(d)
}
}
}notice how I forgot to add error handling in that callback. What if iBuildStuff() times out? do I add more properties to the callback block? add more blocks? Every API wants to do it different and every choice makes my code less and less flexible.
class StuffMaker {
func iBuildStuffWithFutures() -> Future<NSData> {
let p = Promise<NSData>()
dispatch_async(self.mycustomqueue) {
// do stuff to make your NSData
if (SUCCESS) {
let goodStuff = NSData()
p.completeWithSuccess(goodStuff)
}
else {
p.completeWithFail(NSError())
}
}
return p.future()
}
}Notice we are now calling StuffMaker() directly, without having to dispatch first. And I'm not calling dispatch_async() AGAIN before I call the callback block. I will let the consumer of the Future decide where he wants his handlers to run.
Now you 100% guarantee that the code you want will ALWAYS run in the dispatch_queue you want. It just returns a Future object.
Documentation
FutureKit documentation is being written as Xcode Playgrounds. The best way to start is to open the FutureKit.workspace and then opening the Playground inside. (If you open the Playgrounds outside of the workspace, then FutureKit module may not import correctly). The Xcode Playgrounds probably require Xcode 6.3 (in order to see the Markup correctly)
Author: FutureKit
Source Code: https://github.com/FutureKit/FutureKit
License: MIT license
1616839708
Best Swift iOS App Development Company in USA & India
Are you looking for the best swift iOS App Development Company in USA & India? We at AppClues Infotech is one of the leading Swift iOS App development company that help to build Innovative, Secure & high-performance mobile app with modern features & technology.
For more info:
Website: https://www.appcluesinfotech.com/
Email: info@appcluesinfotech.com
Call: +1-978-309-9910
#swift ios app development company in usa & india #swift ios app development company in usa #hire swift ios app developers in usa #top swift ios app development company #best swift ios app development company in usa #app development company in usa & india
1612441441
Hire Expert Swift iOS App Developers in USA
Are you looking to hire the best swift iOS developers for your iPhone or iPad App project? AppClues Infotech is a top-rated iOS app development company in the USA. Hire our dedicated swift iOS app developers to build feature-rich and robust iOS app.
For more info:
Website: https://www.appcluesinfotech.com/
Email: info@appcluesinfotech.com
Call: +1-978-309-9910
#top swift app development company usa #best swift app development company #swift app development #swift ios app development #swift app development company #hire expert swift ios app developers in usa
1606455026
Top Swift iOS App Development Company in USA
Are you looking for a Top Swift iOS App Development Company in USA? AppClues Infotech is a top Swift iOS App Development Company in USA that offers cutting-edge services to businesses for their custom requirements. Hire Dedicated Swift iOS Mobile Apps Developer & Programmers from AppClues Infotech at an affordable cost.
For more info:
Website: https://www.appcluesinfotech.com/
Email: info@appcluesinfotech.com
Call: +1-978-309-9910
#top swift app development company usa #best swift app development company #swift app development #swift ios app development #swift app development company #best swift ios app development company in usa