@arrdem #clojure-spec 🙂

I was poking around tools.namespace and I found it interesting that the implementation of remove-lib is:

(defn remove-lib
  "Remove lib's namespace and remove lib from the set of loaded libs."
  [lib]
  (remove-ns lib)
  (dosync (alter @#'clojure.core/*loaded-libs* disj lib)))

I suspect it's more about backward compatibility and legacy code -- but it's a good question and I'd love to hear the core team explain the background for it.

I think it is because clojure.core/require adds namespaces to clojure.core/loaded-libs as they are loaded, and checks that list of namespaces before actually loading the code, to avoid loading namespaces multiple times unnecessarily.

Here is a link to functions load-one and load-all in clojure.core namespace, which are called to do actual namespace loading when you call require, use, etc. https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L5843-L5866

Oh, sorry, the question is why loaded-libs exists. Don't know, but it has been around since very early versions of Clojure.

^ Yeah, I suspect "backward compatibility" is the real reason this still exists...

...which is a perfectly good reason! It's why we can consistently take alpha and beta builds to production and why Clojure version upgrades are mostly so painless (unlike certain other languages!).

Looks like it was added Aug 2008, when ns macro was added.

(and why are you awake and online at quarter past midnight?)

Accretion is good. Not removing things is good.

I was surprised they removed a predicate during the 1.9 alpha/beta process -- that broke our code!

(an easy fix but...)

Because it was an exact replica of an existing function, but with a different name? Yeah, probably because Alex Miller knows how much each var causes in Clojure init time 🙂

snerk

Yes, I didn't know about the function it replicated, my bad, so I just switched our code back to that (we had all of two instances of it, as I recall). I consider that the "bleeding edge tax" and Clojure is one of the only languages where I've felt that is worth paying!

We've been using clojure.spec in production since the early alphas of 1.9 and it's been so totally worthwhile!!

And we thank you for paying that tax

Alex was actually teasing me for not already being on 1.10.0-alpha2 🙂

(we are multi-version testing against master-SNAPSHOT all the time tho'!)

Huh. Total lines of text in all Clojure repo files (Java, Clojure, README, etc.): 301K. Total line of output in 'git log -p .' (full list of all changes made as diffs, with a couple of lines of context on each one, even: 586K

As soon as we find out what -secret project- is because it is in alpha4, I imagine you will move then

Interesting stats. We're currently at around 75K lines of Clojure (about 55K production and 20K test).

Yeah, Alex has been unusually teasy about that. It is somewhat annoying that these projects just "drop" into master but the care taken with them has usually been worth the "secrecy".

I just spent most of yesterday and some of today bringing boot-tools-deps up-to-date against tools.deps.alpha (which is way more changeable than almost anything I've tracked in Clojure in seven years!). Nice to have Git and local deps projects fully supported.

We'll probably jump to full-on tools.deps as a basis for our multi-subproject mono-repo soon but it's still a bit too "soft" even for me...

I have the perhaps bad habit of being on-line many hours a day, some for work, some for hobbies, anyway, and trying to get back to a more sane local time sleep schedule. In fact, heading AFK soon.

I was reminded how long it takes to transcribe 1 hour of video this weekend while transcribing Stuart Halloway's talk "REPL-Driven Development". Looking for a place to publish it where people can easily find it.

Guess I'll stick it in a public Github repo I have now, with a link to it in the comments of the video here: https://vimeo.com/223309989

Security help anyone ?

@andy.fingerhut That is a great talk that I keep watching over and over -- and referring people too, repeatedly!

@buzzdan I doubt there's anything off-the-shelf for that. I think you'd be better off with a standard web application firewall in place instead of trying to reinvent that yourself.

What's the best way to turn existing map with unqualified keys to a namespaced map? Let's say I have a map {:id 1 :name "read-only"} and I want to turn it into #:role{:id 1 :name "read-only}

@jumar, you have to alter the keywords one by one. that it prints that way happens at the reader / pr-str level. so, (into {} (map (fn [[k v]] [(keyword "role" (name k)) v]) {:id 1 :name "read-only"}))

@andy.fingerhut perhaps a PR to https://github.com/matthiasn/talk-transcripts as well?

besides writing

(fn self [...] ...)

what does smallest containing function mean

(fn [] .... <-- FOO
  ... ME1 ... 
   (fn [] ... <-- BAR
     .. ME2 ... )
  .. ME3 ...
)

what is the formal term I should be using ?

current enclosing function makes sense to me

and no, there’s no other way than to name it

got it; thanks

I'd like to thank everyone who contributed so dearly to the discussion (yesterday) on how to start off the "data scientist, no/little OO exposure and little programming knowledge person type" on a productive clojure trajectory!

what's wrong with:

(defn foo [{:keys [::depth ::inc-by]
                           :OR {::depth 0}
                           :as state}]
...)

err,

(defn foo [{:keys [::depth ::inc-by]
                           :or {::depth 0}
                           :as state}]

should be :or {depth 0}

ah, so it's 'name as symbol' and not 'name as keyword' okay; thanks

the :or map always has the local symbols to bind as its keys

What do people use for searching XML with Xpath in Clojure? I’m using https://github.com/mudge/riveted but I’m wondering why it’s not more popular.

Is there any reason this doesn’t work in post conditions?:

{:post [nil?]}

@martinklepsch You should use % as the result of the function. Run this:

(macroexpand
  '(fn [x]
     {:post [nil?]}
     (fn-body x)))

yeah, I realized that, just wondering why that is, seems… weird?

I actually made the same mistake for months until I realized I was never actually checking anything since the val is just truthy

yeah, seems to me that unknowingly specifying post-conditions that will never fail is pretty easy

what do the matchm, matchv and match-let macros in core.match do? they don’t seem to be documented at all

There was discussion about some improvements to :pre :post validation but never got merged https://dev.clojure.org/jira/browse/CLJ-1473

hello! Do I need a doall when into is already there wrapping a pmap expression?

(spit "test.txt" (time (into [] (pmap inc (range 10000000)))))

(spit "test.txt" (time (into [] (doall (pmap inc (range 10000000))))))

Hey guys I asked this in beginners chat but no one help me, maybe someone can do it here so: my question is that: how can I count key-value to a new object some like this: input -> {:type1 [{:type type1}] :type2 [{:type type2} {:type type2} {:type type2}]} output -> {:type1 1 :type2 3}

@victtorferreiralima

(->> {:type1 [{:type ’type1}] :type2 [{:type ’type2} {:type ’type2}  {:type ’type2}]}
     (map (fn [[k v]] [k (count v)]))
     (into {}))

@victtorferreiralima depending on how you got that data, you might find it easier to use frequencies instead of group-by (that looks like the output of group-by)

user=> (frequencies (map :type '[{:type type1} {:type type2} {:type type2}  {:type type2}]))
{type1 1, type2 3}

oh, you need (comp keyword name) if it needs keywords as well

I tried use frequencies by I got diferent result I think that a don't use quote

so it would become (map (comp keyword name :type) ...)

@victtorferreiralima quote is an instruction to the reader telling it not to evaluate something, it isn't needed in output

but if what you really want is keywords, the above will fix it (@martinklepsch’s example also gives you symbols as keys, but could use the same keyword / name trick in its mapping if needed)

@rauh @martinklepsch I believe the Eastwood linter should warn about most such trivially-true pre and postconditions.

@andy.fingerhut I took this to #clojure-dev

And its docs for the warning give examples of the wrong and right way to do it. https://github.com/jonase/eastwood#wrong-pre-post

(r/fold
                   conj
                   (r/map (fn [base_item]
                            (r/fold
                              conj
                              (r/map (fn [target_item]
                                       (r/filter (match-percent-logic base_item
                                                                      target_item)
                                                 [(:din base_item)
                                                  (:din target_item)]))
                                     items)))
                          items))

r/fold is likely not going to be useful to you

r/fold needs to work over a full realized tree shaped datastructure to be useful

the reducer combinators return a thing that can be reduced

agree with hiredman about utility

conj is likely not going to work well for r/fold too

oh - I had suggested reducers as a way to simplify parallelizing the combinatorial comparison

but maybe something else is more appropriate - likely even

r/fold needs a reducing function and a combining function, some things like + can work for both, but conj isn't going to

(mapv (fn [base_item]
                         (mapv (fn [target_item]
                                 (when (match-percent-logic base_item
                                                            target_item)
                                   [(:din base_item)
                                    (:din target_item)]))
                               items))
                       items)

original loop we are trying to optimize ^^^

oh, actually, r/map and r/filter are folders, so r/fold will flow through

maybe try replacing (r/fold conj ...) with (r/fold cat conj ...)

I think your r/filter call inside the function passed to r/map isn't correct

which is are getting all those weird objects back, you are getting the reducible results of the filter

that should likely still be the (when ...) logic from the original version

I took out the r/filter and it worked well 🙂

how large is items?

100,000 plus

Is there some way to bust open and introspect a reify produced object?

is this a known eastwood issue?

== Linting penguin.babysit ==
Entering directory `/media/justin/806084F16084EEEA/clojure/penguin'
src/penguin/babysit.clj:60:21: wrong-arity: Function on var #'clojure.core/eduction called with 3 args, but it is only known to take one of the following args: [xform* coll]

that * is supposed to represent a variable number of xform args

there was a whole mailing list thread a while back somewhat related to this. some tools attempt to use :arglists metadata to mecahnically check things, but some :arglists are written in such a way as to provide nicer documentation, not mechanical checking

(this was years ago)

yeah, I recall similar conversations on IRC

I'm just surprised something like that is not addressed - I guess not many folks are using eduction, and of those even fewer are using the variable number of xforms feature

it does seem weird that you would attach an arglist specically prettified for human consumption as a data structure though

https://github.com/jonase/eastwood/issues/124 might be a place to dig in to

so there might be a config to explicitly tell it what to accept

@noisesmith If you mean not addressed specially in Eastwood, I don't recall any special checking for particular functions to change how the arg count warnings are done for particular ones. At least not right now.

For the reasons mentioned above, at least one approach would be to enumerate a list of known core functions that manually override :arglists for 'human readable purposes' vs. the purpose Eastwood more often uses them, and either do custom checks for those, or no checking at all.

I'm mobile for the moment, I can make a small repro later- code that education is meant to handle and Eastwood rejects

Thanks for the info, that's something to think on

Well, the beauty of Eastwood is that as long as you don't put it completely in the way of compiling and running your code, it doesn't actually reject anything 🙂 But yeah, false positives are very annoying, and Eastwood still doesn't have a general way to silence individual warnings on particular blocks of code.

e.g. specially formatted comments to suppress particular warnings, as many lint-type tools have

Yeah, my install and deploy tasks just fail on Eastwood warnings, this is a good filter to keep junk artifacts out

But ever so rarely it warns about something that I don't want to work around or fix

I’m trying to update a project (not mine) to use clojure 1.9. It’s configured with Leiningen (and Monolith. This is a sub-project that’s failing). When I try to run lein test it fails during initialization when it tries to compile clojure/core_instance18.clj. Specifically, I get: Unbound: #'clojure.future/Inst is not a protocol This file extends the clojure.core namespace, but it looks like it’s decided that Inst is supposed to come from clojure.future, and I can’t figure out why. I’ve been at it a while, but I’m stuck. Does anyone have a suggestion where I could look please?

is it an aot project? have you deleted any class files laying around on disk?

I don’t believe that it is. I’ll check to see if any classes exist

it looks like you are loading https://github.com/tonsky/clojure-future-spec and it isn't doing the right thing

ah… if I am, then that’s wrong. I tried to remove it

https://github.com/tonsky/clojure-future-spec/blob/master/src/clojure/future_impl.clj

we ran into some clojure-future-spec vs 1.9 issues and eventually a coworker made a clojure-past-spec project to backfill the old namespaces until libs upgrade

ah… it might be a dependency that’s using it

thank you!

lein monolith with-all deps :tree might help you track it down, otherwise you can look at the projects one by one