- rdnzl-devel@lists.common-lisp.net - mailman3.common-lisp.net

RE: [rdnzl-devel] Re: rdnzl, multiprocessing, Allegro, windows, locking
by Goffioul Michael 17 Oct '06

17 Oct '06

> > I just tried the Apropos example on Allegro... whether > started off in > > an emacs buffer or a console window or an IDE debug window. > In each > > environment, whether just typed in or within a > > (mp:process-run-function ...) the listener is locked.. > > OK, so I tried with Corman Lisp 3.0 (using CREATE-THREAD) - > no problems, no locking, like with LispWorks. Maybe someone > on this list can try the same with ECL, so we've covered all > Lisps on Windows with MP capabilities. I tried the Apropos example under ELC and MP, it worked without any problem. Michael.

1 0

[rdnzl-devel] Re: rdnzl, multiprocessing, Allegro, windows, locking
by Edi Weitz 16 Oct '06

16 Oct '06

On Sat, 14 Oct 2006 15:53:08 -0700, "Richard Fateman" <fateman(a)cs.berkeley.edu> wrote: >> I think that's a problem related to the IDE and not to RDNZL. In >> LispWorks 5.0, for example, if I start the apropos example coming >> with RDNZL (which also uses Application.Run) with >> MP:PROCESS-RUN-FUNCTION as suggested in the RDNZL documentation it >> runs fine without locking the IDE, i.e. I can still use the >> listener or other graphical tools while the .NET window is up and >> interacting. > > I just tried the Apropos example on Allegro... whether started off > in an emacs buffer or a console window or an IDE debug window. In > each environment, whether just typed in or within a > (mp:process-run-function ...) the listener is locked.. OK, so I tried with Corman Lisp 3.0 (using CREATE-THREAD) - no problems, no locking, like with LispWorks. Maybe someone on this list can try the same with ECL, so we've covered all Lisps on Windows with MP capabilities. > I got a response from Charley Cox that suggests another route is > needed around this, or I guess I will just have to consider changing > my model of how to program. Yeah, or you change your Lisp implementation... :)

2 5

[rdnzl-devel] Re: rdnzl, multiprocessing, Allegro, windows, locking
by Edi Weitz 15 Oct '06

15 Oct '06

On Fri, 13 Oct 2006 16:58:32 -0700, "Richard Fateman" <fateman(a)cs.berkeley.edu> wrote: > Also using something like this... > > ;; prototype for creating a thread > (defun create-thread(fun) ;function of no arguments, call as > (create-thread #'thefun) > ;; return a .NET thread > (new "Thread" (new "ThreadStart" fun))) > > (defun start (thethread) ; > [Start thethread]) > > (defun run-thread(fun) ; all together > (start (create-thread fun))) > > Does not make a difference in the way I wished, of having control > return to lisp. It still blocks, but worse, it seems that handlers > are not available for call-backs. Again, I don't think this is a problem of RDNZL but rather of how the various Lisp implementations handle callbacks into Lisp. The following code works fine (output as expected, no IDE locking) for me with LispWorks 5.0 and AllegroCL 8.0 (using SLIME) - it crashes with Corman Lisp 3.0, though. Cheers, Edi. (in-package :rdnzl-user) ;; see <http://www.lispworks.com/documentation/lw50/LWRM/html/lwref-718.htm> #+:lispworks (sys:setup-for-alien-threads) (import-type "System.Threading.Thread") (import-type "System.Threading.ThreadStart") (use-namespace "System.Threading") (enable-rdnzl-syntax) (defun create-thread (fn) (new "Thread" (new "ThreadStart" fn))) (defun start (thread) [Start thread]) (defun run-thread (fn) (start (create-thread fn))) (defparameter *counter* 0) (defun test (&optional (n 5)) (let ((out *standard-output*) (done nil)) (flet ((incf-fn () (loop (format out "In thread: ~A.~%" (incf *counter*)) (finish-output out) (sleep .3) (when done (format out "Thread finishes.~%") (finish-output out) (return-from incf-fn))))) (run-thread #'incf-fn) (dotimes (i n) (format out "Outside: ~A.~%" (incf *counter*)) (finish-output out) (sleep .7)) (setq done t))))

1 0

[rdnzl-devel] Re: rdnzl, multiprocessing, Allegro, windows, locking
by Edi Weitz 14 Oct '06

14 Oct '06

On Fri, 13 Oct 2006 16:58:32 -0700, "Richard Fateman" <fateman(a)cs.berkeley.edu> wrote: > More stuff.. > > Perhaps a bug in rdnzl, or an assumption by rdnzl violated by .net > It would seem that you could do this... > > (import-types "System.Threading" "Thread" "ThreadStart") No. The RDNZL docs say that this tries to load the assembly named "System.Threading". As there is no assembly with that name, the failure is what has to be expected. > But that does not work. Instead you have to do this > > (import-type "System.Threading.Thread") > (import-type "System.Threading.ThreadStart") Yep, that's the correct way to do it.

1 0

[rdnzl-devel] Re: rdnzl, multiprocessing, Allegro, windows, locking
by Edi Weitz 14 Oct '06

14 Oct '06

[Re-sending my reply to the mailing list to which I thought this was sent originally. My mail address is edi(a)agharta.de by the way, and not rdnzl-devel-owner(a)common-lisp.net...] On Fri, 13 Oct 2006 09:16:07 -0700, "Richard Fateman" <fateman(a)cs.berkeley.edu> wrote: > Here is what I think I is the smallest program to open a window.. > > (enable-rdnzl-syntax) > (import-types "System.Windows.Forms" "Form" "Application" ) > > [Application.Run (new "Form")] For newcomers trying to copy this: You need to add the line (use-namespace "System.Windows.Forms") before you run the application. > However, started from an emacs buffer, this locks up everything > until the window is killed. > > I can put this in another Allegro OS process by doing this.. > (mp::process-run-function "myprocessname" [Application.Run (new > "Form")]) > > But this also locks up everything until the window is killed. I think that's a problem related to the IDE and not to RDNZL. In LispWorks 5.0, for example, if I start the apropos example coming with RDNZL (which also uses Application.Run) with MP:PROCESS-RUN-FUNCTION as suggested in the RDNZL documentation it runs fine without locking the IDE, i.e. I can still use the listener or other graphical tools while the .NET window is up and interacting. > How can I do this in rdnzl? Can I mix CG and rdnzl? I don't know much about CG but I think that will be very hard or impossible. But that's not a problem of Lisp/RDNZL. I think it would be equally hard to mix a C++ program using MFC with a C# program using .NET's windows forms.

1 0

[rdnzl-devel] RE: Problem/crash with RDNZL under ECL
by Goffioul Michael 30 Sep '06

30 Sep '06

> > Maybe you can try to latest binary package for the LISP shell I > > provided at http://sourceforge.net/projects/ecls . For me, > it crashes > > at exit when I start the shell and open an existing LISP > file in the > > editor. > > I can't reproduce that. I tried with VS 2003 as well as with VS 2005. > In both cases I started VS, then the Lisp shell, then I > attached to the Lisp shell from VS. Then I opened an > existing Lisp source file from the Lisp shell and afterwards > quit the application. > > In the case of VS 2005 the debugger window said: > > The program '[3120] lispshell.exe: Managed' has exited with > code 0 (0x0). Lucky you! :-) Actually, the RDNZL.dll included in the binary package is the one compiled with VS2005, not the one provided in RDNZL package. Can you retry by using your RDNZL.dll instead? Michael.

2 1

[rdnzl-devel] Re: FW: Problem loading load.lisp in ACL 7.0
by Edi Weitz 28 Sep '06

28 Sep '06

[Cc to mailing list.] On Wed, 27 Sep 2006 15:01:33 -0600, "Tuttle, Andrew" <ATuttle(a)p2es.com> wrote: > Just thought I'd let you know that I got RDNZL to work in ACL8. > > So it's either ACL7 or the way we have it set up that was causing > the problem... Thanks for the info. If you find out that there's a specific problem with ACL7, let me know, and I'll try to fix it.

1 0

[rdnzl-devel] RE: Problem/crash with RDNZL under ECL
by Goffioul Michael 27 Sep '06

27 Sep '06

> [Cc to mailing list.] > > On Tue, 26 Sep 2006 17:59:18 +0200, "Goffioul Michael" > <goffioul(a)imec.be> wrote: > > > For your information, I switched to RDNZL.dll compiled with > VS2005 and > > I can't reproduce the problem... Even if it does not explain > > everything, at least I have a workaround :-) > > Hmm. Did you experience the crashes with the latest VS2003 > DLL? The one from 0.10.6? Yes, but I can't be sure this didn't happen with earlier versions. Also there have been recent changes in ECL to implement finalizers, which I'm trying to use in the ECL-port of RDNZL. Michael.

1 0

[rdnzl-devel] New versions 0.10.7 / 0.5.2 (Was: Problem/crash with RDNZL under ECL)
by Edi Weitz 26 Sep '06

26 Sep '06

On Tue, 26 Sep 2006 15:24:05 +0200, "Goffioul Michael" <goffioul(a)imec.be> wrote: > Currently, the only solution I'm left with is to set the invoke and > release callbacks of DelegateAdapter class to null before exiting > and add nullity-check code to DelegateAdapter class before calling > those callbacks. I've released new versions of the Lisp and the C++ code which implement this - just in case. Thanks for the suggestion.

1 0

[rdnzl-devel] RE: Problem/crash with RDNZL under ECL
by Goffioul Michael 26 Sep '06

26 Sep '06

> > In my case, I can easily reproduce it by running my LISP into the > > Visual Studio debugger and run the apropos example. On exit, I'm > > warned by the debugger about the access violation. Note > that if I run > > the LISP outside the debugger, I'm not notified at all. > > I just tried with VS 2003. I started LispWorks 5.0, then > attached the VS debugger to LW, then loaded RDNZL, then > loaded and ran the apropos example. Finally, I quit > LispWorks. I didn't get any messages, though. Maybe this > only happens with .NET 2.0? Or is it specific to ECL? Or do > I have to do something else? I'm not familiar with the VS debugger. > > Nevertheless, it's pretty disturbing that DelegateAdapter > objects are /never/ released... :( I don't know if this specific to .NET 2.0. There are so many different parameters, it's difficult to tell. Can you trace whether your .NET objects referenced in LISP get collected or not? In the case of the apropos example, it appears that the KeyPressEventHandler object never got collected in the LISP world. Michael.

2 1