Re: [swift-corelibs-dev] Internal Tests

[Pushkar N Kulkarni via swift-corelibs-dev]

@testable doesn't work with Foundation. I get this build error:TestFoundation/TestNSURLSession.swift:17:22: error: module 'Foundation' was not compiled for testing    @testable import FoundationIs there an equivalent for Xcode's "Enable Testability" on Linux?Pushkar N Kulkarni,
IBM RuntimesSimplicity is prerequisite for reliability - Edsger W. Dijkstra
-swift-corelibs-dev-boun...@swift.org wrote: -To: Robert Stephen Thompson From: Tony Parker via swift-corelibs-dev Sent by: swift-corelibs-dev-boun...@swift.orgDate: 03/15/2016 08:42PMCc: Swift corelibs dev Subject: Re: [swift-corelibs-dev] Internal TestsUsing @testable makes sense to me. Let's try it out. - TonyOn 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 ThompsonSoftware EngineerWillowTree, Inc.®willowtreeapps.comOn Mar 15, 2016, at 8:02 AM, Daniel Eggert via swift-corelibs-dev  wrote:Is it ok to use    @testable import SwiftFoundationin 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 listswift-corelibs-dev@swift.orghttps://lists.swift.org/mailman/listinfo/swift-corelibs-dev___swift-corelibs-dev mailing listswift-corelibs-dev@swift.orghttps://lists.swift.org/mailman/listinfo/swift-corelibs-dev___swift-corelibs-dev mailing listswift-corelibs-dev@swift.orghttps://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]

Hm, that’s too bad. Do we just need to add a flag to Foundation’s build script?

- Tony

> On Jul 8, 2016, at 12:26 AM, Pushkar N Kulkarni  wrote:
> 
> @testable doesn't work with Foundation. I get this build error:
> 
> TestFoundation/TestNSURLSession.swift:17:22: error: module 'Foundation' was 
> not compiled for testing
> 
> @testable import Foundation
> 
> 
> 
> 
> 
> Is there an equivalent for Xcode's "Enable Testability" on Linux?
> 
> Pushkar N Kulkarni,
> IBM Runtimes
> 
> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
> 
> 
> 
> -swift-corelibs-dev-boun...@swift.org 
>  wrote: -
> To: Robert Stephen Thompson  >
> From: Tony Parker via swift-corelibs-dev 
> Sent by: swift-corelibs-dev-boun...@swift.org 
> 
> Date: 03/15/2016 08:42PM
> Cc: Swift corelibs dev  >
> Subject: Re: [swift-corelibs-dev] Internal Tests
> 
> 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 
> mailto:swift-corelibs-dev@swift.org>> 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 
>>> mailto:swift-corelibs-dev@swift.org>> 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 
> 
> 

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

[swift-corelibs-dev] Debugging Assistance

[Lau Bao via swift-corelibs-dev]

Hi everyone ,

I am new the the mailing list and am trying to figure out a optimal work flow.

I am currently making a change in the stdlib and building the tool
chain through the (swift/utils/build-toolchain) and debugging after i
install the tool chain.

I was wondering if there was a way I can debug maybe from the command
line lldb or IDE, set break points etc for dev and test cycles. I have
looked at the current documentation but it does not have any
instructions. I am new to command line debugging and any help to get
me started is much appreciate.

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

[swift-corelibs-dev] Swift DispatchSource not working

[Darren Mo via swift-corelibs-dev]

I am trying to catch SIGWINCH (terminal window size changed) in Swift 3 (Xcode 
8 beta 2). The following code should exit with a status of 1 when it receives 
SIGWINCH. But it never exits.

```swift
// compile with `xcrun -sdk macosx swiftc sigwinch.swift`

import Darwin
import Dispatch

let source = DispatchSource.signal(signal: SIGWINCH, queue: DispatchQueue.main)
source.setEventHandler {
   exit(1)
}
source.resume()

dispatchMain()
```

The equivalent Objective-C code works as expected.

```objc
// compile with `xcrun -sdk macosx clang sigwinch.m`

#import 
#import 
#import 

int main() {
   dispatch_source_t source = 
dispatch_source_create(DISPATCH_SOURCE_TYPE_SIGNAL,
 SIGWINCH,
 0,
 dispatch_get_main_queue());
   dispatch_source_set_event_handler(source, ^{
  exit(1);
   });
   dispatch_resume(source);

   dispatch_main();
}
```

What am I doing wrong?___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Swift DispatchSource not working

[Pierre Habouzit via swift-corelibs-dev]

the bug is known and will be fixed in Seed 3 (?).
signal based sources are mapped to TYPE_READ by mistake in the overlay.

Matt will confirm.


-Pierre

> On Jul 7, 2016, at 7:13 PM, Darren Mo via swift-corelibs-dev 
>  wrote:
> 
> I am trying to catch SIGWINCH (terminal window size changed) in Swift 3 
> (Xcode 8 beta 2). The following code should exit with a status of 1 when it 
> receives SIGWINCH. But it never exits.
> 
> ```swift
> // compile with `xcrun -sdk macosx swiftc sigwinch.swift`
> 
> import Darwin
> import Dispatch
> 
> let source = DispatchSource.signal(signal: SIGWINCH, queue: 
> DispatchQueue.main)
> source.setEventHandler {
>exit(1)
> }
> source.resume()
> 
> dispatchMain()
> ```
> 
> The equivalent Objective-C code works as expected.
> 
> ```objc
> // compile with `xcrun -sdk macosx clang sigwinch.m`
> 
> #import 
> #import 
> #import 
> 
> int main() {
>dispatch_source_t source = 
> dispatch_source_create(DISPATCH_SOURCE_TYPE_SIGNAL,
>  SIGWINCH,
>  0,
>  
> dispatch_get_main_queue());
>dispatch_source_set_event_handler(source, ^{
>   exit(1);
>});
>dispatch_resume(source);
> 
>dispatch_main();
> }
> ```
> 
> What am I doing wrong?
> ___
> 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