Re: [swift-corelibs-dev] [xctest] Who tests the tests?

[Brian Gesiak via swift-corelibs-dev]

I sent up another attempt for this: 
https://github.com/apple/swift-corelibs-xctest/pull/10
Based on the discussion in that pull request, I'm now exploring using lit to 
test the XCTest output. 
Rather than asking contributors to install lit via the Python Package Index, I 
was considering using the apple/llvm repository's copy. Contributors would need 
to have cloned llvm in a specific directory relative to the cloned 
swift-corelibs-xctest, like so:
rootdir/    llvm/    swift-corelibs-xctest/
This appears to be a convention in the Swift family of repositories, so I don't 
anticipate this to cause confusion among contributors.
If anyone has any input on this approach to lit, or on the direction of these 
changes in general, please let me know! All feedback is greatly appreciated.
- Brian Gesiak
_
From: Mike Ferris 
Sent: Friday, December 4, 2015 3:42 PM
Subject: Re: [swift-corelibs-dev] [xctest] Who tests the tests?
To: Brian Gesiak 
Cc: Tony Parker ,  , 
Daniel Dunbar 


   Oops. It was pointed out to me that XCTestObserver is deprecated. I get 
it confused sometimes with its replacement..  What we’d presumably want to 
pursue adding the the corelibs XCTest is the API from XCTestObservation.h (and 
associated stuff). 
   Your same questions about the bundle stuff will still apply, though. On 
the other hand, perhaps a partial implementation that at least allowed 
observation starting at the test suites or even just at the test cases would 
suffice to start things off.   
   
   Mike   
  On Dec 4, 2015, at 9:08 AM, Brian Gesiak <  
modoca...@gmail.com> wrote:  
   Excellent, thanks for the feedback everyone!  
  
  On Thu, Dec 3, 2015 at 10:39 PM, Daniel Dunbar <  
daniel_dun...@apple.com  > wrote:  
 It should be possible to use an out-of-process model that still 
uses XCTest itself to run the tests. For example, in the package manager we 
have some tests which spawn the package manager in order to test the end-to-end 
behavior. Ideally we would only do this for a small number of tests that really 
need this level of testing, and use unit testing for the rest.   

  I'll send a pull request with this approach, since I believe it's the 
 
  least invasive to the current API while still getting us regression  
  tests for the current implementation. Of course I'd be thrilled if  
  someone beats me to it! :)  
  
 On Dec 3, 2015, at 8:03 PM, Tony Parker <   
anthony.par...@apple.com> wrote:   
The reason I’m asking is that (like Foundation and dispatch), we’re trying to 
keep the API surface of this XCTest very similar to the one that ships today 
with Xcode. This will help developers who need to integrate their 
cross-platform tests into suites that include features that Obj-C XCTest has 
that we will probably not add to the Swift one (e.g., UI testing).   

  Absolutely agree. Still, once we have regression tests in place, I'd  
  love to start a conversation about whether we could provide a Obj-C  
  XCTest-compatible API layer on top of some more flexible architecture.
  
  
 On Fri, Dec 4, 2015 at 11:24 AM, Mike Ferris <   
mfer...@apple.com> wrote:   
One possible direction to consider which would be more consistent with our 
goals this year for API-compatibility would be to look into implementing 
XCTestObserver.   

  Yes! Very exciting. We'll need to consider how methods like  
  `-[XCTestObservation testBundleWillStart:]` map to SwiftXCTest,  
  especially considering we don't use NSBundle at all (which I think is 
 
  a great thing). I'll be looking forward to participating in more  
  discussions on this mailing list.  
  
  - Brian Gesiak  
  
  
  On Fri, Dec 4, 2015 at 11:24 AM, Mike Ferris <  mfer...@apple.com 
 > wrote:  
 
One possible direction to consider which would be more consistent with our 
goals this year for API-compatibility would be to look into implementing 
XCTestObserver.   
   
Mike   
   
On Dec 3, 2015, at 8:03 PM, Tony Parker <   anthony.par...@apple.com> 
wrote:   
   
Hi Brian,   
   
On Dec 3, 2015, at 3:45 PM, Brian Gesiak <   modoca...@gmail.com> wrote:
   
   
Hello! This is in reference to
https://github.com/apple/swift-corelibs-xctest/pull/3. That pull request 
contains a commit that attempts to refactor XCTest such that it is more 
"unit-testable”.   
   
   
Cool, thanks for looking into this area.   
   
To do so, it gives XCTMain an additional parameter: a list of objects 
conforming to the Reporter protocol. I think of this as a minimal, corelibs 
equivalent to Apple's XCTest's XCTestObserver.h. I say "minimal" becaus

Re: [swift-corelibs-dev] [xctest] Who tests the tests?

[Brian Gesiak via swift-corelibs-dev]

I've submitted https://github.com/apple/swift-corelibs-xctest/pull/14
as another attempt at this.

Take a look at the pull request message for details. Turns out I'd
overlooked another dependency: nearly all lit tests use FileCheck,
which means to run the tests developers will need to specify that
file's location on their PATH.

Feedback welcome as always! Sorry for the churn on the pull request.

- Brian Gesiak


On Mon, Dec 7, 2015 at 7:05 PM, Tony Parker  wrote:
> Hi Brian,
>
> On Dec 7, 2015, at 3:54 PM, Brian Gesiak  wrote:
>
> I sent up another attempt for this:
> https://github.com/apple/swift-corelibs-xctest/pull/10
>
> Based on the discussion in that pull request, I'm now exploring using lit to
> test the XCTest output.
>
> Rather than asking contributors to install lit via the Python Package Index,
> I was considering using the apple/llvm repository's copy. Contributors would
> need to have cloned llvm in a specific directory relative to the cloned
> swift-corelibs-xctest, like so:
>
> rootdir/
> llvm/
> swift-corelibs-xctest/
>
> This appears to be a convention in the Swift family of repositories, so I
> don't anticipate this to cause confusion among contributors.
>
> If anyone has any input on this approach to lit, or on the direction of
> these changes in general, please let me know! All feedback is greatly
> appreciated.
>
>
> This is probably a fine approach - swift-corelibs-foundation, for example,
> assumes that swift-corelibs-xctest is a sibling directory to it when
> building.
>
> Even if we change our minds later, there’s no doubt that having a starting
> point is valuable.
>
> - Tony
>
> - Brian Gesiak
> _
> From: Mike Ferris 
> Sent: Friday, December 4, 2015 3:42 PM
> Subject: Re: [swift-corelibs-dev] [xctest] Who tests the tests?
> To: Brian Gesiak 
> Cc: Tony Parker , ,
> Daniel Dunbar 
>
>
> Oops. It was pointed out to me that XCTestObserver is deprecated. I get it
> confused sometimes with its replacement..  What we’d presumably want to
> pursue adding the the corelibs XCTest is the API from XCTestObservation.h
> (and associated stuff).
>
> Your same questions about the bundle stuff will still apply, though. On the
> other hand, perhaps a partial implementation that at least allowed
> observation starting at the test suites or even just at the test cases would
> suffice to start things off.
>
>
> Mike
>
> On Dec 4, 2015, at 9:08 AM, Brian Gesiak < modoca...@gmail.com> wrote:
>
> Excellent, thanks for the feedback everyone!
>
> On Thu, Dec 3, 2015 at 10:39 PM, Daniel Dunbar < daniel_dun...@apple.com >
> wrote:
>
> It should be possible to use an out-of-process model that still uses XCTest
> itself to run the tests. For example, in the package manager we have some
> tests which spawn the package manager in order to test the end-to-end
> behavior. Ideally we would only do this for a small number of tests that
> really need this level of testing, and use unit testing for the rest.
>
>
> I'll send a pull request with this approach, since I believe it's the
> least invasive to the current API while still getting us regression
> tests for the current implementation. Of course I'd be thrilled if
> someone beats me to it! :)
>
> On Dec 3, 2015, at 8:03 PM, Tony Parker < anthony.par...@apple.com> wrote:
> The reason I’m asking is that (like Foundation and dispatch), we’re trying
> to keep the API surface of this XCTest very similar to the one that ships
> today with Xcode. This will help developers who need to integrate their
> cross-platform tests into suites that include features that Obj-C XCTest has
> that we will probably not add to the Swift one (e.g., UI testing).
>
>
> Absolutely agree. Still, once we have regression tests in place, I'd
> love to start a conversation about whether we could provide a Obj-C
> XCTest-compatible API layer on top of some more flexible architecture.
>
> On Fri, Dec 4, 2015 at 11:24 AM, Mike Ferris < mfer...@apple.com> wrote:
> One possible direction to consider which would be more consistent with our
> goals this year for API-compatibility would be to look into implementing
> XCTestObserver.
>
>
> Yes! Very exciting. We'll need to consider how methods like
> `-[XCTestObservation testBundleWillStart:]` map to SwiftXCTest,
> especially considering we don't use NSBundle at all (which I think is
> a great thing). I'll be looking forward to participating in more
> discussions on this mailing list.
>
> - Brian Gesiak
>
>
> On Fri, Dec 4, 2015 at 11:24 AM, Mike Ferris < mfer...@apple.com > wrote:
>
>
> One possible direction to consider which would be more consistent with our
> goals this year for API-compatibility would be to look into implementing
> XCTestObserver.
>
> Mike
>
> On Dec 3, 2015, at 8:03 PM, Tony Parker < anthony.par...@apple.com> wrote:
>
> Hi Brian,
>
> On Dec 3, 2015, at 3:45 PM, Brian Gesiak < modoca...@gmail.com> wrote:
>
> Hello! This is in reference to
> https://github.com/apple/swift-corelibs-xctest/pul

Re: [swift-corelibs-dev] Upcoming holiday schedule

[Brian Gesiak via swift-corelibs-dev]

Thanks for the head's up! Conversely, I imagine that for many people, holidays 
from work are precisely the time to contribute! :)
- Brian Gesiak






On Thu, Dec 17, 2015 at 9:03 AM -0800, "Tony Parker via swift-corelibs-dev" 
 wrote:










Hello fellow contributors,

As you are aware, we are fast approaching the year-end holiday season. Here at 
Apple, many of us are taking some time off starting next week through the new 
year. As a result, it is likely that some pull requests will take more time 
than expected to review and merge. Even if some of us are on vacation, this is 
a great opportunity for anyone to jump in and help review PRs!

Thanks and happy new year,
- Tony

 
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev





___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

[Brian Gesiak via swift-corelibs-dev]

Hello all,

I've been referring to the project hosted at
https://github.com/apple/swift-corelibs-xctest as
"swift-corelibs-xctest", and the project shipped alongside Xcode 7.2
as "Apple XCTest".

What are the canonical names for these projects? I'd like to agree on
common terminology to avoid confusion in the future.

Over the past few weeks I've seen several names for
https://github.com/apple/swift-corelibs-xctest:

- Open source XCTest
- Swift XCTest
- Linux XCTest
- swift-corelibs-xctest

And several names for the XCTest framework shipped alongside Xcode:

- Darwin XCTest
- Apple XCTest

How do you refer to these projects? What do you think is the simplest
way to refer to them, in a way that clearly differentiates them?

Personally, I prefer calling them "swift-corelibs-xctest" and "Apple
XCTest", although I do think that "swift-corelibs-xctest" is a
mouthful.

- Brian Gesiak
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Migrate corelibs-foundation to the newest APIs

[Brian Gesiak via swift-corelibs-dev]

I noticed the folks at IBM were also doing platform checks when using the
corelibs-xctest APIs. I created https://bugs.swift.org/browse/SR-1215 to
track the issue.

corelibs-xctest is small enough that we may want to consider providing
*both* Swift 2.2 and Swift 3 APIs, perhaps behind a `#if swift(<3.0)` check.

corelibs-foundation provides a much greater API surface, so it may not be
feasible. But what does everyone think about this approach for
corelibs-xctest?

- Brian Gesiak

On Tue, Apr 12, 2016 at 12:57 PM, Tony Parker via swift-corelibs-dev <
swift-corelibs-dev@swift.org> wrote:

> Hi Robert,
>
> This is something we really do need some help with. Our goal is to have
> the Linux version match the Darwin version exactly.
>
> There is also a PR up to change some of the results of the automatic
> renaming by the importer, here:
>
> https://github.com/apple/swift/pull/2093
>
> So we should take those into account as well.
>
> - Tony
>
> On Apr 12, 2016, at 9:45 AM, Robert F Dickerson via swift-corelibs-dev <
> swift-corelibs-dev@swift.org> wrote:
>
> As you know, currently, as of the 03-24 DEVELOPMENT snapshot, the function
> signatures for Foundation has diverged. This has caused us to create
> platform specific calls to the NSString, NSDate, NSCache, etc. classes. For
> instance,
>
>
> #if os(Linux) 
>  let lastSlash = fileName.rangeOfString("/", options:
> NSStringCompareOptions.BackwardsSearch)
>  #else
>  let lastSlash = fileName.range(of: "/", options:
> NSStringCompareOptions.backwardsSearch)
>  #endif
>
> I was curious about the timeline for the migration to the newer APIs and
> whether someone in particular was working on it. We have some developers
> here at IBM@Swift that could do some of this work, but want to make sure
> we aren't duplicating work and are coordinated.
>
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>
>
>
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>
>
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

[Brian Gesiak via swift-corelibs-dev]

Hello all!

If you're like me, you might be curious how Core Libraries like
swift-corelibs-xctest are doing with regards to the looming Swift 3.0
release. Well, wonder no more -- this handy JIRA dashboard has the
information you need:
https://bugs.swift.org/secure/Dashboard.jspa?selectPageId=10408

The dashboard not only lists tasks that need to be resolved by Swift 3.0,
but also open starter tasks for new contributors.

Let me know if you find it useful! I personally think it'd be neat to have
one of these for all the swift-corelibs-* projects, what do you all think?
:)

PS: For those interested, the dashboard is implemented using custom task
filters:

- corelibs-xctest Open Tasks: https://bugs.swift.org/issues/?filter=10469
- corelibs-xctest Open 3.0 Tasks:
https://bugs.swift.org/issues/?filter=10471
- corelibs-xctest Open Starter Tasks:
https://bugs.swift.org/issues/?filter=10470

To track tasks related to Swift 3.0, I created a new "swift-3.0" label in
JIRA. I hope no one minds. (+cc Jordan Rose, I've seen him managing labels
on JIRA before.)

- Brian Gesiak
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

[Brian Gesiak via swift-corelibs-dev]

I'm glad people are finding these useful!!

Yes, I've made one for corelibs-foundation as well:
https://bugs.swift.org/secure/Dashboard.jspa?selectPageId=10410

Of course, as David mentioned, task curation is what makes these dashboards
really shine. Try assigning the "swift-3.0" label to tasks that should be
taken care of in time for its release. Also, I noticed
swift-corelibs-foundation doesn't have many tasks with the "StarterBug"
label. I think those are a great way to encourage more people to contribute.

- Brian Gesiak


On Mon, May 23, 2016 at 5:57 PM, David Hart  wrote:

> Brian Gesiak started started one for foundation. It seems it's only
> missing some trimming and labeling of issues:
>
> David,
>
> I actually started on one! http://tinyurl.com/foundation-dashboard :)
>
> Like you mentioned, I don't have a ton of context on the project, so I'm a
> little hesitant to decide what should be tagged with "swift-3.0".
>
> Still, one thing that stands out: swift-corelibs-foundation has only one
> task with the StarterBug label! I wonder if some tasks can be cleaned up,
> given clearer instructions, and labeled as a starter task...
>
> - Brian Gesi
>
>
> On 23 May 2016, at 22:41, Tony Parker via swift-corelibs-dev <
> swift-corelibs-dev@swift.org> wrote:
>
> This is slick!
>
> I would love to have one for Foundation too (although my understanding of
> JIRA is limited at best).
>
> - Tony
>
> On May 22, 2016, at 12:47 PM, Brian Gesiak via swift-corelibs-dev <
> swift-corelibs-dev@swift.org> wrote:
>
> Hello all!
>
> If you're like me, you might be curious how Core Libraries like
> swift-corelibs-xctest are doing with regards to the looming Swift 3.0
> release. Well, wonder no more -- this handy JIRA dashboard has the
> information you need:
> https://bugs.swift.org/secure/Dashboard.jspa?selectPageId=10408
>
> The dashboard not only lists tasks that need to be resolved by Swift 3.0,
> but also open starter tasks for new contributors.
>
> Let me know if you find it useful! I personally think it'd be neat to have
> one of these for all the swift-corelibs-* projects, what do you all think?
> :)
>
> PS: For those interested, the dashboard is implemented using custom task
> filters:
>
> - corelibs-xctest Open Tasks: https://bugs.swift.org/issues/?filter=10469
> - corelibs-xctest Open 3.0 Tasks:
> https://bugs.swift.org/issues/?filter=10471
> - corelibs-xctest Open Starter Tasks:
> https://bugs.swift.org/issues/?filter=10470
>
> To track tasks related to Swift 3.0, I created a new "swift-3.0" label in
> JIRA. I hope no one minds. (+cc Jordan Rose, I've seen him managing labels
> on JIRA before.)
>
> - Brian Gesiak
>
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>
>
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>
>
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] JIRA labels (no worries)

[Brian Gesiak via swift-corelibs-dev]

Hey Jordan,

Thanks for the email! Very good point -- and I definitely felt weird
assigning "Swift 3" labels to tasks, considering it's not up to me to
decide what goes into Swift 3 or not. Still, I think it's helpful to see,
at a glance, what are the time-sensitive tasks for a given project.
Ideally, the tag would be named something like
"ItdBeSwellToGetThisDoneInTimeForSwift3IMHO" :) Seriously, though, ideas
for better label names would be very welcome!

And I appreciate the naming convention! I was wondering myself, but ended
up going with the casing used by the Swift 3.0 release branches.

Anyway, thanks for the clarification!! Very much appreciated. And no need
to apologize for removing the label, I didn't take it personally. :)

- Brian Gesiak


On Thu, May 26, 2016 at 11:13 PM, Jordan Rose  wrote:

> Hey, Brian. Re: your comment about labels
> 
> :
>
> By the way, I'm curious for your thoughts on the swift-3.0 label, which I
> introduced in
> https://lists.swift.org/pipermail/swift-corelibs-dev/Week-of-Mon-20160516/000662.html.
> I've seen you "curate" labels in the past, so I hope I didn't step on your
> toes by creating one. I tagged this task as "swift-3.0" because it's a
> sub-task of SR-710 , which is also
> marked "swift-3.0" – we want to be able to generate tests lists before
> shipping corelibs-xctest.
>
>
> I knocked the "swift-3.0” label off because this was the first time I’d
> seen it in a non-corelibs issue, and because I wasn’t sure we had committed
> to doing this *particular* subtask in Swift 3—or rather, I wasn’t sure
> the *SourceKit* team had committed to doing this in Swift 3. I feel weird
> having release labels assigned by people working in other parts of the
> project because it feels like forcing the SourceKit engineers to fix it. I
> know that (a) wasn’t your intention, and (b) is probably accurate—as in, if
> this alternate solution hadn’t come up *someone* would have had to do
> something—but I reacted to it anyway and removed the label.
>
> I do think now it was a bit of a knee-jerk reaction, so I apologize. As
> you noted, I’ve generally been the one adding labels, and removing or
> standardizing some of the ad hoc ones input by issue reporters; in this
> particular case that led to an instinct to remove a label I hadn’t seen
> rather than thinking about it. Certainly active contributors should be able
> to introduce new labels they find useful.
>
> SR-1613 is resolved, so it’s kind of a moot point now, but do feel free to
> add useful labels in the future. If it matches one I’ve seen before I might
> standardize it, but I won’t remove them. Or if I do I’ll at least comment
> about it. :-)
>
> Jordan
>
> P.S. “swift-3.0” also doesn’t match my naming convention for labels, which
> is UpperCamelCase, but given that I didn’t write it down anywhere or tell
> anybody I can hardly complain!
>
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] [XCTest] Cannot build using XCode

[Brian Gesiak via swift-corelibs-dev]

Madhu,
Thanks for the report!
The main difference between the build scripts (which use xcodebuild) and using 
Xcode itself is the version of Swift that is used. The build scripts build a 
Swift 3.0 compiler, then use that to build XCTest. When using Xcode directly, 
you need to select a recent Swift toolchain yourself.
Which Swift toolchain are you using to compile XCTest in Xcode?
Our tests only make sure apple/swift master works. If the latest Swift 
toolchain from http://swift.org doesn't work, you may have to built your own 
toolchain. You can do so using the `utils/build-toolchain` script in the Swift 
repository.
Once you figure out your Swift toolchain version, let us know! You should be 
able to find out in the preferences pane in Xcode.
- Brian Gesiak





On Sun, May 29, 2016 at 1:24 AM -0700, "Madhu Samuel via swift-corelibs-dev" 
 wrote:










Hi All,
I am new to this forum. 
I am trying to build the xctest project. I followed the instructions at 
https://github.com/apple/swift-corelibs-xctest
I am able to successfully build via the build scripts. But, if I build XCTest 
using xcode using the SwiftXCTest scheme I am getting a few errors. 
1. swift-corelibs-foundation/Foundation/NSXMLDTDNode.swift:242:64: error: 
cannot convert value of type 'UnsafeMutablePointer' (aka 
'UnsafeMutablePointer<()>') to expected argument type 'OpaquePointer'           
 let unmanaged = Unmanaged.fromOpaque(privateData)
2. swift-corelibs-foundation/Foundation/NSTimer.swift:14:47: error: cannot 
convert value of type 'UnsafeMutablePointer' (aka 
'UnsafeMutablePointer<()>') to expected argument type 'OpaquePointer'    let t 
= Unmanaged.fromOpaque(info!).takeUnretainedValue()
etc.
My dev environment, OS: Mac OSX El Capitan 10.11.4 (15E65).Xcode Version: 
Version 7.3.1 (7D1014)XCode Toolchain: Swift Development Snapshot 2016-05-09 (a)
Any help is appreciated.
Regards,Madhu







___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] [XCTest] Cannot build using XCode

[Brian Gesiak via swift-corelibs-dev]

Madhu,
Oy, my bad -- I only just noticed you put the toolchain version at the bottom 
of your original email.
It's possible the May 9th toolchain is already too old to build XCTest. I'll 
double-check myself. In the meantime, you may want to try building your own 
toolchain and using that.
- Brian Gesiak






On Sun, May 29, 2016 at 7:23 AM -0700, "Brian Gesiak"  
wrote:










Madhu,
Thanks for the report!
The main difference between the build scripts (which use xcodebuild) and using 
Xcode itself is the version of Swift that is used. The build scripts build a 
Swift 3.0 compiler, then use that to build XCTest. When using Xcode directly, 
you need to select a recent Swift toolchain yourself.
Which Swift toolchain are you using to compile XCTest in Xcode?
Our tests only make sure apple/swift master works. If the latest Swift 
toolchain from http://swift.org doesn't work, you may have to built your own 
toolchain. You can do so using the `utils/build-toolchain` script in the Swift 
repository.
Once you figure out your Swift toolchain version, let us know! You should be 
able to find out in the preferences pane in Xcode.
- Brian Gesiak





On Sun, May 29, 2016 at 1:24 AM -0700, "Madhu Samuel via swift-corelibs-dev" 
 wrote:










Hi All,
I am new to this forum. 
I am trying to build the xctest project. I followed the instructions at 
https://github.com/apple/swift-corelibs-xctest
I am able to successfully build via the build scripts. But, if I build XCTest 
using xcode using the SwiftXCTest scheme I am getting a few errors. 
1. swift-corelibs-foundation/Foundation/NSXMLDTDNode.swift:242:64: error: 
cannot convert value of type 'UnsafeMutablePointer' (aka 
'UnsafeMutablePointer<()>') to expected argument type 'OpaquePointer'           
 let unmanaged = Unmanaged.fromOpaque(privateData)
2. swift-corelibs-foundation/Foundation/NSTimer.swift:14:47: error: cannot 
convert value of type 'UnsafeMutablePointer' (aka 
'UnsafeMutablePointer<()>') to expected argument type 'OpaquePointer'    let t 
= Unmanaged.fromOpaque(info!).takeUnretainedValue()
etc.
My dev environment, OS: Mac OSX El Capitan 10.11.4 (15E65).Xcode Version: 
Version 7.3.1 (7D1014)XCode Toolchain: Swift Development Snapshot 2016-05-09 (a)
Any help is appreciated.
Regards,Madhu












___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

[swift-corelibs-dev] libdispatch on Linux, or C++ std::async?

[Brian Gesiak via swift-corelibs-dev]

Hello all!

I'm working on https://bugs.swift.org/browse/SR-710, which involves porting
SourceKit to Linux. SourceKit contains a handful of references to
libdispatch symbols.

I have two questions:

1. Could someone share a set of instructions to build
swift-corelibs-libdispatch on Linux? I'm using Ubuntu 15.10 and have
installed [the dependencies listed here](
https://lists.swift.org/pipermail/swift-corelibs-dev/Week-of-Mon-20151207/000122.html).
I have tried using both `swift/utils/build-script --libdispatch` as well as
the instructions in the swift-corelibs-libdispatch `INSTALL` file. Both
fail with the [same errors](
https://gist.github.com/modocache/8389d5d64e39ca5a4281500f84e9ce11). Any
tips?

2. I don't know much about C++, but from what I understand the C++ stdlib
provides tools for asynchronous programming. I list SourceKit's uses of
libdispatch in a comment on https://bugs.swift.org/browse/SR-1639. For
those familiar with both C++ and libdispatch: do you think it's a good idea
to migrate to C++, at least for now?

Any advice would be appreciated. Thanks!!

- Brian Gesiak
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] libdispatch on Linux, or C++ std::async?

[Brian Gesiak via swift-corelibs-dev]

Thanks for the quick responses!

I had tried the experimental/foundation branch as well, with no luck.
Here's the full output from a clean build I just attempted:
https://gist.github.com/modocache/fcf0c78908b39834448c73ac3f50c110

Prior to the build I removed my entire build directory (which included
both libdispatch-linux-x86_64 and swift-linux-x86_64) and removed all build
artifacts from my libdispatch directory (I used `git clean -fxd` -- Make
tells me there's no target `distclean`).

Looking at the build failure, it appears to be the same one that was
reported in https://bugs.swift.org/browse/SR-1242. The author of that
report indicates that
https://github.com/apple/swift-corelibs-libdispatch/pull/64 fixes the
problem. My checkout includes the commits from that pull request, but the
problem remains.

In any case, thanks for all your help! I'll keep trying. Any and all advice
would be much appreciated!

- Brian Gesiak


On Mon, May 30, 2016 at 10:22 AM, Chris Bailey  wrote:

> I'd certainly recommend picking up the experimental/foundation branch as
> Rob recommends. Its where we've been doing some additional work to get
> properly built into the Swift toolchain and to open up some internal APIs
> needed by Foundation.
>
> Whilst I've been building Dispatch either independently or as part of a
> full toolchain using the buildbot_linux preset (with dispatch and
> install-dispatch added), I've just checked your build line and its working
> fine for me. It might be worth cleaning out any partial build you might
> have of libdispatch in your build directory, and running 'make distclean'
> from your libdispatch source directory.
>
> FYI, we've got some further changes to the experimental/foundation branch
> of libdispatch with should land in the next couple of days. This fixes some
> issues with the Swift overlay, and resolves a crash that we've found in the
> underlying libkqueue implementation.
>
> Chris
>
>
>
>
> From:Rob Allen via swift-corelibs-dev <
> swift-corelibs-dev@swift.org>
> To:Brian Gesiak 
> Cc:Swift Core Libs 
> Date:30/05/2016 08:08
> Subject:Re: [swift-corelibs-dev] libdispatch on Linux, or C++
> std::async?
> Sent by:swift-corelibs-dev-boun...@swift.org
> --
>
>
>
> Hi,
>
> For what it's worth, I can't get the master branch to build either, but I
> can get the experimental/foundation branch to build.
>
> Regards,
>
> Rob
>
>
> On 30 May 2016, at 05:28, Brian Gesiak via swift-corelibs-dev <
> *swift-corelibs-dev@swift.org* > wrote:
>
> Hello all!
>
> I'm working on *https://bugs.swift.org/browse/SR-710*
> <https://bugs.swift.org/browse/SR-710>, which involves porting SourceKit
> to Linux. SourceKit contains a handful of references to libdispatch symbols.
>
> I have two questions:
>
> 1. Could someone share a set of instructions to build
> swift-corelibs-libdispatch on Linux? I'm using Ubuntu 15.10 and have
> installed [the dependencies listed here](
> *https://lists.swift.org/pipermail/swift-corelibs-dev/Week-of-Mon-20151207/000122.html*
> <https://lists.swift.org/pipermail/swift-corelibs-dev/Week-of-Mon-20151207/000122.html>).
> I have tried using both `swift/utils/build-script --libdispatch` as well as
> the instructions in the swift-corelibs-libdispatch `INSTALL` file. Both
> fail with the [same errors](
> *https://gist.github.com/modocache/8389d5d64e39ca5a4281500f84e9ce11*
> <https://gist.github.com/modocache/8389d5d64e39ca5a4281500f84e9ce11>).
> Any tips?
>
> 2. I don't know much about C++, but from what I understand the C++ stdlib
> provides tools for asynchronous programming. I list SourceKit's uses of
> libdispatch in a comment on *https://bugs.swift.org/browse/SR-1639*
> <https://bugs.swift.org/browse/SR-1639>. For those familiar with both C++
> and libdispatch: do you think it's a good idea to migrate to C++, at least
> for now?
>
> Any advice would be appreciated. Thanks!!
>
> - Brian Gesiak
>
>
> --
> Development thoughts at *http://akrabat.com* <http://akrabat.com/>
> Daily Jotter for Mac OS X at *http://dailyjotter.com*
> <http://dailyjotter.com/>
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>
>
>
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] libdispatch on Linux, or C++ std::async?

[Brian Gesiak via swift-corelibs-dev]

Gah, thanks Brian and Chris -- yes, I had forgotten. I initialized it once
on a separate development environment and forgot to do so again.

Thanks everyone! I managed to build the project. :)

I'll try getting SourceKit to link against my built libdispatch. Does
anyone have any thoughts on my second question? Would it make sense to move
SourceKit over to C++ async features? SourceKit only uses the following
libdispatch symbols:

- dispatch_after
- dispatch_release
- dispatch_semaphore_create
- dispatch_semaphore_signal
- dispatch_semaphore_wait
- dispatch_time

As far as I understand, having SourceKit use libdispatch means:

1. Having libdispatch built as part of all Swift builds that build
SourceKit. On OS X, most buildbot presets build SourceKit. I'd like to do
the same for Linux.
2. Building libdispatch prior to building Swift, or at least prior to
building Swift tools like SourceKit.

Moving these build dependencies around seems like more work than using C++
async, but I barely know C++, so I'm not sure. Thoughts?

- Brian Gesiak


On Mon, May 30, 2016 at 12:19 PM, Chris Bailey  wrote:

> The missing reference is to 'pthread_workqueue_signal_np()' which was
> added to libpwq via PR #10:
> https://github.com/mheily/libpwq/pull/10
>
> I suspect that you don't have the libpwq submodule checked out in
> swift-corelibs-libdispatch. Is there any contents in
> swift-corelibs-libdispatch/libpwq?
>
> If not, running:
> git submodule init
> git submodule update
> from the swift-corelibs-libdispatch directory should fix it.
>
> Chris
>
>
>
>
> From:Brian Gesiak 
> To:Chris Bailey/UK/IBM@IBMGB
> Cc:Rob Allen , Swift Core Libs <
> swift-corelibs-dev@swift.org>
> Date:30/05/2016 16:51
> Subject:Re: [swift-corelibs-dev] libdispatch on Linux, or C++
> std::async?
> --
>
>
>
> Thanks for the quick responses!
>
> I had tried the experimental/foundation branch as well, with no luck.
> Here's the full output from a clean build I just attempted:
> *https://gist.github.com/modocache/fcf0c78908b39834448c73ac3f50c110*
> <https://gist.github.com/modocache/fcf0c78908b39834448c73ac3f50c110>
>
> Prior to the build I removed my entire build directory (which included
> both libdispatch-linux-x86_64 and swift-linux-x86_64) and removed all build
> artifacts from my libdispatch directory (I used `git clean -fxd` -- Make
> tells me there's no target `distclean`).
>
> Looking at the build failure, it appears to be the same one that was
> reported in *https://bugs.swift.org/browse/SR-1242*
> <https://bugs.swift.org/browse/SR-1242>. The author of that report
> indicates that
> *https://github.com/apple/swift-corelibs-libdispatch/pull/64*
> <https://github.com/apple/swift-corelibs-libdispatch/pull/64> fixes the
> problem. My checkout includes the commits from that pull request, but the
> problem remains.
>
> In any case, thanks for all your help! I'll keep trying. Any and all
> advice would be much appreciated!
>
> - Brian Gesiak
>
>
> On Mon, May 30, 2016 at 10:22 AM, Chris Bailey <*bail...@uk.ibm.com*
> > wrote:
> I'd certainly recommend picking up the experimental/foundation branch as
> Rob recommends. Its where we've been doing some additional work to get
> properly built into the Swift toolchain and to open up some internal APIs
> needed by Foundation.
>
> Whilst I've been building Dispatch either independently or as part of a
> full toolchain using the buildbot_linux preset (with dispatch and
> install-dispatch added), I've just checked your build line and its working
> fine for me. It might be worth cleaning out any partial build you might
> have of libdispatch in your build directory, and running 'make distclean'
> from your libdispatch source directory.
>
> FYI, we've got some further changes to the experimental/foundation branch
> of libdispatch with should land in the next couple of days. This fixes some
> issues with the Swift overlay, and resolves a crash that we've found in the
> underlying libkqueue implementation.
>
> Chris
>
>
>
>
> From:Rob Allen via swift-corelibs-dev <
> *swift-corelibs-dev@swift.org* >
> To:Brian Gesiak <*modoca...@gmail.com* >
> Cc:Swift Core Libs <*swift-corelibs-dev@swift.org*
> >
> Date:30/05/2016 08:08
> Subject:    Re: [swift-corelibs-dev] libdispatch on Linux, or C++
> std::async?
> Sent by:*swift-corelibs-dev-boun...@swift.org*
> 
> --
>
>
>
>
> Hi,
>
> For what it's worth, I can't get the master br

Re: [swift-corelibs-dev] Xcode 8 beta 1 and swift-corelibs-foundation

[Brian Gesiak via swift-corelibs-dev]

Excellent work! I've been enjoying watching all the WWDC livestreams. :)

About the changes to swift-corelibs-xctest: you mean simply using the new
Foundation APIs, correct? I don't imagine we'll be changing the XCTest API
very much -- that is, we won't be renaming `XCTestCase` to `TestCase`,
right?

We discussed this [in Feburary](
https://lists.swift.org/pipermail/swift-corelibs-dev/Week-of-Mon-20160222/000446.html),
and I believe the conclusion was that we wouldn't be applying the same
kinds of grand renaming to XCTest -- would just like to confirm that point.

- Brian Gesiak

On Tue, Jun 14, 2016 at 1:24 PM, Tony Parker via swift-corelibs-dev <
swift-corelibs-dev@swift.org> wrote:

> Hello everyone,
>
> If you’ve downloaded Xcode 8 beta 1, you’ve seen some of the great changes
> we’ve got coming up for Swift 3 on Darwin. We have been working in parallel
> on those improvements and the changes that we need to bring
> swift-corelibs-foundation up-to-date, including:
>
>  * new value types (SE-0069)
>  * new names for API and NS-dropping changes (SE-0086)
>  * new tests (mostly part of the overlay, not all merged to corelibs yet)
>
> We plan to post later today a branch (*name forthcoming) *to the
> swift-corelibs-foundation repository that contains the first version of all
> of these changes. We’ve also been merging all of the other changes from
> master branch.
>
> It’s not quite ready to merge back to master yet, so we would appreciate
> your help! Check out the branch, look for errors or omissions, and submit
> some PRs or send mail to this list.
>
> Our hope is to merge this branch very quickly, in the span of a week or
> two at most. We will likely need to get some parallel PRs up for XCTest and
> swiftpm to help them adapt to the new name and type changes.
>
> Thanks!
> - Tony
>
>
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>
>
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] [XCTest] Cannot build using XCode

[Brian Gesiak via swift-corelibs-dev]

Madhu,
In addition the checking out the latest code in apple/swift, please run 
`utils/update-checkout`, in order to update the other repositories Swift 
depends upon.
I haven't been able to build OS X since Xcode 8 beta was required for the 
build, so I'm not sure about your specific error, unfortunately. Perhaps 
double-check that `xcode-select -print-path` prints out the path to Xcode 8...?
- Brian Gesiak




_
From: Madhu Samuel 
Sent: Monday, June 20, 2016 10:22 PM
Subject: Re: [swift-corelibs-dev] [XCTest] Cannot build using XCode
To: Brian Croom 
Cc: Brian Gesiak ,  


So after spending almost a week trying to build swift and core libraries 
(mainly xctest) during the end of May un-successfully, I made up my mind to 
give another attempt today.
I checkout the latest code from swift repo. Since the xctest documentation 
says, "Confirm you're able to build the Swift project using utils/build-script 
-R", that's where I started. 
Unfortunately, build-script -R gives the below error.
:0: error: Swift does not support the SDK 'MacOSX10.11.sdk'


My active developer directory is 
'/Applications/Xcode-beta.app/Contents/Developer'.The toolchain is 'Xode 8.0'
The build is taken in Mac OSX El Capitan 10.11.4
Let me know whether I miss anything? I assume getting the build working for the 
first time is the hardest, but there I am!
Any help is appreciated!
Regards,
Madhu
On Mon, May 30, 2016 at 8:32 AM, Madhu Samuel  wrote:


Wow, that was a quick response. Thanks Brian Gesiak and Brian Croom. 

My first quick attempt using build-toolchain script to build my own tool chain 
failed. Anyway I will give it another try and let you know the status.
On Mon, May 30, 2016 at 1:52 AM, Brian Croom  wrote:
That's right, breaking changes have been made to Swift since the latest 
toolchain snapshot was released, and Corelibs Foundation has been updated 
accordingly.
Until the next snapshot, an alternative to building your own toolchain would be 
to check out an older commit of Foundation which still builds with the compiler 
in the snapshot toolchain, since XCTest doesn't depend on any of the more 
recent Foundation changes. I've had success using this commit: 
https://github.com/apple/swift-corelibs-foundation/commit/04d4f92870652160388f1c69de3fd7bb0656860c
 
--Brian

söndag 29 maj 2016 skrev Brian Gesiak via swift-corelibs-dev 
:
Madhu,
Oy, my bad -- I only just noticed you put the toolchain version at the bottom 
of your original email.
It's possible the May 9th toolchain is already too old to build XCTest. I'll 
double-check myself. In the meantime, you may want to try building your own 
toolchain and using that.
- Brian Gesiak





On Sun, May 29, 2016 at 7:23 AM -0700, "Brian Gesiak"  
wrote:

Madhu,
Thanks for the report!
The main difference between the build scripts (which use xcodebuild) and using 
Xcode itself is the version of Swift that is used. The build scripts build a 
Swift 3.0 compiler, then use that to build XCTest. When using Xcode directly, 
you need to select a recent Swift toolchain yourself.
Which Swift toolchain are you using to compile XCTest in Xcode?
Our tests only make sure apple/swift master works. If the latest Swift 
toolchain from http://swift.org doesn't work, you may have to built your own 
toolchain. You can do so using the `utils/build-toolchain` script in the Swift 
repository.
Once you figure out your Swift toolchain version, let us know! You should be 
able to find out in the preferences pane in Xcode.
- Brian Gesiak




On Sun, May 29, 2016 at 1:24 AM -0700, "Madhu Samuel via swift-corelibs-dev" 
 wrote:

Hi All,
I am new to this forum. 
I am trying to build the xctest project. I followed the instructions at 
https://github.com/apple/swift-corelibs-xctest
I am able to successfully build via the build scripts. But, if I build XCTest 
using xcode using the SwiftXCTest scheme I am getting a few errors. 
1. swift-corelibs-foundation/Foundation/NSXMLDTDNode.swift:242:64: error: 
cannot convert value of type 'UnsafeMutablePointer' (aka 
'UnsafeMutablePointer<()>') to expected argument type 'OpaquePointer'           
 let unmanaged = Unmanaged.fromOpaque(privateData)
2. swift-corelibs-foundation/Foundation/NSTimer.swift:14:47: error: cannot 
convert value of type 'UnsafeMutablePointer' (aka 
'UnsafeMutablePointer<()>') to expected argument type 'OpaquePointer'    let t 
= Unmanaged.fromOpaque(info!).takeUnretainedValue()
etc.
My dev environment, OS: Mac OSX El Capitan 10.11.4 (15E65).Xcode Version: 
Version 7.3.1 (7D1014)XCode Toolchain: Swift Development Snapshot 2016-05-09 (a)
Any help is appreciated.
Regards,Madhu






___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] [XCTest] Cannot build using XCode

[Brian Gesiak via swift-corelibs-dev]

gt;
>>>> Regards,
>>>> Madhu
>>>>
>>>> On Mon, May 30, 2016 at 8:32 AM, Madhu Samuel 
>>>> wrote:
>>>>
>>>>> Wow, that was a quick response. Thanks Brian Gesiak and Brian Croom.
>>>>>
>>>>> My first quick attempt using build-toolchain script to build my own
>>>>> tool chain failed. Anyway I will give it another try and let you know the
>>>>> status.
>>>>>
>>>>> On Mon, May 30, 2016 at 1:52 AM, Brian Croom 
>>>>> wrote:
>>>>>
>>>>>> That's right, breaking changes have been made to Swift since
>>>>>> the latest toolchain snapshot was released, and Corelibs Foundation has
>>>>>> been updated accordingly.
>>>>>>
>>>>>> Until the next snapshot, an alternative to building your own
>>>>>> toolchain would be to check out an older commit of Foundation which still
>>>>>> builds with the compiler in the snapshot toolchain, since XCTest
>>>>>> doesn't depend on any of the more recent Foundation changes. I've had
>>>>>> success using this commit:
>>>>>> https://github.com/apple/swift-corelibs-foundation/commit/04d4f92870652160388f1c69de3fd7bb0656860c
>>>>>>
>>>>>>
>>>>>> --Brian
>>>>>>
>>>>>>
>>>>>> söndag 29 maj 2016 skrev Brian Gesiak via swift-corelibs-dev <
>>>>>> swift-corelibs-dev@swift.org>:
>>>>>>
>>>>>>> Madhu,
>>>>>>>
>>>>>>> Oy, my bad -- I only just noticed you put the toolchain version at
>>>>>>> the bottom of your original email.
>>>>>>>
>>>>>>> It's possible the May 9th toolchain is already too old to build
>>>>>>> XCTest. I'll double-check myself. In the meantime, you may want to try
>>>>>>> building your own toolchain and using that.
>>>>>>>
>>>>>>> - Brian Gesiak
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sun, May 29, 2016 at 7:23 AM -0700, "Brian Gesiak" <
>>>>>>> modoca...@gmail.com> wrote:
>>>>>>>
>>>>>>> Madhu,
>>>>>>>>
>>>>>>>> Thanks for the report!
>>>>>>>>
>>>>>>>> The main difference between the build scripts (which use
>>>>>>>> xcodebuild) and using Xcode itself is the version of Swift that is 
>>>>>>>> used.
>>>>>>>> The build scripts build a Swift 3.0 compiler, then use that to build
>>>>>>>> XCTest. When using Xcode directly, you need to select a recent Swift
>>>>>>>> toolchain yourself.
>>>>>>>>
>>>>>>>> Which Swift toolchain are you using to compile XCTest in Xcode?
>>>>>>>>
>>>>>>>> Our tests only make sure apple/swift master works. If the latest
>>>>>>>> Swift toolchain from http://swift.org doesn't work, you may have
>>>>>>>> to built your own toolchain. You can do so using the
>>>>>>>> `utils/build-toolchain` script in the Swift repository.
>>>>>>>>
>>>>>>>> Once you figure out your Swift toolchain version, let us know! You
>>>>>>>> should be able to find out in the preferences pane in Xcode.
>>>>>>>>
>>>>>>>> - Brian Gesiak
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sun, May 29, 2016 at 1:24 AM -0700, "Madhu Samuel via
>>>>>>>> swift-corelibs-dev"  wrote:
>>>>>>>>
>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> I am new to this forum.
>>>>>>>>>
>>>>>>>>> I am trying to build the xctest project. I followed the
>>>>>>>>> instructions at https://github.com/apple/swift-corelibs-xctest
>>>>>>>>>
>>>>>>>>> I am able to successfully build via the build scripts. But, if I
>>>>>>>>> build XCTest using xcode using the SwiftXCTest scheme I am getting a 
>>>>>>>>> few
>>>>>>>>> errors.
>>>>>>>>>
>>>>>>>>> 1. swift-corelibs-foundation/Foundation/NSXMLDTDNode.swift:242:64:
>>>>>>>>> error: cannot convert value of type 'UnsafeMutablePointer' (aka
>>>>>>>>> 'UnsafeMutablePointer<()>') to expected argument type 'OpaquePointer'
>>>>>>>>> let unmanaged =
>>>>>>>>> Unmanaged.fromOpaque(privateData)
>>>>>>>>>
>>>>>>>>> 2. swift-corelibs-foundation/Foundation/NSTimer.swift:14:47:
>>>>>>>>> error: cannot convert value of type 'UnsafeMutablePointer' (aka
>>>>>>>>> 'UnsafeMutablePointer<()>') to expected argument type 'OpaquePointer'
>>>>>>>>> let t =
>>>>>>>>> Unmanaged.fromOpaque(info!).takeUnretainedValue()
>>>>>>>>>
>>>>>>>>> etc.
>>>>>>>>>
>>>>>>>>> My dev environment,
>>>>>>>>> OS: Mac OSX El Capitan 10.11.4 (15E65).
>>>>>>>>> Xcode Version: Version 7.3.1 (7D1014)
>>>>>>>>> XCode Toolchain: Swift Development Snapshot 2016-05-09 (a)
>>>>>>>>>
>>>>>>>>> Any help is appreciated.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Madhu
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>
>>>>
>>>
>>
>
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] [XCTest] Cannot build using XCode

[Brian Gesiak via swift-corelibs-dev]

;> 30, in run
>>>>> subprocess.check_call(command, shell=True)
>>>>>   File
>>>>> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py",
>>>>> line 540, in check_call
>>>>> raise CalledProcessError(retcode, cmd)
>>>>> subprocess.CalledProcessError: Command 'xcodebuild -workspace
>>>>> /Users/madhusamuel/dev/swift/swift-corelibs-xctest/XCTest.xcworkspace
>>>>> -scheme SwiftXCTest
>>>>> SWIFT_EXEC="/Users/madhusamuel/dev/swift/build/Ninja-ReleaseAssert/swift-macosx-x86_64/bin/swiftc"
>>>>> SWIFT_LINK_OBJC_RUNTIME=YES
>>>>> SYMROOT="/Users/madhusamuel/dev/swift/build/Ninja-ReleaseAssert/xctest-macosx-x86_64"
>>>>> OBJROOT="/Users/madhusamuel/dev/swift/build/Ninja-ReleaseAssert/xctest-macosx-x86_64"'
>>>>> returned non-zero exit status 65
>>>>> ../swift/utils/build-script: fatal error: command terminated with a
>>>>> non-zero exit status 1, aborting
>>>>> ../swift/utils/build-script: fatal error: command terminated with a
>>>>> non-zero exit status 1, aborting
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jun 21, 2016 at 12:35 PM, Madhu Samuel 
>>>>> wrote:
>>>>>
>>>>>> Hi Brian Croom,
>>>>>>
>>>>>> Thanks for the quick response. I deleted the entire build directory
>>>>>> now. Initiated a new build. Fingers crossed...
>>>>>>
>>>>>> Will update the status as soon as the build finishes.
>>>>>>
>>>>>> On Tue, Jun 21, 2016 at 12:31 PM, Brian Croom <
>>>>>> brian.s.cr...@gmail.com> wrote:
>>>>>>
>>>>>>> Hmm, have you tried deleting your `build/swift-macosx-x86_64/`
>>>>>>> directory? I wonder if cached CMake values could cause that issue.
>>>>>>>
>>>>>>> (By the way, I can confirm that getting the build going for the
>>>>>>> first time is the most challenging! I hope we can get things going for 
>>>>>>> you
>>>>>>> soon.)
>>>>>>>
>>>>>>> 2016-06-20 22:22 GMT-04:00 Madhu Samuel :
>>>>>>>
>>>>>>>> So after spending almost a week trying to build swift and core
>>>>>>>> libraries (mainly xctest) during the end of May un-successfully, I 
>>>>>>>> made up
>>>>>>>> my mind to give another attempt today.
>>>>>>>>
>>>>>>>> I checkout the latest code from swift repo. Since the xctest
>>>>>>>> documentation says, "Confirm you're able to build the Swift project 
>>>>>>>> using
>>>>>>>> utils/build-script -R", that's where I started.
>>>>>>>>
>>>>>>>> Unfortunately, build-script -R gives the below error.
>>>>>>>>
>>>>>>>> :0: error: Swift does not support the SDK 'MacOSX10.11.sdk'
>>>>>>>>
>>>>>>>>
>>>>>>>> My active developer directory is
>>>>>>>> '/Applications/Xcode-beta.app/Contents/Developer'.
>>>>>>>> The toolchain is 'Xode 8.0'
>>>>>>>>
>>>>>>>> The build is taken in Mac OSX El Capitan 10.11.4
>>>>>>>>
>>>>>>>> Let me know whether I miss anything? I assume getting the build
>>>>>>>> working for the first time is the hardest, but there I am!
>>>>>>>>
>>>>>>>> Any help is appreciated!
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Madhu
>>>>>>>>
>>>>>>>> On Mon, May 30, 2016 at 8:32 AM, Madhu Samuel <
>>>>>>>> madhusam...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Wow, that was a quick response. Thanks Brian Gesiak and Brian
>>>>>>>>> Croom.
>>>>>>>>>
>>>>>>>>> My first quick attempt using build-toolchain script to build my
>>>>>>>>> own tool chain failed. Anyway I will give it another try and 

Re: [swift-corelibs-dev] [XCTest] Cannot build using XCode

[Brian Gesiak via swift-corelibs-dev]

 
accordingly.
Until the next snapshot, an alternative to building your own toolchain would be 
to check out an older commit of Foundation which still builds with the compiler 
in the snapshot toolchain, since XCTest doesn't depend on any of the more 
recent Foundation changes. I've had success using this commit: 
https://github.com/apple/swift-corelibs-foundation/commit/04d4f92870652160388f1c69de3fd7bb0656860c
 
--Brian

söndag 29 maj 2016 skrev Brian Gesiak via swift-corelibs-dev 
:
Madhu,
Oy, my bad -- I only just noticed you put the toolchain version at the bottom 
of your original email.
It's possible the May 9th toolchain is already too old to build XCTest. I'll 
double-check myself. In the meantime, you may want to try building your own 
toolchain and using that.
- Brian Gesiak






On Sun, May 29, 2016 at 7:23 AM -0700, "Brian Gesiak"  
wrote:










Madhu,
Thanks for the report!
The main difference between the build scripts (which use xcodebuild) and using 
Xcode itself is the version of Swift that is used. The build scripts build a 
Swift 3.0 compiler, then use that to build XCTest. When using Xcode directly, 
you need to select a recent Swift toolchain yourself.
Which Swift toolchain are you using to compile XCTest in Xcode?
Our tests only make sure apple/swift master works. If the latest Swift 
toolchain from http://swift.org doesn't work, you may have to built your own 
toolchain. You can do so using the `utils/build-toolchain` script in the Swift 
repository.
Once you figure out your Swift toolchain version, let us know! You should be 
able to find out in the preferences pane in Xcode.
- Brian Gesiak





On Sun, May 29, 2016 at 1:24 AM -0700, "Madhu Samuel via swift-corelibs-dev" 
 wrote:










Hi All,
I am new to this forum. 
I am trying to build the xctest project. I followed the instructions at 
https://github.com/apple/swift-corelibs-xctest
I am able to successfully build via the build scripts. But, if I build XCTest 
using xcode using the SwiftXCTest scheme I am getting a few errors. 
1. swift-corelibs-foundation/Foundation/NSXMLDTDNode.swift:242:64: error: 
cannot convert value of type 'UnsafeMutablePointer' (aka 
'UnsafeMutablePointer<()>') to expected argument type 'OpaquePointer'           
 let unmanaged = Unmanaged.fromOpaque(privateData)
2. swift-corelibs-foundation/Foundation/NSTimer.swift:14:47: error: cannot 
convert value of type 'UnsafeMutablePointer' (aka 
'UnsafeMutablePointer<()>') to expected argument type 'OpaquePointer'    let t 
= Unmanaged.fromOpaque(info!).takeUnretainedValue()
etc.
My dev environment, OS: Mac OSX El Capitan 10.11.4 (15E65).Xcode Version: 
Version 7.3.1 (7D1014)XCode Toolchain: Swift Development Snapshot 2016-05-09 (a)
Any help is appreciated.
Regards,Madhu







































___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

[swift-corelibs-dev] Performance testing via SwiftPM and XCTest

[Brian Gesiak via swift-corelibs-dev]

Hello corelibs-dev and build-dev,

Back in May, Brian Croom implemented performance testing in
swift-corelibs-xctest:
https://github.com/apple/swift-corelibs-xctest/pull/109

I’d love to see Swift developers use this feature to measure the
performance of their code. I think we’ll need to add functionality to
swift-corelibs-xctest and SwiftPM in order to do so.
The problem: recording performance test baselines

In order for performance tests to be useful, Apple’s Xcode provides a way
to record “baseline” metrics. Baseline metrics allow a developer to
indicate “this performance test should never be slower than 1.2 seconds on
average, with 10% standard deviation as ‘wiggle room’”. When Apple XCTest
tests are run, they are informed of the baseline metrics that have been set
in Xcode. Apple XCTest performance tests that have a baseline registered
will fail if performance becomes slower than the acceptable amount.

If we could provide swift-corelibs-xctest with a mapping from each
performance test to its baseline metric, it would be easy to write the code
to fail a test if it didn’t perform well enough. That mapping, however, is
the tricky part. Here’s why:

   - The mapping needs to group metrics based on the host machine running
   the test. Performance will of course vary based on the hardware, so it’s
   important to make sure performance baselines set on a Raspberry Pi aren’t
   used when testing on a Mac Pro.
   - The mapping also needs to group metrics based on the target machine.
   Using Apple XCTest, a developer can start a test suite run from their
   MacBook Pro (macOS 64-bit), and see the results of the performance tests
   when run on their iPhone 6s (iOS armv7s). I don’t think this is relevant to
   swift-corelibs-xctest just yet — as far as I know, SwiftPM is not capable
   of cross-compilation, so the host machine will always be identical to the
   target machine. Still, we should design something flexible enough for this
   scenario.

Xcode’s solution: plist files

Xcode’s solves this problem using two kinds of .plist files. I tried
creating a sample project, named Perforate.xcodeproj, which contained a
single performance test. Here’s what Xcode created:


http://www.apple.com/DTDs/PropertyList-1.0.dtd";>

runDestinationsByUUID


8CE9E051-9AB6-44AF-8B80-F2DEFD409CB5


localComputer

busSpeedInMHz
100
cpuCount
1
cpuKind
Intel Core i7
cpuSpeedInMHz
2800
logicalCPUCoresPerPackage
8
modelCode
MacBookPro11,3
physicalCPUCoresPerPackage
4
platformIdentifier
com.apple.platform.macosx


targetArchitecture
x86_64
targetDevice

modelCode
iPhone8,2
platformIdentifier

com.apple.platform.iphonesimulator






http://www.apple.com/DTDs/PropertyList-1.0.dtd";>
classNames

PerforateTests


test_uniqueOrdered_performance



com.apple.XCTPerformanceMetric_WallClockTime

baselineAverage
0.5

baselineIntegrationDisplayName
Local Baseline





Proposed solution for SwiftPM/swift-corelibs-xctest: JSON files

I think we can mimic Xcode’s approach here. Here’s what I’m proposing:

   - swift-corelibs-xctest’s test runner should take a --performance-metrics
argument, where  is the location of a file containing JSON
   that looks pretty much exactly like the
   8CE9E051-9AB6-44AF-8B80-F2DEFD409CB5.plist from above:

{
  "classNames": {
"PerforateTests": {
  "test_uniqueOrdered_performance": {
"baselineAverage": "0.5",
"baselineIntegrationDisplayName": "Local Baseline"
  }
}
  }}


   - SwiftPM’s swift test command should also take a --performance-metrics
argument, where  is the location of a file containing JSON
   that looks pretty much exactly like the
   xcbaselines/DA77262F1

Re: [swift-corelibs-dev] Performance testing via SwiftPM and XCTest

[Brian Gesiak via swift-corelibs-dev]

I received some feedback on this proposal from Ankit Aggarwal, which
centered on how developers would edit and update their baseline metrics.
Here’s what I’m envisioning specifically:
Two new command-line options for swift test

   1. swift test --performance-metrics . This is a path to a
   directory where JSON files containing the baseline metrics for the tests
   will be stored. By default, this path will be
   MyPackage/Tests/PerformanceMetrics. In my previous email, I suggested
   the default --performance-metrics path could be set to the same path as
   the swift test --build-path directory, but I have reconsidered. This is
   because I think developers would want to check their baseline metrics JSON
   files into source control, so that they can share metrics with one another,
   and with their continuous integration servers.
   2. swift test --performance-metrics-update , where  is one
   of {all|new|better|worse|none}. This specifies the behavior SwiftPM
   should take when writing baseline metrics data into the JSON files at the
   --performance-metrics path.
  - all: Write baseline metrics data for all performance test cases. If
  metrics for those test cases already exist in the JSON, they are
  overwritten.
  - new: Only write baseline metrics for performance test cases that
  did not already exist in the baseline metrics JSON. This is the default.
  - better: Only write baseline metrics for performance test cases
  whose performance has improved compared to the last time they
were run. If
  baseline metrics for those test cases already exist in the JSON, they are
  overwritten. If baseline metrics for those test cases does not
exist in the
  JSON, they are written to the JSON.
  - worse: Only write baseline metrics for performance test cases whose
  performance has worsened compared to the last time they were run. If
  baseline metrics for those test cases already exist in the JSON, they are
  overwritten. If baseline metrics for those test cases does not
exist in the
  JSON, they are written to the JSON.

Two new command-line options for swift-corelibs-xctest executables

   1. --performance-metrics . This is a path to a JSON file
   containing a mapping from test cases to baseline metrics.
  - If not specified, performance tests are not run against any
  baseline metrics, and so will never fail.
  - If specified, performance test cases will be run against these
  metrics. Based on the --performance-metrics-update mode (see below),
  performance test cases may fail if their performance does not meet the
  baseline.
   2. --performance-metrics-update . Same as the swift test
   --performance-metrics-update parameter.

PerformanceMetrics directory

If a package’s tests contain any performance tests (i.e.: tests that call
XCTestCase.measure(), XCTestCase.measureMetrics(), etc.), running swift test
will result in the following directories and files being generated:

MyPackage/
.build/
Sources/
Tests/
LinuxMain.swift
MyPackage/
MyPackageTests.swift
PerformanceMetrics/  # Generated if any performance tests are
run. This is the path specified by --performance-metrics.
MyPackage/
Destinations.json  # Contains
a mapping of "runDestinationsByUUID".
8CE9E051-9AB6-44AF-8B80-F2DEFD409CB5.json  # An
individual run destination's baseline metrics.

In order to avoid name collisions, developers will no longer be able to
name their test modules “PerformanceMetrics”.
What happens when swift test is run

   1. swift test, using the default arguments, would be the equivalent of swift
   test --performance-metrics ./Tests/PerformanceMetrics
   --performance-metrics-update new.
   2. SwiftPM determines which of the destinations defined in
   Destinations.json to pass to XCTest. For example, if testing on a macOS
   64-bit system with one processor, SwiftPM attempts to find a run
   destination UUID in Destinations.json that matches those criteria. If no
   Destinations.json file exists, SwiftPM creates a mapping in memory.
   3. SwiftPM invokes LinuxMain.swift, passing swift-corelibs-xctest the
   path to a run destination’s baseline metrics file (in this case,
--performance-metrics
   8CE9E051-9AB6-44AF-8B80-F2DEFD409CB5.json), as well as the update
   behavior (all, new, better, or worse). This file may not already exist,
   such as in the case that a Destinations.json file did not exist, or that
   a JSON file for this particular run destination did not exist.
   4. swift-corelibs-xctest parses the JSON in the baseline metrics JSON
   file it is given, and stores in memory the mappings from test cases to
   their baseline metrics. If the file is empty or does not exist,
   swift-corelibs-xctest stores an empty mapping.
   5. swift-corelibs-xctest runs the tests. If a test exists in the mapping
   from step 4, it co

Re: [swift-corelibs-dev] Performance testing via SwiftPM and XCTest

[Brian Gesiak via swift-corelibs-dev]

Hi, it’s me again. :)

I figured out how we can do this on Darwin: by using .xctestconfiguration
files.
SwiftPM performance tests on Darwin, using XCTestConfiguration files

Xcode passes all sorts of variables to XCTest by specifying the
XCTestConfigurationFilePath=/path/to/an.xctestconfiguration plist file as
an environment variable.

You can see this for yourself by running a unit test suite via Xcode or
xcodebuild on Darwin. When you do, Xcode prints the path to a “test session
log”. That file contains logs that show Xcode is launching XCTest with
XCTestConfiguration environment variables set. The XCTestConfiguration
files are binary plists, which you can convert to XML by using plutil
-convert xml1 .

XCTestConfiguration files appear to specify the paths to baseline metrics
plist files using the baselineFileURL and baselineFileRelativePath keys.
XCTest then parses these plists to determine the baseline metrics to run
performance tests against.

So, SwiftPM could run performance tests on Darwin by passing XCTest

a XCTestConfigurationFilePath=/path/to/an.xctestconfiguration environment
variable, and by specifying the baseline file paths in that plist file.
JSON vs. plist, and other questions

Because the Darwin path for SwiftPM performance testing requires plists be
used, I wonder whether we should use plists to store baseline metrics on
all platforms.

I think this is about as far as I can go short of either:

   1. Getting feedback from Apple employees (and others!)
   2. Submitting an official evolution proposal

I’ll submit a proposal within a week or so. Feedback before then would be
very much appreciated!! :)

- Brian Gesiak
​

On Tue, Jul 26, 2016 at 2:42 AM, Brian Gesiak  wrote:

> I received some feedback on this proposal from Ankit Aggarwal, which
> centered on how developers would edit and update their baseline metrics.
> Here’s what I’m envisioning specifically:
> Two new command-line options for swift test
>
>1. swift test --performance-metrics . This is a path to a
>directory where JSON files containing the baseline metrics for the tests
>will be stored. By default, this path will be
>MyPackage/Tests/PerformanceMetrics. In my previous email, I suggested
>the default --performance-metrics path could be set to the same path
>as the swift test --build-path directory, but I have reconsidered.
>This is because I think developers would want to check their baseline
>metrics JSON files into source control, so that they can share metrics with
>one another, and with their continuous integration servers.
>2. swift test --performance-metrics-update , where  is one
>of {all|new|better|worse|none}. This specifies the behavior SwiftPM
>should take when writing baseline metrics data into the JSON files at the
>--performance-metrics path.
>   - all: Write baseline metrics data for all performance test cases.
>   If metrics for those test cases already exist in the JSON, they are
>   overwritten.
>   - new: Only write baseline metrics for performance test cases that
>   did not already exist in the baseline metrics JSON. This is the default.
>   - better: Only write baseline metrics for performance test cases
>   whose performance has improved compared to the last time they were run. 
> If
>   baseline metrics for those test cases already exist in the JSON, they 
> are
>   overwritten. If baseline metrics for those test cases does not exist in 
> the
>   JSON, they are written to the JSON.
>   - worse: Only write baseline metrics for performance test cases
>   whose performance has worsened compared to the last time they were run. 
> If
>   baseline metrics for those test cases already exist in the JSON, they 
> are
>   overwritten. If baseline metrics for those test cases does not exist in 
> the
>   JSON, they are written to the JSON.
>
> Two new command-line options for swift-corelibs-xctest executables
>
>1. --performance-metrics . This is a path to a JSON file
>containing a mapping from test cases to baseline metrics.
>   - If not specified, performance tests are not run against any
>   baseline metrics, and so will never fail.
>   - If specified, performance test cases will be run against these
>   metrics. Based on the --performance-metrics-update mode (see
>   below), performance test cases may fail if their performance does not 
> meet
>   the baseline.
>2. --performance-metrics-update . Same as the swift test
>--performance-metrics-update parameter.
>
> PerformanceMetrics directory
>
> If a package’s tests contain any performance tests (i.e.: tests that call
> XCTestCase.measure(), XCTestCase.measureMetrics(), etc.), running swift
> test will result in the following directories and files being generated:
>
> M

Re: [swift-corelibs-dev] Performance testing via SwiftPM and XCTest

[Brian Gesiak via swift-corelibs-dev]

I received some feedback from Paulo Faria that I’d like to share here:

Is there a way to change the performance test baselines by code? I can’t
find a way to do it today. So my question would be, why can’t we set the
baselines by code? Is it because we need a different baseline for each
different machine configuration? I think some of the configurations make
more sense to be defined in code — the maximum standard deviation, for
example. Sometimes we want to test performance of a memory intensive
operation and usually the standard deviation is bigger in those cases. This
wouldn’t be an SwiftPM issue though… it would be more of a XCTest issue.

Also, isn’t the long term goal for SwiftPM to allow different testing
frameworks? I think we should take that into consideration when designing
the performance tests integration. The proposal feels very coupled with
XCTest… like the comment about using plist instead of JSON.

Thanks for the feedback!! To answer your questions:
On coupling with XCTest

Yes, the current proposal focuses on XCTest. Its goal is to support XCTest
performance tests in SwiftPM. As I’ve looked into them over the past couple
of days, I’ve begun to realize that performance tests are a fascinating
topic. XCTest is merely one implementation. It’s not the best one, but it
is the one that Apple provides to developers that use Xcode, and
SwiftPM/corelibs-xctest do have an active mission to maintain source
compatibility.

I think limiting the scope here to just XCTest helps make forward progress
possible for now. I plan on drafting a separate proposal for third-party
testing support soon.

You mention using plists as evidence of coupling to XCTest, but I don’t
think this is the case for three reasons:

   1. swift-corelibs-foundation provides utilities to parse plist files.
   Cross-platform, Swift-first testing libraries should have no problem
   parsing plists.
   2. The motivation to use plists is motivated by Xcode, not XCTest. Many
   developers already have baseline plist files. Using plists in SwiftPM
   theoretically allows them to “reuse” those plist files.
   3. My opinion is that using plists allows us to share more with the
   Apple Xcode and XCTest systems, but that opinion isn’t a strong one. We
   could define an entirely new JSON format for baseline files. I just think
   reusing plists is less work, and requires less discussion on
   swift-evolution. :slightly_smiling_face:

On defining baselines programatically

Apple XCTest does not provide this functionality, and swift-corelibs-xctest
does not yet provide any APIs that are not provided by Apple XCTest. I
think proposing APIs that don’t exist in Apple XCTest is a leap that many
would be opposed to. After all, Swift committers believe
swift-corelibs-xctest provides an API that is inherently incompatible with
Swift. Convincing them that we should work on additional APIs on top of it
would be a lot of work!

- Brian Gesiak
​

On Tue, Jul 26, 2016 at 12:38 PM, Brian Gesiak  wrote:

> Hi, it’s me again. :)
>
> I figured out how we can do this on Darwin: by using .xctestconfiguration
> files.
> SwiftPM performance tests on Darwin, using XCTestConfiguration files
>
> Xcode passes all sorts of variables to XCTest by specifying the
> XCTestConfigurationFilePath=/path/to/an.xctestconfiguration plist file as
> an environment variable.
>
> You can see this for yourself by running a unit test suite via Xcode or
> xcodebuild on Darwin. When you do, Xcode prints the path to a “test
> session log”. That file contains logs that show Xcode is launching XCTest
> with XCTestConfiguration environment variables set. The XCTestConfiguration
> files are binary plists, which you can convert to XML by using plutil
> -convert xml1 .
>
> XCTestConfiguration files appear to specify the paths to baseline metrics
> plist files using the baselineFileURL and baselineFileRelativePath keys.
> XCTest then parses these plists to determine the baseline metrics to run
> performance tests against.
>
> So, SwiftPM could run performance tests on Darwin by passing XCTest
> 
> a XCTestConfigurationFilePath=/path/to/an.xctestconfiguration environment
> variable, and by specifying the baseline file paths in that plist file.
> JSON vs. plist, and other questions
>
> Because the Darwin path for SwiftPM performance testing requires plists be
> used, I wonder whether we should use plists to store baseline metrics on
> all platforms.
>
> I think this is about as far as I can go short of either:
>
>1. Getting feedback from Apple employees (and others!)
>2. Submitting an official evolution proposal
>
> I’ll submit a proposal within a week or so. Feedback before then would be
> very much appreciated!! :)
>
> - Brian Gesiak
> ​
>
> On Tue, Jul 26, 2016 at 2:42 AM, Brian Gesiak  wrote:
>
>> I received some feedback on this proposal from An

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

[Brian Gesiak via swift-corelibs-dev]

Thanks for the heads up, Tony!

(+cc corelibs-xctest release manager Mike Ferris)
Just to confirm, we are not resolving https://bugs.swift.org/browse/SR-710,
"Generate XCTestCaseProvider entries on Linux", in time for the Swift 3
release. Is this correct?

- Brian Gesiak


On Fri, Jul 29, 2016 at 2:29 PM, Tony Parker via swift-corelibs-dev <
swift-corelibs-dev@swift.org> wrote:

> Hi Gonzalo,
>
> While not a complete solution for the issues around bridging, the work on
> id-as-Any that I mentioned below was meant to help address these platform
> differences.
>
> For example, let’s say you had a Foundation API that looked like this in
> ObjC:
>
> - (void)foo:(id)x;
>
> and imported like this into Swift:
>
> func foo(_ x : AnyObject)
>
> On Linux, attempting to call this:
>
> bar.foo(“hello”)
>
> would result in an error, because String is not an object type. On Darwin,
> String was implicitly bridged to NSString here for you.
>
> Now (hopefully — I’m still working on verifying this), the above is
> imported like this:
>
> func foo(_ x : Any)
>
> which means that on Linux, this should actually work:
>
> bar.foo(“hello”)
>
> because String is indeed an Any. No need to do something like
> “hello”.bridge().
>
> AnyHashable also helps. because we should be able to express API which
> takes untyped dictionaries with AnyHashable keys instead of NSObject keys.
>
> Most of this stuff has only landed in the last week or two, so if you can
> give it a try and let us know how well it works out, that would be great.
>
> - Tony
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.md
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0131-anyhashable.md
>
>
> On Jul 29, 2016, at 11:06 AM, Gonzalo Larralde 
> wrote:
>
> Hi everyone,
>
> Wanted to know if there's any plan to find a solution for Auto Bridging
> between corelibs-foundation <> Swift types in the same manner as it is done
> for Obj-C.
>
> There has been some discussions about this in the following PRs:
>
> https://github.com/apple/swift-corelibs-foundation/pull/310
> https://github.com/apple/swift-corelibs-foundation/pull/303
> https://github.com/apple/swift/pull/1994
>
> The inclusion of this feature will allow more non-UIKit related packages
> to be used with almost  no changes.
>
> For what I understand the main blocker here is getting this to pass
> through Swift review (probably a more generic version of it, like
> _BridgeableType instead of _ObjectiveCBridgeable would help?), but wanted
> to understand first if this is a priority for the foundation team, and
> there is something that can be done to push for this feature.
>
> Thanks!
>
>
> --
> Slds,
>
> Gonzalo.
>
> On Thu, Jul 28, 2016 at 6:22 PM, Matt Wright via swift-corelibs-dev <
> swift-corelibs-dev@swift.org> wrote:
>
>> The overlay changes were merged to corelibs libdispatch this morning.
>>
>> Sent from my iPhone.
>>
>> On Jul 28, 2016, at 2:03 PM, Tony Parker via swift-corelibs-dev <
>> swift-corelibs-dev@swift.org> wrote:
>>
>> Hi Dave,
>>
>> I don’t believe anyone is looking into this. If you want to do that, I
>> think now would be the time!
>>
>> - Tony
>>
>> On Jul 28, 2016, at 10:50 AM, David P Grove via swift-corelibs-dev <
>> swift-corelibs-dev@swift.org> wrote:
>>
>> Tony Parker wrote on 07/28/2016 01:41:55 PM:
>> >
>> > 1. Integrate swift-corelibs-dispatch into Foundation.
>>
>> Hi Tony,
>>
>> Hopefully this is on the task list already, but if it isn't we should add
>> it before it gets to be too late to change the compiler...
>>
>> When compiling a Swift program on Linux that imports Dispatch (or
>> Foundation once the integration is done), the user has to give the extra
>> compilation flags -Xcc -fblocks to enable block support.
>>
>> We really need to land a change somewhere so that either (1) blocks
>> support is always on for Linux or (2) importing Dispatch or Foundation
>> automatically turns on blocks support.
>>
>> I have some time today and tomorrow that I could use to work on this if
>> no one is handling it already, but I'm not sure how best to tackle the
>> problem.  Suggestions?
>>
>> --dave
>>
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>>
>>
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>>
>>
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>>
>>
>
>
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>
>
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swi

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

[Brian Gesiak via swift-corelibs-dev]

I think a future release is prudent, for the following reasons:

1. swift-corelibs-xctest requires users to list each of their tests in an
`allTests` static property. However, this isn't source-incompatible with
Darwin XCTest. A developer could include the list on Darwin, and their
tests would still compile and run just fine.
2. We decided back in May that [this feature should be implemented by using
SourceKit](
https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160502/001940.html).
Although while SourceKit can technically now be compiled for Linux, it has
a dependency upon libdispatch. To build it, we need to refactor the build
system to (1) first build the Swift compiler and stdlib, (2) then build
libdispatch, (3) finally build SourceKit. I'm not certain that can be done
by August 18th (although I'd love to hear from anyone who disagrees!).
3. Even if we were able to complete step (2), we'd still have to integrate
that feature into swift-corelibs-xctest and SwiftPM, which will no doubt
take some additional time.

Still, I'm looking forward to this being shipped this in Swift 3.x!

- Brian Gesiak


On Fri, Jul 29, 2016 at 3:41 PM, Tony Parker 
wrote:

> Hm, I’ll have to defer to Mike on the status of this one.
>
> If it’s not in place now, we should probably schedule it for a future
> release.
>
> - Tony
>
> On Jul 29, 2016, at 11:43 AM, Brian Gesiak  wrote:
>
> Thanks for the heads up, Tony!
>
> (+cc corelibs-xctest release manager Mike Ferris)
> Just to confirm, we are not resolving https://bugs.swift.org/browse/SR-710,
> "Generate XCTestCaseProvider entries on Linux", in time for the Swift 3
> release. Is this correct?
>
> - Brian Gesiak
>
>
> On Fri, Jul 29, 2016 at 2:29 PM, Tony Parker via swift-corelibs-dev <
> swift-corelibs-dev@swift.org> wrote:
>
>> Hi Gonzalo,
>>
>> While not a complete solution for the issues around bridging, the work on
>> id-as-Any that I mentioned below was meant to help address these platform
>> differences.
>>
>> For example, let’s say you had a Foundation API that looked like this in
>> ObjC:
>>
>> - (void)foo:(id)x;
>>
>> and imported like this into Swift:
>>
>> func foo(_ x : AnyObject)
>>
>> On Linux, attempting to call this:
>>
>> bar.foo(“hello”)
>>
>> would result in an error, because String is not an object type. On
>> Darwin, String was implicitly bridged to NSString here for you.
>>
>> Now (hopefully — I’m still working on verifying this), the above is
>> imported like this:
>>
>> func foo(_ x : Any)
>>
>> which means that on Linux, this should actually work:
>>
>> bar.foo(“hello”)
>>
>> because String is indeed an Any. No need to do something like
>> “hello”.bridge().
>>
>> AnyHashable also helps. because we should be able to express API which
>> takes untyped dictionaries with AnyHashable keys instead of NSObject keys.
>>
>> Most of this stuff has only landed in the last week or two, so if you can
>> give it a try and let us know how well it works out, that would be great.
>>
>> - Tony
>>
>>
>> https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.md
>>
>> https://github.com/apple/swift-evolution/blob/master/proposals/0131-anyhashable.md
>>
>>
>> On Jul 29, 2016, at 11:06 AM, Gonzalo Larralde 
>> wrote:
>>
>> Hi everyone,
>>
>> Wanted to know if there's any plan to find a solution for Auto Bridging
>> between corelibs-foundation <> Swift types in the same manner as it is done
>> for Obj-C.
>>
>> There has been some discussions about this in the following PRs:
>>
>> https://github.com/apple/swift-corelibs-foundation/pull/310
>> https://github.com/apple/swift-corelibs-foundation/pull/303
>> https://github.com/apple/swift/pull/1994
>>
>> The inclusion of this feature will allow more non-UIKit related packages
>> to be used with almost  no changes.
>>
>> For what I understand the main blocker here is getting this to pass
>> through Swift review (probably a more generic version of it, like
>> _BridgeableType instead of _ObjectiveCBridgeable would help?), but wanted
>> to understand first if this is a priority for the foundation team, and
>> there is something that can be done to push for this feature.
>>
>> Thanks!
>>
>>
>> --
>> Slds,
>>
>> Gonzalo.
>>
>> On Thu, Jul 28, 2016 at 6:22 PM, Matt Wright via swift-corelibs-dev <
>> swift-corelibs-dev@swift.org> wrote:
>>
>>> The overlay changes were merged to corelibs libdispatch this morning.
>>>
>>> Sent from my iPhone.
>>>
>>> On Jul 28, 2016, at 2:03 PM, Tony Parker via swift-corelibs-dev <
>>> swift-corelibs-dev@swift.org> wrote:
>>>
>>> Hi Dave,
>>>
>>> I don’t believe anyone is looking into this. If you want to do that, I
>>> think now would be the time!
>>>
>>> - Tony
>>>
>>> On Jul 28, 2016, at 10:50 AM, David P Grove via swift-corelibs-dev <
>>> swift-corelibs-dev@swift.org> wrote:
>>>
>>> Tony Parker wrote on 07/28/2016 01:41:55 PM:
>>> >
>>> > 1. Integrate swift-corelibs-dispatch into Foundation.
>>>
>>> Hi Tony,
>>>
>>> Hopefully this is on the task list already, but if it isn

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

[Brian Gesiak via swift-corelibs-dev]

Speaking of JIRA tasks, I remembered this morning that the versions of
swift-corelibs-foundation and swift-corelibs-xctest expose public API that
does not exist in their Apple counterparts. This is because of a bug in the
linker that prevents us from marking attributes as private:

- https://bugs.swift.org/browse/SR-1129
- https://bugs.swift.org/browse/SR-1901

It would be great if we could fix this problem prior to the Swift 3
release, but if not, we need to be aware that some people may end up using
or relying upon these "unintentionally public" API.

- Brian Gesiak


On Wed, Aug 3, 2016 at 2:10 PM, Daniel Dunbar via swift-corelibs-dev <
swift-corelibs-dev@swift.org> wrote:

> 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 Dunbar on this. Adding -Xcc
> -fblocks as a default option to Swift PM (on Linux). The wrinkle is the
> availability of the blocks runtime - it would either need to become a
> pre-req for Swift, or needs one to be built into the package.
>
> Chris
>
>
>
>
> From:David P Grove via swift-corelibs-dev <
> swift-corelibs-dev@swift.org>
> To:Swift corelibs dev 
> Date:28/07/2016 18:50
> Subject:Re: [swift-corelibs-dev] Wrapping up Swift 3 for
> swift-corelibs
> Sent by:swift-corelibs-dev-boun...@swift.org
> --
>
>
>
> Tony Parker wrote on 07/28/2016 01:41:55 PM:
> >
> > 1. Integrate swift-corelibs-dispatch into Foundation.
>
> Hi Tony,
>
> Hopefully this is on the task list already, but if it isn't we should add
> it before it gets to be too late to change the compiler...
>
> When compiling a Swift program on Linux that imports Dispatch (or
> Foundation once the integration is done), the user has to give the extra
> compilation flags -Xcc -fblocks to enable block support.
>
> We really need to land a change somewhere so that either (1) blocks
> support is always on for Linux or (2) importing Dispatch or Foundation
> automatically turns on blocks support.
>
> I have some time today and tomorrow that I could use to work on this if no
> one is handling it already, but I'm not sure how best to tackle the
> problem.  Suggestions?
>
> --dave
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>
>
>
>
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>
>
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Building with Xcode

[Brian Gesiak via swift-corelibs-dev]

I use the following to build Foundation and XCTest, then run the XCTest tests:
swift $ utils/build-script --preset corelibs-xctest 
The XCTest.xcworkspace is also capable of building and testing. Open it, select 
the XCTest scheme, and build with ⌘B. You should also be able to build the 
Foundation scheme from there as well.
- Brian Gesiak






On Thu, Aug 18, 2016 at 4:14 PM -0400, "Tony Parker via swift-corelibs-dev" 
 wrote:










Hi Luke,
In Xcode it should be possible to set the build order like this:
FoundationXCTestTestFoundation
which should resolve the ordering issue, right? I do this with a build scheme.
- Tony
On Aug 17, 2016, at 6:13 PM, Luke Howard via swift-corelibs-dev 
 wrote:
This is probably a dumb question. Building with XCode, TestFoundation depends 
on SwiftXCTest, which depends on SwiftFoundation. What’s the right way to solve 
this (almost) recursive dependency? I’m using the Xcode 8.0 beta6.
I worked around by symlinking the uninstalled build products directory to 
/Library/Frameworks and adding that as a search path to both projects, but 
presumably there’s a better way. Sorry for the noise if this has been discussed 
before, haven’t built SwiftFoundation for a while.


--www.lukehoward.com
soundcloud.com/lukehoward___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev






___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Getting tests to work in xcode for foundation.

[Brian Gesiak via swift-corelibs-dev]

Dan,
Unfortunately, the method that Xcode uses to display tests in the test 
navigator is private. We are unable to implement that functionality in 
swift-corelibs-xctest. If you'd like to see this working, please file an Apple 
Radar that asks the Developer Tools team to document how this system works. 
Until then, you won't see any tests or their results in Xcode's test navigator. 
:(
Instead, you'll need to check the test output printed to stdout. If you open 
the console in Xcode, you should see the output from each of the tests, 
including whether they passed or failed. That should tell you which test is 
failing,
Can you explain what you mean by "[the test navigator in Xcode] wants me to add 
a new target"? Is Xcode prompting you to add a unit test target?
- Brian Gesiak




On Tue, Sep 6, 2016 at 5:14 AM -0400, "Dan Tugendraich via swift-corelibs-dev" 
 wrote:










I have performed all the getting started steps in; 
https://github.com/apple/swift-corelibs-foundation/blob/swift-3.0-branch/Docs/GettingStarted.mdEverything
 seems to be working fine, I can build the SwiftFoundation target and I can run 
the TestFoundation target. In the console I can see tests are being run. One of 
the tests are failing in the test-suite. But I have no way of checking which 
test and why because the test navigator window in Xcode is empty. It wants me 
to add a new target, but I want it to show the already existing test target 
”TestFoundation”. Any ideas on how to achieve this?


Dan Tugendraich




Kärleksgatan 2, 211 45 Malmö+46 (0) 40 330 480







___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] SwiftXCTest proposals to make it more useful as a framework and for other platforms

[Brian Gesiak via swift-corelibs-dev]

Hey Ilya,

I'm glad you're thinking about how to use corelibs-xctest on mobile
devices. I'd like to prepare it for Android as well, and I think there's a
lot of overlap here.

> This proposal is because Swift has very poor reflection at the moment. So
I suggest creating a generator (pre-build script) for Swift test cases that
for example is able analysing concrete folder with swift files and generate
e.g. TestCases.swift file. This script is intended to be used manually.

You should check out https://bugs.swift.org/browse/SR-710. There's been a
great deal of discussion on this topic in the past. I think we left off
with the idea that we should use SourceKit to generate the list of tests
(+cc Daniel Dunbar). This work has largely been abandoned. If you'd like to
pick it up, you could have huge impact!

I'm not sure I understand your first two points. Are you suggesting that we
implement some method of kicking off tests on an iOS simulator, but only
when corelibs-xctest framework is linked with the application bundle...?
I'd appreciate it if you could explain what you mean in more detail.

- Brian Gesiak


On Fri, Dec 2, 2016 at 5:57 AM, Ilya Laryionau via swift-corelibs-dev <
swift-corelibs-dev@swift.org> wrote:

> Hello Community,
>
> I’m working on adding iOS platform support for SwiftXCTest. So I’ve have
> the following proposals and would like to hear feedback from the community.
>
>1. SwiftXCTest runs the tests in a way `XCTMain([
>testCase(TestFoo.allTests) ])`. XCTMain supports only Linux / FreeBSD /
>macOS. So I suggest introducing an API that will provide a similar way of
>running tests as XCTMain, but in a case using SwiftXCTest as a framework
>e.g. on iOS. It could be the same logic that just returns exit code, when
>XCTMain just exits with this code.
>2. The suggestion above (number 1) is good, but too simple for using
>SwiftXCTest as a framework, since we only have exit code and debug logs. So
>my second proposal is providing mechanism of initialising root test suite
>with array of testCases (array of XCTestCaseEntry objects) with the same
>structure that XCTMain does. This isn’t possible now since XCTestCaseSuite
>class that is used to initialise root test suite (see XCTMain.swift line
>80) is internal.
>3. This proposal is because Swift has very poor reflection at the
>moment. So I suggest creating a generator (pre-build script) for Swift test
>cases that for example is able analysing concrete folder with swift files
>and generate e.g. TestCases.swift file. This script is intended to be used
>manually.
>
> Looking forward to any feedback.
>
> Ilya
>
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>
>
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] SwiftXCTest proposals to make it more useful as a framework and for other platforms

[Brian Gesiak via swift-corelibs-dev]

Ilya,

I would love to see both of your suggestions implemented, but you may need
to submit a swift-evolution proposal for them. I think Apple employees
maintaining swift-corelibs-xctest would have a better idea of whether your
proposals would be accepted by the core team. (+cc Brian Croom).

I think a good next step would be to reply to this email with the function
signatures for the additions you're proposing. That will allow us to
discuss them in more concrete terms.

Thanks for all the great suggestions!

- Brian Gesiak


On Mon, Dec 5, 2016 at 1:30 AM, Ilya Laryionau  wrote:

> Brian,
>
> I appreciate your comments.
>
> You should check out https://bugs.swift.org/browse/SR-710. There's been a
> great deal of discussion on this topic in the past. I think we left off
> with the idea that we should use SourceKit to generate the list of tests
> (+cc Daniel Dunbar). This work has largely been abandoned. If you'd like to
> pick it up, you could have huge impact!
>
>
> This’s a great comment. I’ll check what I can do.
>
> I'm not sure I understand your first two points. Are you suggesting that
> we implement some method of kicking off tests on an iOS simulator, but only
> when corelibs-xctest framework is linked with the application bundle...?
> I'd appreciate it if you could explain what you mean in more detail.
>
>
> Let me clarify my first two points.
>
>
>1. In general you’re correct. I suggest implementing some method that
>triggers the same logic that XCTestMain does. But instead of calling exit,
>when the work is done, returning the exit code.
>2. I suggest implementing API that allows creating XCTestSuite from a
>list of XCTestCaseEntries.
>
>
> Ilya
>
> On 2 Dec 2016, at 21:00, Brian Gesiak  wrote:
>
> Hey Ilya,
>
> I'm glad you're thinking about how to use corelibs-xctest on mobile
> devices. I'd like to prepare it for Android as well, and I think there's a
> lot of overlap here.
>
> > This proposal is because Swift has very poor reflection at the moment.
> So I suggest creating a generator (pre-build script) for Swift test cases
> that for example is able analysing concrete folder with swift files and
> generate e.g. TestCases.swift file. This script is intended to be used
> manually.
>
> You should check out https://bugs.swift.org/browse/SR-710. There's been a
> great deal of discussion on this topic in the past. I think we left off
> with the idea that we should use SourceKit to generate the list of tests
> (+cc Daniel Dunbar). This work has largely been abandoned. If you'd like to
> pick it up, you could have huge impact!
>
> I'm not sure I understand your first two points. Are you suggesting that
> we implement some method of kicking off tests on an iOS simulator, but only
> when corelibs-xctest framework is linked with the application bundle...?
> I'd appreciate it if you could explain what you mean in more detail.
>
> - Brian Gesiak
>
>
> On Fri, Dec 2, 2016 at 5:57 AM, Ilya Laryionau via swift-corelibs-dev <
> swift-corelibs-dev@swift.org> wrote:
>
>> Hello Community,
>>
>> I’m working on adding iOS platform support for SwiftXCTest. So I’ve have
>> the following proposals and would like to hear feedback from the community.
>>
>>1. SwiftXCTest runs the tests in a way `XCTMain([
>>testCase(TestFoo.allTests) ])`. XCTMain supports only Linux / FreeBSD /
>>macOS. So I suggest introducing an API that will provide a similar way of
>>running tests as XCTMain, but in a case using SwiftXCTest as a framework
>>e.g. on iOS. It could be the same logic that just returns exit code, when
>>XCTMain just exits with this code.
>>2. The suggestion above (number 1) is good, but too simple for using
>>SwiftXCTest as a framework, since we only have exit code and debug logs. 
>> So
>>my second proposal is providing mechanism of initialising root test suite
>>with array of testCases (array of XCTestCaseEntry objects) with the same
>>structure that XCTMain does. This isn’t possible now since XCTestCaseSuite
>>class that is used to initialise root test suite (see XCTMain.swift line
>>80) is internal.
>>3. This proposal is because Swift has very poor reflection at the
>>moment. So I suggest creating a generator (pre-build script) for Swift 
>> test
>>cases that for example is able analysing concrete folder with swift files
>>and generate e.g. TestCases.swift file. This script is intended to be used
>>manually.
>>
>> Looking forward to any feedback.
>>
>> Ilya
>>
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>>
>>
>
>
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev