[comp.sys.amiga] ARP-questions and more

d85_kitte@tekn01.chalmers.se (Kristian Wedberg) (08/24/88)

[munch away...]

Hi there!

For my first posting to the net I have the following questions:

What, exactly, is 'handler'-code?
In Dmouse, for instance, Matt Dillon has 'extracted' the handler-code,
but what is the benefit of that?

Secondly, what is the latest version of ARP?
I use version 1.1 release 2, but have a small problem with it. 
If you use a disk a lot, the disk-access gets slower since the files
tends to get chopped up in small pieces, scattered all over the disc.
Therefore, I sometimes do a 'COPY df0: to df1:' to reorganize the 
block-allocation. As it turned out, this didn't work very well with
the ARP copy-command.

My suspicions made me do some tests, and I copied a disc both with the
ARP copy-command and with the native Amiga-one. The latter made
directory-listings no less than 35% faster! The copy-command itself
was also some 10% faster, to boot. For the directory-listing I 
used 'DIR opt a df1:'.

Then what? I checked the block-layout with 'LIST keys ...' and things
like that which confirmed the fact that ARP-copy for some strange reason
juggles the files around a bit before writing them.


So, what gives? Is it a bug, a soi-disant 'feature' or is it already fixed?



						         Kristian Wedberg


!       !       !       !       !       !       !       !       !       !
! The above do represent the    !( Either a big ego, or a small firm.   !
!   views of SoftHouse HB.      !                    Take your pick :-) !
!       !       !       !       !       !       !       !       !       !

cmcmanis%pepper@Sun.COM (Chuck McManis) (08/24/88)

In article <142@tekn01.chalmers.se> (Kristian Wedberg) writes:
->Secondly, what is the latest version of ARP?
->I use version 1.1 release 2, but have a small problem with it. 
->If you use a disk a lot, the disk-access gets slower since the files
->tends to get chopped up in small pieces, scattered all over the disc.
->Therefore, I sometimes do a 'COPY df0: to df1:' to reorganize the 
->block-allocation. As it turned out, this didn't work very well with
->the ARP copy-command.

That is the latest version and yes there is a bug in the copy command.
The problem is that the ARP routine for reading all of the files in a 
directory sorts them first and then returns the list, so when they get
written to the new disk they aren't in a very good order. I've written
another module called HashSort() which sorts file in hash order to make
this problem go away. Should be in the next release.

--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.

dillon@CORY.BERKELEY.EDU (Matt Dillon) (08/25/88)

>What, exactly, is 'handler'-code?
>In Dmouse, for instance, Matt Dillon has 'extracted' the handler-code,
>but what is the benefit of that?

	Dmouse comes in two parts.  The 'Dmouse' executable and the
'dmouse-handler' which must go in L:.  The reason it is split up is
so that all the extra baggage needed to handle the command line, help
text, etc... is NOT made resident.  The 'Dmouse' executable sets up all
the structures, gives help, etc... then LoadSeg()s the 'dmouse-handler'
(leaving it in memory) and then exits.

	So the only thing that remains in memory is dmouse-handler, not
Dmouse the executable with all the option handling and help.

	There are other kinds of handlers.  For instance, a DOS device
like PIPE: and many others you see in the Mountlist reference handlers
in L: which do the 'meat' of the job.

				-Matt