Re: [swift-users] Still having trouble with C interop (passing buffers)

2017-04-25 Thread Rick Mann via swift-users
Yup, that seems to be it. I would have thought that init(capacity:) should 
work, too (it could defer allocation until, say, the call 
withUnsafeMutableBytes()), and just not zero the contents (the init(count:) 
call zeroes the contents).

> On Apr 25, 2017, at 15:20 , Philippe Hausler  wrote:
> 
> 
>> On Apr 25, 2017, at 2:57 PM, Rick Mann via swift-users 
>>  wrote:
>> 
>> I'm trying to pass a Data of allocated size to a C function for it to fill 
>> in:
>> 
>> 
>> lib_example_call(_ params: UnsafePointer!, _ data: 
>> UnsafeMutableRawPointer!)
>> 
>> ...
>> {
>>   self.dataBuffer = Data(capacity: BufferSizeConstant)
> 
> 
> If you want to create a buffer with a given count you should use Data(count: 
> Int), the method you are using just reserves a given capacity. (from what I 
> can tell from your code that is likely what you really want)
> 
>> 
>>   var params = lib_call_params_t();
>>   params.data_capacity = BufferSizeConstant;
>> 
>>   self.dataBuffer?.withUnsafeMutableBytes
>>   { (inBuffer) -> Void in
>>   lib_example_call(¶ms, inBuffer)
>>   }
>> }
>> 
>> I later get called back by the library with a size value of the actual data 
>> it got. self.dataBuffer is a var. I set self.dataBuffer?.count = result 
>> size, which is a reasonable value.
>> 
>> Unfortunately, the resulting buffer is all zeros. The data generated by the 
>> call is definitely not all zero, and a C example program using the same 
>> library works correctly.
>> 
>> So, I think there's something wrong in the way I'm making the call.
>> 
>> Can anyone please enlighten me? Thanks!
>> 
>> -- 
>> Rick Mann
>> rm...@latencyzero.com
>> 
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
> 


-- 
Rick Mann
rm...@latencyzero.com


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


Re: [swift-users] Still having trouble with C interop (passing buffers)

2017-04-25 Thread Philippe Hausler via swift-users

> On Apr 25, 2017, at 2:57 PM, Rick Mann via swift-users 
>  wrote:
> 
> I'm trying to pass a Data of allocated size to a C function for it to fill in:
> 
> 
> lib_example_call(_ params: UnsafePointer!, _ data: 
> UnsafeMutableRawPointer!)
> 
> ...
> {
>self.dataBuffer = Data(capacity: BufferSizeConstant)


If you want to create a buffer with a given count you should use Data(count: 
Int), the method you are using just reserves a given capacity. (from what I can 
tell from your code that is likely what you really want)

> 
>var params = lib_call_params_t();
>params.data_capacity = BufferSizeConstant;
> 
>self.dataBuffer?.withUnsafeMutableBytes
>{ (inBuffer) -> Void in
>lib_example_call(¶ms, inBuffer)
>}
> }
> 
> I later get called back by the library with a size value of the actual data 
> it got. self.dataBuffer is a var. I set self.dataBuffer?.count = result size, 
> which is a reasonable value.
> 
> Unfortunately, the resulting buffer is all zeros. The data generated by the 
> call is definitely not all zero, and a C example program using the same 
> library works correctly.
> 
> So, I think there's something wrong in the way I'm making the call.
> 
> Can anyone please enlighten me? Thanks!
> 
> -- 
> Rick Mann
> rm...@latencyzero.com
> 
> 
> ___
> 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] Still having trouble with C interop (passing buffers)

2017-04-25 Thread Rick Mann via swift-users
I'm trying to pass a Data of allocated size to a C function for it to fill in:


lib_example_call(_ params: UnsafePointer!, _ data: 
UnsafeMutableRawPointer!)

...
{
self.dataBuffer = Data(capacity: BufferSizeConstant)

var params = lib_call_params_t();
params.data_capacity = BufferSizeConstant;

self.dataBuffer?.withUnsafeMutableBytes
{ (inBuffer) -> Void in
lib_example_call(¶ms, inBuffer)
}
}

I later get called back by the library with a size value of the actual data it 
got. self.dataBuffer is a var. I set self.dataBuffer?.count = result size, 
which is a reasonable value.

Unfortunately, the resulting buffer is all zeros. The data generated by the 
call is definitely not all zero, and a C example program using the same library 
works correctly.

So, I think there's something wrong in the way I'm making the call.

Can anyone please enlighten me? Thanks!

-- 
Rick Mann
rm...@latencyzero.com


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


Re: [swift-users] Performance in Trunk builds vs 3.1.1

2017-04-25 Thread Slava Pestov via swift-users
Can you share the code for your benchmark?

Slava

> On Apr 25, 2017, at 6:34 AM, Proyb P via swift-users  
> wrote:
> 
> I have testing the performance between trunk builds downloaded from Swift 
> website (April 22 and 24) and 3.1.1
> 
> Fibonacci (N: 50) benchmark:
> Trunk (22 Apr): 1m13s
> Trunk (24 Apr): 1m16s
> 3.1.1: 1m7s
> 
> I assume there are overhead in trunk build? There is a big regression.
> ___
> 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] Atomics and Memory Fences in Swift

2017-04-25 Thread Shawn Erickson via swift-users
On Mon, Dec 5, 2016 at 9:28 AM Joe Groff via swift-users <
swift-users@swift.org> wrote:

>
> On Dec 4, 2016, at 4:53 PM, Andrew Trick via swift-users <
> swift-users@swift.org> wrote:
>
>
> On Nov 30, 2016, at 5:40 AM, Anders Ha via swift-users <
> swift-users@swift.org> wrote:
>
> Hi guys
>
> I have recently started adopting lock-free atomics with memory fences, but
> it seems Swift at this moment does not have any native instruments.
>
> Then I read a thread in the Apple Developer Forum (
> https://forums.developer.apple.com/thread/49334), which an Apple staff
> claimed that all imported atomic operations are "not guaranteed to be
> atomic". But for my tests with all optimizations enabled (-Owholemodule and
> -O), the OSAtomic primitives and stdatomic fences do not seem going wild.
>
> Is these `atomic_*` and `OSAtomic*` primitives really unsafe in Swift as
> claimed? It doesn't seem like the Swift compiler would reorder memory
> accesses around a C function call that it wouldn't be able to see through.
>
>
> Did you get an answer to this? I’m not sure what led you to believe the
> primitives are unsafe in Swift. Importing them doesn’t change their
> semantics.
>
>
> If you apply them to memory you allocated manually with malloc/free on
> UnsafeMutablePointer's allocation methods, then yeah, they should work as
> they do in C. That's the safest way to use these functions today. Passing a
> Swift `var` inout to one of these functions does not guarantee that
> accesses to that var will maintain atomicity, since there may be bridging
> or reabstracting conversions happening under the hood.
>
> -Joe
>

Is the following in the ball park of being correct (going back over some
old code we have)...

public struct AtomicBool {

private static let bitLocation: UInt32 = 0
private static let trueValue: UInt8 = 0x80
private static let falseValue: UInt8 = 0x00

private let value = UnsafeMutablePointer.allocate(capacity: 1)
// TODO - leaking right? How to deal with that in a struct situation...?
public var onSet: ((_ old: Bool, _ new: Bool) -> ())?

public init(_ intialValue: Bool = false) {
value.initialize(to: intialValue ? AtomicBool.trueValue :
AtomicBool.falseValue)
onSet = nil
}

public init(_ intialValue: Bool = false, onSet: ((_ old: Bool, _ new:
Bool) -> ())?) {
value.initialize(to: intialValue ? AtomicBool.trueValue :
AtomicBool.falseValue)
self.onSet = onSet
}

public mutating func set(_ newValue: Bool) {
_ = getAndSet(newValue)
}

public mutating func getAndSet(_ newValue: Bool) -> Bool {
let oldValue: Bool
if newValue {
oldValue =
Darwin.OSAtomicTestAndSetBarrier(AtomicBool.bitLocation, value)
}
else {
oldValue =
Darwin.OSAtomicTestAndClearBarrier(AtomicBool.bitLocation, value)
}

onSet?(oldValue, newValue)
return oldValue
}

public func get() -> Bool { // TODO - document the lazy "safety" aspect
of get
return value.pointee != AtomicBool.falseValue
}

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


[swift-users] Performance in Trunk builds vs 3.1.1

2017-04-25 Thread Proyb P via swift-users
I have testing the performance between trunk builds downloaded from Swift
website (April 22 and 24) and 3.1.1

Fibonacci (N: 50) benchmark:
Trunk (22 Apr): 1m13s
Trunk (24 Apr): 1m16s
3.1.1: 1m7s

I assume there are overhead in trunk build? There is a big regression.
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users


Re: [swift-users] Data fix for Linux

2017-04-25 Thread Tim Hawkins via swift-users
Do you know if that will include a backend for grandcentral to support
epoll instead of kqueue/kevent? The later is not supported on many linux
distros.

I wish swift supported fedora directly instead of all the hacks i have to
do to get it to work.

On Tue, Apr 25, 2017, 00:21 Proyb P via swift-users 
wrote:

> There is an official release (April 21 2017) for 3.1.1 for Ubuntu on
> Swift download page.
>
>
> On Monday, 24 April 2017, Bridger Maxwell via swift-users <
> swift-users@swift.org> wrote:
>
>> Swift 3.1 contained a bug in Data which causes memory corruption when
>> using methods like base64EncodedString. The Data bug is referenced in this
>> Jira bug which says it is fixed in the 3.1 branch.
>> https://bugs.swift.org/browse/SR-4435
>>
>> Will there be a 3.1.1 release for Linux soon? I see a release tag but I
>> can't find any discussion around timing.
>> https://github.com/apple/swift/releases/tag/swift-3.1.1-RELEASE
>>
>> - Bridger Maxwell
>>
> ___
> 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] Atomics and Memory Fences in Swift

2017-04-25 Thread Anders Ha via swift-users
What about `withUnsafeMutablePointer` on a stored object property, marked with 
`final`? e.g. `withUnsafeMutablePointer(to: &object.lock, os_unfair_lock_lock)`.

The generated object code with `-Owmo` shows that it is optimised to an address 
calculation immediately followed by a call to `os_unfair_lock_lock`. But I am 
not quite sure about its behaviour with no optimisation flag.


Regards,
Anders

> On 6 Dec 2016, at 1:27 AM, Joe Groff  wrote:
> 
>> 
>> On Dec 4, 2016, at 4:53 PM, Andrew Trick via swift-users 
>> mailto:swift-users@swift.org>> wrote:
>> 
>> 
>>> On Nov 30, 2016, at 5:40 AM, Anders Ha via swift-users 
>>> mailto:swift-users@swift.org>> wrote:
>>> 
>>> Hi guys
>>> 
>>> I have recently started adopting lock-free atomics with memory fences, but 
>>> it seems Swift at this moment does not have any native instruments.
>>> 
>>> Then I read a thread in the Apple Developer Forum 
>>> (https://forums.developer.apple.com/thread/49334 
>>> ), which an Apple staff 
>>> claimed that all imported atomic operations are "not guaranteed to be 
>>> atomic". But for my tests with all optimizations enabled (-Owholemodule and 
>>> -O), the OSAtomic primitives and stdatomic fences do not seem going wild.
>>> 
>>> Is these `atomic_*` and `OSAtomic*` primitives really unsafe in Swift as 
>>> claimed? It doesn't seem like the Swift compiler would reorder memory 
>>> accesses around a C function call that it wouldn't be able to see through.
>> 
>> Did you get an answer to this? I’m not sure what led you to believe the 
>> primitives are unsafe in Swift. Importing them doesn’t change their 
>> semantics.
> 
> If you apply them to memory you allocated manually with malloc/free on 
> UnsafeMutablePointer's allocation methods, then yeah, they should work as 
> they do in C. That's the safest way to use these functions today. Passing a 
> Swift `var` inout to one of these functions does not guarantee that accesses 
> to that var will maintain atomicity, since there may be bridging or 
> reabstracting conversions happening under the hood.
> 
> -Joe

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


Re: [swift-users] withUnsafeMutableBytes is killing me

2017-04-25 Thread Ole Begemann via swift-users

On 25.04.2017 12:24, Rick Mann via swift-users wrote:

Not the ResultType, you mean, but the input type, right?


Yes, sorry, I meant ContentType.


Yeah, I finally figured that out, although it doesn't explain another situation 
I'm experiencing that I didn't include in the post.

However, that doesn't explain why it can't infer it in the last example.


On Apr 25, 2017, at 02:58 , Ole Begemann  wrote:

The withUnsafeMutableBytes method has two generic parameters, ResultType and 
ContentType:

mutating func withUnsafeMutableBytes(_ body: 
(UnsafeMutablePointer) throws -> ResultType) rethrows -> ResultType

In your examples, the type checker can't infer the type of ResultType. You'll 
have to state it explicitly by specifying the type of the closure's argument. 
For example:

msg.withUnsafeMutableBytes {
 (inPointer
: UnsafeMutablePointer
) -> Void in
 // ...
}


On 25.04.2017 10:45, Rick Mann via swift-users wrote:

The following playground reproduces an issue I'm having, in that the code won't 
compile depending on the content of the closure. In fact, an empty closure is 
fine, but when I try to call certain things, it's not.

I figure it has something to do with the type inference for inPointer, but I 
can't figure out what it needs to work.

---
import Foundation

//  OKAY:

var msg = Data(capacity: 123456)
msg.withUnsafeMutableBytes
{ (inPointer) -> Void in
foo(inPointer)
}

//error: cannot convert value of type '(_) -> Void' to expected argument type 
'(UnsafeMutablePointer<_>) -> _'
//{ (inPointer) -> Void in
//^~~~

msg.withUnsafeMutableBytes
{ (inPointer) -> Void in
}

//error: cannot convert value of type '(_) -> Void' to expected argument type 
'(UnsafeMutablePointer<_>) -> _'
//{ (inPointer) -> Void in
//^~~~

msg.withUnsafeMutableBytes
{ (inPointer) -> Void in
var s: Int
lgs_error(inPointer, 123456, &s)
}

func
foo(_ data: UnsafeMutableRawPointer!)
{
}

func
lgs_error(_ message: UnsafeMutablePointer!,
_ message_capacity: Int,
_ message_size: UnsafeMutablePointer!) -> Int
{
}
---

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


Re: [swift-users] withUnsafeMutableBytes is killing me

2017-04-25 Thread Rick Mann via swift-users
Not the ResultType, you mean, but the input type, right? Yeah, I finally 
figured that out, although it doesn't explain another situation I'm 
experiencing that I didn't include in the post.

However, that doesn't explain why it can't infer it in the last example.

> On Apr 25, 2017, at 02:58 , Ole Begemann  wrote:
> 
> The withUnsafeMutableBytes method has two generic parameters, ResultType and 
> ContentType:
> 
> mutating func withUnsafeMutableBytes(_ body: 
> (UnsafeMutablePointer) throws -> ResultType) rethrows -> 
> ResultType
> 
> In your examples, the type checker can't infer the type of ResultType. You'll 
> have to state it explicitly by specifying the type of the closure's argument. 
> For example:
> 
> msg.withUnsafeMutableBytes {
> (inPointer
> : UnsafeMutablePointer
> ) -> Void in
> // ...
> }
> 
> 
> On 25.04.2017 10:45, Rick Mann via swift-users wrote:
>> The following playground reproduces an issue I'm having, in that the code 
>> won't compile depending on the content of the closure. In fact, an empty 
>> closure is fine, but when I try to call certain things, it's not.
>> 
>> I figure it has something to do with the type inference for inPointer, but I 
>> can't figure out what it needs to work.
>> 
>> ---
>> import Foundation
>> 
>> //   OKAY:
>> 
>> var msg = Data(capacity: 123456)
>> msg.withUnsafeMutableBytes
>> { (inPointer) -> Void in
>>  foo(inPointer)
>> }
>> 
>> //error: cannot convert value of type '(_) -> Void' to expected argument 
>> type '(UnsafeMutablePointer<_>) -> _'
>> //{ (inPointer) -> Void in
>> //^~~~
>> 
>> msg.withUnsafeMutableBytes
>> { (inPointer) -> Void in
>> }
>> 
>> //error: cannot convert value of type '(_) -> Void' to expected argument 
>> type '(UnsafeMutablePointer<_>) -> _'
>> //{ (inPointer) -> Void in
>> //^~~~
>> 
>> msg.withUnsafeMutableBytes
>> { (inPointer) -> Void in
>>  var s: Int
>>  lgs_error(inPointer, 123456, &s)
>> }
>> 
>> func
>> foo(_ data: UnsafeMutableRawPointer!)
>> {
>> }
>> 
>> func
>> lgs_error(_ message: UnsafeMutablePointer!,
>>  _ message_capacity: Int,
>>  _ message_size: UnsafeMutablePointer!) -> Int
>> {
>> }
>> ---
>> 


-- 
Rick Mann
rm...@latencyzero.com


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


Re: [swift-users] withUnsafeMutableBytes is killing me

2017-04-25 Thread Ole Begemann via swift-users
The withUnsafeMutableBytes method has two generic parameters, ResultType 
and ContentType:


|mutating func withUnsafeMutableBytes(_ body: 
(UnsafeMutablePointer 
) 
throws -> ResultType) rethrows -> ResultType|



In your examples, the type checker can't infer the type of ResultType. 
You'll have to state it explicitly by specifying the type of the 
closure's argument. For example:


msg.withUnsafeMutableBytes {
(inPointer*: UnsafeMutablePointer*) -> Void in
// ...
}


On 25.04.2017 10:45, Rick Mann via swift-users wrote:

The following playground reproduces an issue I'm having, in that the code won't 
compile depending on the content of the closure. In fact, an empty closure is 
fine, but when I try to call certain things, it's not.

I figure it has something to do with the type inference for inPointer, but I 
can't figure out what it needs to work.

---
import Foundation

//  OKAY:

var msg = Data(capacity: 123456)
msg.withUnsafeMutableBytes
{ (inPointer) -> Void in
foo(inPointer)
}

//error: cannot convert value of type '(_) -> Void' to expected argument type 
'(UnsafeMutablePointer<_>) -> _'
//{ (inPointer) -> Void in
//^~~~

msg.withUnsafeMutableBytes
{ (inPointer) -> Void in
}

//error: cannot convert value of type '(_) -> Void' to expected argument type 
'(UnsafeMutablePointer<_>) -> _'
//{ (inPointer) -> Void in
//^~~~

msg.withUnsafeMutableBytes
{ (inPointer) -> Void in
var s: Int
lgs_error(inPointer, 123456, &s)
}

func
foo(_ data: UnsafeMutableRawPointer!)
{
}

func
lgs_error(_ message: UnsafeMutablePointer!,
_ message_capacity: Int,
_ message_size: UnsafeMutablePointer!) -> Int
{
}
---
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users


[swift-users] withUnsafeMutableBytes is killing me

2017-04-25 Thread Rick Mann via swift-users
The following playground reproduces an issue I'm having, in that the code won't 
compile depending on the content of the closure. In fact, an empty closure is 
fine, but when I try to call certain things, it's not.

I figure it has something to do with the type inference for inPointer, but I 
can't figure out what it needs to work.

---
import Foundation

//  OKAY:

var msg = Data(capacity: 123456)
msg.withUnsafeMutableBytes
{ (inPointer) -> Void in
foo(inPointer)
}

//error: cannot convert value of type '(_) -> Void' to expected argument type 
'(UnsafeMutablePointer<_>) -> _'
//{ (inPointer) -> Void in
//^~~~

msg.withUnsafeMutableBytes
{ (inPointer) -> Void in
}

//error: cannot convert value of type '(_) -> Void' to expected argument type 
'(UnsafeMutablePointer<_>) -> _'
//{ (inPointer) -> Void in
//^~~~

msg.withUnsafeMutableBytes
{ (inPointer) -> Void in
var s: Int
lgs_error(inPointer, 123456, &s)
}

func
foo(_ data: UnsafeMutableRawPointer!)
{
}

func
lgs_error(_ message: UnsafeMutablePointer!,
_ message_capacity: Int,
_ message_size: UnsafeMutablePointer!) -> Int
{
}
---


-- 
Rick Mann
rm...@latencyzero.com


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