profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/hartbit/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.
David Hart hartbit Atipik Sàrl & Witty Wings SA Geneva, Switzerland

apple/swift 55769

The Swift Programming Language

apple/swift-evolution 12168

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

apple/swift-package-manager 8244

The Package Manager for the Swift Programming Language

apple/swift-corelibs-foundation 4250

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

apple/swift-corelibs-xctest 894

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

apple/swift-lldb 650

This is the version of LLDB that supports the Swift programming language & REPL.

apple/swift-tools-support-core 228

Contains common infrastructural code for both SwiftPM and llbuild.

hartbit/base16-schemes-source 1

A common list of schemes for base16-builders

hartbit/accelerated-cpp 0

Exercises for Accelerated C++

hartbit/AdventOfCode2017 0

Repository of my Advent of Code 2017 solutions

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 6 hours

pull request commentapple/swift-package-manager

[SE-0301] Package Editor Commands Implementation

@swift-ci please smoke test

owenv

comment created time in 6 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 6 hours

pull request commentapple/swift-package-manager

[5.4] [Bootstrap] Do not pass `-Ddispatch_DIR` to the Yams CMake build (#3363)

Seems fine to me, though I don't have a lot of context for why this was there in the first place (other than your description, which is very helpful).

shahmishal

comment created time in 10 hours

Pull request review commentapple/swift-package-manager

Fix swift package init --help printout

 extension SwiftPackageTool {         }     } -    struct Init: SwiftCommand {+    struct Init: SwiftCommand, CustomReflectable {+        var customMirror: Mirror {+            return Mirror(self, children: ["initMode": self._initMode, "packageName": self._packageName as Any])+        }+                 static let configuration = CommandConfiguration(             abstract: "Initialize a new package")+        +        static let includeSuperCommandInHelp = false

We decided against requiring this bit for the ArgumentParser change.

miggs597

comment created time in 11 hours

pull request commentapple/swift-package-manager

add delegate to track events from the dependency resolver

@swift-ci please smoke test

tomerd

comment created time in 11 hours

push eventapple/swift-package-manager

Anders Bertelrud

commit sha 2bb3e5eabcb37db24881020f277adb4a78978005

Add compiler diagnostics to a test that sometimes fails in CI due to what seem to be module rebuilding issues. The diagnostics are only shown if the test fails; they don't pollute the regular output. (#3424)

view details

push time in 13 hours

PR merged apple/swift-package-manager

Reviewers
Add compiler diagnostics to a test that sometimes fails in CI ready

This test sometimes fails due to what seem to be module rebuilding issues. The diagnostics are only shown if the test fails; they don't pollute the regular output.

+5 -4

1 comment

1 changed file

abertelrud

pr closed time in 13 hours

pull request commentapple/swift-package-manager

Check what compiler flags are available

Yes @abertelrud we can merge!

miggs597

comment created time in 15 hours

pull request commentapple/swift-package-manager

[WIP] add delegate to track events from the dependency resolver

I think I want to modulate this statement ("all optional"): since the delegate itself is optional, it might make sense to define the "major" events that the delegate just has to implement, and then maybe some of the minor ones could be optional (have default implementations that don't do anything). Or should they all be optional for consistency, especially since any new ones that get added later will have to be optional for compatibility reasons (until libSwiftPM is properly versioned). WDYT?

I actually dislike the current pattern in SwiftPM where we have empty implementation for delegates to make them seem optional. sure, it makes life easier for the caller when they first add a delegate but it makes it very difficult to properly evolve the delegate API inc. deprecations as the default empty ones hide the fact that that API changed from the caller making these into runtime issues. in other words, I'd like to see us factor out all the default empty delegate extensions so that the caller can decide explicitly what to ignore and be notified when we deprecate delegate APIs.

tomerd

comment created time in 15 hours

pull request commentapple/swift-package-manager

Check what compiler flags are available

@miggs597 do you feel this is ready to merge?

miggs597

comment created time in 15 hours

pull request commentapple/swift-package-manager

[WIP] add delegate to track events from the dependency resolver

I think having a delegate that's 1:1 with the only current resolver makes sense to me, we can choose to not emit logs for every callback if we want to. I don't think we will know enough to have a differently shaped delegate until we would actually have more than one resolver implementation.

100%. As Boris says, the callbacks should reflect what's actually happening. Individual delegates can then easily choose to ignore some of them, as long as they are all optional.

I think I want to modulate this statement ("all optional"): since the delegate itself is optional, it might make sense to define the "major" events that the delegate just has to implement, and then maybe some of the minor ones could be optional (have default implementations that don't do anything). Or should they all be optional for consistency, especially since any new ones that get added later will have to be optional for compatibility reasons (until libSwiftPM is properly versioned). WDYT?

tomerd

comment created time in 15 hours

pull request commentapple/swift-package-manager

[WIP] add delegate to track events from the dependency resolver

I think having a delegate that's 1:1 with the only current resolver makes sense to me, we can choose to not emit logs for every callback if we want to. I don't think we will know enough to have a differently shaped delegate until we would actually have more than one resolver implementation.

100%. As Boris says, the callbacks should reflect what's actually happening. Individual delegates can then easily choose to ignore some of them, as long as they are all optional.

tomerd

comment created time in 15 hours

push eventapple/swift-package-manager

Anders Bertelrud

commit sha d46052e5762f075b95f440fbbcf15087ed798b7b

Pass `-parse-as-library` when compiling an executable module that has a single source file that isn't named `main.swift` (#3410) (#3421) The Swift compiler has certain special behaviors regarding main source files: - if a module has just a single source file of any name, it's treated as the main source file - if a module has a source file named `main.swift`, it's treated as the main source file If a source file is considered the main source file, it can have top level code. But a source file that has top level code can't also have `@main`. This means that a single source file executable module can't use `@main`, regardless of the name of that source file. A second empty source file can be added as a workaround, but we can employ some countermeasures in SwiftPM. Specifically, if the executable module consists of a single source file and it is not named `main.swift`, we pass `-parse-as-library` so that a single-source file module will work. This matches what can be seen in the build logs in Xcode, meaning that packages will build the same in SwiftPM and in Xcode. Note that this still does not allow use of `@main` in source files named `main.swift`, but that will require compiler support to address. Since this has the potential to break existing packages that use top-level code in a single source file that isn't named `main.swift`, this behavior is gated by a 5.5 tools version. See https://bugs.swift.org/browse/SR-14488 for discussion about improvements so that SwiftPM can convey the intent to build an executable module to the compiler regardless of the number of files in the module or their names. rdar://76746150 (cherry picked from commit 41b97c87dfd37dc263abc4975a65b7d5042e00be)

view details

push time in 15 hours

PR merged apple/swift-package-manager

Reviewers
[5.5] Pass compiler flags to alllow use of @main in single-source-file executable modules 5.5 ready

This is the 5.5 nomination of https://github.com/apple/swift-package-manager/pull/3410 which makes it possible to have single-file source modules with a @main by taking the same approach as Xcode does when building such modules (also increasing compatibility of packages between SwiftPM and Xcode).

The original PR is https://github.com/apple/swift-package-manager/pull/3410 and has a lot more details.

+79 -7

1 comment

3 changed files

abertelrud

pr closed time in 15 hours

push eventapple/swift-package-manager

Anders Bertelrud

commit sha 15f716a131202fad064c3e04d7d2d12bbdcb2908

The logic to generate manifest source from existing parsed manifest data structures misquoted some package version requirement ranges. (#3415) (#3422) This fixes those cases, producing a semantically equivalent package manifests. Since the model does not capture how a particular range was specified, it is not possible to recreate the original shorthands. A future improvement can either extend the model to record the original spelling of the range requirements, or can apply heuristics to shorten the rules in the future (e.g. automatically derive `upToNextMajor()` etc. This also eliminates an extra whitespace before the minimum tools version declaration when the specified tools version allows it, so older parsers can parse the generated manifests. rdar://76559428 (cherry picked from commit 8ee8d407133420fac2ac9928ba26d5d91374c554)

view details

push time in 15 hours

PR merged apple/swift-package-manager

Reviewers
[5.5] Fix a problem in the logic to generate manifest source from existing parsed manifest structs 5.5 ready

This is the 5.5 nomination of https://github.com/apple/swift-package-manager/pull/3415 which fixes a problem serializing package manifests with ranged package dependencies.

+39 -4

1 comment

2 changed files

abertelrud

pr closed time in 15 hours

pull request commentapple/swift-package-manager

Use forwarding symlinks to reduce toolchain installation size

@owenv This looks ready to merge at this point. Thanks again!

owenv

comment created time in 16 hours

pull request commentapple/swift-package-manager

Use forwarding symlinks to reduce toolchain installation size

@abertelrud sure, that makes sense to me. I dropped the underscored target, but kept the ones for swift-build, swift-test, etc. since they're still useful when not using the install action.

Absolutely, I did not mean to suggest removing the existing executables, only not adding the new underscored one. The existing ones are very useful during debug builds (in fact I use them all the time when working on SwiftPM in Xcode, using the scheme that's autocreated for each of them — and I suspect others use them in this was as well).

Perhaps in the future once we can create arbitrary symlinks during a debug build (perhaps with a postbuild action) we'll be able to remove them, but that's a ways off.

owenv

comment created time in 16 hours

pull request commentapple/swift-package-manager

[SE-0301] Package Editor Commands Implementation

@owenv The changes themselves look good to me, but I think the setting of the environment variable in the bootstrap script needs to be made conditional on whether or not SwiftSyntax is available — otherwise it will be somewhat difficult to test other parts of the bootstrap script on the desktop without having the right compiler checked out, etc.

In fact I haven't yet been able to get this to work with a swift-syntax checkout that ought to work in theory (even though that checkout does build cleanly on its own, with a matching compiler next to it).

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.

owenv

comment created time in 16 hours

pull request commentapple/swift-package-manager

Add compiler diagnostics to a test that sometimes fails in CI

@swift-ci please smoke test

abertelrud

comment created time in 16 hours

PR opened apple/swift-package-manager

Add compiler diagnostics to a test that sometimes fails in CI

This test sometimes fails due to what seem to be module rebuilding issues. The diagnostics are only shown if the test fails; they don't pollute the regular output.

+5 -4

0 comment

1 changed file

pr created time in 16 hours

PR opened apple/swift-package-manager

[5.4] [Bootstrap] Do not pass `-Ddispatch_DIR` to the Yams CMake build (#3363)

With the version-bump of Yams in https://github.com/apple/swift/pull/36366, Yams 4.0.2 now actually expresses the dependency on Dispatch in its CMake config.

With the current behavior of passing -Ddispatch_DIR to its CMake build, we have the following problem on Linux:

  • swift's build-script installs Dispatch into a just-built toolchain which we use to build SwiftPM, which will contain, among other things, the Dispatch .swiftmodule.
  • The compiler workspace checkout of swift-corelibs-libdispatch also contains a copy of the Dispatch .swiftmodule.

Both of these will be found, leading to build failures like:

/home/buildnode/jenkins/workspace/swift-PR-Linux/branch-main/swift-nightly-install/usr/lib/swift/dispatch/module.modulemap:1:8: error: redefinition of module 'Dispatch'
19:37:47 module Dispatch {
19:37:47        ^
19:37:47 /home/buildnode/jenkins/workspace/swift-PR-Linux/branch-main/swift-corelibs-libdispatch/dispatch/module.modulemap:1:8: note: previously defined here
19:37:47 module Dispatch {
19:37:47        ^
19:37:47

We also cannot put off building libDispatch until SwiftPM is built, because the libDispatch dylib is required to link SwiftPM. Not passing -Ddispatch_DIR to Yams' CMake build causes it to successfully locate the Dispatch package in the just-built toolchain on its own.

(cherry picked from commit 6af862d3a7efb3108334be0d3e3e33641c91f267)

[One line description of your change]

Motivation:

[Explain here the context, and why you're making that change. What is the problem you're trying to solve.]

Modifications:

[Describe the modifications you've done.]

Result:

[After your change, what will change.]

+0 -3

0 comment

1 changed file

pr created time in 17 hours

pull request commentapple/swift-package-manager

[WIP] add delegate to track events from the dependency resolver

I think having a delegate that's 1:1 with the only current resolver makes sense to me, we can choose to not emit logs for every callback if we want to. I don't think we know enough to have a differently shaped delegate until we would actually have more than one resolver implementation.

tomerd

comment created time in 18 hours

pull request commentapple/swift-package-manager

[5.5][Collections] Better handling of spaces in collection file path

@swift-ci please test linux

yim-lee

comment created time in 19 hours

startedonmyway133/PushNotifications

started time in 21 hours

startednathanvda/cocoon

started time in a day

created tagapple/swift-package-manager

tagswift-5.5-DEVELOPMENT-SNAPSHOT-2021-04-19-a

The Package Manager for the Swift Programming Language

created time in a day