SCOUG-Programming Mailing List Archives
Return to [ 28 |
August |
2005 ]
>> Next Message >>
Content Type: text/plain
Steven mentioned Greg's attempting to port VIM and Python
from LINUX to OS/2 using the GCC compiler. In looking back at
last Saturday's presentation I remember something of a
calendar program, but apparently missed those parts
associated with VIM and Python. If I attempt to port the same
source to OS/2 with the Watcom compiler, I would appreciate
knowing from where and what I should download.
In keeping with the spirit of things I downloaded the latest(?)
GCC compiler (3.3.5) which came as a .zip file. I unzipped it
okay, but stumbled on executing the gccenv.cmd, which is a
REXX script. I have get by this. Just on the install process I
have to score it Watcom 1, GCC 0. Maybe we should do like in
boxing by scoring on a 10 point system. At any rate in terms
of round 1 Watcom won. Thus far it's not even close.
We've not exactly made rapid progress since beginning this
current venture with the SIG. Sometimes like in any long
struggle when a succession of immediate choices blur initial
reasons you need remind yourself what got you into this in
the first place...who brung yah to the dance.
We want to see OS/2 to do more than continue in something
like eCS, but actually thrive, live long, and prosper. We
wanted to do this under the umbrella of open source in
getting applications for other platforms like Windows and
Linux and porting them to OS/2.
In looking at how best we could contribute to this given our
finite people resources we struck a chord on a major
weakness of open source...its people resources. Particular
concern lay in the imbalance between "user only" and "user
contributor" along with the need from the former to the
latter.
We had two basic choices. Either we made the existing
development environment, predominantly GCC based, more
palatable, less inhibiting, and more attractive or in our process
of mastering it we change it in fundamental ways. Both
Steven and Greg have shown a level of mastery, one perhaps
more so than the other, but have they convinced us to follow
in their footsteps?
In short for the moment it appears we have little choice.
Without some minimal level of mastery, specifically of the
core tools, the compilers, the linkers, the make, etc., we
cannot amend these to make them less formidable to others.
Except possibly in the area of documentation, which still
requires mastery on our part, but which may ease the same
path for others. Thus we began our often interrupted and
thus drawn out venture into "comparative linguistics".
I've made no secret that I think it far more complicated and
complex than necessary, something imbued culturally with
what I refer to as the "UNIX mentality" in which we strew
pieces together to make a system instead of designing a
system with integrated pieces. The latter comes from my
"mainframe mentality" evolved over my career in IBM from the
middle 50's, the 60's and early 70's. My career was longer but
that was the period of the rise of first, second, and third
generation languages as well the evolving apex in operating
systems starting with the S/360 MVT through MVS to today's
z/OS.
That same career found me working primarily with distribution
and manufacturing accounts which gives me my bent toward
PICS (Production and Inventory Control Systems) implemented
in COPICS (Communication-Oriented PICS) through IBM's online
transaction processing system CICS (Customer Information
Control System or "kicks"). I did develop considerable
mastery in all those. Of course, I got paid to do it. That's an
incentive mostly missing in open source.
It helped that the title bestowed on those of us in technical
marketing support was "systems engineer". That differs
somewhat in terms of perspective from a "parts engineer". I
tend to look at a system in terms of the number "1", in which
all the supporting parts work together. I don't take the view
in which I have a number of parts from which I can form a
number of systems, some of which include software
development and maintenance.
I basically seek to have one software development system
which incorporates maintenance (to avoid having separate
processes for both) in which the parts need only those
"functions" necessary. In fact in a system the parts disappear
and only the necessary functions remain within a single
linguistic framework.
I assume that we will demonstrate both GCC and Watcom
compilers porting VIM and Python to OS/2. These represent a
particular confluence in coming to the "systemic" solution I
support. VIM, if I understand it correctly, is an enhanced
editor lending itself as an IDE using GCC in the same manner
as the IDE included within the Watcom package. Python is an
interpretive system whose mastery of its internals will
prepare us to "enhance" the IDEs of both. We should then
from a single user interface, i.e. tool, seamlessly edit source
and execute either interpretively or compiled.
I think over the next few months and if we can continue to
get our "fair share" of time at the monthly meeting that we
will open up a host of opportunities as we "master" of these
improves. As part of that we can engage in the scientific
method which relies in independent verification to prove or
disprove the assertions I have made concerning the
Developer's Assistant as well as the productivity gains.
I hope then that you will look as forward to it as I do. We are
coming down to crunch time.
=====================================================
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".
=====================================================
>> Next Message >>
Return to [ 28 |
August |
2005 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
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.
|