RE: [core.spec] Stricter map validations?

Personally I also wouldn't consider a client who sends a key that is not used, to be broken if I now validate that he is not supposed to send it. I did not break the API, I'm only making him realize he might have been wrong on how the API worked since the beginning, if he thought somehow that

Re: functional implementation of core.async primitives

(which also resolves this blocking go problem ... in a way) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your

Re: functional implementation of core.async primitives

Hi! I tried resolving that but pre-emption of the current task turned out to be a really, really tough problem, and I believe that's why we need the core.async macros. Anyhow, I have updated the scheduler to autopromote go blocks into actual JVM threads if they block for more than 10ms - poor

Re: [core.spec] Stricter map validations?

Wow, this has been a really great discussion. I have only played with spec a little, not used it in production. Reading this and participating has really helped me clarify a lot of things. Thanks! In particular, I've been thinking a lot about the three things you mentioned, Didier: safety,

Re: functional implementation of core.async primitives

I don't think the go blocks play well with the back-pressure. The code I present here deadlocks the scheduler: https://github.com/divs1210/functional-core-async/issues/1 On Wed, Nov 15, 2017 at 2:17 PM, Jay Porcasi wrote: > interested to hear any feedback on these

Re: functional implementation of core.async primitives

interested to hear any feedback on these features On Wednesday, November 15, 2017 at 3:52:24 PM UTC+7, Divyansh Prakash wrote: > > Hi! > > Thank you for your feedback! > > I've made the following changes to my implementation : > - bounded channels with backpressure > - proper thread

Re: functional implementation of core.async primitives

Hi! Thank you for your feedback! I've made the following changes to my implementation : - bounded channels with backpressure - proper thread synchronization - thread blocks that run on actual threads (unlike go blocks) TODO: - alts! - preserve thread local bindings in `go` blocks (`thread`