January 2006 - rdnzl-devel@common-lisp.net

[rdnzl-devel] attaching handler / Tablet PC ink/ stroke/ not working
by Richard Fateman 26 Jan '06

26 Jan '06

Is anyone successfully using microsoft "ink" from Lisp via rdnzl? I sent this note to Edi RJF: Could you look at a (1 page) piece of code and see if there is something obvious that (my student and I) are doing wrong trying to use rdnzl? It is at http://www.cs.berkeley.edu/~fateman/temp/mjnet.lisp Edi: I just did and it looks OK to me. ... Nevertheless it doesn't work on either Allegro (RJF) or Lispworks. (Edi) It opens a window and enables "Ink", but if a handler is set up, it stops inking after the first stroke, and never really calls the handler. Oh, you don't need to have a Tablet PC, but it probably helps to have the microsoft Tablet PC SDK downloaded to your Windows machine. (Our project involves reading and speaking mathematics into a computer for processing by computer algebra programs in Lisp.) Thanks for any hints. RJF

2 7

[rdnzl-devel] new rdnzl 0.8.0 doesn't compile for me, Allegro
by Richard Fateman 24 Jan '06

24 Jan '06

This on Allegro 7.0... ;;; Compiling file h:\lisp\RDNZL-0.8.0\port-acl.lisp ; Fast loading from bundle code\efmacs.fasl. ;;; Writing fasl file h:\lisp\RDNZL-0.8.0\port-acl.fasl Error: Object free-dot-net-container cannot be written to a compiled file unless an applicable method is defined on make-load-form. [condition type: program-error] Any help would be appreciated.

2 1

[rdnzl-devel] Re: New versions 0.8.0/0.5.0
by Edi Weitz 16 Jan '06

16 Jan '06

On Mon, 16 Jan 2006 00:58:59 +0000, "lisp" <lisp(a)spikeisland.com> wrote: > I am happy to report that this works! Great! > If you run the function gc-test below in a LWW DLL image, you can > see the delegate adapter for the Click event being reclaimed and > releasing the closure from the callback hash table. > > If you open a process browser window *before* running this, you will > see the process created by LWW to handle the callback from .NET's gc > thread. Inspecting this process's arguments reveals > (rdnzl:%foreign-callable/releasedelegateadapter). This process is > used for all subsequent callbacks from the gc thread. If you kill > it, a new one will be created for the next gc callback. > > If you run this code in a conventional .exe LWW image you do not get > the callback from .NET's gc thread. Thanks for the detailed info. I'll try this tomorrow. > I have run into a further problem - with LWW this time I think. As > far as I can tell, LWW will occasionally run a foreign callback on > the wrong thread resulting in a stack overflow exception condition > being raised. With a form running in a new process and generating > event callbacks, the listener process occasionally reports a stack > overflow and shows the callback happening in *its* backtrace - > presumably confusing the stack check. I've not yet been able to > verify this or reproduce it reliably. > > Any thoughts or suggestions would be welcome... No idea. But it would be /very/ helpful if you could reproduce this and submit a bug report to LispWorks support. As you'll know they're currently working on the 5.0 release which will have some changes in the threading code as well. It'd be nice if they could fix that before they release the new version. Thanks again, Edi.

1 0

[rdnzl-devel] RDNZL - bug in delegate adapter release mechanism
by lisp 13 Jan '06

13 Jan '06

Hi Edi I've tracked down what looks to be a bug in the mechanism for releasing delegate adapters. The foreign callable ReleaseDelegateAdapter is declared with a return type of ffi-void-pointer but tries to return the result of remhash - a boolean. On LWW (at least) this results in: Condition: T cannot be converted to foreign type :POINTER. Call to SYSTEM::FOREIGN-CALLABLE-ENTRY-POINT-NEW-PROCESS-AUX (offset 21) SYSTEM::FUNC : RDNZL::%FOREIGN-CALLABLE/RELEASEDELEGATEADAPTER I would suggest changing it (and the corresponding initialisation and DLL code) to have a void return type: (ffi-define-callable (ReleaseDelegateAdapter ffi-void) ((index ffi-integer)) ;; remove entry from hash table if CLR is done with it (remhash index *callback-hash*)) Also, in DelegateAdapter.cpp you have a comment on the destructor that it doesn't appear to be working: // the destructor notifies Lisp that this instance is no longer used - // at least in theory, this doesn't seem to work right now DelegateAdapter::~DelegateAdapter() { release(indexIntoLisp); } This may have beeen the caused by the callback/threading issues discussed recently. At least it has certainly worked for me here (hence this bug report) when using a DLL based LWW image (many thanks for your recent example of this). Perhaps the .NET GC is running in a different thread, so the callback was failing in a normal .EXE image? The full traceback from the bug above seems to support this - it shows LWW creating a new process to handle the callback: CL-USER 4 : 1 > :bb #<PACKAGE COMMON-LISP-USER> Condition: T cannot be converted to foreign type :POINTER. Call to SYSTEM::FOREIGN-CALLABLE-ENTRY-POINT-NEW-PROCESS-AUX (offset 21) SYSTEM::FUNC : RDNZL::%FOREIGN-CALLABLE/RELEASEDELEGATEADAPTER Catch frame: MP::PROCESS-TAG Catch frame: (NIL) Binding frame: MP:*CURRENT-PROCESS* : NIL Binding frame: WIN32::*DDE-THREAD-INSTANCE* : #<unbound> Binding frame: MQ::*ACTIONS-AFTER-SLEEPING* : NIL Binding frame: MR::*ACTIONS-BEFORE-SLEEPING* : NIL Binding frame: SYSTEM::*READER-STATE* : #<unbound> Binding frame: *PACKAGE* : #<PACKAGE COMMON-LISP-USER> Binding frame: EDITOR::*CURRENT-BUFFER* : NIL Binding frame: EDITOR::*CURRENT-WINDOW* : NIL Binding frame: EDITOR::*EDITOR-STATE* : NIL Binding frame: EDITOR::*EDITOR-INPUT-STYLE* : #S(EDITOR:EDITOR-INPUT- STYLE :KEY-BINDINGS #<EDITOR::KEY-TABLE #<EQUALP Hash Table{332} 20BCA90C> 1 331> :DELETE-SELECTION-MODE NIL :LOGICAL-CHARACTERS #<EQUALP Hash Table{21} 20C3D364> :EXECUTE-MODE #<EDITOR::MODE-OBJECT "Execute" 20CE37FC> :ECHO-MODE #<EDITOR::MODE-OBJECT "Echo Area" 20CE34A4> :PLIST NIL :INTERRUPT-KEYS (#S(SYSTEM::GESTURE-SPEC :DATA 103 :MODIFIERS 2) #S(SYSTEM::GESTURE-SPEC :DATA 71 :MODIFIERS 2)) :STYLE :EMACS :POINT-ALWAYS-VISIBLE T :USE-FACE-TO-FULL-WIDTH-P T) Binding frame: CAPI::*USE-ACCELERATORS* : T Binding frame: CAPI-WIN32-LIB::*ALT-IS-META-KEY* : T Catch frame: #:CATCHER100675 Call to (SUBFUNCTION MP::PROCESS-SG-FUNCTION MP::INITIALIZE-PROCESS- STACK) (offset 347) MS::IGNORED : :DONT-KNOW Catch frame: SYSTEM::EXIT-FOREIGN-CALLABLE Call to SYSTEM::FOREIGN-CALLABLE-ENTRY-POINT-NEW-PROCESS (offset 133) SYSTEM::FUNC : RDNZL::%FOREIGN-CALLABLE/RELEASEDELEGATEADAPTER Call to SYSTEM::%FUNCALL1-ON-LISP-STACK (offset 34) SYSTEM::%FUNCALL1-ON-LISP-STACK T - Dominic Robinson

2 1