Remove hard FSCharting dependency

[npmurphy]

This will require a lot of testing to make sure it works.
Here is some example code

#load "FSCharting.fsx" // Windows
//#load "FSCharting.Gtk.fsx" // Linux/Mac requires FSCharting to use unstable Oxyplot version. IfSharp.FSCharting.Initialize()
let data = [ ("F#", 10); ("C#", 5); ("C++", 20); ("Java", 1); ]
FSharp.Charting.Chart.Bar(data) |> Display

[cgravill]

Do you mean:
#load "FSCharting.fsx" // Windows

We wouldn't want to force a GTK dependency on Windows users.

[cgravill]

That works for me on Windows too. I do get confusing warning:

The directory it's looking in is quite off, is the line as intended here:

#I "../../../bin/packages/FSharp.Charting/lib/net40"

I do think switching to Paket is overall a good change. It does mean we've added a quite manual set of steps i.e. from #61

./paket/paket.bootstrapper.exe
paket.exe install

Perhaps we could trigger those conditionally in the FSCharting.fsx? I'm thinking from a new user perspective who may have used a installer and not even know what Paket is.

[tpetricek]

Many of the auto-generated load scripts (including the FsLab one) add #I for locations that might not exist (FsLab does that for NuGet directory layout and Paket directory layout).

You can add #nowarn "211" to disable the warning - but it has to be run before the interaction that causes the errors.

[cgravill]

To avoid the manual steps, I've made a pull request npmurphy#6 where I reference Paket.Core.dll and fetch the dependencies at install time. This is probably a nicer solution as it leads to exposing the Paket api to users of the Notebook which would be a great way to get additional dependencies.

@tpetricek I tried moving the #nowarn "211" to the very top the of the fsx but it seems like fsi reads ahead, is that right? Would we have to turn off this warning before calling this?

As a more severe approach I've commented out those lines. On Windows with above Paket install that gets the required dlls in place to have a warning-free charting experience. Could you please check if that's OK elsewhere @npmurphy?

[cgravill]

Great, thanks for tidying up the changes and adding to documentation. This change might cause a bit of temporary disruption for people with existing notebooks and FSCharting dependency (now removed from include.fsx, and you now need to call #load FSCharting.fsx or #load FSCharting.gtk.fsx). However, this allows us to extend support to Mac and Linux users and allow Windows users to update their FSCharting.

I'll merge this to the Jupyter branch now.

[npmurphy]

This will require a lot of testing to make sure it works.
Here is some example code

#load "FSCharting.fsx" // Windows
//#load "FSCharting.Gtk.fsx" // Linux/Mac requires FSCharting to use unstable Oxyplot version. IfSharp.FSCharting.Initialize()
let data = [ ("F#", 10); ("C#", 5); ("C++", 20); ("Java", 1); ]
FSharp.Charting.Chart.Bar(data) |> Display

[cgravill]

Do you mean:
#load "FSCharting.fsx" // Windows

We wouldn't want to force a GTK dependency on Windows users.

[cgravill]

That works for me on Windows too. I do get confusing warning:

The directory it's looking in is quite off, is the line as intended here:

#I "../../../bin/packages/FSharp.Charting/lib/net40"

I do think switching to Paket is overall a good change. It does mean we've added a quite manual set of steps i.e. from #61

./paket/paket.bootstrapper.exe
paket.exe install

Perhaps we could trigger those conditionally in the FSCharting.fsx? I'm thinking from a new user perspective who may have used a installer and not even know what Paket is.

[tpetricek]

Many of the auto-generated load scripts (including the FsLab one) add #I for locations that might not exist (FsLab does that for NuGet directory layout and Paket directory layout).

You can add #nowarn "211" to disable the warning - but it has to be run before the interaction that causes the errors.

[cgravill]

To avoid the manual steps, I've made a pull request npmurphy#6 where I reference Paket.Core.dll and fetch the dependencies at install time. This is probably a nicer solution as it leads to exposing the Paket api to users of the Notebook which would be a great way to get additional dependencies.

@tpetricek I tried moving the #nowarn "211" to the very top the of the fsx but it seems like fsi reads ahead, is that right? Would we have to turn off this warning before calling this?

As a more severe approach I've commented out those lines. On Windows with above Paket install that gets the required dlls in place to have a warning-free charting experience. Could you please check if that's OK elsewhere @npmurphy?

[cgravill]

Great, thanks for tidying up the changes and adding to documentation. This change might cause a bit of temporary disruption for people with existing notebooks and FSCharting dependency (now removed from include.fsx, and you now need to call #load FSCharting.fsx or #load FSCharting.gtk.fsx). However, this allows us to extend support to Mac and Linux users and allow Windows users to update their FSCharting.

I'll merge this to the Jupyter branch now.

[npmurphy]

This will require a lot of testing to make sure it works.
Here is some example code

#load "FSCharting.fsx" // Windows
//#load "FSCharting.Gtk.fsx" // Linux/Mac requires FSCharting to use unstable Oxyplot version. IfSharp.FSCharting.Initialize()
let data = [ ("F#", 10); ("C#", 5); ("C++", 20); ("Java", 1); ]
FSharp.Charting.Chart.Bar(data) |> Display

[cgravill]

Do you mean:
#load "FSCharting.fsx" // Windows

We wouldn't want to force a GTK dependency on Windows users.

[cgravill]

That works for me on Windows too. I do get confusing warning:

The directory it's looking in is quite off, is the line as intended here:

#I "../../../bin/packages/FSharp.Charting/lib/net40"

I do think switching to Paket is overall a good change. It does mean we've added a quite manual set of steps i.e. from #61

./paket/paket.bootstrapper.exe
paket.exe install

Perhaps we could trigger those conditionally in the FSCharting.fsx? I'm thinking from a new user perspective who may have used a installer and not even know what Paket is.

[tpetricek]

Many of the auto-generated load scripts (including the FsLab one) add #I for locations that might not exist (FsLab does that for NuGet directory layout and Paket directory layout).

You can add #nowarn "211" to disable the warning - but it has to be run before the interaction that causes the errors.

[cgravill]

To avoid the manual steps, I've made a pull request npmurphy#6 where I reference Paket.Core.dll and fetch the dependencies at install time. This is probably a nicer solution as it leads to exposing the Paket api to users of the Notebook which would be a great way to get additional dependencies.

@tpetricek I tried moving the #nowarn "211" to the very top the of the fsx but it seems like fsi reads ahead, is that right? Would we have to turn off this warning before calling this?

As a more severe approach I've commented out those lines. On Windows with above Paket install that gets the required dlls in place to have a warning-free charting experience. Could you please check if that's OK elsewhere @npmurphy?

[cgravill]

Great, thanks for tidying up the changes and adding to documentation. This change might cause a bit of temporary disruption for people with existing notebooks and FSCharting dependency (now removed from include.fsx, and you now need to call #load FSCharting.fsx or #load FSCharting.gtk.fsx). However, this allows us to extend support to Mac and Linux users and allow Windows users to update their FSCharting.

I'll merge this to the Jupyter branch now.

[npmurphy]

This will require a lot of testing to make sure it works.
Here is some example code

#load "FSCharting.fsx" // Windows
//#load "FSCharting.Gtk.fsx" // Linux/Mac requires FSCharting to use unstable Oxyplot version. IfSharp.FSCharting.Initialize()
let data = [ ("F#", 10); ("C#", 5); ("C++", 20); ("Java", 1); ]
FSharp.Charting.Chart.Bar(data) |> Display

[cgravill]

Do you mean:
#load "FSCharting.fsx" // Windows

We wouldn't want to force a GTK dependency on Windows users.

[cgravill]

That works for me on Windows too. I do get confusing warning:

The directory it's looking in is quite off, is the line as intended here:

#I "../../../bin/packages/FSharp.Charting/lib/net40"

I do think switching to Paket is overall a good change. It does mean we've added a quite manual set of steps i.e. from #61

./paket/paket.bootstrapper.exe
paket.exe install

Perhaps we could trigger those conditionally in the FSCharting.fsx? I'm thinking from a new user perspective who may have used a installer and not even know what Paket is.

[tpetricek]

Many of the auto-generated load scripts (including the FsLab one) add #I for locations that might not exist (FsLab does that for NuGet directory layout and Paket directory layout).

You can add #nowarn "211" to disable the warning - but it has to be run before the interaction that causes the errors.

[cgravill]

To avoid the manual steps, I've made a pull request npmurphy#6 where I reference Paket.Core.dll and fetch the dependencies at install time. This is probably a nicer solution as it leads to exposing the Paket api to users of the Notebook which would be a great way to get additional dependencies.

@tpetricek I tried moving the #nowarn "211" to the very top the of the fsx but it seems like fsi reads ahead, is that right? Would we have to turn off this warning before calling this?

As a more severe approach I've commented out those lines. On Windows with above Paket install that gets the required dlls in place to have a warning-free charting experience. Could you please check if that's OK elsewhere @npmurphy?

[cgravill]

Great, thanks for tidying up the changes and adding to documentation. This change might cause a bit of temporary disruption for people with existing notebooks and FSCharting dependency (now removed from include.fsx, and you now need to call #load FSCharting.fsx or #load FSCharting.gtk.fsx). However, this allows us to extend support to Mac and Linux users and allow Windows users to update their FSCharting.

I'll merge this to the Jupyter branch now.

[npmurphy]

This will require a lot of testing to make sure it works.
Here is some example code

#load "FSCharting.fsx" // Windows
//#load "FSCharting.Gtk.fsx" // Linux/Mac requires FSCharting to use unstable Oxyplot version. IfSharp.FSCharting.Initialize()
let data = [ ("F#", 10); ("C#", 5); ("C++", 20); ("Java", 1); ]
FSharp.Charting.Chart.Bar(data) |> Display

[cgravill]

Do you mean:
#load "FSCharting.fsx" // Windows

We wouldn't want to force a GTK dependency on Windows users.

[cgravill]

That works for me on Windows too. I do get confusing warning:

The directory it's looking in is quite off, is the line as intended here:

#I "../../../bin/packages/FSharp.Charting/lib/net40"

I do think switching to Paket is overall a good change. It does mean we've added a quite manual set of steps i.e. from #61

./paket/paket.bootstrapper.exe
paket.exe install

Perhaps we could trigger those conditionally in the FSCharting.fsx? I'm thinking from a new user perspective who may have used a installer and not even know what Paket is.

[tpetricek]

Many of the auto-generated load scripts (including the FsLab one) add #I for locations that might not exist (FsLab does that for NuGet directory layout and Paket directory layout).

You can add #nowarn "211" to disable the warning - but it has to be run before the interaction that causes the errors.

[cgravill]

To avoid the manual steps, I've made a pull request npmurphy#6 where I reference Paket.Core.dll and fetch the dependencies at install time. This is probably a nicer solution as it leads to exposing the Paket api to users of the Notebook which would be a great way to get additional dependencies.

@tpetricek I tried moving the #nowarn "211" to the very top the of the fsx but it seems like fsi reads ahead, is that right? Would we have to turn off this warning before calling this?

As a more severe approach I've commented out those lines. On Windows with above Paket install that gets the required dlls in place to have a warning-free charting experience. Could you please check if that's OK elsewhere @npmurphy?

[cgravill]

Great, thanks for tidying up the changes and adding to documentation. This change might cause a bit of temporary disruption for people with existing notebooks and FSCharting dependency (now removed from include.fsx, and you now need to call #load FSCharting.fsx or #load FSCharting.gtk.fsx). However, this allows us to extend support to Mac and Linux users and allow Windows users to update their FSCharting.

I'll merge this to the Jupyter branch now.

[npmurphy]

This will require a lot of testing to make sure it works.
Here is some example code

#load "FSCharting.fsx" // Windows
//#load "FSCharting.Gtk.fsx" // Linux/Mac requires FSCharting to use unstable Oxyplot version. IfSharp.FSCharting.Initialize()
let data = [ ("F#", 10); ("C#", 5); ("C++", 20); ("Java", 1); ]
FSharp.Charting.Chart.Bar(data) |> Display

[cgravill]

Do you mean:
#load "FSCharting.fsx" // Windows

We wouldn't want to force a GTK dependency on Windows users.

[cgravill]

That works for me on Windows too. I do get confusing warning:

The directory it's looking in is quite off, is the line as intended here:

#I "../../../bin/packages/FSharp.Charting/lib/net40"

I do think switching to Paket is overall a good change. It does mean we've added a quite manual set of steps i.e. from #61

./paket/paket.bootstrapper.exe
paket.exe install

Perhaps we could trigger those conditionally in the FSCharting.fsx? I'm thinking from a new user perspective who may have used a installer and not even know what Paket is.

[tpetricek]

Many of the auto-generated load scripts (including the FsLab one) add #I for locations that might not exist (FsLab does that for NuGet directory layout and Paket directory layout).

You can add #nowarn "211" to disable the warning - but it has to be run before the interaction that causes the errors.

[cgravill]

To avoid the manual steps, I've made a pull request npmurphy#6 where I reference Paket.Core.dll and fetch the dependencies at install time. This is probably a nicer solution as it leads to exposing the Paket api to users of the Notebook which would be a great way to get additional dependencies.

@tpetricek I tried moving the #nowarn "211" to the very top the of the fsx but it seems like fsi reads ahead, is that right? Would we have to turn off this warning before calling this?

As a more severe approach I've commented out those lines. On Windows with above Paket install that gets the required dlls in place to have a warning-free charting experience. Could you please check if that's OK elsewhere @npmurphy?

[cgravill]

Great, thanks for tidying up the changes and adding to documentation. This change might cause a bit of temporary disruption for people with existing notebooks and FSCharting dependency (now removed from include.fsx, and you now need to call #load FSCharting.fsx or #load FSCharting.gtk.fsx). However, this allows us to extend support to Mac and Linux users and allow Windows users to update their FSCharting.

I'll merge this to the Jupyter branch now.

[npmurphy]

This will require a lot of testing to make sure it works.
Here is some example code

#load "FSCharting.fsx" // Windows
//#load "FSCharting.Gtk.fsx" // Linux/Mac requires FSCharting to use unstable Oxyplot version. IfSharp.FSCharting.Initialize()
let data = [ ("F#", 10); ("C#", 5); ("C++", 20); ("Java", 1); ]
FSharp.Charting.Chart.Bar(data) |> Display

[cgravill]

Do you mean:
#load "FSCharting.fsx" // Windows

We wouldn't want to force a GTK dependency on Windows users.

[cgravill]

That works for me on Windows too. I do get confusing warning:

The directory it's looking in is quite off, is the line as intended here:

#I "../../../bin/packages/FSharp.Charting/lib/net40"

I do think switching to Paket is overall a good change. It does mean we've added a quite manual set of steps i.e. from #61

./paket/paket.bootstrapper.exe
paket.exe install

Perhaps we could trigger those conditionally in the FSCharting.fsx? I'm thinking from a new user perspective who may have used a installer and not even know what Paket is.

[tpetricek]

Many of the auto-generated load scripts (including the FsLab one) add #I for locations that might not exist (FsLab does that for NuGet directory layout and Paket directory layout).

You can add #nowarn "211" to disable the warning - but it has to be run before the interaction that causes the errors.

[cgravill]

To avoid the manual steps, I've made a pull request npmurphy#6 where I reference Paket.Core.dll and fetch the dependencies at install time. This is probably a nicer solution as it leads to exposing the Paket api to users of the Notebook which would be a great way to get additional dependencies.

@tpetricek I tried moving the #nowarn "211" to the very top the of the fsx but it seems like fsi reads ahead, is that right? Would we have to turn off this warning before calling this?

As a more severe approach I've commented out those lines. On Windows with above Paket install that gets the required dlls in place to have a warning-free charting experience. Could you please check if that's OK elsewhere @npmurphy?

[cgravill]

Great, thanks for tidying up the changes and adding to documentation. This change might cause a bit of temporary disruption for people with existing notebooks and FSCharting dependency (now removed from include.fsx, and you now need to call #load FSCharting.fsx or #load FSCharting.gtk.fsx). However, this allows us to extend support to Mac and Linux users and allow Windows users to update their FSCharting.

I'll merge this to the Jupyter branch now.

[npmurphy]

This will require a lot of testing to make sure it works.
Here is some example code

#load "FSCharting.fsx" // Windows
//#load "FSCharting.Gtk.fsx" // Linux/Mac requires FSCharting to use unstable Oxyplot version. IfSharp.FSCharting.Initialize()
let data = [ ("F#", 10); ("C#", 5); ("C++", 20); ("Java", 1); ]
FSharp.Charting.Chart.Bar(data) |> Display

[cgravill]

Do you mean:
#load "FSCharting.fsx" // Windows

We wouldn't want to force a GTK dependency on Windows users.

[cgravill]

That works for me on Windows too. I do get confusing warning:

The directory it's looking in is quite off, is the line as intended here:

#I "../../../bin/packages/FSharp.Charting/lib/net40"

I do think switching to Paket is overall a good change. It does mean we've added a quite manual set of steps i.e. from #61

./paket/paket.bootstrapper.exe
paket.exe install

Perhaps we could trigger those conditionally in the FSCharting.fsx? I'm thinking from a new user perspective who may have used a installer and not even know what Paket is.

[tpetricek]

Many of the auto-generated load scripts (including the FsLab one) add #I for locations that might not exist (FsLab does that for NuGet directory layout and Paket directory layout).

You can add #nowarn "211" to disable the warning - but it has to be run before the interaction that causes the errors.

[cgravill]

To avoid the manual steps, I've made a pull request npmurphy#6 where I reference Paket.Core.dll and fetch the dependencies at install time. This is probably a nicer solution as it leads to exposing the Paket api to users of the Notebook which would be a great way to get additional dependencies.

@tpetricek I tried moving the #nowarn "211" to the very top the of the fsx but it seems like fsi reads ahead, is that right? Would we have to turn off this warning before calling this?

As a more severe approach I've commented out those lines. On Windows with above Paket install that gets the required dlls in place to have a warning-free charting experience. Could you please check if that's OK elsewhere @npmurphy?

[cgravill]

Great, thanks for tidying up the changes and adding to documentation. This change might cause a bit of temporary disruption for people with existing notebooks and FSCharting dependency (now removed from include.fsx, and you now need to call #load FSCharting.fsx or #load FSCharting.gtk.fsx). However, this allows us to extend support to Mac and Linux users and allow Windows users to update their FSCharting.

I'll merge this to the Jupyter branch now.