[Coco] 3rdPart Editor

[Bill Gunshannon]

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