Allegro compilation warnings
Mario Frasca
I was playing around with the idea of having my programs checked for
compilation anytime I start them, and I managed to achieve this by
using the defsystem utility (I'm not sure I understand how much that is
a standard utility, it is included in the CLtL2 online docs, but it is
not described in the allegro ones)
then this construct at the beginning of some of the programs:
(eval-when (:execute :compile-toplevel)
(require <whatever the code requires>)
<...>
)
and something like this at the end of a 'loader' program:
(eval-when (:execute)
(print "checking add-ons system, or compiling them")
(defsystem add-ons-system
(:default-package "ideal"
:default-pathname "ideal:add-ons;"
)
(:module only-one ("cc-utils"
"qual"
"explanation"
"Cooper88a"
"timer"
"add-display-fns"
"matrix"
"gauss"
"extensions"
"top-sort")))
(compile-system 'add-ons-system))
then the question:
this is working, and it allowed me to find a lot of compilation
warnings, which I hate.
the most irritating ones are of this format
Warning: Free reference to undeclared variable *PRECISION* assumed special.
This symbol may have been intended: IDEAL::*PRECISION*.
most of them don't include the second line.
any suggestion on what to do to give the compiler as much information
as it needs so that it won't complain any more?
less disturbing are the ones:
Warning: Variable X-DUMMY is never used.
in C I can give the compiler some #pragma directive to inform it that I
know that this particular parameter is only acting as a dummy, I think
it was #pragma argsused, or something. anything similar in CL?
a pointer to a documentation page could be enough, if that page is
readable.
thanks in advance,
Mario
Raymond Wiker
> this is working, and it allowed me to find a lot of compilation
> warnings, which I hate.
>
> the most irritating ones are of this format
>
> Warning: Free reference to undeclared variable *PRECISION* assumed special.
> This symbol may have been intended: IDEAL::*PRECISION*.
>
> most of them don't include the second line.
>
> any suggestion on what to do to give the compiler as much information
> as it needs so that it won't complain any more?
>
> less disturbing are the ones:
> Warning: Variable X-DUMMY is never used.
>
> in C I can give the compiler some #pragma directive to inform it that I
> know that this particular parameter is only acting as a dummy, I think
> it was #pragma argsused, or something. anything similar in CL?
Check the HyperSpec entries for `ignore' and `ignoreable'.
--
Raymond Wiker
Raymon...@fast.no
scha...@dfki.de
> Warning: Free reference to undeclared variable *PRECISION* assumed special.
> This symbol may have been intended: IDEAL::*PRECISION*.
>
> as it needs so that it won't complain any more?
You could try to make sure that the variable *PRECISION* is known to
the compiler when the free reference to it is compiled. I assume that
it is a global variable introduced by a defvar or defparameter
somewhere. Alternatively, there is the SPECIAL declaration
identifier. I don't know whether this is what you really want, it
seems as if the warnings might actually hint at real errors. But you
can use the declarations to prevent this sort of warnings if you wish.
> Warning: Variable X-DUMMY is never used.
> in C I can give the compiler some #pragma directive to inform it that I
> know that this particular parameter is only acting as a dummy, I think
Have a look at the IGNORE and IGNORABLE declaration identifiers.
You could start from Section 3.3.3 of the HyperSpec available at
http://www.xanalys.com/software_tools/reference/HyperSpec/
Hope this helps,
Axel
Paul F. Dietz
> Warning: Free reference to undeclared variable *PRECISION* assumed special.
> This symbol may have been intended: IDEAL::*PRECISION*.
>
> any suggestion on what to do to give the compiler as much information
> as it needs so that it won't complain any more?
Warnings like this are often a sign that the code is wrong.
At the very least, they indicate poor programming style.
It may be that you meant IDEAL::*PRECISION*, but forgot
this file was in a different package. If so, you have
a bug. Add the package prefix.
If *PRECISION* was really meant, you should add a special
declaration:
(declaim (special *precision*))
or a defvar or defparameter form.
It's a good rule to try to eliminate all warnings, so
they do not obscure future warnings that may indicate
real bugs.
Paul
Erik Naggum
| the most irritating ones are of this format
|
| This symbol may have been intended: IDEAL::*PRECISION*.
|
|
| as it needs so that it won't complain any more?
Well, why don't you declare/define your global variables?
| less disturbing are the ones:
| Warning: Variable X-DUMMY is never used.
So why is it there?
Instead of being "irritated" and "disturbed" and making references
to another language, why not try to program in the language at hand?
The warnings you get indicate that you are still thinking in another
language and your irritation communicates that you don't intend to
stop doing that because you think it is somehow correct to think in
C++ and write in Common Lisp. What I want to know is how you began
to think in C++ in the first place. Or is it that that experience
has taught you that being irritated at computers and languages is
the best approach because nothing else really works any better?
(You're not the first C++ or Microsoft victim to believe this, and
it sometimes takes a long time for people with that background to
get the same kind of warm and calming sensation that the world of
computers can be understood and mastered without mystery and pain
that comes to people who understand the laws of physics and don't
swear at the physical world when it doesn't obey their wishes.
What's so fucking irritating is that those who lack that calmness
make so many incredibly retarded decisions and statements that only
do one thing: perpetuate the mystery and pain for all others. The
best approach is to get a suitable hand-gun and use your Microsoft
and C++ books for target practice. That gives you control, again.
Then start anew with a real language and tools intended for people
to use, not whatever semi-evolved simian the commercials work on.)
#:Erik
--
I agree with everything you say, but I would
attack to death your right to say it.
-- Tom Stoppard
Pierre R. Mai
> If *PRECISION* was really meant, you should add a special
> declaration:
>
> (declaim (special *precision*))
>
> or a defvar or defparameter form.
Just a minor addition: If you are a beginner, use defvar or defparameter
almost exclusively. A stand-alone special declaration is almost always
not what you want.
Regs, Pierre.
--
Pierre R. Mai <pm...@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Dirk Zoller
> Just a minor addition: If you are a beginner, use defvar or defparameter
> almost exclusively. A stand-alone special declaration is almost always
> not what you want.
Paul Graham's "On Lisp" at page 16f gives a comprehensive explanation what
this "special" is about. In short: It changes the way the variable is looked
up from "static" (which is the default in Common Lisp) to "dynamic".
Static means like in Pascal, variables bindings are found in the environment
where the code has been written. Dynamic means in the call chain that led
to the execution of the piece of code at hand.
HTH
Dirk
--
Dirk Zoller
e-mail: d...@onlinehome.de
http://www.dirk-zoller.de
Marco Antoniotti
ma...@cs.uu.nl (Mario Frasca) writes:
> first an introduction:
>
> I was playing around with the idea of having my programs checked for
> compilation anytime I start them, and I managed to achieve this by
> using the defsystem utility (I'm not sure I understand how much that is
> a standard utility, it is included in the CLtL2 online docs, but it is
> not described in the allegro ones)
The DEFSYSTEM utility is *not* part of CLTL2. You are probably
referring to the DEFSYSTEM which come with ACL. This is not
portable.
Instead, MK-DEFSYSTEM is. You can download it from the CLOCC
http://sourceforge.net/projects/clocc
Cheers
--
Marco Antoniotti =============================================================
NYU Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
Pierre R. Mai
> "Pierre R. Mai" wrote:
> > Just a minor addition: If you are a beginner, use defvar or defparameter
> > almost exclusively. A stand-alone special declaration is almost always
> > not what you want.
>
> Paul Graham's "On Lisp" at page 16f gives a comprehensive explanation what
> this "special" is about. In short: It changes the way the variable is looked
> up from "static" (which is the default in Common Lisp) to "dynamic".
>
> Static means like in Pascal, variables bindings are found in the environment
> where the code has been written. Dynamic means in the call chain that led
> to the execution of the piece of code at hand.
defvar and defparameter also implicitly declare the variable special,
so this isn't the reason why I advise against using stand-alone
special declarations. Just think of special declarations as a more
low-level building block, just like
(setf (fdefinition 'myfun) (lambda (x y) (+ x y)))
is more low-level than
(defun myfun (x y)
(+ x y))
There are times when using (setf fdefinition) is appropriate, but only
under special circumstances and when you know exactly what you are
doing. The same IMHO goes for stand-alone special declarations.
Duane Rettig
> Dirk Zoller <d...@onlinehome.de> writes:
>
> > "Pierre R. Mai" wrote:
> > > Just a minor addition: If you are a beginner, use defvar or defparameter
> > > almost exclusively. A stand-alone special declaration is almost always
> > > not what you want.
> >
> > Paul Graham's "On Lisp" at page 16f gives a comprehensive explanation what
> > this "special" is about. In short: It changes the way the variable is looked
> > up from "static" (which is the default in Common Lisp) to "dynamic".
> >
> > Static means like in Pascal, variables bindings are found in the environment
> > where the code has been written. Dynamic means in the call chain that led
> > to the execution of the piece of code at hand.
>
> defvar and defparameter also implicitly declare the variable special,
In fact, this can be seen easily by macroexpansion. I always
recommend that people use the following paradigm when trying
to figure out what is inside a macro:
(pprint (macroexpand <form>))
See examples below.
> so this isn't the reason why I advise against using stand-alone
> special declarations. Just think of special declarations as a more
> low-level building block, just like
>
> (setf (fdefinition 'myfun) (lambda (x y) (+ x y)))
>
> is more low-level than
>
> (defun myfun (x y)
> (+ x y))
>
> There are times when using (setf fdefinition) is appropriate, but only
> under special circumstances and when you know exactly what you are
> doing. The same IMHO goes for stand-alone special declarations.
Correct. For example, if you macroexpand a defining form in
Allegro CL, you see that with a special declaration or a (setf fdefinition)
form you are missing the source-file-recording that tends to occur
automatically with defining forms. Of course, this may be precisely
what you want. But usually you want to use a defining form.
Below are example expansions of several defining forms, and I
even included your setf form as well, to show that the macroexpand
technique is not limited to defining forms.
cl-user(1): (pprint (macroexpand '(defvar foo 100)))
(progn (declaim (special foo)) (or (boundp 'foo) (setq foo 100))
(record-source-file 'foo :type :variable) 'foo)
cl-user(2): (pprint (macroexpand '(defparameter bar 100)))
(progn (declaim (special bar)) (setq bar 100)
(record-source-file 'bar :type :variable) 'bar)
cl-user(3): (pprint (macroexpand '(defconstant bar 100)))
(progn (declaim (special bar))
(eval-when (compile) (excl::defconstant1 'bar 100))
(record-source-file 'bar :type :variable) (excl::defconstant2 'bar 100))
cl-user(4): (pprint (macroexpand '(defun bas () 100)))
(progn (eval-when (:compile-toplevel)
(excl::check-lock-definitions-compile-time 'bas 'function 'defun
(fboundp 'bas))
(push 'bas excl::.functions-defined.))
(progn (eval-when (:compile-toplevel)
(excl::check-de-argdecl-change 'bas 'nil))
(declaim (excl::dynamic-extent-arguments nil bas)))
(setf (fdefinition 'bas)
(let ((excl::f
(named-function bas (lambda nil (block bas 100)))))
(excl::set-func_name excl::f 'bas)
excl::f))
(remprop 'bas 'excl::%fun-documentation) (record-source-file 'bas) 'bas)
cl-user(5): (pprint (macroexpand '(setf (fdefinition 'myfun) (lambda (x y) (+ x y)))))
(let* ((#:g119 (lambda (x y) (+ x y)))) (excl::set-function-1 'myfun #:g119))
cl-user(6):
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)
Erik Naggum
| The DEFSYSTEM utility is *not* part of CLTL2. You are probably
| referring to the DEFSYSTEM which come with ACL. This is not
| portable.
What utter hogwash! You know better than this, Marco, so don't try
to play presidential campaigns on us, even though the rest of the
media does its best to dumb down to the level of the two jerkfaces.
Here's a hint: The implementation of the function CAR in Common Lisp
is not portable. Still, portable Common Lisp programs may use CAR.
How _can_ this be? How can we possibly use non-portable software to
write portable programs? This must be a mystery to people who buy
your line, Marco! Provided they think about it at all.
| Instead, MK-DEFSYSTEM is.
_Really_? You're clearly saying that if I use MK-DEFSYSTEM, I can't
"port" the build rules to Allegro CL's defsystem and vice versa, are
you not? How f**king portable is that?
_Designing_ for multiple, incompatible defsystems so we can't move
build rules around is such an incredibly moronic thing to do that it
ought to result in public flogging while being forced to watch every
presidential campaign ad.
Weren't you the guy who only a short time ago argued that XML was a
move in the right direction? My argument against XML is that it
doesn't help squat with the real problem, which is that data is so
dependent on the interpretation of the structure being represented
that the syntax is immaterial in comparison. Now you go and prove
my whole case by having a DEFSYSTEM wherein the build rules, which
are _way_ more important to a user than whether the implementation
machinery is or is not portable, are worthless if he switches the
"application" that uses those build rules, and he has to encode his
old data in a new format, which is supposedly "portable", just like
XML is "portable" on some irrelevant scale, and therefore "better"?
Methinks you've been had, big time, by the XML hype and have missed
the opportunity to think about information representation entirely,
instead confused into thinking that some irrelevant piece of the
puzzle needs to be "portable" (the syntax or the implementation),
and that that's it, we can all relax now and ignore the cost of
conversion, irritation with subtle differences, and the mysterious
bugs that crop up because we poor humans remember too well.
This is why XML is _not_ s step in the right direction: It works
just like a pacifier on screaming babies who are duped into feeling
they got something good stuffed into their face and so they stop
screaming for whatever they _really_ wanted (love, compassion, body
contact, etc, clearly not as easy to market as some disgusting piece
of plastic, but hey, let's just shut the kids up, just like we can
make all those stupid crying users shut up with some irrelevant hype
that goes nowhere and does nothing for them!). Stop treating people
like screaming babies and grow up, damn it! It's the _information_
that needs to be portable -- to hell with "portable" implementations
that make that information non-portable or some "portable" syntax
that makes it even harder _actually_ to get portable information.
Disclaimer 1: This is why I haven't even _looked_ at MK-DEFSYSTEM,
so I'm just taking Marco's word for it that it is incompatible with
Allegro CL's defsystem and every other defsystem by implication.
Disclaimer 2: I started using Allegro CL's defsystem because it was
there, well integrated into the full system, not because I made any
conscious decision to use that defsystem in particular. It was just
there when I needed it. Having spent lots of time understanding how
to use it and extend it and how it works, I'm not going to throw it
away for some new shit just because it has a portable implementation
that's going to be a helpful feature exactly _once_ in its lifetime.
Mario Frasca
> Well, why don't you declare/define your global variables?
written by others. as long as I didn't modify it, it would just run
quietly. then I had to perform some minor changes and I discovered a
lot of compilation warnings. I'm used to having code without
warnings, or where the amount of warnings I get is exactly a known
figure, so I started modifying the code in order to remove all
warnings.
unfortunately my understanding of the compilation process in
Lisp is still far from complete, hence my questions.
>| less disturbing are the ones:
>| Warning: Variable X-DUMMY is never used.
>
> So why is it there?
wow, an easy question!
you deserve two answers:
1) as far as these warnings are coming from code which I did not write,
I just follow the rule "if it ain't broken, don't fix it".
2) look at this example:
(defun compute-coefficients (x1 p1 x2 p2 x3 p3)
(handler-bind ((DIVISION-BY-ZERO
#'(lambda (x-dummy) (return-from compute-coefficients nil))))
(gauss:solve (list (list x1 1 (- p1) (* x1 p1))
(list x2 1 (- p2) (* x2 p2))
(list x3 1 (- p3) (* x3 p3))))))
here I have to provide handler-bind with a one-parameter-function, but
in this function I really don't know what to do with this parameter. I
named x-dummy so that when reading that warning I know I can ignore
it.
Mario
Mario Frasca
>Warnings like this are often a sign that the code is wrong.
>At the very least, they indicate poor programming style.
>
>It may be that you meant IDEAL::*PRECISION*, but forgot
>this file was in a different package. If so, you have
>a bug. Add the package prefix.
I have an idea of what is going on here:
I have enclosed all (require)s in (eval-when) blocks, and replaces all
(load)s by the corresponding (require). I then tried to achieve the same
as you do when you use 'make'. but then the lisp-way, with defsystem.
now some sources are being compiled without the environment having
loaded some other required sources. I hope this is stated correctly.
I probably have to inspect the various sources and discover all
dependencies or find out where they have been stated and in which
format.
thanks,
Mario
Rainer Joswig
(Mario Frasca) wrote:
> 1) as far as these warnings are coming from code which I did not write,
> I just follow the rule "if it ain't broken, don't fix it".
>
> 2) look at this example:
> (defun compute-coefficients (x1 p1 x2 p2 x3 p3)
> (handler-bind ((DIVISION-BY-ZERO
> #'(lambda (x-dummy) (return-from compute-coefficients nil))))
> (gauss:solve (list (list x1 1 (- p1) (* x1 p1))
> (list x2 1 (- p2) (* x2 p2))
> (list x3 1 (- p3) (* x3 p3))))))
>
> here I have to provide handler-bind with a one-parameter-function, but
> in this function I really don't know what to do with this parameter.
Maybe just ignore it here. It is the condition object, which has
some information about the error. Seems like the
code does not make any use of it.
> I
> named x-dummy so that when reading that warning I know I can ignore
> it.
>
> Mario
...
(lambda (x-dummy)
(declare (ignore x-dummy))
...
The argument to the function actually is a condition.
You may leave a more descriptive variable name:
...
(lambda (condition)
(declare (ignore condition))
...
--
Rainer Joswig, Hamburg, Germany
Email: mailto:jos...@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Erik Naggum
| unfortunately my understanding of the compilation process in
| Lisp is still far from complete, hence my questions.
Sure, but it was your _irritation_ that I commented on. Legacy code
is _not_ a source of pain and suffering. It can be a source of
great pride and hubris: You're _so_much_better_ than the neanderthal
who wrote the code to begin with. It can be a wonderful source of
satisfaction: Almost anything you do will be an improvement. It can
be used for target practice: Just print it out, hang it up, and fire
at will. It's not like you're killing anything that deserved to
live. However, make sure that whoever hired the neanderthal who
makes you waste your time knows how you're spending your time --
most managers are unaware that they need to adjust their behavior
and their decision criteria because their inferiors are reluctant to
tell them how they went wrong in the past. Managers should be
willing to listen to and learn from the experience collected by
their inferiors, or _their_ manager(s) need to hear it. It may be
easier to move elsewhere, but that has the obvious downside of not
identifying and virtually hanging neanderthal programmers _and_ the
managers who hire them. If this is not important to you, chances
are that you are in the same category yourself. (If you were only
working with programming to get paid, bad legacy code is such a huge
source of billable hours that you can't possibly be unhappy with it.)
| >| less disturbing are the ones:
| >| Warning: Variable X-DUMMY is never used.
| >
| > So why is it there?
|
| wow, an easy question!
I'm afraid not.
| you deserve two answers:
I _deserve_ them? Geez.
| 1) as far as these warnings are coming from code which I did not write,
| I just follow the rule "if it ain't broken, don't fix it".
It _is_ broken. That's why you get warnings, and that's why you're
trying to fix it. And I _deserved_ this answer? Geez.
| 2) look at this example:
| (defun compute-coefficients (x1 p1 x2 p2 x3 p3)
| (handler-bind ((DIVISION-BY-ZERO
| #'(lambda (x-dummy) (return-from compute-coefficients nil))))
| (gauss:solve (list (list x1 1 (- p1) (* x1 p1))
| (list x2 1 (- p2) (* x2 p2))
| (list x3 1 (- p3) (* x3 p3))))))
|
| here I have to provide handler-bind with a one-parameter-function,
| but in this function I really don't know what to do with this
| parameter. I named x-dummy so that when reading that warning I know
| I can ignore it.
I suggest you look up handler-case to simplify the expression
dramatically. See? Not an easy question.
Marco Antoniotti
Erik Naggum <er...@naggum.net> writes:
> * Marco Antoniotti <mar...@cs.nyu.edu>
> | The DEFSYSTEM utility is *not* part of CLTL2. You are probably
> | referring to the DEFSYSTEM which come with ACL. This is not
> | portable.
>
> What utter hogwash! You know better than this, Marco, so don't try
> to play presidential campaigns on us, even though the rest of the
> media does its best to dumb down to the level of the two jerkfaces.
>
> Here's a hint: The implementation of the function CAR in Common Lisp
> is not portable. Still, portable Common Lisp programs may use CAR.
> How _can_ this be? How can we possibly use non-portable software to
> write portable programs? This must be a mystery to people who buy
> your line, Marco! Provided they think about it at all.
Come on Erik! You very well that if I write an ACL DEFSYSTEM
spec it simply won't run on CMUCL. Unless somebody "ported" ACL
DEFSYSTEM (or LispWorks, or MCL DEFSYSTEM) to CMUCL.
In the current state of affairs: MK-DEFSYSTEM runs (more or less) on all
platforms. The other DEFSYS around do not (with the possible excepton
of PCL DEFSYS).
I'd rather "write things once" if I can. Writing with ACL DEFSYSTEM
will make me write things at least twice.
> | Instead, MK-DEFSYSTEM is.
>
> _Really_? You're clearly saying that if I use MK-DEFSYSTEM, I can't
> "port" the build rules to Allegro CL's defsystem and vice versa, are
> you not? How f**king portable is that?
Of course you can rewrite the MK-DEFSYSTEM rules in Lispworks
DEFSYSTEM (and MCL, and PCL). You are doing at least twice the
work. "In this sense" it is not portable.
You can always write things in Scheme and then port your Scheme
program from implementation X to implementation Y by rewriting the
code that does "records" or "multi-dimensional arrays". The semantics
is pretty much the same. The syntax as well.
> _Designing_ for multiple, incompatible defsystems so we can't move
> build rules around is such an incredibly moronic thing to do that it
> ought to result in public flogging while being forced to watch every
> presidential campaign ad.
Apart the pain that just comes to my mind by your suggested torture :)
(I have a more sadistic twist: watch *italian* electoral campaign ads)
I do not understand your first sentence. It seems that you assume
that "build rule" is something primitive. I do not understand this.
As per the way I work. I organize my code in such a way that it is
easily structured using MK-DEFSYSTEM. Our group has just purchased a
version of ACL (sorry Xanalys folks :) Duane Rettig will be happy
instead - at least until I'll start bugging him :) ). Yet I do not use
ACL DEFSYSTEM because I cannot run it under CMUCL (at least I cannot
easily - and I have not even tried to think about licensing
questions).
> Weren't you the guy who only a short time ago argued that XML was a
> move in the right direction? My argument against XML is that it
> doesn't help squat with the real problem, which is that data is so
> dependent on the interpretation of the structure being represented
> that the syntax is immaterial in comparison.
And in my reply I said you are right in this respect. However, XML
somewhat frees C/C++/Perl/Java/Python/Ada95/Intercal/Kwikkalkul users
from the burden of writing an AST constructor for their documents.
Which is what you get for free when using CL. *IMHO*, this has an
immense pragmatic effect and a potential for speedup in the day-to-day
life of programmers. I may be wrong on this.
> Now you go and prove
> my whole case by having a DEFSYSTEM wherein the build rules, which
> are _way_ more important to a user than whether the implementation
> machinery is or is not portable, are worthless if he switches the
> "application" that uses those build rules, and he has to encode his
> old data in a new format, which is supposedly "portable", just like
> XML is "portable" on some irrelevant scale, and therefore
> "better"?
Erik. I really do not understand this. I am missing the use of
"build rule" that you make. If I can say something in my defense
(which may imply an interpretation of what you just wrote which may be
incorrect), I wrote CL-CONFIGURATION to address this sort of issues.
With CL-CONFIGURATION you can :REQUIRE-SYSTEM which has been written
in a number of different and incompatible DEFSYSes. In this way you
don't have to translate. I don't expect CL-CONFIGURATION to be
perfect, but I find it useful.
> Methinks you've been had, big time, by the XML hype and have missed
> the opportunity to think about information representation entirely,
> instead confused into thinking that some irrelevant piece of the
> puzzle needs to be "portable" (the syntax or the implementation),
> and that that's it, we can all relax now and ignore the cost of
> conversion, irritation with subtle differences, and the mysterious
> bugs that crop up because we poor humans remember too well.
That's why I wrote CL-CONFIGURATION and CL-ENVIRONMENT.
...
>
> Disclaimer 1: This is why I haven't even _looked_ at MK-DEFSYSTEM,
> so I'm just taking Marco's word for it that it is incompatible with
> Allegro CL's defsystem and every other defsystem by implication.
Yes it is. It also *runs* on Lispworks, MCL, CMUCL, CLisp, ACL, and --
I hope -- Corman Lisp, EClipse and -- maybe -- GCL, ECoLisp and ECLS.
> Disclaimer 2: I started using Allegro CL's defsystem because it was
> there, well integrated into the full system, not because I made any
> conscious decision to use that defsystem in particular. It was just
> there when I needed it. Having spent lots of time understanding how
> to use it and extend it and how it works, I'm not going to throw it
> away for some new shit just because it has a portable implementation
> that's going to be a helpful feature exactly _once_ in its
> lifetime.
Fine. I wrote CL-CONFIGURATION for you.
(conf:defconfiguration "ERIK-SYSTEM-CONFIGURATION"
(:require-system "MARCO-SYSTEM"
:system-file-namestring "marco.system"
:system-type :mk-defsystem)
(:require-system "ERIK-SYSTEM"
:system-file-namestring "erik.sys"
:system-type :allegro))
Running CONF:SETUP on an ACL with MK-DEFSYSTEM available will
correctly load all the required systems. On a CMUCL it will tell you
that you do not have ACL DEFSYSTEM available. (CL-CONFIGURATION does
other things as well, namely set up Logical Pathnames in a way I find
reasonable).
CL-CONFIGURATION is a new piece of software. It is by no means
perfect. But it runs at least on ACL and CMUCL (if it does not run on
other implementations it should really be easy to fix.)
BTW. I started using MK-DEFSYSTEM because I started working with
GCL and CMUCL and then I pretty much went down the road you went.
Paolo Amoroso
> _Really_? You're clearly saying that if I use MK-DEFSYSTEM, I can't
> "port" the build rules to Allegro CL's defsystem and vice versa, are
> you not? How f**king portable is that?
In the following paper Kent Pitman discussed the separation of notation
from functionality in system management tools:
"The Description of Large Systems"
MIT AI Lab Memo No. 801
September, 1984
Abstract:
In this paper, we discuss the problems associated with the description
and manipulation of large systems when their sources are not maintained
as single files. We show why and how tools that address these issues,
such as Unix MAKE and Lisp Machine DEFSYSTEM, have evolved.
Existing formalisms suffer from the problem that their _syntax_ is not
easily separatable from their _functionality_. In programming languages,
standard "calling conventions" exist to insulate the caller of a function
from the syntactic details of how that function was defined, but until
now no such conventions have existed to hide consumers of program systems
from the details of how those systems were specified.
We propose a low-level data abstraction which can support notations such
as those used by MAKE and DEFSYSTEM without requiring that the
introduction of a new notation be accompanied by a completely different
set of tools for instantiating or otherwise manipulating the resulting
system.
Lisp is used for presentation, but the issues are not idiosyncratic to
Lisp.
Keywords: Compilation, Large Systems, Lisp, System Maintenance
Pitman proposed low-level protocols for supporting the creation of
different system management tools. Tim Bradshaw mentioned a similar idea as
an example of a metafeature in a paper presented at LUGM '99:
"One step beyond, or, Creeping metafeaturism"
http://www.cley.com/articles/one-step-beyond.pdf
See section 7 "One step beyond" on page 7.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Erik Naggum
| Come on Erik!
Just _fix_ your attitude problem, Marco. Unless, of course, the
_intent_ of your messages is to piss me off.
| You very well that if I write an ACL DEFSYSTEM spec it simply won't
| run on CMUCL. Unless somebody "ported" ACL DEFSYSTEM (or LispWorks,
| or MCL DEFSYSTEM) to CMUCL.
The most interesting property of a language is whether it has been
specified so that it may be implemented independently. If it can't,
don't ever use it.
Portable code is red herring when it comes to sharing information
that uses code as its vehicle of transportation and existence.
Portable code has in fact led to serious problems when languages
only exist as a single implementation that runs "everywhere".
I'm not sure whether your "If only X were in the standard" recently
was meant as a strong opinion that people should not use that which
is not in the standard, but the Standard you allude to is a document
ath allows people everywhere to implement the language and places
requirements on the implementation.
| In the current state of affairs: MK-DEFSYSTEM runs (more or less) on all
| platforms.
This is not necessarily a good thing. This means that there will be
only one implementation of it because other implementations are not
worth writing. This leads to cancer of the language it implements.
| I'd rather "write things once" if I can. Writing with ACL DEFSYSTEM
| will make me write things at least twice.
You _could_ implement the language used by Allegro CL's defsystem.
| You can always write things in Scheme and then port your Scheme
| program from implementation X to implementation Y by rewriting the
| code that does "records" or "multi-dimensional arrays". The semantics
| is pretty much the same. The syntax as well.
Why are you not getting it? You're so favorable to XML, yet you
don't even seem to grasp that the idea behind XML is that it's a
syntax standard that people implement in order for their data to be
at least parseable from implementation to implementation. You don't
want "A portable XML parser". You want "portable XML data".
| As per the way I work. I organize my code in such a way that it is
| easily structured using MK-DEFSYSTEM.
Languages tend to shape the way we think.
| And in my reply I said you are right in this respect. However, XML
| somewhat frees C/C++/Perl/Java/Python/Ada95/Intercal/Kwikkalkul
| users from the burden of writing an AST constructor for their
| documents. Which is what you get for free when using CL. *IMHO*,
| this has an immense pragmatic effect and a potential for speedup in
| the day-to-day life of programmers. I may be wrong on this.
_Why_ does it have that potential? Is it because there is a common
standard that many people _implement_ and conform to, or is it
because there is code that is portable from C to C++ to Perl to Java
to Python to Ada 95 to Intercal to Kwikkalkul or whatever?
I'm not interested in what a program does with my data when I choose
to use a syntax like XML (or SGML). I'm interested in making sure
that I can write a new application according to a specification that
will be able to read and process it without having access to the
(probably portable, too) code that processed it initially.
| Erik. I really do not understand this. I am missing the use of
| "build rule" that you make.
The information you write down in your defsystem rules are intended
to help you build the system, right? Like a makefile builds stuff.
Of course, "building" in Common Lisp also means loading it into a
Lisp system and perhaps dumping a new image, but the whole idea is
that you have a bunch of sources, a bunch of build rules, and if you
apply the build rules to the sources, you end up with a product.
Those relationships are important to preserve and describe
accurately. That's why a _common_ defsystem is important. That's
why a portable defsystem is probably not a good thing, because there
will never be anyone who argues for or against features in it, no
arguments over the implementation or the precise semantics, only
"does it work or not"-style questions, which are anathema to the
value of the described relationships.
| If I can say something in my defense (which may imply an
| interpretation of what you just wrote which may be incorrect), I
| wrote CL-CONFIGURATION to address this sort of issues. With
| CL-CONFIGURATION you can :REQUIRE-SYSTEM which has been written in a
| number of different and incompatible DEFSYSes. In this way you
| don't have to translate. I don't expect CL-CONFIGURATION to be
| perfect, but I find it useful.
Bad solution to the wrong problem. If you had written this utility
to read the language used by the various defsystems and produced
some common form that could build with your system, we might be
getting somewhere, but as long as you only identify the interpreter
of the descriptions, you help kill the information, i.e., making it
_more_ dependent on the specific interpreter of its representation.
| > Methinks you've been had, big time, by the XML hype and have
| > missed the opportunity to think about information representation
| > entirely, instead confused into thinking that some irrelevant
| > piece of the puzzle needs to be "portable" (the syntax or the
| > implementation), and that that's it, we can all relax now and
| > ignore the cost of conversion, irritation with subtle
| > differences, and the mysterious bugs that crop up because we
| > poor humans remember too well.
|
| That's why I wrote CL-CONFIGURATION and CL-ENVIRONMENT.
I haven't looked at them, but from what you describe, they fall in
the category of "stop-gap solutions that block real progress", like
a huge number of other software "solutions" to fundamental problems.
People will appreciate it, of course, and it does solve a problem
that people actually have, but they have it for a bad reason, and it
should not be solved for another bad reason. That way lies Perl.
| It also *runs* on Lispworks, MCL, CMUCL, CLisp, ACL, and -- I hope
| -- Corman Lisp, EClipse and -- maybe -- GCL, ECoLisp and ECLS.
This is good if you go for the monopoly control situation where you
want everybody to use your _implementation_, but the more you keep
telling me it runs everywhere, the more important it is to make sure
the language it interpretes is specified externally to it and
actually is implemented by someeone else, too.
| Fine. I wrote CL-CONFIGURATION for you.
I hope that one day you will at least listen enough to what I keep
telling you in more and more different ways in the hopes of one day
getting through the belief that you unquestionably do the right
thing that it may not be the right thing. So: No, you didn't.
If anything, I want a standardized defsystem whose semantics is the
object of standardization, not the code. When we have some code
that gets standardized, we all lose, because the standard becomes
"whatever the code does", and thousands of people will hack at the
code and standard means exactly nothing. When we standardize
languages, we all win, because thousands of people will have a
single, authoritative source, and will fight to have people agree
with them on what the specification should say. Since people put in
special cases in code and exploit them to no end, but can't get away
with it in specifications, the means of control over the run-away
programmer is a good specification.
From one data point, you can extrapolate in any direction.
From one implementation, you can standardize in any direction.
| BTW. I started using MK-DEFSYSTEM because I started working with
| GCL and CMUCL and then I pretty much went down the road you went.
Then how did we end up so astonishingly far apart?
Paolo Amoroso
[...about the availability of MK-DEFSYSTEM on several platforms...]
> This is good if you go for the monopoly control situation where you
> want everybody to use your _implementation_, but the more you keep
> telling me it runs everywhere, the more important it is to make sure
> the language it interpretes is specified externally to it and
> actually is implemented by someeone else, too.
MK-DEFSYSTEM comes with good documentation. Would that be a good starting
point for creating a standard? What kind of work would it take to turn that
documentation into a useful standard?
Marco Antoniotti
Hello
I apologize in advandce for the long citations.
Erik Naggum <er...@naggum.net> writes:
> | You very well that if I write an ACL DEFSYSTEM spec it simply won't
> | run on CMUCL. Unless somebody "ported" ACL DEFSYSTEM (or LispWorks,
> | or MCL DEFSYSTEM) to CMUCL.
>
> The most interesting property of a language is whether it has been
> specified so that it may be implemented independently. If it can't,
> don't ever use it.
>
> Portable code is red herring when it comes to sharing information
> that uses code as its vehicle of transportation and existence.
> Portable code has in fact led to serious problems when languages
> only exist as a single implementation that runs "everywhere".
Let's narrow dwon the issues to "DEFSYSTEM". The need for a common
DEFSYSTEM has been felt for some time. Messages were sent to the
X3J13 mailing list asking to put a DEFSYSTEM into the standard.
As per MK-DEFSYSTEM, I must say that there is a document which
describes its behavior in a pretty good way. Of course it could be
made better (actually it should), but it describes pretty well what
the intent of the package should be as well as its "semantics". The
document could be taken as a starting point for other competing
implementations.
MK-DEFSYSTEM also has - IMHO - a rather nice sematics and systems
written in it are rather straightforward (YMWL).
Reimplementing ACL-DEFSYS or LW-DEFSYS would be quite a job at this
point. The current state of affairs tells me that it is easier and
better to converge on MK-DEFSYSTEM.
> I'm not sure whether your "If only X were in the standard" recently
> was meant as a strong opinion that people should not use that which
> is not in the standard, but the Standard you allude to is a document
> ath allows people everywhere to implement the language and places
> requirements on the implementation.
No. It is not a strong opinion. Although I encourage people who start
a fresh new project in Common Lisp to use MK-DEFSYSTEM instead of the
"local" ones. Of course, if you do not plan to distribute your
software, you have less ncentives to use a tool like MK-DEFSYSTEM.
THink of my case. I just wrote a nifty piece of software which will
have to run under Linux (where I essentially will have to use CMUCL),
Windows (where I must use a "not-in-the-standard" feature of ACL -
namely OLE), and probably the Mac using MCL. The system I wrote was
fresh. Basically no code existed before May. In this case using
MK-DEFSYSTEM savesme quite a bit of work.
> | In the current state of affairs: MK-DEFSYSTEM runs (more or less) on all
> | platforms.
>
> This is not necessarily a good thing. This means that there will be
> only one implementation of it because other implementations are not
> worth writing. This leads to cancer of the language it
> implements.
I wouldn't go so far. Let's say that at this point we need a better
document describing what MK-DEFSYSTEM is and must do. Then we make
susre that the implementation is correct w.r.t. the document. People
experiment and "the invisible parenthesis" decides what is worth and
what is not. However, in this case there will be a "usable" common
reference implementation. With the power of hindsight this is on
possible reason why we are using CLOS, but not CLIM.
> | I'd rather "write things once" if I can. Writing with ACL DEFSYSTEM
> | will make me write things at least twice.
>
> You _could_ implement the language used by Allegro CL's defsystem.
Franz could implement MK-DEFSYSTEM.
...
> Why are you not getting it? You're so favorable to XML, yet you
> don't even seem to grasp that the idea behind XML is that it's a
> syntax standard that people implement in order for their data to be
> at least parseable from implementation to implementation. You don't
> want "A portable XML parser". You want "portable XML data".
I am not *that* favourable to XML. And I uderstand your argument.
>
> | As per the way I work. I organize my code in such a way that it is
> | easily structured using MK-DEFSYSTEM.
>
> Languages tend to shape the way we think.
>
> | And in my reply I said you are right in this respect. However, XML
> | somewhat frees C/C++/Perl/Java/Python/Ada95/Intercal/Kwikkalkul
> | users from the burden of writing an AST constructor for their
> | documents. Which is what you get for free when using CL. *IMHO*,
> | this has an immense pragmatic effect and a potential for speedup in
> | the day-to-day life of programmers. I may be wrong on this.
>
> _Why_ does it have that potential? Is it because there is a common
> standard that many people _implement_ and conform to, or is it
> because there is code that is portable from C to C++ to Perl to Java
> to Python to Ada 95 to Intercal to Kwikkalkul or whatever?
>
> I'm not interested in what a program does with my data when I choose
> to use a syntax like XML (or SGML). I'm interested in making sure
> that I can write a new application according to a specification that
> will be able to read and process it without having access to the
> (probably portable, too) code that processed it initially.
I agree with this. I am merely saying that, given the state of
affairs in the rest of the world before XML, XML is quite a step
forward, exactly for the reasons you mention. The fact that you will
then have access to a libxml.so which will contain a parser for the
syntax which you will eventually interpret according to a "spec
document", will save quite a bit of work. The relatively bad news for
the Lisp Community is that Lisp had the notion of Sexpr and READ for
ages.
>
> | Erik. I really do not understand this. I am missing the use of
> | "build rule" that you make.
>
> The information you write down in your defsystem rules are intended
...
>
> Those relationships are important to preserve and describe
> accurately. That's why a _common_ defsystem is important. That's
> why a portable defsystem is probably not a good thing, because there
> will never be anyone who argues for or against features in it, no
> arguments over the implementation or the precise semantics, only
> "does it work or not"-style questions, which are anathema to the
> value of the described relationships.
This is an excellent point. Basically you are saying that 'make' is
"ugly". Which is an agreeable proposition. However, how do you
proceed toward a "common defsystem"? I do not have the time and/or
resources to undertake such a task (I did not even write MK-DEFSYSTEM
to start with). But, having a common portable "reference"
implementation is a good thing. PCL fitted the bill. And now AFAIK,
ACL and LW have non-PCL CLOS system. However, note that your very
same argument applies to ACL-DEFSYSTEM and LW-DEFSYSTEM. "there will
never be anyone who argues for or against features in it, no arguments
over the implementation or the precise semantics, only "does it work
or not"-style questions, which are anathema to the value of the
described relationships."
> | If I can say something in my defense (which may imply an
> | interpretation of what you just wrote which may be incorrect), I
> | wrote CL-CONFIGURATION to address this sort of issues. With
> | CL-CONFIGURATION you can :REQUIRE-SYSTEM which has been written in a
> | number of different and incompatible DEFSYSes. In this way you
> | don't have to translate. I don't expect CL-CONFIGURATION to be
> | perfect, but I find it useful.
>
> Bad solution to the wrong problem. If you had written this utility
> to read the language used by the various defsystems and produced
> some common form that could build with your system, we might be
> getting somewhere, but as long as you only identify the interpreter
> of the descriptions, you help kill the information, i.e., making it
> _more_ dependent on the specific interpreter of its
> representation.
True. I won't argue whether this is a "bad solution to the wrong
problem". I believe that the problem the CL community has is
"bad". As per your suggestion, yes. It would have been better, but it
is a solution that is beyond my energies. After all it has only been
6 months I have been able to actually work on CL to solve my work
problems.
...
> | That's why I wrote CL-CONFIGURATION and CL-ENVIRONMENT.
>
> I haven't looked at them, but from what you describe, they fall in
> the category of "stop-gap solutions that block real progress", like
> a huge number of other software "solutions" to fundamental problems.
> People will appreciate it, of course, and it does solve a problem
> that people actually have, but they have it for a bad reason, and it
> should not be solved for another bad reason. That way lies Perl.
Yes. They are "stop-gap solutions". I don't beleive they are as bad
as to "stop real progress". They are up for grab and you can argue
with their semantics and implementations. Maybe down that line "lies
Perl", I surely hope people won't go all the way there. I surely
wouldn't (though I may write code that goes in that direction).
>
> | It also *runs* on Lispworks, MCL, CMUCL, CLisp, ACL, and -- I hope
> | -- Corman Lisp, EClipse and -- maybe -- GCL, ECoLisp and ECLS.
>
> This is good if you go for the monopoly control situation where you
> want everybody to use your _implementation_, but the more you keep
> telling me it runs everywhere, the more important it is to make sure
> the language it interpretes is specified externally to it and
> actually is implemented by someeone else, too.
The language *is* specified externally (there is a good document
describing it). I have been trying to write up another document which
will explore extensions to MK-DEFSYSTEM (e.g. loading of C libraries -
which now is a non documented and not completely working feature of
MK-DEFSYTEM). Franz and Xanalys can implement MK-DEFSYSTEM as they
want. The licensing allows them to do so. Surely I don't want to be
seen an I simply won't behave as a monopolist. CL-CONFIGURATION is
there to prove this claim of mine.
> | Fine. I wrote CL-CONFIGURATION for you.
>
> I hope that one day you will at least listen enough to what I keep
> telling you in more and more different ways in the hopes of one day
> getting through the belief that you unquestionably do the right
> thing that it may not be the right thing. So: No, you didn't.
>
> If anything, I want a standardized defsystem whose semantics is the
> object of standardization, not the code. When we have some code
> that gets standardized, we all lose, because the standard becomes
> "whatever the code does", and thousands of people will hack at the
> code and standard means exactly nothing. When we standardize
> languages, we all win, because thousands of people will have a
> single, authoritative source, and will fight to have people agree
> with them on what the specification should say. Since people put in
> special cases in code and exploit them to no end, but can't get away
> with it in specifications, the means of control over the run-away
> programmer is a good specification.
Erik, I agree with this. CL-CONFIGURATION comes with what I hope to
be a good document describing the intended semantics of the
system. I am not on par with many people on this list (yourself
included) who are capable of writing a complex standard document and
make sure that there are no loose ends (besides, I have to do other
work as well). If people wants modifications on the document, I am
perfectly willing to start arguing and bite all the necessary bullets.
E.g. on the CLOCC mailing list there has been quite a discussion about
what kind of "novel" features should be included in MK-DEFSYSTEM.
Mainly, some people wanted to include in MK-DEFSYSTEM also a notion of
"version" and have the system take care to "retrieve" the desired
version from the "repository". I am mostly against to this solution
for a number of reasons. Yet the thing did not make it in
MK-DEFSYSTEM (btw. MK-DEFSYSTEM has a form of versioning built-in)
because there was not (yet) agreement on the actual semantics of this
feature. All in all I am saying this because I want to make clear
that I am at the same time open to discussion *and* not willing to
allow unclear features in a system for which I am the caretaker (at
least allow me to exert this right).
> From one data point, you can extrapolate in any direction.
> From one implementation, you can standardize in any direction.
>
> | BTW. I started using MK-DEFSYSTEM because I started working with
> | GCL and CMUCL and then I pretty much went down the road you went.
>
> Then how did we end up so astonishingly far apart?
We are not that far apart. Cosi` vicini, cosi` lontani. ?!? :)
Cheers
marco
Erik Naggum
| MK-DEFSYSTEM comes with good documentation. Would that be a good
| starting point for creating a standard? What kind of work would it
| take to turn that documentation into a useful standard?
Some sort of agreement on (A) what the language implemented by the
system is (a specification), (B) what the language implemented by
the system is not (a scope), (C) what constitues local enhancements
and additions as opposed to basic features (a conformance clause).
Then we would have a good starting point. That we already have one
implementation is not in and by itself a negative. That we have
_only_ one, is. A specifcation must be sufficiently precise to
allow multiple implementations, even with multiple sets of local
enhancements and local features.
I think we need a standard defsystem. I don't think we should use
existing code for that job just because it's there. Therefore, the
questions you ask are very pertinent to the development of a real
standard and real formal agreement.
Mario Frasca
>* Mario Frasca
>| the most irritating ones are of this format
>|
>| Warning: Free reference to undeclared variable *PRECISION* assumed special.
>| This symbol may have been intended: IDEAL::*PRECISION*.
>|
>| most of them don't include the second line.
>|
>| any suggestion on what to do to give the compiler as much information
>| as it needs so that it won't complain any more?
>
as I told you, I'm working on code which has been developed by someone
else. I am trying to have it automatically compiled, but there were
some circular dependencies in the sources, so I had to move some
functions from one file to an other and I have 'announced' the
dependencies in a set of require clauses at the beginning of each
file, so that I can be satisfied of working with these sources.
for some reasons, I don't manage to understand all this apparent
nonsense about the current package, since which is the current package
at a certain point in my sources is not defined statically but
dynamically and I'm not -yet- used to it.
I will make here a list of the problems I encountered:
(eval-when <when> <what>)
I understand what it does, I don't understand how I can use it in a
reasonable way. are there any programming styles which have proven
good practice?
(in-package <pack>)
(require <file>)
these can be used only in an (eval-when) block, otherwise the
compiler will complain. as for the preceding point, I am not sure if
there is any way to have it work without complaints. the programs I
inherited contained the following fragment, which I modified into the
second following fragment, any comments?
>>
(defun ld-sens ()
(load "ideal:sens;sens-menu")
(in-package :sens)
(sens-menu))
<<
>>
(defun ld-sens ()
(load "ideal:sens;sens-menu")
(sens::sens-menu))
<<
(<pack>::<func>)
if I am in the evaluator (interactive session) I can write something
like sens::sens-menu), even if I already am in the sens package. As
far as I could test, this does not work in a (compiled) program. I
also noticed that (in-package <pack>), evaluated when already in
<pack_1>, behaves differently in the interactive session (goes to
<pack>) and in a program (tries to go to <pack_1::pack>.
(import <list>)
I am here just puzzled by the fact that I can use this with more
freedom than (in-package) and (require). I probably see a connection
which is non existing...
now I answer to those references of yours about which language to use
when thinking about a solution. no offence taken, none intended.
references to a language I understand are a means to understand a
language I don't yet know well enough to express the things I want to
express. If I was developing from scratch, I would use those parts of
the language I know, and study the ones I come across as I need them.
having to modify a complex interaction of poorly written sources is as
if you had to modify a bad Albanian text into a good Albanian piece of
poetry, you allow me to think in Italian while studing the subtelties
of that language? thanks.
please, don't speak M$ to me. if you know it, you avoid it.
Mario
Mario Frasca
>The DEFSYSTEM utility is *not* part of CLTL2. You are probably
>referring to the DEFSYSTEM which come with ACL. This is not
>portable.
>
>
> http://sourceforge.net/projects/clocc
I wrote down this reference, thanks.
now I understand why the core program on which the other things were
built (http://www.rpal.rockwell.com/ideal.html) also provides an
*implementation* of defsystem. I did not get it at first. but for the
time being I think I will just stay with it. when I'm done with
correcting dependencies and understanding packages and if I have no
other urgent task -which is quite likely, actually- then I'll have a
serious look at this mk-defsystem.
ciao,
Mario
Marco Antoniotti
ma...@cs.uu.nl (Mario Frasca) writes:
Your problem is more basic. You are not (yet) distinguishing between
READ time and EVALUATION time.
Consider the second DEFUN. When it is READ in by the CL environment
nothing is executed yet. The form is READ in all at once. Now what is
the "reader" doing? It looks at the symbols and tries to make sense
out of them. Now you have (at least) the following cases.
1 - you are in a fresh CL session where the SENS package does not exist.
The reader sees the following symbols in order (it does other
things as well, but let's skip it for the time being):
DEFUN LD-SENS LOAD SENS::SENS-MENU.
Now, DEFUN is looked up in the current package *PACKAGE* (which
most likely is COMMON-LISP-USER), since DEFUN is external in the
COMMON-LISP package (which is used byt the COMMON-LISP-USER
package), it is found and no problems ensue.
LD-SENS is looked up as well in the COMMON-LISP-USER package. It
is not found there and therefore, since it does not have a package
qualifier in front, it is INTERNED in the COMMON-LISP-USER
package. No further problem follow.
SENS::SENS-MENU is different. Because this symbol is qualified
with the SENS:: package qualifier, the CL reader first looks up
the SENS package. It does not find it and it signals an error.
Up to this point the SENS package does not exist.
2 - you are in a long running CL session and somehow you have already
defined the SENS package. Or maybe you are running a "dumped
image" of CL which contains the SENS package.
The reader reads the form, gets to the SENS::SENS-MENU symbol,
finds the SENS package and it is home free.
If you consider the first DEFUN, things work exactly the same in spite
of the presence of the IN-PACKAGE. First the form gest READ in and
then it is available for evaluation.
IN-PACKAGE at the top level of a file is treated specially by the
LOADer. But this is another story.
All in all, you will be better off writing a *separate* package file
with a DEFPACKAGE form in it. The system you are running is
pre-CLtL2, hence people were not used then to do this.
> (<pack>::<func>) <===
> if I am in the evaluator (interactive session) I can write something
> like sens::sens-menu), even if I already am in the sens package. As
> far as I could test, this does not work in a (compiled) program. I
> also noticed that (in-package <pack>), evaluated when already in
> <pack_1>, behaves differently in the interactive session (goes to
> <pack>) and in a program (tries to go to <pack_1::pack>.
First of all, it is not a very good thing to access symbols with the
'::' qualifier. The '::' qualifier (for lack of a better word) is
useful for debugging purposes, but not for programming. If a symbol
is exported use the ':' qualifier.
As far as the "it does not work in a compiled program, see my previous
explanation. I am sure most of your problems lie there.
>
> (import <list>)
> I am here just puzzled by the fact that I can use this with more
> freedom than (in-package) and (require). I probably see a connection
> which is non existing...
>
>
> now I answer to those references of yours about which language to use
> when thinking about a solution. no offence taken, none intended.
>
> references to a language I understand are a means to understand a
> language I don't yet know well enough to express the things I want to
> express. If I was developing from scratch, I would use those parts of
> the language I know, and study the ones I come across as I need them.
> having to modify a complex interaction of poorly written sources is as
> if you had to modify a bad Albanian text into a good Albanian piece of
> poetry, you allow me to think in Italian while studing the subtelties
> of that language? thanks.
Sono a tua disposizione :)
Cheers
Paolo Amoroso
[context: what is required to create a standard]
> Some sort of agreement on (A) what the language implemented by the
> system is (a specification), (B) what the language implemented by
> the system is not (a scope), (C) what constitues local enhancements
> and additions as opposed to basic features (a conformance clause).
I understand (A) and (C), but I fail to get the difference--if any--between
(B) and its implicit definition as a sort of "set complement" of (A) and
(C). Could you elaborate on this?
Erik Naggum
| as I told you, I'm working on code which has been developed by someone
| else. I am trying to have it automatically compiled, but there were
| some circular dependencies in the sources, so I had to move some
| functions from one file to an other and I have 'announced' the
| dependencies in a set of require clauses at the beginning of each
| file, so that I can be satisfied of working with these sources.
The way the system was compiled should be dug up. My hunch is it
was all loaded in as source, and then compiled. You can very easily
do that yourself, and it's much, much easier than what you've been
doing so far.
| for some reasons, I don't manage to understand all this apparent
| nonsense about the current package, since which is the current
| package at a certain point in my sources is not defined statically
| but dynamically and I'm not -yet- used to it.
Well, first you dispense with the opiniated bullshit that it's
"apparent nonsense". To see why, judge how likely it is that you
listen to what I said after I branded your opinion that way first.
If you're really smart, it didn't affect you at all, figuring that I
had my reasons to this very specific incident and that you could
understand them -- the converse is not quite true for your reaction
since it is not specific to anything anyone but you can determine.
You continue to display irrational elements in your behavior towards
the code you're working on. Just what does it take to make you snap
into a more rational approach?
The current package is a read-time concept. When Common Lisp loads
a file, it reads one expression at a time, then evaluates it. If
that expression changes something in the global environment, it is
available for the next expression to use. The in-package macro sets
*package* to the package named by its argument for the duration of
the file as load creates a binding of *package* that is unwound when
the file terminates.
The current package is naturally _also_ a run-time concept, but it
affects only functions that intern symbols in the current package,
among them load and read, in addition to the actual function intern.
If you don't use these functions in your own code, you don't have to
worry about the current package at run-time, as all the symbols you
need were interned at read-time.
Compilation of the files loaded does not alter these facts, as the
file compiler's responsibility is to ensure that the semantics of
loading the file is retained.
| references to a language I understand are a means to understand a
| language I don't yet know well enough to express the things I want
| to express.
How did you learn your first language? Why was that such a lousy
experience that everything must now be done relative to what you
first learned? _If_ it was such a lousy experience, I'm loathe to
believe that you know your first language all that well. If you had
no problems at all learning your first language, why not repeat the
success? Either way, to base learning a new language on old stuff
seems like a plan to lose. Part of learning that first language was
to learn to _think_ in that language. If you don't learn to _think_
in the next language you set out to "learn", you won't ever manage
to get your head around its concepts. That means what is called a
"suspension of disbelief" in reading normal literature, i.e., the
willingness to enter the universe of the book on its own premises.
If you can't do _that_ successfully, you won't ever make a good
programmer in any language.
And how come you had the patience to wait until you did know the
first language well enough before you attempted something, but now
you don't have that patience? Or _didn't_ you have that patience to
begin with? A lot of people don't really possess the tinest shred
of the personal quality of real patience that is required to be good
at _anything_, least of all precision crafts such as programming or,
say, target shooting (which I recently picked up because I run out
of patience with computer programming at times :).
| If I was developing from scratch, I would use those parts of the
| language I know, and study the ones I come across as I need them.
Why is this a bad approach if you are not developing from scratch?
| having to modify a complex interaction of poorly written sources is
| as if you had to modify a bad Albanian text into a good Albanian
| piece of poetry, you allow me to think in Italian while studing the
| subtelties of that language? thanks.
I don't believe you really understand what it means to think in a
programming language, nor have the patience to acquire that skill,
so I'll just give up now.
| please, don't speak M$ to me. if you know it, you avoid it.
I "speak M$" to you? Geez. How the hell is it possible _not_ to do
something wrong to you, Mario Frasca? I don't have the time to
pander to someone whose sensibilities are so erratically tuned and
who displays such a staggering lack of _reqiured_ patience. I would
really suggest you do something other than programming computers.
Mario Frasca
>* ma...@cs.uu.nl (Mario Frasca)
> The way the system was compiled should be dug up. My hunch is it
> was all loaded in as source, and then compiled. You can very easily
> do that yourself, and it's much, much easier than what you've been
> doing so far.
which on evaluation builds up all fasl's from modified sources. it is
working, it did cost some time to have it work, but this is working so
I'm not going to dismantle it.
> Well, first you dispense with the opiniated bullshit that it's
> "apparent nonsense".
Erik, please read what I write before attacking me. I wrote 'apparent
nonsense', not 'pure nonsense', as I don't think it is pure nonsense.
I'm sure there is a sense behind it, but I fail to see it, that is: it
appears as nonsense to me. I can't be more explicit and anyhow, you
did provide me with a (apparently ;) precise description of the
mechanism.
> The current package is a read-time concept. [...]
> The current package is naturally _also_ a run-time concept, [...]
thanks.
> You continue to display irrational elements in your behavior towards
> the code you're working on. Just what does it take to make you snap
> into a more rational approach?
can you display rational thoughts in front of such 'challenging' code:
(defun input-diag-name ()
(setf *i-diag-name*
(input-file-name "~%Enter name of diagram: "
ideal:*default-diag-path-name*))
(initialize-diagram *i-diag-name* *i-evidence*)
(evaluate-diagram)
(format t "~%~A" ideal:*diagram*))
You may think that it is extremely clear what this is doing: outputting
some text, get a string, initialize some data and perform an action on
a diagram. but: is this what would you have expected of a function
named 'input-diag-name? so who tells me that 'initialize-diagram is
not *printing* some output, or that 'evaluate-diagram is not requiring
any user intervention? unfortunately, I didn't need too much
code-digging to find this pearl. there's as many as you need.
probably the only rational action is to do exactly what you said: print
it and trash it. I don't really understand why I should print it
before trashing it, but I guess it is a better personal satisfaction,
possibly similar to what you could experience when burning a self-made
flag of your enemy.
>| If I was developing from scratch, I would use those parts of the
>| language I know, and study the ones I come across as I need them.
>
> Why is this a bad approach if you are not developing from scratch?
who said this is a bad approach? it is just not feasible. excuse me
for being obvious: when I'm not developing from scratch, I have some
sources I have to adjust. these sources contain code. this code uses
parts of a language. that is: 'the decision on which parts of the
language to use was already taken'. in other words, I cannot use those
parts of the language I know and learn others which allow me to express
more complex thoughts, but I have to learn those parts of the language
which were used in the sources. I see a difference here, but maybe I'm
just being pedantic.
you know something, this discussion did produce a good effect: I'm
throwing away the sources I inherited and I'm writing this piece of
software from scratch again. not a big deal: just 72kb of lisp
sources.
Mario
Erik Naggum
| I understand (A) and (C), but I fail to get the difference--if any--between
| (B) and its implicit definition as a sort of "set complement" of (A) and
| (C). Could you elaborate on this?
The purpose of a scope (B) is to make it easier on those of us who
don't think productively in terms of "the whole entire universe of
all possible positions, actions, plans, desires, and desiderata,
except what I said in (A)". Usually, it is important to point out
some of the most important issues that you do not want to address in
order that you can practically and productively exclude discussions
without having to enter another discussion to determine whether they
are part of the negated universe of possibilities. Why did this
need elaboration? Never been to a standards committee? :)
Erik Naggum
| Well, first you dispense with the opiniated bullshit that it's
| "apparent nonsense".
* ma...@cs.uu.nl (Mario Frasca)
| Erik, please read what I write before attacking me.
It's so ironic that you tell me this, because if _you_ can't even
read more than one sentence at a time, you deserve to be attacked.
The next sentence I wrote went:
To see why, judge how likely it is that you listen to what I said
after I branded your opinion that way first.
Because I anticipated some morose response, I wrote this next:
If you're really smart, it didn't affect you at all, figuring that I
had my reasons to this very specific incident and that you could
understand them -- the converse is not quite true for your reaction
since it is not specific to anything anyone but you can determine.
Can you please upgrade from "not really smart" to something like "at
least not really dumb"? Then _maybe_ I'll listen to you. So far,
this has been a waste of my time.
As you decided to label the problems you have "apparent nonsense"
and have continued to display an astonishingly irrational approach
to this whole task, with irritation all over the place, _and_ you
make the _incredibly_ moronic response to an _obvious_ joke at your
expense, there is very little hope for you to pull yourself together
and crank your cranium contents into operation. But surprise me!
| can you display rational thoughts in front of such 'challenging' code:
I have been a "software project firefighter" for 20 years because I
tend to calm down in the face of disaster, danger, and problems that
refuse to submit to any solution. I get really pissed at "small"
things like laziness and incompetence and unfounded assumptions, but
that's because they aren't disasters, they're just sloppiness that
could be prevented if the dickhead perpetrators had paid attention.
I flat out _demand_ that other programmers have some similar traits:
Get all worked up over some minutiae like LOOP or indentation rules
for IF, but calm down, concentrate, focus, and think clearly and
very rationally in the face of actual problems worth solving. If
you can't do that, you have failed my lithmus test for programmers,
but _should_ be smart enough to realize that that means something.
| probably the only rational action is to do exactly what you said:
| print it and trash it.
I actually said "use it for target practice". Which is both much
more violent than trashing it and at the same time much more calming
since you don't want to destroy anything else in the process. It is
obvious that one has to print something out before using it for
target practice, but your stupid rewrite of the joke into "trashing
it" means that the printing out makes absolutely no sense.
| I see a difference here, but maybe I'm just being pedantic.
Yes, and you missed the large print while getting upset over the
small print. Getting upset over the small print means attention to
detail, and that's good. Missing the large print means that your
observational skills and rational approach to prioritizing your
mental processes is sorely lacking, and that's not so good.
To recap (the large print): The technique where you employ more and
more of a language as you grow used to them must _naturally_ be a
good approach even to understanding legacy code, with the _obvious_
advantage that you have a guide to which features to look at next.
| you know something, this discussion did produce a good effect: I'm
| throwing away the sources I inherited and I'm writing this piece of
| software from scratch again. not a big deal: just 72kb of lisp
| sources.
Glad I could help. That is just how I have made most of my money.
I talked to an old friend the other day. He had been unhappy with
the realization that as he got better in his previous job, he was
asked to do more and more "dirty work" and that it thus didn't pay
off to become better. The company he worked for lived off of the
value produced by a 2 million line strong Fortran 77 system that
needed continuous development. And you consider 72K much? It
probably benefits greatly from rewriting in the first place, and the
risk of doing so should be minimal.
Please don't believe that 72K is a lot of code. (72K _lines_ is
getting there, of course.) GNU Emacs 20.7 has 749K lines of C and
Lisp code, some 25M total. The 2.2.17 Linux kernel consists of more
than 2.1 million lines of C code, 64.5M total. A system I wrote
single-handedly (with excellent code review along the way) in four
months consists of 5200 lines (198K) of "infrastructure and support"
code and 2700 lines (104K) of "application" code. This is a _small_
system in my view. I'm _so_ not impressed or sympathetic to your
72K and your plight. Quit whining and go do some real work, now.
#:Erik, who wonders why he bothers with these whining kids
Mario Frasca
a few days ago I wrote you something like 'now I know how to read your
posts'. maybe it is interesting for you to know what I meant by that.
filterErik :: [Sentence] -> [Sentence]
filterEric = filter isTechnical
where filter :: (a -> Bool) -> [a] -> [a]
filter p xs = [ x | x <- xs, p x ]
On 20 Oct 2000 18:24:23 +0000, Erik Naggum <er...@naggum.net> wrote:
> <nothing>
unfortunately, the isTechnical still needs some work at, so I do need
to perform it by hand.
I think the rest of the newsgroup will appreciate if we switch to
private e-mail for our off topic rants.
ciao,
Mario
Erik Naggum
| Followup-To: misc.misc
When you engage in Followup-To wars like this, you show everybody
that you are a useless pest in _any_ forum. How could you think you
could possibly benefit from such moronic behavior? Did you intend
to show me that you really had a working brain? Well, _that_ failed.
| a few days ago I wrote you something like 'now I know how to read your
| posts'. maybe it is interesting for you to know what I meant by that.
No, it is not. People who decide that they have _found_ the answers
they need are braindead and not worth spending any effort on at all.
If your (stupid and even silly) conclusion about "how to read [my]
posts" is now decided and no longer open to evidence, it has itself
become prima facie evidence that you are no longer worth talking to,
because you prove with that methodology and approach that you cease
to listen when what people tell you goes against some property of
your personality. This is what I want people to show me and a small
number of people do not understand that they can do something other
than prove that they are prejudiced, braindead wastes of space
despite very clear signals that the simple act of making up their
mind to discard future evidence is what shows that my commentary on
their lack of thinking skills is _precisely_ to the point.
If they were _not_ complete morons, they would figure out that the
way to change somebody else's mind is to provide them with some
evidence contrary to their current beliefs, but since they do not
themselves change their mind in the face of contrary evidence, this
fantastically simple idea never enters their dysfunctional brain,
thus proving me right. One would have thought that the slightest
bit of intelligence at work would be able to predict the result, but
for some bizarre reason, the idiots who feel the urge to go postal
never acquire the ability to predict behavior that even _dogs_ have.
Let's make a wild guess and assume that you thought something along
these lines: "If I post this phenomenally uninteresting drivel and
direct followups to misc.misc, _then_ I will surely avoid being
attacked for behaving like a moron, because that's the smartest
thing I can possibly do." Am I getting close?
Do you think computer programs can predict what is likely to happen
in that scenario? Just how un-advanced artificial intelligence does
it take to out-predict Mario Frasca? Not a helluva lot, buddy.
| unfortunately, the isTechnical still needs some work at, so I do
| need to perform it by hand.
Amazingly, you managed to post something _intentionally_ devoid of
technical contents while complaining about others. That is pretty
darn funny when you want to prove that you have _nothing_ worthwhile
to say to a forum. Congratulations are in order.
| I think the rest of the newsgroup will appreciate if we switch to
| private e-mail for our off topic rants.
I think everyone would appreciate if you could just try and stop
your off-topic bullshit and get back on track, whatever the hell
that might have been.
#:Erik
Mario Frasca
>* Mario Frasca
>| Followup-To: misc.misc
actually, my first choice was alt.rants, but our newsserver doesn't
provide such a group.
> Did you intend
> to show me that you really had a working brain?
no, I intended to stop this useless sequence of --- undefinable crap.
> Well, _that_ failed.
evidently.
> If your (stupid and even silly) conclusion about "how to read [my]
> posts" is now decided and no longer open to evidence,
I'm always oper to new evidence.
Erik, I was just trying to avoid all of us your useless sequel of
personal insults. I really wonder why you need to do so. I was asking
for some specific help while working on this badly setup software, and
you did manage to give some useful technical help, for which I still
thank you. but you also called me braindead and moron, and you called
the person who developed the software I inherited 'a neanderthal'.
apart from the fact that you don't know either of us, what is the use
of the insult in first place? It doesn't help me doing my job better,
but if it helps you, well, I'm sorry for you.
>| unfortunately, the isTechnical still needs some work at, so I do
>| need to perform it by hand.
>
> Amazingly, you managed to post something _intentionally_ devoid of
> technical contents while complaining about others. That is pretty
> darn funny when you want to prove that you have _nothing_ worthwhile
> to say to a forum. Congratulations are in order.
that was in fact not a good thing. the reason for doing so was: I
don't like being called an idiot in public and not even have the right
to answer before the same public.
by the way, do you mean that most of your posts are not
intentionally devoid of technical contents?
to close this discussion, I hope you allow me to use your words...
they sounded offensive to me, but I'm sure it was just an impression.
"I think everyone would appreciate if you could just try and stop
your off-topic bullshit and get back on track, whatever the hell
that might have been."
Mario
Erik Naggum
| > Did you intend to show me that you really had a working brain?
|
| no, I intended to stop this useless sequence of --- undefinable crap.
What do _you_ call people who do something that even a smidgeon of
applied intelligence would be able to predict would not cause what
they "intended", but rather quite the opposite?
And what's worse of some idiot who _lies_ about his intentions in
order to cast himself as a good guy and some _real_ moron who fails
to predict the obvious results of his actions?
The sad but funny part is that you _would_ have stopped my "useless
sequence of undefinable crap" by showing me that you had a working
brain, but you are quite right: You did _not_ intend to show me that
you have. Hence your _escalating_ idiocy, showing me that you are
about as intelligent as a boxer (take your pick in dogs or brutes).
The only thing that could cause me _not_ to regard you as an idiot
is _counter-evidence_, not some retarded displays of anger on your
part. The question is not whether you like to have your behavior
described as idiotic, but what you do once it happens. If you go on
behaving like an idiot, well, duh. If you get smart and put the
label to shame, I'm to blame, instead. You _choose_ the former.
And _really_, if you don't like insults, stop using them yourself!
It is _really_ idiotic to think you can blame me for your behavior.
| Erik, I was just trying to avoid all of us your useless sequel of
| personal insults.
_Really?_ And now you are arguing that you have not yet figured out
exactly what causes them? What am I supposed to think about you?
| I really wonder why you need to do so.
No need to wonder. You already know everything you need to know.
Just start to _think_. Just start to behave rationally in the face
of something you do not like, such as being called an idiot because
you behave like one or the legacy code you also fail to understand.
The more you choose to "fight back", the worse you're going to lose.
The more you choose to think and respond rationally, the more you're
going to win. If you _want_ to be branded a moron and you _want_
that to stick to your name for a _long_ time, do fight back! If you
resent being called a moron, do something that will cause that label
_not_ to apply to you. This is what applied intelligence is about.
| I was asking for some specific help while working on this badly
| setup software, and you did manage to give some useful technical
| help, for which I still thank you.
Funny way of thanking me, or is _your_ behavior acceptable in your
world when you suddenly have moralistic urgings? You see, it is
obvious from your behavior that you think you can blame me for it.
That is really what ticks me off when it comes to blathering idiots,
and it is, incidentally and interestingly, the same moronic attitude
problem that keeps the peace in the Middle East from having a chance.
| but you also called me braindead and moron, and you called the
| person who developed the software I inherited 'a neanderthal'.
And now that you have been called these things, you do your very
best to prove them right. Why do you do that? Are you unable to
get _yourself_ out of thinking you are an idiot because some random
stranger on the Net called attention to your idiotic behavior?
| apart from the fact that you don't know either of us, what is the
| use of the insult in first place?
You know the answer to this one. You engage in insults yourself,
towards someone you don't know, but you make the idiotic pretense of
thinking you know them and have figured people out. All I want you
to do is to stop playing the sedated moron and crank up whatever is
left in that brain cavity of yours. You probably aren't quite the
moron you enjoy playing so much here, but unless you quit playing
that role, who will ever find out? That you're an enraged little
shit who doesn't know how to pull himself together is certainly a
very important piece of your personality, but there's more to it,
I'm sure, even though your initial reactions to things you don't
understand is to be irritated by them. People who react like that
to their working conditions should _not_ be programmers.
| It doesn't help me doing my job better, but if it helps you, well,
| I'm sorry for you.
Oh, I'm _so_ glad you feel warm and cozy enough with me to come up
this close and try to hug me and all that wonderful emotional crap,
but _could_ you try to keep some personal distance, please?
It has been obvious for a while that you cannot listen to anyone who
does not rub you the right way, and I'm here to ensure that you grow
up and manage to listen to any available information, especially
that which rubs you the wrong way. I don't like little fucks like
you who whine and get irrationally irritated at things you ought to
take a rational, calm approach to, but I still helped you out, did I
not? What is the response I get but _more_ irrational whining from
the little fuck? Cut the crap and get the point, you dimwit!
| that was in fact not a good thing. the reason for doing so was: I
| don't like being called an idiot in public and not even have the
| right to answer before the same public.
You have another option: Don't behave like an idiot when others have
had good _reason_ to call you an idiot because of your behavior.
You don't have to play the macho little fuck who "answers before the
same public". That's so cave man, neanderthal-like behavior, and it
is quite astonishingly unnecessary. You just behave like an adult
human being, fix whatever you think caused the criticism (you _do_
have pretty solid clues, already), and decide that your ego is not
so easily bruised that you have to go ape and want revenge and such.
| by the way, do you mean that most of your posts are not
| intentionally devoid of technical contents?
Funny guy. Try again, be a smart-ass a better way than this.
| to close this discussion, I hope you allow me to use your words...
| they sounded offensive to me, but I'm sure it was just an impression.
To use my words, you need to understand what they were intended to
communicate. You don't. You're just using the words to play a
sickeningly moronic "mirror game" where you think you can just use
words without meaning back at someone. That's such a disgustingly
_non-thinking_ behavior you out to be reprimanded for it.
What did you come here to discuss, Mario Frasca? Your personal
inability to deal with criticism of your behavior? Or did you come
here to get help with your attitude problem and get over that urge
to express your irritation when you could be a rational human being?
Or did you in fact seek help from people whom it would be a _very_
good idea not to insult _while_ you're asking for it?
#:Erik
vsync
> It has been obvious for a while that you cannot listen to anyone who
> does not rub you the right way, and I'm here to ensure that you grow
The irony here is absolutely astounding...
--
vsync
http://quadium.net/ - last updated Sat Oct 7 18:53:10 PDT 2000
(cons (cons (car (cons 'c 'r)) (cdr (cons 'a 'o))) ; Orjner
(cons (cons (car (cons 'n 'c)) (cdr (cons nil 's))) nil))
Erik Naggum
| The irony here is absolutely astounding...
_Again_ you commit the mistake of believing that what you think is
the only possibility is also _actually_ the only possibility just
because that would be convenient for you. Think again. Or think.
You have to pay a lot more attention to detail than you seem able to
do without great effort, "vsync" dude. It's quite annoying to have
some idiot who is clearly unable to deal with more than his own set
of beliefs parade them with so astounding an arrogance. But it is
not for rational men to explain what it would take someone like that
to figure out the difference between "cannot listen to anyone who
does not rub you the right way" to "listens to, then castigates
those who rub you [me] the wrong way"?
A fool who thinks everything he does not understand must be irony,
remains a fool for life.
Mario Frasca
problem so that other persons will be able to avoid my mistakes.
On 12 Oct 2000 09:37:13 GMT, Mario Frasca <ma...@cs.uu.nl> wrote:
>I was playing around with the idea of having my programs checked for
>compilation anytime I start them, and I managed to achieve this by
>using the [Allegro] defsystem utility
as others suggested, this was not a good solution. the Allegro
DEFSYSTEM does work, but the MK:DEFSYSTEM works much better and its
documentation is more than decent. using the latter, you can forget
about REQUIRE and PROVIDE, and consequently also about EVAL-WHEN. when
using the Allegro version, I needed those three more functions. above
all, when I compiled a system, I also had to load it afterwards. this
happens automatically with MK:COMPILE-SYSTEM.
the source for mk:defsystem is available (thanks, Marco) at
https://sourceforge.net/projects/clocc/ and a documentation with
examples can be found at pages 27-44 of the document
http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/
.../lang/lisp/code/tools/mkantdoc.tgz
one extra point I missed and which was causing me problems was about
failing to be consistent on the use of "" and :, in particular when
exporting symbols from a DEFPACKAGE. when enclosed in "", the name is
taken verbatim, with its literal case. when prefixed with ':', I am
actually naming a symbol, and causing its generation in my lisp
session. unless I also use ||, the symbol is in UPPER case. what I
was doing was defining the function MENU (the transition to upper case
was done by lisp) and exporting "menu", where no transition to upper
case happens.
I'm sure others on this newsgroup can be more precise than me.
thanks to all who helped
Mario