Re: core.typed - Can't resolve alias name

If you're at the repl, you should use `cf` to evaluate `defalias` also. Sorry for the late response. Thanks, Ambrose On Thu, Oct 29, 2015 at 9:23 PM, JvJ wrote: > Reposting from the core.typed google group. Didn't get a response. > > I'm just starting with core.typed, and I can't seem to get

core.typed - Can't resolve alias name

Reposting from the core.typed google group. Didn't get a response. I'm just starting with core.typed, and I can't seem to get it to work properly in the REPL. I start by defining an alias (Fhtagn), but when I later try to type-check it, the name "Fhtagn" is unresolved. Am I using it wrong, or

Re: [ANN] core.async-0.2.371

On Thursday, October 29, 2015 at 6:18:47 PM UTC-5, Derek Troy-West wrote: > > > Understanding the limitations of analogies, does this new channel adhere > to that concept of flow-state? Is it a conveyor-belt or a coat-hook? > I don't think it's exactly either of those (hey, analogies). A promis

Re: clojure reflection error

it is not String, it should be javax.mail.Store On Thursday, October 29, 2015 at 4:30:37 PM UTC-7, Eric Yang wrote: > > HI there, > > > I used this lib [io.forward/clojure-mail "1.0"] in my test, it works fine > on my local box, but when I run in in jenkins, there is a strange > reflection error

Re: [ANN] core.async-0.2.371

On Thursday, October 29, 2015 at 5:35:17 PM UTC-5, Rangel Spasov wrote: > > I assume this is a pretty reliable way: > > (:require [clojure.core.async.impl.protocols :refer [closed?]]) > > (closed? a-chan) > Being something under "impl", you should treat this as an implementation detail subject t

clojure reflection error

HI there, I used this lib [io.forward/clojure-mail "1.0"] in my test, it works fine on my local box, but when I run in in jenkins, there is a strange reflection error, any clue why it happened? Thanks! 18:40:02,623 ERROR [SoapUI] An error occurred [No matching field found: getDefaultFolde

Re: [ANN] core.async-0.2.371

Thanks Alex, I think I can sum up my confusion as: I thought channels were single take, but understand now that is not necessarily the case. In his 2013 Strange Loop talk Rich described first-class channels and the subset of state that they expose: "But I think what's really cool about first clas

Re: [ANN] core.async-0.2.371

I assume this is a pretty reliable way: (:require [clojure.core.async.impl.protocols :refer [closed?]]) (closed? a-chan) On Thursday, October 29, 2015 at 2:07:00 PM UTC-7, Lucas Bradstreet wrote: > > Fantastic release. I've been waiting for poll! and offer! for a while. > > What is the recommen

Re: [ANN] core.async-0.2.371

On Oct 29, 2015 4:10 PM, "Alex Miller" > > The buffer is not unbounded - it is of size 1. Is it correct or reasonable to think of it as a constant channel? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@

Re: [ANN] core.async-0.2.371

> > To be clear, I didn't mean that a channel is guaranteed to be closed, > rather that previously I could count on the ability to drain a channel > after I have chosen to close it. Closing a promise-chan which has received > a value has no impact on later takes, it is indistinguishable from a

Re: [ANN] core.async-0.2.371

Fantastic release. I've been waiting for poll! and offer! for a while. What is the recommended way to check whether a channel is closed? Previously if the channel returned nil, then we know the channel is closed, however with poll! we can't tell between the channel being closed or just empty. Tha

Re: [ANN] core.async-0.2.371

> > > >> Secondly, I've perhaps mistakenly considered channels more as a conduit >> between processes rather than a replacement for single assignment message >> passing. I get the value of using a channel and the core.async state >> machine for achieving promise-like semantics in a non-blocki

[ANN] Clojure/conj - last day for regular price tickets!

Clojure/conj Keynote Speaker: Benjamin Pierce We're pleased to announce that Professor Benjamin Pierce from the University of Pennsylvania will be joining us this year as our Keynote speaker! See the full schedule here! http://clojure-conj.org/ -

Re: [ANN] core.async-0.2.371

I'll take a look, thanks. On Thursday, October 29, 2015 at 10:52:08 AM UTC-5, Marian Schubert wrote: > > Awesome! > > I did try it on our project and it failed at one location with: > CompilerException java.lang.UnsupportedOperationException: Can only recur > from tail position > > Minimal exampl

Re: [ANN] core.async-0.2.371

Awesome! I did try it on our project and it failed at one location with: CompilerException java.lang.UnsupportedOperationException: Can only recur from tail position Minimal example which still fails (alts! + case + recur combination) is: (defn this-fails-to-compile [x] (go (loop []

Re: [ANN] core.async-0.2.371

On Thursday, October 29, 2015 at 5:05:04 AM UTC-5, Derek Troy-West wrote: > > Hi Alex, thanks for your efforts and the update. > > I have a few questions about promise-chan if you have a moment. > > Firstly, why provide promise-chan rather than requiring (chan > (buffers/promise)). The buffer pr

Re: [ANN] core.async-0.2.371

Hi Alex, thanks for your efforts and the update. I have a few questions about promise-chan if you have a moment. Firstly, why provide promise-chan rather than requiring (chan (buffers/promise)). The buffer provides the promise semantics and we don't similarly have sliding-chan, dropping-chan, e