Re: [swift-corelibs-dev] KVC dependent classes

[David Hart via swift-corelibs-dev]

Sorry, I said NSProgress but I meant NSPredicate. I personally can't even 
imagine what a alternative API for NSPredicate would look like 樂

> On 15 Mar 2016, at 00:21, Tony Parker  wrote:
> 
> Hi David,
> 
> It’s likely that we’ll have to come up with some alternative API in these 
> cases. For example, in NSProgress I could imagine a callback for progress 
> updates instead of observing the properties. It’s not ideal but I don’t think 
> we want to undertake a reinvention of KVO when we do not have the Objective-C 
> runtime present (so much of it relies on that dynamic behavior).
> 
> - Tony
> 
>> On Mar 14, 2016, at 4:14 PM, David Hart via swift-corelibs-dev 
>>  wrote:
>> 
>> I was looking through Foundation for stuff to do and saw NSProgress, 
>> NSExpression and NSSortDescriptor. They seem to be most reliant on KVC, and 
>> as KVC is not available without the Objective-C runtime, I’m not sure what 
>> those classes are doing here. Are those classes doomed to be dropped? Or is 
>> there another way to implement them?
>> 
>> David.
>> ___
>> 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] NSURLSession & libcurl

[Daniel Eggert via swift-corelibs-dev]

Is it ok for me to split the libcurl specific code inside Foundation into a 
separate file, say NSURLSession+curl.swift ? Or should I try to keep everything 
inside NSURLSession.swift ?

If I go for a separate file, I'd be able to differentiate between internal and 
private for the helpers. I'll end up close to 1000 lines of code for this. 
Having these inside NSURLSession.swift is a bit overwhelming.

/Daniel

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

Re: [swift-corelibs-dev] Internal Tests

[Robert Stephen Thompson via swift-corelibs-dev]

If it doesn’t use it on Linux, it’s because I was mostly running tests in Xcode 
heh, and didn’t end up needing it in the end. On Linux, of course, I think 
you’d want @testable import Foundation. I’m not an Apple guy, though, I just 
happen to be the guy who wrote TestNSXMLDocument.swift! So if there is actually 
a reason not to use it, I’m not aware of it, but don’t necessarily take my word 
for it!

Thanks,
Robert Thompson
Software Engineer
WillowTree, Inc.®
willowtreeapps.com 

> On Mar 15, 2016, at 8:02 AM, Daniel Eggert via swift-corelibs-dev 
>  wrote:
> 
> Is it ok to use
>@testable import SwiftFoundation
> in tests? I'd like to test some internal code.
> 
> TestNSXMLDocument.swift uses this, but not on Linux. What's the reason for 
> this?
> 
> /Daniel
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSURLSession & libcurl

[Philippe Hausler via swift-corelibs-dev]

That seems pretty reasonable to me, I guess the only thing to watch out for is 
private vs internal.

Sent from my iPhone

> On Mar 15, 2016, at 2:44 AM, Daniel Eggert  wrote:
> 
> Is it ok for me to split the libcurl specific code inside Foundation into a 
> separate file, say NSURLSession+curl.swift ? Or should I try to keep 
> everything inside NSURLSession.swift ?
> 
> If I go for a separate file, I'd be able to differentiate between internal 
> and private for the helpers. I'll end up close to 1000 lines of code for 
> this. Having these inside NSURLSession.swift is a bit overwhelming.
> 
> /Daniel
> 
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Wrong type in NSHTTPURLResponse

[Daniel Eggert via swift-corelibs-dev]

On 15 Mar 2016, at 16:16, Daniel Eggert via swift-corelibs-dev 
 wrote:
> 
> The allHeaderFields in
> 
> public class NSHTTPURLResponse : NSURLResponse {
>[...]
>public let allHeaderFields: [NSObject : AnyObject]
> }
> 
> should have been [String : String]
> 
> The initialiser has the correct [String : String] type, though.
> 
> Somehow Apple missed this in their API, too. What's the procedure to get this 
> changed / fixed?
> 
> /Daniel


I've changed it as part of this pull request:

https://github.com/apple/swift-corelibs-foundation/pull/287

I'm happy to change it back if need be.

/Daniel

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

Re: [swift-corelibs-dev] Cannot call CFStreamCreatePairWithSocket on Linux

[Tony Parker via swift-corelibs-dev]

Hi Pushkar,

Yes, this is used by “getStreamsToHostWithName”. I think we’ll have to come up 
with a replacement implementation here, either by starting with the old 
CFNetwork open source code or writing our own.

- Tony

> On Mar 15, 2016, at 8:00 AM, Pushkar N Kulkarni via swift-corelibs-dev 
>  wrote:
> 
> Just to add to that:
> 
> I am wondering if this would hamper the implementation of NSStream, 
> NSInputStream and NSOutputStream for Linux.
> 
> Pushkar N Kulkarni,
> IBM Runtimes
> 
> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
> 
> 
> 
> -Pushkar N Kulkarni/India/IBM wrote: -
> To: swift-corelibs-dev@swift.org 
> From: Pushkar N Kulkarni/India/IBM
> Date: 03/15/2016 08:24PM
> Subject: Cannot call CFStreamCreatePairWithSocket on Linux
> 
> 
> Hello all, 
> 
>  While attempting a simple Swift client-server program on Linux using 
> CFSocket, I tried to create CFReadStream and CFWriteStream instances using 
> CFStreamCreatePairWithSocket(_:_:_:_). The program compiles and links but it 
> crashes with this:
> 
> 2016-03-15 10:30:17.791 Client[21389:5a501740] CoreFoundation: failed to 
> dynamically link symbol _CFSocketStreamCreatePair
> 
> 2016-03-15 10:30:17.791 Client[21389:5a501740] CoreFoundation: failed to 
> dynamically link symbol _CFErrorCreateWithStreamError
> 
> 2016-03-15 10:30:17.791 Client[21389:5a501740] CoreFoundation: failed to 
> dynamically link symbol _CFStreamErrorFromCFError
> 
> 
> 
> 
> 
> I see that these symbols are dynamically linked from CFNetwork which, I 
> guess, doesn't exist on Linux (so there is no lookup for these symbols on 
> Linux). 
> 
> Does this qualify to be a CFStream limitation on Linux?
> 
> Thanks in advance for your time!
> 
> Pushkar N Kulkarni,
> IBM Runtimes
> 
> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
> 
> 
> ___
> 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] Internal Tests

[Tony Parker via swift-corelibs-dev]

Using @testable makes sense to me. Let's try it out. 

- Tony

> On Mar 15, 2016, at 7:54 AM, Robert Stephen Thompson via swift-corelibs-dev 
>  wrote:
> 
> If it doesn’t use it on Linux, it’s because I was mostly running tests in 
> Xcode heh, and didn’t end up needing it in the end. On Linux, of course, I 
> think you’d want @testable import Foundation. I’m not an Apple guy, though, I 
> just happen to be the guy who wrote TestNSXMLDocument.swift! So if there is 
> actually a reason not to use it, I’m not aware of it, but don’t necessarily 
> take my word for it!
> 
> Thanks,
> Robert Thompson
> Software Engineer
> WillowTree, Inc.®
> willowtreeapps.com
> 
>> On Mar 15, 2016, at 8:02 AM, Daniel Eggert via swift-corelibs-dev 
>>  wrote:
>> 
>> Is it ok to use
>>@testable import SwiftFoundation
>> in tests? I'd like to test some internal code.
>> 
>> TestNSXMLDocument.swift uses this, but not on Linux. What's the reason for 
>> this?
>> 
>> /Daniel
>> 
>> ___
>> 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] Building Foundation in Xcode

[Taylor Franklin via swift-corelibs-dev]

Hey Brian,

So I was able to get a toolchain for OSX and everything seemed to work.
But now I'm trying to test my changes on Linux and it seems my changes are
halting the tests when I run ninja test in the Foundation directory. I
began this discussion on a pull request

because I thought this was purely related to the Swift 3 changes, but now
I'm not sure.

Anyway, I try to run the debug tests command that ninja test gives me, but
it says I don't have lldb. I thought I had everything necessary, but I'm
not sure how to get lldb or if it is even necessary. I will note that the
tests work on the master branch of Foundation so it does seem like my
problem, but I'm not sure why the issue is happening. Please view the pull
request I mentioned for a little more detail.

If this is more of a swift-dev issue, I can move the conversation there.


Thanks,
Taylor


On Mon, Mar 14, 2016 at 9:49 AM, Ian Partridge via swift-corelibs-dev <
swift-corelibs-dev@swift.org> wrote:

> Hi David,
>
> You need the latest Foundation from git, I think.  Brian fixed that
> compilation problem here:
>
>
> https://github.com/apple/swift-corelibs-foundation/commit/9fbcf1be1b75d5d9046735f13eddbaef4b3a408a
>
> It would be really nice if the snapshots at
> https://swift.org/download/ could be refreshed!
>
> Thanks,
> Ian
>
> On 14 March 2016 at 07:45, David Hart via swift-corelibs-dev
>  wrote:
> > One step closer :) I built a master version the toolchain, fixed most
> > errors, but left with own a few:
> >
> > Foundation/NSRunLoop.swift:14:43: error: type 'CFRunLoopActivity' has no
> > member 'BeforeTimers'
> > internal let kCFRunLoopBeforeTimers =
> > CFRunLoopActivity.BeforeTimers.rawValue
> >
> > Of course, this is happening because the new version of ClangImporter is
> now
> > importing enum values with lowerCamelCase. It’s beforeTimers, not
> > BeforeTimers. I can fix it, but was wondering if it was in need of
> fixing or
> > if I had built the toolchain with the wrong branch of swift.
> >
> > David.
> >
> > On 14 Mar 2016, at 06:44, Brian Gesiak  wrote:
> >
> > Taylor,
> >
> > Funny you should mention that. The tests take a long time to run, and I
> > don't really mind if a local toolchain I use has one or two failing
> tests.
> > So I delete these two lines before building a toolchain:
> >
> https://github.com/apple/swift/blob/a11e911f662c02c14e28286d76d154370ce5f5e1/utils/build-presets.ini#L711-L712
> >
> > That disables the tests. Your toolchain builds much faster, but beware:
> you
> > may have a bug or two in there! ;)
> >
> > - Brian Gesiak
> >
> >
> > _
> > From: Taylor Franklin 
> > Sent: Monday, March 14, 2016 12:37 AM
> > Subject: Re: [swift-corelibs-dev] Building Foundation in Xcode
> > To: Brian Gesiak 
> > Cc: Pushkar N Kulkarni ,
> > , David Hart 
> >
> >
> > Brian,
> >
> > I have also been having issues, so I tried your suggestions and I cannot
> > even get a toolchain built on the Swift master branch. I also tried the
> > swift-3-api-guidelines branch, assuming that is where the Swift 3 code
> > lives.
> >
> > Anyway, I get the error:
> > Failing Tests (1):
> > Swift :: Driver/filelists.swift
> >
> > Does the build-toolchain script take certain parameters or have other
> > prerequisites?
> > Thanks for any help.
> >
> > - Taylor
> >
> > On Sun, Mar 13, 2016 at 2:34 PM, Brian Gesiak via swift-corelibs-dev
> >  wrote:
> >>
> >> David,
> >>
> >> The repository has been migrated to Swift 3. You'll need a Swift 3
> >> .xctoolchain to build it. There isn't a snapshot available yet, but you
> can
> >> build your own using the script added to Swift in
> >> https://github.com/apple/swift/pull/1630.
> >>
> >> Even using the Swift 3 toolchain, I encountered build errors related to
> >> NSRunLoop. Applying
> >> https://github.com/apple/swift-corelibs-foundation/pull/284 got
> everything
> >> working for me.
> >>
> >> Hope that helps!
> >>
> >> - Brian Gesiak
> >>
> >>
> >>
> >> On Sun, Mar 13, 2016 at 12:31 PM -0700, "David Hart"  >
> >> wrote:
> >>
> >>> Ok, I’m also encountering errors, but many more than Pushkar:
> >>>
> >>> OS: OS X El Capitan
> >>> Xcode: Version 7.3 beta 5 (7D162j)
> >>> Toolchain: Xcode Swift DEVELOPMENT Snapshot 2016-03-01 (a)
> >>>
> >>> And the errors I’m getting seem to come from a mismatch with the
> Standard
> >>> Library:
> >>>
> >>> Foundation/FoundationErrors.swift:10:48: Use of undeclared type
> >>> ‘ErrorProtocol'
> >>> Foundation/NSString.swift:1220:55: Use of undeclared type ‘CVarArg’
> >>> Foundation/NSData.swift:18:38: Use of undeclared type ‘OptionSet’
> >>> Foundation/NSNotification.swift:95:11: Use of undeclared type
> ‘Sequence'
> >>>  ...
> >>>
>