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

[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)

[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)

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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