Fork me on GitHub
#data-science
<
2018-11-09
>
jsa-aerial00:11:55

@metasoarous RE: Single PR. I'm not sure, but when I tried this it failed and when miikka and I looked into it, it became clear that the way the tests are setup (now...) if you have dependencies, you need to have them committed first before adding stuff that depends on them

jsa-aerial00:11:44

Yes, template system is a major part of any vis app with Hanami - Saite makes full use of it. The recursive transformation of parameterized templates into legal VG/VGL specs is really the heart of things. There are a lot of other bits, but those are more straightforward/typical - even the streaming data stuff.

jsa-aerial00:11:41

RE: reagent/react Hanami also uses the new (non deprecated) life cycle components and flow of recent React releases.

jsa-aerial00:11:06

Re: Hanasu websockets. Yes it is way simpler and avoids the complection of Sente. Yes, Hanasu is completely symetric (modulo only servers can perform the handshake http websocket initialization). It's very simple and provides the correct separation of messaging system envelopes from application level envelopes. Plus it provides backpressure info to app level code. Sente does not do any of this and it is rather baroque in structure and code.

metasoarous00:11:58

Yup; I noted. I'll give it a whirl.

jsa-aerial00:11:12

Also, I am getting near releasing a Python client for Hanasu. And plan a Ruby one as well. I need these for Aerobio interaction

👍 4
jsa-aerial00:11:16

Re: Saite stuff. Actually oz is effectively the single tab, single visualization, single session use case of Saite. Saite being on top of Hanami, can use hiccup directly but prefers to use re-com components as higher level hiccup generators. OTOH, it does make use of Hanami's tab system (for multiple sets of visualizations on a single page) and the automated grid layout that it provides.

jsa-aerial00:11:56

If you want complete application specific flexibility to build and layout visualizations with full control over page content and layout (for a specific task/domain) then Hanami is what you want. Saite is for exploratory and ad hoc (presentations and such) visualizations. I suppose the key distinction here is that Hanami is a library (with some optional framework bits) for building apps. Saite is an app.

jsa-aerial00:11:18

For example, Aeroviews is being built on top of Hanami and Aerobio and is using custom re-com components and layouts for the various pages and explorations

jsa-aerial00:11:30

Re: Notebook. I know a really nice and highly capable notebook could be built with Hanami + CodeMirror + ProtoRepl but I don't really have the time to do that.

jsa-aerial00:11:02

Another thing worth mentioning about Hanasu is that it can send and receive either text based (JSON) or binary messages (msgpack) in the same session. I don't think Sente (or Chord for that matter) has this either. You need to pick a line protocol and stick with it.

bvs09:11:56

@js-aerial The thing that works for me with oz is that its syntax is very close to vega-lite, so I am learning from all the vega-lite examples out there. Also, with oz being more of a minimal wrapper around vega/vega-lite, its future usability is less dependent on metasoarous remaining actively supporting this package, which is something I learned to appreciate 🙂. But good luck with Saite/Hanami!

❤️ 4
jsa-aerial15:11:35

Legal VG/VGL specs are legal Hanami templates. So, you can just use the exact thing you use now. Actually, even better you can use the Saite translate tab to convert any JSON VG/VGL to equivalent Clojure(Script). I do that a lot to create specs I can then mess with from Clj/Cljs. But then, if you find yourself repeating things a lot (very typical) you could start abstracting those bits into template(s). WRT 'minimal wrapper' - you still need to follow the VG/VGL/VGE releases - or fall behind or victim to bugs...🙂 But if that is what you want to stay with - go for it!

metasoarous23:11:23

@bvs It's true that keeping the various vega libraries up to date is important, and I have not been as diligent as I would like in keeping them up to date myself. However, to make this easier in the future I've put together a script for automating the process, and @jsa-aerial has been kind enough to help me review the output: https://github.com/metasoarous/oz/blob/master/bin/update-cljsjs.sh. I've also added some notes in the README about this: https://github.com/metasoarous/oz#debugging--updating-vegavega-lite-versions; So if for whatever reason I'm busy and not able to mint a full release of oz right away, it should at least be quite a bit easier for anyone who wishes to run the updates themselves to do so, and push to cljsjs if they see fit. Hopefully this ends up being helpful for the entire community.

👍 4
manandearth10:11:10

@jsa-aerial is there a tutorial or example showing how to require any of the examples of your basic_charts.clj of the jsa-aerial/hanami to the index.html file? I'd like to use it for charting in cljs.

jsa-aerial15:11:04

Let me see if I understand. You want to use the templating from within the browser (cljs)? That's certainly doable and intended for building out domain/task specific apps. So presumably you are already coding on the browser/client side. In your Cljs code, you can just require the aerial.hanami.templates and aerial.hanami.common and have access to all of that capability. hc/xform and ht/... templates will be directly usable (as well as the defaults and update-defaults, subkeyfns, etc. Once you generate a VGL/VG spec (or if you just cut and paste one...) you still need to render it. So, you can require aerial.hanami.core to access the various rendering capabilities there. For example, if you want to use the tab system, you could just call update-tabs on your spec. If you want to create your own custom layouts and such you can call the vgl reagent component explicitly. That does all the direct visualization (using vega, vega-lite, and vega-embed depending on). Have a look at Saite core.cljs https://github.com/jsa-aerial/saite/blob/master/src/cljs/aerial/saite/core.cljs for an example of client side of app built with Hanami

manandearth22:11:15

Thanks, I'll try looking at saite . Trying the Hanami basic_charts.clj locally raised a conflict : > conflict on "h-box" by "re-com.box" used by "re-com.core"

jsa-aerial07:11:01

Not entirely sure what you mean by using basic-charts.clj locally. Those are examples where you work in CLJ (on server side) and push the visualization to the browser. You can't just directly use the Clj in that file from Cljs as things like sv! do not even exist on the client.

jsa-aerial07:11:21

This is probably some confusion on how things are structured between client and server. I'm still not sure if you are working entirely in the browser (Cljs) or a mix of Clj (server) and Cljs (browser).

manandearth08:11:12

I would eventually like to work on both server side and client side, At the moment it is a client side project where all the data is on the client side. What I did (erroneously ..) was copy dependencies and example code from your example clj file. to try it out...

jsa-aerial19:11:14

Ah, so pulling some Clojure only code bits by accident.

jsa-aerial15:11:35

Legal VG/VGL specs are legal Hanami templates. So, you can just use the exact thing you use now. Actually, even better you can use the Saite translate tab to convert any JSON VG/VGL to equivalent Clojure(Script). I do that a lot to create specs I can then mess with from Clj/Cljs. But then, if you find yourself repeating things a lot (very typical) you could start abstracting those bits into template(s). WRT 'minimal wrapper' - you still need to follow the VG/VGL/VGE releases - or fall behind or victim to bugs...🙂 But if that is what you want to stay with - go for it!

jsa-aerial15:11:04

Let me see if I understand. You want to use the templating from within the browser (cljs)? That's certainly doable and intended for building out domain/task specific apps. So presumably you are already coding on the browser/client side. In your Cljs code, you can just require the aerial.hanami.templates and aerial.hanami.common and have access to all of that capability. hc/xform and ht/... templates will be directly usable (as well as the defaults and update-defaults, subkeyfns, etc. Once you generate a VGL/VG spec (or if you just cut and paste one...) you still need to render it. So, you can require aerial.hanami.core to access the various rendering capabilities there. For example, if you want to use the tab system, you could just call update-tabs on your spec. If you want to create your own custom layouts and such you can call the vgl reagent component explicitly. That does all the direct visualization (using vega, vega-lite, and vega-embed depending on). Have a look at Saite core.cljs https://github.com/jsa-aerial/saite/blob/master/src/cljs/aerial/saite/core.cljs for an example of client side of app built with Hanami

metasoarous23:11:23

@bvs It's true that keeping the various vega libraries up to date is important, and I have not been as diligent as I would like in keeping them up to date myself. However, to make this easier in the future I've put together a script for automating the process, and @jsa-aerial has been kind enough to help me review the output: https://github.com/metasoarous/oz/blob/master/bin/update-cljsjs.sh. I've also added some notes in the README about this: https://github.com/metasoarous/oz#debugging--updating-vegavega-lite-versions; So if for whatever reason I'm busy and not able to mint a full release of oz right away, it should at least be quite a bit easier for anyone who wishes to run the updates themselves to do so, and push to cljsjs if they see fit. Hopefully this ends up being helpful for the entire community.

👍 4