[GRASS-SVN] r29418 - grass-addons
svn_grass at osgeo.org
svn_grass at osgeo.org
Wed Dec 12 08:01:34 EST 2007
Author: martinl
Date: 2007-12-12 08:01:32 -0500 (Wed, 12 Dec 2007)
New Revision: 29418
Removed:
grass-addons/SUBMITTING
grass-addons/SUBMITTING_DOCS
grass-addons/SUBMITTING_SCRIPTS
grass-addons/SUBMITTING_TCLTK
Modified:
grass-addons/SVN_HOWTO.txt
Log:
Remove redundant SUBMITTING* files, explained in SVN_HOWTO file
Deleted: grass-addons/SUBMITTING
===================================================================
--- grass-addons/SUBMITTING 2007-12-12 12:53:13 UTC (rev 29417)
+++ grass-addons/SUBMITTING 2007-12-12 13:01:32 UTC (rev 29418)
@@ -1,391 +0,0 @@
-$Id: SUBMITTING,v 1.22 2006/08/09 09:27:57 markus Exp $
-
-NOTE: Please improve this list!
-
-Dear (new) GRASS Developer,
-
-When submitting C code to GRASS Addons-SVN repository, please take
-care of following rules:
-
-[ see SUBMITTING_SCRIPTS for shell script hints ]
-[ see SUBMITTING_TCLTK for tcl and tk hints ]
-
-
-1. Get and read the GRASS 6 Programmer's Manual here:
- http://grass.itc.it/devel/index.php#prog
-
- or generate it from this source code (the programmer's manual is
- integrated in the source code in doxygen style):
- make htmldocs
- make pdfdocs
-
-
-2. Use the directory structure to place your module appropriately into
- the source tree
- - libes go into lib/
- - raster goes into raster/
- - vector goes into vector/
- - ...
-
- Consider to take a look at "GNU Coding Standards"
- http://www.gnu.org/prep/standards.html
-
- In future, there will be a centralized contribution directory.
-
-3. Add a header section to each file you submit and make sure you include
- the copyright. The purpose section is meant to contain a general
- overview of the code in the file to assist other programmers that will
- need to make changes to your code.
-
- Example (ficticious header for a file called color.c) :
-
-/****************************************************************************
- *
- * MODULE: d.rast (or new higher level module name (eg GRASS core)
- * for 6.1)
- * AUTHOR(S): Original author unknown - probably CERL
- * John Doe - jdoe at some.where.org
- * PURPOSE: To provide storage and manipulation of colors used for
- * rendering the raster. The colors are stored in a doubly linked
- * list which must be initialized with InitColors() before it can
- * be used. Note that most linked list functionality (add,
- * remove, get) is supported, but their is no sorting
- * functionality.
- * COPYRIGHT: (C) 2005 by the GRASS Development Team
- *
- * This program is free software under the GNU General Public
- * License (>=v2). Read the file COPYING that comes with GRASS
- * for details.
- *
- *****************************************************************************/
-
- The copyright protects your rights according to GNU General Public
- License (www.gnu.org).
-
-
-4. - deleted.
- We don't want the $ ID $ in source code any more as it causes problems
- for the CVS branches.
-
-
-5. To ensure that the software system continues to work, please include
-
- #include <grass/config.h>
-
- in your files and make use of the various system dependencies
- contained therein. As one example of this, see
- lib/gmath/fft.c . Please refrain from declaring
- system functions within the software; include the proper header files
- (conditionally dependent on config.h macros if necessary) instead.
-
-
-6. Order of include headers
-
- In general, headers should be included in the order:
-
- 1. Core system headers (stdio.h, ctype.h, ...)
- 2. Headers for non-core system components (X11, libraries).
- 3. Headers for core systems of the package being compiled (grass/gis.h, grass/glocale.h ...)
- 4. Headers for the specific library/program being compiled (geodesic.h, ...)
-
- Each class of header has an obligation to be compatible with those
- above it in the list, but not those below it.
-
-
-7. Always specify the return type for ALL functions including those that
- return type "void", and insert return statements for ALL functions.
- Also, use ANSI C prototypes to declare your functions.
- For module return values, see "Exit status" below.
-
- Examples:
-
- void G_something(void);
- int G_something_else(int, int);
-
- void G_something(void)
- {
- /* Snipped out code */
-
- return;
- }
-
- int G_something_else(int x, int y)
- {
- /* Snipped out code */
-
- return(0);
- }
-
-
-8. Exit status is defined as EXIT_SUCCESS or EXIT_FAILURE, e.g.
-
- {
- ...
- if (G_parser (argc, argv))
- exit (EXIT_FAILURE);
-
- ...
- exit (EXIT_SUCCESS)
- }
-
-
-9. Use fprintf instead of printf. But:
-
- For errors and warnings please use the G_fatal_error() and
- G_warning() functions. General messages for the user should use
- G_message() while debug messages should use G_debug() whenever
- possible.
-
- G_message() output is not expected to be sent to pipe or file.
-
- Always use the gettext macros with _("") for user messages,
- example:
- G_fatal_error ( _("Vector file [%s] not available"), name);
-
-
- Pipe/file data output:
- For data output redirected to pipe or file, please use fprintf() and
- specify the stdout stream as follows:
-
- fprintf(stdout, ...);
- fflush(stdout);
-
- fflush(stdout) always required when using fprintf(stdout, ...).
-
-
-10. Use the GRASS library function G_asprintf() instead of the
- standard C functions asprintf(), vsnprintf() and snprintf(). These
- functions are not portable or have other issues. Example:
-
- char *msg;
-
- G_asprintf(&msg, "%s", parameters);
- do_something_with_msg();
- G_free(msg);
-
- Note that you should free memory when G_asprintf() is used.
-
-
-11. Use the following GRASS library functions instead of the standard C
- functions. The reason for this is that the following functions ensure
- good programming practice (eg always checking if memory was allocated)
- and/or improves portability. PLEASE refer to the programmers manual
- for the proper use (eg determining if any casts are needed for arguments
- or return values) of these library functions. They may perform a task
- slightly different from their corresponding C library function, and thus,
- their use may not be the same.
-
- G_malloc() instead of malloc()
- G_calloc() instead of calloc()
- G_realloc() instead of realloc()
- G_free() instead of free()
- G_getenv() instead of getenv()
- G_setenv() instead of setenv()
- G_unsetenv() instead of unsetenv()
- G_sleep() instead of sleep()
-
- Could somebody please add others (please verify that they are
- useful and safe first)
-
-12. Use function names which fulfil the official GNU naming convention.
- http://www.gnu.org/prep/standards/html_node/Names.html#Names
-
- Instead of naming a function like: MyNewFunction() use underscores
- for seperation and lower case letters: my_new_function().
-
-13. Don't use the C++ comment style! This confuses several compilers.
- Use instead:
- /* C-comments */
-
- If you want to comment code portions, use
- #ifdef notdef
- portion_to_be_commented;
- #endif
- This is safe comparing to nested /* comments */
-
- Functions in the library must be documented in doxygen style to
- get them into the programmer's manual (generate with
- make pdfdocs or
- make htmldocs
- ). See lib/gis/*.c for examples.
-
-
-14. PLEASE take the time to add comments throughout your code explaining what
- the code is doing. It will save a HUGE amount of time and frustration for
- other programmers that may have to change your code in the future.
-
-
-15. To promote a consistent coding style, please use the "indent" program
- on all new C modules using the following switches:
-
- $ indent -nbad -bap -bbb -nbbo -nbc -br -bli1 -bls -cbi0 -ncdb -nce \
- -ci4 -cli0 -ncs -d0 -di0 -fc1 -nfca -hnl -i4 -ip4 -l80 -lc80 -lp \
- -npcs -pi4 -nprs -npsl -sbi0 -sc -nsob -ss -ts8 main.c
-
- Existing code should not be re-indented except in extreme cases, as this
- will make "diff" comparisons with older versions impossible. If indent is
- needed, do not check in any changes other than the indentation in the same
- commit! Do add the indent switches and any indent warning messages to the
- CVS log. Any change or fix mixed in with an indent is very hard to track
- making it hard for others to follow the change or fix any new bugs.
-
-
-16. Platform dependent code:
- Do not remove #ifdef __CYGWIN__ and/or #ifndef __CYGWIN__ lines and
- their encapsulated lines from source code (one example was that someone
- removed drand48 definition.)
-
-17. Suggested compiler flags:
- We suggest to use very strict compiler flags to capture errors
- at the very beginning. Here our list of flags, please use them
- to configure you development version of GRASS:
-
- GNU/Linux:
-
- MYCFLAGS="-g -Wall -Werror-implicit-function-declaration -fno-common"
- MYCXXFLAGS="-g -Wall"
-
- CFLAGS="$MYCFLAGS" CXXFLAGS="$MYCXXFLAGS" ./configure ...
-
- MacOSX: [to be suggested]
-
- MS-Windows: [to be suggested]
-
-18. Make sure a new line is at the end of each file.
-
-
-19. When writing Makefiles, use the current standard.
-
- If you have to use commands, please check for:
-
- avoid | use instead
- ------------------+---------------
- make target | $(MAKE) target
- mkdir target | $(MKDIR) target
- cp (executable) | $(INSTALL) -m 755 file target
- cp (normal file) | $(INSTALL) -m 644 file target
- ar | $(AR)
-
- rm: be VERY careful with recursive remove.
-
- Examples: see below examples or others
- raster/r.info/Makefile
- vector/v.digit/Makefile
-
- If you are unsure, please ask on the GRASS Developers list.
-
-20. Have a look at ./INSTALL
-
-
-21. Have a function included in your module which writes to the history
- file of the map (e.g. command line, parameters etc.). See eg
- raster/r.patch/main.c
-
- (the same applies to vector and g3d modules!)
-
-
-22. Standard parser options: use G_define_standard_option() whenever possible
- to define standard module command line options. This will save you time,
- create fewer bugs, and make things easier on the translators.
- See lib/gis/parser.c for details of the function definition.
-
-
-23. Module manual page:
- Place the documentation in HTML format into 'description.html'.
- The easiest way to do this is to study an existing HTML page
- (to get the page style, e.g. vector/v.to.db/description.html).
- With a few exceptions header and footer are NOT allowed.
- You can add figures (PNG format), the figure name prefix should be the
- module name. See raster/r.terraflow/description.html for an example.
-
- Note that the parameter information is auto-generated upon
- compilation. This is done by running module in a virtual session
- after compilation (see the output of 'make'). To subsequently
- verify the final HTML page, check the resulting HTML pages which
- will be stored with the name of the module.
-
- Examples (please add some) should be coded like this:
-
- <div class="code"><pre>
- v.to.db map=soils type=area option=area col=area_size unit=h
- </pre></div>
-
- The online WWW man pages will be updated every Saturday by CVS.
-
-
-24. Add/update, if required the related GUI menus:
- gui/tcltk/menus/menu.tcl
-
-
-25. For consistency, use README rather than README.txt for any README files.
-
-
-26. GRASS/Environment variables:
- If you add a new variable, please follow the naming convention.
- All variables are described in
- lib/init/variables.html
-
-
-27. Be sure to develop on top of the LATEST GRASS code (which is in CVS).
- You can re-check before submission with 'cvs diff':
-
- Be sure to create unified ("diff -u") format. "Plain" diffs (the default
- format) are risky, because they will apply without warning to code which
- has been substantially changed; they are also harder to read than unified.
-
- Such diffs should be made from the top-level directory, e.g.
- "cvs diff -u display/d.vect/main.c"; that way, the diff will
- include the pathname rather than just "main.c".
-
-28. Try to use module names which describe shortly the intended purpose of the module.
-
- The first letters for module name should be:
- d. - display commands
- db. - database commands
- g. - general commands
- i. - imagery commands
- p. - paint commands
- ps. - postscript commands
- r. - raster commands
- r3. - raster3D commands
- v. - vector commands
-
- Some additional naming conventions
- * export modules: (type).out.(format) eg: r.out.arc, v.out.ascii
- * import module: (type).in.(format) eg: r.in.arc, v.in.ascii
- * conversion modules: (type).to.(type) eg: r.to.vect, v.to.rast, r3.to.rast
-
- Avoid module names with more than two dots in the name.
- Example:
- instead of r.to.rast3.elev use r.to.rast3elev
-
-28. Use the grass test suite to test your modules.
-
- http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite
-
- You can easily write specific tests for your modules.
-
- If your module is part of grass and you created some standard test cases,
- please contact the developers to add your tests to the default test suite.
- This will automatize complex test scenarios and assure to find bugs much
- faster, if changes were made to your modules or to the grass library.
-
- Consider to subscribe to the GRASS Quality Assessment System to
- get immediate notification about the code quality:
-
- http://grass.itc.it/mailman/listinfo/grass-qa
-
-29. Tell the other developers about the new code using the following e-mail:
- grass-dev at grass.itc.it
-
- To subscribe to this mailing list, see
- http://grass.itc.it/devel/index.php
-
-
-30. In case of questions feel free to contact the developers at the above
- mailing list.
- http://grass.itc.it/devel/index.php#submission
-
-...
-[please add further hints if required]
-
Deleted: grass-addons/SUBMITTING_DOCS
===================================================================
--- grass-addons/SUBMITTING_DOCS 2007-12-12 12:53:13 UTC (rev 29417)
+++ grass-addons/SUBMITTING_DOCS 2007-12-12 13:01:32 UTC (rev 29418)
@@ -1,53 +0,0 @@
-$Id: SUBMITTING_DOCS,v 1.2 2007/11/05 15:26:28 markus Exp $
-
-NOTE: Please improve this list!
-
-Dear (new) GRASS Developer,
-
-When submitting documentation to GRASS CVS repository, please take
-care of following rules:
-
-[ see SUBMITTING_SCRIPTS for shell script hints ]
-[ see SUBMITTING_TCLTK for tcl and tk hints ]
-[ see SUBMITTING for C hints ]
-
-1. Editing of HTML pages
- To avoid insertion of too complicated HTML tags (see also below),
- we strongly suggest to use a plain text editor rather than a
- HTML editor for editing.
-
-2. Module manual page:
- Place the documentation in HTML format into 'description.html'.
- The easiest way to do this is to study an existing HTML page
- (to get the page style, e.g. vector/v.to.db/description.html).
- With a few exceptions header and footer are NOT allowed.
- You can add figures (PNG format), the figure name prefix should be the
- module name. See raster/r.terraflow/description.html for an example.
-
- Note that the parameter information is auto-generated upon
- compilation. This is done by running module in a virtual session
- after compilation (see the output of 'make'). To subsequently
- verify the final HTML page, check the resulting HTML pages which
- will be stored with the name of the module.
-
- Examples (please add some) should be coded like this:
-
- <div class="code"><pre>
- v.to.db map=soils type=area option=area col=area_size unit=h
- </pre></div>
-
- The online WWW man pages is updated every Saturday by CVS.
-
-3. Usage of limited HTML tags
- Since the MAN conversion of g.html2man is limited, please use
- no other HTML tags than:
- <A> <B> <BLINK> <BODY> <BR> <CODE> <DD> <DL> <DT> <EM>
- <H2> <H3> <H4> <HEAD> <HEADER> <HR> <I> <IMG> <LI> <OL> <P>
- <PRE> <SUP> <TABLE> <TD> <TH> <TITLE> <TR> <UL>
-
-See also:
- http://grass.gdf-hannover.de/wiki/Updating_GRASS_Documentation
-
-...
-[please add further hints if required]
-
Deleted: grass-addons/SUBMITTING_SCRIPTS
===================================================================
--- grass-addons/SUBMITTING_SCRIPTS 2007-12-12 12:53:13 UTC (rev 29417)
+++ grass-addons/SUBMITTING_SCRIPTS 2007-12-12 13:01:32 UTC (rev 29418)
@@ -1,188 +0,0 @@
-$Id: SUBMITTING_SCRIPTS,v 1.9 2007/03/23 13:10:45 jachym Exp $
-
-NOTE: Please improve this list!
-
-Dear (new) GRASS Developer,
-
-When submitting SHELL SCRIPTS to GRASS Addons-SVN repositiory,
-please take care of following rules:
-
-[ see SUBMITTING for C code hints ]
-[ see SUBMITTING_TCLTK for tcl and tk hints ]
-
-0. Instructions for the GRASS script parser can be found in the g.parser
- module's help page.
- http://grass.ibiblio.org/grass63/manuals/html63_user/g.parser.html
-
-1. Use the directory structure to place your script appropriately into
- the source tree
- - scripts go into scripts/
-
- Consider to take a look at [please suggest Shell tutorial]
-
-2. Add a header section to the script you submit and make sure you include
- the copyright. The purpose section is meant to contain a general
- overview of the code in the file to assist other programmers that will
- need to make changes to your code.
-
- Example (ficticious header for a script called r.myscript) :
-
-#!/bin/sh
-
-############################################################################
-#
-# MODULE: r.myscript
-# AUTHOR(S): Me <email AT some domain>
-# PURPOSE: Calculates univariate statistics from a GRASS raster map
-# COPYRIGHT: (C) 2005 by the GRASS Development Team
-#
-# This program is free software under the GNU General Public
-# License (>=v2). Read the file COPYING that comes with GRASS
-# for details.
-#
-#############################################################################
-
- The copyright protects your rights according to GNU General Public
- License (www.gnu.org).
-
-3. - deleted.
- We don't want the $ ID $ in scripts any more as it
- causes problems for the CVS branches.
-
-4. As a general principle, shell variables should almost always be quoted.
- Use only secure temp files, see g.tempfile and scripts/* for examples.
-
-5. [This rule is currently under review] If you search for a command in $PATH, do NOT
- use the "which" command or the "type -p" command. Both commands are not
- supported on all platforms, thus causing problems for some people. As an
- alternative, please use code similar to the following shell script snippet
- which will perform the same function. In this case, the path of the grass60
- command is saved if grass60 is found in $PATH. This won't recognize aliased
- command name.
-
- # Search for grass5 command in user's path
- for i in `echo $PATH | sed 's/^:/.:/
- s/::/:.:/g
- s/:$/:./
- s/:/ /g'`
- do
- if [ -f $i/grass5 ] ; then
-
- # Save the path of the grass60 command
- GRASS_PATH=$i/grass60
- # Use the first one in user's path
- break
- fi
- done
-
-<?>
- If you must use "which", use as follows:
-
- # check if we have awk
- if [ ! -x "`which awk`" ] ; then
- g.message -e "awk required, please install awk or gawk first"
- exit 1
- fi
-</?>
-
-6. Add a test to check if the user is in GRASS before starting main part
- of script. Result of running the script is unpredicable otherwise.
-
- if [ -z "$GISBASE" ] ; then
- echo "You must be in GRASS GIS to run this program." 1>&2
- exit 1
- fi
-
- This is the only case, where g.message module (see below) can not be used.
- In all other cases, you should prefer it's usage over the 'echo' command.
-
-7. Create and use secure temporary files and directories. Use the g.tempfile
- module to do this. e.g.
-
- # setup temporary file
- TMP="`g.tempfile pid=$$`"
- if [ $? -ne 0 ] || [ -z "$TMP" ] ; then
- g.message -e "unable to create temporary files"
- exit 1
- fi
-
- For temportary directories remove the newly created file and mkdir using
- the same name. Beware of commands like "rm -f ${TMP}*" as this becomes
- "rm -f *" if $TMP is unset (hence the test above).
-
-8. Testing the existence of variables. For portability, use
- if [ -z "$VARIABLE" ] ; then
- instead of
- if [ "$VARIABLE" == "" ] ; then
-
- and
-
- if [ -n "$VARIABLE" ] ; then
- instead of
- if [ "$VARIABLE" != "" ] ; then
-
-
-9. Internationalization proofing Awk: In some areas (e.g. some European
- countries) the decimal place is held with a comma instead of a dot.
- When scanning variables awk doesn't understand this, so scripts need to
- temporarily discard locale settings before calling awk.
-
- # set environment so that awk works properly in all languages
- unset LC_ALL
- export LC_NUMERIC=C
-
- awk '{print $1}'
-
-
-10. Use g.findfile when there is a need to test if a map exists.
-
- # test for input raster map
- g.findfile element=cell file="$INPUT" > /dev/null
- if [ $? -eq 0 ] ; then
- g.message -e "Input map not found"
- exit 1
- fi
-
-11. For any informational output, use the g.message modul. This module should
- be also used for error messages and warnings. You can also use it for
- debugging purposes.
-
- g.message "Done."
- g.message -w "No input values found, using default values"
- g.message -e "No map found, exiting."
- g.message -d "Our calculated value is: $value"
-
- Try to omit any usage of the 'echo' command for informational output.
-
-12. For consistency, use README rather than README.txt for any README files.
-
-13. Be sure to develop on top of the LATEST GRASS code (which is in CVS).
- You can re-check before submission with 'cvs diff':
-
- Be sure to create unified ("diff -u") format. "Plain"
- diffs (the default format) are risky, because they will apply without
- warning to code which has been substantially changed; they are also
- harder to read than unified.
-
- Such diffs should be made from the top-level directory, e.g.
- "cvs diff -u display/d.vect/main.c"; that way, the diff will
- include the pathname rather than just "main.c".
-
-14. Tell the other developers about the new code using the following e-mail:
- grass-dev at grass.itc.it
-
- To subscribe to this mailing list, see
- http://grass.itc.it/devel/index.php
-
-15. In case of questions feel free to contact the developers at the above
- mailing list.
- http://grass.itc.it/devel/index.php#submission
-
-
-16. For portability, scripts must work on any POSIX compliant shell, and
- therefore may not include any Bashisms. Test with ash for errors:
-
- ash -n scriptname
-
-...
-[please add further hints if required]
Deleted: grass-addons/SUBMITTING_TCLTK
===================================================================
--- grass-addons/SUBMITTING_TCLTK 2007-12-12 12:53:13 UTC (rev 29417)
+++ grass-addons/SUBMITTING_TCLTK 2007-12-12 13:01:32 UTC (rev 29418)
@@ -1,245 +0,0 @@
-NOTE: Please improve this list!
-
-Dear (new) GRASS Developer,
-
-When submitting TCL and TK SCRIPTS and C code to GRASS Addons-SVN repository,
-please take care of following rules:
-
-[ see SUBMITTING for C code hints ]
-[ see SUBMITTING_SCRIPTS for shell script hints ]
-
-1. Use the directory structure to place your program appropriately into
- the source tree
- - general grass tcl/tk libraries and reusable code go into lib/gtcltk
- - user interfaces go in gui/tcltk
- - scripts go in scripts/
- Programs here must have a proper Makefile and description.html
-
-2. Add a header section to the script you submit and make sure you include
- the copyright. The purpose section is meant to contain a general
- overview of the code in the file to assist other programmers that will
- need to make changes to your code.
-
- Example (fictitious header for a script called r.myscript) :
-
-############################################################################
-#
-# MODULE: r.myscript
-# AUTHOR(S): Me <email AT some domain>
-# PURPOSE: Calculates univariate statistics from a GRASS raster map
-# COPYRIGHT: (C) 2005 by the GRASS Development Team
-#
-# This program is free software under the GNU General Public
-# License (>=v2). Read the file COPYING that comes with GRASS
-# for details.
-#
-#############################################################################
-
- The copyright protects your rights according to GNU General Public
- License (www.gnu.org).
-
-3. PLEASE take the time to add comments throughout your code explaining what
- the code is doing. It will save a HUGE amount of time and frustration for
- other programmers that need to change or understand your code in the future.
- Many of the programmers working on grass are not heavily invested in tcl
- and tk, so extra documentation and explanation are greatly appreciated.
-
-4. Test your program with both tcl/tk 8.3 and tcl/tk 8.4.
-
-5. Always use the gettext macros with [G_msg "..."] for user messages.
- The string must be quoted using quotation marks, not braces, for
- xgettext to find it. The string cannot include variable ($) or
- command ([...]) substitutions. If you need substitutions use
- [format ...].
-
- Examples:
- button .ok -text [G_msg "Ok"]
-
- set statusbartext [format [G_msg "Monitor %d running"] $monitor_number]]
-
- Use positional parameters if substitutions might be rearranged in another language:
-
- format [G_msg "We produced %1\$d units in location %2\$s"] $num $city
- format [G_msg "In location %2\$s we produced %1\$d units"] $num $city
-
-6. Use "GRASS_TCLSH" and "GRASS_WISH" environment variables instead of
- "tclsh" and "wish" at the start of Tcl/Tk scripts. This allows users to
- override the default names, so that developers don't need worry about the
- shell names.
-
- Tcl script:
-
- #!/bin/sh
- # the next line restarts using tclsh. Note the backslash: \
- exec $GRASS_TCLSH "$0" "$@"
-
-
- Tk script:
-
- #!/bin/sh
- # the next line restarts using wish. Note the backslash: \
- exec $GRASS_WISH "$0" "$@"
-
-7. Do not source files that have already been sourced.
-
- gui.tcl sources:
- options.tcl
- select.tcl
- gronsole.tcl
-
- If your code requires something to be sourced before it note so
- in a comment at the top of the file.
-
-8. Set tabstops in your editor to 8 spaces.
- When modifying files use the indentation style that is already present.
- Please use consistent indentation style in your new code. Whether you use
- tabs or spaces to indent please be consistent. Where tabs and spaces are
- mixed please remember that a tab is 8 spaces.
-
-9. Use the tk options database to control the appearance of your user interface.
- In general do not set options on tk widgets unless that option is truly
- specific to that widget. It makes them harder to customize.
-
- Example: Don't set options like -foreground or -background or -font
- when creating widgets, unless there's a really _really_ specific reason to
- have it that color (like it's demonstrating that color).
-
- If you want something like a label to look different than everything else
- of that class (other labels) give it a distinctive name, like
- .moduletitlelabel . If you have a bunch of them give them all the same
- distinctive name. This allows them to have their options controlled by the
- options database.
-
- You can put your options at the start of your script (before creating any
- widgets) like this:
- option add *modultitlelabel.background red
- More examples are in lib/gtcltk/options.tcl
-
- Many common options, like font, background and foreground colors,
- highlighting, scrollbar colors, and help bubble appearance are controlled
- by options.tcl. You can include it at the start of your script with:
- source $env(GISBASE)/etc/gtcltk/options.tcl
-
-10. Avoid using global variables. Thay are a frequent source of bugs, make code
- harder to understand, and make your program difficult to reuse. Additionally,
- putting code into procs usually makes it run faster (it gets compiled).
-
-11. For consistency, use README rather than README.txt for any README files.
-
-12. Use of GRASS commands in shell wrapper.
-
- Any GRASS program run in an xterm (those which do interactive query) needs
- to use grass-run.sh, e.g.:
-
- exec -- $env(GISBASE)/etc/grass-xterm-wrapper -e $env(GISBASE)/etc/grass-run.sh g.proj ...
-
- You should probably also use "-T g.proj -n g.proj" to set the title
- back (otherwise it will be "grass-run.sh", which isn't particularly
- informative).
-
- The xterm will close as soon as the command completes (whether it
- succeeds or fails). You can use the -hold switch to retain the xterm
- window after the command completes, but you should only do that for
- debugging; having to manually close the xterm window each time would
- be annoying in normal use. Alternatively, redirect stdout/stderr to a
- file, to catch any error messages.
-
-13. Be sure to develop on top of the LATEST GRASS code (which is in CVS).
- You can re-check before submission with 'cvs diff':
-
- Be sure to create unified ("diff -u") format. "Plain"
- diffs (the default format) are risky, because they will apply without
- warning to code which has been substantially changed; they are also
- harder to read than unified.
-
- Such diffs should be made from the top-level directory, e.g.
- "cvs diff -u display/d.vect/main.c"; that way, the diff will
- include the pathname rather than just "main.c".
-
-14. Tell the other developers about the new code using the following e-mail:
- grass-dev at grass.itc.it
-
- To subscribe to this mailing list, see
- http://grass.itc.it/devel/index.php
-
-15. In case of questions feel free to contact the developers at the above
- mailing list.
- http://grass.itc.it/devel/index.php#submission
-
-16. Try to evaluate things only once. Tcl compiles the program to bytecode which
- can be interpreted fairly quickly. If there are strings that must still be
- evaluated tcl must parse and either compile or interpret them
- each time they are encountered. In general this means put braces around
- expressions and especially regular expressions (Tcl also compiles regular
- expressions). Multiple evaluation can also lead to bugs.
-
- Expressions via expr command:
- Slow:
- set y [expr $a * $x + $b]
- Fast:
- set y [expr {$a * $x + $b}]
-
- Expressions in conditions:
- Slow:
- if [...] {...
- Fast:
- if {[...]} {...
-
- Regular expressions:
- Very slow:
- regex "x(\[0-9\]+).*not" $string trash number
- Fast:
- regex {x([0-9]+).*not} $string trash number
-
- If you really want speed:
- If a regular expression needs to be constructed from variables but used
- multiple times store it in a variable that will not be destroyed or
- changed between reuse. Tcl stores the compiled regex with the variable.
-
-17. You might want to decompose lists in a somewhat easy way:
-
- Difficult and slow:
- # Make x1 y1 x2 y2 the first four things in the list
- set list [commandMakesList]
- set x1 [lindex $list 0]
- set y1 [lindex $list 1]
- set x2 [lindex $list 2]
- set y2 [lindex $list 3]
-
- Easier and faster:
- # Make x1 y1 x2 y2 the first four things in the list
- foreach {x1 y1 x2 y2} [commandMakesList] {break}
-
- Be sure to include a comment as to what you are doing.
-
-18. Use the Tcl list functions (list, lappend etc) for manipulating lists.
-
- For example, use:
-
- set vals [list $foo $bar]
-
- rather than:
-
- set vals "$foo $bar"
-
- The former will always create a list with two elements, adding braces
- if necessary, while the latter will split $foo and $bar into multiple
- elements if they contain spaces. Additionally the first is faster
- because tcl is not internally converting between strings and lists.
-
- A related issue is to remember that command lines (as used by exec and
- open "|...") are lists. exec behaves like execl(), spawnl() etc, and
- not like system().
-
- Overlooking either of these points is likely to result in code which
- fails when a command argument contains a space.
-
-19. Tcl C library:
- Memory allocated with Tcl_Alloc (such as the result of Tcl_Merge)
- must be freed with Tcl_Free. This means that the ->freeProc of
- an interpreter when returning a string using Tcl_Merge should be
- TCL_DYNAMIC. Incorrectly freeing memory with glibc free will
- cause segfaults in Tcl 8.4 and later.
-
-...
-[please add further hints if required]
Modified: grass-addons/SVN_HOWTO.txt
===================================================================
--- grass-addons/SVN_HOWTO.txt 2007-12-12 12:53:13 UTC (rev 29417)
+++ grass-addons/SVN_HOWTO.txt 2007-12-12 13:01:32 UTC (rev 29418)
@@ -16,7 +16,7 @@
PROXY:
-SVN is a tricky software. It ignores any enviroment variables for proxy.
+SVN is a tricky software. It ignores any environment variables for proxy.
If you have to use a proxy server, edit
$HOME/.subversion/servers
and add:
@@ -42,8 +42,15 @@
3. cd grass-addons/
-4. Now work on the repository (see below).
+4. Read submitting instructions before committing any changes!
+
+ http://trac.osgeo.org/grass/browser/grass/trunk/SUBMITTING
+ http://trac.osgeo.org/grass/browser/grass/trunk/SUBMITTING_DOCS
+ http://trac.osgeo.org/grass/browser/grass/trunk/SUBMITTING_SCRIPTS
+ http://trac.osgeo.org/grass/browser/grass/trunk/SUBMITTING_TCLTK
+5. Now work on the repository (see below).
+
########################
We also have a nice Web interface for *reading* (not submitting):
More information about the grass-commit
mailing list