[Coco] 'arc' copy command and Stack Overflow (ERROR #207)

Tormod Volden lists.tormod at gmail.com
Mon Jan 26 16:16:04 EST 2015


On Mon, Jan 26, 2015 at 6:36 AM, Gene Heskett wrote:
> On Sunday 25 January 2015 22:57:06 Stephen H. Fischer did opine
> And Gene did reply:
>> Be careful, NitrOS-9 has changed some related things.
>>
>> My similar Archive program counted on the return code from Disk Full to
>> stop and tell the user.
>>
>> Upon changing the syntax for another utility I thought I was done.
>>
>> Then I discovered that the disk full error was not being returned to
>> the program.
>
> That is a pretty serious charge Stephen.  No coder in his right mind would
> remove that error return.
>
> What edition number is your in use rbf.mn saying it is?
>
>> Thus I needed to put a warning on my Colorful Sled text editor that use
>> with floppies or other small disks with little remaining space was not
>> advised.
>>
>> No where to report the problem, no one interested, no one to fix it.
>>
> Now days, this is the right place I think.  This is after all, a community
> maintained os, and we are the community.
>
> Humm, the rbf.mn in the level1 tree of my last pull back in Nov 2014is
> edition 26!
> But let me check if level2 is different, I don't think they should be.
> At any rate, this is too short by several pages of printout, and does NOT
> ever load an #e$Full error anyplace in it.
>
> Humm, this is better, the level2 version claims its edition 37, much more
> believable.
>
> But while the labels etc are the same as when I last worked on it, someone
> (ATD) now has comments all over, reverting some of my faster 6309 code for
> the slower original.  The diff is 8 machine cycles per instance.  Now,
> since there is no mention of anyone whose initials are ATD in the edit
> trail at the top of the file, who is ATD?

Gene,
Running
 hg log -p level2/modules/rbf.asm | less +/ATD
and typing ?^diff
shows that these comments were added in a commit in 2003.

hg log -v -r 1144

With the innocent commit message of "More comments". However it is
clear that this commit replaced most of the code...

hg log -p -r 1144

And from reading some of his comments, I see that Alan didn't approve
of your changes either, Gene :)
Funny way of communicating between developers back then.

>
> At any rate, the path to an exit from the time regs.b is loaded with
> #E$Full is quite convoluted.  Its getting loaded is the result of looking
> at the allocation map and finding no more usable storage space.  My quick
> checks do not see regs.b being used in the first 1 or two jumps after it
> has been loaded, but it is possible someone re-used regs.b, clearing the
> error.
>
> If you would like to help test, back up a few releases and find an edition
> 34,  move it into the current hg pull after renaming this one, and go back
> the the build root, do a make clean dskclean; make dsk.  Build a system
> disk using that one and then fill up a disk to overflowing.  If you do not
> get an #E$Full (hex $F0, decimal 240) return then its being thrown away
> someplace external to rbf.mn.

hg log -p level2/modules/rbf.asm | grep edition
searches for the edition changes in the commits. Looks like it jumped
from 30 to 35 in commit 1111.
To get to edition 30, get it from any hg revision before that:
Just to list the file:
hg cat -r 1110 level2/modules/rbf.asm
To change only this file back to that revision:
hg revert -r 1110 level2/modules/rbf.asm

After building and testing it out, you can play the file forward again
to the current revision:
hg revert level2/modules/rbf.asm

Regards,
Tormod


More information about the Coco mailing list