> On Nov 16, 2017, at 2:57 PM, Alex Blewitt <alb...@apple.com> wrote:
>
> I understood your question, but I can only point to you as to what is
> available and run on the swift-corelibs-foundation open source project.
Sorry to continue on this train (especially since it’s a big of a derailment).
I’m really not trying to be obtuse, but I don’t understand your answer. I was
asking what I thought were simple yes/no questions that didn’t require any
private/confidential information about the closed source code. Do you or does
anyone else know if the open-source project has a test target that runs its
test suite against the closed-source implementation? If not, shouldn’t it?
I read your first response as: swift-corelibs-foundation has a test suite that
runs against its own implementation. Am I missing something?
> Yes, being consistent between platforms is one of the purposes of the
> swift-corelibs-foundation project. However, there are both run-time and
> implementation differences between the two platforms; the existence (or not)
> of the Objective-C runtime, whether or not comparisons are performed using
> the rules based on the Darwin version of Foundation or the ICU rules on the
> open-source version of Foundation, and so on.
I understand this, but I’m not talking about run-time/implementation
differences, just testable input/output expectations on the functions and
methods that swift-corelibs-foundation can implement. Assuming that the
functions and methods swift-corelibs-foundation can implement should behave the
same, its test suite should be able to run against Darwin Foundation.
> Some of the differences are just bugs, in which case we can try and resolve
> the issues when they're filed at bugs.swift.org <http://bugs.swift.org/> or
> via pull requests on the GitHub repository. Some of the issues are ones where
> the implementation in the open source version is missing; either because the
> functionally cannot be implemented (e.g. dynamic unloading of bundles) or
> because it's not been prioritised yet (e.g.
> https://github.com/apple/swift-corelibs-foundation/search?utf8=✓&q=nsunimplemented
>
> <https://github.com/apple/swift-corelibs-foundation/search?utf8=%E2%9C%93&q=nsunimplemented>).
> In particular the big items that are missing at the moment are
> encoder/decoder implementations and those relating to nspredicate/expression,
> which both can be implemented in runtimes that have dynamic introspection of
> data structures but which therefore can't be implemented in Linux.
>
> Having said that, if you do find consistency issues which are important to
> you then please file bugs, and optionally provide pull requests for them. We
> can help on the mailing list to try and resolve any issues or questions as
> they arise.
I totally have been and will continue to! I was hopeful that we could discuss a
system that automates some of this and can catch regressions and
inconsistencies more quickly. Is there any reason not to discuss such a
solution?
Stephen
_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
