Re: [swift-corelibs-dev] I ve found a serious Bug in JSONEncoder (SR-6131) and would like to fix it.

(moving to more relevant list) > On Dec 18, 2017, at 08:51, Benoit Pereira da silva via swift-users > wrote: > > Dear all > > I've found a serious Bug in JSONEncoder SR-6131 > and would like to fix it. > This bug cause JSON encoding issues on Double whe

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

Doesn't look like any of us. Anything happen over in Dispatch-land? :0: error: cannot open file '/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift-corelibs-libdispatch/private/module.modulemap': No such file or directory Jordan > On Nov 28, 2017, at 11:57, no

Re: [swift-corelibs-dev] [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 16.04 - Long Test (master) #485

> On Oct 24, 2017, at 16:30, Slava Pestov via swift-dev > wrote: > > >> On Oct 24, 2017, at 4:26 PM, Xi Ge via swift-dev > > wrote: >> >> This could be due to one of the following commit. Could someone shed some >> lights on what’s going on? >> Git (git g...@gith

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

Maybe something changed in the standard library's handling of floats? Max? > On Feb 20, 2017, at 13:26, Philippe Hausler wrote: > > That would be new; I have not seen that failure before. the method is quite > droll - it just calls sin/cos and resets the m values accordingly. > > Did sin/cos

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

Foundation folks, have you seen this before? TestFoundation/TestNSAffineTransform.swift:187: error: TestNSAffineTransform.test_Rotation_Radians : XCTAssertEqualWithAccuracy failed: ("10.0") is not equal to ("-10.0") +/- ("0.001") - y (expected: -10.0, was: 10.0): Jordan > On Feb 20, 2017, at

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

None of these changes would have affected the failing XCTest test. Adding swift-corelibs-dev. https://ci.swift.org//job/oss-swift-incremental-RA-linux-ubuntu-14_04/775/consoleFull#-936285465fca400bf-2f4a-462e-b517-e058d770b2d7 > *** Error in > `/home/buildnode/disk2/workspace/oss-swift-incremen

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

Adding swift-corelibs-dev, since that’s where the Dispatch folks hang out. > On Nov 2, 2016, at 10:44, Doug Coleman via swift-dev > wrote: > > https://bugs.swift.org/browse/SR-2931 > > >> On Nov 2, 2016, at 10:43 AM, no-re...@swift.org wrote: >> >> [FA

Re: [swift-corelibs-dev] [swift-dev] Swift Class Encoding Standard?

This is somewhat intentional. While simple names can be encoded hierarchically like this, generics make everything more tricky. Consider a demangled name "Contacts.Person.Address.PostCode"—in this case not only is splitting on "." is no longer a reasonable thing to do, but there's not currently

Re: [swift-corelibs-dev] [swift-dev] Swift CI PR builder dispatch linux failure

The problem with moving the Darwin Dispatch overlay there is that other overlays depend on Dispatch, and we’re not ready to move those out somewhere else. That would compound this cross-repo dependency problem. Jordan > On Sep 26, 2016, at 12:32, Daniel A. Steffen wrote: > > this may be an u

Re: [swift-corelibs-dev] [swift-dev] Swift CI PR builder dispatch linux failure

Oh, I didn’t realize we had a separate copy of the overlay code (almost certainly the right thing to do at this point). But in that case, why are we seeing any of these errors? Jordan > On Sep 25, 2016, at 11:38, David P Grove wrote: > > The order may need to vary by platform. On Linux, the D

Re: [swift-corelibs-dev] [swift-dev] Swift CI PR builder dispatch linux failure

I think the right order to build things is: 1. libdispatch (C) 2. Swift (compiler + stdlib + Dispatch overlay) 3. Foundation Otherwise we need to build Swift, then build libdispatch, then go back to "Swift" to build the overlay, and only finally get to Foundation. Jordan > On Sep 23, 2016, at

Re: [swift-corelibs-dev] [Swift CI] Build Still Failing: 0. OSS - Swift Incremental RA - Ubuntu 14.04 - Long Test (swift 3.0) #302

> Foundation/NSData.swift:19:8: error: module file was created by an older > version of the compiler; rebuild 'Dispatch' and try again: > /home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/buildbot_incremental/libdispatch-linux-x86_64/src/swift/Dispatch.sw

[swift-corelibs-dev] Flaky NSOperationQueue test

Anyone know what’s up with this one? We get it every few builds or so. 17:15:39 TestFoundation/TestNSOperationQueue.swift:63: error: TestNSOperationQueue.test_OperationPriorities : XCTAssertEqual failed: ("Operation1 executed") is not equal to ("Operation3 executed") - 17:15:39 TestFoundation/

[swift-corelibs-dev] Mailing list flakiness

Hey, all. You might have noticed messages being dropped or taking a long time to get through on the swift.org mailing lists. The story is that the configuration for our outbound mail server changed on Tuesday, but we didn't get around to updating it until Wednesday. We think the system is just c

[swift-corelibs-dev] Fwd: [swift-users] [swift-dev] New Swift Snapshots Available!

> Begin forwarded message: > > From: Michael Ferenduros via swift-users > Subject: Re: [swift-users] [swift-dev] New Swift Snapshots Available! > Date: August 26, 2016 at 08:00:55 PDT > To: swift-us...@swift.org > Reply-To: Michael Ferenduros > > >> On 24 Aug 2016, at 12:38, Chris Bailey via

Re: [swift-corelibs-dev] [Swift CI] Build Failure: 0. OSS - Swift libdispatch Incremental RA - Ubuntu 14.04 (master) #183

Not it. Dispatch folks, any idea what's up? > On Aug 24, 2016, at 16:04, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-libdispatch-linux-ubuntu-14_04 [#183] > > Build URL: > https://ci.swift.org/job/oss-swift-incremental-RA-libdispatch-linux-ubuntu-14_04/183/ > >

Re: [swift-corelibs-dev] [swift-build-dev] JIRA workflow: "Resolved" -> "Verify"?

It hasn’t been used so much so far, but on the bugs where it has I like being able to tell the difference. I don’t think we’d poke people about verification like we do with Radar, though, so we will (and have) end up with a lot of bugs left in Resolved/Verify. Jordan > On Aug 15, 2016, at 10:

[swift-corelibs-dev] JIRA workflow: "Resolved" -> "Verify"?

Hi, swift-dev et al (but especially Ted). I’ve recently noticed that our JIRA workflow has been a bit confusing. We currently have five “statuses": 1. Opened: This bug has been filed. 2. In Progress: Someone is actively working on this bug. (Not everyone has been bothering to set this, but it se

[swift-corelibs-dev] JIRA labels (no worries)

Hey, Brian. Re: your comment about labels : > By the way, I'm curious for your thoughts on the swift-3.0 label, which I > introduced in > https://lis

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

[+swift-corelibs-dev] I don't think Foundation even tries to do incremental builds. I wonder if XCTest.so needs to be marked as a dependency somewhere in the higher-level build system. Jordan > On May 12, 2016, at 15:52, Brian Croom wrote: > > I'm not sure where the resiliency work stands, bu

Re: [swift-corelibs-dev] Foundation and explicit pointer nullability (CI edition)

date. Apologies for all the confusion! Jordan > On Apr 11, 2016, at 20:56 , Jordan Rose via swift-corelibs-dev > wrote: > > Update: we've created the master-before-optional-pointers branch at ff373e9, > but run into some complications putting this plan into action. (Speci

Re: [swift-corelibs-dev] Foundation and explicit pointer nullability (CI edition)

er message tomorrow with any new developments. Jordan > On Apr 11, 2016, at 12:23 , Jordan Rose via swift-corelibs-dev > wrote: > > Hi, swift-corelibs-dev. I'm planning to land the changes for SE-0055: Making > pointer nullability explicit > <https://github.com/apple/s

[swift-corelibs-dev] Foundation and explicit pointer nullability (CI edition)

Hi, swift-corelibs-dev. I'm planning to land the changes for SE-0055: Making pointer nullability explicit this afternoon in the Swift compiler; however, the corresponding diff for Foundation is fai

[swift-corelibs-dev] Foundation and explicit pointer nullability

Hey, Philippe, everyone. I've been working on implementing SE-0055: Making pointer nullability explicit , and it's been going well…but only now am I realizing how much it's going to affect Foundatio

Re: [swift-corelibs-dev] [swift-users] build libdispatch failed in ubuntu 14.04

(adding swift-corelibs-dev for additional eyes) > On Mar 29, 2016, at 7:25 , qibo via swift-users wrote: > > Hi, everyone > I follow the command written in INSTALL in > https://github.com/apple/swift-corelibs-libdispatch/blob/master/INSTALL >

Re: [swift-corelibs-dev] NSCoding methods

"We need to get ahold of a class given a name" is definitely a requirement to do NSCoding right. I'm not at all convinced dlsym is a valid long-term answer for that, though. If you have an 'internal' class, it doesn't (currently) have a public symbol that you can use dlsym for. This sort of goe

Re: [swift-corelibs-dev] NSCoding methods

Here's another example on OS X: import Foundation class Outer { class Inner : NSObject, NSCoding { let uuid: Foundation.NSUUID required init?(coder aDecoder: NSCoder) { uuid = aDecoder.decodeObjectForKey("my.uuid") as! Foundation.NSUUID } override i

Re: [swift-corelibs-dev] NSCoding methods

No, we cannot encode things "non-mangled but with the namespace". For any type other than top-level non-generic class types, using a non-mangled name is not unique. The only correct answer for arbitrary classes is to use mangled names, or something that maps one-to-one with mangled names. Now,

Re: [swift-corelibs-dev] Defining _GNU_SOURCE for module-map-included headers

> On Dec 21, 2015, at 10:57 , Pierre Habouzit wrote: > >> On Dec 21, 2015, at 9:34 AM, Jordan Rose via swift-corelibs-dev >> wrote: >> >> Hm. If this is the right setting to set on everybody's system, we could add >> it as part of Clang initializatio

Re: [swift-corelibs-dev] NSCoding methods

IMHO on Linux NSKeyedArchiver should always use mangled names. If we want cross-platform archives, we should set up standard substitutions, but given that Swift classes exposed to Objective-C are archived with their full names it doesn't make sense to use "half the name" in the archive. Jordan

Re: [swift-corelibs-dev] Defining _GNU_SOURCE for module-map-included headers

Hm. If this is the right setting to set on everybody's system, we could add it as part of Clang initialization (for the Clang inside Swift). Otherwise, you can use "-Xcc" to pass extra flags to Clang, in this case "-Xcc -D_GNU_SOURCE=1". Hope that helps, Jordan > On Dec 20, 2015, at 2:29 , Dmi