Skip to content

TODO.md

Latest commit

 

History

History
2105 lines (1388 loc) · 90.2 KB

TODO.md

File metadata and controls

2105 lines (1388 loc) · 90.2 KB

TODO

  1. switch to eslint as main JS linter

    • add to CI
    • support reformatting ala go fmt => --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?

    • object-keys
    • typed-array
    • ...

  7. how to handle modules with CLIs?

    • will want some sort of CLI test framework to test stdin, stdout, args, etc.

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

    • e.g., fs functions like fs/exists, or cwd

  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. lint filenames

  14. consider changing isNumber to isNumeric

  15. prngs

  16. 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

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

    • a separate function?

  18. replace require statements of external compute modules

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

  20. deploy plato complexity report to gh-pages

    • similar to JSDoc source docs

  21. clean-up cpp test runners

    • powm1
    • riemann-zeta

  22. type-of should check for toStringTag support

  23. update utils/tools

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

  25. 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)

  26. investigate textlint

  27. 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

  28. 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.

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

  30. move test fixture runners into sub-directories based on language

    • e.g., ./fixtures/julia/*

  31. add Saucelabs with zuul (?)

  32. gh-pages

  33. may be useful: browser-repl

  34. 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

  35. jsdoc HTML template

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

  36. tailor Mathjax config

  37. 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
    • will want canonical way to reference project modules, which may be tricky, as modules may move, etc; this is important for automating "see also" type sections
    • otherwise, leave the existing ref as is
    • as part of this, should be able to lint (although remark does this already)
    • 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

  38. consider standard-version

  39. add to contribution guidelines

  40. 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

  41. investigate nbind

    • could be useful for, say, Boost bindings

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

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

  43. make Travis and Appveyor build badges the same dimensions

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

  44. consider using svgo to minimize eqn svgs

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

  46. 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)

  47. add code climate badge

  48. consider using things like shellcheck for linting files other than JavaScript

  49. 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

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

  51. 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

  52. 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

  53. README to man doc (see above)

  54. interactive JSON editor

  55. flatson

  56. REPL incremental json

  57. 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)

  58. consider adding a license prefix to each file

  59. intro how-tos

  60. evaluate using inch for src code documentation evaluation

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

  62. investigate xonsh

  63. 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.

  64. investigate async but awaitful

  65. list-required-modules 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

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

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

  67. 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

  68. doctest

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

  70. cross-platform open browser

  71. 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)

  72. 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

  73. bring glob in-house

  74. review CoC for more community oriented policies

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

  75. 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>

// 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:
// <error_message>

// 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() );
    // returns '...'
}
      $ 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

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

  77. for browser REPL, use a virtual filesystem

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

  79. Add note about ES201. features in JS style guide

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

  80. Function matrix across different environments (equivalents)

    • matlab
    • python
    • julia
    • go
    • r

  81. Add type specs to @stdlib/types/ folder

    • abstract-ndarray
    • abstract-complex
    • etc.

  82. Add git hooks to Makefile

  83. mkdirp

  84. C/C++ linting

    • cpplint: tied to Google Style Guide

  85. Julia linting

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

  86. 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.

  87. remark-insert-svg-equation plugin

  88. remark-insert-svg-figure plugin

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

  89. 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

  90. 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).

  91. 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

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

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

  93. check that JSDoc annotations include @throws

  94. include READMEs in namespace dirs

  95. 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.

  96. proposal: 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.

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

  98. investigate bpkg as a package manager for bash scripts

    • could be useful for test runners, etc.

  99. investigate starscope

  100. review

    • crypto
    • datasets (~bib)
    • fs
    • math/base/blas
    • math/base/dist
    • math/base/random
    • math/base/special
    • math/base/tools
    • math/base/utils
    • math/constants
    • math/statistics
    • math/utils
    • ml
    • namespace
    • net
    • plot
    • regexp
    • repl
    • streams (~)
    • string (~)
    • tools (~)
    • utils

  101. profiling

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

  103. sine browser example

    • could do something similar for other trigonometric functions

  104. 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"}

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

  106. use signed commits

  107. string similarity measures?

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

  109. write own deep-equal algo

    • when complete, replace any use of chai for testing

  110. evaluate bithound

  111. 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

  112. research pull-streams

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

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

  115. licenses utilities

  116. investigate test-all-versions

  117. node-cpp

  118. rr: record and replay framework

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

  120. Use cases for remark plugins:

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

  121. tangle

  122. GitHub issues as a blog

  123. sync-request => useful for REPL

  124. include a creditcard validation module?

  125. adventures / workshoppers

  126. 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.

  127. plot svg components should have factory methods

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

  129. Annotations overlay,

    • x values with text

  130. Evaluate check-build

  131. Evaluate rewind

  132. iterables

  133. vmd

  134. function-plot

  135. see webtorrent-desktop for electron inspiration

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

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

  138. sparkline rug plot

  139. review stem and leaf unicode plot

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

  141. refactor plot electron renderer

  142. ability to "plot" tables?

  143. heatmap

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

  145. remarkjs for Markdown slide shows for workshop slides?

  146. Visual intro to machine learning

  147. Refactor make workshops recipes

  148. mbtaviz and Github org

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

  150. Investigate hyperterm

  151. For AI inspiration, see here and here

  152. trymodule

  153. testron

  154. cssstats

  155. math-input and mathquill

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

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

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

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

  160. investigate iron-node

  161. Sieve of Eratosthenes

  162. files containing new Buffer should var Buffer = require( 'buffer' ).Buffer. Note that this will prob require overruling a lint rule against redefining globals.

  163. See casual for dataset inspiration

  164. GitHub issues Gantt diagrams

  165. gh-board - kaban board using GitHub issues

  166. investigate docstrings: useful or not?

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

  168. Add dev guide for developing on windows

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

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

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

  172. 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

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

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

  175. consider including governance docs

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

  177. Non-node platform detection?

  178. may be worth investigating klipse for live code editing

  179. See if anything good from here

  180. disk drive data

  181. ability to create a gist from the repl

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

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

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

  184. GNU parallel for distributed tasks

  185. stdout-stream

  186. investigate vm2 for sandboxing

  187. 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)?

  188. Linter for dirnames (akin to filenames)?

  189. convert filename linter to use plugin architecture?

  190. generate random strings based on a regular expression

  191. timed tape tests...useful?

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

  192. match-case

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

  194. investigate mancy

  195. semver regex

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

  197. fuzzy search

  198. Image datasets

  199. dependencyci

  200. Consider replacing testling with tape-run

  201. ccount but generalized to array-like objects

  202. tree

  203. print-object-as-tree utility

  204. Consider something like credits

  205. NLP data (note: ambiguous licensing)

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

  207. ASTExplorer

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

  209. pkg which can generate an Anscombe dataset

  210. authors-certificate

  211. FAQ: what is decomposable software?

  212. Electoral college box scores

  213. Electoral college votes by state

  214. datapackage.json schemas

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

    • yes

  216. single-line-stream

  217. snippet-stream

  218. gcc-explorer

  219. password datasets 1 and 2

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

  221. read-glob

  222. bring minimist in-house

  223. 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.

  224. see static-eval

  225. farmers market geo data

  226. perf improvements for dirname and extname.

  227. A constrained RegExp implementation?

  228. noderify and depject -> static linking for JavaScript

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

  230. readdirp, mkdirp, rmdirp, etc.

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

  232. mk recipe to read a dep readme and launch in an electron window/browser

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

  234. travis-deploy-example

  235. reserved words and reserved words and keywords

  236. 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)

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

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

  239. Anything worthwhile?

  240. working remotely adapted for project communication

  241. node-help: repl docs

  242. RFCs docs

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

  244. naming conventions

  245. Tyche prng

  246. typed array binary string

  247. JS interpreter and hotswapping interpreter

  248. chunkify, buffer, split, splitVec

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

  250. parseBibTeX

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

  252. git stats

  253. link checking

  254. lru and node-lru

  255. commitizen: in place of git commit

  256. mem

  257. once

  258. json-depth-stream

  259. is-iso-8601

  260. Generate a diff before publishing to npm

  261. 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

  262. classifying commits based on commit message keywords

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

  264. AWK hist fcn

  265. colormap

  266. bring tape in-house

  267. 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

  268. power-divergence and other associated tests

  269. 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

  270. batch generation of exponential RVs?

  271. lowercase, no-case, param-case

  272. life expectancy by country

  273. robust arithmetic?

  274. stable JSON stringify

  275. fuzzyset

  276. async-memoize

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

  278. prime decomposition

  279. 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

  280. mobius-function

  281. phi function

  282. chart-csv

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

  284. geometric brownian motion

  285. allong.es and ramda for functional inspiration

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

  287. deep-freeze

  288. to-source

  289. data structures

  290. 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.

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

  292. compute bus factor over time

  293. compute degree-of-authorship

  294. Integrate IRHydra as part of dev toolset

  295. Jaccard similarity for git commits

  296. ulp, ulp, ulp, ulp, float-distance

  297. PRNG test to check for bit correlation

  298. styledoc for documenting CSS

  299. chakra node build

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

  301. treemap to visualize source

  302. configuration store

  303. binary-extract

  304. test images

  305. is-online

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

  307. evaluate fastapprox (see also node bindings)

  308. See gitql and textql

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

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

  311. fast inverse square root

  312. approx cbrt and fast cbrt

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

  314. Investigate vintage-streams

  315. regular expression generation

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

  317. 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)

  318. Similar concept once ndarrays?

  319. See quantifiedcode (software map)

  320. US/UK spelling variations

  321. RNN demo, demo, tutorial

  322. ESLint plugin for browser compat

  323. jot

  324. cars dataset

  325. plain-text-data-to-json

  326. package-use

  327. contributor graphs

  328. investigate threads

  329. glmatrix

  330. nat lang date/time parser

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

    • applies mainly to server based applications

  332. itermplot

  333. diacritics-map

  334. problematic strings

  335. xstream

  336. fivethirtyeight data

  337. Blog/tutorial inspiration using gov't data

  338. consider using Stryker for mutation testing

  339. syncsplit and syncthrough

  340. iterative solvers

  341. should blas.dasum use pairwise summation?

  342. array-lru

  343. Fortran style guide

  344. oec data

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

  346. consider prebuildify and node-gyp-build

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

  348. determine strategy for using existing optimized BLAS

  349. Issue rank dashboard

  350. Use of now to create a microservice api

  351. WASM at autodesk

  352. nlp-corpus

  353. data structures

  354. command exists

  355. fmt-obj

  356. pretty-format

  357. memo

  358. 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)

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

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

  360. kill processes

  361. open datasets

  362. ML in other languages

  363. Seeing theory

  364. random string

  365. Stanford JS crypto

  366. spatial index

  367. named-regexp

  368. load-test

  369. 100 exercises

  370. prngs and clustering algorithms

  371. zlib: both JS and native add-on

  372. is-gzip

  373. punycode

  374. an interactive version

  375. in-house prez framework

  376. investigate pkg for creating a single binary executable

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

  378. headless screenshots

  379. Generating random integers

  380. Add a destroy method to http/s servers

  381. Browser workshop framework (similar to Google Codelabs)

Immediate

  1. simple server

  2. abstract-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 (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. rem_pio2

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

  13. hdbscan

  14. number theory fcns (see starred repo)

  15. str manip utils

  16. Avogadro's number

  17. Add credit card fraud data

  18. testing for

    • sin
    • ln
    • exp
    • sqrt
    • tan

  19. fibo

    • lookup

  20. scalbn

  21. int32-to-uint32

  22. fast pow

    • may need to research
    • integer variant from V8

  23. fma

  24. to-number

  25. global var detection

  26. feature detection utils

  27. port https-server

  28. pipe viewer

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

  30. next-tick

  31. 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)

  32. file-type

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

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

  34. kmeans as an EventEmitter

  35. bring debug in-house; see also diagnostics

  36. colorscales

  37. datasets

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

  39. accumulators

  40. discretize

  41. gmm

  42. incrmkurtosis (windowed)

  43. incrmskewness (windowed)

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

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

  46. online stats

  47. hex to ascii

  48. arc4 cipher as a stream

  49. float64-to-hex

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

  51. object diffing

  52. random/uuid; various versions

  53. custom error classes

  54. S&P 500 dataset

  55. sort methods, both numeric and general

  56. is-symbol

  57. is-callable

  58. bithacks and twiddle and awesome

  59. download

  60. md5

  61. murmurhash

  62. deque and denque

  63. date fcns and zeitgeist

  64. ulid

  65. 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

Project Structure

Sample project structure.

|-stdlib |---lib |-----assert |-------is-array-like |-------is-function |-----datasets |-------anscombes-quartet |-----math |-------base |---------assert |-----------is-even |-----------is-integer |-----------is-number |-----------is-odd |---------blas |-----------scal |---------complex |-----------acos |-----------sin |---------dist |-----------norm |-------------cdf |-------------pdf |-----------poisson |---------random |-----------lcg |---------special |-----------erf |-----------erfc |-----------sin |---------tools |-----------evalpoly |-----------evalrational |---------utils |-----------float32-to-word |-----------float64-from-words |-----------float64-to-words |-------constants |---------e |---------pi |---------two-pi |-------fast |---------special |-----------cos |-----------sin |-------core |---------add |---------mult |---------subtract |---------sum |-------dist |---------normal |---------poisson |-------linalg |-------random |---------lcg |-------special |---------erf |---------erfc |-------statistics |---------mean |---------stdev |---------variance |-----namespace |-----regexp |-------eol |-------regexp |-----repl |-----streams |-------math |---------mean |---------stdev |-------utils |---------split |---------join |-----string |-------left-pad |-------pad |-------repeat |-------right-pad |-----tools |-----types |-------array |-------complex |-------dataframe |-------matrix |-------ndarray |-----utils |-------copy |-------deep-get |-------deep-set |-------merge |-------pluck