Linux-Hardware Digest #73, Volume #10 Tue, 20 Apr 99 17:13:45 EDT
Contents:
Need drivers for Toshiba SCSI DVD-ROM (Caveman)
Re: V90 Modem Setup (Rob Clark)
Re: HDD Spindown - For a Year! ("Pat Crean")
Anyone use a Yamaha CDR-400T? ("Scott M. Cooley")
MODEM Question (Rick)
Re: Matrox G100 w/4mb memory (Crossbones)
seagate tape drive support ([EMAIL PROTECTED])
Who uses scsi from Umax astra 1220 S ? ("Walter Harms")
Re: Adaptec 2940UW SCSI with SCAM? ("Walter Harms")
Re: Linux mit ATI Fury 128Range ????????? (Rainer Strathmann)
Re: Programmers are gods ("Osvaldo Pinali Doederlein")
Re: Programmers are gods (Bill Newman)
Re: Sound Blaster Live (Alpine)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Caveman)
Subject: Need drivers for Toshiba SCSI DVD-ROM
Date: Tue, 20 Apr 1999 18:30:09 GMT
please reply by e-mail to [EMAIL PROTECTED]
------------------------------
Crossposted-To: comp.os.linux.setup
Subject: Re: V90 Modem Setup
From: [EMAIL PROTECTED] (Rob Clark)
Date: Mon, 19 Apr 1999 17:53:15 GMT
In article <[EMAIL PROTECTED]>,
Ray A. Lopez <[EMAIL PROTECTED]> wrote:
>I am having some problems getting linux to recognize a Creative PCI V90
>56k modem on Redhat 5.2. Mainly I can't get the system to recognize it
>on any com port. I have tried setting it ttyS0, ttyS1, ttyS2, and ttyS3
>then dialing up my ISP through minicom, but to no use. Has anyone had
>any luck with this particular modem or can offer some advice?
Please check your model number against the list at:
http://www.o2.net/~gromitkc/winmodem.html
in the "GX5 Digicom Systems" section. I believe your modem is probably
one of the many varieties of software modems that only work with the
provided Windows software.
Rob Clark, [EMAIL PROTECTED]
------------------------------
From: "Pat Crean" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking,comp.os.linux.portable
Subject: Re: HDD Spindown - For a Year!
Date: Mon, 19 Apr 1999 16:05:38 -0400
1. Yes
2. Kind of silly --- you wouldn't want to virtualize RAM using RAM, unless
you were a real masochist :-) Just make sure you have sufficient physical
RAM for your apps.
3. /proc is a virtual file system as it is --- it doesn't depend on the disk
4. APM
Having agreed that it will work, I have to wonder if you really would rather
use something designed for embedded use rather than linux --- I really like
the idea that I CAN build a linux router, for example, but would much rather
just plug in the cisco and forget it.....
Pat
David Peavey <[EMAIL PROTECTED]> wrote in message
news:7fg0pb$[EMAIL PROTECTED]...
> I have an application whereby I would like to use a Linux machine as a
> network gateway. This particular function requires a very high Mean time
> between failures (MTBF) - I.E. 10 years without failure. I would like to
> set it up to powered up, with the necessary things loaded, and then left
..
> possibly forever. I would like to be able to run the thing for upwards of
a
> YEAR or so without needing the HDD. Basically, the only time that the HDD
> would be required is for boot up when power returns after a power failure.
> I would turn off all CRON functions that access the HDD. Any error or
event
> logging could be buffered locally (for example in a ram drive) and then
sent
> to a remote Monitor and Control system periodically (Say once per hour or
> once per day). As far as I can tell, I don't believe the software apps
need
> the HDD once they're loaded.
>
> My questions are:
> 1) Can Linux run without the primary HDD spinning? (I would imagine so
> since laptops can run Linux - but for how long?)
> 2) If so, what are the implications of the swap file (could I replace it
> with a ram disk?), and
> 3) how could the the proc file system be handled (another ram disk?)
> 4) Is there a s/w application (or LINUX configuration) that spins down
the
> HDD on command or after a timeout?
>
> Any discussion on this would be greatly appreciated.
>
>
>
------------------------------
Date: Mon, 19 Apr 1999 23:53:50 -1000
From: "Scott M. Cooley" <[EMAIL PROTECTED]>
Subject: Anyone use a Yamaha CDR-400T?
Hi there
I am looking at getting a second-hand Yamaha CDR-400T 4x CD burner to
replace my 2x. Does anyone use this drive under linux or have any
experience with it? I know it's supported by cdrecord / cdwrite /
xcdroast and the like, but I wanted to get firsthand info and see if
anyone's had any major trouble with the drive under linux.
Any info is appreciated. i know linux can be picky about hardware and i
want to do my research first.
thanks in advance,
scott
--
Scott M. Cooley UIN : 512574
Cybertech Systems PGP Key :
Honolulu Hawaii finger [EMAIL PROTECTED]
[EMAIL PROTECTED] http://www.cts-hawaii.com
------------------------------
From: Rick <[EMAIL PROTECTED]>
Subject: MODEM Question
Date: Tue, 20 Apr 1999 19:29:34 GMT
Is it possible to setup a PNP modem in Linux Red Hat 5.0
I have a AOPEN FM56P PNP modem,
if not I will have to go back to my USR modem.
Lemme know
Thanks
------------------------------
From: Crossbones <[EMAIL PROTECTED]>
Subject: Re: Matrox G100 w/4mb memory
Date: Tue, 20 Apr 1999 19:31:47 GMT
Telia Test wrote:
> I can't configure this card to work properly under X, all help will be much
> appreciated. I run RH5.2 with no updates/upgrades
Update X.. You should be able to get it working then.
------------------------------
From: [EMAIL PROTECTED]
Subject: seagate tape drive support
Date: Mon, 19 Apr 1999 20:11:35 GMT
Does anyone know if Linux supports the Seagate STT20000A IDE tape drive?
Gateway is sending those out by default. Thanks for any help.
Jon Sellers
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "Walter Harms" <[EMAIL PROTECTED]>
Subject: Who uses scsi from Umax astra 1220 S ?
Date: 20 Apr 1999 16:16:19 GMT
I am interessted in the Umax astra 1220S. because i have no
SCSI (and no intention to buy a new card), how good does the
supplied card work ? (occacional scans)
walter
--
=====
"Let's just say that on *this* ship--or probably any other--
you don't want to wear a red shirt on landing-party duty."
=====
------------------------------
From: "Walter Harms" <[EMAIL PROTECTED]>
Subject: Re: Adaptec 2940UW SCSI with SCAM?
Date: 20 Apr 1999 16:18:40 GMT
[EMAIL PROTECTED] (Richard Preston) writes:
>My brother is using the Adaptec 2940UW SCSI controller with SCAM (whatever that
>is). It didn't work with Red Hat 5.1 and I was wondering if anyone knew if it
>works with Red Hat 5.2 or S.u.S.E. 6.0 or any other Linux distribution.
>Thanks,
>Richard
use the aix7xxx driver, i have no problems with it.
walter
--
=====
"Let's just say that on *this* ship--or probably any other--
you don't want to wear a red shirt on landing-party duty."
=====
------------------------------
From: [EMAIL PROTECTED] (Rainer Strathmann)
Crossposted-To: comp.os.linux.setup,ger.pc.linux
Subject: Re: Linux mit ATI Fury 128Range ?????????
Date: Mon, 19 Apr 1999 22:24:58 +0200
Hi Roland,
ich habe das selbe Problem mit der ATI Rage Magnum,
als Alternativen x-Server soll man den Accelerated-X Server installieren
aber ich weiß nicht wie?
Gruß Rainer
roland schrieb:
> Wer kann mir helfen
> Jetzt habe ich sus 6.1 endlich installiert, aber dir grafische
> Benutzeroberfläche läuft mit meiner ATI Fury 128 Range nicht.
> Was kann ich tun , welche Altenativen treiber oder Einstellungen sind
> möglich
>
> --
> E-Mail adress:
> ----------------------------------------------------------------------------
> --------------
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>
> Vist:
> ----------------------------------------------------------------------------
> --------------
> http://www.kalisalz.de
> http://www.waldhessen-online.net
------------------------------
From: "Osvaldo Pinali Doederlein" <[EMAIL PROTECTED]>
Crossposted-To:
comp.lang.java.advocacy,comp.os.linux.advocacy,comp.os.ms-windows.advocacy,comp.os.linux.setup
Subject: Re: Programmers are gods
Date: Tue, 20 Apr 1999 18:27:27 +0200
> Matthias Warkus wrote:
> > Enlightenment's modified CPP, called epp:
> > long fuck = 99;
> > char *dick;
This other piece of code from the author, labeled "what my code is really
like", is mostly enjoyable ;) it even manages to run.
#include <stdio.h>
#define blowjob sex
#define sex int
#define joint char
#define reefer joint
#define froob(y) sizeof(y)
#define smoke printf
#define on_the_beach main
#define suckitin(puff) {sex l;l=strlen(puff);memfrob(puff,l);}
#define bacon 0xf
#define eggs 0x3
#define frubfrub(x) scanf("%i",&x)
sex on_the_beach(sex everywhere, joint **is_good){sex *blum;joint *blimblim,
*vendu, buttox;joint ganja[]="c\012BK\\O\012\017C\012H_^^ER\012DE]\040\000";
reefer pot[]="bE]\012GKDS\012H_^^ER\012NE\012SE_\012BK\\O\012\040\000";
suckitin(pot);smoke (pot);frubfrub(pot);suckitin(ganja);blimblim=(joint *)
&buttox;blimblim+=froob(sex);vendu=blimblim;blimblim-=vendu-(joint *)
&buttox;*(vendu-froob(sex))+=(((buttox<<1)|bacon))&eggs;blum=(sex
*)blimblim;
smoke(ganja,(*blum)&eggs);}
------------------------------
Crossposted-To:
comp.lang.java.advocacy,comp.os.linux.advocacy,comp.os.ms-windows.advocacy
From: [EMAIL PROTECTED] (Bill Newman)
Subject: Re: Programmers are gods
Date: Tue, 20 Apr 1999 20:49:00 GMT
westprog ([EMAIL PROTECTED]) wrote:
: I would go along with this. Sometimes you need to do something esoteric - in
: which case, you can explain it. Most code is simple enough - and if it isn't,
: it should be. While I would never stop somebody adding comments, the effort
: involved in making code comprehensible without comments probably makes the
: code more robust and reliable as well.
It's good when you can do this, but sometimes you really can't avoid
writing code which depends on a lot of nonobvious stuff. As an example
of this, I've appended the master source file from a project I'm
currently working on -- a rewrite of CMUCL (a freeware Common Lisp
system) intended to clean up a lot of weird and flaky things in the
build process. There are a lot of comments in it, and I think that a
large proportion of them are attached to things which are
intrinsically nonobvious.
(Some of them are nonobvious even though they're sorta trivial: "Did
he compile that function because he was concerned about speed or
because the semantics of the compiled version are different somehow?")
: > *ALWAYS* code for the *other* programmer, because someday *you* may be
: > the *other* programmer...
: I sometimes find I'm the other programmer the same afternoon.
Yes..
Bill Newman
[EMAIL PROTECTED]
===============================================================================
;;;; Cross-compile.
;;;;
;;;; Running the host Lisp, set up cross-compiling packages, build the
;;;; host cross-compiler from CMUCL .lisp files, then run the
;;;; cross-compiler on CMUCL .lisp files to create target object files,
;;;; then run GENESIS to create a core file from the object files.
;;;; Also dump information from the final state of the cross-compiler
;;;; "internals.h" so that the run-time environment code (which is
;;;; written in C and assembler) will be in agreement with the low-level
;;;; Lisp code (e.g. the backend of the compiler and the guts of the
;;;; symbol table processor).
(in-package "COMMON-LISP-USER")
;;; If we attempt to use predefined values from anything other than COMMON-LISP
;;; symbols, we're doing something wrong, so we might as well hide (UNUSE)
;;; nonstandard packages that implementors of the host Common Lisp might have
;;; USEd for us.
(unuse-package (remove (find-package "COMMON-LISP")
(package-use-list "COMMON-LISP-USER"))
"COMMON-LISP-USER")
;;;; some tools
;;; miscellaneous utilities
(load "read-from-file.lisp")
(load "rename-package-carefully.lisp")
(load "maybe-compile-file.lisp")
;;; Try to minimize/conceal any non-standardness of the host Common Lisp. (This
;;; includes hiding any preexisting CMUCL package structure in the case that
;;; the host Common Lisp happens to be CMUCL.)
(load "ansify.lisp")
;;; Once we're done ANSIfying the COMMON-LISP package, it's probably a mistake
;;; if we change it (beyond changing the values of special variables such
;;; as *** and +, anyway). Set up machinery to warn us when/if we change it.
(load "snapshot.lisp")
(mapc #'compile '(take-snapshot snapshot-diff)) ; else *sooo* *slowww*..
(defvar *cl-snapshot* (take-snapshot :common-lisp))
;;;; special read-macros for cross-compiling
;;; When cross-compiling, the *FEATURES* set for the target Lisp is not in
;;; general the same as the *FEATURES* set for the host Lisp. In order to
;;; distinguish between them, we use *TARGET-FEATURES* instead of *FEATURES*.
;;;
;;; The #T+ and #T- macros test target features in the same way that #+ and #-
;;; test host features. (While cross-compiling, there's a distinction; when
;;; natively compiling, #T+ and #T- are synonymous with #+ and #-.)
(load "sharp-t.lisp")
(defvar *target-features*
(cons :cross
(read-from-file "target-features.lisp-expr")))
(setf *sharp-t-features-name* '*target-features*)
(load "sharp-double-quote.lisp")
;;;; master list of source files and their properties
;;; flags which can be used to describe properties of source files
(defparameter
*expected-stem-flags*
'(;; meaning: This file is not to be compiled when building the
;; cross-compiler which runs on the host ANSI Lisp.
:not-host
;; meaning: This file is not to be compiled as part of the target CMUCL.
:not-target
;; meaning: This file is to be processed with the CMUCL assembler, not
;; COMPILE-FILE. (Note that this doesn't make sense unless :NOT-HOST is
;; also set, since the CMUCL assembler doesn't exist while the
;; cross-compiler is being built in the host ANSI Lisp.)
:assem
;; meaning: The MAYBE-COMPILE-FILE keyword argument called IGNORE-FAILURE-P
;; should be true. (This is a KLUDGE: I'd like to get rid of it. For now,
;; it exists so that compilation can proceed through the legacy warnings in
;; src/compiler/x86/array.lisp, which I've never figured out but which seem
;; acceptable in classic CMUCL. Eventually, it would be great to just get
;; rid of all warnings and remove support for this flag. -- WHN 19990323)
:ignore-failure-p))
(defparameter *stems-and-flags* (read-from-file "stems-and-flags.lisp-expr"))
(defmacro for-stems-and-flags ((stem flags) &body body)
(let ((stem-and-flags (gensym "STEM-AND-FLAGS-")))
`(dolist (,stem-and-flags *stems-and-flags*)
(let ((,stem (first ,stem-and-flags))
(,flags (rest ,stem-and-flags)))
,@body))))
;;; Check for stupid typos in FLAGS list keywords.
(for-stems-and-flags (stem flags)
(declare (ignore stem))
(let ((set-difference (set-difference flags *expected-stem-flags*)))
(when set-difference
(error "found unexpected flag(s) in *STEMS-AND-FLAGS*: ~s"
set-difference))))
;;;; package bashing
;;; Create the CMUCL package structure.
(load "cmucl-packages.lisp")
;;; The running-in-the-host-Lisp Python cross-compiler defines its own versions
;;; of a number of functions which should not shadow host-Lisp functions.
;;; Instead we put them in a special package.
;;;
;;; The common theme of the functions, macros, constants, and so forth in this
;;; package is that they run in the host and affect the compilation of the
;;; target.
(defpackage "H%PYTHON"
(:use) ; (Why provide an empty clause, you ask? USEing package "CL" is
; often the (unwelcome here) default if this clause is not
; explicitly present.)
(:nicknames)
(:import-from "CL" "NIL") ; to make logic and list structure come out right
(:import-from "%KERNEL"
;; CLASS slot accessors which (unlike CLASS-NAME) don't shadow
;; symbols defined in ANSI Common Lisp.
"CLASS-LAYOUT"
"CLASS-STATE"
"CLASS-DIRECT-SUPERCLASSES"
"CLASS-SUBCLASSES"
"CLASS-PCL-CLASS")
(:export "ARRAY-RANK-LIMIT"
"ARRAY-DIMENSION-LIMIT"
"ARRAY-TOTAL-SIZE-LIMIT"
"BUILT-IN-CLASS"
"CLASS" "CLASS-NAME" "CLASS-OF"
"COMPILE-FILE" "COMPILE-FILE-PATHNAME"
"COMPILER-MACRO-FUNCTION"
"CONSTANTP"
"DEFCONSTANT" "DEFCONSTANT-GUTS"
"DEFINE-MODIFY-MACRO" "DEFINE-MODIFY-MACRO-GUTS"
"DEFINE-SETF-EXPANDER" "DEFINE-SETF-EXPANDER-GUTS"
"DEFMACRO" "DEFMACRO-GUTS"
"DEFSETF" "DEFSETF-GUTS"
"DEFSTRUCT" "DEFSTRUCT-GUTS"
"DEFTYPE" "DEFTYPE-GUTS"
"DOCUMENTATION"
"ETYPECASE"
"FBOUNDP"
"FDEFINITION"
"FMAKUNBOUND"
"FIND-CLASS"
"LAMBDA-LIST-KEYWORDS"
"MACRO-FUNCTION"
"MACROEXPAND" "MACROEXPAND-1" "*MACROEXPAND-HOOK*"
"MAKE-LOAD-FORM"
"PROCLAIM"
"SPECIAL-OPERATOR-P"
"STANDARD-CLASS"
"STRUCTURE-CLASS"
"SUBTYPEP"
"TYPE-OF"
"TYPECASE"
"TYPEP"
"WITH-COMPILATION-UNIT"))
;;; OBSOLETE: For a while I kept the COMMON-LISP package for the target
;;; separate from the COMMON-LISP package for the host. For now (19990220) I
;;; (WHN) am not ready to undo all the code catering to that. Instead, to
;;; accommodate that code, T%CL and %CL are made nicknames for COMMON-LISP.
(let ((cl (find-package "COMMON-LISP")))
(rename-package-carefully cl
(package-name cl)
(list* "T%CL" "%CL" (package-nicknames cl))))
;;;; miscellaneous constants/parameters
;;; prefix for source filename stems when cross-compiling
(defparameter *src-prefix* "src/")
;;; (We don't bother to specify the source suffix here because ".lisp" is such
;;; a good default value that we never have to specify it explicitly.)
;;; prefixes for filename stems when cross-compiling. These are quite arbitrary
;;; (although of course they shouldn't collide with anything we don't want to
;;; write over). In particular, they can be either relative path names (e.g.
;;; "host-objects/" or absolute pathnames (e.g. "/tmp/cmucl-xc-host-objects/").
;;;
;;; The cross-compilation process will force the creation of these directories
;;; by executing LISP:ENSURE-DIRECTORIES-EXIST (on the host Common Lisp).
(defparameter *host-obj-prefix* "host-obj/")
(defparameter *target-obj-prefix* "target-obj/")
;;; suffixes for filename stems when cross-compiling. Everything should work
;;; fine for any arbitrary string values here. With more work maybe we
;;; could cause these automatically to become the traditional extensions for
;;; whatever host and target architectures (e.g. ".x86f" or ".axpf") we're
;;; currently doing. That would make it easier for a human looking at the
;;; temporary files to figure out what they're for, but it's not necessary for
;;; the compilation process to work, so we haven't bothered.
(defconstant *host-obj-suffix* ".host-obj")
(defconstant *target-obj-suffix* ".target-obj")
;;;; Build a version of Python running in the host Lisp, to be used
;;;; only in cross-compilation.
(defun host-maybe-cload (stem &key ignore-failure-p)
;; When building the cross-compiler, package %PYTHON refers to special
;; not-in-package-CL versions of CL symbols, e.g. COMPILE-FILE and TYPEP.
(with-nickname ("H%PYTHON" "%PYTHON")
(warn-when-cl-snapshot-diff *cl-snapshot*)
(let (;; While building cross-compiler, we read code with :XC-HOST set.
(old-features (prog1 *features* (push :xc-host *features*))))
(unwind-protect
(load (maybe-compile-file stem
:src-prefix *src-prefix*
:obj-prefix *host-obj-prefix*
:obj-suffix *host-obj-suffix*
:compile-file #'compile-file
:ignore-failure-p ignore-failure-p))
(if (and (eq (first *features*) :xc-host)
(equalp (rest *features*) old-features))
(pop *features*)
;; We probably don't want to be changing features of the host Common
;; Lisp as we build modules of the cross-compiler..
(error "*FEATURES* was changed by compilation or loading.")))
(warn-when-cl-snapshot-diff *cl-snapshot*)))
(values))
(for-stems-and-flags (stem flags)
(unless (find :not-host flags)
(host-maybe-cload
stem
:ignore-failure-p (find :ignore-failure-p flags))))
;;;; Use the version of Python now running in the host Lisp to build object
;;;; modules which describe the target CMUCL.
(defparameter *target-object-files* nil)
(defun target-maybe-compile (stem
&key
(compile-file #'h%python:compile-file)
(ignore-failure-p nil))
(let (;; While compiling target files, we read code with :XC-TARGET set.
(old-features (prog1 *target-features*
(push :xc-target *target-features*)))
;; Life is simpler for GENESIS if it needn't worry about
;; byte-compiled code.
(%ext:*byte-compile-top-level* nil))
(unwind-protect
;; When compiling target files, %PYTHON refers to CL.
(with-nickname ("H%PYTHON" "%PYTHON")
(format t
"~&calling MAYBE-COMPILE-FILE for target file ~s~%"
stem)
(maybe-compile-file stem :src-prefix *src-prefix*
:obj-prefix *target-obj-prefix*
:obj-suffix *target-obj-suffix*
:ignore-failure-p ignore-failure-p
:compile-file compile-file))
(if (and (eq (first *target-features*) :xc-target)
(equal (rest *target-features*) old-features))
(pop *target-features*)
;; The code could be rewritten to handle this case, but the current
;; design vision is that all features of the bootstrap Lisp are set
;; at the outset.
(error "*TARGET-FEATURES* was changed by compilation."))))
(values))
;;; When cross-compiling, EVAL-WHEN :COMPILE-TOPLEVEL code is executed in the
;;; host Common Lisp, not the target. A certain amount of dancing around is
;;; required in order for this to work more or less correctly. (Fortunately,
;;; more or less correctly is good enough -- it only needs to work on the
;;; EVAL-WHEN expressions found in the CMUCL sources themselves, and we can
;;; exercise self-control to keep them from including anything which too
;;; strongly resembles a language lawyer's test case.)
;;;
;;; In order to make the dancing happen, we need to make a distinction between
;;; %PYTHON and COMMON-LISP when we're executing a form at compile time (i.e.
;;; within EVAL-WHEN :COMPILE-TOPLEVEL) but we need to treat %PYTHON as
;;; synonymous with COMMON-LISP otherwise. This can't be done by making %PYTHON
;;; a nickname of COMMON-LISP, because the reader processes things before
;;; EVAL-WHEN, so by the time EVAL-WHEN :COMPILE-TOPLEVEL saw a form, the
;;; distinction it needs would be lost. Instead, we read forms preserving this
;;; distinction (treating %PYTHON as a separate package), and only when we're
;;; about to process them (for anything other than EVAL-WHEN :COMPILE-TOPLEVEL)
;;; we call CROSS-MUNGE-TOP-LEVEL-FORM on them to obliterate the distinction.
;;;
;;; This implementation doesn't try to deal with circular structure.
(defun cross-munge-form (form)
(let ((python (find-package "%PYTHON"))
(cl (find-package "COMMON-LISP"))
(;; We don't try to handle circular program structure, but we do
;; detect it and complain about it.
inside? (make-hash-table)))
(labels ((rcr (form)
(cond ((symbolp form)
(if (eq (symbol-package form) python)
(values (intern (symbol-name form) cl))
form))
((or (numberp form)
(characterp form)
(stringp form))
form)
(t
;; If we reach here, FORM is something with internal
;; structure which could include symbols in the PYTHON
;; package.
(when (gethash form inside?)
(let ((*print-circle* t))
(error "circular structure in ~s" form)))
(setf (gethash form inside?) t)
(prog1
(etypecase form
(cons (cons (rcr (car form))
(rcr (cdr form))))
(vector (map 'vector #'rcr form))
;; Note: STRUCTURE-OBJECTs could be handled here
;; too, as long as we know enough about them to
;; implement something like %INSTANCE-LENGTH and
;; %INSTANCE-LENGTH. But maybe we won't have to..
;; -- WHN 19990406
)
(setf (gethash form inside?) nil))))))
(rcr form))))
(compile 'cross-munge-form) ; else might be slow..
(for-stems-and-flags (stem flags)
(unless (find :not-target flags)
(push (target-maybe-compile
stem
:compile-file (if (find :assem flags)
#'%c::assemble-file
#'h%python:compile-file)
:ignore-failure-p (find :ignore-failure-p flags))
*target-object-files*)
(warn-when-cl-snapshot-diff *cl-snapshot*)))
;;;; Fiat Lisp.
(let ((core-name "bootstrap.core"))
(genesis *target-object-files* :core-name core-name)
(format t
"Voila! The base Lisp core was created in ~s. It doesn't have CLOS~%~
yet, but it should have enough functionality to build CLOS by~%~
loading PCL-derived code.~%"
core-name))
------------------------------
From: Alpine <[EMAIL PROTECTED]>
Subject: Re: Sound Blaster Live
Date: Mon, 19 Apr 1999 16:45:01 -0400
i have been checking the creative sight daily
and the only news is that they are planing on building a driver
but a beta will be 2-3 months away at the very earliest
and the same story from 4front technologies
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.hardware) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Hardware Digest
******************************
