Fork me on GitHub
#clojure
<
2019-09-04
>
viesti08:09:46

Hmm, wonder why into has a single argument version: ([to] to)

👍 1
andy.fingerhut09:09:53

Probably because then (into something) is the same as (into something []) ?

bronsa09:09:15

reduce into

lodin09:09:07

@schmee I saw your announcement of daguerreo. Since tasks typically take a little while, and have side effects, it would be nice to have a mechanism to check that I have specified the correct dependencies. Now, if I need :diced-mango (in the README example) I need to specify :dice-mango as a dependency. And I need to know that :blend is the task that provides me with :smoothie, etc. Have you any thought on how to accomplish any "integrity" check of the job?

schmee18:09:15

hey, thanks for checking out Daguerreo! tasks are validated before they are run to ensure that all dependencies that are specified are present. as for ensuring on a key level, there is nothing like that yet. I’ve been toying around with the idea of specifying :input and :output to tasks, to say that “this tasks provides these outputs and requires these inputs”, but I haven’t decided whether to put that in or not. Is that something you would find useful?

lodin19:09:03

@schmee If I would use Daguerreo I would add something like that to it. I would probably even write a macro to handle the common case, i.e. takes a bunch of keys and writes to a single key. Something similar to prismatic's graph fnk macro, perhaps.

yuhan10:09:49

what's the 'idiomatic' way of removing a tap which I've lost a reference to?

yuhan10:09:34

eg. I define a tap function

(defn my-tap [x]
  (print (keys x)))
(add-tap my-tap)

yuhan10:09:11

then realise I made a mistake and go back to re-eval my-tap

yuhan10:09:25

(defn my-tap [x]
  (println (keys x)))

yuhan10:09:36

now I can't use remove-tap to get rid of the initial tap fn, because #'my-tap points to the new fn

yuhan10:09:59

under the hood there's a clojure.core/tapset atom which holds all the taps, but even that's private so I can't reset it without resorting to some namespace hack

sogaiu10:09:21

iiuc, there isn't an idiomatic way -- what you mentioned at the end about the namespace hack is the only way i know of -- happy to hear otherwise 🙂

yuhan10:09:16

here's the ugly hack I used:

(binding [*ns* (the-ns 'clojure.core)]
  (eval '(reset! tapset #{})))

sogaiu10:09:36

worked fine here 🙂

yuhan11:09:28

that's pretty unfriendly for a REPL-driven development workflow 😕 I just started trying to use tap> and immediately ran into this issue

yuhan11:09:46

Perhaps a reset-taps! function in clojure.core would be a good idea

sogaiu11:09:44

i agree it is inconvenient and unfriendly -- i wish i knew more about the background design for tap>. my sense was that there was something intentional in not providing a key when registering the function originally (like with add-watch). may be it's a good question for ask.clojure?

emccue10:09:36

Would there be a reasonable way of writing something like python's functools.wraps in clojure?

emccue10:09:43

im occasionally frustrated that the naming of wrapped functions goes to annonymous gibberish

emccue10:09:11

case in point this function

potetm12:09:28

(fn foo [& args] ...) instead? The stacktrace will have foo in it.

markus10:09:39

@emccue Where is the gibberish?

yuhan11:09:37

@emccue you could pass the :doc and :arglists keys of the original function metadata to the new function

lodin11:09:16

@emccue You want a macro for that. You can resolve the symbol to its var and get the metadata.

valerauko11:09:11

you can name functions

valerauko11:09:24

(fn cached-function [& args]

lodin11:09:04

@vale I think he wants the name of the passed in function.

valerauko11:09:56

oh. if the function is passed in then you don't even need macros, you already have the function "object" in your hands

lodin11:09:40

But not the name and doc string.

emccue11:09:42

i could do a regex on the tostring

emccue11:09:50

it would be evil but i can do it

vlaaad11:09:09

Funny encapsulation experiment:

(ns encapsulate)

(defn encapsulate [x]
  (if (instance? clojure.lang.IObj x)
    (let [ns *ns*]
      (vary-meta x assoc :type ::encapsulated ::ns ns))
    x))

(defmethod print-method ::encapsulated [x writer]
  (if (= *ns* (::ns (meta x)))
    (print-method (vary-meta x dissoc :type ::ns) writer)
    (print-method "***" writer)))

(ns boop)
(def x (encapsulate/encapsulate {:a 1}))
(prn x) ;; => {:a 1} 

(ns woop)
(prn boop/x) ;; => "***"

not-sure-fry 1
vlaaad11:09:46

I know there is a popular idea that there is no much value in encapsulation when all you have is immutable values, but I still sometimes find it useful to use "soft" encapsulation as a way to say "treat this value as a black box, it's shape is implementation detail that belongs to that namespace only"

lodin12:09:07

@vlaaad I use namespaced keys for that.

vlaaad12:09:23

it's a PoC 🙂

Akshay14:09:03

is there anyone using Open JDK in production with Clojure? what are the odds of oracle changing its license and end up killing it? I ran into this discussion today with one of my friend who is moving from JVM to Elixir/beam. because he does not trust oracle anymore.

Akshay14:09:10

I don't have much experience with JVM and its ecosystems. I am looking for your thoughts and point of view. Thanks

ghadi14:09:33

no problem with the license

ghadi14:09:48

it's GPL... forever, many different companies behind it

ghadi14:09:59

RedHat, Amazon (corretto), Azul, IBM

ghadi14:09:48

moving from JVM to Beam is a far bigger risk IMHO

2
👍 3
James Adam14:09:16

Used OpenJDK, using amazon corretto for some stuff now

Akshay14:09:37

@ghadi Oh thanks that clears it up

roklenarcic14:09:52

ever since I upgraded java from 8 to 12 I've been getting a lot of errors in lein plugins:

Caused by: Syntax error compiling deftype* at (clojure/core/rrb_vector/rrbt.clj:282:1).
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:7115)
	at clojure.lang.Compiler.analyze(Compiler.java:6789)
Caused by: java.lang.IllegalArgumentException: Must hint overloaded method: toArray
	at clojure.lang.Compiler$NewInstanceMethod.parse(Compiler.java:8497)

alexmiller14:09:54

yeah, they added a new Collection toArray arity that made certain calls ambiguous re reflection that were not previously ambiguous

alexmiller14:09:08

that particular error above was fixed in latest rrb-vector iirc

roklenarcic14:09:47

so I have added dependency to rrb-vector 0.0.14, now it works

eraserhd19:09:47

Is there a function somewhere to test whether one nested data structure is a subset of another? e.g. if the left has a key, the right must, recursively?

eraserhd20:09:12

leaves are =.

andy.fingerhut20:09:08

I do not know of anything exactly like that included with Clojure. clojure.data/diff has some similarities to what you are asking, but looks for differences recursively between two values.

eraserhd20:09:31

oh, I think that's exactly what I need.

andy.fingerhut20:09:51

If not, you can copy its code and tweak it to your heart's desire.

alexmiller20:09:14

specifically for nested maps really. this is testing code so it's kind of tailored to the job of "is the stuff I'm looking for a subset of the nested maps that I got"

eraserhd20:09:35

well, same situation here: characterization tests that ensure that I don't break existing bus messages, where I can add fields but not remove them or change them.

eraserhd20:09:39

diff ends up being nice, because I can say (is (empty? (unmet-requirements msg requirements))), where unmet-requirements returns just the things only in requirements.

eraserhd20:09:59

Then, test errors are nice to parse.

andy.fingerhut20:09:20

also perhaps nice to print/save the differences if a problem arises, for debugging

alexmiller20:09:49

there are interesting choices for stuff like this in collection values. Rich and I have talked about adding something like this to clojure itself (flip the args and maybe call it subsumes? or something)

eraserhd20:09:09

Seems related to the data shape problem from Rich's last conj talk.