This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-08-20
Channels
- # announcements (1)
- # bangalore-clj (27)
- # beginners (82)
- # boot (4)
- # chestnut (1)
- # cider (22)
- # cljs-dev (26)
- # cljsrn (4)
- # clojure (118)
- # clojure-dev (18)
- # clojure-italy (2)
- # clojure-losangeles (1)
- # clojure-nl (2)
- # clojure-russia (1)
- # clojure-spec (15)
- # clojure-uk (125)
- # clojurescript (61)
- # core-async (74)
- # cursive (2)
- # datomic (41)
- # duct (6)
- # editors (7)
- # emacs (3)
- # events (1)
- # figwheel-main (3)
- # fulcro (111)
- # hoplon (11)
- # jobs-discuss (97)
- # lein-figwheel (99)
- # off-topic (34)
- # onyx (4)
- # parinfer (9)
- # pedestal (4)
- # precept (2)
- # re-frame (5)
- # reagent (2)
- # reitit (4)
- # ring-swagger (11)
- # shadow-cljs (104)
- # spacemacs (4)
- # tools-deps (19)
- # vim (8)
- # yada (15)
hmm I'm still having trouble using deps.edn with a dependency transitively dependent on a maven artifact with :classifier
- because the artifact names are the same & so would lead to duplicate keys in the :deps
map
I think if you use :local/root
the key is not being used in the lookup. So you could use anything for the key even {foo/bar123 {:local/root "/path/here"}}
I believe
@octo221 this is not currently supported https://dev.clojure.org/jira/browse/TDEPS-12
you can probably hack around it with something like @jeroenvandijkโs suggestion
@alexmiller in the end I solved it by downloading the offending artifact and using :extra-paths
on the clojure page about protocols it mentions parenthetically > Which interfaces are implemented is a design-time choice of the type author, cannot be extended later (although interface injection might eventually address this) Does this exist or perhaps will soon? Not sure if anyone knew if this was on the radar or had a ticket in jira
is it possible to somehow specify classloader when loading namespaces from a file with load-string
?
or is there some other way to do that?
@beoliver This doesnt work, but the general idea is to catch std-err and see if the words "Reflection warning" are there
is there a good way to find consumers of a library? Wondering how widespread org.clojure/data.finger-tree
usage ever got
cljdoc doesn't seem to offer a search by dependency. I can't remember the name of the other online source browser for clojure but i thought i remembered it might have a feature to search by dependency
crossclj @dpsutton
yes thanks @martinklepsch
yeah (re maintaining) โ it's not planned for near future but eventually we might have data in appropriate shapes to answer these kinds of questions
https://crossclj.info/ is pretty useful
A question about meta-data - the documentation states *An important thing to understand about metadata is that it is not considered to be part of the value of an object. As such, metadata does not impact equality (or hash codes). Two objects that differ only in metadata are equal.* yet the following seems to suggest otherwise
> (identical? identical? identical?)
true
> (identical? (with-meta identical? {}) identical?)
false
> (= (with-meta identical? {}) identical?)
false
> (= (with-meta identical? {}) (with-meta identical? {}))
false
follow up: does anyone know of writing about meta data anywhere? It seems "wrong" to me and a constant source of bugs with macros and such
i've never had to use it so i wanted to see how others have used and and why they chose that over making it explicit
an example of using it recently to avoid reflection warnings https://github.com/beoliver/clj-arangodb/blob/master/src/clojure/clj_arangodb/arangodb/options.clj#L18
so that is emitting type tags. I get that. I was thinking more of people who actually use meta to stash information and not just for annotation of compiler information
https://github.com/clojure/clojure/commit/541f04f1b75f95b159af0e4617643d45ebd43596 As of that it will ^
"with-meta in the general case will never return the same object, but it has some optimizations to sometimes return the same object in some cases"
it starts off saying "metadata is that it is not considered to be part of the value of an object"
functions are not values in clojure in the same sense that the collection data types are
Prelude> let f = \x -> x
Prelude> f == f
<interactive>:8:1: error:
โข No instance for (Eq (p0 -> p0)) arising from a use of โ==โ
(maybe you haven't applied a function to enough arguments?)
โข In the expression: f == f
In an equation for โitโ: it = f == f
@hiredman I know... I can see that... I thought (identical? identical? identical?)
might throw an error... thats all... nothing more.
anyway, I think functions supporting IMeta and using reference equality is kind of dumb, but it is what it is
clojure.core/= is sometimes value and sometimes reference equality depending on the types of the data being compared
so for the case of functions, clojurec.core/= is the same as clojure.core/identical?
@beoliver In Clojure, clojure.core/= is far more commonly used, and what is meant by the English word "equals" or "equality" when referring to Clojure. clojure.core/identical? is the oddball, and exists really only for the unusual cases where you might care about object identity.
In the text you quoted: "As such, metadata does not impact equality (or hash codes). Two objects that differ only in metadata are equal.", the words "equality" and "equal" are referring to clojure.core/= equality.
@andy.fingerhut - sure thats why I posted with (= identical? identical)
as well
@andy.fingerhut I only used the (identical? identical? identical?)
as it amused me
clojure.core/= falls back to clojure.core/identical? behavior in many cases, e.g. the arguments are not immutable values.
I would expect as per docs that the following would be true
(= (with-meta identical? {}) identical?)
false
Functions are not treated by Clojure as immutable values. clojure.core/= falls back to clojure.core/identical? when given a function as either arg.
You are probably aware that trying to compare two functions for some notion of "equal arguments gives same return values" is an undecidable computational problem.
> As such, metadata does not impact equality (or hash codes). he's just pointing out a counter example to this claim from the docstring
i think he understands why and the codepath it takes. just pointing out an edgecase in the guarantee from the docstring
Got it. Yes, he has a counterexample. The fact that it is a counterexample, and why it is, makes sense to me from the implementation, and isn't likely to ever change (my guess). Almost no one cares about the results of comparing two functions for equality.
Personally, I would be very suspicious of any code that was using functions (not symbols, but the actual function values) as hash keys, set elements, or in other ways that relied on clojure.core/= behavior. I am sure there is some such Clojure code somewhere, but it sounds like an extremely specialized use case that most people would want to avoid.
so like, the question is, this behavior is inconsistent with the docstring and an implied should someone fix the docstring? and the reason I was discussing the mechanisms and how the behavior arises is, you can come to the conclusion that metadata on functions is bad news by understanding clojure.core/= and with-meta, and come to the same understanding andy has
If we assume for the moment that the implementation isn't going to change to match the documentation mentioned, and changing the documentation is a good idea, the qualification one would need to add to make it correct is pretty small, I think, and would likely only make sense to those with a bit of knowledge of Clojure internals, e.g. "... except for objects that implement IMeta but are not persistent collections", or something close to that.
except there is already a whole parallel metadata universe for things with reference equality
reading https://clojure.org/reference/metadata the one emphasised sentence in italic is the problem... - metadata does not impact equality (or hash codes) ... the actual doc string is ""Returns an object of the same type and value as obj, with map m as its metadata." is slightly more open to interpretation - Same Value.
Starting to get into "angels dancing on the head of a pin" territory with my next comment, perhaps, but I wouldn't be surprised if the Clojure core team did not consider functions as being in the category of "values".
and now we have gone full circle around the contradiction. supporting with-meta implies value, reference equality implies not a value
Wrap a fn in a data structure and then you can compare by value again between equal values (containing fns) with different meta data structures
Not really sure, but it seems like fns could be made to allow it. But to your point, allowing dynamic data on functions is about as antithetical to value-oriented-programming as it can get anyway. It's basically a side effecting escape hatch on everything.
kinda wierd how the page on destructuring documents a function then claims its undocumented
considering this is official clojure documentation, it feels a little wierd to say that clojure.core/destructure
isn't documented
I think they mean in-clojure docs
user=> (doc destructure)
-------------------------
clojure.core/destructure
([bindings])
nil
@beoliver I could easily be missing something, but as far as things that you can call with-meta
on, they must be of class IObj, or something that derives from them, in the Clojure/JVM implementation. Mostly those are the persistent collections, but also symbols (which do not have the issue you pointed out -- they ignore metadata when comparing via clojure.core/=), and functions. Not counting libraries that create implementations of IObj, it seems maybe functions are the only kinds of things built into Clojure that violate the docs you pointed out.
There are more kinds of objects that can have metadata associated with them, e.g. namespaces, agents, atoms, refs, and probably a few other things, but you cannot call with-meta
on them because they do not inherit from class IObj, only the less specific IMeta interface. They cannot violate with-meta's doc string, and I think pretty much the only way supported to attach metadata to those things is to do it when creating such an object in the first place, so they can't violate the docs, either, since you can't create two of them that are = to each other.
You may create an issue for the docs if you are really interested in them mentioning the exception, but it seems like a pretty small one IMO.
At least in the past, docs maintained by the Clojure core team tend to avoid that level of detail.
is this really the easiest way to print to a gzip file using the built-in functionality? am I missing something?
(with-open [os1 (io/output-stream out-file)
os2 (GZIPOutputStream. os1)
w (io/writer os2)
pw (java.io.PrintWriter. w)]
(binding [*out* pw]
...
))
I mostly just feel like four clauses has to be too much
I would think .close
propagates down pw -> w -> os2 -> os1
, so I guess that could be one clause
so (with-open [thanks-noisesmith (-> out-file io/input-stream GZIPOutputStream. io/writer java.io.PrintWriter.)] ...)
you need the name, but
that's definitely nicer; do I need to check with each of the intermediate classes to see if they do propogate the .close
?
or is that a strict expectation on the jvm?
it might depend on how promptly you need that to be freed? I'd imagine the finalizers would eventually know there are no references too.
...deleted?
the claim is that .close
propagates, and if that's true then I can't see how there'd be any noticeable difference
hmm, yeah I don't know
itโs up to whomever implements OutputStream
or Writer
, but I think any built-in implementation of those behaves correctly. Iโd imagine the ones http://clojure.java.io returns do, too.
PrintWriter
docs for close
say
> Closes the stream and releases any system resources associated with it. Closing a previously closed stream has no effect.
which doesn't really seem to address the issue
looks like you can pass the output stream directly to the printwriter though, so that saves a step
yeah - http://clojure.java.io doesn't implement those interfaces, it's just wrappers of some common patterns https://github.com/clojure/clojure/blob/master/src/clj/clojure/java/io.clj