Re: [swift-users] Swift 4.0 LLDBFrontend Crash

[Edward Connell via swift-users]

Specifying the clang import location is what is triggering the LLDBFrontend
crash.
I think you are saying that I should not need to specify the clang include
import location to the compiler.

I've attached the unmodified SwiftProtobuf example program found in the
docs at https://github.com/apple/swift-protobuf.git, so this is independent
from my project.

Are you able to simply do "swift build" and successfully debug and examine
values like "info"?
For me it fails unless I also specify the import location for the clang
include directory.

swift build -I/home/ed/swift/usr/lib/swift/clang/include

And yes I checked, I am picking up the correct swift binary


*Swift*
$ swift --version
Swift version 4.0.1-dev (LLVM 2dedb62a0b, Clang b9d76a314c, Swift
00e34e4b1e)
Target: x86_64-unknown-linux-gnu

*LLDB failure output*

$ lldb HelloWorld
(lldb) target create "HelloWorld"
Current executable set to 'HelloWorld' (x86_64).
(lldb) b main.swift:20
Breakpoint 1: where = HelloWorld`main + 1116 at main.swift:21, address =
0x0041146c
(lldb) run
Process 20745 launched:
'/home/ed/Documents/prototest/.build/x86_64-unknown-linux/debug/HelloWorld'
(x86_64)
Process 20745 stopped
* thread #1, name = 'HelloWorld', stop reason = breakpoint 1.1
frame #0: 0x0041146c HelloWorld`main at main.swift:21
   18  let binaryData: Data = try info.serializedData()
   19
   20  // Deserialize a received Data object from `binaryData`
-> 21  let decodedInfo = try BookInfo(serializedData: binaryData)
   22
   23  // Serialize to JSON format as a Data object
   24  let jsonData: Data = try info.jsonUTF8Data()
Target 0: (HelloWorld) stopped.
(lldb) p info
error: in auto-import:
failed to get module 'HelloWorld' from AST context:
:1:10: note: in file included from :1:
#include "CoreFoundation.h"
 ^

error: /home/ed/swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:26:10:
error: 'stdarg.h' file not found
#include 
 ^

/home/ed/swift/usr/lib/swift/CoreFoundation/CFStream.h:20:10: note: while
building module 'CDispatch' imported from
/home/ed/swift/usr/lib/swift/CoreFoundation/CFStream.h:20:
#include 
 ^

:1:10: note: in file included from :1:
#include "dispatch.h"
 ^

/home/ed/swift/usr/lib/swift/dispatch/dispatch.h:30:10: note: in file
included from /home/ed/swift/usr/lib/swift/dispatch/dispatch.h:30:
#include 
 ^

/home/ed/swift/usr/lib/swift/os/linux_base.h:19:10: note: in file included
from /home/ed/swift/usr/lib/swift/os/linux_base.h:19:
#include 
 ^

error: /usr/include/x86_64-linux-gnu/sys/param.h:23:10: error: 'stddef.h'
file not found
#include 
 ^

error: could not build C module 'CoreFoundation'


On Mon, Oct 16, 2017 at 11:00 AM, Alex Blewitt  wrote:

> > On 16 Oct 2017, at 18:52, Edward Connell  wrote:
> >
> > While creating a bug report for this problem I placed my simple repro
> case in a separate project with default build settings and I found that it
> no longer crashes LLDB.
> >
> > My main project links to several system C libraries, because I am using
> libpng, Cuda, etc...
> > In order for LLDB to function with my project and load things from the
> AST context, I was told to specify the clang include directory.
> >
> > swift build -Xswiftc -I${SWIFT_HOME}/lib/swift/clang/include
> >
> > In the past everything worked fine.
> >
> > The stand alone bug repro project has no C library dependencies, however
> if I add this option, LLDB crashes.
>
> If you can add that information to the bug report, including whawt version
> of swift you're using (with swiftc -v) and the crash report then that would
> allow others to see what problem you're experiencing.
>
> I assume that SWIFT_HOME is the same location as the swift executable that
> you're running? Might be worth checking with 'which swift'.
>
> > I tried eliminating this option from my main project, and from a
> separate project using SwiftProtobuf. The result is that I am no longer
> able to debug either of them. Is there some new way we are supposed to pick
> up system imports, or is the a legitimate bug?
>
> The Swift REPL on Linux needs to have the -I flag in order to work as
> expected. However, the swift compiler shouldn't need to have that
> information, since it will know where the corresponding include directory
> is.
>
> Alex
>


prototest.tar.gz
Description: GNU Zip compressed data
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Swift 4.0 LLDBFrontend Crash

[Edward Connell via swift-users]

While creating a bug report for this problem I placed my simple repro case
in a separate project with default build settings and I found that it no
longer crashes LLDB.

My main project links to several system C libraries, because I am using
libpng, Cuda, etc...
In order for LLDB to function with my project and load things from the AST
context, I was told to specify the clang include directory.

swift build -Xswiftc -I${SWIFT_HOME}/lib/swift/clang/include

In the past everything worked fine.

The stand alone bug repro project has no C library dependencies, however if
I add this option, LLDB crashes.

I tried eliminating this option from my main project, and from a separate
project using SwiftProtobuf. The result is that I am no longer able to
debug either of them. Is there some new way we are supposed to pick up
system imports, or is the a legitimate bug?

Ed


On Mon, Oct 16, 2017 at 1:37 AM, Alex Blewitt <alb...@apple.com> wrote:

> Thanks for the analysis. Can you create a bug at https://bugs.swift.org and
> attach the reproducing test case? That way it can be routed to the
> appropriate people, in case they're not on this mailing list.
>
> Alex
>
>
> On 13 Oct 2017, at 22:09, Edward Connell via swift-users <
> swift-users@swift.org> wrote:
>
> I was able to boil down a repro that has nothing to do with my project,
> woo hoo!
> Put a break at the print statement and run. When it hits the break point
> LLDBFrontend crashes.
> The do/catch seems to be necessary to trigger the crash
>
> Swift 4.0 release
> Ubuntu 16.04
>
> Ed
>
> 
> import Foundation
>
> public class SomeClass { }
>
> public struct SomeStruct {
>   public weak var someClass: SomeClass?
> }
>
> do {
>   let data = SomeStruct()
>
>   print("break here")
> } catch {
>   print(String(describing: error))
> }
>
>
> On Fri, Oct 13, 2017 at 10:21 AM, Edward Connell via swift-users <
> swift-users@swift.org> wrote:
>
>> Hi Michael,
>> Thanks, I created and attached a log for you with "types" and
>> "expressions" enabled
>> I set a breakpoint right before calling the function that triggers the
>> crash, enabled logging, then continued. I was trying to reduce the amount
>> of log output to sift through.
>>
>> This was run with the Swift 4.0 release version
>> Let me know if you want me to try anything else.
>>
>> Thanks, Ed
>>
>>
>>
>> On Thu, Oct 12, 2017 at 11:13 AM, Michael Gottesman <mgottes...@apple.com
>> > wrote:
>>
>>> I just added a section to ./docs/DebuggingTheCompiler.rst on how to get
>>> enable logging from LLDB.
>>>
>>> Can you enable the logging there and add file an SR?
>>>
>>> Michael
>>>
>>> On Oct 7, 2017, at 11:27 AM, Edward Connell <ewconn...@gmail.com> wrote:
>>>
>>> Hi Michael,
>>> No I am not evaluating an expression or anything. This all worked fine
>>> in past builds.
>>>
>>> I simply set a breakpoint in a function and after stopping while
>>> gathering values for the debugger view, it crashes.
>>>
>>> It doesn't crash in all functions, but it does crash when trying to stop
>>> in many different functions.
>>> An example function signature where it crashes is (DataView is a
>>> concrete struct):
>>>
>>> public func setupForward(mode: EvaluationMode, inData: DataView, labels:
>>> DataView?,
>>>  outData: inout DataView, backData:
>>> inout DataView?) throws { ... }
>>>
>>> Before calling the function, all of the parameters have valid values
>>> that I can examine. But as soon as I step into this function, LLDB crashes
>>> with that message. It behaves the same way with other functions that have
>>> different signatures.
>>>
>>> I tried to create a very simple repro case using this signature, but it
>>> didn't crash. My project is on GitHub and this can be easily reproduced.
>>> The only pain is installing my project on your test machine.
>>>
>>> Ubuntu 16.04
>>> Swift 4.0 release
>>> NVidia gpu
>>> Netlib https://github.com/ewconnell/Netlib/wiki#installation
>>> CLion IDE with Swift plugin
>>>
>>> 1) do a debug build
>>> 2) set a breakpoint at CudaSoftmax.swift:44  or any line in the function
>>> 3) run
>>> 4) when it stops LLDBFrontend crashes
>>>
>>> *LLDBFrontend:
>>> /home/buildnode/jenkins/workspace/oss-swift-4.0-package-linux-ubuntu-16_04/swift/lib/SIL

Re: [swift-users] SwiftProtobuf unable to link on Ubuntu

[Edward Connell via swift-users]

Hi Alex,
Yes of course using the Swift PM is what I needed to do. What was I
thinking! ;p
It worked, however SwiftProtobuf 1.0.0 does not build cleanly with Swift
4.0 due to the rework of the Strings API. I hope someone will clean that up
soon.

I appreciate your feedback and time, Ed


On Mon, Oct 16, 2017 at 1:42 AM, Alex Blewitt  wrote:

> > On 14 Oct 2017, at 21:41, Geordie J via swift-users <
> swift-users@swift.org> wrote:
> >
> >> swift build -Xswiftc -I/home/ed/swift-protobuf/.build/release -Xlinker
> -L/home/ed/swift-protobuf/.build/release
> >
> > Have you considered using Swift Package Manager to add protobuf as a
> project dependency? Then you wouldn’t have to mess around with command line
> arguments at all. I haven’t used protobuf yet so can’t help with specifics.
>
> I'd strongly recommend using Swift Package Manager to help you here. You
> need to compile and build protobuf and have that linked into your product
> at the same time. Since this is what Swift PM works well for that's
> probably the longer-term supported way forward.
>
> If you're still trying to do this via the command line, I recommend
> finding where you're compiling the .so for the swift-protobuf code, then
> using nm and grep to look through that library to confirm whether or not it
> contains the symbols that your code thinks is missing.
>
> If you have acquired a swift-protobuf binary library from somewhere else,
> it may not have the Swift code you're looking for, or it may be compiled
> with a different version of Swift, both of which can affect the names of
> the symbols being linked. Generally speaking, any _T* symbols are Swift
> symbols, and that's usually a clue that either they are not present in the
> libraries you have specified in the command line, or the library you're
> linking against doesn't have them. Follow the rabbit down the hole and find
> out which if you are against using Swift PM.
>
> Alex
>
>
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] SwiftProtobuf unable to link on Ubuntu

[Edward Connell via swift-users]

Hi Geordie,
That is actually a capital "I" eye for import
This font make an eye and elle look the same. This is the build line I am
trying to use.

swift build -Xswiftc -I/home/ed/swift-protobuf/.build/release -Xlinker
-L/home/ed/swift-protobuf/.build/release

On Sat, Oct 14, 2017 at 1:00 PM, Geordie J <geo...@gmail.com> wrote:

> Hi
>
> Am 14.10.2017 um 21:55 schrieb Edward Connell via swift-users <
> swift-users@swift.org>:
>
> Has anyone used the SwiftProtobuf module on Linux?
> https://github.com/apple/swift-protobuf
>
> I am able to successfully generate swift classes from my proto file.
> However when building, the code compiles but I get a ton of undefined link
> references.
>
> I included -Xswiftc -I/home/ed/swift-protobuf/.build/release so the
> module is found, but still….
>
>
> This should be "-Xlinker” rather than “-Xswiftc”, and also “-l” is for
> specifying system library names (e.g. "-latomic”). I’m pretty new to this
> but I think the correct flag is “-L”.
> So in the past I have used “-Xlinker -L/path/to/libs”, but I’ve recently
> read you can actually leave off “-Xlinker” and just have the “-L” bit.
>
> Hope that helps.
>
> - Geordie
>
>
> 
> /home/ed/Documents/prototest/Sources/DataModel.pb.swift:31: error:
> undefined reference to '_T013SwiftProtobuf14UnknownStorageVACycfC'
> /home/ed/Documents/prototest/Sources/DataModel.pb.swift:31: error:
> undefined reference to '_T013SwiftProtobuf14UnknownStorageVACycfC'
> /home/ed/Documents/prototest/Sources/DataModel.pb.swift:64: error:
> undefined reference to '_T013SwiftProtobuf14UnknownStor
> ageV8traverseyxz7visitor_tKAA7VisitorRzlF'
> /home/ed/Documents/prototest/Sources/DataModel.pb.swift:0: error:
> undefined reference to '_T013SwiftProtobuf7MessagePAAE13isInitializedSbfg'
>
> etc...
>
> Does anyone have a simple working example on Ubuntu?
>
> Ubuntu 16.04
> Swift 4.0 release
>
> Thanks, Ed
> ___
> 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] SwiftProtobuf unable to link on Ubuntu

[Edward Connell via swift-users]

Has anyone used the SwiftProtobuf module on Linux?
https://github.com/apple/swift-protobuf

I am able to successfully generate swift classes from my proto file.
However when building, the code compiles but I get a ton of undefined link
references.

I included -Xswiftc -I/home/ed/swift-protobuf/.build/release so the module
is found, but still


/home/ed/Documents/prototest/Sources/DataModel.pb.swift:31: error:
undefined reference to '_T013SwiftProtobuf14UnknownStorageVACycfC'
/home/ed/Documents/prototest/Sources/DataModel.pb.swift:31: error:
undefined reference to '_T013SwiftProtobuf14UnknownStorageVACycfC'
/home/ed/Documents/prototest/Sources/DataModel.pb.swift:64: error:
undefined reference to
'_T013SwiftProtobuf14UnknownStorageV8traverseyxz7visitor_tKAA7VisitorRzlF'
/home/ed/Documents/prototest/Sources/DataModel.pb.swift:0: error: undefined
reference to '_T013SwiftProtobuf7MessagePAAE13isInitializedSbfg'

etc...

Does anyone have a simple working example on Ubuntu?

Ubuntu 16.04
Swift 4.0 release

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

Re: [swift-users] Swift 4.0 LLDBFrontend Crash

[Edward Connell via swift-users]

I was able to boil down a repro that has nothing to do with my project, woo
hoo!
Put a break at the print statement and run. When it hits the break point
LLDBFrontend crashes.
The do/catch seems to be necessary to trigger the crash

Swift 4.0 release
Ubuntu 16.04

Ed


import Foundation

public class SomeClass { }

public struct SomeStruct {
  public weak var someClass: SomeClass?
}

do {
  let data = SomeStruct()

  print("break here")
} catch {
  print(String(describing: error))
}


On Fri, Oct 13, 2017 at 10:21 AM, Edward Connell via swift-users <
swift-users@swift.org> wrote:

> Hi Michael,
> Thanks, I created and attached a log for you with "types" and
> "expressions" enabled
> I set a breakpoint right before calling the function that triggers the
> crash, enabled logging, then continued. I was trying to reduce the amount
> of log output to sift through.
>
> This was run with the Swift 4.0 release version
> Let me know if you want me to try anything else.
>
> Thanks, Ed
>
>
>
> On Thu, Oct 12, 2017 at 11:13 AM, Michael Gottesman <mgottes...@apple.com>
> wrote:
>
>> I just added a section to ./docs/DebuggingTheCompiler.rst on how to get
>> enable logging from LLDB.
>>
>> Can you enable the logging there and add file an SR?
>>
>> Michael
>>
>> On Oct 7, 2017, at 11:27 AM, Edward Connell <ewconn...@gmail.com> wrote:
>>
>> Hi Michael,
>> No I am not evaluating an expression or anything. This all worked fine in
>> past builds.
>>
>> I simply set a breakpoint in a function and after stopping while
>> gathering values for the debugger view, it crashes.
>>
>> It doesn't crash in all functions, but it does crash when trying to stop
>> in many different functions.
>> An example function signature where it crashes is (DataView is a concrete
>> struct):
>>
>> public func setupForward(mode: EvaluationMode, inData: DataView, labels:
>> DataView?,
>>  outData: inout DataView, backData: inout
>> DataView?) throws { ... }
>>
>> Before calling the function, all of the parameters have valid values that
>> I can examine. But as soon as I step into this function, LLDB crashes with
>> that message. It behaves the same way with other functions that have
>> different signatures.
>>
>> I tried to create a very simple repro case using this signature, but it
>> didn't crash. My project is on GitHub and this can be easily reproduced.
>> The only pain is installing my project on your test machine.
>>
>> Ubuntu 16.04
>> Swift 4.0 release
>> NVidia gpu
>> Netlib https://github.com/ewconnell/Netlib/wiki#installation
>> CLion IDE with Swift plugin
>>
>> 1) do a debug build
>> 2) set a breakpoint at CudaSoftmax.swift:44  or any line in the function
>> 3) run
>> 4) when it stops LLDBFrontend crashes
>>
>> *LLDBFrontend:
>> /home/buildnode/jenkins/workspace/oss-swift-4.0-package-linux-ubuntu-16_04/swift/lib/SILOptimizer/Mandatory/AccessEnforcementSelection.cpp:613:
>> (anonymous namespace)::SourceAccess (anonymous
>> namespace)::AccessEnforcementSelection::getSourceAccess(swift::SILValue):
>> Assertion `isa(address) || isa(address)' failed.*
>> *Stack dump:*
>> *0. While running pass #10 SILModuleTransform ""Access Enforcement
>> Selection"".*
>>
>>
>> Using the LLDB CLI I am able to stop there. If I try "fr var -O" with
>>
>>- mode, inData, and labels, it prints their values no problem
>>- outData and backData gives me a segmentation violation
>>
>> The visible difference is the "inout"
>>
>> Not sure what the problem is. It worked fine in the past.
>>
>> If you can think of an experiment I can try to create a simple repro
>> case, please let me know.
>>
>> Thanks, Ed
>>
>> On Fri, Oct 6, 2017 at 4:34 PM, Michael Gottesman <mgottes...@apple.com>
>> wrote:
>>
>>> It looks like this is failing during guaranteed optimization. Are you
>>> running an expression in the debugger and we are crashing there?
>>>
>>> Michael
>>>
>>> On Oct 6, 2017, at 11:53 AM, Edward Connell via swift-users <
>>> swift-users@swift.org> wrote:
>>>
>>> While trying to debug a Netlib function, LLDB is crashing
>>>
>>> I'm not sure what this assert means.
>>>
>>> *LLDBFrontend:
>>> /home/buildnode/jenkins/workspace/oss-swift-4.0-package-linux-ubuntu-16_04/swi

Re: [swift-users] Swift 4.0 LLDBFrontend Crash

[Edward Connell via swift-users]

Hi Michael,
Thanks, I created and attached a log for you with "types" and "expressions"
enabled
I set a breakpoint right before calling the function that triggers the
crash, enabled logging, then continued. I was trying to reduce the amount
of log output to sift through.

This was run with the Swift 4.0 release version
Let me know if you want me to try anything else.

Thanks, Ed



On Thu, Oct 12, 2017 at 11:13 AM, Michael Gottesman <mgottes...@apple.com>
wrote:

> I just added a section to ./docs/DebuggingTheCompiler.rst on how to get
> enable logging from LLDB.
>
> Can you enable the logging there and add file an SR?
>
> Michael
>
> On Oct 7, 2017, at 11:27 AM, Edward Connell <ewconn...@gmail.com> wrote:
>
> Hi Michael,
> No I am not evaluating an expression or anything. This all worked fine in
> past builds.
>
> I simply set a breakpoint in a function and after stopping while gathering
> values for the debugger view, it crashes.
>
> It doesn't crash in all functions, but it does crash when trying to stop
> in many different functions.
> An example function signature where it crashes is (DataView is a concrete
> struct):
>
> public func setupForward(mode: EvaluationMode, inData: DataView, labels:
> DataView?,
>  outData: inout DataView, backData: inout
> DataView?) throws { ... }
>
> Before calling the function, all of the parameters have valid values that
> I can examine. But as soon as I step into this function, LLDB crashes with
> that message. It behaves the same way with other functions that have
> different signatures.
>
> I tried to create a very simple repro case using this signature, but it
> didn't crash. My project is on GitHub and this can be easily reproduced.
> The only pain is installing my project on your test machine.
>
> Ubuntu 16.04
> Swift 4.0 release
> NVidia gpu
> Netlib https://github.com/ewconnell/Netlib/wiki#installation
> CLion IDE with Swift plugin
>
> 1) do a debug build
> 2) set a breakpoint at CudaSoftmax.swift:44  or any line in the function
> 3) run
> 4) when it stops LLDBFrontend crashes
>
> *LLDBFrontend:
> /home/buildnode/jenkins/workspace/oss-swift-4.0-package-linux-ubuntu-16_04/swift/lib/SILOptimizer/Mandatory/AccessEnforcementSelection.cpp:613:
> (anonymous namespace)::SourceAccess (anonymous
> namespace)::AccessEnforcementSelection::getSourceAccess(swift::SILValue):
> Assertion `isa(address) || isa(address)' failed.*
> *Stack dump:*
> *0. While running pass #10 SILModuleTransform ""Access Enforcement
> Selection"".*
>
>
> Using the LLDB CLI I am able to stop there. If I try "fr var -O" with
>
>- mode, inData, and labels, it prints their values no problem
>- outData and backData gives me a segmentation violation
>
> The visible difference is the "inout"
>
> Not sure what the problem is. It worked fine in the past.
>
> If you can think of an experiment I can try to create a simple repro case,
> please let me know.
>
> Thanks, Ed
>
> On Fri, Oct 6, 2017 at 4:34 PM, Michael Gottesman <mgottes...@apple.com>
> wrote:
>
>> It looks like this is failing during guaranteed optimization. Are you
>> running an expression in the debugger and we are crashing there?
>>
>> Michael
>>
>> On Oct 6, 2017, at 11:53 AM, Edward Connell via swift-users <
>> swift-users@swift.org> wrote:
>>
>> While trying to debug a Netlib function, LLDB is crashing
>>
>> I'm not sure what this assert means.
>>
>> *LLDBFrontend:
>> /home/buildnode/jenkins/workspace/oss-swift-4.0-package-linux-ubuntu-16_04/swift/lib/SILOptimizer/Mandatory/AccessEnforcementSelection.cpp:613:
>> (anonymous namespace)::SourceAccess (anonymous
>> namespace)::AccessEnforcementSelection::getSourceAccess(swift::SILValue):
>> Assertion `isa(address) || isa(address)' failed.*
>> *Stack dump:*
>> *0. While running pass #10 SILModuleTransform ""Access Enforcement
>> Selection"".*
>>
>> It fails every time and the same way in several functions, but not all
>> functions.
>> I tried to create a simple repro with the same function signature, but I
>> can't get the simple case to fail.
>> A debug build isn't doing whole-module-optimization, so that's not it
>>
>> Ideas anyone?
>>
>> Who owns the LLDBFrontend?
>>
>> Thanks, Ed
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
>>
>>
>>
>
>


lldb-log.txt.tar.gz
Description: GNU Zip compressed data
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Swift 4.0 LLDBFrontend Crash

[Edward Connell via swift-users]

Hi Michael,
No I am not evaluating an expression or anything. This all worked fine in
past builds.

I simply set a breakpoint in a function and after stopping while gathering
values for the debugger view, it crashes.

It doesn't crash in all functions, but it does crash when trying to stop in
many different functions.
An example function signature where it crashes is (DataView is a concrete
struct):

public func setupForward(mode: EvaluationMode, inData: DataView, labels:
DataView?,
 outData: inout DataView, backData: inout
DataView?) throws { ... }

Before calling the function, all of the parameters have valid values that I
can examine. But as soon as I step into this function, LLDB crashes with
that message. It behaves the same way with other functions that have
different signatures.

I tried to create a very simple repro case using this signature, but it
didn't crash. My project is on GitHub and this can be easily reproduced.
The only pain is installing my project on your test machine.

Ubuntu 16.04
Swift 4.0 release
NVidia gpu
Netlib https://github.com/ewconnell/Netlib/wiki#installation
CLion IDE with Swift plugin

1) do a debug build
2) set a breakpoint at CudaSoftmax.swift:44  or any line in the function
3) run
4) when it stops LLDBFrontend crashes

*LLDBFrontend:
/home/buildnode/jenkins/workspace/oss-swift-4.0-package-linux-ubuntu-16_04/swift/lib/SILOptimizer/Mandatory/AccessEnforcementSelection.cpp:613:
(anonymous namespace)::SourceAccess (anonymous
namespace)::AccessEnforcementSelection::getSourceAccess(swift::SILValue):
Assertion `isa(address) || isa(address)' failed.*
*Stack dump:*
*0. While running pass #10 SILModuleTransform ""Access Enforcement
Selection"".*


Using the LLDB CLI I am able to stop there. If I try "fr var -O" with

   - mode, inData, and labels, it prints their values no problem
   - outData and backData gives me a segmentation violation

The visible difference is the "inout"

Not sure what the problem is. It worked fine in the past.

If you can think of an experiment I can try to create a simple repro case,
please let me know.

Thanks, Ed

On Fri, Oct 6, 2017 at 4:34 PM, Michael Gottesman <mgottes...@apple.com>
wrote:

> It looks like this is failing during guaranteed optimization. Are you
> running an expression in the debugger and we are crashing there?
>
> Michael
>
> On Oct 6, 2017, at 11:53 AM, Edward Connell via swift-users <
> swift-users@swift.org> wrote:
>
> While trying to debug a Netlib function, LLDB is crashing
>
> I'm not sure what this assert means.
>
> *LLDBFrontend:
> /home/buildnode/jenkins/workspace/oss-swift-4.0-package-linux-ubuntu-16_04/swift/lib/SILOptimizer/Mandatory/AccessEnforcementSelection.cpp:613:
> (anonymous namespace)::SourceAccess (anonymous
> namespace)::AccessEnforcementSelection::getSourceAccess(swift::SILValue):
> Assertion `isa(address) || isa(address)' failed.*
> *Stack dump:*
> *0. While running pass #10 SILModuleTransform ""Access Enforcement
> Selection"".*
>
> It fails every time and the same way in several functions, but not all
> functions.
> I tried to create a simple repro with the same function signature, but I
> can't get the simple case to fail.
> A debug build isn't doing whole-module-optimization, so that's not it
>
> Ideas anyone?
>
> Who owns the LLDBFrontend?
>
> Thanks, Ed
> ___
> 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] Using libdispatch with Trunk Development snapshot

[Edward Connell via swift-users]

$ find ~/swift -name "*dispatch*"
/home/ed/swift/usr/lib/swift/linux/libdispatch.la
/home/ed/swift/usr/lib/swift/linux/libdispatch.so
/home/ed/swift/usr/lib/swift/dispatch
/home/ed/swift/usr/lib/swift/dispatch/dispatch.h


On Sat, Oct 7, 2017 at 9:51 AM, Lane Schwartz  wrote:

> Edward,
>
> Could you please try running this command wherever your swift-DEVELOPMENT*
> directory is located?
>
> find swift-DEVELOPMENT-SNAPSHOT-* -name "*dispatch*"
>
> Thanks,
> Lane
>
>
>
>
> On Sat, Oct 7, 2017 at 11:47 AM, Edward Connell 
> wrote:
>
>> No I installed it yesterday so 10/5 was the current one
>>
>> On Sat, Oct 7, 2017 at 9:36 AM, Lane Schwartz  wrote:
>>
>>> Do you mean 10/6? I don't see a 10/5 build.
>>>
>>> On Sat, Oct 7, 2017 at 11:26 AM, Edward Connell 
>>> wrote:
>>>
 I had the same problem with the 9/30 build, but the 10/5 build worked
 for me.

 On Sat, Oct 7, 2017 at 9:21 AM, Alex Blewitt via swift-users <
 swift-users@swift.org> wrote:

> This sounds like a bug. There were some changes recently to migrate
> the build towards CMake and it may be that they have broken the build
> accordingly.
>
> Since I can't find one, can you create a bug at https://bugs.swift.org
> with the snapshot build that you saw the issue is?
>
> Alex
>
> > On 7 Oct 2017, at 17:08, Lane Schwartz via swift-users <
> swift-users@swift.org> wrote:
> >
> > Hi,
> >
> > I'm on Ubuntu 16, and I'd like to try out the current Trunk
> Development snapshot. I successfully downloaded and installed it. But when
> I tried compiling my sample program with it, I got an error that
> libdispatch wasn't available.
> >
> > I looked in the directory, and sure enough, the development
> snapshots do not appear to include libdispatch. Is this intentional? What
> is the recommended mechanism for getting libdispatch when using the Trunk
> Development snapshots?
> >
> > Thanks,
> > Lane
> >
> > ___
> > 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
>


>>>
>>>
>>> --
>>> When a place gets crowded enough to require ID's, social collapse is not
>>> far away.  It is time to go elsewhere.  The best thing about space travel
>>> is that it made it possible to go elsewhere.
>>> -- R.A. Heinlein, "Time Enough For Love"
>>>
>>
>>
>
>
> --
> When a place gets crowded enough to require ID's, social collapse is not
> far away.  It is time to go elsewhere.  The best thing about space travel
> is that it made it possible to go elsewhere.
> -- R.A. Heinlein, "Time Enough For Love"
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Using libdispatch with Trunk Development snapshot

[Edward Connell via swift-users]

No I installed it yesterday so 10/5 was the current one

On Sat, Oct 7, 2017 at 9:36 AM, Lane Schwartz  wrote:

> Do you mean 10/6? I don't see a 10/5 build.
>
> On Sat, Oct 7, 2017 at 11:26 AM, Edward Connell 
> wrote:
>
>> I had the same problem with the 9/30 build, but the 10/5 build worked for
>> me.
>>
>> On Sat, Oct 7, 2017 at 9:21 AM, Alex Blewitt via swift-users <
>> swift-users@swift.org> wrote:
>>
>>> This sounds like a bug. There were some changes recently to migrate the
>>> build towards CMake and it may be that they have broken the build
>>> accordingly.
>>>
>>> Since I can't find one, can you create a bug at https://bugs.swift.org
>>> with the snapshot build that you saw the issue is?
>>>
>>> Alex
>>>
>>> > On 7 Oct 2017, at 17:08, Lane Schwartz via swift-users <
>>> swift-users@swift.org> wrote:
>>> >
>>> > Hi,
>>> >
>>> > I'm on Ubuntu 16, and I'd like to try out the current Trunk
>>> Development snapshot. I successfully downloaded and installed it. But when
>>> I tried compiling my sample program with it, I got an error that
>>> libdispatch wasn't available.
>>> >
>>> > I looked in the directory, and sure enough, the development snapshots
>>> do not appear to include libdispatch. Is this intentional? What is the
>>> recommended mechanism for getting libdispatch when using the Trunk
>>> Development snapshots?
>>> >
>>> > Thanks,
>>> > Lane
>>> >
>>> > ___
>>> > 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
>>>
>>
>>
>
>
> --
> When a place gets crowded enough to require ID's, social collapse is not
> far away.  It is time to go elsewhere.  The best thing about space travel
> is that it made it possible to go elsewhere.
> -- R.A. Heinlein, "Time Enough For Love"
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Using libdispatch with Trunk Development snapshot

[Edward Connell via swift-users]

I had the same problem with the 9/30 build, but the 10/5 build worked for
me.

On Sat, Oct 7, 2017 at 9:21 AM, Alex Blewitt via swift-users <
swift-users@swift.org> wrote:

> This sounds like a bug. There were some changes recently to migrate the
> build towards CMake and it may be that they have broken the build
> accordingly.
>
> Since I can't find one, can you create a bug at https://bugs.swift.org
> with the snapshot build that you saw the issue is?
>
> Alex
>
> > On 7 Oct 2017, at 17:08, Lane Schwartz via swift-users <
> swift-users@swift.org> wrote:
> >
> > Hi,
> >
> > I'm on Ubuntu 16, and I'd like to try out the current Trunk Development
> snapshot. I successfully downloaded and installed it. But when I tried
> compiling my sample program with it, I got an error that libdispatch wasn't
> available.
> >
> > I looked in the directory, and sure enough, the development snapshots do
> not appear to include libdispatch. Is this intentional? What is the
> recommended mechanism for getting libdispatch when using the Trunk
> Development snapshots?
> >
> > Thanks,
> > Lane
> >
> > ___
> > 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

[swift-users] Swift 4.0 LLDBFrontend Crash

[Edward Connell via swift-users]

While trying to debug a Netlib function, LLDB is crashing

I'm not sure what this assert means.

*LLDBFrontend:
/home/buildnode/jenkins/workspace/oss-swift-4.0-package-linux-ubuntu-16_04/swift/lib/SILOptimizer/Mandatory/AccessEnforcementSelection.cpp:613:
(anonymous namespace)::SourceAccess (anonymous
namespace)::AccessEnforcementSelection::getSourceAccess(swift::SILValue):
Assertion `isa(address) || isa(address)' failed.*
*Stack dump:*
*0. While running pass #10 SILModuleTransform ""Access Enforcement
Selection"".*

It fails every time and the same way in several functions, but not all
functions.
I tried to create a simple repro with the same function signature, but I
can't get the simple case to fail.
A debug build isn't doing whole-module-optimization, so that's not it

Ideas anyone?

Who owns the LLDBFrontend?

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

Re: [swift-users] Netlib

[Edward Connell via swift-users]

Hi Vladimir,
To answer your questions:

1) The framework is designed to allow the easy creation of models for
training and inference. The framework is intended to be used both for
training and deployment on all platforms.

2) Yes currently only the CudaComputeService is implemented. I am only one
guy, and I didn't have the resources to implement other service types such
as Metal.

3) The same Swift code should run on iOS, if a compute service is provided
such as Metal.

I started this project when only Caffe1 existed and was hoping Apple would
be interested in my work.
While I was working on the project, Microsoft, Google, Facebook, and Amazon
invested literally thousands of man years of effort into their own
frameworks. My code is still significantly faster, but without a major
investment there is no way one guy can compete anymore. There is also no
good financial reason for an investment now, because the competing products
are free.

Apple bought Turi and is now using CoreML for deployment and private
training tools from the Turi acquisition.
At this point from a business point of view, it doesn't make sense for me
to add any more to this code base. That is why I made it publicly available
and hope it will help others.

Who knows, perhaps maybe someone will offer me an interesting job :)

Today I would suggest that if you are trying to deploy on iOS, use Caffe2
for training and CoreML for deployment. CoreML has a converter from Caffe2
to CoreML to make it easy for you.

In a side mail you mentioned that you hate Python. I don't much like python
either, and I see a lot of benefits of a pure Swift solution, particularly
for the ability to directly connect to all of the Apple UI libraries to
create advanced visualization apps.
Unfortunately all of the major toolkits are using python, including the
internal Turi tools. You can use Caffe2's C++ API if you prefer, but it's
probably in your best interest to just live with the python way of doing
things for now.

The core of all the major frameworks are written in C++, so I think the
reason python was chosen is it is much easier than C++ for running
experiments and visualization. Unfortunately deployment was an after
thought for most of the frameworks. In the Caffe2 rewrite, they made more
of an effort.

On a side note, Microsoft's CNTK defined something called BrainScript for
defining models. It appears to be very clean, concise, and superior to
python. They did a nice job. However, I read in some forums that they are
thinking of phasing it out, because the community just wants to use python.
So a better technical solution is not always the best business decision.

Good luck, Ed

On Tue, Oct 3, 2017 at 11:38 AM, Vladimir.S <sva...@gmail.com> wrote:

> On 03.10.2017 19:02, Edward Connell via swift-users wrote:
>
>> Hi All,
>> Sorry something strange happened with the first post, so I am reposting
>> this.
>>
>> I've recently wrapped up an ML framework research project that I've been
>> working on for some time.
>> It addresses a lot of difficult design problems, and works around a lot
>> of compiler bugs and Linux library deficiencies.
>>
>> It's written almost entirely in Swift 4.0 with some C and Cuda kernels.
>> Development and testing were done primarily on Ubuntu 16.04, but it will
>> also build on MacOS.
>> Linux was the primary environment, because there aren't any modern Macs
>> that can host big NVIDIA hardware
>>
>> The framework interfaces with many common C libraries such as: *Cuda,
>> cuDNN, lmdb, png, jpeg, zlib*
>>
>> Anyone in the community that is trying to work with these libraries might
>> benefit from the Swift wrapper classes and examples of successful use.
>> There are other isolated technology pieces that might be of use also.
>>
>> Other people's projects and examples helped me along the way, so I am
>> hoping that my work will help some of you as well.
>>
>> The code and overview docs are published on GitHub
>>
>> docs: https://github.com/ewconnell/Netlib/wiki <
>> https://github.com/ewconnell/Netlib/wiki>
>> code: https://github.com/ewconnell/Netlib <https://github.com/ewconnell/
>> Netlib>
>>
>>
> Ed, it looks awesome! :-) Thank you for doing this and for sharing this!
>
> I'm a beginner in ML world, so could you clarify some points please:
>
> 1. Do I understand correctly, that main purpose of your library is to
> train the model? So, then we can export structure(connections) and
> use them where we need? Or also the purpose is efficient 'calculation' of
> trained model on Mac/Linux, so this could be used in production apps?
>
> 2. Currently this library has only Cuda compute service implemented,
> right? Do you plan to implemen

[swift-users] Netlib

[Edward Connell via swift-users]

Hi All,
Sorry something strange happened with the first post, so I am reposting
this.

I've recently wrapped up an ML framework research project that I've been
working on for some time.
It addresses a lot of difficult design problems, and works around a lot of
compiler bugs and Linux library deficiencies.

It's written almost entirely in Swift 4.0 with some C and Cuda kernels.
Development and testing were done primarily on Ubuntu 16.04, but it will
also build on MacOS.
Linux was the primary environment, because there aren't any modern Macs
that can host big NVIDIA hardware

The framework interfaces with many common C libraries such as: *Cuda,
cuDNN, lmdb, png, jpeg, zlib*

Anyone in the community that is trying to work with these libraries might
benefit from the Swift wrapper classes and examples of successful use.
There are other isolated technology pieces that might be of use also.

Other people's projects and examples helped me along the way, so I am
hoping that my work will help some of you as well.

The code and overview docs are published on GitHub

docs: https://github.com/ewconnell/Netlib/wiki
code: https://github.com/ewconnell/Netlib

Happy coding, Ed :)
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] Netlib now on GitHub

[Edward Connell via swift-users]

Hi All,
I've recently wrapped up an ML framework research project that I've been
working on for some time.
It addresses a lot of difficult design problems, and works around a lot of
compiler bugs and Linux library deficiencies.

It's written almost entirely in Swift 4.0 with some C and Cuda kernels.
Development and testing were done primarily on Ubuntu 16.04, but it will
also build on MacOS.
Linux was the primary environment, because there aren't any modern Macs
that can host big NVIDIA hardware

The framework interfaces with many common C libraries such as: *Cuda,
cuDNN, lmdb, png, jpeg, zlib*

Anyone in the community that is trying to work with these libraries might
benefit from the Swift wrapper classes and examples of successful use.
There are other isolated technology pieces that might be of use also.

Other people's projects and examples helped me along the way, so I am
hoping that my work will help some of you as well.

The code and overview docs are published on GitHub

docs: https://github.com/ewconnell/Netlib/wiki
code: https://github.com/ewconnell/Netlib

Happy coding, Ed :)
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Using #function causes big memory leak

[Edward Connell via swift-users]

I reported it 5/16 in bug reporter. Possibly that was the wrong DB?

https://bugreport.apple.com/web/?problemID=26535526


On Mon, Aug 28, 2017 at 8:45 AM, Joe Groff <jgr...@apple.com> wrote:

>
> > On Aug 27, 2017, at 10:57 AM, Edward Connell via swift-users <
> swift-users@swift.org> wrote:
> >
> > import Foundation
> >
> > class A {
> >   var counter = 0 {
> > //didSet { onSet("counter") }  // no leak
> >   didSet { onSet() }  // huge leak
> >   }
> >
> >   var properties = ["counter" : 0]
> >   func onSet(_ name: String = #function) {
> >   properties[name]! += 1
> >   }
> > }
> >
> > var myclass = A()
> >
> > for i in 0..<1000 {
> >   myclass.counter = i
> > }
> >
> > print(myclass.properties["counter"]!)
>
> The only code generation difference I see, if I modify your didSet to make
> both calls is that the compiler treats #function as a UTF-16 literal,
> whereas "counter" is recognized as an ASCII literal:
>
> // A.counter.didset
> sil hidden @_T03foo1AC7counterSifW : $@convention(method) (Int,
> @guaranteed A) -> () {
> // %0 // user: %2
> // %1 // users: %19, %12, %11,
> %4, %3
> bb0(%0 : $Int, %1 : $A):
>   debug_value %0 : $Int, let, name "oldValue", argno 1 // id: %2
>   debug_value %1 : $A, let, name "self", argno 2  // id: %3
>   %4 = class_method %1 : $A, #A.onSet!1 : (A) -> (String) -> (),
> $@convention(method) (@owned String, @guaranteed A) -> () // user: %11
>   %5 = string_literal utf8 "counter"  // user: %10
>   %6 = integer_literal $Builtin.Word, 7   // user: %10
>   %7 = integer_literal $Builtin.Int1, -1  // user: %10
>   %8 = metatype $@thin String.Type// user: %10
>   // function_ref String.init(_builtinStringLiteral:
> utf8CodeUnitCount:isASCII:)
>   %9 = function_ref @_T0S2SBp21_builtinStringLiteral_
> Bw17utf8CodeUnitCountBi1_7isASCIItcfC : $@convention(method)
> (Builtin.RawPointer, Builtin.Word, Builtin.Int1, @thin String.Type) ->
> @owned String // user: %10
>   %10 = apply %9(%5, %6, %7, %8) : $@convention(method)
> (Builtin.RawPointer, Builtin.Word, Builtin.Int1, @thin String.Type) ->
> @owned String // user: %11
>   %11 = apply %4(%10, %1) : $@convention(method) (@owned String,
> @guaranteed A) -> ()
>   %12 = class_method %1 : $A, #A.onSet!1 : (A) -> (String) -> (),
> $@convention(method) (@owned String, @guaranteed A) -> () // user: %19
>   %13 = string_literal utf16 "counter"// user: %18
>   %14 = integer_literal $Builtin.Word, 7  // user: %18
>   %15 = integer_literal $Builtin.Int1, -1
>   %16 = metatype $@thin String.Type   // user: %18
>   // function_ref String.init(_builtinUTF16StringLiteral:
> utf16CodeUnitCount:)
>   %17 = function_ref 
> @_T0S2SBp26_builtinUTF16StringLiteral_Bw18utf16CodeUnitCounttcfC
> : $@convention(method) (Builtin.RawPointer, Builtin.Word, @thin
> String.Type) -> @owned String // user: %18
>   %18 = apply %17(%13, %14, %16) : $@convention(method)
> (Builtin.RawPointer, Builtin.Word, @thin String.Type) -> @owned String //
> user: %19
>   %19 = apply %12(%18, %1) : $@convention(method) (@owned String,
> @guaranteed A) -> ()
>   %20 = tuple ()  // user: %21
>   return %20 : $()// id: %21
> } // end sil function '_T03foo1AC7counterSifW'
>
> Michael, could there be a leak in the implementation of String(_
> builtinUTF16StringLiteral:utf16CodeUnitCount:)? The SIL at first glance
> looks balanced here.
>
> -Joe
>
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Using #function causes big memory leak

[Edward Connell via swift-users]

Hi Peter, thanks for taking a look.

I would expect the compiler should generate a read only static string with
the name of the function whenever the #function directive is used. I would
expect that should not cause a leak.

If I modify the onSet function to replace a static string as the default
value instead of using #function, there is no leak, so this seems like a
bug to me.

Anyone have other ideas or opinions on this?

Thanks, Ed


import Foundation

class A {
var counter = 0 {
// didSet { onSet("counter") }  // no leak
didSet { onSet() }  // huge leak
}

var properties = ["counter" : 0]
// func onSet(_ name: String = #function) { // leaks
// properties[name]! += 1
// }
func onSet(_ name: String = "counter") {  // no leak
properties[name]! += 1
}
}

var myclass = A()

for i in 0..<1000 {
myclass.counter = i
}

print(myclass.properties["counter"]!)


On Sun, Aug 27, 2017 at 6:59 PM, Peter Nicholls <
swiftu...@peternicholls.co.uk> wrote:

> I looked in to the memory alloc and every time the “leak” iterates it’s
> creating an string item on the auto release stack with “counter” - a few
> million of them, compared to just 1 string on the non- leak. It is also
> quite a lot slower than the non leak version.
>
> I looked at the compiled assembly intermediate and at allocation the only
> difference is that the non-leak allocates via a register and is just a
> byte, but the leak uses a memory pointer is a word and is _unnammed_.
>
> My thought is that this isn’t a bug at all, it’s how the compiler deals
> with an unnamed #function and thus infers _name.
>
> As i trawled through the assembly seemed to me the non leak is making
> efficient use of the registers, through the named #function / _name, where
> as the leak version is using actual memory (hence why it is so much slower)
> with a view to destroying the autocomplete stack (of 9million odd auto
> release objects at 8bytes at a time) when completed. You can see how the
> memory stacks!
>
> Now. As to why and IF Swift is INTENDED to do this, or if indeed you’re
> doing something unintended too I cannot say.
>
> If any of the above is incorrect, please chime in.
>
> Peter Nicholls
> First time post.
>
> > On 27 Aug 2017, at 18:56, Edward Connell via swift-users <
> swift-users@swift.org> wrote:
> >
> > I reported this about a year ago, but it has never been fixed and it
> seems like it should be fixed for the Swift 4.0 release.
> >
> > Here is a simple repro case. If you watch the memory monitor as it runs,
> you see memory consumption climb to 2.7GB when using #function, and no
> memory increase when using a static string.
> >
> > import Foundation
> >
> > class A {
> >   var counter = 0 {
> > //didSet { onSet("counter") }  // no leak
> >   didSet { onSet() }  // huge leak
> >   }
> >
> >   var properties = ["counter" : 0]
> >   func onSet(_ name: String = #function) {
> >   properties[name]! += 1
> >   }
> > }
> >
> > var myclass = A()
> >
> > for i in 0..<1000 {
> >   myclass.counter = i
> > }
> >
> > print(myclass.properties["counter"]!)
> >
> > ___
> > 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] Using #function causes big memory leak

[Edward Connell via swift-users]

I reported this about a year ago, but it has never been fixed and it seems
like it should be fixed for the Swift 4.0 release.

Here is a simple repro case. If you watch the memory monitor as it runs,
you see memory consumption climb to 2.7GB when using #function, and no
memory increase when using a static string.

import Foundation

class A {
var counter = 0 {
// didSet { onSet("counter") }  // no leak
didSet { onSet() }  // huge leak
}

var properties = ["counter" : 0]
func onSet(_ name: String = #function) {
properties[name]! += 1
}
}

var myclass = A()

for i in 0..<1000 {
myclass.counter = i
}

print(myclass.properties["counter"]!)
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] LLDB Frontend crash

[Edward Connell via swift-users]

I have been blocked for several weeks with this LLDB crashing bug, but it
has not been assigned to anyone.
I'm providing repro steps with the LLDB CLI in order to remove any
possibility that it is caused by my IDE. I have had this independently
confirmed by one of the CLion engineers.

I logged the bug: https://bugs.swift.org/browse/SR-5226

I would really appreciate this being fixed so my development can continue.

thanks, Ed


Here is a simple 6 line repro

struct SomeStruct { }

func fetch(outputData: inout SomeStruct?) {
outputData = SomeStruct()
}

var outData: SomeStruct?

fetch(outputData: )

-

1) build the project as HelloWorld (or whatever you like)
2) then from the LLDB CLI, set a breakpoint on line 5 and run
3) then examine outputData:  fr var -O outputData


This is the session output
--

$ lldb HelloWorld
(lldb) target create "HelloWorld"
Current executable set to 'HelloWorld' (x86_64).
(lldb) br se --file main.swift --line 5
Breakpoint 1: where = HelloWorld`HelloWorld.fetch(outputData: inout
Swift.Optional) -> () + 28 at main.swift:5, address
= 0x00400b6c
(lldb) r
Process 14669 launched:
'/home/ed/CLionProjects/untitled1/.build/debug/HelloWorld' (x86_64)
Process 14669 stopped

   - thread #1, name = 'HelloWorld', stop reason = breakpoint 1.1
   frame #0: 0x00400b6c HelloWorld`fetch(outputData=some) at
   main.swift:5
   2
   3 func fetch(outputData: inout SomeStruct?) { 4 outputData =
   SomeStruct() -> 5 }

   6
   7 var outData: SomeStruct?
   8
   Target 0: (HelloWorld) stopped.
   (lldb) fr var -O outputData
   lldb:
   
/home/buildnode/disk2/workspace/oss-swift-4.0-package-linux-ubuntu-16_04/swift/lib/SIL/TypeLowering.cpp:1693:
   const swift::Lowering::TypeLowering
   
::Lowering::TypeConverter::getTypeLoweringForUncachedLoweredType(swift::Lowering::TypeConverter::TypeKey):
   Assertion `key.SubstType->isLegalSILType() && "type is not already
   lowered"' failed.
   Stack dump:
   0. HandleCommand(command = "fr var -O outputData")
   Aborted (core dumped)
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] Is "lazy let" on the schedule anywhere?

[Edward Connell via swift-users]

It sure would be nice if the compiler supported lazy lets for structs. Any
idea when or if this will be supported?

Seems like a nice performance win, lazy var is a pain because you can't
access arguments passed into a function without mutation complaints.

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

[swift-users] lldb failure with Swift 4.0 on Ubuntu 16.04

[Edward Connell via swift-users]

I installed the June 7th Ubuntu 16.04 release and performed a clean build
with no problems.

However when I try to debug I get the following error, and then LLDB
terminates.

*LLDBFrontend:
/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-16_04/swift/lib/SIL/TypeLowering.cpp:1693:
const swift::Lowering::TypeLowering
::Lowering::TypeConverter::getTypeLoweringForUncachedLoweredType(swift::Lowering::TypeConverter::TypeKey):
Assertion `key.SubstType->isLegalSILType() && "type is not already
lowered"' failed.*

I installed the June 9th snapshot and it has the same problem. I tested
both Swift 3.1.1 and Swift 4.0 modes, but it fails the same way for both.

Anyone else see this problem?? Any ideas??

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

Re: [swift-users] arc4random_uniform on Linux is missing from Foundation??

[Edward Connell via swift-users]

Thank you for all the feedback and options. In further investigation, I
also ran across the family of xx48 rngs, which appear to be on both
platforms. They claim to be uniformly distributed.

drand48, erand48, jrand48, lcong48, lrand48, mrand48, nrand48, seed48,
srand48

http://pubs.opengroup.org/onlinepubs/007908775/xsh/drand48.html

Any reason not to use one of these instead?

Thanks, Ed

On Tue, May 23, 2017 at 3:18 AM, Jens Persson <j...@bitcycle.com> wrote:

> Here's a stripped down verison of my implementation of the Xoroshiro128+
> PRNG:
> https://gist.github.com/anonymous/527602968812f853d6147aea8c66d660
>
> /Jens
>
>
> On Mon, May 22, 2017 at 11:21 PM, Jens Persson <j...@bitcycle.com> wrote:
>
>> Sorry for the premature send ...
>> Here is the site: http://xoroshiro.di.unimi.it
>> There is also a section there about "generating uniform doubles in unit
>> interval" which is worth reading.
>> And here's how to get uniform floating point values in the range [0, 1)
>> from various (supposedly) random bit patterns:
>>
>> extension Double {
>>
>> init(unitRange v: UInt64) {
>>
>> let shifts: UInt64 = 63 - UInt64(Double.significandBitCount)
>>
>> self = Double(v >> shifts) * (.ulpOfOne/2)
>>
>> }
>>
>> init(unitRange v: UInt32) {
>>
>> self = (Double(v) + 0.5) / (Double(UInt32.max) + 1.0)
>>
>> }
>>
>> init(unitRange v: UInt16) {
>>
>> self = (Double(v) + 0.5) / (Double(UInt16.max) + 1.0)
>>
>> }
>>
>> init(unitRange v: UInt8) {
>>
>> self = (Double(v) + 0.5) / (Double(UInt8.max) + 1.0)
>>
>> }
>>
>> }
>>
>> extension Float {
>>
>> init(unitRange v: UInt64) {
>>
>> let shifts: UInt64 = 63 - UInt64(Float.significandBitCount)
>>
>> self = Float(v >> shifts) * (.ulpOfOne/2)
>>
>> }
>>
>> init(unitRange v: UInt32) {
>>
>> let shifts: UInt32 = 31 - UInt32(Float.significandBitCount)
>>
>> self = Float(v >> shifts) * (.ulpOfOne/2)
>>
>> }
>>
>> init(unitRange v: UInt16) {
>>
>> let a = Float(v) + 0.5
>>
>> let b = Float(UInt16.max) + 1.0
>>
>> self = a / b
>>
>> }
>>
>> init(unitRange v: UInt8) {
>>
>> let a = Float(v) + 0.5
>>
>> let b = Float(UInt8.max) + 1.0
>>
>> self = a / b
>>
>> }
>>
>> }
>>
>>
>> You will get a very fast and good quality prng using xoroshiro,
>> converting to unit range floating point and then back to uniform range int
>> if you want to, much much faster than arc4random.
>>
>>
>> /Jens
>>
>>
>>
>>
>>
>> On Mon, May 22, 2017 at 11:17 PM, Jens Persson <j...@bitcycle.com> wrote:
>>
>>> Check out the generators (especially xoroshiro) on this site:
>>>
>>> On Mon, May 22, 2017 at 6:54 PM, Saagar Jha via swift-users <
>>> swift-users@swift.org> wrote:
>>>
>>>>
>>>> Saagar Jha
>>>>
>>>> On May 22, 2017, at 08:44, Edward Connell via swift-users <
>>>> swift-users@swift.org> wrote:
>>>>
>>>> Any ideas when Foundation on Linux will support arc4random_uniform?
>>>> This is kind of an important function.
>>>> There doesn't seem to be any decent substitute without requiring the
>>>> installation of libbsd-dev, which turns out to be messy. Currently I am
>>>> doing this, but glibc random with mod does not produce good quality
>>>> numbers, due to modulo bias.
>>>>
>>>>
>>>> Modulo bias is easy to deal with, though, if you force random to
>>>> produce a range that is a multiple of the range that you’re trying to
>>>> produce:
>>>>
>>>> guard range > 0 else { return 0 }
>>>> var random: Int
>>>> repeat {
>>>> random = Int(random())
>>>> } while(random > LONG_MAX / range * range)
>>>> return random % range
>>>>
>>>>
>>>> Has anyone come up with a better solution to get a true uniform
>>>> distribution that isn't super messy?
>>>>
>>>> import Foundation
>>>>
>>>> #if os(Linux)
>>>> import Glibc
>>>> #endif
>>>>
>>>>
>>>> public func random_uniform(range: Int) -> Int {
>>>> guard range > 0 else { return 0 }
>>>> #if os(Linux)
>>>>  return Int(random()) % range
>>>> #else
>>>> return Int(arc4random_uniform(UInt32(range)))
>>>> #endif
>>>> }
>>>>
>>>>
>>>> Thanks, Ed
>>>> ___
>>>> 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

[swift-users] arc4random_uniform on Linux is missing from Foundation??

[Edward Connell via swift-users]

Any ideas when Foundation on Linux will support arc4random_uniform? This is
kind of an important function.
There doesn't seem to be any decent substitute without requiring the
installation of libbsd-dev, which turns out to be messy. Currently I am
doing this, but glibc random with mod does not produce good quality
numbers, due to modulo bias.

Has anyone come up with a better solution to get a true uniform
distribution that isn't super messy?

import Foundation

#if os(Linux)
import Glibc
#endif


public func random_uniform(range: Int) -> Int {
guard range > 0 else { return 0 }
#if os(Linux)
 return Int(random()) % range
#else
return Int(arc4random_uniform(UInt32(range)))
#endif
}


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

[swift-users] Swift 4.0 forEach problem

[Edward Connell via swift-users]

In swift 3.1.1 I was able to have the function below, which "gets" an
optional member collection of objects and calls their setModel member
function. Simple and clean using the forEach method.

public func setModel(model: Model) {

get()?.forEach { $0.setModel(*model*: model) }
}

However it now fails with Swift 4.0 saying: *Extraneous argument label
'model:' in call*

---
If I rewrite the function as follows, then it compiles with no errors.

public func setModel(model: Model) {
if let items = get() {
for item in items {
item.setModel(model: model)
}
}
}


Something is broken...

Any ideas what is wrong?

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

[swift-users] swift 4.0 "swift-version 4" errors with "type(of:"

[Edward Connell via swift-users]

When running the compiler using the "-swift-version 4" flag, the compiler
complains about creating a dynamic type. Errors are flagged from within
concrete base classes and also within protocol extensions.

*error: cannot invoke 'type' with an argument list of type '(of: Self)'*
*let newObject = type(of: self).init()*

Has this changed?? Are we supposed to create dynamic types a different way
now?

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

Re: [swift-users] swift 4.0 complains/warns about swapping array elements

[Edward Connell via swift-users]

Great! Yes, changing the diagnostic message will save people from having to
ask this question.

Thanks, Ed

On Fri, May 19, 2017 at 10:30 AM, Devin Coughlin <dcough...@apple.com>
wrote:

> Hi Ed,
>
> On May 19, 2017, at 10:10 AM, Edward Connell via swift-users <
> swift-users@swift.org> wrote:
>
> I just switched to the 5/17 swift 4.0 tool chain on Linux, and I am
> getting the following complaint when using swap on array elements. Is this
> warning legitimate because of a copy on write issue? If so, is there some
> new swap function for array elements? I realize I can turn 1 line into 3
> and do the swapping myself, it's just verbose.
>
> *warning: simultaneous accesses to var 'dims', but modification requires
> exclusive access; consider copying to a local variable*
> *swap([lastIndex],
> [lastIndex-1])*
>
>
> You can use the new swapAt() method:
>
>dims.swapAt(lastIndex, lastIndex-1)
>
> I recently added a Fix-It for this — but we really should also say
> "consider using ‘swapAt()’” in the diagnostic text as well in this case
> rather then mentioning copying to a local.
>
> Devin
>
>
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] How to use a protocol to infer a generic type with constraints

[Edward Connell via swift-users]

Does anyone have an idea when this is going to be fixed? Or when support
will be implemented?
My app heavily uses collections of heterogenous plug-ins, so it's a real
pain in the neck to work around.


On Tue, May 2, 2017 at 2:08 AM, Satoshi Nakagawa via swift-users <
swift-users@swift.org> wrote:

> Hi Slava,
>
> Thanks for your quick response!
>
> I see. That's in line with what I can read from the Type Constraint Syntax
> section in the official Swift book.
>
> Satoshi
>
>
> On Tue, May 2, 2017 at 1:59 AM, Slava Pestov  wrote:
>
>> Hi Satoshi,
>>
>> Protocols do not conform to themselves. Only concrete types can conform
>> to protocols in the current implementation of Swift.
>>
>> Slava
>>
>> > On May 2, 2017, at 1:57 AM, Satoshi Nakagawa via swift-users <
>> swift-users@swift.org> wrote:
>> >
>> > Hi,
>> >
>> > I got a build error "Generic parameter 'T' could not be inferred" for
>> the following code.
>> >
>> > Can anyone explain why we can't use a protocol to infer the generic
>> type T?
>> >
>> > class Emitter {
>> > func emit() -> T {
>> > ...
>> > }
>> > }
>> >
>> > protocol Emittable {}
>> > protocol Subemittable: Emitable {}
>> >
>> > class ConcreteEmittable: Subemittable {}
>> >
>> > func testCode() {
>> > let emitter = Emitter()
>> >
>> > // Error: Generic parameter 'T' could not be inferred
>> > let _: Emittable = emitter.emit()
>> >
>> > // Error: Generic parameter 'T' could not be inferred
>> > let _: Subemittable = emitter.emit()
>> >
>> > // This works
>> > let _: ConcreteEmittable = emitter.emit()
>> > }
>> >
>> > Thanks,
>> > Satoshi
>> >
>> > ___
>> > 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] LLDB fails when I update to Swift 3.1 (error in auto-import)

[Edward Connell via swift-users]

*Problem solved:* On Linux you need to add the swift 3.1 tool chain clang
include directory to your import path. It wasn't needed for the previous
version. So add this to your swift build options and lldb will start
working again.

-Xswiftc -I${SWIFT_HOME}/usr/lib/swift/clang/include

Ed

On Fri, Apr 14, 2017 at 12:52 PM, Edward Connell <ewconn...@gmail.com>
wrote:

> What version of clang does Swift 3.1 expect?
>
> My version is:
>
> clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)
> Target: x86_64-pc-linux-gnu
> Thread model: posix
> InstalledDir: /usr/bin
>
>
> On Fri, Apr 14, 2017 at 12:23 PM, Edward Connell <ewconn...@gmail.com>
> wrote:
>
>> I didn't see anything in the log that offered an obvious clue to the
>> problem. However I made a test case of only a few lines that demonstrates
>> the problem. Importing Foundation seems to be part of the problem.
>>
>>
>>1. set a breakpoint on the print statement
>>2. start debugging
>>3. on break, at the lldb prompt "p someText", you will get the output
>>below complaining about SwiftGlibc
>>
>>
>> If you comment out "import Foundation" and do the same thing, it works
>> correctly.
>> I've attached this linux test project
>>
>> // main.swift -
>> import Foundation
>>
>> var someText = "hey there"
>>
>> for i in 0..<10 {
>> print("Hello, World!")
>> }
>>
>> // output --
>> *e**rror: in auto-import:*
>> *failed to get module 'HelloWorld' from AST context:*
>> */home/ed/swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:10:
>> note: while building module 'SwiftGlibc' imported from
>> /home/ed/swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:*
>> *#include *
>> * ^*
>>
>> *:3:10: note: in file included from :3:*
>> *#include "///usr/include/utmp.h"*
>> * ^*
>>
>> *///usr/include/utmp.h:23:10: note: in file included from
>> ///usr/include/utmp.h:23:*
>> *#include *
>> * ^*
>>
>> *error: /usr/include/x86_64-linux-gnu/sys/types.h:146:10: error:
>> 'stddef.h' file not found*
>> *#include *
>> * ^*
>>
>> *:1:10: note: in file included from :1:*
>> *#include "CoreFoundation.h"*
>> * ^*
>>
>> *error:
>> /home/ed/swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:10: error:
>> could not build module 'SwiftGlibc'*
>> *#include *
>> * ^*
>>
>> */home/ed/swift/usr/lib/swift/CoreFoundation/CFStream.h:20:10: note:
>> while building module 'CDispatch' imported from
>> /home/ed/swift/usr/lib/swift/CoreFoundation/CFStream.h:20:*
>> *#include *
>> * ^*
>>
>> *:1:10: note: in file included from :1:*
>> *#include "dispatch.h"*
>> * ^*
>>
>> */home/ed/swift/usr/lib/swift/dispatch/dispatch.h:42:10: note: in file
>> included from /home/ed/swift/usr/lib/swift/dispatch/dispatch.h:42:*
>> *#include *
>> *     ^*
>>
>> *error: /usr/include/x86_64-linux-gnu/sys/cdefs.h:23:11: error: could not
>> build module 'SwiftGlibc'*
>> *# include *
>> *  ^*
>>
>> *error: could not build Objective-C module 'CoreFoundation'*
>>
>>
>>
>> On Fri, Apr 14, 2017 at 11:24 AM, Jim Ingham <jing...@apple.com> wrote:
>>
>>> The lldb "types" log is the place where detailed info about what's going
>>> on gets dumped.  Turn that on with:
>>>
>>> (lldb) log enable -f /tmp/lldb-types-log.txt lldb types
>>>
>>> Jim
>>>
>>> > On Apr 14, 2017, at 9:33 AM, Edward Connell via swift-users <
>>> swift-users@swift.org> wrote:
>>> >
>>> > Groan... I just tried to update to Swift 3.1 on ubuntu 16.04.
>>> Everything builds fine, but when I try to debug I get the dreaded:
>>> >
>>> > error in auto-import: failed to get module 'XYZ' from AST context
>>> >
>>> > Everything built and debugged just fine with the previous Swift
>>> release.
>>> > I assume LLDB is unhappy about either failing to find an import, or
>>> somehow thinking there is a duplicate.
>>> >
>>> > How do we get LLDB to disclose the reason that it's failing?
>>> >
>>> > Thanks, Ed
>>> >
>>> > ___
>>> > 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] LLDB fails when I update to Swift 3.1 (error in auto-import)

[Edward Connell via swift-users]

Groan... I just tried to update to Swift 3.1 on ubuntu 16.04. Everything
builds fine, but when I try to debug I get the dreaded:

error in auto-import: failed to get module 'XYZ' from AST context

Everything built and debugged just fine with the previous Swift release.
I assume LLDB is unhappy about either failing to find an import, or somehow
thinking there is a duplicate.

How do we get LLDB to disclose the reason that it's failing?

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

Re: [swift-users] It seems like we really need an #include preprocessor directive?

[Edward Connell via swift-users]

Putting a struct with your common vars in it seems like it wouldn't work,
because now it is a member and the vars aren't exposed on your object
directly, so the outer struct wouldn't conform to the protocols.

My original problem with inheritance is that you can't correctly adopt a
protocol on a base class because protocol extensions that specialize based
on Self will use the Self of the base, not of the final class.

Inheritance is fine if nothing happens in the base classes except declaring
the vars required by the protocol. However, any protocol extension
functionality picked up might be the wrong code for the final class. The
only way I see for it to come out right is that the protocols have to be
adopted only by the final class/struct.

#include was just a first thought of how to deal with the need to duplicate
the protocol var declarations. I agree, it's not a good way to handle the
problem.

Maybe I misunderstood it's purpose, but it seems the swift team is using
GYB/python to do code generation to deal with code duplication to address
this problem. That seems even messier to me.


On Sat, Mar 11, 2017 at 10:29 PM, Jens Alfke  wrote:

>
> On Mar 11, 2017, at 10:21 PM, David Sweeris  wrote:
>
> (I see absolutely nothing wrong with inheritance, and it solves exactly
> this sort of problem. Yes, structs can’t inherit, but they can contain a
> common struct as a member, which is quite similar and addresses this issue.)
>
>
> That forces you into reference semantics, though.
>
>
> No it doesn’t. A struct member of a struct is still a value. If you put a
> common *class* instance in a struct, that would be reference semantics.
>
> —Jens
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] It seems like we really need an #include preprocessor directive?

[Edward Connell via swift-users]

Observations about difining an object

   - Structs can't inherit and classes shouldn't inherit, final concrete
   types should be flat
   - Protocols need to be adopted by the final concrete type, otherwise
   constraint specializations aren't correctly applied

This creates a really ugly code duplication situation when you have
multiple object variants that adopt the same protocols.

The storage declaration, common initialization, common didSet, etc... for
protocol member variables must be duplicated for every instance.
If I have 20 objects that have the same base set of 15 vars, this turns
into a maintenance/bug nightmare.

I noticed the use of GYB in the swift source code.
I don't want to involve python in anything I do, and I don't want to mess
up my code/build with all that stuff.

It seems that an easy workaround would be an #include statement.
The boiler plate can be put in a separate file and included wherever it's
needed.
One piece of code, one tool, one set of bugs.

Has this been considered? Or is there a better way to handle this problem.

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

[swift-users] Protocol conformance failure

[Edward Connell via swift-users]

The error says ItemProtocol does not conform to ItemProtocol.
That doesn't make sense. It seems this should work fine.

// It's all clean until the last line
protocol ItemProtocol : class {
var message: String { get }
}

// heterogenious types
class A : ItemProtocol {
var message = "A"
}

class B : ItemProtocol {
var message = "B"
}


var items: [ItemProtocol] = [A(), B()]

func someFunc(items: [T]) {
for item in items {
print(item.message)
}
}

// Everything compiles fine until this
someFunc(items: items)
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] What is the intended response to Array change notification for dependents?

[Edward Connell via swift-users]

My project is on Linux, so pure Swift.
So you don't think this is an issue of intentional library design, but a
recognized problem that hasn't been addressed yet?

Thanks, Ed


On Tue, Mar 7, 2017 at 8:13 AM, Jens Alfke  wrote:

>
> On Mar 7, 2017, at 8:08 AM, Edward Connell  wrote:
>
> My question is, what was their design intent? Rebuild all dependents every
> time?
>
>
> Swift started out by piggybacking on facilities provided by Foundation.
> Over time it’s becoming self-sufficient, but it’s a work in progress.
> Putting “design intent” in the past tense is inaccurate … I would say that
> this seems to be something to come in the future.
>
> Are you asking how to use KVO with Swift arrays, or are you looking at
> pure Swift?
>
> —Jens
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] What is the intended response to Array change notification for dependents?

[Edward Connell via swift-users]

Thank you Jens, that is exactly the point of my question. 
At the moment in pure swift there is no incremental array change API for 
observers. This must have been considered by the library designers. 

My question is, what was their design intent? Rebuild all dependents every time?


Sent from my iPhone

> On Mar 7, 2017, at 7:59 AM, Jens Alfke <j...@mooseyard.com> wrote:
> 
> 
>> On Mar 6, 2017, at 11:36 PM, Rien via swift-users <swift-users@swift.org> 
>> wrote:
>> 
>> On 07 Mar 2017, at 03:56, Edward Connell via swift-users 
>> <swift-users@swift.org> wrote:
>> 
>> I would like to have an Array implementation where I get more information 
>> than just "the whole thing changed". 
>> As a value type I get it, but lets say it's a list of 500 image info structs 
>> and it's bound to UI. You change one item, now the whole array changes and 
>> you have to rebuild the entire visual tree right? Rebuilding the state of 
>> dependent objects can be really expensive, not just UI things.
> 
> In Apple’s Foundation framework, Key-Value Observing (KVO) fills this need, 
> and can be used with NSMutableArray, including when it’s bridged to Swift. 
> But it doesn’t really transfer to a pure Swift environment since arrays are 
> value types: changing one item is actually replacing the entire array with a 
> new one (optimized through clever internal data-sharing.)
> 
> I would assume that the people working on the design of the Swift Foundation 
> library are thinking about similar observer APIs, but I don’t know the 
> details.
> 
> ―Jens
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] What is the intended response to Array change notification for dependents?

[Edward Connell via swift-users]

I would like to have an Array implementation where I get more information
than just "the whole thing changed".
As a value type I get it, but lets say it's a list of 500 image info
structs and it's bound to UI. You change one item, now the whole array
changes and you have to rebuild the entire visual tree right? Rebuilding
the state of dependent objects can be really expensive, not just UI things.

Is there some efficient strategy that the library designers intended for
this situation?
It seems like a really common and obvious scenario.
Insights and suggestions are appreciated.

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

Re: [swift-users] Is this really a race condition?

[Edward Connell via swift-users]

Not at all, thank you for trying it out.
When I run my code on the Mac in Xcode with thread sanitizer on, I don't
get any warnings or problems at all. I only find problems on Linux. I have
noticed that for the same release, the compiler and libraries are not
identical between Mac and Linux. I am currently using what I believe is the
latest release for both

$ swift --version
Swift version 3.0.2 (swift-3.0.2-RELEASE)
Target: x86_64-unknown-linux-gnu



On Thu, Mar 2, 2017 at 3:32 PM, Zhao Xin <owe...@gmail.com> wrote:

> I am sorry if this bothers you. I just put the original code in Xcode and
> it works. Anyone knows why this works in Xcode or in macOS? I thought it
> should show the same warnings as Linux.
>
> Zhaoxin
>
> On Fri, Mar 3, 2017 at 2:51 AM, Edward Connell via swift-users <
> swift-users@swift.org> wrote:
>
>> Hi Guillaume,
>> There is still a race condition report, but I think maybe we are almost
>> there. I had to modify your example because it didn't quite build, and a
>> loop to do it twice since it randomly complains if you only do it once.
>> Btw, this is on Linux.
>> The warning is triggered when deinitialize is called. It wasn't in your
>> example, but it seems that it is required since the Elements are not a
>> trivial type like Int.
>>
>> Thanks, Ed
>>
>> for _ in 0..<2 {
>> let count = 1000
>> let items = UnsafeMutablePointer<[UInt8]?>.allocate(capacity: count)
>> items.initialize(to: nil, count: count)
>>
>> DispatchQueue.concurrentPerform(iterations: count) {
>> items[$0] = [UInt8](repeating: 7, count: 10)
>> }
>>
>> items.deinitialize(count: count)
>> items.deallocate(capacity: count)
>> }
>>
>> ==
>> WARNING: ThreadSanitizer: data race (pid=24076)
>>   Write of size 8 at 0x7d0c5fa0 by main thread:
>> #0 free  (libtsan.so.0+0x00025819)
>> #1 _TwXxOs31_ClosedRangeIndexRepresentation 
>> (libswiftCore.so+0x0027e071)
>>
>>   Previous write of size 8 at 0x7d0c5fa0 by thread T20:
>> #0 malloc  (libtsan.so.0+0x000254a3)
>> #1 swift_slowAlloc  (libswiftCore.so+0x002ee3e5)
>>
>>   Thread T20 (tid=24288, running) created by main thread at:
>> #0 pthread_create  (libtsan.so.0+0x00027577)
>> #1 manager_workqueue_additem /home/buildnode/disk2/workspac
>> e/oss-swift-3.0-package-linux-ubuntu-16_04/swift-corelibs-
>> libdispatch/libpwq/src/posix/manager.c:815 (libdispatch.so+0x0007c6b1
>> )
>>
>> SUMMARY: ThreadSanitizer: data race ??:0 __interceptor_free
>> ==
>>
>>
>> ThreadSanitizer: reported 1 warnings
>>
>>
>>
>> On Wed, Mar 1, 2017 at 6:48 PM, Edward Connell <ewconn...@gmail.com>
>> wrote:
>>
>>> Ahh! thank you. That makes sense.
>>>
>>> On Wed, Mar 1, 2017 at 3:29 PM, Guillaume Lessard <
>>> gless...@tffenterprises.com> wrote:
>>>
>>>>
>>>> > On Mar 1, 2017, at 3:21 PM, Edward Connell via swift-users <
>>>> swift-users@swift.org> wrote:
>>>> >
>>>> > The thread sanitizer on Linux is reporting that I have race
>>>> conditions in libswiftcore. I eliminated enough code down to this trivial
>>>> example. Is there really a race condition here or are these bogus errors?
>>>> >
>>>> >   let count = 1000
>>>> >   var items = [[UInt8]?](repeating: nil, count: count)
>>>> >
>>>> >   DispatchQueue.concurrentPerform(iterations: count) {
>>>> >   items[$0] = [UInt8](repeating: 7, count: 10)
>>>> >   }
>>>> >
>>>> > My real scenario is retrieving data asynchronously, so I just threw
>>>> in a buffer assignment.
>>>>
>>>> The assignments to array elements are where the race lies.
>>>>
>>>> I don’t know about the libswiftcore part, but: assigning to a shared
>>>> Array concurrently from multiple threads won't work, because of Array's
>>>> copy-on-write behaviour. You could do
>>>>
>>>> let items = UnsafeMutablePointer<[UInt8]?>.allocate(capacity: 1)
>>>> items.initialize(to: nil, count: count)
>>>>
>>>> DispatchQueue.concurrentPerform(iterations: count) {
>>>>   items[$0].initialize([UInt8](repeating: 7, count: 10))
>>>> }
>>>>
>>>> // you’ll be able to see here that they’re all initialized
>>>>
>>>> items.deallocate(capacity: count)
>>>>
>>>> Cheers,
>>>> Guillaume Lessard
>>>>
>>>>
>>>
>>
>> ___
>> 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] Is this really a race condition?

[Edward Connell via swift-users]

Hi Guillaume,
There is still a race condition report, but I think maybe we are almost
there. I had to modify your example because it didn't quite build, and a
loop to do it twice since it randomly complains if you only do it once.
Btw, this is on Linux.
The warning is triggered when deinitialize is called. It wasn't in your
example, but it seems that it is required since the Elements are not a
trivial type like Int.

Thanks, Ed

for _ in 0..<2 {
let count = 1000
let items = UnsafeMutablePointer<[UInt8]?>.allocate(capacity: count)
items.initialize(to: nil, count: count)

DispatchQueue.concurrentPerform(iterations: count) {
items[$0] = [UInt8](repeating: 7, count: 10)
}

items.deinitialize(count: count)
items.deallocate(capacity: count)
}

==
WARNING: ThreadSanitizer: data race (pid=24076)
  Write of size 8 at 0x7d0c5fa0 by main thread:
#0 free  (libtsan.so.0+0x00025819)
#1 _TwXxOs31_ClosedRangeIndexRepresentation 
(libswiftCore.so+0x0027e071)

  Previous write of size 8 at 0x7d0c5fa0 by thread T20:
#0 malloc  (libtsan.so.0+0x000254a3)
#1 swift_slowAlloc  (libswiftCore.so+0x002ee3e5)

  Thread T20 (tid=24288, running) created by main thread at:
#0 pthread_create  (libtsan.so.0+0x00027577)
#1 manager_workqueue_additem
/home/buildnode/disk2/workspace/oss-swift-3.0-package-linux-ubuntu-16_04/swift-corelibs-libdispatch/libpwq/src/posix/manager.c:815
(libdispatch.so+0x0007c6b1)

SUMMARY: ThreadSanitizer: data race ??:0 __interceptor_free
==


ThreadSanitizer: reported 1 warnings



On Wed, Mar 1, 2017 at 6:48 PM, Edward Connell <ewconn...@gmail.com> wrote:

> Ahh! thank you. That makes sense.
>
> On Wed, Mar 1, 2017 at 3:29 PM, Guillaume Lessard <
> gless...@tffenterprises.com> wrote:
>
>>
>> > On Mar 1, 2017, at 3:21 PM, Edward Connell via swift-users <
>> swift-users@swift.org> wrote:
>> >
>> > The thread sanitizer on Linux is reporting that I have race conditions
>> in libswiftcore. I eliminated enough code down to this trivial example. Is
>> there really a race condition here or are these bogus errors?
>> >
>> >   let count = 1000
>> >   var items = [[UInt8]?](repeating: nil, count: count)
>> >
>> >   DispatchQueue.concurrentPerform(iterations: count) {
>> >   items[$0] = [UInt8](repeating: 7, count: 10)
>> >   }
>> >
>> > My real scenario is retrieving data asynchronously, so I just threw in
>> a buffer assignment.
>>
>> The assignments to array elements are where the race lies.
>>
>> I don’t know about the libswiftcore part, but: assigning to a shared
>> Array concurrently from multiple threads won't work, because of Array's
>> copy-on-write behaviour. You could do
>>
>> let items = UnsafeMutablePointer<[UInt8]?>.allocate(capacity: 1)
>> items.initialize(to: nil, count: count)
>>
>> DispatchQueue.concurrentPerform(iterations: count) {
>>   items[$0].initialize([UInt8](repeating: 7, count: 10))
>> }
>>
>> // you’ll be able to see here that they’re all initialized
>>
>> items.deallocate(capacity: count)
>>
>> Cheers,
>> Guillaume Lessard
>>
>>
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] Is this really a race condition?

[Edward Connell via swift-users]

The thread sanitizer on Linux is reporting that I have race conditions in
libswiftcore. I eliminated enough code down to this trivial example. Is
there really a race condition here or are these bogus errors?

let count = 1000
var items = [[UInt8]?](repeating: nil, count: count)

DispatchQueue.concurrentPerform(iterations: count) {
items[$0] = [UInt8](repeating: 7, count: 10)
}

My real scenario is retrieving data asynchronously, so I just threw in a
buffer assignment.

Thanks, Ed

==
WARNING: ThreadSanitizer: data race (pid=30720)
  Read of size 8 at 0x7d908028 by thread T16:
#0 memcpy  (libtsan.so.0+0x0002617a)
#1 _TwCcOs31_ClosedRangeIndexRepresentation 
(libswiftCore.so+0x0027e0fa)

  Previous write of size 8 at 0x7d908028 by main thread:
#0 memcpy  (libtsan.so.0+0x0002617a)
#1 _TwCcOs31_ClosedRangeIndexRepresentation 
(libswiftCore.so+0x0027e0fa)

  Location is heap block of size 8032 at 0x7d908000 allocated by main
thread:
#0 malloc  (libtsan.so.0+0x000254a3)
#1 swift_slowAlloc  (libswiftCore.so+0x002ee3e5)

  Thread T16 (tid=30917, running) created by main thread at:
#0 pthread_create  (libtsan.so.0+0x00027577)
#1 manager_workqueue_additem
/home/buildnode/disk2/workspace/oss-swift-3.0-package-linux-ubuntu-16_04/swift-corelibs-libdispatch/libpwq/src/posix/manager.c:815
(libdispatch.so+0x0007c6b1)

SUMMARY: ThreadSanitizer: data race ??:0 memcpy
==
==
WARNING: ThreadSanitizer: data race (pid=30720)
  Write of size 8 at 0x7d0c00015d80 by thread T16:
#0 free  (libtsan.so.0+0x00025819)
#1 _TwXxOs31_ClosedRangeIndexRepresentation 
(libswiftCore.so+0x0027e071)

  Previous write of size 8 at 0x7d0c00015d80 by main thread:
#0 malloc  (libtsan.so.0+0x000254a3)
#1 swift_slowAlloc  (libswiftCore.so+0x002ee3e5)

  Thread T16 (tid=30917, running) created by main thread at:
#0 pthread_create  (libtsan.so.0+0x00027577)
#1 manager_workqueue_additem
/home/buildnode/disk2/workspace/oss-swift-3.0-package-linux-ubuntu-16_04/swift-corelibs-libdispatch/libpwq/src/posix/manager.c:815
(libdispatch.so+0x0007c6b1)

SUMMARY: ThreadSanitizer: data race ??:0 __interceptor_free
==
==
WARNING: ThreadSanitizer: data race (pid=30720)
  Write of size 8 at 0x7d90a028 by thread T20:
#0 free  (libtsan.so.0+0x00025819)
#1 _TZFSa11_copyBufferfRGVs22_ContiguousArrayBufferx_T_ 
(libswiftCore.so+0x0010884e)

  Previous read of size 8 at 0x7d90a028 by thread T17:
#0 memcpy  (libtsan.so.0+0x0002617a)
#1 _TwCcOs31_ClosedRangeIndexRepresentation 
(libswiftCore.so+0x0027e0fa)

  Thread T20 (tid=30921, running) created by main thread at:
#0 pthread_create  (libtsan.so.0+0x00027577)
#1 manager_workqueue_additem
/home/buildnode/disk2/workspace/oss-swift-3.0-package-linux-ubuntu-16_04/swift-corelibs-libdispatch/libpwq/src/posix/manager.c:815
(libdispatch.so+0x0007c6b1)

  Thread T17 (tid=30918, running) created by main thread at:
#0 pthread_create  (libtsan.so.0+0x00027577)
#1 manager_workqueue_additem
/home/buildnode/disk2/workspace/oss-swift-3.0-package-linux-ubuntu-16_04/swift-corelibs-libdispatch/libpwq/src/posix/manager.c:815
(libdispatch.so+0x0007c6b1)

SUMMARY: ThreadSanitizer: data race ??:0 __interceptor_free
==
==
WARNING: ThreadSanitizer: data race (pid=30720)
  Read of size 8 at 0x7d906028 by thread T23:
#0 memcpy  (libtsan.so.0+0x0002617a)
#1 _TwCcOs31_ClosedRangeIndexRepresentation 
(libswiftCore.so+0x0027e0fa)

  Previous write of size 8 at 0x7d906028 by main thread:
#0 malloc  (libtsan.so.0+0x000254a3)
#1 swift_slowAlloc  (libswiftCore.so+0x002ee3e5)

  Location is heap block of size 8032 at 0x7d906000 allocated by main
thread:
#0 malloc  (libtsan.so.0+0x000254a3)
#1 swift_slowAlloc  (libswiftCore.so+0x002ee3e5)

  Thread T23 (tid=30924, running) created by main thread at:
#0 pthread_create  (libtsan.so.0+0x00027577)
#1 manager_workqueue_additem
/home/buildnode/disk2/workspace/oss-swift-3.0-package-linux-ubuntu-16_04/swift-corelibs-libdispatch/libpwq/src/posix/manager.c:815
(libdispatch.so+0x0007c6b1)

SUMMARY: ThreadSanitizer: data race ??:0 memcpy
==
==
WARNING: ThreadSanitizer: data race (pid=30720)
  Write of size 8 at 0x7d92e000 by thread T19:
#0 free  (libtsan.so.0+0x00025819)
#1 _TZFSa11_copyBufferfRGVs22_ContiguousArrayBufferx_T_ 
(libswiftCore.so+0x00108859)

  Previous write of size 8 at 0x7d92e000 by thread T20:
#0 malloc  (libtsan.so.0+0x000254a3)
#1 swift_slowAlloc  (libswiftCore.so+0x002ee3e5)

  Thread T19 (tid=30920, running) created by main thread at:
#0 pthread_create  (libtsan.so.0+0x00027577)
#1 manager_workqueue_additem

Re: [swift-users] isKnownUniquelyReferenced really a mutating function?

[Edward Connell via swift-users]

I am implementing a custom Array type for a distributed memory system.

I have a DataView struct which represents the array to the user as a value
type, and a backing store class object referenced by the DataView that does
all the replication. Write accesses are mutating so they don't cause a
problem.

However read only accesses are not mutating and there lies the problem. If
the storage object is uniquely referenced, then I can do my business
without taking a synchronization lock, otherwise I need to take a lock
before syncing memory.

I can "always" take a lock to work around this, but most of the time it
isn't necessary and I care about performance.

I think there should be a "read only pass by reference"

I just pulled this comment from the source code. I was under the impression
that isKnownUniquelyReferenced is thread safe, but the comments implies
that it isn't??

--
/// If the instance passed as `object` is being accessed by multiple threads
/// simultaneously, this function may still return `true`. Therefore, you
must
/// only call this function from mutating methods with appropriate thread
/// synchronization. That will ensure that `isKnownUniquelyReferenced(_:)`
/// only returns `true` when there is really one accessor, or when there is
a
/// race condition, which is already undefined behavior.
///
/// - Parameter object: An instance of a class. This function does *not*
modify
///   `object`; the use of `inout` is an implementation artifact.



On Wed, Jan 25, 2017 at 10:31 AM, Joe Groff <jgr...@apple.com> wrote:

>
> > On Jan 25, 2017, at 10:20 AM, Edward Connell via swift-users <
> swift-users@swift.org> wrote:
> >
> > I have a data structure that calls isKnownUniquelyReferenced on a
> member. It forces everything to be marked as mutating because of the inout
> parameter, however the parameter is never mutated, it is just read right??
> The reason it is inout is because a read only reference is required.
> >
> > If it is truly not mutating, is there some way around this so I don't
> have to mark everything in the caller chain as mutating also? It's kind of
> annoying...
>
> In Swift's current model, `isKnownUniquelyReferenced` needs to be inout
> because that's currently the only way to assert unique access to an object
> in memory, since read-only rvalues are otherwise freely copyable so the
> result of the uniqueness check would be only momentarily valid at best.
> What are you trying to do that requires using it on a nonmutable value?
> There may be another way to go about it.
>
> -Joe
>
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] How to include swift test resource files?

[Edward Connell via swift-users]

Swift test builds and runs the package Tests. My tests require data files
such as images to run.
With an Xcode project we can Copy Bundle Resources in the Build Phases to
include the necessary files.

How do we do this with swift test, or swift build?

I thought about a hack to manually copy the resource files, but since
"swift test" builds and runs the tests as a single action there doesn't
seem to be an opportunity.

How do we include package resources during build and test?

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

[swift-users] How do you dynamically load a module on Linux?

[Edward Connell via swift-users]

On OSX my application loads a bundle from the PlugIns directory. It loads
and executes perfectly.

Now I'm painfully trying to port my code to Linux, where we don't seem to
have frameworks or bundles per se. I assumed a bundle is just a dynamic lib
or module. My build creates a PlugIns directory and copies the plugins
.swiftmodule and .swiftdoc files into that directory hoping the load api
would work.

When I call

Bundle.paths(forResourcesOfType: "swiftmodule", inDirectory: dir)

I get zero results. I'm not even sure if this is heading in the right
direction.

How do I dynamically load a module on Linux?

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

Re: [swift-users] Swift Package Manager questions

[Edward Connell via swift-users]

Thanks Ankit,
Should I be able to pick up that change with Xcode 8.1 beta 3 (latest)? Oct
10th.

Ed

On Mon, Oct 17, 2016 at 11:42 AM, Ankit Agarwal <an...@ankit.im> wrote:

> Hi,
>
> Currently in Swift 3 release of SwiftPM, you cannot override this setting.
> A proper solution to this problem is yet to be built in SwiftPM however in
> the mean time this patch was landed to allow overrides by passing custom
> args: https://github.com/apple/swift-package-manager/pull/715
> It is available in a recent trunk snapshot from swift.org
>
> Also, while passing custom arguments to swift build, escape each argument
> with the prefix eg:
> *`-Xswiftc -target x86_64-apple-macosx10.12`  **should be:** `**-Xswiftc
> -target **-Xswiftc **x86_64-apple-macosx10.12`*
>
>
> On Mon, Oct 17, 2016 at 5:23 AM, Edward Connell via swift-users <
> swift-users@swift.org> wrote:
>
>> Hi, I've written a Swift (with some C) framework the builds and runs
>> cleanly in Xcode 8.
>> A critical feature of my project is for my framework to run on MacOS,
>> iOS, and Linux.
>> I am trying to figure out how to build using the SPM so I can run on
>> Ubuntu.
>> I'm not so happy with the project structure now, but at least I think I
>> am almost there.
>>
>> I've hit a sticking point that I can't seem to figure out. The SPM sets
>> the target SDK to 10.10 by default.
>> Features in Swift 3.0 that I am using require at least 10.11. When I type:
>>
>> *swift build -Xcc -I/usr/local/include -Xswiftc -j4 -Xlinker
>> -L/usr/local/lib -Xlinker -lpng -Xlinker -ljpeg*
>>
>> The build bombs with:
>>
>> "... error: 'init(fileURLWithPath:relativeTo:)' is only available on OS
>> X 10.11 or newer"
>>
>> How do I set the correct OS version??
>>
>> I looked at the Xcode settings and tried to pass them through, but there
>> seems to be an argument parsing error by SPM.
>> I am currently trying:
>>
>> *swift build -Xcc -I/usr/local/include -Xswiftc -j4 -Xswiftc -sdk
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
>> -Xswiftc -target x86_64-apple-macosx10.12 -Xlinker -L/usr/local/lib
>> -Xlinker -lpng -Xlinker -ljpeg*
>>
>> And I get:
>>
>> error: unknown command: /Applications/Xcode.app/Conten
>> ts/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
>>
>> So it seems it thinks the parameter is a command.
>>
>> *How do you set the sdk and target versions through swift build to fix
>> this problem?*
>>
>> Thanks, Ed
>>
>>
>> *Configuration*:
>>
>> MacBook Pro (Retina, 13-inch, Early 2015)
>>
>> Sierra 10.12 (16A323)
>>
>> Xcode Version 8.0 (8A218a)
>>
>>
>>
>>
>>
>>
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
>>
>>
>
>
> --
> Ankit
>
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users