This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-04-05
Channels
- # aleph (2)
- # announcements (3)
- # architecture (5)
- # beginners (51)
- # biff (5)
- # cider (1)
- # clerk (8)
- # clj-kondo (6)
- # cljsrn (5)
- # clojure (31)
- # clojure-europe (42)
- # clojure-nl (1)
- # clojure-norway (21)
- # clojure-uk (3)
- # emacs (11)
- # fulcro (2)
- # graphql (6)
- # hugsql (1)
- # jobs (2)
- # leiningen (3)
- # lsp (3)
- # malli (13)
- # missionary (1)
- # off-topic (7)
- # pathom (7)
- # polylith (27)
- # reagent (14)
- # reitit (3)
- # remote-jobs (7)
- # shadow-cljs (20)
- # spacemacs (4)
- # sql (3)
- # tools-build (4)
- # xtdb (7)
What’s state of the art for piping an InputStream to a core.async channel? My current stab looks like this:
(with-open [rdr ( (get res :body))]
(doseq [item (line-seq rdr)]
(put! ch item))
(close! ch))
As always with InputStream, I’m worried that I’m missing subtleties regarding buffering and so on. I’m expecting 500-1000 lines in rapid succession, so ch
is buffered to 1000.
onto-chan!
seems to stall after the first message.you'd need to wait for all the items to be processed before closing the file (with-open [... ] (<!! (onto-chan!! ch (line-seq rdr))))
Ah, @U2FRKM4TW, I think that’s it. I forgot a bang/go-block.
There's also onto-chan!
- might be more appropriate. Will close the channel for you by default.
Note the comment about blocking in its docstring though. Depending on the nature of that buffer, might make more sense to use onto-chan!!
.
i wasn't clear: if you go the onto-chan! road you need to make sure you wait for the items to to be processed by onto-chan! before closing the file
By the time the with-open
block is done, all the data will have been processed, so it's fine. (assuming later comments)
Ah, I see. The doseq
route seems more straightforward then. No further logic wrt waiting for the reader/input stream to be done.
Ah, yeah, right. I misread the "I wasn't clear" part as if you were talking about the initial scenario.
I'm moving over to slingshot
in my project, and I'm curious on how you would incrementally introduce it.
Currently I have a top level try
and catch Exception
statement with cleanup functions that I'd like to keep for the time being, and then start working on the "leaf" exceptions where throw+
can help me with the handling.
Currently the handling of my throw+
exceptions is only going to consist of more specific log statements.
Is it reasonable to log and then re- throw
from the new try+
error handlers that still need that cleanup logic, and in that case what would you throw?
Or am I thinking about this in the wrong way?
I'm curious what your use case is here? Slingshot hasn't been touched in over 8 years and the only contributor still active in the community is @U0NCTKEV8 who hasn't suggested using Slingshot at work... I'd be suspicious of code that relies so heavily on exceptions that it "needs" Slingshot I think...?
Interesting! Slingshot is already used heavily in this project, so perhaps it's more accurate to say that I want to limit the variation in how exceptions are handled, and I'm not particularly attached to either the vanilla way or slingshot.
if I can suggest an alternative : https://github.com/exoscale/ex (I am slightly biased but...)
Bit of a longshot, but does there happen to be a kind of "data visualizer" I could use in Clojure? Mainly, I want to convert a tree-style data structure, like so:
{:data "foo"
:child-nodes [{:data "bar", :child-nodes []}]}
Into an image that shows a tree, with arrowsThere's a bunch of ways to do this. Do you have an example or a sketch of what you want the output to be? The first thing that comes to mind are the various graphviz wrappers.
it's built-in into the core:
(require 'clojure.inspector)
(def i (future (clojure.inspector/inspect-tree your-data))
+1 for GraphViz, but if your looking for a REPL experience check out #C0185BFLLSE.
Or reveal tree view https://vlaaad.github.io/reveal/use#tree
for this kind of thing I reach for https://github.com/jackrusher/arrowic
https://github.com/drcode/vijual may be of interest