Graph drawing in javascript using d3.js

[nathanncohen]

As the title says.

This drawing method will be as good as the examples that are used to tune its parameters :-)

Nathann

CC: @sagetrac-bonfroy

Component: graph theory

Author: Nathann Cohen, Brice Onfroy

Branch: 76acf85

Reviewer: Dima Pasechnik, Volker Braun

Issue created by migration from https://trac.sagemath.org/ticket/14953

[nathanncohen]

Attachment: trac_14953.patch.gz

[fchapoton]

comment:3

Attachment: trac_14953_review1.patch.gz

very nice tool. Here is a purely cosmetic review patch

I still have to finish the review, but later

[nathanncohen]

comment:4

Well if you have some time to review that ?.... :-P

[nathanncohen]

Branch: u/ncohen/14953

[nathanncohen]

comment:5

Now a GIT patch.

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

[changeset:84b44ab]	Git directory layout
[changeset:465f9db]	trac #14953 cleanup, pep8 and details
[changeset:89bbece]	Graph drawing in javascript using d3.js

[sagetrac-git]

Commit: 84b44ab

[rwst]

Work Issues: rebase

[sagetrac-git]

Changed commit from 84b44ab to 44265a5

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

44265a5

trac #14953: Merged with 6.3.beta0

[nathanncohen]

comment:11

Fixed. If you feel like giving it a review ... It is 10 months old already :-P

Nathann

[nathanncohen]

Changed work issues from rebase to none

[dimpase]

comment:13

One must be online to use this stuff, right?

[nathanncohen]

comment:14

Right now yes, but there is no "technical" reason. Right now, it loads the javascript files d3.js from some URL, all this is not contained in the patch. We can later change that or write a spkg containing those files, and there will be no need of that anymore.

Nathann

[dimpase]

comment:15

looks good. I'll check that the docs build, and then it should be good to go.

[dimpase]

Changed branch from u/ncohen/14953 to u/dimpase/14953

[vbraun]

comment:20

Pops up a browser window when running "make ptestlong"... please find a better way of automated testing ;-)

[vbraun]

comment:21

Also, anything that requires internet must be marked as # optional - internet.

[nathanncohen]

comment:22

Hmmmmm... Is there a way to test anything that this patch does ?... :-/

Nathann

[vbraun]

comment:23

You can split the html generation from the show() function and doctest it as usual. Show can just check DOCTEST_MODE to avoid starting the browser.

Also, don't load the html template from SAGE_SRC. Thats the source code, if you need files at runtime then they must be installed under SAGE_LOCAL. You should probably put it somewhere under src/ext and then use SAGE_EXTCODE to refer to it.

[nathanncohen]

Changed commit from 44265a5 to 76acf85

[nathanncohen]

comment:24

Here is a commit to implement all that. The down side is that you have to run "make" for the .html file to be copied in SAGE_EXTCODE ..... That's what Volker wanted.

Nathann

---

New commits:

9cbcc36	trac #14953: Merged with 6.3.beta2
76acf85	trac #14953: Moving the .html to EXT_CODE and using DOCTEST_MODE

[nathanncohen]

Changed branch from u/dimpase/14953 to u/ncohen/14953

[vbraun]

comment:25

lgtm

[vbraun]

Changed reviewer from Dima Pasechnik to Dima Pasechnik, Volker Braun

[vbraun]

Changed branch from u/ncohen/14953 to 76acf85

[sagetrac-tmonteil]

Changed commit from 76acf85 to none

[sagetrac-tmonteil]

comment:27

Hi, i do not like the need to fetch a file from the internet to let this work. My question for a future ticket is the following: if i understand correctly, src/ext is a kind of place where we put external source code that is not big enough to deserve a package, am i right ? In this case, is this the right place to copy the file d3.v3.min.js for offline use ?

[nathanncohen]

comment:28

Yoooooooooooooo !

Hi, i do not like the need to fetch a file from the internet to let this work. My question for a future ticket is the following: if i understand correctly, src/ext is a kind of place where we put external source code that is not big enough to deserve a package, am i right ? In this case, is this the right place to copy the file d3.v3.min.js for offline use ?

HMmmmmmm.... I am interested by Volker's answer, but I would say that stuff in src/ should be reviewed... Sooooooo no third-party code should be there. Besides, it is very easy to write spkg now with git.

This being said, I do not know which files we are allowed to read at runtime...

Nathann

[vbraun]

comment:29

No, SAGE_EXT is where we install non-Python Sage source code. Its not a dump for third-party stuff that you don't want to package.

[nathanncohen]

comment:30

Volker : if we package this code how can we access it at runtime ? What would the spkg-install do, and where would it copy the .js file ?

Nathann

[sagetrac-tmonteil]

comment:31

OK, so we have to make a spkg that just copy the d3.v3.min.js file into ./local/share/d3.js/ directory, then we can use from sage.misc.misc import SAGE_SHARE to get it. It that the correct procedure ? Or do we need to recompile the .js file from sources ?

[dimpase]

comment:32

there could be copyright issues that would preclude one from distributing it with Sage, so it will need to stay an optional Sage package, whether you like it or not.

IANAL. Here is the licence: https://github.com/mbostock/d3/blob/master/LICENSE

[sagetrac-tmonteil]

comment:33

IANAL either, this is a Modified BSD License, which is GPL-compatible according to the FSF (see also wikipedia). So it is OK to have it as a standard spkg, right ?

[sagetrac-tmonteil]

comment:34

This is now #16434 so that i will learn how to package.

[sagetrac-tmonteil]

comment:35

See also #16438 which links both features.