Live data from Hacker News

JupyterLab is ready for users

blog.jupyter.org

201–210 of 250 posts

Re: JupyterLab is ready for users

#201
post #4

Mathematica is wonderful in terms of sheer computational power, but the notebook interface it presents is hopelessly outclassed nowadays by initiatives such as these. I keep hoping Wolfram will spring some impressive new interface on us that will enhance usability for power users (rather than their weird attempts at bringing ‘computation’ to random casual users), but... I'm giving up hope. This looks very impressive.

Nowadays, the Mathematica Notebook is probably Mathematica's biggest brake. For me the GUI feels slow on any computer. However, as already mentioned in the other posts, under the hood Mathematica has not yet been beaten for it's LISP attemp of computer algebra. The biggest contrahent in the Julia/SciPy environment is probably the SAGEmath computer algebra system, however it follows more the route of Maple which is more natural to the employed Python host/meta/binding language but (for me) does not feel as powerful as Mathematica when it comes to symbolic computing.

I think the big advantage of Julia against Mathematica is the modern software stack and the bleeding edge technology they can embed very quickly, such as d3js, WebGL, etc.. The web world is moving quickly and the scientific python community can keep up while Mathematica moves only very slowly -- note they started their web interface (cloud version) only a few years ago.

Re: JupyterLab is ready for users

#203
post #21

This is really exciting for the team! However I don't think that I am particularly sold on the notebook style of coding.. its possible that I simply haven't found a good use case for it, can anyone suggest an example where the notebook style outperforms a simple script based style? For reference, I use Matlab and Mathematica pretty heavily, and python in a text editor like sublime along with a terminal running ipytho…

I find notebooks to be great for prototyping longer pipelines or processes. Instead of having to constantly get fresh data, particularly if it's from an external API, the notebook can persist the data in memory and you can iterate on the next piece of the process right there. I then take that and make it a more formal script/process w/ version control and all that fun stuff. They're also really great for learning. I…

I'm still not sold personally—it seems like the in-memory persistence is only useful for the intermediate case where my data is slow enough to generate/obtain that I don't want to run the code every time to do so, but fast enough that I don't mind running it every time I launch the editor. Most of the data I have that's worth caching due to speed is worth caching to disk. Combined with unpredictable side effects of variables persisting whilst I'm actively hacking on the code and implicit in-memory persistence is pretty off-putting.

A recent workflow I've had for a data analysis project is to have each stage of data processing in a separate function, with all the functions called in order from an " if __name__ == '__main__'" block, with all but the function I'm presently working on commented out. Each function returns nothing, but saves its data to an HDF5 file. Other functions read the inputs they need from the HDF5 file and write their outputs to the same file, and if I want a fresh run I just delete the file, uncomment everything in the '__main__' block and run again.

The functions also save output plots to subfolders.

This is compatible with version control, and caching on disk rather than just in memory.

The biggest downside compared to Jupyter notebooks is lack of interactivity in the saved plots (I can make interactive plots pop up of course but they're all in separate windows all at once so it's less clear which part of the code each plot came from), and lack of LaTeX in code comments - I still will have external LaTeX documents explaining what algorithm I'm using somewhere.

So for now, the downsides of notebooks with respect to version control, data caching and extra state that I have to remember in order to not hit subtle bugs in my code as I hack on it, seem to outweigh the upsides.

Maybe what I would like is an editor that renders LaTeX in comments, and which embeds arbitrary plot windows at given points in the code, but without any data persistence, and without the embedded plots actually being saved anywhere - your file is still a normal Python file and it's just the editor rendering things that way based on magic comments or something.

Or maybe I should just write a decorator that renders a function's docstring as LaTeX and embeds any matplotlib windows produced into one scrolling document with the sections named after the decorated functions. Decorator could take an argument telling it whether to include the full source of the function, the comments of which it could also render as LaTeX. Then you have input code compatible with your favourite text editor and version control, and an output document which optionally includes the code.

Re: JupyterLab is ready for users

#204
I am going to ask a very dumb question, but if I am not an exploratory data scientist, what and how do i use jupyter/ipython for? I keep meaning to try it out but never quite got round to anything but toy stuff.

how does it fit into a developer workflow, or do i need a different mindset?

what should I try to do with this beta to get my mind right is probably the best question

Re: JupyterLab is ready for users

#205
post #147

Earlier quoted context omitted.

Are you referring to editing text files or in notebooks?

I'm interested in any jupyter workflows that allow me to use my text editor and a terminal-based language REPL/shell. In general, - I want to use my text editor to write any non-trivial function/class implementations. - I want any substantial amount of code to be held and version-controlled in regular files of code, not inside JSON. - I want to use the notebook for display (tables, figures, rendered markdown/LaTeX, e…

> How do I start a terminal-based REPL/shell that is sharing the same kernel as the notebook? (Relevant to text editors, because this might be for example an ipython shell running inside emacs, allowing me to easily evaluate fragments of code in the text editor.)

FYI, if you want to do both things inside of JupyterLab, you can easily start a console in JupyterLab connected to the same kernel as the notebook in three different ways: right-click in the notebook and select "New console for notebook". Or from the notebook, select the main menu File>"New Console For Notebook". Or simply start a console from the File>New menu and choose the notebook's kernel from the dropdown.

Re: JupyterLab is ready for users

#206

I'm trying to get a JupyterHub or JupyterLab instance deployed at my university. JupyterHub has documentation on deployment, authentication (e.g,. LDAP, CAS), and so on. I'm guessing that JupyterLab will eventually get things like this. Does anyone know if there will be a migration path for JupyterHub to JupyterLab?

Read this: https://zero-to-jupyterhub.readthedocs.io/en/latest/ then see the "Customization Guide" section has a instruction on how to setup lab by default.

Re: JupyterLab is ready for users

#207
post #143

Give me collaborative editing please. It's a great potential feature for pair programming or instructing with Jupyter.

Have you tried https://github.com/jupyterlab/jupyterlab-google-drive ?

Unfortunately Google retired the Google Drive API, so you can't create new application the use RT. So while it works, there is no point in releasing it.

Re: JupyterLab is ready for users

#208

I'll be teaching a group of nine and ten years olds to code. I'm planning on using Jupyter. What I'd really like to do is make a multiplayer naval game, with each player controlling their ship from their own notebook. Players would start out by running commands like fire(range=400, bearing=120) right from a cell, but would later be able automate their ship - for example, pick the nearest enemy, get the range, and plu…

Your question relates more to IPython Kernel than Jupyter per se. Fortunately ipykernel has out of the box integration with event loops, e.g. https://github.com/ipython/ipykernel/blob/master/ipykernel/e... for asyncio integration, and you can then schedule cell updates on the asyncio event loop as you would normally. To have events on the Python side generate visible updates in the Jupyter notebook you can use ipywidgets, for which the Python widget state in the kernel is automatically synchronized to the JavaScript widget state.

Re: JupyterLab is ready for users

#209

Does anybody knows if with JupyterLab I will be able to keep some code running, close the browser, and still get the output of the code afterwards? For what I know, currently I have to keep the browser open if I want to capture the output of a cell.

If you update the `notebook` package there should be a workaround. Messages will be buffered on server-side until a client reconnect. It is still not perfect, but get part of the way. One long term plan is to have server-side model (not sure if it will be by default, or an extension), and have the browser just be a vue on this. It is quite hard to design as many visualisation libraries assume to be in a browser conte…

Buffering is indeed helpful, but will not solve the problem. I always thought that a proxy server holding the current state and sending diffs to clients would be enough, but it would still have issues with visualization libs. Is there somewhere were this issue can be discussed and addressed? GitHub?

Re: JupyterLab is ready for users

#210

Earlier quoted context omitted.

If you update the `notebook` package there should be a workaround. Messages will be buffered on server-side until a client reconnect. It is still not perfect, but get part of the way. One long term plan is to have server-side model (not sure if it will be by default, or an extension), and have the browser just be a vue on this. It is quite hard to design as many visualisation libraries assume to be in a browser conte…

Buffering is indeed helpful, but will not solve the problem. I always thought that a proxy server holding the current state and sending diffs to clients would be enough, but it would still have issues with visualization libs. Is there somewhere were this issue can be discussed and addressed? GitHub?

There are a couple of issues about that, a bit scattered around. And many moving pieces. I agree that a proxy would be a nice thing, and IIRC someone made a prototype. This also hook into the JupyterLab "StateDB"/"modeldb" work and making it CRDT (Conflict-free Replicated Data Types) which is WIP somewhere; but I'm not sure where the best place is to discuss this. Work may happen on jupyter/notebook , jupyterlab/jupyterlab or maybe even https://github.com/phosphorjs/phosphor I would take my chance on the main mailing list/google group.
Post reply on HN