SCOUG-Programming Mailing List Archives

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

Date:	Wed, 15 Mar 2006 08:35:16 PST8
From:	<n_woodruff@bellsouth.net >
Reply-To:	scoug-programming@scoug.com
To:	<scoug-programming@scoug.com >
Subject:	SCOUG-Programming: Off We Go......

Content Type: text/plain

Hi All.

I didn't consider myself an expert on PM programming until about 15 years of professional PM programming, doing it every day.

I don't think it can be mastered in a weekend. It may be done in 6 months though, if you really put time into it. If at first you don't succeed, try, try again.

I did this as a proof of concept. http://hobbes.nmsu.edu/pub/os2/apps/comm/aol40.zip

Look at the date on it. I wanted to let people know that extensive graphical programming could be done on OS/2 rather than just the 16 color PM programs that you have all seen in the past.

It did at one time connect to AOL using the 3.1 protolcol. When they quit supporting Windoze 3.1 the protocol quit working. I did another one with the 4.0 protocol but that version did checks to make sure you were running their software and I eventually gave up and moved onto other projects.

I was one of the original three developers of CASE:PM. If any one can get their hands on a copy, I'll tell you how to find my name in the program.

Being from Atlanta Georgia, I don't think I will be attending any meetings, any time soon.

Nathan

>
> From: "Lynn H. Maxson"
> Date: Wed, 15 Mar 2006 07:51:05 PST8
> To: "scoug-programming@scoug.com"
> Subject: SCOUG-Programming: Off We Go......
>
> 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".
>
> =====================================================
>
>
>
>

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

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.