Constraint-based three-dimensional dynamic geometry
From a thorough web search, there does not seem to be a dynamic geometry software package which (a) began its life handling three dimensions, rather than just two, and (b) allows you to express the desired geometric configuration in terms of constraints on the entities (e.g. l and k are parallel, a, b, and c a collinear, etc.) rather than as a construction (e.g. l is the perpendicular bisector of a and b). The goal of the dyna3 project is to close this gap.
Note that currently this is just the barest beginnings of the project, more of a framework for developing dyna3 rather than anything useful.
When you load dyna3, you should initially see a three-dimensional coordinate system with labeled axes.
The dyna3 program depends on some externally-maintained JavaScript libraries/modules. The package uses npm to track these external dependencies. A module externals.js is automatically generated from the package.json and package_lock.json files created by npm to load the necessary modules at runtime.
The generation is performed by pkglock_to_externals.litcoffee, which also records the main importable file within the library, as there does not seem to be a systematic way to generate that filename from the module name.
Specific packages/implementation approaches for components of dyna3 include the following items. All packages are obtained from npm unless otherwise noted.
And here is the current complete list of external libraries on which operation of dyna3 depends:
The intial modest outline for bootstrapping dyna3 is as follows:
dyna3 will be an npm project, but as it runs entirely client-side, there’s no initial concern for being able to run under Node.js. However, npm will be useful as a dependency manager and build tool. In addition, helper scripts for the build can be run with node (via coffee).
The package will build into a top-level site/ directory, which will contain all and only the files that must be on a server to deliver dyna3 to a client browser. Everything in site/ will generated from the package files; nothing in site/ will be committed to the repository. Right now the planned contents a of site/ are just a handful of top-level files, the modules/ directory for in-package javascript, the /doc directory for generated documentation, and a copy of the node_modules/ directory as a backup for the external dependencies.
Literate coffeescript modules (in the src/modules directory except for the top-level application) will compile into individual js modules in the site/modules directory (again, except for the top-level application)
Why coffeescript? The motivation for the javascript family of languages is wide deployability and availability of numerous libraries; the motivation for coffeescript is that it (still) reduces the amount of punctuation and extraneous characters from Javascript, resulting in better readability. And Literate coffeescript so that the manual and code are co-located.
All modules will use ES Modules syntax/format for imports.
index.html will be minimal, perhaps containing just a title, and maybe a link to generated documentation in the site/doc directory. All of the modules will create the DOM elements needed to display themselves on the fly.
The documentation will be generated by a coffeescript template (gendoc.litcoffee) which collates in the proper order several particular Markdown files, starting with README.md. The list of files includes all of the Literate Coffeescript files, with the actual code stripped out, leaving just the Markdown. The resulting dyna3.md file will be further processed into HTML and placed in the site directory.