Free vs Commercial Lisp
David Steuber The Interloper
standard, why would commercial lisp systems have any great advantage?
In the wayward topic, "Re: help! absolute beginner," arguments about
GPL, BSD, and Artistic Licensing have emerged. Perhaps GPL really is
a public virus. I don't care to address the licensing issue so much
as the technical issue.
The CPAN is a clear case of packages for Perl being made available for
general use. It is successful because Perl is a popular language that
was so good at text munging that people have decided to push its
envelope to try and make a general purpose programming language out of
it. Most important though, is the fact that Perl has a de facto
standard. You can be fairly confident that a CPAN package can be
added to your Perl source tree.
Well, ANSI CL is a real standard. Ok, some items are a little loose,
ie, implementation dependant. CMUCL uses PCL for CLOS. There is this
thing called MOP that I haven't had the time to look into yet. Still,
there is a standard.
The above mentioned topic had an article proposing the improvement of
CMU's AI repository for CL. I think that is a good idea. If
contributors stick with CL and avoid implementation dependencies, then
it is fairly practical to create the equivalent of CPAN or sunsite for
lisp.
Such an archive would be a great place for various packages for string
processing, graphics, math, physics, etc.
So if such an archive existed, with or without mirrors, why would a
commercial lisp system be better than a free one? The only lisp
systems that would remain in real use would be the ones that conformed
to the ANSI CL spec closely enough to take advantage of the packages
in the archive.
The major area of competition would become the development
environment.
--
David Steuber (ver 1.31.3a)
http://www.david-steuber.com
To reply by e-mail, replace trashcan with david.
May the source be with you...
Erik Naggum
| As long as the free lisp implementations hold to the ANSI Common Lisp
| standard, why would commercial lisp systems have any great advantage?
for the same reason literature has an advantage over dictionaries.
reading through your terribly confused message, I must conclude that
you're like a man born blind who's insisting that sight is greatly
over-rated, never having experienced it yet obviously able to survive
without it.
| The only lisp systems that would remain in real use would be the ones
| that conformed to the ANSI CL spec closely enough to take advantage of
| the packages in the archive.
that's _obviously_ not what's going to happen. here's why: if some
package doesn't work with _your_ favorite Common Lisp implementation,
will you fix your Common Lisp implementation (a generally enormous task)
or will you fix the package and feel much better that you could spend
half an hour changing a perfectly working program so it would work with
your non-conforming implementation? repeat for one million users of
crappy, yet free, implementations of Common Lisp. result: it isn't
likely to work with _anything_.
Perl has the advantage that it has exactly one implementation. that's
what you test it against. Common Lisp has a specification. people will
test against their implementations to decide what to do. you do not know
how to read the standard yourself, so how you can even begin to assume
that others will consult the standard first, and stop doing what they
wanted to do and instead go off and fix the Common Lisp system is quite
literally beyond me.
| The major area of competition would become the development environment.
you know not at all of what you speak.
#:Erik
--
Nie wieder KrF! Nie wieder KrF! Nie wieder KrF! Nie wieder KrF!
William Paul Vrotney
In article <3681615a...@news.newsguy.com> tras...@david-steuber.com
(David Steuber "The Interloper") writes:
>
> As long as the free lisp implementations hold to the ANSI Common Lisp
> standard, why would commercial lisp systems have any great advantage?
>
I have used most all commercial Common Lisp systems and most all free Common
Lisp systems on many projects. And I can tell you confidently that if I had
to do a project that can either fund Allegro Common Lisp or use a free
Common Lisp and pay me the Allegro cost, I would recommend Allegro. I have
no connections with Franz.
I can not say enough about free Common Lisps, most of them are amazing
achievements by their implementors. It is just that Common Lisp is complex
enough and has enough extended implications that it is pretty difficult to
compete well with a commercial Common Lisp that pays attention to these
details. Here are a few that I can think of
1. Good compiler, fast or compact code generation
2. Good debuggers and other code visualization tools
3. Good OS interfaces: file systems, multiprocessing, TCP/IP support, etc.
4. Good foreign function support and foreign data translation
5. Good Garbage Collection algorithms and control options
6. Good tree shaking and delivery systems options
7. More complete compliance to Common Lisp specification (surprise)
8. Fast interpreter and Lisp listener extensions
9. Good documentation for extended facilities
10. Moderately good GUI support
--
William P. Vrotney - vro...@netcom.com
rusty craine
William Paul Vrotney wrote:
> In article <3681615a...@news.newsguy.com> tras...@david-steuber.com
> (David Steuber "The Interloper") writes:
>
> >
> > As long as the free lisp implementations hold to the ANSI Common Lisp
> > standard, why would commercial lisp systems have any great advantage?
> >
>
> I have used most all commercial Common Lisp systems and most all free Common
> Lisp systems on many projects. And I can tell you confidently that if I had
> to do a project that can either fund Allegro Common Lisp or use a free
> Common Lisp and pay me the Allegro cost, I would recommend Allegro. I have
> no connections with Franz.
>
If working in DOS 16 or 32 bit (I would not suspect many are), I can say that
muLisp will run the socks off of any other lisp for that platform. I have not
been a advocate for muLisp in this group because I lacked experience with lisp
on other platforms thus had little to compare muLisp to. The biggest problems
with muLisp there is no unix version.
muLisp vendor ships the most used functions of common so you can run all but
the most esoteric of the examples in this NG. Some of the older version of
muLisp were shipped with a large lib of interlisp function. The current release
is shipped with farily complete clos, flavors, and dos windowing libs..
The _great_ thing about muLisp and the DOS platfrom is that muLisp takes full
advantage of very low level DOS programming (guess that's bad too, not
portable). muLisp for 16 and 32 bit DOS is shipped for 150 dollars. If your
stuck in DOS, it's the best deal you'll ever get.
rusty
Paolo Amoroso
"The Interloper") wrote:
> ie, implementation dependant. CMUCL uses PCL for CLOS. There is this
> thing called MOP that I haven't had the time to look into yet. Still,
You may check:
"Open Implementations and Metaobject Protocols"
Gregor Kiczales, Andreas Paepcke
(Xerox PARC - Open Implementation Group)
http://www.parc.xerox.com/spl/groups/eca/pubs/papers/Kiczales-TUT95/for-web.pdf
Paolo
--
Paolo Amoroso <amo...@mclink.it>
David Steuber
> "Open Implementations and Metaobject Protocols"
> Gregor Kiczales, Andreas Paepcke
> (Xerox PARC - Open Implementation Group)
> http://www.parc.xerox.com/spl/groups/eca/pubs/papers/Kiczales-TUT95/for-web.pdf
Thanks for the link.
David Steuber
> In article <3681615a...@news.newsguy.com> tras...@david-steuber.com
> (David Steuber "The Interloper") writes:
>
> >
> > As long as the free lisp implementations hold to the ANSI Common Lisp
> > standard, why would commercial lisp systems have any great advantage?
> >
>
> details. Here are a few that I can think of
>
> 1. Good compiler, fast or compact code generation
> 2. Good debuggers and other code visualization tools
> 3. Good OS interfaces: file systems, multiprocessing, TCP/IP support, etc.
> 4. Good foreign function support and foreign data translation
> 5. Good Garbage Collection algorithms and control options
> 6. Good tree shaking and delivery systems options
> 7. More complete compliance to Common Lisp specification (surprise)
> 8. Fast interpreter and Lisp listener extensions
> 9. Good documentation for extended facilities
> 10. Moderately good GUI support
These are all good reasons. Obviously I need to open my mind more.
I can just go to www.franz.com and download a free for trial use
version of ACL if I remember previous postings. I think I will do
that this weekend so I have a proper basis of comparison with CMUCL.
In the open source vain, I am considering distributing my application,
if it ever leaves the vapor stage, in source only form. How can I be
sure that I don't indavertantly use a propriatary extension? I
suppose the simple answere is to compile it in both ACL and CMUCL.
Are extension packages normaly marked as such? I'm asking really
stupid questions, aren't I?
David Steuber
> When it comes time to actually run it, obviously compiling and testing
> it with each implementations is a neccesity. Some parts of the spec
> are left to the implementations, and some implementations do not
> completely follow the spec.
As I type this, I am downloading ACL 4.3 for Linux. There is a 5.0,
but it is beta. I have a lib5 system, so I am going with the production
version. Maybe I will get the 5.0 when it isn't beta anymore.
It seems kind of odd not wanting the beta since I am also using CMUCL.
Craig Brozefsky
> In the open source vain, I am considering distributing my application,
> if it ever leaves the vapor stage, in source only form. How can I be
> sure that I don't indavertantly use a propriatary extension? I
> suppose the simple answere is to compile it in both ACL and CMUCL.
> Are extension packages normaly marked as such? I'm asking really
> stupid questions, aren't I?
Read the spec for CL. The HyperSpec is I believe the best reference
material that you can get for free. A search for "CL HyperSpec" at
your freindly neighborhood serch engine shound turn it up.
My understanding is that the COMMON-LISP package should contain all
symbols within the specification.
Erik Naggum
| I can just go to www.franz.com and download a free for trial use version
| of ACL if I remember previous postings. I think I will do that this
| weekend so I have a proper basis of comparison with CMUCL.
this is the right way to go. do remember to get the patches, too. let
me know if you have any problems.
a slight warning might be necessary: it takes time to appreciate the
Allegro CL system. I thought I could upgrade from CMUCL to ACL over a
weekend, but although my code "worked", it was quite obvious I was
missing something very important. the Emacs interface is very good, but
it takes some getting used to. I suggest spending a fair amount of time
with the manuals, which only come in on-line form. print them out if you
can -- I find reading manuals on the screen to be excessively exhausting.
| In the open source vain, I am considering distributing my application,
| if it ever leaves the vapor stage, in source only form. How can I be
| sure that I don't indavertantly use a propriatary extension? I suppose
| the simple answere is to compile it in both ACL and CMUCL. Are extension
| packages normaly marked as such? I'm asking really stupid questions,
| aren't I?
no, not stupid, but basic. stupid is when you ask "advanced" questions
without knowing the basics. (don't go there.)
ANSI Common Lisp specifies that all symbols in the COMMON-LISP package
must be the ones that the standard specifies. all your symbols must be
in a separate package. if all the symbols in your code is either in your
package or in the COMMON-LISP package, you don't use any extensions at
the function or macro level, at least. some standard functions do take
additional keyword arguments, however, and others have extensions of
their own. these are few and far between, but you will find them well
documented in the Allegro CL documentation.
thus, if you simply read in all your source code with READ, you can check
the package of every symbol. this is a fairly simple recursive function,
which I leave as an exercise, but the stronger route is to remove any
other packages from the package use list (obtained by PACKAGE-USE-LIST)
of the package you're using, or, equivalently, specify to use only
COMMON-LISP.
(unuse-package "EXCL" "CL-USER")
removes the default extension package from CL-USER's use list, and then
you can't use any of the symbols in EXCL without a package prefix.
you'll notice those when the Emacs interface inserts them in expanding
your symbols.
(defpackage "STEUBER" (:use "COMMON-LISP"))
creates a new package that uses only the COMMON-LISP package. you would
include an IN-PACKAGE form at the top of your files to use it, or use the
:package command to the Allegro CL top-level. (if you create a new file,
it defaults to use the CL-USER package. insert the IN-PACKAGE form and
write M-x normal-mode to change that on a case by case basis, or set the
Emacs variable FI:DEFAULT-PACKAGE to the name of your default package.)
Christopher R. Barry
[...]
> print them out if you can -- I find reading manuals on the
> screen to be excessively exhausting.
[...]
I found reading anything on a computer monitor for more than 20
minutes to be exhausting until I invested some serious cash in a 21"
Viewsonic P815. This baby can do 1800x1440, but I run it at 1600x1200
with a 90Hz refresh rate. Never, ever use black text on white
backgrounds. I don't know why so many applications have this scheme as
default, it just kills your eyes. I really like using the X resource
color `gray80' for backgrounds.
You can get the best price on it or anything else at:
http://www.pricewatch.com
Christopher
Rainer Joswig
R. Barry) wrote:
> with a 90Hz refresh rate. Never, ever use black text on white
> backgrounds. I don't know why so many applications have this scheme as
> default, it just kills your eyes
Funny, I just hate the spreading of gray backgrounds. My
Netscape/Emacs/etc. always gets a white background.
- You get more contrast.
- If screen content is darker, one usually increases the screen brightness
-> more radiation (or for a laptop, draws more power for the light).
- Also it is important to have the same black/white contrast as
paper, when you are often looking at paper and the screen.
Switching between different gray/color values is stress.
(That's the reason why German keyboards had to be black characters
on white key - unfortunately Apple thought the opposite is
more stylish).
I'm also not convinced that at todays screen DPIs font antialiasing
for small fonts (say upto 14 point) is a good thing.
Nowadays I use the excellent LCD screen of my PowerBook most of the time.
Andi Kleen
Erik Naggum <er...@naggum.no> writes:
> * David Steuber <tras...@david-steuber.com>
> | I can just go to www.franz.com and download a free for trial use version
> | of ACL if I remember previous postings. I think I will do that this
> | weekend so I have a proper basis of comparison with CMUCL.
> this is the right way to go. do remember to get the patches, too. let
> me know if you have any problems.
Installing the latest patch set from franz.com on ACL/Linux 5.0 fails here.
I would be interested in knowing if anyone produced a working image with
the franz.com updates, and if yes with what combination of patches.
[All updates as from 12/20/98 from ftp.franz.com]
[Using the patched libacl503.so from ftp.franz.com, with the release .so version
it fails with the same error
% ls -l libacl503.so
-rwxr-xr-x 1 andi andi 470093 Sep 24 02:24 libacl503.so
(contains the code/* updates from franz.com)
% ls -l code
total 2129
-rw-r--r-- 1 andi andi 3670 Dec 17 19:47 DESCRIPTIONS
-rw-r--r-- 1 root root 40646 Aug 29 18:23 aclwffi.fasl
-rw-r--r-- 1 root root 168273 Aug 29 18:23 aclwin.fasl
-rw-r--r-- 1 andi andi 24742 Dec 5 01:30 build.fasl
-rw-r--r-- 1 andi andi 1545811 Oct 16 23:56 clx.fasl
-rwxr-xr-x 1 root root 2405 Aug 29 20:10 excldep.so
-rw-r--r-- 1 root root 6163 Aug 29 18:20 extloop.fasl
-rw-r--r-- 1 root root 53295 Aug 29 18:23 for.fasl
-rw-r--r-- 1 andi andi 4238 Nov 19 20:34 genutils.fasl
-rw-r--r-- 1 andi andi 43736 Dec 9 19:39 hash.fasl
-rw-r--r-- 1 andi andi 73795 Dec 17 02:39 inspect.fasl
-rw-r--r-- 1 root root 53209 Aug 29 18:23 ipc.fasl
-rw-r--r-- 1 andi andi 16686 Oct 16 20:13 nocompiler.fasl
-rw-r--r-- 1 root root 12963 Aug 29 18:20 oldloop.fasl
-rw-r--r-- 1 andi andi 84835 Nov 5 19:46 scm.fasl
-rwxr-xr-x 1 root root 3327 Aug 29 20:10 socket.so
-rw-r--r-- 1 root root 13821 Aug 29 18:19 sundebug.fasl
% ls update
DESCRIPTIONS p0a003.001 p0a005.002 p0a008.001 p0b003.001
empty p0a003.002 p0a006.001 p0a009.001
p0a001.001 p0a004.001 p0a006.002 p0a010.001
p0a002.001 p0a005.001 p0a007.001 p0b002.001
% ./update.sh
Loading /u2/acl5/libacl503.so.
Mapping lisp-orig.dxl...done.
Mapping acl503.epll.
Allegro CL Trial Edition 5.0 [Linux/X86] (8/29/98 10:57)
Copyright (C) 1985-1998, Franz Inc., Berkeley, CA, USA. All Rights Reserved.
;; Optimization settings: safety 1, space 1, speed 1, debug 2.
;; For a complete description of all compiler switches given the current
;; optimization settings evaluate (EXPLAIN-COMPILER-SETTINGS).
USER(1): ; Autoloading for BUILD-LISP-IMAGE:
; Fast loading /u2/acl5/code/build.fasl
;;; Installing build patch, version 5
Loading /u2/acl5/libacl503.so.
Mapping acl503.epll.
Initial generation spread = 1
Allocated 10492920 bytes for old space
Allocated 5242880 bytes for new space
;;;;;;;;;;;;;;;;;; fasl /u2/acl5/code/hash.fasl
;;; Installing hash patch, version 4
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Autoloading for package "COMP":
; Fast loading from bundle code/compiler-s.fasl.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Autoloading for MATCH-REGEXP:
; Fast loading from bundle code/regexp.fasl.
Loaded patch file /u2/acl5/update/p0b002.001.
Loaded patch file /u2/acl5/update/p0b003.001.
;;;;;;;;;;;
area address(bytes) cons symbols other bytes
8 bytes each 24 bytes each
(free:used) (free:used) (free:used)
Top #x20f04000
New #x20c84000(2621440) 996:1042 254:0 2501952:42408
New #x20a04000(2621440) ----- ----- -----
Old #x20000d48(10498744) 694:38028 47:10801 9331464:588544
Root pages: 5
Lisp heap limit: 67108864
Allegro CL Trial Edition 5.0 [Linux/X86] (12/26/98 13:36)
Copyright (C) 1985-1998, Franz Inc., Berkeley, CA, USA. All Rights Reserved.
;; Optimization settings: safety 1, space 1, speed 1, debug 2.
;; For a complete description of all compiler switches given the current
;; optimization settings evaluate (EXPLAIN-COMPILER-SETTINGS).
USER(1): USER(1): T
USER(2): EXCL::EXIT-ON-ERROR-HOOK
USER(3): :CASE-INSENSITIVE-UPPER
USER(4): NIL
USER(5): NIL
USER(6): T
USER(7): T
USER(8): NIL
USER(9): NIL
USER(10): T
USER(11): ; Loading /u2/acl5/develenv.cl
; Fast loading from bundle code/list2.fasl.
; Fast loading from bundle code/seq2.fasl.
; Fast loading from bundle code/streama.fasl.
; Fast loading from bundle code/srecord.fasl.
; Fast loading from bundle code/tpl-debug.fasl.
; Autoloading for package "DEBUGGER":
; Fast loading from bundle code/debug.fasl.
; Fast loading from bundle code/tpl-proc.fasl.
; Autoloading for package "MULTIPROCESSING":
; Fast loading from bundle code/process-s.fasl.
; Fast loading from bundle code/defsys.fasl.
; Autoloading for package "DEFSYS":
; Fast loading from bundle code/defsys-s.fasl.
; Fast loading from bundle code/foreign.fasl.
; Autoloading for package "FOREIGN-FUNCTIONS":
; Fast loading from bundle code/foreign-s.fasl.
; Fast loading from bundle code/defftype.fasl.
; Fast loading from bundle code/compftype.fasl.
; Fast loading from bundle code/process.fasl.
; Fast loading from bundle code/mdproc.fasl.
; Fast loading from bundle code/sigio.fasl.
; Fast loading from bundle code/eli.fasl.
; Fast loading from bundle code/lep.fasl.
; Autoloading for package "CROSS-REFERENCE":
; Fast loading from bundle code/xref-s.fasl.
; Fast loading from bundle code/lze.fasl.
; Autoloading for package "ACL-SOCKET":
; Fast loading from bundle code/sock-s.fasl.
; Fast loading from bundle code/emacs.fasl.
; Fast loading /u2/acl5/code/scm.fasl
;;; Installing scm patch, version 1
; Fast loading from bundle code/xref.fasl.
; Fast loading from bundle code/walker.fasl.
; Fast loading from bundle code/trace.fasl.
Error (from DEBUG): Can't locate the module "PROF"
Continuable error: ask for a new filename
; Auto-exit
; Exiting Lisp
done.
Error (from ERROR): image creation failed
Evaluation stack:
(EXCL::INTERNAL-INVOKE-DEBUGGER "Error" #<CL:SIMPLE-ERROR @ #x204d632a>
CL:T)
(CL:ERROR CL:SIMPLE-ERROR :FORMAT-CONTROL #1="image creation failed"
:FORMAT-ARGUMENTS CL:NIL)
(EXCL::.ERROR #1#)
->(EXCL:BUILD-LISP-IMAGE #2="lisp.dxl")
[... EXCL::%EVAL ]
(CL:EVAL (EXCL:BUILD-LISP-IMAGE #2#))
(TPL::READ-EVAL-PRINT-ONE-COMMAND CL:NIL CL:NIL)
(EXCL::READ-EVAL-PRINT-LOOP :LEVEL 0)
(TPL::TOP-LEVEL-READ-EVAL-PRINT-LOOP1)
(TPL:TOP-LEVEL-READ-EVAL-PRINT-LOOP)
(SYS::..RUNTIME-OPERATION #3=#<Function TOP-LEVEL-READ-EVAL-PRINT-LOOP>
CL:NIL)
(TPL:START-INTERACTIVE-TOP-LEVEL
#<EXCL:BIDIRECTIONAL-TERMINAL-STREAM [initial terminal io] fd 0/1 @
#x200062aa>
#3# CL:NIL)
(EXCL::START-LISP-EXECUTION)
(EXCL::SETUP-REQUIRED-STACK-GROUP-BINDINGS
#<Function START-LISP-EXECUTION-1>)
(EXCL::START-REBORN-LISP)
; Auto-exit
; Exiting Lisp
%
-Andi
Steve Gonedes
It seems like it can't find the profile package - it's already there,
you just have to dump the image manually.
Here's what I used, it seems to work fine. (I just save it to a file
and load it in with :ld). I also commented some stuff out in
develenv.cl, but this shouldn't matter. You may want to change some
stuff (like the pathname of the dumped image, daylight savings, etc.)
(CL:SETQ EXCL::*BATCH-MODE* CL:NIL)
(CL:SETQ EXCL::*BREAK-HOOK* #'EXCL::EXIT-ON-ERROR-HOOK)
(EXCL:SET-CASE-MODE :CASE-INSENSITIVE-UPPER)
(CL:FORCE-OUTPUT)
(CL:PROCLAIM '(CL:OPTIMIZE (CL:DEBUG 2) (CL:SPEED 1) (CL:SPACE 1)
(CL:SAFETY 1)))
(CL:SETQ EXCL:*DAYLIGHT-SAVING-TIME-OBSERVED* CL:T)
(CL:SETQ SYS::*INSTALL-SERVER-NAME* CL:NIL)
(CL:SETQ SYS::*INSTALL-GENERATE-FONTS* CL:NIL)
(CL:SETQ SYS::*DEVEL* CL:T)
(CL:LOAD "sys:develenv.cl")
(CL:SETF (EXCL:ARGUMENT-SAVING) CL:T)
(SYS:LOAD-PATCHES :PRODUCT #\a :VERSION #\0)
(CL:SETQ EXCL:*PRINT-STARTUP-MESSAGE*
'((:COMPILER-SWITCHES . CL:T) (:COMPILER-EXPLAIN . CL:T)
(:COMPILER-OPTIMIZATIONS . CL:T)
(:SOURCE-FILE-RECORDING . CL:T) (:XREF . CL:T)
(:CASE-MODE . CL:T)))
(cl:setq SYS:*SOURCE-FILE-TYPES* '("lisp" "cl" "lsp" nil))
(CL:SETQ EXCL:*READ-INIT-FILES* 'CL:T)
(CL:SETQ EXCL:*INIT-FILE-NAMES* '(".clinit.cl"))
(CL:PROGN (CL:SETQ EXCL::*STORE-DOCUMENTATION* CL:T)
(CL:SETQ EXCL:*RECORD-SOURCE-FILE-INFO* CL:T)
(CL:SETQ EXCL:*LOAD-LOCAL-NAMES-INFO* CL:T)
(CL:SETQ EXCL:*LOAD-SOURCE-FILE-INFO* CL:T)
(CL:SETQ EXCL:*RECORD-XREF-INFO* CL:T)
(CL:SETQ EXCL:*LOAD-XREF-INFO* CL:T))
(CL:WHEN (CL:PROBE-FILE "sys:custom.cl") (CL:LOAD "sys:custom.cl"))
(EXCL:DISCARD-ALL-SOURCE-FILE-INFO)
(CL:WHEN (CL:NOT (EXCL::PACKAGE-NOT-YET-LOADED :CROSS-REFERENCE))
(EXCL::FUNCALL-IN-PACKAGE :DISCARD-ALL-XREF-INFO :CROSS-REFERENCE))
(CL:SETQ EXCL::*PATCHES-PRELOADABLE* CL:NIL)
(CL:SETQ EXCL::*SOURCE-FILE-AUTOLOAD-SRECORD* CL:T)
(CL:SETQ EXCL:*LIBFASL* CL:NIL)
(CL:PROGN (EXCL:GC :TENURE) (EXCL:GC :TENURE) (EXCL:GC :TENURE)
(EXCL:GC CL:T))
(SYS:RESIZE-AREAS
:OLD 2097152
:NEW (CL:- (CL:/ 2097152 2) (CL:* 1025 50))
:GLOBAL-GC CL:T
:TENURE CL:T)
(CL:PROGN (CL:PRINC "; dumping image...") (CL:FORCE-OUTPUT))
(EXCL:DUMPLISP
:NAME #p"/home/steve/lib/bin/.core" ; *** You should probably change this
:CASE-MODE :CASE-INSENSITIVE-UPPER
:DST CL:T
:LOAD-LOCAL-NAMES-INFO CL:T
:LOAD-SOURCE-FILE-INFO CL:T
:LOAD-XREF-INFO CL:T
:RECORD-SOURCE-FILE-INFO CL:T
:RECORD-XREF-INFO CL:T
:DEBUG-ON-ERROR CL:T
:DISCARD-ARGLISTS :MEDIUM
:DISCARD-LOCAL-NAME-INFO CL:NIL
:DRIBBLE-FILE "dribble.txt"
:EXIT-AFTER-IMAGE-BUILD CL:T
:VERBOSE CL:T)
(EXCL:EXIT 0)
Rainer Joswig
<tras...@david-steuber.com> wrote:
> Craig Brozefsky <cr...@onshore.com> writes:
>
> > When it comes time to actually run it, obviously compiling and testing
> > it with each implementations is a neccesity. Some parts of the spec
> > are left to the implementations, and some implementations do not
> > completely follow the spec.
>
> As I type this, I am downloading ACL 4.3 for Linux. There is a 5.0,
> but it is beta.
Have you looked in the right directory on ftp.franz.com?
ftp> pwd
257 "/pub/linux" is current directory.
ftp> ls -l
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
total 3
drwxr-xr-x 2 483 ftp 1024 Feb 3 1998 acl43
drwxr-xr-x 2 483 ftp 1024 Sep 29 17:36 acl50
drwx------ 2 483 ftp 1024 May 22 1998 acl50beta
226 Transfer complete.
remote: -l
199 bytes received in 0.017 seconds (11.56 Kbytes/s)
ftp> cd acl50
250-Please read the file README.1ST
250- it was last modified on Tue Sep 29 10:36:32 1998 - 88 days ago
250 CWD command successful.
ftp> pwd
257 "/pub/linux/acl50" is current directory.
ftp> ls -l
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
total 22040
-rw-r--r-- 1 483 ftp 358 Sep 29 17:36 README.1ST
-r--r--r-- 1 483 ftp 11376640 Sep 9 18:33 redhat4.tar
-r--r--r-- 1 483 ftp 11100160 Sep 9 18:34 redhat5.tar
226 Transfer complete.
remote: -l
216 bytes received in 0.0065 seconds (32.52 Kbytes/s)
David Steuber
articles that are ACL specific. As of this typing, I haven't unpacked
it yet.
Although I have made some blunders with gnus, and don't have it quite
the way I want it yet, I am picking up Graham's ANSI Common Lisp
again. I have to start from the begining because all the distractions
have made me forget what I've read.
Gotta actually code in CL to get it.
Erik Naggum
| As I type this, I am downloading ACL 4.3 for Linux. There is a 5.0,
| version. Maybe I will get the 5.0 when it isn't beta anymore.
this is an extremely specious argument. first of all, you're not dealing
with Microsoft, OK? version.beta from Franz Inc is the same quality as
version.5 from most other companies. in fact, "5.0.beta" was stable
enough to run a financial news service flawlessly for several months, and
I hesitated to upgrade because that by itself would bring instability to
the system. second, it isn't in beta anymore. you can get 5.0.final,
so I really wonder what the hell you're trying to pull.
| It seems kind of odd not wanting the beta since I am also using CMUCL.
if there's a saying "burnt child shies fire" (I'm just translating from
Norwegian, which generally doesn't work), my favorite rewrite is "burnt
child smells bad".
#:Erik
--
det kommende IT-senteret på Fornebu mangler egentlig bare en flyplass
Paul Dietz
> if there's a saying "burnt child shies fire" (I'm just translating from
> Norwegian, which generally doesn't work), my favorite rewrite is "burnt
> child smells bad".
"Burnt child makes an ash of himself."
Paul
Craig Brozefsky
> this is an extremely specious argument. first of all, you're not dealing
> with Microsoft, OK? version.beta from Franz Inc is the same quality as
> version.5 from most other companies. in fact, "5.0.beta" was stable
> enough to run a financial news service flawlessly for several months, and
> I hesitated to upgrade because that by itself would bring instability to
> the system. second, it isn't in beta anymore. you can get 5.0.final,
> so I really wonder what the hell you're trying to pull.
On the franz web page http://www.franz.com/dload/offer.html they refer
to it as Allegro CL 5.0 Beta. The order/download form does not
indicate wether it is the beta or final that is available. Being that
David is not directly familiar with Franz's track record as far as
software quality goes, one cannot really fault him for treating the
beta as you would a beta from nearly anywhere else.
I do not think that David was trying to pull anything. I think that
the Franz website indicated to him that it was beta, and he came to a
reasonable conclusion from this information.
Erik Naggum
| Installing the latest patch set from franz.com on ACL/Linux 5.0 fails
| here. I would be interested in knowing if anyone produced a working
| image with the franz.com updates, and if yes with what combination of
| patches.
| Error (from DEBUG): Can't locate the module "PROF"
the Trial Edition is really an Enterprise Edition without the runtime
generator or a license to use it commercially. it has the profiler built
in, but not the sys:code;prof.fasl file needed to build a new image.
this may be a bug in the patch process, but the easy fix is to have the
prof.fasl file. I doubt that Franz Inc will want to ship that file to
Trial Edition users, so perhaps the patching procedure should be improved.
anyway, the easy short-term option is to remove the (require :prof) line
from sys:develenv.cl -- but you'll lose the profiler in your new image.
less easy is to load all the patches every time you start, which
shouldn't be that often, anyway. SYS:LOAD-PATCHES does that, but you
have to load the new .fasl files, like inspect.fasl, hash.fasl, yourself.
#:Erik
Erik Naggum
| On the franz web page http://www.franz.com/dload/offer.html they refer to
| it as Allegro CL 5.0 Beta. The order/download form does not indicate
| wether it is the beta or final that is available.
oh, man, that web page is _depressingly_ outdated.
| Being that David is not directly familiar with Franz's track record as
| far as software quality goes, one cannot really fault him for treating
| the beta as you would a beta from nearly anywhere else. I do not think
| that David was trying to pull anything. I think that the Franz website
| indicated to him that it was beta, and he came to a reasonable conclusion
| from this information.
well, I think "fear of beta" is irrational. (look, it even got us VHS.)
#:Erik
David Steuber
> * David Steuber <tras...@david-steuber.com>
> | As I type this, I am downloading ACL 4.3 for Linux. There is a 5.0,
> | but it is beta. I have a lib5 system, so I am going with the production
> | version. Maybe I will get the 5.0 when it isn't beta anymore.
>
> this is an extremely specious argument. first of all, you're not dealing
> with Microsoft, OK? version.beta from Franz Inc is the same quality as
> version.5 from most other companies. in fact, "5.0.beta" was stable
> enough to run a financial news service flawlessly for several months, and
> I hesitated to upgrade because that by itself would bring instability to
> the system. second, it isn't in beta anymore. you can get 5.0.final,
> so I really wonder what the hell you're trying to pull.
I'm not trying to 'pull' anything, Erik. I am simply going by what I
read on Franz's own site. If they are doing ACL 5.0 For Linux as
final, then their website should have been updated to reflect that.
Your fear of upgrading to the final version also makes my point for
me. Why should I have gotten the beta when all I had to do was wait a
little while and get the production release? One install is easier
than two.
> | It seems kind of odd not wanting the beta since I am also using CMUCL.
>
> if there's a saying "burnt child shies fire" (I'm just translating from
> Norwegian, which generally doesn't work), my favorite rewrite is "burnt
> child smells bad".
My comment regarding CMUCL vs Beta was supurflous. CMUCL seems to be
in a perpetual state of development because of its status as public
domain software being maintained by a small group of volunteers. I
judge CMUCL with a different set of standards than something that is
designed to get you interested in the commercial version of a
product. I don't expect CMUCL to be as polished as ACL. This is
mainly due to people on this news group pointing out to me how
superior commercial tools are compared to the free stuff. Well, I'm
holding them to it.
Erik Naggum
| Your fear of upgrading to the final version also makes my point for me.
this is bogus. that one comment has a lot of context that should not be
assumed or ignored. for reference purposes, it goes like this: I (with a
bright colleague reviewing my work) have developed a system with >99.95%
uptime in a world where seconds matter and a minute of downtime equals
lots of cash. that I held back on upgrading from ACL 4.3 for Linux to
ACL 5.0.beta and had the software running on both versions in parallel
for a month and that I did the same between ACL 5.0.beta and ACL 5.0 is
not an argument against getting the beta. rather, it's evidence that you
can run mission critical software on Franz Inc's notion of "beta". you
might find it interesting to know that I had a SPARC nearby to isolate
operating-system specific problems with Linux, too. this is stuff that
just simply _cannot_ crash.
| I don't expect CMUCL to be as polished as ACL. This is mainly due to
| people on this news group pointing out to me how superior commercial
| tools are compared to the free stuff. Well, I'm holding them to it.
good!
David Steuber
> well, I think "fear of beta" is irrational. (look, it even got us VHS.)
Don't even get me started on that. I have a huge pile of BetaMax
tapes that I can't play anymore becuase my last Beta player died.
I've heard rumours of referbs being available, but haven't had the
time to look.
Now my laser disks are being replaced by DVD. At least DVD really is
better.
David Steuber
-> * David Steuber <tras...@david-steuber.com>
-> | Your fear of upgrading to the final version also makes my point for me.
->
-> this is bogus. that one comment has a lot of context that should not be
-> assumed or ignored. for reference purposes, it goes like this: I (with a
-> bright colleague reviewing my work) have developed a system with >99.95%
-> uptime in a world where seconds matter and a minute of downtime equals
-> lots of cash. that I held back on upgrading from ACL 4.3 for Linux to
-> ACL 5.0.beta and had the software running on both versions in parallel
-> for a month and that I did the same between ACL 5.0.beta and ACL 5.0 is
-> not an argument against getting the beta. rather, it's evidence that you
-> can run mission critical software on Franz Inc's notion of "beta". you
-> might find it interesting to know that I had a SPARC nearby to isolate
-> operating-system specific problems with Linux, too. this is stuff that
-> just simply _cannot_ crash.
Well, now that you've given me some context, yes it is bogus. But you
did hesitate ;-)
-> | I don't expect CMUCL to be as polished as ACL. This is mainly due to
-> | people on this news group pointing out to me how superior commercial
-> | tools are compared to the free stuff. Well, I'm holding them to it.
->
-> good!
Still fetching ACL 5.0. Damn ISDN is slow! I wish I could afford a
T3. Or my cable provider would offer cable modem Internet access.
Can I use ISLISP/XEmacs with ACL, or do I have to use an ACL editor?
I've noticed that the mailing list uses your domain, so I am blindly
assuming you know much about it.
--
David Steuber
http://www.david-steuber.com
s/trashcan/david/ to reply by mail
"Hackers penetrate and ravage delicate, private, and publicly owned
computer systems, infecting them with viruses and stealing materials
for their own ends. These people, they're, they're terrorists."
-- Secret Service Agent Richard Gill
Erik Naggum
| Can I use ISLISP/XEmacs with ACL, or do I have to use an ACL editor?
Allegro CL basically assumes Emacs for the development environment, which
I prefer over "decidated" editors. only under Windows does Allegro CL
come with its own IDE. lots of stuff in the Emacs/Lisp interface is very
hard to obtain from ILISP, however, and I use a slightly hacked version
of the ELI package.
#:Erik
--
if people came with documentation, could men get the womanual?