Re: [swift-corelibs-dev] NSCoding methods

2015-12-18 Thread Luke Howard via swift-corelibs-dev 

> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

2015-12-20 Thread Luke Howard 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. 

It’d arguably be more of a hack to add a global manifest of classes if the 
dynamic linker already has one ;-) Here’s a toy implementation of 
swift_classFromString():

https://github.com/lhoward/SwiftRuntimeTest

Disclaimer: I know very little about Swift nor its implementation beyond a bit 
of poking around.

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

What if you (re-)added the ability to annotate Swift classes with their 
Objective-C name on non-Apple platforms? I don’t know what the runtime costs of 
doing this are but it seems like it’s either this, or only allow non-namespaced 
names for Foundation objects.

— Luke
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

2015-12-20 Thread Luke Howard via swift-corelibs-dev 
It's not too hard to figure out (and there are a couple of other ObjC 
implementations) but if Apple have any specs for the archive format, I would be 
keen to take a look.

Also regarding interoperability - perhaps it might be reasonable, for 
non-Foundation classes that have non-namespaced names (on non-ObjC platforms) 
for the caller to configure the NSKeyedArchiver with explicit class mappings?

-- Luke

Sent from my iPhone

> On 21 Dec 2015, at 00:02, Luke Howard via swift-corelibs-dev 
>  wrote:
> 
> 
>> 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.
> 
> It’d arguably be more of a hack to add a global manifest of classes if the 
> dynamic linker already has one ;-) Here’s a toy implementation of 
> swift_classFromString():
> 
> https://github.com/lhoward/SwiftRuntimeTest
> 
> Disclaimer: I know very little about Swift nor its implementation beyond a 
> bit of poking around.
> 
>> 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.
> 
> What if you (re-)added the ability to annotate Swift classes with their 
> Objective-C name on non-Apple platforms? I don’t know what the runtime costs 
> of doing this are but it seems like it’s either this, or only allow 
> non-namespaced names for Foundation objects.
> 
> — Luke
> ___
> swift-corelibs-dev mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

2015-12-22 Thread Luke Howard via swift-corelibs-dev 

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

— Luke
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

2015-12-22 Thread Luke Howard via swift-corelibs-dev 
Also, I’m sure this is just my lack of Swift-fu but I’m occasionally getting 
EXC_BAD_INSTRUCTION in NSString.hash() where the hash code is cast to an Int. 
If I use unsafeBitCast() instead it seems to work, but I have no idea whether 
this is safe or not.

I’m on OS X with the 2015-12-18 snapshot.

— Luke
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

2015-12-22 Thread Luke Howard via swift-corelibs-dev 

> On 23 Dec 2015, at 5:16 AM, Philippe Hausler  wrote:
> 
>> 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)

Right, I only noticed this whilst implementing NSKeyedArchiver.

Should _CFSwiftDictionaryGetKeysAndValues() (== NSDictionary.getObjects) follow 
the ObjC or the CF parameter order? The latter makes more sense to me.

— Luke
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

2015-12-22 Thread Luke Howard via swift-corelibs-dev 
Some work on NSKeyedArchiver below:

https://github.com/lhoward/swift-corelibs-foundation/tree/lhoward/nscoding

Very incomplete (most classes don’t have coders, there is no unarchiver, 
inexperienced Swift programmer).

— Luke
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

2015-12-23 Thread Luke Howard via swift-corelibs-dev 

> On 24 Dec 2015, at 9:37 AM, Jordan Rose  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.

Ah, thanks for pointing this out!

NSClassFromString() – which it appears Foundation uses when coding – returns a 
non-mangled name for a one/top-level non-generic class type (e.g. 
“scoderTest.CodableTest”) but otherwise the mangled type name (e.g. 
“_TtCC10scoderTest11CodableTest6Nested”).

Is there an equivalent function in Swift stdlib?

— Luke
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

2015-12-23 Thread Luke Howard via swift-corelibs-dev 

> On 24 Dec 2015, at 10:12 AM, Philippe Hausler  wrote:
> 
> NSCoding will have to use something to transform from strings to classes, and 
> that satisfy the two cases (or more) that we have already shown, currently 
> there is no thing that does that in either form; either mangled or non 
> mangled. Basically we need something to implement NSClassFromString with. 
> Which we have clearly shown that dlsym does not fully meet the needs since 
> there are cases that will emit as “module.classname” and others that emit as 
> the mangled name. The simple case is probably going to be the a very common 
> usage pattern for consumers (and of previously built applications). The inner 
> class should definitely be handled in addition to this case.

* If the mangled name is present in the archive, you can re-mangle it to get 
the metadata accessor
* If it’s a one-level unmangled name representing a class, it can be mangled
* If it’s a zero-level unmangled name, then it seems reasonable for a first 
implementation to assume it’s a SwiftFoundation class (or that the caller has 
set an explicit mapping)

Noted that dlsym() will only work with public symbols.

> Are there any methods that can fetch the name (either the symbolic or the 
> readable) given a AnyClass in the runtime to get work started here? I think 
> it is definitely sensible as a start to restrict this just to descendants of 
> the class NSObject. I would presume that since the Metadata is potentially 
> volatile contents we should use something along the lines of 
> swift_getTypeName etc?


I have been using _typeName() but it always demangles – for interop with 
existing archives we need to match the behaviour of libobjc's class_getName() 
(equivalent to NSStringFromClass), which appears to demangle one-level classes.

— Luke___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

2015-12-23 Thread Luke Howard via swift-corelibs-dev 
My plan was just to map any flat unmangled names to SwiftFoundation classes 
without the boilerplate explicit mappings, but happy to change approaches.

That's what the code in the branch I posted yesterday does, but I need to fix 
it to encode the mangled name for non-one level class types - was planning to 
implement NSClassFromString/NSStringFromClass at the same time so at least the 
logic is in one place, and those can be refined over time.

Sent from my iPhone

> On 24 Dec 2015, at 11:07, Philippe Hausler  wrote:
> 
> So one thing we can do in the interim until there is a sanctioned way for us 
> to convert strings to classes and classes to strings is we can register the 
> classes globally for transformation so that the Foundation or SwiftFoundation 
> module name won’t be an issue.
> 
> By doing this early on in the initialization for NSKeyedArchiver, once of 
> course.
> 
> NSKeyedArchiver.setClassName("NSArray", forClass: NSArray.self)
> NSKeyedArchiver.setClassName("NSByteCountFormatter", forClass: 
> NSByteCountFormatter.self)
> NSKeyedArchiver.setClassName("NSData", forClass: NSData.self)
> NSKeyedArchiver.setClassName("NSDate", forClass: NSDate.self)
> NSKeyedArchiver.setClassName("NSDateFormatter", forClass: 
> NSDateFormatter.self)
> NSKeyedArchiver.setClassName("NSDateIntervalFormatter", forClass: 
> NSDateIntervalFormatter.self)
> NSKeyedArchiver.setClassName("NSDecimalNumber", forClass: 
> NSDecimalNumber.self)
> NSKeyedArchiver.setClassName("NSDictionary", forClass: NSDictionary.self)
> NSKeyedArchiver.setClassName("NSEnergyFormatter", forClass: 
> NSEnergyFormatter.self)
> NSKeyedArchiver.setClassName("NSFormatter", forClass: NSFormatter.self)
> NSKeyedArchiver.setClassName("NSLengthFormatter", forClass: 
> NSLengthFormatter.self)
> NSKeyedArchiver.setClassName("NSMassFormatter", forClass: 
> NSMassFormatter.self)
> NSKeyedArchiver.setClassName("NSMessagePort", forClass: 
> NSMessagePort.self)
> NSKeyedArchiver.setClassName("NSMutableArray", forClass: 
> NSMutableArray.self)
> NSKeyedArchiver.setClassName("NSMutableData", forClass: 
> NSMutableData.self)
> NSKeyedArchiver.setClassName("NSMutableDictionary", forClass: 
> NSMutableDictionary.self)
> NSKeyedArchiver.setClassName("NSMutableSet", forClass: NSMutableSet.self)
> NSKeyedArchiver.setClassName("NSMutableString", forClass: 
> NSMutableString.self)
> NSKeyedArchiver.setClassName("NSNotification", forClass: 
> NSNotification.self)
> NSKeyedArchiver.setClassName("NSNumber", forClass: NSNumber.self)
> NSKeyedArchiver.setClassName("NSNumberFormatter", forClass: 
> NSNumberFormatter.self)
> NSKeyedArchiver.setClassName("NSPersonNameComponentsFormatter", forClass: 
> NSPersonNameComponentsFormatter.self)
> NSKeyedArchiver.setClassName("NSPort", forClass: NSPort.self)
> NSKeyedArchiver.setClassName("NSRegularExpression", forClass: 
> NSRegularExpression.self)
> NSKeyedArchiver.setClassName("NSSet", forClass: NSSet.self)
> NSKeyedArchiver.setClassName("NSSocketPort", forClass: NSSocketPort.self)
> NSKeyedArchiver.setClassName("NSString", forClass: NSString.self)
> NSKeyedArchiver.setClassName("NSTextCheckingResult", forClass: 
> NSTextCheckingResult.self)
> NSKeyedArchiver.setClassName("NSTimeZone", forClass: NSTimeZone.self)
> NSKeyedArchiver.setClassName("NSUUID", forClass: NSUUID.self)
> NSKeyedArchiver.setClassName("NSValue", forClass: NSValue.self)
> 
> I have a few more things that I was looking at for supporting this that might 
> be useful depending on how far along you are.
> 
> This should give us at least a head start on the NSCoding compliant 
> Foundation classes and user classes can come next once we have support.
> 
>>> On Dec 23, 2015, at 3:33 PM, Luke Howard  wrote:
>>> 
>>> 
>>> On 24 Dec 2015, at 10:12 AM, Philippe Hausler  wrote:
>>> 
>>> NSCoding will have to use something to transform from strings to classes, 
>>> and that satisfy the two cases (or more) that we have already shown, 
>>> currently there is no thing that does that in either form; either mangled 
>>> or non mangled. Basically we need something to implement NSClassFromString 
>>> with. Which we have clearly shown that dlsym does not fully meet the needs 
>>> since there are cases that will emit as “module.classname” and others that 
>>> emit as the mangled name. The simple case is probably going to be the a 
>>> very common usage pattern for consumers (and of previously built 
>>> applications). The inner class should definitely be handled in addition to 
>>> this case.
>> 
>> * If the mangled name is present in the archive, you can re-mangle it to get 
>> the metadata accessor
>> * If it’s a one-level unmangled name representing a class, it can be mangled
>> * If it’s a zero-level unmangled name, then it seems reasonable for a first 
>> implementation to assume it’s a SwiftFoundation class (or that the caller 
>> has set an explici

Re: [swift-corelibs-dev] NSCoding methods

2015-12-23 Thread Luke Howard via swift-corelibs-dev 
My plan was just to map any flat unmangled names to SwiftFoundation classes 
without the boilerplate explicit mappings, but happy to change approaches.

That's what the code in the branch I posted yesterday does, but I need to fix 
it to encode the mangled name for non-one level class types - was planning to 
implement NSClassFromString/NSStringFromClass at the same time so at least the 
logic is in one place, and those can be refined over time.

Sent from my iPhone

> On 24 Dec 2015, at 11:07, Philippe Hausler  wrote:
> 
> So one thing we can do in the interim until there is a sanctioned way for us 
> to convert strings to classes and classes to strings is we can register the 
> classes globally for transformation so that the Foundation or SwiftFoundation 
> module name won’t be an issue.
> 
> By doing this early on in the initialization for NSKeyedArchiver, once of 
> course.
> 
> NSKeyedArchiver.setClassName("NSArray", forClass: NSArray.self)
> NSKeyedArchiver.setClassName("NSByteCountFormatter", forClass: 
> NSByteCountFormatter.self)
> NSKeyedArchiver.setClassName("NSData", forClass: NSData.self)
> NSKeyedArchiver.setClassName("NSDate", forClass: NSDate.self)
> NSKeyedArchiver.setClassName("NSDateFormatter", forClass: 
> NSDateFormatter.self)
> NSKeyedArchiver.setClassName("NSDateIntervalFormatter", forClass: 
> NSDateIntervalFormatter.self)
> NSKeyedArchiver.setClassName("NSDecimalNumber", forClass: 
> NSDecimalNumber.self)
> NSKeyedArchiver.setClassName("NSDictionary", forClass: NSDictionary.self)
> NSKeyedArchiver.setClassName("NSEnergyFormatter", forClass: 
> NSEnergyFormatter.self)
> NSKeyedArchiver.setClassName("NSFormatter", forClass: NSFormatter.self)
> NSKeyedArchiver.setClassName("NSLengthFormatter", forClass: 
> NSLengthFormatter.self)
> NSKeyedArchiver.setClassName("NSMassFormatter", forClass: 
> NSMassFormatter.self)
> NSKeyedArchiver.setClassName("NSMessagePort", forClass: 
> NSMessagePort.self)
> NSKeyedArchiver.setClassName("NSMutableArray", forClass: 
> NSMutableArray.self)
> NSKeyedArchiver.setClassName("NSMutableData", forClass: 
> NSMutableData.self)
> NSKeyedArchiver.setClassName("NSMutableDictionary", forClass: 
> NSMutableDictionary.self)
> NSKeyedArchiver.setClassName("NSMutableSet", forClass: NSMutableSet.self)
> NSKeyedArchiver.setClassName("NSMutableString", forClass: 
> NSMutableString.self)
> NSKeyedArchiver.setClassName("NSNotification", forClass: 
> NSNotification.self)
> NSKeyedArchiver.setClassName("NSNumber", forClass: NSNumber.self)
> NSKeyedArchiver.setClassName("NSNumberFormatter", forClass: 
> NSNumberFormatter.self)
> NSKeyedArchiver.setClassName("NSPersonNameComponentsFormatter", forClass: 
> NSPersonNameComponentsFormatter.self)
> NSKeyedArchiver.setClassName("NSPort", forClass: NSPort.self)
> NSKeyedArchiver.setClassName("NSRegularExpression", forClass: 
> NSRegularExpression.self)
> NSKeyedArchiver.setClassName("NSSet", forClass: NSSet.self)
> NSKeyedArchiver.setClassName("NSSocketPort", forClass: NSSocketPort.self)
> NSKeyedArchiver.setClassName("NSString", forClass: NSString.self)
> NSKeyedArchiver.setClassName("NSTextCheckingResult", forClass: 
> NSTextCheckingResult.self)
> NSKeyedArchiver.setClassName("NSTimeZone", forClass: NSTimeZone.self)
> NSKeyedArchiver.setClassName("NSUUID", forClass: NSUUID.self)
> NSKeyedArchiver.setClassName("NSValue", forClass: NSValue.self)
> 
> I have a few more things that I was looking at for supporting this that might 
> be useful depending on how far along you are.
> 
> This should give us at least a head start on the NSCoding compliant 
> Foundation classes and user classes can come next once we have support.
> 
>>> On Dec 23, 2015, at 3:33 PM, Luke Howard  wrote:
>>> 
>>> 
>>> On 24 Dec 2015, at 10:12 AM, Philippe Hausler  wrote:
>>> 
>>> NSCoding will have to use something to transform from strings to classes, 
>>> and that satisfy the two cases (or more) that we have already shown, 
>>> currently there is no thing that does that in either form; either mangled 
>>> or non mangled. Basically we need something to implement NSClassFromString 
>>> with. Which we have clearly shown that dlsym does not fully meet the needs 
>>> since there are cases that will emit as “module.classname” and others that 
>>> emit as the mangled name. The simple case is probably going to be the a 
>>> very common usage pattern for consumers (and of previously built 
>>> applications). The inner class should definitely be handled in addition to 
>>> this case.
>> 
>> * If the mangled name is present in the archive, you can re-mangle it to get 
>> the metadata accessor
>> * If it’s a one-level unmangled name representing a class, it can be mangled
>> * If it’s a zero-level unmangled name, then it seems reasonable for a first 
>> implementation to assume it’s a SwiftFoundation class (or that the caller 
>> has set an explici

Re: [swift-corelibs-dev] NSCoding methods

2015-12-23 Thread Luke Howard via swift-corelibs-dev 
I’m planning to use this for now:

https://github.com/lhoward/swift-corelibs-foundation/commit/177e7d9f945db58217edec70d90d5cb53cba0245
 


Noted that it won’t work for non-public symbols, but at least I can see how far 
I can get with NSKeyedArchiver/Unarchiver in the meantime.

— Luke___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

2015-12-24 Thread Luke Howard via swift-corelibs-dev 
NSKeyedUnarchiver is working, at least for a few classes for which I’ve 
implemented initWithCoder:. Promisingly encoding and decoding nested Swift 
classes works, using name mangling we discussed yesterday.

It does use NSPropertyListSerialization to read the entire property list into 
memory, whereas it appears Foundation incrementally decodes the archive 
directly. I’m not sure if I’ll have time to implement incremental decoding but 
at least this should be a start.

— Luke

> On 24 Dec 2015, at 1:51 PM, Luke Howard via swift-corelibs-dev 
>  wrote:
> 
> I’m planning to use this for now:
> 
> https://github.com/lhoward/swift-corelibs-foundation/commit/177e7d9f945db58217edec70d90d5cb53cba0245
>  
> <https://github.com/lhoward/swift-corelibs-foundation/commit/177e7d9f945db58217edec70d90d5cb53cba0245>
> 
> Noted that it won’t work for non-public symbols, but at least I can see how 
> far I can get with NSKeyedArchiver/Unarchiver in the meantime.
> 
> — Luke
> 
> ___
> swift-corelibs-dev mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

--
www.lukehoward.com
soundcloud.com/lukehoward

___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

2015-12-25 Thread Luke Howard via swift-corelibs-dev 
Looking at decodeObjectOfClasses/allowedClasses – what is the element type in 
the set of allowed classes? It seems like it should be AnyClass but that can’t 
be added to a Set because it doesn’t implement Hashable (nor to an NSSet 
because the initialiser unconditionally casts to NSObject).

— Luke
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

2015-12-26 Thread Luke Howard via swift-corelibs-dev 
Thanks - also the WithObjCType methods could have a nicer interface (make the 
type an enum of Character, take Any instead of an unsafe pointer).

Sent from my iPhone

> On 26 Dec 2015, at 05:46, Philippe Hausler  wrote:
> 
> Likely we will have to change that signature to instead of being NSSet and 
> Set respectively to be more compatible; however this will be an API 
> change. It might be good to mock up a swift translation layer for these APIs 
> to simulate what it would be like on Darwin if we altered these to be renamed 
> in swift and presented with a better interface via the SDK overlays. Note: 
> this will have to go through our evolution proposal system and be weighed in 
> by the component owners of NSKeyedArchiver and the API teams associated with 
> that to make such a change.
> 
> In my opinion since AnyClass should be unique it by nature should be Hashable 
> - however I am not certain we can actually do that without language changes.
> 
> Perhaps for the time being we could alter the signatures to be:
> 
> public func decodeObjectOfClasses(classes: [AnyClass], forKey key: String) -> 
> AnyObject?
> 
> public var allowedClasses: [AnyClass]?
> 
> 
>> On Dec 25, 2015, at 2:01 AM, Luke Howard via swift-corelibs-dev 
>>  wrote:
>> 
>> Looking at decodeObjectOfClasses/allowedClasses – what is the element type 
>> in the set of allowed classes? It seems like it should be AnyClass but that 
>> can’t be added to a Set because it doesn’t implement Hashable (nor to an 
>> NSSet because the initialiser unconditionally casts to NSObject).
>> 
>> — Luke
>> ___
>> swift-corelibs-dev mailing list
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

2015-12-26 Thread Luke Howard via swift-corelibs-dev 
Thanks - also the encodeValueOfObjCType methods could have a nicer interface 
(make the type an enum of Character, take Any instead of an unsafe pointer)...

Sent from my iPhone

> On 26 Dec 2015, at 05:46, Philippe Hausler  wrote:
> 
> Likely we will have to change that signature to instead of being NSSet and 
> Set respectively to be more compatible; however this will be an API 
> change. It might be good to mock up a swift translation layer for these APIs 
> to simulate what it would be like on Darwin if we altered these to be renamed 
> in swift and presented with a better interface via the SDK overlays. Note: 
> this will have to go through our evolution proposal system and be weighed in 
> by the component owners of NSKeyedArchiver and the API teams associated with 
> that to make such a change.
> 
> In my opinion since AnyClass should be unique it by nature should be Hashable 
> - however I am not certain we can actually do that without language changes.
> 
> Perhaps for the time being we could alter the signatures to be:
> 
> public func decodeObjectOfClasses(classes: [AnyClass], forKey key: String) -> 
> AnyObject?
> 
> public var allowedClasses: [AnyClass]?
> 
> 
>> On Dec 25, 2015, at 2:01 AM, Luke Howard via swift-corelibs-dev 
>>  wrote:
>> 
>> Looking at decodeObjectOfClasses/allowedClasses – what is the element type 
>> in the set of allowed classes? It seems like it should be AnyClass but that 
>> can’t be added to a Set because it doesn’t implement Hashable (nor to an 
>> NSSet because the initialiser unconditionally casts to NSObject).
>> 
>> — Luke
>> ___
>> swift-corelibs-dev mailing list
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

2015-12-26 Thread Luke Howard via swift-corelibs-dev 
Another language thing I ran into – using classForKeyedArchiver/classForCoder 
is impossible because declarations from extensions cannot be overridden yet.

For example I’d like to do:

internal class _NSCFString : NSMutableString {
… 
override var classForCoder: AnyClass {
return NSMutableString.self
}
}

There are a few ways I can work around it but perhaps we can put these 
extensions directly on NSObject for now?

— Luke___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

2015-12-26 Thread Luke Howard via swift-corelibs-dev 

> On 27 Dec 2015, at 3:45 AM, Philippe Hausler  wrote:
> 
> Totally reasonable since that is a limitation that will cause subclassers to 
> not be able to implement that even outside of Foundation.
> 
> What would help most for unit testing what you have so far?
> 
> I have a few init?(coder:) implementations that should match the 
> implementations on darwin; primarily I was focused on getting the plist types 
> done first and then moving onto the other classes.

I’ve done the plist classes and a few others such as NSURL, NSLocale, NSUUID. 
I’m going to look at the rest today, other remaining todos are:

* encodeValueOfObjCType()
* reviewing fatal vs non-fatal error cases
* testing reading/writing from a stream (vs memory), seem to be some issues 
with this
* unit tests
* incremental decoding (probably will not get to this)

Also I’m only looking at NSKeyedArchiver – do we need to support NSArchiver?

Finally, I filed a few bugs (with patches) for things I bumped into along the 
way:

* SR-378: Uninitialised memory in NSDictionary initialiser
* SR-379: CFDictionaryGetKeysAndValues() bridges in wrong order
* SR-380: Occasional crashes in NSString.hash.getter
* SR-381: Request for API to return mangled nominal type name
* SR-386: NSLog() API

— Luke
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

2015-12-26 Thread Luke Howard via swift-corelibs-dev 
> I was looking over some of the init and encode methods you have, there are a 
> few bits that might need some touch ups to match behavioral differences but I 
> think I can probably merge in some of the work I have done as an addendum to 
> what you have already gotten done.

Great, I just gave you write access to the branch.

> It might be good for review side of things to break out those other issues 
> into their own pull requests. Is there a reason to implement NSLog and not 
> just use print?

Not really, just trying to make the messages look similar to Foundation.

> SR-380; that is a compiler issue? or runtime?

Haven’t done enough research to say I’m afraid, I just did a quick fix and 
moved on.

> NSArchiver is old and not very cross platform on the darwin side of things 
> anyhow. I think we should just focus on NSCoder/NSKeyedArchiver and user 
> subclasses of each case.

Agreed.

> Have you tested yet on ubuntu?


Not yet, but will do once I’ve made a bit more progress.

— Luke
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

2015-12-26 Thread Luke Howard via swift-corelibs-dev 

> On 27 Dec 2015, at 1:54 PM, Philippe Hausler  wrote:
> 
> It might be good for review side of things to break out those other issues 
> into their own pull requests.

Agreed – I’ll do this soon.

— Luke
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

2015-12-26 Thread Luke Howard via swift-corelibs-dev 

> On 27 Dec 2015, at 3:09 PM, Philippe Hausler  wrote:
> 
> So a few results so far from the linux side: I ran across a few compiler 
> crashes in the function metadataFromAccessorName; I need to dive a bit deeper 
> into why it is failing.
> I have a few cross platform corrections that I will be pushing shortly for 
> you.

Thanks! With metadataFromAccessorName(), I guess just check the string is valid 
for starters; I’m surprised it even built as _CFCopyNominalTypeNameForClass() 
is C++ ABI-fragile.

— Luke
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

[swift-corelibs-dev] getCString question

2015-12-26 Thread Luke Howard via swift-corelibs-dev 
In the implementation of getCString() in NSString.swift, it doesn’t appear to 
add the terminating NUL byte – is this a bug or am I missing something?

— Luke
--
www.lukehoward.com
soundcloud.com/lukehoward___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

2015-12-27 Thread Luke Howard via swift-corelibs-dev 

> On 27 Dec 2015, at 3:09 PM, Philippe Hausler  wrote:
> 
> So a few results so far from the linux side: I ran across a few compiler 
> crashes in the function metadataFromAccessorName; I need to dive a bit deeper 
> into why it is failing.
> I have a few cross platform corrections that I will be pushing shortly for 
> you.

Thanks Philippe, integrated most of these except for the changes to 
metadataFromAccessorName() – the symbol prefix was wrong and I think it’s 
better to stick with the approach of indirecting the metadata lookup through 
the accessor. Obviously if there’s a compiler issue on Linux we should fix it :)

(Hopefully I didn’t miss anything on the merge, unfortunately rebasing to 
master before merging your changes made it a bit fiddly.)

I’ve implemented but not extensively tested decodeValueOfObjCType(). Do we need 
to support NSConcreteValue?

— Luke
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

2015-12-28 Thread Luke Howard via swift-corelibs-dev 

> On 27 Dec 2015, at 9:31 PM, Luke Howard via swift-corelibs-dev 
>  wrote:
> 
> I’ve implemented but not extensively tested decodeValueOfObjCType(). Do we 
> need to support NSConcreteValue?

I started looking at NSConcreteValue (commit 1a9fe560) and decoding it is fine 
(notwithstanding implementing all the special cases).

What’s the plan for instantiating concrete of NSValue though?

* Class clusters seem impossible to implement in Swift
* Factory methods are an API change
* NSValue becoming concrete seems to muck up CF bridging (also, fragile base 
class problem)
* I looked a little into using ManagedBuffer to size instances dynamically but 
it’s not much help by the time init() is called
* A lookaside table works and is straightforward to implement, but is pretty 
ugly

— Luke
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

2015-12-28 Thread Luke Howard via swift-corelibs-dev 

> On 29 Dec 2015, at 3:01 AM, Philippe Hausler  wrote:
> 
> Not certain what you mean there; each NSValue is just a identity of a key in 
> a dictionary to a NSConcreteValue that the methods forward to? That would 
> mean that each method call would be a dictionary lookup… that does not sound 
> scalable from a performance standpoint.

That is what I meant – and yes I agree.

> In summary - I think perhaps it would be better to start thinking about 
> batching up parts of the NSCoder work and getting it merged before tackling 
> NSValue


Cool, I want to test on Linux first and then reorganise/cleanup the commit 
history.

— Luke
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

2015-12-28 Thread Luke Howard via swift-corelibs-dev 

> On 29 Dec 2015, at 3:01 AM, Philippe Hausler  wrote:
> 
> Not certain what you mean there; each NSValue is just a identity of a key in 
> a dictionary to a NSConcreteValue that the methods forward to? That would 
> mean that each method call would be a dictionary lookup… that does not sound 
> scalable from a performance standpoint.

Although didn’t NSObject do something similar for managing the retain count 
when it didn’t fit inline? I’m too lazy to go look it up...

— Luke
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

2015-12-28 Thread Luke Howard via swift-corelibs-dev 
Yeah, that’s what I implemented (although I forgot the synchronized bit, ahem). 
I backed it out though after your earlier email. I’ll try your patch…

> On 29 Dec 2015, at 10:46 AM, Philippe Hausler  wrote:
> 
>> 
>> On Dec 28, 2015, at 3:10 PM, Luke Howard  wrote:
>> 
>> 
>>> On 29 Dec 2015, at 3:01 AM, Philippe Hausler  wrote:
>>> 
>>> Not certain what you mean there; each NSValue is just a identity of a key 
>>> in a dictionary to a NSConcreteValue that the methods forward to? That 
>>> would mean that each method call would be a dictionary lookup… that does 
>>> not sound scalable from a performance standpoint.
>> 
>> Although didn’t NSObject do something similar for managing the retain count 
>> when it didn’t fit inline? I’m too lazy to go look it up...
>> 
>> — Luke
> 
> Yea the objc runtime has side tables for things like that; I guess I would 
> have to see a proposed implementation and play with it to see what the 
> performance hit would be like.
> 
> So you were thinking something like (note this is just something I drafted in 
> a few minutes so it is a bit rough):
> 
> diff --git a/Foundation/NSDecimalNumber.swift 
> b/Foundation/NSDecimalNumber.swift
> index 927be14..2e6791f 100644
> --- a/Foundation/NSDecimalNumber.swift
> +++ b/Foundation/NSDecimalNumber.swift
> @@ -96,7 +96,7 @@ public class NSDecimalNumber : NSNumber {
> //   ignore exactnessException
> //   raise on overflow, underflow and divide by zero.
> 
> -public var objCType: UnsafePointer { NSUnimplemented() }
> +public override var objCType: UnsafePointer { NSUnimplemented() }
> // return 'd' for double
> 
> public override var doubleValue: Double { NSUnimplemented() }
> diff --git a/Foundation/NSValue.swift b/Foundation/NSValue.swift
> index eefb3b9..6f495a0 100644
> --- a/Foundation/NSValue.swift
> +++ b/Foundation/NSValue.swift
> @@ -8,10 +8,68 @@
> //
> 
> 
> +internal class NSConcreteValue : NSValue {
> +internal var _value: UnsafeMutablePointer = nil
> +internal var _size: Int = 0
> +internal var _objCType: UnsafePointer = nil
> +
> +internal override init() {
> +super.init()
> +}
> +
> +required init?(coder aDecoder: NSCoder) {
> +NSUnimplemented()
> +}
> +
> +override func getValue(value: UnsafeMutablePointer) {
> +value.assignFrom(_value, count: _size)
> +}
> +
> +override var objCType: UnsafePointer {
> +return _objCType
> +}
> +}
> +
> +private var _NSValueSideTable = [ObjectIdentifier : NSConcreteValue]()
> +private var _NSValueSideTableLock = NSLock()
> +
> public class NSValue : NSObject, NSCopying, NSSecureCoding, NSCoding {
> 
> internal override init() {
> -
> +super.init()
> +if self.dynamicType == NSValue.self {
> +_NSValueSideTableLock.synchronized {
> +_NSValueSideTable[ObjectIdentifier(self)] = NSConcreteValue()
> +}
> +}
> +}
> +
> +deinit {
> +if self.dynamicType == NSValue.self {
> +_NSValueSideTableLock.synchronized {
> +_NSValueSideTable[ObjectIdentifier(self)] = nil
> +}
> +}
> +}
> +
> +public func getValue(value: UnsafeMutablePointer) {
> +if self.dynamicType == NSValue.self {
> +_NSValueSideTableLock.synchronized {
> +_NSValueSideTable[ObjectIdentifier(self)]!.getValue(value)
> +}
> +} else {
> +NSRequiresConcreteImplementation()
> +}
> +}
> +
> +public var objCType: UnsafePointer {
> +if self.dynamicType == NSValue.self {
> +return _NSValueSideTableLock.synchronized {
> +return _NSValueSideTable[ObjectIdentifier(self)]!.objCType
> +}
> +} else {
> +NSRequiresConcreteImplementation()
> +}
> }
> 
> public required init?(coder aDecoder: NSCoder) {

--
www.lukehoward.com
soundcloud.com/lukehoward

___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

2015-12-28 Thread Luke Howard via swift-corelibs-dev 
NSConcreteValue is in the current nscoding branch BTW, it works for decoding 
(non-special types, special is todo).

— Luke
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

2015-12-28 Thread Luke Howard via swift-corelibs-dev 
https://github.com/lhoward/swift-corelibs-foundation/commit/49164ea312f0515c8a743d9cb322a78e513085f5

— Luke
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

2015-12-29 Thread Luke Howard via swift-corelibs-dev 
OK, so I’ve cleaned up the commit history for the NSCoding branch, you can find 
it here still:

https://github.com/lhoward/swift-corelibs-foundation/tree/lhoward/nscoding 


I haven’t opened a pull request as I’d like to get it working on Linux first. 
Having a bit of trouble though. (I’m using Ubuntu 15.10 with the latest 
snapshot.)

Firstly, build-wise:

* Changing anything in Foundation/ seems to trigger a recompile of everything 
Swift. Is there a way to do correct dependency analysis? My clock is OK.

* swift/utils/build-script with —debug-foundation still seems to build a 
release version. I worked around by building everything debug, but that takes 
up a lot of disk space.

* lldb crashes all the time when printing variables (actually I also see this 
on OS X as well with the snapshot)

Related to testing:

* Something weird is going on with casting over which completely breaks 
NSKeyedArchiver. I can reproduce it with the following:

let foo = (NSMutableArray() as? AnyObject) as? NSCoding

which the compiler tells me always succeeds (as I believe it should), but at 
runtime returns foo==nil. No issue if it is a locally defined class that 
conforms to NSCoding. It’s failing in _dynamicCastToExistential()’s check for 
_conformsToProtocols() but I haven’t dug deeper yet.

FYI: my LD_LIBRARY_PATH is pointing to the right libswiftCore/libFoundation. I 
removed the module maps for Foundation/CoreFoundation from the snapshot 
directory.

* Subclassing NSObject fails outside Foundation (see SR-272) is also an issue 
but not a blocking one

— Luke___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

2015-12-29 Thread Luke Howard via swift-corelibs-dev 

> On 30 Dec 2015, at 12:03 AM, Luke Howard  wrote:
> 
> * Something weird is going on with casting over which completely breaks 
> NSKeyedArchiver. I can reproduce it with the following:
> 
> let foo = (NSMutableArray() as? AnyObject) as? NSCoding


More details at:

https://bugs.swift.org/browse/SR-404 

— Luke___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

2015-12-29 Thread Luke Howard via swift-corelibs-dev 

> On 30 Dec 2015, at 6:20 AM, Philippe Hausler  wrote:
> 
>> * Something weird is going on with casting over which completely breaks 
>> NSKeyedArchiver. I can reproduce it with the following:
>> 
>> let foo = (NSMutableArray() as? AnyObject) as? NSCoding

https://github.com/lhoward/swift-corelibs-foundation/commit/0de79438392d94ebff45c602bad144aefd1bff13
 


seems to fix this specific issue

— Luke___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

2015-12-29 Thread Luke Howard via swift-corelibs-dev 
OK, it is working on Linux (lightly tested). It needs a compiler fix though, 
see [SR-412].

— Luke
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

[swift-corelibs-dev] Equality, etc in Foundation

2015-12-29 Thread Luke Howard via swift-corelibs-dev 
Whilst implementing XCTests for NSKeyedUnarchiver, I noticed some issues with 
equality.
Let’s say I have the following simple Swift program:

import SwiftFoundation

let url1 = NSURL(string: "foo.xml", relativeToURL:NSURL(string: 
"https://www.example.com";))!
let url2 = NSURL(string: "foo.xml", relativeToURL:NSURL(string: 
"https://www.example.com";))!

print("\(url1.isEqual(url2))")
print("\(url1 == url2)")

It returns false for both, as opposed to true on OS X Foundation.

NSObject() implements Equatable in terms of isEqual; that’s fine, but apart 
from __NSCFType the bridged types do not implement isEqual:. It seems that 
hash, isEqual and description need to be pasted in for the bridged types, à la 
CF_CLASSIMPLEMENTATION.

I feel though I may be missing something – I would have thought TestFoundation 
would depend on the equality operator working :)

— Luke___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Equality, etc in Foundation

2015-12-29 Thread Luke Howard via swift-corelibs-dev 
Proposed fix:

https://github.com/lhoward/swift-corelibs-foundation/commit/fe5dcce6ccf06d2f5b8e85c792012dbaee8f59f7
 
<https://github.com/lhoward/swift-corelibs-foundation/commit/fe5dcce6ccf06d2f5b8e85c792012dbaee8f59f7>

Also tracking in [SR-414].

> On 30 Dec 2015, at 6:15 PM, Luke Howard via swift-corelibs-dev 
>  wrote:
> 
> import SwiftFoundation
> 
> let url1 = NSURL(string: "foo.xml", relativeToURL:NSURL(string: 
> "https://www.example.com <https://www.example.com/>"))!
> let url2 = NSURL(string: "foo.xml", relativeToURL:NSURL(string: 
> "https://www.example.com <https://www.example.com/>"))!
> 
> print("\(url1.isEqual(url2))")
> print("\(url1 == url2)")
> 

--
www.lukehoward.com
soundcloud.com/lukehoward

___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

2015-12-30 Thread Luke Howard via swift-corelibs-dev 
I’ve written a few unit tests for NSKeyedArchiver/NSKeyedUnarchiver but it 
could do with lots more (if anyone is interested!). We are gated by some 
methods not having isEqual() implementations yet (which is used to verify the 
test results).

The tests pass on both Linux and OS X, although presently the user class test 
is disabled for Linux as subclassing NSObject outside of Foundation is broken.

The NSKeyedArchiver tests encode an object (graph), decode it and check it 
matches. The NSKeyedUnarchiver tests decode an object (graph) that was encoded 
using OS X Foundation. We currently don’t exercise NSKeyedArchiver writing to a 
file, although it does work on both platforms.

— Luke

Executed 24 tests, with 0 failures (0 unexpected) in 0.001 (0.022) seconds
Test Case 'TestNSKeyedArchiver.test_archive_array' started.
Test Case 'TestNSKeyedArchiver.test_archive_array' passed (0.01 seconds).
Test Case 'TestNSKeyedArchiver.test_archive_dictionary' started.
Test Case 'TestNSKeyedArchiver.test_archive_dictionary' passed (0.013 seconds).
Test Case 'TestNSKeyedArchiver.test_archive_string' started.
Test Case 'TestNSKeyedArchiver.test_archive_string' passed (0.003 seconds).
Test Case 'TestNSKeyedArchiver.test_archive_mutable_array' started.
Test Case 'TestNSKeyedArchiver.test_archive_mutable_array' passed (0.01 
seconds).
Test Case 'TestNSKeyedArchiver.test_archive_mutable_dictionary' started.
Test Case 'TestNSKeyedArchiver.test_archive_mutable_dictionary' passed (0.008 
seconds).
Test Case 'TestNSKeyedArchiver.test_archive_null' started.
Test Case 'TestNSKeyedArchiver.test_archive_null' passed (0.006 seconds).
Test Case 'TestNSKeyedArchiver.test_archive_set' started.
Test Case 'TestNSKeyedArchiver.test_archive_set' passed (0.006 seconds).
Test Case 'TestNSKeyedArchiver.test_archive_url' started.
Test Case 'TestNSKeyedArchiver.test_archive_url' passed (0.007 seconds).
Test Case 'TestNSKeyedArchiver.test_archive_user_class' started.
Test Case 'TestNSKeyedArchiver.test_archive_user_class' passed (0.0 seconds).
Test Case 'TestNSKeyedArchiver.test_archive_uuid' started.
Test Case 'TestNSKeyedArchiver.test_archive_uuid' passed (0.008 seconds).
Executed 10 tests, with 0 failures (0 unexpected) in 0.007 (0.071) seconds
Test Case 'TestNSKeyedUnarchiver.test_unarchive_array' started.
Test Case 'TestNSKeyedUnarchiver.test_unarchive_array' passed (0.004 seconds).
Test Case 'TestNSKeyedUnarchiver.test_unarchive_complex' started.
Test Case 'TestNSKeyedUnarchiver.test_unarchive_complex' passed (0.012 seconds).
Test Case 'TestNSKeyedUnarchiver.test_unarchive_concrete_value' started.
Test Case 'TestNSKeyedUnarchiver.test_unarchive_concrete_value' passed (0.01 
seconds).
Test Case 'TestNSKeyedUnarchiver.test_unarchive_url' started.
Test Case 'TestNSKeyedUnarchiver.test_unarchive_url' passed (0.005 seconds).
Test Case 'TestNSKeyedUnarchiver.test_unarchive_uuid' started.
Test Case 'TestNSKeyedUnarchiver.test_unarchive_uuid' passed (0.003 seconds).

___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

2016-01-01 Thread Luke Howard via swift-corelibs-dev 

> On 29 Dec 2015, at 10:54 AM, Philippe Hausler  wrote:
> 
> It is ok on the special types; those are harder than they may seem… NSValue 
> in Darwin has some limitations like that especially when it comes to secure 
> coding or non standard aligned values.

I have a solution that’s not too inelegant, see:

https://github.com/lhoward/swift-corelibs-foundation/blob/lhoward/nscoding/Foundation/NSSpecialValue.swift

This takes advantage of the fact that structures can implement protocols in 
Swift. NSRect, etc implement NSCoding (by way of NSSpecialValueCoding). The 
structures are then boxed by NSSpecialValue (a subclass of NSValue). It would 
have been nice to make NSSpecialValue a generic class but unfortunately it 
doesn’t appear you can specialise at runtime, which the unarchiver would need 
to do.

e.g.

extension CGPoint: NSSpecialValueCoding {
public init?(coder aDecoder: NSCoder) {
if aDecoder.allowsKeyedCoding {
self = aDecoder.decodePointForKey("NS.pointval")
} else {
self = aDecoder.decodePoint()
}
}

public func encodeWithCoder(aCoder: NSCoder) {
if aCoder.allowsKeyedCoding {
aCoder.encodePoint(self, forKey: "NS.pointval")
} else {
aCoder.encodePoint(self)
}
}

public static func supportsSecureCoding() -> Bool {
return true
}

static func objCType() -> String {
return "{CGPoint=dd}"
}

func isEqual(aValue: Any) -> Bool {
if let other = aValue as? CGPoint {
return other == self
} else {
return false
}
}
}

There’s still NSConcreteValue for ObjC type representations but I found it 
difficult to merge the two (for reasons I can explain later).

Happy new year!

— Luke
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

[swift-corelibs-dev] CChar vs Int8

2016-01-02 Thread Luke Howard via swift-corelibs-dev 
Many Foundation APIs use Int8 instead of CChar when representing C strings, 
e.g.:
var UTF8String: UnsafePointer 
https://developer.apple.com/library/mac/documentation/Swift/Reference/Swift_Int8_Structure/index.html#//apple_ref/swift/struct/s:VSs4Int8>>
 { get }
I don’t know if/when Swift will be ported to a platform where the character 
type is unsigned but perhaps it would be good to update these to take CChar 
instead?

— Luke___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] CChar vs Int8

2016-01-04 Thread Luke Howard via swift-corelibs-dev 
OK, I filed [SR-466] as a compiler issue. If the behaviour changes and that 
flows through to Darwin Foundation, we can update the open source one...

— Luke

> On 5 Jan 2016, at 8:21 AM, Philippe Hausler  wrote:
> 
> No C strings import as UnsafePointer for some reason; they all import 
> as Int8
> 
> e.g.
> public func pthread_setname_np(_: UnsafePointer) -> Int32
> 
> 
>> On Jan 4, 2016, at 1:20 PM, Tony Parker via swift-corelibs-dev 
>> mailto:[email protected]>> wrote:
>> 
>> Hi Luke,
>> 
>>> On Jan 2, 2016, at 8:28 PM, Luke Howard via swift-corelibs-dev 
>>> mailto:[email protected]>> wrote:
>>> 
>>> Many Foundation APIs use Int8 instead of CChar when representing C strings, 
>>> e.g.:
>>> var UTF8String: UnsafePointer 
>>> <https://developer.apple.com/library/mac/documentation/Swift/Reference/Swift_UnsafePointer_Structure/index.html#//apple_ref/swift/struct/s:VSs13UnsafePointer>>>  
>>> <https://developer.apple.com/library/mac/documentation/Swift/Reference/Swift_Int8_Structure/index.html#//apple_ref/swift/struct/s:VSs4Int8>>
>>>  { get }
>>> I don’t know if/when Swift will be ported to a platform where the character 
>>> type is unsigned but perhaps it would be good to update these to take CChar 
>>> instead?
>>> 
>>> — Luke
>>> 
>> 
>> I’m not really sure why it’s imported to Swift as an unsafe pointer to Int8 
>> anyway. The Objective-C code uses char:
>> 
>> @property (nullable, readonly) __strong const char *UTF8String 
>> NS_RETURNS_INNER_POINTER; // Convenience to return null-terminated UTF8 
>> representation
>> 
>> - (nullable instancetype)initWithUTF8String:(const char 
>> *)nullTerminatedCString;
>> 
>> - Tony
>> 
>> 
>> ___
>> swift-corelibs-dev mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 

--
www.lukehoward.com
soundcloud.com/lukehoward

___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

2016-06-21 Thread Luke Howard via swift-corelibs-dev 
Hi Tony,

Just on the change to NSUUID’s decoder, it changes the existing behaviour (note 
comment "failure to decode the entire uuid_t results in a new uuid”). I don’t 
have time to test whether this comment is accurate but perhaps you can 
cross-check with Darwin.

Having said that, the new behaviour (returning nil on decode failure) does make 
a lot more sense so perhaps it’s better to keep that.

Cheers,
Luke

> On 22 Jun 2016, at 2:46 AM, Tony Parker via swift-corelibs-dev 
>  wrote:
> 
> Hi everyone,
> 
> We’ve merged the swift-3 branch into master. Please let us know if you 
> encounter any issues.
> 
> I’m going to keep going through pull requests, but some may be out of date 
> and need rebasing now.
> 
> Thanks,
> - Tony
> 
>> On Jun 14, 2016, at 10:24 AM, Tony Parker > > wrote:
>> 
>> Hello everyone,
>> 
>> If you’ve downloaded Xcode 8 beta 1, you’ve seen some of the great changes 
>> we’ve got coming up for Swift 3 on Darwin. We have been working in parallel 
>> on those improvements and the changes that we need to bring 
>> swift-corelibs-foundation up-to-date, including:
>> 
>>  * new value types (SE-0069)
>>  * new names for API and NS-dropping changes (SE-0086)
>>  * new tests (mostly part of the overlay, not all merged to corelibs yet)
>> 
>> We plan to post later today a branch (name forthcoming) to the 
>> swift-corelibs-foundation repository that contains the first version of all 
>> of these changes. We’ve also been merging all of the other changes from 
>> master branch.
>> 
>> It’s not quite ready to merge back to master yet, so we would appreciate 
>> your help! Check out the branch, look for errors or omissions, and submit 
>> some PRs or send mail to this list.
>> 
>> Our hope is to merge this branch very quickly, in the span of a week or two 
>> at most. We will likely need to get some parallel PRs up for XCTest and 
>> swiftpm to help them adapt to the new name and type changes. 
>> 
>> Thanks!
>> - Tony
>> 
> 
> ___
> swift-corelibs-dev mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

--
www.lukehoward.com
soundcloud.com/lukehoward

___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

2016-07-05 Thread Luke Howard via swift-corelibs-dev 
I added NSLog for NSKeyedArchiver so the output formatting would more closely 
match Darwin, but I punted whether to make it public.

> On 6 Jul 2016, at 5:42 AM, Tony Parker via swift-corelibs-dev 
>  wrote:
> 
> Hi Sai,
> 
> Out of curiosity, why NSLog instead of Swift’s print function?
> 
> - Tony
> 
>> On Jun 27, 2016, at 4:37 AM, Sai Kanduri via swift-corelibs-dev 
>> mailto:[email protected]>> wrote:
>> 
>> Hi All,
>>  
>> Currently NSLog  has only one internal function  NSLog()  which can be used 
>> only by Foundation classes.Can this be made available as a public API ?
>>  
>>  
>> Thanks & Regards,
>>  
>> Sai Hema,Java L3 Support
>> 
>> ___
>> swift-corelibs-dev mailing list
>> [email protected] 
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 
> ___
> swift-corelibs-dev mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

--
www.lukehoward.com
soundcloud.com/lukehoward

___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

2016-07-06 Thread Luke Howard via swift-corelibs-dev 
OK, we should fix the function signature to make it identical then (currently 
it does not take an argument list), and perhaps define NSLogv() as well.

> On 6 Jul 2016, at 8:36 PM, Chris Bailey  wrote:
> 
> The Darwin overlay contains: 
> 
> https://github.com/apple/swift/blob/master/stdlib/public/SDK/Foundation/Foundation.swift#L918
>  
> :
>  
> public func NSLog(_ format: String, _ args: CVarArg...) { 
>   withVaList(args) { NSLogv(format, $0) } 
> } 
> 
> So for consistency it would make sense to expose it on other platforms as 
> well. 
> 
> Chris
> 
> 
> 
> 
> From:Tony Parker via swift-corelibs-dev 
>  
> To:Luke Howard  
> Cc:[email protected] 
> Date:06/07/2016 00:57 
> Subject:Re: [swift-corelibs-dev] Query on NSLog 
> Sent by:[email protected] 
> 
> 
> 
> Frankly, I think I just forgot to put a stub for it when we put out the first 
> set of APIs. 
> 
> - Tony 
> 
> On Jul 5, 2016, at 4:54 PM, Luke Howard  > wrote: 
> 
> I added NSLog for NSKeyedArchiver so the output formatting would more closely 
> match Darwin, but I punted whether to make it public. 
> 
> On 6 Jul 2016, at 5:42 AM, Tony Parker via swift-corelibs-dev 
> mailto:[email protected]>> wrote: 
> 
> Hi Sai, 
> 
> Out of curiosity, why NSLog instead of Swift’s print function? 
> 
> - Tony 
> 
> On Jun 27, 2016, at 4:37 AM, Sai Kanduri via swift-corelibs-dev 
> mailto:[email protected]>> wrote: 
> 
> Hi All, 
>   
> Currently NSLog  has only one internal function  NSLog()  which can be used 
> only by Foundation classes.Can this be made available as a public API ? 
>   
>   
> Thanks & Regards, 
>   
> Sai Hema,Java L3 Support 
> 
> ___
> swift-corelibs-dev mailing list
> [email protected] 
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>  
> 
> ___
> swift-corelibs-dev mailing list
> [email protected] 
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>  
> 
> -- 
> www.lukehoward.com 
> soundcloud.com/lukehoward  
> 
> ___
> swift-corelibs-dev mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
> 
> 
> 

--
www.lukehoward.com
soundcloud.com/lukehoward

___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

[swift-corelibs-dev] small nit in NSKeyedArchiver.swift

2016-07-19 Thread Luke Howard via swift-corelibs-dev 
Posting to mailing list as I’m not able to test this right now, but I suspect 
this patch should be applied –

diff --git a/Foundation/NSKeyedArchiver.swift b/Foundation/NSKeyedArchiver.swift
index d070a15..fdcedae 100644
--- a/Foundation/NSKeyedArchiver.swift
+++ b/Foundation/NSKeyedArchiver.swift
@@ -193,7 +193,7 @@ public class NSKeyedArchiver : NSCoder {
 }
 } else {
 success = CFPropertyListWrite(plist, self._stream as! 
CFWriteStream,
-  kCFPropertyListOpenStepFormat, 0, 
nil) > 0
+  kCFPropertyListXMLFormat_v1_0, 0, 
nil) > 0
 }
 
 return success

as the Openstep format is not supported by CF for writing.

--
www.lukehoward.com
soundcloud.com/lukehoward___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

[swift-corelibs-dev] Building with Xcode

2016-08-17 Thread Luke Howard via swift-corelibs-dev 
This is probably a dumb question. Building with XCode, TestFoundation depends 
on SwiftXCTest, which depends on SwiftFoundation. What’s the right way to solve 
this (almost) recursive dependency? I’m using the Xcode 8.0 beta6.

I worked around by symlinking the uninstalled build products directory to 
/Library/Frameworks and adding that as a search path to both projects, but 
presumably there’s a better way. Sorry for the noise if this has been discussed 
before, haven’t built SwiftFoundation for a while.

--
www.lukehoward.com
soundcloud.com/lukehoward___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Building with Xcode

2016-08-19 Thread Luke Howard via swift-corelibs-dev 
Are thank you, using the workspace fixed it. Sorry for the noise!

> On 19 Aug 2016, at 7:27 AM, Brian Gesiak  wrote:
> 
> I use the following to build Foundation and XCTest, then run the XCTest tests:
> 
> swift $ utils/build-script --preset corelibs-xctest 
> 
> The XCTest.xcworkspace is also capable of building and testing. Open it, 
> select the XCTest scheme, and build with ⌘B. You should also be able to build 
> the Foundation scheme from there as well.
> 
> - Brian Gesiak

___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

[swift-corelibs-dev] f8c3fe6c breaks on Darwin

2016-08-23 Thread Luke Howard via swift-corelibs-dev 
Enabling libdispatch seems to break the tests on Darwin because 
DEPLOYMENT_ENABLE_LIBDISPATCH is not added to the XCode project build flags 
(both for the C/Swift compilers).

--
www.lukehoward.com
soundcloud.com/lukehoward___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] f8c3fe6c breaks on Darwin

2016-08-23 Thread Luke Howard via swift-corelibs-dev 
Also, the NSData test is broken on Darwin when libdispatch is enabled – 
possibly the system DispatchData is being pulled in and something funny 
happens, this seems to work around it but I’m not sure if it is the correct fix:

+++ b/Foundation/NSData.swift
@@ -228,7 +228,7 @@ open class NSData : NSObject, NSCopying, NSMutableCopying, 
NSSecureCoding {
 }
 
 open override func isEqual(_ value: Any?) -> Bool {
-#if DEPLOYMENT_ENABLE_LIBDISPATCH
+#if DEPLOYMENT_ENABLE_LIBDISPATCH && !os(OSX)
 if let data = value as? DispatchData {
 if data.count != length {
 return false


> On 23 Aug 2016, at 5:46 PM, Luke Howard via swift-corelibs-dev 
>  wrote:
> 
> Enabling libdispatch seems to break the tests on Darwin because 
> DEPLOYMENT_ENABLE_LIBDISPATCH is not added to the XCode project build flags 
> (both for the C/Swift compilers).
> 
> --
> www.lukehoward.com <http://www.lukehoward.com/>
> soundcloud.com/lukehoward
> ___
> swift-corelibs-dev mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

--
www.lukehoward.com
soundcloud.com/lukehoward

___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] f8c3fe6c breaks on Darwin

2016-08-23 Thread Luke Howard via swift-corelibs-dev 
c26f465e breaks even further on Darwin – Xcode project not updated, after 
updating that:

/Users/lukeh/CVSRoot/apple/swift-corelibs-foundation/Foundation/NSURLSession/MultiHandle.swift:216:38:
 error: '_EasyHandle' is not a member type of 'URLSessionTask'
fileprivate extension URLSessionTask._EasyHandle {
  ~~ ^

> On 24 Aug 2016, at 1:50 AM, Philippe Hausler  wrote:
> 
> Tossed up a PR for correcting this uniformly without needing alteration of 
> the #if statements
> 
> https://github.com/apple/swift-corelibs-foundation/pull/584 
> <https://github.com/apple/swift-corelibs-foundation/pull/584>
>> On Aug 23, 2016, at 8:42 AM, Chris Bailey via swift-corelibs-dev 
>> mailto:[email protected]>> wrote:
>> 
>> We're currently making the last few changes which should mean that Dispatch 
>> always builds on Linux if your using Foundation, and as Dispatch is already 
>> there on Darwin, it should mean we can remove the condition statements 
>> entirely. 
>> 
>> Chris
>> 
>> 
>> 
>> 
>> From:Luke Howard via swift-corelibs-dev 
>> mailto:[email protected]>> 
>> To:Tony Parker via swift-corelibs-dev > <mailto:[email protected]>> 
>> Date:23/08/2016 08:55 
>> Subject:Re: [swift-corelibs-dev] f8c3fe6c breaks on Darwin 
>> Sent by:[email protected] 
>> <mailto:[email protected]> 
>> 
>> 
>> 
>> Also, the NSData test is broken on Darwin when libdispatch is enabled – 
>> possibly the system DispatchData is being pulled in and something funny 
>> happens, this seems to work around it but I’m not sure if it is the correct 
>> fix: 
>> 
>> +++ b/Foundation/NSData.swift 
>> @@ -228,7 +228,7 @@ open class NSData : NSObject, NSCopying, 
>> NSMutableCopying, NSSecureCoding { 
>>  } 
>>   
>>  open override func isEqual(_ value: Any?) -> Bool { 
>> -#if DEPLOYMENT_ENABLE_LIBDISPATCH 
>> +#if DEPLOYMENT_ENABLE_LIBDISPATCH && !os(OSX) 
>>  if let data = value as? DispatchData { 
>>  if data.count != length { 
>>  return false 
>> 
>> 
>> On 23 Aug 2016, at 5:46 PM, Luke Howard via swift-corelibs-dev 
>> mailto:[email protected]>> wrote: 
>> 
>> Enabling libdispatch seems to break the tests on Darwin because 
>> DEPLOYMENT_ENABLE_LIBDISPATCH is not added to the XCode project build flags 
>> (both for the C/Swift compilers). 
>> 
>> -- 
>> www.lukehoward.com <http://www.lukehoward.com/>
>> soundcloud.com/lukehoward <http://soundcloud.com/lukehoward> 
>> ___
>> swift-corelibs-dev mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>> <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev> 
>> 
>> -- 
>> www.lukehoward.com <http://www.lukehoward.com/>
>> soundcloud.com/lukehoward <http://soundcloud.com/lukehoward> 
>> ___
>> swift-corelibs-dev mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>> <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev>
>> 
>> 
>> ___
>> swift-corelibs-dev mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 

--
www.lukehoward.com
soundcloud.com/lukehoward

___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

2016-10-27 Thread Luke Howard via swift-corelibs-dev 
BTW is anything blocking integrating SR-2416?

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

That allows value types to be archived too if they support _ObjectBridgeable 
(they’ll come back as reference types though).

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

Luke Howard
web  / facebook 
 / soundcloud 
 / spotify 

___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

2016-10-28 Thread Luke Howard via swift-corelibs-dev 
Thanks, SR closed.

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

Luke Howard
web  / facebook 
 / soundcloud 
 / spotify 

___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

[swift-corelibs-dev] encodeEncodable/decodeDecodable

2017-09-20 Thread Luke Howard via swift-corelibs-dev 
I’m fairly out of touch with Swift these days, but I took a quick look at 
importing the encodeEncodable/decodeDecodable changes from stdlib into 
SwiftFoundation.

I ran into a bunch of bridging issues with the PropertyListDecoder, where it 
would be balk on the encoded property list types being Foundation instead of 
Swift types (e.g. “Expected to decode Dictionary but found a 
dictionary instead”).

Not sure the best way to workaround these: I started doing so explicitly in the 
unbox methods, but it didn’t feel intuitively right (apart from all the 
boilerplate code, sometimes the input value would be a Foundation object, other 
times not). I haven’t had time to investigate further.

Luke Howard
web  / facebook 
 / soundcloud 
 / spotify 
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] encodeEncodable/decodeDecodable

2017-09-22 Thread Luke Howard via swift-corelibs-dev 
Had a crack on this, is anyone able to test this on Linux?

https://github.com/lhoward/swift-corelibs-foundation/commit/8f8d16c8d68f1af7730522e728d96f8d93c88a2e
 
<https://github.com/lhoward/swift-corelibs-foundation/commit/8f8d16c8d68f1af7730522e728d96f8d93c88a2e>

> On 20 Sep 2017, at 23:30, Luke Howard via swift-corelibs-dev 
>  wrote:
> 
> I’m fairly out of touch with Swift these days, but I took a quick look at 
> importing the encodeEncodable/decodeDecodable changes from stdlib into 
> SwiftFoundation.
> 
> I ran into a bunch of bridging issues with the PropertyListDecoder, where it 
> would be balk on the encoded property list types being Foundation instead of 
> Swift types (e.g. “Expected to decode Dictionary but found a 
> dictionary instead”).
> 
> Not sure the best way to workaround these: I started doing so explicitly in 
> the unbox methods, but it didn’t feel intuitively right (apart from all the 
> boilerplate code, sometimes the input value would be a Foundation object, 
> other times not). I haven’t had time to investigate further.
> 
> Luke Howard
> web <http://lukehoward.com/> / facebook 
> <https://www.facebook.com/lukehowardmusic> / soundcloud 
> <https://soundcloud.com/lukehoward/> / spotify 
> <https://open.spotify.com/artist/3duTXsC49HoPt4f4EySDKf>___
> swift-corelibs-dev mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Luke Howard
web <http://lukehoward.com/> / facebook 
<https://www.facebook.com/lukehowardmusic> / soundcloud 
<https://soundcloud.com/lukehoward/> / spotify 
<https://open.spotify.com/artist/3duTXsC49HoPt4f4EySDKf>
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] encodeEncodable/decodeDecodable

2017-09-25 Thread Luke Howard via swift-corelibs-dev 
Hi Itai,

Pull request is here 
<https://github.com/apple/swift-corelibs-foundation/pull/1237>, unfortunately 
tests are failing on Linux. I’m still trying to get Swift built on Linux so I 
can investigate (didn’t have any luck using the prebuilt binaries to build 
Foundation).

Cheers,
Luke

> On 26 Sep 2017, at 06:24, Itai Ferber  wrote:
> 
> Hi Luke,
> 
> Thanks for putting this together! Do you mind putting that up as a pull 
> request <https://github.com/apple/swift-corelibs-foundation/pulls> so we can 
> review it more formally and run it through CI?
> 
> — Itai
> 
> On 22 Sep 2017, at 19:53, Luke Howard via swift-corelibs-dev wrote:
> 
> Had a crack on this, is anyone able to test this on Linux?
> 
> https://github.com/lhoward/swift-corelibs-foundation/commit/8f8d16c8d68f1af7730522e728d96f8d93c88a2e
>  
> <https://github.com/lhoward/swift-corelibs-foundation/commit/8f8d16c8d68f1af7730522e728d96f8d93c88a2e>
> 
>> On 20 Sep 2017, at 23:30, Luke Howard via swift-corelibs-dev 
>> mailto:[email protected]>> wrote:
>> 
>> I’m fairly out of touch with Swift these days, but I took a quick look at 
>> importing the encodeEncodable/decodeDecodable changes from stdlib into 
>> SwiftFoundation.
>> 
>> I ran into a bunch of bridging issues with the PropertyListDecoder, where it 
>> would be balk on the encoded property list types being Foundation instead of 
>> Swift types (e.g. “Expected to decode Dictionary but found a 
>> dictionary instead”).
>> 
>> Not sure the best way to workaround these: I started doing so explicitly in 
>> the unbox methods, but it didn’t feel intuitively right (apart from all the 
>> boilerplate code, sometimes the input value would be a Foundation object, 
>> other times not). I haven’t had time to investigate further.
>> 
>> Luke Howard
>> web <http://lukehoward.com/> / facebook 
>> <https://www.facebook.com/lukehowardmusic> / soundcloud 
>> <https://soundcloud.com/lukehoward/> / spotify 
>> <https://open.spotify.com/artist/3duTXsC49HoPt4f4EySDKf>___
>> swift-corelibs-dev mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 
> Luke Howard
> web <http://lukehoward.com/> / facebook 
> <https://www.facebook.com/lukehowardmusic> / soundcloud 
> <https://soundcloud.com/lukehoward/> / spotify 
> <https://open.spotify.com/artist/3duTXsC49HoPt4f4EySDKf>
> ___
> swift-corelibs-dev mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
> <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev>

Luke Howard
web <http://lukehoward.com/> / facebook 
<https://www.facebook.com/lukehowardmusic> / soundcloud 
<https://soundcloud.com/lukehoward/> / spotify 
<https://open.spotify.com/artist/3duTXsC49HoPt4f4EySDKf>
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] encodeEncodable/decodeDecodable

2017-09-27 Thread Luke Howard via swift-corelibs-dev 
Still having trouble building it on Linux – I did kind of get it built from 
swift-4.0-branch, but didn’t have a working lldb so was difficult to debug 
(except by printf). Currently appear to be running into SR-5938 when trying to 
build from master.

> On 26 Sep 2017, at 09:37, Luke Howard via swift-corelibs-dev 
>  wrote:
> 
> Hi Itai,
> 
> Pull request is here 
> <https://github.com/apple/swift-corelibs-foundation/pull/1237>, unfortunately 
> tests are failing on Linux. I’m still trying to get Swift built on Linux so I 
> can investigate (didn’t have any luck using the prebuilt binaries to build 
> Foundation).
> 
> Cheers,
> Luke
> 
>> On 26 Sep 2017, at 06:24, Itai Ferber > <mailto:[email protected]>> wrote:
>> 
>> Hi Luke,
>> 
>> Thanks for putting this together! Do you mind putting that up as a pull 
>> request <https://github.com/apple/swift-corelibs-foundation/pulls> so we can 
>> review it more formally and run it through CI?
>> 
>> — Itai
>> 
>> On 22 Sep 2017, at 19:53, Luke Howard via swift-corelibs-dev wrote:
>> 
>> Had a crack on this, is anyone able to test this on Linux?
>> 
>> https://github.com/lhoward/swift-corelibs-foundation/commit/8f8d16c8d68f1af7730522e728d96f8d93c88a2e
>>  
>> <https://github.com/lhoward/swift-corelibs-foundation/commit/8f8d16c8d68f1af7730522e728d96f8d93c88a2e>
>> 
>>> On 20 Sep 2017, at 23:30, Luke Howard via swift-corelibs-dev 
>>> mailto:[email protected]>> wrote:
>>> 
>>> I’m fairly out of touch with Swift these days, but I took a quick look at 
>>> importing the encodeEncodable/decodeDecodable changes from stdlib into 
>>> SwiftFoundation.
>>> 
>>> I ran into a bunch of bridging issues with the PropertyListDecoder, where 
>>> it would be balk on the encoded property list types being Foundation 
>>> instead of Swift types (e.g. “Expected to decode Dictionary 
>>> but found a dictionary instead”).
>>> 
>>> Not sure the best way to workaround these: I started doing so explicitly in 
>>> the unbox methods, but it didn’t feel intuitively right (apart from all the 
>>> boilerplate code, sometimes the input value would be a Foundation object, 
>>> other times not). I haven’t had time to investigate further.
>>> 
>>> Luke Howard
>>> web <http://lukehoward.com/> / facebook 
>>> <https://www.facebook.com/lukehowardmusic> / soundcloud 
>>> <https://soundcloud.com/lukehoward/> / spotify 
>>> <https://open.spotify.com/artist/3duTXsC49HoPt4f4EySDKf>___
>>> swift-corelibs-dev mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>>> <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev>
>> 
>> Luke Howard
>> web <http://lukehoward.com/> / facebook 
>> <https://www.facebook.com/lukehowardmusic> / soundcloud 
>> <https://soundcloud.com/lukehoward/> / spotify 
>> <https://open.spotify.com/artist/3duTXsC49HoPt4f4EySDKf>
>> ___
>> swift-corelibs-dev mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>> <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev>
> 
> Luke Howard
> web <http://lukehoward.com/> / facebook 
> <https://www.facebook.com/lukehowardmusic> / soundcloud 
> <https://soundcloud.com/lukehoward/> / spotify 
> <https://open.spotify.com/artist/3duTXsC49HoPt4f4EySDKf>
> ___
> swift-corelibs-dev mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Luke Howard
web <http://lukehoward.com/> / facebook 
<https://www.facebook.com/lukehowardmusic> / soundcloud 
<https://soundcloud.com/lukehoward/> / spotify 
<https://open.spotify.com/artist/3duTXsC49HoPt4f4EySDKf>
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] encodeEncodable/decodeDecodable

2017-09-27 Thread Luke Howard via swift-corelibs-dev 
Hi Itai,

I’ve done something for failWithError on Darwin, you should see it in the pull 
request. Still blocked on Linux, getting Swift to build.

Cheers,
Luke

> On 28 Sep 2017, at 05:57, Itai Ferber  wrote:
> 
> Hi Luke,
> 
> Thanks for putting this together! In the meantime, CI testing has highlighted 
> an issue that will need to be solved before this can be pulled in — namely 
> that NSKeyedUnarchiver is currently incomplete as it does not implement or 
> override failWithError properly.
> This is something we’ll need to do in order to support this properly.
> 
> — Itai
> 
> On 27 Sep 2017, at 7:35, Luke Howard wrote:
> 
> 
> Still having trouble building it on Linux – I did kind of get it built from 
> swift-4.0-branch, but didn’t have a working lldb so was difficult to debug 
> (except by printf). Currently appear to be running into SR-5938 when trying 
> to build from master.
> 
>> On 26 Sep 2017, at 09:37, Luke Howard via swift-corelibs-dev 
>> mailto:[email protected]>> wrote:
>> 
>> Hi Itai,
>> 
>> Pull request is here 
>> <https://github.com/apple/swift-corelibs-foundation/pull/1237>, 
>> unfortunately tests are failing on Linux. I’m still trying to get Swift 
>> built on Linux so I can investigate (didn’t have any luck using the prebuilt 
>> binaries to build Foundation).
>> 
>> Cheers,
>> Luke
>> 
>>> On 26 Sep 2017, at 06:24, Itai Ferber >> <mailto:[email protected]>> wrote:
>>> 
>>> Hi Luke,
>>> 
>>> Thanks for putting this together! Do you mind putting that up as a pull 
>>> request <https://github.com/apple/swift-corelibs-foundation/pulls> so we 
>>> can review it more formally and run it through CI?
>>> 
>>> — Itai
>>> 
>>> On 22 Sep 2017, at 19:53, Luke Howard via swift-corelibs-dev wrote:
>>> 
>>> Had a crack on this, is anyone able to test this on Linux?
>>> 
>>> https://github.com/lhoward/swift-corelibs-foundation/commit/8f8d16c8d68f1af7730522e728d96f8d93c88a2e
>>>  
>>> <https://github.com/lhoward/swift-corelibs-foundation/commit/8f8d16c8d68f1af7730522e728d96f8d93c88a2e>
>>> 
>>>> On 20 Sep 2017, at 23:30, Luke Howard via swift-corelibs-dev 
>>>> mailto:[email protected]>> wrote:
>>>> 
>>>> I’m fairly out of touch with Swift these days, but I took a quick look at 
>>>> importing the encodeEncodable/decodeDecodable changes from stdlib into 
>>>> SwiftFoundation.
>>>> 
>>>> I ran into a bunch of bridging issues with the PropertyListDecoder, where 
>>>> it would be balk on the encoded property list types being Foundation 
>>>> instead of Swift types (e.g. “Expected to decode Dictionary 
>>>> but found a dictionary instead”).
>>>> 
>>>> Not sure the best way to workaround these: I started doing so explicitly 
>>>> in the unbox methods, but it didn’t feel intuitively right (apart from all 
>>>> the boilerplate code, sometimes the input value would be a Foundation 
>>>> object, other times not). I haven’t had time to investigate further.
>>>> 
>>>> Luke Howard
>>>> web <http://lukehoward.com/> / facebook 
>>>> <https://www.facebook.com/lukehowardmusic> / soundcloud 
>>>> <https://soundcloud.com/lukehoward/> / spotify 
>>>> <https://open.spotify.com/artist/3duTXsC49HoPt4f4EySDKf>___
>>>> swift-corelibs-dev mailing list
>>>> [email protected] <mailto:[email protected]>
>>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>>>> <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev>
>>> 
>>> Luke Howard
>>> web <http://lukehoward.com/> / facebook 
>>> <https://www.facebook.com/lukehowardmusic> / soundcloud 
>>> <https://soundcloud.com/lukehoward/> / spotify 
>>> <https://open.spotify.com/artist/3duTXsC49HoPt4f4EySDKf>
>>> ___
>>> swift-corelibs-dev mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>>> <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev>
>> 
>> Luke Howard
>> web <http://lukehoward.com/> / facebook 
>> <https://www.facebook.com/lukehowardmusic> / soundcloud 
&g

Re: [swift-corelibs-dev] PropertyListDecoder/Encoder?

2017-11-16 Thread Luke Howard via swift-corelibs-dev 
https://github.com/apple/swift-corelibs-foundation/pull/1237

May/may not be useful - unfortunately couldn’t get it working on Linux so had 
to close.

Sent from my iPhone

> On 16 Nov 2017, at 21:18, Kevin Lundberg via swift-corelibs-dev 
>  wrote:
> 
> Thank you! I found this shortly before your message, and I’m working on that 
> right now in my project (and it is definitely not a simple copy paste but so 
> far it seems manageable).
> --
> Kevin Lundberg
> 
> 
> 
>> On Nov 16, 2017, at 4:12 PM, Ian Partridge  wrote:
>> 
>> Hi Kevin,
>> 
>> It's unintentional, in the sense that noone has done the work yet to
>> implement the PropertyListDecoder in corelibs-foundation.
>> 
>> However, the Darwin implementation is actually open source - see
>> https://github.com/apple/swift/blob/master/stdlib/public/SDK/Foundation/PlistEncoder.swift
>> - so we should be able to reuse that code. It might not be a straight
>> copy and paste, but the bulk of the work is ready and done...
>> 
>> PRs welcome!
>> 
>> Thanks,
>> Ian
>> 
>> On 16 November 2017 at 20:54, Kevin Lundberg via swift-corelibs-dev
>>  wrote:
>>> I’m trying to port some mac/iOS swift code over to also compile and run on 
>>> linux. However one of the files I’m working with references 
>>> PropertyListDecoder in order to decode some propertylist data we have in 
>>> our library, and it’s failing to compile since PropertyListDecoder doesn’t 
>>> appear to be implemented in the corelibs-foundation project. Is this an 
>>> oversight, or intentional? Are there any workarounds I can do (short of 
>>> re-encoding our data in JSON which i’d prefer not to do) to get access to 
>>> property list decoding on linux?
>>> 
>>> Thanks!
>>> 
>>> --
>>> Kevin Lundberg
>>> 
>>> 
>>> 
>>> ___
>>> swift-corelibs-dev mailing list
>>> [email protected]
>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>> 
>> 
>> 
>> -- 
>> Ian Partridge
> 
> ___
> swift-corelibs-dev mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev