These are chat archives for ReactiveX/RxJava

4th
Nov 2015
johnfoconnor
@johnfoconnor
Nov 04 2015 00:46
is there a way to force an observable to emit it's result(s) "naturally" as a return value instead of as a callback within subscribe?
result = Observable.Range(1, 3).Sum().subscribeAndReturn()
print(result)  // 6
Artem Zinnatullin :slowpoke:
@artem-zinnatullin
Nov 04 2015 01:06

no natural way, because it's a model of work — Observable pushes data to you.

You can block unit it finish via toBlocking

johnfoconnor
@johnfoconnor
Nov 04 2015 01:44
sure, it just seems more intuitive in certain cases to avoid the callback mess. especially for something like myArray = Observable.Range(1, 3).toArray()
obviously it would be toBlocking under the covers
Dorus
@Dorus
Nov 04 2015 09:51
tbh if you do not need any of the async properties of rx, rx is probably not the right tool for the job.
There are ways to use it ofcourse, but it's never "natural".
David Stemmer
@weefbellington
Nov 04 2015 18:47

@Dorus updated the previous gist to use scan, thanks for the input:

source.scan(new HashMap<>(), (output, data) -> {
    output.put(data.id, data.content);
    return output;
}).sample(1, TimeUnit.SECONDS).subscribe(output -> System.out.println(output));

https://gist.github.com/weefbellington/952414cb7076976bfd49

@pakoito @artem-zinnatullin ^ in case you are still interested in this puzzle :)
Dorus
@Dorus
Nov 04 2015 20:01
@weefbellington The only thing to keep in mind is that output.put has side effects, and you are emitting the same collection every time, since sample might allows the previous operators to run concurrent, output might receive new put calls during the onNext call in subscribe. Might be a good idea to use ConcurrentHashMap or clone the collection somewhere.
Your previous example only updated the collection once every second, so this was less problematic.
Paco
@pakoito
Nov 04 2015 20:29
@weefbellington Hey, many thanks for the snippet. Sorry I have been out of the chat, I need to get a desktop client.
I went through the second example and it seems to fit the bill. I can also add an extra signal to have an invalidation policy for data that's not fresh :)
like every 5 seconds add a signal that vacates those positions whose timestamped value is older than 5 seconds
David Stemmer
@weefbellington
Nov 04 2015 21:30
@Dorus good point. I might be a little worried about the efficiency of cloning a new HashMap with each emission. I know that languages like Haskell that don't have mutable data structures are really good at creating a lot of them at once and then recollecting the memory, but I don't know how Java would handle it. So I'd probably go with the ConcurrentHashMap
Paco
@pakoito
Nov 04 2015 22:22
Java is very inefficient when cloning maps, and there's no memory sharing libs out there. It is possible within the JVM tho, as Clojure and other languages have them.
Even worse on Dalvick/ART tho.
Artem Zinnatullin :slowpoke:
@artem-zinnatullin
Nov 04 2015 22:23
Wait, what do you mean by "very inefficient"? Collections just stores references to the objects, not the objects themselves, copy == more references
Paco
@pakoito
Nov 04 2015 22:41
I would doublecheck that, or else the shared memory concept would be pointless.
me or you
Artem Zinnatullin :slowpoke:
@artem-zinnatullin
Nov 04 2015 22:42
idk what exactly you mean by "shared memory concept" :)
Paco
@pakoito
Nov 04 2015 22:44

Sharing is Cheap

If you are certain that an object will never change, then sharing said object becomes a simple matter of providing a reference to it. In Java to do so often requires a lot of defensive copying. Along this vein, because we can freely share references for immutable objects we can likewise intern them for free.

Artem Zinnatullin :slowpoke:
@artem-zinnatullin
Nov 04 2015 22:45
First part about sharing is correct
but
I'm afraid I'll disappoint you: in Java we don't have to implement Cloneable so there is no way to do defensive copy for the runtime
I mean, JVM/JDK don't do defensive copies
Paco
@pakoito
Nov 04 2015 22:47
I just need to find the correct snippet for you to believe me, but the one thing I know about clojure is that their collections are better suited for immutability than plan java ones
Artem Zinnatullin :slowpoke:
@artem-zinnatullin
Nov 04 2015 22:49
Clojure has own collections afaik and since it's fp-only (+-) lang — every clojure object is immutable, so yes they work with immutability better
But it does not make Java inefficient since you can do both mutable and immutable behavior (because sometimes mutability gives much higher performance)
Paco
@pakoito
Nov 04 2015 22:50
when copying we're talking here, as in, trying to create a new collection from an old one
Artem Zinnatullin :slowpoke:
@artem-zinnatullin
Nov 04 2015 22:51
@pakoito just put some object with mutable field into collection and copy the collection then change field of the object and see that both collections work with same object and same value of its mutable field
@pakoito yep, they can do funny things with copying algorithm since everything is immutable, but it's possible in Java too (though there are not standard implementations of such collections in the JDK)
Paco
@pakoito
Nov 04 2015 22:52
so you do agree that for the case above maybe copying is not the best approach, at least with standard Java's collections
Artem Zinnatullin :slowpoke:
@artem-zinnatullin
Nov 04 2015 22:53
depends on usage case :)
Paco
@pakoito
Nov 04 2015 22:53
goddamnit
10 updates a second, potentially 50 different ids
10 up/sec each
Artem Zinnatullin :slowpoke:
@artem-zinnatullin
Nov 04 2015 22:54
10 up/sec is nothing
Paco
@pakoito
Nov 04 2015 22:55
500 up/sec on an Android device hammering the UI thread?
unbatched*
Artem Zinnatullin :slowpoke:
@artem-zinnatullin
Nov 04 2015 22:55
not really, 1-2 ms on non-top device, I guess
Paco
@pakoito
Nov 04 2015 22:55
I've had up to 1k per second, but it's a battery drain
Artem Zinnatullin :slowpoke:
@artem-zinnatullin
Nov 04 2015 22:55
if the only thing you do is emitting items w/o processing
Paco
@pakoito
Nov 04 2015 22:56
you are proicessing tho
David Stemmer
@weefbellington
Nov 04 2015 22:56
wouldn't you only be observing on the UI thread?
Paco
@pakoito
Nov 04 2015 22:56
the stuff you get is a raw string, serializes to object, then you analize
Artem Zinnatullin :slowpoke:
@artem-zinnatullin
Nov 04 2015 22:56
^
go out from UI thread then!
Paco
@pakoito
Nov 04 2015 22:56
yeah the ops happen on the background, but if they come individually on ui they go to the ui dispatch queue
which pile against ui updates
500 per second
and it may end up in "your app is doing too much, skipped 10 frames"
I've had a case once where the object churning was so hard there were several (as in 10-20) GCs per second, and each was 2 frames skipped
but that was buggy code someone else wrote
David Stemmer
@weefbellington
Nov 04 2015 22:59
@pakoito even when you call sample?
Paco
@pakoito
Nov 04 2015 22:59
not with sample
that's what I'm saying
batched it's safe
David Stemmer
@weefbellington
Nov 04 2015 22:59
ah I see
Paco
@pakoito
Nov 04 2015 23:02
@artem-zinnatullin http://pcollections.org/
Artem Zinnatullin :slowpoke:
@artem-zinnatullin
Nov 04 2015 23:03
@pakoito thanks for the link!
David Stemmer
@weefbellington
Nov 04 2015 23:04
@pakoito yeah, looks cool
I’ve played around with guava immutable collections but they’re a bit awkward
and guava is kind of a monolithic library
Artem Zinnatullin :slowpoke:
@artem-zinnatullin
Nov 04 2015 23:05
@pakoito @weefbellington another approach — "Solid" https://github.com/konmik/solid
I like that it brings Streams-like operations, though hadn't used it yet
KONMIIIIIK!!!
Artem Zinnatullin :slowpoke:
@artem-zinnatullin
Nov 04 2015 23:06
Yep :) btw he lives in my town, guess I'll met him oneday
Paco
@pakoito
Nov 04 2015 23:06
don't forget to send a picture to Jake to put in his backlist album
I clash with Konmik in/r/androiddev. Not as often as we used to tho :P
different opinions on MVP
Artem Zinnatullin :slowpoke:
@artem-zinnatullin
Nov 04 2015 23:08
oh yeah, Konmik is much more opinionated than me. // russians…