Skip to content

TODO.md

Latest commit

 

History

History
1940 lines (1253 loc) · 87.6 KB

TODO.md

File metadata and controls

1940 lines (1253 loc) · 87.6 KB

TODO

  1. consider automatic formatting support ala go fmt => eslint --fix

  2. add NPM style guide with versioning info

  3. determine how to handle internal @stdlib links in READMEs

    => use pkg name as unique identifier and use tools to autoupdate READMEs with desired link (e.g., to GitHub README for pkg or to web docs, etc)

  4. create an docs/install.md for developers

    • julia
    • R
    • python
    • golang
    • boost

  5. determine a browser testing strategy

    • could run into memory issues if all numeric tests are run for all functions, etc.
    • one possibility is to loop through all files and run each individually (browserify, testling, and repeat)
    • may have to punt browser testing to individual repos (!) => that is too late, as module would already be deployed

  6. std polyfills?

    • typed-array
    • ...

  7. add unit tests for all pkg CLIs

  8. how to handle browser tests for non-browser fcns

    • e.g., fs functions like fs/exists, or cwd
    • one option is to simply skip tests (which is most likely appropriate for most cases)
    • another option is to use a virtual fs backend in which, to a user, fs commands "behave" just like in Node (which is appropriate for other contexts; e.g., a browser REPL with a virtual filesystem)

  9. migrate JSDoc; use one of

  10. debug eval sources

  11. livegrep for stdlib? Maybe have sthg hosted? Would be an advance over GitHub search as GitHub search often shows results which happened far back in commit history, when what you want is results from the current state of the repo.

  12. See tinycolor

  13. consider changing isNumber to isNumeric

  14. prngs

  15. Makefile target to run test fixtures

    • detect script type; e.g., R, python, Julia, Golang, C, C++, or JS
    • can be as simple as filename extension
    • of course, may also want to use a shell script to run tests (.sh)
    • for files without an extension, assume executable
    • run the script
    • may want to chmod the script, so do not need to know the system alias for the runner environment (e.g., Julia => julia) and can leverage internal shebang
    • if part of CI, would allow continuous testing against an updated fixture space and would also allow continuous testing that fixture runners work

  16. should utils/function-name support generator functions?

    • a separate function?

  17. replace require statements of external compute modules

  18. tests for top-level tools; e.g., JSDoc templates, etc

  19. deploy plato complexity report to gh-pages

    • similar to JSDoc source docs

  20. type-of should check for toStringTag support

  21. generic is-finite util should include note about how differs from global isFinite

  22. create better examples for constants

    • e.g., how and why and in what contexts a constant may be used
    • e.g., float64-max-exponent => useful for randomly generating numbers across the entire range of possible numbers (sort of, as only 1. decimals => logspace)

  23. investigate textlint

  24. project stats

    • use ndu to visualize dependency size
    • use disc to visualize browserify output (see also browserify-size)
    • cost-of-modules
    • get-nps
    • could do something akin to issue stats but locally and/or only including project modules/repos
    • later project stats can be displayed in a separate webpage
    • see visualcinnamon.com for inspiration

  25. FIX: security vulnerability when using rm -rf in Makefile rules

    • due to using environment variables. If one is improperly set, could be catastrophic. Safe delete?

    • consider trash and trash-cli

      • No, as Sindre does not provide backward compatibility. Will need to roll our own.

  26. Makefile does not list top-level examples; is this intentional?

  27. add Saucelabs with zuul (?)

  28. gh-pages

  29. may be useful: browser-repl

  30. module to identify equations in README files

    • parse
    • generate svg
    • generate html
    • commit
    • insert into readme (replace anything already existing)
    • similar to Makefile test targets, include a target to filter and selectively update README equations

  31. jsdoc HTML template

    • needs a total refactor
    • browserify pipeline
    • mathjax
    • see documentation.js and turf

  32. tailor Mathjax config

  33. a project reference manager?

    • something akin to bibtex; i.e., a centralized list of references which can be globally referenced (e.g., IEEE754, as the Wikipedia reference, etc)
    • an individual module, when created, would get the global link included in the README
    • an individual module could override a reference by including a different link, but having the same "tag" in its README
    • academic markdown and citations
    • scholdoc
    • scholarly markdown
    • scholarly markdown guide
    • R markdown
    • Citeproc JSON
    • citeproc-js
    • bibjson
    • multimarkdown
    • tidying Markdown reference links
    • ...
    • separate bib doc(s), which can be readily converted to JSON (e.g., TOML or YAML), thus allowing comments (or maybe even a JSDoc like syntax and something akin to typedefs)
    • in Markdown, use citation markup strategy similar to scholarly markdown
    • given a Markdown file, create a list of two things: the unique citation identifiers used throughout the text and any citations included in the links section
    • ignore internal links to other Markdown sections
    • if an id is found in bib docs, use that reference
    • otherwise, leave the existing ref as is
    • as part of this, should be able to lint
    • once finished, save to disk
    • does require a separate build step, but can be automated pre-push or via watch
    • how would we distinguish (in markup) between just wanting a link and wanting a full-blown reference citation? => maybe if within a references section, similar to links

  34. consider standard-version

  35. add to contribution guidelines

  36. in all tests (and examples), replace Math.random with a seeded lcg

    • for tests, be sure to record the seed so that failed tests can be debugged
    • could have seed be an environment variable, so could be set in CI environment
    • module to get a seed; one method used could be to check env var

  37. investigate nbind

    • could be useful for, say, Boost bindings

  38. Deploy a webhook server to aggregate 3rd party tools notifications (?)

    • Travis CI
    • AppVeyor
    • Codecov
    • Code Climate
    • Circle CI
    • GitHub

  39. make Travis and Appveyor build badges the same dimensions

    • currently, Appveyor includes a logo
    • could use shields.io

  40. consider using svgo to minimize eqn svgs

  41. C++ style guide => use *.cpp and *.hpp

  42. find inspiration for the JS style guide from C++ core guidelines

    • include ESLint rules for each (where applicable) guideline
    • include references (e.g., perf, fast elements, etc)

  43. add code climate badge

  44. consider using tools for linting files other than JavaScript

  45. on src doc build for gh-pages, also do the same for develop; e.g., /docs/src/develop, which could map to http://a.b.c/docs/src/develop

    • would allow a "preview" alongside current prod
    • will also want src docs for each version

  46. investigate whether bit operators would be better for is-even and is-odd

  47. browserify transform to load all "man" pages (e.g., readmes or actual man pages)

    • allow help docs to be loaded into a browser for interactive environments
    • store in local storage (?) or in-memory

  48. load modules into a REPL

    • man pages can be READMES (or not; may require separate usage.txt tailored to REPL env)

    • can these be dynamically compiled/transformed at runtime, or will startup time be too slow

      • dynamic would be nice, as then would not need to maintain a separate collection of man docs

        • need some way of determining which modules are exposed in the REPL (could possibly parse the context files a la browserify, find require statements, and build), finding their READMEs, transforming, and then building a hash table for printing in the REPL

    • help(blas.copy) (or help("blas.dcopy") or ? blas.dcopy (like Julia))

    • with maps, should be able to use function reference (symbol) as key

    • refs

    • ASCII charts

    • ASCII tables

    • should be able to load a REPL context in a browser

    • meaning, should be able to fairly seamlessly have a session in a terminal which is "transferred" to a browser context, including shell history and, say, charts (ASCII to an SVG equivalent)

    • would allow "sharing" a REPL sequence (work in the terminal; load session to browser; generate page; send link/page; recipient load and can start where sender left off)

    • black-screen terminal emulator

    • see hyperterm

  49. README to man doc (see above)

  50. interactive JSON editor

  51. flatson

  52. REPL incremental json

  53. engines field

    • have a script which mines the individual package.json engine fields and determines, in aggregate, the supported engine range for all pkgs and assign as the engine range for the "aggregate"
    • can also lint (search pkg deps, check engine field, and see if compatible)

  54. intro how-tos

  55. evaluate using inch for src code documentation evaluation

  56. link gitter to slack (prob requires a hook server)

  57. investigate xonsh

  58. investigate async but awaitful

  59. list-modules Makefile recipe

    • can be used in conjunction with dep analysis to see which modules are not required by a file, etc; e.g., which modules are not included in a namespace.

  60. list-required-modules (name?) Makefile recipe

    • should analyze require graph (ala browserify) to determine dependencies
    • should work for a single file or a directory
    • for directory, may want to dedupe (flat array), a tree result which states which modules require which modules (similar to a node dependency graph), or, for every found module, the deps for that module (array of arrays)
    • see automation/package.json item below
    • a tree representation could be useful as would allow metrics such as tree "depth", in which we can identify files/modules/pkgs with "deep" trees

  61. investigate npm-publish-please and np (Sindre)

    • not sure a separate tool is necessary, but may find inspiration

  62. REPL startup file, similar to startup.m

    • either command-line option or via a REPL config file
    • could possibly use configstore, or something similar, to cache the config

  63. doctest

  64. to browser (see tools/simple-http-server)

  65. cross-platform open browser

  66. ability to run examples in a browser => Makefile target examples-browser

    • can use simple-http-server (or even disposable-http-server)
    • packify
    • option to stream to multiple browsers (tabs) in parallel (akin to parallel builds)
    • would also be nice to have editor support (e.g., keyboard shortcut to run current file in a browser)

  67. build step which runs examples in browsers and catches any errors

    • could possibly listen on window.onerror to trap uncaught exceptions
    • setup similar to testling, but without needing TAP output; basically, do any errors occur or not
    • will probably need source maps, otherwise will be difficult to debug
    • as a half-way measure, could intercept console method calls, pipe back to server, and then keep a rolling log cache; when an error is received, could stop running examples and print the cache

  68. bring glob in-house

  69. review CoC for more community oriented policies

    • add note about right to delete offending comments, etc; e.g., Chakra core

  70. add JSDoc style guide to JavaScript style guide

    • include annotations

      // Strict equality:
// returns 3.141592653589793

// Approximate equality (use roundn(x) and then strict equal):
// returns ~3.14

// Deep equal:
// returns {'a':[1,2,3]}

// Deep equal (mutation):
// x => [ 1, 2, 3, 4, 5 ]

// Deep equal:
/* returns
     {
       "a": [1,2,3],
       "b": {"beep":"boop"}
     }
*/

// Deep approximately equal:
/* returns
     {
       "a": [~1,~2,~3],
       "b": {"beep":"boop"}
     }
*/

// Wild card continuation:
/* returns
      [
        "beep",
        "boop",
        ...
      ]
*/

// Deep equal (matrices):
/* returns
     x[':'] = [ 0 0
                0 0 ]
*/

// Deep approximately equal (matrices):
/* returns
     mat[':'] = [ ~3.1.    0
                      0   ~3.1.  ]
*/

// Wildcard (matrices):
/* returns
     A[':'] = [...]
*/

// Deep equal (ndarrays):
/* returns
     x[':,:,0'] = [ 0 0
                    0 0 ]

     x[':,0,:'] = [ 0 0
                    0 0 ]

     x['0,:,:'] = [ 0 0
                    0 0 ]
*/

// Type equality:
// returns <boolean>

// Type equality:
// returns <string[]>

// Type equality (instanceof):
// returns <RegExp>

// Type equality (instanceof):
// returns <RangeError>

// Type equality instanceof):
// returns <Foo>

// Type equality + deep equal:
// returns <Float64Array>[ 1, 2, 3 ]

// Wildcard (string):
// returns '...'

// Wildcard (array):
// returns [1,...,10]

// Wildcard (object):
// returns { "a": ... }

// Options:
// returns true || false

// Options:
// returns <Error> || null

// Formatted (string) (?):
// returns => printf('%f', ?)

// Wildcard:
// returns ...

// Throws:
// throws <TypeError>

// Output to terminal:
// beep

// Output to terminal:
// ...

// Output to terminal:
// {"beep":"boop"}

// Output to terminal:
// <boolean>

// Insert figure:
// +> <figure data=?>

// Insert figure:
// +> plot(x, y)

      var fs = require( 'fs' );
fs.readFile( '/path/to/beep.js', onRead );
function onRead( error, data ) {
    if ( error ) {
        throw error;
    }
    console.log( data.toString() );
    // => '...'
}
      $ node ./bin/cli
...
...
      $ node ./bin/cli
e.g., 2016-05-24 08:42.34 Beep boop blah blah.

    • examples of modules, functions, constants, regexps, etc.

    • need a convention for client-side and server-side only examples

    • could use @browseronly and @nodejsonly special annotations, akin to @private and @public

  71. electron ui for creating a stdlib bundle (could support rollup, webpack, browserify)

  72. for browser REPL, use a virtual filesystem

  73. Add Markdown style guide, including notes about comment annotations, equations, etc.

  74. Add note about ES2015 features in JS style guide

    • Backward compatibility is important
    • Only use if can polyfill
    • Must provide a polyfill
    • No compile steps

  75. Function matrix across different environments (equivalents)

    • matlab
    • python
    • julia
    • go
    • r

  76. mkdirp

  77. C/C++ linting

    • cpplint: tied to Google Style Guide

  78. Julia linting

    • lint.jl: no apparent CLI (and very slow :|)

  79. doc viewer

    • modified SimpleHTTPServer which serves READMEs converted to HTML
    • for equations, instead of SVG, use MathJax
    • could also insert live figures (main, as margin notes)
    • an extension would be to make the code samples interactive
    • gateway to running benchmarks, tests, and examples in-browser
    • how would we annotate for reactive documents? inline comments? spans?
    • how would we annotate asides/notes? maybe not necessary for standard module READMEs. Possibly via spans.

  80. remark-insert-svg-figure plugin

    • requires codifying a comment markup syntax, which can take inspiration from how equations are documented in Markdown

  81. make init target

    • can setup makie
    • if have make list-cli-modules, can use npm link to install cli utils
    • setup git hooks
    • install deps
    • run tests, test-coverage, benchmarks, lint, etc

  82. add a run.sh (build.sh ?) file in test/fixtures, which would provide a common entry point for running test fixture runners. Currently, need to know the lang to run. And while the name is the same runner.*, the procedure for running the scripts is not. A common entry point would abstract away the differences.

    • Delegating to a script would mean that each script would assume aliases (e.g., use Rscript to run R code, etc), but could vary depending on the author/host system. In this case, centralization (e.g., having this knowledge in make would make more sense).

  83. JS style guide

    • declare functions using function declarations; also include another note about anon functions
    • use strict section should add notes re: node vs browser
    • use self section should include note about dynamic scoping of this variable
    • status code example has a bug (send should be status)
    • examples should use native built-ins, rather than implicitly rely on modules such as request and express
    • comments: "compared to multi-line"
    • all style guide code should be runnable
    • add note about module order (external before internal, etc)
    • add note about not using /** unless JSDoc
    • add note that module description should propose action (e.g., "Test ..."), while function descriptions should be in active tense (e.g., "Tests ...")
    • add note about file naming conventions (no uppercase, use of snake-case) => need to put in separate style-guide, as not JS specific
    • see #79
    • add rule to JavaScript style guide about not using built-in functions, especially math functions, linking to various accuracy issues and highlighting that browsers often sacrifice accuracy for speed
    • add rules about not using Number, String, and Boolean constructors
    • add rule about using source URL directives in eval'd code
    • add rule about including decimals when working with numbers; e.g., 3.0
    • principal of least abstraction => part of "The Stdlib Way" (inspired by The Unix Way)
    • add note about if(){return;}else{return;} being unnecessary indentation

  84. README link to "live" (e.g., gh-pages) docs (badge)

    • may also apply in reverse, going from "live" to source

  85. check that JSDoc annotations include @throws

  86. need a convention for defining README examples which are for illustration purposes only and not meant to be run

    • e.g., an example which is path dependent and cannot be known ahead of time, as it depends on user environment, etc.

  87. add __stdlib__ field to package.json

    • allowing setting whether a module is browser-only, nodejs-only, etc and whether a module is suitable for a REPL context, etc.

  88. proposal: add @sync and @async JSDoc annotations to document synchronous and asynchronous functions, respectively

  89. investigate bpkg as a package manager for bash scripts

    • could be useful for test runners, etc.

  90. investigate starscope

  91. profiling

  92. analyzing the dependency network => should be able to perform a similar analysis internally

  93. sine browser example

    • could do something similar for other trigonometric functions

  94. stability badges

    • may be good to have stability badges for methods / modules in order to indicate if a particular API is experimental, stable, locked, or otherwise
    • package.json field => "stdlib":{"stability":"experimental"}

  95. makie (and make) target to initialize a module (copy files from snippets to a destination directory)

  96. use signed commits

  97. string similarity measures?

  98. more datasets => some are not that interesting; others possibly

  99. write own deep-equal algo

    • when complete, replace any use of chai for testing

  100. evaluate bithound

  101. utils/copy

    • should preventExtensions, seal, and freeze be extended to objects beyond Object, Array, and class instances?
    • WeakMap support (?) => not convinced this is viable due to weakly held references; i.e., getting a list of keys requires maintaining a separate list.
    • WeakSet support (?) => see WeakMap above
    • Symbol support => requires the ability to get primitive value
    • structured-clone-algorithm
    • ArrayBuffer support
    • Blob support
    • FileList support
    • ImageData support
    • ImageBitmap support
    • File support

  102. research pull-streams

  103. see makefile for the frontend for possible inspiration for frontend tasks

  104. should float64-signbit return a boolean (like Julia) or a 1 or 0?

  105. licenses utilities

  106. investigate test-all-versions

  107. node-cpp

  108. rr: record and replay framework

  109. Investigate the concept of markembed for embedding content in Markdown files

  110. Use cases for remark plugins:

    • reference management
    • conversion to RST
    • conversion to HTML
    • figure (static) insertion (similar to equations)
    • appending/removing sections en masse

  111. tangle

  112. GitHub issues as a blog

  113. sync-request => useful for REPL

  114. include a creditcard validation module?

  115. adventures / workshoppers

  116. build script which reruns the latest commit on develop each day => helps ensure, even in the absence of fresh commits, that we are testing the environment, etc. Would need to be a cron job triggered from a remotely hosted service. (note: this means that the master branch should never run the dep check to ensure up-to-date dependencies; otherwise, master could fail for non-test related reasons)

    • for dep check, build script which acts similar to greenkeeper => creates/updates branch, if check deps fails, auto-installs, runs full build (tests, examples, etc), and checks if fails.

  117. plot svg components should have factory methods

  118. investigate nfty for sending desktop notifications for long-running commands (e.g., Makefile recipes => would need to check if CI environment)

  119. Annotations overlay,

    • x values with text

  120. Evaluate check-build

  121. Evaluate rewind

  122. iterables

  123. vmd

  124. function-plot

  125. see webtorrent-desktop for electron inspiration

  126. 30-day challenge => should be able to do sthg akin using stdlib

  127. svg components: move methods/render.js to render/index.js

  128. sparkline rug plot

  129. review stem and leaf unicode plot

  130. add unicode sparklines to namespace => requires abstract interface

  131. refactor plot electron renderer

  132. ability to "plot" tables?

  133. heatmap

  134. Should plot autoRender be "opt-in", rather than "opt-out"?

  135. remarkjs for Markdown slide shows for workshop slides?

  136. Visual intro to machine learning

  137. Refactor make workshops recipes

  138. mbtaviz and Github org

  139. create separate discrete and continuous distribution namespaces (at same level as general dist namespace)

  140. Investigate hyperterm

  141. For AI inspiration, see here and here

  142. trymodule

  143. testron

  144. cssstats

  145. math-input and mathquill

  146. For Nightingale's rose dataset, generate an SVG figure with code, rather than use a static image

  147. bats: bash automated testing; could also be useful for testing CLI scripts or urchin: shell tests

  148. investigate using now for deploying demos requiring a Node.js server

  149. Google trends data => note, this needs to be under an appropriate license before being used (currently unlicensed)

  150. investigate iron-node

  151. Sieve of Eratosthenes

  152. See casual for dataset inspiration

  153. GitHub issues Gantt diagrams

  154. gh-board - kaban board using GitHub issues

  155. investigate docstrings: useful or not?

  156. For running electron tests, see atom-test-runner

  157. Add dev guide for developing on windows

  158. add a Makefile (and makie) recipe to show disk usage for a given directory

  159. see ava.js for supporting docs (e.g., github templates, build scripts, etc) inspiration

  160. create a bot which tails NPM for math related modules

  161. bot which tails RSS feeds of select math repos and each day retrieves

    • number of stars/watchers
    • number of issues (total, open, closed)
    • number of commits
    • number of contributors

  162. investigate pkgfiles as a dev tool to determine which files will be published to npm

  163. investigate slow-deps as a dev tool to analyze dependency install times

  164. consider including governance docs

  165. investigate jailed for running JS code in sandbox (and also vm2)

  166. Non-node platform detection?

  167. may be worth investigating klipse for live code editing

  168. See if anything good from here

  169. disk drive data

  170. ability to create a gist from the repl

    • part of tools
    • auto browserify scripts? Or create package.json which installs individual pkgs

  171. process as a stdlib util (or some other namespaced) module (or maybe, like cwd, the individual props as mods)

  172. Add tool to detect whether a function can be optimized => note that this is Node.js/V8 specific

  173. GNU parallel for distributed tasks

  174. stdout-stream

  175. investigate vm2 for sandboxing

  176. For master, develop, and PRs into master and develop, run full build sequence; for all other branches, is it necessary to run full sequence or just, say, tests? or maybe for other branches, only run tests, examples, benchmarks for files which changed (similar to git push hook)?

  177. Linter for dirnames (akin to filenames)?

  178. convert filename linter to use plugin architecture?

  179. generate random strings based on a regular expression

  180. timed tape tests...useful?

    • once tape is brought in-house, could make part of the lib

  181. match-case

  182. Consider setting up jenkins for CI (notably Windows)

  183. investigate mancy

  184. semver regex

  185. Could this tutorial (and associated tutorials) be made interactive?

  186. fuzzy search

  187. Image datasets

  188. dependencyci

  189. Consider replacing testling with tape-run

  190. ccount but generalized to array-like objects

  191. tree

  192. print-object-as-tree utility

  193. Consider something like credits

  194. NLP data (note: ambiguous licensing)

  195. Fix SOTU raw text where \&mash; was converted to a single hyphen -

  196. ASTExplorer

  197. Consider using shrinkpack to create reproducible, more reliable, and faster builds in CI environments

  198. pkg which can generate an Anscombe dataset

    • simulator

  199. authors-certificate

  200. Electoral college box scores

  201. Electoral college votes by state

  202. datapackage.json schemas

  203. Does is-typed-array need to address symbol toStringTag? Ditto for which-typed-array?

    • yes

  204. single-line-stream

  205. snippet-stream

  206. gcc-explorer

  207. password datasets 1 and 2

  208. is-utf8, is-valid-utf8, strip-bom-buf, strip-bom-stream, has-bom

  209. read-glob

  210. bring minimist in-house

  211. bring JSON.parse in-house to provide better error messages. Can default to native and, on error, re-parse with userland implementation to provide more extensive error messaging.

  212. see static-eval

  213. farmers market geo data

  214. perf improvements for dirname and extname.

  215. A constrained RegExp implementation?

  216. noderify and depject -> static linking for JavaScript

  217. fs-walk (see also os.walk); fs-walk-folder-tree; module-walker

  218. readdirp, mkdirp, rmdirp, etc.

  219. dependency docs (static site; use simple server)

  220. make recipe to read a dep readme and launch in an electron window/browser

  221. nlp levi dist (see also damlev and leven)

  222. travis-deploy-example

  223. reserved words and reserved words and keywords

  224. a branch (based on master) which every month is run against every single Node version since 0.10.0 (may want a separate Jenkins server for this)

  225. Given an import-require tree, should be able to statically detect cyclic deps and flag

  226. pkg keyword force/network diagram where edges are pkgs and nodes are keywords

  227. Anything worthwhile?

  228. working remotely adapted for project communication

  229. node-help: repl docs

  230. RFCs docs

  231. envify => when browserifying environment dependent tests to be run in the browser, can use to inline env vars

  232. naming conventions

  233. typed array binary string

  234. JS interpreter and hotswapping interpreter

  235. chunkify, buffer, split, splitVec

  236. should http/s-server support graceful shutdown? If so, should update some of the tests which had to manually close connections

  237. parseBibTeX

  238. more images: good photos of cats, interesting features for training models, etc

  239. git stats

  240. link checking

  241. lru and node-lru

  242. commitizen: in place of git commit

  243. mem

  244. once

  245. json-depth-stream

  246. is-iso-8601 (see here)

  247. Generate a diff before publishing to npm

  248. loc per language over time (requires investigating repo at each commit; git log, extract commit hash, checkout each hash, run script, move to next hash, etc) => use Node to manage async

  249. classifying commits based on commit message keywords

  250. Determine a means to distinguish source code, comments, and empty lines when computing SLOC

  251. AWK hist fcn

  252. colormap

  253. bring tape in-house

  254. lint bib for duplicate ids. If identified, need to search for all references using duplicate ids and disambiguate/update

    • tool to allow searching for author name and return list of refs with identifier so an author can easily find an identifier without needing to search the raw bib file.
    • requires bib parser

  255. power-divergence and other associated tests

  256. for each push, run an analysis to determine if any SLOC changed. If only comments and/or docs, don't run unit tests.

    • may still want to run linting of docs and, e.g., JSDoc comments

  257. batch generation of exponential RVs?

  258. lowercase, no-case, param-case

  259. life expectancy by country

  260. robust arithmetic?

  261. stable JSON stringify

  262. fuzzyset

  263. async-memoize

  264. Sieve of Erastothenes, stack overflow, Sieve of Atkin, Sieve of Sundaram

  265. prime decomposition

  266. fast algos, fastpow, CORDIC, trig, math-prims, ACML, l2approx, fast approx, fast and accurate sine and cosine, rosetta commons, jmonkeyengine, fmath, fastermath, SkipCTS, see also Julia fastmath

  267. mobius-function

  268. phi function

  269. chart-csv

  270. Consider more specialized folders for base/special packages (see MATLAB's functionlist)

  271. geometric brownian motion

  272. allong.es and ramda for functional inspiration

  273. as part of the repo dashboard, a plot of build volatility per branch (pull data from various CI)

  274. deep-freeze

  275. to-source

  276. data structures

  277. during decomposition, each pkg has own gh-pages branch and each README HTML should have a tree menu linking to other pkg repo docs. Requires tree menu tool to support a tree having links, rather than inferring from dirs.

  278. inspect-code and vm2 and browser-module-sandbox

  279. compute bus factor over time

  280. compute degree-of-authorship

  281. Integrate IRHydra as part of dev toolset

  282. Jaccard similarity for git commits

  283. ulp, ulp, ulp, ulp, float-distance

  284. PRNG test to check for bit correlation

  285. styledoc for documenting CSS

  286. chakra node build

  287. See float-hacks for possible "fast" and/or approximate math algos

  288. treemap to visualize source

  289. configuration store

  290. binary-extract

  291. test images

  292. is-online

  293. Compute the half-life of code (months) (see Julia) => interesting extension would be per author

  294. evaluate fastapprox (see also node bindings)

  295. See gitql and textql

  296. Another way of determining number of pkgs/tools over time is to clone repo, checkout each commit, and run analysis

  297. use git blame to determine loc per auth per pkg

  298. fast inverse square root

  299. approx cbrt and fast cbrt

  300. crypto non-crypto hash function djb2 and here (may also be interesting to implement others)

  301. Investigate vintage-streams

  302. regular expression generation

  303. ability to search for issues from CLI for deps/pkgs

  304. WYSIWYG Markdown editor for internal rendered Markdown files

    • different rendering modes (GitHub, www, etc)
    • save to disk
    • load from pkg dir
    • communicate over socket (some tasks may be capable of being done entirely client side)
    • live linting (md, code blocks)
    • eqn rendering
    • fig gen
    • live code blocks
    • see dillinger (joe mccann)
    • markdown to JSDoc comment (e.g., for writing up math implementation details in source code)

  305. Similar concept once ndarrays?

  306. See quantifiedcode (software map)

  307. US/UK spelling variations

  308. RNN demo, demo, tutorial

  309. ESLint plugin for browser compat

  310. jot

  311. cars dataset

  312. plain-text-data-to-json

  313. package-use

  314. contributor graphs

  315. investigate threads

  316. glmatrix

  317. nat lang date/time parser

  318. Consider adding Dockerfile(s) (repl, workshop, etc)

    • applies mainly to server based applications

  319. itermplot

  320. diacritics-map

  321. problematic strings

  322. xstream

  323. fivethirtyeight data

  324. Blog/tutorial inspiration using gov't data

  325. consider using Stryker for mutation testing

  326. syncsplit and syncthrough

  327. iterative solvers

  328. should blas.dasum use pairwise summation?

  329. array-lru

  330. Fortran style guide

  331. oec data

  332. bring Buffer polyfill in-house (will either need to include Object polyfill or be paired with a typed array polyfill to support older environments)

  333. consider prebuildify and node-gyp-build

  334. determine feature detection strategy (i.e., when do we rely on an existing (optimized) BLAS implementation? when do we compile ourselves?)

  335. determine strategy for using existing optimized BLAS

  336. Issue rank dashboard

  337. Use of now to create a microservice api

  338. WASM at autodesk

  339. nlp-corpus

  340. data structures

  341. command exists

  342. fmt-obj

  343. pretty-format

  344. memo

  345. REPL chat bot (could, e.g., use AWS lambda)

    • similar to ? or help, could have a chat prefix
    • or could enter chat mode; to exit, user must type keyword (e.g., "bye", "ttyl", etc)
    • translate NL queries to doc searches (e.g., how do I plot in the terminal? how do I set the x-axis label?)
    • could rely entirely on local code, but using sthg like AWS would allow collecting usage statistics (e.g., what types are queries are most common, etc)

  346. integrate collection of REPL usage statistics (opt-in)

    • provide disclaimer regarding metrics collected, etc
    • point to source code so people can inspect themselves

  347. kill processes

  348. open datasets

  349. ML in other languages

  350. Seeing theory

  351. random string

  352. Stanford JS crypto

  353. spatial index

  354. named-regexp

  355. load-test

  356. 100 exercises

  357. prngs and clustering algorithms

  358. zlib: both JS and native add-on

  359. is-gzip

  360. punycode

  361. an interactive version

  362. in-house prez framework

  363. investigate pkg for creating a single binary executable

  364. a built-in terminal-to-gif recorder

  365. headless screenshots

  366. Generating random integers

  367. Add a destroy method to http/s servers

  368. Browser workshop framework (similar to Google Codelabs)

Immediate

  1. simple server

  2. ndarray

  3. terminal sparklines

    • toJSON => needs chart spec
    • colors
    • ansi-256-colors
    • would require escaping to work in the browser
    • ansi_up
    • ansi-to-html
    • but could also detect env and use ansi escape when in terminal mode and use HTML elsewhere (?) => no, too brittle.
    • maybe this should just be a user concern
    • support ndarrays
    • dimension, only 1d?

  4. basic stream utilities

  5. kmeans/dbscan

  6. blas routines

  7. all built-in Math methods

  8. kde

  9. hist

  10. csv/tsv/dsv

Plot

  1. plot cli (requires split)

  2. rects

    • x
    • y
    • orientation: vert, horz
    • width calc'd via x[i+1]-x[i]

  3. xAxis, yAxis -> true/false; whether to create or not

  4. xExtendedTicks?

  5. validation; instead of a sep validator folder, when providing an object, just set the props to validate; also allows moving etc files to prop folders

  6. line -> area

  7. readme

  8. svg components: move methods/render.js to render/index.js

  9. refactor plot electron renderer

  10. Should plot autoRender be "opt-in", rather than "opt-out"?

  11. plot svg components should have factory methods

  12. provided index to isDefined

  13. setting properties should only trigger a change event when the desired value is different from the existing value

  14. Sort properties/options in alphabetical order

  15. Add intro description to each component (e.g., annotations, defs, ...) stating purpose and use case

Tutorials

  1. Image Completion using Neural Networks

Pub

  1. decomposable software
  2. multiple build systems
  3. broken math
  4. backward compatibility (and countertrends)
  5. The REPL (why matters)
  6. mining git repos
  7. open open source reporting
  8. what can be done at standards level to better facilitate math

Modules

  1. incrspace

  2. linspace, logspace, incrspace as generators (?)

    • should support option to return data of a specified type; e.g., float32, etc.
    • returned value should be compliant with abstract-ndarray

  3. remainder (see c) and rem

  4. equivalents to various low-level Julia funcs

  5. blas routines

  6. fmod

  7. remquo

  8. svg2png without promises and cleaner

  9. is-class

  10. ilogb and logb, although these may just be float64-exponent

  11. stream module (e.g., flow-split, flow-join, flow-mean) => /utils /math etc

  12. hdbscan

  13. number theory fcns (see starred repo)

  14. str manip utils

  15. Avogadro's number

  16. Add credit card fraud data

  17. testing for

    • sin
    • ln
    • exp
    • sqrt
    • tan

  18. fibo

    • lookup

  19. scalbn

  20. int32-to-uint32

  21. fast pow

    • may need to research
    • integer variant from V8

  22. fma

  23. to-number

  24. feature detection utils

  25. port https-server

  26. pipe viewer

  27. downloads-folder along with tmpdir, homedir, etc

  28. next-tick

  29. linux utility equivalents

    • cat, mv, rm, ls, touch, etc.
    • allow for swapping out when using browser virtual filesystem, allowing isomorphic apps (although, filesystem data would prob not be copied to browser)

  30. file-type

    • break into separate mods is-pdf-file, etc.

  31. move is-uri main regex to separate module? Would allow for capturing parts of the scheme. Needs evaluating.

  32. kmeans as an EventEmitter

  33. bring debug in-house; see also diagnostics

  34. colorscales

  35. datasets

  36. utility to convert R DESCRIPTION files to JSON => would streamline getting test fixture R dependencies

  37. accumulators

  38. discretize

  39. gmm

  40. incrmkurtosis (windowed)

  41. incrmskewness (windowed)

  42. buffer-indexof and buffer-split => see issues

  43. base math swap (assume array-like) and generics swap (check for array-like)

  44. online stats

  45. hex to ascii

  46. arc4 cipher as a stream

  47. float64-to-hex

  48. object inspector; also, Node.js utils.inspect

  49. object diffing

  50. random/uuid; various versions

  51. custom error classes

  52. S&P 500 dataset

  53. sort methods, both numeric and general

  54. is-callable

  55. bithacks and twiddle and awesome

  56. download

  57. md5

  58. murmurhash

  59. deque and denque

  60. date fcns and zeitgeist

  61. ulid

  62. titlecase

Other

  1. units

  2. Interesting mod => potrace

References

Ideas

  1. when testing numeric code, would be interesting to test against multiple platforms (ala test fixtures); e.g., Julia, Python, R, Go, Boost, etc.

    • ability to run against multiple versions of alternative platforms
    • compare results for each alternative platform version
    • would allow flagging regressions or improvements in the implementations of other platforms
    • would be part of a comprehensive CI before publishing
    • suppose could also be done at the individual module level during separation
    • generate plots showing results across all platforms

  2. a tool which reports which paths are not imported by a file

    • use case is ensuring that modules which should be exported by an aggregate file are exported

  3. for JSDoc docs, ability to run benchmarks for any given method

    • UI button to run benchmark
    • per method/module/etc (similar to having a button to view source)
    • would allow users to test the relatively speed of pathways within a function; e.g., for erf, how fast do particular input values compare to other input values?
    • note: naive benchmarks would only provide a single value => erf(10); but this approach is flawed. Need to cover a range of values; otherwise, you could be testing a special case!
    • would allow another avenue for crowdsourcing benchmarks

  4. if every module wrapped as a stream, then, via linking, terminal becomes a REPL

    • ability to invoke with arg

      $ erf 5
<number>
$ erf 5 1.  13 1
<number>\n<number>\n... (could have option to specify delimiter)

    • ability to pipe

      $ cat x.txt | erf
...

    • may want to prefix with stdlib-<fcn> to avoid conflicts with built-ins

    • tools script could crawl the project and auto create aliases and links

  5. for modules like generic stats functions which may accept a variety of inputs requiring tailored implementations, instead of dynamic code generation, another possibility is to dynamically compile static code and write to disk

    • would allow static analysis
    • easier debugging, as can set breakpoints, etc. => some inspectors support using a pragma to allow debugging eval'd code, thus debugging is possible as is; nevertheless, visual inspection is easier if non-compiled
    • would allow for the use of JSDoc annotations, not possible when using dynamic code generation => can, but akin to documenting a "virtual" function
    • would lead, however, to a much larger codebase
    • in make init, could configure to "watch" and dynamically recompile generated files
    • to discover and identify compile targets, could add a "stdlib" field to a module's package.json with a configuration setting relevant to the type of compilation to perform (could lead to a proliferation of tailored settings, which is not necessarily a good thing)

Automation

tools

Will need a tools directory in individual repositories to

  • house Makefile dependencies

  • include CI scripts

  • house doc tools

    • JSDoc templates
    • JSDoc typedefs

package.json

  1. Populate individual module contributors automatically by extracting author info from git commits?

    • main author could be populated based on highest number of commits? most changes? responsible for most lines of code?
    • most lines of code may be best heuristic as likely that the author is thus most knowledgeable/owns the most code
    • over time the main author could change...is this a problem? => prob not, as the new author should be most familiar with the relevant code

  2. populate scripts similarly for all modules

  3. augment keywords with universal project keywords

  4. can add testling config, if needed

  5. populate git urls based on destination repo

  6. should be able to scan module code to determine dev and main deps and add them to the package.json based on what is installed in the main repo

  7. can updating the version be automated?

LICENSE

  1. Read license field in package.json and generate the appropriate license

Notes

  1. Ideal vs reality

    • @stdmath/base/special/erf
    • @stdmath/base-special-erf
    • @stdmath/generics/special/erf
    • @stdmath/generics-special-erf

  2. Under the @stdlib scope...

    • @stdlib/math-base-special-erf
    • @stdlib/math-base-core-float64-to-binary-string

  3. References on root global