[cells-devel] feedback and question

[Ken Tilton]

On 9/4/06, franks-muc at web.de <franks-muc at web.de> wrote:
>
>
> > I am now able to  get correct behavior  when starting from the repl or
> by evaluating  (run-window 'my-test) in an editor, but only changing this
> parameter to a lower amt: *event-loop-delay*. The value in CVS is 0.08. I
> tried 0.02 and got the keystrokes OK, did not experiment further. The
> problem is that the ACL IDE is then locked out while a Celtk window is open.
> >
> > Since entry fields work for me using Run Project in ACL with the
> *event-loop-delay* parameter at 0.08, I think I will leave it that way
> since that is how I test anyway.
> >
> > Let me know if a lower value for *event-loop-delay* works for you.
> >
> > kt
> >
> >
>
> Reducing *event-loop-delay* is the solution. Already 0.075 let all key
> strokes show up in the entry field (at 100% CPU
> usage by acl).



Yeah, I think any vale that low is effectively zero because it is below some
minimum granularity. Also, my guess is that you are now locked out of the
ACL IDE while a Celtk window is open. That could make debugging pretty hard.
A number of solutions occur to me, including adjusting the delay
intelligently when the  TK window loses the "focus" aka deactivates, or even
just a whole new approach to the event loop. Unfortunately I will not be
able to explore these until  my own project demands it, but  I might poke
around a little now and again, and I will be happy to help anyone else with
ideas if they choose to explore.

The new event loop approach is probably the only way to avoid pegging the
CPU. I forget what happens if we just give the whole event loop to Tcl and
settle for callbacks. Possibly we are looking at hogging the CPU during
development, then switching to a different approach for delivered apps, all
controlled by conditional compilation.

kt

ps. Cells fans, sorry for the spam; if the Celtk traffic keeps up I will
look at getting a new project, or moving Celtk from Cells to Cello and
supporting it fromt here. kt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20060904/a825ff0d/attachment.html>