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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

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 > <swift-corelibs-dev@swift.org> wrote: > > Those methods should probably all belong to the same family of `perform` but > it matches the method naming of: > > open func performSelector(onMai

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

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

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

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 <r...@akrabat.com> wrote: > > >> On 24 May 2016, at 05:38, Philippe Hausler via swift-corelibs-dev >> <swift-corelibs-dev@swift.org> wrote: >> >> I took a few moments to file

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

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

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

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

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

<phaus...@apple.com> 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 <danielegg...@me.com>

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

, at 22:54, Philippe Hausler <phaus...@apple.com> 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 <danielegg...@me.com> wrot

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 <danielegg...@me.com> wrote: >> >> On 25 Mar 2016, at 21:15, Philippe Hausler via swift-corelibs-dev >> <swift-corelibs-dev

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

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,

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

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

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

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

Re: [swift-corelibs-dev] NSCoding methods

> "$classname" = NSUUID; >> }, >> { >> "$classes" = ( >> "Archiver.NSUUID", >> NSObject >> ); >> "$classname" =

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

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

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

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/

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