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

danielgtaylor/aglio 4627

An API Blueprint renderer with theme support that outputs static HTML

kylef/Commander 1461

Compose beautiful command line interfaces in Swift

keith/swift.vim 748

Vim runtime files for Swift

kylef/heroku-buildpack-swift 507

Heroku build pack for Swift

django-request/django-request 436

django-request is a statistics module for django. It stores requests in a database for admins to see, it can also be used to get statistics on who is online etc.

kylef/JSONSchema.swift 234

JSON Schema validator in Swift

Conche/Conche 158

Swift build system and dependency manager.

kylef/apiblueprint.vim 113

This vim plugin brings syntax highlighting and linting for API Blueprint.

apiaryio/api-blueprint-rfcs 38

The API Blueprint RFC process

kattrali/webkitten 36

A command-driven web browser toolkit inspired by luakit and Vim.

push eventkylef/swiftenv-api

Kyle Fuller

commit sha 79c58f2d03cdc29ba2da32ef9b7a68757bc15874

chore: Add 5.5

view details

push time in an hour

push eventkylef/Mockingjay

Dennis Collaris

commit sha 9e5bd2f0da4906ea7891675c4333c57a2dc88649

fix: ambiguous XCTest.tearDown swizzle

view details

push time in 2 hours

PR merged kylef/Mockingjay

Fix ambiguous XCTest.tearDown swizzle

This PR addresses an issue occurring with Xcode 13 that prevents this project from building.

Xcode has trouble determining which XCTest.tearDown is referred to, the class or the instance method. As an alternative I initially suggested Selector("tearDown") which will use the instance method and resolve the issue. However, for that change Xcode displays a warning, and suggests the change in this PR as an alternative.

I have tested the change on Xcode 13 and an old Xcode 12.2 beta, on both it compiles and tests pass.

Closes #119

+1 -1

0 comment

1 changed file

iamDecode

pr closed time in 2 hours

issue closedkylef/Mockingjay

Unable to use the library on Xcode 13.0 (Swift 5.5)

Hi, we updated our Xcode to 13.0 and now the library does not work anymore. It causes this error:

Screenshot 2021-09-21 at 13 39 22

It's something with the method swizzling.

closed time in 2 hours

ppamorim

push eventkylef/URITemplate.swift

Kyle Fuller

commit sha 6affd42c58328a4b229b6b8c8091ada67d7be9a4

chore: update Spectre to 0.10.1

view details

push time in 5 hours

issue commentkylef/PathKit

Xcode 13 compiler error

It looks like there's a patch released a few hours ago in https://github.com/tuist/XcodeProj/releases/tag/8.3.1

chilimovpasha

comment created time in 5 hours

issue commentkylef/PathKit

Xcode 13 compiler error

The screenshot is not PathKit source and is a file from a different dependency you are using -> https://github.com/tuist/XcodeProj/blob/main/Sources/XcodeProj/Extensions/Path%2BExtras.swift .

chilimovpasha

comment created time in 5 hours

issue closedkylef/PathKit

Unable to build with Xcode 13 GM

When I build the package for release (using swift build -c release) I get the following errors:

/Users/ci/Downloads/PathKit-master/Sources/PathKit.swift:594:12: error: value of optional type 'UnsafeMutablePointer<CChar>?' (aka 'Optional<UnsafeMutablePointer<Int8>>') must be unwrapped to a value of type 'UnsafeMutablePointer<CChar>' (aka 'UnsafeMutablePointer<Int8>')
      free(cPattern)
           ^
/Users/ci/Downloads/PathKit-master/Sources/PathKit.swift:594:12: note: coalesce using '??' to provide a default when the optional value contains 'nil'
      free(cPattern)
           ^
                    ?? <#default value#>
/Users/ci/Downloads/PathKit-master/Sources/PathKit.swift:594:12: note: force-unwrap using '!' to abort execution if the optional value contains 'nil'
      free(cPattern)
           ^
                   !
/Users/ci/Downloads/PathKit-master/Sources/PathKit.swift:625:12: error: value of optional type 'UnsafeMutablePointer<CChar>?' (aka 'Optional<UnsafeMutablePointer<Int8>>') must be unwrapped to a value of type 'UnsafeMutablePointer<CChar>' (aka 'UnsafeMutablePointer<Int8>')
      free(cPattern)
           ^
/Users/ci/Downloads/PathKit-master/Sources/PathKit.swift:625:12: note: coalesce using '??' to provide a default when the optional value contains 'nil'
      free(cPattern)
           ^
                    ?? <#default value#>
/Users/ci/Downloads/PathKit-master/Sources/PathKit.swift:625:12: note: force-unwrap using '!' to abort execution if the optional value contains 'nil'
      free(cPattern)
           ^
                   !
/Users/ci/Downloads/PathKit-master/Sources/PathKit.swift:626:12: error: value of optional type 'UnsafeMutablePointer<CChar>?' (aka 'Optional<UnsafeMutablePointer<Int8>>') must be unwrapped to a value of type 'UnsafeMutablePointer<CChar>' (aka 'UnsafeMutablePointer<Int8>')
      free(cPath)
           ^
/Users/ci/Downloads/PathKit-master/Sources/PathKit.swift:626:12: note: coalesce using '??' to provide a default when the optional value contains 'nil'
      free(cPath)
           ^
                 ?? <#default value#>
/Users/ci/Downloads/PathKit-master/Sources/PathKit.swift:626:12: note: force-unwrap using '!' to abort execution if the optional value contains 'nil'
      free(cPath)
           ^
                !

Is this a straightforward patch that can be applied?

closed time in 13 hours

jsorge

issue commentkylef/PathKit

Unable to build with Xcode 13 GM

This has been resolved in 1.0.1 thanks to everyone who helped out here with propsed changes and investigations!

jsorge

comment created time in 13 hours

issue commentkylef/PathKit

Unable to build with Xcode 13 GM

SourcePackages/checkouts/XcodeProj/Sources/XcodeProj/Extensions/Path+Extras.swift

This source file is not from PathKit

jsorge

comment created time in 13 hours

release kylef/PathKit

1.0.1

released time in a day

created tagkylef/PathKit

tag1.0.1

Effortless path operations in Swift

created time in a day

push eventkylef/PathKit

Kyle Fuller

commit sha 3bfd2737b700b9a36565a8c94f4ad2b050a5e574

release: 1.0.1

view details

push time in a day

pull request commentkylef/PathKit

Xcode 13 Hotfix

Thanks @chrisballinger, I'll create a release a bit later today to get this out.

chrisballinger

comment created time in a day

PR merged kylef/PathKit

Xcode 13 Hotfix

Based on @kylef's feedback for this similar PR: https://github.com/kylef/PathKit/pull/78

Also includes a fix for Xcode 12.5 ("ambiguous use of expect") referenced here: https://github.com/kylef/PathKit/pull/74#issuecomment-842159029

+17 -13

0 comment

2 changed files

chrisballinger

pr closed time in a day

push eventkylef/PathKit

Chris Ballinger

commit sha c7dace24a786af674fb22035c1f52585ac3bd734

fix: add support for Xcode 13 (#80) * Fix compilation issue on Xcode 13 * Fix ambiguous use of `expect` issue

view details

push time in a day

pull request commentkylef/swiftenv

Disable localization of `lscpu`.

Thanks @YOCKOW !

YOCKOW

comment created time in a day

PR merged kylef/swiftenv

Disable localization of `lscpu`.

The output of lscpu is localized. It means that lscpu | grep Architecture may return an empty result.

Resolves #185.

+1 -1

0 comment

1 changed file

YOCKOW

pr closed time in a day

push eventkylef/swiftenv

YOCKOW

commit sha 88be2e1b94c3d4cb3a68022fded27d712cb56916

fix: disable localization of `lscpu`. (#186) The output of `lscpu` is localized. It means that `lscpu | grep Architecture` may return an empty result. This commit fixes the issue. Resolves [#185](https://github.com/kylef/swiftenv/issues/185).

view details

push time in a day

issue closedkylef/swiftenv

[install] `find_binary_url_from_api()` doesn't accommodate multilingual localization on non-macOS.

Here: https://github.com/kylef/swiftenv/blob/162cbff87313f44e38340a0d1bfb2632fd377ff7/libexec/swiftenv-install#L217-L220

The output of lscpu is localized. For example, when you set LANG=ja_JP.UTF-8, you can see the result like below:

アーキテクチャ:                      x86_64
CPU 操作モード:                      32-bit, 64-bit
バイト順序:                          Little Endian
:
: <omit>

Consequently, since grep Architecture returns an empty output, it means cpu_arch becomes an empty string. Next, architecture="-$cpu_arch" begets the result that architecture is "-". Thus, a wrong url is generated such as "https://swift.org/builds/swift-5.5-release/ubuntu2004/swift-5.5-RELEASE/swift-5.5-RELEASE-ubuntu20.04-.tar.gz" that is never found.

I think LANG=C or LC_ALL=C is required.

closed time in a day

YOCKOW

pull request commentkylef/PathKit

fix build on Xcode 13 RC

@diederich what about somthing like this:

guard let ... = strdup(...) else {
  fatalError("strdup return null: Likely out of memory")
}

Potentially message can contain string interpolation for the errno if that's exposed.

diederich

comment created time in 3 days

pull request commentircv3/ircv3-specifications

Add Web Push Extension

Do you intent to add a command to view the list of subscriptions? I could see how as a user this could be useful to debug problems and be able to manually clean up or unsubscribe old clients for which you do not know the subscription URL for. This could very well be something that a NickServ or similar service could facilitate for a user and not be included in the spec though.

emersion

comment created time in 4 days

push eventcocodelabs/api.palaverapp.com

Kyle Fuller

commit sha cb517a2cd1dea12fadf4f72147fecf0105cbd717

fix: include missing Message

view details

push time in 4 days

push eventcocodelabs/api.palaverapp.com

Kyle Fuller

commit sha 4893d25c389599f2bf3931ab2445ca6e6d2f7435

feat: support text/irc for subscription events

view details

push time in 4 days

pull request commentkylef/swiftenv

Redirect 'swift --version' stderr to /dev/null

Thanks for catching and fixing this @bscothern

bscothern

comment created time in 4 days

push eventkylef/swiftenv

Braden Scothern

commit sha 162cbff87313f44e38340a0d1bfb2632fd377ff7

fix: redirect 'swift --version' stderr to /dev/null (#184) With the new swift driver running 'swift --version' will always print "swift-driver version: X.Y.Z" to stderr before printing the normal version info to stdout. This causes all of the version checks as swiftenv runs to print the driver over and over. The other option is to instead pass the flag '-disallow-use-new-driver' but at some point the new driver will most likely become the only driver so this future proofs against that.

view details

push time in 4 days

PR merged kylef/swiftenv

Redirect 'swift --version' stderr to /dev/null

With the new swift driver running 'swift --version' will always print "swift-driver version: X.Y.Z" to stderr before printing the normal version info to stdout. This causes all of the version checks as swiftenv runs to print the driver over and over. The other option is to instead pass the flag '-disallow-use-new-driver' but at some point the new driver will most likely become the only driver so this future proofs against that.

+1 -1

0 comment

1 changed file

bscothern

pr closed time in 4 days

Pull request review commentircv3/ircv3-specifications

Add Web Push Extension

+---+title: "Web Push Extension"+layout: spec+copyrights:+  - name: "Simon Ser"+    period: "2021"+    email: "contact@emersion.fr"+---++## Notes for implementing work-in-progress version++This is a work-in-progress specification.++Software implementing this work-in-progress specification MUST NOT use the unprefixed `webpush` CAP name. Instead, implementations SHOULD use the `draft/webpush` CAP name to be interoperable with other software implementing a compatible work-in-progress version. The final version of the specification will use unprefixed CAP names.++## Description++Historically, IRC clients have relied on keeping a TCP connection alive to receive notifications about new events. However, this design has limitations:++- It doesn't bode well with some platforms such as Android, iOS or the Web. On these platforms, the connection to the IRC server can be severed (e.g. when the IRC client isn't in the foreground), resulting in IRC events not received.+- Battery-powered devices aim to avoid any unnecessary wake-up of the modem hardware. IRC connections don't make the difference between messages which may be important to the user (e.g. messages targeting the user directly) and the rest of the messages. As a result messages are frequently sent over the IRC connection, resulting in battery drain.++To address these limitations, various push notification mechanisms have been designed. This specification standardizes an extension for Web Push.++```+      ┌────────────┐              ┌────────────┐+      │            │  Subscribe   │            │+      │            ├─────────────►│            │+      │ IRC client │              │ IRC server │+      │            │              │            │+      │            │              │            │+      └────────────┘              └─────┬──────┘+             ▲                          │+             │                          │+        Push │                          │Push+notification │                          │notification+             │       ┌──────────┐       │+             │       │          │       │+             └───────┤ Web Push │◄──────┘+                     │  Server  │+                     │          │+                     └──────────┘+```++Web Push is defined in [RFC 8030], [RFC 8291] and [RFC 8292].++Although Web Push has been designed for the Web, it can be used on other platforms as well. Web Push provides a vendor-neutral standard to send push notifications.++## Implementation++The `webpush` capability allows clients to subscribe to Web Push and receive+notifications for messages of interest.++Once a client has subscribed, the server will send push notifications for a+server-defined subset of IRC messages. Each push notification MUST contain+exactly one IRC message as the payload, without the final CRLF.++## `WEBPUSH` Command++A new `WEBPUSH` command is introduced. It has a case-insensitive subcommand:++    WEBPUSH <subcommand> <params...>++### `VAPIDPUBKEY` Subcommand++The `VAPIDPUBKEY` subcommand allows clients to query the [Voluntary Application Server Identification (VAPID)][RFC 8292] public key of the server. This can be used to decrypt notifications upon reception.++The client can query the VAPID public key by sending the command:++    WEBPUSH VAPIDPUBKEY++The server will reply with a [URL-safe base64-encoded][RFC 4648 section 5] public key usable with the Elliptic Curve Digital Signature Algorithm (ECDSA) over the P-256 curve.++    WEBPUSH VAPIDPUBKEY <key>++### `REGISTER` Subcommand++The `REGISTER` subcommand creates a new Web Push subscription.++    WEBPUSH REGISTER <endpoint> <keys>++The `<endpoint>` is an URL pointing to a push server, which can be used to send push messages for this particular subscription.++`<keys>` is a string encoded in the message-tag format. The values are [URL-safe base64-encoded][RFC 4648 section 5]. It MUST contain at least:++- One public key with the name `p256dh` set to the client's P-256 ECDH Diffie-Hellman public key.+- One shared key with the name `auth` set to a client-generated authentication secret.

The set of specifications surrounding web push are separated into individual RFCs. RFC8030 does not mandate encryption nor an single encryption standard.

Whereas here we have one specification that defines both the web push capabilities, how to negotiate clients which requires one specific encryption mechanisms. This doesn't appear to be the case for web push.

RFC 8030 "Generic Event Delivery Using HTTP Push" specifies:

Examples do not include specific methods for push message encryption or application server authentication because the protocol does not define a mandatory system. The examples in Voluntary Application Server Identification [VAPID] and Message Encryption for WebPush [ENCRYPT] demonstrate the approach adopted by the W3C Push API [API] for its requirements.

RFC8291 on its own only describes how to use this particular algorithm and does not describe how web push works. This RFC can be replaced on its own.

This is similar to how IRCv3 has specified SASL, the mechanisms are separate specs which live in their own lifecycle from core SASL.

emersion

comment created time in 4 days

PullRequestReviewEvent

Pull request review commentircv3/ircv3-specifications

Add Web Push Extension

+---+title: "Web Push Extension"+layout: spec+copyrights:+  - name: "Simon Ser"+    period: "2021"+    email: "contact@emersion.fr"+---++## Notes for implementing work-in-progress version++This is a work-in-progress specification.++Software implementing this work-in-progress specification MUST NOT use the unprefixed `webpush` CAP name. Instead, implementations SHOULD use the `draft/webpush` CAP name to be interoperable with other software implementing a compatible work-in-progress version. The final version of the specification will use unprefixed CAP names.++## Description++Historically, IRC clients have relied on keeping a TCP connection alive to receive notifications about new events. However, this design has limitations:++- It doesn't bode well with some platforms such as Android, iOS or the Web. On these platforms, the connection to the IRC server can be severed (e.g. when the IRC client isn't in the foreground), resulting in IRC events not received.+- Battery-powered devices aim to avoid any unnecessary wake-up of the modem hardware. IRC connections don't make the difference between messages which may be important to the user (e.g. messages targeting the user directly) and the rest of the messages. As a result messages are frequently sent over the IRC connection, resulting in battery drain.++To address these limitations, various push notification mechanisms have been designed. This specification standardizes an extension for Web Push.++```+      ┌────────────┐              ┌────────────┐+      │            │  Subscribe   │            │+      │            ├─────────────►│            │+      │ IRC client │              │ IRC server │+      │            │              │            │+      │            │              │            │+      └────────────┘              └─────┬──────┘+             ▲                          │+             │                          │+        Push │                          │Push+notification │                          │notification+             │       ┌──────────┐       │+             │       │          │       │+             └───────┤ Web Push │◄──────┘+                     │  Server  │+                     │          │+                     └──────────┘+```++Web Push is defined in [RFC 8030], [RFC 8291] and [RFC 8292].++Although Web Push has been designed for the Web, it can be used on other platforms as well. Web Push provides a vendor-neutral standard to send push notifications.++## Implementation++The `webpush` capability allows clients to subscribe to Web Push and receive+notifications for messages of interest.++Once a client has subscribed, the server will send push notifications for a+server-defined subset of IRC messages. Each push notification MUST contain+exactly one IRC message as the payload, without the final CRLF.

Would the message follow the same capabilities and respect the same 005 isupport as when the client registered?

emersion

comment created time in 5 days