Re: cc65 and "Hello World"

Bill Buckels wrote:
On Apr 17, 12:43 am, "Michael J. Mahon" <mjma...@xxxxxxx> wrote:
I've never seen a software development that didn't rely on some
such process. The alternative is to hold back releasing new bits
until they are thoroughly tested, but then the testers don't get
them--a contradiction in terms.

If you say so. So what's your hurry? Here's some more tunnel vision
again...

I could perhaps see a complicated build process for a large project
like a portfolio management application which hosts quote services and
an order entry system. Or if a large team is required.


Anytime you have more than one developer on a project, uncalculated interdependencies arise. Even then, outside forces can impact a project - upgrade to Vista lately? Automated builds are just one of the easiest to implement sanity checks. Why wouldn't it be part of the project process?

For a compiler project I cannot see this. Perhaps I have missed an
important understanding of what is going-on here. There is a working
compiler, assembler, linker, and library manager. Perhaps there is a
debugger and perhaps the linker allows the embedding of debug symbols,
and perhaps one can attach, detach, trace and step through in the
debugger. Perhaps not. If not this is of a relatively simple scope.

Change management starts at the top. The rationale for a change is
documented and reviewed. A risk benefit analysis is performed and if
the change is approved it is scheduled for a particular release.
That's of course part of the quality plan.

Regardless, there is no real need to provide QA with a product for
system testing and "black box" testing until the programming on a
particular unit is done, until the tracing and test harness have been
performed and until the code walkthrough has been done. In fact the
changes should not be checked-in until that is accomplished.


Nobody claims this process shouldn't be done. I commend you for putting in place proper unit testing and management. Still, the scope of a project shouldn't really affect the process by which it is developed.

CVS is not ideal for this level of change control and RCS is probably
better in some ways using strict locks.


No source control program is ideal, but anything is better than nothing. I have yet to find one that easy to use, unobtrusive, and cross platform.

Therefore development builds from scratch and gets the latest checked-
in code which is stable and makes changes to a stable codebase.
Development does unit testing based on a test frame and test scripts.
If regression testing is required it is done at that level first. The
boundary and equivalence tests are determined in the test script and
the test frame reflects the individual sets that need to be performed.

After development have released the tested and finished latest changes
to QA by way of a release, the high level and system testing and
finally acceptance testing on behalf of the user is done. It is then
and only then after this process is completed that a release candidate
should be available for alpha or beta.


It depends on what you mean by way of a release to QA. If QA doesn't see something until the developers think they have a release candidate, there will probably be some time lost sorting out some basic issues. Developers are notoriously bad end-users of their product. How many times have I heard "it works on *my* machine". A simple, timely regression can reduce this sorting out. Just installing and launching the product can work out the most egregious errors quickly.


The development and testing of libraries and library routines is
completely independent of the development and testing of a binary
executable in a project like a compiler. In fact link libraries and
headers can be considered "baggage" independently from the compiler
itself and its core binaries.


Most link libraries *are* built by the compiler. The interdependencies are high and just the reason you want daily builds for a quick sanity check.

Tools and utilities too can and should be considered separately.


The end user rarely does.

So major achitectural changes to a compiler should not be mixed with
minor changes to link libraries.


See above. Major architectural changes usually indicate changes to the link libraries.

A product lifecycle is part and parcel of all of this. So is
documentation.

Now anyone who wants to compare a properly managed change control
system and properly isolated developement, QA, and production areas
which is what I prefer, with some sales guy who walks over to a
development machine and raids it...


Sorry to hear your funnybone is broken. But, believe it or not, it has happened. A desperate PM would have to send something for customer review and grabs something they see working. Customer complains that something doesn't work. What's the build number? Whatever was on Jim's machine. Aaarrrgggghhhh.

Well I promised Oliver I would be nice, so I'll just say this and be
on my merry way...


Why would you have to promise to be nice? Wouldn't you just want to be?

If anyone here doesn't think I fully tested every aspect of each of
the compilers that I made available from the Aztec C Website before
releasing them for download then they have not used what I put online.
Hey this stuff was really hard to find and put together and to write
the scripts and write and compile the pieces that weren't there and so
forth. I couldn't sluff it.


I don't think anyone thought that.

So I am not standing in a glass house throwing stones. I am not even
throwing stones except really soft ones and really just asking why are
you doing it this way???

Also if anyone thinks this Aztec C stuff that I talk about is native
mode and not cross-compiler well then they haven't looked. Suggesting
that I read your labels when you haven't looked at my work is somewhat
interesting to say the least...


Again, I don't believe there was any confusion here. My point is that this is one of the few compilers that also has a native implementation. That is rare, and of value to me.

The Aztec C for the Apple II, Commodore 64, and CP/M 80 (8080 and Z80)
and CP/M 86 are all available in cross-compilers and in native mode
compilers. Download them and look.

The level of ANSI compliance is relative to the compilers of course,
but since Aztec C was until Microsoft pushed them out of existence a
leader in embedded systems and cross compilation, as well as providing
floating point support, this should not be discounted as a poorly
written or less capable development environment for 6502 based
machines nor for Z80 or 8080.


I don't think anyone is discounting Aztec C. I don't run MSDOS or Windows so I can't really try out the cross compiler.

In fact this is the one to match if you are serious about meeting some
standards of excellence.

That assembly pass is really good with these. A person could reverse
engineer that back to an ANSI compiler without too much thought but it
will be easier with the source.

As far as other compilers and Z80 stuff and so forth you should see
the constant volume of my email on all of this over the years. Yes
there are lots of great compilers out there. My new favorite is
Digital Mars by Walter Bright. (The D Programming Language is
interesting too) And speaking of great distributions...

My distributions are also a good example to follow, because one click
and good examples are always appreciated by end users who may not be
interested in how you are making the compiler. They are more
interested in how they can use it to make their own programs.

As far as reading some label or another, oh well, that is your thing
not mine. Why would an experienced developer even look at something
that doesn't work? To fix it? Got lots of my own stuff to fix... not
looking for more broken stuff. By the same token someone else migh say
why look at old stuff when I got new stuff...


I dunno, 'cause they want to? Why would someone want to update a 20 year old compiler ;-)

Regards,

Bill Buckels

PS - when I get the source for all this and talk to some of the guys
who moved Aztec C to ANSII I'll be doing the Apple II stuff first
because I understand because I have been told by those who were there
that it was almost already finished ANSII-able ready.



Would you know how Aztec C is built, i.e. does it compile itself? It would be nice to be able to build for other environments (Linux, Mac). Looking forward to it,

Dave...
.

Relevant Pages

  • Re: cc65 and "Hello World"
    ... For a compiler project I cannot see this. ... The development and testing of libraries and library routines is ... releasing them for download then they have not used what I put online. ... Also if anyone thinks this Aztec C stuff that I talk about is native ...
    (comp.sys.apple2.programmer)
  • Re: cc65 and "Hello World"
    ... For a compiler project I cannot see this. ... The development and testing of libraries and library routines is ... releasing them for download then they have not used what I put online. ... Also if anyone thinks this Aztec C stuff that I talk about is native ...
    (comp.sys.apple2.programmer)
  • Re: K&R C?
    ... Aztec C is a better compiler since smarter people wrote it, ... there is a reason for you beeing the only aztec-c user. ... Der Zyniker sieht die Welt wie sie ist, ...
    (comp.sys.cbm)
  • Re: Apple II 6502 Applications in C - Recent Applications (Last 2 Years)
    ... are adament that Aztec C tool is unusable which is where much of this mirrored nonsense that you see part-of orginates from in the first place. ... Aztec is a fine native Apple II K&R C compiler, with many features to ... to listen in for a while to check the tone and content before jumping ...
    (comp.sys.apple2.programmer)
  • Re: Apple II 6502 Applications in C - Recent Applications (Last 2 Years)
    ... swipe at Aztec C, particularly anyone from any "cc65 camp". ... Aztec is a fine native Apple II K&R C compiler, with many features to ...
    (comp.sys.apple2.programmer)
Loading