Has anyone ever encountered tricky issues with deadlocking at startup with the clojure.lang.RT class intializer? (Here’s a stack trace that illustrates what I’m talking about https://pastebin.com/1w2bqLun) Here’s what’s going on: Main thread defines an top-level var (which is initialized in the RT class loader) whose value is taken from spawning another thread and blocking on it. That second thread tries to use clojure.lang.RT in normal use (in this case, invoking contains?) which blocks on the RT.java class loader completing. Which won’t ever happen because the two threads are blocking on each other.

Figured this out. TLDR: “user” namespace is treated specially by clojure. Swapping repl init namespace to something else (e.g. foo.user) loads it outside of the clojure.lang.RT class loader and breaks the deadlock.

yes, this has bitten me a bunch of times

be careful what you put in user.clj

my usual solution has been to take user.clj off of the classpath and have a post-init task in leiningen load it manually

(or use Boot which seems to subvert the user.clj loading altogether -- which some may consider a bug 🙂 )

@dinoleif I kind of have a related issue in jira I made about this: https://dev.clojure.org/jira/browse/CLJ-2185

what are you using as a http server with clojure nowadays when http-kit is kinda dead project?

aleph

Pedestal, data driven webservers ftw! 🙂

Is there a reduce that works more in the style of doseq and for?

So I'd like to call a public, static java method from a symbol similiar to calling a clojure a method. That is how could I pass 'Integer/parseInt (possible read from an .edn file) to a function and have it execute? resolve apparently doesn't work on java interop

Hum, I think there was a function that could wrap java methods as clojure functions, so you could pass them around

Try this form:

(. Classname staticMethod args*)

that works but not if you use symbols instead of the actual class names

Hum, the class seems problematic. I was thinking of memfn, but that won't work on static

basically I'm creating a program that accepts Java plugins, and I need to load them from a .edn file. The easiest way to do this would be to have my main program call a static method in the plugin (that's basically what I do with clojure plugins). Unfortunately this seems complicated.

This works:

((eval (read-string "#(Integer/parseInt %)")) "12")

That will. using eval on user input seems...wrong. But I may end up doing that.

Its wrong, if those are not trusted plugins

I'm letting them run arbitrary code anyway, so I'm probably shouldn't be worried about using eval. Thanks

Okay, this also works

And its safer

well, I'm not sure about being safer

but it works and uses the edn reader

(defmacro run
  [f & args]
  `(~(edn/read-string f) [email protected]))
(run "(fn [%] (Integer/parseInt %))" "12")

Sorry, I meant:

(defmacro run
  [f & args]
  `(~(edn/read-string f) [email protected]))
(run "Math/max" 12 34)

You can also have it this way if you prefer to give it a symbol instead of a string:

(defmacro run
  [symbol & args]
  `(~symbol [email protected]))
(run (edn/read-string "Math/max") 12 34)

that works

thanks again

Is there a way to tell environ to load changes from a project profiles.clj without restarting the repl?

The author suggested not to structure the app that way https://github.com/weavejester/environ/issues/16#issuecomment-54326836

I had some what similar need. He pointed me to that explanation https://github.com/weavejester/environ/issues/24

@tap Thank you

in defmulti/defmethod, is there a way to NOT call the multi-method, but to call the dispatch function, to know what it's resolving it?

It's often a good idea to pull the dispatch function out as an actual function so you can test it independently

I have a basic style question on clojure functions. I find it common to need to check a number of preconditions (arg validation etc) before actually executing the body of a function. In languages like groovy/java/x I prefer a number of early if (!condition) return statements in lieu of deep nested ifs for readability. In clojure (with my limited knowledge of it) I tend to end up with just this kind of nested if structure using if and when. I am aware of {:pre x} but pre throws an assertion exception which is not always desirable, the method might just come to the conclusion the data is not applicable but that we are still not at an error condition, i.e. the desirable behavior would in my case be to just skip executing the method. What would be the idiomatic way in clojure to perform these kinds of precondition checks? Or are nested conditional statements it?

There are a bunch of libraries that do this kind of thing

The upcoming spec in core can be used for this too

@alexmiller : the problem I'm having with -is reloading / redefihning defmulti / defmethod at the repl

so I 'know' what dispatch function should be called, but I need to test if it actually is being called

@alexmiller ok, spec could be an option...but wouldn't a spec :pre still throw an assertion exception?

@mbjarland no, you can get plain data from it’s functions

it’s a detailed map with explanation info where the spec failed

it’s really worth looking into, still trying to wrap my head around it 🙂

@nicoschneider right, but you would still end up with logic within your method body with an if (or similar) to check that the data returned from the spec is valid?

valid how?

there’s a way in spec to constrain the relationships between function input and output

@mbjarland what do you mean by “skip execution of the method”? you would need to return some values to the caller

it’s really that general so any validation you could think of can take place

@hmaurer good point, in the particular case I'm on right now this is a side effecting method printing things to the console, so the returned value is secondary, but yes in a general case true and then we end up with an if or when (returning nil)

why last does not has a special case for vectors? It is already (linearly) slow.

to make "working with a vectors" in code as explicit as possible?

last in general should give you slow (linear) expectations

In general, we don't have "special cases". We have traits and collections that implement those traits. The API lib is built on those traits

last is a sequence function that traverses the sequence

If you want fast access to the insertion point, use the stack API (peek, pop, etc)

@alexmiller what is the difference between last and reduce from the "generality" point of view?

(`reduce` is a bunch of special cases combined, as opposed to none in the last)

is there an intuition rule to categorize function either as general (last), or special (reduce), w/o looking up the source code?

sort of similar to "functions operating on collections, take them as last arg, functions for scalars - as first arg"

I don’t see reduce as a bunch of special cases

I really see it as two cases - you are something that can be sequentially traversed or you know how to reduce yourself

both of those have many implementations, but they are the same operation

Let s put it this way: when would anyone want to use first/last on vectors then? Makes the impl a bit pointless

transient support (again, something trait-like, although not done as well) does add a special case to reduce for perf

reduce (being the bottom of many things) has more pressure on it than most other functions

I get that using last on a vector is odd... But first...

both first and last are part of the sequence abstraction. sequences are logical lists. you should reason from there.

generally, most code shouldn’t use either first or last. you should think in collections.

Sure but that's counter intuitive to have poor impls of these for vectors. Would it have any bad implications/cost to do something reasonable in that case?

if you particularly need access to the ends of a collection, it’s usually because you are using it as a stack or a queue, etc. choose a data structure that’s good at those things, then use the ops that are designed for that usage.

it is absolutely not counter intuitive. it is exactly about making operations have intuitive meanings and performance implications.

coming from scala, where every possible operator is implemented for every possible collection, I found clojure's consistency on performance very refreshing

As I said I can somewhat understand why last is like this, doesnt make much sense to use it on a vec. But first is way more common/widespread. Ultimately lot of people are probably using it the wrong way and just expect the impl to be more forgiving

To be clear, I am not arguing that vector should be slow on first. What I care about is the expectations you should form about operations.

and that everything should start from a consistent model of operations and collection traits

in that framework, there is opportunity to provide polymorphic implementations with better performance

@alexmiller playing devil's advocate, if the claim is "last is defined to be linear", constant time is technically O(n)

which is covered by what I just said - you should have expectations based on the op, but no one is going to complain if you’re faster

so it wouldn't be incorrect to have last work constant time in vectors and still claim that it's linear, altho I understand the rationale of worse is better to encourage users to not rely on non promised performance optimizations

I’m not claiming worse perf is better

sorry, didn't mean to imply you did

that's how i rationalize last being linear on vectors in my head

I’m claiming that having a strong conceptual model and an implementation based on traits/interfaces is tremendously valuable

and I’d say that’s more important than having an op be faster than the expectation you should have for that op

to give an example where this has come up in a very nuanced way - we rewrote range to be reducible in 1.7

oh, reduce is "bunch of special cases" in clojurescript:

(cond
       (implements? IReduce coll)
       (-reduce ^not-native coll f)

       (array? coll)
       (array-reduce coll f)

       (string? coll)
       (array-reduce coll f)

       (native-satisfies? IReduce coll)
       (-reduce coll f)

       (iterable? coll)
       (iter-reduce coll f)

       :else
       (seq-reduce f coll)))

and those similar things exist in Clojure - but I consider them to be polymorphic implementations under an abstraction, not special case. but maybe that’s splitting semantic hairs.

no, I mean usually you have a collection and you transform it through a series of sequence or transducer operations to another collection.

if you’re accessing or updating individual items in a collection, you should use a collection operation (get, nth, contains?, update, etc). first/last are only really collection operations on a list or a seq, not on a vector.

so, first is interesting b/c its part of ISeq which includes first/next/more

where more is really derivative of next

it is tempting to say that the perfect number of operations in an interface is 1 and this interface has several. ISeq could conceptually be a composite of “has a first item” and “has more items” which could be separate smaller interfaces

and vectors could provide a more optimized implementation of the smaller “has a first item” interface

is all that worth doing to save a few ns? that’s a matter of taste and design.

coming back to intuition and readability question: operating on/from the sequence head, random (key/index) element access, and operating on/from tail should use different data structures, and it should be obvious by looking at the code? Basically, you need to pick one of those 3 realms, and only then appropriate abstraction's interface: eg. make it obvious you are working with the tail by using peek, and then choose vector or queue, etc. under the hood all you want.

I would start with: what ops do I need to do on a data structure. Then, choose a data structure that can do those things well. Then, use the best expression of those ops (peek, not last).

if you followed that, you would never get to the point of asking why first is not faster on a vector

and I would say the “realms” are a little different: indexed access, list/seq like access (first/rest), FIFO, FILO, etc

both lists and vectors work great for FILO (stack) ops using peek/pop

but lists have a head insertion point and vectors have tail insertion point

I actually don’t know which of those is faster off the top of my head. both are fast. :)

depends on how big the vector is

does it?

yeah IIRC if the vector has to grow a node then cons is faster

but I've benchmarked this a long time ago

I might be mistaken

well I will agree that vector has the potential for more variability

and by cons i mean conj on lists

TIL peek works on lists

based on a quick test, I’d say lists are faster as stacks :)

If I need to reverse vector, what is the best way to do it? Size is < 100, or even < 10. Does it even matter?

I need to traverse seq till about half way from head, and what's left - from tail

you can use a vector for that

rseq reverses a vector in constant time

gives you back a sequence not a vector but for linear traversal it should be fine

or call nth a decrementing range

that too

sweet, thanks

Hi, is there a shorter/nicer way to achieve (and num (pos? num)) ?

i don't know about shorter but clojure.spec ?

(fnil pos? -1)

(some-> num pos?)

1.9 has pos-int? which is close

i always forget about some->

https://clojure.org/guides/threading_macros

Hi. Anyone familiar with clj-http? I want to dump the certificate chain when connecting to an HTTPS server and can't find a clue how to do that. I guess, I need to somehow get at the connection object and then do sth like https://stackoverflow.com/questions/7199129/how-to-get-server-certificate-chain-then-verify-its-valid-and-trusted-in-java but how to get the connection? Or is there a better way?

My coworker released a library for making life a bit easier with verbose Hiccup forms https://github.com/ayato-p/kuuga . Thought it may be interesting.

what is a globally accepted word to designate types which can be derefed and add-watch/`remove-watch`ed ?

reference types ?

identity types ?

@leonoel IRefs https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/IRef.java

Is there an easy way to allow function calls in arguments to a macro? (e.g. reduce to immutable types)

no

E.g. reduce '({:a 1} (do-stuff 2)) to the result: '({:a 1} {:stuff 2})

Hmm, ok.

for exceedingly simple cases you can have your macro call eval on its arguments, but that will (depending on use of the macro) very quickly run in to issues

if you need evaluated arguments, write a function

Yeah, it won't work in this case. That's what I'll need to do. I was hoping I could get this to happen at compile time, but that's alright.

Is it considered non-idiomatic to have a function with arity 2 and 3, like this:

(a b)
(a c b)

(e.g. arity 3 pushes the last argument to the end, and inserts one in betwen

in general it's a bit strange and a potential pitfall for callers of the function, but clojure.core/reduce uses this approach when inserting an initial argument https://clojuredocs.org/clojure.core/reduce

there’s a few others too, like make-array

@joshjones thank you! I just realised even defn takes that approach with docstrings

or fn, with optional names

or condp, with the magic :>> arg

Does anyone using cljfmt know if there is a way to align assoc like so:

(assoc {} :x "x"
          :a "z")

(assoc {} :x "x" 
       :a "z")

I think there needs to be a way to control the amount of indentation, rather than where the indentation occurs.

my workaround is just to move :x down to the next line

I don’t think cljfmt as is is clever enough for the one you want