#Access! .28 Bug'
24 messages in this thread
Keith,
Found another gotcha in Access!. It appears you do not check memory
allocation status when downloading. I was trying to pull down a file on a
small memory Amiga last night, and everytime I ran out of memory the system
crashed.
I can't comment on your technique since I don't know what it is. But if
you're doing AllocRemember() (or AllocMem, of course), you might check the
status each time you ask for a new block and, if you run out of space, dump
the buffer to disk and start anew. This lets a two meg user download an
entire file with only one disk access at the end, yet lets a person with
only 1K free download using a disk write for every sector.
Rick
P.S. There is also a flake in switching from full screen to SPLIT mode; in
some cases the bottom margin is not properly set, and the cursor (and text)
goes right past the bottom gadget strip. Haven't had it happen enough to
give you a repeatable technique yet, but thought you should know.
Richard,
You are correct, (as stated in the doc file) that version DOES try to dload
the ENTIRE file to a buffer before saving to disk. I'll fix that for in the
next
release. (that is only on the QB protocol dloads)
You are not the first person to mention the flake in switching from SPLIT (I
guess you mean CHAT ?) mode and back. (about the cursor ending up behind the
Gadget bar at the bottom of the screen in the bottom window)
Do you use "MoreRows" or something like that? what machine/setup are you
using?
I have NEVER seen that happen and feel that it must have to do with either a
different machine or some other program running that I am not. If you can shed
any light on this problem, please do. (btw, you don't have a PAL machine do
you?)
Thanks,
-Keith
Keith,
No, I do NOT mean CHAT, I mean SPLIT. I wanted to do some CLI stuff without
flipping windows, so I went to SPLIT mode.
I do not use MoreRows. I tried it ages ago, but it seemed to slow the text
output down tremendously (or somesuch, I forget exactly), so I threw it out. In
fact, due to problems I am currently running 512K, which means most of the
tasks I'd normally have sharing the machine were absent. At the MOST, I would
have had RSLClock running, and I don't even think that was up. And no, I don't
have a PAL machine.
The few times I've seen it, the cursor was in the upper half of the screen and,
when I invoked SPLIT, the cursor either stayed "up" there (I.E. became
invisible since SPLIT in effect shows the bottom half), or is on a half-line,
half hidden by the upper gadget bar. Hit return until it comes onto the screen
and everything LOOKS okay… except it doesn't stop when it gets to the bottom
gadget bar.
I'll keep an eye out and gather more information for you next time it happens.
Rick
Richard,
OK, OK! <grin> I did not mean to sound like I was disputing your observation,
I was just unclear as to what the problem actually was. Now that I understand
the situation better, I'm afraid I still haven't seen that but I have a better
path to follow to try and track it down.
Basically this is what happens in 'SPLIT' mode: all the window sizes are reset
to 'non-interlace' size (i.e. 640*200-the size of the gadget bar (and that
might be where the problem is)), then the screen is moved down half-way to
expose the WB screen (or whatever screen happens to be there).
Thanks for taking time to report this problem and I WILL look into it.
-Keith-
Hehe… sounds like you read an irritated tone into my posting which wasn't
there. If I say "NO D*MNIT!…", you can figure I'm mad. Otherwise, read it
in a conversational tone. 8)
As I said, I'll let you know if I get more info, but it does happen rarely.
Rick
Hehe… ok, just wanted to be sure I was not affending you (or anyone else for
that matter) I'm generally an easy going guy.
-Keith
Me? Nah. I don't offend. It's against my religion. 8)
Rick
Keith,
I've noticed another problem with .28 which did not occur in earlier
versions: I use fastfonts with my own font, and menus show up in topaz which
is not what I have selected. Version .26 worked fine and my font replaced
topaz universally.
Thank you,
Fred Schuchman
Fred, yes I believe I did start specifying a font for the windows, I had not
used any of the font utilities and so did not notice the change. I will be
working on loadable fonts and such in the future and until then will remove the
specifier so that you can use your Fastfonts again. Thanks for the report,
-Keith
Try CoComm; doesn't use ram buffer :^) Hi Keith <grin>
A BIG drawback to Cocomm — it's slow because of disk access in it's QB
protocol. It should probably do SOME ram buffering — at least 4k or so.
Steve – just send it to ram. then it's not slow, works fine. I offer the option
– it's a better way to go. –Ben–
"Better" is a relative term.
Rick
Also…. (thinking about it) at 1200, for instance, where 99% of everybody
uses it, it can hit df0: here with no slowdown that _I_ can see. <grin> at
2400, probably, but as I say, stick it in ram or vd0 or etc.AND…. it DOES
buffer about 4k; that's the size of the input serial buffer; and since the
ack are sent ahead, serial stuff comes in even if cocomm's busy. You might
want to be specific about the conditions under which CoComm is slow,
compared to the conditions under which Access is fast; IF I've missed
something, (Which is entirely possible, not having 2400 baud to test with)
I'll certainly fix it. I would consider it a problem if the QB was slower
than the QB in Access, given that my QB was directed to RAM: (Yech!) or
VD0: (Yay!) Considering that (I believe) Access is simply writing to ram
anyway. –BEn–
Ben, problem is for people who don't have much ram to spare and are forced on
big downloads to go to disk. Still lots of people out there with only 512K.
Marlene
MArlene – I know – I assume (and correctly, I bet) that people with 512k
machine don't go downloading the big files very often; A quick search of the
DLs tday revealed that most big files ALSO include the following (or like it):
Warning! Will Only Run with 1 Megabyte or More!…. Which kind of limits it. If
you DO have the memory to run these things, then, generally, you can direct the
DL into it. A variable ram buffer has other problems, too; But I will consider
it. –Ben–
CoComm is so BLOATED it won't FIT in my current system, which is limited to
512K because of contention problems. So THERE! 8P
Rick P.S. Besides, I can keep up with Keith's updates.
hehehehehe
What the heck are you putting in RAM: or VD0: that couldn't be out on that
speedy HD?
Regards, Larry.
See my note to Ben elsewhere: I was joking about that part of the message.
Although it's getting close; with two drives and an interlaced screen there's
only about 200K free on a 512K machine. I had to drop back to one drive and
non-interlaced (yuck) to be able to do anyting useful.
Come on chips, GET here already! 8)
Rick
Ahh… well, if you are going to squander your CHIP ram and eyesight on
interlaced screens, I can see how you would resent doing anything useful with
it. <grin>
Regards, Larry.
That's alright, Larry. While you're madly flipping around in your editor or
reissuing LIST commands because what you want is just off the screen, I'm
sitting here happily seeing all of it in one byte, thank you very much. Come to
think of it, that's a lot of excess wear and tear on your mouse and keys.
Besides, when the 1M chip RAM arrives, you'll have to figure out how you're
going to use the extra 512K. I already know. Thinking ahead: that's the whole
idea. <Tapping temple with forefinger, grinning tongue-in-cheek smile>
Rick
Ahh…
i think we found the operative word… "seeing"… while you are "happily
seeing it all", i am not seeing it without great difficulty unless it is
uninterlaced. I justdon't think the monitors I can afford are up to snuff.
Regards, Larry.
THAT'S weird… because I'm using a 1080, which is decidedly NOT a high class
monitor. Maybe I just have a higher tolerance level?
Rick