profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/BenchR267/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.
Benjamin Herzog BenchR267 Berlin, Germany https://blog.bens.life/cv.pdf  Dev Tools

orta/ARAnalytics 1836

Simplify your iOS/Mac analytics

BenchR267/Get-Schwifty 90

Get Schwifty is a self-hosted Swift transpiler and was originally build for my WWDC scholarship application.

BenchR267/Parsel 21

Create complex parsers by combining simple ones with Parsel!

kiliankoe/Alfred 20

Build awesome Alfred workflows with Swift!

BenchR267/TouchPresenter 18

Highlights every touch with a given view to create better video presentations of your app.

BenchR267/lbd 9

Learning By Doing - my own programming language to learn how to write a compiler toolchain. Follow my progress at http://blog.benchr.de/tags/compiler/

BenchR267/goalfred 6

Go package to simplify writing Alfred workflows

BenchR267/Pod-Search-Alfred 6

Use this workflow to find pods in Alfred and open their Github page.

BenchR267/htwcampus_old 4

Offizielle iOS-App für Studenten und Dozenten der HTW Dresden.

BenchR267/Resty 4

https://blog.benchr.me/post/pop-network-1/

push eventapple/swift-syntax

Kim de Vos

commit sha 9107c1992585c68439acac5650b9c50bc12e2f2e

Add Buildable gyb

view details

Alex Hoppen

commit sha 8319e756104c5c12575970de7383204a0faca3b0

Merge pull request #268 from kimdv/kimdv/add-buildable-gyb Add Buildable gyb

view details

push time in 2 hours

PR merged apple/swift-syntax

Add Buildable gyb

From #263

2. Actually create the Buildable types

I think with that we’re already to the main part. Here is a random collection on thoughts, how I would approach it. Again a disclaimer: I haven’t tested any of this and it might be whofully wrong.

First off, I would try and get a raw API up and running. At this stage, I wouldn’t worry about a nice API or result builders yet, I would just want to get an initialiser-based API up and running with which all syntax nodes can be created.

  • As a baseline, I would start with SyntaxBuilders.swift and modify it according to our needs.
  • I wouldn’t be too focused on the current design of the buildables since we probably can’t automatically re-create a generic modelling like it’s currently done for variables here. I’m fine with any design that’s easy to use and we are not concerned about source breakage here.
  • As a first step, I would try modifying the SyntaxBuilders so they are purely initialiser based, that is all children are passed in the initialiser and we don’t need the use* methods anymore.

After this, I am expecting the API to be much worse than it is today, but it should be exhaustive now. This means, we now need to make it easy to use again. I’ve got a couple of (more or less) necessary improvements in my head already, I’m sure there are more once you get to it.

  • Of course the entire result builder thing. Any syntax collection should be buildable using a corresponding result builder.

  • Any non-optional token without custom text (i.e. a keyword or punctuator) ccan be implicitly synthesized and does not have a corresponding argument in the initialiser

    • Example: We don't need to specify the open { for a struct decl.
  • And as far as I can tell we’re now already at a stage, where custom specialisations are needed. These can be made in a separate file through extensions.

    • Example: According to the specification of a VariableDecl, it is (simplified) a var/let keyword with a following PatternBindingList. But that’s not how anybody thinks about a Var decl. We should create an initialiser that’s closer to what we have today, which correctly creates the pattern binding etc.
    • Example: According to the definition of a StructDecl, it takes its members as a MemberDeclBlock, consisting of a pair of braces and decls which might be followed by a semicolon. The braces can already be implicitly synthesized as described above and nobody cares about semicolons. So we should have a specialised initialiser taking a list of decls (through a result builder) that correctly creates the MemberDeclBlock etc.

I think the advantage of this approach (auto-generate a exhaustive, but verbose API and add convenience extensions on top) apposed to the previous approach (hand write everything), is that there is always a fall-back to create every syntax element, even cutting-edge ones. I expect the convenience initialisers to concern the most commonly used syntax elements, which should also be the most stable, so I expect they should be fairly easy to maintain.

What do you think @kimdv? Does this sound good to you?

Okay, now we are ready for the next step. 🚀 (I have modified this file, not sure if it is the right, but then we can start a conversation)

I'm a little confused on how I should approach this.

  • As a baseline, I would start with SyntaxBuilders.swift and modify it according to our needs.
  • I wouldn’t be too focused on the current design of the buildables since we probably can’t automatically re-create a generic modelling like it’s currently done for variables here. I’m fine with any design that’s easy to use and we are not concerned about source breakage here.
  • As a first step, I would try modifying the SyntaxBuilders so they are purely initialiser based, that is all children are passed in the initialiser and we don’t need the use* methods anymore.

So the idea is that inside etc StructDeclSyntaxBuilder should not have add* but all possibilities should be basses within the init method?

+8775 -500

11 comments

12 changed files

kimdv

pr closed time in 2 hours

issue commentapple/swift-collections

Fatal error: unsupported: file Swift/ArrayBuffer.swift, line 231

Cc @atrick

Interesting; this is triggering this precondition in the standard library:

extension _ArrayBuffer {
  ...
  public __consuming func _copyContents(
    initializing buffer: UnsafeMutableBufferPointer<Element>
  ) -> (Iterator,UnsafeMutableBufferPointer<Element>.Index) {
    // This customization point is not implemented for internal types.
    // Accidentally calling it would be a catastrophic performance bug.
    fatalError("unsupported")
  }
}

Deque is merely calling the public withContiguousStorageIfAvailable method on the supplied argument -- this ought to be safe on all collections.

Note: the arrayLiteral initializer simply forwards to NSArray(array:). The NSString object is irrelevant -- this also reproduces with any NSObject:

let array = NSArray(array: [NSObject()]) as! [NSObject]
let deque = Deque(array) // 💥

It looks like verbatim-bridged NSArrays are currently broken in the stdlib.

mdznr

comment created time in 5 hours

delete branch apple/swift-driver

delete branch : cherry-pick-433c66dbe644f5beb6adb9127eba7e838489a707

delete time in 5 hours

push eventapple/swift-driver

Artem Chikin

commit sha e2bbad1a911c905574ea5d1d196526d4199659f0

Remove target `x86_64` specialization from `testExplicitModuleBuildEndToEnd` (cherry picked from commit 433c66dbe644f5beb6adb9127eba7e838489a707)

view details

Mishal Shah

commit sha d72c0b85721cf74c101756c55edb128a13372d49

Merge pull request #612 from apple/cherry-pick-433c66dbe644f5beb6adb9127eba7e838489a707 [5.5] Remove target `x86_64` specialization from `testExplicitModuleBuildEn…

view details

push time in 5 hours

PR merged apple/swift-driver

[5.5] Remove target `x86_64` specialization from `testExplicitModuleBuildEn…

…dToEnd`

(cherry picked from commit 433c66dbe644f5beb6adb9127eba7e838489a707)

+3 -3

1 comment

3 changed files

shahmishal

pr closed time in 5 hours

push eventapple/swift-atomics

Akis Kesoglou

commit sha 7e101a5653b91a91d84ff9cf4f5303e0fa9c1938

Mark the additional Bool methods as public …inline with the static methods on AtomicStorage and AtomicIntegerStorage.

view details

Karoy Lorentey

commit sha a27aa0d6d165d742ed03f6a63cac0589f39a4215

Merge pull request #24 from dfunckt/main Mark the additional Bool methods as public

view details

push time in 5 hours

PR merged apple/swift-atomics

Mark the additional Bool methods as public

…inline with the static methods on AtomicStorage and AtomicIntegerStorage.

+4 -4

2 comments

2 changed files

dfunckt

pr closed time in 5 hours

issue commentapple/swift-atomics

cannot support Cocoapods

Adding support for alternate build systems is a maintenance burden we are ill-prepared to handle. I'd much prefer to encourage the use of the Swift Package Manager going forward. Apologies if this seems overly cautious; I understand it is inconvenient not to be able to directly use this repository.

If for some reason you must support build systems that aren't compatible with SPM, then vendoring this library is one way to still depend on it. (The license explains the conditions you need to meet when redistributing the code.)

(Adding support for CMake in #25 already makes me very uncomfortable -- and that's a strictly temporary thing, enabling potential adoption of these packages in the package manager itself while the Windows port is being bootstrapped.)

chunxige

comment created time in 5 hours

pull request commentapple/swift-source-compat-suite

Drop Kingfisher 4.0 configuration

@clackary We can close this PR in favor of #528

clackary

comment created time in 5 hours

pull request commentapple/swift-source-compat-suite

Drop Kingfisher 4.0 configuration

@onevcat Thanks!

clackary

comment created time in 5 hours

pull request commentapple/swift-source-compat-suite

Fix Kingfisher build by the new scheme settings

@swift-ci test

onevcat

comment created time in 5 hours

pull request commentapple/swift-source-compat-suite

Drop Kingfisher 4.0 configuration

@shahmishal Sorry for the confusion but #528 should bring the tests back to normal.

clackary

comment created time in 5 hours

PR opened apple/swift-source-compat-suite

Fix Kingfisher build by the new scheme settings

This is a fix for #527

It now succeeds as below:

--- Executing build actions ---
$ /Users/onevcat/Desktop/swift-source-compat-suite/runner.py --swift-branch swift-5.1-branch --swiftc /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swiftc --projects /Users/onevcat/Desktop/swift-source-compat-suite/projects.json --include-repos 'path == "Kingfisher"' --include-versions 'version == "5.1"' --include-actions 'action.startswith("Build")'
$ git -C /Users/onevcat/Desktop/swift-source-compat-suite/project_cache/Kingfisher rev-parse --show-toplevel
PASS: Kingfisher, 5.1, 44450a, Kingfisher, generic/platform=iOS
$ git -C /Users/onevcat/Desktop/swift-source-compat-suite/project_cache/Kingfisher rev-parse --show-toplevel
PASS: Kingfisher, 5.1, 44450a, Kingfisher, generic/platform=macOS
$ git -C /Users/onevcat/Desktop/swift-source-compat-suite/project_cache/Kingfisher rev-parse --show-toplevel
PASS: Kingfisher, 5.1, 44450a, Kingfisher, generic/platform=tvOS
$ git -C /Users/onevcat/Desktop/swift-source-compat-suite/project_cache/Kingfisher rev-parse --show-toplevel
PASS: Kingfisher, 5.1, 44450a, Kingfisher, generic/platform=watchOS
========================================
Action Summary:
     Passed: 4
     Failed: 0
    XFailed: 0
    UPassed: 0
      Total: 4
========================================
Repository Summary:
      Total: 1
========================================
Result: PASS
========================================
--- Kingfisher checked successfully against Swift 5.1 ---
+4 -8

0 comment

1 changed file

pr created time in 5 hours

pull request commentapple/swift-source-compat-suite

Drop Kingfisher 4.0 configuration

:( Ah, it seems that Xcode schemes are used! (I thought it is already using SPM) These schemes also needs update. I will submit a new PR!

clackary

comment created time in 5 hours

pull request commentapple/swift-source-compat-suite

Drop Kingfisher 4.0 configuration

xcodebuild: error: The workspace named "Kingfisher" does not contain a scheme named "Kingfisher-macOS". The "-list" option can be used to find the names of the schemes in the workspace.
clackary

comment created time in 5 hours

pull request commentapple/swift-source-compat-suite

Drop Kingfisher 4.0 configuration

03:59:04.005 FAIL: Kingfisher, 5.1, 44450a, Kingfisher-macOS, generic/platform=macOS
03:59:04.105 $ git -C /Users/buildnode/jenkins/workspace/swift-PR-source-compat-suite-test-macOS/swift-source-compat-suite/project_cache/Kingfisher rev-parse --show-toplevel
03:59:05.964 FAIL: Kingfisher, 5.1, 44450a, Kingfisher-tvOS, generic/platform=tvOS
03:59:06.065 $ git -C /Users/buildnode/jenkins/workspace/swift-PR-source-compat-suite-test-macOS/swift-source-compat-suite/project_cache/Kingfisher rev-parse --show-toplevel
03:59:07.918 FAIL: Kingfisher, 5.1, 44450a, Kingfisher-watchOS, generic/platform=watchOS
clackary

comment created time in 5 hours

pull request commentapple/swift-atomics

Mark the additional Bool methods as public

@swift-ci test

dfunckt

comment created time in 6 hours

pull request commentapple/swift-atomics

build: add a CMake based build for Atomics

@swift-ci test

compnerd

comment created time in 6 hours

Pull request review commentapple/swift-atomics

build: add a CMake based build for Atomics

+#[[+This source file is part of the Swift Atomics Open Source Project++Copyright (c) 2020 Apple Inc. and the Swift Numerics project authors
Copyright (c) 2021 Apple Inc. and the Swift project authors
compnerd

comment created time in 6 hours

Pull request review commentapple/swift-atomics

build: add a CMake based build for Atomics

+#[[+This source file is part of the Swift Atomics Open Source Project++Copyright (c) 2020 Apple Inc. and the Swift Numerics project authors
Copyright (c) 2021 Apple Inc. and the Swift project authors
compnerd

comment created time in 6 hours

Pull request review commentapple/swift-atomics

build: add a CMake based build for Atomics

+#[[+This source file is part of the Swift Atomics Open Source Project++Copyright (c) 2020 Apple Inc. and the Swift Numerics project authors
Copyright (c) 2021 Apple Inc. and the Swift project authors
compnerd

comment created time in 6 hours

Pull request review commentapple/swift-atomics

build: add a CMake based build for Atomics

+#[[+This source file is part of the Swift Atomics Open Source Project++Copyright (c) 2019 Apple Inc. and the Swift Numerics project authors
Copyright (c) 2021 Apple Inc. and the Swift project authors
compnerd

comment created time in 6 hours

Pull request review commentapple/swift-atomics

build: add a CMake based build for Atomics

+#[[+This source file is part of the Swift Atomics Open Source Project++Copyright (c) 2020 Apple Inc. and the Swift Numerics project authors

For consistency, I believe this should read:

Copyright (c) 2021 Apple Inc. and the Swift project authors
compnerd

comment created time in 6 hours

pull request commentapple/swift-package-manager

Use forwarding symlinks to reduce toolchain installation size

@abertelrud thanks for reviewing! There's no rush, but do you mind merging on my behalf, I don't have commit access to this repo

owenv

comment created time in 7 hours

pull request commentapple/swift-package-manager

[SE-0301] Package Editor Commands Implementation

@swift-ci please smoke test

owenv

comment created time in 7 hours

pull request commentapple/swift-package-manager

[SE-0301] Package Editor Commands Implementation

What do you think about making it conditional on the presence of ../swift-syntax? That would make it be included in the toolchain, etc. We could have it print a warning if it is excluding the functionality that depends on SwiftSyntax.

Thanks for taking a look! I've added this check, plus a new flag, --skip-package-syntax to skip it even if SwiftSyntax is present. I figured that might be helpful if someone is working with a full checkout but doesn't otherwise need perfectly matching dependencies.

owenv

comment created time in 7 hours

issue openedapple/swift-collections

Fatal error: unsupported: file Swift/ArrayBuffer.swift, line 231

<!-- Thanks for contributing to Swift Collections!

Before you submit your issue, please replace each paragraph
below with the relevant details for your bug, and complete
the steps in the checklist by placing an 'x' in each box:

- [x] I've completed this task
- [ ] This task isn't completed

-->

When initializing a Deque from an Array, it crashes at runtime with error:

Fatal error: unsupported: file Swift/ArrayBuffer.swift, line 231

Information

  • Package version: commit 62c3a3a
  • Platform version: macOS 11.2.1 (20D74)
  • Swift version: Apple Swift version 5.3.2 (swiftlang-1200.0.45 clang-1200.0.32.28) Target: x86_64-apple-darwin20.3.0

Checklist

  • [x] If possible, I've reproduced the issue using the main branch of this package.
  • [x] I've searched for existing GitHub issues.

Steps to Reproduce

If I try printing out the array that I’m initializing the Deque with, it works fine:

(lldb) po children
▿ 1 element
  ▿ 0 : <REDACTED._REDACTEDViewController: 0x600001428750>

Trying to create a Deque with it fails:

(lldb) po Deque(children)
Fatal error: unsupported: file Swift/ArrayBuffer.swift, line 231
2021-04-21 17:52:18.287219-0700 REDACTED[92393:19385555] Fatal error: unsupported: file Swift/ArrayBuffer.swift, line 231
error: warning: couldn't get required object pointer (substituting NULL): Couldn't load 'self' because its value couldn't be evaluated

error: Execution was interrupted, reason: EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0).
The process has been returned to the state before expression evaluation.

children is an Array (although it is coming from Objective-C code).

(lldb) po type(of: children)
Swift.Array<__C.NSViewController>

But I can force it to be an Array:

(lldb) po Array(children)
▿ 1 element
  ▿ 0 : <REDACTED._REDACTEDViewController: 0x600001428750>

and strangely initializing a Deque with it works just fine:

(lldb) po Deque(Array(children))
▿ 1 element
  ▿ 0 : <REDACTED._REDACTEDViewController: 0x600001428750>

Expected behavior

Initializing a Deque using an Array shouldn’t crash.

Actual behavior

Initializing a Deque using an Array crashes in some scenarios, although I can’t quite a small exactly why yet.

created time in 10 hours

pull request commentapple/swift-driver

Verify module interfaces generated from emit-module jobs

@swift-ci test

xymus

comment created time in 11 hours

PR opened apple/swift-driver

Reviewers
Verify module interfaces generated from emit-module jobs

The verify job was previously only added after merge-module jobs which is more prone to generate broken swift interfaces.

+48 -3

0 comment

2 changed files

pr created time in 11 hours