0. once stdlib is live (merged to master and published), make the default branch be develop

   • all PRs, etc, should be made against develop

1. replace jshint with eslint

   • add to test command
   • support reformatting ala go fmt
   • move eslint config files/modules to this repo (will need to do audit to ensure up-to-date)

2. add NPM style guide with versioning info

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

   • e.g., @stdlib/math/constants/float64-two-pi
   • replace internal module references

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

   • dox

   • mrdoc (aka doxx)

   • docco

   • jsdoc

   • documentation.js

     • see turf-www and turf

   • jsdoc-parse

   • dmd

   • jsdox

   • dokker

   • jsdoc-to-markdown

   • yuidoc

   • groc

   • jsduck

   • esdoc

   • docker.js

   • doctrine

   • doclets

   • mkdocs

   • docpress

   • getdocs

   • flow-jsdoc

   • catharsis

   • ...

10. debug eval sources

    • node-inspector
    • source maps

11. add CONTRIBUTING.md

12. determine strategy for generic validation fcns

13. lint filenames

    • eslint plugin

14. consider changing isNumber to isNumeric

15. prngs

    • pcg
    • sfmt
    • randamu
    • gsl
    • collection of lcgs
    • Lehmer LCG
    • lcgs
    • better rngs for JavaScript
    • d3-random
    • gauss-random
    • lcg-random
    • randy
    • randgen
    • random.js
    • seed-random
    • random-js
    • seedrandom
    • modulo bias
    • diehard tests
    • dieharder
    • RNGTest.jl
    • ziggurat
    • Matlab's randn
    • Gaussian random number generators
    • V8's previously poor implementation
    • xorshift+
    • chrome thread
    • thenextweb
    • hackaday
    • betable post
    • estimating pi
    • xorshift scratch
    • randint
    • rc4 encryption

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

    • 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 backwards 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

    • changelog-standard

39. add to contribution guidelines

    • bluebird
    • optimization killers
    • HTML5 Rocks
    • v8-perf
    • chrome devtools

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. *.cpp vs *.cc for C++ files?

    • 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

    • markdown linting

      • alex

      • retext-readability

      • retext-lint-code

        • uses eslint

    • js code in markdown linting

    • css linting and stylefmt

    • list of style guidelines

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

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

      • docs
      • ultra-repl
      • repl-start
      • node-repl
      • app-specific-repl
      • repl over tcp
      • repl using curl

    • ASCII charts

      • should be able to create an isomorphic API with browser charts
      • ability to open chart in browser
      • sparkly
      • jstrace/chart
      • bashplotlib
      • node-cli-graph
      • ASCIIPlots.jl
      • asciiplot
      • node-clear
      • ansi-escapes
      • node-charm
      • gvz

    • 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)

    • black-screen terminal emulator

53. README to man doc (see above)

    • cannot directly print a raw README, as will contain markup
    • will need to transform into plain text
    • writing manual pages
    • formatted man page
    • ubuntu
    • linux
    • man-n

54. utility which scans the project for package.json files and validates the file using a defined schema

    • can be used as part of a build step to ensure package.json files are properly formatted, valid, and have requisite information

55. flatson

56. refactor module CLIs to match CLI snippet

57. add the engines field to module package.json files

58. consider adding a license prefix to each file

    • julia
    • license-check

59. intro how-tos

    • gifs

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

    • jsdoctest
    • jsdoced.js
    • markdown-doctest
    • mocha-doctest
    • comment-to-assert
    • doctestjs
    • evalmd
    • readme-tester
    • jsmd

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

    • bpipe
    • bcat
    • hcat => could be inspiration for piping data to a chart
    • scat
    • browser-run
    • budo
    • simple-html-index
    • http-server
    • ecstatic
    • glance
    • wzrd
    • serve-static
    • st

70. cross-platform open browser

    • biased-opener
    • opener
    • browser-launcher
    • browser-launcher2
    • opn and opn-cli
    • node-open
    • open-url
    • broser

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'
      
      // 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. @stdlib/regexp/extname, */dirname export circular references; prob best to clone the regexp and bind to exported object

    • requires porting utils-copy

77. for browser REPL, use a virtual filesystem

    • fs and other filesystem methods should remain the same
    • difference is that files are not written to disk, but to, say, IndexedDB
    • would allow for an "isomorphic" REPL and the ability to run all tests and examples on both the server and client
    • filer
    • os.js
    • filesystem API
    • emscripten
    • idb.filesystem.js
    • filer.js
    • browserFS
    • browser-sync-stream

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

79. Add note about ES2015 features in JS style guide

    • Backwards 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

    • will prob want a way to undo setting of hooks (i.e., a reset)
    • intro to git hooks
    • git pre-push

83. Python linting

    • pylint
    • pycodestyle
    • pyflakes
    • prob combo of pylint and pycodestyle

84. R linting

    • lintr: no apparent CLI

85. Julia linting

    • lint.jl: no apparent CLI

86. doc viewer

    • modify SimpleHTTPServer to only serve 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)

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

     • v8-profiler
     • node-inspector
     • node-webkit-agent
     • node-stackvis
     • devtool (blog post)
     • --prof-process
     • v8-profiling
     • chrome://tracing/
     • v8 profiler docs
     • v8 perf
     • v8 performance profiling
     • node-tick
     • node-tick-processor
     • v8 profiling
     • make recipe
     • bring the V8 log processor in-house (tools, wiki, outfile, node-tick)

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

     • chuhai
     • benchmark.js
     • substack benchmark module
     • matcha

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

     • licensee.js
     • license-checker
     • .licenserc
     • licenserc.js
     • licensing
     • licenses
     • licensecheck
     • nlf
     • license-list
     • as part of public docs, can generate a list of deps and their licenses; can do the same for stdlib/lib/** modules, so that all licenses for the individual mods/deps can be viewed together
     • recipe to plot license distribution as a bar plot (?) => could be part of public facing docs

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

     • is-empty-array => should this just be a method off of isArray? => isArray.isEmptyArray?

125. include a creditcard validation module?

126. adventures / workshoppers

     • regex-adventure
     • workshopper-adventure
     • demo-workshopper
     • adventure
     • learnyounode
     • workshopper-exercise
     • stream-adventure
     • functional-javascript
     • p2p-workshop
     • webgl-workshop

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. constant function? similar to identity function but as a factory?

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?

     • markdown-to-slides
     • cleaver

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

179. Non-node platform detection?

180. may be worth investigating klipse for live code editing

181. update tools/scripts to latest remark-lint API for linting Markdown files

182. disk drive data

183. utils, e.g., is-string, need more rigorous testing, especially for things like isPrimitiveStringArray

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

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?

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

     • birds
     • tiny images

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 likes credits

207. NLP data (note: ambiguous licensing)

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

1. randn

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

   • make utils/debug a standard stream (cli name option; does this module need split and join?)
   • split => tests
   • join => example
   • map!!!!!!
   • cat
   • rand
   • from-array
   • duplex-json-stream
   • related => into-stream
   • concat-stream => this is essentially an end sink stream
   • pump (?)
   • end-of-stream
   • something akin to stream-combiner2
   • duplexer2
   • mississippi
   • to-console or maybe to-log (provide own logger, with default being console using util-inspect) => write stream which writes each chunk to console (either normal or object mode); if object mode, use util-inspect and allow setting of depth
   • debug as a transform stream => could provide name and then toggle debugging based on name!
   • tap-stream and inspect-stream; see also sculpt#tap
   • guide to node streams
   • vstream => instrumented streams
   • through2-concurrent
   • log
   • ndjson

5. kmeans/dbscan

6. blas routines

7. all built-in Math methods

8. kde

   • scipy
   • smith
   • kde in python
   • fast computation of kernel estimators
   • lecture
   • scikit-learn
   • wikipedia

9. hist

   • Matlab deprecates hist and histc
   • histogram
   • histcounts

10. csv/tsv/dsv

    • d3-dsv
    • node-csv
    • csv-parse
    • csv-spectrum
    • csv-parser
    • paratext
    • read-csv (file) vs from-csv (stream) vs parse-csv (string or buffer) => some overlap between these

11. simple server

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

1. Image Completion using Neural Networks

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

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

10. utils-pad-string

11. blas routines

12. is-plain-object (?)

13. is-object

14. svg2png without promises and cleaner

    • svgexport

16. utils-deep-get

17. utils-deep-set

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

    • see MFX
    • see Julia

24. testing for

    • sin
    • ln
    • exp
    • sqrt
    • tan

25. fibo

    • lookup

26. scalbn

    • cppreference
    • how would the FLOAT_RADIX be supplied?

27. int32-to-uint32

28. fast pow

    • may need to research

29. port upsearch to fs

    • requires is-* modules

31. global var detection

32. feature detection utils

33. port https-server

34. pipe viewer

    • node-pv
    • blog

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

36. next-tick

    • polyfill

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

42. colorscales

43. datasets

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

    • R docs
    • debian control files
    • debian-control-parser
    • readcontrol

45. accumulators

    • boost src
    • boost docs
    • handystats

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

    • double-hex
    • raw fields of float
    • binary scientific notation
    • converting floats
    • Python float.hex
    • hex floating-point constants

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

1. units

   • unit-parser
   • boost

2. Interesting mod => potrace

• Square root without division
• Reciproot Algorithm: correctly rounded?
• reciproot implementation
• glibc sqrt
• IPython: A System for Interactive Scientific Computing
• IPython: Sloan Grant
• Why not use core streams
• Why JAVA floating-point implementation is bad for everyone

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)

Will need a tools directory in individual repositories to

• house Makefile dependencies

• include CI scripts

• house doc tools

  • JSDoc templates
  • JSDoc typedefs

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

   • dependency-check

     • uses node-detective

   • node-detective

     • apparently relies on outdated mods, but may still work

   • node-source-walk

     • uses more recent acorn version

   • if a dependency is already included in the package.json, keep that dependency, thus allowing local override of a dependency

     • how will that work in terms of dep install within the context of the larger project?
     • module-deps

7. can updating the version be automated?

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

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

   • underscore
   • lodash
   • window.js
   • stackoverflow
   • insert-module-globals
   • TC39
   • symstem.global

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