Re: [Sbcl-devel] What are you using SBCL for?

[Raymond W. <Ray...@fa...>]

Peter Van Eynde writes:
 > Hi people,
 > 
 > I've commented on a few things.
 > 
 > As to my plans, I just want a lisp for students in the 21'th century
 > :-). Stable and with a lot of libraries to easily integrate with the
 > rest of the world. Simple, not?
 > 
 > > 4) delivery issues, packaging stuff.  SAVE-LISP{,-AND-DIE} is great,
 > > and all, but I get strange looks when I tell people the executables
 > > will each be 20Mb in size and won't share code pages between them.
 > 
 > Sharing pages can only be done if they are in the oldest 'frozen'
 > generation that is mmaped R/O. This is not possible with the current VM
 > (AFAIK). Having then COW could only provide sharing until the first
 > major GC.

	I thought that the data in sbcl.core effectively became
read-only. If I'm mistaken (as it seems I am), the 20 MB becomes more
of an issue.

 > Having a simple-to-user webserver would be nice. Clim presentation based
 > would be divine :-).

	I suspect that Daniel Barlow's "Araneida" may be a candidate
for the first. With respect to CLIM, there has been some activity
on the free-clim mailing lists lately - some people have been working
on a free CLIM over the summer. Most of this work has been done under
CMUCL, so it should be possible to get this to work under SBCL,
too. Somebody will have to get CLX working first, though (I think!)

 > > 	1) Reduce the interdependency between the runtime (sbc) and
 > > and the Lisp code. I would like to have a single function in the
 > > runtime, callable at load time, used for resolving all other foreign
 > > functions. This function would be called through a pointer at a fixed
 > > position (i.e, similarly to the way that NIL is given a fixed value.)
 > 
 > IMHO it would be easier and simpler to (on Linux) call the kernel
 > directly. The kernel interface is easier, simpler and above all more
 > constant. Glibc has a tendency to break CMUCL now and again until I
 > started using the kernel directly.
 > 
 > On unixen with a less broken libc it could be used of course :-).

	I *think* it would (still) be better to have a well-defined
set of services supplied by the runtime, and let the runtime sort out
most of the platform dependencies. Among other things, this would eman
no calls to ioctl() from (system) lisp code :-)

 > Calling from lisp to the libc always has to happen via thunks (like
 > the stubs). 
 > 
 > Having a fixed location for the address of the init function seems nice,
 > but beware that the c core also does the signal and gc stuff. This is
 > another connection to consider.

	Yup.

 > > 	2) Remove the Unix dependencies in the Lisp image, and replace
 > > them with a set of well-defined interfaces for doing various low-level
 > > things required by SBCL itself (i.e, before anny application code is
 > 
 > Like a kernel interface :-) ?

	Too system-dependent, IMHO...

 > > 	3) A mechanism for automatically generating foreign interfaces
 > > from C header files. I have been thinking about this for a while, and
 > > it should be doable. The main problem that I see is related to
 > > preprocessor functionality (which does not really fit into the normal
 > > lexer/parser pattern), but this can be overcome by simply using an
 > > external CPP.
 > 
 > What you do about all the constants being #define'ed?

	There's a way to make cpp emit all #defines at the end of the
preprocessed output. Earlier, I think I said that this was done by
specifying the "-M" switch, but that's wrong. It should be either
"-dM" or "dD" - the former outputs just the #define directives, while
the second emits #define directives along with preprocessed output.

 > > 	I've been looking at this for the FreeBSD port. For FreeBSD,
 > > an additional complication is that you cannot use dlopen() & friends
 > > from a statically linked executable, and if it's dynamically linked,
 > 
 > Likewise on Linux.
 > 
 > > you (obviously) don't get the address of dlopen() in sbcl.nm. I did
 > 
 > Using stub functions _are_ the only way.

	But having to stub 45 functions (in addition to
dlopen()/dlsym()) is clearly excessive. That's what I had to do for
the FreeBSD port, but I *may* be able to avoid it if I can arrange so
that alternate-get-global-address is called at load time for unknown
external symbols.

 > You don't know the location of dlopen. It is filled in by ld.so when
 > 'fixing-up' the executable. But it only does this in the c-core. It
 > doesn't know about the lisp-core. So lisp doesn't know the address. The
 > only other way is that the c-core tells the lisp core where dlopen
 > is...

	NIL is already handled in a similar way - it is placed at a
fixed place in the lisp core, known by both the runtime and the lisp
core. A suitable wrapper for dlopen could be handled similarly, I
think. 

 > This looks even dirtier and prone to errors.

	Possibly :-) Anyway, it was just a suggestion. I expect that
if there's any merit to the idea, it will be picked up.

	//Raymond.