Re: [swift-dev] Swift CI: Pull Request Check Status

Awesome! Thanks Mishal! Do we have a persistent place where we are documenting these options? > On Aug 25, 2016, at 1:46 PM, mishal_shah via swift-dev > wrote: > > With new changes to the pull request jobs, if you trigger full test suite it > will also update the smoke test checks. > Trigge

Re: [swift-dev] __swift__

> On Aug 25, 2016, at 3:11 PM, Jordan Rose via swift-dev > wrote: > >> >> On Aug 25, 2016, at 14:58, Douglas Gregor > > wrote: >> >>> >>> On Aug 25, 2016, at 2:48 PM, Jordan Rose >> > wrote: >>> On Aug 25, 2016, at 9:38, Dou

Re: [swift-dev] Swift incremental compile profiling

[+swift-dev again, for posterity] Let’s see, those two are really mostly “I haven’t thought about how to recover from this scenario.” I have an internal presentation on why dependency analysis is the way it is that I should probably throw up in the docs in some format, but mostly these are all

Re: [swift-dev] Why are BinaryFloatingPoint's RawSignificand and RawExponent different type?

Ok, I've learned a lot, thanks! /Jens On Sat, Aug 27, 2016 at 2:26 AM, Stephen Canon wrote: > For any given concrete type, it’s pretty straightforward to map [0, .max] > to [0,1) — note that this is a bit different from what you seem to have > been doing originally, mapping e.g. [0, 2**52) to [0

Re: [swift-dev] Why are BinaryFloatingPoint's RawSignificand and RawExponent different type?

For any given concrete type, it’s pretty straightforward to map [0, .max] to [0,1) — note that this is a bit different from what you seem to have been doing originally, mapping e.g. [0, 2**52) to [0, 1): init(unitRange s: UInt64) { self = Self(s >> UInt64(63 - Self.significandBitCoun

Re: [swift-dev] Why are BinaryFloatingPoint's RawSignificand and RawExponent different type?

Ah, right! Thanks again. How would you make all integer type (UIntN, IntN) convertible/mappable from their respective [.min, .max] range to Double/Float unit range [0, 1)? /Jens On Sat, Aug 27, 2016 at 2:06 AM, Stephen Canon wrote: > Note that with the bug fixed, the result will still not be 1.n

Re: [swift-dev] Why are BinaryFloatingPoint's RawSignificand and RawExponent different type?

Note that with the bug fixed, the result will still not be 1.nextDown, because the size of an ulp changes at 1; the values you produce will be space .ulpOfOne apart, but 1.nextDown is 1 - ulpOfOne/2. – Steve > On Aug 26, 2016, at 8:00 PM, Jens Persson wrote: > > Thanks, but there seem to be s

Re: [swift-dev] Why are BinaryFloatingPoint's RawSignificand and RawExponent different type?

... let a = T.init(unitRangeFromRawSignificand: 0) let b = T.init(unitRangeFromRawSignificand: allSignificantBitsSet) print(a) // 0.0, correct. print(b) // (1.0).nextDown Thanks a lot for all your help! On Sat, Aug 27, 2016 at 2:01 AM, Jens Persson wrote: > Ouch, saw my mistake : ) > > On Sat,

Re: [swift-dev] Why are BinaryFloatingPoint's RawSignificand and RawExponent different type?

Ouch, saw my mistake : ) On Sat, Aug 27, 2016 at 2:00 AM, Jens Persson wrote: > Thanks, but there seem to be something not working the same as in my > original code, here is a quick test of your code: > > protocol BinaryFloatingPointWithBitPattern: BinaryFloatingPoint { > init(bitPattern: Ra

Re: [swift-dev] Why are BinaryFloatingPoint's RawSignificand and RawExponent different type?

Thanks, but there seem to be something not working the same as in my original code, here is a quick test of your code: protocol BinaryFloatingPointWithBitPattern: BinaryFloatingPoint { init(bitPattern: RawSignificand) var bitPattern: RawSignificand { get } } extension Float: BinaryFloatin

Re: [swift-dev] Why are BinaryFloatingPoint's RawSignificand and RawExponent different type?

If BinaryFloatingPoint had init(_: RawSignificand), you could also just write: extension BinaryFloatingPoint { init(unitRangeFromRawSignificand s: RawSignificand) { self = Self(s) * .ulpOfOne } } (this is why I ask if RawSignificand is really the type you want; if you use some co

Re: [swift-dev] Why are BinaryFloatingPoint's RawSignificand and RawExponent different type?

Assuming RawSignificand really is the type you want, I think this does what you’re looking for? protocol BinaryFloatingPointWithBitPattern: BinaryFloatingPoint { init(bitPattern: RawSignificand) var bitPattern: RawSignificand { get } } extension Float: BinaryFloatingPointWithBitPattern {

Re: [swift-dev] Why are BinaryFloatingPoint's RawSignificand and RawExponent different type?

The above is just a useful init for Double and Float. For example I use it for creating random Double's and Float's in the unit range [0, 1) from 64 bit prng like xorshift128Plus or xoroshiro128Plus. It would also be used when trying to write something like this: Double.init(unitRangeMapped value

Re: [swift-dev] Why are BinaryFloatingPoint's RawSignificand and RawExponent different type?

Where does your RawSignificand input come from? Is that really the type that you want? I don’t think you really need very much boilerplate at all here. > On Aug 26, 2016, at 7:30 PM, Jens Persson wrote: > > I understand. > It's just very tempting to try and use the new static computed propert

Re: [swift-dev] Why are BinaryFloatingPoint's RawSignificand and RawExponent different type?

Correction " ... a protocol that only Double and Float conforms to ...". On Sat, Aug 27, 2016 at 1:30 AM, Jens Persson wrote: > I understand. > It's just very tempting to try and use the new static computed properties > for eg 23 and 52 etc. > I guess I'll just have to write a lot of boilerplate

Re: [swift-dev] Why are BinaryFloatingPoint's RawSignificand and RawExponent different type?

I understand. It's just very tempting to try and use the new static computed properties for eg 23 and 52 etc. I guess I'll just have to write a lot of boilerplate, or perhaps a protocol that is just implemented by Double and Float (that will be very similar to BinaryFloatingPoint in a lot of ways).

Re: [swift-dev] Why are BinaryFloatingPoint's RawSignificand and RawExponent different type?

This doesn’t really scale up very well, though. BinaryFloatingPoint needs to also be able to model e.g. Float2048 or similar; we generally don't want to require that RawExponent to be the same type as RawSignificand (which I think is what you’re really suggesting), because in typical bignum usa

Re: [swift-dev] Why are BinaryFloatingPoint's RawSignificand and RawExponent different type?

Oh, to more directly answer your question: I don't like having to create a UInt (UInt64) value when all my bit manipulaton code happens in UInt32 (for Float) for example. The most probable context for using these computed properties and types of BinaryFloatingPoint is one in which specific fixed w

Re: [swift-dev] Why are BinaryFloatingPoint's RawSignificand and RawExponent different type?

Reason for asking is that I have this: extension Double { init(unitRangeFromRawSignificand s: RawSignificand) { let bitPattern = s | (1023 << 52) self = unsafeBitCast(bitPattern, to: Double.self) - 1.0 } } extension Float { init(unitRangeFromRawSignificand s: RawSignifi

Re: [swift-dev] Why are BinaryFloatingPoint's RawSignificand and RawExponent different type?

> On Aug 26, 2016, at 6:06 PM, Jens Persson via swift-dev > wrote: > > I can understand why > Double.RawSignificand is UInt64 > and > Float.RawSignificand is UInt32 > > But I can't understand why both > Double.RawExponent > and > Float.RawExponent > should be UInt. > > Why aren't they also jus

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

Disabled that test and a few others that might time out after it in b98f8d67 > On Aug 26, 2016, at 3:41 PM, mishal_shah wrote: > > Thanks! > >> On Aug 26, 2016, at 3:19 PM, Philippe Hausler > > wrote: >> >> Since this test has been giving us problems I am just going

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

Thanks! > On Aug 26, 2016, at 3:19 PM, Philippe Hausler wrote: > > Since this test has been giving us problems I am just going to disable it. > >> On Aug 26, 2016, at 11:59 AM, mishal_shah via swift-dev > > wrote: >> >> Time out in Foundation test. >> Test Case 'Tes

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

Since this test has been giving us problems I am just going to disable it. > On Aug 26, 2016, at 11:59 AM, mishal_shah via swift-dev > wrote: > > Time out in Foundation test. > Test Case 'TestURLSession.test_downloadTaskWithURL' started at 16:20:09.237 > >> On Aug 26, 2016, at 10:05 AM, no-re.

[swift-dev] Why are BinaryFloatingPoint's RawSignificand and RawExponent different type?

I can understand why Double.RawSignificand is UInt64 and Float.RawSignificand is UInt32 But I can't understand why both Double.RawExponent and Float.RawExponent should be UInt. Why aren't they also just UInt64 and UInt32, resp.? /Jens ___ swift-dev mai

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

This failed due to foundation test failure: Test Case 'TestURLSession.test_downloadTaskWithURL' started at 20:41:02.240 <>Build timed out (after 30 minutes). Marking the build as failed. > On Aug 26, 2016, at 2:11 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-libdispatc

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

Time out in Foundation test. Test Case 'TestURLSession.test_downloadTaskWithURL' started at 16:20:09.237 > On Aug 26, 2016, at 10:05 AM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04 [#7176] > > Build URL: > https://ci.swift.org/job/oss-swift-incremental

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

I've just started working on loopback tests with a simple in-process http server, for URLSession. Pushkar N Kulkarni, IBM RuntimesSimplicity is prerequisite for reliability - Edsger W. Dijkstra -swift-dev-boun...@swift.org wrote: -To: Philippe Hausler From: Tony Parker v