Re: [swift-users] Memory Address of value types and reference types

[Taylor Swift via swift-users]

i think this is something that’s mostly important for educational purposes and 
the fact that Swift is mostly opaque to memory makes it harder to teach. 

> On Sep 12, 2017, at 12:19 PM, Andrew Trick via swift-users 
>  wrote:
> 
> 
>> On Sep 12, 2017, at 9:55 AM, somu subscribe via swift-users 
>>  wrote:
>> 
>> Hi Quinn,
>> 
>> Thanks for the reply,
>> 
>> It is an iOS Swift project (uses Foundation, UIKit, CloudKit and other 
>> native frameworks) in which I would like to check the memory address for 
>> debugging (and out of enthusiasm). There is no C code I am using.
>> 
>> I have some asynchronous call back functions from CloudKit frameworks which 
>> return CKUserIdentity objects.
>> 
>> So thought it would be nice if I could print the memory address of 
>> CKUserIdentity objects and to check if it was unique.
>> 
>> And there are some other custom Swift Structs which I would like to know the 
>> memory address of.
>> 
>> Thanks and regards,
>> Muthu
> 
> For classes, use the Unmanaged API as Quinn’s suggested.
> 
> Your structs, tuples, and enums only have an address during mutation. So, for 
> example, if you wrap all of your code in a function that takes the variable 
> `inout`, you’ll see a consistent address within a single call to that 
> function. There’s an implicit cast from `inout` to Unsafe[Mutable]Pointer 
> arguments, so you can inspect the pointer value...
> 
> func foo(p: Unsafe[Mutable]Pointer) { print(p) }
> 
> foo(&s2)
> 
> As you noticed, between calls to `foo` you could see a different address.
> 
> If you really want to give your structs an “identity” you would need to wrap 
> them in a class.
> 
> -Andy
> 
>>> On 12 Sep 2017, at 10:35 PM, Quinn The Eskimo! via swift-users 
>>>  wrote:
>>> 
>>> 
 On 12 Sep 2017, at 13:44, somu subscribe via swift-users 
  wrote:
 
 1. Is the above shown the correct way to get reference type memory address 
 ?
 2. What Is it the correct way to get value type memory address ?
>>> 
>>> It’s hard to answer that without knowing how you’re intended to use these 
>>> techniques.  If you can explain more about where you’re going with this, I 
>>> should be able to make some specific recommendations.
>>> 
>>> For example, if you’re goal were to pass a Swift object to a C API that 
>>> takes a callback function pointer and a ‘cookie’ value, and hen calls that 
>>> function with that cookie (like the `qsort_r` function), the to/from opaque 
>>> mechanism provider by `Unmanaged` is the recommended way to pass a Swift 
>>> object through such a cookie value.
>>> 
 3. Is it possible to get the memory address of immutable value type 
 (declared as let)
>>> 
>>> No, because such values don’t necessarily exist in memory.
>>> 
>>> 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
>> 
>> ___
>> 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] XML parsing on Linux, with Swift 3.1

[Taylor Swift via swift-users]

The CI builds on Swift 4, i believe it should work fine on master too but
it’s not tested there. Also I don’t think snake_case is C++ convention,
i’ve seen both. I use snake_case because camelCase looks too similar to
UpperCamelCase which is reserved for type names.

On Tue, Sep 5, 2017 at 3:43 AM, Georgios Moschovitis <
george.moschovi...@icloud.com> wrote:

> >
> > Foundation (NS)XML parsing is a little buggy and incomplete, check out
> github.com/kelvin13/swiftxml for a pure swift implementation
>
> Your implementation seems to be Swift4 only?
>
> -g.
>
> PS: Also, I am a bit put-off by some C/C++ coding conventions (e.g.
> snake_case)
>
> >
> >> On Sep 5, 2017, at 1:01 AM, Georgios Moschovitis via swift-users <
> swift-users@swift.org> wrote:
> >>
> >> Hi,
> >>
> >> I would like to parse an RSS feed using Swift 3.1 on Linux.
> >> I tried to use Foundations’s XML but I only managed to get segmentation
> faults.
> >> Is this supposed to work on Linux? I have only seen examples on iOS.
> >>
> >> Apart from that a quick search didn’t reveal any useful XML parsing
> library compatible with Linux.
> >>
> >> Any suggestions?
> >>
> >> -g.
> >> ___
> >> 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] XML parsing on Linux, with Swift 3.1

[Taylor Swift via swift-users]

Foundation (NS)XML parsing is a little buggy and incomplete, check out 
github.com/kelvin13/swiftxml for a pure swift implementation 

> On Sep 5, 2017, at 1:01 AM, Georgios Moschovitis via swift-users 
>  wrote:
> 
> Hi,
> 
> I would like to parse an RSS feed using Swift 3.1 on Linux.
> I tried to use Foundations’s XML but I only managed to get segmentation 
> faults. 
> Is this supposed to work on Linux? I have only seen examples on iOS.
> 
> Apart from that a quick search didn’t reveal any useful XML parsing library 
> compatible with Linux.
> 
> Any suggestions?
> 
> -g.
> ___
> 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] #if DEBUG on Linux

[Taylor Swift via swift-users]

#if DEBUG
print("debug")
#endif

Doesn’t work on Linux, I think only XCode sets this. How can I
conditionally include code that only runs in debug mode on Linux?

I know about `_isDebugAssertConfiguration()` but using it produces warnings
when building in release mode.
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] OpenGL function loader for Swift 4

[Taylor Swift via swift-users]

My library basically maintained the same idea as yours, except the code
generator is in pure Swift, the enums are all scoped under `GL`, and the
types are Swiftized. My PNG library 
depends on zlib though, instead of a pure Swift inflate implementation. No
Foundation dependency though. Adding JPEG and GIF support to complete a set
of Swift image codecs has been a long-term goal.

On Wed, Aug 16, 2017 at 9:30 PM, David Turnbull via swift-users <
swift-users@swift.org> wrote:

> SwiftGL was recently updated to Swift 3 by Justin Kolb. The repos work but
> the tutorial still has old code snips that need updating. Works on Linux,
> Mac, and WSL+Xming.
>
> Inside SwiftGL you'll find an OpenGL loader, a math library for vectors
> and matrices, and image decoders for PNG, GIF, and BMP. All Swift, even the
> inflate algorithm!
>
> http://www.swiftgl.org/
>
>
>> On Mon, Jun 26, 2017 at 7:40 PM, Taylor Swift 
>> wrote:
>>
>>> Hi all, I have released the Swift *OpenGL* library, a package that lets
>>> you interface with the GPU from Swift code. It’s intended to replace 
>>> Turnbull’s
>>> SGL library  which has been
>>> unmaintained since the days of Swift 2.0. Swift OpenGL is tested on Linux,
>>> it *should* work on OSX but I haven’t been able to test it on a Mac.
>>>
>>
>
> ___
> 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] [swift-evolution] How does "Sequence.joined" work?

[Taylor Swift via swift-users]

On Wed, Aug 9, 2017 at 10:43 AM, Daryle Walker via swift-evolution <
swift-evolut...@swift.org> wrote:

>
> On Aug 8, 2017, at 6:45 PM, Geordie Jay  wrote:
>
>
> Daryle Walker via swift-evolution  schrieb am
> Di. 8. Aug. 2017 um 21:25:
>
>> On Aug 8, 2017, at 12:35 AM, Félix Cloutier 
>> wrote:
>>
>> All this means is that `joined()` does not create an array that contains
>> the new result. It's only as magic as the COW semantics on arrays.
>>
>>
>> So you’re saying the COW semantics for Array and other standard library
>> types have secret references/pointers that work even for “let”-mode
>> objects, and the Sequence variants the various forms of “joined” need use a
>> Sequence/Collection of those secret references?
>>
>
> I know nothing about this specific type under the hood and your question
> stumped me when I first saw it as well, so take this with a grain of salt:
>
> I think it's basically just storing the arrays internally (as let) and
> when you iterate through the collection it just goes through the
> subsequences one by one, when the last index of the first is reached it
> begins with the next subsequence.
>
> As for how it avoids creating new storage, simple. As someone else
> mentioned, this is no more magic than Copy On Write for normal arrays.
>
> let a = [1,2,3]
> let b = a // this doesn't produce a copy of the underlying buffer.. I.e.
> value semantics but only one buffer needed
>
> ^^^ This is the take-home message. And your intuition about COW is
> correct: its internal storage is a reference type containing a buffer
> pointer. When (and only when) a mutation occurs, the buffer is copied and
> the new storage becomes the backing for the resulting struct. Any existing
> copies remain unchanged (and truly immutable) because they keep their
> original storage.
>
> https://github.com/apple/swift/blob/master/stdlib/public/core/
> ContiguousArrayBuffer.swift
>
>
> So with that understanding of COW, it becomes easy to imagine all sorts of
> containers that don't require additional storage for their contents:
>
> struct JoinedSequenceOfThreeArrays {
>   let array1: [T]
>   let array2: [T]
>   let array3: [T]
> }
>
> // still only one array buffer storage is required for all of this:
> let c = JoinedSequenceOfThreeArrays(array1: a, array2: a, array3: b)
>
> Does that make sense?
>
>
> Mostly, then I realized a flaw with this explanation. Your theory implies
> that “joined” avoids creating new storage by betraying that and actually
> copying the containers, but said containers use-COW/reference-remote-storage
> themselves. Then what happens when a Sequence uses scoped storage for its
> items? (Example: the mythical “just slap Collection on a tuple and call it
> an array” type.) Either “joined” uses a different no-copy technique or it’s
> lying about saving on storage (and the lack of scoped-storage Sequences
> means no one has called them on it yet).
>

I don’t see any contradiction here. A tuple is a value type; it has no
concept of copy-on-write because it’s copy-on-read. So JoinedSequence will
store a copy of the tuple instead of a buffer reference
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Search for Swift packages on GitHub

[Taylor Swift via swift-users]

I’m pretty sure any serious package author will have Travis or some other
CI set up for their library. Checking for a CI service is a good way to
filter out low-quality repos that are little more than just code dumps. The
swift version can be detemined by reading the Package.swift file. Most
packages also have shields in their readme.md’s, so it might be worth
checking for common shields like `platform`.

On Wed, Aug 9, 2017 at 4:33 AM, Kilian Koeltzsch  wrote:

> You're absolutely right about the additional information. Unfortunately
> some of these (does it support my platform, what versions of Swift it
> builds on) are hard to tell without actually building the package several
> times with differing hardware/toolchains. Others (does it depend on
> Foundation, how well it's documented) would at least require analyzing the
> complete source, which still isn't quite feasible without a dedicated
> service elsewhere having already completed that work.
> For authors that have integrations set up with services that help with
> test coverage, documentation etc. it might be possible to just hook into
> those, but unfortunately the count of these isn't close to anything that
> would make this worth it. At least as far as I know.
>
> The list of dependencies listed in a packages' manifest however can easily
> be pulled into this, in fact I already have that queued up. It's definitely
> nothing major but easily included.
>
> Thanks for the list of suggestions though! They're much appreciated :)
>
> Cheers,
> Kilian
>
> > On 9. Aug 2017, at 03:08, Taylor Swift  wrote:
> >
> > I really like this idea, however what I really want to know about a
> package usually includes: does it support my platform, does it depend on
> Foundation, what other modules it depends on, what versions of Swift it
> builds on (including nightly builds), and how well its documented. I don’t
> know how this can be done by simply querying github’s API though, it’s
> bound to require at least some involvement on the part of the package
> author.
> >
> > On Tue, Aug 8, 2017 at 7:13 PM, Kilian Koeltzsch via swift-users <
> swift-users@swift.org> wrote:
> > Hi all,
> >
> > I was missing a small tool somewhat akin to npm (specifically npm's
> search and install functionality) for the swift ecosystem so I spent some
> time writing something to fill that gap. I'd really love some feedback on
> the idea and usability :)
> >
> > The basic idea is that it's hard to find suitable packages when writing
> a swift library or executable. There is no single centralized listing of
> all packages (packagecatalog.com and swiftmodules.com can only have *so*
> current data), so this tool queries GitHub's API directly for repos written
> in Swift that include a file named Package.swift. It offers ways to search
> for packages, display more info about them and add them to your package
> manifest.
> >
> > You can find the project here: https://github.com/kiliankoe/apodidae
> >
> > It conveniently installs as `swift-catalog` so that you can run it like
> a subcommand of swift itself as `swift catalog`. The basic interaction is
> also shown in the README in more detail.
> >
> > There's still quite a few rough edges and the code definitely needs some
> cleanup, it's more of a test than something that should be depended on at
> this point I guess :P
> >
> > Cheers,
> > Kilian
> >
> >
> > ___
> > 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] [swift-evolution] How does "Sequence.joined" work?

[Taylor Swift via swift-users]

On Wed, Aug 9, 2017 at 1:50 AM, Rob Mayoff  wrote:

> On Tue, Aug 8, 2017 at 11:51 PM, Taylor Swift via swift-users <
> swift-users@swift.org> wrote:
>
>>
>>
>> On Wed, Aug 9, 2017 at 12:29 AM, Félix Cloutier via swift-evolution <
>> swift-evolut...@swift.org> wrote:
>>
>>> Yes, exactly. An Array is a struct wrapper for a reference type
>>> representing storage. Mutating functions first check if they own the only
>>> reference to the storage using isKnownUniquelyReferenced
>>> <https://developer.apple.com/documentation/swift/2429905-isknownuniquelyreferenced>.
>>> If not, they make a fresh copy before applying the mutating operation.
>>>
>>> There's no difference for `let` arrays. Access control is enforced at
>>> compile-time through Array's design: the compiler will prevent you from
>>> calling `mutating` functions on `let` structs, and Array is careful to not
>>> expose functionality that could modify its storage outside of `mutating`
>>> functions.
>>>
>>> There is no secret. Anyone could implement the same thing only using
>>> publicly available and documented compiler features. In fact, it's been
>>> done already for some very powerful collections
>>> <https://github.com/lorentey/BTree>.
>>>
>>
>> This isn’t entirely true. That BTree module readme seems to contain a lot
>> of unsubstantiated hyperbole. It’s possible to implement a classic
>> red-black tree in Swift that performs better than a sorted Array, down
>> to about *n* = 1,500 items, not *n* = *100,000* items as it claims.
>> (Actually, heap allocators these days are good enough that performance is
>> on par with Array all the way down to *n* = 1.) Red-Black trees are slow
>> when *distributed* as packages because of the crossmodule optimization
>> boundary. (This also means the BTree module is much slower than Array
>> for most reasonable *n*.) It’s possible to write modules using compiler
>> attributes that mitigate this slowdown (reclaiming over 50% of lost
>> performance) but it’s hacky and forces you to design your libraries like
>> the standard library (meaning: ugly underscored properties everywhere and
>> everything is public). And these features aren’t “publicly available” or
>> documented at all.
>>
>
> This seems harsh. I didn't notice Félix making any claims about BTree's
> performance. The necessary API for implementing COW is indisputably public
> and documented:
>
> https://developer.apple.com/documentation/swift/2429905-
> isknownuniquelyreferenced
>
>
I really didn’t mean it to be harsh (sorry if it sounded that way 🙁), it’s
just that people tend to be overly optimistic about the performance that
can be achieved with custom Collection packages. It’s true that you can
imitate the *functionality* of stdlib Collection types with public and
documented Swift features, but such custom Collections (when distributed as
packages) are almost never effective at improving an application’s
performance due to the huge constant factor of cross module calls, unless
the library author was willing to make use of undocumented compiler
features.
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] [swift-evolution] How does "Sequence.joined" work?

[Taylor Swift via swift-users]

On Wed, Aug 9, 2017 at 12:29 AM, Félix Cloutier via swift-evolution <
swift-evolut...@swift.org> wrote:

> Yes, exactly. An Array is a struct wrapper for a reference type
> representing storage. Mutating functions first check if they own the only
> reference to the storage using isKnownUniquelyReferenced
> .
> If not, they make a fresh copy before applying the mutating operation.
>
> There's no difference for `let` arrays. Access control is enforced at
> compile-time through Array's design: the compiler will prevent you from
> calling `mutating` functions on `let` structs, and Array is careful to not
> expose functionality that could modify its storage outside of `mutating`
> functions.
>
> There is no secret. Anyone could implement the same thing only using
> publicly available and documented compiler features. In fact, it's been
> done already for some very powerful collections
> .
>

This isn’t entirely true. That BTree module readme seems to contain a lot
of unsubstantiated hyperbole. It’s possible to implement a classic
red-black tree in Swift that performs better than a sorted Array, down to
about *n* = 1,500 items, not *n* = *100,000* items as it claims. (Actually,
heap allocators these days are good enough that performance is on par with
Array all the way down to *n* = 1.) Red-Black trees are slow when
*distributed* as packages because of the crossmodule optimization boundary.
(This also means the BTree module is much slower than Array for most
reasonable *n*.) It’s possible to write modules using compiler attributes
that mitigate this slowdown (reclaiming over 50% of lost performance) but
it’s hacky and forces you to design your libraries like the standard
library (meaning: ugly underscored properties everywhere and everything is
public). And these features aren’t “publicly available” or documented at
all.
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Search for Swift packages on GitHub

[Taylor Swift via swift-users]

I really like this idea, however what I really want to know about a package
usually includes: does it support my platform, does it depend on
Foundation, what other modules it depends on, what versions of Swift it
builds on (including nightly builds), and how well its documented. I don’t
know how this can be done by simply querying github’s API though, it’s
bound to require at least some involvement on the part of the package
author.

On Tue, Aug 8, 2017 at 7:13 PM, Kilian Koeltzsch via swift-users <
swift-users@swift.org> wrote:

> Hi all,
>
> I was missing a small tool somewhat akin to npm (specifically npm's search
> and install functionality) for the swift ecosystem so I spent some time
> writing something to fill that gap. I'd really love some feedback on the
> idea and usability :)
>
> The basic idea is that it's hard to find suitable packages when writing a
> swift library or executable. There is no single centralized listing of all
> packages (packagecatalog.com and swiftmodules.com can only have *so*
> current data), so this tool queries GitHub's API directly for repos written
> in Swift that include a file named Package.swift. It offers ways to search
> for packages, display more info about them and add them to your package
> manifest.
>
> You can find the project here: https://github.com/kiliankoe/apodidae
>
> It conveniently installs as `swift-catalog` so that you can run it like a
> subcommand of swift itself as `swift catalog`. The basic interaction is
> also shown in the README in more detail.
>
> There's still quite a few rough edges and the code definitely needs some
> cleanup, it's more of a test than something that should be depended on at
> this point I guess :P
>
> Cheers,
> Kilian
>
>
> ___
> 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] Package Manager test target name conflict

[Taylor Swift via swift-users]

Many libraries I maintain contain a testTarget called "Tests", but whenever
an external package depends on two or more library packages, the "Tests"
targets conflict with one another, even though the testTargets are never
actually depended on. How do I get the SPM to ignore them?
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] SwiftPM manual dependency management

[Taylor Swift via swift-users]

I just want to add that I have been immensely frustrated and inconvenienced
by the lack of this, what I believe is, basic and essential feature in the
SwiftPM.

On Fri, Jul 21, 2017 at 9:32 AM, Ankit Aggarwal via swift-users <
swift-users@swift.org> wrote:

> I’m just surprised the idea of a "local dependency" is not seen as a first
> class citizen in SwiftPM, still trying to understand the logic behind that.
> Maybe you can give me an idea of the reasoning behind this?
>
>
> I understand your usecase will benefit a lot from the local dependency
> feature. We did consider adding this feature, I think the main concern was
> package authors ending up publishing package which only works for them
> incase they forget updating their manifest before a release. Also, note
> that SwiftPM is still under heavy development and we can definitely
> re-consider adding this!
>
> Also, I think this is a good usecase of a multipackage repository feature.
> We don't have that yet but you can read some of the discussion here
> 
> .
>
> PS: We also have a slack channel if you want to hang out -
> https://lists.swift.org/pipermail/swift-build-dev/
> Week-of-Mon-20160530/000497.html
>
> ___
> 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 I use a tuple to force a certain memory layout?

[Taylor Swift via swift-users]

Okay, apparently layout is only guaranteed if the reference is to the tuple
itself, not a member of the tuple. Don’t know if this is a bug or intended
behavior. The above code works when written as

var buffers:(VBO:GL.UInt, EBO:GL.UInt) = (0, 0)
withUnsafeMutablePointer(to: &buffers)
{
$0.withMemoryRebound(to: UInt32.self, capacity: 2)
{
glGenBuffers(n: 2, buffers: $0)
}
}



On Thu, Jul 20, 2017 at 3:01 PM, Taylor Swift via swift-users <
swift-users@swift.org> wrote:

> This does not seem to be the case…
>
> var buffers:(VBO:GL.UInt, EBO:GL.UInt) = (0, 0)
> glGenBuffers(n: 2, buffers: &buffers.VBO)
> print(buffers)
> // > (VBO: 4, EBO: 0)
>
> var buffers:(VBO:GL.UInt, EBO:GL.UInt) = (0, 0)
> glGenBuffers(n: 1, buffers: &buffers.VBO)
> glGenBuffers(n: 1, buffers: &buffers.EBO)
> print(buffers)
> // > (VBO: 4, EBO: 5)
>
> On Thu, Jul 20, 2017 at 1:18 PM, Johannes Weiß 
> wrote:
>
>> Hi,
>>
>> > On 20 Jul 2017, at 5:41 pm, Taylor Swift  wrote:
>> >
>> > Does addressof count as legally observing it?
>> >
>> > var buffers:(GL.UInt, GL.UInt) = (0, 0)
>> > glGenBuffers(n: 2, buffers: &buffers.0)
>> >
>> > Also, I assume Swift performs a swizzle if the tuple is defined in a
>> separate module from where the pointer to it is constructed?
>>
>> yes, that's legal assuming the called function doesn't store the pointer
>> and read/write it later.
>>
>>
>> >
>> > On Thu, Jul 20, 2017 at 4:59 AM, Johannes Weiß 
>> wrote:
>> > When you can (legally) observe it, tuples in Swift have guaranteed
>> standard C-style layout.
>> >
>> > John McCall confirms this here: https://lists.swift.org/piperm
>> ail/swift-dev/Week-of-Mon-20170424/004481.html
>> >
>> > > On 20 Jul 2017, at 4:33 am, Taylor Swift via swift-users <
>> swift-users@swift.org> wrote:
>> > >
>> > > Many APIs like OpenGL take arrays where the atomic unit is multiple
>> elements long. For example, a buffer of coordinates laid out like
>> > >
>> > > :[Float] = [ x1, y1, z1, x2, y2, z2, ... , xn, yn, zn ]
>> > >
>> > > I want to be able to define in Swift (i.e., without creating and
>> importing a Objective C module) a struct that preserves the layout, so that
>> I can do withMemoryRebound(to:capacity:_) or something similar and treat
>> the buffer as
>> > >
>> > > struct Point
>> > > {
>> > > let x:Float,
>> > > y:Float,
>> > > z:Float
>> > > }
>> > >
>> > > :[Point] = [ point1, point2, ... , pointn ]
>> > >
>> > > The memory layout of the struct isn’t guaranteed, but will the layout
>> be guaranteed to be in declaration order if I use a tuple inside the struct
>> instead?
>> > >
>> > > struct Point
>> > > {
>> > > let _point:(x:Float, y:Float, z:Float)
>> > >
>> > > var x:Float
>> > > {
>> > > return self._point.x
>> > > }
>> > >
>> > > var y:Float
>> > > {
>> > > return self._point.y
>> > > }
>> > >
>> > > var z:Float
>> > > {
>> > > return self._point.z
>> > > }
>> > > }
>> > >
>> > > This is an ugly workaround, but I can’t really think of any
>> alternatives that don’t involve “import something from Objective C”. I am
>> aware that the implementation of structs currently lays them out in
>> declaration order, but I’m looking for something that’s actually defined in
>> the language.
>> > >
>> > >
>> > > ___
>> > > 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] Can I use a tuple to force a certain memory layout?

[Taylor Swift via swift-users]

This does not seem to be the case…

var buffers:(VBO:GL.UInt, EBO:GL.UInt) = (0, 0)
glGenBuffers(n: 2, buffers: &buffers.VBO)
print(buffers)
// > (VBO: 4, EBO: 0)

var buffers:(VBO:GL.UInt, EBO:GL.UInt) = (0, 0)
glGenBuffers(n: 1, buffers: &buffers.VBO)
glGenBuffers(n: 1, buffers: &buffers.EBO)
print(buffers)
// > (VBO: 4, EBO: 5)

On Thu, Jul 20, 2017 at 1:18 PM, Johannes Weiß 
wrote:

> Hi,
>
> > On 20 Jul 2017, at 5:41 pm, Taylor Swift  wrote:
> >
> > Does addressof count as legally observing it?
> >
> > var buffers:(GL.UInt, GL.UInt) = (0, 0)
> > glGenBuffers(n: 2, buffers: &buffers.0)
> >
> > Also, I assume Swift performs a swizzle if the tuple is defined in a
> separate module from where the pointer to it is constructed?
>
> yes, that's legal assuming the called function doesn't store the pointer
> and read/write it later.
>
>
> >
> > On Thu, Jul 20, 2017 at 4:59 AM, Johannes Weiß 
> wrote:
> > When you can (legally) observe it, tuples in Swift have guaranteed
> standard C-style layout.
> >
> > John McCall confirms this here: https://lists.swift.org/
> pipermail/swift-dev/Week-of-Mon-20170424/004481.html
> >
> > > On 20 Jul 2017, at 4:33 am, Taylor Swift via swift-users <
> swift-users@swift.org> wrote:
> > >
> > > Many APIs like OpenGL take arrays where the atomic unit is multiple
> elements long. For example, a buffer of coordinates laid out like
> > >
> > > :[Float] = [ x1, y1, z1, x2, y2, z2, ... , xn, yn, zn ]
> > >
> > > I want to be able to define in Swift (i.e., without creating and
> importing a Objective C module) a struct that preserves the layout, so that
> I can do withMemoryRebound(to:capacity:_) or something similar and treat
> the buffer as
> > >
> > > struct Point
> > > {
> > > let x:Float,
> > > y:Float,
> > > z:Float
> > > }
> > >
> > > :[Point] = [ point1, point2, ... , pointn ]
> > >
> > > The memory layout of the struct isn’t guaranteed, but will the layout
> be guaranteed to be in declaration order if I use a tuple inside the struct
> instead?
> > >
> > > struct Point
> > > {
> > > let _point:(x:Float, y:Float, z:Float)
> > >
> > > var x:Float
> > > {
> > > return self._point.x
> > > }
> > >
> > > var y:Float
> > > {
> > > return self._point.y
> > > }
> > >
> > > var z:Float
> > > {
> > > return self._point.z
> > > }
> > > }
> > >
> > > This is an ugly workaround, but I can’t really think of any
> alternatives that don’t involve “import something from Objective C”. I am
> aware that the implementation of structs currently lays them out in
> declaration order, but I’m looking for something that’s actually defined in
> the language.
> > >
> > >
> > > ___
> > > 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 I use a tuple to force a certain memory layout?

[Taylor Swift via swift-users]

Does addressof count as legally observing it?

var buffers:(GL.UInt, GL.UInt) = (0, 0)
glGenBuffers(n: 2, buffers: &buffers.0)

Also, I assume Swift performs a swizzle if the tuple is defined in a
separate module from where the pointer to it is constructed?

On Thu, Jul 20, 2017 at 4:59 AM, Johannes Weiß 
wrote:

> When you can (legally) observe it, tuples in Swift have guaranteed
> standard C-style layout.
>
> John McCall confirms this here: https://lists.swift.org/
> pipermail/swift-dev/Week-of-Mon-20170424/004481.html
>
> > On 20 Jul 2017, at 4:33 am, Taylor Swift via swift-users <
> swift-users@swift.org> wrote:
> >
> > Many APIs like OpenGL take arrays where the atomic unit is multiple
> elements long. For example, a buffer of coordinates laid out like
> >
> > :[Float] = [ x1, y1, z1, x2, y2, z2, ... , xn, yn, zn ]
> >
> > I want to be able to define in Swift (i.e., without creating and
> importing a Objective C module) a struct that preserves the layout, so that
> I can do withMemoryRebound(to:capacity:_) or something similar and treat
> the buffer as
> >
> > struct Point
> > {
> > let x:Float,
> > y:Float,
> > z:Float
> > }
> >
> > :[Point] = [ point1, point2, ... , pointn ]
> >
> > The memory layout of the struct isn’t guaranteed, but will the layout be
> guaranteed to be in declaration order if I use a tuple inside the struct
> instead?
> >
> > struct Point
> > {
> > let _point:(x:Float, y:Float, z:Float)
> >
> > var x:Float
> > {
> > return self._point.x
> > }
> >
> > var y:Float
> > {
> > return self._point.y
> > }
> >
> > var z:Float
> > {
> > return self._point.z
> > }
> > }
> >
> > This is an ugly workaround, but I can’t really think of any alternatives
> that don’t involve “import something from Objective C”. I am aware that the
> implementation of structs currently lays them out in declaration order, but
> I’m looking for something that’s actually defined in the language.
> >
> >
> > ___
> > 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] Can I use a tuple to force a certain memory layout?

[Taylor Swift via swift-users]

Many APIs like OpenGL take arrays where the atomic unit is multiple
elements long. For example, a buffer of coordinates laid out like

:[Float] = [ x1, y1, z1, x2, y2, z2, ... , xn, yn, zn ]

I want to be able to define *in Swift* (i.e., without creating and
importing a Objective C module) a struct that preserves the layout, so that
I can do withMemoryRebound(to:capacity:_) or something similar and treat
the buffer as

struct Point
{
let x:Float,
y:Float,
z:Float
}

:[Point] = [ point1, point2, ... , pointn ]

The memory layout of the struct isn’t guaranteed, but will the layout be
guaranteed to be in declaration order if I use a tuple inside the struct
instead?

struct Point
{
let _point:(x:Float, y:Float, z:Float)

var x:Float
{
return self._point.x
}

var y:Float
{
return self._point.y
}

var z:Float
{
return self._point.z
}
}

This is an ugly workaround, but I can’t really think of any alternatives
that don’t involve “import something from Objective C”. I am aware that the
implementation of structs currently lays them out in declaration order, but
I’m looking for something that’s actually defined in the language.
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] Public extension method in extension with internal requirements

[Taylor Swift via swift-users]

I have several public structs that conform to this internal protocol. The
protocol has an associated type IntV so that it can service 2, 3, or 4
dimensional noise.

protocol HashedTilingNoise
{
associatedtype IntV

var amplitude:Double { get }
var frequency:Double { get }
var wavelengths:IntV { get }

init(amplitude:Double, frequency:Double, wavelengths:IntV)
}

I extend it to provide common functionality for all the conforming structs.

extension HashedTilingNoise
{
public
func amplitude_scaled(by factor:Double) -> Self
{
return Self(amplitude: self.amplitude * factor, frequency:
self.frequency,
wavelengths: self.wavelengths)
}

public
func frequency_scaled(by factor:Double) -> Self
{
return Self(amplitude: self.amplitude, frequency: self.frequency *
factor, wavelengths: self.wavelengths)
}

...
}

But now I want to provide common functionality just for structs with a
certain dimension. For example, I want to provide a transpose(octaves:)
function for the structs that have 3 dimensional wavelengths.

extension HashedTilingNoise where IntV == Math.IntV3
{
public
func transposed(octaves:Int) -> Self
{
return Self(amplitude: self.amplitude, frequency: self.frequency,
wavelengths: (self.wavelengths.a << octaves,
self.wavelengths.b
<< octaves, self.wavelengths.c << octaves))
}
}

But this gives the compiler error

/home/taylorswift/noise/sources/noise/hash.swift:67:5: error: cannot
declare a public instance method in an extension with internal requirements
public
^~
internal

Because the Math.IntV3 type and the HashedTilingNoise protocol are
internal. I don’t want to expose these as part of the API as they are just
containers for shared functionality.

How do I fix this?
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] Filling two type parameters with the same type

[Taylor Swift via swift-users]

I have a type like

struct DistortedNoise where Source:Noise,
Displacement:Noise
{
let source:Source,
displacement:Displacement

init(source:Source, displacement:Displacement)
{
self.source   = source
self.displacement = displacement
}

init(source:Source)
{
self.source   = source
self.displacement = source
}
}

and I get the error

Compile Swift Module 'Noise' (5 sources)
/home/taylor/noise/sources/noise/noise.swift:576:29: error: 'Source' is not
convertible to 'Displacement'
self.displacement = source
^~

How do I tell Swift that I want the same type fulfilling both Source and
Displacement?
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] the pain of strings

[Taylor Swift via swift-users]

I agree, and the new format of the swift 4 API docs are much harder to find
things in than the swift 3 ones. Perusing all the types and free functions
in alphabetical order is so much easier than trying to guess what “topic”
something is sorted under.

On Sat, Jul 1, 2017 at 12:54 AM, David Baraff  wrote:

>
> On Jun 30, 2017, at 9:48 PM, Taylor Swift via swift-users <
> swift-users@swift.org> wrote:
>
>
> Swift's strings were very deliberately designed this way. It's tougher to
>> get off the ground, sure, but it's better in the long run.
>>
>>
> It probably is, but the correct idiom is not very well known, and sadly
> most tutorials and unofficial guides are still teaching dumb ways of
> subscripting into strings (or worse, falling back into NSString methods
> without mentioning so) so the end result is people writing less performant
> code rather than more performant code.
>
>
> An efficient solution doesn’t help if even experienced programmers can’t
> easily arrive at it.  (I’m highly experienced, but I’ll admit I only put in
> about 5 minutes before I posted that.  on the other hand, it shouldn’t take
> 5 minutes to figure out something that simple with strings.  still, maybe i
> would have done the simple “suffix()” thing had i been looking at the
> actual swift 4 api’s, but i only had swift 3 api’s in front of me.)
>
> ___
> 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] Class vs Structures

[Taylor Swift via swift-users]

An addendum: if something represents a specific “thing” that can’t be
duplicated without consequence, often that means it should be stored in one
specific place in your code, not made into a class.

On Fri, Jun 30, 2017 at 10:10 PM, Brent Royal-Gordon via swift-users <
swift-users@swift.org> wrote:

> On Jun 29, 2017, at 10:40 AM, Vitor Navarro via swift-users <
> swift-users@swift.org> wrote:
>
> Do you guys have any guideline regarding usage here?
>
>
> Here's my suggestion: Use a class when the object represents a specific
> *thing* that can't be duplicated without consequence; use a struct (or
> enum) when the instance represents some abstract data with no concrete
> existence. Some examples using framework types:
>
> * A piece of text is just some data; duplicating it doesn't do anything
> except maybe use more memory. So `String` should be a struct.
>
> * A label is a particular thing that exists at a particular place on
> screen; if you duplicated it, you'd end up with two labels on the screen,
> or with an off-screen copy of a label that wouldn't have any effect when
> you mutated it. So `UILabel` should be a class.
>
> * A URL is just some data; if you construct two URLs with the same
> contents, they are completely interchangeable. So `URL` should be a struct.
>
> * A connection to a web server to retrieve the contents of a URL is a
> particular thing; if you duplicated it, you would either establish another
> connection, or the two instances would interfere with each other (e.g.
> canceling one would cancel the other). So `URLSessionTask` and
> `NSURLConnection` are classes.
>
> Sometimes the same problem, approached in slightly different ways, would
> allow you to use either one. For instance, a database record is a
> particular *thing* and should probably be a class, but copy the values of
> the fields (perhaps omitting the ID) out of it and suddenly you have a
> plausible struct. As a *general* rule, it's usually better to use structs
> where possible because it's easier to reason about their behavior—mutations
> in one function don't suddenly pop up in a totally unrelated function—but
> sometimes a particular type works very easily as a class and very awkwardly
> as a struct. Ultimately, it's a judgement call.
>
> The other point I will make is this: "Protocol-oriented programming" is
> new and exciting and often very useful, but it's a tool, not a religion. If
> subclassing works well for your use case, then subclass away.
>
> --
> Brent Royal-Gordon
> Architechies
>
>
> ___
> 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] the pain of strings

[Taylor Swift via swift-users]

> Swift's strings were very deliberately designed this way. It's tougher to
> get off the ground, sure, but it's better in the long run.
>
>
It probably is, but the correct idiom is not very well known, and sadly
most tutorials and unofficial guides are still teaching dumb ways of
subscripting into strings (or worse, falling back into NSString methods
without mentioning so) so the end result is people writing less performant
code rather than more performant code.
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Is '_ = x' guaranteed to hold a reference to x?

[Taylor Swift via swift-users]

You should probably use `withExtendedLifetime(_:_:)
`
for this.

On Fri, Jun 30, 2017 at 2:54 PM, Charles Srstka via swift-users <
swift-users@swift.org> wrote:

> > On Jun 30, 2017, at 1:47 PM, Mike Ferenduros via swift-users <
> swift-users@swift.org> wrote:
> >
> > I'm doing a RAII sort of thing with an object, and would like to keep it
> alive until an completion-block is called (asynchronously).
> >
> > Is it sufficient to say '_ = x' in the completion-block to keep a live
> reference to the object?
> >
> > I was told that the optimiser is free to discard this line, and thus the
> object could be freed prematurely depending on how the code is compiled. If
> so, is there an idiomatic way to do this? Or should I just avoid RAII in
> Swift?
>
> Nope. In fact, if you try this, you’ll find that it dies immediately after
> the initializer returns:
>
> class C {
> deinit { print("Deinit!") }
> }
>
> do {
> print("Creating")
> _ = C()
> print("Created")
> }
> print("Left the block”)
>
> - - - - -
>
> Creating
> Deinit!
> Created
> Left the block
>
> Charles
> ___
> 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] Passing Data to a f(void *) function

[Taylor Swift via swift-users]

I believe UnsafeRawPointer is a subtype of any UnsafePointer type, so
UnsafePointer’s are always implicitly convertible to UnsafeRawPointers.
So even the following compiles:


import Foundation

func f(_ a:UnsafeRawPointer)
{

}

let data = Data(bytes: [1, 2, 3, 4])
data.withUnsafeBytes{ (ptr:UnsafePointer>) in f(ptr) }

So annotate ptr with its actual type, and it should just work.

On Fri, Jun 30, 2017 at 10:57 AM, Daniel Dunbar via swift-users <
swift-users@swift.org> wrote:

>
> > On Jun 30, 2017, at 7:40 AM, Martin R via swift-users <
> swift-users@swift.org> wrote:
> >
> > I have a C function
> >
> >void myfunc(const void *ptr);
> >
> > which is imported to Swift as
> >
> >func myfunc(_ ptr: UnsafeRawPointer!)
> >
> > This compiles and runs without problems:
> >
> >let data = Data(bytes: [1, 2, 3, 4])
> >data.withUnsafeBytes { (ptr) in myfunc(ptr) } // (A)
> >
> > and the type of `ptr` is inferred as `UnsafePointer`. But adding
> an explicit type
> > annotation produces a compiler warning:
>
> How do you know the inferred type is `UnsafePointer`? I think it is
> more likely it is `UnsafePointer`, and the following compiles:
> ```
> let data = Data(bytes: [1, 2, 3, 4])
> data.withUnsafeBytes { (ptr: UnsafePointer) in
> myfunc(ptr)
> }
> ```
>
>  - Daniel
>
> >
> >data.withUnsafeBytes { (ptr: UnsafePointer) in myfunc(ptr) } //
> (B)
> >// warning: UnsafePointer has been replaced by UnsafeRawPointer
> >
> > which is understandable in the view of "SE-0107 UnsafeRawPointer API".
> >
> > The "Fix-it" replaces `UnsafePointer` by `UnsafeRawPointer`, and
> that does not
> > compile anymore:
> >
> >data.withUnsafeBytes { (ptr: UnsafeRawPointer) in myfunc(ptr) } // (C)
> >// error: cannot convert value of type 'Void' to closure result type
> '_'
> >
> > because there is no `withUnsafeBytes()` method taking a
> `(UnsafeRawPointer)->ResultType`
> > closure.
> >
> >
> > My questions are:
> >
> > 1. Why are (A) and (B) treated differently?
> >
> > 2. Is (A) "legal", or should one use some non-void pointer
> >
> >data.withUnsafeBytes { (ptr: UnsafePointer) in myfunc(ptr) } //
> (D)
> >
> >   (which feels wrong to me because it is converted back to a void
> pointer when
> >   calling the function).
> >
> > 3. Or should there be a `withUnsafeRawPointer()` method which makes (C)
> compile as
> >
> >  data.withUnsafeRawBytes { (ptr: UnsafeRawPointer) in myfunc(ptr) }
> >
> >   This would also allow to access the data at byte offsets more easily,
> e.g.
> >
> >   data.withUnsafeRawBytes { ptr in
> >   let u16 = ptr.load(fromByteOffset: 4, as: UInt16.self)
> >   }
> >
> >   Does that makes sense?
> >
> > Regards, Martin
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ___
> > 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] Class vs Structures

[Taylor Swift via swift-users]

The Ray Wenderlich style guide contains *some* useful insights, but you
should not take it as a “swift best practices” guide, or even a good code
style guide for your own projects. At the risk of sounding blunt, the RW
style guide is optimized for blog posts and cheap tutorials, not a cohesive
Swift code base you have to maintain over time. In addition that website is
heavily iOS-developer oriented, and the iOS platform forces you to interact
with a lot of Objective C frameworks which are more reference-oriented than
native Swift code should be.

Enum scoping is when you want to group free floating functions into a
common namespace to avoid polluting the global scope. For example one of
the libraries I maintain has a collection of internal math functions which
are handy to have around.

enum Math
{
typealias IntV2= (a:Int, b:Int)
typealias IntV3= (a:Int, b:Int, c:Int)
typealias DoubleV2 = (x:Double, y:Double)
typealias DoubleV3 = (x:Double, y:Double, z:Double)

@inline(__always)
private static
func fraction(_ x:Double) -> (Int, Double)
{
let integer:Int = x > 0 ? Int(x) : Int(x) - 1
return (integer, x - Double(integer))
}

@inline(__always)
static
func fraction(_ v:DoubleV2) -> (IntV2, DoubleV2)
{
let (i1, f1):(Int, Double) = Math.fraction(v.0),
(i2, f2):(Int, Double) = Math.fraction(v.1)
return ((i1, i2), (f1, f2))
}

@inline(__always)
static
func fraction(_ v:DoubleV3) -> (IntV3, DoubleV3)
{
let (i1, f1):(Int, Double) = Math.fraction(v.0),
(i2, f2):(Int, Double) = Math.fraction(v.1),
(i3, f3):(Int, Double) = Math.fraction(v.2)
return ((i1, i2, i3), (f1, f2, f3))
}

@inline(__always)
static
func add(_ v1:IntV2, _ v2:IntV2) -> IntV2
{
return (v1.a + v2.a, v1.b + v2.b)
}

...
}

Some, but not all projects will end up with a `Constants`, enum to store
global constants too. Beyond that, you shouldn’t be Enum scoping a lot, it
usually isn’t hard to find a real type where some method or constant
belongs. That being said, you can find a few examples of this pattern in
the Swift standard library: `Unicode`, `CommandLine` and `MemoryLayout`
come to mind.

On Fri, Jun 30, 2017 at 12:12 AM, Vitor Navarro via swift-users <
swift-users@swift.org> wrote:

> Hi Alex,
>
> Thank you for the reply, actually Taylor gave me a great answer which
> solved my question, that was "struct or classes and when should we apply
> each".
>
> Regarding the reference I found this https://github.com/
> raywenderlich/swift-style-guide#code-organization which doesn't follow
> exactly the structs most of the times approach or the protocol driven
> development (WWDC)
>
> Again thanks.
>
> 2017-06-29 14:21 GMT-04:00 Alex Blewitt :
>
>> On 29 Jun 2017, at 18:16, Vitor Navarro via swift-users <
>> swift-users@swift.org> wrote:
>>
>> Hi,
>>
>> I know this question is probably done a thousand times, but I wanted to
>> hear from Swift dev community.
>>
>>
>> What is the question?
>>
>> I think both of them have right places for usage depending on the
>> occasion but documentation, WWDC and the internet give opposite answers
>> regarding this.
>>
>>
>> Do you have references that you can share?
>>
>> Do you guys have any guideline regarding usage here?
>>
>>
>> The Swift Programming Language  sums up the similarities and differences
>> between classes and structures quite well:
>>
>> https://developer.apple.com/library/content/documentation/Sw
>> ift/Conceptual/Swift_Programming_Language/ClassesAndStructures.html
>>
>> Alex
>>
>>
>
> ___
> 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] FloatingPoint equality ..

[Taylor Swift via swift-users]

You can make it even simpler with a range pattern

func almost_equal(_ a:T, _ b:T) -> Bool
{
return b.nextDown ... b.nextUp ~= a
}

On Thu, Jun 29, 2017 at 3:05 PM, Stephen Canon via swift-users <
swift-users@swift.org> wrote:

> I should also point out:
>
> (a) your code can be somewhat simpler in Swift. I would probably write
> something along the lines of:
>
> func almostEqual(_ a: T, _ b: T) -> Bool {
> return a >= b.nextDown && a <= b.nextUp
> }
>
> (b) one ULP is almost never a tolerance you want to use. It’s much too
> small for almost all computations, and too large for most of the remaining
> ones.
>
> – Steve
>
> ___
> 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] Class vs Structures

[Taylor Swift via swift-users]

When in doubt, go with a struct. Probably nineteen types out of twenty I
write are structs. Swift really is optimized with the assumption that
you’re working with structs, that’s why almost everything in the standard
library is a value type. Structs always pack contiguously into arrays,
while arrays of classes can get bridged to a non-contiguous NSArray. Code
that uses classes tends to be hard to read since `let` and `var` cease to
convey useful information about mutability. Classes also open up cans of
worms with strong and weak ownership cycles and all that crap which is
almost completely avoidable if you know how to use value types well.

The only reason to use a class is if you really, really need reference
semantics — i.e., the instance does not have a clearly defined owner, and
you want any changes to the instance to be reflected in all of its owners.
This is rare though, and more often than not this is a code smell that
something is wrong with the larger design. Another case is when the
instance manages some kind of external resource, like a memory buffer, and
you have no other way of untangling the resource management from the life
cycle of the instance. This is why Swift array buffers are classes (though
the Array type itself is a struct which contains the buffer class).

Another case where a class *might* be appropriate is when your type
contains many many stored properties, that pushing and popping them off the
call stack by value would be slower than pushing a reference. That’s
usually a sign that you’re not making enough use of static or computed
properties though. The pass by value cost is also not as important as you
might think — small functions will get inlined by the compiler, while large
functions don’t care since the function call cost will be dwarfed by the
cost of executing the actual function body.

Inheritance and polymorphism are *not* a good enough reason to use classes;
that’s what extensions and protocols are for.

Don’t use a struct as a scoping container; use an enum for that. Some
people scope things to structs because they don’t remember that enums can
be used as a namespace, but the swift idiom is to use an enum for this, not
a struct.

tldr; structs and enums are the preferred native Swift object, classes are
really only there for programmers coming from other languages who are used
to thinking in terms of reference types.

On Thu, Jun 29, 2017 at 1:16 PM, Vitor Navarro via swift-users <
swift-users@swift.org> wrote:

> Hi,
>
> I know this question is probably done a thousand times, but I wanted to
> hear from Swift dev community.
>
> I think both of them have right places for usage depending on the occasion
> but documentation, WWDC and the internet give opposite answers regarding
> this.
>
> Do you guys have any guideline regarding usage here?
>
> Thank you.
>
> Vitor Navarro
>
> ___
> 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] Compilation time problems when building matrices

[Taylor Swift via swift-users]

i have a similar function in my code which uses four intermediates but
compiles in reasonable time

{
// frustum
let f_width:Float  =  self.half_h  * self.twice_size,
f_height:Float =  self.half_k  * self.twice_size,
dx:Float   = -self.shift_x / self.half_h,
dy:Float   = -self.shift_y / self.half_k

let clip_ratio:Float = 1000

self.projection_matrix =
[self.z/f_width , 0  ,
0 , 0,
 0  , self.z/f_height,
0 , 0,
 dx , dy ,(1 + clip_ratio) / (1 -
clip_ratio),-1,
 0  , 0  , self.z*2*clip_ratio / (1 -
clip_ratio), 0]
}

The intermediates are also things you’re going to want to store if anything
for code clarity since the array literal starts looking messy when you
shove long expressions into it. It also cuts down a little on the number of
redundant operations you have to do (from 21 in your example to 16),
especially divisions which you have six of in the original.

On Wed, Jun 28, 2017 at 1:51 PM, Elia Cereda via swift-users <
swift-users@swift.org> wrote:

> Hi,
>
> I currently writing a demo app to teach myself the fundamentals of Metal
> and a big part of that is obviously working with matrices. What I’m seeing
> is that the code build them has some serious compilation time problems.
>
> The worst case is this function, which according
> to -debug-time-function-bodies takes over 9500ms of time to compile.
>
> static func frustum(l: Float, r: Float, t: Float, b: Float, n: Float, f:
> Float) -> float4x4 {
> return float4x4(rows: [
> [ 2 * n / (r - l),   0,  (r + l) / (r - l),
> 0 ],
> [   0, 2 * n / (t - b),  (t + b) / (t - b),
> 0 ],
> [   0,   0, -(f + n) / (f - n), -2 * f
> * n / (f - n) ],
> [   0,   0, -1,
> 1 ],
> ])
> }
>
> I’ve tried making some naive changes to the code and gotten it down to a
> much more reasonable 4ms, but the result is not something I would write if
> given a choice.
>
> static func frustum(l: Float, r: Float, t: Float, b: Float, n: Float, f:
> Float) -> float4x4 {
> let twoN = 2 * n
>
>
> let rPlusL = r + l
> let rMinusL = r - l
>
>
> let tPlusB = t + b
> let tMinusB = t - b
>
>
> let fPlusN = f + n
> let fMinusN = f - n
>
>
> return float4x4(rows: [
> [ twoN / rMinusL,  0,  rPlusL / rMinusL,
> 0 ],
> [  0, twoN / tMinusB,  tPlusB / tMinusB,
> 0 ],
> [  0,  0, -fPlusN / fMinusN, -twoN * f /
> fMinusN ],
> [  0,  0,-1,
> 1 ],
> ])
> }
>
> I’m taking this to swift-users since I’m aware this is a known pain point
> with the compiler. Is this specific instance something that would be worth
> filing a bug for?
>
> Since I do not understand enough of the compiler to understand
> specifically what is causing problems with the first piece of code, I would
> also be extremely grateful if something from the core team (or anyone for
> that matter) could share some wisdom regarding what to do here.
>
> Specifically, is there something that could be done to the first code to
> reduce the amount of overloads that the compiler needs to consider? In my
> naive view of the world, a sum or a multiplication between two Floats can
> only ever produce another Float, is there some way to pass this knowledge
> to the compiler?
>
> Regards,
> Elia Cereda
>
>
> ___
> 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] OpenGL function loader for Swift 4

[Taylor Swift via swift-users]

The Github repo: https://github.com/kelvin13/swift-opengl

On Mon, Jun 26, 2017 at 7:40 PM, Taylor Swift  wrote:

> Hi all, I have released the Swift *OpenGL* library, a package that lets
> you interface with the GPU from Swift code. It’s intended to replace 
> Turnbull’s
> SGL library  which has been
> unmaintained since the days of Swift 2.0. Swift OpenGL is tested on Linux,
> it *should* work on OSX but I haven’t been able to test it on a Mac.
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] OpenGL function loader for Swift 4

[Taylor Swift via swift-users]

Hi all, I have released the Swift *OpenGL* library, a package that lets you
interface with the GPU from Swift code. It’s intended to replace Turnbull’s
SGL library  which has been unmaintained
since the days of Swift 2.0. Swift OpenGL is tested on Linux, it *should*
work on OSX but I haven’t been able to test it on a Mac.
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] [swift-build-dev] Importing C system libraries

[taylor swift via swift-users]

I figured that was the intention, but we can’t be too surprised that everyone 
is maintaining personal modulemap repositories (and polluting search results — 
just try googling for a Swift PNG library!), especially when this central repo 
still doesn’t exist yet.

If Swift ever comes on par with C in terms of being usage and the lingua franca 
of the FOSS world, I can see linux distributions shipping standard modulemaps 
the same way they ship C headers, but you have to admit this is years 
(decades?) away at best.

On the flip side of it, it does wonders in terms of motivating people (me at 
least) to start writing pure Swift replacements for some of these C libraries 
(like libpng)…

> On Mar 29, 2017, at 12:42 AM, Ankit Aggarwal  wrote:
> 
> I think the idea was that there will be one such repository which other 
> packages can use, that too only until the system libraries start shipping 
> their standard modulemap. I thought we had this written down in our 
> documentation somewhere but couldn't find it.
> 
> Maybe Daniel can expand on this.
> 
>> On Wed, Mar 29, 2017 at 10:48 AM, Kelvin Ma via swift-build-dev 
>>  wrote:
>> This worked! Thanks! But why is having empty git repositories strewn about 
>> the “correct” way? System libraries should be imported from within the 
>> project, as they are in C. You have to admit it’s getting quite silly that 
>> Swift devs keep repositories like these on our github accounts. That zlib 
>> repository contains exactly ten lines of code. I used to have 6 or 7 repos 
>> like that one up there before I got rid of them and switched to local repos. 
>> 
>>> On Wed, Mar 29, 2017 at 12:03 AM, Ankit Aggarwal  
>>> wrote:
>>> In this case, these are just umbrella headers. If your modulemap contains 
>>> absolute path to the header, then you don't need the header files, but 
>>> SwiftPM will probably warn about this. Note that this is a "hack" to have 
>>> system packages inside a single repository. The correct way is to have 
>>> system package as a separate published package which you only need to do 
>>> once.
>>> 
 On 29-Mar-2017, at 10:26 AM, Kelvin Ma  wrote:
 
 I will try this, but why are the header files inside the Sources 
 directory? System headers should live in /usr/include…
 
> On Tue, Mar 28, 2017 at 11:48 PM, Ankit Aggarwal 
>  wrote:
> Hi,
> 
> Apologies for not replying to this earlier. 
> 
> You can have multiple targets in a single package. Each target can either 
> be Swift or C-family. The type of target is determined by the sources 
> contained in it (*.c/*.cpp etc means C target, *.swift means Swift 
> target). So if you want to create multiple C targets, this layout should 
> work:
> 
> Package.swift
> Sources/
> Bitmap
> Cubify
> Cairo/anchor.c < This is just an empty file to tell SwiftPM that 
> this is a C target.
> Cairo/include/Cairo.h
> Cairo/include/module.modulemap
> GLFW/anchor.c
> GLFW/include/GLFW.h
> GLFW/include/module.modulemap
> 
> The modulemap is automatically generated, if not provided. This is a 
> package which contains two targets (one C and one Swift): 
> https://github.com/jpsim/Yams
> 
> If you need to pass a bunch of compiler flags, you can use SwiftPM's 
> pkgConfig feature but that will require you to have a separate repository 
> for Cario and GLFW. You can experiment without creating tags using the 
> edit feature.
> 
> PS: You can join SwiftPM slack channel for quicker turn around time: 
> https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160530/000497.html
> 
> Thanks,
> Ankit
> 
> 
>> On Wed, Mar 29, 2017 at 6:06 AM, Michael Ilseman via swift-build-dev 
>>  wrote:
>> This is into uncharted territory for me, but it seems you’re building 
>> with SwiftPM. You’ll probably want to configure extra compiler flags if 
>> that’s possible. You could also bite the bullet and build your C 
>> libraries with SwiftPM as well. Hopefully someone on swift-build-dev can 
>> help you out.
>> 
>> CC-ing Ankit
>> 
>> 
>>> On Mar 28, 2017, at 5:09 PM, Kelvin Ma  
>>> wrote:
>>> 
>>> How do I compile a project with many modules? My tree looks like this:
>>> 
>>> 
>>> ​
>>> 
 On Tue, Mar 28, 2017 at 12:47 PM, Michael Ilseman  
 wrote:
 Sure! In this example, I have built libgit2. I have a directory called 
 Git, and inside that I have the following module map:
 
 module Git [system] {
header "/libgit2/include/git2.h"
export *
 }
 
 When I run, I use:
 
 swift -I  -L  -lgit2 
 foo.swift
 
 inside foo.swift I can:
 
 import Git
 // … use libGit2
 
 
 Re

Re: [swift-users] Importing C system libraries

[taylor swift via swift-users]

see idk how to include the libraries and still make them Importable. And 
dumping the library sources into the project dir would kind of hamper source 
distribution…

> On Mar 28, 2017, at 7:36 PM, Michael Ilseman  wrote:
> 
> This is into uncharted territory for me, but it seems you’re building with 
> SwiftPM. You’ll probably want to configure extra compiler flags if that’s 
> possible. You could also bite the bullet and build your C libraries with 
> SwiftPM as well. Hopefully someone on swift-build-dev can help you out.
> 
> CC-ing Ankit
> 
> 
>> On Mar 28, 2017, at 5:09 PM, Kelvin Ma  wrote:
>> 
>> How do I compile a project with many modules? My tree looks like this:
>> 
>> 
>> ​
>> 
>>> On Tue, Mar 28, 2017 at 12:47 PM, Michael Ilseman  
>>> wrote:
>>> Sure! In this example, I have built libgit2. I have a directory called Git, 
>>> and inside that I have the following module map:
>>> 
>>> module Git [system] {
>>>header "/libgit2/include/git2.h"
>>>export *
>>> }
>>> 
>>> When I run, I use:
>>> 
>>> swift -I  -L  -lgit2 
>>> foo.swift
>>> 
>>> inside foo.swift I can:
>>> 
>>> import Git
>>> // … use libGit2
>>> 
>>> 
>>> Read more about how to write a more appropriate module.map file for your 
>>> purposes at https://clang.llvm.org/docs/Modules.html. For example, you 
>>> might be able to define link flags inside the module.map, use umbrella 
>>> directories, submodules, etc.
>>> 
>>> 
>>> 
 On Mar 28, 2017, at 6:27 AM, Kelvin Ma  wrote:
 
 Can you give an example?
 
> On Mon, Mar 27, 2017 at 3:59 PM, Michael Ilseman  
> wrote:
> Sure. At a low level, you can create a module.map file and use -L/-l 
> flags in your invocation of Swift. If you want to do so at a higher 
> level, then perhaps SwiftPM can. CCing swift-build-dev for the SwiftPM 
> part.
> 
> 
> > On Mar 26, 2017, at 3:20 PM, Kelvin Ma via swift-users 
> >  wrote:
> >
> > Idk if this has been asked before, but is there a way to import C 
> > libraries into a Swift project without creating a local git repo? 
> > Preferably something similar to C where you can just `#include` headers 
> > and then specify the link flags (in Package.swift?)
> >
> > It’s getting very cumbersome to make a bunch of empty git repos just to 
> > use libglfw or libcairo.
> > ___
> > 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