Re: [swift-corelibs-dev] NSCoding methods

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

Re: [swift-corelibs-dev] NSCoding methods

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 presen

Re: [swift-corelibs-dev] NSCoding methods

OK, it is working on Linux (lightly tested). It needs a compiler fix though, see [SR-412]. — 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

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

Re: [swift-corelibs-dev] NSCoding methods

Responses inline: > On Dec 29, 2015, at 5:03 AM, Luke Howard wrote: > > 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 >

Re: [swift-corelibs-dev] NSCoding methods

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

Re: [swift-corelibs-dev] NSCoding methods

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 g

Re: [swift-corelibs-dev] NSCoding methods

https://github.com/lhoward/swift-corelibs-foundation/commit/49164ea312f0515c8a743d9cb322a78e513085f5 — 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

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. > On Dec 28, 2015, at 3:52 PM, Luke Howard wrote: > > NSConcreteValue is in the current nscoding branch

Re: [swift-corelibs-dev] NSCoding methods

NSConcreteValue is in the current nscoding branch BTW, it works for decoding (non-special types, special is todo). — 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

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

Re: [swift-corelibs-dev] NSCoding methods

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

Re: [swift-corelibs-dev] NSCoding methods

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

Re: [swift-corelibs-dev] NSCoding methods

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

Re: [swift-corelibs-dev] NSCoding methods

Responses inline; > On Dec 28, 2015, at 5:01 AM, Luke Howard via swift-corelibs-dev > wrote: > > >> 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?

Re: [swift-corelibs-dev] NSCoding methods

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

Re: [swift-corelibs-dev] NSCoding methods

> 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

Re: [swift-corelibs-dev] NSCoding methods

Yea that seems to work on linux just fine. I made some more linux portability corrections and it is now buildable on ubuntu 14. > On Dec 26, 2015, at 8:15 PM, Luke Howard wrote: > > >> On 27 Dec 2015, at 3:09 PM, Philippe Hausler wrote: >> >> So a few results so far from the linux side: I ra

Re: [swift-corelibs-dev] NSCoding methods

> 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

Re: [swift-corelibs-dev] NSCoding methods

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. > On Dec 26, 2015, at 7:29 PM, Philippe H

Re: [swift-corelibs-dev] NSCoding methods

I think what I might do to help get this ball rolling is actually create a branch on the official repo; That way I can kick off CI etc on it. > On Dec 26, 2015, at 7:09 PM, Luke Howard wrote: > > >> On 27 Dec 2015, at 1:54 PM, Philippe Hausler wrote: >> >> It might be good for review side of

Re: [swift-corelibs-dev] NSCoding methods

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

Re: [swift-corelibs-dev] NSCoding methods

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

Re: [swift-corelibs-dev] NSCoding methods

> On Dec 26, 2015, at 3:33 PM, Luke Howard wrote: > > >> 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 te

Re: [swift-corelibs-dev] NSCoding methods

> 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:) imp

Re: [swift-corelibs-dev] NSCoding methods

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

Re: [swift-corelibs-dev] NSCoding methods

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 NSMut

Re: [swift-corelibs-dev] NSCoding methods

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 bei

Re: [swift-corelibs-dev] NSCoding methods

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 an

Re: [swift-corelibs-dev] NSCoding methods

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 rename

Re: [swift-corelibs-dev] NSCoding methods

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). — Luk

Re: [swift-corelibs-dev] NSCoding methods

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

Re: [swift-corelibs-dev] NSCoding methods

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 l

Re: [swift-corelibs-dev] NSCoding methods

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 p

Re: [swift-corelibs-dev] NSCoding methods

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 p

Re: [swift-corelibs-dev] NSCoding methods

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 ini

Re: [swift-corelibs-dev] NSCoding methods

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

Re: [swift-corelibs-dev] NSCoding methods

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

Re: [swift-corelibs-dev] NSCoding methods

> 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

Re: [swift-corelibs-dev] NSCoding methods

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

Re: [swift-corelibs-dev] NSCoding methods

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 i

Re: [swift-corelibs-dev] NSCoding methods

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

Re: [swift-corelibs-dev] NSCoding methods

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,

Re: [swift-corelibs-dev] NSCoding methods

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 mail

Re: [swift-corelibs-dev] NSCoding methods

> 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

Re: [swift-corelibs-dev] NSCoding methods

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

Re: [swift-corelibs-dev] NSCoding methods

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.

Re: [swift-corelibs-dev] NSCoding methods

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

Re: [swift-corelibs-dev] NSCoding methods

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

Re: [swift-corelibs-dev] NSCoding methods

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

Re: [swift-corelibs-dev] NSCoding methods

> 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

Re: [swift-corelibs-dev] NSCoding methods

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 spec

Re: [swift-corelibs-dev] NSCoding methods

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

Re: [swift-corelibs-dev] NSCoding methods

Is anyone currently working on this who would like to collaborate? Daniel Strokis Sent from my iPhone > On Dec 12, 2015, at 3:47 PM, Philippe Hausler wrote: > > These were not implemented yet since we did not have a way to actually verify > archives. Part of the goal is to have archives be s

[swift-corelibs-dev] NSCoding methods

Hi All, I’ve noticed that for many classes in Foundation, encodeWithCoder and init?(coder aDecoder: NSCoder) call NSUnimplemented. Are these methods that just haven’t been implemented yet, or are we not interested in implementing these moving forward? Apologies if this has already been discuss