Re: core.async consumer + producer working by chunk?

On 5 January 2018 at 19:44, Rob Nikander wrote: > Hi, > > I’m wondering if there is a core.async design idiom for this situation... > > - A buffered channel > - One producer feeding it > - A bunch of consumers pulling from it. > - Producer should wake up and fill the channel only when it’s empty.

Re: Spec - is there any way to tell which keys are not described by a spec?

Ah, yes that seems to be what I want exactly. Thank you, I'll give it a shot. Den fredag 5 januari 2018 kl. 20:53:55 UTC+1 skrev Josh Tilles: > > I think Stu Halloway’s proof-of-concept is at least close to what you > want: > https://gist.github.com/stuarthalloway/f4c4297d344651c99827769e1c3d34

Re: core.async consumer + producer working by chunk?

I don’t know; I don’t fully understand the implementation differences of >!! and offer!. The behavior of offer! makes me think the buffer is not empty until all the outputs of the transducer are consumed, but the behavior of >!! makes me think otherwise. Moritz - is the buffer cleared if: - it’

Re: [ClojureScript] Re: durable datascript experiments

It now has its own repo as datahike and is on clojars to play around. https://github.com/replikativ/datahike We are also working on replication of the hitchhiker-tree here: https://gitlab.com/replikativ/index-sync So hopefully we will be able to stream replicate a datahike db soon. Best, Chris

Re: core.async consumer + producer working by chunk?

On Friday, January 5, 2018 at 4:00:25 PM UTC-5, Moritz Ulrich wrote: > > > You have a channel with a buffer-size of one. You clear the buffer by > taking one item from it, making room for another one. Therefore the put > succeeds. Try just `(async/chan nil xform)` to create a channel without >

Re: core.async consumer + producer working by chunk?

Rob Nikander writes: > Thanks for the explanation! This is very close to what I want. I see some > confusing behavior though. See below. > > On Friday, January 5, 2018 at 2:40:14 PM UTC-5, Brian J. Rubinton wrote: >> >> >> The work-queue channel has a fixed buffer size of 1. A collection (range

Re: [ANN] Git Deps for Clojure!

On Friday, January 5, 2018 at 2:08:50 PM UTC-6, Gary Trakhman wrote: > > Specifically, I'm asking about how to resolve duplicate transitive > dependencies to actual code, possibly referring to the same lib repo at > different git hashes, or different git repos. > Ah, good question. The answer i

Re: core.async consumer + producer working by chunk?

Thanks for the explanation! This is very close to what I want. I see some confusing behavior though. See below. On Friday, January 5, 2018 at 2:40:14 PM UTC-5, Brian J. Rubinton wrote: > > > The work-queue channel has a fixed buffer size of 1. A collection (range > 50) is put on the channel. Whi

Re: [ANN] Git Deps for Clojure!

Specifically, I'm asking about how to resolve duplicate transitive dependencies to actual code, possibly referring to the same lib repo at different git hashes, or different git repos. I think you answered, 'how do you get a single graph of deps nodes given different kinds of deps'? For example:

Re: Spec - is there any way to tell which keys are not described by a spec?

I think Stu Halloway’s proof-of-concept is at least close to what you want: https://gist.github.com/stuarthalloway/f4c4297d344651c99827769e1c3d34e9. (Here’s the context for that code, in case you were curious.) btw, you might want t

Re: core.async consumer + producer working by chunk?

The `mapcat` transducer takes a collection as its input and outputs each of its items individually. This example might be helpful: user> (use ‘[clojure.core.async]) nil user> (def work-queue (chan 1 (mapcat identity))) #’user/work-queue user> (offer! work-queue (range 50)) true user> ( ( (offer!

Re: [ANN] Git Deps for Clojure!

On Fri, Jan 5, 2018 at 1:20 PM, Gary Trakhman wrote: > Congrats on the release! It's exciting to see this vision move forward. > Wondering if the logical next step is the npm style of trees of duplicate > transitive git deps. In general, how is this going to work for transitive > deps? > tools.

Re: [ANN] Git Deps for Clojure!

Congrats on the release! It's exciting to see this vision move forward. Wondering if the logical next step is the npm style of trees of duplicate transitive git deps. In general, how is this going to work for transitive deps? On Fri, Jan 5, 2018 at 1:49 PM Alex Miller wrote: > Pleased to announ

Re: core.async consumer + producer working by chunk?

On Friday, January 5, 2018 at 2:03:00 PM UTC-5, Brian J. Rubinton wrote: > > > What is the buffered channel’s buffer used for? If that’s set to 1 and the > channel’s transducer is `(mapcat identity)` then the producer should be > able to continuously put chunks of work onto the channel with the

Re: core.async consumer + producer working by chunk?

Hi Rob, What is the buffered channel’s buffer used for? If that’s set to 1 and the channel’s transducer is `(mapcat identity)` then the producer should be able to continuously put chunks of work onto the channel with the puts only completing when the previous chunk is completely consumed. That

[ANN] Git Deps for Clojure!

Pleased to announce some new functionality for clj and tools.deps! https://clojure.org/news/2018/01/05/git-deps Additionally, there have been new releases of: - Brew clojure formula (to get it: brew upgrade clojure) - Linux clojure installer (see https://clojure.org/guides/getting_started for in

core.async consumer + producer working by chunk?

Hi, I’m wondering if there is a core.async design idiom for this situation... - A buffered channel - One producer feeding it - A bunch of consumers pulling from it. - Producer should wake up and fill the channel only when it’s empty. In other words, the producer should work in chunks. My firs

Spec - is there any way to tell which keys are not described by a spec?

Hi, I'm writing a spec for a fairly complex data structure. One thing that I have identified troublesome is that I currently have no clue how "well" my spec describes my data. I keep iterating the spec, thinking that I have described all fields but then it turns out later that I've missed some

Re: Advice on Shell Scripting with new "clojure" binary

Cool! I had somehow missed that in the announcement. Quick test on linux: > echo '(println "Yes!!!")' | time clojure Clojure 1.9.0 user=> Yes!!! nil user=> clojure 1.38s user 0.07s system 198% cpu *0.730 total* Well under a second, even with a full-power JVM to load. Very convenient!

Re: Advice on Shell Scripting with new "clojure" binary

Thanks, but I do need the JVM. > On Jan 5, 2018, at 1:33 AM, Gary Verhaegen wrote: > > On 4 January 2018 at 23:26, Delon Newman wrote: >> Also, any additional advice with respect to using Clojure for shell >> scripting would be appreciated. > > Unless you have a specific reason to prefer the J

New Year - New Functional Gig..

Hey All, Happy New Year! With a new year comes the opportunity to start your year with a new new venture! If you haven't had a look yet then do check out our new and improved platform with all the latest and greatest Functional Jobs across the globe. Also with our blog having contributions fro

[JOB] Telia Norge needs people interested in working with Clojure and ClojureScript (Oslo, Norway)

Hello! We here at Telia Norge are starting a new project using Clojure and ClojureScript and need people that know or are interested in learning and using these technologies. So if you could consider becoming our employee and joining the team, let us know as soon as possible (you don't need to

Re: Advice on Shell Scripting with new "clojure" binary

On 4 January 2018 at 23:26, Delon Newman wrote: > Also, any additional advice with respect to using Clojure for shell > scripting would be appreciated. Unless you have a specific reason to prefer the JVM to Node as a platform for your script, I'd encourage you to take a look at Planck and Lumo fo