-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Updating PR 299 (NSURLSession) to work with the latest Foundation #426
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
let errorCode: Int? | ||
} | ||
} | ||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's not check in commented out code, since its purpose is unclear.
Thanks for the comments. I started with a round of deleting commented code with no message. |
I addressed a few of the comments today:
|
] | ||
|
||
if "XCTEST_BUILD_DIR" in Configuration.current.variables: | ||
swift_cflags += [ | ||
'-I${XCTEST_BUILD_DIR}', | ||
'-L${XCTEST_BUILD_DIR}', | ||
'-I${SYSROOT}/usr/include/libxml2' | ||
'-I${SYSROOT}/usr/include/libxml2', | ||
'-I/usr/include/curl' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should also be ${SYSROOT}
attached just like the libxml case so that way cross compile development can specify a root
More changes:
|
I have replaced Unsafe pointers with struct Data in all places except for the libcurl callbacks |
Ok - I want to merge this but I have one strict requirement - we need at least the start of a test suite. Is it possible to get some kind of straightforward loop-back test in place so that we know we aren't going to accidentally break this with changes in the future? |
Sure @parkera I will work on getting some of Daniel's tests running. |
@parkera @phausler : Whats the equivalent of Xcode's "Enable Testability" on Linux? All of Daniel's test cases could be added here if we could get the
|
Isn't the main purpose of |
Some tests use the internal classes to test the public API. Also, there are tests for the internal classes too. We'd need @testable for both |
IIRC the challenge with |
I see that -enable-testing is the flag. If you think using this isn't a good idea, the other option is to rewrite the tests. |
Just seeing this now. I’ve started rebasing my old PR, too. |
@seabaylea @parkera - As per your suggestions I have done the following:
I've also rebased to the latest Foundation. |
Awesome. Kicking off a test. |
@swift-ci please test |
@parkera "We're going to need a remote URL that's as close to 100% reliable as possible." - agreed, as well as building in some resiliency to ignore requests that timeout (rather than an actual failure). |
Hm, it failed again
|
I'm taking a look at whether we can ignore cases where it times out - unfortunately timeout isn't yet implemented (although that looks pretty straightforward to add). |
I was getting similar failures when I was merging it in previously. IIRC it had to do with the JSON getting emitted differently from the id to Any conversions |
Also this PR really needs updates to the xcode project; we should be able to test and run this on Darwin in addition to Linux. |
Ah, is the Dispatch overlay also rebuilt before you recompile Foundation? I remember we had odd ordering around that at one point. |
@jrose-apple I'm not sure how to tell. Can you look at the build log and let me know what you think? |
@parkera @jrose-apple whilst foundation is in build-presets.ini before libdispatch (I've always done it the other way in local builds), from the CI build log it looks to me like libdispatch, including the overlay, builds first regardless. |
If we want to add timeout support, and use that to add either retry logic or ignore the test, it looks like we just need to add the following at line 243 in MultiHandle.swift:
|
Okay, yeah, it looks like it's building in the right order. Actually, it looks like it's finding the dispatch headers, but not the overlay. Maybe that's not in the include paths for swiftpm? |
(The reason the compiler doesn't catch the missing overlay is because I wanted people to feel free to move things between their Swift and C code when it was safe to do so.) |
@pushkarnk Can you update the PR as @seabaylea recommends? Once the test passes reliably we can merge this. |
@jrose-apple thanks - that was it. I've raised PRs against SwiftPM and XCTest to add the build-time location of the Swift 3 overlay to their build/test-time include paths: |
How does this work when we build a toolchain package? Is the Dispatch overlay installed next to the standard library as it is on Apple platforms? |
For the toolchain we install:
which matches the location of the other libraries |
Also includes support for downloadTask and uploadTask with Data and a completion handler. The original PR 299 doesn't build on Ubuntu 14.04, due to an older level of libcurl. This rework removes some of that code (it does not affect any functionality). Updated to use the Dispatch 3.0 API. Includes basic tests with external URLs.
@parkera , @seabaylea : I have added some resiliency in the tests by handling timeouts. I also had to add a basic implementation for Can we test again please, to see how things go? |
@swift-ci please test linux |
It passed! |
Appears #586 does it. Thanks. |
One of the tests added in this pull request, /cc @pushkarnk @parkera |
It looks like #426 addresses that. |
Yup, my bad. Sorry for the noise! |
Sorry, it's #590 actually. |
Will this PR be included in the |
We're planning on merging master to swift-3.0-branch once things are settled down a bit. |
Creating this PR for review, on @parkera 's suggestion. The changes that this PR does to pull request 299 include:
Work in progress:
Kindly review and comment. Thanks.