This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (1)
- # announcements (1)
- # beginners (54)
- # calva (11)
- # clojure (55)
- # clojure-france (1)
- # clojure-italy (4)
- # clojure-spec (10)
- # clojure-uk (7)
- # clojurescript (3)
- # cursive (3)
- # data-science (8)
- # datomic (10)
- # emacs (1)
- # fulcro (21)
- # graalvm (2)
- # jobs (1)
- # kaocha (1)
- # nrepl (1)
- # nyc (1)
- # other-languages (5)
- # reitit (8)
- # rum (5)
- # shadow-cljs (84)
- # spacemacs (2)
- # sql (20)
- # testing (3)
- # vim (1)
@m131 In this particular case, none. It's just that
as-> has a "strange" argument order -- value symbol -- compared to everything else that binds symbols and values -- and that's because
as-> is designed to have the value threaded into it, as its first argument. So it's "natural" to use
-> (or the other thread-first operations).
-> is the "base case" because you can thread into
as-> etc etc.
There’s also a good argument against using
as-> not inside a threading macro by Stuart Sierra at https://stuartsierra.com/2018/07/15/clojure-donts-thread-as
->, the arguments to
as-> appear in the order value name rather than name value, making it unlike anything else in Clojure.
>it places that name second in its parameters. To me, this clearly indicates that it is meant to be used in combination with ->.
So it bothers me to see
(as-> value symbol exp1 exp2 ,, expN) rather than
(-> value form1 form2 ,, (as-> symbol exp1 exp2 ,, expN) ,, formN)
Hi, I wanted to test my server-sent events and receive each event individually but the http client request fns all block until the whole response has been received. How can I get each individual event separately ? (sorry to ask here but I couldn't find a channel for http-kit)
Stuart Sierra has a few thoughts on this as well: https://stuartsierra.com/2018/07/15/clojure-donts-thread-as
Has anyone seen “clojure: error: Cannot execute clojure: No such file or directory” while running
Thanks Alex, that helps but I think I am on the wrong track in general. I have a few macros that attempt to export functions or symbols from other places into a given namespace. This works unless the thing being exported is a macro in which case it works until someone attempts to aot the thing after which the macro fails to work. What doesn't work every is cider's go-to-source. My thought was to override the meta data generated by def to include a different file and line but this type of thing is normally handled by a source-map type datastructure. I don't mind needing to redeclare macros when I am building out the API layer of a library but I cannot be redefining and maintaining a set of forwarding functions and ideally go-to-source works from editors. 1. Does anyone know if nrepl has a source-map type entry it looks for in the var's metadata? 2. Ideas on other ways?
var's have file/line/column metadata and that's how Clojure's
source function works. I don't know if cider has something additional.
I would need to override the file/line/column metadata and I can't see how to do that.
I don't know how you're "exporting" into another namespace, but presumably that means making vars. vars have metadata.
Maybe I can just add the var do the namespace directly instead of going through a def and macro?
seems like you just want the :file :line :column meta at the top level, not under :source-map?
I wrote this for doing that 🙂 https://github.com/juxt/edge/blob/master/lib/edge.app.dev/src/dev_extras.clj#L33-L53
lighter than potemkin, which does var watching to sync up things like dynamic vars. Important features in some senses, but usually a bad sign!
So Alex, how do you get around this? I don't want users to include 10's of namespaces for things implementations of things and I don't want the implementation of a thing to be all in one file. For things like math libraries which have 100's of symbols that users expect to find under one namespace some level of 'lifting some of these things out of these implementation file' seems to make sense.
There's 2 options I've seen recommended in place of this proxying:
1. impl namespaces & api namespaces, see core.async for examples. https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async.clj
load, see clojure.core and clojure.pprint for examples. https://github.com/clojure/clojure/blob/master/src/clj/clojure/pprint.clj#L43-L49
1. reduces to either duplication or implementing everything in the API namespace. Some level of that makes sense sometimes. But pulling functions directly out of the impl namespace also makes sense IMO if the function can be defined and documented in one place it is better locality.
load is something else altogether, sort of an eval power tool.
Thanks both of you, that is enough information to move forward 🙂.
Creating and using a proxying system seems both harder and more confusing than either of those imo
It's all tradeoffs as to how much effort a user needs to use to remember where something is and how structured or complex the actual implementation of what you are doing is and how much effort you want to do to organize and maintain some large file. I usually implement things in some more granular fashion with smaller files and then export a flattened namespace. Zach in potemkin I think states it well: https://github.com/ztellman/potemkin#import-vars I am with Zach on this one.
He seems to imply "Clojure namespaces conflate the layout of your code and your API." as a downside and "This means that the structure of your code and the structure of your API can be decoupled." as an upside. In my opinion, the reverse are true. :)
I'm with Alex there. Having used a variety of ways to import/export Vars across namespaces, I've concluded it's usually a bad idea -- and organizing your namespaces around the API is a better option.
Little question, but need to explain context first.
If I do something like
(def myfn (partial foo "bar")),
I can't instrument
foo with debug bindings via
cider-eval-defun-at-point -1 and have foo breakpoint when I run
(myfn ...) at the REPL.
This is because the
partial is copying the value of the function.
If I instrument with
(def myfn (partial #'foo "bar")) (referring to foo by reference), then I can debug foo via calls to
myfn as expected.
Now the question: is there any downside to doing this by reference?
I can't come up with any & in fact seems like it'd take less memory, but I'm making a PR against someone else's library and want to be sure.