Re: [swift-users] UnsafeMutablePointer Swift 3 conversion

2016-09-12 Thread Patrice Kouame via swift-users
Andy - yes thanks for the guidance and great job on your guide. There's a lot to absorb there. I think the metal samples are another great use case for your new apis. I have a small side project in mind to analyze its impact on performance, comparing the swift 3 compliant "safe" implementation

Re: [swift-users] UnsafeMutablePointer Swift 3 conversion

2016-09-08 Thread Gerard Iglesias via swift-users
Andrew, Thank you for the compliment ;) And thank you for the 2 advices And the question about use of size or stride ? I understand that the underlaying float data are aligned in this specific case, but I wonder in fact if the shader compiler align memory the same way the swift compiler do, I

Re: [swift-users] UnsafeMutablePointer Swift 3 conversion

2016-09-07 Thread Jacob Bandes-Storch via swift-users
> > My migration guide landed on swift.org today! I think it will be a big > help. > https://swift.org/migration-guide/se-0107-migrate.html > > -Andy > Thanks Andy, this is great! I hope that over time, even more accessible material is added for newcomers. I still feel I would have a hard time

Re: [swift-users] UnsafeMutablePointer Swift 3 conversion

2016-09-03 Thread Patrice Kouame via swift-users
Cool. Another approach. Never thought of using assumingMemoryBound. Need to read up on that. I wonder how both versions compare from a safety/security/performance stand point. Behold the spinning cubes… ;-) P > > On Sep 3, 2016, at 9:03 PM, Gerard Iglesias via swift-users >

Re: [swift-users] UnsafeMutablePointer Swift 3 conversion

2016-09-03 Thread Patrice Kouame via swift-users
Ok, I see. But withMemoryRebound requires a return value. Don’t think there’s any way around that…compiler error And mainPtr (now typed correctly/safely) needs to access the appropriate data structure mainPassFrameData. Hence the external mainPtr.pointee assignment (since I can’t do so safely

Re: [swift-users] UnsafeMutablePointer Swift 3 conversion

2016-09-03 Thread Jacob Bandes-Storch via swift-users
I was referring to this: let mainPtr : UnsafeMutablePointer = shadowPtr.advanced (by: 1).withMemoryRebound(to: MainPass.self, capacity: 1) {$0} mainPtr.pointee = mainPassFrameData The result of $0 is being returned from the block and used later. cc'ing Andrew Trick on this

Re: [swift-users] UnsafeMutablePointer Swift 3 conversion

2016-09-03 Thread Gerard Iglesias via swift-users
This is my funny version… I succeeded and I didn’t come back to find an other way… // Grab a pointer to the constant buffer's data store // Since we are using Swift, it is easier to cast the pointer to the ShadowPass type to fill the constant buffer // We need to make a copy of these so the

Re: [swift-users] UnsafeMutablePointer Swift 3 conversion

2016-09-03 Thread Patrice Kouame via swift-users
Not sure what you mean? The positional arg $0 is never used outside the closure whatever the version... No attempt is ever made to save and reuse after withMemoryRebound? Why would I use a separate function? Are we looking at the same code? 邏 rédigé sur mon iPhone. > On Sep 3, 2016, at 4:16

Re: [swift-users] UnsafeMutablePointer Swift 3 conversion

2016-09-03 Thread Jacob Bandes-Storch via swift-users
Yikes! That's unsafe! When using withMemoryRebound, I think you're only supposed to use the argument $0 inside the block. Saving it and using it after withMemoryRebound is probably undefined behavior. But maybe you can move your ".pointee = x" into a separate function rather than using a closure?

Re: [swift-users] UnsafeMutablePointer Swift 3 conversion

2016-09-03 Thread Patrice Kouame via swift-users
Finally Success! I’m seeing my pretty little 3D twirling Metal Renderer cubes again… Here’s how Snippet of old sample code which no longer compiles in Xcode 8 beta 6 with stricter Swift3 unsafe type casting restrictions (in MetalView.swift from # Adopting Metal II: Designing and Implementing

Re: [swift-users] UnsafeMutablePointer Swift 3 conversion

2016-09-03 Thread Gerard Iglesias via swift-users
Ok For the record I succeeded this transformation phase last week I remember the tedious stuff to advance pointer from one struct to the other kind of struct... it worked But I don't have my MacBook with me, only the phone, the six :) Gérard > Le 3 sept. 2016 à 18:22, Patrice Kouame

Re: [swift-users] UnsafeMutablePointer Swift 3 conversion

2016-09-03 Thread Patrice Kouame via swift-users
Indeed. There is a difference between stride and size, but I interpreted capacity incorrectly for my purposes. It should indicate the number of elements (not their size - right?) and the snippets below should work. Still, compiler crashes and Xcode IDE is left in inconsistent state. So I

Re: [swift-users] UnsafeMutablePointer Swift 3 conversion

2016-09-03 Thread Gerard Iglesias via swift-users
Hello, I think that it is more secure to use stride in place of size, sometimes it is not the same value. I use it in my own use of raw bindings Regards Gérard > Le 3 sept. 2016 à 10:03, Patrice Kouame via swift-users > a écrit : > > Hi Jacob - > > I think

Re: [swift-users] UnsafeMutablePointer Swift 3 conversion

2016-09-03 Thread Patrice Kouame via swift-users
Hi Jacob - I think you’re right. “capacity” should be the count of type T elements in my buffer. So in my case that line should read let shadowPtr = constantBufferForFrame.contents().bindMemory(to: ShadowPass.self, capacity: shadowPassData.count) The withMemoryRebound calls need

Re: [swift-users] UnsafeMutablePointer Swift 3 conversion

2016-09-03 Thread Jacob Bandes-Storch via swift-users
Hi Patrice, I don't have a solution for you, but I just wanted to point out what I think may be an error with your use of the new UnsafeRawPointer APIs: constantBufferForFrame.contents().bindMemory(to: ShadowPass.self, capacity: MemoryLayout.size) I believe the `capacity` should actually be the