[WIP] Download converted documents with uploadable configuration #2413

mpacer · 2017-04-13T22:42:36Z

At long last! The ability to upload a custom configuration file to customise exports is here.

There are still a lot of issues I need to work out in terms of the UI, but the core functionality is present.

Steps to accomplish this:

click on File → Custom Download
choose your output format from the dropdown menu
click on choose file and add your .json config file
click submit

Looking forward to getting feedback on this.

Note: by doing this, I've actually made the current "Download as" sub-menu somewhat redundant as that is equivalent to this case but where you simply don't give it any config file.

I'm a little concerned about size limitations due to the current anchor + dataURI approach to downloading things, but I figured others would have clearer thoughts on that than I would be able to express. edit: I realised that the size worries stemmed from an earlier attempt of mine and that I had actually addressed that by using the blob object and createObjectURL approach.

Bonus: it allows downloading without needing to open a new window, which I see as a win.

Thank you to everyone who helped bring this to fruition (@minrk, @takluyver and especially @Carreau).

cc: @bollwyvl

mpacer · 2017-04-13T23:00:02Z

cc @rgbkrk and @ivanov may also be interested in this.

Carreau · 2017-04-14T16:48:33Z

notebook/nbconvert/handlers.py

                }
            )
+
+            print(resources)


forgotten debug

Carreau · 2017-04-14T16:48:49Z

notebook/nbconvert/handlers.py

+
+    @web.authenticated
+    def get(self, format, path):
+


nitpicking 2 whitelines.

I'm guessing you meant the one below get and the one above self.finish().

Carreau · 2017-04-14T16:49:53Z

notebook/static/notebook/js/menubar.js

+      fileformat.append(
+        $('<option>script</option>')
+          .attr('value','script')
+      );


you may be able to chain the append, or put that in a loop.

done, via loop (which takes a standard structure which will make it easier for linking into by 3rd party exporters)

Carreau · 2017-04-14T16:50:25Z

notebook/static/notebook/js/menubar.js

+      form.append(fileinput);
+      body.append(form);
+
+      var notebook_path = utils.encode_uri_components(this.notebook.notebook_path);


you've the same line that defines notebook_path above.

Carreau · 2017-04-14T16:51:14Z

notebook/static/notebook/js/menubar.js

+        };
+        if (fileinput[0].files.length>0){
+          filereader.readAsText(fileinput[0].files[0]);
+        }


else on same line as }

Carreau · 2017-04-14T16:52:06Z

notebook/static/notebook/js/menubar.js

+        xhr.setRequestHeader('X-XSRFToken', xsrf_token);
+        xhr.onreadystatechange = function(){
+          if(xhr.readyState === 4){
+            var blob = xhr.response;


Did you figured out the unicode thing ? was is "just" not using jquery ?

more or less that seemed to do it as bizarre as that is.

I don't know exactly what the issue is, but I hope we can work out how to do this with a more familiar API than the low-level XMLHttpRequest interface.

We searched a lot, and many responses on internet were "do not use jquery". It's trying to do fancy stuff to guess encoding.

Maybe it's possible to turn the encoding detection off? We have Ajax functionality that works throughout the rest of the codebase, I find it hard to believe it's totally incompatible in this one place.

Yep, in our specific case, raw XMLHttpRequest was the only thing that was stated (by others) to work for passing around binary objects unaltered as we wanted. And we tried using other mechanisms to get this to work and none of them worked — figuring out this is probably the part that took longest of this entire PR.

This is precisely the place in which it's totally incompatible. It's a known issue: http://stackoverflow.com/a/23797348/1816995. That answer admittedly is a bit old, but I spent a long time trying to solve it and this works without finagling, so I'd prefer to stick with it.

Carreau · 2017-04-14T16:53:06Z

notebook/static/notebook/js/menubar.js

+          a.download = fileName;
+          a.click();
+          window.URL.revokeObjectURL(url);
+        };


you probably want to remove a from the dom.

Carreau · 2017-04-14T16:53:45Z

notebook/templates/notebook.html

@@ -84,6 +84,7 @@
                            <a href="#">Open...</a></li>
                        <!-- <hr/> -->
                        <li class="divider"></li>
+                        <li id="custom_download"><a href="#">Custom Download</a></li>


Don't forget to put that back in its original place.

I actually think moving it here is an improvement in the design in the menubar. It should not require drilling down into the menu structure to access this feature.

I'm fine moving it down next to "Download as…" but it shouldn't be one option among the various downloads as it is strictly speaking a broader class of functionality.

Re: "Download as…" I'm thinking of actually switching them to use this post method as then they won't open a new window (which I've always disliked).

Carreau · 2017-04-14T16:55:06Z

Thanks that's great. We might be able to make this more readable with Promises at some point. Don't forget to write some documentation as well :-)

takluyver

Could you also post a screenshot of the new dialog, so it's easy to see what it will look like?

takluyver · 2017-04-19T15:01:19Z

notebook/nbconvert/handlers.py

+        json_config = json.loads(json_upload.get("config",{}))
+        c.merge(json_config)
+        nb_content = json.dumps(json_upload["notebook"])
+        self.call_nbconvert(format, path, config=c, content=nb_content, post=True)


This is a bit confusing - it allows for both specifying a path and passing the notebook in the request body. I think we should stick to one or the other.

I think that's for symmetry with get that was defined before. The "only" difference between get and post is that it gets an extra config object. There is also an efficiency question that if the notebook is on the server already we don't need to send it on the wire (and that's how it works currently). In the end we want to be able to post the notebook content and this is part of the transition effort.

This is adding a new handler, so I feel like it should be possible to come up with a neater, clearer way - there's no existing code using POST to this endpoint, so compatibility isn't a concern.

It's actually not adding a new handler (from the perspective of the web endpoints), but merely distinguishing whether it got a GET or a POST request. I was trying to keep the code as similar in the conversion step as possible and that seemed the cleanest way to do it.

I'm going to write something longer in the main PR comment thread based on a conversation with Matthias. But the approach I took is the way to have the cleanest backwards compatibility story. We're going to have to come up with a migration story for the more comprehensive version of this feature.

takluyver · 2017-04-19T15:02:47Z

notebook/nbconvert/handlers.py

-    def get(self, format, path):
-
-        exporter = get_exporter(format, config=self.config, log=self.log)
+    def call_nbconvert(self, format, path, config=None, content=None, post=False):


Is the post parameter used anywhere? I don't see it.

I think that might have been a remnant of an earlier effort, I'll nix it.

takluyver · 2017-04-19T15:04:12Z

notebook/static/notebook/js/menubar.js

+          notebook: notebook.toJSON(),
+          config: config
+        };
+        return json_to_pass;


Same on this side, you're passing both the path to the notebook and the serialised notebook file.

Same answer that's on purpose: currently you need the path which forces us to save the notebook before converting. Also yo need the "path" as it affects things like the naming of the generated files.

I can change the API more fundamentally, but then the name should probably be passed in explicitly as part of the JSON object.

takluyver · 2017-04-19T15:08:24Z

notebook/static/notebook/js/menubar.js

+        xhr.setRequestHeader('X-XSRFToken', xsrf_token);
+        xhr.onreadystatechange = function(){
+          if(xhr.readyState === 4){
+            var blob = xhr.response;


I don't know exactly what the issue is, but I hope we can work out how to do this with a more familiar API than the low-level XMLHttpRequest interface.

takluyver · 2017-04-19T15:13:31Z

notebook/static/notebook/js/menubar.js

+        a.style = "display: none";
+        return function (data, fileName) {
+          var blob = new Blob([data], {type: "octet/stream"}),
+              url = window.URL.createObjectURL(blob);


Neat, I didn't know about object URLs.

takluyver · 2017-04-19T15:16:59Z

notebook/static/notebook/js/menubar.js

+
+      var that = this;
+
+      var handle_nbconvert_post = function(){


Naming stuff: 'handling' something usually refers to the code that runs when that something is received. This function is getting values from the UI and sending the post request.

It technically is receiving the file if it has been uploaded when clicking the "Download" button.

But, ok, it's changed to trigger_nbconvert_post.

takluyver · 2017-04-19T15:18:28Z

notebook/static/notebook/js/menubar.js

+          on_done();
+        }
+      };
+      var on_done = function(){


Naming stuff again: on what being done? on_config_file_read?

It's also being called if there is no config file being passed in so that wouldn't be quite right either.

takluyver · 2017-04-19T15:19:45Z

notebook/static/notebook/js/menubar.js

+          if(xhr.readyState === 4){
+            var blob = xhr.response;
+            var content_disposition = xhr.getResponseHeader('Content-Disposition');
+            var filename = content_disposition.match(/filename="(.+)"/)[1];


This is a good point to have a fallback of some kind, in case the regex doesn't match, or the header isn't even there.

That is, I should just have an error?

I'm pretty sure that the request did not work properly if it doesn't have an attachment and a filename.

Probably an error, it's just best for it to be a clear one rather than a cryptic one because something you assumed would always be true no longer is.

mpacer · 2017-04-20T00:15:35Z

@Carreau and I talked about the choice of continuing to include path and other aspects of the old GET api in this and we realised that there might be issues with backwards compatibility and the way that the endpoints that are being looked for are being defined.

For example a post request handler of a sort exists that does not have a path following it, but the way that the path_regex swallows all paths in the url postceding the format results in us having no way to specify a different API without special casing some of the ways that tornado will handle the current APIs.

As a more general topic, we need to discuss our path toward having nbconvert as a service. I was trying to write this in a way that would allow that fairly easily and I made decisions while keeping that goal in mind.

For example, right now this is transmitting the entire notebook as json when that notebook is already on the server. That introduces higher bandwidth costs but accommodates the case where the notebook is not on the server. But solving that would also require passing along (or embedding) resources to the endpoint that would not otherwise be available for conversion. That seems like a much harder problem, but something we should be thinking about.

@Carreau had specific suggestions about how to move forward with this PR and what issues to open…I don't remember all of them in particular (and need to run and want to post this now) so I'll let him raise those points later.

takluyver · 2017-04-20T16:07:11Z

Fair enough about the raw XHR, though I still hope we can make that code a bit neater.

I'm still puzzled why you're talking about backwards compatibility. You're adding a new operation that wasn't possible before, so there's nothing for it to be backwards compatible with. It doesn't matter that the same URLs already work for GET requests; POST requests are entirely separate. If you don't want to pass the path in the URL, make a new endpoint like /nbconvert-config/html (for instance). Or replace the existing nbconvert post handler - I don't think anything uses that.

Backwards compatibility is what forces us to make awkward compromises. You have the liberty of designing a new API that doesn't have to be backwards compatible with anything, so design it to be beautiful and simple and consistent, not involving a load of duplicate information with a 'backwards compatible' label stuck on it.

mpacer · 2017-04-28T21:03:07Z

oops…messed up a rebase and forced pushed without thinking about it. I'll try to fix this.

ellisonbg · 2017-09-20T22:25:53Z

Recently I have been looking at the UX design around RStudio's document conversion stuff. I knmow some folks who use Jupyter and RStudio and from their perspective, the UX of RStudio is so far ahead of us on this point, they wouldn't think of using nbconvert - even though nbconvert does much of what is offered on RStudio from the technical perspective.

What is a remarkable is that from a technical perspective, what RStudio does is much more primitive that what we do in the notebook (custom REST endpoint, menus, custom UI). They have nicer UI, but the result of that UI is to just fire off a command in the terminal. It converts things in place and leaves the converted documents (HTML, pdf, etc.) in that directory.

I think we should step back from the technical details of this and do some UX design work to understand what Jupyter users really need in this area. It may be that we can provide what they need with some small UI improvements and no difficult technical work.

I think studying the RMarkdown/RStudio model would be a good starting point.

mpacer · 2017-10-04T00:38:04Z

@ellisonbg I agree with you that we have much to learn from the RMarkdown and RStudio approach to document creation. Fortunately, that is exactly the kind of thing that this PR is trying to do!

nbconvert (as a CLI) works as a simple command that you can just fire off in the terminal, which converts things in place and leaves the file(s†) in the directory. You can configure it by passing in a configuration file with the --config argument.

Unfortunately, the notebook doesn't have any good way to surface this functionality when exporting to different formats. That is even taking into account that nbconvert is being used on the backend to manage the conversion.

The primary problem is that there is no user-friendly way to pass a configuration file to nbconvert from the front end.

It is (strictly speaking) possible to configure your exports in a way that is mostly in the front-end. Specifically, the configuration file that nbconvert uses by default is the same configuration file that the NotebookApp receives at the point of its instantiation. So the only way to currently change the configuration of an export is to shut down the server, and then restart it.

Forcing a user to stop whatever they were doing in order to shut down the server and restart it is about as user hostile an approach to configuration as I can imagine. Solving that was the first task of this PR.

This PR makes it possible to pass in a JSON version of the configuration file to the nbconvert calls, which allows us to get around that limitation. You can just create whatever configuration file you want and pass it in.

The second problem that this addresses has to do with how the download occurs. Currently our downloads occur by redirecting us to a new tab where we pass the information needed for conversion via the url. At best, opening a new tab is an inconvenient and unnecessary context switch.

This PR allows us to trigger the download in the background of the current tab without any interruption to a person's workflow.

A third problem this approach inadvertently solves is a feature that @ian-r-rose was asking for: the ability to pass in a notebook as part of the data attached to a POST request that is then able to be converted by nbconvert and return the resulting file in the response to the POST request.

Perhaps most importantly to your points, this PR solves many problems that will make it easier for others to try other UX deisgns on the basis of the infrastructure built here.

So, I think in fact your arguments are reasons for moving forward with this PR, not stepping away from it. Hopefully with these explanations, you agree. If not, then please respond, and I will do my best to address any remaining concerns.

Footnotes:

†: For example, for document formats that don't support images being directly embedded (e.g., plaintext formats like rst), nbconvert creates a directory that contains the relevant images along side the main file.

ellisonbg · 2017-10-04T16:38:33Z

I probably didn't flush out enough details. Here is what I am proposing:

Use existing Jupyter services for working with the filesystem and editing files.
For the configuration file, provide a nice way for the user to create and edit a config file as just a regular text file that would sit next to the notebook to be converted. We have an existing REST endpoint for working with files. It could be as simple as a button that write a sample config file to that directory over the rest endpoint.
For the editing of that file, just use our exsiting file editor UI.
For the running of nbconvert, don't use a REST end point, just open a terminal in the UI for the user and send the right command to it, something like nbconvert yournotebook.ipynb --config config.pys.

In the classic notebook, all of this is possible, but it will be a bit clunky because the different UI's needed (file browser, notebook, file editor, terminal) are on different pages. But it is still possible. In JupyterLab, we can provide an extremely nice and optimized UX around these abstractions.

This is exactly how RStudio works. The only difference is that RMarkdown allows the conversion config to be put into the markdown file in a YAML block. We could also explore things like that as well if we want, but it is not needed for all of this to work.

ian-r-rose · 2017-10-04T18:30:23Z

It seems to me that there are two points of discussion here which are related but distinct:

How do we improve the existing notebook UX for running nbconvert? @mpacer's points about not needing to open a new tab seem like they should be uncontroversial.
In order to get the UX we want, do we need to expand to another REST endpoint? @ellisonbg, it seems like you are suggesting punting on that for custom-configured nbconvert exports and just having people doing that manually through the terminal+file-editor. This obviates the need for restarting the server, as I understand it.
One place where that would be difficult to make work is the use-case that I ran into with @jupyterlab/google-drive: If the notebook store is not on the server, the current path-based nbconvert REST API does not work (cf jupyterlab/jupyterlab-google-drive Remove genutils from requirements.txt #51). In that case, actually being able to POST a notebook contents+configuration is actually a really nice solution.

Carreau · 2017-10-04T19:20:03Z

I agree with M and Ian, and we had this discussion at the dev meeting a couple of month ago; while the approach that you (@ellisonbg) is proposing has some advantage from the user point of view it is in large part orthogonal to what is developed here. This not only expose a UI to do some conversion; but also expose nbconvert through a rest API. This has been discussed quite a bit in various context and is necessary for other improvement we'd like to do; like an nbconvert CLI that use remote conversion - for example because getting latex installation correct is not easy.

I also want to point out that not everyone is using and developing on top of JupyterLab and that the rest API for nbconvert is extremely useful for custom clients wishing to do conversions.

mpacer · 2017-10-07T01:27:06Z

I'm at a loss as to why this is suddenly failing when 817a87c didn't fail.

@rgbkrk do you have any thoughts? This looks really similar to the errors in #2884, but I can't figure out what could be triggering race conditions all of a sudden when it worked in the previous commit…

mpacer · 2017-10-07T02:05:12Z

ok… now when i go back and run tests locally on 817a87c, the tests now fail. I'm deeply baffled as to why. but I'm going to stop trying to appease the casperjs gods and call this a night.

If someone tries this branch and they can't get this to work, please let me know.

ellisonbg · 2017-10-07T23:30:45Z

@Carreau thanks for clarifying the intended usage of the different parts of this PR.

I completely understand the general need for a REST API for nbconvert. In particular, the main usage case that I see is a hosted version of nbconvert that is run separately from the rest of the notebook server.

In general, I tend to think that the REST services of the notebook server are one of the project's "open standards" and we should evolve it conservatively and with very clear versioning semantics and documentation. At the same time, I want nbconvert to be able to move quickly and innovate.

Because of this, I would probably feel more comfortable with the server side parts of this being in nbconvert and used in the notebook server as a server extension. That would also make it very easy to develop a separate server that just does nbconvert REST calls. We have taken the exact same approach with the Git server extension that exposes a REST API to git.

For the classic notebook I am fine with the UI additions in this PR, if the server side stuff is moved to a server extension, the UI could remain and add a small amount of logic to see if the server side stuff is installed and enabled. It could also be added as a nbextension, but that is a pain. The only potential issue there is version mismatch between the UI and the server extension.

For JupyterLab usage, the UI would probably be developed as a JupyterLab extension (an npm extension) so any of these options are fine on that front.

I agree these things are mostly separate from the issues I was bringing up about the usability of nbconvert. However, my points about the usability still stand and I don't think that these proposed changes remove the need for us to consider those matters on their own.

…entmodel, output format & config

…sing to the json object

…base

…ndition

rgbkrk · 2018-02-21T00:20:03Z

notebook/static/notebook/js/menubar.js

+        var url =
+          utils.url_path_join(
+            that.base_url,
+            "nbconvert",


This trailing comma will also make PhantomJS choke.

switch consts to var per remove trailing commas

mpacer · 2018-02-21T07:04:20Z

Working on some tests & changes that came about as a result of writing those tests.

I've introduced a decision point. I need to make either the configuration file that is uploaded the source of truth for the output format or the setting in the application. I'm going to go with the configuration for now, as there would be no way to otherwise point to a non-entrypoint specified output format.

- use Config object - keep naming consistent with other Handlers - use export_format instead of output_format, to match NbConvert.export_format - search configuration for export format and fallback to the json body

also, change name to NbconvertConfigHandler

damianavila · 2018-02-21T13:24:33Z

notebook/static/notebook/js/menubar.js

+
+      var fileformat = $("<select>");
+
+      var export_opts = {


I don't see slides here... could be the case?

Well the tests pass after I made the changes @rgbkrk suggested, but I definitely should include slides there. Apologies!

damianavila · 2018-02-21T13:26:39Z

notebook/templates/notebook.html

-                                <li id="download_markdown"><a href="#">{% trans %}Markdown (.md){% endtrans %}</a></li>
-                                <li id="download_rst"><a href="#">{% trans %}reST (.rst){% endtrans %}</a></li>
-                                <li id="download_latex"><a href="#">{% trans %}LaTeX (.tex){% endtrans %}</a></li>
-                                <li id="download_pdf"><a href="#">{% trans %}PDF via LaTeX (.pdf){% endtrans %}</a></li>


Can I ask you why you remove {% trans %} on these ones?

It was a while ago that I had made that decision with input from either @takluyver or @Carreau, on the grounds that for some of those, a translation would never make sense (e.g., LaTeX should always be LaTeX). However you’re right that we can always include the translation tag and assume that there won’t be a mistranslation (e.g., treating reST as rest (the verb) with weird capitalisation and translating accordingly). Certainly Notebook, Script and the word “via” make sense to translate. I can add those tags back.

@damianavila

- change the capitalization to match menu options - add slides - add translations back Thanks @damianavila

This changes the base-path to be / instead of /api so that in the future other APIs that return files and do not redirect you to a new address (e.g., see jupyter#2413). This also improves the way that the api spec handler responds to a request, by actually displaying the spec with the appropriate content-type header (text/x-yaml) instead of triggering a download with the StaticFileHandler's default application/octet-stream mimetype.

mpacer · 2018-05-01T16:43:44Z

@gnestor @takluyver I just realised I never wrote out the API spec for this, so I definitely need to get that in before this would be merged and now that our spec is cleaner, this should be much easier.

blink1073 · 2020-06-08T10:46:36Z

Closing this PR as stale as part of housekeeping (and because of the merge conflicts). Thanks for exploring this @mpacer!

Carreau reviewed Apr 14, 2017

View reviewed changes

takluyver reviewed Apr 19, 2017

View reviewed changes

mpacer force-pushed the mmd_export branch from 7effe55 to 0d8d641 Compare April 19, 2017 23:27

mpacer force-pushed the mmd_export branch from e576b32 to 0380c9b Compare April 28, 2017 21:05

mpacer mentioned this pull request Sep 7, 2017

Tags: an attempted overview #2826

Closed

juhasch mentioned this pull request Sep 15, 2017

printview assumes the notebook is in the current working directory ipython-contrib/jupyter_contrib_nbextensions#1085

Open

takluyver mentioned this pull request Sep 20, 2017

Add Template as Metatada enhancement proposal jupyter/enhancement-proposals#23

Closed

mpacer force-pushed the mmd_export branch from 0380c9b to c538a0e Compare October 4, 2017 17:56

mpacer force-pushed the mmd_export branch 2 times, most recently from 7d1f362 to deaac69 Compare October 6, 2017 23:48

mpacer added 12 commits February 20, 2018 15:20

match RFC5987 3.2 formatting for Content Disposition, prettify code

8e96ffb

cleanup logs, prints, and comments

26d75de

remove buffer from use as var name (python keyword conflict)

704844b

return old get endpoint to its classic form

cda47c1

create nbconvert-service endpoint, takes no arguments, json with cont…

b9caeaf

…entmodel, output format & config

create contents model style json object for post request

6e62b25

point to the correct api, gather the needed resources in that for pas…

935a176

…sing to the json object

reformat js for onSave to be more idiomatic & better presented

4f1cce5

Add SUPPORTED_METHODS class attributes, bring closer to previous code…

2ab6ab9

…base

remove ES6 style anonymous functions

d39593b

don't assign values to that directly, in case that triggers a race co…

b102783

…ndition

improve POST endpoint to be /nbconvert; clean up unused code

4a636b4

mpacer force-pushed the mmd_export branch from 93843e5 to 9ee188d Compare February 20, 2018 23:24

rgbkrk reviewed Feb 21, 2018

View reviewed changes

Fixes for @rgbkrk's suggestions to make phantom tests pass

74137ef

switch consts to var per remove trailing commas

mpacer force-pushed the mmd_export branch from 9ee188d to 74137ef Compare February 21, 2018 00:29

mpacer added 2 commits February 20, 2018 23:48

improvements to the handler

e237b21

- use Config object - keep naming consistent with other Handlers - use export_format instead of output_format, to match NbConvert.export_format - search configuration for export format and fallback to the json body

add tests for NbconvertConfigHandler

e4342c5

also, change name to NbconvertConfigHandler

damianavila reviewed Feb 21, 2018

View reviewed changes

Fixes in displaying export_formats

a804423

- change the capitalization to match menu options - add slides - add translations back Thanks @damianavila

mpacer mentioned this pull request Feb 23, 2018

API spec improvements, API handler improvements #3368

Merged

mpacer mentioned this pull request Mar 6, 2018

Edit meta-data to suppress code input and cell numbers for reveal.js jupyterlab/jupyterlab#4100

Closed

blink1073 closed this Jun 8, 2020

github-actions bot added the status:resolved-locked label Mar 24, 2021

github-actions bot locked as resolved and limited conversation to collaborators Mar 24, 2021

[WIP] Download converted documents with uploadable configuration #2413

[WIP] Download converted documents with uploadable configuration #2413

Conversation

mpacer commented Apr 13, 2017 • edited Loading

mpacer commented Apr 13, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Carreau commented Apr 14, 2017

takluyver left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mpacer commented Apr 20, 2017

takluyver commented Apr 20, 2017

mpacer commented Apr 28, 2017

ellisonbg commented Sep 20, 2017

mpacer commented Oct 4, 2017

ellisonbg commented Oct 4, 2017

ian-r-rose commented Oct 4, 2017

Carreau commented Oct 4, 2017

mpacer commented Oct 7, 2017

mpacer commented Oct 7, 2017

ellisonbg commented Oct 7, 2017

rgbkrk Feb 21, 2018 • edited Loading

Choose a reason for hiding this comment

mpacer commented Feb 21, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mpacer commented May 1, 2018 • edited Loading

blink1073 commented Jun 8, 2020

mpacer commented Apr 13, 2017 •

edited

Loading

rgbkrk Feb 21, 2018 •

edited

Loading

mpacer commented May 1, 2018 •

edited

Loading