Repost of original >: autocoding project proposal

Timothy Rue threeseas at
Sat Feb 9 11:44:13 EST 2002

Reposting as a matter of 20/20 hindsight in reference to what all has
evolved from this proposal. (has therre really been any productive
direction achieved....)

On 20-Jan-02 22:01:49 Timothy Rue <threeseas at> wrote:
>I'm posting this to this python group because a sample of what is
>mentioned below is done in python. And wouldn't it cool to have python
>used in an autocoding development environment?

>This posting is to introduce or suggest an open source software project
>to produce a core tool that will allow an autocoding environment to be
>developed, allowed to evolve in the open source software community and
>spirit of. I believe we can overcome many of the problems that proprietary
>autocoding systems inherently have (not to mention that existing
>autocoding systems appear to be field/domain specific limited and that
>it may be possible to beat this too.)

>Ghostscript PDF viewers for the following PDF links (if you don't already
>have a PDF viewer)

>The following information represents what is probably the best of what is
>available thru the Web on the subject of autocoding. (via google)

>HIRTS DARP Working Group on Autocoding, 18th, 19th April 2000
>(Brings up various issues which will help you focus in on what
>"autocoding" is and what some of the issues to solve, are.)

>The follow up to the above is:
>May 8th thru 10th, 2001 "DARP HIRTS Workshop" paper by Jakob Engblom:
>(See pages 5-6 section 3.2.5 The Use of Tools in Aerospace)

>In summary, Though autocoding is being used to some extent, it is a
>future hope, since in general it has a bug density which is an order of
>a magnititude lower than manual code.  Point being is that this is
>leading edge stuff, an opportunity for OSS to shine.

>The above paper mentioned the SCADE autocoding product:
>(See code generator part of Product overview, Benefits, Toolset Features)

>Autocoding as it applies to the medical industry:
>(Since it was mentioned in a paper above, know it's a product of a
>different nature.)

>To help show why I believe OSS efforts can shine when it comes to such a
>project as Autocoding:

>QinetiQ - Analysis of the Impact of Open Source Software

>and From the Conference on the Public Domain, Nov. 9-11. 2001 at Duke Law
>School "Coase's Penguin, or, Linux and the Nature of the Firm" by Yochai

>It is also worth mentioning, to my undersandng, that the GNU efforts are
>becomming more modular in nature and there is also the Hurd that is
>modular or componet based from the ground up. This is a consistant and
>fitting direction in accord with an open autocoding development and use

>OK, so although this project is not AeroSpace "Mission Critical", it does
>not hurt to make the quality target of the project to be of such high
>standards. Actually, what I believe is that the core (as mentioned at the
>beginning of this post) can be made to be of high quality itself, where
>the rest, the coding knowledge base or what ever you want to call the
>pre-autocode dictionary, will be of whatever quality it is created and
>improved to be (as is the way and spirit of the OSS community.)

>Where to start?

>Automating what was done manually requires the identification of, and
>ability to apply, the manual action set we use, but have the computer do
>it. A USPTO Published comment introducing these identified actions and
>suggestions of how they may be applied, including autocoding, is here:

>The bottom part of my home page regarding the
>"Virtial Interaction Configuration":

>An older paper on the Virtual Interaction Configuration:

>Why don't I do this shell and/or library myself?

>I don't consider myself a programmer having the experience and knowledge
>of better ways of coding somethings and as such I'm sure this core of
>functionality can be coded better and faster than what I could do, but
>there is what I have done, and that includes some python programming that
>can be used and run to show/communicate some of the concepts of the
>Virtual Interaction Configuration. And I can provide insight as to how it
>may be used for such things as autocoding.  Until recently, this past
>week, I wasn't aware "autocoding" was an actual goal and practice of
>anyone, though I have used the term for sever years now, and apparently,
>given the above HIRTS DARP papers, my perspectives and thoughts on the
>matter have been along the lines of what's been going on. Though I do
>believe The VIC as a core can solve some of the problems facing commercial
>autocoding packages (but this is something to get into later, when I can
>communicate but showing).

>Besides the VIC core, there is the pre-automation code base(s) to create
>for whatever programming language(s) people want to use. And that's
>something clearly beyond my ability to directly do, at least in the
>beginning. Besides, there are many other things the VIC can be used for
>besides autocoding. Consider it a tool for general automation...

>At any rate I do believe Autocoding is a worthwhile goal that the GNU
>community can shine at. And I think some of you, in consideration of the
>HIRTS DARP link contents and the USPTO comment, will too.

>If interested in helping, email me at mailto:threeseas at
>If interested in using such a tool, then say so here, let others know.

*3 S.E.A.S - Virtual Interaction Configuration (VIC) - VISION OF VISIONS!*
   *~ ~ ~      Advancing How we Perceive and Use the Tool of Computers!*
Timothy Rue      What's *DONE* in all we do?  *AI PK OI IP OP SF IQ ID KE*
Email @ mailto:timrue at      >INPUT->(Processing)->OUTPUT>v
Web @  ^<--------<----9----<--------<

More information about the Python-list mailing list