[swift-users] Ubuntu 16.04 Bots on ci.swift.org

[mishal_shah via swift-users]

Ubuntu 16.04 support added to ci.swift.org!  

Starting tomorrow swift.org will also contain Ubuntu 16.04 toolchains.

Master:
0. OSS - Swift Incremental RA - Ubuntu 16.04 (master) 

0. OSS - Swift Incremental RA - Ubuntu 16.04 - Long Test (master) 

0. OSS - LLDB Incremental - Ubuntu 16.04 (master) 

OSS - Swift Package - Ubuntu 16.04 (master) 


Swift-3.0-branch: 
0. OSS - Swift Incremental RA - Ubuntu 16.04 (swift 3.0) 

0. OSS - Swift Incremental RA - Ubuntu 16.04 - Long Test (swift 3.0) 

0. OSS - LLDB Incremental - Ubuntu 16.04 (swift 3.0) 

OSS - Swift Package - Ubuntu 16.04 (swift 3.0) 


Please let me know if you have any questions. 

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

[swift-users] Fwd: How to bridge between CoreFoundation and SwiftFoundation on Linux?

[Joe Groff via swift-users]

> On Sep 21, 2016, at 1:03 PM, Bouke Haarsma via swift-users 
>  wrote:
> 
> The one that comes with SwiftFoundation 
> (https://github.com/apple/swift-corelibs-foundation/tree/master/CoreFoundation).
> 
> I think it should be a bug that CFReadStream cannot be bridged to 
> (NS)InputStream, as otherwise there’s no way to intertwine Sockets 
> (CFSockets) with SwiftFoundation. As the implementation already uses a 
> CFReadStream internally 
> (https://github.com/apple/swift-corelibs-foundation/blob/d3872cb094124d5dd189839505ae73e2fa717cfd/Foundation/NSStream.swift#L122),
>  it would be a matter of adding an initializer. However the value is private, 
> so adding the initializer cannot be done from an extension.

(including the list this time) AIUI, Core Foundation is an implementation 
detail of the corelibs implementation of Foundation. It isn't intended to be 
used directly from Swift code on Linux.

-Joe

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

Re: [swift-users] Can anyone please explain this behavior?

[Joe Groff via swift-users]

> On Sep 21, 2016, at 2:22 PM, Jens Persson via swift-users 
>  wrote:
> 
> // This little Swift program compiles (and runs) fine:
> 
> func foo() -> Int { return a }
> let a = 1
> let b = 2
> print(foo())
> 
> But if `foo()` returns `b` instead of `a`, I get this compile time error:
> "Use of unresolved identifier `b`"

This looks like a bug to me (cc-ing Jordan, who's thought about global scoping 
issues more than me). In "script mode", it shouldn't be possible to refer to a 
variable before its initialization is executed. However, the way this is 
currently modeled is…problematic, to say the least, among other reasons because 
script globals are still visible to "library" files in the same module.

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

Re: [swift-users] Can anyone please explain this behavior?

[Jens Persson via swift-users]

I asked the same question on twitter, and it resulted in some interesting
finds:
https://twitter.com/bitCycle/status/778697998893142016

On Thu, Sep 22, 2016 at 12:41 AM, Zhao Xin  wrote:

> I suggest you defining the variables before using them like Marco does.
> Although from the global variable point of view, both way should be fine.
> But the glitch does exist, especially in playground.
>
> Zhaoxin
>
> On Thu, Sep 22, 2016 at 5:59 AM, Marco S Hyman via swift-users <
> swift-users@swift.org> wrote:
>
>>
>> > On Sep 21, 2016, at 2:22 PM, Jens Persson via swift-users <
>> swift-users@swift.org> wrote:
>> >
>> > // This little Swift program compiles (and runs) fine:
>> >
>> > func foo() -> Int { return a }
>> > let a = 1
>> > let b = 2
>> > print(foo())
>> >
>> > But if `foo()` returns `b` instead of `a`, I get this compile time
>> error:
>> > "Use of unresolved identifier `b`”
>>
>> Interesting.  Seems to have something to do with ordering as if you code
>> it this way:
>>
>> let a = 1
>> let b = 2
>> func foo() -> Int { return b }
>> print(foo())
>>
>> it works fine (Xcode 8 playground).
>> ___
>> 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] Can anyone please explain this behavior?

[Zhao Xin via swift-users]

I suggest you defining the variables before using them like Marco does.
Although from the global variable point of view, both way should be fine.
But the glitch does exist, especially in playground.

Zhaoxin

On Thu, Sep 22, 2016 at 5:59 AM, Marco S Hyman via swift-users <
swift-users@swift.org> wrote:

>
> > On Sep 21, 2016, at 2:22 PM, Jens Persson via swift-users <
> swift-users@swift.org> wrote:
> >
> > // This little Swift program compiles (and runs) fine:
> >
> > func foo() -> Int { return a }
> > let a = 1
> > let b = 2
> > print(foo())
> >
> > But if `foo()` returns `b` instead of `a`, I get this compile time error:
> > "Use of unresolved identifier `b`”
>
> Interesting.  Seems to have something to do with ordering as if you code
> it this way:
>
> let a = 1
> let b = 2
> func foo() -> Int { return b }
> print(foo())
>
> it works fine (Xcode 8 playground).
> ___
> 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] Cross-Compiling to Linux from macOS

[Rafael Costa via swift-users]

Thank you Karl

Enviado do meu iPhone

> Em 21 de set de 2016, às 18:45, Karl  escreveu:
> 
> 
>> On 21 Sep 2016, at 19:14, Rafael Costa via swift-users 
>>  wrote:
>> 
>> Hello fellow Swift users,
>> 
>> I’m encountering some problems and I wish to know if anyone here has ever 
>> come across something similar.
>> 
>> In essence, I want to cross-compile a Swift Project on macOS to run it on 
>> Linux. I’m using the following command to (try) to do so:
>> 
>> swift build -c release --build-path ./.build/linux -Xswiftc -static-stdlib 
>> -Xswiftc -target -Xswiftc x86_64-unknown-linux-gnu 
>> 
>> The “target” parameter is passing to the “swiftc” program just fine. The 
>> problem is that it is overwritten by a “target” parameter added 
>> automatically by swift-build (that sets the target as the same arch/OS as 
>> the host machine)
>> 
>> How can I prevent that? Is it possible to cross-compile for Linux on macOS?
>> 
>> Thanks in advance,
>> Rafael Costa
>> raf...@rafaelcosta.me
>> 
>> 
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
> 
> For example, this is what we do in LLDB to cross-compile the REPL:
> 
> https://github.com/apple/swift-lldb/blob/587e781a6fab4db0338a6e71bbc7fc3475f9d43c/tools/repl/swift/CMakeLists.txt#L11
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Can anyone please explain this behavior?

[Marco S Hyman via swift-users]

> On Sep 21, 2016, at 2:22 PM, Jens Persson via swift-users 
>  wrote:
> 
> // This little Swift program compiles (and runs) fine:
> 
> func foo() -> Int { return a }
> let a = 1
> let b = 2
> print(foo())
> 
> But if `foo()` returns `b` instead of `a`, I get this compile time error:
> "Use of unresolved identifier `b`”

Interesting.  Seems to have something to do with ordering as if you code it 
this way:

let a = 1
let b = 2
func foo() -> Int { return b }
print(foo())

it works fine (Xcode 8 playground).
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Cross-Compiling to Linux from macOS

[Karl via swift-users]

> On 21 Sep 2016, at 19:14, Rafael Costa via swift-users 
>  wrote:
> 
> Hello fellow Swift users,
> 
> I’m encountering some problems and I wish to know if anyone here has ever 
> come across something similar.
> 
> In essence, I want to cross-compile a Swift Project on macOS to run it on 
> Linux. I’m using the following command to (try) to do so:
> 
> swift build -c release --build-path ./.build/linux -Xswiftc -static-stdlib 
> -Xswiftc -target -Xswiftc x86_64-unknown-linux-gnu 
> 
> The “target” parameter is passing to the “swiftc” program just fine. The 
> problem is that it is overwritten by a “target” parameter added automatically 
> by swift-build (that sets the target as the same arch/OS as the host machine)
> 
> How can I prevent that? Is it possible to cross-compile for Linux on macOS?
> 
> Thanks in advance,
> Rafael Costa
> raf...@rafaelcosta.me 
> 
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

For example, this is what we do in LLDB to cross-compile the REPL:

https://github.com/apple/swift-lldb/blob/587e781a6fab4db0338a6e71bbc7fc3475f9d43c/tools/repl/swift/CMakeLists.txt#L11___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Cross-Compiling to Linux from macOS

[Karl via swift-users]

> On 21 Sep 2016, at 19:14, Rafael Costa via swift-users 
>  wrote:
> 
> Hello fellow Swift users,
> 
> I’m encountering some problems and I wish to know if anyone here has ever 
> come across something similar.
> 
> In essence, I want to cross-compile a Swift Project on macOS to run it on 
> Linux. I’m using the following command to (try) to do so:
> 
> swift build -c release --build-path ./.build/linux -Xswiftc -static-stdlib 
> -Xswiftc -target -Xswiftc x86_64-unknown-linux-gnu 
> 
> The “target” parameter is passing to the “swiftc” program just fine. The 
> problem is that it is overwritten by a “target” parameter added automatically 
> by swift-build (that sets the target as the same arch/OS as the host machine)
> 
> How can I prevent that? Is it possible to cross-compile for Linux on macOS?
> 
> Thanks in advance,
> Rafael Costa
> raf...@rafaelcosta.me 
> 
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

It is possible, but I don’t know if swift-build supports it. We don’t really 
have much comprehensive support for cross-compiling right now.

To cross-compile, you need to set the target, sysroot and tools-directory (the 
latter only required if compiling an executable, not for swiftmodules). You 
might also need to set the resource-dir to the lib/swift folder where the 
target’s standard library is.___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] Can anyone please explain this behavior?

[Jens Persson via swift-users]

// This little Swift program compiles (and runs) fine:

func foo() -> Int { return a }
let a = 1
let b = 2
print(foo())

But if `foo()` returns `b` instead of `a`, I get this compile time error:
"Use of unresolved identifier `b`"
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] How to bridge between CoreFoundation and SwiftFoundation on Linux?

[Philippe Hausler via swift-users]

I would suggest that the way to do it is to follow the NSString/NSNumber 
approach used in swift-corelibs-foundation where the structural size is 
equivalent.

the layout would roughly look like:


open class InputStream : Stream {
typealias CFType = CFReadStream
// This layout MUST be the same as CFReadStream so that they are bridgeable
private var _base = _CFInfo(typeID: CFReadStreamGetTypeID())
private var _flags: CFOptionFlags = 0
private var _error: UnsafeMutableRawPointer? = nil
private var _info: UnsafeMutableRawPointer? = nil
private var _callBacks: UnsafeMutableRawPointer? = nil
#if os(OSX) || os(iOS)
private var _lock = pthread_mutex_t()
#elseif os(Linux)
private var _lock = Int32(0)
#endif
private var _previousRunloopsAndModes: UnsafeMutableRawPointer? = nil
#if DEPLOYMENT_ENABLE_LIBDISPATCH
private var _queue: UnsafeMutableRawPointer? = nil
#endif

internal var _cfObject: CFType {
return unsafeBitCast(self, to: CFType.self)
}

...
}

This would ensure the memory size of the allocation of InputStream would be the 
same as CFReadStream. 

These two calls would then need to be un-commented in NSSwiftRuntime.swift

//_CFRuntimeBridgeTypeToClass(CFReadStreamGetTypeID(), 
unsafeBitCast(InputStream.self, UnsafeRawPointer.self))
//_CFRuntimeBridgeTypeToClass(CFWriteStreamGetTypeID(), 
unsafeBitCast(OutputStream.self, UnsafeRawPointer.self))

and __CFSwiftBridge would need entries for calling out to swift for subclassers.


> On Sep 21, 2016, at 1:03 PM, Bouke Haarsma via swift-users 
>  wrote:
> 
> The one that comes with SwiftFoundation 
> (https://github.com/apple/swift-corelibs-foundation/tree/master/CoreFoundation
>  
> ).
> 
> I think it should be a bug that CFReadStream cannot be bridged to 
> (NS)InputStream, as otherwise there’s no way to intertwine Sockets 
> (CFSockets) with SwiftFoundation. As the implementation already uses a 
> CFReadStream internally 
> (https://github.com/apple/swift-corelibs-foundation/blob/d3872cb094124d5dd189839505ae73e2fa717cfd/Foundation/NSStream.swift#L122
>  
> ),
>  it would be a matter of adding an initializer. However the value is private, 
> so adding the initializer cannot be done from an extension.
> 
> —
> Bouke
> 
>> On 21 Sep 2016, at 21:22, Jens Alfke > > wrote:
>> 
>> 
>>> On Sep 20, 2016, at 9:38 PM, Bouke Haarsma via swift-users 
>>> > wrote:
>>> 
>>> When working with CoreFoundation objects (e.g. CFReadStream, CFWriteStream) 
>>> it isn't immediately obvious to me how to bridge them to SwiftFoundation 
>>> counterparts (InputStream / OutputStream).
>>> 
>>> The following works on OSX, but doesn't work on Linux;
>> 
>> What implementation of CF are you using on Linux? OpenStep?
>> 
>> The bridging between Swift and Obj-C Foundation classes is only implemented 
>> on Apple platforms. It’s not part of the open source release. The plan is to 
>> implement classes like InputStream in native Swift as part of the standard 
>> library; that work is in progress.
>> 
>> —Jens
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

Re: [swift-users] How to bridge between CoreFoundation and SwiftFoundation on Linux?

[Bouke Haarsma via swift-users]

The code is for another project. I’m trying to build a (partial) Swift 
implementation of NetService. See also 
https://github.com/Bouke/NetService/tree/linux 
.

Apparently that protocol is EOL;

> // slated for removal, these are the swift-corelibs-only variant of the 
> _ObjectiveCBridgeable
> internal protocol _CFBridgeable {
> associatedtype CFType
> var _cfObject: CFType { get }
> }


—
Bouke


> On 21 Sep 2016, at 21:56, Will Stanton  wrote:
> 
> Hello Bouke,
> 
> Is that code you’re working on within SwiftFoundation or for another project?
> 
> I believe _cfObject can bridge String to CFString within SwiftFoundation (but 
> it’s an internal property), for example in NSDateFormatter.swift:
> String -> CFString
> _setFormatterAttribute(formatter, attributeName: kCFDateFormatterAMSymbol, 
> value: _amSymbol?._cfObject)
> CFString -> String
> (CFDateFormatterCopyProperty(_cfObject, kCFDateFormatterAMSymbol) as! 
> NSString)._swiftObject
> 
> 
> Within SwiftFoundation, it seems CFReadStream+CFWriteStream do not have 
> associated CFTypes. That may be because their implementations just started, 
> but I am not sure what the plan is with those classes and `protocol 
> _CFBridgeable`.
> 
> 
> Regards,
> Will Stanton
> 
>> On Sep 21, 2016, at 12:38 AM, Bouke Haarsma via swift-users 
>>  wrote:
>> 
>> Hi all,
>> 
>> When working with CoreFoundation objects (e.g. CFReadStream, CFWriteStream) 
>> it isn't immediately obvious to me how to bridge them to SwiftFoundation 
>> counterparts (InputStream / OutputStream).
> 

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

Re: [swift-users] How to bridge between CoreFoundation and SwiftFoundation on Linux?

[Bouke Haarsma via swift-users]

The one that comes with SwiftFoundation 
(https://github.com/apple/swift-corelibs-foundation/tree/master/CoreFoundation 
).

I think it should be a bug that CFReadStream cannot be bridged to 
(NS)InputStream, as otherwise there’s no way to intertwine Sockets (CFSockets) 
with SwiftFoundation. As the implementation already uses a CFReadStream 
internally 
(https://github.com/apple/swift-corelibs-foundation/blob/d3872cb094124d5dd189839505ae73e2fa717cfd/Foundation/NSStream.swift#L122
 
),
 it would be a matter of adding an initializer. However the value is private, 
so adding the initializer cannot be done from an extension.

—
Bouke

> On 21 Sep 2016, at 21:22, Jens Alfke  wrote:
> 
> 
>> On Sep 20, 2016, at 9:38 PM, Bouke Haarsma via swift-users 
>> > wrote:
>> 
>> When working with CoreFoundation objects (e.g. CFReadStream, CFWriteStream) 
>> it isn't immediately obvious to me how to bridge them to SwiftFoundation 
>> counterparts (InputStream / OutputStream).
>> 
>> The following works on OSX, but doesn't work on Linux;
> 
> What implementation of CF are you using on Linux? OpenStep?
> 
> The bridging between Swift and Obj-C Foundation classes is only implemented 
> on Apple platforms. It’s not part of the open source release. The plan is to 
> implement classes like InputStream in native Swift as part of the standard 
> library; that work is in progress.
> 
> —Jens

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

Re: [swift-users] How to bridge between CoreFoundation and SwiftFoundation on Linux?

[Jens Alfke via swift-users]

> On Sep 20, 2016, at 9:38 PM, Bouke Haarsma via swift-users 
>  wrote:
> 
> When working with CoreFoundation objects (e.g. CFReadStream, CFWriteStream) 
> it isn't immediately obvious to me how to bridge them to SwiftFoundation 
> counterparts (InputStream / OutputStream).
> 
> The following works on OSX, but doesn't work on Linux;

What implementation of CF are you using on Linux? OpenStep?

The bridging between Swift and Obj-C Foundation classes is only implemented on 
Apple platforms. It’s not part of the open source release. The plan is to 
implement classes like InputStream in native Swift as part of the standard 
library; that work is in progress.

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

[swift-users] Cross-Compiling to Linux from macOS

[Rafael Costa via swift-users]

Hello fellow Swift users,

I’m encountering some problems and I wish to know if anyone here has ever come 
across something similar.

In essence, I want to cross-compile a Swift Project on macOS to run it on 
Linux. I’m using the following command to (try) to do so:

swift build -c release --build-path ./.build/linux -Xswiftc -static-stdlib 
-Xswiftc -target -Xswiftc x86_64-unknown-linux-gnu 

The “target” parameter is passing to the “swiftc” program just fine. The 
problem is that it is overwritten by a “target” parameter added automatically 
by swift-build (that sets the target as the same arch/OS as the host machine)

How can I prevent that? Is it possible to cross-compile for Linux on macOS?

Thanks in advance,
Rafael Costa
raf...@rafaelcosta.me



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

Re: [swift-users] Ubuntu 16.04 support?

[Mishal Shah via swift-users]

I should have Ubuntu 16.04 system available on ci.swift.org by end of day.

Thanks,
Mishal Shah

> On Sep 21, 2016, at 9:25 AM, Todd Fiala  wrote:
> 
> Hmm, likes get a JIRA tracking this if we don’t have one already.
> 
> Mishal, what’s the current ETA on the Ubuntu 16.04 switch-over?
> 
> -Todd
> 
>> On Sep 21, 2016, at 9:11 AM, Michael Gottesman  wrote:
>> 
>> +CC Todd.
>> 
>>> On Sep 20, 2016, at 9:25 PM, Ron Olson via swift-users 
>>>  wrote:
>>> 
>>> Hmm, I don’t get that at all:
>>> 
>>> Welcome to Swift version 3.0 (swift-3.0-RELEASE). Type :help for assistance.
>>> 1> import Foundation
>>> 2> NSURL(string:"http://swift.org;)
>>> $R0: Foundation.NSURL? = 0x00427f00 {
>>> Foundation.NSObject = {}
>>> _base = {
>>> info = 7552
>>> pad = 0
>>> }
>>> _flags = 536887337
>>> _encoding = 0
>>> _string = 0x00427bd0 -> 0x7475d720 full type metadata for 
>>> Foundation.NSString + 16
>>> _baseURL = nil
>>> _extra = nil
>>> _resourceInfo = nil
>>> _range1 = {
>>> location = 0
>>> length = 4
>>> }
>>> _range2 = {
>>> location = 7
>>> length = 9
>>> }
>>> 
>>> … more of the same …
>>> 
>>> On 20 Sep 2016, at 22:28, Bouke Haarsma via swift-users wrote:
>>> 
>>> 
>>> On 2016-09-20 16:37:18 +, Lane Schwartz via swift-users said:
>>> 
>>> In addition to the installation instructions per swift.org, I also needed 
>>> to install "libpython2.7-dev". When starting the Swift REPL it threw the 
>>> following error;
>>> 
>>> ...swift/usr/bin/lldb: error while loading shared libraries: 
>>> libpython2.7.so.1.0: cannot open shared object file: No such file or 
>>> directory
>>> 
>>> Installing that package resolved that issue. However the REPL loads, it 
>>> throws errors like this:
>>> 
>>> ubuntu-1604:~$ swift
>>> Welcome to Swift version 3.0 (swift-3.0-RELEASE). Type :help for assistance.
>>>   1> import Foundation
>>>   2> NSURL(string: "http://swift.org;)
>>> error: Couldn't lookup symbols:
>>>   type metadata accessor for Foundation.NSURL
>>>   Foundation.NSURL.__allocating_init (string : Swift.String) -> 
>>> Swift.Optional
>>> 
>>> I've downgraded to 14.04 LTS.
>>> 
>>> Thanks.
>>> 
>>> 
>>> On Tue, Sep 20, 2016 at 11:28 AM, Ron Olson via swift-users 
>>>  wrote:
>>> I downloaded the Ubuntu 15 release.
>>> 
>>> On 20 Sep 2016, at 11:26, Lane Schwartz wrote:
>>> 
>>> Thanks, Ron. Which binary release did you download? The ubuntu 15 release? 
>>> Or the 14 release?
>>> 
>>> On Tue, Sep 20, 2016 at 11:12 AM, Ron Olson via swift-users 
>>>  wrote:
>>> I can verify that the 3.0 Release works under 16; I downloaded it this 
>>> morning and it works fine.
>>> 
>>> 
>>> On 20 Sep 2016, at 11:10, Lane Schwartz via swift-users wrote:
>>> 
>>> I see that there are swift packages for Ubuntu 14 and 15, but not 16. Is
>>> Swift 3.0 known to work with Ubuntu 16? Can either of the aforementioned
>>> binary releases be used, or is compilation from source required?
>>> 
>>> 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
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> 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
>>> 
>>> 
>>> -- 
>>> -Bouke
>>> ___
>>> 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] Ubuntu 16.04 support?

[Michael Gottesman via swift-users]

+CC Todd.

> On Sep 20, 2016, at 9:25 PM, Ron Olson via swift-users 
>  wrote:
> 
> Hmm, I don’t get that at all:
> 
> Welcome to Swift version 3.0 (swift-3.0-RELEASE). Type :help for assistance.
> 1> import Foundation
> 2> NSURL(string:"http://swift.org; )
> $R0: Foundation.NSURL? = 0x00427f00 {
> Foundation.NSObject = {}
> _base = {
> info = 7552
> pad = 0
> }
> _flags = 536887337
> _encoding = 0
> _string = 0x00427bd0 -> 0x7475d720 full type metadata for 
> Foundation.NSString + 16
> _baseURL = nil
> _extra = nil
> _resourceInfo = nil
> _range1 = {
> location = 0
> length = 4
> }
> _range2 = {
> location = 7
> length = 9
> }
> 
> … more of the same …
> 
> On 20 Sep 2016, at 22:28, Bouke Haarsma via swift-users wrote:
> 
> 
> On 2016-09-20 16:37:18 +, Lane Schwartz via swift-users said:
> 
> In addition to the installation instructions per swift.org, I also needed to 
> install "libpython2.7-dev". When starting the Swift REPL it threw the 
> following error;
> 
> ...swift/usr/bin/lldb: error while loading shared libraries: 
> libpython2.7.so.1.0: cannot open shared object file: No such file or directory
> 
> Installing that package resolved that issue. However the REPL loads, it 
> throws errors like this:
> 
> ubuntu-1604:~$ swift
> Welcome to Swift version 3.0 (swift-3.0-RELEASE). Type :help for assistance.
>   1> import Foundation
>   2> NSURL(string: "http://swift.org;)
> error: Couldn't lookup symbols:
>   type metadata accessor for Foundation.NSURL
>   Foundation.NSURL.__allocating_init (string : Swift.String) -> 
> Swift.Optional
> 
> I've downgraded to 14.04 LTS.
> 
> Thanks.
> 
> 
> On Tue, Sep 20, 2016 at 11:28 AM, Ron Olson via swift-users 
> > wrote:
> I downloaded the Ubuntu 15 release.
> 
> On 20 Sep 2016, at 11:26, Lane Schwartz wrote:
> 
> Thanks, Ron. Which binary release did you download? The ubuntu 15 release? Or 
> the 14 release?
> 
> On Tue, Sep 20, 2016 at 11:12 AM, Ron Olson via swift-users 
> > wrote:
> I can verify that the 3.0 Release works under 16; I downloaded it this 
> morning and it works fine.
> 
> 
> On 20 Sep 2016, at 11:10, Lane Schwartz via swift-users wrote:
> 
> I see that there are swift packages for Ubuntu 14 and 15, but not 16. Is
> Swift 3.0 known to work with Ubuntu 16? Can either of the aforementioned
> binary releases be used, or is compilation from source required?
> 
> 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 
> 
> 
> 
> 
> 
> -- 
> 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
> 
> 
> -- 
> -Bouke
> ___
> 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] Bls: reading keyboard input from xcode playgroud

[Jeremy Pereira via swift-users]

> On 20 Sep 2016, at 17:54, Mr Bee via swift-users  
> wrote:
> 
> I knew it's a bug, hence this email.
> 
> 
> Pada Selasa, 20 September 2016 21:13, Zhao Xin  menulis:
> 
> 
> I test you code in command line `swiftc main.swift` and in macOS Command Line 
> Tool app.
> 
> Here is the main.swift:
> 
> import Foundation
> 
> import Foundation
> 
> func input() -> String {
> let keyboard  = FileHandle.standardInput
> let inputData = keyboard.availableData
> let strData   = String(data: inputData, encoding: .utf8)
> return strData!
> }
> 
> func write(_ txt: String) {
> print(txt, terminator: "")
> }
> 
> func read() -> String {
> let c = CharacterSet.whitespacesAndNewlines
> return input().trimmingCharacters(in: c)
> }
> 
> /* main program */
> 
> write("Enter your name: ")
> let s = read()
> print("You name is \(s)")
> 
> It turns out that the input request was ran before the `write("Enter your 
> name: ")`. I don't why. Maybe it is a bug?

For what it’s worth, this is not a bug, it’s an artefact of the way character 
IO works. stdio streams are either buffered, unbuffered or line buffered. The 
stdout stream is line buffered so the output “Enter your name:” sits in a 
buffer waiting for a line feed which doesn’t happen until the end of the print 
statement.

You can force stdout to flush itself with the c library call fflush(), i.e.

func write(_ txt: String) {
print(txt, terminator: "")
fflush(__stdoutp)
}

The reason why it works OK in the Xcode console must be because stdout is 
directed to a pipe instead of a terminal.I suspect the combination of this and 
how the pipe is read from the other end is what makes it work correctly.


> 
> Another question. I used to use this snippet to read keyboard input from 
> XCode's Playground. And it used to work very well. Today, I just updated my 
> XCode to v.8 and Swift v.3. After a little bit modification here and there 
> due to Swift 3 incompatibility, I got this code compiled without error. But 
> it doesn't work. No keyboard input is taken. It just stucks.

It hasn’t got stuck, put a print statement at the end and you’ll see it gets 
executed. The problem is that FileHandle.availableData returns immediately with 
empty data. According to the documentation this means that standard input has 
been closed. But it could also be the case that it is set to non blocking.

> 
> 
> ___
> 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] Canonical way to cast C structs

[Quinn "The Eskimo!" via swift-users]

On 21 Sep 2016, at 06:45, Bouke Haarsma via swift-users  
wrote:

> This property is not available on Linux …

Hey, it’s call /BSD/ Sockets for a reason (-:

Honestly, I don’t think there’s a good way to maintain the simplicity of this 
abstraction without `ss_len`.  Special casing each address format isn’t viable 
because some addresses are of variable length (I’m looking at you 
`sockaddr_un`!).

You’re going to have to carry around a `sockaddr_storage` /and/ a `socklen_t`, 
and if you’re doing that it’d probably be best to build your own abstraction.  
When I originally wrote these helpers I was doing so in the context of a 
`QSocket` class, which had a `QSocket.Address` struct that wrapped 
`sockaddr_storage`, and that abstraction would have been able to cope with this.

Share and Enjoy
--
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware


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