Revision: 55786
http://sourceforge.net/p/brlcad/code/55786
Author: brlcad
Date: 2013-06-14 19:55:25 +0000 (Fri, 14 Jun 2013)
Log Message:
-----------
more completed tasks including Skriptkid's work implementing thread affinity
for posix threading. decided stashing a matrix as an attribute was a bad idea
(bad analysis results on older versions). release steps now have automatic
update steps.
Modified Paths:
--------------
brlcad/trunk/TODO
Modified: brlcad/trunk/TODO
===================================================================
--- brlcad/trunk/TODO 2013-06-14 19:42:38 UTC (rev 55785)
+++ brlcad/trunk/TODO 2013-06-14 19:55:25 UTC (rev 55786)
@@ -67,7 +67,9 @@
* improve compile-time version management -- port brlcad-version to
windows, reconsider providing compile-time header constants.
+* windows smp support
+
THESE ARE UNSCHEDULED BACKLOG TASKS
-----------------------------------
@@ -767,8 +769,6 @@
* hook bombardier in for crash reporting
-* windows smp support
-
* modify the new tree traversal code to be generic
* add high dynamic range image support to the framebuffers
@@ -814,20 +814,12 @@
* run indent.sh on directories (one at a time, validating results)
-* add support for arbitrary matrix transformations to torus primitive.
- store non-uniform scaling matrices as an attribute for
- backwards-compatible support until v6.
-
* configure support to enable/disable framebuffers, display
managers, geometry converters, and image converters. consider
apache's module management as an example.
* review and merge in the rest of the GSI modifications
-* make target and/or script to update ChangeLog and version
- information, possibly including checking for consistency, to
- facilitate release process.
-
* display the current mode in mged graphics window
* Optional compile-time support for using GMP or CLN for arbitrary
@@ -861,8 +853,6 @@
so you could return primitives to local coordinates. See sf feature
request 2826720 from cericole.
-* test for USE_FORKED_THREADS in configure
-
* optimize CSG structures automatically: automatic simplification,
tree contraction, null object detection.
@@ -890,9 +880,6 @@
* add callback data parameters to libpkg hook functions
-* investigate performance impact of using sched_setaffinity and/or
- pthread_attr_setaffinity_np for linux threading affinity in librt.
-
* rtedge-style tracer that outputs tool paths (splines/segments, etc.)
for CNC/CAM style toolpath cutting descriptions (g-code files).
@@ -911,6 +898,76 @@
* add support for filesystem-based geometry collections
+* design plugin system to allow domain specific tools (say, for example,
+ a tool to create propeller parts) to identify themselves and their
+ features to BRL-CAD, and to allow BRL-CAD to incorporate those features
+ as an integrated part of interaction environments.
+
+* see if it is possible to use tec/ehy primitives to create a proc-db
+ for airfoil/wing shapes. Interesting possibilities with boolean combinations
+ of these primitives, provided their continuity at the ends ensures
+ continuity all along "seams" - something to consider.
+
+* incorporate some variety of spatial partitioning into the facetize command
+ (may involve just rewriting it) to try and realize MUCH faster tessellation
+ of CSG geometry. Current routines are doing a lot of unnecessary work that
+ tends to result in explosive completion times for worst-case scenarios -
+ try to get closer to the "only do the work we need to" ideal. Once a new
+ idea is proven in that command, it should be made into a libgcv routine
+ and convertors/other commands retargeted to use it.
+
+* look into embedding both rgb[3] and complex[n] data types in a union to
+ allow unification of libmultispectral and liboptical APIs to a single
+ more general liboptical. Need to be careful about performance and
+ maintainability concerns.
+
+* we need to define a libbu api for option handling that supports more
+ features than getopt:
+
+ - need support for long options (e.g. --help and --color, not just -h
+ and -C)
+
+ - need a way to consolidate documentation for options into one place
+ (DRY) that supports all of our various documentation styles. Discussed
+ with Sean in the past - initial thoughts:
+
+ + should be in C code - will be needed there, and easier to get it from
+ there to other formats than vice versa.
+
+ + should support printing out the options and documentation in formatted
+ structures that allow our build system to build the command and have
+ the command itself supply a generated snippit of text or markup that
+ could be incorporated into the final document - e.g. the DocBook
+ man page for a command would be set up to expect the
<command>_options.xml
+ file generated by <command> --print-options DocBook (or some other
+ mechanism, that's just an idea) and the CMake build could first build and
+ then run the command at compilation time to provide the absolute most
+ current option listing and short descriptions for the other docs.
+
+ - need to allow order dependent options (e.g. <command> inputfile outputfile)
+ that become order independent if enough information is available, e.g. the
+ above would work and <command> <opt1> -i inputfile <opt2> -o outputfile
<opt3>
+ would also work.
+
+ - (maybe) incorporate some sort of sanity/bounds checking into the option
+ definitions API - i.e. in the C definition of an option, there could
+ be optional parameters to indicate the type and bounds of valid input
+ to that option. Won't always be possible, but may be a good feature
+ to have if it can save lots of repetitive coding of bounds checking in
+ programs.
+
+ *might* be worth taking a look at http://rpm5.org/files/popt/ to see if
+ they have any code we could snarf to make life easier, but regardless
+ we need a libbu API on top of any other code - at such a core level,
+ we can't introduce an external API.
+
+* add per-face analysis of primitives like tgc, arb to their respective
+ analyze commands in libged
+
+* investigate the libngpcore and libngput libraries from the ngPlant
+ project as a possible means of procedurally generating plant models
+ in BRL-CAD (libraries are BSD licensed: http://ngplant.sourceforge.net)
+
* add missing manual pages (jra generated list on 04.2007):
a-d
@@ -1030,77 +1087,7 @@
xyz-pl
yuv-pix
-* design plugin system to allow domain specific tools (say, for example,
- a tool to create propeller parts) to identify themselves and their
- features to BRL-CAD, and to allow BRL-CAD to incorporate those features
- as an integrated part of interaction environments.
-* see if it is possible to use tec/ehy primitives to create a proc-db
- for airfoil/wing shapes. Interesting possibilities with boolean combinations
- of these primitives, provided their continuity at the ends ensures
- continuity all along "seams" - something to consider.
-
-* incorporate some variety of spatial partitioning into the facetize command
- (may involve just rewriting it) to try and realize MUCH faster tessellation
- of CSG geometry. Current routines are doing a lot of unnecessary work that
- tends to result in explosive completion times for worst-case scenarios -
- try to get closer to the "only do the work we need to" ideal. Once a new
- idea is proven in that command, it should be made into a libgcv routine
- and convertors/other commands retargeted to use it.
-
-* look into embedding both rgb[3] and complex[n] data types in a union to
- allow unification of libmultispectral and liboptical APIs to a single
- more general liboptical. Need to be careful about performance and
- maintainability concerns.
-
-* we need to define a libbu api for option handling that supports more
- features than getopt:
-
- - need support for long options (e.g. --help and --color, not just -h
- and -C)
-
- - need a way to consolidate documentation for options into one place
- (DRY) that supports all of our various documentation styles. Discussed
- with Sean in the past - initial thoughts:
-
- + should be in C code - will be needed there, and easier to get it from
- there to other formats than vice versa.
-
- + should support printing out the options and documentation in formatted
- structures that allow our build system to build the command and have
- the command itself supply a generated snippit of text or markup that
- could be incorporated into the final document - e.g. the DocBook
- man page for a command would be set up to expect the
<command>_options.xml
- file generated by <command> --print-options DocBook (or some other
- mechanism, that's just an idea) and the CMake build could first build and
- then run the command at compilation time to provide the absolute most
- current option listing and short descriptions for the other docs.
-
- - need to allow order dependent options (e.g. <command> inputfile outputfile)
- that become order independent if enough information is available, e.g. the
- above would work and <command> <opt1> -i inputfile <opt2> -o outputfile
<opt3>
- would also work.
-
- - (maybe) incorporate some sort of sanity/bounds checking into the option
- definitions API - i.e. in the C definition of an option, there could
- be optional parameters to indicate the type and bounds of valid input
- to that option. Won't always be possible, but may be a good feature
- to have if it can save lots of repetitive coding of bounds checking in
- programs.
-
- *might* be worth taking a look at http://rpm5.org/files/popt/ to see if
- they have any code we could snarf to make life easier, but regardless
- we need a libbu API on top of any other code - at such a core level,
- we can't introduce an external API.
-
-* add per-face analysis of primitives like tgc, arb to their respective
- analyze commands in libged
-
-* investigate the libngpcore and libngput libraries from the ngPlant
- project as a possible means of procedurally generating plant models
- in BRL-CAD (libraries are BSD licensed: http://ngplant.sourceforge.net)
-
-
NEW OBJECTS
-----------
This was sent by the SourceForge.net collaborative development platform, the
world's largest Open Source development site.
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
BRL-CAD Source Commits mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-commits
