Is this a bug in CMU Common Lisp 19c Release (19C) ?
Robert Maas, http://tinyurl.com/uh3t
returning two values, a number and a list of numbers:
(parse1p-specrecs-try line4 0 g*wget-line4-parserules :listall t)
44
(0 40 43 44)
But when I make exactly the same call from inside a
multiple-value-setq form, in an attempt to capture those two
values, it crashes horribly:
(multiple-value-setq (ix1 ixs)
(parse1p-specrecs-try line4 0 g*wget-line4-parserules :listall t))
Help! 12 nested errors. KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded.
Debug (type H for help)
%primitive halt called; the party is over.
LDB monitor
ldb>
Rob Warnock
+---------------
| But when I make exactly the same call from inside a
| multiple-value-setq form, in an attempt to capture those two
| values, it crashes horribly:
|
| (multiple-value-setq (ix1 ixs)
| (parse1p-specrecs-try line4 0 g*wget-line4-parserules :listall t))
| Help! 12 nested errors. KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded.
Were the variables IX1 & IXS previously either declared globally
or bound locally? I can imagine some implementation blowing up if not.
Also, try using MULTIPLE-VALUE-BIND instead and see what happens.
If it doesn't blow up, then you can emulate the MULTIPLE-VALUE-SETQ with:
(multiple-value-bind (tmp1 tmp2)
(parse1p-specrecs-try line4 0 g*wget-line4-parserules :listall t))
(setq ix1 tmp1 ixs tmp2))
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Robert Maas, http://tinyurl.com/uh3t
> Were the variables IX1 & IXS previously either declared globally
> or bound locally?
Taking full advantage of the interactive REP, they weren't declared
at all, because I was debugging one line of code at a time with NO
intention of making them permanently-declared globals. Eventually
if I could have gotten that code to work, it would all have been
incorporated into a function body, at which point those would have
been lexically-bound variables (in a PROG most likely).
> I can imagine some implementation blowing up if not.
Older versions of CMUCL never blew up because of undeclared free
variables treated as global, and never ever ever gave a LDB
debugger trap before under *any* circumstances whatsoever. What
*did* happen sometimes was coredump-abend. And that happened only
very rarely under different circumstances.
Now it's possible the admin on the Unix ISP built this particular
version of CMUCL with LDB instead of coredump as behaviour in case
of fatal error. But still these primitive halts and consequent LDB
traps are much more frequent on this new version than ever with
older versions on other shell account, and under totally innocent
circumstances where I'm not doing anything unusual at all.
> Also, try using MULTIPLE-VALUE-BIND instead and see what happens.
It'll be another day or so before I have built my interactive
session up to that point again, and the sequence to that point will
be grossly different, so I doubt it'll re-create whatever caused
the problem, so I doubt switching to MULTIPLE-VALUE-BIND will show
anything conclusive about what fixes the problem.
> If it doesn't blow up
Hundreds or thousands of times over the years from 2000 to last
week MULTIPLE-VALUE-SETQ never blew up, on the old shell machine
using older versions of CMUCL. If it doesn't blow up the next
thousand times I do multiple value bind it won't prove anything.
> then you can emulate the MULTIPLE-VALUE-SETQ with:
> (multiple-value-bind (tmp1 tmp2)
> (parse1p-specrecs-try line4 0 g*wget-line4-parserules :listall t))
> (setq ix1 tmp1 ixs tmp2))
Ugly! And if I do that in my interactive session, in paranoid
attempt to avoid the LDB crash, then I'll be stuck with that in my
production code, ugly!
Do you perhaps know how to use LDB in a CMUCL context to get some
clue what kind of primitive halt occurred where within CMUCL?
Note: Since my account was moved to the new shell machine nearly a
week ago, my CGI application to send e-mail, which was working
reliably for the past 6 years using the old version of CMUCL on the
old shell account, has crashed in the same way several times,
forcing me to save my message text to a file and e-mail just the
URL instead.
Update: It happened again just now (well a half hour ago before I
started checking for followups to my earlier report and then
composing this response. I had been using, without problem, this
function on the old shell account using an older version of CMUCL:
(defun from-mac-new-user+pw (cv)
(prog (date msgnum textstr pr acct)
(multiple-value-setq (date msgnum textstr) (convow+c-dmt cv))
(length (setq pr (read-from-string textstr)))
(setq acct (car pr))
(length (push pr g*YM-assoc-acct+pw))
(format t "~&** g*YM-assoc-acct+pw has been updated with new acct+pw~%")
(acct-set-global-verbose acct)
(format t "Now is a good time to: ~S"
(subst acct :ACCT '(unix-yahoo-acct-verify-pw :ACCT)))
))
Then just now (an hour ago now) I added some more code, resulting
in this new function definition:
(defun from-mac-new-user+pw (cv)
(prog (date msgnum textstr pr acct oldpr)
(multiple-value-setq (date msgnum textstr) (convow+c-dmt cv))
(length (setq pr (read-from-string textstr)))
(setq acct (car pr))
(when (setq oldpr (assoc acct g*YM-assoc-acct+pw :test #'string-equal))
(when (string= (cadr pr) (cadr oldpr))
(format t "~&** That password already known here!~%") (go skippush))
(error "I have a different password here already."))
(length (push pr g*YM-assoc-acct+pw))
(format t "~&** g*YM-assoc-acct+pw has been updated with new acct+pw~%")
skippush
(acct-set-global-verbose acct)
(format t "Now is a good time to: ~S"
(subst acct :ACCT '(unix-yahoo-acct-verify-pw :ACCT)))
))
Then when I tried to execute the following line of code from the REP:
(from-mac-new-user+pw '("Oomoopai fiefolo loisuilee woymeboa leyfoo jeyraco veveu hebaucea pisokiepey zeushoocaa ripootoa reilai sepea hoajayburee hoamoytu soapaypei nuiji hejoybee jeucheizaasai shoiwezuiday weenoo kauleufei ceyfeamo viehay voagoywea puhobee meysoajau weybeeso."))
this happened:
Help! 12 nested errors. KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded.
Debug (type H for help)
(UNIX::SIGBUS-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP #x47FE1E7C))
%primitive halt called; the party is over.
LDB monitor
ldb>
Debugging that line-by-line before re-defining the function shows
that it *should* have seen the password same as before and thus
executed the (go skippush) etc.
After I post this, and send e-mail to the admin advising him of the
possible bug and pointing to this thread, it'll take me about a
half hour to re-start everything up to the point where it crashed
this last time.
Vassil Nikolov
On Sun, 04 Oct 2009 18:44:12 -0700, seeWeb...@rem.intarweb.org (Robert Maas, http://tinyurl.com/uh3t) said:
> ...
> Help! 12 nested errors. KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded.
> Debug (type H for help)
> (UNIX::SIGBUS-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP #x47FE1E7C))
> %primitive halt called; the party is over.
> LDB monitor
ldb>
I believe you could say
ldb> backtrace
here and see if this sheds more light; also
ldb> help
for more commands.
---Vassil.
--
"Even when the muse is posting on Usenet, Alexander Sergeevich?"
Robert Maas, http://tinyurl.com/uh3t
function call (with different parameter because that uses a random
key that is covertly re-generated each time I re-start the
public-key Mac/Unix link, which must be done each time either CMUCL
on Unix or PowerLisp on Mac is re-started), and with slightly
different function definition from before:
(defun from-mac-new-user+pw (cv)
(prog (date msgnum textstr pr acct oldpr)
(unix-check-yahoo-acct+pw)
(multiple-value-setq (date msgnum textstr) (convow+c-dmt cv))
(length (setq pr (read-from-string textstr)))
(setq acct (car pr))
(when (setq oldpr (assoc acct g*YM-assoc-acct+pw :test #'string-equal))
(when (string= (cadr pr) (cadr oldpr))
(format t "~&** That password already known here!~%") (go skippush))
(error "I have a different password here already."))
(length (push pr g*YM-assoc-acct+pw))
(format t "~&** g*YM-assoc-acct+pw has been updated with new acct+pw~%")
skippush
(acct-set-global-verbose acct)
(format t "Now is a good time to: ~S"
(subst acct :ACCT '(unix-yahoo-acct-verify-pw :ACCT)))
))
Since then I uploaded the very latest version of the two source
files that I was slightly modifying up to that above-reported
crash, but which hasn't been modified any further since then, so
local variables used as globals won't be the problem if it happens
again. Then I went through the whole start-up process again,
carefully copying to one place the notes for how to get to this
situation again, so that I can reduce the re-start-build-everything
time to less than an hour each time I need to try again. Finally I
copied*pasted, from Mac to Unix, the latest version (with latest
random number used in public-key Mac/Unix cryptosystem) of the
function-call that crashed:
(from-mac-new-user+pw '("Eujie wairageure saageyjunai guwei beajoyga nurepadie waboarai kaitutoi fuzaudepoi coazaypeu juhoyshishu roisaicie baihaa puigejo poihaatoiwui joifieta zoocovaichi peese naiveaci saugo vaigeydoi vepau shoamuke wuveenirea zoishayvoi kiniezeufi."))
But it didn't crash this time around!! It worked exactly as
originally expected when I wrote final version of the code several
hours ago:
** That password already known here!
* g*current-YM-acct has been set, ready to use it.
Now is a good time to: (UNIX-YAHOO-ACCT-VERIFY-PW "ChineseEnglish76")
NIL
So next I tried the next step after that as recommended just above:
(UNIX-YAHOO-ACCT-VERIFY-PW "ChineseEnglish76")
and it started to work just fine, but then it crashed:
;
; Warning: This function is undefined:
; SLEEP20
(password known)01234Help! 12 nested errors. KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded.
Debug (type H for help)
(UNIX::SIGBUS-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP #x47FE1E7C))
%primitive halt called; the party is over.
LDB monitor
ldb> quit
Really quit? [y] y
> man ldb
No manual entry for ldb
This is really looking like a corrupted core-image that
*eventually* strikes in some unrelated code shortly after the
corruption has occurred. Since it crashed twice within the same
function call (I had planned to trace that call and functions it
calls from there, to narrow down where it really crashes, which is
why I streamlined the process of building the situation to that
point) and then this last time in the very next function call after
it, I'm guessing that extra-long line being passed from stdin to
CMUCL might be overrunning some C-language buffer that isn't
range-checked, causing core-image corruption.
I got on Google Groups to check for follow-ups and get the
message-ID of my previous update so that I could follow-up my own
article, but saw that Vassil Nikolov had posted a follow-up
already, so I'm doing a follow-up of Vassil's article now:
> From: Vassil Nikolov <vniko...@pobox.com>
> I believe you could say
> ldb> backtrace
> here and see if this sheds more light;
OK, next time it crashes like that, I'll try your suggestion, and
post the result here. I suspect this will be a machine-language
backtrace showing internal workings of CMUCL using C-language
labels if any, which would be meaningless to me as a mere user of
CMUCL, but I'll see when I try it.
> also
> ldb> help
> for more commands.
I'll try that too. Thanks.
Barry Margolin
> Update: The crash happened again, executing exactly the same
> function call (with different parameter because that uses a random
> key that is covertly re-generated each time I re-start the
> public-key Mac/Unix link, which must be done each time either CMUCL
> on Unix or PowerLisp on Mac is re-started), and with slightly
> different function definition from before:
>
> (defun from-mac-new-user+pw (cv)
> (prog (date msgnum textstr pr acct oldpr)
> (unix-check-yahoo-acct+pw)
> (multiple-value-setq (date msgnum textstr) (convow+c-dmt cv))
> (length (setq pr (read-from-string textstr)))
> (setq acct (car pr))
> (when (setq oldpr (assoc acct g*YM-assoc-acct+pw :test #'string-equal))
> (when (string= (cadr pr) (cadr oldpr))
> (format t "~&** That password already known here!~%") (go skippush))
> (error "I have a different password here already."))
> (length (push pr g*YM-assoc-acct+pw))
> (format t "~&** g*YM-assoc-acct+pw has been updated with new acct+pw~%")
> skippush
> (acct-set-global-verbose acct)
> (format t "Now is a good time to: ~S"
> (subst acct :ACCT '(unix-yahoo-acct-verify-pw :ACCT)))
> ))
I don't know if it's related to the problem, but what's the point of the
two LENGTH expressions whose values are never used? LENGTH has no side
effects.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
Robert Maas, http://tinyurl.com/uh3t
- re-starting CMUCL,
- loading all the source-code modules I need,
- running the preliminaries to set up the public-key cryptosystem
between Mac and Unix, and
- finally copy&paste the two function calls, one of which crashes CMUCL,
down to just a half hour each time around. Here's the latest transcript-tail:
* (from-mac-new-user+pw '("Eipay gakuitoo maufaze wayveihaizee joozayzaucu payfaishe chezoo chuilugoyho toopoakaihui reuzeyboy nietiepoa rehihu ruigiepadea noylauru koyreu timekea kojeuvugoy deesocho hiefoovauchey roche keumaavuicoi riki jauroapoy buizeesheyce koomey voinoochay."))
** That password already known here!
* g*current-YM-acct has been set, ready to use it.
Now is a good time to: (UNIX-YAHOO-ACCT-VERIFY-PW "ChineseEnglish76")
NIL
* (UNIX-YAHOO-ACCT-VERIFY-PW "ChineseEnglish76")
;
; Warning: This function is undefined:
; SLEEP20
(password known)0123456789AHelp! 12 nested errors. KERNEL:*MAXIMUM-ERROR-DEPTH*
exceeded.
Debug (type H for help)
(UNIX::SIGBUS-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP #x47FE1E7C))
%primitive halt called; the party is over.
LDB monitor
ldb> backtrace
Backtrace:
0: Foreign fp = 0x47fd75b8, ra = 0x804cfc3
1: Foreign fp = 0x47fd76f8, ra = 0x804d202
2: Foreign fp = 0x47fd7748, ra = 0x804d251
3: Foreign fp = 0x47fd7758, ra = 0x804e424
4: Foreign fp = 0x47fd77f8, ra = 0x80523d9
5: Foreign fp = 0x47fd79c8, ra = 0xffffefd4
6: COMMON-LISP::ERROR
7: UNIX::SIGSEGV-HANDLER
8: UNIX::SIGSEGV-HANDLER
9: Foreign fp = 0x47fd7aa8, ra = 0x80526bc
10: Foreign fp = 0x47fd7ad8, ra = 0x8052523
11: Foreign fp = 0x47fd7b08, ra = 0x804f2ab
12: Foreign fp = 0x47fd7b28, ra = 0x8052c23
13: Foreign fp = 0x47fd7cfc, ra = 0xffffefd4
14: COMMON-LISP::ERROR
15: DEBUG::GET-FILE-TOP-LEVEL-FORM
16: DEBUG::GET-TOP-LEVEL-FORM
17: DEBUG::PRINT-CODE-LOCATION-SOURCE-FORM
18: DEBUG::PRINT-FRAME-CALL
19: DEBUG::DEBUG-LOOP
20: DEBUG::INTERNAL-DEBUG
21: "DEFUN ERROR-ERROR"
22: LISP::%WITH-STANDARD-IO-SYNTAX
23: KERNEL::ERROR-ERROR
24: COMMON-LISP::ERROR
25: UNIX::SIGBUS-HANDLER
26: UNIX::SIGBUS-HANDLER
ldb> help
help Display this info
backtrace backtrace up to N frames
call call FUNCTION with ARG1, ARG2, ...
catchers Print a list of all the active catchers.
context print interrupt context number I.
dump dump memory starting at ADDRESS for COUNT words.
exit Exit this instance of the monitor.
flush flush all temp variables.
gc collect garbage (caveat collector).
grab-signals Set the signal handlers to call LDB.
purify purify (caveat purifier).
print print object at ADDRESS.
quit quit.
regs display current lisp regs.
search search for TYPE starting at ADDRESS for a max of COUNT words.
ldb> regs
CSP = 0x47FD7998
FP = 0x00000000
BSP = 0x380006F0
DYNAMIC = 0x48000000
ALLOC = 0x490B2000
TRIGGER = 0x000000AE
STATIC = 0x291CF418
RDONLY = 0x113A1A90
ldb> catchers
0x47FD7E48:
uwp: 0x0000001C
fp: 0x100B5852
code: 0x0x1c
entry: 0x0000001c
tag: 0x00000000: even fixnum: 0
0x100460E9:
uwp: 0xF48B0AEB
fp: 0x0004BB52
code: 0x0x1c
entry: 0x0deb0000
tag: $1= 0x89fc5389: function pointer(invalid address)
Trace/BPT trap
> context
context: Command not found.
> gc
gc: Command not found.
> quit
quit: Command not found.
> ;oops, I've been talking to the shell the last 3 commands.
Unmatched '.
>
So does any of that backtrace, or regs or catchers, give anyone a
clue what might be going wrong inside CMUCL? The way the ldb of
catchers itself bombed out to the shell seems to confirm that the
core-image is badly trashed.
I see that Barry Margolin already posted a followup to my previous
update, so once again instead of following up my own previous
article, I can follow-up Barry's article:
> > (defun from-mac-new-user+pw (cv)
> > (prog (date msgnum textstr pr acct oldpr)
> > (unix-check-yahoo-acct+pw)
> > (multiple-value-setq (date msgnum textstr) (convow+c-dmt cv))
> > (length (setq pr (read-from-string textstr)))
> > (setq acct (car pr))
> > (when (setq oldpr (assoc acct g*YM-assoc-acct+pw :test #'string-equal))
> > (when (string= (cadr pr) (cadr oldpr))
> > (format t "~&** That password already known here!~%") (go skippush))
> > (error "I have a different password here already."))
> > (length (push pr g*YM-assoc-acct+pw))
> > (format t "~&** g*YM-assoc-acct+pw has been updated with new acct+pw~%")
> > skippush
> > (acct-set-global-verbose acct)
> > (format t "Now is a good time to: ~S"
> > (subst acct :ACCT '(unix-yahoo-acct-verify-pw :ACCT)))
> > ))
> From: Barry Margolin <bar...@alum.mit.edu>
> I don't know if it's related to the problem, but what's the point
> of the two LENGTH expressions whose values are never used? LENGTH
> has no side effects.
The whole point of this exercise is that I can covertly upload
account names and passwords from my Macintosh to Unix over a VT100
dialup, and if somebody tapping my phone line watches *everything*
I send and receive, both the uploads of all source code and the
actual upload of user+password itself, *still* there's no
computationally feasible way to learn the password.
When I originally developed that function, and then every time I
change the source-code again, I debug it by manually copying and
pasting one expression at a time (one PROG statement, or one
smaller sub-expression) over VT100 dialup, so the REP shows the
value of each such expression, which somebody tapping my phone line
would be able to see.
(length (setq pr (read-from-string textstr)))
obtains the (account password) pair, which I most definitely do
*not* want an eavesdropper to be able to see, hence the LENGTH
around it to allow the inner SETQ etc. to execute but hide the
account-password pair from visibility. Letting eavesdropper see it
would allow said person to get into my geocities account and delete
all the files I'm urgently trying to rescue before GeoCities closes
later this month, as well as get into my e-mail account and wreak
disaster.
(length (push pr g*YM-assoc-acct+pw))
pushes that pair onto a list which contains *all* the account names
and corresponding passwords so-far uploaded. Letting an
eavesdropper see that even once would allow that person to get into
*all* my Yahoo! Mail and Geocities accounts and wreak havoc
multipled by number of accounts. Hence it's even more urgent to
protect that line of code with LENGTH.
I can't afford to remove the LENGTH wrapper and then carefully put
it back in when I'm debugging the code. Just one mistake, one
slip-up, where I forget to wrap LENGTH around it, and all my work
is lost.
I'm currently building a new economic system to replace capitalism,
see tinyurl.com/NewEco for my usual style of blabbering, and
tinyurl.com/Portl1 for the current operational system. IRS and SEC
and the Fed and the Treasury and other agencies would *love* to
learn my passwords and trespass into my system and destroy it so
that I can't compete with their monopoly on how people get jobs,
whereby *only* people with lots of money can hire people, and only
people who are friends with people who have lots of money can get
jobs, whereas NewEco will allow *anyone* to hire people, using
NewEco labor-time credit instead of $cash$ to pay them, using a
bidding system for micro-contracts (no contract longer than 440
seconds, i.e. 6 minutes 20 seconds), thus making it easy for
workers to jump in and out without taking a big risk, and making it
impossible for employers to restrict who does each micro-contract,
and thus spreading the contracts among everyone who can do them
instead of locking some people into jobs they are afraid to lose
and locking everyone else out of a job. I can't afford to make it
easy for any of those agencies to learn either my login passwords
or my public-key prime-pairs, and thus destroy my system, hence all
this covert upload and very carefully preventing any confidential
information from being sent to the REP or printed out by the REP.
Note: The current work, where the new version of CMUCL is crashing
horribly, is for the purpose of rescuing my GeoCities files before
they close later this month. I'm trying to automate the process of
logging into my Yahoo/GeoCities accounts and browsing directories
that are hidden from 'wget', while using 'wget' whereever possible.
These GeoCities files will eventually become a major part of
NewEco, but right now I'm in a desparate race to finish automating
the process of cataloging all my GeoCities files so that I can
download them automatically and upload them somewhere more stable
before they all suddenly dissappear when GeoCities closes. I can't
afford to try to do it all manually and risk overlooking hundreds
of files and never realizing I've lost them all and GeoCities will
be gone so there will never be another chance to rescue them.
Robert Maas, http://tinyurl.com/uh3t
posted the previous update until the time I got everything restored
to the point where CMUCL hit the crash again and thus I started
composing this further update:
I tried copying the two very-long strings from PowerLisp to an edit
buffer and broke into pieces of reasonable length, and flushed the
NUL (^@) character at the end of each that PowerLisp added, before
copying and pasting across VT100 link to CMUCL REP, instead of copy
directly from PowerLisp and paste directly across VT100 as before,
to protect against buffer overrun in stdio, but still CMUCL crashed
at nearly the same point as the previous time. Transcript below,
where I rearranged the ldb commands to get a couple more in before
one of them crashes out to the shell:
(from-mac-new-user+pw '("Aimei choadieneepoy sayliecudo faileicheu heechui
hoize voobeybei keifo toyfoiwie ceachaazoy shaisura reihee reuvabay roykieloa
paiweikoi shoyseagoodey zuigau chauloybea choakaymenoi veahebeu goifutai
piejau wauheydoy gunezechoa vanuifee zaishoogo laana tuimoihoy."))
** That password already known here!
* g*current-YM-acct has been set, ready to use it.
Now is a good time to: (UNIX-YAHOO-ACCT-VERIFY-PW "ChineseEnglish76")
NIL
* (UNIX-YAHOO-ACCT-VERIFY-PW "ChineseEnglish76")
;
; Warning: This function is undefined:
; SLEEP20
(password known)0123456789AHelp! 12 nested errors. KERNEL:*MAXIMUM-ERROR-DEPTH*
exceeded.
Debug (type H for help)
(UNIX::SIGBUS-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP #x47FE1E7C))
%primitive halt called; the party is over.
LDB monitor
ldb> regs
CSP = 0x47FD7998
FP = 0x00000000
BSP = 0x380006F0
DYNAMIC = 0x48000000
ALLOC = 0x490B3000
TRIGGER = 0x000000AE
STATIC = 0x291CF418
RDONLY = 0x113A1A90
ldb> context
There are 14 interrupt contexts.
Printing context 13
EAX: 0x00000010: even fixnum: 4
ECX: $1= 0x28f9b7d7: other pointer
EDX: $nil= 0x28f0000b: list pointer (NIL)
EBX: $1= 0x28f9b7d7: other pointer
ESP: 0x47fd7998: even fixnum: 301948518
EBP: 0x47fd79c8: even fixnum: 301948530
ESI: 0x47fd7994: odd fixnum: 301948517
EDI: 0x000000c8: even fixnum: 50
PC: 0x10008f29
ldb> gc
** collect_garbage: last_gen = 672335384. Doing a level 0 GC.
ldb> gc
** collect_garbage: last_gen = 672335384. Doing a level 0 GC.
ldb> gc
** collect_garbage: last_gen = 672335384. Doing a level 0 GC.
ldb> catchers
0x47FD7E48:
uwp: 0x0000001C
fp: 0x100B5852
code: 0x0x1c
entry: 0x0000001c
tag: 0x00000000: even fixnum: 0
0x100460E9:
uwp: 0xF48B0AEB
fp: 0x0004BB52
code: 0x0x1c
entry: 0x0deb0000
tag: $2= 0x89fc5389: function pointer(invalid address)
Trace/BPT trap
>
Robert Maas, http://tinyurl.com/uh3t
decided to try a short-cut where I don't do any of the Mac/Unix
public-key stuff, instead I just load all the sourcefiles on Unix
and then do just these (reducing re-create-problem time to about 15
minutes from when I posted previous update until I looked at the
clock sometime during the LDB interaction):
(unix-set-date-start-boot-to-mac)
(g-load-unix824)
(unix-yah-restore-acct+pw)
(unix-yahoo-acct-verify-pw "ChineseEnglish76")
That last function (lots of stuff called from inside it) runs for
quite a while, re-training my lynx scraper for the new output
produced by the new version of lynx installed on this new shell
account, specifically it re-trains what to expect for the start-up
('home') page appearance on-screen, what to expect for the screen
that appears when the = command is given to see current page and
link, and what to expect for the screen of options that appears
when the d (download through link) command is given. When I confirm
that I want to write out the updated expected-lynx-output file for
that last download screen, but before it starts to write that file,
that's when it died this last time so-far. Transcript from that
final y-or-n-p forward:
Overwrite file with this new expected-string?y
Help! 12 nested errors. KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded.
Debug (type H for help)
(UNIX::SIGBUS-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP #x47FE1E7C))
%primitive halt called; the party is over.
LDB monitor
ALLOC = 0x4904D000
TRIGGER = 0x000000AE
STATIC = 0x291CF418
RDONLY = 0x113A1A90
ldb> context
There are 14 interrupt contexts.
Printing context 13
EAX: 0x00000010: even fixnum: 4
ECX: $1= 0x28f9b7d7: other pointer
EDX: $nil= 0x28f0000b: list pointer (NIL)
EBX: $1= 0x28f9b7d7: other pointer
ESP: 0x47fd7998: even fixnum: 301948518
EBP: 0x47fd79c8: even fixnum: 301948530
ESI: 0x47fd7994: odd fixnum: 301948517
EDI: 0x000000c8: even fixnum: 50
PC: 0x10008f29
ldb> catchers
0x47FD7E48:
uwp: 0x0000001C
fp: 0x100B5852
code: 0x0x1c
entry: 0x0000001c
tag: 0x00000000: even fixnum: 0
0x100460E9:
uwp: 0xF48B0AEB
fp: 0x0004BB52
code: 0x0x1c
entry: 0x0deb0000
tag: $2= 0x89fc5389: function pointer(invalid address)
Trace/BPT trap
>
Does any of that LDB output mean anything to any of you in regard
to what could be causing CMUCL to die so horribly? By the way, it
wrote this to disk:
1 -rw------- 1 rem user 0 Oct 5 02:04 lisp.core
I didn't think it'd be writing that, so I didn't check the clock to
see the times when it first crashed to LDB and when LDB crashed to
shell to see which of those two times was when it wrote the empty
coredump.
Robert Maas, http://tinyurl.com/uh3t
as before, hoping that since some of the lynx-scraper re-training
was already completed it might get further this next time. I was
right. It had already re-trained what to expect as output from lynx
when:
- Lynx is first started and it displays the start-up ('home') page;
- The = command is given to see current page and link;
- Screen of options that appears when the d (download through link)
command is given.
So it scraped all that stuff without any further re-training, and
this time around it re-trained each of the following (except the
last):
- Download to disk file prompts for a filename;
- When it returns to the toplevel ('home') page after that;
- When it refreshes that toplevel ('home') page;
- After it clicks on the link to my home directory, top of that shows.
After it shows me that screen (for debugging, so I can understand
where lynx is at the moment), when it offers to show me differences
between what was expected and what it actually got, it crashes after I
type the response to the y-or-n-p but before it actually shows me the
differences. I'm guessing it is *inside* the call to y-or-n-p where it
dies. I'll have to trace it next time around. Immediately after
posting the previous update, I started remembering that StarTrek-TNG
episode where the Enterprise keeps getting destroyed in a time loop
and Lt. Cmdr. Data figures out a way to covertly communicate a coded
message around the loop. That ST-TNG episode is coming to my mind
again now as I start to issue the LDB commands then copy+paste the
latest transcript here-below:
<<< /home/users/rem/ directory (p1 of 3
Current directory is /home/users/rem/
drwx------ 2 rem user 14 Jan 7 2002 11-Clubs/
-rw------- 1 rem user 11521 Nov 13 2001 1t.html
drwx------ 2 rem user 11 Jan 10 2002 Cmds/
drwx------ 2 rem user 15 Jul 18 07:46 Cruft/
drwx------ 2 rem user 5 Jun 23 2007 Fifos/
drwx------ 7 rem user 7 Jan 9 2002 Files/
drwx------ 6 rem user 6 Jul 15 13:15 FromHosts/
drwx------ 13 rem user 645 Oct 5 02:33 LispWork/
drwx------ 2 rem user 2 Jul 18 07:35 LongNames/
drwx------ 2 rem user 118 Sep 29 01:04 Mail/
drwx------ 2 rem user 4 Jan 9 2002 MaybeJunk/
drwx------ 2 rem user 2 Jul 16 16:12 MiscToSort/
drwx------ 4 rem user 4 Jul 18 07:31 Move/
drwx------ 2 rem user 44 Jul 16 00:56 MySqlWork/
drwx------ 8 rem user 8 Jul 16 16:05 OldRefKeep/
drwx------ 9 rem user 9 Jul 16 15:59 ParseSgxml/
drwx------ 6 rem user 6 Jul 18 07:25 ProgLang/
drwx------ 6 rem user 6 Jul 18 07:37 ProjectsAside/
-- press space for next page --
C)reate D)ownload E)dit F)ull menu M)odify R)emove T)ag U)pload
Show comparison of expected vs. actual text?y
Help! 12 nested errors. KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded.
Debug (type H for help)
(UNIX::SIGBUS-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP #x47FE1E7C))
%primitive halt called; the party is over.
LDB monitor
BSP = 0x38000700
DYNAMIC = 0x48000000
ALLOC = 0x49051000
> ls -lt | more
total 36173
1 -rw------- 1 rem user 0 Oct 5 02:40 lisp.core
...
> date
Mon Oct 5 02:41:22 PDT 2009
>
Comparing time when coredump written, it seems it occurred
somewhere towards the end of the LDB interactions.
I need to remember to trace y-or-n-p to see whether it crashes
before or after that function returns to its caller. I suspect that
stdio is broken in this version of CMUCL and it's dying while
*inside* y-or-n-p, and I need to test that hypothesis.
** I re-did it, this time with y-or-n-p traced. Result: The crash
happens *after* y-or-n-p returns, probably killing my hypothesis. **
Here's a more complete transcript (after I've loaded the source
files, everything after that point):
(list
(trace y-or-n-p)
(unix-set-date-start-boot-to-mac)
(g-load-unix824)
(unix-yah-restore-acct+pw)
(unix-yahoo-acct-verify-pw "ChineseEnglish76")
)
0: (Y-OR-N-P "It's now 2009.10.05 02:54:53 ?
")
It's now 2009.10.05 02:54:53 ?
y
0: Y-OR-N-P returned T
New day (40089), first message.
;Next, do this on Mac:
(UNIXDATE-SET-LOCAL-DATE+MSGNUM 40089)
Loaded table of 17 acct+pw pairs.
0: (Y-OR-N-P "Previously ~D pairs in global, loading ~D pairs from ~
disk, really do it now?"
0
17)
Previously 0 pairs in global, loading 17 pairs from disk, really do it now?y
0: Y-OR-N-P returned T
;
; Warning: This function is undefined:
; SLEEP20
(password known)0123456789AB (#=1306/659 frac=1.000) 0 (#=1216/659 frac=1.000)
(#=927/146 frac=0.993) (#=813/487 frac=1.000) (#=110/28 frac=1.000) (#=161/14
6 frac=0.068) (#=938/146 frac=0.993) (#=1233/659 frac=1.000) [Follow link...
(#=1879/155 frac=0.890) 0123456789ABCDEFGHIJ
0: (Y-OR-N-P "Show all Lynx output so-far?")
Show all Lynx output so-far?y
...(exit-trace overwritten by lynx screen output)...
<<< /home/users/rem/ directory (p1 of 3
Current directory is /home/users/rem/
drwx------ 2 rem user 14 Jan 7 2002 11-Clubs/
-rw------- 1 rem user 11521 Nov 13 2001 1t.html
drwx------ 2 rem user 11 Jan 10 2002 Cmds/
drwx------ 2 rem user 15 Jul 18 07:46 Cruft/
drwx------ 2 rem user 5 Jun 23 2007 Fifos/
drwx------ 7 rem user 7 Jan 9 2002 Files/
drwx------ 6 rem user 6 Jul 15 13:15 FromHosts/
drwx------ 13 rem user 645 Oct 5 02:55 LispWork/
drwx------ 2 rem user 2 Jul 18 07:35 LongNames/
drwx------ 2 rem user 118 Sep 29 01:04 Mail/
drwx------ 2 rem user 4 Jan 9 2002 MaybeJunk/
drwx------ 2 rem user 2 Jul 16 16:12 MiscToSort/
drwx------ 4 rem user 4 Jul 18 07:31 Move/
drwx------ 2 rem user 44 Jul 16 00:56 MySqlWork/
drwx------ 8 rem user 8 Jul 16 16:05 OldRefKeep/
drwx------ 9 rem user 9 Jul 16 15:59 ParseSgxml/
drwx------ 6 rem user 6 Jul 18 07:25 ProgLang/
drwx------ 6 rem user 6 Jul 18 07:37 ProjectsAside/
-- press space for next page --
C)reate D)ownload E)dit F)ull menu M)odify R)emove T)ag U)pload
0: (Y-OR-N-P "Show comparison of expected vs. actual text?")
Show comparison of expected vs. actual text?y
0: Y-OR-N-P returned T
((:INSERT
"<0D><1B>[2A<1B>[7mGetting file://localhost/home/users/rem/<1B>[m<1B>[K<0D><1B
>[7mReading directory...<1B>[m <1B>[22;21H<0D><1B>[7mOK<1B>[m
<08><08><08><08><08><08><08><08><08><08><08><08><08><08><08><0
8><08><08><1B>[H<1B>[7m<<<<1B>[1;34H<1B>[m /home/users/rem/ directory
(p1 of 2<0D><1B>[BCurrent directory is /home/users/rem/ <0D><1B>[2B dr
wx------ 2 rem user 14 Jan 7 2002 <1B>[1m11-Clubs/<1B>[B<1B>[
64D<1B>[m-rw------- 1 rem user 11521 Nov 13 2001 <1B>[1m1t.html<1
B>[B<1B>[63D<1B>[m drwx------ 2 rem user 11 Jan 10 2002 <1B>[1
mCmds/<1B>[B<1B>[60D<1B>[mdrwx------ 2 rem user 15 Jul 18 07:46
<1B>[1mCruft/<1B>[B<1B>[62D<1B>[m drwx------ 2 rem user 5 Jun
23 2007 <1B>[1mFifos/<1B>[B<1B>[61D<1B>[mdrwx------ 7 rem user
7 Jan 9 2002 <1B>[1mFiles/<1B>[B<1B>[62D<1B>[m drwx------ 6 rem use
r 6 Jul 15 13:15 <1B>[1mFromHosts/<1B>[B<1B>[66D<1B>[m drwx------ 13
rem user 645 Oct 5 02:55 <1B>[1mLispWork/<1B>[B<1B>[64D<1B>[mdrwx
------ 2 rem user 2 Jul 18 07:35 <1B>[1mLongNames/<1B>[B<1B>[6
6D<1B>[m drwx------ 2 rem user 118 Sep 29 01:04 <1B>[1mMail/<1B>
[B<1B>[61D<1B>[m drwx------ 2 rem user 4 Jan 9 2002 <1B>[1mM
aybeJunk/<1B>[B<1B>[66D<1B>[m drwx------ 2 rem user 2 Jul 16 1
6:12 <1B>[1mMiscToSort/<1B>[B<1B>[67D<1B>[m drwx------ 4 rem user
4 Jul 18 07:31 <1B>[1mMove/<1B>[m <0D><1B>[B drwx------ 2 rem
user 44 Jul 16 00:56 <1B>[1mMySqlWork/<1B>[B<1B>[65D<1B>[mdrwx-----
- 8 rem user 8 Jul 16 16:05 <1B>[1mOldRefKeep/<1B>[B<1B>[66D<1
B>[mdrwx------ 9 rem user 9 Jul 16 15:59 <1B>[1mParseSgxml/<1B
>[B<1B>[66D<1B>[mdrwx------ 6 rem user 6 Jul 18 07:25 <1B>[1mP
rogLang/<1B>[B<1B>[64D<1B>[mdrwx------ 6 rem user 6 Jul 18 07:
37 <1B>[1mProjectsAside/<0D><1B>[B<1B>[m<1B>[H<1B>[78C3<0D><1B>[21B<1B>[2")
(:STET
"B C)reate D)ownload E)dit F)ull menu M)odify R)emove T)ag U)pload
")
(:CHANGE "<1B>[H<1B>[21B" "<0D><1B>[2A")
(:STET "<1B>[7m-- press space for next page --<1B>[m<1B>[") (:CHANGE "5" "4")
(:STET ";60H<1B>[7m11-Clubs/<1B>[2")
(:CHANGE "4;80H<1B>[m" "0B<1B>[11C<1B>[m"))
0: (Y-OR-N-P "Close enough to retrain now?")
Close enough to retrain now?y
0: Y-OR-N-P returned T
* Size of expected string decreased from 155 to 138.
0: (Y-OR-N-P "See the proposed changes in expect-string?")
See the proposed changes in expect-string?y
0: Y-OR-N-P returned T
((:STET
"B C)reate D)ownload E)dit F)ull menu M)odify R)emove T)ag U)pload
<1B>[")
(:DELETE "H<1B>[21B<1B>[")
(:STET "7m-- press space for next page --<1B>[m<1B>[") (:DELETE "5")
(:STET ";60H<1B>[7m11-Clubs/<1B>[2") (:DELETE "4;80H<1B>[m"))
0: (Y-OR-N-P "Overwrite file with this new expected-string?")
Overwrite file with this new expected-string?y
0: Y-OR-N-P returned T
(#=1879/138 frac=1.000) 0 (#=1757/138 frac=1.000) done] [Move down... (#=482/34
1 frac=0.877) 0123456789ABCDEFGHIJ
0: (Y-OR-N-P "Show all Lynx output so-far?")
Show all Lynx output so-far?y
0: Y-OR-N-P returned T
11-Clubs/
1t.html
-- press space for next page --
Arrow keys: Up and Down to move. Right to follow a link; Left to go back.
C)reate D)ownload E)dit F)ull menu M)odify R)emove T)ag U)pload
0: (Y-OR-N-P "Show comparison of expected vs. actual text?")
Show comparison of expected vs. actual text?y
0: Y-OR-N-P returned T
((:CHANGE "<1B>[H<1B>[21B" "<0D><1B>[2A")
(:STET "<1B>[7mEnter a whereis query: <1B>[m")
(:CHANGE "<1B>[Khtml"
" <1B>[22;24H<1B>[7m
<1B>[22;24H<1B>[m<1B>[7m1<1B>[m<1B>[7mt<1B>[m<1B>[7m.<1B>[m<1B>[7mh<1B>[m<
1B>[7mt<1B>[m<1B>[7mm<1B>[m<1B>[7ml<1B>[m")
(:STET "<0D><1B>[J<1B>[") (:CHANGE "5" "4")
(:STET ";60H<1B>[1m11-Clubs/<1B>[") (:CHANGE "B" "5;60H<1B>[m")
(:STET "<1B>[7m<1B>[4m") (:INSERT "1t.") (:STET "html<0D><1B>[1")
(:CHANGE "6" "7")
(:STET
"B<1B>[m<1B>[B Arrow keys: Up and Down to move. Right to follow a link; Left
to go back.<0D><1B>[B C)reate D)ownload E)dit F)ull menu M)odify R)emove
T)ag U)pload ")
(:CHANGE "<1B>[H<1B>[21B" "<0D><1B>[2A")
(:STET "<1B>[7m-- press space for next page --<1B>[m<1B>[") (:CHANGE "6" "5")
(:STET ";60H<1B>[7m1<1B>[") (:CHANGE "1m<1B>[4m" "4mt.")
(:STET "htm<1B>[m<1B>[7ml<1B>[") (:CHANGE "24;80H<1B>[m" "19B<1B>[13C<1B>[m"))
0: (Y-OR-N-P "Close enough to retrain now?")
Close enough to retrain now?y
0: Y-OR-N-P returned T
* Size of expected string decreased from 341 to 299.
0: (Y-OR-N-P "See the proposed changes in expect-string?")
See the proposed changes in expect-string?y
0: Y-OR-N-P returned T
((:DELETE "<1B>[H<1B>[21B") (:STET "<1B>[7mEnter a whereis query: <1B>[m")
(:DELETE "<1B>[Khtml") (:STET "<0D><1B>[J<1B>[") (:DELETE "5")
(:STET ";60H<1B>[1m11-Clubs/<1B>[") (:DELETE "B")
(:STET "<1B>[7m<1B>[4mhtml<0D><1B>[1") (:DELETE "6")
(:STET
"B<1B>[m<1B>[B Arrow keys: Up and Down to move. Right to follow a link; Left
to go back.<0D><1B>[B C)reate D)ownload E)dit F)ull menu M)odify R)emove
T)ag U)pload <1B>[")
(:DELETE "H<1B>[21B<1B>[")
(:STET "7m-- press space for next page --<1B>[m<1B>[") (:DELETE "6")
(:STET ";60H<1B>[7m1<1B>[") (:DELETE "1m<1B>[4m")
(:STET "htm<1B>[m<1B>[7ml<1B>[") (:DELETE "24;80H<1B>[m"))
0: (Y-OR-N-P "Overwrite file with this new expected-string?")
Overwrite file with this new expected-string?y
0: Y-OR-N-P returned T
(#=482/299 frac=1.000) done, refresh-verify... (#=1770/843 frac=0.841) 01234567
89ABCDEFGHIJ
0: (Y-OR-N-P "Show all Lynx output so-far?")
Show all Lynx output so-far?y
...(exit-trace overwritten by lynx screen output)...
<<< /home/users/rem/ directory (p1 of 3)
Current directory is /home/users/rem/
drwx------ 2 rem user 14 Jan 7 2002 11-Clubs/
-rw------- 1 rem user 11521 Nov 13 2001 1t.html
drwx------ 2 rem user 11 Jan 10 2002 Cmds/
drwx------ 2 rem user 15 Jul 18 07:46 Cruft/
drwx------ 2 rem user 5 Jun 23 2007 Fifos/
drwx------ 7 rem user 7 Jan 9 2002 Files/
drwx------ 6 rem user 6 Jul 15 13:15 FromHosts/
drwx------ 13 rem user 645 Oct 5 02:55 LispWork/
drwx------ 2 rem user 2 Jul 18 07:35 LongNames/
drwx------ 2 rem user 118 Sep 29 01:04 Mail/
drwx------ 2 rem user 4 Jan 9 2002 MaybeJunk/
drwx------ 2 rem user 2 Jul 16 16:12 MiscToSort/
drwx------ 4 rem user 4 Jul 18 07:31 Move/
drwx------ 2 rem user 44 Jul 16 00:56 MySqlWork/
drwx------ 8 rem user 8 Jul 16 16:05 OldRefKeep/
drwx------ 9 rem user 9 Jul 16 15:59 ParseSgxml/
drwx------ 6 rem user 6 Jul 18 07:25 ProgLang/
drwx------ 6 rem user 6 Jul 18 07:37 ProjectsAside/
-- press space for next page --
Arrow keys: Up and Down to move. Right to follow a link; Left to go back.
C)reate D)ownload E)dit F)ull menu M)odify R)emove T)ag U)pload
0: (Y-OR-N-P "Show comparison of expected vs. actual text?")
Show comparison of expected vs. actual text?y
0: Y-OR-N-P returned T
Help! 12 nested errors. KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded.
Debug (type H for help)
%primitive halt called; the party is over.
LDB monitor
ldb> backtrace
Backtrace:
0: Foreign fp = 0x47fd7854, ra = 0x804cfc3
1: Foreign fp = 0x47fd7994, ra = 0x804d202
2: Foreign fp = 0x47fd79e4, ra = 0x804d251
3: Foreign fp = 0x47fd79f4, ra = 0x804e424
4: Foreign fp = 0x47fd7a94, ra = 0x80523d9
5: Foreign fp = 0x47fd7c64, ra = 0xffffefd4
6: COMMON-LISP::ERROR
7: UNIX::SIGSEGV-HANDLER
8: UNIX::SIGSEGV-HANDLER
9: Foreign fp = 0x47fd7d44, ra = 0x80526bc
10: Foreign fp = 0x47fd7d74, ra = 0x8052523
11: Foreign fp = 0x47fd7da4, ra = 0x804f2ab
12: Foreign fp = 0x47fd7dc4, ra = 0x8052c23
13: Foreign fp = 0x47fd7f98, ra = 0xffffefd4
14: COMMON-LISP::ERROR
15: UNIX::SIGBUS-HANDLER
16: UNIX::SIGBUS-HANDLER
ldb> regs
CSP = 0x47FD7C34
FP = 0x00000000
BSP = 0x380006F8
DYNAMIC = 0x48000000
ALLOC = 0x49072000
TRIGGER = 0x000000AE
STATIC = 0x291CF418
RDONLY = 0x113A1A90
ldb> context
There are 15 interrupt contexts.
Printing context 14
EAX: 0x00000010: even fixnum: 4
ECX: $1= 0x28f9b7d7: other pointer
EDX: $nil= 0x28f0000b: list pointer (NIL)
EBX: $1= 0x28f9b7d7: other pointer
ESP: 0x47fd7c34: odd fixnum: 301948685
EBP: 0x47fd7c64: odd fixnum: 301948697
ESI: 0x47fd7c30: even fixnum: 301948684
EDI: 0x000000c8: even fixnum: 50
PC: 0x10008f29
ldb> catchers
0x47FD7E48:
uwp: 0x00000000
fp: 0x00000000
code: 0x0x1c
entry: 0x00000000
tag: 0x00000000: even fixnum: 0
Madhu
* (Robert Maas, http://tinyurl.com/uh3t) <REM-2009...@Yahoo.Com> :
Wrote on Mon, 05 Oct 2009 01:16:08 -0700:
| - finally copy&paste the two function calls, one of which crashes
| CMUCL, down to just a half hour each time around. Here's the latest
| transcript-tail:
[snip]
| ** That password already known here!
| * g*current-YM-acct has been set, ready to use it.
| Now is a good time to: (UNIX-YAHOO-ACCT-VERIFY-PW "ChineseEnglish76")
| NIL
| * (UNIX-YAHOO-ACCT-VERIFY-PW "ChineseEnglish76")
| ;
|
| ; Warning: This function is undefined:
| ; SLEEP20
^^^^ ?
grep your sources for SLEEP20. Maybe you meant (sleep 20) ?
| (password known)0123456789A
|
|Help! 12 nested errors.
| KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded.
Haven't used this lisp implementation in a while but this means there is
a recursive error: There is an error printing the error etc. Check your
ERROR forms to make sure they are valid.
| Debug (type H for help)
|
| (UNIX::SIGBUS-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP
| #x47FE1E7C)) %primitive halt called; the party is over. LDB monitor
| ldb> backtrace
| Backtrace:
--
Madhu
Robert Swindells
Madhu wrote:
>* (Robert Maas, http://tinyurl.com/uh3t) <REM-2009...@Yahoo.Com> :
>Wrote on Mon, 05 Oct 2009 01:16:08 -0700:
>|
>|Help! 12 nested errors.
>| KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded.
>
>Haven't used this lisp implementation in a while but this means there is
>a recursive error: There is an error printing the error etc. Check your
>ERROR forms to make sure they are valid.
>
>| Debug (type H for help)
>|
>| (UNIX::SIGBUS-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP
>| #x47FE1E7C)) %primitive halt called; the party is over. LDB monitor
>| ldb> backtrace
>| Backtrace:
This kind of error usually comes from something fundamental going wrong
than from invalid ERROR forms in my experience.
The operating system version would be useful to know here too. FreeBSD
changed which signal is generated for page protection faults, these are
used to help the garbage collector.
CMUCL 19c is fairly old, the current version is 20a, maybe ask the admin
to upgrade.
Robert Swindells
Madhu
* Robert Swindells <x7r5tif...@stimpy.fdy2.net> :
Wrote on 05 Oct 2009 13:09:27 +0100:
| Madhu wrote:
|>* (Robert Maas, http://tinyurl.com/uh3t) <REM-2009...@Yahoo.Com> :
|>Wrote on Mon, 05 Oct 2009 01:16:08 -0700:
|>| (password known)0123456789A
|>|
|>|Help! 12 nested errors.
|>| KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded.
|>
|>Haven't used this lisp implementation in a while but this means there is
|>a recursive error: There is an error printing the error etc. Check your
|>ERROR forms to make sure they are valid.
|>
|>| Debug (type H for help)
|>|
|>| (UNIX::SIGBUS-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP
|>| #x47FE1E7C)) %primitive halt called; the party is over. LDB monitor
|>| ldb> backtrace
|>| Backtrace:
|
| This kind of error usually comes from something fundamental going wrong
| than from invalid ERROR forms in my experience.
Well I know that slime (SWANK) could put CMUCL into LDB very easily and
repeatably. (with *SWANK-DEBUG-P* when it tries to log an error on a
closed stream), of course I believe slime is doing something
fundamentally wrong, others would disagree.
| The operating system version would be useful to know here too. FreeBSD
| changed which signal is generated for page protection faults, these are
| used to help the garbage collector.
|
| CMUCL 19c is fairly old, the current version is 20a, maybe ask the admin
| to upgrade.
IIRC 19c also had some in progress unstability related to TRACE.
--
Madhu
Robert Maas, http://tinyurl.com/uh3t
and again, each time running the lynx-scrape training a little bit
further, until it got in a loop where each time I re-started it and
ran it it died exactly the same place as the previous run, a
repeatable bug. It was always at this one spot where it asked me if
I wanted to see the differences, and I said yes, and before it
could print out the differences it died. Here is the form where it
died repeatedly:
(if (y-or-n-p "See the proposed changes in expect-string?")
(format t "~&~S~%" (strs-show-differences oldexp newexp)))
From earlier trace of Y-OR-N-P, I knew it had already exited
Y-OR-N-P when it died, so I guessed either it was dying inside
STRS-SHOW-DIFFERENCES, or after that returned it was dying from
inside FORMAT. So next I traced STRS-SHOW-DIFFERENCES. Here was the
result (collected by VersaTerm as a live output-from-modem transcript):
See the proposed changes in expect-string?y
0: (STRS-SHOW-DIFFERENCES
"[H[H[J[48CSign in - Yahoo! Mail (p1 of 2)
Yahoo! Mail [1mHelp[m - [1mYahoo![B[23D[m_________________________________________________________________
[4mWelcome to Yahoo! Mail [8;19HYou must sign in to read or send mail. [10;13HNew to Yahoo!?[B[23D[1mSign up now[m[4m to enjoy Yahoo! Mail [B[33D[mYahoo! Mail Yahoo! Mail
[1m[4mSign up now[B[12D[m[1mLearn more...[16;4H[m[4mExisting Yahoo! users[B[20D[mEnter your ID and password to sign in
Yahoo! ID: [1m________[B[mPassword: [1m_________________[B[ ][m Remember my ID on this computer[21;15H[1mSign In[24;80H[m[A Arrow keys: Up and Down to move. Right to follow a link; Left to go back.
H)elp O)ptions P)rint G)o M)ain screen Q)uit /=search [delete]=history list [H[21B[7m(Text entry field) Enter text. Use UP or DOWN arrows or tab to move off.[m[18;15H________[5B Enter text into the field by typing on the keyboard[K
Ctrl-U to delete all text in field, [Backspace] to delete a character
[H[H[J[23B
[Hign in - Yahoo! Mail (p1 of 2)Yahoo! Mail [1mHelp[m - [1mYahoo![m_________________________________________________________________mWelcome to Yahoo! MailExisting Yahoo! users[BEnter your ID and password to sign in
Yahoo! [1mm_________________ Remember my ID on this computermSign In[m[A Arrow keys: Up and Down to move. Right to follow a link; Left to go back.
H)elp O)ptions P)rint G)o M)ain screen Q)uit /=search [delete]=history list [7m(Text entry field) Enter text. Use UP or DOWN arrows or tab to move off.[m[1;15H________ Enter text into the field by typing on the keyboard
Ctrl-U to delete all text in field, [Backspace] to delete a character
elp! 12 nested errors. KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded.
Debug (type H for help)
%primitive halt called; the party is over.
LDB monitor
ldb>
As you can see, it died in the middle of the trace package trying
to simply print out the first parameter to the function being
traced. It never got to where it'd print out the second parameter,
much less actually get into the body of the function itself. That
hints strongly of a bug in the way CMUCL handles
stdout/errout/termio of long strings.
(It's possible that earlier when it died immediately after I
pasted a long string of *input*, maybe it was the *echo* of that
input by CMUCL that caused the crash, in which case it's possible
all these crashes are being caused by a single bug in CMUCL.)
So next I instrumented STRS-SHOW-DIFFERENCES internally to print
both parameters to a disk file whenever it encountered the
recursive case, as well as printing to stdout a brief trace of
getting into the recursive case and back out of it. Here's what my
handcoded brief trace to stdout looked like:
[Nontrivial case, write...done, recursing...[Nontrivial case, write...done, recu
rsing...[Nontrivial case, write...done, recursing...[Nontrivial case, write...do
ne, recursing...[Nontrivial case, write...done, recursing...back from recursing]
back from recursing]back from recursing][Nontrivial case, write...done, recursin
g...Help! 12 nested errors. KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded.
Here it is re-arranged to prettyprint so you can see the levels of recursion:
[Nontrivial case, write...done, recursing...
[Nontrivial case, write...done, recursing...
[Nontrivial case, write...done, recursing...
[Nontrivial case, write...done, recursing...
[Nontrivial case, write...done, recursing...
back from recursing]
back from recursing]
back from recursing]
[Nontrivial case, write...done, recursing...Help! 12 nested errors. KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded.
So it seems it died three levels deep in the recursive algorithm,
the very first time the second branch at the same level occurred.
But if the function were traced in the usual way, remember it would
have already died just trying to print out the toplevel
first-parameter.
> From: Madhu <enom...@meer.net>
> | ; Warning: This function is undefined:
> | ; SLEEP20
> grep your sources for SLEEP20. Maybe you meant (sleep 20) ?
No, it's a perfectly valid call to a function I had in a patch file
I last wrote 2.5 years ago that uses carry-over to sleep in
reasonable pauses every time the accumulated want-sleep exceeds
some fixed amount. I don't have that patch file loaded currently.
The only place in my current code where it's even potentially
callable is from here:
(defun emit-beep-pause (str &key (pauses nil))
(cond ((null pauses) (write-string str) (finish-output) (sleep 0.2))
(t (map nil #'(lambda (ch)
(write-char ch) (finish-output) (sleep20 pauses))
str)))
(SYSTEM:BEEP) (finish-output) (sleep 3))
The idea was that when I try to print lots of short strings to
dialup, it's sufficient to pause after each short string, to
prevent output buffer to modem from overflowing and losing output.
But when a string is very long, it's better to print one character
at a time, and whenever the pro-rated needed-pause is long enough
the pause before printing any more characters of that same string.
But in fact that keyword parameter isn't currently being used, so
that function not defined (because the patch file not loaded) isn't
a problem.
> | (password known)0123456789A
> |
> |Help! 12 nested errors.
> | KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded.
> Haven't used this lisp implementation in a while but this means there is
> a recursive error: There is an error printing the error etc. Check your
> ERROR forms to make sure they are valid.
I already tried (trace error), and it never happened, because my
code is never calling error. I tested it separately, by
deliberately invoking (error ...) and it *did* show the trace going
into the call (no trace when exiting because it's impossible for
error to return normally). So I know that *if* any of *my* calls to
ERROR happened, they would have been traced. Hence the problem
isn't any of *my* calls to ERROR. Also the fact it happened from
inside the trace package when trying to simply print out a string
parameter to the function being traced, which can't possibly be on
account of any of *my* calls to ERROR.
Note that while CMUCL died while the trace package merely tried to
print the first parameter, when I manually wrote both parameters to
disk it never died in the middle of such output. Here is the file
that resulted: <http://www.rawbw.com/~rem/Tmp5/tmp-debug-str12.txt>
Each record in that file shows the two strings that were given as
parameters, the length of the longest matching sub-string, and the
starting index of the matching sub-string within each of the given
strings.
Robert Maas, http://tinyurl.com/uh3t
> >| Debug (type H for help)
> >|
> >| (UNIX::SIGBUS-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP
> >| #x47FE1E7C)) %primitive halt called; the party is over. LDB monitor
> >| ldb> backtrace
> >| Backtrace:
> This kind of error usually comes from something fundamental going wrong
> than from invalid ERROR forms in my experience.
> The operating system version would be useful to know here too. FreeBSD
> changed which signal is generated for page protection faults, these are
> used to help the garbage collector.
Hmm, the older version of CMUCL on the old shell machine worked
reasonably well, with only one known bug (sleep of floating point
greater than one second returned *immediately*). This newer version
of CMUCL on new shell machine bombs badly. It's possible that when
the admin installed it, he configured it for page faults from the
old system which aren't correct for the new system.
Here's the old system info:
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 4.10-STABLE (SHELL) #0: Thu Feb 16 03:07:17 PST 2006
shell.rawbw.com% lisp
CMU Common Lisp 18b, running on shell.rawbw.com
Send questions and bug reports to your local CMU CL maintainer, or to cmucl-help
@cons.org. and cmuc...@cons.org. respectively.
Loaded subsystems:
Python 1.0, target Intel x86
CLOS based on PCL version: September 16 92 PCL (f)
Here's the new system info:
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 7.1-PRERELEASE (SHELL0) #0: Mon Mar 23 03:17:26 PDT 2009
> lisp
CMU Common Lisp 19c Release (19C), running on shell0.rawbw.com
With core: /usr/local/lib/cmucl/lib/lisp.core
Dumped on: Wed, 2005-11-16 17:18:11-08:00 on snapdragon.csl.sri.com
See <http://www.cons.org/cmucl/> for support information.
Loaded subsystems:
Python 1.1, target Intel x86
CLOS based on Gerd's PCL 2004/04/14 03:32:47
I see quite a lot of differences, but I have no idea which of them
would cause it to crash repeatedly, except maybe
snapdragon.csl.sri.com isn't running a compatible system or CPU so
it compiles C source into bad code for our new shell?
> CMUCL 19c is fairly old, the current version is 20a, maybe ask
> the admin to upgrade.
Um, he upgraded less than a year ago when he installed everything
in this brand-new dual-quad-core Unix shell machine. This is
probably the very first time anyone has seriously tried to use that
"new" CMUCL since he installed it last year. Since the printout at
startup *seems* to indicate this "new" version is nearly four years
old, I wonder where he got such an old version just about a year
ago? Maybe there was a huge gap when there was no new version, so a
year ago the most recent version was still from 2005, so that's
what he got, so he just missed the even newer version that came out
whenever 20a came out?
But if the problem is that his configuration-build file is for the
wrong version of FreeBSD Unix, where it is configured to use the
wrong page fault signals, then downloading the very latest version
and re-building it with the *same* wrong configuration-build file
will result in yet another CMUCL that doesn't work propertly, as
well as an angry sysadmin who would rather just delete all LISPs on
the whole system rather than put up with any more extra labor. So
let's be sure we know *why* this version is crashing before I ask
the sysadmin to download and install a newer version.
Tamas K Papp
wrote:
> But if the problem is that his configuration-build file is for the wrong
> version of FreeBSD Unix, where it is configured to use the wrong page
> fault signals, then downloading the very latest version and re-building
> it with the *same* wrong configuration-build file will result in yet
> another CMUCL that doesn't work propertly, as well as an angry sysadmin
> who would rather just delete all LISPs on the whole system rather than
> put up with any more extra labor. So let's be sure we know *why* this
> version is crashing before I ask the sysadmin to download and install a
> newer version.
You don't need to be an admin to install a Lisp implementation, you
can do it as a user. That's how I run SBCL on my machine. 15 minutes
of work and you are done. You can also keep up with the latest
releases without relying on anyone else.
Consider using clbuild for automating this, and other things.
If you find a bug, it is always good manners to verify that it hasn't
been fixed in the latest release before raising the issue.
Tamas
Robert Swindells
Robert Maas wrote:
>> From: Robert Swindells <r...@fdy2.demon.co.uk>
>> >| Debug (type H for help)
>> >|
>> >| (UNIX::SIGBUS-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP
>> >| #x47FE1E7C)) %primitive halt called; the party is over. LDB monitor
>> >| ldb> backtrace
>> >| Backtrace:
>> This kind of error usually comes from something fundamental going wrong
>> than from invalid ERROR forms in my experience.
>
>> The operating system version would be useful to know here too. FreeBSD
>> changed which signal is generated for page protection faults, these are
>> used to help the garbage collector.
>
>Hmm, the older version of CMUCL on the old shell machine worked
>reasonably well, with only one known bug (sleep of floating point
>greater than one second returned *immediately*). This newer version
>of CMUCL on new shell machine bombs badly. It's possible that when
>the admin installed it, he configured it for page faults from the
>old system which aren't correct for the new system.
There isn't really any configuration involved, the switch is done based
on the version of operating system used to build CMUCL.
>Here's the old system info:
>Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
> The Regents of the University of California. All rights reserved.
>FreeBSD 4.10-STABLE (SHELL) #0: Thu Feb 16 03:07:17 PST 2006
>shell.rawbw.com% lisp
>CMU Common Lisp 18b, running on shell.rawbw.com
>Send questions and bug reports to your local CMU CL maintainer, or to cmucl-help
>@cons.org. and cmuc...@cons.org. respectively.
>Loaded subsystems:
> Python 1.0, target Intel x86
> CLOS based on PCL version: September 16 92 PCL (f)
Ok.
>Here's the new system info:
>Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
> The Regents of the University of California. All rights reserved.
>FreeBSD 7.1-PRERELEASE (SHELL0) #0: Mon Mar 23 03:17:26 PDT 2009
> lisp
>CMU Common Lisp 19c Release (19C), running on shell0.rawbw.com
>With core: /usr/local/lib/cmucl/lib/lisp.core
>Dumped on: Wed, 2005-11-16 17:18:11-08:00 on snapdragon.csl.sri.com
>See <http://www.cons.org/cmucl/> for support information.
>Loaded subsystems:
> Python 1.1, target Intel x86
> CLOS based on Gerd's PCL 2004/04/14 03:32:47
FreeBSD 7.1 is after the signal change.
>I see quite a lot of differences, but I have no idea which of them
>would cause it to crash repeatedly, except maybe
>snapdragon.csl.sri.com isn't running a compatible system or CPU so
>it compiles C source into bad code for our new shell?
This is the home machine of the CMUCL developer who produced the
FreeBSD, you can assume that the build was correct at the time.
>> CMUCL 19c is fairly old, the current version is 20a, maybe ask
>> the admin to upgrade.
>Um, he upgraded less than a year ago when he installed everything
>in this brand-new dual-quad-core Unix shell machine. This is
>probably the very first time anyone has seriously tried to use that
>"new" CMUCL since he installed it last year. Since the printout at
>startup *seems* to indicate this "new" version is nearly four years
>old, I wonder where he got such an old version just about a year
>ago? Maybe there was a huge gap when there was no new version, so a
>year ago the most recent version was still from 2005, so that's
>what he got, so he just missed the even newer version that came out
>whenever 20a came out?
There have been new versions fairly regularly during this period.
Look at <http://common-lisp.net/project/cmucl/downloads/release>.
>But if the problem is that his configuration-build file is for the
>wrong version of FreeBSD Unix, where it is configured to use the
>wrong page fault signals, then downloading the very latest version
>and re-building it with the *same* wrong configuration-build file
>will result in yet another CMUCL that doesn't work propertly, as
>well as an angry sysadmin who would rather just delete all LISPs on
>the whole system rather than put up with any more extra labor. So
>let's be sure we know *why* this version is crashing before I ask
>the sysadmin to download and install a newer version.
You are running an official build, your sysadmin hasn't done any
configuration at all, you just need a build that matches your
operating system version.
Version 20a is built against FreeBSD 7.2 so I would try something a
bit earlier, try 19f.
Robert Swindells
Madhu
* (Robert Maas) <REM-2009...@Yahoo.Com> :
Wrote on Mon, 05 Oct 2009 06:27:06 -0700:
| As you can see, it died in the middle of the trace package trying to
| simply print out the first parameter to the function being traced. It
| never got to where it'd print out the second parameter, much less
| actually get into the body of the function itself. That hints strongly
| of a bug in the way CMUCL handles stdout/errout/termio of long
| strings.
|
| (It's possible that earlier when it died immediately after I pasted a
| long string of *input*, maybe it was the *echo* of that input by
| CMUCL that caused the crash, in which case it's possible all these
| crashes are being caused by a single bug in CMUCL.)
[]
|> From: Madhu <enom...@meer.net>
|> | ; Warning: This function is undefined:
|> | ; SLEEP20
|> grep your sources for SLEEP20. Maybe you meant (sleep 20) ?
|
| No, it's a perfectly valid call to a function I had in a patch file I
| last wrote 2.5 years ago that uses carry-over to sleep in reasonable
| pauses every time the accumulated want-sleep exceeds some fixed
| amount. I don't have that patch file loaded currently.
This was a shot in the dark, Sorry. --- perhaps the call to ERROR
[spiralling down into the ldb] was an the undefined function call. Good
to know it was a red herring
|> Haven't used this lisp implementation in a while but this means there is
|> a recursive error: There is an error printing the error etc. Check your
|> ERROR forms to make sure they are valid.
|
| I already tried (trace error), and it never happened, because my
| code is never calling error.
So that suggestion was useless too. Sorry again.
If the program worked on earlier versions of CMUCL I am inclined to
agree with Robert Swindells it might be a freebsd+version specific
signals/timing problem which leads to the ERROR which immediately dumps
you in LDB.
We'll just have to wait for Raymond Toy to weigh in and shed some light
:) I don't think he uses freebsd though.
| Note that while CMUCL died while the trace package merely tried to
| print the first parameter, when I manually wrote both parameters to
| disk it never died in the middle of such output. Here is the file that
| resulted: <http://www.rawbw.com/~rem/Tmp5/tmp-debug-str12.txt> Each
| record in that file shows the two strings that were given as
| parameters, the length of the longest matching sub-string, and the
| starting index of the matching sub-string within each of the given
| strings.
[Just thinking aloud;
If you were printing the strings immediately after entry into that
function and the statistics just before exit, it looks like all calls of
that function succeeded, if you leave out timing related issues of the
crash. I also assume there are no special streams involved in your
program, and you read STDIN and write to STDOUT, and these streams
cannot suffer any sudden problems]
--
Madhu
Robert Maas, http://tinyurl.com/uh3t
> |>| (UNIX::SIGBUS-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP
> |>| #x47FE1E7C)) %primitive halt called; the party is over. LDB monitor
> |>| ldb> backtrace
> |>| Backtrace:
> | This kind of error usually comes from something fundamental going wrong
> | than from invalid ERROR forms in my experience.
> Well I know that slime (SWANK) could put CMUCL into LDB very
> easily and repeatably.
I'm not doing anything weird like interfacing to emacs as an IDE or
mapping stdio etc. I'm not even using third-party packages such as
asdf. The only thing even slightly unusual I'm doing is making
heavy use of ext:run-program to run lynx and wget etc. as
sub-process under CMUCL, with stdio for wget mapped to files and
stdio for lynx piped through CL streams managed by my lynx-scraper
(send lynx commands, get back lynx VT100 output which is
fuzzy-matched with what is expected from earlier training on
similar situations). But the first LDB crashes happened both in CGI
applications that don't do any sub-process, and in public-key
communication between Mac and Unix which made heavy use of bignum
multiplication but used only stdio without any sub-process, so I'm
sure that ext:run-program isn't at the heart of the bug. One thing
that all three applications have in common is dealing with large
strings of text:
- CGI application spews out very long lines of HTML without
newlines, namely the entire message body of e-mail being sent
during conversion of Unix newlines to TCP cr-lf pairs.
- Public-key Mac/Unix link exchanges very long strings of ConVow
text, although manually breaking the long strings to be composed of
<80 char lines didn't fix the problem, but internally all
white-space of received strings is immediately removed leaving a
single very long "word" of ConVow notation regardless of what was
actually transmitted.
- Lynx-scraper receives thousand-character strings of VT100 text
without any actual newlines anywhere in each batch.
Somebody suggested a page-fault bug caused by new version of
FreeBSD switching to a different signal that CMUCL doesn't yet (as
of version 19c) know about, so if long strings are happening to
cross a page boundary where one of the pages happens to be paged
out and needs to be paged back in, that would seem to readily
explain the crash. I suppose I could write a test rig that did
nothing but build and re-build very long strings all over the Lisp
heap and just keep running forever until it crashes.
- (with *SWANK-DEBUG-P* when it tries to log an error on a closed
- stream), of course I believe slime is doing something
- fundamentally wrong, others would disagree.
Yeah, that's clearly a wrong thing to do. But CMUCL should simply
obtain a stream-closed error, switch errout to termio, and report
the error there, without problem, except if termio is closed, then
what can it do that could possibly be right? Maybe report to the
system error log file, the way CGI applications do?? In my case I'm
not messing with termio, not even remapping stdio except for the
non-Lisp sub-process running under ext:run-program, so that can't
be what's happening here.
> | The operating system version would be useful to know here too. FreeBSD
> | changed which signal is generated for page protection faults, these are
> | used to help the garbage collector.
Yeah, that's the *huge*clue* I was referring to.
> IIRC 19c also had some in progress unstability related to TRACE.
You mean like if TRACE needed to print the parameter to a function
upon entry, and it happened to be a very large string that crossed
a page boundary and require swapping a page back in, i.e. exactly
what I might be seeing if I try to (trace strs-show-differences)
which compares two large strings given as parameters to find the
longest matching sub-string and then recurses over corresponding
unmatched left and right remains?
(defun strs-show-differences (str1 str2 &optional (ignlen 3) (showstr t) ...)
(prog (...)
... code to handle trivial cases where either string is empty
so it returns a single :INSERT or :DELETE record ...
(multiple-value-setq (matlen ix1l ix2l)
(values-list (find-longest-matching-segment str1 str2 ignlen)))
... code to handle case where no match was found
so it returns a single :CHANGE record ...
... code to recurse left remains, producing lefres ...
... code to recurse right remains, producing rigres ...
(return (append lefres
(list (list :STET
(let ((stetstr (subseq str1 ix1l ix1r)))
(if showstr (string-to-showstr stetstr) stetstr))))
rigres))
))
Note that string-to-showstr simply reformats a string
(non-destructively, by building new string) to convert all control
and other nonprintable characters to printable representations.
(format t "~A~%"
(string-to-showstr
(map 'string #'code-char
(loop for ix from 0 to 255 collect ix))))
<00><01><02><03><04><05><06><07><08><09><0A><0B><0C><0D><0E><0F><10><11><12><13>
<14><15><16><17><18><19><1A><1B><1C><1D><1E><1F> !"#$%&'()*+,-./0123456789:;<=>?
@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~<80><81><82><83><
84><85><86><87><88><89><8A><8B><8C><8D><8E><8F><90><91><92><93><94><95><96><97><
98><99><9A><9B><9C><9D><9E><9F><A0><A1><A2><A3><A4><A5><A6><A7><A8><A9><AA><AB><
AC><AD><AE><AF><B0><B1><B2><B3><B4><B5><B6><B7><B8><B9><BA><BB><BC><BD><BE><BF><
C0><C1><C2><C3><C4><C5><C6><C7><C8><C9><CA><CB><CC><CD><CE><CF><D0><D1><D2><D3><
D4><D5><D6><D7><D8><D9><DA><DB><DC><DD><DE><DF><E0><E1><E2><E3><E4><E5><E6><E7><
E8><E9><EA><EB><EC><ED><EE><EF><F0><F1><F2><F3><F4><F5><F6><F7><F8><F9><FA><FB><
FC><FD><FE><FF>
(line breaks added after string created, not in string itself)
Hmm, looking at that output I see one non-printable character that
didn't get converted to printable representation. Can you see it
too? I guess I should fix that ... done, running that test again:
(format t "~A~%"
(string-to-showstr
(map 'string #'code-char
(loop for ix from 0 to 255 collect ix))))
<00><01><02><03><04><05><06><07><08><09><0A><0B><0C><0D><0E><0F><10><11><12><13>
<14><15><16><17><18><19><1A><1B><1C><1D><1E><1F> !"#$%&'()*+,-./0123456789:;<=>?
@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~<7F><80><81><82><
83><84><85><86><87><88><89><8A><8B><8C><8D><8E><8F><90><91><92><93><94><95><96><
97><98><99><9A><9B><9C><9D><9E><9F><A0><A1><A2><A3><A4><A5><A6><A7><A8><A9><AA><
AB><AC><AD><AE><AF><B0><B1><B2><B3><B4><B5><B6><B7><B8><B9><BA><BB><BC><BD><BE><
BF><C0><C1><C2><C3><C4><C5><C6><C7><C8><C9><CA><CB><CC><CD><CE><CF><D0><D1><D2><
D3><D4><D5><D6><D7><D8><D9><DA><DB><DC><DD><DE><DF><E0><E1><E2><E3><E4><E5><E6><
E7><E8><E9><EA><EB><EC><ED><EE><EF><F0><F1><F2><F3><F4><F5><F6><F7><F8><F9><FA><
FB><FC><FD><FE><FF>
Robert Maas, http://tinyurl.com/uh3t
> You don't need to be an admin to install a Lisp implementation, you
> can do it as a user. That's how I run SBCL on my machine. 15 minutes
> of work and you are done. You can also keep up with the latest
> releases without relying on anyone else.
Hmm, thanks for suggesting it at *this* time! On the old shell
machine, my total allocation was 200 MB, and I was already using
over 160 MB, plus an extra 62MB in my system mailbox that I
couldn't move to my file hierarchy because then I'd be over
allocation. It would have been dangerous to install any major
software in that 40MB unused, because if the accounting program
were ever fixed to *count* my system mailbox then I'd need to
immediately get rid of 22MB already to get back within allocation,
and any extra stuff I didn't need would only make the problem
worse.
But on this new shell machine, my total allocation is 500 MB, and
I've already moved that system mailbox to my file hierarchy because
there's plenty of space:
> df -k ~
Filesystem 1024-blocks Used Avail Capacity Mounted on
tank/users/rem 512000 216960 295040 42% /home/users/rem
I've already requested a MySQL database of minimal 100MB size,
which the admin should get around to in a few weeks, so that will
cut my Avail from 295MB down to 195MB. How much of that would be
required to hold *everything* needed to build a new CMUCL (except
of course what's standard on FreeBSD such as GNU C compiler etc.)?
if it doesn't require more than about 20MB then I'd be glad to do
it. If it requires appx. 50MB, then maybe I'd be willing. If it
requires appx. 100MB then I don't think I can really afford to do
it.
> Consider using clbuild for automating this, and other things.
If it doesn't require more than 50MB total, so I'd be willing to
try, then I'll need a URL to show me where to find the best version
of CMUCL to build for this particular system:
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 7.1-PRERELEASE (SHELL0) #0: Mon Mar 23 03:17:26 PDT 2009
> If you find a bug, it is always good manners to verify that it
> hasn't been fixed in the latest release before raising the issue.
Actually there's no point in a mere user going to all the trouble
to build a new version without first checking if doing so might
likely fix a known bug and also finding out *which* version to try
building. I would hate to install a version that crashes my entire
shell and login or even worse crashes UNIX itself. (More likely a
horrible system bug in CMUCL would start a runaway process that
would consume too much CPU, causing the admin to manually kill my
login and get angry at me and retaliate against me in various
ways.)
I wish there was an archive of bugs that various versions of CMUCL
had when running on various versions of Unix/Linux/etc. together
with a search engine whereby I could describe my problem and
retrieve info about which versions of CMUCL had such a known
problem on same or similar versions of FreeBSD. Lacking that,
posting to this newsgroup seems the most reasonble way to get clues
to what might be wrong (page fault causing new type of signal that
some versions of CMUCL including the one I'm using didn't handle
properly) and whether it has yet been fixed in a newer version of
CMUCL that would work on this version of FreeBSD Unix. I peeked
ahead in this thread and saw somebody mention that the very
*latest* version of CMUCL would *not* work on this system because
it was built for a *newer* version of FreeBSD Unix. So I need to be
really careful to choose the appropriate version of CMUCL, one new
enough to have the bug fixed, but not so new that it would require
a new version of FreeBSD Unix to run on.
(The reverse problem, of new version of OS no longer capable of
running old software versions, also happens. I'm still burned that
Macintosh Allegro Common Lisp 1.2.2 which worked fine on my
Macintosh Plus running System 6.0.3, until the 'Plus died in
mid-1999, *freezes* my Macintosh Performa running system 7.5.5 if
I try to run it. The only Lisp I can find for my Performa that
runs even halfway usably is PowerLisp 2.01 68k.)
(I've almost decided, after I finish the current emergency project
to rescue my GeoCities files, and then after I get NewEco running
well enough to provide a way I can "pay" others to help me write
software instead of having to do everything myself or rely on
volunteer labor via newsgroups, that I'll implement Lisp in Forth,
using a reference-count system with lazy prorated reclamation
during times of heavy load and idle-time reclamation during idle
times such as during calls to SLEEP or when polling for user input.
I'm hoping I can build a Lisp-in-Forth that has fewer bugs than
PowerLisp, as well as *never* freezing for five minutes due to GC
in progress or ERROR signal handling, and implementing lexical
variables and closures *properly* unlike PowerLisp.)
Barry Margolin
seeWeb...@rem.intarweb.org (Robert Maas, http://tinyurl.com/uh3t)
wrote:
> (length (setq pr (read-from-string textstr)))
> obtains the (account password) pair, which I most definitely do
> *not* want an eavesdropper to be able to see, hence the LENGTH
> around it to allow the inner SETQ etc. to execute but hide the
> account-password pair from visibility. Letting eavesdropper see it
> would allow said person to get into my geocities account and delete
> all the files I'm urgently trying to rescue before GeoCities closes
> later this month, as well as get into my e-mail account and wreak
> disaster.
>
> (length (push pr g*YM-assoc-acct+pw))
> pushes that pair onto a list which contains *all* the account names
> and corresponding passwords so-far uploaded. Letting an
> eavesdropper see that even once would allow that person to get into
> *all* my Yahoo! Mail and Geocities accounts and wreak havoc
> multipled by number of accounts. Hence it's even more urgent to
> protect that line of code with LENGTH.
When I want to evaluation an expression in the REPL but not display the
result (usually because the result is really long, not for security), I
usually use:
(progn <expression> nil)
Maybe REPLs need an option to turn off the P part of the loop.
Robert Maas, http://tinyurl.com/uh3t
> >> >| (UNIX::SIGBUS-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP
> >> >| #x47FE1E7C)) %primitive halt called; the party is over. LDB monitor
> >> >| ldb> backtrace
> >> >| Backtrace:
> >> This kind of error usually comes from something fundamental going wrong
> >> than from invalid ERROR forms in my experience.
> >> The operating system version would be useful to know here too. FreeBSD
> >> changed which signal is generated for page protection faults, these are
> >> used to help the garbage collector.
> >Hmm, the older version of CMUCL on the old shell machine worked
> >reasonably well, with only one known bug (sleep of floating point
> >greater than one second returned *immediately*). This newer version
> >of CMUCL on new shell machine bombs badly. It's possible that when
> >the admin installed it, he configured it for page faults from the
> >old system which aren't correct for the new system.
> There isn't really any configuration involved, the switch is done
> based on the version of operating system used to build CMUCL.
So, do I understand you correctly: If this version of CMUCL was
built on a version of FreeBSD *before* the change, then it'll bomb
out when trying to run on any version of FreeBSD *after* the
change?
> >Here's the new system info:
> >Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
> > The Regents of the University of California. All rights reserved.
> >FreeBSD 7.1-PRERELEASE (SHELL0) #0: Mon Mar 23 03:17:26 PDT 2009
> FreeBSD 7.1 is after the signal change.
So what we need to know now is whether the CMUCL I'm trying to use
was built on any FreeBSD *before* the signal change, in which case
it'd have wrong signal handler, correct?
> >snapdragon.csl.sri.com ...
> This is the home machine of the CMUCL developer who produced the
> FreeBSD, you can assume that the build was correct at the time.
Oh, OK, thanks for quickly resolving that red herring.
Ah, thanks for that URL, good info there, except one thing missing,
regarding the fix to SLEEP which occurred between the version I was
using on the old shell and the newer version I'm using (the one
with apparent page-fault signal bug):
CMU Common Lisp 18b, running on shell.rawbw.com
* (time (sleep 3.5))
Evaluation took:
0.0 seconds of real time
;It didn't sleep at all, bug I programmed around:
;Bug in CMU-CL: (sleep sec) where sec is a non-integer 1.0 or larger
; returns immediately without sleeping at all. To get around the bug:
(defun cl-sleep (sec)
(cond ((and (not (integerp sec)) (>= sec 1.0))
(multiple-value-bind (int frac) (floor sec)
(sleep int) (sleep frac)))
(t (sleep sec))))
CMU Common Lisp 19c Release (19C), running on shell0.rawbw.com
* (time (sleep 3.5))
; Evaluation took:
; 3.5 seconds of real time
;The bug has been fixed!
But when was it fixed? I see no mention of 'sleep' in any of the
release notes from 18c through 19c. Maybe if my upcoming NewEco
includes a RevTre-TruFut-pseudoWiki for CMUCL, paid volunteers will
eventually build a complete set of release notes that lists *all*
noticeable bugfixes for each release where the fix first occurred?
Back to replying to your message, sorta, actually trying to find
info about the latest releases, to see what they were built on:
<http://common-lisp.net/project/cmucl/downloads/release/20a/release-20a.txt>
- Support for Unicode has been added. You have Unicode support if
*FEATURES* includes :UNICODE.
o CHAR-CODE-LIMIT is 65536.
o There is only one string type; STRING and BASE-STRING are the
same type. All strings are UTF-16 strings and therefore
contain UTF-16 surrogate pairs.
s/therefore contain/therefore MAY contain/
Only if a UniCode character outside the 16-bit "basic plane" needs
to be encoded, then surrogate pairs would be used (or some broken
code that generates surrogate pairs unnecessarily).
- SXHASH was computing the same hash code for upper and lower case
characters by up-casing the character. This isn't necessary
since the characters are not EQUAL, so make SXHASH return
different values for upper and lower case letter.
Doh!!! How come it took so long for somebody to notice that obvious
bug in concept?
Version 20a is built against FreeBSD 7.2 so I would try something a
bit earlier, try 19f.
| cmucl-20a-x86-freebsd_7.2-stable.extra.tar.bz2
OK, I presume that would not work on FreeBSD 7.1, as you stated
(your quoted text later, moved up here for reply). Working
backwards from there now...
[ ] cmucl-19f-x86-freebsd_7.1-stable.extra.tar.bz2 11-Mar-2009 00:22 4.6M
[TXT] cmucl-19f-x86-freebsd_7.1-stable.extra.tar.bz2.asc 11-Mar-2009 00:23 1k
[ ] cmucl-19f-x86-freebsd_7.1-stable.tar.bz2 11-Mar-2009 00:23 14.5M
[TXT] cmucl-19f-x86-freebsd_7.1-stable.tar.bz2.asc 11-Mar-2009 00:23 1k
Hmm, which of those would I need, if I chose that particular version?
Next I looked through *all* the release notes for versions from the
broken 19c I'm using to the very latest, searching for either
'signal' or 'FreeBSD', and I see no mention of fixing the
page-fault signals that are being generated by FreeBSD 7.1.
> You are running an official build, your sysadmin hasn't done any
> configuration at all, you just need a build that matches your
> operating system version.
So I did manage to find that cmucl-19f-x86-freebsd_7.1-stable...
but I don't know whether it includes the page-fault-signal bugfix.
Should I just give it a royal try?
The tar.gz seems to total about 20 MB, so that'd be 50MB after
expansion, 100MB or more with all the temporaries, so I'm not sure
I have enough disk space to build it.
Let me check the system directories to see how large they are:
> whereis cmucl
cmucl: /usr/local/man/man1/cmucl.1.gz /usr/ports/lang/cmucl
> cd /usr/ports/lang/cmucl
> ls
total 9
2 Makefile 1 distinfo 2 pkg-descr 2 pkg-plist 2 work/
> du
949 ./work/lib/cmucl/lib/subsystems
24020 ./work/lib/cmucl/lib
24309 ./work/lib/cmucl
24311 ./work/lib
388 ./work/bin
16 ./work/doc/cmucl
17 ./work/doc
24 ./work/man/man1
25 ./work/man
24752 ./work
24761 .
Hmm, only 25MB total there. Presumably 19f wouldn't be much larger?
Maybe I'd have enough space to build it after all?
(Technically I'm not really building it, just gunzipping and then
trying to figure out how to untar it.)
I'll wait until I get advice whether 19f has the bugfix or not
before I attempt to download-and-install it.
Hmm, curious note in the currently-installed (broken) version of CMUCL:
<file://localhost/usr/ports/lang/cmucl/work/doc/cmucl/README>
+++ FreeBSD/x86
The release binaries should work with any Pentium or better processor.
The binaries were built on FreeBSD 4.7, but should run on any of the
4.x releases.
Nowhere does it say it should work on 5.x or 6.x or 7.x, right?
I wonder if my ISP's admin just plain goofed there?
joseph...@gmail.com
>
> When I want to evaluation an expression in the REPL but not display the
> result (usually because the result is really long, not for security), I
> usually use:
>
> (progn <expression> nil)
>
> Maybe REPLs need an option to turn off the P part of the loop.
>
DEFPARAMETER is another useful trick, and has the advantage of keeping
the result of the evaluation around for further study.
Robert Swindells
Robert Maas wrote:
> From: Robert Swindells <r...@fdy2.demon.co.uk>
> >> >| (UNIX::SIGBUS-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP
> >> >| #x47FE1E7C)) %primitive halt called; the party is over. LDB monitor
> >> >| ldb> backtrace
> >> >| Backtrace:
[snip]
>> Look at <http://common-lisp.net/project/cmucl/downloads/release>.
>Ah, thanks for that URL, good info there, except one thing missing,
>regarding the fix to SLEEP which occurred between the version I was
>using on the old shell and the newer version I'm using (the one
>with apparent page-fault signal bug):
[snip]
>But when was it fixed? I see no mention of 'sleep' in any of the
>release notes from 18c through 19c. Maybe if my upcoming NewEco
>includes a RevTre-TruFut-pseudoWiki for CMUCL, paid volunteers will
>eventually build a complete set of release notes that lists *all*
>noticeable bugfixes for each release where the fix first occurred?
If you really care then look at the CVS logs.
>>Version 20a is built against FreeBSD 7.2 so I would try something a
>>bit earlier, try 19f.
>
>| cmucl-20a-x86-freebsd_7.2-stable.extra.tar.bz2
>
>OK, I presume that would not work on FreeBSD 7.1, as you stated
>(your quoted text later, moved up here for reply). Working
>backwards from there now...
>
> [ ] cmucl-19f-x86-freebsd_7.1-stable.extra.tar.bz2 11-Mar-2009 00:22 4.6M
> [TXT] cmucl-19f-x86-freebsd_7.1-stable.extra.tar.bz2.asc 11-Mar-2009 00:23 1k
> [ ] cmucl-19f-x86-freebsd_7.1-stable.tar.bz2 11-Mar-2009 00:23 14.5M
> [TXT] cmucl-19f-x86-freebsd_7.1-stable.tar.bz2.asc 11-Mar-2009 00:23 1k
>
>Hmm, which of those would I need, if I chose that particular version?
You wouldn't need the 'extra' tarball if you just run CMUCL in a
terminal, it contains CLX, the Motif interface and the Hemlock editor.
>Next I looked through *all* the release notes for versions from the
>broken 19c I'm using to the very latest, searching for either
>'signal' or 'FreeBSD', and I see no mention of fixing the
>page-fault signals that are being generated by FreeBSD 7.1.
We don't put *every* change into release notes,
From memory it was more a case of the CMUCL developer who was
producing the FreeBSD builds picking a point where he felt that 7.0
had become stable enough to be a useful build target.
>> You are running an official build, your sysadmin hasn't done any
>> configuration at all, you just need a build that matches your
>> operating system version.
>
>So I did manage to find that cmucl-19f-x86-freebsd_7.1-stable...
>but I don't know whether it includes the page-fault-signal bugfix.
>Should I just give it a royal try?
You can either take my word for it or look through the CVS logs
yourself.
>The tar.gz seems to total about 20 MB, so that'd be 50MB after
>expansion, 100MB or more with all the temporaries, so I'm not sure
>I have enough disk space to build it.
[snip]
>Hmm, only 25MB total there. Presumably 19f wouldn't be much larger?
>Maybe I'd have enough space to build it after all?
>(Technically I'm not really building it, just gunzipping and then
> trying to figure out how to untar it.)
The 19f release will take up more space than earlier ones by default,
this can be reduced if you really need the space once you have it
working.
>I'll wait until I get advice whether 19f has the bugfix or not
>before I attempt to download-and-install it.
Which bugfix ?
Robert Swindells
Robert Maas, http://tinyurl.com/uh3t
last version of CMUCL that was configured for FreeBSD 7.1, and
tried it just now:
> ls ~/Tmps/TmpCmucl
2 bin/
2 cmu-user/
1924 cmu-user-html.tar
51498 cmucl-19f-x86-freebsd_7.1-stable.tar
2 doc/
2 lib/
2 man/
> du -d 0 ~/Tmps/TmpCmucl
107220 /home/users/rem/Tmps/TmpCmucl
> /home/users/rem/Tmps/TmpCmucl/bin/lisp
CMU Common Lisp 19f (19F), running on shell0.rawbw.com
With core: /home/users/rem/Tmps/TmpCmucl/lib/cmucl/lib/lisp-sse2.core
Dumped on: Tue, 2009-03-10 20:47:48-07:00 on daland
See <http://www.cons.org/cmucl/> for support information.
Loaded subsystems:
Python 1.1, target Intel x86
CLOS based on Gerd's PCL 2008-11-12 16:36:41
.. load all my source files ...
(list ;(trace strs-show-differences)
(unix-set-date-start-boot-to-mac)
(g-load-unix824)
(unix-yah-restore-acct+pw)
.. ran up to the same point where CMUCL 19c crashed, then:
Close enough to retrain now?y
* Size of expected string decreased from 1058 to 712.
See the proposed changes in expect-string?y
Help! 12 nested errors. KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded.
Debug (type H for help)
(UNIX::SIGSEGV-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP #x47FE0500)
)
%primitive halt called; the party is over.
LDB monitor
ldb>
Conclusion, the bug was never fixed in any version that has been
built to run on FreeBSD 7.1.
So will somebody with connections to the CMUCL builders club please
report this apparent bug to them?
Next I tried exactly the same thing but with tracing enabled:
(list (trace strs-show-differences)
(unix-set-date-start-boot-to-mac)
(g-load-unix824)
(unix-yah-restore-acct+pw)
(unix-yahoo-acct-verify-pw "ChineseEnglish76")
)
and just like with CMUCL 19c it crashed while trying to print the
first parameter to the function being called:
y
* Size of expected string decreased from 1058 to 712.
See the proposed changes in expect-string?y
0: (STRS-SHOW-DIFFERENCES
"[H[H[J[48CSign in - Yahoo! Mail (p1 of 2)
Yahoo! Mail [1mHelp[m - [1mYahoo![B[23D[m_________________________________________________________________
[4mWelcome to Yahoo! Mail [8;19HYou must sign in to read or send mail. [10;13HNew to Yahoo!?[B[23D[1mSign up now[m[4m to enjoy Yahoo! Mail [B[33D[mYahoo! Mail Yahoo! Mail
[1m[4mSign up now[B[12D[m[1mLearn more...[16;4H[m[4mExisting Yahoo! users[B[20D[mEnter your ID and password to sign in
Yahoo! ID: [1m________[B[mPassword: [1m_________________[B[ ][m Remember my ID on this computer[21;15H[1mSign In[24;80H[m[A Arrow keys: Up and Down to move. Right to follow a link; Left to go back.
H)elp O)ptions P)rint G)o M)ain screen Q)uit /=search [delete]=history list [H[21B[7m(Text entry field) Enter text. Use UP or DOWN arrows or tab to move off.[m[18;15H________[5B Enter text into the field by typing on the keyboard[K
Ctrl-U to delete all text in field, [Backspace] to delete a character
[H[H[J[23B
[Hign in - Yahoo! Mail (p1 of 2)Yahoo! Mail [1mHelp[m - [1mYahoo![m_________________________________________________________________mWelcome to Yahoo! MailExisting Yahoo! users[BEnter your ID and password to sign in
Yahoo! [1mm_________________ Remember my ID on this computermSign In[m[A Arrow keys: Up and Down to move. Right to follow a link; Left to go back.
H)elp O)ptions P)rint G)o M)ain screen Q)uit /=search [delete]=history list [7m(Text entry field) Enter text. Use UP or DOWN arrows or tab to move off.[m[1;15H________ Enter text into the field by typing on the keyboard
Ctrl-U to delete all text in field, [Backspace] to delete a character
elp! 12 nested errors. KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded.
Debug (type H for help)
%primitive halt called; the party is over.
LDB monitor
ldb>
Robert Maas, http://tinyurl.com/uh3t
> >Ah, thanks for that URL, good info there, except one thing missing,
> >regarding the fix to SLEEP which occurred between the version I was
> >using on the old shell and the newer version I'm using (the one
> >with apparent page-fault signal bug):
> [snip]
> >But when was it fixed? I see no mention of 'sleep' in any of the
> >release notes from 18c through 19c. Maybe if my upcoming NewEco
> >includes a RevTre-TruFut-pseudoWiki for CMUCL, paid volunteers will
> >eventually build a complete set of release notes that lists *all*
> >noticeable bugfixes for each release where the fix first occurred?
> If you really care then look at the CVS logs.
No time, urgently need to finish this current emergency software
task (automatically catalog all my GeoCities files and download
them before they all disappear when Yahoo shuts down GeoCities on
Oct.26) any way I can. My curiosity about when SLEEP was fixed to
handle floating point values greater than or equal to 1.0 must go
onto back burner.
> You wouldn't need the 'extra' tarball if you just run CMUCL in a
> terminal, ...
Also I run it under CGI. I presume that wouldn't need extras either.
> We don't put *every* change into release notes,
Sigh, back burner for curiosity about when SLEEP was fixed.
> From memory it was more a case of the CMUCL developer who was
> producing the FreeBSD builds picking a point where he felt that 7.0
> had become stable enough to be a useful build target.
Which begs the quetion about FreeBSD 7.1 which suddenly introduced
incompatible page-fault signals, which are crashing CMUCL, if the
other poster in this thread is correct.
> >So I did manage to find that cmucl-19f-x86-freebsd_7.1-stable...
> >but I don't know whether it includes the page-fault-signal bugfix.
> >Should I just give it a royal try?
> You can either take my word for it or look through the CVS logs
> yourself.
What exactly are you giving your word about? You never said that
*any* version of CMUCL whatsoever has fixed the page-fault
new-signal bug introduced by FreeBSD 7.1, and in fact (see other
article in this thread, i.e. <news:REM-2009...@Yahoo.Com>)
earlier this afternoon I did indeed download
cmucl-19f-x86-freebsd_7.1-stable.tar and try it, only to find it
dies exactly the same place that 19c did, so obviously they haven't
yet fixed whatever bug my lots-of-large-strings application is
triggering.
> >The tar.gz seems to total about 20 MB, so that'd be 50MB after
> >expansion, 100MB or more with all the temporaries, so I'm not sure
> >I have enough disk space to build it.
In fact it uses 107 megabytes of my disk space, which is too much
to keep around if it doesn't work anyway. If it worked, I'd delete
all the unnecessary files and keep just the part I'm actually
using, probaby 50 MB or less, but with it not working I'll just
delete the whole mess as soon as I need the space for something
else.
> >Hmm, only 25MB total there. Presumably 19f wouldn't be much larger?
> >Maybe I'd have enough space to build it after all?
> >(Technically I'm not really building it, just gunzipping and then
> > trying to figure out how to untar it.)
> The 19f release will take up more space than earlier ones by default,
> this can be reduced if you really need the space once you have it
> working.
The executable just by itself is 51498 1024-byte disk blocks.
> >I'll wait until I get advice whether 19f has the bugfix or not
> >before I attempt to download-and-install it.
Belay that. I went ahead and tried 19f, see other article.
> Which bugfix ?
Handling the new kinds of page-fault interrupts that FreeBSD 7.1
geerates, which seems to crash handling of large strings in CMUCL
right through to 19f. 20a doesn't have a FreeBSD build, so I can't
easily try it.
I'm just going to try a short punt, deleting the relevant
lynx-scrape training file and starting training from scratch, and
if that doesn't work then I'll do a long punt, a complete re-write
of my Web-spidering-with-cookies/login stuff using ext:run-program
+ 'curl' instead of ext:run-program + 'lynx' + fuzzy-match-output.
Thomas A. Russ
> When I want to evaluation an expression in the REPL but not display the
> result (usually because the result is really long, not for security), I
> usually use:
>
> (progn <expression> nil)
I often choose the more postitive variant of this:
(progn <expression> t)
;-D
--
Thomas A. Russ, USC/Information Sciences Institute
Vassil Nikolov
On Mon, 05 Oct 2009 17:13:39 -0400, Barry Margolin <bar...@alum.mit.edu> said:
> When I want to evaluate an expression in the REPL but not display the
> usually use:
> (progn <expression> nil)
On a tangent, this yields a one-minute code golf problem: what is
the smallest (by character count) wrapper of an expression that
achieves the same effect?
Naturally, only what is part of the standard is admissible
(otherwise a character macro that reads as the above form is a
trivial solution).
Needless to say, such a short wrapper will likely not express the
_intent_ nearly as well as the above form (or the very pedantical
(PROGN e (VALUES))).
> Maybe REPLs need an option to turn off the P part of the loop.
Yes, like LOAD has such an option (with the opposite default).
Robert Maas, http://tinyurl.com/uh3t
> lynx-scrape training file and starting training from scratch, and
> if that doesn't work then I'll do a long punt, a complete re-write
> of my Web-spidering-with-cookies/login stuff using ext:run-program
> + 'curl' instead of ext:run-program + 'lynx' + fuzzy-match-output.
I tried the short punt, deleting any lynx-scrape training file
that caused a crash when it was compared with actual output from
lynx, and after each reset of that particular training file the
overall process got a step or two further along in the process of
logging into Yahoo! Mail automatically, but finally it died anyway.
So now it's time for the long punt, re-writing this entire
Web-spider-with-cookies/login using 'curl' instead of 'lynx'.
Here's a transcript of the very last run before I gave up:
** sub-lynx-expect-file-once: "ref-pty-equallink1"
(#=927/146 frac=0.993)
** sub-lynx-expect-file-once: "ref-pty-print1"
(#=812/487 frac=1.000)
** sub-lynx-expect-file-once: "ref-pty-print2"
(#=110/28 frac=1.000)
** sub-lynx-expect-file-once: "ref-pty-equallink1"
(#=160/146 frac=0.068) (#=936/146 frac=0.993)
** sub-lynx-expect-file-once: "ref-pty-active"
(#=1233/659 frac=1.000) [Follow link... (#=111/138 frac=0.051) 0123 (#=1869/13
8 frac=1.000) 0 (#=1751/138 frac=1.000) done] [Move down...
** sub-lynx-expect-file-once: "ref-pty-findyahooform"
(#=496/299 frac=1.000) done, refresh-verify...
** sub-lynx-expect-file-once: "ref-pty-foundyahooform"
(#=1775/709 frac=0.999) good] [Follow link to YM login form... (#=1090/75 frac
=1.000) 0 (#=908/75 frac=1.000) done]
** sub-lynx-expect-file-once: "ref-pty-topyahoologin-reload"
(#=197/56 frac=1.000)
** sub-lynx-expect-file-once: "ref-pty-topyahoologin"
0 (#=908/75 frac=1.000) [Move down to ID TextField...
** sub-lynx-expect-file-once: "ref-pty-yahoologinfield"
(#=673/480 frac=1.000) done, refresh-verify...
** sub-lynx-expect-file-once: "ref-pty-yahoologinskip1r"
(#=1113/1113 frac=1.000) done] [Writing ID&PW into form...
** sub-lynx-expect-file-once: "ref-pty-yahoologindid2"
(#=765/436 frac=1.000) done, refresh...
** sub-lynx-expect-file-once: "ref-pty-yahoo-at-login"
(#=927/927 frac=1.000) done] [Click submit login...
** sub-lynx-expect-file-once: "ref-pty-ask-allow-YNAV"
(#=171/325 frac=0.391) 012 (#=220/325 frac=0.542) (#=325/325 frac=0.778) 0123
(#=467/325 frac=1.000) done. Accept all cookies...[.....Help! 12 nested errors.
KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded.
Debug (type H for help)
(UNIX::SIGBUS-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP #x47FE1E7C))
%primitive halt called; the party is over.
LDB monitor
ldb>
That was with CMUCL 19c. Next I re-tried exactly the same script
with CMUCL 19f, and it crashed at the same place, confirming my
decision to give up (until CMUCL gets the bug fixed).
So now I've been learning how to handle cookies and other stuff
using 'curl', by manually composing the entire command line in
McSink (text editor) on my Mac, then copying from there and pasting
through VT100 emulator to the FreeBSD Unix shell. Each command line
is considerably longer than 255 characters, but VersaTerm copies it
across just fine, and the Unix shell accepts it too. So-far I've:
- submitted the contents of a login form to Yahoo's login server,
- gotten back some cookies and a redirection to a 'verify' URL,
- submitted that URL with the cookies,
- gotten back the same cookies and a redirection to a 'welcome' URL,
- submitted that URL with the same cookies again,
- gotten back the same cookies again and a regular HTML page, which
I'll need to inspect to see if it's successful or failed login
(but having seen the redirection to the 'welcome' URL already,
I'm pretty sure it's a successful login).
Next I'll need to do all this from ext:run-program inside CMUCL, so
that the command parameters can be built automatically, and so that
the replies can be automatically checked for everything going well
so-far and automatically parsing the next URL in the login
redirection chain, and hope it doesn't crash.
Tamas K Papp
wrote:
> If it doesn't require more than 50MB total, so I'd be willing to try,
$ du -sh ~/software/clbuild
31M /home/tpapp/software/clbuild
That includes SBCL, and various libraries.
> then I'll need a URL to show me where to find the best version of CMUCL
> to build for this particular system: Copyright (c) 1980, 1983, 1986,
Sorry, you will have to figure that out yourself.
Unless you have a compelling reason not to, I would really recomend
trying SBCL.
Tamas
Madhu
* (Robert Maas) <REM-2009...@Yahoo.Com> :
Wrote on Mon, 05 Oct 2009 15:30:21 -0700:
| ;Bug in CMU-CL: (sleep sec) where sec is a non-integer 1.0 or larger
| ; returns immediately without sleeping at all. To get around the bug:
[snip]
| ;The bug has been fixed!
|
| But when was it fixed?
1998-09-26. I dug up this information the last time you asked! See my
message
Date: Thu, 08 May 2008 19:32:55 +0530
Message-ID: <m3hcd8u...@meer.net>
Subject: Re: Stupidity in CMUCL prettyprinter
--
Madhu
Pascal J. Bourguignon
> When I want to evaluate an expression in the REPL but not display the
> result (usually because the result is really long, not for security), I
> usually use:
>
> (progn <expression> nil)
>
> Maybe REPLs need an option to turn off the P part of the loop.
Your wish is my command:
(defmacro handling-errors (&body body)
`(handler-case (progn ,@body)
(simple-condition
(err)
(format *error-output* "~&~A: ~%" (class-name (class-of err)))
(apply (function format) *error-output*
(simple-condition-format-control err)
(simple-condition-format-arguments err))
(format *error-output* "~&"))
(condition
(err)
(format *error-output* "~&~A: ~% ~S~%"
(class-name (class-of err)) err))))
(defun rel ()
(do ((+eof+ (gensym))
(hist 1 (1+ hist)))
(nil)
(format t "~%~A[~D]> " (package-name *package*) hist)
(handling-errors
(let ((form (read *standard-input* nil +eof+)))
(cond ((or (eq form +eof+)
(member form '((quit)(exit)(continue))
:test (function equal)))
(return-from rel))
((member form '(:p :print) :test (function equal))
(format t "~& --> ~{~S~^ ;~% ~}~%" /))
(t
(setf +++ ++ ++ + + - - form
/// // // / / (multiple-value-list (eval -))
*** ** ** * * (first /))
(format t "~& --> ~R value~:*~P~%" (length /))))))))
C/USER[63]> (rel)
COMMON-LISP-USER[1]> (truncate 10 3)
--> two values
COMMON-LISP-USER[2]> :p
--> 3 ;
1
COMMON-LISP-USER[3]> (+ 1 2)
--> one value
COMMON-LISP-USER[4]> :print
--> 3
COMMON-LISP-USER[5]> (quit)
NIL
C/USER[64]>
</evilgenius>
The standard has *PRINT-LENGTH* *PRINT-LEVEL* *PRINT-LINES*
*PRINT-ARRAY*...
--
__Pascal Bourguignon__
Björn Lindberg
> If you find a bug, it is always good manners to verify that it hasn't
> been fixed in the latest release before raising the issue.
Not to mention raising the issue in the right fora, i.e. the project
mailing lists.
Bj�rn Lindberg
Raymond Toy
Robert> I've already requested a MySQL database of minimal 100MB size,
Robert> which the admin should get around to in a few weeks, so that will
Robert> cut my Avail from 295MB down to 195MB. How much of that would be
Robert> required to hold *everything* needed to build a new CMUCL (except
Robert> of course what's standard on FreeBSD such as GNU C compiler etc.)?
Why build it? Just go grab the binaries from common-lisp.net. The
20a build takes about 75 MB, unpacked, but that includes the extra
stuff (hemlock, clx, etc.), which you may not need.
Robert> Actually there's no point in a mere user going to all the trouble
Robert> to build a new version without first checking if doing so might
Robert> likely fix a known bug and also finding out *which* version to try
Robert> building. I would hate to install a version that crashes my entire
I've been following along, but, frankly, I can't see what the bug
could be because there just isn't enough information for me to figure
it out. If the code isn't too bug, perhaps you can send it so I can
try to reproduce the bug. But I don't have FreeBSD, so this might not
be of any help.
Robert> I wish there was an archive of bugs that various versions of CMUCL
Robert> had when running on various versions of Unix/Linux/etc. together
Robert> with a search engine whereby I could describe my problem and
Robert> retrieve info about which versions of CMUCL had such a known
Robert> problem on same or similar versions of FreeBSD. Lacking that,
Sorry, but the only archive I know of is the mailing lists.
Robert> posting to this newsgroup seems the most reasonble way to get clues
Robert> to what might be wrong (page fault causing new type of signal that
Robert> some versions of CMUCL including the one I'm using didn't handle
Robert> properly) and whether it has yet been fixed in a newer version of
Robert> CMUCL that would work on this version of FreeBSD Unix. I peeked
Robert> ahead in this thread and saw somebody mention that the very
Robert> *latest* version of CMUCL would *not* work on this system because
Robert> it was built for a *newer* version of FreeBSD Unix. So I need to be
Robert> really careful to choose the appropriate version of CMUCL, one new
Robert> enough to have the bug fixed, but not so new that it would require
Robert> a new version of FreeBSD Unix to run on.
Well, the common-lisp.net binaries have pretty clear names that
include the version of FreeBSD that was used to build these on.
Ray
Raymond Toy
Thomas> Barry Margolin <bar...@alum.mit.edu> writes:
>> When I want to evaluation an expression in the REPL but not display the
>> result (usually because the result is really long, not for security), I
>> usually use:
>>
>> (progn <expression> nil)
Thomas> I often choose the more postitive variant of this:
Thomas> (progn <expression> t)
I use (prog1 t <expression>), because with progn I sometimes forget to
add the final nil or t, thereby blowing up emacs with too much output.
Ray
Robert Maas, http://tinyurl.com/uh3t
> Robert> which the admin should get around to in a few weeks, so that will
> Robert> cut my Avail from 295MB down to 195MB. How much of that would be
> Robert> required to hold *everything* needed to build a new CMUCL (except
> Robert> of course what's standard on FreeBSD such as GNU C compiler etc.)?
> Why build it? Just go grab the binaries from common-lisp.net.
Sorry for the mistaken jargon caused by never having done this sort
of thing before. Indeed all I needed to do was find the appropriate
tar.gz on the Web site that somebody else showed me, click on it,
confirm download, gunzip, then spend a half hour studying the 'man
tar' pages and doing guesswork before I finally figured out the
correct tar command for unpacking it all from the tar file on the
disk. ('man tar' doesn't show any example of this **common** type
of task that needs to be done.)
> The 20a build takes about 75 MB, ...
There isn't any 20a build available for FreeBSD 7.1, only for
FreeBSD 8.0, and it's my understanding the two aren't compatible.
> I can't see what the bug could be because there just isn't enough
> information for me to figure it out.
Because I have no idea how to use LDB to look at the innerds of
CMUCL, and nobody in this thread has told me any LDB commands that
would provide the information needed. The only reasonable clue
so-far is that FreeBSD 7.1 introduces new types of signals for page
faults, which CMUCL doesn't yet know how to handle, so these
page-fault signals cause CMUCL to crash utterly with PRIMITIVE HALT
which is then intercepted by LDB somehow.
> If the code isn't too bug, perhaps you can send it so I can try
> to reproduce the bug.
It's a large application that keeps track of usernames and
passwords on Yahoo and performs automatic login by using
ext:run-program to control lynx as a sub-process and scrapes the
output from lynx using fuzzy string comparison to decide what it is
"seeing" from lynx to decide whether the previous lynx command
worked and what state lynx is in now so that the next lynx command
can be chosen appropriately. I've spent several years developing
this software, so I'm not going to just give over my code to a
stranger, and the application involves confidential usernames and
passwords so I'm not going to give any stranger the information
needed to log into my Yahoo accounts to verify the program crashes
and diagnose what is causing it.
> But I don't have FreeBSD,
Unless you have *exactly* FreeBSD 7.1, which has these new
page-fault signals, you won't be able to test the problem at all.
> Robert> I wish there was an archive of bugs that various versions of CMUCL
> Robert> had when running on various versions of Unix/Linux/etc. together
> Robert> with a search engine whereby I could describe my problem and
> Robert> retrieve info about which versions of CMUCL had such a known
> Robert> problem on same or similar versions of FreeBSD. Lacking that,
> Sorry, but the only archive I know of is the mailing lists.
Is there a search engine for the archive?
> Well, the common-lisp.net binaries have pretty clear names that
> include the version of FreeBSD that was used to build these on.
Yeah, after the other person showed me the archive, and I started
browsing it, I saw indeed it was nicely organized per version of
CMUCL with each directory having such nice names of each
downloadable tar.gz file. See another article in this thread where
I reported that I downloaded cmucl-19f-x86-freebsd_7.1-stable.tar
(that's the name after gunzipping) and tried it, and found the bug
still not fixed, exactly the same crash at the same point in my
application as I was getting with CMUCL 19c.
So last night before bedtime I started re-writing all the
Web-scraping part of my application to use 'curl' instead of 'lynx'
(manually from shell last night, but intending to later run 'curl'
via ext:run-program from CMUCL the same as I had been running
'lynx' before except no fuzzy scraping of output needed, instead
I'll just need to parse the HTTP header that 'curl' delivers to see
whether an operation succeeded or not and to see what state my
Yahoo session is now in).
But this morning I have a new idea: Is there any way in FreeBSD 7.1
to disable those new kinds of page-fault signals being sent to the
application (CMUCL), or is there any way to intercept them en route
so that CMUCL never gets them, or is there any way to configure
CMUCL to ignore them? The result would be that GC doesn't know when
page faults are occurring, so it won't run as efficiently, but at
this point I really don't care, just so the page-fault signals
don't crash CMUCL to LDB. If I can disable those page-fault signals
somehow, and then do the same run that was crashing, and if it
ceases crashing, that would confirm the diagnosis, as well as give
me a workaround.
Robert Swindells
Robert Maas wrote:
>But this morning I have a new idea: Is there any way in FreeBSD 7.1
>to disable those new kinds of page-fault signals being sent to the
>application (CMUCL), or is there any way to intercept them en route
>so that CMUCL never gets them, or is there any way to configure
>CMUCL to ignore them? The result would be that GC doesn't know when
>page faults are occurring, so it won't run as efficiently, but at
>this point I really don't care, just so the page-fault signals
>don't crash CMUCL to LDB. If I can disable those page-fault signals
>somehow, and then do the same run that was crashing, and if it
>ceases crashing, that would confirm the diagnosis, as well as give
>me a workaround.
Since 19f crashes in the same way I don't think your problem has
anything to do with signal delivery.
If you can provide a test case we can have a look at it.
Robert Maas, http://tinyurl.com/uh3t
> | ;Bug in CMU-CL: (sleep sec) where sec is a non-integer 1.0 or larger
> | ; returns immediately without sleeping at all. To get around the bug:
> | But when was it fixed?
> 1998-09-26. I dug up this information the last time you asked! See my
> message
> Date: Thu, 08 May 2008 19:32:55 +0530
> Message-ID: <m3hcd8uc4w....@meer.net>
> Subject: Re: Stupidity in CMUCL prettyprinter
Unfortunately Google Groups has a bug whereby anything with an
atsign in it, not just e-mail addresses but also message IDs, are
masked to prevent spammers' bots from harvesting them. I had to go
to our local NNTP server to get the complete message ID:
> Date: Thu, 08 May 2008 19:32:55 +0530
> Message-ID: <m3hcd8u...@meer.net>
> Subject: Re: Stupidity in CMUCL prettyprinter
Unfortunately that article isn't accessible via Google Groups, and
it's probably much too old to still be in the NNTP cache, but
taking a shot in the dark:
> telnet nntp2.tsoft.net 119
Trying 74.209.131.13...
Connected to ispnews.usenetserver.com.
Escape character is '^]'.
200 TSOFT.COM
HEAD <m3hcd8u...@meer.net>
430 Cant retrieve article, try joining a newsgroup first
quit
205 Exit articles 0, bytes 0, groups 0, posts 0, postbytes 0
Connection closed by foreign host.
As expected, article too old to still be in NNTP cache.
But just to "cover all bases":
> telnet nntp3.tsoft.net 119
Trying 216.168.3.44...
Connected to corp.supernews.com.
Escape character is '^]'.
200 News.GigaNews.Com
HEAD <m3hcd8u...@meer.net>
221 0 <m3hcd8u...@meer.net>
etc.
WTF??? How come such an old article is still in the GigaNews cache?
Anyway, no that's a *different* bug that was fixed.
The bug I found: (sleep floatAtLeast1.0) => returns immediately
The bug they fixed: (sleep floatGreaterThan1.0) => sleeps twice as much as correct
My guess is that they fixed the sleep-twice-as-long bug and thereby
introduced the sleep-not-at-all bug but failed to test on FreeBSD
so the new bug made it out to the version of CMUCL that my old
shell account was using until somebody finally *really* fixed it
correctly sometime before 19c which is installed on new shell
machine.
Raymond Toy
Robert> Sorry for the mistaken jargon caused by never having done this sort
Robert> of thing before. Indeed all I needed to do was find the appropriate
Robert> tar.gz on the Web site that somebody else showed me, click on it,
Robert> confirm download, gunzip, then spend a half hour studying the 'man
Robert> tar' pages and doing guesswork before I finally figured out the
Robert> correct tar command for unpacking it all from the tar file on the
Robert> disk. ('man tar' doesn't show any example of this **common** type
Robert> of task that needs to be done.)
Oops. I guess the installation instructions should say something
about that so you don't have to figure it out yourself.
Robert> There isn't any 20a build available for FreeBSD 7.1, only for
Robert> FreeBSD 8.0, and it's my understanding the two aren't compatible.
If you ask on the mailing list, you might be able to convince someone
to do a 7.1 build. But remember, we're all volunteers, so maybe no
one has a 7.1 system around anymore.
Robert> Because I have no idea how to use LDB to look at the innerds of
Robert> CMUCL, and nobody in this thread has told me any LDB commands that
Robert> would provide the information needed. The only reasonable clue
You've covered most of the ones I would use: back and print.
Robert> so-far is that FreeBSD 7.1 introduces new types of signals for page
Robert> faults, which CMUCL doesn't yet know how to handle, so these
Robert> page-fault signals cause CMUCL to crash utterly with PRIMITIVE HALT
Robert> which is then intercepted by LDB somehow.
PRIMITIVE HALT calls ldb. But if you are getting new signals for page
faults, you should be able to get gdb to catch those. Then we can
make some progress. Just run cmucl (lisp) under gdb and when those
new signals happen, gdb should stop and we can look around to see
what's going on.
>> If the code isn't too bug, perhaps you can send it so I can try
>> to reproduce the bug.
Robert> It's a large application that keeps track of usernames and
Robert> passwords on Yahoo and performs automatic login by using
Robert> ext:run-program to control lynx as a sub-process and scrapes the
Robert> output from lynx using fuzzy string comparison to decide what it is
Robert> "seeing" from lynx to decide whether the previous lynx command
Robert> worked and what state lynx is in now so that the next lynx command
Robert> can be chosen appropriately. I've spent several years developing
Robert> this software, so I'm not going to just give over my code to a
Robert> stranger, and the application involves confidential usernames and
Robert> passwords so I'm not going to give any stranger the information
Robert> needed to log into my Yahoo accounts to verify the program crashes
Robert> and diagnose what is causing it.
I wasn't planning on stealing anything, but, in any case, I'm not too
motivated to debug some huge application on a system that I don't
have. :-)
>> Sorry, but the only archive I know of is the mailing lists.
Robert> Is there a search engine for the archive?
Google can search the gmane archives. The gmane archive isn't
complete, though. I have my own copy that goes back farther. I'll
see if there's anything about FreeBSD....
Ray
Madhu
* (Robert Maas) <REM-2009...@Yahoo.Com> :
Wrote on Tue, 06 Oct 2009 11:47:09 -0700:
|> Date: Thu, 08 May 2008 19:32:55 +0530
|> Message-ID: <m3hcd8u...@meer.net>
|> Subject: Re: Stupidity in CMUCL prettyprinter
|
| Unfortunately that article isn't accessible via Google Groups, and
| it's probably much too old to still be in the NNTP cache, but
| taking a shot in the dark:
Much as I absolutely hate using that accursed service, I checked, and
the article is indeed available. [Of course with that company YMMV
depending on where your IP is and what they decide you can see.]
curl --get -d as_ugroup=comp.lang.lisp -d as_umsgid="m3hcd8u...@meer.net" http://groups.google.com/groups
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://groups.google.com/group/comp.lang.lisp/msg/121a3c9465625c77">here</A>.
</BODY></HTML>
| My guess is that they fixed the sleep-twice-as-long bug and thereby
| introduced the sleep-not-at-all bug but failed to test on FreeBSD so
| the new bug made it out to the version of CMUCL that my old shell
| account was using until somebody finally *really* fixed it correctly
| sometime before 19c which is installed on new shell machine.
No, such speculation is unwarranted. The change was in Sep 1998 and the
version of CMUCL 18 you were using was built prior to that change. AFAIK
the SLEEP code has not changed since that commit.
My copy of the CMUCL sources (from July 2008, pre 20a) indicate the
following change
Author: pw <pw>
Date: Sat Sep 26 18:24:42 1998 +0000
index 2b23519..cd4aa11 100644
@@ -453,13 +453,12 @@
Must be a non-negative, non-complex number."
n))
(multiple-value-bind (sec usec)
- (if (integerp n)
- (values n 0)
- (values (truncate n)
- (truncate (* n 1000000))))
+ (if (integerp n)
+ (values n 0)
+ (multiple-value-bind (sec frac)(truncate n)
+ (values sec(truncate frac 1e-6))))
(unix:unix-select 0 0 0 0 sec usec))
nil)
| Anyway, no that's a *different* bug that was fixed.
| The bug I found: (sleep floatAtLeast1.0) => returns immediately
| The bug they fixed: (sleep floatGreaterThan1.0) => sleeps twice as much as correct
I believe the commit fixes the bug you observed
--
Madhu
Madhu
* Madhu <m38wfoy...@moon.robolove.meer.net> :
Wrote on Wed, 07 Oct 2009 03:43:40 +0530:
| * (Robert Maas) <REM-2009...@Yahoo.Com> :
| | My guess is that they fixed the sleep-twice-as-long bug and thereby
| | introduced the sleep-not-at-all bug but failed to test on FreeBSD so
| | the new bug made it out to the version of CMUCL that my old shell
| | account was using until somebody finally *really* fixed it correctly
| | sometime before 19c which is installed on new shell machine.
|
| No, such speculation is unwarranted.
I must qualify that. It is also conjecturable that you were seeing an MP
multi processing bug unrelated to the SLEEP code, and the bug did not
appear in later releases.
| The change was in Sep 1998 and the version of CMUCL 18 you were using
| was built prior to that change. AFAIK the SLEEP code has not changed
| since that commit.
|
| My copy of the CMUCL sources (from July 2008, pre 20a) indicate the
| following change
[snip]
| | Anyway, no that's a *different* bug that was fixed.
| | The bug I found: (sleep floatAtLeast1.0) => returns immediately
| | The bug they fixed: (sleep floatGreaterThan1.0) => sleeps twice as
| | much as correct
|
| I believe the commit fixes the bug you observed
I made that statement as there appeared to be no other changes to the
SLEEP code (either in code/lispinit.lisp, for without MP, or in
code/multi-proc.lisp with MP). I assume that your version of CMUCL was
built with MP on x86. [Myself I started using CMUCL seriously only
after the 19 release, and have never used fbsd]
--
Madhu
Robert Maas, http://tinyurl.com/uh3t
too long to each fit within a single 1k swap page, the second
garbage-collect causes a primitive halt:
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 7.1-PRERELEASE (SHELL0) #0: Mon Mar 23 03:17:26 PDT 2009
> lisp
CMU Common Lisp 19c Release (19C), running on shell0.rawbw.com
With core: /usr/local/lib/cmucl/lib/lisp.core
Dumped on: Wed, 2005-11-16 17:18:11-08:00 on snapdragon.csl.sri.com
See <http://www.cons.org/cmucl/> for support information.
Loaded subsystems:
Python 1.1, target Intel x86
CLOS based on Gerd's PCL 2004/04/14 03:32:47
*
(list
(length (setq g-bytes (loop for ix from 1 to 3000 collect (random 256))))
(setq g-strs (list))
(loop for ix from 1 to 2000 do
(length (setq g-str (map 'string #'code-char g-bytes)))
(setq g-len (length (push g-str g-strs)))
(when (zerop (mod g-len 30))
(format t " ~D " (length g-strs)) (finish-output) (sleep 0.05)))
(gc) (gc)
)
Warning: Declaring G-BYTES special.
Warning: Declaring G-STRS special.
;
; Warning: These variables are undefined:
; G-LEN G-STR
30 60 90 120 150 180 210 240 270 300 330 360 390 420 450 480 51
0 540 570 600 630 660 690 720 750 780 810 840 870 900 930 960 99
0 1020 1050 1080 1110 1140 1170 1200 1230 1260 1290 1320 1350 1380
1410 1440 1470 1500 1530 1560 1590 1620 1650 1680 1710 1740 1770 1
800 1830 1860 1890 1920 1950 1980 ; [GC threshold exceeded with 6,744,656
bytes in use. Commencing GC.]
; [GC completed with 6,140,952 bytes retained and 603,704 bytes freed.]
; [GC will next occur when at least 18,140,952 bytes are in use.]
; [GC threshold exceeded with 6,143,576 bytes in use. Commencing GC.]
Help! 12 nested errors. KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded.
Debug (type H for help)
(UNIX::SIGSEGV-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP #x28F0000B)
)
%primitive halt called; the party is over.
LDB monitor
ldb> quit
Really quit? [y] y
> /home/users/rem/Tmps/TmpCmucl/bin/lisp
CMU Common Lisp 19f (19F), running on shell0.rawbw.com
With core: /home/users/rem/Tmps/TmpCmucl/lib/cmucl/lib/lisp-sse2.core
Dumped on: Tue, 2009-03-10 20:47:48-07:00 on daland
See <http://www.cons.org/cmucl/> for support information.
Loaded subsystems:
Python 1.1, target Intel x86
CLOS based on Gerd's PCL 2008-11-12 16:36:41
*
(list
(length (setq g-bytes (loop for ix from 1 to 3000 collect (random 256))))
(setq g-strs (list))
(loop for ix from 1 to 2000 do
(length (setq g-str (map 'string #'code-char g-bytes)))
(setq g-len (length (push g-str g-strs)))
(when (zerop (mod g-len 30))
(format t " ~D " (length g-strs)) (finish-output) (sleep 0.05)))
(gc) (gc)
)
Warning: Declaring G-BYTES special.
Warning: Declaring G-STRS special.
;
; Warning: These variables are undefined:
; G-LEN G-STR
30 60 90 120 150 180 210 240 270 300 330 360 390 420 450 480 51
0 540 570 600 630 660 690 720 750 780 810 840 870 900 930 960 99
0 1020 1050 1080 1110 1140 1170 1200 1230 1260 1290 1320 1350 1380
1410 1440 1470 1500 1530 1560 1590 1620 1650 1680 1710 1740 1770 1
800 1830 1860 1890 1920 1950 1980 ; [GC threshold exceeded with 6,804,432
bytes in use. Commencing GC.]
; [GC completed with 6,146,288 bytes retained and 658,144 bytes freed.]
; [GC will next occur when at least 18,146,288 bytes are in use.]
; [GC threshold exceeded with 6,149,152 bytes in use. Commencing GC.]
Help! 12 nested errors. KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded.
Debug (type H for help)
(UNIX::SIGSEGV-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP #x47FE0500)
)
%primitive halt called; the party is over.
LDB monitor
ldb> quit
Really quit? [y] y
By comparison an older version of CMUCL running an older FreeBSD
completed the same script without crashing:
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 4.10-STABLE (SHELL) #0: Thu Feb 16 03:07:17 PST 2006
shell.rawbw.com% lisp
CMU Common Lisp 18b, running on shell.rawbw.com
Send questions and bug reports to your local CMU CL maintainer, or to cmucl-help
@cons.org. and cmuc...@cons.org. respectively.
Loaded subsystems:
Python 1.0, target Intel x86
CLOS based on PCL version: September 16 92 PCL (f)
*
(list
(length (setq g-bytes (loop for ix from 1 to 3000 collect (random 256))))
(setq g-strs (list))
(loop for ix from 1 to 2000 do
(length (setq g-str (map 'string #'code-char g-bytes)))
(setq g-len (length (push g-str g-strs)))
(when (zerop (mod g-len 30))
(format t " ~D " (length g-strs)) (finish-output) (sleep 0.05)))
(gc) (gc)
)
Warning: Declaring G-BYTES special.
Warning: Declaring G-STRS special.
Warning: These variables are undefined:
G-LEN G-STR
[GC threshold exceeded with 2,002,696 bytes in use. Commencing GC.]
[GC completed with 235,032 bytes retained and 1,767,664 bytes freed.]
[GC will next occur when at least 2,235,032 bytes are in use.]
30 60 [GC threshold exceeded with 2,242,792 bytes in use. Commencing GC.]
[GC completed with 348,896 bytes retained and 1,893,896 bytes freed.]
[GC will next occur when at least 2,348,896 bytes are in use.]
90 [GC threshold exceeded with 2,351,808 bytes in use. Commencing GC.]
[GC completed with 490,464 bytes retained and 1,861,344 bytes freed.]
[GC will next occur when at least 2,490,464 bytes are in use.]
120 [GC threshold exceeded with 2,497,200 bytes in use. Commencing GC.]
[GC completed with 602,168 bytes retained and 1,895,032 bytes freed.]
[GC will next occur when at least 2,602,168 bytes are in use.]
150 180 [GC threshold exceeded with 2,605,096 bytes in use. Commencing GC.]
[GC completed with 743,720 bytes retained and 1,861,376 bytes freed.]
[GC will next occur when at least 2,743,720 bytes are in use.]
210 [GC threshold exceeded with 2,746,328 bytes in use. Commencing GC.]
[GC completed with 873,928 bytes retained and 1,872,400 bytes freed.]
[GC will next occur when at least 2,873,928 bytes are in use.]
240 [GC threshold exceeded with 2,876,872 bytes in use. Commencing GC.]
[GC completed with 1,023,688 bytes retained and 1,853,184 bytes freed.]
[GC will next occur when at least 3,023,688 bytes are in use.]
270 300 [GC threshold exceeded with 3,030,424 bytes in use. Commencing GC.]
[GC completed with 1,134,224 bytes retained and 1,896,200 bytes freed.]
[GC will next occur when at least 3,134,224 bytes are in use.]
330 [GC threshold exceeded with 3,137,168 bytes in use. Commencing GC.]
[GC completed with 1,268,672 bytes retained and 1,868,496 bytes freed.]
[GC will next occur when at least 3,268,672 bytes are in use.]
360 [GC threshold exceeded with 3,271,320 bytes in use. Commencing GC.]
[GC completed with 1,385,544 bytes retained and 1,885,776 bytes freed.]
[GC will next occur when at least 3,385,544 bytes are in use.]
390 420 [GC threshold exceeded with 3,392,584 bytes in use. Commencing GC.]
[GC completed with 1,530,128 bytes retained and 1,862,456 bytes freed.]
[GC will next occur when at least 3,530,128 bytes are in use.]
450 [GC threshold exceeded with 3,532,768 bytes in use. Commencing GC.]
[GC completed with 1,647,768 bytes retained and 1,885,000 bytes freed.]
[GC will next occur when at least 3,647,768 bytes are in use.]
480 [GC threshold exceeded with 3,650,712 bytes in use. Commencing GC.]
[GC completed with 1,786,328 bytes retained and 1,864,384 bytes freed.]
[GC will next occur when at least 3,786,328 bytes are in use.]
510 [GC threshold exceeded with 3,793,056 bytes in use. Commencing GC.]
[GC completed with 1,904,280 bytes retained and 1,888,776 bytes freed.]
[GC will next occur when at least 3,904,280 bytes are in use.]
540 570 [GC threshold exceeded with 3,911,320 bytes in use. Commencing GC.]
[GC completed with 2,040,968 bytes retained and 1,870,352 bytes freed.]
[GC will next occur when at least 4,040,968 bytes are in use.]
600 [GC threshold exceeded with 4,042,832 bytes in use. Commencing GC.]
[GC completed with 2,001,656 bytes retained and 2,041,176 bytes freed.]
[GC will next occur when at least 4,001,656 bytes are in use.]
630 [GC threshold exceeded with 4,003,520 bytes in use. Commencing GC.]
[GC completed with 2,140,216 bytes retained and 1,863,304 bytes freed.]
[GC will next occur when at least 4,140,216 bytes are in use.]
660 690 [GC threshold exceeded with 4,142,848 bytes in use. Commencing GC.]
[GC completed with 2,266,344 bytes retained and 1,876,504 bytes freed.]
[GC will next occur when at least 4,266,344 bytes are in use.]
720 [GC threshold exceeded with 4,273,384 bytes in use. Commencing GC.]
[GC completed with 2,407,920 bytes retained and 1,865,464 bytes freed.]
[GC will next occur when at least 4,407,920 bytes are in use.]
750 [GC threshold exceeded with 4,410,552 bytes in use. Commencing GC.]
[GC completed with 2,534,056 bytes retained and 1,876,496 bytes freed.]
[GC will next occur when at least 4,534,056 bytes are in use.]
780 810 [GC threshold exceeded with 4,541,096 bytes in use. Commencing GC.]
[GC completed with 2,680,808 bytes retained and 1,860,288 bytes freed.]
[GC will next occur when at least 4,680,808 bytes are in use.]
840 [GC threshold exceeded with 4,683,432 bytes in use. Commencing GC.]
[GC completed with 2,785,368 bytes retained and 1,898,064 bytes freed.]
[GC will next occur when at least 4,785,368 bytes are in use.]
870 [GC threshold exceeded with 4,792,376 bytes in use. Commencing GC.]
[GC completed with 2,932,080 bytes retained and 1,860,296 bytes freed.]
[GC will next occur when at least 4,932,080 bytes are in use.]
900 930 [GC threshold exceeded with 4,934,720 bytes in use. Commencing GC.]
[GC completed with 3,040,488 bytes retained and 1,894,232 bytes freed.]
[GC will next occur when at least 5,040,488 bytes are in use.]
960 [GC threshold exceeded with 5,047,528 bytes in use. Commencing GC.]
[GC completed with 3,187,240 bytes retained and 1,860,288 bytes freed.]
[GC will next occur when at least 5,187,240 bytes are in use.]
990 [GC threshold exceeded with 5,193,968 bytes in use. Commencing GC.]
[GC completed with 3,294,824 bytes retained and 1,899,144 bytes freed.]
[GC will next occur when at least 5,294,824 bytes are in use.]
1020 [GC threshold exceeded with 5,301,864 bytes in use. Commencing GC.]
[GC completed with 3,432,296 bytes retained and 1,869,568 bytes freed.]
[GC will next occur when at least 5,432,296 bytes are in use.]
1050 1080 [GC threshold exceeded with 5,434,936 bytes in use. Commencing GC.]
[GC completed with 3,546,920 bytes retained and 1,888,016 bytes freed.]
[GC will next occur when at least 5,546,920 bytes are in use.]
1110 [GC threshold exceeded with 5,549,864 bytes in use. Commencing GC.]
[GC completed with 3,696,680 bytes retained and 1,853,184 bytes freed.]
[GC will next occur when at least 5,696,680 bytes are in use.]
1140 [GC threshold exceeded with 5,703,408 bytes in use. Commencing GC.]
[GC completed with 3,807,512 bytes retained and 1,895,896 bytes freed.]
[GC will next occur when at least 5,807,512 bytes are in use.]
1170 1200 [GC threshold exceeded with 5,810,456 bytes in use. Commencing GC.]
[GC completed with 3,946,064 bytes retained and 1,864,392 bytes freed.]
[GC will next occur when at least 5,946,064 bytes are in use.]
1230 [GC threshold exceeded with 5,948,704 bytes in use. Commencing GC.]
[GC completed with 3,896,920 bytes retained and 2,051,784 bytes freed.]
[GC will next occur when at least 5,896,920 bytes are in use.]
1260 [GC threshold exceeded with 5,903,928 bytes in use. Commencing GC.]
[GC completed with 4,035,480 bytes retained and 1,868,448 bytes freed.]
[GC will next occur when at least 6,035,480 bytes are in use.]
1290 1320 [GC threshold exceeded with 6,038,112 bytes in use. Commencing GC.]
[GC completed with 4,156,712 bytes retained and 1,881,400 bytes freed.]
[GC will next occur when at least 6,156,712 bytes are in use.]
1350 [GC threshold exceeded with 6,163,720 bytes in use. Commencing GC.]
[GC completed with 4,306,488 bytes retained and 1,857,232 bytes freed.]
[GC will next occur when at least 6,306,488 bytes are in use.]
1380 [GC threshold exceeded with 6,309,112 bytes in use. Commencing GC.]
[GC completed with 4,416,224 bytes retained and 1,892,888 bytes freed.]
[GC will next occur when at least 6,416,224 bytes are in use.]
1410 1440 [GC threshold exceeded with 6,418,088 bytes in use. Commencing GC.]
[GC completed with 4,547,456 bytes retained and 1,870,632 bytes freed.]
[GC will next occur when at least 6,547,456 bytes are in use.]
1470 [GC threshold exceeded with 6,549,320 bytes in use. Commencing GC.]
[GC completed with 4,678,432 bytes retained and 1,870,888 bytes freed.]
[GC will next occur when at least 6,678,432 bytes are in use.]
1500 [GC threshold exceeded with 6,685,464 bytes in use. Commencing GC.]
[GC completed with 4,817,000 bytes retained and 1,868,464 bytes freed.]
[GC will next occur when at least 6,817,000 bytes are in use.]
1530 [GC threshold exceeded with 6,819,624 bytes in use. Commencing GC.]
[GC completed with 4,934,920 bytes retained and 1,884,704 bytes freed.]
[GC will next occur when at least 6,934,920 bytes are in use.]
1560 1590 [GC threshold exceeded with 6,941,960 bytes in use. Commencing GC.]
[GC completed with 5,077,568 bytes retained and 1,864,392 bytes freed.]
[GC will next occur when at least 7,077,568 bytes are in use.]
1620 [GC threshold exceeded with 7,080,208 bytes in use. Commencing GC.]
[GC completed with 5,190,248 bytes retained and 1,889,960 bytes freed.]
[GC will next occur when at least 7,190,248 bytes are in use.]
1650 [GC threshold exceeded with 7,197,288 bytes in use. Commencing GC.]
[GC completed with 5,331,808 bytes retained and 1,865,480 bytes freed.]
[GC will next occur when at least 7,331,808 bytes are in use.]
1680 1710 [GC threshold exceeded with 7,334,456 bytes in use. Commencing GC.]
[GC completed with 5,453,552 bytes retained and 1,880,904 bytes freed.]
[GC will next occur when at least 7,453,552 bytes are in use.]
1740 [GC threshold exceeded with 7,460,592 bytes in use. Commencing GC.]
[GC completed with 5,599,368 bytes retained and 1,861,224 bytes freed.]
[GC will next occur when at least 7,599,368 bytes are in use.]
1770 [GC threshold exceeded with 7,606,096 bytes in use. Commencing GC.]
[GC completed with 5,718,248 bytes retained and 1,887,848 bytes freed.]
[GC will next occur when at least 7,718,248 bytes are in use.]
1800 1830 [GC threshold exceeded with 7,721,184 bytes in use. Commencing GC.]
[GC completed with 5,864,984 bytes retained and 1,856,200 bytes freed.]
[GC will next occur when at least 7,864,984 bytes are in use.]
1860 [GC threshold exceeded with 7,871,720 bytes in use. Commencing GC.]
[GC completed with 5,813,584 bytes retained and 2,058,136 bytes freed.]
[GC will next occur when at least 7,813,584 bytes are in use.]
1890 [GC threshold exceeded with 7,820,624 bytes in use. Commencing GC.]
[GC completed with 5,963,352 bytes retained and 1,857,272 bytes freed.]
[GC will next occur when at least 7,963,352 bytes are in use.]
1920 [GC threshold exceeded with 7,970,080 bytes in use. Commencing GC.]
[GC completed with 6,070,080 bytes retained and 1,900,000 bytes freed.]
[GC will next occur when at least 8,070,080 bytes are in use.]
1950 1980 [GC threshold exceeded with 8,077,120 bytes in use. Commencing GC.]
[GC completed with 6,219,840 bytes retained and 1,857,280 bytes freed.]
[GC will next occur when at least 8,219,840 bytes are in use.]
[GC threshold exceeded with 6,780,968 bytes in use. Commencing GC.]
[GC completed with 6,237,832 bytes retained and 543,136 bytes freed.]
[GC will next occur when at least 8,237,832 bytes are in use.]
[GC threshold exceeded with 6,237,832 bytes in use. Commencing GC.]
[GC completed with 6,242,440 bytes retained and -4,608 bytes freed.]
[GC will next occur when at least 8,242,440 bytes are in use.]
(3000 NIL NIL NIL NIL)
*
Madhu
Wrote on Wed, 07 Oct 2009 04:21:26 +0530:
| I must qualify that. It is also conjecturable that you were seeing an MP
| multi processing bug unrelated to the SLEEP code, and the bug did not
| appear in later releases.
BTW when I replied last year, I had noticed this commit, but assumed it
had found its way into your copy of CMUCL. But I realize I do not know
what sourcedate your copy of 18b contains. This commit may possibly
satisfy your curiosity better
,---- code/multi-proc.lisp
| revision 1.17
| date: 1998-01-03 08:48:57 +0530; author: dtc; state: Exp; lines: +16 -14;
| Allow a float timeout for process-wait-with-timeout.
`----
(initial-function nil :type (or null function))
(initial-args nil :type list)
(wait-function nil :type (or null function))
- (wait-timeout nil :type (or null fixnum))
+ ;; The real time after which the wait will timeout.
+ (wait-timeout nil :type (or null double-float))
(wait-return-value nil :type t)
--
Madhu
shouldve known better
Robert Maas, http://tinyurl.com/uh3t
> trying SBCL.
On your suggestion there, I tried it. It doesn't work at all,
refuses to even start up. I suggest you contact the person in
charge of making the distribution tar and get it fixed.
Download Options (Lynx Version 2.8.6rel.5), help
Downloaded link: http://softlayer.dl.sourceforge.net/project/sbcl/sbcl/1.0.23/sb
cl-1.0.23-x86-freebsd-binary.tar.bz2
Suggested file name: sbcl-1.0.23-x86-freebsd-binary.tar.bz2
Standard download options:
Save to disk
So I did that, ungzipped it, untarred it, yielding:
31514 -rw------- 1 rem user 32147968 Oct 6 16:51 sbcl-1.0.23-x86-freebsd-binary.tar
2 drwx------ 6 rem user 18 Oct 6 17:19 sbcl-1.0.23-x86-freebsd/
> du -d 1
32220 ./sbcl-1.0.23-x86-freebsd
> cd sbcl-1.0.23-x86-freebsd
> ls
total 532
79 BUGS 4 SUPPORT 1 pubring.pgp
2 COPYING 2 contrib/ 2 run-sbcl.sh
33 CREDITS 2 doc/ 1 sbcl-pwd.sh
10 INSTALL 2 find-gnumake.sh 2 src/
387 NEWS 5 install.sh
3 README 2 output/
> more README
..
If you'd like to install or build the system, see the "INSTALL" file.
> more INSTALL
..
To run SBCL without installing it, from the top of binary distribution
directory:
$ sh run-sbcl.sh
> sh run-sbcl.sh
(running SBCL from: .)
/libexec/ld-elf.so.1: Shared object "libm.so.4" not found, required by "sbcl"
Robert Swindells
This code works fine in 19f on NetBSD, both interpreted and compiled.
The interpreted version:
CMU Common Lisp 19f (19F), running on ren.fdy2.net
With core: /u10/lisp/cmucl/lib/lisp-x87.core
Dumped on: Sun, 2009-08-30 22:16:19+01:00 on eeepc.fdy2.net
See <http://www.cons.org/cmucl/> for support information.
Loaded subsystems:
Python 1.1, target Intel x86
CLOS based on Gerd's PCL 2008-11-12 16:36:41
* (load "maas.lisp")
; Loading #P"/u10/lisp/cmucl/maas.lisp".
Warning: Declaring G-BYTES special.
Warning: Declaring G-STRS special.
;
; Warning: These variables are undefined:
; G-LEN G-STR
30 60 90 120 150 180 210 240 270 300 330 360 390 420 450 480 510 540 570 600 630 660 690 720 750 780 810 840 870 900 930 960 990 1020 1050 1080 1110 1140 1170 1200 1230 1260 1290 1320 1350 1380 1410 1440 1470 1500 1530 1560 1590 1620 1650 1680 1710 1740 1770 1800 1830 1860 1890 1920 1950 1980 ; [GC threshold exceeded with 6,783,008 bytes in use. Commencing GC.]
; [GC completed with 6,146,792 bytes retained and 636,216 bytes freed.]
; [GC will next occur when at least 18,146,792 bytes are in use.]
; [GC threshold exceeded with 6,149,656 bytes in use. Commencing GC.]
; [GC completed with 6,148,248 bytes retained and 1,408 bytes freed.]
; [GC will next occur when at least 18,148,248 bytes are in use.]
;
T
Have you got anything in a CMUCL init file ?
Robert Maas, http://tinyurl.com/uh3t
> Oops. I guess the installation instructions should say something
> about that so you don't have to figure it out yourself.
Actually given that a very large number of distributions over the
Web nowadays use tar files, I think 'man tar' should use this as an
example. Sure anybody who uses tar on a regular basis would "just
know" that "tar -xf whatever.tar" will do the trick, but 'man tar'
should include that in the examples section, IMO.
> You've covered most of the ones I would use: back and print.
From the quick crash I posted a couple hours ago:
ldb> back
Backtrace:
0: Foreign fp = 0x47fd75b8, ra = 0x804cfc3
1: Foreign fp = 0x47fd76f8, ra = 0x804d202
2: Foreign fp = 0x47fd7748, ra = 0x804d251
3: Foreign fp = 0x47fd7758, ra = 0x804e424
4: Foreign fp = 0x47fd77f8, ra = 0x80523d9
5: Foreign fp = 0x47fd79c8, ra = 0xffffefd4
6: COMMON-LISP::ERROR
7: UNIX::SIGSEGV-HANDLER
8: UNIX::SIGSEGV-HANDLER
9: Foreign fp = 0x47fd7aa8, ra = 0x80526bc
10: Foreign fp = 0x47fd7ad8, ra = 0x8052523
11: Foreign fp = 0x47fd7b08, ra = 0x804f2ab
12: Foreign fp = 0x47fd7b28, ra = 0x8052c23
13: Foreign fp = 0x47fd7cfc, ra = 0xffffefd4
14: COMMON-LISP::ERROR
15: DEBUG::GET-FILE-TOP-LEVEL-FORM
16: DEBUG::GET-TOP-LEVEL-FORM
17: DEBUG::PRINT-CODE-LOCATION-SOURCE-FORM
18: DEBUG::PRINT-FRAME-CALL
19: DEBUG::DEBUG-LOOP
20: DEBUG::INTERNAL-DEBUG
21: "DEFUN ERROR-ERROR"
22: LISP::%WITH-STANDARD-IO-SYNTAX
23: KERNEL::ERROR-ERROR
24: COMMON-LISP::ERROR
25: UNIX::SIGBUS-HANDLER
26: UNIX::SIGBUS-HANDLER
ldb> print
Expected an object.
ldb>
> PRIMITIVE HALT calls ldb. But if you are getting new signals for page
> faults, you should be able to get gdb to catch those.
I never heard of 'gdb' before. (I never heard of LDB either until
CMUCL crashed into it.)
> Then we can make some progress. Just run cmucl (lisp) under gdb
> and when those new signals happen, gdb should stop and we can look
> around to see what's going on.
Can you walk me through how to get CMUCL running under gdb, and
then after the signal-intercept happens, what command to give to
gdb to print out the information you need?
> I wasn't planning on stealing anything, but, in any case, I'm not
> too motivated to debug some huge application on a system that I
> don't have. :-)
Then you should appreciate the ten-line crash I posted a couple hours ago:
<news:REM-2009...@Yahoo.Com>
By the way, I think my ISP:
<http://www.RawBandwidth.com/services/res.html>
allows trial accounts for free:
Try our Personal PPP account FREE for 2 weeks with no strings attached.
We don't even take your credit card number!
so if you don't have any other access to FreeBSD 7.1 and you can't
afford any of:
Personal PPP/Shell (extra Web space and CGI), $25.95/mo.
Network Shell (no dialup), $15.00/mo.
Personal Shell (terminal dialup), $19.95/mo. (what I have)
you might ask for a free trial account. 2 weeks should be plenty
long for a CMUCL/internals/FreeBSD expert to diagnose this problem
and get ideas towards a fix.
Robert Maas, http://tinyurl.com/uh3t
> This code works fine in 19f on NetBSD, both interpreted and compiled.
Does NetBSD derive directly from FreeBSD 7.1, which has the new
page-fault signals strongly suspected of causing the primitive
halt, or does it derive from a later version of FreeBSD where the
signals might have reverted to the old signals, or does it derive
from an earlier version of FreeBSD (or from something unrelated to
FreeBSD) which pre-date the trouble-causing new signals? Only if it
derives directly from FreeBSD 7.1 would it be directly relevant to
this problem, except to bracket the problem to show it happens
*only* with FreeBSD 7.1 and not with other unrelated *nixes.
> * (load "maas.lisp")
You don't show the source for mass.lisp, is it exactly what I posted earlier?
> ...
> T
It's not producing the correct return value to the REP.
With my test code:
(list
(length (setq g-bytes (loop for ix from 1 to 3000 collect (random 256))))
(setq g-strs (list))
(loop for ix from 1 to 2000 do
(length (setq g-str (map 'string #'code-char g-bytes)))
(setq g-len (length (push g-str g-strs)))
(when (zerop (mod g-len 30))
(format t " ~D " (length g-strs)) (finish-output) (sleep 0.05)))
(gc) (gc)
)
The correct return value should be:
(3000 NIL NIL NIL NIL)
Apparently your call to (load ...) discards the return value.
> Have you got anything in a CMUCL init file ?
Nope. I switch from one major project to another on a frequent
basis, and like to have control of all my init stuff within source
that I copy from local text file and paste across modem to REP, so
that nothing left over from a previous project will screw up the
current project. Occasionally I want to set up a quick-to-invoke
demo, so then I put the toplevel script in some other
something.lisp file and copy+paste (load "something.lisp") across
the dialup VT100 link to run the demo.
Do you have access to FreeBSD 7.1 where you are, or do you have
time to apply for a two-week free trial of shell account on
RawBandwidth.com so that you can run on the very same system I'm
running on?
Robert Maas, http://tinyurl.com/uh3t
CMU Common Lisp 19c Release (19C), running on shell0.rawbw.com
With core: /usr/local/lib/cmucl/lib/lisp.core
Dumped on: Wed, 2005-11-16 17:18:11-08:00 on snapdragon.csl.sri.com
See <http://www.cons.org/cmucl/> for support information.
Loaded subsystems:
Python 1.1, target Intel x86
CLOS based on Gerd's PCL 2004/04/14 03:32:47
; [GC threshold exceeded with 85,800 bytes in use. Commencing GC.]
; [GC completed with 19,824 bytes retained and 65,976 bytes freed.]
; [GC will next occur when at least 12,019,824 bytes are in use.]
NIL
* (gc)
; [GC threshold exceeded with 23,792 bytes in use. Commencing GC.]
Help! 12 nested errors. KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded.
Debug (type H for help)
(UNIX::SIGSEGV-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP #x28F0000B)
)
%primitive halt called; the party is over.
LDB monitor
ldb> quit
Really quit? [y] y
> /home/users/rem/Tmps/TmpCmucl/bin/lisp
CMU Common Lisp 19f (19F), running on shell0.rawbw.com
With core: /home/users/rem/Tmps/TmpCmucl/lib/cmucl/lib/lisp-sse2.core
Dumped on: Tue, 2009-03-10 20:47:48-07:00 on daland
See <http://www.cons.org/cmucl/> for support information.
Loaded subsystems:
Python 1.1, target Intel x86
CLOS based on Gerd's PCL 2008-11-12 16:36:41
* (gc)
; [GC threshold exceeded with 138,696 bytes in use. Commencing GC.]
; [GC completed with 20,280 bytes retained and 118,416 bytes freed.]
; [GC will next occur when at least 12,020,280 bytes are in use.]
NIL
* (gc)
; [GC threshold exceeded with 24,552 bytes in use. Commencing GC.]
Tamas K Papp
wrote:
> (UNIX::SIGSEGV-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP
> #x47FE0500) )
> %primitive halt called; the party is over. LDB monitor
> ldb> quit
> Really quit? [y] y
>>
Good for you. Now please try to discuss this on the CMUCL mailing
lists instead:
http://www.cons.org/cmucl/support.html
That way, your problem might be resolved more quickly.
HTH,
Tamas
Raymond Toy
>> You've covered most of the ones I would use: back and print.
Robert> From the quick crash I posted a couple hours ago:
ldb> back
Robert> Backtrace:
Robert> 0: Foreign fp = 0x47fd75b8, ra = 0x804cfc3
Robert> 1: Foreign fp = 0x47fd76f8, ra = 0x804d202
Robert> 2: Foreign fp = 0x47fd7748, ra = 0x804d251
Robert> 3: Foreign fp = 0x47fd7758, ra = 0x804e424
Robert> 4: Foreign fp = 0x47fd77f8, ra = 0x80523d9
Robert> 5: Foreign fp = 0x47fd79c8, ra = 0xffffefd4
Robert> 6: COMMON-LISP::ERROR
Robert> 7: UNIX::SIGSEGV-HANDLER
Robert> 8: UNIX::SIGSEGV-HANDLER
Robert> 9: Foreign fp = 0x47fd7aa8, ra = 0x80526bc
Robert> 10: Foreign fp = 0x47fd7ad8, ra = 0x8052523
Robert> 11: Foreign fp = 0x47fd7b08, ra = 0x804f2ab
Robert> 12: Foreign fp = 0x47fd7b28, ra = 0x8052c23
Robert> 13: Foreign fp = 0x47fd7cfc, ra = 0xffffefd4
Robert> 14: COMMON-LISP::ERROR
Robert> 15: DEBUG::GET-FILE-TOP-LEVEL-FORM
Robert> 16: DEBUG::GET-TOP-LEVEL-FORM
Robert> 17: DEBUG::PRINT-CODE-LOCATION-SOURCE-FORM
Robert> 18: DEBUG::PRINT-FRAME-CALL
Robert> 19: DEBUG::DEBUG-LOOP
Robert> 20: DEBUG::INTERNAL-DEBUG
Robert> 21: "DEFUN ERROR-ERROR"
Robert> 22: LISP::%WITH-STANDARD-IO-SYNTAX
Robert> 23: KERNEL::ERROR-ERROR
Robert> 24: COMMON-LISP::ERROR
Robert> 25: UNIX::SIGBUS-HANDLER
Robert> 26: UNIX::SIGBUS-HANDLER
ldb> print
Robert> Expected an object.
Yeah, there's nothing there to really print out. And if the last
output is 26: UNIX::SIGBUS-HANDLER, it sounds like something has
pretty badly trashed the stack so you can't go any further. (Or maybe
try back 100, just in case).
Robert> I never heard of 'gdb' before. (I never heard of LDB either until
Robert> CMUCL crashed into it.)
>> Then we can make some progress. Just run cmucl (lisp) under gdb
>> and when those new signals happen, gdb should stop and we can look
>> around to see what's going on.
Robert> Can you walk me through how to get CMUCL running under gdb, and
Robert> then after the signal-intercept happens, what command to give to
Robert> gdb to print out the information you need?
gdb <bin/lisp>
run
You'll get the regular repl. But the first time you GC or allocate
something, you'll probably get dumped back to gdb because a signal.
At this point, you're going need to have the sources installed
somewhere. And you'll also have to dig through FreeBSD stuff to find
out what signals are generated. From FreeBSD-os.h I see:
#if __FreeBSD_version < 700004
#define PROTECTION_VIOLATION_SIGNAL SIGBUS
#define PROTECTION_VIOLATION_CODE BUS_PAGE_FAULT
#else
#define PROTECTION_VIOLATION_SIGNAL SIGSEGV
#define PROTECTION_VIOLATION_CODE SEGV_ACCERR
#endif
So with FreeBSD_version 700004 (whatever that corresponds to), the
actual signal and code changed. Perhaps this is the problem.
I'm sorry, but you'll have to do some digging on your own. I can give
some hints and suggestions, but I don't know anything about FreeBSD.
Ray
Robert Maas, http://tinyurl.com/uh3t
> lists instead:
I can't do that because I don't have access to any e-mail system
that is suitable for dealing with a mailing list. Yahoo! Mail gets
flooded with hundreds of spam per day, and hasn't even basically
worked for over a year. SpamGourmet doesn't work for outgoing
e-mail, and allows at most 20 incoming e-mail per address-variant
before it silently discards all further e-mail to that same
address. I have a Web-based outgoing-e-mail service I wrote myself
in late 2002 or early 2003 which worked fine on the old shell
account, and since 1.5 years ago it has faked my SpamGourmet
address in the From field, but it runs in CMUCL and consequently
hasn't worked for any but the very shortest messages since my
account was moved to FreeBSD 7.1.
Tamas K Papp
wrote:
>> From: Tamas K Papp <tkp...@gmail.com> Good for you. Now please try to
>> discuss this on the CMUCL mailing lists instead:
>
> I can't do that because I don't have access to any e-mail system that is
> suitable for dealing with a mailing list. Yahoo! Mail gets flooded with
Oops, sorry, I forgot that you always find an excuse for not doing the
reasonable thing. Running lisp implementations on hardware
constraints that should not be binding anymore even on machines you
can get for free, not using any of the zillion free e-mail solutions
(Gmail comes to mind), etc. By the way, those mailing lists are
extremely low-traffic.
Clearly, you want to avoid programming Lisp at any cost.
Too bad that inventive people are making that difficult for you: for
example, you can access the CMUCL lists on Gmane using a newsreader.
However, I don't doubt that you will come up with another excuse on why
you can't do that (the newsreaders that run on your great-grandfather's
abacus can't connect to Gmane, etc).
Good luck,
Tamas
Petter Gustad
writes:
> I can't do that because I don't have access to any e-mail system
> that is suitable for dealing with a mailing list. Yahoo! Mail gets
I seem to remember you were using an UNIX shell account. You should be
able to use a curses based mail program, even connecting to gmail
using IMAP. Personally, I prefer Mew (www.mew.org) in Emacs as my
E-mail client.
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Pascal J. Bourguignon
> seeWeb...@rem.intarweb.org (Robert Maas, http://tinyurl.com/uh3t)
> writes:
>
>> I can't do that because I don't have access to any e-mail system
>> that is suitable for dealing with a mailing list. Yahoo! Mail gets
>
> I seem to remember you were using an UNIX shell account. You should be
> able to use a curses based mail program, even connecting to gmail
> using IMAP. Personally, I prefer Mew (www.mew.org) in Emacs as my
> E-mail client.
Or even just use GNUS as well for email as for news, so he may reduce
the set of his impossibilities...
--
__Pascal Bourguignon__
Raymond Toy
>> lisp
Robert> CMU Common Lisp 19c Release (19C), running on shell0.rawbw.com
Alex (who builds the FreeBSD binaries) mentioned to me that the 19c
binaries are probably built on FreeBSD5. So unless you have the
appropriate compability libraries/kernel you probably can't run
FreeBSD5 on FreeBSD7.
You should upgrade to 19f, which has FreeBSD 7.1 binaries. 19e has
7.0 binaries, and 20a has 7.2 binaries, but I don't know if they will
run on 7.1, though.
Ray
Thomas A. Russ
> > From: Raymond Toy <raymond....@stericsson.com>
> > Oops. I guess the installation instructions should say something
> > about that so you don't have to figure it out yourself.
>
> Actually given that a very large number of distributions over the
> Web nowadays use tar files, I think 'man tar' should use this as an
> example. Sure anybody who uses tar on a regular basis would "just
> know" that "tar -xf whatever.tar" will do the trick, but 'man tar'
> should include that in the examples section, IMO.
Well, at least when I look at "man tar" in mine, the item you seek (or
at least a close and perhaps more useful variant) is the first one of
the examples:
...
EXAMPLES
tar -xvf foo.tar
verbosely extract foo.tar
tar -xzf foo.tar.gz
extract gzipped foo.tar.gz
...
It gives a reasonable example of how to extract all of the files from
the tar archive. And the second example would be the next most common
thing I would expect you to do. But perhaps your man page is
different. Mine comes from Darwin/Mac OS X, but the authors of the man
page are affiliated with Debian Linux.
--
Thomas A. Russ, USC/Information Sciences Institute
Robert Maas, http://tinyurl.com/uh3t
> >> discuss this on the CMUCL mailing lists instead:
> > I can't do that because I don't have access to any e-mail system that is
> > suitable for dealing with a mailing list. Yahoo! Mail gets flooded with
> From: Tamas K Papp <tkp...@gmail.com>
> Oops, sorry, I forgot that you always find an excuse for not doing the
> reasonable thing.
You think it's reasonable to sign up for a mailing list, to ask for
help with a CMUCL problem, but then be unable to read most of the
responses I get back?
> running lisp implementations on hardware constraints that should
> not be binding anymore even on machines you can get for free,
I've been unable to find any free computer with working modem
around here. I have a free laptop computer running Linux, with
broken modem, or wedged drivers to modem, I don't know which, and
I'm unable to find anyone around here who is expert enough at Linux
to help me diagnose the problem. I have another free laptop
computer which won't even boot up, power-up causes it to display
"shutting down" message and sit there for about ten minutes before
it times out and does a cold power-off, and there's nobody around
here who knows how to make it boot up. I tried the FreeCycle group
in the local area, which operates on a Yahoo! Group, but there are
tons of requests for free computers and hardly ever a free computer
to give to one lucky person while the others go without.
> not using any of the zillion free e-mail solutions (Gmail comes
> to mind), etc.
I tried Gmail here. I can get the login cookies, but then I get a
blank screen, because it all requires JavaScript which isn't
available over VT100 term on Unix shell.
> By the way, those mailing lists are extremely low-traffic.
Thanks for the key info. I tried another of the help mailing lists
a couple years ago, and was flooded with hundreds of articles I
never had time to read, and after maybe a thousand unread articles
had accumulated and it was obvious I would never have time to catch
up, I terminated my membership. But if it's true that the CMUCL
developer's bug-reporting mailing list is very low volume, no more
than 10 articles per week, my SpamGourmet address could handle it.
> Clearly, you want to avoid programming Lisp at any cost.
Nope, you are totally wrong, although for quick-start high-volume
not-too-complicated Web services PHP has the advantage that it's
much faster to start up per transaction, and runs on free hosting
services. Typically a complete PHP transaction takes less than a
tenth of a second from start-script to end-script compared to a
much longer time just to run 'sh' script to interface to CMUCL
application, and have CMUCL application load all the needed code
modules (which is much faster if all the disk pages are still in
the RAM cache from previous CGI transaction, but still much slower
than PHP). For all compute-intensive applications, where start-up
cost is small compared to total compute time, as well as any
application that has key elements I don't yet know how to do in
PHP, I still prefer Lisp, if it doesn't crash into LDB monitor!!
BTW: This morning I got a new idea for avoiding the GC bug in CMUCL
on FreeBSD 7.1, namely (ext:gc-off), which I'm going to try as soon
as I finish catching up with this newsgroup thread. At the very end
of a major session I'll manually do (gc) to see how large the heap
had gotten while automatic-GC was disabled for the entire session.
If it's only a few hundred megabytes, that shouldn't other the
sysadmin too badly. Now that I'm using 'curl' instead of
fuzzy-string-matching output from 'lynx', I won't be using quite as
much temporary string space as before, so I'm hoping my total heap
usage with automatic-GC disabled will be reasonably not-too-gigantic.
> Too bad that inventive people are making that difficult for you:
> for example, you can access the CMUCL lists on Gmane using a
> newsreader.
I used to use 'rn' many years ago, and it was tolerable. But all
the ISPs deleted it in favor of 'trn' which is a piece of crap,
even when in 'rn' emulation mode. And now my current ISP has two
different NNTP servers, one for local groups and one for public
groups, and it takes about a half hour to re-build .newsrc every
time I switch from one to the other, which is intolerable, so I use
Google Groups for browsing public newsgroups and for trying to find
followups to stuff I previously posted (newsreaders do *not* have a
global search capability, finding all articles in all newsgroups
that mention 'uh3t', in reverse chronological order), and if I ever
want to browse the local newsgroups I manually TELNET to the local
NNTP server.
Petter Gustad
> I tried Gmail here. I can get the login cookies, but then I get a
> blank screen, because it all requires JavaScript which isn't
> available over VT100 term on Unix shell.
I was thinking of using a curses based program (like emacs -nw) to
access gmail (using IMAP). But I guess you have to use a web browser
to register in the first place...
John Thingstad
<newsma...@gustad.com>:
> seeWeb...@rem.intarweb.org (Robert Maas, http://tinyurl.com/uh3t)
> writes:
>
>> I tried Gmail here. I can get the login cookies, but then I get a
>> blank screen, because it all requires JavaScript which isn't
>> available over VT100 term on Unix shell.
>
> I was thinking of using a curses based program (like emacs -nw) to
> access gmail (using IMAP). But I guess you have to use a web browser
> to register in the first place...
>
> Petter
Well Lynx is text mode browser for Linux. Use that.
--------------
John Thingstad
Robert Maas, http://tinyurl.com/uh3t
(ext:gc-off) at the very top of my load-all-the-modules-I'll-need
script. Then I ran for several hours interactively, both developing
new code and making use of finished code, without any problems.
Finally when I was done for the session, I did:
* (gc)
; [GC threshold exceeded with 158,892,328 bytes in use. Commencing GC.]
; [GC completed with 4,770,608 bytes retained and 154,121,720 bytes freed.]
; [GC will next occur when at least 16,770,608 bytes are in use.]
NIL
* (gc)
; [GC threshold exceeded with 4,774,600 bytes in use. Commencing GC.]
Help! 12 nested errors. KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded.
Debug (type H for help)
%primitive halt called; the party is over.
LDB monitor
ldb> quit
Really quit? [y] y
>
Note that total bytes used and not reclaimed because automatic GC
was disabled was just over 150 megabytes, which really isn't a
large amount of wasted-VM nowadays, so it looks like disabling
automatic GC is a good-enough workaround until the
FreeBSD-7.1-page-fault-signal-crashes-GC bug realy gets fixed.
One caveat: Most of the several hours time spent today was actually
having PowerLisp on the Mac compute public-key crypto-message to
upload to Unix. Very little time was spent actually doing anything
on Unix (decrypting the message, whose payload was a user+password
pair, and ext:run-program 'curl' to perform Yahoo! Mail login to
verify I had actually uploaded the correct password). If I were
doing heavy computing on Unix the amount of heap consumed might be
much larger. Tonight or tomorrow I'll start working on more
elaborate ext:run-program 'curl' scripts that not just log in but
move around the logged-in hierarchy and download GeoCities
directory listings in HTML format and parse them and traverse them
and glean actual filenames from them etc., and then when I get that
code working well enough to download *all* my GeoCities directories
in one batch I'll see how much heap gets consumed with GC disabled,
both for the develop-new-code session that loads new lines of code
and then loads function definitions (bottom-up tool building), and
a pure already-working-tools session.
If these GC-disabled-workaround continue to be good-enough, this
may lend more credence to my idea of writing a really simple
version of Lisp within Forth without even bothering to write any
storage reclamation system until much later when we'd add a
reference-count system with lazy timeshared reclamation (each time
a unit of computing is done, such as a CONS allocation, it checks
if there is any unfinished reclamation to do, and if so it does
just a few steps in the reclamation process before returning to the
normal processing task, except if a CONS is requested but can't be
granted due to exhaustion of memory then it immediately performs as
much of the reclamation is needed to exactly satisfy the CONS
request, and increments the tuning number that tells how many
reclamation steps to perform after each regular compute task, but
whenever the reclamation task is all done it might decrement that
same tuning parameter, thus balancing the desire for speed during
normal operations when memory isn't short and reclamation can wait
until later with the desire to avoid pauses when it really does run
out memory due to too-lazy reclamation).
Rob Warnock
+---------------
| "Robert" == Robert Maas <seeWeb...@rem.intarweb.org> writes:
| >> lisp
| Robert> CMU Common Lisp 19c Release (19C), running on shell0.rawbw.com
|
| Alex (who builds the FreeBSD binaries) mentioned to me that the
| 19c binaries are probably built on FreeBSD5.
It was one of the last builds on FreeBSD-4.x, actually:
$ uname -nsr
FreeBSD a64.rpw3.org 6.2-RELEASE-p4
$ cmucl
CMU Common Lisp 19c Release (19C), running on a64.rpw3.org
With core: /u/rpw3/src/cmd/cmucl-19c/lib/cmucl/lib/lisp.core
Dumped on: Wed, 2005-11-16 17:18:11-08:00 on snapdragon.csl.sri.com
...[more chatter]...
* (lisp-implementation-version)
"19c Release (19C)"
* (remove "BSD" (mapcar #'symbol-name *features*) :test-not #'search)
("FREEBSD4" "FREEBSD" "BSD")
*
FWIW, 19c runs just fine on FreeBSD-6.2:
* (list (software-type) (software-version))
("FreeBSD" "6.2-RELEASE-p4")
*
but then, I have the "compat4x" libraries installed, which,
as Ray notes, you will also need on FreeBSD-7.1 as well in
order to run FreeBSD-4.x binaries such as CMUCL-19c.
Note: I also have the "lib32" libraries installed, since
"a64" is an Athlon64 machine:
$ ldd /usr/local/bin/cmucl
ldd: /usr/local/bin/cmucl: can't read program header
ldd: /usr/local/bin/cmucl: not a dynamic executable
$ ldd32 /usr/local/bin/cmucl
/usr/local/bin/cmucl:
libm.so.2 => /usr/local/lib32/compat/libm.so.2 (0x28092000)
libc.so.4 => /usr/local/lib32/compat/libc.so.4 (0x280ad000)
$
And "ldd32" [since FreeBSD doesn't provide it!] is just this tiny script:
#!/bin/sh
for i in ${1+"$@"}
do
echo "$i":
env LD_32_TRACE_LOADED_OBJECTS=1 "$i"
done
+---------------
| So unless you have the appropriate compability libraries/kernel
| you probably can't run FreeBSD5 on FreeBSD7.
+---------------
FreeBSD 4.x binaries on 7.x, but yes.
+---------------
| You should upgrade to 19f, which has FreeBSD 7.1 binaries.
+---------------
That would be easiest.
+---------------
| 19e has 7.0 binaries...
+---------------
Which with a bit of work *can* be made to run on FreeBSD-4... ;-} ;-}
but you have to hack up some of the dynamic library stuff [which
I did on my laptop so I could defer an O/S upgrade (*blush*)]:
$ uname -nsr
FreeBSD lisp.rpw3.org 4.10-RELEASE
$ ldd /usr/local/bin/cmucl
/usr/local/bin/cmucl:
libm.so.4 => /usr/local/lib/HACK_LINKS/libm.so.4 (0x2807e000)
libc.so.6 => /usr/local/lib/HACK_LINKS/libc.so.6 (0x28099000)
$ cd /usr/local/lib/HACK_LINKS
$ ls -l lib[mc].so.[46]
lrwxr-xr-x 1 root wheel 16 Oct 5 2008 libc.so.6 -> /usr/lib/libc.so
lrwxr-xr-x 1 root wheel 16 Oct 5 2008 libm.so.4 -> /usr/lib/libm.so
$ cmucl
CMU Common Lisp 19e (19E), running on lisp.rpw3.org
With core: /u/rpw3/src/cmd/cmucl-19e/lib/cmucl/lib/lisp.core
Dumped on: Sun, 2008-05-04 19:32:56-07:00 on rienzi
...[etc]...
* (lisp-implementation-version)
"19e (19E)"
* (remove "BSD" (mapcar #'symbol-name *features*) :test-not #'search)
("FREEBSD4" "FREEBSD" "BSD")
* (list (software-type) (software-version))
("FreeBSD" "4.10-RELEASE")
*
+---------------
| ...and 20a has 7.2 binaries, but I don't know if they will run
| on 7.1, though.
+---------------
Minor revs in FreeBSD usually don't break anything major. The
7.2 binaries should either "just work" on 7.1 or can probably
be made to work with the same sort of dynamic library renaming
hackery shown above.
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Pascal J. Bourguignon
>> >> From: Tamas K Papp <tkp...@gmail.com> Good for you. Now please try to
>> >> discuss this on the CMUCL mailing lists instead:
>> > I can't do that because I don't have access to any e-mail system that is
>> > suitable for dealing with a mailing list. Yahoo! Mail gets flooded with
>> From: Tamas K Papp <tkp...@gmail.com>
>> Oops, sorry, I forgot that you always find an excuse for not doing the
>> reasonable thing.
>
> You think it's reasonable to sign up for a mailing list, to ask for
> help with a CMUCL problem, but then be unable to read most of the
> responses I get back?
No. We think it's unreasonable not being able to read emails.
--
__Pascal Bourguignon__
Raymond Toy
Rob> Raymond Toy <raymo...@stericsson.com> wrote:
Rob> +---------------
Rob> | "Robert" == Robert Maas <seeWeb...@rem.intarweb.org> writes:
Rob> | >> lisp
Rob> | Robert> CMU Common Lisp 19c Release (19C), running on shell0.rawbw.com
Rob> |
Rob> | Alex (who builds the FreeBSD binaries) mentioned to me that the
Rob> | 19c binaries are probably built on FreeBSD5.
Rob> +---------------
Rob> It was one of the last builds on FreeBSD-4.x, actually:
Rob> $ uname -nsr
Rob> FreeBSD a64.rpw3.org 6.2-RELEASE-p4
Rob> $ cmucl
Rob> CMU Common Lisp 19c Release (19C), running on a64.rpw3.org
Rob> With core: /u/rpw3/src/cmd/cmucl-19c/lib/cmucl/lib/lisp.core
Rob> Dumped on: Wed, 2005-11-16 17:18:11-08:00 on snapdragon.csl.sri.com
Rob> ...[more chatter]...
Rob> * (lisp-implementation-version)
Rob> "19c Release (19C)"
Rob> * (remove "BSD" (mapcar #'symbol-name *features*) :test-not #'search)
Rob> ("FREEBSD4" "FREEBSD" "BSD")
Rob> *
Actually, I think FREEBSD4 is still a feature, even it it isn't true
anymore. Alex has fixed this, I think. Or will fix it soon. (Have
to dig through the logs to see if this was fixed.)
I think we're just going to get rid of FREEBSD4 completely.
Ray, who still happily runs SunOS 2.4 sparc binaries on a Solaris 10 box.
Petter Gustad
>> I was thinking of using a curses based program (like emacs -nw) to
>> access gmail (using IMAP). But I guess you have to use a web browser
>> to register in the first place...
>>
>> Petter
>
> Well Lynx is text mode browser for Linux. Use that.
I've never lynx or w3m (emacs-w3m) to work with gmail.
Petter Gustad
> "John Thingstad" <jpt...@online.no> writes:
>
>>> I was thinking of using a curses based program (like emacs -nw) to
>>> access gmail (using IMAP). But I guess you have to use a web browser
>>> to register in the first place...
>>>
>>> Petter
>>
>> Well Lynx is text mode browser for Linux. Use that.
>
> I've never lynx or w3m (emacs-w3m) to work with gmail.
Sorry, missed a word there:
I've never got lynx or w3m (emacs-w3m) to work with gmail.
vippstar
> Petter Gustad <newsmailco...@gustad.com> writes:
> > I've never lynx or w3m (emacs-w3m) to work with gmail.
>
> Sorry, missed a word there:
>
> I've never got lynx or w3m (emacs-w3m) to work with gmail.
Where?
Robert Maas, http://tinyurl.com/uh3t
> > help with a CMUCL problem, but then be unable to read most of the
> > responses I get back?
> No. We think it's unreasonable not being able to read emails.
How would you propose that I be able to read e-mail from a mailing
list that I've signed up for, given that all of the available
Web-based e-mail systems either (such as Gmail, HotMail, etc.)
require JavaScript, which isn't available on Unix terms, or (such
as Yahoo) are so flooded with spam that I wouldn't be able to find
any non-spam that I might get?
And given that I haven't been able to find any spam-filtering
multi-sub-address service that works in a reasonable manner of
SMTP-refusing or SMTP-temporary-refusing unwanted e-mail and
allowing me to set a threshold of more than 20 e-mail in a burst
before reaching the per-sub-address limit. (SpamGourmet doesn't
allow setting any per-address limit more than 20, and *discards*
instead of refuses any e-mail past the limit, making unsuitable for
reading a mailing list where more than one person might send e-mail
to be distributed so there's no way I an enforce senders to please
don't send more than the current limit before waiting for me to
tell them I've reset the count.)
And given that I haven't been able to find anyone willing to let me
use a free virtual Unix system whereby I'd be able to write my own
SMTP server that did the right thing regarding filtering incoming
e-mail. (One person *did* allow me an account on a shared machine
in the UK that didn't have an SMTP server and I had permission to
build my own, but then my login stopped working and I couldn't
reach him by e-mail and now DNS says there's no such host so that
system seems no longer an option for setting up my own SMTP
server.)
And given that I don't even have income sufficient to pay basic
living expenses, much less pay extra to lease a virtual host
somewhere on the net.
And given that I haven't been able to find a free laptop computer
that actually works in order to get on PPP, and I haven't been able
to find anyone to pay me to write software, or do any other kind of
useful work, such that I could pay basic living expenses and have
some extra money to *buy* a new laptop computer that could do PPP?
You have me between a rock and a hard place: On the one hand, you
say I should sign up for a mailing list, despite the fact that I
have no practical way to read e-mail from it. On the other hand,
you agree it would be unreasonable to sign up if I can't read
responses because I have no access to any suitable e-mail system.
Given my financial circumstances, do *you* personally offer any
proposed reasonable solution for me?
- Do you know of a free Web-based e-mail sub-address
filtering-forwarding service, like SpamGourmet, except unlike
SpamGourmet it does SMTP 4xy response instead of
accept-and-discard-silently when e-mail exceeds limit, and which
allows a per-sub-address limit to be set larger than 20?
- Do you plan to offer me a free virtual host running Unix (or
Linux etc.) shell, which doesn't have its any SMTP server yet,
where I would be allowed to write my own spam-filtering
registered-sender-only SMTP server and install it there?
- Do you plan to hire me to work for you, so that I can pay off
credit-card debt needed for covering basic living expenses since
1998 when basic living expenses began exceeding income, and with
debts paid off I'd have some money left over to buy a new
computer?
- Do you plan to provide me with free investigative and legal
services, to track down who is sending me spam, file lawsuits
against them for $1000 per spam under California law, formally
"serve" summons on the spammers, argue my case in court to get
judgements against the spammers, track down their regular
sources of income and all their assets such as homes they own,
get attachment-of-wages and confiscation-of-assets orders
against them, arrange for marshal[l]s to execute those orders,
and then pay me half of the gross proceeds to help me get out of
debt and keep the other half to reimburse yourself for all those
free services you provided?
Or are you going to continue enjoying just kicking me while I'm
down, complaining about my financial situation as if it were *my*
fault and as if I were a bad person deserving my fate, blaming *me*
for my lack of access to money and the equipment/services it could
purchase?
Recently I've come to value you as the #2 Lisp guru on this
newsgroup, right after Kent Pitman (KMP), but on the other hand
your personality regarding my financial situation sucks! I'd rather
you either provide me with some help in overcoming my financial
plight, or just stop harassing me over my unfortunate situation I
am helpless to escape. Become part of the solution to alleviate my
unfortunate situation, or just stop being part of the problem.
BTW, back on thread, Last night I started another session of CMUCL
19c with (ext:gc-off) on FreeBSD 7.1, and ran it for another several
hours without it crashing even once, and this time instead of
ending a session and checking how much storage had been used, I
just kept it running and intend to continue that same non-GC session
after I finish posting this newsgroup article. During that second
non-GC session I finished all the code to parse the diagnostic
output from 'curl' to automate the process of logging into Yahoo! Mail
to check whether I had (covertly) uploaded the username+password
correctly. So during that session I successfully uploaded+verified passwords
for appx. 2/3 of all my Yahoo accounts. Then during the same no-GC
session I got back to the code I had been working on Oct.02-03 to
parse the new format of output from 'wget' on the new shell
compared to the output my older software could already parse just
fine on the old shell running an older version of 'wget'. At
exhaustion-hence-bedtime point about 4AM I had located that
Oct.02-03 incomplete code among my many incomplete notes caused by
the disastrous confusion over switch to new shell account with "all
hell breaking loose" of things being incompatible or just plain
crashing horribly, and had re-tested everything up to the point
where I broke off work Oct.03 due to CMUCL crashing all the time,
and finally I wrote some new code up to the point where it can
parse the first four lines of 'wget' diagnostic output and thereby
diagnose whether 'wget' was reporting no such host or 404 no such
file or 200 OK. Here's the current state of the toplevel function
to parse 'wget' output and diagnose what happened and collect all
the data I want to collect:
;Given string that is the URL we tried to fetch with 'wget',
; and given string containing diagnostic output from 'wget':
;Parse the lines of it successivenly, using my one-pass recursive-descent
; parser, to try to diagnose whether the file exists or not.
;If host doesn't even exist according to DNS, return list (:NOHOST)
;If host exists, then:
; If WebPage/file doesn't exist, (code 404), return list: (:NOFILE)
; If it exists (code 200), return list: (:GOT200 ip filnam size mime)
(defun wget-diagout-string-diagnose (url diagstr)
;(setq url g-topgeourl-yes) (setq diagstr g-diagstr-yes)
(prog ()
(setq diaglines (split-string-by-lines diagstr))
(setq res1 (wget-diag-line1-verify (nth 0 diaglines) url))
(unless (eq res1 :OK)
(error "Bug: 'wget' errout line#1 was bad:~%~S" (nth 0 diaglines)))
(setq res2 (wget-diag-line2-verify (nth 1 diaglines)))
;(:GOOD "98.137.46.72")
(when (eq (car res2) :BAD) (return (list :NOHOST)))
(unless (eq (car res2) :GOOD)
(error "Bug: 'wget' errout line#2 neither good nor bad"))
(setq ip (cadr res2))
(setq res3 (wget-diag-line3-verify (nth 2 diaglines)))
(unless (eq res3 :OK) (error "'wget' errout line#3 bad"))
(setq res4 (wget-diag-line4-verify (nth 3 diaglines)))
(when (eq res4 :NOFILE) (return (list :NOFILE)))
(unless (eq res4 :OK)
(error "Bug: 'wget' errout line#4 neither good nor bad"))
;Need to parse additional lines:
;5: "Length: 3445 (3.4K) [text/html]"
;6: "Saving to: `index.html.4'"
;7: " 0K ... 100% 161M=0s"
;8: "2009-10-08 02:33:35 (161 MB/s) - `index.html.4' saved [3445/3445]"
As a sample of how my one-pass recursive-descent parser
(essentially a structured Lispy alternative to geeky horrid-syntax
chicken-track regular expressions where you have to memorize which
characters need to be \quoted in each of several different
circumstances, and the regular expressions don't obviously show
their nested structure in any humane way)
is useful for this task, here's one of the single-line parsers:
(defparameter g*wget-line3-parserules
'((:EXACT "Connecting to ") :HOST1 (:EXACT "|") :IPNUM4
(:EXACT "|:80... connected.")))
;Given string that should be third line of 'wget' diagnostic output, such as:
; "Connecting to www.geocities.com|98.137.46.72|:80... connected."
;Verify the syntax looks correct.
(defun wget-diag-line3-verify (line3)
;(setq line3 (nth 0 g-lines))
(prog (ix1)
(setq ix1 (parse1p-specrecs-try line3 0 g*wget-line3-parserules))
(unless ix1 (error "wget line#3 didn't parse"))
(unless (= ix1 (length line3))
(error "wget line#3, extra text after good parse:~% ~S"
(subseq line3 ix1)))
(return :OK)
))
And here are the definitions of those named production rules used above:
(:HOST1 (:1+ "A9-_."))
(:IPNUM4 :9 (:EXACT ".") :9 (:EXACT ".") :9 (:EXACT ".") :9)
(:9 (:1+ "9"))
Note the following character classes used in parameter to the :1+
pattern, derived partly from COBOL picture statements:
9 = any digit
A = any alphabetic
w = any whitespace
any other character represents exactly itself
Thus for example the character-class string "A9-_." means a single
character can be any alphanumeric or hyphen or underscore or period,
and (:1+ "A9-_.") matches one or more of any combination of
characters each of which belongs to one of those character classes.
Note, my "one pass parser", and most of the named production rules,
were written 2004.Sep-Oct
<http://www.rawbw.com/~rem/WAP/Done2004.9a.html>
<http://www.rawbw.com/~rem/WAP/Done2004.Aa.html>
in order to parse Received lines in spam in order to find and
collect the SMTP-client-IP-number from any of about fifty different
formats of Received line seen in spam, in order to track the IP
numbers backwards from my own ISP through various forwarding
systems I have set up, to find the point where the spammer's ISP or
an "owned" MS-Windows machine illegally sent the spam to my e-mail
address, by introducing it into a SMTP server handing my e-mail
address, and thus learn the IP number of the spammer's "owned"
computer, and thus be able to find which ISP allowed their machines
to be "owned" and used by the spammer, in order to figure out where
to complain about the spam, in the hope the ISP might take measures
to prevent future use of their computers by spammers. (Note that
procmail is totally unable to provide such tracking of IP numbers
back to entry point because it gives priority to Received line that
achieves earliest match to rule in .procmailrc sequence, rather
than specifically locating the chronologically last Received line
before internal post-receipt mail-forwarding.)
This new wget-output-parser is the first new/other application of
that generic table-driven recursive-descent parser after that
Received-line parser appx. five years ago.
Robert Maas, http://tinyurl.com/uh3t
> I've never got lynx or w3m (emacs-w3m) to work with gmail.
Have you found *any* way to effectively use gmail from a VT100 term
on a *nix shell account? Somebody suggested using something like
POP instead of the Web-based interface provided by Google for
getting access to Gmail mailboxes. Have you found that to be
workable from VT100 terms?
By the way, I'm rather happy with fastmail.us as my secret mailbox,
and making do with SpamGourmet to provide multiple sub-addresses
individually configured to forward to fastmail.us, except for the
problem of over-limit being discarded instead of refused, and the
limit can't go past 20.
Robert Swindells
Robert Maas wrote:
>> > You think it's reasonable to sign up for a mailing list, to ask for
>> > help with a CMUCL problem, but then be unable to read most of the
>> > responses I get back?
>> From: p...@informatimago.com (Pascal J. Bourguignon)
>> No. We think it's unreasonable not being able to read emails.
>And given that I haven't been able to find a free laptop computer
>that actually works in order to get on PPP, and I haven't been able
>to find anyone to pay me to write software, or do any other kind of
>useful work, such that I could pay basic living expenses and have
>some extra money to *buy* a new laptop computer that could do PPP?
You wrote that you have got two laptops, one with a modem that isn't
working and one that won't power up.
For the one that won't power up, have you tried removing the battery
and just powering it from the mains ?
External modems are practically worthless to most people these days,
ISTR a long thread where people talked you through locating the serial
port on the laptop that would power up. What happened with this ?
Espen Vestre
> Have you found *any* way to effectively use gmail from a VT100 term
> on a *nix shell account? Somebody suggested using something like
> POP instead of the Web-based interface provided by Google for
> getting access to Gmail mailboxes. Have you found that to be
> workable from VT100 terms?
Of course, you can use pop with gnus in emacs in terminal mode.
Btw. first time I was almost drowning in spam, I simply wrote my own
spam filter in common lisp. I started by writing a bare-bones POP
client, and then built a set of rules around that. The program would log
on to the pop server and then simply delete anything that looked too
much like spam. I used the program as a hook to gnus, so it would always
run before the real gnus pop session started (I now use exim filters on
our mail server to delete spam - usually more than 3000 spams a day are
deleted for my account only).
--
(espen)
Robert Maas, http://tinyurl.com/uh3t
> You wrote that you have got two laptops, one with a modem that
> isn't working and one that won't power up.
The first one, yes. The second one, it does power up to the point
where it notices it's in the middle of a shut-down that hasn't yet
completed, so it tries to complete that shut-down, and hangs for
ten minutes until it times out and does abrupt unsafe power-off.
> For the one that won't power up,
[won't finish shutting down]
> have you tried removing the battery and just powering it from the mains ?
No, because I don't see how removing the battery would allow
shut-down to finish so that it can *recogize* it's off and thereby
allow itself to then be turned on again. But if you honestly
believe removing the battery will allow it to finish the orderly
shut-down, and can convince me as to why you believe that, I'd be
willing to try removing the battery.
> External modems are practically worthless to most people these days,
Since I use an external modem to connect my mac to the phone line
to run VT100 dialup to Unix shell, you are claiming I'm not a real
person? Nay, you played it safe by including the word "most" in
there. I'm not one of your "most people", I'm one of "the others".
> ISTR a long thread where people talked you through locating the
> serial port on the laptop that would power up. What happened with
> this ?
The RedHat Linux DELL laptop uses a different kind of connector
from my Mac. My Mac uses a DIN connector. The DELL laptop uses
something else, I forgot, maybe an EIA or somesuch, that was months
ago. I don't have the money to buy a DIN-to-whatever adaptor that
would allow my modem to plug through the adapter into the laptop.
It would have to not only convert pin layout but also convert
voltage levels, because the Mac DIN uses RS-422 or somesuch instead
of RS-232, according to info I learned just in the past month.
Actually I don't know what signals are used by the laptop, whether
it's RS-232 or RS-422 or what. (I might have that 422 number wrong,
I'm doing it from memory.)
Note the data/FAX modem I'm using with the Mac does *not* have a
female jack for the cable to the Mac. It has a rubber-protected
cord running through a hole in the cabinet, with a male DIN plug on
the other end of the cord, to plug into the female DIN jack on the
back of the Mac. So a cord with male plugs at both ends would be of
no use to connect between laptop and modem.
Robert Swindells
>> From: Robert Swindells <r...@fdy2.demon.co.uk>
>> You wrote that you have got two laptops, one with a modem that
>> isn't working and one that won't power up.
>> have you tried removing the battery and just powering it from the mains ?
>No, because I don't see how removing the battery would allow
>shut-down to finish so that it can *recogize* it's off and thereby
>allow itself to then be turned on again. But if you honestly
>believe removing the battery will allow it to finish the orderly
>shut-down, and can convince me as to why you believe that, I'd be
>willing to try removing the battery.
You could start reading up on SMBus on Wikipedia, or you could just
try it.
>> External modems are practically worthless to most people these days,
[snip]
>> ISTR a long thread where people talked you through locating the
>> serial port on the laptop that would power up. What happened with
>> this ?
>The RedHat Linux DELL laptop uses a different kind of connector
>from my Mac. [snip]
Ok, so look for a different external modem that somebody else doesn't
need anymore, with the correct cable for your laptop, and use that.
Spiros Bousbouras
I just tried "lynx www.gmail.com" on the Linux command line.
I got "Your client has issued a malformed or illegal request."
Further down there is some "code" which I should send to
them to help them fix the problem. It has been like this for
ages. However until recently doing "lynx www.google.com"
would produce the same result but this has been fixed so
hopefully gmail will also be fixed eventually. Personally I
never bothered to send them the code. Note that Lynx is
generally a lot more reliable than Firefox which is the browser
I use for non-text based browsing. Apart from Google, Lynx
has worked fine with every other site which could be expected
to work with a text based browser.
Vassil Nikolov
On Thu, 08 Oct 2009 21:15:06 +0200, Espen Vestre <es...@vestre.net> said:
> Of course, you can use pop with gnus in emacs in terminal mode.
IMAP, too. (I believe Gmail offers IMAP access.)
Practically all of my usage of Gnus (and emacs) on a terminal has
been on an xterm, rather than a VT-100(-class) terminal, but it
seems to me that Gnus won't be handicapped on the latter, since it
makes little use of the meta key. (Having a meta key is never a
hard requirement with emacs, of course, but in some kinds of usage
its absence is felt more strongly; it seems to me Gnus would not be
among those.)
---Vassil.
--
"Even when the muse is posting on Usenet, Alexander Sergeevich?"
Petter Gustad
>> From: Petter Gustad <newsmailco...@gustad.com>
>> I've never got lynx or w3m (emacs-w3m) to work with gmail.
>
> Have you found *any* way to effectively use gmail from a VT100 term
> on a *nix shell account? Somebody suggested using something like
> POP instead of the Web-based interface provided by Google for
> getting access to Gmail mailboxes. Have you found that to be
> workable from VT100 terms?
I use Emacs/Mew for e-mail and use it in at vt100 window as well. I'm
using Mew/IMAP to communicate with my own IMAP server, cut I could as
well have used IMAP to communicate with gmail.
Petter Gustad
Robert Maas, http://tinyurl.com/uh3t
> And if the last output is 26: UNIX::SIGBUS-HANDLER, it sounds
> like something has pretty badly trashed the stack so you can't go
> any further. (Or maybe try back 100, just in case).
Wednesday I tried running with automatic-GC disabled, and the
prevented the crashing (except if I deliberately call GC manually,
then the first GC completes normally but the second GC crashes
before it completes). I started a second automatic-GC-disabled
session Wednesday evening, and used it through most of the night,
and it didn't crash, and I kept it sitting there and resumed it all
day and evening Thursday, and still it didn't crash, and I still
have it sitting there to resume Friday morning. So that seems to be
a reasonable workaround until somebody really fixes the bug.
Thursday I made major progress in re-writing the stuff that worked
fine on the old shell but broke on the new shell because I had to
switch from scraping lynx to parsing curl instead, and wget
produces a different format of output so that parse needed to be
rewritten from scratch too. I reported some of that re-write
progress at the end of the first automatic-GC-disabled session, and
then because it was working so well with automatic-GC-disabled I
went back to my 2009 Feb-Sep practice of reporting all my
significant accomplishments to my Twitter account very shortly afte
they are achieved. Here are the latest such Twitter progress reports:
<http://twitter.com/CalRobert/status/4719984815>
<http://twitter.com/CalRobert/status/4721252083>
<http://twitter.com/CalRobert/status/4721321698>
<http://twitter.com/CalRobert/status/4721336618>
<http://twitter.com/CalRobert/status/4728388970>
<http://twitter.com/CalRobert/status/4729129760>
OK, now with that out of the way, I'll do your backtrace 100 and
post it below:
> lisp
CMU Common Lisp 19c Release (19C), running on shell0.rawbw.com
With core: /usr/local/lib/cmucl/lib/lisp.core
Dumped on: Wed, 2005-11-16 17:18:11-08:00 on snapdragon.csl.sri.com
See <http://www.cons.org/cmucl/> for support information.
Loaded subsystems:
Python 1.1, target Intel x86
CLOS based on Gerd's PCL 2004/04/14 03:32:47
* (gc)
; [GC threshold exceeded with 86,024 bytes in use. Commencing GC.]
; [GC completed with 20,120 bytes retained and 65,904 bytes freed.]
; [GC will next occur when at least 12,020,120 bytes are in use.]
NIL
* (gc)
; [GC threshold exceeded with 24,088 bytes in use. Commencing GC.]
Help! 12 nested errors. KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded.
Debug (type H for help)
(UNIX::SIGSEGV-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP #x28F0000B)
)
%primitive halt called; the party is over.
LDB monitor
ldb> backtrace 100
Backtrace:
0: Foreign fp = 0x47fd75b8, ra = 0x804cfc3
1: Foreign fp = 0x47fd76f8, ra = 0x804d202
2: Foreign fp = 0x47fd7748, ra = 0x804d251
3: Foreign fp = 0x47fd7758, ra = 0x804e424
4: Foreign fp = 0x47fd77f8, ra = 0x80523d9
5: Foreign fp = 0x47fd79c8, ra = 0xffffefd4
6: COMMON-LISP::ERROR
7: UNIX::SIGSEGV-HANDLER
8: UNIX::SIGSEGV-HANDLER
9: Foreign fp = 0x47fd7aa8, ra = 0x80526bc
10: Foreign fp = 0x47fd7ad8, ra = 0x8052523
11: Foreign fp = 0x47fd7b08, ra = 0x804f2ab
12: Foreign fp = 0x47fd7b28, ra = 0x8052c23
13: Foreign fp = 0x47fd7cfc, ra = 0xffffefd4
14: COMMON-LISP::ERROR
15: DEBUG::GET-FILE-TOP-LEVEL-FORM
16: DEBUG::GET-TOP-LEVEL-FORM
17: DEBUG::PRINT-CODE-LOCATION-SOURCE-FORM
18: DEBUG::PRINT-FRAME-CALL
19: DEBUG::DEBUG-LOOP
20: DEBUG::INTERNAL-DEBUG
21: "DEFUN ERROR-ERROR"
22: LISP::%WITH-STANDARD-IO-SYNTAX
23: KERNEL::ERROR-ERROR
24: COMMON-LISP::ERROR
25: UNIX::SIGBUS-HANDLER
26: UNIX::SIGBUS-HANDLER
ldb>
Sorry Charlie^H^H^H^H^H^H^HRaymond, the backtrace only goes to 26.
> Robert> I never heard of 'gdb' before. (I never heard of LDB either until
> Robert> CMUCL crashed into it.)
> >> Then we can make some progress. Just run cmucl (lisp) under gdb
> >> and when those new signals happen, gdb should stop and we can look
> >> around to see what's going on.
> Robert> Can you walk me through how to get CMUCL running under gdb, and
> Robert> then after the signal-intercept happens, what command to give to
> Robert> gdb to print out the information you need?
> gdb <bin/lisp>
> run
OK, I'll give it a try...
> whereis lisp
lisp: /usr/local/bin/lisp
/usr/local/man/man1/lisp.1.gz
/usr/ports/editors/emacs/work/emacs-22.2/lisp
(I prettyprinted that to make it easier to read.)
> gdb </usr/local/bin/lisp>
Missing name for redirect.
> gdb <bin/lisp>
Missing name for redirect.
> gdb /usr/local/bin/lisp
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)
..
(gdb) run
Starting program: /usr/local/bin/lisp
(no debugging symbols found)...(no debugging symbols found)...CMU Common Lisp 19
c Release (19C), running on shell0.rawbw.com
With core: /usr/local/lib/cmucl/lib/lisp.core
Dumped on: Wed, 2005-11-16 17:18:11-08:00 on snapdragon.csl.sri.com
See <http://www.cons.org/cmucl/> for support information.
Loaded subsystems:
Python 1.1, target Intel x86
CLOS based on Gerd's PCL 2004/04/14 03:32:47
* (gc)
; [GC threshold exceeded with 86,256 bytes in use. Commencing GC.]
; [GC completed with 20,336 bytes retained and 65,920 bytes freed.]
; [GC will next occur when at least 12,020,336 bytes are in use.]
NIL
* (gc)
; [GC threshold exceeded with 24,304 bytes in use. Commencing GC.]
Program received signal SIGBUS, Bus error.
0x10068cdc in ?? ()
(gdb)
> You'll get the regular repl. But the first time you GC or allocate
> something, you'll probably get dumped back to gdb because a signal.
No, it only happens the second (gc).
> At this point, you're going need to have the sources installed
> somewhere.
> whereis cmucl
cmucl: /usr/local/man/man1/cmucl.1.gz
/usr/ports/lang/cmucl
> cd /usr/ports/lang/cmucl
> ls -lt | more
total 9
2 -rw-r--r-- 1 root wheel 1480 May 8 00:44 Makefile
1 -rw-r--r-- 1 root wheel 261 May 8 00:44 distinfo
2 -rw-r--r-- 1 root wheel 1269 May 8 00:44 pkg-plist
2 drwxr-xr-x 6 root wheel 16 Nov 22 2008 work/
2 -rw-r--r-- 1 root wheel 1087 May 12 2003 pkg-descr
> du
949 ./work/lib/cmucl/lib/subsystems
24020 ./work/lib/cmucl/lib
24309 ./work/lib/cmucl
24311 ./work/lib
388 ./work/bin
16 ./work/doc/cmucl
17 ./work/doc
24 ./work/man/man1
25 ./work/man
24752 ./work
24761 .
I don't see any sources there. I looked at the Makefile but all it
seems to do is move files from the untar location to the permanent
location, doesn't do any compilation as far as I can see.
> And you'll also have to dig through FreeBSD stuff to find
> out what signals are generated. From FreeBSD-os.h I see:
> #if __FreeBSD_version < 700004
> #define PROTECTION_VIOLATION_SIGNAL SIGBUS
> #define PROTECTION_VIOLATION_CODE BUS_PAGE_FAULT
> #else
> #define PROTECTION_VIOLATION_SIGNAL SIGSEGV
> #define PROTECTION_VIOLATION_CODE SEGV_ACCERR
> #endif
Am I reading this correctly, that CMUCL used to catch the SIGBUS,
but now is catching the SIGSEGV instead, but the SIGBUS is still
occurring, now *not* being caught, so it bombs instead? Maybe the
problem isn't that FreeBSD 7.1 generates a new kind of signal that
CMUCL doesn't know how to handle, but this pre-release version of
FreeBSD 7.1 still is generating the old signals but CMUCL is seeing
the "7.1" version number and mistakenly believing the new signals
are being generated and trying to catch them instead of catching
the old signals that are still being generated?
> So with FreeBSD_version 700004 (whatever that corresponds to), the
> actual signal and code changed. Perhaps this is the problem.
Another possibility is that there's a fencepost error as to *when*
exactly FreeBSD switched to the new signals, that CMUCL is
switching one earlier or one later, so right at the fencepoint the
two disagree as to whether the switch has happened yet or not.
> I'm sorry, but you'll have to do some digging on your own. I can give
> some hints and suggestions, but I don't know anything about FreeBSD.
I don't know anything about FreeBSD either, except that my shell is
/usr/local/bin/tcsh compared to the various other shells that other
versions of *nix might use. The only difference between the
different shells I never noticed is that redirection of stdout and
errout work differently between my very old Unix book (y McGilton
and Morgan) and some of the actual shells I've been forced to use
on various ISPs I've had accounts on. For example, when I wrote
shell scripts to interface between CGI and CMUCL, and I used
/bin/sh as the shell for running the CGI scripts, they didn't work
as I had been used to from regular shell usage. But regarding
internals, even C-callable OS-API utilities, I know nada.
Robert Swindells
>> somewhere.
[snip]
>I don't see any sources there. I looked at the Makefile but all it
>seems to do is move files from the untar location to the permanent
>location, doesn't do any compilation as far as I can see.
You will need to download the sources to 19f from the same place you
got the binaries.
When you have got them use gdb on the 19f build that you downloaded.
Will you take this to email, there is no need for this thread to be
in comp.lang.lisp.
vippstar
> vippstar <vipps...@gmail.com> writes:
> > On Oct 8, 4:43 pm, Petter Gustad <newsmailco...@gustad.com> wrote:
> >> I've never got lynx or w3m (emacs-w3m) to work with gmail.
>
> > Where?
>
> Under Linux.
forgot) was unnoticable until you mentioned it, and even then one had
to search for the missing word ;-) You removed the quotation so that
is not shown in this post.
Aleksej Saushev
>> From: Robert Swindells <r...@fdy2.demon.co.uk>
>> This code works fine in 19f on NetBSD, both interpreted and compiled.
>
> Does NetBSD derive directly from FreeBSD 7.1
What makes you think that NetBSD is likely to derive from FreeBSD?
It isn't Linux, NetBSD and FreeBSD are different operating systems.
--
HE CE3OH...
Raffael Cavallaro
> Actually I was just trying to show that your typo (ie the word you
> forgot) was unnoticable until you mentioned it
I noticed it immediately.
--
Raffael Cavallaro
vippstar
<raffaelcavall...@pas.espam.s.il.vous.plait.mac.com> wrote:
> On 2009-10-09 08:48:24 -0400, vippstar <vipps...@gmail.com> said:
>
> > Actually I was just trying to show that your typo (ie the word you
> > forgot) was unnoticable until you mentioned it
>
> I noticed it immediately.
*clap.wma*
Curt
>
> On Thu, 08 Oct 2009 21:15:06 +0200, Espen Vestre <es...@vestre.net> said:
>> Of course, you can use pop with gnus in emacs in terminal mode.
>
> IMAP, too. (I believe Gmail offers IMAP access.)
>
They do. That's the way I access my gmail account. It's a
non-conforming implementation of the IMAP protocol, though (which means
that certain things in pine, my email client, don't work as expected).
However, last I looked, you have to "turn on" the IMAP access via the web
interface. Which probably provides a juicy excuse for Robert not to use
it.
;-)
Raffael Cavallaro
His error was obvious[1]. His correction was completely understandable.
Your twitting him over correcting it was uncalled for.
1. Without the missing word, his sentence amounted to modifying the
proper noun "lynx" with the adverb "never," so it made as much sense as
saying "we quickly cereal." Such omissions are jarringly obvious to
native speakers.
--
Raffael Cavallaro
Vassil Nikolov
On 09 Oct 2009 16:26:27 GMT, Curt <cu...@free.fr> said:
> ...
> However, last I looked, you have to "turn on" the IMAP access via the web
> interface.
By the way, I have been told that Gmail at least used to
have---maybe still has---a "basic HTML" web interface not dependent
on JavaScript. Might be worth a try.
Vassil Nikolov
On Fri, 9 Oct 2009 13:46:36 -0400, Raffael Cavallaro <raffaelc...@pas.espam.s.il.vous.plait.mac.com> said:
> ...
> [there is no sense in]
> saying "we quickly cereal." Such omissions are jarringly obvious to
> native speakers.
Yes, though... appeal, cereal, conceal, heal, reveal, steal...
George Neuner
wrote:
If you don't know the history, it's not a stupid question given the
similarity in names.
George
George Neuner
(Robert Maas, http://tinyurl.com/uh3t) wrote:
>Does NetBSD derive directly from FreeBSD 7.1,
No. They are separate OSes. FreeBSD was a x86-specific fork from
multiplatform NetBSD (which itself forked from 4.3 BSD Unix).
George
Andrew Reilly
Sort-of.
4.3 Net1 distro
--> 386bsd (which was a DrDobbs article project)
--> 386bsd+patchkit
--> NetBSD0.[89] | more patchkit revisions
--> NetBSD1.x | 386bsd+patchkit==FreeBSD(i forget the revision)
somewhat later the court-case produced the BSD Net2 distro and both
NetBSD and FreeBSD had to rip small bits of themselves out and replace
with new stuff.
Specifically, NetBSD coexisted with the patchkit for a while, and then
the patchkit folk got sick of waiting for that to be rolled into 386bsd
and (re)named the 386+patchkit combination FreeBSD and started their own
distribution from there.
There's bound to be a timeline published on the web somewhere...
They *are* separate, and they did both separate from 386bsd, but not at
the same time. There's been a lot of back-and-forth since, of course.
Cheers,
--
Andrew
Aleksej Saushev
It has nothing to do with history. If names differ, it is more
reasonable to assume that there's some difference. And it does exist.
There's major difference especially at the kernel level, where signal
handling belongs to.
--
HE CE3OH...
Raffael Cavallaro
> On Fri, 9 Oct 2009 13:46:36 -0400, Raffael Cavallaro
> <raffaelc...@pas.espam.s.il.vous.plait.mac.com> said:
>> ...
>> [there is no sense in]
>> saying "we quickly cereal." Such omissions are jarringly obvious to
>> native speakers.
>
> Yes, though... appeal, cereal, conceal, heal, reveal, steal...
You do realize that "appeal", "conceal", "heal", "reveal", and "steal"
are verbs, and that "cereal" is a noun, right?
The error is that the missing word resulted in an adverb ("never")
modifying a noun ("lynx") instead of modifying the missing past
particple of a verb (gotten) which it was intended to modify.
--
Raffael Cavallaro
Vassil Nikolov
On Sat, 10 Oct 2009 10:05:01 -0400, Raffael Cavallaro <raffaelc...@pas.espam.s.il.vous.plait.mac.com> said:
> On 2009-10-09 23:29:32 -0400, Vassil Nikolov <vnik...@pobox.com> said:
>> On Fri, 9 Oct 2009 13:46:36 -0400, Raffael Cavallaro
>> <raffaelc...@pas.espam.s.il.vous.plait.mac.com> said:
>>> ...
>>> [there is no sense in]
>>> saying "we quickly cereal." Such omissions are jarringly obvious to
>>> native speakers.
>>
>> Yes, though... appeal, cereal, conceal, heal, reveal, steal...
> You do realize that "appeal", "conceal", "heal", "reveal", and "steal"
> are verbs, and that "cereal" is a noun, right?
"Appeal", "reveal", and "steal" are also nouns [*]. I took issue
(somewhat facetiously) with "jarringly obvious", especially given
also that "all nouns can be verbed".
"Funny thing, language", as Dr. Chasuble said... [+].
_________
[*] besides being verbs
[+] only in a movie version, though
References:
http://www.merriam-webster.com/dictionary/<WORD>
search?q=%22all+nouns+can+be+verbed%22+jargon
George Neuner
wrote:
>George Neuner <gneu...@comcast.net> writes:
>
>> On Fri, 09 Oct 2009 17:32:04 +0400, Aleksej Saushev <as...@inbox.ru>
>> wrote:
>>
>>>seeWeb...@rem.intarweb.org (Robert Maas, http://tinyurl.com/uh3t)
>>>writes:
>>>
>>>>> From: Robert Swindells <r...@fdy2.demon.co.uk>
>>>>> This code works fine in 19f on NetBSD, both interpreted and compiled.
>>>>
>>>> Does NetBSD derive directly from FreeBSD 7.1
>>>
>>>What makes you think that NetBSD is likely to derive from FreeBSD?
>>>It isn't Linux, NetBSD and FreeBSD are different operating systems.
>>
>> If you don't know the history, it's not a stupid question given the
>> similarity in names.
>
>It has nothing to do with history. If names differ, it is more
>reasonable to assume that there's some difference. And it does exist.
>There's major difference especially at the kernel level, where signal
>handling belongs to.
You danced around my point which is: it is not unreasonable for
someone to think that there might be a connection between the two
given that they both have "BSD" as part of their names.
George
Robert Maas, http://tinyurl.com/uh3t
> Wednesday I tried running with automatic-GC disabled, and the
> prevented the crashing (except if I deliberately call GC manually,
> then the first GC completes normally but the second GC crashes
> before it completes). I started a second automatic-GC-disabled
> session Wednesday evening, and used it through most of the night,
> and it didn't crash, and I kept it sitting there and resumed it all
> day and evening Thursday, and still it didn't crash, and I still
> have it sitting there to resume Friday morning. So that seems to be
> a reasonable workaround until somebody really fixes the bug.
> Thursday I made major progress in re-writing the stuff that worked
> fine on the old shell but broke on the new shell because I had to
> switch from scraping lynx to parsing curl instead, and wget
> produces a different format of output so that parse needed to be
> rewritten from scratch too. I reported some of that re-write
> progress at the end of the first automatic-GC-disabled session, and
> then because it was working so well with automatic-GC-disabled I
> went back to my 2009 Feb-Sep practice of reporting all my
> significant accomplishments to my Twitter account very shortly afte
> they are achieved. Here are the latest such Twitter progress reports:
> <http://twitter.com/CalRobert/status/4719984815>
Oops, after I posted the above, I noticed a typo in that first line
quoted above, which I'll correct now:
| Wednesday I tried running with automatic-GC disabled, and THAT
| prevented the crashing ...
So here's an update: That second GC-disabled session, which I
started Wednesday evening, I continued to use Thursday and Friday
and into Saturday morning, without any crashing or other problem
the whole time. So the evidence strongly supports my hypothesis
that the bug is somewhere inside GC. I was in the middle of
composing my just-previous article, about planning to convert some
of the new dataflow code to use CLOS generic functions:
<news:REM-2009...@Yahoo.Com>
= <http://groups.google.com/group/comp.lang.lisp/msg/967aae746e106149>
late Saturday morning, right after I had collected a transcript
(included in that article) showing my new automatic dataflow, but
before I could run a demonstration of my interactive NestAL
browser, when suddenly CMUCL alerted me that I had reached the
maximum heap space. Once this warning is issued, if I manually call
GC (to attempt to get back down below that limit and then proceed
like normal) it no longer works at all!! Apparently GC requires
some extra temporary storage, which isn't available at this time.
So now I know that with default heap size, CMUCL with GC disabled
let me do productive work for about 2.5 days before I've generated
a half gigabyte of data making CMUCL run out of memory. Below is
the transript:
CMUCL has run out of dynamic heap space (512 MB).
You can control heap size with the -dynamic-space-size commandline option.
Imminent dynamic space overflow has occurred:
Only a small amount of dynamic space is available now. Please note that you will
be returned to the Top-Level without warning if you run out of space while debugging.
Heap (dynamic space) overflow
[Condition of type KERNEL:HEAP-OVERFLOW]
Restarts:
0: [ABORT] Return to Top-Level.
Debug (type H for help)
(KERNEL:DYNAMIC-SPACE-OVERFLOW-WARNING-HIT)
Source: Error finding source:
Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists:
target:code/interr.lisp.
0] 0
* (gc)
; [GC threshold exceeded with 535,392,528 bytes in use. Commencing GC.]
*A2 gc_alloc_new_region failed, nbytes=40.
CMUCL has run out of dynamic heap space (512 MB).
You can control heap size with the -dynamic-space-size commandline option.
Imminent dynamic space overflow has occurred:
Only a small amount of dynamic space is available now. Please note that you will
be returned to the Top-Level without warning if you run out of space while debu
gging.
Heap (dynamic space) overflow
[Condition of type KERNEL:HEAP-OVERFLOW]
Restarts:
0: [ABORT] Return to Top-Level.
Debug (type H for help)
(KERNEL:DYNAMIC-SPACE-OVERFLOW-WARNING-HIT)
Source: Error finding source:
Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists:
target:code/interr.lisp.
0] 0
* (gc)
; [GC threshold exceeded with 535,417,112 bytes in use. Commencing GC.]
*A2 gc_alloc_new_region failed, nbytes=40.
CMUCL has run out of dynamic heap space (512 MB).
You can control heap size with the -dynamic-space-size commandline option.
Imminent dynamic space overflow has occurred:
Only a small amount of dynamic space is available now. Please note that you will
be returned to the Top-Level without warning if you run out of space while debu
gging.
Heap (dynamic space) overflow
[Condition of type KERNEL:HEAP-OVERFLOW]
Restarts:
0: [ABORT] Return to Top-Level.
Debug (type H for help)
(KERNEL:DYNAMIC-SPACE-OVERFLOW-WARNING-HIT)
Source: Error finding source:
Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists:
target:code/interr.lisp.
0] 0
* (quit)
>
Raffael Cavallaro
> especially given
> also that "all nouns can be verbed".
The sentence starts with "I've never...". A native speaker's ear
expects a *participle* at that point, not a noun, or even a verb formed
from a noun.
All of these:
"I've never appeal..."
"I've never reveal..."
"I've never steal..."
are equally jarring to a native speaker who expects to hear:
"I've never appealed..."
"I've never revealed..."
"I've never stolen..."
or, hypothetically, if the noun "lynx" had actually been verbed:
"I've never lynxed..."
but not:
"I've never lynx..."
> "Funny thing, language", as Dr. Chasuble said...
The Michael Redgrave version is still my favorite production of The
Importance of Being Earnest.
--
Raffael Cavallaro
Robert Maas, http://tinyurl.com/uh3t
> Or even just use GNUS as well for email as for news, so he may
> reduce the set of his impossibilities...
Google search yields:
! Gnus is a flexible message reader running under GNU Emacs.
Unfortunately emacs on this new shell account is grossly broken in
the way it handles VT100 screens. Every time I try to edit a
buffer, the cursor jumps to random places instead of where I'm
typing, usually when I type a word break is when the cursor jumps
most often it seems, trashing what I'm seeing. Cursor motion
commands such as skip word etc. likewise trash the screen. Usually,
but not always, ctrl-L will restore a valid screen so I can see
where the cursor really is and see the current state of my edit.
Until and unless that gets fixed, GNUS would be worthless to me.
If I start an edit, save a copy of the screen, then type just a few
characters (auto-insert) until the screen looks trashed, then save
the trashed screen just the way it appears, then ctrl-L and save
the *correct* screen that now appears, and post all of: OrigScreen
KeyStrokes TrashedScreen GoodScreen, if you look at them all could
you perhaps figure out what is going wrong here?
Here, I'll upload that last paragraph to a new file, emacs it, try
to type in it, and show you the result:
When I first open the new buffer with that file's contents, by typing:
C-x C-f filename
it comes up already trashed:
If I start an edit, ve a copy of the screen, then type just a few
characters (auto-insert) until the screen looks trashed, then save
the trashed screen just the way it appears, then ctrl-L and save
the *correctscreen thatanoappeaps, and post alf: OrigScreen
KeyStrokes TrashedScreen GoodScreen, if you look at them all could
you perhaps figure out what is going wrong here?
Now if I do:
C-l
to refresh screen, I see the correct data:
File Edit Options Buffers Tools Help
If I start an edit, save a copy of the screen, then type just a few
characters (auto-insert) until the screen looks trashed, then save
the trashed screen just the way it appears, then ctrl-L and save
the *correct* screen that now appears, and post all of: OrigScreen
KeyStrokes TrashedScreen GoodScreen, if you look at them all could
you perhaps figure out what is going wrong here?
Next I search for where I want to edit:
C-s , if
cursor is in right place, next I skip word:
M-f
still looks good. That part where the cursor is:
GoodScreen, if you_look at them
where _ shows the cursor.
Next I try to type the text:
<space>were<space>to
The space and "we" are in the correct place, but the cursor has
jumped earlier in the line and showed the "r" in the wrong place:
File Edit Options Buffers Tools Help
If I start an edit, save a copy of the screen, then type just a few
characters (auto-insert) until the screen looks trashed, then save
the trashed screen just the way it appears, then ctrl-L and save
the *correct* screen that now appears, and post all of: OrigScreen
KeyStrokes Trar ldok at them acl couldf you we look at them l could
you perhaps figure out what is going wrong here?
Next I refresh screen with:
C-l
and I see a correct screen again, where I had typed space and "wer":
File Edit Options Buffers Tools Help
If I start an edit, save a copy of the screen, then type just a few
characters (auto-insert) until the screen looks trashed, then save
the trashed screen just the way it appears, then ctrl-L and save
the *correct* screen that now appears, and post all of: OrigScreen
KeyStrokes TrashedScreen GoodScreen, if you wer look at them all could
you perhaps figure out what is going wrong here?
Does GNU emacs use curses, and is curses broken on this shell machine?
Or does emacs "roll its own" independent of curses?
Robert Maas, http://tinyurl.com/uh3t
> You should upgrade to 19f, ...
I already did, and posted how (gc) twice in a row crashes it just
the same. I've been running with (ext:gc-off) for the past several
days. It allows me to run for up to a couple days of normal
software development, then manually do one (gc) to reclaim
somewhere around 200-400 megabytes out of the 512 maximum allowed
per startup default configuration, then work for another couple
days, then after all my work is saved a second (gc) crashes 19c and
I presume would likewise crash 19f. If you want me to run the full
test, after this current CMUCL 19c session which I started just
tonight runs to completion in about four days, I can use 19f for
the next CMUCL session and see if I can stretch it out to just 2
days + (gc) + 2 days like 19c.
Since my total disk allocation on this new shell machine is 500 MB,
I figure it's fair if I use an additional 500MB for swap space used
by the heap in CMUCL, but if I were to increase the heap size to
anything bigger with GC turned off so I could run longer than
2+GC+2 days during a single long session, I think the sysadmin
would look at my excessive swap space and KILL my process and shoo
me off the system, so I ain't gonna even try to push his limits.
Robert Maas, http://tinyurl.com/uh3t
> > Web nowadays use tar files, I think 'man tar' should use this as an
> > example. Sure anybody who uses tar on a regular basis would "just
> > know" that "tar -xf whatever.tar" will do the trick, but 'man tar'
> > should include that in the examples section, IMO.
> From: t...@sevak.isi.edu (Thomas A. Russ)
> Well, at least when I look at "man tar" in mine, the item you seek (or
> at least a close and perhaps more useful variant) is the first one of
> the examples:
> ...
> EXAMPLES
> tar -xvf foo.tar
> verbosely extract foo.tar
> tar -xzf foo.tar.gz
> extract gzipped foo.tar.gz
> ...
> But perhaps your man page is different.
It sure is. No such example in the 'man tar' here on FreeBSD 7.1, only:
EXAMPLES
The following creates a new archive called file.tar.gz that contains two
files source.c and source.h:
tar -czf file.tar.gz source.c source.h
To view a detailed table of contents for this archive:
tar -tvf file.tar.gz
To extract all entries from the archive on the default tape drive:
tar -x
To examine the contents of an ISO 9660 cdrom image:
tar -tf image.iso
To move file hierarchies, invoke tar as
tar -cf - -C srcdir . | tar -xpf - -C destdir
or more traditionally
cd srcdir ; tar -cf - . | (cd destdir ; tar -xpf -)
> Mine comes from Darwin/Mac OS X, but the authors of the man page
> are affiliated with Debian Linux.
I don't know where the one here comes from, and can't afford the
time/energy to try to find out.
Robert Maas, http://tinyurl.com/uh3t
> > blank screen, because it all requires JavaScript which isn't
> > available over VT100 term on Unix shell.
> From: Petter Gustad <newsmailco...@gustad.com>
> I was thinking of using a curses based program (like emacs -nw) to
> access gmail (using IMAP). But I guess you have to use a web browser
> to register in the first place...
I already registered (created new account) about a year ago, in a
semi-public computer lab, only to discover upon returning home that
it requires JavaScript to view my e-mail there, so it's useless to
me (except possibly in the future with your idea).
Then a few months ago I needed to post to an online blog-forum,
which required a gmail account, and to my surprise if I logged in
to gmail and got the blank screen but then backed out of there and
tried to post to the forum, IT WORKED!! That means gmail managed to
complete my login just fine, giving me the session cookie, but I
had no confirmation that I had been logged in because the blank
screen didn't even say "you are now logged in". But trying to post
to the forum *did* finally confirm that the login per se worked.
So given that login per se works, IMAP ought to work too, if I can
find an IMAP client that works here (VT100 termcap/terminfo/whatever).
But actually, now that you told me the keyword and I looked it up,
I have a much better use for curses: I can set up
character-interactive sessions on my Web server, whereby my
customer/user TELNETs to a special TCP socket I have set up, and
each keystroke to my server application responds with curses
changes to the VT100 screen, much better than a stdio-commandLine
mode for this purpose (set-exchange algorithm, which I posted a
demo transcript of several months ago). The basic idea is that we
want to exchange elements of a set, each a string, each user-agent
providing something the other doesn't already have, and recognizing
by alternating characters whenever we both have the same item
already hence neither can try to sell it to the other. With stdio
commandline interface, there can be only one string active at any
one time, and when alternating between two strings that are being
exchanged the strings have to be alternately re-displayed back and
forth, huge waste of network bandwidth and patience of user and
total mess-up of VT100 screen used as dumb terminal as the
transcript scrolls one line per keystroke transaction, like this
(note ^ means "I give up, don't know next letter, whereas . means
end of string):
User: K
Host: Ki
User: Kir
Host: Kirk
User: Kirk.
Host: We both knew that already, let's try another now:
Host: M
User: M^
User: S
Host: S^
Host: Mc
User: Mc^
User: Sp
Host: Sp^
Host: McC
User: McC^
User: Spo
Host: Spo^
Host: McCo
User: McCO^
User: Spoc
etc.
Now imagine how much better that would look if you had just one or
two lines on a fixed non-scrolling screen, and the user moved the
curser up or down to switch to the other line: Here are successive
screen images with _ to show cursor:
Host presents this to user:
_
User responds:
K_
Host responds:
Ki_
User responds:
Kir_
Host responds:
Kirk_
User responds:
Kirk
Host flashes alert at bottom of screen:
We both knew that already, let's try another now!
Host presents this to user:
M_
User moves cursor down to start new line:
M
_
User types on that new line:
M
S_
Host moves cursor back up and responds there:
Mc_
S
User moves cursor back down and responds there:
Mc
Sp_
Host moves cursor back up and responds there:
McC_
Sp
User moves cursor back down and responds there:
McC
Spo_
Host moves cursor back up and responds there:
McCo_
Spo
User moves cursor back down and responds there:
McCo
Spoc_
Host moves cursor back up and responds there:
McCoy_
Spoc
User moves cursor back down and responds there:
McCoy
Spock_
etc.
If you can imagine how those screens would look in action, great, huh?
VT100 curses would also make it user-friendly to back up to an
earlier position within a currently-active word and branch from
there. Basically the user first selects the currently-active word
he/she wishes to branch from, by moving cursor up/down when at end
of line. Next within that line the user moves cursor to left to
reach the branch point, to right to get back if overshot the goal.
Next the user presses down-cursor to branch at that point and the
host automatically duplicates the branched-from line up to the
point of the branch and then puts the cursor there for the user to
type the alternate next character there.
Note the purpose of the set-barter algorithm is two-fold:
The host (that I write and carefully test) would never cheat, never
claim it already has something when it really doesn't have it. But
the user might not trust the host, and if every time the user types
an entire item the host refuses to pay for it because the host says
(truthfully if it's *my* host-program running) the host already has
that, the user might (mistakenly, but quite rationally) start to
suspect my host is cheating. But if every time the user types the
next character, the host responds with the next after it, then it's
quite clear to the user that my host-program isn't cheating, so the
user starts to really trust my host-program and be willing to deal
with it. Thus the first purpose is to protect against the
mistakenly accusing my host-program of cheating.
The user is almost surely going to try to cheat if I allow it!! If
I first give something to the user, on the user's promise of giving
something back, sure enough the user will "skip town" and I'll be
short in the deal. But if I never give to the user anything without
first getting an equal amount *from* the user, there's no way the
user can ever cheat my host-program. Thus the second purpose is to
protect against spambots and other users of my system getting stuff
for free and never giving anything back.
Note: I have no objection to spambots using my system, providing
they pay for their use, which no spambot would ever do, but I
protect myself by equal exchange, with user always micro-giving
before host micro-giving-back, rather than try to detect spambots
per se and deny them access. Thus a single mechanism protects
against both spambot-freeloaders and regular-human-freeloaders.
Anyway, all of this will be part of http://TinyURL.Com/NewEco eventually.
Robert Maas, http://tinyurl.com/uh3t
> >> blank screen, because it all requires JavaScript which isn't
> >> available over VT100 term on Unix shell.
> > access gmail (using IMAP). But I guess you have to use a web browser
> > to register in the first place...
> From: "John Thingstad" <jpth...@online.no>
> Well Lynx is text mode browser for Linux. Use that.
It isn't possible to register on gmail using lynx from VT100 term.
I had to go to a semi-public computer lab to register, about a year ago.
By comparison it *is* possible (via lynx on VT100 term) to register
a new account on my new Web service
(which will eventually grow to become http://TinyURL.Com/NewEco)
using my current experimental portal#1, which you can reach via
http://TinyURL.Com/Portl1