Re: [swift-users] Swift migration bug

[Nate Birkholz via swift-users]

No worries, since it was related to changing Swift syntax I thought it might 
end up being in some schema file maintained by the Swift team, thus the 
original question. :) Easy enough to add it to my list of radars.

Sent from my iPhone, please excuse brevity and errors

> On Oct 3, 2016, at 3:59 PM, Jordan Rose  wrote:
> 
> Ha, sorry to get to these in the wrong order. The real rule is "is the 
> feature part of the Swift Open Source project", but certainly a normal Xcode 
> user isn't thinking about whether the command they just used "came from 
> Xcode" or "came from Swift".
> 
> Radars will always get to Apple Swift people if it turns out to be a Swift 
> issue, but bugs.swift.org has fewer communication restrictions and allows 
> non-Apple people to help. If it's not clearly a Swift issue ("the compiler 
> crashed") or an Xcode issue ("I can't open my project"), it's a toss-up. But 
> no harm done (and thanks for reporting the bug in the first place).
> 
> Jordan
> 
> P.S. Why did I ask you to file the bug at bugreport.apple.com yourself? 
> Because if I did it then you'd never hear when it was fixed, and wouldn't get 
> the chance to test it on your own code and say "no, you fixed the wrong 
> thing". :-)
> 
> 
>> On Oct 3, 2016, at 10:12, Nate Birkholz via swift-users 
>>  wrote:
>> 
>> Then Jordan Rose closed it as not a Swift bug. :)
>> 
>> On Mon, Oct 3, 2016 at 2:03 AM, Alex Blewitt  wrote:
 On 30 Sep 2016, at 19:30, Nate Birkholz via swift-users 
  wrote:
 
 I found a bug in Swift 2.3 migration in the XCUITests, not sure if the bug 
 goes to swift.org or to Apple.
 
 UI test generator uses the syntax (XCUIElement).children(matching: .other) 
 but the compiler only recognizes childrenMatchingType(.Other), and you 
 have to manually change the instances. Makes generating UI Tests a pain!
>>> 
>>> Please open a bug at https://bugs.swift.org and then it can be re-routed if 
>>> necessary. If you can attach the snippet of code with before/after that 
>>> would help.
>>> 
>>> Thanks!
>>> 
>>> Alex
>>> 
>> 
>> 
>> 
>> -- 
>> Nate Birkholz
>> ___
>> 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 migration bug

[Jordan Rose via swift-users]

Ha, sorry to get to these in the wrong order. The real rule is "is the feature 
part of the Swift Open Source project", but certainly a normal Xcode user isn't 
thinking about whether the command they just used "came from Xcode" or "came 
from Swift".

Radars will always get to Apple Swift people if it turns out to be a Swift 
issue, but bugs.swift.org has fewer communication restrictions and allows 
non-Apple people to help. If it's not clearly a Swift issue ("the compiler 
crashed") or an Xcode issue ("I can't open my project"), it's a toss-up. But no 
harm done (and thanks for reporting the bug in the first place).

Jordan

P.S. Why did I ask you to file the bug at bugreport.apple.com yourself? Because 
if I did it then you'd never hear when it was fixed, and wouldn't get the 
chance to test it on your own code and say "no, you fixed the wrong thing". :-)


> On Oct 3, 2016, at 10:12, Nate Birkholz via swift-users 
>  wrote:
> 
> Then Jordan Rose closed it as not a Swift bug. :)
> 
> On Mon, Oct 3, 2016 at 2:03 AM, Alex Blewitt  > wrote:
>> On 30 Sep 2016, at 19:30, Nate Birkholz via swift-users 
>> mailto:swift-users@swift.org>> wrote:
>> 
>> I found a bug in Swift 2.3 migration in the XCUITests, not sure if the bug 
>> goes to swift.org  or to Apple.
>> 
>> UI test generator uses the syntax (XCUIElement).children(matching: .other) 
>> but the compiler only recognizes childrenMatchingType(.Other), and you have 
>> to manually change the instances. Makes generating UI Tests a pain!
> 
> Please open a bug at https://bugs.swift.org  and 
> then it can be re-routed if necessary. If you can attach the snippet of code 
> with before/after that would help.
> 
> Thanks!
> 
> Alex
> 
> 
> 
> 
> -- 
> Nate Birkholz
> ___
> 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] Class Variable delayed stored

[jason bronson via swift-users]

I have this class I wrote which stores the error messages from the
firebaseauth if a error occurs.
The problem is that the variable on first return is not set and on second
return is.
variable _errorMsg is empty on first return of method registerUser

Why is it not storing the variable when it's initially triggered?


//

//  Authentication.swift


import Firebase

import FirebaseAuth

import FBSDKCoreKit

import FBSDKLoginKit


class Authentication: UIViewController {


public var _errorMsg: String = ""

private var createdUser: Bool!

private var _userSignedIn = false





   /**

*  Registers a user using email/password method

*/

func registerUser(email : String, password: String) -> Bool{

createdUser = false

FIRAuth.auth()?.createUser(withEmail: email, password: password,
completion: {(user, error) in

if error != nil {

   if let errCode = FIRAuthErrorCode(rawValue: (error?._code)!)
{

switch errCode {

case FIRAuthErrorCode.errorCodeInvalidEmail:

self._errorMsg = "Invalid Email"

print("DEBUG: invalid email")

case FIRAuthErrorCode.errorCodeEmailAlreadyInUse:

self._errorMsg = "Email already in use"

print("DEBUG: in use")

case FIRAuthErrorCode.errorCodeWeakPassword:

self._errorMsg = "Enter a stronger password"

print("DEBUG: stronger password")

default:

print("DEBUG: Create User Error: ")

self._errorMsg = "Unknown Error "



   }



}

print("DEBUG: New user failed to create")



}else{

print("DEBUG: New user created ")

self.createdUser = true

}

})



return self.createdUser





}



   /**

* Registers a user using facebook login method

*/

func facebookLogin() -> Bool{



let facebookLogin = FBSDKLoginManager()

facebookLogin.logIn(withReadPermissions: ["email"], from: self){
(result, error) in

if error != nil {

print("DEBUG: Unable to authenticate with Facebook \(error)"
)

}else if result?.isCancelled == true {

print("DEBUG: User cancelled authenticate with Facebook \(
error)")

}else {

print("DEBUG: User success")

let credential =
FIRFacebookAuthProvider.credential(withAccessToken:
FBSDKAccessToken.current().tokenString)

self.firebaseAuth(credential)

}



}

return _userSignedIn

}



   /**

* Authentication through firebase

* @parameter credential

*/

func firebaseAuth(_ credential: FIRAuthCredential){



FIRAuth.auth()?.signIn(with: credential, completion: {(user, error)
in

if error != nil {

print("DEBUG: Failed auth with Firebase \(error)")

self._userSignedIn = false

}else{

print("DEBUG: Success auth with Firebase")

self._userSignedIn = true

}

})

}




/**

 * Checks if the user is already signed in and sets the variable.

 */

func signedIn() -> Bool {



if ((FIRAuth.auth()?.currentUser) != nil) {

print("DEBUG: user is signed in")

_userSignedIn = true

}



return _userSignedIn

}



   /**

*  Stores the error messages for authentication issues

*/

var errorMsg: String {

get{

return _errorMsg

}

set(value){

_errorMsg = value

}

}





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

Re: [swift-users] Performance critical code in Swift

[Игорь Никитин via swift-users]

Thanks for advices!
I’m switches to C and will write data to file instead of sqlite
It will give me 5x-10x performance growth for writing
But it will also increase the time for reading, I think (I've not measured it)

I’m also looked for some sqlite alternative, but didn’t found
Realm is fast for reading, but not for writing
And it gives some memory overhead
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] UnsafeMutablePointer on the stack?

[Joe Groff via swift-users]

> On Oct 3, 2016, at 10:20 AM, Jens Alfke via swift-users 
>  wrote:
> 
> 
>> On Oct 2, 2016, at 5:14 PM, Mike Ferenduros via swift-users 
>> mailto:swift-users@swift.org>> wrote:
>> 
>> Personally I would be surprised if the malloc caused an actual measurable 
>> performance hit tbh.
> 
> It won’t be noticeable against a call to SecRandom, as noted, but there are 
> other circumstances where it’s a big performance hit to put a temporary 
> buffer on the heap. (Right now I’m working on some rather 
> performance-sensitive database code in C++ where avoiding a few heap 
> allocations per iteration has proven to be a big win.)
> 
> Does Swift have any solution for allocating stack-based array buffers?

There has been some work in the optimizer toward optimizing arrays onto the 
stack when they don't escape. In general, I would recommend sticking with the 
pointer allocate/deallocate methods if you need to directly control the destiny 
of the memory. If the allocate and deallocate occur unconditionally in the same 
function, it is possible to optimize the pair into a stack allocation. Using a 
local variable isn't a guarantee that you'll get stack memory, since closures 
may force the variable onto the heap, and furthermore subjects you to more 
aggressive semantic constraints on the underlying memory than you may want.

-Joe

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

Re: [swift-users] UnsafeMutablePointer on the stack?

[Jens Alfke via swift-users]

> On Oct 2, 2016, at 5:14 PM, Mike Ferenduros via swift-users 
>  wrote:
> 
> Personally I would be surprised if the malloc caused an actual measurable 
> performance hit tbh.

It won’t be noticeable against a call to SecRandom, as noted, but there are 
other circumstances where it’s a big performance hit to put a temporary buffer 
on the heap. (Right now I’m working on some rather performance-sensitive 
database code in C++ where avoiding a few heap allocations per iteration has 
proven to be a big win.)

Does Swift have any solution for allocating stack-based array buffers?

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

Re: [swift-users] Swift migration bug

[Nate Birkholz via swift-users]

Then Jordan Rose closed it as not a Swift bug. :)

On Mon, Oct 3, 2016 at 2:03 AM, Alex Blewitt  wrote:

> On 30 Sep 2016, at 19:30, Nate Birkholz via swift-users <
> swift-users@swift.org> wrote:
>
> I found a bug in Swift 2.3 migration in the XCUITests, not sure if the bug
> goes to swift.org or to Apple.
>
> UI test generator uses the syntax (XCUIElement).children(matching:
> .other) but the compiler only recognizes childrenMatchingType(.Other), and
> you have to manually change the instances. Makes generating UI Tests a pain!
>
>
> Please open a bug at https://bugs.swift.org and then it can be re-routed
> if necessary. If you can attach the snippet of code with before/after that
> would help.
>
> Thanks!
>
> Alex
>
>


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

Re: [swift-users] clang builtins from Swift?

[Chris Lattner via swift-users]

> On Oct 2, 2016, at 6:24 PM, Jean-Denis Muys via swift-users 
>  wrote:
> 
> Hi,
> 
> Xcode seems to think that [some] builtins can be used from Swift. It 
> autocompletes popcount for example, and command-clicking the function opens a 
> bona fide interface file, with the following declaration (among others):
> 
> public func __builtin_popcount(_: UInt32) -> Int32
> 
> However, when I try to compile code that uses that function, I get an 
> unresolved identifier compiler error.
> 
> I guess I need to import some module, but which one?

Huh, that is odd.  It should not be made available to Swift code like that.  
Please file a jira or radar ticket, thank you!

-Chris

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

Re: [swift-users] A sample Rational number type

[Dave Abrahams via swift-users]

on Sun Oct 02 2016, Hooman Mehr  wrote:

>> On Oct 2, 2016, at 5:23 PM, Dave Abrahams via swift-users 
>>  wrote:
>> Presumably you mean:
>> 
>>  let r2 = r±0.0005 // turn a Rational into a Double with no more than
>>// .0005 rounding error
>> 
>> ? That is supercute!
>> 
>
> It is actually the other way around: It returns a rational given a
> double so that the maximum difference of the created rational with the
> input double is the specified tolerance.

Oh, nifty.  How about the other direction?

>> Have you thought about what this would look like after we land
>> https://github.com/apple/swift/pull/3796 (see
>> https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md)
>> ?
>> 
>
> That is the next thing I want to look at, the next chance I get. 

Thank you!

> For now, it isn’t much more than a quick hack on a slow Friday…
>
>> You can also find a working prototype of that code at
>>
> https://github.com/apple/swift/blob/b7622b41756e33bdf3f3415320ffec52aec73281/test/Prototypes/Integers.swift.gyb
>> It would be great to know that the protocols we've designed actually
>> work out for Rational numbers.  With these protocols, can you make your
>> Rational generic on the underlying integer type?
>> 
>> There's a BigInt implementation based on these protocols here:
>> https://github.com/natecook1000/swift/commit/45c52a75dcc15024649a5e093a5da4ee031595c2
>> 
>> It would be really cool to see it work with a generic version of your
>> Rational type.
>
> Interesting idea. A BigInt type can really lift Rational to new
> levels. Interesting case study to see how well the new protocols work.

Quite so!  [FWIW, I rather wish that BigInt was using two's complement
representation, as the protocols were designed to make that work
smoothly]


>> It's interesting to see that one wants a different algorithm for GCD
>> when using BigInts:
>> https://en.wikipedia.org/wiki/Binary_GCD_algorithm#cite_note-11
>> 
>> I wonder how that should be dispatched…
>
> Moreover, there is something I ran into after posting: On today’s CPU
> architectures with fast integer divide, simple binary CGD is slower
> than basic Euler’s algorithm using remainders. Binary GCD needs the
> equivalent of __builtin_ctz to run faster. 

The new integer protocols expose that as a "leadingZeros" property.

> It would be nice if compiler could detect the shift loops and replace
> the whole loop with x86 BSFL instruction.

Talk to the llvm people :-).  You'll want to use masking shifts under
the new integer protocols.

> I need to put some thought on whether there is an efficient means of
> switching the algorithm based on the actual size (or nature) of the
> given Int type, otherwise we may have to specialize, which is not good
> from a generics standpoint.

It depends exactly what you mean by that term :-)

-- 
-Dave

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

Re: [swift-users] Performance critical code in Swift

[Tino Heth via swift-users]

My general advice for performance critical code (especially when it's about 
stuff like serialization and parsing):
If you just want a working solution without spending much time, stick with C.
Swift can be fast, but it's harder to write slow code in C.

If, on the other hand, coding time is no big concern:
Use Swift, try to get it as fast as possible (can take time) — and if this 
isn't enough, switch to C (which might end up to be to slow as well ;-)

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

Re: [swift-users] CharacterSet vs Set

[Gerriet M. Denkmann via swift-users]

> On 3 Oct 2016, at 19:17, Jean-Denis Muys via swift-users 
>  wrote:
> 
> You are right: I don’t know much about asian languages.
> 
> How would you go about counting consonants, vowels (and tone-marks?) in the 
> most general way?

Iterate over unicodeScalars (in the most general case) - Swift characters are 
probably ok for European languages.

For each unicodeScalar a.k.a codepoint you can use the icu function:
int8_t  chrTyp = u_charType (codepoint) 
This returns the general category value for the code point.
This gives you something like U_OTHER_PUNCTUATION, U_MATH_SYMBOL, 
U_OTHER_LETTER etc.
See enum UCharCategory in 


In European languages ignore U_NON_SPACING_MARKs.

There is a compare:options function for NSString (and probably similar for 
Swift String) which might use the options NSCaseInsensitiveSearch and 
NSDiacriticInsensitiveSearch to find equality between ‘E’, ‘e’ and è, é, Ĕ etc.
That is: for each character (or unicodeScalar) compare to a, e, i, o, u with 
these options.

let str = "HaÁÅǺáXeëẽêèâàZ"

for char in str.characters
{
let vowel = isVowel( char )
print("\(char) is \(vowel ? "vowel" : "consonant")")
}

func isVowel( _ char: Character ) -> Bool
{
let s1 = "\(char)"
let s2 = s1 as NSString
let opt: NSString.CompareOptions = [.diacriticInsensitive, 
.caseInsensitive]

//  no idea how do to this with Strings:
if s2.compare("a", options: opt) == .orderedSame {return true}
if s2.compare("e", options: opt) == .orderedSame {return true}
…
return false
}


If you really want to use Thai, then do NOT ignore U_NON_SPACING_MARKs because 
some vowels are classified thusly.
U+0E01 … U+0E2E are consonants, U+0E30 … U+0E39 and U+0E40 … U+0E44 are vowels.
But then: ‘อ’ is sometimes a (silent) consonant (อยาก), sometimes a vowel (บอ), 
sometimes part of a vowel (มือ), sometimes part of a diphthong (เบื่อ).
Similar for ย: normal consonant (ยาก), part of vowel (ไทย) or diphthong (เมีย).
In the latter case only ม is a consonant, the rest is one single diphthong and 
ี is a U_NON_SPACING_MARK which really is a vowel.
Oh, and don't forget the ligatures ฤ, ฤๅ, ฦ, ฦๅ. These are both a consonant and 
a vowel. Same for ำ: not a ligature but a vowel + consonant.


But to talk about german:
What about diphthongs? “neu” has one consonant + one vowel sound (but 2 vowel 
characters).
What if some silly users don’t know how to type umlauts and write “ueber” 
(instead of correctly “über”). This is really one consonant (+diaeresis).
But beware: “aktuell” is definitely not a misspelling of “aktüll” and has two 
vowels.

Gerriet.

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

Re: [swift-users] Swift migration bug

[Nate Birkholz via swift-users]

https://bugs.swift.org/browse/SR-2837

On Mon, Oct 3, 2016 at 2:03 AM, Alex Blewitt  wrote:

> On 30 Sep 2016, at 19:30, Nate Birkholz via swift-users <
> swift-users@swift.org> wrote:
>
> I found a bug in Swift 2.3 migration in the XCUITests, not sure if the bug
> goes to swift.org or to Apple.
>
> UI test generator uses the syntax (XCUIElement).children(matching:
> .other) but the compiler only recognizes childrenMatchingType(.Other), and
> you have to manually change the instances. Makes generating UI Tests a pain!
>
>
> Please open a bug at https://bugs.swift.org and then it can be re-routed
> if necessary. If you can attach the snippet of code with before/after that
> would help.
>
> Thanks!
>
> Alex
>
>


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

[swift-users] How to change the Swift REPL default prompt?

[Rafał Kowalski via swift-users]

Hi,

I've been using the `swift-mode` and the Swift REPL under Emacs to
program in Swift.  Unfortunately, the Swift REPL doesn't expect a "dumb
terminal" and issues a lot of `ESC` terminal control sequences to format
its prompt nicely, e.g. `ESC [J` `ESC [1G ESC[J 1> ESC [1G 1> ESC [1G 1>
ESC [6G`.  This is rather disturbing under Emacs.

Is there a way to set the Swift REPL prompt differently, similarly to
setting a Bash prompt?

https://www.gnu.org/software/bash/manual/bashref.html#Controlling-the-Prompt

cheers
--
-rafał

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

Re: [swift-users] CharacterSet vs Set

[Jean-Denis Muys via swift-users]

You are right: I don’t know much about asian languages.

How would you go about counting consonants, vowels (and tone-marks?) in the 
most general way?

I think I would need to educate myself about those things. Any pointer welcome.

JD


> On 3 Oct 2016, at 12:52, Gerriet M. Denkmann  wrote:
> 
> 
>> On 3 Oct 2016, at 16:28, Jean-Denis Muys via swift-users 
>>  wrote:
>> 
>> ASCII? Probably not. Latin? perhaps, though not obvious. For example French 
>> accented letters would probably have to be handled somehow. Greek or 
>> Cyrillic? Perhaps. Other scripts? Unlikely, but what do I know.
> 
> Don’t be so Europe-centric. Other people have vowels too.
> Thai for example. And here are Swift characters completely useless: กี้ is 
> one character (for Swift) but it is really one consonant + one vowel + one 
> tone-mark.
> So you will have to use unicodeScalars.
> 
> Have fun!
> 
> Gerriet.
> 

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

Re: [swift-users] CharacterSet vs Set

[Gerriet M. Denkmann via swift-users]

> On 3 Oct 2016, at 16:28, Jean-Denis Muys via swift-users 
>  wrote:
> 
> ASCII? Probably not. Latin? perhaps, though not obvious. For example French 
> accented letters would probably have to be handled somehow. Greek or 
> Cyrillic? Perhaps. Other scripts? Unlikely, but what do I know.

Don’t be so Europe-centric. Other people have vowels too.
Thai for example. And here are Swift characters completely useless: กี้ is one 
character (for Swift) but it is really one consonant + one vowel + one 
tone-mark.
So you will have to use unicodeScalars.

Have fun!

Gerriet.

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

Re: [swift-users] UnsafeMutablePointer on the stack?

[Jean-Denis Muys via swift-users]

Indeed,

But that function was just an example. I wanted to learn about how to use the 
stack to call C functions that will fill some memory area passed as a pointer.

Jean-Denis



> On 3 Oct 2016, at 09:46, Quinn The Eskimo! via swift-users 
>  wrote:
> 
> 
> On 3 Oct 2016, at 01:14, Mike Ferenduros via swift-users 
>  wrote:
> 
>> Personally I would be surprised if the malloc caused an actual measurable 
>> performance hit tbh.
> 
> Quite.  SecRandom generates cryptographically sound random numbers and thus 
> is not optimised for speed.
> 
> Share and Enjoy
> --
> Quinn "The Eskimo!"
> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

Re: [swift-users] CharacterSet vs Set

[Jean-Denis Muys via swift-users]

You are perfectly right. The context is playing around really, but I was more 
specifically writing a function counting vowels and consonants in an arbitrary 
string:

func countLetters(s: String) -> (vowels: Int, consonants: Int) {
let vowels: Set = Set("AEIOU".characters)
let consonants: Set = Set("BCDFGHJKLMNPQRSTVWXYZ".characters)

var v = 0, c = 0

for char in s.uppercased().characters {
if vowels.contains(char) {
v += 1
}
if consonants.contains(char) {
c += 1
}
}

return (v, c)
}

As you could see, I opted not to use CharacterSet for this case, as it looked 
too much trouble. 

The current goal is for me to learn Swift. Trying to extrapolate a bit on what 
might happen in the real world, I would tend to answer your questions thus:

> * Do you plan to use a fixed character set?  Or is the character set itself 
> built at runtime?

The character set is likely to be fixed. Does this really change anything?

> * Do you have specific knowledge of either of the inputs?  Like that they’re 
> all ASCII?  Or normalised in a certain way?

ASCII? Probably not. Latin? perhaps, though not obvious. For example French 
accented letters would probably have to be handled somehow. Greek or Cyrillic? 
Perhaps. Other scripts? Unlikely, but what do I know.
Normalisation: it should probably consider all variations of “é” to be the same…
Is this opening a Unicode can of worms? Possibly. I am not knowledgeable 
enough, but willing to learn.

> * Specifically, where do the characters you’re trying to test (`char` in your 
> example) come from?  Do they represent user input, in which case they can be 
> arbitrary Unicode?  Or something more constrained


User input most probably.

I tried and your suggestion:

> let uchar: UnicodeScalar = “E"

will not work with a Character variable (as opposed to a character literal)

let uchar: UnicodeScalar = char

(Cannot convert value of type Character to specified type UnicodeScalar)

Thanks,

Jean-Denis 


> On 3 Oct 2016, at 09:43, Quinn The Eskimo! via swift-users 
>  wrote:
> 
> 
> On 2 Oct 2016, at 19:02, Jean-Denis Muys via swift-users 
>  wrote:
> 
>> The problem is, I could not find a simple way to convert from a character to 
>> a unicodeScalar. 
> 
> As is often the case with string examples, it would help if you posted more 
> about your context.  With the details we have now your code could be written 
> like this:
> 
> let vowels = CharacterSet(charactersIn: "AEIOU")
> let char: UnicodeScalar = "E"
> vowels.contains(char)
> 
> but I’m pretty sure that won’t help in your real app (-:  So, my questions:
> 
> * Do you plan to use a fixed character set?  Or is the character set itself 
> built at runtime?
> 
> * Do you have specific knowledge of either of the inputs?  Like that they’re 
> all ASCII?  Or normalised in a certain way?
> 
> * Specifically, where do the characters you’re trying to test (`char` in your 
> example) come from?  Do they represent user input, in which case they can be 
> arbitrary Unicode?  Or something more constrained
> 
> Share and Enjoy
> --
> Quinn "The Eskimo!"
> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

Re: [swift-users] Swift migration bug

[Alex Blewitt via swift-users]

> On 30 Sep 2016, at 19:30, Nate Birkholz via swift-users 
>  wrote:
> 
> I found a bug in Swift 2.3 migration in the XCUITests, not sure if the bug 
> goes to swift.org  or to Apple.
> 
> UI test generator uses the syntax (XCUIElement).children(matching: .other) 
> but the compiler only recognizes childrenMatchingType(.Other), and you have 
> to manually change the instances. Makes generating UI Tests a pain!

Please open a bug at https://bugs.swift.org  and then 
it can be re-routed if necessary. If you can attach the snippet of code with 
before/after that would help.

Thanks!

Alex

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

Re: [swift-users] UnsafeMutablePointer on the stack?

[Quinn "The Eskimo!" via swift-users]

On 3 Oct 2016, at 01:14, Mike Ferenduros via swift-users 
 wrote:

> Personally I would be surprised if the malloc caused an actual measurable 
> performance hit tbh.

Quite.  SecRandom generates cryptographically sound random numbers and thus is 
not optimised for speed.

Share and Enjoy
--
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware


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

Re: [swift-users] CharacterSet vs Set

[Quinn "The Eskimo!" via swift-users]

On 2 Oct 2016, at 19:02, Jean-Denis Muys via swift-users 
 wrote:

> The problem is, I could not find a simple way to convert from a character to 
> a unicodeScalar. 

As is often the case with string examples, it would help if you posted more 
about your context.  With the details we have now your code could be written 
like this:

let vowels = CharacterSet(charactersIn: "AEIOU")
let char: UnicodeScalar = "E"
vowels.contains(char)

but I’m pretty sure that won’t help in your real app (-:  So, my questions:

* Do you plan to use a fixed character set?  Or is the character set itself 
built at runtime?

* Do you have specific knowledge of either of the inputs?  Like that they’re 
all ASCII?  Or normalised in a certain way?

* Specifically, where do the characters you’re trying to test (`char` in your 
example) come from?  Do they represent user input, in which case they can be 
arbitrary Unicode?  Or something more constrained

Share and Enjoy
--
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware


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