This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-09-17
Channels
- # 100-days-of-code (4)
- # announcements (4)
- # aws (2)
- # beginners (88)
- # cider (1)
- # cljsrn (9)
- # clojure (126)
- # clojure-conj (4)
- # clojure-dev (8)
- # clojure-greece (1)
- # clojure-italy (37)
- # clojure-nl (3)
- # clojure-spec (13)
- # clojure-uk (91)
- # clojurescript (392)
- # clojurewerkz (1)
- # clojutre (10)
- # core-async (6)
- # cursive (5)
- # data-science (1)
- # datomic (41)
- # emacs (21)
- # events (1)
- # figwheel-main (52)
- # fulcro (2)
- # hyperfiddle (4)
- # jobs (3)
- # jobs-discuss (9)
- # luminus (3)
- # lumo (9)
- # mount (1)
- # nyc (1)
- # off-topic (73)
- # other-languages (6)
- # pedestal (8)
- # portkey (2)
- # re-frame (9)
- # reagent (8)
- # rum (17)
- # shadow-cljs (38)
- # sql (19)
- # tools-deps (18)
- # yada (4)
Hi everybody! I have a question about Onyx. I have a job where I want to use watermark triggering to use windows of segments. It works in a toy example, and time-based triggering works in the real application. However, watermark triggering does not work in the real application. What can be the cause and how can I verify and fix that?
I was just pointed to the possibility that completion of the job by closing the input channel may trigger the watermark in the toy example...
@lutz.buech closing the input channel will cause the job to end, not the watermark to be triggered
When using clojure.core.memoize/ttl is it possible to evict a result after some time, regardless if it has been requested? so the ttl is not reset on a cache hit
cli question
:aliases {:test {:extra-paths ["test"]}}
What is the difference between clj -C:test
vs clj -A:test
? I guess there is no difference. So my question is what is the point of having -C
and -A
? Can i use always -A
?
I think in general you can just use -A and ignore the rest most of the time
I remember seeing a while back a gist / blog post about inspecting protocol implementations to see which methods an instance implements, etc. Does anyone have a link, or a hint to google for?
The protocol name will eval to a map with all the protocol state if that helps
I thought there was something else as well? A place where you could see that type A only implements 1 out of 2 methods on protocol Bar?
that info is in the protocol map
because the method impl will be missing in the map
user=> (defprotocol Bar (a [_]) (b [_]))
Bar
user=> (extend-protocol Bar String (a [_] "a"))
nil
user=> (pprint Bar)
{:on user.Bar,
:on-interface user.Bar,
:sigs
{:a {:name a, :arglists ([_]), :doc nil},
:b {:name b, :arglists ([_]), :doc nil}},
:var #'user/Bar,
:method-map {:b :b, :a :a},
:method-builders
{#'user/b
#object[user$eval146$fn__147 0x4983159f "user$eval146$fn__147@4983159f"],
#'user/a
#object[user$eval146$fn__158 0x44e3a2b2 "user$eval146$fn__158@44e3a2b2"]},
:impls
{java.lang.String
{:a
#object[user$eval195$fn__196 0x68ead359 "user$eval195$fn__196@68ead359"]}}}
:sigs tells you the methods in the protocol, :impls lists the method impls per type
one important missing thing here though are inline protocol impls for records/types
I don't think there is any way to discover that short of calling protocol methods on an instance and getting an UnsupportedOperationException
there's quite a few videos on youtube about repl driven developement (via emacs, vi or cursive) with clojure, should get you started
no, clojure's smart enough to clear locals in let forms once you stop using them
the gotcha is if you let it escape scope (clearing can't be done then) or turn off locals clearing for debugging
iterating over it but also returning it is the simple example
or assign it to something with scope outside the let
or consume it twice, with one consumer much slower than the other(?)
concretely the thing to avoid is:
(let [COLL (big lazy seq)]
(some-other-process-that-uses-the-whole-list COLL)
(doseq [i COLL]
(use i)))
the slow one is doseq - it doesn't start until the other returns
@misha if you picture it- the external process can expand COLL, but since doseq is using the same coll but hasn't run yet, the realized results can't be cleared
I like the accordion metaphor, yeah
so coll gets expanded by some-other-process
, and gets kept in memory until doseq finishes
@ghadi so that would mean that items in COLL are realized twice? I don't see how else it would be OK
then it's a no-op
@noisesmith can you give a short example of "assign it to something with scope outside the let"?
(def state (atom []))
... (defn foo [] (let [c (some-huge-lazy-thing)] (swap! state conj c) (doseq [el c] ...)))
- c leaves scope via swap!, now the head is held onto and can't be cleared
another question: does it even make sense to have an atom in a :dynamic var to use it from multiple threads?
I can't think of a case off the top of my head where those behaviors would work together - one says "you can change this but only in this thread scope and not visible to sibling or parent scopes" and the other says "you can change this and it will be visible to all threads"
binding will work only for current thread, not for others (if I, say, pmap inside binding form), won't it?
right, the reason to use binding is because you want that behavior
there's literally no other reason to use it
pmap will propagate bindings - I might have misunderstood you
binding propagates to child scopes, with things like pmap, future, go this is automatic, with lower level jvm thread construction you might need to propagate it more manually
what binding doesn't do is make changes visible to parent or sibling scopes
not saying that it makes sense, but the clojurescript compiler does that https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/env.cljc
@leonoel wow, TIL
hey folks! I am trying to create a macro to add a log layer in my application
(defmacro defn-log [name args body]
(let [the-name (keyword name)]
`(def ~name
(fn ~args
(let [log1# (log/info (str "begin: " `name))
log2# (log/debug (str "input for " `name ": " ~args))
x# (~@body)
log3# (log/debug (str "output for " `name ": " x#))
log4# (log/info (str "ending: " `name))] x#)))))
it’s working for simple cases like
(defnlog ttt [name1] (let [x (+ 1 1)
xy (println name1)] name1)
but cases like doesn’t work.
(defn-log -main [& args] …)
what do you expect `name to do in that macro?
in that case I would expect '~name
my output would be something like begin: tttt input for: tttt name1 output for : tttt : value of x ending tttt
user=> (defmacro foo [n] `(println `n))
#'user/foo
user=> (foo a)
user/n
nil
user=> (defmacro foo [n] `(println '~n))
#'user/foo
user=> (foo a)
a
nil
perhaps you also want 'args in the log instead of args - that's likely the error
(in log2#)
the problem is that there are items in your arglist that can't actually be resolved at runtime - so you either need smarter arglist parsing, or you want to just show the literal arglist
a third option is to insert (keys &env)
into your output form, which leads to locals being printed at runtime
this also shows let bindings, so you would likely want to inject that before the let form
does someone know how I can convert a dom element to a clojurescript value ? (js->clj (gdom/getElement "myId") ) does not return anything useful.
I think the key would be the Dom element api in js - there should be some method to get the markup or structure
this might be your ticket https://developer.mozilla.org/en-US/docs/Web/API/Element/innerHTML
thanks @noisesmith
I have some Figwheel issue: In the repl, it works, and I can build it. But Figwheel Complains in the browser-window
^--- No such namespace: mynodes, could not locate mynodes.cljs, mynodes.cljc, or JavaScript source providing "mynodes" 52
Use of undeclared Var mynodes/forEach at line 51, column 7 in file src-client/client/dom.cljs
it's not complaining about a var mynodes
it's complaining about mynodes/forEach
. it's not finding a mynodes namespace
@arrdem Earlier versions silently ignored them -- but people complained about that which is why the new version complains...
Also it looks like (if you hack the script to let you use multiple deps files) paths from deps files are always treated relatively, they’re never normalized to absolute paths with respect to the location of the deps file.
@seancorfield thanks for the context.
That other issue sounds very much like the (known) issue of local/root deps not working when combined with other deps...
Yes, that’s the problem
@alexmiller thanks for the fast turnaround on the default deps thing, would you be interested in an absolute path patch for clojure.tools.deps.alpha.reader
?
what’s the problem we’re talking about?
btw #tools-deps is prob better for stuff like this discussion
I’m curious about the scenario above where being lax about missing aliases would be helpful to you