On Tue, Nov 11, 2008 at 7:24 AM, Eyal Lotem <eyal.lotem@gmail.com> wrote:

Hi

I would also like to congratulate Conal and everyone else involved in
the Reactive framework and libraries for the new release. Amazing
work!

I have finally managed to do more than read about it, and actually toy
with some Reactive programming :-)
It seems great fun, and the learning curve is not as steep as it might
seem at first.

I mostly played with Test.hs inside the reactive-fieldtrip adapter,
and I have encountered a few issues:

A. It seems that when changing spinningG to scale according to time,
it becomes extremely slow very quickly.

Probably because of the current algorithm for dynamic tessellation (approximation by polygons). As you scale up, a surface will get tessellated more and more finely during rendering. The tessellations are cached in an efficient, infinite, pure data structure (a MemoTrie) as they're computed. Given your experience, I gather there's some tuning required.

B. The lplace demo itself is also extremely slow, whereas other demos
seem to be fine/quick. It might be buggy, and not extremely slow, its
taking so long to react that I am not sure what is happening.

All of the demos are *very* zippy on my machine, even with 10-20 spinning torus pairs going.

Could you please give me particulars about your setup? For instance: cpu(s), graphics card, OS, and versions of opengl & glut.

C. Stylistic question/comment:
The (Anim a) type (UI -> Behavior a) is a Reader
Functor/Applicative/Monad. I see it used as a Functor in various
examples, but it seems that there's no use of the Applicative/Monad of
the reader, is this intentional?
I find it a bit awkward that it passes the "env" arg to all of the
stuff its combining... The example even used an undefined error value
in place of the env in some cases, suggesting that it is a burden to
pass it around. Why not encourage the implicit passing of the env
everywhere via the reader Applicative?

Fixed now. Thanks.

Regards, - Conal