Re: [swift-dev] What about concurrency?

> 7 вер. 2016 р. о 03:05 Chris Lattner написав(ла): > > On Sep 4, 2016, at 3:00 PM, Anton Mironov via swift-dev > wrote: >> >> My job is mostly consists of writing core functionality for macOS (and I >> love core functionality). My code must take advantage of concurrency. I've >> been looki

Re: [swift-dev] What about concurrency?

On Sep 4, 2016, at 3:00 PM, Anton Mironov via swift-dev wrote: > > My job is mostly consists of writing core functionality for macOS (and I love > core functionality). My code must take advantage of concurrency. I've been > looking for solutions that allow me to write clean and (most important

[swift-dev] [SIL] Deconstructing partial_apply

Last week, I put some effort into trying to reduce the power of SIL's infamous partial_apply instruction. The instruction was intended to make representation and optimization of closures easy by avoiding concretization of the closure type and layout, but in practice, the complexity of dealing wi

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

The graph only looks at deps from Foundation's tree because we have no generator for ninja to validate changes against. Sent from my iPhone > On Sep 6, 2016, at 2:52 PM, Slava Pestov wrote: > > What do you do when the swift module file format changes? Should I bump the > module version when

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

What do you do when the swift module file format changes? Should I bump the module version when something ABI-related changes, even if the serialization format itself didn’t change? Slava > On Sep 6, 2016, at 2:44 PM, Philippe Hausler wrote: > > Because Foundation has no information upon the

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

Because Foundation has no information upon the dependency graph for swift; perhaps we should just be recompiling everything every single time for libFoundation.so. It seems like a waste of CPU cycles but I don’t really see any way around it. > On Sep 6, 2016, at 2:41 PM, Slava Pestov via swift

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

This error is caused by stale build artifacts: /home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/buildbot_incremental/foundation-linux-x86_64/TestFoundation/TestFoundation: symbol lookup error: /home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/

[swift-dev] Advice on adding PGO support

Hi swift-dev, I've been working on some patches which add basic support for PGO to swift [1]. What I have so far is just a proof-of-concept. I'd like to get some feedback on the approach I've taken. I've added support for loading profile data, matching up execution counts to the right parts of th

Re: [swift-dev] [swift-evolution] [Swift 4] Organizing source stability

> On Jul 29, 2016, at 21:13, Chris Lattner via swift-dev > wrote: > > >> On Jul 29, 2016, at 5:55 PM, Jacob Bandes-Storch > > wrote: >> >> Here are a few thoughts: >> -swift=4 >> -swift-version=4 > > -swift-version seems like the best option to me, but Jordan will

Re: [swift-dev] Implementation of Type Erasers

Thanks! That explains a lot. In my version, performance only is improved by 10%, so I'm not sure if the tradeoff is worth it: In the isolated case of AnyIterator, there's only one method, so the sizeof is the same (and the performance is worth it). In the case of AnySequence, it would be a lot mo