Re: [swift-corelibs-dev] [swift-evolution] Language or XCTest improvements to allow testing assert/precondition failures

> On Dec 13, 2015, at 2:03 AM, David Hart via swift-evolution > wrote: > > Currently, it is impossible for XCTest to unit test assert and precondition > failures because they kill the process. And those are important to unit test: > how would you test NSArray's objectAtIndex bound conditions?

Re: [swift-corelibs-dev] [xctest] Terminology: What to call "swift-corelibs-xctest" and "Apple XCTest"

I believe we have been saying "Corelibs XCTest", but agree it would be nice to have a standard labelling. - Daniel > On Dec 22, 2015, at 11:57 PM, Brian Gesiak via swift-corelibs-dev > wrote: > > Hello all, > > I've been referring to the project hosted at > https://github.com/apple/swift-co

Re: [swift-corelibs-dev] corelibs-xctest + swiftpm

I think this makes sense (and commented in your PR). For now we will still need the manual build process because we need XCTest to build first in CI, so that we can use it in building/testing the package manager itself, but it certainly makes sense to shoot for it to just be yet another package.

Re: [swift-corelibs-dev] [SE-0046] Implemented consistent function labels

> On Apr 7, 2016, at 10:15 AM, Daniel Eggert via swift-corelibs-dev > wrote: > > With this being merged > > https://github.com/apple/swift-corelibs-foundation/pull/305 > > where do I find a compiler that works? Everything stopped working for me, > because utils/update-checkout currently chec

Re: [swift-corelibs-dev] NSURLSession & libcurl

> On Apr 20, 2016, at 9:43 AM, Daniel Eggert via swift-corelibs-dev > wrote: > > I think that would make a giant mess. I'm curious how far off we are for > having lob libdispatch on Linux. I think it would be worth waiting a bit > longer I n stead of making the code illegible. Just my 2¢. +1

Re: [swift-corelibs-dev] swift-corelibs-xctest JIRA dashboard

Following up on Brian's JIRA dashboard for XCTest, I copied his model and created a dashboard for SwiftPM: https://bugs.swift.org/secure/Dashboard.jspa?selectPageId=10409 and defined several useful SwiftPM public filters: - Package Manager All Tasks: https://bugs.swift.org/issues/?filter=10477

Re: [swift-corelibs-dev] Objective-C Foundation vs CoreLibs Foundation

> On May 23, 2016, at 3:34 PM, Philippe Hausler via swift-corelibs-dev > wrote: > > There are a few considerations for the package manager: we may have circular > build requirements, swift-corelibs-foundation does some squirrelly things > with linking and compilation like linker scripts and t

[swift-corelibs-dev] [RFC] Toolchain based build process

Hi all, The current build process for the overall Swift project (i.e., the compiler + associated projects like Foundation, XCTest, and SwiftPM) relies on each project having dependencies on the built artifacts of previously built projects. Those dependencies are currently communicated to each p

Re: [swift-corelibs-dev] [swift-dev] [RFC] Toolchain based build process

> On Jun 3, 2016, at 1:14 PM, Saleem Abdulrasool wrote: > > On Wed, Jun 1, 2016 at 2:18 PM, Daniel Dunbar via swift-dev > mailto:swift-...@swift.org>> wrote: > Hi all, > > The current build process for the overall Swift project (i.e., the compiler + > associated projects like Foundation, XCTe

Re: [swift-corelibs-dev] [swift-build-dev] [swift-dev] [RFC] Toolchain based build process

Hi Karl, On Fri, Jun 10, 2016 at 2:38 AM, Karl via swift-build-dev < swift-build-...@swift.org> wrote: > We can’t separate building for ‘Build’ and building for an arbitrary > ‘Host’. For those who don’t know, this is how cross-compiling works with > Swift (this isn’t off-topic, I’m going to brin

Re: [swift-corelibs-dev] Wrapping up Swift 3 for swift-corelibs

Can someone file a bug to track how we are going to resolve this issue, and outline our options? I want to make sure we have enough eyes on it to make sure we get what we need for Swift 3. - Daniel > On Aug 1, 2016, at 3:08 AM, Chris Bailey wrote: > > I had a quick conversation with Daniel D

Re: [swift-corelibs-dev] [swift-build-dev] JIRA workflow: "Resolved" -> "Verify"?

Do we anticipate Verify being used in practice much? Would it be better to simplify the workflow and just have a single "Resolved/Closed/Done" state? If the originator does test the bug and find it isn't fixed, they can reopen. My guess is not that many people are going to actively look at the

Re: [swift-corelibs-dev] [swift-dev] [Swift CI] Build Still Failing: 0. OSS - Swift Incremental RA - Ubuntu 14.04 - Long Test (swift 3.0) #302

Alternately, we could change their build scripts to generate llbuild manifest files and build using llbuild (which tracks the Swift compiler version automatically as a dependency). This is why SwiftPM doesn't usually hit this problem, for example. - Daniel > On Sep 24, 2016, at 7:57 PM, Micha

Re: [swift-corelibs-dev] [swift-dev] [Swift CI] Build Still Failing: 0. OSS - Swift Incremental RA - Ubuntu 14.04 - Long Test (swift 3.0) #302

> On Sep 24, 2016, at 9:33 PM, Michael Gottesman wrote: > > >> On Sep 24, 2016, at 8:15 PM, Daniel Dunbar > > wrote: >> >> Alternately, we could change their build scripts to generate llbuild >> manifest files and build using llbuild (which tracks the Swift com

Re: [swift-corelibs-dev] Better integration with UNIX tools

> On Dec 1, 2017, at 6:28 AM, Ian Partridge via swift-corelibs-dev > wrote: > > Hi Nick, > > You might be interested in the new Utility project that the Package > Manager team have published. It has a bunch of Foundation-esque > features including subprocess support, temporary file, progress