Re: [swift-users] Future(of: self.references)?

[Travis Griggs via swift-users]

> On May 22, 2017, at 5:56 PM, Greg Power  wrote:
> 
> Hi Travis,
> 
> I’m certainly not a core contributor, but I could point you to the rejection 
> email for this proposal, which you might not have seen:
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160104/005478.html
>  
> 
> 
> It states that the core team felt that the proposal was not the right 
> direction for Swift, and lists a few reasons.
> 
> The main reason appears to be that enforcing a mandatory self for instance 
> members would increase the visual clutter of the language, which is counter 
> to Swift's goals of clarity and minimal boilerplate.
> 
> That email links to Paul Cantrell’s response to the proposal, which is also a 
> really good (and elucidating) read: 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002910.html
>  
> .
> 
> No need for flame or heat!
> 

Thank you Greg (and others) for the replies. I don’t think much of the 
*rationale* stated there, especially actually Paul Cantrell’s. BUT, I can 
appreciate that it was a “contentious” issue. And as said, I didn’t come to 
stir the pot. Merely to get clarification.

I did my time in the language wars of the late 90’s and early 00’s. After a 
while, like real wars, I came to realize the pointlessness of a lot of it. 
Perspectives are huge, e.g. brevity of characters and brevity in consistency 
are two different things that can counter each other and be argued equally by 
both sides in the name of brevity. History repeats itself. Swift has lots to 
like.

It would be great if there was a switch in a tool like Xcode that would insert 
magical “self” bubbles for visual consistency wherever they appeared. But then… 
I’m still wondering if we’ll ever see refactoring tools emerge in Xcode for 
Swift (and beginning to lose hope).___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] Helping the type checker

[Daniel Müllenborn via swift-users]

I have recently used the "-warn-long-function-bodies" flag, and have luckily 
only one place in my code where I should give the compiler a better hint. At 
Swift 4 it looks a bit different, but I prefer to wait before I make any 
unnecessary changes.

The code is as follows:

  subscript(path: IndexPath) -> ViewModel.SubField {
get {
  return 
ViewModel.connectors[path[0]][path[1]].connector.subFields[path[2]][path[3]]
}
set {
  ViewModel.connectors[path[0]][path[1]].subFields[path[2]][path[3]] = 
newValue
}
  }


I made it:

  subscript(path: IndexPath) -> ViewModel.SubField {
get {
  let connector = ViewModel.connectors[path[0]][path[1]]
  return connector.subFields[path[2]][path[3]]
}
set {
  ViewModel.connectors[path[0]][path[1]].subFields[path[2]][path[3]] = 
newValue
}
  }

And the warning for the get disappears, but I do not know what to do with set 
part.
The 1.4 seconds it takes, now bother me where I know it.

For a better understanding, the types look like this.

enum ViewModel {
  
  struct Connector {
var subFields: [[SubField]] = []
  }
  
  static var connectors: [[ViewModel.Connector]] = []
  
  struct SubField: Hashable {}
  
}

Has anyone a solution for me?

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

[swift-users] Can I have my cake and share it too with extensions?

[Travis Griggs via swift-users]

In my own project, I add some extensions to Data and other objects to make 
building/parsing Data objects easier. Amongst others, I have extensions like 
this:

func += (data:inout Data, string:String) {
data.append(string.data(using: .utf8)!)
}

func += (data:inout Data, convertible:DataConvertible) {
data.append(convertible.data)
}

I use it widely.

But I’ve also been incorporated a small single file MQTT implementation 
(LightMQTT) that is shared as an ad hoc component with others. I’ve been trying 
to simplify the implementation of LightMQTT to use a similar technique, but the 
way things encode themselves is a little different (e.g. a string puts a 2 byte 
big endian count before itself, etc). Naively, I had added extensions like such:

protocol MQTTDataAppendable {
static func += (data:inout Data, appendee:Self)
} 

extension UInt8:MQTTDataAppendable {
static func += (data:inout Data, appendee:UInt8) {
data.append(appendee)
}
}

extension UInt16:MQTTDataAppendable {
static func += (data:inout Data, appendee:UInt16) {
data += UInt8((appendee & 0xFF00) >> 8) 
data += UInt8(appendee & 0xFF)
}
}

extension String:MQTTDataAppendable {
// 
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718016
static func += (data:inout Data, appendee:String) {
data += UInt16(appendee.utf8.count)
data.append(appendee.data(using: .utf8)!)
}
}

So in the same code space, when I tried then use expressions like:

packet += “MQTT”

The compiler gets cornfuzzled because there’s of course ambiguous resolution of 
+=. I get why this is. The question I guess is can I pull this off (regardless 
of whether its a good idea or not, because I suspect it may not be, but I still 
want to know). I toyed with sprinkling fileprivate in front of those 
extensions, but it didn’t like the way I did it.

I could just make a Packet struct that wraps a Data struct I think, and that 
would keep the two from colliding. Curious what other solutions (good or bad) 
would allow the overloaded operator extensions to be disambiguated?
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] arc4random_uniform on Linux is missing from Foundation??

[Edward Connell via swift-users]

Thank you for all the feedback and options. In further investigation, I
also ran across the family of xx48 rngs, which appear to be on both
platforms. They claim to be uniformly distributed.

drand48, erand48, jrand48, lcong48, lrand48, mrand48, nrand48, seed48,
srand48

http://pubs.opengroup.org/onlinepubs/007908775/xsh/drand48.html

Any reason not to use one of these instead?

Thanks, Ed

On Tue, May 23, 2017 at 3:18 AM, Jens Persson  wrote:

> Here's a stripped down verison of my implementation of the Xoroshiro128+
> PRNG:
> https://gist.github.com/anonymous/527602968812f853d6147aea8c66d660
>
> /Jens
>
>
> On Mon, May 22, 2017 at 11:21 PM, Jens Persson  wrote:
>
>> Sorry for the premature send ...
>> Here is the site: http://xoroshiro.di.unimi.it
>> There is also a section there about "generating uniform doubles in unit
>> interval" which is worth reading.
>> And here's how to get uniform floating point values in the range [0, 1)
>> from various (supposedly) random bit patterns:
>>
>> extension Double {
>>
>> init(unitRange v: UInt64) {
>>
>> let shifts: UInt64 = 63 - UInt64(Double.significandBitCount)
>>
>> self = Double(v >> shifts) * (.ulpOfOne/2)
>>
>> }
>>
>> init(unitRange v: UInt32) {
>>
>> self = (Double(v) + 0.5) / (Double(UInt32.max) + 1.0)
>>
>> }
>>
>> init(unitRange v: UInt16) {
>>
>> self = (Double(v) + 0.5) / (Double(UInt16.max) + 1.0)
>>
>> }
>>
>> init(unitRange v: UInt8) {
>>
>> self = (Double(v) + 0.5) / (Double(UInt8.max) + 1.0)
>>
>> }
>>
>> }
>>
>> extension Float {
>>
>> init(unitRange v: UInt64) {
>>
>> let shifts: UInt64 = 63 - UInt64(Float.significandBitCount)
>>
>> self = Float(v >> shifts) * (.ulpOfOne/2)
>>
>> }
>>
>> init(unitRange v: UInt32) {
>>
>> let shifts: UInt32 = 31 - UInt32(Float.significandBitCount)
>>
>> self = Float(v >> shifts) * (.ulpOfOne/2)
>>
>> }
>>
>> init(unitRange v: UInt16) {
>>
>> let a = Float(v) + 0.5
>>
>> let b = Float(UInt16.max) + 1.0
>>
>> self = a / b
>>
>> }
>>
>> init(unitRange v: UInt8) {
>>
>> let a = Float(v) + 0.5
>>
>> let b = Float(UInt8.max) + 1.0
>>
>> self = a / b
>>
>> }
>>
>> }
>>
>>
>> You will get a very fast and good quality prng using xoroshiro,
>> converting to unit range floating point and then back to uniform range int
>> if you want to, much much faster than arc4random.
>>
>>
>> /Jens
>>
>>
>>
>>
>>
>> On Mon, May 22, 2017 at 11:17 PM, Jens Persson  wrote:
>>
>>> Check out the generators (especially xoroshiro) on this site:
>>>
>>> On Mon, May 22, 2017 at 6:54 PM, Saagar Jha via swift-users <
>>> swift-users@swift.org> wrote:
>>>

 Saagar Jha

 On May 22, 2017, at 08:44, Edward Connell via swift-users <
 swift-users@swift.org> wrote:

 Any ideas when Foundation on Linux will support arc4random_uniform?
 This is kind of an important function.
 There doesn't seem to be any decent substitute without requiring the
 installation of libbsd-dev, which turns out to be messy. Currently I am
 doing this, but glibc random with mod does not produce good quality
 numbers, due to modulo bias.


 Modulo bias is easy to deal with, though, if you force random to
 produce a range that is a multiple of the range that you’re trying to
 produce:

 guard range > 0 else { return 0 }
 var random: Int
 repeat {
 random = Int(random())
 } while(random > LONG_MAX / range * range)
 return random % range


 Has anyone come up with a better solution to get a true uniform
 distribution that isn't super messy?

 import Foundation

 #if os(Linux)
 import Glibc
 #endif


 public func random_uniform(range: Int) -> Int {
 guard range > 0 else { return 0 }
 #if os(Linux)
  return Int(random()) % range
 #else
 return Int(arc4random_uniform(UInt32(range)))
 #endif
 }


 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


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