Re: Questions about multiprocessing

Unable to parse email body. Email id is 3790

Re: Questions about multiprocessing

davef@lispworks.com writes:

> For a listener window, display a CAPI interface that includes
> CAPI:LISTENER-PANE/
> http://www.lispworks.com/documentation/lw445/CAPRM/html/capiref-174.htm

This reminds me that I wanted to ask a related question: What is
the best way to avoid the "Something wrong with the echo area"-
messages that you get if you type control characters into listener-
or collector-panes? Should one provide a minibuffer for messages,
or is there a simpler solution?
-- 
  (espen)

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

Re: Questions about multiprocessing

Unable to parse email body. Email id is 3793

Re: Questions about multiprocessing

davef@lispworks.com writes:

> If you need the echo area interaction, then you can do it like this:
>
> (capi:contain (make-instance 'capi:listener-pane :echo-area t))
>
> and retain the pre-defined keys.

That might be the most useful solution.

Thanks a lot!
-- 
  (espen)

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

Re: Questions about multiprocessing

On Wed, 27 Apr 2005 09:08:49 +0200, Espen Vestre <ev@netfonds.no> wrote:

> This reminds me that I wanted to ask a related question: What is the
> best way to avoid the "Something wrong with the echo area"- messages
> that you get if you type control characters into listener- or
> collector-panes? Should one provide a minibuffer for messages, or is
> there a simpler solution?

I had the same problem with an application some time ago and I ended
up providing an echo area pane (with the :ECHO-AREA-PANE keyword
argument) and hiding that pane behind a switchable layout - it's there
so that you won't get any complaints from the editor pane but the user
doesn't see it.

Works for me but if there's a simpler solution I'd also like to hear
it... :)

Cheers,
Edi.

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

Re: Questions about multiprocessing

At 26/04/2005 19:15, davef@lispworks.com wrote:

>  > How to create a new process that has its own listener window (or console)?
>
>For a listener window, display a CAPI interface that includes
>CAPI:LISTENER-PANE/
>http://www.lispworks.com/documentation/lw445/CAPRM/html/capiref-174.htm
>
>For a Windows console window (if that's what you mean) check the
>documentation of SAVE-IMAGE, in particular the :CONSOLE argument.
>http://www.lispworks.com/documentation/lw445/LWRM/html/lwref-214.htm

Actually I had seen CAPI:LISTENER-PANE in the documentation but 
was looking for a more immediate solution (I have not yet practiced CAPI).

I also have seen lispworks:start-tty-listener which could be 
sufficient to me if it is possible to specify variables to be 
initially bound in the process started by start-tty-listener 
(especially *read-table* and IO variables). Is this possible?


>  > What are the purpose of the variables in
>  > mp:*process-initial-bindings*?
>
>These have various purposes.
>
>  >                               Are these bindings always required
>  > when creating a new process? Or should some of them been 
> removed in some situations?
>
>The MP::*ACTIONS-BEFORE-SLEEPING* binding is essential.
>
>Otherwise, each binding is essential or otherwise depending what the
>process does. For example, if it uses the editor, then you definitely
>need the EDITOR::*EDITOR-INPUT-STYLE* binding. If it reads, well then
>the SYS::*READER-STATE* binding is useful.
>
>I don't see any real harm in leaving all these bindings as-is and
>simply appending to the list as in the examples in the LispWorks
>Reference Manual. (Do you?)

Not really. I got into difficulties with tracing some functions 
in a process I started. I looked in mp:*process-initial-bindings* 
before I realize I was trying to trace a function object. 3 years 
without programming in Lisp, I'm almost turned into a beginner again :-(

BTW, what is the LW common way to "spy" a function object like 
the one in the following example? Is it defadvice?

(defun bar () :bar)

(defstruct container ()
   (function-object))

(defvar *c (make-container
              :function-object (fdefinition 'bar)))

(funcall (container-function-object *c))


Francis


>It may cause a few symbols to be retained unnecessarily in a delivered
>application, but that is not a big loss.
>
>__
>Dave Fox
>LispWorks Ltd
>St John's Innovation Centre
>Cowley Road
>Cambridge
>CB4 0WS
>England
>
>+44 1223 421861
>
>
>______________________________________________________________________
>This email has been scanned by the MessageLabs Email Security System.
>For more information please visit http://www.messagelabs.com/email
>______________________________________________________________________


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

Re: Questions about multiprocessing

Unable to parse email body. Email id is 3803

Re: Questions about multiprocessing

At 27/04/2005 17:28, davef@lispworks.com wrote:

>  > >  > How to create a new process that has its own listener window (or console)?
>  > >
>  > >For a listener window, display a CAPI interface that includes
>  > >CAPI:LISTENER-PANE/
>  > >http://www.lispworks.com/documentation/lw445/CAPRM/html/capiref-174.htm
>  > >
>  > >For a Windows console window (if that's what you mean) check the
>  > >documentation of SAVE-IMAGE, in particular the :CONSOLE argument.
>  > >http://www.lispworks.com/documentation/lw445/LWRM/html/lwref-214.htm
>  >
>  > Actually I had seen CAPI:LISTENER-PANE in the documentation but
>  > was looking for a more immediate solution (I have not yet practiced CAPI).
>  >
>  > I also have seen lispworks:start-tty-listener which could be
>  > sufficient to me if it is possible to specify variables to be
>  > initially bound in the process started by start-tty-listener
>  > (especially *read-table* and IO variables). Is this possible?
>
>If you already have a console window then this does what I think you
>want:
>
>(let ((mp:*process-initial-bindings*
>        (cons (cons 'greeting "Hi Francis")
>              mp:*process-initial-bindings*)))
>   (start-tty-listener))
>
>Get a console window in LispWorks by specifying the :CONSOLE argument
>when you save a LispWorks image, or by the handy trick
>
>  (READ-LINE *TERMINAL-IO*)

I take both!


>  >
>  > >  > What are the purpose of the variables in
>  > >  > mp:*process-initial-bindings*?
>  > >
>  > >These have various purposes.
>  > >
>  > >  >                               Are these bindings always required
>  > >  > when creating a new process? Or should some of them been
>  > > removed in some situations?
>  > >
>  > >The MP::*ACTIONS-BEFORE-SLEEPING* binding is essential.
>  > >
>  > >Otherwise, each binding is essential or otherwise depending what the
>  > >process does. For example, if it uses the editor, then you definitely
>  > >need the EDITOR::*EDITOR-INPUT-STYLE* binding. If it reads, well then
>  > >the SYS::*READER-STATE* binding is useful.
>  > >
>  > >I don't see any real harm in leaving all these bindings as-is and
>  > >simply appending to the list as in the examples in the LispWorks
>  > >Reference Manual. (Do you?)
>  >
>  > Not really. I got into difficulties with tracing some functions
>  > in a process I started. I looked in mp:*process-initial-bindings*
>  > before I realize I was trying to trace a function object. 3 years
>  > without programming in Lisp, I'm almost turned into a beginner again :-(
>
>Some Common Lisp implementations do trace function objects, whereas
>LispWorks traces only the symbol (or SETF name), so it could be that
>you are remembering implementation-specific behavior, and have not
>forgotten anything really :)
>
>  > BTW, what is the LW common way to "spy" a function object like
>  > the one in the following example? Is it defadvice?
>
>No, DEFADVICE has the same restriction.
>
>  > (defun bar () :bar)
>  >
>  > (defstruct container ()
>  >    (function-object))
>  >
>  > (defvar *c (make-container
>  >               :function-object (fdefinition 'bar)))
>  >
>  > (funcall (container-function-object *c))
>
>I would probably just put a print statement in BAR though you might
>want to use something like this:
>
>  (trace (funcall :when (eq (car *traced-arglist*) (fdefinition 'bar)))
>         (apply :when (eq (car *traced-arglist*) (fdefinition 'bar))))


This too!

Thanks Dave,

Francis


>__
>Dave Fox
>LispWorks Ltd
>St John's Innovation Centre
>Cowley Road
>Cambridge
>CB4 0WS
>England
>
>+44 1223 421861
>
>
>______________________________________________________________________
>This email has been scanned by the MessageLabs Email Security System.
>For more information please visit http://www.messagelabs.com/email
>______________________________________________________________________


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________