headers
Faried Nawaz | 2 Feb 2004 16:48

motifd on freebsd.


Hello,

I have 18e running on FreeBSD 4.9 with XFree86 4.3.0.  I can't seem to
get cmucl to interface with motifd on its own:

% xhost + localhost
% lisp
CMU Common Lisp 18e, running on xpf.nilpotent.org
With core: /usr/local/lib/cmucl/lib/lisp.core
Dumped on: Mon, 2004-02-02 20:11:17+05:00 on xpf.nilpotent.org
See <http://www.cons.org/cmucl/> for support information.
Loaded subsystems:
    Python 1.1, target Intel x86
    CLOS 18e (based on PCL September 16 92 PCL (f))
    Gray Streams Protocol Support
    CLX X Library MIT R5.02
    Motif toolkit and graphical debugger 1.0
* (setf foo bomb)
Warning:  Declaring FOO special.
Invoking debugger...
Starting server:
   will_fork  = False
   will_trace = False
   No Inet domain socket created.
   path       = /tmp/.motif_socket-p906

A Toolkit error has occurred.
Unable to connect to Motif server.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Eric Marsden | 2 Feb 2004 21:30
Picon
Picon
Favicon

Re: motifd on freebsd.


>>>>> "fn" == Faried Nawaz <fn <at> hungry.org> writes:

  fn> Starting server:
  fn> will_fork  = False
  fn> will_trace = False
  fn> No Inet domain socket created.
  fn> path       = /tmp/.motif_socket-p906
  fn> 
  fn> A Toolkit error has occurred.
  fn> Unable to connect to Motif server.

CMUCL is defaulting to using a unix-domain socket to talk to the
motifd, but it seems that it can't connect to the socket. 

  fn> ps at this point shows me a running motifd:
  fn> 
  fn> 915  p1  S      0:00.01 library:motifd -nofork -local (motifd)

this is strange: CMUCL is trying to speak to a motifd with pid 906,
whereas your motifd has pid 915. Can you check that that motifd is
really a child of your lisp process, and look at what unix-domain
sockets it has open ("lsof" will tell you this). Check that is has a
socket named "/tmp/.motif_socket-p<pid>" open. Then from CMUCL, try to
connect to that socket using EXT:CONNECT-TO-UNIX-SOCKET.

  fn> If I start motifd as a separate process and eval
  fn> 
  fn> (setf toolkit::*default-server-host* "localhost")
  fn>
(Continue reading)

Permalink | Reply | 5 comments |
headers
Faried Nawaz | 2 Feb 2004 22:59

Re: motifd on freebsd.


Eric Marsden wrote:

  this is strange: CMUCL is trying to speak to a motifd with pid 906,
  whereas your motifd has pid 915.

I'm not sure what happened then, but I ran it again, and yes, motifd is
lisp's child process:

% ps alx |grep 700
  500   700   315   0   2  0 1299056 25208 select S+    p4    0:00.19 lisp
  500   701   700   1   2  0  2912  472 poll   I     p4    0:00.01 library:moti
% 

  Can you check that that motifd is
  really a child of your lisp process, and look at what unix-domain
  sockets it has open ("lsof" will tell you this). Check that is has a
  socket named "/tmp/.motif_socket-p<pid>" open. Then from CMUCL, try to
  connect to that socket using EXT:CONNECT-TO-UNIX-SOCKET.

Right now I see

% lisp
CMU Common Lisp 18e, running on xpf.nilpotent.org
With core: /usr/local/lib/cmucl/lib/lisp.core
Dumped on: Mon, 2004-02-02 20:11:17+05:00 on xpf.nilpotent.org
See <http://www.cons.org/cmucl/> for support information.
Loaded subsystems:
    Python 1.1, target Intel x86
    CLOS 18e (based on PCL September 16 92 PCL (f))
(Continue reading)

Permalink | Reply | 1 comment |
headers
Marc Spitzer | 2 Feb 2004 23:11
Favicon

Re: motifd on freebsd.


On Mon, 02 Feb 2004 21:30:19 +0100
Eric Marsden <emarsden <at> laas.fr> wrote:

> 
> >>>>> "fn" == Faried Nawaz <fn <at> hungry.org> writes:
> 
>   fn> Starting server:
>   fn> will_fork  = False
>   fn> will_trace = False
>   fn> No Inet domain socket created.
>   fn> path       = /tmp/.motif_socket-p906
>   fn> 
>   fn> A Toolkit error has occurred.
>   fn> Unable to connect to Motif server.
> 
> CMUCL is defaulting to using a unix-domain socket to talk to the
> motifd, but it seems that it can't connect to the socket. 

I get worse results, motifd cores when I start the debugger with out
starting motifd manually on localhost:

*  (inspect *package*)
Starting server:
   will_fork  = False
   will_trace = False
   No Inet domain socket created.
   path       = /tmp/.motif_socket-p39548
Waiting for connection.
Accepting client on Unix socket.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Edi Weitz | 3 Feb 2004 01:08
Picon
Favicon

MP and saved cores


Is it possible to save a core with a multi-processing function that
automatically starts up when the core is loaded (on x86)? I want to
deliver an app to a customer of mine who isn't Lisp-savvy and I
thought giving him a core and a shell script to start CMUCL with this
core would be the best option (I have done this before successfully
with single-process applications).

However, with MP I have no idea how to do it. The program works fine
and does what it's supposed to do when started from the REPL but I
don't know how to "batchify" it. Here's a simple example to illustrate
my problem. Consider I have a file 'foo.lisp' like this:

  (defun foo ()
    (loop for i below 10
          do (print i) (sleep .5)))

  (compile 'foo)

  (defun bar ()
    (mp:make-process #'foo)
    (mp:make-process #'foo))

  (compile 'bar)

  (ext:save-lisp "test.core"
                 :init-function 'cl-user::bar
                 :process-command-line nil
                 :load-init-file nil
                 :print-herald nil
(Continue reading)

Permalink | Reply | 5 comments |
headers
Edi Weitz | 3 Feb 2004 01:46
Picon
Favicon

Re: MP and saved cores


On Tue, 03 Feb 2004 01:08:19 +0100, I wrote:

> Is it possible to save a core with a multi-processing function that
> automatically starts up when the core is loaded (on x86)? [blabla]

FWIW, I can achieve what I wanted by creating the core without using
the :INIT-FUNCTION keyword argument and then doing something like

  lisp -core my.core -eval '(my-start-function)'

where MY-START-FUNCTION uses MP:MAKE-PROCESS to start the MP stuff and
then MP:PROCESS-WAITs for a certain condition so that it can call
EXT:QUIT.

I'd still like to know if I can do this solely with a core file,
though.

Thanks,
Edi.
Permalink | Reply | 0 comments |
headers
Helmut Eller | 3 Feb 2004 13:07
Picon

Re: MP and saved cores


Edi Weitz <edi <at> agharta.de> writes:

> What am I doing wrong? Or is it impossible to do what I want to do?

startup-idle-and-top-level-loops is actually a loop that never
returns.  A second thread executes the REPL.

Here is slightly modified version of startup-idle-and-top-level-loops
that starts your threads instead of the REPL:

  (defun startup-idle-loop ()
    (assert (eq mp:*current-process* mp::*initial-process*) ()
            "Only the *initial-process* is intended to run the idle loop")
    (mp::init-multi-processing)
    (bar)
    (mp::idle-process-loop))

  (ext:save-lisp "test.core"
                 :init-function 'cl-user::startup-idle-loop
                 :process-command-line nil
                 :load-init-file nil
                 :print-herald nil
                 :site-init nil
                 :batch-mode t)

Helmut.
Permalink | Reply | 0 comments |
headers
Ryan Adams | 3 Feb 2004 14:02
Picon
Picon
Favicon

Newbie Performance Question Versus C++


I am writing an extremely floating-point-intensive application, that
requires the evaluation of a polynomial (not finding the roots, just
substituting) that is not known at compile time (in the C++ sense of
"compile time").  Any particular polynomial evaluation is performed
around 25,000 times with different substituted values, before moving to
another polynomial.  As you might expect, these evaluations seem to be
the limiting factors in the code execution.

As the evaluation is not known until runtime, there is a good deal of
control code surrounding the actual floating-point computations.  It
would seem that with Lisp, and CMUCL in particular, that I could compile
a function on the fly for the particular polynomial evaluation, thereby
eliminating all of the inner-loop control code, and also allow for
possible optimizations.

Is this a reasonable assumption?  Should I expect to see a performance
improvement, or would it be negligible?

Any ideas or shared experience would be very much appreciated.

Thanks in advance,
Ryan
Permalink | Reply | 9 comments |
headers
Eric Marsden | 3 Feb 2004 14:38
Picon
Picon
Favicon

Re: MP and saved cores


>>>>> "ew" == Edi Weitz <edi <at> agharta.de> writes:

  ew> Is it possible to save a core with a multi-processing function that
  ew> automatically starts up when the core is loaded (on x86)? I want to
  ew> deliver an app to a customer of mine who isn't Lisp-savvy and I
  ew> thought giving him a core and a shell script to start CMUCL with this
  ew> core would be the best option (I have done this before successfully
  ew> with single-process applications).

there are two things to look out for: (i) your init-function should return
an integer that will be the Unix exit code; (ii) your init-function
should set up a catch block for %END-OF-THE-WORLD, since this is used
by CMUCL's internal error handling machinery.

One way of achieving what you want is 

,----
|   (defun foo ()
|     (loop for i below 10
|           do (print i) (sleep .5))
|     (ext:quit))
| 
|   (defun bar ()
|     (catch 'lisp::%end-of-the-world
|       (mp::init-multi-processing)
|       (mp:make-process #'foo)
|       (mp:make-process #'foo)
|       (mp::idle-process-loop)))
`----
(Continue reading)

Permalink | Reply | 2 comments |
headers
Thomas Fischbacher | 3 Feb 2004 14:53
Picon
Favicon

Re: Newbie Performance Question Versus C++


Ryan Adams wrote:

> I am writing an extremely floating-point-intensive application, that
> requires the evaluation of a polynomial (not finding the roots, just
> substituting) that is not known at compile time (in the C++ sense of
> "compile time").  Any particular polynomial evaluation is performed
> around 25,000 times with different substituted values, before moving to
> another polynomial.  As you might expect, these evaluations seem to be
> the limiting factors in the code execution.
> 
> As the evaluation is not known until runtime, there is a good deal of
> control code surrounding the actual floating-point computations.  It
> would seem that with Lisp, and CMUCL in particular, that I could compile
> a function on the fly for the particular polynomial evaluation, thereby
> eliminating all of the inner-loop control code, and also allow for
> possible optimizations.

Bad idea.

(defun make-polynomial (v-coeffs)
  (declare (optimize (safety 0) (speed 3)))
  (let* ((v-coeffs (coerce v-coeffs '(simple-array double-float (*))))
	 (nr-coeffs (length v-coeffs)))
    #'(lambda (x)
	(declare (double-float x))
	(labels
	    ((walk (val n)
	       (declare (double-float val) (fixnum n))
	       (if (= n nr-coeffs)
(Continue reading)

Permalink | Reply | 3 comments |

Gmane