SCOUG-Programming Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Wed, 15 Mar 2006 07:51:05 PST8
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	< "scoug-programming@scoug.com" > scoug-programming@scoug.com >
Subject:	SCOUG-Programming: Off We Go......

Content Type: text/plain

From Uncle Lynn,

I will not be at the SIG meeting on Saturday. Instead I will be
in Irvine attending a swim meet in which my youngest
granddaughter will compete. When I get these invites to
witness my grandchildren's activities I order my priorites to
suit.

Nonetheless you are in good hands of Bob Blair this Saturday
as he presents an introduction to presentation manager
programming. Some of you will remember his presentation on
REXX previously. You have every reason to believe that the
same high quality will occur in this presentation as in that.

Now I would like to make note of a new entry on this mailing
list, that of Nathan Woodruff. He joins us to assist in our PM
endeavors. I should leave him to address his credentials, but I
should mention that he was on the team which produced
CASE:PM for OS/2. CASE stands for Computer-Assisted
Software Engineering, a generic term related to programs
which aided in the production of graphics used in different
methods of software analyis and design like flowcharting,
dataflows, and structure charts. Nathan also leads an open
source project for anothe OS/2 PM application related to a
personal accounting application which he wrote.

Welcome, Nathan.

I met Nathan virtually via emails exchanged in another forum
in which VOICE is considering purchase of the complete rights
to the OS/2 version of PMMail, which I use in composing these
messages. Now if VOICE makes the deal, we will have yet
another "source" for PM programming along with and editor.
In a sense our cup is filling up.

That leaves me with responding to the recent exchanges
between Greg and Steven along with reassuring Nathan that
not all share my views in this democratically run SIG. I don't
really mind the "uncle" moniker, although I have more
grandchildren than I have nieces and nephews. I don't mind a
reference which could apply to a younger man.

I doubt seriously if either Greg or Steven will ever understand
the deep appreciation I have for their participation in and
contribution to this discussion and current project. If ever I
need someone to provide in detail examples which support the
goals I have in mind, they somehow in sync volunteer them. In
comedy and elsewhere timing is everything. I remain most
appreciative of their efforts.

When I do make it to a SIG meeting next month I will
remember to bring along this impressive graphical
representation of the "Eclipse Application Development
Life-Cycle", IBM's and the industry's most recent reincarnation
of AD/Cycle. You can do a side-by-side comparison of the
two approaches.

Open source has a very low contributor to user ratio which for
a community like OS/2 represents an overly dependence on
third party efforts whose absence or extended delays further
affect its viability. I continue to claim that this low ratio
exists due in large part to the learning curve cost of entry for
potential contributors. Greg has kindly pointed out a feature
of the Open Watcom source relative to "builds" that illustrates
the (in my view) unnecessary "solutions" to problems which
arise in software development/maintenance.

He is correct when he states that in what I propose no
"builds" as separate source code exists. No "makes" as
separate source code exists. No linkage editors as separate
source code exists. No include files as separate source code
exists. That doesn't mean these "functions" don't occur. It
simply means they don't occur "separately" with their own,
possibly different source code.

After we master presentation manager programming, have it
well within our comfort zone, and communicate it from our
website to do the same for the larger OS/2 community, we
will continue our progression toward an ever "smarter" editor
in which we will do what software cannot and software what
we need not. That means we will turn our attention to
shifting from the use of file management, the source of the
"unnecessary evils" in current methodologies, to that of
database management, initially relational database
management.

We will begin our development of the Data
Repository/Directory which our tool will use exclusively for
source code and text management. Remember we're dealing
with oneness here: one language, one tool, one library (one
data repository/directory).

Builds, makes, and links deal with version control as a
separate process. That in turn leads like editors, interpreters,
and compilers into multiple versions, some distance in terms of
number from the "one" we have in mind. In our approach
version control remains integral to the process as a
sub-function within the tool and its use of the data
repository/directory.

When you make a change to any source code statement or
text sentence, you create a new version. That has an effect
on zero, one, or more (possibly all) of the assemblies
containing the previous version. At the time at which the
change occurs the option within the tool allows for the
selective replication in the different assemblies. When that is
done then the new assembly versions, i.e. the programs in
which they occur, get scheduled as a batch for
re-interpretation and testing, as a single unit of work.

Thus no other source other than the changed source, the only
source which ever gets created, deleted, or modified, under
operator direction controls the "re-generation" process. The
operator can selectively designate affected assemblies based
on an assisted examination by the tool or can designate a
universal application of the change. In either instance on
completion execute a synchronization of the effect of the
change as a single unit of work.

Thus Greg is correct. No build as separate source occurs. The
builds, however, do occur integral to the process. Thus there
are no build files. With the data repository/directory and the
builtin support of its database manager no need for any files
exists. Thus no need for functions based on the use of
separate source files.

The problem exists in the use of file management and thus of
files. It disappears or gets resolved more easily with less
effort and writing/maintaining of source in using a database
manager. The function remains. Its implementation differs.

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"postmaster@scoug.com".

=====================================================

Return to [ 15 | March | 2006 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.