[swift-corelibs-dev] Foundation and NSDecimal

[Alex Blewitt via swift-corelibs-dev]

The Framework function 

NS_INLINE BOOL NSDecimalIsNotANumber(const NSDecimal *dcm)

has been imported into Swift on both Darwin and Linux as

:type lookup NSDecimalIsNotANumber
@discardableResult func NSDecimalIsNotANumber(_ dcm: 
Swift.UnsafePointer) -> Swift.Bool
:type lookup NSDecimalIsNotANumber
func NSDecimalIsNotANumber(_ dcm: Swift.UnsafePointer) -> 
Swift.Bool

However I think this should instead be imported as a member function on the 
Decimal type, instead of passing through a pointer.

extension Decimal {
  public func isNotANumber() -> Bool
}

This may not have been picked up by the automatic renaming progress because 
it's a const pointer, and because it's an NS_INLINE defined in the header, 
instead of in an implementation file.

There are some other global constants NSDecimalMaxSize and NSDecimalNoScale, 
which should probably be implemented as constants in the Decimal type as well 
e.g.

extension Decimal {
  public let maxSize = 8
  public let noScale =  Int16.max
}

Since this would need to be fixed in both the Swift Linux foundation 
implementation and the Darwin overlay (and it would be a breaking change) what 
is the right process to be able to fix this?

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

Re: [swift-corelibs-dev] Foundation and NSDecimal

[Alex Blewitt via swift-corelibs-dev]

I agree, but I'm not sure where that's coming from. It seems to be being 
imported from CoreFoundation on Darwin, and although it's defined this way in 
NSDecimal.h in the Foundation framework:

NS_INLINE BOOL NSDecimalIsNotANumber(const NSDecimal *dcm)
  { return ((dcm->_length == 0) && dcm->_isNegative); }

I'm not sure why the @discardableResult attribute is being added here; perhaps 
it's to do with the fact that it's an NS_INLINE function. Should I raise a 
separate bug for that?

Alex

> On 28 Sep 2016, at 17:32, Kenny Leung via swift-corelibs-dev 
>  wrote:
> 
> I would also say that this should not be marked as @discardableResult, since 
> its only purpose is to report back yes or no, it would be kind of suspicious 
> if the it wasn’t used.
> 
> -Kenny
> 
> 
>> On Sep 27, 2016, at 5:34 AM, Alex Blewitt via swift-corelibs-dev 
>>  wrote:
>> 
>> The Framework function 
>> 
>> NS_INLINE BOOL NSDecimalIsNotANumber(const NSDecimal *dcm)
>> 
>> has been imported into Swift on both Darwin and Linux as
>> 
>> :type lookup NSDecimalIsNotANumber
>> @discardableResult func NSDecimalIsNotANumber(_ dcm: 
>> Swift.UnsafePointer) -> Swift.Bool
>> :type lookup NSDecimalIsNotANumber
>> func NSDecimalIsNotANumber(_ dcm: Swift.UnsafePointer) 
>> -> Swift.Bool
>> 
>> However I think this should instead be imported as a member function on the 
>> Decimal type, instead of passing through a pointer.
>> 
>> extension Decimal {
>> public func isNotANumber() -> Bool
>> }
>> 
>> This may not have been picked up by the automatic renaming progress because 
>> it's a const pointer, and because it's an NS_INLINE defined in the header, 
>> instead of in an implementation file.
>> 
>> There are some other global constants NSDecimalMaxSize and NSDecimalNoScale, 
>> which should probably be implemented as constants in the Decimal type as 
>> well e.g.
>> 
>> extension Decimal {
>> public let maxSize = 8
>> public let noScale =  Int16.max
>> }
>> 
>> Since this would need to be fixed in both the Swift Linux foundation 
>> implementation and the Darwin overlay (and it would be a breaking change) 
>> what is the right process to be able to fix this?
>> 
>> 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

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

[swift-corelibs-dev] Failing test due to network XML validation

[Alex Blewitt via swift-corelibs-dev]

There's a test which attempts to download an XML DTD from an external file, 
which fails when there's an intermittent network connection:

  Test Case 'TestNSArray.test_writeToFile' started at 09:15:53.214
  I/O warning : failed to load external entity 
"http://www.apple.com/DTDs/PropertyList-1.0.dtd";
  .../swift-corelibs-foundation/TestFoundation/TestNSArray.swift:492: error: 
TestNSArray.test_writeToFile : failed - XMLDocument   failes to read / validate 
contenets

It's probably not a good idea to have remote DTD parsing enabled, especially 
for testing a write to file method. Plus, there's a spelling error or two :)

This happens because the XML document has 'validate' called on it:

  let plistDoc = try XMLDocument(contentsOf: URL(fileURLWithPath: 
testFilePath!, isDirectory: false), options: [])
  try plistDoc.validate()

https://github.com/apple/swift-corelibs-foundation/blob/e05884bd835f6ee22e7c0b0484326d63c31d554a/TestFoundation/TestNSArray.swift#L485-L486
 


I don't think the validate call is adding anything here, because if it's 
invalid then the subsequent assert will fail, and we're just testing whether or 
not we can read the contents from file.

Should we remove the try/validate statement here?

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

Re: [swift-corelibs-dev] Calendar identifiers

[Alex Blewitt via swift-corelibs-dev]

> On 4 Oct 2016, at 10:29, Pushkar N Kulkarni via swift-corelibs-dev 
>  wrote:
> 
> Hi there, 
> 
> I've hit an obstacle while working on a crash seen in initing a Calendar 
> (https://bugs.swift.org/browse/SR-2551) 
> 
> 
> For the Calendar initialiser "init(identifier: Calendar.Identifier)", the 
> possible values of Calendar.Identifier are listed here 
> . 
> However, we eventually end up calling 
> "_CFCalendarInitWithIdentifier(CFCalendarRef calendar, CFStringRef 
> identifier)" and the latter works only for a specific set of calendar 
> identifiers. See this if statement:
>
> https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/Locale.subproj/CFCalendar.c#L239
>  
> 
> 
> For other identifier values, we crash (that is SR-2551). On mac, all the 
> identifier values are supported. It seems that the calendar identifier is 
> ultimately encoded as a key-value pair in the locale ID for the calendar.  
> 
> Can anybody please help me understand the rationale of the if-statement 
> above? I am new to ICU. I did search for justifications but didn't come 
> across convincing. 

The if statement is canonicalising the reference to the constant e.g. 
kCFCalendarIdentifierBuddhist. This allows other instances to be passed in but 
then resolved to the same instance, such that pointer comparisons work for 
future calls. The same is done for Swift.

On macOS, there are additional checks in the CoreFoundation equivalent (such as 
kCFCalendarIdentifierISO8601) which is why it works on Darwin. However, I don't 
know if there were specific reasons for excluding the ISO8601 calendar, unless 
the ICU library doesn't understand it. Testing adding support should be a case 
of doing something similar to this commit, which re-enabled the Chinese 
calendar:

https://github.com/apple/swift-corelibs-foundation/commit/c1d940dd6099de65f959fd42274cf0e65984efe0
 

Of course building with the 'if' switch enabled may highlight other issues, but 
on a quick test build it seems that adding the additional if case to the 
statement results in the ISO8601 calendar being returned. I'll let others 
explain in more detail if there's some specific subtlety for why it was left 
out in the first place.

Alex
___
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] Linux - Calendar date(byAdding:to:wrappingComponents:) returns nil when it shouldn't?

[Alex Blewitt via swift-corelibs-dev]

> On 5 Oct 2016, at 16:48, Alex Blewitt via swift-users  
> wrote:
> 
> 
>> On 4 Oct 2016, at 20:10, Jason Ji via swift-users > > wrote:
>> 
>> Hello,
>> 
>> I'm having an issue with (NS)Calendar on Linux which I think is a bug, but I 
>> just wanted to check first if it was just me or if this is indeed a bug. 
>> I've filed a bug report here, just in case: 
>> https://bugs.swift.org/browse/SR-2846 
>> 
>> In short, Calendar has a method date(byAdding:to:wrappingComponents:) which 
>> returns a new date which is the result of date arithmetic on the passed-in 
>> date. It works fine on El Capitan, but doesn't seem to work properly on 
>> Ubuntu 14.04. Below is some sample code:
>> 
>> import Foundation
>> 
>> let today = Date()
>> let diffComponents = DateComponents(day: -1)
>> let newDate = Calendar.current.date(byAdding: diffComponents, to: today) 
>> //returns nil
>> 
>> I've tried this in the swift REPL on Ubuntu 14.04 with both Swift 
>> 3.0-RELEASE, and the latest snapshot (October 2).
>> 
>> If anyone else could try this out as a sanity check for me, that would be 
>> great - I'd be happy to be embarrassed that I've done something wrong.
> 
> It's worth explicitly specifying a calendar (so that it rules out any 
> environmental setup) -- for example, Calendar(identifier:.gregorian). 
> However, I see 'nil' as well as the return result for this operation, so it 
> could be a bug.

I think the bug is here:

https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSCalendar.swift#L464
 


_convert(comps.isLeapMonth, type: "L", vector: &vector, compDesc: 
&compDesc)


The leap month is defined with a capital letter here, but a lower-case letter 
when it's decoded:

https://github.com/apple/swift-corelibs-foundation/blob/338f4bf3a89c75a0420b49f5701466e106af02b5/CoreFoundation/Locale.subproj/CFCalendar.c#L423
 


case 'l': return UCAL_IS_LEAP_MONTH;


The lower-case l should be the correct version so this probably needs to be 
changed here. In addition, there are optional-of-bool issues here; the 
'comps.isLeapMonth' is a boolean value, which means it attempts to roll forward 
the leap month (which doesn't make sense). I think the error was introduced 
here, although it didn't help that the capitalisation was also wrong at the 
time:

https://github.com/apple/swift-corelibs-foundation/commit/d3300b7118924d6ad8ba411d317f33eade854bc5
 

 

Alex

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

[swift-corelibs-dev] Adding retain to CFCalendar.c - SR2879

[Alex Blewitt via swift-corelibs-dev]

I'm looking at https://bugs.swift.org/browse/SR-2879 
 which is exposing itself through an 
over-release of a constant CF string (in this case, kCFEmptyString). I don't 
believe it to be a Swift related problem, because Swift doesn't get into the 
internals of CFCalendar where the problem occurs.

The problem is that CFCalendar releases the localeID when it's deallocated:

if (calendar->_localeID) CFRelease(calendar->_localeID);

https://github.com/apple/swift-corelibs-foundation/blob/1a76e814212e781a9d50782ee24117760cfe9b48/CoreFoundation/Locale.subproj/CFCalendar.c#L54
 

 

The problem is that when the localeID is assigned, it doesn't appear to be 
copied or renamed:

calendar->_localeID = CFLocaleGetIdentifier(CFLocaleGetSystem());

https://github.com/apple/swift-corelibs-foundation/blob/1a76e814212e781a9d50782ee24117760cfe9b48/CoreFoundation/Locale.subproj/CFCalendar.c#L252
 

 
https://github.com/apple/swift-corelibs-foundation/blob/1a76e814212e781a9d50782ee24117760cfe9b48/CoreFoundation/Locale.subproj/CFCalendar.c#L281
 

  

but elsewhere in the code, we do retain it:

   CFStringRef localeID = CFLocaleGetIdentifier(locale);
if (localeID != calendar->_localeID) {
CFRelease(calendar->_localeID);
CFRetain(localeID);

https://github.com/apple/swift-corelibs-foundation/blob/1a76e814212e781a9d50782ee24117760cfe9b48/CoreFoundation/Locale.subproj/CFCalendar.c#L303-L306
 

 

When a locale isn't supplied, it uses the default global one, which is defined 
to be an empty string:

CFLocaleRef CFLocaleGetSystem(void) {
CFLocaleRef locale;
CFLocaleRef uselessLocale = NULL; //if we lose the race creating the global 
locale, we need to release the one we created, but we want to do it outside the 
lock.
__CFLocaleLockGlobal();
if (NULL == __CFLocaleSystem) {
__CFLocaleUnlockGlobal();
locale = CFLocaleCreate(kCFAllocatorSystemDefault, CFSTR(""));
if (!locale) return NULL;

https://github.com/apple/swift-corelibs-foundation/blob/1a76e814212e781a9d50782ee24117760cfe9b48/CoreFoundation/Locale.subproj/CFLocale.c#L255-L261
 

 

The CFSTR("") results in a reference to kCFEmptyString, which reduces by one 
each time a CFCalendar is created and destroyed, leading to the (unrelated) 
test failures of https://github.com/apple/swift-corelibs-foundation/pull/667 
 as documented in 
https://bugs.swift.org/browse/SR-2879 

My suggestion is to insert a CFRetain when the calendar->locale is set, to 
balance out the CFRelease that's being performed in the deallocator. Building 
with this simple change and checking the retain count of kCFEmptyString 
verifies that it does fix the problem, although I'm open to suggestions as to 
improvements of where the retain takes place, if not on lines 252 and 282.

  1> import Foundation 
  2> :p (int)swift_retainCount(&__kCFEmptyString) 
(int) $11 = 1
  2> _ = Calendar(identifier:.gregorian)
  3> :p (int)swift_retainCount(&__kCFEmptyString) 
(int) $12 = 3
  3> _ = Calendar(identifier:.chinese)
  4> :p (int)swift_retainCount(&__kCFEmptyString) 
(int) $13 = 3
  4> _ = Calendar(identifier:.hebrew)
  5> :p (int)swift_retainCount(&__kCFEmptyString) 
(int) $14 = 3
  5> ^D

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

Re: [swift-corelibs-dev] Adding retain to CFCalendar.c - SR2879

[Alex Blewitt via swift-corelibs-dev]

That's what I was expecting, too, but then I found this:

https://github.com/apple/swift-corelibs-foundation/blob/1a76e814212e781a9d50782ee24117760cfe9b48/CoreFoundation/Base.subproj/CFInternal.h#L387-L389
 
<https://github.com/apple/swift-corelibs-foundation/blob/1a76e814212e781a9d50782ee24117760cfe9b48/CoreFoundation/Base.subproj/CFInternal.h#L387-L389>

#if DEPLOYMENT_RUNTIME_SWIFT
 // TODO: Pinned retain count for constants?
 #define __CFSTR_RC_INIT _CF_CONSTANT_OBJECT_STRONG_RC, 0,

Alex

> On 7 Oct 2016, at 17:51, Tony Parker  wrote:
> 
> Hi Alex,
> 
> Thanks for digging into this. This seems like a correct solution for now.
> 
> I think there is a larger question though, which is why it’s possible to 
> overrelease kCFEmptyString. I think we skirted the issue early in bringup of 
> SCL-Foundation, but constant strings are supposed to be “pinned” and ref 
> count operations on them a no-op.
> 
> - Tony
> 
>> On Oct 7, 2016, at 6:47 AM, Alex Blewitt via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> I'm looking at https://bugs.swift.org/browse/SR-2879 
>> <https://bugs.swift.org/browse/SR-2879> which is exposing itself through an 
>> over-release of a constant CF string (in this case, kCFEmptyString). I don't 
>> believe it to be a Swift related problem, because Swift doesn't get into the 
>> internals of CFCalendar where the problem occurs.
>> 
>> The problem is that CFCalendar releases the localeID when it's deallocated:
>> 
>> if (calendar->_localeID) CFRelease(calendar->_localeID);
>> 
>> https://github.com/apple/swift-corelibs-foundation/blob/1a76e814212e781a9d50782ee24117760cfe9b48/CoreFoundation/Locale.subproj/CFCalendar.c#L54
>>  
>> <https://github.com/apple/swift-corelibs-foundation/blob/1a76e814212e781a9d50782ee24117760cfe9b48/CoreFoundation/Locale.subproj/CFCalendar.c#L54>
>>  
>> 
>> The problem is that when the localeID is assigned, it doesn't appear to be 
>> copied or renamed:
>> 
>> calendar->_localeID = CFLocaleGetIdentifier(CFLocaleGetSystem());
>> 
>> https://github.com/apple/swift-corelibs-foundation/blob/1a76e814212e781a9d50782ee24117760cfe9b48/CoreFoundation/Locale.subproj/CFCalendar.c#L252
>>  
>> <https://github.com/apple/swift-corelibs-foundation/blob/1a76e814212e781a9d50782ee24117760cfe9b48/CoreFoundation/Locale.subproj/CFCalendar.c#L252>
>>  
>> https://github.com/apple/swift-corelibs-foundation/blob/1a76e814212e781a9d50782ee24117760cfe9b48/CoreFoundation/Locale.subproj/CFCalendar.c#L281
>>  
>> <https://github.com/apple/swift-corelibs-foundation/blob/1a76e814212e781a9d50782ee24117760cfe9b48/CoreFoundation/Locale.subproj/CFCalendar.c#L281>
>>   
>> 
>> but elsewhere in the code, we do retain it:
>> 
>>CFStringRef localeID = CFLocaleGetIdentifier(locale);
>> if (localeID != calendar->_localeID) {
>>  CFRelease(calendar->_localeID);
>>  CFRetain(localeID);
>> 
>> https://github.com/apple/swift-corelibs-foundation/blob/1a76e814212e781a9d50782ee24117760cfe9b48/CoreFoundation/Locale.subproj/CFCalendar.c#L303-L306
>>  
>> <https://github.com/apple/swift-corelibs-foundation/blob/1a76e814212e781a9d50782ee24117760cfe9b48/CoreFoundation/Locale.subproj/CFCalendar.c#L303-L306>
>>  
>> 
>> When a locale isn't supplied, it uses the default global one, which is 
>> defined to be an empty string:
>> 
>> CFLocaleRef CFLocaleGetSystem(void) {
>> CFLocaleRef locale;
>> CFLocaleRef uselessLocale = NULL; //if we lose the race creating the 
>> global locale, we need to release the one we created, but we want to do it 
>> outside the lock.
>> __CFLocaleLockGlobal();
>> if (NULL == __CFLocaleSystem) {
>>  __CFLocaleUnlockGlobal();
>>  locale = CFLocaleCreate(kCFAllocatorSystemDefault, CFSTR(""));
>>  if (!locale) return NULL;
>> 
>> https://github.com/apple/swift-corelibs-foundation/blob/1a76e814212e781a9d50782ee24117760cfe9b48/CoreFoundation/Locale.subproj/CFLocale.c#L255-L261
>>  
>> <https://github.com/apple/swift-corelibs-foundation/blob/1a76e814212e781a9d50782ee24117760cfe9b48/CoreFoundation/Locale.subproj/CFLocale.c#L255-L261>
>>  
>> 
>> The CFSTR("") results in a reference to kCFEmptyString, which reduces by one 
>> each time a CFCalendar is created and destroyed, leading to the (unrelated) 
>> test failures of https://github.com/apple/swift-corelibs-foundation/pull/667 
>> <https://github.com/apple/swift-corelibs-foundation/pull/667> as documented 
>> i

[swift-corelibs-dev] Cherry-picking changes for the next Swift release?

[Alex Blewitt via swift-corelibs-dev]

I have a couple of Calendar related fixes into swift-corelibs-foundation master:

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

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


How do I go about cherry-picking these to be in the next release? There are 
several remote branches that have the 'swift-3' moniker including several 
'preview' ones:

  origin/swift-3
  origin/swift-3.0-branch
  origin/swift-3.0-preview-1-branch
  origin/swift-3.0-preview-2-branch
  origin/swift-3.0-preview-3-branch
  origin/swift-3.0-preview-4-branch
  origin/swift-3.0-preview-5-branch
  origin/swift-3.0-preview-5-speculative
  origin/swift-3.0.1-preview-2-branch

Why are we representing previews as branches, instead of tags? If I wanted to 
submit a pull request for one of these previews, it's not clear which one(s) I 
should target.

There are also a number of branches that are old (in many cases, over a month):

  origin/dabrahams-patch-1
  origin/dabrahams-patch-2
  origin/data-associated-type-fixes-3.0
  origin/more_value_types
  origin/nscoding
  origin/revert-540-SR-2151
  origin/revert-567-pr-grabbag

Can we get these cleaned up if they are no longer necessary?

Alex

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

[swift-corelibs-dev] Outstanding pull request for NSDecimal?

[Alex Blewitt via swift-corelibs-dev]

I raised https://github.com/apple/swift-corelibs-foundation/pull/687 about a 
week ago for the final push implementing NSDecimal. It's still stuck in limbo - 
can someone add a @swift-ci please test to it, so that it can at least have the 
tests run and possibly committed?

I'm concerned that it may need a rebase after 
https://github.com/apple/swift-corelibs-foundation/pull/694 which fixed a 
warning that I'd introduced inadvertently and would like to ensure that it can 
be merged.

Thanks,

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

[swift-corelibs-dev] Cleaning up old branches

[Alex Blewitt via swift-corelibs-dev]

> On 12 Oct 2016, at 18:25, Tony Parker  wrote:
> 
> Hi Alex,
> 
>> On Oct 12, 2016, at 9:52 AM, Alex Blewitt via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>>  There are several remote branches that have the 'swift-3' moniker including 
>> several 'preview' ones:
>> 
>>   origin/swift-3
>>   origin/swift-3.0-branch
>>   origin/swift-3.0-preview-1-branch
>>   origin/swift-3.0-preview-2-branch
>>   origin/swift-3.0-preview-3-branch
>>   origin/swift-3.0-preview-4-branch
>>   origin/swift-3.0-preview-5-branch
>>   origin/swift-3.0-preview-5-speculative
>>   origin/swift-3.0.1-preview-2-branch
>> 
>> Why are we representing previews as branches, instead of tags? If I wanted 
>> to submit a pull request for one of these previews, it's not clear which 
>> one(s) I should target.
> 
> I agree this is a bit confusing.
> 
> Right now, swift-3.0-branch is the one that is used as the “development” 
> branch for any updates to swift 3.0.
> 
>> 
>> There are also a number of branches that are old (in many cases, over a 
>> month):
>> 
>>   origin/dabrahams-patch-1
>>   origin/dabrahams-patch-2
>>   origin/data-associated-type-fixes-3.0
>>   origin/more_value_types
>>   origin/nscoding
>>   origin/revert-540-SR-2151
>>   origin/revert-567-pr-grabbag
>> 
>> Can we get these cleaned up if they are no longer necessary?
>> 
>> Alex
> 
> Yes, I think we should delete these. I’ll do that for a bunch of these.
> 
> - Tony

Thanks for cleaning up the old branches, Tony. 

I wonder if we need to keep the -preview- branches? It seems they are all 
replaced by equivalent tags, except for -preview-5-speculative (which is 
contained in both swift-3.0 branch and in the swift-3.0-PREVIEW-6 tag, as shown 
below):

$ git ls-remote --heads | grep preview
From https://github.com/apple/swift-corelibs-foundation
3d10cf76b1faa86bae48a5e7d9876ee7ad3af422
refs/heads/swift-3.0-preview-1-branch
c8c1ff0f8b274567f9018297269258290238be73
refs/heads/swift-3.0-preview-2-branch
0ff9f494a66fe7130536c70f23ef5f30b1d2aa9f
refs/heads/swift-3.0-preview-3-branch
686d9b6db204a330f8bacf792e552dbd2f5f82df
refs/heads/swift-3.0-preview-4-branch
686d9b6db204a330f8bacf792e552dbd2f5f82df
refs/heads/swift-3.0-preview-5-branch
958a93ee647dc8aa66f2fc31de5000681d42604f
refs/heads/swift-3.0-preview-5-speculative

$ git ls-remote --tags | grep PREVIEW
From https://github.com/apple/swift-corelibs-foundation
29480f5e877fec0b1c430d9605d0fb1a97c24c9brefs/tags/swift-3.0-PREVIEW-1
3d10cf76b1faa86bae48a5e7d9876ee7ad3af422refs/tags/swift-3.0-PREVIEW-1^{}
c8c1ff0f8b274567f9018297269258290238be73refs/tags/swift-3.0-PREVIEW-2
0ff9f494a66fe7130536c70f23ef5f30b1d2aa9frefs/tags/swift-3.0-PREVIEW-3
686d9b6db204a330f8bacf792e552dbd2f5f82dfrefs/tags/swift-3.0-PREVIEW-4
686d9b6db204a330f8bacf792e552dbd2f5f82dfrefs/tags/swift-3.0-PREVIEW-5
cf473150c9bc1ede5a53b451d32cbe30c231b63drefs/tags/swift-3.0-PREVIEW-6
2eccd197f2c41fe05a7a557c7eff382b3303f030refs/tags/swift-3.0.1-PREVIEW-1
b6898c75e42fe73552b22a32361fb440cc9fdefcrefs/tags/swift-3.0.1-PREVIEW-2
b6898c75e42fe73552b22a32361fb440cc9fdefcrefs/tags/swift-3.0.1-PREVIEW-3

$ git log --oneline --decorate 
refs/remotes/origin/swift-3.0-preview-5-speculative^...refs/tags/swift-3.0-PREVIEW-6
 | grep swift- 
cf47315 (tag: swift-DEVELOPMENT-SNAPSHOT-2016-08-07-a, tag: 
swift-DEVELOPMENT-SNAPSHOT-2016-08-04-a, tag: swift-3.0-PREVIEW-6) Merge branch 
'filemanager-default' of https://github.com/jpsim/swift-corelibs-foundation
3b9a917 (tag: swift-DEVELOPMENT-SNAPSHOT-2016-07-29-a) Revert "Revert 
"UnsafePointer conversion fixes.""
541f035 (tag: swift-DEVELOPMENT-SNAPSHOT-2016-07-28-a) Merge pull request #477 
from swiftix/SE-130
958a93e (origin/swift-3.0-preview-5-speculative) Update for SE-0025 ('private' 
and 'fileprivate') (#445)

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

[swift-corelibs-dev] Executable swift files?

[Alex Blewitt via swift-corelibs-dev]

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] Broken master-next?

[Alex Blewitt via swift-corelibs-dev]

My pull request failed to build:

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


The build failure is entirely unrelated to my changes; it looks like whatever 
point the branch was taken from/built from, the underlying swift implementation 
is broken:

https://ci.swift.org/job/swift-corelibs-foundation-PR-Linux/455/ 
 

In file included from 
/home/buildnode/jenkins/workspace/swift-corelibs-foundation-PR-Linux@2/swift/include/swift/SIL/SILFunction.h:20:
In file included from 
/home/buildnode/jenkins/workspace/swift-corelibs-foundation-PR-Linux@2/swift/include/swift/SIL/SILBasicBlock.h:21:
 
<>/home/buildnode/jenkins/workspace/swift-corelibs-foundation-PR-Linux@2/swift/include/swift/SIL/SILInstruction.h:80:16:
 error: no template named 'ilist_sentinel_traits' in namespace 'llvm'; did you 
mean 'ilist_sentinel_tracking'?
  friend llvm::ilist_sentinel_traits;
 ~~^
   ilist_sentinel_tracking
/home/buildnode/jenkins/workspace/swift-corelibs-foundation-PR-Linux@2/llvm/include/llvm/ADT/ilist_node_options.h:25:47:
 note: 'ilist_sentinel_tracking' declared here
template  struct ilist_sentinel_tracking {};
  ^

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

Re: [swift-corelibs-dev] Memory leak with String.range(options: .regularExpression) [SR-3536]

[Alex Blewitt via swift-corelibs-dev]

On 8 Feb 2017, at 16:51, Tony Parker via swift-corelibs-dev 
 wrote:
> 
> Hi Nethra,
> 
>> On Feb 7, 2017, at 11:44 PM, Nethra Ravindran via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> Hi everyone,
>> 
>> I am working on https://bugs.swift.org/browse/SR-3536 
>> 
>> There is a memory leak when searching for the substring of a string using 
>> regular expression.
>> 
>> 
>> import Foundation
>> 
>> let myString = "Foo"
>> for _ in 1...1 {
>>   let _ = myString.range(of: "bar", options: .regularExpression)
>> }
>> 
>> 
>> From the above test case i could see that over a period of time, around 60 
>> Mb of memory was leaked. 
>> 
>> I see in String.range we eventually call NSString._createRegexForPattern. 
>> Here we maintain a mapping between NSString and NSRegularExpression object 
>> in NSCache. All the entries in the cache are 
>> maintained in a dictionary ( _entries ) which takes the UnsafeRawPointer as 
>> the key, which seems to be the address of the NSString Object and 
>> NSCachedEntry as value.
>> 
>> Though the pattern is of type String, it is stored in the NSCache as 
>> NSString. And since we are storing the NSCachedEntry objects in a dictionary 
>> indexed by the address (UnsafeRawPointer) of the NSString object, there is a 
>> new cache entry created for each iteration ( in the test case ) though the 
>> pattern string remains the same.
>> 
>> Can someone guide me about how to go about resolving this issue.
>> 
> 
> Looks like you’ve done most of the analysis, so you’re already pretty much 
> there. =)
> 
> Is there some other way we could be caching the results here?

There's a 'cache.countLimit = 10' set on the cache:

https://github.com/apple/swift-corelibs-foundation/blob/16657160c2c441a58ea01bf7baa90607a0b395f7/Foundation/NSString.swift#L109
 


Shouldn't it start discarding some of the previous entries after it hits the 
first 10?

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

Re: [swift-corelibs-dev] Memory leak with String.range(options: .regularExpression) [SR-3536]

[Alex Blewitt via swift-corelibs-dev]

On 8 Feb 2017, at 16:59, Alex Blewitt via swift-corelibs-dev 
 wrote:
> 
> There's a 'cache.countLimit = 10' set on the cache:
> 
> https://github.com/apple/swift-corelibs-foundation/blob/16657160c2c441a58ea01bf7baa90607a0b395f7/Foundation/NSString.swift#L109
>  
> <https://github.com/apple/swift-corelibs-foundation/blob/16657160c2c441a58ea01bf7baa90607a0b395f7/Foundation/NSString.swift#L109>
> 
> Shouldn't it start discarding some of the previous entries after it hits the 
> first 10?

Doesn't look like it removes any entries from the cache, nor does the cache 
work when a String is used as a key. Added info to 
https://bugs.swift.org/browse/SR-3536 <https://bugs.swift.org/browse/SR-3536>

 > c.setObject("foo",forKey:"foo")
 > c.object(forKey:"foo")
$R6: Foundation.NSString? = nil

Alex

___
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

[Alex Blewitt via swift-corelibs-dev]

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 
> mailto:nethraravindra...@gmail.com>> 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

Re: [swift-corelibs-dev] Building Foundation

[Alex Blewitt via swift-corelibs-dev]

> On 2 Mar 2017, at 01:51, Mohit Athwani via swift-corelibs-dev 
>  wrote:
> 
> I am trying to build Foundation on my Ubuntu 16.04 LTS version using:
> 
> swift/utils/build-script --xctest --foundation -t
> 
> And it fails with the following tests failing:

OK, what happened when you looked in the logs to find out why the tests were 
failing?

> Every thing has been freshly cloned and no code has been modifed yet...

Which version of the code were you working with? Are you on master, or a stable 
branch? What branch is your 'swift-llvm' subproject checked out as?

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

Re: [swift-corelibs-dev] XCTest Build is failing for Dev environment

[Alex Blewitt via swift-corelibs-dev]

I'd suggest trying to run the command that failed manually and see if there's 
any additional error messages that get printed out:

> xcodebuild -workspace 
> /Users/tapan/swift-source/swift-corelibs-xctest/XCTest.xcworkspace -scheme 
> SwiftXCTest -configuration Release 
> SWIFT_EXEC="/Users/tapan/swift-source/build/Ninja-ReleaseAssert/swift-macosx-x86_64/bin/swiftc"
>  SWIFT_LINK_OBJC_RUNTIME=YES 
> SYMROOT="/Users/tapan/swift-source/build/Ninja-ReleaseAssert/xctest-macosx-x86_64"
>  
> OBJROOT="/Users/tapan/swift-source/build/Ninja-ReleaseAssert/xctest-macosx-x86_64"


It looks like it may be trying to link in SwiftFoundation, and failing. I'm not 
sure if there's any additional steps that need to be built beforehand in order 
to build XCTest.

Alex

> On 23 Apr 2017, at 14:56, Tapan Prakasht via swift-corelibs-dev 
>  wrote:
> 
> Hi,
> 
> I am new to this mailing list.
> 
> I am trying to build XCtest project. I followed every step mentioned
> in the documentation.  I have executed the following command. But
> build got failed.
> 
> ../swift/utils/build-script --preset corelibs-xctest
> 
> Error:
> 
> ** BUILD FAILED **
> 
> 
> The following build commands failed:
>   Ld 
> /Users/tapan/swift-source/build/Ninja-ReleaseAssert/xctest-macosx-x86_64/Release/SwiftFoundation.framework/Versions/A/SwiftFoundation
>  normal x86_64
> (1 failure)
> Traceback (most recent call last):
>   File "/Users/tapan/swift-source/swift-corelibs-xctest/build_script.py", 
> line 526, in 
> main()
>   File "/Users/tapan/swift-source/swift-corelibs-xctest/build_script.py", 
> line 522, in main
> parsed_args.func(parsed_args)
>   File "/Users/tapan/swift-source/swift-corelibs-xctest/build_script.py", 
> line 98, in build
> source_dir=SOURCE_DIR))
>   File "/Users/tapan/swift-source/swift-corelibs-xctest/build_script.py", 
> line 31, in run
> subprocess.check_call(command, shell=True)
>   File 
> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py",
>  line 540, in check_call
> raise CalledProcessError(retcode, cmd)
> subprocess.CalledProcessError: Command 'xcodebuild -workspace 
> /Users/tapan/swift-source/swift-corelibs-xctest/XCTest.xcworkspace -scheme 
> SwiftXCTest -configuration Release 
> SWIFT_EXEC="/Users/tapan/swift-source/build/Ninja-ReleaseAssert/swift-macosx-x86_64/bin/swiftc"
>  SWIFT_LINK_OBJC_RUNTIME=YES 
> SYMROOT="/Users/tapan/swift-source/build/Ninja-ReleaseAssert/xctest-macosx-x86_64"
>  
> OBJROOT="/Users/tapan/swift-source/build/Ninja-ReleaseAssert/xctest-macosx-x86_64"'
>  returned non-zero exit status 65
> ../swift/utils/build-script: fatal error: command terminated with a non-zero 
> exit status 1, aborting
> ../swift/utils/build-script: fatal error: command terminated with a non-zero 
> exit status 1, aborting
> 
> 
> My dev environment is MacOS Sierra 10.12.4 (16E195)
> Xcode 8.3.2
> 
> Can somebody help here?
> 
> Thanks,
> Tapan
> ___
> 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] Build failure and differences between test and build

[Alex Blewitt via swift-corelibs-dev]

We had a test failure on swift-corelibs-foundation recently on master, which 
was related to this pull request being merged by me:

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


The automated tests passed, but after being committed to master, they then 
failed. I subsequently rolled them back with this pull request:

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


A few interim builds have failed; if you see messages like failing to compare 
metric and imperial measurements, that could have been caused by this. Rebasing 
and redoing such test failures should fix the issues.

It's a bit concerning that the test case failed after merge but passed in the 
pull request test. Is this expected?

Alex
Test Case 'TestNSLengthFormatter.test_stringFromMetersMetric' started at 
2017-06-21 10:16:31.688
TestFoundation/TestNSLengthFormatter.swift:71: error: 
TestNSLengthFormatter.test_stringFromMetersMetric : XCTAssertEqual failed: 
("-6.214 mi") is not equal to ("-10 km") - 
TestFoundation/TestNSLengthFormatter.swift:72: error: 
TestNSLengthFormatter.test_stringFromMetersMetric : XCTAssertEqual failed: 
("-0.001 mi") is not equal to ("-0.001 km") - 
TestFoundation/TestNSLengthFormatter.swift:73: error: 
TestNSLengthFormatter.test_stringFromMetersMetric : XCTAssertEqual failed: ("0 
in") is not equal to ("0.01 mm") - 
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] TimeZone database

[Alex Blewitt via swift-corelibs-dev]

It looks like it's /usr/share/zoneinfo on all Ubuntu versions:

alblue.local[~]$ docker run -it --rm ubuntu:14.04 find /usr -name zone.tab
/usr/share/zoneinfo/zone.tab
alblue.local[~]$ docker run -it --rm ubuntu:16.04 find /usr -name zone.tab
/usr/share/zoneinfo/zone.tab
alblue.local[~]$ docker run -it --rm ubuntu:16.10 find /usr -name zone.tab
/usr/share/zoneinfo/zone.tab

This is the same that's coming from CFTimeZone.c:

https://github.com/apple/swift-corelibs-foundation/blob/2611dcd0d9b91fecace537838294bd85f0220503/CoreFoundation/NumberDate.subproj/CFTimeZone.c#L36-L39

Is it possible that the MacOS header is being included and defining TZDIR 
before the CFTimeZone.c file is compiled?

Alex

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

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

[Alex Blewitt via swift-corelibs-dev]

I've pushed a change which will add an unavailability warning for a method 
which was deprecated at the point of being added to Swift, has never worked, 
and likely never will:

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


There are some other types in Foundation which aren't likely to ever be 
implementable in Swift on Linux; Bundle.unload, NSPort/PortMessage, copy(with 
zone) etc. The majority of these methods use NSUnimplemented(), which means 
there are often unannounced runtime errors that you can get from something that 
compiled correctly.

I'd like to suggest that we attempt to resolve this problem, either by removing 
the features whihc are never going to be implemented (e.g. by commenting out 
the calls) or by marking them as @available(*,unavailable, message:"Not 
available on the Linux platform"). That way, calls that are known cannot work 
can be identified at compile time instead of at run-time.

I hope we'll then be able to remove the NSUnimplemented calls on the types that 
can never be implemented, so that we can focus on those types and functions 
that we can. Alternatively we can define a different macro, say 
NSUnavailableOnLinux, to indicate that this functionality cannot be present (as 
opposed to just leaving it blank).

What do you think?

$ git grep -c NSUnimplemented | sort -n -r -k2 -t:
Foundation/NSExpression.swift:37
Foundation/NSURLCache.swift:22
Foundation/FileManager.swift:22
Foundation/NSPort.swift:21
Foundation/NSOrderedSet.swift:20
Foundation/NSSortDescriptor.swift:19
...
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

[Alex Blewitt via swift-corelibs-dev]

On 28 Jul 2017, at 19:44, Tony Parker  wrote:
> 
> This sounds like a good plan to me. We’ll have to discuss the specifics of 
> what is marked unavailable this way, probably best via code review.
> 
> I think we had more hope for some of the more-dynamic methods (e.g. 
> NSSortDescriptor, NSExpression), but it does seem clear at this point that 
> the current API is unsuitable for Swift in various ways.

Perhaps if more dynamic introspection lands in a future version of Swift they 
might make sense. It's also possible that some of the new keypath stuff being 
added in Swift might make a good potential API in future, so maybe those aren't 
quite as cut and dry.  

In the meantime I'll take a stab next week at proposing some unavailability 
annotations for some of the stuff which almost certainly doesn't make sense, to 
do with Mach ports and NSZone. 

Alex

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

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

[Alex Blewitt via swift-corelibs-dev]

> On 28 Jul 2017, at 20:30, Alex Blewitt via swift-corelibs-dev 
>  wrote:
> 
> In the meantime I'll take a stab next week at proposing some unavailability 
> annotations for some of the stuff which almost certainly doesn't make sense, 
> to do with Mach ports and NSZone. 

I've created a pull request which adds NSUnsupported, and uses that to wrap 
NSPort and NSMessagePort:

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

What do you think? Should we use 'deprecated' (so that it's a warning) or 
'unavailable' (so that it's a compile time error)?

+@available(*,deprecated,message:"Not available on non-Darwin platforms")

+@available(*,unavailable,message:"Not available on non-Darwin platforms")


Alex

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

Re: [swift-corelibs-dev] Informal Chat Medium

[Alex Blewitt via swift-corelibs-dev]

> On 2 Aug 2017, at 20:34, David Hart via swift-corelibs-dev 
>  wrote:
> 
> Hello Corelibs dev,

Hi David, welcome!

> A few months back, I wanted to start contributing more seriously to Swift 
> Open Source. I ended up helping out on the Swift Package Manager project and 
> had a very positive experience. It’s not easy to jump into a big project and 
> it would not have been such a success for me without their official Slack 
> channel where I was grateful to often find a helping hand when I had doubts, 
> questions, or wanted to discuss and understand the process or direction of 
> the project. That medium really helped me to ask the kind of questions I was 
> afraid to ask on the mailing-list, which feels like a more formal medium.
> 
> Now that I’m looking into what I can do on corelibs-foundation, I really wish 
> an equivalent channel existed. Is this an idea the corelibs team would be 
> interested in entertaining?

Yes, and indeed something that's been discussed for a while now is the 
possibility of moving the mailing lists to a forum:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170731/038452.html

Although Ted initially started the discussion with 'for swift-evolution' he 
later clarified he thought all should move:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170731/038454.html

While it's not a Slack channel, I wonder if this would suit your needs if it 
were to happen?

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

[swift-corelibs-dev] Problems with dispatch?

[Alex Blewitt via swift-corelibs-dev]

On a recent test build there were compile errors with libdispatch, even after a 
clean build:

src/libdispatch.so: error: undefined reference to '__atomic_fetch_sub_4'
src/libdispatch.so: error: undefined reference to '__atomic_load_4'
src/libdispatch.so: error: undefined reference to '__atomic_fetch_add_4'
src/libdispatch.so: error: undefined reference to '__atomic_compare_exchange_4'
src/libdispatch.so: error: undefined reference to '__atomic_fetch_or_4'
src/libdispatch.so: error: undefined reference to '__atomic_fetch_and_4'
src/libdispatch.so: error: undefined reference to '__atomic_store_4'
src/libdispatch.so: error: undefined reference to '__atomic_exchange_4'
clang-5.0: error: linker command failed with exit code 1 (use -v to see 
invocation)


https://ci.swift.org/job/swift-corelibs-foundation-PR-Linux/245/consoleFull#-12390007823122a513-f36a-4c87-8ed7-cbc36a1ec144
 


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


The changes aren't to do with libdispatch and shouldn't have caused these 
issues (they were related to test code only). 

Could this be due to recent build toolchain updates on the build servers?

Alex
___
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] Problems with dispatch?

[Alex Blewitt via swift-corelibs-dev]

> On 11 Oct 2017, at 22:03, Alex Blewitt via swift-dev  
> wrote:
> 
> On a recent test build there were compile errors with libdispatch, even after 
> a clean build:
> 
> src/libdispatch.so: error: undefined reference to '__atomic_fetch_sub_4'
> src/libdispatch.so: error: undefined reference to '__atomic_load_4'
> src/libdispatch.so: error: undefined reference to '__atomic_fetch_add_4'
> src/libdispatch.so: error: undefined reference to 
> '__atomic_compare_exchange_4'
> src/libdispatch.so: error: undefined reference to '__atomic_fetch_or_4'
> src/libdispatch.so: error: undefined reference to '__atomic_fetch_and_4'
> src/libdispatch.so: error: undefined reference to '__atomic_store_4'
> src/libdispatch.so: error: undefined reference to '__atomic_exchange_4'
> clang-5.0: error: linker command failed with exit code 1 (use -v to see 
> invocation)

These problems have since been fixed, and foundation builds are going through 
as expected.

Alex

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

Re: [swift-corelibs-dev] SR-6405: URLRequest does not capitalise HTTP methods

[Alex Blewitt via swift-corelibs-dev]

There is a TestFoundation target in the swift-corelibs-foundation project, 
which can allow the tests to be run against the open source codebase.

Note that there's no requirement for the methods to be capitalised in 
URLRequest. Chances are that the implementation is such that there are some 
pre-defined values which can be used/replaced for keys, but other ones will 
take the case of whatever you put in them.

I also don't think it makes sense to capitalise everything because in most 
cases it will have no effect, but is wasted computation. So in other words, 
don't pass lowercase values into the x.httpMethod if you don't want it.

Alex

> On 16 Nov 2017, at 17:41, Stephen Celis via swift-corelibs-dev 
>  wrote:
> 
> Brandon Williams and I have come across a lot of inconsistencies between 
> Foundations in our Swift web work. We’ve been trying to file bugs when we 
> remember to, but I’m curious if there’s a better way to catch these. Is the 
> Foundation test suite run against both implementations to attempt to catch 
> these kinds of things? If not it would seem like a big win to do so. If so, I 
> suppose we could help by beefing up the test coverage?
> 
> Stephen
> 
>> On Nov 16, 2017, at 12:18 PM, Ian Partridge via swift-corelibs-dev 
>>  wrote:
>> 
>> Hi, it looks like Foundation on Darwin capitalises certain HTTP
>> methods but not others:
>> 
>> ```
>> let methods = ["get", "head", "post", "put", "delete", "connect",
>> "options", "trace", "patch"]
>> 
>> var x = URLRequest(url: URL(string: "/hello")!)
>> 
>> for m in methods {
>>   x.httpMethod = m
>>   print(x.httpMethod!)
>> }
>> ```
>> 
>> Output on Darwin:
>> GET
>> HEAD
>> POST
>> PUT
>> DELETE
>> CONNECT
>> options
>> trace
>> patch
>> 
>> Currently on Linux we don't do any capitalization so I'd like to fix this.
>> 
>> Is my list of 6 methods above the definitive list of which HTTP
>> methods should be capitalized?
>> 
>> 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

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

Re: [swift-corelibs-dev] SR-6405: URLRequest does not capitalise HTTP methods

[Alex Blewitt via swift-corelibs-dev]

> On 16 Nov 2017, at 19:14, Stephen Celis  wrote:
> 
>> On Nov 16, 2017, at 2:02 PM, Alex Blewitt  wrote:
>> 
>> There is a TestFoundation target in the swift-corelibs-foundation project, 
>> which can allow the tests to be run against the open source codebase.
> 
> Sorry, maybe I wasn’t clear, I was wondering if there’s a test suite that 
> regularly runs against _both_ the open-source Foundation implementation _and_ 
> the closed-source Foundation implementation in order to catch inconsistencies 
> across code bases.

I understood your question, but I can only point to you as to what is available 
and run on the swift-corelibs-foundation open source project.

> I don’t have a strong enough opinion to argue for or against 
> auto-capitalizing the HTTP method, but I _do_ care for consistency across 
> platforms. We have a significant test suite in our code bases with a lot of 
> unit tests and snapshot tests that pass on our dev machines (Mac), but fail 
> on Linux.

Yes, being consistent between platforms is one of the purposes of the 
swift-corelibs-foundation project. However, there are both run-time and 
implementation differences between the two platforms; the existence (or not) of 
the Objective-C runtime, whether or not comparisons are performed using the 
rules based on the Darwin version of Foundation or the ICU rules on the 
open-source version of Foundation, and so on. 

Some of the differences are just bugs, in which case we can try and resolve the 
issues when they're filed at bugs.swift.org  or via 
pull requests on the GitHub repository. Some of the issues are ones where the 
implementation in the open source version is missing; either because the 
functionally cannot be implemented (e.g. dynamic unloading of bundles) or 
because it's not been prioritised yet (e.g. 
https://github.com/apple/swift-corelibs-foundation/search?utf8=✓&q=nsunimplemented
 
).
 In particular the big items that are missing at the moment are encoder/decoder 
implementations and those relating to nspredicate/expression, which both can be 
implemented in runtimes that have dynamic introspection of data structures but 
which therefore can't be implemented in Linux.

Having said that, if you do find consistency issues which are important to you 
then please file bugs, and optionally provide pull requests for them. We can 
help on the mailing list to try and resolve any issues or questions as they 
arise.

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

[Alex Blewitt via swift-corelibs-dev]

Can you file a bug at bugs.swift.org  with a minimal 
test case? It certainly sounds like a bug, and from the looks of the docker 
files, you're using the swift 4.0.2 release on Ubuntu 16.04.

If you can run the test under LLDB and put a breakpoint in that function, and 
get a backtrace (with 'bt') then it might be interesting to see where the 
deinit is being triggered, and give some kind of clue as to what is happening.

Alex

> On 16 Nov 2017, at 22:46, Brandon Williams via swift-corelibs-dev 
>  wrote:
> 
> Oops, sorry, hit send too early!
> 
> The docker file Im using can be seen here:
> 
> https://github.com/pointfreeco/swift-web/blob/bb-travis/Dockerfile 
> 
> 
> Which is this template:
> 
> https://github.com/swiftdocker/docker-swift/blob/5c83628d4696bca62aec3136a4ee9b854e8d548e/4.0/Dockerfile
>  
> 
> 
> So not using any of the betas...
> 
> On Thu, Nov 16, 2017 at 5:45 PM Brandon Williams  > wrote:
> Ah, sorry for now providing more info!
> 
> So the docker file that I am using to run the tests can be see here:
> 
> 
> 
> On Thu, Nov 16, 2017 at 5:43 PM Philippe Hausler  > wrote:
> 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 
>> mailto:swift-corelibs-dev@swift.org>> 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

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

[Alex Blewitt via swift-corelibs-dev]

Thanks!

Alex

> On 17 Nov 2017, at 17:27, Brandon Williams  wrote:
> 
> I haven’t been able to find a minimal test case, but at least the test case I 
> linked to reproduces every time.
> 
> I’m not sure I’ll have time to search for a minimal case today, and I leave 
> for vacation tomorrow :/ perhaps when I get back.
> 
> I did at least file the bug report: https://bugs.swift.org/browse/SR-6422 
> 
> On Fri, Nov 17, 2017 at 4:48 AM Alex Blewitt  > wrote:
> Can you file a bug at bugs.swift.org  with a minimal 
> test case? It certainly sounds like a bug, and from the looks of the docker 
> files, you're using the swift 4.0.2 release on Ubuntu 16.04.
> 
> If you can run the test under LLDB and put a breakpoint in that function, and 
> get a backtrace (with 'bt') then it might be interesting to see where the 
> deinit is being triggered, and give some kind of clue as to what is happening.
> 
> Alex
> 
> 
>> On 16 Nov 2017, at 22:46, Brandon Williams via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> Oops, sorry, hit send too early!
>> 
>> The docker file Im using can be seen here:
>> 
>> https://github.com/pointfreeco/swift-web/blob/bb-travis/Dockerfile 
>> 
>> 
>> Which is this template:
>> 
>> https://github.com/swiftdocker/docker-swift/blob/5c83628d4696bca62aec3136a4ee9b854e8d548e/4.0/Dockerfile
>>  
>> 
>> 
>> So not using any of the betas...
>> 
>> On Thu, Nov 16, 2017 at 5:45 PM Brandon Williams > > wrote:
>> Ah, sorry for now providing more info!
>> 
>> So the docker file that I am using to run the tests can be see here:
>> 
>> 
>> 
>> On Thu, Nov 16, 2017 at 5:43 PM Philippe Hausler > > wrote:
>> 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 
>>> mailto:swift-corelibs-dev@swift.org>> 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 
>> 
> 

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

Re: [swift-corelibs-dev] Linux: Empty `URLComponents` does not generate valid URL

[Alex Blewitt via swift-corelibs-dev]

> On 5 Dec 2017, at 12:55, Brandon Williams via swift-corelibs-dev 
>  wrote:
> 
> Hello all!
> 
> I filed this bug yesterday:
> 
> https://bugs.swift.org/browse/SR-6527 
> 
> And just wanted to see if that makes sense. This bit us in the butt yesterday 
> in our router: https://github.com/pointfreeco/swift-web/pull/86 
> 
Thanks, it's good to know where these issues are when we find them. It would be 
useful to know which version of Swift you were running here; if you can add 
that to the bug, it would be good.

Alex

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