Timing help needed

[cormullion]

This isn't really a newLISP question (that department is working fine) but more of a programming question. I know some of you guys are real programmers, so you might have a suggestion.



Here's a simple version of a project I'm working on:

Code Select Expand

load  (string (env "NEWLISPDIR") "/guiserver.lsp"))

(gs:init)
(gs:frame 'Translator 200 200 400 550 "Translator")
(gs:panel 'MainPanel)
(gs:set-grid-layout 'MainPanel 2 2)
(gs:text-area 'string-input 'textfield-handler )
(gs:text-pane 'text-output 'gs:no-action "text/plain")
 
(gs:set-editable 'text-output nil)

(gs:add-to 'MainPanel 'string-input 'text-output)
(gs:add-to 'Translator 'MainPanel )

(gs:set-visible 'Translator true)

(define (textfield-handler id key dot mark)
(gs:get-text id 'gettextcallback-handler))

(define (gettextcallback-handler id text)
  (and
    text
     (= id "MAIN:string-input")
     (set 'strng (base64-dec text))
     (set 'result (translator strng))
     (gs:set-text 'text-output result)
     ))

(define (translator s)
  (sleep 400)
  (upper-case s))

(gs:listen)


As you see, the hard work is being done by calling the translator function. Yet - if this takes more than a certain time (which I've simulated), there are just too many calls, as newLISP responds to every keystroke and runs the function each time. In fact, newLISP-GS eventually hangs if the translator function doesn't get back pretty quickly... You can almost see it panicking as it has to handle a new call before it's finished the previous one.



Is there a way to get newLISP to not run the function after every keystroke, but only when the user stops typing rapidly?

[newdep]

Is there a way to get newLISP to not run the function after every

keystroke, but only when the user stops typing rapidly?

you are doing the translation per string..



Try doing it per key-input and append those to a string and then translate.

use (yes you have to write your own handler) ->



(gs:key-event 'C 'key-action)

(define (key-action id type code modifiers) (set 'KEY code))



After every KEY input make it the KEY 0 again (set 'KEY 0),

and put that in the loop, then you have a delay or actualy a clear

in the KEY value. I used that in a small game here and it nicely stops, but

not sure if you seek that.

[Lutz]

The first solution would only translate when a space is typed, which makes sense because it waits until a word is finished. Addtionaly you could check for periods, exclamation marks etc.:

Code Select Expand

(define (textfield-handler id key dot mark)
    (if (= key 32)
        (gs:get-text id 'gettextcallback-handler)))




The second solution does timing whenever a normal key is pressed and does translation when more than 1/2 second has passed:

Code Select Expand

(set 'last-key 0)
(define (textfield-handler id key dot mark)
    (if (> (- (time-of-day) last-key) 500)
        (gs:get-text id 'gettextcallback-handler))
    (set 'last-key (time-of-day)))



Lutz

[cormullion]

Thanks for the ideas! I'm trying them out now, and will see how they work.

[Jeff]

By the way, Lutz, the Java swing text editor component is extremely slow moving strings from the interface to the back-end.  The awt text area does not have this problem.  It's somewhere in the jeditor hierarchy, but I am not enough of a java programmer to find it.  I'm thinking we would benefit from a custom class if you ever have the time :)

[Lutz]

The editor component gs:text-pane is a JTextPane which is a styled text widget managing mixed fonts, colors etc., stuff the syntax highlighting needs. If you need a faster text control use gs:text-area which is a swing JtextArea and is supposed to be light weight and closer in functionality and performance to an awt TextArea, not carrying all that overhead.



Lutz

[Jeff]

Yeah, I know, and I do.  But the weight of the editor widget is really atrocious.  Even in pure Java, something is taking an extremely long time to move strings back and forth between the widget and the handler.  It seriously limits the use of the editor for anything but very short strings.