Re: [swift-corelibs-dev] Git history

[Tony Parker via swift-corelibs-dev]

Hi Tom,

I’ve actually been thinking about this a lot over the past few days, but 
haven’t come to any real conclusion yet.

The way I’ve traditionally worked on Foundation is that each commit has more 
content, and each commit is (almost) always associated with a bug. This is 
basically the process I had in mind when I wrote the CONTRIBUTING document.

However, we’re at such an early stage in this project now that I don’t want to 
add a lot of overhead to PRs that contain basic functionality. I’m also 
grateful for all of the work that everyone is putting in, and don’t want to put 
off potential contributors with an overly pedantic policy. We’re trying as hard 
as we can to keep up with everything, but some PRs are sitting for some time 
before we can fully review them, which means they are inevitably out of date 
and have to be rebased.

I think that as more projects start to depend upon the library we will have to 
be much more cautious about how we accept changes, how they are tested, and how 
they are structured (e.g., for easier reverting).

I welcome additional thoughts on this topic.

Thanks,
- Tony

> On Dec 17, 2015, at 1:25 AM, Tom Jowett via swift-corelibs-dev 
>  wrote:
> 
> Hi everyone,
> 
> I'm wondering if there's a way I can help to keep the commit structure of the 
> repo a bit tidier?  I can see the guideline being provided on CONTRIBUTING.md 
> however the current commit history could be a little easier to follow for the 
> average viewer (eb06d19 and b4f6e2b were duplicate commits, e.g) and it seems 
> the rebase before PR element of that guideline could be better followed.
> 
> Perhaps a link in CONTRIBUTING.md to a walkthrough on how to squash and 
> rebase commits (including adding tests appropriately for bisect) could be 
> helpful?  Happy to put one together in the context of this project if you 
> think so.  Also interested in any other suggestions you might have for how 
> this could be remedied.
> 
> Cheers,
> Tom
> 
> 
>  ___
> 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] Starter bug: Run Foundation tests against OS X Foundation

[Tony Parker via swift-corelibs-dev]

Hi everyone,

I filed a bug here that would be a great way for someone to jump into 
contributing to swift-corelibs-foundation:

SR-276 

The basic idea is that we could really use a way to run our Swift test suite 
against the system (OS X) Foundation. This will help everyone to verify that 
the behavior of the library we are building is the same as OS X. If it’s not, 
then we know we have a bug to resolve in some way.

Let me know if you have any questions,
- Tony

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

[swift-corelibs-dev] Upcoming holiday schedule

[Tony Parker via swift-corelibs-dev]

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

Re: [swift-corelibs-dev] libdispatch epoll port

[Tony Parker via swift-corelibs-dev]

Hi Dzianis,

> On Dec 17, 2015, at 12:36 PM, Dzianis Fedarenka via swift-corelibs-dev 
>  wrote:
> 
>>> On Dec 10, 2015, at 12:42 AM, Joakim Hassila via swift-corelibs-dev 
>>>  wrote: 
>>> 
>>> Hi, 
>>> 
 On 8 dec. 2015, at 16:56, Pierre Habouzit  wrote: 
 
 FWIW, this is my personal, let’s call it enlightened, opinion, based on my 
 knowledge of dispatch and my past extensive system programming experience 
 with Linux before I joined Apple. 
 
 I think that long term, the best way to maintain a Linux libdispatch port 
 is to go away from the libkqueue that tries to emulate kqueue fully, where 
 dispatch only needs a small subset of the surface of kqueue. Given how 
 source.c is written today, this is not a very small undertaking, but 
 eventually dispatch source map to epoll_ctl(EPOLLONESHOT) very very well. 
>>> 
>>> That makes sense, could simplify the implementation (and keep thing 
>>> cleaner). Then the follow up question is of course how to split/manage 
>>> source.c (as Daniel pointed out there is the merging issue). 
>> we can decide when/if someone tries to tackle it. I humbly recognize that I 
>> have no great idea of how to do so.
> 
> I have some experience in event multiplexing programming for linux. So it 
> looks like interesting project for me. There is some conceptual questions 
> which I think should be discussed:
> 
> 1) Obviously, kqueue and epoll have a little different semantics. For 
> example: in linux timers, signals and socket can be presented as file 
> descriptor and processed uniformly. Is there any chance that community will 
> agree to develop separate API for linux?

For what it’s worth, we went ahead and based CFRunLoop.c on Linux on top of 
epoll: 

https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/RunLoop.subproj/CFRunLoop.c
 


https://github.com/apple/swift-corelibs-foundation/commit/d594de1bdd7f10a558e30b92809420303ded0a6a#diff-9739b4f43fc59b19e677f9e3f835d159
 


I think it makes total sense for dispatch’s SPI for CF to simply return an 
eventfd.

- Tony

> 2) Does anyone have long term vision about how to inject platform specific 
> code into current implementation of dispatch_source? As far as I’ve read the 
> source it’s heavily bound with kqueue semantics and «#ifdef»-way seems to be 
> completely messy..(
> ___
> 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] NSDate Comparable & Equatable

[Tony Parker via swift-corelibs-dev]

Hi James,

Here’s the start of the thread in the archives:

https://lists.swift.org/pipermail/swift-corelibs-dev/Week-of-Mon-20151130/77.html

- Tony

> On Dec 11, 2015, at 11:46 AM, James Lee via swift-corelibs-dev 
>  wrote:
> 
> Hi all,
> 
> I raised PR 119 yesterday with a comment from Tony Parker about a discussion 
> currently going on about this.
> 
> I seem to have missed out on this and currently not sure of the status on 
> this.
> 
> Cheers
> ___
> 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] NSDate, NSDateFormatter

[Tony Parker via swift-corelibs-dev]

Hi Joe,

Sure, bug reports are appreciated.

If you have the ability to check out the whole stack and try ToT, that would be 
great too. We are moving extremely rapidly right now on implementing missing 
pieces of Foundation.

- Tony

> On Dec 11, 2015, at 10:53 AM, Joseph Bell  wrote:
> 
> Thanks Tony, with LD_LIBRARY_PATH set to include usr/lib/swift/linux I can 
> get the REPL to reproduce what I see with the compiler, and that's a blank 
> line printed out:
> 
> ➜  dates  
> LD_LIBRARY_PATH=/opt/apple/swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04/usr/lib/swift/linux:$LD_LIBRARY_PATH
>  swift printdate.swift 
> 
> ➜  dates  
> 
> Which leads me to the obvious question, either I've forgotten how to use 
> NSDateFormatter, or the implementation in the December 1 drop is silently not 
> supporting setting the dateFormat property, which appears to be the case, as 
> setting dateStyle and timeStyle do appear to work.
> 
> import Foundation
> 
> let dateFormatter = NSDateFormatter()
> dateFormatter.dateFormat = "dd-MM-"
> var dateStr = dateFormatter.stringFromDate(NSDate())
> 
> print(dateStr)
> 
> dateFormatter.dateStyle = .MediumStyle
> dateFormatter.timeStyle = .MediumStyle
> dateStr = dateFormatter.stringFromDate(NSDate())
> print(dateStr)
> 
> results in:
> 
> ➜  dates  
> LD_LIBRARY_PATH=/opt/apple/swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04/usr/lib/swift/linux:$LD_LIBRARY_PATH
>  swift printdate.swift
> <-- this is a blank line emitted by the first print(), which it should not be 
> -->
> Dec 11, 2015, 6:52:33 PM
> 
> Thanks for any insight and if I need to file a bug report I am happy to help,
> Joe
> 
> 
> 
> 
> On Fri, Dec 11, 2015 at 10:59 AM, Tony Parker  > wrote:
> Hi Joe,
> 
> Try this as a workaround: Set the LD_LIBRARY_PATH environment variable to 
> $INSTALLED_LOCATION_OF_SWIFT/usr/lib/swift/linux
> 
> This should only affect the REPL and not compiled code.
> 
> I think this is supposed to be fixed in the top of tree Swift but not in the 
> Dec 1 binary drop.
> 
> - Tony
> 
>> On Dec 11, 2015, at 5:54 AM, Joseph Bell via swift-corelibs-dev 
>> > wrote:
>> 
>> All,
>> 
>> Howdy.  I am using swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04 that was 
>> released on December 1.  The following code:
>> 
>> import Foundation
>> 
>> let dateFormatter = NSDateFormatter()
>> dateFormatter.dateFormat = "dd-MM-"
>> let dateStr = dateFormatter.stringFromDate(NSDate())
>> 
>> print(dateStr)
>> 
>> results in 
>> 
>> LLVM ERROR: Program used external function '_TFC10Foundation6NSDateCfT_S0_' 
>> which could not be resolved!
>> 
>> when executed with the swift driver, and then when compiled with swiftc the 
>> print statement just gives a blank newline.
>> 
>> I don't know if this is a known issue (I haven't found any reference on the 
>> status page or elsewhere indicating this was unimplemented), or I have an 
>> environmental problem.
>> 
>> Thoughts?
>> 
>> Joe
>> 
>>  ___
>> 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] Inconsistencies between Foundation APIs

[Tony Parker via swift-corelibs-dev]

Hi Ian,

Any place where the API differs should be marked with a comment like this:

/// - Experiment: This is a draft API currently under consideration for 
official import into Foundation

If not, then we found some place that we either need to change or propose a 
change for. We can track those with bugs on bugs.swift.org 
. Most of the ‘Experiment’ APIs are something we have 
no alternative but to change, though.

Thanks for your work on this,
- Tony

> On Dec 21, 2015, at 5:39 PM, Ian Ynda-Hummel via swift-corelibs-dev 
>  wrote:
> 
> I've been working on SR-276  and I'm 
> finding a fair amount of inconsistencies between corelib Foundation and OS X 
> Foundation. It seems to be most common with optionality of return values. 
> e.g., in NSURL
> 
> corelib:
> public func URLByAppendingPathComponent(pathComponent: String) -> NSURL?
> 
> OS X:
> public func URLByAppendingPathComponent(pathComponent: String) -> NSURL
> 
> That particular case seems to be a difference in the treatment of the return 
> value from CFURL
> 
>public func CFURLCreateCopyAppendingPathComponent(allocator: CFAllocator!, 
> _ url: CFURL!, _ pathComponent: CFString!, _ isDirectory: Bool) -> CFURL!
> 
> Which briefly looking appears to be the same between corelib and OS X.
> 
> I'm not sure what the best way forward on these things is, though, as the 
> corelib versions have seemed consistently improved, but presumably we still 
> want maintain compatibility. Anyone have ideas?
>  ___
> 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] CChar vs Int8

[Tony Parker via swift-corelibs-dev]

Hi Luke,

> On Jan 2, 2016, at 8:28 PM, Luke Howard via swift-corelibs-dev 
>  wrote:
> 
> Many Foundation APIs use Int8 instead of CChar when representing C strings, 
> e.g.:
> var UTF8String: UnsafePointer 
>   
> >
>  { get }
> I don’t know if/when Swift will be ported to a platform where the character 
> type is unsigned but perhaps it would be good to update these to take CChar 
> instead?
> 
> — Luke
> 

I’m not really sure why it’s imported to Swift as an unsafe pointer to Int8 
anyway. The Objective-C code uses char:

@property (nullable, readonly) __strong const char *UTF8String 
NS_RETURNS_INNER_POINTER;// Convenience to return null-terminated UTF8 
representation

- (nullable instancetype)initWithUTF8String:(const char *)nullTerminatedCString;

- Tony

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

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

[Tony Parker via swift-corelibs-dev]

Hi Keith,

Also - the Xcode project is provided for development ease-of-use only. This 
version of XCTest is only for non-Darwin platforms, and that builds with the 
simple shell script that is in the root directory (build_script.py).

- Tony

> On Jan 4, 2016, at 9:19 AM, Daniel Dunbar via swift-corelibs-dev 
>  wrote:
> 
> I think this makes sense (and commented in your PR). For now we will still 
> need the manual build process because we need XCTest to build first in CI, so 
> that we can use it in building/testing the package manager itself, but it 
> certainly makes sense to shoot for it to just be yet another package.
> 
> - Daniel
> 
>> On Dec 31, 2015, at 11:42 AM, Keith Smiley via swift-corelibs-dev 
>>  wrote:
>> 
>> Hey all,
>> 
>> I was working on integrating a project with corelibs-xctest and I noticed 
>> that
>> it doesn't currently support building with swiftpm and instead provides
>> `.xcodeproj` which generates a `.framework`. Is there any future plan to also
>> include a `Package.swift` so that user's could build it either way? Because 
>> of
>> how simple corelibs-xctest is this is just a matter of including a barebones
>> `Package.swift` and moving the source files.
>> 
>> 
>> Thanks!
>> 
>> --
>> Keith Smiley
>> 
>> ___
>> 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] #if __CORELIBS_FOUNDATION__

[Tony Parker via swift-corelibs-dev]

Hi Drew,

> On Jan 5, 2016, at 12:08 AM, Drew Crawford  wrote:
> 
> 
>> On Jan 4, 2016, at 3:09 PM, Tony Parker > > wrote:
>> 
>> In this particular case, how would you use the #if? Any should be source 
>> compatible with AnyObject, since Any is a superset of AnyObject, right?
> 
> Well I don't know what you mean by "compatible" but the thing about strongly 
> typed languages is we can't do
> 
> let a: Any
> 
> foo(a: AnyObject) { /* */ }
> 
> foo(a)
> 
> because that is "type error".  We can of course cast, but if in Darwin a.self 
> is already AnyObject, casting again to AnyObject produces a warning, and I 
> try to not have any warnings in my code.
> 
> This is kind of a side quest–there are a lot of ways to work around these 
> problems–but the obviously straightforward one was to use #if to 
> conditionally cast, and that wasn't available.
> 
> More broadly I find myself using the #if that I've created very often–my 
> workflow seems to be to create an extension on an NSClass in-file that adds 
> missing functionality and then PR it to corelibs-foundation afterwards–and 
> conditional compilation really helps with that workflow.

My main objection is that I don’t want us to require clients to #if at all, in 
the long term. Putting it in now means that it will be easier to say “just #if” 
instead of fixing the underlying source incompatibility problem.

I think that if we get to a time nearer to the finish line of Swift 3 and we 
still have many source incompatible changes between the Core Libs Foundation 
and a corresponding Darwin Foundation then we should introduce something like 
the #if.

- Tony

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

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

[Tony Parker via swift-corelibs-dev]

Hi Brian!


> On Jun 14, 2016, at 10:43 AM, Brian Gesiak <modoca...@gmail.com> wrote:
> 
> Excellent work! I've been enjoying watching all the WWDC livestreams. :)

Thanks! We have a few more sessions coming up that are pretty neat too. 

> 
> 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?

Yup, exactly. Some of the name changes have landed in swift-corelibs-foundation 
already, and there have been corresponding PRs to fix our clients. This will be 
more of the same types of fixes.

- Tony

> 
> 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] NSStream implementation

[Tony Parker via swift-corelibs-dev]

Hi Mamatha,

This seems like a reasonable starting point. Thanks for taking this on!

- Tony

> On Jun 23, 2016, at 1:14 AM, Mamatha Busi via swift-corelibs-dev 
>  wrote:
> 
> Hi 
> 
> Looking into the NSStream class in Foundation, the NSInputStream and 
> NSOutputStream subclasses have their APIs unimplemented. I would like to have 
> a go at implementing them. Found the Corefoundation implementation of streams 
> in CFStream. Can I use CFStream and build upon it to get NSStream working?
>  
> Regards
> Mamatha
> 
> ___
> 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] KVC dependent classes

[Tony Parker via swift-corelibs-dev]

Hi David,

It’s likely that we’ll have to come up with some alternative API in these 
cases. For example, in NSProgress I could imagine a callback for progress 
updates instead of observing the properties. It’s not ideal but I don’t think 
we want to undertake a reinvention of KVO when we do not have the Objective-C 
runtime present (so much of it relies on that dynamic behavior).

- Tony

> On Mar 14, 2016, at 4:14 PM, David Hart via swift-corelibs-dev 
>  wrote:
> 
> I was looking through Foundation for stuff to do and saw NSProgress, 
> NSExpression and NSSortDescriptor. They seem to be most reliant on KVC, and 
> as KVC is not available without the Objective-C runtime, I’m not sure what 
> those classes are doing here. Are those classes doomed to be dropped? Or is 
> there another way to implement them?
> 
> David.
> ___
> 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] Cannot call CFStreamCreatePairWithSocket on Linux

[Tony Parker via swift-corelibs-dev]

Hi Pushkar,

Yes, this is used by “getStreamsToHostWithName”. I think we’ll have to come up 
with a replacement implementation here, either by starting with the old 
CFNetwork open source code or writing our own.

- Tony

> On Mar 15, 2016, at 8:00 AM, Pushkar N Kulkarni via swift-corelibs-dev 
>  wrote:
> 
> Just to add to that:
> 
> I am wondering if this would hamper the implementation of NSStream, 
> NSInputStream and NSOutputStream for Linux.
> 
> Pushkar N Kulkarni,
> IBM Runtimes
> 
> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
> 
> 
> 
> -Pushkar N Kulkarni/India/IBM wrote: -
> To: swift-corelibs-dev@swift.org 
> From: Pushkar N Kulkarni/India/IBM
> Date: 03/15/2016 08:24PM
> Subject: Cannot call CFStreamCreatePairWithSocket on Linux
> 
> 
> Hello all, 
> 
>  While attempting a simple Swift client-server program on Linux using 
> CFSocket, I tried to create CFReadStream and CFWriteStream instances using 
> CFStreamCreatePairWithSocket(_:_:_:_). The program compiles and links but it 
> crashes with this:
> 
> 2016-03-15 10:30:17.791 Client[21389:5a501740] CoreFoundation: failed to 
> dynamically link symbol _CFSocketStreamCreatePair
> 
> 2016-03-15 10:30:17.791 Client[21389:5a501740] CoreFoundation: failed to 
> dynamically link symbol _CFErrorCreateWithStreamError
> 
> 2016-03-15 10:30:17.791 Client[21389:5a501740] CoreFoundation: failed to 
> dynamically link symbol _CFStreamErrorFromCFError
> 
> 
> 
> 
> 
> I see that these symbols are dynamically linked from CFNetwork which, I 
> guess, doesn't exist on Linux (so there is no lookup for these symbols on 
> Linux). 
> 
> Does this qualify to be a CFStream limitation on Linux?
> 
> Thanks in advance for your time!
> 
> Pushkar N Kulkarni,
> IBM Runtimes
> 
> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
> 
> 
> ___
> 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] Internal Tests

[Tony Parker via swift-corelibs-dev]

Using @testable makes sense to me. Let's try it out. 

- Tony

> On Mar 15, 2016, at 7:54 AM, Robert Stephen Thompson via swift-corelibs-dev 
>  wrote:
> 
> If it doesn’t use it on Linux, it’s because I was mostly running tests in 
> Xcode heh, and didn’t end up needing it in the end. On Linux, of course, I 
> think you’d want @testable import Foundation. I’m not an Apple guy, though, I 
> just happen to be the guy who wrote TestNSXMLDocument.swift! So if there is 
> actually a reason not to use it, I’m not aware of it, but don’t necessarily 
> take my word for it!
> 
> Thanks,
> Robert Thompson
> Software Engineer
> WillowTree, Inc.®
> willowtreeapps.com
> 
>> On Mar 15, 2016, at 8:02 AM, Daniel Eggert via swift-corelibs-dev 
>>  wrote:
>> 
>> 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.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

[Tony Parker via swift-corelibs-dev]

Awesome, thanks for taking this on!

- Tony

> On Mar 17, 2016, at 12:33 PM, Daniel Eggert via swift-corelibs-dev 
>  wrote:
> 
> 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, Philippe Hausler  wrote:
>> 
>> That seems pretty reasonable to me, I guess the only thing to watch out for 
>> is private vs internal.
>> 
>> Sent from my iPhone
>> 
>>> On Mar 15, 2016, at 2:44 AM, Daniel Eggert  wrote:
>>> 
>>> 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

___
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

[Tony Parker via swift-corelibs-dev]

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

> On Apr 8, 2016, at 3:12 AM, Daniel Eggert via swift-corelibs-dev 
>  wrote:
> 
> 
>>> 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
>>> 
>>> 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
___
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

[Tony Parker via swift-corelibs-dev]

Hi Alexander,

Small incremental changes is usually a good approach.

As for adding tests first, we can do that but we just need to make sure they 
don’t fail the build. What approach would you have in mind for that?

- Tony

> On Apr 22, 2016, at 1:37 AM, Alexander Alemayhu via swift-corelibs-dev 
>  wrote:
> 
> Hei Everyone,
> 
> I have been reading the documentation the last couple of days and have been
> thinking that it would make more sense to try to tackle this via several
> incremental changes vs a large pull request some time in the future. What do 
> you
> think?
> 
> If that is preferred, I would purpose as a first step to introduce [tests][1]
> for NSFileHandle.  Adding tests in general sounds like a good idea, but I am 
> not
> sure how one should test NSFileHandle.  Would it be a good starting point to 
> add
> tests for the methods used by [plutil][2]?
> 
> Thanks.
> 
> [1]: 
> https://github.com/apple/swift-corelibs-foundation/blob/master/TestFoundation/main.swift
>  
> 
> 
> [2]: 
> https://github.com/apple/swift-corelibs-foundation/blob/master/Tools/plutil/main.swift
>  
> 
> 
> -- 
> 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

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

[Tony Parker via swift-corelibs-dev]

Hi David,

> On May 22, 2016, at 8:15 AM, David Hart via swift-corelibs-dev 
>  wrote:
> 
> Hello,
> 
> The discussion we had previously on this mailing list made it quite clear 
> that:
> 
> - Objective-C Foundation is the framework that is supposed to be used on all 
> Darwin platforms,
> - swift-corelibs-foundation will be the Foundation framework for all other 
> platforms,
> - Both frameworks will evolve slowly together.

Yup.

> 
> Therefore, it makes sense that for code written against Foundation to be 
> portable, the swift-corelibs-foundation APIs and behavior needs to be 
> identical to Darwin Foundation. Hence the following questions?
> 
> - Shouldn't we be writing tests in a way so that they can be run against 
> Darwin Foundation and have the CI Server run them? For example: while working 
> on NSProgress, I write a bunch of tests against Darwin Foundation, make sure 
> they pass, then copy-paste them in the CoreLibs project, and fix the 
> implementation until they pass. This makes sure that both APIs are consistent 
> with each other. I was thinking that we ought to automate this and have the 
> CI server test them.

That would be a great step. This is part of the reason we tried to set up the 
dependencies of Foundation on XCTest the way we did, and provide the Xcode 
project file; so we could share tests. I would welcome any help we can get on 
improving our automation story here.

> 
> - How are we planning to reconcile the API differences between both 
> frameworks? For examples, one of my tests will run against CoreLibs but not 
> against Darwin because NSThread.init takes a closure as argument in CoreLibs 
> but a target+selector in Darwin. This is just one example, but I guess they 
> are other inconsistencies elsewhere. This seems to be particularly the case 
> with APIs that rely on the Objective-C runtime.
> 

These should be marked as “experimental” in the documentation comments. If not, 
we should do that.

There are some areas where we just don’t know what to do yet, because of the 
lack of the ObjC runtime and implicit bridging on Linux. In some of those 
places we’ve tried to provide a replacement API and mark it as experimental 
until we can figure out the larger story.

> In general, I'm starting to worry about the state of Foundation from a 
> portability point of view. Once Swift 3 is released, I want to start writing 
> portable swift code that relies on Foundation. And it seems like this will 
> require a huge amount of #if os() everywhere to cope with the differences.
> 
> David
> 

Our long term goal is to enable developers to do this. I acknowledge that we 
have a ways to go to get there. I’ve seen an uptick in contributions recently, 
which gives me hope that we can get closer before the release of Swift 3.

- Tony

___
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

[Tony Parker via swift-corelibs-dev]

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 
>  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

Re: [swift-corelibs-dev] Use of pthread_main_np() in NSOperation

[Tony Parker via swift-corelibs-dev]

Since CF is really an implementation detail of Foundation for corelibs, let’s 
use the CF implementation for Foundation.

- Tony

> On May 10, 2016, at 12:10 PM, Chris Bailey via swift-corelibs-dev 
>  wrote:
> 
> NSOperation.swift currently makes a call to pthread_main_np() on line 536. 
> This causes a compilation failure on Linux as there isn't an implementation 
> of pthread_main_np() in Glibc. 
> 
> There's few ways of fixing this. Before I go ahead and implement one of them, 
> I'd like to get some input on what we thing is the best approach. 
> 
> The most obvious approach would be to leverage the shim we've added to 
> CoreFoundation already. We implemented pthread_main_np() using the following 
> function in CFPlatform.c: 
> Boolean _CFIsMainThread(void) { 
> return syscall(SYS_gettid) == getpid(); 
> } 
> This is only available internally to CF, but could be exposed to Foundation, 
> either as _CFIsMainThread() or as pthread_main_np(). 
> 
> Other options would be to expose the pthread_main_np() shim that's in 
> Dispatch already (again internally), or to add it to the Glibc overlay so its 
> available globally. 
> 
> Any thoughts on the best approach? 
> 
> Chris___
> 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] Looking at corelibs-foundation

[Tony Parker via swift-corelibs-dev]

Hi David,


> On May 14, 2016, at 1:04 AM, David Hart  wrote:
> 
> Thanks for all the answers :) These questions are dear to my heart because I 
> plan on using corelibs-foundation on Darwin as soon as possible to share code 
> between our iOS apps and web services.

Yup, that is exactly the use case we want to enable. In fact...

> 
>> On 14 May 2016, at 01:39, Tony Parker  wrote:
>> 
>> Over time it’s not clear how the two will evolve, but we want them to evolve 
>> together from an API point of view at least.
> 
> I have a hard time seeing how they can evolve together seeing as we are 
> already making improvements to corelibs-foundation with the value-type and 
> NS-dropping proposals which will not reflect back to Darwin's system 
> framework.
> 
> 

Quite the contrary! Everything in those proposals applies equally to both 
Darwin and corelibs Foundation. 

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

Re: [swift-corelibs-dev] Looking at corelibs-foundation

[Tony Parker via swift-corelibs-dev]

Hi David,

> On May 11, 2016, at 4:02 PM, David Hart via swift-corelibs-dev 
>  wrote:
> 
> Hello people,
> 
> I wanted to start giving a hand on corelibs-foundation but hit two obstacles 
> I’d like to discuss:
> 
> It feels difficult to know where help is needed because the ReleaseNotes, 
> Status and Know Issues docs have not been updated in a very long time, as if 
> abandoned. Hopefully we can update hem, but perhaps a rule should be put in 
> place so that no pull request is merged without the corresponding update in 
> the documentation?
> 

Sounds good to me. I don't want to start rejecting PRs because they miss a bit 
of documentation but hopefully we can encourage it or update it after we merge.

> I tried downloading the master branch of corelibs-foundation and running the 
> tests before starting any work, but several of them crashed or failed. I am 
> on OS X, Xcode 7.3.1, up to date on the master branches of 
> corelibs-foundation and corelibs-xctest and am using the latest development 
> snapshot. For reference, the failing tests are:
> 
> TestNSString.test_initializeWithFormat3
> TestNSTask.test_pipe_stderr
> TestNSTask.test_pipe_stdout_and_stderr_same_pipe
> TestNSTask.test_passthrough_environment
> TestNSTask.test_no_environment
> TestNSTask.test_custom_environment
> TestNSUserDefaults.test_createUserDefaults
> TestNSUserDefaults.test_getRegisteredDefaultItem
> TestNSXMLDocument.test_xpath
> 
> Any ideas? Perhaps I’m doing something wrong.

Our CI system only builds and tests corelibs-foundation on Linux, so perhaps 
some regressions have snuck in on OS X only (which is interesting if true).

NSTask in particular has been under a lot of changes for Linux recently.

> 
> I was surprised to see fairly little tests for certain classes NSIndexPath, 
> NSUserDefaults, NSScanner. Is that because the code was written before the 
> Open Source project started? What are the rules on test quality and how are 
> they applied?
> 

We’d like to see tests with all new code, for sure. Some of this was written 
fairly quickly in the run up to the launch, so we probably don’t have as many 
tests as we would like there. I do have a task on my plate somewhere to figure 
out how we can integrate more of our internal unit tests into the open source 
project to help with compatibility.

> More generally, I feel worried at how much work is still left, especially 
> with the 3.0 beta branches starting. Am I imagining things or does it not 
> look very good? What can we do to rally the troops?
> 

I totally understand. The Foundation team itself has been focused on the value 
type changes, naming changes, etc that are coming as part of Swift 3. We 
haven’t had nearly as much time as I would have liked to dedicate to bringing 
this project up to parity with Swift 2.2 functionality. We are still hoping to 
accept as many contributions as possible. That is why I went through and 
accepted a bunch of PRs last week.

We have had a few contributions that felt like one-offs; when changes were 
requested we received no response and so I had to close them, which makes me 
pretty sad. I haven’t really seen any true ownership of a particular area. I 
understand it’s asking a lot for someone to come in and help us implement a 
pre-set API, but I believe in a bright future for this project if we can pick 
up the pace a bit.

- Tony

> A well meaning developer,
> David.
> ___
> 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] Looking at corelibs-foundation

[Tony Parker via swift-corelibs-dev]

I did this search to try and find some:

https://github.com/apple/swift-corelibs-foundation/pulls?utf8=✓=is%3Apr+is%3Aclosed+is%3Aunmerged
 
<https://github.com/apple/swift-corelibs-foundation/pulls?utf8=%E2%9C%93=is:pr+is:closed+is:unmerged>

Here’s one:

https://github.com/apple/swift-corelibs-foundation/pull/226 
<https://github.com/apple/swift-corelibs-foundation/pull/226>

Here was another that we had difficulty getting through review on:

https://github.com/apple/swift-corelibs-foundation/pull/248 
<https://github.com/apple/swift-corelibs-foundation/pull/248>

Here is an old one that had some hard to figure out merge conflicts:

https://github.com/apple/swift-corelibs-foundation/pull/225 
<https://github.com/apple/swift-corelibs-foundation/pull/225>

There are probably more… 

Some of the root cause has been our own failure in getting these merged 
quickly, which I’m trying to improve on.

- Tony

> On May 13, 2016, at 10:26 AM, James Lee <ja...@jelee.co.uk> wrote:
> 
> Wanted to chirp up and say I am in the same position as David, with that 
> said, if PR's have been rejected due to a lack of response, are there any 
> that have not been covered elsewhere and can be picked up?
> 
> James
> 
> Sent from my iPhone
> 
> On 13 May 2016, at 18:01, Tony Parker via swift-corelibs-dev 
> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
> 
>> Hi David,
>> 
>>> On May 11, 2016, at 4:02 PM, David Hart via swift-corelibs-dev 
>>> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
>>> 
>>> Hello people,
>>> 
>>> I wanted to start giving a hand on corelibs-foundation but hit two 
>>> obstacles I’d like to discuss:
>>> 
>>> It feels difficult to know where help is needed because the ReleaseNotes, 
>>> Status and Know Issues docs have not been updated in a very long time, as 
>>> if abandoned. Hopefully we can update hem, but perhaps a rule should be put 
>>> in place so that no pull request is merged without the corresponding update 
>>> in the documentation?
>>> 
>> 
>> Sounds good to me. I don't want to start rejecting PRs because they miss a 
>> bit of documentation but hopefully we can encourage it or update it after we 
>> merge.
>> 
>>> I tried downloading the master branch of corelibs-foundation and running 
>>> the tests before starting any work, but several of them crashed or failed. 
>>> I am on OS X, Xcode 7.3.1, up to date on the master branches of 
>>> corelibs-foundation and corelibs-xctest and am using the latest development 
>>> snapshot. For reference, the failing tests are:
>>> 
>>> TestNSString.test_initializeWithFormat3
>>> TestNSTask.test_pipe_stderr
>>> TestNSTask.test_pipe_stdout_and_stderr_same_pipe
>>> TestNSTask.test_passthrough_environment
>>> TestNSTask.test_no_environment
>>> TestNSTask.test_custom_environment
>>> TestNSUserDefaults.test_createUserDefaults
>>> TestNSUserDefaults.test_getRegisteredDefaultItem
>>> TestNSXMLDocument.test_xpath
>>> 
>>> Any ideas? Perhaps I’m doing something wrong.
>> 
>> Our CI system only builds and tests corelibs-foundation on Linux, so perhaps 
>> some regressions have snuck in on OS X only (which is interesting if true).
>> 
>> NSTask in particular has been under a lot of changes for Linux recently.
>> 
>>> 
>>> I was surprised to see fairly little tests for certain classes NSIndexPath, 
>>> NSUserDefaults, NSScanner. Is that because the code was written before the 
>>> Open Source project started? What are the rules on test quality and how are 
>>> they applied?
>>> 
>> 
>> We’d like to see tests with all new code, for sure. Some of this was written 
>> fairly quickly in the run up to the launch, so we probably don’t have as 
>> many tests as we would like there. I do have a task on my plate somewhere to 
>> figure out how we can integrate more of our internal unit tests into the 
>> open source project to help with compatibility.
>> 
>>> More generally, I feel worried at how much work is still left, especially 
>>> with the 3.0 beta branches starting. Am I imagining things or does it not 
>>> look very good? What can we do to rally the troops?
>>> 
>> 
>> I totally understand. The Foundation team itself has been focused on the 
>> value type changes, naming changes, etc that are coming as part of Swift 3. 
>> We haven’t had nearly as much time as I would have liked to dedicate to 
>> bringing this

Re: [swift-corelibs-dev] NSTask and try!

[Tony Parker via swift-corelibs-dev]

> On May 13, 2016, at 1:05 PM, James Lee  wrote:
> 
> Cheers for the clarification. I started assuming there may be a reason when 
> changing the guard let on the launch args to use the InvalidArgumentException.
> 
> Could this be a position where we may need os checking to cover the 
> regression for the moment. It seems odd that the test would pass in CI when 
> an error is thrown with a try! but fail on OSX
> 

Task is certainly one of the cases where the underlying stuff that we’re 
abstracting is significantly different, so I’m not too surprised.

We should try to get something in place so we’re not failing on OS X in the 
short term for sure.

- Tony

> Sent from my iPhone
> 
>> On 13 May 2016, at 20:48, Tony Parker  wrote:
>> 
>> Hi James,
>> 
>>> On May 13, 2016, at 12:25 PM, James Lee via swift-corelibs-dev 
>>>  wrote:
>>> 
>>> Following on from a previous discussion with Tests failing on OSX. I have 
>>> been looking into the failures. It seems that one of the earliest failures 
>>> is due to an error from a try! within NSTask.launch(). This came in with 
>>> this commit: 
>>> https://github.com/apple/swift-corelibs-foundation/commit/4c6f04cfcad3d4b06688558021595d06751fc66a
>>> 
>>> Going by the docs for Foundation - The launch function apparently "Raises 
>>> an NSInvalidArgumentException if the launch path has not been set or is 
>>> invalid or if it fails to create a process."
>>> 
>>> https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSTask_Class/#//apple_ref/occ/instm/NSTask/launch
>>> 
>>> My question is, should this be built into the Swift Foundation API? The 
>>> documentation for Swift doesn't state that the launch function throws.
>>> 
>>> With the test that is failing expecting an error, it feels more Swift-y to 
>>> have any errors throw explicitly, rather than looking at what the lower 
>>> level fills the data with.
>>> 
>>> But before jumping into doing this, I would rather put it out there and see 
>>> what the community feels about this?
>> 
>> Unfortunately the ‘throws’ syntax in Swift often causes a mixup between two 
>> different things, because it flipped the terminology from what all of our 
>> documentation and header comments use.
>> 
>> 1. Cocoa uses exceptions (@throw in ObjC) to indicate programmer errors and 
>> they are generally not intended to be recoverable.  Example: passing nil 
>> where not expected, passing an invalid argument, failing to meet a 
>> precondition of an API.
>> 2. Cocoa uses NSError ** to indicate runtime errors that are recoverable or 
>> at least presentable to user. Example: out of disk space, name of file 
>> already exists.
>> 
>> The ‘throws’ syntax in Swift is actually for case #2, not #1. In Swift, #1 
>> is fatalError or preconditionFailure. #2 is ‘throw Error’.
>> 
>> In the case of NSTask, when the documentation says “raises an 
>> NSInvalidArgumentException” (#1) then in Swift, that should translate to 
>> fatalError or preconditionFailure.
>> 
>> Hope this helps,
>> - Tony
>> 
>>> Cheers
>>> 
>>> James
>>> ___
>>> 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] Looking at corelibs-foundation

[Tony Parker via swift-corelibs-dev]

> On May 13, 2016, at 4:13 PM, David Hart  wrote:
> 
> Hi Tony,
> 
> I’m a bit confused by your answer. I am aware that some Objective-C 
> Foundation and swift-corelibs-foundation classes share a common 
> implementation through CF. My questions were really about the place of 
> swift-corelibs-foundation on OS X and iOS. Can you help me understand?
> 
> What did you mean by "Technically, swift-corelibs-foundation is only part of 
> the distribution on Linux.”?

On Darwin we will use the system framework. It is (clearly) far more mature 
than the swift-corelibs-foundation implementation.

Over time it’s not clear how the two will evolve, but we want them to evolve 
together from an API point of view at least.

> Will swift-corelibs-foundation be part of the canonical Swift distribution on 
> OS X and iOS once Swift 3 is released?

No. Only on Linux or other non-Darwin platforms.

> What is the name of the swift-corelibs-foundation module on OS X and iOS? 
> SwiftFoundation?

SwiftFoundation, and it is named this way specifically to avoid conflict with 
the system Foundation.

> What is the name of the swift-corelibs-foundation module on Linux? Foundation?

Foundation

> If those are different, isn’t there an incentive for having the same moule 
> name on all platforms?
> 
> David.
> 

The system Foundation.framework on Darwin and swift-corelibs-foundation on 
Linux are both called “Foundation”.

Hope that clears this up.

- Tony


>> On 14 May 2016, at 00:44, Tony Parker > > wrote:
>> 
>> Hi David,
>> 
>> Much of the implementation is indeed shared (via the CoreFoundation C code, 
>> and the stuff it uses like ICU and libdispatch). Some of it is a 
>> reimplementation of the same API, but in Swift.
>> 
>> If you write code targeting the Foundation API, then you simply ‘import 
>> Foundation’. The idea here is that the implementation abstracts away the 
>> platform differences including the implementation itself.
>> 
>> - Tony
>> 
>>> On May 13, 2016, at 3:34 PM, David Hart >> > wrote:
>>> 
>>> After looking into it, I guess it would be available, but under the 
>>> SwiftFoundation module. Correct? I guess that decision was made so that 
>>> Swift apps in production built on Foundation don’t break when recompiled 
>>> under Swift 3? Is it worth converging the names of the module so its the 
>>> same on all platforms? Isn’t it bad if portable code was doomed to have #if 
>>> os() for all Foundation imports? If we do rename it, do we rename it to 
>>> SwiftFoundation on Linux or do we rename it to Foundation on OS X (which 
>>> would require renaming the Objective-C Foundation to something else and 
>>> write a migration)?
>>> 
 On 14 May 2016, at 00:19, David Hart via swift-corelibs-dev 
 > wrote:
 
 
> On 13 May 2016, at 21:50, Tony Parker  > wrote:
> 
> Technically, swift-corelibs-foundation is only part of the distribution 
> on Linux. On Darwin platforms, we use a combination of the overlay 
> (stdlib/public/SDK/Foundation directory in the Swift project) and the 
> Foundation.framework that ships on the OS.
 
 I’m confused about swift-corelibs-foundation only being part of the Linux 
 distribution. Are you saying that when Swift 3.0 ships, import Foundation 
 on OS X and iOS will still import the Objective-C framework? If yes, I’m 
 very surprised, and I think many people will be. One of the goals of 
 swift-corelibs-foundation (README) says:
 
• Provide a level of OS independence, to enhance portability.
 
 How can it be portable if different platforms don’t share the same 
 underlying core libraries?
 
 David.
 
 ___
 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] Looking at corelibs-foundation

[Tony Parker via swift-corelibs-dev]

Hi David,

Much of the implementation is indeed shared (via the CoreFoundation C code, and 
the stuff it uses like ICU and libdispatch). Some of it is a reimplementation 
of the same API, but in Swift.

If you write code targeting the Foundation API, then you simply ‘import 
Foundation’. The idea here is that the implementation abstracts away the 
platform differences including the implementation itself.

- Tony

> On May 13, 2016, at 3:34 PM, David Hart  wrote:
> 
> After looking into it, I guess it would be available, but under the 
> SwiftFoundation module. Correct? I guess that decision was made so that Swift 
> apps in production built on Foundation don’t break when recompiled under 
> Swift 3? Is it worth converging the names of the module so its the same on 
> all platforms? Isn’t it bad if portable code was doomed to have #if os() for 
> all Foundation imports? If we do rename it, do we rename it to 
> SwiftFoundation on Linux or do we rename it to Foundation on OS X (which 
> would require renaming the Objective-C Foundation to something else and write 
> a migration)?
> 
>> On 14 May 2016, at 00:19, David Hart via swift-corelibs-dev 
>> > wrote:
>> 
>> 
>>> On 13 May 2016, at 21:50, Tony Parker >> > wrote:
>>> 
>>> Technically, swift-corelibs-foundation is only part of the distribution on 
>>> Linux. On Darwin platforms, we use a combination of the overlay 
>>> (stdlib/public/SDK/Foundation directory in the Swift project) and the 
>>> Foundation.framework that ships on the OS.
>> 
>> I’m confused about swift-corelibs-foundation only being part of the Linux 
>> distribution. Are you saying that when Swift 3.0 ships, import Foundation on 
>> OS X and iOS will still import the Objective-C framework? If yes, I’m very 
>> surprised, and I think many people will be. One of the goals of 
>> swift-corelibs-foundation (README) says:
>> 
>>  • Provide a level of OS independence, to enhance portability.
>> 
>> How can it be portable if different platforms don’t share the same 
>> underlying core libraries?
>> 
>> David.
>> 
>> ___
>> 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 try!

[Tony Parker via swift-corelibs-dev]

Hi James,

> On May 13, 2016, at 12:25 PM, James Lee via swift-corelibs-dev 
>  wrote:
> 
> Following on from a previous discussion with Tests failing on OSX. I have 
> been looking into the failures. It seems that one of the earliest failures is 
> due to an error from a try! within NSTask.launch(). This came in with this 
> commit: 
> https://github.com/apple/swift-corelibs-foundation/commit/4c6f04cfcad3d4b06688558021595d06751fc66a
> 
> Going by the docs for Foundation - The launch function apparently "Raises an 
> NSInvalidArgumentException if the launch path has not been set or is invalid 
> or if it fails to create a process."
> 
> https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSTask_Class/#//apple_ref/occ/instm/NSTask/launch
> 
> My question is, should this be built into the Swift Foundation API? The 
> documentation for Swift doesn't state that the launch function throws.
> 
> With the test that is failing expecting an error, it feels more Swift-y to 
> have any errors throw explicitly, rather than looking at what the lower level 
> fills the data with.
> 
> But before jumping into doing this, I would rather put it out there and see 
> what the community feels about this?
> 

Unfortunately the ‘throws’ syntax in Swift often causes a mixup between two 
different things, because it flipped the terminology from what all of our 
documentation and header comments use.

1. Cocoa uses exceptions (@throw in ObjC) to indicate programmer errors and 
they are generally not intended to be recoverable.  Example: passing nil where 
not expected, passing an invalid argument, failing to meet a precondition of an 
API.
2. Cocoa uses NSError ** to indicate runtime errors that are recoverable or at 
least presentable to user. Example: out of disk space, name of file already 
exists.

The ‘throws’ syntax in Swift is actually for case #2, not #1. In Swift, #1 is 
fatalError or preconditionFailure. #2 is ‘throw Error’.

In the case of NSTask, when the documentation says “raises an 
NSInvalidArgumentException” (#1) then in Swift, that should translate to 
fatalError or preconditionFailure.

Hope this helps,
- Tony

> Cheers
> 
> James
> ___
> 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] Looking at corelibs-foundation

[Tony Parker via swift-corelibs-dev]

> On May 13, 2016, at 10:33 AM, Rob Allen <r...@akrabat.com> wrote:
> 
> Hi all,
> 
>> On 13 May 2016, at 18:01, Tony Parker via swift-corelibs-dev 
>> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> Hi David,
>> 
>>> On May 11, 2016, at 4:02 PM, David Hart via swift-corelibs-dev 
>>> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
>>> 
>>> Hello people,
>>> 
>>> I wanted to start giving a hand on corelibs-foundation but hit two 
>>> obstacles I’d like to discuss:
> 
> This is good timing as I'm planning on seeing if I can contribute to 
> corelibs-foundation on the grounds that it may be at my ability level! 
> 
> 
>>> I tried downloading the master branch of corelibs-foundation and running 
>>> the tests before starting any work, but several of them crashed or failed. 
>>> I am on OS X, Xcode 7.3.1, up to date on the master branches of 
>>> corelibs-foundation and corelibs-xctest and am using the latest development 
>>> snapshot. For reference, the failing tests are:
>>> 
>>> TestNSString.test_initializeWithFormat3
>>> TestNSTask.test_pipe_stderr
>>> TestNSTask.test_pipe_stdout_and_stderr_same_pipe
>>> TestNSTask.test_passthrough_environment
>>> TestNSTask.test_no_environment
>>> TestNSTask.test_custom_environment
>>> TestNSUserDefaults.test_createUserDefaults
>>> TestNSUserDefaults.test_getRegisteredDefaultItem
>>> TestNSXMLDocument.test_xpath
>>> 
>>> Any ideas? Perhaps I’m doing something wrong.
>> 
>> Our CI system only builds and tests corelibs-foundation on Linux, so perhaps 
>> some regressions have snuck in on OS X only (which is interesting if true).
>> 
>> NSTask in particular has been under a lot of changes for Linux recently.
> 
> I've hit this too - I'll try and raise issues over the weekend for them if I 
> can. 
> 
> My plan is to start by writing unit tests if only get a feel for how all the 
> project fits together. Building and testing on Linux is so slow due to the 
> lack of incremental builds that starting with OS X seemed logical.  I thought 
> it was a problem at my end though when the tests failed on OS X.
>  
> Is there a reason why corelibs-foundation isn't build for OS X by the CI 
> system?
> 

Technically, swift-corelibs-foundation is only part of the distribution on 
Linux. On Darwin platforms, we use a combination of the overlay 
(stdlib/public/SDK/Foundation directory in the Swift project) and the 
Foundation.framework that ships on the OS.

However, we want to build and test it on OS X because that’s a much easier 
platform for most of us to deal with on a day-to-day basis.

I think we should consider having the CI build foundation and run its tests on 
OS X, but I’m not sure how to split out that concept from the final package 
that the CI generates. We don’t want to ship swift-corelibs-foundation on OS X 
because then we’d have two separate libraries with the same name and same API…

- Tony

> 
> Regards,
> 
> Rob...
> 

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

Re: [swift-corelibs-dev] Crypto as part of the core libraries

[Tony Parker via swift-corelibs-dev]

Hi Travis,

Someone will need to step up and lead the project. Is that you? =)

Personally, I’m hoping that the structure of the Swift Package Manager will 
really encourage people to create new frameworks, and give them the tools they 
need to distribute for use by many developers. That will be a great incubation 
area for these kinds of ideas.

- Tony

> On Apr 15, 2016, at 9:04 AM, Travis Beech  
> wrote:
> 
> Tony,
> 
> How is that achieved? Or what kicks off that community-driven process?
> 
> Travis Beech | Principal Developer | Unwired Revolution
> Optimizing Operations for Mobile and Distributed Systems
> 
> From: > on behalf 
> of Tony Parker >
> Date: Friday, April 15, 2016 at 9:02 AM
> To: Travis Beech  >
> Cc: "swift-corelibs-dev@swift.org " 
> >
> Subject: Re: [swift-corelibs-dev] Crypto as part of the core libraries
> 
> Hi Travis,
> 
> I think the best path for projects to become part of the corelibs “umbrella” 
> is to start them off as community-driven, and once they have gained enough 
> momentum we should consider folding them into the core distribution.
> 
> This provides a lot of key benefits. Most importantly, the new project will 
> have clear ownership and responsibility. We need to make sure that the right 
> people are there to represent its interests to the larger Swift effort. Also, 
> we’ll know who to talk to to deal with general issues like keeping it up to 
> date with language changes, integrating it with CI, considering API changes, 
> etc.
> 
> - Tony
> 
>> On Apr 14, 2016, at 3:53 PM, Travis Beech via swift-corelibs-dev 
>> > wrote:
>> 
>> I would like to propose that basic crypto be part of the core libraries of 
>> swift. It seems a large oversight that this isn’t a core part of the 
>> runtime. Many if not all modern languages provide the ability to perform 
>> hashing, encryption, certificates, etc. out of the box. 
>> 
>> I believe that any serious app developer should be encrypting their 
>> customer’s data client side; and with the Swift runtime today, I cannot 
>> write a pure Swift app without having to resort to bridging into the 
>> CommonCrypto C library. While this works, in my view, this is a hack used to 
>> bridge the gap of missing functionality. I also don’t think developers 
>> should be using libraries they find out on Github or other places. While the 
>> developers of those projects may have the best of intentions, I think it 
>> best that functionality of this sort come from the language runtime itself, 
>> that is part of the core libraries out of the box.
>> 
>> As Swift looks to move beyond just iOS/OS X, crypto will become an ever 
>> increasingly important aspect of the core libraries such AES and RSA 
>> encryption, HMAC SHA1/256 hashing, etc.
>> 
>> Thank you,
>> 
>> Travis Beech | Principal Developer | Unwired Revolution
>> Optimizing Operations for Mobile and Distributed Systems
>> ___
>> 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] Crypto as part of the core libraries

[Tony Parker via swift-corelibs-dev]

Hi Travis,

I think the best path for projects to become part of the corelibs “umbrella” is 
to start them off as community-driven, and once they have gained enough 
momentum we should consider folding them into the core distribution.

This provides a lot of key benefits. Most importantly, the new project will 
have clear ownership and responsibility. We need to make sure that the right 
people are there to represent its interests to the larger Swift effort. Also, 
we’ll know who to talk to to deal with general issues like keeping it up to 
date with language changes, integrating it with CI, considering API changes, 
etc.

- Tony

> On Apr 14, 2016, at 3:53 PM, Travis Beech via swift-corelibs-dev 
>  wrote:
> 
> I would like to propose that basic crypto be part of the core libraries of 
> swift. It seems a large oversight that this isn’t a core part of the runtime. 
> Many if not all modern languages provide the ability to perform hashing, 
> encryption, certificates, etc. out of the box. 
> 
> I believe that any serious app developer should be encrypting their 
> customer’s data client side; and with the Swift runtime today, I cannot write 
> a pure Swift app without having to resort to bridging into the CommonCrypto C 
> library. While this works, in my view, this is a hack used to bridge the gap 
> of missing functionality. I also don’t think developers should be using 
> libraries they find out on Github or other places. While the developers of 
> those projects may have the best of intentions, I think it best that 
> functionality of this sort come from the language runtime itself, that is 
> part of the core libraries out of the box.
> 
> As Swift looks to move beyond just iOS/OS X, crypto will become an ever 
> increasingly important aspect of the core libraries such AES and RSA 
> encryption, HMAC SHA1/256 hashing, etc.
> 
> Thank you,
> 
> Travis Beech | Principal Developer | Unwired Revolution
> Optimizing Operations for Mobile and Distributed Systems
> ___
> 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] Wrapping up Swift 3 for swift-corelibs

[Tony Parker via swift-corelibs-dev]

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 <modoca...@gmail.com> 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 
> <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 <mailto: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/0116-id-as-any.md>
> https://github.com/apple/swift-evolution/blob/master/proposals/0131-anyhashable.md
>  
> <https://github.com/apple/swift-evolution/blob/master/proposals/0131-anyhashable.md>
> 
> 
>> On Jul 29, 2016, at 11:06 AM, Gonzalo Larralde <gonzalolarra...@gmail.com 
>> <mailto:gonzalolarra...@gmail.com>> 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/310>
>> https://github.com/apple/swift-corelibs-foundation/pull/303 
>> <https://github.com/apple/swift-corelibs-foundation/pull/303>
>> https://github.com/apple/swift/pull/1994 
>> <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 <mailto: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 <mailto: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 <mailto:swift-corelibs-dev@swift.org>> wrote:
>>>> 
>>>> Tony Parker wrote on 07/28/2016 01:41:55 PM:
>>&g

Re: [swift-corelibs-dev] [SR-1608]

[Tony Parker via swift-corelibs-dev]

Hi David,

Thanks for helping!

Can you check out some of our current open PRs to make sure your work isn’t 
overlapping? We’ve had some contributions in this area recently that we still 
need to finish merging.

- Tony

> On Jul 29, 2016, at 11:28 PM, David Liu via swift-corelibs-dev 
>  wrote:
> 
> Hi all,
> 
> I am new to the mailing list, I am  interested in contributing to Swift Open 
> source.
> Recently picked up SR-1608 and have a PR out for it (i split it in 2 to keep 
> the pulls small).
> The code contribution guide lines suggested to contact the mailing list to 
> make sure work is not duplicated.
> So i want to just check with in you guys about it and any guidance is much 
> appreciated.
> 
> Cheers
> 
> 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

Re: [swift-corelibs-dev] Swiftier? implementation of Measurement and Unit in Foundation

[Tony Parker via swift-corelibs-dev]

Hi Joanna,

An important requirement of the design of measurements and units was that it 
had to work in Objective-C as well, where protocols do not have as many 
capabilities as they do in Swift. The bridging into Swift can only do so much, 
and frankly it didn’t seem to be the case that traditional inheritance was 
really much of a problem for this API in the first place.

The approach of separating out the coefficient was one that the HealthKit unit 
API took, but we did not. Some units do lend themselves well to metric 
prefixes, but others do not (angles, for example).

We did make some changes upon import to Swift. Most importantly, Measurement is 
indeed a struct in Swift while a class in Objective-C.

- Tony

> On Aug 11, 2016, at 2:49 AM, Joanna Carter via swift-corelibs-dev 
>  wrote:
> 
> Having had to implement convertible measurements and units for a project a 
> couple of years ago, I thought I would take a look at the upcoming 
> Measurements and Units implementations as found in the Github archive.
> 
> Since we are continually being told that protocol-oriented code and the 
> preferred use of structs were good things, I was surprised at the class 
> inheritance I found.
> 
> As a long-time proponent of OO design (some 29 years) I know that classes are 
> not "evil" but was interested to see if Swift 2.2 could manage to implement 
> Measurements and Units without falling into the inheritance trap where 
> unnecessary implementation has to be included throughout a class hierarchy.
> 
> I replaced the name Dimension with ConvertibleUnit as I felt a Dimension was 
> not truly a Unit; in fact, a Dimension could be better described in terms of 
> composition rather than inheritance i.e. a Dimension "has a" Unit rather than 
> a Dimension "is a" Unit.
> 
> Using a protocol for ConvertibleUnit also removes the requirement for methods 
> in a base class that were either empty or that carried out a conversion at a 
> coefficient of 1, which is essentially no conversion at all.
> 
> Therefore, if I may indulge, here is my attempt at a more protocol-orientd 
> version. The code is not complete with regards to bridging but, looking at 
> the bridging code in Github, that should not be a problem. 
> 
> public protocol UnitConverter
> {
>  func baseUnitValue(fromValue value: Double) -> Double
> 
>  func value(fromBaseUnitValue baseUnitValue: Double) -> Double
> }
> 
> // example converters
> public struct UnitConverterLinear : UnitConverter
> {
>  private let coefficient: Double
> 
>  private let constant: Double
> 
>  public init(coefficient: Double, constant: Double)
>  {
>self.coefficient = coefficient
> 
>self.constant = constant
>  }
> 
>  public init(coefficient: Double)
>  {
>self.init(coefficient: coefficient, constant: 0)
>  }
> 
>  public func baseUnitValue(fromValue value: Double) -> Double
>  {
>return value * coefficient + constant
>  }
> 
>  public func value(fromBaseUnitValue baseUnitValue: Double) -> Double
>  {
>return (baseUnitValue - constant) / coefficient
>  }
> }
> 
> 
> public struct UnitConverterReciprocal : UnitConverter
> {
>  private let reciprocal: Double
> 
>  public init(reciprocal: Double)
>  {
>self.reciprocal = reciprocal
>  }
> 
>  public func baseUnitValue(fromValue value: Double) -> Double
>  {
>return reciprocal / value
>  }
> 
>  public func value(fromBaseUnitValue baseUnitValue: Double) -> Double
>  {
>return baseUnitValue * reciprocal
>  }
> }
> 
> // base protocols
> public protocol Unit
> {
>  var symbol: String { get }
> }
> 
> 
> public protocol ConvertibleUnit : Unit
> {
>  var converter: UnitConverter { get }
> 
>  static var baseUnit : Self { get }
> }
> 
> // generic Measurement
> public struct Measurement
> {
>  var value: Double
> 
>  let unit: UnitType
> 
>  public init(value: Double, unit: UnitType)
>  {
>self.value = value
> 
>self.unit = unit
>  }
> 
>  public func canBeConverted(to unit: 
> TargetUnit) -> Bool
>  {
>return unit is UnitType
>  }
> 
>  public func converting(to unit: TargetUnit) -> 
> Measurement
>  {
>if !canBeConverted(to: unit)
>{
>  fatalError("Unit type not compatible")
>}
> 
>let baseUnitValue = self.unit.converter.baseUnitValue(fromValue: value)
> 
>let convertedValue = unit.converter.value(fromBaseUnitValue: baseUnitValue)
> 
>return Measurement(value: convertedValue, unit: unit)
>  }
> }
> 
> // example implementing ConvertibleUnit
> 
> public struct LengthUnit : ConvertibleUnit
> {
>  public let symbol: String
> 
>  public let converter: UnitConverter
> 
>  private struct Symbol
>  {
>static let kilometers = "km"
>static let meters = "m"
>// ...
>  }
> 
>  private struct Coefficient
>  {
>static let kilometers   = 1000.0
>static let meters   = 1.0
>// ...
>  }
> 
>  public static var kilometers: LengthUnit
>  {
>return LengthUnit(symbol: Symbol.kilometers, converter: 
> 

Re: [swift-corelibs-dev] Query on NSLog

[Tony Parker via swift-corelibs-dev]

Hi Sai,

Out of curiosity, why NSLog instead of Swift’s print function?

- Tony

> On Jun 27, 2016, at 4:37 AM, Sai Kanduri via swift-corelibs-dev 
>  wrote:
> 
> Hi All,
>  
> Currently NSLog  has only one internal function  NSLog()  which can be used 
> only by Foundation classes.Can this be made available as a public API ?
>  
>  
> Thanks & Regards,
>  
> Sai Hema,Java L3 Support
> 
> ___
> 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] Query on NSLog

[Tony Parker via swift-corelibs-dev]

Frankly, I think I just forgot to put a stub for it when we put out the first 
set of APIs.

- Tony

> On Jul 5, 2016, at 4:54 PM, Luke Howard <lu...@padl.com> wrote:
> 
> I added NSLog for NSKeyedArchiver so the output formatting would more closely 
> match Darwin, but I punted whether to make it public.
> 
>> On 6 Jul 2016, at 5:42 AM, Tony Parker via swift-corelibs-dev 
>> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> Hi Sai,
>> 
>> Out of curiosity, why NSLog instead of Swift’s print function?
>> 
>> - Tony
>> 
>>> On Jun 27, 2016, at 4:37 AM, Sai Kanduri via swift-corelibs-dev 
>>> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
>>> 
>>> Hi All,
>>>  
>>> Currently NSLog  has only one internal function  NSLog()  which can be used 
>>> only by Foundation classes.Can this be made available as a public API ?
>>>  
>>>  
>>> Thanks & Regards,
>>>  
>>> Sai Hema,Java L3 Support
>>> 
>>> ___
>>> swift-corelibs-dev mailing list
>>> swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>>> <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev>
>> 
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 
> --
> www.lukehoward.com <http://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

Re: [swift-corelibs-dev] [SR-1608]

[Tony Parker via swift-corelibs-dev]

Hi David,

The compiler has been changing pretty rapidly underneath us, but hopefully has 
settled down a bit now that we’re getting towards the end. I’d suggest rebasing 
against master again and trying with the latest compiler snapshots.

- Tony

> On Aug 3, 2016, at 3:29 AM, David Liu  wrote:
> 
> Hi Tony,
> 
> Thanks for the update, I looked over the PR's i think i am that recent 
> contributor .
> I do have a question about updating and rebasing. Looks like the tip of 
> master is not compiling with the 7/29 snapshot.
> Think it was compiling last right before last weekend. I tried to build the 
> TC manually and TC failed as well. Any suggestions to rebase and build/test?
> 
> Cheers
> 
> Dave
> 
> 
> On Tue, Aug 2, 2016 at 2:22 AM, Tony Parker  > wrote:
> Hi David,
> 
> Thanks for helping!
> 
> Can you check out some of our current open PRs to make sure your work isn’t 
> overlapping? We’ve had some contributions in this area recently that we still 
> need to finish merging.
> 
> - Tony
> 
> > On Jul 29, 2016, at 11:28 PM, David Liu via swift-corelibs-dev 
> > > wrote:
> >
> > Hi all,
> >
> > I am new to the mailing list, I am  interested in contributing to Swift 
> > Open source.
> > Recently picked up SR-1608 and have a PR out for it (i split it in 2 to 
> > keep the pulls small).
> > The code contribution guide lines suggested to contact the mailing list to 
> > make sure work is not duplicated.
> > So i want to just check with in you guys about it and any guidance is much 
> > appreciated.
> >
> > Cheers
> >
> > 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

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

[Tony Parker via swift-corelibs-dev]

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 <gonzalolarra...@gmail.com> 
> 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/310>
> https://github.com/apple/swift-corelibs-foundation/pull/303 
> <https://github.com/apple/swift-corelibs-foundation/pull/303>
> https://github.com/apple/swift/pull/1994 
> <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 <mailto: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 <mailto: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 <mailto: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 <mailto:swift-corelibs-dev@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>>> <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev>
>> 
>> ___
>> swift-corelibs-dev 

[swift-corelibs-dev] URLSession test fest!

[Tony Parker via swift-corelibs-dev]

Hi everyone,

As we’re wrapping up Swift 3.1, I think it’d be a great opportunity to have a 
quality focus area on one of our most important APIs: URLSession. If you’ve 
been wondering how to make a meaningful contribution, this is the perfect time.

It’d be great to greatly expand both unit test and higher level test coverage 
of URLSession. For testing that can’t really be part of a unit test and CI like 
poorly performing networks or esoteric configurations, it would also be nice to 
build a different kind of test tool. That tool would provide a lot of knobs for 
controlling a URLSession. We could make this tool part of the 
swift-corelibs-foundation project.

Is anyone interested in chipping in here? We don’t have to start big. Even 
small contributions could get us moving in the right direction.

Thanks,
- Tony



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

Re: [swift-corelibs-dev] URLSession test fest!

[Tony Parker via swift-corelibs-dev]

Hi Peter,

> On Jan 29, 2017, at 11:05 AM, Peter Tomaselli via swift-corelibs-dev 
> <swift-corelibs-dev@swift.org> wrote:
> 
> Hi all, another new person here.

Perfect, the more the merrier.

> This sounded like a lot of fun so I figured I would try and pitch in! 
> However, I’m unable to get off the ground getting the current tests running. 
> I’m sure it’s something I’m doing wrong, since I am completely new to the 
> project, but I’d love it if anyone had any suggestions to get un-stuck.
> 
> I poked around in JIRA and there are at least two other tickets that have 
> been filed describing the issue I also am having:
> 
> https://bugs.swift.org/browse/SR-3703 <https://bugs.swift.org/browse/SR-3703> 
> [I commented here with the specifics of my system, if you think that is 
> important]
> https://bugs.swift.org/browse/SR-3775 <https://bugs.swift.org/browse/SR-3775> 
> 
> Perhaps I am wrong, but it should be possible to use macOS to contribute 
> tests for URLSession as described here, right? If so, does anyone have any 
> suggestions for tackling the problem described in those two tickets? Thanks!
> 

Yup, we want building and running on macOS to be totally supported (so it’s 
easy to help contribute).

I’ll take a look and see if I can figure out what the problem is too…

- Tony

> Cheers,
> 
> Peter
> 
>> On Jan 27, 2017, at 6:31 PM, Tony Parker via swift-corelibs-dev 
>> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> Hi Paul,
>> 
>>> On Jan 27, 2017, at 12:51 AM, Paul Stringer via swift-corelibs-dev 
>>> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
>>> 
>>> Hi Tony,
>>> 
>>> First post and excited to join the party.
>> 
>> Great, welcome!
>> 
> 
> ___
> 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] URLSession test fest!

[Tony Parker via swift-corelibs-dev]

Hi Paul,

> On Jan 27, 2017, at 12:51 AM, Paul Stringer via swift-corelibs-dev 
>  wrote:
> 
> Hi Tony,
> 
> First post and excited to join the party.

Great, welcome!

> 
> I'm sure this may have been solved many times over by the community already. 
> Maybe we can collect some ideas on this. In the spirit of a small step to get 
> things moving forward I'm sharing my own approach which has proven very 
> effective for making URLSession extremely testable and it's amazingly little 
> code with zero weirdness. All credit for the technique comes from Michael 
> Feathers "Working Effectively with Legacy Code"
> 
> Here's the Gist:
> 
> https://gist.github.com/paulstringer/7f60e446c8b8b6be3647e42936b44877
> 
> And an explanation:
> 
> Leveraging the 'Subclass and Override Method' Technique I create a subclass 
> e.g. 'NSURLSessionTestable'. I then expose any hidden dependancies using 
> NSURLSession.sharedSession() in the code and make this dependancy injected to 
> create a seam. Under test we are then able to substitute uses of 
> sharedSession with an instance of NSURLSessionTestable.
> 
> NSURLSessionTestable is trivial in that we simply override 
> dataTaskWithRequest() -> NSURLSessionDataTask()
> 
> The returned instance of NSURLSessionDataTask() does nothing. Instead we 
> immediately invoke the completionHandler returning local instance variables 
> of Data & URLResponse - these are provided by the test.
> 
> With this approach you have completely removed any network calls and 
> asynchronous behaviour. This leads to extremely concise easy to setup and run 
> tests.
> 
> It's so trivial I wonder if it would even be worth adding to the corelib - 
> I'm personally a little wary of special 'knobs and dials' intended for making 
> it more testable that could be hard to find or worse become used for doing 
> odd stuff in production.
> 
> I've never seen any explicit 'Testable' classes so this would certainly mark 
> a break from tradition but I personally have found the approach to work 
> extremely well and through use of an explicitly named class it's intention 
> revealing + easily discovered.
> 
> - Paul
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

This all sounds very interesting. I think that ‘testable’ subclasses would be 
totally reasonable as part of this test tool or our testing framework.

I have had some challenges in the past trying to carefully manage the public 
API surface vs. what is required for testing. This is easier in ObjC, where 
there are a lot of interesting hacks one can do to get at internal stuff. =) If 
an outcome of this is that we can figure out how to leverage @testable for 
ourselves in swift-corelibs-foundation then that would be awesome as well.

Looking forward to seeing more ideas,

- Tony

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

Re: [swift-corelibs-dev] Asynchronous Operations

[Tony Parker via swift-corelibs-dev]

Hm, that’s probably the least bad option we have at the moment.

I don’t want to introduce “new” API, as it is unlikely we will be able to 
remove it when whatever permanent solution comes up.

- Tony

> On Jan 21, 2017, at 6:09 AM, Brent Royal-Gordon via swift-corelibs-dev 
>  wrote:
> 
>> On Jan 20, 2017, at 7:55 AM, Ian Partridge via swift-corelibs-dev 
>>  wrote:
>> 
>> Is there any way that we could support asynchronous operations in 
>> swift-corelibs-foundation, in the absence of KVO?
> 
> Could we add `willChangeValue(forKey:)` and `didChangeValue(forKey:)` methods 
> just to `Operation` which only handle an `isFinished` key? Presumably they'd 
> just look like:
> 
>   public func willChangeValue(forKey key: String) {
>   // do nothing
>   }
>   public func didChangeValue(forKey key: String) {
>   if key == "isFinished" && isFinished {
>   finish()
>   }
>   }
> 
> I believe that would make existing code just work without needing to do 
> anything special.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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] Need of inputs for NSExpression

[Tony Parker via swift-corelibs-dev]

Hi Pushkar,

> On Jan 16, 2017, at 12:26 AM, Pushkar N Kulkarni <pushkar...@in.ibm.com> 
> wrote:
> 
> Hi Tony, 
> 
> I have a question. 
> 
> >> Some of it is pretty tricky to implement without the dynamic behavior of 
> >> ObjC though.
> I guess you were referring to something like 
> "NSExpression(format:"FUNCTION(4.2, 'factorial')")" where `factorial` is a 
> function defined on an extension of NSNumber. Now, this translation of a 
> string to a function handle/pointer seems quite intimidating to me, in the 
> Swift context :-) 
> Are there any known approaches? Is there any kind of general guidance you'd 
> give here? 

Yah, that’s the problematic bit.

With Objective-C, we have a whole host of API that allows dynamic lookup of 
selectors, classes, etc. None of that exists on Linux, and I don’t think we 
have any reasonable replacement.

- Tony

> 
> Thank you!
> 
> Pushkar N Kulkarni,
> IBM Runtimes
> 
> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
> 
> 
> 
> -swift-corelibs-dev-boun...@swift.org 
> <mailto:-swift-corelibs-dev-boun...@swift.org> wrote: -
> To: Nethra Ravindran <nethraravindra...@gmail.com 
> <mailto:nethraravindra...@gmail.com>>
> From: Tony Parker via swift-corelibs-dev 
> Sent by: swift-corelibs-dev-boun...@swift.org 
> <mailto:swift-corelibs-dev-boun...@swift.org>
> Date: 01/12/2017 09:44PM
> Cc: swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
> Subject: Re: [swift-corelibs-dev] Need of inputs for NSExpression
> 
> Hi Nethra,
> 
> Thanks for your interest!
> 
> Probably the best place to get started would be to take a look at our 
> documentation about NSExpression. Some of it is pretty tricky to implement 
> without the dynamic behavior of ObjC though.
> 
> - Tony
> 
>> On Jan 12, 2017, at 4:24 AM, Nethra Ravindran via swift-corelibs-dev 
>> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> Hi All,
>> 
>> This is Nethra Ravindran and I’m a university student doing my internship. I 
>> would like to contribute to Swift Foundation. I have looked upon 
>> NSExpression and I am interested in contributing the implementation. I would 
>> be very thankful if I could get some pointers about it.
>> 
>> Thank you in advance for your help!
>> 
>> Regards,
>> Nethra Ravindran
>> 
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>> <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev>
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
> <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] [swift-build-dev] Final merge from master to swift-3.1-branch

[Tony Parker via swift-corelibs-dev]

Thanks Mishal!

For all of the contributors to swift-corelibs: if you have a change which you 
think is appropriate for inclusion into Swift 3.1, let’s follow this process:

1. Get a PR up for master to merge your change
2. Once accepted, get a PR up to cherry pick the change to the swift-3.1 
branch. We can have a discussion there about if it’s appropriate for swift 3.1, 
or we can chat about it on the mailing list first if you like.

For Swift 3.1 changes, let’s focus on:

* Regressions from Swift 3.0
* Critical work for server side Swift

New work for unimplemented API can continue on master for the next Swift 
release.

Thanks!

- Tony

> On Jan 17, 2017, at 2:33 PM, mishal_shah via swift-corelibs-dev 
>  wrote:
> 
> I just merged master into swift-3.1-branch for following projects. 
> 
> https://github.com/apple/swift 
> https://github.com/apple/swift-lldb 
> https://github.com/apple/swift-corelibs-foundation 
> 
> https://github.com/apple/swift-corelibs-libdispatch 
> 
> https://github.com/apple/swift-corelibs-xctest 
> 
> https://github.com/apple/swift-integration-tests 
> 
> https://github.com/apple/swift-xcode-playground-support 
> 
> https://github.com/apple/swift-package-manager 
> 
> https://github.com/apple/swift-llbuild 
> 
> 
> Thanks, 
> Mishal Shah
>> On Jan 13, 2017, at 6:49 AM, Nicole Jacque via swift-build-dev 
>> > wrote:
>> 
>> Hello Swift Developers-
>> 
>> As outlined in Ted’s Swift 3.1 Release Process blog post, for the past 
>> month, we’ve been periodically merging master to the swift-3.1-branch 
>> branch.  We will be doing one final merge of master to the swift-3.1-branch 
>> on January 17 at noon (Pacific). Note that we’ve pushed this back a day due 
>> to the MLK Jr. Day holiday.   Any changes landed after that time will 
>> require approval via a pull request against the swift-3.1-branch branch in 
>> order to include them in the Swift 3.1 release.  After this final merge, 
>> development on master will be targeted for Swift 4.
>> 
>> Snapshots of the swift-3.1-branch will be made available on the downloads 
>> page (https://swift.org/download/ ).  Snapshots 
>> will be made available daily, if all package generation CI tests are passing.
>> ___
>> swift-build-dev mailing list
>> swift-build-...@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-build-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] NSString.isAbsolutePath inconsistency

[Tony Parker via swift-corelibs-dev]

Hi Nethra,

If this was in master sometime before this past Tuesday, it should be included 
in the swift-3.1 branch by default (that branch received merges from master).

Did you check out the latest version of the swift-3.1 branch to verify that 
this change was missing?

- Tony

> On Jan 19, 2017, at 4:23 AM, Nethra Ravindran via swift-corelibs-dev 
>  wrote:
> 
> Hi Philippe,
> 
> A naming inconsistency  with NSString.isAbsolutePath (file - 
> NSPathUtilities.swift) was fixed in your PR named “ Import CoreFoundation 
> changes from Sierra “: 
> 
> https://github.com/apple/swift-corelibs-foundation/commit/a455cde38e06052385560d0a7c5aeb5a4991f844
>  
> 
> 
> However it appears that  this PR  hasn’t been cherry picked for 
> swift-3.1-branch. I wanted to check if you plan to cherry-pick this PR for 
> 3.1. If not I can raise a PR only for the NSString.isAbsolutePath 
> inconsistency on the 3.1 branch. 
> 
> Please let me know what you think.
> 
> Thank you.
> 
> -Nethra Ravindran
> ___
> 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] Documentation and coding style

[Tony Parker via swift-corelibs-dev]

Hi Sergej,

> On Jan 20, 2017, at 6:24 AM, Sergej Jaskiewicz via swift-corelibs-dev 
>  wrote:
> 
> Hello everyone.
> 
> I have a couple of questions about the core libraries that I think would be 
> interesting to discuss.
> 
> The first question is about documentation comments. From what I can see in 
> the repos and what the core team members say, those libraries lack them a 
> lot. Maybe some of you have already asked this question, but can’t we just 
> copy the Darwin Foundation & XCTest documentation comments? I can see it has 
> been done in some parts of Swift Foundation, so why don’t we apply it to all 
> the APIs? Of course taking into account the possible differences in behaviour 
> or implementation.

I would be happy to accept PRs that add documentation to the existing API. 
There was just too much of it for us to finish in the first sweep of importing 
API into the project.

> 
> The second question is about a coding style. It can be seen that in different 
> parts of the Foundation/XCTest the coding style quite often differs. Maybe we 
> could develop some kind of a document that would state the general rules.

This is a sure fire way to start a controversy. =)

I’m in a bit of wait-and-see on this. For example, I’m personally 100% opposed 
to hard wrapping at 80 chars - but that’s the style used in the standard 
library. Perhaps a more consistent style will evolve over time.

- Tony

> 
> Do you have any thoughts on this?
> 
> — Sergej
> ___
> 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] Implementing HTTPCookieStorage

[Tony Parker via swift-corelibs-dev]

Yup, I think that makes sense.

I started an implementation a bit ago but didn’t get very far before I got 
derailed onto some other topics. I’ll see if I can clean it up and put it 
somewhere as a starting point.

- Tony

> On Jan 20, 2017, at 2:31 AM, Pushkar N Kulkarni <pushkar...@in.ibm.com> wrote:
> 
> Hi Tony, Will, others: 
> 
> Apologies for bringing this up after a long time!
> 
> I hope we still agree on the use of the "XDG Base Directory Specification". I 
> did a quick read of the spec document. 
> 
> I am happy to file a JIRA report for this.
> 
> The scope, as I understand it is: CoreFoundation will implement the "XDG Base 
> Directory Specification" and present an API to allow Foundation to retrieve 
> the different absolute paths(related to the different env variables defined), 
> which will be used to persist the different kinds of user data.
> 
> Please do let me know if my understanding is correct. Please augment it if 
> necessary. 
> 
> Thanks!
> Pushkar N Kulkarni,
> IBM Runtimes
> 
> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
> 
> 
> 
> -swift-corelibs-dev-boun...@swift.org 
> <mailto:-swift-corelibs-dev-boun...@swift.org> wrote: -----
> To: Will Stanton <willstant...@yahoo.com <mailto:willstant...@yahoo.com>>
> From: Tony Parker via swift-corelibs-dev 
> Sent by: swift-corelibs-dev-boun...@swift.org 
> <mailto:swift-corelibs-dev-boun...@swift.org>
> Date: 11/17/2016 03:45AM
> Cc: swift-corelibs-dev <swift-corelibs-dev@swift.org 
> <mailto:swift-corelibs-dev@swift.org>>
> Subject: Re: [swift-corelibs-dev] Implementing HTTPCookieStorage
> 
> Hi Will,
> 
> > On Nov 14, 2016, at 12:56 PM, Will Stanton <willstant...@yahoo.com 
> > <mailto:willstant...@yahoo.com>> wrote:
> > 
> > Hello Tony,
> > 
> > Thanks for the reply. About XDG_DATA_HOME, the variable is undefined on my 
> > desktop-less server, and I think many processes still have their own save 
> > locations.
> > Still, I can believe its used in a lot of places 
> > (https://github.com/search?q=XDG_DATA_HOME=Code= 
> > <https://github.com/search?q=XDG_DATA_HOME=Code=>✓) and am not 
> > opposed to it!
> > 
> > Perhaps SEARCH/$EXECUTABLE_NAME/Preferences.plist would be good place and 
> > format for NSUserDefaults with SEARCH = getenv(XDG_DATA_HOME) then 
> > ~/.config?
> > 
> > 
> > What about the path for cookies+caches?
> 
> I’m just reading this spec for the first time, but it looks like it accounts 
> for that:
> 
> > • There is a single base directory relative to which user-specific 
> > non-essential (cached) data should be written. This directory is defined by 
> > the environment variable $XDG_CACHE_HOME.
> 
> Overall the spec looks reasonable and seems to be close to what we we would 
> need.
> 
> A great next step would be to file a JIRA and look for volunteers who want to 
> help implement this in SCL-Foundation.
> 
> - Tony
> 
> > 
> > Regards,
> > Will Stanton
> > 
> >> On Nov 14, 2016, at 2:37 PM, Tony Parker via swift-corelibs-dev 
> >> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
> >> 
> >> Off-list, someone pointed me here:
> >> 
> >> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
> >>  
> >> <https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html>
> >> 
> >> and here:
> >> 
> >> http://stackoverflow.com/questions/1024114/location-of-ini-config-files-in-linux-unix
> >>  
> >> <http://stackoverflow.com/questions/1024114/location-of-ini-config-files-in-linux-unix>
> >> 
> >> Noting that there seems to be a growing consensus for $HOME/.config.
> >> 
> >> Is this spec beginning to be used in the real world?
> > 
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
> <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] A URLSession crash and potential solutions

[Tony Parker via swift-corelibs-dev]

Hi Pushkar,

> On Sep 13, 2016, at 12:20 PM, Pushkar N Kulkarni  
> wrote:
> 
> Hi Tony, Philippe, other onlookers, 
> 
> Long note. Kindly bear with me. 
> 
> I've created SR-2631  to report a 
> crash in a very basic usage of URLSession. I'm providing a general synopsis 
> of the problem below and proposing two approaches to solve it.
> 
> The test case attached to the report creates a URLSession object locally 
> inside a function run(), which also creates a dataTask with a completion 
> handler, resumes the task and exits. On exiting run(), the URLSession object 
> has no references pointing to it. It is cleaned up and we crash while trying 
> to resume the task (the resume code and the subsequent callbacks are all 
> asynchronous). 
> 
> This brings us to a basic flaw in the current NSURLSession implementation. 
> Sessions and tasks are either created with delegates or callbacks, which are 
> invoked asynchronously. Both delegates and callbacks need the URLSession 
> objects they were registered with. Delegates need them until the last 
> delegate method invocation returns. Completion handlers need them just until 
> before they are invoked. The current implementation does not attempt to keep 
> the URLSession object alive for the subsequent asynchronous code invocations. 
> Hence the crash. 
> 
> Two questions arise when we think of a solution:
> 1. How can we keep the live URLSession objects alive?
> 2. What trigger can we use to clean them up?
> 
> I try to answer (2) first. The URLSession programming guide 
> 
>  says:
> 
> "When you no longer need a session, invalidate it by calling either 
> invalidateAndCancel (to cancel outstanding tasks) or 
> finishTasksAndInvalidate(to allow outstanding tasks to finish before 
> invalidating the object). *** The session object keeps a strong reference to 
> the delegate until your app explicitly invalidates the session. If you do not 
> invalidate the session, your app leaks memory.*** "
> 

Interesting, this is counter to the usual pattern of delegation but I can see 
why it’s required here. Usually we want our delegates to be zeroing weak 
references.

> The URLSession references also mention that "invalidateAndCancel" and 
> "finishTasksAndInvalidate" break references to the callback and delegate 
> objects and make the session object unusable. *** So, it is apparent that 
> these methods are used to trigger a clean up of the session object ***
> 
> 
> Now coming to possible answers to (1). I can think of two ways of retaining 
> the session object:
> 
> 1. We intentionally maintain a retain cycle between the session and task 
> objects (URLSession <---> URLSessionTask)
> Currently the task object keeps an unowned reference to the session object. 
> We could make it a strong reference.  And break it when invalidateAndCancel 
> or finishTasksAndInvalidate are called. Alternatively, in the case of a 
> completion handler, we could break the cycle just before invoking the 
> handler. As long as we break the cycle eventually, I'm not sure if it could 
> have side effects. 
> 

This is probably the most reasonable approach.

Thanks for looking into this!

- Tony

> 2. We maintain all live sessions in a static array or dictionary in the 
> URLSession class. We remove them on session invalidation or callback 
> invocation. Doing this bookkeeping and searching may involve a cost and 
> scalability may be a problem here.
> 
> 
> Do you have any other approaches to consider? Can you please let me know your 
> opinion on the ones detailed above ? 
> 
> Thank you! 
> 
> Pushkar N Kulkarni,
> IBM Runtimes
> 
> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
> 
> 

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

Re: [swift-corelibs-dev] [swift-dev] Linux: Build process not finding my ICU

[Tony Parker via swift-corelibs-dev]

Hi Eric,

> On Sep 13, 2016, at 10:30 PM, Eric Wing via swift-corelibs-dev 
>  wrote:
> 
> On 9/13/16, Will Stanton  wrote:
>> Hello Eric,
>> 
>> Not sure if this will help, but perhaps you can feed something in build.py?
>> https://github.com/apple/swift-corelibs-foundation/blob/master/build.py
>> 
>> You seem to be working under some tight constraints! Is installing ICU in
>> /usr/local/ not possible?
>> 
>> Regards,
>> Will Stanton
>> 
> 
> Thanks for the reply. That was helpful in giving me a place to start.
> 
> So I'm trying to make it possible to build Swift binaries that can be
> run on most modern Linux's. Steam-Runtime is my base as they are
> heavily focused on binary distribution. I suppose I could put stuff
> into my /usr/local since they do not use that directory for their
> stuff. However, as a general principle, I try to avoid putting stuff
> into installed areas because it makes auditing dependencies for binary
> distribution harder later. The CMake build process is mostly aware
> that components can be elsewhere, but this part of the build process
> is not using CMake.
> 
> 
> So I hacked up build.py, but it looks like I have additional problems.
> 
> Foundation is using newer features in libxml and libcurl than what I
> have available. xmlXPathNodeEval and CURLOPT_XFERINFOFUNCTION seem to
> be the biggest roadblocks at the moment.
> 
> But my bigger problem at the moment is build.py doesn't put the Link
> flags in the right place. When it builds foundation, it puts the link
> flags first, and then all the .o filles from Foundation. The link
> flags need to be after all the .o files. Some of my dependencies are
> static libraries, and I think if the link process tries to use a
> library before the symbol is actually needed, it gets dropped early.
> Then I get a massive amount of unresolved symbol errors. (I've
> verified by manually invoking the command on the terminal myself.)
> 

I think a patch which fixed just this part would probably be fine.

In general we’re probably going to just have to specify a list of minimum 
dependencies for Foundation. We don’t really have a great story for missing 
features from ICU or libxml.

- Tony

> I would appreciate any thoughts/help on what I should look at changing
> next. And I would like to do this in a way that might be accepted back
> into the main source tree.
> 
> Thanks,
> Eric
> ___
> 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] Inconsistent URLSession POST behaviour

[Tony Parker via swift-corelibs-dev]

> On Sep 12, 2016, at 12:52 AM, Michael Ferenduros via swift-corelibs-dev 
>  wrote:
> 
> 
>> On 12 Sep 2016, at 09:25, Pushkar N Kulkarni  wrote:
>> 
>> Hi Michael,
>> 
>> I took a quick look at the URLSession code and it looks like the httpBody 
>> isn't being picked up anywhere. 
>> 
>> Could you please create a bug report on https://bugs.swift.org ?
> 
> Cool:
> https://bugs.swift.org/browse/SR-2617
> 
> Generally, should I be filing bugs for corelibs? I occasionally run into 
> various issues (eg. uploadTask has different parameter naming) but I’m 
> conscious that it’s not complete and probably most issues are already known 
> and being worked on.

Absolutely! We’ve done a lot of work to try and make things match, but since 
it’s a manual process there are things we’ve missed. Please let us know when 
you find a discrepancy.

Some things are omitted intentionally, but if the same method exists with 
different parameter names it’s probably an oversight.

- Tony

> 
> Thanks!
> 
> ___
> 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] Adding retain to CFCalendar.c - SR2879

[Tony Parker via swift-corelibs-dev]

Hi Alex,

Thanks for digging into this. This seems like a correct solution for now.

I think there is a larger question though, which is why it’s possible to 
overrelease kCFEmptyString. I think we skirted the issue early in bringup of 
SCL-Foundation, but constant strings are supposed to be “pinned” and ref count 
operations on them a no-op.

- Tony

> On Oct 7, 2016, at 6:47 AM, Alex Blewitt via swift-corelibs-dev 
>  wrote:
> 
> I'm looking at https://bugs.swift.org/browse/SR-2879 
>  which is exposing itself through an 
> over-release of a constant CF string (in this case, kCFEmptyString). I don't 
> believe it to be a Swift related problem, because Swift doesn't get into the 
> internals of CFCalendar where the problem occurs.
> 
> The problem is that CFCalendar releases the localeID when it's deallocated:
> 
> if (calendar->_localeID) CFRelease(calendar->_localeID);
> 
> https://github.com/apple/swift-corelibs-foundation/blob/1a76e814212e781a9d50782ee24117760cfe9b48/CoreFoundation/Locale.subproj/CFCalendar.c#L54
>  
> 
>  
> 
> The problem is that when the localeID is assigned, it doesn't appear to be 
> copied or renamed:
> 
> calendar->_localeID = CFLocaleGetIdentifier(CFLocaleGetSystem());
> 
> https://github.com/apple/swift-corelibs-foundation/blob/1a76e814212e781a9d50782ee24117760cfe9b48/CoreFoundation/Locale.subproj/CFCalendar.c#L252
>  
> 
>  
> https://github.com/apple/swift-corelibs-foundation/blob/1a76e814212e781a9d50782ee24117760cfe9b48/CoreFoundation/Locale.subproj/CFCalendar.c#L281
>  
> 
>   
> 
> but elsewhere in the code, we do retain it:
> 
>CFStringRef localeID = CFLocaleGetIdentifier(locale);
> if (localeID != calendar->_localeID) {
>   CFRelease(calendar->_localeID);
>   CFRetain(localeID);
> 
> https://github.com/apple/swift-corelibs-foundation/blob/1a76e814212e781a9d50782ee24117760cfe9b48/CoreFoundation/Locale.subproj/CFCalendar.c#L303-L306
>  
> 
>  
> 
> When a locale isn't supplied, it uses the default global one, which is 
> defined to be an empty string:
> 
> CFLocaleRef CFLocaleGetSystem(void) {
> CFLocaleRef locale;
> CFLocaleRef uselessLocale = NULL; //if we lose the race creating the 
> global locale, we need to release the one we created, but we want to do it 
> outside the lock.
> __CFLocaleLockGlobal();
> if (NULL == __CFLocaleSystem) {
>   __CFLocaleUnlockGlobal();
>   locale = CFLocaleCreate(kCFAllocatorSystemDefault, CFSTR(""));
>   if (!locale) return NULL;
> 
> https://github.com/apple/swift-corelibs-foundation/blob/1a76e814212e781a9d50782ee24117760cfe9b48/CoreFoundation/Locale.subproj/CFLocale.c#L255-L261
>  
> 
>  
> 
> The CFSTR("") results in a reference to kCFEmptyString, which reduces by one 
> each time a CFCalendar is created and destroyed, leading to the (unrelated) 
> test failures of https://github.com/apple/swift-corelibs-foundation/pull/667 
>  as documented 
> in https://bugs.swift.org/browse/SR-2879 
> 
> 
> My suggestion is to insert a CFRetain when the calendar->locale is set, to 
> balance out the CFRelease that's being performed in the deallocator. Building 
> with this simple change and checking the retain count of kCFEmptyString 
> verifies that it does fix the problem, although I'm open to suggestions as to 
> improvements of where the retain takes place, if not on lines 252 and 282.
> 
>   1> import Foundation 
>   2> :p (int)swift_retainCount(&__kCFEmptyString) 
> (int) $11 = 1
>   2> _ = Calendar(identifier:.gregorian)
>   3> :p (int)swift_retainCount(&__kCFEmptyString) 
> (int) $12 = 3
>   3> _ = Calendar(identifier:.chinese)
>   4> :p (int)swift_retainCount(&__kCFEmptyString) 
> (int) $13 = 3
>   4> _ = Calendar(identifier:.hebrew)
>   5> :p (int)swift_retainCount(&__kCFEmptyString) 
> (int) $14 = 3
>   5> ^D
> 
> Alex
> ___
> 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

Re: [swift-corelibs-dev] NSRegularExpression - NS prefix not dropped on Darwin

[Tony Parker via swift-corelibs-dev]

Hi Pushkar,

We decided to keep the NS on NSRegularExpression because we know that a strong 
goal for the Swift language is to have built-in support for regex. We wanted to 
be cautious about taking the name without knowing more about how that feature 
would shake out.

We should get a JIRA filed or a PR up to put the NS back for the class name in 
swift-corelibs-foundation.

Thanks,
- Tony

> On Sep 16, 2016, at 6:16 AM, Pushkar N Kulkarni via swift-corelibs-dev 
>  wrote:
> 
> Hello, 
> 
> The NS prefix from NSRegularExpression seems to have been dropped only in 
> open source Foundation. On Darwin the class is still called 
> NSRegularExpression.
> 
> https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSRegularExpression.swift#L30
>  
> 
> 
> I went through the Drop NS prefix proposal 
> 
>  but couldn't relate this to any of the rules mentioned there (except for a 
> possibility that we will have a RegularExpression value type in future only 
> on Darwin!)
> 
> Is there any particular reason for this difference?
> 
> Thanks in advance!
> 
> Pushkar N Kulkarni,
> IBM Runtimes
> 
> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
> 
> 
> ___
> 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

[Tony Parker via swift-corelibs-dev]

Hi Luke,

In Xcode it should be possible to set the build order like this:

Foundation
XCTest
TestFoundation

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] Query on NSKeyedArchiver

[Tony Parker via swift-corelibs-dev]

> On Oct 26, 2016, at 10:14 AM, Max Desiatov <max.desia...@gmail.com> wrote:
> 
> Hi Tony,
> 
> This is very interesting caveat. Is there a plan to get this documented 
> anywhere? I haven't seen any documentation for Swift Foundation published 
> publicly anywhere akin to how it's done for other APIs at 
> https://developer.apple.com/reference/ 
> <https://developer.apple.com/reference/>.
> 
> With best regards, Max.

With respect to the NSObject requirement: It’s really more of a known issue 
than a permanent limitation.

To over summarize the situation: NSKeyedArchiver (the Objective-C one) puts a 
private category on NSObject and assumes all objects respond to those messages 
after that.

We don’t really have documentation for swift-corelibs-foundation beyond what we 
can put in our own headerdoc format there. That would be something I would 
really appreciate help on if anyone is interested in contributing.

- Tony

> 
>> On 26 Oct 2016, at 18:11, Tony Parker via swift-corelibs-dev 
>> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> Hi Sai,
>> 
>> We do have basic support for keyed archiving and unarchiving in 
>> swift-corelibs-foundation on Linux. The limitation is that the NSCoding 
>> protocol cannot be applied to Swift struct types, only class types. On 
>> Darwin, the class also must be a subclass of NSObject. This last limitation 
>> may not exist on Linux, but you should be aware that if you encode a 
>> non-NSObject subclass on Linux then you would not be able to decode it on 
>> Darwin.
>> 
>> - Tony
>> 
>>> On Oct 26, 2016, at 4:07 AM, Sai Kanduri via swift-corelibs-dev 
>>> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
>>> 
>>> Hi Tony,
>>>  
>>> From your comments on Pull Request #574 I understand that we cannot 
>>> archive/un-archive non-NS objects using  NsKeyedArchiver & 
>>> NSKeyedUnarchiver.I s my understanding correct ..? Does this means that 
>>> archiving and un-archiving of  swift types is  not supported on Linux  ?
>>>  
>>> -Sai Hema
>>> 
>>> ___
>>> swift-corelibs-dev mailing list
>>> swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>>> <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev>
>> 
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org <mailto: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] Query on NSKeyedArchiver

[Tony Parker via swift-corelibs-dev]

Hi Sai,

We do have basic support for keyed archiving and unarchiving in 
swift-corelibs-foundation on Linux. The limitation is that the NSCoding 
protocol cannot be applied to Swift struct types, only class types. On Darwin, 
the class also must be a subclass of NSObject. This last limitation may not 
exist on Linux, but you should be aware that if you encode a non-NSObject 
subclass on Linux then you would not be able to decode it on Darwin.

- Tony

> On Oct 26, 2016, at 4:07 AM, Sai Kanduri via swift-corelibs-dev 
>  wrote:
> 
> Hi Tony,
>  
> From your comments on Pull Request #574 I understand that we cannot 
> archive/un-archive non-NS objects using  NsKeyedArchiver & 
> NSKeyedUnarchiver.I s my understanding correct ..? Does this means that 
> archiving and un-archiving of  swift types is  not supported on Linux  ?
>  
> -Sai Hema
> 
> ___
> 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] Implementing HTTPCookieStorage

[Tony Parker via swift-corelibs-dev]

Hi Pushkar,

Good question. If this were Darwin I guess I would say ~/Library/Application 
Support — but I don’t know what the best practices are on other platforms. Does 
anyone out there have some suggestions?

- Tony

> On Nov 7, 2016, at 11:09 AM, Pushkar N Kulkarni via swift-corelibs-dev 
>  wrote:
> 
> Hi there, 
> 
> I have spent some time working on a basic implementation of 
> HTTPCookieStorage. In the process, I came across two crucial questions 
> related to cookie persistence:
> 1. How do you persist the cookies?
> 2. Where do you persist them?
> 
> In my current implementation 
> (https://github.com/apple/swift-corelibs-foundation/pull/672) 
> , I write them 
> to a hidden plist file located in the user's home directory. Would that be an 
> acceptable approach?
> 
> Is there anything more to consider while thinking of persistence? I'd greatly 
> appreciate suggestions/comments. 
> 
> Thanks!
> Pushkar N Kulkarni,
> IBM Runtimes
> 
> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
> 
> 
> ___
> 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] Cannot call CFStreamCreatePairWithSocket on Linux

[Tony Parker via swift-corelibs-dev]

Hi Bouke,

There is currently no plan to open source the more modern versions of 
CFNetwork. We’ll have to replace its functionality in swift-corelibs-foundation.

- Tony

> On Oct 8, 2016, at 1:12 AM, Bouke Haarsma via swift-corelibs-dev 
>  wrote:
> 
> I'm running into the same issue as outlined in this post. Are there currently 
> any plans on bringing CFNetwork to swift-corelibs? 
> 
> On 2016-03-15 15:07:15 +, Philippe Hausler via swift-corelibs-dev said:
> 
> You are correct, those symbols are from CFNetwork which are not yet 
> implemented on linux targets. CFStream is implemented but CFSocketStream is 
> not implemented in swift-corelibs-foundation. It could be technically 
> reasonable to port the open source (very old) CFNetwork to linux. However I 
> am fairly certain that would take a bit of work to get up and running; 
> especially the Security framework portions.
> 
> On Mar 15, 2016, at 7:54 AM, Pushkar N Kulkarni via swift-corelibs-dev 
> > wrote:
> 
> Hello all, 
> 
>  While attempting a simple Swift client-server program on Linux using 
> CFSocket, I tried to create CFReadStream and CFWriteStream instances using 
> CFStreamCreatePairWithSocket(_:_:_:_). The program compiles and links but it 
> crashes with this:
> 
> 2016-03-15 10:30:17.791 Client[21389:5a501740] CoreFoundation: failed to 
> dynamically link symbol _CFSocketStreamCreatePair
> 
> 2016-03-15 10:30:17.791 Client[21389:5a501740] CoreFoundation: failed to 
> dynamically link symbol _CFErrorCreateWithStreamError
> 
> 2016-03-15 10:30:17.791 Client[21389:5a501740] CoreFoundation: failed to 
> dynamically link symbol _CFStreamErrorFromCFError
> 
> 
> 
> 
> 
> I see that these symbols are dynamically linked from CFNetwork which, I 
> guess, doesn't exist on Linux (so there is no lookup for these symbols on 
> Linux). 
> 
> Does this qualify to be a CFStream limitation on Linux?
> 
> Thanks in advance for your time!
> 
> Pushkar N Kulkarni,
> IBM Runtimes
> 
> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
> 
> 
> ___
> 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
> 
> 
> -- 
> -Bouke
> ___
> 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] Implementing HTTPCookieStorage

[Tony Parker via swift-corelibs-dev]

Hi Will,

> On Nov 14, 2016, at 12:56 PM, Will Stanton <willstant...@yahoo.com> wrote:
> 
> Hello Tony,
> 
> Thanks for the reply. About XDG_DATA_HOME, the variable is undefined on my 
> desktop-less server, and I think many processes still have their own save 
> locations.
> Still, I can believe its used in a lot of places 
> (https://github.com/search?q=XDG_DATA_HOME=Code=✓) and am not 
> opposed to it!
> 
> Perhaps SEARCH/$EXECUTABLE_NAME/Preferences.plist would be good place and 
> format for NSUserDefaults with SEARCH = getenv(XDG_DATA_HOME) then ~/.config?
> 
> 
> What about the path for cookies+caches?

I’m just reading this spec for the first time, but it looks like it accounts 
for that:

>   • There is a single base directory relative to which user-specific 
> non-essential (cached) data should be written. This directory is defined by 
> the environment variable $XDG_CACHE_HOME.

Overall the spec looks reasonable and seems to be close to what we we would 
need.

A great next step would be to file a JIRA and look for volunteers who want to 
help implement this in SCL-Foundation.

- Tony

> 
> Regards,
> Will Stanton
> 
>> On Nov 14, 2016, at 2:37 PM, Tony Parker via swift-corelibs-dev 
>> <swift-corelibs-dev@swift.org> wrote:
>> 
>> Off-list, someone pointed me here:
>> 
>> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
>> 
>> and here:
>> 
>> http://stackoverflow.com/questions/1024114/location-of-ini-config-files-in-linux-unix
>> 
>> Noting that there seems to be a growing consensus for $HOME/.config.
>> 
>> Is this spec beginning to be used in the real world?
> 

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

Re: [swift-corelibs-dev] Implementing Bundle.init(for aClass: AnyClass)

[Tony Parker via swift-corelibs-dev]

Hi Mamatha,

> On Nov 18, 2016, at 3:03 AM, Mamatha Busi via swift-corelibs-dev 
>  wrote:
> 
> Hi
> 
> 
> 
> init(for aClass: AnyClass) is an unimplemented API on Linux. I am exploring 
> around this to implement the same and have a couple of queries:
> 
> 
> 
> -> In the context of Linux platform, how relevant is this API for loading 
> bundles dynamically? 
> 
> 

On Darwin, this API really only works if the bundle is already loaded. It’s 
more about getting the NSBundle instance for a particular class.
> 
> -> In a Bundle, how do I go about getting information on the classes that are 
> available within it? 
> 
> 
> 
On Darwin (again) we ask dyld for the library that holds the pointer for the 
class info, then use further dyld functions to find the path for that library, 
and use that info to construct the bundle.

These seem reasonable on Linux and in Swift, if we can get some kind of 
metadata about the class.

- Tony
> Any related insights/suggestions would help.
> 
> 
> 
> Thanks
> 
> 
> Mamatha
> 
> 
> 
> 
> 
> ___
> 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] Implementing HTTPCookieStorage

[Tony Parker via swift-corelibs-dev]

> On Nov 14, 2016, at 10:47 AM, Will Stanton  wrote:
> 
> Hello Tony and Philippe,
> 
> I don’t think it would be odd for cookie/setting files to be in a folder 
> named after Foundation (namely ~/.foundation):
> - The files are owned by Swift/Linux Foundation in the sense Foundation 
> writes them, and Foundation is the only one that should access them directly. 
> Foundation should enforce security.
> - On macOS, settings seem to be written to 
> ~/Library/Preferences/$(BUNDLE_ID).plist, and the proposed 
> ~/.foundation/Preferences/EXECUTABLE_NAME.plist isn’t that different.
> ‘.foundation’ is used in lieu of a library directory, and I feel this is 
> acceptable so as not to clash with any user ~/Preferences or ~/Library 
> directory.  I am OK with the ‘Foundation ownership’ per above.
> And, executable name seems reasonable in lieu of bundle ID.
> 
> I noted something like 
> ~/.foundation/Library/Preferences/EXECUTABLE_NAME.plist may be desirable to 
> keep symmetry/reuse more CF code, but changing Swift CF is probably necessary 
> anyway and better (fewer search paths to loop through, possibly less I/O).
> 

Agreed, I don’t have any problem with baking a set of rules into CF that is 
specific to various platforms. That’s it’s job after all.

> 
> Am interested in alternatives of course :-)
> - But having separate folders for each app seems complicated, ex. 
> '~/.app1/Preferences’ ‘~/.app2/Preferences’ pollutes home.
> - I don’t really mind the name of an encapsulating folder, .foundation or 
> otherwise.
> - Placing system configuration files in /etc is a norm, but I think I’d feel 
> more comfortable with Swift app settings in /home/user (easier to keep track 
> of, and I can delete the whole thing without consequences*). I’m also not 
> writing any real low-level services in Swift… but others probably are… but 
> they probably have their own code to write config data to /etc!
> 

Off-list, someone pointed me here:

https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

and here:

http://stackoverflow.com/questions/1024114/location-of-ini-config-files-in-linux-unix

Noting that there seems to be a growing consensus for $HOME/.config.

Is this spec beginning to be used in the real world?

- Tony

> 
> To Philippe’s points about security+future-proofing:
> Perhaps the cookie file could be named per version of its format:
> ~/.foundation/Cookies/shared initially
> When we have a new format:
> ~/.foundation/Cookies/shared2, shared3, etc? Or even pick a new name entirely?
> 
> I also think it should be up to Swift Foundation to enforce cookie security 
> on a per-app/family basis (the latter requires changes to the package 
> structure?).
> Perhaps for now, it is possible to save the hash and name of the executable 
> storing a cookie? And Foundation can load cookie storage only if the 
> executable name and file haven’t changed? (Is that an unnecessary pain?)
> 
> Regards,
> Will Stanton
> 
>> On Nov 14, 2016, at 12:44 PM, Tony Parker  wrote:
>> 
>> Isn’t it a bit odd to use ‘.foundation’ as the name of the directory, when 
>> Foundation is just one of the libraries involved? On Darwin, the prefs are 
>> organized by application, not by framework.
> 

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

Re: [swift-corelibs-dev] Query on NSKeyedArchiver

[Tony Parker via swift-corelibs-dev]

Sorry, this fell off my radar. I’ll test and merge again.

- Tony

> On Oct 27, 2016, at 2:56 AM, Luke Howard <lu...@padl.com> wrote:
> 
> BTW is anything blocking integrating SR-2416?
> 
> https://github.com/apple/swift-corelibs-foundation/pull/574 
> <https://github.com/apple/swift-corelibs-foundation/pull/574>
> 
> That allows value types to be archived too if they support _ObjectBridgeable 
> (they’ll come back as reference types though).
> 
>> On 27 Oct 2016, at 4:22 AM, Tony Parker via swift-corelibs-dev 
>> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> 
>>> On Oct 26, 2016, at 10:14 AM, Max Desiatov <max.desia...@gmail.com 
>>> <mailto:max.desia...@gmail.com>> wrote:
>>> 
>>> Hi Tony,
>>> 
>>> This is very interesting caveat. Is there a plan to get this documented 
>>> anywhere? I haven't seen any documentation for Swift Foundation published 
>>> publicly anywhere akin to how it's done for other APIs at 
>>> https://developer.apple.com/reference/ 
>>> <https://developer.apple.com/reference/>.
>>> 
>>> With best regards, Max.
>> 
>> With respect to the NSObject requirement: It’s really more of a known issue 
>> than a permanent limitation.
>> 
>> To over summarize the situation: NSKeyedArchiver (the Objective-C one) puts 
>> a private category on NSObject and assumes all objects respond to those 
>> messages after that.
>> 
>> We don’t really have documentation for swift-corelibs-foundation beyond what 
>> we can put in our own headerdoc format there. That would be something I 
>> would really appreciate help on if anyone is interested in contributing.
>> 
>> - Tony
>> 
>>> 
>>>> On 26 Oct 2016, at 18:11, Tony Parker via swift-corelibs-dev 
>>>> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
>>>> 
>>>> Hi Sai,
>>>> 
>>>> We do have basic support for keyed archiving and unarchiving in 
>>>> swift-corelibs-foundation on Linux. The limitation is that the NSCoding 
>>>> protocol cannot be applied to Swift struct types, only class types. On 
>>>> Darwin, the class also must be a subclass of NSObject. This last 
>>>> limitation may not exist on Linux, but you should be aware that if you 
>>>> encode a non-NSObject subclass on Linux then you would not be able to 
>>>> decode it on Darwin.
>>>> 
>>>> - Tony
>>>> 
>>>>> On Oct 26, 2016, at 4:07 AM, Sai Kanduri via swift-corelibs-dev 
>>>>> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> 
>>>>> wrote:
>>>>> 
>>>>> Hi Tony,
>>>>>  
>>>>> From your comments on Pull Request #574 I understand that we cannot 
>>>>> archive/un-archive non-NS objects using  NsKeyedArchiver & 
>>>>> NSKeyedUnarchiver.I s my understanding correct ..? Does this means that 
>>>>> archiving and un-archiving of  swift types is  not supported on Linux  ?
>>>>>  
>>>>> -Sai Hema
>>>>> 
>>>>> ___
>>>>> swift-corelibs-dev mailing list
>>>>> swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>>>>> <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev>
>>>> 
>>>> ___
>>>> swift-corelibs-dev mailing list
>>>> swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>>>> <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev>
>>> 
>> 
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 
> Luke Howard
> web <http://lukehoward.com/> / facebook 
> <https://www.facebook.com/lukehowardmusic> / soundcloud 
> <https://soundcloud.com/lukehoward/> / spotify 
> <https://open.spotify.com/artist/3duTXsC49HoPt4f4EySDKf>

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

Re: [swift-corelibs-dev] Question about NSDecimalCopy

[Tony Parker via swift-corelibs-dev]

Hi Morten,

> On Jan 9, 2017, at 2:16 AM, Morten Bek Ditlevsen via swift-corelibs-dev 
>  wrote:
> 
> Hi list,
> I was looking at the NSDecimal.swift to learn a bit about the implementation 
> of the Decimal type.
> I get that a lot of the API in this type exists for compatibility reasons 
> with the C implementation.
> 
> But I was wondering about how the NSDecimalCopy function differs from a 
> simple assignment of one Decimal value to another.
> 
> NSDecimalCopy simply assigns each field of the struct one by one, so when 
> would it ever be preferable to performing a simple assignment?
> 
> So basically my question is - is there any difference in the result of 
> performing:
> 
> var a: Decimal = 1
> var b: Decimal = 2
> NSDecimalCopy(, )
> 
> and 
> var a: Decimal = 1
> var b: Decimal = 2
> b = a
> 

I suspect that this is just due to some logic copying from the C version.

I’m actually not sure what the compiler does here. It should be possible to try 
it out in a test app, disassemble it, and check out the result. Let us know 
what you find. =)

- Tony

> Secondly - if there is no difference in the result - is it not more 
> performant to assign the value directly?
> 
> This question also raised a question about Swift internals: If you have a 
> pure value type (no nested reference types): Does an assignment then simply 
> copy a chunk of memory with the size of the struct? Or is each field 
> assigned/copied recursively?
> 
> Sincerely,
> /morten
> ___
> 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] Autoupdating type properties

[Tony Parker via swift-corelibs-dev]

Hi Pushkar,

> On Nov 30, 2016, at 6:39 AM, Pushkar N Kulkarni  wrote:
> 
> Thanks Tony, for the detailed explanation! 
> 
>  I think I need a bit more clarification though :)
> 
> >>> Now, nothing in the value type contract says that you cannot have 
> >>> computed properties on a value type. Also, value types are not 
> >>> necessarily “pure”, in the sense that they ignore all external input. 
> >>> What this means for time zone is that its identifier can change depending 
> >>> on user preferences, if its value is “autoupdating". If you set its value 
> >>> to a specific time zone instead, then it does not have the value of 
> >>> “autoupdating" and its computed properties do not behave that way.
> 
> Please correct me if I am wrong in deriving these from the above:
> 1. `NSTimezone.local` will be a computed type property, which when invoked 
> can return different values (based on user preferences - an external factor) 
> at different points in application's lifetime.
> 2. If NSTimezone.default is explicitly set to a time zone, NSTimezone.local 
> will not reflect that change.
> 3. Existing copies of 'NSTimezone.local' (referring to the example in my 
> question) will also not reflect the change.
> 

Swift clients should really use struct TimeZone instead of class NSTimeZone. I 
updated struct TimeZone’s naming and static functions to be a lot more clear:

/// The time zone currently used by the system.
public static var current : TimeZone


/// The time zone currently used by the system, automatically updating to 
the user's current preference.
///
/// If this time zone is mutated, then it no longer tracks the application 
time zone.
///
/// The autoupdating time zone only compares equal to itself.
public static var autoupdatingCurrent : TimeZone

The ‘current’ struct TimeZone is the ‘system’ NSTimeZone. The 
‘autoupdatingCurrent’ struct TimeZone is the ‘autoupdatingCurrent’ NSTimeZone. 
The ‘default’ NSTimeZone is an awful pattern that nobody should use, because 
it’s likely to be an unexpected value*. I did not include it in struct TimeZone.

The result of calling ‘current’ will change depending on external factors (user 
prefs), but the result from calling it will stay whatever value it was when you 
retrieved it.

The result of calling ‘autoupdatingCurrent’ will always be an autoupdating time 
zone, which will reflect user preferences on its properties when called.

Hope that helps,
- Tony

* details: Anyone can set the default time zone, but once it’s retrieved using 
that class method then your copy no longer updates. So you may think you’re 
setting the default time zone for your app, but in reality if some piece of 
code sets it after some other piece of code gets it, you’re just using two 
different time zones in your app. All of the problems of shared global state.

> 
> Pushkar N Kulkarni,
> IBM Runtimes
> 
> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
> 
> 
> 
> -anthony.par...@apple.com  wrote: 
> -
> To: Pushkar N Kulkarni/India/IBM@IBMIN
> From: Tony Parker 
> Sent by: anthony.par...@apple.com 
> Date: 11/30/2016 01:39PM
> Cc: swift-corelibs-dev  >
> Subject: Re: [swift-corelibs-dev] Autoupdating type properties
> 
> Hi Pushkar,
> 
>> On Nov 29, 2016, at 4:12 AM, Pushkar N Kulkarni via swift-corelibs-dev 
>> > wrote:
>> 
>> Hi there, 
>> 
>> I am curious about how an autoupdating type property like `NSTimeZone.local` 
>> could be implemented, given that it is a value (the type is TimeZone). The 
>> requirement essentially is that if the default timezone is changed, the 
>> change should reflect in all copies of this value.
>> 
>> import Foundation
>> 
>> 
>> 
>> let local = NSTimeZone.local
>> 
>> let local1 = local
>> 
>> print(local)  //prints the default TimeZone
>> 
>> print(local1) //prints the default TimeZone
>> 
>> 
>> 
>> let t = TimeZone(identifier: "America/Chicago")!
>> 
>> NSTimeZone.default = t
>> 
>> 
>> 
>> print(local)//prints "America/Chicago (autoupdatingCurrent)
>> 
>> print(local1)   //prints "America/Chicago (autoupdatingCurrent)
>> 
>> 
>> 
>> What makes it complicated is that TimeZone is a value type. I hope I am not 
>> missing something fundamental here!
>> 
>> Any ideas or information will be highly appreciated. Thanks!
> 
> You’re not missing anything fundamental. We considered this case very 
> carefully before proposing these types as value types. I agree that it’s on 
> the borderline, but in the end having it as a value type was too valuable (no 
> pun intended).
> 
> What we decided is essentially this: the value of the time zone is not its 
> identifier. Instead, abstract it one level. That means that “Autoupdating” 
> can be the actual value. Like an open 

Re: [swift-corelibs-dev] Autoupdating type properties

[Tony Parker via swift-corelibs-dev]

Hi Pushkar,

> On Nov 29, 2016, at 4:12 AM, Pushkar N Kulkarni via swift-corelibs-dev 
>  wrote:
> 
> Hi there, 
> 
> I am curious about how an autoupdating type property like `NSTimeZone.local` 
> could be implemented, given that it is a value (the type is TimeZone). The 
> requirement essentially is that if the default timezone is changed, the 
> change should reflect in all copies of this value.
> 
> import Foundation
> 
> 
> 
> let local = NSTimeZone.local
> 
> let local1 = local
> 
> print(local)  //prints the default TimeZone
> 
> print(local1) //prints the default TimeZone
> 
> 
> 
> let t = TimeZone(identifier: "America/Chicago")!
> 
> NSTimeZone.default = t
> 
> 
> 
> print(local)//prints "America/Chicago (autoupdatingCurrent)
> 
> print(local1)   //prints "America/Chicago (autoupdatingCurrent)
> 
> 
> 
> What makes it complicated is that TimeZone is a value type. I hope I am not 
> missing something fundamental here!
> 
> Any ideas or information will be highly appreciated. Thanks!

You’re not missing anything fundamental. We considered this case very carefully 
before proposing these types as value types. I agree that it’s on the 
borderline, but in the end having it as a value type was too valuable (no pun 
intended).

What we decided is essentially this: the value of the time zone is not its 
identifier. Instead, abstract it one level. That means that “Autoupdating” can 
be the actual value. Like an open enumeration.

Now, nothing in the value type contract says that you cannot have computed 
properties on a value type. Also, value types are not necessarily “pure”, in 
the sense that they ignore all external input. What this means for time zone is 
that its identifier can change depending on user preferences, if its value is 
“autoupdating". If you set its value to a specific time zone instead, then it 
does not have the value of “autoupdating" and its computed properties do not 
behave that way.

I reflected this contract in the == method as well. Autoupdating time zones are 
equal to other autoupdating time zones. However, the autoupdating time zone is 
not equal to America/Chicago, even if the current time zone is America/Chicago. 

let la = TimeZone(identifier: "America/Los_Angeles”) // America/Los_Angeles 
(current)
let tz = TimeZone.autoupdatingCurrent // America/Los_Angeles 
(autoupdatingCurrent)
la == tz // false
let tz2 = TimeZone.autoupdatingCurrent // America/Los_Angeles 
(autoupdatingCurrent)
tz == tz2 // true

In the case of Calendar, if you mutate it then it is no longer autoupdating — 
you have changed its value.

I’m sure reasonable people could disagree on the direction we chose here, and 
if we were reinventing the world from scratch I probably would not have added 
this complication to the API. However, the existing autoupdating concept is 
used pervasively and I needed a way to fit it into the new system.

- Tony

> 
> Pushkar N Kulkarni,
> IBM Runtimes
> 
> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
> 
> 
> ___
> 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] index indexes and ranges of String

[Tony Parker via swift-corelibs-dev]

Hi Carlos,

Thanks for proposing this. Would you mind sending it out to swift-dev or 
swift-evolution as well? The authors of the Swift standard library are more 
likely to see your message there.

- Tony

> On Dec 31, 2016, at 11:53 AM, Carlos García via swift-corelibs-dev 
>  wrote:
> 
> Hi,
> 
> I think this is important enough and useful for we to be in the core standard 
> library
> 
> extension String {
> 
> func index(of string: String, options: String.CompareOptions = .literal) 
> -> String.Index? {
> return range(of: string, options: options)?.lowerBound
> }
> 
> func indexes(of string: String, options: String.CompareOptions = 
> .literal) -> [String.Index] {
> var result: [String.Index] = []
> var start = startIndex
> while let range = range(of: string, options: options, range: 
> start.. result.append(range.lowerBound)
> start = range.upperBound
> }
> return result
> }
> 
> func ranges(of string: String, options: String.CompareOptions = .literal) 
> -> [Range] {
> var result: [Range] = []
> var start = startIndex
> while let range = range(of: string, options: options, range: 
> start.. result.append(range)
> start = range.upperBound
> }
> return result
> }
> 
> }
> 
> 
> Source is not mine, I’ve found here: 
> http://stackoverflow.com/a/32306142/4550651 
> 
> 
> Best and happy 2017
> 
> Carlos García
> 
> 
> ___
> 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] URLSession test fest!

[Tony Parker via swift-corelibs-dev]

Hi Pushkar,

Another option is to continue to use httpbin.org <http://httpbin.org/>, but 
make the tests that use that network service not part of the normal unit tests 
but runnable on demand by us as we develop. That means we don’t have to 
reimplement the whole thing but we at least have some tools at our disposal to 
help debug and diagnose issues. As we make fixes we can improve our local unit 
test server’s infrastructure to prevent regressions.

- Tony

> On Mar 9, 2017, at 7:02 AM, Pushkar N Kulkarni <pushkar...@in.ibm.com> wrote:
> 
> Hi Tony, 
> 
> PRs 911 and 913 reminded me of this conversation you started. 
> 
> The current unit testing infrastructure for URLSession may prove insufficient 
> for future contributions. I've been looking at these tests 
> <https://github.com/mike-ferenduros/swift-corelibs-foundation/blob/more-urlsession-tests/TestFoundation/TestNSURLSession.swift>
>  written by Mike Ferenduros and they appear quite exhaustive! The only issue 
> is that they connect to an external HTTP test service - http://httpbin.org. 
> <http://httpbin.org./>  
> 
> A quick look at httpbin.org tells me it has sufficient functionality to aid 
> in URLSession unit testing. Do you think it would make sense to emulate this 
> functionality within TestFoundation?
> 
> 
> Pushkar N Kulkarni,
> IBM Runtimes
> 
> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
> 
> 
> 
> -swift-corelibs-dev-boun...@swift.org 
> <mailto:-swift-corelibs-dev-boun...@swift.org> wrote: -
> To: swift-corelibs-dev <swift-corelibs-dev@swift.org 
> <mailto:swift-corelibs-dev@swift.org>>
> From: Tony Parker via swift-corelibs-dev 
> Sent by: swift-corelibs-dev-boun...@swift.org 
> <mailto:swift-corelibs-dev-boun...@swift.org>
> Date: 01/25/2017 01:13AM
> Subject: [swift-corelibs-dev] URLSession test fest!
> 
> Hi everyone,
> 
> As we’re wrapping up Swift 3.1, I think it’d be a great opportunity to have a 
> quality focus area on one of our most important APIs: URLSession. If you’ve 
> been wondering how to make a meaningful contribution, this is the perfect 
> time.
> 
> It’d be great to greatly expand both unit test and higher level test coverage 
> of URLSession. For testing that can’t really be part of a unit test and CI 
> like poorly performing networks or esoteric configurations, it would also be 
> nice to build a different kind of test tool. That tool would provide a lot of 
> knobs for controlling a URLSession. We could make this tool part of the 
> swift-corelibs-foundation project.
> 
> Is anyone interested in chipping in here? We don’t have to start big. Even 
> small contributions could get us moving in the right direction.
> 
> Thanks,
> - Tony
> 
> 
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
> <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] URLSession test fest!

[Tony Parker via swift-corelibs-dev]

> On Mar 9, 2017, at 9:52 PM, Pushkar N Kulkarni <pushkar...@in.ibm.com> wrote:
> 
> Peter: I agree. A stable testing infrastructure is absolutely necessary.  
> 
> Tony: I am curious about where the sources for these tests (that use the 
> external httpbin.org) will be placed? Will it makes sense to have them in 
> TestFoundation and have a guard to exclude them during normal test execution?

Sure, or we could add a standalone tool like I mentioned at the top of this 
thread.

Either way, we should make it as easy as possible to enable the tests when 
you’re iterating on this code so you can verify the absence of regressions.

- Tony

> 
> Pushkar N Kulkarni,
> IBM Runtimes
> 
> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
> 
> 
> 
> -Peter Tomaselli <vast.gra...@gmail.com <mailto:vast.gra...@gmail.com>> 
> wrote: -
> To: Tony Parker <anthony.par...@apple.com <mailto:anthony.par...@apple.com>>
> From: Peter Tomaselli <vast.gra...@gmail.com <mailto:vast.gra...@gmail.com>>
> Date: 03/10/2017 04:47AM
> Cc: Pushkar N Kulkarni <pushkar...@in.ibm.com 
> <mailto:pushkar...@in.ibm.com>>, swift-corelibs-dev 
> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>>
> Subject: Re: [swift-corelibs-dev] URLSession test fest!
> 
> Just one outside data point on this: as someone who's been wanting to 
> contribute to the test fest, I agree that being able to test against 
> httpbin.org <http://httpbin.org/> (or some other pre-existing server — as 
> opposed to the loopback server) would make it much easier to make useful 
> contributions.
> 
> Not that the loopback server is bad, but I trashed several attempts at a 
> contribution due to lack of confidence about my changes. Specifically, with 
> both "ends" of the test apparatus in flux (for example, having to add 
> "features" to the loopback server just so that features of URLSession could 
> be tested), I found it very hard to know if either end was correct. 
> 
> So, just two cents from a lurker here, but this sounds like a great idea to 
> me. Cheers,
> 
> Peter
> 
> On Mar 9, 2017, at 4:38 PM, Tony Parker via swift-corelibs-dev 
> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
> 
>> Hi Pushkar,
>> 
>> Another option is to continue to use httpbin.org <http://httpbin.org/>, but 
>> make the tests that use that network service not part of the normal unit 
>> tests but runnable on demand by us as we develop. That means we don’t have 
>> to reimplement the whole thing but we at least have some tools at our 
>> disposal to help debug and diagnose issues. As we make fixes we can improve 
>> our local unit test server’s infrastructure to prevent regressions.
>> 
>> - Tony
>> 
>>> On Mar 9, 2017, at 7:02 AM, Pushkar N Kulkarni <pushkar...@in.ibm.com 
>>> <mailto:pushkar...@in.ibm.com>> wrote:
>>> 
>>> Hi Tony, 
>>> 
>>> PRs 911 and 913 reminded me of this conversation you started. 
>>> 
>>> The current unit testing infrastructure for URLSession may prove 
>>> insufficient for future contributions. I've been looking at these tests 
>>> <https://github.com/mike-ferenduros/swift-corelibs-foundation/blob/more-urlsession-tests/TestFoundation/TestNSURLSession.swift>
>>>  written by Mike Ferenduros and they appear quite exhaustive! The only 
>>> issue is that they connect to an external HTTP test service - 
>>> http://httpbin.org. <http://httpbin.org./>  
>>> 
>>> A quick look at httpbin.org <http://httpbin.org/> tells me it has 
>>> sufficient functionality to aid in URLSession unit testing. Do you think it 
>>> would make sense to emulate this functionality within TestFoundation?
>>> 
>>> 
>>> Pushkar N Kulkarni,
>>> IBM Runtimes
>>> 
>>> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
>>> 
>>> 
>>> 
>>> -swift-corelibs-dev-boun...@swift.org 
>>> <mailto:-swift-corelibs-dev-boun...@swift.org> wrote: -
>>> To: swift-corelibs-dev <swift-corelibs-dev@swift.org 
>>> <mailto:swift-corelibs-dev@swift.org>>
>>> From: Tony Parker via swift-corelibs-dev 
>>> Sent by: swift-corelibs-dev-boun...@swift.org 
>>> <mailto:swift-corelibs-dev-boun...@swift.org>
>>> Date: 01/25/2017 01:13AM
>>> Subject: [swift-corelibs-dev] URLSession test fest!
>>> 
>>> Hi everyone,
>>> 
>>> As we’re wr

Re: [swift-corelibs-dev] NSOrderedMutableSet subscript setter

[Tony Parker via swift-corelibs-dev]

Hi Richard,

I suspect the importer must be adding this due to the presence of API like 
objectAtIndex: on the NSOrderedSet API.

If we’re missing it in swift-corelibs-foundation but it exists on Darwin, we 
should add it.

- Tony

> On Mar 14, 2017, at 7:02 AM, Richard Wei via swift-corelibs-dev 
>  wrote:
> 
> Hello corelibs-dev,
> 
> There is a subscript setter in `NSOrderedMutableSet` on Darwin platforms but 
> not on Linux. Neither does the setter exist in Developer Documentation or 
> swft-corelibs-foundation. Is it implicitly bridged from ObjC somehow?
> 
> -Richard
> 
> ___
> 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 4 branch plans

[Tony Parker via swift-corelibs-dev]

Hi all,

We’re wrapping up Swift 4, and it’s past time for us to branch 
swift-corelibs-foundation for Swift 4 to match the rest of the projects. Here 
is my proposal:

Monday: stop auto-merging from master to Swift 4. master becomes Swift 4 update 
work.
After Monday: We are working on merging changes from macOS 10.13 / iOS 11.0 
into swift-corelibs-foundation. That will come after the branch point, to 
reduce risk of breaking stuff for Swift 4.

Thanks,
- Tony

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

Re: [swift-corelibs-dev] PR for better namespace support in XMLNode et al

[Tony Parker via swift-corelibs-dev]

Hi Robert,

I will take a quick look.

- Tony

> On Jul 11, 2017, at 10:01 AM, Robert Thompson via swift-corelibs-dev 
>  wrote:
> 
> Hey, I have a PR up that improves the XML namespace support in XMLNode and 
> friends: https://github.com/apple/swift-corelibs-foundation/pull/1052 
> . It’s been up 
> for about three weeks, was just hoping to prod a gentle reminder of it’s 
> existence :)
> 
> I originally contributed most of the XMLNode/XMLDocument/etc stuff in 
> swift-corelibs-foundation back in January 2016, and when I went to actually 
> use it for something myself (a personal project involving WebDAV), I was 
> horrified to find it crashed on almost anything involving namespaces. So 
> here’s the fix!
> 
> Thanks,
> Robert Thompson
> Software Engineer
> WillowTree, Inc.
> Charlottesville, VA
> ___
> 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] TimeZone database

[Tony Parker via swift-corelibs-dev]

No solution is imminent - we may need to come up with a more portable 
workaround.

- Tony

> On Jul 10, 2017, at 5:48 AM, Ian Partridge <i...@poncho.org.uk> wrote:
> 
> Just picking this up again.. is a solution imminent?  My hack is
> 
> diff --git a/CoreFoundation/NumberDate.subproj/CFTimeZone.c
> b/CoreFoundation/NumberDate.subproj/CFTimeZone.c
> index 434203ab43..86ab6ecb71 100644
> --- a/CoreFoundation/NumberDate.subproj/CFTimeZone.c
> +++ b/CoreFoundation/NumberDate.subproj/CFTimeZone.c
> @@ -33,6 +33,7 @@
> #endif
> #if DEPLOYMENT_TARGET_MACOSX || DEPLOYMENT_TARGET_EMBEDDED
> #include 
> +#define TZDIR"/usr/share/zoneinfo"
> #elif DEPLOYMENT_TARGET_LINUX || DEPLOYMENT_TARGET_FREEBSD
> #ifndef TZDIR
> #define TZDIR "/usr/share/zoneinfo" /* Time zone object file directory */
> 
> which gets the tests running again on Sierra but I guess breaks on High 
> Sierra.
> 
> Thanks,
> Ian
> 
> On 6 July 2017 at 16:28, Tony Parker <anthony.par...@apple.com> wrote:
>> Yes, we’re discussing this one internally too and trying to figure out what
>> the right answer is. Maybe the best solution for now is to find a good
>> mechanism to check the underlying version of the OS and split it out into a
>> function as you suggest.
>> 
>> - Tony
>> 
>> 
>> On Jul 6, 2017, at 7:37 AM, Ian Partridge via swift-corelibs-dev
>> <swift-corelibs-dev@swift.org> wrote:
>> 
>> Good shout Simon, you are right.  I'm on Sierra.  Compare and contrast:
>> 
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/tzfile.h
>> #define TZDIR   "/usr/share/zoneinfo"
>> 
>> /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/tzfile.h
>> #define TZDIR   "/var/db/timezone/zoneinfo"
>> 
>> so I guess if I installed the High Sierra beta it would work OK.
>> 
>> I hacked CF to force it to use /usr/share/zoneinfo and TestFoundation
>> is much happier, but that's not a solution.
>> 
>> On 6 July 2017 at 15:20, Simon Evans <s...@si.org> wrote:
>> 
>> Ian
>> 
>> I also saw this error, I think its because the TZDIR is different in the
>> headers shipped with Xcode 9. Maybe the location of the timezone directory
>> was moved between Sierra and High Sierra. What version of macOS are you
>> testing on?
>> 
>> If it has indeed moved between 10.12 and 10.13 it may require a runtime
>> version check to dynamically return TZDIR.
>> 
>> Simon
>> 
>> 
>> On 6 Jul 2017, at 15:09, Ian Partridge via swift-corelibs-dev
>> <swift-corelibs-dev@swift.org> wrote:
>> 
>> Hi,
>> 
>> I'm seeing quite a lot of tests failing when running the
>> TestFoundation target in Xcode.  The failures are timezone related.
>> Most simply, the code
>> 
>> let timeZone = TimeZone(abbreviation: "GMT")
>> 
>> is returning nil.
>> 
>> Walking through the CF code which sets things up, it seems to be
>> trying to read the timezone database from
>> /var/db/timezone/zoneinfo/zone.tab which doesn't exist on my macOS
>> system.
>> 
>> /usr/share/zoneinfo/zone.tab is there and seems to be the right
>> location (?), but CF is picking up TZDIR from tzfile.h which says:
>> 
>> #define TZDIR   "/var/db/timezone/zoneinfo"
>> 
>> Any thoughts?  I feel like I'm missing something obvious and have gone
>> too far down the rabbit hole.
>> 
>> --
>> Ian Partridge
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>> 
>> 
>> 
>> 
>> 
>> --
>> Ian Partridge
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>> 
>> 
> 
> 
> 
> -- 
> Ian Partridge
> 
> On 6 July 2017 at 16:31, Tony Parker via swift-corelibs-dev
> <swift-corelibs-dev@swift.org> wrote:
>> Yes, we’re discussing this one internally too and trying to figure out what
>> the right answer is. Maybe the best solution for now is to find a good
>> mechanism to check the underlying version of the OS and split it out into a
>> function as you suggest.
>> 
>> - Tony
>> 
>> 
>> On Jul 6, 2017, at 7:37 AM, Ian Partridge via swift-corelibs-dev
>> 

Re: [swift-corelibs-dev] TimeZone database

[Tony Parker via swift-corelibs-dev]

Yes, we’re discussing this one internally too and trying to figure out what the 
right answer is. Maybe the best solution for now is to find a good mechanism to 
check the underlying version of the OS and split it out into a function as you 
suggest.

- Tony

> On Jul 6, 2017, at 7:37 AM, Ian Partridge via swift-corelibs-dev 
>  wrote:
> 
> Good shout Simon, you are right.  I'm on Sierra.  Compare and contrast:
> 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/tzfile.h
> #define TZDIR   "/usr/share/zoneinfo"
> 
> /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/tzfile.h
> #define TZDIR   "/var/db/timezone/zoneinfo"
> 
> so I guess if I installed the High Sierra beta it would work OK.
> 
> I hacked CF to force it to use /usr/share/zoneinfo and TestFoundation
> is much happier, but that's not a solution.
> 
> On 6 July 2017 at 15:20, Simon Evans > wrote:
>> Ian
>> 
>> I also saw this error, I think its because the TZDIR is different in the 
>> headers shipped with Xcode 9. Maybe the location of the timezone directory 
>> was moved between Sierra and High Sierra. What version of macOS are you 
>> testing on?
>> 
>> If it has indeed moved between 10.12 and 10.13 it may require a runtime 
>> version check to dynamically return TZDIR.
>> 
>> Simon
>> 
>> 
>>> On 6 Jul 2017, at 15:09, Ian Partridge via swift-corelibs-dev 
>>>  wrote:
>>> 
>>> Hi,
>>> 
>>> I'm seeing quite a lot of tests failing when running the
>>> TestFoundation target in Xcode.  The failures are timezone related.
>>> Most simply, the code
>>> 
>>> let timeZone = TimeZone(abbreviation: "GMT")
>>> 
>>> is returning nil.
>>> 
>>> Walking through the CF code which sets things up, it seems to be
>>> trying to read the timezone database from
>>> /var/db/timezone/zoneinfo/zone.tab which doesn't exist on my macOS
>>> system.
>>> 
>>> /usr/share/zoneinfo/zone.tab is there and seems to be the right
>>> location (?), but CF is picking up TZDIR from tzfile.h which says:
>>> 
>>> #define TZDIR   "/var/db/timezone/zoneinfo"
>>> 
>>> Any thoughts?  I feel like I'm missing something obvious and have gone
>>> too far down the rabbit hole.
>>> 
>>> --
>>> Ian Partridge
>>> ___
>>> swift-corelibs-dev mailing list
>>> swift-corelibs-dev@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>> 
> 
> 
> 
> -- 
> Ian Partridge
> ___
> 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] TimeZone database

[Tony Parker via swift-corelibs-dev]

Is the path to zoneinfo different on the Ubuntu docker image?

- Tony

> On Jul 6, 2017, at 9:36 AM, Youming Lin <y...@us.ibm.com> wrote:
> 
> We were seeing this on Travis too. Specifically, on a Travis matrix build 
> using Swift 3.1.1 on a Ubuntu 16.04 docker image running inside a Travis 
> 14.04 VM.
> 
> The issue was specific to the Ubuntu 16.04 docker image; when I tested in 
> Ubuntu 16.04 OS as a guest VM, the issue went away.
> 
> Thanks,
> 
> Youming Lin
> IBM Cloud, Swift@IBM, Kitura developer
> Austin, TX
> GitHub: @youming-lin
> 
> Tony Parker via swift-corelibs-dev ---07/06/2017 10:31:15 
> AM---Yes, we’re discussing this one internally too and trying to figure out 
> what the right answer is. May
> 
> From: Tony Parker via swift-corelibs-dev <swift-corelibs-dev@swift.org>
> To: Ian Partridge <i...@poncho.org.uk>
> Cc: swift-corelibs-dev <swift-corelibs-dev@swift.org>
> Date: 07/06/2017 10:31 AM
> Subject: Re: [swift-corelibs-dev] TimeZone database
> Sent by: swift-corelibs-dev-boun...@swift.org
> 
> 
> 
> 
> Yes, we’re discussing this one internally too and trying to figure out what 
> the right answer is. Maybe the best solution for now is to find a good 
> mechanism to check the underlying version of the OS and split it out into a 
> function as you suggest.
> 
> - Tony
> On Jul 6, 2017, at 7:37 AM, Ian Partridge via swift-corelibs-dev 
> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
> 
> Good shout Simon, you are right. I'm on Sierra. Compare and contrast:
> 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/tzfile.h
> #define TZDIR "/usr/share/zoneinfo"
> 
> /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/tzfile.h
> #define TZDIR "/var/db/timezone/zoneinfo"
> 
> so I guess if I installed the High Sierra beta it would work OK.
> 
> I hacked CF to force it to use /usr/share/zoneinfo and TestFoundation
> is much happier, but that's not a solution.
> 
> On 6 July 2017 at 15:20, Simon Evans <s...@si.org <mailto:s...@si.org>> wrote:
> Ian
> 
> I also saw this error, I think its because the TZDIR is different in the 
> headers shipped with Xcode 9. Maybe the location of the timezone directory 
> was moved between Sierra and High Sierra. What version of macOS are you 
> testing on?
> 
> If it has indeed moved between 10.12 and 10.13 it may require a runtime 
> version check to dynamically return TZDIR.
> 
> Simon
> 
> On 6 Jul 2017, at 15:09, Ian Partridge via swift-corelibs-dev 
> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
> 
> Hi,
> 
> I'm seeing quite a lot of tests failing when running the
> TestFoundation target in Xcode. The failures are timezone related.
> Most simply, the code
> 
> let timeZone = TimeZone(abbreviation: "GMT")
> 
> is returning nil.
> 
> Walking through the CF code which sets things up, it seems to be
> trying to read the timezone database from
> /var/db/timezone/zoneinfo/zone.tab which doesn't exist on my macOS
> system.
> 
> /usr/share/zoneinfo/zone.tab is there and seems to be the right
> location (?), but CF is picking up TZDIR from tzfile.h which says:
> 
> #define TZDIR "/var/db/timezone/zoneinfo"
> 
> Any thoughts? I feel like I'm missing something obvious and have gone
> too far down the rabbit hole.
> 
> --
> Ian Partridge
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
> <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev>
> 
> 
> -- 
> Ian Partridge
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
> <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 
> <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] TimeZone database

[Tony Parker via swift-corelibs-dev]

Hm, good question - we do have our ‘bootstrap’ directory which includes some 
time zone headers, but those are the ones from unicode and not tzfile.h.

- Tony

> On Jul 6, 2017, at 11:42 AM, Alex Blewitt <alb...@apple.com> wrote:
> 
> It looks like it's /usr/share/zoneinfo on all Ubuntu versions:
> 
> alblue.local[~]$ docker run -it --rm ubuntu:14.04 find /usr -name zone.tab
> /usr/share/zoneinfo/zone.tab
> alblue.local[~]$ docker run -it --rm ubuntu:16.04 find /usr -name zone.tab
> /usr/share/zoneinfo/zone.tab
> alblue.local[~]$ docker run -it --rm ubuntu:16.10 find /usr -name zone.tab
> /usr/share/zoneinfo/zone.tab
> 
> This is the same that's coming from CFTimeZone.c:
> 
> https://github.com/apple/swift-corelibs-foundation/blob/2611dcd0d9b91fecace537838294bd85f0220503/CoreFoundation/NumberDate.subproj/CFTimeZone.c#L36-L39
>  
> <https://github.com/apple/swift-corelibs-foundation/blob/2611dcd0d9b91fecace537838294bd85f0220503/CoreFoundation/NumberDate.subproj/CFTimeZone.c#L36-L39>
> 
> Is it possible that the MacOS header is being included and defining TZDIR 
> before the CFTimeZone.c file is compiled?
> 
> Alex
> 
>> On 6 Jul 2017, at 19:22, Tony Parker via swift-corelibs-dev 
>> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> Is the path to zoneinfo different on the Ubuntu docker image?
>> 
>> - Tony
>> 
>>> On Jul 6, 2017, at 9:36 AM, Youming Lin <y...@us.ibm.com 
>>> <mailto:y...@us.ibm.com>> wrote:
>>> 
>>> We were seeing this on Travis too. Specifically, on a Travis matrix build 
>>> using Swift 3.1.1 on a Ubuntu 16.04 docker image running inside a Travis 
>>> 14.04 VM.
>>> 
>>> The issue was specific to the Ubuntu 16.04 docker image; when I tested in 
>>> Ubuntu 16.04 OS as a guest VM, the issue went away.
>>> 
>>> Thanks,
>>> 
>>> Youming Lin
>>> IBM Cloud, Swift@IBM, Kitura developer
>>> Austin, TX
>>> GitHub: @youming-lin
>>> 
>>> Tony Parker via swift-corelibs-dev ---07/06/2017 10:31:15 
>>> AM---Yes, we’re discussing this one internally too and trying to figure out 
>>> what the right answer is. May
>>> 
>>> From: Tony Parker via swift-corelibs-dev <swift-corelibs-dev@swift.org 
>>> <mailto:swift-corelibs-dev@swift.org>>
>>> To: Ian Partridge <i...@poncho.org.uk <mailto:i...@poncho.org.uk>>
>>> Cc: swift-corelibs-dev <swift-corelibs-dev@swift.org 
>>> <mailto:swift-corelibs-dev@swift.org>>
>>> Date: 07/06/2017 10:31 AM
>>> Subject: Re: [swift-corelibs-dev] TimeZone database
>>> Sent by: swift-corelibs-dev-boun...@swift.org 
>>> <mailto:swift-corelibs-dev-boun...@swift.org>
>>> 
>>> 
>>> 
>>> Yes, we’re discussing this one internally too and trying to figure out what 
>>> the right answer is. Maybe the best solution for now is to find a good 
>>> mechanism to check the underlying version of the OS and split it out into a 
>>> function as you suggest.
>>> 
>>> - Tony
>>> On Jul 6, 2017, at 7:37 AM, Ian Partridge via swift-corelibs-dev 
>>> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
>>> 
>>> Good shout Simon, you are right. I'm on Sierra. Compare and contrast:
>>> 
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/tzfile.h
>>> #define TZDIR "/usr/share/zoneinfo"
>>> 
>>> /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/tzfile.h
>>> #define TZDIR "/var/db/timezone/zoneinfo"
>>> 
>>> so I guess if I installed the High Sierra beta it would work OK.
>>> 
>>> I hacked CF to force it to use /usr/share/zoneinfo and TestFoundation
>>> is much happier, but that's not a solution.
>>> 
>>> On 6 July 2017 at 15:20, Simon Evans <s...@si.org <mailto:s...@si.org>> 
>>> wrote:
>>> Ian
>>> 
>>> I also saw this error, I think its because the TZDIR is different in the 
>>> headers shipped with Xcode 9. Maybe the location of the timezone directory 
>>> was moved between Sierra and High Sierra. What version of macOS are you 
>>> testing on?
>>> 
>>> If it has indeed moved between 10.12 and 10.13 it may require a runtime 
>>> version check to dynamically return TZDIR.
>>> 
>>> Simon
>>>

Re: [swift-corelibs-dev] TimeZone database

[Tony Parker via swift-corelibs-dev]

We have a list of required packages in our README.md - we could add tzdata to 
that.

- Tony

> On Jul 6, 2017, at 1:48 PM, Youming Lin via swift-corelibs-dev 
> <swift-corelibs-dev@swift.org> wrote:
> 
> Thanks for pointing me to the package. Turns out it was intentional:
> https://github.com/docker-library/official-images/issues/2863 
> <https://github.com/docker-library/official-images/issues/2863>
> 
> A caveat to Swift developers using official Docker Ubuntu images in the 
> future.
> 
> Youming Lin
> IBM Cloud, Swift@IBM, Kitura developer
> Austin, TX
> GitHub: @youming-lin
> 
> Simon Evans ---07/06/2017 03:20:57 PM---Looks like timezone 
> files are in the ‘tzdata’ package. Maybe it got uninstalled or was never 
> install
> 
> From: Simon Evans <s...@si.org>
> To: Youming Lin <y...@us.ibm.com>
> Cc: Alex Blewitt <alb...@apple.com>, Ian Partridge <i...@poncho.org.uk>, 
> swift-corelibs-dev <swift-corelibs-dev@swift.org>
> Date: 07/06/2017 03:20 PM
> Subject: Re: [swift-corelibs-dev] TimeZone database
> 
> 
> 
> 
> Looks like timezone files are in the ‘tzdata’ package. Maybe it got 
> uninstalled or was never installed as part of the base. An ‘apt-get install 
> tzdata’ might fix it.
> 
> Simon
> On 6 Jul 2017, at 20:20, Youming Lin via swift-corelibs-dev 
> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
> That's odd. Maybe my ubuntu:16.04 image is outdated or something, but here 
> are my outputs:
> 
> ylin@youming-mbpr:~/Swift/Kitura-Markdown$ docker run -it --rm ubuntu:16.04 
> find /usr -name zone.tab
> ylin@youming-mbpr:~/Swift/Kitura-Markdown$ docker run -it --rm ubuntu:14.04 
> find /usr -name zone.tab
> /usr/share/zoneinfo/zone.tab
> 
> The file is found in ubuntu:14.04 but not in ubuntu:16.04.
> 
> Here are my images:
> 
> ylin@youming-mbpr:~/Swift/Kitura-Markdown$ docker images
> REPOSITORY TAG IMAGE ID CREATED SIZE
> ubuntu 16.04 7b9b13f7b9c0 4 weeks ago 118MB
> ubuntu 14.04 132b7427a3b4 4 weeks ago 188MB
> 
> Thanks,
> 
> Youming Lin
> IBM Cloud, Swift@IBM, Kitura developer
> Austin, TX
> GitHub: @youming-lin
> 
> Alex Blewitt ---07/06/2017 01:42:22 PM---It looks like it's 
> /usr/share/zoneinfo on all Ubuntu versions: alblue.local[~]$ docker run -it 
> --rm
> 
> From: Alex Blewitt <alb...@apple.com <mailto:alb...@apple.com>>
> To: Tony Parker <anthony.par...@apple.com <mailto:anthony.par...@apple.com>>
> Cc: Youming Lin <y...@us.ibm.com <mailto:y...@us.ibm.com>>, Ian Partridge 
> <i...@poncho.org.uk <mailto:i...@poncho.org.uk>>, swift-corelibs-dev 
> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>>
> Date: 07/06/2017 01:42 PM
> Subject: Re: [swift-corelibs-dev] TimeZone database
> Sent by: alb...@apple.com <mailto:alb...@apple.com>
> 
> 
> 
> 
> It looks like it's /usr/share/zoneinfo on all Ubuntu versions:
> 
> alblue.local[~]$ docker run -it --rm ubuntu:14.04 find /usr -name zone.tab
> /usr/share/zoneinfo/zone.tab
> alblue.local[~]$ docker run -it --rm ubuntu:16.04 find /usr -name zone.tab
> /usr/share/zoneinfo/zone.tab
> alblue.local[~]$ docker run -it --rm ubuntu:16.10 find /usr -name zone.tab
> /usr/share/zoneinfo/zone.tab
> 
> This is the same that's coming from CFTimeZone.c:
> 
> https://github.com/apple/swift-corelibs-foundation/blob/2611dcd0d9b91fecace537838294bd85f0220503/CoreFoundation/NumberDate.subproj/CFTimeZone.c#L36-L39
>  
> <https://github.com/apple/swift-corelibs-foundation/blob/2611dcd0d9b91fecace537838294bd85f0220503/CoreFoundation/NumberDate.subproj/CFTimeZone.c#L36-L39>
> 
> Is it possible that the MacOS header is being included and defining TZDIR 
> before the CFTimeZone.c file is compiled?
> 
> Alex
> On 6 Jul 2017, at 19:22, Tony Parker via swift-corelibs-dev 
> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
> 
> Is the path to zoneinfo different on the Ubuntu docker image?
> 
> - Tony
> On Jul 6, 2017, at 9:36 AM, Youming Lin <y...@us.ibm.com 
> <mailto:y...@us.ibm.com>> wrote:
> We were seeing this on Travis too. Specifically, on a Travis matrix build 
> using Swift 3.1.1 on a Ubuntu 16.04 docker image running inside a Travis 
> 14.04 VM.
> 
> The issue was specific to the Ubuntu 16.04 docker image; when I tested in 
> Ubuntu 16.04 OS as a guest VM, the issue went away.
> 
> Thanks,
> 
> Youming Lin
> IBM Cloud, Swift@IBM, Kitura developer
> Austin, TX
> GitHub: @youming-lin
> 
> Tony Parker via swift-corelibs-dev ---07/06/2017 10:31:15 
> AM---Yes, we’re discussing this one intern

Re: [swift-corelibs-dev] Unavailability macros for APIs that aren't going to be implemented on Linux?

[Tony Parker via swift-corelibs-dev]

This sounds like a good plan to me. We’ll have to discuss the specifics of what 
is marked unavailable this way, probably best via code review.

I think we had more hope for some of the more-dynamic methods (e.g. 
NSSortDescriptor, NSExpression), but it does seem clear at this point that the 
current API is unsuitable for Swift in various ways.

- Tony

> On Jul 28, 2017, at 7:27 AM, Ian Partridge via swift-corelibs-dev 
>  wrote:
> 
> Hi Al, thanks for bringing this up.
> 
> My view is that we shouldn't have API in the project which is never going to 
> be implemented.  The contents of swift-corelibs-foundation should represent a 
> baseline of fundamental types and functionality which is useful to all 
> applications and can be implemented on a broad range of platforms and 
> operating systems.
> 
> I think it is more useful to developers who are porting their Swift 
> applications to other platforms if they are faced with a helpful message when 
> their app attempts to use unavailable API, rather than just "ERROR: type 
> 'NSWhatever' has no member 'foo'" - so I like your idea of using @available 
> annotations to guide people.
> 
> Once Swift 4 is out of the door, I think we should do a review of the 
> codebase and decide which of the remaining NSUnimplemented() are really 
> NSProbablyNever().
> 
> This will also help new contributors to swift-corelibs-foundation as they 
> will be able to be confident that every NSUnimplemented() is a genuine 
> opportunity to contribute.
> 
> Regards,
> Ian Partridge
> 
> On 28 July 2017 at 15:07, Alex Blewitt via swift-corelibs-dev 
> > wrote:
> I've pushed a change which will add an unavailability warning for a method 
> which was deprecated at the point of being added to Swift, has never worked, 
> and likely never will:
> 
> https://github.com/apple/swift-corelibs-foundation/pull/1140 
> 
> 
> There are some other types in Foundation which aren't likely to ever be 
> implementable in Swift on Linux; Bundle.unload, NSPort/PortMessage, copy(with 
> zone) etc. The majority of these methods use NSUnimplemented(), which means 
> there are often unannounced runtime errors that you can get from something 
> that compiled correctly.
> 
> I'd like to suggest that we attempt to resolve this problem, either by 
> removing the features whihc are never going to be implemented (e.g. by 
> commenting out the calls) or by marking them as @available(*,unavailable, 
> message:"Not available on the Linux platform"). That way, calls that are 
> known cannot work can be identified at compile time instead of at run-time.
> 
> I hope we'll then be able to remove the NSUnimplemented calls on the types 
> that can never be implemented, so that we can focus on those types and 
> functions that we can. Alternatively we can define a different macro, say 
> NSUnavailableOnLinux, to indicate that this functionality cannot be present 
> (as opposed to just leaving it blank).
> 
> What do you think?
> 
> $ git grep -c NSUnimplemented | sort -n -r -k2 -t:
> Foundation/NSExpression.swift:37
> Foundation/NSURLCache.swift:22
> Foundation/FileManager.swift:22
> Foundation/NSPort.swift:21
> Foundation/NSOrderedSet.swift:20
> Foundation/NSSortDescriptor.swift:19
> ...
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
> 
> 
> 
> 
> 
> -- 
> Ian Partridge
> ___
> 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] NSString.range(of:options:range:locale) incompatibility

[Tony Parker via swift-corelibs-dev]

Hi Ian,

I don’t think Max has put up that PR against the swift-corelibs-foundation 
implementation, but we should.

- Tony

> On Aug 9, 2017, at 9:04 AM, Ian Partridge via swift-corelibs-dev 
>  wrote:
> 
> I've noticed this current difference in behaviour.
> 
> Darwin:
> 
> $ swift
> Welcome to Apple Swift version 4.0-dev (LLVM 2dedb62a0b, Clang b9d76a314c, 
> Swift 6b4756bd93). Type :help for assistance.
>   1> import Foundation
>   2> "abc".range(of: "a")!.lowerBound..<"abc".range(of: "a")!.upperBound
> $R0: Range = {
>   lowerBound = {
> _compoundOffset = 0
> _cache = utf16
>   }
>   upperBound = {
> _compoundOffset = 4
> _cache = utf16
>   }
> }
> 
> Linux:
> 
> $ swift
> Welcome to Swift version 4.0-dev (LLVM 2dedb62a0b, Clang b9d76a314c, Swift 
> 6b4756bd93). Type :help for assistance.
>   1> import Foundation 
>   2> "abc".range(of: "a")!.lowerBound..<"abc".range(of: "a")!.upperBound 
> $R0: CountableRange = {
>   lowerBound = {
> _compoundOffset = 0
> _cache = utf16
>   }
>   upperBound = {
> _compoundOffset = 4
> _cache = utf16
>   }
> }
> 
> I think this might be because some changes made in the overlay 
> (NSStringAPI.swift) haven't been ported across to swift-corelibs-foundation:
> 
> https://github.com/apple/swift/commit/5f1c3f702189f8197e297479d464dc454330be80
>  
> 
> 
> Is my suspicion right, and is there any work in progress to bring this into 
> sync before Swift 4?
> 
> -- 
> Ian Partridge
> ___
> 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] Bring NSString functions to String

[Tony Parker via swift-corelibs-dev]

> On May 10, 2017, at 4:19 AM, Andrey Fidrya via swift-corelibs-dev 
>  wrote:
> 
> Hi All,
> 
> Btw, when migrating from NSString's methods to URL I've noticed
> that they work a bit differently: URL's methods convert strings
> from NFC to NFD (decomposed) unicode form which is demonstrated
> by the example below.
> 
> I had to additionally call .precomposedStringWithCanonicalMapping
> on resulting string to convert it back to NFC form.
> 
> This was very surprising as it wasn't mentioned anywhere in docs
> and has broken non-english filename support in app.

Out of curiosity, can you explain how this breaks your non-english filename 
support? What OS and filesystem are you using?

- Tony

> Is this expected behavior or a bug?
> 
> //let source = "/my_file.txt"
> let source = "/мой_файл.txt" // problematic is letter 'й'
> 
> let disallowedCharacters = CharacterSet(charactersIn: source).inverted
> 
> 
> do {
> print("--- NSString:")
> let result = (source as NSString).deletingPathExtension as String
> print(result)
> print(result.rangeOfCharacter(from: disallowedCharacters))
> 
> }
> 
> do {
> print("--- String + URL:")
> let result = URL(fileURLWithPath: source).deletingPathExtension().path
> print(result)
> print(result.rangeOfCharacter(from: disallowedCharacters))
> print(result.precomposedStringWithCanonicalMapping.rangeOfCharacter(from: 
> disallowedCharacters))
> }
> 
> 
> --- Output:
> 
> --- NSString:
> /мой_файл
> nil
> --- String + URL:
> /мой_файл
> Optional(Range(Swift.String.CharacterView.Index(_base: 
> Swift.String.UnicodeScalarView.Index(_position: 3), _countUTF16: 
> 2).. Swift.String.UnicodeScalarView.Index(_position: 4), _countUTF16: 1)))
> nil
> 
> 
> Regards,
> Andrey
> 
>> On 10 May 2017, at 12:45, Eric Blachère via swift-corelibs-dev 
>> > wrote:
>> 
>> Thanks for the answer ! It seems a bit weird from them to advocate using 
>> NSString methods in the unavailability comment. I would rather use URL when 
>> I can even if the conversions are a bit tedious ^^
>> 
>> Thanks a lot,
>> Eric
>> 
>> 2017-05-10 10:52 GMT+02:00 Brent Royal-Gordon > >:
>> > On May 8, 2017, at 9:39 AM, Eric Blachère via swift-corelibs-dev 
>> > > wrote:
>> >
>> > I was just wondering if there are plans to bring NSString functions 
>> > manipulating paths into the native String class. (such as 
>> > lastPathComponent, pathComponents etc...)
>> > Because even if we can always make an extension of String to easily cast 
>> > it into NSString, it's still a bit of a shame to have to do it ;)
>> 
>> Unfortunately, it seems like the decision not to include these methods on 
>> String was quite deliberate.
>> 
>> Here's the revision where that happened: 
>> >  
>> >
>>  As you can see, they had that working and chose to disable it, presumably 
>> because they want you to manipulate paths through `URL`. (I wish the radar 
>> referenced in the commit message were public, but alas, it's not.)
>> 
>> --
>> Brent Royal-Gordon
>> Architechies
>> 
>> 
>> ___
>> 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] Bring NSString functions to String

[Tony Parker via swift-corelibs-dev]

> On May 11, 2017, at 5:17 PM, Andrey Fidrya  wrote:
> 
>> 
>> On 12 May 2017, at 00:05, Tony Parker > > wrote:
>> 
>>> On May 10, 2017, at 4:19 AM, Andrey Fidrya via swift-corelibs-dev 
>>> > wrote:
>>> 
>>> Hi All,
>>> 
>>> Btw, when migrating from NSString's methods to URL I've noticed
>>> that they work a bit differently: URL's methods convert strings
>>> from NFC to NFD (decomposed) unicode form which is demonstrated
>>> by the example below.
>>> 
>>> I had to additionally call .precomposedStringWithCanonicalMapping
>>> on resulting string to convert it back to NFC form.
>>> 
>>> This was very surprising as it wasn't mentioned anywhere in docs
>>> and has broken non-english filename support in app.
>> 
>> Out of curiosity, can you explain how this breaks your non-english filename 
>> support? What OS and filesystem are you using?
> 
> OS X, HFS+. The app reconstructed account names from filenames by dropping 
> file extensions. The filename was converted to NFC form once then NSString's 
> methods were used for manipulating the filename. These methods weren't 
> denormalizing the string. After switching to URL the resulting account names 
> started triggering warnings about invalid characters in them ('й' should have 
> been a valid character, but after denormalizing it was no longer found).
> 
> - Andrey

Thanks Andrey. Since this is on Mac, I filed a bug for you in our internal 
system to follow up on this (32156825).

- Tony

> 
>> 
>> - Tony
>> 
>>> Is this expected behavior or a bug?
>>> 
>>> //let source = "/my_file.txt"
>>> let source = "/мой_файл.txt" // problematic is letter 'й'
>>> 
>>> let disallowedCharacters = CharacterSet(charactersIn: source).inverted
>>> 
>>> 
>>> do {
>>> print("--- NSString:")
>>> let result = (source as NSString).deletingPathExtension as String
>>> print(result)
>>> print(result.rangeOfCharacter(from: disallowedCharacters))
>>> 
>>> }
>>> 
>>> do {
>>> print("--- String + URL:")
>>> let result = URL(fileURLWithPath: source).deletingPathExtension().path
>>> print(result)
>>> print(result.rangeOfCharacter(from: disallowedCharacters))
>>> 
>>> print(result.precomposedStringWithCanonicalMapping.rangeOfCharacter(from: 
>>> disallowedCharacters))
>>> }
>>> 
>>> 
>>> --- Output:
>>> 
>>> --- NSString:
>>> /мой_файл
>>> nil
>>> --- String + URL:
>>> /мой_файл
>>> Optional(Range(Swift.String.CharacterView.Index(_base: 
>>> Swift.String.UnicodeScalarView.Index(_position: 3), _countUTF16: 
>>> 2)..>> Swift.String.UnicodeScalarView.Index(_position: 4), _countUTF16: 1)))
>>> nil
>>> 
>>> 
>>> Regards,
>>> Andrey
>>> 
 On 10 May 2017, at 12:45, Eric Blachère via swift-corelibs-dev 
 > wrote:
 
 Thanks for the answer ! It seems a bit weird from them to advocate using 
 NSString methods in the unavailability comment. I would rather use URL 
 when I can even if the conversions are a bit tedious ^^
 
 Thanks a lot,
 Eric
 
 2017-05-10 10:52 GMT+02:00 Brent Royal-Gordon >:
 > On May 8, 2017, at 9:39 AM, Eric Blachère via swift-corelibs-dev 
 > > 
 > wrote:
 >
 > I was just wondering if there are plans to bring NSString functions 
 > manipulating paths into the native String class. (such as 
 > lastPathComponent, pathComponents etc...)
 > Because even if we can always make an extension of String to easily cast 
 > it into NSString, it's still a bit of a shame to have to do it ;)
 
 Unfortunately, it seems like the decision not to include these methods on 
 String was quite deliberate.
 
 Here's the revision where that happened: 
 >
  As you can see, they had that working and chose to disable it, presumably 
 because they want you to manipulate paths through `URL`. (I wish the radar 
 referenced in the commit message were public, but alas, it's not.)
 
 --
 Brent Royal-Gordon
 Architechies
 
 
 ___
 swift-corelibs-dev mailing list
 swift-corelibs-dev@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
 
>>> 
>>> ___
>>> swift-corelibs-dev mailing list
>>> 

Re: [swift-corelibs-dev] Foundation: NSString init detect encoding

[Tony Parker via swift-corelibs-dev]

Someone on the team here just reminded me that we do have a very basic form of 
encoding detection here as well: just looking for the BOM at the beginning of 
the data.

- Tony

> On Jun 21, 2017, at 9:55 AM, Tony Parker via swift-corelibs-dev 
> <swift-corelibs-dev@swift.org> wrote:
> 
> Our preferred approach so far is to mirror Foundation as closely as possible.
> 
> I don’t know if we want to implement stringEncodingForData as part of 
> swift-corelibs-foundation. In any case, we are trying to avoid bringing in as 
> few dependencies outside of the Swift project itself as possible, to keep 
> Foundation as low level as possible for stability, ease of use, and ease of 
> portability.
> 
> - Tony
> 
>> On Jun 21, 2017, at 9:51 AM, Andy Best <andybest@gmail.com 
>> <mailto:andybest@gmail.com>> wrote:
>> 
>> Is the preferred approach to mirror Foundation as closely as possible (e.g. 
>> under Linux basically do nothing), or is implementing something like 
>> stringEncodingForData under the hood preferable in this case?
>> 
>> On 21 June 2017 at 17:43, Tony Parker <anthony.par...@apple.com 
>> <mailto:anthony.par...@apple.com>> wrote:
>> Hi Andy,
>> 
>> 
>>> On Jun 21, 2017, at 7:39 AM, Andy Best via swift-corelibs-dev 
>>> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
>>> 
>>> Hey,
>>> 
>>> I've been looking at the init(contentsOfFile, usedEncoding) initializer for 
>>> NSString in corelibs-foundation.
>>> 
>>> Am I right in thinking that this method should use some method to attempt 
>>> to detect the character encoding of the file before returning a decoded 
>>> String?
>> 
>> In this case, the Foundation implementation just looks at an extended 
>> attribute of the file to see if it contains the encoding. If it doesn’t have 
>> the xattr then we don’t attempt to guess (name of xattr is 
>> “com.apple.TextEncoding”).
>> 
>> Foundation has another API which attempts to guess the encoding of a data 
>> blob, but I think we left it out of the swift-corelibs stubs:
>> 
>> + (NSStringEncoding)stringEncodingForData:(NSData *)data
>>   encodingOptions:(nullable 
>> NSDictionary<NSStringEncodingDetectionOptionsKey, id> *)opts
>>   convertedString:(NSString * _Nullable * 
>> _Nullable)string
>>   usedLossyConversion:(nullable BOOL 
>> *)usedLossyConversion API_AVAILABLE(macos(10.10), ios(8.0), watchos(2.0), 
>> tvos(9.0));
>> 
>> - Tony
>> 
>>> 
>>> If so, I've been working on a pure Swift library to detect string 
>>> encodings, and wondered if continued work on it might be useful for 
>>> implementing this missing method?
>>> 
>>> Andy
>>> ___
>>> swift-corelibs-dev mailing list
>>> swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>>> <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] Build failure and differences between test and build

[Tony Parker via swift-corelibs-dev]

> On Jun 21, 2017, at 6:30 AM, Alex Blewitt via swift-corelibs-dev 
>  wrote:
> 
> We had a test failure on swift-corelibs-foundation recently on master, which 
> was related to this pull request being merged by me:
> 
> https://github.com/apple/swift-corelibs-foundation/pull/1043 
> 
> 
> The automated tests passed, but after being committed to master, they then 
> failed. I subsequently rolled them back with this pull request:
> 
> https://github.com/apple/swift-corelibs-foundation/pull/1056 
> 
> 
> A few interim builds have failed; if you see messages like failing to compare 
> metric and imperial measurements, that could have been caused by this. 
> Rebasing and redoing such test failures should fix the issues.
> 
> It's a bit concerning that the test case failed after merge but passed in the 
> pull request test. Is this expected?

I’m not 100% sure that our test cases are being run against a clean build, 
which has been the root of some confusion like this in the past.

- Tony

> 
> Alex
> Test Case 'TestNSLengthFormatter.test_stringFromMetersMetric' started at 
> 2017-06-21 10:16:31.688
> TestFoundation/TestNSLengthFormatter.swift:71: error: 
> TestNSLengthFormatter.test_stringFromMetersMetric : XCTAssertEqual failed: 
> ("-6.214 mi") is not equal to ("-10 km") - 
> TestFoundation/TestNSLengthFormatter.swift:72: error: 
> TestNSLengthFormatter.test_stringFromMetersMetric : XCTAssertEqual failed: 
> ("-0.001 mi") is not equal to ("-0.001 km") - 
> TestFoundation/TestNSLengthFormatter.swift:73: error: 
> TestNSLengthFormatter.test_stringFromMetersMetric : XCTAssertEqual failed: 
> ("0 in") is not equal to ("0.01 mm") - 
> ___
> 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] Foundation: NSString init detect encoding

[Tony Parker via swift-corelibs-dev]

Hi Andy,


> On Jun 21, 2017, at 7:39 AM, Andy Best via swift-corelibs-dev 
>  wrote:
> 
> Hey,
> 
> I've been looking at the init(contentsOfFile, usedEncoding) initializer for 
> NSString in corelibs-foundation.
> 
> Am I right in thinking that this method should use some method to attempt to 
> detect the character encoding of the file before returning a decoded String?

In this case, the Foundation implementation just looks at an extended attribute 
of the file to see if it contains the encoding. If it doesn’t have the xattr 
then we don’t attempt to guess (name of xattr is “com.apple.TextEncoding”).

Foundation has another API which attempts to guess the encoding of a data blob, 
but I think we left it out of the swift-corelibs stubs:

+ (NSStringEncoding)stringEncodingForData:(NSData *)data
  encodingOptions:(nullable 
NSDictionary *)opts
  convertedString:(NSString * _Nullable * 
_Nullable)string
  usedLossyConversion:(nullable BOOL *)usedLossyConversion 
API_AVAILABLE(macos(10.10), ios(8.0), watchos(2.0), tvos(9.0));

- Tony

> 
> If so, I've been working on a pure Swift library to detect string encodings, 
> and wondered if continued work on it might be useful for implementing this 
> missing method?
> 
> Andy
> ___
> 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] Swift Encoders on Linux

[Tony Parker via swift-corelibs-dev]

Hi Ankit,

Our intention is to share as much of the implementation as possible. There are 
some details that need to be worked out around bridging of types like NSNumber 
(since bridging doesn't exist on Linux we may need to avoid using 'as' in a few 
places), but in general it could be as easy as copying the files from the 
Foundation overlay on Darwin into the other project.

We've been focused on getting the last details in place so haven't been able to 
pursue the rest of this ourselves. If anyone wanted to step up and help us out 
here, it would be awesome to ship the feature concurrently on Linux. 

- Tony

> On May 23, 2017, at 1:11 AM, Ankit Aggarwal via swift-corelibs-dev 
>  wrote:
> 
> Hi,
> 
> It looks like SE-0167 is implemented and can be used in the latest macOS 
> snapshot (yay!). Will corelibs-foundation need a completely separate 
> implementation? Is the corelibs-foundation implementation going to be 
> community driven?
> 
> PS: I think these are awesome APIs and the Package Manager will really 
> benefit from SE-0166, SE-0167.
> ___
> 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] Debugging failures seen only in CI

[Tony Parker via swift-corelibs-dev]

I'm ok with that if it helps us get to the bottom of this once and for all. 

I wonder if it would be possible to enable the logging conditionally, so it 
only appears in CI? Maybe via a runtime call ("turn logging on now"). 

- Tony

> On May 23, 2017, at 2:25 AM, Pushkar N Kulkarni  wrote:
> 
> Hi Tony, 
> 
> In this context, would it be acceptable if we add (temporarily) some 
> diagnostic prints to TestNSURLSession to log information only on failures?  
> 
> Pushkar N Kulkarni,
> IBM Runtimes
> 
> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
> 
> 
> 
> -Pushkar N Kulkarni/India/IBM wrote: -
> To: swift-...@swift.org, swift-corelibs-dev@swift.org
> From: Pushkar N Kulkarni/India/IBM
> Date: 05/19/2017 01:24AM
> Subject: Debugging failures seen only in CI
> 
> Over the past few months, we've seen random and intermittent failures in the 
> URLSession tests in TestFoundation in the CI builds running on Ubuntu 16.04. 
> Surprisingly, these failures never occur on PR builds. We've tried to 
> reproduce them locally (on matching Ubuntu levels) and fixed locally observed 
> issues, assuming those were the issues that broke the CI. 
> 
> However, the tests continue to intermittently fail in the CI and we seemed to 
> have reached a point where we simply aren't able to reproduce these failures 
> locally - we tried 2/4/16CPU with 8G/16G memory running Ubuntu 16.04 on bare 
> metal. Even if we are able to reproduce, as is in the case of a segfault, 
> there's no way to ascertain that the local failures have the same causes (e.g 
> backtrace for a segfault) as the ones in the CI. 
> 
> I have two questions in this context:
> 1. Is there a way to collect failure data from the CI environment - core 
> dumps on a crash or thread stacks on a timeout (I don't think XCTest helps) ? 
> 2. Is there a way to obtain more information about the environment - is it 
> virtualised, # of CPU cores, memory size, CPU/memory available for each 
> build, what's the load (CPU/memory utilisation)? 
> 
> In general, I'd be really helpful to have some suggestions about how to go 
> about debugging failures that are being observed ONLY in the CI.
> 
> Thanks!
> Pushkar N Kulkarni,
> IBM Runtimes
> 
> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
> 
> 
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] [swift-dev] Swift Encoders on Linux

[Tony Parker via swift-corelibs-dev]

Hi David,

I think the struct Measurement should probably be very similar, but the class 
NSMeasurement is probably pretty different.

Regardless, if there is something you think needs to be ported over (I would 
believe that there are a few changes made there that we haven’t copied yet), 
please do put up a PR.

Thanks,
- Tony

> On May 23, 2017, at 1:04 PM, David Hart  wrote:
> 
> Hi Tony,
> 
> Looking forward to all this on Linux!
> 
> On the same topic, I looked at the Measurement Swift type and did a diff 
> between the shims in the swift repo and the version in corelibs-foundation 
> and saw quite a few differences. Is this something that can be improved or it 
> is a consequence of the platform differences?
> 
> Thanks,
> David.
> 
>> On 23 May 2017, at 17:14, Tony Parker via swift-dev  
>> wrote:
>> 
>> Hi Ankit,
>> 
>> Our intention is to share as much of the implementation as possible. There 
>> are some details that need to be worked out around bridging of types like 
>> NSNumber (since bridging doesn't exist on Linux we may need to avoid using 
>> 'as' in a few places), but in general it could be as easy as copying the 
>> files from the Foundation overlay on Darwin into the other project.
>> 
>> We've been focused on getting the last details in place so haven't been able 
>> to pursue the rest of this ourselves. If anyone wanted to step up and help 
>> us out here, it would be awesome to ship the feature concurrently on Linux. 
>> 
>> - Tony
>> 
>>> On May 23, 2017, at 1:11 AM, Ankit Aggarwal via swift-corelibs-dev 
>>>  wrote:
>>> 
>>> Hi,
>>> 
>>> It looks like SE-0167 is implemented and can be used in the latest macOS 
>>> snapshot (yay!). Will corelibs-foundation need a completely separate 
>>> implementation? Is the corelibs-foundation implementation going to be 
>>> community driven?
>>> 
>>> PS: I think these are awesome APIs and the Package Manager will really 
>>> benefit from SE-0166, SE-0167.
>>> ___
>>> swift-corelibs-dev mailing list
>>> swift-corelibs-dev@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>> ___
>> swift-dev mailing list
>> swift-...@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-dev
> 

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

Re: [swift-corelibs-dev] Unable to build swift-corelibs-foundation in XCode 8.3.2

[Tony Parker via swift-corelibs-dev]

Hi everyone,

I’m hoping to merge these early next week.

- Tony

> On Jun 2, 2017, at 4:51 AM, Simon Evans via swift-corelibs-dev 
>  wrote:
> 
> Yes I was also seeing this issue, the Xcode project needs the swift-version 3 
> set and some files were moved around during a URLSession change
> 
> See if these 2 PRs fix it for you, they worked for me
> 
> https://github.com/apple/swift-corelibs-foundation/pull/1017
> https://github.com/apple/swift-corelibs-foundation/pull/1006
> 
> 
> si
> 
>> On 2 Jun 2017, at 12:08, Sai Kanduri via swift-corelibs-dev 
>>  wrote:
>> 
>> Hi All,
>> 
>> Latest Foundation code with XCode 8.3.2 does not compile successfully for 
>> me. Is anyone else also seeing this ?
>> 
>> -Sai Hema
>> 
>> ___
>> 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] Adding type conversion capabilities to JSON encode/decode

[Tony Parker via swift-corelibs-dev]

I haven’t tried this myself yet, but you could imagine creating a type which 
represents an ABV and decodes using a single value container. Then, your custom 
behavior goes into the Codable implementation of this ABV type.

Struct Beer then looks like:

struct Beer: Codable {
let name: String
let abv: ABV
…
}

ABV can have API on it to get the numeric value or String value; or that could 
go into Beer and it would abstract the ABV type from callers.

- Tony

> On Aug 30, 2017, at 2:42 PM, Sneed, Brandon  wrote:
> 
> Thanks Youming,
>  
> That’s not quite what I meant.  I may have misinterpreted what Tony was 
> saying though.
>  
> I wanted to do conversion on String, not the containing type.  The problem of 
> doing it on the containing type is that as soon as you need one field to be 
> custom, you’re roped into handling all the others.  For a small struct, not a 
> big deal, for larger ones, it is.  Something like this is what I tried:
>  
> import Cocoa
>  
> let jsonString = "{" +
> "\"name\": \"Endeavor\"," +
> "\"abv\": 8.9," +
> "\"brewery\": \"Saint Arnold\"," +
> "\"style\": \"ipa\"}"
>  
> struct Beer: Codable {
> let name: String
> let abv: String
> let brewery: String
> let style: String
> }
>  
> extension String {
> init(from decoder: Decoder) throws {
> print("i got hit.")
> let value = try decoder.singleValueContainer().decode(String.self)
> self.init(value)
> }
> }
>  
> let jsonData = jsonString.data(using: .utf8)
> let decoder = JSONDecoder()
> let beer = try! decoder.decode(Beer.self, from: jsonData!)
>  
> fatal error: 'try!' expression unexpectedly raised an error: 
> Swift.DecodingError.typeMismatch(Swift.String, 
> Swift.DecodingError.Context(codingPath: [__lldb_expr_17.Beer.(CodingKeys in 
> _C8902E33F84CE6946081129DAF1824E1).abv], debugDescription: "Expected to 
> decode String but found a number instead.", underlyingError: nil)): file 
> /Library/Caches/com.apple.xbs/Sources/swiftlang/swiftlang-900.0.59/src/swift/stdlib/public/core/ErrorType.swift,
>  line 181
>  
>  
>  
> From: Youming Lin >
> Date: Wednesday, August 30, 2017 at 2:35 PM
> To: "Sneed, Brandon" >
> Cc: Tony Parker >, 
> "swift-corelibs-dev@swift.org " 
> >, 
> "swift-corelibs-dev-boun...@swift.org 
> " 
>  >
> Subject: Re: [swift-corelibs-dev] Adding type conversion capabilities to JSON 
> encode/decode
>  
> Brandon
> 
> I cooked up a simple example and it works as expected.
> 
> ylin@youming-mbpr:~/Swift/Configuration$ swift
> Welcome to Apple Swift version 4.0-dev (LLVM 2dedb62a0b, Clang b9d76a314c, 
> Swift 0899bd328a). Type :help for assistance.
> 1> import Foundation
> 2> struct A: Codable { 
> 3. var integer: Int 
> 4. 
> 5. public init(integer: Int) { 
> 6. self.integer = integer 
> 7. } 
> 8. 
> 9. public init(from decoder: Decoder) throws { 
> 10. print("Custom decoder") 
> 11. let container = try decoder.container(keyedBy: CodingKeys.self) 
> 12. integer = try container.decode(Int.self, forKey: .integer) 
> 13. } 
> 14. } 
> 15. 
> 16. try! JSONDecoder().decode(A.self, from: JSONEncoder().encode(A(integer: 
> 42)))
> Custom decoder
> $R0: A = {
> integer = 42
> }
> 
> You should be able to implement your custom init to convert the number into a 
> string and JSONDecoder should use that automatically.
> 
> Thanks,
> 
> Youming Lin
> IBM Cloud, Swift@IBM, Kitura developer
> Austin, TX
> GitHub: @youming-lin
> 
> "Sneed, Brandon" ---08/30/2017 04:14:57 PM---Thanks Youming, 
> Ok, thanks! I did try that, but I can’t seem to figure out how to make it 
> actually
> 
> From: "Sneed, Brandon" >
> To: Youming Lin >
> Cc: Tony Parker >, 
> "swift-corelibs-dev@swift.org " 
> >, 
> "swift-corelibs-dev-boun...@swift.org 
> " 
>  >
> Date: 08/30/2017 04:14 PM
> Subject: Re: [swift-corelibs-dev] Adding type conversion capabilities to JSON 
> encode/decode
> 
> 
> 
> 
> Thanks Youming,
> 
> Ok, thanks! I did try that, but I can’t seem to figure out how to make it 
> actually get used in the decoding process. That being my preferred way, I 
> tried it first. I chalked it not working up to Swift not knowing which of the 
> 2 init(from decoder:) functions to call, mine or theirs. But, 

Re: [swift-corelibs-dev] Adding type conversion capabilities to JSON encode/decode

[Tony Parker via swift-corelibs-dev]

> On Aug 30, 2017, at 3:12 PM, Sneed, Brandon  wrote:
> 
> Thanks Tony,
>  
> Ah.  That should work, and covers benefit #2 I mentioned very nicely.  Only 
> downside is that as a developer on an app I may not expect that type to 
> change on the server side so I wouldn’t do it by default, and when it does 
> happen, I then need to apply it to each of its siblings because if it can 
> happen to one, it can happen to the others.

In this case, the server decides to send a String instead of a numeric value 
for many kinds of types?

I understand that some JSON libraries have options to stringify all numeric 
values in an attempt to preserve ‘exactness’, although I would argue that this 
depends on what you do with the numeric value on the other side…

- Tony

>  
> Javascript and GSON handle this in a relatively safe way.  I think us having 
> a way to opt-in to the same capabilities is good.  When I say opt-in, I mean 
> at the containing-struct level, not necessarily per member, nor do I want to 
> do a custom init every time.  I’m sure there’s a happy place in the middle, 
> just not sure what it is. 
>  
> I do also want to add that I very much appreciate the discussion.  We’re 
> having one internally too, and the divide seems to be about the same as 
> what’s on the mailing list (which seems about 50/50).
>  
>  
> Brandon Sneed
>  
> From:  on behalf of Tony Parker 
> 
> Date: Wednesday, August 30, 2017 at 3:04 PM
> To: "Sneed, Brandon" 
> Cc: Youming Lin , "swift-corelibs-dev@swift.org" 
> 
> Subject: Re: [swift-corelibs-dev] Adding type conversion capabilities to JSON 
> encode/decode
>  
> I haven’t tried this myself yet, but you could imagine creating a type which 
> represents an ABV and decodes using a single value container. Then, your 
> custom behavior goes into the Codable implementation of this ABV type.
>  
> Struct Beer then looks like:
>  
> struct Beer: Codable {
> let name: String
> let abv: ABV
> …
> }
>  
> ABV can have API on it to get the numeric value or String value; or that 
> could go into Beer and it would abstract the ABV type from callers.
>  
> - Tony
> 
> 
> On Aug 30, 2017, at 2:42 PM, Sneed, Brandon  > wrote:
>  
> Thanks Youming,
>  
> That’s not quite what I meant.  I may have misinterpreted what Tony was 
> saying though.
>  
> I wanted to do conversion on String, not the containing type.  The problem of 
> doing it on the containing type is that as soon as you need one field to be 
> custom, you’re roped into handling all the others.  For a small struct, not a 
> big deal, for larger ones, it is.  Something like this is what I tried:
>  
> import Cocoa
>  
> let jsonString = "{" +
> "\"name\": \"Endeavor\"," +
> "\"abv\": 8.9," +
> "\"brewery\": \"Saint Arnold\"," +
> "\"style\": \"ipa\"}"
>  
> struct Beer: Codable {
> let name: String
> let abv: String
> let brewery: String
> let style: String
> }
>  
> extension String {
> init(from decoder: Decoder) throws {
> print("i got hit.")
> let value = try decoder.singleValueContainer().decode(String.self)
> self.init(value)
> }
> }
>  
> let jsonData = jsonString.data(using: .utf8)
> let decoder = JSONDecoder()
> let beer = try! decoder.decode(Beer.self, from: jsonData!)
>  
> fatal error: 'try!' expression unexpectedly raised an error: 
> Swift.DecodingError.typeMismatch(Swift.String, 
> Swift.DecodingError.Context(codingPath: [__lldb_expr_17.Beer.(CodingKeys in 
> _C8902E33F84CE6946081129DAF1824E1).abv], debugDescription: "Expected to 
> decode String but found a number instead.", underlyingError: nil)): file 
> /Library/Caches/com.apple.xbs/Sources/swiftlang/swiftlang-900.0.59/src/swift/stdlib/public/core/ErrorType.swift,
>  line 181
>  
>  
>  
> From: Youming Lin >
> Date: Wednesday, August 30, 2017 at 2:35 PM
> To: "Sneed, Brandon" >
> Cc: Tony Parker >, 
> "swift-corelibs-dev@swift.org " 
> >, 
> "swift-corelibs-dev-boun...@swift.org 
> " 
>  >
> Subject: Re: [swift-corelibs-dev] Adding type conversion capabilities to JSON 
> encode/decode
>  
> Brandon
> 
> I cooked up a simple example and it works as expected.
> 
> ylin@youming-mbpr:~/Swift/Configuration$ swift
> Welcome to Apple Swift version 4.0-dev (LLVM 2dedb62a0b, Clang b9d76a314c, 
> Swift 0899bd328a). Type :help for assistance.
> 1> import Foundation
> 2> struct A: Codable { 
> 3. var integer: Int 
> 4. 
> 5. public init(integer: 

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

[Tony Parker via swift-corelibs-dev]

Why does it imply a run loop rather than one of many multithreading 
possibilities (dispatch queue, starting one more thread, etc)? And even if it 
did use run loops, why is that a problem?

In general we have been discouraging the use of synchronous and blocking API 
for many years now. It’s convenient for a script like this, but the API under 
discussion would be available to all kinds of apps. We must look for a solution 
that is general enough to be useful everywhere. 

- Tony

> On Nov 27, 2017, at 11:50 PM, Brent Royal-Gordon  
> wrote:
> 
>> On Nov 27, 2017, at 11:01 PM, Brent Royal-Gordon  
>> wrote:
>> 
>> We aren't today
> 
> 
> Sorry, this part of the sentence got mangled in editing. What I meant to say 
> is, script-style programs currently don't run under a runloop, so if this API 
> is being designed for scripting use, a completion handler—even with 
> async/await—might not be the right design.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

[Tony Parker via swift-corelibs-dev]

Why did we give up so easily? I did not say that scripting support is somehow a 
non-goal. In fact, it is exactly the opposite.

I do not believe that somehow API that is useful for scripts is mutually 
exclusive with API that is useful for apps.

- Tony

> On Nov 30, 2017, at 9:26 AM, Jacob Williams  wrote:
> 
> Since this isn’t going to be coming to Foundation any time…ever, I’d take a 
> look at the SwiftShell framework. It makes running command line utilities 
> from swift pretty easy. Chaining outputs from previous commands into 
> subsequent commands is also rather simple. It’s based on Process but gives a 
> lot of sugar that may be useful for you. I’ve been using it in one of my 
> projects on an Ubuntu machine and it is easy to work with.
> 
> https://github.com/kareman/SwiftShell  
> 
>> On Nov 30, 2017, at 1:43 AM, Nick Keets via swift-corelibs-dev 
>> > wrote:
>> 
>> In that case I think the discussion is kind of moot, scripts are 
>> fundamentally different than apps, being terse is important and almost 
>> always you want to block.
>> 
>> If better scripting support is a non-goal for Foundation then `Process` is 
>> mostly fine as it is. My only wish would be to somehow make it easier to 
>> read and write `Data` to stdin/stdout/stderr.
>> 
>> 
>> On Tue, Nov 28, 2017 at 11:30 PM, Tony Parker > > wrote:
>> Of course, Foundation API has no way of distinguishing if the caller is 
>> considered a script or not.
>> 
>> If the API is a bad idea for other kinds of apps then we simply wouldn’t add 
>> it. So, I think this proposed convenience API needs to consider all of the 
>> varied clients of Foundation.
>> 
>> - Tony
>> 
>> 
>>> On Nov 28, 2017, at 12:24 PM, Brent Royal-Gordon >> > wrote:
>>> 
 On Nov 28, 2017, at 8:00 AM, Tony Parker > wrote:
 
 Why does it imply a run loop rather than one of many multithreading 
 possibilities (dispatch queue, starting one more thread, etc)? And even if 
 it did use run loops, why is that a problem?
>>> 
>>> 
>>> The problem is simply that we're discussing using this feature in Swift 
>>> *scripts*. Swift scripts don't typically invoke `RunLoop.run()` or 
>>> `dispatch_main()`, and without changing the way they generate main() 
>>> functions to intrinsically do so (and then schedule main.swift's body on 
>>> the main runloop/queue), I don't see a good way for it to do so. So an 
>>> async API would be inconvenient to use from a Swift script.
>>> 
>>> -- 
>>> Brent Royal-Gordon
>>> Architechies
>>> 
>> 
>> 
>> ___
>> 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] Encountering "Constant strings cannot be deallocated" in Linux foundation

[Tony Parker via swift-corelibs-dev]

I see a couple of places that are suspicious there:

Description:

https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/URL.subproj/CFURLComponents.c#L66
 


And the nameString / valueString constants in the copy query items function:

https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/URL.subproj/CFURLComponents.c#L1057
 

https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/URL.subproj/CFURLComponents.c#L1079
 

https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/URL.subproj/CFURLComponents.c#L1104
 

https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/URL.subproj/CFURLComponents.c#L1134
 

https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/URL.subproj/CFURLComponents.c#L1158
 


Do you have the ability to re-build swift-corelibs-foundation and run a test? I 
suspect if you replace those with CFRetain(CFSTR(…)) then it will fix your 
crash.

- Tony

> On Nov 29, 2017, at 2:06 PM, Brandon Williams  wrote:
> 
> Thanks for the info!
> 
> FWIW, most of the places I have encountered this so far have made use of 
> `URLComponents`, and have even been able to eliminate the crash by getting 
> rid of that code in a few places. The other JIRA bug on this topic also 
> mentions URLComponents in their repro case. Seems to be the culprit.
> 
> Also worth noting that in the above cases dealing with URLComponents the 
> crash only happens in DEBUG compilations, not RELEASE.
> 
> However, I do have another one of these crashes that _does_ happen on RELEASE 
> builds that I haven’t yet been able to reduce.
> 
> 
> On Wed, Nov 29, 2017 at 4:43 PM Tony Parker  > wrote:
> Hi Brandon,
> 
> This is probably a bug in the CoreFoundation C sources part of 
> swift-corelibs-foundation. Unlike Darwin platforms, we can’t make the 
> CFSTR(“”) macro produce a CFStringRef that cannot be overreleased. Probably 
> there is a constant string returned from CF function, then the Swift runtime 
> assumes it can release it, and bam we wind up with an overrelease.
> 
> We’ll have to track down which function is getting called, which probably 
> just requires stepping through that test case with a debugger…
> 
> - Tony
>> On Nov 29, 2017, at 1:34 PM, Brandon Williams via swift-corelibs-dev 
>> > wrote:
>> 
> 
>> Hello all!
>> 
>> We’ve been encountering this runtime error quite a bit recently, and we have 
>> no idea why. We’ve filed a bug and there’s one other on JIRA related to 
>> this, but both without any comments:
>> 
>> https://bugs.swift.org/browse/SR-6422 
>> https://bugs.swift.org/browse/SR-6398 
>> 
>> We’re curious if others are aware of this and or has more info? Is it a red 
>> herring for some other problem?
>> 
>> Any info would be helpful!
> 
>> ___
>> 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] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 16.10 (swift 4.1) #477

[Tony Parker via swift-corelibs-dev]

Last change in this area was 5 days ago:

820e3a88 : (5 days ago) Naoki Ishikawa : use optional binding 
 Foundation/URLSession/http/HTTPURLProtocol.swift | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

but that does not look promising as a source of a regression.

When did this start failing? Is it possible a change in swift or the standard 
library caused the problem?

- Tony

> On Dec 19, 2017, at 4:12 PM, Michael Ilseman  wrote:
> 
> swift-corelibs-dev, any clue why this suddenly started failing?
> 
> TestFoundation/TestURLSession.swift:776: error: 
> TestURLSession.test_simpleUploadWithDelegate : XCTAssertEqual failed: ("0") 
> is not equal to ("16384") - 
> 
> 
> 
>> On Dec 19, 2017, at 4:02 PM, swift...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-swift-4.1-incremental-RA-linux-ubuntu-16_10 [#477]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-4.1-incremental-RA-linux-ubuntu-16_10/477/
>>  
>> 
>> Project: oss-swift-4.1-incremental-RA-linux-ubuntu-16_10
>> Date of build:   Tue, 19 Dec 2017 17:12:38 -0600
>> Build duration:  50 min
>> Identified problems:
>> 
>> Compile Error: This build failed because of a compile error. Below is a list 
>> of all errors in the build log:
>> Indication 1 
>> 
>> Tests:
>> 
>> Name: Swift(linux-x86_64)
>> Failed: 0 test(s), Passed: 10119 test(s), Total: 10119 test(s)
>> Name: Swift-Unit
>> Failed: 0 test(s), Passed: 487 test(s), Total: 487 test(s)
>> 
>> Changes
>> 
>> Commit d2505ab28dd999057f9da70ccdd98b536038ef93 by dgregor:
>> [Runtime] Warn about dynamically querying conditional conformances.
>> 
>> edit: stdlib/public/runtime/ProtocolConformance.cpp
>> add: test/Interpreter/conditional_conformances_warning.swift
>> 
>> Commit 2e14e88b96a5a4eae4a9a9918f88d87647fcfccf by dgregor:
>> Revert "[SE-0143] Put conditional conformances behind an "experimental"
>> 
>> edit: test/SILOptimizer/devirt_conditional_conformance.swift
>> edit: test/Interpreter/conditional_conformances_modules.swift
>> edit: test/decl/ext/generic.swift
>> edit: test/SILGen/conditional_conformance.swift
>> edit: test/decl/var/properties.swift
>> edit: include/swift/AST/DiagnosticsSema.def
>> edit: lib/Sema/TypeCheckProtocol.cpp
>> edit: lib/Frontend/CompilerInvocation.cpp
>> edit: test/Sema/enum_equatable_conditional.swift
>> edit: include/swift/Option/Options.td
>> edit: test/SIL/Parser/witness_tables.sil
>> edit: tools/sil-opt/SILOpt.cpp
>> edit: test/Generics/conditional_conformances.swift
>> edit: test/Generics/conditional_conformances_execute_smoke.swift
>> edit: test/Interpreter/conditional_conformances_smoke.swift
>> edit: stdlib/public/core/CMakeLists.txt
>> edit: lib/Driver/ToolChains.cpp
>> edit: test/IRGen/conditional_conformances.swift
>> edit: test/Interpreter/conditional_conformances.swift
>> edit: test/Generics/requirement_inference.swift
>> edit: include/swift/Basic/LangOptions.h
>> edit: test/Generics/conditional_conformances_operators.swift
>> 
>> Commit 3883b9319c66c261c90cf87d2340819d3f4f8820 by dgregor:
>> Eliminate extraneous uses of
>> 
>> edit: test/Constraints/array_literal.swift
>> edit: test/stmt/foreach.swift
>> edit: test/Interpreter/conditional_conformances_warning.swift
>> edit: test/IRGen/protocol_conformance_records.swift
>> edit: test/Prototypes/Algorithms.swift.gyb
>> 
>> Commit e68f77be5aa54db89dde6c321951153f2bdfbe20 by dgregor:
>> [Runtime] Print demangled names in conditional conformances warning.
>> 
>> edit: stdlib/public/runtime/ProtocolConformance.cpp
>> edit: test/Interpreter/conditional_conformances_warning.swift
>> 
>> Commit cf33f86c1171f505611b61aab464fef2d25e8805 by dgregor:
>> [Runtime] Update field names for the 4.1 branch
>> 
>> edit: stdlib/public/runtime/ProtocolConformance.cpp
>> 
>> Commit 1ac71826854a809f67ae15ddacaaa9a6eb8189e8 by aleksei_lorenz:
>> [driver][darwin] Take the OS version specified in "-target" as the
>> 
>> edit: lib/Driver/ToolChains/Darwin.cpp
>> edit: test/Driver/objc-weak.m
>> edit: test/Driver/darwin-version.c
>> edit: test/Driver/pic.c
>> edit: test/Driver/unavailable_aligned_allocation.cpp
>> 
>> Commit 4a9ce31c969cc4c9429e306d463610c0c623baa9 by aleksei_lorenz:
>> Don't warn about superfluous -m-version-min option in
>> 
>> edit: lib/Driver/ToolChains/Darwin.cpp
>> edit: test/Driver/darwin-version.c
> 

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

Re: [swift-corelibs-dev] [Proposal] RangeReplaceableCollection should inherits from MutableCollection

[Tony Parker via swift-corelibs-dev]

Hi Jiannan,

I think you’ll get a better answer to your question on the ‘swift-dev’ list, 
actually.

Hope this helps,
- Tony

> On Dec 2, 2017, at 9:08 AM, Cao, Jiannan via swift-corelibs-dev 
>  wrote:
> 
> Hi everyone,
> 
> I'd like to discuss the relation between RangeReplaceableCollection and 
> MutableCollection
> 
> MutableCollection is a Collection type that can { set } any element with 
> subscript(position: Index). (and also { set } for subscript(range: 
> Range))
> 
> RangeReplaceableCollection requires a function replaceRange(_:with:)
> 
> If a type conforms to RangeReplaceableCollection, it means any of its range 
> can be replaced, that includes the situation to replace only one element.
> So if some type conforms to RangeReplaceableCollection, it is sufficient to 
> be a MutableCollection.
> So I think the RangeReplaceableCollection should conforms to 
> MutableCollection should inherits from MutableCollection.
> 
> Thanks!
> Jiannan
> 
> 
> ___
> 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 4.1 process

[Tony Parker via swift-corelibs-dev]

Hi everyone,

As you’ve probably already seen, the Swift team has announced the Swift 4.1 
release process:

https://swift.org/blog/swift-4-1-release-process/

We’ve arranged to have swift-corelibs-foundation “auto-merge” from master for a 
longer period of time than the other projects. This is because we’re still 
doing more active development and we do not need as much time to converge for 
Linux as the rest of Swift does for all platforms. This should be in place 
until at least November 27.

After that, we’ll look at moving fixes to the branch on a case-by-case basis 
with new PRs. In the meantime, to target Swift 4.1 - put your changes up 
against the master branch.

Thanks everyone!

- Tony

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