This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-04-12
Channels
- # announcements (1)
- # babashka (124)
- # beginners (98)
- # calva (54)
- # cider (32)
- # cljdoc (5)
- # cljs-dev (131)
- # cljsrn (1)
- # clojure (107)
- # clojure-australia (2)
- # clojure-europe (2)
- # clojure-losangeles (1)
- # clojure-norway (3)
- # clojure-uk (28)
- # clojurescript (21)
- # conjure (86)
- # core-async (7)
- # cursive (3)
- # datascript (5)
- # datomic (28)
- # defnpodcast (2)
- # devcards (1)
- # exercism (47)
- # fulcro (22)
- # graalvm (29)
- # graphql (1)
- # malli (5)
- # nrepl (31)
- # off-topic (111)
- # re-frame (23)
- # reitit (4)
- # spacemacs (6)
- # tools-deps (10)
- # tree-sitter (1)
- # xtdb (6)
It should have no meaning I guess. In the same manner someone uses x
as a variable name the author here used xrel
to indicate that it is a relation also (in the relational model sense)
For example clojure.set/join
has a yrel
also indicating another relation that will perform the join against
I sort of assumed it was cross-relation but I have no basis for that. I find clojure.set
to be a strange mix of simple, obvious stuff and weird stuff I'm not sure about...
the normal case gives num/(divosor)^k . when k > 0, and when k ==0, the value is 1/num, not num/(divisor)^0.
I understand what you are saying @i but I think this is simply a case where you have an edge case in the number of parameters, and a use case that exercises that edge, that gives you different results than you wish. I have no personal knowledge of existing Clojure code that relies upon the current behavior of (/ n)
, but if there are 0 occurrences of such code I would be very surprised. Backwards compatibility is a good thing for Clojure, if there are such use cases today.
If you want a function that calculates num / (divisor)^k
then I would recommend something more like (/ num (apply * (repeat k divisor)))
Neither your original code nor my suggested replacement are good for k < 0, of course, nor for non-integer values of k, so my suggestion only covers one additional value that yours did not (i.e. k=0). Not sure what kind of generality you are looking for, though.
There's a good one here: https://github.com/clojure/math.numeric-tower
i have another question regarding consistency. for example, conj accepts varidiac arguments, but conj! does not.
It also gets hard to create consistency, lots of thinking required, and easy to introduce inconsistency even if you spend a lot of time making sure you don't
There is an open ticket suggesting making conj! variadic, but has not been addressed (and might never be). Such things are nice to have, and similar things have been changed in Clojure in the past, so it is possible it might be changed in future Clojure version.
I believe this is the issue in JIRA that is relevant: https://clojure.atlassian.net/projects/CLJ/issues/CLJ-1103
The transient functions are far and few between, and used in far fewer places in typical code than the persistent versions.
So yes, a few people might notice, but most never would.
If you wish, you can vote on issues you wish to be changed here on http://ask.clojure.org -- votes do not guarantee anything will be done, but high-voted issues tend to get addressed (as in fixed with a change, or declined) sooner than issue that no one votes on.
https://ask.clojure.org/index.php/2370/make-conj-assoc-dissoc-transient-versions-handle-similarly
on the other hand, this makes me think: for such transient stuff, I may resort to java libraries more, such as java.util.stack
A question about transients: I have a grid data structure represented as a vector of vectors, and I find myself updating it quite frequently. I would like to use transients to make the tight loops faster (and avoid unnecessary allocations!), but since it's a nested structure, I'm a bit confused. Should I recursively convert all the inner vectors into transients, then the outer vector, and then recursively convert everything back to persistent?
help understanding java.lang.IllegalStateException
I have a main file named core.clj
which had several function definitions in it. I'm trying to move those function definitions to another file which does not reference core.clj
at all. When I try to load that file, I get the error:
2. Unhandled clojure.lang.Compiler$CompilerException
Error compiling src/clojure_rte/rte_tester.clj at (1:1)
#:clojure.error{:phase :compile-syntax-check,
:line 1,
:column 1,
:source
"/Users/jimka/Repos/clojure-rte/src/clojure_rte/rte_tester.clj"}
Compiler.java: 7647 clojure.lang.Compiler/load
REPL: 1 clojure-rte.core-test/eval30126
REPL: 1 clojure-rte.core-test/eval30126
Compiler.java: 7176 clojure.lang.Compiler/eval
...stuff omitted..
1. Caused by java.lang.IllegalStateException
random-test already refers to: #'clojure-rte.core/random-test in
namespace: clojure-rte.rte-tester
I don't understand why I get a symbol conflict, when I'm not even using nor referencing the ns clojure-rte.core
Did you restart your REPL? In a running REPL, symbols are not unset automatically. Also, are you using a different namespace for the other file?
yes both files have a different name space.
delaying the question of repl for the moment. Am I allowed to the the same function name in two different name spaces as long as the name spaces are independent from each other? Seems logical, otherwise namespaces would be useless. right?
re: restarting the repl, no I haven't restarted it yet. I actually don't know how to restart the cider repl.
in CL/slime there's a function slime-restart-inferior-lisp, I don't find such a cider function
yes, that's how I understand it as well. But the error message seems to say otherwise.
So, if you wanted to redefine clojure.core.map
you first have to exclude importing map
from clojure.core
. Otherwise, it is absolutely fine.
Did you start the REPL or did CIDER start it? If the latter, you can disconnect and jack-in again.
Here is my namespace definition in rte_tester.clj
(ns clojure-rte.rte-tester
(:require [clojure-rte.tester :refer [ random-test]]
;; [clojure-rte.core :refer []]
))
BTW what does ns
do if such a namespace already exists? does it delete the old one, or just extend it? maybe I need to delete the ns before re-loading the file?
Okay, you should not use :refer
most of the times. Somehow a symbol named random-test
is already present in the clojure-rte.rte-tester
namespace.
:refer
is usually a bad practice. Use a short alias for the namespace instead.
[clojure-rte.tester :as tester]
for example.
can I remove that symbol from tester?
Isn't this a problem all beginners have? Where should the process be documented? I saw someone recently say "Yea you're right, this process seems to be missing from the documentation"
I faced the same issue initially. Documentation only makes sense when you are past a stage.
@U010VP3UY9X you can unmap a symbol from a ns:
(.unmap *ns* 'foo)
That should workIf your code can be made public, others could try to reproduce it, and/or look at a more complete state of what you are trying to do, with less guessing.
I realize that might not be possible depending upon the project you are working on.
Also, again, good to see if the issue occurs in a fresh REPL started from the terminal, rather than from CIDER. Even with CIDER, using some mechanism (I do not know, since I do not use CIDER myself) to ensure that a current JVM is stopped, and a new JVM started, could help eliminate problems that can occur if there is an existing set of namespaces, and you are moving functions from one namespace to another.
Yes, it is certainly possible to remove the namespaces from an existing running JVM, and then create new occurrences of those namespaces with the same names.
You are definitely allowed to have the same symbol name in two different namespaces, for two different functions (or whatever values the names refer to, integers, collections, etc. -- it doesn't have to be functions).
But if namespace B does (:require [A :refer [some-name]])
then it is a name conflict to have something named some-name
in namespace B as well, because the :refer [some-name]
means "inside of namespace B, I want to be able to use the symbol some-name
to name the thing called some-name
inside of namespace A".
I forgot to mention, you can mark a symbol as private and it won't be imported when some other namespace imports this namespace.
(defn ^:private f ...)
(def ^:private x ...)
Macro question: I have a macro that is designed to work like ->
, except if it encounters a map it does some special work. If Iโm working with raw maps, itโs fine, but if I pass in a symbol bound to a map, it doesnโt do the special work. What do I need to do to change this?
NOTE: this is designed to work with reagent, which is why I mapv
the results
(defmacro macro-> [node & forms]
(let [forms-rewritten# (mapv
(fn [form]
(if (map? form)
`(special-work ~form)
form))
forms)]
`(-> ~node
~@forms-rewritten#)))
(macro-> node {:a "a"})
works fine but
(def my-map {:a "a"}) (macro-> node my-map)
doesnโt
I want those 2 ^ to work the sameI can see use cases for both
For def
s, you can copy my try-resolve
https://github.com/bsless/clj-fast/blob/master/src/clj_fast/util.clj#L22
(that probably wouldn't work as is, you'll need to do some more thinking and maybe manually expand a tad more)
has anyone else run into a problem with rlwrap
while trying to run the clj
CLI in a containerized Clojure app? This GH issue is not Clojure-related but it seems to describe the same underlying Docker issue (which was "fixed" by...not using rlwrap ๐) https://github.com/Raku/docker/issues/3
Which was the "fix" in the issue: not using rlwrap
๐
Yeah, I've used that bandaid...it just sucks because clj is a much better UX. Not having arrow keys is a total productivity killer, for example. So just thought I'd cast out to see if anyone found a better solution. Thanks!
if there is a fix that can be applied to rlwrap, happy to do so in the clj tool
Thanks @alexmiller, I'll poke around in Docker a bit today
Any reason why one example fails at read time and the other one "works"?
user=> #{#() #()}
Syntax error reading source at (REPL:1:11).
Duplicate key: (fn* [] ())
user=> #{#(-> %) #(-> %)}
#{#object[user$eval5$fn__143 0x7aead3af "user$eval5$fn__143@7aead3af"] #object[user$eval5$fn__6 0x7c1c5936 "user$eval5$fn__6@7c1c5936"]}
The latter example also fails in babashka unlike in Clojure, but I want to know what's the expected behavior here{(rand) 1 (rand) 2
} is the same. It's because there's some checks in the reader.
I've taken it to mean that you should probably not put non literal indexes into literal syntax.
I'm messing around with it now and so far it looks like the second doesn't pass reading because, unlike #()
which reads to the list (fn* [] ())
twice, which will count as equal, #(-> %)
is going to have an argument, which on read will be gensymmed into having a unique name each time and, thus, the two lists will not count as equal
( #{(fn* [p1__9062#] (-> p1__9062#)) (fn* [p1__9061#] (-> p1__9061#))}
as a random example of me calling read on this)
@borkdude probably because of the read results?
user=> (read-string "#()")
(fn* [] ())
user=> (read-string "#()")
(fn* [] ())
user=> (read-string "#(-> %)")
(fn* [p1__195#] (-> p1__195#))
user=> (read-string "#(-> %)")
(fn* [p1__198#] (-> p1__198#))
user=> (read-string "#(-> %)")
(fn* [p1__201#] (-> p1__201#))
Going for that level of compatibility between multiple Clojure implementations seems like a bit of a stretch to me, unless you actually find some subtle bug that affects other behavior as a result.
I haven't thought about it for more than half a minute, but it seems reasonable to leave that behavior in an implementation, and if someone files a bug report, see if it was an experiment they did toying around, or actual production code. If it was production code, push back a little more and see if they know how fragile it is ๐
They can always use (set [expr1 expr2])
instead of #{expr1 expr2}
if they want it to "work", where I put that in scare quotes because, well, I think maybe they should be scared if the difference is that important ๐
yeah, so now it's up to @ivangalbans to respond to this ๐
I have changed my script and it works very well. Thanks a lot @borkdude, @andy.fingerhutโฆ
this difference is not important in my use case ๐
The bigger question is why does the second not work in babashka? Does the reader expand things differently? Could that affect the behavior in other places as well compared to Clojure?
@didibus bb uses edamame and edamame always expands function literals to the form:
$ bb -e "'#(-> %)"
(fn* [%1] (-> %1))
so it doesn't use gensym'ed symbols for thoseHum, interesting, I wonder why Clojure uses gensym then, if it's just an implementation artifact, or is the choice of gensym deliberate. Like can this cause shadowing to happen? Are there good reasons not to want to shadow %1? I would only think of nested #() but those aren't allowed anyways. And I feel choosing to call something % or %n is other context just feels wrong anyways.
@didibus Last time I asked Alex, he said this way of expanding doesn't result in any problems. He also said they were doing something similar for spec2.
In normal JVM Clojure when executing a script, is there a way of detecting whether you're being called with a main argument -m foo
or just executing as a script file?
(defn -main [& args]
(println "args" args))
(when ... ;; we're running as a script
(apply -main *command-line-args*))
I have an uberjar key in my project.clj, like so: :uberjar { :env { :foo "bar" :foo2 "bar2" } } but upon running lein uberjar, my app isn't using the keys from uberjar but from the :dev {:profiles {:env ...}}. How do I fix this?
@prikshet21,I canโt find :env
documented in stock lein. are you using a plugin?
No I'm not. without having the :env, I get null pointer exception on Heroku when using them, even though the config vars are set there.
@prikshet21 I don't use Leiningen so I don't really understand what you're trying to do there but I would not expect the JAR file produced by Leiningen to use anything from project.clj
-- it's a standalone application and it runs in its own JVM context, not Leiningen's.