profile
viewpoint
Anders Ha andersio London, United Kingdom http://andersha.com/ Make Swift things. Maintains @ReactiveCocoa.

andersio/Cycler 72

[Archived] Unidirectional data flow architecture with SwiftUI and Combine.

andersio/MantleData 5

Reactive tools for using Core Data in Swift.

andersio/ReactiveCocoa 1

Streams of values over time

andersio/subpixel 1

subpixel: A subpixel convnet for super resolution with Tensorflow

andersio/BEMSimpleLineGraph 0

Elegant Line Graphs for iOS. (Charting library)

andersio/BTree 0

Fast ordered collections for Swift using in-memory B-trees

andersio/ChitChat 0

A native Mac app wrapper for WhatsApp Web

andersio/ColladaMorphAdjuster 0

Make shape key/morphers in Blender-exported Collada (.dae) available to Apple SceneKit

issue commentgroue/GRDB.swift

Immediacy of ValueObservationScheduler.immediate

Thanks for the explanation!

The initial value escapes this game with the immediate scheduler. The reason why it is restricted to the main queue is, again, the guarantee of correct ordering of fresh value notifications. When the first value is delivered synchronously on the main queue, and all other values asynchronously on the main queue as well, no misordering can happen. Other queues could be handled with dispatchPrecondition(.onQueue(...)), but it unfortunately has availability problems.

I would say what I am really advocating for is an option to disable main thread confinement.

My understanding of the ValueObservation implementation is that:

  1. onChange is invoked with the initial value immediately.

  2. The next stage of the observation setup is scheduled asynchronously via _weakAsyncWriteWithoutTransaction.

  3. On the serial database write queue:

    i) snapshots are compared to determine the necessity of a second fetch, and is delivered synchronously to ValueObserver.notifyChange should it be the case.

    ii) the ValueObserver is then finally registered as a transaction observer in the DatabasePool.

  4. Every call of ValueObserver.notifyChange schedules the callback with the fetched value using the preconfigured ValueObservationSchedulerImpl. This has to be on a DispatchQueue.

Taking the perspective of a random background thread, starting a ValueObservation with the immediate option — even if it is not on the main thread — IMO should still be safe and in the expected order. The code cannot disrespect the program order, even if there are asynchronous hops involved — (2) must happen after (1), (3i) must happen after (2), (3ii) must happen after (3i), and hooks calling into the observer can happen only after (3) releases the database write queue.

So it seems that it should be okay for ValueObservationScheduler to either remove the main thread restriction on .immediate, or provide a use-with-care option for those who want to save an extra DispatchQueue hop.

andersio

comment created time in 2 days

issue openedgroue/GRDB.swift

Immediacy of ValueObservationScheduler.immediate

<!-- ℹ We use Github issues for bug reports, feature requests, general support, and questions about the library.

Please fill out this template when filing an issue. -->

What did you do?

Use ValueObservationScheduler.immediate. :p

What did you expect to happen?

We were expecting that such options would permit observations being started on any thread, and being delivered on whichever thread the SQLite hooks are called on. In other words, no extra scheduling hops would be incurred, and threading is a concern for the subscriber to deal with.

What happened instead?

It isn't actually "Immediate" in the same sense as ImmediateScheduler in Combine, Rx and ReactiveSwift. Main thread confined is perhaps a better description.

I guess there are two questions from me:

  1. Any reason why GRDB should not offer a truly immediate (i.e. no scheduling) option?

  2. Perhaps it is worth considering renaming this "immediate" scheduler to emphasise the prerequisite of main thread confinement?

Environment

GRDB flavor(s): GRDB GRDB version: 5.0.0-beta3 Installation method: CocoaPods Xcode version: 12.0 beta 1 Swift version: 5.3 Platform(s) running GRDB: iOS, macOS macOS version running Xcode: 10.15.6 beta

created time in 3 days

PR opened ReactiveCocoa/Loop

Anders/first value after nil

Pick up again the plan to deprecate Feedback(predicate:effects:).

This PR deprecates:

  • Feedback.init(effects:)
  • Feedback.init(predicate:effects:)

and replace them with:

  • Feedback.init(whenBecomesTrue:effects:)
  • Feedback.init(firstValueAfterNil:effects:)

The experience of RAF/Loop production use has supported well that the replacements here have more desirable semantics. They also support real world use cases better, especially when the state is a product type value with states often only being partially invalidated.

  • [ ] Unit tests
+94 -22

0 comment

1 changed file

pr created time in 7 days

create barnchReactiveCocoa/Loop

branch : anders/first-value-after-nil

created branch time in 7 days

PR opened ReactiveCocoa/Loop

Scope only event type, and erase event type. enhancement

Introduce the convenience to scope only the event type:

enum WeatherUserAction {
  case refresh, retry, ...
}

enum WeatherEvent {
  case didFetch, ...
  case user(WeatherUserAction)
}

let internal: Loop<WeatherState, WeatherEvent>

let state = internal.scoped(event: WeatherEvent.user)
print(type(of: state)) // OUT: Loop<WeatherState, WeatherUserAction>

Also a convenience to erase the event type completely:

let internal: Loop<WeatherState, WeatherEvent>

let state = internal.eraseEventType()
print(type(of: state)) // OUT: Loop<WeatherState, Never>
+28 -12

0 comment

3 changed files

pr created time in 7 days

create barnchReactiveCocoa/Loop

branch : anders/scoping-event-type

created branch time in 7 days

PR opened ReactiveCocoa/Loop

Fix a deadlock when `Loop.producer` is started recursively. bug

The deadlock is fixed by using a recursive lock, so that Loop.producer can be reentrant.

Having said that, event draining must remain non-reentrant, where reentrant calls must continue not to attempt to drain the event queue. So refactoring is done in Floodgate to deal with reentrancy appropriately for the event queue.

+127 -46

0 comment

3 changed files

pr created time in 7 days

create barnchReactiveCocoa/Loop

branch : anders/fix-deadlock

created branch time in 7 days

push eventReactiveCocoa/Loop

Anders Ha

commit sha d87e9a658d2d3f23c82987ac64b3dc08f75c8052

Change SwiftUI wrappers to use a shared cache bound to the main runloop.

view details

push time in 10 days

push eventReactiveCocoa/Loop

Anders Ha

commit sha 589be15f24a7f6d09b36b18309559401050f54dd

Change SwiftUI wrappers to use a shared cache bound to the main runloop.

view details

push time in 10 days

pull request commentReactiveCocoa/Loop

Change SwiftUI wrappers to use a shared cache bound to the main runloop.

Probably overcomplicated this. Could achieve the same effect by abolishing MainThreadLoopBox but keeping objectWillChange. 🤔

andersio

comment created time in 10 days

PR opened ReactiveCocoa/Loop

Change SwiftUI wrappers to use a shared cache bound to the main runloop.

RootLoopBox now internally creates & holds onto a "main thread view", aka MainThreadLoopBox, to serve the SwiftUI bindings @LoopBinding and @EnvironmentLoop.

MainThreadLoopBox subjects its state copying from RootLoopBox to the main queue scheduling. This allows state reads on the main thread always see a consistent value in the same runloop iteration through the MainThreadLoopBox. All @LoopBinding and @EnvironmentLoop are ultimately served by the same MainThreadLoopBox per loop.

This is an aftermath of the WWDC 2020 SwiftUI session on data flows, which stated that @ObservedObject does not have a strong ownership on the object in WWDC 2020. The intended mechanism @StateObject for such use case is available only on iOS 14.0+.

+206 -84

0 comment

9 changed files

pr created time in 10 days

push eventReactiveCocoa/Loop

Anders Ha

commit sha d87e9a658d2d3f23c82987ac64b3dc08f75c8052

Change SwiftUI wrappers to use a shared cache bound to the main runloop.

view details

push time in 10 days

create barnchReactiveCocoa/Loop

branch : anders/swiftui-fix

created branch time in 10 days

issue commentReactiveCocoa/ReactiveCocoa

Crash during runloop's autorelease pool drain on macOS 10.15 Catalina

@ianbytchek The issue stands on its own in an environment having only RAC. So I am fairly confident it is not a user-end error.

ianbytchek

comment created time in 11 days

issue openedgroue/GRDB.swift

Change of behavior for non-existing columns on Xcode 12 beta 1

<!-- ℹ We use Github issues for bug reports, feature requests, general support, and questions about the library.

Please fill out this template when filing an issue. -->

What did you do?

We have a query that does simply:

try pool.write { db in
  try Record.filter(Column("nonExisting") == "stub").deleteAll(in: db)
}

What did you expect to happen?

On Xcode 12 beta, it does throw an error with SQLite error code 1 (SQLITE_ERROR) with a clear message of "no such column nonExisting".

What happened instead?

On Xcode 11.5, it seems SQLite gracefully lets it through.

Could this possibly be caught when building against earlier iOS SDKs too? Been trying to research on whether SQlite has some sort of error checking modes that were previously disabled, but nothing seems relevant.

Environment

GRDB flavor(s): GRDB with system SQLite GRDB version: 5.0.0-beta3 Installation method: CocoaPods Xcode version: Xcode 11.5 and Xcode 12 beta 1 Swift version: 5.2 Platform(s) running GRDB: iOS macOS version running Xcode: 10.5.5

created time in 15 days

pull request commentReactiveCocoa/ReactiveCocoa

Bump SPM swift-tools-version to 5.2

MapKit tests sometimes fail because MapKit intermittently retains the views a little longer.

mluisbrown

comment created time in 23 days

pull request commentReactiveCocoa/ReactiveCocoa

Bump SPM swift-tools-version to 5.2

Could you update .swift-version too?

mluisbrown

comment created time in 23 days

PR closed ReactiveCocoa/ReactiveCocoa

Move Swift tools version to 5.2. ci:verify

Checklist

  • [ ] Updated CHANGELOG.md.
+3 -3

0 comment

2 changed files

andersio

pr closed time in 23 days

issue closedReactiveCocoa/ReactiveCocoa

Use GitHub Actions for CI

It would make the CI jobs faster with the much higher usage limits than Travis: https://help.github.com/en/articles/workflow-syntax-for-github-actions#usage-limits

  • You can execute up to 20 workflows concurrently per repository.
  • ...
  • You can run up to 20 jobs concurrently per repository across all workflows.

@ReactiveCocoa/reactivecocoa Could someone with the admin right sign up for the beta?

https://github.com/features/actions

closed time in 24 days

ikesyo

issue commentReactiveCocoa/ReactiveCocoa

Use GitHub Actions for CI

Moved to GitHub Actions in #3706.

ikesyo

comment created time in 24 days

issue closedReactiveCocoa/ReactiveCocoa

App rejected for HealthKit metadata

Hi, form a couple of months we have upgraded our version of ReactiveCoca and Apple had started to reject our application, because they find HealthKit inside it. The only occurrency of HealthKit in our entire project is in WKInterfaceActivityRing.swift. We use ReactiveCocoa in our watchOS extension, but we don't have HealthKit functionalities. Do you have some suggestion to solve our problem? Is it possible to drop this extension? Maybe our carthage file is misconfigured and we need to change something to import only watchkit extensions without the ones who import HealthKit?

closed time in 24 days

Oni-zerone

issue commentReactiveCocoa/ReactiveCocoa

App rejected for HealthKit metadata

11.0 has been released.

andersha@Mac ~ % otool -L /Users/andersha/Library/Developer/Xcode/DerivedData/ReactiveCocoa-dvxioopgbbdbrcazzetzfbdxwanb/Build/Products/Debug-watchsimulator/ReactiveCocoa.framework/ReactiveCocoa
/Users/andersha/Library/Developer/Xcode/DerivedData/ReactiveCocoa-dvxioopgbbdbrcazzetzfbdxwanb/Build/Products/Debug-watchsimulator/ReactiveCocoa.framework/ReactiveCocoa:
	@rpath/ReactiveCocoa.framework/ReactiveCocoa (compatibility version 1.0.0, current version 1.0.0)
	@rpath/ReactiveSwift.framework/ReactiveSwift (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/Foundation.framework/Foundation (compatibility version 300.0.0, current version 1675.129.0)
	/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)
	/System/Library/Frameworks/CoreFoundation.framework/CoreFoundation (compatibility version 150.0.0, current version 1675.129.0)
	/System/Library/Frameworks/WatchKit.framework/WatchKit (compatibility version 1.0.0, current version 1.0.0)
	@rpath/libswiftCore.dylib (compatibility version 1.0.0, current version 1103.2.25)
	@rpath/libswiftCoreGraphics.dylib (compatibility version 1.0.0, current version 0.0.0)
	@rpath/libswiftFoundation.dylib (compatibility version 1.0.0, current version 0.0.0)
	@rpath/libswiftObjectiveC.dylib (compatibility version 1.0.0, current version 0.0.0)
Oni-zerone

comment created time in 24 days

release ReactiveCocoa/ReactiveCocoa

11.0.0

released time in 24 days

PR opened ReactiveCocoa/ReactiveCocoa

Move Swift tools version to 5.2. ci:verify

Checklist

  • [ ] Updated CHANGELOG.md.
+3 -3

0 comment

2 changed files

pr created time in 24 days

push eventReactiveCocoa/ReactiveCocoa

Anders Ha

commit sha 0001c2883fc413e9a46998421cbc780f574f303f

Update .swift-version

view details

push time in 24 days

create barnchReactiveCocoa/ReactiveCocoa

branch : anders/swiftpm-5-2

created branch time in 24 days

created tagReactiveCocoa/ReactiveCocoa

tag11.0.0

Cocoa framework and Obj-C dynamism bindings for ReactiveSwift.

created time in 24 days

push eventReactiveCocoa/ReactiveCocoa

Anders Ha

commit sha b3d48751cf06060de602f151a886def4c7f4c73b

11.0.0

view details

push time in 24 days

PR merged ReactiveCocoa/ReactiveCocoa

Remove binding for WKInterfaceActivityRing + CI pipeline fixes ci:verify

This causes ReactiveCocoa to link with HealthKit when building for watchOS.

We will release a major version for its removal, and provide no replacement initially other than a suggestion for affected users to define the extension in their own project.

Checklist

  • [x] Updated CHANGELOG.md.
+203 -128

3 comments

15 changed files

andersio

pr closed time in 24 days

push eventReactiveCocoa/ReactiveCocoa

Anders Ha

commit sha 261eebecf77583998da7670f011952875ff418e7

Remove binding for WKInterfaceActivityRing + CI pipeline fixes (#3706) * Remove binding for WKInterfaceActivityRing * Update Changelog. * Remove WKInterfaceActivityRing.swift from build settings. * Move .swift-version to 5.1. [skip ci] * Move CI to Xcode 11.4. * Ditto * Update build destinations. * Disable the test case due to unrelated NSStackView KVO issue. * Adjust the flaky async tests so they don't block the main runloop. * Update podspecs on supported Swift versions. * PR tests in GitHub actions * Fix tests for Mac Catalyst. * Disable UISearchBarSpec for now.

view details

push time in 24 days

pull request commentReactiveCocoa/ReactiveCocoa

Remove binding for WKInterfaceActivityRing + CI pipeline fixes

Finally -.-

andersio

comment created time in 24 days

issue openedReactiveCocoa/ReactiveCocoa

UISearchBar delegate proxy crash on Mac Catalyst

Related: https://github.com/ReactiveX/RxSwift/issues/2161

created time in 24 days

push eventReactiveCocoa/ReactiveCocoa

Anders Ha

commit sha b580bce31582f1dc42ec2fd22e710c075b2de1f0

Disable UISearchBarSpec for now.

view details

push time in 24 days

push eventReactiveCocoa/ReactiveCocoa

Anders Ha

commit sha 2670a511ac57f7e61e855964acecca32ea8ed30a

Fix tests for Mac Catalyst.

view details

push time in 24 days

push eventReactiveCocoa/ReactiveCocoa

Anders Ha

commit sha 3d9dc221d62254f52f251c26ff2603417c0d02e6

Fix tests for Mac Catalyst.

view details

push time in 24 days

push eventReactiveCocoa/ReactiveCocoa

Anders Ha

commit sha ea3aba1e6f12783aa2d23fab720e5d0a1111ca38

Fix tests for Mac Catalyst.

view details

push time in 24 days

push eventReactiveCocoa/ReactiveCocoa

Anders Ha

commit sha ed33b2672de6be913a005633f17ed861ddfb4e1c

PR tests in GitHub actions

view details

push time in 24 days

push eventReactiveCocoa/ReactiveCocoa

Anders Ha

commit sha 9bbf5690ec879daa801ebc89c6cb37a5a2eee644

PR tests in GitHub actions

view details

push time in 24 days

push eventReactiveCocoa/ReactiveCocoa

Anders Ha

commit sha cb31a2795ee62c490c85f87c2f4b3d0edf376472

Update podspecs on supported Swift versions.

view details

push time in 24 days

issue closedReactiveCocoa/ReactiveCocoa

KeyValueObservingSwift4Spec is flaky / sometime crashes

https://travis-ci.org/ReactiveCocoa/ReactiveCocoa/jobs/588775554#L2247

2019-09-24 05:24:19.848 xcodebuild[4308:12288] [MT] IDETestOperationsObserverDebug: (572DACB9-175A-4D65-B907-D439A7C04B10) Finished requesting crash reports. Continuing with testing.
    ✗ NSObject_signal_for____a_reactive_key_value_observer_using_Swift_4_Smart_Key_Path__stress_tests__async_disposal_of_signal_with_in_flight_changes, Test crashed

closed time in 24 days

ikesyo

issue commentReactiveCocoa/ReactiveCocoa

KeyValueObservingSwift4Spec is flaky / sometime crashes

Removed the blocking bits in #3706. That should hopefully stop it from being flaky.

ikesyo

comment created time in 24 days

issue commentReactiveCocoa/ReactiveCocoa

Crash during runloop's autorelease pool drain on macOS 10.15 Catalina

Since it affects only macOS Catalina for now, the fix I have in mind would be the RAC internal ActionProxy swizzling the NSControl directly, instead of isa-swizzling. That hopefully would solve the issue around using with NSStackView, and should not change the behavior of things depending on ActionProxy.

Having that said, this might reemerge with method wiretapping with trigger(for:) and signal(for:), unfortunately. Changing them not to do isa-swizzling would require a RAC major release, because we can no longer guarantee that the callout runs after the call (including the recursive super calls), hence potentially leading to unintended behavioral change. :(

ianbytchek

comment created time in 24 days

push eventReactiveCocoa/ReactiveCocoa

Anders Ha

commit sha f6d08e6b880f0a0b22d6382fcae7e0a992455911

Adjust the flaky async tests so they don't block the main runloop.

view details

push time in 24 days

pull request commentReactiveCocoa/ReactiveCocoa

Remove binding for WKInterfaceActivityRing

@Oni-zerone Got deterred by a Catalina issue and a flaky async test in CI. As soon as CI is passing I will make a release.

andersio

comment created time in 25 days

push eventReactiveCocoa/ReactiveCocoa

Anders Ha

commit sha ed86535e049f506e68fdf3a5ae47a85d9a7d556e

Disable the test case due to unrelated NSStackView KVO issue.

view details

push time in a month

issue commentReactiveCocoa/ReactiveCocoa

Crash during runloop's autorelease pool drain on macOS 10.15 Catalina

Alright, I managed to figure out one of the cause. RAC deliberately avoided this situation by not isa-swizzling if KVO has isa-swizzled already (so we don't subclass the KVO NSKVONotifying_ runtime subclass).

That's said Catalina appears to have broken it because object_getClass is now conceiving NSKVONotifying_, when it had been reflecting the isa honestly before 10.15 Catalina AFAIK. 🤷‍♂️

ianbytchek

comment created time in a month

issue commentReactiveCocoa/ReactiveCocoa

Crash during runloop's autorelease pool drain on macOS 10.15 Catalina

Make sure all RAC bindings that would swizzle have setup, before adding the NSViews to a NSStackView would workaround the issue reliably.

ianbytchek

comment created time in a month

issue commentReactiveCocoa/ReactiveCocoa

Crash during runloop's autorelease pool drain on macOS 10.15 Catalina

Make sure RAC swizzling has happened before adding the NSButton to a NSStackView would likely workaround the issue reliably.

ianbytchek

comment created time in a month

issue commentReactiveCocoa/ReactiveCocoa

Crash during runloop's autorelease pool drain on macOS 10.15 Catalina

It seems the issue is around that we isa-swizzle the class after the internal NSKeyValueProperty instance was created, which had cached the isa pointer to the original NSButton class. But then at removal time, it was perhaps attempting to match the observer using the new isa pointer to our swizzled class.

:|

They have likely tightened how KVO detects isa swizzling.

ianbytchek

comment created time in a month

issue commentReactiveCocoa/ReactiveCocoa

Crash during runloop's autorelease pool drain on macOS 10.15 Catalina

@ianbytchek This looks like isa-swizzling RAC did is intefering with some assumptions made by NSStackView internals in Catalina. Have to look deeper into how this can be resolved.

ianbytchek

comment created time in a month

Pull request review commentReactiveCocoa/Loop

Propagate events with state for feedbacks

 extension Loop {         ///             and having them consumed by `output` using the `SignalProducer.enqueue(to:)` operator.         public init(             events: @escaping (-                _ state: SignalProducer<State, Never>,+                _ state: SignalProducer<(State, Event?), Never>,
                _ statesAndEvents: SignalProducer<(updated: State, by: Event?), Never>,

inspired by https://developer.apple.com/documentation/swift/dictionary/3127161-init

sergdort

comment created time in a month

pull request commentReactiveCocoa/Loop

Propagate events with state for feedbacks

@sergdort

We need to test this:

https://github.com/ReactiveCocoa/Loop/blob/ef4a2084dbc296c514baa46ca6efaf5f4f24f978/Loop/Public/FeedbackLoop.swift#L82-L87

that subscribing to state does yield nil and subsequent events in the order we expected them to be.

sergdort

comment created time in a month

push eventReactiveCocoa/ReactiveSwift

Michael Brown

commit sha 58d92aa01081301549c48a4049e215210f650d07

Add Rx migration cheatsheet (#793)

view details

Anders Ha

commit sha f38aebf4d98cb825ba1d9f9f34f6184dc1baa01d

Merge branch 'master' into anders/podspec

view details

push time in a month

PR closed ReactiveCocoa/ReactiveCocoa

CI build against macOS Catalyst.

Checklist

  • Updated CHANGELOG.md.
+6 -1

0 comment

1 changed file

andersio

pr closed time in a month

push eventReactiveCocoa/ReactiveCocoa

Anders Ha

commit sha 125b4f02a01290480d2348853610af0b2baf44be

Update build destinations.

view details

push time in a month

pull request commentReactiveCocoa/ReactiveSwift

Stop declaring Swift 5.0 support.

@mluisbrown It was bumped to swift-tools-version:5.2 because 5.2 contains SwiftPM fixes around test dependencies. #784

andersio

comment created time in a month

push eventReactiveCocoa/ReactiveCocoa

Anders Ha

commit sha d805976d27433f61bc8199c999230ccb81ed91d2

Ditto

view details

push time in a month

push eventReactiveCocoa/ReactiveSwift

Michael Brown

commit sha 58d92aa01081301549c48a4049e215210f650d07

Add Rx migration cheatsheet (#793)

view details

push time in a month

PR merged ReactiveCocoa/ReactiveSwift

Add Rx migration cheatsheet

Checklist

  • [ ] Updated CHANGELOG.md. Not updated as it's just a documentation addition.
+124 -3

0 comment

2 changed files

mluisbrown

pr closed time in a month

PR opened ReactiveCocoa/ReactiveSwift

Stop declaring Swift 5.0 support.

We have adopted @propertyWrapper which requires Swift 5.1+.

Checklist

  • Updated CHANGELOG.md.
+1 -1

0 comment

1 changed file

pr created time in a month

create barnchReactiveCocoa/ReactiveSwift

branch : anders/podspec

created branch time in a month

push eventReactiveCocoa/ReactiveCocoa

Anders Ha

commit sha 14c69f81068514434189e0de6bc11c7567b5d979

Move CI to Xcode 11.4.

view details

push time in a month

push eventReactiveCocoa/ReactiveCocoa

Anders Ha

commit sha d368dc175ef5025af9b0746f1d16b0aeb16d8446

Move .swift-version to 5.1. [skip ci]

view details

push time in a month

push eventReactiveCocoa/ReactiveCocoa

Anders Ha

commit sha 42f1c402adc95fcc7c9ea36647f5538224a57af4

Remove WKInterfaceActivityRing.swift from build settings.

view details

push time in a month

startedAzoy/Echo

started time in a month

issue commentReactiveCocoa/ReactiveCocoa

App rejected for HealthKit metadata

We will release a major version with it removed ASAP. 👍

Oni-zerone

comment created time in a month

push eventReactiveCocoa/ReactiveCocoa

Anders Ha

commit sha b13f8b06dd12fd79a0a53456a468fadb73f9324f

Update Changelog.

view details

push time in a month

PR opened ReactiveCocoa/ReactiveCocoa

Remove binding for WKInterfaceActivityRing

This causes ReactiveCocoa to link with HealthKit when building for watchOS.

We will release a major version for its removal, and provide no replacement initially other than a suggestion for affected users to define the extension in their own project.

Checklist

  • [ ] Updated CHANGELOG.md.
+0 -15

0 comment

1 changed file

pr created time in a month

create barnchReactiveCocoa/ReactiveCocoa

branch : anders/remove-healthkit-linkage

created branch time in a month

issue commentReactiveCocoa/ReactiveCocoa

App rejected for HealthKit metadata

Hmm that's not right on our end. We shouldn't have included it akin to the rationale behind the separation done for MapKit.

Oni-zerone

comment created time in a month

issue commentReactiveCocoa/ReactiveSwift

[__SwiftNativeNSError release]: message sent to deallocated instance 0x600000c83160

Do you use ReactiveCocoa? Could you please show the complete stack trace?

marosoaie

comment created time in a month

push eventReactiveCocoa/ReactiveSwift

Michael Brown

commit sha f03713963f759c46a6bbec2bc3e717f4877c0d92

Add reactiveswift-composable-architecture to Extended Modules (#791)

view details

push time in a month

PR merged ReactiveCocoa/ReactiveSwift

Add reactiveswift-composable-architecture to Extended Modules

Checklist

  • [ ] Updated CHANGELOG.md.

Didn't update CHANGELOG.md as AFAIK that's not required for a README change.

+9 -0

0 comment

1 changed file

mluisbrown

pr closed time in a month

delete branch ReactiveCocoa/ReactiveSwift

delete branch : update-quick-and-nimble

delete time in a month

push eventReactiveCocoa/ReactiveSwift

IKEDA Sho

commit sha 0c08efef952b93ada7f25eb64cc08396f42f04a5

Update Quick and Nimble (#790) - https://github.com/Quick/Quick/releases/tag/v2.2.1 - https://github.com/Quick/Nimble/releases/tag/v8.0.9

view details

push time in a month

PR merged ReactiveCocoa/ReactiveSwift

Update Quick and Nimble
  • https://github.com/Quick/Quick/releases/tag/v2.2.1
  • https://github.com/Quick/Nimble/releases/tag/v8.0.9

Checklist

  • ~[ ] Updated CHANGELOG.md.~
+12 -12

0 comment

6 changed files

ikesyo

pr closed time in a month

push eventReactiveCocoa/Loop

Anders Ha

commit sha 0e845ad1e3f876db419649d534de79b392dfc6bf

@LoopBinding and @EnvironmentLoop for SwiftUI.

view details

Anders Ha

commit sha b6beb6b28e779db024b60a67a7e015a41b7af72b

Conditional import for building with earlier SDKs.

view details

Anders Ha

commit sha e4d65d788c73ecd46e0afd49d015da46d3f8ac3a

Use `@Published` in SwiftUISubscription.

view details

Anders Ha

commit sha 2a29ae753441889a1678af92bfc6d275497cde08

Split subscription logic.

view details

Anders Ha

commit sha 49404fc7a2142021dfc06c7551558027d76f744c

Merge pull request #11 from ReactiveCocoa/anders/swiftui @LoopBinding and @EnvironmentLoop for SwiftUI.

view details

push time in a month

PR merged ReactiveCocoa/Loop

@LoopBinding and @EnvironmentLoop for SwiftUI. enhancement

Introduce two property wrappers, @LoopBinding and @EnvironmentLoop, for SwiftUI integration as described in #2.

Two simple stepper examples are added to validate the concepts. They shall be replaced with more elaborate examples.

+413 -1

0 comment

14 changed files

andersio

pr closed time in a month

startedtrading-point/swift-composable-architecture

started time in a month

push eventReactiveCocoa/Loop

Anders Ha

commit sha b6beb6b28e779db024b60a67a7e015a41b7af72b

Conditional import for building with earlier SDKs.

view details

Anders Ha

commit sha e4d65d788c73ecd46e0afd49d015da46d3f8ac3a

Use `@Published` in SwiftUISubscription.

view details

Anders Ha

commit sha 2a29ae753441889a1678af92bfc6d275497cde08

Split subscription logic.

view details

push time in a month

Pull request review commentReactiveCocoa/Loop

@LoopBinding and @EnvironmentLoop for SwiftUI.

+import SwiftUI+import Combine+import ReactiveSwift++@available(macOS 10.15, iOS 13.0, tvOS 13.0, watchOS 6.0, *)+@propertyWrapper+public struct LoopBinding<State, Event>: DynamicProperty {+    @ObservedObject+    private var subscription: SwiftUISubscription<State, Event>++    private let loop: Loop<State, Event>++    @inlinable+    public var wrappedValue: State {+        acknowledgedState+    }++    public var projectedValue: LoopBinding<State, Event> {+        self+    }++    @usableFromInline+    internal var acknowledgedState: State!++    public init(_ loop: Loop<State, Event>) {+        // The subscription can be copied without restrictions.+        self.subscription = SwiftUISubscription()

Doesn't work with @EnvironmentLoop.

andersio

comment created time in a month

Pull request review commentReactiveCocoa/Loop

@LoopBinding and @EnvironmentLoop for SwiftUI.

+import SwiftUI+import Combine+import ReactiveSwift++@available(macOS 10.15, iOS 13.0, tvOS 13.0, watchOS 6.0, *)+internal final class SwiftUISubscription<State, Event>: ObservableObject {+    let objectWillChange = ObservableObjectPublisher()+    var latestValue: State!

IUO is intentional to support both @LoopBinding and @EnvironmentLoop. There is no initial state to being with for @EnvironmentLoop, because the actual loop object does not come until the first call of mutating func update().

andersio

comment created time in a month

Pull request review commentReactiveCocoa/Loop

@LoopBinding and @EnvironmentLoop for SwiftUI.

+import SwiftUI+import Combine+import ReactiveSwift++@available(macOS 10.15, iOS 13.0, tvOS 13.0, watchOS 6.0, *)+@propertyWrapper+public struct LoopBinding<State, Event>: DynamicProperty {+    @ObservedObject+    private var subscription: SwiftUISubscription<State, Event>++    private let loop: Loop<State, Event>++    @inlinable+    public var wrappedValue: State {+        acknowledgedState+    }++    public var projectedValue: LoopBinding<State, Event> {+        self+    }++    @usableFromInline+    internal var acknowledgedState: State!++    public init(_ loop: Loop<State, Event>) {+        // The subscription can be copied without restrictions.+        self.subscription = SwiftUISubscription()+        self.loop = loop+    }++    public mutating func update() {+        if subscription.hasStarted == false {+            subscription.attach(to: loop)+        }++        acknowledgedState = subscription.latestValue+    }++    public func scoped<ScopedState, ScopedEvent>(+        to value: KeyPath<State, ScopedState>,+        event: @escaping (ScopedEvent) -> Event+    ) -> LoopBinding<ScopedState, ScopedEvent> {+        LoopBinding<ScopedState, ScopedEvent>(loop.scoped(to: value, event: event))+    }++    public func send(_ event: Event) {+        loop.send(event)+    }

that's an additive functionality that needs designing, esp conversion/relationship of the KeyPaths and Event.

andersio

comment created time in a month

Pull request review commentReactiveCocoa/Loop

@LoopBinding and @EnvironmentLoop for SwiftUI.

+import SwiftUI

Only if we need to support building with Xcode 10 and earlier.

andersio

comment created time in a month

starteddaltoniam/Starscream

started time in a month

pull request commentReactiveCocoa/Loop

Propagate events with state for feedbacks

Could you add unit tests to assert that events are flowing in the order as expected?

sergdort

comment created time in a month

Pull request review commentReactiveCocoa/Loop

Propagate events with state for feedbacks

 extension Loop {             skippingRepeated transform: @escaping (State) -> Control?,             effects: @escaping (Control) -> Effect         ) where Effect.Value == Event, Effect.Error == Never {-            self.init(compacting: { $0.map(transform).skipRepeats() },-                      effects: { $0.map(effects)?.producer ?? .empty })+            self.init(+                compacting: { $0.map(transform).skipRepeats() },+                effects: { $0.map(effects)?.producer ?? .empty }+            )+        }++        public static func skippingRepeated<Control: Equatable, Effect: SignalProducerConvertible>(

If that's the case, I'd prefer not to duplicate the implementation. We should implement one of them in terms of another.

sergdort

comment created time in a month

Pull request review commentReactiveCocoa/Loop

Propagate even with state for feedbacks

 extension Loop {             compacting transform: @escaping (SignalProducer<State, Never>) -> SignalProducer<U, Never>,             effects: @escaping (U) -> Effect         ) where Effect.Value == Event, Effect.Error == Never {-            self.events = { state, output in+            events = { state, output in                 // NOTE: `observe(on:)` should be applied on the inner producers, so                 //       that cancellation due to state changes would be able to                 //       cancel outstanding events that have already been scheduled.-                transform(state)+                transform(state.map(\.0))+                    .flatMap(.latest) { effects($0).producer.enqueue(to: output) }+                    .start()+            }+        }++        /// Creates a Feedback which re-evaluates the given effect every time the+        /// `Signal` derived from the latest state yields a new value.+        ///+        /// If the previous effect is still alive when a new one is about to start,+        /// the previous one would automatically be cancelled.+        ///+        /// - parameters:+        ///   - transform: The transform which derives a `Signal` of values from the+        ///                latest state.+        ///   - effects: The side effect accepting transformed values produced by+        ///              `transform` and yielding events that eventually affect+        ///              the state.+        public static func compacting<U, Effect: SignalProducerConvertible>(

perhaps we should deprecate the init equivalents in favor of static factory API?

sergdort

comment created time in a month

issue commentCarthage/Carthage

Adding `--build-for-distribution` option to enable module stability on consumer-side

As a framework user, I have made a in-house prototype to build 40+ dependencies (including RAS/RAC) under BUILD_LIBRARIES_FOR_DISTRIBUTION=YES using a custom tool, and build & run the unit test suites against them. However, I haven't tested use of XCFrameworks beyond this.

As a framework author, I am struggling to understand why packages distributed primarily as sources should enable BUILD_LIBRARIES_FOR_DISTRIBUTION=YES, even if we are to guarantee module stability.

Quoting the official Swift blogpost:

https://swift.org/blog/library-evolution/

Frameworks that are always built and distributed together, such as Swift Package Manager packages or binary frameworks that are internal to your app, should not be built with library evolution support.

Building always with the Library Evolution mode will impose a resilience boundary on the module, which comes with the runtime overhead that shouldn't be incurred when built from source. IMO CocoaPods appears to have chosen to mark transitive source dependencies of any XCFramework with BUILD_LIBRARIES_FOR_DISTRIBUTION=YES, so that they are built in Library Evolution mode only when required.

ikesyo

comment created time in a month

delete branch andersio/ReactiveTimelane

delete branch : patch-1

delete time in a month

push eventReactiveCocoa/ReactiveSwift

Anders Ha

commit sha 3a925fa8e3225491c376466344be20eb862c83e1

Move to SwiftPM tools version 5.2. (#784) * Move to SwiftPM tools version 5.2. * Bump .swift-version to 5.2.

view details

Anders Ha

commit sha 172d31b47c9aad3fe41ff63c7cda96811482ede5

Documentation and tests for the opt-in empty sentinel for sequence-of-streams operators. (#782) * Update the documentation & rename `noUpstreamSentinal` to `emptySentinel`. * Add tests. * Fix indentation.

view details

Anders Ha

commit sha 9504c5f365273cd6542abbe457fe7a1f83b4c2e3

Remove .swift-version when verifying podspec (#787)

view details

Anders Ha

commit sha 3f4351d04115fd8797802d9b2d17b812cd761602

6.3.0

view details

Anders Ha

commit sha 4772e16155f44ebf905de057507c1fb39b030e12

Restructure readme to incorporate a list of "extended modules". [skip ci] (#789)

view details

Anders Ha

commit sha a3e2da9b34ce232b97b6579d38a8122702fc7d66

Be more tolerate with error code returned by `pthread_mutex_trylock`. (#788) * Be more tolerate with error code returned by `pthread_mutex_trylock`. * Update changelog.

view details

Anders Ha

commit sha 44373e09673507bcccc98469da0a992adc0974df

Merge branch 'master' into anders/rename-throttle

view details

push time in a month

delete branch ReactiveCocoa/ReactiveSwift

delete branch : anders/atomic-try-fix

delete time in a month

push eventReactiveCocoa/ReactiveSwift

Anders Ha

commit sha a3e2da9b34ce232b97b6579d38a8122702fc7d66

Be more tolerate with error code returned by `pthread_mutex_trylock`. (#788) * Be more tolerate with error code returned by `pthread_mutex_trylock`. * Update changelog.

view details

push time in a month

PR merged ReactiveCocoa/ReactiveSwift

Be more tolerate with error code returned by `pthread_mutex_trylock`. bug

It seems EDEADLK could be returned by pthread_mutex_trylock in earlier OS versions, according to #747. Let's add it to the known happy path.

Checklist

  • [x] Updated CHANGELOG.md.
+5 -1

0 comment

2 changed files

andersio

pr closed time in a month

create barnchReactiveCocoa/ReactiveSwift

branch : anders/rasx

created branch time in a month

pull request commentReactiveCocoa/ReactiveSwift

AsyncValue POC

Hi, sorry for the long hiatus on this large and important topic.

I have been drafting on and off an implementation strategy, as part of a new overhaulling initiative, to bring in both cold and hot streams-of-one based on concepts from #722. It should hopefully address value proposition and implementation/maintainance concerns of these primitives, that were brought up in previous discussions. It also make use of Swift's generic system to its full extent (and potentially upcoming features e.g. parameterized extensions). I really appreciate your devotion in prototyping these ideas, and your arguments are a valuable angle for evaluating several possible approaches. 🙇

leonid-s-usov

comment created time in a month

delete branch ReactiveCocoa/ReactiveSwift

delete branch : as-error-convertible

delete time in a month

PR closed ReactiveCocoa/ReactiveSwift

Add attempt and attemptMap overloads for ErrorConvertible

This allows consumers to use throwable closures with their own custom ErrorConvertible types, not just with AnyError.

  • [ ] Add tests for various type inference scenarios https://github.com/ReactiveCocoa/ReactiveSwift/pull/626#pullrequestreview-108491025
  • [ ] Updated CHANGELOG.md.
+143 -16

2 comments

4 changed files

sharplet

pr closed time in a month

pull request commentReactiveCocoa/ReactiveSwift

Add attempt and attemptMap overloads for ErrorConvertible

Closing since antitypical/Result is no longer a RAS dependency.

sharplet

comment created time in a month

more