[swift-corelibs-dev] Looking at corelibs-foundation

[David Hart via swift-corelibs-dev]

Hello people,

I wanted to start giving a hand on corelibs-foundation but hit two obstacles 
I’d like to discuss:

It feels difficult to know where help is needed because the ReleaseNotes, 
Status and Know Issues docs have not been updated in a very long time, as if 
abandoned. Hopefully we can update hem, but perhaps a rule should be put in 
place so that no pull request is merged without the corresponding update in the 
documentation?

I tried downloading the master branch of corelibs-foundation and running the 
tests before starting any work, but several of them crashed or failed. I am on 
OS X, Xcode 7.3.1, up to date on the master branches of corelibs-foundation and 
corelibs-xctest and am using the latest development snapshot. For reference, 
the failing tests are:

TestNSString.test_initializeWithFormat3
TestNSTask.test_pipe_stderr
TestNSTask.test_pipe_stdout_and_stderr_same_pipe
TestNSTask.test_passthrough_environment
TestNSTask.test_no_environment
TestNSTask.test_custom_environment
TestNSUserDefaults.test_createUserDefaults
TestNSUserDefaults.test_getRegisteredDefaultItem
TestNSXMLDocument.test_xpath

Any ideas? Perhaps I’m doing something wrong.

I was surprised to see fairly little tests for certain classes NSIndexPath, 
NSUserDefaults, NSScanner. Is that because the code was written before the Open 
Source project started? What are the rules on test quality and how are they 
applied?

More generally, I feel worried at how much work is still left, especially with 
the 3.0 beta branches starting. Am I imagining things or does it not look very 
good? What can we do to rally the troops?

A well meaning developer,
David.___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] removal of NSURL.filePathURL as it serves no purpose without file reference URL in Linux

[Bhaktavatsal R Maram via swift-corelibs-dev]

 Hi Rainer,Thank you for your inputs. I'll implement it to return file URL (as no conversion is required for open source foundation).-mbvreddy-swift-corelibs-dev-boun...@swift.org wrote: -To: swift-corelibs-dev@swift.orgFrom: Rainer Brockerhoff via swift-corelibs-dev Sent by: swift-corelibs-dev-boun...@swift.orgDate: 05/07/2016 08:35PMSubject: Re: [swift-corelibs-dev] removal of NSURL.filePathURL as it serves no purpose without file reference URL in LinuxOn 5/7/16 08:07, Bhaktavatsal R Maram via swift-corelibs-dev wrote:> I'm working on implementation of unimplemented properties in NSURL.swift.> > /public var filePathURL: NSURL?/> > As per specification[1] which says "If the receiver is a file reference URL, > this property contains a copy of the URL converted to a file path URL. If the > receiver’s URL is a file path URL, this property contains the original URL. If > the original URL is not a file URL, or if the resource is not reachable or no > longer exists, this property contains |nil|. "> > 'filePathURL' property is to hold copy of file reference URL converted to file > path URL.> > > for example,> > file reference URL - *file:///.file/id=6571367.3617528/*> file path URL - *file:///Users/mbvreddy/workarea/swift/MyTest/MyTest.xcodeproj/*> > File reference URL is a special URL on OS X which is of type > file:///.file/id=./. And it is not available on Linux. APIs > that return file reference URLs [2] on OS X foundation NSURL.fileReferenceURL() > is removed from Linux Foundation.AFAIK this particular format of file reference URLs is an OS Ximplementation detail, and should not be relied upon (nor is it, Ithink, supported on certain file systems).One reason for it, no doubt, is to be able to use low-level file systemAPIs independently of things like maximum path length or POSIX workingfile directory.Nothing precludes an implementation on another platform that leveragesper-file identifiers analogous to volume and file id — or you may evenhave a trivial implementation that just stores the full path fromfileSystemImplementation.> So, I think NSURL.filePathURL also should be removed as it serves no purpose > without file reference URL. Any comments are appreciated.I'm not a Linux user but this will probably unduly restrictcross-platform apps. Using file reference URLs is quite common,especially if at some point you need a path to pass to a POSIX API.-- Rainer Brockerhoff  Belo Horizonte, Brazil"In the affairs of others even fools are wiseIn their own business even sages err."http://brockerhoff.net/blog/___swift-corelibs-dev mailing listswift-corelibs-dev@swift.orghttps://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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