Hi Jay
No, there is no native support of selectInput() or selectOutput() in Quil.
You can try calling Processing's methods directly using java interop.
Though it's not straightforward. The problem is that when you call
selectInput() you have to pass a name of callback function to be called.
Th
@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 lov
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 unsubscribe
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 bette
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 the past? I thought
>
> 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 usef
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
> explain what's happe
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
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, sen
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
librar
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
abou
>
>
>> 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
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 memory barrier.
>
>
> N
>
> 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
happens-be
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 a
понедельник, 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 exist
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 t
17 matches
Mail list logo
