Re: [swift-users] CustomStringConvertible?

2017-09-09 Thread Rien via swift-users
Ah, yes. It is possible to ‘store’ it as a fixed string.
But I would still expect the compiler to treat it as if it were a computed 
property.
Given that this is a protocol and a protocol cannot define stored properties.
(yet anyway)

OTOH, what do I know about compilers… lol!

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - An HTTP(S) web server framework in Swift







> On 08 Sep 2017, at 20:26, Michael Rogers  wrote:
> 
> Thanks for your reply, Rien. I just tried this again, and now it seems that 
> either is acceptable. Seems a little weird, but I guess I’d rather have more 
> flexibility than less.
> 
> protocol Powerable {
> var isOn:Bool { get set } // Must have get and set
> var usesDC:Bool { get } // Must have get, may have set
> func turnOn()
> func turnOff()
> }
> 
> class GPS : Powerable, CustomStringConvertible {
> // Either of these work
> //var description: String {
> //return "I am a GPS"
> //}
> var description:String = "I am a GPS"
> var isOn: Bool = false
> var usesDC: Bool = false
> 
> // does the obvious
> func turnOn(){
> isOn = true
> }
> 
> // does the obvious
> func turnOff() {
> isOn = false
> }
> }
> 
> print(GPS()) // output: I am a GPS (both cases)
> 
> Michael
> 
>> On Sep 8, 2017, at 1:21 PM, Rien  wrote:
>> 
>> It cannot be ‘stored’ I would think.
>> I always compute my implementations.
>> 
>> Regards,
>> Rien
>> 
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Balancingrock
>> Project: http://swiftfire.nl - An HTTP(S) web server framework in Swift
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> On 08 Sep 2017, at 19:47, Michael Rogers via swift-users 
>>>  wrote:
>>> 
>>> Quick question (for my own edification, as well as to demonstrate to my 
>>> students the power of this mail list ), is CustomStringConvertible a 
>>> stored property or a computed property? The docs say the latter, but when 
>>> using Xcode’s fabulous FIX button, it seems to imply it’s a stored 
>>> property. 
>>> 
>>> Michael
>>> ___
>>> 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] CustomStringConvertible?

2017-09-08 Thread Rien via swift-users
It cannot be ‘stored’ I would think.
I always compute my implementations.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - An HTTP(S) web server framework in Swift







> On 08 Sep 2017, at 19:47, Michael Rogers via swift-users 
>  wrote:
> 
> Quick question (for my own edification, as well as to demonstrate to my 
> students the power of this mail list ), is CustomStringConvertible a stored 
> property or a computed property? The docs say the latter, but when using 
> Xcode’s fabulous FIX button, it seems to imply it’s a stored property. 
> 
> Michael
> ___
> 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] Very large NSNumber values

2017-06-26 Thread Rien via swift-users
I was working with very large NSNumber values and noticed some odd behaviour 
when converting these values to integers.

An NSNumber with the value +1e+40 will when converted to Ints produce integers 
wit the value zero for Int8, UInt8, Int16, UInt16, Int32 and UInt32.
But for Int64 it will produce Int64.min
And for UInt64 it will produce UInt64.max

It would seem to me that it would be better if the behaviour were consistent 
for all conversions.

Worthy of a bug report?


Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - An HTTP(S) web server framework in Swift







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


Re: [swift-users] JSON keys survey

2017-06-23 Thread Rien via swift-users


> On 23 Jun 2017, at 18:42, Tony Parker via swift-users  
> wrote:
> 
> Hi all,
> 
> This has come up a few times in recent threads, and I wanted to gather some 
> additional info on your real world use cases. Just reply to me, and any input 
> is appreciated:
> 
> 1. Does your JSON use snake_case_keys or CamelCase or other?

Mostly CamelCase but sometimes Capitalised Spaced Out Keys

> 2. Is the key type consistent throughout the JSON?

Depends on usage

> 3. If JSONEncoder/Decoder converted these, would you have any other need to 
> specify custom keys?

Unsure, probably.

> 
> Thanks,
> - Tony
> 
> ___
> 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] Should I be using more catchless do blocks?

2017-06-19 Thread Rien via swift-users
Yes.

But: Only if it makes the code better.

I think that “understandability engineering” is just as important as “software 
engineering”. Maybe more so. After all, code that we understand has a better 
chance of working correctly than code that follows all paradigms but once the 
developer is gone nobody is able to maintain.

I.e. worry less about idiomatic programming and write more understandable code.

Swift is getting - well maybe it’s past already - the point where an 
experienced programmer can write code that no newbie has even a chance of 
understanding. If code blocks help in breaking this trend, go for it.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - An HTTP(S) web server framework in Swift







> On 19 Jun 2017, at 04:07, Michael Savich via swift-users 
>  wrote:
> 
> So, something I did not know until recently is that do blocks in Swift are 
> for more than just error handling, they can also be used to tighten scope. 
> 
> I'm wondering, why not use a ton of do blocks? Like, if I have a 
> ViewController lifecycle method like viewDidLoad, I could segment it into out 
> a do block for creating subviews, a do block for loading data into them, and 
> a do block for adding them to the view itself. This seems like it would 
> enforce grouping code tightly together.
> 
> Yes I could adopt a functional style of programming, but that has its 
> downsides too, namely reading any functional code involves trawling through a 
> long sequence of function calls. What I'm saying is, do blocks seem like a 
> way to get many of the benefits of functional programming while maintaining 
> the readability of imperative code. (Sorry functional programmers, I promise 
> I love Haskell too!)
> 
> So I guess what I'm saying is… somebody talk me down from this ledge. Is 
> there a reason I shouldn't refactor my projects to be full of do blocks? And 
> can this usage of do really be considered idiomatic Swift? Or will most 
> people reading my code be left wondering where all the try and catch 
> statements are?
> 
> Sent from my iPad
> ___
> 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] Decode a JSON object of unknown format into a Dictionary with Decodable in Swift 4

2017-06-18 Thread Rien via swift-users
Dang, hit send too soon. Sorry.

This does not address your question, so please ignore… (foot in mouth)!

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - An HTTP(S) web server framework in Swift







> On 18 Jun 2017, at 09:19, Rien  wrote:
> 
> Are you looking for a general purpose JSON interpreter / API ?
> 
> There are many of them around, and in fact I do have my own: 
> https://github.com/Balancingrock/VJson
> 
> With VJson I would write:
> 
> let json = VJson.parse(… your json object…)
> 
> and then access the metadata as:
> 
> let buyCount = (json | ”metadata” | ”buy_count”)?.intValue
> 
> or:
> 
> var buyCount: Int &= json | “metadata” | “buy_count”
> 
> To loop over the content of metadata:
> 
> for item in (json | “metadata”) ?? [ ] {
>   print (item.nameValue)
>   switch item.type {
>   case .object: …
>   case .number: …
>   case .string: …
>   etc...
>   }
> }
> 
> Obviously I am plugging my own code here, but there are many others around, I 
> understand that SwiftyJSON is quite popular but I have not used that myself.
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl - An HTTP(S) web server framework in Swift
> 
> 
> 
> 
> 
> 
> 
>> On 18 Jun 2017, at 04:07, Chris Anderson via swift-users 
>>  wrote:
>> 
>> Say I have a JSON object such as:
>> 
>>  {
>>"id": "4yq6txdpfadhbaqnwp3",
>>"email": "john@example.com",
>>"name":"John Doe",
>>"metadata": {
>>  "link_id": "linked-id",
>>  "buy_count": 4
>>}
>>  }
>> 
>> And with a struct of:
>> 
>> struct User: Codable {
>>  var id: String
>>  var email: String
>>  var name: String
>> }
>> 
>> How can I decode the `metadata` field into a Dictionary?
>> 
>> I’ve tried doing things such as, in my struct,
>> 
>> var metadata: Dictionary
>> 
>> or
>> 
>> var metadata: [String: Any]
>> 
>> But I get the error 
>> 
>> MyPlayground.playground:3:7: note: cannot automatically synthesize 
>> 'Encodable' because '<>' does not conform to 'Encodable'
>>  var metadata: Dictionary 
>> 
>> A meta or metadata field on many APIs (such as www.stripe.com) can contain 
>> whatever you want, and I still want to be able to process it on the Swift 
>> end. How can I store that meta data field into a Dictionary that I can parse 
>> apart manually after?
>> 
>> Thanks!
>> 
>> Chris Anderson
>> 
>>  
>> 
>> 
>> 
>> ___
>> 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] Decode a JSON object of unknown format into a Dictionary with Decodable in Swift 4

2017-06-18 Thread Rien via swift-users
Are you looking for a general purpose JSON interpreter / API ?

There are many of them around, and in fact I do have my own: 
https://github.com/Balancingrock/VJson

With VJson I would write:

let json = VJson.parse(… your json object…)

and then access the metadata as:

let buyCount = (json | ”metadata” | ”buy_count”)?.intValue

or:

var buyCount: Int &= json | “metadata” | “buy_count”

To loop over the content of metadata:

for item in (json | “metadata”) ?? [ ] {
print (item.nameValue)
switch item.type {
case .object: …
case .number: …
case .string: …
etc...
}
}

Obviously I am plugging my own code here, but there are many others around, I 
understand that SwiftyJSON is quite popular but I have not used that myself.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - An HTTP(S) web server framework in Swift







> On 18 Jun 2017, at 04:07, Chris Anderson via swift-users 
>  wrote:
> 
> Say I have a JSON object such as:
> 
>   {
> "id": "4yq6txdpfadhbaqnwp3",
> "email": "john@example.com",
> "name":"John Doe",
> "metadata": {
>   "link_id": "linked-id",
>   "buy_count": 4
> }
>   }
> 
> And with a struct of:
> 
> struct User: Codable {
>   var id: String
>   var email: String
>   var name: String
> }
> 
> How can I decode the `metadata` field into a Dictionary?
> 
> I’ve tried doing things such as, in my struct,
> 
> var metadata: Dictionary
> 
> or
> 
> var metadata: [String: Any]
> 
> But I get the error 
> 
> MyPlayground.playground:3:7: note: cannot automatically synthesize 
> 'Encodable' because '<>' does not conform to 'Encodable'
>   var metadata: Dictionary 
> 
> A meta or metadata field on many APIs (such as www.stripe.com) can contain 
> whatever you want, and I still want to be able to process it on the Swift 
> end. How can I store that meta data field into a Dictionary that I can parse 
> apart manually after?
> 
> Thanks!
> 
> Chris Anderson
> 
>   
> 
> 
> 
> ___
> 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] Generating html code, best practise?

2017-05-19 Thread Rien via swift-users
I want to generate some HTML code with Swift. Of course there are many way to 
do this, but I am not looking to do an "in-dept all options open” approach.
Just some ‘get the html out quickly” type of thing.

So I wonder, how do _you_ do this?

Simply using Strings is one option, but cumbersome and without any 
‘html-type-safety’
Using some general purpose function (e.g. func tagged(tag: String, content: 
String) -> String) helps a little, but not very much.
Enums are another possibility.
Or var’s in a struct/class that wrap the html element etc.

Many possibilities.

Any suggestion is welcome, suggestions as wel as experiences.
Of course if there is a solution out there, I’d like to know as well. (I didn’t 
find any though)


Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift






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


Re: [swift-users] Making Error sub-enums Equatable

2017-05-08 Thread Rien via swift-users
I’d love to know if there is a better way, but a ‘switch’ or 'if case' is the 
only way I know.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift






> On 08 May 2017, at 11:01, Rick Mann via swift-users  
> wrote:
> 
> Seriously, I've been googling this for a half-hour, and I can't find an 
> answer (everything that comes up is for ErrorType, absolutely nothing for 
> Error).
> 
> I have an enum:
> 
> enum MyErrors : Error
> {
>case one(String)
>case two
>case three(String)
> }
> 
> let a: MyErrors = .one("foo")
> let b = .two
> let c = .towo
> 
> I want to compare them with ==, and I don't care about the associated types. 
> I can't for the life of me figure out how without an exhaustive switch 
> statement in a == definition. Is that the only way?
> 
> -- 
> 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


Re: [swift-users] weak self

2017-05-02 Thread Rien via swift-users
Thanks Guillaume,

Interesting: this is a kind-of symmetry break between optionals and weak 
references.
I.e. most (inexperienced?) programmers will see a strong similarity between 
weak references and optionals.
And for a lot of use cases they do indeed behave similar.
But for weak references I think the guideline should be: Never ‘force-unwrap’ 
it.
Maybe this should be mentioned in the swift guide?
Maybe even include a warning in the compiler for this?

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift






> On 01 May 2017, at 23:26, Guillaume Lessard <gless...@tffenterprises.com> 
> wrote:
> 
> Hi Rien,
> 
>> On May 1, 2017, at 08:46, Rien via swift-users <swift-users@swift.org> wrote:
>> 
>> In my code I use a lot of queues. And (very often) I will use [weak self] to 
>> prevent doing things when ‘self’ is no longer available.
>> 
>> Now I am wondering: how does the compiler know that [weak self] is 
>> referenced?
> 
> The object never knows whether a weak reference to it is being used; in order 
> to be safe you must bind the reference — then you get a strong reference out 
> of it, and that guarantees the object stays alive as long as the strong 
> reference is in scope.
> 
> 
>> I am assuming it keeps a reverse reference from self to the [weak self] in 
>> order to ‘nil’ the [weak self] when self is nilled.
> 
> It does not.
> 
> From the perspective of the runtime, weak references are a different type 
> than normal/strong references; what’s important to know here is that getting 
> a strong reference from a weak one is thread-safe. It’s interesting to know 
> that weak references to “dead” objects are nilled out on use, lazily. When a 
> WeakReference is used, the object’s strong reference count is checked, and if 
> that is zero then the WeakReference is nilled out.
> 
> You could read Mike Ash’s description at 
> <https://www.mikeash.com/pyblog/friday-qa-2015-12-11-swift-weak-references.html>.
>  That describes Swift 3 weak references quite well. There’s a newer 
> implementation of reference counting for Swift 4, but the outwardly-visible 
> behaviour is the same.
> 
> 
>> But when a job is executing it has no control over the exclusive rights to 
>> [weak self].
>> 
>> I.e. [weak self] may be nilled by an outside event in the middle of say:
>> 
>>  if self != nil { return self!.myparam }
>> 
>> The if finding [weak self] non nil, but the return finding [weak self] as nil
>> 
>> Is that correct? i.e. should we never use the above if construct but always:
> 
> There is potential for a race on `self`, as the strong reference count could 
> go to zero between the two uses of the weak reference.
> 
> The proper way is
> 
> if let myref = self { return myref.myparam }
> 
> (or the equivalent guard.)
> That’s safe.
> 
> Cheers,
> Guillaume Lessard

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


Re: [swift-users] weak self

2017-05-01 Thread Rien via swift-users

> On 01 May 2017, at 17:42, Dennis Weissmann <den...@dennisweissmann.me> wrote:
> 
>> 
>> On May 1, 2017, at 5:32 PM, Rien <r...@balancingrock.nl> wrote:
>> 
>>> 
>>> On 01 May 2017, at 16:59, Dennis Weissmann <den...@dennisweissmann.me> 
>>> wrote:
>>> 
>>>> 
>>>> On May 1, 2017, at 4:46 PM, Rien via swift-users <swift-users@swift.org> 
>>>> wrote:
>>>> 
>>>> In my code I use a lot of queues. And (very often) I will use [weak self] 
>>>> to prevent doing things when ‘self’ is no longer available.
>>>> 
>>>> Now I am wondering: how does the compiler know that [weak self] is 
>>>> referenced?
>>>> 
>>>> I am assuming it keeps a reverse reference from self to the [weak self] in 
>>>> order to ‘nil’ the [weak self] when self is nilled.
>>>> 
>>>> But when a job is executing it has no control over the exclusive rights to 
>>>> [weak self].
>>>> 
>>>> I.e. [weak self] may be nilled by an outside event in the middle of say:
>>>> 
>>>>if self != nil { return self!.myparam }
>>>> 
>>>> The if finding [weak self] non nil, but the return finding [weak self] as 
>>>> nil
>>>> 
>>>> Is that correct? i.e. should we never use the above if construct but 
>>>> always:
>>>> 
>>>>return self?.myparam ?? 42
>>>> 
>>> 
>>> Yes, as you said, you never know when self will be nilled out, that's why 
>>> you need to create a (temporary) strong reference to it, work on it, and 
>>> when the block returns, your strong reference is released and self either 
>>> goes away immediately (incase it was released elsewhere after the local 
>>> binding to a strong variable and no other objects had a strong reference to 
>>> it) or it will stay as long as no other object holds a strong reference to 
>>> it.
>>> 
>>> When the closure is more involved than a view lines, I often do a guard let 
>>> `self` = self else { return } to conveniently work with a strong self 
>>> inside the rest of the closure.
>> 
>> I was aware of that practise (use it myself) but I was not sure if it would 
>> always work.
>> I.e. I have not found it documented that
>>  let strongSelf = self
>> will actually retain ‘self’ an not create a strong reference to an 
>> intermediate reference to self.
>> 
>> It makes sense though, otherwise there would be massive failures ‘out 
>> there’. ;-)
>> 
> 
> Yes :) local variables (as others too) are strong by default. If you want 
> them weak (you should very rarely need that though) you have to explicitly 
> mark them weak.
> 
>> will actually retain ‘self’ an not create a strong reference to an 
>> intermediate reference to self.
> 
> Isn't that the same? I might misunderstand you but they would both reference 
> the same object, no? So in the end the retain message would be sent to the 
> same object, wouldn't it? 

Just to belabour this point unnecessarily :)

If you are familiar with the compiler innards, then this might be obvious. 
However I am not, and I can imagine (crazy) scenario’s where an optional woud 
be “unwrapped” by simply taking the reference to the self from the optional and 
storing it in a new non-optional variable… :D … go figure… the mind works in 
devious ways… lol.

Rien.


> 
>> Thanks,
>> Rien.
>> 
>>> 
>>>> Regards,
>>>> Rien
>>>> 
>>>> Site: http://balancingrock.nl
>>>> Blog: http://swiftrien.blogspot.com
>>>> Github: http://github.com/Balancingrock
>>>> Project: http://swiftfire.nl - A server for websites build in Swift
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> ___
>>>> swift-users mailing list
>>>> swift-users@swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-users
>>> 
>>> - Dennis
> 
> - Dennis

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


Re: [swift-users] weak self

2017-05-01 Thread Rien via swift-users

> On 01 May 2017, at 16:59, Dennis Weissmann <den...@dennisweissmann.me> wrote:
> 
>> 
>> On May 1, 2017, at 4:46 PM, Rien via swift-users <swift-users@swift.org> 
>> wrote:
>> 
>> In my code I use a lot of queues. And (very often) I will use [weak self] to 
>> prevent doing things when ‘self’ is no longer available.
>> 
>> Now I am wondering: how does the compiler know that [weak self] is 
>> referenced?
>> 
>> I am assuming it keeps a reverse reference from self to the [weak self] in 
>> order to ‘nil’ the [weak self] when self is nilled.
>> 
>> But when a job is executing it has no control over the exclusive rights to 
>> [weak self].
>> 
>> I.e. [weak self] may be nilled by an outside event in the middle of say:
>> 
>>  if self != nil { return self!.myparam }
>> 
>> The if finding [weak self] non nil, but the return finding [weak self] as nil
>> 
>> Is that correct? i.e. should we never use the above if construct but always:
>> 
>>  return self?.myparam ?? 42
>> 
> 
> Yes, as you said, you never know when self will be nilled out, that's why you 
> need to create a (temporary) strong reference to it, work on it, and when the 
> block returns, your strong reference is released and self either goes away 
> immediately (incase it was released elsewhere after the local binding to a 
> strong variable and no other objects had a strong reference to it) or it will 
> stay as long as no other object holds a strong reference to it.
> 
> When the closure is more involved than a view lines, I often do a guard let 
> `self` = self else { return } to conveniently work with a strong self inside 
> the rest of the closure.

I was aware of that practise (use it myself) but I was not sure if it would 
always work.
I.e. I have not found it documented that
let strongSelf = self
will actually retain ‘self’ an not create a strong reference to an intermediate 
reference to self.

It makes sense though, otherwise there would be massive failures ‘out there’. 
;-)

Thanks,
Rien.

> 
>> Regards,
>> Rien
>> 
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Balancingrock
>> Project: http://swiftfire.nl - A server for websites build in Swift
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
> 
> - Dennis

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


[swift-users] weak self

2017-05-01 Thread Rien via swift-users
In my code I use a lot of queues. And (very often) I will use [weak self] to 
prevent doing things when ‘self’ is no longer available.

Now I am wondering: how does the compiler know that [weak self] is referenced?

I am assuming it keeps a reverse reference from self to the [weak self] in 
order to ‘nil’ the [weak self] when self is nilled.

But when a job is executing it has no control over the exclusive rights to 
[weak self].

I.e. [weak self] may be nilled by an outside event in the middle of say:

if self != nil { return self!.myparam }

The if finding [weak self] non nil, but the return finding [weak self] as nil

Is that correct? i.e. should we never use the above if construct but always:

return self?.myparam ?? 42

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift






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


Re: [swift-users] Why does withUnsafePointer(to:) require a var argument?

2017-04-28 Thread Rien via swift-users
You will need to take full control over allocation and deallocation.

Here is a piece of code from my project SwifterSockets (on github, see the link 
in my signature)

public func tipReceiverLoop(
socket: Int32,
bufferSize: Int,
duration: TimeInterval,
receiver: ReceiverProtocol?) {

...

// Allocate the data buffer

let buffer = UnsafeMutableRawPointer.allocate(bytes: bufferSize, alignedTo: 
1)


// 
===
// This loop stays active as long as the consumer wants more and no error 
occured.
// 
===

var cont = true
repeat {

...
// 
// Wait until select signals incoming data activity
// 

let selres = waitForSelect(socket: socket, timeout: timeout, forRead: 
true, forWrite: false)

switch selres {

...
case .ready:


// =
// Call the recv
// =

let bytesRead = Darwin.recv(socket, buffer.assumingMemoryBound(to: 
UInt8.self), bufferSize, 0)

switch bytesRead {

...
case 1 ... Int.max: // Callback for the received data
cont = receiver?.receiverData(UnsafeBufferPointer(start: 
buffer.assumingMemoryBound(to: UInt8.self), count: bytesRead)) ?? true

...}
}

} while cont


// Deallocate the data buffer

buffer.deallocate(bytes: bufferSize, alignedTo: 1)
}


Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift






> On 28 Apr 2017, at 08:02, Rick Mann  wrote:
> 
> Yeah, okay. So: how do I do this in a way that is safe?
> 
> -- 
> Rick Mann
> rm...@latencyzero.com
> 
>> On Apr 27, 2017, at 23:00, Rien  wrote:
>> 
>> To address your question:
>> 
>> https://developer.apple.com/reference/foundation/data/1779823-withunsafemutablebytes
>> 
>> "Warning
>> The byte pointer argument should not be stored and used outside of the 
>> lifetime of the call to the closure."
>> 
>> Which is exactly what you are doing, hence the code is unsafe (no pun 
>> intended).
>> 
>> Regards,
>> Rien
>> 
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Balancingrock
>> Project: http://swiftfire.nl - A server for websites build in Swift
>> 
>> 
>> 
>> 
>> 
>> 
>>> On 28 Apr 2017, at 01:38, Rick Mann  wrote:
>>> 
>>> 
 On Apr 27, 2017, at 01:48 , Alex Blewitt  wrote:
 
>>> ...
>>> 
 The let constant may not even be stored in a single place; if it's known 
 to be constant it can be in-lined at the point of use and potentially 
 unpacked and dead code elimination throw away the unused members, for 
 example.
 
 If you want to pass in a let constant into the pointer, you can create a 
 copy of it locally in a local variable and then use that instead. However 
 this will be in the local scope, so the pointer isn't valid after it 
 returns.
>>> 
>>> Ah, so this brings up another issue, then. Many of the calls in the C 
>>> library take a pointer to some memory and hang on to it, filling it in at a 
>>> later point (they make network requests). I've been doing it like this, and 
>>> it's been working, but I wonder if this is fragile:
>>> 
>>> class
>>> MyClass
>>> {
>>>  func
>>>  execute()
>>>  {
>>>  self.dataBuffer = Data(count: kLGSImageDataSize)
>>>  precondition(self.dataBuffer != nil, "Unable to allocate image buffer 
>>> (\(kLGSImageDataSize) bytes)")
>>> 
>>>  var params = c_library_params_t()
>>>  params.data_capacity = self.dataBuffer!.count
>>> 
>>>  self.dataBuffer?.withUnsafeMutableBytes
>>>  { (inBuffer) -> Void in
>>>  //  This call returns immediately, but assumes
>>>  //  it can write to inBuffer later…
>>> 
>>>  self.request = c_library_call(, inBuffer)
>>>  }
>>> 
>>>  if self.request == nil
>>>  {
>>>  //  Error
>>>  }
>>>  }
>>> 
>>>  var dataBuffer: Data?
>>> }
>>> 
>>> 
>>> -- 
>>> Rick Mann
>>> rm...@latencyzero.com
>>> 
>>> 
>> 
> 

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


Re: [swift-users] Why does withUnsafePointer(to:) require a var argument?

2017-04-28 Thread Rien via swift-users
To address your question:

https://developer.apple.com/reference/foundation/data/1779823-withunsafemutablebytes

"Warning
The byte pointer argument should not be stored and used outside of the lifetime 
of the call to the closure."

Which is exactly what you are doing, hence the code is unsafe (no pun intended).

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift






> On 28 Apr 2017, at 01:38, Rick Mann  wrote:
> 
> 
>> On Apr 27, 2017, at 01:48 , Alex Blewitt  wrote:
>> 
> ...
> 
>> The let constant may not even be stored in a single place; if it's known to 
>> be constant it can be in-lined at the point of use and potentially unpacked 
>> and dead code elimination throw away the unused members, for example.
>> 
>> If you want to pass in a let constant into the pointer, you can create a 
>> copy of it locally in a local variable and then use that instead. However 
>> this will be in the local scope, so the pointer isn't valid after it returns.
> 
> Ah, so this brings up another issue, then. Many of the calls in the C library 
> take a pointer to some memory and hang on to it, filling it in at a later 
> point (they make network requests). I've been doing it like this, and it's 
> been working, but I wonder if this is fragile:
> 
> class
> MyClass
> {
>func
>execute()
>{
>self.dataBuffer = Data(count: kLGSImageDataSize)
>precondition(self.dataBuffer != nil, "Unable to allocate image buffer 
> (\(kLGSImageDataSize) bytes)")
> 
>var params = c_library_params_t()
>params.data_capacity = self.dataBuffer!.count
> 
>self.dataBuffer?.withUnsafeMutableBytes
>{ (inBuffer) -> Void in
>//  This call returns immediately, but assumes
>//  it can write to inBuffer later…
> 
>self.request = c_library_call(, inBuffer)
>}
> 
>if self.request == nil
>{
>//  Error
>}
>}
> 
>var dataBuffer: Data?
> }
> 
> 
> -- 
> Rick Mann
> rm...@latencyzero.com
> 
> 

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


Re: [swift-users] Why does withUnsafePointer(to:) require a var argument?

2017-04-27 Thread Rien via swift-users

> On 27 Apr 2017, at 09:54, Rick Mann <rm...@latencyzero.com> wrote:
> 
>> 
>> On Apr 26, 2017, at 23:37 , Rien via swift-users <swift-users@swift.org> 
>> wrote:
>> 
>> 1) When you obtain a pointer, it can no longer be ensured by the compiler 
>> that you won’t write to it.
>> 2) A ‘let’ variable (constant) allows way more optimizations than a ‘var’. I 
>> would not be surprised if the majority of ‘let’ constants never see any 
>> memory allocation at all.
> 
> In my case, it's a field in a struct that's allocated elsewhere, and most 
> certainly exists, and is passed as a parameter, so it's 'let'. I really want 
> to be able to say "I promise I won't write to this", which seems reasonable 
> if the language is willing to give me an unsafe pointer in the first place.

IIRC this is the reason for the mutable and non-mutable version of the pointer. 
With the non-mutable pointer you cannot write to the pointee.
(At least not without some additional code)
But it is another step entirely to then allow a let assignment to be used as 
the pointee. I assume the Swift team decided to keep things simple and not 
allow let’s to be used as pointee’s. It could probably be done in theory, but I 
imagine that to be a nightmare case for compiler writers...

Regards,
Rien.

> 
> How is the immutable version of withUnsafePointer different from the mutable 
> one? It passes the argument to the closure as a mutable pointer, which must 
> mean something different.
> 
>> 
>> Regards,
>> Rien
>> 
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Balancingrock
>> Project: http://swiftfire.nl - A server for websites build in Swift
>> 
>> 
>> 
>> 
>> 
>> 
>>> On 27 Apr 2017, at 08:31, Florent Bruneau via swift-users 
>>> <swift-users@swift.org> wrote:
>>> 
>>> Hi Rick,
>>> 
>>> My understanding on this is that withUnsafePointer() requires an inout 
>>> argument because it has to take a reference to the variable in order to be 
>>> able to derive its pointer. The languages requires inout arguments to be 
>>> vars, leading to withUnsafePointer() requiring the passed object to be a 
>>> var.
>>> 
>>> There may be other subtleties I'm not aware of, though.
>>> 
>>>> Le 27 avr. 2017 à 02:42, Rick Mann via swift-users <swift-users@swift.org> 
>>>> a écrit :
>>>> 
>>>> We have withUnsafePointer(to:) and withUnsafeMutablePointer(to:). Why does 
>>>> the first take an inout parameter? The function names imply that the first 
>>>> will not modify the pointer (which I take to mean its contents), and it 
>>>> makes it quite clunky to pass in constant things.
>>>> 
>>>> -- 
>>>> Rick Mann
>>>> rm...@latencyzero.com
>>>> 
>>>> 
>>>> ___
>>>> swift-users mailing list
>>>> swift-users@swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-users
>>> 
>>> -- 
>>> Florent Bruneau
>>> 
>>> ___
>>> 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
> 
> 
> -- 
> Rick Mann
> rm...@latencyzero.com

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


Re: [swift-users] Why does withUnsafePointer(to:) require a var argument?

2017-04-27 Thread Rien via swift-users
1) When you obtain a pointer, it can no longer be ensured by the compiler that 
you won’t write to it.
2) A ‘let’ variable (constant) allows way more optimizations than a ‘var’. I 
would not be surprised if the majority of ‘let’ constants never see any memory 
allocation at all.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift






> On 27 Apr 2017, at 08:31, Florent Bruneau via swift-users 
>  wrote:
> 
> Hi Rick,
> 
> My understanding on this is that withUnsafePointer() requires an inout 
> argument because it has to take a reference to the variable in order to be 
> able to derive its pointer. The languages requires inout arguments to be 
> vars, leading to withUnsafePointer() requiring the passed object to be a var.
> 
> There may be other subtleties I'm not aware of, though.
> 
>> Le 27 avr. 2017 à 02:42, Rick Mann via swift-users  a 
>> écrit :
>> 
>> We have withUnsafePointer(to:) and withUnsafeMutablePointer(to:). Why does 
>> the first take an inout parameter? The function names imply that the first 
>> will not modify the pointer (which I take to mean its contents), and it 
>> makes it quite clunky to pass in constant things.
>> 
>> -- 
>> Rick Mann
>> rm...@latencyzero.com
>> 
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
> 
> -- 
> Florent Bruneau
> 
> ___
> 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] edit array

2017-04-26 Thread Rien via swift-users
Agree, though the function should probably be named something like: withEach 
instead of forEach.
Maybe worth a proposal on evolution?

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift






> On 26 Apr 2017, at 16:47, J.E. Schotsman via swift-users 
>  wrote:
> 
> 
> On 26 Apr 2017, at 16:27, Rien  wrote:
> 
>> To edit the value in the array itself use:
>> 
>> array[index].number += 1
> 
> That requires a for loop.
> Functional programming lets you write for loops more succinctly.
> Why can’t $0 not be used as a reference, like array[index] ?
> I've checked, it’s not among the commonly rejected proposals.
> 
> Jan E.
> 
> ___
> 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] edit array

2017-04-26 Thread Rien via swift-users
Because you are (trying) to edit a copy.

To edit the value in the array itself use:

array[index].number += 1

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift






> On 26 Apr 2017, at 16:15, J.E. Schotsman via swift-users 
>  wrote:
> 
> Simple question: why can’t I edit a variable array with a functional method?
> 
> For example:
> 
> struct TestStruct
>   {
>   var number = 0
>   }
> 
> var array = [TestStruct](repeatElement(TestStruct(), count: 2))
> array.forEach { $0.number += 1 }
> 
> Jan E.
> ___
> 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] Alternative to UnicodeScalar

2017-04-09 Thread Rien via swift-users
With the Array operations: append or insert

var tmp: [CChar] = [0, 0]
for i in 1 ... 100 {
tmp.insert(0, at: 0)
}

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift






> On 09 Apr 2017, at 06:33, Proyb P  wrote:
> 
> How do I append character A-Z by integer into CChar and benchmark timing how 
> fast it’s append compare to UInt8? 
> 
> var tmp: [CChar] = [0,0]
> for var i in 0...256 {
>tmp[0] = 100
> }
> print(String(cString: ))
> 
> 
> On Sun, Apr 9, 2017 at 3:17 AM, Proyb P  wrote:
> Agree, in some case, I seem to find Cchar is really shine at 10x faster than 
> Python from A to Z, 1000x faster than normal Swift? Not sure if there was 
> flaw in the time measurement.
> 
> 
> On Sunday, 9 April 2017, Rien  wrote:
> Server-side is usually UTF-8 (not always), so often you don’t really need 
> strings.
> As an aside, time measurements are difficult, especially when IO is involved 
> there may be thread switches or locks.
> 
> I have written some parsers (UTF-8 based) and not yet encountered performance 
> problems. (though faster is always better)
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl - A server for websites build in Swift
> 
> 
> 
> 
> 
> 
> > On 08 Apr 2017, at 18:19, Proyb P via swift-users  
> > wrote:
> >
> > I have found this took about 0.001s to print 256 characters
> > Compare to Python took 0.16s to print 256 characters, see F8 code and 
> > have modify to run only one call instead of 1000 iterations.
> > https://gist.github.com/anonymous/18e372e8d0173e77b5c405920d4d3080
> >
> > As this is frequently use for server-side swift that will definitely 
> > affected by expensive call, are there any alternative solution for 
> > converting Int to character close to Python timing?
> >
> > import Foundation
> > var display: String = ""
> >
> > func printTimeElapsedWhenRunningCode(title: String, operation: ()->()) {
> > let startTime = CFAbsoluteTimeGetCurrent()
> > operation()
> > let timeElapsed = CFAbsoluteTimeGetCurrent() - startTime
> > print("Time elapsed for \(title): \(timeElapsed) s")
> > }
> >
> > printTimeElapsedWhenRunningCode(title: "s1()") {
> > let startingValue = Int(("A" as UnicodeScalar).value) // 65
> > for i in 0 ..< 256 {
> > print(Character(UnicodeScalar(i + startingValue)!))
> > }
> > }
> > ___
> > 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 3.1 String(

2017-04-05 Thread Rien via swift-users

> On 05 Apr 2017, at 16:26, Maxim Veksler via swift-users 
>  wrote:
> 
> Hi,
> 
> Swift 3.1 compiler seems to introduces a new complier warning regarding 
> String(describing: )
> 
> So this line:
> Log.info("Update name for user \(fbUser)”)

Log.info(“Update name for user \(fbUser ?? “Unknown”)”)

Rien.

> 
> Produces the warning: "note: use 'String(describing:)' to silence this 
> warning"
> 
> and becomes this line
> Log.info("Update name for user \(String(describing: fbUser))")
> 
> This new syntax is not very sexy, especially for logging. Any suggestions, 
> possibility on the API end of Log to make this warning go away? or write it 
> differently.
> ___
> 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] Importing C system libraries

2017-03-28 Thread Rien via swift-users
I feel your pain ;-)

Just embrace the dark side, it takes a little time to get used to, but chances 
are you won’t regret it.

Btw: I still do my development in Xcode, its just that using the SPM (Swift 
Package Manager) and git from the command line gives a whole extra dimension to 
my productivity.

I use a large monitor and have two terminal windows open at all times on the 
left side, and Xcode open on the right. Two monitors would be even better (I 
think).
Xcode is really amazing: when I regenerate the project in a terminal, there is 
no need to close and reopen xcode. Xcode will collapse the navigator, but 
otherwise it just refreshes with the new content. Its quite neat to work this 
way. The only two drawbacks that I have detected so far is that I need to 
“clean” more in Xcode, and that the old project settings are overwritten, thus 
if you do a lot of tweaking of the build settings this might not work out all 
that well.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 27 Mar 2017, at 23:10, Jan Neumüller via swift-users 
>  wrote:
> 
> Is it just me, or is Swift moving to much in a command line direction since 
> the open sourcing? I feel being left behind as an Xcode user...
> 
> Jan
> 
>> On 27 Mar 2017, at 22:59, Michael Ilseman via swift-users 
>>  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
> 
> ___
> 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] Type inference of array element type

2017-03-24 Thread Rien via swift-users
I always yield to proof ;-)

hope someone more knowledgable chips in...

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 24 Mar 2017, at 11:53, Toni Suter <tonisu...@me.com> wrote:
> 
> Hmm, I don't know. It also works with other nominal types. For example:
> 
> struct S {
>   var x: Int
>   var y: Int
> }
> let s1 = S(x: 0, y: 1)
> let s2 = S(x: 2, y: 3)
> let arr = [s1, nil, s2]
> print(type(of: arr))  // Array<Optional>
> 
>> Am 24.03.2017 um 11:30 schrieb Rien <r...@balancingrock.nl>:
>> 
>> Btw, I just looked it up and it seems to me that inference only works for 
>> literals. Which probably means that tuples are out.
>> 
>> Regards,
>> Rien
>> 
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Balancingrock
>> Project: http://swiftfire.nl
>> 
>> 
>> 
>> 
>> 
>>> On 24 Mar 2017, at 11:22, Rien via swift-users <swift-users@swift.org> 
>>> wrote:
>>> 
>>> IMO this is a boundary problem.
>>> How far do you want to go in letting the compiler deduce the actual type?
>>> It is possible to make very elaborate constructs that would basically 
>>> default to a complex tuple/array/dictionary construct with only Any?’s in 
>>> them. (well, the dict would require a Hashable too)
>>> 
>>> Besides, the recent discussion on compile times illustrates another angle 
>>> to this problem: if type inference is used extensively, compile times go to 
>>> infinite…
>>> 
>>> So while I do not know if this is a bug or not, I would recommend not to 
>>> use it anyhow.
>>> 
>>> Regards,
>>> Rien
>>> 
>>> Site: http://balancingrock.nl
>>> Blog: http://swiftrien.blogspot.com
>>> Github: http://github.com/Balancingrock
>>> Project: http://swiftfire.nl
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> On 24 Mar 2017, at 11:08, Toni Suter via swift-users 
>>>> <swift-users@swift.org> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> If I declare a variable and initialize it with an array literal whose 
>>>> elements are integer literals and nil literals,
>>>> the compiler will infer the type Array<Optional> for that variable:
>>>> 
>>>> let arr = [1, nil, 3]
>>>> print(type(of: arr))   // Array<Optional>
>>>> 
>>>> However, that only works with nominal types such as Int and String. If I 
>>>> do the same thing with an array of tuples,
>>>> I get a compile error:
>>>> 
>>>> let arr = [(1, false), nil, (3, true)] // error: type of 
>>>> expression is ambiguous without more context
>>>> print(type(of: arr))
>>>> 
>>>> Why can't the compiler infer the type Array<Optional<(Int, Bool)>> in this 
>>>> example? Is there a reason for this or is it a bug?
>>>> 
>>>> Thanks and best regards,
>>>> Toni
>>>> 
>>>> ___
>>>> 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] Improving compilation times?

2017-03-23 Thread Rien via swift-users

> On 23 Mar 2017, at 08:27, David Hart <da...@hartbit.com> wrote:
> 
> Yes, it's best to avoid concatenating strings with +. Not only for 
> performance reasons, but it's also less readable than string interpolation:
> 
> str += "No: \(count), HostIp: \(clientIp ?? "?") at port: \(service ?? "?")\n”

Concatenation may cause the increase, but this solved it too:

let (clientIpOrNil, serviceOrNil) = 
sockaddrDescription(info.pointee.ai_addr)
let clientIp = clientIpOrNil ?? "?"
let service = serviceOrNil ?? "?"
str += "No: \(count), HostIp: " + clientIp + " at port: " + service + 
"\n”

Regards,
Rien.


> 
> On 23 Mar 2017, at 08:11, Rien via swift-users <swift-users@swift.org> wrote:
> 
>> Thanks for that link, used it to track down the worst compile time offender:
>> 
>> This piece of code:
>> 
>> public func logAddrInfoIPAddresses(_ infoPtr: 
>> UnsafeMutablePointer) -> String {
>> 
>>let addrInfoNil: UnsafeMutablePointer? = nil
>>var count: Int = 0
>>var info: UnsafeMutablePointer = infoPtr
>>var str: String = ""
>> 
>>while info != addrInfoNil {
>> 
>>let (clientIp, service) = sockaddrDescription(info.pointee.ai_addr)
>>str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at port: " + 
>> (service ?? "?") + "\n"
>>count += 1
>>info = info.pointee.ai_next
>>}
>>return str
>> }
>> 
>> Took 38 seconds to compile.
>> 
>> Removing the “str” assignment:
>> 
>> public func logAddrInfoIPAddresses(_ infoPtr: 
>> UnsafeMutablePointer) -> String {
>> 
>>let addrInfoNil: UnsafeMutablePointer? = nil
>>var count: Int = 0
>>var info: UnsafeMutablePointer = infoPtr
>>var str: String = ""
>> 
>>while info != addrInfoNil {
>> 
>>let (clientIp, service) = sockaddrDescription(info.pointee.ai_addr)
>> //str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at port: " 
>> + (service ?? "?") + "\n"
>>count += 1
>>info = info.pointee.ai_next
>>}
>>return str
>> }
>> 
>> Brought it down to 6.6ms
>> 
>> Obviously I have to rewrite, but it does show how just one line of code can 
>> be responsible for approx 80% of the compile time.
>> 
>> Regards,
>> Rien
>> 
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Balancingrock
>> Project: http://swiftfire.nl
>> 
>> 
>> 
>> 
>> 
>>> On 22 Mar 2017, at 23:41, Greg Parker via swift-users 
>>> <swift-users@swift.org> wrote:
>>> 
>>>> 
>>>> On Mar 22, 2017, at 1:03 PM, piotr gorzelany via swift-users 
>>>> <swift-users@swift.org> wrote:
>>>> 
>>>> Hi, I hope I reached the right mailing list to ask a question about 
>>>> tooling.
>>>> 
>>>> Can somebody from the compiler or Xcode team share some tips on how to 
>>>> improve compilation times of larger Swift projects?
>>>> 
>>>> I am an iOS developer and the largest issue my team has with Swift so far 
>>>> is that when the project gets semi large (~30 000 lines) the compilation 
>>>> times start to be high (~10 minutes from clean). This is a MAJOR downside 
>>>> since iOS development oftentimes requires rapid changes to UI or logic. 
>>>> Every person of my team compiles a project at least 10 times a day to test 
>>>> new features or functionalities. When compilation times start to be higher 
>>>> than 10 minutes that gets us to ~1.5h a day of developer time spend just 
>>>> on compiling. Not to mention the focus lost when this is happening.
>>>> 
>>>> I know the Swift Evolution list is buzzing with new ideas and features but 
>>>> from my experience the compilation times is a CRITICAL thing to improve in 
>>>> the next Swift release since it cost real money to waste all those 
>>>> developer hours. Just think of all the hours lost on compiling across all 
>>>> Swift devs worldwide and you will get to probably dozens of thousand of 
>>>> dev hours a day.
>>>> 
>>>> Is the core compiler team going to address compilation performance in the 
>>>> next release?
>

Re: [swift-users] Improving compilation times?

2017-03-23 Thread Rien via swift-users
Thanks for that link, used it to track down the worst compile time offender:

This piece of code:

public func logAddrInfoIPAddresses(_ infoPtr: UnsafeMutablePointer) 
-> String {

let addrInfoNil: UnsafeMutablePointer? = nil
var count: Int = 0
var info: UnsafeMutablePointer = infoPtr
var str: String = ""

while info != addrInfoNil {

let (clientIp, service) = sockaddrDescription(info.pointee.ai_addr)
str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at port: " + 
(service ?? "?") + "\n"
count += 1
info = info.pointee.ai_next
}
return str
}

Took 38 seconds to compile.

Removing the “str” assignment:

public func logAddrInfoIPAddresses(_ infoPtr: UnsafeMutablePointer) 
-> String {

let addrInfoNil: UnsafeMutablePointer? = nil
var count: Int = 0
var info: UnsafeMutablePointer = infoPtr
var str: String = ""

while info != addrInfoNil {

let (clientIp, service) = sockaddrDescription(info.pointee.ai_addr)
//str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at port: " + 
(service ?? "?") + "\n"
count += 1
info = info.pointee.ai_next
}
return str
}

Brought it down to 6.6ms

Obviously I have to rewrite, but it does show how just one line of code can be 
responsible for approx 80% of the compile time.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 22 Mar 2017, at 23:41, Greg Parker via swift-users  
> wrote:
> 
>> 
>> On Mar 22, 2017, at 1:03 PM, piotr gorzelany via swift-users 
>>  wrote:
>> 
>> Hi, I hope I reached the right mailing list to ask a question about tooling.
>> 
>> Can somebody from the compiler or Xcode team share some tips on how to 
>> improve compilation times of larger Swift projects?
>> 
>> I am an iOS developer and the largest issue my team has with Swift so far is 
>> that when the project gets semi large (~30 000 lines) the compilation times 
>> start to be high (~10 minutes from clean). This is a MAJOR downside since 
>> iOS development oftentimes requires rapid changes to UI or logic. Every 
>> person of my team compiles a project at least 10 times a day to test new 
>> features or functionalities. When compilation times start to be higher than 
>> 10 minutes that gets us to ~1.5h a day of developer time spend just on 
>> compiling. Not to mention the focus lost when this is happening.
>> 
>> I know the Swift Evolution list is buzzing with new ideas and features but 
>> from my experience the compilation times is a CRITICAL thing to improve in 
>> the next Swift release since it cost real money to waste all those developer 
>> hours. Just think of all the hours lost on compiling across all Swift devs 
>> worldwide and you will get to probably dozens of thousand of dev hours a day.
>> 
>> Is the core compiler team going to address compilation performance in the 
>> next release?
>> 
>> Maybe there is an existing solution to long compilation times that we don't 
>> know of? It would be great if anybody could share.
>> I was thinking maybe of dividing the app into multiple frameworks since I 
>> think frameworks are compiled only once only on change?
> 
> Build time is always a goal. Pretty much every version of Swift has had 
> changes intended to improve compilation time or decrease the frequency of 
> recompilation.
> 
> Often a large part of the build time is spent in a handful of places where 
> the compiler's type inference system behaves poorly. You can use the 
> -debug-time-function-bodies and -debug-time-expression-type-checking flags to 
> look for these places. You can often get huge decreases in compile time by 
> adding an explicit type declaration in the right place in order to simplify 
> the type inference engine's job.
> 
> Here's a walkthough of one such analysis:
> Profiling your Swift compilation times
> http://irace.me/swift-profiling
> 
> 
> -- 
> Greg Parker gpar...@apple.com Runtime Wrangler
> 
> 
> ___
> 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] It seems like we really need an #include preprocessor directive?

2017-03-11 Thread Rien via swift-users
> On 11 Mar 2017, at 21:12, Edward Connell via swift-users 
>  wrote:
> 
> Observations about difining an object
>   • Structs can't inherit and classes shouldn't inherit, final concrete 
> types should be flat

Why?
I always default to the position that we should do what works. Get the project 
done.
Sure sometimes we do become language lawyers, but don’t let that force you into 
a corner.
If you need inheritance, use it. AFAIIC OOP is a first class citizen in Swift.



>   • Protocols need to be adopted by the final concrete type, otherwise 
> constraint specializations aren't correctly applied
> This creates a really ugly code duplication situation when you have multiple 
> object variants that adopt the same protocols.
> 
> The storage declaration, common initialization, common didSet, etc... for 
> protocol member variables must be duplicated for every instance. 
> If I have 20 objects that have the same base set of 15 vars, this turns into 
> a maintenance/bug nightmare.


What about mimicking inheritance?:

struct FooBar {
  var foo: Int
  var bar: Int
}

protocol FooBarManipulation {
  var fooBar: FooBar { get set }
  func doSomethingWithFooBar()
}


extension FooBarManipulation {
   func doSomthingWithFooBar() { … }
}


class SomeClass: FooBarManipulation {
  var fooBar: FooBar?
}

struct SomeStruct: FooBarManipulation {
  var fooBar = FooBar(...)
}


Regards,
Rien.

> 
> I noticed the use of GYB in the swift source code. 
> I don't want to involve python in anything I do, and I don't want to mess up 
> my code/build with all that stuff.
> 
> It seems that an easy workaround would be an #include statement. 
> The boiler plate can be put in a separate file and included wherever it's 
> needed. 
> One piece of code, one tool, one set of bugs.
> 
> Has this been considered? Or is there a better way to handle this problem.
> 
> Thanks, Ed
> ___
> 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] Generics with variable argument lists

2017-03-09 Thread Rien via swift-users
Ah!, yes that would be perfect!

Many thanks!

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 09 Mar 2017, at 12:36, Ole Begemann <o...@oleb.net> wrote:
> 
> On 09/03/2017 11:05, Rien via swift-users wrote:
>> I am trying to achieve the following:
>> 
>> enum FunctionResult {
>>  case success(T)
>>  case error(String)
>> }
>> 
>> func tester(test: (…) -> FunctionResult, onError: (String) -> T) -> T {
>>   …
>> }
>> 
>> The problem is of course the (…) that simply does not work.
>> 
>> I would like to use this generic with a variety of different signatures, 
>> i.e.:
>> 
>> let result1 = tester(test: myfunc1(param: 26) -> FunctionResult, 
>> onError: { … handle the error ... })
>> let result2 = tester(test: myfunc2(param: “A String") -> 
>> FunctionResult, onError: { … handle the error ... })
>> let result3 = tester(test: myfunc3(param: 26, param2: “String") -> 
>> FunctionResult, onError: { … handle the error ... })
>> 
>> Is this at all possible?
> 
> This should do it:
> 
>func tester(test: @autoclosure () -> FunctionResult,
>onError: (String) -> T) -> T {
>switch test() {
>case .success(let value): return value
>case .error(let error): return onError(error)
>}
>}
> 
> The insight is that you don't really want to pass a function in the first 
> parameter, but only the _result_ of that function call. The @autoclosure 
> attribute then makes sure that the expression you pass to tester is only 
> evaluated inside tester. You can leave it out if you want (if you do, replace 
> `switch test()` with `switch test`).

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


[swift-users] Generics with variable argument lists

2017-03-09 Thread Rien via swift-users
I am trying to achieve the following:

enum FunctionResult {
  case success(T)
  case error(String)
}

func tester(test: (…) -> FunctionResult, onError: (String) -> T) -> T {
   …
}

The problem is of course the (…) that simply does not work.

I would like to use this generic with a variety of different signatures, i.e.:

let result1 = tester(test: myfunc1(param: 26) -> FunctionResult, onError: 
{ … handle the error ... })
let result2 = tester(test: myfunc2(param: “A String") -> FunctionResult, 
onError: { … handle the error ... })
let result3 = tester(test: myfunc3(param: 26, param2: “String") -> 
FunctionResult, onError: { … handle the error ... })

Is this at all possible?

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





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


Re: [swift-users] What is the intended response to Array change notification for dependents?

2017-03-06 Thread Rien via swift-users
I don’t think there is a single answer to this. It is all highly dependant on 
what the application does with the info.
Sometimes it will indeed be necessary to rebuild the entire gui, other times it 
is enough to simply insert a new table cell.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 07 Mar 2017, at 03:56, Edward Connell via swift-users 
>  wrote:
> 
> I would like to have an Array implementation where I get more information 
> than just "the whole thing changed". 
> As a value type I get it, but lets say it's a list of 500 image info structs 
> and it's bound to UI. You change one item, now the whole array changes and 
> you have to rebuild the entire visual tree right? Rebuilding the state of 
> dependent objects can be really expensive, not just UI things.
> 
> Is there some efficient strategy that the library designers intended for this 
> situation? 
> It seems like a really common and obvious scenario.
> Insights and suggestions are appreciated.
> 
> Thanks, Ed
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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


Re: [swift-users] How to optionally link swift framework into another framework

2017-03-06 Thread Rien via swift-users
The way I look at it is that Swift wants all symbols resolved when linking.
C++ is probably very lenient toward full resolution, and as long as you know 
that a certain unresolved reference is not used, you can safely ignore the 
warning.
Or maybe the C++ compiler is just very clever and can figure out that the 
reference is never used?

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 06 Mar 2017, at 18:09, Jakub Bednář  wrote:
> 
> Hi Rien,
> 
> looks like a good way around my problem.
> 
> Still I wonder why this does not work in Swift as it does work in Objective-C 
> or even in strongly typed checked C++.
> 
> Maybe it is some kind of Swift’s security measure to avoid hard-to-debug bugs 
> in C++ caused by virtual table inconsistencies.
> 
> Anyway, thanks for the help.
> 
> J.
> 
> 
>> On Mar 6, 2017, at 6:01 PM, Rien  wrote:
>> 
>> Well, that was a bit short…
>> 
>> When you want to use logging, define the ACC “USE_LOGGING” in the build 
>> settings.
>> When you don’t want to use logging, don’t define the ACC.
>> 
>> PS: You can get my logging framework from github: 
>> https://github.com/Balancingrock/SwifterLog
>> 
>> Regards,
>> Rien
>> 
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Balancingrock
>> Project: http://swiftfire.nl
>> 
>> 
>> 
>> 
>> 
>>> On 06 Mar 2017, at 17:58, Rien  wrote:
>>> 
>>> You need conditional compilation.
>>> 
>>> Called “Active Compilation Conditions” in the build settings.
>>> 
>>> For example define a ACC of “USE_LOGGING”
>>> 
>>> Then in your code:
>>> 
>>> #if USE_LOGGING
>>> 
>>> import Logging
>>> 
>>> #else
>>> 
>>> struct Logging {
>>> func debug(message: string) {}
>>> }
>>> 
>>> #endif
>>> 
>>> 
>>> 
>>> 
>>> Regards,
>>> Rien
>>> 
>>> Site: http://balancingrock.nl
>>> Blog: http://swiftrien.blogspot.com
>>> Github: http://github.com/Balancingrock
>>> Project: http://swiftfire.nl
>>> 
>>> 
>>> 
>>> 
>>> 
 On 06 Mar 2017, at 17:26, Jakub Bednář via swift-users 
  wrote:
 
 Hello everyone,
 
 I am trying to add optional logging into my framework, but for sake of 
 this question, lets assume I want to add optional logging into an app. I 
 have created an example with following setup:
 
 1. Logging.framework declares
 
public protocol Logging {
func debug(message: String)
}
 
and I have build the framework for the app to see it.
 
 2. Application has 
 
import Logging

public class Engine {
 
let logger: Logging?
 
public init(withLogger logger: Logging? = nil) {
self.logger = logger 
}
 
public work() {
self.logger?.debug(“Working”)
}
} 
 
 Now I don’t have the Logging.framework in Embed Binaries nor Link 
 Frameworks lists. My app builds ok, but then fails to start telling me 
 that Logging.framework was not loaded. I checked the binary using otool -L 
 and Logging.framework is still referenced by the binary. Is there any way 
 how to achieve my goal? This would be trivial with Objective-C and I still 
 can’t figure it out in Swift.
 
 Thanks a lot,
 
 J.
 
 ___
 swift-users mailing list
 swift-users@swift.org
 https://lists.swift.org/mailman/listinfo/swift-users
>>> 
>> 
> 

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


Re: [swift-users] How to optionally link swift framework into another framework

2017-03-06 Thread Rien via swift-users
Well, that was a bit short…

When you want to use logging, define the ACC “USE_LOGGING” in the build 
settings.
When you don’t want to use logging, don’t define the ACC.

PS: You can get my logging framework from github: 
https://github.com/Balancingrock/SwifterLog

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 06 Mar 2017, at 17:58, Rien  wrote:
> 
> You need conditional compilation.
> 
> Called “Active Compilation Conditions” in the build settings.
> 
> For example define a ACC of “USE_LOGGING”
> 
> Then in your code:
> 
> #if USE_LOGGING
> 
> import Logging
> 
> #else
> 
> struct Logging {
>   func debug(message: string) {}
> }
> 
> #endif
> 
> 
> 
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl
> 
> 
> 
> 
> 
>> On 06 Mar 2017, at 17:26, Jakub Bednář via swift-users 
>>  wrote:
>> 
>> Hello everyone,
>> 
>> I am trying to add optional logging into my framework, but for sake of this 
>> question, lets assume I want to add optional logging into an app. I have 
>> created an example with following setup:
>> 
>> 1. Logging.framework declares
>> 
>>  public protocol Logging {
>>  func debug(message: String)
>>  }
>> 
>>  and I have build the framework for the app to see it.
>> 
>> 2. Application has 
>> 
>>  import Logging
>>  
>>  public class Engine {
>> 
>>  let logger: Logging?
>> 
>>  public init(withLogger logger: Logging? = nil) {
>>  self.logger = logger 
>>  }
>> 
>>  public work() {
>>  self.logger?.debug(“Working”)
>>  }
>>  } 
>> 
>> Now I don’t have the Logging.framework in Embed Binaries nor Link Frameworks 
>> lists. My app builds ok, but then fails to start telling me that 
>> Logging.framework was not loaded. I checked the binary using otool -L and 
>> Logging.framework is still referenced by the binary. Is there any way how to 
>> achieve my goal? This would be trivial with Objective-C and I still can’t 
>> figure it out in Swift.
>> 
>> Thanks a lot,
>> 
>> J.
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
> 

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


Re: [swift-users] How to optionally link swift framework into another framework

2017-03-06 Thread Rien via swift-users
You need conditional compilation.

Called “Active Compilation Conditions” in the build settings.

For example define a ACC of “USE_LOGGING”

Then in your code:

#if USE_LOGGING

import Logging

#else

struct Logging {
func debug(message: string) {}
}

#endif




Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 06 Mar 2017, at 17:26, Jakub Bednář via swift-users 
>  wrote:
> 
> Hello everyone,
> 
> I am trying to add optional logging into my framework, but for sake of this 
> question, lets assume I want to add optional logging into an app. I have 
> created an example with following setup:
> 
> 1. Logging.framework declares
> 
>   public protocol Logging {
>   func debug(message: String)
>   }
> 
>   and I have build the framework for the app to see it.
> 
> 2. Application has 
> 
>   import Logging
>   
>   public class Engine {
> 
>   let logger: Logging?
> 
>   public init(withLogger logger: Logging? = nil) {
>   self.logger = logger 
>   }
> 
>   public work() {
>   self.logger?.debug(“Working”)
>   }
>   } 
> 
> Now I don’t have the Logging.framework in Embed Binaries nor Link Frameworks 
> lists. My app builds ok, but then fails to start telling me that 
> Logging.framework was not loaded. I checked the binary using otool -L and 
> Logging.framework is still referenced by the binary. Is there any way how to 
> achieve my goal? This would be trivial with Objective-C and I still can’t 
> figure it out in Swift.
> 
> Thanks a lot,
> 
> J.
> 
> ___
> 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] Function conforming to a typealias

2017-02-18 Thread Rien via swift-users
Just tried it, unfortunately it does not achieve what I wanted. As soon as a 
parameter is added, the compiler complains (rightly so) about ignoring an 
argument.

Oh well, at least I get warnings when parameters are added so that I don’t have 
to remember which functions need a touch-up.
 
Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 18 Feb 2017, at 12:05, Rien via swift-users <swift-users@swift.org> wrote:
> 
> It feels a bit strange to write it like that, but yes, that would work. 
> Thanks!
> 
> (It will prevent me from having to touch up old functions when adding more 
> parameters to the signature as the project evolves)
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl
> 
> 
> 
> 
> 
>> On 18 Feb 2017, at 11:52, Adrian Zubarev <adrian.zuba...@devandartist.com> 
>> wrote:
>> 
>> Not sure what you’re trying to solve there but you could use it like this 
>> with closures:
>> 
>> typealias Function = (Int, Bool) -> String?
>> 
>> let myGreatFunc1: Function = { _ in return nil /* or whatever you need there 
>> */ }
>> let myGreatFunc2: Function = { _ in return nil }
>> 
>> 
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 18. Februar 2017 um 11:47:26, Rien via swift-users 
>> (swift-users@swift.org) schrieb:
>> 
>>> I want to create a few functions that all have the same signature.
>>> 
>>> The signature is defined in a typealias
>>> 
>>> Is there any way to shortcut the function definition, or alternatively 
>>> ensure that the function signature will always be equal to the typealias?
>>> 
>>> Examplecode:
>>> 
>>> typealias Mysig = (Int, Bool) -> String?
>>> 
>>> func myGreatFunc1:Mysig {…}
>>> 
>>> func myGreatFunc2:Mysig { …}
>>> 
>>> Alternatively
>>> 
>>> @conformsTo(Mysig)
>>> func myGreatFunc1(_ a:Int, _ b: Bool) -> String? {…}
>>> 
>>> Regards,
>>> Rien
>>> 
>>> Site: http://balancingrock.nl
>>> Blog: http://swiftrien.blogspot.com
>>> Github: http://github.com/Balancingrock
>>> Project: http://swiftfire.nl
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> 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] Function conforming to a typealias

2017-02-18 Thread Rien via swift-users
It feels a bit strange to write it like that, but yes, that would work. Thanks!

(It will prevent me from having to touch up old functions when adding more 
parameters to the signature as the project evolves)

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 18 Feb 2017, at 11:52, Adrian Zubarev <adrian.zuba...@devandartist.com> 
> wrote:
> 
> Not sure what you’re trying to solve there but you could use it like this 
> with closures:
> 
> typealias Function = (Int, Bool) -> String?
> 
> let myGreatFunc1: Function = { _ in return nil /* or whatever you need there 
> */ }
> let myGreatFunc2: Function = { _ in return nil }
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 18. Februar 2017 um 11:47:26, Rien via swift-users (swift-users@swift.org) 
> schrieb:
> 
>> I want to create a few functions that all have the same signature.
>> 
>> The signature is defined in a typealias
>> 
>> Is there any way to shortcut the function definition, or alternatively 
>> ensure that the function signature will always be equal to the typealias?
>> 
>> Examplecode:
>> 
>> typealias Mysig = (Int, Bool) -> String?
>> 
>> func myGreatFunc1:Mysig {…}
>> 
>> func myGreatFunc2:Mysig { …}
>> 
>> Alternatively
>> 
>> @conformsTo(Mysig)
>> func myGreatFunc1(_ a:Int, _ b: Bool) -> String? {…}
>> 
>> Regards,
>> Rien
>> 
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Balancingrock
>> Project: http://swiftfire.nl
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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] Function conforming to a typealias

2017-02-18 Thread Rien via swift-users
Sorry: “prevent me from” should have been “allow me to avoid”

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 18 Feb 2017, at 12:05, Rien <r...@balancingrock.nl> wrote:
> 
> It feels a bit strange to write it like that, but yes, that would work. 
> Thanks!
> 
> (It will prevent me from having to touch up old functions when adding more 
> parameters to the signature as the project evolves)
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl
> 
> 
> 
> 
> 
>> On 18 Feb 2017, at 11:52, Adrian Zubarev <adrian.zuba...@devandartist.com> 
>> wrote:
>> 
>> Not sure what you’re trying to solve there but you could use it like this 
>> with closures:
>> 
>> typealias Function = (Int, Bool) -> String?
>> 
>> let myGreatFunc1: Function = { _ in return nil /* or whatever you need there 
>> */ }
>> let myGreatFunc2: Function = { _ in return nil }
>> 
>> 
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 18. Februar 2017 um 11:47:26, Rien via swift-users 
>> (swift-users@swift.org) schrieb:
>> 
>>> I want to create a few functions that all have the same signature.
>>> 
>>> The signature is defined in a typealias
>>> 
>>> Is there any way to shortcut the function definition, or alternatively 
>>> ensure that the function signature will always be equal to the typealias?
>>> 
>>> Examplecode:
>>> 
>>> typealias Mysig = (Int, Bool) -> String?
>>> 
>>> func myGreatFunc1:Mysig {…}
>>> 
>>> func myGreatFunc2:Mysig { …}
>>> 
>>> Alternatively
>>> 
>>> @conformsTo(Mysig)
>>> func myGreatFunc1(_ a:Int, _ b: Bool) -> String? {…}
>>> 
>>> Regards,
>>> Rien
>>> 
>>> Site: http://balancingrock.nl
>>> Blog: http://swiftrien.blogspot.com
>>> Github: http://github.com/Balancingrock
>>> Project: http://swiftfire.nl
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> 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] Function conforming to a typealias

2017-02-18 Thread Rien via swift-users
I want to create a few functions that all have the same signature.

The signature is defined in a typealias

Is there any way to shortcut the function definition, or alternatively ensure 
that the function signature will always be equal to the typealias?

Examplecode:

typealias Mysig = (Int, Bool) -> String?

func myGreatFunc1:Mysig {…}

func myGreatFunc2:Mysig { …}

Alternatively

@conformsTo(Mysig)
func myGreatFunc1(_ a:Int, _ b: Bool) -> String? {…}

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





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


Re: [swift-users] ambiguous minus operator

2017-02-16 Thread Rien via swift-users
I don’t know about the candidates

But the uptimeNanoseconds is a UInt64 and as such you should probably use 
substractWithOverflow.

var a: UInt64 = 12
var b: UInt64 = 25

let result = UInt64.subtractWithOverflow(a, b)

if result.overflow {
print("Overflow")
} else {
let answer = result.0
}

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 16 Feb 2017, at 16:56, J.E. Schotsman via swift-users 
>  wrote:
> 
> Hello,
> 
> I am trying to define an operator that subtracts dispatch times:
> 
> #import Dispatch
> 
> func -( time1: DispatchTime, time2: DispatchTime ) -> DispatchTimeInterval
>   {
>   return DispatchTimeInterval.nanoseconds( time2.uptimeNanoseconds - 
> time1.uptimeNanoseconds )
>   }
> 
> Compiler says: Ambiguous use of operator ‘-'
> Found this candidate
> Found this candidate
> 
> As usual the candidates are unknown.
> 
> What am I doing wrong?
> 
> Jan E.
> ___
> 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] UnsafePointer to UInt64

2017-02-16 Thread Rien via swift-users
Excellent!

I had not seen the bitPattern initializer before…

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 16 Feb 2017, at 14:47, Martin R <martinr...@gmail.com> wrote:
> 
> // Int to pointer:
> let ptr = UnsafePointer(bitPattern: 123)!
> print(ptr) // 0x007b
> 
> // Pointer to Int:
> let int = Int(bitPattern: ptr)
> print(int) // 123
> 
> Int has the same size as a pointer on both 32-bit and 64-bit platforms.
> 
> Regards, Martin
> 
>> On 16 Feb 2017, at 14:27, Rien via swift-users <swift-users@swift.org> wrote:
>> 
>> What would be the easiest (and fastest) way to convert a pointer to an 
>> (unsigned)integer?
>> 
>> Ptr -> String -> Int
>> 
>> seems a bit cumbersome to me :-)
>> 
>> Regards,
>> Rien
>> 
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Balancingrock
>> Project: http://swiftfire.nl
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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] UnsafePointer to UInt64

2017-02-16 Thread Rien via swift-users
What would be the easiest (and fastest) way to convert a pointer to an 
(unsigned)integer?

Ptr -> String -> Int

seems a bit cumbersome to me :-)

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





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


Re: [swift-users] [swift-evolution] Plan to move swift-evolution and swift-users mailing lists to Discourse

2017-02-09 Thread Rien via swift-users

> On 09 Feb 2017, at 18:29, Cihat Gündüz via swift-evolution 
>  wrote:
> 
> @Jan: Your arguments are very subjective if not even insulting and derogatory 
> to many people who invest a lot of time and effort in crafting those things 
> you despise so openly. Here are just a few example quotes for you to reflect 
> your language:
> 
> "I despise fp“, „is so annoying“, "made Swift imo a worse language“, "I hate 
> ‚modern' or as I call it ugly“, "Today’s standards are a bag of pain“, 
> "crappy sites als Facebook, Twitter, Instagram, Stackoverflow, add lots of 
> other 'cool' sites“, "I can’t stand scrolling“, "I hate both“, "todays 
> absolutely useless crap“, …
> 
> Please be aware that this behavior is against the Code of Conduct of the 
> Swift Community. Let’s try to stay objective and justify different opinions 
> rationally instead of personally. Of course it is valid for you to say that 
> you don’t like FP or that you don’t like how the world is changing in 
> general. But please be aware that you have to add the reason why you think it 
> is so in detail, so we understand your thinking and can overcome changes to 
> the wrong direction. Senctences like „I despise FP“ without any explanation 
> are not a form of constructive feedback though, nobody will learn anything 
> from that kind of thing. Currently you’re merely expressing your anger here, 
> no more, no less.

I don’t think he did. He expressed his opinions rather forcefully, but we all 
tick different. He did not call anybody out specifically.
And just because somebody spend a lot of time on something does not make it 
great. And maybe they need to hear it this way to “get the message”. Sugar 
coating can do a lot of harm.

Btw: this does remind me of some of things I heard about a former -too early 
deceased- leader of apple...

Rien.


> 
> 
> @Jens: One of the biggest reasons I’m all for Discourse is the fact that it’s 
> open source. What this implies is: You know exactly what happens with the 
> data you save there, and, there is no dependency on a third-party service 
> which could change or even close over time. This is why I’m against 
> groups.io, GitHub Issues or any other non-open source solution. What it also 
> means is: If the open source tool we decided to go for (Discourse) doesn’t 
> have good support for emails yet, we can implement it ourselves, improve the 
> existing support or add a bridge to another open source tool that can deal 
> with that.
> 
> -- 
> Cihat Gündüz
> 
> Am 9. Februar 2017 um 15:59:33, Jan Neumüller via swift-evolution 
> (swift-evolut...@swift.org) schrieb:
> 
>> Well, if the community likes it so much. Have fun with it. I will leave as I 
>> have left the Developer Forums at Apple because they became unusable.
>> 
>> 
>>> On 9 Feb 2017, at 15:17, Adrian Zubarev  
>>> wrote:
>>> 
>>> The quote below made my day dear Swift friend as I might remind you that if 
>>> modern is associated with hate in your mind, then the modern programming 
>>> language called Swift would probably be a bad choice. 
>>> 
>>> 
>> I starting to think that myself. I was very active at the beginning of Swift 
>> (way before the open sourcing) but I absolutely don’t like the increasing 
>> influence of functional programming on it. I despise fp and don’t want it in 
>> Swift. If people want it that much use Haskell 8(
>>> I might remind everyone that Discourse is open sourced and therefore tweaks 
>>> are possible. If you prefer a consistent font like on swift.org, than spell 
>>> it out and help to create a corner on the web where every Swiftier feels 
>>> right at home. 
>>> 
>>> 
>> I don’t think that Discourse is salvageable but go on. But I don’t know how 
>> one could rip out this big piece of JavaScript and keep ist functional.
>>> Personally I’d prefer (if possible) that we’d remove profile pictures from 
>>> the forum and simply have only full names (colored?) + some kind of 
>>> annotation (e.g. Core Team, etc.). Profile pictures are only gimmicks that 
>>> does not contribute to anything at all.
>>> 
>>> As Jan already said, the font (and font-size?) of the forum could match the 
>>> font from swift.org if possible. I wouldn’t mind and it’d make it a little 
>>> bit more alike.
>>> 
>>> 
>> You don’t have to care for me - Swift 4 will be the deciding step if I throw 
>> any Swift work away and return to Objective-C. The heavy functional 
>> programming push since open sourcing is so annoying and made Swift imo a 
>> worse language.
>> 
>> Jan
>> ___
>> swift-evolution mailing list
>> swift-evolut...@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolut...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-users mailing list

Re: [swift-users] Custom operators in a framework

2017-02-03 Thread Rien via swift-users
Facepalm!

Of course!, thanks for clearing that up!

I will file a bug report for the diagnostics.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 04 Feb 2017, at 02:14, Jordan Rose <jordan_r...@apple.com> wrote:
> 
> Interesting. I actually see two errors:
> 
> /Users/jrose/Desktop/SwifterJSON/App/AppDelegate.swift:19:18: error: 
> ambiguous operator declarations found for operator
> json["root"] &= 4
>  ^
> :0: note: found this matching operator declaration
> :0: note: found this matching operator declaration
> /Users/jrose/Desktop/SwifterJSON/App/AppDelegate.swift:19:18: error: operator 
> is not a known binary operator
> json["root"] &= 4
>  ^
> 
> which actually seems correct in retrospect: '&=' is already a valid operator 
> in the 'Swift' library, and you're redefining it rather than just reusing 
> that definition. It works if I either remove your `infix operator &=` 
> declaration (and leave all the implementations in place), or if I change to 
> an operator that isn't already defined. Can you file a bug at bugs.swift.org 
> for the lousy diagnostics, at least?
> 
> Jordan
> 
> 
>> On Feb 3, 2017, at 11:34, Rien <r...@balancingrock.nl> wrote:
>> 
>> This is the “defining” package/module:
>> 
>> https://github.com/Balancingrock/SwifterJSON
>> 
>> For the consuming package simply generate a new executable and put the 
>> following in main.swift:
>> 
>> 
>> import SwifterJSON
>> 
>> 
>> // Note: Error disappears when the line below is un-commented
>> 
>> // infix operator &=
>> 
>> var json = VJson()
>> 
>> json["root"] &= 4
>> 
>> print(json.code)
>> 
>> 
>> (seems I have hit a snag with github, otherwise I would create a new repo 
>> for the executable… sorry for that.)
>> 
>> Regards,
>> Rien
>> 
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Balancingrock
>> Project: http://swiftfire.nl
>> 
>> 
>> 
>> 
>> 
>>> On 03 Feb 2017, at 18:36, Jordan Rose <jordan_r...@apple.com> wrote:
>>> 
>>> The operator itself. If you’re not seeing that behavior, that’s a bug! Do 
>>> you have a small test case that reproduces it? (I guess it would take two 
>>> modules regardless, so either a SwiftPM package or an Xcode project would 
>>> do it.)
>>> 
>>> Jordan
>>> 
>>>> On Feb 3, 2017, at 09:34, Rien <r...@balancingrock.nl> wrote:
>>>> 
>>>> Are you referring to the definition of the operator (infix…) or the 
>>>> availability of the function that defines the operator?
>>>> 
>>>> The functions are available, but I have to repeat the “infix…" everywhere 
>>>> I need them.
>>>> 
>>>> I.e. I have a:
>>>> 
>>>> infix operator &=
>>>> 
>>>> And when I use that from another module I get “Operator is not a known 
>>>> binary operator”
>>>> 
>>>> Once I repeat the "infix operator &=“ at the start of the file it works 
>>>> fine.
>>>> 
>>>> Regards,
>>>> Rien
>>>> 
>>>> Site: http://balancingrock.nl
>>>> Blog: http://swiftrien.blogspot.com
>>>> Github: http://github.com/Balancingrock
>>>> Project: http://swiftfire.nl
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On 03 Feb 2017, at 18:14, Jordan Rose <jordan_r...@apple.com> wrote:
>>>>> 
>>>>> Operator declarations are actually public all the time, not internal. 
>>>>> That’s itself probably a bug, but not the world-limiting one you’re 
>>>>> concerned about.
>>>>> 
>>>>> Jordan
>>>>> 
>>>>> 
>>>>>> On Feb 3, 2017, at 01:18, Rien via swift-users <swift-users@swift.org> 
>>>>>> wrote:
>>>>>> 
>>>>>> It is possible to define custom operators in a framework, but it is not 
>>>>>> possible to assign access levels to them.
>>>>>> 
>>>>>> As a consequence they are module internal and cannot be used outside the 
>>>>>> framework.
>>>>>> 
>>>>>> Each project needs to redefine the custom operators in order to use them 
>>>>>> in that project.
>>>>>> 
>>>>>> What is the rationale behind that?
>>>>>> 
>>>>>> Or is it a bug?
>>>>>> 
>>>>>> Are there other ways to accomplish this?
>>>>>> 
>>>>>> Regards,
>>>>>> Rien
>>>>>> 
>>>>>> Site: http://balancingrock.nl
>>>>>> Blog: http://swiftrien.blogspot.com
>>>>>> Github: http://github.com/Balancingrock
>>>>>> Project: http://swiftfire.nl
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ___
>>>>>> 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] Custom operators in a framework

2017-02-03 Thread Rien via swift-users
This is the “defining” package/module:

https://github.com/Balancingrock/SwifterJSON

For the consuming package simply generate a new executable and put the 
following in main.swift:


import SwifterJSON


// Note: Error disappears when the line below is un-commented

// infix operator &=

var json = VJson()

json["root"] &= 4

print(json.code)


(seems I have hit a snag with github, otherwise I would create a new repo for 
the executable… sorry for that.)

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 03 Feb 2017, at 18:36, Jordan Rose <jordan_r...@apple.com> wrote:
> 
> The operator itself. If you’re not seeing that behavior, that’s a bug! Do you 
> have a small test case that reproduces it? (I guess it would take two modules 
> regardless, so either a SwiftPM package or an Xcode project would do it.)
> 
> Jordan
> 
>> On Feb 3, 2017, at 09:34, Rien <r...@balancingrock.nl> wrote:
>> 
>> Are you referring to the definition of the operator (infix…) or the 
>> availability of the function that defines the operator?
>> 
>> The functions are available, but I have to repeat the “infix…" everywhere I 
>> need them.
>> 
>> I.e. I have a:
>> 
>> infix operator &=
>> 
>> And when I use that from another module I get “Operator is not a known 
>> binary operator”
>> 
>> Once I repeat the "infix operator &=“ at the start of the file it works fine.
>> 
>> Regards,
>> Rien
>> 
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Balancingrock
>> Project: http://swiftfire.nl
>> 
>> 
>> 
>> 
>> 
>>> On 03 Feb 2017, at 18:14, Jordan Rose <jordan_r...@apple.com> wrote:
>>> 
>>> Operator declarations are actually public all the time, not internal. 
>>> That’s itself probably a bug, but not the world-limiting one you’re 
>>> concerned about.
>>> 
>>> Jordan
>>> 
>>> 
>>>> On Feb 3, 2017, at 01:18, Rien via swift-users <swift-users@swift.org> 
>>>> wrote:
>>>> 
>>>> It is possible to define custom operators in a framework, but it is not 
>>>> possible to assign access levels to them.
>>>> 
>>>> As a consequence they are module internal and cannot be used outside the 
>>>> framework.
>>>> 
>>>> Each project needs to redefine the custom operators in order to use them 
>>>> in that project.
>>>> 
>>>> What is the rationale behind that?
>>>> 
>>>> Or is it a bug?
>>>> 
>>>> Are there other ways to accomplish this?
>>>> 
>>>> Regards,
>>>> Rien
>>>> 
>>>> Site: http://balancingrock.nl
>>>> Blog: http://swiftrien.blogspot.com
>>>> Github: http://github.com/Balancingrock
>>>> Project: http://swiftfire.nl
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> ___
>>>> 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 101: JSON or XML?

2017-02-03 Thread Rien via swift-users
I do not think there is a ‘best’ answer.

I would go with JSON though.

Apple’s JSON solution is fast, but it has some minor limitations and usability 
is not “up there”.

Then again there are third party solutions, for example my own SwifterJSON 
single-class framework that you can download from github. :-)

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 03 Feb 2017, at 14:00, Roy Henderson via swift-users 
>  wrote:
> 
> Hi,
> 
> I'm about to develop my first non-trivial (for me) Swift 3 app. It will 
> retrieve data from a web server and present it on an iOS device.
> 
> I would welcome guidance regarding whether I should use JSON or XML to store 
> the data on the web server? The effort to generate either format will be 
> similar so my real decision driver is on the client side. Volume will 
> typically be 100-250 "records" per request with each record comprising 5-10 
> text fields.
> 
> I don't want to pull in any third-party components but stay entirely Apple.
> 
> TIA,
> 
> Roy
> ___
> 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] Custom operators in a framework

2017-02-03 Thread Rien via swift-users
It is possible to define custom operators in a framework, but it is not 
possible to assign access levels to them.

As a consequence they are module internal and cannot be used outside the 
framework.

Each project needs to redefine the custom operators in order to use them in 
that project.

What is the rationale behind that?

Or is it a bug?

Are there other ways to accomplish this?

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





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


Re: [swift-users] SPM: how to create cocoa xcode projects?

2017-01-26 Thread Rien via swift-users

> On 26 Jan 2017, at 17:58, Doug Hill <swiftus...@breaqz.com> wrote:
> 
> In Xcode, select menu item File>New>Project
> 
> Select the template for macOS>Cocoa Application
> 
> Doug Hill
> 

Yes, but what is the best way to create a cocoa application building on a bunch 
of SPM packages?

Rien.

> 
>> On Jan 26, 2017, at 4:24 AM, Rien via swift-users <swift-users@swift.org> 
>> wrote:
>> 
>> Just a quick question,
>> 
>>> swift package init —type executable
>> 
>> creates an xcode project with a main.swift.
>> 
>> I want to create a macOS cocoa based application.
>> 
>> How is that best achieved?
>> Or is that not supported yet?
>> 
>> Regards,
>> Rien
>> 
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Balancingrock
>> Project: http://swiftfire.nl
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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] SPM: how to create cocoa xcode projects?

2017-01-26 Thread Rien via swift-users
Just a quick question,

> swift package init —type executable

creates an xcode project with a main.swift.

I want to create a macOS cocoa based application.

How is that best achieved?
Or is that not supported yet?

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





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


Re: [swift-users] SPM: no such module - System Library Wrapper

2017-01-26 Thread Rien via swift-users
Thanks, that was interesting.
However I did not find a solution.

The problem is not that my COpenSsl does not work, it does. I can compile & 
link SecureSockets just fine.

However the (macOS cocoa) app that uses SecureSockets -even though it does not 
use COpenSsl- wants access to that module. And I don’t know how to provide 
that, nor do I know how to prevent this.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 26 Jan 2017, at 11:53, Alex Blewitt <alb...@apple.com> wrote:
> 
> Have a look at BlueSockets which does the same kind of thing:
> 
> https://github.com/IBM-Swift/BlueSocket 
> https://github.com/IBM-Swift/BlueSSLService
> 
> There's a wrapper around OpenSSL as well:
> 
> https://github.com/IBM-Swift/OpenSSL.git 
> 
> Alex
> 
>> On 26 Jan 2017, at 09:49, Rien via swift-users <swift-users@swift.org> wrote:
>> 
>> I have created the following packages:
>> 
>> 1) SwifterSockets (Swift)
>> 2) COpenSsl (wrapper for system libraries)
>> 3) SecureSockets (Swift, uses SwifterSockets and COpenSsl)
>> 
>> Now I want to build a macOS app that uses SecureSockets.
>> 
>> I have created the app in the traditional way, via Xcode.
>> In this app I imported the frameworks created by SwifterSockets and 
>> SecureSockets.
>> 
>> When I try to use SecureSockets I get the error “No such module COpenSsl”
>> 
>> Any idea how I can include the system library wrapper ?
>> 
>> Regards,
>> Rien
>> 
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Balancingrock
>> Project: http://swiftfire.nl
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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] Casting function pointers

2017-01-25 Thread Rien via swift-users
Thank Joe,

A first attempt was not successful, I will try again in a few days.

For now I have put in a work around where I put glue-code into the openSSL 
library itself. I don’t like that solution, but it works.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 25 Jan 2017, at 19:37, Joe Groff <jgr...@apple.com> wrote:
> 
> 
>> On Jan 25, 2017, at 1:23 AM, Rien via swift-users <swift-users@swift.org> 
>> wrote:
>> 
>> I have a case where a callback has the following signature:
>> 
>> @convention(c) (_ ssl: OpaquePointer?, _ num: UnsafeMutablePointer?, 
>> _ arg: UnsafeMutableRawPointer?) -> Int32
>> 
>> But to install this callback I have to use a c-function with this signature:
>> 
>> SSL_CTX_callback_ctrl (OpaquePointer!, Int32, (() -> Void)! )
>> 
>> Is it possible to cast the first function to the second? If so, how?
> 
> I think your best bet would be to write the shim closure yourself. Is `num` a 
> pointer to the value you're supposed to receive from SSL_CTX_callback_ctrl? 
> Is the `arg` really a function pointer? In that case, something like this 
> might work:
> 
> func callback(_ ssl: OpaquePointer?, _ num: UnsafeMutablePointer?, _ 
> arg: UnsafeMutableRawPointer?) -> Int32
> 
> let shimCallback: SSL_CTX_callback_ctrl = { ctx, cmd, fp in
>  var cmdNum = cmd
>  callback(ctx, , unsafeBitCast(fp, to: UnsafeMutableRawPointer?.self))
> }
> 
> -Joe

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


Re: [swift-users] Callback in Swift

2017-01-25 Thread Rien via swift-users


> On 25 Jan 2017, at 10:33, John Brownie  wrote:
> 
> Thanks, that does it for me, though I had to qualify the Unmanaged with a 
> type in the first part.
> 
> Rien wrote:
>> For the context I passed in:
>> 
>> UnsafeMutableRawPointer(Unmanaged.passUnretained(self).toOpaque())
>> 
>> And to get the context back inside the callback:
>> 
>> let ourself = Unmanaged<  … your type 
>> here…>.fromOpaque(arg!).takeUnretainedValue()
>> 
>> Then “ourself” was the object normally obtained as “self”.
>> 
> A more general question is how to learn these tricks. The worst pain I've had 
> in learning Swift is how to handle interactions with frameworks in other 
> languages, such as this one (Cocoa) or the Expat parser (C). The Swift book 
> doesn't even mention Unmanaged or opaque. The book on using Swift with 
> Objective-C mentions Unmanaged, but not opaque (apart from a couple of 
> references, neither of which mentions toOpaque/fromOpaque. If there were a 
> reference that gathered these things together in one place, it would be 
> easier to learn than simply thrashing around for a while and asking for help.

I usually start off with using the debugger. And I like to print out pointer 
values a lot. Shows you how swift handles them.
After that I usually know what to look for and am able to target my googling.
Subscribing to lists (and scanning posts) like these (and evolution) also makes 
you more aware of what is going on. In isolation it is difficult to get a good 
feel for a language.

Rien

> -- 
> John Brownie
> In Finland on furlough from SIL Papua New Guinea

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


Re: [swift-users] Casting function pointers

2017-01-25 Thread Rien via swift-users
I should clarify: is it possible to cast:

> @convention(c) (_ ssl: OpaquePointer?, _ num: UnsafeMutablePointer?, _ 
> arg: UnsafeMutableRawPointer?) -> Int32

to:

> (() -> Void)!


???

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 25 Jan 2017, at 10:23, Rien via swift-users <swift-users@swift.org> wrote:
> 
> I have a case where a callback has the following signature:
> 
> @convention(c) (_ ssl: OpaquePointer?, _ num: UnsafeMutablePointer?, _ 
> arg: UnsafeMutableRawPointer?) -> Int32
> 
> But to install this callback I have to use a c-function with this signature:
> 
> SSL_CTX_callback_ctrl (OpaquePointer!, Int32, (() -> Void)! )
> 
> Is it possible to cast the first function to the second? If so, how?
> 
> 
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl
> 
> 
> 
> 
> 
> ___
> 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] Casting function pointers

2017-01-25 Thread Rien via swift-users
I have a case where a callback has the following signature:

@convention(c) (_ ssl: OpaquePointer?, _ num: UnsafeMutablePointer?, _ 
arg: UnsafeMutableRawPointer?) -> Int32

But to install this callback I have to use a c-function with this signature:

SSL_CTX_callback_ctrl (OpaquePointer!, Int32, (() -> Void)! )

Is it possible to cast the first function to the second? If so, how?



Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





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


[swift-users] SPM: Specify search paths?

2017-01-24 Thread Rien via swift-users
I am still running into walls with SPM.

Is there a way to specify the header and library search paths when using the 
Swift Package Manager?

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





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


Re: [swift-users] SPM & Library with bridging header

2017-01-21 Thread Rien via swift-users
==
This works:
==

First I need openSSL from Swift, that I have done with COpenSsl:

Package.swift:

import PackageDescription

let package = Package(
name: "COpenSsl",
pkgConfig: "openssl"
)


module.modulemap:

module COpenSsl [system] {
  header "/usr/local/include/openssl/ssl.h"
  header "/usr/local/include/openssl/err.h"
  header "/usr/local/include/openssl/crypto.h"
  header "/usr/local/include/openssl/evp.h"
  header "/usr/local/include/openssl/x509v3.h"
  export *
}

And then import this into Swift with:

import COpenSsl


==
This does not work
==

Package.swift for the C-glue code:

import PackageDescription

let package = Package(
name: "OpenSsl",
dependencies: [
.Package(url: "https://github.com/Swiftrien/COpenSsl;, "0.1.0")
]
)



OpenSsl.h:
(In Sources/include)

// #import "openssl/ssl.h"
// #import "openssl/x509.h"
// #import "openssl/x509v3.h"

@import COpenSsl;

void sslCtxSetTlsExtServernameCallback(SSL_CTX *ctx, int (*cb)(SSL *, int *, 
void *), void *arg);

void skGeneralNamePopFree(STACK_OF(GENERAL_NAME) *san_names);



OpenSsl.c:
(In Sources)

#include "OpenSsl.h"

void sslCtxSetTlsExtServernameCallback(SSL_CTX *ctx, int (*cb)(SSL *, int *, 
void *), void *arg) {
SSL_CTX_set_tlsext_servername_arg(ctx, arg);
SSL_CTX_set_tlsext_servername_callback(ctx, cb);
}

void skGeneralNamePopFree(STACK_OF(GENERAL_NAME) *san_names) {
sk_GENERAL_NAME_pop_free(san_names, GENERAL_NAME_free);
}


The @import COpenSsl; statement does not work. Nor do the normal includes.
Hence the compilation fails.

Maybe the import statement is wrong? is there another way to do this?

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 22 Jan 2017, at 06:25, Daniel Dunbar <daniel_dun...@apple.com> wrote:
> 
> What is the glue code you need?
> 
> You can define a C/Obj-C target in the same Swift package, and then use it 
> from your Swift targets. See:
>   
> https://github.com/apple/swift-package-manager/blob/master/Documentation/Reference.md#source-layouts
> for more information.
> 
>  - Daniel
> 
>> On Jan 21, 2017, at 2:24 AM, Rien via swift-users <swift-users@swift.org> 
>> wrote:
>> 
>> The thing I was missing is the “system module”.. found it now though ;-)
>> 
>> So far so good, I want to put that little glue code I need in its own 
>> module. However I cannot find how to specify the import search path.
>> 
>> “swift build -I /usr/local/include/“ does not work (unknown command -I)
>> 
>> And pkgConfig cannot be used on a non-system module.
>> 
>> But without specifying the import search path, SPM cannot compile the c-code.
>> 
>> Any suggestions?
>> 
>> Regards,
>> Rien
>> 
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Swiftrien
>> Project: http://swiftfire.nl
>> 
>> 
>> 
>> 
>>> On 20 Jan 2017, at 19:48, Rien via swift-users <swift-users@swift.org> 
>>> wrote:
>>> 
>>> I may be missing something here, so please bear with me...
>>> 
>>> The client of the lib only has to see the headers that describe the lib, 
>>> not the headers of the files that were used to create the lib.
>>> Or are you referring to a case were the lib also exposes the headers of the 
>>> libs that were used to create the lib?
>>> 
>>> Additional info:
>>> In my particular case I use openSSL and have created a few Swift operations 
>>> that use (wrap) openSSL. My lib does not expose openSSL to the client of 
>>> the lib.
>>> I did have to create a 2 line c-function for a callback. That function is 
>>> not exposed to the lib client. But this two line function is the reason for 
>>> the “mixed language” target.
>>> Ideally no client should use openSSL directly, but it cannot be prevent of 
>>> course that a client links its own files to openSSL using his own bridging 
>>> file.
>>> 
>>> Regards,
>>> Rien
>>> 
>>> Site: http://balancingrock.nl
>>> Blog: http://swiftrien.blogspot.com
>>> Github: http://github.com/Swiftrien
>>> Project: http://swiftfire.nl
>>> 
>>> 
>>> 
>>> 
>>>> On 20 Jan 2017, at 18:39, Jordan Rose <j

Re: [swift-users] enum compare

2017-01-21 Thread Rien via swift-users
Oh, I am not using the correct terminology, sorry. Enum’s don’t have 
“instances” right?
Anyhow, I guess you get my drift…

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 21 Jan 2017, at 14:23, Rien  wrote:
> 
> The “==“ operation can only compare concrete instances of the enum.
> With “type == ACType.other” the right side is not an instance. as the 
> associated value is missing.
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Swiftrien
> Project: http://swiftfire.nl
> 
> 
> 
> 
>> On 21 Jan 2017, at 13:56, tridiak via swift-users  
>> wrote:
>> 
>> Been searching and trying to figure out a comparison problem.
>> 
>> func ==(lhs : ACType, rhs : ACType) -> Bool {
>>  switch (lhs,rhs) {
>>  case (.other, .other):
>>  return true
>>  case (.other, _):
>>  return false
>>  case (_, .other):
>>  return false
>>  default:
>>  return lhs == rhs
>>  }
>>  }
>> 
>> enum ACType {
>>  case noType
>>  case natural
>>  case armour
>>  case shield
>>  case deflection
>>  case dodge
>>  case sacred
>>  case luck
>>  case other(String)
>> 
>>  static func Stacks(type : ACType) -> Bool {
>>  return type == ACType.noType || type == ACType.dodge || type == 
>> ACType.other
>>  }
>> }
>> 
>> I get an error concerning ‘type == ACType.other’.
>> Compiler blab: Binary operator '==' cannot be applied to operands of type 
>> 'ACType' and '(String) -> ACType'
>> 
>> How do I fix this? Simply cannot see it.
>> 
>> TIA Mark
>> ___
>> 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] enum compare

2017-01-21 Thread Rien via swift-users
The “==“ operation can only compare concrete instances of the enum.
With “type == ACType.other” the right side is not an instance. as the 
associated value is missing.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 21 Jan 2017, at 13:56, tridiak via swift-users  
> wrote:
> 
> Been searching and trying to figure out a comparison problem.
> 
> func ==(lhs : ACType, rhs : ACType) -> Bool {
>   switch (lhs,rhs) {
>   case (.other, .other):
>   return true
>   case (.other, _):
>   return false
>   case (_, .other):
>   return false
>   default:
>   return lhs == rhs
>   }
>   }
> 
> enum ACType {
>   case noType
>   case natural
>   case armour
>   case shield
>   case deflection
>   case dodge
>   case sacred
>   case luck
>   case other(String)
> 
>   static func Stacks(type : ACType) -> Bool {
>   return type == ACType.noType || type == ACType.dodge || type == 
> ACType.other
>   }
> }
> 
> I get an error concerning ‘type == ACType.other’.
> Compiler blab: Binary operator '==' cannot be applied to operands of type 
> 'ACType' and '(String) -> ACType'
> 
> How do I fix this? Simply cannot see it.
> 
> TIA Mark
> ___
> 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] SPM & Library with bridging header

2017-01-21 Thread Rien via swift-users
The thing I was missing is the “system module”.. found it now though ;-)

So far so good, I want to put that little glue code I need in its own module. 
However I cannot find how to specify the import search path.

“swift build -I /usr/local/include/“ does not work (unknown command -I)

And pkgConfig cannot be used on a non-system module.

But without specifying the import search path, SPM cannot compile the c-code.

Any suggestions?

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 20 Jan 2017, at 19:48, Rien via swift-users <swift-users@swift.org> wrote:
> 
> I may be missing something here, so please bear with me...
> 
> The client of the lib only has to see the headers that describe the lib, not 
> the headers of the files that were used to create the lib.
> Or are you referring to a case were the lib also exposes the headers of the 
> libs that were used to create the lib?
> 
> Additional info:
> In my particular case I use openSSL and have created a few Swift operations 
> that use (wrap) openSSL. My lib does not expose openSSL to the client of the 
> lib.
> I did have to create a 2 line c-function for a callback. That function is not 
> exposed to the lib client. But this two line function is the reason for the 
> “mixed language” target.
> Ideally no client should use openSSL directly, but it cannot be prevent of 
> course that a client links its own files to openSSL using his own bridging 
> file.
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Swiftrien
> Project: http://swiftfire.nl
> 
> 
> 
> 
>> On 20 Jan 2017, at 18:39, Jordan Rose <jordan_r...@apple.com> wrote:
>> 
>> Hi, Rien. Libraries don’t support bridging headers because the client of the 
>> library has to be able to import the header, and arbitrary bridging headers 
>> may conflict. (This is actually the primary purpose of modules for 
>> Objective-C: to declare a group of headers that are self-contained—besides 
>> what other modules they import—and can therefore be imported earlier or 
>> later without difficulty.) The compiler will mildly try to stop you from 
>> doing this if it can figure out you’re building a library, but it’s a bad 
>> idea no matter what. Even if everything appears to compile fine, it’s likely 
>> you’ll get inscrutable errors when trying te debug anything that uses your 
>> library.
>> 
>> The particular difference between Xcode-created frameworks and 
>> SwiftPM-generated libraries is that Xcode frameworks are set up to be 
>> mixed-source, using the Objective-C public umbrella header in place of a 
>> bridging header. SwiftPM doesn’t support mixed-source targets. (Since I 
>> don’t work on SwiftPM myself I don’t know if there are any public plans to 
>> do so.)
>> 
>> The recommended solution is to group your Objective-C headers into modules 
>> (usually just frameworks) and import them that way, rather than to jam them 
>> in via a bridging header.
>> 
>> Sorry for the trouble,
>> Jordan
>> 
>> 
>>> On Jan 20, 2017, at 08:49, Rien via swift-users <swift-users@swift.org> 
>>> wrote:
>>> 
>>> I noticed something strange about Xcode and SPM concerning the capability 
>>> to generate Libraries.
>>> 
>>> When I try to create a Library in Xcode and then want to add an Objective-C 
>>> bridging header, that is denied. It claims that bridging is not supported 
>>> for Libraries.
>>> 
>>> When I create an Xcode project through the SPM (with “swift package 
>>> generate-xcodeproj”) then I can use bridging headers, even though the end 
>>> result is a library.
>>> 
>>> Question: Is this a viable work around? or are there hidden dangers that 
>>> might not be immediately apparent?
>>> 
>>> As a side note: SPM complains about multiple languages and currently only 
>>> supports pure Swift modules.
>>> This creates the strange situation that I now use SPM to create an xcode 
>>> project and then use Xcode to create bridged mixed language libraries.
>>> 
>>> Regards,
>>> Rien
>>> 
>>> Site: http://balancingrock.nl
>>> Blog: http://swiftrien.blogspot.com
>>> Github: http://github.com/Swiftrien
>>> Project: http://swiftfire.nl
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> 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] Migrating to SPM, best practise?

2017-01-18 Thread Rien via swift-users
I have a small sockets based framework on Github (SwifterSockets).
It was created before SPM existed.
The next update is planned, and I want to move to SPM.

1) How to create a package around the old xcode project?
2) I am unsure how to move from the old git structure to the new.

What would be the best/easiest way to achieve this?

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




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


Re: [swift-users] C-function not found by linker

2017-01-11 Thread Rien via swift-users
Sometimes you just have to post a stupid question to see what you did wrong :-(

So please disregard….


PS: it was of course the “static” (I have no clue why I did put that in there… 
oh well)

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 11 Jan 2017, at 10:28, Rien via swift-users <swift-users@swift.org> wrote:
> 
> My project uses openSSL and that works fine.
> 
> I needed one specific function that cannot be accessed from Swift directly, 
> so I created a C-file for that. (both .h and .c file)
> 
> The function is found during compilation.
> 
> But is then reported as “unused” and the linker reports “missing function”.
> 
> Any idea’s how this can be caused?
> 
> More info:
> 
> The .h file:
> 
> static void sslCtxSetTlsExtServernameCallback(SSL_CTX *ctx, int (*cb)(SSL *, 
> int *, void *), void *arg);
> 
> The .c file:
> 
> static void sslCtxSetTlsExtServernameCallback(SSL_CTX *ctx, int (*cb)(SSL *, 
> int *, void *), void *arg) {
>SSL_CTX_set_tlsext_servername_arg(ctx, arg);
>SSL_CTX_set_tlsext_servername_callback(ctx, cb);
> }
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Swiftrien
> Project: http://swiftfire.nl
> 
> 
> 
> 
> ___
> 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] Exclamation mark's in swift parameter listings?

2017-01-10 Thread Rien via swift-users
I stand corrected.

I do/did think that there is a difference in the way it handles pointers 
optionals and other optionals, but I now realise that even that could not be 
the case.
So please ignore the last line in my previous post.

The rest still stand ;-)

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 10 Jan 2017, at 18:14, Joe Groff <jgr...@apple.com> wrote:
> 
> 
>> On Jan 9, 2017, at 11:19 PM, Rien via swift-users <swift-users@swift.org> 
>> wrote:
>> 
>> It means that a call to that function with an optional will unwrap the 
>> optional before it is used.
>> 
>> That is quite neat when dealing with C-API’s because often you will receive 
>> a pointer from a C-function which is optional to account for the fact that 
>> it can be NULL (= nil).
>> By using a forced unwrapped input parameter you are saved the trouble of 
>> unwrapping all these pointers when using them as input for other C-APIs.
>> 
>> In short, it makes it easier to interface with C-API’s.
>> 
>> Note that there is some under-the-hood magic going on because a C-pointer is 
>> an unboxed value, while a ‘normal’ optional is a boxed value.
> 
> Optionals are never boxed.
> 
> -Joe

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


Re: [swift-users] getResourceValue

2017-01-06 Thread Rien via swift-users
Thanks Rod, very enlightening!

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 06 Jan 2017, at 15:19, Rod Brown  wrote:
> 
> 
>> On 7 Jan 2017, at 12:50 am, Rien  wrote:
>> 
>> Hmm, that is interesting to know. I had not realised that URL is in fact NOT 
>> a NSURL but a new type that is based on NSURL (and can be toll-free bridged 
>> I assume?).
> 
> URL a new Type, which internally wraps a NSURL reference. It is practically 
> toll free bridged, as URL is simply a struct wrapper placed around the 
> internal reference.
> 
> NSURL is a class and has reference semantics. That is, if you change the URL, 
> it would change all URLs with the same reference. This is why NSURL doesn’t 
> allow mutation. If you look at the NSURL API, it has a lot of methods like 
> “URLByAppendingPathComponent” which import into Swift 3 as 
> “appendingPathComponent()”. These return *copies* of the NSURL reference, 
> with the applied mutation.
> 
> URL is a struct and has value semantics. That is, if you change the URL, it 
> only changes the struct at this place and has no wider effects. Thus, there 
> are new mutating methods on this struct, love “appendPathExtension()” and 
> “appendPathComponent()” that allow mutation, because it only affects this 
> local copy. These methods internally actually use the 
> appendingPathComponent() method to get a replacement NSURL instance internal 
> of the struct.
> 
> The URL struct mutating behaviour makes URL manipulation much more convenient 
> in Swift 3.
> 
>> I also presume that the same is true for Data/NSData, Date/NSDate etc?
> 
> Correct. Except Date/NSDate is actually a slight edge case.
> 
> Instead of Date simply wrapping an NSDate, it actually only wraps the 
> NSDate’s timeIntervalSinceReferenceDate. This is because there’s no point 
> wrapping the internal reference to the NSDate, it’s more performant simply to 
> wrap the NSTimeInterval (a Double) and get true struct properties. You should 
> note that this means when you cast from Date to NSDate, you need to create a 
> new reference each time.
> 
> This becomes a bigger issue for IndexPath/NSIndexPath which also does this. 
> Casting between NSIndexPath and IndexPath can be somewhat less performant, as 
> it can hold an arbitrarily large number of integers. It’s also interesting to 
> note that NSIndexPath has an optimisations that could make it perform better 
> than IndexPath: NSIndexPath uses tagged pointers for row/item and section 
> conveniences on iOS, and IndexPath does not. This should really not concern 
> you generally, but you should avoid casting backwards and forwards between 
> the Struct and Reference types a lot as this could cause unnecessary 
> performance problems.
> 
> If you want to see the struct overlay for Foundation for yourself, take a 
> look here:
> https://github.com/apple/swift/tree/master/stdlib/public/SDK/Foundation
> 
>> 
>> (Failure on my part, as I did of course know that the .path method/var is in 
>> fact different on URL and NSURL)
>> 
>> Regards,
>> Rien
>> 
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Swiftrien
>> Project: http://swiftfire.nl
>> 
>> 
>> 
>> 
>>> On 06 Jan 2017, at 14:39, Rod Brown via swift-users  
>>> wrote:
>>> 
>>> Hi Jan,
>>> 
>>> The Swift 3 URL struct has a modernized version of the NSURL API which 
>>> works far better in Swift. This replaces “getResourceValue(…)” with the API 
>>> you mentioned: “resourceValues(forKeys:)”.
>>> 
>>> 
>>> Previously, in Swift 2, you had to use an separate value, use 
>>> AutoreleasingUnsafeMutablePointers, conditionally cast and then hope you 
>>> got the value, and that you used the correct typecast for the key you were 
>>> asking for:
>>> 
>>> let url = NSURL(fileURLWithPath: "/Users/me/Desktop/File.png")
>>> 
>>> var fileType: AnyObject? = nil
>>> do {
>>>try url.getResourceValue(, forKey: NSURLTypeIdentifierKey)
>>> 
>>>if let type = fileType as? String {
>>>// Use the file type here
>>>} else {
>>>// Handle error
>>>}
>>> } catch {
>>>// Handle error
>>> }
>>> 
>>> 
>>> In Swift 3 with the new Swift URL, the resourceValues(forKeys:) creates a 
>>> struct with optional type safe properties representing each resource key 
>>> type, and returns it, allowing you to use if let syntax:
>>> 
>>> let url = URL(fileURLWithPath: "/Users/me/Desktop/File.png")
>>> if let resourceValues = try? url.resourceValues(forKeys: 
>>> [.typeIdentifierKey]),
>>>   let fileType = resourceValues.typeIdentifier {
>>>   // Use the file type here
>>> }
>>> 
>>> 
>>> This is a much cleaner, clearer, and type-safe API.
>>> 
>>> If you want to use the old API, you can simply cast back to NSURL if you 
>>> require the old behaviour. That said, the new one should serve all 

Re: [swift-users] getResourceValue

2017-01-06 Thread Rien via swift-users
Hmm, that is interesting to know. I had not realised that URL is in fact NOT a 
NSURL but a new type that is based on NSURL (and can be toll-free bridged I 
assume?).
I also presume that the same is true for Data/NSData, Date/NSDate etc?

(Failure on my part, as I did of course know that the .path method/var is in 
fact different on URL and NSURL)

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 06 Jan 2017, at 14:39, Rod Brown via swift-users  
> wrote:
> 
> Hi Jan,
> 
> The Swift 3 URL struct has a modernized version of the NSURL API which works 
> far better in Swift. This replaces “getResourceValue(…)” with the API you 
> mentioned: “resourceValues(forKeys:)”.
> 
> 
> Previously, in Swift 2, you had to use an separate value, use 
> AutoreleasingUnsafeMutablePointers, conditionally cast and then hope you got 
> the value, and that you used the correct typecast for the key you were asking 
> for:
> 
> let url = NSURL(fileURLWithPath: "/Users/me/Desktop/File.png")
> 
> var fileType: AnyObject? = nil
> do {
> try url.getResourceValue(, forKey: NSURLTypeIdentifierKey)
> 
> if let type = fileType as? String {
> // Use the file type here
> } else {
> // Handle error
> }
> } catch {
> // Handle error
> }
> 
> 
> In Swift 3 with the new Swift URL, the resourceValues(forKeys:) creates a 
> struct with optional type safe properties representing each resource key 
> type, and returns it, allowing you to use if let syntax:
> 
> let url = URL(fileURLWithPath: "/Users/me/Desktop/File.png")
> if let resourceValues = try? url.resourceValues(forKeys: 
> [.typeIdentifierKey]),
>let fileType = resourceValues.typeIdentifier {
>// Use the file type here
> }
> 
> 
> This is a much cleaner, clearer, and type-safe API.
> 
> If you want to use the old API, you can simply cast back to NSURL if you 
> require the old behaviour. That said, the new one should serve all your needs 
> and make things so much easier so I recommend you give it a go.
> 
> Hope this helps,
> 
> Rod
> 
> 
> 
> 
>> On 6 Jan 2017, at 6:36 am, J.E. Schotsman via swift-users 
>>  wrote:
>> 
>> Hello,
>> 
>> Is getResourceValue a method or URL or only on NSURL?
>> After migrating a project to Swift 3 I have code like
>> 
>> var file:URL
>> file.getResourceValue(...) // compiles!
>> 
>> From the documentation and the headers I get the impression that this should 
>> not compile!
>> 
>> TIA,
>> 
>> Jan E.
>> ___
>> 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] getResourceValue

2017-01-06 Thread Rien via swift-users
URL is the same as NSURL in Swift 3

Foundation -> NSURL -> getResourceValue.

If you use xcode, open up the Help -> Documentation and API reference
The do a search for getResourceValue.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 06 Jan 2017, at 10:01, J.E. Schotsman via swift-users 
>  wrote:
> 
> 
>> On 06 Jan 2017, at 08:25, Rien  wrote:
>> 
>> What is your real question?
>> Obviously the doc says that this is fine, so what are you asking? what is 
>> your problem?
> 
> Which doc?
> My doc is the Xcode 8.2.1 documentation for URL, which only has the methods
> 
> resourceValues(forKeys: Set)
> 
> and
> 
> setResourceValues(URLResourceValues)
> 
>>> On 05 Jan 2017, at 20:36, J.E. Schotsman via swift-users 
>>>  wrote:
>>> 
>>> Hello,
>>> 
>>> Is getResourceValue a method or URL or only on NSURL?
>>> After migrating a project to Swift 3 I have code like
>>> 
>>> var file:URL
>>> file.getResourceValue(...) // compiles!
>>> 
>>> From the documentation and the headers I get the impression that this 
>>> should not compile!
> ___
> 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] getResourceValue

2017-01-05 Thread Rien via swift-users
What is your real question?
Obviously the doc says that this is fine, so what are you asking? what is your 
problem?

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 05 Jan 2017, at 20:36, J.E. Schotsman via swift-users 
>  wrote:
> 
> Hello,
> 
> Is getResourceValue a method or URL or only on NSURL?
> After migrating a project to Swift 3 I have code like
> 
> var file:URL
> file.getResourceValue(...) // compiles!
> 
> From the documentation and the headers I get the impression that this should 
> not compile!
> 
> TIA,
> 
> Jan E.
> ___
> 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] Compiler should issue a warning when a subclass implementation with default values matches a parent implementation without them

2017-01-04 Thread Rien via swift-users
As you know. there is no ambiguity, no warnings needed.
(The parameter is part of the identifier of the function)

Imo, this request falls into the category “do as I think, not as I say”.

That is a discussion without end. Personally I am against ANY warnings of this 
kind. The reason is that I want my code to compile warnings free (default 
compiler behaviour) and I do not want an extra pragma in the code to instruct 
the compiler that when I am calling “foo()” I do indeed want to call “foo()”.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 05 Jan 2017, at 03:29, Wagner Truppel via swift-users 
>  wrote:
> 
> Hello,
> 
> I wasn’t sure whether to post this message here, at swift-dev, or at 
> swift-evolution. so I’ll try here first. Hopefully it will get to the right 
> group of people or, if not, someone will point me to the right mailing list.
> 
> I came across a situation that boils down to this example:
> 
> class Parent {
>func foo() {
>print("Parent foo() called")
>}
> }
> 
> class Child: Parent {
>func foo(x: Int = 0) {
>print("Child foo() called")
>}
> }
> 
> let c = Child()
> c.foo()  // prints "Parent foo() called"
> 
> I understand why this behaves like so, namely, the subclass has a method 
> foo(x:) but no direct implementation of foo() so the parent’s implementation 
> is invoked rather than the child's. That’s all fine except that it is not 
> very intuitive.
> 
> I would argue that the expectation is that the search for an implementation 
> should start with the subclass (which is does) but should look at all 
> possible restrictions of parent implementations, including the restriction 
> due to default values.
> 
> At the very least, I think the compiler should emit a warning or possibly 
> even an error.
> 
> Thanks for reading.
> Cheers,
> 
> Wagner
> ___
> 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] UnsafePointer and C-String

2017-01-03 Thread Rien via swift-users
The documentation at 
https://developer.apple.com/library/content/documentation/Swift/Conceptual/BuildingCocoaApps/InteractingWithCAPIs.html
 shows that it is possible to use String where an UnsafePointer is needed.
API calls to C that need a char* are translated to UnsafePointer.
It follows that we can use a String where a char* is needed.

However in C a string is not only a char*, it is also null-terminated.

What I cannot find though is the guarantee that the buffer where the String is 
converted to an UTF8 sequence is always null-terminated.

I very much suspect it is, and all my tests did find a null-terminated string.

Question: Does anybody know for sure that the buffer is always null-terminated? 
(a link to where I can check this would be most appreciated)

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




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


Re: [swift-users] Weird protocol behaviour.

2016-12-30 Thread Rien via swift-users

> On 30 Dec 2016, at 12:14, Mikhail Seriukov via swift-users 
> <swift-users@swift.org> wrote:
> 
> Ok, 
> But I think I still do not get it.
> What does really happen when we write this?
>> let x = X() as P
>> 

'X()' creates a value.
'as P’ constrains the value such that the only things we know about it is that 
the value will conform to the protocol P
‘let x =‘ assigns the value to a constant, and the only thing we know about 
that constant is that we can call an operation of protocol P on it.

Rien.

> As I said, I expect x to be Any after that. If it is, then it should be ok 
> IMO.
> But if it is not then what is the actual type of x? 
> 
> So the real question is how the type checker works here?
> 
> 
> 2016-12-25 22:13 GMT+07:00 Slava Pestov <spes...@apple.com>:
> 
>> On Dec 22, 2016, at 4:43 PM, Howard Lovatt via swift-users 
>> <swift-users@swift.org> wrote:
>> 
>> The following variation works:
>> 
>> protocol P {}
>> 
>> class P1:P {}
>> 
>> class X:P1 {}
>> 
>> func foo(_ x:A) {}
>> 
>> func bar() {
>> //let x = X() // this compiles
>> let x = X() as P1 // this does not compile. Why?
>> foo(x)
>> }
>> 
>> Which adds credence to the bug theory.
> 
> It’s an intentional limitation. Protocols do not conform to themselves. 
> Lifting the restriction would be difficult to do efficiently given our 
> representation of generics and protocols at runtime.
> 
> Slava
> 
>> 
>> Note two changes: 1. two levels of inheritance and 2. change to classes. If 
>> you do two levels using protocols it doesn't work if you use either classes 
>> or structs.
>> 
>> 
>>   -- Howard.
>> 
>> On 23 December 2016 at 07:29, Kevin Nattinger <sw...@nattinger.net> wrote:
>> I recall seeing a request on the -evolution list for something like `T := X` 
>> to indicate it could be X itself or anything inheriting / implementing it, 
>> so it’s certainly known behavior, if not desired. IMO it’s a bug and `:` 
>> should be fixed to include the root type, whether or not that requires a 
>> discussion on -evolution.
>> 
>>> On Dec 22, 2016, at 2:17 PM, Howard Lovatt via swift-users 
>>> <swift-users@swift.org> wrote:
>>> 
>>> I suspect a compiler bug since A is a P. The equivalent in Java works:
>>> 
>>> interface P {}
>>> class X implements P {}
>>>  
>>>  void foo(A x) {}
>>>  
>>> void bar() {
>>> final P x = new X();
>>> foo(x);
>>> }
>>> 
>>> -- Howard. 
>>> 
>>> On 23 Dec 2016, at 3:19 am, Rien via swift-users <swift-users@swift.org> 
>>> wrote:
>>> 
>>>> IMO the error message says it all:
>>>> 
>>>> Playground execution failed: error: MyPlayground8.playground:9:5: error: 
>>>> cannot invoke 'foo' with an argument list of type '(P)'
>>>>foo(x)
>>>>^
>>>> 
>>>> MyPlayground8.playground:9:5: note: expected an argument list of type '(A)'
>>>>foo(x)
>>>>^
>>>> 
>>>> I.e. you are passing in a protocol while the function is specified for a 
>>>> type.
>>>> Said other way: On which data do you expect the protocol to operate?
>>>> 
>>>> Regards,
>>>> Rien
>>>> 
>>>> Site: http://balancingrock.nl
>>>> Blog: http://swiftrien.blogspot.com
>>>> Github: http://github.com/Swiftrien
>>>> Project: http://swiftfire.nl
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On 22 Dec 2016, at 17:05, Mikhail Seriukov via swift-users 
>>>>> <swift-users@swift.org> wrote:
>>>>> 
>>>>> Hello community! I' wondering if somebody can explain this to me.
>>>>> Please take look at the snippet.
>>>>> 
>>>>> protocol P {}
>>>>> struct X:P {}
>>>>> 
>>>>> func foo(_ x:A) {}
>>>>> 
>>>>> func bar() {
>>>>>//let x = X() // this compiles
>>>>>let x = X() as P // this does not compile. Why?
>>>>>foo(x)
>>>>> }
>>>>> 
>>>>> I expect the both cases to work though. But only first works? And I do 
>>>>> not understand why.
>>>>> My coworkers said that it is a compiler bug, but I'm not shure it is.
>>>>> Thanks for the help.
>>>>> ___
>>>>> 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
> 
> 
> ___
> 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] Using 'SomeProtocol' as a concrete type conforming to protocol 'SomeProtocol' is not supported

2016-12-29 Thread Rien via swift-users
As to the why question: (just guessing here)

By the time the compiler want to know what type will be in the array, it cannot 
do so. The enum is a generic and thus without full type information (it only 
has partial type information).

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 29 Dec 2016, at 00:41, Brandon Knope via swift-users 
>  wrote:
> 
> I don’t understand why this is a problem
> 
> protocol Element {
> 
> }
> 
> enum ElementNode {
> case element(T)
> case empty
> }
> 
> var childElements = [ElementNode]()
> 
> I need to represent an array of my nodes that could be multiple kinds of 
> elements
> 
> Is there a workaround?
> 
> Brandon
> ___
> 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] Weird protocol behaviour.

2016-12-23 Thread Rien via swift-users

> On 23 Dec 2016, at 09:43, Mikhail Seriukov <zloi...@gmail.com> wrote:
> 
> No it does not.
> You have made a type out of the parameter. It’s no longer a protocol.
> IMO the failure here is to understand the difference between a type and a 
> protocol.
> A type (even if empty) is always a combination of storage with functions 
> (that are assumed to work on the data in storage)
> A protocol is just a definition of functions without the accompanying data.
> 
> I see your point. 
> But actually when I write it as  `let x = X() as P` I really mean that I want 
> `x` to be `AnyObject` but conforming to P, not just protocol itself.
> Is it even possible to downcast it this way?

Yes, but only for a destination that needs a protocol. Not for a destination 
that needs a type.

I.e. in the example

protocol P {}
struct X:P {}

func foo(_ x:A) {}

func bar(_ x:P) {}

func bar() {
var p: P
//let x = X() // this compiles
let x = X() as P // this does not compile. Why?
p = x
bar(p)
}

Regards,
Rien.

> 
> 2016-12-23 14:51 GMT+07:00 Marinus van der Lugt <r...@starbase55.com>:
> 
>> On 22 Dec 2016, at 22:43, Howard Lovatt <howard.lov...@gmail.com> wrote:
>> 
>> The following variation works:
>> 
>> protocol P {}
>> 
>> class P1:P {}
>> 
>> class X:P1 {}
>> 
>> func foo(_ x:A) {}
>> 
>> func bar() {
>> //let x = X() // this compiles
>> let x = X() as P1 // this does not compile. Why?
>> foo(x)
>> }
>> 
>> Which adds credence to the bug theory.
> 
> 
> No it does not.
> You have made a type out of the parameter. It’s no longer a protocol.
> IMO the failure here is to understand the difference between a type and a 
> protocol.
> A type (even if empty) is always a combination of storage with functions 
> (that are assumed to work on the data in storage)
> A protocol is just a definition of functions without the accompanying data.
> 
> Rien.
> 
> 
> 
>> 
>> Note two changes: 1. two levels of inheritance and 2. change to classes. If 
>> you do two levels using protocols it doesn't work if you use either classes 
>> or structs.
>> 
>> 
>>   -- Howard.
>> 
>> On 23 December 2016 at 07:29, Kevin Nattinger <sw...@nattinger.net> wrote:
>> I recall seeing a request on the -evolution list for something like `T := X` 
>> to indicate it could be X itself or anything inheriting / implementing it, 
>> so it’s certainly known behavior, if not desired. IMO it’s a bug and `:` 
>> should be fixed to include the root type, whether or not that requires a 
>> discussion on -evolution.
>> 
>>> On Dec 22, 2016, at 2:17 PM, Howard Lovatt via swift-users 
>>> <swift-users@swift.org> wrote:
>>> 
>>> I suspect a compiler bug since A is a P. The equivalent in Java works:
>>> 
>>> interface P {}
>>> class X implements P {}
>>>  
>>>  void foo(A x) {}
>>>  
>>> void bar() {
>>> final P x = new X();
>>> foo(x);
>>> }
>>> 
>>> -- Howard. 
>>> 
>>> On 23 Dec 2016, at 3:19 am, Rien via swift-users <swift-users@swift.org> 
>>> wrote:
>>> 
>>>> IMO the error message says it all:
>>>> 
>>>> Playground execution failed: error: MyPlayground8.playground:9:5: error: 
>>>> cannot invoke 'foo' with an argument list of type '(P)'
>>>>foo(x)
>>>>^
>>>> 
>>>> MyPlayground8.playground:9:5: note: expected an argument list of type '(A)'
>>>>foo(x)
>>>>^
>>>> 
>>>> I.e. you are passing in a protocol while the function is specified for a 
>>>> type.
>>>> Said other way: On which data do you expect the protocol to operate?
>>>> 
>>>> Regards,
>>>> Rien
>>>> 
>>>> Site: http://balancingrock.nl
>>>> Blog: http://swiftrien.blogspot.com
>>>> Github: http://github.com/Swiftrien
>>>> Project: http://swiftfire.nl
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On 22 Dec 2016, at 17:05, Mikhail Seriukov via swift-users 
>>>>> <swift-users@swift.org> wrote:
>>>>> 
>>>>> Hello community! I' wondering if somebody can explain this to me.
>>>>> Please take look at the snippet.
>>>>> 
>>>>> protocol P {}
>>>>> struct X:P {}
>>>>> 
>>>>> func foo(_ x:A) {}
>>>>> 
&

Re: [swift-users] Implicitly capture a mutating self

2016-12-16 Thread Rien via swift-users
Just because it is called “Unsafe” does not mean it is unsafe :-)
It all depends on how you use it.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 16 Dec 2016, at 09:52, Richard Wei <rxr...@gmail.com> wrote:
> 
> Zhao, it’s not a class.
> 
> Rien, unsafe pointers is the last thing I would ever want to introduce in my 
> library…
> 
> Capturing self was clean, working perfectly, until Swift 3.0.2.
> 
> -Richard
> 
>> On Dec 16, 2016, at 02:49, Zhao Xin <owe...@gmail.com> wrote:
>> 
>> What is the type of self? If it is a class, try [unowned self].
>> 
>> Zhaoxin
>> 
>> 
>> 
>> 
>> 
>> 
>> On Fri, Dec 16, 2016 at 4:33 PM, Rien via swift-users 
>> <swift-users@swift.org> wrote:
>> How about using:
>> 
>> UnsafeMutablePointer
>> 
>> ?
>> 
>> Regards,
>> Rien
>> 
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Swiftrien
>> Project: http://swiftfire.nl
>> 
>> 
>> 
>> 
>> > On 16 Dec 2016, at 09:10, Richard Wei via swift-users 
>> > <swift-users@swift.org> wrote:
>> >
>> > Capturing makes it immutable, which unfortunately can't solve this problem.
>> >
>> > -Richard
>> >
>> >> On Dec 16, 2016, at 02:05, Zhao Xin <owe...@gmail.com> wrote:
>> >>
>> >> I did not test the code. But if you cannot implicitly capture a mutating 
>> >> self, you should do it explicitly, right?
>> >>
>> >> let blockSize = min(512, count)
>> >> let blockCount = (count+blockSize-1)/blockSize
>> >> device.sync { [self] () -> () in // Launch CUDA kernel
>> >> try! fill<<<(blockSize, blockCount)>>>[
>> >> .pointer(to: ), .value(value), .value(Int64(count))
>> >> ]
>> >> }
>> >>
>> >> Hope above code works.
>> >>
>> >> Zhaoxin
>> >>
>> >> On Fri, Dec 16, 2016 at 3:46 PM, Richard Wei via swift-users 
>> >> <swift-users@swift.org> wrote:
>> >> Hi,
>> >>
>> >> Swift 3.0.2 seems to have broken my code due to mutating self capture. 
>> >> But I have to pass inout self to the closure. Any workaround?
>> >>
>> >> let blockSize = min(512, count)
>> >> let blockCount = (count+blockSize-1)/blockSize
>> >> device.sync { // Launch CUDA kernel
>> >> try! fill<<<(blockSize, blockCount)>>>[
>> >> .pointer(to: ), .value(value), .value(Int64(count))
>> >> ]
>> >> }
>> >>
>> >> 
>> >>
>> >> -Richard
>> >>
>> >> ___
>> >> 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] Implicitly capture a mutating self

2016-12-16 Thread Rien via swift-users
How about using:

UnsafeMutablePointer

?

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 16 Dec 2016, at 09:10, Richard Wei via swift-users  
> wrote:
> 
> Capturing makes it immutable, which unfortunately can't solve this problem.
> 
> -Richard
> 
>> On Dec 16, 2016, at 02:05, Zhao Xin  wrote:
>> 
>> I did not test the code. But if you cannot implicitly capture a mutating 
>> self, you should do it explicitly, right?
>> 
>> let blockSize = min(512, count)
>> let blockCount = (count+blockSize-1)/blockSize
>> device.sync { [self] () -> () in // Launch CUDA kernel
>> try! fill<<<(blockSize, blockCount)>>>[
>> .pointer(to: ), .value(value), .value(Int64(count))
>> ]
>> }
>> 
>> Hope above code works.
>> 
>> Zhaoxin
>> 
>> On Fri, Dec 16, 2016 at 3:46 PM, Richard Wei via swift-users 
>>  wrote:
>> Hi,
>> 
>> Swift 3.0.2 seems to have broken my code due to mutating self capture. But I 
>> have to pass inout self to the closure. Any workaround?
>> 
>> let blockSize = min(512, count)
>> let blockCount = (count+blockSize-1)/blockSize
>> device.sync { // Launch CUDA kernel
>> try! fill<<<(blockSize, blockCount)>>>[
>> .pointer(to: ), .value(value), .value(Int64(count))
>> ]
>> }
>> 
>> 
>> 
>> -Richard
>> 
>> ___
>> 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] Overload Resolution of Binary Operators

2016-11-14 Thread Rien via swift-users
I seem to remember that while it is possible to define, the compiler will yield 
an error if you try to use the functions (“cannot resolve”).

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 14 Nov 2016, at 23:05, Toni Suter via swift-users  
> wrote:
> 
> Hi,
> 
> I would have expected that the following code reports an error, because
> of ambiguous function overloads:
> 
> infix operator ***: MultiplicationPrecedence
> infix operator +++: AdditionPrecedence
> 
> func ***(x: Int, y: Int) -> String {
>   print("f1")
>   return ""
> }
> 
> func ***(x: Int, y: Int) -> Int {
>   print("f2")
>   return 0
> }
> 
> func +++(x: String, y: Int) -> Int {
>   print("f3")
>   return 0
> }
> 
> func +++(x: Int, y: Int) -> Int {
>   print("f4")
>   return 0
> }
> 
> let result = 0 *** 4 +++ 0// prints f2 and f4
> 
> 
> As far as I can tell, there are two possible overload resolutions: f1 + f3 or 
> f2 + f4.
> I thought that these two solutions get an "equivalent score" and therefore 
> there would
> be a compile error. However, that's not the case. Instead, the type checker 
> picks
> f2 and f4.
> 
> So, I guess my question is, whether there is some rule, that prefers
> operators, which have the same argument types and the same return type
> or whether this is simply a bug.
> 
> Thanks and best regards,
> Toni
> ___
> 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] Details of defer statement in Swift

2016-11-09 Thread Rien via swift-users
The manual says this:

https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html

A defer statement is used for executing code just before transferring program 
control outside of the scope that the defer statement appears in.

The scope of a for loop ends when the loop ends.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 10 Nov 2016, at 08:32, Andrea VEH via swift-users  
> wrote:
> 
> Hello,
> From The Swift Programming Language, I learn the defer statements execute 
> in the reverse order that they appear in the program. And when there are two 
> or more defer statements in a loop(e.g. a for loop), defer statements execute 
> still in the reverse order that they appear, but in the loop order that the 
> loop statement executes. Code snippet is 
> here(https://swiftlang.ng.bluemix.net/#/repl/582421bfdee52b5745935771).
> Early I saw this 
> thread(https://twitter.com/lexrus/status/796370747849441280) from Twitter, I 
> am curious about defer statement's execute order. Can you tell more details 
> about it?
> 
> Best regards,
> ___
> 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] Understanding pass-by-value

2016-11-04 Thread Rien via swift-users

> On 04 Nov 2016, at 13:59, Ryan Lovelett via swift-users 
>  wrote:
> 
> struct Foo {
>  init(from buffer: Data) {
> bar = integer(withBytes: Array(buffer[4..<6]))
> baz = integer(withBytes: Array(buffer[6..<8]))
> ...
>  }
> 
> let d = Data(count: Int(3e+8))
> let f = Foo(from: d)
> 
> Did I just make two copies of the `Data`? How would I investigate this
> to understand it?

I often end up “printing” the addresses or using GDB to take an inside look.
However those snippets of inside information obtained that way are not 
necessary useful outside the specific problem that was studied.
As Brent already hinted: the compiler will generate different code in different 
situations. And for an outsider it is not always easy to understand why which 
code was generated.
The best approach imo is to “trust” the compiler and only start such 
investigations if you experience performance problems.

One thing that tripped me up: if you use inout variables, the observers will be 
triggered once the function completes. Even if the function never changed the 
data referred to. (This is now documented behaviour)


> 
> I _think_ that if I made it `inout` then it would not make a copy but
> now the data buffer is mutable. I want it to be clear I'm not mutating
> the buffer inside the initializer but I also want to be sure I'm not
> making a copy of the buffer either.
> 
> Help?
> 
> -- 
>  Ryan Lovelett
>  r...@lovelett.me
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




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


Re: [swift-users] What is "binding" memory?

2016-11-04 Thread Rien via swift-users

> On 03 Nov 2016, at 23:58, Manfred Schubert via swift-users 
>  wrote:
> 
> Am 03.11.2016 um 15:41 schrieb Rien :
>> 
>> Ah, but that is not the case.
>> 
>> It is important to differentiate between the “gateway” to the memory and the 
>> memory area itself.
>> Different programming languages/compilers have different approaches, but I 
>> believe that Swift allocates a struct for every gateway.
>> widePtr and narrowPtr are two different gateways. They refer to different 
>> struct's. But the struct for each of them refers to the same memory area.
> 
> When you have a look at the Swift memory model explanation
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md#memory-model-explanation
> 
> it looks like memory can only be bound to one type at a time. In particular 
> in the third example where a pointer of type T is used to initialize memory 
> which is bound to type U, it says that the behavior is undefined.
> 
> There is also withMemoryRebound(to:capacity:) which binds memory to another 
> type, executes the code that accesses the memory as this type in a closure, 
> and the restores the old type binding.
> 
> That makes me think that it is not allowed to have multiple „gateways“ to the 
> same memory area at the same time.
> 

It only means that memory access must be typed, not existence.

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

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




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


Re: [swift-users] What is "binding" memory?

2016-11-03 Thread Rien via swift-users
> On 03 Nov 2016, at 15:16, Manfred Schubert via swift-users 
>  wrote:
> 
> 
>> Am 02.11.2016 um 18:37 schrieb Rien :
>> 
 
 var rawPtr = UnsafeMutableRawPointer.allocate(bytes: 2, alignedTo: 0)
 
 var widePtr = rawPtr.bindMemory(to: Int16.self, capacity: 1)
 
 widePtr.pointee = 32
 
 var narrowPtr = rawPtr.bindMemory(to: UInt8.self, capacity: 2)
 
 narrowPtr[0] = 16
 narrowPtr[1] = 255
 
 print(widePtr.pointee)
>>> 
>>> This compiles and runs as expected, but it should not be allowed if I 
>>> understand things correctly. So shouldn’t it be a compile time error or 
>>> crash at runtime? If not, what do I get over how it was before where I was 
>>> casting to a typed pointer?
>> 
>> Why do you think it should not be allowed.
>> AFAICS everything is correct.
> 
> If I understand the documentation correctly, this should not be allowed, 
> because it’s not allowed to access memory as different types at the same 
> time. It needs to be „bound“ to the type first, and can only be bound to one 
> type at a time, so all access as another type must be encapsulated within a 
> closure.
> 

Ah, but that is not the case.

It is important to differentiate between the “gateway” to the memory and the 
memory area itself.
Different programming languages/compilers have different approaches, but I 
believe that Swift allocates a struct for every gateway.
widePtr and narrowPtr are two different gateways. They refer to different 
struct's. But the struct for each of them refers to the same memory area.

Example: widePtr can be located at address 0x1000, narrowPtr can be allocated 
at address 0x2000 while the memory area both refer to (the raw memory) can be 
at address 0x3000

Every access to the raw memory via a gateway must follow the rules for that 
gateway.

Note: Some compilers may only create ephemeral gateways, but as long as the 
compiler checks that the acces follows the correct rules, that is not a problem.

This is not only very useful, but it also opens the door to better interfaces 
to some low level Unix APIs.


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

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




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


Re: [swift-users] What is "binding" memory?

2016-11-02 Thread Rien via swift-users

> On 02 Nov 2016, at 18:07, Manfred Schubert via swift-users 
>  wrote:
> 
> Am 01.11.2016 um 21:40 schrieb Andrew Trick :
>> 
>> I’m not sure I like the “prepares the memory” language myself. Binding 
>> memory communicates to the compiler that the memory locations are safe for 
>> typed access. Nothing happens at runtime--until someone writes a type safety 
>> sanitizer.
> 
> So nothing happens at runtime, and also nothing appears to happen at compile 
> time. If I try this code:
> 
>> var rawPtr = UnsafeMutableRawPointer.allocate(bytes: 2, alignedTo: 0)
>> 
>> var widePtr = rawPtr.bindMemory(to: Int16.self, capacity: 1)
>> 
>> widePtr.pointee = 32
>> 
>> var narrowPtr = rawPtr.bindMemory(to: UInt8.self, capacity: 2)
>> 
>> narrowPtr[0] = 16
>> narrowPtr[1] = 255
>> 
>> print(widePtr.pointee)
> 
> This compiles and runs as expected, but it should not be allowed if I 
> understand things correctly. So shouldn’t it be a compile time error or crash 
> at runtime? If not, what do I get over how it was before where I was casting 
> to a typed pointer?

Why do you think it should not be allowed.
AFAICS everything is correct.
Are you referring to the multiple interpretation of the raw memory? That is 
entirely intentional, indeed one of the main purposes.

Rien.

> 
>> It affects the abstract state of the memory location, independent of the 
>> pointer variable used to access that memory. Binding memory returns a typed 
>> pointer for convenience and clarity, but there’s nothing special about that 
>> particular pointer value.
> 
> If it were not returning a typed pointer, what would it actually do?
> 
> 
> Manfred
> ___
> 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] What is "binding" memory?

2016-11-01 Thread Rien via swift-users
The way I understand it, it prepares a memory structure that refers to the ‘raw 
memory’ such that it can be used to access the referenced memory according to 
the type ‘bound’ to.
 
Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 01 Nov 2016, at 19:55, Manfred Schubert via swift-users 
>  wrote:
> 
> The "UnsafeRawPointer Migration" guide talks about "binding memory to a type“ 
> as if that was a well known term. I have never heard of it yet though, and 
> googling it returns no relevant results. I do not understand what binding 
> memory is supposed to do.
> 
> The migration guide says "Binding uninitialized memory to a type prepares the 
> memory to store values of that type“, but clearly raw memory does not need to 
> be prepared (and cannot be) to hold any arbitrary type and value.
> 
> So what is this for, what does it actually do, and to whom is it done (the 
> raw pointer, or the typed pointer which is returned, or the raw memory)?
> 
> 
> Manfred
> ___
> 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] Set-uniqueness of instances with distinct hashValue

2016-10-23 Thread Rien via swift-users
If you change the “==“ function to:

func == (lhs: X, rhs: X) -> Bool {
return (lhs.x == rhs.x) && (lhs.hashValue == rhs.hashValue)
}

then the example works as expected.

Apple says this: “A hash value, provided by a type’s hashValue property, is an 
integer that is the same for any two instances that compare equally.”

You violated this rule in the original example.

Apple says: “Set and dictionary performance depends on hash values that 
minimize collisions for their associated element and key types, respectively.”

From which I draw the conclusion that there are “under the hood” optimizations 
at work that produce the results in your example. These can probably change 
from compiler version to compiler version and are principally unreliable 
because your example violated the rule for Hashable.

Rien.

> On 23 Oct 2016, at 10:51, milos via swift-users  wrote:
> 
> Given an array of instances of a `Hashable` value type, all equal according 
> to `Equatable` protocol, but with distinct `hashValue`s, I would expect that 
> initialising a set with that array would preserve all the instances. Instead, 
> running the code below in an iOS playground on Xcode 8.0 (8A218a), results in 
> a behaviour that I cannot explain. If anyone can, I’d be very grateful!
> 
>struct X: Hashable {
>let x: Int
>let hashValue: Int
> 
>static func == (lhs: X, rhs: X) -> Bool {
>return lhs.x == rhs.x
>}
>}
> 
>let array: [X] = (1...100).map{ X(x: 7, hashValue: $0) } // unique hash 
> values
>array.count //→ 100
> 
>let set = Set(array)
>set.count //→ 43
> 
>let set2 = Set(Array(set))
>set2.count //→ 30
> 
>let set3 = Set(Array(set2))
>set3.count //→ 30
> 
>set3.sorted{ $0.hashValue < $1.hashValue }
>.forEach{ print(String($0.hashValue, radix: 2), "=", $0.hashValue) } 
> /*→
>   1 = 1
>  11 = 3
> 101 = 5
> = 15
>   10010 = 18
>   10011 = 19
>   11000 = 24
>   11101 = 29
>   1 = 31
>  10 = 32
>  100011 = 35
>  100100 = 36
>  100110 = 38
>  101000 = 40
>  101001 = 41
>  101011 = 43
>  10 = 47
>  110010 = 50
>  110101 = 53
>  01 = 61
> 110 = 66
> 1001011 = 75
> 1001101 = 77
> 100 = 79
> 101 = 80
> 1011001 = 89
> 1011100 = 92
> 100 = 94
> 101 = 95
> 1100010 = 98
>*/
> 
> Many thanks,
> 
> milos
> 
> ___
> 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] Segmentation fault: 11 after updating codebase to Swift 3.0

2016-10-21 Thread Rien via swift-users
I had a similar problem with Xcode 7.2.
The work around I found then was to remove all source files from the project in 
the “target membership” except for the main.swift file.
Then compile again, which will (of course) fail with normal errors.
Then I added the files back in, presto, no more segmentation fault.

Maybe worth a try?

Regards,
Rien.

> On 21 Oct 2016, at 18:26, Evan Maloney via swift-users 
>  wrote:
> 
> After a gargantuan effort updating our entire codebase to Swift 3.0, we are 
> now being greeted with "Segmentation fault: 11" compiler crash whenever 
> attempting to build.
> 
> The issue seems to be related to generics, and sounds similar to this issue:
> 
>   
> http://stackoverflow.com/questions/39426535/segmentation-fault-11-xcode-8-swift-3-after-using-notificationcenter/39426812
> 
> I've filed a bug report that includes our project codebase, which triggers 
> the issue 100% of the time:
> 
>   rdar://problem/28890409
> 
> The usual work-around of turning off Whole Module Optimization (which has 
> gotten around a lot of compiler crashes in the past) does not work here.
> 
> Unfortunately, this code is in such a tangle of generics that undoing it is 
> not going to be simple. Until a new version of Xcode ships, we're pretty much 
> blocked from using Swift 3.0 unless another work-around is possible.
> ___
> 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