hyc@math.lsa.umich.edu (Howard Chu) (08/01/88)
Howdy again... I sent the 5.21b binaries to the binaries group a couple weeks
ago, but it looks like they haven't been posted yet. In any case, patches to
the original source posting are now winging their way to comp.sources.bugs
and comp.sources.d. If you're interested, go get 'em... Most of the changes
are only relevant for Unix users, and I've already described all the GEMDOS
specific changes in a previous posting.
--
/
/_ , ,_. Howard Chu
/ /(_/(__ University of Michigan
/ Computing Center College of LS&A
' Unix Project Information Systemsruss@percival.UUCP (Russ Schwartz) (08/02/88)
["Big Time Television, where two's company and three's an audience." - Max Headroom ] Since people seem to be porting ARC over to the ST and making mods to it anyway, why not add a buffer that allocates as much memory as it needs for the compressing/decompressing process so it will speed it up? There is a program (sharware) called DCOPY by Ralph Walden that does this very thing but it's attached to a menu driven shell that does a lot of other stuff I could do without. Anybody willing to try it? Russell Schwartz ["This is another fine myth you've gotten ...!tektronix!reed!percival!russ me into!" - Lar L. & Har D.] voice: 503-643-2786 BBS: 503-292-1321 (Sysop @ IBBS - FoReM Node #4 - 3/12/2400 - PCPursuitable)
hyc@math.lsa.umich.edu (Howard Chu) (08/03/88)
In article <1309@percival.UUCP> russ@percival.UUCP (Russ Schwartz) writes: >Since people seem to be porting ARC over to the ST and making mods to it >anyway, why not add a buffer that allocates as much memory as it needs for >the compressing/decompressing process so it will speed it up? > My intent was simply to port the MSDOS program, making as few changes as necessary to get a running program. The idea is to make everything look as much like the original as possible. Of course, we don't have people like Phil Katz writing 68000 assembly code for the ST just yet, so lumping in PKARC compatibility into this program seems like a reasonable thing. Gratuitous modifications probably aren't the way to go. At least, not if you're going to call your program "ARC" of any form or another. (Look what's happening with Katz - he's got a lawsuit to worry about now.) In any case, I'm not sure that a large buffer will be such a speedup. I'd expect that it buys as much speedup as simply using a large enough RAMdisk. Running my system on a 1.4meg RAMdisk, I can say that it's godawful slow. I don't think throwing more memory at the problem is the solution. >There is a program (sharware) called DCOPY by Ralph Walden that does this >very thing but it's attached to a menu driven shell that does a lot of other >stuff I could do without. > DCOPY is kind of nice. I still don't think the buffer buys too much, but what the heck. I think the basic idea is right - if you want it faster, rethink the algorithms, and code it in assembler. I haven't had time yet to look up all the background theory & such behind it, though I plan to. So far I've paid as little attention as possible to the fundamentals, trying to locate all the nitpicky superficial details. Ralph Walden seems to have the background down. I bet it's not going to be long before we see a new ARC-compatible utility for the ST that runs at a respectable speed. I agree on that point - I don't want all the other functions DCOPY has. Just a fast ARC... I've never been too eager to jump on it though, knowing there are other people out there already working on it. >Anybody willing to try it? > >Russell Schwartz ["This is another fine myth you've gotten >...!tektronix!reed!percival!russ me into!" - Lar L. & Har D.] >voice: 503-643-2786 > BBS: 503-292-1321 (Sysop @ IBBS - FoReM Node #4 - 3/12/2400 - PCPursuitable) Just a matter of time, I'm sure. In the mean time, it'd probably be a good idea to start thinking about more advanced archiving methods. I think the good ol' Unix(tm) tar & compress utilities are perfect. Port PDtar, latch onto a decent C compiler that can handle arrays of 320K and up, and hey - fast compression, plus full directory hierarchies. Something to consider, at least. ARC is nice, but it shows its CP/M heritage too well - designed for a flat filesystem. Sure MSDOS has evolved beyond CP/M now, but a lot of that design philosophy still shines thru, and it'd be a terrible thing to saddle down a sleek machine like the ST with that kind of anachronistic burden... -- / /_ , ,_. Howard Chu / /(_/(__ University of Michigan / Computing Center College of LS&A ' Unix Project Information Systems
ljdickey@water.waterloo.edu (Lee Dickey) (08/09/88)
Has anyone tried ARC 5.21b yet?
I notice that after every command I give, there I have to press
the carriage return key one more time, because there seems to be
an implicit "-h" (Hold) going on. Does anyone know how to turn this off?
--
L. J. Dickey, Faculty of Mathematics, University of Waterloo.
ljdickey@WATDCS.UWaterloo.ca ljdickey@water.BITNET
ljdickey@water.UUCP ..!uunet!watmath!water!ljdickey
ljdickey@water.waterloo.edu ljdickey@water.waterloo.edu (Lee Dickey) (08/09/88)
In some article hyc@math.lsa.umich.edu (Howard Chu) writes: | In article <1309@percival.UUCP> russ@percival.UUCP (Russ Schwartz) writes: | >Since people seem to be porting ARC over to the ST and making mods to it | >anyway, why not add a buffer that allocates as much memory as it needs for | >the compressing/decompressing process so it will speed it up? | [ stuff deleted ] | ... In any case, I'm not sure that | a large buffer will be such a speedup. I'd expect that it buys as much speedup | as simply using a large enough RAMdisk. Running my system on a 1.4meg RAMdisk, | I can say that it's godawful slow. I don't think throwing more memory at the | problem is the solution. I think I agree. -- L. J. Dickey, Faculty of Mathematics, University of Waterloo. ljdickey@WATDCS.UWaterloo.ca ljdickey@water.BITNET ljdickey@water.UUCP ..!uunet!watmath!water!ljdickey ljdickey@water.waterloo.edu