date:20160511

Re: [swift-users] Initializing a UIColor

2016-05-11 Thread Chris Lattner via swift-users


> On May 11, 2016, at 7:37 AM, Erica Sadun via swift-users 
>  wrote:
> 
>> 
>>> On May 11, 2016, at 9:57 AM, Dennis Weissmann >> > wrote:
>>> 
>>> Huh! There’s a new overload for that initializer:
>>> 
>>> 
>>> 
>>> The one that takes CGFloats is the one that was there before, but the one 
>>> taking Floats is new!
>>> 
>>> You can work around like this:
>>> 
>>> let color = UIColor(red: CGFloat(0.892), green: CGFloat(0.609), blue: 
>>> CGFloat(0.048),  alpha: CGFloat(1.000))
>>> or
>>> let color = UIColor(red: Float(0.892), green: Float(0.609), blue: 
>>> Float(0.048),  alpha: Float(1.000))
>>> 
>>> - Dennis
> 
> 
> Wow, that's a ridiculous situation to have.  Who uses Float with iOS/tvOS 
> anyway? 
> 
> I created a workaround, but I hate it:

This is a known regression that is a fallout of the changes to playground 
literals, it is high priority to get fixed.

-Chris

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

Re: [swift-users] swift redistributable without Xcode

2016-05-11 Thread Tim Prepscius via swift-users

Or better yet.

What is the command that is used to build the downloadable swift
packages for OSX?
I can go from there probably.

-tim

On 5/11/16, Tim Prepscius  wrote:
> Also,
>
> So I build the thing, and I move over the swift directory to a
> computer without Xcode.
>
> I run bin/swift
> and get:
>
> swift-macosx-x86_64 tim$ bin/swift
> ***  You are running Swift's integrated REPL,  ***
> ***  intended for testing purposes only.   ***
> ***  The full REPL is built as part of LLDB.   ***
> ***  Type ':help' for assistance.  ***
> (swift) import Foundation
> :0: error: cannot load underlying module for 'CoreGraphics'
> :0: note: did you forget to set an SDK using -sdk or SDKROOT?
> :0: note: use "xcrun -sdk macosx swiftc" to select the
> default OS X SDK installed with Xcode
>
>
> I then guess the SDK would be:
> ./stdlib/public/SDK
>
> so:
> swift-macosx-x86_64 tim$
> SDKROOT=/Users/tim/temp/swift-macosx-x86_64/stdlib/public/SDK
> bin/swift
> ***  You are running Swift's integrated REPL,  ***
> ***  intended for testing purposes only.   ***
> ***  The full REPL is built as part of LLDB.   ***
> ***  Type ':help' for assistance.  ***
> (swift) import Foundation
> :0: error: cannot load underlying module for 'CoreGraphics'
>
>
>
>
> Any ideas here?
> Is there any known build where I can build swift, copy the build to
> another OS X computer and run it?
>
> Thanks,
>
> -tim
>
> On 5/11/16, Tim Prepscius  wrote:
>> Ok,
>>
>> so when I build finally it:
>> du -h -d 1
>> 3.7M ./cmark-macosx-x86_64
>>  81M ./llbuild-macosx-x86_64
>> 5.6G ./lldb-macosx-x86_64
>> 7.9G ./llvm-macosx-x86_64
>>  18M ./ninja-build
>> 8.4G ./swift-macosx-x86_64
>>  47M ./swiftpm-macosx-x86_64
>>  22G .
>>
>>
>> 22 gigs is a bit much?
>> Even the 8.4gigs for just the swift directory is a bit much.
>>
>> Am I running the wrong preset somehow?
>> Should I be running a certain preset of the build-bot?
>>
>> -tim
>>
>>
>> On 5/9/16, Tim Prepscius  wrote:
>>> Thank you,
>>>
>>> Trying.
>>>
>>> utils/build-toolchain local.swift tries to use ninja which fails
>>> so I go to the swift and see "git clone
>>> g...@github.com:ninja-build/ninja.git && cd ninja" ...
>>> which fails
>>>
>>> so I do:
>>> git clone https://github.com/ninja-build/ninja.git
>>>
>>> and then I do git checkout release
>>> like it says to
>>>
>>> but that creates a branch release
>>> I'm guessing git checkout $RELEASE
>>> where RELEASE=v1.7.1
>>>
>>>
>>> my updated build swift script now looks like this:
>>>
 cat build-apple-swift.sh
>>> #RELEASE=swift-2.2.1-RELEASE
>>> RELEASE=swift-DEVELOPMENT-SNAPSHOT-2016-05-03-a
>>>
>>> #sudo port install cmake ninja
>>>
>>> mkdir apple-swift
>>> cd apple-swift
>>>
>>> NINJA_RELEASE=v1.7.1
>>> git clone https://github.com/ninja-build/ninja.git
>>> (cd ninja && git checkout tags/$NINJA_RELEASE && ./configure.py
>>> --bootstrap)
>>>
>>> git clone https://github.com/apple/swift.git
>>> (cd swift && utils/update-checkout --clone)
>>>
>>> for D in *; do
>>>   if [ -d "${D}" ]; then
>>> echo "checkout $RELEASE of ${D}"
>>> (cd ${D} && git checkout tags/$RELEASE)
>>>   fi
>>> done
>>>
>>> #set MACOSX_DEPLOYMENT_TARGET=10.9
>>>
>>> cd swift
>>> #utils/build-script -R
>>> utils/build-toolchain local.swift
>>>
>>> 
>>>
>>> I will find out if it works in an hour or so I guess
>>>
>>> -tim
>>>
>>> On 5/9/16, Jordan Rose  wrote:
 Hi, Tim. The build directory contains symlinks and such and therefore
 isn’t
 really the best vehicle for distribution. There’s a build-toolchain
 script
 inside swift/utils/ that should give you a self-contained directory,
 and
 more generally there’s a notion of “install components” that can be
 used
 to
 build a self-contained directory tree as an output of build-script.

 Hope that helps,
 Jordan


> On May 8, 2016, at 09:33, Tim Prepscius via swift-users
>  wrote:
>
> Is there any way I can get "import Foundation" working on a machine
> other than the machine I compiled with?
>
> I notice that those "float.h" headers are within the llvm build,
> however when I try to do -I of that directory it fails. (I tried as an
> include as a framework as an include passed to the compiler)..
>
> -tim
>
> On 5/7/16, Tim Prepscius  wrote:
>> Ok, so building is working
>> with the following script:
>>
>> more build-swift-script.sh
>> RELEASE=swift-2.2.1-RELEASE
>>
>> sudo port install cmake ninja
>>
>> mkdir apple-swift
>> cd apple-swift
>>
>> git clone https://github.com/apple/swift.git
>> (cd swift && utils/update-checkout --clone)
>>
>> for D in *; do
>>  if [ -d "${D}" ]; then
>>echo "checkout $RELEASE of ${D}"
>>(cd ${D} && git checkout tags/$RELEASE)

Re: [swift-users] swift redistributable without Xcode

2016-05-11 Thread Tim Prepscius via swift-users

Also,

So I build the thing, and I move over the swift directory to a
computer without Xcode.

I run bin/swift
and get:

swift-macosx-x86_64 tim$ bin/swift
***  You are running Swift's integrated REPL,  ***
***  intended for testing purposes only.   ***
***  The full REPL is built as part of LLDB.   ***
***  Type ':help' for assistance.  ***
(swift) import Foundation
:0: error: cannot load underlying module for 'CoreGraphics'
:0: note: did you forget to set an SDK using -sdk or SDKROOT?
:0: note: use "xcrun -sdk macosx swiftc" to select the
default OS X SDK installed with Xcode


I then guess the SDK would be:
./stdlib/public/SDK

so:
swift-macosx-x86_64 tim$
SDKROOT=/Users/tim/temp/swift-macosx-x86_64/stdlib/public/SDK
bin/swift
***  You are running Swift's integrated REPL,  ***
***  intended for testing purposes only.   ***
***  The full REPL is built as part of LLDB.   ***
***  Type ':help' for assistance.  ***
(swift) import Foundation
:0: error: cannot load underlying module for 'CoreGraphics'




Any ideas here?
Is there any known build where I can build swift, copy the build to
another OS X computer and run it?

Thanks,

-tim

On 5/11/16, Tim Prepscius  wrote:
> Ok,
>
> so when I build finally it:
> du -h -d 1
> 3.7M  ./cmark-macosx-x86_64
>  81M  ./llbuild-macosx-x86_64
> 5.6G  ./lldb-macosx-x86_64
> 7.9G  ./llvm-macosx-x86_64
>  18M  ./ninja-build
> 8.4G  ./swift-macosx-x86_64
>  47M  ./swiftpm-macosx-x86_64
>  22G  .
>
>
> 22 gigs is a bit much?
> Even the 8.4gigs for just the swift directory is a bit much.
>
> Am I running the wrong preset somehow?
> Should I be running a certain preset of the build-bot?
>
> -tim
>
>
> On 5/9/16, Tim Prepscius  wrote:
>> Thank you,
>>
>> Trying.
>>
>> utils/build-toolchain local.swift tries to use ninja which fails
>> so I go to the swift and see "git clone
>> g...@github.com:ninja-build/ninja.git && cd ninja" ...
>> which fails
>>
>> so I do:
>> git clone https://github.com/ninja-build/ninja.git
>>
>> and then I do git checkout release
>> like it says to
>>
>> but that creates a branch release
>> I'm guessing git checkout $RELEASE
>> where RELEASE=v1.7.1
>>
>>
>> my updated build swift script now looks like this:
>>
>>> cat build-apple-swift.sh
>> #RELEASE=swift-2.2.1-RELEASE
>> RELEASE=swift-DEVELOPMENT-SNAPSHOT-2016-05-03-a
>>
>> #sudo port install cmake ninja
>>
>> mkdir apple-swift
>> cd apple-swift
>>
>> NINJA_RELEASE=v1.7.1
>> git clone https://github.com/ninja-build/ninja.git
>> (cd ninja && git checkout tags/$NINJA_RELEASE && ./configure.py
>> --bootstrap)
>>
>> git clone https://github.com/apple/swift.git
>> (cd swift && utils/update-checkout --clone)
>>
>> for D in *; do
>>   if [ -d "${D}" ]; then
>> echo "checkout $RELEASE of ${D}"
>> (cd ${D} && git checkout tags/$RELEASE)
>>   fi
>> done
>>
>> #set MACOSX_DEPLOYMENT_TARGET=10.9
>>
>> cd swift
>> #utils/build-script -R
>> utils/build-toolchain local.swift
>>
>> 
>>
>> I will find out if it works in an hour or so I guess
>>
>> -tim
>>
>> On 5/9/16, Jordan Rose  wrote:
>>> Hi, Tim. The build directory contains symlinks and such and therefore
>>> isn’t
>>> really the best vehicle for distribution. There’s a build-toolchain
>>> script
>>> inside swift/utils/ that should give you a self-contained directory, and
>>> more generally there’s a notion of “install components” that can be used
>>> to
>>> build a self-contained directory tree as an output of build-script.
>>>
>>> Hope that helps,
>>> Jordan
>>>
>>>
 On May 8, 2016, at 09:33, Tim Prepscius via swift-users
  wrote:

 Is there any way I can get "import Foundation" working on a machine
 other than the machine I compiled with?

 I notice that those "float.h" headers are within the llvm build,
 however when I try to do -I of that directory it fails. (I tried as an
 include as a framework as an include passed to the compiler)..

 -tim

 On 5/7/16, Tim Prepscius  wrote:
> Ok, so building is working
> with the following script:
>
> more build-swift-script.sh
> RELEASE=swift-2.2.1-RELEASE
>
> sudo port install cmake ninja
>
> mkdir apple-swift
> cd apple-swift
>
> git clone https://github.com/apple/swift.git
> (cd swift && utils/update-checkout --clone)
>
> for D in *; do
>  if [ -d "${D}" ]; then
>echo "checkout $RELEASE of ${D}"
>(cd ${D} && git checkout tags/$RELEASE)
>  fi
> done
>
> cd swift
> utils/build-script -R
>
> ---
>
> however, running does not work.
> I move the entire build directory to another computer,
>
> I go into:
> build/Ninja-ReleaseAssert/swift-macosx-x86_64/bin
>
> And run:
> ./swift
> ***  You are running Swift's integrated REPL,  ***
> ***  intended

Re: [swift-users] SubSequence Index bug in generic functions?

2016-05-11 Thread Hooman Mehr via swift-users

Filed as: SR-1487 

> On May 11, 2016, at 1:51 PM, Dmitri Gribenko  wrote:
> 
> On Wed, May 11, 2016 at 1:48 PM, Hooman Mehr via swift-users
>  wrote:
>> The reason this is appearing here before filing a radar is getting a quick
>> feedback as I have been assuming this is the expected behavior but Nate Cook
>> told me otherwise. See this thread for the initial discussion that lead to
>> this.
> 
> Hi Hooman,
> 
> This is a bug in String indices.  Could you file it, we will look into it.
> 
> Dmitri
> 
> -- 
> main(i,j){for(i=2;;i++){for(j=2;j (j){printf("%d\n",i);}}} /*Dmitri Gribenko */

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

Re: [swift-users] SubSequence Index bug in generic functions?

2016-05-11 Thread Dmitri Gribenko via swift-users

On Wed, May 11, 2016 at 1:48 PM, Hooman Mehr via swift-users
 wrote:
> The reason this is appearing here before filing a radar is getting a quick
> feedback as I have been assuming this is the expected behavior but Nate Cook
> told me otherwise. See this thread for the initial discussion that lead to
> this.

Hi Hooman,

This is a bug in String indices.  Could you file it, we will look into it.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] SubSequence Index bug in generic functions?

2016-05-11 Thread Hooman Mehr via swift-users

The reason this is appearing here before filing a radar is getting a quick 
feedback as I have been assuming this is the expected behavior but Nate Cook 
told me otherwise. See this thread 

 for the initial discussion that lead to this.

Run this code to see the issue: (Works with the latest Swift 3.0 snapshot)

func subSequenceIndexBug



(_ c: C, _ e: C.Iterator.Element)
{
let junction = c.index(c.startIndex, offsetBy: numericCast(5)) // 
Arbitrary split point.

if let i = c.suffix(from: junction).index(of: e) {

print("Searched for \"\(e)\" and found \"\(c[i])\". Result of 
testing them for equality is: \(e == c[i])")
}
}

subSequenceIndexBug("ABCDEFGHIJKLMNOPQRSTUVWXYZ".characters, "Q")
// Prints: "Searched for "Q" and found "L". Result of testing them for 
equality is: false"

Is this a generics design limitation, my bug, or a compiler bug?

Thanks for your,
Hooman

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

Re: [swift-users] swift redistributable without Xcode

2016-05-11 Thread Tim Prepscius via swift-users

Ok,

so when I build finally it:
du -h -d 1
3.7M./cmark-macosx-x86_64
 81M./llbuild-macosx-x86_64
5.6G./lldb-macosx-x86_64
7.9G./llvm-macosx-x86_64
 18M./ninja-build
8.4G./swift-macosx-x86_64
 47M./swiftpm-macosx-x86_64
 22G.


22 gigs is a bit much?
Even the 8.4gigs for just the swift directory is a bit much.

Am I running the wrong preset somehow?
Should I be running a certain preset of the build-bot?

-tim


On 5/9/16, Tim Prepscius  wrote:
> Thank you,
>
> Trying.
>
> utils/build-toolchain local.swift tries to use ninja which fails
> so I go to the swift and see "git clone
> g...@github.com:ninja-build/ninja.git && cd ninja" ...
> which fails
>
> so I do:
> git clone https://github.com/ninja-build/ninja.git
>
> and then I do git checkout release
> like it says to
>
> but that creates a branch release
> I'm guessing git checkout $RELEASE
> where RELEASE=v1.7.1
>
>
> my updated build swift script now looks like this:
>
>> cat build-apple-swift.sh
> #RELEASE=swift-2.2.1-RELEASE
> RELEASE=swift-DEVELOPMENT-SNAPSHOT-2016-05-03-a
>
> #sudo port install cmake ninja
>
> mkdir apple-swift
> cd apple-swift
>
> NINJA_RELEASE=v1.7.1
> git clone https://github.com/ninja-build/ninja.git
> (cd ninja && git checkout tags/$NINJA_RELEASE && ./configure.py
> --bootstrap)
>
> git clone https://github.com/apple/swift.git
> (cd swift && utils/update-checkout --clone)
>
> for D in *; do
>   if [ -d "${D}" ]; then
> echo "checkout $RELEASE of ${D}"
> (cd ${D} && git checkout tags/$RELEASE)
>   fi
> done
>
> #set MACOSX_DEPLOYMENT_TARGET=10.9
>
> cd swift
> #utils/build-script -R
> utils/build-toolchain local.swift
>
> 
>
> I will find out if it works in an hour or so I guess
>
> -tim
>
> On 5/9/16, Jordan Rose  wrote:
>> Hi, Tim. The build directory contains symlinks and such and therefore
>> isn’t
>> really the best vehicle for distribution. There’s a build-toolchain
>> script
>> inside swift/utils/ that should give you a self-contained directory, and
>> more generally there’s a notion of “install components” that can be used
>> to
>> build a self-contained directory tree as an output of build-script.
>>
>> Hope that helps,
>> Jordan
>>
>>
>>> On May 8, 2016, at 09:33, Tim Prepscius via swift-users
>>>  wrote:
>>>
>>> Is there any way I can get "import Foundation" working on a machine
>>> other than the machine I compiled with?
>>>
>>> I notice that those "float.h" headers are within the llvm build,
>>> however when I try to do -I of that directory it fails. (I tried as an
>>> include as a framework as an include passed to the compiler)..
>>>
>>> -tim
>>>
>>> On 5/7/16, Tim Prepscius  wrote:
 Ok, so building is working
 with the following script:

 more build-swift-script.sh
 RELEASE=swift-2.2.1-RELEASE

 sudo port install cmake ninja

 mkdir apple-swift
 cd apple-swift

 git clone https://github.com/apple/swift.git
 (cd swift && utils/update-checkout --clone)

 for D in *; do
  if [ -d "${D}" ]; then
echo "checkout $RELEASE of ${D}"
(cd ${D} && git checkout tags/$RELEASE)
  fi
 done

 cd swift
 utils/build-script -R

 ---

 however, running does not work.
 I move the entire build directory to another computer,

 I go into:
 build/Ninja-ReleaseAssert/swift-macosx-x86_64/bin

 And run:
 ./swift
 ***  You are running Swift's integrated REPL,  ***
 ***  intended for testing purposes only.   ***
 ***  The full REPL is built as part of LLDB.   ***
 ***  Type ':help' for assistance.  ***
 (swift) import Foundation
 /usr/include/module.map:36:14: error: header 'float.h' not found
  header "float.h" // note: supplied by compiler
 ^
 /System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:11:10:
 note: submodule of top-level module 'Darwin' implicitly imported here
 #include 
 ^
 :1:9: note: in file included from :1:
 #import "Headers/CoreFoundation.h"
^
 /System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:12:10:
 error: 'stdarg.h' file not found
 #include 
 ^
 :0: error: could not build Objective-C module 'CoreFoundation'

 ---

 Any hints?

 -tim

 On 5/6/16, Tim Prepscius  wrote:
> This might be a bug in your tagging system:
>
> compiler-rt
> llbuild
> swift-corelibs-foundation
> swift-corelibs-libdispatch
> swift-corelibs-xctest
> swiftpm
>
> are missing the tag
> error: pathspec 'tags/swift-2.2.1-RELEASE' did not match any file(s)
> known to git.
>
> although they do have tags such as:
> swiftpm tprepscius$ git tag -l
>

[swift-users] Cross-Compiling For ARM Linux

2016-05-11 Thread Donald Pinckney via swift-users

 
 
Hi all,
 
Perhaps this has been discussed a lot already, but I'm a bit lost as to the 
current state of cross-compiling Swift source code from x86_64 Linux to ARM 
Linux.Given the documentation for cross-compiling for Android, it seems 
that there is some cross-compiling support, but I'm not sure how I should go 
about making it not Android specific.
 

 
To be more concrete,I would like to experiment with Swift for the FIRST 
Robotics Competition, which uses ARM Cortex A9, running Real-Time Linux.For 
now, a reasonable intermediate goal seems like figuring out cross-compiling to 
a Raspberry Pi, which has already seen some attention from the Swift community.
 

 
So, it would be awesome if anyone can point me in the right direction!
 

 
Thanks,
 
Donald Pinckney
 
 
 

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

Re: [swift-users] swiftc and CocoaPods modules

2016-05-11 Thread Marcel Rebouças via swift-users

I just realized the text formatting is wrong, sorry for that.

2016-05-09 11:17 GMT-03:00 Marcel Rebouças :

> Hello all,
>
> I'm trying to run the swiftc (a modified one) command in a project folder
> in order to compile all .swift files. It is currently working as follows:
>
> xcrun -sdk iphoneos build/Ninja-DebugAssert/swift-macosx-x86_64/bin/swiftc
> -dump-ast -target armv7-apple-ios7.0 **/*.swift
>
>
> Right now, it is able to find and compile all .swift files in the
> directories and subdirectories, and is able to import modules such as UIKit.
>
>
> However, I can't find a way to make it work with modules added through
> CocoaPods. This generates an error like:
>
>
> *Example/Source/DetailViewController.swift:23:8: **error: **no such
> module 'Alamofire'*
>
>
> Any thoughts?
>
>
> Thanks,
>
> Marcel
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Initializing a UIColor

2016-05-11 Thread Charles Lane via swift-users

I agree, however, I like your workaround better than all the extra parentheses 
and CGFloats!



> On May 11, 2016, at 10:37 AM, Erica Sadun  wrote:
> 
>> 
>>> On May 11, 2016, at 9:57 AM, Dennis Weissmann >> > wrote:
>>> 
>>> Huh! There’s a new overload for that initializer:
>>> 
>>> 
>>> 
>>> The one that takes CGFloats is the one that was there before, but the one 
>>> taking Floats is new!
>>> 
>>> You can work around like this:
>>> 
>>> let color = UIColor(red: CGFloat(0.892), green: CGFloat(0.609), blue: 
>>> CGFloat(0.048),  alpha: CGFloat(1.000))
>>> or
>>> let color = UIColor(red: Float(0.892), green: Float(0.609), blue: 
>>> Float(0.048),  alpha: Float(1.000))
>>> 
>>> - Dennis
> 
> 
> Wow, that's a ridiculous situation to have.  Who uses Float with iOS/tvOS 
> anyway? 
> 
> I created a workaround, but I hate it:
> 
> extension Double {
> var cg: CGFloat { return CGFloat(self) }
> }
> 
> class ViewController: UIViewController {
> override func viewDidLoad() {
> super.viewDidLoad()
> let c = UIColor(red: 0.5.cg, green: 0.5, blue: 0.5, alpha: 0.5)
> }
> }
> 
> -- E
> 

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

Re: [swift-users] Initializing a UIColor

2016-05-11 Thread Erica Sadun via swift-users

> 
>> On May 11, 2016, at 9:57 AM, Dennis Weissmann > > wrote:
>> 
>> Huh! There’s a new overload for that initializer:
>> 
>> 
>> 
>> The one that takes CGFloats is the one that was there before, but the one 
>> taking Floats is new!
>> 
>> You can work around like this:
>> 
>> let color = UIColor(red: CGFloat(0.892), green: CGFloat(0.609), blue: 
>> CGFloat(0.048),  alpha: CGFloat(1.000))
>> or
>> let color = UIColor(red: Float(0.892), green: Float(0.609), blue: 
>> Float(0.048),  alpha: Float(1.000))
>> 
>> - Dennis


Wow, that's a ridiculous situation to have.  Who uses Float with iOS/tvOS 
anyway? 

I created a workaround, but I hate it:

extension Double {
var cg: CGFloat { return CGFloat(self) }
}

class ViewController: UIViewController {
override func viewDidLoad() {
super.viewDidLoad()
let c = UIColor(red: 0.5.cg, green: 0.5, blue: 0.5, alpha: 0.5)
}
}

-- E

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

Re: [swift-users] Initializing a UIColor

2016-05-11 Thread Dennis Weissmann via swift-users

Huh! There’s a new overload for that initializer:



The one that takes CGFloats is the one that was there before, but the one 
taking Floats is new!

You can work around like this:

let color = UIColor(red: CGFloat(0.892), green: CGFloat(0.609), blue: 
CGFloat(0.048),  alpha: CGFloat(1.000))
or
let color = UIColor(red: Float(0.892), green: Float(0.609), blue: Float(0.048), 
 alpha: Float(1.000))

- Dennis

> On May 11, 2016, at 3:46 PM, Charles Lane via swift-users 
>  wrote:
> 
> The following code worked fine in previous development snapshots but fails in 
> the May 9, 2016 snapshot:
> 
>   let color = UIColor(red: 0.892, green: 0.609, blue: 0.048,  alpha: 
> 1.000)
> 
> Does anyone know whether this is a bug or if the syntax changed? (Yes, I 
> imported UIKit). Xcode gives an error of ‘Ambiguous use of 
> init(red:green:blue:alpha:)’
> 
> 
> ___
> 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] Initializing a UIColor

2016-05-11 Thread Charles Lane via swift-users

The following code worked fine in previous development snapshots but fails in 
the May 9, 2016 snapshot:

let color = UIColor(red: 0.892, green: 0.609, blue: 0.048,  alpha: 
1.000)

Does anyone know whether this is a bug or if the syntax changed? (Yes, I 
imported UIKit). Xcode gives an error of ‘Ambiguous use of 
init(red:green:blue:alpha:)’


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

Re: [swift-users] Initializing a UIColor

Re: [swift-users] swift redistributable without Xcode

Re: [swift-users] swift redistributable without Xcode

Re: [swift-users] SubSequence Index bug in generic functions?

Re: [swift-users] SubSequence Index bug in generic functions?

[swift-users] SubSequence Index bug in generic functions?

Re: [swift-users] swift redistributable without Xcode

[swift-users] Cross-Compiling For ARM Linux

Re: [swift-users] swiftc and CocoaPods modules

Re: [swift-users] Initializing a UIColor

Re: [swift-users] Initializing a UIColor

Re: [swift-users] Initializing a UIColor

[swift-users] Initializing a UIColor

13 matches

Site Navigation

Mail list logo

Footer information