Geoff Cant | 14 Dec 2005 11:02
X-Face
Picon

Pong server example


Hi all, I've written a few little patches and a pong server example
for erlisp.

My public darcs repo lives at (http://darcs.lisp.geek.nz/~nem/erlisp/).

I'm working on linked processes at the moment (and investigating ecl
support, distribution and maybe faster openmcl with-timeout replacements).

Cheers,
--

-- 
Geoff

ps: sorry for the short/non-explanatory message - it's 23:00ish here :)
Faré | 22 Nov 2005 10:28
Picon
Gravatar

Various

Grid Computing with clisp: http://grid.bmk.com.au/

Also, here's some SBCL code that implements a the basics required for
properly handling user-level asynchronous signals. Notably lacking is
integration into the event loop: calling (process-check-signals)
before to receive things, and after being woken up from sleep if
nothing was available at first.

(defun make-lock (name)
  (sb-thread:make-mutex :name name))

(defmacro with-lock-held ((lock &optional whostate) &body body)
  (declare (ignore whostate))
  `(sb-thread:with-mutex (,lock)
     , <at> body))

(defclass process ()
  ((name :initform ""
	 :initarg :name
	 :type string
	 :accessor process-name)
   (thread :initform nil
	   :initarg :thread
	   :accessor process-thread)
   (function :initform nil
	     :initarg :function
	     :accessor process-function)
   (lock :initform (make-lock "thread lock")
	  :accessor process-lock)
   (signal :initform nil
(Continue reading)

Eric Lavigne | 17 Sep 2005 01:32
Picon
Gravatar

broken process linking code

This is the process-linking code I wrote over the summer. It doesn't
work, and classes keep me too busy to continue working on it right
now. Hopefully someone will have time to fix it. Otherwise I will
probably get back to it in a few months.

The problem, most likely, is in messaging.lisp. I added calls to a new
function at the beginning of send, receive, and receive-with-matcher,
so that if a process were marked for destruction it would die before
affecting other processes (thus the hook in send) and as soon as
possible (thus the hooks in a couple other places). I didn't
understand the macros that I was trying to modify, so I was not so
surprised to get a bad result. Keeping the hook only in send might fix
the problem, but that could be horribly inefficient depending on how
often the process tries to send messages.

There is also a need for a new test for process-linking. I vaguely
remember writing at least a basic test, but there doesn't seem to be
one in my working directory.

manager.lisp
   most new code
messaging.lisp
   hooks into old code created in send/receive/receive-with-matcher
process.lisp
   "time-to-die" flag added to process class
erlisp.asd
   new entry for manager.lisp
Attachment (plinking.zip): application/octet-stream, 4993 bytes
(Continue reading)

Eric Lavigne | 2 Sep 2005 14:32
Picon
Gravatar

undefined-symbol

I am confused by this error message.

; 
; File: /root/erlisp/erlisp-cmucl/erlisp/src/manager.lisp

; In: DEFUN SYSTEM-MANAGER-PROCESS

;   (RECEIVE-WITH-MATCHER (COND-MATCHER M) (T M))
; Error: (during macroexpansion)
; Error in KERNEL::UNDEFINED-SYMBOL-ERROR-HANDLER:  the function
LISTEN-TO-SYSTEM-MANAGER is undefined.
; 
; Error: (during macroexpansion)
; Error in KERNEL::UNDEFINED-SYMBOL-ERROR-HANDLER:  the function
LISTEN-TO-SYSTEM-MANAGER is undefined.
; 
; Converted SYSTEM-MANAGER-PROCESS.

It complains that function LISTEN-TO-SYSTEM-MANAGER is undefined, but
you can see here that this undefined function is defined immediately
before the function that complains about it being missing. It seems
like everything I've tried over the last two days lead to some sort of
missing function error, and this still doesn't make sense to me. When
I write small Lisp codes on my own, it doesn't seem to matter in which
order I define functions. As long as all the functions are defined
before I start actually running the functions, everything just works.
What is different here? Is symbol scope related to

Excerpt from manager.lisp:

(Continue reading)

Dirk Gerrits | 1 Sep 2005 22:18

Description of pushed patches.


sbcl no longer supports (sb-thread:current-thread-id).
bryan d. o'connor <bryan <at> lunch.org>**20050830023327] 

openmcl-threads using semaphores.
bryan d. o'connor <bryan <at> lunch.org>**20050901181244] 

allegro-threads using gates.
bryan d. o'connor <bryan <at> lunch.org>**20050901235948
 patch written by Dirk Gerrits.

_______________________________________________
erlisp-devel site list
erlisp-devel <at> common-lisp.net
http://common-lisp.net/mailman/listinfo/erlisp-devel

Eric Lavigne | 2 Sep 2005 07:10
Picon
Gravatar

Erlisp file loading order

I am running into another issue involving file loading order.

node.lisp contains the following line:
     (defvar *current-node* (make-instance 'local-node))

Now that nodes are more than just an empty class (each node has a
system-manager), there is a need to call functions while creating node
instances (such as spawn).

Is it okay to have circular dependencies in asdf?
                             (:file "node"
                                    :depends-on ("package" "process"))
                             (:file "process"
                                    :depends-on ("package" "mailbox" "node"
                                                 "compatibility"))
_______________________________________________
erlisp-devel site list
erlisp-devel <at> common-lisp.net
http://common-lisp.net/mailman/listinfo/erlisp-devel

Eric Lavigne | 2 Sep 2005 02:41
Picon
Gravatar

receive

(setf msg (receive t))

Would this receive any available message and assign that message to msg?

Eric
_______________________________________________
erlisp-devel site list
erlisp-devel <at> common-lisp.net
http://common-lisp.net/mailman/listinfo/erlisp-devel

Dirk Gerrits | 1 Sep 2005 07:38

Description of pushed patches.


openmcl-threads
bryan d. o'connor <bryan <at> lunch.org>**20050830025955
 Modified threading procedures in compatibility.lisp
 to support OpenMCL.
_______________________________________________
erlisp-devel site list
erlisp-devel <at> common-lisp.net
http://common-lisp.net/mailman/listinfo/erlisp-devel

bryan o'connor | 30 Aug 2005 05:27
Favicon

openmcl patches

i've filled in the missing pieces in compatibility.lisp to
support openmcl.  all tests pass reliably except the test
receive-with-timeout occassionally runs a few milliseconds
too long.

my darcs repo is here:
   http://monday-monkey.com/repos/erlisp/

     ...bryan

_______________________________________________
erlisp-devel site list
erlisp-devel <at> common-lisp.net
http://common-lisp.net/mailman/listinfo/erlisp-devel

Eric Lavigne | 29 Aug 2005 18:03
Picon
Gravatar

receiving, pattern-matching

How does receive work? I see that one of the arguments is a pattern
for indicating what sort of message I am interested in, but I don't
understand how to write/interpret such a pattern. Also, will I receive
only the first message that matches this pattern? What happens if no
messages match the pattern? Returns nil immediately? Block until such
a message arrives?

Specifically, I would like to send a list as a message and recognize
the message type based on the first element.
Example (recognize that this starts with 'system): 
                    (list 'system 'link-request 'notify)
I would like to receive the first message from the mailbox in
*current-process* whose first element is 'system, returning
immediately in the case where no such message is found. How could I
set up a pattern-matcher for this? Can I use receive? Or will I need
to use receive-with-timeout and a short time limit?

Better still, is there a way to set up a default handler that would
perform predefined action whenever a message matching its pattern
shows up? If so, I would like to use this. If not, I think it would be
worth adding later. I can imagine writing an entire program made up
entirely of default handlers for various message patterns.

I think that I'm very close to finishing process-linking, but my
confusion over the messaging system is holding me back.

Eric
_______________________________________________
erlisp-devel site list
erlisp-devel <at> common-lisp.net
(Continue reading)

Dirk Gerrits | 25 Aug 2005 20:05

Description of pushed patches.


Expanded timeout clause syntax to support time-units.

condition-terminates-process
Eric Lavigne <lavigne.eric <at> gmail.com>**20050824163858
 handler-case added to spawn. Unhandled conditions signalled by a process 
 will kill that process, rather than interrupting the entire lisp image.
 This provides a convenient way to kill processes, by signalling a
 condition. In later patches, the handler-case for may include code for
 sending termination messages to linked processes.

_______________________________________________
erlisp-devel site list
erlisp-devel <at> common-lisp.net
http://common-lisp.net/mailman/listinfo/erlisp-devel


Gmane