[jupyter] Re: Ironing out some issues with nbextension/serverextensions in notebook 5.0 and 4.x

[Brian Granger]

And to answer my own questions:

* Consistent handling of sys-prefix, system and user options
  - Which is default?
  - Which has priority?
  - How are they combined into the final config
* Make it easy to disable or uninstall all extensions for system/sys-prefix/user

Cheers,

Brian


On Thu, Dec 22, 2016 at 2:32 PM, Brian Granger  wrote:
> Hi all,
>
> We have just released notebook 4.3.1 and are starting to look towards
> a notebook 5.0 release. We have a number of small issues related to
> the installation and enabling of nextensions and serverextensions in
> the 4.x release series and 5.0/master.
>
> Because the notebook 5.0 will likely be the first notebook release to
> simultaneously support jupyterlab 1.0, I think it is important to iron
> out some of these problems before its release.
>
> Here are the currently open issues that I know of related to this:
>
> https://github.com/jupyter/notebook/issues/1992
> https://github.com/jupyter/notebook/issues/1797
> https://github.com/jupyter/notebook/issues/1706
> https://github.com/jupyter/notebook/issues/1617
> https://github.com/jupyter/notebook/issues/1508
>
> I would like to have a video meeting about these issues after the new
> year. In the meantime, let's use this email thread to try to better
> understand the big picture of what needs to get done for 5.0.
>
> IMPORTANT: I know we are wanting to move towards a completely
> different approach (the so called "conf.d" approach), but I don't
> think we can delay notebook 5.0 for that release. Also recent work by
> Sylvain suggests we may want to wait to do that once the server is its
> own separate repo/project.
>
> Cheers,
>
> Brian
>
> --
> Brian E. Granger
> Associate Professor of Physics and Data Science
> Cal Poly State University, San Luis Obispo
> @ellisonbg on Twitter and GitHub
> bgran...@calpoly.edu and elliso...@gmail.com



-- 
Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgran...@calpoly.edu and elliso...@gmail.com

-- 
You received this message because you are subscribed to the Google Groups 
"Project Jupyter" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jupyter+unsubscr...@googlegroups.com.
To post to this group, send email to jupyter@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jupyter/CAH4pYpTTPKLGXbiA75KrRBF-JtUVM9Xe7c%2BtUWMJqF3J4WcZjQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[jupyter] Ironing out some issues with nbextension/serverextensions in notebook 5.0 and 4.x

[Brian Granger]

Hi all,

We have just released notebook 4.3.1 and are starting to look towards
a notebook 5.0 release. We have a number of small issues related to
the installation and enabling of nextensions and serverextensions in
the 4.x release series and 5.0/master.

Because the notebook 5.0 will likely be the first notebook release to
simultaneously support jupyterlab 1.0, I think it is important to iron
out some of these problems before its release.

Here are the currently open issues that I know of related to this:

https://github.com/jupyter/notebook/issues/1992
https://github.com/jupyter/notebook/issues/1797
https://github.com/jupyter/notebook/issues/1706
https://github.com/jupyter/notebook/issues/1617
https://github.com/jupyter/notebook/issues/1508

I would like to have a video meeting about these issues after the new
year. In the meantime, let's use this email thread to try to better
understand the big picture of what needs to get done for 5.0.

IMPORTANT: I know we are wanting to move towards a completely
different approach (the so called "conf.d" approach), but I don't
think we can delay notebook 5.0 for that release. Also recent work by
Sylvain suggests we may want to wait to do that once the server is its
own separate repo/project.

Cheers,

Brian

-- 
Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgran...@calpoly.edu and elliso...@gmail.com

-- 
You received this message because you are subscribed to the Google Groups 
"Project Jupyter" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jupyter+unsubscr...@googlegroups.com.
To post to this group, send email to jupyter@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jupyter/CAH4pYpQruqBVhj7ftLV_ZM4xaS1KvdgU1aSKab__6_TWeHzbrQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [jupyter] any close notification for widgets and cells?

[nleclercq . fr]

Hi Sylvain,
Je vois... So the best approach, for now, would be to hide the 'X' button 
and add a 'close' button to our widgets layout triggering the appropriate 
'thread exit' code on python side. Ok, it doesn't cover the 'cell closed' 
case but could help.
Thanks.
N.  


Le jeudi 22 décembre 2016 13:45:48 UTC+1, Sylvain Corlay a écrit :
>
> Hi Nicolas,
>
> I think that this would be a good think to do to handle the case when a 
> widget (model) is completely closed from the front-end. However, is it more 
> subtle than it sounds.
>
> Widgets implement a MVC pattern. The Widget object on the Python side is 
> synchronized with a Javascript "Model". The kernel has no notion of view, 
> or how many views exist for a given model. This design is a consequence of 
> the agnosticity of the architecture to the front-end. The kernel should not 
> know the nature of the (possibly multiple) clients that are connected to it.
>
> In the notebook, the X button only closes a view from the document. 
> Destroying a view does not mean that the widget model is destroyed and 
> triggers no action in the backend.
>
> Sylvain
>
>
> On Wed, Dec 21, 2016 at 12:17 AM,  
> wrote:
>
>> Hi all,
>>
>> I need to stop a thread running in the background when the associated 
>> interface (i.e. main ipywidget) is closed or when the associated cell is 
>> deleted. Not doing so would lead to a bunch of zombie threads after a 
>> while. So my questions are:
>>
>> Is there a way to be notified when the user click on close button of a 
>> ipywiget? 
>> I tried the 'observe' way but it doesn't seem to work - the callback is 
>> not called when I close the widget.
>>
>> As a workaround, hiding the 'X' button could also be a solution cause I 
>> can provide my own 'close' button. 
>> Is it possible to hide the default X button?
>>
>> Concerning the cells, is there a way to be notified when a specific cell 
>> is removed from the notebook? 
>>
>> Thanks for your help,
>> Nicolas
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Project Jupyter" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jupyter+u...@googlegroups.com .
>> To post to this group, send email to jup...@googlegroups.com 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jupyter/15ad43d9-cca1-477d-b917-3a55721b2472%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Project Jupyter" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jupyter+unsubscr...@googlegroups.com.
To post to this group, send email to jupyter@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jupyter/d1dfd51c-afea-4ecb-a238-c60a88dbe172%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [jupyter] Help me with the code issue in jupyter

[Vinayak Patankar]

alright bro

On Thursday, December 22, 2016 at 9:02:34 PM UTC+5:30, Vinayak Patankar 
wrote:
>
> i realised i used np.loadtext instead of np.loadtxt but still i have error 
> :(
> On Thursday, December 22, 2016 at 8:49:19 PM UTC+5:30, Vinayak Patankar 
> wrote:
>>
>> Hi takeowl,
>> i have sent the screenshots..now the output is this...but the graph has 
>> not plotted my data its just a empty graph with a error message
>>
>>
>>
>> On Thursday, De c22, 2016 at 1:10:33 AM UTC+5:30, takowl wrote:
>>>
>>> You're calling the function inside the function definition. None of the 
>>> code inside the function runs until you call it, and that includes the call 
>>> to the function you just added.
>>>
>>> In Python, indentation defines what's inside a function (or a loop, or 
>>> an if block...). So unindent your graphRawFX() call so that it's at the 
>>> left hand edge of the cell.
>>>
>>> On 21 December 2016 at 18:58, Vinayak Patankar  
>>> wrote:
>>>
 *Hi *takowl ,
  I Tried that as well but still it doesnt work...i have attached a 
 screenshot to my code..

 On Wednesday, December 21, 2016 at 10:10:21 PM UTC+5:30, takowl wrote:
>
> Hi Vinayak,
>
> On 21 December 2016 at 13:50, Vinayak Patankar  > wrote:
>
>> def graphRawFX():
>
>
> Your code defines a function, but it never runs that function. After 
> definining the function, you need to call it:
>
> graphRawFX()
>
 -- 
 You received this message because you are subscribed to the Google 
 Groups "Project Jupyter" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to jupyter+u...@googlegroups.com.
 To post to this group, send email to jup...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jupyter/e1a6cdfc-c2ab-4a36-841d-da150a78a008%40googlegroups.com
  
 
 .

 For more options, visit https://groups.google.com/d/optout.

>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Project Jupyter" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jupyter+unsubscr...@googlegroups.com.
To post to this group, send email to jupyter@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jupyter/0427ada3-a68d-4037-babf-f0c594f5aa56%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [jupyter] Re: Clarification of the widget landscape

[Brad]

Hi Brian,

Thank you for the advice.

It sounds like we should first see how far we can go with ipywidgets. 

Is there a way of monitoring progress on this front to see what 
developments and API changes take place?
Would it be appropriate to request a certain widget type if we foresee that 
it may have utility outside of our project?

My sincere thanks to all of you who are involved in developing and 
improving the Jupyter platform so that it can continue to grow as a 
powerful and flexible platform for scientific exploration and other 
applications. 

Kind regards,
Brad

On Tuesday, December 20, 2016 at 2:22:26 PM UTC-7, ellisonbg wrote:
>
> Brad, 
>
> Great question. Nick has done a great job and answering this question 
> and providing a lot of background. I wanted to fill in a few other 
> aspects that may help you decide what fits for you and where things 
> are headed. 
>
> In general, there are a number of factors that go into where the 
> project is headed: 
>
> * The planning and roadmap work from the core project contributors 
> about where we want to go 
> * Which of the various options are attracting users 
> * Which of the various options are attracting developers 
> * Which of the various options have funding to hire developers 
> * etc. 
>
> On all of these fronts, I think ipywidgets is the best bet: 
>
> * It has the largest number of users of the various options and has 
> been around the longest 
> * We have funding to work on it 
> * There are a number of core developers putting a lot of time into it 
> * There are a number of third parties building on top of it 
> * It continues to be our top priority on the roadmap in this area 
>
> The other thing to note is that much of what you describe in your 
> original question can be done with ipywidgets out of the box. In other 
> words, you can probably get a lot done by importing ipywidgets and 
> using it - without diving into JavaScript and building custom widgets. 
>
> I should mention though that ipywidgets is going through a phase of 
> massive change and development right now. Because of this, lots of 
> internal details will change over the next year. However, we are 
> working hard to make sure  the Python APIs change minimally, if at 
> all. But even on the JavaScript side, we are working hard to minimize 
> the changes needed. The good news, is that all of the work being done 
> reflects the fact that ipywidgets is moving quickly and getting a lot 
> of improvements. 
>
> Hope this helps. 
>
> Cheers, 
>
> Brian 
>
> On Mon, Dec 19, 2016 at 8:33 AM, Nicholas Bollweg 
>  wrote: 
> > Brad: 
> > 
> > Thanks for the interest! 
> > 
> > We're excited to help you do really cool things with notebooks, widgets, 
> > etc. I guess it depends on what you mean by "application." Do you want 
> > something that lives "close" to the notebook, such that a scientist can 
> use 
> > it during their work, with full access to kernels, etc. or is it a 
> "display" 
> > that just shows information? Or a SaaS? Or a presentation? Or actually a 
> > "dashboard" on a device?! 
> > 
> > With those questions in mind, I'll answer your last question first: 
> > 
> >> I would also be grateful for pointers to any resources that you think 
> >> would be useful in understanding this landscape. 
> > 
> > 
> > I just updated this example to the newer APIs, based on this very dated 
> > example. This is more of a "replace the old broken computer next to my 
> > scientific equipment," rather than "what is the scheduling status of 
> this 
> > machine?" On the API maturity side, it took about five minutes to get it 
> > working, which isn't that bad considering two years had elapsed, in 
> which we 
> > split everything up, and have done many releases of every component! I 
> can 
> > vouch for python-driven widgets being a sound way to build up rich, 
> > maintainable GUIs! 
> > 
> > Here is a recent talk I did at PyData ATL (sorry, no recording) which is 
> > arguably an application, in that it is (a number of) live coding 
> > environment(s). In that talk, to make matters worse, I use nbpresent, as 
> > another way of laying out notebook content, including widgets (sort of a 
> > sibling/competitor to Jupyter Dashboards). 
> > 
> > Ok, to your specific stuff: 
> > 
> >> IPython widgets 
> > 
> > 
> > ipywidgets is (historically) the reference implementation of Jupyter 
> > Widgets. 
> > 
> > When you install the python module of ipywidgets, it also updates some 
> > JavaScript (jupyter-js-widgets), which is loaded into the notebook. 
> > 
> > For many kinds of interactive computing activities, you might not need 
> to 
> > write any JavaScript, CSS and HTML, and get the full complement of GUI 
> > stand-bys: buttons, sliders, layouts, etc. With a little bit of CSS 
> > knowledge (written in a pythonic way), you can have pretty attractive 
> > content. See the example at the beginning! 
> > 
> >> Jupyter declarative widgets 
> > 
> > 
> > 

[jupyter] Re: Clarification of the widget landscape

[Brad]

Hi Nicholas,

Thank you very much for the detailed explanation. It is greatly appreciated.

FYI, our application will be something that scientists (not necessarily 
experienced programmers) will use to conduct simulations and data analyses. 
The users will interact with a browser-based UI, but most of the heavy-duty 
calculations will be performed using a simulation engine that will reside 
on the user's own machine or on a more powerful server. The Jupyter 
notebook by itself is a little too 'code centric' for the UI, so we need to 
build some tools and interface elements to allow the scientists to conduct 
studies with a minimal amount of coding on their part. We also anticipate 
that more sophisticated users may want to dive in and use elements like 
code cells for more specialized calculations. 

Kind regards,
Brad


On Monday, December 19, 2016 at 8:33:20 AM UTC-7, Nicholas Bollweg wrote:
>
> Brad:
>
> Thanks for the interest!
>
> We're excited to help you do really cool things with notebooks, widgets, 
> etc. I guess it depends on what you mean by "application." Do you want 
> something that lives "close" to the notebook, such that a scientist can use 
> it during their work, with full access to kernels, etc. or is it a 
> "display" that just shows information? Or a SaaS? Or a presentation? Or 
> actually a "dashboard" on a device?!
>
> With those questions in mind, I'll answer your last question first: 
>
> I would also be grateful for pointers to any resources that you think 
>> would be useful in understanding this landscape. 
>>
>
> I just updated this example 
>  
> to the newer APIs, based on this very dated example 
> . This is more of 
> a "replace the old broken computer next to my scientific equipment," rather 
> than "what is the scheduling status of this machine?" On the API maturity 
> side, it took about five minutes to get it working, which isn't that bad 
> considering two years had elapsed, in which we split everything up, and 
> have done many releases of every component! I can vouch for python-driven 
> widgets being a sound way to build up rich, maintainable GUIs!
>
> Here is a recent talk I did at PyData ATL 
>  (sorry, no recording) which 
> is arguably an application, in that it is (a number of) live coding 
> environment(s). In that talk, to make matters worse, I use nbpresent 
> , as another way of 
> laying out notebook content, including widgets (sort of a 
> sibling/competitor to Jupyter Dashboards 
> ).
>
> Ok, to your specific stuff:
>
> IPython widgets
>>
>
> ipywidgets  is (historically) the 
> reference implementation of Jupyter Widgets . 
>
> When you install the python module of ipywidgets, it also updates some 
> JavaScript (jupyter-js-widgets), which is loaded into the notebook.
>
> For many kinds of interactive computing activities, you might not need to 
> write any JavaScript, CSS and HTML, and get the full complement of GUI 
> stand-bys: buttons, sliders, layouts, etc. With a little bit of CSS 
> knowledge (written in a pythonic way), you can have pretty attractive 
> content. See the example at the beginning!
>
> Jupyter declarative widgets
>>
>  
> Declarative widgets gives access to the underlying widget API: Instead of 
> python, you're mainly writing HTML and JavaScript 
> .
>  
> The bits and pieces gets installed via bower, yet another javascript 
> dependency management ecosystem, instead of a python-focused one.
>  
>
>> Jupyter dashboards
>>
>
> The Jupyter Dashboard 
>  
> has two components: the authoring tool and the server. The authoring tool 
> lets you *visually construct content* on a single-screen scrollable 
> dashboard, where the individual content pieces can be markdown, code, 
> output or *any widget* (including, therefore, declarative widgets... 
> though it does take some extra work), and *bundle* up the content. The 
> Server can accept these bundles, and *host* them in a relatively secure 
> way via Docker and clever proxies, and as such can be good for standing up 
> "hands-off" dashboards like kiosks and NOC/EOC kind of big displays.
>  
>
>> Polymer
>>
>
> Polymer is the mother-of-all polyfill 
> s for browsers that don't yet 
> support WebComponents... basically, you can use the future standard, today, 
> at the price of a pretty big slug of JavaScript monkeypatching your 
> environment, which is a totally normal practice, just that Polymer does a 
> LOT, because...
>  
>

Re: [jupyter] any close notification for widgets and cells?

[Sylvain Corlay]

Hi Nicolas,

I think that this would be a good think to do to handle the case when a
widget (model) is completely closed from the front-end. However, is it more
subtle than it sounds.

Widgets implement a MVC pattern. The Widget object on the Python side is
synchronized with a Javascript "Model". The kernel has no notion of view,
or how many views exist for a given model. This design is a consequence of
the agnosticity of the architecture to the front-end. The kernel should not
know the nature of the (possibly multiple) clients that are connected to it.

In the notebook, the X button only closes a view from the document.
Destroying a view does not mean that the widget model is destroyed and
triggers no action in the backend.

Sylvain


On Wed, Dec 21, 2016 at 12:17 AM,  wrote:

> Hi all,
>
> I need to stop a thread running in the background when the associated
> interface (i.e. main ipywidget) is closed or when the associated cell is
> deleted. Not doing so would lead to a bunch of zombie threads after a
> while. So my questions are:
>
> Is there a way to be notified when the user click on close button of a
> ipywiget?
> I tried the 'observe' way but it doesn't seem to work - the callback is
> not called when I close the widget.
>
> As a workaround, hiding the 'X' button could also be a solution cause I
> can provide my own 'close' button.
> Is it possible to hide the default X button?
>
> Concerning the cells, is there a way to be notified when a specific cell
> is removed from the notebook?
>
> Thanks for your help,
> Nicolas
>
> --
> You received this message because you are subscribed to the Google Groups
> "Project Jupyter" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jupyter+unsubscr...@googlegroups.com.
> To post to this group, send email to jupyter@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jupyter/15ad43d9-cca1-477d-b917-3a55721b2472%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Project Jupyter" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jupyter+unsubscr...@googlegroups.com.
To post to this group, send email to jupyter@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jupyter/CAK%3DPhk4GBk%2Bkrp1JFP1uyczsuG-dDSRXhnK%3Dz8UCnDeiLc8PnQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.