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

[Philippe Hausler via swift-corelibs-dev]

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 with the rest of 
the Darwin side of things.

As you can probably guess; operators are not taken lightly since they exist in 
the global scope and it is good to consider the ramifications of what even 
something as simple as comparison of dates has in general.

> On Dec 5, 2015, at 3:36 PM, Chris Amanse via swift-corelibs-dev 
>  wrote:
> 
> Hello Swift Developers,
> 
> I think it's a good idea to conform NSDate to the Comparable protocol, so 
> instead of using:
> 
> if someDate.compare(today) == .OrderedAscending { }
> 
> Developers can easily compare using compare dates using comparison operators:
> 
> if someDate < today { }
> 
> In my opinion, the code is still readable if developers use comparison 
> operators on NSDates.
> 
> Here's a quick implementation from my swift-corelibs-foundation fork: 
> https://github.com/chrisamanse/swift-corelibs-foundation/commit/3c4eff643c5271de5bec2461798051347be13916
>  
> 
> 
> Thank you.
>  ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

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

[Philippe Hausler via swift-corelibs-dev]

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 as `let dict: 
NSDictionary = [“foo” : “bar”]` to use the bridge method to convert. This is 
just an interim solution until we can get better support on the linux side from 
the compiler to enable implicit conversion between object types and struct 
types (which is handled by the protocol _ObjectiveCBridgeable). The change adds 
a new protocol `_ObjectTypeBridgeable` that still has the functionality so that 
once the compiler can support this feature on linux targets we can re-enable 
implicit conversions.

I would strongly suggest that anyone currently developing build against this 
change to ensure that any implicit conversions are made explicitly.
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

[Philippe Hausler via swift-corelibs-dev]

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 and 
Foundation). 

Most likely future optimizations in c and objective c code can be applied in 
addition to the positive effect to swift code.

> On Dec 8, 2015, at 12:02 AM, Jacob Bandes-Storch via swift-evolution 
>  wrote:
> 
> Alright, I've written up a proposal: 
> https://github.com/apple/swift-evolution/pull/40 
> 
> 
> Feedback welcome!
> 
> Jacob
> 
> On Sat, Dec 5, 2015 at 2:25 PM, Jacob Bandes-Storch  > wrote:
> On Sat, Dec 5, 2015 at 1:40 PM, Tony Parker  > wrote:
> One topic I wanted to discuss was finding a comprehensive list of API that 
> needs the attribute.
> 
> On this subject, here are some other APIs which could use the annotation. 
> Again, I think these should be annotated even in the C/Objective-C headers, 
> so they can benefit C/Objective-C callers as well.
> 
> - bsearch, heapsort, qsort, mergesort, psort, and their _b variants
> 
> "passing test" methods:
> - -[{NSArray,NSOrderedSet} indexOfObjectPassingTest:]
> - -[{NSArray,NSOrderedSet} indexesOfObjectsPassingTest:]
> - -[{NSArray,NSOrderedSet} indexOfObjectsAtIndexes:passingTest:]
> - -[{NSArray,NSOrderedSet} indexesOfObjectsAtIndexes:passingTest:]
> - -[SCNNode childNodesPassingTest:]
> - -[SCNSceneSource entriesPassingTest:]
> - -[AVAudioUnitComponentManager componentsPassingTest:]
> - -[NSIndexSet indexPassingTest:]
> - -[NSIndexSet indexWithOptions:passingTest:]
> - -[NSIndexSet indexesPassingTest:]
> - -[NSIndexSet indexesWithOptions:passingTest:]
> - -[NSIndexSet indexInRange:options:passingTest:]
> - -[NSIndexSet indexesInRange:options:passingTest:]
> - -[NSSet objectsPassingTest:]
> - -[NSSet objectsWithOptions:passingTest:]
> - -[NSDictionary keysOfEntriesPassingTest:]
> - -[NSDictionary keysOfEntriesWithOptions:passingTest:]
> 
> "using comparator" methods:
> - -[NSArray indexOfObject:inSortedRange:options:usingComparator:]
> - -[NSArray sortedArrayUsingComparator:]
> - -[NSArray sortedArrayWithOptions:usingComparator:]
> - -[NSDictionary keysSortedByValueUsingComparator:]
> - -[NSDictionary keysSortedByValueWithOptions:usingComparator:]
> - -[NSMutableArray sortUsingComparator:]
> - -[NSMutableArray sortWithOptions:usingComparator:]
> - -[NSMutableOrderedSet sortWithOptions:usingComparator:]
> - -[NSMutableOrderedSet sortRange:options:usingComparator:]
> 
>  (and some of these have "usingFunction" variants)
> 
> "enumerate using block" methods:
> - -[NSTableView enumerateAvailableRowViewsUsingBlock:]
> - -[SKPhysicsWorld enumerateBodiesAtPoint:usingBlock:]
> - -[SKPhysicsWorld enumerateBodiesInRect:usingBlock:]
> - -[NSData enumerateByteRangesUsingBlock:]
> - -[SCNNode enumerateChildNodesUsingBlock:]
> - -[SCNNode enumerateChildNodesWithName:usingBlock:]
> - -[NSIndexSet enumerateIndexesUsingBlock:]
> - -[NSIndexSet enumerateIndexesWithOptions:usingBlock:]
> - -[NSDictionary enumerateKeysAndObjectsUsingBlock:]
> - -[NSDictionary enumerateKeysAndObjectsWithOptions:usingBlock:]
> - -[NSString enumerateLinesUsingBlock:]
> - -[NSString enumerateSubstringsInRange:options:usingBlock:]
> - -[{NSArray,NSSet,NSOrderedSet} enumerateObjectsUsingBlock:]
> - -[{NSArray,NSSet,NSOrderedSet} enumerateObjectsWithOptions:usingBlock:]
> - -[NSIndexSet enumerateRangesUsingBlock:]
> - -[NSIndexSet enumerateRangesWithOptions:usingBlock:]
> - -[NSIndexSet enumerateRangesInRange:options:usingBlock:]
> - -[MPMediaEntity enumerateValuesForProperties:usingBlock:]
> - -[NSMetadataQuery enumerateResultsUsingBlock:]
> - -[NSMetadataQuery enumerateResultsWithOptions:usingBlock:]
> 
> misc:
> - -[NSDocument performSynchronousFileAccessUsingBlock:]
> 
> Wow, that's more than I expected to find! This is obviously beyond the scope 
> of just libdispatch, and I think a lot of these should probably change 
> upstream, in their original frameworks, internally (not something that 
> community members can really contribute to).
> 
> Arguably, the "enumerateXUsingBlock:" pattern should be bridged to Swift as 
> something SequenceType-ish which can be `for-in`ed.
> 
> Jacob Bandes-Storch
> 
>  ___
> swift-evolution mailing list
> swift-evolut...@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

[Philippe Hausler via swift-corelibs-dev]

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/ bringing stuff up 
in Foundation?

My question is that of design and status of where things are at; CFRunLoop 
requires a method to interoperate with the main dispatch queue via 
_dispatch_get_main_queue_port_4CF and _dispatch_main_queue_callback_4CF. 
CFRunLoop will need to transact upon the same event source type as dispatch to 
ensure the main queue behaves correctly - so what type of event source should 
we be using? A socket? A producer/consumer notification via pthread conditions?

> On Dec 11, 2015, at 8:27 AM, David P Grove via swift-corelibs-dev 
>  wrote:
> 
> swift-corelibs-dev-boun...@swift.org wrote on 12/11/2015 11:19:15 AM:
> > 
> > The linux port is in progress, and even if it built, right now, it 
> > wouldn’t be functional.
> > 
> > -Pierre
> > 
> > Yes. I completely understand that there linux port is not 
> > functional. So I want to contribute to it. But it's practically 
> > impossible since there is no usable build system :(.
> 
> It's limping along.  We've managed to run a few programs successfully. 
> 
> I think the next step is actually to get the test suite to compile & build so 
> we can see what functionally isn't working yet.
> 
> Pierre and Daniel, we could use some guidance on how to approach this.  The 
> tests have quite a few unguarded includes of mach header files, uses of mach 
> types, and includes of Foundation.  How would you like this porting to 
> proceed?  Hubertus has already done some initial poking at it, but getting 
> direction on the intended outcome would be very helpful.
> 
> thanks,
> 
> --dave
> 
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

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

[Philippe Hausler via swift-corelibs-dev]

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 pending pull request that needs a little more work around 
> NSPredicates, but in my testing on darwin foundation, I’ve discovered what 
> appears to be an obj-c nullability annotation bug. When constructing a block 
> predicate, the type of the block is this:
> 
> (AnyObject, [String: AnyObject]?) -> Bool
> 
> However, the type signature of evaluateObject(_:substitutionVariables:) is
> 
> (AnyObject?, [String: AnyObject]?) -> Bool
> 
> Note the optional AnyObject here. In Xcode 7.2 with swift 2.1, the following 
> code causes an EXC_BAD_ACCESS signal when calling evaluateWithObject: in a 
> playground:
> 
> let pred = NSPredicate(block: { (obj: AnyObject, bindings: [String: 
> AnyObject]?) -> Bool in
> print(obj)
> return false
> })
> print(pred.evaluateWithObject(nil))
> 
> because obj is in fact optional here, but the type of the block does not 
> allow for this.
> 
> There are two possible approaches here; removing the optional type from 
> evaluateWithObject, or adding it to the block constructor for NSPredicate. 
> Such a change is also presumably trivial to port back to darwin foundation, 
> as that at minimum would need to merely change nullability annotations for 
> these components of NSPredicate. These involve a public-api change which by 
> my understanding needs to go through the swift evolution process.
> 
> Before sending this over to swift-evolution which is already pretty 
> high-traffic, I wanted to float this here to make sure that this is 
> appropriate for that process. Is it enough to draft a proposal outright or 
> for comprehensiveness sake should I also send this out to that list to open 
> discussion first?
> 
> Is there anyone on this list that has an opinion over which approach to take 
> for changing the api here?
> 
> Thanks!
> 
> --
> Kevin Lundberg
> ke...@klundberg.com 
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

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

[Philippe Hausler via swift-corelibs-dev]

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 Dec 14, 2015, at 10:22 AM, Kevin Lundberg  wrote:
> 
> Great, should I file a radar on bugreport.apple.com 
>  for this? And if it’s simple enough to fix that 
> can I apply the same fix to the SwiftFoundation API as a PR without any extra 
> process?
> 
> --
> Kevin Lundberg
> ke...@klundberg.com 
>> On Dec 14, 2015, at 1:09 PM, Philippe Hausler > > wrote:
>> 
>> 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 
>>> mailto:swift-corelibs-dev@swift.org>> wrote:
>>> 
>>> I have a pending pull request that needs a little more work around 
>>> NSPredicates, but in my testing on darwin foundation, I’ve discovered what 
>>> appears to be an obj-c nullability annotation bug. When constructing a 
>>> block predicate, the type of the block is this:
>>> 
>>> (AnyObject, [String: AnyObject]?) -> Bool
>>> 
>>> However, the type signature of evaluateObject(_:substitutionVariables:) is
>>> 
>>> (AnyObject?, [String: AnyObject]?) -> Bool
>>> 
>>> Note the optional AnyObject here. In Xcode 7.2 with swift 2.1, the 
>>> following code causes an EXC_BAD_ACCESS signal when calling 
>>> evaluateWithObject: in a playground:
>>> 
>>> let pred = NSPredicate(block: { (obj: AnyObject, bindings: [String: 
>>> AnyObject]?) -> Bool in
>>> print(obj)
>>> return false
>>> })
>>> print(pred.evaluateWithObject(nil))
>>> 
>>> because obj is in fact optional here, but the type of the block does not 
>>> allow for this.
>>> 
>>> There are two possible approaches here; removing the optional type from 
>>> evaluateWithObject, or adding it to the block constructor for NSPredicate. 
>>> Such a change is also presumably trivial to port back to darwin foundation, 
>>> as that at minimum would need to merely change nullability annotations for 
>>> these components of NSPredicate. These involve a public-api change which by 
>>> my understanding needs to go through the swift evolution process.
>>> 
>>> Before sending this over to swift-evolution which is already pretty 
>>> high-traffic, I wanted to float this here to make sure that this is 
>>> appropriate for that process. Is it enough to draft a proposal outright or 
>>> for comprehensiveness sake should I also send this out to that list to open 
>>> discussion first?
>>> 
>>> Is there anyone on this list that has an opinion over which approach to 
>>> take for changing the api here?
>>> 
>>> Thanks!
>>> 
>>> --
>>> Kevin Lundberg
>>> ke...@klundberg.com 
>>> 
>>> ___
>>> swift-corelibs-dev mailing list
>>> swift-corelibs-dev@swift.org 
>>> https://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

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

[Philippe Hausler via swift-corelibs-dev]

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 
sometimes is a bit hard to follow it all.
Review feedback from the community helps a ton
Rebasing commits from master so that there are no merge conflicts makes my job 
easier.
Unit tests are awesome!

These are rules of thumb that actually can apply easily beyond the break.

> On Dec 17, 2015, at 9:11 AM, Tony Parker via swift-corelibs-dev 
>  wrote:
> 
> Indeed! I hope the mismatch doesn’t cause us to fall too far behind. ;)
> 
> - Tony
> 
>> On Dec 17, 2015, at 9:10 AM, Brian Gesiak > > wrote:
>> 
>> Thanks for the head's up! Conversely, I imagine that for many people, 
>> holidays from work are precisely the time to contribute! :)
>> 
>> - Brian Gesiak
>> 
>> 
>> 
>> 
>> 
>> On Thu, Dec 17, 2015 at 9:03 AM -0800, "Tony Parker via swift-corelibs-dev" 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> Hello fellow contributors,
>> 
>> As you are aware, we are fast approaching the year-end holiday season. Here 
>> at Apple, many of us are taking some time off starting next week through the 
>> new year. As a result, it is likely that some pull requests will take more 
>> time than expected to review and merge. Even if some of us are on vacation, 
>> this is a great opportunity for anyone to jump in and help review PRs!
>> 
>> Thanks and happy new year,
>> - Tony
>> 
>>  
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org 
>> https://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 
> 
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

[Philippe Hausler via swift-corelibs-dev]

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_DEFAULT | 
POSIX_SPAWN_SETSIGMASK | POSIX_SPAWN_SETSIGDEF

You can probably skip QoS since it won’t exist on linux.

There may be some issue with not having libdispatch to use for a source to 
watch a DISPATCH_PROC_EXIT but this perhaps could be done via a pthread (not 
certain on exactly how but perhaps it can be done)

It also might be useful in this case to drop down to C similarly as 
CFXMLInterface - but pick your poison on that one.


> On Dec 18, 2015, at 11:08 AM, Dan Stenmark via swift-corelibs-dev 
>  wrote:
> 
> I hope to take a crack at implementing some of NSTask this weekend.  What are 
> the recommended posix_spawnattr_t flags that should be set?  Do we also want 
> to take the opportunity to expose the ability to override some of these flags 
> (like POSIX_SPAWN_SETPGROUP) or do we want to avoid tying this with 
> posix_spawn() too closely?
> 
> Dan
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

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

[Philippe Hausler via swift-corelibs-dev]

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 do find 
a decent way of dealing with the module map differentials between linux and mac 
os x I would be interested to see if we could improve the state of affairs in 
that bridged portion.

> On Dec 18, 2015, at 2:33 PM, Robert Stephen Thompson via swift-corelibs-dev 
>  wrote:
> 
> Ok, sounds good to me. I have quite a bit done at this point, but it’s not 
> “pretty enough” for a real PR yet. If people really want to look at the 
> ugliness, 
> https://github.com/rothomp3/swift-corelibs-foundation/tree/feature/NSXMLDocument
>  
> 
>  is where it lives.
> 
> Thanks,
> Robert
>> On Dec 18, 2015, at 1:58 PM, Tony Parker > > wrote:
>> 
>> Hi Robert,
>> 
>> There actually already is some discussion on the swift-evolution list about 
>> a language feature to enable factory methods, which would help us to 
>> implement these kinds of things. It is a common pattern in Foundation to 
>> return subclasses from initializers (NSNull, NSPredicate are in the same 
>> boat, among many others), so I’m hoping we can get that one moving along 
>> soon. If you can find that thread, go ahead and reply to it with additional 
>> justification if you want.
>> 
>> I think we should try to move forward on this as if we’ll eventually get 
>> that feature. It’s pretty clear that we need it. We may need to work on 
>> other parts of the implementation first until we get it.
>> 
>> - Tony
>> 
>>> On Dec 18, 2015, at 9:21 AM, Robert Stephen Thompson via swift-corelibs-dev 
>>> mailto:swift-corelibs-dev@swift.org>> wrote:
>>> 
>>> Since I recently did a small implementation of NSXMLNode and NSXMLDocument 
>>> to use in an iOS project, I decided to tackle doing the full-featured one 
>>> here. It’s not that hard, doing it as a wrapper on libxml2, except I’ve run 
>>> into a bit of a snag with making the semantics exactly match Darwin 
>>> Foundation: you can’t return a subclass from init! This really only matters 
>>> in one place, but it matters quite a bit there. The de facto designated 
>>> initializer for NSXMLNode is init(kind: NSXMLNodeKind, options: Int). In 
>>> pure Swift, this always returns an NSXMLNode, not the appropriate subclass! 
>>> Which, of course, means as? returns nil, as! (and unsafeDowncast) crash, 
>>> etc, when you end up trying to retrieve one and treat it as the subclass 
>>> it’s “supposed” to be. I’m completely stumped as to any way around this. It 
>>> might be that it’s just impossible to match Darwin Foundation semantics 
>>> without a new language feature for this, which obviously would have to go 
>>> through swift-evolution and then actually be implemented. Am I correct, or 
>>> is there something I’m missing? Also, should I go ahead and implement the 
>>> rest of this without the exactly matching semantics because something is 
>>> better than nothing?
>>> 
>>> Thanks,
>>> Robert Thompson
>>> Software Engineer
>>> WillowTree, Inc.®
>>> willowtreeapps.com 
>>>  
>>> 
>>> ___
>>> swift-corelibs-dev mailing list
>>> swift-corelibs-dev@swift.org 
>>> https://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 
> 
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

[Philippe Hausler via swift-corelibs-dev]

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 special runtime 
considerations for these types of things. 

The tricksy spot would be cases where you would need to fetch a class without 
the module name. 

For example NSUUID is defined by it’s module name Foundation.NSUUID; in that a 
program could have it’s own NSUUID that is totally different (naming it the 
same thing would be confusing to read and potentially viewed as bad form but it 
can be done…). That would result in MyApplication.NSUUID to define the symbolic 
name of the item. From the perspective of NSKeyedArchiver it will encode things 
as NSUUID (without the namespace) in that in the realm of objc there can be 
only one.

The tl;dr is that there is no manifest of classes or table of names stored in 
the binaries; just symbols.

> On Dec 18, 2015, at 10:57 PM, Luke Howard  wrote:
> 
> 
>> Specifically there is no NSClassFromString yet. I would say if you are 
>> looking for a place to start, perhaps coming up with a good strategy for 
>> accomplishing that in a uniform manner (for both Foundation classes as well 
>> as user classes) would be a good step in the right direction to getting this 
>> started.
> 
> Does Swift have enough runtime metadata to do this for native Swift classes?
> 
> -- Luke

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

Re: [swift-corelibs-dev] NSCoding methods

[Philippe Hausler via swift-corelibs-dev]

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. This will mean 
that we will want to have the encoded class names from the application scope to 
be encoded as the non mangled name but with the namespace. However this 
presents a problem; Foundation will have a namespace which will need to be 
inferred both for encoding and decoding. Thankfully there may be a reasonable 
way to approach this;

public class func classNameForClass(cls: AnyClass) -> String?
public class func setClassName(codedName: String?, forClass cls: AnyClass)

These methods can be used to allow for translation of classes by registering 
the appropriate classes for a “shortened” name that drops the 
Foundation/SwiftFoundation namespace prefix during encoding.

> On Dec 22, 2015, at 2:45 AM, Luke Howard via swift-corelibs-dev 
>  wrote:
> 
> 
>> On 22 Dec 2015, at 5:50 AM, Jordan Rose  wrote:
>> 
>> IMHO on Linux NSKeyedArchiver should always use mangled names. If we want 
>> cross-platform archives, we should set up standard substitutions, but given 
>> that Swift classes exposed to Objective-C are archived with their full names 
>> it doesn't make sense to use "half the name" in the archive.
> 
> You mean namespaced but unmangled yes? If so I agree.
> 
> BTW I found a couple of small CF nits:
> 
> * in CFDictionaryGetKeysAndValues(), keybuf and valuebuf are transposed in 
> the call to CF_SWIFT_FUNCDISPATCHV(NSDictionary.getObjects())
> 
> * _CFSwiftDictionaryGetKeysAndValues() does not handle keybuf or valbuf being 
> NULL (either of which are valid when calling CFDictionaryGetKeysAndValues())
> 

This is a bit un-related to NSCoding and the transposition is probably a 
mistake if it is inverted (the CF method should be reversed from the NS method 
to mimic the objc counterpart)

> — Luke
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

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

[Philippe Hausler via swift-corelibs-dev]

Thanks for the work on this, I will take a look at them later today. Part of 
the hold up on some of the pull requests are that we still have a few compiler 
crashers lurking around and there are a few pr’s that need a bit more work. I 
am leaving XCTest to that team unless it is a critical issue and causing CI 
failure.

> On Dec 23, 2015, at 1:21 AM, Tom Jowett via swift-corelibs-dev 
>  wrote:
> 
> Hi guys - unsure if it's helpful at your end but I rebased (almost) all of 
> the open PR's as of this morning on the current HEAD of master (5435ec4), 
> removed any of the wrong way merges, cleaned up the conflicts and pushed them 
> to my fork.  They're all available here: 
> https://github.com/tomj/swift-corelibs-foundation/branches/all 
> <https://github.com/tomj/swift-corelibs-foundation/branches/all> - I avoided 
> 1 or 2 as they were heavy on the conflicts and I thought I'd their authors 
> would have a better idea on resolving those issues.
> 
> Let me know if there's anything I can do to help get these into the mainline 
> to make it easier for you all.
> 
> Cheers,
> Tom
>  
> Message: 18
> Date: Fri, 18 Dec 2015 08:21:44 -0800
> From: Mike Ferris mailto:mfer...@apple.com>>
> To: Philippe Hausler mailto:phaus...@apple.com>>
> Cc: Swift Core Libs  <mailto:swift-corelibs-dev@swift.org>>
> Subject: Re: [swift-corelibs-dev] Upcoming holiday schedule
> 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
> > On Dec 17, 2015, at 9:18 AM, Philippe Hausler via swift-corelibs-dev 
> > mailto:swift-corelibs-dev@swift.org>> wrote:
> >
> > 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 sometimes is a bit hard to follow it all.
> > Review feedback from the community helps a ton
> > Rebasing commits from master so that there are no merge conflicts makes my 
> > job easier.
> > Unit tests are awesome!
> >
> > These are rules of thumb that actually can apply easily beyond the break.
> >
> >> On Dec 17, 2015, at 9:11 AM, Tony Parker via swift-corelibs-dev 
> >> mailto:swift-corelibs-dev@swift.org> 
> >> <mailto:swift-corelibs-dev@swift.org 
> >> <mailto:swift-corelibs-dev@swift.org>>> wrote:
> >>
> >> Indeed! I hope the mismatch doesn’t cause us to fall too far behind. ;)
> >>
> >> - Tony
> >>
> >>> On Dec 17, 2015, at 9:10 AM, Brian Gesiak  >>> <mailto:modoca...@gmail.com> <mailto:modoca...@gmail.com 
> >>> <mailto:modoca...@gmail.com>>> wrote:
> >>>
> >>> Thanks for the head's up! Conversely, I imagine that for many people, 
> >>> holidays from work are precisely the time to contribute! :)
> >>>
> >>> - Brian Gesiak
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Thu, Dec 17, 2015 at 9:03 AM -0800, "Tony Parker via 
> >>> swift-corelibs-dev"  >>> <mailto:swift-corelibs-dev@swift.org> 
> >>> <mailto:swift-corelibs-dev@swift.org 
> >>> <mailto:swift-corelibs-dev@swift.org>>> wrote:
> >>>
> >>> Hello fellow contributors,
> >>>
> >>> As you are aware, we are fast approaching the year-end holiday season. 
> >>> Here at Apple, many of us are taking some time off starting next week 
> >>> through the new year. As a result, it is likely that some pull requests 
> >>> will take more time than expected to review and merge. Even if some of us 
> >>> are on vacation, this is a great opportunity for anyone to jump in and 
> >>> help review PRs!
> >>>
> >>> Thanks and happy new year,
> >>> - Tony
> >>>
> >>>
> >>> ___
> >>> swift-corelibs-dev mailing list
>  ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

Re: [swift-corelibs-dev] NSCoding methods

[Philippe Hausler via swift-corelibs-dev]

The archiving format encodes the names of the classes in the archive itself. 
Here are a few code examples and a quasi readable output from them:

let uuid = NSUUID()
let data = NSKeyedArchiver.archivedDataWithRootObject(uuid)
let archive = try! NSPropertyListSerialization.propertyListWithData(data, 
options: [], format: nil)
print(archive)

prints the following:

{
"$archiver" = NSKeyedArchiver;
"$objects" = (
"$null",
{
"$class" = "{value 
= 2}";
"NS.uuidbytes" = <797639fe dad74b14 902afab3 c490448b>;
},
{
"$classes" = (
NSUUID,
NSObject
);
"$classname" = NSUUID;
}
);
"$top" = {
root = "{value = 1}";
};
"$version" = 10;
}

Note the $classes and $classname objects; which are what tell the internal 
implementation of NSKeyedUnarchiver what to construct; moreover you can create 
your own classes..

// I don’t really think this is a good naming for an application’s class but 
hey it might happen...
class NSUUID : NSObject, NSCoding {
let uuid: Foundation.NSUUID
required init?(coder aDecoder: NSCoder) {
uuid = aDecoder.decodeObjectForKey("my.uuid") as! Foundation.NSUUID
}
override init() {
uuid = Foundation.NSUUID()
}
func encodeWithCoder(aCoder: NSCoder) {
aCoder.encodeObject(uuid, forKey: "my.uuid")
}
}

let uuid = NSUUID()
let data = NSKeyedArchiver.archivedDataWithRootObject(uuid)
let archive = try! NSPropertyListSerialization.propertyListWithData(data, 
options: [], format: nil)
print(archive)

prints the following:

{
"$archiver" = NSKeyedArchiver;
"$objects" = (
"$null",
{
"$class" = "{value 
= 4}";
"my.uuid" = "{value = 2}";
},
{
"$class" = "{value 
= 3}";
"NS.uuidbytes" = <546e5b5e 15c244a1 aa96eb90 30c3f7f6>;
},
{
"$classes" = (
NSUUID,
NSObject
);
"$classname" = NSUUID;
},
{
"$classes" = (
"Archiver.NSUUID",
NSObject
);
"$classname" = "Archiver.NSUUID";
}
);
"$top" = {
root = "{value = 1}";
};
"$version" = 10;
}

Granted this is a questionable name for a class but it illustrates which class 
names are encoded where and how they should be interpreted in the pre-existing 
archive format; which we will have to figure out some sensible way of inflating 
and deflating to/from disk/network etc.

> On Dec 23, 2015, at 2:37 PM, Jordan Rose  wrote:
> 
> No, we cannot encode things "non-mangled but with the namespace". For any 
> type other than top-level non-generic class types, using a 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 for those. We can just use the plain old 
> Objective-C names that the OS X classes use today.
> 
> Jordan
> 
>> On Dec 22, 2015, at 10:16, Philippe Hausler via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> 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. 
>> This will mean that we will want to have the encoded class names from the 
>> application scope to be encoded as the non mangled name but with the 
>> namespace. However this presents a problem; Foundation will have a namespace 
>> which will need to be inferred both for encoding and decoding. Thankfully 
>> there may be a reasonable way to approach this;
>> 
>> public class func classNameForClass(cls: AnyClass) -> String?
>> public class func setClassName(codedName: String?, forClass cls: AnyClass)
>> 
>> These methods can be used to allow for translation of classes by registering 
>> the appropriate classes for a “shortened” name that drops the 
>> Foundation/SwiftFoundation namespace prefix during encodi

Re: [swift-corelibs-dev] NSCoding methods

[Philippe Hausler via swift-corelibs-dev]

oding {
>> let uuid: Foundation.NSUUID
>> required init?(coder aDecoder: NSCoder) {
>> uuid = aDecoder.decodeObjectForKey("my.uuid") as! Foundation.NSUUID
>> }
>> override init() {
>> uuid = Foundation.NSUUID()
>> }
>> func encodeWithCoder(aCoder: NSCoder) {
>> aCoder.encodeObject(uuid, forKey: "my.uuid")
>> }
>> }
>> 
>> let uuid = NSUUID()
>> let data = NSKeyedArchiver.archivedDataWithRootObject(uuid)
>> let archive = try! NSPropertyListSerialization.propertyListWithData(data, 
>> options: [], format: nil)
>> print(archive)
>> 
>> prints the following:
>> 
>> {
>> "$archiver" = NSKeyedArchiver;
>> "$objects" = (
>> "$null",
>> {
>> "$class" = "> [0x7fff7ab33bb0]>{value = 4}";
>> "my.uuid" = "> [0x7fff7ab33bb0]>{value = 2}";
>> },
>> {
>> "$class" = "> [0x7fff7ab33bb0]>{value = 3}";
>> "NS.uuidbytes" = <546e5b5e 15c244a1 aa96eb90 30c3f7f6>;
>> },
>> {
>> "$classes" = (
>> NSUUID,
>> NSObject
>> );
>> "$classname" = NSUUID;
>>     },
>> {
>> "$classes" = (
>> "Archiver.NSUUID",
>> NSObject
>> );
>> "$classname" = "Archiver.NSUUID";
>> }
>> );
>> "$top" = {
>> root = "{value = 
>> 1}";
>> };
>> "$version" = 10;
>> }
>> 
>> Granted this is a questionable name for a class but it illustrates which 
>> class names are encoded where and how they should be interpreted in the 
>> pre-existing archive format; which we will have to figure out some sensible 
>> way of inflating and deflating to/from disk/network etc.
>> 
>>> On Dec 23, 2015, at 2:37 PM, Jordan Rose >> <mailto:jordan_r...@apple.com>> wrote:
>>> 
>>> No, we cannot encode things "non-mangled but with the namespace". For any 
>>> type other than top-level non-generic class types, using a 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 for those. We can just use the plain old 
>>> Objective-C names that the OS X classes use today.
>>> 
>>> Jordan
>>> 
>>>> On Dec 22, 2015, at 10:16, Philippe Hausler via swift-corelibs-dev 
>>>> mailto:swift-corelibs-dev@swift.org>> wrote:
>>>> 
>>>> 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. 
>>>> This will mean that we will want to have the encoded class names from the 
>>>> application scope to be encoded as the non mangled name but with the 
>>>> namespace. However this presents a problem; Foundation will have a 
>>>> namespace which will need to be inferred both for encoding and decoding. 
>>>> Thankfully there may be a reasonable way to approach this;
>>>> 
>>>> public class func classNameForClass(cls: AnyClass) -> String?
>>>> public class func setClassName(codedName: String?, forClass cls: AnyClass)
>>>> 
>>>> These methods can be used to allow for translation of classes by 
>>>> registering the appropriate classes for a “shortened” name that drops the 
>>>> Foundation/SwiftFoundation namespace prefix during encoding.
>>>> 
>>>>> On Dec 22, 2015, at 2:45 AM, Luke Howard via swift-corelibs-dev 
>>>>> mailto:swift-corelibs-dev@swift.org>> 
>>>>> wrote:
>>>>> 
>>>>> 
>>>>>> On 22 Dec 2015, at 5:50 AM, Jordan Rose >>>>> <mailto:jordan_r...@apple.com>> wrote:
>>>>>> 
>>>>>> IMHO on Linux NSKeyedArchiver should always use mangled names. If we 
>>>>>> want cross-platform archives, we should set up standard substitutions, 
>>>>>> but given that Swift classes exposed to Objective-C are archived with 
>>>>>> their full names it doesn't make sense to use "half the name" in the 
>>>>>> archive.
>>>>> 
>>>>> You mean namespaced but unmangled yes? If so I agree.
>>>>> 
>>>>> BTW I found a couple of small CF nits:
>>>>> 
>>>>> * in CFDictionaryGetKeysAndValues(), keybuf and valuebuf are transposed 
>>>>> in the call to CF_SWIFT_FUNCDISPATCHV(NSDictionary.getObjects())
>>>>> 
>>>>> * _CFSwiftDictionaryGetKeysAndValues() does not handle keybuf or valbuf 
>>>>> being NULL (either of which are valid when calling 
>>>>> CFDictionaryGetKeysAndValues())
>>>>> 
>>>> 
>>>> This is a bit un-related to NSCoding and the transposition is probably a 
>>>> mistake if it is inverted (the CF method should be reversed from the NS 
>>>> method to mimic the objc counterpart)
>>>> 
>>>>> — Luke
>>>>> ___
>>>>> swift-corelibs-dev mailing list
>>>>> swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>>>>> <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev>
>>>> 
>>>> ___
>>>> swift-corelibs-dev mailing list
>>>> swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>>>> <https://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

Re: [swift-corelibs-dev] NSCoding methods

[Philippe Hausler via swift-corelibs-dev]

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 initialization for NSKeyedArchiver, once of 
course.

NSKeyedArchiver.setClassName("NSArray", forClass: NSArray.self)
NSKeyedArchiver.setClassName("NSByteCountFormatter", forClass: 
NSByteCountFormatter.self)
NSKeyedArchiver.setClassName("NSData", forClass: NSData.self)
NSKeyedArchiver.setClassName("NSDate", forClass: NSDate.self)
NSKeyedArchiver.setClassName("NSDateFormatter", forClass: 
NSDateFormatter.self)
NSKeyedArchiver.setClassName("NSDateIntervalFormatter", forClass: 
NSDateIntervalFormatter.self)
NSKeyedArchiver.setClassName("NSDecimalNumber", forClass: 
NSDecimalNumber.self)
NSKeyedArchiver.setClassName("NSDictionary", forClass: NSDictionary.self)
NSKeyedArchiver.setClassName("NSEnergyFormatter", forClass: 
NSEnergyFormatter.self)
NSKeyedArchiver.setClassName("NSFormatter", forClass: NSFormatter.self)
NSKeyedArchiver.setClassName("NSLengthFormatter", forClass: 
NSLengthFormatter.self)
NSKeyedArchiver.setClassName("NSMassFormatter", forClass: 
NSMassFormatter.self)
NSKeyedArchiver.setClassName("NSMessagePort", forClass: NSMessagePort.self)
NSKeyedArchiver.setClassName("NSMutableArray", forClass: 
NSMutableArray.self)
NSKeyedArchiver.setClassName("NSMutableData", forClass: NSMutableData.self)
NSKeyedArchiver.setClassName("NSMutableDictionary", forClass: 
NSMutableDictionary.self)
NSKeyedArchiver.setClassName("NSMutableSet", forClass: NSMutableSet.self)
NSKeyedArchiver.setClassName("NSMutableString", forClass: 
NSMutableString.self)
NSKeyedArchiver.setClassName("NSNotification", forClass: 
NSNotification.self)
NSKeyedArchiver.setClassName("NSNumber", forClass: NSNumber.self)
NSKeyedArchiver.setClassName("NSNumberFormatter", forClass: 
NSNumberFormatter.self)
NSKeyedArchiver.setClassName("NSPersonNameComponentsFormatter", forClass: 
NSPersonNameComponentsFormatter.self)
NSKeyedArchiver.setClassName("NSPort", forClass: NSPort.self)
NSKeyedArchiver.setClassName("NSRegularExpression", forClass: 
NSRegularExpression.self)
NSKeyedArchiver.setClassName("NSSet", forClass: NSSet.self)
NSKeyedArchiver.setClassName("NSSocketPort", forClass: NSSocketPort.self)
NSKeyedArchiver.setClassName("NSString", forClass: NSString.self)
NSKeyedArchiver.setClassName("NSTextCheckingResult", forClass: 
NSTextCheckingResult.self)
NSKeyedArchiver.setClassName("NSTimeZone", forClass: NSTimeZone.self)
NSKeyedArchiver.setClassName("NSUUID", forClass: NSUUID.self)
NSKeyedArchiver.setClassName("NSValue", forClass: NSValue.self)

I have a few more things that I was looking at for supporting this that might 
be useful depending on how far along you are.

This should give us at least a head start on the NSCoding compliant Foundation 
classes and user classes can come next once we have support.

> On Dec 23, 2015, at 3:33 PM, Luke Howard  wrote:
> 
>> 
>> On 24 Dec 2015, at 10:12 AM, Philippe Hausler > > wrote:
>> 
>> NSCoding will have to use something to transform from strings to classes, 
>> and that satisfy the two cases (or more) that we have already shown, 
>> currently there is no thing that does that in either form; either mangled or 
>> non mangled. Basically we need something to implement NSClassFromString 
>> with. Which we have clearly shown that dlsym does not fully meet the needs 
>> since there are cases that will emit as “module.classname” and others that 
>> emit as the mangled name. The simple case is probably going to be the a very 
>> common usage pattern for consumers (and of previously built applications). 
>> The inner class should definitely be handled in addition to this case.
> 
> * If the mangled name is present in the archive, you can re-mangle it to get 
> the metadata accessor
> * If it’s a one-level unmangled name representing a class, it can be mangled
> * If it’s a zero-level unmangled name, then it seems reasonable for a first 
> implementation to assume it’s a SwiftFoundation class (or that the caller has 
> set an explicit mapping)
> 
> Noted that dlsym() will only work with public symbols.
> 
>> Are there any methods that can fetch the name (either the symbolic or the 
>> readable) given a AnyClass in the runtime to get work started here? I think 
>> it is definitely sensible as a start to restrict this just to descendants of 
>> the class NSObject. I would presume that since the Metadata is potentially 
>> volatile contents we should use something along the lines of 
>> swift_getTypeName etc?
> 
> 
> I have been using _typeName() but it always demangles – for interop with 
> existing archives we need to match the behaviour of libobjc's class_getName() 
> (equiv

Re: [swift-corelibs-dev] NSCoding methods

[Philippe Hausler via swift-corelibs-dev]

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 renamed in 
swift and presented with a better interface via the SDK overlays. Note: this 
will have to go through our evolution proposal system and be weighed in by the 
component owners of NSKeyedArchiver and the API teams associated with that to 
make such a change.

In my opinion since AnyClass should be unique it by nature should be Hashable - 
however I am not certain we can actually do that without language changes.

Perhaps for the time being we could alter the signatures to be:

public func decodeObjectOfClasses(classes: [AnyClass], forKey key: String) -> 
AnyObject?

public var allowedClasses: [AnyClass]?


> On Dec 25, 2015, at 2:01 AM, Luke Howard via swift-corelibs-dev 
>  wrote:
> 
> Looking at decodeObjectOfClasses/allowedClasses – what is the element type in 
> the set of allowed classes? It seems like it should be AnyClass but that 
> can’t be added to a Set because it doesn’t implement Hashable (nor to an 
> NSSet because the initialiser unconditionally casts to NSObject).
> 
> — Luke
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

Re: [swift-corelibs-dev] NSCoding methods

[Philippe Hausler via swift-corelibs-dev]

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; primarily I was focused on getting the plist types 
done first and then moving onto the other classes.


> On Dec 26, 2015, at 6:01 AM, Luke Howard  wrote:
> 
> Another language thing I ran into – using classForKeyedArchiver/classForCoder 
> is impossible because declarations from extensions cannot be overridden yet.
> 
> For example I’d like to do:
> 
> internal class _NSCFString : NSMutableString {
> … 
> override var classForCoder: AnyClass {
> return NSMutableString.self
> }
> }
> 
> There are a few ways I can work around it but perhaps we can put these 
> extensions directly on NSObject for now?
> 
> — Luke

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

Re: [swift-corelibs-dev] NSCoding methods

[Philippe Hausler via swift-corelibs-dev]

> 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 testing what you have so far?
>> 
>> I have a few init?(coder:) implementations that should match the 
>> implementations on darwin; primarily I was focused on getting the plist 
>> types done first and then moving onto the other classes.
> 
> I’ve done the plist classes and a few others such as NSURL, NSLocale, NSUUID. 
> I’m going to look at the rest today, other remaining todos are:
> 
> * encodeValueOfObjCType()
> * reviewing fatal vs non-fatal error cases
> * testing reading/writing from a stream (vs memory), seem to be some issues 
> with this
> * unit tests
> * incremental decoding (probably will not get to this)
> 
> Also I’m only looking at NSKeyedArchiver – do we need to support NSArchiver?
> 
> Finally, I filed a few bugs (with patches) for things I bumped into along the 
> way:
> 
> * SR-378: Uninitialised memory in NSDictionary initialiser
> * SR-379: CFDictionaryGetKeysAndValues() bridges in wrong order
> * SR-380: Occasional crashes in NSString.hash.getter
> * SR-381: Request for API to return mangled nominal type name
> * SR-386: NSLog() API
> 
> — Luke

I was looking over some of the init and encode methods you have, there are a 
few bits that might need some touch ups to match behavioral differences but I 
think I can probably merge in some of the work I have done as an addendum to 
what you have already gotten done.

It might be good for review side of things to break out those other issues into 
their own pull requests. Is there a reason to implement NSLog and not just use 
print?

SR-380; that is a compiler issue? or runtime?

 NSArchiver is old and not very cross platform on the darwin side of things 
anyhow. I think we should just focus on NSCoder/NSKeyedArchiver and user 
subclasses of each case.

Have you tested yet on ubuntu?
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

[Philippe Hausler via swift-corelibs-dev]

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 things to break out those other issues 
>> into their own pull requests.
> 
> Agreed – I’ll do this soon.
> 
> — Luke

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

Re: [swift-corelibs-dev] NSCoding methods

[Philippe Hausler via swift-corelibs-dev]

So a few results so far from the linux side: I ran across a few compiler 
crashes in the function metadataFromAccessorName; I need to dive a bit deeper 
into why it is failing.
I have a few cross platform corrections that I will be pushing shortly for you.

> On Dec 26, 2015, at 7:29 PM, Philippe 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:
>> 
>> 
>>> On 27 Dec 2015, at 1:54 PM, Philippe Hausler  wrote:
>>> 
>>> It might be good for review side of things to break out those other issues 
>>> into their own pull requests.
>> 
>> Agreed – I’ll do this soon.
>> 
>> — Luke
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

Re: [swift-corelibs-dev] NSCoding methods

[Philippe Hausler via swift-corelibs-dev]

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 ran across a few compiler 
>> crashes in the function metadataFromAccessorName; I need to dive a bit 
>> deeper into why it is failing.
>> I have a few cross platform corrections that I will be pushing shortly for 
>> you.
> 
> Thanks! With metadataFromAccessorName(), I guess just check the string is 
> valid for starters; I’m surprised it even built as 
> _CFCopyNominalTypeNameForClass() is C++ ABI-fragile.
> 
> — Luke

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

Re: [swift-corelibs-dev] getCString question

[Philippe Hausler via swift-corelibs-dev]

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 bug or am I missing something?
> 
> — Luke
> --
> www.lukehoward.com 
> soundcloud.com/lukehoward
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

Re: [swift-corelibs-dev] NSCoding methods

[Philippe Hausler via swift-corelibs-dev]

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?
> 
> I started looking at NSConcreteValue (commit 1a9fe560) and decoding it is 
> fine (notwithstanding implementing all the special cases).
> 
> What’s the plan for instantiating concrete of NSValue though?
> 
> * Class clusters seem impossible to implement in Swift

Yep, there are a few things in the evolution list to propose this.

> * Factory methods are an API change

We need factory init methods to make this work which is not yet supported by 
the language. 

> * NSValue becoming concrete seems to muck up CF bridging (also, fragile base 
> class problem)

It will end up being a real rats nest to even get it close to working. In the 
end we will have two choices if we don’t have factory init methods, we can have 
NSValue or have NSNumber. My guess is that NSNumber is more commonly used in 
swift than NSValue.

> * I looked a little into using ManagedBuffer to size instances dynamically 
> but it’s not much help by the time init() is called

If need be somethings can be dropped out to C as well

> * A lookaside table works and is straightforward to implement, but is pretty 
> ugly

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 method call would be a dictionary lookup… that does not sound 
scalable from a performance standpoint.

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


In summary - I think perhaps it would be better to start thinking about 
batching up parts of the NSCoder work and getting it merged before tackling 
NSValue
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

[Philippe Hausler via swift-corelibs-dev]

> 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 method call would be a dictionary lookup… that does not sound 
>> scalable from a performance standpoint.
> 
> Although didn’t NSObject do something similar for managing the retain count 
> when it didn’t fit inline? I’m too lazy to go look it up...
> 
> — Luke

Yea the objc runtime has side tables for things like that; I guess I would have 
to see a proposed implementation and play with it to see what the performance 
hit would be like.

So you were thinking something like (note this is just something I drafted in a 
few minutes so it is a bit rough):

diff --git a/Foundation/NSDecimalNumber.swift b/Foundation/NSDecimalNumber.swift
index 927be14..2e6791f 100644
--- a/Foundation/NSDecimalNumber.swift
+++ b/Foundation/NSDecimalNumber.swift
@@ -96,7 +96,7 @@ public class NSDecimalNumber : NSNumber {
 //   ignore exactnessException
 //   raise on overflow, underflow and divide by zero.
 
-public var objCType: UnsafePointer { NSUnimplemented() }
+public override var objCType: UnsafePointer { NSUnimplemented() }
 // return 'd' for double
 
 public override var doubleValue: Double { NSUnimplemented() }
diff --git a/Foundation/NSValue.swift b/Foundation/NSValue.swift
index eefb3b9..6f495a0 100644
--- a/Foundation/NSValue.swift
+++ b/Foundation/NSValue.swift
@@ -8,10 +8,68 @@
 //
 
 
+internal class NSConcreteValue : NSValue {
+internal var _value: UnsafeMutablePointer = nil
+internal var _size: Int = 0
+internal var _objCType: UnsafePointer = nil
+
+internal override init() {
+super.init()
+}
+
+required init?(coder aDecoder: NSCoder) {
+NSUnimplemented()
+}
+
+override func getValue(value: UnsafeMutablePointer) {
+value.assignFrom(_value, count: _size)
+}
+
+override var objCType: UnsafePointer {
+return _objCType
+}
+}
+
+private var _NSValueSideTable = [ObjectIdentifier : NSConcreteValue]()
+private var _NSValueSideTableLock = NSLock()
+
 public class NSValue : NSObject, NSCopying, NSSecureCoding, NSCoding {
 
 internal override init() {
-
+super.init()
+if self.dynamicType == NSValue.self {
+_NSValueSideTableLock.synchronized {
+_NSValueSideTable[ObjectIdentifier(self)] = NSConcreteValue()
+}
+}
+}
+
+deinit {
+if self.dynamicType == NSValue.self {
+_NSValueSideTableLock.synchronized {
+_NSValueSideTable[ObjectIdentifier(self)] = nil
+}
+}
+}
+
+public func getValue(value: UnsafeMutablePointer) {
+if self.dynamicType == NSValue.self {
+_NSValueSideTableLock.synchronized {
+_NSValueSideTable[ObjectIdentifier(self)]!.getValue(value)
+}
+} else {
+NSRequiresConcreteImplementation()
+}
+}
+
+public var objCType: UnsafePointer {
+if self.dynamicType == NSValue.self {
+return _NSValueSideTableLock.synchronized {
+return _NSValueSideTable[ObjectIdentifier(self)]!.objCType
+}
+} else {
+NSRequiresConcreteImplementation()
+}
 }
 
 public required init?(coder aDecoder: NSCoder) {

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

Re: [swift-corelibs-dev] NSCoding methods

[Philippe Hausler via swift-corelibs-dev]

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 BTW, it works for decoding 
> (non-special types, special is todo).
> 
> — Luke

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

Re: [swift-corelibs-dev] NSCoding methods

[Philippe Hausler via swift-corelibs-dev]

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 
> 
> 
> I haven’t opened a pull request as I’d like to get it working on Linux first. 
> Having a bit of trouble though. (I’m using Ubuntu 15.10 with the latest 
> snapshot.)
> 
> Firstly, build-wise:
> 
> * Changing anything in Foundation/ seems to trigger a recompile of everything 
> Swift. Is there a way to do correct dependency analysis? My clock is OK.

Yep; probably should be a “known issue” the ninja script will emit the other 
swift files as deps since there might be cross file dependencies - it is a bit 
slow when the compiler is in debug mode

> 
> * swift/utils/build-script with —debug-foundation still seems to build a 
> release version. I worked around by building everything debug, but that takes 
> up a lot of disk space.

My trick that I do is I will build a release build and then hand edit the 
`.configuration` file of Foundation to be debug; so that way the next `ninja 
reconfigure` will reconfig it as debug and give juicy debugging info but the 
rest of the runtime and compiler is in release mode. (I have been considering 
adding this as a specialized reconfigure option

> 
> * lldb crashes all the time when printing variables (actually I also see this 
> on OS X as well with the snapshot)

po or p?

> 
> Related to testing:
> 
> * Something weird is going on with casting over which completely breaks 
> NSKeyedArchiver. I can reproduce it with the following:
> 
> let foo = (NSMutableArray() as? AnyObject) as? NSCoding
> 
> which the compiler tells me always succeeds (as I believe it should), but at 
> runtime returns foo==nil. No issue if it is a locally defined class that 
> conforms to NSCoding. It’s failing in _dynamicCastToExistential()’s check for 
> _conformsToProtocols() but I haven’t dug deeper yet.
> 
> FYI: my LD_LIBRARY_PATH is pointing to the right libswiftCore/libFoundation. 
> I removed the module maps for Foundation/CoreFoundation from the snapshot 
> directory.

The removal of the module map is usually only needed when building directly to 
an installed root. Most of the build process for incremental builds don’t need 
to have module map removal shenanigans.

> 
> * Subclassing NSObject fails outside Foundation (see SR-272) is also an issue 
> but not a blocking one
> 
> — Luke

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

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

[Philippe Hausler via swift-corelibs-dev]

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 likely will have some special case of 
naming since there is a conflict between Foundation’s String and Swift’s String 
that is yet to be determined fully on how that will be done), so it is still a 
bit up-in-the-air on how that will be achieved. However since there are desired 
behavioral differences between NSString and String we cannot just wholesale 
make it an extension since some of the functions that apply to NSString don’t 
make much sense for String (e.g. characterAtIndex etc).

The bug you are probably looking for is: https://bugs.swift.org/browse/SR-138. 
Basically what we need is _ObjectTypeBridgeable to behave similarly to the type 
conversion portion of _ObjectiveCBridgeable. This would likely be primarily 
work in the compiler and also a bit of work in the stdlib for a few of the 
overlay extensions etc.


> On Jan 2, 2016, at 12:24 AM, Drew Crawford via swift-corelibs-dev 
>  wrote:
> 
> I've noticed that e.g. String is not bridged to NSString.  The expected 
> workaround seems to be calling .bridge() everywhere.
> 
> 1.  Is there a plan for bridging e.g. String with NSString?
> 2.  Would it be appropriate to PR in the meantime e.g.
> 
> extension String {
> public func cStringUsingEncoding(encoding: UInt) -> 
> UnsafePointer {
> return self.bridge().cStringUsingEncoding(encoding)
> }
> }
> 
>   3.  The README also says
> 
>> We will also drop the 'NS' prefix from all Foundation classes
> 
> 
> ...is that the resolution?  e.g what is currently class NSString will become 
> instead extension String?  Is there a bug open for that?
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

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

[Philippe Hausler via swift-corelibs-dev]

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.k.a. CF). CF is 
>> written primarily in C and is very portable. Therefore we have chosen to use 
>> it for the internal implementation of Swift Foundation where possible. As CF 
>> is present on all platforms, we can use it to provide a common 
>> implementation everywhere.
> 
> (emphasis added)
> 
> Is the intent of this paragraph to suggest that most PRs to 
> swift-corelibs-foundation should be a C-language implementation to CF with a 
> light Swift wrapper?  That goes against my intuition, but it "seems to be" a 
> plain reading of the paragraph.

I think the underlying intent is that we should use the right tools for the 
job; where it makes sense, even the standard library uses C++. Similarly some 
of the interfaces for ICU for example make much more sense to encapsulate with 
CF (and re-use some of the existing cross platform abstractions). Some classes 
will be a thin veneer on top of CF, where-as others will be a completely swift 
implementation. Take the two cases of NSCalendar and NSThread. CF provides some 
very hard to write (and hard to get right) implementations of calendrical math, 
even though I wrote a good portion of the NSCalendar swift implementation; I am 
definitely glad that there was an implementation I could fall back upon to deal 
with that logic. The counterpoint of NSThread; we could have wrapped up a 
CFThreadRef type object and bridged it across but It made sense to keep 
NSThread in the realm of Swift not only for a potential example of dealing with 
posix APIs for the community but also it just worked out more cleanly in my 
opinion.

I have not crunched the numbers but I have a gut feeling that a large majority 
of the pull requests have been mostly Swift implementations and only a few of 
them have been thin veneers on-top-of CF and even fewer have been changes to CF 
itself.

> 
> its justification about "all platforms" is also strange–I know CF "kind of" 
> builds for Windows, but is anyone actually testing it there?  To make sure we 
> aren't breaking it?  Or does "all platforms" mean something else here?

I know there have been efforts to port swift to FreeBSD and to new 
architectures like ARM-elf for things like Raspberry Pi, I would not be 
surprised that there are efforts to port to Android or Windows out there. 
Granted we do not have any CI provided by Apple to ensure not breaking these 
efforts but I think that the community will be interested in keeping these 
things running since a cross platform framework and language are really 
appealing (even Apple makes a few products for Android and Windows…)

As of current the Windows target is not held directly from the point at which 
this CF was cut from; so I would probably say “trust but verify” and I would 
not be surprised that there may be a few breaking points there that need to be 
re-looked at for that platform. I am certain that if someone took up a new 
target like Windows that would be met with great enthusiasm from all of the 
swift community. I was ecstatic when I saw that there was a FreeBSD port.

I think the one major thing to take under consideration is that alternate 
platforms than Mac OS X and Ubuntu 14/15 don’t have integration into the CI 
that the swift project maintains. I think however if there is strong desire out 
there it would be interesting to have externally maintained build servers 
provided by the community to verify these targets. I am not in charge of that 
type of decision but I would definitely think that it would be an amiable goal 
and I would think that it would be worthwhile to discuss further.

> 
> I feel like this paragraph is an opportunity to explain to a patch author how 
> to structure their patch between use/maintenance/contributions to the CF 
> layer vs the Swift layer.  I feel like it could do a much better job, but I 
> don't understand what the design guidance actually is, so I can't fix it.
> 

Things that enter into CF territory will be things that we will consider with a 
very close eye on them because they will likely move up-stream into the 
CoreFoundation that ships with our current platforms so that the lifecycle 
completes back out to the exported version in the open-source side of it.  The 
Foundation part of the story is a bit more mutable since we have the 
Objective-C version that will still be maintained. That being said there is a 
very strong desire to keep these in parity; we may use some of the interfaces 
in the swift version to try out what people think of these APIs (most of these 
are marked with experimental, and if they are not we should either correct them 
to be the same or mark them as such). Furthermore the swift version will 
sometimes driv

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

[Philippe Hausler via swift-corelibs-dev]

I think perhaps it might be worth something to investigate on what it would 
take to get these extra platforms integrated into CI as nodes to the Swift 
primary builders. As a note since we do target ARM as a primary platform for 
Darwin and we do target Linux as a primary platform, ARM linux is not a far 
stretch so the Pi is much more “supported” than other targets like the initial 
question of Windows code paths at the current moment.

Perhaps one of the compiler team can chime in since the packaging and automatic 
builds are their domain and not per-se mine.

> On Jan 2, 2016, at 1:57 PM, Dave Fenton via swift-corelibs-dev 
>  wrote:
> 
> Given the educational angle that seems to be part of the mission of Swift, I 
> was hoping that the Raspberry Pi port would be something the Swift project 
> would directly integrate  and distribute 
> 
> -david
> 
> 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@swift.org>> 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.k.a. 
>>>> CF). CF is written primarily in C and is very portable. Therefore we have 
>>>> chosen to use it for the internal implementation of Swift Foundation where 
>>>> possible. As CF is present on all platforms, we can use it to provide a 
>>>> common implementation everywhere.
>>> 
>>> (emphasis added)
>>> 
>>> Is the intent of this paragraph to suggest that most PRs to 
>>> swift-corelibs-foundation should be a C-language implementation to CF with 
>>> a light Swift wrapper?  That goes against my intuition, but it "seems to 
>>> be" a plain reading of the paragraph.
>> 
>> I think the underlying intent is that we should use the right tools for the 
>> job; where it makes sense, even the standard library uses C++. Similarly 
>> some of the interfaces for ICU for example make much more sense to 
>> encapsulate with CF (and re-use some of the existing cross platform 
>> abstractions). Some classes will be a thin veneer on top of CF, where-as 
>> others will be a completely swift implementation. Take the two cases of 
>> NSCalendar and NSThread. CF provides some very hard to write (and hard to 
>> get right) implementations of calendrical math, even though I wrote a good 
>> portion of the NSCalendar swift implementation; I am definitely glad that 
>> there was an implementation I could fall back upon to deal with that logic. 
>> The counterpoint of NSThread; we could have wrapped up a CFThreadRef type 
>> object and bridged it across but It made sense to keep NSThread in the realm 
>> of Swift not only for a potential example of dealing with posix APIs for the 
>> community but also it just worked out more cleanly in my opinion.
>> 
>> I have not crunched the numbers but I have a gut feeling that a large 
>> majority of the pull requests have been mostly Swift implementations and 
>> only a few of them have been thin veneers on-top-of CF and even fewer have 
>> been changes to CF itself.
>> 
>>> 
>>> its justification about "all platforms" is also strange–I know CF "kind of" 
>>> builds for Windows, but is anyone actually testing it there?  To make sure 
>>> we aren't breaking it?  Or does "all platforms" mean something else here?
>> 
>> I know there have been efforts to port swift to FreeBSD and to new 
>> architectures like ARM-elf for things like Raspberry Pi, I would not be 
>> surprised that there are efforts to port to Android or Windows out there. 
>> Granted we do not have any CI provided by Apple to ensure not breaking these 
>> efforts but I think that the community will be interested in keeping these 
>> things running since a cross platform framework and language are really 
>> appealing (even Apple makes a few products for Android and Windows…)
>> 
>> As of current the Windows target is not held directly from the point at 
>> which this CF was cut from; so I would probably say “trust but verify” and I 
>> would not be surprised that there may be a few breaking points there that 
>> need to be re-looked at for that platform. I am certain that if someone took 
>> up a new target like Windows that would be met with great enthusiasm from 
>

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

[Philippe Hausler via swift-corelibs-dev]

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 swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> Proposed fix:
>> 
>> https://github.com/lhoward/swift-corelibs-foundation/commit/fe5dcce6ccf06d2f5b8e85c792012dbaee8f59f7
>>  
>> 
>> 
>> Also tracking in [SR-414].
>> 
>>> On 30 Dec 2015, at 6:15 PM, Luke Howard via swift-corelibs-dev 
>>> mailto:swift-corelibs-dev@swift.org>> wrote:
>>> 
>>> import SwiftFoundation
>>> 
>>> let url1 = NSURL(string: "foo.xml", relativeToURL:NSURL(string: 
>>> "https://www.example.com "))!
>>> let url2 = NSURL(string: "foo.xml", relativeToURL:NSURL(string: 
>>> "https://www.example.com "))!
>>> 
>>> print("\(url1.isEqual(url2))")
>>> print("\(url1 == url2)")
>>> 
>> 
>> --
>> www.lukehoward.com 
>> soundcloud.com/lukehoward 
>> 
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org 
>> https://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

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

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

[Philippe Hausler via swift-corelibs-dev]

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-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> Many Foundation APIs use Int8 instead of CChar when representing C strings, 
>> e.g.:
>> var UTF8String: UnsafePointer 
>> >  
>> >
>>  { get }
>> I don’t know if/when Swift will be ported to a platform where the character 
>> type is unsigned but perhaps it would be good to update these to take CChar 
>> instead?
>> 
>> — Luke
>> 
> 
> I’m not really sure why it’s imported to Swift as an unsafe pointer to Int8 
> anyway. The Objective-C code uses char:
> 
> @property (nullable, readonly) __strong const char *UTF8String 
> NS_RETURNS_INNER_POINTER;  // Convenience to return null-terminated UTF8 
> representation
> 
> - (nullable instancetype)initWithUTF8String:(const char 
> *)nullTerminatedCString;
> 
> - Tony
> 
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

Re: [swift-corelibs-dev] NSRegularExpression implementation

[Philippe Hausler via swift-corelibs-dev]

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-dev 
>  wrote:
> 
> I have been thinking about trying to work on NSRegularExpression in 
> corelibs-foundation, although I am not yet sure I’ll have time for it.
> 
> If I were to attempt it, am I correct in assuming that it should be based on 
> icus (u)regex.h? I have not found any Regex support in CoreFoundation.
> 
> — Lukas
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

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

[Philippe Hausler via swift-corelibs-dev]

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 APIs you are 
interfacing with so ymmv. The formatters are locale independent in that they 
should probably just have a simple callout to uameasfmt_format when creating 
strings from values given a certain unit type.


> On Jan 5, 2016, at 1:23 PM, Johan Jensen via swift-corelibs-dev 
>  wrote:
> 
> I was having a quick look at implementing some of the not-yet-implemented 
> formatters but quickly realized that some of them are highly locale dependent.
> After a quick look I found uameasureformat.h 
> 
>  and uameasfmt_format() which looks quite interesting.
> Is it possible to use these functions?
> If so, should a Swift wrapper be made?
> If not, how is locale dependent formatters expected to be implemented?
> 
> — Johan
>  ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

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

[Philippe Hausler via swift-corelibs-dev]

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.swift ? Or should I try to keep 
> everything inside NSURLSession.swift ?
> 
> If I go for a separate file, I'd be able to differentiate between internal 
> and private for the helpers. I'll end up close to 1000 lines of code for 
> this. Having these inside NSURLSession.swift is a bit overwhelming.
> 
> /Daniel
> 
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

[Philippe Hausler via swift-corelibs-dev]

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 fairly certain that 
would take a bit of work to get up and running; especially the Security 
framework portions.

> On Mar 15, 2016, at 7:54 AM, Pushkar N Kulkarni via swift-corelibs-dev 
>  wrote:
> 
> 
> Hello all, 
> 
>  While attempting a simple Swift client-server program on Linux using 
> CFSocket, I tried to create CFReadStream and CFWriteStream instances using 
> CFStreamCreatePairWithSocket(_:_:_:_). The program compiles and links but it 
> crashes with this:
> 
> 2016-03-15 10:30:17.791 Client[21389:5a501740] CoreFoundation: failed to 
> dynamically link symbol _CFSocketStreamCreatePair
> 
> 2016-03-15 10:30:17.791 Client[21389:5a501740] CoreFoundation: failed to 
> dynamically link symbol _CFErrorCreateWithStreamError
> 
> 2016-03-15 10:30:17.791 Client[21389:5a501740] CoreFoundation: failed to 
> dynamically link symbol _CFStreamErrorFromCFError
> 
> 
> 
> 
> 
> I see that these symbols are dynamically linked from CFNetwork which, I 
> guess, doesn't exist on Linux (so there is no lookup for these symbols on 
> Linux). 
> 
> Does this qualify to be a CFStream limitation on Linux?
> 
> Thanks in advance for your time!
> 
> Pushkar N Kulkarni,
> IBM Runtimes
> 
> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
> 
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

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

[Philippe Hausler via swift-corelibs-dev]

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 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 fairly certain that would take a bit of work to get up and running; 
>> especially the Security framework portions.
>> 
>>> On Mar 15, 2016, at 7:54 AM, Pushkar N Kulkarni via swift-corelibs-dev 
>>> mailto:swift-corelibs-dev@swift.org>> wrote:
>>> 
>>> 
>>> Hello all, 
>>> 
>>>  While attempting a simple Swift client-server program on Linux using 
>>> CFSocket, I tried to create CFReadStream and CFWriteStream instances using 
>>> CFStreamCreatePairWithSocket(_:_:_:_). The program compiles and links but 
>>> it crashes with this:
>>> 
>>> 2016-03-15 10:30:17.791 Client[21389:5a501740] CoreFoundation: failed to 
>>> dynamically link symbol _CFSocketStreamCreatePair
>>> 
>>> 2016-03-15 10:30:17.791 Client[21389:5a501740] CoreFoundation: failed to 
>>> dynamically link symbol _CFErrorCreateWithStreamError
>>> 
>>> 2016-03-15 10:30:17.791 Client[21389:5a501740] CoreFoundation: failed to 
>>> dynamically link symbol _CFStreamErrorFromCFError
>>> 
>>> 
>>> 
>>> 
>>> 
>>> I see that these symbols are dynamically linked from CFNetwork which, I 
>>> guess, doesn't exist on Linux (so there is no lookup for these symbols on 
>>> Linux). 
>>> 
>>> Does this qualify to be a CFStream limitation on Linux?
>>> 
>>> Thanks in advance for your time!
>>> 
>>> Pushkar N Kulkarni,
>>> IBM Runtimes
>>> 
>>> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
>>> 
>>> 
>>> ___
>>> swift-corelibs-dev mailing list
>>> swift-corelibs-dev@swift.org 
>>> https://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
> 

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

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

[Philippe Hausler via swift-corelibs-dev]

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 that were missing compared to Darwin Foundation.
> 
> I also re-worked how attributes are used / stored for the immutable / mutable 
> version.
> 
> I didn't add any documentation to the 4 attributes, because I didn't know if 
> we're allowed to copy over documentation from the Darwin Foundation header 
> files. Can someone clarify?
> 
> /Daniel
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

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

[Philippe Hausler via swift-corelibs-dev]

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 it will always return an instance of a Foo no matter the subclass it is 
called from
@end

@interface Bar : Foo
@end

// in objc it is like this:
Foo *f = [Bar fooNamed:@“test”];

// in swift it is like this:
let f = Bar(named:”test”)

but obviously by the method fooNamed always returns a Foo instead of an 
instancetype because it actually looks up Foo objects from a table.

> On Mar 17, 2016, at 7:35 AM, Daniel Eggert via swift-corelibs-dev 
>  wrote:
> 
> There're some initializers (namely in NSURLSession) that have a comment:
> 
> public /*not inherited*/ init(...
> 
> What is this “not inherited” comment trying to convey, and how would one go 
> about implementing this in Swift?
> 
> /Daniel
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

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

[Philippe Hausler via swift-corelibs-dev]

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 reimplement as something 
completely different if at all possible.

That all being said; if they don’t match 100% it isn’t such a big deal since 
they are just intended for display and nothing programmatic so no one _should_ 
be relying on the values...


> On Mar 17, 2016, at 10:27 AM, Ian Partridge via swift-corelibs-dev 
>  wrote:
> 
> 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

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

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

[Philippe Hausler via swift-corelibs-dev]

> 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. 
> 
> So, I tried to do this: 
> @NSCopying public var reversedOrderedSet: NSOrderedSet {
> 
> return NSOrderedSet.init(array: _orderedStorage.reverse())
> 
> }
> 
> 
> 

swift-corelibs-foundation can’t really implement that in terms of adopting the 
decorator of @NSCopying because it does not have objc backing.

> The compiler says "@NSCopying requires the property to be mutable". When 
> inherited by NSMutableOrderedSet, doesn't this property qualify to be 
> mutable? 
> 
> 
> 
The mutable state here is a setter not a NSMutableOrderedSet


> Does @NSCopying not apply here? Is my understanding of "mutable (stored) 
> property" flawed? Or is there a problem with the implementation?
> 
> 
> 
just comment it out and you will be good to go likely.

> Nowhere in Foundation is @NSCopying being used currently. So don't have a 
> "reference implementation" :)
> 
> 
> 
> 
> 
> Pushkar N Kulkarni,
> IBM Runtimes
> 
> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
> 
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

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

[Philippe Hausler via swift-corelibs-dev]

Actually partially related. The /*@NSCopying*/  comments are hints that we left 
when initially importing that the return value should be copied. It is again a 
export from it’s objc nature. In this case having a property with copy.

e.g.

@property (copy) NSData *data;

exports as

@NSCopying public var data: NSData!

This is mainly there to preserve the copy nature when subclasses are 
implemented.

> On Mar 17, 2016, at 7:48 AM, Pushkar N Kulkarni  wrote:
> 
> Sorry for intruding!
> 
> I have the same question about /*@NSCopying*/  
> 
> Pushkar N Kulkarni,
> IBM 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: Philippe Hausler via swift-corelibs-dev 
> Sent by: swift-corelibs-dev-boun...@swift.org 
> <mailto:swift-corelibs-dev-boun...@swift.org>
> Date: 03/17/2016 08:12PM
> Cc: Swift corelibs dev  <mailto:swift-corelibs-dev@swift.org>>
> Subject: 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 it will always return an instance of a Foo no matter the subclass it 
> is called from
> @end
> 
> @interface Bar : Foo
> @end
> 
> // in objc it is like this:
> Foo *f = [Bar fooNamed:@“test”];
> 
> // in swift it is like this:
> let f = Bar(named:”test”)
> 
> but obviously by the method fooNamed always returns a Foo instead of an 
> instancetype because it actually looks up Foo objects from a table.
> 
> > On Mar 17, 2016, at 7:35 AM, Daniel Eggert via swift-corelibs-dev 
> > mailto:swift-corelibs-dev@swift.org>> wrote:
> > 
> > There're some initializers (namely in NSURLSession) that have a comment:
> > 
> > public /*not inherited*/ init(...
> > 
> > What is this “not inherited” comment trying to convey, and how would one go 
> > about implementing this in Swift?
> > 
> > /Daniel
> > 
> > ___
> > swift-corelibs-dev mailing list
> > swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
> > https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
> > <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev>
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
> <https://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

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

[Philippe Hausler via swift-corelibs-dev]

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. NSXMLParser is based on libxml2 in objc. It just does 
not need a CF abstraction/thunks to convert types.

Sent from my iPhone

> On Mar 23, 2016, at 4:07 AM, Daniel Eggert via swift-corelibs-dev 
>  wrote:
> 
> 
>> On 14 Mar 2016, at 18:29, Robert Stephen Thompson 
>>  wrote:
>> 
>> Just a couple of tips based on my experience wrapping libxml2 for 
>> NSXMLDocument:
>> 1. You’ll need to actually import and link libcurl with CoreFoundation 
>> instead of trying to make a libcurl module.modulemap and importing it 
>> directly. This is because if you do it that way, you’ll have to add libcurl 
>> as a dependency _throughout_ the Swift build process, and it would all be 
>> pretty disruptive (and difficult to do).
>> 2. As a consequence of 1., you’ll need to wrap every function you call from 
>> libcurl in a new CoreFoundation API. See CFXMLInterface.h and 
>> CFXMLInterface.c for what I mean. Of course, this also gives you the 
>> opportunity to add nullability annotations, wrap things in CFString, 
>> CFError, CFArray, etc, so it’s not just busy-work for getting around the 
>> build system, heh. Just depends on how much C you want to write, you could 
>> just straight wrap the libcurl functions and do everything in Swift, but at 
>> the very least nullability annotations are a win here.
> 
> 
> I just looked at this, and libxml2 is being linked against by 
> SwiftFoundation, and NOT by CoreFoundation -- on Darwin.
> 
> Is the correct approach to do what's been done with libxml2, or should I 
> instead have CoreFoundation link against libcurl?
> 
> /Daniel
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

[swift-corelibs-dev] NSOperationQueue and friends

[Philippe Hausler via swift-corelibs-dev]

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 this 
difference is due to features like QoS not being cross platform portable or KVO 
not yet implementable in Swift. This is very much a work-in-progress; it needs 
unit tests and and a bit more polish, but hopefully it is good enough to get 
some work started in some other places.

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

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

[Philippe Hausler via swift-corelibs-dev]

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 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 
>> this difference is due to features like QoS not being cross platform 
>> portable or KVO not yet implementable in Swift. This is very much a 
>> work-in-progress; it needs unit tests and and a bit more polish, but 
>> hopefully it is good enough to get some work started in some other places.
>> 
>> - Philippe Hausler
> 
> 
> Great to see progress on this.
> 
> It does fail this simple test case, though:
> 
> 
>func test_BlockBasedAPI() {
>let queue = NSOperationQueue()
> 
>let expectation = expectationWithDescription("did run block")
>queue.addOperationWithBlock {
>expectation.fulfill()
>}
> 
>waitForExpectationsWithTimeout(0.001, handler: nil)
>}
> 
> I'm not sure what's going on there. I was using this on my branch for 
> NSURLSession since it has a delegate queue that I need to run callbacks on.
> 
> /Daniel
> 
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

[Philippe Hausler via swift-corelibs-dev]

DEPLOYMENT_ENABLE_LIBDISPATCH should not be enabled unless you specifically 
enable it (this is until we get libdispatch fully integrated into the build 
system)

> On Mar 28, 2016, at 1:14 PM, Daniel Eggert  wrote:
> 
> This is on OS X will everything pulled from master yesterday. I'm using 
> Xcode, and I built a toolchain from source. Same happens with the 2016-03-24 
> toolchain from swift.org.
> 
> 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 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 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 this difference is due to features like QoS not being cross platform 
>>>> portable or KVO not yet implementable in Swift. This is very much a 
>>>> work-in-progress; it needs unit tests and and a bit more polish, but 
>>>> hopefully it is good enough to get some work started in some other places.
>>>> 
>>>> - Philippe Hausler
>>> 
>>> 
>>> Great to see progress on this.
>>> 
>>> It does fail this simple test case, though:
>>> 
>>> 
>>>  func test_BlockBasedAPI() {
>>>  let queue = NSOperationQueue()
>>> 
>>>  let expectation = expectationWithDescription("did run block")
>>>  queue.addOperationWithBlock {
>>>  expectation.fulfill()
>>>  }
>>> 
>>>  waitForExpectationsWithTimeout(0.001, handler: nil)
>>>  }
>>> 
>>> I'm not sure what's going on there. I was using this on my branch for 
>>> NSURLSession since it has a delegate queue that I need to run callbacks on.
>>> 
>>> /Daniel
>>> 
> 

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

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

[Philippe Hausler via swift-corelibs-dev]

the swift-corelibs-foundation compiled for Darwin does not define that yet 
either. Are you seeing issues with it when defined?


> On Mar 28, 2016, at 2:51 PM, Daniel Eggert  wrote:
> 
> Ok.
> 
> That test case fail on OS X, though. Should I open a bug?
> 
> /Daniel
> 
> 
>> On Mar 28, 2016, at 22:17, Philippe Hausler  wrote:
>> 
>> DEPLOYMENT_ENABLE_LIBDISPATCH should not be enabled unless you specifically 
>> enable it (this is until we get libdispatch fully integrated into the build 
>> system)
>> 
>>> On Mar 28, 2016, at 1:14 PM, Daniel Eggert  wrote:
>>> 
>>> This is on OS X will everything pulled from master yesterday. I'm using 
>>> Xcode, and I built a toolchain from source. Same happens with the 
>>> 2016-03-24 toolchain from swift.org.
>>> 
>>> 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 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 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 this difference is due to features like QoS not 
>>>>>> being cross platform portable or KVO not yet implementable in Swift. 
>>>>>> This is very much a work-in-progress; it needs unit tests and and a bit 
>>>>>> more polish, but hopefully it is good enough to get some work started in 
>>>>>> some other places.
>>>>>> 
>>>>>> - Philippe Hausler
>>>>> 
>>>>> 
>>>>> Great to see progress on this.
>>>>> 
>>>>> It does fail this simple test case, though:
>>>>> 
>>>>> 
>>>>> func test_BlockBasedAPI() {
>>>>>let queue = NSOperationQueue()
>>>>> 
>>>>>let expectation = expectationWithDescription("did run block")
>>>>>queue.addOperationWithBlock {
>>>>>expectation.fulfill()
>>>>>}
>>>>> 
>>>>>waitForExpectationsWithTimeout(0.001, handler: nil)
>>>>> }
>>>>> 
>>>>> I'm not sure what's going on there. I was using this on my branch for 
>>>>> NSURLSession since it has a delegate queue that I need to run callbacks 
>>>>> on.
>>>>> 
>>>>> /Daniel
>> 

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

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

[Philippe Hausler via swift-corelibs-dev]

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 potentially unknowns please feel free 
to ask questions for how things should be implemented or even questions of how 
the objective-c version works. Those types of discussions are absolutely fair 
game (to the most nitty gritty details).

For your example of NSSortDescriptor: that does have the reliance upon KVC and 
selectors which swift really does not have the introspection to do the KVC 
(beyond perhaps some simple cases) and selectors are not really a thing; we 
would have to change the API. KVC and KVO both were cut from the initial 
swift-corelibs implementation because we thought that they would not be 
something that could easily be implemented in Swift without features like 
property behaviors or other compiler/runtime support (and from swift-evolution 
there have been some discussions about even expressing key paths as something 
less stringy).

Would NSSortDescriptor be something that would be worthwhile to have if lets 
say it didn’t have selectors? Would it make sense as an implementation with 
generics to transact upon a protocol? Does it make sense as a reference type? 
Should it transact upon NSArray or Array?

Changing API is fair game, if there is something that you think is worth 
bringing to the table as a more swift friendly interface that would help all 
platforms (and perhaps even make the objc version better too). And we should 
discuss on what is the best path forward on those types of changes since some 
of the parties involved may span beyond those that work on the open source side 
of things.

The swift-corelibs-foundation definitely could use some performance boosts (I 
know for example the JSON and plist serialization implementations have some 
distinct bottlenecks) but I think our initial goals should be to get the 
surface area covered first and then after we can verify the behavior then 
performance optimizations can be made.

> On Apr 14, 2016, at 5:57 AM, Kiel Gillard via swift-corelibs-dev 
>  wrote:
> 
> Thanks for the reply and for pointing me to the design document.
> 
> I doubt that Foundation's dependency on the exclusive features of the 
> Objective-C runtime would be so instrumental to the majority of its 
> implementation details. I doubt things like algorithms and performance 
> optimisations used in Foundation are each and every time exclusive to the 
> ObjC runtime such that it justifies building a pure Swift implementation 
> without respect to its ancestor. Perennial problems in computer science have 
> their solutions in a variety of languages and runtimes. So even if a solution 
> is dependent on the ObjC runtime, there may be a spiritual sibling to a 
> solution.
> 
> For a simple example, I figured my first small contribution could be to the 
> implementation of NSSortDescriptor. The API seems straightforward and doesn't 
> suggest there's anything exclusive to the ObjC runtime (eg swizzling) going 
> on. So if I was to provide most of this implementation, I would be doing so 
> in the dark of any learnings from its release history.
> 
> Perhaps I need to suppress my sceptical feelings, trust Apple are making the 
> right decision here (because, you know, given they are the ones privy to the 
> source code!) and have faith that Apple won't eventually replace Foundation 
> with a buggy and underperforming equivalent for Swift developers. But I am 
> concerned for the quality of the platform and I desire to give the community 
> the best work I can. I would like to know what the error in my concern is and 
> if others in the community share this concern.
> 
> Kiel
> 
> Sent from my iPhone
> 
> On 14 Apr 2016, at 9:11 PM, Alexander Alemayhu  > wrote:
> 
>> 
>>> On 14 Apr 2016, at 02:32, Kiel Gillard via swift-corelibs-dev 
>>> mailto:swift-corelibs-dev@swift.org>> wrote:
>>> 
>>> Hello all,
>> 
>> Hei,
>> 
>>> 
>>> I’m considering contributing yet part of me feels hesitant or reluctant to 
>>> do so because I do not want to do a poor job at what feels like I’d be 
>>> reverse-engineering the Foundation APIs (as opposed to Core Foundation and 
>>> the pure Swift Foundation).
>> 
>> Cool, I also want to contribute :)
>> 
>>> 
>>> Perhaps I missed the answer somewhere else or maybe I’m lacking the 
>>> imagination to come up with reasons myself, but why isn’t Foundation (as it 
>>> ships in iOS and OS X now) open source, too?
>>> 
>>> Wouldn’t a pure Swift implementation of Foundation benefit from insights 
>>> from the implementation details of Foundation? For example, Foundation may 
>>> have implemented such-and-such an API in a particular way for performance 
>>> reasons that would be unacceptable if released. That insight may be lost by

Re: [swift-corelibs-dev] NSMassFormatter implementation

[Philippe Hausler via swift-corelibs-dev]

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 this?
> 
> Thanks,
> Mauricio
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

Re: [swift-corelibs-dev] NSEnergyFormatter

[Philippe Hausler via swift-corelibs-dev]

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 version 
too.

> On Apr 18, 2016, at 1:56 AM, Vojtěch Šťavík via swift-corelibs-dev 
>  wrote:
> 
> Actually, I have a question. What is the best way to get localized names for 
> units? It seems Mauricio has the same question at 
> https://github.com/apple/swift-corelibs-foundation/pull/320 
>  .
> 
> Subject: Re: [swift-corelibs-dev] NSEnergyFormatter
> From: anthony.par...@apple.com
> Date: Fri, 15 Apr 2016 10:07:18 -0700
> CC: swift-corelibs-dev@swift.org
> To: sta...@outlook.com
> 
> We certainly appreciate help on this. Let us know if you have any questions.
> 
> - Tony
> 
> On Apr 15, 2016, at 7:24 AM, Vojtěch Šťavík via swift-corelibs-dev 
> mailto:swift-corelibs-dev@swift.org>> wrote:
> 
> Hey guys,
> 
> I'd like to help you with the project. I was looking for something simple to 
> start with and I'd choose NSEnergyFormatter. It seems to be pretty 
> straightforward. Is it OK when I start working on it or you have some other 
> plan for formatters?
> 
> Vojta
> @vojtastavik
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org 
> https://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

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

Re: [swift-corelibs-dev] NSEnergyFormatter

[Philippe Hausler via swift-corelibs-dev]

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 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 version too.
> 
>> On Apr 18, 2016, at 1:56 AM, Vojtěch Šťavík via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> Actually, I have a question. What is the best way to get localized names for 
>> units? It seems Mauricio has the same question at 
>> https://github.com/apple/swift-corelibs-foundation/pull/320 
>> <https://github.com/apple/swift-corelibs-foundation/pull/320> .
>> 
>> Subject: Re: [swift-corelibs-dev] NSEnergyFormatter
>> From: anthony.par...@apple.com <mailto:anthony.par...@apple.com>
>> Date: Fri, 15 Apr 2016 10:07:18 -0700
>> CC: swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
>> To: sta...@outlook.com <mailto:sta...@outlook.com>
>> 
>> We certainly appreciate help on this. Let us know if you have any questions.
>> 
>> - Tony
>> 
>> On Apr 15, 2016, at 7:24 AM, Vojtěch Šťavík via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> Hey guys,
>> 
>> I'd like to help you with the project. I was looking for something simple to 
>> start with and I'd choose NSEnergyFormatter. It seems to be pretty 
>> straightforward. Is it OK when I start working on it or you have some other 
>> plan for formatters?
>> 
>> Vojta
>> @vojtastavik
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>> <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev>
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>> <https://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

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

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

[Philippe Hausler via swift-corelibs-dev]

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 
instantiated (in the case of max ops being 1) and initializing it to 1 to gate 
the operations.

> On May 5, 2016, at 1:15 AM, Mamatha Busi via swift-corelibs-dev 
>  wrote:
> 
> Hello
>  
> Code snippet:
> 
> ———
> 
>  let operation1 : NSBlockOperation = NSBlockOperation (block: {
> 
> sleep(1)
> 
> print("Opertion1")
> 
> })
> 
> let operation2 : NSBlockOperation = NSBlockOperation (block: {
> 
> sleep(1)
> 
> print("Opertion2”)
> 
> })
> 
> 
> var operations = [NSOperation]()
> 
> operations.append(operation1)
> 
> operations.append(operation2)
> 
>  
> let queue = NSOperationQueue()
> 
> queue.maxConcurrentOperationCount = 1
> 
> queue.addOperations(operations, waitUntilFinished: true)
> 
>  
>  
> 
>  
> The above code snippet of adding operations to an operation queue and 
> executing with the property ‘maxConcurrentOperationCount = 1’ fails while 
> executing the above with the OpenSource Foundation and libDispatch of MAC 
> inside Xcode. 
> 
> The error I am seeing is: 
> 
> fatal error: unexpectedly found nil while unwrapping an Optional value
> 
> Stack trace points to: attr = DISPATCH_QUEUE_SERIAL 
> 
> which implies that the libDispatch macro is coming as nil during the creation 
> of the serial queue using libDispatch in the file NSOperationQueue
> 
> The same test-case passes on OSx. 
> 
> When I do not restrict the serial operation i.e. I remove ‘  
> queue.maxConcurrentOperationCount = 1’ , test case executes successfully. 
> 
> Setting it to a different value other than 1 also causes no problems. 
> 
> Am I doing something wrong with the API. If I set the property ‘ 
> queue.maxConcurrentOperationCount = 1’ after adding operations to the queue, 
> then the problem does not occur. But then this restricts me to control the 
> operation execution to be serial. So, I expect the above snippet to work on 
> OpenSource as well. Any thoughts on this?
> 
>  
> Thank you.
>  
> Regards
> Mamatha
>  
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

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

[Philippe Hausler via swift-corelibs-dev]

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 
annotation. Worth looking into.

Sent from my iPhone

> On May 6, 2016, at 12:16 AM, Mamatha Busi  wrote:
> 
>  
> @ Philippe: Your right. Converting the 'attr' to an optional did do the job 
> of creating a serial queue successfully. Thanks for that. I will create a PR 
> for this.
>  
> But this makes me think as to why until now, this was not caught by the 
> compiler itself?
>  
> Regards
> Mamatha
>  
> - Original message -
> From: phaus...@apple.com
> To: Mamatha Busi/India/IBM@IBMIN
> Cc: swift-corelibs-dev 
> Subject: Re: [swift-corelibs-dev] Setting property 
> "maxConcurrentOperationCount = 1" of NSOperation fails to execute operations 
> using OpenSource Foundation.
> Date: Thu, May 5, 2016 10:54 PM
>  
> 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 
> instantiated (in the case of max ops being 1) and initializing it to 1 to 
> gate the operations.
>  
>> On May 5, 2016, at 1:15 AM, Mamatha Busi via swift-corelibs-dev 
>>  wrote:
>>  
>> Hello
>>  
>> Code snippet:
>> 
>> ———
>> 
>>  let operation1 : NSBlockOperation = NSBlockOperation (block: {
>> 
>> sleep(1)
>> 
>> print("Opertion1")
>> 
>> })
>> 
>> let operation2 : NSBlockOperation = NSBlockOperation (block: {
>> 
>> sleep(1)
>> 
>> print("Opertion2”)
>> 
>> })
>> 
>> 
>> var operations = [NSOperation]()
>> 
>> operations.append(operation1)
>> 
>> operations.append(operation2)
>> 
>>  
>> let queue = NSOperationQueue()
>> 
>> queue.maxConcurrentOperationCount = 1
>> 
>> queue.addOperations(operations, waitUntilFinished: true)
>> 
>>  
>>  
>> 
>>  
>> The above code snippet of adding operations to an operation queue and 
>> executing with the property ‘maxConcurrentOperationCount = 1’ fails while 
>> executing the above with the OpenSource Foundation and libDispatch of MAC 
>> inside Xcode. 
>> 
>> The error I am seeing is: 
>> 
>> fatal error: unexpectedly found nil while unwrapping an Optional value
>> 
>> Stack trace points to: attr = DISPATCH_QUEUE_SERIAL 
>> 
>> which implies that the libDispatch macro is coming as nil during the 
>> creation of the serial queue using libDispatch in the file NSOperationQueue
>> 
>> The same test-case passes on OSx. 
>> 
>> When I do not restrict the serial operation i.e. I remove ‘  
>> queue.maxConcurrentOperationCount = 1’ , test case executes successfully. 
>> 
>> Setting it to a different value other than 1 also causes no problems. 
>> 
>> Am I doing something wrong with the API. If I set the property ‘ 
>> queue.maxConcurrentOperationCount = 1’ after adding operations to the queue, 
>> then the problem does not occur. But then this restricts me to control the 
>> operation execution to be serial. So, I expect the above snippet to work on 
>> OpenSource as well. Any thoughts on this?
>> 
>>  
>> Thank you.
>>  
>> Regards
>> Mamatha
>>  
>> 
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org
>> https://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

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

[Philippe Hausler via swift-corelibs-dev]

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)

> On May 16, 2016, at 9:34 AM, Ian Partridge via swift-corelibs-dev 
>  wrote:
> 
> 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

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

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

[Philippe Hausler via swift-corelibs-dev]

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-corelibs-dev 
>  wrote:
> 
> Hi people,
> 
> Found some time to continue contributing to corelibs, but I’m getting a 
> compilation error with master:
> 
> NSGeometry.swift (line 39):
> 35 private var hash: Int {
> 36 #if arch(i386) || arch(arm)
> 37 return Int(Float(self.native).bitPattern)
> 38 #else
> 39 return Int(self.native.bitPattern) // Value of type 'NativeType' 
> (aka 'Double') has no member 'bitPattern’
> 40 #endif
> 41 }
> 
> I’m using the latest development toolchain. Is that correct? I tried building 
> a master toolchain instead but got a failing test.
> 
> Any ideas?
> David.
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

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

[Philippe Hausler via swift-corelibs-dev]

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 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-corelibs-dev 
>>  wrote:
>> 
>> Hi people,
>> 
>> Found some time to continue contributing to corelibs, but I’m getting a 
>> compilation error with master:
>> 
>> NSGeometry.swift (line 39):
>> 35 private var hash: Int {
>> 36 #if arch(i386) || arch(arm)
>> 37 return Int(Float(self.native).bitPattern)
>> 38 #else
>> 39 return Int(self.native.bitPattern) // Value of type 'NativeType' 
>> (aka 'Double') has no member 'bitPattern’
>> 40 #endif
>> 41 }
>> 
>> I’m using the latest development toolchain. Is that correct? I tried 
>> building a master toolchain instead but got a failing test.
>> 
>> Any ideas?
>> David.
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org
>> https://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

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

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

[Philippe Hausler via swift-corelibs-dev]

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.

The Python config file is way too complex as it is and was only really designed 
as a stopgap measure. If we can simplify I think it would definitely improve 
the state of things: it is worth investigating.

Sent from my iPhone

> On May 23, 2016, at 3:03 PM, David Hart via swift-corelibs-dev 
>  wrote:
> 
> Would you agree that the first step should be to have the project as a 
> SwiftPM package so that we have a more consistent way to run tests on all 
> platforms? Do you know if SwiftPM is far enough to support 
> swift-corelibs-foundation? I might have a go at it once I finish implementing 
> NSProgress (about half way through I think).
> 
>> On 23 May 2016, at 17:59, Tony Parker via swift-corelibs-dev 
>>  wrote:
>> 
>> Hi David,
>> 
>>> On May 22, 2016, at 8:15 AM, David Hart via swift-corelibs-dev 
>>>  wrote:
>>> 
>>> Hello,
>>> 
>>> The discussion we had previously on this mailing list made it quite clear 
>>> that:
>>> 
>>> - Objective-C Foundation is the framework that is supposed to be used on 
>>> all Darwin platforms,
>>> - swift-corelibs-foundation will be the Foundation framework for all other 
>>> platforms,
>>> - Both frameworks will evolve slowly together.
>> 
>> Yup.
>> 
>>> 
>>> Therefore, it makes sense that for code written against Foundation to be 
>>> portable, the swift-corelibs-foundation APIs and behavior needs to be 
>>> identical to Darwin Foundation. Hence the following questions?
>>> 
>>> - Shouldn't we be writing tests in a way so that they can be run against 
>>> Darwin Foundation and have the CI Server run them? For example: while 
>>> working on NSProgress, I write a bunch of tests against Darwin Foundation, 
>>> make sure they pass, then copy-paste them in the CoreLibs project, and fix 
>>> the implementation until they pass. This makes sure that both APIs are 
>>> consistent with each other. I was thinking that we ought to automate this 
>>> and have the CI server test them.
>> 
>> That would be a great step. This is part of the reason we tried to set up 
>> the dependencies of Foundation on XCTest the way we did, and provide the 
>> Xcode project file; so we could share tests. I would welcome any help we can 
>> get on improving our automation story here.
>> 
>>> 
>>> - How are we planning to reconcile the API differences between both 
>>> frameworks? For examples, one of my tests will run against CoreLibs but not 
>>> against Darwin because NSThread.init takes a closure as argument in 
>>> CoreLibs but a target+selector in Darwin. This is just one example, but I 
>>> guess they are other inconsistencies elsewhere. This seems to be 
>>> particularly the case with APIs that rely on the Objective-C runtime.
>> 
>> These should be marked as “experimental” in the documentation comments. If 
>> not, we should do that.
>> 
>> There are some areas where we just don’t know what to do yet, because of the 
>> lack of the ObjC runtime and implicit bridging on Linux. In some of those 
>> places we’ve tried to provide a replacement API and mark it as experimental 
>> until we can figure out the larger story.
>> 
>>> In general, I'm starting to worry about the state of Foundation from a 
>>> portability point of view. Once Swift 3 is released, I want to start 
>>> writing portable swift code that relies on Foundation. And it seems like 
>>> this will require a huge amount of #if os() everywhere to cope with the 
>>> differences.
>>> 
>>> David
>> 
>> Our long term goal is to enable developers to do this. I acknowledge that we 
>> have a ways to go to get there. I’ve seen an uptick in contributions 
>> recently, which gives me hope that we can get closer before the release of 
>> Swift 3.
>> 
>> - Tony
>> 
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org
>> https://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
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

[Philippe Hausler via swift-corelibs-dev]

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 testable with a reduced 
scope of interfaces. Formatter subclasses are a great point to start with. Some 
of the NSUnimplemented methods are minefields that would require runtime 
support, whereas others are great points to start with.

Furthermore there will likely be a few good ones that will come in when the 
proposals start to land; there is a lot of busy work with the whole naming 
changes. So stay tuned on that front.

> On May 23, 2016, at 7:18 PM, Brian Gesiak via swift-corelibs-dev 
>  wrote:
> 
> I'm glad people are finding these useful!!
> 
> Yes, I've made one for corelibs-foundation as well: 
> https://bugs.swift.org/secure/Dashboard.jspa?selectPageId=10410 
> 
> 
> Of course, as David mentioned, task curation is what makes these dashboards 
> really shine. Try assigning the "swift-3.0" label to tasks that should be 
> taken care of in time for its release. Also, I noticed 
> swift-corelibs-foundation doesn't have many tasks with the "StarterBug" 
> label. I think those are a great way to encourage more people to contribute.
> 
> - Brian Gesiak
> 
> 
> On Mon, May 23, 2016 at 5:57 PM, David Hart  > wrote:
> Brian Gesiak started started one for foundation. It seems it's only missing 
> some trimming and labeling of issues:
> 
>> David,
>> 
>> I actually started on one! http://tinyurl.com/foundation-dashboard 
>>  :)
>> 
>> Like you mentioned, I don't have a ton of context on the project, so I'm a 
>> little hesitant to decide what should be tagged with "swift-3.0".
>> 
>> Still, one thing that stands out: swift-corelibs-foundation has only one 
>> task with the StarterBug label! I wonder if some tasks can be cleaned up, 
>> given clearer instructions, and labeled as a starter task...
>> 
>> - Brian Gesi
> 
> 
> On 23 May 2016, at 22:41, Tony Parker via swift-corelibs-dev 
> mailto:swift-corelibs-dev@swift.org>> wrote:
> 
>> This is slick!
>> 
>> I would love to have one for Foundation too (although my understanding of 
>> JIRA is limited at best).
>> 
>> - Tony
>> 
>>> On May 22, 2016, at 12:47 PM, Brian Gesiak via swift-corelibs-dev 
>>> mailto:swift-corelibs-dev@swift.org>> wrote:
>>> 
>>> Hello all!
>>> 
>>> If you're like me, you might be curious how Core Libraries like 
>>> swift-corelibs-xctest are doing with regards to the looming Swift 3.0 
>>> release. Well, wonder no more -- this handy JIRA dashboard has the 
>>> information you need: 
>>> https://bugs.swift.org/secure/Dashboard.jspa?selectPageId=10408 
>>> 
>>> 
>>> The dashboard not only lists tasks that need to be resolved by Swift 3.0, 
>>> but also open starter tasks for new contributors.
>>> 
>>> Let me know if you find it useful! I personally think it'd be neat to have 
>>> one of these for all the swift-corelibs-* projects, what do you all think? 
>>> :)
>>> 
>>> PS: For those interested, the dashboard is implemented using custom task 
>>> filters:
>>> 
>>> - corelibs-xctest Open Tasks: https://bugs.swift.org/issues/?filter=10469 
>>> 
>>> - corelibs-xctest Open 3.0 Tasks: 
>>> https://bugs.swift.org/issues/?filter=10471 
>>> 
>>> - corelibs-xctest Open Starter Tasks: 
>>> https://bugs.swift.org/issues/?filter=10470 
>>> 
>>> 
>>> To track tasks related to Swift 3.0, I created a new "swift-3.0" label in 
>>> JIRA. I hope no one minds. (+cc Jordan Rose, I've seen him managing labels 
>>> on JIRA before.)
>>> 
>>> - Brian Gesiak
>>> 
>>> ___
>>> swift-corelibs-dev mailing list
>>> swift-corelibs-dev@swift.org 
>>> https://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 
>> 
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

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

[Philippe Hausler via swift-corelibs-dev]

My suggestion to work around this issue: revert that commit locally - the rest 
should build fine. Unfortunately the change was made without a workaround for a 
deprecated transition when the new accessor was added so we had a hard 
transition that required a full rebuild or else the CI would 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 
>> 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 testable with 
>> a reduced scope of interfaces. Formatter subclasses are a great point to 
>> start with. Some of the NSUnimplemented methods are minefields that would 
>> require runtime support, whereas others are great points to start with.
>> 
>> Furthermore there will likely be a few good ones that will come in when the 
>> proposals start to land; there is a lot of busy work with the whole naming 
>> changes. So stay tuned on that front.
> 
> I would love to help out, but can't get the Xcode workspace to compile due 
> the the `return Int(self.native.bitPattern)` issue. 
> 
> Is a new development toolchain likely to be released soon, as I'm struggling 
> to build my own toolchain.
> 
> Regards,
> 
> Rob...
> 
> 
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

[Philippe Hausler via swift-corelibs-dev]

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 script I 
personally use for iterating specific slices of the toolchain: 
https://gist.github.com/phausler/70c8a6c231fedd8a8008f6a6bbaf48d4 


Note: that script is something I use on my machine with hard coded paths so 
your mileage may vary; it is a brutal install phase that just erases the 
previous install of that identifier and copies the built product out. So be 
forwarded you can poke your eye out with this script.

Also after installing a new toolchain it is usually good to restart Xcode and 
clear your module cache just in case there is cruft lying around (when things 
get goofed up sometimes bad state can make it hard to work with things)

> On May 30, 2016, at 11:57 AM, Rajeev Jeyaraj via swift-corelibs-dev 
>  wrote:
> 
> Hi All,
> 
> I am trying to build the swift-corelibs-foundation
> 
> I followed the instructions from here: 
> https://github.com/apple/swift-corelibs-foundation/blob/master/Docs/GettingStarted.md
>  
> 
> 
> At step 3, I am getting the following errors below.
> Run Xcode with the latest toolchain. Follow the instructions here 
>  to start Xcode with the correct 
> toolchain.
> Open Foundation.xcworkspace.
> Build the SwiftFoundation target. This builds CoreFoundation and Foundation.
> 
> 
> Foundation.build/Debug/SwiftFoundation.build/Objects-normal/x86_64/NSXMLDTDNode.swiftdeps
>  -o 
> /Users/Snuffles/Library/Developer/Xcode/DerivedData/Foundation-adgjiwkgknrodccxdwfsovunshof/Build/Intermediates/Foundation.build/Debug/SwiftFoundation.build/Objects-normal/x86_64/NSXMLDTDNode.o
> 
> /Users/Snuffles/development/swift-corelibs-foundation/Foundation/NSXMLDTDNode.swift:242:64:
>  error: cannot convert value of type 'UnsafeMutablePointer' (aka 
> 'UnsafeMutablePointer<()>') to expected argument type 'OpaquePointer'
> let unmanaged = Unmanaged.fromOpaque(privateData)
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

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

[Philippe Hausler via swift-corelibs-dev]

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-foundation from command line, is there a 
> way to specifiy it in the swift/utils/build script?
> 
> Thanks
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

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

[Philippe Hausler via swift-corelibs-dev]

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, Rajeev Jeyaraj  
> wrote:
> 
> i'm trying to build it on mac OS X, i'm having issue with Xcode picking up my 
> tool chain, built via the build-toolchain script.
> Is there any way I can build from the command line, rather than having to go 
> through Xcode?
> 
> On 7 June 2016 at 21:01, Philippe Hausler  > wrote:
> 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 
> > mailto:swift-corelibs-dev@swift.org>> wrote:
> >
> > Hi All,
> >
> > I am trying to build the corelibs-foundation from command line, is there a 
> > way to specifiy it in the swift/utils/build script?
> >
> > Thanks
> > ___
> > swift-corelibs-dev mailing list
> > swift-corelibs-dev@swift.org 
> > https://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

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

[Philippe Hausler via swift-corelibs-dev]

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 attention that the NSKeyValueCoding protocol which is a part of 
> the Darwin-(ObjC-)Foundation (see 
> https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Protocols/NSKeyValueCoding_Protocol/
>  ) is somehow omitted here: 
> https://github.com/apple/swift-corelibs-foundation/blob/master/Docs/Status.md
> 
> Was this done on purpose or is the implementation of NSKeyValueCoding still 
> forthcoming?
> 
> Thanks,
> 
>   Lars
> 
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

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

[Philippe Hausler via swift-corelibs-dev]

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:44 AM, Mamatha Busi via swift-corelibs-dev 
>  wrote:
> 
> Hi
>  
> Trying to implement the JSONSerialization unimplemented method 
> jsonObject(withStream). 
>  
>  JSONSerialization.jsonObject(with stream: InputStream, options opt: 
> ReadingOptions = []) throws -> AnyObject
>  
> The comments in the source code mentions that apart from stream configuration 
> all other behaviour of this method is the same as the 
> JSONObjectWithData:options:error.
> This implies that I can internally reuse the JSONObjectWithData method, 
> however its return type is ‘Any’ whereas the return type in 
> jsonObjectWithStream is ‘AnyObject’. As I cannot downcast ‘Any’ to 
> ‘AnyObject’, I’m looking for inputs if I should rewrite the behaviour or is 
> there any other way?
>  
> Thank you.
>  
> -Mamatha.
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

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

[Philippe Hausler via swift-corelibs-dev]

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:

open func perform(_ aSelector: Selector, on thr: Thread, with arg: Any?, 
waitUntilDone wait: Bool)

> On Aug 15, 2016, at 3:53 PM, Paul Hudson via swift-corelibs-dev 
>  wrote:
> 
> Hello!
> 
> I just noticed that performSelectorInBackground(_:withObject:) has
> been mapped to performSelector(inBackground:with:) in Swift 3. So:
> 
> performSelector(inBackground: #selector(doStuff), with: nil)
> 
> This seems confusing to me – the "inBackground" label has little to do
> with the selector that is attached to it. It's possible this has been
> through careful API review and if so I apologize. On the other hand,
> if it's an oversight is there time for it to be looked at again?
> 
> Thank you!
> 
> 
> Paul
> --
> Free Swift tutorials – hackingwithswift.com
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

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

[Philippe Hausler via swift-corelibs-dev]

> 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: Any?, 
> waitUntilDone wait: Bool, modes array: [String]?)
> 
> But perhaps the naming family should belong to this one:
> 
> open func perform(_ aSelector: Selector, on thr: Thread, with arg: Any?, 
> waitUntilDone wait: Bool)
> 
>> On Aug 15, 2016, at 3:53 PM, Paul Hudson via swift-corelibs-dev 
>>  wrote:
>> 
>> Hello!
>> 
>> I just noticed that performSelectorInBackground(_:withObject:) has
>> been mapped to performSelector(inBackground:with:) in Swift 3. So:
>> 
>> performSelector(inBackground: #selector(doStuff), with: nil)
>> 
>> This seems confusing to me – the "inBackground" label has little to do
>> with the selector that is attached to it. It's possible this has been
>> through careful API review and if so I apologize. On the other hand,
>> if it's an oversight is there time for it to be looked at again?

Unfortunately per timing wise we are really late in the game to fix the names 
of things. It would require a full API review to push through a better name for 
it. (However I agree that perhaps we should rename them)

Also there were a pair of block variants added to RunLoop that falls into this 
family:

open func perform(inModes modes: [RunLoopMode], block: @escaping () -> 
Swift.Void)
open func perform(_ block: @escaping () -> Swift.Void)

>> 
>> Thank you!
>> 
>> 
>> Paul
>> --
>> Free Swift tutorials – hackingwithswift.com
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org
>> https://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

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

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

[Philippe Hausler via swift-corelibs-dev]

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:

open func perform(onMainThread aSelector: Selector, with arg: Any?, 
waitUntilDone wait: Bool, modes array: [String]?)

That way the call sites would look like this:

myObject.perform(inBackground: #selector(doBackgroundStuff), with: nil)
myObject.perform(onMainThread: #selector(doMainThreadStuff), with: nil)
myObject.perform(#selector(doDelayedThings), with: nil, afterDelay: 0.7)
let result = myObject.perform(#selector(doThingsNow), with: 
nil).takeUnretainedValue()

> On Aug 16, 2016, at 8:46 AM, Shawn Erickson via swift-corelibs-dev 
>  wrote:
> 
> It is following the naming methodology of a sentence like structure 
> "performed selector in background  with ". It does read a 
> little strange but likely comes from a simple remapping of the existing 
> objective-c name for familiarly reasons.
> 
> It could be performInBackground(selector:,with:) ... "Perform in background 
>  with " but that also reads a little strange.
> 
> -Shawn
> 
> On Tue, Aug 16, 2016 at 8:40 AM Paul Hudson via swift-corelibs-dev 
> mailto:swift-corelibs-dev@swift.org>> wrote:
> Hello!
> 
> I just noticed that performSelectorInBackground(_:withObject:) has
> been mapped to performSelector(inBackground:with:) in Swift 3. So:
> 
> performSelector(inBackground: #selector(doStuff), with: nil)
> 
> This seems confusing to me – the "inBackground" label has little to do
> with the selector that is attached to it. It's possible this has been
> through careful API review and if so I apologize. On the other hand,
> if it's an oversight is there time for it to be looked at again?
> 
> Thank you!
> 
> 
> Paul
> --
> Free Swift tutorials – hackingwithswift.com 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org 
> https://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

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

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

[Philippe Hausler via swift-corelibs-dev]

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 mean that Dispatch 
> always builds on Linux if your using Foundation, and as Dispatch is already 
> there on Darwin, it should mean we can remove the condition statements 
> entirely. 
> 
> Chris
> 
> 
> 
> 
> From:Luke Howard via swift-corelibs-dev 
>  
> To:Tony Parker via swift-corelibs-dev  
> Date:23/08/2016 08:55 
> Subject:Re: [swift-corelibs-dev] f8c3fe6c breaks on Darwin 
> Sent by:swift-corelibs-dev-boun...@swift.org 
> 
> 
> 
> Also, the NSData test is broken on Darwin when libdispatch is enabled – 
> possibly the system DispatchData is being pulled in and something funny 
> happens, this seems to work around it but I’m not sure if it is the correct 
> fix: 
> 
> +++ b/Foundation/NSData.swift 
> @@ -228,7 +228,7 @@ open class NSData : NSObject, NSCopying, 
> NSMutableCopying, NSSecureCoding { 
>  } 
>   
>  open override func isEqual(_ value: Any?) -> Bool { 
> -#if DEPLOYMENT_ENABLE_LIBDISPATCH 
> +#if DEPLOYMENT_ENABLE_LIBDISPATCH && !os(OSX) 
>  if let data = value as? DispatchData { 
>  if data.count != length { 
>  return false 
> 
> 
> On 23 Aug 2016, at 5:46 PM, Luke Howard via swift-corelibs-dev 
> mailto:swift-corelibs-dev@swift.org>> wrote: 
> 
> Enabling libdispatch seems to break the tests on Darwin because 
> DEPLOYMENT_ENABLE_LIBDISPATCH is not added to the XCode project build flags 
> (both for the C/Swift compilers). 
> 
> -- 
> www.lukehoward.com 
> soundcloud.com/lukehoward  
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>  
> 
> -- 
> www.lukehoward.com 
> soundcloud.com/lukehoward 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

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

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

[Philippe Hausler via swift-corelibs-dev]

+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++ to be built in CF. 

Is there a specific version of ICU that we need to pick that functionality up? 
As it stands we don’t have a upper version limit on ICU but if we had a portion 
of the ICU source in CF it would probably mean that we would get symbolic 
conflicts when linking against versions that already had that.

> On Aug 22, 2016, at 1:36 PM, Will Stanton via swift-corelibs-dev 
>  wrote:
> 
> I recall the time formatter being deprecated in favor of measfmt, so you 
> might be right that uatimeunitformat isn't needed. I think some functions in 
> uatimeunitformat.cpp made combining units easier when calling from (then 
> NS)DateComponentsFormatter, but perhaps that can be put functionality in a 
> (Swift-)CFDateComponentsFormatter wrapper. (Not sure if Apple will come out 
> with its own CFDateComponentsFormatter).
> 
> 
> I think this was what I had to change to get C++ working:
> https://github.com/apple/swift-corelibs-foundation/blob/master/lib/phases.py
> The includes for CompileCxx should be more like CompileC.
> 
> Regards,
> Will Stanton
> 
> Sent from my iPhone
> 
>> On Aug 22, 2016, at 15:58, Henry Betts via swift-corelibs-dev 
>>  wrote:
>> 
>> Yes - I was planning on including uameasureformat.cpp for the linux build, 
>> although I was also unsure whether the build script was setup to compile c++.
>> Noticed a bug in uameasureformat.cpp by the way; DURATION_DAY and 
>> DURATION_WEEK are the wrong way around!
>> 
>> I’m a bit confused by uatimeunitformat. I’m probably missing something 
>> obvious, but what can it do that uameasureformat can’t do?
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

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

[Philippe Hausler via swift-corelibs-dev]

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, after 
> updating that:
> 
> /Users/lukeh/CVSRoot/apple/swift-corelibs-foundation/Foundation/NSURLSession/MultiHandle.swift:216:38:
>  error: '_EasyHandle' is not a member type of 'URLSessionTask'
> fileprivate extension URLSessionTask._EasyHandle {
>   ~~ ^
> 
>> On 24 Aug 2016, at 1:50 AM, Philippe Hausler > > wrote:
>> 
>> 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 
>>> mailto:swift-corelibs-dev@swift.org>> wrote:
>>> 
>>> We're currently making the last few changes which should mean that Dispatch 
>>> always builds on Linux if your using Foundation, and as Dispatch is already 
>>> there on Darwin, it should mean we can remove the condition statements 
>>> entirely. 
>>> 
>>> Chris
>>> 
>>> 
>>> 
>>> 
>>> From:Luke Howard via swift-corelibs-dev 
>>> mailto:swift-corelibs-dev@swift.org>> 
>>> To:Tony Parker via swift-corelibs-dev >> > 
>>> Date:23/08/2016 08:55 
>>> Subject:Re: [swift-corelibs-dev] f8c3fe6c breaks on Darwin 
>>> Sent by:swift-corelibs-dev-boun...@swift.org 
>>>  
>>> 
>>> 
>>> 
>>> Also, the NSData test is broken on Darwin when libdispatch is enabled – 
>>> possibly the system DispatchData is being pulled in and something funny 
>>> happens, this seems to work around it but I’m not sure if it is the correct 
>>> fix: 
>>> 
>>> +++ b/Foundation/NSData.swift 
>>> @@ -228,7 +228,7 @@ open class NSData : NSObject, NSCopying, 
>>> NSMutableCopying, NSSecureCoding { 
>>>  } 
>>>   
>>>  open override func isEqual(_ value: Any?) -> Bool { 
>>> -#if DEPLOYMENT_ENABLE_LIBDISPATCH 
>>> +#if DEPLOYMENT_ENABLE_LIBDISPATCH && !os(OSX) 
>>>  if let data = value as? DispatchData { 
>>>  if data.count != length { 
>>>  return false 
>>> 
>>> 
>>> On 23 Aug 2016, at 5:46 PM, Luke Howard via swift-corelibs-dev 
>>> mailto:swift-corelibs-dev@swift.org>> wrote: 
>>> 
>>> Enabling libdispatch seems to break the tests on Darwin because 
>>> DEPLOYMENT_ENABLE_LIBDISPATCH is not added to the XCode project build flags 
>>> (both for the C/Swift compilers). 
>>> 
>>> -- 
>>> www.lukehoward.com 
>>> soundcloud.com/lukehoward  
>>> ___
>>> swift-corelibs-dev mailing list
>>> swift-corelibs-dev@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>>>  
>>> 
>>> -- 
>>> www.lukehoward.com 
>>> soundcloud.com/lukehoward  
>>> ___
>>> swift-corelibs-dev mailing list
>>> swift-corelibs-dev@swift.org 
>>> https://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 
>>> 
>> 
> 
> --
> www.lukehoward.com 
> soundcloud.com/lukehoward
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

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

[Philippe Hausler via swift-corelibs-dev]

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, Henry Betts  wrote:
> 
> 
>> On 23 Aug 2016, at 16:58, Philippe Hausler  wrote:
>> 
>> Is there a specific version of ICU that we need to pick that functionality 
>> up? As it stands we don’t have a upper version limit on ICU but if we had a 
>> portion of the ICU source in CF it would probably mean that we would get 
>> symbolic conflicts when linking against versions that already had that.
> 
> 
> Looks like the C++ MeasureFormat (and friends) have existed since ICU 3.0, 
> although they have not yet got around to implementing a C interface. I don’t 
> think symbolic conflicts would occur, since, if ICU did eventually introduce 
> the C interface, I assume that it would use just a “u” prefix rather than 
> “ua”. Not sure if that’s what you meant.
> 
> Alternatively, I suppose we could just bypass uameasureformat, and interact 
> with the c++ api directly in CF, since it looks like it’s going to have to be 
> setup to compile c++ anyway.
> 
> Henry

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

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

[Philippe Hausler via swift-corelibs-dev]

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 
> Swift and Foundation types on Linux. For example this one: 
> https://bugs.swift.org/browse/SR-2477 (Double/Int don't coerce with NSNumber 
> on Linux). 
> 
> Is there any general approach you'd suggest to work around this coercion 
> limitation on Linux?
> 
> Pushkar N Kulkarni,
> IBM Runtimes
> 
> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
> 
> 
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

[Philippe Hausler via swift-corelibs-dev]

>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 don't see the 
>winds changing in the immediate future to support ref type bridges uniformly 
>in a cross platform manner. So the only recourse from what I can imagine is to 
>make methods that take Any really respond to any via internal 
>reinterpretation. The return types however are a different story since that 
>makes a requirement on the caller to do the "right" thing.

Sent from my iPhone

> On Sep 8, 2016, at 11:03 AM, Pushkar N Kulkarni  wrote:
> 
> Hi Philippe, 
> 
> Thanks for your response! I have one more question.
> 
> >> In general it is because we don't have bridging on Linux.
> Will we have it in future? Pardon my ignorance. 
> 
> Pushkar N Kulkarni,
> IBM Runtimes
> 
> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
> 
> 
> 
> -phaus...@apple.com wrote: -
> To: Pushkar N Kulkarni/India/IBM@IBMIN
> From: Philippe Hausler 
> Sent by: phaus...@apple.com
> Date: 09/08/2016 09:11PM
> Cc: Tony Parker , Swift corelibs dev 
> 
> Subject: Re: 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 
>> Swift and Foundation types on Linux. For example this one: 
>> https://bugs.swift.org/browse/SR-2477 (Double/Int don't coerce with NSNumber 
>> on Linux). 
>> 
>> Is there any general approach you'd suggest to work around this coercion 
>> limitation on Linux?
>> 
>> Pushkar N Kulkarni,
>> IBM Runtimes
>> 
>> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
>> 
>> 
> 
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Calendar identifiers

[Philippe Hausler via swift-corelibs-dev]

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 doesn't happen with ISO8601 alone. There are half a dozen 
> identifiers that aren't supported. Having said that, I added these 
> identifiers to that if-statement and the calendar initialization did happen:
> 
> .indian, .islamicTabular, .islamicUmmAlQura, .iso8601, .persian, 
> .republicOfChina
> 
> I am not sure if they would cause any other problems thought. 
> 
> Another thing I got curious about: Why is NSCalendar.Identifier.ISO8601 
> associated with an empty string here (it doesn't really matter, I guess)?
> https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSCalendar.swift#L56
>  
> 
> 
> 
> Pushkar N Kulkarni,
> IBM Runtimes
> 
> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
> 
> 
> 
> -alb...@apple.com  wrote: -
> To: Pushkar N Kulkarni/India/IBM@IBMIN
> From: Alex Blewitt 
> Sent by: alb...@apple.com 
> Date: 10/04/2016 03:28PM
> Cc: swift-corelibs-dev  >
> Subject: Re: [swift-corelibs-dev] Calendar identifiers
> 
> 
>> On 4 Oct 2016, at 10:29, Pushkar N Kulkarni via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> Hi there, 
>> 
>> I've hit an obstacle while working on a crash seen in initing a Calendar 
>> (https://bugs.swift.org/browse/SR-2551) 
>> 
>> 
>> For the Calendar initialiser "init(identifier: Calendar.Identifier)", the 
>> possible values of Calendar.Identifier are listed here 
>> . 
>> However, we eventually end up calling 
>> "_CFCalendarInitWithIdentifier(CFCalendarRef calendar, CFStringRef 
>> identifier)" and the latter works only for a specific set of calendar 
>> identifiers. See this if statement:
>>
>> https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/Locale.subproj/CFCalendar.c#L239
>>  
>> 
>> 
>> For other identifier values, we crash (that is SR-2551). On mac, all the 
>> identifier values are supported. It seems that the calendar identifier is 
>> ultimately encoded as a key-value pair in the locale ID for the calendar.  
>> 
>> Can anybody please help me understand the rationale of the if-statement 
>> above? I am new to ICU. I did search for justifications but didn't come 
>> across convincing. 
> 
> The if statement is canonicalising the reference to the constant e.g. 
> kCFCalendarIdentifierBuddhist. This allows other instances to be passed in 
> but then resolved to the same instance, such that pointer comparisons work 
> for future calls. The same is done for Swift.
> 
> On macOS, there are additional checks in the CoreFoundation equivalent (such 
> as kCFCalendarIdentifierISO8601) which is why it works on Darwin. However, I 
> don't know if there were specific reasons for excluding the ISO8601 calendar, 
> unless the ICU library doesn't understand it. Testing adding support should 
> be a case of doing something similar to this commit, which re-enabled the 
> Chinese calendar:
> 
> https://github.com/apple/swift-corelibs-foundation/commit/c1d940dd6099de65f959fd42274cf0e65984efe0
>  
> 
> Of course building with the 'if' switch enabled may highlight other issues, 
> but on a quick test build it seems that adding the additional if case to the 
> statement results in the ISO8601 calendar being returned. I'll let others 
> explain in more detail if there's some specific subtlety for why it was left 
> out in the first place.
> 
> Alex
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

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

[Philippe Hausler via swift-corelibs-dev]

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 
SystemZ so some of the changes that I made may have regressed some of our ports.

One major change that I had to make due to other constraints was a re-work of 
some of the string constants. This makes the Android symbolic definition for 
NSConstantString no longer work and we should consider a more uniform method to 
do that similar to the Ubuntu targets (which was modeled after the Darwin 
version). If you have time; please review the cross platform changes that were 
made on https://github.com/apple/swift-corelibs-foundation/pull/709. I will be 
making some additional changes to gate ICU versions and some other key portions 
for making certain this builds on all platforms.

Thanks for your time,
Philippe
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

[Philippe Hausler via swift-corelibs-dev]

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 where there are two web apps running on the same server. 
They should never share data between them unless specifically allowed to. 
Service A uses Foundation version A and service B uses version B. Unless 
service A and B have privileges to communicate they should never use common 
storage for cookies or preferences. This could allow service A to 
inappropriately use the stored credentials of service B if they are stored in 
the same directory. Moreover if the version B of Foundation has some refinement 
to the storage version of the cookie the file may be incompatible with 
Foundation A’s reading schema. 

In my opinion the directories should be unique to the services running unless 
they share a system based privilege system that is a common version (e.g. they 
are allowed to talk to each other and are not sandboxed apart).

Of course some of this could be side-stepped by having the services running as 
different users. But the versioning issue still occurs and should perhaps be 
something that we consider.


> On Nov 14, 2016, at 9:44 AM, Tony Parker via swift-corelibs-dev 
>  wrote:
> 
> Isn’t it a bit odd to use ‘.foundation’ as the name of the directory, when 
> Foundation is just one of the libraries involved? On Darwin, the prefs are 
> organized by application, not by framework.
> 
> - Tony
> 
>> On Nov 14, 2016, at 1:43 AM, Pushkar N Kulkarni via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> Thanks Will! 
>> 
>> "NSHomeDirectory() + "/.foundation/Cookies/shared" seems good to me
>> 
>> Pushkar N Kulkarni,
>> IBM Runtimes
>> 
>> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
>> 
>> 
>> 
>> -Will Stanton mailto:willstant...@yahoo.com>> 
>> wrote: -
>> To: Pushkar N Kulkarni/India/IBM@IBMIN
>> From: Will Stanton mailto:willstant...@yahoo.com>>
>> Date: 11/08/2016 08:45AM
>> Cc: swift-corelibs-dev > >
>> Subject: Re: [swift-corelibs-dev] Implementing HTTPCookieStorage
>> 
>> Was wondering if there could be a common directory for Foundation-related 
>> files, such as NSUserDefaults in addition to cookie storage?
>> 
>> So maybe for cookies:
>> NSHomeDirectory() + "/.foundation/Cookies/shared"
>> 
>> And settings for an app/service:
>> NSHomeDirectory() + "/.foundation/Preferences/EXECUTABLE_NAME.plist"
>> 
>> 
>> And I’m not familiar with how Apple Foundation/CFNetwork/nsurlsessiond 
>> handles cookies… or caches things, but I think I agree with Kenny that 
>> naming symmetry would be nice if there is a per-user cookies file.
>> 
>> So having a /Library may be nicer, but potentially unnecessary?
>> NSHomeDirectory() + "/.foundation/Library/Cookies/Cookies.something"
>> 
>> Regards,
>> Will Stanton
>> 
>> > On Nov 7, 2016, at 5:45 PM, Tony Parker via swift-corelibs-dev 
>> > mailto:swift-corelibs-dev@swift.org>> wrote:
>> > 
>> > Hi Pushkar,
>> > 
>> > Good question. If this were Darwin I guess I would say 
>> > ~/Library/Application Support — but I don’t know what the best practices 
>> > are on other platforms. Does anyone out there have some suggestions?
>> 
>> 
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org 
>> https://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

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

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

[Philippe Hausler via swift-corelibs-dev]

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/NSNotification.swift
> ./Foundation.xcodeproj/project.pbxproj
> ./TestFoundation/TestNSFileHandle.swift
> ./TestFoundation/TestNSNotificationCenter.swift
> ./TestFoundation/TestNSRunLoop.swift
> ./TestFoundation/TestNSTimer.swift
> 
> None appear to have a shebang at the top to indicate that they are runnable 
> using the swift runtime.
> 
> Alex
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

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

[Philippe Hausler via swift-corelibs-dev]

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 the overlay is the implementation of 
subclassers.

Lets say you have a NSScanner subclass (I am dubious on how common this is but 
it is a decent example).

If we were to add a refinement for swift of scanString the problem would be 
that refinement would not be called as expected by subclassers;

lets say we refine via overlay to:

class Scanner : NSObject {
…
func scanString(_ string: String, into result: inout String?) -> Bool
// which hides this NS_REFINED_FOR_SWIFT as:
func __scanString(_ string: String, into result: 
AutoreleasingUnsafeMutablePointer?) -> Bool
…

}

class MyScanner : Scanner {
override func scanString(_ string: String, into result: inout String?) -> Bool 
{ … }
}

when a MyScanner is passed into an objective-c API calling the method 
-[NSScanner scanString:intoString:] will invoke the __scanString swift method 
instead of the override of scanString (effectively making the override final).

This presents a big issue with NSFormatter subclasses; which are arguably more 
common to be subclassed than Scanner. So the funnel APIs of

func getObjectValue(_ obj: AutoreleasingUnsafeMutablePointer?, for 
string: String, errorDescription error: 
AutoreleasingUnsafeMutablePointer?) -> Bool

probably should be written as:

func getObjectValue(_ obj: inout Any?, for string: String, errorDescription 
error: inout String?) -> Bool

or better yet:
class Formatter : NSObject {
...
func getObjectValue(_ obj: inout Subject?, for string: String, errorDescription 
error: inout String?) -> Bool
...
}

Shy of re-implementing these classes all in swift it would be difficult with 
the current importing mechanisms to correct this problem. Ideally I think we 
should have some mechanism to annotate in, out, and inout parameters so that 
the intent of the API is properly exposed as well as being more swift type 
friendly.

One thought is that we could re-use the distributed object annotations for 
parameters as type annotations to infer to the compiler on the proper semantics 
of how to handle the parameters. 

e.g.

- (BOOL)scanString:(NSString *)string intoString:(out NSString * _Nullable * 
_Nullable)result;

could infer to the compiler that the parameter result with the label of into 
would mean that it is the responsibility of this method to populate a value and 
similarly to error cases the boolean value determines that the populated value 
is actually set (else it is nil)
* if out is not an option then we could still interpret inout and out as 
swift’s inout.

If this were the case it would import as:

func scanString(_ string: String, into result: out String?) -> Bool

this would mean that usage could then be

let str: String?
if myScanner.scanString(“foo”, into: &str) {
}

Overall this would be safer because the variable str would be protected 
idiomatically from any further mutation past the initialization via the method 
scanString. It would also be potentially more efficient since it would could 
avoid autoreleasing an object. It would be valid for subclassing in that the 
method could be called by objc in a reasonable manner. And as a nice bonus the 
compiler could know about the out parameter’s optional value inside of the if 
guard scope (similar to guard/let, but that is perhaps icing on the cake if 
that would work).

tl;dr - I am of the opinion that most of Foundation’s APIs that are imported as 
AUMP are not exactly “intended” to be that and probably would be better off as 
something else.

> On Dec 5, 2016, at 10:55 AM, Oliver Drobnik via swift-corelibs-dev 
>  wrote:
> 
> Hello,
> 
> This is a repeat of an earlier post where I did not get a single response... 
> might have fallen through the cracks...
> 
> 
> 
> Earlier I posted this proposal to the Swift Evolution Mailing list. Then I 
> looked at the NSScanner implementation in core libs and found experimental 
> API using the return value to for returning the scanned results. See my 
> comments on that below:
> 
> 
> —
> 
> Working on a function for Foundation’s Scanner I stumbled on this LLVM crash: 
> https://bugs.swift.org/browse/SR-3295 
> 
> This got me thinking about a workaround and I would like to prose this:
> 
> When importing Foundation into Swift 3, all 
> 
> AutoreleasingUnsafeMutablePointer?
> 
> should instead be exposed as simple:
> 
> inout T?
> 
> e.g.
> 
> open func scanString(_ string: String, into result: 
> AutoreleasingUnsafeMutablePointer?) -> Bool
> 
> would become
> 
> open func scanString(_ string: String, into result: inout String?) -> Bool
> 
> 
> The call would stay exactly the same for normal use cases where you specify a 
> receiving variable:
> 
> var string: String?
> scanStr

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

[Philippe Hausler via swift-corelibs-dev]

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 they belong 
in something above Foundation. 

I don’t know of any linux variants off hand that don’t have /proc, but it might 
be interesting to somehow detect if that is truly a procfs element. I think it 
would perhaps be a failure if just the path /proc is special cased; Android, 
Solaris and Plan9 also share this same concept iirc (there are likely others).

> On Jan 12, 2017, at 11:40 AM, Carl Brown1 via swift-corelibs-dev 
>  wrote:
> 
> Hi,
> 
> I run the Austin Swift meetup group, and a question came up about the /proc 
> filesystem on Linux:
> 
> The question involved the inability to get any useful information from 
> Data(contentsOf: URL(fileURLWithPath: "/proc/sys/fs/file-max")).
> 
> It turns out that Data(contentsOf:) does a stat() on the inode of the file 
> you give it, and then runs alloc()/read() for the specified number of bytes. 
> This works fine on normal files on normal file systems. But all the files in 
> /proc have a 0 length specified by their inodes, and you have to actually 
> read them until EOF to find out how much is there.
> 
> So the question is: Is that something the *Programmer* should be responsible 
> for knowing, or should *Foundation* be responsible for handling that 
> correctly?
> 
> I can see a case that we'd want to avoid embedding things this OS-specific in 
> Foundation, but on the other hand, I know that this is very confusing for 
> Darwin developers moving to Linux and expecting Data(contentsOf:) to "Just 
> work."
> 
> So I thought I'd ask the community and see if there was a consensus.
> 
> Thanks,
> 
> -Carl
> 
> -- 
> Carl Brown
> Swift@IBM
> carl.bro...@ibm.com
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

Re: [swift-corelibs-dev] Asynchronous Operations

[Philippe Hausler via swift-corelibs-dev]

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

So perhaps you misunderstood my comment? What are you meaning by asynchronous 
operation? Technically all operations running in a queue are “asynchronous” on 
Darwin or on Linux. 

My commentary was about the cases where main finishes execution and the 
operation is not finished.

The subclassers of Operation would need to somehow notify the super-class that 
the operation is finished. And we would need to have a mechanism to understand 
if the subclasser is overriding main or start (or both?!)

> 
> Might it be acceptable to add extra temporary public API to enable this?

There is never a thing as temporary API - it haunts us for ever ;)

I think it would be better to advocate a sound design pattern that would 
facilitate proper implementations on all platforms instead… Perhaps like; how 
does one properly use run loops in the context of Operation or dispatch. Often 
that is a suitable way to make things that act asynchronously without consuming 
another thread/queue.

> 
> Many thanks,
> 
> -- 
> Ian Partridge
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

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

[Philippe Hausler via swift-corelibs-dev]

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://bugs.swift.org/browse/SR-2485
> https://bugs.swift.org/browse/SR-2462
> 
> I haven’t seen this in a while - are you able to try running on Swift 3.1 or 
> 3.0.2?
> Your code seems to work on the IBM Sandbox with 3.0.2 but not 3.0.1.
> You could also try replacing every 'let’ with ‘var’ but that might not be the 
> right solution :-)
> 
> Regards,
> Will Stanton
> 
>> On Jan 25, 2017, at 5:04 PM, Dennis Schafroth via swift-users 
>>  wrote:
>> 
>> Hi
>> 
>> Trying to do some simple date parsing from syslog format (“Jan 25 20:21:22”) 
>> into Date. Seem to work once but crashes on second call
>> 
>> 
>> func dateConv(_ dateString: String) -> Date? {
>>  let dateFormatter = DateFormatter()
>>  dateFormatter.dateFormat = "MMM dd HH:mm"
>>  dateFormatter.locale = Locale(identifier: "da_DK_POSIX")
>>  if let date = dateFormatter.date(from: dateString) {
>>print("Real date: \(date)" )
>>return date
>>  }
>>  return nil
>> }
>> 
>> var date  = dateConv("Jan 25 20:10")
>> var date2 = dateConv("Jan 25 20:11”)
>> 
>> # swift main.swift
>> Real date: 2000-01-25 19:10:00 +
>> 0  swift0x0334ab78 
>> llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
>> 1  swift0x03349346 llvm::sys::RunSignalHandlers() + 54
>> 2  swift0x0334b6aa
>> 3  libpthread.so.0  0x7fec92166890
>> 4  libswiftCore.so  0x7fec8e8f0735
>> 5  libFoundation.so 0x7fec8c0ab6ee
>> 6  libFoundation.so 0x7fec8bd7a222
>> 7  libFoundation.so 0x7fec8bd7c623
>> 8  libFoundation.so 0x7fec8bf0e873 
>> _TFC10Foundation6NSDateg11descriptionSS + 99
>> 9  libFoundation.so 0x7fec8c182829 
>> _TTWV10Foundation4Dates23CustomStringConvertibleS_FS1_g11descriptionSS + 57
>> 10 libswiftCore.so  0x7fec8e78c745 
>> _TFs15_print_unlockedu0_R_s16TextOutputStreamrFTxRq__T_ + 997
>> 
>> using swift 3.0.1. Am I doing something wrong? I seems to work on macOS.
>> 
>> cheers,
>> :-Dennis
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

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

[Philippe Hausler via swift-corelibs-dev]

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 which does exist in 3.0.2
> 
> :-Dennis
> 
>> On 26 Jan 2017, at 05.20, Philippe Hausler  wrote:
>> 
>> 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://bugs.swift.org/browse/SR-2485
>>> https://bugs.swift.org/browse/SR-2462
>>> 
>>> I haven’t seen this in a while - are you able to try running on Swift 3.1 
>>> or 3.0.2?
>>> Your code seems to work on the IBM Sandbox with 3.0.2 but not 3.0.1.
>>> You could also try replacing every 'let’ with ‘var’ but that might not be 
>>> the right solution :-)
>>> 
>>> Regards,
>>> Will Stanton
>>> 
 On Jan 25, 2017, at 5:04 PM, Dennis Schafroth via swift-users 
  wrote:
 
 Hi
 
 Trying to do some simple date parsing from syslog format (“Jan 25 
 20:21:22”) into Date. Seem to work once but crashes on second call
 
 
 func dateConv(_ dateString: String) -> Date? {
 let dateFormatter = DateFormatter()
 dateFormatter.dateFormat = "MMM dd HH:mm"
 dateFormatter.locale = Locale(identifier: "da_DK_POSIX")
 if let date = dateFormatter.date(from: dateString) {
  print("Real date: \(date)" )
  return date
 }
 return nil
 }
 
 var date  = dateConv("Jan 25 20:10")
 var date2 = dateConv("Jan 25 20:11”)
 
 # swift main.swift
 Real date: 2000-01-25 19:10:00 +
 0  swift0x0334ab78 
 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
 1  swift0x03349346 llvm::sys::RunSignalHandlers() + 54
 2  swift0x0334b6aa
 3  libpthread.so.0  0x7fec92166890
 4  libswiftCore.so  0x7fec8e8f0735
 5  libFoundation.so 0x7fec8c0ab6ee
 6  libFoundation.so 0x7fec8bd7a222
 7  libFoundation.so 0x7fec8bd7c623
 8  libFoundation.so 0x7fec8bf0e873 
 _TFC10Foundation6NSDateg11descriptionSS + 99
 9  libFoundation.so 0x7fec8c182829 
 _TTWV10Foundation4Dates23CustomStringConvertibleS_FS1_g11descriptionSS + 57
 10 libswiftCore.so  0x7fec8e78c745 
 _TFs15_print_unlockedu0_R_s16TextOutputStreamrFTxRq__T_ + 997
 
 using swift 3.0.1. Am I doing something wrong? I seems to work on macOS.
 
 cheers,
 :-Dennis
>>> 
>>> ___
>>> swift-corelibs-dev mailing list
>>> swift-corelibs-dev@swift.org
>>> https://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

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

[Philippe Hausler via swift-corelibs-dev]

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 thing makes so much 
> sense for us. Developing our tools in swift could be a huge benefit. I am 
> excited to get deeper into swift for linux. 
> 
> I build swift on Ubuntu successfully (without errors) from scratch with this 
> options:
> 
> ./utils/build-script --release --foundation --verbose-build 
> --build-stdlib-deployment-targets all -l -b -p --skip-test-linux 
> --build-swift-static-stdlib --build-swift-static-sdk-overlay --xctest -c
> 
> My goal is to have Foundation in static compiled binaries.
> As mentioned everything in the build process works fine, but the execution of 
> a simple script as shown below failed.
> 
> import Foundation
> 
> print("Hello Swift.")
> I get the following error:
> /bin/swiftc /home/hello.swift -o /home/hello 
> /home/hello.swift:1:8: error: no such module 'Foundation'
> How to build Swift with the current state of foundation? 
> Can you please give me a little kick into the right direction? The web is not 
> very useful in this early state, but i am really want to get into it. 
> 
> Thanks a lot, 
> Kris
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

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

[Philippe Hausler via swift-corelibs-dev]

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 
SwiftPM which might result in a synchronization issue of code, or a last-build 
result re-build of Foundation used in SwiftPM which seems like a pain when it 
comes to first time setup.

Foundation’s build environment is a bit tricky since it is not just plain C, we 
have assembly and some really funky linker tricks that might pose an issue. 
Also it might be a bit difficult to build CoreFoundation as it’s own target (as 
it stands now you can technically build CF without swift and use that 
independently on Linux - which elides the need to publish a separate CFLite).

>From previous build infrastructure efforts that I have undertaken; the general 
>consensus is that using SwiftPM would be nice but it doesn’t offer enough of a 
>compelling reason to switch and complicate the rest of the Swift build process 
>(which is already very complex).

Now the other alternative is that Foundation could be built with cmake. That 
has been something I have explored and it shows some promise. However as for 
fish to fry, it is a very small one. 

Now I think fixing the dirty file bits from the build script might be a good 
thing to fix even without changing the build infrastructure. I have tried to 
fix this problem a few times but it ends up getting really complex really 
quickly.

If you want to dive into the current build system or perhaps look at cmake let 
me know if there are things that I can help out to clarify.

P.S. what slack server are you discussing this on? I was un-aware of any slack 
servers setup for swift.

> On Jan 30, 2017, at 4:49 PM, Robert F Dickerson via swift-corelibs-dev 
>  wrote:
> 
> This has probably been discussed in the past, but wanted to revisit the idea 
> of using native Swift tools to build Foundation. I brought this up in the 
> Slack group, and it seemed to be warmly received- although probably still not 
> simple because of some cyclical dependency issues in the build process.
> 
> But, I think that there would be a lot of value in being able to build 
> Foundation (and CoreFoundation) only using SwiftPM, in other words, simply 
> with `swift build`. 
> 
> Now that SwiftPM is improving its ability to pass in compilation flags more 
> easily and C module compilation. I think that the project could be 
> restructured to make this work. What would be the obstacles for getting this 
> working?
> 
>  
> 
> 
> 
>  
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

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

[Philippe Hausler via swift-corelibs-dev]

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:18 PM, Jordan Rose via swift-dev  
> wrote:
> 
> Foundation folks, have you seen this before?
> 
> TestFoundation/TestNSAffineTransform.swift:187: error: 
> TestNSAffineTransform.test_Rotation_Radians : XCTAssertEqualWithAccuracy 
> failed: ("10.0") is not equal to ("-10.0") +/- ("0.001") - y (expected: 
> -10.0, was: 10.0): 
> 
> Jordan
> 
>> On Feb 20, 2017, at 12:05, no-re...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#2022]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/2022/ 
>> 
>> Project: oss-swift-incremental-RA-linux-ubuntu-16_10
>> Date of build:   Mon, 20 Feb 2017 11:47:26 -0800
>> Build duration:  17 min
>> Identified problems:
>> 
>> Compile Error: This build failed because of a compile error. Below is a list 
>> of all errors in the build log:
>> Indication 1 
>> 
>> Tests:
>> 
>> Name: Swift(linux-x86_64)
>> Failed: 0 test(s), Passed: 8993 test(s), Total: 8993 test(s)
>> Name: Swift-Unit
>> Failed: 0 test(s), Passed: 341 test(s), Total: 341 test(s)
>> 
>> Changes
>> 
>> Commit 042e6510c324c699b86e7a8d0d20068b2ee8feb4 by dgregor:
>> [AST] Drop ProtocolDecl's "inherited protocols" list.
>> 
>> edit: test/decl/class/circular_inheritance.swift
>> edit: lib/IRGen/GenProto.cpp
>> delete: 
>> validation-test/compiler_crashers/28599-false-should-have-found-context-by-now.swift
>> edit: include/swift/AST/Decl.h
>> edit: lib/Sema/ITCDecl.cpp
>> edit: lib/Sema/TypeCheckProtocol.cpp
>> edit: lib/IRGen/GenMeta.cpp
>> edit: test/decl/protocol/protocols.swift
>> edit: lib/Sema/TypeCheckDecl.cpp
>> edit: lib/AST/Type.cpp
>> edit: lib/AST/SubstitutionMap.cpp
>> edit: lib/Serialization/Deserialization.cpp
>> delete: 
>> validation-test/compiler_crashers/28604-isinheritedprotocolsvalid.swift
>> edit: lib/IRGen/GenArchetype.cpp
>> add: 
>> validation-test/compiler_crashers_fixed/28599-false-should-have-found-context-by-now.swift
>> edit: lib/AST/LookupVisibleDecls.cpp
>> edit: lib/ClangImporter/ImportDecl.cpp
>> edit: test/SILGen/objc_bridging_any.swift
>> edit: lib/IRGen/GenClass.cpp
>> edit: lib/Sema/TypeChecker.h
>> edit: lib/AST/Decl.cpp
>> edit: lib/Serialization/Serialization.cpp
>> edit: include/swift/SIL/SILWitnessVisitor.h
>> edit: lib/Sema/TypeCheckType.cpp
>> add: 
>> validation-test/compiler_crashers_fixed/28604-isinheritedprotocolsvalid.swift
>> edit: lib/PrintAsObjC/PrintAsObjC.cpp
>> edit: include/swift/Serialization/ModuleFormat.h
>> edit: lib/IRGen/Fulfillment.cpp
>> 
>> Commit 205303aa64579b40d20c8e052d24c46a87d3a552 by blangmuir:
>> Disable round_trip_stdlib.swift temporarily
>> 
>> edit: test/Syntax/round_trip_stdlib.swift
>> 
>> Commit cb5bc1fedf1da72e5cb25e529915cce941ad327d by mgottesman:
>> Disable opaque_values_silgen.swift with a resilient stdlib until I have
>> 
>> edit: test/SILGen/opaque_values_silgen.swift
>> 
>> Commit b50f044c3d646abfe2e3264369b9a9b616ff6886 by github:
>> Disable a part of the Syntax unit tests under no-asserts. (#7644)
>> 
>> edit: unittests/Syntax/TypeSyntaxTests.cpp
> 
> ___
> swift-dev mailing list
> swift-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

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

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

[Philippe Hausler via swift-corelibs-dev]

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 method that takes a 
CFStringRef can take a NSString.

The reasoning for this behavior is to match the behavior of the objective-c 
version of Foundation.

> On Feb 21, 2017, at 10:20 AM, Nethra Ravindran via swift-corelibs-dev 
>  wrote:
> 
> For example  NSURLComponents is not CFBridgeable.
> 
> - Nethra Ravindran
> 
> On Tue, Feb 21, 2017 at 3:01 PM, Alex Blewitt  > wrote:
> Do you have a couple of examples that you're referring to?
> 
> Alex
> 
>> On 21 Feb 2017, at 09:25, Nethra Ravindran via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> Hi everyone,
>> 
>> To be more precise, I would like to know why few classes are not 
>> CFBridgeable.
>> 
>> Thank you.
>> 
>> - Nethra Ravindran
>> 
>> On Tue, Feb 21, 2017 at 2:20 PM, Nethra Ravindran 
>> mailto:nethraravindra...@gmail.com>> wrote:
>> Hi,
>> 
>> I see that some classes are bridgeable and some are not. It would be great 
>> if someone can explain why few classes are not bridgeable.
>> 
>> Thank you!
>> 
>> - Nethra Ravindran
>> 
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org 
>> https://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

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

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

[Philippe Hausler via swift-corelibs-dev]

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.04 LTS system.
> 
> I cloned the main swift repo and all of it's dependencies via ssh
> ./swift/utils/update-checkout --clone-with-ssh
> and after running (taken from instructions from the Foundation site):
> 
> swift/utils/build-script --xctest --foundation -t
> 
> I get the following error:
> 
> + make build-tests
> /bin/bash ../libtool  --tag=CC   --mode=link 
> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/llvm-linux-x86_64/bin/clang
>  -Wall -Wno-deprecated-declarations  -fblocks 
> -I/home/mohit/Documents/swift-source/swift-corelibs-libdispatch/src/BlocksRuntime
>  -isystem /usr/include/bsd -DLIBBSD_OVERLAY   -g -O0 -rpath 
> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
>   -o dispatch_apply dispatch_apply.o libbsdtests.la ../src/libdispatch.la  
> -lbsd 
> -L/home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
>  -lswiftCore -lswiftSwiftOnoneSupport -lpthread 
> libtool: link: 
> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/llvm-linux-x86_64/bin/clang
>  -Wall -Wno-deprecated-declarations -fblocks 
> -I/home/mohit/Documents/swift-source/swift-corelibs-libdispatch/src/BlocksRuntime
>  -isystem /usr/include/bsd -DLIBBSD_OVERLAY -g -O0 -o .libs/dispatch_apply 
> dispatch_apply.o  ./.libs/libbsdtests.a ../src/.libs/libdispatch.so -lbsd 
> -L/home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
>  -lswiftCore -lswiftSwiftOnoneSupport -lpthread -Wl,-rpath 
> -Wl,//usr/lib/swift/linux -Wl,-rpath 
> -Wl,/home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64/libswiftCore.so:
>  undefined reference to `objc_release'
> clang-4.0: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> Makefile:1123: recipe for target 'dispatch_apply' failed
> make: *** [dispatch_apply] Error 1
> swift/utils/build-script: fatal error: command terminated with a non-zero 
> exit status 2, aborting
> 
> Looks like there is some undefined reference for objc_release in libswiftCore.
> 
> From the looks of the message it looks like swift was actually built but it's 
> just that test cases weren't built. On this hunch, I went into my 
> swift-corelibs-foundation folder and tried to execute:
> 
> ninja
> 
> Which tells me:
> 
> ninja: error: loading 'build.ninja': No such file or directory
> 
> Given my lack of experience here, I'm not quite sure how to go about 
> resolving these issues.
> 
> Could somebody help me out here please.
> 
> Thanks,
> 
> Mohit
> 
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

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

[Philippe Hausler via swift-corelibs-dev]

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 idea, but there are some additional things to consider. In 
> some cases, methods are partially unimplemented (with edge cases, or at least 
> less common cases remaining unfinished). The availability macro can’t reflect 
> that status.
> 
> In other cases, we want to partially implement one function but still call 
> through to an unimplemented function. The entire call may fail with the 
> assert, but at least we have part of the implementation in place.
> 
> - Tony
> 
>> On May 10, 2017, at 4:01 PM, Sergej Jaskiewicz via swift-corelibs-dev 
>>  wrote:
>> 
>> I was wondering why cannot we just mark all the methods/properties/functions 
>> in Swift Foundation that are NSUnimplemented or call a subroutine that is 
>> NSUnimplemented like this:
>> 
>> @available(*, unavailable, message: “foo is not implemented yet”)
>> func foo() { NSUnimplemented() }
>> 
>> In this case we can be sure at compile time that we don’t use code that will 
>> definitely crash.
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org
>> https://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

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

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

[Philippe Hausler via swift-corelibs-dev]

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 swift-corelibs-dev 
>  wrote:
> 
> Well, here is what I got in IBM Swift Sandbox. 
> http://swift.sandbox.bluemix.net/#/repl/5913a8594ee0cd258050b2fd 
> 
> If I got you right, it works.
> 
> Yes, partially implemented functions is a problem. But we definitely could 
> mark the ones that are not implemented at all and not being called.
> 
>> On 11 May 2017, at 02:43, Philippe Hausler > > wrote:
>> 
>> 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 
>>> mailto:swift-corelibs-dev@swift.org>> wrote:
>>> 
>>> Hi Sergej,
>>> 
>>> This is a good idea, but there are some additional things to consider. In 
>>> some cases, methods are partially unimplemented (with edge cases, or at 
>>> least less common cases remaining unfinished). The availability macro can’t 
>>> reflect that status.
>>> 
>>> In other cases, we want to partially implement one function but still call 
>>> through to an unimplemented function. The entire call may fail with the 
>>> assert, but at least we have part of the implementation in place.
>>> 
>>> - Tony
>>> 
 On May 10, 2017, at 4:01 PM, Sergej Jaskiewicz via swift-corelibs-dev 
 mailto:swift-corelibs-dev@swift.org>> wrote:
 
 I was wondering why cannot we just mark all the 
 methods/properties/functions in Swift Foundation that are NSUnimplemented 
 or call a subroutine that is NSUnimplemented like this:
 
 @available(*, unavailable, message: “foo is not implemented yet”)
 func foo() { NSUnimplemented() }
 
 In this case we can be sure at compile time that we don’t use code that 
 will definitely crash.
 ___
 swift-corelibs-dev mailing list
 swift-corelibs-dev@swift.org 
 https://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
>> 
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

Re: [swift-corelibs-dev] CFStringTokenizer

[Philippe Hausler via swift-corelibs-dev]

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 ( 
> enumerateSubstrings(in:using:) ), and I noticed that there is no 
> implementation of CFStringTokenizer in the provided CoreFoundation.
> 
> Is this meant to be the case?
> 
> If so, I'll go ahead and implement it in pure Swift
> 
> 
> Andy
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

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

[Philippe Hausler via swift-corelibs-dev]

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:
> > 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 mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSRegularExpression performance

[Philippe Hausler via swift-corelibs-dev]

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 have a 
“compiled" engine from ICU to be made each time.

2) Last time I looked at this specific sample the cost is bridging strings back 
and forth between NSString and String. In swift 4 we have made some 
improvements for bridging but I am not certain if any specifically apply to 
this context (when run on Darwin). For linux builds we are missing the 
referencing string variants so this can cause some severe performance hits when 
copying large strings. 

3) I would avoid utf8.count in this case for measuring perf (it is probably 
going to be slow for large files)

4) per your commentary on parallelized cases, I am not certain on why that is 
slower. Presuming the source data is large (order of megabytes) it should not 
contend on the access to the regular expression. So I find this odd that it is 
not better to utilize all cores of your machine.

Now I think with some tuning we could probably get swift-corelibs-foundation to 
have some faster paths here. As well as fixing some missteps in the code listed 
for the two tests.

I have some branches that I have been working on for swift-corelibs-foundation 
that might reduce some allocation times and improve string conversions back and 
forth from reference types to structural types but those are not fully baked 
yet. Partially you have to realize that swift-corelibs-foundation is still 
quite new in comparison to the Foundation on Darwin. So we have been focusing 
on getting API coverage to a closer point than per-se performance work. Granted 
however pull requests are welcomed in both cases ;)

> On Jun 29, 2017, at 10:15 AM, Francois Green via swift-corelibs-dev 
>  wrote:
> 
> I’m uncertain if I’m using the correct forum, but I asked this question on 
> the user list a few months back and no one responded.  The 
> NSRegularExpression library seems to perform poorly and I’m wondering if this 
> is a performance bug or is it being used improperly?  I’ve added links to two 
> algorithms from the Benchmark Game project that seem quite slow when compared 
> to other languages.  While I understand that direct comparisons are not 
> possible, this one benchmark really stands out. 
> 
> http://benchmarksgame.alioth.debian.org/u64q/program.php?test=regexredux&lang=swift&id=2
> 
> http://benchmarksgame.alioth.debian.org/u64q/program.php?test=regexredux&lang=swift&id=1
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

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

[Philippe Hausler via swift-corelibs-dev]

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've found what I believe is a bug. Though I'm unclear if the bug is in
>> Swift 3.1 or Swift 3.2/4.0. All I can say for sure is the behavior is
>> quite drastically different between the two.
>> 
>> For the code below (and attached):
>> 
>>   import Cocoa
>> 
>>   var data = Data(bytes: [0x50, 0x4B, 0x01, 0x02, 0x41, 0x61])
>>   data.removeFirst(4)
>>   let base64 = data.base64EncodedString()
>>   let str = String(bytes: data[0..<2], encoding: .utf8)!
>>   print("Base64: \(base64), String: \(str)")
>> 
>> If I compile and run that with the Swift included in Xcode 8.3.3 (e.g.,
>> swift ./data-bug.swift) it outputs: Base64: QWE=, String: Aa. Which is
>> what I expect.
>> 
>> With the Swift that is included with Xcode 9.0 beta 6 (9M214v) (e.g.,
>> swift -swift-version 3 ./data-bug.swift). It performs an illegal
>> hardware instruction and crashes. It also does this if I use use the
>> version 4 of the compiler.
>> 
>> Is this a bug? If so where is the bug? Was this always meant to not work
>> and Swift 3.1 just happened to work or is there now an issue in the
>> Swift 3.2 implementation?
> 
> I have not engaged my brain with the particulars of the rest of the email, 
> but high level question: does this happen without optimization? Or does it 
> happen only with optimization?
> 
> Michael
> 
>> ___
>> swift-dev mailing list
>> swift-...@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-dev
> 
> ___
> swift-dev mailing list
> swift-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

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

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

[Philippe Hausler via swift-corelibs-dev]

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 + 2)], 
encoding: .utf8)!

> On Aug 24, 2017, at 11:07 AM, Philippe Hausler  wrote:
> 
> 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've found what I believe is a bug. Though I'm unclear if the bug is in
>>> Swift 3.1 or Swift 3.2/4.0. All I can say for sure is the behavior is
>>> quite drastically different between the two.
>>> 
>>> For the code below (and attached):
>>> 
>>>  import Cocoa
>>> 
>>>  var data = Data(bytes: [0x50, 0x4B, 0x01, 0x02, 0x41, 0x61])
>>>  data.removeFirst(4)
>>>  let base64 = data.base64EncodedString()
>>>  let str = String(bytes: data[0..<2], encoding: .utf8)!
>>>  print("Base64: \(base64), String: \(str)")
>>> 
>>> If I compile and run that with the Swift included in Xcode 8.3.3 (e.g.,
>>> swift ./data-bug.swift) it outputs: Base64: QWE=, String: Aa. Which is
>>> what I expect.
>>> 
>>> With the Swift that is included with Xcode 9.0 beta 6 (9M214v) (e.g.,
>>> swift -swift-version 3 ./data-bug.swift). It performs an illegal
>>> hardware instruction and crashes. It also does this if I use use the
>>> version 4 of the compiler.
>>> 
>>> Is this a bug? If so where is the bug? Was this always meant to not work
>>> and Swift 3.1 just happened to work or is there now an issue in the
>>> Swift 3.2 implementation?
>> 
>> I have not engaged my brain with the particulars of the rest of the email, 
>> but high level question: does this happen without optimization? Or does it 
>> happen only with optimization?
>> 
>> Michael
>> 
>>> ___
>>> swift-dev mailing list
>>> swift-...@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-dev
>> 
>> ___
>> swift-dev mailing list
>> swift-...@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-dev
> 

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

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

[Philippe Hausler via swift-corelibs-dev]

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 is it behaving that way?
> 
> I updated my earlier script (attached) and added 2 things.
> 
>   1. print("Start: \(data.startIndex), End: \(data.endIndex), Count: 
> \(data.count)") after the data.removeFirst(4).
>   2. The startIndex offset you suggested.
> 
> It no longer crashes. Hooray!
> 
> Swift 3.1:
> 
> Start: 0, End: 2, Count: 2
> Base64: QWE=, String: Aa
> 
> Swift 3.2:
> 
> Start: 4, End: 6, Count: 2
> Base64: QWE=, String: Aa
> 
> Oh wait. Woah. That's a really subtle change that has some very real 
> consequences.
> 
> Is this expected and/or documented? Because I certainly would not have 
> expected that drastic of a change. I'll obviously need to go read a lot more 
> of the changes between Swift 3.1 and Swift 3.2 if these sorts of changes are 
> in scope.
> 
> 
>> On Thu, Aug 24, 2017, at 02:10 PM, Philippe Hausler wrote:
>> 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 + 2)], 
>> encoding: .utf8)!
>> 
>>> On Aug 24, 2017, at 11:07 AM, Philippe Hausler  wrote:
>>> 
>>> 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've found what I believe is a bug. Though I'm unclear if the bug is in
> Swift 3.1 or Swift 3.2/4.0. All I can say for sure is the behavior is
> quite drastically different between the two.
> 
> For the code below (and attached):
> 
>  import Cocoa
> 
>  var data = Data(bytes: [0x50, 0x4B, 0x01, 0x02, 0x41, 0x61])
>  data.removeFirst(4)
>  let base64 = data.base64EncodedString()
>  let str = String(bytes: data[0..<2], encoding: .utf8)!
>  print("Base64: \(base64), String: \(str)")
> 
> If I compile and run that with the Swift included in Xcode 8.3.3 (e.g.,
> swift ./data-bug.swift) it outputs: Base64: QWE=, String: Aa. Which is
> what I expect.
> 
> With the Swift that is included with Xcode 9.0 beta 6 (9M214v) (e.g.,
> swift -swift-version 3 ./data-bug.swift). It performs an illegal
> hardware instruction and crashes. It also does this if I use use the
> version 4 of the compiler.
> 
> Is this a bug? If so where is the bug? Was this always meant to not work
> and Swift 3.1 just happened to work or is there now an issue in the
> Swift 3.2 implementation?
 
 I have not engaged my brain with the particulars of the rest of the email, 
 but high level question: does this happen without optimization? Or does it 
 happen only with optimization?
 
 Michael
 
> ___
> swift-dev mailing list
> swift-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
 
 ___
 swift-dev mailing list
 swift-...@swift.org
 https://lists.swift.org/mailman/listinfo/swift-dev
> 
> 
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

[Philippe Hausler via swift-corelibs-dev]

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 
 

There are a number of areas to consider when reviewing this (and I would 
sincerely appreciate any extra eyes on this pull request). Particularly any 
platforms other than macOS a Ubuntu should be carefully reviewed and tried out 
to ensure it works properly. Also any architectures other than x86_64 should be 
tested out as well (particularly any big endian architectures). 

One extra change included was a small fix to the Xcode project that should 
speed up local builds considerably.

Please let me know if there are any concerns.

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

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

[Philippe Hausler via swift-corelibs-dev]

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 the 
> "Constant strings cannot be deallocated” fatal error thrown in 
> NSCFString.swift, as seen here:
> 
> https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSCFString.swift#L118
>  
> 
> 
> The test that does it is here:
> 
> https://github.com/pointfreeco/swift-web/blob/5f19a0264be5d369ee0438da8599e3c478a6573b/Tests/ApplicativeRouterTests/SyntaxRouterTests.swift#L88-L93
>  
> 
> 
> Now there’s a lot to unravel here and I haven’t been able to quite isolate 
> it, but I thought perhaps someone here might know how that could path could 
> even be executed.
> 
> Thanks for any help!
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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

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

[Philippe Hausler via swift-corelibs-dev]

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-corelibs-dev 
>  wrote:
> 
> Hey Tony,
> 
> We were able to fix our crashes by avoiding our uses of `URLQueryItem`s. In 
> one place I had to completely remove the use of `URLQueryItem`:
> 
> https://github.com/pointfreeco/swift-web/pull/79/files#diff-293b73a926ba418bd9511ef735fc947cL147
> 
> And in another my colleague Stephen Celis discovered that duplicate keys in a 
> query string can cause this to crash:
> 
> https://github.com/pointfreeco/swift-web/pull/80
> 
> He was able to come up with a minimal test case to demonstrate this:
> 
> https://github.com/pointfreeco/swift-web/commit/cfa9b519a829f1c1627620521326f0877c2d023a
> 
> And you can see the failure in this Travis CI report:
> 
> https://travis-ci.org/pointfreeco/swift-web/builds/309316418
> 
> At the bottom you’ll find:
> 
> ```fatal error: Constant strings cannot be deallocated: file 
> Foundation/NSCFString.swift, line 118```
> 
> So definitely seems to be in that area!
> 
> Now, as far as rebuilding swift-corelibs-foundation, I’m down to try but I 
> dont really know much about how to do that. With some instructions I could 
> give it a shot.
> 
> Thanks for the help!
> 
> 
> 
> 
>> On Wed, Nov 29, 2017 at 5:59 PM Tony Parker  wrote:
>> I see a couple of places that are suspicious there:
>> 
>> Description:
>> 
>> https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/URL.subproj/CFURLComponents.c#L66
>> 
>> And the nameString / valueString constants in the copy query items function:
>> 
>> https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/URL.subproj/CFURLComponents.c#L1057
>> https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/URL.subproj/CFURLComponents.c#L1079
>> https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/URL.subproj/CFURLComponents.c#L1104
>> https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/URL.subproj/CFURLComponents.c#L1134
>> https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/URL.subproj/CFURLComponents.c#L1158
>> 
>> Do you have the ability to re-build swift-corelibs-foundation and run a 
>> test? I suspect if you replace those with CFRetain(CFSTR(…)) then it will 
>> fix your crash.
>> 
>> - Tony
>> 
>> 
>>> On Nov 29, 2017, at 2:06 PM, Brandon Williams  wrote:
>>> 
>>> Thanks for the info!
>>> 
>>> FWIW, most of the places I have encountered this so far have made use of 
>>> `URLComponents`, and have even been able to eliminate the crash by getting 
>>> rid of that code in a few places. The other JIRA bug on this topic also 
>>> mentions URLComponents in their repro case. Seems to be the culprit.
>>> 
>>> Also worth noting that in the above cases dealing with URLComponents the 
>>> crash only happens in DEBUG compilations, not RELEASE.
>>> 
>>> However, I do have another one of these crashes that _does_ happen on 
>>> RELEASE builds that I haven’t yet been able to reduce.
>>> 
>>> 
 On Wed, Nov 29, 2017 at 4:43 PM Tony Parker  
 wrote:
 Hi Brandon,
 
 This is probably a bug in the CoreFoundation C sources part of 
 swift-corelibs-foundation. Unlike Darwin platforms, we can’t make the 
 CFSTR(“”) macro produce a CFStringRef that cannot be overreleased. 
 Probably there is a constant string returned from CF function, then the 
 Swift runtime assumes it can release it, and bam we wind up with an 
 overrelease.
 
 We’ll have to track down which function is getting called, which probably 
 just requires stepping through that test case with a debugger…
 
 - Tony
> On Nov 29, 2017, at 1:34 PM, Brandon Williams via swift-corelibs-dev 
>  wrote:
> 
 
> Hello all!
> 
> We’ve been encountering this runtime error quite a bit recently, and we 
> have no idea why. We’ve filed a bug and there’s one other on JIRA related 
> to this, but both without any comments:
> 
> https://bugs.swift.org/browse/SR-6422
> https://bugs.swift.org/browse/SR-6398
> 
> We’re curious if others are aware of this and or has more info? Is it a 
> red herring for some other problem?
> 
> Any info would be helpful!
 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://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
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swif

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

[Philippe Hausler via swift-corelibs-dev]

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 to get them.

Things for process execution that might be interesting to consider:
Pipes from one process to another
Safe shorthand’s to a command + arguments
Output collection to Data 
More customizable streaming in general (e.g. passing fds other than input 
output or error)
And I think in my book the biggest part is crafting a way to make the 
construction of tasks safe by default and not need exceptions or fatal errors 
(I have played around with this and I really think it can be done with minimal 
throwing and much better error reporting of failures).

A composeable interface imho would be really nice and i think we could even 
one-up python.

Argument parsing is another key part that swift does not do and Foundation does 
not do either but SwiftPM has a good start: again with some refinements I think 
it could be transmuted into something general purpose (plus there are some 
interesting open source projects out there)

The one other thing that would be immensely useful is a more integrated and 
faster regex but that probably should have language support for precompiled 
regexes and type-checked syntax for them.

Those three areas I think could improve scripting for swift.

Perhaps as a next step we should collect the needs from SwiftPM so that we can 
provide Process for them instead of duplication of efforts, and file some bugs 
for enhancement requests.

Sent from my iPhone

> On Dec 1, 2017, at 4:26 PM, Daniel Dunbar via swift-corelibs-dev 
>  wrote:
> 
> 
>> On Dec 1, 2017, at 6:28 AM, Ian Partridge via swift-corelibs-dev 
>>  wrote:
>> 
>> 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.
> 
> Just to be clear, the APIs in that product are developed for SwiftPM’s own 
> use. They are definitely useful to us, but they are also unstable and 
> unsupported… you are welcome to reuse them if you find them helpful, but they 
> are very much designed specifically for SwiftPM and may change unexpectedly. 
> Use at your own risk!
> 
> - Daniel
> 
>> 
>> 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] Strange behavior the same code fails when building a Cocoa CLI and succeeds in Swift-corelibs-foundation context.

[Philippe Hausler via swift-corelibs-dev]

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. 
Comments inline...

> On Dec 18, 2017, at 8:45 AM, Benoit Pereira da silva via swift-corelibs-dev 
>  wrote:
> 
> Dear All,
> 
> 
> I do encounter a very strange Issue.
> 
> I have been adding a test to 
> `swift-corelibs-foundation/testJSONSerialization.swift`
> This test succeed within swift-corelibs-foundation test, but fails when 
> repackaged to a Cocoa CLI app.
> 
> The  swift-corelibs-foundation test : 
> 
> 
> func test_serializeFloatingPointWithANonDotDecimalSeparatorLocale() {
> // We use a locale that is using "," as decimal separator.
> setlocale(LC_ALL,"fr_FR”)

This change will set the locale globally for the rest of the process, you 
probably want to make sure to reset the locale back to it’s original state.

> 
> let dictionary = ["decimalValue":1.1]
> do{
> let data = try JSONSerialization.data(withJSONObject: dictionary)
> if let json =  String(data:data, encoding:.utf8){
> XCTAssert(!json.contains(","), "Expected result: 
> \"{\"decimalValue\":1.1001}\" found: \"\(json)\"" )
> }else{
> XCTFail("Failed during string encoding")
> }
> }catch{
> XCTFail("Failed during serialization")
> }
> }
> 
> 
> The simple CLI code that proves the bug 
> (https://bugs.swift.org/browse/SR-6631 
> )
> 
> //
> //  main.swift
> //  doubleEncoding
> //
> //  Created by Benoit Pereira da silva on 02/12/2017.
> //  Copyright © 2017 Pereira da Silva. All rights reserved.
> //
> 
> import Foundation
> 
> // Let's set to french
> setlocale(LC_ALL,"fr_FR")
> 
> do{
> let dictionary = ["decimalValue":1.1]
> let data = try JSONSerialization.data(withJSONObject: dictionary)
> if let json =  String(data:data, encoding:.utf8){
> // the result is : "{"decimalValue":1,1001}"
> // The decimal separator should not be "," but "."
> print(json)
> }
> }catch{
> print("\(error)")
> }
> 
> 
> 
> Any idea ?
> I do use Toolchain: Swift Development Snapshot 2017-12-17 (a)

Building a CLI tool will use the objective-c Foundation in the system so that 
wont use your freshly built swift-corelibs-foundation. So that means we have a 
bug in the objc side if this is actually happening on Darwin (which is a 
completely different issue…) That should be a radar against Foundation and I 
definitely think that may very well be a bug… 

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

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

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

[Philippe Hausler via swift-corelibs-dev]

> 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 your tests and changes.
>> There are a few issues however with your test that might be worth 
>> considering. Comments inline…
> … 
>> Building a CLI tool will use the objective-c Foundation in the system so 
>> that wont use your freshly built swift-corelibs-foundation. So that means we 
>> have a bug in the objc side if this is actually happening on Darwin (which 
>> is a completely different issue…) That should be a radar against Foundation 
>> and I definitely think that may very well be a bug… 
> 
> 
> I have been filling a radar 
> https://bugreport.apple.com/web/?problemID=36107307 
> 
Thanks for taking the time to file that! I will make sure that gets to the 
right owner.

> I do think you are right it's a bug in the Objc Foundation… and trying to 
> solve it in "swift-corelibs-foundation" was a mistake :) 
> 
> 
>>> setlocale(LC_ALL,"fr_FR”)
>> 
>> This change will set the locale globally for the rest of the process, you 
>> probably want to make sure to reset the locale back to it’s original state.
> 
> 
> Setting the locale globally was just a temporary test.
> 
> But i do think that it triggers a serious question:  Should all your tests be 
> ran on all the available locales? 
> You will certainly find a smarter solution …

I think it is sensible to iterate through a key list of known locales that have 
certain characteristics, such as using the , as a decimal separator or « for 
quote begin etc (not to pick on French but it is the one I know better than 
other punctuation differentials from English).

There are probably key areas that are worth doing this to and others that 
probably do not matter so much. e.g. you don’t really need to test locale 
variations with NotificationCenter for example whereas NumberFormatter or 
JSONSerialization may be places that we want to test a few locales by 
subclassing the unit tests and in setup change the locale and teardown reset it.

> 
> Benoit
> 
> 
> 

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