Re: [swift-users] بخصوص: Swift 4.0 bug in concurrent array access

[Greg Parker via swift-users]

> On Jan 8, 2018, at 5:20 PM, Chris Lattner <clatt...@nondot.org> wrote:
> 
>> On Jan 8, 2018, at 2:59 PM, Greg Parker via swift-users 
>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>> 
>>> On Jan 8, 2018, at 12:51 PM, Jordan Rose via swift-users 
>>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>>> 
>>>> On Jan 8, 2018, at 11:47, ⁨‫Fadi Botros‬ ‫⁩ <⁨botros_f...@yahoo.com 
>>>> <mailto:botros_f...@yahoo.com>⁩> wrote:
>>>> 
>>>> 1st: How to invoke the thread sanitizer?
>>> 
>>> Check out this article on developer.apple.com 
>>> <http://developer.apple.com/>: 
>>> https://developer.apple.com/documentation/code_diagnostics/thread_sanitizer/enabling_the_thread_sanitizer
>>>  
>>> <https://developer.apple.com/documentation/code_diagnostics/thread_sanitizer/enabling_the_thread_sanitizer>
>>>> 2nd: I think making something like ConcurrentModificationException of Java 
>>>> should be a little better experience (if it will not make, or make a small 
>>>> performance penalty, also if it makes performance penalty, it would be 
>>>> activated only when you make a debug version or non-optimized version)
>>> 
>>> I don't exactly disagree, but my understanding is that the work to do such 
>>> a thing is nearly equivalent to having thread sanitizer on all the time. 
>>> But maybe there's a simpler model that we could still turn on in debug 
>>> builds. Can you file a bug report requesting this now that bugs.swift.org 
>>> <http://bugs.swift.org/> is back up?
>> 
>> Something like ConcurrentModificationException ought to be cheaper than the 
>> thread sanitizer. The thread sanitizer works hard to detect every 
>> concurrency error. ConcurrentModificationException typically does something 
>> simple and cheap that catches errors sometimes but makes no attempt to be 
>> exhaustive.
>> 
>> Objective-C's fast enumeration protocol includes a mechanism like this. The 
>> collection can have a simple mutation counter, and the enumerator captures 
>> the counter's value at the start and checks that the value is unchanged as 
>> the enumeration proceeds.
> 
> Does ObjC synchronize the mutation counter?  My understanding is that that 
> counter was used to detect mutation while iteration on a single thread, not 
> across threads.

The mutation counter is not synchronized; this is safe for correct code. An 
un-synchronized counter can still sometimes catch mutations from other threads.


-- 
Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime 
Wrangler


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

Re: [swift-users] بخصوص: Swift 4.0 bug in concurrent array access

[Greg Parker via swift-users]

> On Jan 8, 2018, at 12:51 PM, Jordan Rose via swift-users 
>  wrote:
> 
>> On Jan 8, 2018, at 11:47, ⁨‫Fadi Botros‬ ‫⁩ <⁨botros_f...@yahoo.com 
>> ⁩> wrote:
>> 
>> 1st: How to invoke the thread sanitizer?
> 
> Check out this article on developer.apple.com : 
> https://developer.apple.com/documentation/code_diagnostics/thread_sanitizer/enabling_the_thread_sanitizer
>  
> 
>> 2nd: I think making something like ConcurrentModificationException of Java 
>> should be a little better experience (if it will not make, or make a small 
>> performance penalty, also if it makes performance penalty, it would be 
>> activated only when you make a debug version or non-optimized version)
> 
> I don't exactly disagree, but my understanding is that the work to do such a 
> thing is nearly equivalent to having thread sanitizer on all the time. But 
> maybe there's a simpler model that we could still turn on in debug builds. 
> Can you file a bug report requesting this now that bugs.swift.org 
>  is back up?

Something like ConcurrentModificationException ought to be cheaper than the 
thread sanitizer. The thread sanitizer works hard to detect every concurrency 
error. ConcurrentModificationException typically does something simple and 
cheap that catches errors sometimes but makes no attempt to be exhaustive.

Objective-C's fast enumeration protocol includes a mechanism like this. The 
collection can have a simple mutation counter, and the enumerator captures the 
counter's value at the start and checks that the value is unchanged as the 
enumeration proceeds.


-- 
Greg Parker gpar...@apple.com  Runtime 
Wrangler


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

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

[Greg Parker via swift-users]

Jon is correct: JSON uses '.' as the decimal separator. 
Benoit is also correct: the bug is that JSONEncoder is incorrectly writing ',' 
as the decimal separator when the locale is set to fr_FR.

Further discussion will be on the swift-corelibs-dev list.


> On Dec 18, 2017, at 10:08 AM, Jon Shier via swift-users 
>  wrote:
> 
> I’m pretty sure JSON isn’t localized, so this isn’t a bug. Using anything but 
> a . as a decimal separator isn’t valid JSON. 
> 
> 
> Jon
> 
>> On Dec 18, 2017, at 11:51 AM, 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 when using a local that does 
>> not use dot as decimal separator e.g « fr_FR » (we use a coma)
>> 
>> Demonstration of the issue : 
>> 
>> import Foundation
>> 
>> // Required to call setLocale
>> import Darwin
>> 
>> // Let's set to french
>> setlocale(LC_ALL,"fr_FR")
>>  
>> struct Shot:Codable{
>> let seconds:Double
>> }
>>  
>> let shot = Shot(seconds: 1.1)
>>  
>> do{
>> let data = try JSONEncoder().encode(shot)
>> if let json =  String(data:data, encoding:.utf8){
>> // the result is : "{"seconds":1,1001}"
>> // The decimal separator should not be "," but "."
>> print(json)
>> }
>> }catch{
>> print("\(error)")
>> }
>>  
>> exit(EX_OK)
>> 
>> 
>> 
>> 
>> I would like to propose my fix, test it and, but i’m not mastering the 
>> contribution mechanism.
>> 
>> Where should i start? 
>> 
>> I ve forked 
>> https://github.com/benoit-pereira-da-silva/swift-corelibs-foundation 
>> 
>> I have a very simple Unit test that demonstrates the issue.
>> 
>> How can i test my 
>> 
>> 
>> Thanks
>> 
>> 
>> 
>> 
>> 
>> Benoit Pereira da Silva
>> Ultra Mobile Developer & Movement Activist
>> Développeur Ultra Mobile & Militant du mouvement
>> https://pereira-da-silva.com 
>> 
>> 
>> 
>> 
>> 
>> ✄ 
>> This e-mail is confidential. Distribution, copy, publication or use of this 
>> information for any purpose is prohibited without agreement of the sender.
>> Ce message est confidentiel. Toute distribution, copie, publication ou usage 
>> des informations contenues dans ce message sont interdits sans agrément 
>> préalable de l'expéditeur.
>> 
>> 
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-users
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

Re: [swift-users] abs() Bug?

[Greg Parker via swift-users]

> On Dec 12, 2017, at 12:06 PM, C. Keith Ray via swift-users 
>  wrote:
> 
> Should this be reported by Radar or another mechanism?

Either Radar or bugs.swift.org  is fine.


-- 
Greg Parker gpar...@apple.com  Runtime 
Wrangler


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

Re: [swift-users] Swift's method dispatch

[Greg Parker via swift-users]

Evidence in favor of Slava's analysis: if you remove `func f()` from P itself, 
leaving it in the extensions only, then you get "T is Int" from both calls.


> On Dec 8, 2017, at 12:12 PM, Slava Pestov via swift-users 
>  wrote:
> 
> Hi Jens,
> 
> I think the problem is that overload ranking always prefers a protocol 
> requirement to a protocol extension member, because usually you want the 
> dynamic dispatch through the requirement instead of calling the default 
> implementation. But it appears that this heuristic does not take into account 
> the fact that the protocol extension member could be more constrained than 
> the requirement.
> 
> Please file a bug, but it is unclear what the desired behavior actually is 
> here. Perhaps it should just diagnose an ambiguity.
> 
> Slava
> 
>> On Dec 8, 2017, at 6:25 AM, Jens Persson via swift-users 
>>  wrote:
>> 
>> Hi all!
>> 
>> Can someone please explain the rationale behind the last line printing
>> "T is unknown"
>> rather than (what I would expect):
>> "T is Int"
>> in the following program?
>> 
>> 
>> protocol P {
>>associatedtype T
>>func f() // *
>> }
>> extension P {
>>func f() { print("T is unknown") }
>> }
>> extension P where T == Int {
>>func f() { print("T is Int") }
>> }
>> 
>> struct X : P {}
>> 
>> struct Y where U: P, U.T == Int {
>>// NOTE: The compiler/type-checker knows that U.T == Int here so ...
>>typealias T = U.T
>>var a: U
>>func g() { a.f() } // ... how/why could this print anything but "T is 
>> Int"?
>> }
>> 
>> let x = X()
>> x.f() // Prints "T is Int", no matter if * is commented out or not.
>> 
>> let y = Y(a: X())
>> y.g() // Prints "T is unknown" unless * is commented out. Why?
>> 
>> 
>> IMHO this looks like the compiler simply ignores that struct Y has the 
>> constraint  U.T == Int.
>> How else to explain this behavior?
>> /Jens
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

Re: [swift-users] Initialization Catch-22?

[Greg Parker via swift-users]

> On Sep 25, 2017, at 6:12 PM, Kenny Leung via swift-users 
>  wrote:
> 
> I’m trying to implement the AudioQueue example from Apple in Swift, and keep 
> it as Swifty as I can. I’ve run into a problem where I have a let ivar for 
> the AudioQueue, but the only way to initialize that let ivar is to pass a 
> block to the function that creates the AudioQueue. I get the error, "Variable 
> 'self.mQueue' used before being initialized”. Is there any way to get around 
> this catch? 

The compiler cannot guarantee that the code running inside your block does not 
try to use mQueue before it is initialized. Swift strictly enforces its 
initialization rules, so the compiler rejects your code.

One common solution is to change mQueue into an implicitly-unwrapped optional 
var. The compiler still can't tell if your block object uses mQueue before it 
is initialized, but if it does it will get a well-defined runtime error due to 
the nil IUO. That well-defined error is sufficient to pacify the initialization 
rules.

Another solution might be to divide your data into two different types. It 
looks like the block object only needs to access self.audioBuffers and 
self.source. You might be able to box those two fields into a separate class 
type and have the block object capture a reference to that object only. Then 
the initialization order is simple enough for the compiler to understand:
1. PDAudioPlayer.init() initializes a source+audioBuffers object.
2. PDAudioPlayer.init() calls AudioQueueNewOutputWithDispatchQueue(), passing 
it a block that captures a reference to the fully-initialized 
source+audioBuffers object.
3. PDAudioPlayer.init() uses the results of #1 and #2 to complete its own 
initialization or return nil.
This adds an extra allocation and extra indirection to each PDAudioPlayer 
object, but as long as you don't have millions of these things the performance 
difference should be negligible.


> ———8<8<
> class PDAudioPlayer {
> static let kNumberBuffers :Int = 3  // 1
> //var mDataFormat:AudioStreamBasicDescription // 2
> let mQueue :AudioQueueRef  // 3
> //var mBuffers :[AudioQueueBufferRef]// 4
> //var mAudioFile :AudioFileID?// 5
> var bufferByteSize :UInt32? // 6
> var mCurrentPacket :Int64?  // 7
> var mNumPacketsToRead :UInt32?  // 8
> var mPacketDescs :UnsafePointer?  // 9
> var mIsRunning: Bool = false// 10
> 
> let dispatchQueue :DispatchQueue
> let source :PDFileAudioSource
> var audioBuffers :[PDAudioBuffer]
> 
> init?(source:PDFileAudioSource) {
> self.source = source
> self.dispatchQueue = DispatchQueue(label:"AudioPlayer", qos:.default, 
> attributes:[], autoreleaseFrequency:.workItem, target:nil)
> self.audioBuffers = [PDAudioBuffer]()
> 
> var tempAudioQueue :AudioQueueRef?
> var dataFormat = source.mDataFormat
> let status = AudioQueueNewOutputWithDispatchQueue(, 
> , 0, self.dispatchQueue) { [weak self] (queue, buffer) in   // 
> ERROR on this line
> guard let this = self else {
> return // block
> }
> guard let audioBuffer = 
> this.audioBufferForAudioQueueBuffer(aqBuffer:buffer) else {
> return // block
> }
> this.source.fillBuffer(audioBuffer)
> }
> if status != 0 {
> return nil
> }
> guard let audioQueue = tempAudioQueue else {
> return nil
> }
> self.mQueue = audioQueue
> }
> 
> private func audioBufferForAudioQueueBuffer(aqBuffer:AudioQueueBufferRef) 
> -> PDAudioBuffer? {
> for buffer in self.audioBuffers {
> if buffer.audioQueueBuffer == aqBuffer {
> return buffer
> }
> }
> return nil
> }
> }

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

Re: [swift-users] What is up with names not being Strings any more in Swift 4?

[Greg Parker via swift-users]

> On Jul 17, 2017, at 10:01 AM, Nevin Brackett-Rozinsky via swift-users 
>  wrote:
> 
> Could / should these types be ExpressibleByStringLiteral?

They should not. We are deliberately discouraging the string literal of the 
name. The string literal should be in only one place: the definition of the 
name constant. Everything else should use the constant. The compiler can 
provide autocompletion and typo detection of the constant. The string literal 
doesn't get that. 


-- 
Greg Parker gpar...@apple.com  Runtime 
Wrangler


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

Re: [swift-users] Decode a JSON object of unknown format into a Dictionary with Decodable in Swift 4

[Greg Parker via swift-users]

> On Jun 22, 2017, at 6:00 PM, Jon Shier via swift-users 
>  wrote:
> 
>   My main concern here is that, as Swift’s official JSON parsing method, 
> Codable should be able to handle any JSON representation and use and it 
> doesn’t.

Is this true? Is Codable intended to be Swift's official JSON parsing system? 
Is Codable intended to be a general-purpose JSON parsing system? 

My understanding was that Codable was designed to serialize Swift types, not to 
be able to import arbitrary JSON text into Swift nor to interoperate with every 
existing JSON API.


-- 
Greg Parker gpar...@apple.com  Runtime 
Wrangler


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

Re: [swift-users] Can I create a Cocoa app that is only a Swift script?

[Greg Parker via swift-users]

> On Jun 20, 2017, at 7:34 AM, tuuranton--- via swift-users 
>  wrote:
> 
> I want the entire code for my entire Mac app to look like this .swift script:
> 
> #!/path/to/swift
> 
> import Cocoa
> 
> // The rest of my entire Mac app.
> 
> Because we don't yet have binary stability, I guess I'd have to put the swift 
> binary (which runs the above .swift script) and a bunch of .dylibs into the 
> Mac .app bundle somehow.
> 
> Is this possible to do and if so, how?

It is not. The first problem is that there is no value of "/path/to/swift" that 
will work everywhere.


-- 
Greg Parker gpar...@apple.com  Runtime 
Wrangler


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

Re: [swift-users] Questions for bridging from OC to Swift

[Greg Parker via swift-users]

> On May 30, 2017, at 12:11 PM, old donkey via swift-users 
>  wrote:
> 
> Hi All:
> 
> Current bridging from Objective-C to Swift has this behaviour:
> 
> If we define a property in Objective-C, and we don’t say it is nullable or 
> nonnull, like this: @property (nonatomic, strong, readonly) NSString 
> *someString;
> 
> When we reference it from Swift, this property will be bridging to String! 
> (implicitly unwrapped optional) type automatically, and there is no warning 
> indicate we should check if this is nil first.
> 
> So the result is when some edge cases happen, the App will crash.
> 
> As more and more large projects are trying to use Swift now, this may seems a 
> problem for more people.
> 
> The documents I can find is: https://developer.apple.com/swift/blog/?id=25 
> and 
> https://developer.apple.com/library/content/documentation/Swift/Conceptual/BuildingCocoaApps/InteractingWithObjective-CAPIs.html,
>  it says “Swift cannot distinguish between optional and nonoptional 
> references, and imports it as an implicitly unwrapped optional.”
> 
> As in Objective-C, the default property is nullable(if you don’t say it is 
> nonnull), I am curious what’s the reason that the property is not bridging to 
> optional, for me, feel optional value should be a better fit here.

Importing every unmarked Objective-C object pointer as strict optional makes 
traditional Objective-C interfaces cumbersome to use from Swift. You end up 
needing a nil check for every return value, every property access, etc. Such 
code is hard to read and hard to write.

Importing as implicitly-unwrapped optional is a usability compromise. Most 
Objective-C pointers are never actually nil. If a pointer is nil, and the 
author didn't check, then the process deliberately halts. This is no worse than 
the behavior you get when writing Objective-C code.

IUO import is intended to be a stopgap. In the long term every Objective-C 
interface ought to be explicitly annotated so that Swift can import them more 
precisely. In your own code you can use NS_ASSUME_NONNULL_BEGIN/END in your 
header files. Every un-annotated object pointer inside those markers is nonnull.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler


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

Re: [swift-users] stack trace of Swift executable

[Greg Parker via swift-users]

The stack trace printed by the process will never include file and line 
numbers. Swift and ObjC work the same way here.

You want to find the crash report generated by the OS. Either it will have file 
and line numbers already, or it will contain enough information to look up the 
file and line numbers after the fact (part of a process called "symbolication").


> On May 3, 2017, at 2:47 AM, Alex Blewitt  wrote:
> 
> Greg,
> 
> This occurs when compiled with swiftc -g as well. In fact, I think 'swift 
> build', when run by default, will compile with swiftc -g. It's only when you 
> run 'swift build --configuration release' that it will compile without it.
> 
> $ swiftc --version
> Apple Swift version 3.1 (swift-3.1.1-RELEASE)
> Target: x86_64-apple-macosx10.9
> $ swiftc -g main.swift
> $ ./main
> Hello, world!
> fatal error: unexpectedly found nil while unwrapping an Optional value
> Current stack trace:
> 0libswiftCore.dylib 0x00010edc7160 swift_reportError 
> + 125
> 1libswiftCore.dylib 0x00010ede3ac0 
> _swift_stdlib_reportFatalError + 60
> 2libswiftCore.dylib 0x00010ebd4260 specialized 
> specialized StaticString.withUTF8Buffer ((UnsafeBufferPointer) -> 
> A) -> A + 342
> 3libswiftCore.dylib 0x00010ed4f120 partial apply for 
> (_fatalErrorMessage(StaticString, StaticString, file : StaticString, line : 
> UInt, flags : UInt32) -> Never).(closure #2) + 109
> 4libswiftCore.dylib 0x00010ebd4260 specialized 
> specialized StaticString.withUTF8Buffer ((UnsafeBufferPointer) -> 
> A) -> A + 342
> 5libswiftCore.dylib 0x00010ed01d00 specialized 
> _fatalErrorMessage(StaticString, StaticString, file : StaticString, line : 
> UInt, flags : UInt32) -> Never + 96
> 6main   0x00010eb91340 say(message : 
> String?) -> () + 248
> 7main   0x00010eb911e0 main + 328
> 8libdyld.dylib  0x7fffb444d234 start + 1
> Illegal instruction: 4
> 
> Note that lldb can symbolicate the result and identify the return value, by 
> looking at the backtrace:
> 
> $ lldb main
> (lldb) target create "main"
> Current executable set to 'main' (x86_64).
> (lldb) run
> Process 33032 launched: '/tmp/main' (x86_64)
> Hello, world!
> fatal error: unexpectedly found nil while unwrapping an Optional value
> 2017-05-03 10:41:17.340963+0100 main[33032:55100807] fatal error: 
> unexpectedly found nil while unwrapping an Optional value
> Current stack trace:
> 0libswiftCore.dylib 0x0001002c1160 swift_reportError 
> + 125
> 1libswiftCore.dylib 0x0001002ddac0 
> _swift_stdlib_reportFatalError + 60
> 2libswiftCore.dylib 0x0001000ce260 specialized 
> specialized StaticString.withUTF8Buffer ((UnsafeBufferPointer) -> 
> A) -> A + 342
> 3libswiftCore.dylib 0x000100249120 partial apply for 
> (_fatalErrorMessage(StaticString, StaticString, file : StaticString, line : 
> UInt, flags : UInt32) -> Never).(closure #2) + 109
> 4libswiftCore.dylib 0x0001000ce260 specialized 
> specialized StaticString.withUTF8Buffer ((UnsafeBufferPointer) -> 
> A) -> A + 342
> 5libswiftCore.dylib 0x0001001fbd00 specialized 
> _fatalErrorMessage(StaticString, StaticString, file : StaticString, line : 
> UInt, flags : UInt32) -> Never + 96
> 6main   0x00011340 say(message : 
> String?) -> () + 248
> 7main   0x000111e0 main + 328
> 8libdyld.dylib  0x7fffb444d234 start + 1
> Process 33032 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = 
> EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
> frame #0: 0x0001001fbd60 libswiftCore.dylib`function signature 
> specialization  
> of Swift._fatalErrorMessage (Swift.StaticString, Swift.StaticString, file : 
> Swift.StaticString, line : Swift.UInt, flags : Swift.UInt32) -> Swift.Never + 
> 96
> libswiftCore.dylib`function signature specialization  attribute, Arg[2] = Dead, Arg[3] = Dead> of Swift._fatalErrorMessage 
> (Swift.StaticString, Swift.StaticString, file : Swift.StaticString, line : 
> Swift.UInt, flags : Swift.UInt32) -> Swift.Never:
> ->  0x1001fbd60 <+96>: ud2
> 0x1001fbd62 <+98>: nopw   %cs:(%rax,%rax)
> 
> libswiftCore.dylib`protocol witness table accessor for  
> Swift.AnySequence : Swift.Sequence in Swift:
> 0x1001fbd70 <+0>:  pushq  %rbp
> 0x1001fbd71 <+1>:  movq   %rsp, %rbp
> (lldb) bt
> * thread #1, queue = 'com.apple.main-thread', stop reason = 
> EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
>   * frame #0: 0x0001001fbd60 libswiftCore.dylib`function signature 
> specialization  
> of Swift._fatalErrorMessage (Swift.StaticString, Swift.StaticString, file : 
> 

Re: [swift-users] stack trace of Swift executable

[Greg Parker via swift-users]

That doesn't look symbolicated. If it were symbolicated, and the build used -g, 
you would have a file and line number for the main+345 frame.


> On May 2, 2017, at 2:31 PM, Nick Snyder via swift-users 
>  wrote:
> 
> In practice, I would need the stack trace first to figure out how to 
> reproduce the issue, so lldb doesn't really help.
> 
> How would I go about symbolicating this further on macOS (Xcode or otherwise)?
> 
> From reading the docs it seems like the crash report I get is already 
> completely symbolicated:
> https://developer.apple.com/library/content/technotes/tn2151/_index.html#//apple_ref/doc/uid/DTS40008184-CH1-SYMBOLICATION-_DETERMINING_WHETHER_A_CRASH_REPORT_IS_SYMBOLICATED
>  
> 
> 
> On Tue, May 2, 2017 at 1:21 AM, Alex Blewitt  > wrote:
> If you can reproduce it, and run it under lldb, it will print the source line 
> for you:
> 
> $ lldb .build/debug/main
> (lldb) target create ".build/debug/main"
> ruCurrent executable set to '.build/debug/main' (x86_64).
> (lldb) run
> Process 19013 launched: '/private/tmp/main/.build/debug/main' (x86_64)
> Hello, world!
> fatal error: unexpectedly found nil while unwrapping an Optional value
> 2017-05-02 09:17:11.351608+0100 asdf[19013:54205130] fatal error: 
> unexpectedly found nil while unwrapping an Optional value
> Current stack trace:
> 0libswiftCore.dylib 0x0001002c1160 swift_reportError 
> + 125
> 1libswiftCore.dylib 0x0001002ddac0 
> _swift_stdlib_reportFatalError + 60
> 2libswiftCore.dylib 0x0001000ce260 specialized 
> specialized StaticString.withUTF8Buffer ((UnsafeBufferPointer) -> 
> A) -> A + 342
> 3libswiftCore.dylib 0x000100249120 partial apply for 
> (_fatalErrorMessage(StaticString, StaticString, file : StaticString, line : 
> UInt, flags : UInt32) -> Never).(closure #2) + 109
> 4libswiftCore.dylib 0x0001000ce260 specialized 
> specialized StaticString.withUTF8Buffer ((UnsafeBufferPointer) -> 
> A) -> A + 342
> 5libswiftCore.dylib 0x0001001fbd00 specialized 
> _fatalErrorMessage(StaticString, StaticString, file : StaticString, line : 
> UInt, flags : UInt32) -> Never + 96
> 6main   0x00011340 say(message : 
> String?) -> () + 248
> 7main   0x000111e0 main + 328
> 8libdyld.dylib  0x7fffb444d234 start + 1
> Process 19013 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = 
> EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
> frame #0: 0x0001001fbd60 libswiftCore.dylib`function signature 
> specialization  
> of Swift._fatalErrorMessage (Swift.StaticString, Swift.StaticString, file : 
> Swift.StaticString, line : Swift.UInt, flags : Swift.UInt32) -> Swift.Never + 
> 96
> libswiftCore.dylib`function signature specialization  attribute, Arg[2] = Dead, Arg[3] = Dead> of Swift._fatalErrorMessage 
> (Swift.StaticString, Swift.StaticString, file : Swift.StaticString, line : 
> Swift.UInt, flags : Swift.UInt32) -> Swift.Never:
> ->  0x1001fbd60 <+96>: ud2
> 0x1001fbd62 <+98>: nopw   %cs:(%rax,%rax)
> 
> libswiftCore.dylib`protocol witness table accessor for  
> Swift.AnySequence : Swift.Sequence in Swift:
> 0x1001fbd70 <+0>:  pushq  %rbp
> 0x1001fbd71 <+1>:  movq   %rsp, %rbp
> 
> (lldb) bt
> * thread #1, queue = 'com.apple.main-thread', stop reason = 
> EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
>   * frame #0: 0x0001001fbd60 libswiftCore.dylib`function signature 
> specialization  
> of Swift._fatalErrorMessage (Swift.StaticString, Swift.StaticString, file : 
> Swift.StaticString, line : Swift.UInt, flags : Swift.UInt32) -> Swift.Never + 
> 96
> frame #1: 0x00011438 main`say(message=nil) -> () at main.swift:5
> frame #2: 0x00011328 main`main at main.swift:8
> frame #3: 0x7fffb444d235 libdyld.dylib`start + 1
> frame #4: 0x7fffb444d235 libdyld.dylib`start + 1
> 
> There is a symbolication tool available for Linux in the 
> ~/swift/utils/symbolicate-linux-fatal, and Xcode can do the same 
> symbolication for you as well.
> 
> Alex
> 
>> On 28 Apr 2017, at 22:28, Nick Snyder via swift-users > > wrote:
>> 
>> I have a simple main.swift that looks like this:
>> 
>> ```
>> print("Hello, world!")
>> let x: String? = nil
>> 
>> func say(message: String?) {
>> print(x!) // intentional crash
>> }
>> 
>> say(message: x)
>> ```
>> 
>> Running this results in the crash
>> 
>> ```
>> $ swift build && ./.build/debug/hello
>> Hello, world!
>> fatal error: unexpectedly found nil while unwrapping an 

Re: [swift-users] Swift Concurrency and Actor model

[Greg Parker via swift-users]

> On Apr 11, 2017, at 9:10 AM, Gerard Iglesias via swift-users 
>  wrote:
> 
> Thanx for the link on this…
> 
> I am experimenting the use of dispatch queue to mimic somme Actor Model 
> things and it is not a bad idea, dispatch queue are perfect for that.
> 
> I wonder what is the scalability of the Dispatch layer, are we able to create 
> a bunch of dispatch queue without putting the system on its knees ? I will do 
> tests

Dispatch queues are intended to be cheap, comparable to a pthread_mutex IIRC.

The limited resource are the top-level global queues, DispatchQueue.main and 
DispatchQueue.global(…). There are a limited number of threads available to 
service concurrent items on those queues (around 500 threads on macOS and iOS, 
IIRC). If too many concurrent work items are pushed into the global queues at 
one time then the process may deadlock when dispatch exhausts its thread pool.


-- 
Greg Parker gpar...@apple.com  Runtime 
Wrangler


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

Re: [swift-users] Improving compilation times?

[Greg Parker via swift-users]

> On Mar 22, 2017, at 1:03 PM, piotr gorzelany via swift-users 
>  wrote:
> 
> Hi, I hope I reached the right mailing list to ask a question about tooling.
> 
> Can somebody from the compiler or Xcode team share some tips on how to 
> improve compilation times of larger Swift projects?
> 
> I am an iOS developer and the largest issue my team has with Swift so far is 
> that when the project gets semi large (~30 000 lines) the compilation times 
> start to be high (~10 minutes from clean). This is a MAJOR downside since iOS 
> development oftentimes requires rapid changes to UI or logic. Every person of 
> my team compiles a project at least 10 times a day to test new features or 
> functionalities. When compilation times start to be higher than 10 minutes 
> that gets us to ~1.5h a day of developer time spend just on compiling. Not to 
> mention the focus lost when this is happening.
> 
> I know the Swift Evolution list is buzzing with new ideas and features but 
> from my experience the compilation times is a CRITICAL thing to improve in 
> the next Swift release since it cost real money to waste all those developer 
> hours. Just think of all the hours lost on compiling across all Swift devs 
> worldwide and you will get to probably dozens of thousand of dev hours a day.
> 
> Is the core compiler team going to address compilation performance in the 
> next release?
> 
> Maybe there is an existing solution to long compilation times that we don't 
> know of? It would be great if anybody could share.
> I was thinking maybe of dividing the app into multiple frameworks since I 
> think frameworks are compiled only once only on change?

Build time is always a goal. Pretty much every version of Swift has had changes 
intended to improve compilation time or decrease the frequency of recompilation.

Often a large part of the build time is spent in a handful of places where the 
compiler's type inference system behaves poorly. You can use the 
-debug-time-function-bodies and -debug-time-expression-type-checking flags to 
look for these places. You can often get huge decreases in compile time by 
adding an explicit type declaration in the right place in order to simplify the 
type inference engine's job.

Here's a walkthough of one such analysis:
Profiling your Swift compilation times
http://irace.me/swift-profiling


-- 
Greg Parker gpar...@apple.com  Runtime 
Wrangler


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

Re: [swift-users] Master branch not compiling

[Greg Parker via swift-users]

> On Feb 20, 2017, at 12:56 PM, Mohit Athwani via swift-users 
>  wrote:
> 
> Hello,
>  I fetched updates from upstream into my forked and cloned repository and 
> tried to compile for linux_1604 and the compile fails with error: no matching 
> constructor for initialization of swift::TypeAliasDecl
> 
> Wondering if anybody else is facing this issue. This is the master branch btw

IIRC there was a temporary problem here a few days ago. Does it still fail if 
you pull changes from today's master?


-- 
Greg Parker gpar...@apple.com  Runtime 
Wrangler


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

Re: [swift-users] Check deployment target at runtime or compile time

[Greg Parker via swift-users]

> On Feb 15, 2017, at 11:11 AM, Ole Begemann via swift-users 
>  wrote:
> 
> In macOS 10.12 and iOS 10.0, class properties were introduced to Objective-C 
> [1]. I noticed that the Objective-C runtime treats class properties 
> differently based on the deployment target. Example:
> 
>// MyClass is an Objective-C class that has a class property
>let metaclass = object_getClass(MyClass.self)
>var count: UInt32 = 0
>let properties = class_copyPropertyList(metaclass, )
>// Work with properties
>// Deallocate properties
> 
> When the deployment target is macOS 10.12, passing a metaclass to 
> copyPropertyList() returns the class properties, but it returns an empty list 
> on a lower deployment target.

That's right. The Objective-C runtime was written with the expectation that 
class properties would be added someday, but that code was buggy. On macOS 
10.10 and iOS 8.x and older if libobjc sees a class property then it may crash. 
The fix was for clang and swiftc to leave class properties out of the ObjC 
metadata when compiling for those deployment targets. 

macOS 10.11 and iOS 9.x deployment targets are both safe. (Class properties 
still did not exist then. Instead the bug that nobody had seen yet was 
unknowingly fixed when the code was rewritten for an unrelated optimization.)

Note that class property visibility depends on the deployment target used to 
compile that class's implementation. It is possible to see class properties 
from some classes but not others if the classes come from different executables 
with different deployment targets.


> I'd like to perform a check (either at runtime or compile time) which of 
> these behaviors I'll get.
> 
> I didn't find a way to perform a compile-time check in Swift against the 
> deployment target; if #available() checks against the SDK the code is linked 
> against. Likewise, the usual runtime check using 
> ProcessInfo().isOperatingSystemAtLeast() doesn't check against the deployment 
> target.
> 
> The best I came up with is this:
> 
> /**
> Returns `true` if the current deployment target is at least the specified 
> version that corresponds to the current platform.
> 
> The arguments must be passed in the form of the `__MAC_XX_X`, 
> `__IPHONE_XX_X`, etc. constants defined in Availability.h.
> */
> public func isDeploymentTargetAtLeast(
>macOS macOSVersion: Int32, iOS iOSVersion: Int32,
>tvOS tvOSVersion: Int32, watchOS watchOSVersion: Int32) -> Bool {
> 
>#if os(macOS)
>return __MAC_OS_X_VERSION_MIN_REQUIRED >= macOSVersion
>#elseif os(iOS)
>return __IPHONE_OS_VERSION_MIN_REQUIRED >= iOSVersion
>#elseif os(tvOS)
>return __TV_OS_VERSION_MIN_REQUIRED >= tvOSVersion
>#elseif os(watchOS)
>return __WATCH_OS_VERSION_MIN_REQUIRED >= watchOSVersion
>#else
>return false
>#endif
> }
> 
> For example, to test if the current deployment target is at least macOS 
> 10.12, iOS 10.0, tvOS 10.0, or watchOS 3.0:
> 
> guard isDeploymentTargetAtLeast(
>macOS: __MAC_10_12, iOS: __IPHONE_10_0,
>tvOS: __TVOS_10_0, watchOS: __WATCHOS_3_0) else {
> 
>// Deployment target is lower
>...
> }
> 
> Is this correct? Is there a better way to do this?

That code ought to work, assuming that the implementation of 
isDeploymentTargetAtLeast() and the implementations of the interrogated classes 
are in the same executable, or are all in executables compiled with the same 
deployment target.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler


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

Re: [swift-users] Crash with swift_weakLoadStrong in the stack

[Greg Parker via swift-users]

Ah, it's 32-bit iOS. (I assumed i386 or x86_64 from the unaligned instruction 
addresses, but forgot that 32-bit ARM can have those too.) The small-looking 
addresses are okay, then.

That +437720 is still bogus. Ordinarily a symbol with a large offset means that 
the code was actually in some other function, but there was no symbol available 
for that other function. In such cases the symbolicator picks the closest 
symbol available; the large offset means that other symbol was far away. In 
this case that offset is larger than the address itself, which is impossible. 
Something in that frame was calculated incorrectly.

You may get better answers from Crashlytics about this. It looks suspiciously 
like an incorrect backtrace and/or incorrect symbolication of the backtrace.


> On Feb 13, 2017, at 4:25 PM, Jon Shier  wrote:
> 
> These crashes are uploaded from device, namely an iPad 4 (running the app in 
> compatibility mode) uploaded through Crashlytics and then downloaded from 
> there. I haven’t been able to reproduce the crash and so I haven’t seen a raw 
> dump. Here’s the full crash stack, redacted, from an iPad 4 running iOS 
> 10.1.1 (this is an iOS 10+ app).
> 
> #0. Crashed: com.apple.main-thread
> 0  App0x665ac 
> Controller.handleSomeNotification(SomeNotification) -> () 
> (Controller.swift:92)
> 1  libswiftCore.dylib 0x131854f swift_unknownWeakLoadStrong + 
> 10
> 2  App0x65cfc 
> Controller.handleFinishSomeNotification(Notification) -> () (Controller.swift)
> 3  App0x65dd8 @objc 
> Controller.handleSomeOtherNotification(Notification) -> () + 437720
> 4  CoreFoundation 0x1bafa761 
> __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 10
> 5  CoreFoundation 0x1bafa09d _CFXRegistrationPost + 386
> 6  CoreFoundation 0x1baf9e81 
> ___CFXNotificationPost_block_invoke + 40
> 7  CoreFoundation 0x1bb5581d -[_CFXNotificationRegistrar 
> find:object:observer:enumerator:] + 1188
> 8  CoreFoundation 0x1ba5a09d _CFXNotificationPost + 540
> 9  App0x15b004 specialized 
> specialized NotificationCenter.post (A, forName : NSNotification.Name) -> 
> () (Notifications.swift)
> 10 App0x8d6f4 
> SomeListener.(post(SomeNotification : SomeNotification) -> ()).(closure #1) 
> (SomeNotificationHandler.swift)
> 11 App0x96318 partial apply for 
> SomeListener.(post(SomeNotification : SomeNotification) -> ()).(closure #1) 
> (SomeNotificationHandler.swift)
> 12 libdispatch.dylib  0x1b1f5097 
> _dispatch_call_block_and_release + 10
> 13 libdispatch.dylib  0x1b1f5083 _dispatch_client_callout + 22
> 14 libdispatch.dylib  0x1b1f95fd 
> _dispatch_main_queue_callback_4CF + 890
> 15 CoreFoundation 0x1bb0aa17 
> __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 8
> 16 CoreFoundation 0x1bb08cff __CFRunLoopRun + 1422
> 17 CoreFoundation 0x1ba58073 CFRunLoopRunSpecific + 486
> 18 CoreFoundation 0x1ba57e81 CFRunLoopRunInMode + 104
> 19 GraphicsServices   0x1d204bfd GSEventRunModal + 156
> 20 UIKit  0x20c0c82f -[UIApplication 
> _run] + 574
> 21 UIKit  0x20c06f61 UIApplicationMain + 
> 150
> 22 App0x4bc38 main 
> (AppDelegate.swift:12)
> 23 libdispatch.dylib  0x1b22250b (Missing)
> 
> Essentially I have a listener waiting on a background queue for a push 
> notification to come in, which then repackages the payload into a 
> Notification using a generic convenience method I wrote, and posted onto the 
> main queue. Controller is listening for this two separate notifications, one 
> of which is the SomeNotification. But the @objc method in there is the 
> selector for the other notification, SomeOther. There should be no path 
> between 3 and 2 in the stack, and there are no weak references I can see, 
> except perhaps the implicit ones from NotificationCenter. Badly 
> resymbolicated log? Is that even possible?
> 
> 
> Jon
> 
>> On Feb 13, 2017, at 6:52 PM, Greg Parker > > wrote:
>> 
>>> 
>>> On Feb 13, 2017, at 12:18 PM, Jon Shier via swift-users 
>>> > wrote:
>>> 
>>> Swift Users:
>>> I’m currently seeing a crash in my iOS app that has no apparent cause, 
>>> but a bit of Swift runtime machinery in the stack has me confused.
>>> 
>>> #0. Crashed: com.apple.main-thread
>>> 0  App0x665ac 
>>> Controller.handleOtherNotification(Notification) -> () (Controller.swift:92)

Re: [swift-users] Autoreleasepool for Ubuntu

[Greg Parker via swift-users]

> On Nov 2, 2016, at 1:08 PM, Joe Groff via swift-users  
> wrote:
> 
>> On Nov 2, 2016, at 1:00 PM, Philippe Hausler > > wrote:
>> 
>> See:
>> 
>> https://github.com/apple/swift-corelibs-foundation/blob/d015466450b2675037c6f1ace8e17e73050ccfb9/Foundation/NSURL.swift#L561
>>  
>> 
>> 
>> This is far and few between of cases that it would be useful but there are a 
>> few APIs that we have not been able to express without being able to 
>> autorelease items. Most of which we have either forbidden in Linux or 
>> redesigned because they were sub-par swift experiences. However it seems 
>> reasonable to have a minimal shim to provide cross platform code 
>> compatibility even if it does next to nothing. That way trivial code as the 
>> original issue showed can easily be directly compiled on either platform 
>> without littering gnarly #ifdefs about.
> 
> In the fullness of time, the borrow model will hopefully give us a way to 
> represent those kinds of "returns inner pointer" APIs safely in Swift without 
> relying on dynamic lifetime extension, or awkward 'with { ... }' callbacks.

Not to mention using autoreleasepool to handle returns-inner-pointer isn't 
memory safe anyway. If the autorelease pool pops too soon then you end up with 
a dangling pointer that no amount of compiler analysis can detect. 


-- 
Greg Parker gpar...@apple.com Runtime Wrangler


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

Re: [swift-users] Why can't we get `URL` equal on the same path?

[Greg Parker via swift-users]

> On Oct 14, 2016, at 7:33 AM, Zhao Xin via swift-users  
> wrote:
> 
> As you can see, `URL` is not equal but the `path` is. I wonder why urls do 
> not equal here?
> 
> let url = URL(fileURLWithPath: "foo/bar", isDirectory: false)
> let baseURL = url.deletingLastPathComponent()
> let newURL = URL(fileURLWithPath: "bar", isDirectory: false, relativeTo: 
> baseURL)
> 
> print(url == newURL) // prints false
> print(url.path == newURL.path) // prints true

Here's one reason:
print(url.baseURL == newURL.baseURL)  // prints false


-- 
Greg Parker gpar...@apple.com  Runtime 
Wrangler


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

Re: [swift-users] Overload by return type optionality?

[Greg Parker via swift-users]

> On Oct 13, 2016, at 2:36 PM, Rick Mann via swift-users 
>  wrote:
> 
> It seems I can write this:
> 
> extension String
> {
>  public func deleting(prefix inPrefix: String) -> String
>  public func deleting(prefix inPrefix: String) -> String?
> }
> 
> But I was hoping it would do the right thing:
> 
> let a = s.deleting(prefix: "foo")
> if let b = s.deleting(prefix: "foo") { }
> 
> But it finds these ambiguous, and I'm not sure how to specify which I want.

You can specify which you want by explicitly naming the type:
let a = s.deleting(prefix: "foo") as String
or
let a : String = s.deleting(prefix: "foo")

…but presumably that doesn't give you the usability that you were hoping for.


-- 
Greg Parker gpar...@apple.com  Runtime 
Wrangler


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

Re: [swift-users] Closure typing changed in Swift 3

[Greg Parker via swift-users]

> On Sep 9, 2016, at 8:05 PM, Rick Mann via swift-users  
> wrote:
> 
> I figured it out. The real problem is that .json accepts AnyObject, and the 
> Dictionary is not AnyObject (not sure what this change is, since it worked in 
> Swift 2). Anyway, that confused the type inference, which resulted in the red 
> herring error message about the closure assignment.

What changed is Objective-C bridging. Previously the compiler could convert 
Dictionary to NSDictionary to AnyObject. Now that path is no longer implicitly 
available.


-- 
Greg Parker gpar...@apple.com  Runtime 
Wrangler


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

Re: [swift-users] Automatically dump stack trace on trap

[Greg Parker via swift-users]

> On Dec 22, 2015, at 4:32 PM, Karl Pickett via swift-users 
>  wrote:
> 
> Having stack traces on critical faults is an "enterprisey" feature that I 
> like.  It would be nice if swift allowed customization of what happened on a 
> trap (like array out of bounds), so it dumped the thread's stack trace to 
> stderr before exiting.
> 
> I can simulate the desired behavior by installing a signal handler for 
> SIGILL, and launch a script that fires up a debugger which attaches to the 
> process and dumps the stack trace(s) before terminating it.
> 
> I wrote it in C pretty easily and it is here: 
> https://gist.github.com/kjpgit/9a1059a5960694767193 
> 
> 
> It's just a small pain to build and link the C code to each swift project.  
> So my question is, can I use pure swift code for the signal handling instead 
> of that C shim.
> 
> 1)  Does swift on linux support an atomic_fetch_add() equivalent out of the 
> box (or some other signal-safe serialization)
> 2) Any other concerns using swift code in a signal handler.  I'd just be 
> using Glibc system calls, and any char data would be pre-allocated.

You should use the C code. Signal handlers are allowed to do almost nothing. 
Neither the Swift runtime nor the code generated by the Swift compiler promise 
to be signal-safe.


-- 
Greg Parker gpar...@apple.com  Runtime 
Wrangler


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