That would be great, if possible! I did try looking yesterday with visualvm
to see what was going on, but some 50,000 findClass calls in, visualvm ran
out of memory and crashed. And then I got distracted ...
Jony
On Tuesday, 30 December 2014 07:22:02 UTC, Mikera wrote:
I'm trying to figure
Hi Mike,
some numbers on my 2012 MacBook Air (i7):
Making a new namespace that requires gg4clj, in a newly started Gorilla
REPL session (i.e. a newly started JVM):
(time (ns test
(:require [gg4clj.core :as gg4clj])))
takes ~80ms.
If I add [clojure.core.matrix :as matrix] to the :require
@Mike Thinking out loud here ... one option would be to put the core.matrix
dependent stuff in gg4clj in a separate ns, like gg4clj.datasets or
similar. This would then avoid the loading time for users just wanting to
use gg4clj.core. I'm not sure I think this as good a solution, ultimately,
I'm trying to figure out how to get core.matrix to load much faster - I
think it's actually some kind of Clojure issue with protocols but I'm not
*exactly* sure what is causing
On Tuesday, 30 December 2014 05:13:24 UTC+8, Jony Hudson wrote:
@Mike Thinking out loud here ... one option would be
@Chris Thanks, hope it's useful for you. I might have a play with ggvis and
see how it works out.
@Mike Yeah, it would definitely be good to support core.matrix datasets.
One thing that would be nice would be to avoid the overhead of loading all
of core.matrix for those that don't use it. Do
core.matrix isn't that big of a dependency itself - it only gets expensive
in/when you load the implementations (NDArray, vectorz-clj, Clatrix etc.).
Which should be a choice of the ultimate user.
It is possible to just depend on the protocols, but I think that risks
breakage since protocols
Wonderful, gg4clj is really nice!
Regarding ggvis, it might be worth knowing that it can generate not only
interactive htmls, but also a static JSONs in Vega format (which is of
course fun to edit from Clojure).
For example:
capture.output(data.frame(x=c(1,2)) %% ggvis(x=~x) %% show_spec);
Hahaha; Well, you beat me to it... But awesome!
I'd still love to work on a native clojure implementation, but also
acknowledge that it might be a while before I'm able to given a shift in
focus of late. In the mean time, this will be super useful when base
gorilla-repl plotting functionality
Very cool!
On the data representation front, would you be open to making it support
the core.matrix Dataset protocols as well as regular Clojure maps? That
would make it much easier to integrate with Incanter 2.0 etc., and
potentially avoid some copying overhead.
It should be a simple change
Looks beautifull :) Good work
I don't know if you're also aware of ggvis. The ggplot2 reincarnation from
the same developer. It has some extra niceties like interactivity. It also
renders it output in vega. So it should ouput render also nicely in gorrila
(I guess)
http://ggvis.rstudio.com/
Thanks :-)
And thanks for the pointer to ggvis. I've been shying away from interactive
plots in Gorilla, since I haven't really seen or thought of a way to do it
that seems satisfactory - and I'm not sure ggvis is there yet. But
definitely will keep an eye on it though ...
Jony
On Friday,
11 matches
Mail list logo
