Re: [swift-corelibs-dev] Packaging Everything for Testing

[Dmitri Gribenko via swift-corelibs-dev]

On Fri, Dec 11, 2015 at 7:13 PM, Joseph Bell via swift-corelibs-dev <
swift-corelibs-dev@swift.org> wrote:

> Howdy,
>
> I have been using the SNAPSHOT .tar.gz to write some basic Swift
> applications, and now wanted to turn my attention to compiling with the
> latest coming out of the corelibs-foundation library.  I understand that to
> do so I need to download clang, llvm, swift, and swift-corelibs-foundation
> and use the swift/utils/build-script to build everything.
>
> I can do that successfully, but now I have a build/Ninja-ReleaseAssert
> directory littered with all manner of artifacts that it's not clear how to
> pull together and run with it.  Is there either a packaging tool (creating
> the filesystem layout seen in the SNAPSHOT) or sets of exports one uses to
> run with a hand-built swift and corelibs?
>

Here's how the official packages are built:

./utils/build-script --preset=buildbot_linux_1404
install_destdir=/tmp/install installable_package=/tmp/swift.tar.gz

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
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

[David P Grove via swift-corelibs-dev]

Thanks Pierre.

We made a little progress on getting tests to compile this afternoon:
https://github.com/dgrove-oss/swift-corelibs-libdispatch/tree/fixtests

Absolutely not ready for a pull request, but mentioning it in case anyone
else was starting on the same task and wanted to collaborate.

--dave



From:   Pierre Habouzit 
To: David P Grove/Watson/IBM@IBMUS
Cc: Dzianis Fedarenka ,
swift-corelibs-dev@swift.org
Date:   12/11/2015 12:59 PM
Subject:Re: [swift-corelibs-dev] libdispatch build issue
Sent by:phabou...@apple.com




  On Dec 11, 2015, at 8:27 AM, David P Grove via swift-corelibs-dev <
  swift-corelibs-dev@swift.org> 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.



We do have an internal test-suite that we can’t share because it rely on
internal Apple infrastructure. I haven’t closed the loop with Daniel
completely on this but our position I think is that these should be made
portable even if that means dropping anything mach related stuff by hiding
it behind a #if __APPLE__ or similar.

-Pierre


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

Re: [swift-corelibs-dev] NSDecimal & NSDecimalNumber

[Brent Royal-Gordon via swift-corelibs-dev]

> This may be better suited to swift-evolution or users list, but regarding 
> fatalError do you have any techniques for testing this behavior?

I believe the Swift compiler’s tests run code it expects to trap in a separate 
process and verify that the other process trapped. We may want to think about 
extending XCTest in some way to offer this behavior.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-corelibs-dev] NSDecimal & NSDecimalNumber

[Tony Parker via swift-corelibs-dev]

> On Dec 11, 2015, at 1:02 PM, Dan Thorpe  wrote:
> 
> Thanks for the clarification Tony - and for reminding me of the primary goal 
> r.e. API compatibility. :)
> 
> This may be better suited to swift-evolution or users list, but regarding 
> fatalError do you have any techniques for testing this behavior? I was 
> thinking about an internal try/throw/ layer (which would then be caught and 
> trampolined to fatalError for the public APIs) so that it would be possible 
> to write unit tests for the edge cases where there is a calculation error.
> 
> Cheers,
> Dan 

It’s a good question regarding the testability of fatalError paths. I think it 
would be really unfortunate if we had to write our own trampolines every place 
that we wanted to use it, but I’m not sure how else to verify the behavior if 
we don’t want to allow every test case to crash. Let’s raise the issue on the 
more general swift-users list and see if anyone has any ideas.

- Tony

> 
>> On 11 Dec 2015, at 19:00, Tony Parker > > wrote:
>> 
>> Hi Dan, Florian,
>> 
>> I agree with Philippe that NSDecimal is a particularly troublesome area in 
>> terms of how poorly the API is imported into Swift.
>> 
>> Since NSDecimal is already a value type, it may be possible to do something 
>> better here ourselves without worrying about the bridging problem. It would 
>> be an API change, however, so we should follow the swift-evolution process.
>> 
>> NSDecimalNumber would be more complicated, since it’s a class (and 
>> furthermore, a subclass of NSNumber).
>> 
>>> On Dec 11, 2015, at 4:58 AM, Dan Thorpe via swift-corelibs-dev 
>>> mailto:swift-corelibs-dev@swift.org>> wrote:
>>> 
>>> I’d be really interested in working on a Swift decimal number type. I’ve 
>>> done some work on this for a Money type here: 
>>> https://github.com/danthorpe/Money/tree/development/Money/Shared/Decimal 
>>> 
>>> 
>>> I agree that it’s best to start with NSDecimal, and that approach 2 would 
>>> offer the most flexibility.
>>> 
>>> I have a few other thoughts regarding the number behaviors.
>>> 
>>> NSDecimal’s functions accept rounding mode parameters and return 
>>> NSCalculationError but NSDecimalNumber accepts NSDecimalNumberBehavior 
>>> parameter and throws NSExceptions. I’m not really sure what the reason for 
>>> this discrepancy is and should a new Swift NSDecimal use 
>>> NSDecimalNumberBehavior, but maintain backwards compatibility with default 
>>> behaviors and defined rounding mode? 
>>> 
>> 
>> Our primary goal is API compatibility across platforms. It would be really 
>> unfortunate if a client of Foundation had to #ifdef their code to account 
>> for a platform difference.
>> 
>> That’s not to say we can’t improve things (as we do with every release), but 
>> compatibility requirements are a fact of life for a low level library like 
>> ours. Our clients appreciate it. =)
>> 
>>> Also, should a Swift NSDecimal continues with raising NSException, or adopt 
>>> Swift style error handling? I don’t think we would want to introduce 
>>> try/throw/catch semantics into the publicly exposed methods - but we could 
>>> have an internal API layer which does. Backwards compatible functions would 
>>> then have to convert between Swift ErrorType and NSException or 
>>> NSCalculationError.
>>> 
>> 
>> Anywhere that Darwin Foundation raises an NSException, we are replacing with 
>> fatalError, precondition, or similar. The root cause of either is the same 
>> (a programmer error). The try/catch/throws mechanism is for errors that we 
>> may want to present to a user at some point.
>> 
>> Hope this helps,
>> - Tony
>> 
>>> Cheers,
>>> Dan
>>> 
>>> p.s. in the linked project, I made a DecimalNumberType protocol generic 
>>> over the Behavior, which I’m not entire sure was a good decision or not.
>>> 
>>> 
 On 11 Dec 2015, at 12:32, Florian Reinhart via swift-corelibs-dev 
 mailto:swift-corelibs-dev@swift.org>> wrote:
 
 Hi all,
 
 Is someone already working on NSDecimal and/or NSDecimalNumber? If not I 
 would like to help and have a few questions on how to best tackle this.
 
 I think it’s best to start with NSDecimal and then use NSDecimal to create 
 NSDecimalNumber. That’s why I want to concentrate on NSDecimal first. As 
 far as I know there is no CF type we can utilize for NSDecimal and the 
 existing interface is not Swift-like. I see two possible approaches here:
 We try to match the existing interface of NSDecimal as close as possible 
 and only provide the same function interface with UnsafePointers all over 
 the place
 We create a Swift-like version of the NSDecimal struct. This struct stores 
 its data in private properties and exposes methods (add, multiply, etc.) 
 and computed properties (isNaN, etc.). Additionally, to achieve 
 compatibility with the existing Foundation NSD

Re: [swift-corelibs-dev] NSDecimal & NSDecimalNumber

[Dan Thorpe via swift-corelibs-dev]

Thanks for the clarification Tony - and for reminding me of the primary goal 
r.e. API compatibility. :)

This may be better suited to swift-evolution or users list, but regarding 
fatalError do you have any techniques for testing this behavior? I was thinking 
about an internal try/throw/ layer (which would then be caught and trampolined 
to fatalError for the public APIs) so that it would be possible to write unit 
tests for the edge cases where there is a calculation error.

Cheers,
Dan 

> On 11 Dec 2015, at 19:00, Tony Parker  wrote:
> 
> Hi Dan, Florian,
> 
> I agree with Philippe that NSDecimal is a particularly troublesome area in 
> terms of how poorly the API is imported into Swift.
> 
> Since NSDecimal is already a value type, it may be possible to do something 
> better here ourselves without worrying about the bridging problem. It would 
> be an API change, however, so we should follow the swift-evolution process.
> 
> NSDecimalNumber would be more complicated, since it’s a class (and 
> furthermore, a subclass of NSNumber).
> 
>> On Dec 11, 2015, at 4:58 AM, Dan Thorpe via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> I’d be really interested in working on a Swift decimal number type. I’ve 
>> done some work on this for a Money type here: 
>> https://github.com/danthorpe/Money/tree/development/Money/Shared/Decimal 
>> 
>> 
>> I agree that it’s best to start with NSDecimal, and that approach 2 would 
>> offer the most flexibility.
>> 
>> I have a few other thoughts regarding the number behaviors.
>> 
>> NSDecimal’s functions accept rounding mode parameters and return 
>> NSCalculationError but NSDecimalNumber accepts NSDecimalNumberBehavior 
>> parameter and throws NSExceptions. I’m not really sure what the reason for 
>> this discrepancy is and should a new Swift NSDecimal use 
>> NSDecimalNumberBehavior, but maintain backwards compatibility with default 
>> behaviors and defined rounding mode? 
>> 
> 
> Our primary goal is API compatibility across platforms. It would be really 
> unfortunate if a client of Foundation had to #ifdef their code to account for 
> a platform difference.
> 
> That’s not to say we can’t improve things (as we do with every release), but 
> compatibility requirements are a fact of life for a low level library like 
> ours. Our clients appreciate it. =)
> 
>> Also, should a Swift NSDecimal continues with raising NSException, or adopt 
>> Swift style error handling? I don’t think we would want to introduce 
>> try/throw/catch semantics into the publicly exposed methods - but we could 
>> have an internal API layer which does. Backwards compatible functions would 
>> then have to convert between Swift ErrorType and NSException or 
>> NSCalculationError.
>> 
> 
> Anywhere that Darwin Foundation raises an NSException, we are replacing with 
> fatalError, precondition, or similar. The root cause of either is the same (a 
> programmer error). The try/catch/throws mechanism is for errors that we may 
> want to present to a user at some point.
> 
> Hope this helps,
> - Tony
> 
>> Cheers,
>> Dan
>> 
>> p.s. in the linked project, I made a DecimalNumberType protocol generic over 
>> the Behavior, which I’m not entire sure was a good decision or not.
>> 
>> 
>>> On 11 Dec 2015, at 12:32, Florian Reinhart via swift-corelibs-dev 
>>> mailto:swift-corelibs-dev@swift.org>> wrote:
>>> 
>>> Hi all,
>>> 
>>> Is someone already working on NSDecimal and/or NSDecimalNumber? If not I 
>>> would like to help and have a few questions on how to best tackle this.
>>> 
>>> I think it’s best to start with NSDecimal and then use NSDecimal to create 
>>> NSDecimalNumber. That’s why I want to concentrate on NSDecimal first. As 
>>> far as I know there is no CF type we can utilize for NSDecimal and the 
>>> existing interface is not Swift-like. I see two possible approaches here:
>>> We try to match the existing interface of NSDecimal as close as possible 
>>> and only provide the same function interface with UnsafePointers all over 
>>> the place
>>> We create a Swift-like version of the NSDecimal struct. This struct stores 
>>> its data in private properties and exposes methods (add, multiply, etc.) 
>>> and computed properties (isNaN, etc.). Additionally, to achieve 
>>> compatibility with the existing Foundation NSDecimal, we provide the same 
>>> functions that take NSDecimal pointers and internally use the methods of 
>>> the Swift struct.
>>> What do you think?
>>> 
>>> Unfortunately, I haven’t found a lot of documentation for NSDecimal, yet. 
>>> Is there any documentation, which describes the NSDecimal functions?
>>> 
>>> —Florian
>>> 
>>> ___
>>> swift-corelibs-dev mailing list
>>> swift-corelibs-dev@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>>> 

Re: [swift-corelibs-dev] NSDate Comparable & Equatable

[Tony Parker via swift-corelibs-dev]

Hi James,

Here’s the start of the thread in the archives:

https://lists.swift.org/pipermail/swift-corelibs-dev/Week-of-Mon-20151130/77.html

- Tony

> On Dec 11, 2015, at 11:46 AM, James Lee via swift-corelibs-dev 
>  wrote:
> 
> Hi all,
> 
> I raised PR 119 yesterday with a comment from Tony Parker about a discussion 
> currently going on about this.
> 
> I seem to have missed out on this and currently not sure of the status on 
> this.
> 
> Cheers
> ___
> 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] libdispatch build issue

[Pierre Habouzit via swift-corelibs-dev]

I was talking about the *dispatch* run loop code. I'm not sure it's needed. The 
main queue is a different story. 

-Pierre on his iPhone

> On 11 déc. 2015, at 11:28, Tony Parker via swift-corelibs-dev 
>  wrote:
> 
> 
>>> On Dec 11, 2015, at 11:25 AM, Pierre Habouzit via swift-corelibs-dev 
>>>  wrote:
>>> 
 On Dec 11, 2015, at 9:57 AM, Pierre Habouzit via swift-corelibs-dev 
  wrote:
 
 
 On Dec 11, 2015, at 9:02 AM, Philippe Hausler via swift-corelibs-dev 
  wrote:
 
 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?
>>> 
>>> The linux equivalent to what we’re doing for the runloop is to use an 
>>> eventfd() to replace sending messages to its port.
>> 
>> Though the runloop code should be disabled on linux right now, as it’s 
>> highly dependent on mach ports, and we should discuss whether having a 
>> dispatch queue attached to the runloop makes sense for the non mach version, 
>> and if it does, should it have exactly the same queue_runloop implementation 
>> as today. I think not, and the simplest way to port the implementation is to 
>> have a different implementation for linux completely and not rely on the 
>> weird 4CF hooks that we have on OS X.
>> 
>> -Pierre
> 
> We already have a Windows implementation in there that uses HANDLE, so we are 
> not completely dependent on mach ports.
> 
> I think it’s critical for portability that we maintain the concept of 
> dispatch_main and CFRunLoop main thread integration. The exact mechanism is 
> something we can design, but we have a fairly proven pattern here that would 
> be straightforward to port.
> 
> - 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] libdispatch build issue

[Tony Parker via swift-corelibs-dev]

> On Dec 11, 2015, at 11:25 AM, Pierre Habouzit via swift-corelibs-dev 
>  wrote:
> 
>> On Dec 11, 2015, at 9:57 AM, Pierre Habouzit via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>>> 
>>> On Dec 11, 2015, at 9:02 AM, Philippe Hausler via swift-corelibs-dev 
>>> mailto:swift-corelibs-dev@swift.org>> wrote:
>>> 
>>> 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?
>> 
>> The linux equivalent to what we’re doing for the runloop is to use an 
>> eventfd() to replace sending messages to its port.
> 
> Though the runloop code should be disabled on linux right now, as it’s highly 
> dependent on mach ports, and we should discuss whether having a dispatch 
> queue attached to the runloop makes sense for the non mach version, and if it 
> does, should it have exactly the same queue_runloop implementation as today. 
> I think not, and the simplest way to port the implementation is to have a 
> different implementation for linux completely and not rely on the weird 4CF 
> hooks that we have on OS X.
> 
> -Pierre

We already have a Windows implementation in there that uses HANDLE, so we are 
not completely dependent on mach ports.

I think it’s critical for portability that we maintain the concept of 
dispatch_main and CFRunLoop main thread integration. The exact mechanism is 
something we can design, but we have a fairly proven pattern here that would be 
straightforward to port.

- Tony

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

Re: [swift-corelibs-dev] NSDecimal & NSDecimalNumber

[Tony Parker via swift-corelibs-dev]

Hi Dan, Florian,

I agree with Philippe that NSDecimal is a particularly troublesome area in 
terms of how poorly the API is imported into Swift.

Since NSDecimal is already a value type, it may be possible to do something 
better here ourselves without worrying about the bridging problem. It would be 
an API change, however, so we should follow the swift-evolution process.

NSDecimalNumber would be more complicated, since it’s a class (and furthermore, 
a subclass of NSNumber).

> On Dec 11, 2015, at 4:58 AM, Dan Thorpe via swift-corelibs-dev 
>  wrote:
> 
> I’d be really interested in working on a Swift decimal number type. I’ve done 
> some work on this for a Money type here: 
> https://github.com/danthorpe/Money/tree/development/Money/Shared/Decimal 
> 
> 
> I agree that it’s best to start with NSDecimal, and that approach 2 would 
> offer the most flexibility.
> 
> I have a few other thoughts regarding the number behaviors.
> 
> NSDecimal’s functions accept rounding mode parameters and return 
> NSCalculationError but NSDecimalNumber accepts NSDecimalNumberBehavior 
> parameter and throws NSExceptions. I’m not really sure what the reason for 
> this discrepancy is and should a new Swift NSDecimal use 
> NSDecimalNumberBehavior, but maintain backwards compatibility with default 
> behaviors and defined rounding mode? 
> 

Our primary goal is API compatibility across platforms. It would be really 
unfortunate if a client of Foundation had to #ifdef their code to account for a 
platform difference.

That’s not to say we can’t improve things (as we do with every release), but 
compatibility requirements are a fact of life for a low level library like 
ours. Our clients appreciate it. =)

> Also, should a Swift NSDecimal continues with raising NSException, or adopt 
> Swift style error handling? I don’t think we would want to introduce 
> try/throw/catch semantics into the publicly exposed methods - but we could 
> have an internal API layer which does. Backwards compatible functions would 
> then have to convert between Swift ErrorType and NSException or 
> NSCalculationError.
> 

Anywhere that Darwin Foundation raises an NSException, we are replacing with 
fatalError, precondition, or similar. The root cause of either is the same (a 
programmer error). The try/catch/throws mechanism is for errors that we may 
want to present to a user at some point.

Hope this helps,
- Tony

> Cheers,
> Dan
> 
> p.s. in the linked project, I made a DecimalNumberType protocol generic over 
> the Behavior, which I’m not entire sure was a good decision or not.
> 
> 
>> On 11 Dec 2015, at 12:32, Florian Reinhart via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> Hi all,
>> 
>> Is someone already working on NSDecimal and/or NSDecimalNumber? If not I 
>> would like to help and have a few questions on how to best tackle this.
>> 
>> I think it’s best to start with NSDecimal and then use NSDecimal to create 
>> NSDecimalNumber. That’s why I want to concentrate on NSDecimal first. As far 
>> as I know there is no CF type we can utilize for NSDecimal and the existing 
>> interface is not Swift-like. I see two possible approaches here:
>> We try to match the existing interface of NSDecimal as close as possible and 
>> only provide the same function interface with UnsafePointers all over the 
>> place
>> We create a Swift-like version of the NSDecimal struct. This struct stores 
>> its data in private properties and exposes methods (add, multiply, etc.) and 
>> computed properties (isNaN, etc.). Additionally, to achieve compatibility 
>> with the existing Foundation NSDecimal, we provide the same functions that 
>> take NSDecimal pointers and internally use the methods of the Swift struct.
>> What do you think?
>> 
>> Unfortunately, I haven’t found a lot of documentation for NSDecimal, yet. Is 
>> there any documentation, which describes the NSDecimal functions?
>> 
>> —Florian
>> 
>> ___
>> 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] NSDate, NSDateFormatter

[Tony Parker via swift-corelibs-dev]

Hi Joe,

Sure, bug reports are appreciated.

If you have the ability to check out the whole stack and try ToT, that would be 
great too. We are moving extremely rapidly right now on implementing missing 
pieces of Foundation.

- Tony

> On Dec 11, 2015, at 10:53 AM, Joseph Bell  wrote:
> 
> Thanks Tony, with LD_LIBRARY_PATH set to include usr/lib/swift/linux I can 
> get the REPL to reproduce what I see with the compiler, and that's a blank 
> line printed out:
> 
> ➜  dates  
> LD_LIBRARY_PATH=/opt/apple/swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04/usr/lib/swift/linux:$LD_LIBRARY_PATH
>  swift printdate.swift 
> 
> ➜  dates  
> 
> Which leads me to the obvious question, either I've forgotten how to use 
> NSDateFormatter, or the implementation in the December 1 drop is silently not 
> supporting setting the dateFormat property, which appears to be the case, as 
> setting dateStyle and timeStyle do appear to work.
> 
> import Foundation
> 
> let dateFormatter = NSDateFormatter()
> dateFormatter.dateFormat = "dd-MM-"
> var dateStr = dateFormatter.stringFromDate(NSDate())
> 
> print(dateStr)
> 
> dateFormatter.dateStyle = .MediumStyle
> dateFormatter.timeStyle = .MediumStyle
> dateStr = dateFormatter.stringFromDate(NSDate())
> print(dateStr)
> 
> results in:
> 
> ➜  dates  
> LD_LIBRARY_PATH=/opt/apple/swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04/usr/lib/swift/linux:$LD_LIBRARY_PATH
>  swift printdate.swift
> <-- this is a blank line emitted by the first print(), which it should not be 
> -->
> Dec 11, 2015, 6:52:33 PM
> 
> Thanks for any insight and if I need to file a bug report I am happy to help,
> Joe
> 
> 
> 
> 
> On Fri, Dec 11, 2015 at 10:59 AM, Tony Parker  > wrote:
> Hi Joe,
> 
> Try this as a workaround: Set the LD_LIBRARY_PATH environment variable to 
> $INSTALLED_LOCATION_OF_SWIFT/usr/lib/swift/linux
> 
> This should only affect the REPL and not compiled code.
> 
> I think this is supposed to be fixed in the top of tree Swift but not in the 
> Dec 1 binary drop.
> 
> - Tony
> 
>> On Dec 11, 2015, at 5:54 AM, Joseph Bell via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> All,
>> 
>> Howdy.  I am using swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04 that was 
>> released on December 1.  The following code:
>> 
>> import Foundation
>> 
>> let dateFormatter = NSDateFormatter()
>> dateFormatter.dateFormat = "dd-MM-"
>> let dateStr = dateFormatter.stringFromDate(NSDate())
>> 
>> print(dateStr)
>> 
>> results in 
>> 
>> LLVM ERROR: Program used external function '_TFC10Foundation6NSDateCfT_S0_' 
>> which could not be resolved!
>> 
>> when executed with the swift driver, and then when compiled with swiftc the 
>> print statement just gives a blank newline.
>> 
>> I don't know if this is a known issue (I haven't found any reference on the 
>> status page or elsewhere indicating this was unimplemented), or I have an 
>> environmental problem.
>> 
>> Thoughts?
>> 
>> Joe
>> 
>>  ___
>> 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] libdispatch build issue

[Pierre Habouzit via swift-corelibs-dev]

> On Dec 11, 2015, at 9:02 AM, Philippe Hausler via swift-corelibs-dev 
>  wrote:
> 
> 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?

The linux equivalent to what we’re doing for the runloop is to use an eventfd() 
to replace sending messages to its port.


>> On Dec 11, 2015, at 8:27 AM, David P Grove via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> 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 
> 
___
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

[David P Grove via swift-corelibs-dev]

phaus...@apple.com wrote on 12/11/2015 12:02:30 PM:
> 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?

If you grab the master branch it should build libdispatch.so on ubuntu
15.04.

I've put a quick cheat sheet in a pull request:
https://github.com/apple/swift-corelibs-libdispatch/pull/11

There's a patch from Hubertus to get timers at least partially working that
you may want too:
https://github.com/apple/swift-corelibs-libdispatch/pull/8


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

Sorry, I don't understand the code well enough yet to answer this
one :(   I'm sure Pierre or Daniel can.

--dave
___
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] NSDate, NSDateFormatter

[Tony Parker via swift-corelibs-dev]

Hi Joe,

Try this as a workaround: Set the LD_LIBRARY_PATH environment variable to 
$INSTALLED_LOCATION_OF_SWIFT/usr/lib/swift/linux

This should only affect the REPL and not compiled code.

I think this is supposed to be fixed in the top of tree Swift but not in the 
Dec 1 binary drop.

- Tony

> On Dec 11, 2015, at 5:54 AM, Joseph Bell via swift-corelibs-dev 
>  wrote:
> 
> All,
> 
> Howdy.  I am using swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04 that was 
> released on December 1.  The following code:
> 
> import Foundation
> 
> let dateFormatter = NSDateFormatter()
> dateFormatter.dateFormat = "dd-MM-"
> let dateStr = dateFormatter.stringFromDate(NSDate())
> 
> print(dateStr)
> 
> results in 
> 
> LLVM ERROR: Program used external function '_TFC10Foundation6NSDateCfT_S0_' 
> which could not be resolved!
> 
> when executed with the swift driver, and then when compiled with swiftc the 
> print statement just gives a blank newline.
> 
> I don't know if this is a known issue (I haven't found any reference on the 
> status page or elsewhere indicating this was unimplemented), or I have an 
> environmental problem.
> 
> Thoughts?
> 
> Joe
> 
>  ___
> 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] libdispatch build issue

[David P Grove via swift-corelibs-dev]

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

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

[Pierre Habouzit via swift-corelibs-dev]

> On Dec 11, 2015, at 8:19 AM, Dzianis Fedarenka via swift-corelibs-dev 
>  wrote:
> 
> 
>> 11 дек. 2015 г., в 18:36, Pierre Habouzit > > написал(а):
>> 
>> 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 :(.

That’s the point, porting starts with making it build ;)


-Pierre

___
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

[Dzianis Fedarenka via swift-corelibs-dev]

> 11 дек. 2015 г., в 18:36, Pierre Habouzit  написал(а):
> 
> 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 :(.___
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

[Dzianis Fedarenka via swift-corelibs-dev]

Actually, I’ve built library on 14.04 but it required some hack’s like adding 
dummy #define and calling libtool with different arguments after make failed 
with errors.

First try:

user$ sudo apt-get install libblocksruntime-dev libkqueue-dev 
libpthread-workqueue-dev
Reading package lists...
Building dependency tree...
Reading state information...
libblocksruntime-dev is already the newest version.
libkqueue-dev is already the newest version.
libpthread-workqueue-dev is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.

user$ git clone https://github.com/apple/swift-corelibs-libdispatch && cd 
swift-corelibs-libdispatch
user$ sh autogen.sh
user$ ./configure --with-blocks-runtime
user$ make
queue.c:216:22: error: use of undeclared identifier 'WORKQ_BG_PRIOQUEUE'
.dgq_wq_priority = WORKQ_BG_PRIOQUEUE,
   ^
queue.c:227:22: error: use of undeclared identifier 'WORKQ_BG_PRIOQUEUE'
.dgq_wq_priority = WORKQ_BG_PRIOQUEUE,
   ^
queue.c:926:18: error: invalid application of 'sizeof' to an incomplete type 
'struct dispatch_root_queue_context_s []'
dispatch_assert(countof(_dispatch_root_queue_contexts) ==
^

queue.c:926:18: error: invalid application of 'sizeof' to an incomplete type 
'struct dispatch_root_queue_context_s []'
dispatch_assert(countof(_dispatch_root_queue_contexts) ==
^
queue.c:926:18: error: invalid application of 'sizeof' to an incomplete type 
'struct dispatch_root_queue_context_s []'
dispatch_assert(countof(_dispatch_root_queue_contexts) ==
^
queue.c:926:18: error: invalid application of 'sizeof' to an incomplete type 
'struct dispatch_root_queue_context_s []'
dispatch_assert(countof(_dispatch_root_queue_contexts) ==
^
5 warnings and 6 errors generated.


Second try (with manually defined WORKQ_BG_PRIOQUEUE macro ;)):
user$ make
/bin/bash ../libtool  --tag=CXX   --mode=link clang++  -g -O2 -avoid-version
-o libdispatch.la -rpath /usr/local/lib allocator.lo apply.lo benchmark.lo 
data.lo introspection.lo init.lo io.lo object.lo once.lo queue.lo semaphore.lo 
source.lo time.lo transform.lo voucher.lo shims/linux_stubs.lo -lpthread  
-Lyes -lBlocksRuntime
../libtool: line 6000: cd: yes: No such file or directory
libtool: link: cannot determine absolute directory name of `yes'
make[2]: *** [libdispatch.la] Error 1
make[2]: Leaving directory 
`/home/user/code/libs/tmp/swift-corelibs-libdispatch/src'
make[1]: *** [all] Error 2
make[1]: Leaving directory 
`/home/user/code/libs/tmp/swift-corelibs-libdispatch/src'
make: *** [all-recursive] Error 1

Third try (after running libtool without -Lyes option):
user$ make
bsdtests.c:28:10: fatal error: 'crt_externs.h' file not found
#include 
 ^
1 error generated.


Few… At least libdispatch was built ;)

> 11 дек. 2015 г., в 18:02, David P Grove via swift-corelibs-dev 
>  написал(а):
> 
> swift-corelibs-dev-boun...@swift.org wrote on 12/11/2015 03:17:47 AM:
> 
> > From: f-dz-f via swift-corelibs-dev 
> > To: swift-corelibs-dev@swift.org
> > Date: 12/11/2015 03:18 AM
> > Subject: [swift-corelibs-dev]  libdispatch build issue
> > Sent by: swift-corelibs-dev-boun...@swift.org
> 
> > PS On ubuntu 14.04 project is also generally unbuildable (despite 
> > title of commit:33b735c5330b5a97d029bccfff9a7d78ef1f214 ;)). 
> 
> Hi,
> 
> Right now the Linux build is assuming you've installed some pre-req packages. 
>  In particular,
> 
> sudo apt-get install libblocksruntime-dev libkqueue-dev 
> libpthread-workqueue-dev
> 
> I've been building on 15.10;  haven't tried 14.04 recently.  Maybe try 
> install the pre-reqs on 14.04 and see what happens?
> 
> I'll put together a quick check sheet with build pre-reqs and instructions 
> and submit a pull request to include it.
> 
> --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] NSDecimal & NSDecimalNumber

[Matthew Johnson via swift-corelibs-dev]

This thread is related to the thread I started last night about Foundation and 
value types. 

Ideally all Foundation types that are already structs would expose a more 
Swifty interface and those that are naturally value types but currently 
implemented as classes would be bridged and exposed in Swift as value types.  

Responses last night seem to indicate at least some appetite for doing this if 
an acceptable bridging strategy can be identified even though it increases 
scope a bit as it is not directly related to portability.  

I would be extremely pleased if we are able to pull this off as it should be 
possible to design value types by composing Date, URL, Decimal, etc without 
needing to create our own value type wrappers for them.

Matthew

Sent from my iPhone

> On Dec 11, 2015, at 9:45 AM, Philippe Hausler via swift-corelibs-dev 
>  wrote:
> 
> NSDecimalNumber is mostly just a simple object wrapper for NSDecimal that 
> interoperates with NSNumber so that seems like a pretty sensible approach 
> ordering.
> 
> Since the goal of the swift-corelibs-foundation is to as closely match the 
> current APIs of Foundation as possible (exclusions have been made where it 
> just isn’t possible); so I would say that option 1 would be the more 
> appropriate way to start off. 
> 
> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/NumbersandValues/Articles/DecimalNumbers.html
>  might be a decent place to get a little bit of background; my suggestion 
> however would be to write some really good unit tests to verify it’s 
> behavior. 
> 
> Eventually we would like to archive these things so keeping it the same 
> structure is probably a good idea.
> 
> That all being said - NSDecimal itself seems reasonably suitable for a 
> re-look from a swift perspective. NSDecimalAdd, NSDecimalSubtract etc all 
> really would be more wonderful with operators and some instance 
> methods/properties would be really useful as well. The implementation of 
> NSDecimal and these additions are two different pieces and should be 
> considered separately as well. In that any change that we make to diverge 
> from usage immediately will not be directly usable on Mac OS X/iOS since we 
> will have to work that into the foundation overlay and/or make modifications 
> to the Foundation implementation for supporting any changes like that. 
> 
> So in short: #1 is the suggested route for a pull request onto Foundation and 
> #2 is a better route for a proposal for swift-evolution (specifically 
> targeted at Foundation).
> 
>> On Dec 11, 2015, at 4:32 AM, Florian Reinhart via swift-corelibs-dev 
>>  wrote:
>> 
>> Hi all,
>> 
>> Is someone already working on NSDecimal and/or NSDecimalNumber? If not I 
>> would like to help and have a few questions on how to best tackle this.
>> 
>> I think it’s best to start with NSDecimal and then use NSDecimal to create 
>> NSDecimalNumber. That’s why I want to concentrate on NSDecimal first. As far 
>> as I know there is no CF type we can utilize for NSDecimal and the existing 
>> interface is not Swift-like. I see two possible approaches here:
>> We try to match the existing interface of NSDecimal as close as possible and 
>> only provide the same function interface with UnsafePointers all over the 
>> place
>> We create a Swift-like version of the NSDecimal struct. This struct stores 
>> its data in private properties and exposes methods (add, multiply, etc.) and 
>> computed properties (isNaN, etc.). Additionally, to achieve compatibility 
>> with the existing Foundation NSDecimal, we provide the same functions that 
>> take NSDecimal pointers and internally use the methods of the Swift struct.
>> What do you think?
>> 
>> Unfortunately, I haven’t found a lot of documentation for NSDecimal, yet. Is 
>> there any documentation, which describes the NSDecimal functions?
>> 
>> —Florian
>> 
>> ___
>> 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] libdispatch build issue

[Pierre Habouzit via swift-corelibs-dev]

Hi,

> On Dec 11, 2015, at 12:17 AM, f-dz-f via swift-corelibs-dev 
>  wrote:
> 
> Hi! I’m unable to build on OS X 10.11 
> 
> Using make:
> 
> ../private/voucher_activity_private.h:493:10: fatal error: 'os/lock_private.h'
>   file not found
> #include 
>  ^
> 
> Using Xcode:
> 
> /Users/dzianis/Documents/my_code/libs/swift-corelibs-libdispatch/private/voucher_activity_private.h:493:10:
>  'os/lock_private.h' file not found

Yes, this is known and we’re working on resolving that issue.

> PS On ubuntu 14.04 project is also generally unbuildable (despite title of 
> commit:33b735c5330b5a97d029bccfff9a7d78ef1f214 ;)).

The linux port is in progress, and even if it built, right now, it wouldn’t be 
functional.

-Pierre

___
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

[David P Grove via swift-corelibs-dev]

swift-corelibs-dev-boun...@swift.org wrote on 12/11/2015 03:17:47 AM:

> From: f-dz-f via swift-corelibs-dev 
> To: swift-corelibs-dev@swift.org
> Date: 12/11/2015 03:18 AM
> Subject: [swift-corelibs-dev]  libdispatch build issue
> Sent by: swift-corelibs-dev-boun...@swift.org

> PS On ubuntu 14.04 project is also generally unbuildable (despite
> title of commit:33b735c5330b5a97d029bccfff9a7d78ef1f214 ;)).

Hi,

Right now the Linux build is assuming you've installed some pre-req
packages.  In particular,

sudo apt-get install libblocksruntime-dev libkqueue-dev
libpthread-workqueue-dev

I've been building on 15.10;  haven't tried 14.04 recently.  Maybe
try install the pre-reqs on 14.04 and see what happens?

I'll put together a quick check sheet with build pre-reqs and
instructions and submit a pull request to include it.

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

[swift-corelibs-dev] NSDecimal & NSDecimalNumber

[Florian Reinhart via swift-corelibs-dev]

Hi all,

Is someone already working on NSDecimal and/or NSDecimalNumber? If not I would 
like to help and have a few questions on how to best tackle this.

I think it’s best to start with NSDecimal and then use NSDecimal to create 
NSDecimalNumber. That’s why I want to concentrate on NSDecimal first. As far as 
I know there is no CF type we can utilize for NSDecimal and the existing 
interface is not Swift-like. I see two possible approaches here:
We try to match the existing interface of NSDecimal as close as possible and 
only provide the same function interface with UnsafePointers all over the place
We create a Swift-like version of the NSDecimal struct. This struct stores its 
data in private properties and exposes methods (add, multiply, etc.) and 
computed properties (isNaN, etc.). Additionally, to achieve compatibility with 
the existing Foundation NSDecimal, we provide the same functions that take 
NSDecimal pointers and internally use the methods of the Swift struct.
What do you think?

Unfortunately, I haven’t found a lot of documentation for NSDecimal, yet. Is 
there any documentation, which describes the NSDecimal functions?

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

[swift-corelibs-dev] libdispatch build issue

[f-dz-f via swift-corelibs-dev]

Hi! I’m unable to build on OS X 10.11 

Using make:

../private/voucher_activity_private.h:493:10: fatal error: 'os/lock_private.h'
  file not found
#include 
 ^

Using Xcode:

/Users/dzianis/Documents/my_code/libs/swift-corelibs-libdispatch/private/voucher_activity_private.h:493:10:
 'os/lock_private.h' file not found

PS On ubuntu 14.04 project is also generally unbuildable (despite title of 
commit:33b735c5330b5a97d029bccfff9a7d78ef1f214 ;)). ___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev