Compulsory reference to (old version of) FSharp.Charting blocks reference of newer versions

[ndalchau]

I've been using Jupyter/Ifsharp in combination with FSharp.Charting (FSC) a lot recently. To make use of the newest features of FSC (histograms and bug fixes in my case), I've been building FSC locally. Annoyingly, in order to reference my local FSC build in a notebook, I've had to forcibly remove the existing compulsory reference to v0.9 of FSC in Ifsharp. Without doing this, it seems that the compulsory reference blocks my local reference.

Do others find this annoying? The compulsory reference is definitely more of a hindrance than a convenience for me.

I'd be happy to submit a pull request for the removal of the compulsory reference, but thought it best to garner opinions before doing this.

[npmurphy]

That sounds like a sensible thing to do, the old version of FSCharting does not work on Linux.

Can the code to turn the charts into PNGs from Util.fs https://github.com/fsprojects/IfSharp/blob/master/src/IfSharp.Kernel/Util.fs#L74 be pulled out into an load_fscharting.fsx script that is already in the default path?

So to use FSCharting one would run

    #N FSCharting
    #load fscharting.fsx

And then proceed as before?

[cgravill]

I agree, while it’s convenient having a version of FSC/F# Charting automatically referenced, it’s important to allow users to control the version they use.

I’ve seen some of the notebooks @ndalchau and @npmurphy have made. While they can manually remove the references, when they share notebooks with others, it leads to confusing problems.

Now with the NuGet support (and perhaps we could add Paket support e.g. https://fsprojects.github.io/Paket/reference-from-repl.html#Adding-and-removing-NuGet-packages) then it seems less critical for usability to automatically reference dlls. @prosconi and @Rickasaurus do think it would be reasonable to remove them and go with an alternative? The switch over to Jupyter seems like a good time to make this change if so.

[tpetricek]

It would be great to add XPlot.PlotLy integration to: http://tahahachana.github.io/XPlot/

Plotly produces nice HTML5 charts and (unlike google charts), it is a standalone JS library (no sending of data to any server). Google Charts are nice too - when you don't mind sending data to Google.

Unlike F# Charting, they also work cross-platform - so it's getting closer to running IFSharp in some sort of Linux VM in Docker - or whatever the cool kids do these days :)

[prosconi]

@tpetricek One problem with having HTML5 charts is including the JS library. AFAIK there is no mechanism for easily including external JS libraries when viewing / sharing notebooks.

@npmurphy You would also have to register a display printer like so: https://github.com/fsprojects/IfSharp/blob/master/src/IfSharp.Kernel/Printers.fs#L38-L46

I'm torn between including F# Charting and taking it out. It is just so convenient to have it built in. Perhaps something like @npmurphy suggested is a happy medium

[cgravill]

@tpetricek we actually have a working integration to XPlot by @npmurphy on our local version. The original version was done as changes to XPlot but he has a newer version that can be done solely in IfSharp.

As a teaser graphic:

He's got it all working on Linux too and been providing PRs, so it's just a question of dockerifying it. I've had MBrace working in the notebook too which is where we want to get to!

@prosconi I believe @filippopolo has partial solution to including client-side graphics. It's enough for our usage but that we're watching the proposals around Jupyter client-side extensions

[isaacabraham]

@tpetricek doesn't Plotly force you to sign up for an account and put your charts in a dashboard or such - and then rate limit you? Or has that changed now?

[Rickasaurus]

At least for Bayard Rock internal stuff, it would be very nice to have a place to list automatically loaded packages as a compromise solution. It would be ok to reference an external script, but the downside there is no

N support.

[Rickasaurus]

Also that XPlot stuff looks awesome. I hope it's released soon.

[Rickasaurus]

Perhaps we could have a standard way to let nuget packages expose pretty printing? Like an ifsharp.fsx file that would be automatically loaded when the package is referenced?

[tpetricek]

@isaacabraham Not in the latest version

[cgravill]

With @npmurphy we've removed the compulsory reference FSharp.Charting with pull request #65

We've done this by a switch to installing dependencies with Paket and then two scripts to provide the convenience functions:

#load "FSCharting.fsx" // Windows
//#load "FSCharting.Gtk.fsx" // Linux/Mac requires FSCharting to use unstable Oxyplot version.

//...charting as previously

This gives us support for other operating systems (thanks to @npmurphy) but also users can now update their FSharp.Charting version with Paket. For @ndalchau you could take a copy of FSCharting.fsx and point it to your custom build.

#I "packages/FSharp.Charting/lib/net40" //<--- Change this
#I __SOURCE_DIRECTORY__

#r "System.Windows.Forms.DataVisualization.dll"
#r "IfSharp.Kernel.dll"
#r "FSharp.Charting.dll"

While this is still somewhat manual it doesn't require rebuilding IfSharp any more which should be much easier.

Hope this helps, I'll close this as complete but feel free to add new issues to refine, The Docker work is progressing #62 and XPlot is done (we should update the documentation though), pull request here #61