Ahh, ok. I guess I can recall normally without TCO… As a trie, it’s not too deep. Will have to check.

Thx @hiredman and @bfabry !

you can just create your own recur frame using loop

Hi, I am learning the reader conditional, and I tried this code in repl. I found it not returned as I expected, as showed in the 3rd and 5th expression, I thought these will return “CLR”:

user> (read-string {:read-cond :allow :features #{:cljs}} "#?(:cljs \"ClojureScript\" :clj \"Clojure\")")
"ClojureScript"
user> (read-string {:read-cond :allow :features #{:cljs}} "#?(:cljs \"ClojureScript\" :clj \"Clojure\" :clr \"CRL\")")
"ClojureScript"
user> (read-string {:read-cond :allow :features #{:clr}} "#?(:cljs \"ClojureScript\" :clj \"Clojure\" :clr \"CRL\")")
"Clojure"
user> (read-string {:read-cond :allow :features #{:clj}} "#?(:cljs \"ClojureScript\" :clj \"Clojure\" :clr \"CRL\")")
"Clojure"
user> (read-string {:read-cond :allow :features #{:clr}} "#?(:cljs \"ClojureScript\" :clj \"Clojure\" :clr \"CRL\")")
"Clojure"
user> (read-string {:read-cond :allow :features #{:clr}} "#?(:cljs \"ClojureScript\" :clr \"CRL\")")
"CRL"
user> (read-string {:read-cond :allow :features #{:clr}} "#?(:cljs \"ClojureScript\" :clr \"CRL\" :clj \"Clojure\")")
"CRL"
user> (read-string {:read-cond :allow :features #{:clj}} "#?(:cljs \"ClojureScript\" :clr \"CRL\" :clj \"Clojure\")")
"Clojure"
user> (read-string {:read-cond :allow :features #{:cljs}} "#?(:cljs \"ClojureScript\" :clr \"CRL\" :clj \"Clojure\")")
"ClojureScript"

I found the :clj form must comes the last to get the read-string to work well.

the doc https://clojure.org/reference/reader said “However, note that the Clojure reader will always inject the platform feature :clj as well.” Does that because of this?

That sounds like the most likely explanation.

Is there a good online resource for the subtleties of deftype? I’m trying to use a Java array as an unsycnhronized-mutable field, and getting some weird behavior when trying to use aset (This is non-idiomatic, performance-sensitive code)

I get an ArrayStoreException when using aset inside the the type, but similar code produces no errors at the REPL

Is there some weird interaction between set! and aset going on?

Today in extreme overuse of Clojure: I wanted to pretty-print json in color from the command line. 7-line Python script with pygments only worked from local directory but not from $PATH for totally mysterious reasons. So I rewrote it in 11 lines of Clojure. Amusingly, it turns out that Clygments pulls in, among other things, all of Jython. So my 11 line trivial thing is a 40mb(!!!) binary. But, by god, it WORKS FROM THE PATH. https://github.com/paultopia/cloppjson

I am querying an integer array in postgres database using clojure.java.jdbc. The result is coming back as an org.postgresql.jdbc4.Jdbc4Array. Is there any simple way to get this to coerce back into a clojure vector?

@gowder: That's amazing. I love it. I just spend like 30 seconds going, "Oh yes. Oh no. Oh yes. Oh no..."

@seancorfield Hi, I still do not understand why the :clj will intercept :cljs and :clr form. What does the inject the platform feature :clj mean in “However, note that the Clojure reader will always inject the platform feature :clj as well.” ? Thank you.

is there any project which provides erlang like processes on top of clojure via core.async (for the mailboxes)

pulsar I think, not sure how reliable this is tho. It's not easy to replicate these on the jvm

@gowder: FWIW, jq (https://stedolan.github.io/jq) also works for pretty-printing JSON with colors.

is there a cleaner way make a postwalk with state (without atom): https://gist.github.com/razum2um/b691ad0d760795efaeb886e6caf05122 ?

Hi, why does transducer here returns a vector rather than a list?

user> (def xf (map dec))
#'user/xf
user> (transduce xf conj (range 10))
[-1 0 1 2 3 4 5 6 7 8]

the zero of conj is []

because you don't provide an init, transduce is going to use that

Ahh… Thanks!

if you provided () you'd get (8 7 6 5 4 3 2 1 0 -1) anyway not [], since seqs conj to the left

:thumbsup: 😄

@cmal If you want a lazy seq as a result of applying your transducer, check out https://clojuredocs.org/clojure.core/sequence

@flowthing did not know that, thanks!

I was watching this talk of rich hicky https://www.youtube.com/watch?v=oyLBGkS5ICk

i didn't get exactly what he meant about the solution instead of semantic versioning for functions, NSs and artifacts

can someone please help me understand this 🙂

One takeaway from this is that the interface to your public functions which are used by others should not change as you release new code. Much in the same way data is by definition immutable, and the lion who jumps is not the same lion who lands (paraphrasing here), the interface to your functions, once exposed, should not change. This also means they should not be removed if at all possible (or arities removed, or type of return change, etc). Better to call a function foo2 than to change foo and break lots of other code which depends on it. @lxsameer

@lxsameer He's saying that sem-ver doesn't actually /solve/ the problem of breaking changes, it just brushes it under the rug. A better way to "solve" the problem of breaking changes is not to make them.

well put

good , so basically for changing a namespace i have to create new one ( ofcourse it was not possible to change it and keep the old interface at the same time) , right ?

what about artifacts ? should i create a new one ?

'artifacts' is a weird way to talk about it, I think. His example of python was good

If your library has changed so much it won't work with previous versions, it needs a new name

Because, let's face it, Python2 and Python3 are different languages, and both will have to be maintained separately until the end of time

yeah that's right

changing a namespace is ok if the contract is respected adding new functions is ok correct a bug is ok improve perf is ok make a function accept less is ok make a function return more is ok etc etc...

"make a function return more" <-- can you elaborate?

e.g. it could return a map with extra keys

yes -- though this gets into hairy territory, and gets into what expectations the caller has, even if they aren't explicitly guaranteed by the callee. If a function has been known to always return {:a 1 :b 2} and the function now adds a new k-v to this, then equality checks which expect only :a and :b (even if incorrectly, as they should select the keys they need) will fail ... it's not an unlikely scenario

fair enough

This is a Leiningen specific question, but what's the difference between :dependencies and :plugins on the profile configuration file?

@rinaldi plugins are about modifying / enhancing leiningen itself. dependencies are your code's needed libraries

@ghadi Oh gotcha, that makes sense. Thank you.

Where can I find a good writeup on the differences of cljs/core.async and clj/core.async . It seems like there should be some fundamental differences since browser js is single threaded; but I don't know enough about it to dcerive all tye implications.

@qqq I think the main difference is that thread >!! <!! alt!! et al have no meaning, so you use go >! <! alt! instead always. I found David Nolen's blog posts on core.async the best intro to it, and they're all written in cljs, so that might be a place to start

they share no code, if you can believe it

that makes sense when I think about it but that's rather impressive

@hiredman: they are two separate impls that happen to have a similar API ?

yes

when usint (chan 10), this is a chan with at most 10 elements. is there a way to tell put! or >! on this channel to return an error instead of blocking ?

this is called "back pressure" right ?

David Nolen has mentioned in the past that a certain layout was kept in cljs code to keep the diffs from clj simple

so there may not be explicitly shared code, but they at least look at the diffs in respect to the two repos

yeah that's back pressure. you can use offer! for what you want

unless I totally misunderstood him

@bfabry : nice, thanks

and poll! is the receive equivalent

alternatively use alt! with an optional timeout channel

right, I'm familiar with the alt trick, but was not aware of poll

@qqq well, put! will never block/park, but you can only have 1024 pending puts

though I think in general, I'm okay with the 'taker' blocking, but the 'putter' sometimes need to tell stuff to backfoff

>! will park on a full buffer, >!! will block, and put! will always succeed, unless the pending puts limit of 1024 is reached, which means that you are doing too many async puts @qqq

park = suspends go thread, blolck = suspends os thread right?

yes, in the context of cljs >!! doesn't make sense

park means “let someone else use the thread your go is currently using”

because, one thread, if we block it, how could the channel ever clear

right since it would block the mani js thread, and the system deadlocks

@qqq pretty much, yes -- park means "save the state of this thead, and let another piece of code use it"

go blocks describe a series of continuations delimited by parking operations, and it’s helpful to avoid calling them “threads” since threads are real things that we use

and in line with what noisesmith just said, note that unlike preemptable native threads, code executing in a go block must relinquish control (to other, parked code) in order to pause execution, so the semantics of threads and go blocks are not the same, even though threads are the vehicle used to execute the code in a go block

right; go blocks ar e'inverted' at interaction with channels

so a (while true) can inf loop a goblock, which would infloop the thread it's running on

the go macro in particular is very different between cljs and clojure, the clojure one uses tools.analyzer

the cljs one uses what is effectively a custom analyzer

the clojure go macro tries to avoid splitting code that it doesn't have to, but the cljs just splits everything (if I recall)

I heard it is one of the most complicated clojure macros of all time

what motivated you to wake up one morning and decide "today, I will read the go macro" ?

the clojure one I read because I wanted to see how they decided to do it, the cljs one because I wanted to fix bugs in it

the fact that it is a macro isn't all that interesting, it is really a compiler from source language to target language

the source language and target language happen to be the same language

it is neat. just core.async effectively contains two different compilers. compilers tend to be complicated and have odd bugs and edge cases, and having two distinct ones mean bug fixes in one may or may not translate over

cljs core.async has other interesting issues, because macroexpansion in cljs can return what is effectively a blob of javascript, which the core.async analyzer cannot analyze

https://dev.clojure.org/jira/browse/ASYNC-128?focusedCommentId=45035&amp;page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-45035

@lxsameer Yeah... I quite like the approach given by Carlo Pescio: http://www.carlopescio.com/2012/12/ask-not-what-object-is-but.html It's about: minimize the sum of the size of artifacts you change. - Or: don't change things, just add stuff

Simple rule, not always very simple to implement, but it's been very helpful to me ever since I read his blog.

just, given some code that running it under cljs with core.async and under clojure with core.async, what are the odds the code runs the same given that cljs and clojure don't share code, core.async cljs and core.async clojure don't share code, and whatever js runtime you pick may or may not share some amount of code with the jvm you pick

the only thing there to make them behave the same at all is eternal vigilance

when an offer! fails, is there a way in a go-block to say: I'm going to chill for a bit, let other blocks run ?

that's exactly what alts! with a timeout will do

unless I'm misunderstanding

@qqq more generally, you could just read from anything, even if you know it returns instantly, to give the go scheduler a chance to change things up

I think…

or write to something, for that matter

(alt! (timeout 1) :write-failed [[put-port put-val]] :write-succeeded)

@bfabry : good point; I somehow failed to make that mental connection; thanks!

hi, is there any way to send a client certificate (.crt and .key) in a Get request? in clojure

I am trying with Http.client but i cannot see the option

also tried with http kit

and no success

@alricu I believe you have to create a keystore (client cert / key), and a truststore (CA). Then you pass it as an option to clj-http https://github.com/dakrone/clj-http/#keystores-trust-stores

SSL in java is just the worst

way easier in most python libs or go

creating the keystore involves a baroque set of cli commands that you have to look up even if you've made them 1000 times

https://github.com/hiredman/selfsigned

not that helps, because you likely have a cert to start with

grab lock
 ... do some work
release lock

locking

there’s good reason to prefer lock free stuff, but locking does what you just described

the jvm lets any object used as a lock, called a "monitor", which is what locking does

https://clojuredocs.org/clojure.core/locking <-- whoa, was unaware of this

generally it is better to use a purpose made lock than locking, if you need to lock

you usually are better off with a design that doesn’t use it

https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/package-summary.html

I need an "atom" where the swap! is NOT re-entrant ... where (swap! a f) <-- f is called 0precisely once

use compare-and-set!

you can’t really have correct code with precisely once can you? at most once is reasonable

this is not for network delivery

(as opposed to swap! which is at least once)

well, you can’t have exactly once semantics over a network period

I don't think compare-and-set! works; it might evaluate f on an old value

@noisesmith: you can't reason about computer programs unless you have 'precisely once execution of functions locally'

when a test.check run causes an exception, where does it say what value caused the error?

@qqq but we are talking about N threads, once you have that precisely once doesn’t really work out

@noisesmith: I think you are making untrue assumptions.

Let's see how to clarify this.

Imagine we have an initial state s0; imageine wse have a bunch of functions f1, f2, f3, f4, f5, .... each of which has type signature :: state -> state

@hoff how are you invoking test.check?

(defn exec [s f] (locking s (reset! s (f @s))) // this guarantess precisely once invocation

defspec and then lein test

@qqq zero or once

because someone else could have the lock

@hoff it should print a map that has both the initial problematic value and the shrunken one

yeah, so you wait until they are done

then you execute

it's precisely once unless deadlocks

like I said, zero or once, they could hold on until exit

I'm just getting '{:result #error { :cause nil :via [{:type java.lang.StackOverflowError :message nil :at [clojure.lang.RT seq "RT.java" 525]}] :trace [[clojure.lang.RT seq "RT.java" 525]'

and then a million lines from the stackoverflow

@hoff check below the stack

for a key :fail

@noisesmith : I don't think that is the official definitino of 'zero or once'

@hoff then you'll also see a top-level key :shrunk with a key :smallest

by your argument, even sinl-gle threadced programs are also only zero-or-once, because, in theory, you could throw the computer out the window

@qqq it’s a basic rule of concurrent systems, you can have zero or one, you can have one or more, you can’t have precisely once.

once concurrency exists those are your conditions

let's stop having this conversation

it's a waste of both our time

found it, it was hidden at the end of the last line. (there was a stacktrace line shifting it off to the right)

@qqq presumably you want exactly-once because f has side-effects?

@hoff some sort of default manner of printing exceptions by clojure proper has unfortunate effects like that

@qqq anyway, calling compare-and-set! and only calling f if the function returns true is an alternative but it doesn’t prevent calling on stale state, otherwise yeah you need a lock.

but compare-and-set! will respond false if your state is old

@bfabry : yes, f_i can have side effects; what I want is when I feed it f1, f2, f3, ... f9 (from possibly different threads) -- I want each f_i to execute precisely once, but I don't care which order they evalute in; here, "preisely once -- assumes no deadlock, no crashing"

compare_and_set! doesn'w ork , because by the time we reailze the state is old, we al4ready did the sideeffects

sounds a lot like an agent - they prevent a lot of the issues with using locking directly

any reason why one wouldn’t do what you want?

yeah so atoms (generally) are not the primitives you want to be using to do something like that. atoms are for coordinating modifications to the atom, not for coordinating arbitrary modifications to the world. I'd suggest core.async (or maybe agents but I dunno much about them)

@noisesmith @bfabry : agents would be perfect, if only they were synchronous

what about a send wrapper that passes in a promise that gets delivered so the caller can block on it? maybe that’s hokey

interesting

how do I get a "blocking promise"

promises are blocking promises

@p will block until someone delivers to it

lol

p being defined as (let [p (promise)] …)

the callback on the agent then calls deliver

I think this will do; thanks!

await

await is for all pending actions, not just the one you just sent - but it is simpler, yes

depending on usage pattern await could be better

probably better

https://groups.google.com/forum/#!topic/clojure/hvc2fzYYAWc <-- is there no promise for cljs yet? (I'm trying to write files in cljc)

there are no promises, and no agents, in cljs

argh lol

okay, core.async it is 🙂

if your code needs to be cljc use core.async

well, thanks for helping me work through all the possible choices in the design space

I feel like I get why things have to do be a certai way now

Sorry for being pedantic about the “no such thing as exactly once” thing, it’s a peeve of mine in distsys and isn’t an issue for most single server code. Systems that are distributed and claim exactly once are typically doing something disasterously wrong.

and really, “at most once” isn’t so bad 😄

I completely agree with you taht there is no such thing as "exactly once delivery"

but I feel like in a single machine environment, even if it's multi core multi processed, unless the machine halts / crashes / inf-loops, it is possible to guarantee "exactly once execution" -- otherwise, we dcan't reasonab about programs

> we can’t reason about programs agreed!

😄

for what it's worth Google Dataflow promises "exactly-once semantics" which means that it rolls back the results of extra executions (gets thrown out the window if you do side-effects)

Executing something once is possible in practice, with the usual caveats about being on a single machine and assuming reliable hardware/OS/VM.

But yeah, once you distribute stuff or get to the point where reliability of the underlying system has to be taken into account, all bets are off.

And the byzantine general problem rears its head.