This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (73)
- # capetown (1)
- # cider (13)
- # cljsrn (4)
- # clojure (56)
- # clojure-russia (2)
- # clojure-uk (1)
- # clojurescript (50)
- # community-development (3)
- # cursive (1)
- # datomic (80)
- # defnpodcast (2)
- # emacs (2)
- # fulcro (16)
- # graphql (8)
- # hoplon (206)
- # immutant (43)
- # keechma (4)
- # lumo (4)
- # off-topic (26)
- # perun (2)
- # re-frame (2)
- # reagent (4)
- # remote-jobs (2)
- # rum (4)
- # shadow-cljs (82)
- # spacemacs (5)
- # vim (6)
I split it to avoid quoting arg to macro, in the first place, plus to keep form with syntax quote/unquote as small as possible. but now all of it is irrelevant
and also org.slf4j/log4j-over-slf4j and org.slf4j/slf4j-simple IIRC
Is it interesting for clojure world?
Regarding my question from yesterday I already figured out that twitter-api is using http.async.client which is using com.ning/async-http-client which is using io.netty/netty which is using com.ning.http.client.providers.netty.NettyAsyncHttpProvider to make async calls (when io.netty is in the classpath) which can prevent the application from closing when the NettyAsyncHttpProvider is not closed properly as per https://stackoverflow.com/questions/30534600/how-to-close-asynchttpclient-with-netty-for-an-asynchronous-http-request.
ok, now I finally see that there is already an open issue: https://github.com/adamwynne/twitter-api/issues/74
Hey! Does anyone have to recent performance benchmarks on webstacks? Im seeing a delay in requests of about 100msecs that I cant explain. The hoops jumped through are nginx -> immutant/jboss -> ring -> moustache -> handler. The handler is 3msecs, the total request 100msecs before it starts streaming
I know that is so evil question here, but… While I love Clojure, I am looking solution which don’t use so much memory to use on machines with very low memory. Which solution (language / framework / whatever) could i like then?
yeah, but for now i am thinking about software to automate all things, like monitoring, temperature protection, bios updates. Like plug & play. So it is more about software around GPU mining, then directly software to mining.
@kwladyka check https://github.com/uncomplicate for GPU-related Clojure libraries. Those are the best to the best of my knowledge
as for low memory devices there is: https://github.com/nakkaya/ferret but I have never tried it 😄
no i wouldnt say that, it’s just another systems language that fills a similar niche to c++
go might be a decent option, but it depends on your latency requirements etc since go is garbage collected (similar to jvm)
and also doesnt run well on 32-bit arm systems (not sure if that’s where you’re going with this low memory requirement)
c or c++ will give you the best support, other languages will have varying levels of support.
Hmm not really sure how it work in practice. On first fire i would like to detect overheat, monitoring if everything works fine and if not notify, update GPUs bios, etc. I don’t think i have to use C++ for this things around GPU mining
python probably the most straightforward since it has a big ecosystem and is well supported
yeah, maybe it is naive, but as Clojure fun i was looking something which can give me more pleasure, than Python 😉
@ymilky Was hoping to ask you a quick and simple question around #franzy. I have kafka (and zookeeper) running in a docker-compose setup.
If I can produce and consume using kafka tools (confluentinc/cp-kafka:3.3.1), what leap do I need to make, to subscribe (or manually consume) from the same topic, using franzy?
Using the examples here, messages that are definitely on a topic, are not being consumed, when using franzy. https://github.com/ymilky/franzy#subscription-based-consumer