profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/Lukasa/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.
Cory Benfield Lukasa Apple London, England https://lukasa.co.uk Professional open source developer with a long background in building networking tools. Creator of @python-hyper, core developer of Swift NIO. Everywhere.

httpwg/http2-spec 3594

Working copy of the HTTP/2 Specification

grpc/grpc-swift 1386

The Swift language implementation of gRPC.

apple/swift-crypto 1098

Open-source implementation of a substantial portion of the API of Apple CryptoKit suitable for use on Linux platforms.

apple/swift-nio-ssh 230

SwiftNIO SSH is a programmatic implementation of SSH using SwiftNIO

apple/swift-nio-transport-services 203

Extensions for SwiftNIO to support Apple platforms as first-class citizens.

apple/swift-http-structured-headers 99

A Swift implementation of the HTTP Structured Header Field specification.

brettcannon/sans-io 86

Network protocol implementations in Python, sans I/O

Lukasa/entweet 67

Badass encryption for Twitter

Lukasa/collectr 20

Static file management for everyone.

Lukasa/cryptopals 7

My solutions to the Matasano Crypto Challenges

delete branch Lukasa/swift-nio

delete branch : cb-enable-nightly-tests

delete time in 9 hours

push eventapple/swift-nio

Cory Benfield

commit sha 19403414baa3f1c19a880154c81cbdeda9668acd

Get unit tests running again on nightly builds. (#1961) Motivation: In February, @weissi noticed that the nightly builds of Swift could no longer compile the unit tests. We disabled them at that time and reported an upstream bug, https://bugs.swift.org/browse/SR-14268. This is not an ideal situation, but the Swift core team has provided a workaround we can use to re-enable the tests. Modifications: Provide free functions that wrap some specific extension methods that are called in unit tests, and amend the call sites to use them. Result: We can re-enable the nightly tests.

view details

push time in 9 hours

PR merged apple/swift-nio

Reviewers
Get unit tests running again on nightly builds. patch-version-bump-only

Motivation:

In February, @weissi noticed that the nightly builds of Swift could no longer compile the unit tests. We disabled them at that time and reported an upstream bug, https://bugs.swift.org/browse/SR-14268. This is not an ideal situation, but the Swift core team has provided a workaround we can use to re-enable the tests.

Modifications:

Provide free functions that wrap some specific extension methods that are called in unit tests, and amend the call sites to use them.

Result:

We can re-enable the nightly tests.

+54 -10

0 comment

5 changed files

Lukasa

pr closed time in 9 hours

PR opened apple/swift-nio

Reviewers
Get unit tests running again on nightly builds. patch-version-bump-only

Motivation:

In February, @weissi noticed that the nightly builds of Swift could no longer compile the unit tests. We disabled them at that time and reported an upstream bug, https://bugs.swift.org/browse/SR-14268. This is not an ideal situation, but the Swift core team has provided a workaround we can use to re-enable the tests.

Modifications:

Provide free functions that wrap some specific extension methods that are called in unit tests, and amend the call sites to use them.

Result:

We can re-enable the nightly tests.

+54 -10

0 comment

5 changed files

pr created time in 11 hours

create barnchLukasa/swift-nio

branch : cb-enable-nightly-tests

created branch time in 11 hours

issue commentapple/swift-nio

Add a generic connection error for NIO

Yeah, this seems useful.

For what it's worth, no other connection backend has ever thrown NIOConnectionError, so currently these errors are separate per backend.

adam-fowler

comment created time in 17 hours

push eventapple/swift-nio

Fabian Fett

commit sha d8e1b1f96f32b84b1bedaf31b91ebbbadae31718

[NIOSingleStepByteToMessageProcessor] Inline process methods (#1959) * Inline NIOSingleStepByteToMessageProcessor * Code review

view details

push time in 19 hours

PR merged apple/swift-nio

[NIOSingleStepByteToMessageProcessor] Inline process methods patch-version-bump-only

We like speed. To make NIOSingleStepByteToMessageProcessor even faster, we should mark the process method as @inlinable.

NIOSingleStepByteToMessageProcessor overhead is reduced:

Previous: without_inline

Inlined: with_inline

The important bit is the relative performance improvement between withNonCowBuffer and the actual decode invocation.

Result:

Faster NIOSingleStepByteToMessageProcessor.

+23 -11

0 comment

2 changed files

fabianfett

pr closed time in 19 hours

PullRequestReviewEvent

issue commentgrpc/grpc-swift

Xcode 13 RC (13A233) support for armv7 (Real devices)

So far I still haven't reproduced this. Can you remove your .build and your DerivedData folder to just be 100% sure that we aren't bringing in some weird state from elsewhere?

niorko

comment created time in 19 hours

Pull request review commentapple/swift-nio

[NIOSingleStepByteToMessageProcessor] Inline process methods

 public final class NIOSingleStepByteToMessageProcessor<Decoder: NIOSingleStepByt         self.maximumBufferSize = maximumBufferSize     } -    private func append(_ buffer: ByteBuffer) {+    @usableFromInline+    func append(_ buffer: ByteBuffer) {

This may as well be inlinable too, as should init.

fabianfett

comment created time in 21 hours

Pull request review commentapple/swift-nio

[NIOSingleStepByteToMessageProcessor] Inline process methods

 public final class NIOSingleStepByteToMessageProcessor<Decoder: NIOSingleStepByt         return result     } -    private func decodeLoop(decodeMode: DecodeMode, seenEOF: Bool = false, _ messageReceiver: (Decoder.InboundOut) throws -> Void) throws {+    @inlinable+    func decodeLoop(decodeMode: DecodeMode, seenEOF: Bool = false, _ messageReceiver: (Decoder.InboundOut) throws -> Void) throws {

Can you prefix this with an underscore so we know it was supposed to be private?

fabianfett

comment created time in 21 hours

PullRequestReviewEvent
PullRequestReviewEvent

issue commentgrpc/grpc-swift

Xcode 13 RC (13A233) support for armv7 (Real devices)

For example:

/Volumes/FBMac/tmp/DerivedData/kate-ios-grpc-swift-aeudckuyjkzqicdqqcwbtlwoieon/SourcePackages/checkouts/swift-nio-ssl/Sources/NIOSSL/SSLContext.swift:401:20: error: ambiguous use of 'CNIOBoringSSL_SSL_CTX_use_PrivateKey_file'
            return CNIOBoringSSL_SSL_CTX_use_PrivateKey_file(context, pointer, fileType)
                   ^
CNIOBoringSSL.CNIOBoringSSL_SSL_CTX_use_PrivateKey_file:1:13: note: found this candidate
public func CNIOBoringSSL_SSL_CTX_use_PrivateKey_file(_ ctx: OpaquePointer!, _ file: UnsafePointer<CChar>!, _ type: Int32) -> Int32
            ^
CNIOBoringSSLShims.CNIOBoringSSL_SSL_CTX_use_PrivateKey_file:1:13: note: found this candidate
public func CNIOBoringSSL_SSL_CTX_use_PrivateKey_file(_ ctx: OpaquePointer!, _ file: UnsafePointer<CChar>!, _ type: Int32) -> Int32

This shows the function CNIOBoringSSL_SSL_CTX_use_PrivateKey_file being available from CNIOBoringSSL and CNIOBoringSSLShims. That shouldn't be the case, we should be resolving only the one.

However, we also see errors like this:

/Volumes/FBMac/tmp/DerivedData/kate-ios-grpc-swift-aeudckuyjkzqicdqqcwbtlwoieon/SourcePackages/checkouts/swift-nio-ssl/Sources/NIOSSL/SSLContext.swift:413:90: error: ambiguous use of 'count'
            CNIOBoringSSL_SSL_CTX_set_alpn_protos(context, $0.baseAddress!, CUnsignedInt($0.count))
                                                                                         ^
Swift.UnsafeBufferPointer:2:16: note: found this candidate
    public let count: Int
               ^
Swift.Collection:5:27: note: found this candidate
    @inlinable public var count: Int { get }

This shouldn't really be ambiguous. For now I'm assuming this error is an awkward follow-on from the former, but it could be something else altogether.

niorko

comment created time in 21 hours

issue commentgrpc/grpc-swift

Xcode 13 RC (13A233) support for armv7 (Real devices)

Ah, this second log is more useful. This seems to show a problem with the modulemaps: we're including the same header file through separate paths. I have to admit I don't know why this is causing some of these issues: the compiler seems to be having real trouble resolving a bunch of the includes.

niorko

comment created time in 21 hours

issue commentgrpc/grpc-swift

Xcode 13 RC (13A233) support for armv7 (Real devices)

The reason I'm surprised this has anything to do with armv7 is that the errors are primarily the result of whether the X509 structure is opaque or not. This should not be architecture specific.

niorko

comment created time in 21 hours

issue commentgrpc/grpc-swift

Xcode 13 RC (13A233) support for armv7 (Real devices)

It should work with real devices using arm64. The issue seems likely to be to do with the way armv7 is building.

niorko

comment created time in 21 hours

PullRequestReviewEvent

issue commentgrpc/grpc-swift

Xcode 13 RC (13A233) support for armv7 (Real devices)

This is a very interesting set of errors: they all come from SwiftNIO SSL, but they don't appear when building that project directly so far as I can see. Additionally, the nature of these errors is that there appears to be a header mismatch: we seem to be getting the wrong header files from CNIOBoringSSL.

Can I confirm that this occurs for you on a clean build (that is, if you rm -rf .build)?

niorko

comment created time in 21 hours

PullRequestReviewEvent

issue commentapple/swift-nio

Xcode 13 GM not compiling ByteBuffer-Core

To tie a bow on this, the fix is available in SwiftNIO version 2.32.3.

Andrewangeta

comment created time in 2 days

PullRequestReviewEvent

delete branch Lukasa/swift-nio-extras

delete branch : cb-remove-submodule

delete time in 2 days

PR opened apple/swift-nio-extras

Reviewers
Remove SourceKitten submodule. patch-version-bump-only

Motivation:

This SourceKitten submodule is not needed, and there isn't any appropriate map, so it can't actually be initialized. This is breaking adopters of swift-nio-extras.

Modifications:

  • Delete the submodule.

Results:

Adopters can build again.

+0 -1

0 comment

1 changed file

pr created time in 2 days

create barnchLukasa/swift-nio-extras

branch : cb-remove-submodule

created branch time in 2 days

pull request commentswift-server/async-http-client

[DRAFT] HTTP2 connection pooling

@swift-server-bot add to allowlist

dnadoba

comment created time in 2 days

issue commentapple/swift-nio

Provide NonBlockingFileIO helpers that use Swift System

In principle, yes.

Lukasa

comment created time in 2 days

delete branch Lukasa/swift-nio-ssl-1

delete branch : cb-clean-up-implementation-only

delete time in 2 days