/swift

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Port to Android #1442

Merged
merged 1 commit into from Apr 13, 2016
+592 −149

Conversation

Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
@modocache
Collaborator

modocache commented Feb 25, 2016

What's in this pull request?

This adds an Android target for the stdlib. It is also the first example of cross-compiling outside of Darwin: a Linux host machine builds for an Android target.

Relevant mailing list discussions:

  1. https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20151207/000171.html
  2. https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20151214/000492.html

The Android variant of Swift may be built and tested using the following build-script invocation:

$ utils/build-script \
  -R \                                           # Build in ReleaseAssert mode.
  -T \                                           # Run all tests.
  --android \                                    # Build for Android.
  --android-deploy-device-path /data/local/tmp \ # Temporary directory on the device where Android tests are run.
  --android-ndk ~/android-ndk-r10e \             # Path to an Android NDK.
  --android-ndk-version 21 \
  --android-icu-uc ~/libicu-android/armeabi-v7a/libicuuc.so \
  --android-icu-uc-include ~/libicu-android/armeabi-v7a/icu/source/common \
  --android-icu-i18n ~/libicu-android/armeabi-v7a/libicui18n.so \
  --android-icu-i18n-include ~/libicu-android/armeabi-v7a/icu/source/i18n/

Android builds have the following dependencies, as can be seen in the build script invocation:

  1. An Android NDK of version 21 or greater, available to download here: http://developer.android.com/ndk/downloads/index.html.
  2. A libicu compatible with android-armv7. You may build your own by cloning https://github.com/SwiftAndroid/libiconv-libicu-android and running the build.sh script in that repository.

What's worth discussing about this pull request?

Continuous integration: I'd be thrilled to have this merged into the main Swift repository, but I don't want to dump a bunch of code that no one can maintain. I think CI is a very important part of maintaining a healthy build, but:

  1. An Android-compatible build of libicu is necessary to build for Android.
  2. An Android device (or possibly emulator) is necessary to run the Android tests.

Do either of those sound like something CI servers could be configured with? Or can someone help me think of alternatives--perhaps building libicu as part of the Swift build, as we do with ninja? #1398 includes some pkg-config logic that may be useful here.

FIXMEs: There are quite a few spots labeled "FIXME" that I could use some help with. Feedback welcome!

Thanks a ton to @zhuowei, who deserves the vast majority of the credit. I just tweaked a few things. 😊
Show outdated Hide outdated stdlib/private/SwiftPrivateLibcExtras/Subprocess.swift
@1ace

This comment has been minimized.

Show comment
Hide comment
@1ace

1ace Feb 25, 2016

First off, thank you for this awesome work!
I haven't read much of it yet, but I just wanted to mention one thing: I think you should try to separate changes in multiple commits as much as possible to make it more digestible. That will help reviewers by letting them focus on related changes before moving on to the next commit.

My personal rule is: if you make sense to be between those two changes (ie. have one but not the other), put them in separate commits. You should obviously order those commits in a way that ensures you don't use features before adding them. For instance, the last commit should be the one adding the new target to utils/build-script once everything else is ready.

1ace commented Feb 25, 2016

First off, thank you for this awesome work!
I haven't read much of it yet, but I just wanted to mention one thing: I think you should try to separate changes in multiple commits as much as possible to make it more digestible. That will help reviewers by letting them focus on related changes before moving on to the next commit.

My personal rule is: if you make sense to be between those two changes (ie. have one but not the other), put them in separate commits. You should obviously order those commits in a way that ensures you don't use features before adding them. For instance, the last commit should be the one adding the new target to utils/build-script once everything else is ready.
Show outdated Hide outdated stdlib/public/Bionic/Glibc.swift
Show outdated Hide outdated stdlib/public/runtime/Errors.cpp
Show outdated Hide outdated stdlib/public/stubs/Stubs.cpp
Show outdated Hide outdated test/IRGen/report_dead_method_call.swift
Show outdated Hide outdated utils/android/adb/commands.py
@modocache

This comment has been minimized.

Show comment
Hide comment
@modocache

modocache Feb 25, 2016

Collaborator

Thanks for the feedback, @1ace! I agree: this work depends on #1396, #1410, #1426, #1395, #1334, which I've issued separately to make them easier to review. Unfortunately, GitHub falls apart with a dependent stack of commits, such as this pull request would end up being. I think you'll find other ports, such as Cygwin #1108, end up being similarly large.

The problem is that all of these changes are directly related to Android. Take the os(Android) definition, for example: I don't think it would make sense for the Swift maintainers to merge a pull request that added #if os(Android) ... #endif before Swift can even be built for Android. Phabricator would allow users to specify that the commit adding os(Android) is dependent upon the commit that adds Android options to CMakeLists.txt, and so forth. GitHub has no such system of specifying dependencies, and encourages large pull requests like this one.

Of course, if the review unearths more pieces I can split out into separate pull requests, I'll definitely do so! 👍
Collaborator

modocache commented Feb 25, 2016

Thanks for the feedback, @1ace! I agree: this work depends on #1396, #1410, #1426, #1395, #1334, which I've issued separately to make them easier to review. Unfortunately, GitHub falls apart with a dependent stack of commits, such as this pull request would end up being. I think you'll find other ports, such as Cygwin #1108, end up being similarly large.

The problem is that all of these changes are directly related to Android. Take the os(Android) definition, for example: I don't think it would make sense for the Swift maintainers to merge a pull request that added #if os(Android) ... #endif before Swift can even be built for Android. Phabricator would allow users to specify that the commit adding os(Android) is dependent upon the commit that adds Android options to CMakeLists.txt, and so forth. GitHub has no such system of specifying dependencies, and encourages large pull requests like this one.

Of course, if the review unearths more pieces I can split out into separate pull requests, I'll definitely do so! 👍
Show outdated Hide outdated validation-test/stdlib/CollectionType.swift.gyb
Show outdated Hide outdated validation-test/stdlib/String.swift
@avaidyam

This comment has been minimized.

Show comment
Hide comment
@avaidyam

avaidyam Feb 25, 2016

@modocache @zhuowei @ephemer Awesome job! I've been watching this since possibly day one. 👍 :shipit: 😄

avaidyam commented Feb 25, 2016

@modocache @zhuowei @ephemer Awesome job! I've been watching this since possibly day one. 👍 :shipit: 😄
Show outdated Hide outdated utils/android/adb_test_runner/main.py
Show outdated Hide outdated stdlib/public/runtime/ProtocolConformance.cpp
Show outdated Hide outdated stdlib/private/StdlibUnittest/StdlibUnittest.swift.gyb
Show outdated Hide outdated lib/Driver/ToolChains.cpp
Show outdated Hide outdated lib/Driver/ToolChains.cpp
Show outdated Hide outdated lib/Driver/ToolChains.cpp
lib/Basic/LangOptions.cpp
@@ -105,6 +106,8 @@ std::pair<bool, bool> LangOptions::setTarget(llvm::Triple triple) {
addPlatformConditionValue("os", "watchOS");
else if (triple.isiOS())
addPlatformConditionValue("os", "iOS");
else if (triple.isAndroid())
addPlatformConditionValue("os", "Android");

This comment has been minimized.

Show comment
Hide comment
@gribozavr

gribozavr Feb 25, 2016

Collaborator

This change needs a test like test/Parse/ConditionalCompilation/x64FreeBSDTarget.swift for each supported triple.
Copy URL
@gribozavr

gribozavr Feb 25, 2016

Collaborator

This change needs a test like test/Parse/ConditionalCompilation/x64FreeBSDTarget.swift for each supported triple.

This comment has been minimized.

Show comment
Hide comment
@modocache

modocache Mar 14, 2016

Collaborator

Done! I added test/Parse/ConditionalCompilation/armAndroidTarget.swift.
Copy URL
@modocache

modocache Mar 14, 2016

Collaborator

Done! I added test/Parse/ConditionalCompilation/armAndroidTarget.swift.
@gribozavr

This comment has been minimized.

Show comment
Hide comment
@gribozavr

gribozavr Feb 25, 2016

Collaborator

@swift-ci Please smoke test
Collaborator

gribozavr commented Feb 25, 2016

@swift-ci Please smoke test
@gribozavr

This comment has been minimized.

Show comment
Hide comment
@gribozavr

gribozavr Feb 25, 2016

Collaborator

@modocache There seem to be build issues on Linux x86_64, please take a look when you have a moment.
Collaborator

gribozavr commented Feb 25, 2016

@modocache There seem to be build issues on Linux x86_64, please take a look when you have a moment.
@jckarter

This comment has been minimized.

Show comment
Hide comment
@jckarter

jckarter Feb 25, 2016

Member

Looks like <mutex> is missing from the target C++ standard library:

In file included from /home/buildnode/jenkins/workspace/swift-PR-Linux/swift/stdlib/public/runtime/HeapObject.cpp:17:
/home/buildnode/jenkins/workspace/swift-PR-Linux/swift/include/swift/Basic/Lazy.h:19:10: fatal error: 'mutex' file not found
#include <mutex>
         ^
Member

jckarter commented Feb 25, 2016

Looks like <mutex> is missing from the target C++ standard library:

In file included from /home/buildnode/jenkins/workspace/swift-PR-Linux/swift/stdlib/public/runtime/HeapObject.cpp:17:
/home/buildnode/jenkins/workspace/swift-PR-Linux/swift/include/swift/Basic/Lazy.h:19:10: fatal error: 'mutex' file not found
#include <mutex>
         ^
@DCRichards

This comment has been minimized.

Show comment
Hide comment
@DCRichards

DCRichards Feb 25, 2016

this is really cool, I've never seen a 52 file change commit though, good lord!

DCRichards commented Feb 25, 2016

this is really cool, I've never seen a 52 file change commit though, good lord!
@modocache

This comment has been minimized.

Show comment
Hide comment
@modocache

modocache Feb 25, 2016

Collaborator

I'm working on addressing the feedback--thanks so much for the review, @gribozavr!

In the meantime, if anyone out there wants to help with this pull request, here's the output from the test suite: https://gist.github.com/modocache/48babfa768d495806116. Six tests are failing.

Some of those failures, like IRGen/objc_simd.sil, could be addressed outside of this pull request (for that test specifically, check out some of my notes in SwiftAndroid#16).
Collaborator

modocache commented Feb 25, 2016

I'm working on addressing the feedback--thanks so much for the review, @gribozavr!

In the meantime, if anyone out there wants to help with this pull request, here's the output from the test suite: https://gist.github.com/modocache/48babfa768d495806116. Six tests are failing.

Some of those failures, like IRGen/objc_simd.sil, could be addressed outside of this pull request (for that test specifically, check out some of my notes in SwiftAndroid#16).
@lattner

This comment has been minimized.

Show comment
Hide comment
@lattner

lattner Feb 25, 2016

Collaborator

@modocache This is really awesome to see, thank you for working on it. Per the previous comment, if you can split this up into smaller PR's, that will make it easier to review and merge piecemeal.
Collaborator

lattner commented Feb 25, 2016

@modocache This is really awesome to see, thank you for working on it. Per the previous comment, if you can split this up into smaller PR's, that will make it easier to review and merge piecemeal.
@practicalswift

This comment has been minimized.

Show comment
Hide comment
@practicalswift

practicalswift Feb 25, 2016

Collaborator

@modocache Excellent stuff! Keep those great contributions coming 👍
Collaborator

practicalswift commented Feb 25, 2016

@modocache Excellent stuff! Keep those great contributions coming 👍
@unsign3d

This comment has been minimized.

Show comment
Hide comment
@unsign3d

unsign3d Feb 25, 2016

Excellent work, I'm looking forword to use it o.o

unsign3d commented Feb 25, 2016

Excellent work, I'm looking forword to use it o.o
@b3ll

This comment has been minimized.

Show comment
Hide comment
@b3ll

b3ll Feb 26, 2016

🎉

Keep up the great work @modocache! :D

b3ll commented Feb 26, 2016

🎉

Keep up the great work @modocache! :D
@pbassut

This comment has been minimized.

Show comment
Hide comment
@pbassut

pbassut Feb 26, 2016

Great work! @modocache

pbassut commented Feb 26, 2016

Great work! @modocache
@domdomegg

This comment has been minimized.

Show comment
Hide comment
@domdomegg

domdomegg Feb 27, 2016

Good work @modocache

domdomegg commented Feb 27, 2016

Good work @modocache

@modocache modocache referenced this pull request Feb 28, 2016

Merged

Refactor code duplication in inspecting dylibs #1466

0 of 1 task complete

@at15 at15 referenced this pull request Feb 29, 2016

Closed

Weekly for 2016/03/02 #11

1 of 2 tasks complete
@modocache

This comment has been minimized.

Show comment
Hide comment
@modocache

modocache Mar 1, 2016

Collaborator

For those following this pull request:

  • I'm busy with other stuff this week, but will address feedback (like splitting this up) next week.
  • In the meantime, I'll rebase this work onto apple/swift master each morning (US time), and confirm it all still works for me.
  • If you'd like to help me address feedback, send pull requests to SwiftAndroid/swift's master branch.
  • I don't mind +1 comments, but not everyone likes them. Let's hold off on those! 😅
Collaborator

modocache commented Mar 1, 2016

For those following this pull request:

  • I'm busy with other stuff this week, but will address feedback (like splitting this up) next week.
  • In the meantime, I'll rebase this work onto apple/swift master each morning (US time), and confirm it all still works for me.
  • If you'd like to help me address feedback, send pull requests to SwiftAndroid/swift's master branch.
  • I don't mind +1 comments, but not everyone likes them. Let's hold off on those! 😅
@JesseScott

This comment has been minimized.

Show comment
Hide comment
@JesseScott

JesseScott Mar 3, 2016

Enough congratulations people! I'm as excited about this as anyone, but either offer to help or stop spamming this issue with 👍 's ...

JesseScott commented Mar 3, 2016

Enough congratulations people! I'm as excited about this as anyone, but either offer to help or stop spamming this issue with 👍 's ...

@modocache modocache referenced this pull request Mar 7, 2016

Closed

Enable cross-compiling #1398

@gribozavr

This comment has been minimized.

Show comment
Hide comment
@gribozavr

gribozavr Mar 10, 2016

Collaborator

Here I've decided to:

  1. Remove the #define uselocale(a), since that function is available on API 21 (which this work is now based upon).
  2. Convert tabs to spaces.
  3. Preserve the definitions of strtod_l and friends here, since they're unavailable on Android.

Does that sound reasonable? Of course we can always improve upon this in the future.

SGTM! Thanks, @modocache!
Collaborator

gribozavr commented Mar 10, 2016

Here I've decided to:

  1. Remove the #define uselocale(a), since that function is available on API 21 (which this work is now based upon).
  2. Convert tabs to spaces.
  3. Preserve the definitions of strtod_l and friends here, since they're unavailable on Android.

Does that sound reasonable? Of course we can always improve upon this in the future.

SGTM! Thanks, @modocache!

modocache added a commit to modocache/swift that referenced this pull request Mar 14, 2016

@modocache
[Glibc] Configure modulemap for target, not host 
The current Glibc CMakeLists.txt uses the host machine to determine
which modulemap to use. The same modulemap can't be used for all
platforms because headers are available in different locations on
different platforms.

Using the host machine to determine which modulemap to configure and
place at a specific path in the resource dir is fine, so long as:

1. Only one Glibc is being compiled in a single CMake invocation.
2. The target machine needs the same modulemap as the host.

apple#1442 violates both of these
assumptions: the Glibc module for both Linux and Android is compiled
at the same time, and the Android target can't use the Linux modulemap.

This commit instead uses the target(s) to determine which
modulemap to use. The modulemap is configured and placed in an OS-
and architecture-specific directory in the resource dir. The path to
that modulemap is referenced by the ClangImporter (since it is no
longer at a path that is automatically discovered as an implicit
modulemap).

`lldb-import-test` does not appear to pass a valid target triple to
ClangImporter, so we disable tests that use it outside of OS X.
2766687

@modocache modocache referenced this pull request Mar 14, 2016

Merged

[Glibc] Configure modulemap for target, not host #1679

0 of 1 task complete

modocache added a commit to modocache/swift that referenced this pull request Mar 14, 2016

@modocache
[Glibc] Configure modulemap for target, not host 
The current Glibc CMakeLists.txt uses the host machine to determine
which modulemap to use. The same modulemap can't be used for all
platforms because headers are available in different locations on
different platforms.

Using the host machine to determine which modulemap to configure and
place at a specific path in the resource dir is fine, so long as:

1. Only one Glibc is being compiled in a single CMake invocation.
2. The target machine needs the same modulemap as the host.

apple#1442 violates both of these
assumptions: the Glibc module for both Linux and Android is compiled
at the same time, and the Android target can't use the Linux modulemap.

This commit instead uses the target(s) to determine which
modulemap to use. The modulemap is configured and placed in an OS-
and architecture-specific directory in the resource dir. The path to
that modulemap is referenced by the ClangImporter (since it is no
longer at a path that is automatically discovered as an implicit
modulemap).

`lldb-import-test` does not appear to pass a valid target triple to
ClangImporter, so we disable tests that use it outside of OS X.
b62940d

modocache added a commit to SwiftAndroid/swift that referenced this pull request Mar 14, 2016

@modocache
[Glibc] Configure modulemap for target, not host 
The current Glibc CMakeLists.txt uses the host machine to determine
which modulemap to use. The same modulemap can't be used for all
platforms because headers are available in different locations on
different platforms.

Using the host machine to determine which modulemap to configure and
place at a specific path in the resource dir is fine, so long as:

1. Only one Glibc is being compiled in a single CMake invocation.
2. The target machine needs the same modulemap as the host.

apple#1442 violates both of these
assumptions: the Glibc module for both Linux and Android is compiled
at the same time, and the Android target can't use the Linux modulemap.

This commit instead uses the target(s) to determine which
modulemap to use. The modulemap is configured and placed in an OS-
and architecture-specific directory in the resource dir. The path to
that modulemap is referenced by the ClangImporter (since it is no
longer at a path that is automatically discovered as an implicit
modulemap).

`lldb-import-test` does not appear to pass a valid target triple to
ClangImporter, so we disable tests that use it outside of OS X.
03a8623

modocache added a commit to SwiftAndroid/swift that referenced this pull request Mar 14, 2016

@modocache
[Glibc] Configure modulemap for target, not host 
The current Glibc CMakeLists.txt uses the host machine to determine
which modulemap to use. The same modulemap can't be used for all
platforms because headers are available in different locations on
different platforms.

Using the host machine to determine which modulemap to configure and
place at a specific path in the resource dir is fine, so long as:

1. Only one Glibc is being compiled in a single CMake invocation.
2. The target machine needs the same modulemap as the host.

apple#1442 violates both of these
assumptions: the Glibc module for both Linux and Android is compiled
at the same time, and the Android target can't use the Linux modulemap.

This commit instead uses the target(s) to determine which
modulemap to use. The modulemap is configured and placed in an OS-
and architecture-specific directory in the resource dir. The path to
that modulemap is referenced by the ClangImporter (since it is no
longer at a path that is automatically discovered as an implicit
modulemap).

`lldb-import-test` does not appear to pass a valid target triple to
ClangImporter, so we disable tests that use it outside of OS X.
85d41ec
@phasuksmit

This comment has been minimized.

Show comment
Hide comment
@phasuksmit

phasuksmit Apr 13, 2016

just 'wow'

phasuksmit commented Apr 13, 2016

just 'wow'
@jblorenzo

This comment has been minimized.

Show comment
Hide comment
@jblorenzo

jblorenzo Apr 13, 2016

very promising 👍

jblorenzo commented Apr 13, 2016

very promising 👍
@GreyEcologist

This comment has been minimized.

Show comment
Hide comment
@GreyEcologist

GreyEcologist Apr 13, 2016

congrats! This is exciting stuff!

GreyEcologist commented Apr 13, 2016

congrats! This is exciting stuff!
@ephemer

This comment has been minimized.

Show comment
Hide comment
@ephemer

ephemer Apr 13, 2016

@modocache @zhuowei @jrose-apple @gribozavr thank you all for your awesome work, looking forward to continuing with this

ephemer commented Apr 13, 2016

@modocache @zhuowei @jrose-apple @gribozavr thank you all for your awesome work, looking forward to continuing with this
@rileytestut

This comment has been minimized.

Show comment
Hide comment
@rileytestut

rileytestut Apr 13, 2016

Amazing!!

rileytestut commented Apr 13, 2016

Amazing!!
@zakrid

This comment has been minimized.

Show comment
Hide comment
@zakrid

zakrid Apr 13, 2016

Absolutely terrific work from everyone involved!

zakrid commented Apr 13, 2016

Absolutely terrific work from everyone involved!
@freak4pc

This comment has been minimized.

Show comment
Hide comment
@freak4pc

freak4pc Apr 13, 2016

Incredible effort from all! Beautiful work! Looking forward to seeing this move further.

freak4pc commented Apr 13, 2016

Incredible effort from all! Beautiful work! Looking forward to seeing this move further.
@kleinlieu

This comment has been minimized.

Show comment
Hide comment
@kleinlieu

kleinlieu Apr 13, 2016

Wow, we just witnessed history in the making.

kleinlieu commented Apr 13, 2016

Wow, we just witnessed history in the making.
@zakrid

This comment has been minimized.

Show comment
Hide comment
@zakrid

zakrid Apr 13, 2016

@kleinlieu true! Watch the media/news pick this up in a few days and milk it for weeks 😄

zakrid commented Apr 13, 2016

@kleinlieu true! Watch the media/news pick this up in a few days and milk it for weeks 😄
@wxyyxc1992

This comment has been minimized.

Show comment
Hide comment
@wxyyxc1992

wxyyxc1992 Apr 14, 2016

Anticipated

wxyyxc1992 commented Apr 14, 2016

Anticipated
@lovemo

This comment has been minimized.

Show comment
Hide comment
@lovemo

lovemo Apr 14, 2016

great

lovemo commented Apr 14, 2016

great
@kiban18

This comment has been minimized.

Show comment
Hide comment
@kiban18

kiban18 Apr 14, 2016

Amazing!!

kiban18 commented Apr 14, 2016

Amazing!!
@vapor99

This comment has been minimized.

Show comment
Hide comment
@vapor99

vapor99 Apr 14, 2016

Whoah! Very nice!

vapor99 commented Apr 14, 2016

Whoah! Very nice!
@Ir1d

This comment has been minimized.

Show comment
Hide comment
@Ir1d

Ir1d Apr 14, 2016

Congrats!

Ir1d commented Apr 14, 2016

Congrats!
@wangxuguo

This comment has been minimized.

Show comment
Hide comment
@wangxuguo

wangxuguo Apr 14, 2016

I'm out?

wangxuguo commented Apr 14, 2016

I'm out?
@kewang

This comment has been minimized.

Show comment
Hide comment
@kewang

kewang Apr 14, 2016

Today's Big Thing !!!

  1. Kobe last game
  2. Warriors 73 wins
  3. Swift accepted "Port to Android" PR

kewang commented Apr 14, 2016

Today's Big Thing !!!

  1. Kobe last game
  2. Warriors 73 wins
  3. Swift accepted "Port to Android" PR
@cHaLkdusT

This comment has been minimized.

Show comment
Hide comment
@cHaLkdusT

cHaLkdusT Apr 14, 2016

This is exciting!

cHaLkdusT commented Apr 14, 2016

This is exciting!
@meeDamian

This comment has been minimized.

Show comment
Hide comment
@meeDamian

meeDamian Apr 14, 2016

Unsubscribbling, because spam. Can someone close, to pipe comments into, comfortably silent, reaction emojis? Also, fantastic work!

meeDamian commented Apr 14, 2016

Unsubscribbling, because spam. Can someone close, to pipe comments into, comfortably silent, reaction emojis? Also, fantastic work!
@JingweiWang

This comment has been minimized.

Show comment
Hide comment
@JingweiWang

JingweiWang Apr 14, 2016

OMG, I think I must to learn Swift.

JingweiWang commented Apr 14, 2016

OMG, I think I must to learn Swift.
@yichengchen

This comment has been minimized.

Show comment
Hide comment
@yichengchen

yichengchen Apr 14, 2016

Exciting！

yichengchen commented Apr 14, 2016

Exciting！
@nolim1t

This comment has been minimized.

Show comment
Hide comment
@nolim1t

nolim1t Apr 14, 2016

Good work @modocache

nolim1t commented Apr 14, 2016

Good work @modocache
@consbulaquena

This comment has been minimized.

Show comment
Hide comment
@consbulaquena

consbulaquena Apr 14, 2016

Congratulations!

consbulaquena commented Apr 14, 2016

Congratulations!
@nishantpractoios

This comment has been minimized.

Show comment
Hide comment
@nishantpractoios

nishantpractoios Apr 14, 2016

Exciting !

nishantpractoios commented Apr 14, 2016

Exciting !
@AlwaysTyping

This comment has been minimized.

Show comment
Hide comment
@AlwaysTyping

AlwaysTyping Apr 14, 2016

66666666666

AlwaysTyping commented Apr 14, 2016

66666666666
@rafaelwkerr

This comment has been minimized.

Show comment
Hide comment
@rafaelwkerr

rafaelwkerr Apr 14, 2016

Awesome

rafaelwkerr commented Apr 14, 2016

Awesome
@conqueror

This comment has been minimized.

Show comment
Hide comment
@conqueror

conqueror Apr 14, 2016

Great news 👍

conqueror commented Apr 14, 2016

Great news 👍
@shige0501

This comment has been minimized.

Show comment
Hide comment
@shige0501

shige0501 Apr 15, 2016

Good job!

shige0501 commented Apr 15, 2016

Good job!
@swiftc-org

This comment has been minimized.

Show comment
Hide comment
@swiftc-org

swiftc-org Apr 15, 2016

Nice work!

swiftc-org commented Apr 15, 2016

Nice work!
@Geno1024

This comment has been minimized.

Show comment
Hide comment
@Geno1024

Geno1024 Apr 15, 2016

Excellent!

Geno1024 commented Apr 15, 2016

Excellent!
@dodola

This comment has been minimized.

Show comment
Hide comment
@dodola

dodola Apr 15, 2016

👍 Excellent

dodola commented Apr 15, 2016

👍 Excellent

@icepy icepy referenced this pull request Apr 16, 2016

Closed

Swift的期待 #35

@AniOSDeveloper

This comment has been minimized.

Show comment
Hide comment
@AniOSDeveloper

AniOSDeveloper Apr 16, 2016

Good job!

AniOSDeveloper commented Apr 16, 2016

Good job!
@ray26

This comment has been minimized.

Show comment
Hide comment
@ray26

ray26 Apr 16, 2016

6666

ray26 commented Apr 16, 2016

6666
@andrekandore

This comment has been minimized.

Show comment
Hide comment
@andrekandore

andrekandore Apr 16, 2016

😎 Nice

andrekandore commented Apr 16, 2016

😎 Nice
@justinoboyle

This comment has been minimized.

Show comment
Hide comment
@justinoboyle

justinoboyle Apr 17, 2016

Great work.

justinoboyle commented Apr 17, 2016

Great work.
@otymartin

This comment has been minimized.

Show comment
Hide comment
@otymartin

otymartin Apr 17, 2016

I just want to put my mark on this😎

otymartin commented Apr 17, 2016 •
edited
Edited 1 time
  • @otymartin otymartin edited Apr 17, 2016 (most recent)

I just want to put my mark on this😎
@istx25

This comment has been minimized.

Show comment
Hide comment
@istx25

istx25 Apr 18, 2016

Wow! Fantastic news. I'm excited to play around with this. Congrats to everyone involved. Your work is appreciated. 👏🏼👏🏼

istx25 commented Apr 18, 2016

Wow! Fantastic news. I'm excited to play around with this. Congrats to everyone involved. Your work is appreciated. 👏🏼👏🏼
@chenp-fjnu

This comment has been minimized.

Show comment
Hide comment
@chenp-fjnu

chenp-fjnu Apr 19, 2016

It's one very good new for developers, for many companies, they have IOS and Android version for every application, it will reduce the effort. Xamarin is another option, but Linux based system should support swift well. I love Swift. Wish it will become usable for real case soon.

chenp-fjnu commented Apr 19, 2016 •
edited
Edited 1 time
  • @chenp-fjnu chenp-fjnu edited Apr 19, 2016 (most recent)

It's one very good new for developers, for many companies, they have IOS and Android version for every application, it will reduce the effort. Xamarin is another option, but Linux based system should support swift well. I love Swift. Wish it will become usable for real case soon.
@refinedKing

This comment has been minimized.

Show comment
Hide comment
@refinedKing

refinedKing Apr 19, 2016

Good Job !!!

refinedKing commented Apr 19, 2016

Good Job !!!

@apple apple locked and limited conversation to collaborators Apr 19, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.