Fork me on GitHub
#clojure
<
2019-08-10
>
g00:08:26

has anyone done anything related to profiling production code that doesn’t involve directly tagging functions inline? for example, i have a sort of embryonic idea involving, perhaps, a middleware-like construct that reloads function bodies with their tagged versions in accordance with some kind of configuration info

g00:08:10

basically the idea is i want to keep tabs on the performance of larger pieces of code, in the knowledge that their internals are probably subject to a lot of churn (which will get worse if i have to add in the cost of readjusting the profiling tags every time they change)

g00:08:48

i guess another option would be to create some kind of internal api that i can ping and will simply return the performance info of a certain function given an input

g01:08:31

in general i like tufte, but am trying to investigate some cleaner ways of integrating it into a production codebase

sogaiu02:08:08

@gtzogana i don't have it fully implemented but i've been working on an approach that involves source code modification to insert and remove instrumentation such as logging, performance measurement, etc.

sogaiu02:08:18

this approach is meant to be automated so the instrumentation does not get added or removed manually. it should also work for the 3 clojures - jvm, clr, and js.

sogaiu02:08:10

perhaps you would count this as directly tagging functions inline though.

murtaza5204:08:49

@jahson @noisesmith @alexmiller - thanks for the help. yes the bug was that the reducing function uses a reduce-kv for a hash-map, while my f was assuming reduce.

Silenced Ego05:08:02

I'm trying to use asynchronous streams in clojurescript. Should I interop with RxJS, use core.asyc, or something else?

dominicm06:08:50

Those 2 libraries provide very different functionality

Silenced Ego06:08:17

hm really? how is use case different

dominicm06:08:11

rxjs is about reactive programming, core.async promises much less, simply giving channels.

dominicm06:08:29

rxjs is a higher-level abstraction I believe.

Silenced Ego06:08:17

i'm writing an app that reacts to data coming in from a socket, processes it asynchronously in a few ways and puts it in a database. I thought RxJS was pretty nice for this, but I would prefer to do things the most idiomatic way for clojurescript if possible. Which tool do you think I should use?

dominicm06:08:40

do you mind if you lose data you've accepted when your server goes down?

Silenced Ego06:08:29

occasionally missing periods of data is fine for my app

dominicm06:08:00

then core.async is probably fine, yeah. Although tbh, you could probably get away with just using callbacks.

Silenced Ego06:08:58

what about call back hell? I know that happens in JS and that's why promises were invented. I'm new to clojurescript

dominicm06:08:01

for this use-case, this is fine.

dominicm06:08:46

call back "hell" is really just about this:

(foo (fn [result]
      (bar result (fn [result2]
                           (baz result2 (fn [result3])))))
and so on

Silenced Ego06:08:53

do you know if core.async can play nicely with JS promises in case I must interop ?

dominicm06:08:26

You will need to bridge them

dominicm06:08:43

but js promises are quite nice to use directly via interop, instead of bridging to promises

murtaza5206:08:38

@U09LZR36F by loss of data, do you mean that the db goes down, and the js is not able to write to it ?

dominicm06:08:14

@UMA62JW4W I mean that if you read from a socket, and your only queue is core.async, then if your application goes down that whole queue is lost.

dominicm06:08:26

As opposed to e.g. a durable queue like sqs or something.

murtaza5206:08:12

makes sense, however if he is reading or getting msgs from a durable queue in the first place, he could use an offset that is saved to a cache … so next time when the app comes up it knows where to resume from

dominicm06:08:48

potentially, yes. This is a pretty broad space with a wide range of levels of guarantees and parallelism required.

dominicm06:08:02

e.g. some durable queues don't have replay. Once delivered they delete the message.

Silenced Ego07:08:51

I have to perform some asynchronous tasks like group the data by the minute coming in from the socket. In RxJS this is pretty easy, I just connect the socket to an observable that emits only once per minute based on the data which has timestamps on it. I think this is possible to do this with call backs, but then I think I lose the nice looking composibility of RxJS pipelines. Can transducers in core.async do the same thing?

dominicm07:08:06

not really, rxjs is much nicer for that kind of thing

dominicm07:08:32

they can, there might be a library around for it even, but I don't often see that kind of windowing.

murtaza5207:08:13

Can using a timeout and alt/alts achieve the same thing in core.async ?

murtaza5207:08:28

I mean core.async/timeout

dominicm07:08:04

Yeah. You can definitely build this functionality on top of core.async, but core.async is a lower-level set of building blocks

g15:08:07

i’ll give it a try, thanks @schmee