Hey,

I would like to refactor your current iOS offerings to include OSX support - NSTableView and perhaps NSCollectionView.

Would that be ok? And if so, have you any preference on how you would like it done?

Chris

Xcode Version 7.1.1 (7B1005)

My code is like this:

dispatch_async(queue) {
    let s1 = get_a_string()
    let s2 = get_another_string()

    // size of a and b is about 1000
    let a = s1!.characters.split { $0 == "\n" }.map(String.init)
    let b = s2!.characters.split { $0 == "\n" }.map(String.init)

    let diff = a.diff(b) // crash in Array::diffFromIndices
}

Maybe I'm missing something, but is there a more direct way of getting into the diff other than through Array.apply(_:) and the various UIKit extensions? Looking at the public API, DiffStep<T> is exposed but the properties in Diff<T> are not; so maybe this is a mistake? If so, I can provide a PR.

I'm asking this because I have a use case that requires consuming the diff results on a lower-level layer that hides the diff'ing implementation from the UI.

I think you should separate Dwifft.swift and Dwifft+UIKit.swift, because, as you said, maybe only Dwifft+UIKit.swift is actually useful for people. By doing that, I'd be easier to explain what the it does. Dwifft is very useful and neat, but it has one major problem: It took me a whole paragraph to understand what could be explained with

Automatic updates of UITableView with animations in Swift :large_orange_diamond:

What are your thoughts?

Hi,

my app sometimes crashes when updating the CollectionView. Unfortunately I'm not able to reproduce the crashes, but the same code (using the TableViewDiffCalculator) works without problems for my tableviews.

I'm using pagination and want to eliminate possible duplicates - hence the diff function here.

// strongSelf is from a guard clause in the callback
let diff = strongSelf.itemList.diff(newItems)
strongSelf.itemList.append(contentsOf: strongSelf.itemList.apply(diff))

the didset iss correctly triggered with the append

var itemList: Array<Item> = [] {
    didSet {
      self.diffCalculator?.rows = itemList
    }
  }

Relevant crashlog:

#0. Crashed: com.apple.main-thread
0  libsystem_kernel.dylib         0x181562014 __pthread_kill + 8
1  libsystem_pthread.dylib        0x18162a450 pthread_kill + 112
2  libsystem_c.dylib              0x1814d63e0 abort + 140
3  libsystem_malloc.dylib         0x1815a6a38 _nano_vet_and_size_of_live + 330
4  libsystem_malloc.dylib         0x1815a8bf0 _nano_malloc_check_clear + 392
5  libsystem_malloc.dylib         0x1815a7b3c nano_malloc + 44
6  libsystem_malloc.dylib         0x1815962c4 malloc_zone_malloc + 172
7  CoreFoundation                 0x18246615c _CFRuntimeCreateInstance + 312
8  CoreFoundation                 0x182551604 __CFStringCreateImmutableFunnel3 + 2116
9  CoreFoundation                 0x18247034c CFStringCreateCopy + 504
10 CoreFoundation                 0x1825519f0 _CFStringCreateWithFormatAndArgumentsAux2 + 256
11 CoreFoundation                 0x182575b98 _CFLogvEx2Predicate + 156
12 CoreFoundation                 0x182575eec _CFLogvEx3 + 408
13 Foundation                     0x18305c454 _NSLogv + 132
14 Foundation                     0x182f8335c NSLog + 32
15 Foundation                     0x18301f76c -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 64
16 UIKit                          0x188ce90e8 -[UICollectionView _endItemAnimationsWithInvalidationContext:tentativelyForReordering:animator:] + 13428
17 UIKit                          0x188cecc34 -[UICollectionView _endUpdatesWithInvalidationContext:tentativelyForReordering:animator:] + 92
18 UIKit                          0x188cecf14 -[UICollectionView _performBatchUpdates:completion:invalidationContext:tentativelyForReordering:animator:] + 384
19 UIKit                          0x188cecd74 -[UICollectionView _performBatchUpdates:completion:invalidationContext:tentativelyForReordering:] + 96
20 UIKit                          0x188ceccf8 -[UICollectionView _performBatchUpdates:completion:invalidationContext:] + 84
21 UIKit                          0x1885c71c0 -[UICollectionView performBatchUpdates:completion:] + 64
22 Dwifft                         0x100f1439c CollectionViewDiffCalculator.rows.setter (Dwifft+UIKit.swift)

Any idea what could be happening here?

I've been getting errors from within some unit test code that uses TableViewDiffCalculator. From view controller code that's invoked whenever backing data has changed...

vehicles.producer.startWithNext { vehicles in
    self.diffCalculator.rows = vehicles.sort()
}

...an exception like this is thrown when diffCalculator.rows is set:

failed: caught "NSInternalInconsistencyException", "Invalid update: invalid number of rows in section 0. The number of rows contained in an existing section after the update (5) must be equal to the number of rows contained in that section before the update (5), plus or minus the number of rows inserted or deleted from that section (5 inserted, 0 deleted) and plus or minus the number of rows moved into or out of that section (0 moved in, 0 moved out)."

After looking into this, my understanding is that tableView.beginUpdates() and tableView.endUpdates() require the table's dataSource to be modified in between the two calls, or at least in the same block. This is what Apple's documentation seems to suggest:

At the conclusion of a block—that is, after endUpdates returns—the table view queries its data source and delegate as usual for row and section data. Thus the collection objects backing the table view should be updated to reflect the new or removed rows or sections.

Sure enough, if I surround my self.diffCalculator.rows = ... call with update methods...

vehicles.producer.startWithNext { vehicles in
    self.tableView.beginUpdates()
    self.diffCalculator.rows = vehicles.sort()
    self.tableView.endUpdates()
}

...no exception is thrown, since update methods can be nested, and only the outer set triggers the actual insertions/deletions to the table.

My proposal to fix this would be to move Dwifft's beginUpdates call to a willSet observer, so that the initial number of rows is calculated before rows is changed, or to encourage wrapping rows modifications with update methods, like I did above.

I think this bug is being missed in the Dwifft tests because insertRowsAtIndexPaths and deleteRowsAtIndexPaths are being overridden. What's confusing to me is why I'm noticing this in testing, but not when my application is being run, but regardless, let me know what you think!

Fix taken from here: http://stackoverflow.com/questions/25265183/collectionview-performbatchupdates-crash

if oldRows.isEmpty { collectionView?.reloadData() } else { collectionView?.performBatchUpdates({ () -> Void in self.collectionView?.insertItemsAtIndexPaths(insertionIndexPaths) self.collectionView?.deleteItemsAtIndexPaths(deletionIndexPaths) }, completion: nil) }

After comparing ["a", "b", "c", "d"] to ["c", "b", "a"] we should know how to transform the first array into the second and vice versa. I mean we should get something like this:

{
  $0.moveTo(2)
  $1.same()
  $2.moveTo(0)
  $3.delete()
}

So that it's possible to move a UITableViewCell to a new position when needed.

There is a bunch of cases where we need to compare two sets of data and deal with their diff but here we forced to convert these collections to arrays and obviously use a heavier algorithm to deal with them. This can be achieved with the basic Swift Set operations like subtracting but I would really like to see such option in this library.

Seems something is fishy here... It compiles fine using the standard Debug xcconfig, but throws some missing symbol errors when trying to use Release.

I repro'd in a clean project using the Example app source so repro steps are:

• Download repro project
• Hit run and notice errors
• Edit the scheme to flip run back to using Debug
• Run again and notice no errors

The only difference I can see is you're linking the example app locally versus using a pod / carthage.

Undefined symbols for architecture i386:
  "__TFC6Dwifft22AbstractDiffCalculator5valuefT11atIndexPathV10Foundation9IndexPath_q_", referenced from:
      __TTSf4g_g_n___TFC10DwifftPods24StuffTableViewController9tableViewfTCSo11UITableView12cellForRowAtV10Foundation9IndexPath_CSo15UITableViewCell in StuffTableViewController.o
      __TTSf4g_g_n___TFC10DwifftPods29StuffCollectionViewController14collectionViewfTCSo16UICollectionView13cellForItemAtV10Foundation9IndexPath_CSo20UICollectionViewCell in StuffCollectionViewController.o
      __TTSf4g_g_n___TFC10DwifftPods25EventsTableViewController9tableViewfTCSo11UITableView12cellForRowAtV10Foundation9IndexPath_CSo15UITableViewCell in EventsTableViewController.o
  "__TFC6Dwifft22AbstractDiffCalculator5valuefT10forSectionSi_x", referenced from:
      __TToFC10DwifftPods24StuffTableViewController9tableViewfTCSo11UITableView23titleForHeaderInSectionSi_GSqSS_ in StuffTableViewController.o
      __TTSf4g_gs_g_n___TFC10DwifftPods29StuffCollectionViewController14collectionViewfTCSo16UICollectionView33viewForSupplementaryElementOfKindSS2atV10Foundation9IndexPath_CSo24UICollectionReusableView in StuffCollectionViewController.o
      __TTSf4d_n_n___TFC10DwifftPods25EventsTableViewController9tableViewfTCSo11UITableView23titleForHeaderInSectionSi_GSqSS_ in EventsTableViewController.o
  "__TFC6Dwifft22AbstractDiffCalculator15numberOfObjectsfT9inSectionSi_Si", referenced from:
      __TToFC10DwifftPods24StuffTableViewController9tableViewfTCSo11UITableView21numberOfRowsInSectionSi_Si in StuffTableViewController.o
      __TToFC10DwifftPods29StuffCollectionViewController14collectionViewfTCSo16UICollectionView22numberOfItemsInSectionSi_Si in StuffCollectionViewController.o
      __TFC10DwifftPods25EventsTableViewController9tableViewfTCSo11UITableView21numberOfRowsInSectionSi_Si in EventsTableViewController.o
      __TToFC10DwifftPods25EventsTableViewController9tableViewfTCSo11UITableView21numberOfRowsInSectionSi_Si in EventsTableViewController.o
  "__TFC6Dwifft22AbstractDiffCalculator16numberOfSectionsfT_Si", referenced from:
      __TToFC10DwifftPods24StuffTableViewController16numberOfSectionsfT2inCSo11UITableView_Si in StuffTableViewController.o
      __TToFC10DwifftPods29StuffCollectionViewController16numberOfSectionsfT2inCSo16UICollectionView_Si in StuffCollectionViewController.o
      __TFC10DwifftPods25EventsTableViewController16numberOfSectionsfT2inCSo11UITableView_Si in EventsTableViewController.o
      __TToFC10DwifftPods25EventsTableViewController16numberOfSectionsfT2inCSo11UITableView_Si in EventsTableViewController.o
  "__TFC6Dwifft22AbstractDiffCalculators15sectionedValuesGVS_15SectionedValuesxq__", referenced from:
      __TFC10DwifftPods24StuffTableViewController7shufflefT_T_ in StuffTableViewController.o
      __TFC10DwifftPods29StuffCollectionViewController7shufflefT_T_ in StuffCollectionViewController.o
      __TTSf4g_n___TFC10DwifftPods25EventsTableViewControllers12buttonPushesGSaV10Foundation4Date_ in EventsTableViewController.o
      __TTSf4n_g___TFFC10DwifftPods25EventsTableViewController11viewDidLoadFT_T_U_FCSo5TimerT_ in EventsTableViewController.o
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)

It takes 7s to calculate 500 object The Object is a custom class, with properties and some other methods, will spend much time than using Int or String as T

Hi there,

I'm trying to use this library with SPM (Swift Package Manager) but the Package.swift file contained at tag 0.9.0 is invalid. The one on the master branch however is valid.

Would you be able to tag the current master branch with a new version (e.g. 0.10.0)?

Simply tagging the latest commit would fix this issue.

Thanks!

This is an automated pull request to sync changes between the public and private repos.

:robot: This pull request should be merged (not squashed) to preserve continuity across repos, so please let a bot do the merging!

Originally posted by @Octomerger in https://github.com/github/docs/pull/11462

Originally posted by @Wiatt99923 in https://github.com/jflinter/Dwifft/issues/105

This is an automated pull request to sync changes between the public and private repos.

:robot: This pull request should be merged (not squashed) to preserve continuity across repos, so please let a bot do the merging!

Originally posted by @Octomerger in https://github.com/github/docs/pull/11462

SPM in Xcode 12 bumps minimum iOS deployment target to iOS 9, which produces warnings when trying to use Dwifft.

This PR fixes that by deleting minimum supported platforms from Package.swift. Please note, that macOS platform stays, because Dwifft minimum requirement for MacOS is higher than SwiftPM minimum deployment target.

I've also fixed couple new warnings from Swift compiler and enabled building for watchOS.

Hello, thank you for the awesome library!

We depend on it on one of our libraries and recently we migrated to SPM. We currently need to reference (master) branch or commit (6fec2b), which does not work well for library dependecies – there are even some issues with SPM.

Could you please just tag the current master HEAD 0.10.0? (The patch version is required.)