From robert.kern at gmail.com Thu Dec 1 09:23:05 2011 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 01 Dec 2011 14:23:05 +0000 Subject: [IPython-dev] Inprocess kernel for Qt frontend Message-ID: With a bit of hacking and code duplication, I managed to get the IPythonWidget Qt frontend to talk to an inprocess kernel. https://gist.github.com/1416977 I originally did this work against an older version of IPython (i.e. when we used names like XReqSocketChannel) but haven't been able to release it publicly until now. I have updated it to run off of master. I may have missed some necessary changes. I also may have missed some opportunities; could we use the BlockingKernelManager to do the same thing now? I certainly don't want this code integrated into IPython as-is (hence a gist rather than a pull request), but it exists as a workaround for people who do want to embed an IPython interpreter into their Qt application. Is there a way we can extend the IPython API to support this more directly so one does not have to duplicate code the way I did? -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco From fperez.net at gmail.com Thu Dec 1 13:05:46 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 1 Dec 2011 10:05:46 -0800 Subject: [IPython-dev] Inprocess kernel for Qt frontend In-Reply-To: References: Message-ID: Hey Robert, On Thu, Dec 1, 2011 at 6:23 AM, Robert Kern wrote: > With a bit of hacking and code duplication, I managed to get the IPythonWidget > Qt frontend to talk to an inprocess kernel. > > ? https://gist.github.com/1416977 > > I originally did this work against an older version of IPython (i.e. when we > used names like XReqSocketChannel) but haven't been able to release it publicly > until now. I have updated it to run off of master. I may have missed some > necessary changes. I also may have missed some opportunities; could we use the > BlockingKernelManager to do the same thing now? > > I certainly don't want this code integrated into IPython as-is (hence a gist > rather than a pull request), but it exists as a workaround for people who do > want to embed an IPython interpreter into their Qt application. Is there a way > we can extend the IPython API to support this more directly so one does not have > to duplicate code the way I did? That's certainly our intent, and I have a sketch in my head of how it needs to be done, unfortunately no time right now to really work on it (my available ipython time is fully consumed with keeping up with the PR flow to get 0.12 released, sorry). But I've made this an issue we can track moving forward: http://mail.scipy.org/pipermail/ipython-dev/2011-December/008456.html hopefully soon we can clean this up, it would be great to get 0.13 out with a solid implementation of this idea that can be shared by the qt console and terminal ones without code duplication. That is one of the major milestones we need to achieve before considering ipython 1.0. Yes, I've said it, there will eventually be a 1.0 :) Thanks for getting this moving! Cheers, f From fperez.net at gmail.com Thu Dec 1 17:53:15 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 1 Dec 2011 14:53:15 -0800 Subject: [IPython-dev] Heads-up: test suite fails on Ubuntu 11.10 if system matplotlib is installed, it's an ubuntu bug. Message-ID: Just so that none of you waste your time, if you install the system matplotlib package, the test suite fails, with KnownFailure tests being reported as errors. The fault is the ubuntu matplotlib package (the *ubuntu* package, not matplotlib itself and not even the upstream Debian one, the issue is specific to the ubuntu repackaging). Bug report here: https://bugs.launchpad.net/ubuntu/+source/matplotlib/+bug/871176 The solution is to edit the file /usr/share/pyshared/matplotlib-1.0.1.egg-info/entry_points.txt and comment it out (it's only two lines). You can also just empty it out or remove it, I guess. The bug is insanely hard to track down, and it happens even if you completely override both the system matplotlib and nose with a personal install of both, as this buggy global plugin is still pulled in. Since both Stefan and I wasted hours on this one, I figured I'd warn people... Cheers, f From fperez.net at gmail.com Tue Dec 6 02:48:45 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 5 Dec 2011 23:48:45 -0800 Subject: [IPython-dev] Should we disable autocall by default from now on? In-Reply-To: References: Message-ID: Hi folks, On Tue, Nov 29, 2011 at 11:07 PM, Fernando Perez wrote: > So I'd like to hear some feedback, as we're getting ready to put 0.12 > out the door soon... Despite the fact that I'm one of those people who think that autocall is actually a very nice feature, I think we had very convincing arguments about this being often confusing to newcomers. I've changed the default to off now: https://github.com/ipython/ipython/commit/a7d609a4520a68856d255221ec57a24944700bce and just committed more doc updates where autocall was mentioned to reflect this. Thomas, if you'd like the autocall-safe mode as well, it can certainly be added, so feel free to put up a PR for that. But it seems to me that Min, Thomas and I are better off simply configuring this the way we want it in our personal profiles, so that the new user experience leads to less surprises (and so we have less of the weird bugs that do pop up every now and then due to this). Thanks to everyone for the detailed feedback. It may seem a bit silly to obsess so much over such a small point, but I'm glad you guys care enough to discuss it :) Best, f From fperez.net at gmail.com Tue Dec 6 06:25:35 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 6 Dec 2011 03:25:35 -0800 Subject: [IPython-dev] The homestretch for 0.12... Message-ID: Hi folks, we haven't had too many problem reports with the 0.12 beta, but we have had a ton of recent small contributions. This is is great, in that we greatly appreciate new code, but now we need to spend a bit of time stabilizing things and closing what we can, if we want a solid 0.12 release that also goes out real soon. I've gone over the issues list and bumped to 0.13 everything that was not likely to be doable soon (old issues, too complex, too delicate to do now, etc). This is what's left (only 12!): https://github.com/ipython/ipython/issues/?milestone=6&sort=created&direction=desc&state=open We also have a few PRs open, 9 at the moment: https://github.com/ipython/ipython/pulls At this point, anyone who can lend a hand with any of the above, it would be very much appreciated. In particular, we do have one very nasty blocker and we're not quite sure what's going on or how to best fix it: https://github.com/ipython/ipython/issues/481 Major brownie points for anyone who helps us make progress with that. So let's focus our energies on the remaining things, and we should be able to cut an RC by week's end... Cheers, f ps - to put things in perspective, the 0.11 release had 511 github issues closed in ~16 months, and in the last 4 months since 0.11 we've closed a total of 442! (214 pull requests and 228 regular ones). It seems our predictions of 0.11 really providing a more approachable project were true :) From fperez.net at gmail.com Tue Dec 6 12:27:03 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 6 Dec 2011 09:27:03 -0800 Subject: [IPython-dev] Heads-up: little utility in tools/, 'git mrb' for merging remote branches Message-ID: Hi all, I committed this little utility I recently wrote and that others can find useful: https://github.com/ipython/ipython/blob/master/tools/git-mrb I find myself very often testing remote branches from the same regular contributors, so rather than copy/pasting github's instructions, I made this that lets me simply highlight the branch name and type git mrb remote:branchname # this last part copy/pasted from the PR page For example, since I have Carreau's fork as a remote, I can do for https://github.com/ipython/ipython/pull/1108: git mrb Carreau:completer-usability-2 and it automatically fetches, merges (steps 1-2 of the merge instructions) and then waits for me to test things out. It asks whether I want to delete the branch and go back to master or to leave it alone. I delete it if the tests don't pass, if there's a problem or if I decide to do the merge with the github blue button (which simplifies the editing of the merge commit message). Possible enhancements: - to support also working directly with a PR number - auto-detecting that if I don't have a remote for the necessary branch, it can go and fetch from github that one time, as right now it's only useful for remotes you are already tracking (I've added the remotes of frequent contributors for this reason). But even as-is, I've found it to save me time as it makes the review process quicker by pretty much automating the manual parts. Probably more than the time itself of the actions, it's the more fluid process it enables that I like, as I don't have to stop to do clunky manual operations. Cheers, f From fperez.net at gmail.com Tue Dec 6 15:18:58 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 6 Dec 2011 12:18:58 -0800 Subject: [IPython-dev] New console frontend, testing needed.. Message-ID: Hi all, We have finally landed the two-process terminal frontend from https://github.com/ipython/ipython/pull/864 (which itself built on two previous PRs, #433 and #708). This adds a terminal-based frontend which you can start with ipython console it should feel pretty much like 'plain old' ipython, and supports --pylab, profiles and all the same options. But this one actually runs the kernel in a separate process, which means it can attach to kernels started by the Qt console or by the notebook. If you're willing to test it and let us know of any problems, we'd greatly appreciate it. Those of you used to running from git need only update master. If you want a static download, github conveniently provides a download of master in zip and tar.gz formats: https://github.com/ipython/ipython/zipball/master https://github.com/ipython/ipython/tarball/master A big thank you to those who put in all the effort to make this happen, starting with Omar Zapata (this was the continuation of his Summer of Code effort last year) and Paul Ivanov who built on top of Omar's work. Cheers, f From ellisonbg at gmail.com Tue Dec 6 16:01:25 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Tue, 6 Dec 2011 13:01:25 -0800 Subject: [IPython-dev] New console frontend, testing needed.. In-Reply-To: References: Message-ID: Fantastic! Great work everyone! Cheers, Brian On Tue, Dec 6, 2011 at 12:18 PM, Fernando Perez wrote: > Hi all, > > We have finally landed the two-process terminal frontend from > > https://github.com/ipython/ipython/pull/864 > > (which itself built on two previous PRs, #433 and #708). ?This adds a > terminal-based frontend which you can start with > > ipython console > > it should feel pretty much like 'plain old' ipython, and supports > --pylab, profiles and all the same options. ?But this one actually > runs the kernel in a separate process, which means it can attach to > kernels started by the Qt console or by the notebook. > > If you're willing to test it and let us know of any problems, we'd > greatly appreciate it. ?Those of you used to running from git need > only update master. If you want a static download, github conveniently > provides a download of master in zip and tar.gz formats: > > https://github.com/ipython/ipython/zipball/master > https://github.com/ipython/ipython/tarball/master > > A big thank you to those who put in all the effort to make this > happen, starting with Omar Zapata (this was the continuation of his > Summer of Code effort last year) and Paul Ivanov who built on top of > Omar's work. > > 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 Tue Dec 6 16:07:51 2011 From: benjaminrk at gmail.com (MinRK) Date: Tue, 6 Dec 2011 13:07:51 -0800 Subject: [IPython-dev] New console frontend, testing needed.. In-Reply-To: References: Message-ID: On Tue, Dec 6, 2011 at 12:18, Fernando Perez wrote: > Hi all, > > We have finally landed the two-process terminal frontend from > > https://github.com/ipython/ipython/pull/864 > > (which itself built on two previous PRs, #433 and #708). This adds a > terminal-based frontend which you can start with > > ipython console > > it should feel pretty much like 'plain old' ipython, and supports > --pylab, profiles and all the same options. But this one actually > runs the kernel in a separate process, which means it can attach to > kernels started by the Qt console or by the notebook. > I should note the principal shortcomings of this frontend (that I know of): * Ctrl-C is wonky in pylab mode, because the sigint is still received in the subprocess * There is no shortcut for killing the kernel yet, but a simple `os._exit(0)` works to restart the kernel. -MiNRK > > If you're willing to test it and let us know of any problems, we'd > greatly appreciate it. Those of you used to running from git need > only update master. If you want a static download, github conveniently > provides a download of master in zip and tar.gz formats: > > https://github.com/ipython/ipython/zipball/master > https://github.com/ipython/ipython/tarball/master > > A big thank you to those who put in all the effort to make this > happen, starting with Omar Zapata (this was the continuation of his > Summer of Code effort last year) and Paul Ivanov who built on top of > Omar's work. > > 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 kiranbkrishna at gmail.com Thu Dec 8 00:11:10 2011 From: kiranbkrishna at gmail.com (Kiran Balakrishnan) Date: Thu, 8 Dec 2011 10:41:10 +0530 Subject: [IPython-dev] (no subject) Message-ID: Hi all , I am a new developer interested in IPython. Last day I tried out running Ipyhton from the Eclipse console.Eclipse was set up to execute python programs using the PyDev. But When i ran IPython i found the output was in some unreadable format.(please see the attached screenshot ). Some characters where printed out as garbage values.Is it because eclipse not supporting or using unicode encoding???? is there any way to correct it. I think Eclips ereally is a cool development environment , fixing this issue may help newbie developers (like me) to contribue more effectively . Regards -- Kiran Balakrishnan -------------- next part -------------- A non-text attachment was scrubbed... Name: eclipse console.png Type: image/png Size: 58777 bytes Desc: not available URL: From benjaminrk at gmail.com Thu Dec 8 00:28:54 2011 From: benjaminrk at gmail.com (MinRK) Date: Wed, 7 Dec 2011 21:28:54 -0800 Subject: [IPython-dev] (no subject) In-Reply-To: References: Message-ID: Those are the ANSI color escapes, which presumably your eclipse console doesn't support. Turning off the colors should solve the issue. If you have control over startup args, then you can add `--colors=NoColor` Or, you can set this as the default behavior in a config file. In a shell: > ipython profile create edit the ipython_profile.py that it created, and uncomment the line containing 'TerminalInteractiveShell.colors', so it says: c.TerminalInteractiveShell.colors = 'NoColor' Or, in a pinch, you can to `%colors nocolor` after starting IPython to turn off the coloring. -MinRK On Wed, Dec 7, 2011 at 21:11, Kiran Balakrishnan wrote: > Hi all , > I am a new developer interested in IPython. > Last day I tried out running Ipyhton from the Eclipse console.Eclipse > was set up to execute python programs using the PyDev. But When i ran > IPython i found the output was in some unreadable format.(please see > the attached screenshot ). > Some characters where printed out as garbage values.Is it because > eclipse not supporting or using unicode encoding???? is there any way > to correct it. > > I think Eclips ereally is a cool development environment , fixing this > issue may help newbie developers (like me) to contribue more > effectively . > > Regards > -- > Kiran Balakrishnan > > _______________________________________________ > 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 hans_meine at gmx.net Thu Dec 8 04:29:21 2011 From: hans_meine at gmx.net (Hans Meine) Date: Thu, 08 Dec 2011 10:29:21 +0100 Subject: [IPython-dev] Should we disable autocall by default from now on? In-Reply-To: References: Message-ID: <1620433.JRbgOOHdye@hmeine-pc> Am Mittwoch, 30. November 2011, 22:56:05 schrieb Thomas Kluyver: > [?] With the notebook, I imagine we > could literally rewrite the cell to "plot(e1)". To my mind, that would > clearly say "this is the right way to do it, but I knew what you meant." That?s a really nice idea. It also fixes one of autocall?s problem, namely that it becomes dangerous to copy-paste code into standard .py files. My personal impression with autocall when I first heard about it was "wow - that?s useful", but over the years, I have only used it for very few use cases, i.e. for a small set of functions. Some example were: In [1]: ,execfile pythonic.py In [1]: reload mymod After some months, I was so used to this syntax, that I even started to think that the latter would call a %reload magic (yes, in spite of the line telling me about the expansion). I guess the confusion would not have arised if I used autocall for more than this tiny set of functions. However, even though I am a lazy typer, I believe I may be able to /type faster than I would have to think/ about whether the thing I want to achieve can be typed faster/shorter with autocall. (Plus, I am now using the German "Neo" layout which has /all/ kinds of parentheses at your immediate fingertips. ;-p ) So, I would question the overall benefit of autocall not only for beginners, at least in a standard terminal. Ciao, Hans From hans_meine at gmx.net Thu Dec 8 04:43:26 2011 From: hans_meine at gmx.net (Hans Meine) Date: Thu, 08 Dec 2011 10:43:26 +0100 Subject: [IPython-dev] Should we disable autocall by default from now on? In-Reply-To: References: Message-ID: <3206869.ONNsygYv33@hmeine-pc> I want to propose some changes (my previous mail got a little bit long, so I start over now): Am Mittwoch, 30. November 2011, 22:56:05 schrieb Thomas Kluyver: > I think this is a technical issue as much as anything. The terminal shell > clearly shows the rewritten command, and it is sent as a payload over ZMQ, > but AFAIK both of our frontends ignore it. This should be fixed; indeed I do not see the expanded form anymore. > With the notebook, I imagine we > could literally rewrite the cell to "plot(e1)". That would be great. In fact, I would propose to do this in all frontends: - In graphical terminals (Qt, Notebook, Wx, ...), it should be rewritten in-place. - In the standard terminal, /it should be rewritten in history/ at least. Note that the latter can and should be done independent of other expansions (e.g. magics); I recall the discussion in which we (more or less) all agreed that history should give you the raw command (e.g. a magic) instead of revealing implementation details. OTOH, I think with autocall, this could be better the other way round: a) when copy-pasting from the history into .py files b) when recalling and modifying the command into a more complex form not supported by autocall c) with %recall or %macro and later copying into .py files (Yes, c) is probably subsumed by a) ) What do you think? Ciao, Hans From takowl at gmail.com Thu Dec 8 06:53:07 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Thu, 8 Dec 2011 11:53:07 +0000 Subject: [IPython-dev] Should we disable autocall by default from now on? In-Reply-To: <3206869.ONNsygYv33@hmeine-pc> References: <3206869.ONNsygYv33@hmeine-pc> Message-ID: On 8 December 2011 09:43, Hans Meine wrote: > - In the standard terminal, /it should be rewritten in history/ at least. > > Note that the latter can and should be done independent of other expansions > (e.g. magics); I recall the discussion in which we (more or less) all > agreed > that history should give you the raw command (e.g. a magic) instead of > revealing implementation details. > Just to summarise what currently happens with history: we store 'raw' and 'translated' history, where translated history should always be syntactically valid Python code. Autocalling, magics, system commands and aliases are all translated. Raw history is naturally exactly what the user entered. For most things (%hist, %recall, %rerun, %pastebin and readline history) we default to using the raw history. %macro, %edit and %save use translated history. What you're proposing would fit in as a sort of 'preferred' history, picking raw or translated history depending on the contents. I can see how that would be useful, but on the other hand I'm not sure that the benefits merit the added complexity, especially now that autocall is off by default. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.buchs at gmail.com Fri Dec 9 15:02:47 2011 From: kevin.buchs at gmail.com (Kevin Buchs) Date: Fri, 9 Dec 2011 14:02:47 -0600 Subject: [IPython-dev] edit not executing on Windows Message-ID: I have worked through the configuration so I might call emacs from a server for my editor on MS Windows. However, I noted that the edited code is not executed, though I have saved it. I am running the 0.12 beta. Here is the snippet from my ipython_qtconsole_config.py: import sys if sys.platform == 'win32': c.IPythonWidget.editor = 'c:/apps/emacs/bin/emacsclient.exe -a c:/apps/emacs/bin/runemacs.exe' else: c.IPythonWidget.editor = 'emacsclient -a emacs' There have been times in the past when I wished there was a way to invoke the editor without executing the results, but now it seems to be behaving that way all the time. Have I missed something? -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Fri Dec 9 15:06:33 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Fri, 9 Dec 2011 20:06:33 +0000 Subject: [IPython-dev] edit not executing on Windows In-Reply-To: References: Message-ID: On 9 December 2011 20:02, Kevin Buchs wrote: > There have been times in the past when I wished there was a way to invoke > the editor without executing the results, but now it seems to be behaving > that way all the time. Because of the slightly different model with a GUI editor (which often won't block the parent process), we decided not to automatically execute the code in the Qt console. There was some discussion about making this the default in the terminal as well, but I don't think we changed that (yet). Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Sat Dec 10 17:27:53 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 10 Dec 2011 14:27:53 -0800 Subject: [IPython-dev] Victims of our own success, change of strategy needed to get 0.12 released... Message-ID: Hi folks, Since we have a fairly small team, I've always tried to avoid having separate release branches, as that requires later merging those back into the main development line and keeping for a while two truly parallel lines of work. Instead, we've tended to simply stabilize master enough to release it and simply continue forward. But that's just not going to work this time around: we're now victims of our own success, and the stream of contributions is arriving faster than we can safely merge them and see their impact for a release. Serves us well for refactoring the code to be more modular, testable and approachable, I guess :) Now, I do *not* want to cut the enthusiastic contributions we're getting, but we do need to have a period where we test a frozen version on top of which we strictly apply *only fixes* and no actual new code. Basically we need to move to what many projects do already with a release branch that is frozen while master continues evolving, and 0.12 will released from that release branch. So what I'd like to do is to triage, from our list of currently 16 open PRs, what do we actually want to go into 0.12. After that list is established, we'll try to merge *only those* and will create an actual 0.12 branch to further stabilize them. New PRs can be directed to master, but those we'll either merge right away (if they are done) or we'll retarget them to a 0.12 branch we'll push to the main repo. So let me know which ones you think are either nearly ready or important enough to target them for 0.12, and we'll do this. Cheers, f From benjaminrk at gmail.com Sat Dec 10 19:02:25 2011 From: benjaminrk at gmail.com (MinRK) Date: Sat, 10 Dec 2011 16:02:25 -0800 Subject: [IPython-dev] Victims of our own success, change of strategy needed to get 0.12 released... In-Reply-To: References: Message-ID: A summary of the ones currently outstanding: General: 811 (OSError): incomplete, not to be merged 1073 (storemagic/default extensions): Proposes extra work to move extensions to Shell from App. I suggest letting the extra work wait until after release, and merge this one as-is. 1116 (shlex unicode): BLOCKER I believe this is ready as-is. It needs a rebase, because it's based on a branch that was already merged via cherry-pick, but that can easily be done at merge time. I'd be happy doing this right now. 1120 (vim-ipython): This is Paul's, and doesn't touch the core. We should just merge it, wherever it is, when we cut the RC, as Paul describes in the PR. 1128 (pylab start menu and profile): BLOCKER Minor issue and easy fix, a conversation is all we need. Since we ship a broken button, it should be merged. I think based on Fernando's lates comment on the mailing list, the recommendation is to remove the pylab profile that we ship altogether, and make the start menu item just do `--pylab`. 1129 (unified setup.py): Looks perfectly fine to me, but I am wary of a significant change to setup.py immediately before release. I would let this one slide, and merge immediately after release. 1130 (arg_split / ValueError): I'd let this one slip. %timeit is the principally improved magic, and this particular fix could have unforeseen implications. The right answer should probably be that some/all magics *do not* use arg_split, which is really for something else, instead using their own function that behaves appropriately. 1137 (MPIExec->MPI rename): Simple rename of a few launchers, so that the MPILauncher names are more symmetrical with SGE/MPI/SSH/PBS/LSF. I would like this in 0.12, simply because it means the old names won't need to survive in a deprecated form for as long. 1138 (symlink): One line fix in a test, I'll merge it now. 1140 (embed): BLOCKER This one is really important, because part of embedding just doesn't work right now. It could be ready as-is, I'm just not familiar enough with the relevant code to be able to tell. Notebook related: 873 (ReST): incomplete, not to be merged 1079 (login/logout buttons in the notebook): The principal issue this fixes is that no login button is drawn during a read-only view, when login is possible. You must explicitly visit notebook/login in order to login. It is incomplete at this point, and principally a convenience improvement for an uncommon use case. We need not block on it, but it would be nice for users of read-only mode for following along. 1125 (notebook logo): Still ironing out alignment issues. It's an aesthetic improvement, so I wouldn't block on it. 1132 (name field): Principally aesthetic improvement to read-only mode. Looks clean and simple, should be ready for merge after a quick test. 1135 (custom settings to notebook webapp): I think this should be merged. It's tiny and clean, but makes customizing the notebook *much* easier, without requiring write access to the IPython source dir, and is friendlier to environments where serving static files from a source tree is inappropriate. 1139 (notification): Proof of concept, not meant to be merged. In general, we can't wait for the notebook to be perfect, or we won't get 0.12 out for years. QtConsole related: 1122 (IPythonWidget.execute_file): Fixes a quote-escape issue in IPythonWidget.execute_file, a method that is used for nothing at all, as far as I can tell. Looks fine to me, but I don't know why we have the method at all. My reading of the list: blockers: 1116, 1128, 1140 I recommend: 1073, 1120, 1122, 1132, 1135, 1137 should go in if they are finished in time, but shouldn't block: 1079, 1125 recommend pushing to after release: 1129, 1130, 1139 -MinRK On Sat, Dec 10, 2011 at 14:27, Fernando Perez wrote: > Hi folks, > > Since we have a fairly small team, I've always tried to avoid having > separate release branches, as that requires later merging those back > into the main development line and keeping for a while two truly > parallel lines of work. Instead, we've tended to simply stabilize > master enough to release it and simply continue forward. > > But that's just not going to work this time around: we're now victims > of our own success, and the stream of contributions is arriving faster > than we can safely merge them and see their impact for a release. > Serves us well for refactoring the code to be more modular, testable > and approachable, I guess :) > > Now, I do *not* want to cut the enthusiastic contributions we're > getting, but we do need to have a period where we test a frozen > version on top of which we strictly apply *only fixes* and no actual > new code. Basically we need to move to what many projects do already > with a release branch that is frozen while master continues evolving, > and 0.12 will released from that release branch. > > So what I'd like to do is to triage, from our list of currently 16 > open PRs, what do we actually want to go into 0.12. After that list > is established, we'll try to merge *only those* and will create an > actual 0.12 branch to further stabilize them. New PRs can be directed > to master, but those we'll either merge right away (if they are done) > or we'll retarget them to a 0.12 branch we'll push to the main repo. > > So let me know which ones you think are either nearly ready or > important enough to target them for 0.12, and we'll do this. > > 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 takowl at gmail.com Sat Dec 10 19:40:02 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Sun, 11 Dec 2011 00:40:02 +0000 Subject: [IPython-dev] Victims of our own success, change of strategy needed to get 0.12 released... In-Reply-To: References: Message-ID: Commenting on a couple of my own PRs: On 11 December 2011 00:02, MinRK wrote: > 1073 (storemagic/default extensions): > Proposes extra work to move extensions to Shell from App. I suggest > letting the extra work wait until after release, and merge this one as-is. > That sounds fine to me. I'd like to add extensions to the shell so they can be used for more default functionality (anything in the app isn't used when IPython is embedded), but it's not a big deal at the moment. > 1129 (unified setup.py): > Looks perfectly fine to me, but I am wary of a significant change to > setup.py immediately before release. I would let this one slide, and merge > immediately after release. > Not a problem, but in that case I'd like to get a simpler fix for #1119 (start menu shortcuts in Python 3) into 0.12. I'll try to do a PR soon. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Sat Dec 10 20:38:37 2011 From: benjaminrk at gmail.com (MinRK) Date: Sat, 10 Dec 2011 17:38:37 -0800 Subject: [IPython-dev] Victims of our own success, change of strategy needed to get 0.12 released... In-Reply-To: References: Message-ID: Based on Thomas' sharp eyes on #1116, it turns out that it depends on my #1130, which I previously recommended postponing. I have adjusted #1130 to be more conservative, so I am no longer concerned about side effects. Since #1116 is actually serious and depends on it, we should merge them both. -MinRK On Sat, Dec 10, 2011 at 16:40, Thomas Kluyver wrote: > Commenting on a couple of my own PRs: > > > On 11 December 2011 00:02, MinRK wrote: > >> 1073 (storemagic/default extensions): >> Proposes extra work to move extensions to Shell from App. I suggest >> letting the extra work wait until after release, and merge this one as-is. >> > > That sounds fine to me. I'd like to add extensions to the shell so they > can be used for more default functionality (anything in the app isn't used > when IPython is embedded), but it's not a big deal at the moment. > > >> 1129 (unified setup.py): >> Looks perfectly fine to me, but I am wary of a significant change to >> setup.py immediately before release. I would let this one slide, and merge >> immediately after release. >> > > Not a problem, but in that case I'd like to get a simpler fix for #1119 > (start menu shortcuts in Python 3) into 0.12. I'll try to do a PR soon. > > Thanks, > Thomas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Sat Dec 10 20:42:36 2011 From: benjaminrk at gmail.com (MinRK) Date: Sat, 10 Dec 2011 17:42:36 -0800 Subject: [IPython-dev] Victims of our own success, change of strategy needed to get 0.12 released... In-Reply-To: References: Message-ID: On Sat, Dec 10, 2011 at 16:40, Thomas Kluyver wrote: > Commenting on a couple of my own PRs: > > > On 11 December 2011 00:02, MinRK wrote: > >> 1073 (storemagic/default extensions): >> Proposes extra work to move extensions to Shell from App. I suggest >> letting the extra work wait until after release, and merge this one as-is. >> > > That sounds fine to me. I'd like to add extensions to the shell so they > can be used for more default functionality (anything in the app isn't used > when IPython is embedded), but it's not a big deal at the moment. > > >> 1129 (unified setup.py): >> Looks perfectly fine to me, but I am wary of a significant change to >> setup.py immediately before release. I would let this one slide, and merge >> immediately after release. >> > > Not a problem, but in that case I'd like to get a simpler fix for #1119 > (start menu shortcuts in Python 3) into 0.12. I'll try to do a PR soon. > Since the Start Menu shortcuts are for the Windows .exe installer only (right?), I'm fine simply leaving them out of this release. I don't think they are particularly important to more advanced users, which I think is a superset of those running Python 3. > > Thanks, > Thomas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Sat Dec 10 22:48:55 2011 From: benjaminrk at gmail.com (Min RK) Date: Sat, 10 Dec 2011 19:48:55 -0800 Subject: [IPython-dev] Victims of our own success, change of strategy needed to get 0.12 released... In-Reply-To: References: Message-ID: <6C3006FF-6E75-4969-940D-F40ACC994A76@gmail.com> On Dec 10, 2011, at 19:27, Jonathan March wrote: > On Sat, Dec 10, 2011 at 6:02 PM, MinRK wrote: > QtConsole related: > > 1122 (IPythonWidget.execute_file): > Fixes a quote-escape issue in IPythonWidget.execute_file, a method that is used for nothing at all, as far as I can tell. Looks fine to me, but I don't know why we have the method at all. > > This *is* used in some applications which embed a qtconsole widget, though not in the ipython-qtconsole app itself. Okay, that makes sense. > > I recommend: ... 1122... > > Thanks, > Jonathan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Sun Dec 11 06:37:52 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Sun, 11 Dec 2011 11:37:52 +0000 Subject: [IPython-dev] Victims of our own success, change of strategy needed to get 0.12 released... In-Reply-To: References: Message-ID: On 11 December 2011 01:42, MinRK wrote: > Since the Start Menu shortcuts are for the Windows .exe installer only > (right?), I'm fine simply leaving them out of this release. I don't think > they are particularly important to more advanced users, which I think is a > superset of those running Python 3. I don't think it's necessarily only advanced users running Python 3. I see a fair few questions from newcomers who've picked Python 3 to start off with. Whether or not we think that's a good idea, I don't want to put another hurdle in their way when it should be trivially fixable. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.buchs at gmail.com Mon Dec 12 14:46:02 2011 From: kevin.buchs at gmail.com (Kevin Buchs) Date: Mon, 12 Dec 2011 13:46:02 -0600 Subject: [IPython-dev] 0.12 testing: MS Windows terminal history editing Message-ID: I've been working with ipython 0.12 development version for a bit. I just updated my git clone to verify that this problem has not been fixed. History editing in default mode (terminal) on Windows XP is misbehaving. When recalling multi-line commands from history, sometimes the cursor is placed in the middle vertically or at the top vertically and cannot move any further to the right. Other times a line may be chopped off, though it is actually there and when executing it does run. Other problems exist with redrawing and text insertion. See the attached screen shot, where I cut in beginning on a *history -n* output and then *rep*(layed) entry 50 for "In [56]. You can see the underline cursor appear on the top of three lines, out into space on the right side. [image: ipython -pylab_2011-12-12_09-50-16.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ipython -pylab_2011-12-12_09-50-16.png Type: image/png Size: 6024 bytes Desc: not available URL: From jorgen.stenarson at bostream.nu Mon Dec 12 17:49:36 2011 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Mon, 12 Dec 2011 23:49:36 +0100 Subject: [IPython-dev] 0.12 testing: MS Windows terminal history editing In-Reply-To: References: Message-ID: <4EE68500.6040709@bostream.nu> Kevin Buchs skrev 2011-12-12 20:46: > I've been working with ipython 0.12 development version for a bit. I > just updated my git clone to verify that this problem has not been fixed. > > History editing in default mode (terminal) on Windows XP is misbehaving. > When recalling multi-line commands from history, > sometimes the cursor is placed in the middle vertically or at the top > vertically and cannot move any further to the right. Other times a line > may be chopped off, though it is actually there and when executing it > does run. Other problems exist with redrawing and text insertion. > > See the attached screen shot, where I cut in beginning on a *history > -n* output and then *rep*(layed) entry 50 for "In [56]. You can see the > underline cursor appear on the top of three lines, out into space on the > right side. > > ipython -pylab_2011-12-12_09-50-16.png > Your problems are most likely because pyreadline is not designed to handle multiline edits. It is not something I'm personally interested in working on. So unless someone else submits a patch it is unlikely to be implemented in the near future. /J?rgen From benjaminrk at gmail.com Mon Dec 12 18:45:54 2011 From: benjaminrk at gmail.com (MinRK) Date: Mon, 12 Dec 2011 15:45:54 -0800 Subject: [IPython-dev] Victims of our own success, change of strategy needed to get 0.12 released... In-Reply-To: References: Message-ID: After some helpful review, We've got all the serious ones merged, just waiting on: 1140: fixes for embedding 1128: pylab start menu item Both of which could already be finished, but are awaiting confirmation. Then it's just merging Paul's vim-ipython PR wherever it is at the time of RC, and we can merge Stefan's read-only login button improvements if they are finished in time. -MinRK -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Mon Dec 12 19:09:30 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Tue, 13 Dec 2011 00:09:30 +0000 Subject: [IPython-dev] Victims of our own success, change of strategy needed to get 0.12 released... In-Reply-To: References: Message-ID: On 12 December 2011 23:45, MinRK wrote: > 1140: fixes for embedding And I've just merged this one. Besides a bugfix, that restores the backwards compatibility we needed for Debian/Ubuntu. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Mon Dec 12 20:13:51 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 12 Dec 2011 17:13:51 -0800 Subject: [IPython-dev] 0.12 testing: MS Windows terminal history editing In-Reply-To: <4EE68500.6040709@bostream.nu> References: <4EE68500.6040709@bostream.nu> Message-ID: On Mon, Dec 12, 2011 at 2:49 PM, J?rgen Stenarson wrote: > Your problems are most likely because pyreadline is not designed to > handle multiline edits. It is not something I'm personally interested in > working on. So unless someone else submits a patch it is unlikely to be > implemented in the near future. Then we should probably change things to make multiline history false by default on Windows, no? Cheers, f From fperez.net at gmail.com Mon Dec 12 21:02:34 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 12 Dec 2011 18:02:34 -0800 Subject: [IPython-dev] Victims of our own success, change of strategy needed to get 0.12 released... In-Reply-To: References: Message-ID: On Mon, Dec 12, 2011 at 4:09 PM, Thomas Kluyver wrote: > And I've just merged this one. Besides a bugfix, that restores the backwards > compatibility we needed for Debian/Ubuntu. Thanks a lot everyone for this awesome work! We're now very close, we should be able to cut an RC very soon. Cheers, f From fperez.net at gmail.com Tue Dec 13 02:03:42 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 12 Dec 2011 23:03:42 -0800 Subject: [IPython-dev] Victims of our own success, change of strategy needed to get 0.12 released... In-Reply-To: References: Message-ID: On Mon, Dec 12, 2011 at 6:02 PM, Fernando Perez wrote: > Thanks a lot everyone for this awesome work! ?We're now very close, we > should be able to cut an RC very soon. OK, so looking at what we have, it seems we should be able to cut the RC tomorrow. Of things we can merge before the RC, we have: # 1079: if Stefan can finish it up quickly, we can go ahead with it. Otherwise it will go to post-0.12. # 1120: it doesn't have any dependencies. Paul, should we just go ahead and merge now? # 1129: currently conflicted, but a quick rebase should take care of it. If all goes well, we'll merge the three above and can cut the RC right away. The only blocker we have left tagged for 0.12 is our old nemesis: https://github.com/ipython/ipython/issues/481 Given that nobody seems to know how to fix it, we can't hold 0.12 indefinitely for it. A medal awaits the brave hero who slays this particular dragon, but in the meantime, we'll have to push 0.12 out without a fix if no solution is found in the next few days. Besides that, we only have three more issues that are of type 'bug' and targeted for 0.12: https://github.com/ipython/ipython/issues?labels=type-bug&sort=created&direction=desc&state=open&page=1&milestone=6 and I think we can live if it goes out without any of them fixed (we'll move them to 0.13, obviously). All in all, I think we're in pretty good shape! Thanks everyone for working so hard in the past few days to get us here. Cheers, f From fperez.net at gmail.com Tue Dec 13 22:15:39 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 13 Dec 2011 19:15:39 -0800 Subject: [IPython-dev] IPython 0.12.rc1 ready for testing! Message-ID: Hi all, I've just uploaded our first (and hopefully only) release candidate to the download site: http://archive.ipython.org/testing/0.12.rc1/ Please beat on it and let us know of anything that doesn't work. At this point we'll only commit critical bugfixes and documentation/example updates (there's a fair bit of those still to do). If the RC period lingers for long and there's pressure to start moving again on master, we'll make a separate branch for 0.12. But it seems after last weekend's blitz we may be able to just develop straight on master for the next few days, since thanks to everyone's hard work all the stuff that was in flight got landed. So have at it, and hopefully before too long we can be confident enough of it to call the final 0.12 out! If possible I'd like to do that this coming weekend, but we'll see both how everyone's schedule and the RC work out. Cheers, f From ischnell at enthought.com Tue Dec 13 22:43:32 2011 From: ischnell at enthought.com (Ilan Schnell) Date: Tue, 13 Dec 2011 21:43:32 -0600 Subject: [IPython-dev] IPython 0.12.rc1 ready for testing! In-Reply-To: References: Message-ID: That's great news. I'll start testing it tomorrow. - Ilan On Tue, Dec 13, 2011 at 9:15 PM, Fernando Perez wrote: > Hi all, > > I've just uploaded our first (and hopefully only) release candidate to > the download site: > > http://archive.ipython.org/testing/0.12.rc1/ > > Please beat on it and let us know of anything that doesn't work. ?At > this point we'll only commit critical bugfixes and > documentation/example updates (there's a fair bit of those still to > do). > > If the RC period lingers for long and there's pressure to start moving > again on master, we'll make a separate branch for 0.12. ?But it seems > after last weekend's blitz we may be able to just develop straight on > master for the next few days, since thanks to everyone's hard work all > the stuff that was in flight got landed. > > So have at it, and hopefully before too long we can be confident > enough of it to call the final 0.12 out! ?If possible I'd like to do > that this coming weekend, but we'll see both how everyone's schedule > and the RC work out. > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From fperez.net at gmail.com Wed Dec 14 15:57:27 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 14 Dec 2011 12:57:27 -0800 Subject: [IPython-dev] From the sage list: thinking about our messaging protocol Message-ID: Hi folks, this conversation started on the sage-dev list, but I'm moving part of it over here b/c it's really about our messaging protocol... It would be great if ultimately we have a set of protocol tests that validate our spec, as others are beginning to rely on the spec and it's pretty easy to drift if we have no tests telling us what is meant to stay. That doesn't mean we can never tweak the spec as we better understand certain cases, but we'll do it explicitly and not by accidental code drift. Cheers, f ---------- Forwarded message ---------- From: Jason Grout Date: Wed, Dec 14, 2011 at 12:43 PM Subject: [sage-devel] Re: Questions about the single-cell server To: sage-devel at googlegroups.com On 12/14/11 1:57 PM, Fernando Perez wrote: > > At this point we have a spec in the document you > pointed to, but precious little in the way of independent compliance > testing, so there's a real danger of the actual implementation > diverging from the specification simply by accident. Already I see it's changed from what we implemented. ?For example, your header now contains the msg_type, and the top-level contains the msg_id, duplicating both pieces of information. ?To me, it makes sense to keep things the way they were (msg_id in header, msg_type at the top-level), and don't duplicate the information. ?This minimizes the information that has to go back and forth (no need to send back the msg_type in the parent_header, since the client could just store it, though I suppose the argument could be made that msg_type really does belong in the header). What if the msg_id or msg_type between the header and the top-level is inconsistent? ?Which takes precedence? I presume that the header information takes precedence, but since the top-level fields are for convenience, my guess is that in practice, the top-level fields take precedence, since if you have to compare the top-level fields with the header fields, you might as well just use the header fields. A very simple wrapper function on the receiving end can add the convenience fields if they really need to be at the top-level, and that would guarantee consistency. Feel free to CC this message over to the ipython list if you want to take up the discussion there. Thanks, Jason -- To post to this group, send an email to sage-devel at googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscribe at googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org From benjaminrk at gmail.com Wed Dec 14 17:17:40 2011 From: benjaminrk at gmail.com (MinRK) Date: Wed, 14 Dec 2011 14:17:40 -0800 Subject: [IPython-dev] From the sage list: thinking about our messaging protocol In-Reply-To: References: Message-ID: Hello, On Wed, Dec 14, 2011 at 12:57, Fernando Perez wrote: > Hi folks, > > this conversation started on the sage-dev list, but I'm moving part of > it over here b/c it's really about our messaging protocol... > > It would be great if ultimately we have a set of protocol tests that > validate our spec, as others are beginning to rely on the spec and > it's pretty easy to drift if we have no tests telling us what is meant > to stay. ?That doesn't mean we can never tweak the spec as we better > understand certain cases, but we'll do it explicitly and not by > accidental code drift. > > Cheers, > > f > ---------- Forwarded message ---------- > From: Jason Grout > Date: Wed, Dec 14, 2011 at 12:43 PM > Subject: [sage-devel] Re: Questions about the single-cell server > To: sage-devel at googlegroups.com > > > On 12/14/11 1:57 PM, Fernando Perez wrote: >> >> At this point we have a spec in the document you >> pointed to, but precious little in the way of independent compliance >> testing, so there's a real danger of the actual implementation >> diverging from the specification simply by accident. > > > > Already I see it's changed from what we implemented. ?For example, > your header now contains the msg_type, and the top-level contains the > msg_id, duplicating both pieces of information. ?To me, it makes sense > to keep things the way they were (msg_id in header, msg_type at the > top-level), and don't duplicate the information. ?This minimizes the > information that has to go back and forth (no need to send back the > msg_type in the parent_header, since the client could just store it, > though I suppose the argument could be made that msg_type really does > belong in the header). These changes were made because of IPython.parallel, specifically the need to view headers *without* unserializing the potentially large body of the message. This means that the message must not be sent as a single blob, but as a multipart message, and the [header,parent_header, content] should be a complete representation of the message. Nothing should be in the top-level except for copies for convenience, because it is not required to be sent over the network. Since they are strictly copies of the contents of the header (as the spec defines them), top-level keys should be considered read-only, as changing them directly would violate the protocol. The header is really 'metadata about the message', and any/all information about the message should go in there. It seems inconsistent for the header to be an incomplete description of the message, which would be true if msg_id and/or msg_type were absent. > > What if the msg_id or msg_type between the header and the top-level is > inconsistent? ?Which takes precedence? I presume that the header > information takes precedence, but since the top-level fields are for > convenience, my guess is that in practice, the top-level fields take > precedence, since if you have to compare the top-level fields with the > header fields, you might as well just use the header fields. There is no priority, because there is no non-pathological way for these two values to differ. The top-level keys are *defined* as convenient aliases to the header keys. If they differ, then the protocol has not been implemented, and it would be appropriate to either raise an error, or set the top-level key from the header on recv (IPython does the latter, because top-level aliases are not sent over the network). In IPython, the Session object, which is responsible for building messages and sending them over the wire, copies the msg_type and msg_id to the top-level from the header purely for convenience of other code. The top-level copies are never sent over the network, so any changes to them, or indeed any extra keys injected into the message, would not be reflected on the receiving side. We did briefly have a 'cleaned up' version after we cut 0.11, where the top-level duplicates were removed, but found that the result was actually much messier, given how frequently these values are accessed. > > A very simple wrapper function on the receiving end can add the > convenience fields if they really need to be at the top-level, and > that would guarantee consistency. That's exactly what we do. In IPython, *all* communication is managed through Session objects, which make certain guarantees: * A message has a header, parent_header, and content. * The 'msg_id' and 'msg_type' keys of the header are copied to the top-level for convenience. This Session object also handles serialization, authentication, and the use of buffers and pyzmq MessageTracker objects used in IPython.parallel for non-copying operations, all of which are *extensions* of the messaging spec. This is what enables us to switch between json, pickle, msgpack, and protobuf for serialization with a line or two of config. -MinRK > > Feel free to CC this message over to the ipython list if you want to > take up the discussion there. > > Thanks, > > Jason > > > -- > To post to this group, send an email to sage-devel at googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscribe at googlegroups.com > For more options, visit this group at http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From satra at mit.edu Thu Dec 15 06:29:55 2011 From: satra at mit.edu (Satrajit Ghosh) Date: Thu, 15 Dec 2011 12:29:55 +0100 Subject: [IPython-dev] pycharm now supports ipython 0.11 Message-ID: pycharm, a commercial ide (free for opensource projects) that i've grown to like a fair bit just released a new version with ipython 0.11 support. http://www.jetbrains.com/pycharm/whatsnew/ cheers, satra -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Thu Dec 15 15:29:25 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 15 Dec 2011 12:29:25 -0800 Subject: [IPython-dev] pycharm now supports ipython 0.11 In-Reply-To: References: Message-ID: On Thu, Dec 15, 2011 at 3:29 AM, Satrajit Ghosh wrote: > pycharm, a commercial ide (free for opensource projects) that i've grown to > like a fair bit just released a new version with ipython 0.11 support. > > http://www.jetbrains.com/pycharm/whatsnew/ Great! Do you know if it works with current master as well? And what specific ipython support does it provide? Cheers, f From cekees at gmail.com Fri Dec 16 20:46:41 2011 From: cekees at gmail.com (Chris Kees) Date: Fri, 16 Dec 2011 19:46:41 -0600 Subject: [IPython-dev] display protocol: animation and video Message-ID: I'd like to include animations in the notebook and am trying to think through the options for connecting to the display protocol. The case I'm targeting is one with a small number of high-resolution frames (e.g. 50 to 500 frames). Each frame is generated by compositing portions of the frame rendered on (possibly many) mpi engines. At the moment I generate a png or svg of the composite image on the root engine and just bring the last image in the sequence over to the client, which I can display with something like c = Client() view = c[:] view.activate() Image(view['imageSequence'][rootEngine][-1]) All I want to do now is make the whole sequence of images available with "VCR buttons" (rewind, pause, play, fast forward, maybe a slider to look at specific frames). Should I 1) generate a single SVG of the entire animation on the root engine, 2) use ffmpeg via matplotlib or some other wrapper to ffmpeg to generate a video on the root engine, or 3) continue bringing over the entire image sequence and do the conversion to animated SVG or mpeg on the client. On 1: I've tried including the SVG for the animation here http://srufaculty.sru.edu/david.dailey/svg/ovaling.svg using SVG(data="""..."""), but it doesn't show up in the notebook. Maybe SVG animations aren't fully supported in the notebook yet? On 2: How do I bring the mpeg over? Just read the mpeg file on the root engine, write it back out on the client, and display using HTML(file="filename.mp4")? Thanks for any suggestions. Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Fri Dec 16 23:18:12 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Fri, 16 Dec 2011 20:18:12 -0800 Subject: [IPython-dev] display protocol: animation and video In-Reply-To: References: Message-ID: On Fri, Dec 16, 2011 at 5:46 PM, Chris Kees wrote: > I'd like to include animations in the notebook and am trying to think > through the options for connecting to the display protocol. ?The case I'm > targeting is one with a small number of high-resolution frames (e.g. 50 to > 500 frames). Each frame is generated by compositing portions of the frame > rendered on (possibly many) mpi engines. ?At the moment I generate a png or > svg of the composite image on the root engine and just bring the last image > in the sequence over to the client, which I can display with something like So we have not thought about animiation in the display protocol yet. Definitely room for improvement. > c = Client() > view = c[:] > view.activate() > Image(view['imageSequence'][rootEngine][-1]) > > All I want to do now is make the whole sequence of images available with > "VCR buttons" (rewind, pause, play, fast forward, maybe a slider to look at > specific frames). ?Should I 1) generate a single SVG of the entire animation > on the root engine, 2) use ffmpeg via matplotlib or some other wrapper to > ffmpeg to generate a video on the root engine, or 3) continue bringing over > the entire image sequence and do the ?conversion to animated SVG or mpeg on > the client. > > On 1: I've tried including the SVG for the animation here > http://srufaculty.sru.edu/david.dailey/svg/ovaling.svg using > SVG(data="""..."""), but it doesn't show up in the notebook. ? ?Maybe SVG > animations aren't fully supported in the notebook yet? What is the MIME type for animated SVGs? Our current implementation assumes the standard SVG image MIME type when we construct the data URI in the browser. > On 2: How do I bring the mpeg over? Just read the mpeg file on the root > engine, write it back out on the client, and display using > HTML(file="filename.mp4")? I think you will need to encode the image and put it into the HTML using a data URI: http://en.wikipedia.org/wiki/Data_URI_scheme Using this approach you should be able to embed any media type. Cheers, Brian > Thanks for any suggestions. > > Chris > > _______________________________________________ > 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 Sat Dec 17 16:44:57 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 17 Dec 2011 13:44:57 -0800 Subject: [IPython-dev] Last call: 0.12 this weekend? Message-ID: Hi all, we haven't had too many scares since the RC went out, so I'd like to cut 0.12 this weekend (time permitting, I have some work things I must take care of first). The only thing left I'd like to see go in is https://github.com/ipython/ipython/pull/1168 which is just adding a convenience flag for an existing feature. Once that gets reviewed, I think we're good to go code-wise. I'll do some final doc and example touch-ups, including finishing up a sample notebook that people can use to get started. But I won't touch the core code further (there's often at release time minor tweaks to make to the files in tools/ or to the release.py file, but that should be it). Anyone have any objection or see any glaring problems? I know we still haven't fixed https://github.com/ipython/ipython/issues/481 but given nobody is quite sure what to do here, we can't hold the release forever on account of one issue. This and the other few issues left that were targeted for 0.12 will simply be retargeted for 0.13. Cheers, f From fperez.net at gmail.com Sat Dec 17 17:29:11 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 17 Dec 2011 14:29:11 -0800 Subject: [IPython-dev] display protocol: animation and video In-Reply-To: References: Message-ID: On Fri, Dec 16, 2011 at 8:18 PM, Brian Granger wrote: > So we have not thought about animiation in the display protocol yet. > Definitely room for improvement. I tried to hack up something quick for Chris using the html5 video tag with an mp4 file, but it's not easy to make it work b/c the notebook doesn't expose access to the local filesystem for html tags (that's why we encode inline the image data in the Image() object). Which got me thinking about that issue in a more general sense. I think we should offer a way for users to refer to local files in the starting directory of the notebook, so that they could expose them to the browser in situations like this one. I know there are a few important caveats to keep in mind, namely: Caveat 1: in the most general case, we must not assume that the notebook server and the kernel reside on the same host. Just yesterday chatting with Titus Brown he had a good use case for running the notebook server locally on a laptop but accessing kernels living in a remote Amazon EC2 instance. This would let him save notebooks locally and would eliminate upstream traffic of images while letting him work on large, amazon-hosted datasets. Still, I think that for the common case where the notebook server and the kernels do reside on the same filesystem, offering an easy solution is worthwhile. It won't apply to scenarios such as Titus' above, but it will be very useful in many cases. Caveat 2: the working directory of the kernel can vary at runtime (the user can run %cd/os.chdir() at any time). So the filesystem served by the notebook over http would be rooted where it started the kernel. If that kernel later moves to a different working directory, so be it. It's up to the user to keep track of this and adjust his/her code accordingly. Caveat 3: security. The notebook server needs to sanitize paths to avoid accessing remote paths, which means always checking that a requested path is below the starting point via abspath(). Caveat 4..n: everything else I haven't thought of yet. But even given those, I think it would be very useful to offer a handler that would allow people to return objects whose repr includes things like: or using the Markdown image syntax to show local images in Markdown cells. We'd write a handler for the 'file/' URL that would simply search the rest of that URL as a local file in the directory where the notebook started a local kernel. For remote kernels, it would default to the server's filesystem since the server can't access the kernel FS (this would be useful in a scenario such as Titus', for showing local files like images or video in Markdown areas). Thoughts? Cheers, f From cekees at gmail.com Sat Dec 17 20:03:05 2011 From: cekees at gmail.com (Chris Kees) Date: Sat, 17 Dec 2011 19:03:05 -0600 Subject: [IPython-dev] display protocol: animation and video In-Reply-To: References: Message-ID: On Sat, Dec 17, 2011 at 4:29 PM, Fernando Perez wrote: > On Fri, Dec 16, 2011 at 8:18 PM, Brian Granger > wrote: > > So we have not thought about animiation in the display protocol yet. > > Definitely room for improvement. > > I tried to hack up something quick for Chris using the html5 video tag > with an mp4 file, but it's not easy to make it work b/c the notebook > doesn't expose access to the local filesystem for html tags (that's > why we encode inline the image data in the Image() object). > > Which got me thinking about that issue in a more general sense. I > think we should offer a way for users to refer to local files in the > starting directory of the notebook, so that they could expose them to > the browser in situations like this one. I know there are a few > important caveats to keep in mind, namely: > > Caveat 1: in the most general case, we must not assume that the > notebook server and the kernel reside on the same host. Just > yesterday chatting with Titus Brown he had a good use case for running > the notebook server locally on a laptop but accessing kernels living > in a remote Amazon EC2 instance. This would let him save notebooks > locally and would eliminate upstream traffic of images while letting > him work on large, amazon-hosted datasets. > > I agree that this case is worth planning for. The HPCMP "utility servers" may make this kind of scenario useful for us as well. The notebook server would run on the login nodes, the kernels on large memory nodes accessed through a queue, and the engines on another large cluster---I need to check on how the filesystems are mounted. I've been working towards rendering 'in situ' on the engines but given the capabilities of the utility server nodes it may be feasible and more efficient in some cases to bring the geometry and solution/field data over to the kernel and render it there (that's what my initial example did with matplotlib). > Still, I think that for the common case where the notebook server and > the kernels do reside on the same filesystem, offering an easy > solution is worthwhile. It won't apply to scenarios such as Titus' > above, but it will be very useful in many cases. > > Caveat 2: the working directory of the kernel can vary at runtime (the > user can run %cd/os.chdir() at any time). So the filesystem served by > the notebook over http would be rooted where it started the kernel. > If that kernel later moves to a different working directory, so be it. > It's up to the user to keep track of this and adjust his/her code > accordingly. > > Caveat 3: security. The notebook server needs to sanitize paths to > avoid accessing remote paths, which means always checking that a > requested path is below the starting point via abspath(). > > Caveat 4..n: everything else I haven't thought of yet. > > > > But even given those, I think it would be very useful to offer a > handler that would allow people to return objects whose repr includes > things like: > > > > I can say at least that as a newbie my expectation was that I could access the filesystem from html so you'll probably save yourself some headaches on the mailing list if you provide it. It occurs to me that storing images in the notebook directory and displaying images in the markdown cells could also be a useful verification and/or teaching tool ("This notebook solves u_{xx} = f. The solution is shown below"). > or using the Markdown image syntax to show local images in Markdown > cells. We'd write a handler for the 'file/' URL that would simply > search the rest of that URL as a local file in the directory where the > notebook started a local kernel. For remote kernels, it would default > to the server's filesystem since the server can't access the kernel FS > (this would be useful in a scenario such as Titus', for showing local > files like images or video in Markdown areas). > > Thoughts? > > Cheers, > > f > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Sat Dec 17 20:12:17 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 17 Dec 2011 17:12:17 -0800 Subject: [IPython-dev] display protocol: animation and video In-Reply-To: References: Message-ID: On Sat, Dec 17, 2011 at 5:03 PM, Chris Kees wrote: > I can say at least that as a newbie my expectation was that I could access > the filesystem from html so you'll probably save yourself some headaches on > the mailing list if you provide it. Yes, in fact the first time I noticed it not working, it took me a minute to realize why not, and I don't think it would be immediately obvious to a user who isn't familiar with how the internal pieces fit together (who sees what data, who serves http vs executing code, etc). > It occurs to me that storing images in the notebook directory and displaying > images in the markdown cells could also be a useful verification and/or > teaching tool ("This notebook solves u_{xx} = f. The solution is shown > below"). Great, thanks for the feedback. I think it's indeed possible and useful, and I don't see any major hurdles to implementing it. It's just an extra URL handler to write in the app. Let's see if anyone notices any reason why we should absolutely not do this, and otherwise we'll put it in the todo list for 0.13. Cheers, f From tomspur at fedoraproject.org Sun Dec 18 08:05:40 2011 From: tomspur at fedoraproject.org (Thomas Spura) Date: Sun, 18 Dec 2011 14:05:40 +0100 Subject: [IPython-dev] Last call: 0.12 this weekend? In-Reply-To: References: Message-ID: On Sat, Dec 17, 2011 at 10:44 PM, Fernando Perez wrote: > Anyone have any objection or see any glaring problems? When running rm -rf ~/.config/ipython and doing %install_default_config, this results in a crash: Installing default config file in: /home/tom/.config/ipython/profile_default --------------------------------------------------------------------------- IOError Traceback (most recent call last) /home/tom/src/ipython.git/ in () ----> 1 get_ipython().magic(u'install_default_config') /home/tom/src/ipython.git/IPython/core/interactiveshell.pyc in magic(self, arg_s, next_input) 1996 self._magic_locals = sys._getframe(1).f_locals 1997 with self.builtin_trap: -> 1998 result = fn(magic_args) 1999 # Ensure we're not keeping object references around: 2000 self._magic_locals = {} /home/tom/src/ipython.git/IPython/core/magic.pyc in magic_install_default_config(self, s) 3403 pd = self.shell.profile_dir 3404 print "Installing default config file in: %s" % pd.location -> 3405 pd.copy_config_file('ipython_config.py', overwrite=overwrite) 3406 3407 # Pylab support: simple wrappers that activate pylab, load gui input /home/tom/src/ipython.git/IPython/core/profiledir.pyc in copy_config_file(self, config_file, path, overwrite) 149 path = os.path.join(get_ipython_package_dir(), u'config', u'profile', u'default') 150 src = os.path.join(path, config_file) --> 151 shutil.copy(src, dst) 152 return True 153 /usr/lib64/python2.7/shutil.pyc in copy(src, dst) 114 if os.path.isdir(dst): 115 dst = os.path.join(dst, os.path.basename(src)) --> 116 copyfile(src, dst) 117 copymode(src, dst) 118 /usr/lib64/python2.7/shutil.pyc in copyfile(src, dst) 79 raise SpecialFileError("`%s` is a named pipe" % fn) 80 ---> 81 with open(src, 'rb') as fsrc: 82 with open(dst, 'wb') as fdst: 83 copyfileobj(fsrc, fdst) IOError: [Errno 2] No such file or directory: u'./IPython/config/profile/default/ipython_config.py' Also see this bug report for that: https://bugzilla.redhat.com/show_bug.cgi?id=751146 All I could find in the github issues is this: https://github.com/ipython/ipython/issues/467 but that was with the old config system... Greetings, Tom From takowl at gmail.com Sun Dec 18 08:15:22 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Sun, 18 Dec 2011 13:15:22 +0000 Subject: [IPython-dev] Last call: 0.12 this weekend? In-Reply-To: References: Message-ID: On 18 December 2011 13:05, Thomas Spura wrote: > IOError: [Errno 2] No such file or directory: > u'./IPython/config/profile/default/ipython_config.py' > The default profile now has the config file auto-generated when you do "ipython profile create", so there's nothing to copy. I guess this wasn't updated when we changed that. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomspur at fedoraproject.org Sun Dec 18 08:24:46 2011 From: tomspur at fedoraproject.org (Thomas Spura) Date: Sun, 18 Dec 2011 14:24:46 +0100 Subject: [IPython-dev] Last call: 0.12 this weekend? In-Reply-To: References: Message-ID: On Sun, Dec 18, 2011 at 2:15 PM, Thomas Kluyver wrote: > On 18 December 2011 13:05, Thomas Spura wrote: >> >> IOError: [Errno 2] No such file or directory: >> u'./IPython/config/profile/default/ipython_config.py' > > > The default profile now has the config file auto-generated when you do > "ipython profile create", so there's nothing to copy. I guess this wasn't > updated when we changed that. Hmm, can %install_default_config then be changed to eigther: * be removed totally or * link to "ipython profile create" or * do the same like "ipython profile create" ? (I would prefer the first or second...) Greetings, Tom From takowl at gmail.com Sun Dec 18 08:30:18 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Sun, 18 Dec 2011 13:30:18 +0000 Subject: [IPython-dev] Last call: 0.12 this weekend? In-Reply-To: References: Message-ID: On 18 December 2011 13:24, Thomas Spura wrote: > Hmm, can %install_default_config then be changed to eigther: I'm quite sure it can, but I don't know the best way to do it. I think Min knows these things best, hopefully he'll be online later. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Sun Dec 18 13:33:13 2011 From: benjaminrk at gmail.com (MinRK) Date: Sun, 18 Dec 2011 10:33:13 -0800 Subject: [IPython-dev] Last call: 0.12 this weekend? In-Reply-To: References: Message-ID: On Sun, Dec 18, 2011 at 05:30, Thomas Kluyver wrote: > On 18 December 2011 13:24, Thomas Spura wrote: >> >> Hmm, can %install_default_config then be changed to eigther: > > > I'm quite sure it can, but I don't know the best way to do it. I think Min > knows these things best, hopefully he'll be online later. Sure, it can. I'd vote for removing it altogether, in favor of just *calling* `!ipython profile create ` -MinRK > > Thomas > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > From tomspur at fedoraproject.org Sun Dec 18 13:59:50 2011 From: tomspur at fedoraproject.org (Thomas Spura) Date: Sun, 18 Dec 2011 19:59:50 +0100 Subject: [IPython-dev] Last call: 0.12 this weekend? In-Reply-To: References: Message-ID: On Sun, Dec 18, 2011 at 7:33 PM, MinRK wrote: > On Sun, Dec 18, 2011 at 05:30, Thomas Kluyver wrote: >> On 18 December 2011 13:24, Thomas Spura wrote: >>> >>> Hmm, can %install_default_config then be changed to eigther: >> >> >> I'm quite sure it can, but I don't know the best way to do it. I think Min >> knows these things best, hopefully he'll be online later. > > Sure, it can. ?I'd vote for removing it altogether, in favor of just > *calling* `!ipython profile create ` +1 :) %install_profiles should be dead too... Both done in PR 1174 Thanks, Tom From fperez.net at gmail.com Mon Dec 19 04:49:07 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 19 Dec 2011 01:49:07 -0800 Subject: [IPython-dev] [ANN] IPython 0.12 is out! Message-ID: Hi all, on behalf of the IPython development team, I'm thrilled to announce, after an intense 4 1/2 months of work, the official release of IPython 0.12. This is a very important release for IPython, for several reasons. First and foremost, we have a major new feature, our interactive web-based notebook, that has been in our sights for a very long time. We tried to build one years ago (with WX) as a Google SoC project in 2005, had other prototypes later on, but things never quite worked. Finally the refactoring effort started two years ago, the communications architecture we built in 2010, and the advances of modern browsers, gave us all the necessary pieces. With this foundation in place, while part of the team worked on the 0.11 release, Brian Granger had already started quietly building the web notebook, which we demoed in early-alpha mode at the SciPy 2011 conference (http://www.archive.org/details/Wednesday-203-6-IpythonANewArchitectureForInteractiveAndParallel). By the EuroScipy conference in August we had merged Brian's amazing effort into our master branch, and after that multiple people (old and new) jumped in to make all kinds of improvements, leaving us today with something that is an excellent foundation. It's still the first release of the notebook, and as such we know it has a number of rough edges, but several of us have been using it as a daily research tool for the last few months. Do not hesitate to file issues for any problems you encounter with it, and we even have an 'open issue' for general discussion of ideas and features for the notebook at: https://github.com/ipython/ipython/issues/977. Furthermore, it is clear that our big refactoring work, combined with the amazing facilities at Github, are paying off. The 0.11 series was a major amount of work, with 511 issues closed over almost two years. But that pales in comparison to this cycle: in only 4 1/2 months we closed 515 issues, with 50% being Pull Requests. And very importantly, our list of contributors includes many new faces (see the credits section in our release notes for full details), which is the best thing that can happen to an open source project. We hope you will find the new features (the notebook isn't the only one! see below) compelling, and that many more will not only use IPython but will join the project; there's plenty to do and now there are tasks for many different skill sets (web, javascript, gui work, low-level networking, parallel machinery, console apps, etc). *Downloads* Download links and instructions are at: http://ipython.org/download.html And IPython is also on PyPI: http://pypi.python.org/pypi/ipython Those contain a built version of the HTML docs; if you want pure source downloads with no docs, those are available on github: Tarball: https://github.com/ipython/ipython/tarball/rel-0.12 Zipball: https://github.com/ipython/ipython/zipball/rel-0.12 * Features * Here is a quick listing of the major new features: - An interactive browser-based Notebook with rich media support - Two-process terminal console - Tabbed QtConsole - Full Python 3 compatibility - Standalone Kernel - PyPy support And many more... We closed over 500 tickets, merged over 200 pull requests, and more than 45 people contributed commits for the final release. Please see our release notes for the full details on everything about this release: http://ipython.org/ipython-doc/stable/whatsnew/version0.12.html * IPython tutorial at PyCon 2012 * Those of you attending (or planning on it) PyCon 2012 in Santa Clara, CA, may be interested in attending a hands-on tutorial we will be presenting on the many faces of IPython. See https://us.pycon.org/2012/schedule/presentation/121/ for full details. * Errata * This was caught by Matthias Bussionnier's (one of our great new contributors) sharp eyes while I was writing these release notes: In the example notebook called display_protocol, the first cell starts with: from IPython.lib.pylabtools import print_figure which should instead be: from IPython.core.pylabtools import print_figure This has already been fixed on master, but since the final 0.12 files have been uploaded to github and PyPI, we'll let them be. As usual, if you find any other problem, please file a ticket --or even better, a pull request fixing it-- on our github issues site (https://github.com/ipython/ipython/issues/). Many thanks to all who contributed! Fernando, on behalf of the IPython development team. http://ipython.org From jason-sage at creativetrax.com Mon Dec 19 09:36:09 2011 From: jason-sage at creativetrax.com (Jason Grout) Date: Mon, 19 Dec 2011 08:36:09 -0600 Subject: [IPython-dev] From the sage list: thinking about our messaging protocol In-Reply-To: References: Message-ID: <4EEF4BD9.9050305@creativetrax.com> On 12/14/11 4:17 PM, MinRK wrote: > These changes were made because of IPython.parallel, specifically the > need to view headers*without* unserializing the potentially large > body of the message. It just occurred to me: would it be okay to add version numbers to the messaging protocol to prevent confusion? You could even match the version numbers to ipython releases (i.e., version 0.11, 0.12, etc.), if you wanted to tie it that closely to ipython. Thanks, Jason From benjaminrk at gmail.com Mon Dec 19 13:48:31 2011 From: benjaminrk at gmail.com (Min RK) Date: Mon, 19 Dec 2011 10:48:31 -0800 Subject: [IPython-dev] From the sage list: thinking about our messaging protocol In-Reply-To: <4EEF4BD9.9050305@creativetrax.com> References: <4EEF4BD9.9050305@creativetrax.com> Message-ID: On Dec 19, 2011, at 6:36, Jason Grout wrote: > On 12/14/11 4:17 PM, MinRK wrote: >> These changes were made because of IPython.parallel, specifically the >> need to view headers*without* unserializing the potentially large >> body of the message. > > It just occurred to me: would it be okay to add version numbers to the messaging protocol to prevent confusion? You could even match the version numbers to ipython releases (i.e., version 0.11, 0.12, etc.), if you wanted to tie it that closely to ipython. > Yes, that makes sense, we should probably do so. So far there has only been one version in released code, because we made the changes discussed here prior to 0.11, so any changes should mark version 2. > Thanks, > > Jason > From fperez.net at gmail.com Tue Dec 20 04:19:03 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 20 Dec 2011 01:19:03 -0800 Subject: [IPython-dev] [IPython-User] [SciPy-User] [ANN] IPython 0.12 is out! In-Reply-To: References: Message-ID: On Mon, Dec 19, 2011 at 7:39 AM, Wes McKinney wrote: > My sincere congratulations to the IPython team! You set an amazingly > high standard that we should all strive to emulate. I never seem to > run out of good things to say about the work that you are doing-- > looking forward to an even more productive 2012! Well, your kind words are very much appreciated, but I actually wanted to thank you for saying those good things, as you've actually already helped us by doing so... A few days ago on the nipy list someone posted a link to Titus Brown's blog post: http://ivory.idyll.org/blog/dec-11/data-intensive-science-and-workflows as I was reading I kept thinking 'well, the ipython notebook could be useful there...', and then I read further down that he had tried the notebook. Eventually on Friday I had a very nice chat with Titus about this and related matters, that hopefully will lead to interesting things down the road. And as it turns out, I owe it to you! He mentioned how a chance meeting on a train where his next-seat neighbor turned out to be a scientific python guy (you) led to a conversation about the notebook. So thanks!! Best, f From benjaminrk at gmail.com Tue Dec 20 15:50:48 2011 From: benjaminrk at gmail.com (MinRK) Date: Tue, 20 Dec 2011 12:50:48 -0800 Subject: [IPython-dev] [IPython-User] [SciPy-User] [ANN] IPython 0.12 is out! In-Reply-To: References: Message-ID: Related to this, I wanted to post a quick dev question: I know we plan to continue the short release cycle with at least two more significant releases in 2012, but do we want to have a 'bugfix' branch for possible 0.12.1? We were bitten pretty hard by the pyzmq version-check bug, and we probably should have cut 0.11.1 with the fix, which we had in master two months before the issue came up. I suppose we don't have to make a decision until we make our first change that shouldn't go into an incremental release, but I thought I would float the idea. I don't think we have to make such a release unless we find a potential bug that justifies one, but I think the cost of making 0.11.1 would have been lower than the time we spent saying "duplicate of #XYZ, fixed in master" on GitHub. -MinRK From fperez.net at gmail.com Tue Dec 20 18:02:27 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 20 Dec 2011 15:02:27 -0800 Subject: [IPython-dev] [IPython-User] [SciPy-User] [ANN] IPython 0.12 is out! In-Reply-To: References: Message-ID: On Tue, Dec 20, 2011 at 12:50 PM, MinRK wrote: > I know we plan to continue the short release cycle with at least two > more significant releases in 2012, but do we want to have a 'bugfix' > branch for possible 0.12.1? ?We were bitten pretty hard by the pyzmq > version-check bug, and we probably should have cut ?0.11.1 with the > fix, which we had in master two months before the issue came up. > > I suppose we don't have to make a decision until we make our first > change that shouldn't go into an incremental release, but I thought I > would float the idea. ?I don't think we have to make such a release > unless we find a potential bug that justifies one, but I think the > cost of making 0.11.1 would have been lower than the time we spent > saying "duplicate of #XYZ, fixed in master" on GitHub. Agreed. It's easy enough to make such a branch after the fact, if it proves to be necessary, and to cherry pick anything from master we'd like to see in there. I agree that we probably should have cut a 0.11.1 for that silly bug :) In this case there's an added incentive to a bugfix branch: while we'll most likely get 0.12 included in ubuntu 12.04, they won't do a version upgrade to 0.13. But I think they do push minor bugfix-only updates, so it would help anyone in an environment that sticks to the default ubuntu LTS policies get at least the most critical fixes. Cheers f From fperez.net at gmail.com Tue Dec 20 18:15:56 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 20 Dec 2011 15:15:56 -0800 Subject: [IPython-dev] Offline for a week Message-ID: Hi folks, Just a note that as of tomorrow I'll be offline for roughly a week. I know the rest of the team does a great job of manning the fort when one of us is unavailable, but in case someone expects a direct reply from me, it won't happen for a few days. Happy Holidays and a great 2012 for everyone, hopefully with lots of IPython in it :) f From tomspur at fedoraproject.org Wed Dec 21 04:02:18 2011 From: tomspur at fedoraproject.org (Thomas Spura) Date: Wed, 21 Dec 2011 10:02:18 +0100 Subject: [IPython-dev] [IPython-User] [SciPy-User] [ANN] IPython 0.12 is out! In-Reply-To: References: Message-ID: On Wed, Dec 21, 2011 at 12:02 AM, Fernando Perez wrote: > On Tue, Dec 20, 2011 at 12:50 PM, MinRK wrote: >> I know we plan to continue the short release cycle with at least two >> more significant releases in 2012, but do we want to have a 'bugfix' >> branch for possible 0.12.1? ?We were bitten pretty hard by the pyzmq >> version-check bug, and we probably should have cut ?0.11.1 with the >> fix, which we had in master two months before the issue came up. >> >> I suppose we don't have to make a decision until we make our first >> change that shouldn't go into an incremental release, but I thought I >> would float the idea. ?I don't think we have to make such a release >> unless we find a potential bug that justifies one, but I think the >> cost of making 0.11.1 would have been lower than the time we spent >> saying "duplicate of #XYZ, fixed in master" on GitHub. > > Agreed. ?It's easy enough to make such a branch after the fact, if it > proves to be necessary, and to cherry pick anything from master we'd > like to see in there. ?I agree that we probably should have cut a > 0.11.1 for that silly bug :) > > In this case there's an added incentive to a bugfix branch: while > we'll most likely get 0.12 included in ubuntu 12.04, they won't do a > version upgrade to 0.13. ?But I think they do push minor bugfix-only > updates, so it would help anyone in an environment that sticks to the > default ubuntu LTS policies get at least the most critical fixes. Hmm, and why not? I can understand, that nobody wants to do the switch to 0.11 in a released distribution, because anything changes, e.g. configuration all modules... So when you plan something similar with the next release, a bugfix release would be great. When the next release includes the feature set of the old one (only adds more feature) and has the bugfixes of the old one, I don't see a problem, to not do an extra bugfix release... Greetings, Tom From fperez.net at gmail.com Wed Dec 21 04:38:06 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 21 Dec 2011 01:38:06 -0800 Subject: [IPython-dev] [IPython-User] [SciPy-User] [ANN] IPython 0.12 is out! In-Reply-To: References: Message-ID: On Wed, Dec 21, 2011 at 1:02 AM, Thomas Spura wrote: > I don't see a problem, to not do an > extra bugfix release... My understanding is that ubuntu won't do a 0.12 -> 0.13 update during the LTS release cycle, but that they would apply a 0.12.1 'small fixes' update. Since the burden on us is not that large, I don't mind doing it... Cheers, f From nicolas.chauvat at logilab.fr Wed Dec 21 05:06:49 2011 From: nicolas.chauvat at logilab.fr (Nicolas Chauvat) Date: Wed, 21 Dec 2011 11:06:49 +0100 Subject: [IPython-dev] [IPython-User] [SciPy-User] [ANN] IPython 0.12 is out! In-Reply-To: References: Message-ID: <20111221100649.GA17767@volans.logilab.fr> On Tue, Dec 20, 2011 at 03:02:27PM -0800, Fernando Perez wrote: > > cost of making 0.11.1 would have been lower than the time we spent > > saying "duplicate of #XYZ, fixed in master" on GitHub. > > Agreed. It's easy enough to make such a branch after the fact, if it > proves to be necessary, and to cherry pick anything from master we'd > like to see in there. I agree that we probably should have cut a > 0.11.1 for that silly bug :) +1 having a stable branch where only fixes can enter and a development branch for the rest is a very common good practice. > In this case there's an added incentive to a bugfix branch: while > we'll most likely get 0.12 included in ubuntu 12.04, they won't do a > version upgrade to 0.13. But I think they do push minor bugfix-only > updates, so it would help anyone in an environment that sticks to the > default ubuntu LTS policies get at least the most critical fixes. True. Distributions have their dev/stable phases too :) -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances From benjaminrk at gmail.com Wed Dec 21 05:35:56 2011 From: benjaminrk at gmail.com (MinRK) Date: Wed, 21 Dec 2011 02:35:56 -0800 Subject: [IPython-dev] [IPython-User] [SciPy-User] [ANN] IPython 0.12 is out! In-Reply-To: <20111221100649.GA17767@volans.logilab.fr> References: <20111221100649.GA17767@volans.logilab.fr> Message-ID: On Wed, Dec 21, 2011 at 02:06, Nicolas Chauvat wrote: > On Tue, Dec 20, 2011 at 03:02:27PM -0800, Fernando Perez wrote: >> > cost of making 0.11.1 would have been lower than the time we spent >> > saying "duplicate of #XYZ, fixed in master" on GitHub. >> >> Agreed. ?It's easy enough to make such a branch after the fact, if it >> proves to be necessary, and to cherry pick anything from master we'd >> like to see in there. ?I agree that we probably should have cut a >> 0.11.1 for that silly bug :) > > +1 having a stable branch where only fixes can enter and a development > branch for the rest is a very common good practice. It certainly is, and the reason we did not do so for 0.11, and would consider not doing so for 0.12 is that we have planned a very short release cycle (3-6 months per release) while recently introduced features (zmq, qt, notebook) get settled. In that situation bugfix releases are of limited value, and our precious little dev time is better put towards finishing each 'real' release. But if we do find any *critical* bugs like the zmq-version detection one, we should cut a bugfix release to prevent perpetual reports of a long-fixed bug. > >> In this case there's an added incentive to a bugfix branch: while >> we'll most likely get 0.12 included in ubuntu 12.04, they won't do a >> version upgrade to 0.13. ?But I think they do push minor bugfix-only >> updates, so it would help anyone in an environment that sticks to the >> default ubuntu LTS policies get at least the most critical fixes. > > True. Distributions have their dev/stable phases too :) > > -- > Nicolas Chauvat > > logilab.fr - services en informatique scientifique et gestion de connaissances From stefan at sun.ac.za Wed Dec 21 12:04:12 2011 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Wed, 21 Dec 2011 09:04:12 -0800 Subject: [IPython-dev] Notebook configuration defaults Message-ID: Hi all, I just did a demo of a fresh install of the IPython notebook for a colleague. Some comments: - Not having "inline" as the default pylab mode is pretty confusing and un-notebook-like. - The notebook profile configuration file doesn't clearly indicate that "inline" is an option for the pylab variable. - Having configuration (such as the tab completer config) in the side-bar is not ideal (especially if we're going to be adding more). - Being able to launch "ipython notebook myfile.ipy" would be useful. Cheers St?fan From fperez.net at gmail.com Thu Dec 22 13:20:29 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 22 Dec 2011 10:20:29 -0800 Subject: [IPython-dev] You can help ipython: port the faq to the new wiki Message-ID: Hi all, here's something an enterprising user could give us a hand with, if you'd like to contribute to the project. When we moved our wiki from the old moin instance to our new website, it seems we missed the FAQ and possibly other similar pages. The old one is here: http://ipython.scipy.org/Wiki/FAQ and I've made a placeholder here: http://wiki.ipython.org/FrequentlyAskedQuestions If you could help us in porting that old page over, it would be awesome. Some syntax conversions may be necessary, I set the placeholder to use reST so that we can more easily move information back and forth from the manual into the faq. Bonus points for any other pages you may find out that we missed and that you can help us with porting. Best f From Nicolas.Rougier at inria.fr Thu Dec 22 14:31:02 2011 From: Nicolas.Rougier at inria.fr (Nicolas Rougier) Date: Thu, 22 Dec 2011 20:31:02 +0100 Subject: [IPython-dev] You can help ipython: port the faq to the new wiki In-Reply-To: References: Message-ID: Just did the port. Hope it's ok. (It lacks the IpythonOnWindows link & page, I will try to work on it too). By the way, last question may require some update. Nicolas On Dec 22, 2011, at 19:20 , Fernando Perez wrote: > Hi all, > > here's something an enterprising user could give us a hand with, if > you'd like to contribute to the project. When we moved our wiki from > the old moin instance to our new website, it seems we missed the FAQ > and possibly other similar pages. > > The old one is here: > > http://ipython.scipy.org/Wiki/FAQ > > and I've made a placeholder here: > > http://wiki.ipython.org/FrequentlyAskedQuestions > > If you could help us in porting that old page over, it would be > awesome. Some syntax conversions may be necessary, I set the > placeholder to use reST so that we can more easily move information > back and forth from the manual into the faq. > > Bonus points for any other pages you may find out that we missed and > that you can help us with porting. > > Best > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From ischnell at enthought.com Fri Dec 23 11:55:48 2011 From: ischnell at enthought.com (Ilan Schnell) Date: Fri, 23 Dec 2011 10:55:48 -0600 Subject: [IPython-dev] EPD 7.2 released Message-ID: Hello, I am pleased to announce the release of Enthought Python Distribution, EPD version 7.2, along with its "EPD Free" counterpart. The highlights of this release are: the addition of GDAL and updates to over 30 packages, including SciPy, matplotlib and IPython. The new IPython 0.12 includes the HTML notebook, which caused the Tornado web-server also to be added to EPD. To see which libraries are included in the free vs. full version, please see: http://www.enthought.com/products/epdlibraries.php The complete list of additions, updates and fixes is in the change log: http://www.enthought.com/products/changelog.php About EPD --------- The Enthought Python Distribution (EPD) is a "kitchen-sink-included" distribution of the Python programming language, including over 90 additional tools and libraries. The EPD bundle includes NumPy, SciPy, IPython, 2D and 3D visualization tools, and many other tools. EPD is currently available as a single-click installer for Windows XP, Vista and 7, MacOS (10.5 and 10.6), RedHat 3, 4, 5 and 6, as well as Solaris 10 (x86 and x86_64/amd64 on all platforms). All versions of EPD (32 and 64-bit) are free for academic use. An annual subscription including installation support is available for individual and commercial use. Additional support options, including customization, bug fixes and training classes are also available: http://www.enthought.com/products/epd_sublevels.php - Ilan From takowl at gmail.com Fri Dec 23 13:04:32 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Fri, 23 Dec 2011 18:04:32 +0000 Subject: [IPython-dev] You can help ipython: port the faq to the new wiki In-Reply-To: References: Message-ID: When I was rearranging content, I thought the FAQ deserved to be on the main website, which is why they weren't on the new wiki: http://ipython.org/faq.html Note that these have been updated a bit since then, although there's probably more that could be done - e.g. we shouldn't mention Python 2.4 and 2.5, as it implies IPython still works there. Pull requests welcome at https://github.com/ipython/ipython-website Sorry I wasn't online sooner to point this out. Thomas On 22 December 2011 19:31, Nicolas Rougier wrote: > > Just did the port. Hope it's ok. > > (It lacks the IpythonOnWindows link & page, I will try to work on it too). > > By the way, last question may require some update. > > > Nicolas > > > On Dec 22, 2011, at 19:20 , Fernando Perez wrote: > > > Hi all, > > > > here's something an enterprising user could give us a hand with, if > > you'd like to contribute to the project. When we moved our wiki from > > the old moin instance to our new website, it seems we missed the FAQ > > and possibly other similar pages. > > > > The old one is here: > > > > http://ipython.scipy.org/Wiki/FAQ > > > > and I've made a placeholder here: > > > > http://wiki.ipython.org/FrequentlyAskedQuestions > > > > If you could help us in porting that old page over, it would be > > awesome. Some syntax conversions may be necessary, I set the > > placeholder to use reST so that we can more easily move information > > back and forth from the manual into the faq. > > > > Bonus points for any other pages you may find out that we missed and > > that you can help us with porting. > > > > Best > > > > 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 satra at mit.edu Sat Dec 24 12:12:46 2011 From: satra at mit.edu (Satrajit Ghosh) Date: Sat, 24 Dec 2011 18:12:46 +0100 Subject: [IPython-dev] pycharm now supports ipython 0.11 In-Reply-To: References: Message-ID: > > Great! Do you know if it works with current master as well? And what > specific ipython support does it provide? > it looks like they included 0.11 and probably in the terminal mode (not the two process kernel mode - anyway to quickly test?) cheers, satra here are some outputs --- /software/virtualenvs.EPD/7.1/devpype/bin/python -u /Applications/PyCharm.app/helpers/pydev/pydevconsole.py 49830 49831 PyDev console: using IPython 0.11 import sys; print('Python %s on %s' % (sys.version, sys.platform)) Python 2.7.2 |CUSTOM| (default, Jul 3 2011, 15:56:02) [GCC 4.0.1 (Apple Inc. build 5493)] on darwin sys.path.extend(['/Applications/PyCharm.app/helpers', '/software/nipy-repo/scikit-learn']) >>> %magic IPython's 'magic' functions =========================== --- another place: --- >>> a = dict(foo=1, goo=2) >>> a.keys() Out[1]: ['goo', 'foo'] >>> _1 Out[1]: ['goo', 'foo'] --- -------------- next part -------------- An HTML attachment was scrubbed... URL: From satra at mit.edu Sat Dec 24 12:13:28 2011 From: satra at mit.edu (Satrajit Ghosh) Date: Sat, 24 Dec 2011 18:13:28 +0100 Subject: [IPython-dev] pycharm now supports ipython 0.11 In-Reply-To: References: Message-ID: sorry 0.11 didn't have the two process mode anyway! cheers, satra On Sat, Dec 24, 2011 at 6:12 PM, Satrajit Ghosh wrote: > Great! Do you know if it works with current master as well? And what >> specific ipython support does it provide? >> > > it looks like they included 0.11 and probably in the terminal mode (not > the two process kernel mode - anyway to quickly test?) > > cheers, > > satra > > here are some outputs > > --- > /software/virtualenvs.EPD/7.1/devpype/bin/python -u > /Applications/PyCharm.app/helpers/pydev/pydevconsole.py 49830 49831 > PyDev console: using IPython 0.11 > import sys; print('Python %s on %s' % (sys.version, sys.platform)) > Python 2.7.2 |CUSTOM| (default, Jul 3 2011, 15:56:02) > [GCC 4.0.1 (Apple Inc. build 5493)] on darwin > sys.path.extend(['/Applications/PyCharm.app/helpers', > '/software/nipy-repo/scikit-learn']) > >>> %magic > > IPython's 'magic' functions > =========================== > --- > > another place: > --- > >>> a = dict(foo=1, goo=2) > >>> a.keys() > Out[1]: ['goo', 'foo'] > >>> _1 > Out[1]: ['goo', 'foo'] > --- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Sat Dec 24 12:47:04 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Sat, 24 Dec 2011 17:47:04 +0000 Subject: [IPython-dev] pycharm now supports ipython 0.11 In-Reply-To: References: Message-ID: On 24 December 2011 17:13, Satrajit Ghosh wrote: > sorry 0.11 didn't have the two process mode anyway! It did, that's how the Qt console works. One easy way to check what it's using: import sys sys.stdout If the repr() of stdout looks like "', mode 'w' at 0xb787a078>", it's just running in a terminal. If it mentions an OutStream object (IIRC), it's ZMQ based. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From satra at mit.edu Sat Dec 24 12:58:27 2011 From: satra at mit.edu (Satrajit Ghosh) Date: Sat, 24 Dec 2011 18:58:27 +0100 Subject: [IPython-dev] pycharm now supports ipython 0.11 In-Reply-To: References: Message-ID: > > > It did, that's how the Qt console works. hi thomas, sorry. should have been a little more precise. the terminal didn't have the two process option. :) > One easy way to check what it's using: > > import sys > sys.stdout > thanks >>> sys.stdout Out[1]: ', mode 'w' at 0x10028a1e0> so terminal based. cheers, satra -------------- next part -------------- An HTML attachment was scrubbed... URL: