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 14:50, Benoit Pereira da silva via swift-corelibs-dev wrote: > Dear Core libs Dev. > > I ve found a serious bug on JSONSerialization https:// > bugs.swift.org/browse/SR-6631 > > I'm trying to build the swift-corelibs-foundation to try to validate a > fix. > And i m not able to build the master branch & run the tests. > CoreFoundation,SwiftFoundation does compile but not TestFoundation … > > I ve got a `No such module SwiftXCTest` message > > M'I missing something? > > > > Benoit Pereira da Silva > Ultra Mobile Developer & Movement Activist > Développeur Ultra Mobile & Militant du mouvement > https://pereira-da-silva.com > > > > > ✄ > This e-mail is confidential. Distribution, copy, publication or use of > this information for any purpose is prohibited without agreement of the > sender. > Ce message est confidentiel. Toute distribution, copie, publication ou > usage des informations contenues dans ce message sont interdits sans > agrément préalable de l'expéditeur. > > > > > ___ > swift-corelibs-dev mailing list > swift-corelibs-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-corelibs-dev > > -- Ian Partridge ___ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
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: https://www.hackingwithswift.com/articles/44/apple-s-new-utility-library-will-power-up-command-line-apps I hope it gets more publicity as there's some great functionality here, which has already been used "for real" by the package manager. Thanks, Ian Partridge On 30 November 2017 at 08:43, Nick Keets via swift-corelibs-dev wrote: > In that case I think the discussion is kind of moot, scripts are > fundamentally different than apps, being terse is important and almost > always you want to block. > > If better scripting support is a non-goal for Foundation then `Process` is > mostly fine as it is. My only wish would be to somehow make it easier to > read and write `Data` to stdin/stdout/stderr. > > > On Tue, Nov 28, 2017 at 11:30 PM, Tony Parker > wrote: >> >> Of course, Foundation API has no way of distinguishing if the caller is >> considered a script or not. >> >> If the API is a bad idea for other kinds of apps then we simply wouldn’t >> add it. So, I think this proposed convenience API needs to consider all of >> the varied clients of Foundation. >> >> - Tony >> >> >> On Nov 28, 2017, at 12:24 PM, Brent Royal-Gordon >> wrote: >> >> On Nov 28, 2017, at 8:00 AM, Tony Parker wrote: >> >> Why does it imply a run loop rather than one of many multithreading >> possibilities (dispatch queue, starting one more thread, etc)? And even if >> it did use run loops, why is that a problem? >> >> >> The problem is simply that we're discussing using this feature in Swift >> *scripts*. Swift scripts don't typically invoke `RunLoop.run()` or >> `dispatch_main()`, and without changing the way they generate main() >> functions to intrinsically do so (and then schedule main.swift's body on the >> main runloop/queue), I don't see a good way for it to do so. So an async API >> would be inconvenient to use from a Swift script. >> >> -- >> Brent Royal-Gordon >> Architechies >> >> > > > ___ > swift-corelibs-dev mailing list > swift-corelibs-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-corelibs-dev > -- Ian Partridge ___ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
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 - so we should be able to reuse that code. It might not be a straight copy and paste, but the bulk of the work is ready and done... PRs welcome! Thanks, Ian On 16 November 2017 at 20:54, Kevin Lundberg via swift-corelibs-dev wrote: > I’m trying to port some mac/iOS swift code over to also compile and run on > linux. However one of the files I’m working with references > PropertyListDecoder in order to decode some propertylist data we have in our > library, and it’s failing to compile since PropertyListDecoder doesn’t appear > to be implemented in the corelibs-foundation project. Is this an oversight, > or intentional? Are there any workarounds I can do (short of re-encoding our > data in JSON which i’d prefer not to do) to get access to property list > decoding on linux? > > Thanks! > > -- > Kevin Lundberg > > > > ___ > swift-corelibs-dev mailing list > swift-corelibs-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-corelibs-dev -- Ian Partridge ___ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
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 these. Please continue to file bugs! Even better, open a PR with a fix and a testcase :-) > Is the Foundation test suite run against both implementations to attempt to > catch these kinds of things? > If not it would seem like a big win to do so. Not yet, but there is work underway to do this. See https://github.com/apple/swift-corelibs-foundation/pull/1286 which adds an Xcode project to enable just that. The goal is to get this into CI so that we automatically run the SCLF testsuite against both implementations. > If so, I suppose we could help by beefing up the test coverage? That would be fantastic, we always need more tests. We cannot build confidence in the SCLF implementation without a robust testsuite that passes against both implementations (thinks Java TCK...) -- Ian Partridge ___ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
Re: [swift-corelibs-dev] SR-6405: URLRequest does not capitalise HTTP methods
On 16 November 2017 at 19:02, Alex Blewitt wrote: > Note that there's no requirement for the methods to be capitalised in > URLRequest. I'm not sure what you mean by requirement. It may not be documented, but Darwin does behave this way. > Chances are that the implementation is such that there are some pre-defined > values which can be used/replaced for keys, but other ones will take the case > of whatever you put in them. Perhaps. That's what I'd like to enquire about. Is making SCLF compatible with the output in my example sufficient, or are there other factors to consider? > I also don't think it makes sense to capitalise everything because in most > cases it will have no effect, but is wasted computation. Darwin doesn't capitalise everything, as I've shown, so SCLF shouldn't either. > So in other words, don't pass lowercase values into the x.httpMethod if you > don't want it. I'm sorry, I don't understand this. x.httpMethod accepts an arbitrary String - you can write `x.httpMethod = frobnicate` if you want. Darwin seems to treat some values e.g. "get" specially though. This isn't documented, but SCLF should behave the same because there's code out there that does `x.httpMethod = "get"`, `y.httpMethod = "GET", compares the URLRequests and expects them to be equal. -- Ian Partridge ___ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
[swift-corelibs-dev] SR-6405: URLRequest does not capitalise HTTP methods
Hi, it looks like Foundation on Darwin capitalises certain HTTP
methods but not others:
```
let methods = ["get", "head", "post", "put", "delete", "connect",
"options", "trace", "patch"]
var x = URLRequest(url: URL(string: "/hello")!)
for m in methods {
x.httpMethod = m
print(x.httpMethod!)
}
```
Output on Darwin:
GET
HEAD
POST
PUT
DELETE
CONNECT
options
trace
patch
Currently on Linux we don't do any capitalization so I'd like to fix this.
Is my list of 6 methods above the definitive list of which HTTP
methods should be capitalized?
Thanks,
--
Ian Partridge
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
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, Ian Partridge wrote: > > 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 > could become a "swift.org" Slack. > > I see this as separate to the move of the mailing lists to Discourse. > > Thanks, > Ian -- Ian Partridge ___ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
[swift-corelibs-dev] NSString.range(of:options:range:locale) incompatibility
I've noticed this current difference in behaviour.
Darwin:
$ swift
Welcome to Apple Swift version 4.0-dev (LLVM 2dedb62a0b, Clang b9d76a314c,
Swift 6b4756bd93). Type :help for assistance.
1> import Foundation
2> "abc".range(of: "a")!.lowerBound..<"abc".range(of: "a")!.upperBound
$R0: Range = {
lowerBound = {
_compoundOffset = 0
_cache = utf16
}
upperBound = {
_compoundOffset = 4
_cache = utf16
}
}
Linux:
$ swift
Welcome to Swift version 4.0-dev (LLVM 2dedb62a0b, Clang b9d76a314c, Swift
6b4756bd93). Type :help for assistance.
1> import Foundation
2> "abc".range(of: "a")!.lowerBound..<"abc".range(of: "a")!.upperBound
$R0: CountableRange = {
lowerBound = {
_compoundOffset = 0
_cache = utf16
}
upperBound = {
_compoundOffset = 4
_cache = utf16
}
}
I think this might be because some changes made in the overlay
(NSStringAPI.swift) haven't been ported across to swift-corelibs-foundation:
https://github.com/apple/swift/commit/5f1c3f702189f8197e297479d464dc454330be80
Is my suspicion right, and is there any work in progress to bring this into
sync before Swift 4?
--
Ian Partridge
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
[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) "___CFSwiftGetBaseClass", referenced from: ___CFInitialize in libCoreFoundation.a(CFRuntime.o) ld: symbol(s) not found for architecture x86_64 These functions are marked @_cdecl which is an attribute added to enable exporting of top-level Swift functions to C. CF uses this during initialization of the runtime to call out to NSSwiftRuntime.swift (mostly for setting up the _CFSwiftBridge function table). I guess this exporting of the Swift function isn't working in optimised builds, for some reason. Any ideas? -- Ian Partridge ___ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
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 could become a "swift.org" Slack. I see this as separate to the move of the mailing lists to Discourse. Thanks, Ian On 2 August 2017 at 20:34, David Hart via swift-corelibs-dev wrote: > Hello Corelibs dev, > > A few months back, I wanted to start contributing more seriously to Swift > Open Source. I ended up helping out on the Swift Package Manager project and > had a very positive experience. It’s not easy to jump into a big project and > it would not have been such a success for me without their official Slack > channel where I was grateful to often find a helping hand when I had doubts, > questions, or wanted to discuss and understand the process or direction of > the project. That medium really helped me to ask the kind of questions I was > afraid to ask on the mailing-list, which feels like a more formal medium. > > Now that I’m looking into what I can do on corelibs-foundation, I really wish > an equivalent channel existed. Is this an idea the corelibs team would be > interested in entertaining? > > Regards, > David. > ___ > swift-corelibs-dev mailing list > swift-corelibs-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-corelibs-dev -- Ian Partridge ___ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
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 the meantime I'll take a stab next week at proposing some > unavailability annotations for some of the stuff which almost certainly > doesn't make sense, to do with Mach ports and NSZone. > > > I've created a pull request which adds NSUnsupported, and uses that to > wrap NSPort and NSMessagePort: > > https://github.com/apple/swift-corelibs-foundation/pull/1150 > > What do you think? Should we use 'deprecated' (so that it's a warning) or > 'unavailable' (so that it's a compile time error)? > > + @available(*,deprecated,message:"Not available on non-Darwin platforms") > + @available(*,unavailable,message:"Not available on non-Darwin platforms" > ) > > Alex > > > ___ > swift-corelibs-dev mailing list > swift-corelibs-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-corelibs-dev > > -- Ian Partridge ___ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
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 on a broad range of platforms and operating systems. I think it is more useful to developers who are porting their Swift applications to other platforms if they are faced with a helpful message when their app attempts to use unavailable API, rather than just "ERROR: type 'NSWhatever' has no member 'foo'" - so I like your idea of using @available annotations to guide people. Once Swift 4 is out of the door, I think we should do a review of the codebase and decide which of the remaining NSUnimplemented() are really NSProbablyNever(). This will also help new contributors to swift-corelibs-foundation as they will be able to be confident that every NSUnimplemented() is a genuine opportunity to contribute. Regards, Ian Partridge On 28 July 2017 at 15:07, Alex Blewitt via swift-corelibs-dev < swift-corelibs-dev@swift.org> wrote: > I've pushed a change which will add an unavailability warning for a method > which was deprecated at the point of being added to Swift, has never > worked, and likely never will: > > https://github.com/apple/swift-corelibs-foundation/pull/1140 > > There are some other types in Foundation which aren't likely to ever be > implementable in Swift on Linux; Bundle.unload, NSPort/PortMessage, > copy(with zone) etc. The majority of these methods use NSUnimplemented(), > which means there are often unannounced runtime errors that you can get > from something that compiled correctly. > > I'd like to suggest that we attempt to resolve this problem, either by > removing the features whihc are never going to be implemented (e.g. by > commenting out the calls) or by marking them as @available(*,unavailable, > message:"Not available on the Linux platform"). That way, calls that are > known cannot work can be identified at compile time instead of at run-time. > > I hope we'll then be able to remove the NSUnimplemented calls on the types > that can never be implemented, so that we can focus on those types and > functions that we can. Alternatively we can define a different macro, say > NSUnavailableOnLinux, to indicate that this functionality cannot be present > (as opposed to just leaving it blank). > > What do you think? > > $ git grep -c NSUnimplemented | sort -n -r -k2 -t: > Foundation/NSExpression.swift:37 > Foundation/NSURLCache.swift:22 > Foundation/FileManager.swift:22 > Foundation/NSPort.swift:21 > Foundation/NSOrderedSet.swift:20 > Foundation/NSSortDescriptor.swift:19 > ... > > ___ > swift-corelibs-dev mailing list > swift-corelibs-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-corelibs-dev > > -- Ian Partridge ___ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
Re: [swift-corelibs-dev] TimeZone database
Just picking this up again.. is a solution imminent? My hack is diff --git a/CoreFoundation/NumberDate.subproj/CFTimeZone.c b/CoreFoundation/NumberDate.subproj/CFTimeZone.c index 434203ab43..86ab6ecb71 100644 --- a/CoreFoundation/NumberDate.subproj/CFTimeZone.c +++ b/CoreFoundation/NumberDate.subproj/CFTimeZone.c @@ -33,6 +33,7 @@ #endif #if DEPLOYMENT_TARGET_MACOSX || DEPLOYMENT_TARGET_EMBEDDED #include +#define TZDIR"/usr/share/zoneinfo" #elif DEPLOYMENT_TARGET_LINUX || DEPLOYMENT_TARGET_FREEBSD #ifndef TZDIR #define TZDIR "/usr/share/zoneinfo" /* Time zone object file directory */ which gets the tests running again on Sierra but I guess breaks on High Sierra. Thanks, Ian On 6 July 2017 at 16:28, Tony Parker wrote: > Yes, we’re discussing this one internally too and trying to figure out what > the right answer is. Maybe 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 > wrote: > > Good shout Simon, you are right. I'm on Sierra. Compare and contrast: > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/tzfile.h > #define TZDIR "/usr/share/zoneinfo" > > /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/tzfile.h > #define TZDIR "/var/db/timezone/zoneinfo" > > so I guess if I installed the High Sierra beta it would work OK. > > I hacked CF to force it to use /usr/share/zoneinfo and TestFoundation > is much happier, but that's not a solution. > > On 6 July 2017 at 15:20, Simon Evans wrote: > > Ian > > I also saw this error, I think its because the TZDIR is different in the > headers shipped with Xcode 9. Maybe the location of the timezone directory > was moved between Sierra and High Sierra. What version of macOS 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 > wrote: > > 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 the timezone database from > /var/db/timezone/zoneinfo/zone.tab which doesn't exist on my macOS > system. > > /usr/share/zoneinfo/zone.tab is there and seems to be the right > location (?), but CF is picking up TZDIR from tzfile.h which says: > > #define TZDIR "/var/db/timezone/zoneinfo" > > Any thoughts? I feel like I'm missing something obvious and have gone > too far down the rabbit hole. > > -- > Ian Partridge > ___ > swift-corelibs-dev mailing list > swift-corelibs-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-corelibs-dev > > > > > > -- > Ian Partridge > ___ > swift-corelibs-dev mailing list > swift-corelibs-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-corelibs-dev > > -- Ian Partridge On 6 July 2017 at 16:31, Tony Parker via swift-corelibs-dev wrote: > Yes, we’re discussing this one internally too and trying to figure out what > the right answer is. Maybe 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 > wrote: > > Good shout Simon, you are right. I'm on Sierra. Compare and contrast: > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/tzfile.h > #define TZDIR "/usr/share/zoneinfo" > > /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/tzfile.h > #define TZDIR "/var/db/timezone/zoneinfo" > > so I guess if I installed the High Sierra beta it would work OK. > > I hacked CF to force it to use /usr/share/zoneinfo and TestFoundation > is much happier, but that's not a solution. > > On 6 July 2017 at 15:20, Simon Evans wrote: > > Ian > > I also saw this error, I think its because the TZDIR is different in the > headers shipped with Xcode 9. Maybe the loca
Re: [swift-corelibs-dev] TimeZone database
I've only poked this briefly, but it looks like CFCopySystemVersionString() might give the info we'd need? On 6 July 2017 at 16:28, Tony Parker wrote: > Yes, we’re discussing this one internally too and trying to figure out what > the right answer is. Maybe 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 > wrote: > > Good shout Simon, you are right. I'm on Sierra. Compare and contrast: > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/tzfile.h > #define TZDIR "/usr/share/zoneinfo" > > /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/tzfile.h > #define TZDIR "/var/db/timezone/zoneinfo" > > so I guess if I installed the High Sierra beta it would work OK. > > I hacked CF to force it to use /usr/share/zoneinfo and TestFoundation > is much happier, but that's not a solution. > > On 6 July 2017 at 15:20, Simon Evans wrote: > > Ian > > I also saw this error, I think its because the TZDIR is different in the > headers shipped with Xcode 9. Maybe the location of the timezone directory > was moved between Sierra and High Sierra. What version of macOS 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 > wrote: > > 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 the timezone database from > /var/db/timezone/zoneinfo/zone.tab which doesn't exist on my macOS > system. > > /usr/share/zoneinfo/zone.tab is there and seems to be the right > location (?), but CF is picking up TZDIR from tzfile.h which says: > > #define TZDIR "/var/db/timezone/zoneinfo" > > Any thoughts? I feel like I'm missing something obvious and have gone > too far down the rabbit hole. > > -- > Ian Partridge > ___ > swift-corelibs-dev mailing list > swift-corelibs-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-corelibs-dev > > > > > > -- > Ian Partridge > ___ > swift-corelibs-dev mailing list > swift-corelibs-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-corelibs-dev > > -- Ian Partridge ___ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
Re: [swift-corelibs-dev] TimeZone database
Good shout Simon, you are right. I'm on Sierra. Compare and contrast: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/tzfile.h #define TZDIR "/usr/share/zoneinfo" /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/tzfile.h #define TZDIR "/var/db/timezone/zoneinfo" so I guess if I installed the High Sierra beta it would work OK. I hacked CF to force it to use /usr/share/zoneinfo and TestFoundation is much happier, but that's not a solution. On 6 July 2017 at 15:20, Simon Evans wrote: > Ian > > I also saw this error, I think its because the TZDIR is different in the > headers shipped with Xcode 9. Maybe the location of the timezone directory > was moved between Sierra and High Sierra. What version of macOS 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 >> wrote: >> >> 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 the timezone database from >> /var/db/timezone/zoneinfo/zone.tab which doesn't exist on my macOS >> system. >> >> /usr/share/zoneinfo/zone.tab is there and seems to be the right >> location (?), but CF is picking up TZDIR from tzfile.h which says: >> >> #define TZDIR "/var/db/timezone/zoneinfo" >> >> Any thoughts? I feel like I'm missing something obvious and have gone >> too far down the rabbit hole. >> >> -- >> Ian Partridge >> ___ >> swift-corelibs-dev mailing list >> swift-corelibs-dev@swift.org >> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev > -- Ian Partridge ___ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
[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 the timezone database from /var/db/timezone/zoneinfo/zone.tab which doesn't exist on my macOS system. /usr/share/zoneinfo/zone.tab is there and seems to be the right location (?), but CF is picking up TZDIR from tzfile.h which says: #define TZDIR "/var/db/timezone/zoneinfo" Any thoughts? I feel like I'm missing something obvious and have gone too far down the rabbit hole. -- Ian Partridge ___ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
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: '-index-store-path' > > Command /Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2017-06-26-a.xctoolchain/usr/bin/swiftc failed with exit code 1 To answer my own question - I was able to get the Xcode build working by running: defaults write com.apple.dt.Xcode IDEIndexEnableBoltIndex NO Many thanks to Simon Evans for pointing me at the right incantation! -- Ian Partridge ___ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
[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 target with: :0: error: unknown argument: '-index-store-path' Command /Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2017-06-26-a.xctoolchain/usr/bin/swiftc failed with exit code 1 It looks like the -index-store-path option has been removed from the compiler recently, but is still being referred to somewhere. I have poked around but can't see where this option is coming from. The full option being passed to the compiler is -index-store-path /Users/ipartrid/Library/Developer/Xcode/DerivedData/Foundation-dlbuoxyagtlausbjtyopapynebeb/Index/DataStore Can anyone advise? -- Ian Partridge ___ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
[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. Details below. What:*Swift on Linux "Birds of a Feather"* When:*Thu, 8 June 2017 3:00 PM – 4:30 PM PDT* Where:Hyatt Place San Jose Downtown, Salons 2 & 3 282 Almaden Blvd, San Jose, CA Register here: https://swift_on_linux_bof.eventbrite.com The aim of the event is to allow the Swift on Linux community to meet and discuss areas of mutual interest. We hope there will be interest from developers working in areas including Foundation, Swift Package Manager, Swift on Android/RaspberryPi/etc., open source projects like SourceKitten, Jazzy and SwiftLint, and those working on Linux-compatible frameworks and packages. If it is Swift and Linux, it is on-topic! The topics to be covered will be decided at the start by the attendees, but could include discussions of the current status of Swift on Linux (strengths, weaknesses), areas of focus in the Swift 5 timeframe, and how the community can work together to accelerate progress for Swift on Linux. We look forward to welcoming you! -- Ian Partridge ___ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
[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 ___ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
Re: [swift-corelibs-dev] Asynchronous Operations
Thank you everyone for your comments.
Adding willChangeValue(forKey:) and didChangeValue(forKey:) to
Operation does solve the problem for me. The Swift 3 code I'm porting
from macOS to Linux works correctly when I patch Foundation as Brent
suggests.
I've opened a PR against swift-corelibs-foundation and would welcome
feedback on this. Thank you.
https://github.com/apple/swift-corelibs-foundation/pull/836
P.S. The code I'm porting is roughly analogous to
https://gist.github.com/ianpartridge/e3b8496cb114005a93f5c86ff76af630
although it uses URLSession instead of an async dispatch queue.
On 23 January 2017 at 17:32, Tony Parker wrote:
> Hm, that’s probably the least bad option we have at the moment.
>
> I don’t want to introduce “new” API, as it is unlikely we will be able to
> remove it when whatever permanent solution comes up.
>
> - Tony
>
>> On Jan 21, 2017, at 6:09 AM, Brent Royal-Gordon via swift-corelibs-dev
>> wrote:
>>
>>> On Jan 20, 2017, at 7:55 AM, Ian Partridge via swift-corelibs-dev
>>> wrote:
>>>
>>> Is there any way that we could support asynchronous operations in
>>> swift-corelibs-foundation, in the absence of KVO?
>>
>> Could we add `willChangeValue(forKey:)` and `didChangeValue(forKey:)`
>> methods just to `Operation` which only handle an `isFinished` key?
>> Presumably they'd just look like:
>>
>> public func willChangeValue(forKey key: String) {
>> // do nothing
>> }
>> public func didChangeValue(forKey key: String) {
>> if key == "isFinished" && isFinished {
>> finish()
>> }
>> }
>>
>> I believe that would make existing code just work without needing to do
>> anything special.
>>
>> --
>> Brent Royal-Gordon
>> Architechies
>>
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>
--
Ian Partridge
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
[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: https://github.com/apple/swift-corelibs-foundation/blob/6c2afef20330681ec1f8e4e4e3e2664bfd75/Foundation/NSOperation.swift#L50 My understanding is that it's unlikely KVO will arrive on Linux any time soon, so this leaves us with a problem in Operation. Asynchronous usage of Operation is an important feature. Is there any way that we could support asynchronous operations in swift-corelibs-foundation, in the absence of KVO? Might it be acceptable to add extra temporary public API to enable this? Many thanks, -- Ian Partridge ___ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
Re: [swift-corelibs-dev] NSMutableData memory leak
We're continuing to investigate this, and have raised SR-1552 to track it - https://bugs.swift.org/browse/SR-1552 -- Ian Partridge ___ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
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 allocated memory as managed by the > deallocator blocks. So I bet the problem is that the code-path for > NSMutableData(capacity: 0) is hitting the don’t deallocate code path > incorrectly (where as the other versions are hitting the appropriate > flagging; hence the crashes) > > Does this also occur in the Darwin builds of this? (Using SwiftFoundtion > instead of Foundation) Yes, I have been investigating this using a new TestNSData test under XCode. -- Ian Partridge ___ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
[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 with Valgrind's massif profiler shows this stacktrace is
responsible for the leak:
67.36% (114,349B) (heap allocation functions) malloc/new/new[],
--alloc-fns, etc.
->65.01% (110,352B) 0x59F7A89: _CFDataInit
->65.01% (110,352B) 0x5B8A8DF:
_TTSf4n_n_n_g_n___TFC10Foundation6NSDatacfT5bytesGSqGSpT___6lengthSi4copySb11deallocatorGSqFTGSpT__Si_T___S0_
->65.01% (110,352B) 0x5B873ED:
_TFC10Foundation13NSMutableDataCfT8capacitySi_GSqS0__
->65.01% (110,352B) 0x40105D: main
I've stepped through the code with a debugger and observed that the
requested capacity is thrown away
[1]
to begin with. The leak occurs regardless of the capacity requested.
The deinitializer for NSData does call through to _CFDeinit(), which does
then call the finalize()
[2]
function and hence through to __CFDataDeallocate()
[3].
However, once in __CFDataDeallocate(), the code to free the buffer is
skipped, because __kCFDontDeallocate is set.
If I hack _CFDataInit() so that __kCFDontDeallocate isn't set (by
commenting out this line
[4])
then I get crashes elsewhere - so this obviously isn't the right approach.
I can see that some work has been done in this area
[5]
previously by Philippe so I'm wondering if anyone can advise on what might
be going on here?
The init?(length:) initializer avoids CFData entirely and calls malloc()
and free() directly. I'm not sure why that approach was taken and whether
it's relevant to my issue.
Any help would be gratefully received!
Thanks,
[1]
https://github.com/apple/swift-corelibs-foundation/blob/df239bbbdf5bcdd9ea31c394c6af4dd7c328f99d/Foundation/NSData.swift#L904
[2]
https://github.com/apple/swift-corelibs-foundation/blob/ea6179dd35be2c7d9a8f953579f626a5f1be6511/CoreFoundation/Base.subproj/CFRuntime.c#L1773
[3]
https://github.com/apple/swift-corelibs-foundation/blob/ea3014bd7883e428727272118cbf37dc56522be6/CoreFoundation/Collections.subproj/CFData.c#L294
[4]
https://github.com/apple/swift-corelibs-foundation/blob/ea3014bd7883e428727272118cbf37dc56522be6/CoreFoundation/Collections.subproj/CFData.c#L337
[5]
https://github.com/apple/swift-corelibs-foundation/commit/ea3014bd7883e428727272118cbf37dc56522be6
--
Ian Partridge
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
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 I spotted in the output of:
for i in 1..<1000 {
print("\(i) " + NSHTTPURLResponse.localizedStringForStatusCode(i))
}
on Obj-C Foundation.
600 returns the empty string! Output is at
https://gist.github.com/ianpartridge/2d34e29d97b42c260931 - have a
look...
--
Ian Partridge
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
[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 this is "OK". The Obj-C implementation also returns strings for invalid status codes, instead of the empty string. For example, if you ask for status code 666 (an invalid code) you get "server error". My instinct is we should start afresh and follow the RFC, as people are unlikely to be relying on the content of these strings. Thanks for your time! -- Ian Partridge ___ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
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 for bringing the implementation of .localizedStringForStatusCode() up to date with the latest specs? Best wishes, -- Ian Partridge ___ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
