<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Responses inline:<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 29, 2015, at 5:03 AM, Luke Howard &lt;<a href="mailto:lukeh@padl.com" class="">lukeh@padl.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">OK, so I’ve cleaned up the commit history for the NSCoding branch, you can find it here still:<div class=""><br class=""></div><div class=""><a href="https://github.com/lhoward/swift-corelibs-foundation/tree/lhoward/nscoding" class="">https://github.com/lhoward/swift-corelibs-foundation/tree/lhoward/nscoding</a></div><div class=""><br class=""></div><div class="">I haven’t opened a pull request as I’d like to get it working on Linux first. Having a bit of trouble though. (I’m using Ubuntu 15.10 with the latest snapshot.)</div><div class=""><br class=""></div><div class="">Firstly, build-wise:</div><div class=""><br class=""></div>* Changing anything in Foundation/ seems to trigger a recompile of&nbsp;everything Swift. Is there a way to do correct dependency analysis? My clock is OK.<br class=""></div></div></blockquote><div><br class=""></div><div>Yep; probably should be a “known issue” the ninja script will emit the other swift files as deps since there might be cross file dependencies - it is a bit slow when the compiler is in debug mode</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class="">* swift/utils/build-script with —debug-foundation still seems to build a&nbsp;release version. I worked around by building everything debug, but that takes&nbsp;up a lot of disk space.<br class=""></div></div></blockquote><div><br class=""></div><div>My trick that I do is I will build a release build and then hand edit the `.configuration` file of Foundation to be debug; so that way the next `ninja reconfigure` will reconfig it as debug and give juicy debugging info but the rest of the runtime and compiler is in release mode. (I have been considering adding this as a specialized reconfigure option</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class="">* lldb crashes all the time when printing variables (actually I also see this on OS X as well&nbsp;with the snapshot)</div></div></div></blockquote><div><br class=""></div><div>po or p?</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class="">Related to testing:</div><div class=""><br class=""></div>* Something weird is going on with casting over which completely breaks NSKeyedArchiver. I can reproduce it with the following:<br class=""><br class="">&nbsp; &nbsp; let&nbsp;foo&nbsp;=&nbsp;(NSMutableArray() as? AnyObject) as? NSCoding<br class=""><br class="">which the compiler tells me always succeeds (as I believe it should), but at runtime returns foo==nil. No issue if it is a locally defined class that conforms to NSCoding. It’s failing in&nbsp;_dynamicCastToExistential()’s check for _conformsToProtocols() but I haven’t dug deeper yet.<br class=""><br class="">FYI: my LD_LIBRARY_PATH is pointing to the right libswiftCore/libFoundation. I removed the module maps for Foundation/CoreFoundation from the snapshot directory.<br class=""></div></div></blockquote><div><br class=""></div><div>The removal of the module map is usually only needed when building directly to an installed root. Most of the build process for incremental builds don’t need to have module map removal shenanigans.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class="">* Subclassing NSObject fails outside Foundation (see SR-272) is also an issue but not a blocking one</div><div class=""><br class=""><div class="">— Luke</div></div></div></div></blockquote></div><br class=""></div></body></html>