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

[Daniel Eggert via swift-corelibs-dev]

Is it ok for me to split the libcurl specific code inside Foundation into a 
separate file, say NSURLSession+curl.swift ? Or should I try to keep everything 
inside NSURLSession.swift ?

If I go for a separate file, I'd be able to differentiate between internal and 
private for the helpers. I'll end up close to 1000 lines of code for this. 
Having these inside NSURLSession.swift is a bit overwhelming.

/Daniel

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

Re: [swift-corelibs-dev] Wrong type in NSHTTPURLResponse

[Daniel Eggert via swift-corelibs-dev]

On 15 Mar 2016, at 16:16, Daniel Eggert via swift-corelibs-dev 
<swift-corelibs-dev@swift.org> wrote:
> 
> The allHeaderFields in
> 
> public class NSHTTPURLResponse : NSURLResponse {
>[...]
>public let allHeaderFields: [NSObject : AnyObject]
> }
> 
> should have been [String : String]
> 
> The initialiser has the correct [String : String] type, though.
> 
> Somehow Apple missed this in their API, too. What's the procedure to get this 
> changed / fixed?
> 
> /Daniel


I've changed it as part of this pull request:

https://github.com/apple/swift-corelibs-foundation/pull/287

I'm happy to change it back if need be.

/Daniel

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

Re: [swift-corelibs-dev] NSOperationQueue and friends

[Daniel Eggert via swift-corelibs-dev]

Ok.

That test case fail on OS X, though. Should I open a bug?

/Daniel


> On Mar 28, 2016, at 22:17, Philippe Hausler  wrote:
> 
> DEPLOYMENT_ENABLE_LIBDISPATCH should not be enabled unless you specifically 
> enable it (this is until we get libdispatch fully integrated into the build 
> system)
> 
>> On Mar 28, 2016, at 1:14 PM, Daniel Eggert  wrote:
>> 
>> This is on OS X will everything pulled from master yesterday. I'm using 
>> Xcode, and I built a toolchain from source. Same happens with the 2016-03-24 
>> toolchain from swift.org.
>> 
>> For some reason DEPLOYMENT_ENABLE_LIBDISPATCH isn't set, but I guess it 
>> should be?
>> 
>> /Daniel
>> 
>> 
>>> On 26 Mar 2016, at 22:54, Philippe Hausler  wrote:
>>> 
>>> Is that on Linux? Perhaps it is because it is missing run loop interaction?
>>> 
>>> Sent from my iPhone
>>> 
>>> On Mar 26, 2016, at 10:52 AM, Daniel Eggert  wrote:
>>> 
> 
> On 25 Mar 2016, at 21:15, Philippe Hausler via swift-corelibs-dev 
>  wrote:
> 
> I know a few of you have been waiting for this: I just pushed an initial 
> implementation of NSOperationQueue, NSOperation and NSBlockOperation. It 
> is worth noting that this implementaiton has a few behavioral differences 
> between this implementation and the one implemented in objective-c. Part 
> of this difference is due to features like QoS not being cross platform 
> portable or KVO not yet implementable in Swift. This is very much a 
> work-in-progress; it needs unit tests and and a bit more polish, but 
> hopefully it is good enough to get some work started in some other places.
> 
> - Philippe Hausler
 
 
 Great to see progress on this.
 
 It does fail this simple test case, though:
 
 
 func test_BlockBasedAPI() {
 let queue = NSOperationQueue()
 
 let expectation = expectationWithDescription("did run block")
 queue.addOperationWithBlock {
 expectation.fulfill()
 }
 
 waitForExpectationsWithTimeout(0.001, handler: nil)
 }
 
 I'm not sure what's going on there. I was using this on my branch for 
 NSURLSession since it has a delegate queue that I need to run callbacks on.
 
 /Daniel
> 
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSOperationQueue and friends

[Daniel Eggert via swift-corelibs-dev]

This is on OS X will everything pulled from master yesterday. I'm using Xcode, 
and I built a toolchain from source. Same happens with the 2016-03-24 toolchain 
from swift.org.

For some reason DEPLOYMENT_ENABLE_LIBDISPATCH isn't set, but I guess it should 
be?

/Daniel


> On 26 Mar 2016, at 22:54, Philippe Hausler  wrote:
> 
> Is that on Linux? Perhaps it is because it is missing run loop interaction?
> 
> Sent from my iPhone
> 
> On Mar 26, 2016, at 10:52 AM, Daniel Eggert  wrote:
> 
>>> 
>>> On 25 Mar 2016, at 21:15, Philippe Hausler via swift-corelibs-dev 
>>>  wrote:
>>> 
>>> I know a few of you have been waiting for this: I just pushed an initial 
>>> implementation of NSOperationQueue, NSOperation and NSBlockOperation. It is 
>>> worth noting that this implementaiton has a few behavioral differences 
>>> between this implementation and the one implemented in objective-c. Part of 
>>> this difference is due to features like QoS not being cross platform 
>>> portable or KVO not yet implementable in Swift. This is very much a 
>>> work-in-progress; it needs unit tests and and a bit more polish, but 
>>> hopefully it is good enough to get some work started in some other places.
>>> 
>>> - Philippe Hausler
>> 
>> 
>> Great to see progress on this.
>> 
>> It does fail this simple test case, though:
>> 
>> 
>>   func test_BlockBasedAPI() {
>>   let queue = NSOperationQueue()
>> 
>>   let expectation = expectationWithDescription("did run block")
>>   queue.addOperationWithBlock {
>>   expectation.fulfill()
>>   }
>> 
>>   waitForExpectationsWithTimeout(0.001, handler: nil)
>>   }
>> 
>> I'm not sure what's going on there. I was using this on my branch for 
>> NSURLSession since it has a delegate queue that I need to run callbacks on.
>> 
>> /Daniel
>> 

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

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

[Daniel Eggert via swift-corelibs-dev]

Changes since last week:

NSURLSessionDataTask (i.e. GET requests) now work with callbacks and with 
completion handler.

Debug output is enabled by environment variables.

Handling a few common error scenarios to return the corresponding NSError.

/Daniel

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

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

[Daniel Eggert via swift-corelibs-dev]

> On 08 Apr 2016, at 01:44, Daniel Dunbar <daniel_dun...@apple.com> wrote:
> 
>> 
>> On Apr 7, 2016, at 10:15 AM, Daniel Eggert via swift-corelibs-dev 
>> <swift-corelibs-dev@swift.org> wrote:
>> 
>> With this being merged
>> 
>> https://github.com/apple/swift-corelibs-foundation/pull/305
>> 
>> where do I find a compiler that works? Everything stopped working for me, 
>> because utils/update-checkout currently checks out something that can't 
>> build a toolchain.
> 
> Yes, this unfortunately just a reality of the language changing on trunk and 
> the current development model -- if you want to track trunk you at times will 
> need to build from trunk and not a snapshot.

I was trying to build off master, but it was failing for me. Works now. Sorry 
for the noise.

/Daniel

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

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

[Daniel Eggert via swift-corelibs-dev]

On 08 Apr 2016, at 16:52, Tony Parker  wrote:
> 
> These are turbulent times for syntax in Swift. :)
> 
> Pretty soon now we're also going to have to deal with the swift renaming 
> rules as applied to all functions in corelibs-foundation. 
> 
> - Tony

I know. Trying to rebase my 5k+ line changes against master is turning into a 
full day undertaking at this point.



I'm currently seeing thousands of these on master:

.../Swift/swift-corelibs-foundation/Foundation/NSArray.swift:257:31: Extraneous 
'_' in parameter: 'anObject' has no keyword argument name

Is someone going to clean that up "soon"? I lost track of what we're trying to 
go for with the naming changes.

/Daniel

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

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

[Daniel Eggert via swift-corelibs-dev]

> On 14 Mar 2016, at 18:29, Robert Stephen Thompson 
>  wrote:
> 
> Just a couple of tips based on my experience wrapping libxml2 for 
> NSXMLDocument:
> 1. You’ll need to actually import and link libcurl with CoreFoundation 
> instead of trying to make a libcurl module.modulemap and importing it 
> directly. This is because if you do it that way, you’ll have to add libcurl 
> as a dependency _throughout_ the Swift build process, and it would all be 
> pretty disruptive (and difficult to do).
> 2. As a consequence of 1., you’ll need to wrap every function you call from 
> libcurl in a new CoreFoundation API. See CFXMLInterface.h and 
> CFXMLInterface.c for what I mean. Of course, this also gives you the 
> opportunity to add nullability annotations, wrap things in CFString, CFError, 
> CFArray, etc, so it’s not just busy-work for getting around the build system, 
> heh. Just depends on how much C you want to write, you could just straight 
> wrap the libcurl functions and do everything in Swift, but at the very least 
> nullability annotations are a win here.


I just looked at this, and libxml2 is being linked against by SwiftFoundation, 
and NOT by CoreFoundation -- on Darwin.

Is the correct approach to do what's been done with libxml2, or should I 
instead have CoreFoundation link against libcurl?

/Daniel

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

Re: [swift-corelibs-dev] NSOperationQueue and friends

[Daniel Eggert via swift-corelibs-dev]

> On 28 Mar 2016, at 23:59, Philippe Hausler  wrote:
> 
> the swift-corelibs-foundation compiled for Darwin does not define that yet 
> either. Are you seeing issues with it when defined?


When I add

OTHER_SWIFT_FLAGS = -DDEPLOYMENT_ENABLE_LIBDISPATCH

it works. So I guess that's what I should do?

/Daniel

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

Re: [swift-corelibs-dev] NSURL getResourceValue

[Daniel Eggert via swift-corelibs-dev]

> On 31 Mar 2016, at 21:44, Tony Parker  wrote:
> 
> Hi Zach, Daniel,
> 
>> On Mar 31, 2016, at 11:03 AM, Zach Waldowski via swift-corelibs-dev 
>>  wrote:
>> 
>> The semantics of the methods are fairly nuanced in ObjC.
>> 
>> You can have a resource value that fails to be fetched, or one that
>> succeeded to fetch but had no value. A Swift version would model this as
>> `throws -> AnyObject?`.
>> 
>> For the dictionary version, you may ask for a resource value, it
>> succeeds, but isn't included in the dictionary because it was `nil`.
>> This version is modeled "fine" in Swift, but like you mentioned it also
>> isn't available.
>> 
>> Sorry for not being clear — the point was that it is desired for
>> corelibs-Foundation to have the same API as Darwin-Foundation, as has
>> been mentioned on this mailing list. Anything outside that has to be
>> approved (internally to Apple, I think?), and this just hasn't been
>> worked through yet.
>> 
>> Unrelated, it also appears that the underlying versions
>> (CFURLCopyResourcePropertyForKey and CFURLCopyResourcePropertiesForKeys)
>> aren't included in corelibs-CoreFoundation. I have to imagine those are
>> pretty platform-specific, but I can't comment on their conspicuous
>> disappearance because I have no more knowledge than you do. ;)
>> 
>> Zach
>> 
> 
> Yes, the reason we left these out is that they are very platform specific.
> 
> I could potentially see some kind of solution here where a dramatically 
> reduced set of keys are available on all platforms. Things like file name and 
> file size are probably able to be implemented in a cross-platform way. For 
> now, I just left the whole thing out because sorting through what would be 
> portable or not would be a pretty large task.
> 
> - Tony


Thanks for the info. I agree that a Swift overlay for Darwin Foundation would 
be great, and adding those versions to SwiftFoundation would be most excellent. 
I remember that when these APIs were added to OS X once of the reasons was that 
it provides a unified API for all these kinds of things, and it allows the 
library to cache these, dramatically reducing the calls to stat(2) and friends.

I think the fact that these are so platform specific is a good reason to 
include them: Foundation’s goal is to “Provide a level of OS independence, to 
enhance portability”.

/Daniel

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

[swift-corelibs-dev] dispatch_data_t and NSData

[Daniel Eggert via swift-corelibs-dev]

Is there interest in bridging between dispatch_data_t and NSData similar to 
what's available with Darwin Foundation. Being able to avoid buffer copies 
seems like a big win. And with libdispatch (almost) being available on Linux, 
would it make sense to back (immutable) NSData with libdispatch in stead if 
CFData? Just curious what the reasoning is...

/Daniel

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

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

[Daniel Eggert via swift-corelibs-dev]

I don't think it compiles, but I haven't tried, yet. I've been trying to keep 
it up-to-date with master. 

/Daniel

> On Apr 18, 2016, at 13:15, Tony Parker <anthony.par...@apple.com> wrote:
> 
> I think that’s a fair approach - but does this even compile on Linux without 
> dispatch in place? I get “no such module ‘Dispatch’” errors when compiling.
> 
> - Tony
> 
>> On Apr 18, 2016, at 11:24 AM, Pushkar N Kulkarni <pushkar...@in.ibm.com> 
>> wrote:
>> 
>> Thanks for your great work on NSURLSession and friends, Daniel!
>> 
>> I was wondering if we are only waiting for dispatch to be available on Linux 
>> here. In that case, could we have the failing tests (if any) excluded (only 
>> on Linux perhaps) and have this merged please? Some of us at IBM would like 
>> to work with the current implementation and contribute on top of it.
>> 
>> Thanks!
>> 
>> Pushkar N Kulkarni,
>> IBM Runtimes
>> 
>> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
>> 
>> 
>> 
>> -----swift-corelibs-dev-boun...@swift.org wrote: -
>> To: Swift corelibs dev <swift-corelibs-dev@swift.org>
>> From: Daniel Eggert via swift-corelibs-dev 
>> Sent by: swift-corelibs-dev-boun...@swift.org
>> Date: 04/05/2016 12:14AM
>> Subject: Re: [swift-corelibs-dev] NSURLSession & libcurl
>> 
>> I won't be able to put too many more hours into this after next week.
>> 
>> https://github.com/apple/swift-corelibs-foundation/pull/299
>> 
>> Feedback is very welcome.
>> 
>> The tests show what's working, and there are "TODO:" markers throughout the 
>> code where applicable.
>> 
>> /Daniel
>> 
>> ___
>> 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] NSTask and NSFileHandle implementation

[Daniel Eggert via swift-corelibs-dev]

Wouldn't it still be a huge win to use dispatch for reading from / writing to a 
file descriptor?

/Daniel


> On Apr 18, 2016, at 01:52, Chris Bailey via swift-corelibs-dev 
>  wrote:
> 
> Hi Dan: 
> 
> The Dispatch sources are mostly complete - unfortunately 
> DISPATCH_SOURCE_TYPE_PROC isn't there and it unlikely to be there in a hurry. 
> It would ideally need the underlying kqueue library to have EVFILT_PROC 
> support, which it doesn't today. 
> 
> Chris
> 
> 
> 
> 
> From:Dan Stenmark via swift-corelibs-dev 
>  
> To:Alexander Alemayhu  
> Cc:Swift core libraries  
> Date:16/04/2016 22:00 
> Subject:Re: [swift-corelibs-dev] NSTask and NSFileHandle 
> implementation 
> Sent by:swift-corelibs-dev-boun...@swift.org 
> 
> 
> 
> While we’re on the subject, I’ve been out of the loop for a little while: 
> how’s the Linux-side implementation of dispatch sources looking these days?  
> In particular, I’m interested in the status of DISPATCH_SOURCE_TYPE_READ and 
> DISPATCH_SOURCE_TYPE_PROC. 
> 
> Right now, NSTask is using Good Ol’ CFRunLoops for it’s event handling, and 
> I’d really like to move that over to GCD as soon as I can. 
> 
> Dan 
> 
> 
> On Apr 16, 2016, at 1:55 PM, Dan Stenmark  
> wrote: 
> 
> Hey Alexander, 
> 
> I supplied most of the initial implementation of NSTask, but was holding off 
> on IO redirection until someone tackled NSFileHandle.  I can’t say if anyone 
> else on this list is working on this right now, but if not and if you’re 
> really interested in finishing NSFileHandle, I would (very happily!) take 
> care of the relevant implementation in NSTask. 
> 
> Dan 
> 
> On Apr 16, 2016, at 1:50 AM, Alexander Alemayhu via swift-corelibs-dev 
>  wrote: 
> 
> Hei Everyone, 
> 
> Is anyone working on the NSTask and/or NSFileHandle implementation? 
> 
> I would like to fix the hangs issue in order to revert [3aa8434][0](disable 
> NSTask tests for now since it can cause hangs., 2016-01-21), but want to 
> avoid 
> duplicating work. Fixing this should also resolve [SR-625][1]. 
> 
> Thanks. 
> 
> [0]: 
> https://github.com/apple/swift-corelibs-foundation/commit/3aa8434df50d9513a0ac1646fb52516a092fa728
>  
> [1]: https://bugs.swift.org/browse/SR-625 
> 
> -- 
> Mit freundlichen Grüßen
> 
> Alexander Alemayhu 
> ___
> 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

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

[Daniel Eggert via swift-corelibs-dev]

I think that would make a giant mess. I'm curious how far off we are for having 
lob libdispatch on Linux. I think it would be worth waiting a bit longer I n 
stead of making the code illegible. Just my 2￠.

/Daniel


> On Apr 20, 2016, at 04:23, Pushkar N Kulkarni <pushkar...@in.ibm.com> wrote:
> 
> Hi Tony, Daniel, 
> 
> Thanks for your responses. 
> 
> Would it be acceptable if, for now, we check for the availability of Dispatch 
> and conditionally compile calls to it into the current implementation of 
> NSURLSession* (something like the  _HAS_DISPATCH__ macro used in 
> CoreFoundation)? This would make NSURLSession and related classes functional 
> with a custom toolchain that has Dispatch, on Linux. It'd also make them 
> functional on OS X.
> 
> I realise this may need some code restructuring.
> 
> Pushkar N Kulkarni,
> IBM Runtimes
> 
> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
> 
> 
> 
> -Daniel Eggert <danielegg...@me.com> wrote: -
> To: Tony Parker <anthony.par...@apple.com>
> From: Daniel Eggert <danielegg...@me.com>
> Date: 04/19/2016 08:21PM
> Cc: Pushkar N Kulkarni/India/IBM@IBMIN, Swift corelibs dev 
> <swift-corelibs-dev@swift.org>
> Subject: Re: [swift-corelibs-dev] NSURLSession & libcurl
> 
> I don't think it compiles, but I haven't tried, yet. I've been trying to keep 
> it up-to-date with master. 
> 
> /Daniel
> 
>> On Apr 18, 2016, at 13:15, Tony Parker <anthony.par...@apple.com> wrote:
>> 
>> I think that’s a fair approach - but does this even compile on Linux without 
>> dispatch in place? I get “no such module ‘Dispatch’” errors when compiling.
>> 
>> - Tony
>> 
>>> On Apr 18, 2016, at 11:24 AM, Pushkar N Kulkarni <pushkar...@in.ibm.com> 
>>> wrote:
>>> 
>>> Thanks for your great work on NSURLSession and friends, Daniel!
>>> 
>>> I was wondering if we are only waiting for dispatch to be available on 
>>> Linux here. In that case, could we have the failing tests (if any) excluded 
>>> (only on Linux perhaps) and have this merged please? Some of us at IBM 
>>> would like to work with the current implementation and contribute on top of 
>>> it.
>>> 
>>> Thanks!
>>> 
>>> Pushkar N Kulkarni,
>>> IBM Runtimes
>>> 
>>> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
>>> 
>>> 
>>> 
>>> -swift-corelibs-dev-boun...@swift.org wrote: -
>>> To: Swift corelibs dev <swift-corelibs-dev@swift.org>
>>> From: Daniel Eggert via swift-corelibs-dev 
>>> Sent by: swift-corelibs-dev-boun...@swift.org
>>> Date: 04/05/2016 12:14AM
>>> Subject: Re: [swift-corelibs-dev] NSURLSession & libcurl
>>> 
>>> I won't be able to put too many more hours into this after next week.
>>> 
>>> https://github.com/apple/swift-corelibs-foundation/pull/299
>>> 
>>> Feedback is very welcome.
>>> 
>>> The tests show what's working, and there are "TODO:" markers throughout the 
>>> code where applicable.
>>> 
>>> /Daniel
>>> 
>>> ___
>>> 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