From: Steve Judd (sjudd_at_ffd2.com)
Date: 2006-04-10 18:22:33
Hey Spiro,
On Mon, 10 Apr 2006, Spiro Trikaliotis wrote:
> BTW: You depend on $BA containing the number of the last accessed drive.
> If there was no access before, your routine fails.
Well, assuming that the program was loaded from somewhere is usually a
pretty good assumption...
However, with e.g. programs that survive a reset (like Sirius or Slang in
my case) I handle this problem elsewhere in the code. (I mean, it's not
as if that code snippet is a standalone program...)
> Why do you think that this one is slower? Have you done any
> measurements?
Well, because when I run it, it's slower :).
I don't know why. I've done very little with disk drives/communication.
> Of course, both of your sample have one "problem": They depend upon the
> error channel sending a CR as last character. Although they do,
> "theoretically", it would be clearer to wait until EOF is signalled.
Could be, I suppose. But I think it's pretty standard, and I haven't seen
it fail.
> Well, I tend to disagree again. Although this works, I would change the
> order: First CLRCHN, then CLOSE. It seems the "right" order to me to
> first "detach" from a file (sending UNTALK or UNLISTEN), and THEN
> closing it, than the other way around. Remember: If you close the file,
> from an API's point of view, you still are outputting to that file,
> although it is already closed.
Well, what if I've already called CHKOUT to output elsewhere?
But hey, if another way is more personally satisfying, and works, I say go
for it.
Wait, what are we talking about again? ;)
-S
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.