jsa-aerial / saite Goto Github PK

The idea would be to have active code editors per visualization. These could directly change or even completely redo the associated visualization. Should not restrict to any given frame area, i.e., could be placed in top, bottom, left, and/or right. As indicated, could have more than one.

This would go a long way toward making Saite a full fledged notebook, with chapters (tabs), interactive code, literate programming, etc.

Should be able to convert Clj specs given in the clj pane to equivalent JSON Vega/Vega-Lite specs. Need to support templates (including nested ones) in the Clj as well. This enables complete bi-directional conversion support.

Take a specification in a panel and render it so that what it specifies can be seen. Supports client side exploratory visualization. The rendering could be in a modal panel (window) which could have annotations enabling pushing to a tab.

Vim and Sublime can be used as editors and their base key bindings and behavior are available. However, key bindings, or other means as appropriate for these editors, for code evaluation (JS only, JVM only, and mixed), as well as code navigation (in particular, paredit capabilities) are not setup. This is mostly due to the fact that I do not know what is most appropriate for these editors for such capabilities. The actual functions for these capabilities, are available and should work just as well as for the emacs editor. See the std-key-maps for details on those. A PR to help with setting either of these up more completely would be most welcome!

Any picture frame element (area - top, bottom, left, right) of either empty frames or frames with visualizations, should be able to include LaTex in their content.

Would greatly enhance the notebook quality of Saite.

Save a static snapshot of DOM of a current Saite session. No active visualizations. Tabs and their data would turn into document 'headers' and bodies. So, the result is serialized content of tabs generated from left most tab to right most tab.

As a byproduct of this, all the plots/charts would also be independently saved as accessible pngs.

It is not clear that this all that useful, but various people seem to think it is.

Fortunately, as described in #1, being totally data centric in all presentation aspects makes this more straight forward than might first be thought.

Related to #8, maybe should even be merged into one. Why stop at just editor panes in frame elements? Why not just go all the way - fully realized editor panes, with full evaluation capabilities on full and partial code forms, with results presented in associated output areas in same frame (a different picture element - say editor in left element and output area in right element or top vs bottom) and with visualizations at center of these frames or better yet in other frames. So, code and output in an empty picture frame and vis in adjacent pictures. Or something like that....

Save a current 'live document' (Saite explore/work session) to file storage.

1. Save per session with a given file name. Sessions will be able to save multiple such named snapshots. All artifacts (including session name, tab layout, tab content, visualizations, annotations (picture frames), etc. should be saved so as to be reproducible in form, content and activity.

2. A saved document can be reloaded at any time to bring the session back to the content and actions at time of snapshot

3. Saved documents should be simple data, supporting simple sharing and exchange.

Since Saite is a Hanami application, and all presentation aspects of a Hanami application are specified completely in terms of data (including meta information such as how to render, annotations, layouts, etc), this is looking to be a reasonably straightforward data transformation exercise. The basic idea would be to keep a 'log' of current layouts in their fully realized data representation. So, no template transformations, etc would be needed to reload a document. Loading then would simply be 'replaying' the log of data messages to recreate the DOM at time of snapshot.

Might be nice to be able to interactively delete a tab(s), as opposed to reload to get rid of something you don't want.

This is likely low hanging fruit.

Might be nice to be able to reorder tabs interactively, instead of reloading with the new desired layout.

The code to do this is trivial. The issue is what visual gesture(s) should be used to effect the running of that code. There are a few options, would be nice if others had some opinions.

I'm trying to test this out on W10, and getting the following error after following the self install instructions on the stand-alone jar:

Enter installation directory [~/.saite]: ~/.saite
Exception in thread "main" java.lang.IllegalArgumentException: character to be escaped is missing
        at java.util.regex.Matcher.appendReplacement(Matcher.java:809)
        at java.util.regex.Matcher.replaceAll(Matcher.java:955)
        at clojure.string$replace.invokeStatic(string.clj:106)
        at clojure.string$replace.invoke(string.clj:75)
        at aerial.fs$replace_re.invoke(fs.clj:18)
        at aerial.fs$fullpath.invoke(fs.clj:40)
        at aerial.aerosaite.core$get_install_dir.invokeStatic(core.clj:84)
        at aerial.aerosaite.core$get_install_dir.invoke(core.clj:76)
        at aerial.aerosaite.core$_main.invokeStatic(core.clj:197)
        at aerial.aerosaite.core$_main.doInvoke(core.clj:179)
        at clojure.lang.RestFn.applyTo(RestFn.java:137)
        at aerial.aerosaite.core.main(Unknown Source)

I don't seem to have visibility on the aerial.aerosaite.core repo, so I can't see what -main is doing. It looks like maybe your filesystem utility support doesn't cover windows (that's my best guess based on the stack trace). Looking at the aerial.fs/fullpath, the one that ships with the saite uberjar is different than the one on the public repo. I looked at the source from the REPL.

The original source uses regexes for matching different separators.

If I monkey patch it from the repl to use literal strings instead of the regex:

(defn fullpath
  "Canonicalize FILESPEC, a string, to a fully qualified file path
   for the native system.  ~ in position one is translated to the
   users home directory path, / and \\ are translated to the file
   separator for the native system."
  [filespec-str]
  (let [^String s (str filespec-str)
        s (replace-re
           (case separator
             "/" "\\"
             "/") separator s)]
    (cond
      (= s "~") (System/getProperty "user.home")

      (.startsWith s "~")
      (str (System/getProperty "user.home")
           (if (= (.charAt s 1) File/separatorChar) "" separator)
           (subs s 1))

      :else s)))

I get a passing result:

aerial.fs=> (fullpath "~/.saite/path/to/glory")
"C:\\Users\\joinr\\.saite\\path\\to\\glory"