Re: [swift-corelibs-dev] Strange behavior the same code fails when building a Cocoa CLI and succeeds in Swift-corelibs-foundation context.

[Philippe Hausler via swift-corelibs-dev]

> On Dec 18, 2017, at 9:29 AM, Benoit Pereira da silva  wrote:
> 
> Thanks Philippe,
> 
> 
>> Good find, 
>> You can make a pull request and we can get our continuous integration 
>> servers to start building that and testing your change – that is probably 
>> the easiest way to get validation on your tests and changes.
>> There are a few issues however with your test that might be worth 
>> considering. Comments inline…
> … 
>> Building a CLI tool will use the objective-c Foundation in the system so 
>> that wont use your freshly built swift-corelibs-foundation. So that means we 
>> have a bug in the objc side if this is actually happening on Darwin (which 
>> is a completely different issue…) That should be a radar against Foundation 
>> and I definitely think that may very well be a bug… 
> 
> 
> I have been filling a radar 
> https://bugreport.apple.com/web/?problemID=36107307 
> 
Thanks for taking the time to file that! I will make sure that gets to the 
right owner.

> I do think you are right it's a bug in the Objc Foundation… and trying to 
> solve it in "swift-corelibs-foundation" was a mistake :) 
> 
> 
>>> setlocale(LC_ALL,"fr_FR”)
>> 
>> This change will set the locale globally for the rest of the process, you 
>> probably want to make sure to reset the locale back to it’s original state.
> 
> 
> Setting the locale globally was just a temporary test.
> 
> But i do think that it triggers a serious question:  Should all your tests be 
> ran on all the available locales? 
> You will certainly find a smarter solution …

I think it is sensible to iterate through a key list of known locales that have 
certain characteristics, such as using the , as a decimal separator or « for 
quote begin etc (not to pick on French but it is the one I know better than 
other punctuation differentials from English).

There are probably key areas that are worth doing this to and others that 
probably do not matter so much. e.g. you don’t really need to test locale 
variations with NotificationCenter for example whereas NumberFormatter or 
JSONSerialization may be places that we want to test a few locales by 
subclassing the unit tests and in setup change the locale and teardown reset it.

> 
> Benoit
> 
> 
> 

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

Re: [swift-corelibs-dev] Strange behavior the same code fails when building a Cocoa CLI and succeeds in Swift-corelibs-foundation context.

[Philippe Hausler via swift-corelibs-dev]

Good find, 

You can make a pull request and we can get our continuous integration servers 
to start building that and testing your change – that is probably the easiest 
way to get validation on your tests and changes.

There are a few issues however with your test that might be worth considering. 
Comments inline...

> On Dec 18, 2017, at 8:45 AM, Benoit Pereira da silva via swift-corelibs-dev 
>  wrote:
> 
> Dear All,
> 
> 
> I do encounter a very strange Issue.
> 
> I have been adding a test to 
> `swift-corelibs-foundation/testJSONSerialization.swift`
> This test succeed within swift-corelibs-foundation test, but fails when 
> repackaged to a Cocoa CLI app.
> 
> The  swift-corelibs-foundation test : 
> 
> 
> func test_serializeFloatingPointWithANonDotDecimalSeparatorLocale() {
> // We use a locale that is using "," as decimal separator.
> setlocale(LC_ALL,"fr_FR”)

This change will set the locale globally for the rest of the process, you 
probably want to make sure to reset the locale back to it’s original state.

> 
> let dictionary = ["decimalValue":1.1]
> do{
> let data = try JSONSerialization.data(withJSONObject: dictionary)
> if let json =  String(data:data, encoding:.utf8){
> XCTAssert(!json.contains(","), "Expected result: 
> \"{\"decimalValue\":1.1001}\" found: \"\(json)\"" )
> }else{
> XCTFail("Failed during string encoding")
> }
> }catch{
> XCTFail("Failed during serialization")
> }
> }
> 
> 
> The simple CLI code that proves the bug 
> (https://bugs.swift.org/browse/SR-6631 
> )
> 
> //
> //  main.swift
> //  doubleEncoding
> //
> //  Created by Benoit Pereira da silva on 02/12/2017.
> //  Copyright © 2017 Pereira da Silva. All rights reserved.
> //
> 
> import Foundation
> 
> // Let's set to french
> setlocale(LC_ALL,"fr_FR")
> 
> do{
> let dictionary = ["decimalValue":1.1]
> let data = try JSONSerialization.data(withJSONObject: dictionary)
> if let json =  String(data:data, encoding:.utf8){
> // the result is : "{"decimalValue":1,1001}"
> // The decimal separator should not be "," but "."
> print(json)
> }
> }catch{
> print("\(error)")
> }
> 
> 
> 
> Any idea ?
> I do use Toolchain: Swift Development Snapshot 2017-12-17 (a)

Building a CLI tool will use the objective-c Foundation in the system so that 
wont use your freshly built swift-corelibs-foundation. So that means we have a 
bug in the objc side if this is actually happening on Darwin (which is a 
completely different issue…) That should be a radar against Foundation and I 
definitely think that may very well be a bug… 

> 
> 
> Benoit
> 
> 
> 
> Benoit Pereira da Silva
> Ultra Mobile Developer & Movement Activist
> Développeur Ultra Mobile & Militant du mouvement
> https://pereira-da-silva.com 
> 
> 
> 
> 
> 
> ✄ 
> This e-mail is confidential. Distribution, copy, publication or use of this 
> information for any purpose is prohibited without agreement of the sender.
> Ce message est confidentiel. Toute distribution, copie, publication ou usage 
> des informations contenues dans ce message sont interdits sans agrément 
> préalable de l'expéditeur.
> 
> 
> 
> ___
> 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

[Philippe Hausler via swift-corelibs-dev]

I think that perhaps we have a problem with the retain count flags in the 
definition of CFSTR. Previously the pinned reference would prevent the 
deallocation. This may have gotten clobbered with the latest CF import.

Sent from my iPhone

> On Nov 29, 2017, at 7:55 PM, Brandon Williams via swift-corelibs-dev 
>  wrote:
> 
> Hey Tony,
> 
> We were able to fix our crashes by avoiding our uses of `URLQueryItem`s. In 
> one place I had to completely remove the use of `URLQueryItem`:
> 
> https://github.com/pointfreeco/swift-web/pull/79/files#diff-293b73a926ba418bd9511ef735fc947cL147
> 
> And in another my colleague Stephen Celis discovered that duplicate keys in a 
> query string can cause this to crash:
> 
> https://github.com/pointfreeco/swift-web/pull/80
> 
> He was able to come up with a minimal test case to demonstrate this:
> 
> https://github.com/pointfreeco/swift-web/commit/cfa9b519a829f1c1627620521326f0877c2d023a
> 
> And you can see the failure in this Travis CI report:
> 
> https://travis-ci.org/pointfreeco/swift-web/builds/309316418
> 
> At the bottom you’ll find:
> 
> ```fatal error: Constant strings cannot be deallocated: file 
> Foundation/NSCFString.swift, line 118```
> 
> So definitely seems to be in that area!
> 
> Now, as far as rebuilding swift-corelibs-foundation, I’m down to try but I 
> dont really know much about how to do that. With some instructions I could 
> give it a shot.
> 
> Thanks for the help!
> 
> 
> 
> 
>> On Wed, Nov 29, 2017 at 5:59 PM Tony Parker  wrote:
>> 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
> 

Re: [swift-corelibs-dev] Encountering "Constant strings cannot be deallocated"

[Philippe Hausler via swift-corelibs-dev]

Is this with a recent build? Do you know what commit the 
swift-corelibs-foundation is from? That might help nail down what is going on 
here.

> On Nov 16, 2017, at 2:41 PM, Brandon Williams via swift-corelibs-dev 
>  wrote:
> 
> Hello! I have a test case that when run on Linux somehow encounters the 
> "Constant strings cannot be deallocated” fatal error thrown in 
> NSCFString.swift, as seen here:
> 
> https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSCFString.swift#L118
>  
> 
> 
> The test that does it is here:
> 
> https://github.com/pointfreeco/swift-web/blob/5f19a0264be5d369ee0438da8599e3c478a6573b/Tests/ApplicativeRouterTests/SyntaxRouterTests.swift#L88-L93
>  
> 
> 
> Now there’s a lot to unravel here and I haven’t been able to quite isolate 
> it, but I thought perhaps someone here might know how that could path could 
> even be executed.
> 
> Thanks for any help!
> ___
> 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-dev] Foundation Data Behavior Different (read: crashes) in Swift 3.1 and Swift 3.2

[Philippe Hausler via swift-corelibs-dev]

This is expected behaviors of collections and their slices. The previous result 
was a bug.

I agree that collections in general and their slices need more documentation.

Sent from my iPhone

> On Aug 24, 2017, at 11:28 AM, Ryan Lovelett  
> wrote:
> 
> I think your onto it Philippe but then why is it behaving that way?
> 
> I updated my earlier script (attached) and added 2 things.
> 
>   1. print("Start: \(data.startIndex), End: \(data.endIndex), Count: 
> \(data.count)") after the data.removeFirst(4).
>   2. The startIndex offset you suggested.
> 
> It no longer crashes. Hooray!
> 
> Swift 3.1:
> 
> Start: 0, End: 2, Count: 2
> Base64: QWE=, String: Aa
> 
> Swift 3.2:
> 
> Start: 4, End: 6, Count: 2
> Base64: QWE=, String: Aa
> 
> Oh wait. Woah. That's a really subtle change that has some very real 
> consequences.
> 
> Is this expected and/or documented? Because I certainly would not have 
> expected that drastic of a change. I'll obviously need to go read a lot more 
> of the changes between Swift 3.1 and Swift 3.2 if these sorts of changes are 
> in scope.
> 
> 
>> On Thu, Aug 24, 2017, at 02:10 PM, Philippe Hausler wrote:
>> I see the issue.. the latest version traps (appropriately so).
>> 
>> let str = String(bytes: data[0..<2], encoding: .utf8)!
>> 
>> The sub-range of the slice you have is incorrectly indexed. Try this out (I 
>> am presuming this is what you mean):
>> 
>> let str = String(bytes: data[data.startIndex..<(data.startIndex + 2)], 
>> encoding: .utf8)!
>> 
>>> On Aug 24, 2017, at 11:07 AM, Philippe Hausler  wrote:
>>> 
>>> Is there a radar or bugs.swift.org ticket filed on this?
>>> 
>>> I presume because of the import this is a Darwin thing and not a linux 
>>> thing.
>>> 
 On Aug 24, 2017, at 11:05 AM, Michael Gottesman via swift-dev 
  wrote:
 
 
> On Aug 24, 2017, at 10:47 AM, Ryan Lovelett via swift-dev 
>  wrote:
> 
> I've found what I believe is a bug. Though I'm unclear if the bug is in
> Swift 3.1 or Swift 3.2/4.0. All I can say for sure is the behavior is
> quite drastically different between the two.
> 
> For the code below (and attached):
> 
>  import Cocoa
> 
>  var data = Data(bytes: [0x50, 0x4B, 0x01, 0x02, 0x41, 0x61])
>  data.removeFirst(4)
>  let base64 = data.base64EncodedString()
>  let str = String(bytes: data[0..<2], encoding: .utf8)!
>  print("Base64: \(base64), String: \(str)")
> 
> If I compile and run that with the Swift included in Xcode 8.3.3 (e.g.,
> swift ./data-bug.swift) it outputs: Base64: QWE=, String: Aa. Which is
> what I expect.
> 
> With the Swift that is included with Xcode 9.0 beta 6 (9M214v) (e.g.,
> swift -swift-version 3 ./data-bug.swift). It performs an illegal
> hardware instruction and crashes. It also does this if I use use the
> version 4 of the compiler.
> 
> Is this a bug? If so where is the bug? Was this always meant to not work
> and Swift 3.1 just happened to work or is there now an issue in the
> Swift 3.2 implementation?
 
 I have not engaged my brain with the particulars of the rest of the email, 
 but high level question: does this happen without optimization? Or does it 
 happen only with optimization?
 
 Michael
 
> ___
> swift-dev mailing list
> swift-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-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] [swift-dev] Foundation Data Behavior Different (read: crashes) in Swift 3.1 and Swift 3.2

[Philippe Hausler via swift-corelibs-dev]

I see the issue.. the latest version traps (appropriately so).

let str = String(bytes: data[0..<2], encoding: .utf8)!

The sub-range of the slice you have is incorrectly indexed. Try this out (I am 
presuming this is what you mean):

let str = String(bytes: data[data.startIndex..<(data.startIndex + 2)], 
encoding: .utf8)!

> On Aug 24, 2017, at 11:07 AM, Philippe Hausler  wrote:
> 
> Is there a radar or bugs.swift.org ticket filed on this?
> 
> I presume because of the import this is a Darwin thing and not a linux thing.
> 
>> On Aug 24, 2017, at 11:05 AM, Michael Gottesman via swift-dev 
>>  wrote:
>> 
>> 
>>> On Aug 24, 2017, at 10:47 AM, Ryan Lovelett via swift-dev 
>>>  wrote:
>>> 
>>> I've found what I believe is a bug. Though I'm unclear if the bug is in
>>> Swift 3.1 or Swift 3.2/4.0. All I can say for sure is the behavior is
>>> quite drastically different between the two.
>>> 
>>> For the code below (and attached):
>>> 
>>>  import Cocoa
>>> 
>>>  var data = Data(bytes: [0x50, 0x4B, 0x01, 0x02, 0x41, 0x61])
>>>  data.removeFirst(4)
>>>  let base64 = data.base64EncodedString()
>>>  let str = String(bytes: data[0..<2], encoding: .utf8)!
>>>  print("Base64: \(base64), String: \(str)")
>>> 
>>> If I compile and run that with the Swift included in Xcode 8.3.3 (e.g.,
>>> swift ./data-bug.swift) it outputs: Base64: QWE=, String: Aa. Which is
>>> what I expect.
>>> 
>>> With the Swift that is included with Xcode 9.0 beta 6 (9M214v) (e.g.,
>>> swift -swift-version 3 ./data-bug.swift). It performs an illegal
>>> hardware instruction and crashes. It also does this if I use use the
>>> version 4 of the compiler.
>>> 
>>> Is this a bug? If so where is the bug? Was this always meant to not work
>>> and Swift 3.1 just happened to work or is there now an issue in the
>>> Swift 3.2 implementation?
>> 
>> I have not engaged my brain with the particulars of the rest of the email, 
>> but high level question: does this happen without optimization? Or does it 
>> happen only with optimization?
>> 
>> Michael
>> 
>>> ___
>>> swift-dev mailing list
>>> swift-...@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-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] [swift-dev] Foundation Data Behavior Different (read: crashes) in Swift 3.1 and Swift 3.2

[Philippe Hausler via swift-corelibs-dev]

Is there a radar or bugs.swift.org ticket filed on this?

I presume because of the import this is a Darwin thing and not a linux thing.

> On Aug 24, 2017, at 11:05 AM, Michael Gottesman via swift-dev 
>  wrote:
> 
> 
>> On Aug 24, 2017, at 10:47 AM, Ryan Lovelett via swift-dev 
>>  wrote:
>> 
>> I've found what I believe is a bug. Though I'm unclear if the bug is in
>> Swift 3.1 or Swift 3.2/4.0. All I can say for sure is the behavior is
>> quite drastically different between the two.
>> 
>> For the code below (and attached):
>> 
>>   import Cocoa
>> 
>>   var data = Data(bytes: [0x50, 0x4B, 0x01, 0x02, 0x41, 0x61])
>>   data.removeFirst(4)
>>   let base64 = data.base64EncodedString()
>>   let str = String(bytes: data[0..<2], encoding: .utf8)!
>>   print("Base64: \(base64), String: \(str)")
>> 
>> If I compile and run that with the Swift included in Xcode 8.3.3 (e.g.,
>> swift ./data-bug.swift) it outputs: Base64: QWE=, String: Aa. Which is
>> what I expect.
>> 
>> With the Swift that is included with Xcode 9.0 beta 6 (9M214v) (e.g.,
>> swift -swift-version 3 ./data-bug.swift). It performs an illegal
>> hardware instruction and crashes. It also does this if I use use the
>> version 4 of the compiler.
>> 
>> Is this a bug? If so where is the bug? Was this always meant to not work
>> and Swift 3.1 just happened to work or is there now an issue in the
>> Swift 3.2 implementation?
> 
> I have not engaged my brain with the particulars of the rest of the email, 
> but high level question: does this happen without optimization? Or does it 
> happen only with optimization?
> 
> Michael
> 
>> ___
>> swift-dev mailing list
>> swift-...@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-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] NSRegularExpression performance

[Philippe Hausler via swift-corelibs-dev]

From a performance standpoint there are a few things going on here.

1) I would highly suggest to have a compiled NSRegularExpression stored once 
per pattern. From what I can tell this is true for the code listed? Regexes in 
general are not always best to re-create all the time since it has to have a 
“compiled" engine from ICU to be made each time.

2) Last time I looked at this specific sample the cost is bridging strings back 
and forth between NSString and String. In swift 4 we have made some 
improvements for bridging but I am not certain if any specifically apply to 
this context (when run on Darwin). For linux builds we are missing the 
referencing string variants so this can cause some severe performance hits when 
copying large strings. 

3) I would avoid utf8.count in this case for measuring perf (it is probably 
going to be slow for large files)

4) per your commentary on parallelized cases, I am not certain on why that is 
slower. Presuming the source data is large (order of megabytes) it should not 
contend on the access to the regular expression. So I find this odd that it is 
not better to utilize all cores of your machine.

Now I think with some tuning we could probably get swift-corelibs-foundation to 
have some faster paths here. As well as fixing some missteps in the code listed 
for the two tests.

I have some branches that I have been working on for swift-corelibs-foundation 
that might reduce some allocation times and improve string conversions back and 
forth from reference types to structural types but those are not fully baked 
yet. Partially you have to realize that swift-corelibs-foundation is still 
quite new in comparison to the Foundation on Darwin. So we have been focusing 
on getting API coverage to a closer point than per-se performance work. Granted 
however pull requests are welcomed in both cases ;)

> On Jun 29, 2017, at 10:15 AM, Francois Green via swift-corelibs-dev 
>  wrote:
> 
> I’m uncertain if I’m using the correct forum, but I asked this question on 
> the user list a few months back and no one responded.  The 
> NSRegularExpression library seems to perform poorly and I’m wondering if this 
> is a performance bug or is it being used improperly?  I’ve added links to two 
> algorithms from the Benchmark Game project that seem quite slow when compared 
> to other languages.  While I understand that direct comparisons are not 
> possible, this one benchmark really stands out. 
> 
> http://benchmarksgame.alioth.debian.org/u64q/program.php?test=regexredux=swift=2
> 
> http://benchmarksgame.alioth.debian.org/u64q/program.php?test=regexredux=swift=1
> ___
> 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] Xcode build broken with latest snapshot

[Philippe Hausler via swift-corelibs-dev]

You can also add a user defined Xcode setting so that others don’t have to set 
that default: SWIFT_INDEX_STORE_ENABLE and set it to NO

> On Jun 27, 2017, at 8:29 AM, Ian Partridge via swift-corelibs-dev 
>  wrote:
> 
> On 27 June 2017 at 15:42, Ian Partridge  > wrote:
> > With Xcode 9 beta 2, swift.org  
> > DEVELOPMENT-SNAPSHOT-2017-06-26-a, and latest master of 
> > swift-corelibs-foundation and swift-corelibs-xctest the build fails in the 
> > SwiftXCTest target with:
> >
> > :0: error: unknown argument: '-index-store-path'
> >
> > Command 
> > /Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2017-06-26-a.xctoolchain/usr/bin/swiftc
> >  failed with exit code 1
> 
> To answer my own question - I was able to get the Xcode build working by 
> running:
> 
> defaults write com.apple.dt.Xcode IDEIndexEnableBoltIndex NO
> 
> Many thanks to Simon Evans for pointing me at the right incantation!
> 
> -- 
> 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] CFStringTokenizer

[Philippe Hausler via swift-corelibs-dev]

That particular implementation is not part of the open source side of CF, so a 
re-implementation in Swift/C would be the way to go here.

> On Jun 22, 2017, at 9:44 AM, Andy Best via swift-corelibs-dev 
>  wrote:
> 
> Hey,
> 
> I'm looking at implementing the final missing NSString method ( 
> enumerateSubstrings(in:using:) ), and I noticed that there is no 
> implementation of CFStringTokenizer in the provided CoreFoundation.
> 
> Is this meant to be the case?
> 
> If so, I'll go ahead and implement it in pure Swift
> 
> 
> 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] Mark NSUnimplemented functions as unavailable.

[Philippe Hausler via swift-corelibs-dev]

It might be also useful to keep track of each one of these so we can make sure 
there are bugs for each one. (Even if it is a list that a script could create 
tickets). Many of the NSUnimplemented methods are good points to start 
contributing.

> On May 10, 2017, at 16:59, Sergej Jaskiewicz via swift-corelibs-dev 
>  wrote:
> 
> Well, here is what I got in IBM Swift Sandbox. 
> http://swift.sandbox.bluemix.net/#/repl/5913a8594ee0cd258050b2fd 
> 
> If I got you right, it works.
> 
> Yes, partially implemented functions is a problem. But we definitely could 
> mark the ones that are not implemented at all and not being called.
> 
>> On 11 May 2017, at 02:43, Philippe Hausler > > wrote:
>> 
>> This of course is predicated upon availability macros working appropriately 
>> on linux (which last time I checked we don’t have a version variant). It is 
>> definitely worth investigation.
>> 
>>> On May 10, 2017, at 16:41, Tony Parker via swift-corelibs-dev 
>>> > wrote:
>>> 
>>> Hi Sergej,
>>> 
>>> This is a good idea, but there are some additional things to consider. In 
>>> some cases, methods are partially unimplemented (with edge cases, or at 
>>> least less common cases remaining unfinished). The availability macro can’t 
>>> reflect that status.
>>> 
>>> In other cases, we want to partially implement one function but still call 
>>> through to an unimplemented function. The entire call may fail with the 
>>> assert, but at least we have part of the implementation in place.
>>> 
>>> - Tony
>>> 
 On May 10, 2017, at 4:01 PM, Sergej Jaskiewicz via swift-corelibs-dev 
 > wrote:
 
 I was wondering why cannot we just mark all the 
 methods/properties/functions in Swift Foundation that are NSUnimplemented 
 or call a subroutine that is NSUnimplemented like this:
 
 @available(*, unavailable, message: “foo is not implemented yet”)
 func foo() { NSUnimplemented() }
 
 In this case we can be sure at compile time that we don’t use code that 
 will definitely crash.
 ___
 swift-corelibs-dev mailing list
 swift-corelibs-dev@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>>> 
>>> ___
>>> swift-corelibs-dev mailing list
>>> swift-corelibs-dev@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>> 
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

Re: [swift-corelibs-dev] Mark NSUnimplemented functions as unavailable.

[Philippe Hausler via swift-corelibs-dev]

This of course is predicated upon availability macros working appropriately on 
linux (which last time I checked we don’t have a version variant). It is 
definitely worth investigation.

> On May 10, 2017, at 16:41, Tony Parker via swift-corelibs-dev 
>  wrote:
> 
> Hi Sergej,
> 
> This is a good idea, but there are some additional things to consider. In 
> some cases, methods are partially unimplemented (with edge cases, or at least 
> less common cases remaining unfinished). The availability macro can’t reflect 
> that status.
> 
> In other cases, we want to partially implement one function but still call 
> through to an unimplemented function. The entire call may fail with the 
> assert, but at least we have part of the implementation in place.
> 
> - Tony
> 
>> On May 10, 2017, at 4:01 PM, Sergej Jaskiewicz via swift-corelibs-dev 
>>  wrote:
>> 
>> I was wondering why cannot we just mark all the methods/properties/functions 
>> in Swift Foundation that are NSUnimplemented or call a subroutine that is 
>> NSUnimplemented like this:
>> 
>> @available(*, unavailable, message: “foo is not implemented yet”)
>> func foo() { NSUnimplemented() }
>> 
>> In this case we can be sure at compile time that we don’t use code that will 
>> definitely crash.
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

Re: [swift-corelibs-dev] Building swift with xctest and foundation fails

[Philippe Hausler via swift-corelibs-dev]

You need to also pass --libdispatch but I am not quite sure that will fully fix 
the problem at hand.

Sent from my iPhone

> On Mar 29, 2017, at 6:29 PM, Mohit Athwani via swift-corelibs-dev 
>  wrote:
> 
> I'm trying to get back to work starting from scratch on Swift Foundation on 
> my Ubuntu 16.04 LTS system.
> 
> I cloned the main swift repo and all of it's dependencies via ssh
> ./swift/utils/update-checkout --clone-with-ssh
> and after running (taken from instructions from the Foundation site):
> 
> swift/utils/build-script --xctest --foundation -t
> 
> I get the following error:
> 
> + make build-tests
> /bin/bash ../libtool  --tag=CC   --mode=link 
> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/llvm-linux-x86_64/bin/clang
>  -Wall -Wno-deprecated-declarations  -fblocks 
> -I/home/mohit/Documents/swift-source/swift-corelibs-libdispatch/src/BlocksRuntime
>  -isystem /usr/include/bsd -DLIBBSD_OVERLAY   -g -O0 -rpath 
> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
>   -o dispatch_apply dispatch_apply.o libbsdtests.la ../src/libdispatch.la  
> -lbsd 
> -L/home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
>  -lswiftCore -lswiftSwiftOnoneSupport -lpthread 
> libtool: link: 
> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/llvm-linux-x86_64/bin/clang
>  -Wall -Wno-deprecated-declarations -fblocks 
> -I/home/mohit/Documents/swift-source/swift-corelibs-libdispatch/src/BlocksRuntime
>  -isystem /usr/include/bsd -DLIBBSD_OVERLAY -g -O0 -o .libs/dispatch_apply 
> dispatch_apply.o  ./.libs/libbsdtests.a ../src/.libs/libdispatch.so -lbsd 
> -L/home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
>  -lswiftCore -lswiftSwiftOnoneSupport -lpthread -Wl,-rpath 
> -Wl,//usr/lib/swift/linux -Wl,-rpath 
> -Wl,/home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64/libswiftCore.so:
>  undefined reference to `objc_release'
> clang-4.0: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> Makefile:1123: recipe for target 'dispatch_apply' failed
> make: *** [dispatch_apply] Error 1
> swift/utils/build-script: fatal error: command terminated with a non-zero 
> exit status 2, aborting
> 
> Looks like there is some undefined reference for objc_release in libswiftCore.
> 
> From the looks of the message it looks like swift was actually built but it's 
> just that test cases weren't built. On this hunch, I went into my 
> swift-corelibs-foundation folder and tried to execute:
> 
> ninja
> 
> Which tells me:
> 
> ninja: error: loading 'build.ninja': No such file or directory
> 
> Given my lack of experience here, I'm not quite sure how to go about 
> resolving these issues.
> 
> Could somebody help me out here please.
> 
> Thanks,
> 
> Mohit
> 
> 
> ___
> 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 bridgeable classes

[Philippe Hausler via swift-corelibs-dev]

The reasoning why is that some classes are designed as a has-a relationship 
instead of an is-a relationship. For example a NSRunLoop has a CFRunLoopRef but 
a NSString is a CFStringRef. This means that you cannot pass a NSRunLoop to a 
function that takes a CFRunLoopRef by design. Where-as any method that takes a 
CFStringRef can take a NSString.

The reasoning for this behavior is to match the behavior of the objective-c 
version of Foundation.

> On Feb 21, 2017, at 10:20 AM, Nethra Ravindran via swift-corelibs-dev 
>  wrote:
> 
> For example  NSURLComponents is not CFBridgeable.
> 
> - Nethra Ravindran
> 
> On Tue, Feb 21, 2017 at 3:01 PM, Alex Blewitt  > wrote:
> Do you have a couple of examples that you're referring to?
> 
> Alex
> 
>> On 21 Feb 2017, at 09:25, Nethra Ravindran via swift-corelibs-dev 
>> > wrote:
>> 
>> Hi everyone,
>> 
>> To be more precise, I would like to know why few classes are not 
>> CFBridgeable.
>> 
>> Thank you.
>> 
>> - Nethra Ravindran
>> 
>> On Tue, Feb 21, 2017 at 2:20 PM, Nethra Ravindran 
>> > wrote:
>> Hi,
>> 
>> I see that some classes are bridgeable and some are not. It would be great 
>> if someone can explain why few classes are not bridgeable.
>> 
>> 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

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

Re: [swift-corelibs-dev] [swift-users] DateFormatter crash on second usage (new instance) on Linux (swift 3.0.1)

[Philippe Hausler via swift-corelibs-dev]

You are probably missing the package libblocksruntime-dev. That would cause 
that failure.

Sent from my iPhone

> On Jan 26, 2017, at 6:33 AM, Dennis Schafroth  wrote:
> 
> Thanks for the suggestions. 
> 
> It works with 3.0.2 but won't compile with 3.1 beta for Ubuntu 14.04. Missing 
> a Block.h which does exist in 3.0.2
> 
> :-Dennis
> 
>> On 26 Jan 2017, at 05.20, Philippe Hausler  wrote:
>> 
>> We should run those tests with ASAN, I thought I had fixed that with the 
>> Sierra merge.
>> 
>> Sent from my iPhone
>> 
>>> On Jan 25, 2017, at 6:11 PM, Will Stanton via swift-corelibs-dev 
>>>  wrote:
>>> 
>>> Based on the backtrace, I think the code is running into a memory issue 
>>> with Swift Foundation:
>>> https://bugs.swift.org/browse/SR-2485
>>> https://bugs.swift.org/browse/SR-2462
>>> 
>>> I haven’t seen this in a while - are you able to try running on Swift 3.1 
>>> or 3.0.2?
>>> Your code seems to work on the IBM Sandbox with 3.0.2 but not 3.0.1.
>>> You could also try replacing every 'let’ with ‘var’ but that might not be 
>>> the right solution :-)
>>> 
>>> Regards,
>>> Will Stanton
>>> 
 On Jan 25, 2017, at 5:04 PM, Dennis Schafroth via swift-users 
  wrote:
 
 Hi
 
 Trying to do some simple date parsing from syslog format (“Jan 25 
 20:21:22”) into Date. Seem to work once but crashes on second call
 
 
 func dateConv(_ dateString: String) -> Date? {
 let dateFormatter = DateFormatter()
 dateFormatter.dateFormat = "MMM dd HH:mm"
 dateFormatter.locale = Locale(identifier: "da_DK_POSIX")
 if let date = dateFormatter.date(from: dateString) {
  print("Real date: \(date)" )
  return date
 }
 return nil
 }
 
 var date  = dateConv("Jan 25 20:10")
 var date2 = dateConv("Jan 25 20:11”)
 
 # swift main.swift
 Real date: 2000-01-25 19:10:00 +
 0  swift0x0334ab78 
 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
 1  swift0x03349346 llvm::sys::RunSignalHandlers() + 54
 2  swift0x0334b6aa
 3  libpthread.so.0  0x7fec92166890
 4  libswiftCore.so  0x7fec8e8f0735
 5  libFoundation.so 0x7fec8c0ab6ee
 6  libFoundation.so 0x7fec8bd7a222
 7  libFoundation.so 0x7fec8bd7c623
 8  libFoundation.so 0x7fec8bf0e873 
 _TFC10Foundation6NSDateg11descriptionSS + 99
 9  libFoundation.so 0x7fec8c182829 
 _TTWV10Foundation4Dates23CustomStringConvertibleS_FS1_g11descriptionSS + 57
 10 libswiftCore.so  0x7fec8e78c745 
 _TFs15_print_unlockedu0_R_s16TextOutputStreamrFTxRq__T_ + 997
 
 using swift 3.0.1. Am I doing something wrong? I seems to work on macOS.
 
 cheers,
 :-Dennis
>>> 
>>> ___
>>> 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-users] DateFormatter crash on second usage (new instance) on Linux (swift 3.0.1)

[Philippe Hausler via swift-corelibs-dev]

We should run those tests with ASAN, I thought I had fixed that with the Sierra 
merge.

Sent from my iPhone

> On Jan 25, 2017, at 6:11 PM, Will Stanton via swift-corelibs-dev 
>  wrote:
> 
> Based on the backtrace, I think the code is running into a memory issue with 
> Swift Foundation:
> https://bugs.swift.org/browse/SR-2485
> https://bugs.swift.org/browse/SR-2462
> 
> I haven’t seen this in a while - are you able to try running on Swift 3.1 or 
> 3.0.2?
> Your code seems to work on the IBM Sandbox with 3.0.2 but not 3.0.1.
> You could also try replacing every 'let’ with ‘var’ but that might not be the 
> right solution :-)
> 
> Regards,
> Will Stanton
> 
>> On Jan 25, 2017, at 5:04 PM, Dennis Schafroth via swift-users 
>>  wrote:
>> 
>> Hi
>> 
>> Trying to do some simple date parsing from syslog format (“Jan 25 20:21:22”) 
>> into Date. Seem to work once but crashes on second call
>> 
>> 
>> func dateConv(_ dateString: String) -> Date? {
>>  let dateFormatter = DateFormatter()
>>  dateFormatter.dateFormat = "MMM dd HH:mm"
>>  dateFormatter.locale = Locale(identifier: "da_DK_POSIX")
>>  if let date = dateFormatter.date(from: dateString) {
>>print("Real date: \(date)" )
>>return date
>>  }
>>  return nil
>> }
>> 
>> var date  = dateConv("Jan 25 20:10")
>> var date2 = dateConv("Jan 25 20:11”)
>> 
>> # swift main.swift
>> Real date: 2000-01-25 19:10:00 +
>> 0  swift0x0334ab78 
>> llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
>> 1  swift0x03349346 llvm::sys::RunSignalHandlers() + 54
>> 2  swift0x0334b6aa
>> 3  libpthread.so.0  0x7fec92166890
>> 4  libswiftCore.so  0x7fec8e8f0735
>> 5  libFoundation.so 0x7fec8c0ab6ee
>> 6  libFoundation.so 0x7fec8bd7a222
>> 7  libFoundation.so 0x7fec8bd7c623
>> 8  libFoundation.so 0x7fec8bf0e873 
>> _TFC10Foundation6NSDateg11descriptionSS + 99
>> 9  libFoundation.so 0x7fec8c182829 
>> _TTWV10Foundation4Dates23CustomStringConvertibleS_FS1_g11descriptionSS + 57
>> 10 libswiftCore.so  0x7fec8e78c745 
>> _TFs15_print_unlockedu0_R_s16TextOutputStreamrFTxRq__T_ + 997
>> 
>> using swift 3.0.1. Am I doing something wrong? I seems to work on macOS.
>> 
>> cheers,
>> :-Dennis
> 
> ___
> 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] Asynchronous Operations

[Philippe Hausler via swift-corelibs-dev]

> On Jan 20, 2017, at 7:55 AM, Ian Partridge via swift-corelibs-dev 
>  wrote:
> 
> On Darwin, asynchronous usage of Operation is supported via KVO notifications.
> 
> Because KVO is only available on Darwin platforms, swift-corelibs-foundation 
> currently does not support asychronous Operations, and there is a comment to 
> that effect:
> 
> https://github.com/apple/swift-corelibs-foundation/blob/6c2afef20330681ec1f8e4e4e3e2664bfd75/Foundation/NSOperation.swift#L50
>  
> 
> 
> My understanding is that it's unlikely KVO will arrive on Linux any time 
> soon, so this leaves us with a problem in Operation.  Asynchronous usage of 
> Operation is an important feature.
> 
> Is there any way that we could support asynchronous operations in 
> swift-corelibs-foundation, in the absence of KVO?

So perhaps you misunderstood my comment? What are you meaning by asynchronous 
operation? Technically all operations running in a queue are “asynchronous” on 
Darwin or on Linux. 

My commentary was about the cases where main finishes execution and the 
operation is not finished.

The subclassers of Operation would need to somehow notify the super-class that 
the operation is finished. And we would need to have a mechanism to understand 
if the subclasser is overriding main or start (or both?!)

> 
> Might it be acceptable to add extra temporary public API to enable this?

There is never a thing as temporary API - it haunts us for ever ;)

I think it would be better to advocate a sound design pattern that would 
facilitate proper implementations on all platforms instead… Perhaps like; how 
does one properly use run loops in the context of Operation or dispatch. Often 
that is a suitable way to make things that act asynchronously without consuming 
another thread/queue.

> 
> Many thanks,
> 
> -- 
> 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] Opinions wanted: Special Handling of /proc FileSystem on Linux?

[Philippe Hausler via swift-corelibs-dev]

IMHO it seems reasonable for Foundation to return the contents of procfs items 
when constructing Data. That being said - I would probably favor a more 
structured parsing for actually using that resultant Data than just a blob. 
Those structured elements are probably not very portable so perhaps they belong 
in something above Foundation. 

I don’t know of any linux variants off hand that don’t have /proc, but it might 
be interesting to somehow detect if that is truly a procfs element. I think it 
would perhaps be a failure if just the path /proc is special cased; Android, 
Solaris and Plan9 also share this same concept iirc (there are likely others).

> On Jan 12, 2017, at 11:40 AM, Carl Brown1 via swift-corelibs-dev 
>  wrote:
> 
> Hi,
> 
> I run the Austin Swift meetup group, and a question came up about the /proc 
> filesystem on Linux:
> 
> The question involved the inability to get any useful information from 
> Data(contentsOf: URL(fileURLWithPath: "/proc/sys/fs/file-max")).
> 
> It turns out that Data(contentsOf:) does a stat() on the inode of the file 
> you give it, and then runs alloc()/read() for the specified number of bytes. 
> This works fine on normal files on normal file systems. But all the files in 
> /proc have a 0 length specified by their inodes, and you have to actually 
> read them until EOF to find out how much is there.
> 
> So the question is: Is that something the *Programmer* should be responsible 
> for knowing, or should *Foundation* be responsible for handling that 
> correctly?
> 
> I can see a case that we'd want to avoid embedding things this OS-specific in 
> Foundation, but on the other hand, I know that this is very confusing for 
> Darwin developers moving to Linux and expecting Data(contentsOf:) to "Just 
> work."
> 
> So I thought I'd ask the community and see if there was a consensus.
> 
> Thanks,
> 
> -Carl
> 
> -- 
> Carl Brown
> Swift@IBM
> carl.bro...@ibm.com
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

Re: [swift-corelibs-dev] Executable swift files?

[Philippe Hausler via swift-corelibs-dev]

They should not be marked as executable, that looks to be a mistake.

> On Nov 28, 2016, at 9:33 AM, Alex Blewitt via swift-corelibs-dev 
>  wrote:
> 
> Is there any particular reason why the following files have the executable 
> bits set?
> 
> ./Foundation/NSFileHandle.swift
> ./Foundation/NSNotification.swift
> ./Foundation.xcodeproj/project.pbxproj
> ./TestFoundation/TestNSFileHandle.swift
> ./TestFoundation/TestNSNotificationCenter.swift
> ./TestFoundation/TestNSRunLoop.swift
> ./TestFoundation/TestNSTimer.swift
> 
> None appear to have a shebang at the top to indicate that they are runnable 
> using the swift runtime.
> 
> 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
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

[Philippe Hausler via swift-corelibs-dev]

Furthermore isn’t it a bit of a conflict if we have multiple versions of 
Foundation running apps on a server? I would expect that the mutable state of 
cookies should never be shared across processes not just from a security 
standpoint but also from a versioning standpoint. 

Let have a scenario where there are two web apps running on the same server. 
They should never share data between them unless specifically allowed to. 
Service A uses Foundation version A and service B uses version B. Unless 
service A and B have privileges to communicate they should never use common 
storage for cookies or preferences. This could allow service A to 
inappropriately use the stored credentials of service B if they are stored in 
the same directory. Moreover if the version B of Foundation has some refinement 
to the storage version of the cookie the file may be incompatible with 
Foundation A’s reading schema. 

In my opinion the directories should be unique to the services running unless 
they share a system based privilege system that is a common version (e.g. they 
are allowed to talk to each other and are not sandboxed apart).

Of course some of this could be side-stepped by having the services running as 
different users. But the versioning issue still occurs and should perhaps be 
something that we consider.


> On Nov 14, 2016, at 9:44 AM, Tony Parker via swift-corelibs-dev 
>  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.
> 
> - Tony
> 
>> On Nov 14, 2016, at 1:43 AM, Pushkar N Kulkarni via swift-corelibs-dev 
>> > wrote:
>> 
>> Thanks Will! 
>> 
>> "NSHomeDirectory() + "/.foundation/Cookies/shared" seems good to me
>> 
>> Pushkar N Kulkarni,
>> IBM Runtimes
>> 
>> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
>> 
>> 
>> 
>> -Will Stanton > 
>> wrote: -
>> To: Pushkar N Kulkarni/India/IBM@IBMIN
>> From: Will Stanton >
>> Date: 11/08/2016 08:45AM
>> Cc: swift-corelibs-dev > >
>> Subject: Re: [swift-corelibs-dev] Implementing HTTPCookieStorage
>> 
>> Was wondering if there could be a common directory for Foundation-related 
>> files, such as NSUserDefaults in addition to cookie storage?
>> 
>> So maybe for cookies:
>> NSHomeDirectory() + "/.foundation/Cookies/shared"
>> 
>> And settings for an app/service:
>> NSHomeDirectory() + "/.foundation/Preferences/EXECUTABLE_NAME.plist"
>> 
>> 
>> And I’m not familiar with how Apple Foundation/CFNetwork/nsurlsessiond 
>> handles cookies… or caches things, but I think I agree with Kenny that 
>> naming symmetry would be nice if there is a per-user cookies file.
>> 
>> So having a /Library may be nicer, but potentially unnecessary?
>> NSHomeDirectory() + "/.foundation/Library/Cookies/Cookies.something"
>> 
>> Regards,
>> Will Stanton
>> 
>> > On Nov 7, 2016, at 5:45 PM, Tony Parker via swift-corelibs-dev 
>> > > wrote:
>> > 
>> > 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?
>> 
>> 
>> ___
>> 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] Coercion problems on Linux

[Philippe Hausler via swift-corelibs-dev]

That particular issue we could plaster over with generics. In general it is 
because we don't have bridging on Linux.

Sent from my iPhone

> On Sep 8, 2016, at 8:36 AM, Pushkar N Kulkarni  wrote:
> 
> Hi Tony/Philippe, 
> 
> There've been a few bug reports related to the coercion problems between 
> Swift and Foundation types on Linux. For example this one: 
> https://bugs.swift.org/browse/SR-2477 (Double/Int don't coerce with NSNumber 
> on Linux). 
> 
> Is there any general approach you'd suggest to work around this coercion 
> limitation on Linux?
> 
> 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] Measurement Formatters & ICU

[Philippe Hausler via swift-corelibs-dev]

Just because it was super-easy for me to fix:

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

That should allow C++ to be built if desired into CoreFoundation. However round 
tripping that into the Darwin version of CoreFoundation may be a bit cagey.

> On Aug 23, 2016, at 4:53 PM, Henry Betts  wrote:
> 
> 
>> On 23 Aug 2016, at 16:58, Philippe Hausler  wrote:
>> 
>> Is there a specific version of ICU that we need to pick that functionality 
>> up? As it stands we don’t have a upper version limit on ICU but if we had a 
>> portion of the ICU source in CF it would probably mean that we would get 
>> symbolic conflicts when linking against versions that already had that.
> 
> 
> Looks like the C++ MeasureFormat (and friends) have existed since ICU 3.0, 
> although they have not yet got around to implementing a C interface. I don’t 
> think symbolic conflicts would occur, since, if ICU did eventually introduce 
> the C interface, I assume that it would use just a “u” prefix rather than 
> “ua”. Not sure if that’s what you meant.
> 
> Alternatively, I suppose we could just bypass uameasureformat, and interact 
> with the c++ api directly in CF, since it looks like it’s going to have to be 
> setup to compile c++ anyway.
> 
> Henry

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

Re: [swift-corelibs-dev] Measurement Formatters & ICU

[Philippe Hausler via swift-corelibs-dev]

+Daphne since she was the one who implemented the Darwin version of the unit 
and measurements and I think she has some ideas on how we could perhaps build a 
uniform version for Linux hosts.

Per the C++; the script for that phase probably needs a bit of love since we 
haven’t had a need for C++ to be built in CF. 

Is there a specific version of ICU that we need to pick that functionality up? 
As it stands we don’t have a upper version limit on ICU but if we had a portion 
of the ICU source in CF it would probably mean that we would get symbolic 
conflicts when linking against versions that already had that.

> On Aug 22, 2016, at 1:36 PM, Will Stanton via swift-corelibs-dev 
>  wrote:
> 
> I recall the time formatter being deprecated in favor of measfmt, so you 
> might be right that uatimeunitformat isn't needed. I think some functions in 
> uatimeunitformat.cpp made combining units easier when calling from (then 
> NS)DateComponentsFormatter, but perhaps that can be put functionality in a 
> (Swift-)CFDateComponentsFormatter wrapper. (Not sure if Apple will come out 
> with its own CFDateComponentsFormatter).
> 
> 
> I think this was what I had to change to get C++ working:
> https://github.com/apple/swift-corelibs-foundation/blob/master/lib/phases.py
> The includes for CompileCxx should be more like CompileC.
> 
> Regards,
> Will Stanton
> 
> Sent from my iPhone
> 
>> On Aug 22, 2016, at 15:58, Henry Betts via swift-corelibs-dev 
>>  wrote:
>> 
>> Yes - I was planning on including uameasureformat.cpp for the linux build, 
>> although I was also unsure whether the build script was setup to compile c++.
>> Noticed a bug in uameasureformat.cpp by the way; DURATION_DAY and 
>> DURATION_WEEK are the wrong way around!
>> 
>> I’m a bit confused by uatimeunitformat. I’m probably missing something 
>> obvious, but what can it do that uameasureformat can’t do?
> 
> ___
> 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] NSObject's performSelector(inBackground:with:) doesn't feel right in Swift 3

[Philippe Hausler via swift-corelibs-dev]

I would claim that perhaps it should be:

open func perform(inBackground aSelector: Selector, with anArgument: Any?)

That way it matches the completion family of the rest of performing. But if 
that is the case we should take a look at the onMainThread ones as well so they 
look like this perhaps:

open func perform(onMainThread aSelector: Selector, with arg: Any?, 
waitUntilDone wait: Bool, modes array: [String]?)

That way the call sites would look like this:

myObject.perform(inBackground: #selector(doBackgroundStuff), with: nil)
myObject.perform(onMainThread: #selector(doMainThreadStuff), with: nil)
myObject.perform(#selector(doDelayedThings), with: nil, afterDelay: 0.7)
let result = myObject.perform(#selector(doThingsNow), with: 
nil).takeUnretainedValue()

> On Aug 16, 2016, at 8:46 AM, Shawn Erickson via swift-corelibs-dev 
>  wrote:
> 
> It is following the naming methodology of a sentence like structure 
> "performed selector in background  with ". It does read a 
> little strange but likely comes from a simple remapping of the existing 
> objective-c name for familiarly reasons.
> 
> It could be performInBackground(selector:,with:) ... "Perform in background 
>  with " but that also reads a little strange.
> 
> -Shawn
> 
> On Tue, Aug 16, 2016 at 8:40 AM Paul Hudson via swift-corelibs-dev 
> > wrote:
> Hello!
> 
> I just noticed that performSelectorInBackground(_:withObject:) has
> been mapped to performSelector(inBackground:with:) in Swift 3. So:
> 
> performSelector(inBackground: #selector(doStuff), with: nil)
> 
> This seems confusing to me – the "inBackground" label has little to do
> with the selector that is attached to it. It's possible this has been
> through careful API review and if so I apologize. On the other hand,
> if it's an oversight is there time for it to be looked at again?
> 
> Thank you!
> 
> 
> Paul
> --
> Free Swift tutorials – hackingwithswift.com 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

Re: [swift-corelibs-dev] NSObject's performSelector(inBackground:with:) doesn't feel right in Swift 3

[Philippe Hausler via swift-corelibs-dev]

> On Aug 16, 2016, at 8:42 AM, Philippe Hausler via swift-corelibs-dev 
> <swift-corelibs-dev@swift.org> wrote:
> 
> Those methods should probably all belong to the same family of `perform` but 
> it matches the method naming of:
> 
> open func performSelector(onMainThread aSelector: Selector, with arg: Any?, 
> waitUntilDone wait: Bool, modes array: [String]?)
> 
> But perhaps the naming family should belong to this one:
> 
> open func perform(_ aSelector: Selector, on thr: Thread, with arg: Any?, 
> waitUntilDone wait: Bool)
> 
>> On Aug 15, 2016, at 3:53 PM, Paul Hudson via swift-corelibs-dev 
>> <swift-corelibs-dev@swift.org> wrote:
>> 
>> Hello!
>> 
>> I just noticed that performSelectorInBackground(_:withObject:) has
>> been mapped to performSelector(inBackground:with:) in Swift 3. So:
>> 
>> performSelector(inBackground: #selector(doStuff), with: nil)
>> 
>> This seems confusing to me – the "inBackground" label has little to do
>> with the selector that is attached to it. It's possible this has been
>> through careful API review and if so I apologize. On the other hand,
>> if it's an oversight is there time for it to be looked at again?

Unfortunately per timing wise we are really late in the game to fix the names 
of things. It would require a full API review to push through a better name for 
it. (However I agree that perhaps we should rename them)

Also there were a pair of block variants added to RunLoop that falls into this 
family:

open func perform(inModes modes: [RunLoopMode], block: @escaping () -> 
Swift.Void)
open func perform(_ block: @escaping () -> Swift.Void)

>> 
>> Thank you!
>> 
>> 
>> Paul
>> --
>> Free Swift tutorials – hackingwithswift.com
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

Re: [swift-corelibs-dev] NSKeyValueCoding and the Swift Foundation

[Philippe Hausler via swift-corelibs-dev]

Both KVC and KVO require dynamic dispatching and selector manipulation that is 
not present in swift-corelibs-foundation (since everything is based on swift 
objects).

> On Jun 12, 2016, at 10:54 AM, Lars Sonchocky-Helldorf via swift-corelibs-dev 
>  wrote:
> 
> Hi everybody,
> 
> it came to my attention that the NSKeyValueCoding protocol which is a part of 
> the Darwin-(ObjC-)Foundation (see 
> https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Protocols/NSKeyValueCoding_Protocol/
>  ) is somehow omitted here: 
> https://github.com/apple/swift-corelibs-foundation/blob/master/Docs/Status.md
> 
> Was this done on purpose or is the implementation of NSKeyValueCoding still 
> forthcoming?
> 
> Thanks,
> 
>   Lars
> 
> 
> ___
> 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] How to build swift-corelibs-foundation from command line

[Philippe Hausler via swift-corelibs-dev]

It needs to be bootstrapped in a different way for OS X builds (primarily since 
there is already the system framework of Foundation present).

Are you instilling the toolchain to /Library/Developer/Toolchains? And do you 
have it selected in the preferences in Xcode?

> On Jun 7, 2016, at 6:03 PM, Rajeev Jeyaraj  
> wrote:
> 
> i'm trying to build it on mac OS X, i'm having issue with Xcode picking up my 
> tool chain, built via the build-toolchain script.
> Is there any way I can build from the command line, rather than having to go 
> through Xcode?
> 
> On 7 June 2016 at 21:01, Philippe Hausler  > wrote:
> Building it on Linux just pass --foundation. Building it on Mac OS X you will 
> need to build the toolchain, install that and then build via the Xcode 
> project.
> 
> > On Jun 7, 2016, at 5:59 PM, Rajeev Jeyaraj via swift-corelibs-dev 
> > > wrote:
> >
> > Hi All,
> >
> > I am trying to build the corelibs-foundation from command line, is there a 
> > way to specifiy it in the swift/utils/build script?
> >
> > 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] How to build swift-corelibs-foundation from command line

[Philippe Hausler via swift-corelibs-dev]

Building it on Linux just pass --foundation. Building it on Mac OS X you will 
need to build the toolchain, install that and then build via the Xcode project.

> On Jun 7, 2016, at 5:59 PM, Rajeev Jeyaraj via swift-corelibs-dev 
>  wrote:
> 
> Hi All,
> 
> I am trying to build the corelibs-foundation from command line, is there a 
> way to specifiy it in the swift/utils/build script?
> 
> 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] swift-corelibs-xctest JIRA dashboard

[Philippe Hausler via swift-corelibs-dev]

My suggestion to work around this issue: revert that commit locally - the rest 
should build fine. Unfortunately the change was made without a workaround for a 
deprecated transition when the new accessor was added so we had a hard 
transition that required a full rebuild or else the CI would break on Linux.

Sent from my iPhone

> On May 24, 2016, at 1:13 AM, Rob Allen <r...@akrabat.com> wrote:
> 
> 
>> On 24 May 2016, at 05:38, Philippe Hausler via swift-corelibs-dev 
>> <swift-corelibs-dev@swift.org> wrote:
>> 
>> I took a few moments to file a few more starters for Foundation (hopefully I 
>> should be able to fill out a few more soon). I ran across a some nice ones 
>> that should be relatively trivial to knock out. I think for Foundation the 
>> marker for a good starter bug would be things that are highly testable with 
>> a reduced scope of interfaces. Formatter subclasses are a great point to 
>> start with. Some of the NSUnimplemented methods are minefields that would 
>> require runtime support, whereas others are great points to start with.
>> 
>> Furthermore there will likely be a few good ones that will come in when the 
>> proposals start to land; there is a lot of busy work with the whole naming 
>> changes. So stay tuned on that front.
> 
> I would love to help out, but can't get the Xcode workspace to compile due 
> the the `return Int(self.native.bitPattern)` issue. 
> 
> Is a new development toolchain likely to be released soon, as I'm struggling 
> to build my own toolchain.
> 
> 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] Compilation Error - Which Toolchain

[Philippe Hausler via swift-corelibs-dev]

This was a change in the standard library. I presumed that change had been in 
for a full build cycle. However since that looks like it is not the case I am 
going to revert the offending commit for now and revisit it when the binaries 
are rev'd

> On May 19, 2016, at 3:48 PM, David Hart via swift-corelibs-dev 
>  wrote:
> 
> Hi people,
> 
> Found some time to continue contributing to corelibs, but I’m getting a 
> compilation error with master:
> 
> NSGeometry.swift (line 39):
> 35 private var hash: Int {
> 36 #if arch(i386) || arch(arm)
> 37 return Int(Float(self.native).bitPattern)
> 38 #else
> 39 return Int(self.native.bitPattern) // Value of type 'NativeType' 
> (aka 'Double') has no member 'bitPattern’
> 40 #endif
> 41 }
> 
> I’m using the latest development toolchain. Is that correct? I tried building 
> a master toolchain instead but got a failing test.
> 
> Any ideas?
> 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] NSMutableData memory leak

[Philippe Hausler via swift-corelibs-dev]

I think there is probably some likely issue with the fact that NSMutableData is 
a subclass and the layout initialization is not properly setup during the init 
for that object.

__kCFDontDeallocate is used to mark the allocated memory as managed by the 
deallocator blocks. So I bet the problem is that the code-path for 
NSMutableData(capacity: 0) is hitting the don’t deallocate code path 
incorrectly (where as the other versions are hitting the appropriate flagging; 
hence the crashes)

Does this also occur in the Darwin builds of this? (Using SwiftFoundtion 
instead of Foundation)

> On May 16, 2016, at 9:34 AM, Ian Partridge via swift-corelibs-dev 
>  wrote:
> 
> import Foundation
> 
> while true {
>   var myData: NSMutableData? = NSMutableData(capacity: 0)
>   myData = nil
> }
> 
> Running this infinite loop with swift-corelibs-foundation shows a steady 
> memory leak, with the process's RSS increasing over time.  No leak is seen 
> with Foundation on Darwin.
> 
> Instrumenting with Valgrind's massif profiler shows this stacktrace is 
> responsible for the leak:
> 
> 67.36% (114,349B) (heap allocation functions) malloc/new/new[], --alloc-fns, 
> etc.
> ->65.01% (110,352B) 0x59F7A89: _CFDataInit
>   ->65.01% (110,352B) 0x5B8A8DF: 
> _TTSf4n_n_n_g_n___TFC10Foundation6NSDatacfT5bytesGSqGSpT___6lengthSi4copySb11deallocatorGSqFTGSpT__Si_T___S0_
> ->65.01% (110,352B) 0x5B873ED: 
> _TFC10Foundation13NSMutableDataCfT8capacitySi_GSqS0__
>   ->65.01% (110,352B) 0x40105D: main
> I've stepped through the code with a debugger and observed that the requested 
> capacity is thrown away 
> 
>  [1] to begin with.  The leak occurs regardless of the capacity requested.
> 
> The deinitializer for NSData does call through to _CFDeinit(), which does 
> then call the finalize() 
> 
>  [2] function and hence through to __CFDataDeallocate() 
> 
>  [3].  However, once in __CFDataDeallocate(), the code to free the buffer is 
> skipped, because __kCFDontDeallocate is set.
> 
> If I hack _CFDataInit() so that __kCFDontDeallocate isn't set (by commenting 
> out this line 
> 
>  [4]) then I get crashes elsewhere - so this obviously isn't the right 
> approach.
> 
> I can see that some work has been done in this area 
> 
>  [5] previously by Philippe so I'm wondering if anyone can advise on what 
> might be going on here?
> 
> The init?(length:) initializer avoids CFData entirely and calls malloc() and 
> free() directly.  I'm not sure why that approach was taken and whether it's 
> relevant to my issue.
> 
> Any help would be gratefully received!
> 
> Thanks,
> 
> [1] 
> https://github.com/apple/swift-corelibs-foundation/blob/df239bbbdf5bcdd9ea31c394c6af4dd7c328f99d/Foundation/NSData.swift#L904
>  
> 
> [2] 
> https://github.com/apple/swift-corelibs-foundation/blob/ea6179dd35be2c7d9a8f953579f626a5f1be6511/CoreFoundation/Base.subproj/CFRuntime.c#L1773
>  
> 
> [3] 
> https://github.com/apple/swift-corelibs-foundation/blob/ea3014bd7883e428727272118cbf37dc56522be6/CoreFoundation/Collections.subproj/CFData.c#L294
>  
> 
> [4] 
> https://github.com/apple/swift-corelibs-foundation/blob/ea3014bd7883e428727272118cbf37dc56522be6/CoreFoundation/Collections.subproj/CFData.c#L337
>  
> 
> [5] 
> https://github.com/apple/swift-corelibs-foundation/commit/ea3014bd7883e428727272118cbf37dc56522be6
>  
> 
> 
> -- 
> 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

Re: [swift-corelibs-dev] Setting property "maxConcurrentOperationCount = 1" of NSOperation fails to execute operations using OpenSource Foundation.

[Philippe Hausler via swift-corelibs-dev]

Hmm that seems unfortunate. I wonder if the serial creation is due to an 
unwrapped optional? var attr: dispatch_queue_attr_t? instead might do the 
trick… or alternatively we could just let the underlying queue be concurrent 
all the time and enforce the max ops via making the semaphore always 
instantiated (in the case of max ops being 1) and initializing it to 1 to gate 
the operations.

> On May 5, 2016, at 1:15 AM, Mamatha Busi via swift-corelibs-dev 
>  wrote:
> 
> Hello
>  
> Code snippet:
> 
> ———
> 
>  let operation1 : NSBlockOperation = NSBlockOperation (block: {
> 
> sleep(1)
> 
> print("Opertion1")
> 
> })
> 
> let operation2 : NSBlockOperation = NSBlockOperation (block: {
> 
> sleep(1)
> 
> print("Opertion2”)
> 
> })
> 
> 
> var operations = [NSOperation]()
> 
> operations.append(operation1)
> 
> operations.append(operation2)
> 
>  
> let queue = NSOperationQueue()
> 
> queue.maxConcurrentOperationCount = 1
> 
> queue.addOperations(operations, waitUntilFinished: true)
> 
>  
>  
> 
>  
> The above code snippet of adding operations to an operation queue and 
> executing with the property ‘maxConcurrentOperationCount = 1’ fails while 
> executing the above with the OpenSource Foundation and libDispatch of MAC 
> inside Xcode. 
> 
> The error I am seeing is: 
> 
> fatal error: unexpectedly found nil while unwrapping an Optional value
> 
> Stack trace points to: attr = DISPATCH_QUEUE_SERIAL 
> 
> which implies that the libDispatch macro is coming as nil during the creation 
> of the serial queue using libDispatch in the file NSOperationQueue
> 
> The same test-case passes on OSx. 
> 
> When I do not restrict the serial operation i.e. I remove ‘  
> queue.maxConcurrentOperationCount = 1’ , test case executes successfully. 
> 
> Setting it to a different value other than 1 also causes no problems. 
> 
> Am I doing something wrong with the API. If I set the property ‘ 
> queue.maxConcurrentOperationCount = 1’ after adding operations to the queue, 
> then the problem does not occur. But then this restricts me to control the 
> operation execution to be serial. So, I expect the above snippet to work on 
> OpenSource as well. Any thoughts on this?
> 
>  
> Thank you.
>  
> 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] NSEnergyFormatter

[Philippe Hausler via swift-corelibs-dev]

The formatter in this case should probably query ICU4C’s function 
uplrules_select (and other associated functions). On Darwin energy, length and 
mass formatters all funnel to one unit formatter that can abstractly handle 
each of those cases (which might not be a bad idea to have in the swift version 
too.

> On Apr 18, 2016, at 1:56 AM, Vojtěch Šťavík via swift-corelibs-dev 
>  wrote:
> 
> Actually, I have a question. What is the best way to get localized names for 
> units? It seems Mauricio has the same question at 
> https://github.com/apple/swift-corelibs-foundation/pull/320 
>  .
> 
> Subject: Re: [swift-corelibs-dev] NSEnergyFormatter
> From: anthony.par...@apple.com
> Date: Fri, 15 Apr 2016 10:07:18 -0700
> CC: swift-corelibs-dev@swift.org
> To: sta...@outlook.com
> 
> We certainly appreciate help on this. Let us know if you have any questions.
> 
> - Tony
> 
> On Apr 15, 2016, at 7:24 AM, Vojtěch Šťavík via swift-corelibs-dev 
> > wrote:
> 
> Hey guys,
> 
> I'd like to help you with the project. I was looking for something simple to 
> start with and I'd choose NSEnergyFormatter. It seems to be pretty 
> straightforward. Is it OK when I start working on it or you have some other 
> plan for formatters?
> 
> Vojta
> @vojtastavik
> ___
> 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] NSOperationQueue and friends

[Philippe Hausler via swift-corelibs-dev]

the swift-corelibs-foundation compiled for Darwin does not define that yet 
either. Are you seeing issues with it when defined?


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

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

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

[Philippe Hausler via swift-corelibs-dev]

DEPLOYMENT_ENABLE_LIBDISPATCH should not be enabled unless you specifically 
enable it (this is until we get libdispatch fully integrated into the build 
system)

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

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

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

[Philippe Hausler via swift-corelibs-dev]

Is that on Linux? Perhaps it is because it is missing run loop interaction?

Sent from my iPhone

On Mar 26, 2016, at 10:52 AM, Daniel Eggert <danielegg...@me.com> wrote:

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

[swift-corelibs-dev] NSOperationQueue and friends

[Philippe Hausler via swift-corelibs-dev]

I know a few of you have been waiting for this: I just pushed an initial 
implementation of NSOperationQueue, NSOperation and NSBlockOperation. It is 
worth noting that this implementaiton has a few behavioral differences between 
this implementation and the one implemented in objective-c. Part of this 
difference is due to features like QoS not being cross platform portable or KVO 
not yet implementable in Swift. This is very much a work-in-progress; it needs 
unit tests and and a bit more polish, but hopefully it is good enough to get 
some work started in some other places.

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

Re: [swift-corelibs-dev] NSHTTPURLResponse.localizedStringForStatusCode()

[Philippe Hausler via swift-corelibs-dev]

Well the interesting part here is that it is a localized string for a status 
code, so these should be a human readable output intended for display. If they 
were just stringForStatusCode then I would agree they should match the RFC, but 
since it is localized I think we shouldn’t try and reimplement as something 
completely different if at all possible.

That all being said; if they don’t match 100% it isn’t such a big deal since 
they are just intended for display and nothing programmatic so no one _should_ 
be relying on the values...


> On Mar 17, 2016, at 10:27 AM, Ian Partridge via swift-corelibs-dev 
>  wrote:
> 
> Hi,
> 
> A quick question about implementing this method.
> 
> Do we want the strings returned to match those returned by the
> Objective-C implementation of Foundation, or follow RFC 2616?
> Currently they are inconsistent, e.g. Obj-C Foundation returns "no
> error" for status code 200, whereas the RFC says this is "OK".
> 
> The Obj-C implementation also returns strings for invalid status
> codes, instead of the empty string.  For example, if you ask for
> status code 666 (an invalid code) you get "server error".
> 
> My instinct is we should start afresh and follow the RFC, as people
> are unlikely to be relying on the content of these strings.
> 
> Thanks for your time!
> 
> -- 
> 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] NSURLSession & libcurl

[Philippe Hausler via swift-corelibs-dev]

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

Re: [swift-corelibs-dev] NSRegularExpression implementation

[Philippe Hausler via swift-corelibs-dev]

NSRegularExpression is backed by ICU’s uregex; there is no regex support in CF 
however since ICU is a pretty involved C API it would not be un-reasonable to 
create an accessor API to make certain behaviors easier to deal with in swift.

> On Jan 4, 2016, at 8:58 PM, Lukas Stabe via swift-corelibs-dev 
>  wrote:
> 
> I have been thinking about trying to work on NSRegularExpression in 
> corelibs-foundation, although I am not yet sure I’ll have time for it.
> 
> If I were to attempt it, am I correct in assuming that it should be based on 
> icus (u)regex.h? I have not found any Regex support in CoreFoundation.
> 
> — Lukas
> ___
> 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] Locale formatting (UAMeasureFormat)

[Philippe Hausler via swift-corelibs-dev]

Length, Energy and Mass formatters should definitely use the ICU backing. It 
might be a good idea to funnel them all into one unit formatter access point. I 
personally find it is sometimes easier to interface to C APIs in C and expose 
them back up as simple funnel methods but it depends on which APIs you are 
interfacing with so ymmv. The formatters are locale independent in that they 
should probably just have a simple callout to uameasfmt_format when creating 
strings from values given a certain unit type.


> On Jan 5, 2016, at 1:23 PM, Johan Jensen via swift-corelibs-dev 
>  wrote:
> 
> I was having a quick look at implementing some of the not-yet-implemented 
> formatters but quickly realized that some of them are highly locale dependent.
> After a quick look I found uameasureformat.h 
> 
>  and uameasfmt_format() which looks quite interesting.
> Is it possible to use these functions?
> If so, should a Swift wrapper be made?
> If not, how is locale dependent formatters expected to be implemented?
> 
> — Johan
>  ___
> 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] bridging (SR-138)

[Philippe Hausler via swift-corelibs-dev]

String is bridged it just is not yet implicitly converted via the compiler; we 
are missing certain functionality due to the compiler not supporting the objc 
code paths on linux.

The re-naming of swift classes exposed from Foundation will likely leave the 
class NSString still a thing (however it likely will have some special case of 
naming since there is a conflict between Foundation’s String and Swift’s String 
that is yet to be determined fully on how that will be done), so it is still a 
bit up-in-the-air on how that will be achieved. However since there are desired 
behavioral differences between NSString and String we cannot just wholesale 
make it an extension since some of the functions that apply to NSString don’t 
make much sense for String (e.g. characterAtIndex etc).

The bug you are probably looking for is: https://bugs.swift.org/browse/SR-138. 
Basically what we need is _ObjectTypeBridgeable to behave similarly to the type 
conversion portion of _ObjectiveCBridgeable. This would likely be primarily 
work in the compiler and also a bit of work in the stdlib for a few of the 
overlay extensions etc.


> On Jan 2, 2016, at 12:24 AM, Drew Crawford via swift-corelibs-dev 
>  wrote:
> 
> I've noticed that e.g. String is not bridged to NSString.  The expected 
> workaround seems to be calling .bridge() everywhere.
> 
> 1.  Is there a plan for bridging e.g. String with NSString?
> 2.  Would it be appropriate to PR in the meantime e.g.
> 
> extension String {
> public func cStringUsingEncoding(encoding: UInt) -> 
> UnsafePointer {
> return self.bridge().cStringUsingEncoding(encoding)
> }
> }
> 
>   3.  The README also says
> 
>> We will also drop the 'NS' prefix from all Foundation classes
> 
> 
> ...is that the resolution?  e.g what is currently class NSString will become 
> instead extension String?  Is there a bug open for that?
> 
> ___
> 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] relationship of CF

[Philippe Hausler via swift-corelibs-dev]

Responses inline:

> On Jan 2, 2016, at 3:58 AM, Drew Crawford via swift-corelibs-dev 
>  wrote:
> 
> I had a question about something I saw in the docs:
> 
>> A significant portion of the implementation of Foundation on Apple platforms 
>> is provided by another framework called CoreFoundation (a.k.a. CF). CF is 
>> written primarily in C and is very portable. Therefore we have chosen to use 
>> it for the internal implementation of Swift Foundation where possible. As CF 
>> is present on all platforms, we can use it to provide a common 
>> implementation everywhere.
> 
> (emphasis added)
> 
> Is the intent of this paragraph to suggest that most PRs to 
> swift-corelibs-foundation should be a C-language implementation to CF with a 
> light Swift wrapper?  That goes against my intuition, but it "seems to be" a 
> plain reading of the paragraph.

I think the underlying intent is that we should use the right tools for the 
job; where it makes sense, even the standard library uses C++. Similarly some 
of the interfaces for ICU for example make much more sense to encapsulate with 
CF (and re-use some of the existing cross platform abstractions). Some classes 
will be a thin veneer on top of CF, where-as others will be a completely swift 
implementation. Take the two cases of NSCalendar and NSThread. CF provides some 
very hard to write (and hard to get right) implementations of calendrical math, 
even though I wrote a good portion of the NSCalendar swift implementation; I am 
definitely glad that there was an implementation I could fall back upon to deal 
with that logic. The counterpoint of NSThread; we could have wrapped up a 
CFThreadRef type object and bridged it across but It made sense to keep 
NSThread in the realm of Swift not only for a potential example of dealing with 
posix APIs for the community but also it just worked out more cleanly in my 
opinion.

I have not crunched the numbers but I have a gut feeling that a large majority 
of the pull requests have been mostly Swift implementations and only a few of 
them have been thin veneers on-top-of CF and even fewer have been changes to CF 
itself.

> 
> its justification about "all platforms" is also strange–I know CF "kind of" 
> builds for Windows, but is anyone actually testing it there?  To make sure we 
> aren't breaking it?  Or does "all platforms" mean something else here?

I know there have been efforts to port swift to FreeBSD and to new 
architectures like ARM-elf for things like Raspberry Pi, I would not be 
surprised that there are efforts to port to Android or Windows out there. 
Granted we do not have any CI provided by Apple to ensure not breaking these 
efforts but I think that the community will be interested in keeping these 
things running since a cross platform framework and language are really 
appealing (even Apple makes a few products for Android and Windows…)

As of current the Windows target is not held directly from the point at which 
this CF was cut from; so I would probably say “trust but verify” and I would 
not be surprised that there may be a few breaking points there that need to be 
re-looked at for that platform. I am certain that if someone took up a new 
target like Windows that would be met with great enthusiasm from all of the 
swift community. I was ecstatic when I saw that there was a FreeBSD port.

I think the one major thing to take under consideration is that alternate 
platforms than Mac OS X and Ubuntu 14/15 don’t have integration into the CI 
that the swift project maintains. I think however if there is strong desire out 
there it would be interesting to have externally maintained build servers 
provided by the community to verify these targets. I am not in charge of that 
type of decision but I would definitely think that it would be an amiable goal 
and I would think that it would be worthwhile to discuss further.

> 
> I feel like this paragraph is an opportunity to explain to a patch author how 
> to structure their patch between use/maintenance/contributions to the CF 
> layer vs the Swift layer.  I feel like it could do a much better job, but I 
> don't understand what the design guidance actually is, so I can't fix it.
> 

Things that enter into CF territory will be things that we will consider with a 
very close eye on them because they will likely move up-stream into the 
CoreFoundation that ships with our current platforms so that the lifecycle 
completes back out to the exported version in the open-source side of it.  The 
Foundation part of the story is a bit more mutable since we have the 
Objective-C version that will still be maintained. That being said there is a 
very strong desire to keep these in parity; we may use some of the interfaces 
in the swift version to try out what people think of these APIs (most of these 
are marked with experimental, and if they are not we should either correct them 
to be the same or mark them as such). Furthermore the 

Re: [swift-corelibs-dev] NSCoding methods

[Philippe Hausler via swift-corelibs-dev]

plication’s class but 
>> hey it might happen...
>> class NSUUID : NSObject, NSCoding {
>> let uuid: Foundation.NSUUID
>> required init?(coder aDecoder: NSCoder) {
>> uuid = aDecoder.decodeObjectForKey("my.uuid") as! Foundation.NSUUID
>> }
>> override init() {
>> uuid = Foundation.NSUUID()
>> }
>> func encodeWithCoder(aCoder: NSCoder) {
>> aCoder.encodeObject(uuid, forKey: "my.uuid")
>> }
>> }
>> 
>> let uuid = NSUUID()
>> let data = NSKeyedArchiver.archivedDataWithRootObject(uuid)
>> let archive = try! NSPropertyListSerialization.propertyListWithData(data, 
>> options: [], format: nil)
>> print(archive)
>> 
>> prints the following:
>> 
>> {
>> "$archiver" = NSKeyedArchiver;
>> "$objects" = (
>> "$null",
>> {
>> "$class" = "> [0x7fff7ab33bb0]>{value = 4}";
>> "my.uuid" = "> [0x7fff7ab33bb0]>{value = 2}";
>> },
>> {
>> "$class" = "> [0x7fff7ab33bb0]>{value = 3}";
>> "NS.uuidbytes" = <546e5b5e 15c244a1 aa96eb90 30c3f7f6>;
>> },
>> {
>> "$classes" = (
>> NSUUID,
>> NSObject
>> );
>> "$classname" = NSUUID;
>>     },
>>         {
>> "$classes" = (
>> "Archiver.NSUUID",
>> NSObject
>> );
>> "$classname" = "Archiver.NSUUID";
>> }
>> );
>> "$top" = {
>> root = "{value = 
>> 1}";
>> };
>> "$version" = 10;
>> }
>> 
>> Granted this is a questionable name for a class but it illustrates which 
>> class names are encoded where and how they should be interpreted in the 
>> pre-existing archive format; which we will have to figure out some sensible 
>> way of inflating and deflating to/from disk/network etc.
>> 
>>> On Dec 23, 2015, at 2:37 PM, Jordan Rose <jordan_r...@apple.com 
>>> <mailto:jordan_r...@apple.com>> wrote:
>>> 
>>> No, we cannot encode things "non-mangled but with the namespace". For any 
>>> type other than top-level non-generic class types, using a non-mangled name 
>>> is not unique. The only correct answer for arbitrary classes is to use 
>>> mangled names, or something that maps one-to-one with mangled names.
>>> 
>>> Now, Foundation classes are not arbitrary classes, but then I don't see why 
>>> we'd need to use mangled names for those. We can just use the plain old 
>>> Objective-C names that the OS X classes use today.
>>> 
>>> Jordan
>>> 
>>>> On Dec 22, 2015, at 10:16, Philippe Hausler via swift-corelibs-dev 
>>>> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
>>>> 
>>>> To clarify the goals: I think it is reasonable for us to have a goal to be 
>>>> able to encode/decode archives from foreign targets; e.g. linux encodes an 
>>>> archive and mac os x decodes or iOS encodes and linux decodes. This will 
>>>> allow for server architecture to transmit binary archives across the wire. 
>>>> This will mean that we will want to have the encoded class names from the 
>>>> application scope to be encoded as the non mangled name but with the 
>>>> namespace. However this presents a problem; Foundation will have a 
>>>> namespace which will need to be inferred both for encoding and decoding. 
>>>> Thankfully there may be a reasonable way to approach this;
>>>> 
>>>> public class func classNameForClass(cls: AnyClass) -> String?
>>>> public class func setClassName(codedName: String?, forClass cls: AnyClass)
>>>> 
>>>> These methods can be used to allow for translation of classes by 
>>>> registering the appropriate classes for a “shortened” name that drops the 
>>>> Foundation/SwiftFoundation namespace prefix during encoding.
>>>> 
>>>>> On Dec 22, 2015, at 2:45 AM, Luke Howard via swift-corelibs-dev 
>>>>> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> 
>>>>> wrote:
>>>>> 
>>>>> 
>>>>>> On 22 Dec 2015, at 5:50 AM, Jordan Rose <jordan_r...@apple.com 
>>>>>> <mailto:jordan_r...@apple.com>> wrote:
>>>>>> 
>>>>>> IMHO on Linux NSKeyedArchiver should always use mangled names. If we 
>>>>>> want cross-platform archives, we should set up standard substitutions, 
>>>>>> but given that Swift classes exposed to Objective-C are archived with 
>>>>>> their full names it doesn't make sense to use "half the name" in the 
>>>>>> archive.
>>>>> 
>>>>> You mean namespaced but unmangled yes? If so I agree.
>>>>> 
>>>>> BTW I found a couple of small CF nits:
>>>>> 
>>>>> * in CFDictionaryGetKeysAndValues(), keybuf and valuebuf are transposed 
>>>>> in the call to CF_SWIFT_FUNCDISPATCHV(NSDictionary.getObjects())
>>>>> 
>>>>> * _CFSwiftDictionaryGetKeysAndValues() does not handle keybuf or valbuf 
>>>>> being NULL (either of which are valid when calling 
>>>>> CFDictionaryGetKeysAndValues())
>>>>> 
>>>> 
>>>> This is a bit un-related to NSCoding and the transposition is probably a 
>>>> mistake if it is inverted (the CF method should be reversed from the NS 
>>>> method to mimic the objc counterpart)
>>>> 
>>>>> — Luke
>>>>> ___
>>>>> 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] NSCoding methods

[Philippe Hausler via swift-corelibs-dev]

To clarify the goals: I think it is reasonable for us to have a goal to be able 
to encode/decode archives from foreign targets; e.g. linux encodes an archive 
and mac os x decodes or iOS encodes and linux decodes. This will allow for 
server architecture to transmit binary archives across the wire. This will mean 
that we will want to have the encoded class names from the application scope to 
be encoded as the non mangled name but with the namespace. However this 
presents a problem; Foundation will have a namespace which will need to be 
inferred both for encoding and decoding. Thankfully there may be a reasonable 
way to approach this;

public class func classNameForClass(cls: AnyClass) -> String?
public class func setClassName(codedName: String?, forClass cls: AnyClass)

These methods can be used to allow for translation of classes by registering 
the appropriate classes for a “shortened” name that drops the 
Foundation/SwiftFoundation namespace prefix during encoding.

> On Dec 22, 2015, at 2:45 AM, Luke Howard via swift-corelibs-dev 
>  wrote:
> 
> 
>> On 22 Dec 2015, at 5:50 AM, Jordan Rose  wrote:
>> 
>> IMHO on Linux NSKeyedArchiver should always use mangled names. If we want 
>> cross-platform archives, we should set up standard substitutions, but given 
>> that Swift classes exposed to Objective-C are archived with their full names 
>> it doesn't make sense to use "half the name" in the archive.
> 
> You mean namespaced but unmangled yes? If so I agree.
> 
> BTW I found a couple of small CF nits:
> 
> * in CFDictionaryGetKeysAndValues(), keybuf and valuebuf are transposed in 
> the call to CF_SWIFT_FUNCDISPATCHV(NSDictionary.getObjects())
> 
> * _CFSwiftDictionaryGetKeysAndValues() does not handle keybuf or valbuf being 
> NULL (either of which are valid when calling CFDictionaryGetKeysAndValues())
> 

This is a bit un-related to NSCoding and the transposition is probably a 
mistake if it is inverted (the CF method should be reversed from the NS method 
to mimic the objc counterpart)

> — Luke
> ___
> 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] NSCoding methods

[Philippe Hausler via swift-corelibs-dev]

Somewhat; the mangled symbols are technically searchable by dlsym but that 
seems like a hack. Perhaps one of the stdlib/compiler team might be able to 
speak more on this than myself and they may have suggestions for a better way. 
Foundation is at a special spot in which we can sometimes get special runtime 
considerations for these types of things. 

The tricksy spot would be cases where you would need to fetch a class without 
the module name. 

For example NSUUID is defined by it’s module name Foundation.NSUUID; in that a 
program could have it’s own NSUUID that is totally different (naming it the 
same thing would be confusing to read and potentially viewed as bad form but it 
can be done…). That would result in MyApplication.NSUUID to define the symbolic 
name of the item. From the perspective of NSKeyedArchiver it will encode things 
as NSUUID (without the namespace) in that in the realm of objc there can be 
only one.

The tl;dr is that there is no manifest of classes or table of names stored in 
the binaries; just symbols.

> On Dec 18, 2015, at 10:57 PM, Luke Howard  wrote:
> 
> 
>> Specifically there is no NSClassFromString yet. I would say if you are 
>> looking for a place to start, perhaps coming up with a good strategy for 
>> accomplishing that in a uniform manner (for both Foundation classes as well 
>> as user classes) would be a good step in the right direction to getting this 
>> started.
> 
> Does Swift have enough runtime metadata to do this for native Swift classes?
> 
> -- Luke

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

Re: [swift-corelibs-dev] Possible Proposal: Foundation corelibs API change necessary for NSPredicate

[Philippe Hausler via swift-corelibs-dev]

As a general rule of thumb we ❤️radars. In this case I have already filed a bug 
with the component owner since it clearly looks like this is perhaps a 
incorrectly annotated API. So a PR for this is quite reasonable to change to ? 
since it would be a bit difficult to implement else wise.

> On Dec 14, 2015, at 10:22 AM, Kevin Lundberg  wrote:
> 
> Great, should I file a radar on bugreport.apple.com 
>  for this? And if it’s simple enough to fix that 
> can I apply the same fix to the SwiftFoundation API as a PR without any extra 
> process?
> 
> --
> Kevin Lundberg
> ke...@klundberg.com 
>> On Dec 14, 2015, at 1:09 PM, Philippe Hausler > > wrote:
>> 
>> This might actually just be a bug in our annotations of what is nullable and 
>> what is not. I would have to double check but it seems pretty reasonable 
>> that it should have been nullable to begin with.
>> 
>>> On Dec 14, 2015, at 10:06 AM, Kevin Lundberg via swift-corelibs-dev 
>>> > wrote:
>>> 
>>> I have a pending pull request that needs a little more work around 
>>> NSPredicates, but in my testing on darwin foundation, I’ve discovered what 
>>> appears to be an obj-c nullability annotation bug. When constructing a 
>>> block predicate, the type of the block is this:
>>> 
>>> (AnyObject, [String: AnyObject]?) -> Bool
>>> 
>>> However, the type signature of evaluateObject(_:substitutionVariables:) is
>>> 
>>> (AnyObject?, [String: AnyObject]?) -> Bool
>>> 
>>> Note the optional AnyObject here. In Xcode 7.2 with swift 2.1, the 
>>> following code causes an EXC_BAD_ACCESS signal when calling 
>>> evaluateWithObject: in a playground:
>>> 
>>> let pred = NSPredicate(block: { (obj: AnyObject, bindings: [String: 
>>> AnyObject]?) -> Bool in
>>> print(obj)
>>> return false
>>> })
>>> print(pred.evaluateWithObject(nil))
>>> 
>>> because obj is in fact optional here, but the type of the block does not 
>>> allow for this.
>>> 
>>> There are two possible approaches here; removing the optional type from 
>>> evaluateWithObject, or adding it to the block constructor for NSPredicate. 
>>> Such a change is also presumably trivial to port back to darwin foundation, 
>>> as that at minimum would need to merely change nullability annotations for 
>>> these components of NSPredicate. These involve a public-api change which by 
>>> my understanding needs to go through the swift evolution process.
>>> 
>>> Before sending this over to swift-evolution which is already pretty 
>>> high-traffic, I wanted to float this here to make sure that this is 
>>> appropriate for that process. Is it enough to draft a proposal outright or 
>>> for comprehensiveness sake should I also send this out to that list to open 
>>> discussion first?
>>> 
>>> Is there anyone on this list that has an opinion over which approach to 
>>> take for changing the api here?
>>> 
>>> Thanks!
>>> 
>>> --
>>> Kevin Lundberg
>>> ke...@klundberg.com 
>>> 
>>> ___
>>> swift-corelibs-dev mailing list
>>> swift-corelibs-dev@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>>> 
>> 
> 

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

Re: [swift-corelibs-dev] libdispatch build issue

[Philippe Hausler via swift-corelibs-dev]

This is only tangentially related: but I was attempting to build dispatch as 
well to start work on CFRunLoop and a few other dispatch bound features in 
Foundation on linux. I was seeing similar failures as Dzianis Fedarenka. Is 
there a branch/fork that I can grab to test this stuff out w/ bringing stuff up 
in Foundation?

My question is that of design and status of where things are at; CFRunLoop 
requires a method to interoperate with the main dispatch queue via 
_dispatch_get_main_queue_port_4CF and _dispatch_main_queue_callback_4CF. 
CFRunLoop will need to transact upon the same event source type as dispatch to 
ensure the main queue behaves correctly - so what type of event source should 
we be using? A socket? A producer/consumer notification via pthread conditions?

> On Dec 11, 2015, at 8:27 AM, David P Grove via swift-corelibs-dev 
>  wrote:
> 
> swift-corelibs-dev-boun...@swift.org wrote on 12/11/2015 11:19:15 AM:
> > 
> > The linux port is in progress, and even if it built, right now, it 
> > wouldn’t be functional.
> > 
> > -Pierre
> > 
> > Yes. I completely understand that there linux port is not 
> > functional. So I want to contribute to it. But it's practically 
> > impossible since there is no usable build system :(.
> 
> It's limping along.  We've managed to run a few programs successfully. 
> 
> I think the next step is actually to get the test suite to compile & build so 
> we can see what functionally isn't working yet.
> 
> Pierre and Daniel, we could use some guidance on how to approach this.  The 
> tests have quite a few unguarded includes of mach header files, uses of mach 
> types, and includes of Foundation.  How would you like this porting to 
> proceed?  Hubertus has already done some initial poking at it, but getting 
> direction on the intended outcome would be very helpful.
> 
> thanks,
> 
> --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] [swift-evolution] Proposal: add `noescape` attribute to public API (particularly libdispatch)

[Philippe Hausler via swift-corelibs-dev]

To re-iterate my comment on github; I think this is a great idea. 

There are a couple of suggestions for scope limiting; since this will require 
changes in the c and objective-c layers to support this attribute it would be 
good to limit this for now to just the core libraries (dispatch, XCTest and 
Foundation). 

Most likely future optimizations in c and objective c code can be applied in 
addition to the positive effect to swift code.

> On Dec 8, 2015, at 12:02 AM, Jacob Bandes-Storch via swift-evolution 
>  wrote:
> 
> Alright, I've written up a proposal: 
> https://github.com/apple/swift-evolution/pull/40 
> 
> 
> Feedback welcome!
> 
> Jacob
> 
> On Sat, Dec 5, 2015 at 2:25 PM, Jacob Bandes-Storch  > wrote:
> On Sat, Dec 5, 2015 at 1:40 PM, Tony Parker  > wrote:
> One topic I wanted to discuss was finding a comprehensive list of API that 
> needs the attribute.
> 
> On this subject, here are some other APIs which could use the annotation. 
> Again, I think these should be annotated even in the C/Objective-C headers, 
> so they can benefit C/Objective-C callers as well.
> 
> - bsearch, heapsort, qsort, mergesort, psort, and their _b variants
> 
> "passing test" methods:
> - -[{NSArray,NSOrderedSet} indexOfObjectPassingTest:]
> - -[{NSArray,NSOrderedSet} indexesOfObjectsPassingTest:]
> - -[{NSArray,NSOrderedSet} indexOfObjectsAtIndexes:passingTest:]
> - -[{NSArray,NSOrderedSet} indexesOfObjectsAtIndexes:passingTest:]
> - -[SCNNode childNodesPassingTest:]
> - -[SCNSceneSource entriesPassingTest:]
> - -[AVAudioUnitComponentManager componentsPassingTest:]
> - -[NSIndexSet indexPassingTest:]
> - -[NSIndexSet indexWithOptions:passingTest:]
> - -[NSIndexSet indexesPassingTest:]
> - -[NSIndexSet indexesWithOptions:passingTest:]
> - -[NSIndexSet indexInRange:options:passingTest:]
> - -[NSIndexSet indexesInRange:options:passingTest:]
> - -[NSSet objectsPassingTest:]
> - -[NSSet objectsWithOptions:passingTest:]
> - -[NSDictionary keysOfEntriesPassingTest:]
> - -[NSDictionary keysOfEntriesWithOptions:passingTest:]
> 
> "using comparator" methods:
> - -[NSArray indexOfObject:inSortedRange:options:usingComparator:]
> - -[NSArray sortedArrayUsingComparator:]
> - -[NSArray sortedArrayWithOptions:usingComparator:]
> - -[NSDictionary keysSortedByValueUsingComparator:]
> - -[NSDictionary keysSortedByValueWithOptions:usingComparator:]
> - -[NSMutableArray sortUsingComparator:]
> - -[NSMutableArray sortWithOptions:usingComparator:]
> - -[NSMutableOrderedSet sortWithOptions:usingComparator:]
> - -[NSMutableOrderedSet sortRange:options:usingComparator:]
> 
>  (and some of these have "usingFunction" variants)
> 
> "enumerate using block" methods:
> - -[NSTableView enumerateAvailableRowViewsUsingBlock:]
> - -[SKPhysicsWorld enumerateBodiesAtPoint:usingBlock:]
> - -[SKPhysicsWorld enumerateBodiesInRect:usingBlock:]
> - -[NSData enumerateByteRangesUsingBlock:]
> - -[SCNNode enumerateChildNodesUsingBlock:]
> - -[SCNNode enumerateChildNodesWithName:usingBlock:]
> - -[NSIndexSet enumerateIndexesUsingBlock:]
> - -[NSIndexSet enumerateIndexesWithOptions:usingBlock:]
> - -[NSDictionary enumerateKeysAndObjectsUsingBlock:]
> - -[NSDictionary enumerateKeysAndObjectsWithOptions:usingBlock:]
> - -[NSString enumerateLinesUsingBlock:]
> - -[NSString enumerateSubstringsInRange:options:usingBlock:]
> - -[{NSArray,NSSet,NSOrderedSet} enumerateObjectsUsingBlock:]
> - -[{NSArray,NSSet,NSOrderedSet} enumerateObjectsWithOptions:usingBlock:]
> - -[NSIndexSet enumerateRangesUsingBlock:]
> - -[NSIndexSet enumerateRangesWithOptions:usingBlock:]
> - -[NSIndexSet enumerateRangesInRange:options:usingBlock:]
> - -[MPMediaEntity enumerateValuesForProperties:usingBlock:]
> - -[NSMetadataQuery enumerateResultsUsingBlock:]
> - -[NSMetadataQuery enumerateResultsWithOptions:usingBlock:]
> 
> misc:
> - -[NSDocument performSynchronousFileAccessUsingBlock:]
> 
> Wow, that's more than I expected to find! This is obviously beyond the scope 
> of just libdispatch, and I think a lot of these should probably change 
> upstream, in their original frameworks, internally (not something that 
> community members can really contribute to).
> 
> Arguably, the "enumerateXUsingBlock:" pattern should be bridged to Swift as 
> something SequenceType-ish which can be `for-in`ed.
> 
> Jacob Bandes-Storch
> 
>  ___
> swift-evolution mailing list
> swift-evolut...@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev