profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/weissi/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.

apple/swift 57276

The Swift Programming Language

apple/swift-evolution 12731

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.

apple/swift-package-manager 8491

The Package Manager for the Swift Programming Language

apple/swift-corelibs-foundation 4404

The Foundation Project, providing core utilities, internationalization, and OS independence

apple/swift-corelibs-xctest 930

The XCTest Project, A Swift core library for providing unit test support

weissi/FRLayeredNavigationController 492

FRLayeredNavigationController, an iOS container view controller that works like a stack of paper with an API similar to UINavigationController.

kylebrowning/APNSwift 415

An HTTP/2 APNS library built on swift-nio

swift-server/swift-backtrace 236

💥 Backtraces for Swift on Linux and Windows

swift-server/swift-service-lifecycle 234

Cleanly startup and shutdown server application, freeing resources in order before exiting.

MrLotU/SwiftPrometheus 64

Client side Prometheus library in Swift

issue closedapple/swift-nio

ByteToMessageDecoder uses channelReadComplete wrongly

ByteToMessageDecoder uses channelReadComplete wrongly, it doesn't do anything with the event at all but it should only send the event after a number of .continues when we received a channelReadComplete.

closed time in 9 days

weissi

issue commentapple/swift-nio

ByteToMessageDecoder uses channelReadComplete wrongly

@Lukasa yes, agreed, nothing needs to be done here and everything that could be done is probably overly complex for not much benefit.

weissi

comment created time in 9 days

issue commentapple/swift-nio

Replace NIOAtomics with swift-atomics

@PeterAdams-A this doesn't really need a major. This can be broken into 2 pieces of work:

  1. make NIO itself use swift-atomics
  2. deprecate all NIOAtomics Once NIO 3 comes out, the deprecated stuff will be removed anyway.
PeterAdams-A

comment created time in 16 days

issue openedswift-server/guides

Guides like the Ubuntu guide recommend installing Swift 5.2

Swift version information should be updated.

created time in 17 days

issue openedswift-server/swift-backtrace

doesn't (necessarily) exit after printing stacktrace

https://github.com/swift-server/swift-backtrace/blob/99a6c79fc5df7b8584ff65c20211211f02e14ce2/Sources/Backtrace/Backtrace.swift#L79

I would expect that SwiftBacktrace (because it's relying on undefined behaviour) to exit (by reraising the signal) after having printed the stacktrace. It doesn't do that however, hoping that the same signal will be raised again. This may not be the case, we may run into a different crash or even continue the program for a little while.

I think we should add a raise(signal) to the code.

created time in a month

create barnchweissi/async-http-client

branch : jw-pcap-all

created branch time in a month

Pull request review commentapple/swift-nio

Add compiler setting for __APPLE_USE_RFC_3542 for CNIODarwin

 for target in "${targets[@]}"; do     libraries="s.libraries = 'z'"   fi +  compiler_flags=""+  if [[ "$target" == "CNIODarwin" ]]; then+    compiler_flags="s.compiler_flags = '-D__APPLE_USE_RFC_3542=1'"

Then we can probably also just take it out of Package.swift, no?

glbrntt

comment created time in a month

PullRequestReviewEvent

Pull request review commentapple/swift-nio

Add compiler setting for __APPLE_USE_RFC_3542 for CNIODarwin

 for target in "${targets[@]}"; do     libraries="s.libraries = 'z'"   fi +  compiler_flags=""+  if [[ "$target" == "CNIODarwin" ]]; then+    compiler_flags="s.compiler_flags = '-D__APPLE_USE_RFC_3542=1'"

@glbrntt if we set this unconditionally, why don't we just #define __APPLE_USE_RFC_3542 1 before the include of the relevant header (that makes use of this)?

glbrntt

comment created time in a month

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentswift-server/async-http-client

[RFC] Add async/await proposal

+# Proposal: Async-await support++## Introduction++With the introduction of [async/await][SE-0296] in Swift 5.5, it is now possible to write asynchronous code without the need for callbacks. ++Language support for [`AsyncSequence`][SE-0298] also allows for writing functions that return values over time.++We would like to explore how we could offer APIs that make use of these new language features to allow users to run HTTPRequest using these new idioms.++This proposal describes what these APIs could look like and explores some of the potential usability concerns.++## Proposed API additions++### New `AsyncRequest` type++The proposed new `AsyncRequest` shall be a simple swift structure.++```swift+struct AsyncRequest {+  /// The requests url.+  var url: String+  +  /// The request's HTTPMethod+  var method: HTTPMethod+  +  /// The request's headers+  var headers: HTTPHeaders++  /// The request's body+  var body: Body?

@fabianfett you can do the same in NIOHTTP1. If you see channelRead(.head(...)), channelRead(.body(...)), channelRead(.end(...)), channelReadComplete, then you have everything in one go and you don't need to stream. If you get channelReadComplete before channelRead(.end(...)) then you'd need to stream.

fabianfett

comment created time in a month

PullRequestReviewEvent

Pull request review commentswift-server/async-http-client

[RFC] Add async/await proposal

+# Proposal: Async-await support++## Introduction++With the introduction of [async/await][SE-0296] in Swift 5.5, it is now possible to write asynchronous code without the need for callbacks. ++Language support for [`AsyncSequence`][SE-0298] also allows for writing functions that return values over time.++We would like to explore how we could offer APIs that make use of these new language features to allow users to run HTTPRequest using these new idioms.++This proposal describes what these APIs could look like and explores some of the potential usability concerns.++## Proposed API additions++### New `AsyncRequest` type++The proposed new `AsyncRequest` shall be a simple swift structure.++```swift+struct AsyncRequest {+  /// The requests url.+  var url: String+  +  /// The request's HTTPMethod+  var method: HTTPMethod+  +  /// The request's headers+  var headers: HTTPHeaders++  /// The request's body+  var body: Body?+    +  init(url: String) {+    self.url = url+    self.method = .GET+    self.headers = .init()+    self.body = .none+  }+}+```++A notable change from the current [`HTTPRequest`][HTTPRequest] is that the url is not of type `URL`. This makes the creation of a request non throwing. Existing issues regarding current API: ++- [HTTPClient.Request.url is a let constant][issue-395]+- [refactor to make request non-throwing](https://github.com/swift-server/async-http-client/pull/56)+- [improve request validation](https://github.com/swift-server/async-http-client/pull/67)++The url validation will become part of the normal request validation that occurs when the request is scheduled on the `HTTPClient`. If the user supplies a request with an invalid url, the http client, will reject the request.++In normal try/catch flows this should not change the control flow:++```swift+do {+  var request = AsyncRequest(url: "invalidurl")+  try await httpClient.execute(request, deadline: .now() + .seconds(3))+} catch {+  print(error)+}+```++If the library code throws from the AsyncRequest creation or the request invocation the user will, in normal use cases, handle the error in the same catch block. ++#### Body streaming++The new AsyncRequest has a new body type, that is wrapper around an internal enum. This allows us to evolve this type for use-cases that we are not aware of today. ++```swift+public struct Body {+  static func bytes<S: Sequence>(_ sequence: S) -> Body where S.Element == UInt8++  static func stream<S: AsyncSequence>(_ sequence: S) -> Body where S.Element == ByteBuffer++  static func stream<S: AsyncSequence>(_ sequence: S) -> Body where S.Element == UInt8+}+```++The main difference to today's `Request.Body` type is the lack of a `StreamWriter` for streaming scenarios. The existing StreamWriter offered the user an API to write into (thus the user was in control of when writing happened). The new `AsyncRequest.Body` uses `AsyncSequence`s to stream requests. By iterating over the provided AsyncSequence, the HTTPClient is  in control when writes happen, and can ask for more data efficiently. 

problem statements in #194 and #264

fabianfett

comment created time in a month

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentswift-server/async-http-client

[RFC] Add async/await proposal

+# Proposal: Async-await support++## Introduction++With the introduction of [async/await][SE-0296] in Swift 5.5, it is now possible to write asynchronous code without the need for callbacks. ++Language support for [`AsyncSequence`][SE-0298] also allows for writing functions that return values over time.++We would like to explore how we could offer APIs that make use of these new language features to allow users to run HTTPRequest using these new idioms.++This proposal describes what these APIs could look like and explores some of the potential usability concerns.++## Proposed API additions++### New `AsyncRequest` type++The proposed new `AsyncRequest` shall be a simple swift structure.++```swift+struct AsyncRequest {+  /// The requests url.+  var url: String+  +  /// The request's HTTPMethod+  var method: HTTPMethod+  +  /// The request's headers+  var headers: HTTPHeaders++  /// The request's body+  var body: Body?+    +  init(url: String) {+    self.url = url+    self.method = .GET+    self.headers = .init()+    self.body = .none+  }+}+```++A notable change from the current [`HTTPRequest`][HTTPRequest] is that the url is not of type `URL`. This makes the creation of a request non throwing. Existing issues regarding current API: ++- [HTTPClient.Request.url is a let constant][issue-395]+- [refactor to make request non-throwing](https://github.com/swift-server/async-http-client/pull/56)+- [improve request validation](https://github.com/swift-server/async-http-client/pull/67)++The url validation will become part of the normal request validation that occurs when the request is scheduled on the `HTTPClient`. If the user supplies a request with an invalid url, the http client, will reject the request.++In normal try/catch flows this should not change the control flow:++```swift+do {+  var request = AsyncRequest(url: "invalidurl")+  try await httpClient.execute(request, deadline: .now() + .seconds(3))+} catch {+  print(error)+}+```++If the library code throws from the AsyncRequest creation or the request invocation the user will, in normal use cases, handle the error in the same catch block. ++#### Body streaming++The new AsyncRequest has a new body type, that is wrapper around an internal enum. This allows us to evolve this type for use-cases that we are not aware of today. ++```swift+public struct Body {+  static func bytes<S: Sequence>(_ sequence: S) -> Body where S.Element == UInt8++  static func stream<S: AsyncSequence>(_ sequence: S) -> Body where S.Element == ByteBuffer++  static func stream<S: AsyncSequence>(_ sequence: S) -> Body where S.Element == UInt8+}+```++The main difference to today's `Request.Body` type is the lack of a `StreamWriter` for streaming scenarios. The existing StreamWriter offered the user an API to write into (thus the user was in control of when writing happened). The new `AsyncRequest.Body` uses `AsyncSequence`s to stream requests. By iterating over the provided AsyncSequence, the HTTPClient is  in control when writes happen, and can ask for more data efficiently. 

I assume we'd fix the StreamWriter API, right? There's already #291

fabianfett

comment created time in a month

Pull request review commentswift-server/async-http-client

[RFC] Add async/await proposal

+# Proposal: Async-await support++## Introduction++With the introduction of [async/await][SE-0296] in Swift 5.5, it is now possible to write asynchronous code without the need for callbacks. ++Language support for [`AsyncSequence`][SE-0298] also allows for writing functions that return values over time.++We would like to explore how we could offer APIs that make use of these new language features to allow users to run HTTPRequest using these new idioms.++This proposal describes what these APIs could look like and explores some of the potential usability concerns.++## Proposed API additions++### New `AsyncRequest` type++The proposed new `AsyncRequest` shall be a simple swift structure.++```swift+struct AsyncRequest {+  /// The requests url.+  var url: String+  +  /// The request's HTTPMethod+  var method: HTTPMethod+  +  /// The request's headers+  var headers: HTTPHeaders++  /// The request's body+  var body: Body?

@ktoso hmm, the above HTTPEntity.* list seems extremely HTTP/1.1 specific and even exposes some really bad things like "close delimited" which we don't need. Also a user shouldn't care if it's sent using chunked encoding or not, right? That's a choice the HTTP lib can make itself. If the user doesn't tell the number of bytes ahead of time, then in HTTP/1.1 it should use chunked encoding. If the user promises the size ahead of time, it can use content-length instead. It should never use EOF-framing (aka "close delimited").

  • Empty seems like an (unnecessary?) specialisation of a body with a pre-announced length (of 0 bytes)
  • indefiniteLength seems like an (unnecessary?) specialisation of a body without a pre-announced length
fabianfett

comment created time in a month

PullRequestReviewEvent
PullRequestReviewEvent

issue commentswift-server/async-http-client

RFC: design suggestion: Make this a "3-tier library"

@fabianfett Thanks! I kinda like HTTPTransport, HTTPClient, HTTPRequest. Don't think "transport" really makes sense but it's not too terrible either :).

weissi

comment created time in a month

Pull request review commentapple/swift-metrics

Introduce FloatingPointCounter

 // //===----------------------------------------------------------------------===// +// MARK: Testing API++internal var _enableAssertions = true

yeah, go ahead. Just need to copy the three "driver" files and for every new test suite, you'll need to put an entry into this dict. It's able to automatically enumerate all test* methods, so no need to declare every test. (Here's the method enumeration code)

rauhul

comment created time in a month

PullRequestReviewEvent

Pull request review commentapple/swift-metrics

Introduce FloatingPointCounter

 // //===----------------------------------------------------------------------===// +// MARK: Testing API++internal var _enableAssertions = true

In NIO we test them in NIOCrashTester.

rauhul

comment created time in a month

PullRequestReviewEvent

issue commentapple/swift-nio

Ordering of tasks scheduled with the same deadline on `SelectableEventLoop` is undefined

As to the "memory ordering questions", the issue isn't execute it's scheduleTask. This is where we need to be able to tell in what order things get enqueued, as they need to be executed in the order they were enqueued, which right now they are not.

Yes, but that's not relevant for the futures, right? It's definitely relevant for scheduleTask(deadline: X).

glbrntt

comment created time in a month

issue commentapple/swift-nio

Ordering of tasks scheduled with the same deadline on `SelectableEventLoop` is undefined

@Lukasa wait, a 64bit counter is definitely enough. The user could submit one work item per nanosecond for over 500 years, and only then would we overflow. I think that's acceptable.

glbrntt

comment created time in a month

pull request commentapple/swift-metrics

Introduce FloatingPointCounter

CC @MrLotU

rauhul

comment created time in 2 months

pull request commentapple/swift

Check withContiguousStorageIfAvailable before copying byte by byte

Can't believe that RawBufferCopyBytes in Apple Silicon is 5694x faster. 🥇

Yes, this is expected, especially in debug mode. Previously, it would call the getter for every single byte, and then the setter. Now, it'll just call memmove once. And memmove is a libc function so it's always optimised. Ie. there's just a lot less Swift code running to transfer the bytes.

In -Osize, you'll see that it's "just" 20x and that's because the compiler was able to better optimise the getter & setter. But now, that's no longer necessary, we'll just do memmove.

Great stuff, thank you!

wongzigii

comment created time in 2 months