From edi at agharta.de  Sat Oct 14 16:32:50 2006
From: edi at agharta.de (Edi Weitz)
Date: Sat, 14 Oct 2006 18:32:50 +0200
Subject: [rdnzl-devel] Re: rdnzl, multiprocessing, Allegro, windows, locking
In-Reply-To: <00f701c6ef23$7ddf0720$230110ac@RJFE510> (Richard Fateman's
	message of "Fri, 13 Oct 2006 16:58:32 -0700")
References: <00f701c6ef23$7ddf0720$230110ac@RJFE510>
Message-ID: <ufydq97t9.fsf@agharta.de>

[Re-sending my reply to the mailing list to which I thought this was
sent originally.  My mail address is edi at agharta.de by the way, and
not rdnzl-devel-owner at common-lisp.net...]

On Fri, 13 Oct 2006 09:16:07 -0700, "Richard Fateman" <fateman at 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.


From edi at agharta.de  Sat Oct 14 18:19:24 2006
From: edi at agharta.de (Edi Weitz)
Date: Sat, 14 Oct 2006 20:19:24 +0200
Subject: [rdnzl-devel] Re: rdnzl, multiprocessing, Allegro, windows, locking
In-Reply-To: <00f701c6ef23$7ddf0720$230110ac@RJFE510> (Richard Fateman's
	message of "Fri, 13 Oct 2006 16:58:32 -0700")
References: <00f701c6ef23$7ddf0720$230110ac@RJFE510>
Message-ID: <uwt7269qr.fsf@agharta.de>

On Fri, 13 Oct 2006 16:58:32 -0700, "Richard Fateman" <fateman at 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.


From edi at agharta.de  Sun Oct 15 11:43:20 2006
From: edi at agharta.de (Edi Weitz)
Date: Sun, 15 Oct 2006 13:43:20 +0200
Subject: [rdnzl-devel] Re: rdnzl, multiprocessing, Allegro, windows, locking
In-Reply-To: <012101c6efe3$85495c70$230110ac@RJFE510> (Richard Fateman's
	message of "Sat, 14 Oct 2006 15:53:08 -0700")
References: <012101c6efe3$85495c70$230110ac@RJFE510>
Message-ID: <u7iz1ajon.fsf@agharta.de>

On Sat, 14 Oct 2006 15:53:08 -0700, "Richard Fateman" <fateman at 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... :)


From edi at agharta.de  Sun Oct 15 16:06:22 2006
From: edi at agharta.de (Edi Weitz)
Date: Sun, 15 Oct 2006 18:06:22 +0200
Subject: [rdnzl-devel] Re: rdnzl, multiprocessing, Allegro, windows, locking
In-Reply-To: <00f701c6ef23$7ddf0720$230110ac@RJFE510> (Richard Fateman's
	message of "Fri, 13 Oct 2006 16:58:32 -0700")
References: <00f701c6ef23$7ddf0720$230110ac@RJFE510>
Message-ID: <uu025a7i9.fsf@agharta.de>

On Fri, 13 Oct 2006 16:58:32 -0700, "Richard Fateman" <fateman at 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))))


From cox at franz.com  Mon Oct 16 06:09:59 2006
From: cox at franz.com (Charles A. Cox)
Date: Sun, 15 Oct 2006 23:09:59 -0700
Subject: [rdnzl-devel] Re: rdnzl, multiprocessing, Allegro, windows, locking
In-Reply-To: <u7iz1ajon.fsf@agharta.de> (message from Edi Weitz on Sun, 15 Oct
	2006 13:43:20 +0200)
References: <012101c6efe3$85495c70$230110ac@RJFE510> <u7iz1ajon.fsf@agharta.de>
Message-ID: <200610160609.k9G69xgg009281@gemini.franz.com>

> > 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... :)

  It looks as if the foreign calls to .net are using the most
conservative behavior, which is to block out all threads to protect
the Lisp heap while the foreign call is active.  If this restriction
is not needed, then it should be a simple matter to remove it in
port-acl.lisp.

  I will look into this and report back.

	Charley
---
Charles A. Cox, Franz Inc.        555 12th Street, Suite 1450
Internet: cox at franz.com           Oakland, CA  94607
WWW: http://www.franz.com/        Phone: (510) 452-2000; FAX: (510) 452-0182


From edi at agharta.de  Mon Oct 16 10:32:11 2006
From: edi at agharta.de (Edi Weitz)
Date: Mon, 16 Oct 2006 12:32:11 +0200
Subject: [rdnzl-devel] Re: rdnzl, multiprocessing, Allegro, windows, locking
In-Reply-To: <200610160609.k9G69xgg009281@gemini.franz.com> (Charles A.
	Cox's message of "Sun, 15 Oct 2006 23:09:59 -0700")
References: <012101c6efe3$85495c70$230110ac@RJFE510> <u7iz1ajon.fsf@agharta.de>
	<200610160609.k9G69xgg009281@gemini.franz.com>
Message-ID: <uiriky2j8.fsf@agharta.de>

On Sun, 15 Oct 2006 23:09:59 -0700, "Charles A. Cox" <cox at franz.com> wrote:

>> > 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... :)
>
>   It looks as if the foreign calls to .net are using the most
> conservative behavior, which is to block out all threads to protect
> the Lisp heap while the foreign call is active.  If this restriction
> is not needed, then it should be a simple matter to remove it in
> port-acl.lisp.
>
>   I will look into this and report back.

Great.  Please note that I'll be away on vacation next week, so if you
send patches after Thursday, I won't be able to make a new RDNZL
release before November.

Thanks,
Edi.


From cox at franz.com  Mon Oct 16 21:30:38 2006
From: cox at franz.com (Charles A. Cox)
Date: Mon, 16 Oct 2006 14:30:38 -0700
Subject: [rdnzl-devel] Re: rdnzl, multiprocessing, Allegro, windows, locking
In-Reply-To: <uiriky2j8.fsf@agharta.de> (message from Edi Weitz on Mon, 16 Oct
	2006 12:32:11 +0200)
References: <uiriky2j8.fsf@agharta.de>
Message-ID: <200610162130.k9GLUcaC003127@gemini.franz.com>

> Great.  Please note that I'll be away on vacation next week, so if you
> send patches after Thursday, I won't be able to make a new RDNZL
> release before November.

  The diffs below fix two areas: (1) clean up external-format
initialization, and (2) enable rdnzl to run (as separate in-Lisp
processes) without locking out the rest of Lisp.

Edi, I didn't try to commit these changes even though I think I still
may have write-access to the module on common-lisp.net.  The diffs
below are relative to a checkout done today.  If you'd like me to
submit the diffs in some other way, let me know.

	Charley

===== Begin diffs =====

Index: port-acl.lisp
===================================================================
RCS file: /project/rdnzl/cvsroot/RDNZL/port-acl.lisp,v
retrieving revision 1.6
diff -c -r1.6 port-acl.lisp
*** port-acl.lisp	10 Aug 2006 15:36:47 -0000	1.6
--- port-acl.lisp	16 Oct 2006 21:25:44 -0000
***************
*** 61,67 ****
                          (ash ,get-next-octet 8)))))
  
  ;; force auto-compilation.  Suppress the unnecessary notes.
! (with-output-to-string (*standard-output*)
    (string-to-octets "foo" :external-format :rdnzl-fat))
  
  (in-package :rdnzl)
--- 61,67 ----
                          (ash ,get-next-octet 8)))))
  
  ;; force auto-compilation.  Suppress the unnecessary notes.
! (with-output-to-string (*system-messages*)
    (string-to-octets "foo" :external-format :rdnzl-fat))
  
  (in-package :rdnzl)
***************
*** 144,149 ****
--- 144,150 ----
         (ff:def-foreign-call (,lisp-name ,c-name) ,(arg-spec arg-list)
           :returning ,(ffi-map-type result-type)
           :strings-convert t
+ 	 :release-heap :when-ok
           :convention ':c)
         ,@(when (eq result-type 'ffi-wide-char)
             `((excl:fwrap ',lisp-name 'wchar_t-wrapper 'wchar_t-retval))))))

===== End diffs =====

---
Charles A. Cox, Franz Inc.        555 12th Street, Suite 1450
Internet: cox at franz.com           Oakland, CA  94607
WWW: http://www.franz.com/        Phone: (510) 452-2000; FAX: (510) 452-0182


From edi at agharta.de  Mon Oct 16 22:39:36 2006
From: edi at agharta.de (Edi Weitz)
Date: Tue, 17 Oct 2006 00:39:36 +0200
Subject: [rdnzl-devel] New version 0.10.8 (Was: rdnzl, multiprocessing,
 Allegro, windows, locking)
In-Reply-To: <200610162130.k9GLUcaC003127@gemini.franz.com> (Charles A.
	Cox's message of "Mon, 16 Oct 2006 14:30:38 -0700")
References: <uiriky2j8.fsf@agharta.de>
	<200610162130.k9GLUcaC003127@gemini.franz.com>
Message-ID: <uirijx4uv.fsf_-_@agharta.de>

On Mon, 16 Oct 2006 14:30:38 -0700, "Charles A. Cox" <cox at franz.com> wrote:

>   The diffs below fix two areas: (1) clean up external-format
> initialization, and (2) enable rdnzl to run (as separate in-Lisp
> processes) without locking out the rest of Lisp.

Thanks, I've released a new version which incorporates your patches.

> Edi, I didn't try to commit these changes even though I think I
> still may have write-access to the module on common-lisp.net.  The
> diffs below are relative to a checkout done today.  If you'd like me
> to submit the diffs in some other way, let me know.

That's fine.  Of course you still have write access, but the
common-lisp.net CVS currently isn't in sync with my local CVS anyway:

  http://common-lisp.net/pipermail/rdnzl-devel/2006-September/000100.html

Cheers,
Edi.


From cox at franz.com  Mon Oct 16 22:49:34 2006
From: cox at franz.com (Charles A. Cox)
Date: Mon, 16 Oct 2006 15:49:34 -0700
Subject: [rdnzl-devel] Re: New version 0.10.8 (Was: rdnzl, multiprocessing,
 Allegro, windows, locking)
In-Reply-To: <uirijx4uv.fsf_-_@agharta.de> (message from Edi Weitz on Tue, 17
	Oct 2006 00:39:36 +0200)
References: <uiriky2j8.fsf@agharta.de>
	<200610162130.k9GLUcaC003127@gemini.franz.com>
	<uirijx4uv.fsf_-_@agharta.de>
Message-ID: <200610162249.k9GMnYpO005697@gemini.franz.com>

> Thanks, I've released a new version which incorporates your patches.

  Thanks for the quick turnaround.

	Charley
---
Charles A. Cox, Franz Inc.        555 12th Street, Suite 1450
Internet: cox at franz.com           Oakland, CA  94607
WWW: http://www.franz.com/        Phone: (510) 452-2000; FAX: (510) 452-0182


From goffioul at imec.be  Tue Oct 17 10:00:49 2006
From: goffioul at imec.be (Goffioul Michael)
Date: Tue, 17 Oct 2006 12:00:49 +0200
Subject: [rdnzl-devel] Re: rdnzl, multiprocessing, Allegro, windows,
	locking
Message-ID: <38C0C9E3083ADB42BFFFC6C2A8B012CE04BC20FA@WINEX2.imec.be>

> > 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.


From goffioul at imec.be  Wed Oct 25 09:51:48 2006
From: goffioul at imec.be (Goffioul Michael)
Date: Wed, 25 Oct 2006 11:51:48 +0200
Subject: [rdnzl-devel] RDNZL C++ used in non-LISP environment
Message-ID: <38C0C9E3083ADB42BFFFC6C2A8B012CE04D13CB5@WINEX2.imec.be>

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.


From edi at agharta.de  Wed Oct 25 22:52:22 2006
From: edi at agharta.de (Edi Weitz)
Date: Thu, 26 Oct 2006 00:52:22 +0200
Subject: [rdnzl-devel] RDNZL C++ used in non-LISP environment
In-Reply-To: <38C0C9E3083ADB42BFFFC6C2A8B012CE04D13CB5@WINEX2.imec.be>
	(Goffioul Michael's message of "Wed, 25 Oct 2006 11:51:48 +0200")
References: <38C0C9E3083ADB42BFFFC6C2A8B012CE04D13CB5@WINEX2.imec.be>
Message-ID: <u64e8knyx.fsf@agharta.de>

Hi Michael!

On Wed, 25 Oct 2006 11:51:48 +0200, "Goffioul Michael" <goffioul at imec.be> wrote:

> 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?

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.)

BTW, note that I just returned from vacation (earlier than expected)
and will be in Boston next week, so you'll probably have to wait a bit
until this'll actually happen.

Cheers,
Edi.


From goffioul at imec.be  Thu Oct 26 08:18:13 2006
From: goffioul at imec.be (Goffioul Michael)
Date: Thu, 26 Oct 2006 10:18:13 +0200
Subject: [rdnzl-devel] RDNZL C++ used in non-LISP environment
Message-ID: <38C0C9E3083ADB42BFFFC6C2A8B012CE04DE0125@WINEX2.imec.be>

> > 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.


From edi at agharta.de  Thu Oct 26 19:03:44 2006
From: edi at agharta.de (Edi Weitz)
Date: Thu, 26 Oct 2006 21:03:44 +0200
Subject: [rdnzl-devel] RDNZL C++ used in non-LISP environment
In-Reply-To: <38C0C9E3083ADB42BFFFC6C2A8B012CE04DE0125@WINEX2.imec.be>
	(Goffioul Michael's message of "Thu, 26 Oct 2006 10:18:13 +0200")
References: <38C0C9E3083ADB42BFFFC6C2A8B012CE04DE0125@WINEX2.imec.be>
Message-ID: <uy7r23nn3.fsf@agharta.de>

On Thu, 26 Oct 2006 10:18:13 +0200, "Goffioul Michael" <goffioul at imec.be> wrote:

> The header can be created by:
>
> grep -E '__declspec(dllexport)' *.h | sed -e 's/dllexport/dllimport/g'

OK.

> The import lib file is created by VS200X when building the DLL.

So, I don't need to include it, right?


From goffioul at imec.be  Fri Oct 27 08:54:39 2006
From: goffioul at imec.be (Goffioul Michael)
Date: Fri, 27 Oct 2006 10:54:39 +0200
Subject: [rdnzl-devel] RDNZL C++ used in non-LISP environment
Message-ID: <38C0C9E3083ADB42BFFFC6C2A8B012CE04DE0788@WINEX2.imec.be>

> > 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.