From tf@another.gun.de Mon, 4 Aug 1997 12:21:17 +0200 Date: Mon, 4 Aug 1997 12:21:17 +0200 From: Thomas Fischbacher tf@another.gun.de Subject: Portable C library interface? Hi there! I've written a package that allows me to conveniently interface all different kinds of C library routines; main reason to do so was the rather braindead C interface of Allegro CL. And though this package was written for ACL, I've put some effort in designing it in a way so that it can be used with virtually any LISP supporting calls to C code and virtually any Unix. (Excluding for example GCL(ELF) for Linux, since this can't faslink.) Though it needs some more testing, first experiments are very promising. Next step will be to port it to CMU CL and non-Linux platforms (the latter requiring only change of a few constants, such as integer size, padding, etc.) Clearly, since this package is designed to provide a usable C interface portable across many different brands of Unix and LISP implementations, and since CMU CL's alien interface is among the most elaborate ones, some of the structure provided by CMU CL will be lost. On the other hand, my package can do some nice and quite unusual things. For example, every C typedef has a direct representation. Anybody out there who wants to help me with this project? -- regards, Thomas Fischbacher tf@another.gun.de From pisati@nichimen.com Fri, 08 Aug 1997 10:24:37 -0700 Date: Fri, 08 Aug 1997 10:24:37 -0700 From: Luca Pisati pisati@nichimen.com Subject: Portable C library interface? Thomas Fischbacher wrote: > > Hi there! > > I've written a package that allows me to conveniently interface > all different kinds of C library routines; main reason to do so > was the rather braindead C interface of Allegro CL. And though this > package was written for ACL, I've put some effort in designing it > in a way so that it can be used with virtually any LISP supporting > calls to C code and virtually any Unix. (Excluding for example > GCL(ELF) for Linux, since this can't faslink.) Do you mean that you wrote an FF encapsulation, in order to have a different syntax access to it ? > Though it needs some more testing, first experiments are very > promising. Next step will be to port it to CMU CL and non-Linux > platforms (the latter requiring only change of a few constants, > such as integer size, padding, etc.) > > Clearly, since this package is designed to provide a usable C > interface portable across many different brands of Unix and > LISP implementations, and since CMU CL's alien interface is > among the most elaborate ones, some of the structure provided by > CMU CL will be lost. On the other hand, my package can do some > nice and quite unusual things. For example, every C typedef > has a direct representation. > > Anybody out there who wants to help me with this project? I'm intersted to know more about what you did. ... and I have a lot of expertience with FF usage ... -- Luca Pisati Voice: (310) 577-0518 Nichimen Graphics Fax: (310) 577-0577 12555 W. Jefferson #285 EMail: mailto:pisati@nichimen.com Los Angeles, CA 90066 Web: http://www.nichimen.com From dwighth@intellinet.com Fri, 8 Aug 1997 17:22:13 -0500 Date: Fri, 8 Aug 1997 17:22:13 -0500 From: Dwight Hughes dwighth@intellinet.com Subject: Code for the Xok exokernel from MIT? Can anyone in this group manage to get their hands on the code for the Xok exokernel at MIT - or at least a complete interface specification? This could be quite useful to LispOS in meeting the needs for extreme flexibility, Lisp to the metal, performance, and the ability to run much Unix software without modification (with the addition of MIT's ExOS to the Xok). MIT has been developing an approach to OS design they call an exokernel. The first of these was the Aegis exokernel for MIPS-based DECstations -- now they have developed the Xok for Intel x86 architectures. The concept behind the exokernel is that the job of the kernel should *only* be "to allocate, deallocate and multiplex physical resources in a secure way". This means that the exokernel should *not* define any hardware abstractions (like even microkernels do) but instead rather directly export the hardware state to user level apps that can then define whatever abstractions they desire. A "normal" OS would then be defined of two parts: the exokernel and what they call a library OS, or libOS, at the user level. User level programs would then use the libOS much like any OS - with one *big* difference: any user program can also directly gain access to the hardware and define any abstractions it might need to be efficient. Developing new OSs is just a matter of defining a new libOS. (The exokernel approach can wail - at times up to 2 orders of magnitude faster than even well tuned Un*x type OSs.) exokernel papers: http://www.pdos.lcs.mit.edu/PDOS-papers.html The rationale behind the exokernel is put forth in: "Exterminate All Operating System Abstractions", by Dawson R. Engler and M. Frans Kaashoek. The Xok/ExOS is defined and discussed in: "Application performance and flexibility on exokernel systems", by M. Frans Kaashoek, Dawson R. Engler, Gregory R. Ganger, Héctor M. Briceño, Russell Hunt, David Mazières, Thomas Pinckney, Robert Grimm, John Jannotti, and Kenneth Mackenzie. The Aegis exokernel in: "Exokernel: An Operating System Architecture for Application-Level Resource Management", by Dawson R. Engler, M. Frans Kaashoek, and James O'Toole Jr. -- Dwight From marcusd@cathcart.sysc.pdx.edu 08 Aug 1997 23:45:45 -0700 Date: 08 Aug 1997 23:45:45 -0700 From: Marcus G. Daniels marcusd@cathcart.sysc.pdx.edu Subject: Code for the Xok exokernel from MIT? >>>>> "DH" == Dwight Hughes writes: DH> exokernel papers: http://www.pdos.lcs.mit.edu/PDOS-papers.html DH> The rationale behind the exokernel is put forth in: "Exterminate DH> All Operating System Abstractions", by Dawson R. Engler and DH> M. Frans Kaashoek. Also, Dawson Engler's papers (and sources) for vcode may also be of interest to some folks. Vcode is a C library for generating native code on-the-fly. From dwighth@intellinet.com Sat, 9 Aug 1997 16:14:12 -0500 Date: Sat, 9 Aug 1997 16:14:12 -0500 From: Dwight Hughes dwighth@intellinet.com Subject: Code for the Xok exokernel from MIT? | From: Marcus G. Daniels | | >>>>> "DH" == Dwight Hughes writes: | | | DH> exokernel papers: http://www.pdos.lcs.mit.edu/PDOS-papers.html | | DH> The rationale behind the exokernel is put forth in: "Exterminate | DH> All Operating System Abstractions", by Dawson R. Engler and | DH> M. Frans Kaashoek. | | Also, Dawson Engler's papers (and sources) for vcode may also be of interest | to some folks. Vcode is a C library for generating native code on-the-fly. Also on David Engler's page at http://www.pdos.lcs.mit.edu/~engler/ is his thesis paper covering the exokernel design and implementation for the Aegis exokernel in a much more thorough fashion than the papers I cited earlier. -- Dwight From dwighth@intellinet.com Sun, 10 Aug 1997 01:23:32 -0500 Date: Sun, 10 Aug 1997 01:23:32 -0500 From: Dwight Hughes dwighth@intellinet.com Subject: A couple of Lisp code resources . . . PLOB! (Persistent Lisp OBjects!) code and doc: http://www.lisp.de/software/plob/Welcome.html Mockmma: a Common Lisp package and libraries that implement a symbolic math language compatible with Mathematica(tm) -- http://http.cs.berkeley.edu/~fateman/mma.mailer (a note on where to ftp the code from and how to use it) -- Dwight From bernardp@cli.di.unipi.it Tue, 26 Aug 1997 11:29:20 +0200 (MET DST) Date: Tue, 26 Aug 1997 11:29:20 +0200 (MET DST) From: Pierpaolo Bernardi bernardp@cli.di.unipi.it Subject: .pdf formatted Alto documentaion] Hi, The following may be of interest, Pierpaolo. ================================================================ From: aek@goonsquad.spies.com (Al Kossow) Newsgroups: comp.sys.xerox,alt.folklore.computers Subject: .pdf formatted Alto documentaion Date: 18 Aug 1997 18:09:21 GMT Organization: spies.com Lines: 12 Thanks to Dan Finch and Paul McJones, all of the individual page scans of many of the Alto manuals are now available on: http://www.spies.com/aek/alto/index.html This includes the 1979 edition of the Alto Users' Handbook, the Alto Hardware and OS manuals, the BCPL manual, Mesa system, user, and debugger manuals, the PUP protocol specs and the Alto Trek 2.1 manual. These files are quite large (3 - 7 mb each), BTW.