Forum unknown
· Talk to the Trade
#BlitzDisk
15 messages in this thread
Last nite a friend asked me to come over and help him out with a problem he
was having setting up the BlitzDisk program he received with his FastFonts
disk. We had no problem getting it to work on his floppies but were never
able to get it to work correctly on his HD. He has a CLtd 24 meg. When we
entered the command suggested in the manual: "Blitzdisk SCSI.device DIRONLY
NOCHIP" the program terminated with the error message "Bad Number Input".
After some experimentation we discovered that the program wanted a number
after the Blitzdisk command, i.e. "Blitzdisk 1000 SCSI.device DIRONLY NOCHIP"
even though the manual seems to indicate that this is not needed and defaults
to 100 if not given. Now txe`the program seems to work….almost. It only
seems to buffer some directories on the HD and not others. The root directory
has about 85 entries in it and there is another directory that has about 185
entries. As you switch around between the different directories and ram:
sometimes they seem to be buffered and sometimes not. Changing the size of
the buffer doesn't seem to have any effect. Is there a limit to the number
of files it can cache in a directory? Or are we doing somethin wrong? Thanks
for your help.
Hmm, I don't have the manual we sent out with the FasgtFonts BlitzDisk
update, just the one with TxEd Plus … but indeed you do need to either use
the keyword "DEVNAME" preceeding the device name, or you need to specify all
the entries in order starting with the number of buffers … BlitzDisk uses
the ARP command line parser, and you can see the template using "BlitzDisk ?"
which will show you the order of keywords.
You should be able to get as many buffers as you've got RAM allocated, so the
directories should remain cached … however, if there is not enough RAM to
allocate all the buffers, they'll get recycled and you'll need to go back to
disk. I'm not quite sure why, but sometimes the filesystem seems to read
different blocks in when you do two DIR's for the same directory, so you'll
need to access the disk for a few blocks even if you do a directory for the
same place twice. After the second time it seems all of the blocks have been
read in.
…cheath
Cheath,
Just picked up TxEd+ two days ago. Nice program. Found a little 'bug-lette'
that I'm not sure you are aware of, and since I know you're working on a
bugfix/update, I thought I'd mention it. If it's known/fixed, just
disregard.
I'm writing an ARexx macro (using the full ARexx, not the demo). I tried to
set up a macro to the Return key (a better auto-indent for C coding). Found
that when I do a "status L" when the cursor is at the end of the line and
there is no LF entered at the end of the line, the variable RESULT is one
character too short. If I insert the new-line, then move the cursor back up,
the "status L" command returns the complete line. Looks like you are
assuming the EOL is there and returning 1-character less in all situations.
Hope this explanation is clear enough – if not, I'll try to recreate a code
fragment and upload.
Thanks…Bob
P.S. Any way to speed up the macro execution? This macro turned out to be
too slow to be usable, since it would be invoked much too often in the course
of heavy coding/typing.
Hmm, sounds like STATUS L doesn't know about EOF. Too late for the new
production run, but I'll look at it before I send out the update disks. I
'spect I never saw that because I tend to leave extra blank lines ahead of
the cursor rather than entering text directly at EOF.
For speed, if there is something you're doing a lot, you might consider
writing a customized module in C to handle the particular set of
manipulations; then use macro commands which perform larger pieces of the
job, such as grabbing a whole block of text with a couple of TxEd commands,
and then processing the block within your custom program, pasting the block
back when you're done. If you can think of new primitives within TxEd Plus
that would make it easier to create customized external programs, I'd like to
hear about 'em-
…cheath
Cheath,
The EOF thing sounds like the problem (I was always creating a 'new' file
when I was testing the initial attempts at the macro). It's not a real
'pressing' problem – just thought I'd pass it on.
As to writing the stuff in C – that's exactly what I was thinking I'd have
to do. I was thinking of creating an ARexx-style library to do the actual
processing, and then use ARexx as the glue between TxEd+ and my library
routines. I think that overhead would be bearable (although it may not be
bearable finding the time to do it 😎 ).
I don't think adding primitives into TxEd would help (at first think,
anyway). We'll just have to see what develops.
Thanks…Bob
Bob,
Another thing you might try to speed up macros — whereever possible, use a
"string file" for the entire macro program. This completely avoids the file
system — searching for and loading the program — and runs a lot faster.
For example, binding to a macro key could be
MACRO T "options results;status F;say result"
would run the entire string as a program.
-Bill
Bill,
That seems like a good idea for real short stuff that's pretty simple
linear logic. However, with more complex stuff, it's pretty cumbersome. The
macro that I tried to do (to implement an intelligent C-oriented auto-indent)
ended up being about 55 lines long with some fairly complex if statements. I
don't think the 'string' approach would work with that, nor could I read it
after I typed it in (assuming the buffer limit was that large).
In this case, I'll either have to live with the builtin auto-indenting in
Txed, which is better than nothing, or do a bit of C coding and use ARexx as
the interface glue. At least I'll have the ARexx macro as a good prototype
of what I'm trying to do — another advantage to ARexx.
..Bob
Bob,
Your point is well-taken — a 55-line macro wouldn't be very readable as one
long string file. ARexx would be perfectly happy processing it, tho,
provided it would fit in whatever buffer space TxEd+ uses for macro strings.
Bob,
Your point is well-taken — a 55-line macro wouldn't be very readable as one
long string file. ARexx would be perfectly happy processing it, tho,
provided it would fit in whatever buffer space TxEd+ uses for macro strings.
Bill,
That seems like a good idea for real short stuff that's pretty simple
linear logic. However, with more complex stuff, it's pretty cumbersome. The
macro that I tried to do (to implement an intelligent C-oriented auto-indent)
ended up being about 55 lines long with some fairly complex if statements. I
don't think the 'string' approach would work with that, nor could I read it
after I typed it in (assuming the buffer limit was that large).
In this case, I'll either have to live with the builtin auto-indenting in
Txed, which is better than nothing, or do a bit of C coding and use ARexx as
the interface glue. At least I'll have the ARexx macro as a good prototype
of what I'm trying to do — another advantage to ARexx.
..Bob
Bob,
Another thing you might try to speed up macros — whereever possible, use a
"string file" for the entire macro program. This completely avoids the file
system — searching for and loading the program — and runs a lot faster.
For example, binding to a macro key could be
MACRO T "options results;status F;say result"
would run the entire string as a program.
-Bill
Cheath,
The EOF thing sounds like the problem (I was always creating a 'new' file
when I was testing the initial attempts at the macro). It's not a real
'pressing' problem – just thought I'd pass it on.
As to writing the stuff in C – that's exactly what I was thinking I'd have
to do. I was thinking of creating an ARexx-style library to do the actual
processing, and then use ARexx as the glue between TxEd+ and my library
routines. I think that overhead would be bearable (although it may not be
bearable finding the time to do it 😎 ).
I don't think adding primitives into TxEd would help (at first think,
anyway). We'll just have to see what develops.
Thanks…Bob
Hmm, sounds like STATUS L doesn't know about EOF. Too late for the new
production run, but I'll look at it before I send out the update disks. I
'spect I never saw that because I tend to leave extra blank lines ahead of
the cursor rather than entering text directly at EOF.
For speed, if there is something you're doing a lot, you might consider
writing a customized module in C to handle the particular set of
manipulations; then use macro commands which perform larger pieces of the
job, such as grabbing a whole block of text with a couple of TxEd commands,
and then processing the block within your custom program, pasting the block
back when you're done. If you can think of new primitives within TxEd Plus
that would make it easier to create customized external programs, I'd like to
hear about 'em-
…cheath
Cheath,
Just picked up TxEd+ two days ago. Nice program. Found a little 'bug-lette'
that I'm not sure you are aware of, and since I know you're working on a
bugfix/update, I thought I'd mention it. If it's known/fixed, just
disregard.
I'm writing an ARexx macro (using the full ARexx, not the demo). I tried to
set up a macro to the Return key (a better auto-indent for C coding). Found
that when I do a "status L" when the cursor is at the end of the line and
there is no LF entered at the end of the line, the variable RESULT is one
character too short. If I insert the new-line, then move the cursor back up,
the "status L" command returns the complete line. Looks like you are
assuming the EOL is there and returning 1-character less in all situations.
Hope this explanation is clear enough – if not, I'll try to recreate a code
fragment and upload.
Thanks…Bob
P.S. Any way to speed up the macro execution? This macro turned out to be
too slow to be usable, since it would be invoked much too often in the course
of heavy coding/typing.
Hmm, I don't have the manual we sent out with the FasgtFonts BlitzDisk
update, just the one with TxEd Plus … but indeed you do need to either use
the keyword "DEVNAME" preceeding the device name, or you need to specify all
the entries in order starting with the number of buffers … BlitzDisk uses
the ARP command line parser, and you can see the template using "BlitzDisk ?"
which will show you the order of keywords.
You should be able to get as many buffers as you've got RAM allocated, so the
directories should remain cached … however, if there is not enough RAM to
allocate all the buffers, they'll get recycled and you'll need to go back to
disk. I'm not quite sure why, but sometimes the filesystem seems to read
different blocks in when you do two DIR's for the same directory, so you'll
need to access the disk for a few blocks even if you do a directory for the
same place twice. After the second time it seems all of the blocks have been
read in.
…cheath