This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (4)
- # beginners (111)
- # calva (12)
- # cider (10)
- # cljdoc (1)
- # cljs-dev (7)
- # cljsrn (4)
- # clojure (38)
- # clojure-houston (1)
- # clojure-serbia (3)
- # clojure-spec (22)
- # clojure-uk (26)
- # clojurescript (4)
- # cursive (1)
- # data-science (1)
- # datomic (12)
- # klipse (1)
- # off-topic (28)
- # pathom (9)
- # protorepl (3)
- # quil (4)
- # shadow-cljs (43)
- # tools-deps (24)
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
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)
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
in general i like
tufte, but am trying to investigate some cleaner ways of integrating it into a production codebase
@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.
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.
I'm trying to use asynchronous streams in clojurescript. Should I interop with RxJS, use core.asyc, or something else?
rxjs is about reactive programming, core.async promises much less, simply giving channels.
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?
then core.async is probably fine, yeah. Although tbh, you could probably get away with just using callbacks.
what about call back hell? I know that happens in JS and that's why promises were invented. I'm new to clojurescript
call back "hell" is really just about this:
and so on
(foo (fn [result] (bar result (fn [result2] (baz result2 (fn [result3])))))
do you know if core.async can play nicely with JS promises in case I must interop ?
but js promises are quite nice to use directly via interop, instead of bridging to promises
@U09LZR36F by loss of data, do you mean that the db goes down, and the js is not able to write to it ?
@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.
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
potentially, yes. This is a pretty broad space with a wide range of levels of guarantees and parallelism required.
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?
they can, there might be a library around for it even, but I don't often see that kind of windowing.
Yeah. You can definitely build this functionality on top of core.async, but core.async is a lower-level set of building blocks
@gtzogana sounds like you’re looking for Java Flight Recorder: https://dzone.com/articles/using-java-flight-recorder-with-openjdk-11-1