| .. |
|
ApiCompare
|
6bbf23237b
TFM updates. ArrayEmpty
|
7 years ago |
|
Benchmarks.System.Interactive
|
ed7bc62379
Undo benchmark, undo Finally
|
7 years ago |
|
FasterLinq
|
6bbf23237b
TFM updates. ArrayEmpty
|
7 years ago |
|
Playground
|
6bbf23237b
TFM updates. ArrayEmpty
|
7 years ago |
|
System.Interactive
|
14a1dba258
IxCS8: Allow Share to be disposed
|
7 years ago |
|
System.Interactive.Async
|
aacb761f40
Switch to ValueTask for predicates, selectors, etc. We await those ourselves and they are expected to be called in a high-frequency manner, so this seems to be the right choice. The only drawback is when these operators are used using method group conversion of a Task-returning async method, which is likely rare in query expressions where one typically uses (async) lambdas, and there's a workaround Task-to-ValueTask conversion. We can't overload on ValueTask and Task return types, so this seems the best way forward.
|
7 years ago |
|
System.Interactive.Async.Providers
|
aacb761f40
Switch to ValueTask for predicates, selectors, etc. We await those ourselves and they are expected to be called in a high-frequency manner, so this seems to be the right choice. The only drawback is when these operators are used using method group conversion of a Task-returning async method, which is likely rare in query expressions where one typically uses (async) lambdas, and there's a workaround Task-to-ValueTask conversion. We can't overload on ValueTask and Task return types, so this seems the best way forward.
|
7 years ago |
|
System.Interactive.Async.Providers.Tests
|
aacb761f40
Switch to ValueTask for predicates, selectors, etc. We await those ourselves and they are expected to be called in a high-frequency manner, so this seems to be the right choice. The only drawback is when these operators are used using method group conversion of a Task-returning async method, which is likely rare in query expressions where one typically uses (async) lambdas, and there's a workaround Task-to-ValueTask conversion. We can't overload on ValueTask and Task return types, so this seems the best way forward.
|
7 years ago |
|
System.Interactive.Async.Tests
|
35baf55cdc
Add test for Throw.
|
7 years ago |
|
System.Interactive.Providers
|
0ae1af3798
Fix build error
|
7 years ago |
|
System.Interactive.Tests
|
6bbf23237b
TFM updates. ArrayEmpty
|
7 years ago |
|
System.Linq.Async
|
aacb761f40
Switch to ValueTask for predicates, selectors, etc. We await those ourselves and they are expected to be called in a high-frequency manner, so this seems to be the right choice. The only drawback is when these operators are used using method group conversion of a Task-returning async method, which is likely rare in query expressions where one typically uses (async) lambdas, and there's a workaround Task-to-ValueTask conversion. We can't overload on ValueTask and Task return types, so this seems the best way forward.
|
7 years ago |
|
System.Linq.Async.Queryable
|
aacb761f40
Switch to ValueTask for predicates, selectors, etc. We await those ourselves and they are expected to be called in a high-frequency manner, so this seems to be the right choice. The only drawback is when these operators are used using method group conversion of a Task-returning async method, which is likely rare in query expressions where one typically uses (async) lambdas, and there's a workaround Task-to-ValueTask conversion. We can't overload on ValueTask and Task return types, so this seems the best way forward.
|
7 years ago |
|
System.Linq.Async.Queryable.Tests
|
aacb761f40
Switch to ValueTask for predicates, selectors, etc. We await those ourselves and they are expected to be called in a high-frequency manner, so this seems to be the right choice. The only drawback is when these operators are used using method group conversion of a Task-returning async method, which is likely rare in query expressions where one typically uses (async) lambdas, and there's a workaround Task-to-ValueTask conversion. We can't overload on ValueTask and Task return types, so this seems the best way forward.
|
7 years ago |
|
System.Linq.Async.Tests
|
7184e4f28a
Remove CreateEnumerator.
|
7 years ago |
|
build
|
0aaa781c42
use as tool
|
7 years ago |
|
refs
|
6bbf23237b
TFM updates. ArrayEmpty
|
7 years ago |
|
CodeCoverage.runsettings
|
d18ec867ec
Update code coverage filter
|
7 years ago |
|
Directory.build.props
|
347b5aacbb
Merge branch 'master' into IxAsyncCSharp8
|
7 years ago |
|
Directory.build.targets
|
6bbf23237b
TFM updates. ArrayEmpty
|
7 years ago |
|
Ix.Async.NET.sln
|
1362fd4d81
Add minimal solution for Ix.Async.
|
7 years ago |
|
Ix.NET.sln
|
347b5aacbb
Merge branch 'master' into IxAsyncCSharp8
|
7 years ago |
|
ReactiveX.snk
|
a2f10c9a1e
Change the strong name signing key; check in new one.
|
9 years ago |
|
global.json
|
d4dde5f89a
Update extras
|
7 years ago |
|
version.json
|
c279f09ea5
remove extra config
|
7 years ago |
Bart De Smet
aacb761f40
Switch to ValueTask for predicates, selectors, etc. We await those ourselves and they are expected to be called in a high-frequency manner, so this seems to be the right choice. The only drawback is when these operators are used using method group conversion of a Task-returning async method, which is likely rare in query expressions where one typically uses (async) lambdas, and there's a workaround Task-to-ValueTask conversion. We can't overload on ValueTask and Task return types, so this seems the best way forward.