Re: [swift-dev] Building Foundation on FreeBSD

On Mon, Jan 4, 2016 at 4:57 PM, Davide Italiano wrote: > On Mon, Dec 21, 2015 at 6:12 PM, Jordan Rose wrote: >> >>> On Dec 20, 2015, at 4:14 , Davide Italiano wrote: >>> >>> On Sun, Dec 20, 2015 at 5:07 AM, Davide Italiano >>> wrote: On Sat, Dec 19, 2015 at 11:28 PM, Jordan Rose wr

Re: [swift-dev] Building Foundation on FreeBSD

On Mon, Dec 21, 2015 at 6:12 PM, Jordan Rose wrote: > >> On Dec 20, 2015, at 4:14 , Davide Italiano wrote: >> >> On Sun, Dec 20, 2015 at 5:07 AM, Davide Italiano >> wrote: >>> On Sat, Dec 19, 2015 at 11:28 PM, Jordan Rose wrote: On Dec 19, 2015, at 7:14 , Davide Italiano wrote:

Re: [swift-dev] Testing fails in GYBUnicodeDataUtils.py

On Mon, Jan 4, 2016, at 06:09 PM, Tom Gall wrote: > On Mon, Jan 4, 2016 at 4:44 PM, Ryan Lovelett > wrote: > > I would suggest setting the environment variables and re-running but > > that is just my opinion. > > > > I went through many of the same issues on Arch as well. Arch uses Python > > 2.7.

Re: [swift-dev] Testing fails in GYBUnicodeDataUtils.py

On Mon, Jan 4, 2016 at 4:44 PM, Ryan Lovelett wrote: > I would suggest setting the environment variables and re-running but > that is just my opinion. > > I went through many of the same issues on Arch as well. Arch uses Python > 2.7.11 and Python 3.5.1; with 3.5.1 being default. Well point I was

Re: [swift-dev] Testing fails in GYBUnicodeDataUtils.py

I would suggest setting the environment variables and re-running but that is just my opinion. I went through many of the same issues on Arch as well. Arch uses Python 2.7.11 and Python 3.5.1; with 3.5.1 being default. I can _maybe_ give you a clue on the lldb issue. Check out SR-14 [1] which link

Re: [swift-dev] Testing fails in GYBUnicodeDataUtils.py

Hi Ryan, In my case I'm on Python 2.7. Your comment is interesting as I was just tracking down why python-config --libs and python-config --includes doesn't seem to be used to determine what is the system python install. I was just starting to trace through the build tool to figure out how build-

Re: [swift-dev] Testing fails in GYBUnicodeDataUtils.py

I wonder what the value of LC_ALL, LC_CTYPE, LANG are set to in your environment? On my system LC_CTYPE=en_US.UTF-8 and LANG=en_US.UTF-8. My understand of Python on Linux is that it reads these environment variables to set `sys.getfilesystemencoding()`. This has to do with configuring Python to con

Re: [swift-dev] [swift-corelibs-dev] LazySequenceType: make prefix return a lazy collection

Hi Mark, I’m going to loop in the swift-dev list for this question. - Tony > On Jan 4, 2016, at 5:15 AM, Mark Aron Szulyovszky via swift-corelibs-dev > wrote: > > Hi, > > I came across hit issue while chaining filter() and prefix() on lazy > sequences: > https://bugs.swift.org/browse/SR-461

Re: [swift-dev] Testing fails in GYBUnicodeDataUtils.py

On Mon, Jan 4, 2016, at 03:40 PM, Tom Gall via swift-dev wrote: > Building with: ./swift/utils/build-script -R -t --foundation > > on Linux (gentoo amd64) fails with > > + /usr/bin/cmake --build > /home/tgall/swift/build/Ninja-ReleaseAssert/swift-linux-x86_64 -- -j4 > SwiftUnitTests > > [6/29] G

Re: [swift-dev] Testing fails in GYBUnicodeDataUtils.py

> On Jan 4, 2016, at 12:40, Tom Gall via swift-dev wrote: > > Building with: ./swift/utils/build-script -R -t --foundation > > on Linux (gentoo amd64) fails with > > + /usr/bin/cmake --build > /home/tgall/swift/build/Ninja-ReleaseAssert/swift-linux-x86_64 -- -j4 > SwiftUnitTests > > [6/29] Ge

Re: [swift-dev] swift_retainCount in CoreFoundation

Looks like it was killed in d430c06f. > On 5 Jan 2016, at 7:10 AM, Tony Parker via swift-dev > wrote: > > Hi Joe, > > I think we can probably elide CFGetRetainCount from the corelibs-foundation. > It’s almost always an anti-pattern to check a retain count anyway (as I’m > sure you’re aware s

[swift-dev] Testing fails in GYBUnicodeDataUtils.py

Building with: ./swift/utils/build-script -R -t --foundation on Linux (gentoo amd64) fails with + /usr/bin/cmake --build /home/tgall/swift/build/Ninja-ReleaseAssert/swift-linux-x86_64 -- -j4 SwiftUnitTests [6/29] Generating UnicodeGraphemeBreakTest.cpp from UnicodeGraphemeBreakTest.cpp.gyb with

Re: [swift-dev] swift_retainCount in CoreFoundation

Hi Joe, I think we can probably elide CFGetRetainCount from the corelibs-foundation. It’s almost always an anti-pattern to check a retain count anyway (as I’m sure you’re aware since you’re trying to kill the swift version of it). File a bug for us and we’ll get on it. Thanks, - Tony > On Dec

Re: [swift-dev] SIL: "unowned" the calling convention and "unowned" the variable ownership convention

> On Jan 4, 2016, at 11:07 AM, Jordan Rose via swift-dev > wrote: > Hi, Michael. The calling convention is equivalent to the 'unowned(unsafe)' > variant of 'unowned', so I don't think it's entirely unrelated. > > I don't like "Immediate" because I don't know what it means. Admittedly I > don't

Re: [swift-dev] SIL: "unowned" the calling convention and "unowned" the variable ownership convention

Hi, Michael. The calling convention is equivalent to the 'unowned(unsafe)' variant of 'unowned', so I don't think it's entirely unrelated. I don't like "Immediate" because I don't know what it means. Admittedly I don't work on SIL, but when is something passed "immediate" as opposed to "guarant

Re: [swift-dev] clang version requirements?

Hi, Tom. I wouldn't expect 3.7 or 3.8 to cause any problems when used as the compiler building Swift. You'll note that Swift embeds its own version of LLVM and Clang for later use; it will not (and cannot) use the standard one on your system. More information on that is available on the Swift we

Re: [swift-dev] Linker script on Linux

> On Dec 30, 2015, at 17:49, Luke Howard via swift-dev > wrote: > > >> On 31 Dec 2015, at 12:33 PM, Joe Groff > > wrote: >> >> >>> On Dec 30, 2015, at 1:24 AM, Luke Howard via swift-dev >> > wrote: >>> >>> Per [SR-404], anything that cons

Re: [swift-dev] Official Docker Image & "Blessing"s of Community Platforms

Yes we can most definitely tag images for snapshots. Maybe our versioning could reflect that too. Haris On January 4, 2016 at 1:17:56 PM, Thomas Catterall (m...@swizzlr.co) wrote: Hi Daniel, We'd release new images as new snapshots are released; we don't do it yet but we can "tag" images so t

[swift-dev] clang version requirements?

Hi All, Getting my "sea" legs under me building swift and company on Linux. (Gentoo/x86-64 to be exact). In the docs I see Ubuntu 3.6 r100 as the minimum mentioned for llvm/clang. As API and standard support within the llvm/clang/clang++ universe can change a bit, I was wondering if there was any

Re: [swift-dev] TWISt-shout newletter 2016-01-04

Sorry, you do not need to be logged in. The links were broken. Now fixed. -Kenny > On Jan 4, 2016, at 10:27 AM, Kenny Leung via swift-dev > wrote: > > Hi All. > > Let’s kick off 2016 with the first This Week In Swift newsletter. You can > find it here: > > https://github.com/pepperdog/TWIS

[swift-dev] TWISt-shout newletter 2016-01-04

Hi All. Let’s kick off 2016 with the first This Week In Swift newsletter. You can find it here: https://github.com/pepperdog/TWISt-shout/blob/master/2016/TWISt-shout-2016-01-04.md You will need to be logged into GitHub to view the code commits. Any comments, suggestions, updates, or omissions

Re: [swift-dev] [swift-lldb-dev] LLDB Invalid address (32 bit arm)

On Mon, Jan 4, 2016 at 9:45 AM, William Dillon via swift-lldb-dev < swift-lldb-...@swift.org> wrote: > > On Jan 4, 2016, at 9:17 AM, Todd Fiala wrote: > > I added some more comments to the pull request that I Think is related to > this thread here: > https://github.com/apple/swift-lldb/pull/3 > >

Re: [swift-dev] Official Docker Image & "Blessing"s of Community Platforms

Hi Daniel, We'd release new images as new snapshots are released; we don't do it yet but we can "tag" images so that you could pin your image to a particular snapshot. Tom Sent from my iPhone > On 4 Jan 2016, at 12:24, Daniel Dunbar wrote: > > Hi Thomas, > > Just a question: how would the c

Re: [swift-dev] [swift-lldb-dev] LLDB Invalid address (32 bit arm)

> On Jan 4, 2016, at 9:17 AM, Todd Fiala wrote: > > I added some more comments to the pull request that I Think is related to > this thread here: > https://github.com/apple/swift-lldb/pull/3 > > > The archspec changes really need to happen in llvm.

Re: [swift-dev] Official Docker Image & "Blessing"s of Community Platforms

Hi Thomas, Just a question: how would the constant changing of the Swift compiler version and language interact with this? It seems odd to have an "official" version of what is an otherwise unreleased language version/compiler. - Daniel > On Dec 29, 2015, at 10:07 AM, Thomas Catterall via swi

Re: [swift-dev] [swift-lldb-dev] LLDB Invalid address (32 bit arm)

I added some more comments to the pull request that I Think is related to this thread here: https://github.com/apple/swift-lldb/pull/3 The archspec changes really need to happen in llvm.org lldb svn trunk and need to be put up for

Re: [swift-dev] [swift-lldb-dev] LLDB Invalid address (32 bit arm)

On Mon, Jan 4, 2016 at 6:50 PM, Todd Fiala via swift-lldb-dev < swift-lldb-...@swift.org> wrote: > > On Dec 28, 2015, at 10:39 AM, William Dillon via swift-lldb-dev < > swift-lldb-...@swift.org> wrote: > > Hi Todd, > > Yes, I think that LLDB is more or less working with Swift on ARM. We can > sta

Re: [swift-dev] [swift-lldb-dev] LLDB Invalid address (32 bit arm)

> On Dec 28, 2015, at 10:39 AM, William Dillon via swift-lldb-dev > wrote: > > Hi Todd, > > Yes, I think that LLDB is more or less working with Swift on ARM. We can > start the REPL and do some tasks with it, though it isn’t all that reliable > yet. I’d love to hear about the reliability p