soft-eng@MITRE.ARPA (Alok Nigam) (10/24/88)
Soft-Eng Digest Sun, 23 Oct 88 V: Issue 39
Today's Topics:
Ada Can Contest Deadline Extended
bar code systems for inventory and retail applications (2 msgs)
Centre for Software Maintenance
Cynic's Guide to SE #6: Forthcoming Revolt
Digital Mapping System request
EEG readers (was Re: Cynic's Guide to SE #6: Forthcoming Revolt)
References: tech. communication & SW development
Request for evaluations of Ready Systems products
Software Maintenance
What's a PC? (was Re: Cynic's Guide to SE #6: Forthcoming)
----------------------------------------------------------------------
Date: 17 Oct 88 10:20:33 GMT
From: sei!ajpo!eberard@pt.cs.cmu.edu (Edward Berard)
Subject: Ada Can Contest Deadline Extended
Due to demand, the deadline for the "Ada Can" contest has been
extended to December 31, 1988. All entries postmarked no later than
December 31, 1988 will be considered. Winners will be notified by
March 1, 1988.
"Ada Can" is an Ada programming contest consisting of ten problems
with cash prizes for the two best solutions for each problem. A total
of U.S. $7500.00 in prize money will be awarded. The Ada Can problem
set can be found on the Ada Software Repository, or a copy can be
obtained from Jenifer Lott, EVB Software Engineering, 5320 Spectrum
Drive, Frederick, Maryland 21701, phone: (301) 695-6960, fax: (301)
695-7734. Multiple copies of the Ada Can problem brochure are
available to qualified individuals and organizations.
Remember, if two or more similar entries are submitted for the same
problem, preference will be given to the earlier entry. So, submit
your entries early.
Ada Can Quote of the Week: "Hey! These problems are really hard."
-- Ed Berard
(301) 695-6960
------------------------------
Date: 19 Oct 88 02:15:25 GMT
From: wucs1!wuibc!gmat@uunet.uu.net (Gregory Martin Amaya Tormo)
Subject: bar code systems for inventory and retail applications
I am still in need of responses to how you implement software
developement at your place of work. 2 paragraphs is all I ask. I must
write the essay this weekend (10/22). I have had people who would like to
see the results, but no one as yet wants to contribute....
HELP!
David Deitch, Computer Connection
dwd0238@wucec3.wustl.bitnet
Fido 1:100/22
------------------------------
Date: 19 Oct 88 02:15:25 GMT
From: wucs1!wuibc!gmat@uunet.uu.net (Gregory Martin Amaya Tormo)
Subject: bar code systems for inventory and retail applications
I am still in need of responses to how you implement software
developement at your place of work. 2 paragraphs is all I ask. I must
write the essay this weekend (10/22). I have had people who would like to
see the results, but no one as yet wants to contribute....
HELP!
David Deitch, Computer Connection
dwd0238@wucec3.wustl.bitnet
Fido 1:100/22
------------------------------
Date: Tue, 18 Oct 88 16:54:44 EDT
From: reg@lti.com (Rick Genter x18)
Subject: Centre for Software Maintenance
Can someone send me an e-mail address for either M. Munro or M. Ward at
the Centre for Software Maintenance, University of Durham, UK? Thanks.
------------------------------
Date: 17 Oct 88 17:24:51 GMT
From: att!poseidon!psrc@bloom-beacon.mit.edu (Paul S. R. Chisholm)
Subject: Cynic's Guide to SE #6: Forthcoming Revolt
> But for program development? Can these small machines give the
> same support for large-scale projects? I saw a demonstration of
> the debugger for Turbo-Pascal, and I wasn't too impressed. Nice
> graphics, but it didn't seem to do better than the VMS debugger.
I don't know which TP debugger you saw, but several companies make
*good* ones. Borland's new Turbo Debugger (*not* the new integrated
debugger in TP 5.0 and TC 2.0) offers a multiple views of the
software: variables and expressions, code shown as C or assembler,
registers (CPU and math coprocessor), stack, breakpoints, program
output, and a log that breakpoints and such can write to. You can
break at a given line or instruction, or when a certain expression
comes true, or a certain variable gets modified. There are actually
*three* debuggers: one for vanilla 8088's and such, one for 80386-based
systems, and one for remote debugging of software running on a second
system. (There's also a programmable interface for hardware debugging
boards like Atron's and Periscope's.)
> Source-code control? Make?
Yes. Yes. And lint, and C++, and ksh, and awk, and vi, and emacs, and
nroff/troff, and TeX, and some Scribe variants.
But wait, there's more! Many (most?) of the new computer assisted
software engineering (CASE) tools are being written for desktop systems
(Macintoshes and high-end MS-DOS boxes). Even the mainframe COBOL
programmers are finding lots of tools for their eventual platform
running on PCs.
What's going on here? Companies that write software tools like writing
them for desktop systems, for three reasons.
1) There are a *lot* of these boxes out there. Literally millions,
even if you make a 286 or a 68000 your minimal requirement. So there's
a large customer base.
2) These boxes are *cheap*. Yes, a dumb terminal only costs $400.
But a 286 or 68000 system can be picked up for $2000-$3000. (And the
manager who buys such systems for his or her staff can buy word
processing software for a few hundred dollars more, making the PCs even
more cost effective.) So there's a large *potential* customer base.
3) The desktop platforms are reasonably standardized. Text-only
applications are easier to write for MS-DOS than curses, and lots
faster. Graphics applications for the Mac (screen and printer) are a
breeze. (Granted, the initial learning curve looks like a cliff.)
Graphics applications in the CGA/HGA/EGA/VGA world of MS-DOS are
tougher; third party libraries help ease the pain considerably. I can
write a graphics application for NeWS, and X, and Apollo; but the
graphics parts aren't going to share a lot of code. (And I've got
binary compatibility of executables, not just source code compatibility.
And a standard medium and format for distributing code and data.)
It's a lot easier to write a software tool for a big box than to
squeeze it into a little one. But it's a lot more *profitable* to
shoehorn such tools on to the desktop. That's what a lot of companies
have done; and that's why PC programmers can get spoiled.
------------------------------
Date: 17 Oct 88 03:24:18 GMT
From: nic.MR.NET!shamash!nis!com50!dpmizar!swrinde!petro!rcm@ub.d.umn.edu (Ron C. McDowell)
Subject: Digital Mapping System request
(Please email replies to me or to midlyd!bob <see below for correct paths>)
Please forgive the posting to all these groups, but the question doesn't really
seem to have a home:
) Our county is looking into buying a Digital Mapping System.
) I would like to talk with someone who has experience with
) working with such a system on the Unix/Xenix OS.
)
) Robert (Bob) Pitts TELEPHONE: 803 332 1511 / 800 845 4118
) MID-LYD Systems UUCP: ...flattop!midlyd!bob
> P O Box A ...uunet!dpmizar!petro!midlyd!bob
) Lydia SC 29079-0158 ...gatech!hubcap!midlyd!bob
Thanks,
Ron McDowell @ Programming Consultants +1 512 655-3716
4418 Monaco rcm@flattop.UUCP
San Antonio, Texas 78218-4339 {uunet!dpmizar|gatech}!petro!flattop!rcm
------------------------------
Date: 21 Oct 88 00:45:08 GMT
From: sm.unisys.com!aero!venera.isi.edu!lmiller@oberon.usc.edu (Larry Miller)
Subject: EEG readers (was Re: Cynic's Guide to SE #6: Forthcoming Revolt)
>> My personal belief is that first you get the underlying foundation
>>right, then you add mice/windows/data_gloves/eeg_readers/etc... [snip]
> ^^^^^^^^^^^
And there follows a discussion of having heard about such things.
Work along this line was funded by ARPA at several locations about a decade
ago, including espcially UCLA and Illinois. The most successful work was by
J. Vidal at UCLA:
%A Jacques J. Vidal
%T Real-Time Detection of Brain Events in EEG
%J Proceedings of the IEEE
%V 65
%N 5
%D May, 1977
%P 633-641
------------------------------
Date: 21 Oct 88 20:38:40 GMT
From: ll@sei.cmu.edu (Linda Levine)
Subject: References: tech. communication & SW development
In preparation for writing curriculum material on technical communication,
we are looking for references that bridge software development and technical
communication. Here are a couple of examples of the kind of thing we're
after:
Richard Walton & Diane Balestri. "Writing as a Design Discipline: Exploring
the Relationship Between Composition and Programming." Machine-Mediated
Learning, vol.2, no.1 & 2, 1987, pp.47-65.
John Lehman. "Program Design and Rhetoric." IEEE Software, May 1986, pp.71-73
Please note: we're not only interested in design issues but in the many
possible connections between software development and the process of
composing-- including process models, planning, writing, testing, etc...
If you know of any similar or related materials that might be useful for us,
we'd be grateful if you'd send e-mail to ll@sei.cmu.edu.
------------------------------
Date: 17 Oct 88 18:04:01 GMT
From: njsmu!telesci!howell@princeton.edu (Douglass J Howell )
Subject: Request for evaluations of Ready Systems products
We currently use Ready Systems VRTX product (a very old
release). We are contemplating upgrading to their new
VRTX32 product line and its assocated tools:
VRTX32
MPV
TNX
IFX
RTsource
RTscope
Hyperlink
CARDtools
C
I would appreciate receiving evaluations of these
products by people who have knowledge of them. If
enough interest is shown, I will summarize & email
the responses
------------------------------
Date: 19 Oct 88 20:34:48 GMT
From: phoenix!pucc!EGNILGES@princeton.edu (Ed Nilges)
Subject: Software Maintenance
I am looking for network discussions on software maintenance. Is
there such a group (I've checked the help info, no luck). Or is
this a good conference for issues of maintaining software?
------------------------------
Date: 15 Oct 88 23:15:07 GMT
From: garfield!john13@uunet.uu.net (John Russell)
Subject: What's a PC? (was Re: Cynic's Guide to SE #6: Forthcoming)
>I don't
>have much respect for PC make facilities especially since a PC has limited
>concurrent execution powers to allow for the nested makes needed for the nested
>directory structure.
That isn't necessarily true of all PC's (personal computers, as opposed to
"IBM PC" which is what most people consider PC to mean).
An Amiga has concurrent execution powers limited only by available memory. You
might be able to fill up available memory, although it's no problem to make
heavily used executables resident (ie only one copy of executable code for
multiple invocations).
I've been disappointed with mainframe performance ever since the end of the
summer, when the load average went back to real-world levels and my compiles
started turning into meal-breaks :-(.
------------------------------
End of Soft-Eng Digest
******************************