This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aws (2)
- # aws-lambda (18)
- # beginners (68)
- # boot (6)
- # cider (2)
- # clara (2)
- # clojars (27)
- # clojure (68)
- # clojure-austin (5)
- # clojure-berlin (6)
- # clojure-dev (28)
- # clojure-greece (7)
- # clojure-italy (46)
- # clojure-japan (3)
- # clojure-nl (1)
- # clojure-russia (8)
- # clojure-sg (1)
- # clojure-spec (17)
- # clojure-uk (86)
- # clojurescript (82)
- # community-development (2)
- # cursive (18)
- # datomic (11)
- # duct (5)
- # fulcro (254)
- # garden (2)
- # graphql (6)
- # hoplon (19)
- # instaparse (4)
- # kekkonen (2)
- # leiningen (4)
- # luminus (3)
- # lumo (9)
- # off-topic (28)
- # om (7)
- # onyx (38)
- # other-languages (27)
- # portkey (7)
- # protorepl (1)
- # re-frame (56)
- # reagent (64)
- # ring (14)
- # ring-swagger (7)
- # shadow-cljs (255)
- # sql (2)
- # vim (11)
- # yada (10)
@alexmiller: > I’m also not sure how easy it is to pick up a lein project.clj and actually parse it to a point of understanding its dependencies past a naive read. This is not very easy - you’ll need to resolve the project properly, and also optionally tell it which profiles to use.
I think perhaps Leiningen's project.clj contents can contain executable code, in general, although most projects don't take advantage of that.
This is certainly true. A good number of projects I would wager do take advantage of this in different profiles, namely test profiles. I suppose it depends on what you’re specifically referring to by executable code, though.
For example, Leiningen 2.7.1 fires up a REPL using 'lein repl' in a directory with this project.clj file contents:
(let [version-str (str "1" ".8." "0") proj (symbol "org.clojure" "tools.namespace")] (defproject execproj "0.1.0-SNAPSHOT" :dependencies [[org.clojure/clojure ~version-str] [~proj "0.2.9"]]))
Yes, this is the case, and you’ll definitely need to handle that. Another thing is that the lein resolution really has to be done with CWD set to the project location - lots of projects rely on that for various wierdnesses.
All of this is why the plan is to make things extensible in tools.deps, and let the community work on it as they want - I don’t expect to work on this in core
It’s also required to either set env vars, or hook lein - all this depends whether you want to do the resolution in-process or not.
Cursive has some really ungodly stuff to work around all this to allow the resolution to happen in-process for speed reasons - some users have projects of > 80 lein projects.
If you’re only interested in resolving one project at a time then starting a subprocess is almost certainly the best idea.
Hah, and if you think
project.clj is hard to handle, just wait until you start looking at
build.boot files which are just arbitrary executable Clojure code 🙂
Hi. Recently I figured out a way to write and debug macros-generating macros more easily. I was confused by the different results I would get with
pprint when displaying a list starting with the symbol
quote. So i started to investigate and it turned out
pprint explicitly translates
(quote abc) to
'abc while the reader does the opposite job when expanding the reader macro
'. I peaked at clojure.tools.reader source code, and it appeared that translating
(clojure.tools.reader/syntax-quote abc) had been planned but commented out.
So I wrote, as a pure development tool, a monkey-patch that enables
[backtick] translation in both the
pprint with this effect:
``abc ;; (quote my-ns/abc) (pprint ``abc) ;; 'my-ns/abc
But above all, it prevents this:
``abc ;; (clojure.core/syntax-quote my-ns/abc) (pprint ``abc) ;; `my-ns/abc (def args [1 2 3]) (pprint (syntax-quote `(abc [email protected]))) ;; `(my-ns/abc 1 2 3) (pprint (syntax-quote `(abc ~'[email protected]))) ;; `(my-ns/abc [email protected])
And prints this instead:
(pprint ``(do (fn1 arg1 arg2) (fn2 arg3 arg4))) (clojure.core/seq (clojure.core/concat (clojure.core/list 'do) (clojure.core/list (clojure.core/seq (clojure.core/concat (clojure.core/list 'user/fn1) (clojure.core/list 'user/arg1) (clojure.core/list 'user/arg2)))) (clojure.core/list (clojure.core/seq (clojure.core/concat (clojure.core/list 'user/fn2) (clojure.core/list 'user/arg3) (clojure.core/list 'user/arg4))))))
The code itself is at https://github.com/TristeFigure/shuriken/blob/master/src/shuriken/monkey_patches/syntax_quote.clj I think this could be a great addition to Clojure (modulo the gory details of how I implemented it, especially the fact that I substitute Clojure's reader with that from clojure.tools.reader). What do you think ?
(pprint ``(do (fn1 arg1 arg2) (fn2 arg3 arg4))) `(do (user/fn1 user/arg1 user/arg2) (user/fn2 user/arg3 user/arg4))
@tristefigure a change like this would be a breaking change, moving syntax quote from read-time to a macro, so it's highly unlikely that this will ever happen, especially when this sounds tooling could aid you in this
and the fact that its main use case is to aid debugging rather than a functional enhancement
Hi, I'm trying to write a tool that would read clojure datastructures from the output of a REPL or a log stream and that would reformat it (pretty printing for example). I have a problem with the print-level and print-length options which are common in this context and which make datastructures impossible to read. I think it would make sense to make print-method to print a tag reader when the print-length or print-level limit is reached. Is this something that has been discussed before ?
print-dup, print-readably controlling the main printer, the pretty printer being its own thing governed by hald a dozen of dynvars...
pprint also doesn't have the contract prn has of printing readable forms, but that doesn't stop people from expecting it
right, but prn printing readably is a very important property, everything else can be built upon