mattgallagher / cwlsignal Goto Github PK

Hi,
I am facing issue below while trying to upgrade my app with Xcode 12.4. Please add support for Xcode 12 .

Undefined symbols for architecture armv7: "type metadata accessor for CwlUtils.(DequeBuffer in _205C59B1D6FDABD6FAE37E9199C346A4)", referenced from: CwlSignal.Signal.(resumeIfPossibleInternal in _ACD91BA4CE4CE61201EA964A7D8CD939)(dw: inout CwlUtils.DeferredWork) -> () in CwlSignal.o CwlSignal.Signal.(pop in _ACD91BA4CE4CE61201EA964A7D8CD939)() -> Swift.Result<A, CwlSignal.SignalEnd>? in CwlSignal.o CwlSignal.Signal.(specializedSyncPop in _ACD91BA4CE4CE61201EA964A7D8CD939)() -> () in CwlSignal.o ld: symbol(s) not found for architecture armv7 clang: error: linker command failed with exit code 1 (use -v to see invocation)

With Xcode 9 beta 2 with new build system enabled, I get

CodeSign /Users/xxx/Library/Developer/Xcode/DerivedData/xxx-gzzbuuauubqaczemizsmdnorzrub/Build/Products/Debug-iphonesimulator/CwlUtils.framework
    cd /Users/xxx/Projects/xxx/xxx-iOS/Vendor/CwlSignal
    export CODESIGN_ALLOCATE=/Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate
    /usr/bin/codesign --force --sign - --timestamp=none /Users/xxx/Library/Developer/Xcode/DerivedData/xxx-gzzbuuauubqaczemizsmdnorzrub/Build/Products/Debug-iphonesimulator/CwlUtils.framework

/Users/xxx/Library/Developer/Xcode/DerivedData/xxx-gzzbuuauubqaczemizsmdnorzrub/Build/Products/Debug-iphonesimulator/CwlUtils.framework: bundle format unrecognized, invalid, or unsuitable
Command CodeSign failed with a nonzero exit code

I include the framework manually, following all steps from the current README.
Also with old build system enabled the project builds successfully.

Great library, thanks for sharing!

I've been checking out the playground, and I noticed that the text on the page "Parallel composition - combine" doesn't seem to match the code — it's more or less identical to the text on the "transform" page.

The following code deadlocks when signal2 is created:

let context = Exec.asyncQueue()

let signal1 = Signal.from(sequence: [1])
    .continuous()

let signal2 = signal1
    .map(context: context) { 2*$0 }
    .continuous()

queue.sync is called when already executing on queue.

I believe this was introduced in the 2.0 refactoring.

Trying to install 2.0.0-beta.8 through Carthage with Xcode 8.3.3:

ld: bitcode bundle could not be generated because '/Users/zoul/Library/Caches/org.carthage.CarthageKit/DerivedData/CwlSignal/2.0.0-beta.8/Build/Products/Release-iphoneos/CwlUtils.framework/CwlUtils' was built without full bitcode. All frameworks and dylibs for bitcode must be generated from Xcode Archive or Install build for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Am I doing something wrong? I tried 1.x, but that also fails to install through Carthage for a different reason.

Seems that CwlUtils.framework shouldn't be placed there.

I'm probably missing something very obvious, but when I try and install CwlSignal with Carthage, I'm getting many compilation errors (from Carthage's xcodebuild log) complaining about the use of the Cancellable type, for example:

CwlSignal/CwlSignal.swift:1226:50: error: use of undeclared type 'Cancellable'
public final class SignalInput<T>: SignalSender, Cancellable {
                                                 ^~~~~~~~~~~

I did some digging in the CwlSignal source, and I can't actually see where that type is declared. Is there some other dependency I should make sure to include first, or something? Or am I just being dense? Any help would be most appreciated. Thanks!

As you did not have published CwlSignal and CwlUtils as CocoaPods public pod, people currently can only point to your github repo if they want to use CwlSignal.

Unfortunately with direct github links you cannot specify version of the pod. Lastest changes in CwlUtils (after Oct25, 2018/2.0 tag) therefore are breaking current CwlSignal pod.

It would be good idea to push stable releases of the CwlUtils and CwlSignal pods to CocoaPods specs repo to let people use stable builds with specified version. See:
https://guides.cocoapods.org/making/getting-setup-with-trunk

First, if you don’t like the idea of the issue tracker being used for questions, feel free to close this. Otherwise:

I have a continuous parent signal that I derive various other signals from. Most of the subscribers are fine with the continuous semantics. But with some subscribers I just want to receive the future values, not the initial ones. Example:

let (input, signal) = Signal<Int>.create { s in s.continuous() }

input.send(value: 1)
input.send(value: 2)

let e1 = signal.subscribeValues { val in
    print("A: \(val)")
}

let e2 = signal.subscribeValues { val in
    print("B: \(val)")
}

input.send(value: 3)

This prints:

A: 2
B: 2
A: 3
B: 3

Now I would like the second subscription not to receive the initial value, ie. the output should look like this:

A: 2
A: 3
B: 3

Is it possible to get that kind of behaviour without tweaking the parent signal? Does it make sense? (Cross-posting from Stack Overflow where I had little success.)

If you build CwlSignal via directly via Xcode, using instructions in CwlSignal's README (or xcodebuild or Carthage and/or Punic) the CFBundleVersion in the built product Info.plist is blank. In the project the CFBundleVersion is defined as "$(CURRENT_PROJECT_VERSION)" which obviously isn't getting populated.

iTunes Connect will reject any framework with a missing CFBundleVersion.

I’ve created a .podspec for CwlSignal so it can be added to the CocoaPods package manager specs.

https://github.com/Ashton-W/CwlSignal

However, CwlSignal doesn't have any version tags. A version tag will make dependency resolution much easier.

Semantic version tags (instead of plain commit hashes/revisions) allow for resolution of cross-dependencies.

In case you didn’t know this yet; you can tag the current HEAD as, for instance, version 1.0.0, like so:

$ git tag -a 1.0.0 -m "Tag release 1.0.0"
$ git push --tags

Matt, please excuse my use of an issue template

Using 2.0.0-beta.15, both CwlSignal and CwlUtil trigger the 'linking against a dylib which is not safe for use in application extensions' warning when being linked into an iMessage extension. Are they in fact not safe for use in extensions, or could 'Require Only App-Extension-Safe API' be set in the framework projects so that Xcode knows everything is good to go?

Hello! The minimum iOS version specified in the project build settings is iOS 8, but the code (specifically CwlSignal.swift) calls os_unfair_lock_unlock(), which (according to the compiler) is not available in < iOS 10. Bumping the iOS deployment target up to iOS 10 fixes the issue and things compile normally. Would it be reasonable at this point to update the project to require iOS 10 at this point?

Hi, I’m trying to execute the test target on macOS. Both Xcode 8 and 9b4 fail, it seems like your personal development team ID is hardcoded in both the local project files and the downloaded dependencies. Do the tests run for you on a vanilla machine/user account?
I might be doing something wrong, though, the whole dependency download and test build chain is quite involved and too clever for me.

No signing certificate "Mac Development" found:  No "Mac Development" signing certificate matching team ID "S7YQ892G6G" with a private key was found.

On your blog post introducing CwlSignal (emphasis added):

CwlSignal is fast; it can deliver multiple millions of values per second synchronously (more than 4 million per second per core on my Mac) and hundreds of thousands of values per second asynchronously (more than 200 000 values per second per core on my Mac). That makes it at least as fast as prominent competitor implementations and in most cases, between 2 and 10 times faster.

Can you provide more detail on how you arrived at this and what specific libraries you were comparing against? It would be great if others could be able to reproduce those results.

I ran into this repo recently and the result were unexpected considering the performance claim. CwlSignal ended up coming last in all tests, in some cases significantly.

I'm not trying to accuse you of misleading. Certainly there are going to be flaws in the way those tests are done*, but currently that's the only comparison of frp libs for ios that I could find.

* In particular, the version of each lib used in that repo had to be updated. One of the tests had to be modified because it was unfairly iterating far more on CwlSignal than others, etc...

Hey Matt!

Not sure if you are cool with questions here, but here's mine. :)

In your post introducing CwlSignal you talk about capturing. I see that using that operator captures the activation values. I see that you can access those using the activation() method, but I'm unclear why doing so blocks future signal delivery.

Cool looking library so far!

Subscribing, canceling and subscribing again doesn't work. The second send always fails.

let (input, signal) = Signal<Int>.create() { $0.multicast() }

let ep1 = signal.subscribeValues { _ in }
assert(input.send(result: .success(1)) == nil)
ep1.cancel()

let ep2 = signal.subscribeValues { _ in }
assert(input.send(result: .success(1)) == nil) // fails with SignalSendError.disconnected
ep2.cancel()

I was preparing to do some leak tests on my code and noticed that Release/Instruments style builds weren't working. Pulled your latest and noticed that you'd changed an area that appeared to play a part, but it's not quite cleared up yet (I'm running Xcode 8.3beta):

/Users/mark/Developer/Analysis/Submodules/CwlSignal/.build/cwl_symlinks/CwlUtils/Sources/CwlUtils/CwlStackFrame.swift:44:35: error: use of unresolved identifier 'frame_address'
                let frame = StackFrame(address: frame_address())

Interestingly, if I remove the conditional OMIT_STACK_FRAME check then, while compile takes an inordinately long time, the build eventually succeeds and I'm able to run Instruments.app leaks.

Hey Matt,

Thanks for releasing CwlSignal - it's been fun to try out over the last couple days.

One difference I noticed between CwlSignal and ReactiveSwift is that errors from flattened inner signals aren't propagated to the outer signal. It looks like this affects flatMap* and concatMap, or maybe wherever a SignalMergeSet is used with closesOutput set to false.

For example, I was expecting this (non-SignalError) error from the inner signal to be emitted:

func testFlatMapPropagatesInnerSignalErrors() {
	var results = [Result<Int>]()
	_ = Signal.fromSequence([1, 2]).flatMap { v in
		return Signal<Int>.generate(context: .direct) { input in
			guard let i = input else { return }
			switch v {
			case 1: i.send(value: v*10)
			case 2: i.send(error: TestError.oneValue) // Expected this error to close / terminate the signal
			default: fatalError()
			}
		}
	}.subscribe { r in
		results.append(r)
	}

	XCTAssert(results.at(0)?.value == 10)
	XCTAssert(results.at(1)?.error as? TestError == .oneValue) // Failed, got SignalError.closed
}

I didn't see a test covering this, so not sure if the behavior is intentional?

The Reactive X documentation for "FlatMap" doesn't spell this out either, but I think it's standard to propagate inner errors in RxJava, etc. as well.

Key paths would make a nice addition to the API, for example on Signal:

func filterMap<U>(_ path: KeyPath<OutputValue, U?>) -> Signal<U> {
    return filterMap { $0[keyPath: path] }
}

Hopefully we will eventually get some kind of keypath ↔︎ function equivalence on the language level, but until then, would you consider adding the overloads for key paths where appropriate?

I'm including CwlSignal as a sub-project, which worked well before the xcode10 merge, since now I can't reference CwlUtils framework in the Copy to Frameworks build step.

Checked out e73f2f4 commit & tried building same project on Xcode 10 beta 1 and can't get past this:

PhaseScriptExecution Run\ Script /Users/---/Library/Developer/Xcode/DerivedData/----gstrjbtdifdhifbzsgokqjsutevz/Build/Intermediates.noindex/CwlSignal.build/Debug-iphoneos/CwlUtils_iOS.build/Script-C9351F8C1F0B6E820038F4E0.sh (in target: CwlUtils_iOS)
    cd /Users/---/Projects/---/----Xcode10/Vendor/CwlSignal
    /bin/sh -c /Users/---/Library/Developer/Xcode/DerivedData/----gstrjbtdifdhifbzsgokqjsutevz/Build/Intermediates.noindex/CwlSignal.build/Debug-iphoneos/CwlUtils_iOS.build/Script-C9351F8C1F0B6E820038F4E0.sh

Build settings from command line:
    ARCHS = arm64
    BITCODE_GENERATION_MODE = marker
    CACHE_ROOT = /var/folders/nv/2btd50sn4973rcvjddc0xp740000gn/C/com.apple.DeveloperTools/10.0-10L176w/Xcode
    DSTROOT = /tmp/CwlSignal.dst
    MODULE_CACHE_DIR = /Users/---/Library/Developer/Xcode/DerivedData/ModuleCache.noindex
    OBJROOT = /Users/---/Library/Developer/Xcode/DerivedData/----gstrjbtdifdhifbzsgokqjsutevz/Build/Intermediates.noindex
    ONLY_ACTIVE_ARCH = YES
    SDKROOT = iphoneos12.0
    SRCROOT = /Users/---/Projects/Framme/----Xcode10/Vendor/CwlSignal
    SYMROOT = /Users/---/Library/Developer/Xcode/DerivedData/----gstrjbtdifdhifbzsgokqjsutevz/Build/Products
    TOOLCHAINS = com.apple.dt.toolchain.XcodeDefault

note: Using new build system
note: Planning build
note: Constructing build description
Build system information
error: unable to attach DB: error: accessing build database "/Users/---/Library/Developer/Xcode/DerivedData/Biketo-gstrjbtdifdhifbzsgokqjsutevz/Build/Intermediates.noindex/XCBuildData/build.db": database is locked Possibly there are two concurrent builds running in the same filesystem location.

** BUILD FAILED **

Five of the playground examples are failing compile. All others are Ok.

BTW: Impressive software and documentation

1. Advanced composition - nested operators

`error: CwlSignal.playground:27:6: error: cannot assign value of type 'SignalChannel<DispatchTimeInterval, SignalMultiInput, Result, SignalMulti<Result>>' to type '(SignalMultiInput, SignalMulti<Result>)'
}.multicast()

`

2. Advanced composition - loopback

`error: CwlSignal.playground:50:29: error: cannot convert value of type 'Result<String>' to expected argument type 'Result<()>'
        loopbackInput.send(result: r)
                                   ^`



3. App scenario - threadsafe key-value storage

`error: CwlSignal.playground:50:5: error: cannot assign value of type 'SignalChannel<DocumentValues.Tuple, SignalInput<DocumentValues.Tuple>, [AnyHashable : Any], SignalMulti<[AnyHashable : Any]>>' (aka 'SignalChannel<(AnyHashable, Optional<Any>), SignalInput<(AnyHashable, Optional<Any>)>, Dictionary<AnyHashable, Any>, SignalMulti<Dictionary<AnyHashable, Any>>>') to type '(SignalInput<DocumentValues.Tuple>, SignalMulti<DocumentValues.Dict>)' (aka '(SignalInput<(AnyHashable, Optional<Any>)>, SignalMulti<Dictionary<AnyHashable, Any>>)')
                }.continuous(initialValue: [:])
~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
`

4. Advanced behaviors - Capturing

`error: CwlSignal.playground:12:45: error: expression type 'SignalChannel<Int, SignalInput<Int>, Int, SignalMulti<Int>>' is ambiguous without more context
let (input, output) = Signal<Int>.channel().continuous()
                      ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~`

5. Parallel composition - merging

`error: CwlSignal.playground:57:16: error: cannot invoke initializer for type 'SignalChannel<_, SignalInput<_>, _, Signal<_>>' with an argument list of type '((input: SignalMergedInput<String>, signal: Signal<String>))'
let mergeSet = SignalChannel(Signal<String>.createMergedInput()).subscribeValuesUntilEnd {
               ^

CwlSignal.playground:57:16: note: overloads for 'SignalChannel<_, SignalInput<_>, _, Signal<_>>' exist with these partially matching parameter lists: (input: Input, signal: Output), ()
let mergeSet = SignalChannel(Signal<String>.createMergedInput()).subscribeValuesUntilEnd {
               ^

error: CwlSignal.playground:38:18: error: use of unresolved identifier 'MultiChannel'
let multiInput = MultiChannel<String>().subscribeValuesUntilEnd {
                 ^~~~~~~~~~~~`

Pleased to say CwlSignal supports Carthage already.

However, it generates the following binaries:

Carthage/
└── Build
    ├── Mac
    │   ├── CwlCatchException.framework
    │   ├── CwlCatchException.framework.dSYM
    │   ├── CwlPreconditionTesting.framework
    │   ├── CwlPreconditionTesting.framework.dSYM
    │   ├── CwlSignal.framework
    │   ├── CwlSignal.framework.dSYM
    │   ├── CwlUtils.framework
    │   └── CwlUtils.framework.dSYM
    ├── iOS
    │   ├── CwlCatchException.framework
    │   ├── CwlCatchException.framework.dSYM
    │   ├── CwlPreconditionTesting.framework
    │   ├── CwlPreconditionTesting.framework.dSYM
    │   ├── CwlSignal.framework
    │   ├── CwlSignal.framework.dSYM
    │   ├── CwlUtils.framework
    │   └── CwlUtils.framework.dSYM
    └── tvOS
        ├── CwlPreconditionTesting.framework
        └── CwlPreconditionTesting.framework.dSYM

Unfortunately Carthage will build the schemes in all projects it finds, including the CwlUtils. Users of this framework only actually need CwlSignal.framework.

We could document this fact for Carthage users. I don't know of a way to control what Cathage builds. Thoughts?

found that swift5.0 is not supported in the latest version 2.1.0

After updating to latest master 0d31f45 build for device crashes due to image not found error.