From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: d3js chord diagrams Date: Tue, 25 Oct 2016 11:01:26 +0200 Message-ID: <87h980ajkp.fsf@gnu.org> References: <87zilxtkvp.fsf@elephly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:46436) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byxby-0006l9-56 for guix-devel@gnu.org; Tue, 25 Oct 2016 05:01:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1byxbt-0001kH-FT for guix-devel@gnu.org; Tue, 25 Oct 2016 05:01:34 -0400 In-Reply-To: <87zilxtkvp.fsf@elephly.net> (Ricardo Wurmus's message of "Sat, 22 Oct 2016 00:09:14 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ricardo Wurmus Cc: guix-devel Hi! Ricardo Wurmus skribis: > I=E2=80=99ve built something: > > http://elephly.net/graph.html Awesome! Much better than staring at a static graph in Evince. > I=E2=80=99ve tried earlier to build a force-directed graph to visualise t= he > package dependency graph, but I had to realise that a force-directed > graph with the number of links and nodes that is common in software > dependencies is visually indistinguishable from a cat=E2=80=99s hair ball= . In > contrast I find the chord diagram to be much clearer. Are there other types of visualizations supported by d3 that would help? > I turned this into a backend for =E2=80=9Cguix graph=E2=80=9D, so that yo= u can generate > There are a couple of implementation issues that I=E2=80=99d like to get = input > on before submitting a proper patch. This depends on =E2=80=9Cd3.v3.js= =E2=80=9D, which > I=E2=80=99ve downloaded from http://d3js.org/d3.v3.js. (This is not mini= fied > and thus rather large.) In my current implementation the contents of > this file are embedded in the report, because we don=E2=80=99t serve this= file > at a well-known location. Is this okay? We probably could use file:// > links, but that requires knowledge about where this file is located. What about having a fixed-output derivation (aka. =E2=80=98origin=E2=80=99)= to download that file from a stable, versioned URL? > If it is okay to bundle d3js with Guix, where should it be installed? > How can graph.scm know about the location of this file after > installation? Should I add the path to d3.v3.js to > =E2=80=9Cguix/config.scm.in=E2=80=9D? An option is to download it to the store on demand. The downside, of course, is that it would require network access. If the .js files were to be installed, I agree with using PREFIX/lib/js as Pjotr suggests. > Should this go to =E2=80=9C$out/share/guix/=E2=80=9D? How would these fi= les be found > when using =E2=80=9C./pre-inst-env=E2=80=9D? Well, if it=E2=80=99s just the small graph.js, you could store it in module= dir, like we do for patches. This is a hack, but the advantage is that we can just use (search-path %load-path =E2=80=A6) to find them, regardless of whether we=E2=80=99re using ./pre-inst-env or not. Otherwise we could add a new GUIX_JAVASCRIPT_PATH env. var. and corresponding =E2=80=98search-javascript-file=E2=80=99 procedure. > Attached are patches so that you can play with this. The assumption is > that =E2=80=9Cgraph.js=E2=80=9D and =E2=80=9Cd3.v3.js=E2=80=9D are in the= current directory, the same > directory where you invoke =E2=80=9C./pre-inst-env guix graph --backend= =3Dd3js =E2=80=A6=E2=80=9D. Just tried it and it works like a charm. :-) Thank you! Ludo=E2=80=99.