From takowl at gmail.com Fri Feb 1 06:40:58 2013 From: takowl at gmail.com (Thomas Kluyver) Date: Fri, 1 Feb 2013 11:40:58 +0000 Subject: [IPython-dev] IPython 0.13.1 with Notebook and Qt console working on smartphone In-Reply-To: <510B3CA8.4020005@gmail.com> References: <510B3CA8.4020005@gmail.com> Message-ID: On 1 February 2013 03:55, Roberto Colistete Jr. wrote: > I have also tested my Nokia N9 running IPython Notebook server and > web clients on many devices : PC's, Android tablets, Maemo 5/Nokia N900 > smartphone, etc. It works very well. As Nokia N9 has WiFi hotspot, we > can have a full IPython 0.13.1 in your pocket, accessible to any > computer/tablet/smartphone without IPython but with good web browser > (with websockets and MathJax support). > Nice work! It's a pity that Nokia ditched that line. Do you think it will be possible to apply the work to future boot2gecko, Sailfish, or Ubuntu phones? Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.colistete at gmail.com Fri Feb 1 08:42:35 2013 From: roberto.colistete at gmail.com (Roberto Colistete Jr.) Date: Fri, 01 Feb 2013 11:42:35 -0200 Subject: [IPython-dev] IPython 0.13.1 with Notebook and Qt console working on smartphone In-Reply-To: References: <510B3CA8.4020005@gmail.com> Message-ID: <510BC64B.8000504@gmail.com> Em 01-02-2013 09:40, Thomas Kluyver escreveu: > On 1 February 2013 03:55, Roberto Colistete Jr. > > wrote: > > I have also tested my Nokia N9 running IPython Notebook > server and > web clients on many devices : PC's, Android tablets, Maemo 5/Nokia > N900 > smartphone, etc. It works very well. As Nokia N9 has WiFi hotspot, we > can have a full IPython 0.13.1 in your pocket, accessible to any > computer/tablet/smartphone without IPython but with good web browser > (with websockets and MathJax support). > > > Nice work! It's a pity that Nokia ditched that line. Do you think it > will be possible to apply the work to future boot2gecko, Sailfish, or > Ubuntu phones? > > Thomas Nokia ceased to sell Nokia N9 in many countries in 2012, but it is still available in other countries, sometimes at low price. It is estimated that Nokia N9 sold some million units in 2011 and 2012, e.g., in 2011/Q4 it sold more (1.5-2 million units) than Nokia Lumia. So there is a good MeeGo Harmattan community worldwide, and typical real Linux mobile users keep using their devices for some years. Other current mobile OS : - AFAIK, there is no public IPython package to install on Android, BlackBerry OS, iOS, Symbian, Windows Phone; - Maemo 4 (Nokia N8x0) & Maemo 5 (Nokia N900) have IPython 0.10.2 : http://talk.maemo.org/showthread.php?p=1168357. About future in 2013/2014 : - Firefox OS (Boot2Gecko) : it doesn't support native (C/C++) development, neither Python. So no IPython, except if somebody releases Python running in HTML5... - Sailfish OS : uses Mer (successor of community MeeGo), plus UI and hardware adaptation from Jolla in Qt/Qt Quick. It already has Python 2.7.3 and some dependencies (readline5, python-pycurl, python-pygments) needed by IPython, but others (python-zmq, python-tornado, etc) need to be packaged. So IPython terminal console could be packaged as soon as the official Sailfish SDK is released (in 2013/Q1), IPython Qt console and IPython Notebook would need more work; - Ubuntu Phone OS : uses Ubuntu for ARM with a Qt/Qt Quick UI. It is expected that all packages from Ubuntu desktop without GUI will be available. Packages with GUI in GTK/QtWidget needed to be rewritten in Qt Quick. So IMHO IPython terminal console and IPython Notebook will be easily available. The complete Ubuntu Phone SDK will be released in the following weeks. I am waiting for Sailfish SDK and Ubuntu Phone SDK to start porting some Python modules and softwares : IPython, SymPy, etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.colistete at gmail.com Fri Feb 1 11:32:29 2013 From: roberto.colistete at gmail.com (Roberto Colistete Jr.) Date: Fri, 01 Feb 2013 14:32:29 -0200 Subject: [IPython-dev] Blog article "Scientific Python for computers, tablets and smartphones" In-Reply-To: References: <510B3CA8.4020005@gmail.com> Message-ID: <510BEE1D.1080109@gmail.com> I've updated my blog article comparing scientific Python tools for computers, tablets and smartphones : http://translate.google.com/translate?hl=pt-BR&sl=pt&tl=en&u=http%3A%2F%2Frobertocolistete.wordpress.com%2F2012%2F12%2F26%2Fpython-cientifico-em-computadores-tablets-e-smartphones%2F now IPython 0.13.1 with IPython Notebook and Qt console on MeeGo Harmattan OS is mentioned. The conclusion is very simple : real mobile Linux (with glibc, X11, dependencies, etc) are better for scientific Python. Like Maemo 5 OS and MeeGo Harmattan OS. And future Sailfish OS and Ubuntu Phone OS can follow the same path. From fperez.net at gmail.com Fri Feb 1 11:45:46 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 1 Feb 2013 17:45:46 +0100 Subject: [IPython-dev] Blog article "Scientific Python for computers, tablets and smartphones" In-Reply-To: <510BEE1D.1080109@gmail.com> References: <510B3CA8.4020005@gmail.com> <510BEE1D.1080109@gmail.com> Message-ID: Great, thanks! It's a shame that Nokia killed the MeeGo effort, it looked really promising... Cheers, f On Fri, Feb 1, 2013 at 5:32 PM, Roberto Colistete Jr. wrote: > I've updated my blog article comparing scientific Python tools for > computers, tablets and smartphones : > http://translate.google.com/translate?hl=pt-BR&sl=pt&tl=en&u=http%3A%2F%2Frobertocolistete.wordpress.com%2F2012%2F12%2F26%2Fpython-cientifico-em-computadores-tablets-e-smartphones%2F > now IPython 0.13.1 with IPython Notebook and Qt console on MeeGo > Harmattan OS is mentioned. > > The conclusion is very simple : real mobile Linux (with glibc, X11, > dependencies, etc) are better for scientific Python. Like Maemo 5 OS and > MeeGo Harmattan OS. And future Sailfish OS and Ubuntu Phone OS can > follow the same path. > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From fperez.net at gmail.com Fri Feb 1 11:47:59 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 1 Feb 2013 17:47:59 +0100 Subject: [IPython-dev] IPython 0.13.1 with Notebook and Qt console working on smartphone In-Reply-To: <510BC64B.8000504@gmail.com> References: <510B3CA8.4020005@gmail.com> <510BC64B.8000504@gmail.com> Message-ID: n Fri, Feb 1, 2013 at 2:42 PM, Roberto Colistete Jr. wrote: > I am waiting for Sailfish SDK and Ubuntu Phone SDK to start porting some > Python modules and softwares : IPython, SymPy, etc. keep us posted! Once this is ready we should update the site with links to this information; while a bit of a niche market I think it's great to promote this kind of work. Cheers, f From roberto.colistete at gmail.com Fri Feb 1 12:00:21 2013 From: roberto.colistete at gmail.com (Roberto Colistete Jr.) Date: Fri, 01 Feb 2013 15:00:21 -0200 Subject: [IPython-dev] IPython 0.13.1 with Notebook and Qt console working on smartphone In-Reply-To: References: <510B3CA8.4020005@gmail.com> <510BC64B.8000504@gmail.com> Message-ID: <510BF4A5.6080800@gmail.com> Em 01-02-2013 14:47, Fernando Perez escreveu: > n Fri, Feb 1, 2013 at 2:42 PM, Roberto Colistete Jr. > wrote: >> I am waiting for Sailfish SDK and Ubuntu Phone SDK to start porting some >> Python modules and softwares : IPython, SymPy, etc. > keep us posted! Once this is ready we should update the site with > links to this information; while a bit of a niche market I think it's > great to promote this kind of work. > > Cheers, > > f If you want, IPython 0.12.1 for Maemo and full IPython 0.13.1 for MeeGo Harmattan could be cited somewhere (in FAQ, Wiki, etc, of IPython.org). Links : IPython for Maemo (with 100-200 thousand downloads) : http://talk.maemo.org/showthread.php?p=1168357 IPython for MeeGo Harmattan (with estimated some thousand downloads) : http://talk.maemo.org/showthread.php?t=79997 From fperez.net at gmail.com Fri Feb 1 12:43:04 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 1 Feb 2013 18:43:04 +0100 Subject: [IPython-dev] IPython 0.13.1 with Notebook and Qt console working on smartphone In-Reply-To: <510BF4A5.6080800@gmail.com> References: <510B3CA8.4020005@gmail.com> <510BC64B.8000504@gmail.com> <510BF4A5.6080800@gmail.com> Message-ID: Thanks! I'm returning to the US next week and we'll have (finally!) an all-hands meeting to get going with the grant work, and doc/site updates are part of the job, so we'll update things with this and set up a location for similar info to go in the future. On Fri, Feb 1, 2013 at 6:00 PM, Roberto Colistete Jr. wrote: > If you want, IPython 0.12.1 for Maemo and full IPython 0.13.1 for > MeeGo Harmattan could be cited somewhere (in FAQ, Wiki, etc, of > IPython.org). Links : > IPython for Maemo (with 100-200 thousand downloads) : > http://talk.maemo.org/showthread.php?p=1168357 > IPython for MeeGo Harmattan (with estimated some thousand downloads) : > http://talk.maemo.org/showthread.php?t=79997 From carl.input at gmail.com Sat Feb 2 10:22:44 2013 From: carl.input at gmail.com (Carl Smith) Date: Sat, 2 Feb 2013 15:22:44 +0000 Subject: [IPython-dev] Blog article "Scientific Python for computers, tablets and smartphones" In-Reply-To: References: <510B3CA8.4020005@gmail.com> <510BEE1D.1080109@gmail.com> Message-ID: Ubuntu Phone looks really interesting for an OS to build on. I've been using Python on Android for a while, and it's a constant challenge to work around the limitations. I had a go at IPython on Android, but ended up using SL4A in Remote Mode to control the droid over WiFi from an instance of IPython Notebook, running on a regular box on the same network. It seems ok to run things like text editors off-board anyway. If you're hacking a mobile phone, you really want to do that in a desktop environment and only have the code you've written actually running on the phone. You can even run the program off-board and have the runtime access the device with RPC style calls over the local network, which is how SL4A does Remote Mode. The problem is getting a nice environment running that has ready access to all the features of a mobile device. Most distros don't support telephony or any of the sensors. I like hacking toy robots so I really need those sensors. Thanks for this information Roberto. It's slightly off topic, but you may find this project interesting. The top link is to a paper that explains things a bit. http://opendatakit.org/about/research/ Cheers Carl From fperez.net at gmail.com Sat Feb 2 16:29:29 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 2 Feb 2013 22:29:29 +0100 Subject: [IPython-dev] Blog article "Scientific Python for computers, tablets and smartphones" In-Reply-To: References: <510B3CA8.4020005@gmail.com> <510BEE1D.1080109@gmail.com> Message-ID: It would be great if you guys who know the ins and outs of Python/IPython running natively on the various mobile platforms added a bit of this info to the wiki: https://github.com/ipython/ipython/wiki That's the kind of thing that is good to record on a wiki so it's more easily found by others in the future. Cheers, f On Sat, Feb 2, 2013 at 4:22 PM, Carl Smith wrote: > Ubuntu Phone looks really interesting for an OS to build on. I've been > using Python on Android for a while, and it's a constant challenge to > work around the limitations. I had a go at IPython on Android, but > ended up using SL4A in Remote Mode to control the droid over WiFi from > an instance of IPython Notebook, running on a regular box on the same > network. > > It seems ok to run things like text editors off-board anyway. If > you're hacking a mobile phone, you really want to do that in a desktop > environment and only have the code you've written actually running on > the phone. You can even run the program off-board and have the runtime > access the device with RPC style calls over the local network, which > is how SL4A does Remote Mode. > > The problem is getting a nice environment running that has ready > access to all the features of a mobile device. Most distros don't > support telephony or any of the sensors. I like hacking toy robots so > I really need those sensors. > > Thanks for this information Roberto. It's slightly off topic, but you > may find this project interesting. The top link is to a paper that > explains things a bit. > > http://opendatakit.org/about/research/ > > Cheers > > Carl > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From benjaminrk at gmail.com Sat Feb 2 20:29:04 2013 From: benjaminrk at gmail.com (MinRK) Date: Sat, 2 Feb 2013 17:29:04 -0800 Subject: [IPython-dev] IPython Notebook on PyPy Message-ID: I refactored pyzmq a bit this month, so that the low-level Cython code exposing libzmq is a 'backend', while all the fun Pythony extras live in pure Python subclasses. This made way for Felipe Cruz contributing a CFFI backend with minimal code duplication. I just merged his PR, with the result that the IPython Notebook now works just fine on PyPy. Requires: - PyZMQ master (a release should come later this month) - cffi, py, ctypes-configure (pip will grab them as dependencies) - libzmq 3.2 (PyZMQ's building libzmq as an extension is not yet supported on PyPy) -MinRK -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.colistete at gmail.com Sun Feb 3 15:11:45 2013 From: roberto.colistete at gmail.com (Roberto Colistete Jr.) Date: Sun, 03 Feb 2013 18:11:45 -0200 Subject: [IPython-dev] IPython 0.13.1 Notebook server on smartphone In-Reply-To: <510B3CA8.4020005@gmail.com> References: <510B3CA8.4020005@gmail.com> Message-ID: <510EC481.5060604@gmail.com> Here my post about a smartphone Nokia N9 as IPython Notebook server : http://talk.maemo.org/showpost.php?p=1320465&postcount=19 My tests included : - 4 web clients at once, 2 notebooks, 1 Android tablet and 1 Nokia N900 smartphone, see : http://talk.maemo.org/showpost.php?p=1320501&postcount=6 - many types of mobile web browsers on Android, Maemo 4&5 and Symbian, besides PC's. So AFAIK, currently we can run IPython Notebook server on : - PC's with Linux, Mac OS, Windows; - mini-PC's running Linux (costing from US$30-40); - smartphone Nokia N9 with MeeGo Harmattan OS; - Android tablet Aakash, it costs US$35 : http://scipy.in/static/files/slides/python-on-aakash.pdf - Linux chroot on tablets/smartphones with Maemo/MeeGo, rooted Android devices, etc. -------- Mensagem original -------- Assunto: IPython 0.13.1 with Notebook and Qt console working on smartphone Data: Fri, 01 Feb 2013 01:55:20 -0200 De: Roberto Colistete Jr. Para: IPython developers list I have also tested my Nokia N9 running IPython Notebook server and web clients on many devices : PC's, Android tablets, Maemo 5/Nokia N900 smartphone, etc. It works very well. As Nokia N9 has WiFi hotspot, we can have a full IPython 0.13.1 in your pocket, accessible to any computer/tablet/smartphone without IPython but with good web browser (with websockets and MathJax support). -------------- next part -------------- An HTML attachment was scrubbed... URL: From bussonniermatthias at gmail.com Sun Feb 3 15:17:11 2013 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Sun, 3 Feb 2013 21:17:11 +0100 Subject: [IPython-dev] IPython 0.13.1 Notebook server on smartphone In-Reply-To: <510EC481.5060604@gmail.com> References: <510B3CA8.4020005@gmail.com> <510EC481.5060604@gmail.com> Message-ID: <615B48A8-63AC-499C-9D83-BF255F1068BA@gmail.com> Le 3 f?vr. 2013 ? 21:11, Roberto Colistete Jr. a ?crit : > Here my post about a smartphone Nokia N9 as IPython Notebook server : > http://talk.maemo.org/showpost.php?p=1320465&postcount=19 > My tests included : > - 4 web clients at once, 2 notebooks, 1 Android tablet and 1 Nokia N900 smartphone, see : > http://talk.maemo.org/showpost.php?p=1320501&postcount=6 > - many types of mobile web browsers on Android, Maemo 4&5 and Symbian, besides PC's. Using new cell toolbar / toolbar It should be possible to add an 'edit' button on top of each cell to avoid the code<->markdown convert process. You have the doc here : http://elacave.lmdb.eu/~carreau/yui/classes/IPython.CellToolbar.html And using custom.js allows to do it without modifying IPython internals. -- Matthias From roberto.colistete at gmail.com Sun Feb 3 15:51:18 2013 From: roberto.colistete at gmail.com (Roberto Colistete Jr.) Date: Sun, 03 Feb 2013 18:51:18 -0200 Subject: [IPython-dev] IPython 0.13.1 Notebook server on smartphone In-Reply-To: <615B48A8-63AC-499C-9D83-BF255F1068BA@gmail.com> References: <510B3CA8.4020005@gmail.com> <510EC481.5060604@gmail.com> <615B48A8-63AC-499C-9D83-BF255F1068BA@gmail.com> Message-ID: <510ECDC6.4000500@gmail.com> Em 03-02-2013 18:17, Matthias BUSSONNIER escreveu: > Le 3 f?vr. 2013 ? 21:11, Roberto Colistete Jr. a ?crit : > >> Here my post about a smartphone Nokia N9 as IPython Notebook server : >> http://talk.maemo.org/showpost.php?p=1320465&postcount=19 >> My tests included : >> - 4 web clients at once, 2 notebooks, 1 Android tablet and 1 Nokia N900 smartphone, see : >> http://talk.maemo.org/showpost.php?p=1320501&postcount=6 >> - many types of mobile web browsers on Android, Maemo 4&5 and Symbian, besides PC's. > Using new cell toolbar / toolbar > It should be possible to add an 'edit' button on top of each cell to avoid the code<->markdown convert process. > You have the doc here : > http://elacave.lmdb.eu/~carreau/yui/classes/IPython.CellToolbar.html > > And using custom.js allows to do it without modifying IPython internals. Nice suggestion to have an edit button on each cell. When a notebook is large, it takes a lot of scrolling to reach the IPython Notebook menu and toolbar. From roberto.colistete at gmail.com Sun Feb 3 15:59:57 2013 From: roberto.colistete at gmail.com (Roberto Colistete Jr.) Date: Sun, 03 Feb 2013 18:59:57 -0200 Subject: [IPython-dev] IPython Notebook for mobile web clients ? In-Reply-To: <510EC481.5060604@gmail.com> References: <510EC481.5060604@gmail.com> Message-ID: <510ECFCD.7030300@gmail.com> Citing the link below : http://talk.maemo.org/showpost.php?p=1320465&postcount=19 We see that Android Chrome web browser works very well as IPython Notebook web client, and possibly some iOS web browsers also work ok. Other mobile OS, like mobile Linux Maemo 5 and MeeGo Harmattan, also have good web browsers for IPython Notebook use. Summing up all the current devices (smartphones, tablets, Mini-PC's, etc) with Android, iOS, Maemo/MeeGo, etc, we have some hundreds millions of potential web clients for IPython Notebook. It is estimated 2013 will have more tablets sold than notebooks, while we already have more smartphones every year than PC's (desktops + notebooks). These mobile devices for web clients, some of them in very cheap hardware, can be ideal to schools, universities, at home, etc, where servers with IPython Notebook can also use cheap devices (see email below). My suggestion is to take into account this huge number of devices which can be web clients of IPython Notebooks. So the User Interface (UI) should have the option to be more mobile friendly, e.g. : - font and window sizes to better fit mobile screens, e.g, with typical 800-1024 pixels for width, maybe an option "--mobile" could be added to "ipython notebook"; - have more options to edit a non-code cell, because double tap doesn't edit it in touch devices due to being filtered by touch web browsers to zoom in/out. For example, add an "Edit" item in "Edit" or "Cell" menu, as well as an "Edit" icon in the toolbar; - put the "Keyboard shortcuts" window on the left or easier to move, because in touch devices is impossible or hard to move it. -------- Mensagem original -------- Assunto: IPython 0.13.1 Notebook server on smartphone Data: Sun, 03 Feb 2013 18:11:45 -0200 De: Roberto Colistete Jr. Para: IPython developers list Here my post about a smartphone Nokia N9 as IPython Notebook server : http://talk.maemo.org/showpost.php?p=1320465&postcount=19 My tests included : - 4 web clients at once, 2 notebooks, 1 Android tablet and 1 Nokia N900 smartphone, see : http://talk.maemo.org/showpost.php?p=1320501&postcount=6 - many types of mobile web browsers on Android, Maemo 4&5 and Symbian, besides PC's. So AFAIK, currently we can run IPython Notebook server on : - PC's with Linux, Mac OS, Windows; - mini-PC's running Linux (costing from US$30-40); - smartphone Nokia N9 with MeeGo Harmattan OS; - Android tablet Aakash, it costs US$35 : http://scipy.in/static/files/slides/python-on-aakash.pdf - Linux chroot on tablets/smartphones with Maemo/MeeGo, rooted Android devices, etc. -------- Mensagem original -------- Assunto: IPython 0.13.1 with Notebook and Qt console working on smartphone Data: Fri, 01 Feb 2013 01:55:20 -0200 De: Roberto Colistete Jr. Para: IPython developers list I have also tested my Nokia N9 running IPython Notebook server and web clients on many devices : PC's, Android tablets, Maemo 5/Nokia N900 smartphone, etc. It works very well. As Nokia N9 has WiFi hotspot, we can have a full IPython 0.13.1 in your pocket, accessible to any computer/tablet/smartphone without IPython but with good web browser (with websockets and MathJax support). -------------- next part -------------- An HTML attachment was scrubbed... URL: From asmeurer at gmail.com Sun Feb 3 16:05:12 2013 From: asmeurer at gmail.com (Aaron Meurer) Date: Sun, 3 Feb 2013 14:05:12 -0700 Subject: [IPython-dev] IPython Notebook for mobile web clients ? In-Reply-To: <510ECFCD.7030300@gmail.com> References: <510EC481.5060604@gmail.com> <510ECFCD.7030300@gmail.com> Message-ID: <-3396486623161672781@unknownmsgid> On Feb 3, 2013, at 2:00 PM, "Roberto Colistete Jr." < roberto.colistete at gmail.com> wrote: Citing the link below : http://talk.maemo.org/showpost.php?p=1320465&postcount=19 We see that Android Chrome web browser works very well as IPython Notebook web client, and possibly some iOS web browsers also work ok. Other mobile OS, like mobile Linux Maemo 5 and MeeGo Harmattan, also have good web browsers for IPython Notebook use. Summing up all the current devices (smartphones, tablets, Mini-PC's, etc) with Android, iOS, Maemo/MeeGo, etc, we have some hundreds millions of potential web clients for IPython Notebook. It is estimated 2013 will have more tablets sold than notebooks, while we already have more smartphones every year than PC's (desktops + notebooks). These mobile devices for web clients, some of them in very cheap hardware, can be ideal to schools, universities, at home, etc, where servers with IPython Notebook can also use cheap devices (see email below). My suggestion is to take into account this huge number of devices which can be web clients of IPython Notebooks. So the User Interface (UI) should have the option to be more mobile friendly, e.g. : - font and window sizes to better fit mobile screens, e.g, with typical 800-1024 pixels for width, maybe an option "--mobile" could be added to "ipython notebook"; - have more options to edit a non-code cell, because double tap doesn't edit it in touch devices due to being filtered by touch web browsers to zoom in/out. For example, add an "Edit" item in "Edit" or "Cell" menu, as well as an "Edit" icon in the toolbar; - put the "Keyboard shortcuts" window on the left or easier to move, because in touch devices is impossible or hard to move it. Also, things like Shift-Enter are impossible on most mobile keyboards. Aaron Meurer -------- Mensagem original -------- Assunto: IPython 0.13.1 Notebook server on smartphone Data: Sun, 03 Feb 2013 18:11:45 -0200 De: Roberto Colistete Jr. Para: IPython developers list Here my post about a smartphone Nokia N9 as IPython Notebook server : http://talk.maemo.org/showpost.php?p=1320465&postcount=19 My tests included : - 4 web clients at once, 2 notebooks, 1 Android tablet and 1 Nokia N900 smartphone, see : http://talk.maemo.org/showpost.php?p=1320501&postcount=6 - many types of mobile web browsers on Android, Maemo 4&5 and Symbian, besides PC's. So AFAIK, currently we can run IPython Notebook server on : - PC's with Linux, Mac OS, Windows; - mini-PC's running Linux (costing from US$30-40); - smartphone Nokia N9 with MeeGo Harmattan OS; - Android tablet Aakash, it costs US$35 : http://scipy.in/static/files/slides/python-on-aakash.pdf - Linux chroot on tablets/smartphones with Maemo/MeeGo, rooted Android devices, etc. -------- Mensagem original -------- Assunto: IPython 0.13.1 with Notebook and Qt console working on smartphone Data: Fri, 01 Feb 2013 01:55:20 -0200 De: Roberto Colistete Jr. Para: IPython developers list I have also tested my Nokia N9 running IPython Notebook server and web clients on many devices : PC's, Android tablets, Maemo 5/Nokia N900 smartphone, etc. It works very well. As Nokia N9 has WiFi hotspot, we can have a full IPython 0.13.1 in your pocket, accessible to any computer/tablet/smartphone without IPython but with good web browser (with websockets and MathJax support). _______________________________________________ IPython-dev mailing list IPython-dev at scipy.org http://mail.scipy.org/mailman/listinfo/ipython-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From carl.input at gmail.com Sun Feb 3 16:06:36 2013 From: carl.input at gmail.com (Carl Smith) Date: Sun, 3 Feb 2013 21:06:36 +0000 Subject: [IPython-dev] IPython 0.13.1 Notebook server on smartphone In-Reply-To: <510ECDC6.4000500@gmail.com> References: <510B3CA8.4020005@gmail.com> <510EC481.5060604@gmail.com> <615B48A8-63AC-499C-9D83-BF255F1068BA@gmail.com> <510ECDC6.4000500@gmail.com> Message-ID: The menu bar, at least optionally, should be thinner and fixed I reckon. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Sun Feb 3 17:36:35 2013 From: ellisonbg at gmail.com (Brian Granger) Date: Sun, 3 Feb 2013 14:36:35 -0800 Subject: [IPython-dev] IPython Notebook for mobile web clients ? In-Reply-To: <510ECFCD.7030300@gmail.com> References: <510EC481.5060604@gmail.com> <510ECFCD.7030300@gmail.com> Message-ID: We have mobile plans, but are just not there yet.... On Sun, Feb 3, 2013 at 12:59 PM, Roberto Colistete Jr. < roberto.colistete at gmail.com> wrote: > Citing the link below : > http://talk.maemo.org/showpost.php?p=1320465&postcount=19 > We see that Android Chrome web browser works very well as IPython Notebook > web client, and possibly some iOS web browsers also work ok. Other mobile > OS, like mobile Linux Maemo 5 and MeeGo Harmattan, also have good web > browsers for IPython Notebook use. > > Summing up all the current devices (smartphones, tablets, Mini-PC's, > etc) with Android, iOS, Maemo/MeeGo, etc, we have some hundreds millions of > potential web clients for IPython Notebook. It is estimated 2013 will have > more tablets sold than notebooks, while we already have more smartphones > every year than PC's (desktops + notebooks). > > These mobile devices for web clients, some of them in very cheap > hardware, can be ideal to schools, universities, at home, etc, where > servers with IPython Notebook can also use cheap devices (see email below). > > My suggestion is to take into account this huge number of devices > which can be web clients of IPython Notebooks. So the User Interface (UI) > should have the option to be more mobile friendly, e.g. : > - font and window sizes to better fit mobile screens, e.g, with typical > 800-1024 pixels for width, maybe an option "--mobile" could be added to > "ipython notebook"; > - have more options to edit a non-code cell, because double tap doesn't > edit it in touch devices due to being filtered by touch web browsers to > zoom in/out. For example, add an "Edit" item in "Edit" or "Cell" menu, as > well as an "Edit" icon in the toolbar; > - put the "Keyboard shortcuts" window on the left or easier to move, > because in touch devices is impossible or hard to move it. > > > -------- Mensagem original -------- Assunto: IPython 0.13.1 Notebook > server on smartphone Data: Sun, 03 Feb 2013 18:11:45 -0200 De: Roberto > Colistete Jr. Para: > IPython developers list > > Here my post about a smartphone Nokia N9 as IPython Notebook server : > http://talk.maemo.org/showpost.php?p=1320465&postcount=19 > My tests included : > - 4 web clients at once, 2 notebooks, 1 Android tablet and 1 Nokia N900 > smartphone, see : > http://talk.maemo.org/showpost.php?p=1320501&postcount=6 > - many types of mobile web browsers on Android, Maemo 4&5 and Symbian, > besides PC's. > > So AFAIK, currently we can run IPython Notebook server on : > - PC's with Linux, Mac OS, Windows; > - mini-PC's running Linux (costing from US$30-40); > - smartphone Nokia N9 with MeeGo Harmattan OS; > - Android tablet Aakash, it costs US$35 : > http://scipy.in/static/files/slides/python-on-aakash.pdf > - Linux chroot on tablets/smartphones with Maemo/MeeGo, rooted Android > devices, etc. > > > -------- Mensagem original -------- Assunto: IPython 0.13.1 with > Notebook and Qt console working on smartphone Data: Fri, 01 Feb 2013 > 01:55:20 -0200 De: Roberto Colistete Jr. Para: > IPython developers list > I have also tested my Nokia N9 running IPython Notebook server and web > clients on many devices : PC's, Android tablets, Maemo 5/Nokia N900 > smartphone, etc. It works very well. As Nokia N9 has WiFi hotspot, we can > have a full IPython 0.13.1 in your pocket, accessible to any > computer/tablet/smartphone without IPython but with good web browser (with > websockets and MathJax support). > > > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.colistete at gmail.com Sun Feb 3 19:10:29 2013 From: roberto.colistete at gmail.com (Roberto Colistete Jr.) Date: Sun, 03 Feb 2013 22:10:29 -0200 Subject: [IPython-dev] Blog article "Scientific Python for computers, tablets and smartphones" In-Reply-To: References: <510B3CA8.4020005@gmail.com> <510BEE1D.1080109@gmail.com> Message-ID: <510EFC75.5010809@gmail.com> I've added an item "IPython for Mobile OS" to the IPython Wiki (https://github.com/ipython/ipython/wiki). Feel free to revise. Maemo & MeeGo were cited, as well as Aakash Android tablet. But I haven't found details about IPython on Aakash : which version, if there is a working IPython terminal, etc. IPython Notebook web client use on mobile OS is also commented. See : https://github.com/ipython/ipython/wiki/IPython-for-Mobile-OS If anybody has tested iOS, BlackBerry OS, Windows Mobile/Phone OS, etc, web browsers as good IPython Notebook web clients, please contribute to the above Wiki. Em 02-02-2013 19:29, Fernando Perez escreveu: > It would be great if you guys who know the ins and outs of > Python/IPython running natively on the various mobile platforms added > a bit of this info to the wiki: > > https://github.com/ipython/ipython/wiki > > That's the kind of thing that is good to record on a wiki so it's more > easily found by others in the future. > > Cheers, > > f > > On Sat, Feb 2, 2013 at 4:22 PM, Carl Smith wrote: >> Ubuntu Phone looks really interesting for an OS to build on. I've been >> using Python on Android for a while, and it's a constant challenge to >> work around the limitations. I had a go at IPython on Android, but >> ended up using SL4A in Remote Mode to control the droid over WiFi from >> an instance of IPython Notebook, running on a regular box on the same >> network. >> >> It seems ok to run things like text editors off-board anyway. If >> you're hacking a mobile phone, you really want to do that in a desktop >> environment and only have the code you've written actually running on >> the phone. You can even run the program off-board and have the runtime >> access the device with RPC style calls over the local network, which >> is how SL4A does Remote Mode. >> >> The problem is getting a nice environment running that has ready >> access to all the features of a mobile device. Most distros don't >> support telephony or any of the sensors. I like hacking toy robots so >> I really need those sensors. >> >> Thanks for this information Roberto. It's slightly off topic, but you >> may find this project interesting. The top link is to a paper that >> explains things a bit. >> >> http://opendatakit.org/about/research/ >> >> Cheers >> >> Carl >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From bussonniermatthias at gmail.com Mon Feb 4 12:24:00 2013 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Mon, 4 Feb 2013 18:24:00 +0100 Subject: [IPython-dev] IPython 0.13.1 Notebook server on smartphone In-Reply-To: References: <510B3CA8.4020005@gmail.com> <510EC481.5060604@gmail.com> <615B48A8-63AC-499C-9D83-BF255F1068BA@gmail.com> <510ECDC6.4000500@gmail.com> Message-ID: <2314E433-69A6-4FD8-A383-1587C07473E3@gmail.com> Le 3 f?vr. 2013 ? 22:06, Carl Smith a ?crit : > The menu bar, at least optionally, should be thinner and fixed I reckon. > I'm not an expert on mobile web d?veloppement, but it seem to me that in mobile browser you don't have this notion of page "scrolling". Browser seem to have a damned high page and you are actually moving the all page? so you can't have something fixed at the top, or at least you have to develop an UI especially for the mobiles browser -- Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Mon Feb 4 15:38:49 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 4 Feb 2013 12:38:49 -0800 Subject: [IPython-dev] Blog article "Scientific Python for computers, tablets and smartphones" In-Reply-To: <510EFC75.5010809@gmail.com> References: <510B3CA8.4020005@gmail.com> <510BEE1D.1080109@gmail.com> <510EFC75.5010809@gmail.com> Message-ID: n Sun, Feb 3, 2013 at 4:10 PM, Roberto Colistete Jr. wrote: > I've added an item "IPython for Mobile OS" to the IPython Wiki > (https://github.com/ipython/ipython/wiki). Feel free to revise. > Thanks! Having this started is perfect, it will improve over time. Best f From fperez.net at gmail.com Mon Feb 4 15:47:20 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 4 Feb 2013 12:47:20 -0800 Subject: [IPython-dev] IPython Notebook for mobile web clients ? In-Reply-To: <-3396486623161672781@unknownmsgid> References: <510EC481.5060604@gmail.com> <510ECFCD.7030300@gmail.com> <-3396486623161672781@unknownmsgid> Message-ID: On Sun, Feb 3, 2013 at 1:05 PM, Aaron Meurer wrote: > - have more options to edit a non-code cell, because double tap doesn't > edit it in touch devices due to being filtered by touch web browsers to > zoom in/out. For example, add an "Edit" item in "Edit" or "Cell" menu, as > well as an "Edit" icon in the toolbar; > > Also, things like Shift-Enter are impossible on most mobile keyboards. Fortunately our toolbar always exposes the 'play' button that does Shift-Enter, so it seems to me that the only show-stopper for mobile editing is an 'Edit' icon. Is that the case? While, as Brian mentioned, full mobile support is a ways off, if we could make a simple tweak to the existing code that *allows* for mobile use (albeit with a sub-par UI), it would already help a lot of early adopters start using the notebook. So having a list of the minimal blockers that can be fixed easily would be useful. Cheers, f -------------- next part -------------- An HTML attachment was scrubbed... URL: From bussonniermatthias at gmail.com Mon Feb 4 16:17:43 2013 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Mon, 4 Feb 2013 22:17:43 +0100 Subject: [IPython-dev] IPython Notebook for mobile web clients ? In-Reply-To: References: <510EC481.5060604@gmail.com> <510ECFCD.7030300@gmail.com> <-3396486623161672781@unknownmsgid> Message-ID: <4AC8252D-7D65-467B-8506-7EE4FEE2133F@gmail.com> Le 4 f?vr. 2013 ? 21:47, Fernando Perez a ?crit : > On Sun, Feb 3, 2013 at 1:05 PM, Aaron Meurer wrote: >> - have more options to edit a non-code cell, because double tap doesn't edit it in touch devices due to being filtered by touch web browsers to zoom in/out. For example, add an "Edit" item in "Edit" or "Cell" menu, as well as an "Edit" icon in the toolbar; > Also, things like Shift-Enter are impossible on most mobile keyboards. > > Fortunately our toolbar always exposes the 'play' button that does Shift-Enter, so it seems to me that the only show-stopper for mobile editing is an 'Edit' icon. Use the snippet at the end of this mail to add an "Edit" button to each "CellToolBar" (select the "Mobile" Preset in the main toolbar) It will need a CSS fix that will be released soon (need to be written though) to look nice. > Is that the case? While, as Brian mentioned, full mobile support is a ways off, if we could make a simple tweak to the existing code that *allows* for mobile use (albeit with a sub-par UI), it would already help a lot of early adopters start using the notebook. No need to tweak anymore ! (you can also add button in the MainToolbar if you whish) Cf example http://elacave.lmdb.eu/~carreau/yui/classes/IPython.ToolBar.html#method_add_buttons_group > > So having a list of the minimal blockers that can be fixed easily would be useful. Yes, We should open a Meta-Issue with a tasklist -- Matthias > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev In your custom.js ------ mobile_preset = [] var edit = function(div, cell) { var button_container = $(div); var button = $('
').button({icons:{primary:'ui-icon-pencil'}}); button.click(function(){ cell.edit() }) button_container.append(button); } IPython.CellToolbar.register_callback('mobile.edit',edit); mobile_preset.push('mobile.edit'); IPython.CellToolbar.register_preset('Mobile',mobile_preset); From wojtek.danilo.ml at gmail.com Tue Feb 5 00:08:40 2013 From: wojtek.danilo.ml at gmail.com (=?ISO-8859-2?Q?Wojciech_Dani=B3o?=) Date: Tue, 5 Feb 2013 06:08:40 +0100 Subject: [IPython-dev] IPython authentication Message-ID: Hi! I'm new to IPython, but this project seems like a very good "boilerplate" for my custom project. I've read a lot of docs and looked at the source code and I want to ask you if something I want to do with IPython is possible. I want to run a IPython Kernel on a machine. It will execute my batch program. I want users to be able to connect to this kernel (locally or over network) and execute Python code - everything so far is provided by IPython i think. The problem is, I want to know WHICH user executed the code, because I want to make something like collaboration model - If one user executes a code - lets say "draw line", I want this line t show in the second user GUI with a tooltip, which user executed it. Is it somehow possible? Could you give me any hints how to do it? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Tue Feb 5 00:28:44 2013 From: benjaminrk at gmail.com (MinRK) Date: Mon, 4 Feb 2013 21:28:44 -0800 Subject: [IPython-dev] IPython authentication In-Reply-To: References: Message-ID: On Mon, Feb 4, 2013 at 9:08 PM, Wojciech Dani?o wrote: > Hi! > I'm new to IPython, but this project seems like a very good "boilerplate" > for my custom project. I've read a lot of docs and looked at the source > code and I want to ask you if something I want to do with IPython is > possible. > > I want to run a IPython Kernel on a machine. It will execute my batch > program. I want users to be able to connect to this kernel (locally or over > network) and execute Python code - everything so far is provided by IPython > i think. > The problem is, I want to know WHICH user executed the code, because I > want to make something like collaboration model - If one user executes a > code - lets say "draw line", I want this line t show in the second user GUI > with a tooltip, which user executed it. > > Is it somehow possible? Could you give me any hints how to do it? > Messages have a 'session' key, which is unique, and a username in the header (generally the unix username). These are attributes of the Session object, so at the very least every frontend (aka client aka user session) has a unique ID. The header of each request is attached as the 'parent_header' of replies and side effects of the request. Among these side effects (of execute_requests) are: pyin: the Python code just run display_data: display side effects stream: stdout/stderr And these come to all frontends on the iopub channel. So let's say you have two frontends attached to the Kernel. When a 'pyin' message comes in on the iopub channel, and you check it, you can trigger an event based on the content and parent_header, such as "client [FOO] just ran this code: etc.". If you want to draw the display *results* of the execution, they will be `display_data` messages on the same channel, and you can associate them with their source in the same way. That should be all you need, I think. -MinRK -------------- next part -------------- An HTML attachment was scrubbed... URL: From wojtek.danilo.ml at gmail.com Tue Feb 5 00:44:56 2013 From: wojtek.danilo.ml at gmail.com (=?ISO-8859-2?Q?Wojciech_Dani=B3o?=) Date: Tue, 5 Feb 2013 06:44:56 +0100 Subject: [IPython-dev] IPython authentication In-Reply-To: References: Message-ID: Benjamin thank you very much for yours answer! I'm very happy that all the things are implemented - I'm starting to test these things out :) If I could I owuld ask you additional 2, a little more precious questions: 1) Lets concider we have kernel K and clients A and B. If client A executes something on K, I would like K to send notification about it to B (broadcast to clients) - I think youre talking about something like that (or am I wrong?). 2) Additional when A or B executes a command on K it will run some functions from my batch python module. Is it possible that these functions will broadcast some customized messages to client with the functionality provided by Kernel? So basically is it possible to send to Kernel and from Kernel to clients customized messages with custom fields etc (extend the handling mechanizm) or should I implement this next to the IPython communication mechanism (I do not want to implement that next to it, because that is a little bit ugly ;) ) Thank you once again! 2013/2/5 MinRK > > > On Mon, Feb 4, 2013 at 9:08 PM, Wojciech Dani?o < > wojtek.danilo.ml at gmail.com> wrote: > >> Hi! >> I'm new to IPython, but this project seems like a very good "boilerplate" >> for my custom project. I've read a lot of docs and looked at the source >> code and I want to ask you if something I want to do with IPython is >> possible. >> >> I want to run a IPython Kernel on a machine. It will execute my batch >> program. I want users to be able to connect to this kernel (locally or over >> network) and execute Python code - everything so far is provided by IPython >> i think. >> The problem is, I want to know WHICH user executed the code, because I >> want to make something like collaboration model - If one user executes a >> code - lets say "draw line", I want this line t show in the second user GUI >> with a tooltip, which user executed it. >> >> Is it somehow possible? Could you give me any hints how to do it? >> > > Messages have a 'session' key, which is unique, and a username in the > header (generally the unix username). These are attributes of the Session > object, so at the very least every frontend (aka client aka user session) > has a unique ID. The header of each request is attached as the > 'parent_header' of replies and side effects of the request. Among these > side effects (of execute_requests) are: > > pyin: the Python code just run > display_data: display side effects > stream: stdout/stderr > > And these come to all frontends on the iopub channel. > > So let's say you have two frontends attached to the Kernel. When a 'pyin' > message comes in on the iopub channel, and you check it, you can trigger an > event based on the content and parent_header, such as "client [FOO] just > ran this code: etc.". > > If you want to draw the display *results* of the execution, they will be > `display_data` messages on the same channel, and you can associate them > with their source in the same way. > > That should be all you need, I think. > > -MinRK > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Tue Feb 5 01:09:13 2013 From: benjaminrk at gmail.com (MinRK) Date: Mon, 4 Feb 2013 22:09:13 -0800 Subject: [IPython-dev] IPython authentication In-Reply-To: References: Message-ID: On Mon, Feb 4, 2013 at 9:44 PM, Wojciech Dani?o wrote: > Benjamin thank you very much for yours answer! I'm very happy that all the > things are implemented - I'm starting to test these things out :) > > If I could I owuld ask you additional 2, a little more precious questions: > 1) Lets concider we have kernel K and clients A and B. If client A > executes something on K, I would like K to send notification about it to B > (broadcast to clients) - I think youre talking about something like that > (or am I wrong?). > Yes, this is the `pyin` message. It is sent to all clients on the iopub channel when an execute_request begins (prior to evaluating that request). > 2) Additional when A or B executes a command on K it will run some > functions from my batch python module. Is it possible that these functions > will broadcast some customized messages to client with the functionality > provided by Kernel? > Yes, if you modify the kernel. You might be able to get away with just registering a `post_execute_hook` in IPython. > So basically is it possible to send to Kernel and from Kernel to clients > customized messages with custom fields etc (extend the handling mechanizm) > or should I implement this next to the IPython communication mechanism (I > do not want to implement that next to it, because that is a little bit ugly > ;) ) > I would recommend trying to use the existing functionality as best you can. In general, you would use: publisher = get_ipython().display_pub and publisher.publish("myapp", display_data) That should let you publish fairly arbitrary data to the clients. > > Thank you once again! > > 2013/2/5 MinRK > >> >> >> On Mon, Feb 4, 2013 at 9:08 PM, Wojciech Dani?o < >> wojtek.danilo.ml at gmail.com> wrote: >> >>> Hi! >>> I'm new to IPython, but this project seems like a very good >>> "boilerplate" for my custom project. I've read a lot of docs and looked at >>> the source code and I want to ask you if something I want to do with >>> IPython is possible. >>> >>> I want to run a IPython Kernel on a machine. It will execute my batch >>> program. I want users to be able to connect to this kernel (locally or over >>> network) and execute Python code - everything so far is provided by IPython >>> i think. >>> The problem is, I want to know WHICH user executed the code, because I >>> want to make something like collaboration model - If one user executes a >>> code - lets say "draw line", I want this line t show in the second user GUI >>> with a tooltip, which user executed it. >>> >>> Is it somehow possible? Could you give me any hints how to do it? >>> >> >> Messages have a 'session' key, which is unique, and a username in the >> header (generally the unix username). These are attributes of the Session >> object, so at the very least every frontend (aka client aka user session) >> has a unique ID. The header of each request is attached as the >> 'parent_header' of replies and side effects of the request. Among these >> side effects (of execute_requests) are: >> >> pyin: the Python code just run >> display_data: display side effects >> stream: stdout/stderr >> >> And these come to all frontends on the iopub channel. >> >> So let's say you have two frontends attached to the Kernel. When a >> 'pyin' message comes in on the iopub channel, and you check it, you can >> trigger an event based on the content and parent_header, such as "client >> [FOO] just ran this code: etc.". >> >> If you want to draw the display *results* of the execution, they will be >> `display_data` messages on the same channel, and you can associate them >> with their source in the same way. >> >> That should be all you need, I think. >> >> -MinRK >> >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev >> >> > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wojtek.danilo.ml at gmail.com Tue Feb 5 05:36:11 2013 From: wojtek.danilo.ml at gmail.com (=?ISO-8859-2?Q?Wojciech_Dani=B3o?=) Date: Tue, 5 Feb 2013 11:36:11 +0100 Subject: [IPython-dev] IPython authentication In-Reply-To: References: Message-ID: Thank you! All the informations provided by you are very useful for me. Would you please tell me one more thing? Is there any implemented mechanism for handling such situation, that each user will have custom "variable namespace" with several variables shared. I want simply keep each users locals variables separate, so If A user will type "a=5" and B user will type "a=6" these variables will not overlap. But if user A will type "batch.x=5", then user B is able to access this varbiale, since "batch" variable is shared between them. I know this is very special case and probably there is nothing implemented which is able to handle it, but maybe you'll be able to give me last portion of hints how to start with it. 2013/2/5, MinRK : > On Mon, Feb 4, 2013 at 9:44 PM, Wojciech Dani?o > wrote: > >> Benjamin thank you very much for yours answer! I'm very happy that all >> the >> things are implemented - I'm starting to test these things out :) >> >> If I could I owuld ask you additional 2, a little more precious >> questions: >> 1) Lets concider we have kernel K and clients A and B. If client A >> executes something on K, I would like K to send notification about it to >> B >> (broadcast to clients) - I think youre talking about something like that >> (or am I wrong?). >> > > Yes, this is the `pyin` message. It is sent to all clients on the iopub > channel when an execute_request begins (prior to evaluating that request). > > >> 2) Additional when A or B executes a command on K it will run some >> functions from my batch python module. Is it possible that these >> functions >> will broadcast some customized messages to client with the functionality >> provided by Kernel? >> > > Yes, if you modify the kernel. You might be able to get away with just > registering a `post_execute_hook` in IPython. > > >> So basically is it possible to send to Kernel and from Kernel to clients >> customized messages with custom fields etc (extend the handling >> mechanizm) >> or should I implement this next to the IPython communication mechanism (I >> do not want to implement that next to it, because that is a little bit >> ugly >> ;) ) >> > > I would recommend trying to use the existing functionality as best you can. > In general, you would use: > > publisher = get_ipython().display_pub > > and > > publisher.publish("myapp", display_data) > > That should let you publish fairly arbitrary data to the clients. > > > >> >> Thank you once again! >> >> 2013/2/5 MinRK >> >>> >>> >>> On Mon, Feb 4, 2013 at 9:08 PM, Wojciech Dani?o < >>> wojtek.danilo.ml at gmail.com> wrote: >>> >>>> Hi! >>>> I'm new to IPython, but this project seems like a very good >>>> "boilerplate" for my custom project. I've read a lot of docs and looked >>>> at >>>> the source code and I want to ask you if something I want to do with >>>> IPython is possible. >>>> >>>> I want to run a IPython Kernel on a machine. It will execute my batch >>>> program. I want users to be able to connect to this kernel (locally or >>>> over >>>> network) and execute Python code - everything so far is provided by >>>> IPython >>>> i think. >>>> The problem is, I want to know WHICH user executed the code, because I >>>> want to make something like collaboration model - If one user executes >>>> a >>>> code - lets say "draw line", I want this line t show in the second user >>>> GUI >>>> with a tooltip, which user executed it. >>>> >>>> Is it somehow possible? Could you give me any hints how to do it? >>>> >>> >>> Messages have a 'session' key, which is unique, and a username in the >>> header (generally the unix username). These are attributes of the >>> Session >>> object, so at the very least every frontend (aka client aka user >>> session) >>> has a unique ID. The header of each request is attached as the >>> 'parent_header' of replies and side effects of the request. Among these >>> side effects (of execute_requests) are: >>> >>> pyin: the Python code just run >>> display_data: display side effects >>> stream: stdout/stderr >>> >>> And these come to all frontends on the iopub channel. >>> >>> So let's say you have two frontends attached to the Kernel. When a >>> 'pyin' message comes in on the iopub channel, and you check it, you can >>> trigger an event based on the content and parent_header, such as "client >>> [FOO] just ran this code: etc.". >>> >>> If you want to draw the display *results* of the execution, they will be >>> `display_data` messages on the same channel, and you can associate them >>> with their source in the same way. >>> >>> That should be all you need, I think. >>> >>> -MinRK >>> >>> _______________________________________________ >>> IPython-dev mailing list >>> IPython-dev at scipy.org >>> http://mail.scipy.org/mailman/listinfo/ipython-dev >>> >>> >> >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev >> >> > From benjaminrk at gmail.com Tue Feb 5 12:33:02 2013 From: benjaminrk at gmail.com (MinRK) Date: Tue, 5 Feb 2013 09:33:02 -0800 Subject: [IPython-dev] IPython authentication In-Reply-To: References: Message-ID: On Tue, Feb 5, 2013 at 2:36 AM, Wojciech Dani?o wrote: > Thank you! All the informations provided by you are very useful for me. > > Would you please tell me one more thing? Is there any implemented > mechanism for handling such situation, that each user will have custom > "variable namespace" with several variables shared. > I want simply keep each users locals variables separate, so If A user > will type "a=5" and B user will type "a=6" these variables will not > overlap. But if user A will type "batch.x=5", then user B is able to > access this varbiale, since "batch" variable is shared between them. > I know this is very special case and probably there is nothing > implemented which is able to handle it, but maybe you'll be able to > give me last portion of hints how to start with it. > > No, this is not something IPython provides. If you were to do this, you would need to subclass the Kernel, and override execute_request to change the shell.user_ns based on the client that submits each request. > > 2013/2/5, MinRK : > > On Mon, Feb 4, 2013 at 9:44 PM, Wojciech Dani?o > > wrote: > > > >> Benjamin thank you very much for yours answer! I'm very happy that all > >> the > >> things are implemented - I'm starting to test these things out :) > >> > >> If I could I owuld ask you additional 2, a little more precious > >> questions: > >> 1) Lets concider we have kernel K and clients A and B. If client A > >> executes something on K, I would like K to send notification about it to > >> B > >> (broadcast to clients) - I think youre talking about something like that > >> (or am I wrong?). > >> > > > > Yes, this is the `pyin` message. It is sent to all clients on the iopub > > channel when an execute_request begins (prior to evaluating that > request). > > > > > >> 2) Additional when A or B executes a command on K it will run some > >> functions from my batch python module. Is it possible that these > >> functions > >> will broadcast some customized messages to client with the functionality > >> provided by Kernel? > >> > > > > Yes, if you modify the kernel. You might be able to get away with just > > registering a `post_execute_hook` in IPython. > > > > > >> So basically is it possible to send to Kernel and from Kernel to clients > >> customized messages with custom fields etc (extend the handling > >> mechanizm) > >> or should I implement this next to the IPython communication mechanism > (I > >> do not want to implement that next to it, because that is a little bit > >> ugly > >> ;) ) > >> > > > > I would recommend trying to use the existing functionality as best you > can. > > In general, you would use: > > > > publisher = get_ipython().display_pub > > > > and > > > > publisher.publish("myapp", display_data) > > > > That should let you publish fairly arbitrary data to the clients. > > > > > > > >> > >> Thank you once again! > >> > >> 2013/2/5 MinRK > >> > >>> > >>> > >>> On Mon, Feb 4, 2013 at 9:08 PM, Wojciech Dani?o < > >>> wojtek.danilo.ml at gmail.com> wrote: > >>> > >>>> Hi! > >>>> I'm new to IPython, but this project seems like a very good > >>>> "boilerplate" for my custom project. I've read a lot of docs and > looked > >>>> at > >>>> the source code and I want to ask you if something I want to do with > >>>> IPython is possible. > >>>> > >>>> I want to run a IPython Kernel on a machine. It will execute my batch > >>>> program. I want users to be able to connect to this kernel (locally or > >>>> over > >>>> network) and execute Python code - everything so far is provided by > >>>> IPython > >>>> i think. > >>>> The problem is, I want to know WHICH user executed the code, because I > >>>> want to make something like collaboration model - If one user executes > >>>> a > >>>> code - lets say "draw line", I want this line t show in the second > user > >>>> GUI > >>>> with a tooltip, which user executed it. > >>>> > >>>> Is it somehow possible? Could you give me any hints how to do it? > >>>> > >>> > >>> Messages have a 'session' key, which is unique, and a username in the > >>> header (generally the unix username). These are attributes of the > >>> Session > >>> object, so at the very least every frontend (aka client aka user > >>> session) > >>> has a unique ID. The header of each request is attached as the > >>> 'parent_header' of replies and side effects of the request. Among > these > >>> side effects (of execute_requests) are: > >>> > >>> pyin: the Python code just run > >>> display_data: display side effects > >>> stream: stdout/stderr > >>> > >>> And these come to all frontends on the iopub channel. > >>> > >>> So let's say you have two frontends attached to the Kernel. When a > >>> 'pyin' message comes in on the iopub channel, and you check it, you can > >>> trigger an event based on the content and parent_header, such as > "client > >>> [FOO] just ran this code: etc.". > >>> > >>> If you want to draw the display *results* of the execution, they will > be > >>> `display_data` messages on the same channel, and you can associate them > >>> with their source in the same way. > >>> > >>> That should be all you need, I think. > >>> > >>> -MinRK > >>> > >>> _______________________________________________ > >>> IPython-dev mailing list > >>> IPython-dev at scipy.org > >>> http://mail.scipy.org/mailman/listinfo/ipython-dev > >>> > >>> > >> > >> _______________________________________________ > >> IPython-dev mailing list > >> IPython-dev at scipy.org > >> http://mail.scipy.org/mailman/listinfo/ipython-dev > >> > >> > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adgaudio at gmail.com Wed Feb 6 11:47:22 2013 From: adgaudio at gmail.com (Alex Gaudio) Date: Wed, 6 Feb 2013 11:47:22 -0500 Subject: [IPython-dev] IPython + gevent compatibility Message-ID: Hello all, I did some research into how we could make IPython and gevent compatible with each other, and after some discussion on github, we decided the best way to integrate the two is execute a gevent.monkey patch in the IPython launcher (or earlier). As a follow-up to this, Thomas Kluyver suggested I ask you all the following question: Is anyone here be interested in IPython supporting a specific ipython_gevent launcher? It might look like this: # EASY-INSTALL-ENTRY-SCRIPT: 'ipython==0.13.1','console_scripts','ipython' __requires__ = 'ipython==0.13.1' import sys from pkg_resources import load_entry_point *import gevent.monkey ; gevent.monkey.patch_all()* *## monkey patch would be added here ##* sys.exit( load_entry_point('ipython==0.13.1', 'console_scripts', 'ipython')() ) Thanks for your time! Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Thu Feb 7 16:44:29 2013 From: takowl at gmail.com (Thomas Kluyver) Date: Thu, 7 Feb 2013 21:44:29 +0000 Subject: [IPython-dev] Line-based frontends - architecture Message-ID: Thinking about the possibility of developing a web console to complement the notebook, it struck me that the wire protocol doesn't yet provide for line-based frontends to know when the input is complete, to decide whether to execute or present another continuation prompt. With the Qt console, we avoid the issue by running the same input transformation machinery in the frontend, but that only works for frontends written in Python. I see three potential solutions to this: 1. Add a message type to the protocol, by which the frontend can send a block of code, and the kernel can indicate whether it is 'finished'. 2. Reimplement the logic to determine whether a code block is finished in the frontend. 3. Leave it up to the user, with separate key combinations for 'execute' and 'new line', as it is in the notebook. I prefer number 1. I think the console-like interaction is valuable enough to make 3 undesirable. 2 sounds like a lot of work, especially as we get both more frontends and more kernels for different languages, with different rules about when a block is complete. Thoughts? Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.voorhies at ucsf.edu Thu Feb 7 16:58:25 2013 From: mark.voorhies at ucsf.edu (Mark Voorhies) Date: Thu, 7 Feb 2013 13:58:25 -0800 Subject: [IPython-dev] Line-based frontends - architecture In-Reply-To: References: Message-ID: <51142381.3090301@ucsf.edu> On 02/07/2013 01:44 PM, Thomas Kluyver wrote: > Thinking about the possibility of developing a web console to complement > the notebook, it struck me that the wire protocol doesn't yet provide for > line-based frontends to know when the input is complete, to decide whether > to execute or present another continuation prompt. > > With the Qt console, we avoid the issue by running the same input > transformation machinery in the frontend, but that only works for frontends > written in Python. > > I see three potential solutions to this: > > 1. Add a message type to the protocol, by which the frontend can send a > block of code, and the kernel can indicate whether it is 'finished'. > 2. Reimplement the logic to determine whether a code block is finished in > the frontend. > 3. Leave it up to the user, with separate key combinations for 'execute' > and 'new line', as it is in the notebook. > > I prefer number 1. I think the console-like interaction is valuable enough > to make 3 undesirable. 2 sounds like a lot of work, especially as we get > both more frontends and more kernels for different languages, with > different rules about when a block is complete. > > Thoughts? "1" certainly seems cleanest. I think that there is room to complement it with "3": In the default python shell, there is the annoying behavior that blocks must be followed by an empty line (so that the shell knows that the block has been closed) and empty lines can't be used in unindented code (e.g., for style) without triggering execution; so, leaving the option for the user to distinguish between "next line" and "send to the kernel" in some shells is still useful (but compatible with "1"). --Mark > > Thanks, > Thomas > > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > From ellisonbg at gmail.com Thu Feb 7 17:28:40 2013 From: ellisonbg at gmail.com (Brian Granger) Date: Thu, 7 Feb 2013 14:28:40 -0800 Subject: [IPython-dev] Line-based frontends - architecture In-Reply-To: References: Message-ID: I don't think anything needs to be done at all. The problems with detecting a "finished" block of code arises only in environments that are truly line oriented. Browsers don't suffere from that limitation. On Thu, Feb 7, 2013 at 1:44 PM, Thomas Kluyver wrote: > Thinking about the possibility of developing a web console to complement the > notebook, it struck me that the wire protocol doesn't yet provide for > line-based frontends to know when the input is complete, to decide whether > to execute or present another continuation prompt. > > With the Qt console, we avoid the issue by running the same input > transformation machinery in the frontend, but that only works for frontends > written in Python. > > I see three potential solutions to this: > > 1. Add a message type to the protocol, by which the frontend can send a > block of code, and the kernel can indicate whether it is 'finished'. > 2. Reimplement the logic to determine whether a code block is finished in > the frontend. > 3. Leave it up to the user, with separate key combinations for 'execute' and > 'new line', as it is in the notebook. > > I prefer number 1. I think the console-like interaction is valuable enough > to make 3 undesirable. 2 sounds like a lot of work, especially as we get > both more frontends and more kernels for different languages, with different > rules about when a block is complete. > > Thoughts? > > Thanks, > Thomas > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From takowl at gmail.com Thu Feb 7 18:40:41 2013 From: takowl at gmail.com (Thomas Kluyver) Date: Thu, 7 Feb 2013 23:40:41 +0000 Subject: [IPython-dev] Line-based frontends - architecture In-Reply-To: References: Message-ID: On 7 February 2013 22:28, Brian Granger wrote: > I don't think anything needs to be done at all. The problems with > detecting a "finished" block of code arises only in environments that > are truly line oriented. Browsers don't suffere from that limitation. > I think it's a question of the user interface, not the display technology. If we want the same key to automatically do 'execute' or 'next line' as appropriate, we need a way of distinguishing which to do. In the notebook, we use shift-return/ctrl-return for execute, so it's not required. But for a console interface, having return automatically execute or produce another line is extremely convenient and intuitive. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Thu Feb 7 19:19:46 2013 From: ellisonbg at gmail.com (Brian Granger) Date: Thu, 7 Feb 2013 16:19:46 -0800 Subject: [IPython-dev] Line-based frontends - architecture In-Reply-To: References: Message-ID: But the double meaning of enter in the terminal based IPython is not a deliberate design choice - it is only due to the limitation of the terminal. Put another way - If the plain readline based terminal was able to detect shift-enter keyboard events, regular IPython, from day 1, would distinguish between enter (newline) and shit-enter (run code). Trying to override the meaning of enter to be two different things is not something we want to ever do unless we are absolutely forced to. Case in point - I have some private code that starts to implement a console style web UI for IPython - it still uses shift-enter to run code and the user experience is great... On Thu, Feb 7, 2013 at 3:40 PM, Thomas Kluyver wrote: > On 7 February 2013 22:28, Brian Granger wrote: >> >> I don't think anything needs to be done at all. The problems with >> detecting a "finished" block of code arises only in environments that >> are truly line oriented. Browsers don't suffere from that limitation. > > > I think it's a question of the user interface, not the display technology. > If we want the same key to automatically do 'execute' or 'next line' as > appropriate, we need a way of distinguishing which to do. In the notebook, > we use shift-return/ctrl-return for execute, so it's not required. But for a > console interface, having return automatically execute or produce another > line is extremely convenient and intuitive. > > Thomas > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com On Thu, Feb 7, 2013 at 3:40 PM, Thomas Kluyver wrote: > On 7 February 2013 22:28, Brian Granger wrote: >> >> I don't think anything needs to be done at all. The problems with >> detecting a "finished" block of code arises only in environments that >> are truly line oriented. Browsers don't suffere from that limitation. > > > I think it's a question of the user interface, not the display technology. > If we want the same key to automatically do 'execute' or 'next line' as > appropriate, we need a way of distinguishing which to do. In the notebook, > we use shift-return/ctrl-return for execute, so it's not required. But for a > console interface, having return automatically execute or produce another > line is extremely convenient and intuitive. > > Thomas > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From takowl at gmail.com Thu Feb 7 19:33:54 2013 From: takowl at gmail.com (Thomas Kluyver) Date: Fri, 8 Feb 2013 00:33:54 +0000 Subject: [IPython-dev] Line-based frontends - architecture In-Reply-To: References: Message-ID: On 8 February 2013 00:19, Brian Granger wrote: > But the double meaning of enter in the terminal based IPython is not a > deliberate design choice - it is only due to the limitation of the > terminal. Put another way - If the plain readline based terminal was > able to detect shift-enter keyboard events, regular IPython, from day > 1, would distinguish between enter (newline) and shit-enter (run > code). Trying to override the meaning of enter to be two different > things is not something we want to ever do unless we are absolutely > forced to. Case in point - I have some private code that starts to > implement a console style web UI for IPython - it still uses > shift-enter to run code and the user experience is great... > Counterexample: the Qt console. We can distinguish enter with modifier keys, but we choose to use the automatic execute/newline. Ctrl-enter forces a newline, overriding the automatic decision. For a console interface, where you're usually entering single lines of code, I think this behaviour is desirable. Every REPL I can bring to mind follows this pattern, whereas if it was merely a limitation of the technology, I would expect people to have long since worked around it. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.voorhies at ucsf.edu Thu Feb 7 19:49:59 2013 From: mark.voorhies at ucsf.edu (Mark Voorhies) Date: Thu, 7 Feb 2013 16:49:59 -0800 Subject: [IPython-dev] Line-based frontends - architecture In-Reply-To: References: Message-ID: <51144BB7.50903@ucsf.edu> On 02/07/2013 04:33 PM, Thomas Kluyver wrote: > On 8 February 2013 00:19, Brian Granger wrote: > >> But the double meaning of enter in the terminal based IPython is not a >> deliberate design choice - it is only due to the limitation of the >> terminal. Put another way - If the plain readline based terminal was >> able to detect shift-enter keyboard events, regular IPython, from day >> 1, would distinguish between enter (newline) and shit-enter (run >> code). Trying to override the meaning of enter to be two different >> things is not something we want to ever do unless we are absolutely >> forced to. Case in point - I have some private code that starts to >> implement a console style web UI for IPython - it still uses >> shift-enter to run code and the user experience is great... >> > > Counterexample: the Qt console. We can distinguish enter with modifier > keys, but we choose to use the automatic execute/newline. Ctrl-enter forces > a newline, overriding the automatic decision. > > For a console interface, where you're usually entering single lines of > code, I think this behaviour is desirable. Every REPL I can bring to mind > follows this pattern, whereas if it was merely a limitation of the > technology, I would expect people to have long since worked around it. > > Thomas ctrl-j = eval-print-last-sexp in Emacs Lisp Interaction mode (e.g., *scratch* buffer) is a possible counter to the counter. I think this would follow Brian's argument that a deliberate execute command is useful in a shell that can handle rich editing. --Mark From asmeurer at gmail.com Thu Feb 7 20:14:14 2013 From: asmeurer at gmail.com (Aaron Meurer) Date: Thu, 7 Feb 2013 18:14:14 -0700 Subject: [IPython-dev] Line-based frontends - architecture In-Reply-To: References: Message-ID: <4223153269814712158@unknownmsgid> On Feb 7, 2013, at 5:34 PM, Thomas Kluyver wrote: On 8 February 2013 00:19, Brian Granger wrote: > But the double meaning of enter in the terminal based IPython is not a > deliberate design choice - it is only due to the limitation of the > terminal. Put another way - If the plain readline based terminal was > able to detect shift-enter keyboard events, regular IPython, from day > 1, would distinguish between enter (newline) and shit-enter (run > code). Trying to override the meaning of enter to be two different > things is not something we want to ever do unless we are absolutely > forced to. Case in point - I have some private code that starts to > implement a console style web UI for IPython - it still uses > shift-enter to run code and the user experience is great... > Counterexample: the Qt console. We can distinguish enter with modifier keys, but we choose to use the automatic execute/newline. Ctrl-enter forces a newline, overriding the automatic decision. For a console interface, where you're usually entering single lines of code, I think this behaviour is desirable. Every REPL I can bring to mind follows this pattern, whereas if it was merely a limitation of the technology, I would expect people to have long since worked around it. Thomas So really you would just want to swap Enter and Shift-Enter in a web console. The point is that executing is the default. It has nothing to do with it being forced to also mean newline based on the context. Aaron Meurer -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Fri Feb 8 05:29:10 2013 From: takowl at gmail.com (Thomas Kluyver) Date: Fri, 8 Feb 2013 10:29:10 +0000 Subject: [IPython-dev] Line-based frontends - architecture In-Reply-To: <4223153269814712158@unknownmsgid> References: <4223153269814712158@unknownmsgid> Message-ID: On 8 February 2013 01:14, Aaron Meurer wrote: > So really you would just want to swap Enter and Shift-Enter in a web > console. The point is that executing is the default. It has nothing to do > with it being forced to also mean newline based on the context. No, that would be worse. You'd be happily using the console, and then you'd type 'a="""foo' or 'def f(x):', and instead of doing anything sensible, it would just throw a SyntaxError at you. I think the automatic newline/execute is simply the most convenient mechanism for a console. Using other consoles, I've never wanted to be forced to use separate keys (although there are cases where it's useful to override the automatic decision). Everything else sounds like a workaround for a console that's unable to tell whether my input is complete. And we don't need that: we can fairly easily add that capability, which we already use in the Qt console. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From satra at mit.edu Sun Feb 10 12:51:07 2013 From: satra at mit.edu (Satrajit Ghosh) Date: Sun, 10 Feb 2013 12:51:07 -0500 Subject: [IPython-dev] [off-topic] help solve a game theory/math challenge Message-ID: a friend of mine organized a challenge to determine strategies for winning in a game which simulates (at a very simplistic level) natural disasters. he asked me to see if a collaborative solution could be faster and better than the targeted solutions he is getting from people. i've summarized the challenge and there are links to ipython notebooks that simulate the game and a github repo for solving this here: http://satra.cogitatum.org/blog/2013/01/22/collaborativeproblemsolving/ if any of you have the spare cycles or know someone doing game theory who might have more cycles towards such problems, he would very much appreciate people coming forward together to solve it. cheers, satra -------------- next part -------------- An HTML attachment was scrubbed... URL: From massimodisasha at gmail.com Mon Feb 11 18:44:25 2013 From: massimodisasha at gmail.com (epi) Date: Mon, 11 Feb 2013 18:44:25 -0500 Subject: [IPython-dev] Fwd: Google Summer of Code 2013 References: Message-ID: FYI :-) Inizio messaggio inoltrato: >> From: Carol Smith >> Date: Mon, Feb 11, 2013 at 8:02 PM >> Subject: Google Summer of Code 2013 >> To: Google Summer of Code Announce >> >> >> Hi all, >> >> We're pleased to announce that Google Summer of Code will be happening for its ninth year this year. Please check out the blog post [1] about the program and read the FAQs [2] and Timeline [3] on Melange for more information. >> >> [1] - http://google-opensource.blogspot.com/2013/02/flip-bits-not-burgers-google-summer-of.html >> [2] - http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2013/help_page >> [3] - http://www.google-melange.com/gsoc/events/google/gsoc2013 >> >> Cheers, >> Carol -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Mon Feb 11 19:19:09 2013 From: takowl at gmail.com (Thomas Kluyver) Date: Tue, 12 Feb 2013 00:19:09 +0000 Subject: [IPython-dev] [IPython-User] Fwd: Google Summer of Code 2013 In-Reply-To: References: Message-ID: In previous years I know we've not done GSoC, because mentoring takes up quite a bit of time itself. But maybe with the grant supporting several people working on IPython, we could reconsider that. Thomas On 11 February 2013 23:44, epi wrote: > > FYI > > :-) > > Inizio messaggio inoltrato: > > From: Carol Smith > Date: Mon, Feb 11, 2013 at 8:02 PM > Subject: Google Summer of Code 2013 > To: Google Summer of Code Announce < > google-summer-of-code-announce at googlegroups.com> > > > Hi all, > > We're pleased to announce that Google Summer of Code will be happening for > its ninth year this year. Please check out the blog post [1] about the > program and read the FAQs [2] and Timeline [3] on Melange for more > information. > > [1] - > http://google-opensource.blogspot.com/2013/02/flip-bits-not-burgers-google-summer-of.html > [2] - > http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2013/help_page > [3] - http://www.google-melange.com/gsoc/events/google/gsoc2013 > > Cheers, > Carol > > > > _______________________________________________ > IPython-User mailing list > IPython-User at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-user > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Mon Feb 11 20:52:21 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 11 Feb 2013 17:52:21 -0800 Subject: [IPython-dev] [IPython-User] Fwd: Google Summer of Code 2013 In-Reply-To: References: Message-ID: On Mon, Feb 11, 2013 at 4:19 PM, Thomas Kluyver wrote: > In previous years I know we've not done GSoC, because mentoring takes up > quite a bit of time itself. But maybe with the grant supporting several > people working on IPython, we could reconsider that. My take is actually the opposite: if anything, given our responsibilities towards the Sloan grant, we shouldn't spread ourselves any thinner right now. Yes there's money there, but there's also a ton of work to be done. GSoC is really a *mentoring* program to teach others how to participate in open source, that may by almost by accident produce useful code. Its real value is in the mentoring experience and in therefore growing a community. Unfortunately right now I think pretty much all the core people who could have enough experience in our project to be good mentors are already fully (if not over-) committed, so I don't see how we could do a good job mentoring a student. I say that as someone who in the past has been a mentor, and I felt that a) I didn't do enough of a good job as mentor because it demanded more time than I really had; b) it didn't really serve the IPython project all that much in the end. Cheers, f From ellisonbg at gmail.com Mon Feb 11 23:51:30 2013 From: ellisonbg at gmail.com (Brian Granger) Date: Mon, 11 Feb 2013 20:51:30 -0800 Subject: [IPython-dev] [IPython-User] Fwd: Google Summer of Code 2013 In-Reply-To: References: Message-ID: On Mon, Feb 11, 2013 at 5:52 PM, Fernando Perez wrote: > On Mon, Feb 11, 2013 at 4:19 PM, Thomas Kluyver wrote: >> In previous years I know we've not done GSoC, because mentoring takes up >> quite a bit of time itself. But maybe with the grant supporting several >> people working on IPython, we could reconsider that. > > My take is actually the opposite: if anything, given our > responsibilities towards the Sloan grant, we shouldn't spread > ourselves any thinner right now. Yes there's money there, but there's > also a ton of work to be done. I completely agree with Fernando. There is an important philosophy behind the Sloan grant that I think is worth stating. I don't view the Sloan grant as something that allows us to expand out activities to include more things. I view the grant as something that allows us to do a better job at what we are already doing: fewer bugs, higher quality features, moving faster through things that were already on our radar. This is really important. I think the GSoC would take us away from that focus. > GSoC is really a *mentoring* program to teach others how to > participate in open source, that may by almost by accident produce > useful code. Its real value is in the mentoring experience and in > therefore growing a community. Unfortunately right now I think pretty > much all the core people who could have enough experience in our > project to be good mentors are already fully (if not over-) committed, > so I don't see how we could do a good job mentoring a student. >From my experience with GSoC (mentor for 4 years on SymPy), you really have to put in a lot of time to make it worth while. It also takes the right kind of projects - and I don't think IPython has many of those right now. It is a much more complicated project than SymPy and the work tends to be much more coupled. All that to say, it is a non-trivial thing to commit to. > I say that as someone who in the past has been a mentor, and I felt > that a) I didn't do enough of a good job as mentor because it > demanded more time than I really had; b) it didn't really serve the > IPython project all that much in the end. Yep. Cheers, Brian > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From ellisonbg at gmail.com Thu Feb 14 15:01:02 2013 From: ellisonbg at gmail.com (Brian Granger) Date: Thu, 14 Feb 2013 12:01:02 -0800 Subject: [IPython-dev] GH wiki updates Message-ID: Hi, I have been working on the GitHub wiki for the last few days and wanted to summarize my progress: * I have gone through and created pseudo namespaces for our wiki pages using prefixes in the page names such as "Dev:" and "Install:" and "Cookbook:". Please use this from now on. * I have audited our content and removed all pages that are outdated. I haven't removed them from the wiki yet - they just have a "Trash:" prefix. Please look through these and see if you are OK with my decisions. If you want to keep something in the Trash, please update it as you move it back out of the Trash. * I have moved all of our developer docs to a single location - the GH wiki. There is an open PR to remove this stuff from the Sphinx docs. I have gone through and edited much of this material - it was a horrible mess. * Please help keep the wiki organized. * Right now our wiki has content in 3 different formats. From now on, please use Markdown for all new pages - I have rewritten quite a bit of content in Markdown. Some general observations about our documentation from working on it for a few days... Our biggest problem is that our documentation is too *deep* and *narrow*. * It is deep because the docs we do have are far too verbose. This means that none of us is willing or able to maintain it. In many cases, we aren't even aware of what documentation exists so bits and pieces get rewritten all over the place. * It is narrow because there are huge topics that don't have much documentation. * So...*PLEASE* be extremely concise when you are writing documentation. * Also, the length of the documentation should be proportional to the stability of the code/API. Rapidly evolving code should have minimal documentation or we will never be able to keep it updated. More stable parts of the code base should have more complete docs. We definitely need to have further discussions about how we want to approach our documentation. Cheers, Brian -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From takowl at gmail.com Thu Feb 14 16:25:11 2013 From: takowl at gmail.com (Thomas Kluyver) Date: Thu, 14 Feb 2013 21:25:11 +0000 Subject: [IPython-dev] GH wiki updates In-Reply-To: References: Message-ID: Thanks for doing this work. On 14 February 2013 20:01, Brian Granger wrote: > * I have gone through and created pseudo namespaces for our wiki pages > using prefixes in the page names such as "Dev:" and "Install:" and > "Cookbook:". Please use this from now on. > Is there any way to create redirects on Github wikis? I'd ensured that links to wiki.ipython.org were correctly redirected to the corresponding Github wiki pages, but of course the URL changes have broken that. Maybe I can patch the Cookbook pages with a bit more regex-foo... Likewise, with removing parts from the Sphinx docs, I wonder if we should link to the corresponding Wiki pages? I see breaking links as the web equivalent of breaking APIs, so I think it's something we shouldn't do lightly. Best wishes, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Thu Feb 14 16:45:13 2013 From: ellisonbg at gmail.com (Brian Granger) Date: Thu, 14 Feb 2013 13:45:13 -0800 Subject: [IPython-dev] GH wiki updates In-Reply-To: References: Message-ID: On Thu, Feb 14, 2013 at 1:25 PM, Thomas Kluyver wrote: > Thanks for doing this work. > > > On 14 February 2013 20:01, Brian Granger wrote: >> >> * I have gone through and created pseudo namespaces for our wiki pages >> using prefixes in the page names such as "Dev:" and "Install:" and >> "Cookbook:". Please use this from now on. > > > Is there any way to create redirects on Github wikis? I'd ensured that links > to wiki.ipython.org were correctly redirected to the corresponding Github > wiki pages, but of course the URL changes have broken that. Maybe I can > patch the Cookbook pages with a bit more regex-foo... The GH wiki has been changed to an extent that I don't think it is worth trying to maintain links. Our goal with moving the wiki to GH was to consolidate our content - not create an additional maintenance burden. I have removed many pages, combined others, renamed almost all and added new ones. I am fine with a single bulk redirect from wiki.ipython.org to the GH wiki. > Likewise, with removing parts from the Sphinx docs, I wonder if we should > link to the corresponding Wiki pages? I see breaking links as the web > equivalent of breaking APIs, so I think it's something we shouldn't do > lightly. Good point, I will add a link from the Sphinx dev docs index to the Dev: part of the GH wiki. Cheers, Brian > Best wishes, > Thomas > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From fperez.net at gmail.com Thu Feb 14 18:12:39 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 14 Feb 2013 15:12:39 -0800 Subject: [IPython-dev] Please help the Python Software Foundation: Python trademark in legal trouble in Europe Message-ID: Hi all, please do NOT respond to this thread or to me directly. This is strictly to spread this message as widely as possible, so that anyone who receives it and can act on it does so. Needless to say, do forward this to anyone you think might be in a position to take useful action. The Python trademark is in serious risk across Europe due to the actions of a UK-based IP troll. If you operate in Europe, please help the Python Software Foundation gather evidence in the legal battle to protect the Python trademark across the EU. You can find the official blog post from the PSF with instructions on how to help here: http://pyfound.blogspot.com/2013/02/python-trademark-at-risk-in-europe-we.html and this thread on Hacker News is being monitored by the PSF Chairman Van Lindberg in case you want to ask the team directly any questions: http://news.ycombinator.com/item?id=5221093 Cheers, f From jonathan.taylor at stanford.edu Thu Feb 14 21:35:40 2013 From: jonathan.taylor at stanford.edu (Jonathan Taylor) Date: Thu, 14 Feb 2013 18:35:40 -0800 Subject: [IPython-dev] slideshow mode Message-ID: I would like to test out the slideshow mode. I see the slide toolbar, but don't know how to view it as a slideshow. -- Jonathan Taylor Dept. of Statistics Sequoia Hall, 137 390 Serra Mall Stanford, CA 94305 Tel: 650.723.9230 Fax: 650.725.8977 Web: http://www-stat.stanford.edu/~jtaylo -------------- next part -------------- An HTML attachment was scrubbed... URL: From damianavila at gmail.com Thu Feb 14 21:45:02 2013 From: damianavila at gmail.com (=?ISO-8859-1?Q?Dami=E1n_Avila?=) Date: Thu, 14 Feb 2013 23:45:02 -0300 Subject: [IPython-dev] slideshow mode In-Reply-To: References: Message-ID: <511DA12E.20508@gmail.com> El 14/02/13 23:35, Jonathan Taylor escribi?: > I would like to test out the slideshow mode. I see the slide toolbar, > but don't know how to view it as a slideshow. > > -- > Jonathan Taylor > Dept. of Statistics > Sequoia Hall, 137 > 390 Serra Mall > Stanford, CA 94305 > Tel: 650.723.9230 > Fax: 650.725.8977 > Web: http://www-stat.stanford.edu/~jtaylo > > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev You have two possibilities: * Use the live slideshow from Mathias. This only support slides for now and you can get more info here: https://github.com/Carreau/ipython-static-profiles * Use the recently merged reveal converter inside current nbconvert: https://github.com/ipython/nbconvert The -f reveal option will give you a static html slideshow supporting slides, subslides, fragments and speaker notes, and other great features from the reveal library. I am writing a little tutorial (and I will publish tonight or tomorrow morning) to show you how to use this new reveal slideshow. Cheers. Dami?n. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bussonniermatthias at gmail.com Fri Feb 15 02:39:50 2013 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Fri, 15 Feb 2013 08:39:50 +0100 Subject: [IPython-dev] slideshow mode In-Reply-To: References: Message-ID: <0F711B38-82CF-4972-BB20-6FD14AFB2E65@gmail.com> Copy of the explanation I sent to Fernando a few week ago at the end of this mail. I didn't had time to re-work on this, PR and bug report are welcomed. -- Matthias > Not fully functional, but should do pretty much the same than at SciPy "12. > > You will have to run a pretty recent version of IPython to use it though, but I Guess that will not be a problem :-) > > Just clone (or merge) the following > https://github.com/Carreau/ipython-static-profiles > > in your .ipython/profile_xx/static/ > > There is a small read me on how to install/use/... etc. > > You might have to restart your server for it to catch the fact that there is a custom.js and custom.css file. > > Going to the end auto exit and enable back to slide 1. > > (... some time passes) > > > Some more stuff : > > support for > - Fragment cell > - Skip/Notes cell > - 'undefined' cell (noted as - ) > > As you might not have read the all PRs I'll do a quick recap. > > Slide is the unit of content that can appear on a screen at once. > So any cell that you will mark as "slide" with the Cell Toolbar UI can only be at the top of the screen and delimitate the beginning of a new slide. > > You can get "skip" and "notes" cells, those won't show in Live Slideshow mode nor in Damian's slideshow viewer. > Difference is that slideshow viewer support speaker "notes" on a separate windows. > > Lastly "Fragment" is a part of a slide that shows after key press like a bullet point list in normal presentation if you wish, > except we are constrained at cell level in our case. > > By default undefined slide automatically appear with the previous slide. > > > So, small example : > > Slide number / type > > 1 - (automatically interpreted as slide) > 2 slide > 3 - > 4 slide > 5 slide > 6 - > 7 fragment > 8 - > 9 fragment > 10 skip > 11 fragment > 12 slide > > Cell on screen after each key press. > 1 > 2,3 > 4 > 5,6 > 5,6,7,8 > 5,6,7,8,9 > 5,6,7,8,9,11 > 12 > ... > > Hope that make sense. > -- > Matthias From damianavila at gmail.com Fri Feb 15 16:29:01 2013 From: damianavila at gmail.com (=?ISO-8859-1?Q?Dami=E1n_Avila?=) Date: Fri, 15 Feb 2013 18:29:01 -0300 Subject: [IPython-dev] Reveal converter has finally arrived! Message-ID: <511EA89D.7040107@gmail.com> To all, Do you want to prepare slideshows for a talk, a tutorial, a course, etc (we have a lot of conference ahead!). Well, now you can use the IPython notebook to do it! nbconvert now supports a new format "reveal" which gives you a notebook-based html/css slideshow powered by reveal javascript library. You have more info about how to use in this blog post: http://www.damian.oquanta.info/posts/reveal-converter-mini-tutorial.html Note: nbconvert is being rewritten right now, but the new development version (actually a PR) also support this new converter... so do not worry ;-) If you have any doubts, problems or suggestions, just let me know. Cheers. Dami?n. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Fri Feb 15 16:36:00 2013 From: ellisonbg at gmail.com (Brian Granger) Date: Fri, 15 Feb 2013 13:36:00 -0800 Subject: [IPython-dev] Reveal converter has finally arrived! In-Reply-To: <511EA89D.7040107@gmail.com> References: <511EA89D.7040107@gmail.com> Message-ID: Damian, Can you point us to the repo that has the current version (in this email)... Cheers and great work! Brian On Fri, Feb 15, 2013 at 1:29 PM, Dami?n Avila wrote: > To all, > > Do you want to prepare slideshows for a talk, a tutorial, a course, etc (we > have a lot of conference ahead!). > > Well, now you can use the IPython notebook to do it! > > nbconvert now supports a new format "reveal" which gives you a > notebook-based html/css slideshow powered by reveal javascript library. > > You have more info about how to use in this blog post: > http://www.damian.oquanta.info/posts/reveal-converter-mini-tutorial.html > > Note: nbconvert is being rewritten right now, but the new development > version (actually a PR) also support this new converter... so do not worry > ;-) > > If you have any doubts, problems or suggestions, just let me know. > > Cheers. > > Dami?n. > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From fperez.net at gmail.com Fri Feb 15 21:16:00 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 15 Feb 2013 18:16:00 -0800 Subject: [IPython-dev] A gallery of interesting IPython Notebooks Message-ID: Hi folks, I've just created a gallery of good/interesting/useful notebooks here: https://github.com/ipython/ipython/wiki/A-gallery-of-interesting-IPython-Notebooks Feel free to pitch in, share it, add good examples you may know of, etc. At some point in the future we'll have a more automated/searchable mechanism for this, but in the meantime being able to showcase and find good work like this, even if it requires a little manual work, can be very handy. Big kudos to Matthias for having come out of left field with nbviewer. Every day that goes by we get more mileage out of it. Cheers, f From jason-sage at creativetrax.com Fri Feb 15 22:21:18 2013 From: jason-sage at creativetrax.com (Jason Grout) Date: Fri, 15 Feb 2013 21:21:18 -0600 Subject: [IPython-dev] cell magics Message-ID: <511EFB2E.5080201@creativetrax.com> William Stein and I have been discussing cell magics lately as he is implementing them in his Salvus project. I think the result, which is a little different than the current IPython system, is more consistent, easier to read, and more elegant. What are your thoughts? PROPOSAL: Line and cell magics are normal python functions that take a string as their first input. The string is either the rest of the line, or if there is no discernible string on the rest of the line, the string is taken as the rest of the cell. As an example: %timeit(runs=10) 2+3 which gets translated to time("2+3", runs=10) A cell magic is exactly the same function, only it is invoked by putting the string on the following lines, rather than on the same line, so the string is taken as the remainder of the cell: %timeit(runs=10) 2+3 5+6 which gets translated to timeit("2+3\n5+6", runs=10) Notice there is no distinction between line and cell magic functions---the distinction entirely happens in how they are invoked (whether the string is on the same line or on following lines). Also, magic options are passed in exactly the same way that arguments are always passed to python functions, instead of having a non-pythonic, bash-like syntax for options. END OF PROPOSAL That's the proposal. I got to thinking more about it too. The whole concept of magics (passing a string to a function) is like decorators. In fact, we could make it exactly like decorators, if we wanted (I'm not sure that we want to introduce the extra complexity, but it would be more consistent with decorators): %timeit 2+3 transforms to timeit("2+3"), but %timeit(runs=4) 2+3 effectively does timeit(runs=4)("2+3") In some sense, the magics are implementing a very (*very*) rudimentary macro system for python, the advantages being that we can pass an unevaluated string into a function without having to type the quote marks. Right now we can only pass in single-line strings or the entire rest of the cell. But what if we brainstormed for other ways to denote a string that was to be treated special? For example, we could use a github/markdown-like syntax: ```timeit(runs=4) 2+3 5+6 ``` (except that python supports `a` is repr(a)). But this might look nice: ```R hist(x) ``` translating to R("hist(x)"). In fact, we could make it even more lispy by supporting parameter expansion: ```R hist(%d) ```%x which would do something like R("hist(%d)"%x) I'm just brainstorming at the end here, but I'm still curious your thoughts on the subject, especially on the first proposal of unifying the line and cell magic syntax and calling syntax to be more consistent with each other and with python. Thanks, Jason From jason-sage at creativetrax.com Fri Feb 15 22:30:52 2013 From: jason-sage at creativetrax.com (Jason Grout) Date: Fri, 15 Feb 2013 21:30:52 -0600 Subject: [IPython-dev] cell magics In-Reply-To: <511EFB2E.5080201@creativetrax.com> References: <511EFB2E.5080201@creativetrax.com> Message-ID: <511EFD6C.4030603@creativetrax.com> On 2/15/13 9:21 PM, Jason Grout wrote: > %timeit(runs=10) 2+3 > > which gets translated to time("2+3", runs=10) Of course, I meant for it to get translated to timeit("2+3", runs=10) Thanks, Jason From fperez.net at gmail.com Sat Feb 16 01:47:33 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 15 Feb 2013 22:47:33 -0800 Subject: [IPython-dev] cell magics In-Reply-To: <511EFB2E.5080201@creativetrax.com> References: <511EFB2E.5080201@creativetrax.com> Message-ID: Hi Jason, On Fri, Feb 15, 2013 at 7:21 PM, Jason Grout wrote: > William Stein and I have been discussing cell magics lately as he is > implementing them in his Salvus project. I think the result, which is a > little different than the current IPython system, is more consistent, > easier to read, and more elegant. What are your thoughts? Mmh, for now, big -1 from me, for what I think are good reasons within the design and philosophy of IPython. I happen to think that our design is actually more consistent, easier to read, and more elegant, but you're obviously entitled to your opinion on the matter ;) > PROPOSAL: > > Line and cell magics are normal python functions that take a string as > their first input. The string is either the rest of the line, or if > there is no discernible string on the rest of the line, the string is > taken as the rest of the cell. As an example: > > %timeit(runs=10) 2+3 > > which gets translated to time("2+3", runs=10) > > A cell magic is exactly the same function, only it is invoked by putting > the string on the following lines, rather than on the same line, so the > string is taken as the remainder of the cell: > > %timeit(runs=10) > 2+3 > 5+6 > > which gets translated to timeit("2+3\n5+6", runs=10) > > Notice there is no distinction between line and cell magic > functions---the distinction entirely happens in how they are invoked > (whether the string is on the same line or on following lines). Also, > magic options are passed in exactly the same way that arguments are > always passed to python functions, instead of having a non-pythonic, > bash-like syntax for options. The whole point of magics is precisely to have a non-pythonic, no-parentheses, bash-like syntax that emphasizes ease of typing (the space bar is much, much easier to hit than the parens keys). Magics were put in from day one (not even by me, as the rudiments of the system and the 'magics' name were already in place in Janko Hauser's IPP) explicitly with the intention of having a syntax that would be very 'command-like'. When I inherited IPP and put it into IPython, I had used extensively IDL which had a similar notion of 'commands', and I later discovered that matlab has something similar (though I didn't know it at the time). These commands are separate from the main programming language (though for IDL and matlab, they are part of the same specification since the whole thing is produced by a single group). The point of such a system is that it meets a number of criteria: - the namespace where these exist is completely orthogonal to the Python one. In IPython, aside from the small transgression we make with %pylab that does a few global imports, *you* manage your Python namespaces explicitly as much as you would in normal Python code. Sage takes a different approach and imports on the order of thousands of names by default: ---------------------------------------------------------------------- | Sage Version 4.7.1, Release Date: 2011-08-11 | | Type notebook() for the GUI, and license() for information. | ---------------------------------------------------------------------- sage: len(dir()) 1878 I personally don't like this. For comparison, in IPython you get this (you can choose to load more stuff, obviously, but you do so explicitly and knowingly): In [1]: len(dir()) Out[1]: 45 I can keep a namespace of 45 things in my head, I can't really manage one with 2000 things. This orthogonality is important because it lets us easily provide the convenience of preloading all magics relevant to IPython control without polluting the user's namespace. This also makes it possible to do things like doing a full reset of the user ns without impacting the control system. The orthogonality of the namespaces also means that extensions can be loaded at runtime that add special functionality and new magics with zero risk of breaking normal user code, as the namespaces will never collide, by design. - by being really separate objects, it's clear that they play a role that's a bit different from that of normal code: they control IPython itself, and they do things that go beyond the Python syntax. Sage chose to create a hybrid of the python language and other things (ints with different semantics, extended list/range syntax, different power operator, etc). That's perfectly OK for you guys, but we drew the design boundaries differently. We leave the language alone, and introduce special cases that are always demarcated by special, orthogonal syntax that's invalid in Python itself (modulo a few convenience automatic transforms that can be turned off if desired and are there just to save time for the diehards). I am personally happy to have chosen that route over a decade ago, and it seems that over the year the rest of the project team has also agreed with this approach. - the syntax is deliberately different from a python one: not only is it quicker and more convenient to type 'func -k args' than 'func("arg", kw=1)' when working interactively, I also very much prefer to know that "magics are like bash, Python is like python" than thinking that the magic system is some kind of half-way hybrid between the two. I find it eminently more readable as it uses two conceptually distinct categories for which my brain already has buckets ready, instead of creating a new special-case, bizarre blend of the two that I wouldn't use anywhere else. - our design makes it just as easy to unify cell/line magics if you want. As you can see in the docs (http://ipython.org/ipython-doc/dev/interactive/reference.html#defining-your-own-magics), you can have a single function (not even a class is needed) that does line/cell magics in one shot. I don't find that any more complex than your proposal. Furthermore, we do have some very clean base classes that let you handle the more complex cases with zero boilerplate, as you can focus only on your own functionality and state management (when classes are warranted) and we take care of the basics). In summary, while you're free to prefer the design in Sage, I very much disagree on all points and see very little chance that we'll change ours. If anything, the exercise of writing this down has convinced me further that what we have is a solid piece of architecture we shouldn't mess with. All the best, f From jason-sage at creativetrax.com Sat Feb 16 02:35:09 2013 From: jason-sage at creativetrax.com (Jason Grout) Date: Sat, 16 Feb 2013 01:35:09 -0600 Subject: [IPython-dev] cell magics In-Reply-To: References: <511EFB2E.5080201@creativetrax.com> Message-ID: <511F36AD.20209@creativetrax.com> On 2/16/13 12:47 AM, Fernando Perez wrote: > In summary, while you're free to prefer the design in Sage, I very > much disagree on all points and see very little chance that we'll > change ours. If anything, the exercise of writing this down has > convinced me further that what we have is a solid piece of > architecture we shouldn't mess with. Thanks for the detailed email. I figured that there was pretty close to zero chance IPython would change, if only from backwards compatibility. However, you've gone way beyond just backwards compatibility and argued pretty effectively for the current syntax. In fact, much of what you wrote I think would be great in an "overview of magics" document somewhere :). I had been thinking of magics as literally "string decorators" (i.e., functions in the user namespace that take a string as their first argument). I see you think of them and their uses very differently. I'm still forming my opinions (and brainstorming ideas), so I appreciate the thoughtful answer. Jason P.S. And for the record, though I come from the Sage community, I don't necessarily personally espouse the "import everything" philosophy; I think Sage probably went a little overboard there. I suppose I'm somewhat halfway between the kitchen-sink and minimalistic "namespaces are a honking great idea" philosophies right now. I realize you were just making general statements about communities and philosophies, of course. From fperez.net at gmail.com Sat Feb 16 02:44:41 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 15 Feb 2013 23:44:41 -0800 Subject: [IPython-dev] cell magics In-Reply-To: <511F36AD.20209@creativetrax.com> References: <511EFB2E.5080201@creativetrax.com> <511F36AD.20209@creativetrax.com> Message-ID: Hey Jason, On Fri, Feb 15, 2013 at 11:35 PM, Jason Grout wrote: > Thanks for the detailed email. I figured that there was pretty close to > zero chance IPython would change, if only from backwards compatibility. > However, you've gone way beyond just backwards compatibility and > argued pretty effectively for the current syntax. In fact, much of what > you wrote I think would be great in an "overview of magics" document > somewhere :). Yup, good point. We're starting to put effort into our docs, I'll fish this out of email in a few days (or someone else will beat me to it). One thing we have too little of, and which we need, are this kinds of explanations that describe the design, architecture and philosophy of the system. I know due to our lack of docs it may not look like it, but we've actually thought a LOT about having a coherent internal design at all levels in IPython. It may have started as a quick and dirty hack, but we've done our best to shape it into something with a fair amount of internal consistency that follows a few simple principles that actually be stated and explained. We just need to *actually* state them :) > I had been thinking of magics as literally "string decorators" (i.e., > functions in the user namespace that take a string as their first > argument). I see you think of them and their uses very differently. > I'm still forming my opinions (and brainstorming ideas), so I appreciate > the thoughtful answer. My pleasure. It was a good exercise, so thanks for the opportunity :) > Jason > > P.S. And for the record, though I come from the Sage community, I don't > necessarily personally espouse the "import everything" philosophy; I > think Sage probably went a little overboard there. I suppose I'm > somewhat halfway between the kitchen-sink and minimalistic "namespaces > are a honking great idea" philosophies right now. I realize you were > just making general statements about communities and philosophies, of > course. Sure, and I know that much of that also stems from a consistent following of Sage's motto of being a "viable alternative to the M*s". The M*s all do this, and their users are accustomed (for better or worse) to such functionality, so for Sage that path is one that is consistent with its guiding principles. Not the choice *I* would make, but I can understand why and how Sage got there. Cheers, f From fperez.net at gmail.com Thu Feb 14 17:56:22 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 14 Feb 2013 14:56:22 -0800 Subject: [IPython-dev] Python trademark in legal trouble in Europe, please help Message-ID: Hi all, please do NOT respond to this thread or to me directly. This is strictly to spread this message as widely as possible, so that anyone who receives it and can act on it does so. Needless to say, do forward this to anyone you think might be in a position to take useful action. The Python trademark is in serious risk across Europe due to the actions of a UK-based IP troll. If you operate in Europe, please help the Python Software Foundation gather evidence in the legal battle to protect the Python trademark across the EU. You can find the official blog post from the PSF with instructions on how to help here: http://pyfound.blogspot.com/2013/02/python-trademark-at-risk-in-europe-we.html and this thread on Hacker News is being monitored by the PSF Chairman Van Lindberg in case you want to ask the team directly any questions: http://news.ycombinator.com/item?id=5221093 Cheers, f From scopatz at gmail.com Fri Feb 15 12:43:17 2013 From: scopatz at gmail.com (Anthony Scopatz) Date: Fri, 15 Feb 2013 11:43:17 -0600 Subject: [IPython-dev] SciPy 2013 Announcement -- June 24 - 29, 2013, Austin, TX! Message-ID: Hello All, As this years conference communications co-chair, it is my extreme pleasure to announce the *SciPy 2013 conference from June 24th - 29th in sunny Austin, Texas, USA.* Please see our website(or below) for more details. A call for presentations, tutorials, and papers will be coming out very soon. Please make sure to sign up on our mailing list, follow us on twitter , or Google Plus so that you don't miss out on any important updates. I sincerely hope that you can attend this year and make 2013 the best year for SciPy yet! Happy Hacking! Anthony Scopatz SciPy 2013 Conference Announcement ---------------------------------- SciPy 2013, the twelfth annual Scientific Computing with Python conference, will be held this June 24th-29th in Austin, Texas. SciPy is a community dedicated to the advancement of scientific computing through open source Python software for mathematics, science, and engineering. The annual SciPy Conference allows participants from academic, commercial, and governmental organizations to showcase their latest projects, learn from skilled users and developers, and collaborate on code development. The conference consists of two days of tutorials by followed by two days of presentations, and concludes with two days of developer sprints on projects of interest to the attendees. Specialized Tracks ------------------ This year we are happy to announce two specialized tracks run in parallel to the general conference: *Machine Learning* In recent years, Python's machine learning libraries rapidly matured with a flurry of new libraries and cutting-edge algorithm implement and development occurring within Python. As Python makes these algorithms more accessible, machine learning algorithm application has spread across disciplines. Showcase your favorite machine learning library or how it has been used as an effective tool in your work! *Reproducible Science* Over recent years, the Open Science movement has stoked a renewed acknowledgement of the importance of reproducible research. The goals of this movement include improving the dissemination of progress, prevent fraud through transparency, and enable deeper/wider development and collaboration. This track is to discuss the tools and methods used to achieve reproducible scientific computing. Domain-specific Mini-symposia ----------------------------- Introduced in 2012, mini-symposia are held to discuss scientific computing applied to a specific scientific domain/industry during a half afternoon after the general conference. Their goal is to promote industry specific libraries and tools, and gather people with similar interests for discussions. Mini-symposia on the following topics will take place this year: - Meteorology, climatology, and atmospheric and oceanic science - Astronomy and astrophysics - Medical imaging - Bio-informatics Tutorials --------- Multiple interactive half-day tutorials will be taught by community experts. The tutorials provide conceptual and practical coverage of tools that have broad interest at both an introductory or advanced level. This year, a third track will be added, targeting specifically programmers with no prior knowledge of scientific python. Developer Sprints ----------------- A hackathon environment is setup for attendees to work on the core SciPy packages or their own personal projects. The conference is an opportunity for developers that are usually physically separated to come together and engage in highly productive sessions. It is also an occasion for new community members to introduce themselves and recieve tips from community experts. This year, some of the sprints will be scheduled and announced ahead of the conference. Birds-of-a-Feather (BOF) Sessions --------------------------------- Birds-of-a-Feather sessions are self-organized discussions that run parallel to the main conference. The BOFs sessions cover primary, tangential, or unrelated topics in an interactive, discussion setting. This year, some of the BOF sessions will be scheduled and announced ahead of the conference. Important Dates --------------- - March 18th: Presentation abstracts, poster, tutorial submission deadline. Application for sponsorship deadline. - April 15th: Speakers selected - April 22nd: Sponsorship acceptance deadline - May 1st: Speaker schedule announced - May 5th: Paper submission deadline - May 6th: Early-bird registration ends - June 24th-29th: 2 days of tutorials, 2 days of conference, 2 days of sprints We look forward to a very exciting conference and hope to see you all at the conference. The SciPy2013 organization team: * Andy Terrel, Co-chair * Jonathan Rocher, Co-chair * Katy Huff, Program Committee co-chair * Matt McCormick, Program Committee co-chair * Dharhas Pothina, Tutorial co-chair * Francesc Alted, Tutorial co-chair * Corran Webster, Sprint co-chair * Peter Wang, Sprint co-chair * Matthew Turk, BoF co-chair * Jarrod Millman, Proceeding co-chair * St?fan van der Walt, Proceeding co-chair * Anthony Scopatz, Communications co-chair * Majken Tranby, Communications co-chair * Jeff Daily, Financial Aid co-chair * John Wiggins, Financial Aid co-chair * Leah Jones, Operations chair * Brett Murphy, Sponsor chair * Bill Cowan, Financial chair -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Sat Feb 16 10:52:33 2013 From: takowl at gmail.com (Thomas Kluyver) Date: Sat, 16 Feb 2013 15:52:33 +0000 Subject: [IPython-dev] cell magics In-Reply-To: <511EFB2E.5080201@creativetrax.com> References: <511EFB2E.5080201@creativetrax.com> Message-ID: On 16 February 2013 03:21, Jason Grout wrote: > Line and cell magics are normal python functions that take a string as > their first input. The string is either the rest of the line, or if > there is no discernible string on the rest of the line, the string is > taken as the rest of the cell. As an example: > > %timeit(runs=10) 2+3 > > which gets translated to time("2+3", runs=10) > > A cell magic is exactly the same function, only it is invoked by putting > the string on the following lines, rather than on the same line, so the > string is taken as the remainder of the cell: > > %timeit(runs=10) > 2+3 > 5+6 > > which gets translated to timeit("2+3\n5+6", runs=10) > As you noted in a later e-mail, we're not about to break backwards compatibility, but it's worth thinking about the syntax. Here's my perspective on magics: - As Fernando says, they started off as commands with a deliberately shell-like syntax, and many still work like this, e.g. %cd or %run. - A couple of line magics accepted a Python statement as an argument (%timeit, %prun). This is a convenient shorthand for functions that accept code as a string. - After the development of the notebook, magics were extended to include cell magics, which are conceptually much more like your idea of 'string decorators'. A primary use has been to include code written in other languages. Arguably, the newer uses don't have to fit into the same scheme as the original command-like magics. But neither do they have to be separate, and I think we're better off supporting one flexible scheme than adding a second, incompatible scheme for cell magics. Best wishes, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Sat Feb 16 13:48:54 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 16 Feb 2013 10:48:54 -0800 Subject: [IPython-dev] cell magics In-Reply-To: References: <511EFB2E.5080201@creativetrax.com> Message-ID: On Sat, Feb 16, 2013 at 7:52 AM, Thomas Kluyver wrote: > - After the development of the notebook, magics were extended to include > cell magics, It's important to know that this is a perfect example of correlation not being causation: we could have added the cell magics once we had the qtconsole, we just didn't have the time/resources for it. All that's needed for cell magics to make sense is a practical multi-line client, which we only had once the qt console was functional. It was only when Chris Kees and Jose Unpingco worked with us to get DoD funding that we had the bandwidth to dig deeper into the magic system to overhaul it, and in the process, add the cell magics. I mention this because it's important to clarify that they have nothing to do with the notebook as a client: the magic system is part of the core of ipython, that is available to *all* clients, even the plain terminal. Obviously in a line terminal it's pretty miserable to use any non-trivial cell magic, but you can do so if you really want: In [1]: %%bash ...: echo hi ...: hi > Arguably, the newer uses don't have to fit into the same scheme as the > original command-like magics. But neither do they have to be separate, and I > think we're better off supporting one flexible scheme than adding a second, > incompatible scheme for cell magics. Yup. Cheers, f From takowl at gmail.com Sat Feb 16 14:15:43 2013 From: takowl at gmail.com (Thomas Kluyver) Date: Sat, 16 Feb 2013 19:15:43 +0000 Subject: [IPython-dev] cell magics In-Reply-To: References: <511EFB2E.5080201@creativetrax.com> Message-ID: On 16 February 2013 18:48, Fernando Perez wrote: > It's important to know that this is a perfect example of correlation > not being causation: we could have added the cell magics once we had > the qtconsole, we just didn't have the time/resources for it. All > that's needed for cell magics to make sense is a practical multi-line > client, which we only had once the qt console was functional. > Technically, I quite agree. But from a user perspective, I think the notebook made the need for something like cell magics much more pressing than the Qt console. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Sat Feb 16 14:51:14 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 16 Feb 2013 11:51:14 -0800 Subject: [IPython-dev] cell magics In-Reply-To: References: <511EFB2E.5080201@creativetrax.com> Message-ID: On Sat, Feb 16, 2013 at 11:15 AM, Thomas Kluyver wrote: > On 16 February 2013 18:48, Fernando Perez wrote: >> >> It's important to know that this is a perfect example of correlation >> not being causation: we could have added the cell magics once we had >> the qtconsole, we just didn't have the time/resources for it. All >> that's needed for cell magics to make sense is a practical multi-line >> client, which we only had once the qt console was functional. > > > Technically, I quite agree. But from a user perspective, I think the > notebook made the need for something like cell magics much more pressing > than the Qt console. And more useful! But it's important for users to understand how the abstractions fit together, because I regularly get questions that stem from users confusing the roles the notebook and the kernel play. The cell magics may shine brightest in the notebook for user experience reasons, but they are a feature whose implementation lives 100% inside the kernel, and which is therefore available to all clients. Just yesterday I had a discussion with Matthew about some issues with %%bash where I had to make precisely this clarification. A solution he was proposing was based on just this kind of blurring/confusion between client and kernel that I am trying to dispel. Cheers, f From jason-sage at creativetrax.com Sat Feb 16 17:07:04 2013 From: jason-sage at creativetrax.com (Jason Grout) Date: Sat, 16 Feb 2013 16:07:04 -0600 Subject: [IPython-dev] cell magics In-Reply-To: References: <511EFB2E.5080201@creativetrax.com> Message-ID: <51200308.2070502@creativetrax.com> On 2/16/13 12:47 AM, Fernando Perez wrote: > Hi Jason, > >> PROPOSAL: >> >> Line and cell magics are normal python functions that take a string as >> their first input. The string is either the rest of the line, or if >> there is no discernible string on the rest of the line, the string is >> taken as the rest of the cell. As an example: >> >> %timeit(runs=10) 2+3 >> >> which gets translated to time("2+3", runs=10) >> >> A cell magic is exactly the same function, only it is invoked by putting >> the string on the following lines, rather than on the same line, so the >> string is taken as the remainder of the cell: >> >> %timeit(runs=10) >> 2+3 >> 5+6 >> >> which gets translated to timeit("2+3\n5+6", runs=10) >> >> Notice there is no distinction between line and cell magic >> functions---the distinction entirely happens in how they are invoked >> (whether the string is on the same line or on following lines). Also, >> magic options are passed in exactly the same way that arguments are >> always passed to python functions, instead of having a non-pythonic, >> bash-like syntax for options. I've spent all day (and a better part of a night :) writing and rewriting this reply; hopefully it's clear. Like I mentioned before, I'm still forming an opinion and working on seeing things clearly. Special thanks goes to some private comments from William for helping me to see more clearly what is a real difference between the two philosophies and what is an implementation detail. To summarize, I think the two positions are: Current IPython: 1a. % is only a valid operator on registered string decorators 2a. Two different syntaxes for invoking line and cell string decorators 3a. optional arguments to string decorators should not have pythonic syntax In our proposal, we say: 1b. % should be a valid operator on any string decorator 2b. The % cell/line invocation syntax should be unified 3b. optional arguments to string decorators should have pythonic syntax Is that a fair characterization? Let's take these in turn: 1. where % is a valid operator ============================== I think your argument boils down to "let's make % only apply to registered string decorators so that people will think in a certain way when they use %". That may have held when you had tight control on exactly what was registered, but now with everyone and their mother implementing custom extensions doing who knows what, it's artificially restrictive to insist that % means "modify the editor or go beyond python". Thomas points out that already the scope of % directives has massively increased beyond the original idea. With custom extensions, the scope of what is accomplished and how a user thinks when they use % blows wide open. With our proposal, % could still just complete with registered string decorators (with even the exact same registration system, so you can register things outside of the user's namespace). The difference is that if I wanted to run a string decorator that wasn't in the registered namespace, but I had just defined in my user namespace, I wouldn't have to pollute the registered namespace for my one invocation. I could just run %my_function directly. I think this is particularly important because the registered % namespace is a flat list of names, so it's not a very organized namespace (which is exactly a problem you have with Sage's philosophy, ironically :). 2. Unification of user syntax for cell/line decorators ====================================================== You only address the fact that you have special ways to make it easy for a developer to define both a line and cell magic. That's an implementation detail, and it's easier with our proposal anyway since everything is automatically both. We see already that there are a number of decorators that could be both, but are only defined as one, like %ruby, for example. But the real issue here is that IPython has two different syntaxes for the users to invoke string decorators. That means that I, as a user, constantly have to remember if a command is one, or the other, or both, because the very first two characters are different between the two. For example, just now I typed %ru, and I see from the completions that ruby is only a cell decorator. So now I have to backspace and put that extra % in there. It also means that if a string decorator can be invoked as both, in order to change between the two, I have to not only put the string in a different place, but I also have to go back and modify the % part too. If I forget to modify the %, I get very confusing results With our proposal, these issues go away. All string decorators are invoked with %. The difference between a line or cell decorator is determined by whether or not there is a string on the line (just as the difference between if blah: something and if blah: something something else is (partly) just seen by looking to see if the block is on the same line). So to change between cell and line string decorators, all I have to do is move the line. For example: %time some_function now I want to add a few more things to the time run. All I have to do is change where the string is: %time some_function some_other function and the lack of a string after %time tells me that I should look below %time for the string. I don't have to constantly keep adjusting the % character(s). P.S. Actually, after thinking about it more, since a single % is ambiguous syntax, I think I would prefer all string decorators be invoked with %%, which is invalid python syntax. Then we won't have this problem: cd=5 a=4\ %cd or this problem: cd=4 a="time: %d"\ %cd 3. format of optional arguments =============================== It seems that there are two main arguments for this: * backwards compatibility (with IPP and previous IPython versions, as well as IDL and matlab apparently?). But I'll point out that we can easily support this too, in almost exactly the same invocation: %timeit('-r 5 -and -other -options') 2+3 * also, you made the argument that it should be command-line type syntax because it is visually distinctive from python. I think this argument presupposes that: (a) users are comfortable with bash-like syntax. With the rising popularity of IPython, and especially with the rising popularity of the notebook, I think we're going to see more and more non-unix users that see the bash-like syntax as one more *new* thing to learn, rather than something that is already familiar in a different context. In fact, I look at the %timeit syntax for example, and I have to try to remember what the options are each time. Compare: %timeit -r5 2+3 %timeit(runs=5) 2+3 I think it's pretty clear which statement is more readable. This focus on readability over brevity (remember, "Readability counts") is part of why python is so good in general. I look at the %R option syntax, and I absolutely *have* to go to the help to see what is going on. Supporting a pythonic syntax I think will help users tremendously. Of course, this readability stuff is just a convention. You could make %timeit --runs=5 2+3 but the point is that encouraging a bash-like syntax is casting a vote for brevity over readability. Considering that each extension will implement its own short options, I think I vote for readability, so I have a better chance of looking at a string decorator invocation and having an idea of what it is doing (b) the bash-like syntax is just as powerful. But it's certainly not. With a bash-like syntax that isn't valid python code, but just a string, I cannot pass in python objects directly. I can do that if my parameters are valid python syntax. This is a lesson IPython learned when it decided on a rich pyout/display_data/stream output system instead of just passing on a stdout string. It makes sense to apply that same lesson here to the string decorator inputs. (c) we need visually distinctive syntax because % directives are very different from python code. But like I mention above with custom user extensions, I don't think this idea that % directives are command-line sorts of things applies as much anymore because the field is wide open. Regardless, if we *have* to have bash syntax for some extension, it's easy to make an invocation like: %script('-bg') blah I think I just convinced myself that the new proposal really is a better plan. Whew! Okay, so...comments? Thanks, Jason From takowl at gmail.com Sat Feb 16 17:39:42 2013 From: takowl at gmail.com (Thomas Kluyver) Date: Sat, 16 Feb 2013 22:39:42 +0000 Subject: [IPython-dev] cell magics In-Reply-To: <51200308.2070502@creativetrax.com> References: <511EFB2E.5080201@creativetrax.com> <51200308.2070502@creativetrax.com> Message-ID: That's quite a lot to read, but while I think about it in more detail, a couple of bits that jump out at me: On 16 February 2013 22:07, Jason Grout wrote: > %time some_function > > now I want to add a few more things to the time run. All I have to do > is change where the string is: > > %time > some_function > some_other function > > and the lack of a string after %time tells me that I should look below > %time for the string. I don't have to constantly keep adjusting the % > character(s). > For %%timeit, however, we use the remainder of the line as a setup statement, before timing the body. Now you can argue that that's a bad idea, but it's useful to have that distinction. > P.S. Actually, after thinking about it more, since a single % is > ambiguous syntax, I think I would prefer all string decorators be > invoked with %%, which is invalid python syntax. Then we won't have > this problem: > > cd=5 > a=4\ > %cd > > or this problem: > > cd=4 > a="time: %d"\ > %cd > My input transformation work should handle such cases. Arguably it could be done more easily if we used a syntax like %% that could never appear in a valid Python statement, but it still wouldn't be trivial: a = """ %%foo """ > ... > I think it's pretty clear which statement is more readable. This focus > on readability over brevity (remember, "Readability counts") is part of > why python is so good in general. > And part of the reason IPython exists is to provide for the cases when you do want brevity. Because there are times when you want to type '%run -d foo' than 'pdb.runcall(execfile, "foo.py")'. Of course, IPython has evolved - when it was only a shell, most of what you entered was just for single use, so readability wasn't hugely important. When you're writing & publishing a notebook, readability is a much bigger deal. But I've yet to see a particular problem with people abusing magic syntax and making notebooks hard to read. > * backwards compatibility (with IPP and previous IPython versions, as > well as IDL and matlab apparently?). But I'll point out that we can > easily support this too, in almost exactly the same invocation: > > %timeit('-r 5 -and -other -options') 2+3 Honestly, I wouldn't call that 'almost the same invocation'. Moreover, it sacrifices the brevity without enforcing any corresponding gain in readability. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason-sage at creativetrax.com Sat Feb 16 17:54:32 2013 From: jason-sage at creativetrax.com (Jason Grout) Date: Sat, 16 Feb 2013 16:54:32 -0600 Subject: [IPython-dev] cell magics In-Reply-To: References: <511EFB2E.5080201@creativetrax.com> <51200308.2070502@creativetrax.com> Message-ID: <51200E28.7030308@creativetrax.com> On 2/16/13 4:39 PM, Thomas Kluyver wrote: > That's quite a lot to read, but while I think about it in more detail, a > couple of bits that jump out at me: It was quite a lot to write :). > > On 16 February 2013 22:07, Jason Grout > wrote: > > %time some_function > > now I want to add a few more things to the time run. All I have to do > is change where the string is: > > %time > some_function > some_other function > > and the lack of a string after %time tells me that I should look below > %time for the string. I don't have to constantly keep adjusting the % > character(s). > > > For %%timeit, however, we use the remainder of the line as a setup > statement, before timing the body. Now you can argue that that's a bad > idea, but it's useful to have that distinction. %timeit('setup code', runs=4) some function some other function would work fine, right? Or (more explicitly) %timeit(runs=4, setup='setup code') blah blah > > P.S. Actually, after thinking about it more, since a single % is > ambiguous syntax, I think I would prefer all string decorators be > invoked with %%, which is invalid python syntax. Then we won't have > this problem: > > cd=5 > a=4\ > %cd > > or this problem: > > cd=4 > a="time: %d"\ > %cd > > > My input transformation work should handle such cases. Arguably it could > be done more easily if we used a syntax like %% that could never appear > in a valid Python statement, but it still wouldn't be trivial: > > a = """ > %%foo > """ But if it's a token-based transformer, it will know %%foo is inside a string, and it won't see that as a token. > > > ... > > I think it's pretty clear which statement is more readable. This focus > on readability over brevity (remember, "Readability counts") is part of > why python is so good in general. > > > And part of the reason IPython exists is to provide for the cases when > you do want brevity. Because there are times when you want to type '%run > -d foo' than 'pdb.runcall(execfile, "foo.py")'. > > Of course, IPython has evolved - when it was only a shell, most of what > you entered was just for single use, so readability wasn't hugely > important. When you're writing & publishing a notebook, readability is a > much bigger deal. But I've yet to see a particular problem with people > abusing magic syntax and making notebooks hard to read. And it's only the *very*, *very* beginning.... > > > * backwards compatibility (with IPP and previous IPython versions, as > > well as IDL and matlab apparently?). But I'll point out that we can > > easily support this too, in almost exactly the same invocation: > > > > %timeit('-r 5 -and -other -options') 2+3 > > Honestly, I wouldn't call that 'almost the same invocation'. Moreover, > it sacrifices the brevity without enforcing any corresponding gain in > readability. I wasn't advocating for that, of course, I was advocating for the readable version below. Thanks, Jason From fperez.net at gmail.com Sat Feb 16 17:56:40 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 16 Feb 2013 14:56:40 -0800 Subject: [IPython-dev] cell magics In-Reply-To: <51200E28.7030308@creativetrax.com> References: <511EFB2E.5080201@creativetrax.com> <51200308.2070502@creativetrax.com> <51200E28.7030308@creativetrax.com> Message-ID: On Sat, Feb 16, 2013 at 2:54 PM, Jason Grout wrote: > On 2/16/13 4:39 PM, Thomas Kluyver wrote: >> That's quite a lot to read, but while I think about it in more detail, a >> couple of bits that jump out at me: > > > It was quite a lot to write :). Just to say: I won't pitch in for a few more hours, likely tonight. In the middle of something else, and there's enough dense content here that I need to think about it and give you a proper reply. I'll do my best tonight/tomorrow. Great discussion, BTW. Cheers, f From jason-sage at creativetrax.com Sat Feb 16 18:19:54 2013 From: jason-sage at creativetrax.com (Jason Grout) Date: Sat, 16 Feb 2013 17:19:54 -0600 Subject: [IPython-dev] cell magics In-Reply-To: <51200308.2070502@creativetrax.com> References: <511EFB2E.5080201@creativetrax.com> <51200308.2070502@creativetrax.com> Message-ID: <5120141A.8010808@creativetrax.com> On 2/16/13 4:07 PM, Jason Grout wrote: > (b) the bash-like syntax is just as powerful. But it's certainly not. > With a bash-like syntax that isn't valid python code, but just a string, > I cannot pass in python objects directly. I can do that if my > parameters are valid python syntax. This is a lesson IPython learned > when it decided on a rich pyout/display_data/stream output system > instead of just passing on a stdout string. It makes sense to apply > that same lesson here to the string decorator inputs. Another point on this. Since we use straight python instead of a custom string-based syntax, we can do: k=4 %timeit(runs=k) 2+3 or %timeit(setup="x=%s"%random.random()) x+4 Using straight python instead of a custom string-based file format is something I learned from IPython when you guys made your config files actually just python files. I find it somewhat ironic now that you are arguing against making something more pythonic, and implicitly rejecting the programmability and power of having a pythonic syntax :). Thanks, Jason From takowl at gmail.com Sat Feb 16 18:52:28 2013 From: takowl at gmail.com (Thomas Kluyver) Date: Sat, 16 Feb 2013 23:52:28 +0000 Subject: [IPython-dev] cell magics In-Reply-To: <5120141A.8010808@creativetrax.com> References: <511EFB2E.5080201@creativetrax.com> <51200308.2070502@creativetrax.com> <5120141A.8010808@creativetrax.com> Message-ID: On 16 February 2013 23:19, Jason Grout wrote: > k=4 > %timeit(runs=k) 2+3 > Give us some credit, that's already possible ;-) %timeit -r $k 2+3 > Using straight python instead of a custom string-based file format is > something I learned from IPython when you guys made your config files > actually just python files. I find it somewhat ironic now that you are > arguing against making something more pythonic, and implicitly rejecting > the programmability and power of having a pythonic syntax :). > For what it's worth, with hindsight, I'm not sure executable config files were such a great idea: - There's lots of reasons that we want config that we can modify from the program - to allow GUI configuration dialogs, or changing config from with something like the %config magic. There's no really good way to do that with an executable config file. If we write the new values into the file, we could be blowing away whatever logic the user already has there. If we store them separately, then sooner or later, the user finds a config value that doesn't appear to work, because it's overridden by a value somewhere else. - More generally, executable config files force you to have a full implementation of the language to load them. That's not such a problem for us, but I noticed with the xdg-user-dirs mechanism, you can only reliably access the information by running sh in a subprocess. Config in INI, JSON or even sqlite (like Firefox) can be accessed with a simple library. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason-sage at creativetrax.com Sat Feb 16 19:14:41 2013 From: jason-sage at creativetrax.com (Jason Grout) Date: Sat, 16 Feb 2013 18:14:41 -0600 Subject: [IPython-dev] cell magics In-Reply-To: References: <511EFB2E.5080201@creativetrax.com> <51200308.2070502@creativetrax.com> <5120141A.8010808@creativetrax.com> Message-ID: <512020F1.9070900@creativetrax.com> On 2/16/13 5:52 PM, Thomas Kluyver wrote: > On 16 February 2013 23:19, Jason Grout > wrote: > > k=4 > %timeit(runs=k) 2+3 > > > Give us some credit, that's already possible ;-) > > %timeit -r $k 2+3 Cool. I didn't know that. But if k was a list (for some other parameter), and you were trying to sub it in, you'd have to convert the list to a string, then convert it back in the decorator. That's a little silly. > > Using straight python instead of a custom string-based file format is > something I learned from IPython when you guys made your config files > actually just python files. I find it somewhat ironic now that you are > arguing against making something more pythonic, and implicitly rejecting > the programmability and power of having a pythonic syntax :). > > > For what it's worth, with hindsight, I'm not sure executable config > files were such a great idea: > > - There's lots of reasons that we want config that we can modify from > the program - to allow GUI configuration dialogs, or changing config > from with something like the %config magic. There's no really good way > to do that with an executable config file. If we write the new values > into the file, we could be blowing away whatever logic the user already > has there. If we store them separately, then sooner or later, the user > finds a config value that doesn't appear to work, because it's > overridden by a value somewhere else. > > - More generally, executable config files force you to have a full > implementation of the language to load them. That's not such a problem > for us, but I noticed with the xdg-user-dirs mechanism, you can only > reliably access the information by running sh in a subprocess. Config in > INI, JSON or even sqlite (like Firefox) can be accessed with a simple > library. > Both good points! -Jason From takowl at gmail.com Sat Feb 16 19:38:24 2013 From: takowl at gmail.com (Thomas Kluyver) Date: Sun, 17 Feb 2013 00:38:24 +0000 Subject: [IPython-dev] cell magics In-Reply-To: <512020F1.9070900@creativetrax.com> References: <511EFB2E.5080201@creativetrax.com> <51200308.2070502@creativetrax.com> <5120141A.8010808@creativetrax.com> <512020F1.9070900@creativetrax.com> Message-ID: On 17 February 2013 00:14, Jason Grout wrote: > Cool. I didn't know that. But if k was a list (for some other > parameter), and you were trying to sub it in, you'd have to convert the > list to a string, then convert it back in the decorator. That's a > little silly. > In theory, but I don't think we've ever had such a case. The %%R magic has something roughly similar - you can pass in variables including arrays, like %%R -i myvar code... In that case, the magic looks in the namespaces for 'myvar', so it doesn't have to be converted to a string and back. Arguably you could pull the variable in more elegantly with your proposal, something like: %R(input=[myvar]) code But we also use the name to assign the converted variable to in R, so you'd need to provide that separately: %R(input={'myvar':myvar}) code That is slightly more flexible, but most of the time it's going to involve unnecessary repetition, in addition to the extra punctuation. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason-sage at creativetrax.com Sat Feb 16 20:26:28 2013 From: jason-sage at creativetrax.com (Jason Grout) Date: Sat, 16 Feb 2013 19:26:28 -0600 Subject: [IPython-dev] cell magics In-Reply-To: References: <511EFB2E.5080201@creativetrax.com> <51200308.2070502@creativetrax.com> <5120141A.8010808@creativetrax.com> <512020F1.9070900@creativetrax.com> Message-ID: <512031C4.3000306@creativetrax.com> On 2/16/13 6:38 PM, Thomas Kluyver wrote: > On 17 February 2013 00:14, Jason Grout > wrote: > > Cool. I didn't know that. But if k was a list (for some other > parameter), and you were trying to sub it in, you'd have to convert the > list to a string, then convert it back in the decorator. That's a > little silly. > > > In theory, but I don't think we've ever had such a case. The %%R magic > has something roughly similar - you can pass in variables including > arrays, like > > %%R -i myvar > code... > > In that case, the magic looks in the namespaces for 'myvar', so it > doesn't have to be converted to a string and back. Arguably you could > pull the variable in more elegantly with your proposal, something like: > > %R(input=[myvar]) > code > > But we also use the name to assign the converted variable to in R, so > you'd need to provide that separately: > > %R(input={'myvar':myvar}) > code > > That is slightly more flexible, but most of the time it's going to > involve unnecessary repetition, in addition to the extra punctuation. > If you were going to use the name and the value, it would make sense to do: %R(input=['myvar']) or even %R(input='myvar') -Jason From jason-sage at creativetrax.com Sat Feb 16 20:28:09 2013 From: jason-sage at creativetrax.com (Jason Grout) Date: Sat, 16 Feb 2013 19:28:09 -0600 Subject: [IPython-dev] A gallery of interesting IPython Notebooks In-Reply-To: References: Message-ID: <51203229.4050306@creativetrax.com> On 2/15/13 8:16 PM, Fernando Perez wrote: > Hi folks, > > I've just created a gallery of good/interesting/useful notebooks here: > > https://github.com/ipython/ipython/wiki/A-gallery-of-interesting-IPython-Notebooks > > Feel free to pitch in, share it, add good examples you may know of, etc. > > At some point in the future we'll have a more automated/searchable > mechanism for this, but in the meantime being able to showcase and > find good work like this, even if it requires a little manual work, > can be very handy. > > Big kudos to Matthias for having come out of left field with nbviewer. > Every day that goes by we get more mileage out of it. > Does someone want to submit this to Hacker News? It sounds like it'd be a cool link there. Jason From shaklev at gmail.com Sat Feb 16 20:33:36 2013 From: shaklev at gmail.com (=?UTF-8?Q?Stian_H=C3=A5klev?=) Date: Sat, 16 Feb 2013 20:33:36 -0500 Subject: [IPython-dev] A gallery of interesting IPython Notebooks In-Reply-To: <51203229.4050306@creativetrax.com> References: <51203229.4050306@creativetrax.com> Message-ID: Done, feel free to comment/vote up. https://news.ycombinator.com/item?id=5233855 Stian On Sat, Feb 16, 2013 at 8:28 PM, Jason Grout wrote: > On 2/15/13 8:16 PM, Fernando Perez wrote: > > Hi folks, > > > > I've just created a gallery of good/interesting/useful notebooks here: > > > > > https://github.com/ipython/ipython/wiki/A-gallery-of-interesting-IPython-Notebooks > > > > Feel free to pitch in, share it, add good examples you may know of, etc. > > > > At some point in the future we'll have a more automated/searchable > > mechanism for this, but in the meantime being able to showcase and > > find good work like this, even if it requires a little manual work, > > can be very handy. > > > > Big kudos to Matthias for having come out of left field with nbviewer. > > Every day that goes by we get more mileage out of it. > > > > > Does someone want to submit this to Hacker News? It sounds like it'd be > a cool link there. > > Jason > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- http://reganmian.net/blog -- Random Stuff that Matters -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Sat Feb 16 20:35:01 2013 From: takowl at gmail.com (Thomas Kluyver) Date: Sun, 17 Feb 2013 01:35:01 +0000 Subject: [IPython-dev] cell magics In-Reply-To: <512031C4.3000306@creativetrax.com> References: <511EFB2E.5080201@creativetrax.com> <51200308.2070502@creativetrax.com> <5120141A.8010808@creativetrax.com> <512020F1.9070900@creativetrax.com> <512031C4.3000306@creativetrax.com> Message-ID: On 17 February 2013 01:26, Jason Grout wrote: > If you were going to use the name and the value, it would make sense to do: > > %R(input=['myvar']) > Yep, that's functionally equivalent to what we do at present. > or even > > %R(input='myvar') > The list was to allow for multiple variables. You could have a special cased isinstance(input, str), but it's a bit unpythonic. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason-sage at creativetrax.com Sat Feb 16 20:52:24 2013 From: jason-sage at creativetrax.com (Jason Grout) Date: Sat, 16 Feb 2013 19:52:24 -0600 Subject: [IPython-dev] cell magics In-Reply-To: References: <511EFB2E.5080201@creativetrax.com> <51200308.2070502@creativetrax.com> <5120141A.8010808@creativetrax.com> <512020F1.9070900@creativetrax.com> <512031C4.3000306@creativetrax.com> Message-ID: <512037D8.2080007@creativetrax.com> On 2/16/13 7:35 PM, Thomas Kluyver wrote: > On 17 February 2013 01:26, Jason Grout > wrote: > > If you were going to use the name and the value, it would make sense > to do: > > %R(input=['myvar']) > > > Yep, that's functionally equivalent to what we do at present. > > or even > > %R(input='myvar') > > > The list was to allow for multiple variables. You could have a special > cased isinstance(input, str), but it's a bit unpythonic. > I see this syntax fairly often: %R(input='myvar,othervar,thirdvar') or %R(input='myvar othervar thirdvar') In fact, I got the code to parse that from the python library (IIRC): input.replace(',', ' ').split() So you could support: * a string, variables delimited by commas or whitespace * a list of strings * a dictionary if you wanted to specify the R names You could also do something like: %R(myvar=myvar, othervar=othervar) That's probably the most pythonic. Thanks, Jason From ellisonbg at gmail.com Sun Feb 17 19:50:51 2013 From: ellisonbg at gmail.com (Brian Granger) Date: Sun, 17 Feb 2013 16:50:51 -0800 Subject: [IPython-dev] cell magics In-Reply-To: <512037D8.2080007@creativetrax.com> References: <511EFB2E.5080201@creativetrax.com> <51200308.2070502@creativetrax.com> <5120141A.8010808@creativetrax.com> <512020F1.9070900@creativetrax.com> <512031C4.3000306@creativetrax.com> <512037D8.2080007@creativetrax.com> Message-ID: Jason, I apologize that I don't have much time to participate in this discussion, but I will try to summarize my thoughts. * I don't think that changing IPython's line/cell magic syntax is on table right now. * I think the syntax you are proposing has a leaky abstraction that will come back to bite you: By having the syntax 1/2 python and 1/2 unrestricted strings, you are going to be continually forced to make decisions about which things go where: Why not this: %timeit() -n1 -r1 myfunction() * I also think your proposed syntax completely misses the point of magics - namely to allow non-python syntax for quick and easy interactive usage. If you are not doing that with magics, then why not just use pure python and regular functions/classes with no "%" at all. * I agree with the namespace pollution thoughts that Fernando mentioned. Cheers, Brian On Sat, Feb 16, 2013 at 5:52 PM, Jason Grout wrote: > On 2/16/13 7:35 PM, Thomas Kluyver wrote: >> On 17 February 2013 01:26, Jason Grout > > wrote: >> >> If you were going to use the name and the value, it would make sense >> to do: >> >> %R(input=['myvar']) >> >> >> Yep, that's functionally equivalent to what we do at present. >> >> or even >> >> %R(input='myvar') >> >> >> The list was to allow for multiple variables. You could have a special >> cased isinstance(input, str), but it's a bit unpythonic. >> > > > I see this syntax fairly often: > > %R(input='myvar,othervar,thirdvar') > > or > > %R(input='myvar othervar thirdvar') > > In fact, I got the code to parse that from the python library (IIRC): > > input.replace(',', ' ').split() > > So you could support: > > * a string, variables delimited by commas or whitespace > * a list of strings > * a dictionary if you wanted to specify the R names > > You could also do something like: > > %R(myvar=myvar, othervar=othervar) > > That's probably the most pythonic. > > Thanks, > > Jason > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From fperez.net at gmail.com Sun Feb 17 23:26:21 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 17 Feb 2013 20:26:21 -0800 Subject: [IPython-dev] Index and public link to our notebook example collection Message-ID: Hi folks, one thing we've been needing badly is an easy way to link to at least our official notebook examples. I went ahead and committed without review an update to the docs and website (I didn't touch any core code, it's only a readme and a script in tools/), so now we have a real index: https://github.com/ipython/ipython/tree/master/examples/notebooks#a-collection-of-notebooks-for-using-ipython-effectively This is something we can point anyone to and that has immediately accessible links to all our intro notebooks. I've updated the front page with this and an official link to nbviewer, which was long overdue. In the end we'll want nbviewer to do this automatically, but in the meantime it's an ok solution so we have *something* that works for direct indexing of our examples. The script is a quick hack, but I'm in a huge rush and can't generalize it now. We can clean it up later. Matthias, get those analytics going :) Cheers, f ps - devs: if you add/remove/rename any notebooks, simply go to the examples dir and run ../../tools/mknbindex.py that will re-generate the index file README.md. As long as the title list doesn't change, there's no need to do this, so it shouldn't be a burden. From ellisonbg at gmail.com Sun Feb 17 23:44:58 2013 From: ellisonbg at gmail.com (Brian Granger) Date: Sun, 17 Feb 2013 20:44:58 -0800 Subject: [IPython-dev] Index and public link to our notebook example collection In-Reply-To: References: Message-ID: Fernando, Great! Thanks for doing this, it is a huge step forward to have even this level of visibility to our notebook examples. This makes me think that transitioning to notebook based narrative docs might not be too bad: * Start to put narrative notebook docs in a directory hierarchy. * For each dir in the heirarchy, auto-generate a README.md file in the same way you have done here. It is not perfect, but I think it is good enough to get us going in the right direction. Question: should our narrative docs be in a separate repo moving forward? Cheers, Brian On Sun, Feb 17, 2013 at 8:26 PM, Fernando Perez wrote: > Hi folks, > > one thing we've been needing badly is an easy way to link to at least > our official notebook examples. I went ahead and committed without > review an update to the docs and website (I didn't touch any core > code, it's only a readme and a script in tools/), so now we have a > real index: > > https://github.com/ipython/ipython/tree/master/examples/notebooks#a-collection-of-notebooks-for-using-ipython-effectively > > This is something we can point anyone to and that has immediately > accessible links to all our intro notebooks. I've updated the front > page with this and an official link to nbviewer, which was long > overdue. > > In the end we'll want nbviewer to do this automatically, but in the > meantime it's an ok solution so we have *something* that works for > direct indexing of our examples. The script is a quick hack, but I'm > in a huge rush and can't generalize it now. We can clean it up later. > > Matthias, get those analytics going :) > > Cheers, > > f > > ps - devs: if you add/remove/rename any notebooks, simply go to the > examples dir and run > > ../../tools/mknbindex.py > > that will re-generate the index file README.md. As long as the title > list doesn't change, there's no need to do this, so it shouldn't be a > burden. > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From fperez.net at gmail.com Mon Feb 18 00:17:19 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 17 Feb 2013 21:17:19 -0800 Subject: [IPython-dev] [IPython-User] Index and public link to our notebook example collection In-Reply-To: References: Message-ID: Hey, On Sun, Feb 17, 2013 at 8:44 PM, Brian Granger wrote: > Great! Thanks for doing this, it is a huge step forward to have even > this level of visibility to our notebook examples. This makes me yes, even if hackish, I'd been wanting to get this done for a long time. We can polish later. > think that transitioning to notebook based narrative docs might not be > too bad: > > * Start to put narrative notebook docs in a directory hierarchy. > * For each dir in the heirarchy, auto-generate a README.md file in the > same way you have done here. We can generalize the little script a little for that, I just didn't have time right now. That's precisely what I had in mind we could start doing. > It is not perfect, but I think it is good enough to get us going in > the right direction. I think so too, that's why I wanted to get the ball in motion. > Question: should our narrative docs be in a separate repo moving forward? Mmh, I'm very mildly in favor of keeping them together, but I'm happy to hear if anyone has a strong preference for a separate repo and their reasons. Cheers, f From ellisonbg at gmail.com Mon Feb 18 16:06:52 2013 From: ellisonbg at gmail.com (Brian Granger) Date: Mon, 18 Feb 2013 13:06:52 -0800 Subject: [IPython-dev] [IPython-User] Index and public link to our notebook example collection In-Reply-To: References: Message-ID: I am probably slightly in favor of a separate repo, but let's try to chat with everyone on HipChat about this... On Sun, Feb 17, 2013 at 9:17 PM, Fernando Perez wrote: > Hey, > > On Sun, Feb 17, 2013 at 8:44 PM, Brian Granger wrote: >> Great! Thanks for doing this, it is a huge step forward to have even >> this level of visibility to our notebook examples. This makes me > > yes, even if hackish, I'd been wanting to get this done for a long > time. We can polish later. > >> think that transitioning to notebook based narrative docs might not be >> too bad: >> >> * Start to put narrative notebook docs in a directory hierarchy. >> * For each dir in the heirarchy, auto-generate a README.md file in the >> same way you have done here. > > We can generalize the little script a little for that, I just didn't > have time right now. That's precisely what I had in mind we could > start doing. > >> It is not perfect, but I think it is good enough to get us going in >> the right direction. > > I think so too, that's why I wanted to get the ball in motion. > >> Question: should our narrative docs be in a separate repo moving forward? > > Mmh, I'm very mildly in favor of keeping them together, but I'm happy > to hear if anyone has a strong preference for a separate repo and > their reasons. > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From fperez.net at gmail.com Tue Feb 19 00:12:48 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 18 Feb 2013 21:12:48 -0800 Subject: [IPython-dev] Front page updated, new notebook page made Message-ID: Hi folks, I have a barrage of talks to give and questions keep coming up about how our site doesn't really "explain what ipython is". We also didn't really have an actual short summary page for what the notebook is... So I just: - added a more detailed and precise description of what "IPython is" to the front page. It's a bit wall-of-text, which I don't like, but I couldn't quite find a way to make it really really short while actually explaining what we do. - added a new notebook page (http://ipython.org/notebook.html). It's not enough and a bit ugly (if I centered the image it broke page layout on Chrome, so I left it with that ugly left-align). But at least we have *something* that summarizes the main point and has links to the more nifty things, like our examples or the new gallery. By all means feel free to improve either of these. But with all the presentations coming up, at least having something like this on our landing site was really necessary. Cheers, f From aron at ahmadia.net Tue Feb 19 00:17:11 2013 From: aron at ahmadia.net (Aron Ahmadia) Date: Mon, 18 Feb 2013 19:17:11 -1000 Subject: [IPython-dev] Front page updated, new notebook page made In-Reply-To: References: Message-ID: Quick copy bug in the first couple of sentences: "While the focus of the project is Python, our architecture is designed in a lanugage-agnostic way to enable interactive computing in any language." should be language-agnostic A On Mon, Feb 18, 2013 at 7:12 PM, Fernando Perez wrote: > Hi folks, > > I have a barrage of talks to give and questions keep coming up about > how our site doesn't really "explain what ipython is". We also didn't > really have an actual short summary page for what the notebook is... > > So I just: > > - added a more detailed and precise description of what "IPython is" > to the front page. It's a bit wall-of-text, which I don't like, but I > couldn't quite find a way to make it really really short while > actually explaining what we do. > > - added a new notebook page (http://ipython.org/notebook.html). It's > not enough and a bit ugly (if I centered the image it broke page > layout on Chrome, so I left it with that ugly left-align). But at > least we have *something* that summarizes the main point and has links > to the more nifty things, like our examples or the new gallery. > > By all means feel free to improve either of these. But with all the > presentations coming up, at least having something like this on our > landing site was really necessary. > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Tue Feb 19 00:19:01 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 18 Feb 2013 21:19:01 -0800 Subject: [IPython-dev] Front page updated, new notebook page made In-Reply-To: References: Message-ID: On Mon, Feb 18, 2013 at 9:17 PM, Aron Ahmadia wrote: > Quick copy bug in the first couple of sentences: > > "While the focus of the project is Python, our architecture is designed in a > lanugage-agnostic way to enable interactive computing in any language." > > should be language-agnostic Oops! Thanks, fixed. From fperez.net at gmail.com Tue Feb 19 00:36:43 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 18 Feb 2013 21:36:43 -0800 Subject: [IPython-dev] Still room for IPython tutorial at PyCon March 13 Message-ID: Hi folks, Brian, Min and I will teach an IPython tutorial in Santa Clara this year. While PyCon registration is full, if you live in the Bay Area and can make it just for the day, there's still room to sign up for it: IPython in-depth: high-productivity interactive and parallel python https://us.pycon.org/2013/schedule/presentation/20/ Here are other tutorials of interest to the science crowd: Python for Data Analysis https://us.pycon.org/2013/schedule/presentation/26/ Bayesian statistics made simple https://us.pycon.org/2013/schedule/presentation/21/ An Introduction to scikit-learn: Machine Learning in Python https://us.pycon.org/2013/schedule/presentation/22/ Advanced Machine Learning with scikit-learn https://us.pycon.org/2013/schedule/presentation/23/ Analyzing Social Networks with Python https://us.pycon.org/2013/schedule/presentation/29/ A Gentle Introduction to Computer Vision https://us.pycon.org/2013/schedule/presentation/30/ Applied Parallel Computing with Python https://us.pycon.org/2013/schedule/presentation/27/ The full tutorial schedule is here: https://us.pycon.org/2013/schedule/tutorials Cheers, f From pi at berkeley.edu Wed Feb 20 03:23:18 2013 From: pi at berkeley.edu (Paul Ivanov) Date: Wed, 20 Feb 2013 00:23:18 -0800 Subject: [IPython-dev] Roadmap to IPython 1.0 and beyond Message-ID: <20130220082318.GH25418@HbI-OTOH.berkeley.edu> HTML version of this message is up on the website [0]. TL;DR summary: Hi! IPython 1.0 coming mid-July 2013. See the grant [1] which is funding the bulk of the work, as well as our roadmap [2] for achieving the grant's objectives. There's been a lot of excitement on about the grant the IPython team received from the Sloan Foundation. The easiest way to communicate the contents of the Sloan grant is to just provide it in its entirety, which is what we've done with direct links for html [3] and pdf [4] version). The interested reader will find a description of changes coming to IPython over the next two years, as well as the motivation behind them, and the personnel involved. (For example, the astute reader of the grant will correctly infer that this email is one way in which I am filling my responsibility as "community engagement and evangelism"... GO TEAM!) Two weeks ago, the bulk of IPython's core contributors had a series of planning sessions. For three days, Brian, Fernando, Min, and I met on campus in Berkeley, with Thomas and Matthias joining in via video teleconference (and Brad, for one of the days, too). You can see the full notes from those meetings. [5] Our primary objective was to outline a plan of what work we want to accomplish in the next two years (broadly speaking) as well as to make concrete goals for our next (1.0!) release, which will land around Bastille Day (July 14th, 2013, for the uninitiated). It's kind of funny that there's a message from Fernando to [ipython-user] back in April of 2005 titled "Towards IPython 1.0, the famous big cleanup". In it [6], Fernando makes a last call for outstanding critical bugs because he's preparing users for a transition toward big changes in the IPython code base. Because, once he makes the first commit and starts working on the cleanup, he'll have to ignore every request made ?until the new shiny ipython emerges from the process, reborn in a glory which shall blind the world.? Toward the end of the email, he finishes with: "I hope the changes will be worth it, and when the dust settles, we'll have something we can call IPython 1.0"... And eight years and a few months after that email was sent, we will! :) What will 1.0 look like? Biggest changes on the user side will be the integration of nbconvert [7] into IPython proper. But that's just my summary of it, the interested reader is encouraged to read the gory details in the roadmap. that's it from me for now, here are the links 0. http://ipython.org/roadmap-announcement.html 1. http://ipython.org/sloan-grant.html 2. https://github.com/ipython/ipython/wiki/Roadmap:-IPython 3. http://ipython.org/_static/sloangrant/sloan-grant.html 4. http://ipython.org/_static/sloangrant/sloan-grant.pdf 5. https://github.com/ipython/ipython/wiki/Dev:-Meeting-notes,-February-6,-2013 6. http://mail.scipy.org/pipermail/ipython-user/2005-April/002648.html 7. https://github.com/ipython/nbconvert best, -- Paul Ivanov http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 From massimodisasha at gmail.com Sat Feb 23 08:57:01 2013 From: massimodisasha at gmail.com (epi) Date: Sat, 23 Feb 2013 08:57:01 -0500 Subject: [IPython-dev] kernel die with : 'module' object has no attribute 'dumps' Message-ID: Hi, i was using my notebook in the last days (3?) ansi had a repeated "dead kernel" message from bash i can see this log : mdistefano at epinux:~$ ipython notebook [NotebookApp] Using existing profile dir: u'/home/mdistefano/.ipython/profile_default' [NotebookApp] Serving notebooks from local directory: /home/mdistefano/dev/ecoop/trunk/python/notebook/ [NotebookApp] The IPython Notebook is running at: http://128.128.89.215:10000/ [NotebookApp] Use Control-C to stop this server and shut down all kernels. [NotebookApp] Using MathJax from CDN: http://cdn.mathjax.org/mathjax/latest/MathJax.js [NotebookApp] Kernel started: c0f6500e-bcaa-4ebc-80e6-79119b44a8a1 [NotebookApp] Connecting to: tcp://127.0.0.1:34385 DATA: [{'a': 'A', 'c': 3.0, 'b': (2, 4)}] Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python2.7/dist-packages/IPython/kernel/__init__.py", line 3, in from .connect import * File "/usr/local/lib/python2.7/dist-packages/IPython/kernel/connect.py", line 21, in import json File "json.py", line 11, in data_string = json.dumps(data) AttributeError: 'module' object has no attribute 'dumps' [NotebookApp] Connecting to: tcp://127.0.0.1:34978 [NotebookApp] Connecting to: tcp://127.0.0.1:43877 [NotebookApp] Kernel died: c0f6500e-bcaa-4ebc-80e6-79119b44a8a1 but from a standard IPython session i can do something like : epy at epinux:~$ ipython Python 2.7.3 (default, Jan 2 2013, 13:56:14) Type "copyright", "credits" or "license" for more information. IPython 1.0.dev -- An enhanced Interactive Python. ? -> Introduction and overview of IPython's features. %quickref -> Quick reference. help -> Python's own help system. object? -> Details about 'object', use 'object??' for extra details. In [1]: import json In [2]: json.dumps('data') Out[2]: '"data"' Probably something wrong on my environment, but i'm not sure, i'm tying to investigate :/ thanks for any help, --Massimo. From bussonniermatthias at gmail.com Sat Feb 23 09:50:41 2013 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Sat, 23 Feb 2013 15:50:41 +0100 Subject: [IPython-dev] kernel die with : 'module' object has no attribute 'dumps' In-Reply-To: References: Message-ID: <2134096F-1781-4F81-B21F-8053333CBE0D@gmail.com> Do you have a json.py in your --notebook-dir ? or in ~/ because > File "json.py", line 11, in > data_string = json.dumps(data) This seem like not part of IPython. (you could try a locate json.py) -- Matthias Le 23 f?vr. 2013 ? 14:57, epi a ?crit : > Hi, > > i was using my notebook in the last days (3?) ansi had a repeated "dead kernel" message > > from bash i can see this log : > > > mdistefano at epinux:~$ ipython notebook > [NotebookApp] Using existing profile dir: u'/home/mdistefano/.ipython/profile_default' > [NotebookApp] Serving notebooks from local directory: /home/mdistefano/dev/ecoop/trunk/python/notebook/ > [NotebookApp] The IPython Notebook is running at: http://128.128.89.215:10000/ > [NotebookApp] Use Control-C to stop this server and shut down all kernels. > [NotebookApp] Using MathJax from CDN: http://cdn.mathjax.org/mathjax/latest/MathJax.js > [NotebookApp] Kernel started: c0f6500e-bcaa-4ebc-80e6-79119b44a8a1 > [NotebookApp] Connecting to: tcp://127.0.0.1:34385 > DATA: [{'a': 'A', 'c': 3.0, 'b': (2, 4)}] > Traceback (most recent call last): > File "", line 1, in > File "/usr/local/lib/python2.7/dist-packages/IPython/kernel/__init__.py", line 3, in > from .connect import * > File "/usr/local/lib/python2.7/dist-packages/IPython/kernel/connect.py", line 21, in > import json > File "json.py", line 11, in > data_string = json.dumps(data) > AttributeError: 'module' object has no attribute 'dumps' > [NotebookApp] Connecting to: tcp://127.0.0.1:34978 > [NotebookApp] Connecting to: tcp://127.0.0.1:43877 > [NotebookApp] Kernel died: c0f6500e-bcaa-4ebc-80e6-79119b44a8a1 > > > > but from a standard IPython session i can do something like : > > epy at epinux:~$ ipython > Python 2.7.3 (default, Jan 2 2013, 13:56:14) > Type "copyright", "credits" or "license" for more information. > > IPython 1.0.dev -- An enhanced Interactive Python. > ? -> Introduction and overview of IPython's features. > %quickref -> Quick reference. > help -> Python's own help system. > object? -> Details about 'object', use 'object??' for extra details. > > In [1]: import json > > In [2]: json.dumps('data') > Out[2]: '"data"' > > > Probably something wrong on my environment, but i'm not sure, i'm tying to investigate :/ > > thanks for any help, > > > --Massimo. > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From massimodisasha at gmail.com Sat Feb 23 10:48:50 2013 From: massimodisasha at gmail.com (epi) Date: Sat, 23 Feb 2013 10:48:50 -0500 Subject: [IPython-dev] kernel die with : 'module' object has no attribute 'dumps' In-Reply-To: <2134096F-1781-4F81-B21F-8053333CBE0D@gmail.com> References: <2134096F-1781-4F81-B21F-8053333CBE0D@gmail.com> Message-ID: Thanks Mattias, and jtylor on irc it was a my mistake (of course) trying to learn how to work on json files (to add metadata in a notebook ) i made the mistake to name json.py my script .. and i stored it in the notebook dir :( of course 0.13 was not showing the error because it was "ignoring" my profile notebook dirfrom the profile removing the offending file, everything works fine. thanks, --Massimo. > Do you have a json.py in your --notebook-dir ? or in ~/ > > because >> File "json.py", line 11, in >> data_string = json.dumps(data) > > This seem like not part of IPython. > (you could try a locate json.py) > -- > Matthias > > Le 23 f?vr. 2013 ? 14:57, epi a ?crit : > >> Hi, >> >> i was using my notebook in the last days (3?) ansi had a repeated "dead kernel" message >> >> from bash i can see this log : >> >> >> mdistefano at epinux:~$ ipython notebook >> [NotebookApp] Using existing profile dir: u'/home/mdistefano/.ipython/profile_default' >> [NotebookApp] Serving notebooks from local directory: /home/mdistefano/dev/ecoop/trunk/python/notebook/ >> [NotebookApp] The IPython Notebook is running at: http://128.128.89.215:10000/ >> [NotebookApp] Use Control-C to stop this server and shut down all kernels. >> [NotebookApp] Using MathJax from CDN: http://cdn.mathjax.org/mathjax/latest/MathJax.js >> [NotebookApp] Kernel started: c0f6500e-bcaa-4ebc-80e6-79119b44a8a1 >> [NotebookApp] Connecting to: tcp://127.0.0.1:34385 >> DATA: [{'a': 'A', 'c': 3.0, 'b': (2, 4)}] >> Traceback (most recent call last): >> File "", line 1, in >> File "/usr/local/lib/python2.7/dist-packages/IPython/kernel/__init__.py", line 3, in >> from .connect import * >> File "/usr/local/lib/python2.7/dist-packages/IPython/kernel/connect.py", line 21, in >> import json >> File "json.py", line 11, in >> data_string = json.dumps(data) >> AttributeError: 'module' object has no attribute 'dumps' >> [NotebookApp] Connecting to: tcp://127.0.0.1:34978 >> [NotebookApp] Connecting to: tcp://127.0.0.1:43877 >> [NotebookApp] Kernel died: c0f6500e-bcaa-4ebc-80e6-79119b44a8a1 >> >> >> >> but from a standard IPython session i can do something like : >> >> epy at epinux:~$ ipython >> Python 2.7.3 (default, Jan 2 2013, 13:56:14) >> Type "copyright", "credits" or "license" for more information. >> >> IPython 1.0.dev -- An enhanced Interactive Python. >> ? -> Introduction and overview of IPython's features. >> %quickref -> Quick reference. >> help -> Python's own help system. >> object? -> Details about 'object', use 'object??' for extra details. >> >> In [1]: import json >> >> In [2]: json.dumps('data') >> Out[2]: '"data"' >> >> >> Probably something wrong on my environment, but i'm not sure, i'm tying to investigate :/ >> >> thanks for any help, >> >> >> --Massimo. >> >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From benjaminrk at gmail.com Mon Feb 25 02:01:29 2013 From: benjaminrk at gmail.com (MinRK) Date: Sun, 24 Feb 2013 23:01:29 -0800 Subject: [IPython-dev] IPEP 10: Message-ID: I've added IPEP 10: https://github.com/ipython/ipython/wiki/IPEP-10%3A-kernel-side-filtering-of-display-formats to address the issue of some library code wanting to check whether it is running in a Kernel for display-capability reasons. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Mon Feb 25 02:12:20 2013 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 25 Feb 2013 09:12:20 +0200 Subject: [IPython-dev] IPEP 10: In-Reply-To: References: Message-ID: Hi Min On Mon, Feb 25, 2013 at 9:01 AM, MinRK wrote: > I've added IPEP 10: > > https://github.com/ipython/ipython/wiki/IPEP-10%3A-kernel-side-filtering-of-display-formats Does this mean that all front-ends currently connected would need to register their supported display types with the kernel? St?fan From benjaminrk at gmail.com Mon Feb 25 02:21:57 2013 From: benjaminrk at gmail.com (Min RK) Date: Sun, 24 Feb 2013 23:21:57 -0800 Subject: [IPython-dev] IPEP 10: In-Reply-To: References: Message-ID: <01134DF6-59B6-40D5-B380-52AF74DC3707@gmail.com> On Feb 24, 2013, at 23:12, St?fan van der Walt wrote: > Hi Min > > On Mon, Feb 25, 2013 at 9:01 AM, MinRK wrote: >> I've added IPEP 10: >> >> https://github.com/ipython/ipython/wiki/IPEP-10%3A-kernel-side-filtering-of-display-formats > > Does this mean that all front-ends currently connected would need to > register their supported display types with the kernel? No, this proposal does not change the fact that the kernel is generally unaware of frontend capabilities. it only provides an avenue for limited cases, such as in-process IPython, to express their limitations and avoid wasted rendering, or for users / devs to limit which formats are displayed in general from the kernel side in an easy fashion. > > St?fan > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From stefan at sun.ac.za Mon Feb 25 02:33:06 2013 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 25 Feb 2013 09:33:06 +0200 Subject: [IPython-dev] IPEP 10: In-Reply-To: <01134DF6-59B6-40D5-B380-52AF74DC3707@gmail.com> References: <01134DF6-59B6-40D5-B380-52AF74DC3707@gmail.com> Message-ID: On Mon, Feb 25, 2013 at 9:21 AM, Min RK wrote: > No, this proposal does not change the fact that the kernel is generally unaware of frontend capabilities. > it only provides an avenue for limited cases, such as in-process IPython, to express their limitations and avoid wasted rendering, or for users / devs to limit which formats are displayed in general from the kernel side in an easy fashion. Great. To avoid the problem with separately registering active types, could one use a subclass of dict that updates a keys list on every set? St?fan From rob at roryoung.co.uk Mon Feb 25 05:03:31 2013 From: rob at roryoung.co.uk (Robert Young) Date: Mon, 25 Feb 2013 10:03:31 +0000 Subject: [IPython-dev] Hierarchical notebook listing Message-ID: Hi, This email is intended to start a conversation around hierarchical notebook listings. I submitted a pull request [1] and it was pointed out that supporting directories deserves some thought and discussion. Rob [1] https://github.com/ipython/ipython/pull/2977 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bussonniermatthias at gmail.com Mon Feb 25 12:06:14 2013 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Mon, 25 Feb 2013 18:06:14 +0100 Subject: [IPython-dev] IPEP 10: In-Reply-To: References: Message-ID: <1F100CE1-726A-41A3-917E-C1D35793E3F8@gmail.com> From a first quick read, I would be -1 on whitelisting types. The strength of nbformat is that it embeds **all** the data type that are available afterward with nbconvert for example. A frontend does not need to know how to show a format to store it in the file. -- Matthias Le 25 f?vr. 2013 ? 08:01, MinRK a ?crit : > I've added IPEP 10: > > https://github.com/ipython/ipython/wiki/IPEP-10%3A-kernel-side-filtering-of-display-formats > > to address the issue of some library code wanting to check whether it is running in a Kernel for display-capability reasons. > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Mon Feb 25 12:14:17 2013 From: benjaminrk at gmail.com (MinRK) Date: Mon, 25 Feb 2013 09:14:17 -0800 Subject: [IPython-dev] IPEP 10: In-Reply-To: <1F100CE1-726A-41A3-917E-C1D35793E3F8@gmail.com> References: <1F100CE1-726A-41A3-917E-C1D35793E3F8@gmail.com> Message-ID: On Mon, Feb 25, 2013 at 9:06 AM, Matthias BUSSONNIER < bussonniermatthias at gmail.com> wrote: > From a first quick read, I would be -1 on whitelisting types. > The strength of nbformat is that it embeds **all** the data type that are > available afterward with nbconvert for example. > A frontend does not need to know how to show a format to store it in the > file. > You have misunderstood. The principal use case for this is in-process IPython, where output is not saved, and there is zero uncertainty about unsupported display formats. The notebook is not relevant here, and this makes no changes at all to the behavior in the notebook. > > -- > Matthias > > > Le 25 f?vr. 2013 ? 08:01, MinRK a ?crit : > > I've added IPEP 10: > > > https://github.com/ipython/ipython/wiki/IPEP-10%3A-kernel-side-filtering-of-display-formats > > to address the issue of some library code wanting to check whether it is > running in a Kernel for display-capability reasons. > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bussonniermatthias at gmail.com Mon Feb 25 12:28:28 2013 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Mon, 25 Feb 2013 18:28:28 +0100 Subject: [IPython-dev] Hierarchical notebook listing In-Reply-To: References: Message-ID: Hi, I had a quick look at the code, but let's not talk about implementation. I think the question of the dashboard/filesystem is a delicate one. I already tried to hack a few things on it and I think it require a clear definition of what need to be done on the api side before refactoring it. The things that we need to considere are : - our web app is not the only client of the api (Emacs client) - backend can be databases So even if tree is a nice representation for filesytem (and I totally agree that in some case being able to see notebook a few level deeper than the current would be so much useful) It can't apply everywhere. There is also the problem that right now, the *kernel* starting directory is the same that the notebook dir, and with a tree view you can start it either on the root, or in the path of the launched ipynb. And right now, this is also a problem with db backend. On a performance side, walking all the filesystem to find all ipynb file is not very optimal neither, but we can surely hook onto indexing software to do that, and/or limit the depth. We discussed about this stuff during our last meeting, and there is also the issue with the naming/title of notebook. Notebook have a "document name" (could be different from filename) that **have to** be available **without** parsing the JSON. in filesystem this is done with the filename. There is again an issue with database. Dashboard might/ will need to know if a notebook - is already attached to a kernel, - if already opened in a new page - if other users are using it. Finally, there is an issue with the unique uuid, that we wish to make persistent across notebook launching. From at least this, and maybe other point, we should find a correct data structure that should accommodate both the backend (data base/ filesystem) and the dashboard as much as possible. IMHO: - we could include metadata in the message that could apply only on some specific dashboard. - we can't do with only one dashboard, there are specificities we can't deal with. About The PR: - It it **really** nice to see fixes on existing javascript - And tests ! But I do think we need to think about the data we send on the wire **before** going this way. Just my reflexion on this. BTW, One thing I would really **love** is having my started notebook on the top of my list, and being able to filter through the list ! -- Matthias Le 25 f?vr. 2013 ? 11:03, Robert Young a ?crit : > Hi, > > This email is intended to start a conversation around hierarchical notebook listings. I submitted a pull request [1] and it was pointed out that supporting directories deserves some thought and discussion. > > Rob > > [1] https://github.com/ipython/ipython/pull/2977 > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From bussonniermatthias at gmail.com Mon Feb 25 12:31:16 2013 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Mon, 25 Feb 2013 18:31:16 +0100 Subject: [IPython-dev] IPEP 10: In-Reply-To: References: <1F100CE1-726A-41A3-917E-C1D35793E3F8@gmail.com> Message-ID: Le 25 f?vr. 2013 ? 18:14, MinRK a ?crit : > > > On Mon, Feb 25, 2013 at 9:06 AM, Matthias BUSSONNIER wrote: > From a first quick read, I would be -1 on whitelisting types. > The strength of nbformat is that it embeds **all** the data type that are available afterward with nbconvert for example. > A frontend does not need to know how to show a format to store it in the file. > > You have misunderstood. The principal use case for this is in-process IPython, > where output is not saved, and there is zero uncertainty about unsupported display formats. > The notebook is not relevant here, and this makes no changes at all to the behavior in the notebook. Ah, ok, I missed that. Too many mails to read? -- Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Mon Feb 25 15:04:01 2013 From: benjaminrk at gmail.com (MinRK) Date: Mon, 25 Feb 2013 12:04:01 -0800 Subject: [IPython-dev] IPEP 10: In-Reply-To: References: <01134DF6-59B6-40D5-B380-52AF74DC3707@gmail.com> Message-ID: On Sun, Feb 24, 2013 at 11:33 PM, St?fan van der Walt wrote: > On Mon, Feb 25, 2013 at 9:21 AM, Min RK wrote: > > No, this proposal does not change the fact that the kernel is generally > unaware of frontend capabilities. > > it only provides an avenue for limited cases, such as in-process > IPython, to express their limitations and avoid wasted rendering, or for > users / devs to limit which formats are displayed in general from the > kernel side in an easy fashion. > > Great. > > To avoid the problem with separately registering active types, could > one use a subclass of dict that updates a keys list on every set? > I think that should be possible, I'll think about it. > > St?fan > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Mon Feb 25 18:53:06 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 25 Feb 2013 18:53:06 -0500 Subject: [IPython-dev] IPython nb on raspberry pi.. Message-ID: Hey folks, could be relevant to our plans of using the notebook at pycon on a raspberry pi: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=32&t=35050 f From ellisonbg at gmail.com Mon Feb 25 19:49:43 2013 From: ellisonbg at gmail.com (Brian Granger) Date: Mon, 25 Feb 2013 16:49:43 -0800 Subject: [IPython-dev] Hierarchical notebook listing In-Reply-To: References: Message-ID: Some of the questions we need to think about: * What does the web service look like to move around and query directories. * Do we map directory paths onto notebook URLS? If so, how? * How do we build a UI/UX that is extremely simple, but functional enough to get the job done. * How do we want to abstract these things for different notebook backend stores? * How do notebook directories get mapped to kernel cwds? Cheers, Brian On Mon, Feb 25, 2013 at 2:03 AM, Robert Young wrote: > Hi, > > This email is intended to start a conversation around hierarchical notebook > listings. I submitted a pull request [1] and it was pointed out that > supporting directories deserves some thought and discussion. > > Rob > > [1] https://github.com/ipython/ipython/pull/2977 > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From mark.voorhies at ucsf.edu Mon Feb 25 20:00:48 2013 From: mark.voorhies at ucsf.edu (Mark Voorhies) Date: Mon, 25 Feb 2013 17:00:48 -0800 Subject: [IPython-dev] Hierarchical notebook listing In-Reply-To: References: Message-ID: <512C0940.6030400@ucsf.edu> On 02/25/2013 02:03 AM, Robert Young wrote: > Hi, > > This email is intended to start a conversation around hierarchical notebook > listings. I submitted a pull request [1] and it was pointed out that > supporting directories deserves some thought and discussion. > > Rob > > [1] https://github.com/ipython/ipython/pull/2977 This doesn't speak to non-filesystem navigation or the URL problem, but Joey Hess has been doing a lot of filesystem stat hacking for the git annex assistant project (user friendly web app on top of git-annex, which adds large file support/remote tracking on top of git) -- possible source of ideas? His design blog is here: http://git-annex.branchable.com/design/assistant/blog/ --Mark From rmcgibbo at gmail.com Mon Feb 25 23:51:10 2013 From: rmcgibbo at gmail.com (Robert McGibbon) Date: Mon, 25 Feb 2013 20:51:10 -0800 Subject: [IPython-dev] IPEP 11: Tab Completion System Refactor Message-ID: Hi, I've posted IPEP 11, which is a proposal to refactor the kernel side tab completion machinery. There are two three for refactoring: the first is to provide a richer API for new tab completion matchers to interact with IPython, enabling, for example, projects like PR2701 to be done more cleanly. The second goal is to make the tab completion system less tied to GNU readline and capable of delivering richer contextual information to non-readline frontends like the notebook. The third is to clean up and simplify the existing code. https://github.com/ipython/ipython/wiki/IPEP-11%3A-Tab-Completion-System-Refactor Any and all thoughts are appreciated. -Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From bussonniermatthias at gmail.com Tue Feb 26 03:10:50 2013 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Tue, 26 Feb 2013 09:10:50 +0100 Subject: [IPython-dev] IPython nb on raspberry pi.. In-Reply-To: References: Message-ID: <14D91EF1-4E37-421B-BE94-1CD01F52D709@gmail.com> Le 26 f?vr. 2013 ? 00:53, Fernando Perez a ?crit : > Hey folks, > > could be relevant to our plans of using the notebook at pycon on a raspberry pi: > > http://www.raspberrypi.org/phpBB3/viewtopic.php?f=32&t=35050 https://github.com/ipython/ipython/issues/2974#issuecomment-13994146 This comment on github make me think it works ok... -- Matthias > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From bussonniermatthias at gmail.com Tue Feb 26 05:47:00 2013 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Tue, 26 Feb 2013 11:47:00 +0100 Subject: [IPython-dev] Hierarchical notebook listing In-Reply-To: References: Message-ID: <67358ECD-CFF9-4ED6-840D-9349F657EF32@gmail.com> Le 26 f?vr. 2013 ? 01:49, Brian Granger a ?crit : > Some of the questions we need to think about: > > * What does the web service look like to move around and query directories. > * Do we map directory paths onto notebook URLS? If so, how? > * How do we build a UI/UX that is extremely simple, but functional > enough to get the job done. > * How do we want to abstract these things for different notebook backend stores? IMHO, the "backend" should return a notebook "document name" ( not the one store in the json metadata) and a UUID when asked to "list" notebook The actual content of the notebook when asked. The actual "mapping" filesystem/url would be using uuid that are generated from hmac and path, so unique, and persistent. This also work for database | uuid | document_name | content | For the UI, I can see "breadcrumbs" to navigate in parents directory. We could also do something like github, where you show both ipynb and folder and you can enter a folder. This would require some "custom" data structure that could be exchange from dashboard and backend. -- Matthias > * How do notebook directories get mapped to kernel cwds? > Cheers, > > Brian > > On Mon, Feb 25, 2013 at 2:03 AM, Robert Young wrote: >> Hi, >> >> This email is intended to start a conversation around hierarchical notebook >> listings. I submitted a pull request [1] and it was pointed out that >> supporting directories deserves some thought and discussion. >> >> Rob >> >> [1] https://github.com/ipython/ipython/pull/2977 >> >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev >> > > > > -- > Brian E. Granger > Cal Poly State University, San Luis Obispo > bgranger at calpoly.edu and ellisonbg at gmail.com > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From pelson.pub at gmail.com Tue Feb 26 11:01:48 2013 From: pelson.pub at gmail.com (Phil Elson) Date: Tue, 26 Feb 2013 16:01:48 +0000 Subject: [IPython-dev] IPython nb on raspberry pi.. In-Reply-To: <14D91EF1-4E37-421B-BE94-1CD01F52D709@gmail.com> References: <14D91EF1-4E37-421B-BE94-1CD01F52D709@gmail.com> Message-ID: I think the two users are on different OSes. Seems like for the user on ArchArm Linux works, but for a particular Raspbian user it doesn't. I've got a RPi with Raspbian handy if you want me to test anything out. Cheers, On 26 February 2013 08:10, Matthias BUSSONNIER wrote: > > Le 26 f?vr. 2013 ? 00:53, Fernando Perez a ?crit : > > > Hey folks, > > > > could be relevant to our plans of using the notebook at pycon on a > raspberry pi: > > > > http://www.raspberrypi.org/phpBB3/viewtopic.php?f=32&t=35050 > > > https://github.com/ipython/ipython/issues/2974#issuecomment-13994146 > This comment on github make me think it works ok... > -- > Matthias > > > > > f > > _______________________________________________ > > IPython-dev mailing list > > IPython-dev at scipy.org > > http://mail.scipy.org/mailman/listinfo/ipython-dev > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Tue Feb 26 11:44:41 2013 From: takowl at gmail.com (Thomas Kluyver) Date: Tue, 26 Feb 2013 16:44:41 +0000 Subject: [IPython-dev] IPython nb on raspberry pi.. In-Reply-To: References: <14D91EF1-4E37-421B-BE94-1CD01F52D709@gmail.com> Message-ID: On 26 February 2013 16:01, Phil Elson wrote: > I think the two users are on different OSes. Seems like for the user on > ArchArm Linux works, but for a particular Raspbian user it doesn't. > > I've got a RPi with Raspbian handy if you want me to test anything out. > If you've got time, it would be great if you can try to replicate the problem that that user reported, and debug what might have caused it. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From pelson.pub at gmail.com Tue Feb 26 16:10:58 2013 From: pelson.pub at gmail.com (Phil Elson) Date: Tue, 26 Feb 2013 21:10:58 +0000 Subject: [IPython-dev] IPython nb on raspberry pi.. In-Reply-To: References: <14D91EF1-4E37-421B-BE94-1CD01F52D709@gmail.com> Message-ID: I can't replicate the problem. I installed v0.13.1 on a completely clean system with: sudo apt-get install ipython-notebook And configured a standard notebook as per the very clear docs at http://ipython.org/ipython-doc/dev/interactive/htmlnotebook.html#running-a-public-notebook-server. It all went without a hitch. Anyway, HTH - just shout if you want me to try anything specific. Regards, Phil On 26 February 2013 16:44, Thomas Kluyver wrote: > On 26 February 2013 16:01, Phil Elson wrote: > >> I think the two users are on different OSes. Seems like for the user on >> ArchArm Linux works, but for a particular Raspbian user it doesn't. >> >> I've got a RPi with Raspbian handy if you want me to test anything out. >> > > If you've got time, it would be great if you can try to replicate the > problem that that user reported, and debug what might have caused it. > > Thanks, > Thomas > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Tue Feb 26 18:40:45 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 26 Feb 2013 18:40:45 -0500 Subject: [IPython-dev] IPython nb on raspberry pi.. In-Reply-To: References: <14D91EF1-4E37-421B-BE94-1CD01F52D709@gmail.com> Message-ID: Thanks for the feedback! We want to have a demo set up for pycon using it, so this is very useful. Cheers, f On Tue, Feb 26, 2013 at 4:10 PM, Phil Elson wrote: > I can't replicate the problem. I installed v0.13.1 on a completely clean > system with: > > sudo apt-get install ipython-notebook > > And configured a standard notebook as per the very clear docs at > http://ipython.org/ipython-doc/dev/interactive/htmlnotebook.html#running-a-public-notebook-server > . It all went without a hitch. > > Anyway, HTH - just shout if you want me to try anything specific. > > Regards, > > Phil > > > On 26 February 2013 16:44, Thomas Kluyver wrote: >> >> On 26 February 2013 16:01, Phil Elson wrote: >>> >>> I think the two users are on different OSes. Seems like for the user on >>> ArchArm Linux works, but for a particular Raspbian user it doesn't. >>> >>> I've got a RPi with Raspbian handy if you want me to test anything out. >> >> >> If you've got time, it would be great if you can try to replicate the >> problem that that user reported, and debug what might have caused it. >> >> Thanks, >> Thomas >> >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev >> > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > From roberto.colistete at gmail.com Thu Feb 28 22:53:33 2013 From: roberto.colistete at gmail.com (Roberto Colistete Jr.) Date: Fri, 01 Mar 2013 00:53:33 -0300 Subject: [IPython-dev] IPython nb on raspberry pi.. In-Reply-To: References: <14D91EF1-4E37-421B-BE94-1CD01F52D709@gmail.com> Message-ID: <5130263D.8080906@gmail.com> Very nice to have IPython Notebook on Raspberry Pi. Please update the page : https://github.com/ipython/ipython/wiki/Install:-Mobile to include it. Regards, Roberto Em 26-02-2013 18:10, Phil Elson escreveu: > I can't replicate the problem. I installed v0.13.1 on a completely > clean system with: > > sudo apt-get install ipython-notebook > > And configured a standard notebook as per the very clear docs at > http://ipython.org/ipython-doc/dev/interactive/htmlnotebook.html#running-a-public-notebook-server > . It all went without a hitch. > > Anyway, HTH - just shout if you want me to try anything specific. > > Regards, > > Phil > > > On 26 February 2013 16:44, Thomas Kluyver > wrote: > > On 26 February 2013 16:01, Phil Elson > wrote: > > I think the two users are on different OSes. Seems like for > the user on ArchArm Linux works, but for a particular > Raspbian user it doesn't. > > I've got a RPi with Raspbian handy if you want me to test > anything out. > > > If you've got time, it would be great if you can try to replicate > the problem that that user reported, and debug what might have > caused it. > > Thanks, > Thomas > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: