[M3devel] organization of scripts folder

[Daniel Alejandro Benavides D.]

Hi Randy:
I think your idea sounds great, maybe scripts package structure clean up could help to define a "category" rather than an individual package in CM3IDE as a framework for scripting with quake, obliq, visualobliq, obliq-3d and friends, but as the CM3 builder powered  support for scripting   of  quake, obliq  and friends  support already present in WebScape and DeckScape  web browser programs that would help to develop "addons" for CM3IDE such as allowing distributed  checking of M3, obliq, etc programs with Showheap, Shownew and Showthread views allowed for each program running; a   "deck" (tab) per program of a given CM3IDE server on the web client DeckScape or WebScape  browser just standalone or distributed  view of it, giving the system a world of tools to delevop distributed served M3, obliq, etc programs. That would be aplus besides the bash/bat command line language scripts and others to mantain the core system by itself without CM3IDE
This new category (Scripts) could help in checking the scripting facilities in CM3IDE and further enhancements in terms of components, like those you are telling, Explorer context menu integration and possible similar add ons for Mozilla family and others like email readers and web browsers developed at DEC.

As the examples Category is already present in CM3IDE would be nice to put the example scripts you mention to test CM3 system scripts for  bootstraping, upgrading, testing and misc. processes to aid debugging (runtime views of M3 program parameters). Whether they can run in a common web browser interface would require  harder work to make it  inside CM3IDE or easier in DeckScape and WebScape web browsers.

Actually hard work was made by professor Tian Zhao (UW-Milwaukee) and professor Jens Parlsberg ( Purdue University) to do type inference in NP-time for no-explicit typed obliq scripts, giving us an opportunity to implement it and help the compile/run process of obliq scripts (potentially giving an ahead of time ability to check and accept or reject some  scripts) and why not, write distributed platform-independent no-explicitly typed code to produce the explicitly typed and reduce runtime overhead for better performance and improved documentation of obliq and friends scripts.

Thanks in advance, hope it helps and  generate some further rethinking of system scripts and new ideas on quake, obliq and friends to aid the CM3 and CM3IDE scripting engine integration enhancements. 
 


--- El mar, 27/10/09, Randy Coleburn <rcoleburn at scires.com> escribió:

De: Randy Coleburn <rcoleburn at scires.com>
Asunto: Re: [M3devel] organization of scripts folder
Para: "<m3devel at elegosoft.com>" <m3devel at elegosoft.com>
Fecha: martes, 27 octubre, 2009 10:08


 
I install some of my scripts.  
Not sure if anyone else uses them.
 
Nonetheless, I know that for me some of these scripts make cm3 easier to use on Windows.
For example, I have scripts that:
1.  Start the IDE.
2.  Set up all the paths and environment variables for operating cm3 and Microsoft linker / Visual Studio at the command shell.
3.  Open a cm3 command shell window in a particular folder.  I've integrated this with the Explorer context menu for even greater utility.
4.  Automate building of multiple packages based on the concept of a project.
etc.
 
Perhaps others would have similar scripts that should be available as part of the install.
 
So, I'm suggesting here that we make a conscious choice on a standardized way for folks to contribute such scripts with the intent that when the installs are built that these scripts get included.  End users are free to use the scripts, not use them, or even remove them after the product is installed.
 
What do others think?
 
Regards,
Randy Coleburn

>>> <jay.krell at cornell.edu> 10/27/2009 4:02 AM >>>

None of the scripts are installed.

 - Jay (phone)

On Oct 26, 2009, at 10:10 PM, "Randy Coleburn" <rcoleburn at scires.com> wrote:





I would like to better understand the rationale behind the "scripts" folder in terms of how it is organized and supposed to be used.
 
Here is the current folder structure:
 
scripts
+---config
+---doc
+---examples
+---iphone
|   \---1
+---python
+---regression
\---win
 
In the past, I had put some BAT/CMD scripts in the "scripts" folder with the intent that these would be placed in the "bin" folder of the target install.  Later, the other subfolders were added, including the one named "win".
 
It seems there are perhaps multiple intentions for the scripts folder.  For example, there are scripts that one would use mainly in setting up, maintaining, or administering cm3.  There are other scripts that would be useful for certain target platforms as part of the installed system.  There may be other scripts useful for testing.
 
I am almost finished with testing of a new script I want to be included in the "bin" folder of the installed system on Windows platforms.  This script will replace some of the old ones I have out there.  It is designed to work with Win2000, WinXP, and Vista, whereas my old scripts don't work well on Vista.  I also have some scripts I've built that aid in rebuilding package sets based on the PkgInfo.txt file.
 
Before I remove my old scripts and replace them with the new ones, I thought it best for us to think about how the scripts folder should be organized.
 
As a first cut, I propose something along the following lines:
 
scripts
+---doc = documentation for stuff in the "scripts" folder tree
+---dev = scripts used for system development, maintenance, admin
+   +---windows = dev scripts written for Microsoft Windows (BAT, CMD)
+   +---posix = dev scripts written for unix shell (sh, bash, etc.)
+   \---python = dev scripts written in python

+---install = scripts that should be put in "bin" folder of target install

+   +---common = scripts common to all target platforms+   +---windows = BAT/CMD scripts for Microsoft Windows
+   +---posix = shell scripts for POSIX platforms (sh, bash, etc.)
+   +---python = scripts written in python (applicable to any platform with python)
+   \---XXX = scripts for target platform XXX (XXX is name of platform)
+             (assuming XXX needs something special not covered above)

\---test = scripts used for regression testing
    +---windows = test scripts written for Microsoft Windows (BAT, CMD)
    +---posix = test scripts written for unix shell (sh, bash, etc.)
    \---python = test scripts written in python
 
What do you think?
 
Regards,
Randy Coleburn
 
 


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091028/8f9e3de6/attachment-0002.html>