Hi all,
I'm attempting to implement an xml parser using (swift-3.0-PREVIEW-2). When
compiling it requires all of the NSXMLParserDelegate functions to be
implemented (they are optional on OSX) which I have implemented. However at run
time none of the the delegate functions are called even though
FWIW, if you agree that this approach is reasonable, I would be willing
to write the patch for it.
-Kevin Ballard
On Tue, Aug 2, 2016, at 05:46 PM, Kevin Ballard wrote:
> I agree with Stephan, NSIndexPath performance is important and we
> should avoid the overhead of allocating/freeing an array f
I agree with Stephan, NSIndexPath performance is important and we should
avoid the overhead of allocating/freeing an array for the common case.
Instead of just always wrapping NSIndexPath, maybe we should just switch
the internal representation to something like
enum Indices {
case one(Int)
I want to port https://github.com/apple/swift/pull/3923 to
swift-corelibs-libdispatch but I can't figure out how to build
swift-corelibs-libdispatch on OS X. Running `sh autogen.sh` results in
src/Makefile.am:9: error: Libtool library used but 'LIBTOOL' is undefined
src/Makefile.am:9: The usua
Hi Tony,
Thanks for the update, I looked over the PR's i think i am that recent
contributor .
I do have a question about updating and rebasing. Looks like the tip of
master is not compiling with the 7/29 snapshot.
Think it was compiling last right before last weekend. I tried to build the
TC manua
Hi
I was looking at Data.swift and noticed that 2 of the init methods
were different in corelibs-foundation v swift stdlib
https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/Data.swift
has
public init?(capacity: Int)
public init?(count: Int)
https://github.com/apple/swif
Tony,
I understand why you'd ideally want to have a real-world benchmark to guide
performance optimisations, but if you require that for every
performance-related change, you set a very high bar, and that bar will
probably have the effect of biasing performance downwards, since if there
is no exis
Hi Stephan,
> On Aug 2, 2016, at 6:04 PM, Stephan Tolksdorf wrote:
>
> Hi Parker,
>
> I noticed the IndexPath overhead when I investigated why a Swift 3
> implementation of UICollectionViewLayout.layoutAttributesForElementsInRect
> spent more time in malloc, free and related methods, but I do
Oh, I'm sorry, Tony, I was too hasty and mistook your last name for your
first name :-(
- Stephan
On 2 August 2016 at 12:04, Stephan Tolksdorf wrote:
> Hi Parker,
>
> I noticed the IndexPath overhead when I investigated why a Swift 3
> implementation of UICollectionViewLayout.layoutAttributesFo
Hi Parker,
I noticed the IndexPath overhead when I investigated why a Swift 3
implementation of UICollectionViewLayout.layoutAttributesForElementsInRect
spent more time in malloc, free and related methods, but I don't have a
benchmark.
Is it important that IndexPath uses native Swift refcounting?
Hi David,
Thanks for helping!
Can you check out some of our current open PRs to make sure your work isn’t
overlapping? We’ve had some contributions in this area recently that we still
need to finish merging.
- Tony
> On Jul 29, 2016, at 11:28 PM, David Liu via swift-corelibs-dev
> wrote:
>
Hi Stephan,
Do you have some benchmarks that you could share? That would help us focus
performance work in the right area.
I know that 2-item IndexPaths are super common with UIKit collection view and
friends, so we may just want to special case those. Unfortunately, NSIndexPath
is not abstrac
12 matches
Mail list logo
