Forum unknown
· Utilities/Other Aps
MyCLI vers. 1.1
11 messages in this thread
This is just a caution about the MyCLI program floating around many BBS
systems. The latest release of it has apparently NOT been fully debugged, and
it has some serious problems when multitasking. 1) The program will take over
the serial port when the program is started IF the terminal option is on.
This, of course, prevents it's use with any other communications software,
since the modem is IMMEDIATELY disconnected from the phone line when this
happens.
2) For some reason, when running the program from a hard drive, the program
will crash WOrkbench, making it as if the LoadWB command was never issued.
This can be somewhat annoying, since it means a reboot. This has also been
noted at times when the hard drive is not even installed, so it is NOT the
hard drive driver or controller causing this problem.
A friend of mine wrote the MyCLI version 1.1, are you talking about the
version recently posted to People Link? If so, there are a few other
problems in that version – commands like Diskcopy, which access the keyboard
as in "Press RETURN to continue", will hang MyCLI if entered at the MyCLI
prompt. Normally, you should "RUN MYCLI", to leave a free, normal CLI task
around, and do those sorts of commands from there. The problems with the
serial port aren't the responsibility of my friend, Rick Wirch, since he
never touched that code – it was all in version 1.0, and he doesn't modem, so
he never updated it. BTW, a Manx version of MyCLI, which also cleaned up a
small leap year bug, was posted to People Link a few days ago, thanks to D.J.
James. Rick would like to see the new and improved versions, so he can play
Keeper of the Source, since the original author, Mike Schwartz of Mt. View,
CA, is not listed in the phone book. ??? I called the one Mike S. who was
listed, and he said he had gotten a series of calls about MyCLI. To a
non-computer person, these calls were quite amusing. Anyways, this program
needs to multi-task better, and maybe even merge in some of the Unix-like
shell that's been passed around. It needs version 2.0 to be really useful, I
think. I'll harass Rick about these bugs.
I believe that that's the one…..Supposedly ,there's a new one out (told to
me by HR Laser) that has some of the major bugs fixed. Will upload it
tonight.. as MYCLI.12. John
I believe that that's the one…..Supposedly ,there's a new one out (told to
me by HR Laser) that has some of the major bugs fixed. Will upload it
tonight.. as MYCLI.12. John
JOhn…..missed the opportunity to reply to your earlier post about online's
terrible capture buffer. Set the buffer size to 1K, instead of bigger than
64K. It will just keep appending the next K to the previous K, etc etc and
will not truncate what is already there on the disk, as if, for instance, you
set it for 64K, then capture a 70K file, you'll end up with only the last 6 K
of your file!!! as the first 64K goes into outer space. Try it with a setting
of 1K !!!
Harv: I re-read the section of the manual that deals with this, when I first
had trouble. The trouble is, I think in terms of buffers that ALWAYS spool
to disk. That's why it's a _BUFFER_, right? The documentation doesn't say
that a 64 K buffer won't spool to disk, so I assumed that it would. I still
think it's a bug. I'd rather have a buffer that size, so it flushed only once
in a while, especially since Online! seems to have severe
always-behind-updating-the-screen problems. This is evident in the long time
it takes CTRL/S to "stop" the flow of characters…
If you provide a filename when requested, the buffer will scroll to the disk
no matter what size buffer you have selected. The problem seems to be that
there is no double buffering, and/or a nak is not sent to the host while
OnLine! is trying to write to the disk. Since a larger buffer takes longer
to write, characters are lost. Using a 1K buffer, you'll get almost constant
drive writes, but you will get everything.
This problem was mentioned during Beta test (I was one of the testers, and I
among others complained about it). Why it wasn't resolved was never
explained.
If you provide a filename when requested, the buffer will scroll to the disk
no matter what size buffer you have selected. The problem seems to be that
there is no double buffering, and/or a nak is not sent to the host while
OnLine! is trying to write to the disk. Since a larger buffer takes longer
to write, characters are lost. Using a 1K buffer, you'll get almost constant
drive writes, but you will get everything.
This problem was mentioned during Beta test (I was one of the testers, and I
among others complained about it). Why it wasn't resolved was never
explained.
Harv: I re-read the section of the manual that deals with this, when I first
had trouble. The trouble is, I think in terms of buffers that ALWAYS spool
to disk. That's why it's a _BUFFER_, right? The documentation doesn't say
that a 64 K buffer won't spool to disk, so I assumed that it would. I still
think it's a bug. I'd rather have a buffer that size, so it flushed only once
in a while, especially since Online! seems to have severe
always-behind-updating-the-screen problems. This is evident in the long time
it takes CTRL/S to "stop" the flow of characters…
JOhn…..missed the opportunity to reply to your earlier post about online's
terrible capture buffer. Set the buffer size to 1K, instead of bigger than
64K. It will just keep appending the next K to the previous K, etc etc and
will not truncate what is already there on the disk, as if, for instance, you
set it for 64K, then capture a 70K file, you'll end up with only the last 6 K
of your file!!! as the first 64K goes into outer space. Try it with a setting
of 1K !!!
A friend of mine wrote the MyCLI version 1.1, are you talking about the
version recently posted to People Link? If so, there are a few other
problems in that version – commands like Diskcopy, which access the keyboard
as in "Press RETURN to continue", will hang MyCLI if entered at the MyCLI
prompt. Normally, you should "RUN MYCLI", to leave a free, normal CLI task
around, and do those sorts of commands from there. The problems with the
serial port aren't the responsibility of my friend, Rick Wirch, since he
never touched that code – it was all in version 1.0, and he doesn't modem, so
he never updated it. BTW, a Manx version of MyCLI, which also cleaned up a
small leap year bug, was posted to People Link a few days ago, thanks to D.J.
James. Rick would like to see the new and improved versions, so he can play
Keeper of the Source, since the original author, Mike Schwartz of Mt. View,
CA, is not listed in the phone book. ??? I called the one Mike S. who was
listed, and he said he had gotten a series of calls about MyCLI. To a
non-computer person, these calls were quite amusing. Anyways, this program
needs to multi-task better, and maybe even merge in some of the Unix-like
shell that's been passed around. It needs version 2.0 to be really useful, I
think. I'll harass Rick about these bugs.