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 en
Is it ok to use
@testable import SwiftFoundation
in tests? I'd like to test some internal code.
TestNSXMLDocument.swift uses this, but not on Linux. What's the reason for this?
/Daniel
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.or
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 p
On 15 Mar 2016, at 16:16, Daniel Eggert via swift-corelibs-dev
wrote:
>
> The allHeaderFields in
>
> public class NSHTTPURLResponse : NSURLResponse {
>[...]
>public let allHeaderFields: [NSObject : AnyObject]
> }
>
> should have been [String : String]
&
I’ve made good progress on this. I’ll try to get something that’s merge-able
within the next week. It won’t be 100% complete by any means, but should
hopefully (A) cover the most common use cases, and (B) be a solid basis for the
remaining functionality.
/Daniel
> On 15 Mar 2016, at 15:12, Ph
There're some initializers (namely in NSURLSession) that have a comment:
public /*not inherited*/ init(...
What is this “not inherited” comment trying to convey, and how would one go
about implementing this in Swift?
/Daniel
___
swift-corelibs-dev ma
I created https://github.com/apple/swift-corelibs-foundation/pull/290
to add 4 attributes that were missing compared to Darwin Foundation.
I also re-worked how attributes are used / stored for the immutable / mutable
version.
I didn't add any documentation to the 4 attributes, because I didn't k
What code will be used to make then _localized_?
/Daniel
> On 17 Mar 2016, at 19:15, Ian Partridge via swift-corelibs-dev
> wrote:
>
> Hi Philippe, thanks for your quick reply.
>
> The HTTP status code reason phrases are designed to be human readable.
> They are standard phrases that are easi
> 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
> On 23 Mar 2016, at 14:44, Philippe Hausler wrote:
>
> The swift-corelibs-foundation version of CF is a static library that is being
> built into the Foundation product dynamic library so the linkage for libxml2
> and anything else should be on that.
>
> The layout of how linking works for t
I've created this pull request in an attempt to get more feedback on my
approach. I hope this is in line with the contribution guidelines.
https://github.com/apple/swift-corelibs-foundation/pull/299
This is will work-in-progress and marked as such.
/Daniel
_
>
> 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 behaviora
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
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 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
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
_
What's the reason for the "resource value" API on NSURL not being present in
SwiftFoundation?
/Daniel
func getResourceValue(_ value: AutoreleasingUnsafeMutablePointer,
forKey key: String) throws
___
swift-corelibs-dev mailing list
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
C
> interop.
>
> Zach
>
> On Thu, Mar 31, 2016, at 07:17 AM, Daniel Eggert via swift-corelibs-dev
> wrote:
>> What's the reason for the "resource value" API on NSURL not being present
>> in SwiftFoundation?
>>
>> /Daniel
&
> 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
>>
This code crashes for me with SwiftFoundation, but not with Darwin Foundation:
/// Turn `NSData` into `dispatch_data_t`
internal func createDispatchData(data: NSData) -> dispatch_data_t {
let c = data.copy() as! NSData
let info = Unmanaged.passRetained(c)
let destructor = {
inf
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
__
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.
Does https://ci.swift.org/ have daily Toolchai
> On 08 Apr 2016, at 01:44, Daniel Dunbar wrote:
>
>>
>> On Apr 7, 2016, at 10:15 AM, Daniel Eggert via swift-corelibs-dev
>> wrote:
>>
>> With this being merged
>>
>> https://github.com/apple/swift-corelibs-foundation/pull/305
>>
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
I've rebased against master and squashed these PRs:
https://github.com/apple/swift-corelibs-foundation/pull/287
https://github.com/apple/swift-corelibs-foundation/pull/306
/Daniel
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https:/
gt;
>> 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
>> Fr
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 the
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 prerequisi
29 matches
Mail list logo