Re: [swift-corelibs-dev] CoreFoundation,SwiftFoundation does compile but not TestFoundation …

Hi Benoit, I guess you are trying to build on macOS? Have you checked out swift-corelibs-xctest alongside swift-corelibs-foundation? There are instructions here: https://github.com/apple/swift-corelibs-foundation/blob/master/Docs/GettingStarted.md#on-os-x Thanks, Ian On 18 December 2017 at

Re: [swift-corelibs-dev] Better integration with UNIX tools

Hi Nick, You might be interested in the new Utility project that the Package Manager team have published. It has a bunch of Foundation-esque features including subprocess support, temporary file, progress bars and more. There's a good blog post about it here:

Re: [swift-corelibs-dev] PropertyListDecoder/Encoder?

Hi Kevin, It's unintentional, in the sense that noone has done the work yet to implement the PropertyListDecoder in corelibs-foundation. However, the Darwin implementation is actually open source - see https://github.com/apple/swift/blob/master/stdlib/public/SDK/Foundation/PlistEncoder.swift -

Re: [swift-corelibs-dev] SR-6405: URLRequest does not capitalise HTTP methods

On 16 November 2017 at 17:41, Stephen Celis wrote: > Brandon Williams and I have come across a lot of inconsistencies between > Foundations in our Swift web work. We’ve been trying to file bugs when we > remember to, but I’m curious if there’s a better way to catch

Re: [swift-corelibs-dev] Informal Chat Medium

Hi all, We have set up a #foundation channel on the Swift Package Manager Slack and a few Foundation contributors have joined already. If you'd like to join too, you can request an invite at https://swift-package-manager.herokuapp.com/ See you there! Ian Partridge On 3 August 2017 at 11:52,

[swift-corelibs-dev] Running TestFoundation in Instruments

Has anyone successfully run the TestFoundation scheme under Instruments? When I "build for profiling" in Xcode 9 beta 4 I see a linker failure: Undefined symbols for architecture x86_64: "___CFInitializeSwift", referenced from: ___CFInitialize in libCoreFoundation.a(CFRuntime.o)

Re: [swift-corelibs-dev] Informal Chat Medium

I've also found the SwiftPM Slack extremely useful and friendly. Having something similar for corelibs-foundation is a good idea and I would certainly join it. Maybe we could start a #corelibs-foundation channel on the SwiftPM Slack, as an experiment? If it's useful, over time the SwiftPM Slack

Re: [swift-corelibs-dev] Unavailability macros for APIs that aren't going to be implemented on Linux?

I think a compile-time failure is appropriate and most helpful to a developer. On 2 August 2017 at 09:38, Alex Blewitt via swift-corelibs-dev < swift-corelibs-dev@swift.org> wrote: > > On 28 Jul 2017, at 20:30, Alex Blewitt via swift-corelibs-dev < > swift-corelibs-dev@swift.org> wrote: > > In

Re: [swift-corelibs-dev] Unavailability macros for APIs that aren't going to be implemented on Linux?

Hi Al, thanks for bringing this up. My view is that we shouldn't have API in the project which is never going to be implemented. The contents of swift-corelibs-foundation should represent a baseline of fundamental types and functionality which is useful to all applications and can be implemented

Re: [swift-corelibs-dev] TimeZone database

ybe the best solution for now is to find a good > mechanism to check the underlying version of the OS and split it out into a > function as you suggest. > > - Tony > > > On Jul 6, 2017, at 7:37 AM, Ian Partridge via swift-corelibs-dev > <swift-corelibs-dev@swift.org> wrote:

Re: [swift-corelibs-dev] TimeZone database

acOS are you > testing on? > > If it has indeed moved between 10.12 and 10.13 it may require a runtime > version check to dynamically return TZDIR. > > Simon > > >> On 6 Jul 2017, at 15:09, Ian Partridge via swift-corelibs-dev >> <swift-corelibs-dev@swift.

[swift-corelibs-dev] TimeZone database

Hi, I'm seeing quite a lot of tests failing when running the TestFoundation target in Xcode. The failures are timezone related. Most simply, the code let timeZone = TimeZone(abbreviation: "GMT") is returning nil. Walking through the CF code which sets things up, it seems to be trying to read

Re: [swift-corelibs-dev] Xcode build broken with latest snapshot

On 27 June 2017 at 15:42, Ian Partridge wrote: > With Xcode 9 beta 2, swift.org DEVELOPMENT-SNAPSHOT-2017-06-26-a, and latest master of swift-corelibs-foundation and swift-corelibs-xctest the build fails in the SwiftXCTest target with: > > :0: error: unknown argument:

[swift-corelibs-dev] Xcode build broken with latest snapshot

Hi, Just back from vacation, I'm trying to update my Xcode development environment for Foundation to the latest levels. With Xcode 9 beta 2, swift.org DEVELOPMENT-SNAPSHOT-2017-06-26-a, and latest master of swift-corelibs-foundation and swift-corelibs-xctest the build fails in the SwiftXCTest

[swift-corelibs-dev] Beyond WWDC: Swift on Linux "Birds of a Feather"

For anyone attending WWDC, AltConf, CocoaConf Next Door, or one of the other events in San Jose during the week of June 5th, the Swift@IBM team are hosting a Swift on Linux "Birds of a Feather". Spaces are limited to 70 attendees, so sign up quickly using the link if you are able to attend.

[swift-corelibs-dev] URLProtocol

Currently, URLProtocol is unimplemented. I'm currently looking at understand the scope of work involved in implementing this, and what the major pitfalls might be. If anyone else has looked into this area or has thoughts or advice I'd love to hear from you! Thanks, -- Ian Partridge

Re: [swift-corelibs-dev] Asynchronous Operations

> - Tony > >> On Jan 21, 2017, at 6:09 AM, Brent Royal-Gordon via swift-corelibs-dev >> <swift-corelibs-dev@swift.org> wrote: >> >>> On Jan 20, 2017, at 7:55 AM, Ian Partridge via swift-corelibs-dev >>> <swift-corelibs-dev@swift.org> wr

[swift-corelibs-dev] Asynchronous Operations

On Darwin, asynchronous usage of Operation is supported via KVO notifications. Because KVO is only available on Darwin platforms, swift-corelibs-foundation currently does not support asychronous Operations, and there is a comment to that effect:

Re: [swift-corelibs-dev] NSMutableData memory leak

On 16 May 2016 at 17:43, Philippe Hausler wrote: > I think there is probably some likely issue with the fact that NSMutableData > is a subclass and the layout initialization is not properly setup during the > init for that object. > > __kCFDontDeallocate is used to mark the

[swift-corelibs-dev] NSMutableData memory leak

import Foundation while true { var myData: NSMutableData? = NSMutableData(capacity: 0) myData = nil } Running this infinite loop with swift-corelibs-foundation shows a steady memory leak, with the process's RSS increasing over time. No leak is seen with Foundation on Darwin. Instrumenting

Re: [swift-corelibs-dev] NSHTTPURLResponse.localizedStringForStatusCode()

On 17 March 2016 at 19:31, Daniel Eggert wrote: > What code will be used to make then _localized_? Good question - I wondered if Obj-C foundation translated them based on the current locale, but it doesn't. They seem to be fixed strings. By the way, some more strangeness

[swift-corelibs-dev] NSHTTPURLResponse.localizedStringForStatusCode()

Hi, A quick question about implementing this method. Do we want the strings returned to match those returned by the Objective-C implementation of Foundation, or follow RFC 2616? Currently they are inconsistent, e.g. Obj-C Foundation returns "no error" for status code 200, whereas the RFC says

Re: [swift-corelibs-dev] NSHTTPURLResponse.localizedStringForStatusCode()

Hi Philippe, thanks for your quick reply. The HTTP status code reason phrases are designed to be human readable. They are standard phrases that are easily searched for online. The latest table is at http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml - isn't there a case