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

RE: [rdnzl-devel] RDNZL C++ used in non-LISP environment
by Goffioul Michael 27 Oct '06

27 Oct '06

> > The import lib file is created by VS200X when building the DLL. > > So, I don't need to include it, right? It depends on the target. You could think about providing RDNZL in a binary package, with the header and the import library file. Especially if you want it to be usable with other compilers like MinGW; then the user won't probably have VS200X installed. Michael.

1 0

RE: [rdnzl-devel] RDNZL C++ used in non-LISP environment
by Goffioul Michael 26 Oct '06

26 Oct '06

> > To ease my work, I created a header file and import > library, such that > > my octave module is linked with the RDNZL DLL. So I > wondered if these > > files could not be provided in some stand-alone RDNZL.DLL package, > > such that it could be used by anybody. The import library only > > publishes C function, so you can even think of providing such a > > library for MinGW compiler (although I didn't try). > > > > What do you think? > > Sounds good to me. Do I understand correctly that I'd just > have to add one or two files to the C++ source code as it is > now? Then you should just send them and I'll make a new > release. (And maybe you should provide some text which can > be added to the README file.) The header can be created by: grep -E '__declspec(dllexport)' *.h | sed -e 's/dllexport/dllimport/g' The import lib file is created by VS200X when building the DLL. Michael.

2 1

[rdnzl-devel] RDNZL C++ used in non-LISP environment
by Goffioul Michael 25 Oct '06

25 Oct '06

Hi all, Recently, I had the idea to try to bridge .NET with Octave (the Matlab clone). Instead of re-inventing the wheel, I wondered "why not try to re-use RDNZL DLL?". And it worked pretty well. Actually, RDNZL provides everything you need to bridge a C/C++ application with .NET, without having to handle the managed part yourself. It's not really bound to LISP. To ease my work, I created a header file and import library, such that my octave module is linked with the RDNZL DLL. So I wondered if these files could not be provided in some stand-alone RDNZL.DLL package, such that it could be used by anybody. The import library only publishes C function, so you can even think of providing such a library for MinGW compiler (although I didn't try). What do you think? Michael.

2 1

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