|
|
| Author |
Message |
| 25 new of 156 responses total. |
scg
|
|
response 87 of 156:
|
Feb 5 16:37 UTC 1999 |
I use vi. It works well for me. I really don't have a reason to use anything
else. If other people feel a need to use emacs, that's fine with me.
|
janc
|
|
response 88 of 156:
|
Feb 5 18:27 UTC 1999 |
Re: cmcgee
None of those seem to be exactly bbs problems. All of them seem weird.
Overprinting the bottom line of the screen could be either:
- Grex has got your terminal settings messed up, so it thinks it
should be sending you carriage returns, but not line feeds. This
could happen if some program you ran previous crashed in an ugly
way and left your terminal it a bad mode. Easiest solution is to
log off and on again.
- Your terminal settings on your communications program are in a real
odd state. This is less likely, but in some cases it could happen
just by have a strange control sequence set to your terminal.
Easiest fix is probably to exit and restart your comm program.
The word wrap not working could be related. Or not. Some possibilities
are:
- For some reason you aren't running "gate". Picospan itself doesn't
have automatic word wrap. You always have to type returns. If
word wrap normally works for you, it is because there is a separate
program called "gate" that is collecting your text, and will pass
it to Picospan when you are done. If you somehow fell back into
the built-in Picospan text collection, you'd lose word wrap, and
have buffer overflow problems. I can't imagine why you wouldn't
be running gate though. It is configured into your account.
- Maybe you were running gate, but when it tried to word wrap (by
sending a carriage-return/newline) it wasn't working because either
Grex or your terminal program wasn't dealing with carriage returns.
This doesn't completely make sense to me, because you shouldn't see
buffer overflows in that case.
So basically, I don't know what was going on, but I'm reasonably
confident that it won't happen the next time you log in. Seems like
something got into a really bad state, but that usually doesn't carry
from login session to login session.
|
remmers
|
|
response 89 of 156:
|
Feb 5 18:56 UTC 1999 |
(Since others have posted their two cents re vi vs. emacs, I'll add mine
but promise to say nothing further about it in this item.
For short editing jobs, I use vi. For largish programming projects involving
multiple files and frequent recompiles, I much much much prefer emacs, for
reasons that I won't go into here.
When I'm in emacs and want to do something that vi is especially good at, I
just switch emacs into vi emulation mode for a bit (takes one keystroke),
then back to native emacs.
Also, I like emacs' X Window interface - supports mouse and multiple frames
quite nicely.
Oh then too, I use emacs for reading usenet news. It contains a nice threaded
newsreader.)
|
anderyn
|
|
response 90 of 156:
|
Feb 5 20:55 UTC 1999 |
I use emacs because it's what I first learned and I can use it without
seeing the keyboard. I also use it as my mail-reading program and have
used it as my net.news reader, but don't now, since I only can read
net.news through dejanews... It's a pain to learn, I have found, but
it's instinctive to me, now, and I don't like vi, or anything else.
|
dang
|
|
response 91 of 156:
|
Feb 5 21:48 UTC 1999 |
I use vi, because I learned it first. I learned it first because it's
more standard, more common (Yes, it was at the time. We didn't have
emacs), and easier to learn. I use it now because I know it very very
well, emacs doesn't do anything I want that vim doesn't (including nice,
colored, mouse, splitscreen X interface), and emacs is *still* a pain to
learn. However, this isn't a vi/emacs item, is it?
|
cmcgee
|
|
response 92 of 156:
|
Feb 6 00:52 UTC 1999 |
Thanks Jan. The first time I tried logging in again, nothing changed, but
the next time bbs worked fine. *shrug* Maxwell posited "daemons" sorting
molecules. I've always found that a workable theory. It explains a lot
of what happens with physics and other techie subjects like computers.
(Now Rane is gonna tell me it isn't daemons, it's really quarks)
;-)
|
rcurl
|
|
response 93 of 156:
|
Feb 6 05:28 UTC 1999 |
Maxwell posited those daemons to explain why they can't exist. Computers
have no such luck.
|
valerie
|
|
response 94 of 156:
|
Feb 7 21:46 UTC 1999 |
This response has been erased.
|
i
|
|
response 95 of 156:
|
Feb 7 22:49 UTC 1999 |
HURRAY!!! Thanks Jan & STeve!!!
|
steve
|
|
response 96 of 156:
|
Feb 7 22:58 UTC 1999 |
We verified that the new sun-4/690 CPU card was working, and took
64M off it and gave it to Grex, hence our 192M of memory. The 'new'
6/90 card wasn't booting in its normal (as opposed to diagnostic) mode,
so we took two of the little SBUS daughterboard cards off it, and lo
and behold it came up. We couldn't boot anything off it, as it seems
to have last been used with IPI disks (IPI being another now dead type
of disk interface like IDE and SCSI), so we're going to have to either
boot from CD rom or clone Grex's boot disk for it. Neither will be
hard to do, but we're out of time for today.
All in all, I'm happy. Grex has needed extra memory for a while
now, and todays addition will help out a lot. The extra CPU card
that we installed, giving us 4 CPUs that run Grex will be an interesting
thing to watch. There are some theories that with SunOS (as opposed
to the newer SOlaris) having four CPUs will degrade overall performance
because of contention between the four of them waiting to do things in
the kernel, but I'm not sure about that. I have heard arguments on
both sides, but Grex doesn't seem to use a computer in any normal way
so our results will be different. If we need to back out a CPU card
its easy enough to take it out again.
Next step: more disk for Grex.
|
scg
|
|
response 97 of 156:
|
Feb 7 23:07 UTC 1999 |
We have two new 690 motherboards. Did you try both of them, or just one?
|
steve
|
|
response 98 of 156:
|
Feb 7 23:31 UTC 1999 |
Just the newest one. To test the other one we'll need to do a
CPU transplant. I was kinda tempted to do that today, but decided
to be more focused.
|
janc
|
|
response 99 of 156:
|
Feb 8 03:27 UTC 1999 |
Doing a CPU transplant would be easy. But I think we'd also have to put
some memory on it, which is not so easy. I think we should concentrate on
the other one for now.
Anyway, for a vastly more detailed discussion of all this, see item:garage,
86
(That's item 86 in the garage conference for those of you not reading this
with Backtalk). That's probably also a better discussion place for techie
details.
|
aruba
|
|
response 100 of 156:
|
Feb 10 20:12 UTC 1999 |
Carol and I made some spiffy mailing labels with our new color printer.
They have Grex's logo and return address on them. I'll use them to mail
auction items to people.
|
remmers
|
|
response 101 of 156:
|
Feb 17 01:07 UTC 1999 |
The Grex Board of Directors will meet Tuesday, Feb 23, 6:30pm
upstairs at Zingerman's Next Door, 422 Detroit Street, Ann Arbor.
The public is invited. See item 75 in coop (item:coop,75) for
the agenda.
|
steve
|
|
response 102 of 156:
|
Feb 22 02:53 UTC 1999 |
I worked on getting more memory on Grex today, and didn't
succeed. The expansion card we have has 64M in it, and I was
going to increase that to 128M for a total of 256M in Grex.
Unforunately, there is a problem with some of the sockets
for the SIMM memory parts and Grex wouldn't boot with the
added memory. Going into the diagnostics mode it nearly
instantly found a particular SIMM as being bad. After trying
various things, I took out the new (2nd) 64M ram bank and
found that the card was still damaged. There are two sockets
which appear to be be damaged.
It definitely looks to me like we have some bad sockets,
possibly (probably?) due to problems with the previous owners
of the card. However, not all is lost. I've straightened out
the little finger of SIMM sockets before, and that may be all
that is needed.
Right now we're back to 128M, which while not as good as
having 192M, is still fairly decent.
|
remmers
|
|
response 103 of 156:
|
Feb 22 20:01 UTC 1999 |
REMINDER: Grex Board of Directors meeting Tuesday, Feb. 23, 6:30pm
upstairs at Zingerman's Next Door, 422 Detroit St., Ann Arbor.
The public is invited.
See Item 75 in the Coop conference (item:coop,75) for the agenda.
|
steve
|
|
response 104 of 156:
|
Feb 24 05:19 UTC 1999 |
Grex is now running with its memory card again, thanks to the
efforts of Charles (arthurp). He fixed the mangled simm sockets
and after some fighting with it, Grex was able to boot up with
this card. It now has 128M, making for a total of 256M of ram
here. Several of us have been here in the Pumpkin for the last
hour, waiting to see if any errors would develop. We've been here
for a little more than an hour now, and all is well.
Thanks Charles for your efforts.
|
aruba
|
|
response 105 of 156:
|
Feb 24 14:51 UTC 1999 |
Thanks Charles and STeve!
I'd like to announce that Kiwanis, through keesan and jdeigert, has donated
a photocopyier to Grex. It's in my office, on top of the file cabinet they
donated, and it seems to work fine.
|
steve
|
|
response 106 of 156:
|
Feb 24 17:12 UTC 1999 |
Wow. Thats cool.
|
remmers
|
|
response 107 of 156:
|
Feb 24 18:30 UTC 1999 |
Grex seems to be running along pretty zippily on 256M. Thanks to
arthurp and steve for their efforts!
Thanks also to keesan and jdeigert for the photocopier.
|
keesan
|
|
response 108 of 156:
|
Feb 24 19:47 UTC 1999 |
See the coop item on tax deductability of dues, this copier will allow grex
to keep better tax records as a nonprofit.
|
steve
|
|
response 109 of 156:
|
Feb 24 21:40 UTC 1999 |
The interesting part about that memoey is that we really are using it.
Watching the 'vmstat' program is fun; you can see when lots of sendmails
fire off, with the pool of available memory going down. We're doing a lot
less swapping right now, which is a good thing. I'm still on the lookout
for more ram, and once we have the alternate Sun-4/670 populated with 64M
ram, I'd like to get more memory here. ...I shall continue to beg for
ram. ;-)
|
janc
|
|
response 110 of 156:
|
Feb 26 18:21 UTC 1999 |
A test version of Backtalk 0.9.6 is now available on Grex. To try it go to
http://www.cyberspace.org/cgi-bin/pw/bt.new/pistachio/confhome?conf=backt
alk
IMPORTANT NOTE:
This has been deliberately broken so that you can only join the
"backtalk" and "backtalk2" conferences. It will claim all other
conferences do not exist if you try to join them. It does some
different things with item files, and we want to make sure it isn't
going to drive Picospan crazy before we allow it into any of the
regular conferences.
If you want to go back to reading the other conferences, change the
"bt.new" in the URL back to "bt".
WHAT'S NEW:
- HTML responses. You now have the option of using HTML tags in
your response and item text. This means pictures, tables, links,
font changes, and so forth can be done in responses.
Sanity checking is done on the HTML to make sure you don't use
any tags that would mess up the page, and to close any tags
you left open.
Backtalk automatically generates a (much less pretty) plaintext
version of all HTML responses so that Picospan users don't have
to look at HTML tags.
- Preview button. Lets you see what your response would look like if
posted, both to other Backtalk users and to Picospan users. Very
useful for composing HTML responses.
- Forget works better. Fixed some bugs here.
- A few more button color options.
- Updates to help files.
- More aggressive item indexing. Item indexing makes Backtalk faster,
but it used to be so timid about it that it wasn't being done in
most conferences.
- Several minor bug fixes.
And various other features not relevant to Grex: support for password
protected conferences, lastlog maintainance, better user list functions
(turned off here because we have too many users), and better Yapp
compatibility.
|
other
|
|
response 111 of 156:
|
Feb 26 18:59 UTC 1999 |
wow. sounds like te html parsing required a lot of work and will make
conferencing a whole new range of fun stuff! thanks, jan!!
|