Fork Studio for kdb+.

• Charlie changed the license to Apache 2!
  
  • https://github.com/CharlesSkelton/studio
• Next steps?
  
  • Seems like it could be a separate project.
  • Owners?  Ci / CD integration?

• No one from FINOS on the call to discuss Studio for kdb+.
  • Revisit this next time.
• Someone contacted maintainer of q Insight Pad about open sourcing it.
  • Current thinking is that open source is a possibility, but not something as permissive as an MIT license.
  • Would still like to retain a measure of control over its direction and who might support it commercially.

JupyterQ / PyQ notebooks?

• Any interest in contributions for those?
• Since q doesn't have a proper "spawn" call, it's arguably safer to do HDB maintenance (copy / link / remove files) from Python.
• More robust examples of q / Python interop?
  • JupyterQ / embedPy examples of saving DataFrames to Pickle?
  • PyQ examples of loading serialized q into Python?

• The idea of using Python scripts for HDB maintenance was not popular.
• The preferred direction was:
  1. Use q builtins as extensively as possible (hdel, etc.)
  2. Lobby for a proper function that takes an argument vector.  (Possibly as a -n!x "internal" function.)
  3. Release a plugin that wraps fork(2) / execvpe(3).
• Best if members lobby Kx for #2 so that the entire community can benefit.

New ideas to increase contributions?

• Snippets gallery instead of fully-baked libraries?
• Just let Peter go all out? 

• Might be nice to get an example of kdb integration with Perspective, a JPMC contribution to FINOS:
  
  • https://perspective.finos.org/
• TorQ has a Grafana adapter
  • https://www.aquaq.co.uk/q/ask-shall-receive-grafana-kdb-adaptor/
  • https://github.com/grafana/grafana
  • Jonny will look into what might be involved with contributing that.
• Module loader is still highly desirable.
  • Support for search paths would be required given the way silos form in enterprises.