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

> 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

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 searc

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

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

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

> 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

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

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

, 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

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

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

Re: [swift-corelibs-dev] NSCoding methods

? > > 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 li

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

> 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

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

> 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

[swift-corelibs-dev] getCString question

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

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

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

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

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

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

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

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

> 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

> 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

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

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

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

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

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 H

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

> 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

[swift-corelibs-dev] CChar vs Int8

Many Foundation APIs use Int8 instead of CChar when representing C strings, e.g.: var UTF8String: UnsafePointer https://developer.apple.com

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

> 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:swift-corelibs-dev@swift.org>> wrote: >> >> Hi Luke, >> >>> On Ja

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

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 behav

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

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? > > - To

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

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

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

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

[swift-corelibs-dev] Building with Xcode

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

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

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 cap

[swift-corelibs-dev] f8c3fe6c breaks on Darwin

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

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

t != 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 > (b

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

uld 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:

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

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

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

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://githu

[swift-corelibs-dev] encodeEncodable/decodeDecodable

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 F

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

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

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

t; > — 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 > &g

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

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:

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

nning into SR-5938 when trying > to build from master. > >> On 26 Sep 2017, at 09:37, Luke Howard via swift-corelibs-dev >> mailto:swift-corelibs-dev@swift.org>> wrote: >> >> Hi Itai, >> >> Pull request is here >> <https://github.com/ap

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

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