From dave.hirschfeld at gmail.com Wed May 1 06:00:14 2013 From: dave.hirschfeld at gmail.com (Dave Hirschfeld) Date: Wed, 1 May 2013 10:00:14 +0000 (UTC) Subject: [IPython-dev] Cell Magics Broken in QtConsole? Message-ID: No combination of enter, shift-enter or even ctrl-enter will seem to exit a cell magic in the qtconsole with the latest ipython. Is anyone else seeing this behaviour? In [15]: print sys_info() {'commit_hash': 'ddc8bac', 'commit_source': 'repository', 'default_encoding': 'cp1252', 'ipython_path': 'c:\\dev\\code\\ipython\\IPython', 'ipython_version': '1.0.dev', 'os_name': 'nt', 'platform': 'Windows-7-6.1.7601-SP1', 'sys_executable': 'C:\\dev\\bin\\Python27\\python.exe', 'sys_platform': 'win32', 'sys_version': '2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)]'} In [16]: %%timeit ...: x = 10 ...: y = 2*x ...: ...: ...: ...: <======= Can't get it to exit!?! Thanks, Dave From takowl at gmail.com Wed May 1 07:42:39 2013 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 1 May 2013 12:42:39 +0100 Subject: [IPython-dev] Cell Magics Broken in QtConsole? In-Reply-To: References: Message-ID: Yes, I can replicate that. Sorry, I probably broke it by accident while fixing issue #3178. I've made an issue, I'll try to get to it soon: https://github.com/ipython/ipython/issues/3248 Thomas On 1 May 2013 11:00, Dave Hirschfeld wrote: > No combination of enter, shift-enter or even ctrl-enter will seem to exit a > cell magic in the qtconsole with the latest ipython. > > Is anyone else seeing this behaviour? > > > In [15]: print sys_info() > {'commit_hash': 'ddc8bac', > 'commit_source': 'repository', > 'default_encoding': 'cp1252', > 'ipython_path': 'c:\\dev\\code\\ipython\\IPython', > 'ipython_version': '1.0.dev', > 'os_name': 'nt', > 'platform': 'Windows-7-6.1.7601-SP1', > 'sys_executable': 'C:\\dev\\bin\\Python27\\python.exe', > 'sys_platform': 'win32', > 'sys_version': '2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit > (Intel)]'} > > In [16]: %%timeit > ...: x = 10 > ...: y = 2*x > ...: > ...: > ...: > ...: <======= Can't get it to exit!?! > > > Thanks, > Dave > > _______________________________________________ > 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 Wed May 1 07:49:06 2013 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 1 May 2013 12:49:06 +0100 Subject: [IPython-dev] IPython integrated in Light Table Message-ID: Always good to hear of people using IPython: Light Table's new Python integration uses IPython 'for a better overall experience' if it's installed. That includes inline plots in the editor. http://www.chris-granger.com/2013/04/28/light-table-040/ Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From jtratner at gmail.com Wed May 1 15:49:55 2013 From: jtratner at gmail.com (Jeffrey Tratner) Date: Wed, 1 May 2013 15:49:55 -0400 Subject: [IPython-dev] How to hook js plugins into IPython Notebook Message-ID: Hi all, I'd like to write a js plugin for IPython Notebook, but I'm not clear on what can be hooked into the interface. Specifically, I'd like to do the following: 1. Add an item to the menu. 2. Add another keyboard shortcut. [and also if there already exist hooks to register event listeners, etc. -- clearly it's not difficult to add another event listener for keyboard shortcuts, but I'd like the plugin to be well behaved]. 3. Persist classes, IDs or data attributes into the notebook format between sessions. Also, can I count on `$` / `jQuery` being available going forward? I'm happy to read docs on this and experiment myself, but I haven't found anything that answers the above so far. I'm currently reading through the ipython/jsplugins repo, but any tips on where to look or what to hook into would be very appreciated. I really love the notebook format - thank you all for making that happen! Best, Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Wed May 1 15:58:15 2013 From: ellisonbg at gmail.com (Brian Granger) Date: Wed, 1 May 2013 12:58:15 -0700 Subject: [IPython-dev] How to hook js plugins into IPython Notebook In-Reply-To: References: Message-ID: Jeff, The short answer is that we are not quite there yet. The code in the jsplugins repo is only experimental and the final API will probably look different from that. We have plens to start work on this part of IPython in July, but it is going to be probably into the Fall before we have something tnat is ready to play with. In the meantime, the way we are encouraging users to add additional JS to the notebook is by creating a custom.js file in your profile_dir/js/static. It will be loaded onto the page and you can access all of our JS objects. Yes, you can count on jQuery/$ being available. Cheers, Brian On Wed, May 1, 2013 at 12:49 PM, Jeffrey Tratner wrote: > Hi all, > > I'd like to write a js plugin for IPython Notebook, but I'm not clear on > what can be hooked into the interface. Specifically, I'd like to do the > following: > > > 1. Add an item to the menu. > 2. Add another keyboard shortcut. [and also if there already exist hooks to > register event listeners, etc. -- clearly it's not difficult to add another > event listener for keyboard shortcuts, but I'd like the plugin to be well > behaved]. > 3. Persist classes, IDs or data attributes into the notebook format between > sessions. > > Also, can I count on `$` / `jQuery` being available going forward? > > I'm happy to read docs on this and experiment myself, but I haven't found > anything that answers the above so far. I'm currently reading through the > ipython/jsplugins repo, but any tips on where to look or what to hook into > would be very appreciated. > > I really love the notebook format - thank you all for making that happen! > > Best, > > Jeff > > _______________________________________________ > 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 jtratner at gmail.com Wed May 1 16:01:47 2013 From: jtratner at gmail.com (Jeffrey Tratner) Date: Wed, 1 May 2013 16:01:47 -0400 Subject: [IPython-dev] How to hook js plugins into IPython Notebook In-Reply-To: References: Message-ID: Okay, it sounds like I should wait until you all are finished in the Fall to do any extensive work on plugins. Thanks for getting back to me, Jeff On Wed, May 1, 2013 at 3:58 PM, Brian Granger wrote: > Jeff, > > The short answer is that we are not quite there yet. The code in the > jsplugins repo is only experimental and the final API will probably > look different from that. We have plens to start work on this part of > IPython in July, but it is going to be probably into the Fall before > we have something tnat is ready to play with. In the meantime, the > way we are encouraging users to add additional JS to the notebook is > by creating a custom.js file in your profile_dir/js/static. It will > be loaded onto the page and you can access all of our JS objects. > Yes, you can count on jQuery/$ being available. > > Cheers, > > Brian > > On Wed, May 1, 2013 at 12:49 PM, Jeffrey Tratner > wrote: > > Hi all, > > > > I'd like to write a js plugin for IPython Notebook, but I'm not clear on > > what can be hooked into the interface. Specifically, I'd like to do the > > following: > > > > > > 1. Add an item to the menu. > > 2. Add another keyboard shortcut. [and also if there already exist hooks > to > > register event listeners, etc. -- clearly it's not difficult to add > another > > event listener for keyboard shortcuts, but I'd like the plugin to be well > > behaved]. > > 3. Persist classes, IDs or data attributes into the notebook format > between > > sessions. > > > > Also, can I count on `$` / `jQuery` being available going forward? > > > > I'm happy to read docs on this and experiment myself, but I haven't found > > anything that answers the above so far. I'm currently reading through the > > ipython/jsplugins repo, but any tips on where to look or what to hook > into > > would be very appreciated. > > > > I really love the notebook format - thank you all for making that happen! > > > > Best, > > > > Jeff > > > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Wed May 1 19:12:22 2013 From: ellisonbg at gmail.com (Brian Granger) Date: Wed, 1 May 2013 16:12:22 -0700 Subject: [IPython-dev] A few notes on IPEPs Message-ID: Hi, Our usage of IPEPs is going really well - they are quickly becoming a useful way of working out and documenting the design of larger features. I have updated the main IPEP page with improved guidelines: https://github.com/ipython/ipython/wiki/IPEPs:-IPython-Enhancement-Proposals Some of the main points: * Let's open an issue for each IPEP and use that to track the discussion and implementation. * Let's add a table to the top of each IPEP that tracks its basic information and status. I wanted to encourage everyone to revisit the IPEPs you have authored and check on the following: * Make sure the IPEP is updated to reflect the current state of the discussion and implementation. * Add the table at the top of the IPEP with the basic information (see the index page for an example) * Make sure the table has an updated status - we might eventually want to add the status to the main IPEP index so we can see the status of each of them easily. Cheers, Brian -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From asmeurer at gmail.com Wed May 1 20:12:32 2013 From: asmeurer at gmail.com (Aaron Meurer) Date: Wed, 1 May 2013 18:12:32 -0600 Subject: [IPython-dev] A few notes on IPEPs In-Reply-To: References: Message-ID: Can you give definitions for the various statuses? Does "Accepted" mean "implemented"? The regular Python PEPs have a lot more statuses (see http://www.python.org/dev/peps/pep-0001/). Aaron Meurer On Wed, May 1, 2013 at 5:12 PM, Brian Granger wrote: > Hi, > > Our usage of IPEPs is going really well - they are quickly becoming a > useful way of working out and documenting the design of larger > features. I have updated the main IPEP page with improved guidelines: > > https://github.com/ipython/ipython/wiki/IPEPs:-IPython-Enhancement-Proposals > > Some of the main points: > > * Let's open an issue for each IPEP and use that to track the > discussion and implementation. > * Let's add a table to the top of each IPEP that tracks its basic > information and status. > > I wanted to encourage everyone to revisit the IPEPs you have authored > and check on the following: > > * Make sure the IPEP is updated to reflect the current state of the > discussion and implementation. > * Add the table at the top of the IPEP with the basic information (see > the index page for an example) > * Make sure the table has an updated status - we might eventually want > to add the status to the main IPEP index so we can see the status of > each of them easily. > > Cheers, > > Brian > > -- > Brian E. Granger > Cal Poly State University, San Luis Obispo > bgranger at calpoly.edu and ellisonbg at gmail.com > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From ellisonbg at gmail.com Wed May 1 20:27:33 2013 From: ellisonbg at gmail.com (Brian Granger) Date: Wed, 1 May 2013 17:27:33 -0700 Subject: [IPython-dev] A few notes on IPEPs In-Reply-To: References: Message-ID: I didn't want to get too formal, but we probably want a separate Implemented status and keep "Accepted" to mean "we plan on doing this as described, but haven't. Updating the wiki... Cheers, Brian On Wed, May 1, 2013 at 5:12 PM, Aaron Meurer wrote: > Can you give definitions for the various statuses? Does "Accepted" > mean "implemented"? The regular Python PEPs have a lot more statuses > (see http://www.python.org/dev/peps/pep-0001/). > > Aaron Meurer > > On Wed, May 1, 2013 at 5:12 PM, Brian Granger wrote: >> Hi, >> >> Our usage of IPEPs is going really well - they are quickly becoming a >> useful way of working out and documenting the design of larger >> features. I have updated the main IPEP page with improved guidelines: >> >> https://github.com/ipython/ipython/wiki/IPEPs:-IPython-Enhancement-Proposals >> >> Some of the main points: >> >> * Let's open an issue for each IPEP and use that to track the >> discussion and implementation. >> * Let's add a table to the top of each IPEP that tracks its basic >> information and status. >> >> I wanted to encourage everyone to revisit the IPEPs you have authored >> and check on the following: >> >> * Make sure the IPEP is updated to reflect the current state of the >> discussion and implementation. >> * Add the table at the top of the IPEP with the basic information (see >> the index page for an example) >> * Make sure the table has an updated status - we might eventually want >> to add the status to the main IPEP index so we can see the status of >> each of them easily. >> >> Cheers, >> >> Brian >> >> -- >> 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 > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From ellisonbg at gmail.com Thu May 2 00:38:29 2013 From: ellisonbg at gmail.com (Brian Granger) Date: Wed, 1 May 2013 21:38:29 -0700 Subject: [IPython-dev] Major reorg of notebook code Message-ID: Hi, I wanted to let everyone know that over the next few days I will be doing a major refactor of everything in the notebook subpackage. This includes all js/html/css/less files being moved into new locations and edited. Because of this, please wait until this work is merge before doing any new work on the notebook. Will post back here with updates. Cheers, Brian -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From dave.hirschfeld at gmail.com Thu May 2 04:40:47 2013 From: dave.hirschfeld at gmail.com (Dave Hirschfeld) Date: Thu, 2 May 2013 08:40:47 +0000 (UTC) Subject: [IPython-dev] submodules over https Message-ID: If you're behind a firewall or otherwise can't use the git protocol but instead use https access you may get an error message similar to below when trying to update to the latest IPython: updating git submodules Submodule 'components' (git://github.com/ipython/ipython-components.git) registered for path 'IPython/frontend/html/notebook/stat ic/components' Cloning into 'IPython/frontend/html/notebook/static/components'... fatal: unable to connect to github.com: github.com[0: 204.232.175.90]: errno=No error Clone of 'git://github.com/ipython/ipython-components.git' into submodule path 'IPython/frontend/html/notebook/static/components' failed Traceback (most recent call last): File "setupegg.py", line 6, in execfile('setup.py') File "setup.py", line 129, in ensure_submodules_exist() File "setup.py", line 127, in ensure_submodules_exist update_submodules() File "C:\dev\code\ipython\setupbase.py", line 396, in update_submodules subprocess.check_call('git submodule update --recursive'.split()) File "C:\dev\bin\Python27\lib\subprocess.py", line 511, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['git', 'submodule', 'update', '-- recursive']' returned non-zero exit status 1 To fix this you'll need to edit your config file which can be found in the top-level .git folder. The [submodule "components"] section which looks like: [submodule "components"] url = git://github.com/ipython/ipython-components.git ...needs to be changed to: [submodule "components"] url = https://github.com/ipython/ipython-components.git If you immediately try to update the submodules you'll likely get the following error: C:\dev\code\ipython [master +1 ~0 -0 !]> git submodule update --recursive fatal: Needed a single revision Unable to find current revision in submodule path 'IPython/frontend/html/notebook/static/components' Translated, this means that there's a failed submodules checkout blocking the update and you need to delete the IPython\frontend\html\notebook\static\components directory. After that the error message you get will change to: C:\dev\code\ipython [master +1 ~0 -1 !]> git submodule update --recursive fatal: unable to connect to github.com: github.com[0: 204.232.175.90]: errno=No error Unable to fetch in submodule path 'IPython/frontend/html/notebook/static/components' ...which means you need to edit the config file for the specific submodule, in this case it can be found in the .git\modules\components\config directory. The [remote "origin"] section which looks like: [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* url = git://github.com/ipython/ipython-components.git ...needs to be changed to: [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* url = https://github.com/ipython/ipython-components.git After all this it should hopefully work! Since this is a bit of a hassle it might be nice if the https url could be used by default for submodules as I assume it will just work for everyone and anyone who cares is probably the most capable of switching it back. HTH, Dave From zvoros at gmail.com Thu May 2 04:52:42 2013 From: zvoros at gmail.com (=?ISO-8859-1?Q?Zolt=E1n_V=F6r=F6s?=) Date: Thu, 02 May 2013 10:52:42 +0200 Subject: [IPython-dev] can't run ipython with profile Message-ID: <5182295A.1080800@gmail.com> Hi all, I am not entirely sure, whether this problem is related to development, but since the it occurred after I checked out the latest version from github, I assume that to be the case. Whenever I try to run ipython with a profile, the kernel refuses to start. (Without profile, everything seems to be working.) Here is the traceback: Traceback (most recent call last): File "/home/v923z/sandbox/ipython/dev/ipython/ipython.py", line 21, in from setupbase import check_for_submodules, update_submodules File "/home/v923z/sandbox/ipython/dev/ipython/setupbase.py", line 75, in execfile(pjoin('IPython','core','release.py'), globals()) IOError: [Errno 2] No such file or directory: 'IPython/core/release.py' (By the way, the file release.py is on my system.) During checkout, I got the following message: OPTIONAL DEPENDENCIES sphinx: 1.1.3 pygments: 1.5 nose: Not found (required for running the test suite) pexpect: 2.4 pyzmq: 2.2.0.1 readline: yes running install running build running build_py submodules missing! Run `setup.py submodule` and try again and when I tried to run setup.py submodule, I ended up with this: running submodule git submodule init Submodule 'components' () registered for path 'IPython/frontend/html/notebook/static/components' git submodule update --recursive submodules could not be checked out I wonder whether this problem can be duplicated on other systems, and what steps I should take to shoot the trouble. Cheers, Zolt?n From dave.hirschfeld at gmail.com Thu May 2 06:42:57 2013 From: dave.hirschfeld at gmail.com (Dave Hirschfeld) Date: Thu, 2 May 2013 10:42:57 +0000 (UTC) Subject: [IPython-dev] submodules over https References: Message-ID: Dave Hirschfeld gmail.com> writes: > > After all this it should hopefully work! > > HTH, > Dave > It seems there's a typo in setupbase.py https://github.com/ipython/ipython/blob/master/setupbase.py#L384 I'm assuming that 'external' should in fact be 'components' With this change I can compile & run the latest IPython. HTH, Dave From aron at ahmadia.net Thu May 2 06:55:19 2013 From: aron at ahmadia.net (Aron Ahmadia) Date: Thu, 2 May 2013 11:55:19 +0100 Subject: [IPython-dev] submodules over https In-Reply-To: References: Message-ID: Hi Dave, I just noticed that the submodule URLs are hardcoded instead of relative: https://github.com/ipython/ipython/blob/master/.gitmodules#L3 Can you check that if you do a non-recursive checkout, then modify this line in the top-level .gitmodule file from: url = git://github.com/ipython/ipython-components.git url = ../ipython-components.git that everything works for you? I'm not sure whether it's better to use relative URLs here, because it assumes if you're working from a fork that you've forked all the appropriate sub-repositories. A On Thu, May 2, 2013 at 11:42 AM, Dave Hirschfeld wrote: > Dave Hirschfeld gmail.com> writes: > > > > > After all this it should hopefully work! > > > > HTH, > > Dave > > > > It seems there's a typo in setupbase.py > > https://github.com/ipython/ipython/blob/master/setupbase.py#L384 > > I'm assuming that 'external' should in fact be 'components' > > With this change I can compile & run the latest IPython. > > HTH, > Dave > > _______________________________________________ > 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 aron at ahmadia.net Thu May 2 06:55:19 2013 From: aron at ahmadia.net (Aron Ahmadia) Date: Thu, 2 May 2013 11:55:19 +0100 Subject: [IPython-dev] submodules over https In-Reply-To: References: Message-ID: Hi Dave, I just noticed that the submodule URLs are hardcoded instead of relative: https://github.com/ipython/ipython/blob/master/.gitmodules#L3 Can you check that if you do a non-recursive checkout, then modify this line in the top-level .gitmodule file from: url = git://github.com/ipython/ipython-components.git url = ../ipython-components.git that everything works for you? I'm not sure whether it's better to use relative URLs here, because it assumes if you're working from a fork that you've forked all the appropriate sub-repositories. A On Thu, May 2, 2013 at 11:42 AM, Dave Hirschfeld wrote: > Dave Hirschfeld gmail.com> writes: > > > > > After all this it should hopefully work! > > > > HTH, > > Dave > > > > It seems there's a typo in setupbase.py > > https://github.com/ipython/ipython/blob/master/setupbase.py#L384 > > I'm assuming that 'external' should in fact be 'components' > > With this change I can compile & run the latest IPython. > > HTH, > Dave > > _______________________________________________ > 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 dave.hirschfeld at gmail.com Thu May 2 07:20:30 2013 From: dave.hirschfeld at gmail.com (Dave Hirschfeld) Date: Thu, 2 May 2013 11:20:30 +0000 (UTC) Subject: [IPython-dev] submodules over https References: Message-ID: Aron Ahmadia ahmadia.net> writes: > > Hi Dave, > I just noticed that the submodule URLs are hardcoded instead of relative: > > > https://github.com/ipython/ipython/blob/master/.gitmodules#L3 > So that's where the path is hard coded - good to know! > > Can you check that if you do a non-recursive checkout, then modify this line in the top-level .gitmodule file from: > > > url = git://github.com/ipython/ipython-components.git > > url = ../ipython-components.git > > > that everything works for you? > I can confirm that changing the url to a relative path in this one location allows everything to work correctly with a repo checked out via https. > It seems there's a typo in setupbase.py > > https://github.com/ipython/ipython/blob/master/setupbase.py#L384 > > I'm assuming that 'external' should in fact be 'components' > With this change I can compile & run the latest IPython. > NB: To build & install you still have to fix the typo in setupbase.py Thanks, Dave From aron at ahmadia.net Thu May 2 09:12:15 2013 From: aron at ahmadia.net (Aron Ahmadia) Date: Thu, 2 May 2013 14:12:15 +0100 Subject: [IPython-dev] submodules over https In-Reply-To: References: Message-ID: Looks like the setupbase.py typo has been addressed: https://github.com/ipython/ipython/pull/3258 A On Thu, May 2, 2013 at 12:20 PM, Dave Hirschfeld wrote: > Aron Ahmadia ahmadia.net> writes: > > > > > Hi Dave, > > I just noticed that the submodule URLs are hardcoded instead of relative: > > > > > > https://github.com/ipython/ipython/blob/master/.gitmodules#L3 > > > > > So that's where the path is hard coded - good to know! > > > > > > Can you check that if you do a non-recursive checkout, then modify this > line in the top-level .gitmodule file from: > > > > > > url = git://github.com/ipython/ipython-components.git > > > > url = ../ipython-components.git > > > > > > that everything works for you? > > > > > I can confirm that changing the url to a relative path in this one location > allows everything to work correctly with a repo checked out via https. > > > > It seems there's a typo in setupbase.py > > > > https://github.com/ipython/ipython/blob/master/setupbase.py#L384 > > > > I'm assuming that 'external' should in fact be 'components' > > With this change I can compile & run the latest IPython. > > > > > NB: To build & install you still have to fix the typo in setupbase.py > > Thanks, > Dave > > _______________________________________________ > 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 aron at ahmadia.net Thu May 2 09:12:15 2013 From: aron at ahmadia.net (Aron Ahmadia) Date: Thu, 2 May 2013 14:12:15 +0100 Subject: [IPython-dev] submodules over https In-Reply-To: References: Message-ID: Looks like the setupbase.py typo has been addressed: https://github.com/ipython/ipython/pull/3258 A On Thu, May 2, 2013 at 12:20 PM, Dave Hirschfeld wrote: > Aron Ahmadia ahmadia.net> writes: > > > > > Hi Dave, > > I just noticed that the submodule URLs are hardcoded instead of relative: > > > > > > https://github.com/ipython/ipython/blob/master/.gitmodules#L3 > > > > > So that's where the path is hard coded - good to know! > > > > > > Can you check that if you do a non-recursive checkout, then modify this > line in the top-level .gitmodule file from: > > > > > > url = git://github.com/ipython/ipython-components.git > > > > url = ../ipython-components.git > > > > > > that everything works for you? > > > > > I can confirm that changing the url to a relative path in this one location > allows everything to work correctly with a repo checked out via https. > > > > It seems there's a typo in setupbase.py > > > > https://github.com/ipython/ipython/blob/master/setupbase.py#L384 > > > > I'm assuming that 'external' should in fact be 'components' > > With this change I can compile & run the latest IPython. > > > > > NB: To build & install you still have to fix the typo in setupbase.py > > Thanks, > Dave > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Thu May 2 12:32:56 2013 From: benjaminrk at gmail.com (MinRK) Date: Thu, 2 May 2013 09:32:56 -0700 Subject: [IPython-dev] submodules over https In-Reply-To: References: Message-ID: I didn't know about relative URLs, that's cool. There is one problem with them, though: forks. It means that a clone from someone else's repo won't be able to find it because it will resolve to their ipython-components repo as well (same goes for secondary clones from the filesystem, etc.). I just ran into this while testing my own branch which changes the url to relative, which doesn't work because my fork of ipython-components isn't up to date. What is the disadvantage of just hard-coding https? On Thu, May 2, 2013 at 6:12 AM, Aron Ahmadia wrote: > Looks like the setupbase.py typo has been addressed: > https://github.com/ipython/ipython/pull/3258 > > A > > > On Thu, May 2, 2013 at 12:20 PM, Dave Hirschfeld < > dave.hirschfeld at gmail.com> wrote: > >> Aron Ahmadia ahmadia.net> writes: >> >> > >> > Hi Dave, >> > I just noticed that the submodule URLs are hardcoded instead of >> relative: >> > >> > >> > https://github.com/ipython/ipython/blob/master/.gitmodules#L3 >> > >> >> >> So that's where the path is hard coded - good to know! >> >> >> > >> > Can you check that if you do a non-recursive checkout, then modify this >> line in the top-level .gitmodule file from: >> > >> > >> > url = git://github.com/ipython/ipython-components.git >> > >> > url = ../ipython-components.git >> > >> > >> > that everything works for you? >> > >> >> >> I can confirm that changing the url to a relative path in this one >> location >> allows everything to work correctly with a repo checked out via https. >> >> >> > It seems there's a typo in setupbase.py >> > >> > https://github.com/ipython/ipython/blob/master/setupbase.py#L384 >> > >> > I'm assuming that 'external' should in fact be 'components' >> > With this change I can compile & run the latest IPython. >> > >> >> >> NB: To build & install you still have to fix the typo in setupbase.py >> >> Thanks, >> Dave >> >> _______________________________________________ >> 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 benjaminrk at gmail.com Thu May 2 12:32:56 2013 From: benjaminrk at gmail.com (MinRK) Date: Thu, 2 May 2013 09:32:56 -0700 Subject: [IPython-dev] submodules over https In-Reply-To: References: Message-ID: I didn't know about relative URLs, that's cool. There is one problem with them, though: forks. It means that a clone from someone else's repo won't be able to find it because it will resolve to their ipython-components repo as well (same goes for secondary clones from the filesystem, etc.). I just ran into this while testing my own branch which changes the url to relative, which doesn't work because my fork of ipython-components isn't up to date. What is the disadvantage of just hard-coding https? On Thu, May 2, 2013 at 6:12 AM, Aron Ahmadia wrote: > Looks like the setupbase.py typo has been addressed: > https://github.com/ipython/ipython/pull/3258 > > A > > > On Thu, May 2, 2013 at 12:20 PM, Dave Hirschfeld < > dave.hirschfeld at gmail.com> wrote: > >> Aron Ahmadia ahmadia.net> writes: >> >> > >> > Hi Dave, >> > I just noticed that the submodule URLs are hardcoded instead of >> relative: >> > >> > >> > https://github.com/ipython/ipython/blob/master/.gitmodules#L3 >> > >> >> >> So that's where the path is hard coded - good to know! >> >> >> > >> > Can you check that if you do a non-recursive checkout, then modify this >> line in the top-level .gitmodule file from: >> > >> > >> > url = git://github.com/ipython/ipython-components.git >> > >> > url = ../ipython-components.git >> > >> > >> > that everything works for you? >> > >> >> >> I can confirm that changing the url to a relative path in this one >> location >> allows everything to work correctly with a repo checked out via https. >> >> >> > It seems there's a typo in setupbase.py >> > >> > https://github.com/ipython/ipython/blob/master/setupbase.py#L384 >> > >> > I'm assuming that 'external' should in fact be 'components' >> > With this change I can compile & run the latest IPython. >> > >> >> >> NB: To build & install you still have to fix the typo in setupbase.py >> >> Thanks, >> Dave >> >> _______________________________________________ >> 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 aron at ahmadia.net Thu May 2 12:44:07 2013 From: aron at ahmadia.net (Aron Ahmadia) Date: Thu, 2 May 2013 17:44:07 +0100 Subject: [IPython-dev] submodules over https In-Reply-To: References: Message-ID: Min, It's most useful for maintaining branches of repositories containing subrepositories without having pull requests open. Let's say I want somebody to see my version of IPython, that points to my own edits to the Components subrepo as some top-level edits. With the hardcoded approach, I can't maintain a top-level IPython fork without keeping a little commit in there that modifies .gitmodules to point to my repositories (or switch to relative URLs) unless you keep a pull request open at IPython/xxx for all the branch commits. So in summary: relative urls - able to maintain branches that point to correct subrepository commits without pull requests open, single forks from github don't work hardcoded urls - single forks work, hard to maintain branches that require commits in subrepositories (that are not yet merged into IPython) A On Thu, May 2, 2013 at 5:32 PM, MinRK wrote: > I didn't know about relative URLs, that's cool. There is one problem with > them, though: forks. It means that a clone from someone else's repo won't > be able to find it because it will resolve to their ipython-components repo > as well (same goes for secondary clones from the filesystem, etc.). I just > ran into this while testing my own branch which changes the url to > relative, which doesn't work because my fork of ipython-components isn't up > to date. > > What is the disadvantage of just hard-coding https? > > > > On Thu, May 2, 2013 at 6:12 AM, Aron Ahmadia wrote: > >> Looks like the setupbase.py typo has been addressed: >> https://github.com/ipython/ipython/pull/3258 >> >> A >> >> >> On Thu, May 2, 2013 at 12:20 PM, Dave Hirschfeld < >> dave.hirschfeld at gmail.com> wrote: >> >>> Aron Ahmadia ahmadia.net> writes: >>> >>> > >>> > Hi Dave, >>> > I just noticed that the submodule URLs are hardcoded instead of >>> relative: >>> > >>> > >>> > https://github.com/ipython/ipython/blob/master/.gitmodules#L3 >>> > >>> >>> >>> So that's where the path is hard coded - good to know! >>> >>> >>> > >>> > Can you check that if you do a non-recursive checkout, then modify this >>> line in the top-level .gitmodule file from: >>> > >>> > >>> > url = git://github.com/ipython/ipython-components.git >>> > >>> > url = ../ipython-components.git >>> > >>> > >>> > that everything works for you? >>> > >>> >>> >>> I can confirm that changing the url to a relative path in this one >>> location >>> allows everything to work correctly with a repo checked out via https. >>> >>> >>> > It seems there's a typo in setupbase.py >>> > >>> > https://github.com/ipython/ipython/blob/master/setupbase.py#L384 >>> > >>> > I'm assuming that 'external' should in fact be 'components' >>> > With this change I can compile & run the latest IPython. >>> > >>> >>> >>> NB: To build & install you still have to fix the typo in setupbase.py >>> >>> Thanks, >>> Dave >>> >>> _______________________________________________ >>> 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 aron at ahmadia.net Thu May 2 12:44:07 2013 From: aron at ahmadia.net (Aron Ahmadia) Date: Thu, 2 May 2013 17:44:07 +0100 Subject: [IPython-dev] submodules over https In-Reply-To: References: Message-ID: Min, It's most useful for maintaining branches of repositories containing subrepositories without having pull requests open. Let's say I want somebody to see my version of IPython, that points to my own edits to the Components subrepo as some top-level edits. With the hardcoded approach, I can't maintain a top-level IPython fork without keeping a little commit in there that modifies .gitmodules to point to my repositories (or switch to relative URLs) unless you keep a pull request open at IPython/xxx for all the branch commits. So in summary: relative urls - able to maintain branches that point to correct subrepository commits without pull requests open, single forks from github don't work hardcoded urls - single forks work, hard to maintain branches that require commits in subrepositories (that are not yet merged into IPython) A On Thu, May 2, 2013 at 5:32 PM, MinRK wrote: > I didn't know about relative URLs, that's cool. There is one problem with > them, though: forks. It means that a clone from someone else's repo won't > be able to find it because it will resolve to their ipython-components repo > as well (same goes for secondary clones from the filesystem, etc.). I just > ran into this while testing my own branch which changes the url to > relative, which doesn't work because my fork of ipython-components isn't up > to date. > > What is the disadvantage of just hard-coding https? > > > > On Thu, May 2, 2013 at 6:12 AM, Aron Ahmadia wrote: > >> Looks like the setupbase.py typo has been addressed: >> https://github.com/ipython/ipython/pull/3258 >> >> A >> >> >> On Thu, May 2, 2013 at 12:20 PM, Dave Hirschfeld < >> dave.hirschfeld at gmail.com> wrote: >> >>> Aron Ahmadia ahmadia.net> writes: >>> >>> > >>> > Hi Dave, >>> > I just noticed that the submodule URLs are hardcoded instead of >>> relative: >>> > >>> > >>> > https://github.com/ipython/ipython/blob/master/.gitmodules#L3 >>> > >>> >>> >>> So that's where the path is hard coded - good to know! >>> >>> >>> > >>> > Can you check that if you do a non-recursive checkout, then modify this >>> line in the top-level .gitmodule file from: >>> > >>> > >>> > url = git://github.com/ipython/ipython-components.git >>> > >>> > url = ../ipython-components.git >>> > >>> > >>> > that everything works for you? >>> > >>> >>> >>> I can confirm that changing the url to a relative path in this one >>> location >>> allows everything to work correctly with a repo checked out via https. >>> >>> >>> > It seems there's a typo in setupbase.py >>> > >>> > https://github.com/ipython/ipython/blob/master/setupbase.py#L384 >>> > >>> > I'm assuming that 'external' should in fact be 'components' >>> > With this change I can compile & run the latest IPython. >>> > >>> >>> >>> NB: To build & install you still have to fix the typo in setupbase.py >>> >>> Thanks, >>> Dave >>> >>> _______________________________________________ >>> 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 benjaminrk at gmail.com Thu May 2 12:45:34 2013 From: benjaminrk at gmail.com (MinRK) Date: Thu, 2 May 2013 09:45:34 -0700 Subject: [IPython-dev] submodules over https In-Reply-To: References: Message-ID: but relative urls don't work for any regular PRs that *don't* affect the submodule On Thu, May 2, 2013 at 9:44 AM, Aron Ahmadia wrote: > Min, > > It's most useful for maintaining branches of repositories containing > subrepositories without having pull requests open. > > Let's say I want somebody to see my version of IPython, that points to my > own edits to the Components subrepo as some top-level edits. With the > hardcoded approach, I can't maintain a top-level IPython fork without > keeping a little commit in there that modifies .gitmodules to point to my > repositories (or switch to relative URLs) unless you keep a pull request > open at IPython/xxx for all the branch commits. > > So in summary: > > relative urls - able to maintain branches that point to correct > subrepository commits without pull requests open, single forks from github > don't work > hardcoded urls - single forks work, hard to maintain branches that require > commits in subrepositories (that are not yet merged into IPython) > > A > > > > > On Thu, May 2, 2013 at 5:32 PM, MinRK wrote: > >> I didn't know about relative URLs, that's cool. There is one problem >> with them, though: forks. It means that a clone from someone else's repo >> won't be able to find it because it will resolve to their >> ipython-components repo as well (same goes for secondary clones from the >> filesystem, etc.). I just ran into this while testing my own branch which >> changes the url to relative, which doesn't work because my fork of >> ipython-components isn't up to date. >> >> What is the disadvantage of just hard-coding https? >> >> >> >> On Thu, May 2, 2013 at 6:12 AM, Aron Ahmadia wrote: >> >>> Looks like the setupbase.py typo has been addressed: >>> https://github.com/ipython/ipython/pull/3258 >>> >>> A >>> >>> >>> On Thu, May 2, 2013 at 12:20 PM, Dave Hirschfeld < >>> dave.hirschfeld at gmail.com> wrote: >>> >>>> Aron Ahmadia ahmadia.net> writes: >>>> >>>> > >>>> > Hi Dave, >>>> > I just noticed that the submodule URLs are hardcoded instead of >>>> relative: >>>> > >>>> > >>>> > https://github.com/ipython/ipython/blob/master/.gitmodules#L3 >>>> > >>>> >>>> >>>> So that's where the path is hard coded - good to know! >>>> >>>> >>>> > >>>> > Can you check that if you do a non-recursive checkout, then modify >>>> this >>>> line in the top-level .gitmodule file from: >>>> > >>>> > >>>> > url = git://github.com/ipython/ipython-components.git >>>> > >>>> > url = ../ipython-components.git >>>> > >>>> > >>>> > that everything works for you? >>>> > >>>> >>>> >>>> I can confirm that changing the url to a relative path in this one >>>> location >>>> allows everything to work correctly with a repo checked out via https. >>>> >>>> >>>> > It seems there's a typo in setupbase.py >>>> > >>>> > https://github.com/ipython/ipython/blob/master/setupbase.py#L384 >>>> > >>>> > I'm assuming that 'external' should in fact be 'components' >>>> > With this change I can compile & run the latest IPython. >>>> > >>>> >>>> >>>> NB: To build & install you still have to fix the typo in setupbase.py >>>> >>>> Thanks, >>>> Dave >>>> >>>> _______________________________________________ >>>> 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 benjaminrk at gmail.com Thu May 2 12:45:34 2013 From: benjaminrk at gmail.com (MinRK) Date: Thu, 2 May 2013 09:45:34 -0700 Subject: [IPython-dev] submodules over https In-Reply-To: References: Message-ID: but relative urls don't work for any regular PRs that *don't* affect the submodule On Thu, May 2, 2013 at 9:44 AM, Aron Ahmadia wrote: > Min, > > It's most useful for maintaining branches of repositories containing > subrepositories without having pull requests open. > > Let's say I want somebody to see my version of IPython, that points to my > own edits to the Components subrepo as some top-level edits. With the > hardcoded approach, I can't maintain a top-level IPython fork without > keeping a little commit in there that modifies .gitmodules to point to my > repositories (or switch to relative URLs) unless you keep a pull request > open at IPython/xxx for all the branch commits. > > So in summary: > > relative urls - able to maintain branches that point to correct > subrepository commits without pull requests open, single forks from github > don't work > hardcoded urls - single forks work, hard to maintain branches that require > commits in subrepositories (that are not yet merged into IPython) > > A > > > > > On Thu, May 2, 2013 at 5:32 PM, MinRK wrote: > >> I didn't know about relative URLs, that's cool. There is one problem >> with them, though: forks. It means that a clone from someone else's repo >> won't be able to find it because it will resolve to their >> ipython-components repo as well (same goes for secondary clones from the >> filesystem, etc.). I just ran into this while testing my own branch which >> changes the url to relative, which doesn't work because my fork of >> ipython-components isn't up to date. >> >> What is the disadvantage of just hard-coding https? >> >> >> >> On Thu, May 2, 2013 at 6:12 AM, Aron Ahmadia wrote: >> >>> Looks like the setupbase.py typo has been addressed: >>> https://github.com/ipython/ipython/pull/3258 >>> >>> A >>> >>> >>> On Thu, May 2, 2013 at 12:20 PM, Dave Hirschfeld < >>> dave.hirschfeld at gmail.com> wrote: >>> >>>> Aron Ahmadia ahmadia.net> writes: >>>> >>>> > >>>> > Hi Dave, >>>> > I just noticed that the submodule URLs are hardcoded instead of >>>> relative: >>>> > >>>> > >>>> > https://github.com/ipython/ipython/blob/master/.gitmodules#L3 >>>> > >>>> >>>> >>>> So that's where the path is hard coded - good to know! >>>> >>>> >>>> > >>>> > Can you check that if you do a non-recursive checkout, then modify >>>> this >>>> line in the top-level .gitmodule file from: >>>> > >>>> > >>>> > url = git://github.com/ipython/ipython-components.git >>>> > >>>> > url = ../ipython-components.git >>>> > >>>> > >>>> > that everything works for you? >>>> > >>>> >>>> >>>> I can confirm that changing the url to a relative path in this one >>>> location >>>> allows everything to work correctly with a repo checked out via https. >>>> >>>> >>>> > It seems there's a typo in setupbase.py >>>> > >>>> > https://github.com/ipython/ipython/blob/master/setupbase.py#L384 >>>> > >>>> > I'm assuming that 'external' should in fact be 'components' >>>> > With this change I can compile & run the latest IPython. >>>> > >>>> >>>> >>>> NB: To build & install you still have to fix the typo in setupbase.py >>>> >>>> Thanks, >>>> Dave >>>> >>>> _______________________________________________ >>>> 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 aron at ahmadia.net Thu May 2 12:53:09 2013 From: aron at ahmadia.net (Aron Ahmadia) Date: Thu, 2 May 2013 17:53:09 +0100 Subject: [IPython-dev] submodules over https In-Reply-To: References: Message-ID: Could you explain that a bit more? The only thing that breaks is if you try to clone a top-level IPython fork on github but haven't forked all the proper submodules. To me that's more of a github issue (it should allow you fork all subrepositories in one fell forky swoop). I guess the question is what your common case is. How often do you expect people to just want to fork IPython vs. maintaining public IPython branches that contain subrepositories. For your case, it might be better to go with hardcoded submodule URLs but provide instructions somewhere on how to issue a pull request when you have subrepository commits as well. A On Thu, May 2, 2013 at 5:45 PM, MinRK wrote: > but relative urls don't work for any regular PRs that *don't* affect the > submodule > > > > On Thu, May 2, 2013 at 9:44 AM, Aron Ahmadia wrote: > >> Min, >> >> It's most useful for maintaining branches of repositories containing >> subrepositories without having pull requests open. >> >> Let's say I want somebody to see my version of IPython, that points to my >> own edits to the Components subrepo as some top-level edits. With the >> hardcoded approach, I can't maintain a top-level IPython fork without >> keeping a little commit in there that modifies .gitmodules to point to my >> repositories (or switch to relative URLs) unless you keep a pull request >> open at IPython/xxx for all the branch commits. >> >> So in summary: >> >> relative urls - able to maintain branches that point to correct >> subrepository commits without pull requests open, single forks from github >> don't work >> hardcoded urls - single forks work, hard to maintain branches that >> require commits in subrepositories (that are not yet merged into IPython) >> >> A >> >> >> >> >> On Thu, May 2, 2013 at 5:32 PM, MinRK wrote: >> >>> I didn't know about relative URLs, that's cool. There is one problem >>> with them, though: forks. It means that a clone from someone else's repo >>> won't be able to find it because it will resolve to their >>> ipython-components repo as well (same goes for secondary clones from the >>> filesystem, etc.). I just ran into this while testing my own branch which >>> changes the url to relative, which doesn't work because my fork of >>> ipython-components isn't up to date. >>> >>> What is the disadvantage of just hard-coding https? >>> >>> >>> >>> On Thu, May 2, 2013 at 6:12 AM, Aron Ahmadia wrote: >>> >>>> Looks like the setupbase.py typo has been addressed: >>>> https://github.com/ipython/ipython/pull/3258 >>>> >>>> A >>>> >>>> >>>> On Thu, May 2, 2013 at 12:20 PM, Dave Hirschfeld < >>>> dave.hirschfeld at gmail.com> wrote: >>>> >>>>> Aron Ahmadia ahmadia.net> writes: >>>>> >>>>> > >>>>> > Hi Dave, >>>>> > I just noticed that the submodule URLs are hardcoded instead of >>>>> relative: >>>>> > >>>>> > >>>>> > https://github.com/ipython/ipython/blob/master/.gitmodules#L3 >>>>> > >>>>> >>>>> >>>>> So that's where the path is hard coded - good to know! >>>>> >>>>> >>>>> > >>>>> > Can you check that if you do a non-recursive checkout, then modify >>>>> this >>>>> line in the top-level .gitmodule file from: >>>>> > >>>>> > >>>>> > url = git://github.com/ipython/ipython-components.git >>>>> > >>>>> > url = ../ipython-components.git >>>>> > >>>>> > >>>>> > that everything works for you? >>>>> > >>>>> >>>>> >>>>> I can confirm that changing the url to a relative path in this one >>>>> location >>>>> allows everything to work correctly with a repo checked out via https. >>>>> >>>>> >>>>> > It seems there's a typo in setupbase.py >>>>> > >>>>> > https://github.com/ipython/ipython/blob/master/setupbase.py#L384 >>>>> > >>>>> > I'm assuming that 'external' should in fact be 'components' >>>>> > With this change I can compile & run the latest IPython. >>>>> > >>>>> >>>>> >>>>> NB: To build & install you still have to fix the typo in setupbase.py >>>>> >>>>> Thanks, >>>>> Dave >>>>> >>>>> _______________________________________________ >>>>> 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 aron at ahmadia.net Thu May 2 12:53:09 2013 From: aron at ahmadia.net (Aron Ahmadia) Date: Thu, 2 May 2013 17:53:09 +0100 Subject: [IPython-dev] submodules over https In-Reply-To: References: Message-ID: Could you explain that a bit more? The only thing that breaks is if you try to clone a top-level IPython fork on github but haven't forked all the proper submodules. To me that's more of a github issue (it should allow you fork all subrepositories in one fell forky swoop). I guess the question is what your common case is. How often do you expect people to just want to fork IPython vs. maintaining public IPython branches that contain subrepositories. For your case, it might be better to go with hardcoded submodule URLs but provide instructions somewhere on how to issue a pull request when you have subrepository commits as well. A On Thu, May 2, 2013 at 5:45 PM, MinRK wrote: > but relative urls don't work for any regular PRs that *don't* affect the > submodule > > > > On Thu, May 2, 2013 at 9:44 AM, Aron Ahmadia wrote: > >> Min, >> >> It's most useful for maintaining branches of repositories containing >> subrepositories without having pull requests open. >> >> Let's say I want somebody to see my version of IPython, that points to my >> own edits to the Components subrepo as some top-level edits. With the >> hardcoded approach, I can't maintain a top-level IPython fork without >> keeping a little commit in there that modifies .gitmodules to point to my >> repositories (or switch to relative URLs) unless you keep a pull request >> open at IPython/xxx for all the branch commits. >> >> So in summary: >> >> relative urls - able to maintain branches that point to correct >> subrepository commits without pull requests open, single forks from github >> don't work >> hardcoded urls - single forks work, hard to maintain branches that >> require commits in subrepositories (that are not yet merged into IPython) >> >> A >> >> >> >> >> On Thu, May 2, 2013 at 5:32 PM, MinRK wrote: >> >>> I didn't know about relative URLs, that's cool. There is one problem >>> with them, though: forks. It means that a clone from someone else's repo >>> won't be able to find it because it will resolve to their >>> ipython-components repo as well (same goes for secondary clones from the >>> filesystem, etc.). I just ran into this while testing my own branch which >>> changes the url to relative, which doesn't work because my fork of >>> ipython-components isn't up to date. >>> >>> What is the disadvantage of just hard-coding https? >>> >>> >>> >>> On Thu, May 2, 2013 at 6:12 AM, Aron Ahmadia wrote: >>> >>>> Looks like the setupbase.py typo has been addressed: >>>> https://github.com/ipython/ipython/pull/3258 >>>> >>>> A >>>> >>>> >>>> On Thu, May 2, 2013 at 12:20 PM, Dave Hirschfeld < >>>> dave.hirschfeld at gmail.com> wrote: >>>> >>>>> Aron Ahmadia ahmadia.net> writes: >>>>> >>>>> > >>>>> > Hi Dave, >>>>> > I just noticed that the submodule URLs are hardcoded instead of >>>>> relative: >>>>> > >>>>> > >>>>> > https://github.com/ipython/ipython/blob/master/.gitmodules#L3 >>>>> > >>>>> >>>>> >>>>> So that's where the path is hard coded - good to know! >>>>> >>>>> >>>>> > >>>>> > Can you check that if you do a non-recursive checkout, then modify >>>>> this >>>>> line in the top-level .gitmodule file from: >>>>> > >>>>> > >>>>> > url = git://github.com/ipython/ipython-components.git >>>>> > >>>>> > url = ../ipython-components.git >>>>> > >>>>> > >>>>> > that everything works for you? >>>>> > >>>>> >>>>> >>>>> I can confirm that changing the url to a relative path in this one >>>>> location >>>>> allows everything to work correctly with a repo checked out via https. >>>>> >>>>> >>>>> > It seems there's a typo in setupbase.py >>>>> > >>>>> > https://github.com/ipython/ipython/blob/master/setupbase.py#L384 >>>>> > >>>>> > I'm assuming that 'external' should in fact be 'components' >>>>> > With this change I can compile & run the latest IPython. >>>>> > >>>>> >>>>> >>>>> NB: To build & install you still have to fix the typo in setupbase.py >>>>> >>>>> Thanks, >>>>> Dave >>>>> >>>>> _______________________________________________ >>>>> 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 benjaminrk at gmail.com Thu May 2 12:56:30 2013 From: benjaminrk at gmail.com (MinRK) Date: Thu, 2 May 2013 09:56:30 -0700 Subject: [IPython-dev] submodules over https In-Reply-To: References: Message-ID: It means that everyone who forks IPython must also fork ipython-components, and must continually pull/push to keep their components repo up to date. It also means that you cannot do filesystem clones unless you have also done clones of ipython-components to the same location on the filesystem. A very simple "I want to check out this user's branch" doesn't work under normal circumstances: git clone git://github.com/minrk/ipython.git -b relative-submodule --recursive will fail This will be true of every branch from every user who doesn't maintain an up to date fork of ipython-components On Thu, May 2, 2013 at 9:53 AM, Aron Ahmadia wrote: > Could you explain that a bit more? The only thing that breaks is if you > try to clone a top-level IPython fork on github but haven't forked all the > proper submodules. To me that's more of a github issue (it should allow > you fork all subrepositories in one fell forky swoop). > > I guess the question is what your common case is. How often do you expect > people to just want to fork IPython vs. maintaining public IPython branches > that contain subrepositories. For your case, it might be better to go with > hardcoded submodule URLs but provide instructions somewhere on how to issue > a pull request when you have subrepository commits as well. > > A > > > On Thu, May 2, 2013 at 5:45 PM, MinRK wrote: > >> but relative urls don't work for any regular PRs that *don't* affect the >> submodule >> >> >> >> On Thu, May 2, 2013 at 9:44 AM, Aron Ahmadia wrote: >> >>> Min, >>> >>> It's most useful for maintaining branches of repositories containing >>> subrepositories without having pull requests open. >>> >>> Let's say I want somebody to see my version of IPython, that points to >>> my own edits to the Components subrepo as some top-level edits. With the >>> hardcoded approach, I can't maintain a top-level IPython fork without >>> keeping a little commit in there that modifies .gitmodules to point to my >>> repositories (or switch to relative URLs) unless you keep a pull request >>> open at IPython/xxx for all the branch commits. >>> >>> So in summary: >>> >>> relative urls - able to maintain branches that point to correct >>> subrepository commits without pull requests open, single forks from github >>> don't work >>> hardcoded urls - single forks work, hard to maintain branches that >>> require commits in subrepositories (that are not yet merged into IPython) >>> >>> A >>> >>> >>> >>> >>> On Thu, May 2, 2013 at 5:32 PM, MinRK wrote: >>> >>>> I didn't know about relative URLs, that's cool. There is one problem >>>> with them, though: forks. It means that a clone from someone else's repo >>>> won't be able to find it because it will resolve to their >>>> ipython-components repo as well (same goes for secondary clones from the >>>> filesystem, etc.). I just ran into this while testing my own branch which >>>> changes the url to relative, which doesn't work because my fork of >>>> ipython-components isn't up to date. >>>> >>>> What is the disadvantage of just hard-coding https? >>>> >>>> >>>> >>>> On Thu, May 2, 2013 at 6:12 AM, Aron Ahmadia wrote: >>>> >>>>> Looks like the setupbase.py typo has been addressed: >>>>> https://github.com/ipython/ipython/pull/3258 >>>>> >>>>> A >>>>> >>>>> >>>>> On Thu, May 2, 2013 at 12:20 PM, Dave Hirschfeld < >>>>> dave.hirschfeld at gmail.com> wrote: >>>>> >>>>>> Aron Ahmadia ahmadia.net> writes: >>>>>> >>>>>> > >>>>>> > Hi Dave, >>>>>> > I just noticed that the submodule URLs are hardcoded instead of >>>>>> relative: >>>>>> > >>>>>> > >>>>>> > https://github.com/ipython/ipython/blob/master/.gitmodules#L3 >>>>>> > >>>>>> >>>>>> >>>>>> So that's where the path is hard coded - good to know! >>>>>> >>>>>> >>>>>> > >>>>>> > Can you check that if you do a non-recursive checkout, then modify >>>>>> this >>>>>> line in the top-level .gitmodule file from: >>>>>> > >>>>>> > >>>>>> > url = git://github.com/ipython/ipython-components.git >>>>>> > >>>>>> > url = ../ipython-components.git >>>>>> > >>>>>> > >>>>>> > that everything works for you? >>>>>> > >>>>>> >>>>>> >>>>>> I can confirm that changing the url to a relative path in this one >>>>>> location >>>>>> allows everything to work correctly with a repo checked out via https. >>>>>> >>>>>> >>>>>> > It seems there's a typo in setupbase.py >>>>>> > >>>>>> > https://github.com/ipython/ipython/blob/master/setupbase.py#L384 >>>>>> > >>>>>> > I'm assuming that 'external' should in fact be 'components' >>>>>> > With this change I can compile & run the latest IPython. >>>>>> > >>>>>> >>>>>> >>>>>> NB: To build & install you still have to fix the typo in setupbase.py >>>>>> >>>>>> Thanks, >>>>>> Dave >>>>>> >>>>>> _______________________________________________ >>>>>> 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 benjaminrk at gmail.com Thu May 2 12:56:30 2013 From: benjaminrk at gmail.com (MinRK) Date: Thu, 2 May 2013 09:56:30 -0700 Subject: [IPython-dev] submodules over https In-Reply-To: References: Message-ID: It means that everyone who forks IPython must also fork ipython-components, and must continually pull/push to keep their components repo up to date. It also means that you cannot do filesystem clones unless you have also done clones of ipython-components to the same location on the filesystem. A very simple "I want to check out this user's branch" doesn't work under normal circumstances: git clone git://github.com/minrk/ipython.git -b relative-submodule --recursive will fail This will be true of every branch from every user who doesn't maintain an up to date fork of ipython-components On Thu, May 2, 2013 at 9:53 AM, Aron Ahmadia wrote: > Could you explain that a bit more? The only thing that breaks is if you > try to clone a top-level IPython fork on github but haven't forked all the > proper submodules. To me that's more of a github issue (it should allow > you fork all subrepositories in one fell forky swoop). > > I guess the question is what your common case is. How often do you expect > people to just want to fork IPython vs. maintaining public IPython branches > that contain subrepositories. For your case, it might be better to go with > hardcoded submodule URLs but provide instructions somewhere on how to issue > a pull request when you have subrepository commits as well. > > A > > > On Thu, May 2, 2013 at 5:45 PM, MinRK wrote: > >> but relative urls don't work for any regular PRs that *don't* affect the >> submodule >> >> >> >> On Thu, May 2, 2013 at 9:44 AM, Aron Ahmadia wrote: >> >>> Min, >>> >>> It's most useful for maintaining branches of repositories containing >>> subrepositories without having pull requests open. >>> >>> Let's say I want somebody to see my version of IPython, that points to >>> my own edits to the Components subrepo as some top-level edits. With the >>> hardcoded approach, I can't maintain a top-level IPython fork without >>> keeping a little commit in there that modifies .gitmodules to point to my >>> repositories (or switch to relative URLs) unless you keep a pull request >>> open at IPython/xxx for all the branch commits. >>> >>> So in summary: >>> >>> relative urls - able to maintain branches that point to correct >>> subrepository commits without pull requests open, single forks from github >>> don't work >>> hardcoded urls - single forks work, hard to maintain branches that >>> require commits in subrepositories (that are not yet merged into IPython) >>> >>> A >>> >>> >>> >>> >>> On Thu, May 2, 2013 at 5:32 PM, MinRK wrote: >>> >>>> I didn't know about relative URLs, that's cool. There is one problem >>>> with them, though: forks. It means that a clone from someone else's repo >>>> won't be able to find it because it will resolve to their >>>> ipython-components repo as well (same goes for secondary clones from the >>>> filesystem, etc.). I just ran into this while testing my own branch which >>>> changes the url to relative, which doesn't work because my fork of >>>> ipython-components isn't up to date. >>>> >>>> What is the disadvantage of just hard-coding https? >>>> >>>> >>>> >>>> On Thu, May 2, 2013 at 6:12 AM, Aron Ahmadia wrote: >>>> >>>>> Looks like the setupbase.py typo has been addressed: >>>>> https://github.com/ipython/ipython/pull/3258 >>>>> >>>>> A >>>>> >>>>> >>>>> On Thu, May 2, 2013 at 12:20 PM, Dave Hirschfeld < >>>>> dave.hirschfeld at gmail.com> wrote: >>>>> >>>>>> Aron Ahmadia ahmadia.net> writes: >>>>>> >>>>>> > >>>>>> > Hi Dave, >>>>>> > I just noticed that the submodule URLs are hardcoded instead of >>>>>> relative: >>>>>> > >>>>>> > >>>>>> > https://github.com/ipython/ipython/blob/master/.gitmodules#L3 >>>>>> > >>>>>> >>>>>> >>>>>> So that's where the path is hard coded - good to know! >>>>>> >>>>>> >>>>>> > >>>>>> > Can you check that if you do a non-recursive checkout, then modify >>>>>> this >>>>>> line in the top-level .gitmodule file from: >>>>>> > >>>>>> > >>>>>> > url = git://github.com/ipython/ipython-components.git >>>>>> > >>>>>> > url = ../ipython-components.git >>>>>> > >>>>>> > >>>>>> > that everything works for you? >>>>>> > >>>>>> >>>>>> >>>>>> I can confirm that changing the url to a relative path in this one >>>>>> location >>>>>> allows everything to work correctly with a repo checked out via https. >>>>>> >>>>>> >>>>>> > It seems there's a typo in setupbase.py >>>>>> > >>>>>> > https://github.com/ipython/ipython/blob/master/setupbase.py#L384 >>>>>> > >>>>>> > I'm assuming that 'external' should in fact be 'components' >>>>>> > With this change I can compile & run the latest IPython. >>>>>> > >>>>>> >>>>>> >>>>>> NB: To build & install you still have to fix the typo in setupbase.py >>>>>> >>>>>> Thanks, >>>>>> Dave >>>>>> >>>>>> _______________________________________________ >>>>>> 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 benjaminrk at gmail.com Thu May 2 13:00:06 2013 From: benjaminrk at gmail.com (MinRK) Date: Thu, 2 May 2013 10:00:06 -0700 Subject: [IPython-dev] submodules over https In-Reply-To: References: Message-ID: So it seems like a hardcoded URL is the right approach, but back to my original question - is there any disadvantage to hardcoding https? There is an obvious reason to not use git://, as it is currently. On Thu, May 2, 2013 at 9:56 AM, MinRK wrote: > It means that everyone who forks IPython must also fork > ipython-components, and must continually pull/push to keep their components > repo up to date. > It also means that you cannot do filesystem clones unless you have also > done clones of ipython-components to the same location on the filesystem. > > A very simple "I want to check out this user's branch" doesn't work under > normal circumstances: > > git clone git://github.com/minrk/ipython.git -b relative-submodule > --recursive > > will fail > > This will be true of every branch from every user who doesn't maintain an > up to date fork of ipython-components > > > On Thu, May 2, 2013 at 9:53 AM, Aron Ahmadia wrote: > >> Could you explain that a bit more? The only thing that breaks is if you >> try to clone a top-level IPython fork on github but haven't forked all the >> proper submodules. To me that's more of a github issue (it should allow >> you fork all subrepositories in one fell forky swoop). >> >> I guess the question is what your common case is. How often do you >> expect people to just want to fork IPython vs. maintaining public IPython >> branches that contain subrepositories. For your case, it might be better >> to go with hardcoded submodule URLs but provide instructions somewhere on >> how to issue a pull request when you have subrepository commits as well. >> >> A >> >> >> On Thu, May 2, 2013 at 5:45 PM, MinRK wrote: >> >>> but relative urls don't work for any regular PRs that *don't* affect the >>> submodule >>> >>> >>> >>> On Thu, May 2, 2013 at 9:44 AM, Aron Ahmadia wrote: >>> >>>> Min, >>>> >>>> It's most useful for maintaining branches of repositories containing >>>> subrepositories without having pull requests open. >>>> >>>> Let's say I want somebody to see my version of IPython, that points to >>>> my own edits to the Components subrepo as some top-level edits. With the >>>> hardcoded approach, I can't maintain a top-level IPython fork without >>>> keeping a little commit in there that modifies .gitmodules to point to my >>>> repositories (or switch to relative URLs) unless you keep a pull request >>>> open at IPython/xxx for all the branch commits. >>>> >>>> So in summary: >>>> >>>> relative urls - able to maintain branches that point to correct >>>> subrepository commits without pull requests open, single forks from github >>>> don't work >>>> hardcoded urls - single forks work, hard to maintain branches that >>>> require commits in subrepositories (that are not yet merged into IPython) >>>> >>>> A >>>> >>>> >>>> >>>> >>>> On Thu, May 2, 2013 at 5:32 PM, MinRK wrote: >>>> >>>>> I didn't know about relative URLs, that's cool. There is one problem >>>>> with them, though: forks. It means that a clone from someone else's repo >>>>> won't be able to find it because it will resolve to their >>>>> ipython-components repo as well (same goes for secondary clones from the >>>>> filesystem, etc.). I just ran into this while testing my own branch which >>>>> changes the url to relative, which doesn't work because my fork of >>>>> ipython-components isn't up to date. >>>>> >>>>> What is the disadvantage of just hard-coding https? >>>>> >>>>> >>>>> >>>>> On Thu, May 2, 2013 at 6:12 AM, Aron Ahmadia wrote: >>>>> >>>>>> Looks like the setupbase.py typo has been addressed: >>>>>> https://github.com/ipython/ipython/pull/3258 >>>>>> >>>>>> A >>>>>> >>>>>> >>>>>> On Thu, May 2, 2013 at 12:20 PM, Dave Hirschfeld < >>>>>> dave.hirschfeld at gmail.com> wrote: >>>>>> >>>>>>> Aron Ahmadia ahmadia.net> writes: >>>>>>> >>>>>>> > >>>>>>> > Hi Dave, >>>>>>> > I just noticed that the submodule URLs are hardcoded instead of >>>>>>> relative: >>>>>>> > >>>>>>> > >>>>>>> > https://github.com/ipython/ipython/blob/master/.gitmodules#L3 >>>>>>> > >>>>>>> >>>>>>> >>>>>>> So that's where the path is hard coded - good to know! >>>>>>> >>>>>>> >>>>>>> > >>>>>>> > Can you check that if you do a non-recursive checkout, then modify >>>>>>> this >>>>>>> line in the top-level .gitmodule file from: >>>>>>> > >>>>>>> > >>>>>>> > url = git://github.com/ipython/ipython-components.git >>>>>>> > >>>>>>> > url = ../ipython-components.git >>>>>>> > >>>>>>> > >>>>>>> > that everything works for you? >>>>>>> > >>>>>>> >>>>>>> >>>>>>> I can confirm that changing the url to a relative path in this one >>>>>>> location >>>>>>> allows everything to work correctly with a repo checked out via >>>>>>> https. >>>>>>> >>>>>>> >>>>>>> > It seems there's a typo in setupbase.py >>>>>>> > >>>>>>> > https://github.com/ipython/ipython/blob/master/setupbase.py#L384 >>>>>>> > >>>>>>> > I'm assuming that 'external' should in fact be 'components' >>>>>>> > With this change I can compile & run the latest IPython. >>>>>>> > >>>>>>> >>>>>>> >>>>>>> NB: To build & install you still have to fix the typo in setupbase.py >>>>>>> >>>>>>> Thanks, >>>>>>> Dave >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 benjaminrk at gmail.com Thu May 2 13:00:06 2013 From: benjaminrk at gmail.com (MinRK) Date: Thu, 2 May 2013 10:00:06 -0700 Subject: [IPython-dev] submodules over https In-Reply-To: References: Message-ID: So it seems like a hardcoded URL is the right approach, but back to my original question - is there any disadvantage to hardcoding https? There is an obvious reason to not use git://, as it is currently. On Thu, May 2, 2013 at 9:56 AM, MinRK wrote: > It means that everyone who forks IPython must also fork > ipython-components, and must continually pull/push to keep their components > repo up to date. > It also means that you cannot do filesystem clones unless you have also > done clones of ipython-components to the same location on the filesystem. > > A very simple "I want to check out this user's branch" doesn't work under > normal circumstances: > > git clone git://github.com/minrk/ipython.git -b relative-submodule > --recursive > > will fail > > This will be true of every branch from every user who doesn't maintain an > up to date fork of ipython-components > > > On Thu, May 2, 2013 at 9:53 AM, Aron Ahmadia wrote: > >> Could you explain that a bit more? The only thing that breaks is if you >> try to clone a top-level IPython fork on github but haven't forked all the >> proper submodules. To me that's more of a github issue (it should allow >> you fork all subrepositories in one fell forky swoop). >> >> I guess the question is what your common case is. How often do you >> expect people to just want to fork IPython vs. maintaining public IPython >> branches that contain subrepositories. For your case, it might be better >> to go with hardcoded submodule URLs but provide instructions somewhere on >> how to issue a pull request when you have subrepository commits as well. >> >> A >> >> >> On Thu, May 2, 2013 at 5:45 PM, MinRK wrote: >> >>> but relative urls don't work for any regular PRs that *don't* affect the >>> submodule >>> >>> >>> >>> On Thu, May 2, 2013 at 9:44 AM, Aron Ahmadia wrote: >>> >>>> Min, >>>> >>>> It's most useful for maintaining branches of repositories containing >>>> subrepositories without having pull requests open. >>>> >>>> Let's say I want somebody to see my version of IPython, that points to >>>> my own edits to the Components subrepo as some top-level edits. With the >>>> hardcoded approach, I can't maintain a top-level IPython fork without >>>> keeping a little commit in there that modifies .gitmodules to point to my >>>> repositories (or switch to relative URLs) unless you keep a pull request >>>> open at IPython/xxx for all the branch commits. >>>> >>>> So in summary: >>>> >>>> relative urls - able to maintain branches that point to correct >>>> subrepository commits without pull requests open, single forks from github >>>> don't work >>>> hardcoded urls - single forks work, hard to maintain branches that >>>> require commits in subrepositories (that are not yet merged into IPython) >>>> >>>> A >>>> >>>> >>>> >>>> >>>> On Thu, May 2, 2013 at 5:32 PM, MinRK wrote: >>>> >>>>> I didn't know about relative URLs, that's cool. There is one problem >>>>> with them, though: forks. It means that a clone from someone else's repo >>>>> won't be able to find it because it will resolve to their >>>>> ipython-components repo as well (same goes for secondary clones from the >>>>> filesystem, etc.). I just ran into this while testing my own branch which >>>>> changes the url to relative, which doesn't work because my fork of >>>>> ipython-components isn't up to date. >>>>> >>>>> What is the disadvantage of just hard-coding https? >>>>> >>>>> >>>>> >>>>> On Thu, May 2, 2013 at 6:12 AM, Aron Ahmadia wrote: >>>>> >>>>>> Looks like the setupbase.py typo has been addressed: >>>>>> https://github.com/ipython/ipython/pull/3258 >>>>>> >>>>>> A >>>>>> >>>>>> >>>>>> On Thu, May 2, 2013 at 12:20 PM, Dave Hirschfeld < >>>>>> dave.hirschfeld at gmail.com> wrote: >>>>>> >>>>>>> Aron Ahmadia ahmadia.net> writes: >>>>>>> >>>>>>> > >>>>>>> > Hi Dave, >>>>>>> > I just noticed that the submodule URLs are hardcoded instead of >>>>>>> relative: >>>>>>> > >>>>>>> > >>>>>>> > https://github.com/ipython/ipython/blob/master/.gitmodules#L3 >>>>>>> > >>>>>>> >>>>>>> >>>>>>> So that's where the path is hard coded - good to know! >>>>>>> >>>>>>> >>>>>>> > >>>>>>> > Can you check that if you do a non-recursive checkout, then modify >>>>>>> this >>>>>>> line in the top-level .gitmodule file from: >>>>>>> > >>>>>>> > >>>>>>> > url = git://github.com/ipython/ipython-components.git >>>>>>> > >>>>>>> > url = ../ipython-components.git >>>>>>> > >>>>>>> > >>>>>>> > that everything works for you? >>>>>>> > >>>>>>> >>>>>>> >>>>>>> I can confirm that changing the url to a relative path in this one >>>>>>> location >>>>>>> allows everything to work correctly with a repo checked out via >>>>>>> https. >>>>>>> >>>>>>> >>>>>>> > It seems there's a typo in setupbase.py >>>>>>> > >>>>>>> > https://github.com/ipython/ipython/blob/master/setupbase.py#L384 >>>>>>> > >>>>>>> > I'm assuming that 'external' should in fact be 'components' >>>>>>> > With this change I can compile & run the latest IPython. >>>>>>> > >>>>>>> >>>>>>> >>>>>>> NB: To build & install you still have to fix the typo in setupbase.py >>>>>>> >>>>>>> Thanks, >>>>>>> Dave >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 wking at tremily.us Thu May 2 13:12:14 2013 From: wking at tremily.us (W. Trevor King) Date: Thu, 02 May 2013 13:12:14 -0400 Subject: [IPython-dev] submodules over https In-Reply-To: Message-ID: <20130502171214.GK15975@odin.tremily.us> On Thu, May 02, 2013 at 10:00:06AM -0700, MinRK wrote: > So it seems like a hardcoded URL is the right approach, I disagree. Aron's point about use cases is well made. If this is your expected approach: On Thu, May 02, 2013 at 09:56:30AM -0700, MinRK wrote: > A very simple "I want to check out this user's branch" doesn't work under > normal circumstances: > > git clone git://github.com/minrk/ipython.git -b relative-submodule > --recursive then hardcoding is the way to go. However, folks interested in your relative-submodule branch are likely already IPython devs that have the main repo and its submodules checked out. In that case, the submodule URL doesn't matter at all (because they already have the submodules checked out before they switch to your branch). The benefit of relative URLs is that if you want to mirror the IPython repositories somewhere else (or start your own permanent fork), the relative URLs are one less thing you have to change. For me and my projets, the mirroring argument seals the deal. I'm not familiar enough with IPython development to have an opinion there ;). Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From wking at tremily.us Thu May 2 13:12:14 2013 From: wking at tremily.us (W. Trevor King) Date: Thu, 02 May 2013 13:12:14 -0400 Subject: [IPython-dev] submodules over https In-Reply-To: Message-ID: <20130502171214.GK15975@odin.tremily.us> On Thu, May 02, 2013 at 10:00:06AM -0700, MinRK wrote: > So it seems like a hardcoded URL is the right approach, I disagree. Aron's point about use cases is well made. If this is your expected approach: On Thu, May 02, 2013 at 09:56:30AM -0700, MinRK wrote: > A very simple "I want to check out this user's branch" doesn't work under > normal circumstances: > > git clone git://github.com/minrk/ipython.git -b relative-submodule > --recursive then hardcoding is the way to go. However, folks interested in your relative-submodule branch are likely already IPython devs that have the main repo and its submodules checked out. In that case, the submodule URL doesn't matter at all (because they already have the submodules checked out before they switch to your branch). The benefit of relative URLs is that if you want to mirror the IPython repositories somewhere else (or start your own permanent fork), the relative URLs are one less thing you have to change. For me and my projets, the mirroring argument seals the deal. I'm not familiar enough with IPython development to have an opinion there ;). Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From benjaminrk at gmail.com Thu May 2 13:28:51 2013 From: benjaminrk at gmail.com (MinRK) Date: Thu, 2 May 2013 10:28:51 -0700 Subject: [IPython-dev] submodules over https In-Reply-To: <20130502171214.GK15975@odin.tremily.us> References: <20130502171214.GK15975@odin.tremily.us> Message-ID: A permanent fork doesn't have a strong case, because it's a one-commit change for a permanent never-changing update to the URL. Mirroring is a better case, since it shouldn't actually affect the repo. But it seems pretty terrible that under normal circumstances, no clone of any IPython repo other than the official one or a proper careful mirror will actually be functional. On Thu, May 2, 2013 at 10:12 AM, W. Trevor King wrote: > On Thu, May 02, 2013 at 10:00:06AM -0700, MinRK wrote: > > So it seems like a hardcoded URL is the right approach, > > I disagree. Aron's point about use cases is well made. If this is > your expected approach: > > On Thu, May 02, 2013 at 09:56:30AM -0700, MinRK wrote: > > A very simple "I want to check out this user's branch" doesn't work under > > normal circumstances: > > > > git clone git://github.com/minrk/ipython.git -b relative-submodule > > --recursive > > then hardcoding is the way to go. However, folks interested in your > relative-submodule branch are likely already IPython devs that have > the main repo and its submodules checked out. In that case, the > submodule URL doesn't matter at all (because they already have the > submodules checked out before they switch to your branch). The > benefit of relative URLs is that if you want to mirror the IPython > repositories somewhere else (or start your own permanent fork), the > relative URLs are one less thing you have to change. For me and my > projets, the mirroring argument seals the deal. I'm not familiar > enough with IPython development to have an opinion there ;). > > Cheers, > Trevor > > -- > This email may be signed or encrypted with GnuPG (http://www.gnupg.org). > For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Thu May 2 13:28:51 2013 From: benjaminrk at gmail.com (MinRK) Date: Thu, 2 May 2013 10:28:51 -0700 Subject: [IPython-dev] submodules over https In-Reply-To: <20130502171214.GK15975@odin.tremily.us> References: <20130502171214.GK15975@odin.tremily.us> Message-ID: A permanent fork doesn't have a strong case, because it's a one-commit change for a permanent never-changing update to the URL. Mirroring is a better case, since it shouldn't actually affect the repo. But it seems pretty terrible that under normal circumstances, no clone of any IPython repo other than the official one or a proper careful mirror will actually be functional. On Thu, May 2, 2013 at 10:12 AM, W. Trevor King wrote: > On Thu, May 02, 2013 at 10:00:06AM -0700, MinRK wrote: > > So it seems like a hardcoded URL is the right approach, > > I disagree. Aron's point about use cases is well made. If this is > your expected approach: > > On Thu, May 02, 2013 at 09:56:30AM -0700, MinRK wrote: > > A very simple "I want to check out this user's branch" doesn't work under > > normal circumstances: > > > > git clone git://github.com/minrk/ipython.git -b relative-submodule > > --recursive > > then hardcoding is the way to go. However, folks interested in your > relative-submodule branch are likely already IPython devs that have > the main repo and its submodules checked out. In that case, the > submodule URL doesn't matter at all (because they already have the > submodules checked out before they switch to your branch). The > benefit of relative URLs is that if you want to mirror the IPython > repositories somewhere else (or start your own permanent fork), the > relative URLs are one less thing you have to change. For me and my > projets, the mirroring argument seals the deal. I'm not familiar > enough with IPython development to have an opinion there ;). > > Cheers, > Trevor > > -- > This email may be signed or encrypted with GnuPG (http://www.gnupg.org). > For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy > > _______________________________________________ > 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 wking at tremily.us Thu May 2 13:42:33 2013 From: wking at tremily.us (W. Trevor King) Date: Thu, 02 May 2013 13:42:33 -0400 Subject: [IPython-dev] submodules over https In-Reply-To: Message-ID: <20130502174233.GM15975@odin.tremily.us> On Thu, May 02, 2013 at 06:15:11PM +0100, Aron Ahmadia wrote: > Just wanted to point out that I found out how to use submodules from > your pull request to pycuda. Thanks! Glad to help :). On Thu, May 02, 2013 at 10:28:51AM -0700, MinRK wrote: > Mirroring is a better case, since it shouldn't actually affect the > repo. But it seems pretty terrible that under normal circumstances, > no clone of any IPython repo other than the official one or a proper > careful mirror will actually be functional. I think ?proper careful mirror? is a bit alarmist ;). If it's just a single level of submodules (and it's currently just a single `components` submodule), all you have to do is mirror the submodules at the same place. For me: $ cd /var/git $ git clone git://github.com/ipython/ipython.git $ git clone git://github.com/ipython/ipython-components.git Working mirror complete ;). Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From wking at tremily.us Thu May 2 13:42:33 2013 From: wking at tremily.us (W. Trevor King) Date: Thu, 02 May 2013 13:42:33 -0400 Subject: [IPython-dev] submodules over https In-Reply-To: Message-ID: <20130502174233.GM15975@odin.tremily.us> On Thu, May 02, 2013 at 06:15:11PM +0100, Aron Ahmadia wrote: > Just wanted to point out that I found out how to use submodules from > your pull request to pycuda. Thanks! Glad to help :). On Thu, May 02, 2013 at 10:28:51AM -0700, MinRK wrote: > Mirroring is a better case, since it shouldn't actually affect the > repo. But it seems pretty terrible that under normal circumstances, > no clone of any IPython repo other than the official one or a proper > careful mirror will actually be functional. I think ?proper careful mirror? is a bit alarmist ;). If it's just a single level of submodules (and it's currently just a single `components` submodule), all you have to do is mirror the submodules at the same place. For me: $ cd /var/git $ git clone git://github.com/ipython/ipython.git $ git clone git://github.com/ipython/ipython-components.git Working mirror complete ;). Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From benjaminrk at gmail.com Thu May 2 13:48:30 2013 From: benjaminrk at gmail.com (MinRK) Date: Thu, 2 May 2013 10:48:30 -0700 Subject: [IPython-dev] submodules over https In-Reply-To: <20130502174233.GM15975@odin.tremily.us> References: <20130502174233.GM15975@odin.tremily.us> Message-ID: Maybe I am overestimating how many users actually want IPython to be installable from their own fork, rather than only ever being valid after merging into master. I don't mean to say that maintaining separate `components` is difficult, but it is tedious and unintuitive. Let's give relative URL a shot for now, and revisit the issue if there are actual problems (not counting the one I ran into when trying to write exactly this PR). On Thu, May 2, 2013 at 10:42 AM, W. Trevor King wrote: > On Thu, May 02, 2013 at 06:15:11PM +0100, Aron Ahmadia wrote: > > Just wanted to point out that I found out how to use submodules from > > your pull request to pycuda. Thanks! > > Glad to help :). > > On Thu, May 02, 2013 at 10:28:51AM -0700, MinRK wrote: > > Mirroring is a better case, since it shouldn't actually affect the > > repo. But it seems pretty terrible that under normal circumstances, > > no clone of any IPython repo other than the official one or a proper > > careful mirror will actually be functional. > > I think ?proper careful mirror? is a bit alarmist ;). If it's just a > single level of submodules (and it's currently just a single > `components` submodule), all you have to do is mirror the submodules > at the same place. For me: > > $ cd /var/git > $ git clone git://github.com/ipython/ipython.git > $ git clone git://github.com/ipython/ipython-components.git > > Working mirror complete ;). > > Cheers, > Trevor > > -- > This email may be signed or encrypted with GnuPG (http://www.gnupg.org). > For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Thu May 2 13:48:30 2013 From: benjaminrk at gmail.com (MinRK) Date: Thu, 2 May 2013 10:48:30 -0700 Subject: [IPython-dev] submodules over https In-Reply-To: <20130502174233.GM15975@odin.tremily.us> References: <20130502174233.GM15975@odin.tremily.us> Message-ID: Maybe I am overestimating how many users actually want IPython to be installable from their own fork, rather than only ever being valid after merging into master. I don't mean to say that maintaining separate `components` is difficult, but it is tedious and unintuitive. Let's give relative URL a shot for now, and revisit the issue if there are actual problems (not counting the one I ran into when trying to write exactly this PR). On Thu, May 2, 2013 at 10:42 AM, W. Trevor King wrote: > On Thu, May 02, 2013 at 06:15:11PM +0100, Aron Ahmadia wrote: > > Just wanted to point out that I found out how to use submodules from > > your pull request to pycuda. Thanks! > > Glad to help :). > > On Thu, May 02, 2013 at 10:28:51AM -0700, MinRK wrote: > > Mirroring is a better case, since it shouldn't actually affect the > > repo. But it seems pretty terrible that under normal circumstances, > > no clone of any IPython repo other than the official one or a proper > > careful mirror will actually be functional. > > I think ?proper careful mirror? is a bit alarmist ;). If it's just a > single level of submodules (and it's currently just a single > `components` submodule), all you have to do is mirror the submodules > at the same place. For me: > > $ cd /var/git > $ git clone git://github.com/ipython/ipython.git > $ git clone git://github.com/ipython/ipython-components.git > > Working mirror complete ;). > > Cheers, > Trevor > > -- > This email may be signed or encrypted with GnuPG (http://www.gnupg.org). > For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Thu May 2 14:00:30 2013 From: benjaminrk at gmail.com (MinRK) Date: Thu, 2 May 2013 11:00:30 -0700 Subject: [IPython-dev] submodules over https In-Reply-To: References: <20130502174233.GM15975@odin.tremily.us> Message-ID: actual problem hit immediately, changing the PR to just use `https:` instead of `git:` On Thu, May 2, 2013 at 10:48 AM, MinRK wrote: > Maybe I am overestimating how many users actually want IPython to be > installable from their own fork, rather than only ever being valid after > merging into master. I don't mean to say that maintaining separate > `components` is difficult, but it is tedious and unintuitive. > > Let's give relative URL a shot for now, and revisit the issue if there are > actual problems (not counting the one I ran into when trying to write > exactly this PR). > > > On Thu, May 2, 2013 at 10:42 AM, W. Trevor King wrote: > >> On Thu, May 02, 2013 at 06:15:11PM +0100, Aron Ahmadia wrote: >> > Just wanted to point out that I found out how to use submodules from >> > your pull request to pycuda. Thanks! >> >> Glad to help :). >> >> On Thu, May 02, 2013 at 10:28:51AM -0700, MinRK wrote: >> > Mirroring is a better case, since it shouldn't actually affect the >> > repo. But it seems pretty terrible that under normal circumstances, >> > no clone of any IPython repo other than the official one or a proper >> > careful mirror will actually be functional. >> >> I think ?proper careful mirror? is a bit alarmist ;). If it's just a >> single level of submodules (and it's currently just a single >> `components` submodule), all you have to do is mirror the submodules >> at the same place. For me: >> >> $ cd /var/git >> $ git clone git://github.com/ipython/ipython.git >> $ git clone git://github.com/ipython/ipython-components.git >> >> Working mirror complete ;). >> >> Cheers, >> Trevor >> >> -- >> This email may be signed or encrypted with GnuPG (http://www.gnupg.org). >> For more information, see >> http://en.wikipedia.org/wiki/Pretty_Good_Privacy >> >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Thu May 2 14:00:30 2013 From: benjaminrk at gmail.com (MinRK) Date: Thu, 2 May 2013 11:00:30 -0700 Subject: [IPython-dev] submodules over https In-Reply-To: References: <20130502174233.GM15975@odin.tremily.us> Message-ID: actual problem hit immediately, changing the PR to just use `https:` instead of `git:` On Thu, May 2, 2013 at 10:48 AM, MinRK wrote: > Maybe I am overestimating how many users actually want IPython to be > installable from their own fork, rather than only ever being valid after > merging into master. I don't mean to say that maintaining separate > `components` is difficult, but it is tedious and unintuitive. > > Let's give relative URL a shot for now, and revisit the issue if there are > actual problems (not counting the one I ran into when trying to write > exactly this PR). > > > On Thu, May 2, 2013 at 10:42 AM, W. Trevor King wrote: > >> On Thu, May 02, 2013 at 06:15:11PM +0100, Aron Ahmadia wrote: >> > Just wanted to point out that I found out how to use submodules from >> > your pull request to pycuda. Thanks! >> >> Glad to help :). >> >> On Thu, May 02, 2013 at 10:28:51AM -0700, MinRK wrote: >> > Mirroring is a better case, since it shouldn't actually affect the >> > repo. But it seems pretty terrible that under normal circumstances, >> > no clone of any IPython repo other than the official one or a proper >> > careful mirror will actually be functional. >> >> I think ?proper careful mirror? is a bit alarmist ;). If it's just a >> single level of submodules (and it's currently just a single >> `components` submodule), all you have to do is mirror the submodules >> at the same place. For me: >> >> $ cd /var/git >> $ git clone git://github.com/ipython/ipython.git >> $ git clone git://github.com/ipython/ipython-components.git >> >> Working mirror complete ;). >> >> Cheers, >> Trevor >> >> -- >> This email may be signed or encrypted with GnuPG (http://www.gnupg.org). >> For more information, see >> http://en.wikipedia.org/wiki/Pretty_Good_Privacy >> >> _______________________________________________ >> 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 ellisonbg at gmail.com Thu May 2 14:00:53 2013 From: ellisonbg at gmail.com (Brian Granger) Date: Thu, 2 May 2013 11:00:53 -0700 Subject: [IPython-dev] submodules over https In-Reply-To: References: <20130502174233.GM15975@odin.tremily.us> Message-ID: I don't think using relative submodule urls is a good idea. A common GitHub work flow when people start the contribute to a project is: 1, Fork ipython/ipython 2. Create a local clone of username/ipython 3. Branch and push to username/ipython 4. Create a PR This completely common workflow would require new devs to muck with the submodule url or also fork our submodules. I don't see that as acceptable as we want to minimize the friction for new people to contribute. Even forcing people to do "git submodule init && git submodule update" adds friction. So unless I am misunderstanding somethign, I am -1 on relative urls. Cheers, Brian On Thu, May 2, 2013 at 10:48 AM, MinRK wrote: > Maybe I am overestimating how many users actually want IPython to be > installable from their own fork, rather than only ever being valid after > merging into master. I don't mean to say that maintaining separate > `components` is difficult, but it is tedious and unintuitive. > > Let's give relative URL a shot for now, and revisit the issue if there are > actual problems (not counting the one I ran into when trying to write > exactly this PR). > > > On Thu, May 2, 2013 at 10:42 AM, W. Trevor King wrote: >> >> On Thu, May 02, 2013 at 06:15:11PM +0100, Aron Ahmadia wrote: >> > Just wanted to point out that I found out how to use submodules from >> > your pull request to pycuda. Thanks! >> >> Glad to help :). >> >> On Thu, May 02, 2013 at 10:28:51AM -0700, MinRK wrote: >> > Mirroring is a better case, since it shouldn't actually affect the >> > repo. But it seems pretty terrible that under normal circumstances, >> > no clone of any IPython repo other than the official one or a proper >> > careful mirror will actually be functional. >> >> I think ?proper careful mirror? is a bit alarmist ;). If it's just a >> single level of submodules (and it's currently just a single >> `components` submodule), all you have to do is mirror the submodules >> at the same place. For me: >> >> $ cd /var/git >> $ git clone git://github.com/ipython/ipython.git >> $ git clone git://github.com/ipython/ipython-components.git >> >> Working mirror complete ;). >> >> Cheers, >> Trevor >> >> -- >> This email may be signed or encrypted with GnuPG (http://www.gnupg.org). >> For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy >> >> _______________________________________________ >> 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 From ellisonbg at gmail.com Thu May 2 14:00:53 2013 From: ellisonbg at gmail.com (Brian Granger) Date: Thu, 2 May 2013 11:00:53 -0700 Subject: [IPython-dev] submodules over https In-Reply-To: References: <20130502174233.GM15975@odin.tremily.us> Message-ID: I don't think using relative submodule urls is a good idea. A common GitHub work flow when people start the contribute to a project is: 1, Fork ipython/ipython 2. Create a local clone of username/ipython 3. Branch and push to username/ipython 4. Create a PR This completely common workflow would require new devs to muck with the submodule url or also fork our submodules. I don't see that as acceptable as we want to minimize the friction for new people to contribute. Even forcing people to do "git submodule init && git submodule update" adds friction. So unless I am misunderstanding somethign, I am -1 on relative urls. Cheers, Brian On Thu, May 2, 2013 at 10:48 AM, MinRK wrote: > Maybe I am overestimating how many users actually want IPython to be > installable from their own fork, rather than only ever being valid after > merging into master. I don't mean to say that maintaining separate > `components` is difficult, but it is tedious and unintuitive. > > Let's give relative URL a shot for now, and revisit the issue if there are > actual problems (not counting the one I ran into when trying to write > exactly this PR). > > > On Thu, May 2, 2013 at 10:42 AM, W. Trevor King wrote: >> >> On Thu, May 02, 2013 at 06:15:11PM +0100, Aron Ahmadia wrote: >> > Just wanted to point out that I found out how to use submodules from >> > your pull request to pycuda. Thanks! >> >> Glad to help :). >> >> On Thu, May 02, 2013 at 10:28:51AM -0700, MinRK wrote: >> > Mirroring is a better case, since it shouldn't actually affect the >> > repo. But it seems pretty terrible that under normal circumstances, >> > no clone of any IPython repo other than the official one or a proper >> > careful mirror will actually be functional. >> >> I think ?proper careful mirror? is a bit alarmist ;). If it's just a >> single level of submodules (and it's currently just a single >> `components` submodule), all you have to do is mirror the submodules >> at the same place. For me: >> >> $ cd /var/git >> $ git clone git://github.com/ipython/ipython.git >> $ git clone git://github.com/ipython/ipython-components.git >> >> Working mirror complete ;). >> >> Cheers, >> Trevor >> >> -- >> This email may be signed or encrypted with GnuPG (http://www.gnupg.org). >> For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy >> >> _______________________________________________ >> 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 From aron at ahmadia.net Thu May 2 14:05:11 2013 From: aron at ahmadia.net (Aron Ahmadia) Date: Thu, 2 May 2013 19:05:11 +0100 Subject: [IPython-dev] submodules over https In-Reply-To: References: <20130502174233.GM15975@odin.tremily.us> Message-ID: Brian, >From what I understand of the intentions for the component submodule (most pull requests will not touch it), I think you're correct. *Even forcing people to do "git submodule init && git submodule update" adds friction.* * * Tell them to do: git clone --recursive ipython/ipython # this does the submodule init/update bits for you Submodules add an unfriendly level of complexity, but it turns out that version control is a hard problem :/ A On Thu, May 2, 2013 at 7:00 PM, Brian Granger wrote: > I don't think using relative submodule urls is a good idea. A common > GitHub work flow when people start the contribute to a project is: > > 1, Fork ipython/ipython > 2. Create a local clone of username/ipython > 3. Branch and push to username/ipython > 4. Create a PR > > This completely common workflow would require new devs to muck with > the submodule url or also fork our submodules. I don't see that as > acceptable as we want to minimize the friction for new people to > contribute. Even forcing people to do "git submodule init && git > submodule update" adds friction. > > So unless I am misunderstanding somethign, I am -1 on relative urls. > > Cheers, > > Brian > > On Thu, May 2, 2013 at 10:48 AM, MinRK wrote: > > Maybe I am overestimating how many users actually want IPython to be > > installable from their own fork, rather than only ever being valid after > > merging into master. I don't mean to say that maintaining separate > > `components` is difficult, but it is tedious and unintuitive. > > > > Let's give relative URL a shot for now, and revisit the issue if there > are > > actual problems (not counting the one I ran into when trying to write > > exactly this PR). > > > > > > On Thu, May 2, 2013 at 10:42 AM, W. Trevor King > wrote: > >> > >> On Thu, May 02, 2013 at 06:15:11PM +0100, Aron Ahmadia wrote: > >> > Just wanted to point out that I found out how to use submodules from > >> > your pull request to pycuda. Thanks! > >> > >> Glad to help :). > >> > >> On Thu, May 02, 2013 at 10:28:51AM -0700, MinRK wrote: > >> > Mirroring is a better case, since it shouldn't actually affect the > >> > repo. But it seems pretty terrible that under normal circumstances, > >> > no clone of any IPython repo other than the official one or a proper > >> > careful mirror will actually be functional. > >> > >> I think ?proper careful mirror? is a bit alarmist ;). If it's just a > >> single level of submodules (and it's currently just a single > >> `components` submodule), all you have to do is mirror the submodules > >> at the same place. For me: > >> > >> $ cd /var/git > >> $ git clone git://github.com/ipython/ipython.git > >> $ git clone git://github.com/ipython/ipython-components.git > >> > >> Working mirror complete ;). > >> > >> Cheers, > >> Trevor > >> > >> -- > >> This email may be signed or encrypted with GnuPG (http://www.gnupg.org > ). > >> For more information, see > http://en.wikipedia.org/wiki/Pretty_Good_Privacy > >> > >> _______________________________________________ > >> 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 > _______________________________________________ > 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 aron at ahmadia.net Thu May 2 14:05:11 2013 From: aron at ahmadia.net (Aron Ahmadia) Date: Thu, 2 May 2013 19:05:11 +0100 Subject: [IPython-dev] submodules over https In-Reply-To: References: <20130502174233.GM15975@odin.tremily.us> Message-ID: Brian, >From what I understand of the intentions for the component submodule (most pull requests will not touch it), I think you're correct. *Even forcing people to do "git submodule init && git submodule update" adds friction.* * * Tell them to do: git clone --recursive ipython/ipython # this does the submodule init/update bits for you Submodules add an unfriendly level of complexity, but it turns out that version control is a hard problem :/ A On Thu, May 2, 2013 at 7:00 PM, Brian Granger wrote: > I don't think using relative submodule urls is a good idea. A common > GitHub work flow when people start the contribute to a project is: > > 1, Fork ipython/ipython > 2. Create a local clone of username/ipython > 3. Branch and push to username/ipython > 4. Create a PR > > This completely common workflow would require new devs to muck with > the submodule url or also fork our submodules. I don't see that as > acceptable as we want to minimize the friction for new people to > contribute. Even forcing people to do "git submodule init && git > submodule update" adds friction. > > So unless I am misunderstanding somethign, I am -1 on relative urls. > > Cheers, > > Brian > > On Thu, May 2, 2013 at 10:48 AM, MinRK wrote: > > Maybe I am overestimating how many users actually want IPython to be > > installable from their own fork, rather than only ever being valid after > > merging into master. I don't mean to say that maintaining separate > > `components` is difficult, but it is tedious and unintuitive. > > > > Let's give relative URL a shot for now, and revisit the issue if there > are > > actual problems (not counting the one I ran into when trying to write > > exactly this PR). > > > > > > On Thu, May 2, 2013 at 10:42 AM, W. Trevor King > wrote: > >> > >> On Thu, May 02, 2013 at 06:15:11PM +0100, Aron Ahmadia wrote: > >> > Just wanted to point out that I found out how to use submodules from > >> > your pull request to pycuda. Thanks! > >> > >> Glad to help :). > >> > >> On Thu, May 02, 2013 at 10:28:51AM -0700, MinRK wrote: > >> > Mirroring is a better case, since it shouldn't actually affect the > >> > repo. But it seems pretty terrible that under normal circumstances, > >> > no clone of any IPython repo other than the official one or a proper > >> > careful mirror will actually be functional. > >> > >> I think ?proper careful mirror? is a bit alarmist ;). If it's just a > >> single level of submodules (and it's currently just a single > >> `components` submodule), all you have to do is mirror the submodules > >> at the same place. For me: > >> > >> $ cd /var/git > >> $ git clone git://github.com/ipython/ipython.git > >> $ git clone git://github.com/ipython/ipython-components.git > >> > >> Working mirror complete ;). > >> > >> Cheers, > >> Trevor > >> > >> -- > >> This email may be signed or encrypted with GnuPG (http://www.gnupg.org > ). > >> For more information, see > http://en.wikipedia.org/wiki/Pretty_Good_Privacy > >> > >> _______________________________________________ > >> 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 > _______________________________________________ > 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 wking at tremily.us Thu May 2 16:24:57 2013 From: wking at tremily.us (W. Trevor King) Date: Thu, 02 May 2013 16:24:57 -0400 Subject: [IPython-dev] submodules over https In-Reply-To: References: <20130502174233.GM15975@odin.tremily.us> Message-ID: <20130502202457.GN15975@odin.tremily.us> On Thu, May 02, 2013 at 07:05:11PM +0100, Aron Ahmadia wrote: > *Even forcing people to do "git submodule init && git > submodule update" adds friction.* > * > * > Tell them to do: > > git clone --recursive ipython/ipython # this does the submodule > init/update bits for you Brian raises a good point. When I start working on a new project, I usually clone upstream. If I actually write a useful PR, I fork on GitHub (via `hub fork`). With this approach, the relative submodules work fine. If you *start* your development with a fork on GitHub and subsequent local clone of your fork, you're going to run into problems with relative submodule URLs. If we already have IPythonistas that have tripped over this problem, hard coded URLs may be the way to go. > Submodules add an unfriendly level of complexity, but it turns out > that version control is a hard problem :/ I think it's mostly that submodules were designed for a distribution management perspective, so pulling in lots of optional submodules with loose bindings between them is easy. Making submodularization transparent (strong bindings) is more difficult, although there's been a lot of work upstream over the past few months to make submodules more of a first class citizen: git$ git log --all --oneline --grep submodule --since=2013-02-01 | wc -l 68 Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From wking at tremily.us Thu May 2 16:24:57 2013 From: wking at tremily.us (W. Trevor King) Date: Thu, 02 May 2013 16:24:57 -0400 Subject: [IPython-dev] submodules over https In-Reply-To: References: <20130502174233.GM15975@odin.tremily.us> Message-ID: <20130502202457.GN15975@odin.tremily.us> On Thu, May 02, 2013 at 07:05:11PM +0100, Aron Ahmadia wrote: > *Even forcing people to do "git submodule init && git > submodule update" adds friction.* > * > * > Tell them to do: > > git clone --recursive ipython/ipython # this does the submodule > init/update bits for you Brian raises a good point. When I start working on a new project, I usually clone upstream. If I actually write a useful PR, I fork on GitHub (via `hub fork`). With this approach, the relative submodules work fine. If you *start* your development with a fork on GitHub and subsequent local clone of your fork, you're going to run into problems with relative submodule URLs. If we already have IPythonistas that have tripped over this problem, hard coded URLs may be the way to go. > Submodules add an unfriendly level of complexity, but it turns out > that version control is a hard problem :/ I think it's mostly that submodules were designed for a distribution management perspective, so pulling in lots of optional submodules with loose bindings between them is easy. Making submodularization transparent (strong bindings) is more difficult, although there's been a lot of work upstream over the past few months to make submodules more of a first class citizen: git$ git log --all --oneline --grep submodule --since=2013-02-01 | wc -l 68 Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From benjaminrk at gmail.com Thu May 2 16:45:09 2013 From: benjaminrk at gmail.com (MinRK) Date: Thu, 2 May 2013 13:45:09 -0700 Subject: [IPython-dev] submodules over https In-Reply-To: <20130502202457.GN15975@odin.tremily.us> References: <20130502174233.GM15975@odin.tremily.us> <20130502202457.GN15975@odin.tremily.us> Message-ID: On Thu, May 2, 2013 at 1:24 PM, W. Trevor King wrote: > On Thu, May 02, 2013 at 07:05:11PM +0100, Aron Ahmadia wrote: > > *Even forcing people to do "git submodule init && git > > submodule update" adds friction.* > > * > > * > > Tell them to do: > > > > git clone --recursive ipython/ipython # this does the submodule > > init/update bits for you > > Brian raises a good point. When I start working on a new project, I > usually clone upstream. If I actually write a useful PR, I fork on > GitHub (via `hub fork`). With this approach, the relative submodules > work fine. > This is how I work as well, and why I was persuaded by your argument until I heard from Brian. > > If you *start* your development with a fork on GitHub and subsequent > local clone of your fork, you're going to run into problems with > relative submodule URLs. If we already have IPythonistas that have > tripped over this problem, hard coded URLs may be the way to go. > > > Submodules add an unfriendly level of complexity, but it turns out > > that version control is a hard problem :/ > > I think it's mostly that submodules were designed for a distribution > management perspective, so pulling in lots of optional submodules with > loose bindings between them is easy. Making submodularization > transparent (strong bindings) is more difficult, although there's been > a lot of work upstream over the past few months to make submodules > more of a first class citizen: > > git$ git log --all --oneline --grep submodule --since=2013-02-01 | wc -l > 68 > Thanks for your help guys, we are a bit new to this stuff. > > Cheers, > Trevor > > -- > This email may be signed or encrypted with GnuPG (http://www.gnupg.org). > For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Thu May 2 16:45:09 2013 From: benjaminrk at gmail.com (MinRK) Date: Thu, 2 May 2013 13:45:09 -0700 Subject: [IPython-dev] submodules over https In-Reply-To: <20130502202457.GN15975@odin.tremily.us> References: <20130502174233.GM15975@odin.tremily.us> <20130502202457.GN15975@odin.tremily.us> Message-ID: On Thu, May 2, 2013 at 1:24 PM, W. Trevor King wrote: > On Thu, May 02, 2013 at 07:05:11PM +0100, Aron Ahmadia wrote: > > *Even forcing people to do "git submodule init && git > > submodule update" adds friction.* > > * > > * > > Tell them to do: > > > > git clone --recursive ipython/ipython # this does the submodule > > init/update bits for you > > Brian raises a good point. When I start working on a new project, I > usually clone upstream. If I actually write a useful PR, I fork on > GitHub (via `hub fork`). With this approach, the relative submodules > work fine. > This is how I work as well, and why I was persuaded by your argument until I heard from Brian. > > If you *start* your development with a fork on GitHub and subsequent > local clone of your fork, you're going to run into problems with > relative submodule URLs. If we already have IPythonistas that have > tripped over this problem, hard coded URLs may be the way to go. > > > Submodules add an unfriendly level of complexity, but it turns out > > that version control is a hard problem :/ > > I think it's mostly that submodules were designed for a distribution > management perspective, so pulling in lots of optional submodules with > loose bindings between them is easy. Making submodularization > transparent (strong bindings) is more difficult, although there's been > a lot of work upstream over the past few months to make submodules > more of a first class citizen: > > git$ git log --all --oneline --grep submodule --since=2013-02-01 | wc -l > 68 > Thanks for your help guys, we are a bit new to this stuff. > > Cheers, > Trevor > > -- > This email may be signed or encrypted with GnuPG (http://www.gnupg.org). > For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Fri May 3 01:25:30 2013 From: benjaminrk at gmail.com (MinRK) Date: Thu, 2 May 2013 22:25:30 -0700 Subject: [IPython-dev] git submodules Message-ID: As of this week, IPython now gets its third-party javascript dependencies from a git submodule. This adds an extra wrinkle to using IPython from git, but the basics all work: git clone git://github.com/ipython/ipython.git cd ipython && python setup.py install # or cd ipython && python setup.py develop # or one step with pip: pip install -e git://github.com/ipython/ipython.git#egg=ipython But where you might get tripped up is updating an existing repo via `git pull`, which does not update the submodule (the plan is for this to be needed very rarely, but it will come up, especially now that the submodule is new). The gist is that if you get 404s on files in `static/components` while running the notebook, the first thing to try is: python setup.py submodule which just does git submodule init git submodule update --recursive to make sure that the components submodule is up to date. We will try to get this as automatic as we can, so that we trip up / confuse / annoy as few people as possible, but we are figuring things out as we go right now. -MinRK -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsdale24 at gmail.com Fri May 3 14:01:58 2013 From: dsdale24 at gmail.com (Darren Dale) Date: Fri, 3 May 2013 14:01:58 -0400 Subject: [IPython-dev] git submodules In-Reply-To: References: Message-ID: Min, Did you also consider using git subtrees? On Fri, May 3, 2013 at 1:25 AM, MinRK wrote: > As of this week, IPython now gets its third-party javascript dependencies > from a git submodule. > This adds an extra wrinkle to using IPython from git, but the basics all > work: > > git clone git://github.com/ipython/ipython.git > cd ipython && python setup.py install > # or > cd ipython && python setup.py develop > > # or one step with pip: > > pip install -e git://github.com/ipython/ipython.git#egg=ipython > > But where you might get tripped up is updating an existing repo via `git > pull`, which does not update the submodule (the plan is for this to be > needed very rarely, but it will come up, especially now that the submodule > is new). The gist is that if you get 404s on files in `static/components` > while running the notebook, the first thing to try is: > > python setup.py submodule > > which just does > > git submodule init > git submodule update --recursive > > to make sure that the components submodule is up to date. > > We will try to get this as automatic as we can, so that we trip up / confuse > / annoy as few people as possible, but we are figuring things out as we go > right now. > > -MinRK > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > From benjaminrk at gmail.com Fri May 3 14:28:14 2013 From: benjaminrk at gmail.com (MinRK) Date: Fri, 3 May 2013 11:28:14 -0700 Subject: [IPython-dev] git submodules In-Reply-To: References: Message-ID: No, we didn't. They look promising, but I can't find any sufficiently helpful documentation about what they actually do. I will have a look at whether they might be preferable - it certainly seems so. On Fri, May 3, 2013 at 11:01 AM, Darren Dale wrote: > Min, > > Did you also consider using git subtrees? > > On Fri, May 3, 2013 at 1:25 AM, MinRK wrote: > > As of this week, IPython now gets its third-party javascript dependencies > > from a git submodule. > > This adds an extra wrinkle to using IPython from git, but the basics all > > work: > > > > git clone git://github.com/ipython/ipython.git > > cd ipython && python setup.py install > > # or > > cd ipython && python setup.py develop > > > > # or one step with pip: > > > > pip install -e git://github.com/ipython/ipython.git#egg=ipython > > > > But where you might get tripped up is updating an existing repo via `git > > pull`, which does not update the submodule (the plan is for this to be > > needed very rarely, but it will come up, especially now that the > submodule > > is new). The gist is that if you get 404s on files in > `static/components` > > while running the notebook, the first thing to try is: > > > > python setup.py submodule > > > > which just does > > > > git submodule init > > git submodule update --recursive > > > > to make sure that the components submodule is up to date. > > > > We will try to get this as automatic as we can, so that we trip up / > confuse > > / annoy as few people as possible, but we are figuring things out as we > go > > right now. > > > > -MinRK > > > > _______________________________________________ > > IPython-dev mailing list > > IPython-dev at scipy.org > > http://mail.scipy.org/mailman/listinfo/ipython-dev > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Fri May 3 14:34:22 2013 From: benjaminrk at gmail.com (MinRK) Date: Fri, 3 May 2013 11:34:22 -0700 Subject: [IPython-dev] git submodules In-Reply-To: References: Message-ID: Ah - git subtrees actually add all of the files in the other repo in every sync commit - so this is really just doing exactly what we had before, just adding another repo to the mix. There isn't much benefit to subtrees in our case, then. On Fri, May 3, 2013 at 11:28 AM, MinRK wrote: > No, we didn't. They look promising, but I can't find any sufficiently > helpful documentation about what they actually do. I will have a look at > whether they might be preferable - it certainly seems so. > > > On Fri, May 3, 2013 at 11:01 AM, Darren Dale wrote: > >> Min, >> >> Did you also consider using git subtrees? >> >> On Fri, May 3, 2013 at 1:25 AM, MinRK wrote: >> > As of this week, IPython now gets its third-party javascript >> dependencies >> > from a git submodule. >> > This adds an extra wrinkle to using IPython from git, but the basics all >> > work: >> > >> > git clone git://github.com/ipython/ipython.git >> > cd ipython && python setup.py install >> > # or >> > cd ipython && python setup.py develop >> > >> > # or one step with pip: >> > >> > pip install -e git://github.com/ipython/ipython.git#egg=ipython >> > >> > But where you might get tripped up is updating an existing repo via `git >> > pull`, which does not update the submodule (the plan is for this to be >> > needed very rarely, but it will come up, especially now that the >> submodule >> > is new). The gist is that if you get 404s on files in >> `static/components` >> > while running the notebook, the first thing to try is: >> > >> > python setup.py submodule >> > >> > which just does >> > >> > git submodule init >> > git submodule update --recursive >> > >> > to make sure that the components submodule is up to date. >> > >> > We will try to get this as automatic as we can, so that we trip up / >> confuse >> > / annoy as few people as possible, but we are figuring things out as we >> go >> > right now. >> > >> > -MinRK >> > >> > _______________________________________________ >> > IPython-dev mailing list >> > IPython-dev at scipy.org >> > http://mail.scipy.org/mailman/listinfo/ipython-dev >> > >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Mon May 6 17:05:53 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 6 May 2013 14:05:53 -0700 Subject: [IPython-dev] IPython mini-book is out! Message-ID: Hi all, you may have already noticed it on the site, but it's worth making official mention of this; the first book that's directly focused on IPython is now out: "Learning IPython for Interactive Computing and Data Visualization", by Cyrille Rossant: http://ipython.rossant.net The publisher page is here: http://www.packtpub.com/learning-ipython-for-interactive-computing-and-data-visualization/book And amongst other cool things, it's accompanied by a github repo that contains all examples in the book (scripts and notebooks): https://github.com/rossant/ipython-minibook Our own Matthias Bussonnier was one of the technical reviewers for the book, which I've also had a chance to see in pre-print form. My first impressions are that it's a great hands-on introduction to using IPython effectively along with the 'scipy stack', in a condensed format. The whole book is ~ 120 pages of actual text (plus tables and index), so it's a quick read meant to get you off the ground quickly and effectively. I am obviously thrilled to see this happen, and I hope it will be very useful to the community at large. I'd also like to thank Packt publishing, who have sent courtesy copies of the book to the entire core development team and will donate a portion of the royalties to support IPython development, as part of their policy of supporting all open-source projects for which they publish books (http://www.packtpub.com/open-source). Cheers, f From fereyes at lbl.gov Tue May 7 01:01:50 2013 From: fereyes at lbl.gov (Francis Reyes) Date: Mon, 6 May 2013 22:01:50 -0700 Subject: [IPython-dev] Vim key bindings ... Message-ID: Hi all, I've been tooling around in ipython notebook the past few days and like what I see. Two (hopefully straightforward) questions 1. Whatever happened to the vim key bindings proposal http://mail.scipy.org/pipermail/ipython-dev/2012-January/008665.html? 2. Is it possible to start ipython notebook from *within* a python session? I have a few programs that embed a python interpreter, and this I cannot run ipython notebook from the command line. Keep up the great work, F Francis Reyes Advanced Light Source 1 Cyclotron Road Berkeley, CA 94720 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jtratner at gmail.com Tue May 7 01:34:17 2013 From: jtratner at gmail.com (Jeffrey Tratner) Date: Tue, 7 May 2013 01:34:17 -0400 Subject: [IPython-dev] Vim key bindings ... In-Reply-To: References: Message-ID: It'd be great to have #2 spelled out in the docs somewhere too. On May 7, 2013 1:02 AM, "Francis Reyes" wrote: > Hi all, > > I've been tooling around in ipython notebook the past few days and like > what I see. > > Two (hopefully straightforward) questions > > 1. Whatever happened to the vim key bindings proposal > http://mail.scipy.org/pipermail/ipython-dev/2012-January/008665.html? > > 2. Is it possible to start ipython notebook from *within* a python > session? I have a few programs that embed a python interpreter, and this I > cannot run ipython notebook from the command line. > > Keep up the great work, > > F > > Francis Reyes > Advanced Light Source > 1 Cyclotron Road > Berkeley, CA 94720 > > _______________________________________________ > 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 May 7 08:36:43 2013 From: takowl at gmail.com (Thomas Kluyver) Date: Tue, 7 May 2013 13:36:43 +0100 Subject: [IPython-dev] Vim key bindings ... In-Reply-To: References: Message-ID: In a literal sense, you can start the notebook server from any Python process, but it's probably not what you want. The kernel will be started in a separate process, so you won't have access to any variables from your existing process. There's a way to embed an IPython kernel into a process (e.g. [1]) and connect a Qt console to it, but I'm not sure if there's a convenient way to open a notebook to an existing kernel. [1] https://github.com/ipython/ipython/blob/master/examples/lib/ipkernel_qtapp.py Thomas On 7 May 2013 06:34, Jeffrey Tratner wrote: > It'd be great to have #2 spelled out in the docs somewhere too. > On May 7, 2013 1:02 AM, "Francis Reyes" wrote: > >> Hi all, >> >> I've been tooling around in ipython notebook the past few days and like >> what I see. >> >> Two (hopefully straightforward) questions >> >> 1. Whatever happened to the vim key bindings proposal >> http://mail.scipy.org/pipermail/ipython-dev/2012-January/008665.html? >> >> 2. Is it possible to start ipython notebook from *within* a python >> session? I have a few programs that embed a python interpreter, and this I >> cannot run ipython notebook from the command line. >> >> Keep up the great work, >> >> F >> >> Francis Reyes >> Advanced Light Source >> 1 Cyclotron Road >> Berkeley, CA 94720 >> >> _______________________________________________ >> 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 stanton at haas.berkeley.edu Tue May 7 23:04:13 2013 From: stanton at haas.berkeley.edu (Richard Stanton) Date: Wed, 8 May 2013 03:04:13 +0000 Subject: [IPython-dev] matplotlibrc seems to be ignored from IPython notebook Message-ID: I want to increase the default setting of saved matplotlib graphs, so I created a file ~/.matplotlib/matplotlibrc containing the line savefigdpi : 300 I then created a test notebook containing a single cell with the contents import numpy as np import matplotlib.pyplot as plt x = np.array([1,2,3]) y = np.array([4,5,6]) plt.plot(x,y) plt.savefig('d0.png') plt.savefig('d300.png',dpi=300) When I run this within the notebook, the two png files are created fine, but have different sizes. When I run the same code from the command line (after saving the same commands to a script file testplot.py), using ipython testplot.py the two graphs have the same size, as desired. Does matplotlib ignore the contents of ~/.matplotlib/matplotlibrc when called from an Ipython notebook? By the way, this is using matplotlib 1.2.0 and Ipython 0.13.2, if it makes any difference. Thanks for any help. Richard Stanton From benjaminrk at gmail.com Tue May 7 23:36:18 2013 From: benjaminrk at gmail.com (MinRK) Date: Tue, 7 May 2013 20:36:18 -0700 Subject: [IPython-dev] matplotlibrc seems to be ignored from IPython notebook In-Reply-To: References: Message-ID: It is not ignored, but IPython sets a few of its own defaults with the InlineBackend.rc config . One of these is savefig.dpi. You can prevent this by simply clearing the inline backend rc with: c.InlineBackend.rc = {} in your config file. On Tue, May 7, 2013 at 8:04 PM, Richard Stanton wrote: > I want to increase the default setting of saved matplotlib graphs, so I > created a file ~/.matplotlib/matplotlibrc containing the line > > savefigdpi : 300 > > I then created a test notebook containing a single cell with the contents > > import numpy as np > import matplotlib.pyplot as plt > x = np.array([1,2,3]) > y = np.array([4,5,6]) > plt.plot(x,y) > plt.savefig('d0.png') > plt.savefig('d300.png',dpi=300) > > > When I run this within the notebook, the two png files are created fine, > but have different sizes. When I run the same code from the command line > (after saving the same commands to a script file testplot.py), using > > ipython testplot.py > > the two graphs have the same size, as desired. Does matplotlib ignore the > contents of ~/.matplotlib/matplotlibrc when called from an Ipython > notebook? > > By the way, this is using matplotlib 1.2.0 and Ipython 0.13.2, if it makes > any difference. > > Thanks for any help. > > Richard Stanton > > > > _______________________________________________ > 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 krastanov.stefan at gmail.com Wed May 8 05:02:04 2013 From: krastanov.stefan at gmail.com (Stefan Krastanov) Date: Wed, 8 May 2013 11:02:04 +0200 Subject: [IPython-dev] _repr_javascript_ code samples for D3 Message-ID: Hi all, I have seen a nice visualization of networkx graph through d3.js in the notebook. I want to use D3 to visualize some other objects. I guess I should use `_repr_javascript_` but I do not know how the scoping of javascript libraries works, how much is sandboxed by the notebook, where to include the library, etc. I was hoping that you can point me to a code sample that does it The Right Way(TM). A quick code search on github did not return anything useful. Regards Stefan From stanton at haas.berkeley.edu Wed May 8 12:20:45 2013 From: stanton at haas.berkeley.edu (Richard Stanton) Date: Wed, 8 May 2013 16:20:45 +0000 Subject: [IPython-dev] matplotlibrc seems to be ignored from IPython notebook In-Reply-To: Message-ID: A quick follow-up: Even in an Ipython notebook, the code works as expected if I start the notebook server with the command ipython notebook --pylab It fails (i.e., it ignores the dpi settings in matplotlibrc) if I start the notebook server with the command ipython notebook --pylab inline So the problem seems to be with the use of the inline option. On 5/7/13 8:04 PM, "Richard Stanton" wrote: >I want to increase the default setting of saved matplotlib graphs, so I >created a file ~/.matplotlib/matplotlibrc containing the line > >savefigdpi : 300 > >I then created a test notebook containing a single cell with the contents > >import numpy as np >import matplotlib.pyplot as plt >x = np.array([1,2,3]) >y = np.array([4,5,6]) >plt.plot(x,y) >plt.savefig('d0.png') >plt.savefig('d300.png',dpi=300) > > >When I run this within the notebook, the two png files are created fine, >but have different sizes. When I run the same code from the command line >(after saving the same commands to a script file testplot.py), using > >ipython testplot.py > >the two graphs have the same size, as desired. Does matplotlib ignore the >contents of ~/.matplotlib/matplotlibrc when called from an Ipython >notebook? > >By the way, this is using matplotlib 1.2.0 and Ipython 0.13.2, if it makes >any difference. > >Thanks for any help. > >Richard Stanton > > > From benjaminrk at gmail.com Wed May 8 12:28:23 2013 From: benjaminrk at gmail.com (Min RK) Date: Wed, 8 May 2013 09:28:23 -0700 Subject: [IPython-dev] matplotlibrc seems to be ignored from IPython notebook In-Reply-To: References: Message-ID: <09EF48D5-645E-45AB-A4A7-4EC646D23421@gmail.com> Did you not receive my reply yesterday? Yes, it is only the inline backend that sets a few defaults. Resending: It is not ignored, but IPython sets a few of its own defaults with the InlineBackend.rc config . One of these is savefig.dpi. You can prevent this by simply clearing the inline backend rc with: c.InlineBackend.rc = {} in your config file. -MinRK On May 8, 2013, at 9:20, Richard Stanton wrote: > A quick follow-up: > > Even in an Ipython notebook, the code works as expected if I start the > notebook server with the command > > ipython notebook --pylab > > It fails (i.e., it ignores the dpi settings in matplotlibrc) if I start > the notebook server with the command > > ipython notebook --pylab inline > > So the problem seems to be with the use of the inline option. > > > > > > > On 5/7/13 8:04 PM, "Richard Stanton" wrote: > >> I want to increase the default setting of saved matplotlib graphs, so I >> created a file ~/.matplotlib/matplotlibrc containing the line >> >> savefigdpi : 300 >> >> I then created a test notebook containing a single cell with the contents >> >> import numpy as np >> import matplotlib.pyplot as plt >> x = np.array([1,2,3]) >> y = np.array([4,5,6]) >> plt.plot(x,y) >> plt.savefig('d0.png') >> plt.savefig('d300.png',dpi=300) >> >> >> When I run this within the notebook, the two png files are created fine, >> but have different sizes. When I run the same code from the command line >> (after saving the same commands to a script file testplot.py), using >> >> ipython testplot.py >> >> the two graphs have the same size, as desired. Does matplotlib ignore the >> contents of ~/.matplotlib/matplotlibrc when called from an Ipython >> notebook? >> >> By the way, this is using matplotlib 1.2.0 and Ipython 0.13.2, if it makes >> any difference. >> >> Thanks for any help. >> >> Richard Stanton > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From stanton at haas.berkeley.edu Wed May 8 13:17:21 2013 From: stanton at haas.berkeley.edu (Richard Stanton) Date: Wed, 8 May 2013 17:17:21 +0000 Subject: [IPython-dev] matplotlibrc seems to be ignored from IPython notebook In-Reply-To: Message-ID: >From: MinRK > >It is not ignored, but IPython sets a few of its own defaults with the >InlineBackend.rc config . One of these is savefig.dpi. You can prevent >this by simply clearing the inline backend rc with: > >c.InlineBackend.rc = {} > >in your config file. ----- Thanks. That makes sense, but when I put that line in a (new) file called ~/ipy_user_conf.py, the plotting behavior is the same as before. Should I have edited a different configuration file? From benjaminrk at gmail.com Wed May 8 13:18:32 2013 From: benjaminrk at gmail.com (MinRK) Date: Wed, 8 May 2013 10:18:32 -0700 Subject: [IPython-dev] matplotlibrc seems to be ignored from IPython notebook In-Reply-To: References: Message-ID: ipy_user_conf.py hasn't had any effect for a few years now (since 0.11). It should be in ipython_config or ipython_notebook_config (start with `ipython profile create`) On Wed, May 8, 2013 at 10:17 AM, Richard Stanton wrote: > > >From: MinRK > > > >It is not ignored, but IPython sets a few of its own defaults with the > >InlineBackend.rc config . One of these is savefig.dpi. You can prevent > >this by simply clearing the inline backend rc with: > > > >c.InlineBackend.rc = {} > > > >in your config file. > > ----- > > Thanks. That makes sense, but when I put that line in a (new) file called > ~/ipy_user_conf.py, the plotting behavior is the same as before. Should I > have edited a different configuration file? > > > > _______________________________________________ > 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 Wed May 8 13:18:45 2013 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 8 May 2013 18:18:45 +0100 Subject: [IPython-dev] matplotlibrc seems to be ignored from IPython notebook In-Reply-To: References: Message-ID: On 8 May 2013 18:17, Richard Stanton wrote: > Thanks. That makes sense, but when I put that line in a (new) file called > ~/ipy_user_conf.py, the plotting behavior is the same as before. Should I > have edited a different configuration file? > Yep, ipy_user_conf.py is from old versions of IPython - look for a file ipython_config.py. If you haven't modified it before, run 'ipython profile create' to create it. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick.surry at gmail.com Wed May 8 13:35:06 2013 From: patrick.surry at gmail.com (Patrick Surry) Date: Wed, 8 May 2013 13:35:06 -0400 Subject: [IPython-dev] Example of a minimal custom IPython client? Message-ID: <8CE43504-2815-44C1-A663-E04728C0BD62@gmail.com> I've become a big fan of IPython + pandas for data analysis, and have got interested in the idea of building a simple UI for end-user interaction with pandas DataFrame and Series objects. The idea being to streamline the initial exploratory data analysis process. Sort of like an object-specific "watch" window that you'd use in a debugger. It seems like the IPython communication model is ideal for that kind of thing, so I could potentially build a little UI analogous to the qtconsole which could subscribe to the server process and watch whatever object I'm interested in, and maybe have UI elements that issued python statements back to the server. But I'm new to the dev side of IPython and haven't figured out where to start. I'm curious to know if anyone has done anything like that before, and whether there are any examples I could work from. Perhaps the "Hello World" of custom IPython clients? Advice welcome, Thanks, Patrick From gvwilson at third-bit.com Wed May 8 13:49:16 2013 From: gvwilson at third-bit.com (Greg Wilson) Date: Wed, 08 May 2013 13:49:16 -0400 Subject: [IPython-dev] Example of a minimal custom IPython client? In-Reply-To: <8CE43504-2815-44C1-A663-E04728C0BD62@gmail.com> References: <8CE43504-2815-44C1-A663-E04728C0BD62@gmail.com> Message-ID: <518A901C.60200@third-bit.com> Small world :-) - G On 2013-05-08 1:35 PM, Patrick Surry wrote: > I've become a big fan of IPython + pandas for data analysis, and have got interested in the idea of building a simple UI for end-user interaction with pandas DataFrame and Series objects. The idea being to streamline the initial exploratory data analysis process. Sort of like an object-specific "watch" window that you'd use in a debugger. > > It seems like the IPython communication model is ideal for that kind of thing, so I could potentially build a little UI analogous to the qtconsole which could subscribe to the server process and watch whatever object I'm interested in, and maybe have UI elements that issued python statements back to the server. But I'm new to the dev side of IPython and haven't figured out where to start. > > I'm curious to know if anyone has done anything like that before, and whether there are any examples I could work from. Perhaps the "Hello World" of custom IPython clients? > > Advice welcome, > > Thanks, > Patrick > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From takowl at gmail.com Wed May 8 17:38:50 2013 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 8 May 2013 22:38:50 +0100 Subject: [IPython-dev] Example of a minimal custom IPython client? In-Reply-To: <518A901C.60200@third-bit.com> References: <8CE43504-2815-44C1-A663-E04728C0BD62@gmail.com> <518A901C.60200@third-bit.com> Message-ID: It's an interesting idea. Unfortunately, there's nothing in the message spec to subscribe to updates on a particular object or group of objects, and I can't off the top of my head think how we'd add that. You could send the object of interest to the frontend after each execution in the kernel, although that could be inefficient if you have a large object that you're making frequent changes to. I think all our frontends so far are designed around entering and running code. You could have a look at how Spyder's object inspector is implemented, though. Best wishes, Thomas On 8 May 2013 18:49, Greg Wilson wrote: > Small world :-) > - G > > On 2013-05-08 1:35 PM, Patrick Surry wrote: > > I've become a big fan of IPython + pandas for data analysis, and have > got interested in the idea of building a simple UI for end-user interaction > with pandas DataFrame and Series objects. The idea being to streamline the > initial exploratory data analysis process. Sort of like an object-specific > "watch" window that you'd use in a debugger. > > > > It seems like the IPython communication model is ideal for that kind of > thing, so I could potentially build a little UI analogous to the qtconsole > which could subscribe to the server process and watch whatever object I'm > interested in, and maybe have UI elements that issued python statements > back to the server. But I'm new to the dev side of IPython and haven't > figured out where to start. > > > > I'm curious to know if anyone has done anything like that before, and > whether there are any examples I could work from. Perhaps the "Hello > World" of custom IPython clients? > > > > Advice welcome, > > > > Thanks, > > Patrick > > > > _______________________________________________ > > 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 benjaminrk at gmail.com Wed May 8 18:20:23 2013 From: benjaminrk at gmail.com (MinRK) Date: Wed, 8 May 2013 15:20:23 -0700 Subject: [IPython-dev] Example of a minimal custom IPython client? In-Reply-To: References: <8CE43504-2815-44C1-A663-E04728C0BD62@gmail.com> <518A901C.60200@third-bit.com> Message-ID: Here is a simple script that connects to an existing kernel and watches a particular variable name, displaying its representation every cell (if it changes). The same could be done for HTML table representations of data frames, etc. https://gist.github.com/5544117 -MinRK On Wed, May 8, 2013 at 2:38 PM, Thomas Kluyver wrote: > It's an interesting idea. Unfortunately, there's nothing in the message > spec to subscribe to updates on a particular object or group of objects, > and I can't off the top of my head think how we'd add that. You could send > the object of interest to the frontend after each execution in the kernel, > although that could be inefficient if you have a large object that you're > making frequent changes to. > > I think all our frontends so far are designed around entering and running > code. You could have a look at how Spyder's object inspector is > implemented, though. > > Best wishes, > Thomas > > > On 8 May 2013 18:49, Greg Wilson wrote: > >> Small world :-) >> - G >> >> On 2013-05-08 1:35 PM, Patrick Surry wrote: >> > I've become a big fan of IPython + pandas for data analysis, and have >> got interested in the idea of building a simple UI for end-user interaction >> with pandas DataFrame and Series objects. The idea being to streamline the >> initial exploratory data analysis process. Sort of like an object-specific >> "watch" window that you'd use in a debugger. >> > >> > It seems like the IPython communication model is ideal for that kind of >> thing, so I could potentially build a little UI analogous to the qtconsole >> which could subscribe to the server process and watch whatever object I'm >> interested in, and maybe have UI elements that issued python statements >> back to the server. But I'm new to the dev side of IPython and haven't >> figured out where to start. >> > >> > I'm curious to know if anyone has done anything like that before, and >> whether there are any examples I could work from. Perhaps the "Hello >> World" of custom IPython clients? >> > >> > Advice welcome, >> > >> > Thanks, >> > Patrick >> > >> > _______________________________________________ >> > 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 stanton at haas.berkeley.edu Thu May 9 00:10:06 2013 From: stanton at haas.berkeley.edu (Richard Stanton) Date: Thu, 9 May 2013 04:10:06 +0000 Subject: [IPython-dev] matplotlibrc seems to be ignored from IPython notebook In-Reply-To: Message-ID: Thanks. Now it's getting close. With the setting you suggested, file saving is now at the desired 300dpi (as set in my matplotlibrc file). However, the displayed inline graph is now huge! Ideally, I'd like to have the change in resolution apply only to saving, not to displaying inline. I've tried setting figure.dpi to 72 as well as savefig.dpi to 300 (the two settings seem to be intended to achieve exactly what I'm looking for), but it has no effect. pylab.gcf().get_dpi() reports 72, but the inline plot still appears huge. Is there something I'm missing? > >ipy_user_conf.py hasn't had any effect for a few years now (since 0.11). >It >should be in ipython_config or ipython_notebook_config (start with >`ipython >profile create`) > > >On Wed, May 8, 2013 at 10:17 AM, Richard Stanton >wrote: > >> >> >From: MinRK >> > >> >It is not ignored, but IPython sets a few of its own defaults with the >> >InlineBackend.rc config . One of these is savefig.dpi. You can prevent >> >this by simply clearing the inline backend rc with: >> > >> >c.InlineBackend.rc = {} >> > >> >in your config file. >> >> ----- >> >> Thanks. That makes sense, but when I put that line in a (new) file >>called >> ~/ipy_user_conf.py, the plotting behavior is the same as before. Should >>I >> have edited a different configuration file? From asmeurer at gmail.com Thu May 9 00:18:50 2013 From: asmeurer at gmail.com (Aaron Meurer) Date: Wed, 8 May 2013 22:18:50 -0600 Subject: [IPython-dev] matplotlibrc seems to be ignored from IPython notebook In-Reply-To: References: Message-ID: The discussion at https://github.com/ipython/ipython/issues/2234 is probably relevant. Aaron Meurer On Wed, May 8, 2013 at 10:10 PM, Richard Stanton wrote: > Thanks. Now it's getting close. With the setting you suggested, file > saving is now at the desired 300dpi (as set in my matplotlibrc file). > However, the displayed inline graph is now huge! Ideally, I'd like to have > the change in resolution apply only to saving, not to displaying inline. > I've tried setting figure.dpi to 72 as well as savefig.dpi to 300 (the two > settings seem to be intended to achieve exactly what I'm looking for), but > it has no effect. pylab.gcf().get_dpi() reports 72, but the inline plot > still appears huge. Is there something I'm missing? > > > > >ipy_user_conf.py hasn't had any effect for a few years now (since 0.11). > >It > >should be in ipython_config or ipython_notebook_config (start with > >`ipython > >profile create`) > > > > > >On Wed, May 8, 2013 at 10:17 AM, Richard Stanton > >wrote: > > > >> > >> >From: MinRK > >> > > >> >It is not ignored, but IPython sets a few of its own defaults with the > >> >InlineBackend.rc config . One of these is savefig.dpi. You can prevent > >> >this by simply clearing the inline backend rc with: > >> > > >> >c.InlineBackend.rc = {} > >> > > >> >in your config file. > >> > >> ----- > >> > >> Thanks. That makes sense, but when I put that line in a (new) file > >>called > >> ~/ipy_user_conf.py, the plotting behavior is the same as before. Should > >>I > >> have edited a different configuration file? > > _______________________________________________ > 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 dave.hirschfeld at gmail.com Fri May 10 05:04:08 2013 From: dave.hirschfeld at gmail.com (Dave Hirschfeld) Date: Fri, 10 May 2013 09:04:08 +0000 (UTC) Subject: [IPython-dev] IPython Parallel Ports Message-ID: In my ipcontroller-client.json file it appears that I've got 6 ports defined: { "control": , "task": , "notification": , "exec_key": "secret_code", "task_scheme": "leastload", "mux": , "iopub": , "ssh": "", "registration": , "interface": "tcp://ipaddress", "pack": "json", "unpack": "json", "location": "ipaddress" } The controller is running on the same grid as the engines but I need to communicate with it from outside i.e. without opening a remote desktop on the server to run my code. I assume that some of these ports are only used for talking to the engines and aren't required to be open to the outside world? If so, which ports do I need to open so that I can talk to the controller from outside the closed grid network? Thanks, Dave NB: Reposting to ipython-dev as it seems my original never turned up on ipython-user. Apologies if this turns up twice. From benjaminrk at gmail.com Fri May 10 12:50:00 2013 From: benjaminrk at gmail.com (MinRK) Date: Fri, 10 May 2013 09:50:00 -0700 Subject: [IPython-dev] IPython Parallel Ports In-Reply-To: References: Message-ID: ipcontroller-client is not used by the engines - ipcontroller-engine is used by engines. They share one port in common - registration. A client uses all of these ports. On Fri, May 10, 2013 at 2:04 AM, Dave Hirschfeld wrote: > In my ipcontroller-client.json file it appears that I've got 6 ports > defined: > > { > "control": , > "task": , > "notification": , > "exec_key": "secret_code", > "task_scheme": "leastload", > "mux": , > "iopub": , > "ssh": "", > "registration": , > "interface": "tcp://ipaddress", > "pack": "json", > "unpack": "json", > "location": "ipaddress" > } > > The controller is running on the same grid as the engines but I need to > communicate with it from outside i.e. without opening a remote desktop on > the server to run my code. > > I assume that some of these ports are only used for talking to the engines > and aren't required to be open to the outside world? If so, which ports do > I > need to open so that I can talk to the controller from outside the closed > grid network? > > Thanks, > Dave > > NB: Reposting to ipython-dev as it seems my original never turned up on > ipython-user. Apologies if this turns up twice. > > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Fri May 10 12:50:00 2013 From: benjaminrk at gmail.com (MinRK) Date: Fri, 10 May 2013 09:50:00 -0700 Subject: [IPython-dev] IPython Parallel Ports In-Reply-To: References: Message-ID: ipcontroller-client is not used by the engines - ipcontroller-engine is used by engines. They share one port in common - registration. A client uses all of these ports. On Fri, May 10, 2013 at 2:04 AM, Dave Hirschfeld wrote: > In my ipcontroller-client.json file it appears that I've got 6 ports > defined: > > { > "control": , > "task": , > "notification": , > "exec_key": "secret_code", > "task_scheme": "leastload", > "mux": , > "iopub": , > "ssh": "", > "registration": , > "interface": "tcp://ipaddress", > "pack": "json", > "unpack": "json", > "location": "ipaddress" > } > > The controller is running on the same grid as the engines but I need to > communicate with it from outside i.e. without opening a remote desktop on > the server to run my code. > > I assume that some of these ports are only used for talking to the engines > and aren't required to be open to the outside world? If so, which ports do > I > need to open so that I can talk to the controller from outside the closed > grid network? > > Thanks, > Dave > > NB: Reposting to ipython-dev as it seems my original never turned up on > ipython-user. Apologies if this turns up twice. > > > > _______________________________________________ > 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 jtratner at gmail.com Fri May 10 14:01:46 2013 From: jtratner at gmail.com (Jeffrey Tratner) Date: Fri, 10 May 2013 14:01:46 -0400 Subject: [IPython-dev] Printing HTML within IPython Notebook / IPython-specific prettyprint? Message-ID: Hi all, I know that I can use IPython.core.display.HTML to format something such that it outputs as HTML into the notebook. However, it appears to only work if it's the output of a cell, e.g. ``` from IPython.core.display import HTML html_text = HTML("

Some text!

") html_text ``` But I'd like to be able to output pretty printed HTML in the midst of a function. Is it possible to get IPython to consider something as HTML (instead of as plain text)? I tried using `lib.pretty`, but that didn't hook into it, and a plain print statemtn didn't work either.). It would be great to be able to do something like ``` from __future__ import print_function try: from IPython.somemodule import print_func except ImportError: print_func = print ``` Does this exist now and/or is it planned for the future? If not, any suggestions on how I might go about making this work? Thanks, Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From pi at berkeley.edu Fri May 10 14:24:14 2013 From: pi at berkeley.edu (Paul Ivanov) Date: Fri, 10 May 2013 11:24:14 -0700 Subject: [IPython-dev] Printing HTML within IPython Notebook / IPython-specific prettyprint? In-Reply-To: References: Message-ID: <20130510182414.GF8563@HbI-OTOH.berkeley.edu> Hi Jeff, I think display is what you want to use for now: from IPython.display import display, HTML for x in range(10): display(HTML("" + str(x) + "")) Jeffrey Tratner, on 2013-05-10 14:01, wrote: > Does this exist now and/or is it planned for the future? If not, any > suggestions on how I might go about making this work? monkey patching print is an interesting idea. -- _ / \ A* \^ - ,./ _.`\\ / \ / ,--.S \/ \ / `"~,_ \ \ __o ? _ \<,_ /:\ --(_)/-(_)----.../ | \ --------------.......J Paul Ivanov http://pirsquared.org From jtratner at gmail.com Fri May 10 14:35:22 2013 From: jtratner at gmail.com (Jeffrey Tratner) Date: Fri, 10 May 2013 14:35:22 -0400 Subject: [IPython-dev] Printing HTML within IPython Notebook / IPython-specific prettyprint? In-Reply-To: <20130510182414.GF8563@HbI-OTOH.berkeley.edu> References: <20130510182414.GF8563@HbI-OTOH.berkeley.edu> Message-ID: That was just what I was looking for -- thanks! On Fri, May 10, 2013 at 2:24 PM, Paul Ivanov wrote: > Hi Jeff, > > I think display is what you want to use for now: > > > from IPython.display import display, HTML > for x in range(10): > display(HTML("" + str(x) + "")) > > Jeffrey Tratner, on 2013-05-10 14:01, wrote: > > Does this exist now and/or is it planned for the future? If not, any > > suggestions on how I might go about making this work? > > monkey patching print is an interesting idea. > > > -- > _ > / \ > A* \^ - > ,./ _.`\\ / \ > / ,--.S \/ \ > / `"~,_ \ \ > __o ? > _ \<,_ /:\ > --(_)/-(_)----.../ | \ > --------------.......J > Paul Ivanov > http://pirsquared.org > _______________________________________________ > 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 Sat May 11 21:41:25 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 11 May 2013 18:41:25 -0700 Subject: [IPython-dev] Code size spike in April, did something accidentally get committed? Message-ID: Hi all, I just noticed a big spike in code size in April in Ohloh's report: http://www.ohloh.net/p/ipython/analyses/latest/languages_summary I haven't had time to investigate locally to track the repo size myself, but I was wondering if anybody knows where that's coming from. It looks as if some large chunk of code had accidentally been put in the repo and then removed. Any ideas? Cheers, f From asmeurer at gmail.com Sat May 11 21:48:43 2013 From: asmeurer at gmail.com (Aaron Meurer) Date: Sat, 11 May 2013 19:48:43 -0600 Subject: [IPython-dev] Code size spike in April, did something accidentally get committed? In-Reply-To: References: Message-ID: Using git log --graph --topo-order --stat and jumping down to April ("/Apr"), https://github.com/ipython/ipython/pull/3232 looks like a viable candidate. I wish there were a way to get the physical size of a commit, though ( http://stackoverflow.com/q/12701967/161801). Aaron Meurer On Sat, May 11, 2013 at 7:41 PM, Fernando Perez wrote: > Hi all, > > I just noticed a big spike in code size in April in Ohloh's report: > > http://www.ohloh.net/p/ipython/analyses/latest/languages_summary > > I haven't had time to investigate locally to track the repo size > myself, but I was wondering if anybody knows where that's coming from. > It looks as if some large chunk of code had accidentally been put in > the repo and then removed. > > Any ideas? > > 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 Sat May 11 21:59:26 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 11 May 2013 18:59:26 -0700 Subject: [IPython-dev] Code size spike in April, did something accidentally get committed? In-Reply-To: References: Message-ID: On Sat, May 11, 2013 at 6:48 PM, Aaron Meurer wrote: > Using git log --graph --topo-order --stat and jumping down to April > ("/Apr"), https://github.com/ipython/ipython/pull/3232 looks like a viable > candidate. Yup, I think you're right. I didn't think of using --stat as a way of figuring this out, thanks for the tip! I wish we'd been able to do something about that big spike in advance, but I see from the PR log it was a pretty messy situation, so I'm not sure it was really viable (and I didn't participate at the time). Oh well... > I wish there were a way to get the physical size of a commit, though > (http://stackoverflow.com/q/12701967/161801). Agreed! Cheers f From benjaminrk at gmail.com Sat May 11 23:12:49 2013 From: benjaminrk at gmail.com (MinRK) Date: Sat, 11 May 2013 20:12:49 -0700 Subject: [IPython-dev] Code size spike in April, did something accidentally get committed? In-Reply-To: References: Message-ID: And that PR is actually what prompted the move to submodules - it would have been better to go for submodules *instead* of that PR, but it's the way things go. On Sat, May 11, 2013 at 6:59 PM, Fernando Perez wrote: > On Sat, May 11, 2013 at 6:48 PM, Aaron Meurer wrote: > > Using git log --graph --topo-order --stat and jumping down to April > > ("/Apr"), https://github.com/ipython/ipython/pull/3232 looks like a > viable > > candidate. > > Yup, I think you're right. I didn't think of using --stat as a way of > figuring this out, thanks for the tip! > > I wish we'd been able to do something about that big spike in advance, > but I see from the PR log it was a pretty messy situation, so I'm not > sure it was really viable (and I didn't participate at the time). Oh > well... > > > I wish there were a way to get the physical size of a commit, though > > (http://stackoverflow.com/q/12701967/161801). > > Agreed! > > 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 zvoros at gmail.com Sun May 12 02:31:02 2013 From: zvoros at gmail.com (=?ISO-8859-1?Q?Zolt=E1n_V=F6r=F6s?=) Date: Sun, 12 May 2013 08:31:02 +0200 Subject: [IPython-dev] is markdown broken in latest ipython? Message-ID: <518F3726.8010402@gmail.com> Hi all, I have just pulled the master branch from git, and it seems to me that markdown rendering is broken. I used to have a short piece of script at the beginning of my notebooks, so that I can hide various fields. toggle input Now, this returns the error Error rendering Markdown! SyntaxError: Unexpected token & and the content is not rendered. (What makes the situation even weirder is the fact that there is no ampersand in the code.) I was wondering whether others have encountered the same problem, and whether there is a fix for it. Cheers, Zolt?n -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.hirschfeld at gmail.com Sun May 12 09:47:02 2013 From: dave.hirschfeld at gmail.com (Dave Hirschfeld) Date: Sun, 12 May 2013 13:47:02 +0000 (UTC) Subject: [IPython-dev] Notebook ignoring --notebook-dir argument Message-ID: When I start the notebook with `ipython notebook` from a terminal in a specific directory it doesn't open in that directory, but in my home directory. Specifying the `--notebook-dir` argument appears to have no effect. Is anyone else seeing this with the current master? In [3]: print sys_info() {'commit_hash': 'dfc7609', 'commit_source': 'repository', 'default_encoding': 'cp850', 'ipython_path': 'c:\\dev\\code\\ipython\\IPython', 'ipython_version': '1.0.dev', 'os_name': 'nt', 'platform': 'Windows-7-6.1.7601-SP1', 'sys_executable': 'C:\\dev\\bin\\Python27\\python.exe', 'sys_platform': 'win32', 'sys_version': '2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)]'} Thanks, Dave From gvwilson at third-bit.com Sun May 12 09:56:57 2013 From: gvwilson at third-bit.com (Greg Wilson) Date: Sun, 12 May 2013 09:56:57 -0400 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: Message-ID: <518F9FA9.30507@third-bit.com> We just ran six Software Carpentry boot camps in a five-day period, and things largely went well --- most of our instructors are now using the IPython Notebook for all Python instruction, and learners are responding well. One problem that did come up, though, is the behavior of '%%file'. If I have a file called 'data.txt' on my hard drive, and put: %%file data.txt in a cell and then execute it, 'data.txt' is overwritten and the data is lost. Everyone (including me, when I'm forgetful) expects this to load and display the existing file content if the file exists, just like an editor would. I realize that it's problematic to have the in-cell display update automagically if and when the file is edited by some other tool, but "load if exists, create if not" seems like it ought to be straightforward. Failing that, a prompt that says, "This exists, are you sure you want to overwrite it?" would be better than what happens now. Thoughts? Thanks, Greg From wking at tremily.us Sun May 12 10:23:27 2013 From: wking at tremily.us (W. Trevor King) Date: Sun, 12 May 2013 10:23:27 -0400 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: <518F9FA9.30507@third-bit.com> References: <518F9FA9.30507@third-bit.com> Message-ID: <20130512142327.GG20636@odin.tremily.us> On Sun, May 12, 2013 at 09:56:57AM -0400, Greg Wilson wrote: > If I have a file called 'data.txt' on my hard drive, and put: > > %%file data.txt > > in a cell and then execute it, 'data.txt' is overwritten and the data is > lost. Everyone (including me, when I'm forgetful) expects this to load > and display the existing file content if the file exists, just like an > editor would. Maybe the current %%file magic should be renamed to %%save-file, and you're expecting a (currently unimplemented?) %%open-file. I don't like the idea of mandatory interactivity. It looks like there was previous work in this direction (234309d, ask_yes_no on %%file overwrite, 2012-06-05), but it was dropped in d0c569e (%%file always overwrites, 2012-06-09). The commit message doesn't elaborate on the motivation for dropping the interactivity. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From benjaminrk at gmail.com Sun May 12 10:36:27 2013 From: benjaminrk at gmail.com (Min RK) Date: Sun, 12 May 2013 07:36:27 -0700 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: <20130512142327.GG20636@odin.tremily.us> References: <518F9FA9.30507@third-bit.com> <20130512142327.GG20636@odin.tremily.us> Message-ID: <36C9A01A-E60E-4922-85C9-57B44F731346@gmail.com> On May 12, 2013, at 7:23, "W. Trevor King" wrote: > On Sun, May 12, 2013 at 09:56:57AM -0400, Greg Wilson wrote: >> If I have a file called 'data.txt' on my hard drive, and put: >> >> %%file data.txt >> >> in a cell and then execute it, 'data.txt' is overwritten and the data is >> lost. Everyone (including me, when I'm forgetful) expects this to load >> and display the existing file content if the file exists, just like an >> editor would. it should probably at least give up and provide a helpful message when the cell is empty, rather than writing an empty file. > > Maybe the current %%file magic should be renamed to %%save-file, and > you're expecting a (currently unimplemented?) %%open-file. it is *not* an editor - if you want to load a file's contents into a cell, that's precisely what %load does. > I don't > like the idea of mandatory interactivity. It looks like there was > previous work in this direction (234309d, ask_yes_no on %%file > overwrite, 2012-06-05), but it was dropped in d0c569e (%%file always > overwrites, 2012-06-09). The commit message doesn't elaborate on the > motivation for dropping the interactivity. The interactivity was dropped because the notebook didn't support any interaction. This is no longer true, so going back to prompting for overwrite probably makes sense. > > Cheers, > Trevor > > -- > This email may be signed or encrypted with GnuPG (http://www.gnupg.org). > For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From wking at tremily.us Sun May 12 10:51:39 2013 From: wking at tremily.us (W. Trevor King) Date: Sun, 12 May 2013 10:51:39 -0400 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: <36C9A01A-E60E-4922-85C9-57B44F731346@gmail.com> References: <518F9FA9.30507@third-bit.com> <20130512142327.GG20636@odin.tremily.us> <36C9A01A-E60E-4922-85C9-57B44F731346@gmail.com> Message-ID: <20130512145139.GH20636@odin.tremily.us> On Sun, May 12, 2013 at 07:36:27AM -0700, Min RK wrote: > On May 12, 2013, at 7:23, "W. Trevor King" wrote: > > On Sun, May 12, 2013 at 09:56:57AM -0400, Greg Wilson wrote: > >> If I have a file called 'data.txt' on my hard drive, and put: > >> > >> %%file data.txt > >> > >> in a cell and then execute it, 'data.txt' is overwritten and the data is > >> lost. Everyone (including me, when I'm forgetful) expects this to load > >> and display the existing file content if the file exists, just like an > >> editor would. > [snip] > > Maybe the current %%file magic should be renamed to %%save-file, and > > you're expecting a (currently unimplemented?) %%open-file. > > it is *not* an editor - if you want to load a file's contents into a > cell, that's precisely what %load does. Ah, thanks. I didn't see anything load-related in the cell magics list [1], and I couldn't even find a standard-magic list in the docs :p [2]. I wasn't proposing an editor-like command, I was saying that the ambiguity Greg points out with `%%file` is understandable. In the ?explicit is better than implicit? spirit, it would make sense to use a more explicit name for a file-saving magic. On the other hand, backwards compatibility has a good deal of weight too. Cheers, Trevor [1]: http://ipython.org/ipython-doc/dev/whatsnew/version0.13.html#cell-magics [2]: I suppose auto-completion makes such a listing less important. -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From benjaminrk at gmail.com Sun May 12 11:04:15 2013 From: benjaminrk at gmail.com (MinRK) Date: Sun, 12 May 2013 08:04:15 -0700 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: <20130512145139.GH20636@odin.tremily.us> References: <518F9FA9.30507@third-bit.com> <20130512142327.GG20636@odin.tremily.us> <36C9A01A-E60E-4922-85C9-57B44F731346@gmail.com> <20130512145139.GH20636@odin.tremily.us> Message-ID: On Sun, May 12, 2013 at 7:51 AM, W. Trevor King wrote: > On Sun, May 12, 2013 at 07:36:27AM -0700, Min RK wrote: > > On May 12, 2013, at 7:23, "W. Trevor King" wrote: > > > On Sun, May 12, 2013 at 09:56:57AM -0400, Greg Wilson wrote: > > >> If I have a file called 'data.txt' on my hard drive, and put: > > >> > > >> %%file data.txt > > >> > > >> in a cell and then execute it, 'data.txt' is overwritten and the data > is > > >> lost. Everyone (including me, when I'm forgetful) expects this to > load > > >> and display the existing file content if the file exists, just like an > > >> editor would. > > [snip] > > > Maybe the current %%file magic should be renamed to %%save-file, and > > > you're expecting a (currently unimplemented?) %%open-file. > > > > it is *not* an editor - if you want to load a file's contents into a > > cell, that's precisely what %load does. > > Ah, thanks. I didn't see anything load-related in the cell magics > list [1], That would be because it doesn't make any sense for load to be a cell magic - cell magics always take the body of a cell as an argument. > and I couldn't even find a standard-magic list in the docs > :p [2]. I wasn't proposing an editor-like command, I was saying that > the ambiguity Greg points out with `%%file` is understandable. In the > ?explicit is better than implicit? spirit, it would make sense to use > a more explicit name for a file-saving magic. On the other hand, > backwards compatibility has a good deal of weight too. > %lsmagic lists magics, as will %lsmagic, etc. Also, in master if you call `%%file filename` with no cell body, you will get an error saying "%%file is a cell magic, but the cell body is empty", so I would consider this part of the issue addressed. > > Cheers, > Trevor > > [1]: > http://ipython.org/ipython-doc/dev/whatsnew/version0.13.html#cell-magics > [2]: I suppose auto-completion makes such a listing less important. > > -- > This email may be signed or encrypted with GnuPG (http://www.gnupg.org). > For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy > > _______________________________________________ > 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 wking at tremily.us Sun May 12 11:35:47 2013 From: wking at tremily.us (W. Trevor King) Date: Sun, 12 May 2013 11:35:47 -0400 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <518F9FA9.30507@third-bit.com> <20130512142327.GG20636@odin.tremily.us> <36C9A01A-E60E-4922-85C9-57B44F731346@gmail.com> <20130512145139.GH20636@odin.tremily.us> Message-ID: <20130512153547.GA23803@odin.tremily.us> On Sun, May 12, 2013 at 08:04:15AM -0700, MinRK wrote: > Also, in master if you call `%%file filename` with no cell body, you > will get an error saying "%%file is a cell magic, but the cell body > is empty", so I would consider this part of the issue addressed. Works for me. For the curious, this happened in 07b4449 (better UsageError for cell magic with no body, 2013-04-15). Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From jiffyclub at gmail.com Sun May 12 11:45:03 2013 From: jiffyclub at gmail.com (Matt Davis) Date: Sun, 12 May 2013 08:45:03 -0700 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: <20130512153547.GA23803@odin.tremily.us> References: <518F9FA9.30507@third-bit.com> <20130512142327.GG20636@odin.tremily.us> <36C9A01A-E60E-4922-85C9-57B44F731346@gmail.com> <20130512145139.GH20636@odin.tremily.us> <20130512153547.GA23803@odin.tremily.us> Message-ID: I agree renaming %%file to %%savefile would be a good idea so it's clear it's a one-way process. - Matt On Sun, May 12, 2013 at 8:35 AM, W. Trevor King wrote: > On Sun, May 12, 2013 at 08:04:15AM -0700, MinRK wrote: > > Also, in master if you call `%%file filename` with no cell body, you > > will get an error saying "%%file is a cell magic, but the cell body > > is empty", so I would consider this part of the issue addressed. > > Works for me. For the curious, this happened in 07b4449 (better > UsageError for cell magic with no body, 2013-04-15). > > Cheers, > Trevor > > -- > This email may be signed or encrypted with GnuPG (http://www.gnupg.org). > For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carl.input at gmail.com Sun May 12 11:53:13 2013 From: carl.input at gmail.com (Carl Smith) Date: Sun, 12 May 2013 16:53:13 +0100 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <518F9FA9.30507@third-bit.com> <20130512142327.GG20636@odin.tremily.us> <36C9A01A-E60E-4922-85C9-57B44F731346@gmail.com> <20130512145139.GH20636@odin.tremily.us> <20130512153547.GA23803@odin.tremily.us> Message-ID: %%flush ?? -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Sun May 12 17:22:05 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 12 May 2013 14:22:05 -0700 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <518F9FA9.30507@third-bit.com> <20130512142327.GG20636@odin.tremily.us> <36C9A01A-E60E-4922-85C9-57B44F731346@gmail.com> <20130512145139.GH20636@odin.tremily.us> <20130512153547.GA23803@odin.tremily.us> Message-ID: On Sun, May 12, 2013 at 8:45 AM, Matt Davis wrote: > I agree renaming %%file to %%savefile would be a good idea so it's clear > it's a one-way process. Yes, in hindsight, the name 'file' was probably a sub-optimal choice: given that the purpose of the function is to take a (potentially destructive) action, it should be named as a verb to make that unambiguous. I don't want to have it blend magically the behavior of `%load`, which already works perfectly fine and is well named. But renaming %%file is probably a good idea, keeping a stub %%file for a release of two that just prints a deprecation message and forwards the call to the new name. Potential contenders: savefile, writefile, filesave, and _-separated versions thereof. Technically we *could* use '-' in magic names, since they don't need to conform to python syntax. Perhaps 'file-save' is a bit more readable and more finger-friendly than an underscore... I'm leaning towards 'filesave', as it follows the 'File->Save' pattern of most menus and will tab-complete from the word 'file', which is the name we were already using. Thoughts? f From gvwilson at third-bit.com Sun May 12 17:27:19 2013 From: gvwilson at third-bit.com (Greg Wilson) Date: Sun, 12 May 2013 17:27:19 -0400 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <518F9FA9.30507@third-bit.com> <20130512142327.GG20636@odin.tremily.us> <36C9A01A-E60E-4922-85C9-57B44F731346@gmail.com> <20130512145139.GH20636@odin.tremily.us> <20130512153547.GA23803@odin.tremily.us> Message-ID: <51900937.5030106@third-bit.com> On 2013-05-12 5:22 PM, Fernando Perez wrote: > On Sun, May 12, 2013 at 8:45 AM, Matt Davis wrote: >> I agree renaming %%file to %%savefile would be a good idea so it's clear >> it's a one-way process. > I'm leaning towards 'filesave', as it follows the 'File->Save' pattern > of most menus and will tab-complete from the word 'file', which is the > name we were already using. > > Thoughts? Just did a very unscientific poll: %%overwrite got two votes, %%filesave got zero, and "what?" beat them both :-) - G From fperez.net at gmail.com Sun May 12 17:33:16 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 12 May 2013 14:33:16 -0700 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: <51900937.5030106@third-bit.com> References: <518F9FA9.30507@third-bit.com> <20130512142327.GG20636@odin.tremily.us> <36C9A01A-E60E-4922-85C9-57B44F731346@gmail.com> <20130512145139.GH20636@odin.tremily.us> <20130512153547.GA23803@odin.tremily.us> <51900937.5030106@third-bit.com> Message-ID: Mmh, %%overwrite... I didn't like it too much when I first saw it, but it's growing on me, and it has the advantage of being unambiguous about the destructive nature of the action. f On Sun, May 12, 2013 at 2:27 PM, Greg Wilson wrote: > On 2013-05-12 5:22 PM, Fernando Perez wrote: >> On Sun, May 12, 2013 at 8:45 AM, Matt Davis wrote: >>> I agree renaming %%file to %%savefile would be a good idea so it's clear >>> it's a one-way process. >> I'm leaning towards 'filesave', as it follows the 'File->Save' pattern >> of most menus and will tab-complete from the word 'file', which is the >> name we were already using. >> >> Thoughts? > Just did a very unscientific poll: %%overwrite got two votes, %%filesave > got zero, and "what?" beat them both :-) > - G > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From zvoros at gmail.com Sun May 12 17:36:16 2013 From: zvoros at gmail.com (=?ISO-8859-1?Q?Zolt=E1n_V=F6r=F6s?=) Date: Sun, 12 May 2013 23:36:16 +0200 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <518F9FA9.30507@third-bit.com> <20130512142327.GG20636@odin.tremily.us> <36C9A01A-E60E-4922-85C9-57B44F731346@gmail.com> <20130512145139.GH20636@odin.tremily.us> <20130512153547.GA23803@odin.tremily.us> <51900937.5030106@third-bit.com> Message-ID: <51900B50.6090306@gmail.com> Couldn't %%file accept an argument (beyond the filename), which would indicate what kind of action is going to be taken? Like %%file overwrite somefile %%file append somefile etc. On 12/05/13 23:33, Fernando Perez wrote: > Mmh, %%overwrite... I didn't like it too much when I first saw it, > but it's growing on me, and it has the advantage of being unambiguous > about the destructive nature of the action. > > f > > On Sun, May 12, 2013 at 2:27 PM, Greg Wilson wrote: >> On 2013-05-12 5:22 PM, Fernando Perez wrote: >>> On Sun, May 12, 2013 at 8:45 AM, Matt Davis wrote: >>>> I agree renaming %%file to %%savefile would be a good idea so it's clear >>>> it's a one-way process. >>> I'm leaning towards 'filesave', as it follows the 'File->Save' pattern >>> of most menus and will tab-complete from the word 'file', which is the >>> name we were already using. >>> >>> Thoughts? >> Just did a very unscientific poll: %%overwrite got two votes, %%filesave >> got zero, and "what?" beat them both :-) >> - G >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From jtaylor.debian at googlemail.com Sun May 12 17:39:00 2013 From: jtaylor.debian at googlemail.com (Julian Taylor) Date: Sun, 12 May 2013 23:39:00 +0200 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <518F9FA9.30507@third-bit.com> <20130512142327.GG20636@odin.tremily.us> <36C9A01A-E60E-4922-85C9-57B44F731346@gmail.com> <20130512145139.GH20636@odin.tremily.us> <20130512153547.GA23803@odin.tremily.us> <51900937.5030106@third-bit.com> Message-ID: <51900BF4.5010703@googlemail.com> how about %%save-as? On 12.05.2013 23:33, Fernando Perez wrote: > Mmh, %%overwrite... I didn't like it too much when I first saw it, > but it's growing on me, and it has the advantage of being unambiguous > about the destructive nature of the action. > > f > > On Sun, May 12, 2013 at 2:27 PM, Greg Wilson wrote: >> On 2013-05-12 5:22 PM, Fernando Perez wrote: >>> On Sun, May 12, 2013 at 8:45 AM, Matt Davis wrote: >>>> I agree renaming %%file to %%savefile would be a good idea so it's clear >>>> it's a one-way process. >>> I'm leaning towards 'filesave', as it follows the 'File->Save' pattern >>> of most menus and will tab-complete from the word 'file', which is the >>> name we were already using. >>> >>> Thoughts? >> Just did a very unscientific poll: %%overwrite got two votes, %%filesave >> got zero, and "what?" beat them both :-) >> - G >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > From wking at tremily.us Sun May 12 17:44:47 2013 From: wking at tremily.us (W. Trevor King) Date: Sun, 12 May 2013 17:44:47 -0400 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: <51900B50.6090306@gmail.com> References: <20130512142327.GG20636@odin.tremily.us> <36C9A01A-E60E-4922-85C9-57B44F731346@gmail.com> <20130512145139.GH20636@odin.tremily.us> <20130512153547.GA23803@odin.tremily.us> <51900937.5030106@third-bit.com> <51900B50.6090306@gmail.com> Message-ID: <20130512214447.GK23803@odin.tremily.us> On Sun, May 12, 2013 at 11:36:16PM +0200, Zolt?n V?r?s wrote: > Couldn't %%file accept an argument (beyond the filename), which would > indicate what kind of action is going to be taken? Like > %%file overwrite somefile > > %%file append somefile That's effectively what it already does, except it uses `--force` (with [1]) and `--append` instead of `overwrite` and `append`. The problem was the default `--force`, which is fixed in #3313. The ongoing %%overwrite discussion is about trying to increase the intuitive understanding to make the command's effect easier to remember. Cheers, Trevor [1]: https://github.com/ipython/ipython/pull/3313 -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From zvoros at gmail.com Sun May 12 17:51:39 2013 From: zvoros at gmail.com (=?ISO-8859-1?Q?Zolt=E1n_V=F6r=F6s?=) Date: Sun, 12 May 2013 23:51:39 +0200 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: <20130512214447.GK23803@odin.tremily.us> References: <20130512142327.GG20636@odin.tremily.us> <36C9A01A-E60E-4922-85C9-57B44F731346@gmail.com> <20130512145139.GH20636@odin.tremily.us> <20130512153547.GA23803@odin.tremily.us> <51900937.5030106@third-bit.com> <51900B50.6090306@gmail.com> <20130512214447.GK23803@odin.tremily.us> Message-ID: <51900EEB.9060904@gmail.com> Fair enough. Thanks for the clarification! Cheers, Zolt?n > On Sun, May 12, 2013 at 11:36:16PM +0200, Zolt?n V?r?s wrote: >> Couldn't %%file accept an argument (beyond the filename), which would >> indicate what kind of action is going to be taken? Like >> %%file overwrite somefile >> >> %%file append somefile > That's effectively what it already does, except it uses `--force` > (with [1]) and `--append` instead of `overwrite` and `append`. The > problem was the default `--force`, which is fixed in #3313. > > The ongoing %%overwrite discussion is about trying to increase the > intuitive understanding to make the command's effect easier to > remember. > From gvwilson at third-bit.com Sun May 12 17:56:19 2013 From: gvwilson at third-bit.com (Greg Wilson) Date: Sun, 12 May 2013 17:56:19 -0400 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <518F9FA9.30507@third-bit.com> <20130512142327.GG20636@odin.tremily.us> <36C9A01A-E60E-4922-85C9-57B44F731346@gmail.com> <20130512145139.GH20636@odin.tremily.us> <20130512153547.GA23803@odin.tremily.us> <51900937.5030106@third-bit.com> Message-ID: <51901003.70206@third-bit.com> On 2013-05-12 5:33 PM, Fernando Perez wrote: > Mmh, %%overwrite... I didn't like it too much when I first saw it, > but it's growing on me, and it has the advantage of being unambiguous > about the destructive nature of the action. > Could we do a simple usability test in the spirit of http://mail.python.org/pipermail/python-dev/2000-July/006427.html and http://mail.python.org/pipermail/python-dev/2000-July/006098.html to find out what users would expect each alternative to do? I've included a very rough first cut below (which looks better with a monospaced font :-) Thanks, Greg -------------------- You have a directory called 'data' that contains two files: * 'fish.csv' contains 160 lines of observations in comma-separated values format. * 'site.txt' contains 20 lines of text describing the site where you collected data (in plain English). * 'weather.txt' contains half a dozen lines of text about the weather during your site visit. You run the IPython Notebook in that directory and do the operations described below. What does the Notebook display when each cell command is run (in the order shown, with all of the cell content typed in before the cell is run), and what changes does it make inside the 'data' directory and/or the files it contains when each cell is run? 1. +----------------------------------------+ |%%load fish.csv | +----------------------------------------+ 2. +----------------------------------------+ |%%display fish.csv | +----------------------------------------+ 3. +----------------------------------------+ |%%file site.txt | +----------------------------------------+ 4. +----------------------------------------+ |%%file weather.txt | |Generally sunny, but on the last day | |we had torrential rain followed by a | |meteorite shower. | +----------------------------------------+ 5. +----------------------------------------+ |%%overwrite site.txt | +----------------------------------------+ 6. +----------------------------------------+ |%%overwrite site.txt | |Typical riverbank site, some signs of | |recent erosion due to road-building, | |plus traces of metallic iridium left | |behind by the mothership. | +----------------------------------------+ From takowl at gmail.com Sun May 12 18:28:17 2013 From: takowl at gmail.com (Thomas Kluyver) Date: Sun, 12 May 2013 23:28:17 +0100 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: <51901003.70206@third-bit.com> References: <518F9FA9.30507@third-bit.com> <20130512142327.GG20636@odin.tremily.us> <36C9A01A-E60E-4922-85C9-57B44F731346@gmail.com> <20130512145139.GH20636@odin.tremily.us> <20130512153547.GA23803@odin.tremily.us> <51900937.5030106@third-bit.com> <51901003.70206@third-bit.com> Message-ID: Not convinced by %%overwrite: - It doesn't make much sense when the file doesn't already exist - It should be usable the other way round as well - you know what you want to do (save some text to a file), find the quickest way to do that. My vote would be %%writefile. Thomas On 12 May 2013 22:56, Greg Wilson wrote: > On 2013-05-12 5:33 PM, Fernando Perez wrote: > > Mmh, %%overwrite... I didn't like it too much when I first saw it, > > but it's growing on me, and it has the advantage of being unambiguous > > about the destructive nature of the action. > > > Could we do a simple usability test in the spirit of > http://mail.python.org/pipermail/python-dev/2000-July/006427.html and > http://mail.python.org/pipermail/python-dev/2000-July/006098.html to > find out what users would expect each alternative to do? I've included a > very rough first cut below (which looks better with a monospaced font :-) > Thanks, > Greg > > -------------------- > > You have a directory called 'data' that contains two files: > > * 'fish.csv' contains 160 lines of observations in comma-separated > values format. > * 'site.txt' contains 20 lines of text describing the site where you > collected data (in plain English). > * 'weather.txt' contains half a dozen lines of text about the weather > during your site visit. > > You run the IPython Notebook in that directory and do the operations > described below. What does the Notebook display when each cell > command is run (in the order shown, with all of the cell content typed > in before the cell is run), and what changes does it make inside the > 'data' directory and/or the files it contains when each cell is run? > > 1. +----------------------------------------+ > |%%load fish.csv | > +----------------------------------------+ > > 2. +----------------------------------------+ > |%%display fish.csv | > +----------------------------------------+ > > 3. +----------------------------------------+ > |%%file site.txt | > +----------------------------------------+ > > 4. +----------------------------------------+ > |%%file weather.txt | > |Generally sunny, but on the last day | > |we had torrential rain followed by a | > |meteorite shower. | > +----------------------------------------+ > > 5. +----------------------------------------+ > |%%overwrite site.txt | > +----------------------------------------+ > > 6. +----------------------------------------+ > |%%overwrite site.txt | > |Typical riverbank site, some signs of | > |recent erosion due to road-building, | > |plus traces of metallic iridium left | > |behind by the mothership. | > +----------------------------------------+ > > _______________________________________________ > 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 jiffyclub at gmail.com Sun May 12 18:38:29 2013 From: jiffyclub at gmail.com (Matt Davis) Date: Sun, 12 May 2013 15:38:29 -0700 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <518F9FA9.30507@third-bit.com> <20130512142327.GG20636@odin.tremily.us> <36C9A01A-E60E-4922-85C9-57B44F731346@gmail.com> <20130512145139.GH20636@odin.tremily.us> <20130512153547.GA23803@odin.tremily.us> <51900937.5030106@third-bit.com> <51901003.70206@third-bit.com> Message-ID: I agree with Thomas that %%overwrite won't be a natural choice when the file doesn't already exist. I think %%filesave or %%writefile would be good choices. - Matt On Sun, May 12, 2013 at 3:28 PM, Thomas Kluyver wrote: > Not convinced by %%overwrite: > - It doesn't make much sense when the file doesn't already exist > - It should be usable the other way round as well - you know what you want > to do (save some text to a file), find the quickest way to do that. > > My vote would be %%writefile. > > Thomas > > > On 12 May 2013 22:56, Greg Wilson wrote: > >> On 2013-05-12 5:33 PM, Fernando Perez wrote: >> > Mmh, %%overwrite... I didn't like it too much when I first saw it, >> > but it's growing on me, and it has the advantage of being unambiguous >> > about the destructive nature of the action. >> > >> Could we do a simple usability test in the spirit of >> http://mail.python.org/pipermail/python-dev/2000-July/006427.html and >> http://mail.python.org/pipermail/python-dev/2000-July/006098.html to >> find out what users would expect each alternative to do? I've included a >> very rough first cut below (which looks better with a monospaced font :-) >> Thanks, >> Greg >> >> -------------------- >> >> You have a directory called 'data' that contains two files: >> >> * 'fish.csv' contains 160 lines of observations in comma-separated >> values format. >> * 'site.txt' contains 20 lines of text describing the site where you >> collected data (in plain English). >> * 'weather.txt' contains half a dozen lines of text about the weather >> during your site visit. >> >> You run the IPython Notebook in that directory and do the operations >> described below. What does the Notebook display when each cell >> command is run (in the order shown, with all of the cell content typed >> in before the cell is run), and what changes does it make inside the >> 'data' directory and/or the files it contains when each cell is run? >> >> 1. +----------------------------------------+ >> |%%load fish.csv | >> +----------------------------------------+ >> >> 2. +----------------------------------------+ >> |%%display fish.csv | >> +----------------------------------------+ >> >> 3. +----------------------------------------+ >> |%%file site.txt | >> +----------------------------------------+ >> >> 4. +----------------------------------------+ >> |%%file weather.txt | >> |Generally sunny, but on the last day | >> |we had torrential rain followed by a | >> |meteorite shower. | >> +----------------------------------------+ >> >> 5. +----------------------------------------+ >> |%%overwrite site.txt | >> +----------------------------------------+ >> >> 6. +----------------------------------------+ >> |%%overwrite site.txt | >> |Typical riverbank site, some signs of | >> |recent erosion due to road-building, | >> |plus traces of metallic iridium left | >> |behind by the mothership. | >> +----------------------------------------+ >> >> _______________________________________________ >> 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 ellisonbg at gmail.com Sun May 12 19:20:05 2013 From: ellisonbg at gmail.com (Brian Granger) Date: Sun, 12 May 2013 16:20:05 -0700 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <518F9FA9.30507@third-bit.com> <20130512142327.GG20636@odin.tremily.us> <36C9A01A-E60E-4922-85C9-57B44F731346@gmail.com> <20130512145139.GH20636@odin.tremily.us> <20130512153547.GA23803@odin.tremily.us> <51900937.5030106@third-bit.com> <51901003.70206@third-bit.com> Message-ID: I haven't following this too closely, but my initial thought is that all of this is sounding too complex. Let's keep it simple - remembering that the notebook app will eventually have a full blown file editor in a separate window. On Sun, May 12, 2013 at 3:38 PM, Matt Davis wrote: > I agree with Thomas that %%overwrite won't be a natural choice when the file > doesn't already exist. I think %%filesave or %%writefile would be good > choices. > > - Matt > > > On Sun, May 12, 2013 at 3:28 PM, Thomas Kluyver wrote: >> >> Not convinced by %%overwrite: >> - It doesn't make much sense when the file doesn't already exist >> - It should be usable the other way round as well - you know what you want >> to do (save some text to a file), find the quickest way to do that. >> >> My vote would be %%writefile. >> >> Thomas >> >> >> On 12 May 2013 22:56, Greg Wilson wrote: >>> >>> On 2013-05-12 5:33 PM, Fernando Perez wrote: >>> > Mmh, %%overwrite... I didn't like it too much when I first saw it, >>> > but it's growing on me, and it has the advantage of being unambiguous >>> > about the destructive nature of the action. >>> > >>> Could we do a simple usability test in the spirit of >>> http://mail.python.org/pipermail/python-dev/2000-July/006427.html and >>> http://mail.python.org/pipermail/python-dev/2000-July/006098.html to >>> find out what users would expect each alternative to do? I've included a >>> very rough first cut below (which looks better with a monospaced font :-) >>> Thanks, >>> Greg >>> >>> -------------------- >>> >>> You have a directory called 'data' that contains two files: >>> >>> * 'fish.csv' contains 160 lines of observations in comma-separated >>> values format. >>> * 'site.txt' contains 20 lines of text describing the site where you >>> collected data (in plain English). >>> * 'weather.txt' contains half a dozen lines of text about the weather >>> during your site visit. >>> >>> You run the IPython Notebook in that directory and do the operations >>> described below. What does the Notebook display when each cell >>> command is run (in the order shown, with all of the cell content typed >>> in before the cell is run), and what changes does it make inside the >>> 'data' directory and/or the files it contains when each cell is run? >>> >>> 1. +----------------------------------------+ >>> |%%load fish.csv | >>> +----------------------------------------+ >>> >>> 2. +----------------------------------------+ >>> |%%display fish.csv | >>> +----------------------------------------+ >>> >>> 3. +----------------------------------------+ >>> |%%file site.txt | >>> +----------------------------------------+ >>> >>> 4. +----------------------------------------+ >>> |%%file weather.txt | >>> |Generally sunny, but on the last day | >>> |we had torrential rain followed by a | >>> |meteorite shower. | >>> +----------------------------------------+ >>> >>> 5. +----------------------------------------+ >>> |%%overwrite site.txt | >>> +----------------------------------------+ >>> >>> 6. +----------------------------------------+ >>> |%%overwrite site.txt | >>> |Typical riverbank site, some signs of | >>> |recent erosion due to road-building, | >>> |plus traces of metallic iridium left | >>> |behind by the mothership. | >>> +----------------------------------------+ >>> >>> _______________________________________________ >>> 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 > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From ellisonbg at gmail.com Sun May 12 19:23:31 2013 From: ellisonbg at gmail.com (Brian Granger) Date: Sun, 12 May 2013 16:23:31 -0700 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <518F9FA9.30507@third-bit.com> <20130512142327.GG20636@odin.tremily.us> <36C9A01A-E60E-4922-85C9-57B44F731346@gmail.com> <20130512145139.GH20636@odin.tremily.us> <20130512153547.GA23803@odin.tremily.us> <51900937.5030106@third-bit.com> <51901003.70206@third-bit.com> Message-ID: It feels like we are trying to create a mini file editor in a notebook cell. %%file and friends are not supposed to be that in any way. I think %%file with prompting the user for overwrite is sufficient for this particular purpose = write and store simple files in the notebook. On Sun, May 12, 2013 at 4:20 PM, Brian Granger wrote: > I haven't following this too closely, but my initial thought is that > all of this is sounding too complex. Let's keep it simple - > remembering that the notebook app will eventually have a full blown > file editor in a separate window. > > On Sun, May 12, 2013 at 3:38 PM, Matt Davis wrote: >> I agree with Thomas that %%overwrite won't be a natural choice when the file >> doesn't already exist. I think %%filesave or %%writefile would be good >> choices. >> >> - Matt >> >> >> On Sun, May 12, 2013 at 3:28 PM, Thomas Kluyver wrote: >>> >>> Not convinced by %%overwrite: >>> - It doesn't make much sense when the file doesn't already exist >>> - It should be usable the other way round as well - you know what you want >>> to do (save some text to a file), find the quickest way to do that. >>> >>> My vote would be %%writefile. >>> >>> Thomas >>> >>> >>> On 12 May 2013 22:56, Greg Wilson wrote: >>>> >>>> On 2013-05-12 5:33 PM, Fernando Perez wrote: >>>> > Mmh, %%overwrite... I didn't like it too much when I first saw it, >>>> > but it's growing on me, and it has the advantage of being unambiguous >>>> > about the destructive nature of the action. >>>> > >>>> Could we do a simple usability test in the spirit of >>>> http://mail.python.org/pipermail/python-dev/2000-July/006427.html and >>>> http://mail.python.org/pipermail/python-dev/2000-July/006098.html to >>>> find out what users would expect each alternative to do? I've included a >>>> very rough first cut below (which looks better with a monospaced font :-) >>>> Thanks, >>>> Greg >>>> >>>> -------------------- >>>> >>>> You have a directory called 'data' that contains two files: >>>> >>>> * 'fish.csv' contains 160 lines of observations in comma-separated >>>> values format. >>>> * 'site.txt' contains 20 lines of text describing the site where you >>>> collected data (in plain English). >>>> * 'weather.txt' contains half a dozen lines of text about the weather >>>> during your site visit. >>>> >>>> You run the IPython Notebook in that directory and do the operations >>>> described below. What does the Notebook display when each cell >>>> command is run (in the order shown, with all of the cell content typed >>>> in before the cell is run), and what changes does it make inside the >>>> 'data' directory and/or the files it contains when each cell is run? >>>> >>>> 1. +----------------------------------------+ >>>> |%%load fish.csv | >>>> +----------------------------------------+ >>>> >>>> 2. +----------------------------------------+ >>>> |%%display fish.csv | >>>> +----------------------------------------+ >>>> >>>> 3. +----------------------------------------+ >>>> |%%file site.txt | >>>> +----------------------------------------+ >>>> >>>> 4. +----------------------------------------+ >>>> |%%file weather.txt | >>>> |Generally sunny, but on the last day | >>>> |we had torrential rain followed by a | >>>> |meteorite shower. | >>>> +----------------------------------------+ >>>> >>>> 5. +----------------------------------------+ >>>> |%%overwrite site.txt | >>>> +----------------------------------------+ >>>> >>>> 6. +----------------------------------------+ >>>> |%%overwrite site.txt | >>>> |Typical riverbank site, some signs of | >>>> |recent erosion due to road-building, | >>>> |plus traces of metallic iridium left | >>>> |behind by the mothership. | >>>> +----------------------------------------+ >>>> >>>> _______________________________________________ >>>> 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 >> > > > > -- > 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 From fperez.net at gmail.com Sun May 12 19:46:02 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 12 May 2013 16:46:02 -0700 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <518F9FA9.30507@third-bit.com> <20130512142327.GG20636@odin.tremily.us> <36C9A01A-E60E-4922-85C9-57B44F731346@gmail.com> <20130512145139.GH20636@odin.tremily.us> <20130512153547.GA23803@odin.tremily.us> <51900937.5030106@third-bit.com> <51901003.70206@third-bit.com> Message-ID: On Sun, May 12, 2013 at 4:23 PM, Brian Granger wrote: > It feels like we are trying to create a mini file editor in a notebook > cell. %%file and friends are not supposed to be that in any way. I > think %%file with prompting the user for overwrite is sufficient for > this particular purpose = write and store simple files in the > notebook. No, nobody is trying to create an editor, it's just that the *name* can be improved, and that's all I think is within scope here. The function makes a (potentially destructive) action, so it should be named as a verb, much like %%load is. %%file is indeed ambiguous, and we have proven evidence of confusion, which we should take into account. FWIW, with a name change I actually think that #3313 might not even be needed. I'll follow-up there on that point. Cheers, f From wking at tremily.us Sun May 12 19:51:26 2013 From: wking at tremily.us (W. Trevor King) Date: Sun, 12 May 2013 19:51:26 -0400 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <20130512153547.GA23803@odin.tremily.us> <51900937.5030106@third-bit.com> <51901003.70206@third-bit.com> Message-ID: <20130512235126.GA1495@odin.tremily.us> On Sun, May 12, 2013 at 04:23:31PM -0700, Brian Granger wrote: > It feels like we are trying to create a mini file editor in a notebook > cell. %%file and friends are not supposed to be that in any way. I > think %%file with prompting the user for overwrite is sufficient for > this particular purpose = write and store simple files in the > notebook. We're not trying to make an editor. We're just trying to figure out what the ?write to file? magic should be called. There's also already an existing line magic called `%save` which, strangly enough, looks like it does almost exactly the same thing as the cell magic `%%file` ;). Consolidated naming (a la `%timeit` and `%%timeit`) is probably a good idea. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From brad.froehle at gmail.com Mon May 13 01:00:00 2013 From: brad.froehle at gmail.com (Bradley M. Froehle) Date: Sun, 12 May 2013 22:00:00 -0700 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <518F9FA9.30507@third-bit.com> <20130512142327.GG20636@odin.tremily.us> <36C9A01A-E60E-4922-85C9-57B44F731346@gmail.com> <20130512145139.GH20636@odin.tremily.us> <20130512153547.GA23803@odin.tremily.us> <51900937.5030106@third-bit.com> <51901003.70206@third-bit.com> Message-ID: Hi, On Sun, May 12, 2013 at 4:46 PM, Fernando Perez wrote: > On Sun, May 12, 2013 at 4:23 PM, Brian Granger > wrote: > > It feels like we are trying to create a mini file editor in a notebook > > cell. %%file and friends are not supposed to be that in any way. I > > think %%file with prompting the user for overwrite is sufficient for > > this particular purpose = write and store simple files in the > > notebook. > > No, nobody is trying to create an editor, it's just that the *name* > can be improved, and that's all I think is within scope here. The > function makes a (potentially destructive) action, so it should be > named as a verb, much like %%load is. %%file is indeed ambiguous, and > we have proven evidence of confusion, which we should take into > account. > I agree with Fernando that the best course of action here might be to rename `%%file` into something less ambiguous. If we go down that road, I agree that at a minimum the name should be a verb which indicates that it will write to a file. Bonus points if it also indicates that the cell contents are what will be written to the file. The suggested verbs I've seen so far are `save`, `write`, and `overwrite`. Each of these could then be decorated with `file` or `f` (or `cell`) to increase the specificity. Unfortunately there isn't a good shell analogue to draw from here; the closest function would be `tee` which is very unix-y and not even perfect metaphor. Using `%%save` is problematic because there is already a different semantic meaning associated with `%save`. So, my vote would be for one of the following: * %%write * %%fwrite * %%writelines * %%writecell -Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Mon May 13 01:44:32 2013 From: benjaminrk at gmail.com (MinRK) Date: Sun, 12 May 2013 22:44:32 -0700 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <518F9FA9.30507@third-bit.com> <20130512142327.GG20636@odin.tremily.us> <36C9A01A-E60E-4922-85C9-57B44F731346@gmail.com> <20130512145139.GH20636@odin.tremily.us> <20130512153547.GA23803@odin.tremily.us> <51900937.5030106@third-bit.com> <51901003.70206@third-bit.com> Message-ID: %%overwrite doesn't sound good to me, since it isn't even accurate. %%fwrite (or the longer %%filewrite / %%writefile, which I understand but would not prefer) would be the front runner for me. Since all the magic does is: with open('filename', 'a' | 'w') as f: f.write(cell) I don't think anything with `save` in the name would be less confusing than plain `%%file`, since save already means something (a variety of things, actually) totally unrelated. I should point out that the current file magic, with PR #3313 cannot do anything destructive without thoroughly explicit user action. Personally, I think that restoring the overwrite prompt is all that should be done, but I appreciate the motivation to come up with a new name. On Sun, May 12, 2013 at 10:00 PM, Bradley M. Froehle wrote: > Hi, > > On Sun, May 12, 2013 at 4:46 PM, Fernando Perez wrote: > >> On Sun, May 12, 2013 at 4:23 PM, Brian Granger >> wrote: >> > It feels like we are trying to create a mini file editor in a notebook >> > cell. %%file and friends are not supposed to be that in any way. I >> > think %%file with prompting the user for overwrite is sufficient for >> > this particular purpose = write and store simple files in the >> > notebook. >> >> No, nobody is trying to create an editor, it's just that the *name* >> can be improved, and that's all I think is within scope here. The >> function makes a (potentially destructive) action, so it should be >> named as a verb, much like %%load is. %%file is indeed ambiguous, and >> we have proven evidence of confusion, which we should take into >> account. >> > > I agree with Fernando that the best course of action here might be to > rename `%%file` into something less ambiguous. If we go down that road, I > agree that at a minimum the name should be a verb which indicates that it > will write to a file. Bonus points if it also indicates that the cell > contents are what will be written to the file. > > The suggested verbs I've seen so far are `save`, `write`, and `overwrite`. > Each of these could then be decorated with `file` or `f` (or `cell`) to > increase the specificity. Unfortunately there isn't a good shell analogue > to draw from here; the closest function would be `tee` which is very unix-y > and not even perfect metaphor. > > Using `%%save` is problematic because there is already a different > semantic meaning associated with `%save`. > > So, my vote would be for one of the following: > * %%write > * %%fwrite > * %%writelines > * %%writecell > > -Brad > > _______________________________________________ > 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 May 13 08:25:46 2013 From: carl.input at gmail.com (Carl Smith) Date: Mon, 13 May 2013 13:25:46 +0100 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <518F9FA9.30507@third-bit.com> <20130512142327.GG20636@odin.tremily.us> <36C9A01A-E60E-4922-85C9-57B44F731346@gmail.com> <20130512145139.GH20636@odin.tremily.us> <20130512153547.GA23803@odin.tremily.us> <51900937.5030106@third-bit.com> <51901003.70206@third-bit.com> Message-ID: Does no one like %%flush ? I thought that was ideal. It didn't even make the candidates list :( -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Mon May 13 09:20:55 2013 From: takowl at gmail.com (Thomas Kluyver) Date: Mon, 13 May 2013 14:20:55 +0100 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <518F9FA9.30507@third-bit.com> <20130512142327.GG20636@odin.tremily.us> <36C9A01A-E60E-4922-85C9-57B44F731346@gmail.com> <20130512145139.GH20636@odin.tremily.us> <20130512153547.GA23803@odin.tremily.us> <51900937.5030106@third-bit.com> <51901003.70206@third-bit.com> Message-ID: On 13 May 2013 13:25, Carl Smith wrote: > Does no one like %%flush ? > > I thought that was ideal. It didn't even make the candidates list :( > I wouldn't immediately think of what the magic does as 'flushing' something, either if I was reading it or looking for it. Writing and saving seem like the clearest terms for the operation. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From bussonniermatthias at gmail.com Mon May 13 09:31:40 2013 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Mon, 13 May 2013 15:31:40 +0200 Subject: [IPython-dev] is markdown broken in latest ipython? In-Reply-To: <518F3726.8010402@gmail.com> References: <518F3726.8010402@gmail.com> Message-ID: Le 12 mai 2013 ? 08:31, Zolt?n V?r?s a ?crit : > Hi all, > > I have just pulled the master branch from git, and it seems to me that markdown rendering is broken. I used to have a short piece of script at the beginning of my notebooks, so that I can hide various fields. > > > toggle input The new marked parser replace the quotes in $("div.input") by their html escaped sequences: &39; same with simple quote. Would you like to open a bug report to be able to follow when a fix is available ? -- Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From zvoros at gmail.com Mon May 13 09:34:11 2013 From: zvoros at gmail.com (=?ISO-8859-1?Q?Zolt=E1n_V=F6r=F6s?=) Date: Mon, 13 May 2013 15:34:11 +0200 Subject: [IPython-dev] is markdown broken in latest ipython? In-Reply-To: References: <518F3726.8010402@gmail.com> Message-ID: <5190EBD3.9040808@gmail.com> Hi Matthias, I can open a ticket, no problem. In the meantime, is there a workaround? I know that I could inject javascript from the profile, but that can't be done on a notebook-by-notebook basis, can it? Whatever I place into the script folder will be inserted in all notebooks. Also, when sharing a notebook, I would have to distribute my script, and ask the person to place it in their own folder. Sort of awkward... Cheers, Zolt?n On 13/05/13 15:31, Matthias BUSSONNIER wrote: > > Le 12 mai 2013 ? 08:31, Zolt?n V?r?s a ?crit : > >> Hi all, >> >> I have just pulled the master branch from git, and it seems to me >> that markdown rendering is broken. I used to have a short piece of >> script at the beginning of my notebooks, so that I can hide various >> fields. >> >> >> toggle input > > The new marked parser replace the quotes in $("div.input") by their > html escaped sequences: &39; same with simple quote. > Would you like to open a bug report to be able to follow when a fix is > available ? > > -- > Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From carl.input at gmail.com Mon May 13 11:09:49 2013 From: carl.input at gmail.com (Carl Smith) Date: Mon, 13 May 2013 16:09:49 +0100 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <518F9FA9.30507@third-bit.com> <20130512142327.GG20636@odin.tremily.us> <36C9A01A-E60E-4922-85C9-57B44F731346@gmail.com> <20130512145139.GH20636@odin.tremily.us> <20130512153547.GA23803@odin.tremily.us> <51900937.5030106@third-bit.com> <51901003.70206@third-bit.com> Message-ID: Fair enough. I always think of pushing data from memory to storage as flushing it. I don't remember where I picked that term up from, but I guess it's less commonplace than I thought. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.froehle at gmail.com Mon May 13 11:15:28 2013 From: brad.froehle at gmail.com (Bradley M. Froehle) Date: Mon, 13 May 2013 08:15:28 -0700 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <518F9FA9.30507@third-bit.com> <20130512142327.GG20636@odin.tremily.us> <36C9A01A-E60E-4922-85C9-57B44F731346@gmail.com> <20130512145139.GH20636@odin.tremily.us> <20130512153547.GA23803@odin.tremily.us> <51900937.5030106@third-bit.com> <51901003.70206@third-bit.com> Message-ID: On Mon, May 13, 2013 at 5:25 AM, Carl Smith wrote: > Does no one like %%flush ? > > I thought that was ideal. It didn't even make the candidates list :( > Sorry Carl, that was an unintentional oversight on my part. Cheers, Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From carl.input at gmail.com Mon May 13 11:17:23 2013 From: carl.input at gmail.com (Carl Smith) Date: Mon, 13 May 2013 16:17:23 +0100 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <518F9FA9.30507@third-bit.com> <20130512142327.GG20636@odin.tremily.us> <36C9A01A-E60E-4922-85C9-57B44F731346@gmail.com> <20130512145139.GH20636@odin.tremily.us> <20130512153547.GA23803@odin.tremily.us> <51900937.5030106@third-bit.com> <51901003.70206@third-bit.com> Message-ID: I was only playing Brad, no worries. Thomas is right anyway, no one will search for flush. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gvwilson at third-bit.com Mon May 13 11:21:57 2013 From: gvwilson at third-bit.com (Greg Wilson) Date: Mon, 13 May 2013 11:21:57 -0400 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <51900937.5030106@third-bit.com> <51901003.70206@third-bit.com> Message-ID: <51910515.3010605@third-bit.com> On 2013-05-13 11:09 AM, Carl Smith wrote: > I always think of pushing data from memory to storage as flushing it. > I don't remember where I picked that term up from, but I guess it's > less commonplace than I thought. It's a common term among programmers (partly, I think, because 'fflush' has been part of the C standard library for more than 40 years), but it's not one that most non-programmers would recognize. That's why I'd like to try a lightweight name recognition/expectation check on users before finalizing new names... Thx, G From benjaminrk at gmail.com Mon May 13 11:28:07 2013 From: benjaminrk at gmail.com (MinRK) Date: Mon, 13 May 2013 08:28:07 -0700 Subject: [IPython-dev] is markdown broken in latest ipython? In-Reply-To: <5190EBD3.9040808@gmail.com> References: <518F3726.8010402@gmail.com> <5190EBD3.9040808@gmail.com> Message-ID: Bug is already open , and fix is already in marked. Just waiting for a release before we update the components. On Mon, May 13, 2013 at 6:34 AM, Zolt?n V?r?s wrote: > Hi Matthias, > > I can open a ticket, no problem. In the meantime, is there a workaround? I > know that I could inject javascript from the profile, but that can't be > done on a notebook-by-notebook basis, can it? Whatever I place into the > script folder will be inserted in all notebooks. Also, when sharing a > notebook, I would have to distribute my script, and ask the person to place > it in their own folder. Sort of awkward... > > Cheers, > Zolt?n > > > On 13/05/13 15:31, Matthias BUSSONNIER wrote: > > > Le 12 mai 2013 ? 08:31, Zolt?n V?r?s a ?crit : > > Hi all, > > I have just pulled the master branch from git, and it seems to me that > markdown rendering is broken. I used to have a short piece of script at the > beginning of my notebooks, so that I can hide various fields. > > > toggle input > > > The new marked parser replace the quotes in $("div.input") by their html > escaped sequences: &39; same with simple quote. > Would you like to open a bug report to be able to follow when a fix is > available ? > > -- > 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 zvoros at gmail.com Mon May 13 11:29:50 2013 From: zvoros at gmail.com (=?ISO-8859-1?Q?Zolt=E1n_V=F6r=F6s?=) Date: Mon, 13 May 2013 17:29:50 +0200 Subject: [IPython-dev] is markdown broken in latest ipython? In-Reply-To: References: <518F3726.8010402@gmail.com> <5190EBD3.9040808@gmail.com> Message-ID: <519106EE.9010404@gmail.com> Hi Min, Thanks for the info! Cheers, Zolt?n On 13/05/13 17:28, MinRK wrote: > Bug is already open > , and fix is > already in marked. Just waiting for a release before we update the > components. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Mon May 13 11:30:30 2013 From: ellisonbg at gmail.com (Brian Granger) Date: Mon, 13 May 2013 08:30:30 -0700 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: <51910515.3010605@third-bit.com> References: <51900937.5030106@third-bit.com> <51901003.70206@third-bit.com> <51910515.3010605@third-bit.com> Message-ID: I still favor %%file and adding the prompt to overwrite. On Mon, May 13, 2013 at 8:21 AM, Greg Wilson wrote: > On 2013-05-13 11:09 AM, Carl Smith wrote: >> I always think of pushing data from memory to storage as flushing it. >> I don't remember where I picked that term up from, but I guess it's >> less commonplace than I thought. > It's a common term among programmers (partly, I think, because 'fflush' > has been part of the C standard library for more than 40 years), but > it's not one that most non-programmers would recognize. That's why I'd > like to try a lightweight name recognition/expectation check on users > before finalizing new names... > Thx, > G > _______________________________________________ > 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 wking at tremily.us Mon May 13 11:55:36 2013 From: wking at tremily.us (W. Trevor King) Date: Mon, 13 May 2013 11:55:36 -0400 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <51900937.5030106@third-bit.com> <51901003.70206@third-bit.com> Message-ID: <20130513155536.GJ1495@odin.tremily.us> On Sun, May 12, 2013 at 10:00:00PM -0700, Bradley M. Froehle wrote: > Using `%%save` is problematic because there is already a different > semantic meaning associated with `%save`. After reading over the docstrings, I'm not seeing a semantic difference (just cell- vs. line-magic, which is obvious from the % prefixes). Can someone spell it out for me? I'm a bit sleep deprived, so apologies if I'm just being dense. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From bussonniermatthias at gmail.com Mon May 13 11:58:34 2013 From: bussonniermatthias at gmail.com (Matthias Bussonnier) Date: Mon, 13 May 2013 17:58:34 +0200 Subject: [IPython-dev] is markdown broken in latest ipython? In-Reply-To: <519106EE.9010404@gmail.com> References: <518F3726.8010402@gmail.com> <5190EBD3.9040808@gmail.com> <519106EE.9010404@gmail.com> Message-ID: My bad, I probably didn't configured github correctly to receive mails from IPython-components. Le lundi 13 mai 2013, Zolt?n V?r?s a ?crit : > Hi Min, > > Thanks for the info! > > Cheers, > Zolt?n > > On 13/05/13 17:28, MinRK wrote: > > Bug is already open, > and fix is already in marked. Just waiting for a release before we update > the components. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Mon May 13 14:30:07 2013 From: benjaminrk at gmail.com (Min RK) Date: Mon, 13 May 2013 11:30:07 -0700 Subject: [IPython-dev] is markdown broken in latest ipython? In-Reply-To: References: <518F3726.8010402@gmail.com> <5190EBD3.9040808@gmail.com> <519106EE.9010404@gmail.com> Message-ID: <352B7CF2-674F-409A-A535-FEA2AAD7250A@gmail.com> On May 13, 2013, at 8:58, Matthias Bussonnier wrote: > My bad, I probably didn't configured github correctly to receive mails from IPython-components. No worries, and it took me forever to find it, because I forgot the issue was opened against components. Perhaps we should disable Issues on components. Do note that, as described in that issue, script tags in markdown cells will be completely disabled by IPython 1.0 (as opposed to master, where they are merely broken). > > Le lundi 13 mai 2013, Zolt?n V?r?s a ?crit : >> Hi Min, >> >> Thanks for the info! >> >> Cheers, >> Zolt?n >> >> On 13/05/13 17:28, MinRK wrote: >>> Bug is already open, and fix is already in marked. Just waiting for a release before we update the components. > _______________________________________________ > 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 May 14 03:23:07 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 14 May 2013 00:23:07 -0700 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <51900937.5030106@third-bit.com> <51901003.70206@third-bit.com> <51910515.3010605@third-bit.com> Message-ID: On Mon, May 13, 2013 at 8:30 AM, Brian Granger wrote: > I still favor %%file and adding the prompt to overwrite. We have clear evidence of repeated user confusion with this, and it's an ambiguous name for something that's an action (and a potentially destructive one, at that). This is a case where user feedback (in this case collected by Greg) is showing us there's a real usability problem, we just need to fix it. Furthermore, making it by default interactive is going to cause all kinds of unexpected problems in automatically managed notebooks and scripts that will now block a process when they try to open a prompt. A rename to a verb term, along with the option of an interactive flag for those who clearly want that mode (and hence aren't worried about auto-execution) addresses cleanly both issues. Cheers, f From fperez.net at gmail.com Tue May 14 03:25:53 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 14 May 2013 00:25:53 -0700 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: <20130513155536.GJ1495@odin.tremily.us> References: <51900937.5030106@third-bit.com> <51901003.70206@third-bit.com> <20130513155536.GJ1495@odin.tremily.us> Message-ID: On Mon, May 13, 2013 at 8:55 AM, W. Trevor King wrote: > On Sun, May 12, 2013 at 10:00:00PM -0700, Bradley M. Froehle wrote: >> Using `%%save` is problematic because there is already a different >> semantic meaning associated with `%save`. > > After reading over the docstrings, I'm not seeing a semantic > difference (just cell- vs. line-magic, which is obvious from the % > prefixes). Can someone spell it out for me? > > I'm a bit sleep deprived, so apologies if I'm just being dense. No worries, it's an artifact of history: %save was written back when all we had was the terminal-based IPython, and it was meant as a quick way of grabbing chunks of history and putting them out on disk. There was no concept of cells back then. I think it would be perfectly reasonable to unify %save and %%file: into a single name and implementation: the line one would write history lines out to disk, thu> > Cheers, > Trevor > > -- > This email may be signed or encrypted with GnuPG (http://www.gnupg.org). s> For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > e cell one would do the same for its cell. We just need to pick a name :) f From dave.hirschfeld at gmail.com Tue May 14 06:21:38 2013 From: dave.hirschfeld at gmail.com (Dave Hirschfeld) Date: Tue, 14 May 2013 10:21:38 +0000 (UTC) Subject: [IPython-dev] Notebook ignoring --notebook-dir argument References: Message-ID: Dave Hirschfeld gmail.com> writes: > > When I start the notebook with `ipython notebook` from a terminal in a > specific directory it doesn't open in that directory, but in my home > directory. Specifying the `--notebook-dir` argument appears to have no effect. > > Is anyone else seeing this with the current master? > > Thanks, > Dave > I was going to attempt a git bisect but after updating to the latest master it seems it's working for me again. -Dave From krastanov.stefan at gmail.com Tue May 14 09:36:17 2013 From: krastanov.stefan at gmail.com (Stefan Krastanov) Date: Tue, 14 May 2013 15:36:17 +0200 Subject: [IPython-dev] _repr_javascript_ code samples for D3 In-Reply-To: References: Message-ID: I was able to hack together something that uses `publish_html` and `publish_javascript` in order to create a D3 graphic from within the ipython notebook: Prepare a container: publish_html("""
wrote: > Hi all, > > I have seen a nice visualization of networkx graph through d3.js in > the notebook. I want to use D3 to visualize some other objects. I > guess I should use `_repr_javascript_` but I do not know how the > scoping of javascript libraries works, how much is sandboxed by the > notebook, where to include the library, etc. I was hoping that you can > point me to a code sample that does it The Right Way(TM). > > A quick code search on github did not return anything useful. > > Regards > Stefan From bussonniermatthias at gmail.com Tue May 14 09:54:56 2013 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Tue, 14 May 2013 15:54:56 +0200 Subject: [IPython-dev] _repr_javascript_ code samples for D3 In-Reply-To: References: Message-ID: <1899802B-D35B-462D-B768-30D923781B4D@gmail.com> Hi stephan, Right now we are focusing on polishing IPython for the 1.0 around mid July, we plan on having meeting after to start discussing interactivity and dynamic graph (For example d3js) after that. There are some prototype and hack around, but none of them completely satisfy us. So right now, there are no "right way" to do it. I don't want to promise you too much, nor go too much into detail about something that would change, but we will probably define a way to tell o the notebook interface, "here are some javascrit plugin that know how to represent data" then on your object you would probably define a _json_repr_ that say "I hold the data of such type" And the js plugin will then be given the data and the container in which to do it's stuff. tricky part is that some plugin might want to have interaction with kernel, and that you also need to store the data for later convert ion (by nbviewer for example). In my vision of things, we could inspire on vega[1], and I already have some idea to integrate it with nbviewer to also have some dynamic representation with it. As for you problem, if you are on dev, you could simplify things by using custom.js and using a $.getScript(''http://d3js.org/d3.v3.min.js") in it, that will inject d3 library on all your notebooks, it will help. You can have a look at https://github.com/ipython/ipython/pull/2518 if you want some more place to start to know what where the issues with fist prototyping. [1] http://trifacta.github.io/vega/ -- Matthias Le 14 mai 2013 ? 15:36, Stefan Krastanov a ?crit : > I was able to hack together something that uses `publish_html` and > `publish_javascript` in order to create a D3 graphic from within the > ipython notebook: > > > Prepare a container: > > publish_html(""" >
"""%_ipython_div_counter) > > Load the library > > publish_javascript(""" > var script = document.createElement("script"); > script.src = "http://d3js.org/d3.v3.min.js"; > document.body.appendChild(script); > """) > > And after that another `publish_javascript` for doing the D3.js specific stuff. > > However I do not believe this is the correct way to create objects > that visualize nicely in IPython. Is there a guide how to do this The > Right Way(TM)? > > > On 8 May 2013 11:02, Stefan Krastanov wrote: >> Hi all, >> >> I have seen a nice visualization of networkx graph through d3.js in >> the notebook. I want to use D3 to visualize some other objects. I >> guess I should use `_repr_javascript_` but I do not know how the >> scoping of javascript libraries works, how much is sandboxed by the >> notebook, where to include the library, etc. I was hoping that you can >> point me to a code sample that does it The Right Way(TM). >> >> A quick code search on github did not return anything useful. >> >> Regards >> Stefan > _______________________________________________ > 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 krastanov.stefan at gmail.com Tue May 14 10:08:56 2013 From: krastanov.stefan at gmail.com (Stefan Krastanov) Date: Tue, 14 May 2013 16:08:56 +0200 Subject: [IPython-dev] _repr_javascript_ code samples for D3 In-Reply-To: <1899802B-D35B-462D-B768-30D923781B4D@gmail.com> References: <1899802B-D35B-462D-B768-30D923781B4D@gmail.com> Message-ID: Thanks for explaining your plans to me. If D3 representation becomes as simple as _repr_json_ in vega format it would be absolutely awesome. On 14 May 2013 15:54, Matthias BUSSONNIER wrote: > Hi stephan, > > Right now we are focusing on polishing IPython for the 1.0 around mid July, > we plan on having meeting after to start discussing interactivity and > dynamic > graph (For example d3js) after that. There are some prototype and hack > around, > but none of them completely satisfy us. > > So right now, there are no "right way" to do it. I don't want to promise you > too much, > nor go too much into detail about something that would change, but we will > probably define > a way to tell o the notebook interface, > > "here are some javascrit plugin that know how to represent data" > > then on your object you would probably define a _json_repr_ that say > > "I hold the data of such type" > > And the js plugin will then be given the data and the container in which to > do it's stuff. > > > tricky part is that some plugin might want to have interaction with kernel, > and that you also need to store > the data for later convert ion (by nbviewer for example). > > In my vision of things, we could inspire on vega[1], > and I already have some idea to integrate it with nbviewer to also have some > dynamic representation with it. > > As for you problem, if you are on dev, you could simplify things by using > custom.js > and using a $.getScript(''http://d3js.org/d3.v3.min.js") in it, that will > inject d3 library on all your notebooks, > it will help. > > You can have a look at https://github.com/ipython/ipython/pull/2518 if you > want some more place to start to > know what where the issues with fist prototyping. > > [1] http://trifacta.github.io/vega/ > > -- > Matthias > > > > Le 14 mai 2013 ? 15:36, Stefan Krastanov a ?crit : > > I was able to hack together something that uses `publish_html` and > `publish_javascript` in order to create a D3 graphic from within the > ipython notebook: > > > Prepare a container: > > publish_html(""" >
"""%_ipython_div_counter) > > Load the library > > publish_javascript(""" > var script = document.createElement("script"); > script.src = "http://d3js.org/d3.v3.min.js"; > document.body.appendChild(script); > """) > > And after that another `publish_javascript` for doing the D3.js specific > stuff. > > However I do not believe this is the correct way to create objects > that visualize nicely in IPython. Is there a guide how to do this The > Right Way(TM)? > > > On 8 May 2013 11:02, Stefan Krastanov wrote: > > Hi all, > > > I have seen a nice visualization of networkx graph through d3.js in > > the notebook. I want to use D3 to visualize some other objects. I > > guess I should use `_repr_javascript_` but I do not know how the > > scoping of javascript libraries works, how much is sandboxed by the > > notebook, where to include the library, etc. I was hoping that you can > > point me to a code sample that does it The Right Way(TM). > > > A quick code search on github did not return anything useful. > > > Regards > > Stefan > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > From benjaminrk at gmail.com Tue May 14 14:27:52 2013 From: benjaminrk at gmail.com (MinRK) Date: Tue, 14 May 2013 11:27:52 -0700 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <51900937.5030106@third-bit.com> <51901003.70206@third-bit.com> <51910515.3010605@third-bit.com> Message-ID: On Tue, May 14, 2013 at 12:23 AM, Fernando Perez wrote: > On Mon, May 13, 2013 at 8:30 AM, Brian Granger > wrote: > > I still favor %%file and adding the prompt to overwrite. > > We have clear evidence of repeated user confusion with this, and it's > an ambiguous name for something that's an action (and a potentially > destructive one, at that). This is a case where user feedback (in > this case collected by Greg) is showing us there's a real usability > problem, we just need to fix it. > Excluding every destructive consequence mentioned so far, since the empty cell issue is long-since addressed in master. > > Furthermore, making it by default interactive is going to cause all > kinds of unexpected problems in automatically managed notebooks and > scripts that will now block a process when they try to open a prompt. > That is true of all notebooks with interactive elements, what makes %%file special? > A rename to a verb term, along with the option of an interactive flag > for those who clearly want that mode (and hence aren't worried about > auto-execution) addresses cleanly both issues. > so if it were called `fwrite` or `writefile`, it would be okay to clobber by default? Renaming it doesn't make it any less destructive, and the destructive behavior is still implicit. I don't think there's any value in a non-default interactive behavior - either clobbering by default is fine, or it is unsafe and should be confirmed - safety being non-default won't ever be used. I'm fine renaming to `fwrite` without changing any behavior, if that makes more sense than prompting for overwrite, I'm just surprised that it seems to. > > 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 ellisonbg at gmail.com Tue May 14 15:35:32 2013 From: ellisonbg at gmail.com (Brian Granger) Date: Tue, 14 May 2013 12:35:32 -0700 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <51900937.5030106@third-bit.com> <51901003.70206@third-bit.com> <51910515.3010605@third-bit.com> Message-ID: On Tue, May 14, 2013 at 11:27 AM, MinRK wrote: > > > > On Tue, May 14, 2013 at 12:23 AM, Fernando Perez > wrote: >> >> On Mon, May 13, 2013 at 8:30 AM, Brian Granger >> wrote: >> > I still favor %%file and adding the prompt to overwrite. >> >> We have clear evidence of repeated user confusion with this, and it's >> an ambiguous name for something that's an action (and a potentially >> destructive one, at that). This is a case where user feedback (in >> this case collected by Greg) is showing us there's a real usability >> problem, we just need to fix it. > > > Excluding every destructive consequence mentioned so far, since the empty > cell issue is long-since addressed in master. > >> >> >> Furthermore, making it by default interactive is going to cause all >> kinds of unexpected problems in automatically managed notebooks and >> scripts that will now block a process when they try to open a prompt. > > > That is true of all notebooks with interactive elements, what makes %%file > special? I agree - if a user wants to get rid of the interactive element for these purposes, they can simply add the --overwrite flag. >> >> A rename to a verb term, along with the option of an interactive flag >> for those who clearly want that mode (and hence aren't worried about >> auto-execution) addresses cleanly both issues. > > > so if it were called `fwrite` or `writefile`, it would be okay to clobber by > default? Renaming it doesn't make it any less destructive, and the > destructive behavior is still implicit. My original intention with %%file is that people would never touch these files through any other means, so the overwrite wouldn't be a problem. But upon further thinking, I agree with Min that overwrite-by-default is just a bad idea. > I don't think there's any value in a non-default interactive behavior - > either clobbering by default is fine, or it is unsafe and should be > confirmed - safety being non-default won't ever be used. I agree. > I'm fine renaming to `fwrite` without changing any behavior, if that makes > more sense than prompting for overwrite, I'm just surprised that it seems > to. The name "%%file" is conceptually close to what the magic does = it writes/saves/creates a *file*. What you call the action (write/save/create) is ambiguous, the end result (file) is not. I don't want to pick a name that emphasizes the ambiguous part of the magic while underplaying the perfectly clear part (file). The name "%%fwrite" requires users to make the non-obvious conceptual jump that "f" = "file". That is a step back. If we do change the name (I am open to it but not thrilled about it) I would prefer something that makes its purpose more obvious: %%writefile %%savefile I also prefer names that order words in a grammatically sensible manner (%%writefile rather than %%filewrite) Cheers, Brian >> >> >> Cheers, >> >> f >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev > > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From njwilson23 at gmail.com Tue May 14 16:35:25 2013 From: njwilson23 at gmail.com (Nat Wilson) Date: Tue, 14 May 2013 13:35:25 -0700 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <51900937.5030106@third-bit.com> <51901003.70206@third-bit.com> <51910515.3010605@third-bit.com> Message-ID: > > The name "%%file" is conceptually close to what the magic does = it > writes/saves/creates a *file*. What you call the action > (write/save/create) is ambiguous, the end result (file) is not. > %%file could just as well mean read/load a file though, couldn't it? Having never used the %%file magic, I wasn't immediately sure what it did. Nat On Tue, May 14, 2013 at 12:35 PM, Brian Granger wrote: > On Tue, May 14, 2013 at 11:27 AM, MinRK wrote: > > > > > > > > On Tue, May 14, 2013 at 12:23 AM, Fernando Perez > > wrote: > >> > >> On Mon, May 13, 2013 at 8:30 AM, Brian Granger > >> wrote: > >> > I still favor %%file and adding the prompt to overwrite. > >> > >> We have clear evidence of repeated user confusion with this, and it's > >> an ambiguous name for something that's an action (and a potentially > >> destructive one, at that). This is a case where user feedback (in > >> this case collected by Greg) is showing us there's a real usability > >> problem, we just need to fix it. > > > > > > Excluding every destructive consequence mentioned so far, since the empty > > cell issue is long-since addressed in master. > > > >> > >> > >> Furthermore, making it by default interactive is going to cause all > >> kinds of unexpected problems in automatically managed notebooks and > >> scripts that will now block a process when they try to open a prompt. > > > > > > That is true of all notebooks with interactive elements, what makes > %%file > > special? > > I agree - if a user wants to get rid of the interactive element for > these purposes, they can simply add the --overwrite flag. > > >> > >> A rename to a verb term, along with the option of an interactive flag > >> for those who clearly want that mode (and hence aren't worried about > >> auto-execution) addresses cleanly both issues. > > > > > > so if it were called `fwrite` or `writefile`, it would be okay to > clobber by > > default? Renaming it doesn't make it any less destructive, and the > > destructive behavior is still implicit. > > My original intention with %%file is that people would never touch > these files through any other means, so the overwrite wouldn't be a > problem. But upon further thinking, I agree with Min that > overwrite-by-default is just a bad idea. > > > I don't think there's any value in a non-default interactive behavior - > > either clobbering by default is fine, or it is unsafe and should be > > confirmed - safety being non-default won't ever be used. > > I agree. > > > I'm fine renaming to `fwrite` without changing any behavior, if that > makes > > more sense than prompting for overwrite, I'm just surprised that it seems > > to. > > The name "%%file" is conceptually close to what the magic does = it > writes/saves/creates a *file*. What you call the action > (write/save/create) is ambiguous, the end result (file) is not. I > don't want to pick a name that emphasizes the ambiguous part of the > magic while underplaying the perfectly clear part (file). > > The name "%%fwrite" requires users to make the non-obvious conceptual > jump that "f" = "file". That is a step back. > > If we do change the name (I am open to it but not thrilled about it) I > would prefer something that makes its purpose more obvious: > > %%writefile > %%savefile > > I also prefer names that order words in a grammatically sensible > manner (%%writefile rather than %%filewrite) > > Cheers, > > Brian > > >> > >> > >> Cheers, > >> > >> f > >> _______________________________________________ > >> IPython-dev mailing list > >> IPython-dev at scipy.org > >> http://mail.scipy.org/mailman/listinfo/ipython-dev > > > > > > > > _______________________________________________ > > IPython-dev mailing list > > IPython-dev at scipy.org > > http://mail.scipy.org/mailman/listinfo/ipython-dev > > > > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Tue May 14 16:53:29 2013 From: benjaminrk at gmail.com (MinRK) Date: Tue, 14 May 2013 13:53:29 -0700 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <51900937.5030106@third-bit.com> <51901003.70206@third-bit.com> <51910515.3010605@third-bit.com> Message-ID: On Tue, May 14, 2013 at 12:35 PM, Brian Granger wrote: > On Tue, May 14, 2013 at 11:27 AM, MinRK wrote: > > > > > > > > On Tue, May 14, 2013 at 12:23 AM, Fernando Perez > > wrote: > >> > >> On Mon, May 13, 2013 at 8:30 AM, Brian Granger > >> wrote: > >> > I still favor %%file and adding the prompt to overwrite. > >> > >> We have clear evidence of repeated user confusion with this, and it's > >> an ambiguous name for something that's an action (and a potentially > >> destructive one, at that). This is a case where user feedback (in > >> this case collected by Greg) is showing us there's a real usability > >> problem, we just need to fix it. > > > > > > Excluding every destructive consequence mentioned so far, since the empty > > cell issue is long-since addressed in master. > > > >> > >> > >> Furthermore, making it by default interactive is going to cause all > >> kinds of unexpected problems in automatically managed notebooks and > >> scripts that will now block a process when they try to open a prompt. > > > > > > That is true of all notebooks with interactive elements, what makes > %%file > > special? > > I agree - if a user wants to get rid of the interactive element for > these purposes, they can simply add the --overwrite flag. > > >> > >> A rename to a verb term, along with the option of an interactive flag > >> for those who clearly want that mode (and hence aren't worried about > >> auto-execution) addresses cleanly both issues. > > > > > > so if it were called `fwrite` or `writefile`, it would be okay to > clobber by > > default? Renaming it doesn't make it any less destructive, and the > > destructive behavior is still implicit. > > My original intention with %%file is that people would never touch > these files through any other means, so the overwrite wouldn't be a > problem. But upon further thinking, I agree with Min that > overwrite-by-default is just a bad idea. > > > I don't think there's any value in a non-default interactive behavior - > > either clobbering by default is fine, or it is unsafe and should be > > confirmed - safety being non-default won't ever be used. > > I agree. > > > I'm fine renaming to `fwrite` without changing any behavior, if that > makes > > more sense than prompting for overwrite, I'm just surprised that it seems > > to. > > The name "%%file" is conceptually close to what the magic does = it > writes/saves/creates a *file*. What you call the action > (write/save/create) is ambiguous, the end result (file) is not. I > don't want to pick a name that emphasizes the ambiguous part of the > magic while underplaying the perfectly clear part (file). > > The name "%%fwrite" requires users to make the non-obvious conceptual > jump that "f" = "file". That is a step back. > > If we do change the name (I am open to it but not thrilled about it) I > would prefer something that makes its purpose more obvious: > > %%writefile > %%savefile > > I also prefer names that order words in a grammatically sensible > manner (%%writefile rather than %%filewrite) > The alternative argument here is that starting with `file` is more logically hierarchical / discoverable. `file` is the most relevant keyword, so it should be the start, which would make the magic more easily found, especially among completions. I'm torn, because both have disadvantages and neither is very good. > > Cheers, > > Brian > > >> > >> > >> Cheers, > >> > >> f > >> _______________________________________________ > >> IPython-dev mailing list > >> IPython-dev at scipy.org > >> http://mail.scipy.org/mailman/listinfo/ipython-dev > > > > > > > > _______________________________________________ > > IPython-dev mailing list > > IPython-dev at scipy.org > > http://mail.scipy.org/mailman/listinfo/ipython-dev > > > > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fereyes at lbl.gov Tue May 14 20:12:58 2013 From: fereyes at lbl.gov (Francis Reyes) Date: Tue, 14 May 2013 17:12:58 -0700 Subject: [IPython-dev] inject JS via magics? Message-ID: <8DED7AD1-FC2D-400C-8982-27CCCB05264B@lbl.gov> For ipython notebook, I'm having some fun with making my own magics. Is it possible to inject javascript code into the current notebook session via magics? Is there a Right Way ? Thanks, F Francis Reyes Advanced Light Source 1 Cyclotron Road Berkeley, CA 94720 From benjaminrk at gmail.com Tue May 14 20:17:58 2013 From: benjaminrk at gmail.com (MinRK) Date: Tue, 14 May 2013 17:17:58 -0700 Subject: [IPython-dev] inject JS via magics? In-Reply-To: <8DED7AD1-FC2D-400C-8982-27CCCB05264B@lbl.gov> References: <8DED7AD1-FC2D-400C-8982-27CCCB05264B@lbl.gov> Message-ID: Yes, that's fine. Just do: from IPython.display import display, Javascript display(Javascript("some_js();")) On Tue, May 14, 2013 at 5:12 PM, Francis Reyes wrote: > For ipython notebook, I'm having some fun with making my own magics. > > Is it possible to inject javascript code into the current notebook session > via magics? > > Is there a Right Way ? > > Thanks, > > F > > > > Francis Reyes > Advanced Light Source > 1 Cyclotron Road > Berkeley, CA 94720 > > > > _______________________________________________ > 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 steve.jackson at icecube.wisc.edu Wed May 15 11:26:39 2013 From: steve.jackson at icecube.wisc.edu (Steve Jackson) Date: Wed, 15 May 2013 10:26:39 -0500 Subject: [IPython-dev] execute() in IPython widgets Message-ID: <6F7A56DF-90E7-431B-B410-40D84FDB3BF9@icecube.wisc.edu> Greetings, I have an application using the RichIPythonWidget with the QtInProcessKernelManager. I often need to execute python scripts as if their contents had been typed directly into the widget, i.e., in the __main__ namespace. The command "execfile('myfile.py')" works correctly for this. (The magic function "%run myfile.py" does not work, because the file does not execute in the __main__ namespace, but that's okay.) So far, so good. Now I want to convince the RichIPythonWidget to behave as if the user had just typed "execfile('myfile.py')" and pressed enter. Specifically, I need three things to happen: (1) The widget should open and execute the file... (2) ... with the __main__ namespace ... (3) ... and print any print statements that the file has in it Here are some things that do not work: * widget.execute_file('foo.py') -- this behaves the same as the %run magic, providing (1) without (2). * widget.execute( 'execfile("foo.py")' ) -- this almost works, however, it does not provide (3). Print messages from foo.py are not echoed to the widget under any combination of arguments to this method. (In particular, they are suppressed even if interactive=True.) * widget.kernel_client.execute( 'execfile("myfile.py")' ) -- the file executes, but there are no print messages and exceptions are not raised. I realize this is a low-level API and that something would need to be done with its return value; I have not explored this further. Can anyone suggest a workaround? If this is a bug, I can file a bug report on github, but first I wanted to check whether I am missing something. ~S From bussonniermatthias at gmail.com Wed May 15 11:32:14 2013 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Wed, 15 May 2013 17:32:14 +0200 Subject: [IPython-dev] execute() in IPython widgets In-Reply-To: <6F7A56DF-90E7-431B-B410-40D84FDB3BF9@icecube.wisc.edu> References: <6F7A56DF-90E7-431B-B410-40D84FDB3BF9@icecube.wisc.edu> Message-ID: <596EF0D8-5A97-4071-BD0E-349E65564EC8@gmail.com> Le 15 mai 2013 ? 17:26, Steve Jackson a ?crit : > Greetings, > > I have an application using the RichIPythonWidget with the QtInProcessKernelManager. I often need to execute python scripts as if their contents had been typed directly into the widget, i.e., in the __main__ namespace. The command "execfile('myfile.py')" works correctly for this. (The magic function "%run myfile.py" does not work, because the file does not execute in the __main__ namespace, but that's okay.) Have a look at run -i Why not load the file like %%load does, or set the content of input buffer (stripping 2 first line if there is encoding declaration and shebang) and then execute it ? -- Matthias From steve.jackson at icecube.wisc.edu Wed May 15 11:56:53 2013 From: steve.jackson at icecube.wisc.edu (Steve Jackson) Date: Wed, 15 May 2013 10:56:53 -0500 Subject: [IPython-dev] execute() in IPython widgets In-Reply-To: <596EF0D8-5A97-4071-BD0E-349E65564EC8@gmail.com> References: <6F7A56DF-90E7-431B-B410-40D84FDB3BF9@icecube.wisc.edu> <596EF0D8-5A97-4071-BD0E-349E65564EC8@gmail.com> Message-ID: <80BDE17F-EFCA-42D5-A5B8-ABEE604D6443@icecube.wisc.edu> Thanks for the quick reply? On May 15, 2013, at 10:32 AM, Matthias BUSSONNIER wrote: > Have a look at run -i This is good to know about, but it doesn't solve my particular problem (more below). > Why not load the file like %%load does, or set the content of input buffer (stripping 2 first line if there is encoding declaration and shebang) and then execute it ? These approaches don't help me (I don't seem to have a %%load function, though I do have %load). But this have helped me isolate the problem with print messages. If I execute the following lines: widget.input_buffer = "print 'Hello'" widget.execute( interactive=True ) then the following output appears in the widget: In [1]: print 'Hello' However, the actual print statement is not echoed in the widget, as it would have if the command had been executed in response to user keyboard input. ~S From stefan at sun.ac.za Wed May 15 12:06:17 2013 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Wed, 15 May 2013 18:06:17 +0200 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <51900937.5030106@third-bit.com> <51901003.70206@third-bit.com> <51910515.3010605@third-bit.com> Message-ID: On Tue, May 14, 2013 at 10:53 PM, MinRK wrote: > The alternative argument here is that starting with `file` is more logically > hierarchical / discoverable. `file` is the most relevant keyword, so it > should be the start, which would make the magic more easily found, > especially among completions. I'm torn, because both have disadvantages and > neither is very good. Another alternative that might appeal to folks from the unix world: %%cat > file.txt %%cat >> file.txt %%cat file.txt (not implemented below) http://nbviewer.ipython.org/5585099 https://gist.github.com/stefanv/5585120 St?fan From steve.jackson at icecube.wisc.edu Wed May 15 12:25:14 2013 From: steve.jackson at icecube.wisc.edu (Steve Jackson) Date: Wed, 15 May 2013 11:25:14 -0500 Subject: [IPython-dev] execute() in IPython widgets In-Reply-To: <80BDE17F-EFCA-42D5-A5B8-ABEE604D6443@icecube.wisc.edu> References: <6F7A56DF-90E7-431B-B410-40D84FDB3BF9@icecube.wisc.edu> <596EF0D8-5A97-4071-BD0E-349E65564EC8@gmail.com> <80BDE17F-EFCA-42D5-A5B8-ABEE604D6443@icecube.wisc.edu> Message-ID: <4292A549-8CB7-4C7A-BDDA-D02F29EE7020@icecube.wisc.edu> My last message is somewhat incorrect, and the example bug it contains is more complex than I wrote. Here is a thing that fails in strange ways: widget.execute("print 'Message one'") widget.input_buffer = "print 'Second line'" widget.execute() When I run this sequence I see this output: In [2]: print 'Message one' Message one Message one In [1]: print 'Second line' Note that the first print message repeats twice, while the second is never printed. Perhaps this is a bug in execute(), or perhaps I am trying to do something unsupported. Sorry for the confusion in my earlier message. ~S > These approaches don't help me (I don't seem to have a %%load function, though I do have %load). But this have helped me isolate the problem with print messages. If I execute the following lines: > > widget.input_buffer = "print 'Hello'" > widget.execute( interactive=True ) > > then the following output appears in the widget: > > In [1]: print 'Hello' > > However, the actual print statement is not echoed in the widget, as it would have if the command had been executed in response to user keyboard input. > ~S > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From gvwilson at third-bit.com Wed May 15 16:08:10 2013 From: gvwilson at third-bit.com (Greg Wilson) Date: Wed, 15 May 2013 16:08:10 -0400 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <51910515.3010605@third-bit.com> Message-ID: <5193EB2A.2060308@third-bit.com> On 2013-05-15 12:06 PM, St?fan van der Walt wrote: > Another alternative that might appeal to folks from the unix world: > > %%cat > file.txt > %%cat >> file.txt > %%cat file.txt +1 --- this is elegant. - G From benjaminrk at gmail.com Wed May 15 16:09:59 2013 From: benjaminrk at gmail.com (MinRK) Date: Wed, 15 May 2013 13:09:59 -0700 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: <5193EB2A.2060308@third-bit.com> References: <51910515.3010605@third-bit.com> <5193EB2A.2060308@third-bit.com> Message-ID: With the exception of `%%cat file.txt`, since a cell magic that *reads* a file doesn't make sense. We could add `%cat`, though that's a duplicate of the already existing *alias* `cat`.? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wking at tremily.us Wed May 15 16:18:44 2013 From: wking at tremily.us (W. Trevor King) Date: Wed, 15 May 2013 16:18:44 -0400 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <51910515.3010605@third-bit.com> <5193EB2A.2060308@third-bit.com> Message-ID: <20130515201844.GL18348@odin.tremily.us> On Wed, May 15, 2013 at 01:09:59PM -0700, MinRK wrote: > With the exception of `%%cat file.txt`, since a cell magic that > *reads* a file doesn't make sense. I think this argument sinks the whole `%%cat` idea. The fact that `%%cat` is sometimes used to write files is due to shell redirection, not something inherent in the `cat` command (writing files with ?concatenate??). It's a good thing we can't have spaces in magic names, so I can't suggest the amusing `%%cat >$FILENAME < From fperez.net at gmail.com Wed May 15 17:25:27 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 15 May 2013 14:25:27 -0700 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <51910515.3010605@third-bit.com> <5193EB2A.2060308@third-bit.com> Message-ID: On Wed, May 15, 2013 at 1:09 PM, MinRK wrote: > With the exception of `%%cat file.txt`, since a cell magic that *reads* a > file doesn't make sense. We could add `%cat`, though that's a duplicate of > the already existing *alias* `cat`. I'm also -1 on cat for this, we don't want to have to explain shell redirection to understand an ipython magic. The problem with %%file is that it's easily mis-interpreted (and has been) by novice users, in that regard cat wouldn't be much improvement. A name that's fairly self-explanatory is what we want, even though we can't seem to find one everybody likes... From fperez.net at gmail.com Wed May 15 17:31:40 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 15 May 2013 14:31:40 -0700 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <51900937.5030106@third-bit.com> <51901003.70206@third-bit.com> <51910515.3010605@third-bit.com> Message-ID: On Tue, May 14, 2013 at 12:35 PM, Brian Granger wrote: > The name "%%file" is conceptually close to what the magic does = it > writes/saves/creates a *file*. What you call the action > (write/save/create) is ambiguous, the end result (file) is not. I > don't want to pick a name that emphasizes the ambiguous part of the > magic while underplaying the perfectly clear part (file). While I remember liking %%file when we had the initial naming discussions on this for these same reasons, unfortunately we have evidence that users do get confused by this. I've had the same question asked during teaching workshops over the last few months. If it's really confusing lots of users, we should find a way to mitigate that instead of having to answer this same question til the end of days. > The name "%%fwrite" requires users to make the non-obvious conceptual > jump that "f" = "file". That is a step back. Agreed, too cryptic. > If we do change the name (I am open to it but not thrilled about it) I > would prefer something that makes its purpose more obvious: > > %%writefile > %%savefile > > I also prefer names that order words in a grammatically sensible > manner (%%writefile rather than %%filewrite) Given that in python, the actual lingo uses 'write' (as in open('foo', 'w') and f.write() ), I think that writefile is probably my favorite choice. Starting with the word file helps a tiny bit discoverability/tab completion, but I also agree that a more natural reading probably outweighs that. >From everything we've seen so far, I'm leaning towards `writefile`, which should really be completely unambiguous to anyone and should clear this source of confusion once and for all. f From benjaminrk at gmail.com Wed May 15 17:38:06 2013 From: benjaminrk at gmail.com (MinRK) Date: Wed, 15 May 2013 14:38:06 -0700 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <51900937.5030106@third-bit.com> <51901003.70206@third-bit.com> <51910515.3010605@third-bit.com> Message-ID: On Wed, May 15, 2013 at 2:31 PM, Fernando Perez wrote: > On Tue, May 14, 2013 at 12:35 PM, Brian Granger > wrote: > > The name "%%file" is conceptually close to what the magic does = it > > writes/saves/creates a *file*. What you call the action > > (write/save/create) is ambiguous, the end result (file) is not. I > > don't want to pick a name that emphasizes the ambiguous part of the > > magic while underplaying the perfectly clear part (file). > > While I remember liking %%file when we had the initial naming > discussions on this for these same reasons, unfortunately we have > evidence that users do get confused by this. I've had the same > question asked during teaching workshops over the last few months. > > If it's really confusing lots of users, we should find a way to > mitigate that instead of having to answer this same question til the > end of days. > > > The name "%%fwrite" requires users to make the non-obvious conceptual > > jump that "f" = "file". That is a step back. > > Agreed, too cryptic. > > > If we do change the name (I am open to it but not thrilled about it) I > > would prefer something that makes its purpose more obvious: > > > > %%writefile > > %%savefile > > > > I also prefer names that order words in a grammatically sensible > > manner (%%writefile rather than %%filewrite) > > Given that in python, the actual lingo uses 'write' (as in open('foo', > 'w') and f.write() ), I think that writefile is probably my favorite > choice. Starting with the word file helps a tiny bit > discoverability/tab completion, but I also agree that a more natural > reading probably outweighs that. > > >From everything we've seen so far, I'm leaning towards `writefile`, > which should really be completely unambiguous to anyone and should > clear this source of confusion once and for all. > Then I think PR #3317 best reflects consensus - rename to `writefile`, no change in behavior. > > 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 ellisonbg at gmail.com Wed May 15 17:42:03 2013 From: ellisonbg at gmail.com (Brian Granger) Date: Wed, 15 May 2013 14:42:03 -0700 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <51900937.5030106@third-bit.com> <51901003.70206@third-bit.com> <51910515.3010605@third-bit.com> Message-ID: I too think that writefile is my favorite so for. What about prompting on overwrite. I think Min and I are in favor of that - but I think this new name resolves some of the confusion so I am fine either way. On Wed, May 15, 2013 at 2:38 PM, MinRK wrote: > > > > On Wed, May 15, 2013 at 2:31 PM, Fernando Perez > wrote: >> >> On Tue, May 14, 2013 at 12:35 PM, Brian Granger >> wrote: >> > The name "%%file" is conceptually close to what the magic does = it >> > writes/saves/creates a *file*. What you call the action >> > (write/save/create) is ambiguous, the end result (file) is not. I >> > don't want to pick a name that emphasizes the ambiguous part of the >> > magic while underplaying the perfectly clear part (file). >> >> While I remember liking %%file when we had the initial naming >> discussions on this for these same reasons, unfortunately we have >> evidence that users do get confused by this. I've had the same >> question asked during teaching workshops over the last few months. >> >> If it's really confusing lots of users, we should find a way to >> mitigate that instead of having to answer this same question til the >> end of days. >> >> > The name "%%fwrite" requires users to make the non-obvious conceptual >> > jump that "f" = "file". That is a step back. >> >> Agreed, too cryptic. >> >> > If we do change the name (I am open to it but not thrilled about it) I >> > would prefer something that makes its purpose more obvious: >> > >> > %%writefile >> > %%savefile >> > >> > I also prefer names that order words in a grammatically sensible >> > manner (%%writefile rather than %%filewrite) >> >> Given that in python, the actual lingo uses 'write' (as in open('foo', >> 'w') and f.write() ), I think that writefile is probably my favorite >> choice. Starting with the word file helps a tiny bit >> discoverability/tab completion, but I also agree that a more natural >> reading probably outweighs that. >> >> >From everything we've seen so far, I'm leaning towards `writefile`, >> which should really be completely unambiguous to anyone and should >> clear this source of confusion once and for all. > > > Then I think PR #3317 best reflects consensus - rename to `writefile`, > no change in behavior. > >> >> >> f >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev > > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From fperez.net at gmail.com Wed May 15 17:44:38 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 15 May 2013 14:44:38 -0700 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <51900937.5030106@third-bit.com> <51901003.70206@third-bit.com> <51910515.3010605@third-bit.com> Message-ID: I'm still mildly -1 on prompting on overwrite. I think of this like the default behavior of all unix commands, which is NOT to prompt the user for explicit interaction unless manually requests. But if people feel strongly about it, I can live with it. f On Wed, May 15, 2013 at 2:42 PM, Brian Granger wrote: > I too think that writefile is my favorite so for. What about > prompting on overwrite. I think Min and I are in favor of that - but > I think this new name resolves some of the confusion so I am fine > either way. > > On Wed, May 15, 2013 at 2:38 PM, MinRK wrote: >> >> >> >> On Wed, May 15, 2013 at 2:31 PM, Fernando Perez >> wrote: >>> >>> On Tue, May 14, 2013 at 12:35 PM, Brian Granger >>> wrote: >>> > The name "%%file" is conceptually close to what the magic does = it >>> > writes/saves/creates a *file*. What you call the action >>> > (write/save/create) is ambiguous, the end result (file) is not. I >>> > don't want to pick a name that emphasizes the ambiguous part of the >>> > magic while underplaying the perfectly clear part (file). >>> >>> While I remember liking %%file when we had the initial naming >>> discussions on this for these same reasons, unfortunately we have >>> evidence that users do get confused by this. I've had the same >>> question asked during teaching workshops over the last few months. >>> >>> If it's really confusing lots of users, we should find a way to >>> mitigate that instead of having to answer this same question til the >>> end of days. >>> >>> > The name "%%fwrite" requires users to make the non-obvious conceptual >>> > jump that "f" = "file". That is a step back. >>> >>> Agreed, too cryptic. >>> >>> > If we do change the name (I am open to it but not thrilled about it) I >>> > would prefer something that makes its purpose more obvious: >>> > >>> > %%writefile >>> > %%savefile >>> > >>> > I also prefer names that order words in a grammatically sensible >>> > manner (%%writefile rather than %%filewrite) >>> >>> Given that in python, the actual lingo uses 'write' (as in open('foo', >>> 'w') and f.write() ), I think that writefile is probably my favorite >>> choice. Starting with the word file helps a tiny bit >>> discoverability/tab completion, but I also agree that a more natural >>> reading probably outweighs that. >>> >>> >From everything we've seen so far, I'm leaning towards `writefile`, >>> which should really be completely unambiguous to anyone and should >>> clear this source of confusion once and for all. >> >> >> Then I think PR #3317 best reflects consensus - rename to `writefile`, >> no change in behavior. >> >>> >>> >>> f >>> _______________________________________________ >>> IPython-dev mailing list >>> IPython-dev at scipy.org >>> http://mail.scipy.org/mailman/listinfo/ipython-dev >> >> >> >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev >> > > > > -- > Brian E. Granger > Cal Poly State University, San Luis Obispo > bgranger at calpoly.edu and ellisonbg at gmail.com > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From ellisonbg at gmail.com Wed May 15 17:49:13 2013 From: ellisonbg at gmail.com (Brian Granger) Date: Wed, 15 May 2013 14:49:13 -0700 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <51900937.5030106@third-bit.com> <51901003.70206@third-bit.com> <51910515.3010605@third-bit.com> Message-ID: OK let's just do the rename and not prompt. On Wed, May 15, 2013 at 2:44 PM, Fernando Perez wrote: > I'm still mildly -1 on prompting on overwrite. I think of this like > the default behavior of all unix commands, which is NOT to prompt the > user for explicit interaction unless manually requests. > > But if people feel strongly about it, I can live with it. > > f > > On Wed, May 15, 2013 at 2:42 PM, Brian Granger wrote: >> I too think that writefile is my favorite so for. What about >> prompting on overwrite. I think Min and I are in favor of that - but >> I think this new name resolves some of the confusion so I am fine >> either way. >> >> On Wed, May 15, 2013 at 2:38 PM, MinRK wrote: >>> >>> >>> >>> On Wed, May 15, 2013 at 2:31 PM, Fernando Perez >>> wrote: >>>> >>>> On Tue, May 14, 2013 at 12:35 PM, Brian Granger >>>> wrote: >>>> > The name "%%file" is conceptually close to what the magic does = it >>>> > writes/saves/creates a *file*. What you call the action >>>> > (write/save/create) is ambiguous, the end result (file) is not. I >>>> > don't want to pick a name that emphasizes the ambiguous part of the >>>> > magic while underplaying the perfectly clear part (file). >>>> >>>> While I remember liking %%file when we had the initial naming >>>> discussions on this for these same reasons, unfortunately we have >>>> evidence that users do get confused by this. I've had the same >>>> question asked during teaching workshops over the last few months. >>>> >>>> If it's really confusing lots of users, we should find a way to >>>> mitigate that instead of having to answer this same question til the >>>> end of days. >>>> >>>> > The name "%%fwrite" requires users to make the non-obvious conceptual >>>> > jump that "f" = "file". That is a step back. >>>> >>>> Agreed, too cryptic. >>>> >>>> > If we do change the name (I am open to it but not thrilled about it) I >>>> > would prefer something that makes its purpose more obvious: >>>> > >>>> > %%writefile >>>> > %%savefile >>>> > >>>> > I also prefer names that order words in a grammatically sensible >>>> > manner (%%writefile rather than %%filewrite) >>>> >>>> Given that in python, the actual lingo uses 'write' (as in open('foo', >>>> 'w') and f.write() ), I think that writefile is probably my favorite >>>> choice. Starting with the word file helps a tiny bit >>>> discoverability/tab completion, but I also agree that a more natural >>>> reading probably outweighs that. >>>> >>>> >From everything we've seen so far, I'm leaning towards `writefile`, >>>> which should really be completely unambiguous to anyone and should >>>> clear this source of confusion once and for all. >>> >>> >>> Then I think PR #3317 best reflects consensus - rename to `writefile`, >>> no change in behavior. >>> >>>> >>>> >>>> f >>>> _______________________________________________ >>>> IPython-dev mailing list >>>> IPython-dev at scipy.org >>>> http://mail.scipy.org/mailman/listinfo/ipython-dev >>> >>> >>> >>> _______________________________________________ >>> IPython-dev mailing list >>> IPython-dev at scipy.org >>> http://mail.scipy.org/mailman/listinfo/ipython-dev >>> >> >> >> >> -- >> 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 > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From takowl at gmail.com Wed May 15 17:51:40 2013 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 15 May 2013 22:51:40 +0100 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <51900937.5030106@third-bit.com> <51901003.70206@third-bit.com> <51910515.3010605@third-bit.com> Message-ID: On 15 May 2013 22:42, Brian Granger wrote: > I too think that writefile is my favorite so for. What about > prompting on overwrite. I think Min and I are in favor of that - but > I think this new name resolves some of the confusion so I am fine > either way. > writefile gets my vote too. I'd side with not prompting - the name change and the empty-cell protection should avoid the accidents we've seen, and I think a prompt would get annoying if you're quickly re-running a notebook. Commands to overwrite files in both Python and shell scripting don't prompt, so arguably programmers are used to that behaviour (or should learn to expect it). I don't feel strongly about this, though, so long as there's an option to skip the prompt. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Wed May 15 17:59:31 2013 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Wed, 15 May 2013 23:59:31 +0200 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <51910515.3010605@third-bit.com> <5193EB2A.2060308@third-bit.com> Message-ID: On May 15, 2013 11:26 PM, "Fernando Perez" wrote: > I'm also -1 on cat for this, we don't want to have to explain shell > redirection to understand an ipython magic. Point taken, but the magics already behave in a shell-like way, so I don't think it's much of a leap. Perhaps a generic redirect magic would more clearly identify what is happening. This would also be a nice way of dumping Python output to file or stdout. E.g., it might be easier to have %%pipe /tmp/log print ''' Whatever you want in the file ''' St?fan -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Wed May 15 19:38:09 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 15 May 2013 16:38:09 -0700 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <51910515.3010605@third-bit.com> <5193EB2A.2060308@third-bit.com> Message-ID: Make a gist for it, pop a link to it in the extensions index! https://github.com/ipython/ipython/wiki/Extensions-Index Cheers, f On Wed, May 15, 2013 at 2:59 PM, St?fan van der Walt wrote: > On May 15, 2013 11:26 PM, "Fernando Perez" wrote: >> I'm also -1 on cat for this, we don't want to have to explain shell >> redirection to understand an ipython magic. > > Point taken, but the magics already behave in a shell-like way, so I don't > think it's much of a leap. > > Perhaps a generic redirect magic would more clearly identify what is > happening. This would also be a nice way of dumping Python output to file or > stdout. > > E.g., it might be easier to have > > %%pipe /tmp/log > print ''' > Whatever you want in the file > ''' > > St?fan > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > From fperez.net at gmail.com Wed May 15 21:22:29 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 15 May 2013 18:22:29 -0700 Subject: [IPython-dev] what goes wrong with %%file In-Reply-To: References: <51910515.3010605@third-bit.com> <5193EB2A.2060308@third-bit.com> Message-ID: for reference, merged: https://github.com/ipython/ipython/pull/3317 On Wed, May 15, 2013 at 4:38 PM, Fernando Perez wrote: > Make a gist for it, pop a link to it in the extensions index! > > https://github.com/ipython/ipython/wiki/Extensions-Index > > Cheers, > > f > > On Wed, May 15, 2013 at 2:59 PM, St?fan van der Walt wrote: >> On May 15, 2013 11:26 PM, "Fernando Perez" wrote: >>> I'm also -1 on cat for this, we don't want to have to explain shell >>> redirection to understand an ipython magic. >> >> Point taken, but the magics already behave in a shell-like way, so I don't >> think it's much of a leap. >> >> Perhaps a generic redirect magic would more clearly identify what is >> happening. This would also be a nice way of dumping Python output to file or >> stdout. >> >> E.g., it might be easier to have >> >> %%pipe /tmp/log >> print ''' >> Whatever you want in the file >> ''' >> >> St?fan >> >> >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev >> From ellisonbg at gmail.com Thu May 16 20:51:42 2013 From: ellisonbg at gmail.com (Brian Granger) Date: Thu, 16 May 2013 17:51:42 -0700 Subject: [IPython-dev] Flat is better than nested Message-ID: Hi, Fernando, Min and I met on Google+ hangout today to talk about some of the notebook reorganization. We plan on using Google+ more often, but want to make sure that we summarize decisions made there either on ipython-dev or an appropriate GitHub PR/issue. This email is to summarize the decisions from our G+ hangout. During that discussion we ended up talking about the deep nesting that we have in IPython.frontend Deep inside the notebook frontend, we end up with imports of the sort: IPython.frontend.html.notebook.handlers The qt frontend has similarly deep nesting. To solve this problem, we decided to flatten this out a bit. Here is what we decided: IPython.frontend.qt -> IPython.qt IPython.frontend.html.notebook -> IPython.html IPython.frontend.terminal -> IPython.terminal Future HTML frontends (like an HTML terminal) will go inside IPython.html because they need to share a lot of static assets (js/less/css). This will happen *after* my notebook re-org pull requests are landed. Comments? Questions? Cheers, Brian -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From fperez.net at gmail.com Thu May 16 21:06:53 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 16 May 2013 18:06:53 -0700 Subject: [IPython-dev] IPython "lab meetings" on g+ hangouts on air Message-ID: Hi folks, as Brian just mentioned, we had a google hangout discussion today, that arose impromptu from having a chat room discussion where it was obvious we needed more bandwidth than just typing can provide. Today (perhaps because of all the changes Google made yesterday, who knows), g+ was a bit glitchy, and we were unable to make the hangout on-air, so it ended up not being recorded. But in general we want all these discussions to be public, for example here's our previous one: http://www.youtube.com/watch?v=Yb35M8cW7o4 While I think it's great to jump in on video conversations like this as-needed from the dev room or a github issue/PR discussion, we've also been thinking about having a more regular 'lab meeting' style discussion that is scheduled at a fixed time. This would give a predictable time for everyone to participate, and would play the same role as lab meetings in everyday research, but taking into consideration the fact that we're an open, international collaboration. Those lab meetings would be held with hangouts on-air, and thus open for anyone who wants to watch and join, and kept on-record afterwards. The plan would be to hold them for ~60-90 minutes, to make regular progress on design decisions that impact the project at large. Impromptu hangouts as required by the everyday workflow will continue to happen, and we'll do our best to also record those in public format. If you like the idea, I'd like to propose Thursdays at 10am US Pacific time, i.e. UTC-7 hours right now (PDT). That's a good time for all the folks here in California while still being reasonable in Europe. I know we can't find a time that will work across all of Earth, but at least that probably covers reasonably well our current core team and lots of others. How does this sound to you all? Would the time work for a reasonable chunk of our active developers? Note that I am NOT asking only of the 'core' github committers, but of anyone who is putting lots of time into IPython work and is interested in joining these discussions. Cheers, f From ellisonbg at gmail.com Thu May 16 21:09:50 2013 From: ellisonbg at gmail.com (Brian Granger) Date: Thu, 16 May 2013 18:09:50 -0700 Subject: [IPython-dev] IPython "lab meetings" on g+ hangouts on air In-Reply-To: References: Message-ID: I like this idea and the time works fine for me... Cheers, Brian On Thu, May 16, 2013 at 6:06 PM, Fernando Perez wrote: > Hi folks, > > as Brian just mentioned, we had a google hangout discussion today, > that arose impromptu from having a chat room discussion where it was > obvious we needed more bandwidth than just typing can provide. > > Today (perhaps because of all the changes Google made yesterday, who > knows), g+ was a bit glitchy, and we were unable to make the hangout > on-air, so it ended up not being recorded. But in general we want all > these discussions to be public, for example here's our previous one: > > http://www.youtube.com/watch?v=Yb35M8cW7o4 > > While I think it's great to jump in on video conversations like this > as-needed from the dev room or a github issue/PR discussion, we've > also been thinking about having a more regular 'lab meeting' style > discussion that is scheduled at a fixed time. > > This would give a predictable time for everyone to participate, and > would play the same role as lab meetings in everyday research, but > taking into consideration the fact that we're an open, international > collaboration. > > Those lab meetings would be held with hangouts on-air, and thus open > for anyone who wants to watch and join, and kept on-record afterwards. > > The plan would be to hold them for ~60-90 minutes, to make regular > progress on design decisions that impact the project at large. > Impromptu hangouts as required by the everyday workflow will continue > to happen, and we'll do our best to also record those in public > format. > > If you like the idea, I'd like to propose Thursdays at 10am US Pacific > time, i.e. UTC-7 hours right now (PDT). That's a good time for all > the folks here in California while still being reasonable in Europe. > I know we can't find a time that will work across all of Earth, but at > least that probably covers reasonably well our current core team and > lots of others. > > How does this sound to you all? Would the time work for a reasonable > chunk of our active developers? Note that I am NOT asking only of the > 'core' github committers, but of anyone who is putting lots of time > into IPython work and is interested in joining these discussions. > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From benjaminrk at gmail.com Thu May 16 22:12:29 2013 From: benjaminrk at gmail.com (MinRK) Date: Thu, 16 May 2013 19:12:29 -0700 Subject: [IPython-dev] IPython "lab meetings" on g+ hangouts on air In-Reply-To: References: Message-ID: sounds good, and works for me. On Thu, May 16, 2013 at 6:09 PM, Brian Granger wrote: > I like this idea and the time works fine for me... > > Cheers, > > Brian > > On Thu, May 16, 2013 at 6:06 PM, Fernando Perez > wrote: > > Hi folks, > > > > as Brian just mentioned, we had a google hangout discussion today, > > that arose impromptu from having a chat room discussion where it was > > obvious we needed more bandwidth than just typing can provide. > > > > Today (perhaps because of all the changes Google made yesterday, who > > knows), g+ was a bit glitchy, and we were unable to make the hangout > > on-air, so it ended up not being recorded. But in general we want all > > these discussions to be public, for example here's our previous one: > > > > http://www.youtube.com/watch?v=Yb35M8cW7o4 > > > > While I think it's great to jump in on video conversations like this > > as-needed from the dev room or a github issue/PR discussion, we've > > also been thinking about having a more regular 'lab meeting' style > > discussion that is scheduled at a fixed time. > > > > This would give a predictable time for everyone to participate, and > > would play the same role as lab meetings in everyday research, but > > taking into consideration the fact that we're an open, international > > collaboration. > > > > Those lab meetings would be held with hangouts on-air, and thus open > > for anyone who wants to watch and join, and kept on-record afterwards. > > > > The plan would be to hold them for ~60-90 minutes, to make regular > > progress on design decisions that impact the project at large. > > Impromptu hangouts as required by the everyday workflow will continue > > to happen, and we'll do our best to also record those in public > > format. > > > > If you like the idea, I'd like to propose Thursdays at 10am US Pacific > > time, i.e. UTC-7 hours right now (PDT). That's a good time for all > > the folks here in California while still being reasonable in Europe. > > I know we can't find a time that will work across all of Earth, but at > > least that probably covers reasonably well our current core team and > > lots of others. > > > > How does this sound to you all? Would the time work for a reasonable > > chunk of our active developers? Note that I am NOT asking only of the > > 'core' github committers, but of anyone who is putting lots of time > > into IPython work and is interested in joining these discussions. > > > > 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 > _______________________________________________ > 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 jtratner at gmail.com Thu May 16 23:55:55 2013 From: jtratner at gmail.com (Jeffrey Tratner) Date: Thu, 16 May 2013 23:55:55 -0400 Subject: [IPython-dev] Cell magic for closures Message-ID: Hi all, I've been using ipython notebook for a project at work and I really enjoy it. The only issue that I have is that sometimes using the code in cells and editing code on the fly means that you unintentionally define globals without meaning to. Clearly you can define a new function, but that also pollutes the name space and just feels weird. Javascript has a convention of wrapping code in an immediately executed function and I know that someone has proposed adding something like a given keyword to python to accomplish something similar, but it'd be nice to be able to do it without adding an extra level of indentation and to be able to do it in 2.7. I'm imagining a syntax like %%closure that consumes a cell and executes it as if it were underneath a def statement. This has the benefit of reducing the level of indentation as well as doing things like this: within_cell_variable = xyz # do something del within_cell_variable --- or if you need to iterate over something, suddenly you've polluted the namespace with a random off variable. I'd love to have this, I think it would be useful in the context of a notebook and reduce the amount of def statements used only to encapsulate variables. It's also kinda magical I guess. Best, Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From jetaylor74 at gmail.com Fri May 17 03:03:47 2013 From: jetaylor74 at gmail.com (Jonathan Taylor) Date: Fri, 17 May 2013 00:03:47 -0700 Subject: [IPython-dev] using _repr_* Message-ID: * I have been trying to understand the _repr_ methods and have a class with a _repr_latex_ method in this simple file: http://nbviewer.ipython.org/url/stat.stanford.edu/~jtaylo/notebooks/latex_repr.ipynb * I expected to see rendered latex output -- should I not expect this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From asmeurer at gmail.com Fri May 17 03:18:38 2013 From: asmeurer at gmail.com (Aaron Meurer) Date: Fri, 17 May 2013 01:18:38 -0600 Subject: [IPython-dev] using _repr_* In-Reply-To: References: Message-ID: I think this issue, according to the LatexFormatter documentation, is that you need to wrap the latex in $ or $$. Aaron Meurer On Fri, May 17, 2013 at 1:03 AM, Jonathan Taylor wrote: > * I have been trying to understand the _repr_ methods and have a class > with a _repr_latex_ method in this simple file: > > > http://nbviewer.ipython.org/url/stat.stanford.edu/~jtaylo/notebooks/latex_repr.ipynb > > * I expected to see rendered latex output -- should I not expect this? > > > > _______________________________________________ > 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 jonathan.taylor at stanford.edu Fri May 17 03:24:57 2013 From: jonathan.taylor at stanford.edu (Jonathan Taylor) Date: Fri, 17 May 2013 00:24:57 -0700 Subject: [IPython-dev] using _repr_* In-Reply-To: References: Message-ID: Great, thanks. I didn't see that in the examples. On Fri, May 17, 2013 at 12:03 AM, Jonathan Taylor wrote: > * I have been trying to understand the _repr_ methods and have a class > with a _repr_latex_ method in this simple file: > > > http://nbviewer.ipython.org/url/stat.stanford.edu/~jtaylo/notebooks/latex_repr.ipynb > > * I expected to see rendered latex output -- should I not expect this? > > > -- Jonathan Taylor Dept. of Statistics Sequoia Hall, 137 390 Serra Mall Stanford, CA 94305 Tel: 650.723.9230 Fax: 650.725.8977 Web: http://www-stat.stanford.edu/~jtaylo -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Fri May 17 03:44:18 2013 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Fri, 17 May 2013 09:44:18 +0200 Subject: [IPython-dev] Flat is better than nested In-Reply-To: References: Message-ID: On Fri, May 17, 2013 at 2:51 AM, Brian Granger wrote: > During that discussion we ended up talking about the deep nesting that > we have in IPython.frontend > > Deep inside the notebook frontend, we end up with imports of the sort: > > IPython.frontend.html.notebook.handlers > > The qt frontend has similarly deep nesting. > > To solve this problem, we decided to flatten this out a bit. Here is > what we decided: > > IPython.frontend.qt -> IPython.qt > IPython.frontend.html.notebook -> IPython.html > IPython.frontend.terminal -> IPython.terminal That seems like a minor saving when measured against the loss of structure. When I see "ipython.frontend.qt" I know exactly what you mean, whereas "IPython.qt" doesn't evoke anything specific. Isn't the nesting problem rather deeper down, i.e. under qt, html and terminal? St?fan From bussonniermatthias at gmail.com Fri May 17 04:34:16 2013 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Fri, 17 May 2013 10:34:16 +0200 Subject: [IPython-dev] IPython "lab meetings" on g+ hangouts on air In-Reply-To: References: Message-ID: <8957A5CD-17C2-4C2C-87F0-7DE893367AD7@gmail.com> Le 17 mai 2013 ? 03:06, Fernando Perez a ?crit : > Hi folks, > [?] > http://www.youtube.com/watch?v=Yb35M8cW7o4 > Catching up? > If you like the idea, I'd like to propose Thursdays at 10am US Pacific > time, i.e. UTC-7 hours right now (PDT). That's a good time for all > the folks here in California while still being reasonable in Europe. > I know we can't find a time that will work across all of Earth, but at > least that probably covers reasonably well our current core team and > lots of others. Seem great, I would suggest having even an IPython Channel on youtube, and/or a google doc on which we can write before/after what we should be talking about/ what have been decided. -- Matthias From takowl at gmail.com Fri May 17 08:14:57 2013 From: takowl at gmail.com (Thomas Kluyver) Date: Fri, 17 May 2013 13:14:57 +0100 Subject: [IPython-dev] Cell magic for closures In-Reply-To: References: Message-ID: Hmm, that's an interesting idea. Running it under a def might cause some other problems, like UnboundLocalErrors when you try to modify variables. Another approach might be a cell magic that remembered what globals were defined at the start of the cell, and removed any new ones after running the cell. Perhaps it would be best to collect some examples of cases where this would be useful, to see what's the best way to do it. You can of course write an extension for it: http://ipython.org/ipython-doc/stable/config/extensions/index.html Best wishes, Thomas On 17 May 2013 04:55, Jeffrey Tratner wrote: > Hi all, > > I've been using ipython notebook for a project at work and I really enjoy > it. The only issue that I have is that sometimes using the code in cells > and editing code on the fly means that you unintentionally define globals > without meaning to. Clearly you can define a new function, but that also > pollutes the name space and just feels weird. > > Javascript has a convention of wrapping code in an immediately executed > function and I know that someone has proposed adding something like a given > keyword to python to accomplish something similar, but it'd be nice to be > able to do it without adding an extra level of indentation and to be able > to do it in 2.7. > > I'm imagining a syntax like %%closure that consumes a cell and executes it > as if it were underneath a def statement. This has the benefit of reducing > the level of indentation as well as doing things like this: > > within_cell_variable = xyz > > # do something > > del within_cell_variable > > --- > > or if you need to iterate over something, suddenly you've polluted the > namespace with a random off variable. > > I'd love to have this, I think it would be useful in the context of a > notebook and reduce the amount of def statements used only to encapsulate > variables. It's also kinda magical I guess. > > Best, > > Jeff > > _______________________________________________ > 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 jtratner at gmail.com Fri May 17 08:23:00 2013 From: jtratner at gmail.com (Jeffrey Tratner) Date: Fri, 17 May 2013 08:23:00 -0400 Subject: [IPython-dev] Cell magic for closures In-Reply-To: References: Message-ID: That's a good point about unbound locals. Thanks for the link to the extensions page. On May 17, 2013 8:15 AM, "Thomas Kluyver" wrote: > Hmm, that's an interesting idea. Running it under a def might cause some > other problems, like UnboundLocalErrors when you try to modify variables. > Another approach might be a cell magic that remembered what globals were > defined at the start of the cell, and removed any new ones after running > the cell. > > Perhaps it would be best to collect some examples of cases where this > would be useful, to see what's the best way to do it. You can of course > write an extension for it: > http://ipython.org/ipython-doc/stable/config/extensions/index.html > > Best wishes, > Thomas > > > On 17 May 2013 04:55, Jeffrey Tratner wrote: > >> Hi all, >> >> I've been using ipython notebook for a project at work and I really enjoy >> it. The only issue that I have is that sometimes using the code in cells >> and editing code on the fly means that you unintentionally define globals >> without meaning to. Clearly you can define a new function, but that also >> pollutes the name space and just feels weird. >> >> Javascript has a convention of wrapping code in an immediately executed >> function and I know that someone has proposed adding something like a given >> keyword to python to accomplish something similar, but it'd be nice to be >> able to do it without adding an extra level of indentation and to be able >> to do it in 2.7. >> >> I'm imagining a syntax like %%closure that consumes a cell and executes >> it as if it were underneath a def statement. This has the benefit of >> reducing the level of indentation as well as doing things like this: >> >> within_cell_variable = xyz >> >> # do something >> >> del within_cell_variable >> >> --- >> >> or if you need to iterate over something, suddenly you've polluted the >> namespace with a random off variable. >> >> I'd love to have this, I think it would be useful in the context of a >> notebook and reduce the amount of def statements used only to encapsulate >> variables. It's also kinda magical I guess. >> >> Best, >> >> Jeff >> >> _______________________________________________ >> 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 ccordoba12 at gmail.com Fri May 17 12:19:47 2013 From: ccordoba12 at gmail.com (=?UTF-8?B?Q2FybG9zIEPDs3Jkb2Jh?=) Date: Fri, 17 May 2013 11:19:47 -0500 Subject: [IPython-dev] Flat is better than nested In-Reply-To: References: Message-ID: <519658A3.3000007@gmail.com> I agree with St?fan: removing "frontend" isn't much of a help, because it has a compelling and easy meaning to grasp. For us in Spyder it would be better to be able to import things like RichIPythonWidget as from IPython.frontend.qt import RichIPythonWidget instead of from IPython.qt.console.rich_ipython_widget import RichIPythonWidget because even without "frontend" there are four levels of nested modules to reach one of the most essential pieces of that frontend. So why not add an __all__ attribute to each frontend instead? Cheers, Carlos El 17/05/13 02:44, St?fan van der Walt escribi?: > On Fri, May 17, 2013 at 2:51 AM, Brian Granger wrote: >> During that discussion we ended up talking about the deep nesting that >> we have in IPython.frontend >> >> Deep inside the notebook frontend, we end up with imports of the sort: >> >> IPython.frontend.html.notebook.handlers >> >> The qt frontend has similarly deep nesting. >> >> To solve this problem, we decided to flatten this out a bit. Here is >> what we decided: >> >> IPython.frontend.qt -> IPython.qt >> IPython.frontend.html.notebook -> IPython.html >> IPython.frontend.terminal -> IPython.terminal > That seems like a minor saving when measured against the loss of > structure. When I see "ipython.frontend.qt" I know exactly what you > mean, whereas "IPython.qt" doesn't evoke anything specific. Isn't the > nesting problem rather deeper down, i.e. under qt, html and terminal? > > St?fan > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Fri May 17 12:53:28 2013 From: ellisonbg at gmail.com (Brian Granger) Date: Fri, 17 May 2013 09:53:28 -0700 Subject: [IPython-dev] Flat is better than nested In-Reply-To: <519658A3.3000007@gmail.com> References: <519658A3.3000007@gmail.com> Message-ID: A few points: * The html.notebook level are redundant. We will only have 1 html frontend. * We have an eye to split off our different frontends as separate projects in the future. They are much too unstable at this point to do that, but this move to bring html/qt/terminal to the top level reflects that direction of thinking - they are of top level importance. Cheers, Brian On Fri, May 17, 2013 at 9:19 AM, Carlos C?rdoba wrote: > I agree with St?fan: removing "frontend" isn't much of a help, because it > has a compelling and easy meaning to grasp. > > For us in Spyder it would be better to be able to import things like > RichIPythonWidget as > > from IPython.frontend.qt import RichIPythonWidget > > instead of > > from IPython.qt.console.rich_ipython_widget import RichIPythonWidget > > because even without "frontend" there are four levels of nested modules to > reach one of the most essential pieces of that frontend. > > So why not add an __all__ attribute to each frontend instead? > > Cheers, > Carlos > > El 17/05/13 02:44, St?fan van der Walt escribi?: > > On Fri, May 17, 2013 at 2:51 AM, Brian Granger wrote: > > During that discussion we ended up talking about the deep nesting that > we have in IPython.frontend > > Deep inside the notebook frontend, we end up with imports of the sort: > > IPython.frontend.html.notebook.handlers > > The qt frontend has similarly deep nesting. > > To solve this problem, we decided to flatten this out a bit. Here is > what we decided: > > IPython.frontend.qt -> IPython.qt > IPython.frontend.html.notebook -> IPython.html > IPython.frontend.terminal -> IPython.terminal > > That seems like a minor saving when measured against the loss of > structure. When I see "ipython.frontend.qt" I know exactly what you > mean, whereas "IPython.qt" doesn't evoke anything specific. Isn't the > nesting problem rather deeper down, i.e. under qt, html and terminal? > > St?fan > _______________________________________________ > 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 From benjaminrk at gmail.com Fri May 17 15:50:46 2013 From: benjaminrk at gmail.com (MinRK) Date: Fri, 17 May 2013 12:50:46 -0700 Subject: [IPython-dev] Cell magic for closures In-Reply-To: References: Message-ID: Here's an exampleof what two approaches might look like. On Fri, May 17, 2013 at 5:23 AM, Jeffrey Tratner wrote: > That's a good point about unbound locals. Thanks for the link to the > extensions page. > On May 17, 2013 8:15 AM, "Thomas Kluyver" wrote: > >> Hmm, that's an interesting idea. Running it under a def might cause some >> other problems, like UnboundLocalErrors when you try to modify variables. >> Another approach might be a cell magic that remembered what globals were >> defined at the start of the cell, and removed any new ones after running >> the cell. >> >> Perhaps it would be best to collect some examples of cases where this >> would be useful, to see what's the best way to do it. You can of course >> write an extension for it: >> http://ipython.org/ipython-doc/stable/config/extensions/index.html >> >> Best wishes, >> Thomas >> >> >> On 17 May 2013 04:55, Jeffrey Tratner wrote: >> >>> Hi all, >>> >>> I've been using ipython notebook for a project at work and I really >>> enjoy it. The only issue that I have is that sometimes using the code in >>> cells and editing code on the fly means that you unintentionally define >>> globals without meaning to. Clearly you can define a new function, but that >>> also pollutes the name space and just feels weird. >>> >>> Javascript has a convention of wrapping code in an immediately executed >>> function and I know that someone has proposed adding something like a given >>> keyword to python to accomplish something similar, but it'd be nice to be >>> able to do it without adding an extra level of indentation and to be able >>> to do it in 2.7. >>> >>> I'm imagining a syntax like %%closure that consumes a cell and executes >>> it as if it were underneath a def statement. This has the benefit of >>> reducing the level of indentation as well as doing things like this: >>> >>> within_cell_variable = xyz >>> >>> # do something >>> >>> del within_cell_variable >>> >>> --- >>> >>> or if you need to iterate over something, suddenly you've polluted the >>> namespace with a random off variable. >>> >>> I'd love to have this, I think it would be useful in the context of a >>> notebook and reduce the amount of def statements used only to encapsulate >>> variables. It's also kinda magical I guess. >>> >>> Best, >>> >>> Jeff >>> >>> _______________________________________________ >>> 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 ccordoba12 at gmail.com Fri May 17 15:51:54 2013 From: ccordoba12 at gmail.com (=?UTF-8?B?Q2FybG9zIEPDs3Jkb2Jh?=) Date: Fri, 17 May 2013 14:51:54 -0500 Subject: [IPython-dev] Flat is better than nested In-Reply-To: References: <519658A3.3000007@gmail.com> Message-ID: <51968A5A.6090500@gmail.com> Ok, thanks for the answer, that makes more sense (although I don't agree with making such changes so far ahead in time). But what about my proposal of an __all__ attribute? That would make IPython consumer lives much easier and pleasant. Cheers, Carlos El 17/05/13 11:53, Brian Granger escribi?: > A few points: > > * The html.notebook level are redundant. We will only have 1 html frontend. > * We have an eye to split off our different frontends as separate > projects in the future. They are much too unstable at this point to > do that, but this move to bring html/qt/terminal to the top level > reflects that direction of thinking - they are of top level > importance. > > Cheers, > > Brian > > On Fri, May 17, 2013 at 9:19 AM, Carlos C?rdoba wrote: >> I agree with St?fan: removing "frontend" isn't much of a help, because it >> has a compelling and easy meaning to grasp. >> >> For us in Spyder it would be better to be able to import things like >> RichIPythonWidget as >> >> from IPython.frontend.qt import RichIPythonWidget >> >> instead of >> >> from IPython.qt.console.rich_ipython_widget import RichIPythonWidget >> >> because even without "frontend" there are four levels of nested modules to >> reach one of the most essential pieces of that frontend. >> >> So why not add an __all__ attribute to each frontend instead? >> >> Cheers, >> Carlos >> >> El 17/05/13 02:44, St?fan van der Walt escribi?: >> >> On Fri, May 17, 2013 at 2:51 AM, Brian Granger wrote: >> >> During that discussion we ended up talking about the deep nesting that >> we have in IPython.frontend >> >> Deep inside the notebook frontend, we end up with imports of the sort: >> >> IPython.frontend.html.notebook.handlers >> >> The qt frontend has similarly deep nesting. >> >> To solve this problem, we decided to flatten this out a bit. Here is >> what we decided: >> >> IPython.frontend.qt -> IPython.qt >> IPython.frontend.html.notebook -> IPython.html >> IPython.frontend.terminal -> IPython.terminal >> >> That seems like a minor saving when measured against the loss of >> structure. When I see "ipython.frontend.qt" I know exactly what you >> mean, whereas "IPython.qt" doesn't evoke anything specific. Isn't the >> nesting problem rather deeper down, i.e. under qt, html and terminal? >> >> St?fan >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev >> >> >> >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev >> > > From fperez.net at gmail.com Fri May 17 18:16:49 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 17 May 2013 15:16:49 -0700 Subject: [IPython-dev] Flat is better than nested In-Reply-To: <51968A5A.6090500@gmail.com> References: <519658A3.3000007@gmail.com> <51968A5A.6090500@gmail.com> Message-ID: Hi Carlos, On Fri, May 17, 2013 at 12:51 PM, Carlos C?rdoba wrote: > Ok, thanks for the answer, that makes more sense (although I don't agree > with making such changes so far ahead in time). > > But what about my proposal of an __all__ attribute? That would make > IPython consumer lives much easier and pleasant. Yes, that's something we actually need to work on and that's been on my radar for a long time: exposing for some of the main packages a bit of interface in the main __init__ file. BTW, it's worth noting that the Qt code in IPython is very much in need of engineering love... You guys and Enthought are the main stakeholders in there, but there's not a ton of activity. The reality is that it's a bit of a liability to have a complex code like that where the most active core IPython team isn't really using it. So if you see architectural cleanups that you can make, by all means dig into the code. I'm sure things will be better for everyone involved if that part of the code gains some more active maintainership. Cheers, f From krastanov.stefan at gmail.com Sat May 18 14:04:00 2013 From: krastanov.stefan at gmail.com (Stefan Krastanov) Date: Sat, 18 May 2013 20:04:00 +0200 Subject: [IPython-dev] implementing sympy plots with d3 in the notebook Message-ID: Hello all, If any of you have 5 minutes to tell us whether we are doing something horribly wrong we would appreciate it. Recently, I tried to extend the sympy plotting module so that we can plot with d3. A proof of concept can be seen here (sympy pull request, vega and d3): https://github.com/sympy/sympy/pull/2120 The 5 lines that deal with ipython are in `def show(self):` A more hackish earlier version can be seen here (blog post, only d3): http://blog.krastanov.org/2013/05/14/sympy-plots-with-d3-in-ipyhton/ What is the IPython team opinion? Should we wait a few months for somekind of `_repr_json`? Regards Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From damianavila at gmail.com Sun May 19 11:45:36 2013 From: damianavila at gmail.com (=?ISO-8859-1?Q?Dami=E1n_Avila?=) Date: Sun, 19 May 2013 12:45:36 -0300 Subject: [IPython-dev] IPython "lab meetings" on g+ hangouts on air In-Reply-To: References: Message-ID: <5198F3A0.7080502@gmail.com> El 16/05/13 22:06, Fernando Perez escribi?: > Hi folks, > > as Brian just mentioned, we had a google hangout discussion today, > that arose impromptu from having a chat room discussion where it was > obvious we needed more bandwidth than just typing can provide. > > Today (perhaps because of all the changes Google made yesterday, who > knows), g+ was a bit glitchy, and we were unable to make the hangout > on-air, so it ended up not being recorded. But in general we want all > these discussions to be public, for example here's our previous one: > > http://www.youtube.com/watch?v=Yb35M8cW7o4 > > While I think it's great to jump in on video conversations like this > as-needed from the dev room or a github issue/PR discussion, we've > also been thinking about having a more regular 'lab meeting' style > discussion that is scheduled at a fixed time. > > This would give a predictable time for everyone to participate, and > would play the same role as lab meetings in everyday research, but > taking into consideration the fact that we're an open, international > collaboration. > > Those lab meetings would be held with hangouts on-air, and thus open > for anyone who wants to watch and join, and kept on-record afterwards. > > The plan would be to hold them for ~60-90 minutes, to make regular > progress on design decisions that impact the project at large. > Impromptu hangouts as required by the everyday workflow will continue > to happen, and we'll do our best to also record those in public > format. > > If you like the idea, I'd like to propose Thursdays at 10am US Pacific > time, i.e. UTC-7 hours right now (PDT). That's a good time for all > the folks here in California while still being reasonable in Europe. > I know we can't find a time that will work across all of Earth, but at > least that probably covers reasonably well our current core team and > lots of others. > > How does this sound to you all? Would the time work for a reasonable > chunk of our active developers? Note that I am NOT asking only of the > 'core' github committers, but of anyone who is putting lots of time > into IPython work and is interested in joining these discussions. > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev I think it is a great idea! I will try to participate in the meeting as much as I can. Cheers. Dami?n. From massimodisasha at gmail.com Sun May 19 13:15:14 2013 From: massimodisasha at gmail.com (epi) Date: Sun, 19 May 2013 13:15:14 -0400 Subject: [IPython-dev] IPython "lab meetings" on g+ hangouts on air In-Reply-To: <5198F3A0.7080502@gmail.com> References: <5198F3A0.7080502@gmail.com> Message-ID: I love this, i enjoyed the first hangout i'll follow you guys :) thanks! Massimo. Il giorno 19/mag/2013, alle ore 11:45, Dami?n Avila ha scritto: > El 16/05/13 22:06, Fernando Perez escribi?: >> Hi folks, >> >> as Brian just mentioned, we had a google hangout discussion today, >> that arose impromptu from having a chat room discussion where it was >> obvious we needed more bandwidth than just typing can provide. >> >> Today (perhaps because of all the changes Google made yesterday, who >> knows), g+ was a bit glitchy, and we were unable to make the hangout >> on-air, so it ended up not being recorded. But in general we want all >> these discussions to be public, for example here's our previous one: >> >> http://www.youtube.com/watch?v=Yb35M8cW7o4 >> >> While I think it's great to jump in on video conversations like this >> as-needed from the dev room or a github issue/PR discussion, we've >> also been thinking about having a more regular 'lab meeting' style >> discussion that is scheduled at a fixed time. >> >> This would give a predictable time for everyone to participate, and >> would play the same role as lab meetings in everyday research, but >> taking into consideration the fact that we're an open, international >> collaboration. >> >> Those lab meetings would be held with hangouts on-air, and thus open >> for anyone who wants to watch and join, and kept on-record afterwards. >> >> The plan would be to hold them for ~60-90 minutes, to make regular >> progress on design decisions that impact the project at large. >> Impromptu hangouts as required by the everyday workflow will continue >> to happen, and we'll do our best to also record those in public >> format. >> >> If you like the idea, I'd like to propose Thursdays at 10am US Pacific >> time, i.e. UTC-7 hours right now (PDT). That's a good time for all >> the folks here in California while still being reasonable in Europe. >> I know we can't find a time that will work across all of Earth, but at >> least that probably covers reasonably well our current core team and >> lots of others. >> >> How does this sound to you all? Would the time work for a reasonable >> chunk of our active developers? Note that I am NOT asking only of the >> 'core' github committers, but of anyone who is putting lots of time >> into IPython work and is interested in joining these discussions. >> >> Cheers, >> >> f >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev > > > I think it is a great idea! I will try to participate in the meeting as > much as I can. > > Cheers. > > Dami?n. > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From ccordoba12 at gmail.com Sun May 19 13:19:30 2013 From: ccordoba12 at gmail.com (=?UTF-8?B?Q2FybG9zIEPDs3Jkb2Jh?=) Date: Sun, 19 May 2013 12:19:30 -0500 Subject: [IPython-dev] Flat is better than nested In-Reply-To: References: <519658A3.3000007@gmail.com> <51968A5A.6090500@gmail.com> Message-ID: <519909A2.6070508@gmail.com> Hi Fernando, I'll talk to Pierre and the other members of our team to see if we can come up with a sensible PR. Just adding _all__ would be a real gain for us. Cheers, Carlos El 17/05/13 17:16, Fernando Perez escribi?: > Hi Carlos, > > On Fri, May 17, 2013 at 12:51 PM, Carlos C?rdoba wrote: >> Ok, thanks for the answer, that makes more sense (although I don't agree >> with making such changes so far ahead in time). >> >> But what about my proposal of an __all__ attribute? That would make >> IPython consumer lives much easier and pleasant. > Yes, that's something we actually need to work on and that's been on > my radar for a long time: exposing for some of the main packages a bit > of interface in the main __init__ file. > > BTW, it's worth noting that the Qt code in IPython is very much in > need of engineering love... You guys and Enthought are the main > stakeholders in there, but there's not a ton of activity. > > The reality is that it's a bit of a liability to have a complex code > like that where the most active core IPython team isn't really using > it. So if you see architectural cleanups that you can make, by all > means dig into the code. I'm sure things will be better for everyone > involved if that part of the code gains some more active > maintainership. > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From asmeurer at gmail.com Sun May 19 13:29:55 2013 From: asmeurer at gmail.com (Aaron Meurer) Date: Sun, 19 May 2013 11:29:55 -0600 Subject: [IPython-dev] Flat is better than nested In-Reply-To: <519909A2.6070508@gmail.com> References: <519658A3.3000007@gmail.com> <51968A5A.6090500@gmail.com> <519909A2.6070508@gmail.com> Message-ID: One thing you can try to make __all__ a little more manageable is to create a decorator @importable that automatically adds a class or function to __all__. See for example https://github.com/mattpap/sympy/commit/aa37bc12f43d603a4c17e6765a9706d92b95526f . Aaron Meurer On Sun, May 19, 2013 at 11:19 AM, Carlos C?rdoba wrote: > Hi Fernando, > > I'll talk to Pierre and the other members of our team to see if we can > come up with a sensible PR. Just adding _all__ would be a real gain for us. > > Cheers, > Carlos > > El 17/05/13 17:16, Fernando Perez escribi?: > > Hi Carlos, > > > > On Fri, May 17, 2013 at 12:51 PM, Carlos C?rdoba > wrote: > >> Ok, thanks for the answer, that makes more sense (although I don't agree > >> with making such changes so far ahead in time). > >> > >> But what about my proposal of an __all__ attribute? That would make > >> IPython consumer lives much easier and pleasant. > > Yes, that's something we actually need to work on and that's been on > > my radar for a long time: exposing for some of the main packages a bit > > of interface in the main __init__ file. > > > > BTW, it's worth noting that the Qt code in IPython is very much in > > need of engineering love... You guys and Enthought are the main > > stakeholders in there, but there's not a ton of activity. > > > > The reality is that it's a bit of a liability to have a complex code > > like that where the most active core IPython team isn't really using > > it. So if you see architectural cleanups that you can make, by all > > means dig into the code. I'm sure things will be better for everyone > > involved if that part of the code gains some more active > > maintainership. > > > > Cheers, > > > > f > > _______________________________________________ > > IPython-dev mailing list > > IPython-dev at scipy.org > > http://mail.scipy.org/mailman/listinfo/ipython-dev > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Sun May 19 16:34:48 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 19 May 2013 13:34:48 -0700 Subject: [IPython-dev] IPython "lab meetings" on g+ hangouts on air In-Reply-To: References: <5198F3A0.7080502@gmail.com> Message-ID: Does anyone have any good suggestions on a tool for collaborative note-taking, so that we can leave some public summary/record of these meetings with minimal fuss? A google doc is a bit of a hassle for this, I think, esp. since we want something to produce plaintext. Etherpad is ugly as sin, but it's fairly functional and I know the software carpentry folks use it very effectively. Unless someone knows of a better solution, I guess we could just use etherpad. I'm not thinking of anything very involved, simply a document for each meeting where everyone can type, and that we can copy/paste to the mailing list at the end as a quick and dirty summary. I know we won't have time for formal minutes, so these docs could end up being little more than a link to the URL for the youtube video. But if there's anything worth summarizing in text, I think it will be useful to have a note-taking app open with everyone involved. Note that this is different from chat: g+ has an open chat channel, but that's a sequence of messages. What I'm thinking of is a proper *editor* where we can leave a text file at the end; a chat app won't work for this. I want this to be very lightweight and low-friction, so hopefully a simple g+ hangout plus a common text file is all we'll need. I propose we go with the ugly etherpad unless anyone has a better solution (but I'm happy to use something else if there is such a thing). Cheers, f On Sun, May 19, 2013 at 10:15 AM, epi wrote: > I love this, > i enjoyed the first hangout > i'll follow you guys :) > > thanks! > > Massimo. > > Il giorno 19/mag/2013, alle ore 11:45, Dami?n Avila ha scritto: > >> El 16/05/13 22:06, Fernando Perez escribi?: >>> Hi folks, >>> >>> as Brian just mentioned, we had a google hangout discussion today, >>> that arose impromptu from having a chat room discussion where it was >>> obvious we needed more bandwidth than just typing can provide. >>> >>> Today (perhaps because of all the changes Google made yesterday, who >>> knows), g+ was a bit glitchy, and we were unable to make the hangout >>> on-air, so it ended up not being recorded. But in general we want all >>> these discussions to be public, for example here's our previous one: >>> >>> http://www.youtube.com/watch?v=Yb35M8cW7o4 >>> >>> While I think it's great to jump in on video conversations like this >>> as-needed from the dev room or a github issue/PR discussion, we've >>> also been thinking about having a more regular 'lab meeting' style >>> discussion that is scheduled at a fixed time. >>> >>> This would give a predictable time for everyone to participate, and >>> would play the same role as lab meetings in everyday research, but >>> taking into consideration the fact that we're an open, international >>> collaboration. >>> >>> Those lab meetings would be held with hangouts on-air, and thus open >>> for anyone who wants to watch and join, and kept on-record afterwards. >>> >>> The plan would be to hold them for ~60-90 minutes, to make regular >>> progress on design decisions that impact the project at large. >>> Impromptu hangouts as required by the everyday workflow will continue >>> to happen, and we'll do our best to also record those in public >>> format. >>> >>> If you like the idea, I'd like to propose Thursdays at 10am US Pacific >>> time, i.e. UTC-7 hours right now (PDT). That's a good time for all >>> the folks here in California while still being reasonable in Europe. >>> I know we can't find a time that will work across all of Earth, but at >>> least that probably covers reasonably well our current core team and >>> lots of others. >>> >>> How does this sound to you all? Would the time work for a reasonable >>> chunk of our active developers? Note that I am NOT asking only of the >>> 'core' github committers, but of anyone who is putting lots of time >>> into IPython work and is interested in joining these discussions. >>> >>> Cheers, >>> >>> f >>> _______________________________________________ >>> IPython-dev mailing list >>> IPython-dev at scipy.org >>> http://mail.scipy.org/mailman/listinfo/ipython-dev >> >> >> I think it is a great idea! I will try to participate in the meeting as >> much as I can. >> >> Cheers. >> >> Dami?n. >> >> >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From fperez.net at gmail.com Sun May 19 16:39:48 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 19 May 2013 13:39:48 -0700 Subject: [IPython-dev] Flat is better than nested In-Reply-To: References: <519658A3.3000007@gmail.com> <51968A5A.6090500@gmail.com> <519909A2.6070508@gmail.com> Message-ID: mmh, that actually looks very cool. I like how it also makes reading the source very clear and simple. I only have a couple of questions: - did you ever measure the impact on import times? IPython is kind of a monster already, and I always worry about making import times worse. - for nested packages, I guess you still need to collect from subpackages in `__init__`. But with this approach, it seems like one could then in the proper container `__init__` do a few `from subpak1 import *; from subpak2 import *;`, etc. This would pull the `__all__` lists from all these guys. I also like that, by marking things explicitly in the source at the location of definition, it will encourage people to do an even better job at documenting those functions; anything marked @public should really have a good docstring... Thanks! f On Sun, May 19, 2013 at 10:29 AM, Aaron Meurer wrote: > One thing you can try to make __all__ a little more manageable is to create > a decorator @importable that automatically adds a class or function to > __all__. > > See for example > https://github.com/mattpap/sympy/commit/aa37bc12f43d603a4c17e6765a9706d92b95526f. > > Aaron Meurer > > > On Sun, May 19, 2013 at 11:19 AM, Carlos C?rdoba > wrote: >> >> Hi Fernando, >> >> I'll talk to Pierre and the other members of our team to see if we can >> come up with a sensible PR. Just adding _all__ would be a real gain for >> us. >> >> Cheers, >> Carlos >> >> El 17/05/13 17:16, Fernando Perez escribi?: >> > Hi Carlos, >> > >> > On Fri, May 17, 2013 at 12:51 PM, Carlos C?rdoba >> > wrote: >> >> Ok, thanks for the answer, that makes more sense (although I don't >> >> agree >> >> with making such changes so far ahead in time). >> >> >> >> But what about my proposal of an __all__ attribute? That would make >> >> IPython consumer lives much easier and pleasant. >> > Yes, that's something we actually need to work on and that's been on >> > my radar for a long time: exposing for some of the main packages a bit >> > of interface in the main __init__ file. >> > >> > BTW, it's worth noting that the Qt code in IPython is very much in >> > need of engineering love... You guys and Enthought are the main >> > stakeholders in there, but there's not a ton of activity. >> > >> > The reality is that it's a bit of a liability to have a complex code >> > like that where the most active core IPython team isn't really using >> > it. So if you see architectural cleanups that you can make, by all >> > means dig into the code. I'm sure things will be better for everyone >> > involved if that part of the code gains some more active >> > maintainership. >> > >> > Cheers, >> > >> > f >> > _______________________________________________ >> > IPython-dev mailing list >> > IPython-dev at scipy.org >> > http://mail.scipy.org/mailman/listinfo/ipython-dev >> >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev > > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > From massimodisasha at gmail.com Sun May 19 16:44:38 2013 From: massimodisasha at gmail.com (epi) Date: Sun, 19 May 2013 16:44:38 -0400 Subject: [IPython-dev] IPython "lab meetings" on g+ hangouts on air In-Reply-To: References: <5198F3A0.7080502@gmail.com> Message-ID: <74476C79-C9EA-4735-8E71-F34186E79013@gmail.com> At my university we are successful using hackpad [1] [1] https://hackpad.com/ Il giorno 19/mag/2013, alle ore 16:34, Fernando Perez ha scritto: > Does anyone have any good suggestions on a tool for collaborative > note-taking, so that we can leave some public summary/record of these > meetings with minimal fuss? > > A google doc is a bit of a hassle for this, I think, esp. since we > want something to produce plaintext. > > Etherpad is ugly as sin, but it's fairly functional and I know the > software carpentry folks use it very effectively. > > Unless someone knows of a better solution, I guess we could just use > etherpad. I'm not thinking of anything very involved, simply a > document for each meeting where everyone can type, and that we can > copy/paste to the mailing list at the end as a quick and dirty > summary. > > I know we won't have time for formal minutes, so these docs could end > up being little more than a link to the URL for the youtube video. > But if there's anything worth summarizing in text, I think it will be > useful to have a note-taking app open with everyone involved. > > Note that this is different from chat: g+ has an open chat channel, > but that's a sequence of messages. What I'm thinking of is a proper > *editor* where we can leave a text file at the end; a chat app won't > work for this. > > I want this to be very lightweight and low-friction, so hopefully a > simple g+ hangout plus a common text file is all we'll need. > > I propose we go with the ugly etherpad unless anyone has a better > solution (but I'm happy to use something else if there is such a > thing). > > Cheers, > > f > > On Sun, May 19, 2013 at 10:15 AM, epi wrote: >> I love this, >> i enjoyed the first hangout >> i'll follow you guys :) >> >> thanks! >> >> Massimo. >> >> Il giorno 19/mag/2013, alle ore 11:45, Dami?n Avila ha scritto: >> >>> El 16/05/13 22:06, Fernando Perez escribi?: >>>> Hi folks, >>>> >>>> as Brian just mentioned, we had a google hangout discussion today, >>>> that arose impromptu from having a chat room discussion where it was >>>> obvious we needed more bandwidth than just typing can provide. >>>> >>>> Today (perhaps because of all the changes Google made yesterday, who >>>> knows), g+ was a bit glitchy, and we were unable to make the hangout >>>> on-air, so it ended up not being recorded. But in general we want all >>>> these discussions to be public, for example here's our previous one: >>>> >>>> http://www.youtube.com/watch?v=Yb35M8cW7o4 >>>> >>>> While I think it's great to jump in on video conversations like this >>>> as-needed from the dev room or a github issue/PR discussion, we've >>>> also been thinking about having a more regular 'lab meeting' style >>>> discussion that is scheduled at a fixed time. >>>> >>>> This would give a predictable time for everyone to participate, and >>>> would play the same role as lab meetings in everyday research, but >>>> taking into consideration the fact that we're an open, international >>>> collaboration. >>>> >>>> Those lab meetings would be held with hangouts on-air, and thus open >>>> for anyone who wants to watch and join, and kept on-record afterwards. >>>> >>>> The plan would be to hold them for ~60-90 minutes, to make regular >>>> progress on design decisions that impact the project at large. >>>> Impromptu hangouts as required by the everyday workflow will continue >>>> to happen, and we'll do our best to also record those in public >>>> format. >>>> >>>> If you like the idea, I'd like to propose Thursdays at 10am US Pacific >>>> time, i.e. UTC-7 hours right now (PDT). That's a good time for all >>>> the folks here in California while still being reasonable in Europe. >>>> I know we can't find a time that will work across all of Earth, but at >>>> least that probably covers reasonably well our current core team and >>>> lots of others. >>>> >>>> How does this sound to you all? Would the time work for a reasonable >>>> chunk of our active developers? Note that I am NOT asking only of the >>>> 'core' github committers, but of anyone who is putting lots of time >>>> into IPython work and is interested in joining these discussions. >>>> >>>> Cheers, >>>> >>>> f >>>> _______________________________________________ >>>> IPython-dev mailing list >>>> IPython-dev at scipy.org >>>> http://mail.scipy.org/mailman/listinfo/ipython-dev >>> >>> >>> I think it is a great idea! I will try to participate in the meeting as >>> much as I can. >>> >>> Cheers. >>> >>> Dami?n. >>> >>> >>> _______________________________________________ >>> 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 Sun May 19 16:50:30 2013 From: asmeurer at gmail.com (Aaron Meurer) Date: Sun, 19 May 2013 14:50:30 -0600 Subject: [IPython-dev] Flat is better than nested In-Reply-To: References: <519658A3.3000007@gmail.com> <51968A5A.6090500@gmail.com> <519909A2.6070508@gmail.com> Message-ID: Actually, that commit just lives in one of Mateusz's development branches, so we haven't deployed it yet. I didn't time it either. I suppose any kind of function decoration will make import times a little slower, though whether or not it will be significant is unclear. I'm not entirely clear on the difference, but it seems that the common idiom for __init__.py is something like __all__ = [] import submodule __all__.extend(submodule.__all__) Adding new submodules is a lot less common than adding new functions or classes, so doing things manually there should not be too bad. This also lets you finely control whether you need to do "from IPython import something" or "from IPython.submodule import something" or "from IPython.submodule.submodule import something" for each submodule. Aaron Meurer On Sun, May 19, 2013 at 2:39 PM, Fernando Perez wrote: > mmh, that actually looks very cool. I like how it also makes reading > the source very clear and simple. I only have a couple of questions: > > - did you ever measure the impact on import times? IPython is kind of > a monster already, and I always worry about making import times worse. > > - for nested packages, I guess you still need to collect from > subpackages in `__init__`. But with this approach, it seems like one > could then in the proper container `__init__` do a few `from subpak1 > import *; from subpak2 import *;`, etc. This would pull the `__all__` > lists from all these guys. > > I also like that, by marking things explicitly in the source at the > location of definition, it will encourage people to do an even better > job at documenting those functions; anything marked @public should > really have a good docstring... > > Thanks! > > f > > On Sun, May 19, 2013 at 10:29 AM, Aaron Meurer wrote: >> One thing you can try to make __all__ a little more manageable is to create >> a decorator @importable that automatically adds a class or function to >> __all__. >> >> See for example >> https://github.com/mattpap/sympy/commit/aa37bc12f43d603a4c17e6765a9706d92b95526f. >> >> Aaron Meurer >> >> >> On Sun, May 19, 2013 at 11:19 AM, Carlos C?rdoba >> wrote: >>> >>> Hi Fernando, >>> >>> I'll talk to Pierre and the other members of our team to see if we can >>> come up with a sensible PR. Just adding _all__ would be a real gain for >>> us. >>> >>> Cheers, >>> Carlos >>> >>> El 17/05/13 17:16, Fernando Perez escribi?: >>> > Hi Carlos, >>> > >>> > On Fri, May 17, 2013 at 12:51 PM, Carlos C?rdoba >>> > wrote: >>> >> Ok, thanks for the answer, that makes more sense (although I don't >>> >> agree >>> >> with making such changes so far ahead in time). >>> >> >>> >> But what about my proposal of an __all__ attribute? That would make >>> >> IPython consumer lives much easier and pleasant. >>> > Yes, that's something we actually need to work on and that's been on >>> > my radar for a long time: exposing for some of the main packages a bit >>> > of interface in the main __init__ file. >>> > >>> > BTW, it's worth noting that the Qt code in IPython is very much in >>> > need of engineering love... You guys and Enthought are the main >>> > stakeholders in there, but there's not a ton of activity. >>> > >>> > The reality is that it's a bit of a liability to have a complex code >>> > like that where the most active core IPython team isn't really using >>> > it. So if you see architectural cleanups that you can make, by all >>> > means dig into the code. I'm sure things will be better for everyone >>> > involved if that part of the code gains some more active >>> > maintainership. >>> > >>> > Cheers, >>> > >>> > f >>> > _______________________________________________ >>> > IPython-dev mailing list >>> > IPython-dev at scipy.org >>> > http://mail.scipy.org/mailman/listinfo/ipython-dev >>> >>> _______________________________________________ >>> IPython-dev mailing list >>> IPython-dev at scipy.org >>> http://mail.scipy.org/mailman/listinfo/ipython-dev >> >> >> >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev >> > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From asmeurer at gmail.com Sun May 19 16:59:09 2013 From: asmeurer at gmail.com (Aaron Meurer) Date: Sun, 19 May 2013 14:59:09 -0600 Subject: [IPython-dev] IPython "lab meetings" on g+ hangouts on air In-Reply-To: References: <5198F3A0.7080502@gmail.com> Message-ID: On Sun, May 19, 2013 at 2:34 PM, Fernando Perez wrote: > Does anyone have any good suggestions on a tool for collaborative > note-taking, so that we can leave some public summary/record of these > meetings with minimal fuss? > > A google doc is a bit of a hassle for this, I think, esp. since we > want something to produce plaintext. Just curious, why does it have to be plain text? I've found Google Docs features like tables and highlighting are quite useful in sometimes. Maybe you could find a collaborative editing tool that uses Markdown. Then you could just post the result on the wiki. Ace seems pretty good. Maybe one of these (http://ace.ajax.org/#nav=production) can do the trick. Aaron Meurer > > Etherpad is ugly as sin, but it's fairly functional and I know the > software carpentry folks use it very effectively. > > Unless someone knows of a better solution, I guess we could just use > etherpad. I'm not thinking of anything very involved, simply a > document for each meeting where everyone can type, and that we can > copy/paste to the mailing list at the end as a quick and dirty > summary. > > I know we won't have time for formal minutes, so these docs could end > up being little more than a link to the URL for the youtube video. > But if there's anything worth summarizing in text, I think it will be > useful to have a note-taking app open with everyone involved. > > Note that this is different from chat: g+ has an open chat channel, > but that's a sequence of messages. What I'm thinking of is a proper > *editor* where we can leave a text file at the end; a chat app won't > work for this. > > I want this to be very lightweight and low-friction, so hopefully a > simple g+ hangout plus a common text file is all we'll need. > > I propose we go with the ugly etherpad unless anyone has a better > solution (but I'm happy to use something else if there is such a > thing). > > Cheers, > > f > > On Sun, May 19, 2013 at 10:15 AM, epi wrote: >> I love this, >> i enjoyed the first hangout >> i'll follow you guys :) >> >> thanks! >> >> Massimo. >> >> Il giorno 19/mag/2013, alle ore 11:45, Dami?n Avila ha scritto: >> >>> El 16/05/13 22:06, Fernando Perez escribi?: >>>> Hi folks, >>>> >>>> as Brian just mentioned, we had a google hangout discussion today, >>>> that arose impromptu from having a chat room discussion where it was >>>> obvious we needed more bandwidth than just typing can provide. >>>> >>>> Today (perhaps because of all the changes Google made yesterday, who >>>> knows), g+ was a bit glitchy, and we were unable to make the hangout >>>> on-air, so it ended up not being recorded. But in general we want all >>>> these discussions to be public, for example here's our previous one: >>>> >>>> http://www.youtube.com/watch?v=Yb35M8cW7o4 >>>> >>>> While I think it's great to jump in on video conversations like this >>>> as-needed from the dev room or a github issue/PR discussion, we've >>>> also been thinking about having a more regular 'lab meeting' style >>>> discussion that is scheduled at a fixed time. >>>> >>>> This would give a predictable time for everyone to participate, and >>>> would play the same role as lab meetings in everyday research, but >>>> taking into consideration the fact that we're an open, international >>>> collaboration. >>>> >>>> Those lab meetings would be held with hangouts on-air, and thus open >>>> for anyone who wants to watch and join, and kept on-record afterwards. >>>> >>>> The plan would be to hold them for ~60-90 minutes, to make regular >>>> progress on design decisions that impact the project at large. >>>> Impromptu hangouts as required by the everyday workflow will continue >>>> to happen, and we'll do our best to also record those in public >>>> format. >>>> >>>> If you like the idea, I'd like to propose Thursdays at 10am US Pacific >>>> time, i.e. UTC-7 hours right now (PDT). That's a good time for all >>>> the folks here in California while still being reasonable in Europe. >>>> I know we can't find a time that will work across all of Earth, but at >>>> least that probably covers reasonably well our current core team and >>>> lots of others. >>>> >>>> How does this sound to you all? Would the time work for a reasonable >>>> chunk of our active developers? Note that I am NOT asking only of the >>>> 'core' github committers, but of anyone who is putting lots of time >>>> into IPython work and is interested in joining these discussions. >>>> >>>> Cheers, >>>> >>>> f >>>> _______________________________________________ >>>> IPython-dev mailing list >>>> IPython-dev at scipy.org >>>> http://mail.scipy.org/mailman/listinfo/ipython-dev >>> >>> >>> I think it is a great idea! I will try to participate in the meeting as >>> much as I can. >>> >>> Cheers. >>> >>> Dami?n. >>> >>> >>> _______________________________________________ >>> 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 From mattpap at gmail.com Sun May 19 19:21:44 2013 From: mattpap at gmail.com (Mateusz Paprocki) Date: Mon, 20 May 2013 01:21:44 +0200 Subject: [IPython-dev] Flat is better than nested In-Reply-To: References: <519658A3.3000007@gmail.com> <51968A5A.6090500@gmail.com> <519909A2.6070508@gmail.com> Message-ID: Hi, On 19 May 2013 22:39, Fernando Perez wrote: > mmh, that actually looks very cool. I like how it also makes reading > the source very clear and simple. I only have a couple of questions: > > - did you ever measure the impact on import times? IPython is kind of > a monster already, and I always worry about making import times worse. > Assuming that decorator application has the same cost as function call, then: In [1]: from sympy.utilities.decorator import public In [2]: def f(): pass In [3]: %timeit public(f); 1000000 loops, best of 3: 355 ns per loop In [4]: class F(object): pass In [5]: %timeit public(F); 1000000 loops, best of 3: 660 ns per loop (on 3.4 GHz i7). For ~100 @public cases (in sympy.polys) our bin/test_import tool confirms that there is no visible speed impact. Current implementation is rather rough, so there may be a way to improve speed (I didn't explore other possible approaches, e.g. using inspect). - for nested packages, I guess you still need to collect from > subpackages in `__init__`. But with this approach, it seems like one > could then in the proper container `__init__` do a few `from subpak1 > import *; from subpak2 import *;`, etc. This would pull the `__all__` > lists from all these guys. > > I also like that, by marking things explicitly in the source at the > location of definition, it will encourage people to do an even better > job at documenting those functions; anything marked @public should > really have a good docstring... > > Thanks! > > f > Mateusz > > On Sun, May 19, 2013 at 10:29 AM, Aaron Meurer wrote: > > One thing you can try to make __all__ a little more manageable is to > create > > a decorator @importable that automatically adds a class or function to > > __all__. > > > > See for example > > > https://github.com/mattpap/sympy/commit/aa37bc12f43d603a4c17e6765a9706d92b95526f > . > > > > Aaron Meurer > > > > > > On Sun, May 19, 2013 at 11:19 AM, Carlos C?rdoba > > wrote: > >> > >> Hi Fernando, > >> > >> I'll talk to Pierre and the other members of our team to see if we can > >> come up with a sensible PR. Just adding _all__ would be a real gain for > >> us. > >> > >> Cheers, > >> Carlos > >> > >> El 17/05/13 17:16, Fernando Perez escribi?: > >> > Hi Carlos, > >> > > >> > On Fri, May 17, 2013 at 12:51 PM, Carlos C?rdoba < > ccordoba12 at gmail.com> > >> > wrote: > >> >> Ok, thanks for the answer, that makes more sense (although I don't > >> >> agree > >> >> with making such changes so far ahead in time). > >> >> > >> >> But what about my proposal of an __all__ attribute? That would make > >> >> IPython consumer lives much easier and pleasant. > >> > Yes, that's something we actually need to work on and that's been on > >> > my radar for a long time: exposing for some of the main packages a bit > >> > of interface in the main __init__ file. > >> > > >> > BTW, it's worth noting that the Qt code in IPython is very much in > >> > need of engineering love... You guys and Enthought are the main > >> > stakeholders in there, but there's not a ton of activity. > >> > > >> > The reality is that it's a bit of a liability to have a complex code > >> > like that where the most active core IPython team isn't really using > >> > it. So if you see architectural cleanups that you can make, by all > >> > means dig into the code. I'm sure things will be better for everyone > >> > involved if that part of the code gains some more active > >> > maintainership. > >> > > >> > Cheers, > >> > > >> > f > >> > _______________________________________________ > >> > IPython-dev mailing list > >> > IPython-dev at scipy.org > >> > http://mail.scipy.org/mailman/listinfo/ipython-dev > >> > >> _______________________________________________ > >> IPython-dev mailing list > >> IPython-dev at scipy.org > >> http://mail.scipy.org/mailman/listinfo/ipython-dev > > > > > > > > _______________________________________________ > > 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 carl.input at gmail.com Mon May 20 11:56:12 2013 From: carl.input at gmail.com (Carl Smith) Date: Mon, 20 May 2013 16:56:12 +0100 Subject: [IPython-dev] IPython "lab meetings" on g+ hangouts on air In-Reply-To: References: <5198F3A0.7080502@gmail.com> Message-ID: There's prose.io, which edits gh files with support for using Markdown. I have only played with it, so can't recommend it, but it may work well for this. On May 19, 2013 9:59 PM, "Aaron Meurer" wrote: > On Sun, May 19, 2013 at 2:34 PM, Fernando Perez > wrote: > > Does anyone have any good suggestions on a tool for collaborative > > note-taking, so that we can leave some public summary/record of these > > meetings with minimal fuss? > > > > A google doc is a bit of a hassle for this, I think, esp. since we > > want something to produce plaintext. > > Just curious, why does it have to be plain text? I've found Google > Docs features like tables and highlighting are quite useful in > sometimes. > > Maybe you could find a collaborative editing tool that uses Markdown. > Then you could just post the result on the wiki. > > Ace seems pretty good. Maybe one of these > (http://ace.ajax.org/#nav=production) can do the trick. > > Aaron Meurer > > > > > Etherpad is ugly as sin, but it's fairly functional and I know the > > software carpentry folks use it very effectively. > > > > Unless someone knows of a better solution, I guess we could just use > > etherpad. I'm not thinking of anything very involved, simply a > > document for each meeting where everyone can type, and that we can > > copy/paste to the mailing list at the end as a quick and dirty > > summary. > > > > I know we won't have time for formal minutes, so these docs could end > > up being little more than a link to the URL for the youtube video. > > But if there's anything worth summarizing in text, I think it will be > > useful to have a note-taking app open with everyone involved. > > > > Note that this is different from chat: g+ has an open chat channel, > > but that's a sequence of messages. What I'm thinking of is a proper > > *editor* where we can leave a text file at the end; a chat app won't > > work for this. > > > > I want this to be very lightweight and low-friction, so hopefully a > > simple g+ hangout plus a common text file is all we'll need. > > > > I propose we go with the ugly etherpad unless anyone has a better > > solution (but I'm happy to use something else if there is such a > > thing). > > > > Cheers, > > > > f > > > > On Sun, May 19, 2013 at 10:15 AM, epi wrote: > >> I love this, > >> i enjoyed the first hangout > >> i'll follow you guys :) > >> > >> thanks! > >> > >> Massimo. > >> > >> Il giorno 19/mag/2013, alle ore 11:45, Dami?n Avila < > damianavila at gmail.com> ha scritto: > >> > >>> El 16/05/13 22:06, Fernando Perez escribi?: > >>>> Hi folks, > >>>> > >>>> as Brian just mentioned, we had a google hangout discussion today, > >>>> that arose impromptu from having a chat room discussion where it was > >>>> obvious we needed more bandwidth than just typing can provide. > >>>> > >>>> Today (perhaps because of all the changes Google made yesterday, who > >>>> knows), g+ was a bit glitchy, and we were unable to make the hangout > >>>> on-air, so it ended up not being recorded. But in general we want all > >>>> these discussions to be public, for example here's our previous one: > >>>> > >>>> http://www.youtube.com/watch?v=Yb35M8cW7o4 > >>>> > >>>> While I think it's great to jump in on video conversations like this > >>>> as-needed from the dev room or a github issue/PR discussion, we've > >>>> also been thinking about having a more regular 'lab meeting' style > >>>> discussion that is scheduled at a fixed time. > >>>> > >>>> This would give a predictable time for everyone to participate, and > >>>> would play the same role as lab meetings in everyday research, but > >>>> taking into consideration the fact that we're an open, international > >>>> collaboration. > >>>> > >>>> Those lab meetings would be held with hangouts on-air, and thus open > >>>> for anyone who wants to watch and join, and kept on-record afterwards. > >>>> > >>>> The plan would be to hold them for ~60-90 minutes, to make regular > >>>> progress on design decisions that impact the project at large. > >>>> Impromptu hangouts as required by the everyday workflow will continue > >>>> to happen, and we'll do our best to also record those in public > >>>> format. > >>>> > >>>> If you like the idea, I'd like to propose Thursdays at 10am US Pacific > >>>> time, i.e. UTC-7 hours right now (PDT). That's a good time for all > >>>> the folks here in California while still being reasonable in Europe. > >>>> I know we can't find a time that will work across all of Earth, but at > >>>> least that probably covers reasonably well our current core team and > >>>> lots of others. > >>>> > >>>> How does this sound to you all? Would the time work for a reasonable > >>>> chunk of our active developers? Note that I am NOT asking only of the > >>>> 'core' github committers, but of anyone who is putting lots of time > >>>> into IPython work and is interested in joining these discussions. > >>>> > >>>> Cheers, > >>>> > >>>> f > >>>> _______________________________________________ > >>>> IPython-dev mailing list > >>>> IPython-dev at scipy.org > >>>> http://mail.scipy.org/mailman/listinfo/ipython-dev > >>> > >>> > >>> I think it is a great idea! I will try to participate in the meeting as > >>> much as I can. > >>> > >>> Cheers. > >>> > >>> Dami?n. > >>> > >>> > >>> _______________________________________________ > >>> 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 wking at tremily.us Mon May 20 12:26:54 2013 From: wking at tremily.us (W. Trevor King) Date: Mon, 20 May 2013 12:26:54 -0400 Subject: [IPython-dev] Flat is better than nested In-Reply-To: <519658A3.3000007@gmail.com> References: <519658A3.3000007@gmail.com> Message-ID: <20130520162654.GG23990@odin.tremily.us> On Fri, May 17, 2013 at 11:19:47AM -0500, Carlos C?rdoba wrote: > For us in Spyder it would be better to be able to import things like > RichIPythonWidget as > > from IPython.frontend.qt import RichIPythonWidget > > instead of > > from IPython.qt.console.rich_ipython_widget import RichIPythonWidget > > because even without "frontend" there are four levels of nested modules > to reach one of the most essential pieces of that frontend. > > So why not add an __all__ attribute to each frontend instead? I've just been skimming this thread, but I'd caution against namespace squashing for scripting things (not very DRY). If users are calling RichIPythonWidget from their IPython session, then providing a shortcut namespace is fine (? la Matplotlib's pylab [1]), but having multiple script-oriented locations is just confusing. In this case, it might be best to have: from ._rich_ipython_widget import RichIPythonWidget in IPython.qt.console (or IPython.qt?), which all consumers have to use instead of importing the (now private) rich_ipython_widget module directly. Cheers, Trevor [1]: http://matplotlib.org/faq/usage_faq.html#matplotlib-pylab-and-pyplot-how-are-they-related -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From ccordoba12 at gmail.com Mon May 20 13:00:04 2013 From: ccordoba12 at gmail.com (=?UTF-8?B?Q2FybG9zIEPDs3Jkb2Jh?=) Date: Mon, 20 May 2013 12:00:04 -0500 Subject: [IPython-dev] Flat is better than nested In-Reply-To: <20130520162654.GG23990@odin.tremily.us> References: <519658A3.3000007@gmail.com> <20130520162654.GG23990@odin.tremily.us> Message-ID: <519A5694.8030605@gmail.com> Hi, @Aaron: A @public decorator seems really cool, it makes look code really neat! I'll investigate how to include it in our PR. @Trevor: I think you are missing the point: these changes are not meant for regular users but for projects that are using IPython as a library. The idea is to put in __all__ the main pieces of qtconsole (not only RichIPythonWidget, but also QtKernelManager, QtKernelClient, etc) to tell those projects what elements they need to rely on to build a customized frontend. Cheers, Carlos El 20/05/13 11:26, W. Trevor King escribi?: > On Fri, May 17, 2013 at 11:19:47AM -0500, Carlos C?rdoba wrote: >> For us in Spyder it would be better to be able to import things like >> RichIPythonWidget as >> >> from IPython.frontend.qt import RichIPythonWidget >> >> instead of >> >> from IPython.qt.console.rich_ipython_widget import RichIPythonWidget >> >> because even without "frontend" there are four levels of nested modules >> to reach one of the most essential pieces of that frontend. >> >> So why not add an __all__ attribute to each frontend instead? > I've just been skimming this thread, but I'd caution against namespace > squashing for scripting things (not very DRY). If users are calling > RichIPythonWidget from their IPython session, then providing a > shortcut namespace is fine (? la Matplotlib's pylab [1]), but having > multiple script-oriented locations is just confusing. In this case, > it might be best to have: > > from ._rich_ipython_widget import RichIPythonWidget > > in IPython.qt.console (or IPython.qt?), which all consumers have to > use instead of importing the (now private) rich_ipython_widget module > directly. > > Cheers, > Trevor > > [1]: http://matplotlib.org/faq/usage_faq.html#matplotlib-pylab-and-pyplot-how-are-they-related > > > > _______________________________________________ > 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 Mon May 20 13:11:31 2013 From: asmeurer at gmail.com (Aaron Meurer) Date: Mon, 20 May 2013 11:11:31 -0600 Subject: [IPython-dev] Flat is better than nested In-Reply-To: <519A5694.8030605@gmail.com> References: <519658A3.3000007@gmail.com> <20130520162654.GG23990@odin.tremily.us> <519A5694.8030605@gmail.com> Message-ID: On a somewhat unrelated note, if __all__ is supposed to represent those things in a module that are public API, would it make sense for IPython's tab completer to respect this, so that from module import only showed those things in module.__all__, if module.__all__ is defined? To me, that would go a long way to solidifying this definition of __all__ in people's minds, or at least people like me who use IPython to prototype code that uses library code. Aaron Meurer On Mon, May 20, 2013 at 11:00 AM, Carlos C?rdoba wrote: > Hi, > > @Aaron: A @public decorator seems really cool, it makes look code really > neat! I'll investigate how to include it in our PR. > > @Trevor: I think you are missing the point: these changes are not meant for > regular users but for projects that are using IPython as a library. The idea > is to put in __all__ the main pieces of qtconsole (not only > RichIPythonWidget, but also QtKernelManager, QtKernelClient, etc) to tell > those projects what elements they need to rely on to build a customized > frontend. > > Cheers, > Carlos > > El 20/05/13 11:26, W. Trevor King escribi?: > > On Fri, May 17, 2013 at 11:19:47AM -0500, Carlos C?rdoba wrote: > > For us in Spyder it would be better to be able to import things like > RichIPythonWidget as > > from IPython.frontend.qt import RichIPythonWidget > > instead of > > from IPython.qt.console.rich_ipython_widget import RichIPythonWidget > > because even without "frontend" there are four levels of nested modules > to reach one of the most essential pieces of that frontend. > > So why not add an __all__ attribute to each frontend instead? > > I've just been skimming this thread, but I'd caution against namespace > squashing for scripting things (not very DRY). If users are calling > RichIPythonWidget from their IPython session, then providing a > shortcut namespace is fine (? la Matplotlib's pylab [1]), but having > multiple script-oriented locations is just confusing. In this case, > it might be best to have: > > from ._rich_ipython_widget import RichIPythonWidget > > in IPython.qt.console (or IPython.qt?), which all consumers have to > use instead of importing the (now private) rich_ipython_widget module > directly. > > Cheers, > Trevor > > [1]: > http://matplotlib.org/faq/usage_faq.html#matplotlib-pylab-and-pyplot-how-are-they-related > > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > From wking at tremily.us Mon May 20 13:15:07 2013 From: wking at tremily.us (W. Trevor King) Date: Mon, 20 May 2013 13:15:07 -0400 Subject: [IPython-dev] Flat is better than nested In-Reply-To: <519A5694.8030605@gmail.com> References: <519658A3.3000007@gmail.com> <20130520162654.GG23990@odin.tremily.us> <519A5694.8030605@gmail.com> Message-ID: <20130520171507.GI23990@odin.tremily.us> On Mon, May 20, 2013 at 12:00:04PM -0500, Carlos C?rdoba wrote: > @Trevor: I think you are missing the point: these changes are not meant > for regular users but for projects that are using IPython as a library. > The idea is to put in __all__ the main pieces of qtconsole (not only > RichIPythonWidget, but also QtKernelManager, QtKernelClient, etc) to > tell those projects what elements they need to rely on to build a > customized frontend. It makes sense to pull important pieces into an easy to find location. I just think it makes sense to deprecate the overly-nested original location when you make the move. After all [1]: There should be one-- and preferably only one --obvious way to do it. ;). Cheers, Trevor [1]: http://www.python.org/dev/peps/pep-0020/ -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From fperez.net at gmail.com Mon May 20 16:46:19 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 20 May 2013 13:46:19 -0700 Subject: [IPython-dev] Flat is better than nested In-Reply-To: <20130520171507.GI23990@odin.tremily.us> References: <519658A3.3000007@gmail.com> <20130520162654.GG23990@odin.tremily.us> <519A5694.8030605@gmail.com> <20130520171507.GI23990@odin.tremily.us> Message-ID: On Mon, May 20, 2013 at 10:15 AM, W. Trevor King wrote: > On Mon, May 20, 2013 at 12:00:04PM -0500, Carlos C?rdoba wrote: >> @Trevor: I think you are missing the point: these changes are not meant >> for regular users but for projects that are using IPython as a library. >> The idea is to put in __all__ the main pieces of qtconsole (not only >> RichIPythonWidget, but also QtKernelManager, QtKernelClient, etc) to >> tell those projects what elements they need to rely on to build a >> customized frontend. > > It makes sense to pull important pieces into an easy to find location. > I just think it makes sense to deprecate the overly-nested original > location when you make the move. After all [1]: > > There should be one-- and preferably only one --obvious way to do it. Well, it's a matter of balancing two constraints: 1- having a relatively flat public API, so that third-party projects (what Carlos refers to) don't have to do very crazy from IPython.this.that.foo.bar.baz import frob, which gets annoying. 2- allowing the IPython team to develop the libraries with smallish files and a directory layout that lets people focus on a few things at a time. Flattening the actual filesystem completely works against 2, but Python fortunately offers the __all__ attribute to expose a public api. The decorator trick is a convenient way of populating that which remains close to the code being exposed, so I actually like it quite a bit. One more note: having these top-level entry points not only helps third-party users keep shorter imports, it also lets us reorganize things internally as needed without breaking the user-facing API. It can be handy as the project evolves to move things around in deeply nested files: if projects are only importing those components from high-level entry points, nothing will break for them. I don't think we'll have the time to do a systematic run down of all the APIs to achieve this before 1.0, but I'd certainly like to have most of our 'official' entry points require only from IPython.X import Y with no deeper nesting. Cheers, f From fperez.net at gmail.com Mon May 20 17:00:04 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 20 May 2013 14:00:04 -0700 Subject: [IPython-dev] Flat is better than nested In-Reply-To: <51968A5A.6090500@gmail.com> References: <519658A3.3000007@gmail.com> <51968A5A.6090500@gmail.com> Message-ID: On Fri, May 17, 2013 at 12:51 PM, Carlos C?rdoba wrote: > Ok, thanks for the answer, that makes more sense (although I don't agree > with making such changes so far ahead in time). One more reason that explains the reasoning behind this: if we really want to end up with less nested public APIs (which goes on top of your suggestion of better __all__ support), the frontend level didn't really add anything. We can't in frontend/__init__ import anything from the subpackages, because a notebook user most certainly won't want Qt libraries pulled in, and similarly you guys probably don't want tornado to become a dependency for Spyder :) So the frontend/ level was serving one purpose only: informing users of the code, by aggregation in the filesystem, that html, terminal and qt are our three frontends. While there's certainly some value to this, there's also a cost in deeper nesting and the above constraint. It just seemed like flattening was a better tradeoff in this case, since most library users (e.g. sypder) will know anyways that IPython's qt directory is really for the qt console, since it's not like we ship entire pieces of Qt widgets or anything similar. We realize this represents a small loss of information at the filesystem layout level, but it was a worthwhile tradeoff in terms of the rest of our package management and API constraints. I hope this clarifies things. Cheers, f From fperez.net at gmail.com Mon May 20 17:04:09 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 20 May 2013 14:04:09 -0700 Subject: [IPython-dev] IPython "lab meetings" on g+ hangouts on air In-Reply-To: References: <5198F3A0.7080502@gmail.com> Message-ID: On Sun, May 19, 2013 at 1:59 PM, Aaron Meurer wrote: > On Sun, May 19, 2013 at 2:34 PM, Fernando Perez wrote: >> Does anyone have any good suggestions on a tool for collaborative >> note-taking, so that we can leave some public summary/record of these >> meetings with minimal fuss? >> >> A google doc is a bit of a hassle for this, I think, esp. since we >> want something to produce plaintext. > > Just curious, why does it have to be plain text? I've found Google > Docs features like tables and highlighting are quite useful in > sometimes. I just want to keep it very simple for completely public editing and immediate pasting either into a wiki page with logs or a mailing list post. I love and use Google Docs extensively, but for plaintext/markdown it's kind of a miserable experience. > Maybe you could find a collaborative editing tool that uses Markdown. > Then you could just post the result on the wiki. It seems like either hackpad or prose.io, suggested by Massimo and Carl, could do the trick. We'll see, for now we can just start without anything, but if anyone wants to jump in and keep a summary with minimal effort, that person can lead the choice of tool as well :) Cheers, f From takowl at gmail.com Mon May 20 17:13:52 2013 From: takowl at gmail.com (Thomas Kluyver) Date: Mon, 20 May 2013 22:13:52 +0100 Subject: [IPython-dev] Flat is better than nested In-Reply-To: References: <519658A3.3000007@gmail.com> <20130520162654.GG23990@odin.tremily.us> <519A5694.8030605@gmail.com> Message-ID: On 20 May 2013 18:11, Aaron Meurer wrote: > On a somewhat unrelated note, if __all__ is supposed to represent > those things in a module that are public API, would it make sense for > IPython's tab completer to respect this, so that > > from module import > > only showed those things in module.__all__, if module.__all__ is > defined? To me, that would go a long way to solidifying this > definition of __all__ in people's minds, or at least people like me > who use IPython to prototype code that uses library code. > There's an option for this (c.IPCompleter.limit_to__all__), but it defaults to False - I think the rationale is that you may want to use 'from foo import bar' to explicitly import something that isn't included in __all__. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From asmeurer at gmail.com Mon May 20 17:23:37 2013 From: asmeurer at gmail.com (Aaron Meurer) Date: Mon, 20 May 2013 15:23:37 -0600 Subject: [IPython-dev] Flat is better than nested In-Reply-To: References: <519658A3.3000007@gmail.com> <20130520162654.GG23990@odin.tremily.us> <519A5694.8030605@gmail.com> Message-ID: It doesn't seem to work. I have a file with __all__ defined, but doing "from file import " still lists all the names in that file. Aaron Meurer On Mon, May 20, 2013 at 3:13 PM, Thomas Kluyver wrote: > > On 20 May 2013 18:11, Aaron Meurer wrote: >> >> On a somewhat unrelated note, if __all__ is supposed to represent >> those things in a module that are public API, would it make sense for >> IPython's tab completer to respect this, so that >> >> from module import >> >> only showed those things in module.__all__, if module.__all__ is >> defined? To me, that would go a long way to solidifying this >> definition of __all__ in people's minds, or at least people like me >> who use IPython to prototype code that uses library code. > > > There's an option for this (c.IPCompleter.limit_to__all__), but it defaults > to False - I think the rationale is that you may want to use 'from foo > import bar' to explicitly import something that isn't included in __all__. > > Thomas > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > From ellisonbg at gmail.com Tue May 21 15:08:20 2013 From: ellisonbg at gmail.com (Brian Granger) Date: Tue, 21 May 2013 12:08:20 -0700 Subject: [IPython-dev] IPython "lab meetings" on g+ hangouts on air In-Reply-To: References: <5198F3A0.7080502@gmail.com> Message-ID: Do we have a time for this week? Brian On Mon, May 20, 2013 at 2:04 PM, Fernando Perez wrote: > On Sun, May 19, 2013 at 1:59 PM, Aaron Meurer wrote: >> On Sun, May 19, 2013 at 2:34 PM, Fernando Perez wrote: >>> Does anyone have any good suggestions on a tool for collaborative >>> note-taking, so that we can leave some public summary/record of these >>> meetings with minimal fuss? >>> >>> A google doc is a bit of a hassle for this, I think, esp. since we >>> want something to produce plaintext. >> >> Just curious, why does it have to be plain text? I've found Google >> Docs features like tables and highlighting are quite useful in >> sometimes. > > I just want to keep it very simple for completely public editing and > immediate pasting either into a wiki page with logs or a mailing list > post. I love and use Google Docs extensively, but for > plaintext/markdown it's kind of a miserable experience. > >> Maybe you could find a collaborative editing tool that uses Markdown. >> Then you could just post the result on the wiki. > > It seems like either hackpad or prose.io, suggested by Massimo and > Carl, could do the trick. > > We'll see, for now we can just start without anything, but if anyone > wants to jump in and keep a summary with minimal effort, that person > can lead the choice of tool as well :) > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From ellisonbg at gmail.com Tue May 21 15:36:42 2013 From: ellisonbg at gmail.com (Brian Granger) Date: Tue, 21 May 2013 12:36:42 -0700 Subject: [IPython-dev] implementing sympy plots with d3 in the notebook In-Reply-To: References: Message-ID: Stefan, > If any of you have 5 minutes to tell us whether we are doing something > horribly wrong we would appreciate it. > > Recently, I tried to extend the sympy plotting module so that we can plot > with d3. > > A proof of concept can be seen here (sympy pull request, vega and d3): > https://github.com/sympy/sympy/pull/2120 > > The 5 lines that deal with ipython are in `def show(self):` > > > A more hackish earlier version can be seen here (blog post, only d3): > http://blog.krastanov.org/2013/05/14/sympy-plots-with-d3-in-ipyhton/ > > > What is the IPython team opinion? Should we wait a few months for somekind > of `_repr_json`? Starting in the late summer we will implement a much less hackish API for doing this type of thing. That new API will some quite different than what you are doing now. Your current approach may continue to work, but might need some changes. The more you do now, the more you will have to change. The less you do now, the easier it will be in the future. The other thing that I mentioned on the sympy list is that once the better APIs are in place, there are going to be *multiple* libraries that emerge for doing d3 based plotting in the notebook. If you just wait, you can use those libraries without inventing your own. If it were me, I would wait and work on other things in the meantime. Cheers, Brian > Regards > Stefan > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From fperez.net at gmail.com Tue May 21 17:54:33 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 21 May 2013 14:54:33 -0700 Subject: [IPython-dev] IPython "lab meetings" on g+ hangouts on air In-Reply-To: References: <5198F3A0.7080502@gmail.com> Message-ID: On Tue, May 21, 2013 at 12:08 PM, Brian Granger wrote: > Do we have a time for this week? Let's try the Thursday, 10am slot and see if it works well for us. We can always reschedule as necessary. Cheers, f From nborwankar at gmail.com Tue May 21 21:26:38 2013 From: nborwankar at gmail.com (Nitin Borwankar) Date: Tue, 21 May 2013 18:26:38 -0700 Subject: [IPython-dev] IPython "lab meetings" on g+ hangouts on air In-Reply-To: References: <5198F3A0.7080502@gmail.com> Message-ID: Dave Winer of RSS fame has created a collaborative web outliner called Fargo fargo.io It's a great app for meeting notes Read-Only version of doc can be published. Works off Dropbox. Nitin ------------------------------------------------------------------ Nitin Borwankar nborwankar at gmail.com On Sun, May 19, 2013 at 1:34 PM, Fernando Perez wrote: > Does anyone have any good suggestions on a tool for collaborative > note-taking, so that we can leave some public summary/record of these > meetings with minimal fuss? > > A google doc is a bit of a hassle for this, I think, esp. since we > want something to produce plaintext. > > Etherpad is ugly as sin, but it's fairly functional and I know the > software carpentry folks use it very effectively. > > Unless someone knows of a better solution, I guess we could just use > etherpad. I'm not thinking of anything very involved, simply a > document for each meeting where everyone can type, and that we can > copy/paste to the mailing list at the end as a quick and dirty > summary. > > I know we won't have time for formal minutes, so these docs could end > up being little more than a link to the URL for the youtube video. > But if there's anything worth summarizing in text, I think it will be > useful to have a note-taking app open with everyone involved. > > Note that this is different from chat: g+ has an open chat channel, > but that's a sequence of messages. What I'm thinking of is a proper > *editor* where we can leave a text file at the end; a chat app won't > work for this. > > I want this to be very lightweight and low-friction, so hopefully a > simple g+ hangout plus a common text file is all we'll need. > > I propose we go with the ugly etherpad unless anyone has a better > solution (but I'm happy to use something else if there is such a > thing). > > Cheers, > > f > > On Sun, May 19, 2013 at 10:15 AM, epi wrote: > > I love this, > > i enjoyed the first hangout > > i'll follow you guys :) > > > > thanks! > > > > Massimo. > > > > Il giorno 19/mag/2013, alle ore 11:45, Dami?n Avila < > damianavila at gmail.com> ha scritto: > > > >> El 16/05/13 22:06, Fernando Perez escribi?: > >>> Hi folks, > >>> > >>> as Brian just mentioned, we had a google hangout discussion today, > >>> that arose impromptu from having a chat room discussion where it was > >>> obvious we needed more bandwidth than just typing can provide. > >>> > >>> Today (perhaps because of all the changes Google made yesterday, who > >>> knows), g+ was a bit glitchy, and we were unable to make the hangout > >>> on-air, so it ended up not being recorded. But in general we want all > >>> these discussions to be public, for example here's our previous one: > >>> > >>> http://www.youtube.com/watch?v=Yb35M8cW7o4 > >>> > >>> While I think it's great to jump in on video conversations like this > >>> as-needed from the dev room or a github issue/PR discussion, we've > >>> also been thinking about having a more regular 'lab meeting' style > >>> discussion that is scheduled at a fixed time. > >>> > >>> This would give a predictable time for everyone to participate, and > >>> would play the same role as lab meetings in everyday research, but > >>> taking into consideration the fact that we're an open, international > >>> collaboration. > >>> > >>> Those lab meetings would be held with hangouts on-air, and thus open > >>> for anyone who wants to watch and join, and kept on-record afterwards. > >>> > >>> The plan would be to hold them for ~60-90 minutes, to make regular > >>> progress on design decisions that impact the project at large. > >>> Impromptu hangouts as required by the everyday workflow will continue > >>> to happen, and we'll do our best to also record those in public > >>> format. > >>> > >>> If you like the idea, I'd like to propose Thursdays at 10am US Pacific > >>> time, i.e. UTC-7 hours right now (PDT). That's a good time for all > >>> the folks here in California while still being reasonable in Europe. > >>> I know we can't find a time that will work across all of Earth, but at > >>> least that probably covers reasonably well our current core team and > >>> lots of others. > >>> > >>> How does this sound to you all? Would the time work for a reasonable > >>> chunk of our active developers? Note that I am NOT asking only of the > >>> 'core' github committers, but of anyone who is putting lots of time > >>> into IPython work and is interested in joining these discussions. > >>> > >>> Cheers, > >>> > >>> f > >>> _______________________________________________ > >>> IPython-dev mailing list > >>> IPython-dev at scipy.org > >>> http://mail.scipy.org/mailman/listinfo/ipython-dev > >> > >> > >> I think it is a great idea! I will try to participate in the meeting as > >> much as I can. > >> > >> Cheers. > >> > >> Dami?n. > >> > >> > >> _______________________________________________ > >> 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 Wed May 22 17:13:09 2013 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Wed, 22 May 2013 23:13:09 +0200 Subject: [IPython-dev] IPython "lab meetings" on g+ hangouts on air In-Reply-To: References: <5198F3A0.7080502@gmail.com> Message-ID: <7154635F-6F18-4036-B7FA-61B5F81D6E24@gmail.com> Hi, Le 21 mai 2013 ? 23:54, Fernando Perez a ?crit : > Let's try the Thursday, 10am slot and see if it works well for us. We > can always reschedule as necessary. So this week I will probably not be able to make it then, but will catch up later. Do you plan on on keeping the same time and day every (other?) week ? 10am UTC-8 should work for me otherwise. -- Matthias From david at wolever.net Wed May 22 17:25:27 2013 From: david at wolever.net (David Wolever) Date: Wed, 22 May 2013 17:25:27 -0400 Subject: [IPython-dev] Announcing BrowserCast: a Notebook-based presentation tool Message-ID: <648317CC-C87D-457C-8E6C-0B91D34024BF@wolever.net> Hey all, I've been working on an Notebook plugin which allows notebooks to be set to audio, creating a screencast-style presentation in the browser. I've got a couple old-school screencasts which show it off: - Why is BrowserCast cool? http://youtu.be/OAIyHgbi5rM - Creating a presentation with BrowserCast: http://youtu.be/UhHRuPPFWtE And you can try it for yourself with one bookmarklet: - http://wolever.github.io/browsercast/ And check out the source on GitHub: - https://github.com/wolever/browsercast I'm also planning on turning this into a proper IPython extension? But I don't know exactly how to create a zip file that will make `%install_ext` happy, or how I can use the Notebook's HTTP server to serve the static files. If someone could point me in the right direction, I would appreciate it: https://github.com/wolever/browsercast/issues/2 As always, feedback is very much appreciated. David -- phone: (416) 906-0403 pgp: B230230D From fperez.net at gmail.com Wed May 22 18:11:31 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 22 May 2013 15:11:31 -0700 Subject: [IPython-dev] IPython "lab meetings" on g+ hangouts on air In-Reply-To: <7154635F-6F18-4036-B7FA-61B5F81D6E24@gmail.com> References: <5198F3A0.7080502@gmail.com> <7154635F-6F18-4036-B7FA-61B5F81D6E24@gmail.com> Message-ID: On Wed, May 22, 2013 at 2:13 PM, Matthias BUSSONNIER wrote: > Hi, > > Le 21 mai 2013 ? 23:54, Fernando Perez a ?crit : > >> Let's try the Thursday, 10am slot and see if it works well for us. We >> can always reschedule as necessary. > > So this week I will probably not be able to make it then, > but will catch up later. > > Do you plan on on keeping the same time and day every (other?) week ? Yes, as long as it works for a reasonable number of people. Otherwise we can switch it around, keeping the time constant to bridge the California-Europe gap... Cheers, f From takowl at gmail.com Wed May 22 18:25:05 2013 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 22 May 2013 23:25:05 +0100 Subject: [IPython-dev] Announcing BrowserCast: a Notebook-based presentation tool In-Reply-To: <648317CC-C87D-457C-8E6C-0B91D34024BF@wolever.net> References: <648317CC-C87D-457C-8E6C-0B91D34024BF@wolever.net> Message-ID: On 22 May 2013 22:25, David Wolever wrote: > I've been working on an Notebook plugin which allows notebooks to be set > to audio, creating a screencast-style presentation in the browser. > Cool, that looks useful. > I'm also planning on turning this into a proper IPython extension? But I > don't know exactly how to create a zip file that will make `%install_ext` > happy, > For now %install_ext can only handle a single Python module. For larger things, you can create a regular Python package that people install with pip: IPython extensions work from any importable location. Someone else should be able to help you more with the notebook server integration. Best wishes, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at wolever.net Thu May 23 00:26:53 2013 From: david at wolever.net (David Wolever) Date: Thu, 23 May 2013 00:26:53 -0400 Subject: [IPython-dev] Announcing BrowserCast: a Notebook-based presentation tool In-Reply-To: References: <648317CC-C87D-457C-8E6C-0B91D34024BF@wolever.net> Message-ID: <7ABF68BF-76D2-4295-A6D2-1D0B3FAC9CE3@wolever.net> On 2013-05-22, at 6:25 PM, Thomas Kluyver wrote: > For now %install_ext can only handle a single Python module. For larger things, you can create a regular Python package that people install with pip: IPython extensions work from any importable location. Oh? Because the API docs for IPython.core.extension[0] suggest: > If filename is given, the file will be so named (inside the extension directory). Otherwise, the name from the URL will be used. The file must have a .py or .zip extension; otherwise, a ValueError will be raised. [0]: http://ipython.org/ipython-doc/dev/api/generated/IPython.core.extensions.html From bussonniermatthias at gmail.com Thu May 23 02:58:54 2013 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Thu, 23 May 2013 08:58:54 +0200 Subject: [IPython-dev] Announcing BrowserCast: a Notebook-based presentation tool In-Reply-To: <7ABF68BF-76D2-4295-A6D2-1D0B3FAC9CE3@wolever.net> References: <648317CC-C87D-457C-8E6C-0B91D34024BF@wolever.net> <7ABF68BF-76D2-4295-A6D2-1D0B3FAC9CE3@wolever.net> Message-ID: Le 23 mai 2013 ? 06:26, David Wolever a ?crit : > > On 2013-05-22, at 6:25 PM, Thomas Kluyver wrote: > >> For now %install_ext can only handle a single Python module. For larger things, you can create a regular Python package that people install with pip: IPython extensions work from any importable location. > > Oh? Because the API docs for IPython.core.extension[0] suggest: >> If filename is given, the file will be so named (inside the extension directory). Otherwise, the name from the URL will be used. The file must have a .py or .zip extension; otherwise, a ValueError will be raised. > > [0]: http://ipython.org/ipython-doc/dev/api/generated/IPython.core.extensions.html %Install_ext is provided as a convenience to **install** single extension files. But modules can ship multiple extension packaged as python files; for example with sympy you can use %load_ext sympy.interactive.ipythonprinting within only installing sympy with pip. -- Matthias > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From takowl at gmail.com Thu May 23 08:46:59 2013 From: takowl at gmail.com (Thomas Kluyver) Date: Thu, 23 May 2013 13:46:59 +0100 Subject: [IPython-dev] Announcing BrowserCast: a Notebook-based presentation tool In-Reply-To: <7ABF68BF-76D2-4295-A6D2-1D0B3FAC9CE3@wolever.net> References: <648317CC-C87D-457C-8E6C-0B91D34024BF@wolever.net> <7ABF68BF-76D2-4295-A6D2-1D0B3FAC9CE3@wolever.net> Message-ID: On 23 May 2013 05:26, David Wolever wrote: > Oh? Because the API docs for IPython.core.extension[0] suggest: > > If filename is given, the file will be so named (inside the extension > directory). Otherwise, the name from the URL will be used. The file must > have a .py or .zip extension; otherwise, a ValueError will be raised. > Yep, sorry, when that was written, I thought that you could make an importable zip file. What Python actually allows is putting a zip file on sys.path to import modules from it, but that's not quite what we need here. I should remember to updated it. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdroe at stsci.edu Thu May 23 11:00:48 2013 From: mdroe at stsci.edu (Michael Droettboom) Date: Thu, 23 May 2013 11:00:48 -0400 Subject: [IPython-dev] IPython/matplotlib WebAgg backend integration Message-ID: <519E2F20.3000009@stsci.edu> I have a PR for a first pass at integrating matplotlib's new fully-interactive WebAgg backend with IPython here: https://github.com/matplotlib/matplotlib/pull/2054 I'd appreciate feedback on it from IPython folks. There are also a few points in the code I've marked as "TODO" that might have obvious solutions for IPython folks but which are currently stumping me. Thanks -- and I'm hoping there are some folks I can talk to at Scipy about getting these rough edges polished and getting this all working nicely together. Cheers, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Thu May 23 12:49:18 2013 From: ellisonbg at gmail.com (Brian Granger) Date: Thu, 23 May 2013 09:49:18 -0700 Subject: [IPython-dev] IPython "lab meetings" on g+ hangouts on air In-Reply-To: References: <5198F3A0.7080502@gmail.com> <7154635F-6F18-4036-B7FA-61B5F81D6E24@gmail.com> Message-ID: Here is a hackpad for the meeting: https://hackpad.com/IPython-dev-meeting-5232013-6wTSjJt7TZK On Wed, May 22, 2013 at 3:11 PM, Fernando Perez wrote: > On Wed, May 22, 2013 at 2:13 PM, Matthias BUSSONNIER > wrote: >> Hi, >> >> Le 21 mai 2013 ? 23:54, Fernando Perez a ?crit : >> >>> Let's try the Thursday, 10am slot and see if it works well for us. We >>> can always reschedule as necessary. >> >> So this week I will probably not be able to make it then, >> but will catch up later. >> >> Do you plan on on keeping the same time and day every (other?) week ? > > Yes, as long as it works for a reasonable number of people. Otherwise > we can switch it around, keeping the time constant to bridge the > California-Europe gap... > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From fperez.net at gmail.com Thu May 23 13:07:25 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 23 May 2013 10:07:25 -0700 Subject: [IPython-dev] Lab meeting on air. Links Message-ID: Live stream on youtube; http://youtu.be/vSSL4jJYpu4 Hackpad for note taking: https://hackpad.com/IPython-dev-meeting-5232013-6wTSjJt7TZK Chat: we'll use the dev chat room: www.hipchat.com/ghtNzvmfC, anyone can log in... From david at wolever.net Thu May 23 18:24:07 2013 From: david at wolever.net (David Wolever) Date: Thu, 23 May 2013 18:24:07 -0400 Subject: [IPython-dev] Announcing BrowserCast: a Notebook-based presentation tool In-Reply-To: References: <648317CC-C87D-457C-8E6C-0B91D34024BF@wolever.net> <7ABF68BF-76D2-4295-A6D2-1D0B3FAC9CE3@wolever.net> Message-ID: <4B2A35EE-2431-4198-9AA1-123EC5A637AB@wolever.net> On 2013-05-23, at 8:46 AM, Thomas Kluyver wrote: > Yep, sorry, when that was written, I thought that you could make an importable zip file. What Python actually allows is putting a zip file on sys.path to import modules from it, but that's not quite what we need here. I should remember to updated it. Ah, ok ? good to know. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at wolever.net Thu May 23 18:33:25 2013 From: david at wolever.net (David Wolever) Date: Thu, 23 May 2013 18:33:25 -0400 Subject: [IPython-dev] How can an extension add Notebook URL handlers? Message-ID: <595EDE1B-646A-4C11-A32E-C29D03A9257A@wolever.net> Hey, I'd like to turn BrowserCast into a "real" extension? but to do that, I need to extend NotebookWebApplication's list of URL handlers to include a handler which will serve the relevant static files (ex, a handler so that requests for "/browsercast/static/(.*)" will be served from "?/site-packages/ipython_browsercast/static/"). How can I do that? Thanks, David -- phone: (416) 906-0403 pgp: B230230D From david at wolever.net Thu May 23 18:41:18 2013 From: david at wolever.net (David Wolever) Date: Thu, 23 May 2013 18:41:18 -0400 Subject: [IPython-dev] How can an extension inject HTML? Message-ID: Hey, As part of turning BrowserCast into a "real" extension, I need to inject some HTML into the document when the extension is loaded (ex, add the "start BrowserCast" button, or whatever makes most sense). How can I do that? Thanks, David -- phone: (416) 906-0403 pgp: B230230D From benjaminrk at gmail.com Thu May 23 18:41:31 2013 From: benjaminrk at gmail.com (MinRK) Date: Thu, 23 May 2013 15:41:31 -0700 Subject: [IPython-dev] How can an extension add Notebook URL handlers? In-Reply-To: <595EDE1B-646A-4C11-A32E-C29D03A9257A@wolever.net> References: <595EDE1B-646A-4C11-A32E-C29D03A9257A@wolever.net> Message-ID: Extensions do not have that level of access - you would need to subclass the application, extend it, and add your own entry point. Unless we add a notion of notebook server plugins, adding handlers won't be possible without subclassing. On Thu, May 23, 2013 at 3:33 PM, David Wolever wrote: > Hey, > I'd like to turn BrowserCast into a "real" extension? but to do that, I > need to extend NotebookWebApplication's list of URL handlers to include a > handler which will serve the relevant static files (ex, a handler so that > requests for "/browsercast/static/(.*)" will be served from > "?/site-packages/ipython_browsercast/static/"). > > How can I do that? > > Thanks, > David > > -- > phone: (416) 906-0403 > pgp: B230230D > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Thu May 23 18:42:30 2013 From: benjaminrk at gmail.com (MinRK) Date: Thu, 23 May 2013 15:42:30 -0700 Subject: [IPython-dev] How can an extension inject HTML? In-Reply-To: References: Message-ID: On Thu, May 23, 2013 at 3:41 PM, David Wolever wrote: > Hey, > As part of turning BrowserCast into a "real" extension, I need to inject > some HTML into the document when the extension is loaded (ex, add the > "start BrowserCast" button, or whatever makes most sense). > > How can I do that? > typically in your profile's custom.js, you can perform arbitrary manipulation of the notebook page. > > Thanks, > David > > -- > phone: (416) 906-0403 > pgp: B230230D > > _______________________________________________ > 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 Thu May 23 18:57:20 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 23 May 2013 15:57:20 -0700 Subject: [IPython-dev] Lab meetings on air Message-ID: Hi folks, I think the meeting today went really well, so we'll do our best to stick to this schedule and process... I've put up a page on the wiki here with all the relevant links and a record of prior ones (today and an impromptu one we had a few days ago): https://github.com/ipython/ipython/wiki/%22Lab-meetings-on-Air%22:-public-development-discussions I'm sure there will be kinks to iron in the process, just let us know of any ideas you may have to improve things. But I'm pretty happy with the outcome as it is. Cheers, f From david at wolever.net Thu May 23 19:03:45 2013 From: david at wolever.net (David Wolever) Date: Thu, 23 May 2013 19:03:45 -0400 Subject: [IPython-dev] How can an extension add Notebook URL handlers? In-Reply-To: References: <595EDE1B-646A-4C11-A32E-C29D03A9257A@wolever.net> Message-ID: <33EEC03D-14CA-4AAF-A7F1-307C30FA22E5@wolever.net> On 2013-05-23, at 6:41 PM, MinRK wrote: > Extensions do not have that level of access - you would need to subclass the application, extend it, and add your own entry point. > Unless we add a notion of notebook server plugins, adding handlers won't be possible without subclassing. Ok, good to know ? thanks. -- phone: (416) 906-0403 pgp: B230230D -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at wolever.net Thu May 23 19:04:53 2013 From: david at wolever.net (David Wolever) Date: Thu, 23 May 2013 19:04:53 -0400 Subject: [IPython-dev] How can an extension inject HTML? In-Reply-To: References: Message-ID: <109EFDF1-CE31-4DC5-BC02-7034D6FB6748@wolever.net> On 2013-05-23, at 6:42 PM, MinRK wrote: > typically in your profile's custom.js, you can perform arbitrary manipulation of the notebook page. Hrm? This seems less than ideal, since it would mean that installing the BrowserCast extension requires the extra fiddly step of editing your custom.js. Is there no other way the extension can inject JavaScript? -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Thu May 23 19:08:10 2013 From: benjaminrk at gmail.com (MinRK) Date: Thu, 23 May 2013 16:08:10 -0700 Subject: [IPython-dev] How can an extension inject HTML? In-Reply-To: <109EFDF1-CE31-4DC5-BC02-7034D6FB6748@wolever.net> References: <109EFDF1-CE31-4DC5-BC02-7034D6FB6748@wolever.net> Message-ID: On Thu, May 23, 2013 at 4:04 PM, David Wolever wrote: > > On 2013-05-23, at 6:42 PM, MinRK wrote: > > typically in your profile's custom.js, you can perform arbitrary > manipulation of the notebook page. > > > Hrm? This seems less than ideal, since it would mean that installing the > BrowserCast extension requires the extra fiddly step of editing your > custom.js. > > Is there no other way the extension can inject JavaScript? > you can always inject javascript from any Python code by calling `display(Javascript("some_javascript();"))`. It is often appropriate to make such a call as part of `%load_ext browsercast`, for example. But custom.js is the only way to add js that runs on all notebooks at load time without executing any code. > > > > > _______________________________________________ > 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 Thu May 23 19:23:46 2013 From: takowl at gmail.com (Thomas Kluyver) Date: Fri, 24 May 2013 00:23:46 +0100 Subject: [IPython-dev] How can an extension inject HTML? In-Reply-To: References: <109EFDF1-CE31-4DC5-BC02-7034D6FB6748@wolever.net> Message-ID: On 24 May 2013 00:08, MinRK wrote: > you can always inject javascript from any Python code by calling > `display(Javascript("some_javascript();"))`. It is often appropriate to > make such a call as part of `%load_ext browsercast`, for example. > > But custom.js is the only way to add js that runs on all notebooks at load > time without executing any code. > This is probably worth thinking more about, though - our existing extension infrastructure only handles the kernel side, and we'll want something that allows neatly contained extensions that modify the notebook UI as well. Is that already on our agenda somewhere? Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Thu May 23 19:24:44 2013 From: ellisonbg at gmail.com (Brian Granger) Date: Thu, 23 May 2013 16:24:44 -0700 Subject: [IPython-dev] How can an extension inject HTML? In-Reply-To: References: <109EFDF1-CE31-4DC5-BC02-7034D6FB6748@wolever.net> Message-ID: Yes, that will be part of the work in the late summer/fall. On Thu, May 23, 2013 at 4:23 PM, Thomas Kluyver wrote: > On 24 May 2013 00:08, MinRK wrote: >> >> you can always inject javascript from any Python code by calling >> `display(Javascript("some_javascript();"))`. It is often appropriate to >> make such a call as part of `%load_ext browsercast`, for example. >> >> But custom.js is the only way to add js that runs on all notebooks at load >> time without executing any code. > > > This is probably worth thinking more about, though - our existing extension > infrastructure only handles the kernel side, and we'll want something that > allows neatly contained extensions that modify the notebook UI as well. Is > that already on our agenda somewhere? > > Thomas > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From wojtek.danilo.ml at gmail.com Sun May 26 20:23:44 2013 From: wojtek.danilo.ml at gmail.com (=?ISO-8859-2?Q?Wojciech_Dani=B3o?=) Date: Mon, 27 May 2013 02:23:44 +0200 Subject: [IPython-dev] IPython Javascript integration Message-ID: Hi! I'm new to IPython. I want to use it as a base layer for my application - lets say - as a batch processing program base layer. I want my application to have HTML5 based GUI and I want it to communicate with the server side batch program. Has IPython got support for such JavaScript - Python communication? I think it has, because the INotebook is browser based, so it communicates with IPython kernel somewhere. 1. Could you give me some tips how to start searching about existing solutions in this topic and how to create such JavaScript <-> IPython kernel communication? 2. Does such communication support websockets? If not, could you give me some hints, how to best integrate websocket communication support with IPython? (I would love my batch program to interact as smooth as possible with my GUI). 3. Additional has IPython got some authentication mechanism built in? Thank you, Wojtek -------------- next part -------------- An HTML attachment was scrubbed... URL: From bussonniermatthias at gmail.com Mon May 27 02:16:47 2013 From: bussonniermatthias at gmail.com (Matthias Bussonnier) Date: Mon, 27 May 2013 08:16:47 +0200 Subject: [IPython-dev] IPython Javascript integration In-Reply-To: References: Message-ID: Hi, Short answer from my phone. JavaScript communicate through web socket s to the web server (tornado) that relay the messages to te python kernel via ZMQ. There is authentication at server level, but not multiuser for now. Having the ability to add a user-define communication layer between jus and python on top of what we have currently is on the roadmap. You can do it now, but it will require some involvement. -- Matthias Le lundi 27 mai 2013, Wojciech Dani?o a ?crit : > Hi! > I'm new to IPython. > > I want to use it as a base layer for my application - lets say - as a > batch processing program base layer. > I want my application to have HTML5 based GUI and I want it to communicate > with the server side batch program. > > Has IPython got support for such JavaScript - Python communication? I > think it has, because the INotebook is browser based, so it communicates > with IPython kernel somewhere. > > > 1. Could you give me some tips how to start searching about existing > solutions in this topic and how to create such JavaScript <-> IPython > kernel communication? > 2. Does such communication support websockets? If not, could you give > me some hints, how to best integrate websocket communication support with > IPython? (I would love my batch program to interact as smooth as possible > with my GUI). > 3. Additional has IPython got some authentication mechanism built in? > > > Thank you, > Wojtek > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.hirschfeld at gmail.com Tue May 28 04:09:18 2013 From: dave.hirschfeld at gmail.com (Dave Hirschfeld) Date: Tue, 28 May 2013 08:09:18 +0000 (UTC) Subject: [IPython-dev] Notebook broken with latest master Message-ID: After updating this morning, including a "git submodule update --recursive" I'm finding that the Notebook is broken. What happens is that the notebook appears to load in the same directory (the last one I used before updating?) regardless of what directory I start it from. As shown below the log message says the notebook is starting from C:/temp but the main notebook page says it is running from my C:/dev/code directory and all the notebooks listed return 500 errors. I've tried pressing F5 multiple times in both chrome & firefox and the problem persists. In [3]: print sys_info() {'commit_hash': '686357b', 'commit_source': 'repository', 'default_encoding': 'cp1252', 'ipython_path': 'c:\\dev\\code\\ipython\\IPython', 'ipython_version': '1.0.dev', 'os_name': 'nt', 'platform': 'Windows-7-6.1.7601-SP1', 'sys_executable': 'C:\\dev\\bin\\Python27\\python.exe', 'sys_platform': 'win32', 'sys_version': '2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)]'} C:\temp> ipython notebook 2013-05-28 09:01:22.668 [NotebookApp] Using existing profile dir: u'C:\\Users\\dhirschfeld\\.ipython\\profile_default' 2013-05-28 09:01:23.861 [NotebookApp] Using MathJax from CDN: http://cdn.mathjax.org/mathjax/latest/MathJax.js 2013-05-28 09:01:23.888 [NotebookApp] Serving notebooks from local directory: C:\temp 2013-05-28 09:01:23.888 [NotebookApp] The IPython Notebook is running at: http://127.0.0.1:8888/ 2013-05-28 09:01:23.890 [NotebookApp] Use Control-C to stop this server and shut down all kernels. HTH, Dave From dave.hirschfeld at gmail.com Tue May 28 04:33:03 2013 From: dave.hirschfeld at gmail.com (Dave Hirschfeld) Date: Tue, 28 May 2013 08:33:03 +0000 (UTC) Subject: [IPython-dev] Notebook broken with latest master RESOLVED References: Message-ID: Dave Hirschfeld gmail.com> writes: > > After updating this morning, including a "git submodule update --recursive" > I'm finding that the Notebook is broken. > Please ignore! I had an orphaned notebook process interfering with the one I'd started. After killing the other process the notebook is working fine again. Sorry for the false alarm! -Dave From bussonniermatthias at gmail.com Tue May 28 04:40:27 2013 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Tue, 28 May 2013 10:40:27 +0200 Subject: [IPython-dev] Notebook broken with latest master RESOLVED In-Reply-To: References: Message-ID: <68E658AD-4335-4772-8CAE-1EFBCBB289F0@gmail.com> Le 28 mai 2013 ? 10:33, Dave Hirschfeld a ?crit : > Dave Hirschfeld gmail.com> writes: > >> >> After updating this morning, including a "git submodule update --recursive" >> I'm finding that the Notebook is broken. >> > > Please ignore! I had an orphaned notebook process interfering with the one I'd > started. After killing the other process the notebook is working fine again. > > Sorry for the false alarm! Still happy having people updating to master on a daily basis :-) -- Matthias From ccordoba12 at gmail.com Tue May 28 11:41:31 2013 From: ccordoba12 at gmail.com (=?UTF-8?B?Q2FybG9zIEPDs3Jkb2Jh?=) Date: Tue, 28 May 2013 10:41:31 -0500 Subject: [IPython-dev] Flat is better than nested In-Reply-To: References: <519658A3.3000007@gmail.com> <51968A5A.6090500@gmail.com> Message-ID: <51A4D02B.2050909@gmail.com> El 20/05/13 16:00, Fernando Perez escribi?: > On Fri, May 17, 2013 at 12:51 PM, Carlos C?rdoba wrote: >> Ok, thanks for the answer, that makes more sense (although I don't agree >> with making such changes so far ahead in time). > One more reason that explains the reasoning behind this: if we really > want to end up with less nested public APIs (which goes on top of your > suggestion of better __all__ support), the frontend level didn't > really add anything. We can't in frontend/__init__ import anything > from the subpackages, because a notebook user most certainly won't > want Qt libraries pulled in, and similarly you guys probably don't > want tornado to become a dependency for Spyder :) Well, right now I'm working to create a notebook plugin for Spyder, and if everything goes well, I hope to have a demo to show at my Scipy talk :) > So the frontend/ level was serving one purpose only: informing users > of the code, by aggregation in the filesystem, that html, terminal and > qt are our three frontends. Yes, that was precisely my point (and I think St?fan's too). > While there's certainly some value to > this, there's also a cost in deeper nesting and the above constraint. > It just seemed like flattening was a better tradeoff in this case, > since most library users (e.g. sypder) will know anyways that > IPython's qt directory is really for the qt console, since it's not > like we ship entire pieces of Qt widgets or anything similar. Perhaps it was a bit more easier for newcomers to find everything inside "frontend" but I think it's wise to avoid too much nesting. > We realize this represents a small loss of information at the > filesystem layout level, but it was a worthwhile tradeoff in terms of > the rest of our package management and API constraints. > > I hope this clarifies things. Yep, thanks for taking the time to explain things more fully. Cheers, Carlos > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From ccordoba12 at gmail.com Tue May 28 11:53:01 2013 From: ccordoba12 at gmail.com (=?UTF-8?B?Q2FybG9zIEPDs3Jkb2Jh?=) Date: Tue, 28 May 2013 10:53:01 -0500 Subject: [IPython-dev] Flat is better than nested In-Reply-To: References: <519658A3.3000007@gmail.com> <20130520162654.GG23990@odin.tremily.us> <519A5694.8030605@gmail.com> <20130520171507.GI23990@odin.tremily.us> Message-ID: <51A4D2DD.2020909@gmail.com> El 20/05/13 15:46, Fernando Perez escribi?: > One more note: having these top-level entry points not only helps > third-party users keep shorter imports, it also lets us reorganize > things internally as needed without breaking the user-facing API. It > can be handy as the project evolves to move things around in deeply > nested files: if projects are only importing those components from > high-level entry points, nothing will break for them. This is a very good point (that I didn't know): so __all__ is like the equivalent of header files in the C/C++ world, which expose public API, so that one can develop the implementation in as many c/cpp files as one wants. From stefan at sun.ac.za Tue May 28 11:55:15 2013 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Tue, 28 May 2013 17:55:15 +0200 Subject: [IPython-dev] Flat is better than nested In-Reply-To: <51A4D02B.2050909@gmail.com> References: <519658A3.3000007@gmail.com> <51968A5A.6090500@gmail.com> <51A4D02B.2050909@gmail.com> Message-ID: On Tue, May 28, 2013 at 5:41 PM, Carlos C?rdoba wrote: >> So the frontend/ level was serving one purpose only: informing users >> of the code, by aggregation in the filesystem, that html, terminal and >> qt are our three frontends. > > Yes, that was precisely my point (and I think St?fan's too). Yes, I think what I tried to convey was that having a single level of nesting up-front does not hurt--the problem is having classes hidden deep within the hierarchy. E.g., if I can do from IPython.frontend import qt and work only with "qt" from there, that's perfectly adequate. St?fan From roberto.colistete at gmail.com Tue May 28 14:22:03 2013 From: roberto.colistete at gmail.com (Roberto Colistete Jr.) Date: Tue, 28 May 2013 15:22:03 -0300 Subject: [IPython-dev] IPython (Notebook) 0.13.2 on Ubuntu Touch OS In-Reply-To: <510EC481.5060604@gmail.com> References: <510EC481.5060604@gmail.com> Message-ID: <51A4F5CB.9000507@gmail.com> Ubuntu Touch OS is Ubuntu for smartphones & tablets. Version 13.10 will be stable, currently it is very simplified and lacks many functions. But Ubuntu Touch 13.04 already has Python 2.7.4 and all the Python modules of regular Ubuntu 13.04. But only softwares with GUI written in Qt5/QML/HTML5 work, so those written using Gtk, Qt4, wxWidgets, etc, can't work. Here is my first contact with Ubuntu Touch on a device (Nexus 4), described in this portuguese blog article : http://robertocolistete.wordpress.com/2013/05/26/ubuntu-touch-no-nexus-4-instalando-e-testando/ Here is the (Google) english translation : http://translate.google.com.br/translate?sl=pt&tl=en&js=n&prev=_t&hl=pt-BR&ie=UTF-8&eotf=1&u=http%3A%2F%2Frobertocolistete.wordpress.com%2F2013%2F05%2F26%2Fubuntu-touch-no-nexus-4-instalando-e-testando%2F Here are some screen photos (while I don't know how to screenshot via software) : http://www.robertocolistete.net/UbuntuTouch/IPython_SymPy_UbuntuTouch.jpg IPython Notebook 0.13.2 running SymPy 0.7.2 with MathJax/TeX rendering. http://www.robertocolistete.net/UbuntuTouch/IPython_SymPyPlotting_UbuntuTouch.jpg IPython Notebook 0.13.2 showing the new plotting module (using PyLab) of SymPy 0.7.2, embedded in the Notebook. IPython 0.13.2 runs the Notebook interface. In server and client mode. In client mode there are some issues due to current development of the web navigator of Ubuntu Touch. IPython Notebook client works with DashBoard, opens IPython Notebooks, renders MathJax and PyLab embedded plots, make calculations, etc. But IPython Notebook doesn't allow to create "New Notebook", large Notebooks which are not totally shown (the scrolling is limited) and some bottons don't work very well. I hope to see IPython Notebook more "touch-friendly" so it will work better in mobile Linux OS : MeeGo Harmattan 1.2 (see below), Nemo / Sailfish OS and Ubuntu Touch. -------- Mensagem original -------- Assunto: IPython 0.13.1 Notebook server on smartphone Data: Sun, 03 Feb 2013 18:11:45 -0200 De: Roberto Colistete Jr. Para: IPython developers list Here my post about a smartphone Nokia N9 as IPython Notebook server : http://talk.maemo.org/showpost.php?p=1320465&postcount=19 My tests included : - 4 web clients at once, 2 notebooks, 1 Android tablet and 1 Nokia N900 smartphone, see : http://talk.maemo.org/showpost.php?p=1320501&postcount=6 - many types of mobile web browsers on Android, Maemo 4&5 and Symbian, besides PC's. So AFAIK, currently we can run IPython Notebook server on : - PC's with Linux, Mac OS, Windows; - mini-PC's running Linux (costing from US$30-40); - smartphone Nokia N9 with MeeGo Harmattan OS; - Android tablet Aakash, it costs US$35 : http://scipy.in/static/files/slides/python-on-aakash.pdf - Linux chroot on tablets/smartphones with Maemo/MeeGo, rooted Android devices, etc. -------- Mensagem original -------- Assunto: IPython 0.13.1 with Notebook and Qt console working on smartphone Data: Fri, 01 Feb 2013 01:55:20 -0200 De: Roberto Colistete Jr. Para: IPython developers list I have also tested my Nokia N9 running IPython Notebook server and web clients on many devices : PC's, Android tablets, Maemo 5/Nokia N900 smartphone, etc. It works very well. As Nokia N9 has WiFi hotspot, we can have a full IPython 0.13.1 in your pocket, accessible to any computer/tablet/smartphone without IPython but with good web browser (with websockets and MathJax support). -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IPython_SymPy_UbuntuTouch.jpg Type: image/jpeg Size: 82922 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IPython_SymPyPlotting_UbuntuTouch.jpg Type: image/jpeg Size: 94249 bytes Desc: not available URL: From hans_meine at gmx.net Wed May 29 03:53:30 2013 From: hans_meine at gmx.net (Hans Meine) Date: Wed, 29 May 2013 09:53:30 +0200 Subject: [IPython-dev] cell magics In-Reply-To: <51200308.2070502@creativetrax.com> References: <511EFB2E.5080201@creativetrax.com> <51200308.2070502@creativetrax.com> Message-ID: <8D9E2F49-5C6D-4837-AC07-F1BAE42F9D65@gmx.net> Hi Jason, let me answer from my perspective, too: It all boils down to the fact that magics are exactly *not* Python. (I guess) They're called magics because they "magically" transform into valid, longer python code. Their whole point is not to perform something that's not possible without magics, but to offer a really short, easy to type (-> accessible) way to perform some action. The magics I use most often are %run, %debug, %history, %pylab, %gui and %cpaste (in the terminal), in the past also %store and %macro. They allow me to do stuff interactively really quickly, without first getting references to some responsible objects or namespaces. Only very seldomly I use the fact that I can use them in .ipy files to be run through IPython, and that's only for short-lived files that reproduce some debugging session. Am 16.02.2013 um 23:07 schrieb Jason Grout: > With our proposal, % could still just complete with registered > string decorators (with even the exact same registration system, so you > can register things outside of the user's namespace). The difference is > that if I wanted to run a string decorator that wasn't in the registered > namespace, but I had just defined in my user namespace, I wouldn't have > to pollute the registered namespace for my one invocation. I could just > run %my_function directly. I think this is particularly important > because the registered % namespace is a flat list of names, so it's not > a very organized namespace (which is exactly a problem you have with > Sage's philosophy, ironically :). With magics, I don't think about namespaces. There shouldn't be too many of them anyhow. > But the real issue here is that IPython has two different syntaxes for > the users to invoke string decorators. That means that I, as a user, > constantly have to remember if a command is one, or the other, or both, > because the very first two characters are different between the two. > For example, just now I typed %ru, and I see from the completions > that ruby is only a cell decorator. So now I have to backspace and put > that extra % in there. ? I appreciate the thought you put into this argument, but to me this is a non-issue. You can always come up with cases where you don't remember the name of something and need to backspace. For me, cell magics are clearly distinct from the others, and I would never look for %ruby. ;-) > With our proposal, these issues go away. All string decorators are > invoked with %. The difference between a line or cell decorator is > determined by whether or not there is a string on the line (just as the > difference between ? Here, you make two assumptions that do not hold: 1) %magics always take arguments. Many of them perform important (often, listing) actions without arguments, and with your proposal, I would have to at least press enter twice in the terminal. 2) %%cell_magics don't take arguments on the same line. You were already given counterexamples for that one. > (a) users are comfortable with bash-like syntax. With the rising > popularity of IPython, and especially with the rising popularity of the > notebook, I think we're going to see more and more non-unix users that > see the bash-like syntax as one more *new* thing to learn, rather than > something that is already familiar in a different context. In fact, I > look at the %timeit syntax for example, and I have to try to remember > what the options are each time. Isn't that the case with most API? Just use '%timeit?' and be happy with IPython. :-) > Compare: > > %timeit -r5 2+3 > > %timeit(runs=5) 2+3 > > I think it's pretty clear which statement is more readable. This focus > on readability over brevity (remember, "Readability counts") is part of > why python is so good in general. Readibility does count (and I advocate that _a lot_), but not for the commands I type in an IPython console. There, I want to type as fast as possible, so brevity trumps. (Also, lack of parentheses and commas is a big plus for typing, depending on your keyboard layout at least.) > I look at the %R option syntax, and I absolutely *have* to go to the > help to see what is going on. Even worse are the lines below!! :-) (Hint: I don't speak R.) As soon as you put magics in a permanent document (such as the notebook), you are interested in --long option names, of course. Anyway, I wonder how many %magics and options you will realistically use in notebooks. (Many of the aforementioned %magics don't really belong there.) Best regards Hans From dave.hirschfeld at gmail.com Wed May 29 06:47:52 2013 From: dave.hirschfeld at gmail.com (Dave Hirschfeld) Date: Wed, 29 May 2013 10:47:52 +0000 (UTC) Subject: [IPython-dev] Logging output garbled Message-ID: The following (expected) exception in my console: In [26]: rc[2].get('x') --------------------------------------------------------------------------- NameError Traceback (most recent call last) in () c:\dev\code\ipython\IPython\parallel\util.py in _pull(keys) 243 return map(lambda key: eval(key, globals()), keys) 244 else: --> 245 return eval(keys, globals()) 246 247 @interactive in () NameError: name 'x' is not defined ...gets logged by the engine as follows: C:\Users\dhirschfeld>ipengine 2013-05-29 11:38:22.798 [IPEngineApp] Using existing profile dir: u'C:\\Users\\dhirschfeld\\.ipython\\profile_default' 2013-05-29 11:38:22.802 [IPEngineApp] Loading url_file u'C:\\Users\\dhirschfeld\\.ipython\\profile_default\\security\\ipcontroller- engine.json' 2013-05-29 11:38:22.819 [IPEngineApp] Registering with controller at tcp://127.0.0.1:54414 2013-05-29 11:38:22.977 [IPEngineApp] Starting to monitor the heartbeat signal from the hub every 3010 ms. 2013-05-29 11:38:22.983 [IPEngineApp] Using existing profile dir: u'C:\\Users\\dhirschfeld\\.ipython\\profile_default' 2013-05-29 11:38:22.989 [IPEngineApp] Completed registration with id 2 2013-05-29 11:38:34.990 [IPEngineApp] Exception in apply request: ?[1;31m--------------------------------------------------------------------- ------?[0m ?[1;31mNameError?[0m Traceback (most recent call last) ?[1;32m?[0m in ?[0;36m?[1;34m()?[0m ?[1;32mc:\dev\code\ipython\IPython\parallel\util.py?[0m in ?[0;36m_pull?[1;34m(keys)?[0m ?[0;32m 243?[0m ?[1;32mreturn?[0m ?[0mmap?[0m?[1;33m(?[0m?[1;32mlambda?[0m ?[0mkey?[0m?[1;33m:?[0m ?[0meval?[0m?[1;33m(?[0m?[0mkey?[0m?[1;33m,?[0m ?[0mglobals?[0m?[1;33m(?[0m?[1;33m)?[0m?[1;33m)?[0m?[1;33m,?[0m ?[0mkeys?[0m?[1;33m)?[0m?[1;33m?[0m?[0m ?[0;32m 244?[0m ?[1;32melse?[0m?[1;33m:?[0m?[1;33m?[0m?[0m ?[1;32m--> 245?[1;33m ?[1;32mreturn?[0m ?[0meval?[0m?[1;33m(?[0m?[0mkeys?[0m?[1;33m,?[0m ?[0mglobals?[0m?[1;33m(?[0m?[1;33m)?[0m?[1;33m)?[0m?[1;33m?[0m?[0m ?[0m?[0;32m 246?[0m ?[1;33m?[0m?[0m ?[0;32m 247?[0m ?[1;33m@?[0m?[0minteractive?[0m?[1;33m?[0m?[0m ?[1;32m?[0m in ?[0;36m?[1;34m()?[0m ?[1;31mNameError?[0m: name 'x' is not defined I assume the mess are ansi escape codes? They do make it slightly hard to debug problems using the logs (which are very useful) so I'm wondering if there is a way to prevent this happening? Thanks, Dave From dave.hirschfeld at gmail.com Wed May 29 07:02:42 2013 From: dave.hirschfeld at gmail.com (Dave Hirschfeld) Date: Wed, 29 May 2013 11:02:42 +0000 (UTC) Subject: [IPython-dev] Debugging parallel engines Message-ID: I'm running a local cluster and would like to debug an error on one of the engines. With the notebook it's very handy to start up a qtconsole, connecting to the currently running notebook kernel as follows: Notebook log message: 2013-05-29 11:49:08.684 [NotebookApp] Kernel started: 4008d184-2b6f-4a8f-9447- f435c33e0abf Command to connect a qtconsole to the running kernel: ipython qtconsole --existing=kernel-4008d184-2b6f-4a8f-9447-f435c33e0abf.json When starting an engine however no message is printed stating which file to use to connect to it. Is it possible to connect a qtconsole to a currently running parallel engine instance? Thanks, Dave From benjaminrk at gmail.com Wed May 29 14:08:20 2013 From: benjaminrk at gmail.com (MinRK) Date: Wed, 29 May 2013 11:08:20 -0700 Subject: [IPython-dev] Debugging parallel engines In-Reply-To: References: Message-ID: You can do this on an engine as well, you just have to tell the engine(s) to listen for connections by calling `parallel.bind_kernel()` on them http://nbviewer.ipython.org/5672387 On Wed, May 29, 2013 at 4:02 AM, Dave Hirschfeld wrote: > I'm running a local cluster and would like to debug an error on one of the > engines. With the notebook it's very handy to start up a qtconsole, > connecting > to the currently running notebook kernel as follows: > > Notebook log message: > 2013-05-29 11:49:08.684 [NotebookApp] Kernel started: > 4008d184-2b6f-4a8f-9447- > f435c33e0abf > > Command to connect a qtconsole to the running kernel: > ipython qtconsole > --existing=kernel-4008d184-2b6f-4a8f-9447-f435c33e0abf.json > > > When starting an engine however no message is printed stating which file to > use to connect to it. > > Is it possible to connect a qtconsole to a currently running parallel > engine > instance? > > Thanks, > Dave > > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Wed May 29 14:08:20 2013 From: benjaminrk at gmail.com (MinRK) Date: Wed, 29 May 2013 11:08:20 -0700 Subject: [IPython-dev] Debugging parallel engines In-Reply-To: References: Message-ID: You can do this on an engine as well, you just have to tell the engine(s) to listen for connections by calling `parallel.bind_kernel()` on them http://nbviewer.ipython.org/5672387 On Wed, May 29, 2013 at 4:02 AM, Dave Hirschfeld wrote: > I'm running a local cluster and would like to debug an error on one of the > engines. With the notebook it's very handy to start up a qtconsole, > connecting > to the currently running notebook kernel as follows: > > Notebook log message: > 2013-05-29 11:49:08.684 [NotebookApp] Kernel started: > 4008d184-2b6f-4a8f-9447- > f435c33e0abf > > Command to connect a qtconsole to the running kernel: > ipython qtconsole > --existing=kernel-4008d184-2b6f-4a8f-9447-f435c33e0abf.json > > > When starting an engine however no message is printed stating which file to > use to connect to it. > > Is it possible to connect a qtconsole to a currently running parallel > engine > instance? > > Thanks, > Dave > > > > _______________________________________________ > 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 Wed May 29 21:11:49 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 29 May 2013 18:11:49 -0700 Subject: [IPython-dev] Reminder: lab meeting on air tomorrow, 10am PST Message-ID: Hi folks, just a reminder we'll have our regular 'lab meeting on air' tomorrow. I think Brian can't make it as he's traveling, but we should move forward in general even when some people aren't available (myself included) to keep the momentum. If there's anything specific you have in mind, feel free to edit the agenda file: https://hackpad.com/IPython-dev-meetings-6wTSjJt7TZK See you there! f -- Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail From dave.hirschfeld at gmail.com Thu May 30 04:33:51 2013 From: dave.hirschfeld at gmail.com (Dave Hirschfeld) Date: Thu, 30 May 2013 08:33:51 +0000 (UTC) Subject: [IPython-dev] Debugging parallel engines References: Message-ID: MinRK gmail.com> writes: > > You can do this on an engine as well, you just have to tell the engine(s) to listen for connections by calling `parallel.bind_kernel()` on them > > http://nbviewer.ipython.org/5672387 > > Is it possible to connect a qtconsole to a currently running parallel engine > instance? > Thanks, > Dave Brilliant, thanks - that's *extremely* useful for debugging! %qtconsole doesn't appear to work on windows - is this a known issue? >>> res = rc[0].execute("%qtconsole") >>> res.display_outputs() ERROR: Could not start qtconsole: ValueError('close_fds is not supported on Windows platforms if you redirect stdin/stdout/stderr',) >>> It's not a problem because when you call `bind_kernel` the engine tells you the name of the json file to connect to in the logs and you can then start a qtconsole from the command line with the --existing switch 2013-05-30 09:26:10.615 [IPEngineApp] Opening ports for direct connections as an IPython kernel 2013-05-30 09:26:10.638 [IPEngineApp] To connect another client to this kernel, use: 2013-05-30 09:26:10.638 [IPEngineApp] --existing kernel-9248.json To connect another client to this kernel, use: --existing kernel-9248.json Thanks for your help!... -Dave From jorgen.stenarson at kroywen.se Thu May 30 12:06:48 2013 From: jorgen.stenarson at kroywen.se (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Thu, 30 May 2013 18:06:48 +0200 Subject: [IPython-dev] Reminder: lab meeting on air tomorrow, 10am PST In-Reply-To: References: Message-ID: <51A77918.2030108@kroywen.se> Fernando Perez skrev 2013-05-30 03:11: > Hi folks, > > just a reminder we'll have our regular 'lab meeting on air' tomorrow. > I think Brian can't make it as he's traveling, but we should move > forward in general even when some people aren't available (myself > included) to keep the momentum. > > If there's anything specific you have in mind, feel free to edit the > agenda file: > > https://hackpad.com/IPython-dev-meetings-6wTSjJt7TZK > At what time is the meeting? I could not find that on the hackpad page. /J?rgen From jorgen.stenarson at kroywen.se Thu May 30 12:09:54 2013 From: jorgen.stenarson at kroywen.se (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Thu, 30 May 2013 18:09:54 +0200 Subject: [IPython-dev] Reminder: lab meeting on air tomorrow, 10am PST In-Reply-To: <51A77918.2030108@kroywen.se> References: <51A77918.2030108@kroywen.se> Message-ID: <51A779D2.1080608@kroywen.se> J?rgen Stenarson skrev 2013-05-30 18:06: > Fernando Perez skrev 2013-05-30 03:11: >> Hi folks, >> >> just a reminder we'll have our regular 'lab meeting on air' tomorrow. >> I think Brian can't make it as he's traveling, but we should move >> forward in general even when some people aren't available (myself >> included) to keep the momentum. >> >> If there's anything specific you have in mind, feel free to edit the >> agenda file: >> >> https://hackpad.com/IPython-dev-meetings-6wTSjJt7TZK >> > > At what time is the meeting? I could not find that on the hackpad page. > Oops I missed it in the subject of Fernando's mail. It would be good to have it on the hackpad page, especially if it will always be at the same time. /J?rgen