date:20151223

Re: [swift-corelibs-dev] Upcoming holiday schedule

2015-12-23 Thread Tom Jowett via swift-corelibs-dev

Hi guys - unsure if it's helpful at your end but I rebased (almost) all of
the open PR's as of this morning on the current HEAD of master (5435ec4),
removed any of the wrong way merges, cleaned up the conflicts and pushed
them to my fork.  They're all available here:
https://github.com/tomj/swift-corelibs-foundation/branches/all - I avoided
1 or 2 as they were heavy on the conflicts and I thought I'd their authors
would have a better idea on resolving those issues.

Let me know if there's anything I can do to help get these into the
mainline to make it easier for you all.

Cheers,
Tom


> Message: 18
> Date: Fri, 18 Dec 2015 08:21:44 -0800
> From: Mike Ferris 
> To: Philippe Hausler 
> Cc: Swift Core Libs 
> Subject: Re: [swift-corelibs-dev] Upcoming holiday schedule
> Message-ID: 
> Content-Type: text/plain; charset="utf-8"
> I will also be out starting tomorrow through the end of the month which
> means XCTest will get little coverage during that time.
> Mike
> > On Dec 17, 2015, at 9:18 AM, Philippe Hausler via swift-corelibs-dev <
> swift-corelibs-dev@swift.org> wrote:
> >
> > I will probably be around a bit more than Tony over the break; I will
> try to keep up with the pull requests.
> >
> > There are a few things that I think will speed up the process so that we
> can keep things running well:
> >
> > Discrete commits that implement a specific thing; reviewing two
> different spots sometimes is a bit hard to follow it all.
> > Review feedback from the community helps a ton
> > Rebasing commits from master so that there are no merge conflicts makes
> my job easier.
> > Unit tests are awesome!
> >
> > These are rules of thumb that actually can apply easily beyond the break.
> >
> >> On Dec 17, 2015, at 9:11 AM, Tony Parker via swift-corelibs-dev <
> swift-corelibs-dev@swift.org > wrote:
> >>
> >> Indeed! I hope the mismatch doesn’t cause us to fall too far behind. ;)
> >>
> >> - Tony
> >>
> >>> On Dec 17, 2015, at 9:10 AM, Brian Gesiak   > wrote:
> >>>
> >>> Thanks for the head's up! Conversely, I imagine that for many people,
> holidays from work are precisely the time to contribute! :)
> >>>
> >>> - Brian Gesiak
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Thu, Dec 17, 2015 at 9:03 AM -0800, "Tony Parker via
> swift-corelibs-dev"  swift-corelibs-dev@swift.org>> wrote:
> >>>
> >>> Hello fellow contributors,
> >>>
> >>> As you are aware, we are fast approaching the year-end holiday season.
> Here at Apple, many of us are taking some time off starting next week
> through the new year. As a result, it is likely that some pull requests
> will take more time than expected to review and merge. Even if some of us
> are on vacation, this is a great opportunity for anyone to jump in and help
> review PRs!
> >>>
> >>> Thanks and happy new year,
> >>> - Tony
> >>>
> >>>
> >>> ___
> >>> swift-corelibs-dev mailing list
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Upcoming holiday schedule

2015-12-23 Thread Philippe Hausler via swift-corelibs-dev

Thanks for the work on this, I will take a look at them later today. Part of 
the hold up on some of the pull requests are that we still have a few compiler 
crashers lurking around and there are a few pr’s that need a bit more work. I 
am leaving XCTest to that team unless it is a critical issue and causing CI 
failure.

> On Dec 23, 2015, at 1:21 AM, Tom Jowett via swift-corelibs-dev 
>  wrote:
> 
> Hi guys - unsure if it's helpful at your end but I rebased (almost) all of 
> the open PR's as of this morning on the current HEAD of master (5435ec4), 
> removed any of the wrong way merges, cleaned up the conflicts and pushed them 
> to my fork.  They're all available here: 
> https://github.com/tomj/swift-corelibs-foundation/branches/all 
>  - I avoided 
> 1 or 2 as they were heavy on the conflicts and I thought I'd their authors 
> would have a better idea on resolving those issues.
> 
> Let me know if there's anything I can do to help get these into the mainline 
> to make it easier for you all.
> 
> Cheers,
> Tom
>  
> Message: 18
> Date: Fri, 18 Dec 2015 08:21:44 -0800
> From: Mike Ferris mailto:mfer...@apple.com>>
> To: Philippe Hausler mailto:phaus...@apple.com>>
> Cc: Swift Core Libs  >
> Subject: Re: [swift-corelibs-dev] Upcoming holiday schedule
> Message-ID:  >
> Content-Type: text/plain; charset="utf-8"
> I will also be out starting tomorrow through the end of the month which means 
> XCTest will get little coverage during that time.
> Mike
> > On Dec 17, 2015, at 9:18 AM, Philippe Hausler via swift-corelibs-dev 
> > mailto:swift-corelibs-dev@swift.org>> wrote:
> >
> > I will probably be around a bit more than Tony over the break; I will try 
> > to keep up with the pull requests.
> >
> > There are a few things that I think will speed up the process so that we 
> > can keep things running well:
> >
> > Discrete commits that implement a specific thing; reviewing two different 
> > spots sometimes is a bit hard to follow it all.
> > Review feedback from the community helps a ton
> > Rebasing commits from master so that there are no merge conflicts makes my 
> > job easier.
> > Unit tests are awesome!
> >
> > These are rules of thumb that actually can apply easily beyond the break.
> >
> >> On Dec 17, 2015, at 9:11 AM, Tony Parker via swift-corelibs-dev 
> >> mailto:swift-corelibs-dev@swift.org> 
> >>  >> >> wrote:
> >>
> >> Indeed! I hope the mismatch doesn’t cause us to fall too far behind. ;)
> >>
> >> - Tony
> >>
> >>> On Dec 17, 2015, at 9:10 AM, Brian Gesiak  >>>   >>> >> wrote:
> >>>
> >>> Thanks for the head's up! Conversely, I imagine that for many people, 
> >>> holidays from work are precisely the time to contribute! :)
> >>>
> >>> - Brian Gesiak
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Thu, Dec 17, 2015 at 9:03 AM -0800, "Tony Parker via 
> >>> swift-corelibs-dev"  >>>  
> >>>  >>> >> wrote:
> >>>
> >>> Hello fellow contributors,
> >>>
> >>> As you are aware, we are fast approaching the year-end holiday season. 
> >>> Here at Apple, many of us are taking some time off starting next week 
> >>> through the new year. As a result, it is likely that some pull requests 
> >>> will take more time than expected to review and merge. Even if some of us 
> >>> are on vacation, this is a great opportunity for anyone to jump in and 
> >>> help review PRs!
> >>>
> >>> Thanks and happy new year,
> >>> - Tony
> >>>
> >>>
> >>> ___
> >>> swift-corelibs-dev mailing list
>  ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

Re: [swift-corelibs-dev] NSCoding methods

2015-12-23 Thread Jordan Rose via swift-corelibs-dev

No, we cannot encode things "non-mangled but with the namespace". For any type 
other than top-level non-generic class types, using a non-mangled name is not 
unique. The only correct answer for arbitrary classes is to use mangled names, 
or something that maps one-to-one with mangled names.

Now, Foundation classes are not arbitrary classes, but then I don't see why 
we'd need to use mangled names for those. We can just use the plain old 
Objective-C names that the OS X classes use today.

Jordan

> On Dec 22, 2015, at 10:16, Philippe Hausler via swift-corelibs-dev 
>  wrote:
> 
> To clarify the goals: I think it is reasonable for us to have a goal to be 
> able to encode/decode archives from foreign targets; e.g. linux encodes an 
> archive and mac os x decodes or iOS encodes and linux decodes. This will 
> allow for server architecture to transmit binary archives across the wire. 
> This will mean that we will want to have the encoded class names from the 
> application scope to be encoded as the non mangled name but with the 
> namespace. However this presents a problem; Foundation will have a namespace 
> which will need to be inferred both for encoding and decoding. Thankfully 
> there may be a reasonable way to approach this;
> 
> public class func classNameForClass(cls: AnyClass) -> String?
> public class func setClassName(codedName: String?, forClass cls: AnyClass)
> 
> These methods can be used to allow for translation of classes by registering 
> the appropriate classes for a “shortened” name that drops the 
> Foundation/SwiftFoundation namespace prefix during encoding.
> 
>> On Dec 22, 2015, at 2:45 AM, Luke Howard via swift-corelibs-dev 
>>  wrote:
>> 
>> 
>>> On 22 Dec 2015, at 5:50 AM, Jordan Rose  wrote:
>>> 
>>> IMHO on Linux NSKeyedArchiver should always use mangled names. If we want 
>>> cross-platform archives, we should set up standard substitutions, but given 
>>> that Swift classes exposed to Objective-C are archived with their full 
>>> names it doesn't make sense to use "half the name" in the archive.
>> 
>> You mean namespaced but unmangled yes? If so I agree.
>> 
>> BTW I found a couple of small CF nits:
>> 
>> * in CFDictionaryGetKeysAndValues(), keybuf and valuebuf are transposed in 
>> the call to CF_SWIFT_FUNCDISPATCHV(NSDictionary.getObjects())
>> 
>> * _CFSwiftDictionaryGetKeysAndValues() does not handle keybuf or valbuf 
>> being NULL (either of which are valid when calling 
>> CFDictionaryGetKeysAndValues())
>> 
> 
> This is a bit un-related to NSCoding and the transposition is probably a 
> mistake if it is inverted (the CF method should be reversed from the NS 
> method to mimic the objc counterpart)
> 
>> — Luke
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>> 
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
> 
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

2015-12-23 Thread Philippe Hausler via swift-corelibs-dev

The archiving format encodes the names of the classes in the archive itself. 
Here are a few code examples and a quasi readable output from them:

let uuid = NSUUID()
let data = NSKeyedArchiver.archivedDataWithRootObject(uuid)
let archive = try! NSPropertyListSerialization.propertyListWithData(data, 
options: [], format: nil)
print(archive)

prints the following:

{
"$archiver" = NSKeyedArchiver;
"$objects" = (
"$null",
{
"$class" = "{value 
= 2}";
"NS.uuidbytes" = <797639fe dad74b14 902afab3 c490448b>;
},
{
"$classes" = (
NSUUID,
NSObject
);
"$classname" = NSUUID;
}
);
"$top" = {
root = "{value = 1}";
};
"$version" = 10;
}

Note the $classes and $classname objects; which are what tell the internal 
implementation of NSKeyedUnarchiver what to construct; moreover you can create 
your own classes..

// I don’t really think this is a good naming for an application’s class but 
hey it might happen...
class NSUUID : NSObject, NSCoding {
let uuid: Foundation.NSUUID
required init?(coder aDecoder: NSCoder) {
uuid = aDecoder.decodeObjectForKey("my.uuid") as! Foundation.NSUUID
}
override init() {
uuid = Foundation.NSUUID()
}
func encodeWithCoder(aCoder: NSCoder) {
aCoder.encodeObject(uuid, forKey: "my.uuid")
}
}

let uuid = NSUUID()
let data = NSKeyedArchiver.archivedDataWithRootObject(uuid)
let archive = try! NSPropertyListSerialization.propertyListWithData(data, 
options: [], format: nil)
print(archive)

prints the following:

{
"$archiver" = NSKeyedArchiver;
"$objects" = (
"$null",
{
"$class" = "{value 
= 4}";
"my.uuid" = "{value = 2}";
},
{
"$class" = "{value 
= 3}";
"NS.uuidbytes" = <546e5b5e 15c244a1 aa96eb90 30c3f7f6>;
},
{
"$classes" = (
NSUUID,
NSObject
);
"$classname" = NSUUID;
},
{
"$classes" = (
"Archiver.NSUUID",
NSObject
);
"$classname" = "Archiver.NSUUID";
}
);
"$top" = {
root = "{value = 1}";
};
"$version" = 10;
}

Granted this is a questionable name for a class but it illustrates which class 
names are encoded where and how they should be interpreted in the pre-existing 
archive format; which we will have to figure out some sensible way of inflating 
and deflating to/from disk/network etc.

> On Dec 23, 2015, at 2:37 PM, Jordan Rose  wrote:
> 
> No, we cannot encode things "non-mangled but with the namespace". For any 
> type other than top-level non-generic class types, using a non-mangled name 
> is not unique. The only correct answer for arbitrary classes is to use 
> mangled names, or something that maps one-to-one with mangled names.
> 
> Now, Foundation classes are not arbitrary classes, but then I don't see why 
> we'd need to use mangled names for those. We can just use the plain old 
> Objective-C names that the OS X classes use today.
> 
> Jordan
> 
>> On Dec 22, 2015, at 10:16, Philippe Hausler via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> To clarify the goals: I think it is reasonable for us to have a goal to be 
>> able to encode/decode archives from foreign targets; e.g. linux encodes an 
>> archive and mac os x decodes or iOS encodes and linux decodes. This will 
>> allow for server architecture to transmit binary archives across the wire. 
>> This will mean that we will want to have the encoded class names from the 
>> application scope to be encoded as the non mangled name but with the 
>> namespace. However this presents a problem; Foundation will have a namespace 
>> which will need to be inferred both for encoding and decoding. Thankfully 
>> there may be a reasonable way to approach this;
>> 
>> public class func classNameForClass(cls: AnyClass) -> String?
>> public class func setClassName(codedName: String?, forClass cls: AnyClass)
>> 
>> These methods can be used to allow for translation of classes by registering 
>> the appropriate classes for a “shortened” name that drops the 
>> Foundation/SwiftFoundation namespace prefix during encoding.
>> 
>>> On Dec 22, 2015, at 2:45 AM, Luke Howard via swift-corelibs-dev 
>>> mailto:swift-corelibs-dev@swift.org>> wrote:
>>> 
>>> 
 On 22 Dec 2015, at 5:50 AM, Jordan Rose >>> > wrote:

 IMHO on Linux NSKeyedArchiver should always use mangled names. If we want 
 cross-platform archives, we should set up standard substitutions, but 
 given that Swift classes exposed to Objective-C are archived with their 
 full names it doesn't make sense to use "half t

Re: [swift-corelibs-dev] NSCoding methods

2015-12-23 Thread Jordan Rose via swift-corelibs-dev

Here's another example on OS X:

import Foundation

class Outer {
class Inner : NSObject, NSCoding {
let uuid: Foundation.NSUUID
required init?(coder aDecoder: NSCoder) {
uuid = aDecoder.decodeObjectForKey("my.uuid") as! Foundation.NSUUID
}
override init() {
uuid = Foundation.NSUUID()
}
func encodeWithCoder(aCoder: NSCoder) {
aCoder.encodeObject(uuid, forKey: "my.uuid")
}
}
}

NSKeyedArchiver.archiveRootObject(Outer.Inner(), toFile: 
"/Users/jrose/Desktop/test-archive")


Which results in this archive:

{
  "$version" => 10
  "$objects" => [
0 => "$null"
1 => {
  "my.uuid" => {value = 
2}
  "$class" => {value = 
4}
}
2 => {
  "NS.uuidbytes" => <67f0b08b c8274f8c b0c78d90 bd4627dc>
  "$class" => {value = 
3}
}
3 => {
  "$classname" => "NSUUID"
  "$classes" => [
0 => "NSUUID"
1 => "NSObject"
  ]
}
4 => {
  "$classname" => "_TtCC4main5Outer5Inner"
  "$classes" => [
0 => "_TtCC4main5Outer5Inner"
1 => "NSObject"
  ]
}
  ]
  "$archiver" => "NSKeyedArchiver"
  "$top" => {
"root" => {value = 1}
  }
}

NSStringFromClass makes pretty names when they fall into the "simple" category, 
but that's not an arbitrarily extensible transformation, and NSCoding shouldn't 
have to know anything about it.

Jordan

> On Dec 23, 2015, at 14:48, Philippe Hausler  wrote:
> 
> The archiving format encodes the names of the classes in the archive itself. 
> Here are a few code examples and a quasi readable output from them:
> 
> let uuid = NSUUID()
> let data = NSKeyedArchiver.archivedDataWithRootObject(uuid)
> let archive = try! NSPropertyListSerialization.propertyListWithData(data, 
> options: [], format: nil)
> print(archive)
> 
> prints the following:
> 
> {
> "$archiver" = NSKeyedArchiver;
> "$objects" = (
> "$null",
> {
> "$class" = " [0x7fff7ab33bb0]>{value = 2}";
> "NS.uuidbytes" = <797639fe dad74b14 902afab3 c490448b>;
> },
> {
> "$classes" = (
> NSUUID,
> NSObject
> );
> "$classname" = NSUUID;
> }
> );
> "$top" = {
> root = "{value = 1}";
> };
> "$version" = 10;
> }
> 
> Note the $classes and $classname objects; which are what tell the internal 
> implementation of NSKeyedUnarchiver what to construct; moreover you can 
> create your own classes..
> 
> // I don’t really think this is a good naming for an application’s class but 
> hey it might happen...
> class NSUUID : NSObject, NSCoding {
> let uuid: Foundation.NSUUID
> required init?(coder aDecoder: NSCoder) {
> uuid = aDecoder.decodeObjectForKey("my.uuid") as! Foundation.NSUUID
> }
> override init() {
> uuid = Foundation.NSUUID()
> }
> func encodeWithCoder(aCoder: NSCoder) {
> aCoder.encodeObject(uuid, forKey: "my.uuid")
> }
> }
> 
> let uuid = NSUUID()
> let data = NSKeyedArchiver.archivedDataWithRootObject(uuid)
> let archive = try! NSPropertyListSerialization.propertyListWithData(data, 
> options: [], format: nil)
> print(archive)
> 
> prints the following:
> 
> {
> "$archiver" = NSKeyedArchiver;
> "$objects" = (
> "$null",
> {
> "$class" = " [0x7fff7ab33bb0]>{value = 4}";
> "my.uuid" = " [0x7fff7ab33bb0]>{value = 2}";
> },
> {
> "$class" = " [0x7fff7ab33bb0]>{value = 3}";
> "NS.uuidbytes" = <546e5b5e 15c244a1 aa96eb90 30c3f7f6>;
> },
> {
> "$classes" = (
> NSUUID,
> NSObject
> );
> "$classname" = NSUUID;
> },
> {
> "$classes" = (
> "Archiver.NSUUID",
> NSObject
> );
> "$classname" = "Archiver.NSUUID";
> }
> );
> "$top" = {
> root = "{value = 1}";
> };
> "$version" = 10;
> }
> 
> Granted this is a questionable name for a class but it illustrates which 
> class names are encoded where and how they should be interpreted in the 
> pre-existing archive format; which we will have to figure out some sensible 
> way of inflating and deflating to/from disk/network etc.
> 
>> On Dec 23, 2015, at 2:37 PM, Jordan Rose > > wrote:
>> 
>> No, we cannot encode things "non-mangled but with the namespace". For any 
>> type other than top-level non-generic class types, using a non-mangled name 
>> is not unique. The only correct answer for arbitrary classes is to use 
>> mangled names, or something that maps one-to-one with mangled names.
>> 
>> Now, Foundation classes are not arbitrary classes, but then I don't see why 
>> we'd need to use mang

Re: [swift-corelibs-dev] NSCoding methods

2015-12-23 Thread Philippe Hausler via swift-corelibs-dev

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.

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?

> On Dec 23, 2015, at 2:53 PM, Jordan Rose  wrote:
> 
> Here's another example on OS X:
> 
> import Foundation
> 
> class Outer {
> class Inner : NSObject, NSCoding {
> let uuid: Foundation.NSUUID
> required init?(coder aDecoder: NSCoder) {
> uuid = aDecoder.decodeObjectForKey("my.uuid") as! 
> Foundation.NSUUID
> }
> override init() {
> uuid = Foundation.NSUUID()
> }
> func encodeWithCoder(aCoder: NSCoder) {
> aCoder.encodeObject(uuid, forKey: "my.uuid")
> }
> }
> }
> 
> NSKeyedArchiver.archiveRootObject(Outer.Inner(), toFile: 
> "/Users/jrose/Desktop/test-archive")
> 
> 
> Which results in this archive:
> 
> {
>   "$version" => 10
>   "$objects" => [
> 0 => "$null"
> 1 => {
>   "my.uuid" => {value 
> = 2}
>   "$class" => {value 
> = 4}
> }
> 2 => {
>   "NS.uuidbytes" => <67f0b08b c8274f8c b0c78d90 bd4627dc>
>   "$class" => {value 
> = 3}
> }
> 3 => {
>   "$classname" => "NSUUID"
>   "$classes" => [
> 0 => "NSUUID"
> 1 => "NSObject"
>   ]
> }
> 4 => {
>   "$classname" => "_TtCC4main5Outer5Inner"
>   "$classes" => [
> 0 => "_TtCC4main5Outer5Inner"
> 1 => "NSObject"
>   ]
> }
>   ]
>   "$archiver" => "NSKeyedArchiver"
>   "$top" => {
> "root" => {value = 1}
>   }
> }
> 
> NSStringFromClass makes pretty names when they fall into the "simple" 
> category, but that's not an arbitrarily extensible transformation, and 
> NSCoding shouldn't have to know anything about it.
> 
> Jordan
> 
>> On Dec 23, 2015, at 14:48, Philippe Hausler > > wrote:
>> 
>> The archiving format encodes the names of the classes in the archive itself. 
>> Here are a few code examples and a quasi readable output from them:
>> 
>> let uuid = NSUUID()
>> let data = NSKeyedArchiver.archivedDataWithRootObject(uuid)
>> let archive = try! NSPropertyListSerialization.propertyListWithData(data, 
>> options: [], format: nil)
>> print(archive)
>> 
>> prints the following:
>> 
>> {
>> "$archiver" = NSKeyedArchiver;
>> "$objects" = (
>> "$null",
>> {
>> "$class" = "> [0x7fff7ab33bb0]>{value = 2}";
>> "NS.uuidbytes" = <797639fe dad74b14 902afab3 c490448b>;
>> },
>> {
>> "$classes" = (
>> NSUUID,
>> NSObject
>> );
>> "$classname" = NSUUID;
>> }
>> );
>> "$top" = {
>> root = "{value = 
>> 1}";
>> };
>> "$version" = 10;
>> }
>> 
>> Note the $classes and $classname objects; which are what tell the internal 
>> implementation of NSKeyedUnarchiver what to construct; moreover you can 
>> create your own classes..
>> 
>> // I don’t really think this is a good naming for an application’s class but 
>> hey it might happen...
>> class NSUUID : NSObject, NSCoding {
>> let uuid: Foundation.NSUUID
>> required init?(coder aDecoder: NSCoder) {
>> uuid = aDecoder.decodeObjectForKey("my.uuid") as! Foundation.NSUUID
>> }
>> override init() {
>> uuid = Foundation.NSUUID()
>> }
>> func encodeWithCoder(aCoder: NSCoder) {
>> aCoder.encodeObject(uuid, forKey: "my.uuid")
>> }
>> }
>> 
>> let uuid = NSUUID()
>> let data = NSKeyedArchiver.archivedDataWithRootObject(uuid)
>> let archive = try! NSPropertyListSerialization.propertyListWithData(data, 
>> options: [], format: nil)
>> print(archive)
>> 
>> prints the following:
>> 
>> {
>> "$archiver" = NSKeyedArchiver;
>> "$objects" = (
>> "$null",
>> {
>> "$class" = "> [0x7fff7ab33bb0]>{value = 4}";
>> "my.uuid" = "> [0x7fff7ab33bb0]>{value = 2}";
>> },
>> {
>> "$class" = "> [0x7fff7ab33bb0]>{value = 3}";

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
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

2015-12-23 Thread Jordan Rose via swift-corelibs-dev

"We need to get ahold of a class given a name" is definitely a requirement to 
do NSCoding right. I'm not at all convinced dlsym is a valid long-term answer 
for that, though. If you have an 'internal' class, it doesn't (currently) have 
a public symbol that you can use dlsym for.

This sort of goes with the existing problem of static registration: there's no 
pure Swift way to get all subclasses of a class, or to get a class from a name 
for any other reason. That's a general language problem, though, and we should 
discuss it on swift-dev.

Jordan


> On Dec 23, 2015, at 15:12, 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.
> 
> 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?
> 
>> On Dec 23, 2015, at 2:53 PM, Jordan Rose > > wrote:
>> 
>> Here's another example on OS X:
>> 
>> import Foundation
>> 
>> class Outer {
>> class Inner : NSObject, NSCoding {
>> let uuid: Foundation.NSUUID
>> required init?(coder aDecoder: NSCoder) {
>> uuid = aDecoder.decodeObjectForKey("my.uuid") as! 
>> Foundation.NSUUID
>> }
>> override init() {
>> uuid = Foundation.NSUUID()
>> }
>> func encodeWithCoder(aCoder: NSCoder) {
>> aCoder.encodeObject(uuid, forKey: "my.uuid")
>> }
>> }
>> }
>> 
>> NSKeyedArchiver.archiveRootObject(Outer.Inner(), toFile: 
>> "/Users/jrose/Desktop/test-archive")
>> 
>> 
>> Which results in this archive:
>> 
>> {
>>   "$version" => 10
>>   "$objects" => [
>> 0 => "$null"
>> 1 => {
>>   "my.uuid" => > [0x7fff7c5acd80]>{value = 2}
>>   "$class" => {value 
>> = 4}
>> }
>> 2 => {
>>   "NS.uuidbytes" => <67f0b08b c8274f8c b0c78d90 bd4627dc>
>>   "$class" => {value 
>> = 3}
>> }
>> 3 => {
>>   "$classname" => "NSUUID"
>>   "$classes" => [
>> 0 => "NSUUID"
>> 1 => "NSObject"
>>   ]
>> }
>> 4 => {
>>   "$classname" => "_TtCC4main5Outer5Inner"
>>   "$classes" => [
>> 0 => "_TtCC4main5Outer5Inner"
>> 1 => "NSObject"
>>   ]
>> }
>>   ]
>>   "$archiver" => "NSKeyedArchiver"
>>   "$top" => {
>> "root" => {value = 1}
>>   }
>> }
>> 
>> NSStringFromClass makes pretty names when they fall into the "simple" 
>> category, but that's not an arbitrarily extensible transformation, and 
>> NSCoding shouldn't have to know anything about it.
>> 
>> Jordan
>> 
>>> On Dec 23, 2015, at 14:48, Philippe Hausler >> > wrote:
>>> 
>>> The archiving format encodes the names of the classes in the archive 
>>> itself. Here are a few code examples and a quasi readable output from them:
>>> 
>>> let uuid = NSUUID()
>>> let data = NSKeyedArchiver.archivedDataWithRootObject(uuid)
>>> let archive = try! NSPropertyListSerialization.propertyListWithData(data, 
>>> options: [], format: nil)
>>> print(archive)
>>> 
>>> prints the following:
>>> 
>>> {
>>> "$archiver" = NSKeyedArchiver;
>>> "$objects" = (
>>> "$null",
>>> {
>>> "$class" = ">> [0x7fff7ab33bb0]>{value = 2}";
>>> "NS.uuidbytes" = <797639fe dad74b14 902afab3 c490448b>;
>>> },
>>> {
>>> "$classes" = (
>>> NSUUID,
>>> NSObject
>>> );
>>> "$classname" = NSUUID;
>>> }
>>> );
>>> "$top" = {
>>> root = "{value = 
>>> 1}";
>>> };
>>> "$version" = 10;
>>> }
>>> 
>>> Note the $classes and $classname objects; which are what tell the internal 
>>> implementation of NSKeyedUnarchiver what to construct; moreover you can 
>>> create your own classes..
>>> 
>>> // I don’t really think this is a good naming for an application’s class 
>>> but hey it might happen...
>>> class NSUUID : NSObject, NSCoding {
>>> let uuid: Foundation.NSUUID
>>> required init?(coder aDecoder: NSCoder) {
>>> uuid = aDecoder.decodeO

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
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

2015-12-23 Thread Philippe Hausler via swift-corelibs-dev

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

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
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Upcoming holiday schedule

Re: [swift-corelibs-dev] Upcoming holiday schedule

Re: [swift-corelibs-dev] NSCoding methods

Re: [swift-corelibs-dev] NSCoding methods

Re: [swift-corelibs-dev] NSCoding methods

Re: [swift-corelibs-dev] NSCoding methods

Re: [swift-corelibs-dev] NSCoding methods

Re: [swift-corelibs-dev] NSCoding methods

Re: [swift-corelibs-dev] NSCoding methods

Re: [swift-corelibs-dev] NSCoding methods

Re: [swift-corelibs-dev] NSCoding methods

Re: [swift-corelibs-dev] NSCoding methods

Re: [swift-corelibs-dev] NSCoding methods

13 matches

Site Navigation

Mail list logo

Footer information