In Smalltalk if I want a list of all existing instances of a class, I can use
"classname allInstances" to get such a list. What is the equvialent in Lisp?
>>>>> On Sat, 16 Jun 2001 20:36:49 GMT, lispnewbie ("lispnewbie") writes:
lispnewbie> In Smalltalk if I want a list of all existing instances of a class, I can use
lispnewbie> "classname allInstances" to get such a list. What is the equvialent in Lisp?
Common Lisp doesn't have an operator to do that.
Can you tell more about how you would use such an operator?
I know where all my instances are because they are connected to some
other data structure. In the simplist case, I might have placed them
into a list. If you really wanted a global list of all instances of
some class, you could write about two lines of code (an :AFTER method
on INITIALIZE-INSTANCE) to record the instance in some list.
On Sat, 16 Jun 2001 21:42:21 GMT, Christopher Stacy
<······@spacy.Boston.MA.US> wrote:
>into a list. If you really wanted a global list of all instances of
>some class, you could write about two lines of code (an :AFTER method
>on INITIALIZE-INSTANCE) to record the instance in some list.
As an example of how I would use it in Smalltalk, suppose I have a number of
Smalltalk processes running, and because of some bug in my code, lose control
of one of them, and can no longer find it. In Smalltalk I can terminate the
process by first using "Process allInstances inspect" to find it, and then
invoking its termination function. The same kind of thing is useful for a
lot of different kinds of objects, not just processes. Of course
allInstances is not very fast, so it should only be used in unusual
situations such as debugging. But it's very handy in those situations.
Suppose I'm a Lisp newbie and don't know what a package is, and want a list
of loaded packages so I can get a clue about packages by recognizing some of
the names in the list. In Smalltalk I could ask the class browser to find
all classes whose names have "package" or "pkg" in them, then I could inspect
all instances of those classes. That kind of thing is what makes Smalltalk
so easy to learn. Anything you don't understand, you can find the answer
quickly by using Smalltalk's extremely powerful browsing and inspection
facilities. Of course Lisp has special variables containing lists of
packages, etc., but you can't expect a newbie to know that, or to know what
special variables to look at.
By the way, is there an easy way to get a list of all special variables?
What would the objects in the list be? Is a variable an object you can put
in a list? Or can you only put its contents in a list? Or maybe a list of
all special variables would just be a list of their names?
And how would I go about iterating through all existing objects? Would it be
a nightmare to attempt such a thing? How would I avoid conflicts with the
objects created by the iteration?
Obviously your way, of using :after etc., would be a lot better and more
efficient, if the purpose was to build this kind of facility into some code.
But I'm looking at this from a debugging, browsing, and learning point of
view. How to make simple but powerful tools that can be used for finding all
kinds of answers, like in Smalltalk, without having previous exposure to the
code and objects you want to debug or browse or learn about.
··········@questions.com writes:
> Suppose I'm a Lisp newbie and don't know what a package is, and want a list
> of loaded packages so I can get a clue about packages by recognizing some of
> the names in the list.
(list-all-packages) !
Regards,
Peter
>>>>> On Sat, 16 Jun 2001 22:42:30 GMT, lispnewbie ("lispnewbie") writes:
lispnewbie> That kind of thing is what makes Smalltalk so easy to learn.
Let me sum up the answer to your questions by just answering that one.
Answer: Guess what language Smalltalk got all those ideas from?
You can do all the exploratory and debugging things in Lisp that you are
used to in Smalltalk, and more. You don't do them all the same way.
Most of the rest of your message does not make very much sense --
wondering what a variable is and so forth -- so I'd suggest that
you get a book on Lisp and learn a little bit about the language.
Then come back and ask the questions that still puzzle you.
As worded, your current questions almost seem like a troll!
lispnewbie> And how would I go about iterating through all existing objects?
That would not be a particularly meaningful operation.
On Sun, 17 Jun 2001 10:38:40 GMT, Christopher Stacy
<······@spacy.Boston.MA.US> wrote:
> lispnewbie> And how would I go about iterating through all existing objects?
>
>That would not be a particularly meaningful operation.
For example, to find a "lost" object. I might have only vague knowledge of a
particular object, and might want to inspect it to learn more about it. It
would be handy to be able to iterate through all objects to find those that
match a pattern, which might represent the vague knowledge I have of the
object I'm looking for.
You might be thinking of small and medium sized projects done by one person,
such that it's easy to keep track of all the details. But I'm used to
working on very large projects, where I have to understand the work of large
numbers of other programmers. Such work is often poorly documented, and best
understood by browsing and inspecting the running code and objects. I might
have no idea where to look among megabytes of source code for a particular
bug, but might be able to find it fast by browsing and inspecting various
objects related to it.
··········@questions.com writes:
> On Sun, 17 Jun 2001 10:38:40 GMT, Christopher Stacy
> <······@spacy.Boston.MA.US> wrote:
>
> > lispnewbie> And how would I go about iterating through all
> > lispnewbie> existing objects?
> >
> > That would not be a particularly meaningful operation.
>
> For example, to find a "lost" object. I might have only vague knowledge of a
> particular object, and might want to inspect it to learn more about it. It
> would be handy to be able to iterate through all objects to find those that
> match a pattern, which might represent the vague knowledge I have of the
> object I'm looking for.
It might be very handy, but it might be extraordinarily expensive.
You either have to maintain a table of such things (which potentially
interferes with the GC's ability to collect them, and certainly adds
bloat to your running image) or else you have to assume the system is
marking the objects with enough state to find them again (which
probably internally any Lisp system is, since the GC needs this to
run) but you ALSO in that case have to touch and page-in every page in
the Lisp system, and that can be very disk-intensive in some systems,
slowing your system to a crawl. It might be a useful debugging operation,
and if you have a support contract with your vendor, you might ask for it;
maybe they can write it for you--I bet mostly it's not a lot of work. But
as a LANGUAGE feature, it's DANGEROUS becuase if at arbitrary points in a
user program you did this, you would basically touch all memory and that
would be bad. Of course, there's a third case and that's that you identify
which classes you will programmatically need to track all instances of and
just for those classes you keep track of the instances. But if you have
such foreknowledge, you can already do that by doing:
(defvar *foo-instances* '())
(defmethod initialize-instance :after ((foo foo) &key)
(push foo *foo-instances*))
> You might be thinking of small and medium sized projects done by one person,
> such that it's easy to keep track of all the details. But I'm used to
> working on very large projects, where I have to understand the work of large
> numbers of other programmers. Such work is often poorly documented, and best
> understood by browsing and inspecting the running code and objects. I might
> have no idea where to look among megabytes of source code for a particular
> bug, but might be able to find it fast by browsing and inspecting various
> objects related to it.
Here you are talking system-level questions, and this is an issue best left
to the system vendor. It is generally agreed in our community that the
language is about the commonality between all vendors, and is about the code
we write in files, whereas the system is vendor-specific and is about the
speed/quality/debuggability/productivity-yield that individual vendors offer
in order to be competitive. There is no single right answer to this.
The market will and does sort this out. If you are paying a vendor for
support, they will surely listen to your issues. If you are not, then you
are not likely to be viewed as a very serious "part of the market". Your
comments are still heard, but are not likely to be acted upon individually.
··········@questions.com writes:
> For example, to find a "lost" object. I might have only vague knowledge of a
> particular object, and might want to inspect it to learn more about it. It
> would be handy to be able to iterate through all objects to find those that
> match a pattern, which might represent the vague knowledge I have of the
> object I'm looking for.
>
> You might be thinking of small and medium sized projects done by one person,
> such that it's easy to keep track of all the details. But I'm used to
> working on very large projects, where I have to understand the work of large
> numbers of other programmers. Such work is often poorly documented, and best
> understood by browsing and inspecting the running code and objects. I might
> have no idea where to look among megabytes of source code for a particular
> bug, but might be able to find it fast by browsing and inspecting various
> objects related to it.
I suspect you should be able to get (most of) what you want by using some
combinations of INSPECT, DESCRIBE, APROPOS, DOCUMENTATION, together with
WITH-PACKAGE-ITERATOR, DO-SYMBOLS, etc. Also somewhat related, most CLOS
implementations provide CLASS-DIRECT-SUBCLASSES and stuff, from which you
can extract the hierarchy by doing a breadth-first-search starting from
STANDARD-CLASS.
For example, the following kludge works for CMUCL (assuming some value of
"works" which nonetheless should be adequate for explorative purposes):
(defun unreliably-list-special-variables-in-package (package)
(do-symbols (sym package)
(when (search "special variable"
(with-output-to-string (*standard-output*)
(describe sym)))
(print sym))))
(unreliably-list-special-variables-in-package *package*)
=>
*BLOCK-COMPILE-DEFAULT*
*INLINE-EXPANSION-LIMIT*
*BEFORE-SAVE-INITIALIZATIONS*
*EFFICIENCY-NOTE-COST-THRESHOLD*
...
;;; -- huaiyuan
* Huaiyuan <········@rac5.wam.umd.edu>
> For example, the following kludge works for CMUCL (assuming some value of
> "works" which nonetheless should be adequate for explorative purposes):
>
> (defun unreliably-list-special-variables-in-package (package)
> (do-symbols (sym package)
> (when (search "special variable"
> (with-output-to-string (*standard-output*)
> (describe sym)))
> (print sym))))
You may not be aware of this, but this uses an implementation-dependent
feature that clearly depends on some other feature that you should have
investigated and used instead of letting describe use it for you. I get
this Perl feeling from your example: It is easier to parse textual output
from some useful function to look for some random text string you think
will return all true positive and no true negative than to go look for
the real answer. Yecch! Here's a trivial example that shows you what
kind of bad Perl solution you came up with:
* (setq *top-level-auto-declare* nil)
NIL
* (setq foobar-random-noise '("this is not a special variable"))
Warning: This variable is undefined:
FOOBAR-RANDOM-NOISE
("this is not a special variable")
* (describe 'foobar-random-noise)
FOOBAR-RANDOM-NOISE is an internal symbol in the COMMON-LISP-USER package.
It is a undefined variable; its value is ("this is not a special variable").
("this is not a special variable") is a CONS.
In CMUCL, the function walker:variable-globally-special-p takes a symbol
and returns true if it is globally declared special.
In Allegro CL, the function excl::variable-special-p does the same, but
needs an environment, too. nil is the global environment, as usual.
#:Erik
--
Travel is a meat thing.
Erik Naggum <····@naggum.net> writes:
> * Huaiyuan <········@rac5.wam.umd.edu>
> > For example, the following kludge works for CMUCL (assuming some value of
> > "works" which nonetheless should be adequate for explorative purposes):
> >
> > (defun unreliably-list-special-variables-in-package (package)
> > (do-symbols (sym package)
> > (when (search "special variable"
> > (with-output-to-string (*standard-output*)
> > (describe sym)))
> > (print sym))))
>
> You may not be aware of this, but this uses an implementation-dependent
> feature that clearly depends on some other feature that you should have
> investigated and used instead of letting describe use it for you. I get
> this Perl feeling from your example: It is easier to parse textual output
> from some useful function to look for some random text string you think
> will return all true positive and no true negative than to go look for
> the real answer. Yecch! Here's a trivial example that shows you what
> kind of bad Perl solution you came up with:
[example elided.]
Ouch! [374KB of to-be written text presenting a pseudo-philosophical
argument masquerading my feeble after-blunder face-saving attempt elided.]
... But at the end, I have to agree with you that I was being sloppy. I
should have known better and used (APROPOS "SPECIAL-P") instead of settling
on a non-solution.
Hmm..., or should I? That is to suppose I knew "SPECIAL-P" was a hopeful
candidate text string to be presented in the function-name I was looking
for. I'd think "SPECIAL-P" is surely no less random than "special
variable" when looking for something about special variable? Before
someone makes public his/her implementation of SEMANTIC-APROPOS or
WITH-TELEPATHY, we still can't escape entirely from a little bit of
Perlism, it seems.
If there are better ways to handle this kind of things, pray tell. Thanks!
- huaiyuan
> Ouch! [374KB of to-be written text presenting a pseudo-philosophical
> argument masquerading my feeble after-blunder face-saving attempt elided.]
> ... But at the end, I have to agree with you that I was being sloppy. I
> should have known better and used (APROPOS "SPECIAL-P") instead of settling
> on a non-solution.
> Hmm..., or should I? That is to suppose I knew "SPECIAL-P" was a hopeful
> candidate text string to be presented in the function-name I was looking
> for. I'd think "SPECIAL-P" is surely no less random than "special
> variable" when looking for something about special variable? Before
> someone makes public his/her implementation of SEMANTIC-APROPOS or
> WITH-TELEPATHY, we still can't escape entirely from a little bit of
> Perlism, it seems.
> If there are better ways to handle this kind of things, pray tell. Thanks!
Somebody else pointed it out already, but I decided to reiterate.
CLtL2 has a variable-information function defined, which can tell you
if a given variable has a special binding. CLtL2 lists that X3J13
added that as part of SYNTACTIC-ENVIRONMENT-ACCESS:SMALL (Jun89), and
the HyperSpec notes that it was retracted Mar91, and gives no
discussion. Perhaps somebody could fill in the blanks on what
happened.
joelh
Joel Ray Holveck <·····@juniper.net> writes:
> Somebody else pointed it out already, but I decided to reiterate.
> CLtL2 has a variable-information function defined, which can tell you
> if a given variable has a special binding. CLtL2 lists that X3J13
> added that as part of SYNTACTIC-ENVIRONMENT-ACCESS:SMALL (Jun89), and
> the HyperSpec notes that it was retracted Mar91, and gives no
> discussion. Perhaps somebody could fill in the blanks on what
> happened.
Sure. The problem was similar to what occurred with the MOP. It's
nice to write words that say "this is how it works" but it's even
better when those words are true.
In the case of the MOP, AMOP (Gregor's document) describes what a
number of implementations do (mostly either those that descend from
PCL or those that set out to implement AMOP from the start), but it
didn't describe what implementations that have CLOS in general do.
That is, there are other ways of implementing CLOS than going through
the MOP, so standardizing on the MOP meant a big burden of
implementation for some vendors and risked that some vendors basically
could not claim conformance to the result.
In the case of the syntactic enviroment access stuff, the issue was
that some implementations really used an ENV argument internally and kept
the macro expansion environment in there and others used compiler dynamic
state. Of course, you could just have an implementation like
(defclass compiler-env () ())
(defmethod get-meth1-state ((env compiler-env)) *meth1-state*)
(defmethod get-meth2-state ((env compiler-env)) *meth2-state*)
...
and it would mostly look like environments were real objects when secretly
they were not. But when people closed over them and returned the env argument
to elsewhere, the lie would be exposed. So implementors tried to get more
and more of the state into their environments but it wasn't all easy.
Then to compound it, people started to use the interface we defined had
lots of detailed holes because really no one had ever defined such an
interface. The best standards come from taking existing practice of use and
defining it to be standard, not from making up wished-for functionality
out of whole cloth and hoping it will stand up. Bug after bug was found
in the way we defined stuff for CLTL2, and finally the people who were its
strongest advocates reluctantly suggested pulling the whole thing rather than
standardizing it in some broken form, which they feared would be worse.
The hope had been, and I guess still is, that vendors would proceed to
use and clarify the CLTL2 substrate in some way until things really did work
that way and then we could go ahead with a future standard. It doesn't
seem to have gone quite that way.
Kent M Pitman <······@world.std.com> wrote:
> Joel Ray Holveck <·····@juniper.net> writes:
>
> > CLtL2 lists that X3J13 added [VARIABLE-INFORMATION] as part of
> > SYNTACTIC-ENVIRONMENT-ACCESS:SMALL (Jun89), and the HyperSpec notes that
> > it was retracted Mar91, and gives no discussion.
> [..snip..]
>
> Then to compound it, people started to use the interface we defined had
> lots of detailed holes because really no one had ever defined such an
> interface. [...] Bug after bug was found in the way we defined stuff for
> CLTL2,
Off hand does anyone know if there's a summary, or other record, of
these bugs and holes somewhere? The reason being that some
implementations (e.g. MCL, LispWorks) still provide these functions, so
it would be useful to know the potential pitfalls (beyond
non-portabilty) prior to use.
Thanks.
--
Duncan Harvey
"Smiling and waving. Before letting himself fall."
-- Anja Garbarek, The Diver
Huaiyuan <········@rac5.wam.umd.edu> writes:
[snip]
> For example, the following kludge works for CMUCL (assuming some value of
> "works" which nonetheless should be adequate for explorative purposes):
>
> (defun unreliably-list-special-variables-in-package (package)
> (do-symbols (sym package)
> (when (search "special variable"
> (with-output-to-string (*standard-output*)
> (describe sym)))
> (print sym))))
>
> (unreliably-list-special-variables-in-package *package*)
>
> =>
> *BLOCK-COMPILE-DEFAULT*
> *INLINE-EXPANSION-LIMIT*
> *BEFORE-SAVE-INITIALIZATIONS*
> *EFFICIENCY-NOTE-COST-THRESHOLD*
> ...
>
> ;;; -- huaiyuan
In LispWorks the code above fails to work (and rightly so.) However
the following version works fine.
(defun unreliably-list-special-variables-in-package (package)
(do-symbols (sym package)
(when (not (search "#<unbound value>"
(with-output-to-string (*standard-output*)
(describe sym))))
(print sym))))
But wouldn't it be better to do this instead?
(defun reliably-list-special-variables-in-package (package)
(do-symbols (sym package)
(when (boundp sym)
(print sym))))
This version is about 7.5 times faster than the first, not that it
matters for "explorative purposes."
--
Peter
Peter Buchlovsky <·······@cs.bham.ac.uk> writes:
[snip]
> In LispWorks the code above fails to work (and rightly so.) However
> the following version works fine.
>
> (defun unreliably-list-special-variables-in-package (package)
> (do-symbols (sym package)
> (when (not (search "#<unbound value>"
> (with-output-to-string (*standard-output*)
> (describe sym))))
> (print sym))))
>
> But wouldn't it be better to do this instead?
>
> (defun reliably-list-special-variables-in-package (package)
> (do-symbols (sym package)
> (when (boundp sym)
> (print sym))))
>
> This version is about 7.5 times faster than the first, not that it
> matters for "explorative purposes."
I later realised that this is wrong (read: complete rubbish) so I
apologise if it confused anyone. (It is most likely that I am the only
one who is confused around here.)
It appears that LispWorks' describe doesn't say whether a variable is
special or not. I followed Erik Naggum's suggestion and found
WALKER:VARIABLE-SPECIAL-P but it didn't work for me.
CL-USER 114 > (defvar *foobar* "This is a special variable.")
*FOOBAR*
CL-USER 115 > (walker:variable-special-p '*foobar* nil)
NIL
--
Peter
Peter Buchlovsky <·······@cs.bham.ac.uk> writes:
> It appears that LispWorks' describe doesn't say whether a variable is
> special or not. I followed Erik Naggum's suggestion and found
> WALKER:VARIABLE-SPECIAL-P but it didn't work for me.
I don't know what that is, but LW has an implementation of the CLtL2
environment query functions (chapter 8.5,
<http://www.supelec.fr/docs/cltl/clm/node102.html#SECTION001250000000000000000>
), so you can test for specialness directly:
(defun reliably-list-special-variables-in-package (package)
(do-symbols (sym package)
(when (eq (variable-information sym) :special)
(print sym))))
--
Pekka P. Pirinen
Global Graphics Software (incorporating Harlequin and Jaws)
The great problem with Lisp is that it is just good enough to keep us
from developing something really good. - Alan Kay
* ··········@questions.com
> For example, to find a "lost" object.
Common Lisp features a garbage collector. If there is no way you can
reference an object, it does not matter whether it exists (in memory) or
not. Consequently, it saves on memory consumption to (re)use the space
used by objects that people have "lost" for something they have not lost.
If the system hangs on to objects after you lost them, there is probabl a
very good reason for that, and an accompanying mechanism to delete those
objects. Otherwise, there is no way you can both lose it and fint it. I
wouls guess that only a few kinds of objects satisfy this condition, such
as processes, streams, packages, symbols, etc. In fact, all operating
system resources _should_ satisfy this condition, but they do not always
do so. E.g., streams usually reflect a scarce system resource that you
really want to be able to recover and your Common Lisp system should have
a way to go from system resource to high-level resource, such as from a
file descriptor to a stream. This particular mapping is astonishingly
simple to accomplish and it is a shame that it needs to be done manually.
> I might have only vague knowledge of a particular object, and might want
> to inspect it to learn more about it. It would be handy to be able to
> iterate through all objects to find those that match a pattern, which
> might represent the vague knowledge I have of the object I'm looking for.
Then it would serve your purposes much better to learn how to find
objects that might satisfy your needs than to find all objects in order
to test them to satisfy your needs. From what you keep telling me about
SmallTalk, it seems like a seriously misdesigned language when it lets
people rummage around the garbage to find something or other that may or
may not have been "lost". However, since I do not consider SmallTalk
misdesigned, I instead consider your usage of these features _abusive_.
Similar abuse may of course be accomplished in Common Lisp. The garbage
collector will necessarily know about all (live) objects, and you may ask
it nicely to return a list of all of them -- it necessarily has a way to
reference all objects independently of all other references. In Allegro
CL, you do that with the function (excl::get-objects <object-type-id>).
Evaluate (room t) to see which object types and ids are available.
> You might be thinking of small and medium sized projects done by one
> person, such that it's easy to keep track of all the details. But I'm
> used to working on very large projects, where I have to understand the
> work of large numbers of other programmers. Such work is often poorly
> documented, and best understood by browsing and inspecting the running
> code and objects. I might have no idea where to look among megabytes of
> source code for a particular bug, but might be able to find it fast by
> browsing and inspecting various objects related to it.
This leads me to believe that the existence of the features you want
encourage the abuse you have described and apparently consider a plus,
while I hold the view that if certain things are harder to do than
others, people will do other things to avoid the hardest part of the job.
In a nutshell: If it is harder to document than to browse, people will
browse, but if it is harder to browse than to document, people will
document. Programming languages are all about built-in convenience. In
a twisted form, the Sapir-Whorff hypothesis, that languages shape the way
we think, applies because of sheer laziness and/or intelligent use of
resources (the two frequently coincide).
Incidentally, there is the function apropos, and some Common Lisps even
feature an apropos-regexp function for those who think regexps are cool.
#:Erik
--
Travel is a meat thing.
On Sun, 17 Jun 2001 23:21:31 GMT, Erik Naggum <····@naggum.net> wrote:
> Common Lisp features a garbage collector. If there is no way you can
By a lost object I don't mean unreferenced, but just that I don't know where
to look for it.
> SmallTalk, it seems like a seriously misdesigned language when it lets
> people rummage around the garbage to find something or other that may or
> may not have been "lost". However, since I do not consider SmallTalk
> misdesigned, I instead consider your usage of these features _abusive_.
"Classname allInstances" is a safe, consistent, and useful feature of
Smalltalk. It doesn't rummage around in garbage. It only finds live
objects. It typically takes a fraction of a second, and is only used at the
top level, for purposes such as exploring and debugging. I might for example
use "Process allInstances size" to see how many processes currently exist in
the Smalltalk image, or "MyWindowClass allInstances select: #isHidden" to see
any hidden windows I might have, or even "Metaclass allInstances size" to see
how many classes are in the class library. None of those queries are abuse
of any kind. They just mostly satisfy idle curiosity, but in some cases can
save a lot of debugging time or learning time.
>>>>> "lispnewbie" == lispnewbie <··········@questions.com> writes:
lispnewbie> By a lost object I don't mean unreferenced, but just that
lispnewbie> I don't know where to look for it.
That is, perhaps, one of the most mysterious things I've ever read in
any post. What are you talking about?
The *only* situation I can possibly see what you're saying as
feasible is if you sat down at some elses Lisp prompt after they
loaded code that you never saw. You can use the describe, inspect,
list-all-packages, etc. to see what's around, and maybe even get lucky
with function-lambda-list and function-lambda-expression. But, if
it's _your_ program, then I think your question is absurd. *YOU'RE*
the one writing the program.
dave
David Bakhash <·····@alum.mit.edu> writes:
>
> >>>>> "lispnewbie" == lispnewbie <··········@questions.com> writes:
>
> lispnewbie> By a lost object I don't mean unreferenced, but just that
> lispnewbie> I don't know where to look for it.
>
> That is, perhaps, one of the most mysterious things I've ever read in
> any post. What are you talking about?
>
> The *only* situation I can possibly see what you're saying as
> feasible is if you sat down at some elses Lisp prompt after they
> loaded code that you never saw. You can use the describe, inspect,
> list-all-packages, etc. to see what's around, and maybe even get lucky
> with function-lambda-list and function-lambda-expression. But, if
> it's _your_ program, then I think your question is absurd. *YOU'RE*
> the one writing the program.
I think the thing he's saying is that a piece of code is like a Rubik's
cube. Ignoring the obvious reading order, which must double as a load
order and might or might not be a good learning order, any given page
might be the front page, with all other pages secondary. I wrote a code
browser of this kind in a hypertext system I made back in the early 80's
(pre-www). Even in the www itself, the page you view in focus seems
"the front page" and everything else is a cross-reference.
In this context, I believe what he's saying is that he's chosen a front
page but has no foothold into an instance from which to begin inspecting.
This used to be a problem on the Lisp Machine, and the answer was to go
into Peek to get a plausible thing to root from. Usually a window or a
file stream would do. Sometimes one would force a keyboard interrupt on
a frame to get a debugger and then do (inspect *terminal-io*).
In this regard, I would say that "all instances" is no more the criterial
thing than anything else. Just a way of getting a root. I think being
able to inspect a function and be able to click on its closed contents
may work as well. And also, many systems with multiprocessing systems also
provide the equivalent of Genera's "Peek". I know LispWorks has a process
browser and a windows browser and a half dozen other browsers which
collectively do the same kind of thing, for example.
I think in the context of the "foothold for inspect problem", there is a
real issue here. But describing the problem as "absence of an all-instances
capability" probably was not an articulate way of describing the need.
··········@questions.com writes:
> "Classname allInstances" is a safe, consistent, and useful feature of
> Smalltalk. It doesn't rummage around in garbage. It only finds live
> objects. It typically takes a fraction of a second, and is only used at the
> top level, for purposes such as exploring and debugging.
"used at top level" = "system command", not "language support".
Although we briefly dabbled, as a community, with specifying large amounts
of required tools structure in the language, we have moved away from requiring
that because too often it placed unnecessary implementation burdens on vendors,
some of which have been quite commercially costly. Whether or not this one
would be is tricky to say, but it's a fair bet that if it were program
callable some vendor would object, and if it's not program callable, that's the
line we defined for where the language definition should keep out of the
vendor's hair.
Common Lisp does have a fixed amount of language baggage that we have not
removed for historical reasons, although even there there is pressure to
do so. In general, I think the right way to say it is that it's being
gradually phased out of the language.
That is NOT to say that it not useful to have such support, but RATHER
to say that it is just inappropriate to a LANGUAGE specification.
We've largely decided that this is stuff a vendor should provide so
that the vendor can control documentation on how to use it, and so
that the vendor can assure that support for it is reliably removed
from the image for delivery, where appropriate, and most of all so that
the vendor can decide that the implementation constraints imposed are not
onerous.
For example, the common lisp function ED will try to edit a function's
definition, but not all implementations will find that it's worth the
storage to hold onto the location of the function definition. In some
implementations this is extremely handy, while in other implementations
utterly useless. And worse, its presence in those implementations where it
is useful makes it problematic to remove when applications are delivered.
Also, though I don't doubt your experience is that it takes a fraction of
a second to do these things, I'm quite ssure that places a heavy constraint
on an implementation to implement certain aspects of the system in certain
ways EVEN AFTER the support has been removed for delivery. Our experience
in Lisp systems is that such constraints are best evaluated by individual
vendors; those that find it serves their user base are absolutely encouraged
to provide them, but those that find it doesn't serve theirs are not required
to go that direction.
I can tell you for sure there are Lisp systems in which walking virtual
memory to find an object of a given class would take a LOT longer than
a fraction of a second. Our requiring a command of the kind you ask for
might force such implementations to revise their storage layout in order
to not be embarrassing for this test you want, yet this test might not be
used very often in practice, and the systems that were revised to make this
fast might lose important optimizations that were less visible to newbies
and more visible to veterans. These are questiosn best left to vendors.
> I might for example
> use "Process allInstances size" to see how many processes currently exist in
> the Smalltalk image, or "MyWindowClass allInstances select: #isHidden" to see
> any hidden windows I might have, or even "Metaclass allInstances size" to see
> how many classes are in the class library. None of those queries are abuse
> of any kind. They just mostly satisfy idle curiosity, but in some cases can
> save a lot of debugging time or learning time.
Idle curiosity can be a powerful thing.
But idly assuming that an implementation is broken for not providing you
this can be an inadvertently powerful thing, too.
You get nothing in the world for free. Everything is a trade-off.
This is one trade-off best left to vendors, who each economically
feel the effect of making it (or not) in their own way.
* ··········@questions.com
> By a lost object I don't mean unreferenced, but just that I don't know
> where to look for it.
Sigh. Then it is not the object that is lost, it is you. It is wrong to
solve that problem in programming languages.
> "Classname allInstances" is a safe, consistent, and useful feature of
> Smalltalk.
So you have made it clear that you think. I happen to disagree, based on
the way you tell us that you use it. Incidentally, I use the same kind
of function in Allegro CL, which I had hoped you would understand, but I
consider it about as "safe and consistent" as that trick I did with
changing the type information between bignum and bit vector. I know how
to do both safely and without destroying anything, but the fact that you
can get at _any_ object and meddle with it even if it was intended to be
captured in such a way that code optimizers and all users expected a very
consistent object between invocations does _not_ constitute "safe" to me.
> It doesn't rummage around in garbage. It only finds live objects.
So does the garbage collector. Please excuse the expression, which was
intended to impart to you that you are using a feature that is
necessarily looking for objects via a different mechanism than one
usually _wants_ to use, and which is essentially the same as the garbage
collector, namely that of following internal object chains or allocation
patterns. Any other implementation of allInstances is really wasteful,
but this _is_ the domain of the allocator (and garbage collector).
(Maybe you do not understand what the garbage collector does, yet, and
that is perfectl OK, but then you must not act as if you do, either.)
> It typically takes a fraction of a second, and is only used at the top
> level, for purposes such as exploring and debugging.
If it is a safe, consistent and useful feature of SmallTalk, I _expect_
people to use it in very different ways than it was "intended". That is
why it is a bad idea to publish such interfaces to the memory subsystem.
> They just mostly satisfy idle curiosity, but in some cases can save a lot
> of debugging time or learning time.
Yes, sure, but my argument was actually that by so doing, you are not
encouraged to write better code or learn by more efficient means. I see
that you completely ignored this argument, and so my first hunch that it
would be a waste of time to respond to you was probably correct.
#:Erik
--
Travel is a meat thing.
"Erik Naggum" <····@naggum.net> wrote in message ·····················@naggum.net...
>
> > They just mostly satisfy idle curiosity, but in some cases can save a lot
> > of debugging time or learning time.
>
> Yes, sure, but my argument was actually that by so doing, you are not
> encouraged to write better code or learn by more efficient means. I see
> that you completely ignored this argument, and so my first hunch that it
> would be a waste of time to respond to you was probably correct.
>
I must be missing the point then. Wasn't MOP designed, in part,to
provide information about the specifics of an application for the
purpose of allowing greater understanding of it's inner workings?
I think the ability to query a system to find out what it's current
state it's in directly, instead of looking at source and making an
educated guess, is a good thing. Especially on a large project where
the majority of work has been done by other people before your
inclusion. As a bad analogy, it's usually easier to fix a piece of
machinery if you've examined one while it was working.
Geoff
* "Geoff Summerhayes" <·············@hNoOtSmPaAiMl.com>
> I must be missing the point then.
Most probably. I am unable to reconnect what have been talking about
with your argument.
> Wasn't MOP designed, in part,to provide information about the specifics
> of an application for the purpose of allowing greater understanding of
> it's inner workings?
That is so not the point. Yes, wonderful tools exist to further both
introspection in a system and learning and understanding in its users.
Some of these tools actually make possible both thinking and solutions
that would have been impossible to predict before it was deployed. That
is the mark of a truly good idea. However, all good ideas can be carried
too far and turn into _very_ bad ideas. E.g., the idea that members of a
family pool their efforts and their earning so that the whole family can
prosper as a result is a good idea, because of the preexisting commitment
among the family members to the family. Doing exactly the same thing for
a country of a hundred million people is not a good idea because there is
no commitment from a citizen to a country on that scale.
> I think the ability to query a system to find out what it's current state
> it's in directly, instead of looking at source and making an educated
> guess, is a good thing.
I suggest that you look at the conditions that make it a good thing and
see if you can find ways that some or all of those conditions can fail to
be met with disastrous results. So far, all you have done is show us
that you can think of positive consequences of having those conditions
met. That is, frankly, utterly uninteresting. We all agree that all of
this stuff has useful aspects. _Nobody_ is arguing against these things.
I am, however, arguing against the standard implementation of a _specific_
feature that has more negative aspects to it than positive because the
conditions that are usually met by introspective functions are _not_ met
by this particular feature. Somewhere along the line, I think you managed
to conclude the general from the specific, when the general was already
taken for granted, and argue for the specific based on arguments for the
general. Both of which as disastrous logical fallacies. I have a hard
time even coming to grips with the proportion of such an invalid argument.
It is virtually a textbook example of how _not_ to argue for something.
We have been told that this allInstances feature is great _because_ of
the lack of documentation in large systems. I know, from experience,
that that documentation is lacking _because_ of the availability of
features that obviate the need for proper documentation. Thus, a feature
that is "good" has very, very bad consequences because it turns people
who are resource-conscious into worse programmers when they _know_ that
whoever has to deal with their code is probably going to skip reading the
documentation when they have that tool, too, so they never bother to write
it in the first place, in a wonderful process of proving themselves right:
Of course they didn't read the non-existing documentation before they used
the allInstances trick to discover the information they were looking for!
Please think things through, do not stop thinking just because of the sexy
surface appeal of something.
#:Erik
--
Travel is a meat thing.
"Erik Naggum" <····@naggum.net> wrote in message ·····················@naggum.net...
> * "Geoff Summerhayes" <·············@hNoOtSmPaAiMl.com>
> > I must be missing the point then.
>
> Most probably. I am unable to reconnect what have been talking about
> with your argument.
>
> > Wasn't MOP designed, in part,to provide information about the specifics
> > of an application for the purpose of allowing greater understanding of
> > it's inner workings?
>
> That is so not the point. Yes, wonderful tools exist to further both
> introspection in a system and learning and understanding in its users.
> Some of these tools actually make possible both thinking and solutions
> that would have been impossible to predict before it was deployed. That
> is the mark of a truly good idea. However, all good ideas can be carried
> too far and turn into _very_ bad ideas. E.g., the idea that members of a
> family pool their efforts and their earning so that the whole family can
> prosper as a result is a good idea, because of the preexisting commitment
> among the family members to the family. Doing exactly the same thing for
> a country of a hundred million people is not a good idea because there is
> no commitment from a citizen to a country on that scale.
>
> > I think the ability to query a system to find out what it's current state
> > it's in directly, instead of looking at source and making an educated
> > guess, is a good thing.
>
> I suggest that you look at the conditions that make it a good thing and
> see if you can find ways that some or all of those conditions can fail to
> be met with disastrous results. So far, all you have done is show us
> that you can think of positive consequences of having those conditions
> met. That is, frankly, utterly uninteresting. We all agree that all of
> this stuff has useful aspects. _Nobody_ is arguing against these things.
>
> I am, however, arguing against the standard implementation of a _specific_
> feature that has more negative aspects to it than positive because the
> conditions that are usually met by introspective functions are _not_ met
> by this particular feature. Somewhere along the line, I think you managed
> to conclude the general from the specific, when the general was already
> taken for granted, and argue for the specific based on arguments for the
> general. Both of which as disastrous logical fallacies. I have a hard
> time even coming to grips with the proportion of such an invalid argument.
> It is virtually a textbook example of how _not_ to argue for something.
>
> We have been told that this allInstances feature is great _because_ of
> the lack of documentation in large systems. I know, from experience,
> that that documentation is lacking _because_ of the availability of
> features that obviate the need for proper documentation. Thus, a feature
> that is "good" has very, very bad consequences because it turns people
> who are resource-conscious into worse programmers when they _know_ that
> whoever has to deal with their code is probably going to skip reading the
> documentation when they have that tool, too, so they never bother to write
> it in the first place, in a wonderful process of proving themselves right:
> Of course they didn't read the non-existing documentation before they used
> the allInstances trick to discover the information they were looking for!
>
> Please think things through, do not stop thinking just because of the sexy
> surface appeal of something.
>
I don't agree on a couple of points. Certainly not with the OP and its use
in a large system lacking documentation, I was thinking more along the lines
of debugging, being able to say,
(let ((*print-readably* t))
(format t "~{~A~%~}" (all-instances 'foo :derived-classes nil)))
or something similar. It may be more trouble to implement than it is worth,
but I'm not going to dismiss it out-of-hand, it really is kind of sexy. :-)
I disagree with the `"good" features -> worse programmers -> less documentation'
argument also, in my experience it's always been
`lazy programmers -> less documentation -> any damn excuse(lack of time,
"The code is obvious, once you get used to the X,XX,XXX,... for variable
names you'll be fine", etc.)'
OTOH, maybe you were just mocking my fuzzy thinking with that argument.
In that case, ignore this.
Thank you kindly,
Geoff
"Geoff Summerhayes" <·············@hNoOtSmPaAiMl.com> wrote in message ···················@corp.supernews.com...
>
> (let ((*print-readably* t))
> (format t "~{~A~%~}" (all-instances 'foo :derived-classes nil)))
>
Yes, I know ~A sets *print-readably* to false. Arrgh. I suffer
from `post-haste'.
Pun intended,
Geoff
* "Geoff Summerhayes" <·············@hNoOtSmPaAiMl.com>
> I don't agree on a couple of points. Certainly not with the OP and its use
> in a large system lacking documentation, I was thinking more along the lines
> of debugging, being able to say,
>
> (let ((*print-readably* t))
> (format t "~{~A~%~}" (all-instances 'foo :derived-classes nil)))
>
> or something similar. It may be more trouble to implement than it is worth,
> but I'm not going to dismiss it out-of-hand, it really is kind of sexy. :-)
Nobody else is dismissing it, either. _Please_ make an effort to avaid
reading so much weird shit into what I write. I am trying to make you
understand that this is a trade-off, a convenience factor, etc, that has
some costs as well as some benefits. If the world had clear-cut cases of
stuff with no costs and all benefits and vice versa, we simply would not
need to engage in engineering at all. E.g, some seriously misguided
people think that thay are making life easier by removing some trade-offs
and giving you "The Right Solution", but they do not even recognize that
they are operating within a context that may not be the same as that of
others. This happens _all_the_time_. Other people simply are not copies
of yourself who respond and think the same way you do. It is flat out
_wrong_ to presume that what works for you and appeals to you will work
for and appeal to others. (Well, if it does, you are a fantastically
boring person. :)
> I disagree with the `"good" features -> worse programmers -> less documentation'
> argument also,
Small wonder. I never even _implied_ "worse programmers". It is clear
that you do not subscribe to the long-standing and unchallenged Sapir-
Whorff hypothesis that language shapes the way we think (or _determines_
it in the stronger version of the hypothesis). I find this so obvious
that I have trouble dealing with people who do not accept it, and wonder
what they use _their_ languages for, but if I were to explain it in a
very different way, it has to do with what is more or less convenient to
do, and therefore more likely that people _will_ do. It is a little like
burglar alarms. They do manifestly _not_ work well because the burglar
gets caught more often in houses with burglar alarms than houses without
(they actually do not) but because of the much higher _perceived_ risk of
getting caught. So instead of burglarizing an alarmed house, they check
out the first non-alarmed house they find on their way, instead. This
does not have _anything_ to do with smart/dumb criminals, but with the
psychology of convenience, _all_ other things being equal. Smart people
simply do not waste their resources doing things that are inefficient.
This means that the smarter you are, the more likely you are to figure
out the least resource-intensive way to do something. I.e., the _better_
the programmers who are exposed to a system with clever features that
obviate the need for boring work, the more the clever features are used
and the boring work undone. Personally, I could not possibly care less
what happens to "worse programmers". What concerns me is the smartest of
the crop and how they will routinely refuse to waste their time doing
idiot stuff when better ways exist -- hell, they even _make_ better ways
that does away with the idiot stuff. That is how the allInstances thing
was invented in the first place (it was way easier than something else),
if I read Frank A. Adrian's story correctly and it was _not_ because of
any _desire_ to make people do the wrong thing. It just has that effect
on people who really think about what they do and really do figure out
how to make the most of their systems.
> OTOH, maybe you were just mocking my fuzzy thinking with that argument.
> In that case, ignore this.
Well, my wish for the day is that you manage to read this as a serious
opinion and chanin of thought, even though it is miles away from how you
evidently think yourself.
#:Erik
--
Travel is a meat thing.
Erik Naggum <····@naggum.net> writes:
> ... Smart people
> simply do not waste their resources doing things that are inefficient.
> This means that the smarter you are, the more likely you are to figure
> out the least resource-intensive way to do something. ...
The hardest part is, figuring out the least resource-intensive way to do
something itself is usually rather resource-intensive.
Life is hard, and then you fall into an infinite regression.
- huaiyuan
* Erik Naggum
> ... Smart people
> simply do not waste their resources doing things that are inefficient.
> This means that the smarter you are, the more likely you are to figure
> out the least resource-intensive way to do something. ...
* Huaiyuan <········@rac1.wam.umd.edu>
> The hardest part is, figuring out the least resource-intensive way to do
> something itself is usually rather resource-intensive.
Please read "The Joy of Figuring Things Out" by Richard Feinman. I urge
you to grasp some of the undiluted pleasure of making hard things simpler
through the expenditure of sometimes vast intellectual effort. Curiously
(at least to people who do not figure things out), figuring things out is
(usually) a one-time thing. After you figured it out, through that
ardous process, others need not (ideally) go through the same steps and
the same toil to get there. Structured, published, and organized, this
is called "research". Many young people prefer laziness now to working
hard to make their life easier as they grow older and wiser. I have no
sympathy for such people at all, but I do not have to do anything to take
a little (admittedly evil) pleasure in their (future) misery: Like
figuring things out is its own reward, laziness is its own punishment.
But, hey, feel free to optimize the path of your life at every step.
Some of us like to plan ahead and usually made the steps we do today a
very, very long time ago. Not only does it make everything _much_ easier
to know what to do beforehand, you _know_ when you are taking a detour.
Those who do not, often fail to take the necessary steps back to the path
they originally _wanted_ to follow themselves.
#:Erik
--
Intellectual laziness is punishable by brain death. It is a natural law.
Erik Naggum <····@naggum.net> writes:
> Please read "The Joy of Figuring Things Out" by Richard Feinman. I urge
> you to grasp some of the undiluted pleasure of making hard things simpler
> through the expenditure of sometimes vast intellectual effort. Curiously
> (at least to people who do not figure things out), figuring things out is
> (usually) a one-time thing. After you figured it out, through that
> ardous process, others need not (ideally) go through the same steps and
> the same toil to get there. Structured, published, and organized, this
> is called "research". Many young people prefer laziness now to working
> hard to make their life easier as they grow older and wiser. I have no
> sympathy for such people at all, but I do not have to do anything to take
> a little (admittedly evil) pleasure in their (future) misery: Like
> figuring things out is its own reward, laziness is its own punishment.
>
> But, hey, feel free to optimize the path of your life at every step.
> Some of us like to plan ahead and usually made the steps we do today a
> very, very long time ago. Not only does it make everything _much_ easier
> to know what to do beforehand, you _know_ when you are taking a detour.
> Those who do not, often fail to take the necessary steps back to the path
> they originally _wanted_ to follow themselves.
Those are good advices; and I can totally agree that the process of problem
solving is its very own reward. In fact, your previous post reminded me of
a very interesting problem: the control of reasoning, or metareasoning.
You see: "figuring out the least resource-intensive way of doing thing" can
be seen as a (meta) problem that arises from one's attempt to solve the
original problem. But solving this meta problem can give rise to meta meta
problem, and so on (hence the danger of infinite regression). So, how much
computation resources should you spend in solving the meta problem instead
of the problem itself, to minimize the overall resources spent? (And how
much time should you spend to consider the above question? :)
(See, e.g., http://citeseer.nj.nec.com/cs?q=metareasoning).
- huaiyuan
* Huaiyuan <········@rac4.wam.umd.edu>
> You see: "figuring out the least resource-intensive way of doing thing"
> can be seen as a (meta) problem that arises from one's attempt to solve
> the original problem. But solving this meta problem can give rise to
> meta meta problem, and so on (hence the danger of infinite regression).
> So, how much computation resources should you spend in solving the meta
> problem instead of the problem itself, to minimize the overall resources
> spent?
Now this is a much more intereting meaning to your article that I
assumed. Excuse me for being tired of intellectually lazy people, and
thanks for the intelligent response.
If I have but one character flaw, it is that I tend to ignore the problem
and go for the meta-problem. However, the meta-problem does not become
the problem for another round of that tendency, but I understand well the
problem you raise. In my view, what we do here and now is interesting
only insofar as it supports what we can do in the future, and what we did
in the past is interesting mostly in what it allows us to do now and in
the future. Since we are individually going to live for much longer than
any of us can reasonably plan and collectively much longer than any of us
can reasonably grasp, survival is meaningless without a long-term future
view with an eye to continuity and planability from the past. ("Live in
the moment" is an insult to human intelligence and human survival.")
With that as background, it should be obvious that I do not consider
there to be an upper limit on the amount of resources that should be
consumed on meta-problems as long as day-to-day survival is achieved and
that is largely an effect of the momentum of past planning and use of
resources. The only danger I see, then, is that solving a problem
necessarily breaks with the continuity of the past in ways that reduce
our planability in the present and the short-term future. (Long-term
planning takes such problem-solving into account.) I see absolutely no
other danger in any spending on meta-problems.
Now, since we have essentially infinite time and infinite resources
available to the human race (or whatever succeeds us), the problem is not
whether to solve a problem or meta-problem, but in what order. This must
of necessity be a global optimization, not a local one, so the problem is
how to organize society to that the two coincide and mesh well with the
requirement for individual and personal fulfillment, risk-taking, and
achievement.
In other words, I consider the problem of spending resources on the
problem at hand or at the meta-problem a question of intelligence and
wisdom of leadership and resource management, both monetary and human.
If you do not plan ahead, spent everything on the problem. If you intend
to be able to plan ahead after your current plans are toppled by changes
in your environment, spend all you can spare on the meta-problem.
My cynical, misanthropic, even pessimistic view of most things "human"
derive from the sorry fact that those who are most motivated to search
for positions of leadership are usually so astonishingly unintelligent
when it comes to serving any other need than their mental illness: the
hunger for power over people. Any display of power-hunger should be an
immediate cause for incarceration and treatment in a truly humane society,
but this, sadly, does not reflect how the human race reached its current
position. Slave labor, brute force, physical threats, etc, were proper
and necessary in times when society had very little or nothing to offer
the individual member thereof. Yet amazingly, some people still live as
if society were a negative force in their lives, as if the infrastructure
and general agreement on a number of massively important aspects of human
life were good for nothing, such as the morons in Gothenburg recently,
who flew there on jets, drove in safe cars on good roads, crossed borders
and jurisdictions peacefully and reaped the benefits of global economies
only to destroy a few million dollars' worth of somebody else's property
in order to protest against their future ability to similarly travel and
express their views in the global media. Clearly, these are people who
have zero understanding of the _effects_ of organizing societies well, and
thus have no possible constructivity to their activity at all, other than
accidentally increasing the gross national product.
> (And how much time should you spend to consider the above question? :)
Infinite, as metareasoning is a process, not a problem with a solution.
> (See, e.g., http://citeseer.nj.nec.com/cs?q=metareasoning).
Thanks for the pointer.
#:Erik
--
Travel is a meat thing.
Erik Naggum <····@naggum.net> writes:
> ........... Since we are individually going to live for much longer than
> any of us can reasonably plan and collectively much longer than any of us
> can reasonably grasp, survival is meaningless without a long-term future
> view with an eye to continuity and planability from the past. ("Live in
> the moment" is an insult to human intelligence and human survival.")
But the most powerful and gratifying intellectual force, creativity, seems to
arise in some ineffable way only out of the present moment! The past seems only
to provide the opportunity to develop the necessary intellectual scope.
Of course the vast majority spend no time whatsoever in the present moment;
they are either reliving the past or planning/rehearsing the future. (I
suppose even Buddhists must plan, or natural selection would have eliminated
them ages ago!) But IMHO attemping to live at least a small part of one's life
in the present moment (it's difficult) does wonders for peace of mind and
creativity.
Since devising sophisticated software has such a large creative component,
wouldn't it be important to nurture ways of thinking which enhance creativity?
Regards, KBK
>
> Since devising sophisticated software has such a large creative component,
> wouldn't it be important to nurture ways of thinking which enhance
creativity?
Things are only done in the present moment, including planning. Paying
attention to what one is doing, _now_, not letting past impressions and
wishful thinking about the future cloud your mind. Concentration is of
great benefit and should be nutured. Some of us spend so much time
programming machines but in a way our minds are the computers. Spend some
time figuring out what your minds are actually doing and not what you would
like them to do. Push the meta-problem about your own thinking.
This push for a better mind is not accomplished by reasoning, but by
practice, observation and contemplation. The world would be much better
off.
Wade
"Wade Humeniuk" <········@cadvision.com> writes:
> Things are only done in the present moment, including planning. Paying
> attention to what one is doing, _now_, not letting past impressions and
> wishful thinking about the future cloud your mind. Concentration is of
> great benefit and should be nutured. Some of us spend so much time
> programming machines but in a way our minds are the computers. Spend some
> time figuring out what your minds are actually doing and not what you would
> like them to do. Push the meta-problem about your own thinking.
>
> This push for a better mind is not accomplished by reasoning, but by
> practice, observation and contemplation. The world would be much better
> off.
"Planning" is something like chaining together of future events which could be
causally related and which have a resonably high probability of occurring,
based on history. As Eric said, if you can't know the probabilities your
planning horizon goes to zero.
But planning, like logical thinking, engages a series of thoughts about the
past and future, which is different from "observation and contemplation". When
the mind is so occupied, the present moment is essentially ignored.
Creativity, the flash of insight, seems to occur when you are not "looking
directly" at the problem, i.e. "thinking" hard about it. When I get stuck
designing something, I set it aside with confidence that the answer will
"occur" to me. IMHO, there is something else going on!
I must admit, though, that the solution to problem A can "occur" while I'm
focused on problem B!
Regards, KBK
* Erik Naggum
> ("Live in the moment" is an insult to human intelligence and human
> survival.")
* Kurt B. Kaiser
> But the most powerful and gratifying intellectual force, creativity,
> seems to arise in some ineffable way only out of the present moment! The
> past seems only to provide the opportunity to develop the necessary
> intellectual scope.
I had hoped the context would be clear. Of course, we actually _do_ live
in the moment, but the expression is in my view incredibly stupid. The
question is whether we live _for_ the moment, _for_ the past, or _for_
the future. The (my) question is what meaning the moment has to each one
of us. Some cultures are incredibly history-bound, and go on for
millennia sulking about lost territories, oppression, what have you, and
destroy the moment they could have lived in by creating mass hysteria,
abject fear, society-wide angst, and a despondent outlook towards
whatever they can catch a glimmer of a future in such a fucked-up
culture. Some subcultures pine for a past that has _no_ links to the
present at all, such as some of the political parties favoring farmers
and the like in Europe. And people in some subcultures live so much for
the future that it is perfectly OK to be rewarded with a Nobel prize half
a century after your discovery, when the world has caught up with you.
Now, because of the dreadfully short life-span of the human body, it is
nigh impossible to do something that will be rewarded more than 100 years
into the future. In fact, the 100-year limit to our perspective is _so_
strong with the present human cultures that people _still_ write the year
they live in with only two digits. Regular mortals cannot grasp the need
to write down a date that is unamiguous for more than one hundred years,
and this is not because they are immensely stupid (that is, that they are
does not explain this phenomenon :), but because the human lifespan is so
tragically short that in 100 years everything is literally forgotten.
(Except with certain cultures that live millennia in the past, although I
suspect that they, too forget the details and just cling to the emotions
that the transgressions of the past instilled in their forefathers, so
much so that there is no hope of recovery after the facts are forgotten).
> Of course the vast majority spend no time whatsoever in the present
> moment; they are either reliving the past or planning/rehearsing the
> future. (I suppose even Buddhists must plan, or natural selection would
> have eliminated them ages ago!) But IMHO attemping to live at least a
> small part of one's life in the present moment (it's difficult) does
> wonders for peace of mind and creativity.
Take up shooting as your next hobby. Absolutely nothing beats "living in
the moment" when you pull that trigger. Peace of mind is a prerequisite
for the marksman, and anyone who wants to succeed in shooting needs to
find his own way of relaxing and calming body and soul. But it would
still be a literally meaningless task if it were done without a purpose
_other_ than mere relaxation and fun. Becoming good at it is one goal,
another is to use it as a rewarding recreation. I think of most of the
silly things people do that they claim are recreational but cause more
stress than they relieve (traveling somewhere on vacation, for instance).
> Since devising sophisticated software has such a large creative
> component, wouldn't it be important to nurture ways of thinking which
> enhance creativity?
I found that the process of forcing my mind clear and the body to relax
and return to 45-50 in pulse with 10-12-second breathing intervals needs
to be rewarded in order to be achieved on a regular basis. Even with an
air/CO2 .177 gun you can achieve this in minutes. Half an hour's worth
of mental and physical cycles of relaxation and concentration can give
you back two hours of energy.
There is, however, a much more sinister angle on this "live in the
moment" thing which I maybe should not bring up, but it is important.
People who have no direction and do not plan are incredibly easy to lead,
for a religious leader, for a political leader, for a gang leader, for
any psychopath who wants to control other people. If he can make people
"live in and for the moment", that "leader" gets to define the direction
and gets to plan for a lot of other people. Slaves live for the moment,
never knowing what their master will do next. _Fear_ is the most potent
instrument to cause people to abandon planning -- the greater the fear,
the shorter the time-span of the plans. People who cannot plan the next
meal do not plan for old age. Living without plans is anti-human. So
whenever I hear this said by someone who also seeks power over people, I
get very, very suspicious about their _real_ motives. If it is said by
your ordinary fellow, it probably means taking time off from stressful
work in _order_ to reflect and plan and recover, such a different thing.
So this does emphatically not mean that recreation and "time off" should
not be planned. Quite the contrary. But it is not because it is a good
thing to "live in tne moment" -- it is because it is a good thing for our
ability to make and fulfill better plans.
To bring this a tad back to programming and the reason this whole thing
came up: When squeezed for resources, people's planning horizon gets a
lot closer. Day-to-day operations should be sufficiently well known and
sufficiently "safe" at least three months into the future (even taking
the inevitable changes during this time into account), for people to plan
ahead for real. Empirically, if your planning horizon comes closer than
that, you start doing things that are counter-productive to long-range
planning only to keep going in the short term. Stress builds up, and a
lot lower quality work comes out of it. That is why people who are under
a great stress from unavailable resources prefer tools that solve their
immedaite problems instead of their _real_ problems. That is why Perl is
more popular than Lisp. That is why people put up with the insane log
formats of most "server" software instead of fixing it for good. That is
why bad IT management makes their staff work very hard at ensuring that
they stay within the mainstream and do not stray into _real_ solutions.
People who solve _real_ problems are simply unmanageable, because they
pose a risk from within to a manager who is supposed to handle risks from
without. Since IT professionals usually _do_ want to solve real problems,
this requires _much_ better managers than can pass in other industries.
_This_ is the root cause of the "software crisis", not software, not IT
professionals, not programming languages, but managers who are unable to
deal with internal risk factors. That is why C++ and Java and Perl are
such good bets: Hiring people who claim to be good at those languages is
risk-free to a manager. They are never going to do anything to upset the
plans laid by _any_ IT manager, but they are never going to do anything
other than solve immediate problems, either, thus perpetuating their own
class and causing a whole industry for idiot manager education to deal
with idiot employees when probably _one_ Lisp programmer worth his salt
could put thousands of those jerks out of circulation and take their
managers with them. I firmly believe that when a manager chooses (read:
enforces) one of those languages, it is for purposes of self-preservation
rather than problem-solving.
#:Erik
--
Travel is a meat thing.
Erik Naggum <····@naggum.net> writes:
> * Erik Naggum
> > ("Live in the moment" is an insult to human intelligence and human
> > survival.")
>
> * Kurt B. Kaiser
> > But the most powerful and gratifying intellectual force, creativity,
> > seems to arise in some ineffable way only out of the present moment! The
> > past seems only to provide the opportunity to develop the necessary
> > intellectual scope.
>
> I had hoped the context would be clear. Of course, we actually _do_ live
> in the moment, but the expression is in my view incredibly stupid. The
> question is whether we live _for_ the moment, _for_ the past, or _for_
> the future. The (my) question is what meaning the moment has to each one
> of us. .........................................................
Yes, of course technically we can only live _in_ the moment, at least the "side
effects" to our "process" can only affect the environment in the present; but
I'm interpreting "live in the moment" to mean something like "pay attention to
the current moment".
> ................ In fact, the 100-year limit to our perspective is _so_
> strong with the present human cultures that people _still_ write the year
> they live in with only two digits. Regular mortals cannot grasp the need
> to write down a date that is unamiguous for more than one hundred years,
> and this is not because they are immensely stupid (that is, that they are
> does not explain this phenomenon :), but because the human lifespan is so
> tragically short that in 100 years everything is literally forgotten.
Yes, less than a year after Y2K I'm often writing "01", but I know my stuff is
completely ephemeral and will soon be gone along with last decades' National
Geographics print copies (just buy the whole 100 years or so on one DVD =). On
the other hand, Vernor Vinge's "A Deepness in the Sky" has some interesting
plotting based on millenia of cruft built up in layers of supposedly ephemeral
embedded code.
> (Except with certain cultures that live millennia in the past, although I
> suspect that they, too forget the details and just cling to the emotions
> that the transgressions of the past instilled in their forefathers, so
> much so that there is no hope of recovery after the facts are forgotten).
Whole cultures lost!
> > Of course the vast majority spend no time whatsoever in the present
> > moment; they are either reliving the past or planning/rehearsing the
> > future. (I suppose even Buddhists must plan, or natural selection would
> > have eliminated them ages ago!) But IMHO attemping to live at least a
> > small part of one's life in the present moment (it's difficult) does
> > wonders for peace of mind and creativity.
>
> Take up shooting as your next hobby. Absolutely nothing beats "living in
> the moment" when you pull that trigger. Peace of mind is a prerequisite
> for the marksman, and anyone who wants to succeed in shooting needs to
> find his own way of relaxing and calming body and soul. But it would
> still be a literally meaningless task if it were done without a purpose
> _other_ than mere relaxation and fun. Becoming good at it is one goal,
> another is to use it as a rewarding recreation. I think of most of the
> silly things people do that they claim are recreational but cause more
> stress than they relieve (traveling somewhere on vacation, for instance).
Unexpected and interesting answer! The highest levels of oriental martial arts
involve a "moving meditation" in which you "mindlessly" let the action happen.
The practitioner must have fully mastered the technical aspects of the budo and
also be experienced in zazen (i.e. simple meditation without motion) to begin
to accomplish this.
> I found that the process of forcing my mind clear and the body to relax
> and return to 45-50 in pulse with 10-12-second breathing intervals needs
> to be rewarded in order to be achieved on a regular basis. Even with an
> air/CO2 .177 gun you can achieve this in minutes. Half an hour's worth
> of mental and physical cycles of relaxation and concentration can give
> you back two hours of energy.
You are saying that the target session is the reward? Or the individual shot?
When you take the shot, at the last moment, is this a deliberate action
involving logical thought or does it just "happen"?
> There is, however, a much more sinister angle on this "live in the
> moment" thing which I maybe should not bring up, but it is important.
> People who have no direction and do not plan are incredibly easy to lead,
> for a religious leader, for a political leader, for a gang leader, for
> any psychopath who wants to control other people. If he can make people
> "live in and for the moment", that "leader" gets to define the direction
> and gets to plan for a lot of other people. Slaves live for the moment,
> never knowing what their master will do next. _Fear_ is the most potent
> instrument to cause people to abandon planning -- the greater the fear,
> the shorter the time-span of the plans. People who cannot plan the next
> meal do not plan for old age. Living without plans is anti-human. So
> whenever I hear this said by someone who also seeks power over people, I
> get very, very suspicious about their _real_ motives. If it is said by
> your ordinary fellow, it probably means taking time off from stressful
> work in _order_ to reflect and plan and recover, such a different thing.
The practice of zazen seems to generally develop a sense of perspective
relating to personal motives. It was developed in cultures where the
individual potentiality was relatively bleak. So IMHO living _for_ the moment,
perhaps because one is forced to do so, is quite different from living _in_ the
moment, paying attention to it, which even a prisoner can do.
> So this does emphatically not mean that recreation and "time off" should
> not be planned. Quite the contrary. But it is not because it is a good
> thing to "live in tne moment" -- it is because it is a good thing for our
> ability to make and fulfill better plans.
>
> To bring this a tad back to programming and the reason this whole thing
> came up: When squeezed for resources, people's planning horizon gets a
> lot closer. Day-to-day operations should be sufficiently well known and
> sufficiently "safe" at least three months into the future (even taking
> the inevitable changes during this time into account), for people to plan
> ahead for real. Empirically, if your planning horizon comes closer than
> that, you start doing things that are counter-productive to long-range
> planning only to keep going in the short term. Stress builds up, and a
> lot lower quality work comes out of it. That is why people who are under
> a great stress from unavailable resources prefer tools that solve their
> immedaite problems instead of their _real_ problems. That is why Perl is
> more popular than Lisp. That is why people put up with the insane log
> formats of most "server" software instead of fixing it for good. That is
> why bad IT management makes their staff work very hard at ensuring that
> they stay within the mainstream and do not stray into _real_ solutions.
> People who solve _real_ problems are simply unmanageable, because they
> pose a risk from within to a manager who is supposed to handle risks from
> without. Since IT professionals usually _do_ want to solve real problems,
> this requires _much_ better managers than can pass in other industries.
> _This_ is the root cause of the "software crisis", not software, not IT
> professionals, not programming languages, but managers who are unable to
> deal with internal risk factors. That is why C++ and Java and Perl are
> such good bets: Hiring people who claim to be good at those languages is
> risk-free to a manager. They are never going to do anything to upset the
> plans laid by _any_ IT manager, but they are never going to do anything
> other than solve immediate problems, either, thus perpetuating their own
> class and causing a whole industry for idiot manager education to deal
> with idiot employees when probably _one_ Lisp programmer worth his salt
> could put thousands of those jerks out of circulation and take their
> managers with them. I firmly believe that when a manager chooses (read:
> enforces) one of those languages, it is for purposes of self-preservation
> rather than problem-solving.
You have often mentioned the difference between chaining tools in Perl and
creating a novel design in Lisp. As long as one is "coding" (i.e. chaining
tools) there is not much creativity, but "design" is something else again.
What is commonly called "design" is often just chaining of these tools,
commonly expressed graphically, and no risk to your IT manager. The risk lies
in creativity!
Regards, KBK
···@shore.net (Kurt B. Kaiser) writes:
> Of course the vast majority spend no time whatsoever in the present moment;
> they are either reliving the past or planning/rehearsing the future. (I
> suppose even Buddhists must plan, or natural selection would have eliminated
> them ages ago!) But IMHO attemping to live at least a small part of one's life
> in the present moment (it's difficult) does wonders for peace of mind and
> creativity.
Speaking for all Buddhists is like speaking for all Christians, only
more so. There's too many different sects to cover any topic with
certainty. Let me just put forward _my_ opinion as a Soto Zen
Buddhist. Every other Buddhist will have a different opinion, I'm
sure.
Remembering the past or planning for the future is necessary and
proper for people to do. Like you said, it would be hard to survive
without using both of those abilities.
But there's a big difference between planning and worrying, between
remembering and obsessing. To make the difference clearer: it's
useful for me to plan an efficient route to the store. It's not
useful for me to worry that I may not choose the right route, or to be
sad about all the gas I've wasted on inefficient routes in the past,
or mad at all those bastards out there who don't care enough not to
waste gas, or be pleased with myself about my prudence. The best way
is just to see the need, make the plan, and keep on rocking. No need
to make a big deal out of it.
Humans love drama. All that "living in the moment" should imply is
just a removal of our personal little drama about the past and future,
not a cessation of the act of planning or remembering.
My two cents.
--
C. O. Puckett replace "sendnospam" with "puckett"
In article <················@naggum.net>, Erik Naggum wrote:
> Small wonder. I never even _implied_ "worse programmers". It is clear
> that you do not subscribe to the long-standing and unchallenged Sapir-
> Whorff hypothesis that language shapes the way we think (or _determines_
> it in the stronger version of the hypothesis).
Sapir-Whorff hypothesis is not unchallenged.
Steven Pinker, in his _The_Language_Instinct_ [chap 3 Mentalese], argued
strongly against the Sapir-Whorff hypothesis. He started with rather
obvious proposition that the thought is not the same as language, and
build his argument from there with examples showing that languageless
thought exists and there's no clearcut proof that the language shapes
our thoughts, etc.
regards,
abe
"Overtly resist change."
Why Lispnewbie is asking for ths feature is that Smallalk has this paradigm
of UI interaction called the MVC model. In it, a Model holds information, a
View mediates user output usign information stored on the Model, and a
Controller takes UI events and transforms them into messages that are sent
to the Model and View in order to let the user make changes, see
information, etc. Since more than one View can be attached to a Model, the
Model keeps a list of all Views hooked to it in order to send to the views a
notification that it has changed. The windowing system in Smalltalk is also
based on this paradigm.
In this paradigm, the attachment of the View to the Model is handled
programatically. When one closes a View, unless the corresponding Model is
notified that the View has gone away, the Model keeps a reference to the
View, keeping it (and it's usually vast attached resources) from being
reclaimed. Usually, the Model and View only self reference, so both can go
away once the View has been removed from the Screen's View. But during
development, the Model is often pointed to by a global that's been used to
test the object, etc., and so the View hangs around. So, sloppy programmers
often inspect all (sub-)instances of View to find Views that should have
been detached, and use manual interactions to remove them from the
dependency list or to "becomes:" them (trust me, you don't want to know what
this is :-) to a null string so that messages to them can be ignored and
that the storage allocated to them can be destroyed.
This type of dependency mechanism can be used throughout the system for any
object as a model. The dependency lists are kept in a global hash table
(for objects not subclassed from class Model), so the hash table acts as
another point for collecting undeleted dependents. often, rather than
walking the hash table looking for crap you forgot to send the message
"release" to, it's easier to look at "allInstances" of a given class.
All of this has been made much less problematic with the addition of
WeakReference objects to most Smalltalks, but, as they say, "Old habits die
hard"...
I hope this (dreadfully oversimplified) explanation shows why a Smalltalk
programmer might view the lack of an "allInstances" method on a class to be
a dreadful oversight. I myself, have never missed the thing in CLOS, having
been parsimonius in my consing and always willing to reload my files into
the image :-).
faa
"Erik Naggum" <····@naggum.net> wrote in message
·····················@naggum.net...
> * ··········@questions.com
> > For example, to find a "lost" object.
>
> Common Lisp features a garbage collector. If there is no way you can
> reference an object, it does not matter whether it exists (in memory) or
> not. Consequently, it saves on memory consumption to (re)use the space
> used by objects that people have "lost" for something they have not
lost.
> If the system hangs on to objects after you lost them, there is probabl
a
> very good reason for that, and an accompanying mechanism to delete those
> objects. Otherwise, there is no way you can both lose it and fint it.
I
> wouls guess that only a few kinds of objects satisfy this condition,
such
> as processes, streams, packages, symbols, etc. In fact, all operating
> system resources _should_ satisfy this condition, but they do not always
> do so. E.g., streams usually reflect a scarce system resource that you
> really want to be able to recover and your Common Lisp system should
have
> a way to go from system resource to high-level resource, such as from a
> file descriptor to a stream. This particular mapping is astonishingly
> simple to accomplish and it is a shame that it needs to be done
manually.
>
> > I might have only vague knowledge of a particular object, and might want
> > to inspect it to learn more about it. It would be handy to be able to
> > iterate through all objects to find those that match a pattern, which
> > might represent the vague knowledge I have of the object I'm looking
for.
>
> Then it would serve your purposes much better to learn how to find
> objects that might satisfy your needs than to find all objects in order
> to test them to satisfy your needs. From what you keep telling me about
> SmallTalk, it seems like a seriously misdesigned language when it lets
> people rummage around the garbage to find something or other that may or
> may not have been "lost". However, since I do not consider SmallTalk
> misdesigned, I instead consider your usage of these features _abusive_.
>
> Similar abuse may of course be accomplished in Common Lisp. The garbage
> collector will necessarily know about all (live) objects, and you may
ask
> it nicely to return a list of all of them -- it necessarily has a way to
> reference all objects independently of all other references. In Allegro
> CL, you do that with the function (excl::get-objects <object-type-id>).
> Evaluate (room t) to see which object types and ids are available.
>
> > You might be thinking of small and medium sized projects done by one
> > person, such that it's easy to keep track of all the details. But I'm
> > used to working on very large projects, where I have to understand the
> > work of large numbers of other programmers. Such work is often poorly
> > documented, and best understood by browsing and inspecting the running
> > code and objects. I might have no idea where to look among megabytes of
> > source code for a particular bug, but might be able to find it fast by
> > browsing and inspecting various objects related to it.
>
> This leads me to believe that the existence of the features you want
> encourage the abuse you have described and apparently consider a plus,
> while I hold the view that if certain things are harder to do than
> others, people will do other things to avoid the hardest part of the
job.
> In a nutshell: If it is harder to document than to browse, people will
> browse, but if it is harder to browse than to document, people will
> document. Programming languages are all about built-in convenience. In
> a twisted form, the Sapir-Whorff hypothesis, that languages shape the
way
> we think, applies because of sheer laziness and/or intelligent use of
> resources (the two frequently coincide).
>
> Incidentally, there is the function apropos, and some Common Lisps even
> feature an apropos-regexp function for those who think regexps are cool.
>
> #:Erik
> --
> Travel is a meat thing.
>>>>> On Sun, 17 Jun 2001 11:51:57 GMT, lispnewbie ("lispnewbie") writes:
lispnewbie> You might be thinking of small and medium sized projects done by one person,
lispnewbie> such that it's easy to keep track of all the details. But I'm used to
lispnewbie> working on very large projects, where I have to understand the work of large
lispnewbie> numbers of other programmers. Such work is often poorly documented, and best
lispnewbie> understood by browsing and inspecting the running code and objects. I might
lispnewbie> have no idea where to look among megabytes of source code for a particular
lispnewbie> bug, but might be able to find it fast by browsing and inspecting various
lispnewbie> objects related to it.
I am thinking of systems with more than 100 MB of Lisp source code.
I haven't ever needed a list of all the instances of all the objects
in order to figure out what's going on, largely because Lisp and most
of its development environments provide good tools for exploration
and inspection of large systems. I think I already said that, though.
>>>>> "lispnewbie" == lispnewbie <··········@questions.com> writes:
lispnewbie> In Smalltalk if I want a list of all existing instances
lispnewbie> of a class, I can use "classname allInstances" to get
lispnewbie> such a list. What is the equvialent in Lisp?
If what you want is to keep track of all instances of arbitrary
classes, then you may consider defining a new metaclass for this.
This is certainly a viable reason to modify the nature of CLOS. It
really depends a bit on the level of where you want this logic to go.
Someone has already suggested using an :after method on I think
initialize-instance. Another way is get into the heart of
standard-class. If you wanted to define your new metaclass such that
you can ask the class for all of its instances, I'd say that this
would merit using the MOP.
Once you dive into it a bit, you'll see that this particular example
is straightforward. Of course, there are other ways, but this is
probably the one which is the most meaningful, since you're really
adding a property to the way the class itself behaves.
dave
>>>>> On Sun, 17 Jun 2001 09:27:13 GMT, David Bakhash ("David") writes:
David> If what you want is to keep track of all instances of arbitrary
David> classes, then you may consider defining a new metaclass for this.
That is not available in ANSI Common Lisp (the MOP is not part of that
language), although some vendors support this.
* David Bakhash
> If what you want is to keep track of all instances of arbitrary
> classes, then you may consider defining a new metaclass for this.
* Christopher Stacy
> That is not available in ANSI Common Lisp (the MOP is not part of that
> language), although some vendors support this.
Vote with your feet when it comes to supporting the MOP. If the vendor
does not support it, just walk away. If people are told not to expect
the most basic features above and beyond Common Lisp because it is not in
the standard, the language will die. In fact, I consider the fact that
people are willing to whine about feature X not being in the standard as
the reason that Common Lisp has seen little development. The point with
a standard is not to ask what is in it, it is to ask whether that which
is in it is implemented, and whether that implementation is according to
that standard. If it is not specified in one standard, it may be
specified in another standard. MOP is a community standard that merits
about the same level of authority within the community as ANSI does for
the greater community. Similar efforts have been attempted with other
features that people need, too, but instead of writing standards-quality
stuff to support an implementation, some people prefer to post only the
implementation, which is completely useless to people who are used to
having a really good standard to refer to when they need to understand
what to _expect_ from an implementation. (Many other languages are the
other way around: That the implementation _is_ the specification.)
MOP _is_ part of the Common Lisp toolchest and the common environment
that surrounds the language proper. This is one of the reasons it is not
a lot of work to build a Common Lisp interpreter or compiler (as is often
done with Scheme), but a lot of work to build a Common Lisp _system_ (as
is ofte not done with Scheme). If we do not appreciate the systems, but
only the language, we have no chance at all against languages that have
successfull merged to two concepts, such as Perl and Java.
The only way to _make_ vendors support stuff people need is to make sure
they are chosen if and only if they do. In the case of the "Open Sores"
community, their biggest problem is that they do not want what they have
not got, in particular, the lack of willingness to implement what is in
the commercial offerings, coupled with a lack of willingness to use what
is only in the commercial offerings, making sure that the willingness to
implement it is never going to materialize, either.
#:Erik
--
Travel is a meat thing.