Revision: 75986
http://sourceforge.net/p/brlcad/code/75986
Author: starseeker
Date: 2020-05-31 14:04:45 +0000 (Sun, 31 May 2020)
Log Message:
-----------
Merged changes from trunk through r75985
Modified Paths:
--------------
brlcad/branches/bioh/NEWS
brlcad/branches/bioh/doc/CMakeLists.txt
brlcad/branches/bioh/doc/docbook/system/man3/CMakeLists.txt
brlcad/branches/bioh/doc/docbook/system/man5/CMakeLists.txt
brlcad/branches/bioh/doc/docbook/system/mann/whichid.xml
brlcad/branches/bioh/doc/html/CMakeLists.txt
brlcad/branches/bioh/doc/html/manuals/mged/brlcad_glossary.html
brlcad/branches/bioh/doc/html/manuals/mged/brlcad_solids.html
brlcad/branches/bioh/doc/html/manuals/mged/cmd_line_ed.html
brlcad/branches/bioh/doc/html/manuals/mged/contents.html
brlcad/branches/bioh/doc/html/manuals/mged/default_key_bindings.html
brlcad/branches/bioh/doc/html/manuals/mged/default_mouse_bindings.html
brlcad/branches/bioh/doc/html/manuals/mged/ged.html
brlcad/branches/bioh/doc/html/manuals/mged/index.html
brlcad/branches/bioh/doc/html/manuals/mged/mged.html
brlcad/branches/bioh/doc/html/manuals/mged/mged2.html
brlcad/branches/bioh/doc/html/manuals/mged/mged3.html
brlcad/branches/bioh/doc/html/manuals/mged/mged_callbacks.html
brlcad/branches/bioh/doc/html/manuals/mged/mged_cmd_index.html
brlcad/branches/bioh/doc/html/manuals/mged/mged_env_vars.html
brlcad/branches/bioh/doc/html/manuals/mged/mged_gui.html
brlcad/branches/bioh/doc/html/manuals/mged/mged_tcl_vars.html
brlcad/branches/bioh/doc/html/manuals/mged/preface.html
brlcad/branches/bioh/doc/html/manuals/mged/shaders.html
brlcad/branches/bioh/doc/legal/embedded/CMakeLists.txt
brlcad/branches/bioh/misc/debian/CMakeLists.txt
brlcad/branches/bioh/misc/debian/archer.desktop
brlcad/branches/bioh/misc/debian/brlcad.install
brlcad/branches/bioh/misc/debian/mged.desktop
brlcad/branches/bioh/misc/debian/rtwizard.desktop
brlcad/branches/bioh/misc/debian/rules
brlcad/branches/bioh/regress/repository/repocheck.cpp
brlcad/branches/bioh/sh/make_rpm.sh
brlcad/branches/bioh/src/archer/CMakeLists.txt
brlcad/branches/bioh/src/libbn/poly.c
brlcad/branches/bioh/src/libdm/dm-X.c
brlcad/branches/bioh/src/libdm/dm-ogl.c
brlcad/branches/bioh/src/libdm/dm-osgl.cpp
brlcad/branches/bioh/src/libdm/dm-qt.cpp
brlcad/branches/bioh/src/libdm/dm-tk.c
brlcad/branches/bioh/src/libdm/dm-wgl.c
brlcad/branches/bioh/src/libged/CMakeLists.txt
brlcad/branches/bioh/src/libged/comb.c
brlcad/branches/bioh/src/libged/search.c
brlcad/branches/bioh/src/libpkg/pkg.c
brlcad/branches/bioh/src/librt/roots.c
brlcad/branches/bioh/src/shapes/bolt.c
brlcad/branches/bioh/src/shapes/gastank.c
brlcad/branches/bioh/src/shapes/handle.c
brlcad/branches/bioh/src/shapes/window.c
brlcad/branches/bioh/src/shapes/window_frame.c
brlcad/branches/bioh/src/shapes/wire.c
brlcad/branches/bioh/src/tclscripts/libdm.tcl
brlcad/branches/bioh/src/tclscripts/mged/bindings.tcl
Added Paths:
-----------
brlcad/branches/bioh/doc/README.other/
brlcad/branches/bioh/doc/docbook/system/man3/libpkg.xml
brlcad/branches/bioh/doc/docbook/system/man5/benchmark.xml
brlcad/branches/bioh/doc/legal/embedded/alphanum.txt
brlcad/branches/bioh/doc/notes/
brlcad/branches/bioh/src/archer/archer_ack.txt
brlcad/branches/bioh/src/libged/alphanum.h
brlcad/branches/bioh/src/libged/which.cpp
Removed Paths:
-------------
brlcad/branches/bioh/doc/README.AIX
brlcad/branches/bioh/doc/README.BSD
brlcad/branches/bioh/doc/README.IRIX
brlcad/branches/bioh/doc/README.OSCON-2014
brlcad/branches/bioh/doc/README.Solaris
brlcad/branches/bioh/doc/README.VAX
brlcad/branches/bioh/doc/TODO.BREP
brlcad/branches/bioh/doc/TODO.shaded_displays
brlcad/branches/bioh/doc/archer_ack.txt
brlcad/branches/bioh/doc/benchmark.tr
brlcad/branches/bioh/doc/brep.txt
brlcad/branches/bioh/doc/bsd_semaphore_bug.txt
brlcad/branches/bioh/doc/bu_opt_design_notes.txt
brlcad/branches/bioh/doc/c_cxx_patterns/
brlcad/branches/bioh/doc/cmake_vars.txt
brlcad/branches/bioh/doc/csv_to_comgeom.txt
brlcad/branches/bioh/doc/cvs.txt
brlcad/branches/bioh/doc/ecosystem.dot
brlcad/branches/bioh/doc/editors.txt
brlcad/branches/bioh/doc/ged.tr
brlcad/branches/bioh/doc/history.txt
brlcad/branches/bioh/doc/html/manuals/mged/concl.html
brlcad/branches/bioh/doc/html/manuals/mged/mged1.html
brlcad/branches/bioh/doc/html/manuals/mged/notes.html
brlcad/branches/bioh/doc/html/manuals/mged/outline
brlcad/branches/bioh/doc/html/manuals/mged/skipped
brlcad/branches/bioh/doc/hypot.txt
brlcad/branches/bioh/doc/implicit_constraints.txt
brlcad/branches/bioh/doc/irprep.tr
brlcad/branches/bioh/doc/lcov.txt
brlcad/branches/bioh/doc/mater.txt
brlcad/branches/bioh/doc/matrix.txt
brlcad/branches/bioh/doc/mk.tr
brlcad/branches/bioh/doc/parsers/
brlcad/branches/bioh/doc/pkg.tr
brlcad/branches/bioh/doc/regions.txt
brlcad/branches/bioh/doc/rounding.txt
brlcad/branches/bioh/doc/tool_categories.txt
brlcad/branches/bioh/doc/trunk_hierarchy.org
brlcad/branches/bioh/misc/debian/brlcad-doc-animation.desktop
brlcad/branches/bioh/src/libged/which.c
Property Changed:
----------------
brlcad/branches/bioh/
brlcad/branches/bioh/NEWS
brlcad/branches/bioh/doc/
brlcad/branches/bioh/regress/
Index: brlcad/branches/bioh
===================================================================
--- brlcad/branches/bioh 2020-05-29 16:33:10 UTC (rev 75985)
+++ brlcad/branches/bioh 2020-05-31 14:04:45 UTC (rev 75986)
Property changes on: brlcad/branches/bioh
___________________________________________________________________
Modified: svn:mergeinfo
## -7,4 +7,4 ##
/brlcad/branches/osg:62110-62113
/brlcad/branches/prep-cache:68236-68933
/brlcad/branches/tcltk86:68300-75257
-/brlcad/trunk:75720-75933
\ No newline at end of property
+/brlcad/trunk:75720-75985
\ No newline at end of property
Modified: brlcad/branches/bioh/NEWS
===================================================================
--- brlcad/branches/bioh/NEWS 2020-05-29 16:33:10 UTC (rev 75985)
+++ brlcad/branches/bioh/NEWS 2020-05-31 14:04:45 UTC (rev 75986)
@@ -13,6 +13,7 @@
--- 20XX-XX-XX Release 7.3X.X ---
----------------------------------------------------------------------
+* improved output path sorting of search command - Cliff Yapp
* added 3dm-g failure message about supported versions - Cliff Yapp
* fixed bw-png writing corrupted png files on Windows - Sean Morrison
Property changes on: brlcad/branches/bioh/NEWS
___________________________________________________________________
Modified: svn:mergeinfo
## -7,4 +7,4 ##
/brlcad/branches/osg/NEWS:62110-62113
/brlcad/branches/prep-cache/NEWS:68236-68933
/brlcad/branches/tcltk86/NEWS:68300-75257
-/brlcad/trunk/NEWS:75728-75834
\ No newline at end of property
+/brlcad/trunk/NEWS:75728-75834,75934-75985
\ No newline at end of property
Index: brlcad/branches/bioh/doc
===================================================================
--- brlcad/branches/bioh/doc 2020-05-29 16:33:10 UTC (rev 75985)
+++ brlcad/branches/bioh/doc 2020-05-31 14:04:45 UTC (rev 75986)
Property changes on: brlcad/branches/bioh/doc
___________________________________________________________________
Modified: svn:mergeinfo
## -7,4 +7,4 ##
/brlcad/branches/osg/doc:62110-62113
/brlcad/branches/prep-cache/doc:68236-68933
/brlcad/branches/tcltk86/doc:68300-75257
-/brlcad/trunk/doc:75728-75834
\ No newline at end of property
+/brlcad/trunk/doc:75728-75834,75934-75985
\ No newline at end of property
Modified: brlcad/branches/bioh/doc/CMakeLists.txt
===================================================================
--- brlcad/branches/bioh/doc/CMakeLists.txt 2020-05-29 16:33:10 UTC (rev
75985)
+++ brlcad/branches/bioh/doc/CMakeLists.txt 2020-05-31 14:04:45 UTC (rev
75986)
@@ -2,45 +2,30 @@
verbose_add_subdirectory(doc html)
verbose_add_subdirectory(doc legal)
-CMAKEFILES(
- parsers/bison_to_lemon.txt
- parsers/flex_to_re2c.txt
- parsers/templates/CMakeLists.txt
- parsers/templates/main.c
- parsers/templates/main.h
- parsers/templates/parser.lemon
- parsers/templates/scanner.perplex
- parsers/writing_perplex_lemon_parsers.txt
- )
-
set(documentation_DATA
+ BRL-CAD.bib
IDEAS
PROJECTS
- README.AIX
- README.BSD
- README.IRIX
README.Linux
README.MacOSX
- README.Solaris
- README.VAX
README.Windows
- TODO.BREP
- TODO.shaded_displays
- archer_ack.txt
- benchmark.tr
- bu_opt_design_notes.txt
- brep.txt
- BRL-CAD.bib
+ README.other/README.AIX
+ README.other/README.BSD
+ README.other/README.IRIX
+ README.other/README.Solaris
+ README.other/README.VAX
checklist.txt
- cvs.txt
description.txt
- editors.txt
- ged.tr
- history.txt
- hypot.txt
- irprep.tr
- mater.txt
- matrix.txt
+ notes/TODO.BREP
+ notes/TODO.shaded_displays
+ notes/brep.txt
+ notes/bu_opt_design_notes.txt
+ notes/cvs.txt
+ notes/editors.txt
+ notes/history.txt
+ notes/hypot.txt
+ notes/mater.txt
+ notes/matrix.txt
pre_BRL-CAD.bib
)
ADD_DOC(documentation_DATA ".")
@@ -210,13 +195,11 @@
mged/wm-leg1.ps
mged/wm-prims.ps
mged/wm-tube.ps
- mk.tr
+ notes/ecosystem.dot
+ notes/regions.txt
+ notes/rounding.txt
+ notes/tool_categories.txt
old-mged.tr
- pkg.tr
- regions.txt
- rounding.txt
- tool_categories.txt
- ecosystem.dot
)
ADD_DOC(documentation_mged_old_DATA mged_old)
@@ -225,44 +208,55 @@
CMAKEFILES(
CMakeLists.txt
- README.OSCON-2014
+ README.other/README.OSCON-2014
STARTERS
STRATEGY
- bsd_semaphore_bug.txt
- cmake_vars.txt
- csv_to_comgeom.txt
- implicit_constraints.txt
- lcov.txt
+ notes/bsd_semaphore_bug.txt
+ notes/cmake_vars.txt
+ notes/csv_to_comgeom.txt
+ notes/implicit_constraints.txt
+ notes/lcov.txt
pad_file.xml.in
- trunk_hierarchy.org
)
# Generic C/C++ examples
CMAKEFILES(
- c_cxx_patterns/01_basic_C/CMakeLists.txt
- c_cxx_patterns/01_basic_C/main.c
- c_cxx_patterns/01_basic_C/nlib.c
- c_cxx_patterns/01_basic_C/nlib.h
- c_cxx_patterns/02_hidden_C/CMakeLists.txt
- c_cxx_patterns/02_hidden_C/main.c
- c_cxx_patterns/02_hidden_C/nlib.c
- c_cxx_patterns/02_hidden_C/nlib.h
- c_cxx_patterns/03_PImpl_C/CMakeLists.txt
- c_cxx_patterns/03_PImpl_C/main.c
- c_cxx_patterns/03_PImpl_C/nlib.c
- c_cxx_patterns/03_PImpl_C/nlib.h
- c_cxx_patterns/04_hidden_CXX/CMakeLists.txt
- c_cxx_patterns/04_hidden_CXX/main.c
- c_cxx_patterns/04_hidden_CXX/nlib.cxx
- c_cxx_patterns/04_hidden_CXX/nlib.h
- c_cxx_patterns/05_PImpl_CXX/CMakeLists.txt
- c_cxx_patterns/05_PImpl_CXX/main.c
- c_cxx_patterns/05_PImpl_CXX/nlib.cxx
- c_cxx_patterns/05_PImpl_CXX/nlib.h
- c_cxx_patterns/CMakeLists.txt
- c_cxx_patterns/README
+ notes/c_cxx_patterns/01_basic_C/CMakeLists.txt
+ notes/c_cxx_patterns/01_basic_C/main.c
+ notes/c_cxx_patterns/01_basic_C/nlib.c
+ notes/c_cxx_patterns/01_basic_C/nlib.h
+ notes/c_cxx_patterns/02_hidden_C/CMakeLists.txt
+ notes/c_cxx_patterns/02_hidden_C/main.c
+ notes/c_cxx_patterns/02_hidden_C/nlib.c
+ notes/c_cxx_patterns/02_hidden_C/nlib.h
+ notes/c_cxx_patterns/03_PImpl_C/CMakeLists.txt
+ notes/c_cxx_patterns/03_PImpl_C/main.c
+ notes/c_cxx_patterns/03_PImpl_C/nlib.c
+ notes/c_cxx_patterns/03_PImpl_C/nlib.h
+ notes/c_cxx_patterns/04_hidden_CXX/CMakeLists.txt
+ notes/c_cxx_patterns/04_hidden_CXX/main.c
+ notes/c_cxx_patterns/04_hidden_CXX/nlib.cxx
+ notes/c_cxx_patterns/04_hidden_CXX/nlib.h
+ notes/c_cxx_patterns/05_PImpl_CXX/CMakeLists.txt
+ notes/c_cxx_patterns/05_PImpl_CXX/main.c
+ notes/c_cxx_patterns/05_PImpl_CXX/nlib.cxx
+ notes/c_cxx_patterns/05_PImpl_CXX/nlib.h
+ notes/c_cxx_patterns/CMakeLists.txt
+ notes/c_cxx_patterns/README
)
+# Notes about parser generators
+CMAKEFILES(
+ notes/parsers/bison_to_lemon.txt
+ notes/parsers/flex_to_re2c.txt
+ notes/parsers/templates/CMakeLists.txt
+ notes/parsers/templates/main.c
+ notes/parsers/templates/main.h
+ notes/parsers/templates/parser.lemon
+ notes/parsers/templates/scanner.perplex
+ notes/parsers/writing_perplex_lemon_parsers.txt
+ )
+
# Local Variables:
# tab-width: 8
# mode: cmake
Deleted: brlcad/branches/bioh/doc/README.AIX
===================================================================
--- brlcad/branches/bioh/doc/README.AIX 2020-05-29 16:33:10 UTC (rev 75985)
+++ brlcad/branches/bioh/doc/README.AIX 2020-05-31 14:04:45 UTC (rev 75986)
@@ -1,35 +0,0 @@
-BRL-CAD on AIX README
-=====================
-
-Dec. 15, 2011 - As of this date, it has been some time since an AIX
-build of BRL-CAD has been tested, and thus far it has NOT been tested
-b with the new CMake build system.
-
-Kitware provides an AIX powerpc binary for CMake, see
-http://www.cmake.org/cmake/resources/software.html
-
-
-Building BRL-CAD under AIX is fairly straightforward using a correctly
-installed version on the GCC compiler. If, however, you are using the
-IBM Visual Age compiler, then there are additional manual compilation
-steps that will be necessary. In particular, the IBM compiler and
-associated standard C library headers are inconsistent with respect to
-ANSI/POSIX compliance compiler options.
-
-The IBM compiler supports a variety of compliance options, the two of
-particular relevance to building BRL-CAD (in terms of being the close
-to obtaining a functional compile) are the strict compliance
-(-qlanglvl=stdc89) or "extended" compliance (-qlanglvl=extc89) modes.
-Problems encountered in our build environment using strict compliance
-does mostly work though we ran into errors in the standard C library
-headers.
-
-Using the "extended" compliance mode resolved the standard C library
-header issues, but introduces problems in the compilation of BRL-CAD
-as the compiler then disables the provision of the __STDC__
-preprocessor symbol. BRL-CAD then defaults back to K&R mode, which
-the compiler verbosely refuses to compile. The "quick fix" that has
-been used in the past is to simply swap the compiler between the two
-modes as when one fails (e.g. strict), the other usually succeeds
-(e.g. extended). Barring that working, you can use extended mode and
-define __STDC__ manually.
Deleted: brlcad/branches/bioh/doc/README.BSD
===================================================================
--- brlcad/branches/bioh/doc/README.BSD 2020-05-29 16:33:10 UTC (rev 75985)
+++ brlcad/branches/bioh/doc/README.BSD 2020-05-31 14:04:45 UTC (rev 75986)
@@ -1,16 +0,0 @@
-BRL-CAD on BSD README
-=====================
-
-BRL-CAD is frequently compiled under various variants of
-BSD including FreeBSD, NetBSD, OpenBSD, and even the original
-4.3 BSD (though now rare) - FreeBSD is the most common BSD
-platform tested, not counting Mac OSX. See the README.VAX
-document for additional details that pertain to building
-BRL-CAD on a VAX running BSD.
-
-CMake binaries for *BSD operating systems are not distributed
-by Kitware, but should be available through standard *BSD
-packaging mechanisms. Failing that, CMake can be bootstrapped
-without much difficulty on most modern Unix-style platforms.
-
-BRL-CAD is included in the FreeBSD Ports system.
Deleted: brlcad/branches/bioh/doc/README.IRIX
===================================================================
--- brlcad/branches/bioh/doc/README.IRIX 2020-05-29 16:33:10 UTC (rev
75985)
+++ brlcad/branches/bioh/doc/README.IRIX 2020-05-31 14:04:45 UTC (rev
75986)
@@ -1,51 +0,0 @@
-BRL-CAD on IRIX README
-======================
-
-Building on IRIX is one of the most tricky platforms to support
-without installing up-to-date compilation tools. That said, the build
-has and should work just fine with either the MIPSPro or GCC
-compilers. The best performance is usually achieved with the MIPSPro
-compiler, whereas GCC will compile faster with less fuss.
-
-Kitware provides CMake binaries for IRIX64 platforms:
-http://www.cmake.org/cmake/resources/software.html
-
-
-Parallel building
------------------
-For parallel compilation on IRIX, the -P option enables parallel
-build mode and the PARALLEL environment variable sets the number
-of CPUs (default is two):
-
-PARALLEL=4 make -P
-
-
-Potential problems you may encounter
-------------------------------------
-
-Symptom: MIPSPro linker reports symbol(s) missing
-
-Description: There's a known bug in the MIPSpro linker involving
-rpaths that are too long (namely longer than 255 characters) so care
-should be taken to not compile in directories that are too deep. The
-way this bug is usually seen is that the build will fail during
-compilation where unresolved symbols are reported during linking,
-symbols that are correctly included in the libraries being linked.
-
-Workaround: It is usually sufficient to retry the compile from a
-shorter path. (e.g., /tmp instead of /some/deep/path/to/brlcad)
-
----
-
-Symptom: GCC crashes during compilation with internal errors
-
-Description: Certain versions of the gcc compiler are known to crash
-with internal error messages, for example on src/mged/animedit.c, when
-using optimization flags (i.e. -O3).
-
-Workaround: Compile in whatever directory is failing with -O0 instead:
- cd src/mged
- sed -i "s/ -O3 / -O0 /g" CMakeFiles/mged.dir/flags.make
- make
- cd ../..
- make
Deleted: brlcad/branches/bioh/doc/README.OSCON-2014
===================================================================
--- brlcad/branches/bioh/doc/README.OSCON-2014 2020-05-29 16:33:10 UTC (rev
75985)
+++ brlcad/branches/bioh/doc/README.OSCON-2014 2020-05-31 14:04:45 UTC (rev
75986)
@@ -1,53 +0,0 @@
-BRL-CAD: A Vibrant Open Source Model
-
-+ intro
-
- - speaker
-
- - old vs. new (Rurel's joke about old farmer and his young farmhand)
-
-+ overview
-
- - history, players
-
- Mike Muuss [author of ping]
-
- - license
-
- - languages (Ohloh stats)
-
-+ important technical features
-
- - database format
-
- - tools
-
- - libraries
-
- - use of other FOSS libraries
-
- - road map
-
-+ other features
-
-+ community
-
- - players (Ohloh stats)
-
-+ process
-
- - Source Forge
-
- - API changes
-
- - deprecation policy
-
- - release procedures
-
- - version control
-
- - bug tracking
-
-- policy
-
-- outreach
Deleted: brlcad/branches/bioh/doc/README.Solaris
===================================================================
--- brlcad/branches/bioh/doc/README.Solaris 2020-05-29 16:33:10 UTC (rev
75985)
+++ brlcad/branches/bioh/doc/README.Solaris 2020-05-31 14:04:45 UTC (rev
75986)
@@ -1,61 +0,0 @@
-BRL-CAD on Solaris README
-=========================
-In recent years, there have been a variety of Solaris-style operating
-systems that have appeared, following Sun's open-source release of
-OpenSolaris. OpenSolaris itself doesn't seem to be especially active, but
-another derivative system called OpenIndiana has appeared, based on the
-illumos kernel - the Solaris file will be the place to add any notes
-needed to build on such derivative systems, as well as Solaris proper.
-
-Kitware does not provide a pre-compiled binary for CMake on Solaris
-type systems. To bootstrap from the source code, try the following:
-
-(You probably want to use gmake and gcc/g++ for this...)
-
-1. Download the source from http://www.cmake.org/cmake/resources/software.html
-2. unzip the tarball: gunzip cmake-X.Y.Z.tar.gz
-3. open the tarball: tar -xvf cmake-X.Y.Z.tar
-4. cd cmake-X.Y.Z
-5. CXX=g++ ./bootstrap -prefix=/home/user/cmake-install (or your preferred
directory)
-6. gmake
-7. gmake install
-
-Then (if you installed to somewhere other than a system dir) add the
-bin directory to your path:
-
-csh: setenv PATH /home/user/cmake-install/bin:$PATH
-bash: export PATH=/home/user/cmake-install/bin:$PATH
-
-From there, you should be good to build BRL-CAD. The most recent tests
-of the Sun Studio compiler suggest that there are issues to resolve,
-so (unless you want to fix those issues, which would be welcome!) you
-probably want to use the GCC compiler suite to build BRL-CAD as well:
-
-CC=gcc CXX=g++ cmake ../brlcad
-
-If while compiling you encounter an error "Text relocation remains
-against symbol" along with some number of lines following, it usually
-means that the build has attempted to link a static system library
-into a shared library being compiled (e.g. attempting to link a system
-libz.a into the png library distributed in src/other/libpng being
-compiled as libpng.so). If this happens, it likely indicates a problem
-with the CMake build logic and should be reported as a bug - you may also
-need to install a shared version of the library. Another possibility
-would be to add -mipure-text to the linker flags.
-
-OpenIndiana
------------
-
-To build with gcc and CMake on OpenIndiana, you need to install the
-following packages:
-
-pkg install pkg:/developer/gcc-7
-pkg install pkg:/developer/build/cmake
-pkg install pkg:/developer/versioning/subversion
-pkg install pkg:/system/header
-pkg install pkg:/developer/lexer/flex
-
-(Note that gcc-7 building doesn't work as of 2017-08-23 - the above
-install list is a starting point, but the repo currently doesn't
-build and isn't close to building. It may be an older gcc would
-have better luck...)
Deleted: brlcad/branches/bioh/doc/README.VAX
===================================================================
--- brlcad/branches/bioh/doc/README.VAX 2020-05-29 16:33:10 UTC (rev 75985)
+++ brlcad/branches/bioh/doc/README.VAX 2020-05-31 14:04:45 UTC (rev 75986)
@@ -1,43 +0,0 @@
-BRL-CAD on VAX README
-=====================
-
-One of the first systems to run BRL-CAD was the VAX. In particular, a
-VAX 11/780 named VGR is the baseline reference machine for the BRL-CAD
-Benchmark suite. Through the 80's and most of the 90's, BRL-CAD was
-compiled for and maintained on VGR running 4.3 BSD until the hardware
-was finally decommissioned.
-
-BRL-CAD has been successfully compiled for and run under the simh
-Computer History Simulation Project's VAX simulator. Using this
-simulator, it's feasible to install one of the BSD variants
-(e.g. NetBSD) and the GCC compiler.
-
-No one has tried bootstrapping CMake on a VAX simh NetBSD image yet, so it
-is not known what problems may occur - the basic bootstrap procedure is:
-
-1. Download the source from http://www.cmake.org/cmake/resources/software.html
-2. unzip the tarball: gunzip cmake-X.Y.Z.tar.gz
-3. open the tarball: tar -xvf cmake-X.Y.Z.tar
-4. cd cmake-X.Y.Z
-5. CXX=g++ ./bootstrap -prefix=/home/user/cmake-install (or your preferred
directory)
-6. gmake
-7. gmake install
-
-As of the last effort involved in compiling BRL-CAD under this
-environment (using GNU Autotools), there were a few steps
-necessary that included the following:
-
- - Define the preprocessor symbol "vax".
-
- - Disable compilation of libfft and sig. The FFT library builds
- convolution kernels that are too large for the usual VAX memory
- sizes.
-
- - Compile against libm.a instead of libm.so. The shared object
- library (at least under NetBSD) is buggy and will cause run-time
- bus errors (i.e. rt will crash). With CMake, you might try:
- -DM_LIBRARY=/usr/lib/libm.a
-
-After those steps, you should at least be able to perform a benchmark
-compilation (i.e. "make benchmark"), raytrace images, and obtain
-performance metrics.
Deleted: brlcad/branches/bioh/doc/TODO.BREP
===================================================================
--- brlcad/branches/bioh/doc/TODO.BREP 2020-05-29 16:33:10 UTC (rev 75985)
+++ brlcad/branches/bioh/doc/TODO.BREP 2020-05-31 14:04:45 UTC (rev 75986)
@@ -1,304 +0,0 @@
-BREP TODO
-=========
-
-Included below is a basic work breakdown related to the implementation
-of boundary representation (BREP) support in BRL-CAD. Feel free to
-add to or expand this list and/or embellish it with additional
-information as appropriate. If you would like to work on the BREP
-implementation, send a note to the brlcad-devel mailing list.
-
-This file is a general scratch pad for categorizing and itemizing BREP
-implementation tasks. It is not an implementation plan.
-
-This is a work in progress.
-
-
-Geometry Entities
------------------
-
-point
-line (e.g., line segment, ray, bidirectionally infinite line)
-line set (e.g., polyline, polygon)
-curve (e.g., spline, arc, circle, ellipse)
-plane
-surface (e.g., spline, polygonal)
-surface+curve (i.e. a trimmed surface)
-solid
-
-
-Geometry Evaluation
--------------------
-
-point -> point
-point -> line
-point -> curve
-point -> plane
-point -> surface
-point -> surface+curve
-point -> solid
-
-line -> line
-line -> curve
-line -> plane
-line -> surface
-line -> surface+curve
-line -> solid
-
-curve -> curve
-curve -> plane
-curve -> surface
-curve -> surface+curve
-curve -> solid
-
-plane -> plane
-plane -> surface
-plane -> surface+curve
-plane -> solid
-
-surface -> surface
-surface -> surface+curve
-surface -> solid
-
-surface+curve -> surface+curve
-surface+curve -> solid
-
-solid -> solid
-
-
-Geometry Queries
-----------------
-
-[ geometric properties ]
-intersects
-inside
-outside
-on
-intersectionSet
-firstIntersectionSet
-closestDistance
-closestSet (e.g., closestPoint)
-booleanEvaluation
-insideSet (e.g., insideSolid, insideLoop (trimmed))
-outsideSet
-onSet
-
-[ parametric properties ]
-uvSpace <--> ImageSpace Mapping (for ALL primitive types)
-curvatures
-normalSet (e.g., normalVector, normalPlane)
-tangentSet (e.g., tangentVectors, tangentPlanes)
-
-[ checks ]
-isValid
-isSolid
-isManifold
-isFlat
-
-[ bounding volumes ]
-boundingBox
-boundingSphere
-
-
-Geometry Modifiers
-------------------
-
-scale
-rotate
-translate
-shear
-
-mirror
-copy/clone
-delete
-
-invertRepresentation
-evaluateBoolean (i.e. CSG)
-snapTogether (e.g., | -)
-
-sweep
-extrude
-revolve
-extend/stretch
-
-trim (e.g., cutting plane)
-split (i.e. copy and two trims)
-
-fillet
-chamfer
-
-
-Ray Tracing
------------
-
-intersectionSet query
- boundingBox
- line -> solid evaluation
-normalSet query
- line -> solid evaluation
-
-line->solid evaluation
- line->surface || line->plane
-
-line->plane
- line->line
-
-line->surface
- line->curve || line->line
- closestDistance
-
-closestDistance
- point->plane
- point->point
-
-line->curve
- line->point
-
-line->line
- line->point
-
-line->point
- point->point
-
-
-Interactive Visualization
--------------------------
-
-implicit primitive to solid conversion
-solid on solid CSG evaluation (i.e. unevaluated to evaluated BREP)
-solid tessellation
-
-
-Conversion
-----------
-
-3DM to BRL-CAD
-BRL-CAD to 3DM
-STEP to BRL-CAD
-IGES to BRL-CAD
-BRL-CAD to STEP
-BRL-CAD to IGES
-
-
-********************************************************************************
- Below are some thoughts and notes about specific issues related to the above
- topics - may be useful as comments at some point, or at least food for
thought.
-********************************************************************************
-
-/*
- * Point-Point Evaluation
- *
- * Answer Evaluation Questions involving two points:
- *
- * 1. Intersection - for a point, there are three possible categories of of
intersection:
- * * Identical - point values identical and all bound values identical
- *
- * * * * * * * * *
- * * *
- * * 1 2 *
- * * * *
- * * *
- * * *
- * * * * * * * * *
- *
- * * Contained - values not all identical but bounds of the point of
interest all smaller than bounds of
- * point it is being compared to
- *
- *
- * * * * * * * * * * * * * * * * * * *
* *
- * * 1 * *
*
- * * * * * * * * * * * * * *
*
- * * * * * * * 1 *
*
- * * * 2 * * * * *
*
- * * * * * * * 2 *
*
- * * * * * * * * * * * * * *
*
- * * * * * * * * * * * * * * * * * * *
* *
- *
- *
- * * Overlapping - values not all identical but bounds of the point of
interest all overlap bounds of
- * the point it is being compared to. (Note: a corner
case is when the value of the upper
- * bound of one point is equal to the lower bound of the
other - this is defined to be
- * overlapping.)
- *
- *
- * * * * * * * * * * * * * * * * *
* * * * * * * *
- * * * * *
* *
- * * 1 * * * * * * * * * * *
* * * * * * * * * *
- * * * * * * * * * * * * 1 * *
* * 1 * *
- * * * * * * * * *
* * * *
- * * * * * * * * * * * * * * * * * * *
* * 2 * *
- * * 2 * * 2 *
* * * * * * * * *
- * * * * *
* *
- * * * * * * * * * * * * * * * * * *
* * * * * * * * *
- *
- *
- * 2. Outside - "If the points are not identical in value and/or error
bounds, is the point of interest and its error
- * bounds contained or overlapping with the comparison point, or vice
versa? If not, the point of interest is
- * outside the comparison point.
- *
- * Contained and Overlapping points present a problem. Take the case
where two points have an overlapping bound
- * and a third point must decide its relationship with each of them:
- *
- * * * * * * * * *
- * * *
- * * 1 *
- * * *
- * * * * * * * * * * * * * * * * *
- * * * * * * *
- * * * * * * * * * * *
- * * 2 * * 3 *
- * * * * *
- * * * * *
- * * * * * * * * * * * * * * * * *
- *
- * Point 1 and Point 2 overlap and may intersect. When Point 3
evaluates its relationships with Point 1 and
- * Point 2, it finds that it overlaps and may intersect Point 1, but it
does NOT overlap Point 3. This means
- * that Point 1 may intersect Point 2 OR Point 3, but NOT both at the
same time. Any assumption of equality
- * involving any of these three points must decide how to handle this
situation, and the decision must be both
- * consistent and reproducible. The possible decisions are:
- *
- * 1 = 2, 1 != 3
- * 1 != 2, 1 = 3
- *
- * In order to have a concrete method for deciding this question, point
evaluation cannot be a local, two point
- * only test. It is necessary to search out all points which overlap
the two points in question (i.e. the only
- * points which might impact the decisions of which points are identical
in this particular case) and resolve the
- * question amongst all of them. One possibility would be to assemble
all the guaranteed non-equalities among
- * the set, search for the shortest distance between values among the
remaining possible relationships, and assign
- * intersection status based on those results. (This may not be
sufficient - bounding box size may also be
- * important.) For the original two points supplied, the question of
intersection or non-intersection is now
- * resolved as long as no geometry changes are made to any element that
has bounds overlapping their individual
- * bound.
- *
- * Once this near space evaluation is done, each point's list of
intersecting and non-intersecting points is updated.
- * A query routine with two points can first check the points' own
intersection/non-intersection lists to see if
- * the answer is already pre-determined. If it is not, determining via
the bounds inside/outside is straightforward
- * and deterministic and it cannot be intersecting.
- *
- * One question is what to do when the geometry DOES change. New
geometry may potentially change the decisions
- * on what is and is not intersecting - perhaps it should? Potential
trouble there with overlapping vs. non-
- * overlapping regions.
- */
-
-SOLID NURBS RAYTRACING ROBUSTNESS IMPROVEMENT/REFINEMENT
-
-One of the difficult tasks with solid raytracing is determining reliably when
we're inside or outside in cases where
-BRep edges don't exactly join up geometrically. OpenNURBS has tolerances
which define such shapes as "valid", but the
-mathematics of the ray interesection will still report wonky results once hit
points get inside those tolerance regions.
-
-We have resolution logic that tries to handle ambiguous cases, but one
potential technique we are not currently using
-would use the bounding box information from the NURBS prep trees to augment
that logic's robustness (or, more precisely,
-bound the portions of the ray segment within which point ambiguities need to
be resolved.)
-
-The current thought is to use the not-on-surface-point bounding box points
(which we can categorize as inside or outside
-relative to the surface they are bounding by construting vectors from on
surface points to those points and comparing
-them to the surface normal vectors) and the surface points themselves to
construct an outer and inner bounding volume
-for the BRep (to be reliable, we would also have to take care that we refine
enough to avoid self intersections in
-those volumes.) The overall bounding box of the outer volume should always be
larger than that of the inner volume,
-so a comparison of those would allow us to flip them if the "wrong" box is too
big to deal with a BRep with inverted
-surface normals. (Might actually also allow us to reliably detect and fix
such BReps, but that's a different topic.)
-
-Once we have the outer bounding volume, we intersect that along with the NURBS
BRep itself and use the ray segments
-from the outer bounding volume as bounding regions within which we resolve any
point ambiguities. This should allow
-us to "locally" resolve issues in such a way that doesn't accidentally flag
(say) a grazing corner hit as the in
-hit for a clean hit pair much further down the shotline (which will result in
a long "solid" segment through empty
-space.)
Deleted: brlcad/branches/bioh/doc/TODO.shaded_displays
===================================================================
--- brlcad/branches/bioh/doc/TODO.shaded_displays 2020-05-29 16:33:10 UTC
(rev 75985)
+++ brlcad/branches/bioh/doc/TODO.shaded_displays 2020-05-31 14:04:45 UTC
(rev 75986)
@@ -1,122 +0,0 @@
-Consolidated from an e-mail thread and several e-mail messages by Sean
-to the BRL-CAD developers list in Jun 2013 which includes this message:
-
-https://sourceforge.net/mailarchive/forum.php?thread_name=02c584af-d1ad-4d23-9837-1412eed14350%40me.com&forum_name=brlcad-devel
-
-> 4. Finally we will get rid of wireframes. However, we will be able
-> to easily enable or disable shaded geometry or vice versa.
-
-We're not getting rid of wireframes. Shaded display geometry becoming
-the default, however, is already planned and in the works. NURBS
-surface-surface intersections (Wu's project) are required for that to
-happen.
-
-...
-
-Making wireframes not be the default is one of several reasons why
-we've been working on NURBS infrastructure. Not understanding why
-this is required given our representation format is usually an
-indication that someone does not yet understand the fundamental
-problem... which is not meant to be taken in a negative way. MOST
-people don't have experience with our particular problem domain which
-is specific to having mathematically-based implicit geometry
-representations along with boolean operations.
-
-When most people say shaded display, they usually think of OpenGL,
-Direct3D, games, other modeling systems, etc. Those systems are
-driven by polygons (triangles). To have that style of shaded display,
-you have to have polygons. We do not have polygons. We do not have a
-robust method for getting polygons. NURBS gives us a robust method.
-
-When we can 1) convert any geometry to NURBS, 2) evaluate any
-booleans, and 3) tessellate NURBS robustly, it will be possible to
-have robust shaded displays for all geometry. #1 was finished last
-year primarily thanks to Cliff and Wu. #3 was finished just this year
-primarily due to Keith. Work on #2 is underway and is scheduled to be
-finished this year..
-
-It's been a while since I've had to succinctly describe the problem
-and solution, so hopefully that is all understandable to everyone.
-There are several independent tasks that will need to be completed is
-anyone wants to help us get there more quickly. ;)
-
-...
-
-> Sean, are those tasks grouped somewhere in the TODO list, or?
-
-Not in such a succinct form because there is a lot of interrelation
-with other tasks/projects. E.g., one can frame reliable STEP NURBS
-import is just as important for shaded displays because users usually
-want to view their own existing data. Or once we have robust boolean
-evaluation of NURBS, most of our converters will need to be updated to
-use the new method ... that's a lot of work. :)
-
-Some tasks that come to mind related to shaded displays are:
-
-* library routine for boolean evaluation of NURBS
-
-* library routine for non-solid NURBS tessellation (capability exists,
- but not as formal API)
-
-* library routine for solid NURBS tessellation (capability exists, but
- not as formal API)
-
-* libgcv routine to perform NURBS boolean evaluation and tessellation
-
-* connecting "facetize" command to use libgcv (solid tessellation)
-
-* migrate current converter polygonal mesh boolean evaluation method
- of NMG-based converters to libgcv
-
-* updating all NMG-based exporters to use new libgcv routine, retain
- old method as legacy option
-
-* updating mged/archer to utilize boolean evaluated NURBS as a
- visualization mode
-
-Other useful but maybe not strictly necessary tasks:
-
-* optimize NURBS prep
-
-* connecting "E" and "ev" commands to use libgcv (non-solid or solid)
-
-* implement support for plate-mode NURBS
-
-* update STEP and 3DM converters to support non-solid NURBS import via
- plate-mode
-
-* libgcv routine to perform NURBS healing (close near-solid NURBS
- geometries)
-
-* update NURBS importers to with option to perform healing on import
-
-* update NURBS ray tracing to perform reparameterization/healing
- during prep
-
-* update IGES importer to import NURBS directly
-
-* implement OBJ NURBS import support
-
-* parallelize single-object NURBS prep (particularly the surface tree
- building)
-
-* parallelize boolean evaluation of NURBS
-
-* parallelize NURBS tessellation
-
-* refactor libdm API to better support (polygonal,curve,point) display
- lists
-
-* refactor libdm implementation to re-encapsulate platform-specific
- logic (no #ifdefs in public headers)
-
-* review old bspline NURBS logic, integrate useful portions, then
- remove the rest
-
-* formally document our BREP/NURBS primitive, capabilities and
- limitations
-
-That's just off the top of my head. There are undoubtedly other tasks
-involved but that's a partial list. Some/many of them are already in
-the TODO file, but many are not yet. Feel free to
-expand/incorporate/ignore. ;)
Deleted: brlcad/branches/bioh/doc/archer_ack.txt
===================================================================
--- brlcad/branches/bioh/doc/archer_ack.txt 2020-05-29 16:33:10 UTC (rev
75985)
+++ brlcad/branches/bioh/doc/archer_ack.txt 2020-05-31 14:04:45 UTC (rev
75986)
@@ -1,11 +0,0 @@
-
-Archer was developed by SURVICE Engineering under the Phase II Small Business
Innovative Research (SBIR) grant AF03-141 (reference contract FA8651-04-C-0137)
under the supervision of Lt. Edwin Rodriguez (AFRL/MNAL) (reference
crossbow.survice.com).
-
-Archer is built upon BRL-CAD. SURVICE would like to acknowledge the
contribution and support from the Army Research Laboratory (ARL) BRL-CAD
Development Team, without which Archer would not be possible.
-
-The following is the Archer Development Team:
-- Bob Parker: Principal programmer
-- Doug Howard: Original coding
-- Keith Bowman: Architecture
-- Steve Phillips: Website and Software Change Request (SCR) tracking system
-- Mark Butkiewicz: Project Management
Deleted: brlcad/branches/bioh/doc/benchmark.tr
===================================================================
--- brlcad/branches/bioh/doc/benchmark.tr 2020-05-29 16:33:10 UTC (rev
75985)
+++ brlcad/branches/bioh/doc/benchmark.tr 2020-05-31 14:04:45 UTC (rev
75986)
@@ -1,849 +0,0 @@
-.\" $Header$
-.\" groff -t -ms -X benchmark.tr
-.\" groff -t -ms benchmark.tr | print-postscript
-.\"
-.\" sort '-t ' +7nr -8
-.de BR
-\fB\\$1\fR\\$2
-..
-.TL
-The BRL-CAD Benchmark Suite
-.AU
-Michael John Muuss
-.AU
-Charles M. Kennedy
-.AU
-Lee A. Butler
-.AI
-The U.S. Army Research Laboratory
-.PP
-This document describes the BRL-CAD Benchmark Suite Methodology, and
-the Ray-Tracing Figure of Merit (RTFM) used to judge the computational
-performance of different computer systems.
-.PP
-The core of the test is the \fBrt\fR ray-tracing program. The results
-for each processor are determined by running a benchmark test of the
-RT ray-tracing program on each of the sample databases provided. The
-\fBrt\fR program requires a binary database for input ("db/xxx.g"),
-and produces a binary image as output ("bench/xxx.pix"), along with a
-log file ("bench/xxx.log"). Each run will produce a 512x512x24 bit
-color shaded image in a "bench/xxx.pix" file, and a run log in
-"bench/xxx.log". Reference copies of the images are provided as
-"pix/xxx.pix" and "pix/xxx.log". The sample databases provided are
-processed in order of increasing difficulty, and each produces a
-colorful image. In each picture there are two light sources; the
-primary source is located near the center of the model (the white
-ball), and the secondary light source is located at the "eye"
-position.
-.NH 1
-The Benchmark Models
-.LP
-moss.g -- This is a simple model, containing a yellow torus, a green
-ellipsoid, a bluish cube, a pink truncated (distorted) cone, all
-sitting on a blue plate. Note the shadowing, and "specular splash".
-.sp
-world.g -- The same model as moss.g, but with various rendering
-features enabled. The model is enclosed in a hollow cloud sphere.
-The plate is a mirror, the egg is crystal, the box has a debugging
-texture map applied.
-.sp
-star.g -- A familiar sight to Star Trek fans; a low-detail exterior of
-the ship "Enterprise". The hull is white, with some other structures
-in other colors. The small red object in the foreground is the
-shuttlecraft Galileo, to scale.
-.sp
-bldg391.g -- An exploded view of a two-story imaginary computer site,
-including various walls, red stairways, green disk drives, etc. The
-lower floor is a mirror, the upper floor is glass.
-.sp
-m35.g -- A truck.
-.sp
-sphflake.g -- A sphereflake.
-.NH 1
-MACHINE INDEPENDENCE
-.PP
-To make the benchmark distribution machine independent, the databases
-are provided in an ASCII format in the "db" directory, and
-ascii-to-binary converters are provided in the "conv" directory. The
-setup command "\fBcake benchmark\fR" (see the document \fIInstalling
-the BRL-CAD Package\fR) will automatically compile and run the
-converters.
-.PP
-If you are running this benchmark on a non-UNIX machine that has
-difficulty writing binary streams, change the "-o file.pix" flag to
-"-O file.a_pix" and RT will write an ASCII form directly. For more
-discussion, consult the doc/pix.5 and conv/asc2pix.1 manual pages.
-.PP
-The reference images are distributed in binary BRL-CAD
-.BR pix (5)
-format. Earlier releases distributed the reference images in the
-portable ASCII form, and then converted them to the binary form. This
-consumed a significant amount of extra storage on UNIX machines, so
-this practice was discontinued. It is assumed that anyone attempting
-to benchmark a system that can not read pure binary files will at
-least have access to a UNIX system. That UNIX system can be used to
-convert the reference images to the portable ASCII form with the
-.BR pix2asc (1)
-tool, and then those images may be sent to the machine under test.
-.PP
-Information about modifying the benchmark to run on a particular
-system may be found in the document \fIInstalling the BRL-CAD
-Package\fR. For a detailed explanation of various hardware specific
-modifications necessary to take advantage of parallel processing, see
-the document \fIWorkstations, Networking, Distributed Graphics, and
-Parallel Processing\fR. Implementations for several different types
-of hardware in use at ARL are included.
-.PP
-If you encounter difficulty with running the benchmark, you might wish
-to build the full BRL-CAD package, to take advantage of the image
-tools in determining the nature of the problem. For example, one
-system suffered from a compiler bug that made TGC solids vanish, while
-another system had difficulties with the light visibility
-calculations.
-.NH 1
-OBTAINING CORRECT RESULTS
-.PP
-The benchmark timings are not considered valid unless the correct
-results are given. Make sure that the answers match the reference
-files to within plus-or-minus one in each color (see pixdiff(1)).
-Slight variations in the calculated pixels are generally attributable
-to variations in floating point precision. You may wish to compare
-the execution times and log file remarks from your tests (in the
-"bench/xxx.log" files) with the VAX-11/780 (with hardware FPA) times
-which are given in the "pix/xxx.log" files. The log file for sphflake
-has yet to be run on the same system, causing weighted results. It's
-still useful and informative, however, for deriving performance
-statistics. The reference images are also located in the "pix/"
-directory.
-.PP
-For example, if you are running the benchmark on a Cray XMP, the
-world.pix and bldg391.pix images will have a single byte in the blue
-channel off by 1, out in the cloud background. This is not to be
-considered an error.
-.NH 1
-BENCHMARK IMAGE DISPLAY
-.PP
-If you have a suitable framebuffer, you may wish to display the images
-generated by the benchmark, and compare them to the reference images.
-This section assumes that you have successfully compiled the full set
-of BRL-CAD software, not just the benchmark portion. Programs for
-dealing with images are in the "util" directory. To display a
-\fBpix\fR(5) file on a framebuffer, set environment variable FB_FILE
-(see \fBbrlcad\fR(1) for details), and run \fBpix-fb\fR. Note that by
-leaving FB_FILE unset, your default display will be used.
-.sp
-.nf
-.ft B
- cd bench
- pix-fb moss.pix
-.ft R
-.fi
-.sp
-If the images computed on your machine do not match the reference
-images, the program "util/pixdiff" will compute a pix file that will
-highlight the differences for you, and report a summary of bytes
-equal, off-by-1, and off-by-many, e.g.,
-.sp
-.ft B
- pixdiff moss.pix ../pix/moss.pix \(or pix-fb
-.ft R
-.fi
-.sp
-For a display of the relative magnitude of the differences at each
-pixel, use "util/bwdiff" instead, e.g.,
-.sp
-.nf
-.ft B
- bwdiff moss.pix ../pix/moss.pix \(or pix-fb
-.ft R
-or
-.ft B
- bwdiff moss.pix ../pix/moss.pix \(or \\
- bwmod -s 128 -m 4 -a 128 \(or pix-fb
-.ft R
-.fi
-.sp
-and for statistics on the differences, use
-.sp
-.ft B
- bwdiff moss.pix ../pix/moss.pix \(or pixstat
-.ft R
-.ne 8i
-.NH 1
-THE COMPETITION
-.PP
-The full benchmark takes about 9 CPU hours on a VAX-11/780, so you
-should scale your expectations accordingly.
-.PP
-Here is a sampling of some systems that have been tested, with as much
-information about the configuration as could be obtained. Some
-systems have a great many options for small things that can affect
-performance, such as memory interleaving.
-.LP
-.TS
-center box;
-l l.
-System Name Configuration
-_ _
-axposf DEC Alpha 4000/710, 256M, OSF/1 V3.0 \(dg
-ex-art Pentium-P90, 16MB, 256K cache, BSD/OS 2.0,
-hawks 486DX/33, 24MB, 256K cache, BSD/OS 2.0
-orac 486/100, 20MB, No cache, BSD/OS 2.0 (laptop)
-pk Cray C90, C916/161024, UNICOS 8.0.2.4
-vapor SGI, 18* 75 MHz R8000 IP21, 1024M RAM 8-way, Irix 6.0
-vblt 66 MHz 486DX2/66, 16M RAM, Linux 1.1.73
-vgr DEC VAX-11/780 w/FPA, 64M RAM, 4.3 BSD
-vision Sun-3/280 w/68881 FPA, 16M RAM, SunOS 4.1.1
-voyage SGI, 4* 25 MHz R3000 IP7, 56M RAM, Irix 4.0.1
-whiz SGI Ingido**2, 100 MHz IP22, 96M RAM, Irix 5.2
-waffle SGI, 4* 25 MHz R3000 IP7, 64M RAM, Irix 4.0.5 (heavy network use)
-warp Sun SPARCstation 5, 32M RAM, SunOS 4.1.4
-wax SGI, 24* 150 MHz R4400 IP19, 1024M RAM 4-way, Irix 5.2
-wilson SGI, 8* 100 MHz R4400 IP19, 1024M RAM 8-way, Irix 5.2
-wilted Sun-4/25 ELC, 16M RAM, SunOS 4.1.1
-wimp 33 MHz 386DX/33 w/387, 256k cache, 16M RAM, BSDI 2.0beta2
-wimpy Sun SS10BSX-GX, 2* 50 MHz SuperSPARC, 64M RAM, SunOS 5.4
-wizard SGI Ingido**2, 150 MHz IP22, 96M RAM, Irix 5.3
-.TE
-\(dg The Alpha was heavily loaded while the benchmark was being run.
-DEC requires us to show the load average at the time:
-.br
-03:28 up 18 days, 10:59, 7 users, load average: 2.00, 2.00, 2.08
-.NH 1
-BENCHMARK RESULTS
-.PP
-In the tradition of Dongarra, the Rays/sec figure is considered the
-"RT Figure of Merit" (RTFM). Note that the RTFM can only be compared
-between different runs on the \fIsame\fR database; it is not
-meaningful to compare RTFM numbers between different databases. The
-Rays/sec number for a multi-processor machine is for "aggregate CPU
-cluster seconds", rather than rays/total CPU seconds (which remains
-fairly constant on good parallel machines).
-.PP
-The statistics are recorded in an easily understood format, with all
-results for a particular configuration listed on a single line. The
-numbers reported are the rays/sec (RTFM) figure. Entries denoted with
-a dagger ("\(dg") produced incorrect results. Entries denoted with a
-dash ("-") were not available and should be considered differently
-than those entries with a dagger. Generally the results are not
-available because time constraints prevented running the complete set
-of databases.
-.fi
-.br
-.ne 8i
-.NH 1
-RELEASE 4.4 STATISTICS (4-Jan-1995)
-.PP
-There is very little difference in RTFM numbers between Release 4.0
-and Release 4.4, so they can be usefully compared. In some cases the
-4.4 performance is slower due to the use of shared libraries. For
-example "vision" dropped from 1.33 to 1.22 due to the shared
-libraries. For most users reducing the disk consumption from 300
-MBytes to 30 MBytes makes this a reasonable tradeoff. However, for
-the best performance, use non-shared libraries.
-.LP
-.TS H
-expand box;
-l | n n n n n | n | l.
-H/W Moss World Star Bldg M35 Mean S/W Notes
-_
-.TH
-vapor 810.91 1091.39 1012.63 1027.25 1092.85 1007 -P18 static
-vapor 773.8 1038.7 979.49 970.91 1036.62 959.9 -P17
-vapor 732.85 1021.69 968.93 922.62 1024.15 934.04 -P18 (SW lock)
-wax 769.38 940.83 953.36 924.7 1050.14 927.68 -P24
-vapor 730.17 994.97 934.43 917.1 987.83 912.9 -P16
-wax 725.26 957.68 927.61 932.67 992.75 907.19 -P24
-wax 756.95 915.96 940.43 903.45 966.09 896.57 -P23
-vapor 686.8 939.63 897.72 884.39 927.16 867.14 -P15
-wax 691.18 853.75 887.17 859.32 933.41 844.96 -P21
-wax 724.73 683.08 890.87 900.82 939.31 827.76 -P22
-vapor 645.32 881.18 843.23 801.41 859.26 806.08 -P14
-wax 637.28 757.74 820.21 871.37 877.6 792.84 -P20
-vapor 608.12 835.84 795.36 759.95 806.32 761.11 -P13
-_
-wax 606.98 784.3 754.46 799.95 794.52 748.04 -P19
-wax 590.16 758.23 794.06 794.52 757.79 738.95 -P18
-wax 579.29 722.35 787.55 720.26 754.65 712.82 -P17
-vapor 571.14 783.72 740.47 697.24 746.72 707.85 -P12
-wax 553.72 697.1 744.21 663.61 723.03 676.33 -P16
-vapor 534.85 716.58 685.87 656.25 685.77 655.86 -P11
-wax 519.01 655.57 690.95 651.9 663.92 636.27 -P15
-wax 475.88 637.33 665.38 608.31 653.99 608.17 -P14
-vapor 499.46 663.26 633.48 614.58 624.34 607.02 -P10
-wax 449.16 591.54 616.21 590.59 614.25 572.35 -P13
-vapor 463.3 598.34 575.07 555.62 560.89 550.64 -P9
-wax 424.71 556.8 595.02 521.63 538.78 527.38 -P12
-vapor 424.89 534.5 509.85 497.63 503.99 494.17 -P8
-wax 391.66 490.63 545.28 488.57 508.96 485.02 -P11
-wax 315.45 472.03 525.47 442.37 461.44 443.35 -P10
-vapor 381.1 467.67 440.13 425.57 442.04 431.3 -P7
-wax 309.35 426.37 386.11 417.85 434.96 394.92 -P9
-vapor 336.55 392.2 390.72 373.92 380.03 374.68 -P6
-_
-wax 307.6 361.32 396.07 380.17 380.74 365.18 -P8
-wax 245.87 332.33 362.5 338.62 331.39 322.14 -P7
-vapor 288.45 327.78 328.76 314.54 320.16 315.93 -P5
-wax 254.82 255.29 299.93 302.08 256.54 273.73 -P6
-wilson 223.01 265.17 287.8 262.19 269.62 261.55 -P8
-vapor 240.6 269.93 266.46 253.99 259.05 258 -P4
-wax 215.96 231.65 221.78 248.63 221.45 227.89 -P5
-wax 177.94 185.27 213.74 201.64 197.27 195.17 -P4
-vapor 187.58 198.84 202.28 191.94 194.74 195.07 -P3
-wax 120.4 138.01 162.12 159.36 141.33 144.24 -P3
-vapor 130.61 140.04 134.88 129.38 129.78 132.93 -P2
-wax 100.83 102.09 111.12 87.26 98.62 99.98 -P2
-wimpy 99.10 95.78 92.15 97.51 96.65 96.23 -P2
-wimpy 82.14 93.60 92.17 103.59 82.22 90.74 -P2
-_
-axposf 81.05 82.27 86.72 84.36 79.28 82.73 -P1
-vapor 79.68 77.7 73.89 71.38 70.06 74.54 -P1 static
-vapor 69.34 70.14 67.52 65.55 66.69 67.84 -P1 shared
-wizard 63.8 55.86 68.97 73.21 61.56 64.68
-wax 62.28 58.58 65.24 67.39 59.31 62.56 -P1
-wax 59.08 56.06 61.45 64.4 56.11 59.42 -P1
-voyage 52.78 55.44 58.19 58.03 52.41 55.37 -P4
-pk 64.89 55.71 48.01 49.50 53.43 54.30 -P1
-waffle 38.56 47.63 62.36 59.62 51.20 51.87 -P4
-wimpy 50.17 48.82 50.46 55.12 49.27 50.76 -P1
-wimpy 47.80 43.23 51.37 54.10 46.23 48.54 -P1
-weber 46.53 43.45 50.88 50.33 46.03 47.44 -P1
-wilson 41.16 39.54 45.98 42.93 34.82 40.88 -P1
-whiz 36.25 31.08 37.21 39.62 36.98 36.22
-warp 19.88 21.33 23.71 24.19 22.60 22.34
-ex-art 16.89 18.54 22.98 26.97 25.57 22.19
-orac 7.57 8.23 10.72 12.43 11.30 10.05
-wilted 9.58 9.53 10.66 10.53 9.87 10.03
-hawks 3.64 4.17 5.71 6.90 6.23 5.33
-vblt 4.85 4.89 5.29 5.24 4.90 5.03
-wimp 1.16 1.34 1.82 2.25 2.06 1.72
-vision 1.07 1.23 1.23 1.31 1.26 1.22 -P1
-vgr 1.0 1.0 1.0 1.0 1.0 1.0
-.TE
-.br
-.ne 8i
-.NH 1
-THE OLD COMPETITION
-.PP
-These are the definitions for systems measured in previous tests.
-.LP
-.TS
-center box;
-l l.
-System Name Configuration
-_ _
-alliant Alliant FX/8 (8 CEs, 9 IPs, 64 Mbytes), Concentrix 3.0
-amber HP 9000/720, 32 MB memory
-amsaa-seer Gould PN 9080, w/MACCs, UTX 2.0, 4x4Mb mem boards
-ardec-3 Pyramid 90Mx, Dual-CPU, OSx 2.5, 16 Mbytes
-bob Cray-2, SN 2009, 4.3ns clock
-cor3 Pyramid MIS-12T/3, OSx 192
-patton Cray X-MP/48, SN213, UNICOS 5.0, 8.5ns clock
-uy1 Cray Y-MP8/2128, UNICOS 5.1.11
-shpcrc2 IBM RS/6000, AIX 3.1
-slc1 Macintosh II, 68020, 68881, AUX 1.1, GCC 1.39
-spark Gould PN 9050, no MACC, UTX 2.0, 2x4Mb mem boards
-sws2 Convex C120, 16 Mbytes, Convex Unix 6.2.32.2
-vector Alliant FX/80 (8 ACEs, 6 IPs, 32 Mbytes), Concentrix
-venom Alliant FX/8 (8 CEs, 6 IPs, 32 Mbytes), Concentrix
-vgr VAX 780, FPA, 4.3 BSD
-virus Sun-3/50, 15 Mhz clock, 12 Mhz 68881, Sun UNIX 3.2
-vista SGI 3030, w/FP chip, UNIX release 3.5
-vmb Gould PN 9080, no MACCs, UTX 2.0, 12x1Mb mem boards
-vhs Silicon Graphics 4D/60T, 12.5 Mhz clock 16 MB memory
-ovoyage Silicon Graphics 4D/120, 16.7 Mhz clock 16 MB memory
-taylor Silicon Graphics 4D/220, 25 Mhz clock 16 MB memory
-crim Silicon Graphics 4DCRIMS 50Mhz clock 128 MB memory
-wiltse Silicon Graphics 4D R4000 50Mhz clock
-c1east T{
-Convex C1 XP (2 IOPs, 4 Multibus, 64 Mbytes),
-S/W 6.0.1.12
-T}
-elxsi-gnu Elxsi 6420, BSD 4.2 16 MB
-elxsi-gnuy Elxsi 6420, Sys Vr2, 16MB
-elxsi-m1 Elxsi 6410, BSD 4.2 16 MB
-hep Denelcor HEP, 4 PEMs
-indigo SGI Iris 3030, FPA, GL2-W3.5
-mseries T{
-MIPS Mseries, Release 0.6, UMIPS 2.1, 16 MB of R2350 RAM.
-R2000 CPU rev 5.0, R2010 FP rev 2.0
-T}
-multiflow Multiflow Trace 7/200 (PRELIMINARY)
-nova T{
-Sun SPARCserver 490, 32 Mb, 33 MHz clock, 33 MHz TI 8847 FPU, SunOS 4.1.1B
-T}
-rh2 Tektronix, Motorola 88000
-snm2 Cray 1-M, SN2, UNICOS 2.0
-sws1 Convex C1, ConvexOS 9.1 48MB memory
-tek4132 Tektronix 4132, 32082 fpp, UTek 2.3
-utah-gr VAX 785, FPA, 4.3 BSD
-utah-cs VAX 8600, FPA, 4.3 BSD
-veto Sun 4/260 32MB memory Sun UNIX 4.0.3
-violet VaxStationII GPX, Ultrix 1.2
-vision Sun-3/280, 16 MB memory
-vortac Sun-3/160, 16.67 Mhz clock, 12 Mhz 68881, Sun 3.2
-walrus Silicon Graphics 4D/280 25 Mhz clock 64 MB memory Irix 3.3.1
-whiz Silicon Graphics 4D/240 25 Mhz clock 56 MB memory Irix 3.3.1
-whisper Sun SPARCStation 1+
-wilted Sun SPARCstation ELC , Diskless, 12MB memory Sun UNIX 4.1.1
-worm Silicon Graphics 4D/280 25 Mhz clock 64 MB memory Irix 3.3.1
-.TE
-.br
-.ne 8i
-.NH 1
-OLD BENCHMARK RESULTS
-.PP
-These are the results of previous benchmarks.
-.NH 1
-RELEASE 1.20 STATISTICS (12-Feb-1987)
-.LP
-.TS H
-expand box;
-l l | n n n n | n | l.
-A/* H/W Moss World Star Bldg Mean S/W Notes
-_
-.TH
-Rays tek4132 80.5 44.0 33.9 31.4 ? UTek 2.3
-*vgr tek4132 0.72 0.69 0.62 0.62 ?
-_
-Rays violet 107.7 57.3 44.7 44.1 ? Ultrix 1.2
-*vgr violet 0.96 0.90 0.81 0.87 ?
-_
-Rays violet 119.0 63.0 50.0 46.3 ? Ultrix 1.2,
-*vgr violet 1.06 0.99 0.91 0.91 ? w/fast_sqrt
-_
-Rays vgr 112.1 63.6 55.0 50.7 ? BSD 4.3
-*vgr vgr 1.0 1.0 1.0 1.0 1.0
-_
-Rays indigo 115.9 85.3 \(dg 101.8 ? GL2-W3.5
-*vgr indigo 1.03 1.34 \(dg 2.01 ?
-_
-Rays vista 116.4 86.0 \(dg 102.3 ? SGI UNIX 3.5
-*vgr vista 1.04 1.35 \(dg 2.02 ?
-_
-Rays virus 127.3 69.9 57.0 52.4 ? Sun UNIX 3.2
-*vgr virus 1.14 1.10 1.04 1.03 ?
-_
-Rays vortac 148.2 81.0 65.8 60.7 ? Sun UNIX 3.2
-*vgr vortac 1.32 1.27 1.20 1.20 ?
-_
-Rays utah-gr 191.8 105.8 89.9 86.5 ? 4.3 BSD
-*vgr utah-gr 1.71 1.66 1.64 1.71 ?
-_
-Rays ardec-3 - 68.4 57.2 - ? OSx 2.5
-*vgr ardec-3 - 1.08 1.04 - ?
-_
-Rays elxsim1 380.5 232.2 204.8 189.3 ? BSD 4.2
-*vgr elxsim1 3.39 3.65 3.72 3.73 ?
-_
-Rays spark 413.4 232.0 213.8 211.9 ? UTX 2.0
-*vgr spark 3.69 3.65 3.89 4.18 ?
-_
-Rays vmb 413.9 233.4 210.6 212.6 ? UTX 2.0
-*vgr vmb 3.69 3.67 3.83 4.19 ?
-_
-Rays c1east 454.8 252.4 205.6 192.3 ? Convex UNIX 6.0.1.12,
-*vgr c1east 4.06 3.97 3.74 3.80 ? vanilla cc
-_
-Rays seer 460.7 263.2 246.8 241.0 ? UTX 2.0
-*vgr seer 4.11 4.14 4.49 4.75 ?
-_
-Rays venom 492.9 228.0 180.0 157.1 ? Concentrix 2.0
-*vgr venom 4.40 3.58 3.27 3.10 ?
-_
-Rays elxgnu 520.6 315.4 264.4 242.0 ? BSD 4.2
-*vgr elxgnu 4.64 4.96 4.81 4.77 ?
-_
-Rays utah-cs 521.1 292.1 237.4 216.2 ? BSD 4.3
-*vgr utah-cs 4.64 4.59 4.32 4.27 ?
-_
-Rays c1east 521.6 285.3 230.5 215.1 ? Convex UNIX 6.0.1.12,
-*vgr c1east 4.66 4.49 4.20 4.24 ? vc -O1 (scalar)
-_
-Rays c1east 527.7 287.4 228.7 210.0 ? Convex UNIX 6.0.1.12,
-*vgr c1east 4.71 4.52 4.16 4.14 ? vc -O2 (vector)
-_
-Rays elxgnuy 644.7 349.3 264.6 242.1 ? System Vr2
-*vgr elxgnuy 5.75 5.49 4.81 4.77 ?
-_
-Rays mflow 845.2 439.5 313.1 338.9 ? (preliminary)
-*vgr mflow 7.54 6.91 5.69 6.68 ?
-_
-Rays venom 904.9 424.6 349.3 312.6 ? Concentrix 2.0,
-*vgr venom 8.07 6.68 6.35 6.17 ? 2 CEs, no vectors
-_
-Rays venom 1375.5 650.0 523.4 459.9 ? Concentrix 2.0,
-*vgr venom 12.27 10.22 9.52 9.07 ? 3 CEs, no vectors
-_
-Rays venom 1813.5 845.5 686.0 600.7 ? Concentrix 2.0,
-*vgr venom 16.17 13.29 12.47 11.85 ? 4 CEs, no vectors
-_
-Rays venom 2364.1 1104.4 870.2 775.9 ? Concentrix 2.0,
-*vgr venom 21.08 17.36 15.82 15.3 ? 5 CEs, no vectors
-_
-Rays snm2 2492.9 - - - ? Unicos 2.0,
-*vgr snm2 22.24 - - - ? no vectors, no optim
-_
-Rays hep 2502.0 - - - ? 1 PEM, npsw=10
-*vgr hep 22.32 - - - ?
-_
-Rays venom 2811.4 1319.0 1051.6 918.0 ? Concentrix 2.0,
-*vgr venom 25.08 20.74 19.12 18.1 ? 6 CEs, no vectors
-_
-Rays venom 3248.8 1533.0 1232.3 1065.9 ? Concentrix 2.0,
-*vgr venom 28.98 24.10 22.41 21.02 ? 7 CEs, no vectors
-_
-Rays patton 3453.3 1514.3 1271.2 1027.3 ? COS V115BF2
-*vgr patton 30.81 23.81 23.11 20.26 ? 1 CPU, no vectors
-_
-Rays venom 3677.3 1724.2 1375.4 1208.4 ? Concentrix 2.0,
-*vgr venom 32.80 27.11 25.01 23.83 ? 8 CEs, no vectors
-_
-Rays alliant 3972.9 1840.0 1457.2 1266.4 ? Concentrix 3.0,
-*vgr alliant 35.44 28.93 26.49 24.98 ? 8 CEs, no vectors
-_
-Rays hep 4055.9 - - - ? 1 PEM, npsw=40
-*vgr hep 36.18 - - - ?
-_
-Rays patton 6856.6 - 2522.2 - ? COS V115BF2
-*vgr patton 61.16 - 45.86 - ? 2 CPUs, no vectors
-_
-Rays patton 10205.1 - 3749.9 - ? COS V115BF2
-*vgr patton 91.04 - 68.18 - ? 3 CPUs, no vectors
-_
-Rays patton 13320.2 - 4955.6 - ? COS V115BF2
-*vgr patton 118.82 - 90.10 - ? 4 CPUs, no vectors
-.TE
-.NH 1
-RELEASE 2.3 STATISTICS (2-Nov-1987)
-.LP
-.TS H
-expand box;
-l l | n n n n | n | l.
-A/* H/W Moss World Star Bldg Mean S/W Notes
-_
-.TH
-Rays vgr 118.8 64.9 36.5 34.2 ? BSD 4.3
-*vgr vgr 1.0 1.0 1.0 1.0 1.0
-_
-Rays vmb 375.4 218.6 186.4 196.2 ? UTX 2.0
-*vgr vmb 3.16 3.37 5.11 5.74 ?
-_
-Rays venom 468.2 221.7 166.1 144.9 ? Concentrix 3.0,
-*vgr venom 3.94 3.42 4.55 4.24 ? 1 CE, no vectors
-_
-Rays sws2 471.9 258.4 202.5 186.4 ? Convex Unix 6.2.32.2
-*vgr sws2 3.97 3.98 5.55 5.45 ? vanilla cc -O
-_
-Rays vector 656.6 301.6 221.1 195.0 ? Concentrix 3.0,
-*vgr vector 5.53 4.65 6.06 5.70 ? 1 ACE, no vectors
-_
-Rays venom 827.3 424.0 327.1 287.9 ? Concentrix 3.0,
-*vgr venom 6.96 6.53 8.96 8.42 ? 2 CEs, no vectors
-_
-Rays vhs 958.3 545.6 447.0 414.1 ? -O2 optimization
-*vgr vhs 8.07 9.41 12.25 12.11 ?
-_
-Rays mseries 988.3 603.5 515.6 491.6 ?
-*vgr mseries 8.32 9.29 14.13 14.37 ?
-_
-Rays vector 1280.9 596.8 436.7 389.2 ? Concentrix 3.0,
-*vgr vector 10.78 9.19 11.96 11.38 ? 2 ACEs, no vectors
-_
-Rays venom 1288.7 630.6 486.4 428.0 ? Concentrix 3.0,
-*vgr venom 10.85 9.72 13.33 12.51 ? 3 CEs, no vectors
-_
-Rays venom 1732.9 853.2 645.4 560.1 ? Concentrix 3.0,
-*vgr venom 14.59 13.15 17.68 16.38 ? 4 CEs, no vectors
-_
-Rays bob 1856.7 801.9 574.1 500.3 ? 1 CPU, UNICOS 3.0,
-*vgr bob 15.63 12.36 15.73 15.62 ? CC -O
-_
-Rays vector 1952.1 881.7 647.6 578.8 ? Concentrix 3.0,
-*vgr vector 16.43 13.58 17.74 16.92 ? 3 ACEs, no vectors
-_
-Rays venom 2158.4 1031.3 797.3 703.1 ? Concentrix 3.0,
-*vgr venom 18.17 15.89 21.84 20.56 ? 5 CEs, no vectors
-_
-Rays bob 2346.1 1127.4 751.0 677.2 ? 1 CPU UNICOS 4.0
-*vgr bob 19.75 17.37 20.57 19.80 ? CC -O
-_
-Rays bob 2423.5 1045.7 719.3 609.4 ? 1 CPU, UNICOS 3.0,
-*vgr bob 20.40 16.11 19.71 17.82 ? VCC -O
-_
-Rays vector 2546.2 1170.0 867.2 758.7 ? Concentrix 3.0,
-*vgr vector 21.43 18.03 23.76 22.18 ? 4 ACEs, no vectors
-_
-Rays venom 2633.7 1232.7 943.4 839.5 ? Concentrix 3.0,
-*vgr venom 22.17 18.99 25.85 24.55 ? 6 CEs, no vectors
-_
-Rays venom 2769.4 1393.3 1098.1 971.6 ? Concentrix 3.0,
-*vgr venom 23.31 21.47 30.08 28.41 ? 7 CEs, no vectors
-_
-Rays vector 3131.2 1453.8 1065.8 945.4 ? Concentrix 3.0,
-*vgr vector 26.36 22.40 29.20 27.64 ? 5 ACEs, no vectors
-_
-Rays venom 3368.7 1605.3 1231.3 1095.11 ? Concentrix 3.0,
-*vgr venom 28.36 24.73 33.73 32.02 ? 8 CEs, no vectors
-_
-Rays patton 3456.5 1691.8 1169.0 1043.6 ? 1 CPU, UNICOS 2.1
-*vgr patton 29.10 26.07 32.03 30.51 ? no vectors
-_
-Rays vector 3686.4 1688.6 1259.1 1129.0 ? Concentrix 3.0,
-*vgr vector 31.03 26.02 34.49 33.01 ? 6 ACEs, no vectors
-_
-Rays vector 4140.3 1953.0 1463.3 1299.7 ? Concentrix 3.0,
-*vgr vector 34.85 30.09 40.09 38.00 ? 7 ACEs, no vectors
-_
-Rays bob 4641.7 2243.4 1498.2 1358.1 ? 2 CPUs, UNICOS 4.0
-*vgr bob 39.07 34.57 41.05 39.71 ? CC -O
-_
-Rays vector 4712.2 2226.3 1649.0 1469.7 ? Concentrix 3.0,
-*vgr vector 39.66 34.30 45.18 42.97 ? 8 ACEs, no vectors
-_
-Rays bob 6884.9 3422.4 2267.7 2034.3 ? 3 CPUs, UNICOS 4.0
-*vgr bob 57.95 52.73 62.13 59.48 ? CC -O
-_
-Rays bob 9477.1 4484.7 2947.0 2832.9 ? 4 CPUs, UNICOS 4.0
-*vgr bob 79.77 69.10 80.76 82.83 ? CC -O
-.TE
-.NH 1
-RELEASE 3.0 STATISTICS (10-Oct-1988)
-.LP
-.TS H
-expand box;
-l l | n n n n | n | l.
-A/* H/W Moss World Star Bldg Mean S/W Notes
-_
-.TH
-Abs vgr 138.85 67.15 54.48 49.11 77.39 BSD 4.3
-*vgr vgr 1.00 1.00 1.00 1.00 1.00 w/FPA
-_
-Abs sdm 163.56 76.98 59.79 52.51 88.21 SunOS 3.4
-*vgr sdm 1.17 1.14 1.09 1.06 1.11 w/68881
-_
-Abs ardec-3 417.95 212.43 177.01 160.73 242.03 9820, OSx 4.1
-*vgr ardec-3 3.01 3.16 3.24 3.27 3.17 -P 1
-_
-Abs spark 443.84 216.92 190.42 192.82 261.00 UTX 2.0
-*vgr spark 3.19 3.23 3.49 3.92 3.37 no MACC
-_
-Abs vmb 482.28 226.33 191.52 193.04 273.29 UTX 2.0
-*vgr vmb 3.47 3.37 3.51 3.93 3.57 no MACC
-_
-Abs sws2 546.23 255.45 183.10 163.85 287.15 Convex 6.2.32.2
-*vgr sws2 3.93 3.80 3.36 3.33 3.60 /bin/cc
-_
-Abs sun4 767.7 373.7 315.5 284.5 435.6 Unix 3.5
-*vgr sun4 5.52 5.56 5.79 5.79 5.62 -O2 optim
-_
-Abs video 940.33 469.30 399.21 367.64 544.12 UNIX 2.0
-*vgr video 6.77 6.98 7.32 7.48 7.13 -O2
-_
-Abs vhs 954.81 471.90 409.78 392.55 557.26 IRix 3.1
-*vgr vhs 6.87 7.02 7.52 7.99 7.45 Parallel, -P1
-_
-Abs bob 2602.68 1078.25 712.39 642.42 1258.93 UNICOS 4.0, /bin/cc
-*vgr bob 21.22 18.17 15.39 13.98 17.19 -P 1
-_
-Abs vector 3811.68 1469.80 1060.50 921.21 1815.79 Alliant 3.0
-*vgr vector 27.45 21.88 19.46 18.75 21.88 -P 5
-_
-Abs vector 4515.09 1751.94 1266.49 1090.85 2156.09 Alliant 3.0
-*vgr vector 32.51 26.08 23.24 22.21 26.01 -P 6
-_
-Abs patton 4550.67 1920.15 1298.61 1153.02 2230.61 UNICOS 3.0, /bin/cc
-*vgr patton 37.10 32.36 28.05 25.09 30.65 -P 1
-_
-Abs vector 5130.74 2004.49 1438.97 1261.36 2458.89 Alliant 3.0
-*vgr vector 36.95 29.85 26.41 25.68 29.72 -P 7
-_
-Abs bob 5186.24 2132.17 1409.10 1273.72 2500.30 UNICOS 4.0, /bin/cc
-*vgr bob 42.28 35.93 30.44 27.71 34.09 -P 2
-_
-Abs vector 5813.76 2260.61 1638.31 1422.82 2783.87 Alliant 3.0
-*vgr vector 41.87 33.66 30.07 28.97 33.64 -P 8
-_
-Abs amber 5901.29 2702.65 2096.35 1893.41 3148.42
-*vgr amber 42.50 40.24 38.47 38.55 39.94 -P 1
-_
-Abs bob 7934.12 3392.98 2119.11 1929.74 3843.98 UNICOS 4.0, /bin/cc
-*vgr bob 64.69 57.18 45.78 41.99 52.41 -P 3
-_
-Abs patton 8898.79 3782.55 2559.48 2292.13 4383.23 UNICOS 3.0, /bin/cc
-*vgr patton 72.56 63.75 55.30 49.88 60.37 -P 2
-_
-Abs bob 10734.52 4436.61 2883.53 2617.47 5168.03 UNICOS 4.0,
/bin/cc
-*vgr bob 87.52 74.77 62.30 56.96 70.38 -P 4
-_
-Abs patton 13078.79 5631.95 3832.88 3416.90 6490.13 UNICOS 3.0,
/bin/cc
-*vgr patton 106.64 94.92 82.81 74.36 89.68 -P 3
-_
-Abs patton 17157.78 7437.55 5073.58 4531.25 8550.04 UNICOS 3.0,
/bin/cc
-*vgr patton 139.90 125.35 109.62 98.61 118.37 -P 4
-.TE
-.bp
-.NH 1
-RELEASE 3.7 STATISTICS (19-June-1989)
-.LP
-.TS H
-expand box;
-l l | n n n n n | n | l.
-A/* H/W Moss World Star Bldg M35 Mean CPU
-_
-.TH
-Abs vgr 128.64 54.47 45.17 40.35 49.02 63.53 1
-*vgr vgr 1.00 1.00 1.00 1.00 1.00 1.00
-_
-Abs rh2 1704.56 791.31 599.81 549.74 589.01 846.88 1
-*vgr rh2 13.25 14.52 13.27 13.62 12.01 13.33
-_
-Abs spark 435.69 208.59 176.76 177.69 174.67 234.68 1
-*vgr spark 3.53 3.61 4.17 4.29 3.40 3.80
-_
-Abs vhs 973.11 475.00 384.62 351.12 343.44 505.45 1
-*vgr vhs 7.56 8.72 8.51 8.70 7.00 8.09
-_
-Abs whisper 1118.35 561.81 473.52 439.76 509.26 620.54 1
-*vgr whisper 8.69 10.31 10.48 10.89 10.38 10.15
-_
-Abs nova 2024.80 976.01 790.17 732.35 ? 1130.83 1
-*vgr nova 15.74 17.92 17.49 18.15 ? 17.32
-_
-Abs ovoyage 1969.57 1001.21 862.77 809.61 786.11 1085.85 2
-*vgr ovoyage 15.31 18.38 19.10 20.06 16.03 17.77
-_
-Abs taylor 2446.98 1076.24 912.03 837.56 799.58 1214.47 1
-*vgr taylor 19.02 19.75 20.19 20.75 16.31 19.20
-_
-Abs worm 2671.46 1218.49 966.76 859.61 932.18 1329.70 1
-*vgr worm 20.76 22.36 21.40 21.30 19.01 20.96
-_
-Abs viper 3255.73 1368.96 1102.71 1039.37 1008.15 1554.98 8
-*vgr viper 25.30 25.13 24.41 25.75 20.56 24.23
-_
-Abs vector 3956.86 1625.23 1234.03 1137.36 1121.41 1814.97 8
-*vgr vector 30.75 29.83 27.31 28.18 22.87 27.78
-_
-Abs taylor 4730.05 2225.56 1742.09 1590.57 1551.78 2368.01 2
-*vgr taylor 36.76 40.85 38.56 39.41 31.65 37.44
-_
-Abs worm 5017.85 2309.86 1894.92 1708.27 1791.11 2544.40 2
-*vgr worm 39.00 42.40 41.95 42.33 36.53 40.44
-_
-Abs worm 7082.79 3359.99 2740.50 2502.03 2594.37 3655.93 3
-*vgr worm 55.05 61.68 60.67 62.00 52.92 58.46
-_
-Abs worm 8664.78 4162.53 3323.46 3115.36 3378.75 4528.97 4
-*vgr worm 67.35 76.41 73.57 77.20 68.92 72.69
-_
-Abs worm 10072.1 5016.57 4032.60 3855.90 4043.11 5404.06 5
-*vgr worm 78.29 92.09 89.27 95.56 82.47 87.53
-_
-Abs worm 11678.4 5752.20 4758.80 4493.16 4700.52 6276.60 6
-*vgr worm 90.78 105.60 105.35 111.35 95.88 101.79
-_
-Abs worm 12282.3 6021.31 5394.36 4908.98 5141.71 6749.72 7
-*vgr worm 95.47 110.54 119.42 121.65 104.89 110.39
-_
-Abs worm 12158.3 5913.50 5784.67 5327.66 5505.71 6937.96 8
-*vgr worm 94.51 108.56 128.06 132.03 112.31 115.09
-_
-Abs patton 16028.8 7289.7 4827.9 4392.5 20829.2 53368.1 4
-*vgr patton 124.6 133.83 106.88 108.85 106.23 116.07
-.TE
-.bp
-.NH 1
-RELEASE 4.0 STATISTICS
-.LP
-.TS H
-expand box;
-l l | n n n n n | n | l.
-A/* H/W Moss World Star Bldg M35 Mean CPU
-_
-.TH
-Abs vgr 137.82 67.23 56.39 53.91 69.25 76.92 1
-*vgr vgr 1.00 1.00 1.00 1.00 1.00 1.00
-_
-Abs slc1 153.63 80.95 62.94 60.48 ? 71.60 1
-*vgr slc1 1.12 1.20 1.12 1.13 ? .91
-_
-Abs vision 165.85 89.78 76.44 75.78 96.18 100.80 1
-*vgr vision 1.21 1.33 1.36 1.42 1.36 1.33
-_
-Abs vmb 381.92 195.11 178.78 186.62 214.31 231.34 1
-*vgr vmb 2.78 2.90 3.18 3.49 3.03 3.07
-_
-Abs sws1 636.26 288.76 212.99 210.18 271.02 323.84 1
-*vgr sws1 4.64 4.30 3.79 3.93 3.83 4.09
-_
-Abs veto 827.25 436.38 361.89 348.99 422.19 479.34 1
-*vgr veto 6.03 6.50 6.45 6.54 5.97 6.29
-_
-Abs vhs 1040.44 500.52 436.90 415.15 496.30 577.86 1
-*vgr vhs 7.59 7.46 7.79 7.78 7.02 7.52
-_
-Abs cor3 1203.14 553.22 445.45 398.79 534.18 626.95 1
-*vgr cor3 8.78 8.24 7.94 7.47 7.55 7.99
-_
-Abs wilted 1556.66 800.18 722.95 708.21 858.90 929.38 1
-*vgr wilted 11.36 11.93 12.89 13.27 12.15 12.32
-_
-Abs shpcrc2 2274.36 1041.79 915.99 854.30 1110.23 1239.33 1
-*vgr shpcrc2 16.59 15.53 16.33 16.01 15.70 16.03
-_
-Abs walrus 2291.38 1094.04 960.07 892.67 1066.31 1260.89 1
-*vgr walrus 16.72 16.31 17.12 16.72 15.08 16.39
-_
-Abs walrus 4010.55 2019.34 1767.75 1685.19 2029.78 2302.52 2
-*vgr walrus 29.27 30.11 31.52 31.58 28.71 30.23
-_
-Abs patton 5235.87 2108.02 1509.85 1507.81 2132.01 2498.71 1
-*vgr patton 38.21 31.43 26.92 28.25 30.15 30.99
-_
-Abs crim 4679.97 2246.04 2143.07 1936.85 2224.65 2646.11 1
-*vgr crim 34.15 33.49 38.22 36.29 31.47 34.72
-_
-Abs uy1 6220.79 2474.97 1742.33 1748.73 2464.90 2930.34 1
-*vgr uy1 45.40 36.90 31.07 32.77 34.86 36.20
-_
-Abs wiltse 5785.83 2737.06 2473.66 2310.58 2699.06 3201.23 1
-*vgr wiltse 42.22 40.81 44.11 43.30 38.18 41.72 -mips1
-_
-Abs walrus 5743.85 2938.73 2513.24 2446.85 2858.84 3300.30 3
-*vgr walrus 41.92 43.82 44.82 45.85 40.44 43.37
-_
-Abs wiltse 7093.51 3458.89 2887.77 2730.62 3199.08 3873.97 1
-*vgr wiltse 51.77 51.57 51.50 51.17 45.25 50.25 -mips2
-_
-Abs walrus 7131.48 3613.02 3262.01 3048.77 3594.35 4129.92 4
-*vgr walrus 52.05 53.87 58.17 57.13 50.84 54.41
-_
-Abs whiz 7159.01 3655.65 3355.85 3132.36 3655.02 4191.57 4
-*vgr whiz 52.25 54.51 59.85 58.70 51.70 55.40
-_
-Abs walrus 7698.43 4119.06 3889.37 3690.27 4244.30 4728.28 5
-*vgr walrus 56.18 61.42 69.36 69.15 60.04 63.23
-_
-Abs walrus 8718.08 4625.56 4469.49 4295.53 4765.40 5374.81 6
-*vgr walrus 63.63 68.97 79.71 80.50 67.41 72.04
-_
-Abs walrus 8937.71 4882.66 4911.99 4601.09 5335.14 5733.71 7
-*vgr walrus 65.23 72.81 87.60 86.22 75.47 77.46
-_
-Abs walrus 9300.31 5136.17 5243.14 5112.23 5318.45 6022.06 8
-*vgr walrus 67.88 76.59 93.51 95.80 75.23 81.80
-_
-.TE
-.bp
-.NH 1
-ADDITIONAL STATISTICS
-.PP
-It would be greatly appreciated if you would e-mail any statistics
-that you gather to the BRL-CAD developers, including: the ``summary''
-file produced by the benchmark script, which BRL-CAD release was used,
-the manufacturer of the machine, hardware model name/number, software
-version numbers (OS and compiler), presence or absence of floating
-point hardware, processor cache sizes, bus and memory speeds, and the
-local host name (preferably an Internet or UUCP host name) of the
-specific machine used.
Deleted: brlcad/branches/bioh/doc/brep.txt
===================================================================
--- brlcad/branches/bioh/doc/brep.txt 2020-05-29 16:33:10 UTC (rev 75985)
+++ brlcad/branches/bioh/doc/brep.txt 2020-05-31 14:04:45 UTC (rev 75986)
@@ -1,223 +0,0 @@
-BRL-CAD Boundary-Representation Primitive
------------------------------------------
-
--- Introduction --
-
-This document describes the new Boundary-representation (BREP)
-primitive that has been implemented in BRL-CAD for use with external
-geometry import and improved visualisation.
-
-The primitive is not yet complete, and is currently quite buggy, so
-this document also serves to describe the current state of
-development, and the knowledge a developer needs to continue working
-on this primitive.
-
-
--- BREP Description --
-
-A boundary-representation is a method of representing solid geometry
-by describing its topology and corresponding geometry. In other words,
-the vertexes, edges, and faces as well as the points, curves, and
-surfaces belonging to those topological elements.
-
-For example, a cube has 8 vertexes each mapping to 1 point in space, 6
-faces each mapping to 1 surface, and 8 edges each shared by two faces
-and sharing its two vertexes with two other faces and owning 1 real
-curve.
-
-Actually creating/using a BREP requires keeping track of a lot of details,
-including everything mentioned above, plus curve / face orientations
-(a CCW edge/vertex ordering is usually used for determining front/back
-designations.)
-
-BRL-CAD has/had an existing BREP structure: the NMG (non-manifold
-geometry) primitive/library.
-
-[[describe reasons for not using the existing library]]
-
-One can use many types of surface and curve geometry, but generally a
-small subset are used by any particular implementation: e.g. having
-converted a few pieces of Pro/E through IGES to the new BRL-CAD BREP
-primitive, I've seen the following curve and surface types used:
-
-* Line
-* Arc
-* NURBS curve
-* Surface of revolution
-* NURBS surface
-
-The simple IGES converter used to import and test new geometry handles
-those types already. Other limitations of the converter are described
-later in the document.
-
-
--- Primitive Implementation --
-
-openNURBS was chosen to represent the geometry within BRL-CAD. This
-turned out to be a good and bad choice at the same time:
-
-* contains a lot of solid functionality
-* missing a lot of useful and important functionality
-
-In other words, the openNURBS API provided methods of functions for
-several pieces of functionality that had implementations removed when
-McNeil and Associates released openNURBS as essentially public domain
-code. This slowed development somewhat and meant the functionality had
-to be reimplemented by hand.
-
-The API is relatively straightforward C++, and it is used to evaluate
-geometry and represent/store BREPs in the BRL-CAD geometry file,
-through the built-in serialization facility (i.e. 3DM files).
-
-
--- Raytracing BREPs --
-
-See Abert et al. (raytracing 06 paper: Direct and Fast Ray Tracing of NURBS
-Surfaces).
-
-We use a two-dimensional root-finding technique: we represent the ray
-as two orthogonal planes (the intersection of the planes includes the
-ray), and then find the root of an equation that represents the
-gradient of the distance from the point to the intersection of the ray
-planes. When this gradient becomes zero (we found a root), we've also
-found the uv parameters for the intersection point.
-
-Newton iteration is used, mostly since it is simple, displays
-quadratic convergence when using good guesses, and is amenable to
-acceleration using SIMD instructions.
-
-Evaluation of the surface and its derivatives is done by the openNURBS
-library at this point. The Abert paper gives some information on how
-to do the evaluation using SIMD instructions (needed for speeding
-things up).
-
-A simple SIMD vector class has been implemented (see vector.h)
-supporting both SSE2 and FPU vector operations. This is currently only
-lightly used, since no optimization work has taken place yet
-(correctness before optimization).
-
-After intersection, we need to trim the surface. Every edge of a BREP
-is part of a loop "within" a face. Loops define boundaries on
-faces. In our cube example above, the four edges of a each face
-comprise a single loop (in this case an outer boundary). The surface
-may be defined as an infinite plane, but this outer boundary loop
-limits it to the area enclosed within those edges. As you may imagine,
-a face may have more than one loop and these additional loops will
-always be internal. All loops can also be considered trims, although
-this term seems to be reserved for actual geometric curves that are
-parameterized within the domain of an individual surface.
-
-Properly ray tracing a BREP is difficult (thus, the obvious
-explanation why this primitive is incomplete). There are several facts
-about BREPs that result in problematic situations during ray tracing:
-BREPs are not like implicit solid geometry: there is no nice equation
-to simply solve (a lot of numerical techniques are used); surfaces,
-curves and point geometry may not be aligned; there can be gaps
-between two mated surfaces... and the list goes on.
-
-Since it's possible to miss a surface but *need* a hit (i.e. it hit an
-edge but passed between surfaces that did not mate up or overlap), we
-need to do edge checks: at some point, we find out how far an
-intersection point or a ray is from some set of edges
-
-
--- Current Capabilities & Limitations --
-
-Developing a BRL-CAD primitive requires a minimum of 4 basic
-capabilities: reading from a geom db, writing to a geom db, providing
-a plot of the primitive (for MGED display), and handling shot
-intersection, which involves finding all intersections with the
-primitive and returning the results as a list of "segments" (these
-segments will later be used by BRL-CAD to do its boolean weaving).
-
-This primitive currently handles the first 3 capabilities fine, but
-has problems with the intersections (the most important part!)
-
-Issues:
-
-* bad acne (possibly caused by missing surfaces? duplicate
- intersections (making an odd number of hits along the ray), trimming
- errors?
-
-* problems with trimming (not completely sure the bezier clipping is
- correct)
-
-* possible problems with tolerances (been working with a very small
- (~2mm) object that has a moderate number of faces/edges)
-
-* no optimization, bad algorithms: bounding boxes (subsurface bounding
- boxes) should contain correct metadata concerning the need for
- trimming within the box, also a list of edges touched by the box for
- more efficient edge checking, evaluation optimization, etc...
-
-
-The current issue seems to be that we're missing surfaces altogether or
-getting extra intersections! or something funky is happening during
-trimming and edge checking. (BTW Pro/E seems to output overlapping
-surfaces, relying on the outer boundary loop to trim it - this implies
-that it should be quite difficult to actually miss both surfaces at an
-edge (since would have to get at least one intersection if they
-overlap at the edge!)
-
-[[ some pictures may be useful here ]]
-
-See all instances of "XXX" in the code (some may be out of date, but
-if something was fishy or I was being stupid/lazy/ignorant or some
-other bit of code was causing a problem, I tried to mark it with XXX.
-
-
--- Conceptual/Implementation Issues --
-
-model-space curve pullback to surface domain for trimming (introduces
-possible errors while trimming (i.e. at an edge it's possible both
-surfaces can be trimmed because of inaccuracies of sampling)...
-
-multiple intersections found
-
-handling edge/surface grazing consistently
-
-bezier conversion of nurbs curves for trimming
-
-subsurface bounding boxes: when subdividing a surface domain and
-testing for flatness, hard to create a perfect bounding box around the
-subdomain (i.e. such that all points on the surface lie within the
-bounding box.) For the most part this may not be a problem, but
-oblique shots cause problems here (an image would help). Either way,
-the problem of better fitting bounding boxes (without just arbitrarily
-increasing the size which would seriously affect performance) needs to
-be considered... currently attempting to sample an additional 5 points
-(instead of just the corners). This should serve to handle the current
-problem.
-
-Close-up axis aligned rendering of a cylinder from the circular ends
-produces a halo of spurious points. Ugh!
-
-Optimize for small objects (there are some fixed size adjustments in
-the bounding box/subsurface code).
-
-
--- IGES converter --
-
-A significant bit of time was spent writing the skeleton for a new
-IGES converter in order to get non-trivial BREP geometry from an
-external package into BRL-CAD for testing purposes (have been using
-the piston head part from one of the Pro/E tutorial models).
-
-I believe this converter can be made production-ready with some work:
-
-* polish options for output
-
-* handle assemblies and their proper mapping to BRL-CAD
-
-* handle naming? (don't know if IGES carries names, or if Pro/E adds
- them)
-
-* handle units properly!
-
-* tolerances when converting are still flaky (fix it) (cause BREP
- validity problems). Trims endpoint are not within zero tolerance
- (1e-12), so they "don't match" but they are very very close
- (1e-11)... so need to go through and call ON_Brep::CloseTrimGap() on
- each pair of trims in a loop.
-
-* Run lots of test cases!!!
Deleted: brlcad/branches/bioh/doc/bsd_semaphore_bug.txt
===================================================================
--- brlcad/branches/bioh/doc/bsd_semaphore_bug.txt 2020-05-29 16:33:10 UTC
(rev 75985)
+++ brlcad/branches/bioh/doc/bsd_semaphore_bug.txt 2020-05-31 14:04:45 UTC
(rev 75986)
@@ -1,161 +0,0 @@
-The below backtraces were able to catch the infamous "fatal semaphore
-acquisition failure" bug on BSD. This is a bit tricky to catch in the act, so
-the below backtraces are added here to serve as references. They document both
-the gdb backtrace and the trick used to successfully attach to it it (a long
-sleep call compiled in to the key failure area prior to the run, allowing us to
-get a debugger on the program before it actually vanishes.) This case is most
-reliably seen when running make regress in parallel mode - it doesn't usually
-trigger when running individual programs interactively, although those do
-fail occasionally.
-
-So far this has only been observed on FreeBSD.
-
-Adjustment of the bombing message code reveals that the fatal error is
-EPERM - The current thread does not own the mutex.
-
-Maybe relevant (not sure if we have any code that might be using automatic
variables after thread_exit(), but the symptoms sound similar...) Only other
candidate I'm seeing is memory corruption of some sort...
-https://stackoverflow.com/a/7612070
-
-
-The first failure is from a GQA run:
-
-Architecture set to: x86_64--freebsd11.2.
-(lldb) bt
-* thread #1, name = 'gqa'
- * frame #0: 0x0000000817433f5c libthr.so.3`_umtx_op_err + 12
- frame #1: 0x000000081743056a
libthr.so.3`join_common(pthread=0x000000081ae18800,
thread_return=0x0000000000000000, abstime=0x0000000000000000) at thr_join.c:125
- frame #2: 0x0000000814b9b841
libbu.so.20`bu_parallel(func=(libged.so.20`plane_worker at gqa.c:1223),
ncpu=16, arg=0x00007fffffffe660) at parallel.c:722
- frame #3: 0x0000000800af161c libged.so.20`ged_gqa(gedp=0x000000081ae8d000,
argc=11, argv=0x000000081ae1c300) at gqa.c:2449
- frame #4: 0x00000000004010c3 gqa`main(argc=12, argv=0x00007fffffffe828) at
gqa.c:102
- frame #5: 0x0000000000400c05 gqa`_start + 149
-(lldb) thread list
-Process 56371 stopped
-* thread #1: tid = 101853, 0x0000000817433f5c libthr.so.3`_umtx_op_err + 12,
name = 'gqa'
- thread #2: tid = 100989, 0x000000081792e6da libc.so.7`__sys_nanosleep + 10,
name = 'gqa'
-(lldb) thread select 2
-* thread #2, name = 'gqa'
- frame #0: 0x000000081792e6da libc.so.7`__sys_nanosleep + 10
-libc.so.7`__sys_nanosleep:
--> 0x81792e6da <+10>: jb 0x8179a05a4 ; .cerror
- 0x81792e6e0 <+16>: retq
- 0x81792e6e1: int3
- 0x81792e6e2: int3
-(lldb) bt
-* thread #2, name = 'gqa'
- * frame #0: 0x000000081792e6da libc.so.7`__sys_nanosleep + 10
- frame #1: 0x0000000817428a2c
libthr.so.3`__thr_nanosleep(time_to_sleep=<unavailable>,
time_remaining=<unavailable>) at thr_syscalls.c:287
- frame #2: 0x00000008178b19eb libc.so.7`__sleep(seconds=60000) at sleep.c:62
- frame #3: 0x0000000814bb218c libbu.so.20`bu_semaphore_release(i=20) at
semaphore.c:272
- frame #4: 0x0000000800aebc31 libged.so.20`hit(ap=0x00007fffdd7f9dd8,
PartHeadp=0x00007fffdd7f97e8, segs=0x00007fffdd7f98e8) at gqa.c:1093
- frame #5: 0x0000000804062b12
librt.so.20`rt_shootray(ap=0x00007fffdd7f9dd8) at shoot.c:1273
- frame #6: 0x0000000800aec6cf libged.so.20`plane_worker(cpu=5,
ptr=0x00007fffffffe660) at gqa.c:1280
- frame #7: 0x0000000814b9bdcb
libbu.so.20`parallel_interface_arg(utd=0x000000081afedc80) at parallel.c:428
- frame #8: 0x0000000817426026
libthr.so.3`thread_start(curthread=0x000000081ae18800) at thr_create.c:290
-(lldb) up
-frame #1: 0x0000000817428a2c
libthr.so.3`__thr_nanosleep(time_to_sleep=<unavailable>,
time_remaining=<unavailable>) at thr_syscalls.c:287
- 284
- 285 curthread = _get_curthread();
- 286 _thr_cancel_enter(curthread);
--> 287 ret = __sys_nanosleep(time_to_sleep, time_remaining);
- 288 _thr_cancel_leave(curthread, 1);
- 289
- 290 return (ret);
-(lldb) up
-frame #2: 0x00000008178b19eb libc.so.7`__sleep(seconds=60000) at sleep.c:62
- 59
- 60 time_to_sleep.tv_sec = seconds;
- 61 time_to_sleep.tv_nsec = 0;
--> 62 if (((int (*)(const struct timespec *, struct timespec
*))
- 63 __libc_interposing[INTERPOS_nanosleep])(
- 64 &time_to_sleep, &time_remaining) != -1)
- 65 return (0);
-(lldb) up
-frame #3: 0x0000000814bb218c libbu.so.20`bu_semaphore_release(i=20) at
semaphore.c:272
- 269 # if defined(HAVE_PTHREAD_H)
- 270 if (pthread_mutex_unlock(&bu_semaphores[i].mu)) {
- 271 fprintf(stderr, "bu_semaphore_acquire():
pthread_mutex_unlock() failed on [%d]\n", i);
--> 272 sleep(60000);
- 273 bu_bomb("fatal semaphore acquisition failure");
- 274 }
- 275 # endif
-
-
-The second is from an rt raytrace of a bot:
-
-bin/rt".
-Architecture set to: x86_64--freebsd11.2.
-(lldb) bt
-* thread #1, name = 'rt'
- * frame #0: 0x0000000800861f5c libthr.so.3`_umtx_op_err + 12
- frame #1: 0x000000080085e56a
libthr.so.3`join_common(pthread=0x000000081aa3a400,
thread_return=0x0000000000000000, abstime=0x0000000000000000) at thr_join.c:125
- frame #2: 0x000000081455d841
libbu.so.20`bu_parallel(func=(librt.so.20`_db_walk_dispatcher at
db_tree.c:1955), ncpu=16, arg=0x00007fffffffd700) at parallel.c:722
- frame #3: 0x00000008032b0f8e
librt.so.20`db_walk_tree(dbip=0x000000081a861000, argc=1,
argv=0x00007fffffffe888, ncpu=16, init_state=0x00007fffffffd988,
reg_start_func=(librt.so.20`_rt_gettree_region_start at tree.c:109),
reg_end_func=(librt.so.20`_rt_gettree_region_end at tree.c:146),
leaf_func=(librt.so.20`_rt_gettree_leaf at tree.c:444),
client_data=0x00007fffffffd978) at db_tree.c:2199
- frame #4: 0x00000008036661d7
librt.so.20`rt_gettrees_muves(rtip=0x000000081a8a7000,
attrs=0x0000000000000000, argc=1, argv=0x00007fffffffe888, ncpus=16) at
tree.c:783
- frame #5: 0x0000000803669021
librt.so.20`rt_gettrees_and_attrs(rtip=0x000000081a8a7000,
attrs=0x0000000000000000, argc=1, argv=0x00007fffffffe888, ncpus=16) at
tree.c:887
- frame #6: 0x0000000803669142
librt.so.20`rt_gettrees(rtip=0x000000081a8a7000, argc=1,
argv=0x00007fffffffe888, ncpus=16) at tree.c:914
- frame #7: 0x0000000000406a00 rt`def_tree(rtip=0x000000081a8a7000) at
do.c:575
- frame #8: 0x000000000040bd52 rt`main(argc=6, argv=0x00007fffffffe860) at
main.c:495
- frame #9: 0x00000000004062e5 rt`_start + 149
-(lldb) thread list
-Process 7726 stopped
-* thread #1: tid = 100805, 0x0000000800861f5c libthr.so.3`_umtx_op_err + 12,
name = 'rt'
- thread #2: tid = 101797, 0x0000000816ec76da libc.so.7`__sys_nanosleep + 10,
name = 'rt'
-(lldb) thread select 2
-* thread #2, name = 'rt'
- frame #0: 0x0000000816ec76da libc.so.7`__sys_nanosleep + 10
-libc.so.7`__sys_nanosleep:
--> 0x816ec76da <+10>: jb 0x816f395a4 ; .cerror
- 0x816ec76e0 <+16>: retq
- 0x816ec76e1: int3
- 0x816ec76e2: int3
-(lldb) bt
-* thread #2, name = 'rt'
- * frame #0: 0x0000000816ec76da libc.so.7`__sys_nanosleep + 10
- frame #1: 0x0000000800856a2c
libthr.so.3`__thr_nanosleep(time_to_sleep=<unavailable>,
time_remaining=<unavailable>) at thr_syscalls.c:287
- frame #2: 0x0000000816e4a9eb libc.so.7`__sleep(seconds=60000) at sleep.c:62
- frame #3: 0x000000081457418c libbu.so.20`bu_semaphore_release(i=12) at
semaphore.c:272
- frame #4: 0x000000080366a193
librt.so.20`_rt_find_identical_solid(mat=0x0000000000000000,
dp=0x000000081a8a2e98, rtip=0x000000081a8a7000) at tree.c:425
- frame #5: 0x00000008036681e3
librt.so.20`_rt_gettree_leaf(tsp=0x000000081a9fa008, pathp=0x000000081a9fa150,
ip=0x00007fffd69eecc0, client_data=0x00007fffffffd978) at tree.c:491
- frame #6: 0x00000008032ae1b1
librt.so.20`db_recurse(tsp=0x000000081a9fa008, pathp=0x000000081a9fa150,
region_start_statepp=0x00007fffd69eef60, client_data=0x00007fffffffd978) at
db_tree.c:1170
- frame #7: 0x00000008032b35c9
librt.so.20`_db_walk_subtree(tp=0x000000081a81f200,
region_start_statepp=0x00007fffd69eef60,
leaf_func=(librt.so.20`_rt_gettree_leaf at tree.c:444),
client_data=0x00007fffffffd978, resp=0x000000000062e520) at db_tree.c:1898
- frame #8: 0x00000008032b172f librt.so.20`_db_walk_dispatcher(cpu=16,
arg=0x00007fffffffd700) at db_tree.c:1992
- frame #9: 0x000000081455ddcb
libbu.so.20`parallel_interface_arg(utd=0x000000081a9f85e0) at parallel.c:428
- frame #10: 0x0000000800854026
libthr.so.3`thread_start(curthread=0x000000081aa3a400) at thr_create.c:290
-(lldb) up
-frame #1: 0x0000000800856a2c
libthr.so.3`__thr_nanosleep(time_to_sleep=<unavailable>,
time_remaining=<unavailable>) at thr_syscalls.c:287
- 284
- 285 curthread = _get_curthread();
- 286 _thr_cancel_enter(curthread);
--> 287 ret = __sys_nanosleep(time_to_sleep, time_remaining);
- 288 _thr_cancel_leave(curthread, 1);
- 289
- 290 return (ret);
-(lldb) up
-frame #2: 0x0000000816e4a9eb libc.so.7`__sleep(seconds=60000) at sleep.c:62
- 59
- 60 time_to_sleep.tv_sec = seconds;
- 61 time_to_sleep.tv_nsec = 0;
--> 62 if (((int (*)(const struct timespec *, struct timespec
*))
- 63 __libc_interposing[INTERPOS_nanosleep])(
- 64 &time_to_sleep, &time_remaining) != -1)
- 65 return (0);
-(lldb) up
-frame #3: 0x000000081457418c libbu.so.20`bu_semaphore_release(i=12) at
semaphore.c:272
- 269 # if defined(HAVE_PTHREAD_H)
- 270 if (pthread_mutex_unlock(&bu_semaphores[i].mu)) {
- 271 fprintf(stderr, "bu_semaphore_acquire():
pthread_mutex_unlock() failed on [%d]\n", i);
--> 272 sleep(60000);
- 273 bu_bomb("fatal semaphore acquisition failure");
- 274 }
- 275 # endif
-(lldb) up
-frame #4: 0x000000080366a193
librt.so.20`_rt_find_identical_solid(mat=0x0000000000000000,
dp=0x000000081a8a2e98, rtip=0x000000081a8a7000) at tree.c:425
- 422 */
- 423 bu_semaphore_acquire(RT_SEM_STATS);
- 424 stp->st_bit = rtip->nsolids++;
--> 425 bu_semaphore_release(RT_SEM_STATS);
- 426
- 427 /*
- 428 * Fill in the last little bit of the structure in full
parallel
-(lldb)
-
Deleted: brlcad/branches/bioh/doc/bu_opt_design_notes.txt
===================================================================
--- brlcad/branches/bioh/doc/bu_opt_design_notes.txt 2020-05-29 16:33:10 UTC
(rev 75985)
+++ brlcad/branches/bioh/doc/bu_opt_design_notes.txt 2020-05-31 14:04:45 UTC
(rev 75986)
@@ -1,97 +0,0 @@
-Thoughts on expansion of bu_opt capability to include subcommands, other misc
-notes...
-
-Check over POSIX.1-2008 Utility Conventions - should guide (but not define) our
-option handling. (In particular, we want long opts. On the other hand,
-probably explicitly don't want the full GNU 'opts anywhere' convention as that
-precludes structured subcommand parsing.)
-
-http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html
-
-* Define separate structure for subcommands, have as an optional pointer in
- bu_opt structure.
-
-* Explore + and -+ as opt/longopt specifiers for subcommands, directly mapping
to
-- and -- for options. Use +- to denote the end of a subcommand, like -- denotes
-end of options.
-
-Rule - options with optional arguments (e.g. --help JSON vs --help - both are
-legal) will require that arguments needing to start with a "+" character (e.g.
---help "+arg1") be quoted. (For that matter, is the same true of normal "-"
-option parsing?)
-
-Can we allow "lazy" subcommand specification without +/-+ if we disqualify any
-string in quotes from being a subcommand? (e.g. 'cmd arg1 arg2' treats arg1 as
-a subcommand but 'cmd "arg1" arg2' treats arg1 as an arg? Do we need to worry
-about this at all?
-
-Can "leftover" operands from a subcommand be handed back up to parent commands?
-
-Convention thoughts:
-
-- or -- - option/long-option handling per POSIX and GNU convention.
-
-+ or -+ - explicit specifier of subcommand.
-
--- - explicit 'exit option parsing' mode - remainder is operands (per POSIX)
-except that a -+ option will indicate another subcommand or a +- will elevate
-the parsing environment back to the parent level.
-
-+- "exit subcommand" - returns parsing to the parent level command evaluation
-environment: brep -a1 -+plot -p1 +- -o out.pl results in brep handling -o
-out.pl, not plot.
-
-Scope of "next arg" other than +- is current command/subcommand: e.g. brep -a1
--+plot -p1 will pass p1 to plot's option handling, not brep's
-
-If subsequent -+ are specified, first check if the current command has the
-specified subcommand. If not, return parsing to the parent level to see if it
-has the specified subcommand, and so on until a command table claims the
-subcommand. Allows for both a subcommand of a subcommand:
-
-brep obj_csg.c -+bool_eval -+plot curve S1_S2
-
-and subsequent subcommands:
-brep obj_csg.c -+facetize -+simplify
-
-to be specified without requiring +- unless a command and a subcommand both
-have a matching subcommand.
-
-With that feature present, +- is necessary to specify a parent command's
version of
-the subcommand unambiguously (i.e. requires explicit exiting of subcommand
state with
-a matching subcommand):
-
-cmd arg1 +c +d -> runs d subcommand defined by c
-cmd arg1 +c +- +d -> runs d subcommand defined by cmd
-
-
-TODOs for bu_opt help routines:
-
-Maybe have help as a default subcommand rather than a default option, to allow
for fancy
-stuff without bastardizing the help option?
-
-* define a built-in bu_help to support docbook, json, etc. specification which
- can be used by commands not wanting to define their own, more complex
options.
-
-* need a routine to generate a POSIX compliant one-line description of the
- command's syntax
-
-* need built-in help (option or subcommand, maybe both?) that is available for
- commands not wanting to define their own help, but can be over-ridden by an
- explicit specification of help in the options. We will need some "smart"
help
- options for JSON, DocBook, etc as well as subcommand listing (--help cmds
- maybe?) so a calling script can systematically and automatically generate
- documentation for all commands.
-
-* explore the possibility of adding to the help system a generator of some sort
- that can produce a JSON structure describing the structure of the commands
and
- options in such a way that a libbu routine could accept that structure as a
- validation template and validate a command line string against it. Would
- (potentially) allow for things like smart tab completion, valid/invalid
syntax
- highlighting, etc. without having to either explicitly duplicate the command
- syntax in code or back such validation logic into each command. With this
- setup we would run the "generate syntax" help option for every
command/subcommand
- in all of BRL-CAD (which just coincidentally would make the function of the
- help system for every command in the code a build time requirement/check)
- and supply a pre-built validation database in a data_dir location for libbu
- to check.
Deleted: brlcad/branches/bioh/doc/cmake_vars.txt
===================================================================
--- brlcad/branches/bioh/doc/cmake_vars.txt 2020-05-29 16:33:10 UTC (rev
75985)
+++ brlcad/branches/bioh/doc/cmake_vars.txt 2020-05-31 14:04:45 UTC (rev
75986)
@@ -1,99 +0,0 @@
-# This is a worksheet to help with organizing our CMake options with
-# an eye towards consistency, clarity, and simplification.
-#
-# TODO:
-# * consistent naming convention
-# * eliminate aliases
-# * drop unnecessary/unhelpful/obsolete flags
-# * audit what ccmake presents by default
-#
-
-### HOW TO COMPILE ###
-
-CMAKE_BUILD_TYPE := Release | Debug
-
-BRLCAD_ENABLE_VERBOSE_PROGRESS "verbose output" OFF
-BRLCAD_ENABLE_COVERAGE "Build with coverage enabled" OFF
-
-ENABLE_ALL_CXX_COMPILE "Build all C and C++ files with a C++ compiler." OFF
- ENABLE_ALL_CXX
-ENABLE_POSIX_COMPLIANCE
- ENABLE_POSIX
-
-BRLCAD_ENABLE_PROFILING
-BRLCAD_ENABLE_DTRACE "Build with dtrace support" OFF
-
-BRLCAD_ENABLE_SMP "Enable SMP architecture parallel computation support" ON
-BRLCAD_ENABLE_RUNTIME_DEBUG
- ENABLE_RUNTIME_DEBUG
- ENABLE_RUN_TIME_DEBUG
- ENABLE_RUNTIME_DEBUGGING
- ENABLE_RUN_TIME_DEBUGGING
-BRLCAD_FLAGS_DEBUG
- ENABLE_DEBUG
- ENABLE_FLAGS_DEBUG
- ENABLE_DEBUG_FLAGS
-BRLCAD_ENABLE_COMPILER_WARNINGS
- ENABLE_WARNINGS
- ENABLE_COMPILER_WARNINGS
-BRLCAD_ENABLE_STRICT
- ENABLE_STRICT
- ENABLE_STRICT_COMPILE
- ENABLE_STRICT_COMPILE_FLAGS
-ENABLE_STRICT_COMPILER_STANDARD_COMPLIANCE "Build with strict ISO C compliance
checking. Defaults to OFF." OFF
-
-
-### WHAT TO COMPILE ###
-
-BRLCAD_ENABLE_MINIMAL "Skip GUI support and docs. Faster builds." OFF
-BUILD_SHARED_LIBS "Build shared libraries" ON
-BUILD_STATIC_LIBS "Build static libraries" ON
-BRLCAD_ENABLE_BRLCAD_LIBRARY "Build the brlcad.dll" OFF
-
-BRLCAD_BUNDLED_LIBS := AUTO | BUNDLED | SYSTEM
- ENABLE_ALL
-
-BRLCAD_ENABLE_AQUA "Use Aqua instead of X11 whenever possible on OSX." OFF
-BRLCAD_ENABLE_X11 "Use X11." OFF
-BRLCAD_ENABLE_TK "Enable features requiring the Tk toolkit" ON
-BRLCAD_ENABLE_OPENGL "Enable support for OpenGL based Display Managers in
BRL-CAD." ON
- OFF "Disabled - NOT BRLCAD_ENABLE_X11 and NOT
BRLCAD_ENABLE_AQUA"
- ENABLE_OPENGL
-BRLCAD_ENABLE_QT "Enable features requiring Qt" OFF
-BRLCAD_ENABLE_OSG "Enable features requiring OpenSceneGraph" OFF
-
-BRLCAD_ENABLE_RTGL "Enable experimental RTGL code." OFF
-BRLCAD_ENABLE_BULLET "Enable features requiring the Bullet Physics Library" ON
-BRLCAD_ENABLE_GCT "Enable features requiring GCT" ON
-BRLCAD_ENABLE_GDAL "Enable features requiring the Geospatial Data Abstraction
Library" ON
-BRLCAD_ENABLE_SPR "Enable features requiring Screened Poisson Surface
Reconstruction" OFF
-
-BRLCAD_ENABLE_BINARY_ATTRIBUTES "Enable support for binary attributes" OFF
-
-BRLCAD_ENABLE_OPENCL "Enable features requiring OpenCL" OFF
-
-BRLCAD_EXTRADOCS
- ENABLE_DOCS
- ENABLE_EXTRA_DOCS
- ENABLE_DOCBOOK
-BRLCAD_EXTRADOCS_VALIDATE "Perform validation for DocBook documentation" ON
-BRLCAD_EXTRADOCS_HTML "Build MAN page output from DocBook documentation" ON
-BRLCAD_EXTRADOCS_PHP "Build MAN page output from DocBook documentation" OFF
-BRLCAD_EXTRADOCS_PPT "Build MAN page output from DocBook documentation" ON
-BRLCAD_EXTRADOCS_MAN "Build MAN page output from DocBook documentation" ON
-BRLCAD_EXTRADOCS_PDF "Build PDF output from DocBook documentation" OFF
-BRLCAD_ENABLE_TARGETS "controls all DocBook based documentation. Keys off
what target level is enabled."
- EXTRADOCS_DEFAULT is ON when <= 2 ; OFF when > 2
-
-
-### HOW TO INSTALL ###
-
-BRLCAD_ENABLE_WIX
-BRLCAD_INSTALL_EXAMPLE_GEOMETRY "Install the example BRL-CAD geometry files."
ON
-
-# Local Variables:
-# tab-width: 8
-# mode: cmake
-# indent-tabs-mode: t
-# End:
-# ex: shiftwidth=2 tabstop=8
Deleted: brlcad/branches/bioh/doc/csv_to_comgeom.txt
===================================================================
--- brlcad/branches/bioh/doc/csv_to_comgeom.txt 2020-05-29 16:33:10 UTC (rev
75985)
+++ brlcad/branches/bioh/doc/csv_to_comgeom.txt 2020-05-31 14:04:45 UTC (rev
75986)
@@ -1,17 +0,0 @@
-These are some notes about using text manipulation tools to try taking the csv
-text files from GCI's transcription work and formatting them as comgeom files.
-I don't think they're fully working as yet, but certainly they are a starting
-point.
-
-tr "\r" "\n" < in_raw.csv > in.csv
-
-Solid table:
-
-awk -F, 'BEGIN {widthlist = "3 3 10 10 10 10 10 10 10"; split (widthlist,
widths, " ")}{for(i=1;i<=NF;i++){printf "%-*s", widths[i],$i};printf "\n"}'
in.csv
-
-Region table:
-awk -F, 'BEGIN {widthlist = "5 2 5 7 7 7 7 7 7 7 2 5 10"; split (widthlist,
widths, " ")}{for(i=1;i<=NF;i++){printf "%-*s", widths[i],$i};printf "\n"}'
in.csv
-
-Ident table:
-awk -F, 'BEGIN {widthlist = "10 10 10 43 3 3"; split (widthlist, widths, "
")}{for(i=1;i<=NF;i++){printf "%-*s", widths[i],$i};printf "\n"}' in.csv
-
Deleted: brlcad/branches/bioh/doc/cvs.txt
===================================================================
--- brlcad/branches/bioh/doc/cvs.txt 2020-05-29 16:33:10 UTC (rev 75985)
+++ brlcad/branches/bioh/doc/cvs.txt 2020-05-31 14:04:45 UTC (rev 75986)
@@ -1,804 +0,0 @@
-BRL-CAD Concurrent Versions System Policy and Guidelines
-========================================================
-
-
-**********************************************************************
-NOTE: THESE INSTRUCTIONS ARE OUT-OF-DATE AS BRL-CAD NOW USES
-SUBVERSION INSTEAD OF CVS. CONSULT WITH CAUTION AS SOME PORTIONS ARE
-STILL RELEVANT BUT OTHERS THAT ARE CVS-SPECIFIC ARE NOT.
-**********************************************************************
-
-
-The document includes a set of requirements and recommended procedures
-for how to effectively use CVS with this project. Included are
-details on checking code in and out, effective use of commit messages,
-tag naming conventions, branch management, making releases, and more.
-Basic knowledge of CVS, its capabilities, and to a lesser extent its
-limitations are beyond the scope of this document. See the CVS
-website and the "References" section for more information. That said,
-the following general rules should always be adhered to:
-
-1. Code committed against HEAD should at least be tested and compile
- for the developer committing changes. "Don't break it."
-
-2. There is a STABLE branch that may only have code committed against
- it that a) compiles on all relevant platforms, b) does not
- detrimentally degrade performance, and c) runs correctly passing
- available validation tests.
-
-3. Branches should be used for experimental work that would otherwise
- leave HEAD in an inconsistent, non-compiling, or untestable state.
- Branches are not merged into HEAD until the code has been tested
- for correct and proper functionality.
-
-4. Commit and update frequently. Large or complicated changes should
- be broken up into smaller succinct commits as best possible to make
- reviewing easier. Commit working code early and commit often.
-
-5. Be consistent and informative. Tags need to follow a consistent
- naming convention. Commit messages need to be informative. Source
- code changes should follow existing style and be usefully
- commented.
-
-
-TABLE OF CONTENTS
------------------
- Introduction
- Table of Contents
- Overview
- Checking out sources
- from HEAD
- from STABLE
- from a branch/revision
- Checking in sources
- commit messages
- to HEAD
- to STABLE
- to a branch/revision
- Tag naming convention
- for releases
- for branches
- Making a release
- creating a maintenance branch
- applying release patches
- Merging a branch
- merging a branch into HEAD
- merging HEAD into a branch
- Making a branch
- Usage Tips
- References
-
-
-OVERVIEW
---------
-
- Code organizational sanity and consistency are of paramount
- importance. As CVS can both help and hinder efforts to keep the
- sources organized, the policy and guidelines outlined herein
- overview the manner in which CVS should be used with this project.
-
- This CVS policy and guidelines document should be used in
- combination with a developer's guide that covers other aspects of
- code contributions and developer behavior such as how and where to
- provide patches, what coding styles should be used, and how to
- make releases. Likewise, exact semantics of testing policy,
- requirements for migrating code from HEAD to STABLE, basic CVS
- usage, and release policy are outside the scope of this document.
-
- The intent of this document is to cover the broad aspects of how
- CVS is to be organized and used. This includes branch management,
- tag naming conventions, checking sources in and out, and other
- relevant usage policy.
-
- CVS branches should be used to separate out the various types of
- source code revisions. These include:
-
- 1) current or "active" sources
- 2) stable sources
- 3) releases
- 4) experimental sources
-
- The CVS HEAD is for active development. A separate STABLE branch
- exists to hold a revision of the sources that is validated and
- tested across platforms. Releases should only made off of stable
- revisions of the source code. When a release is made, a
- maintenance branch may and should exist for making patch releases.
- Finally, various experimental and developer undertakings that may
- benefit by being isolated from changes to HEAD or STABLE, or would
- likewise be disruptive to normal HEAD functionality, may live on
- a branch of their own.
-
- It's very important that the main CVS HEAD revision be a "mostly"
- stable code base so that at any given time users may download the
- latest sources, get the source code to compile with minimal
- effort, and have the core components mostly function as expected.
- See the "Checking in sources to HEAD" section for more details.
-
- Some users and developers will need from time to time to obtain a
- relatively recent version of the sources that is certain or at
- least expected to "work". This is what the STABLE branch is for.
- See the "Checking in sources to STABLE" section for more
- information.
-
-
@@ Diff output truncated at 100000 characters. @@
This was sent by the SourceForge.net collaborative development platform, the
world's largest Open Source development site.
_______________________________________________
BRL-CAD Source Commits mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-commits
