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

[Mike Ferris via swift-corelibs-dev]

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

[swift-corelibs-dev] NSXMLNode and Friends

[Robert Stephen Thompson via swift-corelibs-dev]

Since I recently did a small implementation of NSXMLNode and NSXMLDocument to 
use in an iOS project, I decided to tackle doing the full-featured one here. 
It’s not that hard, doing it as a wrapper on libxml2, except I’ve run into a 
bit of a snag with making the semantics exactly match Darwin Foundation: you 
can’t return a subclass from init! This really only matters in one place, but 
it matters quite a bit there. The de facto designated initializer for NSXMLNode 
is init(kind: NSXMLNodeKind, options: Int). In pure Swift, this always returns 
an NSXMLNode, not the appropriate subclass! Which, of course, means as? returns 
nil, as! (and unsafeDowncast) crash, etc, when you end up trying to retrieve 
one and treat it as the subclass it’s “supposed” to be. I’m completely stumped 
as to any way around this. It might be that it’s just impossible to match 
Darwin Foundation semantics without a new language feature for this, which 
obviously would have to go through swift-evolution and then actually be 
implemented. Am I correct, or is there something I’m missing? Also, should I go 
ahead and implement the rest of this without the exactly matching semantics 
because something is better than nothing?

Thanks,
Robert Thompson
Software Engineer
WillowTree, Inc.®
willowtreeapps.com
 ___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSXMLNode and Friends

[Tony Parker via swift-corelibs-dev]

Hi Robert,

There actually already is some discussion on the swift-evolution list about a 
language feature to enable factory methods, which would help us to implement 
these kinds of things. It is a common pattern in Foundation to return 
subclasses from initializers (NSNull, NSPredicate are in the same boat, among 
many others), so I’m hoping we can get that one moving along soon. If you can 
find that thread, go ahead and reply to it with additional justification if you 
want.

I think we should try to move forward on this as if we’ll eventually get that 
feature. It’s pretty clear that we need it. We may need to work on other parts 
of the implementation first until we get it.

- Tony

> On Dec 18, 2015, at 9:21 AM, Robert Stephen Thompson via swift-corelibs-dev 
>  wrote:
> 
> Since I recently did a small implementation of NSXMLNode and NSXMLDocument to 
> use in an iOS project, I decided to tackle doing the full-featured one here. 
> It’s not that hard, doing it as a wrapper on libxml2, except I’ve run into a 
> bit of a snag with making the semantics exactly match Darwin Foundation: you 
> can’t return a subclass from init! This really only matters in one place, but 
> it matters quite a bit there. The de facto designated initializer for 
> NSXMLNode is init(kind: NSXMLNodeKind, options: Int). In pure Swift, this 
> always returns an NSXMLNode, not the appropriate subclass! Which, of course, 
> means as? returns nil, as! (and unsafeDowncast) crash, etc, when you end up 
> trying to retrieve one and treat it as the subclass it’s “supposed” to be. 
> I’m completely stumped as to any way around this. It might be that it’s just 
> impossible to match Darwin Foundation semantics without a new language 
> feature for this, which obviously would have to go through swift-evolution 
> and then actually be implemented. Am I correct, or is there something I’m 
> missing? Also, should I go ahead and implement the rest of this without the 
> exactly matching semantics because something is better than nothing?
> 
> Thanks,
> Robert Thompson
> Software Engineer
> WillowTree, Inc.®
> willowtreeapps.com 
>  
> 
> ___
> 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] Recommended posix_spawnattr_t for NSTask's implementation

[Dan Stenmark via swift-corelibs-dev]

I hope to take a crack at implementing some of NSTask this weekend.  What are 
the recommended posix_spawnattr_t flags that should be set?  Do we also want to 
take the opportunity to expose the ability to override some of these flags 
(like POSIX_SPAWN_SETPGROUP) or do we want to avoid tying this with 
posix_spawn() too closely?

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

Re: [swift-corelibs-dev] Recommended posix_spawnattr_t for NSTask's implementation

[Philippe Hausler via swift-corelibs-dev]

I would definitely say that posix_spawn is the correct path to implement this; 
that will keep pretty close to the way the one on darwin works;

Couple of suggestions:

posix_spawnattr_setsigmask should be set to the empty signal set

the attribute flags should probably be POSIX_SPAWN_CLOEXEC_DEFAULT | 
POSIX_SPAWN_SETSIGMASK | POSIX_SPAWN_SETSIGDEF

You can probably skip QoS since it won’t exist on linux.

There may be some issue with not having libdispatch to use for a source to 
watch a DISPATCH_PROC_EXIT but this perhaps could be done via a pthread (not 
certain on exactly how but perhaps it can be done)

It also might be useful in this case to drop down to C similarly as 
CFXMLInterface - but pick your poison on that one.


> On Dec 18, 2015, at 11:08 AM, Dan Stenmark via swift-corelibs-dev 
>  wrote:
> 
> I hope to take a crack at implementing some of NSTask this weekend.  What are 
> the recommended posix_spawnattr_t flags that should be set?  Do we also want 
> to take the opportunity to expose the ability to override some of these flags 
> (like POSIX_SPAWN_SETPGROUP) or do we want to avoid tying this with 
> posix_spawn() too closely?
> 
> Dan
> ___
> 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] Recommended posix_spawnattr_t for NSTask's implementation

[Pierre Habouzit via swift-corelibs-dev]

-Pierre

> On Dec 18, 2015, at 11:14 AM, Philippe Hausler via swift-corelibs-dev 
>  wrote:
> 
> I would definitely say that posix_spawn is the correct path to implement 
> this; that will keep pretty close to the way the one on darwin works;
> 
> Couple of suggestions:
> 
> posix_spawnattr_setsigmask should be set to the empty signal set
> 
> the attribute flags should probably be POSIX_SPAWN_CLOEXEC_DEFAULT | 
> POSIX_SPAWN_SETSIGMASK | POSIX_SPAWN_SETSIGDEF
> 
> You can probably skip QoS since it won’t exist on linux.
> 
> There may be some issue with not having libdispatch to use for a source to 
> watch a DISPATCH_PROC_EXIT but this perhaps could be done via a pthread (not 
> certain on exactly how but perhaps it can be done)

No, it can’t that’s the big problem with posix_spawn() on linux, because the 
new task isn’t a child with this (or maybe it is on linux I don’t know) and 
there is no equivalent to the EVFILT_PROC which is the kevent backend for the 
PROC_EXIT dispatch source thing.

This feature is only available through netlink on linux which is restricted to 
the root user.

It *may* be that posix_spawn()ed things are children on linux and that a 
SIGCHLD source should be used instead, which means that NSTask would have to 
multiplex the SIGCHLD + waitpid() and route them back to the right NSTask().


> It also might be useful in this case to drop down to C similarly as 
> CFXMLInterface - but pick your poison on that one.
> 
> 
>> On Dec 18, 2015, at 11:08 AM, Dan Stenmark via swift-corelibs-dev 
>>  wrote:
>> 
>> I hope to take a crack at implementing some of NSTask this weekend.  What 
>> are the recommended posix_spawnattr_t flags that should be set?  Do we also 
>> want to take the opportunity to expose the ability to override some of these 
>> flags (like POSIX_SPAWN_SETPGROUP) or do we want to avoid tying this with 
>> posix_spawn() too closely?
>> 
>> Dan
>> ___
>> 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] Recommended posix_spawnattr_t for NSTask's implementation

[David Smith via swift-corelibs-dev]

One issue that we ran into in the ObjC NSTask is setting the current working 
directory in the child process. We worked around the lack of an API for that by 
using per-thread working directories, which is kind of awful. I'm not up to 
date on what the best approach to use for this on Linux would be; it sounds 
like clone() can do it, but I don't know if that's exposed at the posix_spawn 
level at all.

David

> On Dec 18, 2015, at 11:08 AM, Dan Stenmark via swift-corelibs-dev 
>  wrote:
> 
> I hope to take a crack at implementing some of NSTask this weekend.  What are 
> the recommended posix_spawnattr_t flags that should be set?  Do we also want 
> to take the opportunity to expose the ability to override some of these flags 
> (like POSIX_SPAWN_SETPGROUP) or do we want to avoid tying this with 
> posix_spawn() too closely?
> 
> Dan
> ___
> 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] Recommended posix_spawnattr_t for NSTask's implementation

[Pierre Habouzit via swift-corelibs-dev]

FWIW Glibc implements posix_spawn on posix platforms in terms of {,v}fork + 
execve.
So that means that SIGCHLD can be used.

I don’t think linux has per-thread wd, since linux has had atcalls for a very 
long time, which makes this system interface not useful and only weird 
(pthread_{,f}chdir).

I don’t think there’s a good way to fix this beside asking for POSIX to have a 
posix_spawnattr_setwd(attr, const char *); or changing it around the spawn, 
which of course, is bad and racy

The other alternative is to use a trampoline execv() when -[NSTask 
currentDirectoryPath] has been set that will just chdir() and exec's again. 
it’s not really pretty but does the job. Given that this should be the 
exception and not the rule, maybe that’s acceptable.


-Pierre

> On Dec 18, 2015, at 11:37 AM, David Smith via swift-corelibs-dev 
>  wrote:
> 
> One issue that we ran into in the ObjC NSTask is setting the current working 
> directory in the child process. We worked around the lack of an API for that 
> by using per-thread working directories, which is kind of awful. I'm not up 
> to date on what the best approach to use for this on Linux would be; it 
> sounds like clone() can do it, but I don't know if that's exposed at the 
> posix_spawn level at all.
> 
>   David
> 
>> On Dec 18, 2015, at 11:08 AM, Dan Stenmark via swift-corelibs-dev 
>>  wrote:
>> 
>> I hope to take a crack at implementing some of NSTask this weekend.  What 
>> are the recommended posix_spawnattr_t flags that should be set?  Do we also 
>> want to take the opportunity to expose the ability to override some of these 
>> flags (like POSIX_SPAWN_SETPGROUP) or do we want to avoid tying this with 
>> posix_spawn() too closely?
>> 
>> Dan
>> ___
>> 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] Recommended posix_spawnattr_t for NSTask's implementation

[Dan Stenmark via swift-corelibs-dev]

I’m assuming that OS X’s method for setting a pthread’s cwd is private API.  
Unless a better way to accomplish the same end-goal is in the works, is there 
any way to expose it?

In regards to Linux, the more I look at this, the less attractive posix_spawn() 
appears as a way of implementing this on that platform.  I’ll likely have a 
better idea how to approach this following some prototyping later tonight, but 
my current line of thinking involves vfork() -> unshare() -> chdir() -> 
execve().

Dan

> On Dec 18, 2015, at 12:39 PM, Pierre Habouzit  wrote:
> 
> FWIW Glibc implements posix_spawn on posix platforms in terms of {,v}fork + 
> execve.
> So that means that SIGCHLD can be used.
> 
> I don’t think linux has per-thread wd, since linux has had atcalls for a very 
> long time, which makes this system interface not useful and only weird 
> (pthread_{,f}chdir).
> 
> I don’t think there’s a good way to fix this beside asking for POSIX to have 
> a posix_spawnattr_setwd(attr, const char *); or changing it around the spawn, 
> which of course, is bad and racy
> 
> The other alternative is to use a trampoline execv() when -[NSTask 
> currentDirectoryPath] has been set that will just chdir() and exec's again. 
> it’s not really pretty but does the job. Given that this should be the 
> exception and not the rule, maybe that’s acceptable.
> 
> 
> -Pierre
> 
>> On Dec 18, 2015, at 11:37 AM, David Smith via swift-corelibs-dev 
>>  wrote:
>> 
>> One issue that we ran into in the ObjC NSTask is setting the current working 
>> directory in the child process. We worked around the lack of an API for that 
>> by using per-thread working directories, which is kind of awful. I'm not up 
>> to date on what the best approach to use for this on Linux would be; it 
>> sounds like clone() can do it, but I don't know if that's exposed at the 
>> posix_spawn level at all.
>> 
>>  David
>> 
>>> On Dec 18, 2015, at 11:08 AM, Dan Stenmark via swift-corelibs-dev 
>>>  wrote:
>>> 
>>> I hope to take a crack at implementing some of NSTask this weekend.  What 
>>> are the recommended posix_spawnattr_t flags that should be set?  Do we also 
>>> want to take the opportunity to expose the ability to override some of 
>>> these flags (like POSIX_SPAWN_SETPGROUP) or do we want to avoid tying this 
>>> with posix_spawn() too closely?
>>> 
>>> Dan
>>> ___
>>> 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] NSXMLNode and Friends

[Robert Stephen Thompson via swift-corelibs-dev]

Ok, sounds good to me. I have quite a bit done at this point, but it’s not 
“pretty enough” for a real PR yet. If people really want to look at the 
ugliness, 
https://github.com/rothomp3/swift-corelibs-foundation/tree/feature/NSXMLDocument
 is where it lives.

Thanks,
Robert
> On Dec 18, 2015, at 1:58 PM, Tony Parker  wrote:
> 
> Hi Robert,
> 
> There actually already is some discussion on the swift-evolution list about a 
> language feature to enable factory methods, which would help us to implement 
> these kinds of things. It is a common pattern in Foundation to return 
> subclasses from initializers (NSNull, NSPredicate are in the same boat, among 
> many others), so I’m hoping we can get that one moving along soon. If you can 
> find that thread, go ahead and reply to it with additional justification if 
> you want.
> 
> I think we should try to move forward on this as if we’ll eventually get that 
> feature. It’s pretty clear that we need it. We may need to work on other 
> parts of the implementation first until we get it.
> 
> - Tony
> 
>> On Dec 18, 2015, at 9:21 AM, Robert Stephen Thompson via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> Since I recently did a small implementation of NSXMLNode and NSXMLDocument 
>> to use in an iOS project, I decided to tackle doing the full-featured one 
>> here. It’s not that hard, doing it as a wrapper on libxml2, except I’ve run 
>> into a bit of a snag with making the semantics exactly match Darwin 
>> Foundation: you can’t return a subclass from init! This really only matters 
>> in one place, but it matters quite a bit there. The de facto designated 
>> initializer for NSXMLNode is init(kind: NSXMLNodeKind, options: Int). In 
>> pure Swift, this always returns an NSXMLNode, not the appropriate subclass! 
>> Which, of course, means as? returns nil, as! (and unsafeDowncast) crash, 
>> etc, when you end up trying to retrieve one and treat it as the subclass 
>> it’s “supposed” to be. I’m completely stumped as to any way around this. It 
>> might be that it’s just impossible to match Darwin Foundation semantics 
>> without a new language feature for this, which obviously would have to go 
>> through swift-evolution and then actually be implemented. Am I correct, or 
>> is there something I’m missing? Also, should I go ahead and implement the 
>> rest of this without the exactly matching semantics because something is 
>> better than nothing?
>> 
>> Thanks,
>> Robert Thompson
>> Software Engineer
>> WillowTree, Inc.®
>> willowtreeapps.com 
>>  
>> 
>> ___
>> 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] NSXMLNode and Friends

[Philippe Hausler via swift-corelibs-dev]

Dealing with the cross platform part of the module map portion may be a bit 
tricky; I had to use some of libxml2 for CFXMLInterface it is effectively a 
simple wrapper around a few xml c calls that are a bit swift-friendlier. 
Perhaps that might make some of that integration easier. However if you do find 
a decent way of dealing with the module map differentials between linux and mac 
os x I would be interested to see if we could improve the state of affairs in 
that bridged portion.

> On Dec 18, 2015, at 2:33 PM, Robert Stephen Thompson via swift-corelibs-dev 
>  wrote:
> 
> Ok, sounds good to me. I have quite a bit done at this point, but it’s not 
> “pretty enough” for a real PR yet. If people really want to look at the 
> ugliness, 
> https://github.com/rothomp3/swift-corelibs-foundation/tree/feature/NSXMLDocument
>  
> 
>  is where it lives.
> 
> Thanks,
> Robert
>> On Dec 18, 2015, at 1:58 PM, Tony Parker > > wrote:
>> 
>> Hi Robert,
>> 
>> There actually already is some discussion on the swift-evolution list about 
>> a language feature to enable factory methods, which would help us to 
>> implement these kinds of things. It is a common pattern in Foundation to 
>> return subclasses from initializers (NSNull, NSPredicate are in the same 
>> boat, among many others), so I’m hoping we can get that one moving along 
>> soon. If you can find that thread, go ahead and reply to it with additional 
>> justification if you want.
>> 
>> I think we should try to move forward on this as if we’ll eventually get 
>> that feature. It’s pretty clear that we need it. We may need to work on 
>> other parts of the implementation first until we get it.
>> 
>> - Tony
>> 
>>> On Dec 18, 2015, at 9:21 AM, Robert Stephen Thompson via swift-corelibs-dev 
>>> mailto:swift-corelibs-dev@swift.org>> wrote:
>>> 
>>> Since I recently did a small implementation of NSXMLNode and NSXMLDocument 
>>> to use in an iOS project, I decided to tackle doing the full-featured one 
>>> here. It’s not that hard, doing it as a wrapper on libxml2, except I’ve run 
>>> into a bit of a snag with making the semantics exactly match Darwin 
>>> Foundation: you can’t return a subclass from init! This really only matters 
>>> in one place, but it matters quite a bit there. The de facto designated 
>>> initializer for NSXMLNode is init(kind: NSXMLNodeKind, options: Int). In 
>>> pure Swift, this always returns an NSXMLNode, not the appropriate subclass! 
>>> Which, of course, means as? returns nil, as! (and unsafeDowncast) crash, 
>>> etc, when you end up trying to retrieve one and treat it as the subclass 
>>> it’s “supposed” to be. I’m completely stumped as to any way around this. It 
>>> might be that it’s just impossible to match Darwin Foundation semantics 
>>> without a new language feature for this, which obviously would have to go 
>>> through swift-evolution and then actually be implemented. Am I correct, or 
>>> is there something I’m missing? Also, should I go ahead and implement the 
>>> rest of this without the exactly matching semantics because something is 
>>> better than nothing?
>>> 
>>> Thanks,
>>> Robert Thompson
>>> Software Engineer
>>> WillowTree, Inc.®
>>> willowtreeapps.com 
>>>  
>>> 
>>> ___
>>> 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

[Daniel Strokis via swift-corelibs-dev]

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 serializable on Darwin 
> platforms and de-serializable on linux (and visa-versa). That way someone 
> could presumably archive objects on an iPhone and send the archive over the 
> wire to a linux machine and that machine would be able to de-serialize it and 
> yield the appropriate structure. This means that we need to make certain 
> while implementing these that they mimic the same coder keys and structural 
> serialization order (when not initing with a keyed archiver). NSCoder itself 
> has a start of an implementation but NSKeyedArchiver has a limitation in that 
> we cannot yet build construction of objects dynamically from their class 
> name. 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.
> 
> It might also be a good start to build a verification NSCoder subclass to 
> verify the order and keys/values for any abstract class. That way we can test 
> and verify the coding/decoding on all platforms.
> 
>> On Dec 12, 2015, at 11:58 AM, Daniel Strokis via swift-corelibs-dev 
>>  wrote:
>> 
>> 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 discussed before 
>> and I’m just out of the loop. 
>> 
>> Thanks, 
>> Daniel Strokis
>> 
>> ___
>> 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

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