Hello all, I want to represent a network of nodes and links between
nodes in lisp. When I do the following:
(defstruct node (links nil))
(defstruct link (from nil) (to nil) (symmetric nil))
(setf node1 (make-node))
(setf node2 (make-node))
(setf link12 (make-link))
(setf (link-from link12) node1)
(setf (link-to link12) node2)
(setf (node-links node1) (list link12))
(setf (node-links node2) (list link12))
Lisp hangs. This is because objectzs cannot apparentlt not contain
each other recursively. But how then can I represent a network
without having to build and search a table of links between objects
refered to by some id (eg like in
(defstruct node (id (get-unique-id))
(links a-list-of-ids))
Now, when I want to find a node that is linked to some node I will
have to retrieve it from some table via the id via a function like
(get-node with-id)) ???
Thanks, joachim.
ok, the problem is indeed the printing, thanks!
I have an additional pobem now however, if I evaluate
=> (setf *print-circle* t)
T
then *print-circle* remains nil:
=> *print-circle*
NIL
I use Allegro Common Lisp 6.0. In their documentation the variable
*print-circle* is part of the common-graphcs package wich does not
exist for linux systems.
Joachim.
* ·······@arti.vub.ac.be
| I have an additional pobem now however, if I evaluate
|
| => (setf *print-circle* t)
| T
|
| then *print-circle* remains nil:
|
| => *print-circle*
| NIL
This does not appear to be very likely. Do you restart a new listener
between these two forms?
| I use Allegro Common Lisp 6.0. In their documentation the variable
| *print-circle* is part of the common-graphcs package wich does not exist
| for linux systems.
What nonsense. The _function_ named print-circle is a common-graphics
feature, but the _variable_ named *print-circle* (note the asterisks) is
part of standard Common Lisp. If you use the documentation for Allegro
CL 6.0, at least follow the links and pay attention so you do not make it
appear that you confusion is Franz's fault.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
Post with compassion: http://home.chello.no/~xyzzy/kitten.jpg
Erik Naggum <····@naggum.net> writes:
> * ·······@arti.vub.ac.be
> | I have an additional pobem now however, if I evaluate
> |
> | => (setf *print-circle* t)
> | T
> |
> | then *print-circle* remains nil:
> |
> | => *print-circle*
> | NIL
What is wrong with the above is that I put a prompt in front of the
expressions which indeed makes it seem I evaluate the expressions
within the same listener. What I actually did was I evaluated the
expressions from a file within emacs using the ACL-Emacs interface.
It appears that whenever a new expression is evaluated, a new listener
is started that is not entirely the same as the original one. This is
at least very confusing since when one evaluates an expression the
normal case is that, at the next evaluation, the previous one is still
'remembered':
(setf x 5)
evaluates to 5
x
now still evaluates to 5
but when one replaces x with *print-circle*, the behaviour is very different.
> This does not appear to be very likely. Do you restart a new listener
> between these two forms?
thus: yes indeed I guess. And I still do not know how to solve my problem
since I would like *print-circle* to be true _always_.
>
> | I use Allegro Common Lisp 6.0. In their documentation the variable
> | *print-circle* is part of the common-graphcs package wich does not exist
> | for linux systems.
>
> What nonsense. The _function_ named print-circle is a common-graphics
> feature, but the _variable_ named *print-circle* (note the asterisks) is
> part of standard Common Lisp. If you use the documentation for Allegro
> CL 6.0, at least follow the links and pay attention so you do not make it
> appear that you confusion is Franz's fault.
very sorry, you are completely right. Nevertheless, I find Franz
documentation sometimes very confusing.
* ·······@arti.vub.ac.be
| What is wrong with the above is that I put a prompt in front of the
| expressions which indeed makes it seem I evaluate the expressions within
| the same listener.
It is quite common to make a number of special variables local to each
listener. This is generally considered a very useful feature.
| And I still do not know how to solve my problem since I would like
| *print-circle* to be true _always_.
See the macro top-level:setq-default.
| Nevertheless, I find Franz documentation sometimes very confusing.
Unlike the old paper manuals, last made for release 4.3 as far as I can
see, it is hard to just _read_ HTML-based documentation. In fact, this
is my biggest gripe with "hypertext" in the first place. But I digress.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
Post with compassion: http://home.chello.no/~xyzzy/kitten.jpg
>>>>> "EN" == Erik Naggum <····@naggum.net> writes:
[...]
EN> Unlike the old paper manuals, last made for release 4.3 as
EN> far as I can see, it is hard to just _read_ HTML-based
EN> documentation. In fact, this is my biggest gripe with
EN> "hypertext" in the first place. But I digress.
I used to like hypertext before I realized that regular and readable-on-paper
material would disappear. Companies probably realized that people who actually
like reading manuals are in the minority compared to people who just just use
them to look up whatever incantation they need and stopped providing them.
This is not progress. Printing from the browser is not a substitute for a
well written linear manual. I even tried taking a notebook computer to bed --
not the same thing. A whole mode of learning is disappearing, it seems.
B<cranky>M
Bulent Murtezaoglu <··@acm.org> writes:
> I used to like hypertext before I realized that regular and
> readable-on-paper material would disappear.
Curious, since they are pretty much all still readable on paper
AFAICT.
In general, I much prefer the medium of reading through text printed
on paper for many of the same reasons you do. This doesn't prevent me
from also reading the same things as hypertexted. I like having both.
Bulent Murtezaoglu <··@acm.org> writes:
> >>>>> "EN" == Erik Naggum <····@naggum.net> writes:
> EN> Unlike the old paper manuals, last made for release 4.3 as
> EN> far as I can see, it is hard to just _read_ HTML-based
> EN> documentation. In fact, this is my biggest gripe with
> EN> "hypertext" in the first place. But I digress.
>
> I used to like hypertext before I realized that regular and
> readable-on-paper material would disappear. Companies probably
> realized that people who actually like reading manuals are in the
> minority compared to people who just just use them to look up
> whatever incantation they need and stopped providing them. This is
> not progress. Printing from the browser is not a substitute for a
> well written linear manual. I even tried taking a notebook computer
> to bed -- not the same thing. A whole mode of learning is
> disappearing, it seems.
Survival of the fittest.
Just too bad whoever's running the show never consulted us for what
the "fittest" predicate should be. We refer to the term as if it was
fixed in meaning, when in reality it is utterly dynamic and (depending
on your religious model) utterly arbitrary.
Some among us choose to occasionally attribute the aribtrariness to
"God's will", as if to say "perhaps we are not headed, as it otherwise
seems we are, for a 'hill climbing' problem."
I, for one, see a definite meta-parallel between this issue and
the "evolving sales model" (to use a neutral term) we were discussing
in another thread. Once again we see the issue of evolution working
by selection on need-of-the-moment at the likely expense of long-term
variability.
Indeed, Lisp itself was entirely at risk a few years ago over a matter
of a few megabytes of storage (which measure now mostly favors us, but
at a time when it doesn't evolutionarily matter) or a matter of a tiny
constant factor in memory cycles (which again mostly don't matter now
because cycles can mostly be purchased cheaply for a small constant
factor in dollars that is surely not dominant in most applications).
Fortunately, Lisp is a varied enough language that it has usually had
some strength or another in its quiver to keep it alive even in the case
where people were disregarding most of its other potential strengths.
The absolute essential of the moment is worth nothing the next...
I don't think we'll ever get out of the desire to compete. It's
probably wired into us. The best we can do is to do, as in sports,
and channel our competitive urge from "war" to a system of rules (say,
"soccer"), so that we blow off steam in a more constructive (or, at
least, less destructive) way.
Likewise, the "free market" is a nice concept, but occasionally
intervening from outside and saying "let's rescue this idea" or "let's
make it hard to kill off that idea". Ideas as varied as taxation,
anti-trust legislation, historical preservation societies,
time capsules, and deja news are all among the ways of trying to stave
off what would otherwise be the inevitable pressure to throw away the
future to salvage the moment.
In article <···············@shell01.theworld.com>,
Kent M Pitman <······@world.std.com> writes:
> Bulent Murtezaoglu <··@acm.org> writes:
>
>> I used to like hypertext before I realized that regular and
>> readable-on-paper material would disappear.
>
> Survival of the fittest.
>
> Just too bad whoever's running the show never consulted us for what
> the "fittest" predicate should be.
I thought we had decided we're all good capitalists. That being the case,
the measure of "fittest" is whichever approach returns the micro optimized
return over a hyper short period of time.
Printing, handling, and shipping printed manuals is expensive. Take those
beautiful Symbolics manuals for instance. (No! You can't take mine!) How much
did each copy cost Symbolics? I'd bet a pretty penny. Beans counters, being
"good" capitalists, take about 10 nanoseconds to realize that's a pretty penny
they can save if they discontinue the printed version. Afterall, you're
already shipping the bits on the CD.
Sorry, it's Monday! :-)
Mike McDonald
·······@mikemac.com
"Mike McDonald" <·······@mikemac.com> ha scritto nel messaggio ················@enews1.newsguy.com...
> In article <···············@shell01.theworld.com>,
> Kent M Pitman <······@world.std.com> writes:
> > Bulent Murtezaoglu <··@acm.org> writes:
> >
>
> >> I used to like hypertext before I realized that regular and
> >> readable-on-paper material would disappear.
> >
> > Survival of the fittest.
> >
> > Just too bad whoever's running the show never consulted us for what
> > the "fittest" predicate should be.
>
> I thought we had decided we're all good capitalists. That being the case,
> the measure of "fittest" is whichever approach returns the micro optimized
> return over a hyper short period of time.
>
> Printing, handling, and shipping printed manuals is expensive. Take those
> beautiful Symbolics manuals for instance. (No! You can't take mine!) How much
> did each copy cost Symbolics? I'd bet a pretty penny. Beans counters, being
> "good" capitalists, take about 10 nanoseconds to realize that's a pretty penny
> they can save if they discontinue the printed version. Afterall, you're
> already shipping the bits on the CD.
I am well willing to pay extra for printed docs, so even
the bean counters should be happy.
Alas, when I asked for printed docs, (to be bought for a
supplement, of course) my vendor said it's not cost-effective
to provide them, as very few users asks for them.
Are you sure (all who complain, not Mike personally) you
have voiced your need of printed docs to your vendor?
P.
From: Robert Folland
Subject: Re: representing a network in lisp
Date:
Message-ID: <uu1qmug1v.fsf@circinus.no>
Bulent Murtezaoglu <··@acm.org> writes:
> >>>>> "EN" == Erik Naggum <····@naggum.net> writes:
> [...]
> EN> Unlike the old paper manuals, last made for release 4.3 as
> EN> far as I can see, it is hard to just _read_ HTML-based
> EN> documentation. In fact, this is my biggest gripe with
> EN> "hypertext" in the first place. But I digress.
>
> I used to like hypertext before I realized that regular and readable-on-paper
> material would disappear. Companies probably realized that people who actually
> like reading manuals are in the minority compared to people who just just use
> them to look up whatever incantation they need and stopped providing them.
> This is not progress. Printing from the browser is not a substitute for a
> well written linear manual. I even tried taking a notebook computer to bed --
> not the same thing. A whole mode of learning is disappearing, it seems.
I agree with this sentiment, reading books on a notebook does not work
when it is HTML-based. What I find actually works well on a notebook
is the Acrobat eBook Reader on Windows and xdvi on Linux.
I am reading and working my way through Touretzkys book in eBook
Reader for Windows, and CLtL2 in dvi-format on Linux.
Sadly the eBook Reader isn't available for Linux, and xdvi isn't
available for Windows... but having the same programming environment
on both platforms helps (Gnu Emacs, CLISP/ACL/LispWorks, cygwin).
CLtL2 in HTML-format is good for bringing up a page from ILISP though,
as is the Hyperspec.
So the nice thing to do would be to automagically produce both types
of format I guess, like it has been done for CLtL2 (from TeX
sources...).
-Robert
From: Dorai Sitaram
Subject: Re: representing a network in lisp
Date:
Message-ID: <a8t0ta$5pj$1@news.gte.com>
In article <·············@circinus.no>,
Robert Folland <······@circinus.no> wrote:
>Sadly ... xdvi isn't
>available for Windows...
Have you tried yap, the dvi previewer that comes with
MiKTeX (a, maybe the, TeX distro for Windows)?
Robert Folland schrieb:
>
> Bulent Murtezaoglu <··@acm.org> writes:
> > >>>>> "EN" == Erik Naggum <····@naggum.net> writes:
> > [...]
> > EN> Unlike the old paper manuals, last made for release 4.3 as
> > EN> far as I can see, it is hard to just _read_ HTML-based
> > EN> documentation. In fact, this is my biggest gripe with
> > EN> "hypertext" in the first place. But I digress.
> > I used to like hypertext before I realized that regular and readable-on-paper
> > material would disappear. Companies probably realized that people who actually
> > like reading manuals are in the minority compared to people who just just use
> > them to look up whatever incantation they need and stopped providing them.
> > This is not progress. Printing from the browser is not a substitute for a
> > well written linear manual. I even tried taking a notebook computer to bed --
> > not the same thing. A whole mode of learning is disappearing, it seems.
> I agree with this sentiment, reading books on a notebook does not work
> when it is HTML-based. What I find actually works well on a notebook
> is the Acrobat eBook Reader on Windows and xdvi on Linux.
Oh. I love documentations in html.
My way is to use the html-editor "phase5". This allow me to make changes
in the source-code and view the document in the browser-preview (ie.5,
very fast method) or I use the option "strip all html" (for
java-script-pages or the upcoming xmls) to get a plain text document.
But mostly I linked various sides together for My-Dokus (a simple
frame-set with a navbar).
I practice this since about 3 years (thats when I edit my first
html-pages) and also my printer is nearly never in use (the good effect
is: no papers laying around like in former days and bookmarking is also
edit-able html, but more improtant: it helps the forests). And I can
say, in my case I do not like to download the big pdf-files. Sadly case
is, some people offer *.ps-files as only doc-forms (or *.eps) and this
in a tar.gz. But therefore I use a win-compatible ghost-view and this
does copy&paste. So I have no problems. (The Latex-docus I usualy let
them where they are).
In the comp.lang.forth-news-group I found an interesting discussion
about how to present documentations. Some people disagree there with
Adobes Software Products/Moneymaking (also they reported font-problems
on some platforms with newer versions). And I find under Linux-SuSE the
pdfs are very slow. When I find a solution how to bring the pdf-stuff
into nice html-form, I will be glad. (there is a pdf2cl-cl2pdf(?), but
it does not work for me :( )
> CLtL2 in HTML-format is good for bringing up a page from ILISP though,
> as is the Hyperspec.
Well, I am a German with broken English, so, I have some Hyperspec
passages translated (and strip off unnecessary lines). Reading english
words about something unknown doubles my problems in most cases and
slowdown working/learning. Also I give up the translating software, for
translate programming-texts this is no good idea (example the command:
"push-stack" becomes to: "schiebe Stapel").
> So the nice thing to do would be to automagically produce both types
> of format I guess, like it has been done for CLtL2 (from TeX
> sources...).
Why not offer good old plain-text files ? In nearly all cases (think
about pictures) this is a very small file-size (and usualy a web-browser
shows the content nice). I remember in 1995 this was common way on
win-systems until the hlp-files come up.
But, the most problem I found is a kind of different one. This is, when
a profi writes a text for beginners, he is not able to imagine what a
beginner thought about, so his text failed, mostly about the stupid
details the writer assumed they are well known, and this is ^2 for lisp
- there are many trivial details.
stefan
what does a win user (80%!) do with *.bz2 ?
Erik Naggum <····@naggum.net> writes:
> | And I still do not know how to solve my problem since I would like
> | *print-circle* to be true _always_.
>
> See the macro top-level:setq-default.
from within an emacs buffer of ACL-mode I evaluated (with C-c C-s):
(top-level:setq-default *print-circle* T)
which returned T.
Now if I evaluate *print-circle*, form within the same buffer, again
with C-c C-s, it still returns NIL :-(
I even put the line (1) into my ~/.clinit.cl. *print-circle* remains
NIL :-(
Joachim.
·······@arti.vub.ac.be wrote:
> Erik Naggum <····@naggum.net> writes:
>
>> | And I still do not know how to solve my problem since I would like
>> | *print-circle* to be true _always_.
>>
>> See the macro top-level:setq-default.
>
> from within an emacs buffer of ACL-mode I evaluated (with C-c C-s):
>
> (top-level:setq-default *print-circle* T)
>
> which returned T.
>
> Now if I evaluate *print-circle*, form within the same buffer, again
> with C-c C-s, it still returns NIL :-(
>
> I even put the line (1) into my ~/.clinit.cl. *print-circle* remains
> NIL :-(
I strongly advise against setting variables like *print-circle* to another
value. You can easily mess up your environment by doing such things. This
is why many environments hold their own bindings while evaluating the
buffer. This means that the *print-circle* of two different
buffer-evaluations are two different bindings.
If you want to set *print-circle* to T you should do it locally by doing
something like the following:
(defun foo ()
(let ((*print-circle* t))
(bar)))
Since *print-circle* is a special variable it will be visible in the
dynamic extent of BAR.
The fact that you could not set *print-circle* to T globally is not a
language issue but an IDE issue. It is actually a safety feature of ACL and
a strong sign that you do something wrong.
ciao,
Jochen
--
http://www.dataheaven.de
"Jochen Schmidt" <···@dataheaven.de> wrote in message
·················@rznews2.rrze.uni-erlangen.de...
>
>
> I strongly advise against setting variables like *print-circle* to another
> value. You can easily mess up your environment by doing such things.
What could you possibly mess up by having *print-circle* set to T?
> This is why many environments hold their own bindings while evaluating the
> buffer. This means that the *print-circle* of two different
> buffer-evaluations are two different bindings.
I can see an argument for having two different buffers have
differing values for reader and printer behavior, but not for
two different (and sequential) evaluations in the same buffer.
> If you want to set *print-circle* to T you should do it locally by doing
> something like the following:
>
> (defun foo ()
> (let ((*print-circle* t))
> (bar)))
>
> Since *print-circle* is a special variable it will be visible in the
> dynamic extent of BAR.
But this has no effect on what is printed at top level when foo
exits.
>
> The fact that you could not set *print-circle* to T globally is not a
> language issue but an IDE issue. It is actually a safety feature of
> ACL and a strong sign that you do something wrong.
This is absurd. Having *print-circle* be NIL means that attempting
to print a circular structure will hang (or print infinite text).
This isn't `safe', it's confusing.
Personally, I find the default print settings of ACL to be
annoying and I reset them in my init file.
Joe Marshall wrote:
>
> "Jochen Schmidt" <···@dataheaven.de> wrote in message
> ·················@rznews2.rrze.uni-erlangen.de...
>>
>>
>> I strongly advise against setting variables like *print-circle* to
>> another
>> value. You can easily mess up your environment by doing such things.
>
> What could you possibly mess up by having *print-circle* set to T?
For *print-circle* particular nothing more but a speed penalty for
circularity checking. I said "variables like *print-circle*" which was
meant to include other variables like *print-base* *print-readably*.
>> This is why many environments hold their own bindings while evaluating
>> the buffer. This means that the *print-circle* of two different
>> buffer-evaluations are two different bindings.
>
> I can see an argument for having two different buffers have
> differing values for reader and printer behavior, but not for
> two different (and sequential) evaluations in the same buffer.
I don't think so. It is not like being unable to use the changed value
while the buffer is evaluating. If you want to make sure that the code in
the buffer uses the changed value then you should do this change in the
code you want to evaluate. So you will not be confused if your application
behaves different next time you load it. Such things can of course still
happen with variables not "protected" in such ways but I think that it is
no bad idea to do this for the printer and reader control variables.
If you do not like the ACL behaviour then be free to use another
lisp-system like Xanalys LispWorks which does not behave this way. I
personally use LispWorks and I'm quite happy with it being the way it is.
But I do not think that ACLs behaviour can be counted as a bug.
>> If you want to set *print-circle* to T you should do it locally by doing
>> something like the following:
>>
>> (defun foo ()
>> (let ((*print-circle* t))
>> (bar)))
>>
>> Since *print-circle* is a special variable it will be visible in the
>> dynamic extent of BAR.
>
> But this has no effect on what is printed at top level when foo
> exits.
This is true. And I would find it confusing if you could not set the
printer/reader-variables in a listener so that _this_ listener uses them
for direct interaction. This is actually a different issue. I was not
talking about setting this variables in your listener but about trying to
set them in a buffer to evaluate and then thinking that it should have
global effect.
>> The fact that you could not set *print-circle* to T globally is not a
>> language issue but an IDE issue. It is actually a safety feature of
>> ACL and a strong sign that you do something wrong.
>
> This is absurd. Having *print-circle* be NIL means that attempting
> to print a circular structure will hang (or print infinite text).
> This isn't `safe', it's confusing.
Having *print-circle* to T by default will mean always checking for
circularity which may not be needed or wanted too. I would have said the
same if the default would have been T and someone wants to set it globally
to NIL the way the OP did it. I think it should definitely be possible to
change the global defaults (and actually it is of course possible). This
has nothing to do with the issue of having local bindings of this variables
when a buffer evaluates.
> Personally, I find the default print settings of ACL to be
> annoying and I reset them in my init file.
This was not my point so go ahead. If you want to shout to anyone about
this topic do it to the ones who can change something about it (-> Franz)
but not me.
ciao,
Jochen
--
http://www.dataheaven.de
* Jochen Schmidt <···@dataheaven.de>
| For *print-circle* particular nothing more but a speed penalty for
| circularity checking.
A speed penalty for the return value of evaluated forms in an interface
based on sockets and printing values? You cannot be for real. This is
just too damn silly to be an honest opinion. Who is paying you for this?
| I said "variables like *print-circle*" which was meant to include other
| variables like *print-base* *print-readably*.
And if you _want_ a different print base? Are you just trolling?
| If you want to make sure that the code in the buffer uses the changed
| value then you should do this change in the code you want to evaluate.
What is wrong with you? Why do you not understand the value seen by the
printer of the return value of a form _cannot_ be changed by the form
itself? My god, you cannot have thought about this issue at _all_!
Do you know how a read-eval-print loop works at all?
| If you do not like the ACL behaviour then be free to use another
| lisp-system like Xanalys LispWorks which does not behave this way.
Ah, there we have it. You are an idiot marketing droid from Xanalys!
"Do not change a trivial little thing, change your whole environment!"
What kind of mindlessness is required to even _suggest_ this?
| This is true. And I would find it confusing if you could not set the
| printer/reader-variables in a listener so that _this_ listener uses them
| for direct interaction.
Hello? Anybody home? This is exactly what the discussion is about!
| This is actually a different issue. I was not talking about setting this
| variables in your listener but about trying to set them in a buffer to
| evaluate and then thinking that it should have global effect.
You have _no_ idea what this is about, do you?
| Having *print-circle* to T by default will mean always checking for
| circularity which may not be needed or wanted too.
What? The other option is to limit the length or the level of the output
so you cannot look at what really happened. Well, the third option is to
die horribly if you have circular structures, and that is a serious bug.
| I would have said the same if the default would have been T and someone
| wants to set it globally to NIL the way the OP did it. I think it should
| definitely be possible to change the global defaults (and actually it is
| of course possible).
Actually it is, eh? Dude, you are _really_ clueless. Quit yapping if
you do not even have the humility to ask before you spout idiotic drivel!
| This has nothing to do with the issue of having local bindings of this
| variables when a buffer evaluates.
Yes, it does. Clueless moron. Stop spreading disinformation in the
guise of marketing for Xanalys, will you?
How _fantastically_ annoying it is to counter the nonsense and drivel
from people who are so clueless that they do not even recognize when they
are out of clues even before they start talking. Man!
Sheesh, some people.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
Post with compassion: http://home.chello.no/~xyzzy/kitten.jpg
* Jochen Schmidt <···@dataheaven.de>
| I strongly advise against setting variables like *print-circle* to
| another value.
Are you for real? This problem concerns the inability of an evaluated
form in the Emacs-Lisp Interface to return a circular structure. If
anything, the binding of *print-circle* should be forced to true, to
prevent this problem.
| You can easily mess up your environment by doing such things.
What nonsense! If you make these kinds of changes, it is because you
want to, and if your environment cannot survive changing them, it is such
a pile of crap that you are much better off without it.
| This is why many environments hold their own bindings while evaluating
| the buffer. This means that the *print-circle* of two different
| buffer-evaluations are two different bindings. If you want to set
| *print-circle* to T you should do it locally by doing something like the
| following:
|
| (defun foo ()
| (let ((*print-circle* t))
| (bar)))
|
| Since *print-circle* is a special variable it will be visible in the
| dynamic extent of BAR.
And this relates to printing return value how? Please _think_!
| The fact that you could not set *print-circle* to T globally is not a
| language issue but an IDE issue. It is actually a safety feature of ACL
| and a strong sign that you do something wrong.
Riiiight. Having your Emacs and Lisp session die on you because you
return a prefectly valid structure _and_ you asked for *print-circle* to
be true is a hint you are doing something wrong. Gimme a fucking break!
Sheesh, some people.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
Post with compassion: http://home.chello.no/~xyzzy/kitten.jpg
* ·······@arti.vub.ac.be
| I even put the line (1) into my ~/.clinit.cl. *print-circle* remains NIL
| :-(
I had to investigate this because it appears to be the only variable that
this happens to. Now, there are some curious bindings in the Lisp Emacs
Protocol implementation. editor-connection-server binds *print-circle*
to nil, and the function that actually evaluates the form that the editor
server has received also specifically binds *print-circle* to nil. This
is very strange. There are no comments explaining this in the code,
there is nothing in the documentation that I can find to explain this,
but *print-circle* clearly is treated very specially. This curiosity
means that evaluating any form that produces a circular form of any kind
will cause that Lisp evaluation process to produce infinite amounts of
output. Now, Franz Inc has specifically ensured that *print-circle* is
nil, so this is no ordinary bug, but a design choice. This is very odd.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
Post with compassion: http://home.chello.no/~xyzzy/kitten.jpg
From: Brian P Templeton
Subject: Re: representing a network in lisp
Date:
Message-ID: <87g01xor4j.fsf@tunes.org>
Erik Naggum <····@naggum.net> writes:
> * ·······@arti.vub.ac.be
> | What is wrong with the above is that I put a prompt in front of the
> | expressions which indeed makes it seem I evaluate the expressions within
> | the same listener.
>
> It is quite common to make a number of special variables local to each
> listener. This is generally considered a very useful feature.
>
> | And I still do not know how to solve my problem since I would like
> | *print-circle* to be true _always_.
>
> See the macro top-level:setq-default.
>
> | Nevertheless, I find Franz documentation sometimes very confusing.
>
> Unlike the old paper manuals, last made for release 4.3 as far as I can
> see, it is hard to just _read_ HTML-based documentation. In fact, this
> is my biggest gripe with "hypertext" in the first place. But I digress.
>
Hypertext /= HTML. I like both hypertext and paper docs (and dislike
HTML).
> ///
> --
> In a fight against something, the fight has value, victory has none.
> In a fight for something, the fight is a loss, victory merely relief.
>
> Post with compassion: http://home.chello.no/~xyzzy/kitten.jpg
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
* Erik Naggum
> Unlike the old paper manuals, last made for release 4.3 as far as I can
> see, it is hard to just _read_ HTML-based documentation. In fact, this
> is my biggest gripe with "hypertext" in the first place. But I digress.
* Brian P Templeton
| Hypertext /= HTML.
But HTML is "hypertext" in sarcastic-quotes.
| I like both hypertext and paper docs (and dislike HTML).
What kinds of real hypertext systems do you have available?
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
Post with compassion: http://home.chello.no/~xyzzy/kitten.jpg
From: Brian P Templeton
Subject: Re: representing a network in lisp
Date:
Message-ID: <87adrxdld8.fsf@tunes.org>
Erik Naggum <····@naggum.net> writes:
> * Erik Naggum
>> Unlike the old paper manuals, last made for release 4.3 as far as I can
>> see, it is hard to just _read_ HTML-based documentation. In fact, this
>> is my biggest gripe with "hypertext" in the first place. But I digress.
>
> * Brian P Templeton
> | Hypertext /= HTML.
>
> But HTML is "hypertext" in sarcastic-quotes.
>
OK.
> | I like both hypertext and paper docs (and dislike HTML).
>
> What kinds of real hypertext systems do you have available?
>
Xanadu 88 (aka Udanax Green; see <URL:http://www.udanax.com/) is
available, but not complete and probably not maintained. I'm currently
designing a metatext system, NOPE (probably will be renamed to MOX).
> ///
> --
> In a fight against something, the fight has value, victory has none.
> In a fight for something, the fight is a loss, victory merely relief.
>
> Post with compassion: http://home.chello.no/~xyzzy/kitten.jpg
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
·······@arti.vub.ac.be writes:
> => (setf *print-circle* t)
> T
>
> then *print-circle* remains nil:
>
> => *print-circle*
> NIL
>
> I use Allegro Common Lisp 6.0. ...
There is a top level command :printer-variables that prompts for
new values for various printer control variables.
From: Friedrich Dominicus
Subject: Re: representing a network in lisp
Date:
Message-ID: <8766329uxo.fsf@fbigm.here>
·······@arti.vub.ac.be writes:
>
> => *print-circle*
> NIL
>
> I use Allegro Common Lisp 6.0. In their documentation the variable
> *print-circle* is part of the common-graphcs package wich does not
> exist for linux systems.
I think it's a bug than because *print-circle* is part of the Standard
so it should be available in the CL-USER Package.
Regards
Friedrich
* Friedrich Dominicus
| I think it's a bug than because *print-circle* is part of the Standard
| so it should be available in the CL-USER Package.
The bug is in Joachim's reporting of the facts. Do not believe people
who say something so unlikely and so easily checked -- check it out or
ask for confirmation. Some people are simply untrained in reporting
facts and their confusion is contagious because they report their own
confused conclusions as if they were the facts they concluded from.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
Post with compassion: http://home.chello.no/~xyzzy/kitten.jpg