Re: Keep application running when main thread only starts go blocks

Dunno about clojure, but in javaland you would submit jobs through an executor and then wait for all tasks on the executor to finish, blocking the main thread. A bit of googling, and you can alter the core.async executor: http://stackoverflow.com/a/18779688/22992 And then you can await for its

Re: Keep application running when main thread only starts go blocks

I think this is solution is fine. A single channel is not going to use any noticeable resources. You've basically created a latch - there are several latch-like things built into Java you can use as well. In the main thread you could do: (let [signal (java.util.concurrent.CountDownLatch. 1)]

Re: clojure.spec for specifying sequences of states over time

A few thoughts on your design and a possible solution to your problem. Firstly if we are concerned about the correct ordering of values over time, then it sounds like we are dealing with something that contains hidden mutable state. That hidden state is a can be problematic. In general, when workin

wondering why spec.test/instrument doesn't check :ret

spec.test/instrument doesn't check the return value of spec'd functions and according to the spec guide this is because we should be checking function implementations at testing time, not development time. It seems to me that adding :ret and :fn checks to instrumented functions would be worthwhi

Re: Is this behavior of clojure.core/pr a bug?

Has anybody written a pr-edn that enforces the rules of https://github.com/edn-format/edn, refusing to print anything nonconformant? This would solve the original problem on this thread without requiring any changes to Clojure. On Fri, Aug 5, 2016 at 9:42 PM, Blake Miller wrote: > I agree with

Re: Is this behavior of clojure.core/pr a bug?

The user-provided examples and comments at ClojureDocs.org are not official Clojure documentation, but in many cases contain useful additional info. I have just added examples to clojure.core/pr similar to those that motivated this thread, and Timothy Baldridge's suggestion to use transit in cases

Re: wondering why spec.test/instrument doesn't check :ret

I’m not sure it answers your question *directly*, but a quote from Rich in another thread seems relevant: On Monday, July 11, 2016 at 10:01:05 AM UTC-4, Rich Hickey wrote: > On Sunday, July 10, 2016 at 6:04:39 AM UTC-4, puzzler

Re: wondering why spec.test/instrument doesn't check :ret

> I'm sure this was considered Indeed, and when clojure.spec was first introduced, instrument did check :ret and :fn specs. That feature was deliberately removed and the reason for it is (paraphrased): * clojure.spec/instrument helps check that your functions are _called_ correctly * clo

can clojure java.jdbc function 'result-set-seq' add option to support custom 'result-set-read-column' ?

Hello the contributor of jdbc, Using java.jdbc with postgres composite type, the common way is extend the IResultSetReadColumn protocol. When there are multiple databases in use, every database should specify it's own column reader. Add option to 'result-set-seq' support custom function to re

RE: can clojure java.jdbc function 'result-set-seq' add option to supportcustom 'result-set-read-column' ?

Hi Joe, I’m starting to see more requests for per-database customization in a multi-database environment so this is definitely something I’d consider. Could you create a JIRA issue for tracking purposes, along with any suggestions you have about how this might work – and remain performant? htt