[Openmcl-devel] NSSlider not responsive

[Gary Byers]

On Sat, 2 Feb 2008, Osei Poku wrote:

>
> On Feb 2, 2008, at 6:16 PM, Gary Byers wrote:
>> 
>> On Sat, 2 Feb 2008, Osei Poku wrote:
>> 
>>>> On Sat, 2 Feb 2008, Osei Poku wrote:
>>>>> On thing to note is that when I set the target of the slider's action
>>>>> to be a simple text label using takeFloatValueFrom:, the slider moves
>>>>> as expected and can be dragged up and down.  Could this be a lisp
>>>>> callback issue?
>>> 
>>> On Feb 2, 2008, at 5:34 PM, Gary Byers wrote:
>>> 
>>>> What was the slider's target before you made this change ?
>>> 
>>> The slider's target was the window-controller/WindowController class using 
>>> the #/slide: message.
>>> 
>> 
>> It was the class, or an instance of it ?
>
> To an instance of it.  Sorry for my imprecise terminology.
>
> I have some update on this problem and the solution was very silly.  Maybe 
> you can explain it.
>
> When my slide: method was defined without a specified return type (ie 
> (objc:defmethod #/slide ((self window-controller) sender) ...)), the slider 
> movement was not smooth.  When the slide: method was defined with a :void 
> return type (ie (objc:defmethod (#/slide: :void) ((self window-controller) 
> sender) ....)) then the slider motion was smooth and continuously updated the 
> target control as I expect.
>

Sure.  Suppose we take ObjC out of the picture for a moment, and
define a callback that's declared to return a pointer (an "address"),
but fails to do so:

? (defcallback foo (:address)
     nil)

and call it using the low-level FF-CALL.

? (ff-call foo :address)
> Error: value NIL is not of the expected type MACPTR.
> While executing: FOO, in process listener(1).

The type error occurs in the callback function FOO: it can't
obtain a (foreign) address from the lisp return value NIL.

In your case, the ObjC method:

(objc:defmethod #/slide: ...)

was implicitly declared to return something of type :id (an ObjC
class or instance); it actually returns NIL (the :void value
from the last method call).  That would generate the same sort
of error as in the FOO case above.

When a (lisp or ObjC) error occurs during event processing, a
handler is supposed to try to print an error message and a
backtrace, then aborts processing the current event and tries
to process another one.

It's likely that that happened in your case.  However, the
stream to which the event thread tried to log this debugging
info was likely to just be an alias for the standard output
stream of the (OS-level) process.  If you run the ide via

? (require "COCOA")

that standard output stream is the terminal or Emacs connection
(possibly the *inferior lisp* buffer under SLIME.)

If you run the double-clickable application, the process-level
standard output stream is likely to be connected to the
system logging facility.  You can see that output via
/Applications/Utilities/Console.app; it's also likely
to be written to a text file in /var/log (probably /var/log/system.log,
though I think that this has changed over time.)

It would obviously be better to have error messages/debugging info go
somewhere where you can see them (and even better to be able to 
use the backtrace window and other tools to debug things that go
wrong during event processing.)  This is all planned, but also
a bit complicated (if things are wrong in the event thread, giving
it another window to manage may not be the best idea ...)  Maybe
process-level output should go both to a window (so that you
can see it if things aren't too badly hosed) and to a logging
device (which tends to be pretty robust).

I have seen cases where log file fills up with recursive errors
printing backtraces (should be better now than it once was)
and where the event thread entered a break loop and kept printing
prompts in response to the EOF it gets from /dev/null.  (It either
shouldn't have entered the break loop or should handle that EOF
more intelligently.)

Until this whole situation gets better, looking at the log output
(or *inferior lisp* buffer) is a good habit is a good habit to
get into.