Re: [swift-corelibs-dev] Strange behavior the same code fails when building a Cocoa CLI and succeeds in Swift-corelibs-foundation context.

> On Dec 18, 2017, at 9:29 AM, Benoit Pereira da silva wrote: > > Thanks Philippe, > > >> Good find, >> You can make a pull request and we can get our continuous integration >> servers to start building that and testing your change – that is probably >> the easiest way to get validation on

Re: [swift-corelibs-dev] Strange behavior the same code fails when building a Cocoa CLI and succeeds in Swift-corelibs-foundation context.

Good find, You can make a pull request and we can get our continuous integration servers to start building that and testing your change – that is probably the easiest way to get validation on your tests and changes. There are a few issues however with your test that might be worth considering.

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

Looking through some of them they are somewhat similar to the Foundation APIs, but there are a few improvements that I think would make them more compelling for generalized use. I don’t think that it is out of the question to perhaps merge the two concepts and reduce to Foundation as the place t

Re: [swift-corelibs-dev] Encountering "Constant strings cannot be deallocated" in Linux foundation

I think that perhaps we have a problem with the retain count flags in the definition of CFSTR. Previously the pinned reference would prevent the deallocation. This may have gotten clobbered with the latest CF import. Sent from my iPhone > On Nov 29, 2017, at 7:55 PM, Brandon Williams via swift-

Re: [swift-corelibs-dev] Encountering "Constant strings cannot be deallocated"

Is this with a recent build? Do you know what commit the swift-corelibs-foundation is from? That might help nail down what is going on here. > On Nov 16, 2017, at 2:41 PM, Brandon Williams via swift-corelibs-dev > wrote: > > Hello! I have a test case that when run on Linux somehow encounters

[swift-corelibs-dev] Latest CoreFoundation import from High Sierra

Thank you for your patience with this process. This latest release took a bit longer than we expected. But here is the pull request for the changes to CoreFoundation to reflect the changes in High Sierra: https://github.com/apple/swift-corelibs-foundation/pull/1305

Re: [swift-corelibs-dev] [swift-dev] Foundation Data Behavior Different (read: crashes) in Swift 3.1 and Swift 3.2

This is expected behaviors of collections and their slices. The previous result was a bug. I agree that collections in general and their slices need more documentation. Sent from my iPhone > On Aug 24, 2017, at 11:28 AM, Ryan Lovelett > wrote: > > I think your onto it Philippe but then why i

Re: [swift-corelibs-dev] [swift-dev] Foundation Data Behavior Different (read: crashes) in Swift 3.1 and Swift 3.2

I see the issue.. the latest version traps (appropriately so). let str = String(bytes: data[0..<2], encoding: .utf8)! The sub-range of the slice you have is incorrectly indexed. Try this out (I am presuming this is what you mean): let str = String(bytes: data[data.startIndex..<(data.startIndex

Re: [swift-corelibs-dev] [swift-dev] Foundation Data Behavior Different (read: crashes) in Swift 3.1 and Swift 3.2

Is there a radar or bugs.swift.org ticket filed on this? I presume because of the import this is a Darwin thing and not a linux thing. > On Aug 24, 2017, at 11:05 AM, Michael Gottesman via swift-dev > wrote: > > >> On Aug 24, 2017, at 10:47 AM, Ryan Lovelett via swift-dev >> wrote: >> >> I

Re: [swift-corelibs-dev] NSRegularExpression performance

From a performance standpoint there are a few things going on here. 1) I would highly suggest to have a compiled NSRegularExpression stored once per pattern. From what I can tell this is true for the code listed? Regexes in general are not always best to re-create all the time since it has to ha

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

You can also add a user defined Xcode setting so that others don’t have to set that default: SWIFT_INDEX_STORE_ENABLE and set it to NO > On Jun 27, 2017, at 8:29 AM, Ian Partridge via swift-corelibs-dev > wrote: > > On 27 June 2017 at 15:42, Ian Partridge > wrote:

Re: [swift-corelibs-dev] CFStringTokenizer

That particular implementation is not part of the open source side of CF, so a re-implementation in Swift/C would be the way to go here. > On Jun 22, 2017, at 9:44 AM, Andy Best via swift-corelibs-dev > wrote: > > Hey, > > I'm looking at implementing the final missing NSString method ( > enu

Re: [swift-corelibs-dev] Mark NSUnimplemented functions as unavailable.

It might be also useful to keep track of each one of these so we can make sure there are bugs for each one. (Even if it is a list that a script could create tickets). Many of the NSUnimplemented methods are good points to start contributing. > On May 10, 2017, at 16:59, Sergej Jaskiewicz via sw

Re: [swift-corelibs-dev] Mark NSUnimplemented functions as unavailable.

This of course is predicated upon availability macros working appropriately on linux (which last time I checked we don’t have a version variant). It is definitely worth investigation. > On May 10, 2017, at 16:41, Tony Parker via swift-corelibs-dev > wrote: > > Hi Sergej, > > This is a good i

Re: [swift-corelibs-dev] Building swift with xctest and foundation fails

You need to also pass --libdispatch but I am not quite sure that will fully fix the problem at hand. Sent from my iPhone > On Mar 29, 2017, at 6:29 PM, Mohit Athwani via swift-corelibs-dev > wrote: > > I'm trying to get back to work starting from scratch on Swift Foundation on > my Ubuntu 16

Re: [swift-corelibs-dev] Query on bridgeable classes

The reasoning why is that some classes are designed as a has-a relationship instead of an is-a relationship. For example a NSRunLoop has a CFRunLoopRef but a NSString is a CFStringRef. This means that you cannot pass a NSRunLoop to a function that takes a CFRunLoopRef by design. Where-as any met

Re: [swift-corelibs-dev] [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 16.10 (master) #2022

That would be new; I have not seen that failure before. the method is quite droll - it just calls sin/cos and resets the m values accordingly. Did sin/cos change? the values being sent in are reasonable (not at a point it would be in any question of the return value) > On Feb 20, 2017, at 9:1

Re: [swift-corelibs-dev] Building Foundation with SwiftPM

So there are a few issues that would be a bit tricky to deal with: SwiftPM uses Foundation so you would have to devise some way to build SwiftPM either without Foundation (which seems sub-optimal or replication of effort/code), directly importing parts of Foundation into the code-base for Swift

Re: [swift-corelibs-dev] swift-corelibs-dev build-script with --foundation is not working for me

Currently swift-corelibs-foundation only builds as a dynamic library. I wonder if the option —build-swift-static-stdlib is causing issue with that. > On Jan 26, 2017, at 12:57 AM, Kris Simon via swift-corelibs-dev > wrote: > > Hi, > > a couple of days ago i ran into swift on linux. The whole

Re: [swift-corelibs-dev] [swift-users] DateFormatter crash on second usage (new instance) on Linux (swift 3.0.1)

You are probably missing the package libblocksruntime-dev. That would cause that failure. Sent from my iPhone > On Jan 26, 2017, at 6:33 AM, Dennis Schafroth wrote: > > Thanks for the suggestions. > > It works with 3.0.2 but won't compile with 3.1 beta for Ubuntu 14.04. Missing > a Block.h

Re: [swift-corelibs-dev] [swift-users] DateFormatter crash on second usage (new instance) on Linux (swift 3.0.1)

We should run those tests with ASAN, I thought I had fixed that with the Sierra merge. Sent from my iPhone > On Jan 25, 2017, at 6:11 PM, Will Stanton via swift-corelibs-dev > wrote: > > Based on the backtrace, I think the code is running into a memory issue with > Swift Foundation: > https:

Re: [swift-corelibs-dev] Asynchronous Operations

> On Jan 20, 2017, at 7:55 AM, Ian Partridge via swift-corelibs-dev > wrote: > > 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,

Re: [swift-corelibs-dev] Opinions wanted: Special Handling of /proc FileSystem on Linux?

IMHO it seems reasonable for Foundation to return the contents of procfs items when constructing Data. That being said - I would probably favor a more structured parsing for actually using that resultant Data than just a blob. Those structured elements are probably not very portable so perhaps t

Re: [swift-corelibs-dev] Scanner with Swift 3

It is worth noting that this is not the only case that has this “flaw”. In many of the AUMPs exposed in Foundation they are really either “out” parameters or in a few cases “inout” parameters (and I think there are a handful of “in” style parameters too). The major issue for refining this in th

Re: [swift-corelibs-dev] Executable swift files?

They should not be marked as executable, that looks to be a mistake. > On Nov 28, 2016, at 9:33 AM, Alex Blewitt via swift-corelibs-dev > wrote: > > Is there any particular reason why the following files have the executable > bits set? > > ./Foundation/NSFileHandle.swift > ./Foundation/NSNoti

Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

Furthermore isn’t it a bit of a conflict if we have multiple versions of Foundation running apps on a server? I would expect that the mutable state of cookies should never be shared across processes not just from a security standpoint but also from a versioning standpoint. Let have a scenario

[swift-corelibs-dev] Updates to CF imports to swift-corelibs-foundation

I just recently put up a PR that brings in the Apple changes from CoreFoundation to swift-corelibs-foundation. This brings our CF backing for SCLF to be in line with the Sierra/iOS10 release. I was unable to test other platforms like Android, Cygwin, or other architectures like Raspberry Pi or

Re: [swift-corelibs-dev] Calendar identifiers

The definition should be; NSString * const kCFCalendarIdentifierISO8601 = @"iso8601”; It was likely empty since it was probably un-implemented. > On Oct 4, 2016, at 8:34 AM, Pushkar N Kulkarni via swift-corelibs-dev > wrote: > > Hi Alex, > > Thanks for your response. > > This failure does

Re: [swift-corelibs-dev] Coercion problems on Linux

>From a technical perspective it is not impossible to do however as of current >reference type to structural type bridging is conflated with the objective c >runtime being present (specifically present on Darwin targets). Personally I >think we need a better answer than what we have today but I

Re: [swift-corelibs-dev] Coercion problems on Linux

That particular issue we could plaster over with generics. In general it is because we don't have bridging on Linux. Sent from my iPhone > On Sep 8, 2016, at 8:36 AM, Pushkar N Kulkarni wrote: > > Hi Tony/Philippe, > > There've been a few bug reports related to the coercion problems between

Re: [swift-corelibs-dev] Measurement Formatters & ICU

Just because it was super-easy for me to fix: https://github.com/apple/swift-corelibs-foundation/pull/587 That should allow C++ to be built if desired into CoreFoundation. However round tripping that into the Darwin version of CoreFoundation may be a bit cagey. > On Aug 23, 2016, at 4:53 PM, He

Re: [swift-corelibs-dev] f8c3fe6c breaks on Darwin

Looks like there was a merge done without the requirement that I set forth in the pull request. This means the Xcode project is properly broken now. > On Aug 23, 2016, at 4:14 PM, Luke Howard via swift-corelibs-dev > wrote: > > c26f465e breaks even further on Darwin – Xcode project not updated

Re: [swift-corelibs-dev] Measurement Formatters & ICU

+Daphne since she was the one who implemented the Darwin version of the unit and measurements and I think she has some ideas on how we could perhaps build a uniform version for Linux hosts. Per the C++; the script for that phase probably needs a bit of love since we haven’t had a need for C++ t

Re: [swift-corelibs-dev] f8c3fe6c breaks on Darwin

Tossed up a PR for correcting this uniformly without needing alteration of the #if statements https://github.com/apple/swift-corelibs-foundation/pull/584 > On Aug 23, 2016, at 8:42 AM, Chris Bailey via swift-corelibs-dev > wrote: > > We're currently making the last few changes which should me

Re: [swift-corelibs-dev] NSObject's performSelector(inBackground:with:) doesn't feel right in Swift 3

I would claim that perhaps it should be: open func perform(inBackground aSelector: Selector, with anArgument: Any?) That way it matches the completion family of the rest of performing. But if that is the case we should take a look at the onMainThread ones as well so they look like this perhaps:

Re: [swift-corelibs-dev] NSObject's performSelector(inBackground:with:) doesn't feel right in Swift 3

> On Aug 16, 2016, at 8:42 AM, Philippe Hausler via swift-corelibs-dev > wrote: > > Those methods should probably all belong to the same family of `perform` but > it matches the method naming of: > > open func performSelector(onMainThread aSelector: Selector, with arg: A

Re: [swift-corelibs-dev] NSObject's performSelector(inBackground:with:) doesn't feel right in Swift 3

Those methods should probably all belong to the same family of `perform` but it matches the method naming of: open func performSelector(onMainThread aSelector: Selector, with arg: Any?, waitUntilDone wait: Bool, modes array: [String]?) But perhaps the naming family should belong to this one: o

Re: [swift-corelibs-dev] Implementing JSONSerialization.jsonObject(with stream)

We had changed the return type of JSONSerialization to be Any such that it avoided the caller needing to bridge types (which works poorly on linux). Even though this is an API change technically, just change the return type to match the other JSONSerialization methods. > On Jul 15, 2016, at 12:

Re: [swift-corelibs-dev] NSKeyValueCoding and the Swift Foundation

Both KVC and KVO require dynamic dispatching and selector manipulation that is not present in swift-corelibs-foundation (since everything is based on swift objects). > On Jun 12, 2016, at 10:54 AM, Lars Sonchocky-Helldorf via swift-corelibs-dev > wrote: > > Hi everybody, > > it came to my at

Re: [swift-corelibs-dev] How to build swift-corelibs-foundation from command line

It needs to be bootstrapped in a different way for OS X builds (primarily since there is already the system framework of Foundation present). Are you instilling the toolchain to /Library/Developer/Toolchains? And do you have it selected in the preferences in Xcode? > On Jun 7, 2016, at 6:03 PM,

Re: [swift-corelibs-dev] How to build swift-corelibs-foundation from command line

Building it on Linux just pass --foundation. Building it on Mac OS X you will need to build the toolchain, install that and then build via the Xcode project. > On Jun 7, 2016, at 5:59 PM, Rajeev Jeyaraj via swift-corelibs-dev > wrote: > > Hi All, > > I am trying to build the corelibs-foundati

Re: [swift-corelibs-dev] unable to build swift core foundation

The toolcahins are in a bit of flux right now so you may need to build your own custom one. If you want you can build one via the easy command of ./swift/utils/build-toolchain or if you need to be a bit more fancy (or want to only build partial slices of the toolchain) I posted a version of a sc

Re: [swift-corelibs-dev] swift-corelibs-xctest JIRA dashboard

break on Linux. Sent from my iPhone > On May 24, 2016, at 1:13 AM, Rob Allen wrote: > > >> On 24 May 2016, at 05:38, Philippe Hausler via swift-corelibs-dev >> wrote: >> >> I took a few moments to file a few more starters for Foundation (hopefully I >> sho

Re: [swift-corelibs-dev] swift-corelibs-xctest JIRA dashboard

I took a few moments to file a few more starters for Foundation (hopefully I should be able to fill out a few more soon). I ran across a some nice ones that should be relatively trivial to knock out. I think for Foundation the marker for a good starter bug would be things that are highly testabl

Re: [swift-corelibs-dev] Objective-C Foundation vs CoreLibs Foundation

There are a few considerations for the package manager: we may have circular build requirements, swift-corelibs-foundation does some squirrelly things with linking and compilation like linker scripts and tacked on assembly data segments. I am not certain those edge use cases are supported yet.

Re: [swift-corelibs-dev] Compilation Error - Which Toolchain

Just pushed the revert, I will revisit it when we have the next drop of the toolchains for all platforms that include the required change for this correction. > On May 20, 2016, at 9:05 AM, Philippe Hausler via swift-corelibs-dev > wrote: > > This was a change in the standar

Re: [swift-corelibs-dev] Compilation Error - Which Toolchain

This was a change in the standard library. I presumed that change had been in for a full build cycle. However since that looks like it is not the case I am going to revert the offending commit for now and revisit it when the binaries are rev'd > On May 19, 2016, at 3:48 PM, David Hart via swift

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

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

Re: [swift-corelibs-dev] Setting property "maxConcurrentOperationCount = 1" of NSOperation fails to execute operations using OpenSource Foundation.

I have a feeling this is associated with the changes for IUO types that recently landed. I am very worried that this actually could happen on Darwin targets as well. Perhaps it is the swift overlay for dispatch that is correcting the failure on Darwin and the dispatch on Linux is missing that a

Re: [swift-corelibs-dev] Setting property "maxConcurrentOperationCount = 1" of NSOperation fails to execute operations using OpenSource Foundation.

Hmm that seems unfortunate. I wonder if the serial creation is due to an unwrapped optional? var attr: dispatch_queue_attr_t? instead might do the trick… or alternatively we could just let the underlying queue be concurrent all the time and enforce the max ops via making the semaphore always in

Re: [swift-corelibs-dev] NSEnergyFormatter

Sorry one slight clarification; the uplrules is only for the pluralization; uameasfmt_getMultipleUnitNames is the other major component. > On Apr 18, 2016, at 9:16 AM, Philippe Hausler via swift-corelibs-dev > wrote: > > The formatter in this case should probably query ICU4

Re: [swift-corelibs-dev] NSEnergyFormatter

The formatter in this case should probably query ICU4C’s function uplrules_select (and other associated functions). On Darwin energy, length and mass formatters all funnel to one unit formatter that can abstractly handle each of those cases (which might not be a bad idea to have in the swift ver

Re: [swift-corelibs-dev] NSMassFormatter implementation

Absolutely! If you have any questions about the details of how the objc version works feel free to reach out. > On Apr 14, 2016, at 5:14 AM, Mauricio Meirelles via swift-corelibs-dev > wrote: > > Hi all, > I was thinking on start the NSMassFormatter implementation. > Are you accepting PR for t

Re: [swift-corelibs-dev] Why isn't Foundation shipped in OS X and iOS open source?

Some of this topic I am unqualified to comment on but I will try to address some of the concerns. With the goal of matching the surface area of APIs and behavior that are important for cross platform development we can get very close no matter the backing language. In the areas that are potenti

Re: [swift-corelibs-dev] NSOperationQueue and friends

; For some reason DEPLOYMENT_ENABLE_LIBDISPATCH isn't set, but I guess it >>> should be? >>> >>> /Daniel >>> >>> >>>> On 26 Mar 2016, at 22:54, Philippe Hausler wrote: >>>> >>>> Is that on Linux? Perhaps

Re: [swift-corelibs-dev] NSOperationQueue and friends

ppe Hausler wrote: >> >> Is that on Linux? Perhaps it is because it is missing run loop interaction? >> >> Sent from my iPhone >> >> On Mar 26, 2016, at 10:52 AM, Daniel Eggert wrote: >> >>>> >>>> On 25 Mar 2016, at 21:15, P

Re: [swift-corelibs-dev] NSOperationQueue and friends

Is that on Linux? Perhaps it is because it is missing run loop interaction? Sent from my iPhone On Mar 26, 2016, at 10:52 AM, Daniel Eggert wrote: >> >> On 25 Mar 2016, at 21:15, Philippe Hausler via swift-corelibs-dev >> wrote: >> >> I know a few of you have

[swift-corelibs-dev] NSOperationQueue and friends

I know a few of you have been waiting for this: I just pushed an initial implementation of NSOperationQueue, NSOperation and NSBlockOperation. It is worth noting that this implementaiton has a few behavioral differences between this implementation and the one implemented in objective-c. Part of

Re: [swift-corelibs-dev] NSURLSession & libcurl

The swift-corelibs-foundation version of CF is a static library that is being built into the Foundation product dynamic library so the linkage for libxml2 and anything else should be on that. The layout of how linking works for the Darwin version is different because of how we split the layers.

Re: [swift-corelibs-dev] non-inherited init

Runtimes > > Simplicity is prerequisite for reliability - Edsger W. Dijkstra > > > > -swift-corelibs-dev-boun...@swift.org > <mailto:-swift-corelibs-dev-boun...@swift.org> wrote: - > To: Daniel Eggert mailto:danielegg...@me.com>> > From: Philipp

Re: [swift-corelibs-dev] A question about @NSCopying

> On Mar 18, 2016, at 1:18 PM, Pushkar N Kulkarni via swift-corelibs-dev > wrote: > > I am trying to implement some of the methods and properties in NSOrderedSet. > > The read-only property "reversedOrderedSet" has the @NSCopying attribute > according to the NSOrderedSet class reference. >

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

Well the interesting part here is that it is a localized string for a status code, so these should be a human readable output intended for display. If they were just stringForStatusCode then I would agree they should match the RFC, but since it is localized I think we shouldn’t try and reimpleme

Re: [swift-corelibs-dev] non-inherited init

That is a comment emitted by the importer, unfortunately it is impossible for non objc to mimic that behavior 100% because it is an init method that is constructed from a class method. @interface Foo : NSObject + (Foo *)fooNamed:(NSString *)name; // this is not an inherited init method in that

Re: [swift-corelibs-dev] NSURLRequest — missing attributes

I personally find inline documentation helpful as a reminder of the goal of the desired behavior. Sent from my iPhone > On Mar 16, 2016, at 7:47 AM, Daniel Eggert via swift-corelibs-dev > wrote: > > I created https://github.com/apple/swift-corelibs-foundation/pull/290 > to add 4 attributes t

Re: [swift-corelibs-dev] Cannot call CFStreamCreatePairWithSocket on Linux

CFNetwork is a separate dynamic library that is lazily loaded via dlopen. So we don’t need to have CFNetwork present to build. > On Mar 15, 2016, at 10:51 AM, Max Howell wrote: > > For interests sake, how come it could link? > >> You are correct, those symbols are from CFNetwork which are not

Re: [swift-corelibs-dev] Cannot call CFStreamCreatePairWithSocket on Linux

You are correct, those symbols are from CFNetwork which are not yet implemented on linux targets. CFStream is implemented but CFSocketStream is not implemented in swift-corelibs-foundation. It could be technically reasonable to port the open source (very old) CFNetwork to linux. However I am fai

Re: [swift-corelibs-dev] NSURLSession & libcurl

That seems pretty reasonable to me, I guess the only thing to watch out for is private vs internal. Sent from my iPhone > On Mar 15, 2016, at 2:44 AM, Daniel Eggert wrote: > > Is it ok for me to split the libcurl specific code inside Foundation into a > separate file, say NSURLSession+curl.sw

Re: [swift-corelibs-dev] Locale formatting (UAMeasureFormat)

Length, Energy and Mass formatters should definitely use the ICU backing. It might be a good idea to funnel them all into one unit formatter access point. I personally find it is sometimes easier to interface to C APIs in C and expose them back up as simple funnel methods but it depends on which

Re: [swift-corelibs-dev] NSRegularExpression implementation

NSRegularExpression is backed by ICU’s uregex; there is no regex support in CF however since ICU is a pretty involved C API it would not be un-reasonable to create an accessor API to make certain behaviors easier to deal with in swift. > On Jan 4, 2016, at 8:58 PM, Lukas Stabe via swift-corelibs

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

No C strings import as UnsafePointer for some reason; they all import as Int8 e.g. public func pthread_setname_np(_: UnsafePointer) -> Int32 > On Jan 4, 2016, at 1:20 PM, Tony Parker via swift-corelibs-dev > wrote: > > Hi Luke, > >> On Jan 2, 2016, at 8:28 PM, Luke Howard via swift-corelibs

Re: [swift-corelibs-dev] Equality, etc in Foundation

Actually I think we already got this one integrated. > On Jan 4, 2016, at 12:58 PM, Tony Parker via swift-corelibs-dev > wrote: > > Hi Luke, > > Your proposed fix seems reasonable to me. Did you submit it as a PR too? > > Thanks, > - Tony > >> On Dec 29, 2015, at 11:28 PM, Luke Howard via sw

Re: [swift-corelibs-dev] relationship of CF

gt; On Jan 2, 2016, at 3:00 PM, Philippe Hausler via swift-corelibs-dev > mailto:swift-corelibs-dev@swift.org>> wrote: > >> >> Responses inline: >> >>> On Jan 2, 2016, at 3:58 AM, Drew Crawford via swift-corelibs-dev >>> mailto:swift-corelibs-dev@

Re: [swift-corelibs-dev] relationship of CF

Responses inline: > On Jan 2, 2016, at 3:58 AM, Drew Crawford via swift-corelibs-dev > wrote: > > I had a question about something I saw in the docs: > >> A significant portion of the implementation of Foundation on Apple platforms >> is provided by another framework called CoreFoundation (a

Re: [swift-corelibs-dev] bridging (SR-138)

String is bridged it just is not yet implicitly converted via the compiler; we are missing certain functionality due to the compiler not supporting the objc code paths on linux. The re-naming of swift classes exposed from Foundation will likely leave the class NSString still a thing (however it

Re: [swift-corelibs-dev] NSCoding methods

Responses inline: > On Dec 29, 2015, at 5:03 AM, Luke Howard wrote: > > OK, so I’ve cleaned up the commit history for the NSCoding branch, you can > find it here still: > > https://github.com/lhoward/swift-corelibs-foundation/tree/lhoward/nscoding >

Re: [swift-corelibs-dev] NSCoding methods

It is ok on the special types; those are harder than they may seem… NSValue in Darwin has some limitations like that especially when it comes to secure coding or non standard aligned values. > On Dec 28, 2015, at 3:52 PM, Luke Howard wrote: > > NSConcreteValue is in the current nscoding branch

Re: [swift-corelibs-dev] NSCoding methods

> On Dec 28, 2015, at 3:10 PM, Luke Howard wrote: > > >> On 29 Dec 2015, at 3:01 AM, Philippe Hausler wrote: >> >> Not certain what you mean there; each NSValue is just a identity of a key in >> a dictionary to a NSConcreteValue that the methods forward to? That would >> mean that each meth

Re: [swift-corelibs-dev] NSCoding methods

Responses inline; > On Dec 28, 2015, at 5:01 AM, Luke Howard via swift-corelibs-dev > wrote: > > >> On 27 Dec 2015, at 9:31 PM, Luke Howard via swift-corelibs-dev >> wrote: >> >> I’ve implemented but not extensively tested decodeValueOfObjCType(). Do we >> need to support NSConcreteValue?

Re: [swift-corelibs-dev] getCString question

This probably is a bug. Additionally this seems to also be missing the NSCF callout as well. > On Dec 26, 2015, at 10:46 PM, Luke Howard via swift-corelibs-dev > wrote: > > In the implementation of getCString() in NSString.swift, it doesn’t appear to > add the terminating NUL byte – is this a

Re: [swift-corelibs-dev] NSCoding methods

Yea that seems to work on linux just fine. I made some more linux portability corrections and it is now buildable on ubuntu 14. > On Dec 26, 2015, at 8:15 PM, Luke Howard wrote: > > >> On 27 Dec 2015, at 3:09 PM, Philippe Hausler wrote: >> >> So a few results so far from the linux side: I ra

Re: [swift-corelibs-dev] NSCoding methods

ppe Hausler via swift-corelibs-dev > wrote: > > I think what I might do to help get this ball rolling is actually create a > branch on the official repo; That way I can kick off CI etc on it. > >> On Dec 26, 2015, at 7:09 PM, Luke Howard wrote: >> >> >

Re: [swift-corelibs-dev] NSCoding methods

I think what I might do to help get this ball rolling is actually create a branch on the official repo; That way I can kick off CI etc on it. > On Dec 26, 2015, at 7:09 PM, Luke Howard wrote: > > >> On 27 Dec 2015, at 1:54 PM, Philippe Hausler wrote: >> >> It might be good for review side of

Re: [swift-corelibs-dev] NSCoding methods

> On Dec 26, 2015, at 3:33 PM, Luke Howard wrote: > > >> On 27 Dec 2015, at 3:45 AM, Philippe Hausler wrote: >> >> Totally reasonable since that is a limitation that will cause subclassers to >> not be able to implement that even outside of Foundation. >> >> What would help most for unit te

Re: [swift-corelibs-dev] NSCoding methods

Totally reasonable since that is a limitation that will cause subclassers to not be able to implement that even outside of Foundation. What would help most for unit testing what you have so far? I have a few init?(coder:) implementations that should match the implementations on darwin; primaril

Re: [swift-corelibs-dev] NSCoding methods

Likely we will have to change that signature to instead of being NSSet and Set respectively to be more compatible; however this will be an API change. It might be good to mock up a swift translation layer for these APIs to simulate what it would be like on Darwin if we altered these to be rename

Re: [swift-corelibs-dev] NSCoding methods

So one thing we can do in the interim until there is a sanctioned way for us to convert strings to classes and classes to strings is we can register the classes globally for transformation so that the Foundation or SwiftFoundation module name won’t be an issue. By doing this early on in the ini

Re: [swift-corelibs-dev] NSCoding methods

<546e5b5e 15c244a1 aa96eb90 30c3f7f6>; >> }, >> { >> "$classes" = ( >> NSUUID, >> NSObject >> ); >> "$classname" = NSUUID; >

Re: [swift-corelibs-dev] NSCoding methods

non-mangled name > is not unique. The only correct answer for arbitrary classes is to use > mangled names, or something that maps one-to-one with mangled names. > > Now, Foundation classes are not arbitrary classes, but then I don't see why > we'd need to use mangled names

Re: [swift-corelibs-dev] Upcoming holiday schedule

dule > Message-ID: <mailto:ad8f0e5c-2555-4c15-a7fa-7c852ad2e...@apple.com>> > Content-Type: text/plain; charset="utf-8" > I will also be out starting tomorrow through the end of the month which means > XCTest will get little coverage during that time. > Mike >

Re: [swift-corelibs-dev] NSCoding methods

To clarify the goals: I think it is reasonable for us to have a goal to be able to encode/decode archives from foreign targets; e.g. linux encodes an archive and mac os x decodes or iOS encodes and linux decodes. This will allow for server architecture to transmit binary archives across the wire

Re: [swift-corelibs-dev] NSCoding methods

Somewhat; the mangled symbols are technically searchable by dlsym but that seems like a hack. Perhaps one of the stdlib/compiler team might be able to speak more on this than myself and they may have suggestions for a better way. Foundation is at a special spot in which we can sometimes get spec

Re: [swift-corelibs-dev] NSXMLNode and Friends

Dealing with the cross platform part of the module map portion may be a bit tricky; I had to use some of libxml2 for CFXMLInterface it is effectively a simple wrapper around a few xml c calls that are a bit swift-friendlier. Perhaps that might make some of that integration easier. However if you

Re: [swift-corelibs-dev] Recommended posix_spawnattr_t for NSTask's implementation

I would definitely say that posix_spawn is the correct path to implement this; that will keep pretty close to the way the one on darwin works; Couple of suggestions: posix_spawnattr_setsigmask should be set to the empty signal set the attribute flags should probably be POSIX_SPAWN_CLOEXEC_DEFAU

Re: [swift-corelibs-dev] Upcoming holiday schedule

I will probably be around a bit more than Tony over the break; I will try to keep up with the pull requests. There are a few things that I think will speed up the process so that we can keep things running well: Discrete commits that implement a specific thing; reviewing two different spots so

Re: [swift-corelibs-dev] Possible Proposal: Foundation corelibs API change necessary for NSPredicate

As a general rule of thumb we ❤️radars. In this case I have already filed a bug with the component owner since it clearly looks like this is perhaps a incorrectly annotated API. So a PR for this is quite reasonable to change to ? since it would be a bit difficult to implement else wise. > On De

Re: [swift-corelibs-dev] Possible Proposal: Foundation corelibs API change necessary for NSPredicate

This might actually just be a bug in our annotations of what is nullable and what is not. I would have to double check but it seems pretty reasonable that it should have been nullable to begin with. > On Dec 14, 2015, at 10:06 AM, Kevin Lundberg via swift-corelibs-dev > wrote: > > I have a pe

Re: [swift-corelibs-dev] libdispatch build issue

This is only tangentially related: but I was attempting to build dispatch as well to start work on CFRunLoop and a few other dispatch bound features in Foundation on linux. I was seeing similar failures as Dzianis Fedarenka. Is there a branch/fork that I can grab to test this stuff out w/ bringi

Re: [swift-corelibs-dev] [swift-evolution] Proposal: add `noescape` attribute to public API (particularly libdispatch)

To re-iterate my comment on github; I think this is a great idea. There are a couple of suggestions for scope limiting; since this will require changes in the c and objective-c layers to support this attribute it would be good to limit this for now to just the core libraries (dispatch, XCTest a

[swift-corelibs-dev] Implicit conversions between types will be disabled in Foundation

After seeing numerous failures in type conversions that work in the Mac OS X Xcode project target but don’t work in the Linux target, we have come to the conclusion that implicit conversions are going to have to be disabled for now. I have a change incoming that will require all conversions such

Re: [swift-corelibs-dev] Proposal: Conforming NSDate to Comparable

In all that seems like a pretty reasonable concept. Foundation is going to be using the same evolution template as the rest of the Swift evolution process; could you fill out a draft of that and I can help campion your proposal to the component owner for NSDate and we can see how this will fair

  1   2   >