cosell@bbn.com (Bernie Cosell) (03/20/90)
I'm about to plunge in again and try doing some Amiga development. I was actually one of the original A1000 developers, but I got put off by the apparently difficulty of the task --- not of the application I was thinking of doing, but of the difficulty of doing battle with the operating system, and so mostly gave up. Over the years I've occasionally flirted with diving in again, and here I am again... The documentation gets better and better, and so mostly I think it is not too hard any more to figure out HOW to write your application [contrasted with trying to puzzle out what was going on from the original RKM's... :-( I really envied those early devleopers for being able to figure out how to get ANYTHING done...]. BUT... the development environment still seems to be impenetrable, and I'd appreciate some advice on how to cope with it. It is hard to figure out quite how to ask this, but simply put the real question is: how do you go about doing the development/debugging cycle? My memories of the old days is that EVERY programming error resulted in either a crashed machine, or a hung-up one [or at the least, a hung-up task and you could no longer figure out what-happened-to-it]. Made for VERY painful, and S L O W, debugging. Are there tricks and techniques for making things smoother? As I recall, the two biggest problems with dealing with a slightly-sick program were: (1) whenever it died (or if you wanted to restart it), it had always a bunch of allocated stuff that now had no good way to get undone (e.g., windows and menus up, locks on directories, etc), and (2) whenever it died or stopped, it would leave one or more queues of un-replied-to messages in its wake. In my at-work environment, I generally do "three window" development: one window running an editor, one running dbxtool, and a third with a shell for general poking around, grepping, running make, etc. Seems to work very nicely. Of course, the Amiga can do all of that... BUT... if virtually every programming error requires a reboot to get the system flying again, the point of having an editor waiting, or a CLI sitting there is pretty moot. Is there some special way to organize your programs, or special tricks in the ways they're writter, or other little hints, that might help me out? Thanks!! /Bernie\ ps, just to make clear: I've worked in LOTS of different development environments over the years, and written LOTS of code: I probably don't need elementary-software-engineering advice [small modules, clean interfaces, etc, etc]. Even *given* a meticulous 'personal ecology', Amy seems to make for a prohibitively hostile development environment... /b\
djh@dragon.metaphor.com (Dallas J. Hodgson) (03/21/90)
I understand your note about 'development pain'. I can say that these four things have increased my development ability a whole HELL of a lot, and make things a lot less painful for us Amiga programmers. They are : 1) GOMF 3.0 (prevents most common-programming error GURUS & frees resources) 2) A hard drive. 3) RAD:, the recoverable ramdisk. 4) SDB, from Manx. (A source-level debugger that looks & feels like dbxtool!) +----------------------------------------------------------------------------+ | Dallas J. Hodgson | "This here's the wattle, | | Metaphor Computer Systems | It's the emblem of our land. | | Mountain View, Ca. | You can put it in a bottle, | | USENET : djh@metaphor.com | You can hold it in your hand." | +============================================================================+ | "The views I express are my own, and not necessarily those of my employer" | +----------------------------------------------------------------------------+
cmcmanis@stpeter.Sun.COM (Chuck McManis) (03/23/90)
When I develop applications I've been using Lattice C 5.0x and usually
have a copy of MicroEmacs (my own, not C/A's) running and a CLI window.
I have a Rexx command attached to F1 that saves all emacs buffers and
runs lmk redirecting the output into another buffer window so that I
can peruse the list of errors and fix them in my code. Pressing F2 runs
the application and pressing F3 runs the application under CPR the
Lattice debugger.
This is also possible with Lattice's editor LSE.
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: <none> Internet: cmcmanis@Eng.Sun.COM
These opinions are my own and no one elses, but you knew that didn't you.
"If it didn't have bones in it, it wouldn't be crunchy now would it?!"