[swift-dev] Making the sign of NaNs unspecified to enable enum layout optimization

2016-10-19 Thread Joe Groff via swift-dev 
I had a discussion with Steve this morning about the potential for enum layout 
optimization with floating-point payloads. One great thing about floating-point 
is that it has NaNs, and lots of them. For the most part, the only significant 
semantic difference among these NaNs is whether they're signaling or not, so 
it's tempting to reclaim some of these representations for other purposes. 
Javascript engines are of course famous for "NaN-encoding" values, representing 
JS numbers as native Doubles and packing pointers to non-number object 
instances into the same representation by using NaN bit patterns. In Swift, we 
could do similar things for enums with floating-point payloads, making 'Float?' 
and 'Double?' take the same amount of space as non-optionals, and automatically 
applying Javascript-style layout optimizations when defining enums with mixed 
float and object payloads. IEEE 754 is ambivalent about the role of NaN 
payloads, and there are libraries that use payloads for interesting diagnostic 
purposes, but the standard declares up front that it "does not interpret the 
sign of a NaN" (section 6.3). Reserving "negative" NaNs with the sign bit set 
as extra inhabitants could let us do enum layout optimization without 
interfering with the ability for libraries to freely use NaN payloads.

However, the way we usually handle enum optimization with extra inhabitants is 
problematic for floats. We normally say that it is undefined behavior for a 
value to have an extra inhabitant representation—a class reference cannot be 
null, a Bool can only be 0 or 1, and so on. With floats, we need to 
interoperate with numerics code not written in Swift, and we want to be able to 
read floating-point data out of memory that may use arbitrary bit patterns. We 
don't want every double-returning C function or load from memory to require a 
check for reserved values afterward. Making it undefined behavior for floats to 
have "extra inhabitant" representations is thus probably not practical.

Instead of saying that extra inhabitants are undefined behavior, we could 
instead continue to allow Floats and Doubles to have arbitrary bit patterns, 
and only check for reserved values at the point we construct an enum that wants 
to use reserved values for layout. If we reserve negative NaNs, then for 
example, constructing a Float? or Double? from a nonoptional value would check 
whether the payload value is NaN and if so, clear the sign bit at that point. 
That way, we don't have any ABI problems with Floats and Doubles from foreign 
sources, but still get the benefits of layout optimization for Swift types. On 
the other hand, this would mean that supposedly-idempotent operations like 
'.some(x)!' lose the sign information for NaNs. Since we wouldn't want to 
prevent the optimizer from folding those kinds of operations away, we could 
define Swift's semantics to say that querying the sign of a NaN value produces 
an unspecified value. This matches the intent of IEEE 754, and shouldn't impact 
most numerics code in practice. If we were interested in pursuing enum layout 
optimization with float payloads, I think this would be the best approach.

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

Re: [swift-dev] copy-on-write proposal

2016-10-19 Thread Andrew Trick via swift-dev 

> On Oct 19, 2016, at 10:13 AM, Dave Abrahams via swift-dev 
>  wrote:
> 
> 
> on Tue Oct 18 2016, Erik Eckstein  > wrote:
> 
>>> On Oct 17, 2016, at 10:21 AM, Dave Abrahams  wrote:
>>> 
>>> 
>>> on Mon Oct 17 2016, Erik Eckstein  wrote:
>>> 
>> 
 On Oct 16, 2016, at 2:05 PM, Dave Abrahams via swift-dev 
  wrote:
 
> on Thu Oct 13 2016, Joe Groff  > wrote:
> 
>>> On Oct 11, 2016, at 4:48 PM, Erik Eckstein via swift-dev 
>>>  wrote:
>>> 
>>> This is a proposal for representing copy-on-write buffers in
>>> SIL. Actually it’s still a draft for a proposal. It also heavily
>>> depends on how we move forward with SIL ownership.
>>> 
>>> If you have any comments, please let me know.
>> 
>> The SIL-level design seems sensible to me at a glance. At the language
>> level, I think it would make more sense to treat this as an attribute
>> on class types rather than on properties in structs using the class. I
>> don't think many people reuse class definitions as both shared
>> reference types and as value type payloads, 
> 
> Foundation does, or would if they could.
> 
>> but beyond that, I think that making it an attribute of classes would
>> put us into a better position to leverage the borrow model to enforce
>> the "mutable-only-when-unique" aspect of COW implementations. John
>> alluded to this in the "SIL address types and borrowing" thread:
>> 
>>> I wonder if it would make more sense to make copy-on-write buffer
>>> references a move-only type, so that as long as you were just
>>> working with the raw reference (as opposed to the CoW aggregate,
>>> which would remain copyable) it wouldn't get implicitly copied
>>> anymore.  You could have mutable and immutable buffer reference
>>> types, both move-only, and there could be a consuming checkUnique
>>> operation on the immutable one that, I dunno, returned an Either of
>>> the mutable and immutable versions.
>>> 
>>> For CoW aggregates, you'd need some @copied attribute on the field
>>> to make sure that the CoW attribute was still copyable.  Within the
>>> implementation of the type, though, you would be projecting out the
>>> reference immediately, and thereafter you'd be certain that you were
>>> borrowing / moving it around as appropriate.
>> 
>> If 'copy-on-write' were a trait on classes, then we could distinguish
>> unique and nonunique references to the class. A unique reference would
>> act like a move-only type to prevent accidental loss of uniqueness. 
> 
> +1
> 
>> We can also allow a copy-on-write class to have "mutating" methods,
>> and only allow mutation on unique references. It seems to me like,
>> exploring this direction, we could also come up with a way for the
>> high-level value-semantics operations on the struct to statically
>> indicate which methods are known to leave the value's buffers in a
>> unique state, or which return values that are uniquely owned, which
>> would give the optimizer more ability to avoid uniqueness checks
>> across calls without relying on inlining and IPO.
> 
> That's pretty cool.  However, I think there's nothing to prevent any
> mutating method from storing a copy of self in a global, so I think we'd
> need some participation from the programmer (either an agreement not to
> do that, or an explicit claim of uniqueness on exit) in order to
> identify operations that create/preserve uniqueness.
 
 If a mutating reference (like self in a mutating method) is move-only
 then you would not be able to “copy” it to a global.
>>> 
>>> Yes, a reference to a move-only type would work for this purpose.
>>> 
>>> 
> On Oct 16, 2016, at 2:01 PM, Dave Abrahams via swift-dev 
>  wrote:
> 
> 
> on Tue Oct 11 2016, Erik Eckstein  wrote:
> 
>> This is a proposal for representing copy-on-write buffers in
>> SIL. Actually it’s still a draft for a proposal. It also heavily
>> depends on how we move forward with SIL ownership.
>> 
>> :orphan:
>> 
>> .. highlight:: sil
>> 
>> ===
>> Copy-On-Write Representation in SIL
>> ===
>> 
>> .. contents::
>> 
>> Overview
>> 
>> 
>> This document proposes:
>> 
>> - An ownership attribute to define copy-on-write (COW) buffers in Swift 
>> data
>> types.
>> 
>> - A representation of COW buffers in SIL so that optimizations can take 
>> benefit
>> of it.
>> 
>> The basic idea is to enable the SIL optimizer to reason about COW data 
>> types
>> in the same way as a

Re: [swift-dev] PR Tests Failing

2016-10-19 Thread Michael Gottesman via swift-dev 
I just talked with Roman. He said that this was due to his commit earlier and 
that we need to do clean builds to work around it.

Perhaps we should clean the workspaces?

Michael

> On Oct 19, 2016, at 2:39 PM, Michael Gottesman via swift-dev 
>  wrote:
> 
> My PR test is failing due to something unrelated:
> 
> https://ci.swift.org/job/swift-PR-osx-smoke-test/2441/console
> 
> Does anyone know what is going on?
> 
> Michael
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

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

[swift-dev] PR Tests Failing

2016-10-19 Thread Michael Gottesman via swift-dev 
My PR test is failing due to something unrelated:

https://ci.swift.org/job/swift-PR-osx-smoke-test/2441/console

Does anyone know what is going on?

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

[swift-dev] imageView does't show the image with Swift 3 and Xcode 8

2016-10-19 Thread Yue Cui via swift-dev 
I recently migrated my app to Swift 3 and Xcode 8.

The imageView didn't show the image if I re-open the app.

I used viewWillAppear() for this function. The code is as below:

let imageUrl: NSURL = NSURL(string: "\(userDefaults.string(forKey:
"avatar_url")!)")!
let imageData:NSData = NSData(contentsOf: imageUrl as URL)!
let logo = UIImage(data: imageData as Data)!
self.logoImage.image = logo

Any thoughts?

Thanks in advance.

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

Re: [swift-dev] smoke test not very smoky?

2016-10-19 Thread mishal_shah via swift-dev 
Yes, I will fix it today by creating new preset for smoke test.

Mishal Shah

> On Oct 19, 2016, at 9:44 AM, Dave Abrahams via swift-dev 
>  wrote:
> 
> 
> on Wed Oct 19 2016, Dave Abrahams  > wrote:
> 
>> It still seems like, for a smoke test, we're doing way too much work.
>> This appears to be much more than what I get from build-script -t when
>> I run tests locally.  Maybe I'm misunderstanding the intended role of
>> our smoke tests, but since nobody is correcting me, I'm betting not.
> 
> 
> Someone wrote to me privately:
> 
>  "buildbot_linux_1404" preset used in Linux smoke test contains
>  "--long-test".
> 
> This seems wrong to me.  Can we fix it?
> 
>> 
>> Anyway, regardless of the explanation, what can be done about this?
>> Between a spurious failure in LLDB and the length of the smoke test it
>> took several hours to be able to merge something that could not
>> possibly break the build, which seems absurd.
>> 
>>> On Oct 18, 2016, at 11:44 PM, mishal_shah  wrote:
>>> 
>>> 
 On Oct 18, 2016, at 8:29 PM, Michael Gottesman  
 wrote:
 
 
> On Oct 18, 2016, at 6:40 PM, Dave Abrahams via swift-dev 
>  wrote:
> 
> 
> I thought the smoke test was supposed to be a fairly quick test
> that just covered the basics, but it seems to be doing plenty of *really
> long* tests, for example:
> https://ci.swift.org/job/swift-PR-Linux-smoke-test/1916/console
> which has already been running for over 30 minutes.  Am I missing
> something?
 
 I think people have over time been adding more to the Linux tests. But I 
 am not in the know. Mishal, do you know whats happening here?
>>> 
>>> This is most likely due to number cores we have for Linux bots, the new 
>>> Linux bots are 12 cores vs 48 cores and we are running multiple executors 
>>> on it. 
>>> 
>>> Old  -  48 cores / 4 executors = 12 cores
>>> New - 12 cores / 2 executors = 6 cores
>>> 
>>> Thanks, 
>>> Mishal Shah
 
 Michael
 
> 
> -- 
> -Dave
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
 
>>> 
>> ___
>> swift-dev mailing list
>> swift-dev@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-dev 
>> 
> 
> -- 
> -Dave
> 
> ___
> swift-dev mailing list
> swift-dev@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-dev 
> 
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] smoke test not very smoky?

2016-10-19 Thread Dave Abrahams via swift-dev 

on Wed Oct 19 2016, Jordan Rose  wrote:

>> On Oct 19, 2016, at 9:44, Dave Abrahams via swift-dev  
>> wrote:
>> 
>> 
>> on Wed Oct 19 2016, Dave Abrahams > > wrote:
>> 
>>> It still seems like, for a smoke test, we're doing way too much work.
>>> This appears to be much more than what I get from build-script -t when
>>> I run tests locally.  Maybe I'm misunderstanding the intended role of
>>> our smoke tests, but since nobody is correcting me, I'm betting not.
>
> Even smoke tests should run the validation tests…

What's the point of distinguishing validation from other tests if even
the smoke tests run them?

>> Someone wrote to me privately:
>> 
>>  "buildbot_linux_1404" preset used in Linux smoke test contains
>>  "--long-test".
>> 
>> This seems wrong to me.  Can we fix it?
>
> …but I could see "long tests" going either way.

Well, what is “smoke” supposed to mean?  If it requires running
validation tests and maybe even long tests, what is the “smoke test”
distinction *for*?

-- 
-Dave

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

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 16.10 (master) #114

2016-10-19 Thread Doug Coleman via swift-dev 
One of the next builds succeeded, so the code is fine.

The problem with just doing a clean build is the job might be available on 
several machines, but only the machine that gets it next will try a clean 
build—the other machines might not get the clean build command.



> On Oct 19, 2016, at 10:05 AM, Roman Levenstein  wrote:
> 
> Hi Doug,
> 
> 
> It could be related to my commit 91f5b9dac1f0be357dd8c93bb449a415e33cc66f.
> 
> Can you try a clean build?  That’s how I got it to pass tests on the bots 
> when I was testing the PR before I merged.
> 
> -Roman
> 
>> On Oct 19, 2016, at 9:59 AM, Doug Coleman > > wrote:
>> 
>> Failing with:
>> 
>> undefined symbol: 
>> _TTSgq5Vs5UInt8___TFs27_allocateUninitializedArrayurFBwTGSax_Bp_ 
>> 
>> 
>> more:
>> + pushd 
>> /home/buildnode/disk1/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift-corelibs-foundation
>> ~/disk1/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift-corelibs-foundation
>>  ~/disk1/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10
>> + /usr/bin/ninja TestFoundation
>> ninja: no work to do.
>> + popd
>> ~/disk1/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10
>> + env 
>> LD_LIBRARY_PATH=//usr//lib/swift/:/home/buildnode/disk1/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/foundation-linux-x86_64/Foundation:/home/buildnode/disk1/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/xctest-linux-x86_64:/home/buildnode/disk1/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/libdispatch-linux-x86_64/src/.libs:
>>  
>> /home/buildnode/disk1/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/foundation-linux-x86_64/TestFoundation/TestFoundation
>> /home/buildnode/disk1/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/foundation-linux-x86_64/TestFoundation/TestFoundation:
>>  symbol lookup error: 
>> /home/buildnode/disk1/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/foundation-linux-x86_64/TestFoundation/TestFoundation:
>>  undefined symbol: 
>> _TTSgq5Vs5UInt8___TFs27_allocateUninitializedArrayurFBwTGSax_Bp_
>> /home/buildnode/disk1/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift/utils/build-script:
>>  fatal error: command terminated with a non-zero exit status 127, aborting
>> /home/buildnode/disk1/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift/utils/build-script:
>>  fatal error: command terminated with a non-zero exit status 1, aborting
>> 
>> 
>> 
>>> On Oct 19, 2016, at 9:53 AM, no-re...@swift.org  
>>> wrote:
>>> 
>>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#114]
>>> 
>>> Build URL:  
>>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/114/ 
>>> 
>>> Project:oss-swift-incremental-RA-linux-ubuntu-16_10
>>> Date of build:  Wed, 19 Oct 2016 09:34:53 -0700
>>> Build duration: 18 min
>>> Tests:
>>> 
>>> Name: Swift(linux-x86_64)
>>> Failed: 0 test(s), Passed: 8442 test(s), Total: 8442 test(s)
>>> Name: Swift-Unit
>>> Failed: 0 test(s), Passed: 299 test(s), Total: 299 test(s)
>>> 
>>> Changes
>>> 
>>> Commit 3778c79dc41ce9867a36a4b1f2d5ccb65a7b39f9 by jordan_rose:
>>> [SDK] Use SwiftPrivate to remove _silgen_name from the AppKit overlay.
>>> 
>>> edit: stdlib/public/SDK/AppKit/AppKit.swift
>>> edit: apinotes/AppKit.apinotes
>>> 
>>> Commit 2e560b03191fa66bc618f4e6ffe4f5580e6445ca by jordan_rose:
>>> [SDK] Use an extra shim header to remove _silgen_name from XCTest.
>>> 
>>> edit: stdlib/public/SDK/XCTest/XCTest.swift
>>> edit: stdlib/public/SDK/XCTest/XCTestCaseAdditions.mm
>>> edit: stdlib/public/SwiftShims/CMakeLists.txt
>>> add: stdlib/public/SwiftShims/XCTestOverlayShims.h
>>> edit: stdlib/public/SwiftShims/module.modulemap
>>> 
>>> Commit 244cf50c0c62e0922cc84f40b822bd3b317d7ce6 by jordan_rose:
>>> [SDK] Use an extra shims header to remove _silgen_name from the os
>>> 
>>> edit: stdlib/public/SDK/os/os_log.swift
>>> edit: stdlib/public/SDK/os/os.mm
>>> edit: stdlib/public/SwiftShims/module.modulemap
>>> add: stdlib/public/SwiftShims/OSOverlayShims.h
>>> edit: stdlib/public/SwiftShims/CMakeLists.txt
>>> 
>>> Commit 7b0b2d6de2555634e67c520e30db4932f7dd5ee3 by jordan_rose:
>>> [SDK] Use perform(_:with:) to remove _silgen_name from GameplayKit.
>>> 
>>> delete: stdlib/public/SDK/GameplayKit/GameplayKit.mm
>>> edit: stdlib/public/SDK/GameplayKit/CMakeLists.txt
>>> edit: stdlib/public/SDK/GameplayKit/GameplayKit.swift
>>> 
>>> Commit c97451f85134ea7f93e2b7dce7a9395bbc3167dd by jordan_rose:
>>> [SDK] Use existing NS_REFINED_FOR_SWIFT to remove _silgen_name from
>>> 
>>> edit: stdlib/public/SDK/SceneKit/SceneKit.swift.gyb
>>> edit: stdlib/public/SDK/SceneKit/CMakeLists.txt
>>> delete: stdlib/public/SDK/SceneKit/Thunks.mm

Re: [swift-dev] smoke test not very smoky?

2016-10-19 Thread Jordan Rose via swift-dev 

> On Oct 19, 2016, at 9:44, Dave Abrahams via swift-dev  
> wrote:
> 
> 
> on Wed Oct 19 2016, Dave Abrahams  > wrote:
> 
>> It still seems like, for a smoke test, we're doing way too much work.
>> This appears to be much more than what I get from build-script -t when
>> I run tests locally.  Maybe I'm misunderstanding the intended role of
>> our smoke tests, but since nobody is correcting me, I'm betting not.

Even smoke tests should run the validation tests…


> Someone wrote to me privately:
> 
>  "buildbot_linux_1404" preset used in Linux smoke test contains
>  "--long-test".
> 
> This seems wrong to me.  Can we fix it?

…but I could see "long tests" going either way.___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 16.10 (master) #114

2016-10-19 Thread Doug Coleman via swift-dev 
Failing with:

undefined symbol: 
_TTSgq5Vs5UInt8___TFs27_allocateUninitializedArrayurFBwTGSax_Bp_ 


more:
+ pushd 
/home/buildnode/disk1/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift-corelibs-foundation
~/disk1/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift-corelibs-foundation
 ~/disk1/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10
+ /usr/bin/ninja TestFoundation
ninja: no work to do.
+ popd
~/disk1/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10
+ env 
LD_LIBRARY_PATH=//usr//lib/swift/:/home/buildnode/disk1/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/foundation-linux-x86_64/Foundation:/home/buildnode/disk1/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/xctest-linux-x86_64:/home/buildnode/disk1/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/libdispatch-linux-x86_64/src/.libs:
 
/home/buildnode/disk1/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/foundation-linux-x86_64/TestFoundation/TestFoundation
/home/buildnode/disk1/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/foundation-linux-x86_64/TestFoundation/TestFoundation:
 symbol lookup error: 
/home/buildnode/disk1/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/foundation-linux-x86_64/TestFoundation/TestFoundation:
 undefined symbol: 
_TTSgq5Vs5UInt8___TFs27_allocateUninitializedArrayurFBwTGSax_Bp_
/home/buildnode/disk1/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift/utils/build-script:
 fatal error: command terminated with a non-zero exit status 127, aborting
/home/buildnode/disk1/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift/utils/build-script:
 fatal error: command terminated with a non-zero exit status 1, aborting



> On Oct 19, 2016, at 9:53 AM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#114]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/114/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-16_10
> Date of build:Wed, 19 Oct 2016 09:34:53 -0700
> Build duration:   18 min
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 0 test(s), Passed: 8442 test(s), Total: 8442 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 299 test(s), Total: 299 test(s)
> 
> Changes
> 
> Commit 3778c79dc41ce9867a36a4b1f2d5ccb65a7b39f9 by jordan_rose:
> [SDK] Use SwiftPrivate to remove _silgen_name from the AppKit overlay.
> 
> edit: stdlib/public/SDK/AppKit/AppKit.swift
> edit: apinotes/AppKit.apinotes
> 
> Commit 2e560b03191fa66bc618f4e6ffe4f5580e6445ca by jordan_rose:
> [SDK] Use an extra shim header to remove _silgen_name from XCTest.
> 
> edit: stdlib/public/SDK/XCTest/XCTest.swift
> edit: stdlib/public/SDK/XCTest/XCTestCaseAdditions.mm
> edit: stdlib/public/SwiftShims/CMakeLists.txt
> add: stdlib/public/SwiftShims/XCTestOverlayShims.h
> edit: stdlib/public/SwiftShims/module.modulemap
> 
> Commit 244cf50c0c62e0922cc84f40b822bd3b317d7ce6 by jordan_rose:
> [SDK] Use an extra shims header to remove _silgen_name from the os
> 
> edit: stdlib/public/SDK/os/os_log.swift
> edit: stdlib/public/SDK/os/os.mm
> edit: stdlib/public/SwiftShims/module.modulemap
> add: stdlib/public/SwiftShims/OSOverlayShims.h
> edit: stdlib/public/SwiftShims/CMakeLists.txt
> 
> Commit 7b0b2d6de2555634e67c520e30db4932f7dd5ee3 by jordan_rose:
> [SDK] Use perform(_:with:) to remove _silgen_name from GameplayKit.
> 
> delete: stdlib/public/SDK/GameplayKit/GameplayKit.mm
> edit: stdlib/public/SDK/GameplayKit/CMakeLists.txt
> edit: stdlib/public/SDK/GameplayKit/GameplayKit.swift
> 
> Commit c97451f85134ea7f93e2b7dce7a9395bbc3167dd by jordan_rose:
> [SDK] Use existing NS_REFINED_FOR_SWIFT to remove _silgen_name from
> 
> edit: stdlib/public/SDK/SceneKit/SceneKit.swift.gyb
> edit: stdlib/public/SDK/SceneKit/CMakeLists.txt
> delete: stdlib/public/SDK/SceneKit/Thunks.mm
> 
> Commit cb59b941359c587de0c279dcf21131c76ade6677 by jordan_rose:
> [SDK] Use an extra shim header to eliminate _silgen_name from
> 
> edit: stdlib/public/SwiftShims/CMakeLists.txt
> edit: stdlib/public/SDK/ObjectiveC/CMakeLists.txt
> delete: stdlib/public/SDK/ObjectiveC/ObjectiveC.mm
> edit: stdlib/public/SwiftShims/module.modulemap
> edit: stdlib/public/SDK/ObjectiveC/ObjectiveC.swift
> add: stdlib/public/SwiftShims/ObjectiveCOverlayShims.h
> 
> Commit 26e24f7beebdbe5aea22107b38189d4e78d62cb0 by jordan_rose:
> [SDK] Use an extra shim header to remove _silgen_name from
> 
> edit: stdlib/public/SDK/SafariServices/CMakeLists.txt
> edit: stdlib/public/SwiftShims/CMakeLists.txt
> edit: stdlib/public/SwiftShims/module.modulemap
> add: stdlib/public/SwiftShims/SafariServicesOverlayShims.h
> edit: stdlib/public/SDK/SafariServices/SafariServices.swift
> delete: stdlib/public/SDK/SafariServices/SafariServices.mm
> 
> Commit

Re: [swift-dev] smoke test not very smoky?

2016-10-19 Thread Dave Abrahams via swift-dev 

on Wed Oct 19 2016, Dave Abrahams  wrote:

> It still seems like, for a smoke test, we're doing way too much work.
> This appears to be much more than what I get from build-script -t when
> I run tests locally.  Maybe I'm misunderstanding the intended role of
> our smoke tests, but since nobody is correcting me, I'm betting not.


Someone wrote to me privately:

  "buildbot_linux_1404" preset used in Linux smoke test contains
  "--long-test".

This seems wrong to me.  Can we fix it?

>
> Anyway, regardless of the explanation, what can be done about this?
> Between a spurious failure in LLDB and the length of the smoke test it
> took several hours to be able to merge something that could not
> possibly break the build, which seems absurd.
>
>> On Oct 18, 2016, at 11:44 PM, mishal_shah  wrote:
>> 
>> 
>>> On Oct 18, 2016, at 8:29 PM, Michael Gottesman  wrote:
>>> 
>>> 
 On Oct 18, 2016, at 6:40 PM, Dave Abrahams via swift-dev 
  wrote:
 
 
 I thought the smoke test was supposed to be a fairly quick test
 that just covered the basics, but it seems to be doing plenty of *really
 long* tests, for example:
 https://ci.swift.org/job/swift-PR-Linux-smoke-test/1916/console
 which has already been running for over 30 minutes.  Am I missing
 something?
>>> 
>>> I think people have over time been adding more to the Linux tests. But I am 
>>> not in the know. Mishal, do you know whats happening here?
>> 
>> This is most likely due to number cores we have for Linux bots, the new 
>> Linux bots are 12 cores vs 48 cores and we are running multiple executors on 
>> it. 
>> 
>> Old  -  48 cores / 4 executors = 12 cores
>> New - 12 cores / 2 executors = 6 cores
>> 
>> Thanks, 
>> Mishal Shah
>>> 
>>> Michael
>>> 
 
 -- 
 -Dave
 ___
 swift-dev mailing list
 swift-dev@swift.org
 https://lists.swift.org/mailman/listinfo/swift-dev
>>> 
>> 
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

-- 
-Dave

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

Re: [swift-dev] smoke test not very smoky?

2016-10-19 Thread Dave Abrahams via swift-dev 
It still seems like, for a smoke test, we're doing way too much work.  This 
appears to be much more than what I get from build-script -t when I run tests 
locally.  Maybe I'm misunderstanding the intended role of our smoke tests, but 
since nobody is correcting me, I'm betting not.

Anyway, regardless of the explanation, what can be done about this?  Between a 
spurious failure in LLDB and the length of the smoke test it took several hours 
to be able to merge something that could not possibly break the build, which 
seems absurd.

Sent from my iPad

> On Oct 18, 2016, at 11:44 PM, mishal_shah  wrote:
> 
> 
>> On Oct 18, 2016, at 8:29 PM, Michael Gottesman  wrote:
>> 
>> 
>>> On Oct 18, 2016, at 6:40 PM, Dave Abrahams via swift-dev 
>>>  wrote:
>>> 
>>> 
>>> I thought the smoke test was supposed to be a fairly quick test
>>> that just covered the basics, but it seems to be doing plenty of *really
>>> long* tests, for example:
>>> https://ci.swift.org/job/swift-PR-Linux-smoke-test/1916/console
>>> which has already been running for over 30 minutes.  Am I missing
>>> something?
>> 
>> I think people have over time been adding more to the Linux tests. But I am 
>> not in the know. Mishal, do you know whats happening here?
> 
> This is most likely due to number cores we have for Linux bots, the new Linux 
> bots are 12 cores vs 48 cores and we are running multiple executors on it. 
> 
> Old  -  48 cores / 4 executors = 12 cores
> New - 12 cores / 2 executors = 6 cores
> 
> Thanks, 
> Mishal Shah
>> 
>> Michael
>> 
>>> 
>>> -- 
>>> -Dave
>>> ___
>>> swift-dev mailing list
>>> swift-dev@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-dev
>> 
> 
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev