Re: I found an even easier way to crash CMUCL 19c/19f on FreeBSD 7.1

From: Petter Gustad <newsmailco...@xxxxxxxxxx>
I seem to remember you were using an UNIX shell account.

Yes, VT100 emulator through modem+phone to Unix VT100 term.

You should be able to use a curses based mail program,

I don't know anything about that. Since "curses" is a plural of a
comman word, it would be rather difficult to get good search
results with a search engine. Is there a curses tutorial that you
recommend that works on a VT100 term, so that when I finish the
current GeoCities-closing rescue-files crisis I can read it to get
an idea what you're talking about?

even connecting to gmail using IMAP.

Yeah, that's what I was thinking of when I said POP etc. I remembed
it was something MAP but couldn't remember the "I" so I mentionned
the similer but older protocol instead so you'd get on the same
"wavelength" with me and lead me the next step, and it worked, you
led me to IMAP. I think I read something about the differences
between them, where POP requires you *first* download *all* your
new e-mail to your own computer at the start of the session,
whereas IMAP is something like a distributed API for keeping all
e-mail on the hosting service (Gmail in this case) until and unless
you request a particular message or category/group of messages to
be *moved* to the client computer. Is that vaguely correct??

Personally, I prefer Mew (www.mew.org) in Emacs as my E-mail client.

The version of Emacs here is horribly broken. Over and over as I'm
typing input, it moves the cursor to the wrong place, so what I'm
typing *looks* like it's going to some wrong place, and I have to
later press ctrl-L to see how my edit *really* is at that point.
Basically from the point where it starts trashing the cursor and
writing my new type-in to the wrong place on my VT100 term, until I
press ctrl-L, I'm typing semi-blind, can see new text I type, but
can't see where it's really going in my edit.

It's even worse with minibuffer auto-complete such as when typing a
directory path and filename: If I type space, it enters space in
the minibuffer, instead of completing the current word as far along
as there's only one option possible like the older version of Emacs
did on the other shell machine.

Old shell I was on until two weeks ago:
FreeBSD 4.10-STABLE (SHELL) #0: Thu Feb 16 03:07:17 PST 2006
GNU Emacs 20.7.2
(worked fine)

New shell I've been on the past two weeks:
FreeBSD 7.1-PRERELEASE (SHELL0) #0: Mon Mar 23 03:17:26 PDT 2009
GNU Emacs 22.2.1
(seriously broken: handling VT100 screen, minibuffer auto-complete)

I know my terminal type is correct, so wrong term-type isn't the problem:
echo $TERM
vt100
echo $term
vt100
echo $Term
Term: Undefined variable.

So why is emacs screwing up so badly? Do I need to explicitly tell
emacs that I'm on a limited-bandwidth dialup? I remember when I was
using a 1200 BPS modem (more than 20 years ago, upgraded to 2400
BPS modem then, got this modem in 1998 and started using 19200 BPS
a few months/years after then), on a direct dialup port, emacs
would transmit cursor-control sequences in a burst faster than the
modem could take, causing trashing, unless I told it to insert
extra NUL bytes after each sequence. But on 19200 BPS modem, with a
transparent TELNET with plenty of buffering between my shell and
the physical modem, that can't be a problem, can it? Or maybe it
can?? Help?

Bottom line, I can't possibly cope with an e-mail program where
Emacs is trashing the screen every five seconds and I have to keep
refreshing the screen just to see if I've already lost.
<nit>OK, that was 3 lines, but you know the clich{e'}, right?</nit>


Back to the original topic of this thread:
If I go more than 2 days with automatic-GC disabled, eventually it
fills up the 512 MB allocation and at that point it refuses to let
me do a (GC) to get it back down to smaller memory.
But I tried something new today, after about one day running a big
session with automatic-GC off, when I reached a stable point where
the functions were stable/working and I had saved the main dataset
to disk, I tried:
* (gc)
; [GC threshold exceeded with 348,244,872 bytes in use. Commencing GC.]
; [GC completed with 6,950,552 bytes retained and 341,294,320 bytes freed.]
; [GC will next occur when at least 18,950,552 bytes are in use.]
then I started the next major work session without re-starting
CMUCL, and so far after about 11 additional hours since then, it
hasn't crashed or anything else bad.
(The bug seems to strike only when two GCs happen close together,
such as when the first "generation" of GC can't reclaim enough
memory so it immediately does a second "generation" of GC, or
where I manually do (GC) twice in a row with almost nothing
between.)
So it looks like I can keep a CMUCL session alive indefinitely long
if I manually do (GC) just once per major software-development
session of a day or so, after it's allocated enough new memory to
avoid the page fault bug, but before it's allocated 512 MB to where
GC is no longer possible. I'm too tired to do any more software
development tonight, so I'm using the last of my barely-awake
energy to respond to this one newsgroup article. I'll resume the
*same* CMUCL session, without any new (GC), after a night's sleep,
picking up where I left off in the middle of a major
software-development session that should take another half or full
day to reach another "good time to GC".

P.S. It looks like I can do about 340 megabytes of work during a
single major work session. I wonder how that compares with "lines
of code" as a measure of productivity?

Hmm, when I upload new versions of my source files, I keep around
two backups. Someday after a few days of heavy work, after a new
upload of changed source, I should do (for each newly-uploaded
file):
diff foo.lisp-old foo.lisp | wc
as a measure of how much code I wrote/changed in each of the files,
and add up the 'wc' totals, and claim I did that many "lines of
code" between the two uploads. Would be that a good metric??

Hey, I still have a few minutes before I pass out, so I think I'll
do it now:
ls -lt | more
;Most recent upload, start of this past session:
5 -rw------- 1 rem user 3702 Oct 11 22:22 topHelpText.dat
21 -rw------- 1 rem user 20136 Oct 11 22:20 2009-3-NestAL.lisp
29 -rw------- 1 rem user 28982 Oct 11 21:40 2009-9-geo2.lisp

;Previous upload, start of previous session:
18 -rw------- 1 rem user 16967 Oct 10 20:41 2009-6-sgxmlp.lisp
25 -rw------- 1 rem user 24908 Oct 10 20:35 2009-9-geo2.lisp-old
18 -rw------- 1 rem user 17503 Oct 10 20:27 2009-3-NestAL.lisp-old
8 -rw------- 1 rem user 7260 Oct 10 20:14 2009-7-sgxmlp.lisp
5 -rw------- 1 rem user 3640 Oct 10 20:10 topHelpText.dat-old
22 -rw------- 1 rem user 21046 Oct 10 17:46 2009-3-sgxmlp.lisp
23 -rw------- 1 rem user 22253 Oct 10 17:37 2009-9-geo.lisp
25 -rw------- 1 rem user 25029 Oct 10 17:31 2009-5-sgxmlp.lisp
30 -rw------- 1 rem user 29690 Oct 10 17:24 2009-8-MUPK.lisp
27 -rw------- 1 rem user 26151 Oct 10 17:09 2008-7-Code.lisp
21 -rw------- 1 rem user 20227 Oct 10 16:48 2009-A-parse1p.lisp
8 -rw------- 1 rem user 6738 Oct 10 16:37 2009-7-web1.lisp

;Previous2 upload, start of previous2 session:
30 -rw------- 1 rem user 29601 Oct 8 00:18 2009-8-MUPK.lisp-old
11 -rw------- 1 rem user 9990 Oct 8 00:07 2009-A-subcurl.lisp

;Previous3 upload, start of previous3 session:
3 -rw------- 1 rem user 2180 Oct 7 14:13 topHelpText.dat-old2


diff topHelpText.dat-old topHelpText.dat | wc
2 8 70
diff 2009-3-NestAL.lisp-old 2009-3-NestAL.lisp | wc
53 339 2749
diff 2009-9-geo2.lisp-old 2009-9-geo2.lisp | wc
79 549 4252
2+53+79=134 lines of code (subtotal)

diff 2009-6-sgxmlp.lisp-old 2009-6-sgxmlp.lisp | wc
21 133 995
diff 2009-9-geo2.lisp-old 2009-9-geo2.lisp | wc
79 549 4252
diff 2009-3-NestAL.lisp-old 2009-3-NestAL.lisp | wc
53 339 2749
diff 2009-7-sgxmlp.lisp-old 2009-7-sgxmlp.lisp | wc
49 363 2459
diff ~/Trash/topHelpText.dat-old2 ./topHelpText.dat-old | wc
46 189 1577
21+79+53+49+46=248 lines of code (subtotal)

diff 2009-3-sgxmlp.lisp-old 2009-3-sgxmlp.lisp | wc
107 721 5243
diff 2009-9-geo.lisp-old 2009-9-geo.lisp | wc
95 639 4829
diff 2009-5-sgxmlp.lisp-old 2009-5-sgxmlp.lisp | wc
77 626 4096
diff 2009-8-MUPK.lisp-old 2009-8-MUPK.lisp | wc
15 55 575
diff 2008-7-Code.lisp-old 2008-7-Code.lisp | wc
15 63 488
diff 2009-A-parse1p.lisp-old 2009-A-parse1p.lisp | wc
216 1559 10620
diff 2009-7-web1.lisp-old 2009-7-web1.lisp | wc
23 133 933
107+95+77+15+15+216+23=548 lines of code (subtotal)

diff 2009-8-MUPK.lisp-old 2009-8-MUPK.lisp | wc
15 55 575
diff 2009-A-subcurl.lisp-old 2009-A-subcurl.lisp | wc
26 153 1147
15+26=41 lines of code (subtotal)

Grand total lines of code:
134+248+548+41=971 lines of code
(minus the 'diff' header lines,
but fairly/properly/honestly counting lines of inline documentation
which are just as important as the executable code)
plus throwaway code I needed for more extensive testing and operation,
so the two biases sorta cancel each other),
each line unit-tested before starting on next line of code,
each completed function composed of these lines unit-tested before starting
work on first line of next function,
and integrated application tested by actual use.
Time span from Oct 7 14:13 to Oct 11 22:22 = 4.33 days
Average 971/4.33 = about 220 to 230 LOC/workday.
So how does that compare with the average software engineer at rate
of writing and fully unit + alpha/integration testing LOC?
.

Relevant Pages

  • Re: I found an even easier way to crash CMUCL 19c/19f on FreeBSD 7.1
    ... I seem to remember you were using an UNIX shell account. ... new e-mail to your own computer at the start of the session, ... The version of Emacs here is horribly broken. ... Hmm, when I upload new versions of my source files, I keep around ...
    (comp.lang.lisp)
  • Re: Tam Lin podcast site
    ... The first screen is always a session on ... I sometimes use the Emacs scratch buffer for that, ... "Incompatibility Package" on TOPS-20 (there was the official ...
    (rec.arts.sf.fandom)
  • Re: Tam Lin podcast site
    ... you want to return to a suspended edit job and paste something you cut ... The first screen is always a session on ... As far as Emacs knows, ... "Incompatibility Package" on TOPS-20 (there was the official ...
    (rec.arts.sf.fandom)
  • Re: SIGHUP and Session leaders (was Re: Start scripts under linux)
    ... Set the variables in your shell equally. ... And note who is the session ... Why doesn't my process get SIGHUP when its parent dies? ... and one or more processes in the orphaned group are ...
    (comp.os.linux.setup)
  • Re: Detaching processes on VMS
    ... it is still a single session so you end up with dualing keyboards. ... >* Pull up a Unix shell window on your desktop workstation at the office. ... >* Run nethack or tetris for terminals until bored. ... Certainly the original designers of VMS would've been aware of it. ...
    (comp.os.vms)