From carl.input at gmail.com Thu Nov 1 15:49:16 2012 From: carl.input at gmail.com (Carl Smith) Date: Thu, 1 Nov 2012 19:49:16 +0000 Subject: [IPython-dev] IPython on Android In-Reply-To: <5090AC9E.6080900@creativetrax.com> References: <5090AC9E.6080900@creativetrax.com> Message-ID: Thanks for your help. I have been struggling to embed IPython in a regular Python script, so I need to figure out how many problems there are with this before I try an get the Notebook running. I just wanted thanks for all your help. I've been offline last couple of days. On Oct 31, 2012 4:44 AM, "Jason Grout" wrote: > On 10/30/12 7:07 PM, Thomas Kluyver wrote: > > On 30 October 2012 20:14, Carl Smith > > wrote: > > > > That's what I thought too. I can sort pyzmq, but not zmq itself, so > > I'm probably shot > > > > > > Is Python4Android running on top of the Java runtime, or is it CPython > > ported to Android? If it's possible to get pyzmq, maybe zmq can be > > compiled in as a static library? > > Isn't zmq support on android? http://www.zeromq.org/build:android > > See also https://github.com/zeromq/libzmq/pull/393 > > Thanks, > > Jason > > > > _______________________________________________ > 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 Mon Nov 5 16:14:10 2012 From: carl.input at gmail.com (Carl Smith) Date: Mon, 5 Nov 2012 21:14:10 +0000 Subject: [IPython-dev] Thoughts on Cloud Services Message-ID: Hi all To cut a long story short, I've not been doing much on NotebookCloud for a while now. I'm really happy with how things have gone so far, but have reached the point where I've taken it pretty much as far as I can. I will keep everything running so long as people still use it and wanted to say thanks to everyone who's supported me with this, it's been a lot of fun. I'm happy for anyone to take over nbcloud, or just ransack it to create new stuff, and I'm happy to contribute to those efforts. The thing is, as IPython's cloud features mature, the need for something like NotebookCloud will continue to diminish. Besides, it doesn't really solve many of the problems that users suffer with. If I started again, I'd be more focussed on building a library that wraps boto and StartCluster and includes the IPython code needed to create IPython setups on AWS. You'd still need to publish and maintain at least one core AMI for it to work, but users could use the library to derive and share new AMIs from the core one, so that may take care of itself before long. The feature that's requested more than anything else is the ability to create and share custom, self-configuring AMIs. That's the killer feature going forward, and it should really be available within a regular IPython session. It's nice to only need a browser to manage servers, but that's way down the list of priorities for most users. If IPython had a library that could manage IPython AWS instances, AMIs and everything else, no doubt someone would wrap that in a web app before too long anyway :) Thanks again everyone Carl From takowl at gmail.com Mon Nov 5 18:48:00 2012 From: takowl at gmail.com (Thomas Kluyver) Date: Mon, 5 Nov 2012 23:48:00 +0000 Subject: [IPython-dev] Thoughts on Cloud Services In-Reply-To: References: Message-ID: On 5 November 2012 21:14, Carl Smith wrote: > To cut a long story short, I've not been doing much on NotebookCloud > for a while now. I'm really happy with how things have gone so far, > but have reached the point where I've taken it pretty much as far as I > can. I will keep everything running so long as people still use it and > wanted to say thanks to everyone who's supported me with this, it's > been a lot of fun. I'm happy for anyone to take over nbcloud, or just > ransack it to create new stuff, and I'm happy to contribute to those > efforts. > Thanks, Carl, for the time you've put in with NotebookCloud. It's really great to be able to tell people that setting up the IPython Notebook on a dedicated Amazon cloud is as easy as a few clicks. And it's especially good to have had that available so soon after the Notebook was released. I hope someone picks it up and takes it forward in whatever form. And of course we hope you'll stick around and build us more cool stuff ;-) Best wishes, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From carl.input at gmail.com Mon Nov 5 20:46:29 2012 From: carl.input at gmail.com (Carl Smith) Date: Tue, 6 Nov 2012 01:46:29 +0000 Subject: [IPython-dev] Thoughts on Cloud Services In-Reply-To: References: Message-ID: Thanks Thomas. Of course. On Nov 5, 2012 11:48 PM, "Thomas Kluyver" wrote: > On 5 November 2012 21:14, Carl Smith wrote: > >> To cut a long story short, I've not been doing much on NotebookCloud >> for a while now. I'm really happy with how things have gone so far, >> but have reached the point where I've taken it pretty much as far as I >> can. I will keep everything running so long as people still use it and >> wanted to say thanks to everyone who's supported me with this, it's >> been a lot of fun. I'm happy for anyone to take over nbcloud, or just >> ransack it to create new stuff, and I'm happy to contribute to those >> efforts. >> > > Thanks, Carl, for the time you've put in with NotebookCloud. It's really > great to be able to tell people that setting up the IPython Notebook on a > dedicated Amazon cloud is as easy as a few clicks. And it's especially good > to have had that available so soon after the Notebook was released. I hope > someone picks it up and takes it forward in whatever form. > > And of course we hope you'll stick around and build us more cool stuff ;-) > > Best wishes, > 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 klonuo at gmail.com Tue Nov 6 12:11:50 2012 From: klonuo at gmail.com (klo uo) Date: Tue, 6 Nov 2012 18:11:50 +0100 Subject: [IPython-dev] IPEP 6: Qt console additional pane Message-ID: Hi, I opened new IPEP as suggested by Thomas: https://github.com/ipython/ipython/wiki/IPEP-6:-Qt-console---additional-pane Please take a look and provide your POV and suggestions Cheers -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Tue Nov 6 13:13:14 2012 From: takowl at gmail.com (Thomas Kluyver) Date: Tue, 6 Nov 2012 18:13:14 +0000 Subject: [IPython-dev] IPEP 6: Qt console additional pane In-Reply-To: References: Message-ID: On 6 November 2012 17:11, klo uo wrote: > I opened new IPEP as suggested by Thomas: > https://github.com/ipython/ipython/wiki/IPEP-6:-Qt-console---additional-pane Thanks! I've added some messy thoughts on my 'sidecar' idea. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From carl.input at gmail.com Tue Nov 6 20:43:31 2012 From: carl.input at gmail.com (Carl Smith) Date: Wed, 7 Nov 2012 01:43:31 +0000 Subject: [IPython-dev] A couple of odd behaviours... Message-ID: Hi all I've been playing with IPython and Android and have come across a couple of issues. In order to connect the droid to my PC, I have to run the following two commands. adb forward tcp:9999 tcp:45001 export AP_PORT=9999 For the record, adb is the Android Debug Bridge, which enables the connection. If I do the above commands in a regular shell, then launch IPython, Classic or Notebook, it all works as expected, but if I run the above commands in IPython, it fails with an adb specific error. For completeness... # SESSION !adb forward tcp:9999 tcp:45001 !export AP_PORT=9999 import android d = android.Android() # TRACEBACK gaierror Traceback (most recent call last) in () ----> 1 d = android.Android() /home/carl/droidbridge/android.pyc in __init__(self, addr) 32 if addr is None: 33 addr = HOST, PORT ---> 34 self.conn = socket.create_connection(addr) 35 self.client = self.conn.makefile() 36 self.id = 0 /usr/lib/python2.7/socket.pyc in create_connection(address, timeout, source_address) 551 host, port = address 552 err = None --> 553 for res in getaddrinfo(host, port, 0, SOCK_STREAM): 554 af, socktype, proto, canonname, sa = res 555 sock = None gaierror: [Errno -2] Name or service not known Any thoughts on this would be appreciated. Also, once I have the Notebook running, and the above problem dealt with, there's an issue with output. You can use adb to issue shell commands using `adb shell `, so `adb shell ls` runs `ls` on the droid. When I do this in the notebook, the output is blank. The page moves to show the list, so if there's three files, it renders three lines, if there five files, it renders five lines, but the lines are blank. If you drag select them with a mouse, each line is just a newline character. If you do `a = !adb shell ls`, you can eval or print `a` and get a list of the files, as you'd expect. I appreciate there's not many people around IPython Dev that will have adb to hand, but if anyone would like more details, just let me know. I'm really just hoping someone might have some idea of why this would happen. Note: In IPython Classic, `!abd shell ls` works fine. The blank lines are in the Notebook only. Cheers Carl From zvoros at gmail.com Wed Nov 7 05:39:12 2012 From: zvoros at gmail.com (=?ISO-8859-1?Q?Zolt=E1n_V=F6r=F6s?=) Date: Wed, 07 Nov 2012 11:39:12 +0100 Subject: [IPython-dev] comment on autosave Message-ID: <509A3A50.4050403@gmail.com> Hi all, I might be poking into a hornets' nest, but I was wondering whether configurably linking saving the notebook to the cell execution could appease all those who complain about autosave. My idea is that one could simply have a flag in the profile, and if that flag is set, then that.save_notebook() could be executed at the end of execute_selected_cell(). This solution should be safe in the sense that as long as the function save_notebook works, there should be absolutely no problems with using it in execute_selected_cell, and we wouldn't have to tamper with the javascript base. In any case, if you think this could be a viable option, I could try to implement it. Cheers, Zolt?n From takowl at gmail.com Wed Nov 7 06:44:54 2012 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 7 Nov 2012 11:44:54 +0000 Subject: [IPython-dev] A couple of odd behaviours... In-Reply-To: References: Message-ID: On 7 November 2012 01:43, Carl Smith wrote: > !adb forward tcp:9999 tcp:45001 > !export AP_PORT=9999 > My suspicion would be that !export doesn't propagate environment variables back to the Python process. I'd try modifying os.environ directly. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From carl.input at gmail.com Wed Nov 7 06:47:09 2012 From: carl.input at gmail.com (Carl Smith) Date: Wed, 7 Nov 2012 11:47:09 +0000 Subject: [IPython-dev] A couple of odd behaviours... In-Reply-To: References: Message-ID: Nice one. I'll look at that. Cheers Thomas. On Nov 7, 2012 11:45 AM, "Thomas Kluyver" wrote: > On 7 November 2012 01:43, Carl Smith wrote: > >> !adb forward tcp:9999 tcp:45001 >> !export AP_PORT=9999 >> > > My suspicion would be that !export doesn't propagate environment variables > back to the Python process. I'd try modifying os.environ directly. > > 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 bussonniermatthias at gmail.com Wed Nov 7 09:28:52 2012 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Wed, 7 Nov 2012 15:28:52 +0100 Subject: [IPython-dev] comment on autosave In-Reply-To: <509A3A50.4050403@gmail.com> References: <509A3A50.4050403@gmail.com> Message-ID: <9EB0D161-2D68-41CC-B00C-B75D1860533B@gmail.com> Hi Zolt?n, Le 7 nov. 2012 ? 11:39, Zolt?n V?r?s a ?crit : > Hi all, > > I might be poking into a hornets' nest, but I was wondering whether > configurably linking saving the notebook to the cell execution could > appease all those who complain about autosave. My idea is that one could > simply have a flag in the profile, and if that flag is set, then > that.save_notebook() could be executed at the end of > execute_selected_cell(). This solution should be safe in the sense that > as long as the function save_notebook works, there should be absolutely > no problems with using it in execute_selected_cell, and we wouldn't have > to tamper with the javascript base. > > In any case, if you think this could be a viable option, I could try to > implement it. Thanks for the suggestion, It is a good idea, but the problem is there is no good way yet to propagate configuration to the JS side except from the custom.js in user profile. you could listen to event 'execution_request.Kernel' and 'shell_reply.Kernel' for code execution. I don't remember the name of the event for MD cell rendering or even if there is one. (this could be added) This should be a one liner in custom.js like : $([IPython.event]).on('shell_reply.Kernel',IPython.notebook.save_notebook); I would just warn you that it does overwrite the current version of the file, whereas what you might wish is a secondary file with another name. save can take a name parameter, but then it renames the notebook instead of doing a copy so be carefull. We'll be really happy if you find a good way of propagating option from profile/command line to the browser side, or at least open an IPep about that :-) If you came up with anything you can add it to the wiki :-) -- Matthias From zvoros at gmail.com Wed Nov 7 09:31:26 2012 From: zvoros at gmail.com (=?ISO-8859-1?Q?Zolt=E1n_V=F6r=F6s?=) Date: Wed, 07 Nov 2012 15:31:26 +0100 Subject: [IPython-dev] comment on autosave In-Reply-To: <9EB0D161-2D68-41CC-B00C-B75D1860533B@gmail.com> References: <509A3A50.4050403@gmail.com> <9EB0D161-2D68-41CC-B00C-B75D1860533B@gmail.com> Message-ID: <509A70BE.5060909@gmail.com> Hi Matthias, Thanks for the comments, and I see the problems. As for overwriting the file, I had the impression that the problem was that some people don't want to bother about pressing Cntr-S. In that case, the file is overwritten anyway, so my suggestion was really just to make this mechanism automatic, without having to explicitly hit Cntr-S. But since you have already proposed a solution in your mail on the user list, I wonder there would still be any point in implementing "write-to-disc-when-executing-cell". Cheers, Zolt?n On 11/07/2012 03:28 PM, Matthias BUSSONNIER wrote: > Hi Zolt?n, > Le 7 nov. 2012 ? 11:39, Zolt?n V?r?s a ?crit : > >> Hi all, >> >> I might be poking into a hornets' nest, but I was wondering whether >> configurably linking saving the notebook to the cell execution could >> appease all those who complain about autosave. My idea is that one could >> simply have a flag in the profile, and if that flag is set, then >> that.save_notebook() could be executed at the end of >> execute_selected_cell(). This solution should be safe in the sense that >> as long as the function save_notebook works, there should be absolutely >> no problems with using it in execute_selected_cell, and we wouldn't have >> to tamper with the javascript base. >> >> In any case, if you think this could be a viable option, I could try to >> implement it. > Thanks for the suggestion, > It is a good idea, but the problem is there is no good way yet to propagate configuration to the JS side except from the custom.js in user profile. > > you could listen to event 'execution_request.Kernel' and 'shell_reply.Kernel' for code execution. > I don't remember the name of the event for MD cell rendering or even if there is one. > (this could be added) > > > This should be a one liner in custom.js like : > > $([IPython.event]).on('shell_reply.Kernel',IPython.notebook.save_notebook); > > I would just warn you that it does overwrite the current version of the file, whereas what you might wish is a secondary file with another name. > save can take a name parameter, but then it renames the notebook instead of doing a copy so be carefull. > > We'll be really happy if you find a good way of propagating option from profile/command line to the browser side, or at least open an IPep about that :-) > > If you came up with anything you can add it to the wiki :-) From carl.input at gmail.com Wed Nov 7 10:32:10 2012 From: carl.input at gmail.com (Carl Smith) Date: Wed, 7 Nov 2012 15:32:10 +0000 Subject: [IPython-dev] A couple of odd behaviours... In-Reply-To: References: Message-ID: Thanks Thomas. That was what I was missing. It's working perfectly now. I'm still lost as to why `adb shell ls` is printing blank lines, but you've cheered me up no end :) On 7 November 2012 11:47, Carl Smith wrote: > Nice one. I'll look at that. Cheers Thomas. > > On Nov 7, 2012 11:45 AM, "Thomas Kluyver" wrote: >> >> On 7 November 2012 01:43, Carl Smith wrote: >>> >>> !adb forward tcp:9999 tcp:45001 >>> !export AP_PORT=9999 >> >> >> My suspicion would be that !export doesn't propagate environment variables >> back to the Python process. I'd try modifying os.environ directly. >> >> Thomas >> >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev >> > From takowl at gmail.com Wed Nov 7 10:35:15 2012 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 7 Nov 2012 15:35:15 +0000 Subject: [IPython-dev] A couple of odd behaviours... In-Reply-To: References: Message-ID: On 7 November 2012 15:32, Carl Smith wrote: > Thanks Thomas. That was what I was missing. It's working perfectly > now. I'm still lost as to why `adb shell ls` is printing blank lines, > but you've cheered me up no end :) > Great. That one mystifies me as well. Do you see anything in the controlling terminal where you started the notebook? Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From carl.input at gmail.com Wed Nov 7 10:54:00 2012 From: carl.input at gmail.com (Carl Smith) Date: Wed, 7 Nov 2012 15:54:00 +0000 Subject: [IPython-dev] A couple of odd behaviours... In-Reply-To: References: Message-ID: Nah. Nothing unusual in the terminal. I'm going to try a few other commands, see if it sheds any light. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carl.input at gmail.com Wed Nov 7 21:42:33 2012 From: carl.input at gmail.com (Carl Smith) Date: Thu, 8 Nov 2012 02:42:33 +0000 Subject: [IPython-dev] A couple of odd behaviours... In-Reply-To: References: Message-ID: Sorry Thomas, I was wrong. I had a bug in my code that was causing things to fail silently. The answer to your question should have been "Yes, it prints everything in the terminal". I tried `pwd` and so on, and get the same behaviour. Everything printed by `!abd shell ` ends up in the terminal, not in the Notebook, though I still get a newline in the Notebook for each line that should be there. Any thoughts? On 7 November 2012 15:54, Carl Smith wrote: > Nah. Nothing unusual in the terminal. > > I'm going to try a few other commands, see if it sheds any light. From takowl at gmail.com Thu Nov 8 09:23:40 2012 From: takowl at gmail.com (Thomas Kluyver) Date: Thu, 8 Nov 2012 14:23:40 +0000 Subject: [IPython-dev] A couple of odd behaviours... In-Reply-To: References: Message-ID: On 8 November 2012 02:42, Carl Smith wrote: > I tried `pwd` and so on, and get the same behaviour. Everything > printed by `!abd shell ` ends up in the terminal, not in the > Notebook, though I still get a newline in the Notebook for each line > that should be there. > > Any thoughts? > You don't have anything in config or startup files that could be setting ip.system to ip.system_raw? Can you check that ip.system is ip.system_piped, just before an offending command? We fail to redirect C-level stdout from within the kernel process (issue #1230), but the subprocess when you run a system command should be run in a new pseudoterminal controlled by IPython, so I'm mystified why the output is going to the wrong place. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From carl.input at gmail.com Thu Nov 8 11:03:16 2012 From: carl.input at gmail.com (Carl Smith) Date: Thu, 8 Nov 2012 16:03:16 +0000 Subject: [IPython-dev] A couple of odd behaviours... In-Reply-To: References: Message-ID: I don't have anything in config or startup files at all. I was using nbcloud for ages, and reformatted this machine not so long back, so my local Notebook installation is brand new. I'm still using the default config IPython created for me, and have nothing in startup. I'm not sure how to check ip.system is ip.system_piped, but tried the following with the same result. ip = get_ipython() ip.system = ip.system_piped !adb shell ls I've noticed that it doesn't always print everything to the terminal. It seems to do it sometimes and not others, so I need to figure out what's causing the change and maybe work it out from there. If I do `ip.system = ip.system_raw`, then it always goes to the terminal, so that works. If I do `ip.system = ip.system_piped` it goes bank to printing blank lines, with nothing in the terminal. Because the printing to the terminal thing is happening on and off, well, I've only seen it happen once, I need to find out why. It can't literally be random. I did just try creating a new directory on my main machine, then launching the Notebook from that empty directory, then just running `!adb shell ls` in a new notebook. Same problem. I also tried running the three lines above to explicitly demand that my output gets piped, but to no avail. I tried using os.system, which sends stdout to the terminal, and ip.system, which prints blank lines. P.S. Why does ip.system return None? Shouldn't it return an int? On 8 November 2012 14:23, Thomas Kluyver wrote: > On 8 November 2012 02:42, Carl Smith wrote: >> >> I tried `pwd` and so on, and get the same behaviour. Everything >> printed by `!abd shell ` ends up in the terminal, not in the >> Notebook, though I still get a newline in the Notebook for each line >> that should be there. >> >> Any thoughts? > > > You don't have anything in config or startup files that could be setting > ip.system to ip.system_raw? Can you check that ip.system is ip.system_piped, > just before an offending command? > > We fail to redirect C-level stdout from within the kernel process (issue > #1230), but the subprocess when you run a system command should be run in a > new pseudoterminal controlled by IPython, so I'm mystified why the output is > going to the wrong place. > > Thomas > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > From carl.input at gmail.com Thu Nov 8 11:13:33 2012 From: carl.input at gmail.com (Carl Smith) Date: Thu, 8 Nov 2012 16:13:33 +0000 Subject: [IPython-dev] A couple of odd behaviours... In-Reply-To: References: Message-ID: On reflection, I think I may have caused stdout to go to the terminal the one time I saw that it had, by messing around trying to fix things. I'm really unsure on that one now. I may have been playing with os.system at the time. None of this is a massive problem for me as it stands. I'll probably want to return the output of all adb shell commands anyway. I've made my Android object callable, with it's args being the adb shell commands, so I can just do `a = droid('ls')`. It's pure curiosity that's got me now. On 8 November 2012 16:03, Carl Smith wrote: > I don't have anything in config or startup files at all. I was using > nbcloud for ages, and reformatted this machine not so long back, so my > local Notebook installation is brand new. I'm still using the default > config IPython created for me, and have nothing in startup. > > I'm not sure how to check ip.system is ip.system_piped, but tried the > following with the same result. > > ip = get_ipython() > ip.system = ip.system_piped > !adb shell ls > > I've noticed that it doesn't always print everything to the terminal. > It seems to do it sometimes and not others, so I need to figure out > what's causing the change and maybe work it out from there. > > If I do `ip.system = ip.system_raw`, then it always goes to the > terminal, so that works. If I do `ip.system = ip.system_piped` it goes > bank to printing blank lines, with nothing in the terminal. Because > the printing to the terminal thing is happening on and off, well, I've > only seen it happen once, I need to find out why. It can't literally > be random. > > I did just try creating a new directory on my main machine, then > launching the Notebook from that empty directory, then just running > `!adb shell ls` in a new notebook. Same problem. I also tried running > the three lines above to explicitly demand that my output gets piped, > but to no avail. > > I tried using os.system, which sends stdout to the terminal, and > ip.system, which prints blank lines. > > P.S. Why does ip.system return None? Shouldn't it return an int? > > On 8 November 2012 14:23, Thomas Kluyver wrote: >> On 8 November 2012 02:42, Carl Smith wrote: >>> >>> I tried `pwd` and so on, and get the same behaviour. Everything >>> printed by `!abd shell ` ends up in the terminal, not in the >>> Notebook, though I still get a newline in the Notebook for each line >>> that should be there. >>> >>> Any thoughts? >> >> >> You don't have anything in config or startup files that could be setting >> ip.system to ip.system_raw? Can you check that ip.system is ip.system_piped, >> just before an offending command? >> >> We fail to redirect C-level stdout from within the kernel process (issue >> #1230), but the subprocess when you run a system command should be run in a >> new pseudoterminal controlled by IPython, so I'm mystified why the output is >> going to the wrong place. >> >> Thomas >> >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev >> From carl.input at gmail.com Thu Nov 8 11:20:37 2012 From: carl.input at gmail.com (Carl Smith) Date: Thu, 8 Nov 2012 16:20:37 +0000 Subject: [IPython-dev] A couple of odd behaviours... In-Reply-To: References: Message-ID: Thanks again for your time on this Thomas. It's really kind of you to give the users so much attention, but honestly, focus on your studies mate. I don't want to think that you fell behind to deal with my obscure issues :) On 8 November 2012 16:13, Carl Smith wrote: > On reflection, I think I may have caused stdout to go to the terminal > the one time I saw that it had, by messing around trying to fix > things. I'm really unsure on that one now. I may have been playing > with os.system at the time. > > None of this is a massive problem for me as it stands. I'll probably > want to return the output of all adb shell commands anyway. I've made > my Android object callable, with it's args being the adb shell > commands, so I can just do `a = droid('ls')`. It's pure curiosity > that's got me now. > > On 8 November 2012 16:03, Carl Smith wrote: >> I don't have anything in config or startup files at all. I was using >> nbcloud for ages, and reformatted this machine not so long back, so my >> local Notebook installation is brand new. I'm still using the default >> config IPython created for me, and have nothing in startup. >> >> I'm not sure how to check ip.system is ip.system_piped, but tried the >> following with the same result. >> >> ip = get_ipython() >> ip.system = ip.system_piped >> !adb shell ls >> >> I've noticed that it doesn't always print everything to the terminal. >> It seems to do it sometimes and not others, so I need to figure out >> what's causing the change and maybe work it out from there. >> >> If I do `ip.system = ip.system_raw`, then it always goes to the >> terminal, so that works. If I do `ip.system = ip.system_piped` it goes >> bank to printing blank lines, with nothing in the terminal. Because >> the printing to the terminal thing is happening on and off, well, I've >> only seen it happen once, I need to find out why. It can't literally >> be random. >> >> I did just try creating a new directory on my main machine, then >> launching the Notebook from that empty directory, then just running >> `!adb shell ls` in a new notebook. Same problem. I also tried running >> the three lines above to explicitly demand that my output gets piped, >> but to no avail. >> >> I tried using os.system, which sends stdout to the terminal, and >> ip.system, which prints blank lines. >> >> P.S. Why does ip.system return None? Shouldn't it return an int? >> >> On 8 November 2012 14:23, Thomas Kluyver wrote: >>> On 8 November 2012 02:42, Carl Smith wrote: >>>> >>>> I tried `pwd` and so on, and get the same behaviour. Everything >>>> printed by `!abd shell ` ends up in the terminal, not in the >>>> Notebook, though I still get a newline in the Notebook for each line >>>> that should be there. >>>> >>>> Any thoughts? >>> >>> >>> You don't have anything in config or startup files that could be setting >>> ip.system to ip.system_raw? Can you check that ip.system is ip.system_piped, >>> just before an offending command? >>> >>> We fail to redirect C-level stdout from within the kernel process (issue >>> #1230), but the subprocess when you run a system command should be run in a >>> new pseudoterminal controlled by IPython, so I'm mystified why the output is >>> going to the wrong place. >>> >>> Thomas >>> >>> _______________________________________________ >>> IPython-dev mailing list >>> IPython-dev at scipy.org >>> http://mail.scipy.org/mailman/listinfo/ipython-dev >>> From takowl at gmail.com Thu Nov 8 11:40:00 2012 From: takowl at gmail.com (Thomas Kluyver) Date: Thu, 8 Nov 2012 16:40:00 +0000 Subject: [IPython-dev] A couple of odd behaviours... In-Reply-To: References: Message-ID: On 8 November 2012 16:20, Carl Smith wrote: > Thanks again for your time on this Thomas. It's really kind of you to > give the users so much attention, but honestly, focus on your studies > mate. I don't want to think that you fell behind to deal with my > obscure issues :) > Intellectual curiosity and all that ;-). I confess I'm mystified, though. Does the same thing happen in the Qt console? Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From carl.input at gmail.com Thu Nov 8 12:00:37 2012 From: carl.input at gmail.com (Carl Smith) Date: Thu, 8 Nov 2012 17:00:37 +0000 Subject: [IPython-dev] A couple of odd behaviours... In-Reply-To: References: Message-ID: I had to quickly set things up, but yeah, everything works according to spec in the console. It's just the Notebook. I'd ask on the adb list if there's anything unusual about how it works, but I think it was done in house by Google. I'm not sure. I'll have to look into it. Anyway, it works in On 8 November 2012 16:40, Thomas Kluyver wrote: > On 8 November 2012 16:20, Carl Smith wrote: >> >> Thanks again for your time on this Thomas. It's really kind of you to >> give the users so much attention, but honestly, focus on your studies >> mate. I don't want to think that you fell behind to deal with my >> obscure issues :) > > > Intellectual curiosity and all that ;-). I confess I'm mystified, though. > Does the same thing happen in the Qt console? > > Thomas > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > From carl.input at gmail.com Thu Nov 8 12:01:37 2012 From: carl.input at gmail.com (Carl Smith) Date: Thu, 8 Nov 2012 17:01:37 +0000 Subject: [IPython-dev] A couple of odd behaviours... In-Reply-To: References: Message-ID: ... the Qt console. On 8 November 2012 17:00, Carl Smith wrote: > I had to quickly set things up, but yeah, everything works according > to spec in the console. It's just the Notebook. I'd ask on the adb > list if there's anything unusual about how it works, but I think it > was done in house by Google. I'm not sure. I'll have to look into it. > > Anyway, it works in > > On 8 November 2012 16:40, Thomas Kluyver wrote: >> On 8 November 2012 16:20, Carl Smith wrote: >>> >>> Thanks again for your time on this Thomas. It's really kind of you to >>> give the users so much attention, but honestly, focus on your studies >>> mate. I don't want to think that you fell behind to deal with my >>> obscure issues :) >> >> >> Intellectual curiosity and all that ;-). I confess I'm mystified, though. >> Does the same thing happen in the Qt console? >> >> Thomas >> >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev >> From takowl at gmail.com Thu Nov 8 12:10:17 2012 From: takowl at gmail.com (Thomas Kluyver) Date: Thu, 8 Nov 2012 17:10:17 +0000 Subject: [IPython-dev] A couple of odd behaviours... In-Reply-To: References: Message-ID: On 8 November 2012 17:00, Carl Smith wrote: > I had to quickly set things up, but yeah, everything works according > to spec in the console. It's just the Notebook. I'd ask on the adb > list if there's anything unusual about how it works, but I think it > was done in house by Google. I'm not sure. I'll have to look into it. > Hmm, that's really weird, because the Qt console and the notebook use the same kernel. Can you try starting with "ipython qtconsole --debug", and finding the lines that look like this: [IPKernelApp] Content: {'user_variables': [], 'code': '!pwd\n', 'silent': False, 'allow_stdin': True, 'store_history': True, 'user_expressions': {}} ---> [IPythonQtConsoleApp] stream: {'data': '/home/thomas/Code/ubuntu/unattended-upgrades\r\n', 'name': 'stdout'} Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From carl.input at gmail.com Thu Nov 8 12:21:38 2012 From: carl.input at gmail.com (Carl Smith) Date: Thu, 8 Nov 2012 17:21:38 +0000 Subject: [IPython-dev] A couple of odd behaviours... In-Reply-To: References: Message-ID: I've got this line... [IPKernelApp] Content: {'user_variables': [], 'allow_stdin': True, 'code': "try:\n _usage\nexcept:\n from IPython.core import usage as _usage\n get_ipython().register_magic_function(_usage.page_guiref, 'line', 'guiref')\n del _usage", 'user_expressions': {}, 'silent': True} ---> There's this similar looking one too... [IPKernelApp] Content: {'user_variables': [], 'allow_stdin': True, 'code': '', 'user_expressions': {'1264bcb0-29c8-11e2-8c4f-0019d1474c91': 'get_ipython().magics_manager.lsmagic_info()'}, 'silent': True} ---> On 8 November 2012 17:10, Thomas Kluyver wrote: > On 8 November 2012 17:00, Carl Smith wrote: >> >> I had to quickly set things up, but yeah, everything works according >> to spec in the console. It's just the Notebook. I'd ask on the adb >> list if there's anything unusual about how it works, but I think it >> was done in house by Google. I'm not sure. I'll have to look into it. > > > Hmm, that's really weird, because the Qt console and the notebook use the > same kernel. Can you try starting with "ipython qtconsole --debug", and > finding the lines that look like this: > > [IPKernelApp] Content: {'user_variables': [], 'code': '!pwd\n', 'silent': > False, 'allow_stdin': True, 'store_history': True, 'user_expressions': {}} > ---> > > [IPythonQtConsoleApp] stream: {'data': > '/home/thomas/Code/ubuntu/unattended-upgrades\r\n', 'name': 'stdout'} > > Thomas > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > From carl.input at gmail.com Thu Nov 8 12:24:10 2012 From: carl.input at gmail.com (Carl Smith) Date: Thu, 8 Nov 2012 17:24:10 +0000 Subject: [IPython-dev] A couple of odd behaviours... In-Reply-To: References: Message-ID: I don't have a line from [IPythonQtConsoleApp] with `stream:` in. The closest I have is... [IPythonQtConsoleApp] execute: {'status': 'ok', 'execution_count': 0, 'user_variables': {}, 'payload': [], 'user_expressions': {}} On 8 November 2012 17:21, Carl Smith wrote: > I've got this line... > > [IPKernelApp] Content: {'user_variables': [], 'allow_stdin': True, > 'code': "try:\n _usage\nexcept:\n from IPython.core import usage > as _usage\n get_ipython().register_magic_function(_usage.page_guiref, > 'line', 'guiref')\n del _usage", 'user_expressions': {}, 'silent': > True} > ---> > > There's this similar looking one too... > > [IPKernelApp] Content: {'user_variables': [], 'allow_stdin': True, > 'code': '', 'user_expressions': > {'1264bcb0-29c8-11e2-8c4f-0019d1474c91': > 'get_ipython().magics_manager.lsmagic_info()'}, 'silent': True} > ---> > > > > On 8 November 2012 17:10, Thomas Kluyver wrote: >> On 8 November 2012 17:00, Carl Smith wrote: >>> >>> I had to quickly set things up, but yeah, everything works according >>> to spec in the console. It's just the Notebook. I'd ask on the adb >>> list if there's anything unusual about how it works, but I think it >>> was done in house by Google. I'm not sure. I'll have to look into it. >> >> >> Hmm, that's really weird, because the Qt console and the notebook use the >> same kernel. Can you try starting with "ipython qtconsole --debug", and >> finding the lines that look like this: >> >> [IPKernelApp] Content: {'user_variables': [], 'code': '!pwd\n', 'silent': >> False, 'allow_stdin': True, 'store_history': True, 'user_expressions': {}} >> ---> >> >> [IPythonQtConsoleApp] stream: {'data': >> '/home/thomas/Code/ubuntu/unattended-upgrades\r\n', 'name': 'stdout'} >> >> Thomas >> >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev >> From takowl at gmail.com Thu Nov 8 12:24:59 2012 From: takowl at gmail.com (Thomas Kluyver) Date: Thu, 8 Nov 2012 17:24:59 +0000 Subject: [IPython-dev] A couple of odd behaviours... In-Reply-To: References: Message-ID: Sorry, I should have been clearer: start the Qt console like that, then execute !adb shell ls (or any command that shows the problem). -------------- next part -------------- An HTML attachment was scrubbed... URL: From carl.input at gmail.com Thu Nov 8 12:26:52 2012 From: carl.input at gmail.com (Carl Smith) Date: Thu, 8 Nov 2012 17:26:52 +0000 Subject: [IPython-dev] A couple of odd behaviours... In-Reply-To: References: Message-ID: Got it; I needed to enter something first. This appeared after I entered `!ls` in the console. [IPythonQtConsoleApp] stream: {'data': 'Untitled0.ipynb\r\n', 'name': 'stdout'} On 8 November 2012 17:24, Carl Smith wrote: > I don't have a line from [IPythonQtConsoleApp] with `stream:` in. The > closest I have is... > > [IPythonQtConsoleApp] execute: {'status': 'ok', 'execution_count': 0, > 'user_variables': {}, 'payload': [], 'user_expressions': {}} > > On 8 November 2012 17:21, Carl Smith wrote: >> I've got this line... >> >> [IPKernelApp] Content: {'user_variables': [], 'allow_stdin': True, >> 'code': "try:\n _usage\nexcept:\n from IPython.core import usage >> as _usage\n get_ipython().register_magic_function(_usage.page_guiref, >> 'line', 'guiref')\n del _usage", 'user_expressions': {}, 'silent': >> True} >> ---> >> >> There's this similar looking one too... >> >> [IPKernelApp] Content: {'user_variables': [], 'allow_stdin': True, >> 'code': '', 'user_expressions': >> {'1264bcb0-29c8-11e2-8c4f-0019d1474c91': >> 'get_ipython().magics_manager.lsmagic_info()'}, 'silent': True} >> ---> >> >> >> >> On 8 November 2012 17:10, Thomas Kluyver wrote: >>> On 8 November 2012 17:00, Carl Smith wrote: >>>> >>>> I had to quickly set things up, but yeah, everything works according >>>> to spec in the console. It's just the Notebook. I'd ask on the adb >>>> list if there's anything unusual about how it works, but I think it >>>> was done in house by Google. I'm not sure. I'll have to look into it. >>> >>> >>> Hmm, that's really weird, because the Qt console and the notebook use the >>> same kernel. Can you try starting with "ipython qtconsole --debug", and >>> finding the lines that look like this: >>> >>> [IPKernelApp] Content: {'user_variables': [], 'code': '!pwd\n', 'silent': >>> False, 'allow_stdin': True, 'store_history': True, 'user_expressions': {}} >>> ---> >>> >>> [IPythonQtConsoleApp] stream: {'data': >>> '/home/thomas/Code/ubuntu/unattended-upgrades\r\n', 'name': 'stdout'} >>> >>> Thomas >>> >>> _______________________________________________ >>> IPython-dev mailing list >>> IPython-dev at scipy.org >>> http://mail.scipy.org/mailman/listinfo/ipython-dev >>> From carl.input at gmail.com Thu Nov 8 12:28:29 2012 From: carl.input at gmail.com (Carl Smith) Date: Thu, 8 Nov 2012 17:28:29 +0000 Subject: [IPython-dev] A couple of odd behaviours... In-Reply-To: References: Message-ID: When I did `!adb shell ls`, I got the following... [IPythonQtConsoleApp] stream: {'data': 'acct\r\r\ncache\r\r\nconfig\r\r\nd\r\r\ndata\r\r\ndefault.prop\r\r\ndev\r\r\nefs\r\r\netc\r\r\nfota.rc\r\r\ninit\r\r\ninit.goldfish.rc\r\r\ninit.rc\r\r\ninit.smdk4210.rc\r\r\ninit.smdk4210.usb.rc\r\r\nlib\r\r\nlpm.rc\r\r\nmnt\r\r\npreload\r\r\nproc\r\r\nrecovery.rc\r\r\nres\r\r\nsbin\r\r\nsdcard\r\r\nsys\r\r\nsystem\r\r\ntmp\r\r\nueventd.goldfish.rc\r\r\nueventd.rc\r\r\nueventd.smdk4210.rc\r\r\nvendor\r\r\n', 'name': 'stdout'} [IPKernelApp] {'parent_header': {'date': datetime.datetime(2012, 11, 8, 17, 27, 24, 738194), 'username': 'carl', 'session': '44bb1c02-4a19-437f-b2c4-869ee195a00b', 'msg_id': 'b4a34377-54e0-4714-bd82-e85c562682f7', 'msg_type': 'execute_request'}, 'msg_type': u'execute_reply', 'msg_id': '5d6e64a5-5007-483d-8b47-b46d6eb7d6ad', 'content': {'status': u'ok', 'execution_count': 1, 'user_variables': {}, 'payload': [], 'user_expressions': {}}, 'header': {'date': datetime.datetime(2012, 11, 8, 17, 27, 24, 973465), 'username': u'kernel', 'session': u'03382175-eff5-4e65-b5b7-d0bc0473e7a1', 'msg_id': '5d6e64a5-5007-483d-8b47-b46d6eb7d6ad', 'msg_type': u'execute_reply'}, 'tracker': , 'metadata': {'dependencies_met': True, 'engine': u'77619da4-0319-499d-90c3-43d269935d5d', 'status': u'ok', 'started': datetime.datetime(2012, 11, 8, 17, 27, 24, 742003)}} [IPythonQtConsoleApp] execute: {'status': 'ok', 'execution_count': 1, 'user_variables': {}, 'payload': [], 'user_expressions': {}} On 8 November 2012 17:24, Thomas Kluyver wrote: > Sorry, I should have been clearer: start the Qt console like that, then > execute !adb shell ls (or any command that shows the problem). > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > From takowl at gmail.com Thu Nov 8 12:32:37 2012 From: takowl at gmail.com (Thomas Kluyver) Date: Thu, 8 Nov 2012 17:32:37 +0000 Subject: [IPython-dev] A couple of odd behaviours... In-Reply-To: References: Message-ID: On 8 November 2012 17:28, Carl Smith wrote: > > 'acct\r\r\ncache\r\r\nconfig\r\r\nd\r\r\ndata\r\r\ndefault.prop\r\r\ndev\r\r\nefs\r\r\netc\r\r\nfota.rc\r\r\ninit\r\r\ninit.goldfish.rc\r\r\ninit.rc\r\r\ninit.smdk4210.rc\r\r\ninit.smdk4210.usb.rc\r\r\nlib\r\r\nlpm.rc\r\r\nmnt\r\r\npreload\r\r\nproc\r\r\nrecovery.rc\r\r\nres\r\r\nsbin\r\r\nsdcard\r\r\nsys\r\r\nsystem\r\r\ntmp\r\r\nueventd.goldfish.rc\r\r\nueventd.rc\r\r\nueventd.smdk4210.rc\r\r\nvendor\r\r\n', > I bet this is the problem. Not content with Unix line endings \n, Windows \r\n or classic Mac \r, adb appears to have decided on \r\r\n. I bet the Javascript in the notebook is handling that differently to the terminal and the Qt console, so the first \r is blanking the line. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From carl.input at gmail.com Thu Nov 8 12:37:37 2012 From: carl.input at gmail.com (Carl Smith) Date: Thu, 8 Nov 2012 17:37:37 +0000 Subject: [IPython-dev] A couple of odd behaviours... In-Reply-To: References: Message-ID: You're a genius Thomas. I'll be back in ten. I'm at home and my kids are kicking off :/ On 8 November 2012 17:32, Thomas Kluyver wrote: > On 8 November 2012 17:28, Carl Smith wrote: >> >> >> 'acct\r\r\ncache\r\r\nconfig\r\r\nd\r\r\ndata\r\r\ndefault.prop\r\r\ndev\r\r\nefs\r\r\netc\r\r\nfota.rc\r\r\ninit\r\r\ninit.goldfish.rc\r\r\ninit.rc\r\r\ninit.smdk4210.rc\r\r\ninit.smdk4210.usb.rc\r\r\nlib\r\r\nlpm.rc\r\r\nmnt\r\r\npreload\r\r\nproc\r\r\nrecovery.rc\r\r\nres\r\r\nsbin\r\r\nsdcard\r\r\nsys\r\r\nsystem\r\r\ntmp\r\r\nueventd.goldfish.rc\r\r\nueventd.rc\r\r\nueventd.smdk4210.rc\r\r\nvendor\r\r\n', > > > I bet this is the problem. Not content with Unix line endings \n, Windows > \r\n or classic Mac \r, adb appears to have decided on \r\r\n. I bet the > Javascript in the notebook is handling that differently to the terminal and > the Qt console, so the first \r is blanking the line. > > Thomas > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > From carl.input at gmail.com Thu Nov 8 12:54:21 2012 From: carl.input at gmail.com (Carl Smith) Date: Thu, 8 Nov 2012 17:54:21 +0000 Subject: [IPython-dev] A couple of odd behaviours... In-Reply-To: References: Message-ID: Sorry. Just had to do the old din-dins routine. What do you think can be done about this then? Shall I open a bug report? I'd have a go at fixing it, but wouldn't know where to start. From takowl at gmail.com Thu Nov 8 13:00:02 2012 From: takowl at gmail.com (Thomas Kluyver) Date: Thu, 8 Nov 2012 18:00:02 +0000 Subject: [IPython-dev] A couple of odd behaviours... In-Reply-To: References: Message-ID: On 8 November 2012 17:54, Carl Smith wrote: > What do you think can be done about this then? Shall I open a bug > report? I'd have a go at fixing it, but wouldn't know where to start. > Yes, do open a bug report. If you're willing to dig into the notebook javascript, it will be somewhere in there, but I don't know where. Or if you're busy, I'm sure someone will get onto it before long. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From carl.input at gmail.com Thu Nov 8 13:07:58 2012 From: carl.input at gmail.com (Carl Smith) Date: Thu, 8 Nov 2012 18:07:58 +0000 Subject: [IPython-dev] A couple of odd behaviours... In-Reply-To: References: Message-ID: I'll report it and have a look to see if I can sort it too. It should be an easy fix once I've found the code for it. Thanks again. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bussonniermatthias at gmail.com Fri Nov 9 03:39:43 2012 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Fri, 9 Nov 2012 09:39:43 +0100 Subject: [IPython-dev] Some Nbviewer stats Message-ID: <8D2C530F-2678-4AB6-B6A9-C9BD375F5C52@gmail.com> Hi all, 3 weeks ago (22 oct) I tried to enable statistics on nbviewer, sadly with our plan we are limited on the amount of data than can be stored, So I had to shut the recording of the statistics down yesterday (8 nov) after more than 10 000 pages rendered. Still I have a top 20 of the most viewed notebooks during the last 2 weeks. Number of view , url (prepend nbiewer.ipython.org/) (714) urls/raw.github.com/changhiskhan/talks/master/pydata2012/pandas_timeseries.ipynb (617) urls/raw.github.com/jseabold/538model/master/silver_model.ipynb (585) 3835181 (571) url/jakevdp.github.com/downloads/notebooks/XKCD_plots.ipynb (444) 3962843 (379) urls/raw.github.com/ipython/ipython/master/docs/examples/notebooks/00_notebook_tour.ipynb (366) 3914904 (317) urls/raw.github.com/gist/3974344/edebf73792346f771459f26c6088347dd711c212/ml_with_sklearn_notebook.ipynb (208) 2352771 (179) url/mentat.za.net/numpy/pydata/pydata2012_nyc_numpy.ipynb (164) url/lyorn.idyll.org/~t/transfer/armo-diginorm-reports.ipynb (156) urls/raw.github.com/beacon-center/intro-computational-science/master/hw-week8-which-k.ipynb (144) urls/github.com/weecology/progbio/raw/master/ipynbs/numpy.ipynb (143) urls/raw.github.com/fperez/blog/master/120907-Blogging with the IPython Notebook.ipynb (114) url/mentat.za.net/numpy/pydata/broadcast_scalar.svg (109) 3804365 (99) 3914895 (94) url/raw.github.com/weecology/progbio/master/ipynbs/testing_in_ipynb.ipynb (90) urls/raw.github.com/ipython/ipython/3607712653c66d63e0d7f13f073bde8c0f209ba8/docs/examples/notebooks/cython_extension.ipynb (84) urls/github.com/weecology/progbio/raw/master/ipynbs/matplotlib.ipynb If someone is interested I might have a Postgres backup with 2 table : 1 ) notebook_id | url 2 ) notebook_id | acces timestamp If anyone want to make nice graphs over time, I 'll be happy to send him/her the raw data. It would be interesting for example to see how silver_model had a huge increase of view after it's post on twitter, or how XKCD_plots started to increase steadily after being on the first page of nbviewer. Hopefully we will find a way to reenable the statistics in a different way. Cheers, -- Matthias From aron at ahmadia.net Fri Nov 9 03:50:35 2012 From: aron at ahmadia.net (Aron Ahmadia) Date: Fri, 9 Nov 2012 09:50:35 +0100 Subject: [IPython-dev] Some Nbviewer stats In-Reply-To: <8D2C530F-2678-4AB6-B6A9-C9BD375F5C52@gmail.com> References: <8D2C530F-2678-4AB6-B6A9-C9BD375F5C52@gmail.com> Message-ID: Wow, very cool Matthias. Somebody should write a blog post about this :) Cheers, Aron On Fri, Nov 9, 2012 at 9:39 AM, Matthias BUSSONNIER < bussonniermatthias at gmail.com> wrote: > Hi all, > > 3 weeks ago (22 oct) I tried to enable statistics on nbviewer, sadly with > our plan we are limited on the amount of data than can be stored, > So I had to shut the recording of the statistics down yesterday (8 nov) > after more than 10 000 pages rendered. > Still I have a top 20 of the most viewed notebooks during the last 2 weeks. > > Number of view , url (prepend nbiewer.ipython.org/) > > (714) urls/ > raw.github.com/changhiskhan/talks/master/pydata2012/pandas_timeseries.ipynb > (617) urls/raw.github.com/jseabold/538model/master/silver_model.ipynb > (585) 3835181 > (571) url/jakevdp.github.com/downloads/notebooks/XKCD_plots.ipynb > (444) 3962843 > (379) urls/ > raw.github.com/ipython/ipython/master/docs/examples/notebooks/00_notebook_tour.ipynb > (366) 3914904 > (317) urls/ > raw.github.com/gist/3974344/edebf73792346f771459f26c6088347dd711c212/ml_with_sklearn_notebook.ipynb > (208) 2352771 > (179) url/mentat.za.net/numpy/pydata/pydata2012_nyc_numpy.ipynb > (164) url/lyorn.idyll.org/~t/transfer/armo-diginorm-reports.ipynb > (156) urls/ > raw.github.com/beacon-center/intro-computational-science/master/hw-week8-which-k.ipynb > (144) urls/github.com/weecology/progbio/raw/master/ipynbs/numpy.ipynb > (143) urls/raw.github.com/fperez/blog/master/120907-Blogging with the > IPython Notebook.ipynb > (114) url/mentat.za.net/numpy/pydata/broadcast_scalar.svg > (109) 3804365 > (99) 3914895 > (94) url/ > raw.github.com/weecology/progbio/master/ipynbs/testing_in_ipynb.ipynb > (90) urls/ > raw.github.com/ipython/ipython/3607712653c66d63e0d7f13f073bde8c0f209ba8/docs/examples/notebooks/cython_extension.ipynb > (84) urls/github.com/weecology/progbio/raw/master/ipynbs/matplotlib.ipynb > > If someone is interested I might have a Postgres backup with 2 table : > > 1 ) notebook_id | url > 2 ) notebook_id | acces timestamp > > If anyone want to make nice graphs over time, I 'll be happy to send > him/her the raw data. > It would be interesting for example to see how silver_model had a huge > increase of view after it's post on twitter, or how XKCD_plots started to > increase steadily after being on the first page of nbviewer. > > Hopefully we will find a way to reenable the statistics in a different way. > > Cheers, > -- > Matthias > _______________________________________________ > 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 klonuo at gmail.com Fri Nov 9 08:09:51 2012 From: klonuo at gmail.com (klo uo) Date: Fri, 9 Nov 2012 14:09:51 +0100 Subject: [IPython-dev] Some Nbviewer stats In-Reply-To: References: <8D2C530F-2678-4AB6-B6A9-C9BD375F5C52@gmail.com> Message-ID: I didn't know that it can display folder like listing for (potentially) multiple notebooks, i.e. http://nbviewer.ipython.org/3974344 How does that work, in a sense if I want to do the same? On Fri, Nov 9, 2012 at 9:50 AM, Aron Ahmadia wrote: > Wow, very cool Matthias. Somebody should write a blog post about this :) > > Cheers, > Aron > > > On Fri, Nov 9, 2012 at 9:39 AM, Matthias BUSSONNIER < > bussonniermatthias at gmail.com> wrote: > >> Hi all, >> >> 3 weeks ago (22 oct) I tried to enable statistics on nbviewer, sadly >> with our plan we are limited on the amount of data than can be stored, >> So I had to shut the recording of the statistics down yesterday (8 nov) >> after more than 10 000 pages rendered. >> Still I have a top 20 of the most viewed notebooks during the last 2 >> weeks. >> >> Number of view , url (prepend nbiewer.ipython.org/) >> >> (714) urls/ >> raw.github.com/changhiskhan/talks/master/pydata2012/pandas_timeseries.ipynb >> (617) urls/raw.github.com/jseabold/538model/master/silver_model.ipynb >> (585) 3835181 >> (571) url/jakevdp.github.com/downloads/notebooks/XKCD_plots.ipynb >> (444) 3962843 >> (379) urls/ >> raw.github.com/ipython/ipython/master/docs/examples/notebooks/00_notebook_tour.ipynb >> (366) 3914904 >> (317) urls/ >> raw.github.com/gist/3974344/edebf73792346f771459f26c6088347dd711c212/ml_with_sklearn_notebook.ipynb >> (208) 2352771 >> (179) url/mentat.za.net/numpy/pydata/pydata2012_nyc_numpy.ipynb >> (164) url/lyorn.idyll.org/~t/transfer/armo-diginorm-reports.ipynb >> (156) urls/ >> raw.github.com/beacon-center/intro-computational-science/master/hw-week8-which-k.ipynb >> (144) urls/github.com/weecology/progbio/raw/master/ipynbs/numpy.ipynb >> (143) urls/raw.github.com/fperez/blog/master/120907-Blogging with the >> IPython Notebook.ipynb >> (114) url/mentat.za.net/numpy/pydata/broadcast_scalar.svg >> (109) 3804365 >> (99) 3914895 >> (94) url/ >> raw.github.com/weecology/progbio/master/ipynbs/testing_in_ipynb.ipynb >> (90) urls/ >> raw.github.com/ipython/ipython/3607712653c66d63e0d7f13f073bde8c0f209ba8/docs/examples/notebooks/cython_extension.ipynb >> (84) urls/github.com/weecology/progbio/raw/master/ipynbs/matplotlib.ipynb >> >> If someone is interested I might have a Postgres backup with 2 table : >> >> 1 ) notebook_id | url >> 2 ) notebook_id | acces timestamp >> >> If anyone want to make nice graphs over time, I 'll be happy to send >> him/her the raw data. >> It would be interesting for example to see how silver_model had a huge >> increase of view after it's post on twitter, or how XKCD_plots started to >> increase steadily after being on the first page of nbviewer. >> >> Hopefully we will find a way to reenable the statistics in a different >> way. >> >> Cheers, >> -- >> Matthias >> _______________________________________________ >> 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 Fri Nov 9 08:37:38 2012 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Fri, 9 Nov 2012 14:37:38 +0100 Subject: [IPython-dev] Some Nbviewer stats In-Reply-To: References: <8D2C530F-2678-4AB6-B6A9-C9BD375F5C52@gmail.com> Message-ID: <5CC859B9-F4AB-44D9-98B5-F8BFA09EAF83@gmail.com> Le 9 nov. 2012 ? 14:09, klo uo a ?crit : > I didn't know that it can display folder like listing for (potentially) multiple notebooks, i.e. http://nbviewer.ipython.org/3974344 > > How does that work, in a sense if I want to do the same? Just make a multi-file gist. gist are special cased, it does not work with other urls. -- Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason-sage at creativetrax.com Fri Nov 9 12:55:40 2012 From: jason-sage at creativetrax.com (Jason Grout) Date: Fri, 09 Nov 2012 11:55:40 -0600 Subject: [IPython-dev] cloud ipython Message-ID: <509D439C.1080308@creativetrax.com> Maybe this was mentioned recently? It appears to be Continuum.IO's version of a multi-user cloud python/ipython notebook. http://continuum.io/blog/introducing-wakari Thanks, Jason From fperez.net at gmail.com Mon Nov 12 00:34:21 2012 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 12 Nov 2012 00:34:21 -0500 Subject: [IPython-dev] PyCon Canada keynote went great: thanks to all of you for making me look good! Message-ID: Hi folks, I just completed a mini-marathon with two talks at U. Toronto and the closing keynote for PyCon Canada, which went unusually well. It's not very often that I get two or three applause interruptions during a conference talk and a standing ovation at the end. I really, really want to thank everyone here who is basically working so hard to ultimately make me look good; I feel almost like I'm stealing a thunder that collectively is nothing but the result of *your* work. When I started IPython, back in 2001, it was basically a crazy excuse to not work on my dissertation and a way to teach myself Python (I'd read about the language a few weeks earlier and IPython was my first Python program). I had to justify to my classmates (and later colleagues) why I thought there was any value in this, when all they saw was a 'pastime that was distracting me from doing real and useful work'. Seeing the wider community accept it now should make all of us proud. I especially want to thank Brian and Min, who did believe the crazy original idea that controlling one interactive interpreter well was the right core abstraction to build an interactive parallel computing library, back in 2004/5. They poured their amazing talent (and patience) into this effort, and there's no way we'd be where we are without them: I'm positive I would have abandoned IPython some time back if we hadn't had this small but dedicated team that believed there were genuinely good ideas worth persevering for. Ville was also instrumental in keeping things moving forward in that period, even if he has now moved on to work on other projects. And in the last few years, things have really taken off, with first Thomas, then Matthias, Paul, Brad, Evan, JD March, Jorgen, David W-F and everyone else who now keeps us forever behind on our pull request queue. Really, thanks to all of you for keeping such an amazing project moving forward. The reception we are getting is a testament to the fact that we are doing things right, and all the real credit goes to you guys. I'm going to crash now, and with David W-F's help will tomorrow see how many candidates we get for sprints work here in Toronto. It will feel good to get back to code, given how the last few months have been pretty much nothing but grants, travel and talks... Cheers, f ps - if anyone is curious, my slides are here, but it's fairly similar material to what I have in other talks (just presented with a different emphasis for this audience): https://speakerdeck.com/fperez/science-and-python-a-interactively-biased-retrospective-of-a-mostly-successful-decade I'll post the video link once it's up. From takowl at gmail.com Mon Nov 12 07:19:30 2012 From: takowl at gmail.com (Thomas Kluyver) Date: Mon, 12 Nov 2012 12:19:30 +0000 Subject: [IPython-dev] PyCon Canada keynote went great: thanks to all of you for making me look good! In-Reply-To: References: Message-ID: On 12 November 2012 05:34, Fernando Perez wrote: > I just completed a mini-marathon with two talks at U. Toronto and the > closing keynote for PyCon Canada, which went unusually well. It's not > very often that I get two or three applause interruptions during a > conference talk and a standing ovation at the end. I really, really > want to thank everyone here who is basically working so hard to > ultimately make me look good; Congratulations, Fernando! I think you've downplayed your own role: the existence of a strong team owes quite a bit to your vision and leadership. With hindsight, I'm glad that IPython was one of my first experiences of contributing to an open source project. It's still one of the most welcoming projects I've interacted with, and it's taught me a lot about good development. Good luck with the sprints - I look forward to seeing what gets done. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From massimodisasha at gmail.com Mon Nov 12 11:10:47 2012 From: massimodisasha at gmail.com (Massimo Di Stefano) Date: Mon, 12 Nov 2012 11:10:47 -0500 Subject: [IPython-dev] custom widget example : python and javascript Message-ID: Hi IPython! i was tring to learn how to code a cell in order to have interaction between python <-> Javascript (jquery?) i can try to explain with an example ? let's say i have a dictionary in python : >>>mydict = {'key1':'val1', 'key2':'val2'} and a function that take as input the dict and print out the value : >>>def printval(mydict, keyN): print maydict['keyN'] what i'm tring to learn is : how to render inside an "IPython notebook cell" a js gui tool like a "dropdown menu" that will contain the "mydict keys" and button that will connect the selected value in the dropdown menu to the printval function ? i guess it should be trivial for who knows the how the internal engine works, i was really attracted by the new "js plugin system" (i saw it in NYC at the PyData ? cool!) for me an example like this can be a perfect starting point to start to develop something useful ?. thamk you for you great support! Massimo. From bussonniermatthias at gmail.com Mon Nov 12 12:38:29 2012 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Mon, 12 Nov 2012 18:38:29 +0100 Subject: [IPython-dev] custom widget example : python and javascript In-Reply-To: References: Message-ID: <505356F2-D241-458F-A8A9-A4340084DFCA@gmail.com> Hi Massimo, The documentation is really sparse on the JS side. What you will need to do is : publish javascript form python, this javascript will have access to a `container` variable that you will have to make visible, and add all the element you which inside (using query). This javascript can bind event to `IPython.notebook.kernel.execute(code,callback)` to execute code in the kernel. you can have a look at `docs/examples/widgets/directview` where there is a drop down menu that ask you on which engine you wish to execute the code. So this should be a good starting point. Brian have also a pending PR to make things easier https://github.com/ipython/ipython/pull/2518 -- Matthias Le 12 nov. 2012 ? 17:10, Massimo Di Stefano a ?crit : > > Hi IPython! > > > i was tring to learn how to code a cell in order to have interaction between python <-> Javascript (jquery?) > > i can try to explain with an example ? > > let's say i have a dictionary in python : > > >>>> mydict = {'key1':'val1', 'key2':'val2'} > > and a function that take as input the dict and print out the value : > >>>> def printval(mydict, keyN): > print maydict['keyN'] > > > what i'm tring to learn is : > > how to render inside an "IPython notebook cell" a js gui tool like a "dropdown menu" that will contain the "mydict keys" > and button that will connect the selected value in the dropdown menu to the printval function ? > > i guess it should be trivial for who knows the how the internal engine works, i was really attracted by the new "js plugin system" (i saw it in NYC at the PyData ? cool!) > for me an example like this can be a perfect starting point to start to develop something useful ?. > > thamk you for you great support! > > Massimo. > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From ellisonbg at gmail.com Tue Nov 13 13:31:43 2012 From: ellisonbg at gmail.com (Brian Granger) Date: Tue, 13 Nov 2012 10:31:43 -0800 Subject: [IPython-dev] PyCon Canada keynote went great: thanks to all of you for making me look good! In-Reply-To: References: Message-ID: Fernando, Glad it went well! On Sun, Nov 11, 2012 at 9:34 PM, Fernando Perez wrote: > Hi folks, > > I just completed a mini-marathon with two talks at U. Toronto and the > closing keynote for PyCon Canada, which went unusually well. It's not > very often that I get two or three applause interruptions during a > conference talk and a standing ovation at the end. I really, really > want to thank everyone here who is basically working so hard to > ultimately make me look good; I feel almost like I'm stealing a > thunder that collectively is nothing but the result of *your* work. > > When I started IPython, back in 2001, it was basically a crazy excuse > to not work on my dissertation and a way to teach myself Python (I'd > read about the language a few weeks earlier and IPython was my first > Python program). I had to justify to my classmates (and later > colleagues) why I thought there was any value in this, when all they > saw was a 'pastime that was distracting me from doing real and useful > work'. Seeing the wider community accept it now should make all of us > proud. > > We are so glad you were irresponsible in not working on your thesis! I just wish I had been around at the time to join you early on. Even though it was your first python project, and by now we have refactored/rewritten most of the code, there is one thing that is perfectly clear. Your vision for the project, from day one, was spectacular. You knew exactly what people wanted and needed when working interactively - and the entire user experience reflects that. Along with your extremely generous leadership, that vision has provided a laser focus for the project that has helped us to not get too distracted with all of the new stuff. In fact, when I was designing the notebook last summer, I continually made choices to try and keep the IPython DNA in the notebook experience. > I especially want to thank Brian and Min, who did believe the crazy > original idea that controlling one interactive interpreter well was > the right core abstraction to build an interactive parallel computing > library, back in 2004/5. They poured their amazing talent (and > patience) into this effort, and there's no way we'd be where we are > without them: I'm positive I would have abandoned IPython some time > back if we hadn't had this small but dedicated team that believed > there were genuinely good ideas worth persevering for. Ville was also > instrumental in keeping things moving forward in that period, even if > he has now moved on to work on other projects. And in the last few > years, things have really taken off, with first Thomas, then > Matthias, Paul, Brad, Evan, JD March, Jorgen, David W-F and everyone > else who now keeps us forever behind on our pull request queue. > > Again, your generosity at work ;-) But it really is *our* pleasure. Cheers, Brian > Really, thanks to all of you for keeping such an amazing project > moving forward. The reception we are getting is a testament to the > fact that we are doing things right, and all the real credit goes to > you guys. > > I'm going to crash now, and with David W-F's help will tomorrow see > how many candidates we get for sprints work here in Toronto. It will > feel good to get back to code, given how the last few months have been > pretty much nothing but grants, travel and talks... > > Cheers, > > f > > ps - if anyone is curious, my slides are here, but it's fairly similar > material to what I have in other talks (just presented with a > different emphasis for this audience): > > https://speakerdeck.com/fperez/science-and-python-a-interactively-biased-retrospective-of-a-mostly-successful-decade > > I'll post the video link once it's up. > _______________________________________________ > 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 ellisonbg at gmail.com Tue Nov 13 13:37:11 2012 From: ellisonbg at gmail.com (Brian Granger) Date: Tue, 13 Nov 2012 10:37:11 -0800 Subject: [IPython-dev] custom widget example : python and javascript In-Reply-To: References: Message-ID: I would have a look at my jsonhandlers branch: https://github.com/ipython/ipython/pull/2518 And then grab the jsplugins repo: https://github.com/ipython/jsplugins These existing plugins should show you how to get started with the new APIs (which I recommend using). Cheers, Brian On Mon, Nov 12, 2012 at 8:10 AM, Massimo Di Stefano < massimodisasha at gmail.com> wrote: > > Hi IPython! > > > i was tring to learn how to code a cell in order to have interaction > between python <-> Javascript (jquery?) > > i can try to explain with an example ? > > let's say i have a dictionary in python : > > > >>>mydict = {'key1':'val1', 'key2':'val2'} > > and a function that take as input the dict and print out the value : > > >>>def printval(mydict, keyN): > print maydict['keyN'] > > > what i'm tring to learn is : > > how to render inside an "IPython notebook cell" a js gui tool like a > "dropdown menu" that will contain the "mydict keys" > and button that will connect the selected value in the dropdown menu to > the printval function ? > > i guess it should be trivial for who knows the how the internal engine > works, i was really attracted by the new "js plugin system" (i saw it in > NYC at the PyData ? cool!) > for me an example like this can be a perfect starting point to start to > develop something useful ?. > > thamk you for you great support! > > Massimo. > > _______________________________________________ > 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 fperez.net at gmail.com Tue Nov 13 17:22:17 2012 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 13 Nov 2012 17:22:17 -0500 Subject: [IPython-dev] Nice WebGL integration in the notebook at the IPython sprints at PyCon Canada (tried JSMol first) Message-ID: Hi folks, I know a number of people have asked about 3d in the notebook. We had a team try to integrate JSMol (the JS version of the venerable JMol) but they found too many bugs for that to be a viable path, and instead focused on doing it directly with pure WebGL and the new JSON management machinery. Here's a quick demo: http://www.flickr.com/photos/47156828 at N06/8183294725 they had to run and I don't have the github repo URL right now, will get it soon and will post. But it looked very nice! I'll try to make a little blog post later on with a summary of what we got done, there's been a ton of good work. Cheers, f From fperez.net at gmail.com Tue Nov 13 17:24:23 2012 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 13 Nov 2012 17:24:23 -0500 Subject: [IPython-dev] Nice WebGL integration in the notebook at the IPython sprints at PyCon Canada (tried JSMol first) In-Reply-To: References: Message-ID: ps - the user-facing code for that example is simply from MMTK.Proteins import Protein display(Protein('insulin')) I think that's an API people will like :) From takowl at gmail.com Tue Nov 13 17:39:55 2012 From: takowl at gmail.com (Thomas Kluyver) Date: Tue, 13 Nov 2012 22:39:55 +0000 Subject: [IPython-dev] Nice WebGL integration in the notebook at the IPython sprints at PyCon Canada (tried JSMol first) In-Reply-To: References: Message-ID: On 13 November 2012 22:24, Fernando Perez wrote: > from MMTK.Proteins import Protein > display(Protein('insulin')) > Awesome! Nice work, whoever was working on that. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas at pettiaux.be Wed Nov 14 02:18:08 2012 From: nicolas at pettiaux.be (Nicolas Pettiaux) Date: Wed, 14 Nov 2012 08:18:08 +0100 Subject: [IPython-dev] Hurry! Nominate Fernando Perez as free software hero by Thursday! Message-ID: Dear, I know that Fernando is reading the list and that I have not asked him before posting this. I do even without his permission. I think that Fernando Perez of ipython fame deserve the free software foundation award (Guido has already got it years ago). Please help me support him as candidate. More on the context of the award after the text, at the end of this mail. Here is what I have written so far to support (please help me finish) The following text is also in http://lite.framapad.org/p/fsfaward12 for an easy collaborative editing. Please spread this to get support. Much thanks, Nicolas ========== to be sent to award-nominations at gnu.org ======== I propose to nominate "Fernando Perez" , the leader and initial programmer of ipython for the Free software foundation award. Fernando is a great programmer from Columbia, now living in the US (Berkely, Ca) who speaks Spanish, English and French. He is truly an international leader and a extraordinary person. Fernando is the original creator and still leader of ipython (see http://ipython.org) IPython provides a rich toolkit to help you make the most out of using Python, with: * Powerful Python shells (terminal and Qt-based). * A web-based notebook with the same core features but support for code, text, mathematical expressions, inline plots and other rich media. * Support for interactive data visualization and use of GUI toolkits. * Flexible, embeddable interpreters to load into your own projects. * Easy to use, high performance tools for parallel computing. Fernando has succeded to drive and motivate a very active community that has very fruitful contact with other python communities, like sympy, iscipy, numpy and matplotlib. Thanks to Mr Perez's work's, the free software movement has a good alternative to propriatory softwares like matlab, mathematica, maple and the web site wolframalpha.com But Fernando is also an extraordinary person and friend. For example, very recently, Fernando has assisted his close friend John Hunter, the creator of Matplotlib who died from cancer at the end of August, up to creating the John Hunter fund to help his family and help create a Distinguished Service Award of the Python software foundationn whose first award in 2012 has been attributed to the late John Hunter. All this makes me recommend Fernando Perez very warmly for the FSF award 2012. Best regards, Nicolas Pettiaux ============== ---------- Forwarded message ---------- From: Free Software Foundation Date: 2012/11/14 Subject: Hurry! Nominate your free software heroes by Thursday! To: Nicolas Pettiaux Dear Free Software Supporters, This Thursday is the deadline to nominate someonefor the 15th annual Free Software Awards. The Free Software Awards recognize people and projects who have advanced free software and used it to benefit humanity. Each year, the Free Software Foundation carefully reviews nominations submitted by you, our supporters. There are so many dedicated people and inspiring projects to choose from, but we need you to nominate them. So please, in this week before Thanksgiving, take a few minutes to nominate the people and projects for which you are most thankful for the Free Software Awards. Nominations are due on November 15th--that's this Thursday. To nominate an individual for the Award for the Advancement of Free Software or a project for the Award for Projects of Social Benefit, send your nomination along with a description of the project or individual to award-nominations at gnu.org. Your nominations will be reviewed by our awards committee and the winners will be announced at LibrePlanet 2013. So check out our submission guidelinesand get those nominations in to award-nominations at gnu.org by November 15th. Thanks, Libby Reinish Campaigns Manager, Free Software Foundation PS. Help us spread the word about the 15th Annual Free Software Awards: http://ur1.ca/awieq -- Follow us on identi.ca at http://identi.ca/fsf | Subscribe to our blogs via RSS at http://fsf.org/blogs/RSS Join us as an associate member at http://fsf.org/jf *Make sure we have your correct location information? please do not forward this email with this link intact. * Sent from the Free Software Foundation, 51 Franklin Street Fifth Floor Boston, MA 02110-1335 United States You can unsubscribe to this mailing-list by visiting the link https://crm.fsf.org/index.php?q=civicrm/mailing/unsubscribe&reset=1&jid=126782&qid=2981632&h=5c8188422864cf96. To stop all email from the Free Software Foundation, including Defective by Design, and the Free Software Supporter newsletter, click this link: https://crm.fsf.org/index.php?q=civicrm/mailing/optout&reset=1&jid=126782&qid=2981632&h=5c8188422864cf96 . -- Nicolas Pettiaux, dr. sc - gsm : 0496 24 55 01 - wiki.rmll.be - wiki.wlsm.be RMLL - World libre software and culture meeting - WLSM Soutenez la candidature de Bruxelles, 6 => 11/7/2013. Liste orga sur http://lc.cx/Zia Support Brussels as candidate, July 6 to 11, 2013 - Orga list on http://lc.cx/Zia Lepacte.be - ? promouvoir les libert?s num?riques en Belgique ? - hetpact.be -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhh at crosscompute.com Wed Nov 14 08:42:19 2012 From: rhh at crosscompute.com (Roy Hyunjin Han) Date: Wed, 14 Nov 2012 08:42:19 -0500 Subject: [IPython-dev] Hurry! Nominate Fernando Perez as free software hero by Thursday! In-Reply-To: References: Message-ID: > Columbia Nicolas, I think you meant to say Colombia, with an "o" and not a "u." From nicolas at pettiaux.be Wed Nov 14 09:52:21 2012 From: nicolas at pettiaux.be (Nicolas Pettiaux) Date: Wed, 14 Nov 2012 15:52:21 +0100 Subject: [IPython-dev] Hurry! Nominate Fernando Perez as free software hero by Thursday! In-Reply-To: References: Message-ID: 2012/11/14 Roy Hyunjin Han > > Columbia > > Nicolas, I think you meant to say Colombia, with an "o" and not a "u." > indeed I think we need to send the letter individually to fsf Thanks, Nicolas -- Nicolas Pettiaux, dr. sc - gsm : 0496 24 55 01 - wiki.rmll.be - wiki.wlsm.be RMLL - World libre software and culture meeting - WLSM Soutenez la candidature de Bruxelles, 6 => 11/7/2013. Liste orga sur http://lc.cx/Zia Support Brussels as candidate, July 6 to 11, 2013 - Orga list on http://lc.cx/Zia Lepacte.be - ? promouvoir les libert?s num?riques en Belgique ? - hetpact.be -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Wed Nov 14 10:38:53 2012 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 14 Nov 2012 10:38:53 -0500 Subject: [IPython-dev] PyCon Canada keynote went great: thanks to all of you for making me look good! In-Reply-To: References: Message-ID: Hi all, the video for the talk is now up: http://pyvideo.org/video/1605/science-and-python-retrospective-of-a-mostly-s Cheers, f From fperez.net at gmail.com Wed Nov 14 10:42:37 2012 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 14 Nov 2012 10:42:37 -0500 Subject: [IPython-dev] Hurry! Nominate Fernando Perez as free software hero by Thursday! In-Reply-To: References: Message-ID: I'm sorry that I have to run now and will be offline most of the day, flying back this evening to the US, so this reply is super-rushed. I am humbled and thankful to you for the enthusiasm and support towards what I've done. But I really don't think I deserve such a thing: the scientific python community is truly a federated effort where everyone plays a role, and mine is hardly more deserving or important than that of many others. But regardless, many thanks for this vote of confidence! Awards aside, the point of all this is to continue working with such a talented and generous bunch of people doing interesting work. Cheers, f From carl.input at gmail.com Wed Nov 14 14:05:42 2012 From: carl.input at gmail.com (Carl Smith) Date: Wed, 14 Nov 2012 19:05:42 +0000 Subject: [IPython-dev] PyCon Canada keynote went great: thanks to all of you for making me look good! In-Reply-To: References: Message-ID: Great talk Fernando, and covering some really important Python history. All the SciPy Rockstars should be very proud of how far you've all come. Awesome. -------------- next part -------------- An HTML attachment was scrubbed... URL: From asmeurer at gmail.com Wed Nov 14 19:15:53 2012 From: asmeurer at gmail.com (Aaron Meurer) Date: Wed, 14 Nov 2012 17:15:53 -0700 Subject: [IPython-dev] PyCon Canada keynote went great: thanks to all of you for making me look good! In-Reply-To: References: Message-ID: The video on that page is glitchy for me. Much better to just use the version on YouTube: https://www.youtube.com/watch?v=F4rFuIb1Ie4. Aaron Meurer On Wed, Nov 14, 2012 at 8:38 AM, Fernando Perez wrote: > Hi all, > > the video for the talk is now up: > > > http://pyvideo.org/video/1605/science-and-python-retrospective-of-a-mostly-s > > 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 carl.input at gmail.com Thu Nov 15 09:27:46 2012 From: carl.input at gmail.com (Carl Smith) Date: Thu, 15 Nov 2012 14:27:46 +0000 Subject: [IPython-dev] Just looking for feedback before PR Message-ID: Hi all A couple of months ago, I posted an idea on this list and got some feedback from Thomas and Matthias. The idea is to apply default CSS to Markdown cells. Thomas suggested that the feature should be easy to disable, but on by default. I was also advised to expect a few iterations on the actual styles themselves. The PR wasn't made as I wanted to test the styles on a few real notebooks, to ensure the changes worked in practice. I've since had a chance to do that. I'm attaching my version of the Brief Tour notebook, with the styles applied, in the hope that I could get some feedback on both the styles and the new version of the notebook. I would have used nbviewer, but it currently ignores the styles tag that I've stashed inside the topmost Markdown cell. There's no urgency here at all ~ there's still plenty to iron out on both fronts anyway ~ but I'd really appreciate any input. Thanks for your time Carl # Notes * The
style rule is a hack and will be looked into some more * The Tour could really do with an example of a HTML widget communicating with the kernel, in a section called Widgets * The English hasn't been spell checked or proof read * The Acknowledgements could probably do with some editing. I didn't know much about the history of some of the libraries, and didn't know where to draw the line with what names to mention * The notebook is meant for people with no knowledge of IPython so it isn't going to teach a core dev much * The notebook is meant as a fun demo, so no real instructions on Notebook use are included -------------- next part -------------- A non-text attachment was scrubbed... Name: a_brief_tour.ipynb Type: application/octet-stream Size: 21544 bytes Desc: not available URL: From takowl at gmail.com Thu Nov 15 09:32:05 2012 From: takowl at gmail.com (Thomas Kluyver) Date: Thu, 15 Nov 2012 14:32:05 +0000 Subject: [IPython-dev] Just looking for feedback before PR In-Reply-To: References: Message-ID: On 15 November 2012 14:27, Carl Smith wrote: > I'm attaching my version of the Brief Tour notebook, with the styles > applied, in the hope that I could get some feedback on both the styles > and the new version of the notebook. I would have used nbviewer, but > it currently ignores the styles tag that I've stashed inside the > topmost Markdown cell. Hi Carl, Is it convenient to save a static HTML copy, or a PDF, from the browser? It's still unfortunately a bit inconvenient to open an ipynb file, so that might get more eyes on it. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From carl.input at gmail.com Thu Nov 15 09:42:45 2012 From: carl.input at gmail.com (Carl Smith) Date: Thu, 15 Nov 2012 14:42:45 +0000 Subject: [IPython-dev] Just looking for feedback before PR In-Reply-To: References: Message-ID: > Is it convenient to save a static HTML copy, or a PDF, from the browser? > It's still unfortunately a bit inconvenient to open an ipynb file, so that > might get more eyes on it. No problem. I'm attaching a static HTML version. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carl.input at gmail.com Thu Nov 15 09:44:22 2012 From: carl.input at gmail.com (Carl Smith) Date: Thu, 15 Nov 2012 14:44:22 +0000 Subject: [IPython-dev] Just looking for feedback before PR In-Reply-To: References: Message-ID: You'll need to download, then open the file. The View option in Gmail doesn't work at all. From takowl at gmail.com Thu Nov 15 09:56:14 2012 From: takowl at gmail.com (Thomas Kluyver) Date: Thu, 15 Nov 2012 14:56:14 +0000 Subject: [IPython-dev] Just looking for feedback before PR In-Reply-To: References: Message-ID: On 15 November 2012 14:42, Carl Smith wrote: > No problem. I'm attaching a static HTML version. Unfortunately, the browser appears to have saved it with a folder of associated files, which include stylesheets and javascript, so those are missing from the file you sent. Maybe a PDF is the best way to do it. (Minor rant: why is there no good way to store a static copy of a webpage+resources in a file? There's a proposed MHTML standard, but it seems to have failed to get traction) Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From carl.input at gmail.com Thu Nov 15 10:48:14 2012 From: carl.input at gmail.com (Carl Smith) Date: Thu, 15 Nov 2012 15:48:14 +0000 Subject: [IPython-dev] Just looking for feedback before PR In-Reply-To: References: Message-ID: I have to go out, but will put another copy up tonight. Maybe I can put it on Blogger for a few days. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Thu Nov 15 12:33:33 2012 From: ellisonbg at gmail.com (Brian Granger) Date: Thu, 15 Nov 2012 09:33:33 -0800 Subject: [IPython-dev] Just looking for feedback before PR In-Reply-To: References: Message-ID: Carl, Very nice, I like the look of this. A couple of months ago, I posted an idea on this list and got some > feedback from Thomas and Matthias. The idea is to apply default CSS to > Markdown cells. I see that you have just applied these styles to text cells, rather than the rendered_html class. Right now the tour version you are dealing with puts the heading cells in the markdown rather than using actual heading cells. I have a PR open that updates all example notebooks to use actual heading cells: I think we want to have these styles applied to the heading cells, as well as HTML output, so I would use the rendered_html class. > Thomas suggested that the feature should be easy to disable, but on by > default. I was also advised to expect a few iterations on the actual > styles themselves. The PR wasn't made as I wanted to test the styles > on a few real notebooks, to ensure the changes worked in practice. > I've since had a chance to do that. > > But there are a few bigger issues here - I think I missed the earlier discussion - so I feel like I am playing catch up. Some general thoughts on this. * There is a very specific look I have been trying to create with the notebook, namely that of a clean, empty piece of white paper. This means have a very simple, uncluttered look with an absolute minimum number of visual distractions and minimal styling. Even adding the subtle shading to the code cell's input area was a difficult decision, but one that I think does make sense. I think this is really important and is a key part of the notebook's user experience. In light of this, I think the style you have created, while very good looking, doesn't match these overall design goals. Because of this, I don't think it makes sense to have it as the default. * I regularly use custom styles in markdown cells to customize the look of individual notebooks. This is such a simple and elegant solution for customization. We should create a place on the github wiki that points to css files on gists that have nice styles such as this, that users can plug into notebooks. If this turns out to be a nice way of working, we could think about including this customization point in the notebook's (yet to be written) configuration UI. * I am willing to consider changing the notebook styling, but there has to be a clearly identified problem each change is solving. One change that I have thought about is that the current heading styles take up a bit too much vertical space. That makes it difficult to view notebooks on screens with small vertical real estate. This is a very specific problem that has a specific, focused solution. Some specific comments about your style though: * In some contexts it really is useful to emphasize the heading styles - I like how that is done here. * In general, we are using a small amount of border radius on all of our rectangles with borders. The sharp corners of the heading divs look inconsistent with the rest of the UI look. * I think the fill colors of the different heading levels need to have a more consistent color scheme. For example, right now the h1 color is grey, but the h2 level is the same as the code cells. Could you try to just lighten or darken the code cell's fill color for the different heading levels? * I am finding that font size used in notebooks is very specific to the purpose of the notebook. For example, in presentations I up the font-size dramatically. I see you are using a larger font size (16pt for text) that may or may not make sense for users. * There are many things that I do like about your style though and in some contexts I would use it. * It would be wonderful if we could start to use less for all of our css - even cooler if users could enter css using less in markdown cells. That would make it *much* easier to tune the look with a few lines of css/less. Cheers, Brian I'm attaching my version of the Brief Tour notebook, with the styles > applied, in the hope that I could get some feedback on both the styles > and the new version of the notebook. I would have used nbviewer, but > it currently ignores the styles tag that I've stashed inside the > topmost Markdown cell. > > There's no urgency here at all ~ there's still plenty to iron out on > both fronts anyway ~ but I'd really appreciate any input. > > Thanks for your time > > Carl > > # Notes > * The
style rule is a hack and will be looked into some more > * The Tour could really do with an example of a HTML widget > communicating with the kernel, in a section called Widgets > * The English hasn't been spell checked or proof read > * The Acknowledgements could probably do with some editing. I > didn't know much about the history of some of the libraries, and > didn't know where to draw the line with what names to mention > * The notebook is meant for people with no knowledge of IPython > so it isn't going to teach a core dev much > * The notebook is meant as a fun demo, so no real instructions on > Notebook use are included > > _______________________________________________ > 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 carl.input at gmail.com Thu Nov 15 13:37:34 2012 From: carl.input at gmail.com (Carl Smith) Date: Thu, 15 Nov 2012 18:37:34 +0000 Subject: [IPython-dev] Just looking for feedback before PR In-Reply-To: References: Message-ID: Cheers for the detailed feedback Brian > I see that you have just applied these styles to text cells, rather than > the rendered_html class. Right now the tour version you are dealing with > puts the heading cells in the markdown rather than using actual heading > cells. I have a PR open that updates all example notebooks to use actual > heading cells: > > I think we want to have these styles applied to the heading cells, as well > as HTML output, so I would use the rendered_html class. That's an easy edit. No problem. Can I just ask why we have header cells at all? It may be a daft question, but I always used Markdown to create headers, so I never knew what the header cells were for. Is there a good reason to have more than just code and Markdown cells? > But there are a few bigger issues here - I think I missed the earlier > discussion - so I feel like I am playing catch up. Some general thoughts on > this. It was discussed while the ML was very quiet. I think John Hunter was ill at the time. I remember the list being really quiet for a couple of weeks. > * There is a very specific look I have been trying to create with the > notebook, namely that of a clean, empty piece of white paper. This means > have a very simple, uncluttered look with an absolute minimum number of > visual distractions and minimal styling. Even adding the subtle shading to > the code cell's input area was a difficult decision, but one that I think > does make sense. I think this is really important and is a key part of the > notebook's user experience. In light of this, I think the style you have > created, while very good looking, doesn't match these overall design goals. > Because of this, I don't think it makes sense to have it as the default. I understand your point here. I really like the Notebook's super clean look, and know minimalism is more difficult to get right than it seems like it would be until you've tried it. I'll come back to this point. > * I regularly use custom styles in markdown cells to customize the look of > individual notebooks. This is such a simple and elegant solution for > customization. We should create a place on the github wiki that points to > css files on gists that have nice styles such as this, that users can plug > into notebooks. If this turns out to be a nice way of working, we could > think about including this customization point in the notebook's (yet to be > written) configuration UI. Maybe we could explore adding a simple stylesheet to each new Notebook profile. When the profile is used, the Notebook could check for that stylesheet file. If the file is empty or absent, then no style is applied, else it'll use whatever's in the stylesheet. This means users with a few profiles and no incentive to edit the styles would have a few copies of the same file on disc, but these are small files and are not using any RAM. The benefits would be that there'd be no need for a new config option, just delete the file to disable the styles, the user would have a readily accessible file to hack at, the file serves as a template, which is handy for those of us who know very little CSS, and it allows profile based configuration. > * I am willing to consider changing the notebook styling, but there has to > be a clearly identified problem each change is solving. One change that I > have thought about is that the current heading styles take up a bit too much > vertical space. That makes it difficult to view notebooks on screens with > small vertical real estate. This is a very specific problem that has a > specific, focused solution. As it stands, I don't personally see any reason to change the Notebook styling at all, but I haven't used the header cells, so I can't comment on that issue. I really like the look of the Notebook, and I'm naturally a merciless critic when it comes to art and design. It's my background. > * In general, we are using a small amount of border radius on all of our > rectangles with borders. The sharp corners of the heading divs look > inconsistent with the rest of the UI look. An easy edit. > * I think the fill colors of the different heading levels need to have a > more consistent color scheme. For example, right now the h1 color is grey, > but the h2 level is the same as the code cells. Could you try to just > lighten or darken the code cell's fill color for the different heading > levels? Is that a typo, or are you asking me to change the *code cell* fill colour? I'm thinking to lighten up the headers. I've no reason to edit the code cell CSS. It looks spot on already. > * I am finding that font size used in notebooks is very specific to the > purpose of the notebook. For example, in presentations I up the font-size > dramatically. I see you are using a larger font size (16pt for text) that > may or may not make sense for users. That's probably just my personal taste coming through. I love anti-aliasing, so I tend to give every character plenty of pixels to play with. It probably looks a bit too big to most people. > * It would be wonderful if we could start to use less for all of our css - > even cooler if users could enter css using less in markdown cells. That > would make it *much* easier to tune the look with a few lines of css/less. This sounds like a good idea, but I've not actually used less to know how well it works. I'll look it up tonight. I'm glad you like the general idea, and it's really valuable to hear the thoughts of such an experienced user. You can foresee cases that I'm not envisioning, where my approach might not be a good fit. Thanks again for your time Brian. Cheers Carl From bussonniermatthias at gmail.com Thu Nov 15 14:01:34 2012 From: bussonniermatthias at gmail.com (Matthias Bussonnier) Date: Thu, 15 Nov 2012 20:01:34 +0100 Subject: [IPython-dev] Just looking for feedback before PR In-Reply-To: References: Message-ID: Short from my phone. Longer answer later. Heading cell are used in conversion to latex/other to give section/subsection... Etc. Which is much harder otherwise as you could mix and match markdown and html hx tag. Could also help doing a notebook TOC later. Le 15 nov. 2012 19:37, "Carl Smith" a ?crit : > Cheers for the detailed feedback Brian > > > I see that you have just applied these styles to text cells, rather than > > the rendered_html class. Right now the tour version you are dealing with > > puts the heading cells in the markdown rather than using actual heading > > cells. I have a PR open that updates all example notebooks to use actual > > heading cells: > > > > I think we want to have these styles applied to the heading cells, as > well > > as HTML output, so I would use the rendered_html class. > > That's an easy edit. No problem. > > Can I just ask why we have header cells at all? It may be a daft > question, but I always used Markdown to create headers, so I never > knew what the header cells were for. Is there a good reason to have > more than just code and Markdown cells? > > > But there are a few bigger issues here - I think I missed the earlier > > discussion - so I feel like I am playing catch up. Some general > thoughts on > > this. > > It was discussed while the ML was very quiet. I think John Hunter was > ill at the time. I remember the list being really quiet for a couple > of weeks. > > > * There is a very specific look I have been trying to create with the > > notebook, namely that of a clean, empty piece of white paper. This means > > have a very simple, uncluttered look with an absolute minimum number of > > visual distractions and minimal styling. Even adding the subtle shading > to > > the code cell's input area was a difficult decision, but one that I think > > does make sense. I think this is really important and is a key part of > the > > notebook's user experience. In light of this, I think the style you have > > created, while very good looking, doesn't match these overall design > goals. > > Because of this, I don't think it makes sense to have it as the default. > > I understand your point here. I really like the Notebook's super clean > look, and know minimalism is more difficult to get right than it seems > like it would be until you've tried it. I'll come back to this point. > > > * I regularly use custom styles in markdown cells to customize the look > of > > individual notebooks. This is such a simple and elegant solution for > > customization. We should create a place on the github wiki that points > to > > css files on gists that have nice styles such as this, that users can > plug > > into notebooks. If this turns out to be a nice way of working, we could > > think about including this customization point in the notebook's (yet to > be > > written) configuration UI. > > Maybe we could explore adding a simple stylesheet to each new Notebook > profile. When the profile is used, the Notebook could check for that > stylesheet file. If the file is empty or absent, then no style is > applied, else it'll use whatever's in the stylesheet. > > This means users with a few profiles and no incentive to edit the > styles would have a few copies of the same file on disc, but these are > small files and are not using any RAM. The benefits would be that > there'd be no need for a new config option, just delete the file to > disable the styles, the user would have a readily accessible file to > hack at, the file serves as a template, which is handy for those of us > who know very little CSS, and it allows profile based configuration. > > > * I am willing to consider changing the notebook styling, but there has > to > > be a clearly identified problem each change is solving. One change that > I > > have thought about is that the current heading styles take up a bit too > much > > vertical space. That makes it difficult to view notebooks on screens > with > > small vertical real estate. This is a very specific problem that has a > > specific, focused solution. > > As it stands, I don't personally see any reason to change the Notebook > styling at all, but I haven't used the header cells, so I can't > comment on that issue. I really like the look of the Notebook, and I'm > naturally a merciless critic when it comes to art and design. It's my > background. > > > * In general, we are using a small amount of border radius on all of our > > rectangles with borders. The sharp corners of the heading divs look > > inconsistent with the rest of the UI look. > > An easy edit. > > > * I think the fill colors of the different heading levels need to have a > > more consistent color scheme. For example, right now the h1 color is > grey, > > but the h2 level is the same as the code cells. Could you try to just > > lighten or darken the code cell's fill color for the different heading > > levels? > > Is that a typo, or are you asking me to change the *code cell* fill > colour? I'm thinking to lighten up the headers. I've no reason to edit > the code cell CSS. It looks spot on already. > > > * I am finding that font size used in notebooks is very specific to the > > purpose of the notebook. For example, in presentations I up the > font-size > > dramatically. I see you are using a larger font size (16pt for text) > that > > may or may not make sense for users. > > That's probably just my personal taste coming through. I love > anti-aliasing, so I tend to give every character plenty of pixels to > play with. It probably looks a bit too big to most people. > > > * It would be wonderful if we could start to use less for all of our css > - > > even cooler if users could enter css using less in markdown cells. That > > would make it *much* easier to tune the look with a few lines of > css/less. > > This sounds like a good idea, but I've not actually used less to know > how well it works. I'll look it up tonight. > > I'm glad you like the general idea, and it's really valuable to hear > the thoughts of such an experienced user. You can foresee cases that > I'm not envisioning, where my approach might not be a good fit. > > Thanks again for your time Brian. > > Cheers > > Carl > _______________________________________________ > 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 Thu Nov 15 14:04:23 2012 From: carl.input at gmail.com (Carl Smith) Date: Thu, 15 Nov 2012 19:04:23 +0000 Subject: [IPython-dev] Just looking for feedback before PR In-Reply-To: References: Message-ID: Thanks Matthias. It's not something I'd normally come across personally. I just assumed there was a good reason, IPython being pretty demanding of good reasoning for new features. Thanks again From bussonniermatthias at gmail.com Thu Nov 15 14:46:00 2012 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Thu, 15 Nov 2012 20:46:00 +0100 Subject: [IPython-dev] Just looking for feedback before PR In-Reply-To: References: Message-ID: <317EAFE2-9755-4839-AA5E-8BEA916CC14E@gmail.com> > Maybe we could explore adding a simple stylesheet to each new Notebook > profile. When the profile is used, the Notebook could check for that > stylesheet file. If the file is empty or absent, then no style is > applied, else it'll use whatever's in the stylesheet. > > This means users with a few profiles and no incentive to edit the > styles would have a few copies of the same file on disc, but these are > small files and are not using any RAM. The benefits would be that > there'd be no need for a new config option, just delete the file to > disable the styles, the user would have a readily accessible file to > hack at, the file serves as a template, which is handy for those of us > who know very little CSS, and it allows profile based configuration. let's call it is .profile_xxx/static/css/custom.css let's do the same with js. let's all go to scipy2012 and ask min to do it in 10min... Tada ! (the template being the default css files) BTW you can over rite any ipyton css/js files by creating a file with the same name in .profile_xxx/static/ > > This sounds like a good idea, but I've not actually used less to know > how well it works. I'll look it up tonight. less is basically css with variable and nested rules. speaking of nested rules. in cell.js and similar when selecting js does : this.element.addClass('ui-widget-content ui-corner-all'); (and unselecting removes it of course) With less you can change that to : -> this.element.addClass('cell-selected'); and create a less rule : import jquerytheme.css .codecell-selected { .ui-widget-content; .ui-corner-all; } It would further decouple Js and styling. -- Matthias > > Thanks again for your time Brian. > > Cheers > > Carl > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From carl.input at gmail.com Thu Nov 15 14:58:52 2012 From: carl.input at gmail.com (Carl Smith) Date: Thu, 15 Nov 2012 19:58:52 +0000 Subject: [IPython-dev] Just looking for feedback before PR In-Reply-To: <317EAFE2-9755-4839-AA5E-8BEA916CC14E@gmail.com> References: <317EAFE2-9755-4839-AA5E-8BEA916CC14E@gmail.com> Message-ID: > let's call it is .profile_xxx/static/css/custom.css > let's do the same with js. > let's all go to scipy2012 and ask min to do it in 10min... > Tada ! (the template being the default css files) > > BTW you can over rite any ipyton css/js files by creating a file with the same name in > .profile_xxx/static/ Looks like you're one step ahead, or you've got Min one step ahead at least :) >> >> This sounds like a good idea, but I've not actually used less to know >> how well it works. I'll look it up tonight. > > less is basically css with variable and nested rules. > speaking of nested rules. > > in cell.js and similar when selecting js does : > this.element.addClass('ui-widget-content ui-corner-all'); > (and unselecting removes it of course) > > With less you can change that to : > -> this.element.addClass('cell-selected'); > > and create a less rule : > > import jquerytheme.css > > .codecell-selected { > .ui-widget-content; > .ui-corner-all; > } > > It would further decouple Js and styling. > -- > Matthias Cheers for the pointers Matthias. So, what I'm taking away from all this is that I should still work on my CSS stuff, making it more consistent with the Notebook, but with a view to having it as a stylesheet for others to add to their profiles, not as a default. This way users can style their Markdown the same way they'd style anything else. Any feedback on the version of the Brief Tour would be appreciated. If people like the changes I've made, we can tidy it up and add it to the main examples directory. Thanks again Carl From bussonniermatthias at gmail.com Thu Nov 15 15:26:34 2012 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Thu, 15 Nov 2012 21:26:34 +0100 Subject: [IPython-dev] Just looking for feedback before PR In-Reply-To: References: <317EAFE2-9755-4839-AA5E-8BEA916CC14E@gmail.com> Message-ID: I globally like it. Maybe a little better than original css, but it might be the effect of smth new. I haven't compared the difference in vertical spacing. markdown is 15px,

is 16px, looks weird. other non uniformity in the MD cell with * *italics* * **boldfaced** * `monospaced` * [anchors](http://ipython.org) * lists like this one * which can be nested * arbitrarily * a range of headers * horizontal rules some text are 14px; other 15px I would add a .text_cell p { ? text-align: justify; } header go less far than cell on the right (cf headerAndCell screenshot attached) The 90? corner do not hurt my feelings. I once created a notebook with almost everything you can style. for example, you can add

Something inside
To a md cell and you have a false tooltip. I'll try to find it again or re-do it. It might be of help when testing css. Good job. -- Matthias Le 15 nov. 2012 ? 20:58, Carl Smith a ?crit : >> let's call it is .profile_xxx/static/css/custom.css >> let's do the same with js. >> let's all go to scipy2012 and ask min to do it in 10min... >> Tada ! (the template being the default css files) >> >> BTW you can over rite any ipyton css/js files by creating a file with the same name in >> .profile_xxx/static/ > > Looks like you're one step ahead, or you've got Min one step ahead at least :) > >>> >>> This sounds like a good idea, but I've not actually used less to know >>> how well it works. I'll look it up tonight. >> >> less is basically css with variable and nested rules. >> speaking of nested rules. >> >> in cell.js and similar when selecting js does : >> this.element.addClass('ui-widget-content ui-corner-all'); >> (and unselecting removes it of course) >> >> With less you can change that to : >> -> this.element.addClass('cell-selected'); >> >> and create a less rule : >> >> import jquerytheme.css >> >> .codecell-selected { >> .ui-widget-content; >> .ui-corner-all; >> } >> >> It would further decouple Js and styling. >> -- >> Matthias > > Cheers for the pointers Matthias. > > So, what I'm taking away from all this is that I should still work on > my CSS stuff, making it more consistent with the Notebook, but with a > view to having it as a stylesheet for others to add to their profiles, > not as a default. This way users can style their Markdown the same way > they'd style anything else. > > Any feedback on the version of the Brief Tour would be appreciated. If > people like the changes I've made, we can tidy it up and add it to the > main examples directory. > > Thanks again > > Carl > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: headerAndCell.png Type: image/png Size: 6608 bytes Desc: not available URL: From ellisonbg at gmail.com Thu Nov 15 17:15:42 2012 From: ellisonbg at gmail.com (Brian Granger) Date: Thu, 15 Nov 2012 14:15:42 -0800 Subject: [IPython-dev] Just looking for feedback before PR In-Reply-To: References: <317EAFE2-9755-4839-AA5E-8BEA916CC14E@gmail.com> Message-ID: I like the custom.css idea. But also keep in mind the following. Anything added to to the jsplugins directory is automatically added to index.html. That allows users to just throw files there and have them loaded into the notebook without worrying about how they are named. On Thu, Nov 15, 2012 at 12:26 PM, Matthias BUSSONNIER < bussonniermatthias at gmail.com> wrote: > I globally like it. Maybe a little better than original css, but it might > be the effect of smth new. > > I haven't compared the difference in vertical spacing. > > > markdown is 15px,

is 16px, looks weird. > > other non uniformity in the MD cell with > > * *italics* > * **boldfaced** > * `monospaced` > * [anchors](http://ipython.org) > * lists like this one > * which can be nested > * arbitrarily > * a range of headers > * horizontal rules > > some text are 14px; other 15px > > I would add a > > .text_cell p { > ? text-align: justify; > } > > header go less far than cell on the right (cf headerAndCell screenshot > attached) > > The 90? corner do not hurt my feelings. > > I once created a notebook with almost everything you can style. for > example, you can add >

>
Something > inside
>
>
> To a md cell and you have a false tooltip. > > I'll try to find it again or re-do it. It might be of help when testing > css. > > Good job. > -- > Matthias > > > > > Le 15 nov. 2012 ? 20:58, Carl Smith a ?crit : > > let's call it is .profile_xxx/static/css/custom.css > > let's do the same with js. > > let's all go to scipy2012 and ask min to do it in 10min... > > Tada ! (the template being the default css files) > > > BTW you can over rite any ipyton css/js files by creating a file with the > same name in > > .profile_xxx/static/ > > > Looks like you're one step ahead, or you've got Min one step ahead at > least :) > > > This sounds like a good idea, but I've not actually used less to know > > how well it works. I'll look it up tonight. > > > less is basically css with variable and nested rules. > > speaking of nested rules. > > > in cell.js and similar when selecting js does : > > this.element.addClass('ui-widget-content ui-corner-all'); > > (and unselecting removes it of course) > > > With less you can change that to : > > -> this.element.addClass('cell-selected'); > > > and create a less rule : > > > import jquerytheme.css > > > .codecell-selected { > > .ui-widget-content; > > .ui-corner-all; > > } > > > It would further decouple Js and styling. > > -- > > Matthias > > > Cheers for the pointers Matthias. > > So, what I'm taking away from all this is that I should still work on > my CSS stuff, making it more consistent with the Notebook, but with a > view to having it as a stylesheet for others to add to their profiles, > not as a default. This way users can style their Markdown the same way > they'd style anything else. > > Any feedback on the version of the Brief Tour would be appreciated. If > people like the changes I've made, we can tidy it up and add it to the > main examples directory. > > Thanks again > > 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 > > -- 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: headerAndCell.png Type: image/png Size: 6608 bytes Desc: not available URL: From d.warde.farley at gmail.com Thu Nov 15 17:44:30 2012 From: d.warde.farley at gmail.com (David Warde-Farley) Date: Thu, 15 Nov 2012 17:44:30 -0500 Subject: [IPython-dev] A thought about nbconvert Message-ID: I just had an idea for a feature and wanted some feedback before I implement it. There's a pull request in the nbconvert queue to suppress certain content types at export time. I was wondering if it would make sense to use the new cell metadata mechanism to allow selective suppression of individual cells at export time: either the input, the output, or both. I guess my thought is that sometimes, you don't want to know how the sausage is made; sometimes you just want the image and not the code to generate it to be displayed in the tutorial/book/etc. Things like %pylab inline don't necessarily add much to a printed document either. Of course, if they grab the ipython notebook format, that code will all be there. Thoughts? Any preferences on key names, values, etc.? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pivanov314 at gmail.com Thu Nov 15 18:01:51 2012 From: pivanov314 at gmail.com (Paul Ivanov) Date: Thu, 15 Nov 2012 15:01:51 -0800 Subject: [IPython-dev] A thought about nbconvert In-Reply-To: References: Message-ID: On Thu, Nov 15, 2012 at 2:44 PM, David Warde-Farley < d.warde.farley at gmail.com> wrote: > I just had an idea for a feature and wanted some feedback before I > implement it. > > There's a pull request in the nbconvert queue to suppress certain content > types at export time. I was wondering if it would make sense to use the new > cell metadata mechanism to allow selective suppression of individual cells > at export time: either the input, the output, or both. > > I guess my thought is that sometimes, you don't want to know how the > sausage is made; sometimes you just want the image and not the code to > generate it to be displayed in the tutorial/book/etc. Things like %pylab > inline don't necessarily add much to a printed document either. Of course, > if they grab the ipython notebook format, that code will all be there. > > Thoughts? Any preferences on key names, values, etc.? > Hi David! this sounds great. My understanding is that there should be no strict/formal structure to metadata, so in light of the perfectly legitimate scenario you describe, it would be best that provide generic converters, which subclass the ones we have available, and then decide to only include, or selective exclude content based on the cell metadata. This might even be a mixin for the converter classes we have now, so at the command line you could do something like --ignore-metadata='solution', or --only-metadata='awesomeness' -- Paul Ivanov 314 address only used for lists, off-list direct email at: http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 -------------- next part -------------- An HTML attachment was scrubbed... URL: From carl.input at gmail.com Thu Nov 15 18:16:45 2012 From: carl.input at gmail.com (Carl Smith) Date: Thu, 15 Nov 2012 23:16:45 +0000 Subject: [IPython-dev] Just looking for feedback before PR In-Reply-To: References: <317EAFE2-9755-4839-AA5E-8BEA916CC14E@gmail.com> Message-ID: Brian, I really need to book up on all these features. Since the Notebook came out, I've been doing a poor job of playing catchup. The docs are a bit lacking though. Unless I'm missing a load of paperwork, the documentation has fallen way behind. I'm just discussing some day job stuff at the moment, but if it'll leave me enough free time, I think I'll start trying to bring the users' docs forward a bit. Though that'll probably require some more bandwidth from you guys. >> markdown is 15px,

is 16px, looks weird. Matthias, I preferred this to having them the same size. The monospaced fonts look huge inline. I thought the slightly lower tops helped. I can change it back though. The main thing is to just distinguish the inline code from the regular text more, as the font change alone isn't visually striking enough. >> other non uniformity in the MD cell with >> >> * *italics* >> * **boldfaced** >> * `monospaced` >> * [anchors](http://ipython.org) >> * lists like this one >> * which can be nested >> * arbitrarily >> * a range of headers >> * horizontal rules >> >> some text are 14px; other 15px Yeah, that's no good. I need to rethink changing font sizes altogether. Brian's not sure it makes sense to change them. See above. >> I would add a >> >> .text_cell p { >> ? text-align: justify; >> } >> >> header go less far than cell on the right (cf headerAndCell screenshot attached) I hadn't seen that as an issue, but now you mention it, it'd make sense if they lined up properly. The screenshot really highlights how crap it looks at the moment. >> The 90? corner do not hurt my feelings. I liked the sharper edges too, at least on the h2 tags, but I'd really like to conform to Brian's plans for the overall look, so that'll have to be reconsidered. The h1 tags do look inconsistently sharp. Maybe, we can find some happy compromise. >> I once created a notebook with almost everything you can style. for example, you can add >>

>>
Something inside
>>
>>
>> To a md cell and you have a false tooltip. >> >> I'll try to find it again or re-do it. It might be of help when testing css. It be good to see that if you can find it. I think we're all agreed that being able to use plain Markdown to create styled content is a winner, but all disagree on exactly how to implement it. I'll take on board everything that's been said and see if I can come up with something closer to what everyone wants. We can work from there tomorrow or something. Thanks all Carl From d.warde.farley at gmail.com Thu Nov 15 18:46:54 2012 From: d.warde.farley at gmail.com (David Warde-Farley) Date: Thu, 15 Nov 2012 18:46:54 -0500 Subject: [IPython-dev] A thought about nbconvert In-Reply-To: References: Message-ID: Hey Paul, Hmm. So, two things: - If I were to add it to the "simple" metadata editor (as is currently the case with slideshow stuff, I think?) wouldn't that force a key name? - similarly, fine-grained behaviour (code but not output, output but not code) seems hard to accomplish in a generic way. Thoughts? David On Thu, Nov 15, 2012 at 6:01 PM, Paul Ivanov wrote: > On Thu, Nov 15, 2012 at 2:44 PM, David Warde-Farley < > d.warde.farley at gmail.com> wrote: > >> I just had an idea for a feature and wanted some feedback before I >> implement it. >> >> There's a pull request in the nbconvert queue to suppress certain content >> types at export time. I was wondering if it would make sense to use the new >> cell metadata mechanism to allow selective suppression of individual cells >> at export time: either the input, the output, or both. >> >> I guess my thought is that sometimes, you don't want to know how the >> sausage is made; sometimes you just want the image and not the code to >> generate it to be displayed in the tutorial/book/etc. Things like %pylab >> inline don't necessarily add much to a printed document either. Of course, >> if they grab the ipython notebook format, that code will all be there. >> >> Thoughts? Any preferences on key names, values, etc.? >> > > Hi David! > > this sounds great. My understanding is that there should be no > strict/formal structure to metadata, so in light of the perfectly > legitimate scenario you describe, it would be best that provide generic > converters, which subclass the ones we have available, and then decide to > only include, or selective exclude content based on the cell metadata. This > might even be a mixin for the converter classes we have now, so at the > command line you could do something like --ignore-metadata='solution', or > --only-metadata='awesomeness' > > > -- > Paul Ivanov > 314 address only used for lists, off-list direct email at: > http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 > > _______________________________________________ > 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 Fri Nov 16 02:48:12 2012 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Fri, 16 Nov 2012 08:48:12 +0100 Subject: [IPython-dev] A thought about nbconvert In-Reply-To: References: Message-ID: <85D48EE1-A3D4-4F82-A832-9FAF324DCB8E@gmail.com> Le 16 nov. 2012 ? 00:46, David Warde-Farley a ?crit : Hi David, > Hey Paul, > > Hmm. So, two things: > > - If I were to add it to the "simple" metadata editor (as is currently the case with slideshow stuff, I think?) wouldn't that force a key name? This is one of the reason the Metadata UI is not moving forward right now. it is not made only for slideshow. I would like to make it easily extendable. My first thought was that you could register a callback that get the current cell as first argument, and the div of the clicked button as second. So that you can do whatever you want (just toggle a value) or completely open a jQuery dialog. The problem is when does the metadata extension append ? is it through a Js plugin, or anytime a notebook is launched. The main problem with the second one is that it is hard to extend both already instantiated metadata UI toolbar and class prototype. Also if the metadata is modified by something else than the button, how is the button state updated ? Eventually this UI might be used for touch device (cut, copy, past, run)... so we surely want to be able to at least partially load it. (hence jsplugin is hard) unless you only hide part with css. (this is also something I want to talk to brian, because right now js plugin are always loaded and you might want to load them only at some point) As for the key name, you could use your own prefix. like stuff things in `nbconvert.conversionOption.whatever`, `nbconvert.conversionOption.anotherStuff` > - similarly, fine-grained behaviour (code but not output, output but not code) seems hard to accomplish in a generic way. You can also use 'notebook' and 'worksheet' level metadata. this can be a global flag, which is 'merged' into each cell metadata at convert time to avoid all the `if metadata.nooutput or worksheet.metadata.nooutput :` But if there is no global flag from command line, I'm fine with it, it could be a done programatically. As I wrote on the other PR let's build a good module, and having command line tool will be convenience. -- Matthias > > Thoughts? > > David > From bussonniermatthias at gmail.com Fri Nov 16 02:59:37 2012 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Fri, 16 Nov 2012 08:59:37 +0100 Subject: [IPython-dev] Just looking for feedback before PR In-Reply-To: References: <317EAFE2-9755-4839-AA5E-8BEA916CC14E@gmail.com> Message-ID: Le 16 nov. 2012 ? 00:16, Carl Smith a ?crit : > Brian, I really need to book up on all these features. Since the > Notebook came out, I've been doing a poor job of playing catchup. The > docs are a bit lacking though. Unless I'm missing a load of paperwork, > the documentation has fallen way behind. I'm working on js doc now. > > I'm just discussing some day job stuff at the moment, but if it'll > leave me enough free time, I think I'll start trying to bring the > users' docs forward a bit. Though that'll probably require some more > bandwidth from you guys. > >>> markdown is 15px,

is 16px, looks weird. > > Matthias, I preferred this to having them the same size. The > monospaced fonts look huge inline. I thought the slightly lower tops > helped. I can change it back though. The main thing is to just > distinguish the inline code from the regular text more, as the font > change alone isn't visually striking enough. That the opposite for me :-) inline code is smaller ! (cf screenshot) >>> other non uniformity in the MD cell with >>> >>> * *italics* >>> * **boldfaced** >>> * `monospaced` >>> * [anchors](http://ipython.org) >>> * lists like this one >>> * which can be nested >>> * arbitrarily >>> * a range of headers >>> * horizontal rules >>> >>> some text are 14px; other 15px > > Yeah, that's no good. I need to rethink changing font sizes > altogether. Brian's not sure it makes sense to change them. See above. > >>> I would add a >>> >>> .text_cell p { >>> ? text-align: justify; >>> } >>> >>> header go less far than cell on the right (cf headerAndCell screenshot attached) > > I hadn't seen that as an issue, but now you mention it, it'd make > sense if they lined up properly. The screenshot really highlights how > crap it looks at the moment. > >>> The 90? corner do not hurt my feelings. > > I liked the sharper edges too, at least on the h2 tags, but I'd really > like to conform to Brian's plans for the overall look, so that'll have > to be reconsidered. The h1 tags do look inconsistently sharp. Maybe, > we can find some happy compromise. > >>> I once created a notebook with almost everything you can style. for example, you can add >>>

>>>
Something inside
>>>
>>>
>>> To a md cell and you have a false tooltip. >>> >>> I'll try to find it again or re-do it. It might be of help when testing css. > > It be good to see that if you can find it. > > I think we're all agreed that being able to use plain Markdown to > create styled content is a winner, but all disagree on exactly how to > implement it. I'll take on board everything that's been said and see > if I can come up with something closer to what everyone wants. We can > work from there tomorrow or something. Thanks to you. -- Matthias > > Thanks all > > Carl > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: inlinecode.png Type: image/png Size: 9481 bytes Desc: not available URL: From ellisonbg at gmail.com Fri Nov 16 12:24:55 2012 From: ellisonbg at gmail.com (Brian Granger) Date: Fri, 16 Nov 2012 09:24:55 -0800 Subject: [IPython-dev] A thought about nbconvert In-Reply-To: <85D48EE1-A3D4-4F82-A832-9FAF324DCB8E@gmail.com> References: <85D48EE1-A3D4-4F82-A832-9FAF324DCB8E@gmail.com> Message-ID: I like the idea of using cell metadata to filter the things that appear in the converted notebook. What about creating a metadata field called tags that is a list of tags that cell has. That would allow to to include and exclude different tags upon conversion. We could do: export and exclude tag=['solutions'] to create a notebook without the solution to problems for example. On Thu, Nov 15, 2012 at 11:48 PM, Matthias BUSSONNIER < bussonniermatthias at gmail.com> wrote: > > Le 16 nov. 2012 ? 00:46, David Warde-Farley a ?crit : > > Hi David, > > > Hey Paul, > > > > Hmm. So, two things: > > > > - If I were to add it to the "simple" metadata editor (as is currently > the case with slideshow stuff, I think?) wouldn't that force a key name? > > This is one of the reason the Metadata UI is not moving forward right now. > it is not made only for slideshow. > I would like to make it easily extendable. > My first thought was that you could register a callback that get the > current cell as first argument, and the div of the clicked button as second. > So that you can do whatever you want (just toggle a value) or completely > open a jQuery dialog. > > The problem is when does the metadata extension append ? is it through a > Js plugin, or anytime a notebook is launched. > The main problem with the second one is that it is hard to extend both > already instantiated metadata UI toolbar and class prototype. > > Also if the metadata is modified by something else than the button, how is > the button state updated ? > > Eventually this UI might be used for touch device (cut, copy, past, > run)... so we surely want to be able to at least partially load it. (hence > jsplugin is hard) > unless you only hide part with css. > (this is also something I want to talk to brian, because right now js > plugin are always loaded and you might want to load them only at some point) > > > As for the key name, you could use your own prefix. > like stuff things in `nbconvert.conversionOption.whatever`, > `nbconvert.conversionOption.anotherStuff` > > > > - similarly, fine-grained behaviour (code but not output, output but not > code) seems hard to accomplish in a generic way. > You can also use 'notebook' and 'worksheet' level metadata. > this can be a global flag, which is 'merged' into each cell metadata at > convert time to avoid all the > `if metadata.nooutput or worksheet.metadata.nooutput :` > > But if there is no global flag from command line, I'm fine with it, it > could be a done programatically. As I wrote on the other PR let's build a > good module, and having command line tool will be convenience. > -- > Matthias > > > > > > Thoughts? > > > > David > > > > _______________________________________________ > 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 ellisonbg at gmail.com Fri Nov 16 12:25:31 2012 From: ellisonbg at gmail.com (Brian Granger) Date: Fri, 16 Nov 2012 09:25:31 -0800 Subject: [IPython-dev] A thought about nbconvert In-Reply-To: References: <85D48EE1-A3D4-4F82-A832-9FAF324DCB8E@gmail.com> Message-ID: We could also use these tags to filter cells in the actual notebook UI. So a presentation mode could filter out certain tags. On Fri, Nov 16, 2012 at 9:24 AM, Brian Granger wrote: > I like the idea of using cell metadata to filter the things that appear in > the converted notebook. What about creating a metadata field called tags > that is a list of tags that cell has. That would allow to to include and > exclude different tags upon conversion. We could do: > > export and exclude tag=['solutions'] to create a notebook without the > solution to problems for example. > > > On Thu, Nov 15, 2012 at 11:48 PM, Matthias BUSSONNIER < > bussonniermatthias at gmail.com> wrote: > >> >> Le 16 nov. 2012 ? 00:46, David Warde-Farley a ?crit : >> >> Hi David, >> >> > Hey Paul, >> > >> > Hmm. So, two things: >> > >> > - If I were to add it to the "simple" metadata editor (as is currently >> the case with slideshow stuff, I think?) wouldn't that force a key name? >> >> This is one of the reason the Metadata UI is not moving forward right >> now. it is not made only for slideshow. >> I would like to make it easily extendable. >> My first thought was that you could register a callback that get the >> current cell as first argument, and the div of the clicked button as second. >> So that you can do whatever you want (just toggle a value) or completely >> open a jQuery dialog. >> >> The problem is when does the metadata extension append ? is it through a >> Js plugin, or anytime a notebook is launched. >> The main problem with the second one is that it is hard to extend both >> already instantiated metadata UI toolbar and class prototype. >> >> Also if the metadata is modified by something else than the button, how >> is the button state updated ? >> >> Eventually this UI might be used for touch device (cut, copy, past, >> run)... so we surely want to be able to at least partially load it. (hence >> jsplugin is hard) >> unless you only hide part with css. >> (this is also something I want to talk to brian, because right now js >> plugin are always loaded and you might want to load them only at some point) >> >> >> As for the key name, you could use your own prefix. >> like stuff things in `nbconvert.conversionOption.whatever`, >> `nbconvert.conversionOption.anotherStuff` >> >> >> > - similarly, fine-grained behaviour (code but not output, output but >> not code) seems hard to accomplish in a generic way. >> You can also use 'notebook' and 'worksheet' level metadata. >> this can be a global flag, which is 'merged' into each cell metadata at >> convert time to avoid all the >> `if metadata.nooutput or worksheet.metadata.nooutput :` >> >> But if there is no global flag from command line, I'm fine with it, it >> could be a done programatically. As I wrote on the other PR let's build a >> good module, and having command line tool will be convenience. >> -- >> Matthias >> >> >> > >> > Thoughts? >> > >> > David >> > >> >> _______________________________________________ >> 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 > > -- 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 bussonniermatthias at gmail.com Sat Nov 17 07:23:01 2012 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Sat, 17 Nov 2012 13:23:01 +0100 Subject: [IPython-dev] Rich user_variable and user_expression. Message-ID: Hi dev list, As you might be aware, IPython have a rich display and messaging protocol. The messaging one has been design before the display protocol. Especially, user_variable and user_expression only allow to get string repr of object. This is one of the reason we might be considering extending the messaging protocol, And especially user_variable and user_expression to transmit not only the repr of result/variable but also the _repr_latex_ _repr_html_ ... etc. One argument against this is that rich display is pretty expensive, so that we discourage moving huge amount of data through this channel especially if fronted do not use it. IMHO, when a piece of code use user_expression or user_variable, you could explicitly ask for a preferred representation. So most representation should be opt-in. We'll be happy to have your thought about that if you use the messaging protocol in your applications. Also this mail should be used as a starting point for us if we decide to draft a next version of the messaging protocol. Thanks, -- Matthias http://ipython.org/ipython-doc/stable/development/messaging.html From carl.input at gmail.com Sat Nov 17 13:35:00 2012 From: carl.input at gmail.com (Carl Smith) Date: Sat, 17 Nov 2012 18:35:00 +0000 Subject: [IPython-dev] Just looking for feedback before PR In-Reply-To: References: <317EAFE2-9755-4839-AA5E-8BEA916CC14E@gmail.com> Message-ID: Can I ask again; is it really not possible to get rid of the header cells? I'm not sure what information a header1 cell provides that a h1 tag wouldn't, but couldn't that information go inside html comment style markup or something? Like slideshow markup. It seems like the UX would be a lot nicer if there were only two kinds of cell, code cells and note cells. Note cells would just be Markdown cells, and headers would be done with Markdown inside them. There'd be no raw cells, you'd just use pre tags, which displays raw text without highlighting already. You could then have Ctrl-M>M be the Mode shortcut, and have it toggle a cell between code mode and note mode. Surely reducing nine cell types down to two is more important than making it easier to convert to LaTex? -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Sat Nov 17 13:43:56 2012 From: takowl at gmail.com (Thomas Kluyver) Date: Sat, 17 Nov 2012 18:43:56 +0000 Subject: [IPython-dev] Just looking for feedback before PR In-Reply-To: References: <317EAFE2-9755-4839-AA5E-8BEA916CC14E@gmail.com> Message-ID: On 17 November 2012 18:35, Carl Smith wrote: > Can I ask again; is it really not possible to get rid of the header cells? > I'm not sure what information a header1 cell provides that a h1 tag > wouldn't, but couldn't that information go inside html comment style markup > or something? Like slideshow markup. I'm not sure why header cells exist at present, but the notebook format has wide enough use that we would have to be a bit careful about removing them. E.g. we could remove the UI to create new header cells, while leaving the notebook able to load header cells from existing files. If we wanted to be a bit pushier, we could convert header cells to markdown cells when the notebook was loaded, which would pave the way for dropping them from future versions of the format. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Sat Nov 17 23:10:21 2012 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 17 Nov 2012 20:10:21 -0800 Subject: [IPython-dev] Fwd: [matplotlib-devel] OpenGL backend with Galry In-Reply-To: References: Message-ID: Hey folks, impressive job by Cyrille Rossant after I gave him just a few quick pointers on how the JSON handling and WebGL integration had to be set up; this provides fast 2-d visualization in the notebook with a matplotlib-like API but using WebGL for the rendering. Cheers, f ---------- Forwarded message ---------- From: Cyrille Rossant Date: Sat, Nov 17, 2012 at 4:07 PM Subject: Re: [matplotlib-devel] OpenGL backend with Galry To: Fernando Perez Cc: matplotlib-devel at lists.sourceforge.net >> Yup, it's a bit of a hack right now b/c you need to merge several >> branches and tools that are still in review, but it's not too bad. >> >> You need to start from this branch: >> >> https://github.com/ellisonbg/ipython/tree/jsonhandlers >> >> and then grab this repo: >> >> https://github.com/ipython/jsplugins >> >> I would start by testing the d3graph plugin and verify that you can do >> what I show here (watch ~ 40 seconds): >> >> http://www.youtube.com/watch?v=F4rFuIb1Ie4&t=40m0s >> >> That should give you the basics. Then the webgl visualizer example is here: >> >> https://github.com/RishiRamraj/seepymol OK so I now have a very experimental proof of concept of how integrating Galry in the IPython notebook. There's a short demo here: http://www.youtube.com/watch?v=taN4TobRS-E I'll put the code on github but there's of course much more to do. I'll also work on a basic matplotlib-like high-level interface that will work in both standard python/ipython consoles, and in the IPython notebook. Cheers, Cyrille From Nicolas.Rougier at inria.fr Sun Nov 18 04:01:25 2012 From: Nicolas.Rougier at inria.fr (Nicolas Rougier) Date: Sun, 18 Nov 2012 10:01:25 +0100 Subject: [IPython-dev] [matplotlib-devel] OpenGL backend with Galry In-Reply-To: References: Message-ID: <53FF2D9B-CA3F-4863-B64A-485C617930BE@inria.fr> I've been trying your explanation regarding d3graph but I ended with: [4]: display(G) with no actual display of the graph. I guess I did something wrong but I'm stuck, any idea ? I'm using python 2.7.2/osx/safari and I started ipython with "notebook" option only. Nicolas On Nov 18, 2012, at 5:10 , Fernando Perez wrote: > Hey folks, > > impressive job by Cyrille Rossant after I gave him just a few quick > pointers on how the JSON handling and WebGL integration had to be set > up; this provides fast 2-d visualization in the notebook with a > matplotlib-like API but using WebGL for the rendering. > > Cheers, > > f > > > ---------- Forwarded message ---------- > From: Cyrille Rossant > Date: Sat, Nov 17, 2012 at 4:07 PM > Subject: Re: [matplotlib-devel] OpenGL backend with Galry > To: Fernando Perez > Cc: matplotlib-devel at lists.sourceforge.net > > >>> Yup, it's a bit of a hack right now b/c you need to merge several >>> branches and tools that are still in review, but it's not too bad. >>> >>> You need to start from this branch: >>> >>> https://github.com/ellisonbg/ipython/tree/jsonhandlers >>> >>> and then grab this repo: >>> >>> https://github.com/ipython/jsplugins >>> >>> I would start by testing the d3graph plugin and verify that you can do >>> what I show here (watch ~ 40 seconds): >>> >>> http://www.youtube.com/watch?v=F4rFuIb1Ie4&t=40m0s >>> >>> That should give you the basics. Then the webgl visualizer example is here: >>> >>> https://github.com/RishiRamraj/seepymol > > > OK so I now have a very experimental proof of concept of how > integrating Galry in the IPython notebook. There's a short demo here: > http://www.youtube.com/watch?v=taN4TobRS-E > > I'll put the code on github but there's of course much more to do. > > I'll also work on a basic matplotlib-like high-level interface that > will work in both standard python/ipython consoles, and in the IPython > notebook. > > Cheers, > Cyrille > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From cyrille.rossant at gmail.com Sun Nov 18 05:46:31 2012 From: cyrille.rossant at gmail.com (Cyrille Rossant) Date: Sun, 18 Nov 2012 10:46:31 +0000 Subject: [IPython-dev] [matplotlib-devel] OpenGL backend with Galry In-Reply-To: <53FF2D9B-CA3F-4863-B64A-485C617930BE@inria.fr> References: <53FF2D9B-CA3F-4863-B64A-485C617930BE@inria.fr> Message-ID: > > I've been trying your explanation regarding d3graph but I ended with: > > [4]: display(G) > > > > with no actual display of the graph. I guess I did something wrong but I'm > stuck, any idea ? > > I'm using python 2.7.2/osx/safari and I started ipython with "notebook" > option only. > > I had the same problem at first, in fact I was not using the "jsonhandlers" branch of the ellisonbg fork of IPython. You should download it and make sure this is the IPython you're using by installing it over your existing IPython setup. Apart from that, you should also make sure that all the .js files and .py files are where they should be (according to the README files). Cyrille -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Sun Nov 18 06:14:24 2012 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 18 Nov 2012 03:14:24 -0800 Subject: [IPython-dev] [matplotlib-devel] OpenGL backend with Galry In-Reply-To: References: <53FF2D9B-CA3F-4863-B64A-485C617930BE@inria.fr> Message-ID: On Sun, Nov 18, 2012 at 2:46 AM, Cyrille Rossant wrote: > I had the same problem at first, in fact I was not using the "jsonhandlers" > branch of the ellisonbg fork of IPython. You should download it and make > sure this is the IPython you're using by installing it over your existing > IPython setup. Apart from that, you should also make sure that all the .js > files and .py files are where they should be (according to the README > files). Yup, that's pretty much it. Obviously we want all of this to work out of the box, and it will once we can land all these various branches with proper review. Cheers, f From fperez.net at gmail.com Sun Nov 18 06:15:34 2012 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 18 Nov 2012 03:15:34 -0800 Subject: [IPython-dev] Notebook diffing tool by Matthew Message-ID: Hi folks, Matthew just wrote up a notebook-diff tool. Eventually we'll want this kind of capability nicely integrated into nbconvert, but in the meantime here it is: https://github.com/fperez/nipy-notebooks/blob/master/notebook_diff.py Does crude unified diff on notebooks after stripping output and input line numbers. You've got to search through the text to see the bit to which the diff refers, but at least it gives an idea... Actually piping this through wdiff is particularly nice: ./notebook_diff.py exploring_r_formula.ipynb jbs_r_formula.ipynb | wdiff -d -a Cheers, f From bussonniermatthias at gmail.com Sun Nov 18 06:45:47 2012 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Sun, 18 Nov 2012 12:45:47 +0100 Subject: [IPython-dev] Notebook diffing tool by Matthew In-Reply-To: References: Message-ID: Le 18 nov. 2012 ? 12:15, Fernando Perez a ?crit : > Hi folks, > > Matthew just wrote up a notebook-diff tool. Eventually we'll want > this kind of capability nicely integrated into nbconvert, but in the > meantime here it is: > > https://github.com/fperez/nipy-notebooks/blob/master/notebook_diff.py > > Does crude unified diff on notebooks after stripping output and input > line numbers. You've got to search through the text to see the bit to > which the diff refers, but at least it gives an idea... One thing that can be done is adding cell ID. This help to do a per-cell diff (or find splitted/merged cells) The advantage is that diff notebook is still a real ipynb file. http://nbviewer.ipython.org/urls/raw.github.com/Carreau/ipython/58d78fce482cfc907e85de3e86850e8e448d94dd/docs/examples/notebooks/octave_diff.ipynb (nbviewer does not render the cell correctly with the right color, added text should be green and removed red, without input prompt.) > Actually piping this through wdiff is particularly nice: > > ./notebook_diff.py exploring_r_formula.ipynb jbs_r_formula.ipynb | wdiff -d -a > > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From Nicolas.Rougier at inria.fr Sun Nov 18 06:46:48 2012 From: Nicolas.Rougier at inria.fr (Nicolas Rougier) Date: Sun, 18 Nov 2012 12:46:48 +0100 Subject: [IPython-dev] [matplotlib-devel] OpenGL backend with Galry In-Reply-To: References: <53FF2D9B-CA3F-4863-B64A-485C617930BE@inria.fr> Message-ID: <614C0DE5-5150-43A5-93BD-60888A91F8A7@inria.fr> That was the problem, I cloned the repository main branch... Thanks. Nicolas On Nov 18, 2012, at 12:14 , Fernando Perez wrote: > On Sun, Nov 18, 2012 at 2:46 AM, Cyrille Rossant > wrote: >> I had the same problem at first, in fact I was not using the "jsonhandlers" >> branch of the ellisonbg fork of IPython. You should download it and make >> sure this is the IPython you're using by installing it over your existing >> IPython setup. Apart from that, you should also make sure that all the .js >> files and .py files are where they should be (according to the README >> files). > > Yup, that's pretty much it. > > Obviously we want all of this to work out of the box, and it will once > we can land all these various branches with proper review. > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From ellisonbg at gmail.com Sun Nov 18 13:13:06 2012 From: ellisonbg at gmail.com (Brian Granger) Date: Sun, 18 Nov 2012 10:13:06 -0800 Subject: [IPython-dev] Notebook diffing tool by Matthew In-Reply-To: References: Message-ID: Let's create an issue to track these efforts.... On Sun, Nov 18, 2012 at 3:15 AM, Fernando Perez wrote: > Hi folks, > > Matthew just wrote up a notebook-diff tool. Eventually we'll want > this kind of capability nicely integrated into nbconvert, but in the > meantime here it is: > > https://github.com/fperez/nipy-notebooks/blob/master/notebook_diff.py > > Does crude unified diff on notebooks after stripping output and input > line numbers. You've got to search through the text to see the bit to > which the diff refers, but at least it gives an idea... > > Actually piping this through wdiff is particularly nice: > > ./notebook_diff.py exploring_r_formula.ipynb jbs_r_formula.ipynb | wdiff > -d -a > > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Sun Nov 18 17:06:50 2012 From: ellisonbg at gmail.com (Brian Granger) Date: Sun, 18 Nov 2012 14:06:50 -0800 Subject: [IPython-dev] Just looking for feedback before PR In-Reply-To: References: <317EAFE2-9755-4839-AA5E-8BEA916CC14E@gmail.com> Message-ID: Carl, Here is a bit of background on the heading cells. We initially tried to do everything with restructured text. That didn't work because of how rst headings are always relative. This means we couldn't render cells one by one. There was also the problem that the rst rendering involved a call to the server. Thus we went with markdown for cells, mainly because of how headings were handled. But as we began to use markdown, we realized that its approach to headings was a bit too flexible. We really wanted the ability for notebooks to have formal structure (nested heading levels). There are a number of usage cases for this: * Exporting to formats that also have nested heading levels (latex, html, etc.) * Enabling entire sections/subsections in a notebook to be moved, copied, collapsed, etc. That would be impossible to do with headings embedded inside markdown cells that have other content. * Heading cells are common enough that it is nice to be able to do them without the markdown syntax. Hope this explains our choices a bit more. Cheers, Brian On Sat, Nov 17, 2012 at 10:35 AM, Carl Smith wrote: > Can I ask again; is it really not possible to get rid of the header cells? > I'm not sure what information a header1 cell provides that a h1 tag > wouldn't, but couldn't that information go inside html comment style markup > or something? Like slideshow markup. > > It seems like the UX would be a lot nicer if there were only two kinds of > cell, code cells and note cells. Note cells would just be Markdown cells, > and headers would be done with Markdown inside them. There'd be no raw > cells, you'd just use pre tags, which displays raw text without > highlighting already. > > You could then have Ctrl-M>M be the Mode shortcut, and have it toggle a > cell between code mode and note mode. > > Surely reducing nine cell types down to two is more important than making > it easier to convert to LaTex? > > _______________________________________________ > 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 carl.input at gmail.com Sun Nov 18 19:21:53 2012 From: carl.input at gmail.com (Carl Smith) Date: Mon, 19 Nov 2012 00:21:53 +0000 Subject: [IPython-dev] Just looking for feedback before PR In-Reply-To: References: <317EAFE2-9755-4839-AA5E-8BEA916CC14E@gmail.com> Message-ID: > Thus we went with markdown for cells, mainly because of how headings were > handled. But as we began to use markdown, we realized that its approach to > headings was a bit too flexible. We really wanted the ability for notebooks > to have formal structure (nested heading levels). There are a number of > usage cases for this: > > * Exporting to formats that also have nested heading levels (latex, html, > etc.) > * Enabling entire sections/subsections in a notebook to be moved, copied, > collapsed, etc. That would be impossible to do with headings embedded > inside markdown cells that have other content. > * Heading cells are common enough that it is nice to be able to do them > without the markdown syntax. Hi Brian Thanks for taking the time to explain this for me. So, the choice to use header cells over hidden markup, is just considered more convenient? If that's the case, to be honest, I'd still prefer to define every element in my notebooks using plain text, even if it meant just using some kind of pig XML. We could easily define some unused, HTML element names as meaningful, then use them in Markdown cells, safe in the knowledge that the browser will just ignore them. There's no reason not to use a tag like in a Markdown cell for example. The hidden tags could provide meta for converters or extensions or whatever else. These tags could have almost anything in them; you can get away with murder if it's between angle brackets. Stuff like would work fine. The tags used by HTML or core IPython features would be reserved, but users could use the rest of the namespace arbitrarily, so a converter might define a tag named . You could also reserve all names that start with special strings like ipynb, so you could later define tags that do stuff like and and so on. Maybe I'm still missing something, but that's where my thinking has led me so far. From carl.input at gmail.com Sun Nov 18 20:28:50 2012 From: carl.input at gmail.com (Carl Smith) Date: Mon, 19 Nov 2012 01:28:50 +0000 Subject: [IPython-dev] ACE Editor Magic for IPython Notebook Message-ID: The following link is to a Google Doc. No login is required. https://docs.google.com/document/d/1fPXUz7h0swJ_Fbmvx9FSpD9JdWIQWj45A-llPPpJnww/edit From takowl at gmail.com Mon Nov 19 05:07:28 2012 From: takowl at gmail.com (Thomas Kluyver) Date: Mon, 19 Nov 2012 10:07:28 +0000 Subject: [IPython-dev] ACE Editor Magic for IPython Notebook In-Reply-To: References: Message-ID: Cool, I look forward to seeing this nicely integrated. Another thing I'd like to see is a terminal in a tab, using a tool like these: - http://code.google.com/p/shellinabox/ (what Python Anywhere uses) - http://liftoffsoftware.com/Products/GateOne (very fancy, but its AGPL/commercial licensing may be an obstacle) Thanks, Thomas On 19 November 2012 01:28, Carl Smith wrote: > The following link is to a Google Doc. No login is required. > > > https://docs.google.com/document/d/1fPXUz7h0swJ_Fbmvx9FSpD9JdWIQWj45A-llPPpJnww/edit > _______________________________________________ > 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 Mon Nov 19 06:48:28 2012 From: carl.input at gmail.com (Carl Smith) Date: Mon, 19 Nov 2012 11:48:28 +0000 Subject: [IPython-dev] ACE Editor Magic for IPython Notebook In-Reply-To: References: Message-ID: > Another thing I'd like to see is a terminal in a tab, using a tool like > these: > - http://code.google.com/p/shellinabox/ (what Python Anywhere uses) > - http://liftoffsoftware.com/Products/GateOne (very fancy, but its > AGPL/commercial licensing may be an obstacle) That'd be nice. I'm not a lawyer, but AGPL might be doable. From what I gather, if you're already publishing all of your source code, there's no problem. I'm not sure though, but that's what it seems to say. From carl.input at gmail.com Mon Nov 19 10:01:59 2012 From: carl.input at gmail.com (Carl Smith) Date: Mon, 19 Nov 2012 15:01:59 +0000 Subject: [IPython-dev] ACE Editor Magic for IPython Notebook In-Reply-To: References: Message-ID: Does anyone have any pointers on how to go about doing this, and how difficult it'd be? Min?? Ideally we'd have a generic JavaScript client that can be easily plumbed into any web app that wanted to act as some kind of front end. From ellisonbg at gmail.com Mon Nov 19 10:16:15 2012 From: ellisonbg at gmail.com (Brian Granger) Date: Mon, 19 Nov 2012 07:16:15 -0800 Subject: [IPython-dev] ACE Editor Magic for IPython Notebook In-Reply-To: References: Message-ID: We do want the ability for users to edit other file types and I think we should start there and add the %edit capability once that is done. This feature is large enough though that I think we need to do a IPEP for the design work. If you want to push this forward, can you start an IPEP: https://github.com/ipython/ipython/wiki/IPython-Enhancement-Proposals-(IPEPs) On Mon, Nov 19, 2012 at 7:01 AM, Carl Smith wrote: > Does anyone have any pointers on how to go about doing this, and how > difficult it'd be? Min?? > > Ideally we'd have a generic JavaScript client that can be easily > plumbed into any web app that wanted to act as some kind of front end. > _______________________________________________ > 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 bussonniermatthias at gmail.com Mon Nov 19 10:54:56 2012 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Mon, 19 Nov 2012 16:54:56 +0100 Subject: [IPython-dev] ACE Editor Magic for IPython Notebook In-Reply-To: References: Message-ID: <5E4163E7-85F3-4E2D-AB80-4E7D3E52152B@gmail.com> Le 19 nov. 2012 ? 16:01, Carl Smith a ?crit : > Does anyone have any pointers on how to go about doing this, and how > difficult it'd be? Min?? I think by publishing javascript/json you could open a new window that point to another URL and pass it parameter. That would be a start . I'm don't know how your app works, if it is a different server or not? Idea would be to start with a json plugin I think. ( do you have/ can you give a link to what you want to integrate ?) -- Matthias > > Ideally we'd have a generic JavaScript client that can be easily > plumbed into any web app that wanted to act as some kind of front end. > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From carl.input at gmail.com Mon Nov 19 11:33:14 2012 From: carl.input at gmail.com (Carl Smith) Date: Mon, 19 Nov 2012 16:33:14 +0000 Subject: [IPython-dev] IPEP 7: Notebook dependent frontends Message-ID: Hi all Just a heads up for everyone on the mailing lists: There's a new IPEP. https://github.com/ipython/ipython/wiki/IPEP-7:-Notebook-dependent-frontends Thanks Carl From matthewturk at gmail.com Mon Nov 19 11:35:35 2012 From: matthewturk at gmail.com (Matthew Turk) Date: Mon, 19 Nov 2012 11:35:35 -0500 Subject: [IPython-dev] IPEP 7: Notebook dependent frontends In-Reply-To: References: Message-ID: Hi Carl, On Mon, Nov 19, 2012 at 11:33 AM, Carl Smith wrote: > Hi all > > Just a heads up for everyone on the mailing lists: There's a new IPEP. > > https://github.com/ipython/ipython/wiki/IPEP-7:-Notebook-dependent-frontends > > Thanks This idea is a pretty exciting one to me, as we have a bunch of JavaScript code that we'd like to move to the IPython backend. To Carl and others, what's the best way to help with this initiative? -Matt > > Carl > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From carl.input at gmail.com Mon Nov 19 11:50:56 2012 From: carl.input at gmail.com (Carl Smith) Date: Mon, 19 Nov 2012 16:50:56 +0000 Subject: [IPython-dev] ACE Editor Magic for IPython Notebook In-Reply-To: <5E4163E7-85F3-4E2D-AB80-4E7D3E52152B@gmail.com> References: <5E4163E7-85F3-4E2D-AB80-4E7D3E52152B@gmail.com> Message-ID: > I think by publishing javascript/json you could open a new window that point to another URL and pass it parameter. > That would be a start . > I'm don't know how your app works, if it is a different server or not? It's just a JS editor, so you'd ordinarily implement your own server and communication, normally using AJAX requests. I could have IPython start up a second server on the same machine, and then open a new tab, pointing it to the second server. This would be easy to do, security aside, but misses the opportunity to work towards a more elegant, general solution for all Notebook Panel Apps, which is what I'm currently calling them. One important thing to consider early on is how to create a panel app that can share a kernel with the Notebook. Some apps, like a shell, would need that. Cheers P.S. I drafted an IPEP for this, IPEP 7, updated the wiki and sent a message on both lists. From ellisonbg at gmail.com Mon Nov 19 12:13:42 2012 From: ellisonbg at gmail.com (Brian Granger) Date: Mon, 19 Nov 2012 09:13:42 -0800 Subject: [IPython-dev] IPEP 7: Notebook dependent frontends In-Reply-To: References: Message-ID: Carl, I think there has been a bit of confusion. I think the IPEP we need to discuss at this point is for adding *native* support in the IPython Notebook server for editing other file types using ACE/CodeMirror. That is, I think we want the notebook dashboard to show all file types (not just notebooks) and when a user clicks on one of the other file types, they get an editor window with that file. This should be fully integrated with the notebook UI+Server and on by default for all users. I don't think we want to go into the direction that you propose of allowing the creation of completely custom UIs/Frontends. The reason is that such UIs will require custom server code to support, which raises a whole bunch of issues that we are simply not ready to tackle in any way. Does this make sense? On this broader issue, the new Javascript plugins under review would provide an implementation route for some of what you are talking about (the client side, not the server side). On Mon, Nov 19, 2012 at 8:33 AM, Carl Smith wrote: > Hi all > > Just a heads up for everyone on the mailing lists: There's a new IPEP. > > > https://github.com/ipython/ipython/wiki/IPEP-7:-Notebook-dependent-frontends > > Thanks > > Carl > _______________________________________________ > 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 ellisonbg at gmail.com Mon Nov 19 12:14:54 2012 From: ellisonbg at gmail.com (Brian Granger) Date: Mon, 19 Nov 2012 09:14:54 -0800 Subject: [IPython-dev] [IPython-User] IPEP 7: Notebook dependent frontends In-Reply-To: References: Message-ID: Matthew, If you just have JavaScript code that you want to plug into the notebook then that is already possible in the JavaScript plugins branch that is under review: https://github.com/ipython/ipython/pull/2518 Or do you also have custom server side code as well? Cheers, Brian On Mon, Nov 19, 2012 at 8:35 AM, Matthew Turk wrote: > Hi Carl, > > On Mon, Nov 19, 2012 at 11:33 AM, Carl Smith wrote: > > Hi all > > > > Just a heads up for everyone on the mailing lists: There's a new IPEP. > > > > > https://github.com/ipython/ipython/wiki/IPEP-7:-Notebook-dependent-frontends > > > > Thanks > > This idea is a pretty exciting one to me, as we have a bunch of > JavaScript code that we'd like to move to the IPython backend. To > Carl and others, what's the best way to help with this initiative? > > -Matt > > > > > Carl > > _______________________________________________ > > IPython-dev mailing list > > IPython-dev at scipy.org > > http://mail.scipy.org/mailman/listinfo/ipython-dev > _______________________________________________ > IPython-User mailing list > IPython-User at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-user > -- 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 matthewturk at gmail.com Mon Nov 19 12:19:54 2012 From: matthewturk at gmail.com (Matthew Turk) Date: Mon, 19 Nov 2012 12:19:54 -0500 Subject: [IPython-dev] [IPython-User] IPEP 7: Notebook dependent frontends In-Reply-To: References: Message-ID: Hi Brian, On Mon, Nov 19, 2012 at 12:14 PM, Brian Granger wrote: > Matthew, > > If you just have JavaScript code that you want to plug into the notebook > then that is already possible in the JavaScript plugins branch that is under > review: > > https://github.com/ipython/ipython/pull/2518 This looks like it could do what we've been looking at -- I must have missed this on the mailing list, and will investigate if it'll work. This looks like it works with profiles, but is distribution of profiles still a bit tricky? (i.e., issue 1227) > > Or do you also have custom server side code as well? No, we're going to scrap all the custom server side code for now; mainly it was to pass large binary data directly into typed arrays on the client. It would be nice to be able to supply our own HTML templates to have things load at startup, but I might be able to get it to work just using JS plugins. I'll have a go soon and write back with questions. -Matt > > Cheers, > > Brian > > > On Mon, Nov 19, 2012 at 8:35 AM, Matthew Turk wrote: >> >> Hi Carl, >> >> On Mon, Nov 19, 2012 at 11:33 AM, Carl Smith wrote: >> > Hi all >> > >> > Just a heads up for everyone on the mailing lists: There's a new IPEP. >> > >> > >> > https://github.com/ipython/ipython/wiki/IPEP-7:-Notebook-dependent-frontends >> > >> > Thanks >> >> This idea is a pretty exciting one to me, as we have a bunch of >> JavaScript code that we'd like to move to the IPython backend. To >> Carl and others, what's the best way to help with this initiative? >> >> -Matt >> >> > >> > Carl >> > _______________________________________________ >> > IPython-dev mailing list >> > IPython-dev at scipy.org >> > http://mail.scipy.org/mailman/listinfo/ipython-dev >> _______________________________________________ >> IPython-User mailing list >> IPython-User at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-user > > > > > -- > Brian E. Granger > Cal Poly State University, San Luis Obispo > bgranger at calpoly.edu and ellisonbg at gmail.com > > > _______________________________________________ > IPython-User mailing list > IPython-User at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-user > From dtlussier at gmail.com Mon Nov 19 12:46:01 2012 From: dtlussier at gmail.com (Dan Lussier) Date: Mon, 19 Nov 2012 11:46:01 -0600 Subject: [IPython-dev] use case - embedding IPython notebook within website (Drupal at least for now) Message-ID: Hi. I am a long time IPython user (thanks!) , but I am new to the IPython Notebook. I am interested in embedding IPython notebooks within a larger website project as a way to (1) statically demonstrate completed computations/figures, but also allow readers/users to experiment with their own computations. In reading about the Notebook - I understand I can generate a static HTML version of a notebook I develop and I could reskin ( https://gist.github.com/1497850, https://github.com/fperez/blog). This is close to what I am looking for, but a few additional points of interest for me are: * Ability to embed the dynamic or state notebook within a larger page that is not generated by the IPython (iframes ?) * Security - constrain users to only limited resources on the webserver (file system, system function calls, total compute resources). We are building a public facing website which will have numerous, but not a huge number of external users. * Flexibility - Currently we are using Drupal as the web framework for the project, but this may be subject to change in future iterations of the projects, so my main interest is in understanding a general approach which would allow IPython notebooks to be embedded within a page. If anybody has experience in doing something similar, or has developed a workflow that facilitates this type of process I would really appreciate the leg up. If we end up developing a useful workflow or tool along the way we are happy to contribute it back to the project/ecosystem. Many thanks, Dan Lussier Dan Lussier, BSc EIT Research Engineer Composites Research Network University of British Columbia www.crn.ubc.ca Notice: This communication may contain confidential, proprietary or legally privileged information. It is intended only for the person(s) to whom it is addressed. If you are not an intended recipient, please notify the sender that you have received it in error and immediately delete the entire communication, including any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carl.input at gmail.com Mon Nov 19 12:49:24 2012 From: carl.input at gmail.com (Carl Smith) Date: Mon, 19 Nov 2012 17:49:24 +0000 Subject: [IPython-dev] IPEP 7: Notebook dependent frontends In-Reply-To: References: Message-ID: On 19 November 2012 17:13, Brian Granger wrote: > Carl, > > I think there has been a bit of confusion. I think the IPEP we need to > discuss at this point is for adding *native* support in the IPython Notebook > server for editing other file types using ACE/CodeMirror. That is, I think > we want the notebook dashboard to show all file types (not just notebooks) > and when a user clicks on one of the other file types, they get an editor > window with that file. This should be fully integrated with the notebook > UI+Server and on by default for all users. I don't think we want to go into > the direction that you propose of allowing the creation of completely custom > UIs/Frontends. The reason is that such UIs will require custom server code > to support, which raises a whole bunch of issues that we are simply not > ready to tackle in any way. Does this make sense? Ah, OK. Feel free to edit or delete the IPEP if it's not especially useful as is. I was intending for these frontends to only use the existing API that the Notebook uses now, so no server side changes would need to be made beyond adding one feature. The IPython server would need to be able to serve any local file as a HTTP response. If the IPython server API could accept requests to a specified URL, where the request would contain a path to a file, and the server could just return that file, then everything should work without any other changes being made. A user could save the main HTML file for any web app on the same machine IPython is running on, then write a magic that outputs some JS. The JS would open a new tab, pointing the tab at the specified URL and passing the file's path in the request. The server would return the file, and the app would be rendered in the new tab. Once the app is running, it should use the same API as the Notebook uses for all future interactions with the server/kernel. You could almost do this now, but you'd need a separate server to simply serve the panel app's source on each instantiation. > On this broader issue, the new Javascript plugins under review would provide > an implementation route for some of what you are talking about (the client > side, not the server side). I wasn't aware of this work. Maybe this will handle the problems on the client-side, which, as I understand it, are only problems of difficulty, rather than technical limitations. Thanks Brian From aron at ahmadia.net Mon Nov 19 12:52:30 2012 From: aron at ahmadia.net (Aron Ahmadia) Date: Mon, 19 Nov 2012 10:52:30 -0700 Subject: [IPython-dev] use case - embedding IPython notebook within website (Drupal at least for now) In-Reply-To: References: Message-ID: Hi Dan As you noted, there are pretty large security concerns with regards to this sort of thing. I am the CTO of RunMyCode.org, which is looking into exploring similar solutions beyond just Python, and I'd be interested in learning more about what you discover and learn from looking into this. The guys at Continuum Analytics are doing something similar with http://wakari.io You could also look into the work that was done in NoteBook Cloud: https://notebookcloud.appspot.com/docs I believe iframes are the right approach, but I'm interested in hearing what other people have to say. Good luck, Aron On Mon, Nov 19, 2012 at 10:46 AM, Dan Lussier wrote: > Hi. > > > I am a long time IPython user (thanks!) , but I am new to the IPython > Notebook. > > > I am interested in embedding IPython notebooks within a larger website > project as a way to (1) statically demonstrate completed > computations/figures, but also allow readers/users to experiment with their > own computations. > > > In reading about the Notebook - I understand I can generate a static HTML > version of a notebook I develop and I could reskin ( > https://gist.github.com/1497850, https://github.com/fperez/blog). This > is close to what I am looking for, but a few additional points of interest > for me are: > > > * Ability to embed the dynamic or state notebook within a larger page > that is not generated by the IPython (iframes ?) > > > * Security - constrain users to only limited resources on the webserver > (file system, system function calls, total compute resources). We are > building a public facing website which will have numerous, but not a huge > number of external users. > > > * Flexibility - Currently we are using Drupal as the web framework for > the project, but this may be subject to change in future iterations of the > projects, so my main interest is in understanding a general approach which > would allow IPython notebooks to be embedded within a page. > > > If anybody has experience in doing something similar, or has developed a > workflow that facilitates this type of process I would really appreciate > the leg up. If we end up developing a useful workflow or tool along the > way we are happy to contribute it back to the project/ecosystem. > > > Many thanks, > > > Dan Lussier > > > > > > Dan Lussier, BSc EIT > > Research Engineer > > > Composites Research Network > > University of British Columbia > > www.crn.ubc.ca > > > > > > Notice: This communication may contain confidential, proprietary or > legally privileged information. It is intended only for the person(s) to > whom it is addressed. If you are not an intended recipient, please notify > the sender that you have received it in error and immediately delete the > entire communication, including any attachments. > > _______________________________________________ > 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 Nov 19 16:04:29 2012 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Mon, 19 Nov 2012 22:04:29 +0100 Subject: [IPython-dev] Just looking for feedback before PR In-Reply-To: References: <317EAFE2-9755-4839-AA5E-8BEA916CC14E@gmail.com> Message-ID: Le 19 nov. 2012 ? 01:21, Carl Smith a ?crit : >> Thus we went with markdown for cells, mainly because of how headings were >> handled. But as we began to use markdown, we realized that its approach to >> headings was a bit too flexible. We really wanted the ability for notebooks >> to have formal structure (nested heading levels). There are a number of >> usage cases for this: >> >> * Exporting to formats that also have nested heading levels (latex, html, >> etc.) >> * Enabling entire sections/subsections in a notebook to be moved, copied, >> collapsed, etc. That would be impossible to do with headings embedded >> inside markdown cells that have other content. >> * Heading cells are common enough that it is nice to be able to do them >> without the markdown syntax. > Hi Carl, The problem is not about extracting metadata by themself. It is more to manipulate notebook cell. The ideas is to be able to collapse everything under a cell level x to move it around. Which is difficult if this level is part of a MD cell that have a few things in it. Basically you want each header section (whatever level) to always be at the top of a cell. This would be doable without header cell, but as always it is still a subtile balance between complexity, support and feature. Hopefully time will come (hopefully before we'll took over the world), where we'll have enough resources to do better than that. But even if I would like to do without heading cell for now I'm fully supporting Brian. We've already thought of tags in md/code cell to add information. We don't believe it is the right solution, but don't prevent it to be implemented by other. My opinion is that inline metadata is really good for fast edit , but it diminish readability. A compromise would be a parser that read inline metadata and put them in hidden JSON metadata and vice versa. I would also add that notebook format is not for html only (e.g emacs client). Markdown is readable as plaintext, and html in markdown start to be difficult to read. adding extra information as inline tag would be extra noise (either from user, or from programmer to hide) whereas metadata field has just to be hidden. We'll be really happy to be proven wrong and find a better way, but as until now Brian vision for notebook always proven right. So for now, I think we will keep heading cell (it does not harm). Hopefully with time, we will see what happened and can deprecate the header cell if we feel the need to do so , of we if find they are not necessary. Thanks for your reflexion on it and the time you take to post your suggestion and your answer. This help us to know what feature of the notebook are known and not known to better target what need to be done. -- Matthias > Hi Brian > > Thanks for taking the time to explain this for me. So, the choice to > use header cells over hidden markup, is just considered more > convenient? If that's the case, to be honest, I'd still prefer to > define every element in my notebooks using plain text, even if it > meant just using some kind of pig XML. > > We could easily define some unused, HTML element names as meaningful, > then use them in Markdown cells, safe in the knowledge that the > browser will just ignore them. There's no reason not to use a tag like > in a Markdown cell for example. > > The hidden tags could provide meta for converters or extensions or > whatever else. These tags could have almost anything in them; you can > get away with murder if it's between angle brackets. Stuff like cmd arg0 arg1> would work fine. > > The tags used by HTML or core IPython features would be reserved, but > users could use the rest of the namespace arbitrarily, so a converter > might define a tag named . You could also reserve all names > that start with special strings like ipynb, so you could later define > tags that do stuff like src="http://site.com/license.html"> and mail="jd at site.com"> and so on. > > Maybe I'm still missing something, but that's where my thinking has > led me so far. > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From bussonniermatthias at gmail.com Mon Nov 19 16:13:15 2012 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Mon, 19 Nov 2012 22:13:15 +0100 Subject: [IPython-dev] ACE Editor Magic for IPython Notebook In-Reply-To: References: <5E4163E7-85F3-4E2D-AB80-4E7D3E52152B@gmail.com> Message-ID: Le 19 nov. 2012 ? 17:50, Carl Smith a ?crit : >> I think by publishing javascript/json you could open a new window that point to another URL and pass it parameter. >> That would be a start . >> I'm don't know how your app works, if it is a different server or not? > > It's just a JS editor, so you'd ordinarily implement your own server > and communication, normally using AJAX requests. One dirty way would be to use the '%%file' magic to write on disk. We could probably hook on user_expressions to get the file content. (for now) The other question is : Do we want to modify file on server computer or on kernel computer (that can be different) Kernel does IMHO make more sense. -- Matthias > > I could have IPython start up a second server on the same machine, and > then open a new tab, pointing it to the second server. This would be > easy to do, security aside, but misses the opportunity to work towards > a more elegant, general solution for all Notebook Panel Apps, which is > what I'm currently calling them. > > One important thing to consider early on is how to create a panel app > that can share a kernel with the Notebook. Some apps, like a shell, > would need that. > > Cheers > > P.S. I drafted an IPEP for this, IPEP 7, updated the wiki and sent a > message on both lists. > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From bussonniermatthias at gmail.com Mon Nov 19 16:22:13 2012 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Mon, 19 Nov 2012 22:22:13 +0100 Subject: [IPython-dev] use case - embedding IPython notebook within website (Drupal at least for now) In-Reply-To: References: Message-ID: <3467A0CC-E27F-4F72-AEBD-90461C481084@gmail.com> Le 19 nov. 2012 ? 18:46, Dan Lussier a ?crit : > Hi. > > I am a long time IPython user (thanks!) , but I am new to the IPython Notebook. > > I am interested in embedding IPython notebooks within a larger website project as a way to (1) statically demonstrate completed computations/figures, but also allow readers/users to experiment with their own computations. > > In reading about the Notebook - I understand I can generate a static HTML version of a notebook I develop and I could reskin (https://gist.github.com/1497850, https://github.com/fperez/blog). This is close to what I am looking for, but a few additional points of interest for me are: You could also have a look at nbviewer. (nbviewer.ipython.org) Since 0.13.1+ you should be able to override any file of ipython notebook by creating a modified version in .profile_xxx/static/whatever. not sure about template though. > > * Ability to embed the dynamic or state notebook within a larger page that is not generated by the IPython (iframes ?) > > * Security - constrain users to only limited resources on the webserver (file system, system function calls, total compute resources). We are building a public facing website which will have numerous, but not a huge number of external users. > > * Flexibility - Currently we are using Drupal as the web framework for the project, but this may be subject to change in future iterations of the projects, so my main interest is in understanding a general approach which would allow IPython notebooks to be embedded within a page. > > If anybody has experience in doing something similar, or has developed a workflow that facilitates this type of process I would really appreciate the leg up. If we end up developing a useful workflow or tool along the way we are happy to contribute it back to the project/ecosystem. We'll be happy to have you feedback to know what need to be done to help integration of notebook. Looking forward to experience in integrating notebook, and contribution. -- Matthias > > Many thanks, > > Dan Lussier > > > > Dan Lussier, BSc EIT > Research Engineer > > Composites Research Network > University of British Columbia > www.crn.ubc.ca > > > > Notice: This communication may contain confidential, proprietary or legally privileged information. It is intended only for the person(s) to whom it is addressed. If you are not an intended recipient, please notify the sender that you have received it in error and immediately delete the entire communication, including any attachments. > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From carl.input at gmail.com Mon Nov 19 17:36:14 2012 From: carl.input at gmail.com (Carl Smith) Date: Mon, 19 Nov 2012 22:36:14 +0000 Subject: [IPython-dev] Just looking for feedback before PR In-Reply-To: References: <317EAFE2-9755-4839-AA5E-8BEA916CC14E@gmail.com> Message-ID: Thanks, both to Brian and Matthias, for taking the time to discuss this with me. Personally, I'd never put a header anywhere except at the top of a cell, but I understand that's not something you can rely on. Other users may do so from time to time. Please don't make them mandatory though. I think there's a PR looking at converting headers into header cells. That would be frustrating. The solution to all this may lay in creating a new, Markdown based language, specifically for the Notebook, but I understand this would be expensive and only addresses minor UX issues, so I'm happy to fall in behind Brian and focus on other things. His judgement to date has been excellent. Thanks again for your time and patience. All the best Carl From carl.input at gmail.com Mon Nov 19 19:03:59 2012 From: carl.input at gmail.com (Carl Smith) Date: Tue, 20 Nov 2012 00:03:59 +0000 Subject: [IPython-dev] Extending the Notebook File Format Message-ID: Firstly, I'd like to say sorry to everyone on this list. I've been pretty vocal lately, mostly suggesting features that I'm only loosely committed to working on, or criticising features other people worked hard on. I really don't mean to be difficult. That said, I did want to bring up one more issue :) The current file format, .ipynb, works well for actual notebooks, but doesn't include the ancillary files, so it's hard to share your work. Obviously, users can put the notebook in the root directory of a project tree, ensure everything they want to share is in there somewhere, then zip it, but doing this by hand is not exactly convenient, and doesn't deal with stuff like config files well. I'd like to suggest creating a second file format, for packaged notebooks, that is just the current file format, but with the file and whatever else you'd like to include inside a zipped directory. IPython should recognise these package files and handle them, unzipping them behind the scenes. A user could still create a regular notebook, and work loosely, so they wouldn't need to worry about project directories. They could save this as a regular notebook, just as they can now. Nothing should change on that front, but, if the user was interested in sharing or publishing their notebook along with their data, they would be encouraged to create a notebook project. Only a project could be reliably packaged. It'd be nice to have a projectify tool that could take a notebook and check any paths that it uses, any extensions, any customisations or config files and raise warnings with dialogues if they're not where they need to be, so you could usually turn a sketchy notebook into a tidy project with a few clicks of the OK button. The Notebook interface would include New File and New Project options, so users will normally start with a regular file if they're just hacking stuff, and would start with a project if they intend to share it, but being able to turn a notebook into a project would be nice. The same tool would be able to check a project before it was packaged to ensure everything was still all present and correct. When working on a project, hitting Save would just update the notebook file, but hitting Package would run the validator and go through the motions, before zipping the project, ready for sharing. This process would copy any needed files from the user's current notebook profile too, so all that stuff would also be preserved in the package in a way that IPython knows how to handle. Longer term, this format could be extended to include an optional config file. If it was present, it'd be used for things like creating packages with many notebooks, that could be read like a book, or could include information on mounting big datasets or installing dependencies and so on, which would be especially handy for consistent environments like NotebookCloud or Wakari, where these types of things can be done pretty reliably with a script. Again, sorry to be so noisy just lately, and thanks for being so good about it. I'm just sharing ideas in the hope that there's enough value in some of them to justify the bandwidth I've consumed. Cheers all Carl From bussonniermatthias at gmail.com Tue Nov 20 04:30:33 2012 From: bussonniermatthias at gmail.com (Matthias Bussonnier) Date: Tue, 20 Nov 2012 10:30:33 +0100 Subject: [IPython-dev] Extending the Notebook File Format In-Reply-To: References: Message-ID: Hi, I think the subject of project bundle have already been discussed somewhere some time ago. I don't quite remember what was said. I don't think it is worth a file 'format'. But unzipping/taring support maybe. But this will.come with the ability to browse disk with.frontend i think. As we wish to have backend like git which have ways of generating tarball, we could hook on that. But lets not forget that zipping would lost commit history, and that seemless integration with things like github/gists (which can be multi files) would be better. The dependencies/checking is IMHO ouside of IPython scope. There have been some mail on project manager for python a month or so ago, which are more general tool that could be adapted to works with IPython. Thanks for your ideas, carry on we don't mind and love discussing. -- Matthias. Le 20 nov. 2012 01:04, "Carl Smith" a ?crit : > Firstly, I'd like to say sorry to everyone on this list. I've been > pretty vocal lately, mostly suggesting features that I'm only loosely > committed to working on, or criticising features other people worked > hard on. I really don't mean to be difficult. That said, I did want to > bring up one more issue :) > > The current file format, .ipynb, works well for actual notebooks, but > doesn't include the ancillary files, so it's hard to share your work. > Obviously, users can put the notebook in the root directory of a > project tree, ensure everything they want to share is in there > somewhere, then zip it, but doing this by hand is not exactly > convenient, and doesn't deal with stuff like config files well. > > I'd like to suggest creating a second file format, for packaged > notebooks, that is just the current file format, but with the file and > whatever else you'd like to include inside a zipped directory. IPython > should recognise these package files and handle them, unzipping them > behind the scenes. > > A user could still create a regular notebook, and work loosely, so > they wouldn't need to worry about project directories. They could save > this as a regular notebook, just as they can now. Nothing should > change on that front, but, if the user was interested in sharing or > publishing their notebook along with their data, they would be > encouraged to create a notebook project. Only a project could be > reliably packaged. > > It'd be nice to have a projectify tool that could take a notebook and > check any paths that it uses, any extensions, any customisations or > config files and raise warnings with dialogues if they're not where > they need to be, so you could usually turn a sketchy notebook into a > tidy project with a few clicks of the OK button. > > The Notebook interface would include New File and New Project options, > so users will normally start with a regular file if they're just > hacking stuff, and would start with a project if they intend to share > it, but being able to turn a notebook into a project would be nice. > The same tool would be able to check a project before it was packaged > to ensure everything was still all present and correct. > > When working on a project, hitting Save would just update the notebook > file, but hitting Package would run the validator and go through the > motions, before zipping the project, ready for sharing. This process > would copy any needed files from the user's current notebook profile > too, so all that stuff would also be preserved in the package in a way > that IPython knows how to handle. > > Longer term, this format could be extended to include an optional > config file. If it was present, it'd be used for things like creating > packages with many notebooks, that could be read like a book, or could > include information on mounting big datasets or installing > dependencies and so on, which would be especially handy for consistent > environments like NotebookCloud or Wakari, where these types of things > can be done pretty reliably with a script. > > Again, sorry to be so noisy just lately, and thanks for being so good > about it. I'm just sharing ideas in the hope that there's enough value > in some of them to justify the bandwidth I've consumed. > > Cheers all > > Carl > _______________________________________________ > 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 Nov 20 05:40:00 2012 From: takowl at gmail.com (Thomas Kluyver) Date: Tue, 20 Nov 2012 10:40:00 +0000 Subject: [IPython-dev] Extending the Notebook File Format In-Reply-To: References: Message-ID: I don't know exactly how it should work, but I like the idea of some way to store code and data together in a form that can easily be moved between computers and shared with colleagues. CCed again Trent Hauck, the author of Gloo, the project manager mentioned on the list before, as he might have ideas relevant to the discussion. Thanks, Thomas On 20 November 2012 09:30, Matthias Bussonnier wrote: > Hi, > > I think the subject of project bundle have already been discussed > somewhere some time ago. I don't quite remember what was said. > > I don't think it is worth a file 'format'. But unzipping/taring support > maybe. But this will.come with the ability to browse disk with.frontend i > think. > > As we wish to have backend like git which have ways of generating tarball, > we could hook on that. But lets not forget that zipping would lost commit > history, and that seemless integration with things like github/gists (which > can be multi files) would be better. > > The dependencies/checking is IMHO ouside of IPython scope. There have been > some mail on project manager for python a month or so ago, which are more > general tool that could be adapted to works with IPython. > > Thanks for your ideas, carry on we don't mind and love discussing. > -- > Matthias. > Le 20 nov. 2012 01:04, "Carl Smith" a ?crit : > > Firstly, I'd like to say sorry to everyone on this list. I've been >> pretty vocal lately, mostly suggesting features that I'm only loosely >> committed to working on, or criticising features other people worked >> hard on. I really don't mean to be difficult. That said, I did want to >> bring up one more issue :) >> >> The current file format, .ipynb, works well for actual notebooks, but >> doesn't include the ancillary files, so it's hard to share your work. >> Obviously, users can put the notebook in the root directory of a >> project tree, ensure everything they want to share is in there >> somewhere, then zip it, but doing this by hand is not exactly >> convenient, and doesn't deal with stuff like config files well. >> >> I'd like to suggest creating a second file format, for packaged >> notebooks, that is just the current file format, but with the file and >> whatever else you'd like to include inside a zipped directory. IPython >> should recognise these package files and handle them, unzipping them >> behind the scenes. >> >> A user could still create a regular notebook, and work loosely, so >> they wouldn't need to worry about project directories. They could save >> this as a regular notebook, just as they can now. Nothing should >> change on that front, but, if the user was interested in sharing or >> publishing their notebook along with their data, they would be >> encouraged to create a notebook project. Only a project could be >> reliably packaged. >> >> It'd be nice to have a projectify tool that could take a notebook and >> check any paths that it uses, any extensions, any customisations or >> config files and raise warnings with dialogues if they're not where >> they need to be, so you could usually turn a sketchy notebook into a >> tidy project with a few clicks of the OK button. >> >> The Notebook interface would include New File and New Project options, >> so users will normally start with a regular file if they're just >> hacking stuff, and would start with a project if they intend to share >> it, but being able to turn a notebook into a project would be nice. >> The same tool would be able to check a project before it was packaged >> to ensure everything was still all present and correct. >> >> When working on a project, hitting Save would just update the notebook >> file, but hitting Package would run the validator and go through the >> motions, before zipping the project, ready for sharing. This process >> would copy any needed files from the user's current notebook profile >> too, so all that stuff would also be preserved in the package in a way >> that IPython knows how to handle. >> >> Longer term, this format could be extended to include an optional >> config file. If it was present, it'd be used for things like creating >> packages with many notebooks, that could be read like a book, or could >> include information on mounting big datasets or installing >> dependencies and so on, which would be especially handy for consistent >> environments like NotebookCloud or Wakari, where these types of things >> can be done pretty reliably with a script. >> >> Again, sorry to be so noisy just lately, and thanks for being so good >> about it. I'm just sharing ideas in the hope that there's enough value >> in some of them to justify the bandwidth I've consumed. >> >> Cheers all >> >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From d.warde.farley at gmail.com Tue Nov 20 15:10:04 2012 From: d.warde.farley at gmail.com (David Warde-Farley) Date: Tue, 20 Nov 2012 15:10:04 -0500 Subject: [IPython-dev] Notebook "execution engine"? Message-ID: My perusal of the docs has failed me if this already exists, but as a counterpart to nbstripout (in nbconvert), it seems like a useful utility to have would be a way of executing notebooks in a "headless notebook" server, with figures and other output being captured and dumped to a second, output notebook. I'm thinking of use cases in buildbots and the like. Am I right in assuming that the process of going from notebook file with only inputs to notebook with inputs and outputs currently relies on there being a browser in the loop? David -------------- next part -------------- An HTML attachment was scrubbed... URL: From bussonniermatthias at gmail.com Tue Nov 20 15:35:30 2012 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Tue, 20 Nov 2012 21:35:30 +0100 Subject: [IPython-dev] Notebook "execution engine"? In-Reply-To: References: Message-ID: Le 20 nov. 2012 ? 21:10, David Warde-Farley a ?crit : > My perusal of the docs has failed me if this already exists, but as a counterpart to nbstripout (in nbconvert), it seems like a useful utility to have would be a way of executing notebooks in a "headless notebook" server, with figures and other output being captured and dumped to a second, output notebook. I'm thinking of use cases in buildbots and the like. > > Am I right in assuming that the process of going from notebook file with only inputs to notebook with inputs and outputs currently relies on there being a browser in the loop? Nothing in IPython repository, As usual, looking at min's gists... (but should be adapted) https://gist.github.com/2620735 In anyway we will have to maintain the ipynb state on the server side at some point so this would exist in the future in a tested and up-to-date version. -- Matthias > > David > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From massimodisasha at gmail.com Tue Nov 20 20:02:15 2012 From: massimodisasha at gmail.com (Massimo Di Stefano) Date: Tue, 20 Nov 2012 20:02:15 -0500 Subject: [IPython-dev] lines number in code cell Message-ID: Hi All, i was wondering if it is possible (and if make sense for you) to modify the stile of a cell type : code adding line's number. what do you think ? can you point to the src code that generates the graphic layout for the code cell ? Thanks! Massimo. From fperez.net at gmail.com Tue Nov 20 20:22:19 2012 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 20 Nov 2012 17:22:19 -0800 Subject: [IPython-dev] lines number in code cell In-Reply-To: References: Message-ID: On Tue, Nov 20, 2012 at 5:02 PM, Massimo Di Stefano wrote: > i was wondering if it is possible (and if make sense for you) to modify the stile of a cell type : code > adding line's number. > what do you think ? See the keyboard shortcuts: C-M-L toggles line numbers. Cheers f From asmeurer at gmail.com Tue Nov 20 21:13:19 2012 From: asmeurer at gmail.com (Aaron Meurer) Date: Tue, 20 Nov 2012 19:13:19 -0700 Subject: [IPython-dev] lines number in code cell In-Reply-To: References: Message-ID: You mean C-m l. C-M-L means (at least to an Emacs user such as myself) Control-Meta-L, or even Control-Meta-Shift-L. Nice feature, by the way. Aaron Meurer On Tue, Nov 20, 2012 at 6:22 PM, Fernando Perez wrote: > On Tue, Nov 20, 2012 at 5:02 PM, Massimo Di Stefano > wrote: > > i was wondering if it is possible (and if make sense for you) to modify > the stile of a cell type : code > > adding line's number. > > what do you think ? > > See the keyboard shortcuts: C-M-L toggles line numbers. > > 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 Nov 20 22:24:57 2012 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 20 Nov 2012 19:24:57 -0800 Subject: [IPython-dev] lines number in code cell In-Reply-To: References: Message-ID: On Tue, Nov 20, 2012 at 6:13 PM, Aaron Meurer wrote: > You mean C-m l. C-M-L means (at least to an Emacs user such as myself) > Control-Meta-L, or even Control-Meta-Shift-L. > > Nice feature, by the way. Yes, I used caps to try to avoid the i/l confusion in lowercase, but only introduced a modifier confusion, sorry :) In our shortcuts, 'm' (the m lettter, not the Meta key) acts effectively as a near-universal modifier for most bindings, and I just didn't think of the possible confusion with Meta. Cheers, f From fperez.net at gmail.com Tue Nov 20 22:26:05 2012 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 20 Nov 2012 19:26:05 -0800 Subject: [IPython-dev] Recap of PyConCa 2012 with what got done for IPython Message-ID: Hi all, in case you are interested, here's a short recap on my recent pycon canada talk/visit, including a summary of the work done by various folks at the sprints on IPython: http://blog.fperez.org/2012/11/back-from-pycon-canada-2012.html please let me know if I omitted anyone so I can rectify that! Cheers, f From thereisnocowlevel at gmail.com Tue Nov 20 23:08:54 2012 From: thereisnocowlevel at gmail.com (Rishi Ramraj) Date: Tue, 20 Nov 2012 23:08:54 -0500 Subject: [IPython-dev] Recap of PyConCa 2012 with what got done for IPython In-Reply-To: References: Message-ID: FYI: The repository that contains the molecular visualiser: https://github.com/RishiRamraj/seepymol On Tue, Nov 20, 2012 at 10:26 PM, Fernando Perez wrote: > Hi all, > > in case you are interested, here's a short recap on my recent pycon > canada talk/visit, including a summary of the work done by various > folks at the sprints on IPython: > > http://blog.fperez.org/2012/11/back-from-pycon-canada-2012.html > > please let me know if I omitted anyone so I can rectify that! > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Cheers, - Rishi -------------- next part -------------- An HTML attachment was scrubbed... URL: From asmeurer at gmail.com Wed Nov 21 03:51:31 2012 From: asmeurer at gmail.com (Aaron Meurer) Date: Wed, 21 Nov 2012 01:51:31 -0700 Subject: [IPython-dev] IPEP 7: Notebook dependent frontends In-Reply-To: References: Message-ID: On Mon, Nov 19, 2012 at 10:49 AM, Carl Smith wrote: > On 19 November 2012 17:13, Brian Granger wrote: > > Carl, > > > > I think there has been a bit of confusion. I think the IPEP we need to > > discuss at this point is for adding *native* support in the IPython > Notebook > > server for editing other file types using ACE/CodeMirror. That is, I > think > > we want the notebook dashboard to show all file types (not just > notebooks) > > and when a user clicks on one of the other file types, they get an editor > > window with that file. This should be fully integrated with the notebook > > UI+Server and on by default for all users. I don't think we want to go > into > > the direction that you propose of allowing the creation of completely > custom > > UIs/Frontends. The reason is that such UIs will require custom server > code > > to support, which raises a whole bunch of issues that we are simply not > > ready to tackle in any way. Does this make sense? > > Ah, OK. Feel free to edit or delete the IPEP if it's not especially > useful as is. > Wouldn't it be better to add some kind of "rejected" status to the IPEP, similar to regular Python PEPs? In fact, I find the status part of regular PEPs to be the most useful part, because it's otherwise not clear if the PEP was already implemented, or being implemented, or still being written/discussed, or rejected, or what. Here's a PEP of the Python PEP guidelines: http://www.python.org/dev/peps/pep-0001/. It might be useful to emulate much of that with the IPEPs. Aaron Meurer > I was intending for these frontends to only use the existing API that > the Notebook uses now, so no server side changes would need to be made > beyond adding one feature. The IPython server would need to be able to > serve any local file as a HTTP response. > > If the IPython server API could accept requests to a specified URL, > where the request would contain a path to a file, and the server could > just return that file, then everything should work without any other > changes being made. > > A user could save the main HTML file for any web app on the same > machine IPython is running on, then write a magic that outputs some > JS. The JS would open a new tab, pointing the tab at the specified URL > and passing the file's path in the request. The server would return > the file, and the app would be rendered in the new tab. Once the app > is running, it should use the same API as the Notebook uses for all > future interactions with the server/kernel. > > You could almost do this now, but you'd need a separate server to > simply serve the panel app's source on each instantiation. > > > On this broader issue, the new Javascript plugins under review would > provide > > an implementation route for some of what you are talking about (the > client > > side, not the server side). > > I wasn't aware of this work. Maybe this will handle the problems on > the client-side, which, as I understand it, are only problems of > difficulty, rather than technical limitations. > > Thanks Brian > _______________________________________________ > 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 Wed Nov 21 14:21:24 2012 From: carl.input at gmail.com (Carl Smith) Date: Wed, 21 Nov 2012 19:21:24 +0000 Subject: [IPython-dev] IPEP 7: Notebook dependent frontends In-Reply-To: References: Message-ID: > Wouldn't it be better to add some kind of "rejected" status to the IPEP, > similar to regular Python PEPs? In fact, I find the status part of regular > PEPs to be the most useful part, because it's otherwise not clear if the PEP > was already implemented, or being implemented, or still being > written/discussed, or rejected, or what. This sounds like a good idea in general, though I do still think this IPEP is worth considering. The Notebook currently imposes a number of major limitations that inhibit development by third parties. There's growing, and already significant, interest in using the IPython Notebook in ways that IPython Dev are unlikely to work on directly. I think it's important to have IPython work well as a library for reuse, and this IPEP at least opens up exploration of how that can be achieved on one important front, web clients. From fperez.net at gmail.com Wed Nov 21 22:09:15 2012 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 21 Nov 2012 19:09:15 -0800 Subject: [IPython-dev] Recap of PyConCa 2012 with what got done for IPython In-Reply-To: References: Message-ID: On Tue, Nov 20, 2012 at 8:08 PM, Rishi Ramraj wrote: > FYI: The repository that contains the molecular visualiser: > > https://github.com/RishiRamraj/seepymol Oops, I failed to include that link, sorry. Fixed now. From d.warde.farley at gmail.com Thu Nov 22 15:14:05 2012 From: d.warde.farley at gmail.com (David Warde-Farley) Date: Thu, 22 Nov 2012 15:14:05 -0500 Subject: [IPython-dev] cythonmagic mysteriously broken (EPD 7.1-2) Message-ID: Using epd-7.1-2 at my workplace, IPython master, and Cython 0.17.2 installed in ~/.local, I get the following using the Cython cell magic: %%cython cdef int i(): return 0 Exception in thread Thread-2: Traceback (most recent call last): File "/opt/lisa/os/epd-7.1.2/lib/python2.7/threading.py", line 552, in __bootstrap_inner self.run() File "/u/wardefar/src/ipython/IPython/zmq/heartbeat.py", line 55, in run zmq.device(zmq.FORWARDER, self.socket, self.socket) File "device.pyx", line 55, in zmq.core.device.device (zmq/core/device.c:851) ZMQError: Interrupted system call Then the kernel dies. Any idea what's going on? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wen.g.gong at gmail.com Thu Nov 22 19:41:34 2012 From: wen.g.gong at gmail.com (W Gong) Date: Thu, 22 Nov 2012 19:41:34 -0500 Subject: [IPython-dev] where is the code to generate IPython Notebook URL for a new .ipynb file Message-ID: Hi, I am new and like to know which file has the code to generate IPython Notebook URL for a new .ipynb file. For example, I start notebook in a folder "c:\ipython", as soon as a new "test.ipynb" file is dropped into that folder, the dashboard shows the "test.ipynb" file and generates an URL like http://127.0.0.1:8888/519307ea-7f69-4add-95a4-17cfe6ef101a I like to know whether a dict exists between the filename "test.ipynb" and the URL string. Thanks, Wen -------------- next part -------------- An HTML attachment was scrubbed... URL: From bussonniermatthias at gmail.com Fri Nov 23 04:06:00 2012 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Fri, 23 Nov 2012 10:06:00 +0100 Subject: [IPython-dev] where is the code to generate IPython Notebook URL for a new .ipynb file In-Reply-To: References: Message-ID: Le 23 nov. 2012 ? 01:41, W Gong a ?crit : > Hi, > I am new and like to know which file has the code to generate IPython Notebook URL for a new .ipynb file. > > For example, I start notebook in a folder "c:\ipython", > as soon as a new "test.ipynb" file is dropped into that folder, > the dashboard shows the "test.ipynb" file and generates an URL like > http://127.0.0.1:8888/519307ea-7f69-4add-95a4-17cfe6ef101a > > I like to know whether a dict exists between the filename "test.ipynb" and the URL string. Hi, The regex for URL is defined here : IPython/frontend/html/notebook/notebookapp.py L144 And the dict cam from FileNotebookManager (filenbmanager.py) L49. You can also access it via the http://127.0.0.1:8888/notebooks url. Hope that's help. Tell us if you need more explanation on what does what. -- Matthias > > Thanks, > Wen > > > > > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From aka.tkf at gmail.com Fri Nov 23 15:27:15 2012 From: aka.tkf at gmail.com (Takafumi Arakaki) Date: Fri, 23 Nov 2012 21:27:15 +0100 Subject: [IPython-dev] Enhancement proposal for kernel messaging protocol Message-ID: Dear IPython developers, I wrote a PR for adding new option to messaging protocol [1]_. Bussonnier Matthias and Thomas Kluyver suggested to discuss about possible extensions for current messaging protocol, and then make an IPEP before working on these extensions. So, let me start the discussion here. 1. Protocol introspection. Currently, messaging protocol has no introspection mechanism. It is not a problem when the messaging protocol is used only for internal communication. However, there are various software using IPython via messaging protocol. Also, IPython version of the kernel and client can be different, for example when used over ssh connection. Therefore, we need some introspection mechanism to inform messaging protocol supported by connecting kernel. One way to inform supported messaging protocol is to add version number to the messaging protocol. There are several options for version numbering: a. Protocol version = IPython version. This may be the simplest way to do it. But in development version, supported protocol will be unclear. b. Semantic Versioning [2]_. This is some what close to how notebook version works (right?). Simple explanation: It takes the form of `x.y.z`. Patch version `z` is incremented for bug fix. Minor version `y` is incremented for backward compatible changes. Major version `x` is incremented for backwards incompatible changes. For the messaging protocol, the next version number will be 1.1.0 if we think the current protocol is public. It will be 0.2.0 if we think the current protocol is still in development. There are several ways to let client know the version number. c. Add `version_request` / `version_reply` messaging protocol. d. Add `version` slot to the message format. It can be in the top level, `header` or `metadata`. e. Send version number during "hand shake" (but there is no such stage for the current messaging protocol, I suppose?). 2. New optional `unique` key to `history_request`. I propose [1]_ to add this new boolean key `unique` to `history_request` [3]_. When this key is specified and true, `history_reply` contains only entries of unique input. This is useful for searching history using `hist_access_type: 'search'`. This operation can be done in client side. However, sending large number of entries over messaging protocol is time consuming. One case this `unique` key can be critical is when using `history_request` in an interactive UI to search IPython history in as-you-type manner ("QuickSilver style"; for example, my Emacs client EIN [4]_ has such UI). For such kind of UI speed is critical and it is preferred to be done in the kernel side. (As you can see, this is the reason why I made the PR in the first place!) 3. Messaging protocol to pass structured data to kernel. Currently it is not possible to pass structured data such as dict from client to kernel. You can generate Python code and use `execute_request`, but it is difficult to do this properly in non-Python client such as Javascript client. Note that it is already possible to pass structured data to client from kernel by using JSON repr. (I think I saw some argument related to this issue tracker, but I can't find it now. Please post the link if you know.) There are several ways to solve this problem: a. Add RPC-like message `call_request` / `call_reply`. Client can execute a short code to register "methods" in kernel to use this RPC. For example `__import__('mylib.ipyutils').register()`. b. Add `override_variables` slot to `execute_request`. This slot takes a dict and the value in the dict will override the value correspond to its key. For example, client can execute `func(x)` with `override_variables: {'x': 1}`. The problem is that it contaminates user's namespace. To solve this problem, we can add another `namespace` slot to `execute_request`. This way, client can import its supporting library without contaminating user's namespace and execute its functions using `override_variables`. For example, client can issue `execute_request` like this:: {'code' "import mylib; mylib.ipyutils.func(x)", 'namespace': 'mylib', 'override_variables': {'x': 1}} Merit of this approach comparing to the other one (`call_request`) is that `namespace` can be used for another purpose. For example, notebook client can have separated namespace for each worksheet, to avoid namespace collision. Sharing data between namespaces can be easily done by using singleton object. Other possible application is editor integration. For example, you have associate one namespace to each file (= python module) opened in the editor. .. [1] https://github.com/ipython/ipython/pull/2609 .. [2] http://semver.org/ .. [3] http://ipython.org/ipython-doc/dev/development/messaging.html#history .. [4] http://github.com/tkf/emacs-ipython-notebook --- Takafumi Arakaki From ellisonbg at gmail.com Fri Nov 23 19:17:28 2012 From: ellisonbg at gmail.com (Brian Granger) Date: Fri, 23 Nov 2012 16:17:28 -0800 Subject: [IPython-dev] Extending the Notebook File Format In-Reply-To: References: Message-ID: On Mon, Nov 19, 2012 at 4:03 PM, Carl Smith wrote: > Firstly, I'd like to say sorry to everyone on this list. I've been > pretty vocal lately, mostly suggesting features that I'm only loosely > committed to working on, or criticising features other people worked > hard on. I really don't mean to be difficult. That said, I did want to > bring up one more issue :) No problem, we don't mind lots of ideas flying around. It doesn't mean we will implement every things, but it is good to discuss these things. > The current file format, .ipynb, works well for actual notebooks, but > doesn't include the ancillary files, so it's hard to share your work. > Obviously, users can put the notebook in the root directory of a > project tree, ensure everything they want to share is in there > somewhere, then zip it, but doing this by hand is not exactly > convenient, and doesn't deal with stuff like config files well. > > I'd like to suggest creating a second file format, for packaged > notebooks, that is just the current file format, but with the file and > whatever else you'd like to include inside a zipped directory. IPython > should recognise these package files and handle them, unzipping them > behind the scenes. When we originally designed the notebook format, we thought about doing something like this. We even wrote an NSF proposal that had details on a notebook+data package format. But I think our thinking has evolved on this issue somewhat. The big change in our thinking has been driven by git/github. At this point, git/github have become a nearly universal way of collaborating and sharing code+data with others. Last Spring at PyCon, Fernando and I had many long discussions about how we wanted to encourage sharing in the notebook. Our conclusion was something like this: * Everyone should already be putting their code+data on git/github or other version control systems. * These systems implement a nearly universal approach to sharing sets of files that scale from person-to-person to very large teams. * The default and recommended way of sharing in the notebook should be through git repos (or other VCSs) * We should build tools to encourage and support those usage patterns. An example of this type of integration would be a button to publish a notebook to a gist. * We should not try to reinvent the wheel in this area. * This is consistent with ipython's notion of a notebook project, namely that it is just a regular directory on your file system. With these things in mind, we have mostly moved away from the idea of a special ipython package format. The other *massive* complete showstopper problem with having a package format that consists of zipping up files is this: It can't be version controlled. In my mind, the future of open reproducible computing sits on top of the foundation of version control. Without that, all of our best practices fall apart. > A user could still create a regular notebook, and work loosely, so > they wouldn't need to worry about project directories. They could save > this as a regular notebook, just as they can now. Nothing should > change on that front, but, if the user was interested in sharing or > publishing their notebook along with their data, they would be > encouraged to create a notebook project. Only a project could be > reliably packaged. Are there any usage cases that a git repo can't cover? > It'd be nice to have a projectify tool that could take a notebook and > check any paths that it uses, any extensions, any customisations or > config files and raise warnings with dialogues if they're not where > they need to be, so you could usually turn a sketchy notebook into a > tidy project with a few clicks of the OK button. I think there are multiple issues in this paragraph that really need to be considered separately: * What constitutes and ipython project * Installation/libraries/environment * Incorporating config into the notebook format. > The Notebook interface would include New File and New Project options, > so users will normally start with a regular file if they're just > hacking stuff, and would start with a project if they intend to share > it, but being able to turn a notebook into a project would be nice. > The same tool would be able to check a project before it was packaged > to ensure everything was still all present and correct. > > When working on a project, hitting Save would just update the notebook > file, but hitting Package would run the validator and go through the > motions, before zipping the project, ready for sharing. This process > would copy any needed files from the user's current notebook profile > too, so all that stuff would also be preserved in the package in a way > that IPython knows how to handle. > > Longer term, this format could be extended to include an optional > config file. If it was present, it'd be used for things like creating > packages with many notebooks, that could be read like a book, or could > include information on mounting big datasets or installing > dependencies and so on, which would be especially handy for consistent > environments like NotebookCloud or Wakari, where these types of things > can be done pretty reliably with a script. I think that part of the success of the ipython notebook is how we don't try to layer anything on top of your files system. Notebook files are just plain files on your file system, there is no database that adds additional layers of info on top of that, immediate integration with git, etc. While I think there are nice ideas in what you are proposing, it would pull us away from this beautiful and simple model that has served us so well. Cheers, Brian > Again, sorry to be so noisy just lately, and thanks for being so good > about it. I'm just sharing ideas in the hope that there's enough value > in some of them to justify the bandwidth I've consumed. > > Cheers all > > Carl > _______________________________________________ > 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 Fri Nov 23 19:20:48 2012 From: ellisonbg at gmail.com (Brian Granger) Date: Fri, 23 Nov 2012 16:20:48 -0800 Subject: [IPython-dev] IPEP 7: Notebook dependent frontends In-Reply-To: References: Message-ID: I don't disagree that we want IPython to be useful as a library, I just didn't think that is what this IPEP was going to be about originally. On Wed, Nov 21, 2012 at 11:21 AM, Carl Smith wrote: >> Wouldn't it be better to add some kind of "rejected" status to the IPEP, >> similar to regular Python PEPs? In fact, I find the status part of regular >> PEPs to be the most useful part, because it's otherwise not clear if the PEP >> was already implemented, or being implemented, or still being >> written/discussed, or rejected, or what. > > This sounds like a good idea in general, though I do still think this > IPEP is worth considering. > > The Notebook currently imposes a number of major limitations that > inhibit development by third parties. There's growing, and already > significant, interest in using the IPython Notebook in ways that > IPython Dev are unlikely to work on directly. I think it's important > to have IPython work well as a library for reuse, and this IPEP at > least opens up exploration of how that can be achieved on one > important front, web clients. > _______________________________________________ > 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 carl.input at gmail.com Fri Nov 23 19:55:55 2012 From: carl.input at gmail.com (Carl Smith) Date: Sat, 24 Nov 2012 00:55:55 +0000 Subject: [IPython-dev] Extending the Notebook File Format In-Reply-To: References: Message-ID: Cheers Brian I'm really interested in ways to share notebooks, so I appreciate you taking the time to go over this. I'll keep the following points in mind. > * Everyone should already be putting their code+data on git/github or > other version control systems. > * These systems implement a nearly universal approach to sharing sets > of files that scale from person-to-person to very large teams. > * The default and recommended way of sharing in the notebook should be > through git repos (or other VCSs) > * We should build tools to encourage and support those usage patterns. > An example of this type of integration would be a button to publish a > notebook to a gist. > * We should not try to reinvent the wheel in this area. > * This is consistent with ipython's notion of a notebook project, > namely that it is just a regular directory on your file system. This makes a lot of sense, and I can see why zipping directories isn't going to work. I should have been thinking git from the start. > Are there any usage cases that a git repo can't cover? Nothing that zipping a directory might solve. I'll give it some more thought. Thanks again. From carl.input at gmail.com Fri Nov 23 20:04:04 2012 From: carl.input at gmail.com (Carl Smith) Date: Sat, 24 Nov 2012 01:04:04 +0000 Subject: [IPython-dev] IPEP 7: Notebook dependent frontends In-Reply-To: References: Message-ID: I'm happy to see it edited to represent what you wanted you were thinking of. Whatever you think's best. This idea can be discussed on the list if anyone wants to explore it. All the best Carl From wen.g.gong at gmail.com Fri Nov 23 22:04:11 2012 From: wen.g.gong at gmail.com (W Gong) Date: Fri, 23 Nov 2012 22:04:11 -0500 Subject: [IPython-dev] how ipython notebook support widget or applet besides HTML and code? Message-ID: Hi, I learned ipython notebook a few days ago and like it very much, To me, IPython Notebook is a new generation of web browser because it brings exploration and interactivity to user. One question is how to add widget support (e.g. embed canvas, drawing board, java applet). To illustrate my use-case, here is a notebook that I created to teach python to 10 yr old kids. To make it more interesting or engaging, I combine rich text, image, video with code. In this example, I used HTML() to embed a javascript clock at the beginning. But how would one do the same in python? I have another use-case to embed java applet: Nobel Physicist - Carl Wieman at U of Colorado - Bolder has a wonderful science education initiative called PhET which is to bring virtual lab to science students. If teachers and students can perform virtual experiment, at the same time, do calculations in math/physics via sympy and write a lab report, all within the IPython notebook, it would be a huge boost to our education. Thanks and cheers, Wen -------------- next part -------------- An HTML attachment was scrubbed... URL: From bussonniermatthias at gmail.com Sat Nov 24 06:10:05 2012 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Sat, 24 Nov 2012 12:10:05 +0100 Subject: [IPython-dev] how ipython notebook support widget or applet besides HTML and code? In-Reply-To: References: Message-ID: Le 24 nov. 2012 ? 04:04, W Gong a ?crit : Hi, > Hi, > I learned ipython notebook a few days ago and like it very much, > To me, IPython Notebook is a new generation of web browser because it brings exploration and interactivity to user. > > One question is how to add widget support (e.g. embed canvas, drawing board, java applet). Depending on what you exactly want to do you might have different way of doing it. The first thing you can do is use display protocol (see docs/example/notebook/display_protocol.ipynb) to define html/latex/json representation for object. other example http://nbviewer.ipython.org/urls/raw.github.com/ipython/ipython/master/docs/examples/notebooks/00_notebook_tour.ipynb Near the end, you have a youtube video python object which representation is an embedded youtube player. > To illustrate my use-case, here is a notebook that I created to teach python to 10 yr old kids. To make it more interesting or engaging, I combine rich text, image, video with code. In this example, I used HTML() to embed a javascript clock at the beginning. But how would one do the same in python? The other thing we are working on are json plugin https://github.com/ipython/ipython/pull/2518 have a look at http://vimeo.com/channels/pydata/53051817 for demo. > > I have another use-case to embed java applet: > Nobel Physicist - Carl Wieman at U of Colorado - Bolder has a wonderful science education initiative called PhET which is to bring virtual lab to science students. > If teachers and students can perform virtual experiment, at the same time, do calculations in math/physics via sympy and write a lab report, all within the IPython notebook, it would be a huge boost to our education. You should be able to do the same and use a custom _repr_html_ to display this form python. I think the introduction notebook in /docs/example/notebooks/ are a good start to see what could be done. also, you can share static version of your notebook through nbviewer.ipython.org. here is what it looks for yours. http://nbviewer.ipython.org/url/dl.dropbox.com/u/54552252/what-is-time.ipynb -- Matthias From wen.g.gong at gmail.com Sat Nov 24 20:16:20 2012 From: wen.g.gong at gmail.com (W Gong) Date: Sat, 24 Nov 2012 20:16:20 -0500 Subject: [IPython-dev] how ipython notebook support widget or applet besides HTML and code? In-Reply-To: References: Message-ID: Hi Matthias, Thank you for your helpful and pointed replies, will try out the new json plugin. I see he gave a demo as part of Brian's NYC PyData talk which looks very promising. Cheers, Wen On Sat, Nov 24, 2012 at 6:10 AM, Matthias BUSSONNIER < bussonniermatthias at gmail.com> wrote: > > Le 24 nov. 2012 ? 04:04, W Gong a ?crit : > Hi, > > > Hi, > > I learned ipython notebook a few days ago and like it very much, > > To me, IPython Notebook is a new generation of web browser because it > brings exploration and interactivity to user. > > > > One question is how to add widget support (e.g. embed canvas, drawing > board, java applet). > > Depending on what you exactly want to do you might have different way of > doing it. > > The first thing you can do is use display protocol (see > docs/example/notebook/display_protocol.ipynb) to define html/latex/json > representation for object. > > other example > > http://nbviewer.ipython.org/urls/raw.github.com/ipython/ipython/master/docs/examples/notebooks/00_notebook_tour.ipynb > Near the end, you have a youtube video python object which representation > is an embedded youtube player. > > > To illustrate my use-case, here is a notebook that I created to teach > python to 10 yr old kids. To make it more interesting or engaging, I > combine rich text, image, video with code. In this example, I used HTML() > to embed a javascript clock at the beginning. But how would one do the same > in python? > > The other thing we are working on are json plugin > https://github.com/ipython/ipython/pull/2518 > > have a look at http://vimeo.com/channels/pydata/53051817 > for demo. > > > > > I have another use-case to embed java applet: > > Nobel Physicist - Carl Wieman at U of Colorado - Bolder has a wonderful > science education initiative called PhET which is to bring virtual lab to > science students. > > If teachers and students can perform virtual experiment, at the same > time, do calculations in math/physics via sympy and write a lab report, all > within the IPython notebook, it would be a huge boost to our education. > > You should be able to do the same and use a custom _repr_html_ to display > this form python. > > I think the introduction notebook in /docs/example/notebooks/ are a good > start to see what could be done. > > > also, you can share static version of your notebook through > nbviewer.ipython.org. > > here is what it looks for yours. > > http://nbviewer.ipython.org/url/dl.dropbox.com/u/54552252/what-is-time.ipynb > > -- > Matthias > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Thanks, - Wen -------------- next part -------------- An HTML attachment was scrubbed... URL: From sheila at codersquid.com Sun Nov 25 18:53:35 2012 From: sheila at codersquid.com (sheila miguez) Date: Sun, 25 Nov 2012 17:53:35 -0600 Subject: [IPython-dev] OSMagics configurable? Message-ID: Hi, I am new to ipython, and have some questions on how or whether one should configure options for osm commands. I had a conversation with Greg Wilson during pycon.ca sprints discussing worked examples. Somehow it turned in to a bit of ipython code that makes a backup copy of a file if it already exists so that new users don't clobber things when using %%file. I don't like changing an app's behavior on people like that, so I made backup only occur if a magic argument is passed to %%file. Greg rightly pointed out that people who are learning to program won't know to use that. I started looking through how config works. Perhaps OSMagics could become configurable, but if that was a good idea, someone would have done it already. Is it a highly inadvisable thing or just something that no one has needed yet? Another thing, I noticed that config has different profiles. Perhaps backup could be turned off by default, but there could exist a teaching profile that enables it. thanks -- sheila -------------- next part -------------- An HTML attachment was scrubbed... URL: From wen.g.gong at gmail.com Mon Nov 26 10:11:43 2012 From: wen.g.gong at gmail.com (W Gong) Date: Mon, 26 Nov 2012 10:11:43 -0500 Subject: [IPython-dev] improve http://nbviewer.ipython.org/ Message-ID: as a new user, I like to learn from examples or best practices: To support a similar request by another new user Dennis, can someone : 1) add "http://nbviewer.ipython.org/" to Help menu 2) make user submitted .ipynb visible at nbviewer.ipython.org Currently this website is like a blackhole, you know what you submitted by yourself, but you cannot see submission by others (except just 3 all the times) By the way, who owns and maintains nbviewer.ipython.org? Thanks, Wen On Sun, Nov 25, 2012 at 6:53 PM, sheila miguez wrote: > Hi, > > I am new to ipython, and have some questions on how or whether one should > configure options for osm commands. > > I had a conversation with Greg Wilson during pycon.ca sprints discussing > worked examples. Somehow it turned in to a bit of ipython code that makes a > backup copy of a file if it already exists so that new users don't clobber > things when using %%file. > > I don't like changing an app's behavior on people like that, so I made > backup only occur if a magic argument is passed to %%file. Greg rightly > pointed out that people who are learning to program won't know to use that. > > I started looking through how config works. Perhaps OSMagics could become > configurable, but if that was a good idea, someone would have done it > already. Is it a highly inadvisable thing or just something that no one has > needed yet? > > Another thing, I noticed that config has different profiles. Perhaps > backup could be turned off by default, but there could exist a teaching > profile that enables it. > > thanks > > > -- > sheila > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > -- Thanks, - Wen -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Mon Nov 26 10:16:07 2012 From: takowl at gmail.com (Thomas Kluyver) Date: Mon, 26 Nov 2012 15:16:07 +0000 Subject: [IPython-dev] improve http://nbviewer.ipython.org/ In-Reply-To: References: Message-ID: So everyone's aware, you can see the code and make pull requests for nbviewer in the normal way: https://github.com/ipython/nbviewer Thanks, Thomas On 26 November 2012 15:11, W Gong wrote: > as a new user, I like to learn from examples or best practices: > To support a similar request by another new user Dennis, > > can someone : > 1) add "http://nbviewer.ipython.org/" to Help menu > 2) make user submitted .ipynb visible at nbviewer.ipython.org > Currently this website is like a blackhole, you know what you submitted by > yourself, but you cannot see submission by others (except just 3 all the > times) > > By the way, who owns and maintains nbviewer.ipython.org? > > Thanks, > > Wen > > On Sun, Nov 25, 2012 at 6:53 PM, sheila miguez wrote: > >> Hi, >> >> I am new to ipython, and have some questions on how or whether one should >> configure options for osm commands. >> >> I had a conversation with Greg Wilson during pycon.ca sprints discussing >> worked examples. Somehow it turned in to a bit of ipython code that makes a >> backup copy of a file if it already exists so that new users don't clobber >> things when using %%file. >> >> I don't like changing an app's behavior on people like that, so I made >> backup only occur if a magic argument is passed to %%file. Greg rightly >> pointed out that people who are learning to program won't know to use that. >> >> I started looking through how config works. Perhaps OSMagics could become >> configurable, but if that was a good idea, someone would have done it >> already. Is it a highly inadvisable thing or just something that no one has >> needed yet? >> >> Another thing, I noticed that config has different profiles. Perhaps >> backup could be turned off by default, but there could exist a teaching >> profile that enables it. >> >> thanks >> >> >> -- >> sheila >> >> >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev >> >> > > > -- > > Thanks, > > - Wen > > > > > > _______________________________________________ > 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 Nov 26 12:41:10 2012 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Mon, 26 Nov 2012 18:41:10 +0100 Subject: [IPython-dev] improve http://nbviewer.ipython.org/ In-Reply-To: References: Message-ID: Le 26 nov. 2012 ? 16:11, W Gong a ?crit : > as a new user, I like to learn from examples or best practices: > To support a similar request by another new user Dennis, > > can someone : > 1) add "http://nbviewer.ipython.org/" to Help menu > 2) make user submitted .ipynb visible at nbviewer.ipython.org > Currently this website is like a blackhole, you know what you submitted by yourself, but you cannot see submission by others (except just 3 all the times) > > By the way, who owns and maintains nbviewer.ipython.org? Nbviewer is hosted on heroku, all dev should have the ability to push, Fernando (and Brian ?) own the python.org domain name, I am the one mainly push ing the updates on heroku. > Currently this website is like a blackhole, you know what you submitted by yourself, but you cannot see submission by others (except just 3 all the times) I tried to put a top 10 notebooks, but the free postgressql plan was filled up in 2 weeks, so I had to disable it. I'm working on having auto-screenshot on the notebook on nbviewer to make a mosaic of popular notebook. > 2) make user submitted .ipynb visible at nbviewer.ipython.org This would make sense once we have a "publish to nbviewer" button in the notebook. But in the nbviewer way, it does not make sense, nbviewer does not retain anything , the field to past a URL is a pure convenience. You could generate the nbviewer link even if the file is not on the internet yet. Nbviewer fetch and render the link "live" when you open it. Actually that what the bookmarklet and chrome extension does. As Thomas point out, the repo is on github, but it is not up to date. The reason is that nbviewer ships with a modified version of nbconvert, which is a pain to maintain in parallel. So as long as nbviewer does not integrate nbconvert as is, I would prefer it not to be hacked or modified and focus the effort on nbconvert. We'll still welcome pull request, but it often mean manual backporting. And I really need more time to document how to deploy on heroku or other. -- Matthias > > Thanks, > > Wen > > On Sun, Nov 25, 2012 at 6:53 PM, sheila miguez wrote: > Hi, > > I am new to ipython, and have some questions on how or whether one should configure options for osm commands. > > I had a conversation with Greg Wilson during pycon.ca sprints discussing worked examples. Somehow it turned in to a bit of ipython code that makes a backup copy of a file if it already exists so that new users don't clobber things when using %%file. > > I don't like changing an app's behavior on people like that, so I made backup only occur if a magic argument is passed to %%file. Greg rightly pointed out that people who are learning to program won't know to use that. > > I started looking through how config works. Perhaps OSMagics could become configurable, but if that was a good idea, someone would have done it already. Is it a highly inadvisable thing or just something that no one has needed yet? > > Another thing, I noticed that config has different profiles. Perhaps backup could be turned off by default, but there could exist a teaching profile that enables it. > > thanks > > > -- > sheila > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > > > > -- > > Thanks, > > - Wen > > > > > _______________________________________________ > 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 Mon Nov 26 12:56:18 2012 From: carl.input at gmail.com (Carl Smith) Date: Mon, 26 Nov 2012 17:56:18 +0000 Subject: [IPython-dev] improve http://nbviewer.ipython.org/ In-Reply-To: References: Message-ID: Matthias, just an aside: nbconvert puts ugly red borders round certain chars in code cells. I've not had a chance to look at this properly, but dropping the following CSS at the bottom of the head seems to fix things for now. .highlight .err { border: none; } I also added `color: red;` to this rule to add some highlighting, but this is just a cheap and inconsistent fix until I can look at it. Should be a five minute job, but I've not got round to it. From bussonniermatthias at gmail.com Mon Nov 26 13:27:41 2012 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Mon, 26 Nov 2012 19:27:41 +0100 Subject: [IPython-dev] improve http://nbviewer.ipython.org/ In-Reply-To: References: Message-ID: <05E43076-B76E-488A-82D0-CD6792137A9B@gmail.com> Le 26 nov. 2012 ? 18:56, Carl Smith a ?crit : > Matthias, just an aside: nbconvert puts ugly red borders round certain > chars in code cells. I've not had a chance to look at this properly, > but dropping the following CSS at the bottom of the head seems to fix > things for now. > > .highlight .err { border: none; } > > I also added `color: red;` to this rule to add some highlighting, but > this is just a cheap and inconsistent fix until I can look at it. > Should be a five minute job, but I've not got round to it. I guess those are the things that should be corrected on nbconvert, and that will be fixed when nbconvert becomes a dependencies of nbviewer. I'll try to have a look. -- Matthias > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From carl.input at gmail.com Mon Nov 26 14:35:56 2012 From: carl.input at gmail.com (Carl Smith) Date: Mon, 26 Nov 2012 19:35:56 +0000 Subject: [IPython-dev] improve http://nbviewer.ipython.org/ In-Reply-To: <05E43076-B76E-488A-82D0-CD6792137A9B@gmail.com> References: <05E43076-B76E-488A-82D0-CD6792137A9B@gmail.com> Message-ID: No worries. It is an nbconvert issue. I'll do it tonight. It it'll be an easy thing to start with. I've been meaning to make a few easy PRs to IPython to learn the process. Have you figured out how to syntax highlight code examples in md cells yet? I was going to look at that too. -------------- next part -------------- An HTML attachment was scrubbed... URL: From taavi.burns at gmail.com Tue Nov 27 14:49:18 2012 From: taavi.burns at gmail.com (Taavi Burns) Date: Tue, 27 Nov 2012 14:49:18 -0500 Subject: [IPython-dev] IPython nosetests extension Message-ID: https://github.com/taavi/ipython_nose I've gotten the %nose magic Greg Ward and I worked on at the PyCon Canada sprints to a reasonable point. I'm not yet convinced that it's ready for integration into IPython (I think I'd like to get IPython to add id attributes on the cells so I don't have to add them myself with JS), but it should be good enough for some real-world testing. It's pip-installable in development mode: . YOUR/VIRTUALENV/activate git clone https://github.com/taavi/ipython_nose.git cd ipython_nose pip install -e . I might not bother putting it on PyPI if it's as likely to get included in the base IPython as Fernando was suggesting. ;) I'd appreciate any feedback on features and bugs. Feel free to lodge them in the github tracker. Pull requests are also welcome! Please keep in mind that the end goal is to integrate it into IPython proper, so some work might be deferred until then. Thanks! -- taa /*eof*/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Tue Nov 27 15:10:44 2012 From: ellisonbg at gmail.com (Brian Granger) Date: Tue, 27 Nov 2012 12:10:44 -0800 Subject: [IPython-dev] IPython nosetests extension In-Reply-To: References: Message-ID: Hi, this is really exciting and will be a huge improvement for using the notebook for real work. I will try to look a bit more at this over the next week (in the middle of finals right now). But a few comments: * Why exactly do you need cell ids? * We are soon going to completely remove the ability to publish javascript from Python. There are two many horrific security problems. The replacement abstraction is "javascript plugins" that are under review here: https://github.com/ipython/ipython/pull/2518 There is more work to do on this, but this will give you an idea of where we are headed. Please ask questions about the plugins on that PR. Cheers, Brian On Tue, Nov 27, 2012 at 11:49 AM, Taavi Burns wrote: > https://github.com/taavi/ipython_nose > > I've gotten the %nose magic Greg Ward and I worked on at the PyCon Canada > sprints to a reasonable point. I'm not yet convinced that it's ready for > integration into IPython (I think I'd like to get IPython to add id > attributes on the cells so I don't have to add them myself with JS), but it > should be good enough for some real-world testing. > > It's pip-installable in development mode: > . YOUR/VIRTUALENV/activate > git clone https://github.com/taavi/ipython_nose.git > cd ipython_nose > pip install -e . > > I might not bother putting it on PyPI if it's as likely to get included in > the base IPython as Fernando was suggesting. ;) > > I'd appreciate any feedback on features and bugs. Feel free to lodge them in > the github tracker. Pull requests are also welcome! Please keep in mind that > the end goal is to integrate it into IPython proper, so some work might be > deferred until then. > > Thanks! > > -- > taa > /*eof*/ > > _______________________________________________ > 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 Tue Nov 27 22:35:24 2012 From: ellisonbg at gmail.com (Brian Granger) Date: Tue, 27 Nov 2012 19:35:24 -0800 Subject: [IPython-dev] Enhancement proposal for kernel messaging protocol In-Reply-To: References: Message-ID: > I wrote a PR for adding new option to messaging protocol [1]_. > Bussonnier Matthias and Thomas Kluyver suggested to discuss about > possible extensions for current messaging protocol, and then make an > IPEP before working on these extensions. So, let me start the > discussion here. Great, thanks for getting this started. > > 1. Protocol introspection. > > Currently, messaging protocol has no introspection mechanism. It is > not a problem when the messaging protocol is used only for internal > communication. However, there are various software using IPython via > messaging protocol. Also, IPython version of the kernel and client > can be different, for example when used over ssh connection. > Therefore, we need some introspection mechanism to inform messaging > protocol supported by connecting kernel. I agree with this assessment. > One way to inform supported messaging protocol is to add version > number to the messaging protocol. There are several options for > version numbering: > > a. Protocol version = IPython version. > > This may be the simplest way to do it. But in development version, > supported protocol will be unclear. The problem with this is that the message protocol is quite stable over the ipython versions. This is why the notebook format has its own version numbers. > b. Semantic Versioning [2]_. > > This is some what close to how notebook version works (right?). > Simple explanation: It takes the form of `x.y.z`. Patch version > `z` is incremented for bug fix. Minor version `y` is incremented > for backward compatible changes. Major version `x` is incremented > for backwards incompatible changes. > > For the messaging protocol, the next version number will be 1.1.0 > if we think the current protocol is public. It will be 0.2.0 if we > think the current protocol is still in development. > > There are several ways to let client know the version number. I would use the exact same convention that we do in the notebook format. X.Y: X = major versions, incompatible Y = minor versions, compatible > c. Add `version_request` / `version_reply` messaging protocol. Yes, this is what I would prefer. > d. Add `version` slot to the message format. It can be in > the top level, `header` or `metadata`. > e. Send version number during "hand shake" (but there is no > such stage for the current messaging protocol, I suppose?). > > > 2. New optional `unique` key to `history_request`. > > I propose [1]_ to add this new boolean key `unique` to > `history_request` [3]_. When this key is specified and true, > `history_reply` contains only entries of unique input. This is useful > for searching history using `hist_access_type: 'search'`. This > operation can be done in client side. However, sending large number > of entries over messaging protocol is time consuming. One case this > `unique` key can be critical is when using `history_request` in an > interactive UI to search IPython history in as-you-type manner > ("QuickSilver style"; for example, my Emacs client EIN [4]_ has such > UI). For such kind of UI speed is critical and it is preferred to be > done in the kernel side. > > (As you can see, this is the reason why I made the PR in the first > place!) Yes, I can see that this would be a good thing to have. > > 3. Messaging protocol to pass structured data to kernel. > > Currently it is not possible to pass structured data such as dict from > client to kernel. You can generate Python code and use > `execute_request`, but it is difficult to do this properly in > non-Python client such as Javascript client. Note that it is > already possible to pass structured data to client from kernel > by using JSON repr. > > (I think I saw some argument related to this issue tracker, but > I can't find it now. Please post the link if you know.) > > There are several ways to solve this problem: > > a. Add RPC-like message `call_request` / `call_reply`. Client can > execute a short code to register "methods" in kernel to use this > RPC. For example `__import__('mylib.ipyutils').register()`. > > b. Add `override_variables` slot to `execute_request`. This slot > takes a dict and the value in the dict will override the value > correspond to its key. For example, client can execute `func(x)` > with `override_variables: {'x': 1}`. > > The problem is that it contaminates user's namespace. To solve this > problem, we can add another `namespace` slot to `execute_request`. > This way, client can import its supporting library without > contaminating user's namespace and execute its functions using > `override_variables`. For example, client can issue `execute_request` > like this:: > > {'code' "import mylib; mylib.ipyutils.func(x)", > 'namespace': 'mylib', > 'override_variables': {'x': 1}} > > Merit of this approach comparing to the other one (`call_request`) > is that `namespace` can be used for another purpose. For example, > notebook client can have separated namespace for each worksheet, > to avoid namespace collision. Sharing data between namespaces can > be easily done by using singleton object. Other possible application > is editor integration. For example, you have associate one namespace > to each file (= python module) opened in the editor. Even though we will eventually need this, I don't think we are ready to tackle it yet. This will happen as part of the work on interactive widgets that will hopefully get started in Jan. But, for the first two of these enhancements, I think they sound great and don't need an IPEP. A separate PR for each would be great :) Cheers, Brian > .. [1] https://github.com/ipython/ipython/pull/2609 > .. [2] http://semver.org/ > .. [3] http://ipython.org/ipython-doc/dev/development/messaging.html#history > .. [4] http://github.com/tkf/emacs-ipython-notebook > > --- > Takafumi Arakaki > _______________________________________________ > 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 rmcgibbo at gmail.com Thu Nov 29 02:58:14 2012 From: rmcgibbo at gmail.com (Robert McGibbon) Date: Wed, 28 Nov 2012 23:58:14 -0800 Subject: [IPython-dev] Function specific hooks into the ipython tab completion system Message-ID: <96A177C3-9E59-44BD-8268-52F802E12C37@gmail.com> Hey, Tab completion in IPython is one of the things that makes it so useful, especially the context specific tab completion for things like "from ..." where only packages, or obviously the special completion for attributes when the line contains a dot. I use IPython for interactive data analysis a lot, and one of the most frequent operations is loading up data with something like numpy.loadtxt() or various related functions. It would be really awesome if we could annotate functions to interact with the tab completion system, perhaps for instance saying that argument 0 to numpy.loadtxt() is supposed to be a filename, so let's give tab-complete suggestions that try to look for directories/files. Some functions only files with specific extensions, so you could filter based on that or whatever. By hacking on the code for completerlib.py:cd_completer, I sketched out a little demo of what you could do with this: https://gist.github.com/4167151. The architecture is totally wrong, but it lets you get behavior like: ``` In [1]: ls datfile.dat dir1/ dir2/ file.gz random_junk test.py In [2]: directory_as_a_variable = 'sdfsfsd' In [3]: f = np.loadtxt( datfile.dat dir1/ dir2/ file.gz In [4]: normal_function( Display all 330 possibilities? (y or n) In [5]: g = np.loadtxt(di dict dir1/ directory_as_a_variable divmod dir dir2/ directory_of_my_choosing ``` Basically hitting the tab completion, when np.loadtxt is on the input line, only shows directories and files that end with a certain extension. If you start to type in the name of an object in your namespace, it'll show up too, but only once you've typed in more than 1 matching character. The implementation in my gist is pretty lame. The way I've coded it up, the special behavior is based on simply finding the string "np.loadtxt" on the input line, not on the actual function. This means you can't really make the behavior specific to your position in the argument list (i.e. I know that the first arg is a filename, and so should be tab completed like this, but the other ones are not). I suspect the right way to do the implementation is via function decorators to specify the behavior and then adding to IPCompleter instead. I think I'm up for giving this a shot. Thoughts? Is this a feature anyone else would find interesting? -Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From asmeurer at gmail.com Thu Nov 29 04:27:44 2012 From: asmeurer at gmail.com (Aaron Meurer) Date: Thu, 29 Nov 2012 02:27:44 -0700 Subject: [IPython-dev] Function specific hooks into the ipython tab completion system In-Reply-To: <96A177C3-9E59-44BD-8268-52F802E12C37@gmail.com> References: <96A177C3-9E59-44BD-8268-52F802E12C37@gmail.com> Message-ID: I've often thought this as well. Probably a full-blown IPEP is in order here. Perhaps __annotations__ would be the correct way to go here. Aaron Meurer On Thu, Nov 29, 2012 at 12:58 AM, Robert McGibbon wrote: > Hey, > > Tab completion in IPython is one of the things that makes it so useful, > especially the context specific tab completion for things like "from ..." > where only packages, or obviously the special completion for attributes when > the line contains a dot. > > I use IPython for interactive data analysis a lot, and one of the most > frequent operations is loading up data with something like numpy.loadtxt() > or various related functions. > > It would be really awesome if we could annotate functions to interact with > the tab completion system, perhaps for instance saying that argument 0 to > numpy.loadtxt() is supposed to be a filename, so let's give tab-complete > suggestions that try to look for directories/files. Some functions only > files with specific extensions, so you could filter based on that or > whatever. > > By hacking on the code for completerlib.py:cd_completer, I sketched out a > little demo of what you could do with this: https://gist.github.com/4167151. > The architecture is totally wrong, but it lets you get behavior like: > > ``` > In [1]: ls > datfile.dat dir1/ dir2/ file.gz random_junk test.py > > In [2]: directory_as_a_variable = 'sdfsfsd' > > In [3]: f = np.loadtxt( > datfile.dat dir1/ dir2/ file.gz > > In [4]: normal_function( > Display all 330 possibilities? (y or n) > > In [5]: g = np.loadtxt(di > dict dir1/ directory_as_a_variable > divmod > dir dir2/ directory_of_my_choosing > ``` > > Basically hitting the tab completion, when np.loadtxt is on the input line, > only shows directories and files that end with a certain extension. If you > start to type in the name of an object in your namespace, it'll show up too, > but only once you've typed in more than 1 matching character. > > The implementation in my gist is pretty lame. The way I've coded it up, the > special behavior is based on simply finding the string "np.loadtxt" on the > input line, not on the actual function. This means you can't really make the > behavior specific to your position in the argument list (i.e. I know that > the first arg is a filename, and so should be tab completed like this, but > the other ones are not). I suspect the right way to do the implementation is > via function decorators to specify the behavior and then adding to > IPCompleter instead. > > I think I'm up for giving this a shot. > > Thoughts? Is this a feature anyone else would find interesting? > > -Robert > > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > From bussonniermatthias at gmail.com Thu Nov 29 05:02:31 2012 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Thu, 29 Nov 2012 11:02:31 +0100 Subject: [IPython-dev] Function specific hooks into the ipython tab completion system In-Reply-To: References: <96A177C3-9E59-44BD-8268-52F802E12C37@gmail.com> Message-ID: <357B7D49-C7B4-413A-A530-AA8F63EA79BF@gmail.com> Hi, I may be wrong, but IIRC you can insert your own completer in the IPython completer chain and decide to filter the previous completion. You should be able to have a custom completer that just forward the previous completion in most cases, And just do a dir completion if the object is np.loadtxt in your case (or look at __annotations__ if you wish). I've found one reference to inserting custom completer here http://ipython.org/ipython-doc/dev/api/generated/IPython.core.interactiveshell.html?highlight=interactiveshell#IPython.core.interactiveshell.InteractiveShell.set_custom_completer -- Matthias Le 29 nov. 2012 ? 10:27, Aaron Meurer a ?crit : > I've often thought this as well. Probably a full-blown IPEP is in > order here. Perhaps __annotations__ would be the correct way to go > here. > > Aaron Meurer > > On Thu, Nov 29, 2012 at 12:58 AM, Robert McGibbon wrote: >> Hey, >> >> Tab completion in IPython is one of the things that makes it so useful, >> especially the context specific tab completion for things like "from ..." >> where only packages, or obviously the special completion for attributes when >> the line contains a dot. >> >> I use IPython for interactive data analysis a lot, and one of the most >> frequent operations is loading up data with something like numpy.loadtxt() >> or various related functions. >> >> It would be really awesome if we could annotate functions to interact with >> the tab completion system, perhaps for instance saying that argument 0 to >> numpy.loadtxt() is supposed to be a filename, so let's give tab-complete >> suggestions that try to look for directories/files. Some functions only >> files with specific extensions, so you could filter based on that or >> whatever. >> >> By hacking on the code for completerlib.py:cd_completer, I sketched out a >> little demo of what you could do with this: https://gist.github.com/4167151. >> The architecture is totally wrong, but it lets you get behavior like: >> >> ``` >> In [1]: ls >> datfile.dat dir1/ dir2/ file.gz random_junk test.py >> >> In [2]: directory_as_a_variable = 'sdfsfsd' >> >> In [3]: f = np.loadtxt( >> datfile.dat dir1/ dir2/ file.gz >> >> In [4]: normal_function( >> Display all 330 possibilities? (y or n) >> >> In [5]: g = np.loadtxt(di >> dict dir1/ directory_as_a_variable >> divmod >> dir dir2/ directory_of_my_choosing >> ``` >> >> Basically hitting the tab completion, when np.loadtxt is on the input line, >> only shows directories and files that end with a certain extension. If you >> start to type in the name of an object in your namespace, it'll show up too, >> but only once you've typed in more than 1 matching character. >> >> The implementation in my gist is pretty lame. The way I've coded it up, the >> special behavior is based on simply finding the string "np.loadtxt" on the >> input line, not on the actual function. This means you can't really make the >> behavior specific to your position in the argument list (i.e. I know that >> the first arg is a filename, and so should be tab completed like this, but >> the other ones are not). I suspect the right way to do the implementation is >> via function decorators to specify the behavior and then adding to >> IPCompleter instead. >> >> I think I'm up for giving this a shot. >> >> Thoughts? Is this a feature anyone else would find interesting? >> >> -Robert >> >> >> >> _______________________________________________ >> 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 rmcgibbo at gmail.com Thu Nov 29 05:28:41 2012 From: rmcgibbo at gmail.com (Robert McGibbon) Date: Thu, 29 Nov 2012 02:28:41 -0800 Subject: [IPython-dev] Function specific hooks into the ipython tab completion system In-Reply-To: <357B7D49-C7B4-413A-A530-AA8F63EA79BF@gmail.com> References: <96A177C3-9E59-44BD-8268-52F802E12C37@gmail.com> <357B7D49-C7B4-413A-A530-AA8F63EA79BF@gmail.com> Message-ID: <669615BA-66DA-4CA6-8848-ED64BC4E3710@gmail.com> Hi, Good spot, Matthias. I didn't see that method was already exposed -- I was just looking at IPCompleter.matchers, which what that method inserts into. Annotations are cool, but they're not obviously composable. I worry that if I use them for this and then fix one syntax of how the annotation is parsed, and somebody else is using annotations in their lib for something else, the two schemes won't be able to interoperate. Also they're py3k only. My preferred syntax would be from tablib import tabcompletion, filename, @tabcompletion(fname=filename, mode=['r', 'w']) def load(fname, mode, other_argument): pass or maybe with a parameterized filename to get specific extensions @tabcompletion(fname=filename('.txt')) def f(fname, other_argument): pass Is this something that other people would be interested in? -Robert On Nov 29, 2012, at 2:02 AM, Matthias BUSSONNIER wrote: > Hi, > > I may be wrong, but IIRC you can insert your own completer in the IPython completer chain and decide to filter the previous completion. > > You should be able to have a custom completer that just forward the previous completion in most cases, > And just do a dir completion if the object is np.loadtxt in your case (or look at __annotations__ if you wish). > > I've found one reference to inserting custom completer here > http://ipython.org/ipython-doc/dev/api/generated/IPython.core.interactiveshell.html?highlight=interactiveshell#IPython.core.interactiveshell.InteractiveShell.set_custom_completer > > > -- > Matthias > > Le 29 nov. 2012 ? 10:27, Aaron Meurer a ?crit : > >> I've often thought this as well. Probably a full-blown IPEP is in >> order here. Perhaps __annotations__ would be the correct way to go >> here. >> >> Aaron Meurer >> >> On Thu, Nov 29, 2012 at 12:58 AM, Robert McGibbon wrote: >>> Hey, >>> >>> Tab completion in IPython is one of the things that makes it so useful, >>> especially the context specific tab completion for things like "from ..." >>> where only packages, or obviously the special completion for attributes when >>> the line contains a dot. >>> >>> I use IPython for interactive data analysis a lot, and one of the most >>> frequent operations is loading up data with something like numpy.loadtxt() >>> or various related functions. >>> >>> It would be really awesome if we could annotate functions to interact with >>> the tab completion system, perhaps for instance saying that argument 0 to >>> numpy.loadtxt() is supposed to be a filename, so let's give tab-complete >>> suggestions that try to look for directories/files. Some functions only >>> files with specific extensions, so you could filter based on that or >>> whatever. >>> >>> By hacking on the code for completerlib.py:cd_completer, I sketched out a >>> little demo of what you could do with this: https://gist.github.com/4167151. >>> The architecture is totally wrong, but it lets you get behavior like: >>> >>> ``` >>> In [1]: ls >>> datfile.dat dir1/ dir2/ file.gz random_junk test.py >>> >>> In [2]: directory_as_a_variable = 'sdfsfsd' >>> >>> In [3]: f = np.loadtxt( >>> datfile.dat dir1/ dir2/ file.gz >>> >>> In [4]: normal_function( >>> Display all 330 possibilities? (y or n) >>> >>> In [5]: g = np.loadtxt(di >>> dict dir1/ directory_as_a_variable >>> divmod >>> dir dir2/ directory_of_my_choosing >>> ``` >>> >>> Basically hitting the tab completion, when np.loadtxt is on the input line, >>> only shows directories and files that end with a certain extension. If you >>> start to type in the name of an object in your namespace, it'll show up too, >>> but only once you've typed in more than 1 matching character. >>> >>> The implementation in my gist is pretty lame. The way I've coded it up, the >>> special behavior is based on simply finding the string "np.loadtxt" on the >>> input line, not on the actual function. This means you can't really make the >>> behavior specific to your position in the argument list (i.e. I know that >>> the first arg is a filename, and so should be tab completed like this, but >>> the other ones are not). I suspect the right way to do the implementation is >>> via function decorators to specify the behavior and then adding to >>> IPCompleter instead. >>> >>> I think I'm up for giving this a shot. >>> >>> Thoughts? Is this a feature anyone else would find interesting? >>> >>> -Robert >>> >>> >>> >>> _______________________________________________ >>> 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 tdimiduk at physics.harvard.edu Thu Nov 29 09:38:13 2012 From: tdimiduk at physics.harvard.edu (Tom Dimiduk) Date: Thu, 29 Nov 2012 09:38:13 -0500 Subject: [IPython-dev] Function specific hooks into the ipython tab completion system In-Reply-To: <669615BA-66DA-4CA6-8848-ED64BC4E3710@gmail.com> References: <96A177C3-9E59-44BD-8268-52F802E12C37@gmail.com> <357B7D49-C7B4-413A-A530-AA8F63EA79BF@gmail.com> <669615BA-66DA-4CA6-8848-ED64BC4E3710@gmail.com> Message-ID: <50B77355.8050404@physics.harvard.edu> That looks pretty great. I would use something like that. For the filename('.txt'), it could be handy to be able to pass arbitrary globs (as in for glob.glob). You could still default to matching against the end of the string for extensions, but adding the glob support costs little (since you probably want to use glob internally anyway. For extra (and unnecessary) fancyness, I could also see use cases for from from tablib import tabcompletion, instance class bar: pass @tabcompletion(foo=instance(bar)) to be able to only complete for specific types of objects for other parameters (it would do an isinstance test). Even more bonus points if the decorator could parse numpy styled docstrings to grab that kind of information about parameters. I guess at this point you could do type checking, file existence checking, and a variety of other fun stuff there as well once you have that information, but that is almost certainly going out of the scope of your proposal. Sorry if I am growing your proposal too much, the basic thing you proposed would still be very useful. If I can grab some spare mental cycles, I would collaborate with you on it if you end up writing it. Tom On 11/29/2012 05:28 AM, Robert McGibbon wrote: > Hi, > > Good spot, Matthias. I didn't see that method was already exposed -- I > was just looking at IPCompleter.matchers, which what that method > inserts into. > > Annotations are cool, but they're not obviously composable. I worry > that if I use them for this and then fix one syntax of how the > annotation is parsed, and somebody else > is using annotations in their lib for something else, the two schemes > won't be able to interoperate. Also they're py3k only. > > My preferred syntax would be > > from tablib import tabcompletion, filename, > > @tabcompletion(fname=filename, mode=['r', 'w']) > def load(fname, mode, other_argument): > pass > > or maybe with a parameterized filename to get specific extensions > > @tabcompletion(fname=filename('.txt')) > def f(fname, other_argument): > pass > > Is this something that other people would be interested in? > > -Robert > > On Nov 29, 2012, at 2:02 AM, Matthias BUSSONNIER wrote: > >> Hi, >> >> I may be wrong, but IIRC you can insert your own completer in the >> IPython completer chain and decide to filter the previous completion. >> >> You should be able to have a custom completer that just forward the >> previous completion in most cases, >> And just do a dir completion if the object is np.loadtxt in your case >> (or look at __annotations__ if you wish). >> >> I've found one reference to inserting custom completer here >> http://ipython.org/ipython-doc/dev/api/generated/IPython.core.interactiveshell.html?highlight=interactiveshell#IPython.core.interactiveshell.InteractiveShell.set_custom_completer >> >> >> -- >> Matthias >> >> Le 29 nov. 2012 ? 10:27, Aaron Meurer a ?crit : >> >>> I've often thought this as well. Probably a full-blown IPEP is in >>> order here. Perhaps __annotations__ would be the correct way to go >>> here. >>> >>> Aaron Meurer >>> >>> On Thu, Nov 29, 2012 at 12:58 AM, Robert McGibbon >>> > wrote: >>>> Hey, >>>> >>>> Tab completion in IPython is one of the things that makes it so useful, >>>> especially the context specific tab completion for things like >>>> "from ..." >>>> where only packages, or obviously the special completion for >>>> attributes when >>>> the line contains a dot. >>>> >>>> I use IPython for interactive data analysis a lot, and one of the most >>>> frequent operations is loading up data with something like >>>> numpy.loadtxt() >>>> or various related functions. >>>> >>>> It would be really awesome if we could annotate functions to >>>> interact with >>>> the tab completion system, perhaps for instance saying that >>>> argument 0 to >>>> numpy.loadtxt() is supposed to be a filename, so let's give >>>> tab-complete >>>> suggestions that try to look for directories/files. Some functions only >>>> files with specific extensions, so you could filter based on that or >>>> whatever. >>>> >>>> By hacking on the code for completerlib.py:cd_completer, I sketched >>>> out a >>>> little demo of what you could do with this: >>>> https://gist.github.com/4167151. >>>> The architecture is totally wrong, but it lets you get behavior like: >>>> >>>> ``` >>>> In [1]: ls >>>> datfile.dat dir1/ dir2/ file.gz random_junk >>>> test.py >>>> >>>> In [2]: directory_as_a_variable = 'sdfsfsd' >>>> >>>> In [3]: f = np.loadtxt( >>>> datfile.dat dir1/ dir2/ file.gz >>>> >>>> In [4]: normal_function( >>>> Display all 330 possibilities? (y or n) >>>> >>>> In [5]: g = np.loadtxt(di >>>> dict dir1/ >>>> directory_as_a_variable >>>> divmod >>>> dir dir2/ >>>> directory_of_my_choosing >>>> ``` >>>> >>>> Basically hitting the tab completion, when np.loadtxt is on the >>>> input line, >>>> only shows directories and files that end with a certain extension. >>>> If you >>>> start to type in the name of an object in your namespace, it'll >>>> show up too, >>>> but only once you've typed in more than 1 matching character. >>>> >>>> The implementation in my gist is pretty lame. The way I've coded it >>>> up, the >>>> special behavior is based on simply finding the string "np.loadtxt" >>>> on the >>>> input line, not on the actual function. This means you can't really >>>> make the >>>> behavior specific to your position in the argument list (i.e. I >>>> know that >>>> the first arg is a filename, and so should be tab completed like >>>> this, but >>>> the other ones are not). I suspect the right way to do the >>>> implementation is >>>> via function decorators to specify the behavior and then adding to >>>> IPCompleter instead. >>>> >>>> I think I'm up for giving this a shot. >>>> >>>> Thoughts? Is this a feature anyone else would find interesting? >>>> >>>> -Robert >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 > > > > _______________________________________________ > 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 Thu Nov 29 10:18:55 2012 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Thu, 29 Nov 2012 16:18:55 +0100 Subject: [IPython-dev] Function specific hooks into the ipython tab completion system In-Reply-To: <50B77355.8050404@physics.harvard.edu> References: <96A177C3-9E59-44BD-8268-52F802E12C37@gmail.com> <357B7D49-C7B4-413A-A530-AA8F63EA79BF@gmail.com> <669615BA-66DA-4CA6-8848-ED64BC4E3710@gmail.com> <50B77355.8050404@physics.harvard.edu> Message-ID: > Even more bonus points if the decorator could parse numpy styled docstrings to grab that kind of information about parameters. I guess at this point you could do type checking, file existence checking, and a variety of other fun stuff there as well once you have that information, but that is almost certainly going out of the scope of your proposal. This might be a starting point. func_kw_complete for builtin and cython with embededsignature=True using docstring https://github.com/ipython/ipython/pull/2599 -- Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From asmeurer at gmail.com Thu Nov 29 14:08:28 2012 From: asmeurer at gmail.com (Aaron Meurer) Date: Thu, 29 Nov 2012 12:08:28 -0700 Subject: [IPython-dev] Function specific hooks into the ipython tab completion system In-Reply-To: <669615BA-66DA-4CA6-8848-ED64BC4E3710@gmail.com> References: <96A177C3-9E59-44BD-8268-52F802E12C37@gmail.com> <357B7D49-C7B4-413A-A530-AA8F63EA79BF@gmail.com> <669615BA-66DA-4CA6-8848-ED64BC4E3710@gmail.com> Message-ID: <2629562003809302943@unknownmsgid> On Nov 29, 2012, at 3:28 AM, Robert McGibbon wrote: Hi, Good spot, Matthias. I didn't see that method was already exposed -- I was just looking at IPCompleter.matchers, which what that method inserts into. Annotations are cool, but they're not obviously composable. I worry that if I use them for this and then fix one syntax of how the annotation is parsed, and somebody else is using annotations in their lib for something else, the two schemes won't be able to interoperate. Also they're py3k only. Annotations syntax is python 3 only, but other than that, anyone can modify an object's __annotations__ dict. Also, note that annotations don't have to be strings. They can be arbitrary objects. So what I would do is create completer template objects (e.g., there would be a FileCompleter for your example), and annotate with those. To compose, just make these objects in such a way that they are easily composable (or just annotate with a list of such objects, and append to the list of you want to add more). Aaron Meurer My preferred syntax would be from tablib import tabcompletion, filename, @tabcompletion(fname=filename, mode=['r', 'w']) def load(fname, mode, other_argument): pass or maybe with a parameterized filename to get specific extensions @tabcompletion(fname=filename('.txt')) def f(fname, other_argument): pass Is this something that other people would be interested in? -Robert On Nov 29, 2012, at 2:02 AM, Matthias BUSSONNIER wrote: Hi, I may be wrong, but IIRC you can insert your own completer in the IPython completer chain and decide to filter the previous completion. You should be able to have a custom completer that just forward the previous completion in most cases, And just do a dir completion if the object is np.loadtxt in your case (or look at __annotations__ if you wish). I've found one reference to inserting custom completer here http://ipython.org/ipython-doc/dev/api/generated/IPython.core.interactiveshell.html?highlight=interactiveshell#IPython.core.interactiveshell.InteractiveShell.set_custom_completer -- Matthias Le 29 nov. 2012 ? 10:27, Aaron Meurer a ?crit : I've often thought this as well. Probably a full-blown IPEP is in order here. Perhaps __annotations__ would be the correct way to go here. Aaron Meurer On Thu, Nov 29, 2012 at 12:58 AM, Robert McGibbon wrote: Hey, Tab completion in IPython is one of the things that makes it so useful, especially the context specific tab completion for things like "from ..." where only packages, or obviously the special completion for attributes when the line contains a dot. I use IPython for interactive data analysis a lot, and one of the most frequent operations is loading up data with something like numpy.loadtxt() or various related functions. It would be really awesome if we could annotate functions to interact with the tab completion system, perhaps for instance saying that argument 0 to numpy.loadtxt() is supposed to be a filename, so let's give tab-complete suggestions that try to look for directories/files. Some functions only files with specific extensions, so you could filter based on that or whatever. By hacking on the code for completerlib.py:cd_completer, I sketched out a little demo of what you could do with this: https://gist.github.com/4167151. The architecture is totally wrong, but it lets you get behavior like: ``` In [1]: ls datfile.dat dir1/ dir2/ file.gz random_junk test.py In [2]: directory_as_a_variable = 'sdfsfsd' In [3]: f = np.loadtxt( datfile.dat dir1/ dir2/ file.gz In [4]: normal_function( Display all 330 possibilities? (y or n) In [5]: g = np.loadtxt(di dict dir1/ directory_as_a_variable divmod dir dir2/ directory_of_my_choosing ``` Basically hitting the tab completion, when np.loadtxt is on the input line, only shows directories and files that end with a certain extension. If you start to type in the name of an object in your namespace, it'll show up too, but only once you've typed in more than 1 matching character. The implementation in my gist is pretty lame. The way I've coded it up, the special behavior is based on simply finding the string "np.loadtxt" on the input line, not on the actual function. This means you can't really make the behavior specific to your position in the argument list (i.e. I know that the first arg is a filename, and so should be tab completed like this, but the other ones are not). I suspect the right way to do the implementation is via function decorators to specify the behavior and then adding to IPCompleter instead. I think I'm up for giving this a shot. Thoughts? Is this a feature anyone else would find interesting? -Robert _______________________________________________ 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 _______________________________________________ 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 asmeurer at gmail.com Thu Nov 29 14:16:24 2012 From: asmeurer at gmail.com (Aaron Meurer) Date: Thu, 29 Nov 2012 12:16:24 -0700 Subject: [IPython-dev] Function specific hooks into the ipython tab completion system In-Reply-To: <2629562003809302943@unknownmsgid> References: <96A177C3-9E59-44BD-8268-52F802E12C37@gmail.com> <357B7D49-C7B4-413A-A530-AA8F63EA79BF@gmail.com> <669615BA-66DA-4CA6-8848-ED64BC4E3710@gmail.com> <2629562003809302943@unknownmsgid> Message-ID: <-8731458141539952470@unknownmsgid> On Nov 29, 2012, at 12:08 PM, Aaron Meurer wrote: On Nov 29, 2012, at 3:28 AM, Robert McGibbon wrote: Hi, Good spot, Matthias. I didn't see that method was already exposed -- I was just looking at IPCompleter.matchers, which what that method inserts into. Annotations are cool, but they're not obviously composable. I worry that if I use them for this and then fix one syntax of how the annotation is parsed, and somebody else is using annotations in their lib for something else, the two schemes won't be able to interoperate. Also they're py3k only. Annotations syntax is python 3 only, but other than that, anyone can modify an object's __annotations__ dict. Also, note that annotations don't have to be strings. They can be arbitrary objects. So what I would do is create completer template objects (e.g., there would be a FileCompleter for your example), and annotate with those. To compose, just make these objects in such a way that they are easily composable (or just annotate with a list of such objects, and append to the list of you want to add more). Actually, I think what we really need is a good type annotations system. PEP 3107, which defines the python 3 annotations syntax, mentions that they are leaving it up to the community to define such things. I think this is the perfect community to do that, lying at the center of the scientific python universe. It would then be just a case of making those type annotations completeable. This is one of the best kept secrets of python 3, and I think the special syntax could really help drive the community to switch. Aaron Meurer Aaron Meurer My preferred syntax would be from tablib import tabcompletion, filename, @tabcompletion(fname=filename, mode=['r', 'w']) def load(fname, mode, other_argument): pass or maybe with a parameterized filename to get specific extensions @tabcompletion(fname=filename('.txt')) def f(fname, other_argument): pass Is this something that other people would be interested in? -Robert On Nov 29, 2012, at 2:02 AM, Matthias BUSSONNIER wrote: Hi, I may be wrong, but IIRC you can insert your own completer in the IPython completer chain and decide to filter the previous completion. You should be able to have a custom completer that just forward the previous completion in most cases, And just do a dir completion if the object is np.loadtxt in your case (or look at __annotations__ if you wish). I've found one reference to inserting custom completer here http://ipython.org/ipython-doc/dev/api/generated/IPython.core.interactiveshell.html?highlight=interactiveshell#IPython.core.interactiveshell.InteractiveShell.set_custom_completer -- Matthias Le 29 nov. 2012 ? 10:27, Aaron Meurer a ?crit : I've often thought this as well. Probably a full-blown IPEP is in order here. Perhaps __annotations__ would be the correct way to go here. Aaron Meurer On Thu, Nov 29, 2012 at 12:58 AM, Robert McGibbon wrote: Hey, Tab completion in IPython is one of the things that makes it so useful, especially the context specific tab completion for things like "from ..." where only packages, or obviously the special completion for attributes when the line contains a dot. I use IPython for interactive data analysis a lot, and one of the most frequent operations is loading up data with something like numpy.loadtxt() or various related functions. It would be really awesome if we could annotate functions to interact with the tab completion system, perhaps for instance saying that argument 0 to numpy.loadtxt() is supposed to be a filename, so let's give tab-complete suggestions that try to look for directories/files. Some functions only files with specific extensions, so you could filter based on that or whatever. By hacking on the code for completerlib.py:cd_completer, I sketched out a little demo of what you could do with this: https://gist.github.com/4167151. The architecture is totally wrong, but it lets you get behavior like: ``` In [1]: ls datfile.dat dir1/ dir2/ file.gz random_junk test.py In [2]: directory_as_a_variable = 'sdfsfsd' In [3]: f = np.loadtxt( datfile.dat dir1/ dir2/ file.gz In [4]: normal_function( Display all 330 possibilities? (y or n) In [5]: g = np.loadtxt(di dict dir1/ directory_as_a_variable divmod dir dir2/ directory_of_my_choosing ``` Basically hitting the tab completion, when np.loadtxt is on the input line, only shows directories and files that end with a certain extension. If you start to type in the name of an object in your namespace, it'll show up too, but only once you've typed in more than 1 matching character. The implementation in my gist is pretty lame. The way I've coded it up, the special behavior is based on simply finding the string "np.loadtxt" on the input line, not on the actual function. This means you can't really make the behavior specific to your position in the argument list (i.e. I know that the first arg is a filename, and so should be tab completed like this, but the other ones are not). I suspect the right way to do the implementation is via function decorators to specify the behavior and then adding to IPCompleter instead. I think I'm up for giving this a shot. Thoughts? Is this a feature anyone else would find interesting? -Robert _______________________________________________ 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 _______________________________________________ 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 taavi.burns at gmail.com Thu Nov 29 18:43:59 2012 From: taavi.burns at gmail.com (Taavi Burns) Date: Thu, 29 Nov 2012 18:43:59 -0500 Subject: [IPython-dev] IPython nosetests extension In-Reply-To: References: Message-ID: On Tue, Nov 27, 2012 at 3:10 PM, Brian Granger wrote: > Hi, this is really exciting and will be a huge improvement for using > the notebook for real work. I will try to look a bit more at this > over the next week (in the middle of finals right now). But a few > comments: > > * Why exactly do you need cell ids? > I've enhanced the test failure stack traces such that the function's "filename" (like ) links to the cell that defines that code. That makes it easy to click close to the definition of a failing test or function. Even better would be linking directly to the line of code in question? :) Unfortunately the current implementation has a visual bug when linking to an anchor: the top IPython bar shifts up about 0.3em (it shifts back if you hit the empty fragment, "#"). > * We are soon going to completely remove the ability to publish > javascript from Python. There are two many horrific security > problems. The replacement abstraction is "javascript plugins" that > are under review here: > > https://github.com/ipython/ipython/pull/2518 > > There is more work to do on this, but this will give you an idea of > where we are headed. Please ask questions about the plugins on that > PR. > That makes a lot of sense. From a quick reading of it, an extension would be able to register JS to be loaded onto the page, and the publish_json method would allow the payload to be handed to one of those custom functions. There's no reason I can't port this extension to that style once that lands. I do have a few questions up-front: 1. Is there a better way than peeking at sys.displayhook to determine what kind of output to produce? 2. I'd really like to have cell anchor generation happen always. Seems like it would be useful to provide intra-notebook links to cells. I'm not sure how one would manage those links as the execution order evolves, though. For this extension, that migration is actually a good thing, as the anchor points to the code that was actually run even if it's no longer visible. 3. I'd love to have a consistent interface to stream something like stdout character-wise instead of line-wise. Right now it's hacked to hook stdout directly on the console, and with even more horrible jQuery machinations on the notebook side. Thanks! Cheers, > > Brian > > On Tue, Nov 27, 2012 at 11:49 AM, Taavi Burns > wrote: > > https://github.com/taavi/ipython_nose > > > > I've gotten the %nose magic Greg Ward and I worked on at the PyCon Canada > > sprints to a reasonable point. I'm not yet convinced that it's ready for > > integration into IPython (I think I'd like to get IPython to add id > > attributes on the cells so I don't have to add them myself with JS), but > it > > should be good enough for some real-world testing. > > > > It's pip-installable in development mode: > > . YOUR/VIRTUALENV/activate > > git clone https://github.com/taavi/ipython_nose.git > > cd ipython_nose > > pip install -e . > > > > I might not bother putting it on PyPI if it's as likely to get included > in > > the base IPython as Fernando was suggesting. ;) > > > > I'd appreciate any feedback on features and bugs. Feel free to lodge > them in > > the github tracker. Pull requests are also welcome! Please keep in mind > that > > the end goal is to integrate it into IPython proper, so some work might > be > > deferred until then. > > > > Thanks! > > > > -- > > taa > > /*eof*/ > > > > _______________________________________________ > > 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 > -- taa /*eof*/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmcgibbo at gmail.com Fri Nov 30 07:49:23 2012 From: rmcgibbo at gmail.com (Robert McGibbon) Date: Fri, 30 Nov 2012 04:49:23 -0800 Subject: [IPython-dev] Function specific hooks into the ipython tab completion system In-Reply-To: <50B77355.8050404@physics.harvard.edu> References: <96A177C3-9E59-44BD-8268-52F802E12C37@gmail.com> <357B7D49-C7B4-413A-A530-AA8F63EA79BF@gmail.com> <669615BA-66DA-4CA6-8848-ED64BC4E3710@gmail.com> <50B77355.8050404@physics.harvard.edu> Message-ID: <0B0DB9F0-4400-43CA-8BCD-EA2DEA7CE1FE@gmail.com> Hey, [tl;dr (1) Prototype working (2) Dynamic language = limited potential (3) Function annotations and getting the ball rolling on annotation interoperability schemes] I have a working prototype of the system at https://github.com/rmcgibbo/ipython/tree/functab. Currently, the only type of matches that are supported are for enumerated string literals. I will be adding more soon, and making the interface such that it is easy to extend the code with new argument specific tab completion logic. The heavy lifting is done I think. Here's what you can do currently: In [1]: from IPython.extensions.customtab import tab_completion In [2]: @tab_completion(mode=['read', 'write']) ...: def my_io(fname, mode): ...: print 'lets go now!' ...: In [3]: my_io('f.tgz', 'read' 'write' (or if there's only one matching completion, it'll obviously just fill in) So when your cursor is in place to be adding the second argument, it will do tab completions based on two static strings read from the decorator. It pretty much as you'd expect, supporting keyword args, etc. The one thing that's tricky is dealing with quotation mark literals (' and ") in readline. This was my first time coding against readline, so maybe I was making some rookie mistakes, but it seems to me like if you don't play any tricks, the quotation marks are not treated correctly. When the current token is '"rea', as if you've just started typing "read", and you hit tab, readline seems to tokenize the line and associate the opening quotation mark with the previous token, not the current one. This means that if you include it in the completion that you give, and you hit tab, the line will end up with TWO opening quotation marks, ala '""read'. (And it'll keep going if you keep hitting tab). I had to hack my way around this, but if anyone has any suggestions I'm all ears. --- As Tom said, there's a lot you could do with this -- enumerated string literals are just the tip of the iceberg. Some other ones include glob-completed string literals for filenames, type-based matching of python objects in the current namespace (i.e. only show tab completions for ndarray objects in your session, etc). You obviously can't do as much as you could in a statically typed language -- if you have type-based tab completion looking for ndarray objects, you're not going to be able to infer that since the return value of some random function like np.random.randn is going to be an ndarray, you could tab complete that too. While things like type checking can be done with decorators / annotations, this isn't really the place. In particular, the code for tab completion gets evaluated before you as a user ever hit enter and execute your line of code -- and itsnot appropriate to actually exec anything -- so there's no way to know the type of the first argument to a function like foo(bar(x), 1 at the time that the tab is executed. ---- As to the decorator vs function annotation syntax, I am hesitant to use annotations for a few reasons. First, selfishly, I don't use python3. (I would, but I depend on PyTabes for everything, and it isn't py3k ready). Without the syntactical support, manually attaching __annotations__ to functions seems like a lame api. Second, in order to do annotations "right" in such a way that two independent project don't have annotation semantics that fail to interoperate, everyone needs to agree on some system. If one library expects the annotations to be strings (or to mean a specific thing, like a type for typechecking) and another library expects something different, then everyone is in a bad spot. PEP3107 seems to want some convention to "develop organically". As the author of the PEP said on Python-ideas: > When the first big project like Zope or Twisted announces that "we will do > annotation interop like so...", everyone else will be pressured to > line up behind them. > I don't want to pick a mechanism, only to have to roll > another release when Zope or Twisted or some other big project pushes > out their own solution. But, on the other hand, maybe there's no time like the present to start, and although the PEP was finalized in 2010, and it doesn't seem like Django or any other big package is using annotations, so maybe we should lead the way? In that spirit, I propose two possible schemes for annotation interoperability: (1) All the annotations should be dicts. That way we can put tab-complete specific stuff under the 'tab' key and other libraries/features can put their stuff under a different key, like 'type' or what have you. One advantage are that it's simple. On the other hand, its kind of verbose, and IMO ugly. def my_io(fname, mode : {'tab': ['read', 'write']}): pass def my_io(fname, mode : {'tab': ['read', 'write'], 'foo':'bar'}): pass (2). Inspired by ggplot, where you compose plots by summing components, the annotations could be the sum of objects that overload __add__, like: def my_io(fname, mode : tab('read', 'write')) pass or def my_io(fname, mode : tab('read', 'write') + typecheck(str)): pass Where tab and typecheck are something like: class tab(object): def __init__(self, *args, **kwargs): self.args = args self.kwargs = kwargs self.next = None self.prev = None def __add__(self, other): if not hasattr(other, '__add__'): raise ValueError('"{}" must also be composable'.format(other)) self.next = other other.prev = self return other Then you could basically recover something analogous to the dictionary in proposal one by walking through the next/prev pointers. The advantages of this are chiefly visual. Obviously other things like lists or tuples or generic iterables could be done too. def my_io(fname, mode : (tab('read', 'write'), typecheck(str))): pass or def my_io(fname, mode : [tab('read', 'write'), typecheck(str)]): pass With some cleverness, it might be possible to add an __iter__ method to the tab class that would let you turn the sum into a list via list(iterable), such that via polymorphism the ggplot style and the tuple/list style could exist side-by-side. Basically, IMHO, using function annotation system requires some serious thought -- probably above my pay grade -- to do right. (Sorry this email was so long) -Robert On Nov 29, 2012, at 6:38 AM, Tom Dimiduk wrote: > That looks pretty great. I would use something like that. > > For the filename('.txt'), it could be handy to be able to pass arbitrary globs (as in for glob.glob). You could still default to matching against the end of the string for extensions, but adding the glob support costs little (since you probably want to use glob internally anyway. > > For extra (and unnecessary) fancyness, I could also see use cases for > from from tablib import tabcompletion, instance > class bar: > pass > @tabcompletion(foo=instance(bar)) > to be able to only complete for specific types of objects for other parameters (it would do an isinstance test). > > Even more bonus points if the decorator could parse numpy styled docstrings to grab that kind of information about parameters. I guess at this point you could do type checking, file existence checking, and a variety of other fun stuff there as well once you have that information, but that is almost certainly going out of the scope of your proposal. > > Sorry if I am growing your proposal too much, the basic thing you proposed would still be very useful. If I can grab some spare mental cycles, I would collaborate with you on it if you end up writing it. > > Tom > > On 11/29/2012 05:28 AM, Robert McGibbon wrote: >> Hi, >> >> Good spot, Matthias. I didn't see that method was already exposed -- I was just looking at IPCompleter.matchers, which what that method inserts into. >> >> Annotations are cool, but they're not obviously composable. I worry that if I use them for this and then fix one syntax of how the annotation is parsed, and somebody else >> is using annotations in their lib for something else, the two schemes won't be able to interoperate. Also they're py3k only. >> >> My preferred syntax would be >> >> from tablib import tabcompletion, filename, >> >> @tabcompletion(fname=filename, mode=['r', 'w']) >> def load(fname, mode, other_argument): >> pass >> >> or maybe with a parameterized filename to get specific extensions >> >> @tabcompletion(fname=filename('.txt')) >> def f(fname, other_argument): >> pass >> >> Is this something that other people would be interested in? >> >> -Robert >> >> On Nov 29, 2012, at 2:02 AM, Matthias BUSSONNIER wrote: >> >>> Hi, >>> >>> I may be wrong, but IIRC you can insert your own completer in the IPython completer chain and decide to filter the previous completion. >>> >>> You should be able to have a custom completer that just forward the previous completion in most cases, >>> And just do a dir completion if the object is np.loadtxt in your case (or look at __annotations__ if you wish). >>> >>> I've found one reference to inserting custom completer here >>> http://ipython.org/ipython-doc/dev/api/generated/IPython.core.interactiveshell.html?highlight=interactiveshell#IPython.core.interactiveshell.InteractiveShell.set_custom_completer >>> >>> >>> -- >>> Matthias >>> >>> Le 29 nov. 2012 ? 10:27, Aaron Meurer a ?crit : >>> >>>> I've often thought this as well. Probably a full-blown IPEP is in >>>> order here. Perhaps __annotations__ would be the correct way to go >>>> here. >>>> >>>> Aaron Meurer >>>> >>>> On Thu, Nov 29, 2012 at 12:58 AM, Robert McGibbon wrote: >>>>> Hey, >>>>> >>>>> Tab completion in IPython is one of the things that makes it so useful, >>>>> especially the context specific tab completion for things like "from ..." >>>>> where only packages, or obviously the special completion for attributes when >>>>> the line contains a dot. >>>>> >>>>> I use IPython for interactive data analysis a lot, and one of the most >>>>> frequent operations is loading up data with something like numpy.loadtxt() >>>>> or various related functions. >>>>> >>>>> It would be really awesome if we could annotate functions to interact with >>>>> the tab completion system, perhaps for instance saying that argument 0 to >>>>> numpy.loadtxt() is supposed to be a filename, so let's give tab-complete >>>>> suggestions that try to look for directories/files. Some functions only >>>>> files with specific extensions, so you could filter based on that or >>>>> whatever. >>>>> >>>>> By hacking on the code for completerlib.py:cd_completer, I sketched out a >>>>> little demo of what you could do with this: https://gist.github.com/4167151. >>>>> The architecture is totally wrong, but it lets you get behavior like: >>>>> >>>>> ``` >>>>> In [1]: ls >>>>> datfile.dat dir1/ dir2/ file.gz random_junk test.py >>>>> >>>>> In [2]: directory_as_a_variable = 'sdfsfsd' >>>>> >>>>> In [3]: f = np.loadtxt( >>>>> datfile.dat dir1/ dir2/ file.gz >>>>> >>>>> In [4]: normal_function( >>>>> Display all 330 possibilities? (y or n) >>>>> >>>>> In [5]: g = np.loadtxt(di >>>>> dict dir1/ directory_as_a_variable >>>>> divmod >>>>> dir dir2/ directory_of_my_choosing >>>>> ``` >>>>> >>>>> Basically hitting the tab completion, when np.loadtxt is on the input line, >>>>> only shows directories and files that end with a certain extension. If you >>>>> start to type in the name of an object in your namespace, it'll show up too, >>>>> but only once you've typed in more than 1 matching character. >>>>> >>>>> The implementation in my gist is pretty lame. The way I've coded it up, the >>>>> special behavior is based on simply finding the string "np.loadtxt" on the >>>>> input line, not on the actual function. This means you can't really make the >>>>> behavior specific to your position in the argument list (i.e. I know that >>>>> the first arg is a filename, and so should be tab completed like this, but >>>>> the other ones are not). I suspect the right way to do the implementation is >>>>> via function decorators to specify the behavior and then adding to >>>>> IPCompleter instead. >>>>> >>>>> I think I'm up for giving this a shot. >>>>> >>>>> Thoughts? Is this a feature anyone else would find interesting? >>>>> >>>>> -Robert >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> >> >> _______________________________________________ >> 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 Fri Nov 30 09:11:21 2012 From: takowl at gmail.com (Thomas Kluyver) Date: Fri, 30 Nov 2012 14:11:21 +0000 Subject: [IPython-dev] Function specific hooks into the ipython tab completion system In-Reply-To: <0B0DB9F0-4400-43CA-8BCD-EA2DEA7CE1FE@gmail.com> References: <96A177C3-9E59-44BD-8268-52F802E12C37@gmail.com> <357B7D49-C7B4-413A-A530-AA8F63EA79BF@gmail.com> <669615BA-66DA-4CA6-8848-ED64BC4E3710@gmail.com> <50B77355.8050404@physics.harvard.edu> <0B0DB9F0-4400-43CA-8BCD-EA2DEA7CE1FE@gmail.com> Message-ID: On 30 November 2012 12:49, Robert McGibbon wrote: > I don't use python3. (I would, but I depend on PyTabes for everything, and > it isn't py3k ready). Without the > syntactical support, manually attaching __annotations__ to functions seems > like a lame api. > It would be quite easy to write a decorator (@annotations perhaps) that would take care of handling __annotations__ for you, like this: @annotate(a=tab('foo'), b=int) def myfunc(a, b=1): ... Then frameworks using annotations could keep working seamlessly as downstream code transitions to: def myfunc(a:tab('foo'), b:int =5): ... > Second, in order to do annotations "right" in such a way that two > independent project don't have annotation semantics > that fail to interoperate, everyone needs to agree on some system. If one > library expects the annotations to be strings > (or to mean a specific thing, like a type for typechecking) and another > library expects something different, then everyone is > in a bad spot. PEP3107 seems > to want some convention to "develop organically". > I agree that this is somewhat awkward. But I think a convention will have to develop where frameworks ignore annotations they don't understand. As a starting set of rules, it seems sensible that: - Annotations that are built-in types (e.g. int) will indicate some kind of variable contract, so the associated parameter should always be of that type. - Annotations that are strings will be used like docstrings. I suggest all more advanced uses involve some sort of wrapper, like tab() in your examples. Frameworks that don't recognise the wrapper will ignore the contents. > (2). Inspired by ggplot , where > you compose plots by *summing* components, the annotations could be the > sum of > objects that overload __add__, like: > This looks nice! I'd also thought of the dictionary idea, but it does make code ugly. I'd implement it slightly differently, though - instead of a linked list, I'd make __add__ return a container object, so you could add things like strings (so long as they're not in first place): def my_io(fname, mode: tab('read','write') + "The mode in which to open the file"): ... I think it's worth floating these ideas in a more general Python forum, so we can get feedback from other people thinking about using annotations. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From wen.g.gong at gmail.com Fri Nov 30 10:29:50 2012 From: wen.g.gong at gmail.com (W Gong) Date: Fri, 30 Nov 2012 10:29:50 -0500 Subject: [IPython-dev] try jsplugins d3graph Message-ID: Hi, I followed the instruction from jsplugins > d3graph > README.md d3graph.py : copied to .ipython\extensions d3graph.js and d3graph.css : copied to .ipython\profile_default\static\jsplugins\d3graph (Note: I am on window, using EPD and ipython-0.13.2.dev-py2.7.egg) run ipython notebook --pylab inline open Visualizing Graphs with d3.ipynb each cell was executed, but the graph did not show up. But I can plot graph with: pos=nx.spring_layout(G,iterations=100) plt.subplot(221) nx.draw(G,pos,font_size=8) A screenshot is available at http://dl.dropbox.com/u/54552252/d3graph_display-not-showing.jpg Let me what is missing Thanks, Wen -------------- next part -------------- An HTML attachment was scrubbed... URL: From cyrille.rossant at gmail.com Fri Nov 30 10:38:29 2012 From: cyrille.rossant at gmail.com (Cyrille Rossant) Date: Fri, 30 Nov 2012 15:38:29 +0000 Subject: [IPython-dev] try jsplugins d3graph In-Reply-To: References: Message-ID: 2012/11/30 W Gong > Hi, > I followed the instruction from jsplugins > d3graph > README.md > > d3graph.py : copied to .ipython\extensions > > d3graph.js and d3graph.css : copied > to .ipython\profile_default\static\jsplugins\d3graph > > (Note: I am on window, using EPD and > ipython-0.13.2.dev-py2.7.egg) > > run ipython notebook --pylab inline > > open Visualizing Graphs with d3.ipynb > > each cell was executed, but the graph did not show up. > > But I can plot graph with: > > pos=nx.spring_layout(G,iterations=100) > plt.subplot(221) > nx.draw(G,pos,font_size=8) > > > A screenshot is available at > http://dl.dropbox.com/u/54552252/d3graph_display-not-showing.jpg > > Let me what is missing > Hi, Are you using this branch for IPython? https://github.com/ellisonbg/ipython/tree/jsonhandlers Cyrille -------------- next part -------------- An HTML attachment was scrubbed... URL: From wen.g.gong at gmail.com Fri Nov 30 10:50:05 2012 From: wen.g.gong at gmail.com (W Gong) Date: Fri, 30 Nov 2012 10:50:05 -0500 Subject: [IPython-dev] try jsplugins d3graph In-Reply-To: References: Message-ID: Hi, Cyrille, I am not aware of this branch, but will try it out. Thanks for your quick response Wen On Fri, Nov 30, 2012 at 10:38 AM, Cyrille Rossant wrote: > > 2012/11/30 W Gong > >> Hi, >> I followed the instruction from jsplugins > d3graph > README.md >> >> d3graph.py : copied to .ipython\extensions >> >> d3graph.js and d3graph.css : copied >> to .ipython\profile_default\static\jsplugins\d3graph >> >> (Note: I am on window, using EPD and >> ipython-0.13.2.dev-py2.7.egg) >> >> run ipython notebook --pylab inline >> >> open Visualizing Graphs with d3.ipynb >> >> each cell was executed, but the graph did not show up. >> >> But I can plot graph with: >> >> pos=nx.spring_layout(G,iterations=100) >> plt.subplot(221) >> nx.draw(G,pos,font_size=8) >> >> >> A screenshot is available at >> http://dl.dropbox.com/u/54552252/d3graph_display-not-showing.jpg >> >> Let me what is missing >> > > Hi, > > Are you using this branch for IPython? > https://github.com/ellisonbg/ipython/tree/jsonhandlers > > Cyrille > > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > -- Thanks, - Wen -------------- next part -------------- An HTML attachment was scrubbed... URL: From asmeurer at gmail.com Fri Nov 30 10:52:45 2012 From: asmeurer at gmail.com (Aaron Meurer) Date: Fri, 30 Nov 2012 08:52:45 -0700 Subject: [IPython-dev] Function specific hooks into the ipython tab completion system In-Reply-To: <0B0DB9F0-4400-43CA-8BCD-EA2DEA7CE1FE@gmail.com> References: <96A177C3-9E59-44BD-8268-52F802E12C37@gmail.com> <357B7D49-C7B4-413A-A530-AA8F63EA79BF@gmail.com> <669615BA-66DA-4CA6-8848-ED64BC4E3710@gmail.com> <50B77355.8050404@physics.harvard.edu> <0B0DB9F0-4400-43CA-8BCD-EA2DEA7CE1FE@gmail.com> Message-ID: <3384313335217771310@unknownmsgid> On Nov 30, 2012, at 5:49 AM, Robert McGibbon wrote: Hey, *[tl;dr (1) Prototype working (2) Dynamic language = limited potential (3) Function annotations and* *getting the ball rolling on annotation interoperability schemes]* I have a working prototype of the system at https://github.com/rmcgibbo/ipython/tree/functab. Currently, the only type of matches that are supported are for enumerated string literals. I will be adding more soon, and making the interface such that it is easy to extend the code with new argument specific tab completion logic. The heavy lifting is done I think. Here's what you can do currently: In [1]: from IPython.extensions.customtab import tab_completion In [2]: @tab_completion(mode=['read', 'write']) ...: def my_io(fname, mode): ...: print 'lets go now!' ...: In [3]: my_io('f.tgz', 'read' 'write' (or if there's only one matching completion, it'll obviously just fill in) So when your cursor is in place to be adding the second argument, it will do tab completions based on two static strings read from the decorator. It pretty much as you'd expect, supporting keyword args, etc. The one thing that's tricky is dealing with quotation mark literals (' and ") in readline. This was my first time coding against readline, so maybe I was making some rookie mistakes, but it seems to me like if you don't play any tricks, the quotation marks are not treated correctly. When the current token is '"rea', as if you've just started typing "read", and you hit tab, readline seems to tokenize the line and associate the opening quotation mark with the previous token, not the current one. This means that if you include it in the completion that you give, and you hit tab, the line will end up with TWO opening quotation marks, ala '""read'. (And it'll keep going if you keep hitting tab). I had to hack my way around this, but if anyone has any suggestions I'm all ears. --- As Tom said, there's a lot you could do with this -- enumerated string literals are just the tip of the iceberg. Some other ones include glob-completed string literals for filenames, type-based matching of python objects in the current namespace (i.e. only show tab completions for ndarray objects in your session, etc). You obviously can't do as much as you could in a statically typed language -- if you have type-based tab completion looking for ndarray objects, you're not going to be able to infer that since the return value of some random function like np.random.randn is going to be an ndarray, you could tab complete that too. While things like type checking can be done with decorators / annotations, this isn't really the place. In particular, the code for tab completion gets evaluated before you as a user ever hit enter and execute your line of code -- and itsnot appropriate to actually exec anything -- so there's no way to know the type of the first argument to a function like foo(bar(x), 1 at the time that the tab is executed. Function annotations also let you annotate the return type of a function. ---- As to the decorator vs function annotation syntax, I am hesitant to use annotations for a few reasons. First, selfishly, I don't use python3. (I would, but I depend on PyTabes for everything, and it isn't py3k ready). Without the syntactical support, manually attaching __annotations__ to functions seems like a lame api. It would be easy to make the decorators discussed before use __annotations__ to store the data. Second, in order to do annotations "right" in such a way that two independent project don't have annotation semantics that fail to interoperate, everyone needs to agree on some system. If one library expects the annotations to be strings (or to mean a specific thing, like a type for typechecking) and another library expects something different, then everyone is in a bad spot. PEP3107 seems to want some convention to "develop organically". As the author of the PEP said on Python-ideas: When the first big project like Zope or Twisted announces that "we will do annotation interop like so...", everyone else will be pressured to line up behind them. I don't want to pick a mechanism, only to have to roll another release when Zope or Twisted or some other big project pushes out their own solution. But, on the other hand, maybe there's no time like the present to start, and although the PEP was finalized in 2010, and it doesn't seem like Django or any other big package is using annotations, so maybe we should lead the way? This is exactly the point I was trying to make. Unless I'm mistaken, no one in the scientific python community uses annotations yet. IPython is the perfect project to start to standardize it for this community, and hopefully push other communities as well. In that spirit, I propose two possible schemes for annotation interoperability: (1) All the annotations should be dicts. That way we can put tab-complete specific stuff under the 'tab' key and other libraries/features can put their stuff under a different key, like 'type'or what have you. One advantage are that it's simple. On the other hand, its kind of verbose, and IMO ugly. def my_io(fname, mode : {'tab': ['read', 'write']}): pass def my_io(fname, mode : {'tab': ['read', 'write'], 'foo':'bar'}): pass I like this idea. In general, the elements of the list would be TabCompletion objects that describe arbitrary tab completions (e.g., files in the current directory). (2). Inspired by ggplot , where you compose plots by *summing* components, the annotations could be the sum of objects that overload __add__, like: def my_io(fname, mode : tab('read', 'write')) pass or def my_io(fname, mode : tab('read', 'write') + typecheck(str)): pass Where tab and typecheck are something like: class tab(object): def __init__(self, *args, **kwargs): self.args = args self.kwargs = kwargs self.next = None self.prev = None def __add__(self, other): if not hasattr(other, '__add__'): raise ValueError('"{}" must also be composable'.format(other)) self.next = other other.prev = self return other Then you could basically recover something analogous to the dictionary in proposal one by walking through the next/prev pointers. The advantages of this are chiefly visual. You could actually make this identical to option 1 by subclassing dict and overriding __add__. I'm not sure it's necessary for most libraries, though. If you want simple syntax, just write a simple helper function so you can just do mode: tab(["read", "write"]), where tab(a) returns {'tab': a}. But if you just require the API __annotations__["arg"]['tab'], it doesn't matter if you use a dict or a custom object. Aaron Meurer Obviously other things like lists or tuples or generic iterables could be done too. def my_io(fname, mode : (tab('read', 'write'), typecheck(str))): pass or def my_io(fname, mode : [tab('read', 'write'), typecheck(str)]): pass With some cleverness, it might be possible to add an __iter__ method to the tab class that would let you turn the sum into a list via list(iterable), such that via polymorphism the ggplot style and the tuple/list style could exist side-by-side. Basically, IMHO, using function annotation system requires some serious thought -- probably above my pay grade -- to do right. (Sorry this email was so long) -Robert On Nov 29, 2012, at 6:38 AM, Tom Dimiduk wrote: That looks pretty great. I would use something like that. For the filename('.txt'), it could be handy to be able to pass arbitrary globs (as in for glob.glob). You could still default to matching against the end of the string for extensions, but adding the glob support costs little (since you probably want to use glob internally anyway. For extra (and unnecessary) fancyness, I could also see use cases for from from tablib import tabcompletion, instance class bar: pass @tabcompletion(foo=instance(bar)) to be able to only complete for specific types of objects for other parameters (it would do an isinstance test). Even more bonus points if the decorator could parse numpy styled docstrings to grab that kind of information about parameters. I guess at this point you could do type checking, file existence checking, and a variety of other fun stuff there as well once you have that information, but that is almost certainly going out of the scope of your proposal. Sorry if I am growing your proposal too much, the basic thing you proposed would still be very useful. If I can grab some spare mental cycles, I would collaborate with you on it if you end up writing it. Tom On 11/29/2012 05:28 AM, Robert McGibbon wrote: Hi, Good spot, Matthias. I didn't see that method was already exposed -- I was just looking at IPCompleter.matchers, which what that method inserts into. Annotations are cool, but they're not obviously composable. I worry that if I use them for this and then fix one syntax of how the annotation is parsed, and somebody else is using annotations in their lib for something else, the two schemes won't be able to interoperate. Also they're py3k only. My preferred syntax would be from tablib import tabcompletion, filename, @tabcompletion(fname=filename, mode=['r', 'w']) def load(fname, mode, other_argument): pass or maybe with a parameterized filename to get specific extensions @tabcompletion(fname=filename('.txt')) def f(fname, other_argument): pass Is this something that other people would be interested in? -Robert On Nov 29, 2012, at 2:02 AM, Matthias BUSSONNIER wrote: Hi, I may be wrong, but IIRC you can insert your own completer in the IPython completer chain and decide to filter the previous completion. You should be able to have a custom completer that just forward the previous completion in most cases, And just do a dir completion if the object is np.loadtxt in your case (or look at __annotations__ if you wish). I've found one reference to inserting custom completer here http://ipython.org/ipython-doc/dev/api/generated/IPython.core.interactiveshell.html?highlight=interactiveshell#IPython.core.interactiveshell.InteractiveShell.set_custom_completer -- Matthias Le 29 nov. 2012 ? 10:27, Aaron Meurer a ?crit : I've often thought this as well. Probably a full-blown IPEP is in order here. Perhaps __annotations__ would be the correct way to go here. Aaron Meurer On Thu, Nov 29, 2012 at 12:58 AM, Robert McGibbon wrote: Hey, Tab completion in IPython is one of the things that makes it so useful, especially the context specific tab completion for things like "from ..." where only packages, or obviously the special completion for attributes when the line contains a dot. I use IPython for interactive data analysis a lot, and one of the most frequent operations is loading up data with something like numpy.loadtxt() or various related functions. It would be really awesome if we could annotate functions to interact with the tab completion system, perhaps for instance saying that argument 0 to numpy.loadtxt() is supposed to be a filename, so let's give tab-complete suggestions that try to look for directories/files. Some functions only files with specific extensions, so you could filter based on that or whatever. By hacking on the code for completerlib.py:cd_completer, I sketched out a little demo of what you could do with this: https://gist.github.com/4167151. The architecture is totally wrong, but it lets you get behavior like: ``` In [1]: ls datfile.dat dir1/ dir2/ file.gz random_junk test.py In [2]: directory_as_a_variable = 'sdfsfsd' In [3]: f = np.loadtxt( datfile.dat dir1/ dir2/ file.gz In [4]: normal_function( Display all 330 possibilities? (y or n) In [5]: g = np.loadtxt(di dict dir1/ directory_as_a_variable divmod dir dir2/ directory_of_my_choosing ``` Basically hitting the tab completion, when np.loadtxt is on the input line, only shows directories and files that end with a certain extension. If you start to type in the name of an object in your namespace, it'll show up too, but only once you've typed in more than 1 matching character. The implementation in my gist is pretty lame. The way I've coded it up, the special behavior is based on simply finding the string "np.loadtxt" on the input line, not on the actual function. This means you can't really make the behavior specific to your position in the argument list (i.e. I know that the first arg is a filename, and so should be tab completed like this, but the other ones are not). I suspect the right way to do the implementation is via function decorators to specify the behavior and then adding to IPCompleter instead. I think I'm up for giving this a shot. Thoughts? Is this a feature anyone else would find interesting? -Robert _______________________________________________ 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 _______________________________________________ IPython-dev mailing listIPython-dev at scipy.orghttp://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 wen.g.gong at gmail.com Fri Nov 30 11:58:16 2012 From: wen.g.gong at gmail.com (W Gong) Date: Fri, 30 Nov 2012 11:58:16 -0500 Subject: [IPython-dev] try jsplugins d3graph In-Reply-To: References: Message-ID: yes, d3grpah now works, But PyTutor does not: after %%pytutor, shall I expect the callstack to display? nothing is display for me Did I miss any pre-requisite? Any suggestion? Thanks, Wen On Fri, Nov 30, 2012 at 10:50 AM, W Gong wrote: > Hi, Cyrille, > I am not aware of this branch, but will try it out. > > Thanks for your quick response > > Wen > > On Fri, Nov 30, 2012 at 10:38 AM, Cyrille Rossant < > cyrille.rossant at gmail.com> wrote: > >> >> 2012/11/30 W Gong >> >>> Hi, >>> I followed the instruction from jsplugins > d3graph > README.md >>> >>> d3graph.py : copied to .ipython\extensions >>> >>> d3graph.js and d3graph.css : copied >>> to .ipython\profile_default\static\jsplugins\d3graph >>> >>> (Note: I am on window, using EPD and >>> ipython-0.13.2.dev-py2.7.egg) >>> >>> run ipython notebook --pylab inline >>> >>> open Visualizing Graphs with d3.ipynb >>> >>> each cell was executed, but the graph did not show up. >>> >>> But I can plot graph with: >>> >>> pos=nx.spring_layout(G,iterations=100) >>> plt.subplot(221) >>> nx.draw(G,pos,font_size=8) >>> >>> >>> A screenshot is available at >>> http://dl.dropbox.com/u/54552252/d3graph_display-not-showing.jpg >>> >>> Let me what is missing >>> >> >> Hi, >> >> Are you using this branch for IPython? >> https://github.com/ellisonbg/ipython/tree/jsonhandlers >> >> Cyrille >> >> >> >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev >> >> > > > -- > > Thanks, > > - Wen > > > > > -- Thanks, - Wen -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Fri Nov 30 12:10:30 2012 From: ellisonbg at gmail.com (Brian Granger) Date: Fri, 30 Nov 2012 09:10:30 -0800 Subject: [IPython-dev] try jsplugins d3graph In-Reply-To: References: Message-ID: I think there is a problem with the pytutor one right now, as Fernando ran into something similar. PRs welcome :) Brian On Fri, Nov 30, 2012 at 8:58 AM, W Gong wrote: > yes, > d3grpah now works, > > But PyTutor does not: > after %%pytutor, shall I expect the callstack to display? nothing is display > for me > > Did I miss any pre-requisite? Any suggestion? > > Thanks, > Wen > > > On Fri, Nov 30, 2012 at 10:50 AM, W Gong wrote: >> >> Hi, Cyrille, >> I am not aware of this branch, but will try it out. >> >> Thanks for your quick response >> >> Wen >> >> On Fri, Nov 30, 2012 at 10:38 AM, Cyrille Rossant >> wrote: >>> >>> >>> 2012/11/30 W Gong >>>> >>>> Hi, >>>> I followed the instruction from jsplugins > d3graph > README.md >>>> >>>> d3graph.py : copied to .ipython\extensions >>>> >>>> d3graph.js and d3graph.css : copied to >>>> .ipython\profile_default\static\jsplugins\d3graph >>>> >>>> (Note: I am on window, using EPD and >>>> ipython-0.13.2.dev-py2.7.egg) >>>> >>>> run ipython notebook --pylab inline >>>> >>>> open Visualizing Graphs with d3.ipynb >>>> >>>> each cell was executed, but the graph did not show up. >>>> >>>> But I can plot graph with: >>>> >>>> pos=nx.spring_layout(G,iterations=100) >>>> plt.subplot(221) >>>> nx.draw(G,pos,font_size=8) >>>> >>>> >>>> A screenshot is available at >>>> http://dl.dropbox.com/u/54552252/d3graph_display-not-showing.jpg >>>> >>>> Let me what is missing >>> >>> >>> Hi, >>> >>> Are you using this branch for IPython? >>> https://github.com/ellisonbg/ipython/tree/jsonhandlers >>> >>> Cyrille >>> >>> >>> >>> _______________________________________________ >>> IPython-dev mailing list >>> IPython-dev at scipy.org >>> http://mail.scipy.org/mailman/listinfo/ipython-dev >>> >> >> >> >> -- >> >> Thanks, >> >> - Wen >> >> >> >> > > > > -- > > Thanks, > > - Wen > > > > > > _______________________________________________ > 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 wen.g.gong at gmail.com Fri Nov 30 13:59:20 2012 From: wen.g.gong at gmail.com (W Gong) Date: Fri, 30 Nov 2012 13:59:20 -0500 Subject: [IPython-dev] try jsplugins d3graph In-Reply-To: References: Message-ID: Brian from pytutor.js, I see the following commented out: /* To import, put this at the top of your HTML page: */ I don't see jquery.ba-bbq.min.js jquery-ui-1.8.24.custom.min.js jquery.qtip.min.js are loaded anyway Wen On Fri, Nov 30, 2012 at 12:10 PM, Brian Granger wrote: > I think there is a problem with the pytutor one right now, as Fernando > ran into something similar. PRs welcome :) > > Brian > > On Fri, Nov 30, 2012 at 8:58 AM, W Gong wrote: > > yes, > > d3grpah now works, > > > > But PyTutor does not: > > after %%pytutor, shall I expect the callstack to display? nothing is > display > > for me > > > > Did I miss any pre-requisite? Any suggestion? > > > > Thanks, > > Wen > > > > > > On Fri, Nov 30, 2012 at 10:50 AM, W Gong wrote: > >> > >> Hi, Cyrille, > >> I am not aware of this branch, but will try it out. > >> > >> Thanks for your quick response > >> > >> Wen > >> > >> On Fri, Nov 30, 2012 at 10:38 AM, Cyrille Rossant > >> wrote: > >>> > >>> > >>> 2012/11/30 W Gong > >>>> > >>>> Hi, > >>>> I followed the instruction from jsplugins > d3graph > README.md > >>>> > >>>> d3graph.py : copied to .ipython\extensions > >>>> > >>>> d3graph.js and d3graph.css : copied to > >>>> .ipython\profile_default\static\jsplugins\d3graph > >>>> > >>>> (Note: I am on window, using EPD and > >>>> ipython-0.13.2.dev-py2.7.egg) > >>>> > >>>> run ipython notebook --pylab inline > >>>> > >>>> open Visualizing Graphs with d3.ipynb > >>>> > >>>> each cell was executed, but the graph did not show up. > >>>> > >>>> But I can plot graph with: > >>>> > >>>> pos=nx.spring_layout(G,iterations=100) > >>>> plt.subplot(221) > >>>> nx.draw(G,pos,font_size=8) > >>>> > >>>> > >>>> A screenshot is available at > >>>> http://dl.dropbox.com/u/54552252/d3graph_display-not-showing.jpg > >>>> > >>>> Let me what is missing > >>> > >>> > >>> Hi, > >>> > >>> Are you using this branch for IPython? > >>> https://github.com/ellisonbg/ipython/tree/jsonhandlers > >>> > >>> Cyrille > >>> > >>> > >>> > >>> _______________________________________________ > >>> IPython-dev mailing list > >>> IPython-dev at scipy.org > >>> http://mail.scipy.org/mailman/listinfo/ipython-dev > >>> > >> > >> > >> > >> -- > >> > >> Thanks, > >> > >> - Wen > >> > >> > >> > >> > > > > > > > > -- > > > > Thanks, > > > > - Wen > > > > > > > > > > > > _______________________________________________ > > 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 > -- Thanks, - Wen -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Fri Nov 30 14:56:04 2012 From: ellisonbg at gmail.com (Brian Granger) Date: Fri, 30 Nov 2012 11:56:04 -0800 Subject: [IPython-dev] try jsplugins d3graph In-Reply-To: References: Message-ID: Thanks, I will have a look at this when I get back to working on the plugin stuff. Brian On Fri, Nov 30, 2012 at 10:59 AM, W Gong wrote: > Brian > > from pytutor.js, I see the following commented out: > > /* To import, put this at the top of your HTML page: > > > > > > > > rel="stylesheet" /> > > > > > > > > > */ > > I don't see > jquery.ba-bbq.min.js > jquery-ui-1.8.24.custom.min.js > jquery.qtip.min.js > > are loaded anyway > > Wen > > On Fri, Nov 30, 2012 at 12:10 PM, Brian Granger wrote: >> >> I think there is a problem with the pytutor one right now, as Fernando >> ran into something similar. PRs welcome :) >> >> Brian >> >> On Fri, Nov 30, 2012 at 8:58 AM, W Gong wrote: >> > yes, >> > d3grpah now works, >> > >> > But PyTutor does not: >> > after %%pytutor, shall I expect the callstack to display? nothing is >> > display >> > for me >> > >> > Did I miss any pre-requisite? Any suggestion? >> > >> > Thanks, >> > Wen >> > >> > >> > On Fri, Nov 30, 2012 at 10:50 AM, W Gong wrote: >> >> >> >> Hi, Cyrille, >> >> I am not aware of this branch, but will try it out. >> >> >> >> Thanks for your quick response >> >> >> >> Wen >> >> >> >> On Fri, Nov 30, 2012 at 10:38 AM, Cyrille Rossant >> >> wrote: >> >>> >> >>> >> >>> 2012/11/30 W Gong >> >>>> >> >>>> Hi, >> >>>> I followed the instruction from jsplugins > d3graph > README.md >> >>>> >> >>>> d3graph.py : copied to .ipython\extensions >> >>>> >> >>>> d3graph.js and d3graph.css : copied to >> >>>> .ipython\profile_default\static\jsplugins\d3graph >> >>>> >> >>>> (Note: I am on window, using EPD and >> >>>> ipython-0.13.2.dev-py2.7.egg) >> >>>> >> >>>> run ipython notebook --pylab inline >> >>>> >> >>>> open Visualizing Graphs with d3.ipynb >> >>>> >> >>>> each cell was executed, but the graph did not show up. >> >>>> >> >>>> But I can plot graph with: >> >>>> >> >>>> pos=nx.spring_layout(G,iterations=100) >> >>>> plt.subplot(221) >> >>>> nx.draw(G,pos,font_size=8) >> >>>> >> >>>> >> >>>> A screenshot is available at >> >>>> http://dl.dropbox.com/u/54552252/d3graph_display-not-showing.jpg >> >>>> >> >>>> Let me what is missing >> >>> >> >>> >> >>> Hi, >> >>> >> >>> Are you using this branch for IPython? >> >>> https://github.com/ellisonbg/ipython/tree/jsonhandlers >> >>> >> >>> Cyrille >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> IPython-dev mailing list >> >>> IPython-dev at scipy.org >> >>> http://mail.scipy.org/mailman/listinfo/ipython-dev >> >>> >> >> >> >> >> >> >> >> -- >> >> >> >> Thanks, >> >> >> >> - Wen >> >> >> >> >> >> >> >> >> > >> > >> > >> > -- >> > >> > Thanks, >> > >> > - Wen >> > >> > >> > >> > >> > >> > _______________________________________________ >> > 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 > > > > > -- > > Thanks, > > - Wen > > > > > > _______________________________________________ > 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 d.warde.farley at gmail.com Fri Nov 30 18:05:51 2012 From: d.warde.farley at gmail.com (David Warde-Farley) Date: Fri, 30 Nov 2012 18:05:51 -0500 Subject: [IPython-dev] [nbconvert] Reining in the number of constructor arguments Message-ID: I'm wondering how to solve (and how you guys think I should solve) a certain problem I foresee, of a potentially rapidly growing number of constructor arguments for Converter classes, which need to be maintained across constructors in order to keep the front-end calling code generic (one could use *args and **kwargs catch-alls but that's pretty ugly). A pull request that @Jovani started and I have finished off adds a highlight_source argument to the constructors for all of the classes. I have some features in mind that control fine-grained output behavior. Passing these as either positional or keyword arguments requires every other Converter class to know about every possible argument, which is a maintenance nightmare, and doesn't necessarily make sense: part of the problem is that not every backend even *supports* all of the options, e.g. the ConverterPy can't highlight source in code blocks because that doesn't make any sense in terms of the output type. My thought on solving this goes something like this: - on the front-end, delegate all but very core functions that are backend-agnostic to a sub-parser - on the back-end, have either the "namespace" object produced by argparse or a dictionary constructed from it passed as a *single* argument to the constructor. - have each class examine this namespace Questions: - Should a backend that can't highlight source, or perform optional function X, raise an error, a warning, or fail silently? My gut says warning is the right balance of informative and yet annoying. (should I use the warnings module, logging.warn, ...?) This raises one problem, though, in that some defaults as per argparse will raise warnings automatically in some backends, e.g. without --no-highlight, the default argument of `True` will raise a warning when the output type is a Python script. A possible solution: make argparse's default be 'None' for options even when True/False is the default. Have converter classes expose a class-level `config_defaults` dict, where values are 2-tuples: (default value, legal_values), which the class uses to address its configuration needs for things that come up as None in the configuration object passed in, and raise warnings for invalid values where appropriate. Thoughts? Am I off my rocker? David From takowl at gmail.com Fri Nov 30 18:44:53 2012 From: takowl at gmail.com (Thomas Kluyver) Date: Fri, 30 Nov 2012 23:44:53 +0000 Subject: [IPython-dev] [nbconvert] Reining in the number of constructor arguments In-Reply-To: References: Message-ID: On 30 November 2012 23:05, David Warde-Farley wrote: > I'm wondering how to solve (and how you guys think I should solve) a > certain problem I foresee, of a potentially rapidly growing number of > constructor arguments for Converter classes, which need to be > maintained across constructors in order to keep the front-end calling > code generic (one could use *args and **kwargs catch-alls but that's > pretty ugly). > I may be barking up the wrong tree, but instead of constructor arguments, would it make sense to simply set attributes on the converter, e.g. conv = HTMLConverter() conv.highlight_source = False This is the route I went for in a recent nbviewer PR: https://github.com/ipython/nbviewer/pull/10/files#L0R127 This gives us simple introspection by looking at the attributes, and classes will ignore irrelevant options, so long as we don't get conflicting names. We could also allow setting them from the constructor using **kwargs. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmcgibbo at gmail.com Fri Nov 30 18:47:39 2012 From: rmcgibbo at gmail.com (Robert McGibbon) Date: Fri, 30 Nov 2012 15:47:39 -0800 Subject: [IPython-dev] Function specific hooks into the ipython tab completion system In-Reply-To: <3384313335217771310@unknownmsgid> References: <96A177C3-9E59-44BD-8268-52F802E12C37@gmail.com> <357B7D49-C7B4-413A-A530-AA8F63EA79BF@gmail.com> <669615BA-66DA-4CA6-8848-ED64BC4E3710@gmail.com> <50B77355.8050404@physics.harvard.edu> <0B0DB9F0-4400-43CA-8BCD-EA2DEA7CE1FE@gmail.com> <3384313335217771310@unknownmsgid> Message-ID: There are a lot of possible interoperability schemes -- which don't all interoperate with each other -- for annotations it seems. I'm not sure if I really want my smallish tab completion feature to get bogged down in this discussion. But I'm going to change my prototype implementation to use __annotations__. For the virtue of simplicity, I'm going to use a scheme where func.__annotations__['arg'] is expected to be iterable. To check for tab completion stuff, my code will iterate through, look for stuff it recognizes, and ignore stuff that it doesn't. If someone else wants to try to get this discussion going in the wider python community, I'm all ears. But I don't think that person is going to be me. -Robert On Nov 30, 2012, at 7:52 AM, Aaron Meurer wrote: > On Nov 30, 2012, at 5:49 AM, Robert McGibbon wrote: > >> Hey, >> >> [tl;dr (1) Prototype working (2) Dynamic language = limited potential (3) Function annotations and >> getting the ball rolling on annotation interoperability schemes] >> >> I have a working prototype of the system at https://github.com/rmcgibbo/ipython/tree/functab. >> Currently, the only type of matches that are supported are for enumerated string literals. >> I will be adding more soon, and making the interface such that it is easy to extend the code with >> new argument specific tab completion logic. The heavy lifting is done I think. >> >> Here's what you can do currently: >> >> In [1]: from IPython.extensions.customtab import tab_completion >> >> In [2]: @tab_completion(mode=['read', 'write']) >> ...: def my_io(fname, mode): >> ...: print 'lets go now!' >> ...: >> >> In [3]: my_io('f.tgz', >> 'read' 'write' >> >> (or if there's only one matching completion, it'll obviously just fill in) >> >> So when your cursor is in place to be adding the second argument, it will do tab completions based on >> two static strings read from the decorator. It pretty much as you'd expect, supporting keyword args, etc. >> >> The one thing that's tricky is dealing with quotation mark literals (' and ") in readline. This was my first >> time coding against readline, so maybe I was making some rookie mistakes, but it seems to me like if >> you don't play any tricks, the quotation marks are not treated correctly. When the current token is '"rea', >> as if you've just started typing "read", and you hit tab, readline seems to tokenize the line and associate >> the opening quotation mark with the previous token, not the current one. This means that if you include it >> in the completion that you give, and you hit tab, the line will end up with TWO opening quotation marks, >> ala '""read'. (And it'll keep going if you keep hitting tab). I had to hack my way around this, but if >> anyone has any suggestions I'm all ears. >> >> --- >> >> As Tom said, there's a lot you could do with this -- enumerated string literals are just the tip of the >> iceberg. Some other ones include glob-completed string literals for filenames, type-based >> matching of python objects in the current namespace (i.e. only show tab completions for ndarray >> objects in your session, etc). >> >> You obviously can't do as much as you could in a statically typed language -- if you have type-based tab >> completion looking for ndarray objects, you're not going to be able to infer that since the return value of >> some random function like np.random.randn is going to be an ndarray, you could tab complete that too. >> While things like type checking can be done with decorators / annotations, this isn't really the place. In particular, >> the code for tab completion gets evaluated before you as a user ever hit enter and execute your line of >> code -- and itsnot appropriate to actually exec anything -- so there's no way to know the type of the first >> argument to a function like foo(bar(x), 1 at the time that the tab is executed. > > Function annotations also let you annotate the return type of a function. > >> >> ---- >> >> As to the decorator vs function annotation syntax, I am hesitant to use annotations for a few reasons. First, selfishly, >> I don't use python3. (I would, but I depend on PyTabes for everything, and it isn't py3k ready). Without the >> syntactical support, manually attaching __annotations__ to functions seems like a lame api. > > It would be easy to make the decorators discussed before use __annotations__ to store the data. > >> >> Second, in order to do annotations "right" in such a way that two independent project don't have annotation semantics >> that fail to interoperate, everyone needs to agree on some system. If one library expects the annotations to be strings >> (or to mean a specific thing, like a type for typechecking) and another library expects something different, then everyone is >> in a bad spot. PEP3107 seems to want some convention to "develop organically". As the author of the PEP said on >> Python-ideas: >> >>> When the first big project like Zope or Twisted announces that "we will do >>> annotation interop like so...", everyone else will be pressured to >>> line up behind them. >>> I don't want to pick a mechanism, only to have to roll >>> another release when Zope or Twisted or some other big project pushes >>> out their own solution. >> But, on the other hand, maybe there's no time like the present to start, and although the PEP was finalized in 2010, >> and it doesn't seem like Django or any other big package is using annotations, so maybe we should lead the way? > > This is exactly the point I was trying to make. Unless I'm mistaken, no one in the scientific python community uses annotations yet. IPython is the perfect project to start to standardize it for this community, and hopefully push other communities as well. > >> >> In that spirit, I propose two possible schemes for annotation interoperability: >> >> (1) All the annotations should be dicts. That way we can put tab-complete specific stuff under the 'tab' key and other >> libraries/features can put their stuff under a different key, like 'type' or what have you. One advantage are that it's >> simple. On the other hand, its kind of verbose, and IMO ugly. >> >> def my_io(fname, mode : {'tab': ['read', 'write']}): >> pass >> >> def my_io(fname, mode : {'tab': ['read', 'write'], 'foo':'bar'}): >> pass >> > > I like this idea. In general, the elements of the list would be TabCompletion objects that describe arbitrary tab completions (e.g., files in the current directory). > >> (2). Inspired by ggplot, where you compose plots by summing components, the annotations could be the sum of >> objects that overload __add__, like: >> >> def my_io(fname, mode : tab('read', 'write')) >> pass >> >> or >> >> def my_io(fname, mode : tab('read', 'write') + typecheck(str)): >> pass >> >> Where tab and typecheck are something like: >> >> class tab(object): >> def __init__(self, *args, **kwargs): >> self.args = args >> self.kwargs = kwargs >> self.next = None >> self.prev = None >> >> def __add__(self, other): >> if not hasattr(other, '__add__'): >> raise ValueError('"{}" must also be composable'.format(other)) >> self.next = other >> other.prev = self >> return other >> >> Then you could basically recover something analogous to the dictionary in proposal one >> by walking through the next/prev pointers. The advantages of this are chiefly visual. > > You could actually make this identical to option 1 by subclassing dict and overriding __add__. > > I'm not sure it's necessary for most libraries, though. If you want simple syntax, just write a simple helper function so you can just do mode: tab(["read", "write"]), where tab(a) returns {'tab': a}. > > But if you just require the API __annotations__["arg"]['tab'], it doesn't matter if you use a dict or a custom object. > > Aaron Meurer > >> >> Obviously other things like lists or tuples or generic iterables could be done too. >> >> def my_io(fname, mode : (tab('read', 'write'), typecheck(str))): >> pass >> >> or >> >> def my_io(fname, mode : [tab('read', 'write'), typecheck(str)]): >> pass >> >> With some cleverness, it might be possible to add an __iter__ method to the tab class that >> would let you turn the sum into a list via list(iterable), such that via polymorphism the ggplot >> style and the tuple/list style could exist side-by-side. >> >> Basically, IMHO, using function annotation system requires some serious thought -- probably >> above my pay grade -- to do right. >> >> (Sorry this email was so long) >> >> -Robert >> >> On Nov 29, 2012, at 6:38 AM, Tom Dimiduk wrote: >> >>> That looks pretty great. I would use something like that. >>> >>> For the filename('.txt'), it could be handy to be able to pass arbitrary globs (as in for glob.glob). You could still default to matching against the end of the string for extensions, but adding the glob support costs little (since you probably want to use glob internally anyway. >>> >>> For extra (and unnecessary) fancyness, I could also see use cases for >>> from from tablib import tabcompletion, instance >>> class bar: >>> pass >>> @tabcompletion(foo=instance(bar)) >>> to be able to only complete for specific types of objects for other parameters (it would do an isinstance test). >>> >>> Even more bonus points if the decorator could parse numpy styled docstrings to grab that kind of information about parameters. I guess at this point you could do type checking, file existence checking, and a variety of other fun stuff there as well once you have that information, but that is almost certainly going out of the scope of your proposal. >>> >>> Sorry if I am growing your proposal too much, the basic thing you proposed would still be very useful. If I can grab some spare mental cycles, I would collaborate with you on it if you end up writing it. >>> >>> Tom >>> >>> On 11/29/2012 05:28 AM, Robert McGibbon wrote: >>>> Hi, >>>> >>>> Good spot, Matthias. I didn't see that method was already exposed -- I was just looking at IPCompleter.matchers, which what that method inserts into. >>>> >>>> Annotations are cool, but they're not obviously composable. I worry that if I use them for this and then fix one syntax of how the annotation is parsed, and somebody else >>>> is using annotations in their lib for something else, the two schemes won't be able to interoperate. Also they're py3k only. >>>> >>>> My preferred syntax would be >>>> >>>> from tablib import tabcompletion, filename, >>>> >>>> @tabcompletion(fname=filename, mode=['r', 'w']) >>>> def load(fname, mode, other_argument): >>>> pass >>>> >>>> or maybe with a parameterized filename to get specific extensions >>>> >>>> @tabcompletion(fname=filename('.txt')) >>>> def f(fname, other_argument): >>>> pass >>>> >>>> Is this something that other people would be interested in? >>>> >>>> -Robert >>>> >>>> On Nov 29, 2012, at 2:02 AM, Matthias BUSSONNIER wrote: >>>> >>>>> Hi, >>>>> >>>>> I may be wrong, but IIRC you can insert your own completer in the IPython completer chain and decide to filter the previous completion. >>>>> >>>>> You should be able to have a custom completer that just forward the previous completion in most cases, >>>>> And just do a dir completion if the object is np.loadtxt in your case (or look at __annotations__ if you wish). >>>>> >>>>> I've found one reference to inserting custom completer here >>>>> http://ipython.org/ipython-doc/dev/api/generated/IPython.core.interactiveshell.html?highlight=interactiveshell#IPython.core.interactiveshell.InteractiveShell.set_custom_completer >>>>> >>>>> >>>>> -- >>>>> Matthias >>>>> >>>>> Le 29 nov. 2012 ? 10:27, Aaron Meurer a ?crit : >>>>> >>>>>> I've often thought this as well. Probably a full-blown IPEP is in >>>>>> order here. Perhaps __annotations__ would be the correct way to go >>>>>> here. >>>>>> >>>>>> Aaron Meurer >>>>>> >>>>>> On Thu, Nov 29, 2012 at 12:58 AM, Robert McGibbon wrote: >>>>>>> Hey, >>>>>>> >>>>>>> Tab completion in IPython is one of the things that makes it so useful, >>>>>>> especially the context specific tab completion for things like "from ..." >>>>>>> where only packages, or obviously the special completion for attributes when >>>>>>> the line contains a dot. >>>>>>> >>>>>>> I use IPython for interactive data analysis a lot, and one of the most >>>>>>> frequent operations is loading up data with something like numpy.loadtxt() >>>>>>> or various related functions. >>>>>>> >>>>>>> It would be really awesome if we could annotate functions to interact with >>>>>>> the tab completion system, perhaps for instance saying that argument 0 to >>>>>>> numpy.loadtxt() is supposed to be a filename, so let's give tab-complete >>>>>>> suggestions that try to look for directories/files. Some functions only >>>>>>> files with specific extensions, so you could filter based on that or >>>>>>> whatever. >>>>>>> >>>>>>> By hacking on the code for completerlib.py:cd_completer, I sketched out a >>>>>>> little demo of what you could do with this: https://gist.github.com/4167151. >>>>>>> The architecture is totally wrong, but it lets you get behavior like: >>>>>>> >>>>>>> ``` >>>>>>> In [1]: ls >>>>>>> datfile.dat dir1/ dir2/ file.gz random_junk test.py >>>>>>> >>>>>>> In [2]: directory_as_a_variable = 'sdfsfsd' >>>>>>> >>>>>>> In [3]: f = np.loadtxt( >>>>>>> datfile.dat dir1/ dir2/ file.gz >>>>>>> >>>>>>> In [4]: normal_function( >>>>>>> Display all 330 possibilities? (y or n) >>>>>>> >>>>>>> In [5]: g = np.loadtxt(di >>>>>>> dict dir1/ directory_as_a_variable >>>>>>> divmod >>>>>>> dir dir2/ directory_of_my_choosing >>>>>>> ``` >>>>>>> >>>>>>> Basically hitting the tab completion, when np.loadtxt is on the input line, >>>>>>> only shows directories and files that end with a certain extension. If you >>>>>>> start to type in the name of an object in your namespace, it'll show up too, >>>>>>> but only once you've typed in more than 1 matching character. >>>>>>> >>>>>>> The implementation in my gist is pretty lame. The way I've coded it up, the >>>>>>> special behavior is based on simply finding the string "np.loadtxt" on the >>>>>>> input line, not on the actual function. This means you can't really make the >>>>>>> behavior specific to your position in the argument list (i.e. I know that >>>>>>> the first arg is a filename, and so should be tab completed like this, but >>>>>>> the other ones are not). I suspect the right way to do the implementation is >>>>>>> via function decorators to specify the behavior and then adding to >>>>>>> IPCompleter instead. >>>>>>> >>>>>>> I think I'm up for giving this a shot. >>>>>>> >>>>>>> Thoughts? Is this a feature anyone else would find interesting? >>>>>>> >>>>>>> -Robert >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 > _______________________________________________ > 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 Fri Nov 30 18:51:32 2012 From: takowl at gmail.com (Thomas Kluyver) Date: Fri, 30 Nov 2012 23:51:32 +0000 Subject: [IPython-dev] Function specific hooks into the ipython tab completion system In-Reply-To: References: <96A177C3-9E59-44BD-8268-52F802E12C37@gmail.com> <357B7D49-C7B4-413A-A530-AA8F63EA79BF@gmail.com> <669615BA-66DA-4CA6-8848-ED64BC4E3710@gmail.com> <50B77355.8050404@physics.harvard.edu> <0B0DB9F0-4400-43CA-8BCD-EA2DEA7CE1FE@gmail.com> <3384313335217771310@unknownmsgid> Message-ID: On 30 November 2012 23:47, Robert McGibbon wrote: > If someone else wants to try to get this discussion going in the wider > python community, I'm all ears. But I don't > think that person is going to be me. > I might do that. Thanks for your thoughts - I look forward to seeing the results. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From pivanov314 at gmail.com Fri Nov 30 18:52:15 2012 From: pivanov314 at gmail.com (Paul Ivanov) Date: Fri, 30 Nov 2012 15:52:15 -0800 Subject: [IPython-dev] [nbconvert] Reining in the number of constructor arguments In-Reply-To: References: Message-ID: On Fri, Nov 30, 2012 at 3:05 PM, David Warde-Farley wrote: > I'm wondering how to solve (and how you guys think I should solve) a > certain problem I foresee, of a potentially rapidly growing number of > constructor arguments for Converter classes, which need to be > maintained across constructors in order to keep the front-end calling > code generic (one could use *args and **kwargs catch-alls but that's > pretty ugly). I don't think it's ugly - I think it's the right way to do it. It allows one to easily add keyword arguments to all of the subclasses of Converter, for example, by writing the relevant code only in one place. See the --stdout flag I've proposed in https://github.com/ipython/nbconvert/pull/62 > A pull request that @Jovani started and I have finished off adds a > highlight_source argument to the constructors for all of the classes. > I have some features in mind that control fine-grained output > behavior. Passing these as either positional or keyword arguments > requires every other Converter class to know about every possible > argument, which is a maintenance nightmare, and doesn't necessarily > make sense: part of the problem is that not every backend even > *supports* all of the options, e.g. the ConverterPy can't highlight > source in code blocks because that doesn't make any sense in terms of > the output type. And for this reason, that flag should not be exposed globally, the same way that all possible flags to ipython notebook aren't exposed when one does just "ipython --help". The solution I think makes sense is to have formatter specific flags be exposed only when a specific formatter is selected. So `nbconvert -f html -h` should show --highlight-source as an option, whereas `nbconvert -f py -h` should not. > My thought on solving this goes something like this: > - on the front-end, delegate all but very core functions that are > backend-agnostic to a sub-parser > - on the back-end, have either the "namespace" object produced by > argparse or a dictionary constructed from it passed as a *single* > argument to the constructor. > - have each class examine this namespace The nice thing about kwargs is that it's evident from the method signature where they are being used, whereas passing around an opaque "namespace" object as a single argument doesn't really buy you anything, since **kwarg is a single argument, anyway ;) But I haven't thought about this very carefully yet. > Questions: > - Should a backend that can't highlight source, or perform optional > function X, raise an error, a warning, or fail silently? My gut says > warning is the right balance of informative and yet annoying. (should > I use the warnings module, logging.warn, ...?) I think it should fail, the same way `ipython -X` fails with [TerminalIPythonApp] Bad config encountered during initialization: [TerminalIPythonApp] Unrecognized flag: '-X' > This raises one problem, though, in that some defaults as per argparse > will raise warnings automatically in some backends, e.g. without > --no-highlight, the default argument of `True` will raise a warning > when the output type is a Python script. > > A possible solution: make argparse's default be 'None' for options > even when True/False is the default. Have converter classes expose a > class-level `config_defaults` dict, where values are 2-tuples: > (default value, legal_values), which the class uses to address its > configuration needs for things that come up as None in the > configuration object passed in, and raise warnings for invalid values > where appropriate. > > Thoughts? Am I off my rocker? In summary, I think it would be annoying to expose all of the flags that don't apply to all the converters globally. If the Converter base class accepts it as a flag, we have it show up in the docs, whereas formatter specific flags should only show up in the help printout for specific formatters. best, -- Paul Ivanov 314 address only used for lists, off-list direct email at: http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 From rmcgibbo at gmail.com Fri Nov 30 18:55:18 2012 From: rmcgibbo at gmail.com (Robert McGibbon) Date: Fri, 30 Nov 2012 15:55:18 -0800 Subject: [IPython-dev] Function specific hooks into the ipython tab completion system In-Reply-To: References: <96A177C3-9E59-44BD-8268-52F802E12C37@gmail.com> <357B7D49-C7B4-413A-A530-AA8F63EA79BF@gmail.com> <669615BA-66DA-4CA6-8848-ED64BC4E3710@gmail.com> <50B77355.8050404@physics.harvard.edu> <0B0DB9F0-4400-43CA-8BCD-EA2DEA7CE1FE@gmail.com> <3384313335217771310@unknownmsgid> Message-ID: Awesome. Keep me in the loop! I'm happy to play a support role. -Robert On Nov 30, 2012, at 3:51 PM, Thomas Kluyver wrote: > On 30 November 2012 23:47, Robert McGibbon wrote: > If someone else wants to try to get this discussion going in the wider python community, I'm all ears. But I don't > think that person is going to be me. > > I might do that. Thanks for your thoughts - I look forward to seeing the results. > > 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 d.warde.farley at gmail.com Fri Nov 30 19:26:17 2012 From: d.warde.farley at gmail.com (David Warde-Farley) Date: Fri, 30 Nov 2012 19:26:17 -0500 Subject: [IPython-dev] [nbconvert] Reining in the number of constructor arguments In-Reply-To: References: Message-ID: On Fri, Nov 30, 2012 at 6:44 PM, Thomas Kluyver wrote: > On 30 November 2012 23:05, David Warde-Farley > wrote: >> >> I'm wondering how to solve (and how you guys think I should solve) a >> certain problem I foresee, of a potentially rapidly growing number of >> constructor arguments for Converter classes, which need to be >> maintained across constructors in order to keep the front-end calling >> code generic (one could use *args and **kwargs catch-alls but that's >> pretty ugly). > > > I may be barking up the wrong tree, but instead of constructor arguments, > would it make sense to simply set attributes on the converter, e.g. > > conv = HTMLConverter() > conv.highlight_source = False Somehow, I didn't think of this. This is fairly elegant. I'll have to think about this in a background thread over dinner. Thanks, David From d.warde.farley at gmail.com Fri Nov 30 19:34:12 2012 From: d.warde.farley at gmail.com (David Warde-Farley) Date: Fri, 30 Nov 2012 19:34:12 -0500 Subject: [IPython-dev] [nbconvert] Reining in the number of constructor arguments In-Reply-To: References: Message-ID: On Fri, Nov 30, 2012 at 6:52 PM, Paul Ivanov wrote: > On Fri, Nov 30, 2012 at 3:05 PM, David Warde-Farley > wrote: >> I'm wondering how to solve (and how you guys think I should solve) a >> certain problem I foresee, of a potentially rapidly growing number of >> constructor arguments for Converter classes, which need to be >> maintained across constructors in order to keep the front-end calling >> code generic (one could use *args and **kwargs catch-alls but that's >> pretty ugly). > > I don't think it's ugly - I think it's the right way to do it. It allows > one to easily add keyword arguments to all of the subclasses of > Converter, for example, by writing the relevant code only in one place. > See the --stdout flag I've proposed in > https://github.com/ipython/nbconvert/pull/62 The annoying thing about it is that it makes introspection harder. The generated docs and the obj? help in IPython end up telling less of the story, and if the docstring is not kept up to snuff there's no canary in the mine. >> Passing these as either positional or keyword arguments >> requires every other Converter class to know about every possible >> argument, which is a maintenance nightmare, and doesn't necessarily >> make sense: part of the problem is that not every backend even >> *supports* all of the options, e.g. the ConverterPy can't highlight >> source in code blocks because that doesn't make any sense in terms of >> the output type. > > And for this reason, that flag should not be exposed globally, the same > way that all possible flags to ipython notebook aren't exposed when one > does just "ipython --help". > > The solution I think makes sense is to have formatter specific flags be > exposed only when a specific formatter is selected. > > So `nbconvert -f html -h` should show --highlight-source as an option, > whereas `nbconvert -f py -h` should not. So a separate, delegated parser for each output mode is the way to go, you think? It seems like the right place for this code would be in a class method attached to each Converter class. Then nbconvert.py could iterate over the classes it knows about and call cls.cli_argument_parser(), and add that to the global one. > The nice thing about kwargs is that it's evident from the method > signature where they are being used, whereas passing around an opaque > "namespace" object as a single argument doesn't really buy you anything, > since **kwarg is a single argument, anyway ;) > > But I haven't thought about this very carefully yet. > >> Questions: >> - Should a backend that can't highlight source, or perform optional >> function X, raise an error, a warning, or fail silently? My gut says >> warning is the right balance of informative and yet annoying. (should >> I use the warnings module, logging.warn, ...?) > > I think it should fail, the same way `ipython -X` fails with > > [TerminalIPythonApp] Bad config encountered during initialization: > [TerminalIPythonApp] Unrecognized flag: '-X' Okay, didn't realize there was precedent. Thanks. > In summary, I think it would be annoying to expose all of the flags that > don't apply to all the converters globally. If the Converter base class > accepts it as a flag, we have it show up in the docs, whereas formatter > specific flags should only show up in the help printout for specific > formatters. Yes, that sounds like a better solution. Cheers, David From pivanov314 at gmail.com Fri Nov 30 20:04:53 2012 From: pivanov314 at gmail.com (Paul Ivanov) Date: Fri, 30 Nov 2012 17:04:53 -0800 Subject: [IPython-dev] [nbconvert] Reining in the number of constructor arguments In-Reply-To: References: Message-ID: On Fri, Nov 30, 2012 at 4:34 PM, David Warde-Farley wrote: > On Fri, Nov 30, 2012 at 6:52 PM, Paul Ivanov wrote: >> On Fri, Nov 30, 2012 at 3:05 PM, David Warde-Farley >> wrote: > > The annoying thing about it is that it makes introspection harder. The > generated docs and the obj? help in IPython end up telling less of the > story, and if the docstring is not kept up to snuff there's no canary > in the mine. Well, the inheritance would be made clear, and a dev could follow that. One could argue in the other direction - what if I want to know *only* the arguments that are unique to a given converter subclass, and not all of the arguments it "inherited" (in some manner, whether by virtue of subclassing or de-facto having the same paramters used in multiple places). >>> Passing these as either positional or keyword arguments >>> requires every other Converter class to know about every possible >>> argument, which is a maintenance nightmare, and doesn't necessarily >>> make sense: part of the problem is that not every backend even >>> *supports* all of the options, e.g. the ConverterPy can't highlight >>> source in code blocks because that doesn't make any sense in terms of >>> the output type. >> >> And for this reason, that flag should not be exposed globally, the same >> way that all possible flags to ipython notebook aren't exposed when one >> does just "ipython --help". >> >> The solution I think makes sense is to have formatter specific flags be >> exposed only when a specific formatter is selected. >> >> So `nbconvert -f html -h` should show --highlight-source as an option, >> whereas `nbconvert -f py -h` should not. > > So a separate, delegated parser for each output mode is the way to go, > you think? > > It seems like the right place for this code would be in a class method > attached to each Converter class. Then nbconvert.py could iterate over the > classes it knows about and call cls.cli_argument_parser(), and add that to > the global one. yes, this is along the lines of my thinking as well, and since all our converters subclass from Converter, it's easy to ensure that they all have such a method ;). The iteration over classes would only be need in the case where the user wanted all possible flags, whereas I'd argue getting only the converter class which is implied by the --format argument would be sufficient in the simple -h case. >> I think it should fail, the same way `ipython -X` fails with >> >> [TerminalIPythonApp] Bad config encountered during initialization: >> [TerminalIPythonApp] Unrecognized flag: '-X' > > Okay, didn't realize there was precedent. Thanks. >From a perspective of a user, it's better to get an error in this case rather having to somehow guess whether --some-random-flag has any effect or not. Warnings are easier to miss, since suppose you do a run but had a typo for one of the parameters, and *some* result is produced, but it doesn't reflect the effect of the flag that you had a typo in. Now you sort of have to go back and figure out what actually happend. Another precedent, as an example is the -j flag, at least for GNU's ls $ ls -j ls: invalid option -- 'j' Try 'ls --help' for more information. better, -- Paul Ivanov 314 address only used for lists, off-list direct email at: http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7