On Thu, 22 Dec 2005 18:47:39 +0100, Edi Weitz <edi@agharta.de> wrote:

My guess is that this doesn't work because of threading issues - .NET is trying to call into Lisp from a thread which wasn't created by Lisp.

And I was right. Here's a solution that avoids these problems and works for me. Files are at the end of this message. 1. Build a DLL (they don't have the threading problems I mentioned - see link in my earlier email) using LispWorks as usual, something like (from a console window): "\Program Files\LispWorks\lispworks-4460.exe" -init deliver.lisp 2. Make sure RDNZL.dll can be found - put it into c:\Windows\System32 for example. 3. Start the DLL as a program: rundll32 demo.dll,demo You should now see a window on which you can "draw" using the mouse. After every fifth stroke a message should come up telling you how many strokes the app has counted so far. If you don't have a LispWorks license to deliver executables you can download the DLL to play with from <http://nanook.agharta.de/InkDemo.zip> and start with #2 above. I don't know how to do that with AllegroCL but I guess Franz' support will help you. If they come up with a solution it'd be nice if you could post it here. Cheers, Edi. -------------------- deliver.lisp -------------------- (load-all-patches) ;; modify to match the location of RDNZL on your PC (load "/home/lisp/RDNZL/load.lisp") (use-package :rdnzl) (load (compile-file "tablet.lisp")) (shutdown-rdnzl) (deliver 'init "demo" 1 :dll-exports '("demo")) (quit) -------------------- tablet.lisp -------------------- (enable-rdnzl-syntax) (import-types "Microsoft.Ink" "InkOverlay" "InkCollectorStrokeEventHandler") (import-types "System.Windows.Forms" "Form" "Application" "MessageBox") (import-type "System.EventHandler") (use-namespace "Microsoft.Ink") (use-namespace "System.Windows.Forms") (use-namespace "System") (defparameter *stroke-counter* 0) (defun handle-stroke (object event) (declare (ignore object event)) (when (zerop (mod (incf *stroke-counter*) 5)) [MessageBox.Show (format nil "~A strokes so far..." *stroke-counter*)])) (defun demo () (let ((window (new "Form")) (ink-overlay)) (flet ((on-load (object event) (declare (ignore object event)) (setf ink-overlay (new "InkOverlay" [%Handle window]) [%Enabled ink-overlay] t) [+Stroke ink-overlay (new "InkCollectorStrokeEventHandler" #'handle-stroke)])) [+Load window (new "EventHandler" #'on-load)] [Application.Run window]))) (disable-rdnzl-syntax) (fli:define-foreign-callable ("demo" :calling-convention :stdcall) ((hwnd w:hwnd) (hinst w:hinstance) (string :pointer) (cmd-show :int)) (declare (ignore hwnd hinst string cmd-show)) (demo)) (defun init () (init-rdnzl))

On Fri, 23 Dec 2005 12:32:04 +0100, Edi Weitz <edi@agharta.de> wrote:

FWIW, I now also tried the example with Corman Lisp and it seems to work fine. Looks like Corman Lisp doesn't have problems with "foreign" threads calling into Lisp.

Another data point (I realize that I'm talking to myself all of the time... :) - LispWorks version 5.0 (due out Q2 2006) will also be able to cope with this: <http://article.gmane.org/gmane.lisp.lispworks.general/5093> Cheers, Edi.

On Thu, 22 Dec 2005 18:47:39 +0100, Edi Weitz <edi@agharta.de> wrote:

I forgot to mention: My guess is that this doesn't work because of threading issues - .NET is trying to call into Lisp from a thread which wasn't created by Lisp. [...] I'm not familiar enough with AllegroCL but maybe it's similar there.

Hmm, seems that it's slightly more complicated in this case. I got a copy of AllegroCL 8.0 for Windows today and played around with it a bit. Still no solution, unfortunately, but here are some more data points: 1. RDNZL seems to work fine with AllegroCL 8.0. I had already checked with the beta, so no surprise. 2. The problem with the "Microsoft.Ink" library remains the same, though. 3. I rummaged around in the AllegroCL docs and found the following: "A note on calling into Lisp from threads started by foreign code [...] In an :os-threads Allegro CL, however, it is legitimate for a thread started outside Lisp to call into Lisp via any foreign-callable function. Some extra work has to be done to create a Lisp process to represent that thread within the lisp world. That extra work is performed by a 'customs agent' process that is started by a call to START-CUSTOMS. See the documentation for that function for details." Aha! So we just have to call START-CUSTOMS and everything works? No, unfortunately not. 4. The reference entry for START-CUSTOMS says that the function is deprecated, so the paragraph from above is bogus. Nowadays, START-CUSTOM just calls START-SCHEDULER and (again, according to the docs) this is actually never necessary because starting a process will call this function implicitely. 5. So, back to square one. But I thought, hey, what will happen if I start the function DEMO[1] not from the REPL but from a thread? (mp:process-run-function "demo" #'demo) The problem is still the same but MP:PROCESS-RUN-FUNCTION does /not/ return until I close the .NET window. So, /something/ is blocking there because the function usually returns immediately. As I said, still no cigar. But maybe someone more familiar with AllegroCL's MP implementation knows what to make of this. Cheers, Edi. [1] see <http://common-lisp.net/pipermail/rdnzl-devel/2005-December/000044.html>