Re: [swift-dev] Swift port to Windows : Offering help!

2016-04-27 Thread Han via swift-dev 
I was busy. Before cleaning build procedure, I merged recent snapshot, and 
resolving conflict,  followed up some bug, modified and checked Cygwin build. 
Now in cleaning build procedure for MSVC, I decided to change the cmake 
generator to Ninja from MSBuild - it is more faster when recompiling.

It will be finished in soon. But don't expect too much, ... you should use hexa 
editor to build the static library.

- Han Sangjin

2016. 4. 28. 6:09 Joel Van Eenwyk  :

> Hi Han,
> 
>  
> 
> I’ve synced and ready to help out on this.
> 
>  
> 
> “For building MSVC port, it will be better waiting several days until I 
> prepare a draft build manual - current build description is too dirty 
> (/misc/Build_msvc.txt).”
> 
>  
> 
> Any updates on this?
> 
> 
> 
> --Joel
> 
>  
> 
> From: Shawn Erickson [mailto:shaw...@gmail.com] 
> Sent: Friday, April 22, 2016 8:27 AM
> To: Sangjin Han ; Joel Van Eenwyk 
> 
> Cc: swift-dev 
> Subject: Re: [swift-dev] Swift port to Windows : Offering help!
> 
>  
> 
> Trying to get back on PR1950 today.. fighting to get things building again 
> after a recent update-checkout.
> 
>  
> 
> -Shawn
> 
> On Thu, Apr 21, 2016 at 7:18 PM Sangjin Han via swift-dev 
>  wrote:
> 
> Hi Joel,
> 
>  
> 
> I list some URLs.
> 
>  
> 
> Bug/Feature report in http://bugs.swift.org
> 
> ---
> 
> SR-34 Port Swift to Windows (https://bugs.swift.org/browse/SR-34)
> 
> SR-612 In Cygwin port, print() crashed at hook 
> (https://bugs.swift.org/browse/SR-612)
> 
> SR-1128 autolink extraction does not work on Cygwin 
> (https://bugs.swift.org/browse/SR-1128)
> 
> SR-1131 Build script for MSVC on Windows 
> (https://bugs.swift.org/browse/SR-1131)
> 
>  
> 
>  
> 
> Pull Requsts in http://github.com/apple/swift 
> 
> -
> 
> [stdlib/msvc] Runtime with MSVC library 
> (https://github.com/apple/swift/pull/1918)
> 
> -- Currently working on. Waiting passing PR #1950.
> 
>  
> 
> [swiftc/msvc] Compiling with MSVC library 
> (https://github.com/apple/swift/pull/1516)
> 
> -- Waiting some more opinions or reviews.
> 
>  
> 
> [runtime] enhanced and refactored recently added Mutex abstraction 
> (https://github.com/apple/swift/pull/1950)
> 
> -- This is not about porting, but it enhances portability by removing POSIX 
> pthread. After merging, PR #1918 will be more simpler.
> 
>  
> 
> IRGen: add support for DLL Storage semantics 
> (https://github.com/apple/swift/pull/2080)
> 
> -- I think this is the most important topic for Windows/MSVC porting, but not 
> Cygwin port.
> 
>  
> 
>  
> 
> Issues in Mailing list
> 
> --
> 
> Subject: "swift (ABI) and Windows" in 
> https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160404/subject.html 
> and  
> https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160411/subject.html 
> 
>  
> 
> Subject: "long double usage in swift" in 
> https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160321/subject.html
> 
>  
> 
>  
> 
> My Repo for Patch
> 
> -
> 
> Repository: 
> https://github.com/tinysun212/swift-windows/tree/upstream-with-windows
> 
> binary for MSVC: 
> https://github.com/tinysun212/swift-windows/releases/tag/swift-msvc-20160418
> 
> binary for Cygwin: 
> https://github.com/tinysun212/swift-windows-bin/tree/master/swift-cygwin
> 
>  
> 
>  
> 
> Help
> 
> 
> 
> If you are also interested in Cygwin port, it is also very helpful to 
> verify/check the build manual (it is placed at /BUILD-CYGWIN-64.md in root of 
> my repo), so that we make a PR for master, and everyone build the Cygwin port 
> without my forked repo.
> 
>  
> 
> For building MSVC port, it will be better waiting several days until I 
> prepare a draft build manual - current build description is too dirty 
> (/misc/Build_msvc.txt).
> 
>  
> 
> If you once run the compilers, you can see they are lack compared to Linux or 
> OS X.
> 
>  
> 
> All of that is only on swift port. For swift-lldb, swift-corelibs-foundation, 
> swift-corelibs-libdispatch, I have not touched at all.
> 
>  
> 
> Han Sangjin
> 
>  
> 
> 2016-04-22 8:20 GMT+09:00 Joel Van Eenwyk :
> 
> Hi Han,
> 
>  
> 
> Thanks for the details! Do you have a custom fork or branch with these 
> changes? I'd love to be able to test this out and contribute if you think 
> that could help you out. I can get started on testing what you have now as 
> soon as tomorrow.
> 
>  
> 
> Cheers,
> 
>  
> 
> --Joel
> 
>  
> 
> On Thu, Apr 21, 2016 at 4:15 PM, Sangjin Han via swift-dev 
>  wrote:
> 
>  
> 
> I'm writing code for Windows/Cygwin port on my free time. There is no well 
> documented information about that. Instead I'll give you some information and 
> several links for you.
> 
>  
> 
> 1. Cygwin port
> 
>   Cygwin is a POSIX environment on Windows.

[swift-dev] swift-3.0-branch to be made; details to be announced soon

2016-04-27 Thread Ted Kremenek via swift-dev 
Hi everyone,

We’re going to create a "swift-3.0-branch" branch across the various Swift 
repositories within the next couple days.  The branch will be used to provide a 
more stable baseline for producing qualified snapshots for Swift 3.  With a 
large number of Swift 3 changes having landed the idea is to provide more 
qualified downloads — probably called “developer previews” or something of that 
nature — that will be available for those interested in playing with Swift 3 
but not wanting to pull just the latest snapshots from master.  I’ll post 
details on how this branch will be managed via a blog post in the next couple 
days.  For the time being, you can just ignore it — but I wanted to give 
everyone a heads up on why it was there.

Ted___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Swift port to Windows : Offering help!

2016-04-27 Thread Joel Van Eenwyk via swift-dev 
Hi Han,



I’ve synced and ready to help out on this.



“For building MSVC port, it will be better waiting several days until I
prepare a draft build manual - current build description is too dirty (/misc
/Build_msvc.txt).”



Any updates on this?


--Joel



*From:* Shawn Erickson [mailto:shaw...@gmail.com]
*Sent:* Friday, April 22, 2016 8:27 AM
*To:* Sangjin Han ; Joel Van Eenwyk <
joel.vaneen...@gmail.com>
*Cc:* swift-dev 
*Subject:* Re: [swift-dev] Swift port to Windows : Offering help!



Trying to get back on PR1950 today.. fighting to get things building again
after a recent update-checkout.



-Shawn

On Thu, Apr 21, 2016 at 7:18 PM Sangjin Han via swift-dev <
swift-dev@swift.org> wrote:

Hi Joel,



I list some URLs.



Bug/Feature report in http://bugs.swift.org

---

SR-34 Port Swift to Windows (https://bugs.swift.org/browse/SR-34)

SR-612 In Cygwin port, print() crashed at hook (
https://bugs.swift.org/browse/SR-612)

SR-1128 autolink extraction does not work on Cygwin (
https://bugs.swift.org/browse/SR-1128)

SR-1131 Build script for MSVC on Windows (
https://bugs.swift.org/browse/SR-1131)





Pull Requsts in http://github.com/apple/swift

-

[stdlib/msvc] Runtime with MSVC library (
https://github.com/apple/swift/pull/1918)

-- Currently working on. Waiting passing PR #1950.



[swiftc/msvc] Compiling with MSVC library (
https://github.com/apple/swift/pull/1516)

-- Waiting some more opinions or reviews.



[runtime] enhanced and refactored recently added Mutex abstraction (
https://github.com/apple/swift/pull/1950)

-- This is not about porting, but it enhances portability by removing POSIX
pthread. After merging, PR #1918 will be more simpler.



IRGen: add support for DLL Storage semantics (
https://github.com/apple/swift/pull/2080)

-- I think this is the most important topic for Windows/MSVC porting, but
not Cygwin port.





Issues in Mailing list

--

Subject: "swift (ABI) and Windows" in
https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160404/subject.html
and
https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160411/subject.html




Subject: "long double usage in swift" in
https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160321/subject.html





My Repo for Patch

-

Repository:
https://github.com/tinysun212/swift-windows/tree/upstream-with-windows

binary for MSVC:
https://github.com/tinysun212/swift-windows/releases/tag/swift-msvc-20160418

binary for Cygwin:
https://github.com/tinysun212/swift-windows-bin/tree/master/swift-cygwin





Help



If you are also interested in Cygwin port, it is also very helpful to
verify/check the build manual (it is placed at /BUILD-CYGWIN-64.md in root
of my repo), so that we make a PR for master, and everyone build the Cygwin
port without my forked repo.



For building MSVC port, it will be better waiting several days until I
prepare a draft build manual - current build description is too dirty
(/misc/Build_msvc.txt).



If you once run the compilers, you can see they are lack compared to Linux
or OS X.



All of that is only on swift port. For swift-lldb,
swift-corelibs-foundation, swift-corelibs-libdispatch, I have not touched
at all.



Han Sangjin



2016-04-22 8:20 GMT+09:00 Joel Van Eenwyk :

Hi Han,



Thanks for the details! Do you have a custom fork or branch with these
changes? I'd love to be able to test this out and contribute if you think
that could help you out. I can get started on testing what you have now as
soon as tomorrow.



Cheers,



--Joel



On Thu, Apr 21, 2016 at 4:15 PM, Sangjin Han via swift-dev <
swift-dev@swift.org> wrote:



I'm writing code for Windows/Cygwin port on my free time. There is no well
documented information about that. Instead I'll give you some information
and several links for you.



1. Cygwin port

  Cygwin is a POSIX environment on Windows. Porting to Cygwin is relatively
easer than Windows native. This is x86_64-unknown-windows-cygwin in llvm
target name.



  Currently, you can build the swift compiler and standard library if you
applying my 'informal' hacked patch and build manual.



  To-be tasks are verifying and sharing the build manual, porting the
autolink-extract module, passing failed test code, etc.





2. Window port

  This is x86_64-pc-windows-msvc in llvm target name, so I call this
'Windows with MSVC library' when confusing with Cygwin - Windows with
Cygwin DLL. Porting to Windows is harder than Cygwin. Swift source uses
C++11 standard with some POSIX functions, GNU extension functions as well
as platform specific codes for OS X or Linux, and the build script for
Swift supposed to run on BASH shell. To compile the Swift source, we should
use the Clang compiler for clang specific feature.



  Currently, there is a 'informal' compiler that barely compiles

[swift-dev] ObjC generic containers and ObjectiveCBridgeable conformance

2016-04-27 Thread Joe Groff via swift-dev 
Importing ObjC generics is currently disabled for the bridged container 
classes, NSArray, NSDictionary, and NSSet. To enable generics for these types, 
we need to figure out what to do about their interaction with 
ObjectiveCBridgeable container bridging. The mapping from generic Swift value 
type to generic ObjC class is nontrivial, since the element type may itself be 
bridged—Array bridges to NSArray, whereas Array 
would bridge to NSArray. We'd need multiple constrained 
conformances to be able to accurately model this relationship at compile time. 
Absent that functionality, I can think of a couple of approaches in the short 
term:

1) Do nothing, and import NSArray and friends as nongeneric types.
2) Import NSArray and friends as generic, and define the ObjectiveCBridgeable 
relationship in terms of their upper bound type, so that Array bridges to 
NSArray, Dictionary to NSDictionary, and 
so on.
3) Do (2), but also do additional special-case bridging in the compiler 
(again), to insert unchecked conversions from the upper bound types like 
NSArray to the appropriate generic type NSArray.

Are there any other approaches I'm missing?

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