Hello Nikita,
I think Quil should definitely provide a way to write functional style
processing code. At the moment, my knowledge of both Clojure and Processing
is not enough to evaluate these solutions. I'm certainly going to write my
code following some of this and if someone proposes a solut
The complicated-looking semaphore code was adapted from
http://stackoverflow.com/a/5275254/2559313 . I think some issues with other
alternatives are in there.
On Mon, Mar 10, 2014 at 1:27 PM, Nikita Beloglazov
wrote:
> Lee,
>
> I think question about managing/updating state in quil pop ups prett
Lee,
I think question about managing/updating state in quil pop ups pretty
frequently and many people expect quil to have built-in tools to do it in
functional style. And using atoms to update state may feel hacky. I think
this tools should exist and quil 2.0 is a good time to address the issue.
Y
FWIW, I've got an example of a decoupled update/draw loop here:
https://github.com/gtrak/quilltest/blob/master/src/quilltest/balls.clj
On Sun, Mar 9, 2014 at 10:16 PM, Lee Spector wrote:
>
> FWIW I'm not crazy about these suggestions because they seem to me to be
> mostly cosmetic, and actually
FWIW I'm not crazy about these suggestions because they seem to me to be mostly
cosmetic, and actually negative if they end up leading to multiple incompatible
modes of operation. The Processing model seems to me to be intrinsically
imperative, and it's also well-known by lots of people and eas
Hi Pablo
You can find similar old thread on Quil github repo:
https://github.com/quil/quil/pull/19 It may serve as good background what
other people considered to make Quil more "functional-style".
I like your suggestion though I would split your :draw function to 2 fns:
an :update function, w
2014-03-09 14:21 GMT+01:00 J. Pablo Fernández :
>
>
> On Sunday, March 9, 2014 1:02:52 PM UTC, Laurent PETIT wrote:
>>
>> Hello,
>>
>> To be honest I don't see any fundamental difference between your first
>> attempt and the improvement: both share the fact that the mutation of the
>> state happen
On Sunday, March 9, 2014 1:02:52 PM UTC, Laurent PETIT wrote:
>
> Hello,
>
> To be honest I don't see any fundamental difference between your first
> attempt and the improvement: both share the fact that the mutation of the
> state happens within the draw function. So in both cases, you have a
Hello,
To be honest I don't see any fundamental difference between your first
attempt and the improvement: both share the fact that the mutation of the
state happens within the draw function. So in both cases, you have a
temporal coupling between updating the state of the app and rendering a new
v
