Re: Derefs broken after clojure.tools.namespace.repl/refresh

@Colin If I understand correctly, if I buy the personal license I can use it for my own commercial projects, but I can also use it at my work, to work on their code base, as long as I'm the one using it. Is that correct? I probably can't convince work to buy into a bunch of licenses, but I'd

Re: Derefs broken after clojure.tools.namespace.repl/refresh

Awesome, time for me to try Cursive. -- 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 first post. To

Re: Derefs broken after clojure.tools.namespace.repl/refresh

I spoke about it at Clojure/West: https://www.youtube.com/watch?v=ql77RwhcCK0. I talked there about some of the limitations, but it works really nicely for the most part. CIDER actually has a nice debugger these days too. It works in a very different way, via source instrumentation. It works

Re: Derefs broken after clojure.tools.namespace.repl/refresh

Cursive has had a really good debugger for a long time. I don't use it much, but when I need it it *just works*. Timothy On Tue, Apr 11, 2017 at 7:37 PM, Didier wrote: > A good debugger is indeed extremely useful for Clojure - I use one every >> day :-) >> > > Am I living in

Re: Derefs broken after clojure.tools.namespace.repl/refresh

> > A good debugger is indeed extremely useful for Clojure - I use one every > day :-) > Am I living in the past? I thought Clojure didn't have a way to step through code interactively? On Tuesday, 11 April 2017 16:30:14 UTC-7, Colin Fleming wrote: > > A good debugger is indeed extremely

Re: Derefs broken after clojure.tools.namespace.repl/refresh

A good debugger is indeed extremely useful for Clojure - I use one every day :-) On 12 April 2017 at 05:29, Didier wrote: > Experimentation is good. This is indeed surprising. I think it shows that > a good debugger would still sometime be useful in Clojure. I can't really >

Getting a password from command line and repl

Hi, I'm currently trying to get a password from the user in case it wasn't supplied by other means, but it seems to be a bit more difficult than I expected. I've already searched both the web and this mail list finding only partial solutions to the problem. I must say I'm not completely fluent

Re: Derefs broken after clojure.tools.namespace.repl/refresh

Experimentation is good. This is indeed surprising. I think it shows that a good debugger would still sometime be useful in Clojure. I can't really explain what's happening. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group,

Re: Java 8 Lambda Interop

Sorry to awaken this old thread. It seems like reifying a valid lambda, for the specific clojure function which you want to pass to Java code, is indeed the most sensible way, given all the surface that java's lambda api entails. To the best of my knowledge no generic interop features or

Re: Seeking critique of "pattern" in clojure.spec (LONG)

I should have called them "blueberries" instead of the more provocative "virtual times." I was trying to go from an abstract mathematical definition to a formalization in Clojure. Eventually, virtual times will be part of a discrete-even simulation platform, but it's too early to say much

Re: Using transducers in a new transducing context

> > >> Transducers should ensure stateful changes guarantee visibility. That is: >> you should not make assumptions about external memory barriers. > > > How do you enforce no more than one thread at a time without setting a > memory barrier ? > I could have one thread that invokes a transduce

Re: Using transducers in a new transducing context

Seems risky to depend on that. eduction creates an iterable for example - it has no way of preventing somebody from creating the iterator on one thread and consuming it on another. On Tue, Apr 11, 2017 at 7:32 AM, Léo Noel wrote: >> volatile! is what ensures that there's a

Re: Using transducers in a new transducing context

> > volatile! is what ensures that there's a memory barrier. > No. The memory barrier is set by the transducing context as a consequence of implementing the "single thread at a time" rule. Be it lock, thread isolation, agent isolation, or anything that ensures that the end of a step

Re: Using transducers in a new transducing context

The single thread at a time rule is implemented by the transducing context (transduce, into, core.async, etc). Inside of a transducer's implementation you just have to make the assumption that it's being used properly. volatile! is what ensures that there's a memory barrier. On Tue, Apr 11, 2017

Re: Derefs broken after clojure.tools.namespace.repl/refresh

понедельник, 10 апреля 2017 г., 22:56:43 UTC+2 пользователь Didier написал: > > Hum, not sure why you would do this, but I'm guessing refresh goes in an > infinite async loop. You keep reloading a namespace which creates a thread > to reload itself. > > I can't really explain why the symbol

Re: Using transducers in a new transducing context

Thank you Alex for these precisions. The JVM is pretty good at minimizing this stuff - so while you are stating > these barriers are redundant and are implying that's an issue, it would not > surprise me if the JVM is able to reduce or eliminate the impacts of that. > At the very least, it's