[Coco] 3rdPart Editor

Mon Dec 17 20:47:23 EST 2018

On Monday 17 December 2018 20:10:52 Bill Gunshannon wrote:

> On 12/17/18 6:58 PM, Gene Heskett wrote:
> > On Monday 17 December 2018 14:38:15 Bill Gunshannon wrote:
> >> On 12/17/18 11:23 AM, Bill Pierce via Coco wrote:
> >>
> >> Bill, I don't think you understand...
> >>
> >>
> >> That's strongly possible...
> >>
> >>
> >>
> >> The makefiles present in the repo are NOT OS9 makefiles.
> >>
> >> I would have thought some were.  If not, why are there  no OS9
> >> valid makefiles?
> >>
> >> Doing everything on a PC and them moving it to the COCO may sound
> >> like fun,
> >>
> >> but what's the point?  If OS9 on a COCO is incapable of doing
> >> something as
> >>
> >> simple as building a line oriented editor then what is it good for?
> >> Hint: some of
> >>
> >> us don't see the COCO as a game machine.  I have an Xbox for that.
> >>
> >>
> >> They are for the make included in the Mercurial distro used to
> >> build the NitrOS9 repo on modern machines. None of the OS9 makes
> >> will work with those makefiles. In fact, the repo cannot be built
> >> at all under OS9.
> >>
> >> That is also pretty sad.  I know it would take a while, but to not
> >> be able to do it
> >>
> >> at all.....
> >>
> >>
> >>
> >>
> >>
> >> I also think you're over-estimating make and what it does. Make
> >> does not produce anything. All make does is scan for a given
> >> filetype (defined in the makefile) and recursively calls the proper
> >> module until all files are done. Make has very little in "commands"
> >> as the flags used in the makefiles are generated elsewhere in
> >> "rules.mak" or other makefiles or defs files. The flags pace
> >> through make are usually being passed on to the designated C
> >> compiler module. The macros created in the makefiles determine what
> >> program make calls for what file extention.
> >>
> >> I am well aware of what make does.  Been using for several decades
> >> now.  But my experience
> >>
> >> was with the one that came with the C Compiler and we (at least I)
> >> now know it is totally
> >>
> >> broken.  It was not issuing usable commands for the compiler and
> >> couldn't even handle
> >>
> >> the typical "clean" which does nothing but delete a handful of
> >> files. I will report back my
> >>
> >> luck with the newer one.
> >>
> >>
> >>
> >> Neither of the two makes for OS9 have extensive enough
> >> functionality to handle most of what's done in the repo (like ed).
> >>
> >> Seriously?  All it has to do for "ed" is compile a small handful of
> >> .c files to .r files and
> >>
> >> then compile the "main" file and link them.  Surely even the
> >> simplest version of make
> >>
> >> could handle that.  I guess we'll see.
> >>
> >>
> >>
> >>
> >> If you are having a problem building as simple, single C file, then
> >> I doubt make is the problem. You have probably not defined your
> >> build process in the makefile.
> >>
> >> No, make was the problem.  We'll see if the other one is better  if
> >> not, I may have to look for a different version (Minix maybe) and
> >> port it to OS9.
> >>
> >>
> >>
> >>
> >>
> >> And I was wrong... the docs for make are NOT in the C compiler
> >> manual. In fact, make didn't come in the C compiler package as make
> >> will not work in OS9 L1 due to 64k memory limits. Make came with
> >> the Level 2 Developer's System. You'll find make's description in
> >> that manual.
> >>
> >> I'll look for it but if others posting here are right, it won;t
> >> work anyway because it is bug ridden.
> >>
> >>
> >>
> >>
> >> And, while I have people's attention, here's a few other things I
> >> have run into since getting back into this.
> >>
> >> OS9 DSAVE -- for random and unknown reasons tries to recursively
> >> create directories.
> >
> > Your dsave src is at least 5 years out of date, I fixed it so an
> > existing directory is not an error at least that far back.
>
> I certainly hope not.  I just pulled everything down from the
> repository about a week ago.
>
> >> FORMAT (on the COCO)  I tried repeatedly to format my IDE disks.  I
> >> would type FORMAT /i0 answer all the questions as they came up and
> >> after usually an hour or more it would hang during the verify step.
> >> Tried a number of disks and tried /i1 as well.  Then, one morning I
> >> decided to give it one more shot but not wanting to sit there for
> >> an hour I used the form of the FORMAT command where you provide all
> >> the options on the command line having to only answer yes/no about
> >> it being a hard disk. Lo and behold, it worked.  That's how I  now
> >> have two disks /i0 and /i1 working on my COCO.  Makes a lot of
> >> stuff much faster.
> >
> > Thats because a hard drive newer than an mfm is permanently
> > formatted at the factory, so All the formatter has to do is install
> > an empty filesystem.  The disks just ignore the format instructions,
> > returning an ok after killing some time to convince the user its
> > doing something. Old mfm drives will, but the finer width tracks on
> > more modern ide/scsi and sata require special factory gear to format
> > or reformat them.
>
> That still doesn't explain why interactive doesn't work but non-
> interactive does.  It's the same binary.
>
> >> Not sure what else I will find but I have to admit to being
> >> surprised that bugs this obvious had never been run into by anyone
> >> else.
> >
> > The dsave bug about existing dirs has been fixed, by me, at least
> > half a decade ago. Compare your copy of makdir with the one from my
> > web page. Thats where the error is, so I fixed it in 2010. I'm now
> > trying to get the copy of it I copied to one of my /x descriptors
> > with drivewire, and if I can figure out how to run os9 copy, I'll
> > get it on my web page.
> >
> > This makdir will not kill dsave if the directory already exists. But
> > some one fam with the toolshed should tell me how to run os9 copy.>
> >
> > And I looked at Genes-os9-stf on my web page again, and found it,
> > its already there, the binary, the asm src in case somebody wants to
> > check and a makdir-README that fully explains the problem and the
> > fix. The web page is in the sig, so help yourself, replacing the
> > makdir your are swearing at.  If this version is not in the nitros9
> > repo, who ever does have write perms, please move it into the repo,
> > renaming the existing makdir.asm to makdir.asm-old in case somebody
> > is a diehard purist.
>
> Am I to assume then that the repo is not up to date?  That could pose
> somewhat of a problem.
>
> bill

At this point I'm uncertain. I was under the impression all this time 
that I had submitted that makdir you can get from my web page, to the 
repo but to hear/read you were having trouble with dsave's 
directory "recursion" you called it, made me go fire up drivewire, 
reboot the coco3/6309 and move a fresh copy to this machine, getting 
ready to give apache2 permission to serve it up, but it was only then I 
finally found it.  It had been there all along but my poor eyeballs 
couldn't see it. I don't have new glasses yet, so after cataract surgery 
I am not seeing the fine details like a 10 pt font on this 1920x 
monitor. Test your old one by trying to makdir /an/existing/dir. The old 
one won't hurt you, but it reports the 218 error to dsave, killing 
dsave. If it spits an error 218 at you, you have the fading & thinning 
grey haired version, replace it with the copy from my web page, it 
gobbles up a 218 and keeps on going.  So dsave sails right on by and 
keeps on going.

Which means your dsave scripts Just Work, again. It won't kill any 
kittens, or poison your goldfish...  :)

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>