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 >>

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

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: > >

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

Re: [swift-corelibs-dev] Inconsistencies between Foundation APIs

Hi Ian, Any place where the API differs should be marked with a comment like this: /// - Experiment: This is a draft API currently under consideration for official import into Foundation If not, then we found some place that we either need to change or propose a change for. We can track those

[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-corelibs-dev] CChar vs Int8

Hi Luke, > On Jan 2, 2016, at 8:28 PM, Luke Howard via swift-corelibs-dev > wrote: > > Many Foundation APIs use Int8 instead of CChar when representing C strings, > e.g.: > var UTF8String: UnsafePointer >

[swift-corelibs-dev] NSURL.fileSystemRepresentation implementation

As far as I understand NSURL is responsible for deallocating memory to which UnsafePointer returned from NSURL.fileSystemRepresentation points to. Could one use private buffer to store result for NSURL.fileSystemRepresentation or layout of this class should be the same as CFURL? Also NSFileManager

Re: [swift-corelibs-dev] CChar vs Int8

OK, I filed [SR-466] as a compiler issue. If the behaviour changes and that flows through to Darwin Foundation, we can update the open source one... — Luke > On 5 Jan 2016, at 8:21 AM, Philippe Hausler wrote: > > No C strings import as UnsafePointer for some reason; they

Re: [swift-corelibs-dev] corelibs-xctest + swiftpm

Hi Keith, Also - the Xcode project is provided for development ease-of-use only. This version of XCTest is only for non-Darwin platforms, and that builds with the simple shell script that is in the root directory (build_script.py). - Tony > On Jan 4, 2016, at 9:19 AM, Daniel Dunbar via

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

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

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 >

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

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

Hi, I came across hit issue while chaining filter() and prefix() on lazy sequences: https://bugs.swift.org/browse/SR-461 And started wondering if it would be more consistent if lazy.filter().prefix() returned a custom LazySequenceType instead of Slice>. That way