Can Programming Be Strictly Portable Relative To Language?

The activity associated with development of strictly portable methods of software development will be presented here. Included in this Portability effort will be Windows based C, C++, C#, and Visual Basic; and Linux based C and C++.

FRIDAY: Currently, I believe that the common name problem can be resolved using the script calling capability of the script software parts library. This require a different form of certification chain capabilities which will probably require upgrading the certified copy library. This will be examined after I upgrade the associated software parts of the script software parts library.

Development of Utility Libraries

The activity associated with development of utility software parts libraries will be presented here.

The effort associated with the development, upgrading and testing the  script software parts library will be documented here. Specifically, the script software parts library will be upgraded to behave more like a software part. It will also be formally tested.

SCRIPT FRIDAY ACTIVITY: The handling of the optional parameters for the script calling software parts will be examined first. Corrections and improvements will be made as needed.

SCRIPT SATURDAY ACTIVITY: Currently, The software part that loads the script calling argument specifies both the calling argument as well as the called parameter which has to be defined in advance. This is not a normal coding method. Calling a subroutine does not require knowledge of called subroutine parameter names.  This can be solved by expanding the instruction for beginning loading a script to include a list of parameters.  The single command that currently begins loading a script would optionally be replaced by three commands: one that initializes the loading process and begins the parameter list, one that adds a parameter, and one that ends the parameter list.

SCRIPT SUNDAY ACTIVITY: Originally, a data storage capability was provided for each script.  This capability provided both the calling parameters for the script as well as other data storage requirements and is retained only during the execution of the script. The primary difference between the parameters and other data storage elements is the loading restrictions: Parameters can only be loaded from the calling script and the other data storage elements can only be loaded from within the called script. To implement this restriction, we must develop both capabilities at the same time.

SCRIPT MONDAY ACTIVITY: The software parts needed to define a parameter and a data storage element have been prepared. The next task is to define the necessary software parts to organize this capability at the beginning of the script before the first executable script command.  Any parameters should come first, then any data storage elements, and then any executable commands.  The necessary software parts to implement and enforce this order will be prepared next.

SCRIPT TUESDAY ACTIVITY: The most efficient solution to organizing the parameter and data storage element definition at the beginning of the script before the first executable script command was to build a “software fence”; i.e, a software part that must be inserted after the last data definition statement and before the first executable commands.  This software part has been prepared and tested. The next step is to modify the script calling and data loading software parts.

Can Programming Be Strictly Portable Relative To Language?

The activity associated with development of strictly portable methods of software development will be presented here. Included in this Portability effort will be Windows based C, C++, C#, and Visual Basic; and Linux based C and C++.

FRIDAY: Modifications to the common includes software parts library are needed. Specifically, the ability to receive a copy of a set of include commands without preparing them for copy to a subsequent task (the end of the copy sequence) has not been prepared.  The additional software parts will now be prepared.

TUESDAY: Modifications to the common includes software parts library have been made and tested.  Specifically, the ability to receive a copy of a set of include commands without preparing them for copy to a subsequent task (the end of the copy sequence) is now provided.  A review of the permissible use of this library now needs to be made.  Also, an untested feature of the script library was encountered and checked out. The formal tests of the script library must be upgraded.

WEDNESDAY: We can use the C++ #include statement to identify the rules associated with the use of the includes software parts library.  Specifically, we have three types of include statements: system, data and class include statements. The system include statements are written in all source files. The data include is written in the class header file and the the class include statement is written in the source files. There appear to be no certification chains required for the #include statements. We also need to consider a common name that will allow us to bring in not only the #include statements but also the other command sequences associated with the referenced file.

Development of Utility Libraries

The activity associated with development of utility software parts libraries will be presented here.

The effort associated with the development, upgrading and testing the  script software parts library will be documented here. Specifically, the script software parts library will be upgraded to behave more like a software part. It will also be formally tested.

SCRIPT THURSDAY ACTIVITY: It has been decided to improve the handling of parameters in the script calling software parts.  This will include optional parameters in the base software part that executes the script.

Is Strictly Portable Web-Site Development Possible?

The activity associated with the maintenance of whatifwe.com web-site be presented here. Of critical importance is the use of strictly portable (Win32, Linux) standard methods for preparing the web-site files using the Programmable Software Development Environment.

MONDAY: The last update of the Programmable Software Development Environment revealed the desirability of updating the web-site. I do not want to perform this effort using Front Page. I plan to restart my development of the software parts libraries associated with web-site development.  To accomplished this, I must update the test program that I am using for all of my formal testing. This will be started as soon as possible and reported in the “Economical Rigorous Software Testing at All Levels”. topic.

MANUAL MAINTENANCE

The activity associated with the maintenance of Programmable Software Development Environment Manual be presented here. Of critical importance is the use of strictly portable (Win32, Linux) standard methods for preparing the associated “*.html” files.

SATURDAY: The Manual Update has been completed.  Please track the completion of this Programmable Software Development Environment update project in the “Open Source Software Development Tool: Upgrade Progress”. Section.

Open Source Software Development Tool: Upgrade Progress

It is planned to update the Programmable Software Development Environment to provide the capability of preparing a text file copy of the command line screen display.  It is also planned to update the debug screen menu to provide the capability of making a comment (which would be recorded in the screen display file). A person desiring to learn how to use this program would want to look over my shoulder when I am using it.  This screen display file would provide an equivalent capability.

SATURDAY: The zip files containing the new version of the Programmable Software Development Environment will now be prepared.

THURSDAY: The modifications of the Windows and Linux versions of the Programmable Software Development Environment  been completed and are available for download (Version 3). I apologize for using Version 3 over and over again. I really don’t want to update my web-site every time that upgrade my program. You can find a complete history of versions on  “iso9001programming.codeplex.com”.

MANUAL MAINTENANCE

The activity associated with the maintenance of Programmable Software Development Environment Manual be presented here. Of critical importance is the use of strictly portable (Win32, Linux) standard methods for preparing the associated “*.html” files.

FRIDAY: The “_REPORT_FILE” has been successfully prepared. The development of the new “Report Generation Commands” page is next.

MONDAY: The development of the new “Report Generation Commands” page has been successfully completed. I believe that the current version of the manual is adequate for the new version of the Programmable Software Development Environment. The common line screen reporting capabilities are important for our communication. The next step will be to proof the manual. When completed, this version of the Programmable Software Development Environment can be prepared for publication

TUESDAY: My first examination of the Manual revealed link errors that have been corrected. I also observed some deficiencies in the documentation of the Project File relative to the Command-Line Report Generation File. My next task will be to re-examine and correct these deficiencies.

THURSDAY: The observed deficiencies in the documentation of the Project File relative to the Command-Line Report Generation File have been fixed. A second overall review of the manual needs to be made and then this version of the Programmable Software Development Environment can be packaged for upload. It is also important at this time to review the web-site for needed upgrade.

Can Programming Be Strictly Portable Relative To Language?

The activity associated with development of strictly portable methods of software development will be presented here. Included in this Portability effort will be Windows based C, C++, C#, and Visual Basic; and Linux based C and C++.

FRIDAY: The script library has been sufficiently tested that the testing of the second level operation of the common include library can continue.

TUESDAY: The testing of the second level operation of the common include library has been completed. The tests include the copying of the system includes and the definition of class and data includes. Testing the third level of operation is next.

Economical Rigorous Software Testing at All Levels

The ability to thoroughly and economically test software work-products at all levels is a necessary requirement of the error-free software development process.  The Programmable Software Development Environment has a Monte-Carlo (random generator) based test system which is capable of satisfying this requirement.

Historically, this tool has been very difficult to set up and hence has only been experimentally use. Recently, a library of software parts has been developed which greatly simplifies its use. As a consequence, it is being successfully used in the checkout and formal testing required in my portable software development research and development activity.

This blog will be used to focus upon on my test related research and development efforts.

FRIDAY: A local script only exists in the task in which it was created. It is discarded when this task is complete. A global script that calls a local script in a particular task will fail to execute in a subsequent task.  The associated error is now properly reported. The single line this script calling capability for global and local scripts has now been sufficiently tested that it can been used for manual development.

SATURDAY: To determine what additional changes are needed to the script software parts library, I need to answer the question: How much is the script going to simulate a macro?  In the past, I made a limited effort. Maybe a complete simulation is needed. I will re-examine this question

MONDAY: To make the script simulate a macro, I will need to improve the script calling arguments and return capabilities, and both the automatic and global data storage. I have tentatively decided to proceed with the update.  The script calling arguments will be first. The planned improvement will include a parameter capability for the _RUN_SCRIPT macro.