threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?



  • 1. I/O libraries?
    Judging by the fairly involved conversation about reading from strings in another thread, and the code that was produced, there is a fairly severe lack of support for I/O in Lisp. Sure, you managed to write a "safe-read" function eventually, but the mere fact that this was neccessary shows that standard support is lacking. As such, I'm going to have to ask two questions: - First, are there any I/O libraries around that would handle this properly? - Second, what would be the procedure for making this part of the CL standard? Is anyone actually working on it? I'm writing an application that will take arbitrary input from the internet, and I'd appreciate it if someone a bit more experienced than I am were to think about security.

Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?

Postby Petter Gustad » Fri, 01 May 2009 00:19:56 GMT

AJ Rossini < XXXX@XXXXX.COM > writes:

Does anybody know what happened to NetCLOS and how usable it is?

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Similar Threads:

1.threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?

2.threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?

Dear all -

Is there any package that provides (or plans to provide) a general
interface to threaded or similar parallel-execution technologies (user
space message passing or user-space shared-mem) with the generality
being across the "free" lisps (I'd include things like the personal
editions from commercial vendors, since I'd like to be able to check
these as needed)?

My current guess is that bordeaux-threads would be the best starting
point, but is anyone aware of a currently maintained package which
might be relevant in particular for multicore architectures?  (it
looks like it's been dormant for a bit).

Any pointers welcome!

3.returning cffi pointers with sb-threads


I have a C function that allocates/fills two C structures then enters
into a loop (catching events for an X11 window).  I need these two
structures while it is running, so I thought I would pass pointers to
the C function, where it can place pointers to these new stuctures.
After the thread has started, I save the thread and the two pointers
in a class.  The Lisp code looks like this (I am using SBCL):

(cffi:defcfun ("create_xlib_context" create_xlib_context) :int
  (display_name :string)
  (width :int)
  (height :int)
  (xc-pointer :pointer)
  (context-pointer :pointer))

(defun create-xlib-context (width height &optional (display-name ":0"))
  (let ((xlc (make-instance 'xlib-context))
	(xc-pointer (foreign-alloc :pointer))
	(context-pointer (foreign-alloc :pointer)))
    (setf (slot-value xlc 'thread)
	   (lambda () 
	     (let ((err (create_xlib_context display-name width height
					     xc-pointer context-pointer)))
	       (unless (zerop err)
		 (error "Error ~a when creating xlib-context." err))))))
    ;; extract slots
    (setf (slot-value xlc 'xc) (mem-ref xc-pointer :pointer))
    (setf (slot-value xlc 'pointer) (mem-ref context-pointer :pointer))
    (foreign-free xc-pointer)
    (foreign-free context-pointer)

The skeleton of the C functions is

create_xlib_context(char *display_name,
		    unsigned int width,
		    unsigned int height,
		    xlib_context **xc_pointer,
		    cairo_t **context_pointer) {
    *xc_pointer = xc;
    *context_pointer = context;
    for (;;) {

Something weird is going on, because the two pointers I get back are
not the right ones (I print them from the C function for debugging).
Any suggestions?



4.Audit code request: clisp ffi interface to tcl/tk

5.Unified lisp

Greetings!  Just dreaming of the distant (possible) future and how one
might get there.  I'm wondering whether there are any

scheme      -> common lisp
emacs lisp  -> common lisp
islisp      -> common lisp

source translators available.  If not, I'm interested in exploring the
difficulty of implementing such.  I'm also interested in which dialect
is more suitable for hosting the others, if any.

Take care,
Camm Maguire			     			 XXXX@XXXXX.COM 
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

6. bug in a cffi? (crossposting from cffi-devel)

7. multicore lisp?

8. OT: multicore lisp?

Return to lisp


Who is online

Users browsing this forum: No registered users and 59 guest