Proposed an alternative `CellList` for the notebook, which stores cells in a map, plus a vector for storing cell ordering. This should make storage in a model database backend easier, and handles some edge cases for undo/redo. jupyterlab/jupyterlab#1908
There's a large, open PR on state management and application restoration on page refreshes that should be finished within a day or so. If you want to follow along, there's an overview of the restoration lifecycle in the PR description: jupyterlab/jupyterlab#1291
Demos at Gateways 2016, NYU, PlotCon and multiple other venues (fperez, jason). Very well received, lots of interest for potential collaborations. Special thanks to Matt Rocklin & Luke Canavan for great Dask demo.
Ongoing work on the embedding of widgets with formal json spec for widget state + sphinx extension. (Widget state can be fully generated from python backend now, which will enable pure-python sphinx extensions)
We will be sending out a Request for Proposals (RFP) for the Technical Writer Contract position (1 year) If anyone knows an awesome tech writer who would be interested in submitting a proposal, please send me their contact info.
New approach: put a minus (-) next to your name if you would NOTlike to audibly share progress during the meeting. The moderator will start at the top of the Hackpad and call out those without a minus next to their name.
Would like us to discuss this technical topic all together during this meeting
We've never had *good* support for lists on the CLI, though you could cram them into list literals, e.g. `--Class.list_trait="['x', 'y']"`. This paves the way for proper list aliases, etc., but it will be hard to do without breaking the old, clunky way.
I think i volunteered indirectly to be the lab rat for this experiment last Friday. Once there's a bit more than the vanilla cookiecutter, I'd like to sit down and try to add something as simple as a ... button? menu item? ... and see how far I get. I probably could use what's there, but I'm sure I'd start struggling as soon as I wanted to do more than console.log.
Agreed. We should just make sure we look at it before we get close to a release. The principles of the design shouldn't be substantially different. Starting with LESS to get the ball rolling makes sense.
Also, I am trying to use very simple aspects of less that would be supported by basically any less preprocessor. The "API" aspects of our CSS are 1) class names (which won't change) and 2) the variable declarations (which will be a few dozen lines). But those things should be stable through major versions of JupyterLab
Proposal: Emulate what a desktop editor would do: aggressively save to a temporary file that can be recovered, and have a setting for an auto save interval to disk. "Checkpointing" should be done using version control. We should also periodically check for a file change on disk and ask to revert.
Documentation while I am gone: I will have the Cal Poly Developers monitor this site http://www.iheartjupyterdocs.org/for any doc build failures. I will ask them to file an issue if there is a broken build and ask the Jupyter team to rally as needed. Thanks!
Will attend JupyterDays Atlanta
Shout outs: Reese Netro for excellent work capturing notes and comments from JupyterHub conference on Friday. Ana for speaker mentoring and SciPy organization. Matthias Bussonnier for help with CPython issue tracker comments.