Skip to content

TODO.md

Latest commit

 

History

History
2123 lines (1354 loc) · 85.5 KB

TODO.md

File metadata and controls

2123 lines (1354 loc) · 85.5 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

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

    • 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

    • 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. should etc config files be placed in subdirectories?

    • would require updating Makefile targets

  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.14       0
                      0   ~3.14 ]
*/

// 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 ES2015 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. Python linting

  84. R linting

  85. Julia linting

  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.

  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/generics/statistics
    • math/generics/utils
    • math/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. benchmarking

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

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

  107. use signed commits

  108. string similarity measures?

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

  110. write own deep-equal algo

    • when complete, replace any use of chai for testing

  111. evaluate bithound

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

  113. research pull-streams

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

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

  116. licenses utilities

  117. investigate test-all-versions

  118. node-cpp

  119. rr: record and replay framework

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

  121. Use cases for remark plugins:

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

  122. tangle

  123. GitHub issues as a blog

  124. sync-request => useful for REPL

  125. include a creditcard validation module?

  126. adventures / workshoppers

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

  128. plot svg components should have factory methods

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

  130. Annotations overlay,

    • x values with text

  131. Evaluate check-build

  132. Evaluate rewind

  133. iterables

  134. vmd

  135. when browserifying @stdlib/plot should ignore electron!!!!

    • may want to have a separate view method entirely; one that is catered to browser context

  136. function-plot

  137. see webtorrent-desktop for electron inspiration

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

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

  140. sparkline rug plot

  141. review stem and leaf unicode plot

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

  143. refactor plot electron renderer

  144. ability to "plot" tables?

  145. heatmap

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

  147. remarkjs for Markdown slide shows for workshop slides?

  148. Visual intro to machine learning

  149. Refactor make workshops recipes

  150. mbtaviz and Github org

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

  152. Investigate hyperterm

  153. For AI inspiration, see here and here

  154. trymodule

  155. testron

  156. cssstats

  157. math-input and mathquill

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

  159. bats: bash automated testing; could also be useful for testing CLI scripts

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

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

  162. investigate iron-node

  163. Sieve of Eratosthenes

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

  165. See casual for dataset inspiration

  166. GitHub issues Gantt diagrams

  167. gh-board - kaban board using GitHub issues

  168. investigate docstrings: useful or not?

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

  170. Add dev guide for developing on windows

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

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

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

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

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

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

  177. consider including governance docs

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

  179. Non-node platform detection?

  180. may be worth investigating klipse for live code editing

  181. See if anything good from here

  182. disk drive data

  183. ability to create a gist from the repl

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

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

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

  186. GNU parallel for distributed tasks

  187. stdout-stream

  188. investigate vm2 for sandboxing

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

  190. Linter for dirnames (akin to filenames)?

  191. convert filename linter to use plugin architecture?

  192. generate random strings based on a regular expression

  193. timed tape tests...useful?

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

  194. match-case

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

  196. investigate mancy

  197. semver regex

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

  199. fuzzy search

  200. Image datasets

  201. dependencyci

  202. Consider replacing testling with tape-run

  203. ccount but generalized to array-like objects

  204. tree

  205. print-object-as-tree utility

  206. Consider something like credits

  207. NLP data (note: ambiguous licensing)

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

  209. ASTExplorer

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

  211. pkg which can generate an Anscombe quartet

  212. authors-certificate

  213. FAQ: what is decomposable software?

  214. Electoral college box scores

  215. Electoral college votes by state

  216. datapackage.json schemas

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

  218. single-line-stream

  219. snippet-stream

  220. gcc-explorer

  221. password datasets 1 and 2

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

  223. read-glob

  224. bring minimist in-house

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

  226. see static-eval

  227. farmers market geo data

  228. perf improvements for dirname and extname.

  229. A constrained RegExp implementation?

  230. noderify and depject -> static linking for JavaScript

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

  232. readdirp, mkdirp, rmdirp, etc.

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

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

  235. nlp levi dist (see also damlev)

  236. travis-deploy-example

  237. reserved words and reserved words and keywords

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

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

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

  241. Anything worthwhile?

  242. working remotely adapted for project communication

  243. node-help: repl docs

  244. RFCs docs

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

  246. naming conventions

  247. Tyche prng

  248. typed array binary string

  249. JS interpreter and hotswapping interpreter

  250. chunkify, buffer, split, splitVec

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

  252. parseBibTeX

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

  254. git stats

  255. link checking

  256. lru and node-lru

  257. commitizen: in place of git commit

  258. mem

  259. once

  260. json-depth-stream

  261. is-iso-8601

  262. Generate a diff before publishing to npm

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

  264. classifying commits based on commit message keywords

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

  266. AWK hist fcn

  267. colormap

  268. bring tape in-house

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

  270. power-divergence and other associated tests

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

  272. batch generation of exponential RVs?

  273. lowercase, no-case, param-case

  274. life expectancy by country

  275. robust arithmetic?

  276. stable JSON stringify

  277. fuzzyset

  278. async-memoize

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

  280. prime decomposition

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

  282. mobius-function

  283. phi function

  284. chart-csv

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

  286. geometric brownian motion

  287. allong.es and ramda for functional inspiration

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

  289. deep-freeze

  290. to-source

  291. data structures

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

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

  294. compute bus factor over time

  295. compute degree-of-authorship

  296. Integrate IRHydra as part of dev toolset

  297. Jaccard similarity for git commits

  298. ulp, ulp, ulp, ulp, float-distance

  299. PRNG test to check for bit correlation

  300. styledoc for documenting CSS

  301. explore wasm and native addon for a single pkg

  302. chakra node build

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

  304. treemap to visualize source

  305. configuration store

  306. binary-extract

  307. test images

  308. is-online

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

  310. evaluate fastapprox (see also node bindings)

  311. See gitql and textql

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

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

  314. fast inverse square root

  315. approx cbrt and fast cbrt

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

  317. Investigate vintage-streams

  318. regular expression generation

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

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

  321. Similar concept once ndarrays?

  322. See quantifiedcode (software map)

  323. US/UK spelling variations

  324. RNN demo, demo, tutorial

  325. ESLint plugin for browser compat

  326. jot

  327. cars dataset

  328. plain-text-data-to-json

  329. package-use

  330. contributor graphs

  331. investigate threads

  332. glmatrix

  333. nat lang date/time parser

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

  335. itermplot

  336. diacritics-map

  337. problematic strings

  338. xstream

  339. fivethirtyeight data

  340. Blog/tutorial inspiration using gov't data

  341. consider using Stryker for mutation testing

  342. syncsplit and syncthrough

  343. iterative solvers

  344. should blas.dasum use pairwise summation?

  345. array-lru

  346. Fortran style guide

  347. oec data

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

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

Tutorials

  1. Image Completion using Neural Networks

Workshops

Numeric Computing

  1. node-markov
  2. include links to survey in main README
  3. as a REPL exercise, simulation (randn, hist, plot normal pdf)

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. is-finite (generic)

    • may need to describe how different from built-in

  2. is-infinite (generic)

  3. is-nan (generic)

  4. is-even (generic)

  5. is-odd (generic)

  6. incrspace

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

  8. workshop Moby Dick corpus

  9. remainder (c) and rem

  10. equivalents to various low-level Julia funcs

  11. blas routines

  12. fmod

  13. remquo

  14. svg2png without promises and cleaner

  15. is-class

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

  17. rem_pio2

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

  19. hdbscan

  20. number theory fcns (see starred repo)

  21. str manip utils

  22. Avogadro's number

  23. round to number of sig figs

  24. testing for

    • sin
    • ln
    • exp
    • sqrt
    • tan

  25. fibo

    • lookup

  26. scalbn

  27. int32-to-uint32

  28. fast pow

    • may need to research
    • integer variant from V8

  29. fma

  30. to-number

  31. global var detection

  32. feature detection utils

  33. port https-server

  34. pipe viewer

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

  36. next-tick

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

  38. file-type

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

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

  40. kmeans as an EventEmitter

  41. bring debug in-house; see also diagnostics

  42. colorscales

  43. datasets

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

  45. accumulators

  46. discretize

  47. gmm

  48. incrmkurtosis (windowed)

  49. incrmskewness (windowed)

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

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

  52. online stats

  53. escape-regexp

  54. hex to ascii

  55. arc4 cipher as a stream

  56. float64-to-hex

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

  58. object diffing

  59. random/uuid; various versions

  60. custom error classes

  61. S&P 500 dataset

  62. sort methods, both numeric and general

  63. is-symbol

  64. is-callable

  65. bithacks and twiddle and awesome

  66. foreach, foreach, foreach

  67. md5

  68. murmurhash

  69. deque and denque

  70. date fcns and zeitgeist

  71. ulid

  72. titlecase

  73. download

  74. Add credit card fraud data

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 19 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 |-----datasets |-------anscombes-quartet |-----math |-------base |---------blas |-----------scal |---------complex |-----------acos |-----------sin |---------dist |-----------norm |-------------cdf |-------------pdf |-----------poisson |---------random |-----------lcg |---------special |-----------erf |-----------erfc |-----------sin |---------tools |-----------evalpoly |-----------evalrational |---------utils |-----------is-even |-----------is-integer |-----------is-number |-----------is-odd |-------constants |---------e |---------pi |---------two-pi |-------fastmath |---------special |-----------cos |-----------sin |-------generics |---------core |-----------add |-----------mult |-----------subtract |-----------sum |---------dist |-----------norm |-----------poisson |---------linalg |---------random |-----------lcg |---------special |-----------erf |-----------erfc |---------statistics |-----------mean |-----------stdev |-----------variance |-----namespace |-----regexp |-------eol |-------regexp |-----repl |-----streams |-------math |---------mean |---------stdev |-------utils |---------split |---------join |-----tools |-----types |-------array |-------complex |-------dataframe |-------matrix |-------ndarray |-----utils |-------copy |-------deep-get |-------deep-set |-------error-reviver |-------error-to-json |-------is-array-like |-------is-function |-------left-pad-string |-------merge |-------pad-string |-------pluck |-------repeat-string |-------right-pad-string