From: Lars Marius Garshol
Subject: Re: string assembly in lisp?? help??
Date:
Message-ID: <wk677zykui.fsf@ifi.uio.no>
* Lars Marius Garshol
|
| I assumed the vector approach to be more effective (and made sure to
| allocate a reasonable initial-size vector to begin with). That is a
| reasonable assumption, no?
* Tim Bradshaw
|
| No, it's a bad assumption. Your approach allocates a vector (why
| not a string, in the first place?) and then makes a string with the
| same contents (remember that COERCE does not modify its argument, it
| makes a new object `corresponding to' its argument but with the
| right type).
You seem to be correct about this. I didn't know this about COERCE,
and I also wasn't aware of the possibility of directly modifiying
strings like this. (The explanation of this perhaps surprising
ignorance is that I'm a Lisp newbie. :)
(format t "Trying vector approach.~%")
(time
(dotimes (ix 10000 'ok)
(let ((str (make-array 30 :fill-pointer 0 :adjustable t)))
(vector-push-extend #\a str)
(vector-push-extend #\a str)
(vector-push-extend #\a str)
(vector-push-extend #\a str)
(vector-push-extend #\a str)
(vector-push-extend #\a str)
(vector-push-extend #\a str)
(vector-push-extend #\a str)
(vector-push-extend #\a str)
(vector-push-extend #\a str)
(setq str (coerce str 'string)))))
(format t "~%~%Trying string approach.~%")
(time
(dotimes (ix 10000 'ok)
(let ((str (make-string 30)))
(dotimes (fp 10)
(setf (char str fp) #\a)))))
Running this gives me:
[······@pc-larsga meta]$ clisp timer.lsp
Trying vector approach.
Real time: 1.119389 sec.
Run time: 0.98 sec.
Space: 1800572 Bytes
GC: 3, GC time: 0.04 sec.
Trying string approach.
Real time: 5.550576 sec.
Run time: 5.55 sec.
Space: 17562752 Bytes
GC: 33, GC time: 0.55 sec.
[······@pc-larsga meta]$ clisp -q -c timer.lsp
Compiling file /home/tosca/c1/larsga/privat/prog/clisp/meta/timer.lsp ...
Compilation of file /home/tosca/c1/larsga/privat/prog/clisp/meta/timer.lsp is finished.
0 errors, 0 warnings
[······@pc-larsga meta]$ clisp timer
Trying vector approach.
Real time: 0.470378 sec.
Run time: 0.47 sec.
Space: 1800072 Bytes
GC: 3, GC time: 0.04 sec.
Trying string approach.
Real time: 0.179193 sec.
Run time: 0.18 sec.
Space: 400072 Bytes
GC: 1, GC time: 0.01 sec.
[······@pc-larsga meta]$ lisp timer.lsp
;;; *** Don't forget to edit /var/lib/cmucl/site-init.lisp! ***
CMU Common Lisp 18a+ release x86-linux 2.4.7 6 November 1998 cvs, running on pc-larsga
Send bug reports and questions to your local CMU CL maintainer,
or to ········@debian.org
or to ··········@cons.org. (prefered)
type (help) for help, (quit) to exit, and (demo) to see the demos
Loaded subsystems:
Python 1.0, target Intel x86
CLOS based on PCL version: September 16 92 PCL (f)
* (load "timer")
; Loading #p"/home/tosca/c1/larsga/privat/prog/clisp/meta/timer.lsp".
Trying vector approach.
Compiling LAMBDA NIL:
Compiling Top-Level Form:
[GC threshold exceeded with 2,003,432 bytes in use. Commencing GC.]
[GC completed with 106,136 bytes retained and 1,897,296 bytes freed.]
[GC will next occur when at least 2,106,136 bytes are in use.]
Evaluation took:
1.9 seconds of real time
1.15 seconds of user run time
0.04 seconds of system run time
[Run times include 0.09 seconds GC run time]
837 page faults and
2232128 bytes consed.
Trying string approach.
Compiling LAMBDA NIL:
Compiling Top-Level Form:
Evaluation took:
0.02 seconds of real time
0.02 seconds of user run time
0.0 seconds of system run time
0 page faults and
399304 bytes consed.
*
| Using COERCE directly will traverse the list (I guess) twice, but
| only allocate a single string of the right length.
As I've pointed out before this is all done under the assumption that
the initial character source is not a list.
--Lars M.
On 17 Mar 1999 20:31:01 +0100, Lars Marius Garshol wrote:
..
>[······@pc-larsga meta]$ lisp timer.lsp
>;;; *** Don't forget to edit /var/lib/cmucl/site-init.lisp! ***
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Not wanting to pick on you, but why haven't you done this? Should
I automaticly fill in the "right" values at installation time?
Groetjes, Peter
--
It's logic Jim, but not as we know it. | ········@debian.org for pleasure,
"God, root, what is difference?",Pitr | ········@inthan.be for more pleasure!
From: Lars Marius Garshol
Subject: Re: string assembly in lisp?? help??
Date:
Message-ID: <wkaexbkn1j.fsf@ifi.uio.no>
* Lars Marius Garshol
|
| [······@pc-larsga meta]$ lisp timer.lsp
| ;;; *** Don't forget to edit /var/lib/cmucl/site-init.lisp! ***
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
* Peter Van Eynde
|
| Not wanting to pick on you, but why haven't you done this?
Simply because this is an installation I did on my computer at work
just to check out CMU-CL. I did that a couple of days ago and so far
haven't run CMU-CL more than 3-4 times, so I haven't bothered yet.
| Should I automaticly fill in the "right" values at installation
| time?
Sorry, I don't understand this question.
--Lars M.
On 18 Mar 1999 13:19:36 +0100, Lars Marius Garshol wrote:
>| Should I automaticly fill in the "right" values at installation
>| time?
>
>Sorry, I don't understand this question.
You're supposed to fill in a bit of trivial data like the site-name.
I was wondering if people would prefer the installation routine to
ask for this when installing, rather then bugging people to edit
this file.
Groetjes, Peter
--
It's logic Jim, but not as we know it. | ········@debian.org for pleasure,
"God, root, what is difference?",Pitr | ········@inthan.be for more pleasure!
From: Daniel R Barlow
Subject: CMUCL configuration (was Re: string assembly in lisp?? help??)
Date:
Message-ID: <7cqvv5$ldu@fishy.ox.compsoc.net>
In article <·······················@mail.inthan.be>,
Peter Van Eynde <········@inthan.be> wrote:
>You're supposed to fill in a bit of trivial data like the site-name.
>I was wondering if people would prefer the installation routine to
>ask for this when installing, rather then bugging people to edit
>this file.
This person wouldn't. I convert your packages to rpms with "alien";
rpm installation is traditionally a non-interactive thing.
You could make cmuclconfig sort it out, though. That's interactive
anyway.
-dan
········@mail.inthan.be (Peter Van Eynde) writes:
> On 18 Mar 1999 13:19:36 +0100, Lars Marius Garshol wrote:
> >| Should I automaticly fill in the "right" values at installation
> >| time?
> >
> >Sorry, I don't understand this question.
>
> You're supposed to fill in a bit of trivial data like the site-name.
> I was wondering if people would prefer the installation routine to
> ask for this when installing, rather then bugging people to edit
> this file.
IMHO, asking people to edit files at installation time is not a good thing.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
> ········@mail.inthan.be (Peter Van Eynde) writes:
>
> > You're supposed to fill in a bit of trivial data like the site-name.
> > I was wondering if people would prefer the installation routine to
> > ask for this when installing, rather then bugging people to edit
> > this file.
>
> IMHO, asking people to edit files at installation time is not a good thing.
I agree with Marco.
Absolutely under no circumstances should one edit a file upon
installation. The list of ways this can go wrong is large and
varied. It's not to say I've never done it. But neither I nor anyone
should ever feel they have followed normal, healthy engineering practice
when they do. It's an ugly kludge that one should feel embarrassed
about and should strive to eliminate.
* It is equivalent to editing source code for software reuse.
It is the antithesis of modular programming. It is the worst
of what C++ has to offer in the way of so-called oo design.
* This completely thwarts the ability to use md5 and
other checksum tools to verify the integrity of an installed piece of
foreign software.
* It risks that people who don't competently edit it
will create problems they are not aware of and nightmares for people
having to support them. It makes it impossible to say "I have foo 1.4"
becuase you don't--you have 1.4 as modified by me. That's a new
version. It needs a new name. And everyone will have different names.
* It risks the insertion of bogus or confidential information that will
be retransmitted to other sites if someone retransmits the software
installation to someone else instead of grabbing it fresh from the source.
* It isn't perspicuous. It's easy to overlook an edit you have to make.
* It forces people to be programmers continuing the worst trend of
computer science which is to make everyone have to be computer-savvy
just to do ordinary tasks rather than making computers be people-savvy.
All installation guides should ever say is just say "Press install."
That's not to say that they shouldn't ask you questions, log what they
did for inspection by those who want it, make the installation undoable,
etc. But anything more than those two words is a bug in the doc and
the system design.
I'm in a very grumpy mood today so unlike usual where I say there is
too sides to everything and everything is just a trade-off, I'm going to
just assert I'm right on this one.
Part of my bad mood may be related to having wasted two weeks learning
about how to compile the linux kernel, poking around in network card
device drivers, running all manner of configuration and diagnostic
tools, etc. just trying to get linux to boot with two network cards.
There isn't just a tool that does everything. One always just has to
edit a single line of a file. It's just that there are 50,000 linux
programmers and 50,000 single lines one might have to edit. There is
simply no way that is the right model of anything.
On Thu, 18 Mar 1999 17:54:04 GMT, Kent M Pitman wrote:
>> IMHO, asking people to edit files at installation time is not a good thing.
>
>I agree with Marco.
Agreed, the new version will ask for these details.
> [... arguments against editing files ...]
I had written a long explanation of why debian makes certain
choices, but this is distinctly off-charter. Let me just say that
I/we try to solve this problem the best way we can, and that at
least I know of no better system to date (I would be happy to be
corrected) and that nearly all of your comments are either already
solved or solutions are being discussed[1].
Groetjes, Peter
[1] It's a difficult road to walk _between_ point-and click dumming
down and sendmail (old style, no m4) configuration...
--
It's logic Jim, but not as we know it. | ········@debian.org for pleasure,
"God, root, what is difference?",Pitr | ········@inthan.be for more pleasure!
From: Lars Marius Garshol
Subject: Re: string assembly in lisp?? help??
Date:
Message-ID: <wkpv65lv9y.fsf@ifi.uio.no>
* Peter Van Eynde
|
| You're supposed to fill in a bit of trivial data like the site-name.
| I was wondering if people would prefer the installation routine to
| ask for this when installing, rather then bugging people to edit
| this file.
I'd much prefer to be asked.
--Lars M.
* Lars Marius Garshol <······@ifi.uio.no>
| You seem to be correct about this. I didn't know this about COERCE, and I
| also wasn't aware of the possibility of directly modifiying strings like
| this. (The explanation of this perhaps surprising ignorance is that I'm a
| Lisp newbie. :)
|
| (format t "Trying vector approach.~%")
| (time
| (dotimes (ix 10000 'ok)
| (let ((str (make-array 30 :fill-pointer 0 :adjustable t)))
| (vector-push-extend #\a str)
| (vector-push-extend #\a str)
| (vector-push-extend #\a str)
| (vector-push-extend #\a str)
| (vector-push-extend #\a str)
| (vector-push-extend #\a str)
| (vector-push-extend #\a str)
| (vector-push-extend #\a str)
| (vector-push-extend #\a str)
| (vector-push-extend #\a str)
| (setq str (coerce str 'string)))))
try it like this, instead:
(make-array 30 :fill-pointer 0 :adjustable t :element-type 'character)
BTW, if you have to time things, you might as well do it with proper
declarations and optimizations. otherwise, you don't know what you're
timing.
#:Erik