[Coco] 3rdPart Editor

[Gene Heskett]

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.
 
> 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.

> 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.

> bill



-- 
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>