profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/adam-fowler/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Adam Fowler adam-fowler https://opticalaberration.com/ Used to make video games, can't be arsed anymore

adam-fowler/mqtt-nio 56

A Swift NIO MQTT v3.1.1 and v5.0 Client

adam-fowler/jmespath.swift 27

Swift implementation of JMESPath, the JSON query language

adam-fowler/aws-signer-v4 12

Generate a signed URL or Request headers for submitting to Amazon Web Services.

adam-fowler/compress-nio 9

Compression/Decompression support for Swift NIO ByteBuffer

adam-fowler/s3-filesystem-kit 6

Swift File Manager for AWS S3

adam-fowler/sns-to-slack-lambda 5

Swift Lambda for publishing SNS messages to Slack

adam-fowler/EmCuTeeTee 2

iOS MQTT Client using MQTTNIO library

adam-fowler/ses-forwarder-lambda 2

Swift based SES email forwarding lambda

adam-fowler/dictionary-encoder 1

Swift Dictionary Encoder, based off the JSON Encoder in Foundation

adam-fowler/localstack-awscli 1

Use for testing localstack in a GH action

push eventsoto-project/soto-core

Adam Fowler

commit sha d9e34897534398acdfb8ed2e2ee971634426fb24

Use async/await versions of code when testing AsyncSequence

view details

push time in 13 hours

push eventsoto-project/soto-core

Adam Fowler

commit sha 849089c0ee9ecd037e1b8d5b58cda2668849c10f

Add checkCancellation before http request to AWS

view details

push time in 13 hours

push eventsoto-project/soto-core

push time in 17 hours

push eventsoto-project/soto-core

Adam Fowler

commit sha f476167cf4e1cd1fcbdaad10db32ed539fc200ba

kick off GH action

view details

push time in 17 hours

push eventsoto-project/soto-core

Adam Fowler

commit sha bf0c39854270958a82245b4f68197cc9ed334b90

comment

view details

push time in 17 hours

issue openedapple/swift-nio

Add a generic connection error for NIO

Currently NIOConnectionError is part of NIOPosix. If I am wanting to write a platform agnostic NIO package and respond to connection errors there is currently no way to do this without importing NIOPosix and then of course you are only responding to connection errors from NIOPosix.

Could we have a generic connection error that holds the original platform specific error . Something like (I know this is a name clash)

struct NIOConnectionError: Error {
    let error: Error
}

I'm guessing this would be a breaking change as functions would be throwing a new error type. Maybe something for NIO3.

created time in 18 hours

PR opened soto-project/soto-core

Add AWSPayload.asyncSequence

This adds AWSPayload.asyncSequence which allows you to provide an AsyncSequence of ByteBuffers to a request.

+106 -7

0 comment

5 changed files

pr created time in 18 hours

PR closed soto-project/soto-core

Async sequence `AWSPayload`

This adds AWSPayload.asyncSequence which allows you to provide an AsyncSequence of ByteBuffers to a request.

+1819 -54

0 comment

24 changed files

adam-fowler

pr closed time in 18 hours

PR opened soto-project/soto-core

Async sequence `AWSPayload`

This adds AWSPayload.asyncSequence which allows you to provide an AsyncSequence of ByteBuffers to a request.

+1819 -54

0 comment

24 changed files

pr created time in 18 hours

push eventsoto-project/soto-core

Adam Fowler

commit sha 9965f427bbb899660714736effa2bad9a85b1b27

Add AWSPayload.asyncSequence

view details

push time in 18 hours

create barnchsoto-project/soto-core

branch : async-sequence-payload

created branch time in 18 hours

push eventsoto-project/soto-core

Adam Fowler

commit sha da2b55d750bd00fb2d79b9e629c9c04bdd1bd17b

Replace import NIO with import NIOCore (#459) * Replace import NIO with import NIOCore Needed to add a couple of import NIOPosix calls as well, hopefully can remove those at some point * swift format

view details

Adam Fowler

commit sha c404fe18a839ca62522df961a1602bde58732ea5

Add EventLoopFuture.get() async

view details

Adam Fowler

commit sha 2166c189695337d1371b8036cac308b3cf677411

Add async interfaces for AWSClient

view details

Adam Fowler

commit sha 3226af0cd930d527fb35fc69b1da6ebcf2216e8e

Add tests for async interfaces

view details

Adam Fowler

commit sha 75e402bd3491f5997f36ca84605bde72dc329130

Use runAsyncAndBlock

view details

Adam Fowler

commit sha 14bc1d352952253bc0a2ac067bce004592816854

Add PaginateSequence

view details

Adam Fowler

commit sha 992cdecbc95fd6e377a7d9c0b22a19b75abc8171

Add signURL async versions

view details

Adam Fowler

commit sha 0e083d03606894cd8279bf9d0393d9517f1bddc8

Update AWSClient.execute async for new stream flag

view details

Adam Fowler

commit sha d551ef199034415234785066eb85ca0438dbc9b3

Add #if compiler(>=5.4) && $AsyncAwait tests

view details

Adam Fowler

commit sha ead146f115b8de9bc37fe8d3a878c37b983e6f84

Make inputKey optional in paginator, add optional moreResultsKey

view details

Adam Fowler

commit sha 050a7f9e135503afda9348e593aee2b7e52c7bfc

Use nightly builds of swift for CI

view details

Adam Fowler

commit sha cb1b7288425d254a2c27e61ee1a520518a57480d

Wrap everything with @available(macOS 9999, etc)

view details

Adam Fowler

commit sha e0bf432eb5c7fbfd29a558db26d72d4fd18191c2

Use versions of reduce from swift code with rethrows replaced

view details

Adam Fowler

commit sha f1a2c23cbf95c6056ed71347a4bc0b47f6ddf2ad

Added `AsyncCredentialProvider`

view details

Adam Fowler

commit sha 07ecdda0951b8f1906535d1d23e915f55bfbb544

Tidying up Remove all experimental concurrency features Split concurrency tests into separate files Use group.next() in tests Revert GH actions to main branch versions

view details

Adam Fowler

commit sha 0b5014d90003e94db045cbe77d421ab9536066fb

Move paginate async tests into their own class Fixup Tests Fix AWSClientAsyncTests This isn't popular for try await _ in group {} Add swiftlang/swift:nightly-focal to CI to test async code Disable async tests as they crash thread sanitizer

view details

Adam Fowler

commit sha fe94ea02fb27857c8432e04ac809f17eccb5d8e3

Replace custom async code with _NIOConcurrency versions

view details

Adam Fowler

commit sha 374a4b709ee1472d8d66756e91da6de24711118f

Updated for latest async/await syntax changes Remove reduce implementations, as rethrows works on protocols now

view details

Adam Fowler

commit sha e79d61eb7673008be6cf5fbabc75ec3034d50d84

Add AsyncCredentialProviderTests

view details

Adam Fowler

commit sha 0df7402accb1c3755a27699b162f0429e68f1262

Update available version numbers Swap out swift version for swift nightlies Remove $AsyncAwait test

view details

push time in 19 hours

delete branch soto-project/soto

delete branch : nio-core

delete time in 20 hours

push eventsoto-project/soto

Adam Fowler

commit sha db8d1d07be8daceb43010ce291264f54ca1528e9

Replace NIO with NIOCore where applicable (#526) * Replace NIO with NIOCore where applicable * Fix S3Tests

view details

push time in 20 hours

PR merged soto-project/soto

Reviewers
Replace NIO with NIOCore where applicable
+15 -14

3 comments

14 changed files

adam-fowler

pr closed time in 20 hours

pull request commentsoto-project/soto

Replace NIO with NIOCore where applicable

Cool as long as it's something we export that should be fine. My thinking was to avoid headaches in the future when SwiftPM fixes the bug of making all targets in the dependency tree available to everything at some point in the future

I'll look into this in another PR maybe

adam-fowler

comment created time in 20 hours

pull request commentsoto-project/soto

Replace NIO with NIOCore where applicable

LGTM. The only thing I don't see is adding NIOCore as a dependency in the manifest - was this done previously or are you relying on SwiftPM exposing that to you via NIO's exports?

I guess the services that include the import NIOCore/NIOPosix should really have the dependency in the manifest. It's a bit of a pain, when you are autogenerating the Package.swift. In most cases I could actually remove the import NIOCore as I have @_exported a number of the NIOCore symbols from SotoCore.

adam-fowler

comment created time in 20 hours

push eventsoto-project/soto

Adam Fowler

commit sha a51e7d73988ab536e5fa94846b82f30d06f9c462

Fix S3Tests

view details

push time in 20 hours

PR opened soto-project/soto

Replace NIO with NIOCore where applicable
+14 -14

0 comment

14 changed files

pr created time in a day

create barnchsoto-project/soto

branch : nio-core

created branch time in a day

delete branch soto-project/soto-core

delete branch : nio-core

delete time in a day

PR merged soto-project/soto-core

Reviewers
Replace import NIO with import NIOCore

Needed to add a couple of import NIOPosix calls as well, hopefully can remove those at some point

+99 -77

1 comment

51 changed files

adam-fowler

pr closed time in a day

push eventsoto-project/soto-core

Adam Fowler

commit sha da2b55d750bd00fb2d79b9e629c9c04bdd1bd17b

Replace import NIO with import NIOCore (#459) * Replace import NIO with import NIOCore Needed to add a couple of import NIOPosix calls as well, hopefully can remove those at some point * swift format

view details

push time in a day

pull request commentswift-server/guides

Swift Concurrency adoption guidelines for Swift Server Libraries

  • [ ] example with async sequence

Soto has an AsyncSequence sample used for paginated results. It is full of generics so might not be the simplest example though. https://github.com/soto-project/soto-core/blob/async-await/Sources/SotoCore/AWSClient%2BPaginate%2Basync.swift

fabianfett

comment created time in a day

Pull request review commentswift-server/guides

Swift Concurrency adoption guidelines for Swift Server Libraries

+# Swift Concurrency adoption guidelines for Swift Server Libraries++This writeup attempts to provide a set of guidelines to follow by authors of server-side Swift libraries. Specifically a lot of the discussion here revolves around what to do about existing APIs and libraries making extensive use of Swift NIO’s `EventLoopFuture` and related types.++Swift Concurrency is a multi-year effort. It is very valuable for the server community to participate in this multi-year adoption of the concurrency features, one by one, and provide feedback while doing so. As such, we should not hold off adopting concurrency features until Swift 6 as we may miss valuable opportunity to improve the concurrency model.++In 2021 we saw structured concurrency and actors arrive with Swift 5.5. Now is a great time to provide APIs using those primitives. In the future we will see fully checked Swift concurrency. This will come with breaking changes. For this reason adopting the new concurrency features can be split into two phases.+++## What you can do right now++### API Design++Firstly, existing libraries should strive to add `async` functions where possible to their user-facing “surface” APIs in addition to existing `*Future` based APIs wherever possible. These additive APIs can be gated on the Swift version and can be added without breaking existing users' code, for example like this:++```swift+extension Worker {+  func work() -> EventLoopFuture<Value> { ... }+  +  #if swift(>=5.5)+  func work() async throws -> Value { ... }+  #endif+}+```++If a function cannot fail but was using futures before, it should not include the `throws` keyword in its new incarnation. 

Given most implementations will be using EventLoopFuture.get initially everyone will be forced into adding throws

fabianfett

comment created time in a day

PullRequestReviewEvent

Pull request review commentswift-server/guides

Swift Concurrency adoption guidelines for Swift Server Libraries

+# Swift Concurrency adoption guidelines for Swift Server Libraries++This writeup attempts to provide a set of guidelines to follow by authors of server-side Swift libraries. Specifically a lot of the discussion here revolves around what to do about existing APIs and libraries making extensive use of Swift NIO’s `EventLoopFuture` and related types.++Swift Concurrency is a multi-year effort. It is very valuable for the server community to participate in this multi-year adoption of the concurrency features, one by one, and provide feedback while doing so. As such, we should not hold off adopting concurrency features until Swift 6 as we may miss valuable opportunity to improve the concurrency model.++In 2021 we saw structured concurrency and actors arrive with Swift 5.5. Now is a great time to provide APIs using those primitives. In the future we will see fully checked Swift concurrency. This will come with breaking changes. For this reason adopting the new concurrency features can be split into two phases.+++## What you can do right now++### API Design++Firstly, existing libraries should strive to add `async` functions where possible to their user-facing “surface” APIs in addition to existing `*Future` based APIs wherever possible. These additive APIs can be gated on the Swift version and can be added without breaking existing users' code, for example like this:++```swift+extension Worker {+  func work() -> EventLoopFuture<Value> { ... }+  +  #if swift(>=5.5)+  func work() async throws -> Value { ... }+  #endif+}+```++If a function cannot fail but was using futures before, it should not include the `throws` keyword in its new incarnation. ++Such adoption can begin immediately, and should not cause any issues to existing users of existing libraries. ++### SwiftNIO helper functions++To allow an easy transition to async code, SwiftNIO offers a number of helper methods on `EventLoopFuture` and `-Promise`. Those live in the `_NIOConcurrency` module and will move to `NIOCore` once Swift concurrency is released.

Is the module keeping the _ prefix even after swift 5.5 release?

fabianfett

comment created time in a day

Pull request review commentswift-server/guides

Swift Concurrency adoption guidelines for Swift Server Libraries

+# Swift Concurrency adoption guidelines for Swift Server Libraries++This writeup attempts to provide a set of guidelines to follow by authors of server-side Swift libraries. Specifically a lot of the discussion here revolves around what to do about existing APIs and libraries making extensive use of Swift NIO’s `EventLoopFuture` and related types.++Swift Concurrency is a multi-year effort. It is very valuable for the server community to participate in this multi-year adoption of the concurrency features, one by one, and provide feedback while doing so. As such, we should not hold off adopting concurrency features until Swift 6 as we may miss valuable opportunity to improve the concurrency model.++In 2021 we saw structured concurrency and actors arrive with Swift 5.5. Now is a great time to provide APIs using those primitives. In the future we will see fully checked Swift concurrency. This will come with breaking changes. For this reason adopting the new concurrency features can be split into two phases.+++## What you can do right now++### API Design++Firstly, existing libraries should strive to add `async` functions where possible to their user-facing “surface” APIs in addition to existing `*Future` based APIs wherever possible. These additive APIs can be gated on the Swift version and can be added without breaking existing users' code, for example like this:++```swift+extension Worker {+  func work() -> EventLoopFuture<Value> { ... }+  +  #if swift(>=5.5)+  func work() async throws -> Value { ... }

Is it worth adding the @available(macOS 12.0, iOS 15.0, watchOS 8.0, tvOS 15.0, *)?

fabianfett

comment created time in a day

PullRequestReviewEvent

push eventadam-fowler/jmespath.swift

Adam Fowler

commit sha dfefd85537f15ad44f211d9fdacb89e21ed0de31

Remove unnecessary @testable

view details

push time in 2 days