This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-08-09
Channels
- # announcements (16)
- # beginners (86)
- # calva (4)
- # cider (17)
- # circleci (1)
- # clj-kondo (4)
- # cljs-dev (12)
- # cljsrn (4)
- # clojure (82)
- # clojure-europe (2)
- # clojure-houston (4)
- # clojure-italy (5)
- # clojure-nl (7)
- # clojure-spec (49)
- # clojure-uk (19)
- # clojurescript (76)
- # core-async (7)
- # cursive (1)
- # data-science (4)
- # datomic (5)
- # figwheel (1)
- # fulcro (10)
- # graalvm (15)
- # jobs (1)
- # juxt (6)
- # kaocha (2)
- # leiningen (5)
- # random (2)
- # shadow-cljs (25)
- # sql (5)
- # tools-deps (113)
- # vim (3)
- # yada (14)
Hey guys, if I were to write a wrapper function (g) for another function (f), so that (g x y z)
is (f "hello" x y z)
, how should I write it?
apply
has many signatures such that there's no need to (concat ["hello"] args)
Instead you can just say (apply f "hello" args)
Separately, it might be cleaner to do something like:
(def g (partial f "hello")
To be clear, I want g
to always insert a constant "hello"
at the first position of the f
call, regardless of the number of arguments.
Can I get an opinion? Making a magazine site. There's subscriptions. You gotta pay $5 to read some of the locked material. With locked material, I have a cljs app basically say "hey it's locked" and if you have credentials or session data, it makes an ajax request for the article. Any tips of how to make this robust?
The robustness is in the ability to differentiate a customer that has paid for a resource from one that hasn't. A small jwt id in a cookie or token is one way to do this (simple data, plus verification you set this data, which at least prevents js based hacks)
let them use jwt to prove who they are, then use that id to verify with your db which resources they have access to, etc.
I have used future for multhreading in core-async. Here is the screenshot of my code and error message. I got null pointer exception for using future. If i use just
(async/thread-call (process-data-chan))
instead of
(future (async/thread-call (process-data-chan)))
i dont get any null pointer exception. Can anyone explain me and give me solution about this? I am newbie in clojure and specially in multi threading.thread-call expects a function as its arg. does (process-data-chan) return a function?
so you get the exception with future? and not with the bare call? are you sure it's not the other way around (the exception is with the bare call?)
future captures all internal exceptions. They will be raised when you deref the future.
@U1QQJJK89 thanks a lot. I have to write
(async/thread-call process-data-chan)
instead i write wrong one. Actually i want to use go block of core async to do that operation of multi threading which i did with future. But I really find go block hard to understand!watch hickeys core.async intro talk. Helped me understand it when I was starting out: https://www.infoq.com/presentations/clojure-core-async/
I'm trying out Reagent. One thing bugs me as someone who came from working with React JSX is that the prevailing formatting convention supported by tooling is very line copy-paste unfriendly:
for example, if I were to append a [:li "c"]
after [:li "b"]
, in the following code
[:ul
[:li "a"]
[:li "b"]]
I can't just line copy-paste the last line. Instead, I need to do some minor editing...
I'd say that this rule from the style guide applies here: https://guide.clojure.style/#gather-trailing-parens
@U051BLM8F, maybe we should change it to say "delimiters" rather than "parens"?
Personally I’m using Parinfer (https://shaunlebron.github.io/parinfer/), it helps a lot for these cases
In emacs (and probably in other editors), you wouldn’t copy the last line in this case, you’d forward select the next expression (which would select [:li "b"]
and then copy the selection
you could also in emacs use c-k to kill the last line, which would retain the final bracket and not delete it
I would like to generate a range of distinct days with Clojure.spec, anyone could help me with it?
I tried asking in #yada but it seems to be rather empty during my normal hours. But I'd appreciate if someone has a resource on getting oauth2 (with google preferably) to work with yada.oauth that they point me at it.
if i want to conj
a bunch of objects onto a vector in a map atom, and i have them in a list, is it better to write a (doseq [obj objects] (swap! v update :key conj obj)
or something like (swap! v update :key #(apply conj % objects))
?
that's a cumbersome way of saying: is it "better"/more idiomatic to do a bunch of swap!
s or a single swap!
with apply
?
absolutely the latter
the former is N separate transactions (and someone else could be doing the same thing, interleaving the results)
but really you'd probably be better off with (swap! v update :key into objects)
but be careful with the nil case - into uses a list in that case
I guess conj has the same problem (since into uses conj)
into will also automatically use transients if it can (like with vectors)
oh that's clever, yeah. i'll experiment with into
, see if that handles my usecases
I usually guard against the nil case with fnil
like so: (swap! v update :key (fnil into []) objects)
, to make the type of the collection explicit.
Can easily swap out the vector in (fnil into [])
for a #{}
or {}
depending on the type one wants.
I'm reading a XLSX file with this java library (https://github.com/monitorjbl/excel-streaming-reader) and transforming the HSSFRow objects into a lazy-seq by converting an Iterable interface using iterator-seq
any chance the lazy-seq escapes the body of the with-open that keeps the resource open?
only the ones that aren't realized up to the entries you try to use
iterator-seq chunks, the chunking can hide this error with smaller inputs
(I'm a big non-fan of chunking iterator-seq btw since iterators often imply some kind of side effect even if just extra IO...)
somewhere I have a snippet for non-chunking iterator-seq, but it's not hard to write regardless
I'm connecting some dots here (while running my code, I did a quick re-write to check if this was the problem)
I send each processed row to rabbitmq and I was watching the patterns of the messages received and I noticed some chunks
yes, it will consume N items at a time, even if you ask for 1 at a time
nope, it's built into the code
but as I mentioned, rewriting iterator-seq to not chunk is only a few lines of code
(defn iterator-seq [iter] (clojure.lang.RT/chunkIteratorSeq iter))
you aren't kidding
lost my version, but this one is identical https://gist.github.com/raek/2601906
(defn iterator-seq [it]
(lazy-seq
(when (.hasNext it)
(cons (.next it)
(iterator-seq it)))))
I'd never put an arg list on the same line as a function name, otherwise to the character my version
i'm extremely inconsistent on that. do you have a motivating reason or just your aesthetics?
If you care about external resource control, you shouldn’t use seqs in the first place
the args on line with function-name thing makes sense in cl, with their doc-string placement
Use loop or education or something else
@alexmiller that's fair :/
My general of thumb is - if you care exactly how many things get realized and when, then don’t use lazy seqs
As they make no guarantees
yeah, I like that as a principled approach, but that's in conflict with every professional codebase I've inherited or collaborated on
Sounds like you’re the common factor ;)
it's like some things in core.async - the design principles work but the way most people seem to adopt them fall into very predictable misuses
Hey clojurians, when I start to learn clojure this year I built some basics tests/algorithms, and today I look that repository and think about create a library to be like a group of nice algorithms, that could be useful. So if you want to help me to build this library access the link and lets code: https://github.com/rogervieiraa/clojure.algorithm (This repository is noob friendly, so the code sometime isnt the in the best way, if you found some code that can be upgraded, open an issue explaing that, this it's a nice way to help each other to write better code)