From takowl at gmail.com Thu Sep 1 02:24:56 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Thu, 1 Sep 2011 07:24:56 +0100 Subject: [IPython-dev] [PEAK] simplegeneric & Python 3 In-Reply-To: <20110901025501.5946D3A4069@sparrow.telecommunity.com> References: <CAOvn4qgBz1B1W4VLJT3pi1rNHx8kV_sqadjPd8K0FxL0m-pu6g@mail.gmail.com> <20110901025501.5946D3A4069@sparrow.telecommunity.com> Message-ID: <CAOvn4qi+ccxe2EXcgjudar4JRr8C8Treii3jaLUVNvgQ5Avq8A@mail.gmail.com> Great - thanks for this. IPython people, we should "upgrade" the bundled simplegeneric to 0.8, although the code changes are probably minimal. Thomas On 1 September 2011 03:54, P.J. Eby <pje at telecommunity.com> wrote: > At 04:01 PM 8/14/2011 +0100, Thomas Kluyver wrote: > >> Hi, >> >> While working on IPython, I've patched simplegeneric to work with Python >> 3. It didn't require any major changes. The diff is here if you want to >> incorporate it: >> >> <https://github.com/takluyver/**ipython/commit/** >> 34f06125b2f989f0d096f57642a2a0**196c98bb1a<https://github.com/takluyver/ipython/commit/34f06125b2f989f0d096f57642a2a0196c98bb1a> >> >https://github.com/**takluyver/ipython/commit/** >> 34f06125b2f989f0d096f57642a2a0**196c98bb1a<https://github.com/takluyver/ipython/commit/34f06125b2f989f0d096f57642a2a0196c98bb1a> >> >> >> Our installation process for Python 3 runs all the code through 2to3, but >> that doesn't actually make any changes to simplegeneric, so with this patch, >> it should be directly usable in Python 3. >> > > I've implemented a similar change in SVN now (with a revamped test suite as > well), and released simplegeneric 0.8 to PyPI. Thanks for the report! > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110901/de107935/attachment.html> From pivanov314 at gmail.com Thu Sep 1 21:49:41 2011 From: pivanov314 at gmail.com (Paul Ivanov) Date: Thu, 1 Sep 2011 18:49:41 -0700 Subject: [IPython-dev] msg_type moved to 'header'? Message-ID: <20110902014941.GE2763@ykcyc> Hey there, I just updated trunk and had to spend some time tracking down why vim-ipython's shell wasn't working like it was in 0.11 turns out that 'msg_type' moved from being just inside a messsage, to being inside a message's header, i.e. m['msg_type'] is now m['header']['msg_type'] I made a pull request for a note about this backwards incompatible change to be included in development.txt - but wonder if this change is worth making. (ok, i see it is, figured it out as I wrote this) <naive me> I can imagine there might be folks out there writing ipython integrated applications using the messaging spec in 0.11, perhaps to interface with a text editor, that'll have to support both versions of the spec, but it's not clear what the win is of moving msg_type to the header. Do these hypothetical folks have to bite the bullet this time around, or might there be some recourse and a backwards-compatible reinstatement of 'msg_type' to top level. </naive me> oh, it looks like in 0.11 'msg_type' was replicated in both the top level and in the header, so the above all makes sense now, and top level removal is not that big of a deal. so consider this message being encouragement to document these type of changes as they're merged. :) best, -- Paul Ivanov 314 address only used for lists, off-list direct email at: http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110901/52a372da/attachment.sig> From benjaminrk at gmail.com Fri Sep 2 14:57:58 2011 From: benjaminrk at gmail.com (MinRK) Date: Fri, 2 Sep 2011 11:57:58 -0700 Subject: [IPython-dev] msg_type moved to 'header'? In-Reply-To: <20110902014941.GE2763@ykcyc> References: <20110902014941.GE2763@ykcyc> Message-ID: <CAHNn8BWigK0JLYi9D8EkCOaowsNH3J57RiTTiaWExKpg5fypbw@mail.gmail.com> Paul, thanks for the catch. After chatting with Brian, I am going to restore the msg_id/msg_type aliases to the top-level of the msg dict. They have always been in the header, because the header/parent/content are the only things sent over the wire. But it still makes sense for msg_id/msg_type to be accessible in the top level of the dict. I'll make sure the docs reflect this as well. We should definitely be more careful changing published specs. -MinRK On Thu, Sep 1, 2011 at 18:49, Paul Ivanov <pivanov314 at gmail.com> wrote: > Hey there, > > I just updated trunk and had to spend some time tracking down why > vim-ipython's shell wasn't working like it was in 0.11 > > turns out that 'msg_type' moved from being just inside a messsage, to > being inside a message's header, i.e. m['msg_type'] is now > m['header']['msg_type'] > > I made a pull request for a note about this backwards > incompatible change to be included in development.txt - but > wonder if this change is worth making. (ok, i see it is, figured > it out as I wrote this) > > <naive me> > I can imagine there might be folks out there writing ipython > integrated applications using the messaging spec in 0.11, perhaps > to interface with a text editor, that'll have to support both > versions of the spec, but it's not clear what the win is of > moving msg_type to the header. > > Do these hypothetical folks have to bite the bullet this time > around, or might there be some recourse and a > backwards-compatible reinstatement of 'msg_type' to top level. > </naive me> > > oh, it looks like in 0.11 'msg_type' was replicated in both the > top level and in the header, so the above all makes sense now, > and top level removal is not that big of a deal. > > so consider this message being encouragement to document these > type of changes as they're merged. :) > > best, > -- > Paul Ivanov > 314 address only used for lists, off-list direct email at: > http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEARECAAYFAk5gNi4ACgkQe+cmRQ8+KPcNywCfa2h3aS1Hg2gUf3PUIQzP8aTT > nsMAniczwNeuZ2tHwmlUuSXDhlQ8WxBh > =di5j > -----END PGP SIGNATURE----- > > _______________________________________________ > 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: <http://mail.python.org/pipermail/ipython-dev/attachments/20110902/40d8bb31/attachment.html> From gael.varoquaux at normalesup.org Fri Sep 2 18:15:04 2011 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Sat, 3 Sep 2011 00:15:04 +0200 Subject: [IPython-dev] Hiring a junior developer on the scikit-learn Message-ID: <20110902221504.GE27778@phare.normalesup.org> Hi list, Once again, we are looking for a junior developer to work on the scikit-learn. Below is the official job posting. Unofficially I would like to stress that this is a unique opportunity to be payed for two years to work on learning and improving the scientific Python toolstack. Gael ________________________________________________________________________________ **Job Description** INRIA is looking to hire a young graduate on a 2-year position to help with the community-driven development of the open source machine learning in Python library, scikit-learn. The scikit-learn is one of the major machine-learning libraries in Python. It aims to be state-of-the-art on mid-size to large datasets by harnessing the power of the scientific Python toolstack. Speaking French is not a requirement, as it is an international team. **Requirements** * Programming skills in Python and C/C++ * Understanding of quality assurance in software development: test-driven programming, version control, technical documentation. * Some knowledge of Linux/Unix * Software design skills * Knowledge of open-source development and community-driven environments * Good technical English level * An experience in statistical learning or a mathematical-oriented mindset is a plus * We can only hire a young-graduate that has received a masters or equivalent degree at most a year ago. **About the company** INRIA is the French computer science research institute. It recognized word-wide as one of the leading research institutions and has a strong expertise in machine learning. You will be working in the `Parietal team <https://parietal.saclay.inria.fr/>`_ that makes a heavy use of Python for brain imaging analysis. Parietal is a small research team (around 10 people) with an excellent technical knowledge of scientific and numerical computing in Python as well as a fine understanding of algorithmic issues in machine learning and statistics. Parietal is committed to investing in scikit-learn. Working at Parietal is a unique opportunity to improve your skills in machine learning and numerical computing in Python. In addition, working full time on the scikit-learn, a very active open-source project, will give you premium experience of open source community management and collaborative project development. **Contact Info:** * **Technical Contact**: Bertand Thirion * **E-mail contact**: bertrand.thirion at inria.fr * **HR Contact**: Marie Domingues * **E-mail Contact**: marie.domingues at inria.fr * **No telecommuting** From kroger at pedrokroger.net Fri Sep 2 23:12:22 2011 From: kroger at pedrokroger.net (Pedro Kroger) Date: Sat, 3 Sep 2011 00:12:22 -0300 Subject: [IPython-dev] ipython.el is broken in 0.11 Message-ID: <26B43868-35D7-43C3-8EE1-F5ACC4F9E671@pedrokroger.net> Hi, congrats on the release, lots of good stuff! But, ipython.el is broken in 0.11 (I tested with emacs 23.3). This pull request uses the new --color=foo syntax: https://github.com/ipython/ipython/pull/757 Also, completion is not working on ipython.el shell. I get things like "Can't find completion for "os.path."" Thanks, Pedro From takowl at gmail.com Sat Sep 3 06:15:33 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Sat, 3 Sep 2011 11:15:33 +0100 Subject: [IPython-dev] ipython.el is broken in 0.11 In-Reply-To: <26B43868-35D7-43C3-8EE1-F5ACC4F9E671@pedrokroger.net> References: <26B43868-35D7-43C3-8EE1-F5ACC4F9E671@pedrokroger.net> Message-ID: <CAOvn4qiVvOq1aiNpA1_8QgXpfk7HNHcX-CzuDG8zDyOmjsBmYg@mail.gmail.com> On 3 September 2011 04:12, Pedro Kroger <kroger at pedrokroger.net> wrote: > But, ipython.el is broken in 0.11 (I tested with emacs 23.3). > This pull request uses the new --color=foo syntax: > > https://github.com/ipython/ipython/pull/757 > > Also, completion is not working on ipython.el shell. I get things like > "Can't find completion for "os.path."" > Thanks, Pedro. If you're comfortable working with emacs lisp, feel free to make more extensive changes to ipython.el, or to write a new one. Paul Ivanov recently wrote a very nice IPython integration layer for vim, using the new ZMQ protocol. I'm sure emacs users would love something similar, but so far no-one's been motivated to write it. Best wishes, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110903/c3832707/attachment.html> From takowl at gmail.com Sat Sep 3 07:11:14 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Sat, 3 Sep 2011 12:11:14 +0100 Subject: [IPython-dev] Pull requests summary Message-ID: <CAOvn4qiJkcpqkW8f6gnMC_RP-byBo6uFCM0TY2e4cdumN-dA=A@mail.gmail.com> We're once again at risk of drowning in pull requests, so here's a summary, roughly grouped by size: Small: - 754: [Min] restores something that was removed from the messaging protocol since 0.11. - 753: [Paul] (superseded by 754) - 757: [Pedro Kroger] Fixes for ipython.el - 750: [Valentin Haenel] Docs stuff. Should just need to rebuild the docs and check the output. - 748: [Brian] Excludes notebook tests if Tornado isn't present. I'll test this in a minute. - 725: [Min] Check for PySide/PyQT version for frontend. OKed by Eric. - 722: [Thomas] Gets terminal IPython working on PyPy. Medium - 746: [Pauli Virtanen] Updates the autoreload extension and brings it out of quarantine. - 745: [Min] Protects the Qt console against failing history requests. Eric has given it a thumbs up, but plans to work on a more general solution. - 743: [Nicolas] Pyglet event loop integration. - 742: [Nicolas] Glut event loop integration. Fernando has already dived into reviewing it. - 741: [Eric Firing] Keep plot windows interactive while in the pager. Has a minor side effect. - 736: [Satra] Authentication for web notebook. Extensive discussion with Min & Brian. - 668: [rabbitmcrabbit?] Updates the quarantined greedy completer. Some work still to be done. Min/Fernando to give information on the config system. - 664: [Erik] Updates for the documentation. I'll merge it in shortly. - 622: [Jens Nielsen] Add config option for whether Pylab should import all. Fernando to do final review. - 506: [Martin Spacek] Makes return replicate the cell under the cursor, in the Qt console. Martin to do some more work on it. Large: - 708: [Omar, Min, Thomas] Adds a simple terminal-based frontend for the ZMQ protocol. We probably don't want to spend a lot of time on this, but it would be good to offer it in some form, for people who're SSHing in and can't install frontends on their own machine. - 663: [Thomas] Python 3 compatibility work. Rebased after the notebook work, but I need to rebase again. I'd also like some feedback on how best to handle doctests, but that needn't block merging the PR. - 648: [Thomas] Rework user namespaces and modules - should allow pickling objects defined interactively. This goes to the heart of how we run code, so it could do with a serious review. - 507: [Thomas] Separate prompt manager from displayhook. Fernando, Min and I were working this out, but we all got a bit busy. I'll send a separate email about it. - 433: (Superseded by 708, will close). Thanks everyone, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110903/2a104840/attachment.html> From takowl at gmail.com Sat Sep 3 08:22:51 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Sat, 3 Sep 2011 13:22:51 +0100 Subject: [IPython-dev] Link styles in documentation Message-ID: <CAOvn4qhE9_65rdTxWa-q8dJpz3qbw7brm7PBFqYSb2wZrRt-iA@mail.gmail.com> It seems Sphinx lets us insert two distinct kinds of links: `link`_ puts the link inline, while [link]_ points you to a footnote for the link (reST calls this a citation), and we're using something of a mixture of the two. In principle, reST should format `link`_ according to the output, so when we generate a PDF, it should appear as a footnote (the 'call-out form'). It seems Sphinx doesn't take advantage of this and leaves `link`_ inline for the PDF output. I suggest that we use `link`_ formatting consistently, and enable the sphinx options latex_show_urls and latex_show_pagerefs. This will mean links are a single click in our HTML output, and internal & external links can be read in the printed PDF output (The URL or page reference appears in brackets after the link). Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110903/a3ec0277/attachment.html> From takowl at gmail.com Sat Sep 3 08:53:53 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Sat, 3 Sep 2011 13:53:53 +0100 Subject: [IPython-dev] Prompt manager Message-ID: <CAOvn4qjMGxxAXQJMuVrSx2vyQwhqPREYNsuFwOm2TPEefJsSFA@mail.gmail.com> There were a couple of questions we've not yet resolved about the prompt manager code (see discussion at https://github.com/ipython/ipython/pull/507). First, for generating prompts over ZMQ, we intended to use the user_expressions field of an execution request, but this can't easily access things that aren't in the user namespace, e.g. os.getcwd(). We can work round that using the __import__("os").getcwd() form, but it feels somewhat less than ideal. This can however be resolved at a later stage, because the frontends currently generate prompts by themselves - my primary aim with this is to simplify the rather convoluted code generating prompts for the plain terminal. Second, we've ended up with three versions of EvalFormatter: A - Would evaluate {n/4}, but would treat {2} as a reference to a positional argument. B - Would evaluate {2} as an integer literal (so it's equivalent to just putting 2 in the string). C - Unlike A & B, will rejoin format strings to objects, so {a[:2]} will slice, but you lose the ability to do format strings {date:%Y-%m-%d} We were leaning towards keeping format strings separate for prompts (you can still slice using {a[slice(None,2)]} ), but do we want to keep C around for any other purpose in the code? I'd favour using A - it's flexible enough to use positional arguments if we do want to for any reason, and I don't see a use case for putting integer literals inside format {}s. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110903/c1e6e0c7/attachment.html> From andresete.chaos at gmail.com Sat Sep 3 21:22:57 2011 From: andresete.chaos at gmail.com (=?ISO-8859-1?Q?Omar_Andr=E9s_Zapata_Mesa?=) Date: Sat, 3 Sep 2011 20:22:57 -0500 Subject: [IPython-dev] Pull requests summary In-Reply-To: <CAOvn4qiJkcpqkW8f6gnMC_RP-byBo6uFCM0TY2e4cdumN-dA=A@mail.gmail.com> References: <CAOvn4qiJkcpqkW8f6gnMC_RP-byBo6uFCM0TY2e4cdumN-dA=A@mail.gmail.com> Message-ID: <CAOB9epqdfq1YO9-DNGaztNxPUkWspUFGKDqs+o+pZGZ2=_ANPA@mail.gmail.com> Hi all. Thanks Thomas. do you need that I update the pull request 708? do you have some suggestion? is not needed this code? I would appreciate any suggestions because I want to make this contribution to the project. If you think this should be rewritten or redesigned, please tell me. thanks ipython team. On Sat, Sep 3, 2011 at 6:11 AM, Thomas Kluyver <takowl at gmail.com> wrote: > We're once again at risk of drowning in pull requests, so here's a summary, > roughly grouped by size: > > Small: > - 754: [Min] restores something that was removed from the messaging > protocol since 0.11. > - 753: [Paul] (superseded by 754) > - 757: [Pedro Kroger] Fixes for ipython.el > - 750: [Valentin Haenel] Docs stuff. Should just need to rebuild the docs > and check the output. > - 748: [Brian] Excludes notebook tests if Tornado isn't present. I'll test > this in a minute. > - 725: [Min] Check for PySide/PyQT version for frontend. OKed by Eric. > - 722: [Thomas] Gets terminal IPython working on PyPy. > > Medium > - 746: [Pauli Virtanen] Updates the autoreload extension and brings it out > of quarantine. > - 745: [Min] Protects the Qt console against failing history requests. Eric > has given it a thumbs up, but plans to work on a more general solution. > - 743: [Nicolas] Pyglet event loop integration. > - 742: [Nicolas] Glut event loop integration. Fernando has already dived > into reviewing it. > - 741: [Eric Firing] Keep plot windows interactive while in the pager. Has > a minor side effect. > - 736: [Satra] Authentication for web notebook. Extensive discussion with > Min & Brian. > - 668: [rabbitmcrabbit?] Updates the quarantined greedy completer. Some > work still to be done. Min/Fernando to give information on the config > system. > - 664: [Erik] Updates for the documentation. I'll merge it in shortly. > - 622: [Jens Nielsen] Add config option for whether Pylab should import > all. Fernando to do final review. > - 506: [Martin Spacek] Makes return replicate the cell under the cursor, in > the Qt console. Martin to do some more work on it. > > Large: > - 708: [Omar, Min, Thomas] Adds a simple terminal-based frontend for the > ZMQ protocol. We probably don't want to spend a lot of time on this, but it > would be good to offer it in some form, for people who're SSHing in and > can't install frontends on their own machine. > - 663: [Thomas] Python 3 compatibility work. Rebased after the notebook > work, but I need to rebase again. I'd also like some feedback on how best to > handle doctests, but that needn't block merging the PR. > - 648: [Thomas] Rework user namespaces and modules - should allow pickling > objects defined interactively. This goes to the heart of how we run code, so > it could do with a serious review. > - 507: [Thomas] Separate prompt manager from displayhook. Fernando, Min and > I were working this out, but we all got a bit busy. I'll send a separate > email about it. > - 433: (Superseded by 708, will close). > > Thanks everyone, > Thomas > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > -- Omar Andres Zapata Mesa Systems Engineering Student Universidad de Antioquia At Medellin - Colombia User Linux #490962 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110903/11cacb28/attachment.html> From takowl at gmail.com Sun Sep 4 07:38:27 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Sun, 4 Sep 2011 12:38:27 +0100 Subject: [IPython-dev] Pull requests summary In-Reply-To: <CAOB9epqdfq1YO9-DNGaztNxPUkWspUFGKDqs+o+pZGZ2=_ANPA@mail.gmail.com> References: <CAOvn4qiJkcpqkW8f6gnMC_RP-byBo6uFCM0TY2e4cdumN-dA=A@mail.gmail.com> <CAOB9epqdfq1YO9-DNGaztNxPUkWspUFGKDqs+o+pZGZ2=_ANPA@mail.gmail.com> Message-ID: <CAOvn4qjKmLnJA=O7KiQk7eC2WPJDhDpCZWPttvNfrKs1brN7Sg@mail.gmail.com> 2011/9/4 Omar Andr?s Zapata Mesa <andresete.chaos at gmail.com> > Hi all. > Thanks Thomas. > do you need that I update the pull request 708? > do you have some suggestion? > is not needed this code? > The code is certainly useful - thanks for your work on it. Min says in the PR that hitting Ctrl-C from the ZMQ terminal at present crashes the kernel, so if you've got time to do some more work on it, that would definitely be a good place to start. The PR is based on Min's branch at the moment, so probably the best thing is to branch from his branch, and make a pull request back to him (like I did to work on your branch). Don't hesitate to ask about the code here on the list. Best wishes, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110904/4edfe6cb/attachment.html> From andresete.chaos at gmail.com Sun Sep 4 14:31:25 2011 From: andresete.chaos at gmail.com (=?ISO-8859-1?Q?Omar_Andr=E9s_Zapata_Mesa?=) Date: Sun, 4 Sep 2011 13:31:25 -0500 Subject: [IPython-dev] Pull requests summary In-Reply-To: <CAOvn4qjKmLnJA=O7KiQk7eC2WPJDhDpCZWPttvNfrKs1brN7Sg@mail.gmail.com> References: <CAOvn4qiJkcpqkW8f6gnMC_RP-byBo6uFCM0TY2e4cdumN-dA=A@mail.gmail.com> <CAOB9epqdfq1YO9-DNGaztNxPUkWspUFGKDqs+o+pZGZ2=_ANPA@mail.gmail.com> <CAOvn4qjKmLnJA=O7KiQk7eC2WPJDhDpCZWPttvNfrKs1brN7Sg@mail.gmail.com> Message-ID: <CAOB9epoE5JhPZQYHjgzbBY+u9Xm10X2GQ0FD2HW2UtomhEJYBQ@mail.gmail.com> ok! thanks thomas, I am working on the code. best regards Omar 2011/9/4 Thomas Kluyver <takowl at gmail.com> > 2011/9/4 Omar Andr?s Zapata Mesa <andresete.chaos at gmail.com> > >> Hi all. >> Thanks Thomas. >> do you need that I update the pull request 708? >> > do you have some suggestion? >> is not needed this code? >> > > The code is certainly useful - thanks for your work on it. > > Min says in the PR that hitting Ctrl-C from the ZMQ terminal at present > crashes the kernel, so if you've got time to do some more work on it, that > would definitely be a good place to start. The PR is based on Min's branch > at the moment, so probably the best thing is to branch from his branch, and > make a pull request back to him (like I did to work on your branch). Don't > hesitate to ask about the code here on the list. > > Best wishes, > Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110904/0f51d97a/attachment.html> From fperez.net at gmail.com Tue Sep 6 14:04:02 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 6 Sep 2011 11:04:02 -0700 Subject: [IPython-dev] Link styles in documentation In-Reply-To: <CAOvn4qhE9_65rdTxWa-q8dJpz3qbw7brm7PBFqYSb2wZrRt-iA@mail.gmail.com> References: <CAOvn4qhE9_65rdTxWa-q8dJpz3qbw7brm7PBFqYSb2wZrRt-iA@mail.gmail.com> Message-ID: <CAHAreOq2-oyuOVRn5QxF7GP0k-7NUQUYvZC6PCcHLvNLjnZWPQ@mail.gmail.com> On Sat, Sep 3, 2011 at 5:22 AM, Thomas Kluyver <takowl at gmail.com> wrote: > It seems Sphinx lets us insert two distinct kinds of links: `link`_ puts the > link inline, while [link]_ points you to a footnote for the link (reST calls > this a citation), and we're using something of a mixture of the two. In > principle, reST should format `link`_ according to the output, so when we > generate a PDF, it should appear as a footnote (the 'call-out form'). It > seems Sphinx doesn't take advantage of this and leaves `link`_ inline for > the PDF output. > > I suggest that we use `link`_ formatting consistently, and enable the sphinx > options latex_show_urls?and latex_show_pagerefs. This will mean links are a > single click in our HTML output, and internal & external links can be read > in the printed PDF output (The URL or page reference appears in brackets > after the link). +1 Feel free to update these at will as you encounter them without a PR; from your recent (much welcome) summary it's obvious we need to preserve our limited review resources for pure code, so be liberal with doc updates. We all trust each other and can clean up little slip-ups later if need be. Cheers, f From fperez.net at gmail.com Tue Sep 6 14:05:25 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 6 Sep 2011 11:05:25 -0700 Subject: [IPython-dev] msg_type moved to 'header'? In-Reply-To: <CAHNn8BWigK0JLYi9D8EkCOaowsNH3J57RiTTiaWExKpg5fypbw@mail.gmail.com> References: <20110902014941.GE2763@ykcyc> <CAHNn8BWigK0JLYi9D8EkCOaowsNH3J57RiTTiaWExKpg5fypbw@mail.gmail.com> Message-ID: <CAHAreOqm5rgqO-gqRR=XviXaW_3Qu2gSz3O3u1StG6dT28TdNg@mail.gmail.com> On Fri, Sep 2, 2011 at 11:57 AM, MinRK <benjaminrk at gmail.com> wrote: > > I'll make sure the docs reflect this as well. ?We should definitely be more > careful changing published specs. +1 We're starting to have this strange thing called 'users' of the actual protocol :) Ah, the painful price of success... :) Cheers, f ps - thanks to Paul for the catch! From satra at mit.edu Sat Sep 10 14:39:44 2011 From: satra at mit.edu (Satrajit Ghosh) Date: Sat, 10 Sep 2011 14:39:44 -0400 Subject: [IPython-dev] mayavi with ipython Message-ID: <CA+A4wOnkvm07XSAb5+a9-JfPZai=rPDNTY-cpSjKiGJMRW5LYg@mail.gmail.com> hi, we would like to launch a simple interactive mayavi window. --- from mayavi import mlab mlab.test_mesh() mlab.show() --- but we would like this to launch from the terminal and return us an ipython prompt so that we can interact with the objects. unfortunately, we don't understand the event loop interactions too well. any ideas on how to achieve this? cheers, satra -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110910/c4463a6b/attachment.html> From fperez.net at gmail.com Sat Sep 10 15:35:55 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 10 Sep 2011 12:35:55 -0700 Subject: [IPython-dev] mayavi with ipython In-Reply-To: <CA+A4wOnkvm07XSAb5+a9-JfPZai=rPDNTY-cpSjKiGJMRW5LYg@mail.gmail.com> References: <CA+A4wOnkvm07XSAb5+a9-JfPZai=rPDNTY-cpSjKiGJMRW5LYg@mail.gmail.com> Message-ID: <CAHAreOpSLwSGVgt4fndOr9uonkRYDmQkq=6N+6Xi7gih9LWhJA@mail.gmail.com> On Sat, Sep 10, 2011 at 11:39 AM, Satrajit Ghosh <satra at mit.edu> wrote: > we would like to launch a simple interactive mayavi window. > > --- > from mayavi import mlab > mlab.test_mesh() > mlab.show() > --- > > but we would like this to launch from the terminal and return us an ipython > prompt so that we can interact with the objects. unfortunately, we don't > understand the event loop interactions too well. > > any ideas on how to achieve this? One way: 1. put the code into a script, but do NOT call show() (which blocks): amirbar[~]> cat mv.py from enthought.mayavi import mlab mlab.test_mesh() 2. Start it as ipython --gui wx -i mv.py Cheers, f From fperez.net at gmail.com Sat Sep 10 15:42:46 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 10 Sep 2011 12:42:46 -0700 Subject: [IPython-dev] Prompt manager In-Reply-To: <CAOvn4qjMGxxAXQJMuVrSx2vyQwhqPREYNsuFwOm2TPEefJsSFA@mail.gmail.com> References: <CAOvn4qjMGxxAXQJMuVrSx2vyQwhqPREYNsuFwOm2TPEefJsSFA@mail.gmail.com> Message-ID: <CAHAreOpefZxus+a6M1DVWyxGe+hgusV+TEZezYZybNBGHhgTSA@mail.gmail.com> On Sat, Sep 3, 2011 at 5:53 AM, Thomas Kluyver <takowl at gmail.com> wrote: > > First, for generating prompts over ZMQ, we intended to use the > user_expressions field of an execution request, but this can't easily access > things that aren't in the user namespace, e.g. os.getcwd(). We can work > round that using the __import__("os").getcwd() form, but it feels somewhat > less than ideal. This can however be resolved at a later stage, because the > frontends currently generate prompts by themselves - my primary aim with > this is to simplify the rather convoluted code generating prompts for the > plain terminal. I've been thinking a fair bit about this issue, and I think we need to introduce an extra namespace, let's call it frontend_ns, that frontends can use to execute their code in, keep variables available without collisions with the user, etc. Then, things like prompt computations and similar could be done there. Granted, if multiple frontends are connected they'd be sharing this namespace, but at least it would be isolated from the user one. I think this would give us a lot of flexibility for interactions with the frontends. The need for an isolated space to manage prompts is what got me thinking along these lines, but I could imagine frontends keeping richer state and exposing a highly customized view to the user in a notebook, with an 'app' view, and then allowing them to further execute code in their own user_ns that only sees the data the app wants to expose. Thoughts? f From gael.varoquaux at normalesup.org Sat Sep 10 18:45:20 2011 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Sun, 11 Sep 2011 00:45:20 +0200 Subject: [IPython-dev] mayavi with ipython In-Reply-To: <CAHAreOpSLwSGVgt4fndOr9uonkRYDmQkq=6N+6Xi7gih9LWhJA@mail.gmail.com> References: <CA+A4wOnkvm07XSAb5+a9-JfPZai=rPDNTY-cpSjKiGJMRW5LYg@mail.gmail.com> <CAHAreOpSLwSGVgt4fndOr9uonkRYDmQkq=6N+6Xi7gih9LWhJA@mail.gmail.com> Message-ID: <20110910224520.GB24983@phare.normalesup.org> On Sat, Sep 10, 2011 at 12:35:55PM -0700, Fernando Perez wrote: > 1. put the code into a script, but do NOT call show() (which blocks): It used to be possible to write fool-proof code so that show would not block under IPython. This was very useful to make code that would work out of the box for users. Is this no longer possible? Gael From fperez.net at gmail.com Sat Sep 10 19:27:35 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 10 Sep 2011 16:27:35 -0700 Subject: [IPython-dev] mayavi with ipython In-Reply-To: <20110910224520.GB24983@phare.normalesup.org> References: <CA+A4wOnkvm07XSAb5+a9-JfPZai=rPDNTY-cpSjKiGJMRW5LYg@mail.gmail.com> <CAHAreOpSLwSGVgt4fndOr9uonkRYDmQkq=6N+6Xi7gih9LWhJA@mail.gmail.com> <20110910224520.GB24983@phare.normalesup.org> Message-ID: <CAHAreOoe20DjSU_6b5JNpd+9DcWG6pkf-cE0p=4yBQBMVNUYJQ@mail.gmail.com> On Sat, Sep 10, 2011 at 3:45 PM, Gael Varoquaux <gael.varoquaux at normalesup.org> wrote: > It used to be possible to write fool-proof code so that show would not > block under IPython. This was very useful to make code that would work > out of the box for users. Is this no longer possible? Now that we're not using threads for handling the GUI event loops, show() does indeed block, at least the ubuntu-provided version I have on my box. So it's possible that some tweaks are needed on the mayavi side to make show() non-blocking without the need for user intervention. I know it's possible because matplotlib from current master indeed works without blocking. It will be a matter of checking just what mpl is doing to avoid show() blocking and using the same idea in mayavi, I imagine. Cheers, f From fperez.net at gmail.com Mon Sep 12 18:02:14 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 12 Sep 2011 15:02:14 -0700 Subject: [IPython-dev] Experimental GLUT integration In-Reply-To: <08A5BCE9-54BB-4878-8C92-25CDEC87EF4E@inria.fr> References: <08A5BCE9-54BB-4878-8C92-25CDEC87EF4E@inria.fr> Message-ID: <CAHAreOoC=uN4vUBdTOOkJ7i+zVOoNcZK0_megQjomHfTw3tarw@mail.gmail.com> Hi folks, On Fri, Aug 26, 2011 at 10:30 AM, Nicolas Rougier <Nicolas.Rougier at inria.fr> wrote: > > I've coded an experimental GLUT integration (thanks to Fernando's explanations) for the new input hook system. I would like to know if people could test it and review if the code's ok.There is also an integration example in the docs/examples/lib/gui-glut.py > > You should be able to type: > > In [5]: %gui glut > In [6]: %run gui-glut.py > > At this point a small black window should appear > > In [7]: gl.glClearColor(1,1,1,1) > > The window color should change to white. Nicolas has made these into proper pull requests, both for glut and for pyglet: https://github.com/ipython/ipython/pull/742 https://github.com/ipython/ipython/pull/743 but as you can see from our discussions, there are still some lingering issues. If you have OpenGL knowledge, your help would be greatly appreciated, you can just comment on the discussions and I'm sure any feedback you can provide Nicolas will help. Ultimately it would be great to offer out of the box support for interactive control of glut and pyglet apps from IPython. Cheers, f From fperez.net at gmail.com Mon Sep 12 22:28:39 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 12 Sep 2011 19:28:39 -0700 Subject: [IPython-dev] Pull requests summary In-Reply-To: <CAOvn4qiJkcpqkW8f6gnMC_RP-byBo6uFCM0TY2e4cdumN-dA=A@mail.gmail.com> References: <CAOvn4qiJkcpqkW8f6gnMC_RP-byBo6uFCM0TY2e4cdumN-dA=A@mail.gmail.com> Message-ID: <CAHAreOpOaX5UFhdHTvHLhtRH6fc4z2suGfEnf08-NwH054jahg@mail.gmail.com> Thomas, many thanks for doing this. Since we've actually manged to make some progress and regain terrain, I'm updating your list with what's currently left. We should stress that we really welcome input from *anyone* on pull requests! Reviewing a contribution from someone else is a good way to start learning the project and its workflow, and it helps the core team by having more eyes on new code. So this is what's still on our plate: On Sat, Sep 3, 2011 at 4:11 AM, Thomas Kluyver <takowl at gmail.com> wrote: > We're once again at risk of drowning in pull requests, so here's a summary, > roughly grouped by size: > > Medium > - 746: [Pauli Virtanen] Updates the autoreload extension and brings it out > of quarantine. I started the review on this one, should be fairly painless. > - 743: [Nicolas] Pyglet event loop integration. > - 742: [Nicolas] Glut event loop integration. Fernando has already dived > into reviewing it. I've got these two in progress. Help from GL experts would be welcome, as I mentioned in another thread. > - 668: [rabbitmcrabbit?] Updates the quarantined greedy completer. Some work > still to be done. Min/Fernando to give information on the config system. Yup. Min, if you can give the OP a bit of guidance on the Config machinery here, that would be awesome. I'll try to help as well. > - 506: [Martin Spacek] Makes return replicate the cell under the cursor, in > the Qt console. Martin to do some more work on it. > Large: > - 708: [Omar, Min, Thomas] Adds a simple terminal-based frontend for the ZMQ > protocol. We probably don't want to spend a lot of time on this, but it > would be good to offer it in some form, for people who're SSHing in and > can't install frontends on their own machine. This one is actually important in that it will help us finalize the architectural breakdown into well-differentiated components that is already under way. It also means that it requires more bandwidth tahn we have available right now. > - 648: [Thomas] Rework user namespaces and modules - should allow pickling > objects defined interactively. This goes to the heart of how we run code, so > it could do with a serious review. I'll get to this one as soon as we flush the rest of the easy stuff, as it requires some dedicated effort. > - 507: [Thomas] Separate prompt manager from displayhook. Fernando, Min and > I were working this out, but we all got a bit busy. I'll send a separate > email about it. Already replied on that one, let's sort out the frontend_ns ideas and we should be able to finish this one. Thanks again for this status check! We've fortunately (thanks to everyone who's pitched in) made good progress since your original email, so I think the disaster of death-by-PR-drowning has been averted for now. Cheers, f From Nicolas.Rougier at inria.fr Tue Sep 13 07:39:41 2011 From: Nicolas.Rougier at inria.fr (Nicolas Rougier) Date: Tue, 13 Sep 2011 13:39:41 +0200 Subject: [IPython-dev] Experimental GLUT integration In-Reply-To: <CAHAreOoC=uN4vUBdTOOkJ7i+zVOoNcZK0_megQjomHfTw3tarw@mail.gmail.com> References: <08A5BCE9-54BB-4878-8C92-25CDEC87EF4E@inria.fr> <CAHAreOoC=uN4vUBdTOOkJ7i+zVOoNcZK0_megQjomHfTw3tarw@mail.gmail.com> Message-ID: <D12A2582-36DD-44B9-98F0-AABE30BC1C58@inria.fr> I'm still fighting against glut and I would have one question: To make things work, I need to intercept SIGINT and to print explicitly 'KeyboardInterrupt' and then reprint the prompt. What is the best way to reprint the current prompt ? nicolas On Sep 13, 2011, at 0:02 , Fernando Perez wrote: > Hi folks, > > On Fri, Aug 26, 2011 at 10:30 AM, Nicolas Rougier > <Nicolas.Rougier at inria.fr> wrote: >> >> I've coded an experimental GLUT integration (thanks to Fernando's explanations) for the new input hook system. I would like to know if people could test it and review if the code's ok.There is also an integration example in the docs/examples/lib/gui-glut.py >> >> You should be able to type: >> >> In [5]: %gui glut >> In [6]: %run gui-glut.py >> >> At this point a small black window should appear >> >> In [7]: gl.glClearColor(1,1,1,1) >> >> The window color should change to white. > > Nicolas has made these into proper pull requests, both for glut and for pyglet: > > https://github.com/ipython/ipython/pull/742 > https://github.com/ipython/ipython/pull/743 > > but as you can see from our discussions, there are still some > lingering issues. If you have OpenGL knowledge, your help would be > greatly appreciated, you can just comment on the discussions and I'm > sure any feedback you can provide Nicolas will help. > > Ultimately it would be great to offer out of the box support for > interactive control of glut and pyglet apps from IPython. > > Cheers, > > f From andresete.chaos at gmail.com Tue Sep 13 15:01:15 2011 From: andresete.chaos at gmail.com (=?ISO-8859-1?Q?Omar_Andr=E9s_Zapata_Mesa?=) Date: Tue, 13 Sep 2011 14:01:15 -0500 Subject: [IPython-dev] crtl+c annotations in zmq terminal for suggestions Message-ID: <CAOB9eprdVqeX3g8ki6nfgtOE=LQnZCMKhK-jnd47YZ+wVvP7ng@mail.gmail.com> hi all. Doing some tests in the zmq frontend I find the next things from minrk repo git://github.com/minrk/ipython.git in the branch termzmq ->open a new kernel but not using ipython/IPython/frontend/zmqterminal/app.py just run python -c "from IPython.zmq.ipkernel import main; main()" python -c "from IPython.zmq.ipkernel import main; main()" [IPKernelApp] To connect another client to this kernel, use: [IPKernelApp] --existing --shell=49587 --iopub=57815 --stdin=55774 --hb=33990 if you press crtl+c the kernel output is ^CKeyboardInterrupt caught in kernel that is right!! -> open in other console python app.py --existing --shell=49587 --iopub=57815 --stdin=55774 --hb=33990 and press crtl+c output KeyboardInterrupt --------------------------------------------------------------------------- RuntimeError Traceback (most recent call last) /usr/local/lib/python2.6/dist-packages/IPython/frontend/terminal/interactiveshell.pyc in raw_input(self, prompt) 338 339 try: --> 340 line = raw_input_original(prompt).decode(self.stdin_encoding) 341 except ValueError: 342 warn("\n********\nYou or a %run:ed script called sys.stdin.close()" /home/omazapa/MyProjects/ipython/IPython/frontend/zmqterminal/app.py in handle_sigint(self, *args) 143 # FIXME: this doesn't work, the kernel just dies every time 144 self.shell.write('KeyboardInterrupt\n') --> 145 self.kernel_manager.interrupt_kernel() 146 147 def init_code(self): /usr/local/lib/python2.6/dist-packages/IPython/zmq/kernelmanager.pyc in interrupt_kernel(self) 916 self.kernel.send_signal(signal.SIGINT) 917 else: --> 918 raise RuntimeError("Cannot interrupt kernel. No kernel is running!") 919 920 def signal_kernel(self, signum): RuntimeError: Cannot interrupt kernel. No kernel is running! -> it produces a ugly traceback but the kernel is not die. -> any know why is tell me that No kernel is running? (but the kernel is running) -> calling ipkernel directly show the next traceback -- Omar Andres Zapata Mesa Head Developer Phenomenology of Fundamental Interactions Group (Gfif) http://gfif.udea.edu.co Division of computer science Gfif Developers (Gfif Dev) http://gfifdev.udea.edu.co Systems Engineering Student Universidad de Antioquia At Medellin - Colombia Usuario Linux #490962 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110913/b63e7ea4/attachment.html> From benjaminrk at gmail.com Tue Sep 13 15:17:45 2011 From: benjaminrk at gmail.com (MinRK) Date: Tue, 13 Sep 2011 12:17:45 -0700 Subject: [IPython-dev] crtl+c annotations in zmq terminal for suggestions In-Reply-To: <CAOB9eprdVqeX3g8ki6nfgtOE=LQnZCMKhK-jnd47YZ+wVvP7ng@mail.gmail.com> References: <CAOB9eprdVqeX3g8ki6nfgtOE=LQnZCMKhK-jnd47YZ+wVvP7ng@mail.gmail.com> Message-ID: <CAHNn8BUx0MxWYMXjv6D6b6NQCNLKRBmSMLgTCGZq-UNLY6azCg@mail.gmail.com> 2011/9/13 Omar Andr?s Zapata Mesa <andresete.chaos at gmail.com> > hi all. > Doing some tests in the zmq frontend I find the next things > from minrk repo git://github.com/minrk/ipython.git in the branch termzmq > > ->open a new kernel but not using > ipython/IPython/frontend/zmqterminal/app.py > just run python -c "from IPython.zmq.ipkernel import main; main()" > You can start a kernel with just `ipython kernel` > > python -c "from IPython.zmq.ipkernel import main; main()" > [IPKernelApp] To connect another client to this kernel, use: > [IPKernelApp] --existing --shell=49587 --iopub=57815 --stdin=55774 > --hb=33990 > > if you press crtl+c the kernel output is > ^CKeyboardInterrupt caught in kernel > that is right!! > > -> open in other console > python app.py --existing --shell=49587 --iopub=57815 --stdin=55774 > --hb=33990 > Also, this can be started with just `ipython zmq ...` > > and press crtl+c > output > > KeyboardInterrupt > --------------------------------------------------------------------------- > RuntimeError Traceback (most recent call last) > /usr/local/lib/python2.6/dist-packages/IPython/frontend/terminal/interactiveshell.pyc > in raw_input(self, prompt) > > 338 > 339 try: > --> 340 line = > raw_input_original(prompt).decode(self.stdin_encoding) > 341 except ValueError: > 342 warn("\n********\nYou or a %run:ed script called > sys.stdin.close()" > > /home/omazapa/MyProjects/ipython/IPython/frontend/zmqterminal/app.py in > handle_sigint(self, *args) > > 143 # FIXME: this doesn't work, the kernel just dies every time > > 144 self.shell.write('KeyboardInterrupt\n') > --> 145 self.kernel_manager.interrupt_kernel() > 146 > 147 def init_code(self): > > /usr/local/lib/python2.6/dist-packages/IPython/zmq/kernelmanager.pyc in > interrupt_kernel(self) > > 916 self.kernel.send_signal(signal.SIGINT) > 917 else: > --> 918 raise RuntimeError("Cannot interrupt kernel. No kernel > is running!") > > 919 > 920 def signal_kernel(self, signum): > > RuntimeError: Cannot interrupt kernel. No kernel is running! > > -> it produces a ugly traceback but the kernel is not die. > -> any know why is tell me that No kernel is running? (but the kernel is > running) > -> calling ipkernel directly show the next traceback > External frontends cannot interrupt the kernel, because they know nothing about the kernel apart from its zmq ports. In the long run, we need to split the existing KernelManager into a thin KernelParent that starts, interrupts, and restarts, and a KernelClient that is actually used in frontends to issue commands. Doing this will allow interrupt and restart from all frontends, rather than just the owner. Obviously, the traceback shouldn't happen, but the interrupt behavior in general in the terminal frontend is quite wrong at the moment, and the principal part of that code in need of further development. -MinRK > > > -- > Omar Andres Zapata Mesa > Head Developer Phenomenology of Fundamental Interactions Group (Gfif) > http://gfif.udea.edu.co > Division of computer science Gfif Developers (Gfif Dev) > http://gfifdev.udea.edu.co > Systems Engineering Student > Universidad de Antioquia At Medellin - Colombia > Usuario Linux #490962 > > > _______________________________________________ > 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: <http://mail.python.org/pipermail/ipython-dev/attachments/20110913/d11bae0f/attachment.html> From fperez.net at gmail.com Tue Sep 13 16:14:00 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 13 Sep 2011 13:14:00 -0700 Subject: [IPython-dev] Experimental GLUT integration In-Reply-To: <D12A2582-36DD-44B9-98F0-AABE30BC1C58@inria.fr> References: <08A5BCE9-54BB-4878-8C92-25CDEC87EF4E@inria.fr> <CAHAreOoC=uN4vUBdTOOkJ7i+zVOoNcZK0_megQjomHfTw3tarw@mail.gmail.com> <D12A2582-36DD-44B9-98F0-AABE30BC1C58@inria.fr> Message-ID: <CAHAreOoJM5iK53aP=OtMWrkmvgxCfJN-RLiaBLxY7LhDYXg5BQ@mail.gmail.com> Hi Nicolas, On Tue, Sep 13, 2011 at 4:39 AM, Nicolas Rougier <Nicolas.Rougier at inria.fr> wrote: > > I'm still fighting against glut and I would have one question: > > To make things work, I need to intercept SIGINT and to print explicitly 'KeyboardInterrupt' and then reprint the prompt. > > What is the best way to reprint the current prompt ? odd as it sounds, there's no simple, clean way to reprint the current prompt (at least not in fully formatted form in color). You can get it with ip = get_ipython() prompt = ip.hooks.generate_prompt(False) but that string has embedded characters that for some reason mess up the line if you print them directly, though they show up correctly if passed as an argument to raw_input(prompt), which is how we actually use it. But I think it's ok if you simply print 'KeyboardInterrupt'. We already have other cases where this happens, and I think we're all used to just hitting Enter at that point, which cleanly redraws the prompt. Not ideal, but it should do for now. One of our big todo items is certainly a full restructuring of our prompt management machinery (for which PR #507 is a start), but you don't need to wait for that to happen. Cheers, f From ellisonbg at gmail.com Wed Sep 14 16:29:11 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Wed, 14 Sep 2011 13:29:11 -0700 Subject: [IPython-dev] Prompt manager In-Reply-To: <CAHAreOpefZxus+a6M1DVWyxGe+hgusV+TEZezYZybNBGHhgTSA@mail.gmail.com> References: <CAOvn4qjMGxxAXQJMuVrSx2vyQwhqPREYNsuFwOm2TPEefJsSFA@mail.gmail.com> <CAHAreOpefZxus+a6M1DVWyxGe+hgusV+TEZezYZybNBGHhgTSA@mail.gmail.com> Message-ID: <CAH4pYpR8sPXKVUmxsxwYmzrxtHZQcqd2TMm4nLb590oudFWM-w@mail.gmail.com> On Sat, Sep 10, 2011 at 12:42 PM, Fernando Perez <fperez.net at gmail.com> wrote: > On Sat, Sep 3, 2011 at 5:53 AM, Thomas Kluyver <takowl at gmail.com> wrote: >> >> First, for generating prompts over ZMQ, we intended to use the >> user_expressions field of an execution request, but this can't easily access >> things that aren't in the user namespace, e.g. os.getcwd(). We can work >> round that using the __import__("os").getcwd() form, but it feels somewhat >> less than ideal. This can however be resolved at a later stage, because the >> frontends currently generate prompts by themselves - my primary aim with >> this is to simplify the rather convoluted code generating prompts for the >> plain terminal. > > I've been thinking a fair bit about this issue, and I think we need to > introduce an extra namespace, let's call it frontend_ns, that > frontends can use to execute their code in, keep variables available > without collisions with the user, etc. ?Then, things like prompt > computations and similar could be done there. > Granted, if multiple frontends are connected they'd be sharing this > namespace, but at least it would be isolated from the user one. ?I > think this would give us a lot of flexibility for interactions with > the frontends. ?The need for an isolated space to manage prompts is > what got me thinking along these lines, but I could imagine frontends > keeping richer state and exposing a highly customized view to the user > in a notebook, with an 'app' view, and then allowing them to further > execute code in their own user_ns that only sees the data the app > wants to expose. > > Thoughts? I think this sounds like too much additional complexity for something that very few users ever touch. Every new feature we add is something we have to maintain, test, debug, etc. Also, in the notebook, we have to size the prompt area statically, so I don't think it makes sense to even allow prompt customization in that context. I *do* think that we should provide increasingly powerful and rich ways of displaying and interacting with data in the output area, but I don't think user data should start to creep into other parts of the UI. I am -1 on this. Cheers, Brian > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From fperez.net at gmail.com Wed Sep 14 19:18:21 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 14 Sep 2011 16:18:21 -0700 Subject: [IPython-dev] Prompt manager In-Reply-To: <CAH4pYpR8sPXKVUmxsxwYmzrxtHZQcqd2TMm4nLb590oudFWM-w@mail.gmail.com> References: <CAOvn4qjMGxxAXQJMuVrSx2vyQwhqPREYNsuFwOm2TPEefJsSFA@mail.gmail.com> <CAHAreOpefZxus+a6M1DVWyxGe+hgusV+TEZezYZybNBGHhgTSA@mail.gmail.com> <CAH4pYpR8sPXKVUmxsxwYmzrxtHZQcqd2TMm4nLb590oudFWM-w@mail.gmail.com> Message-ID: <CAHAreOr_L4XJ1wZkvJZwb1pHC7P+xvgzMHuawMjbMS8b3Xag7A@mail.gmail.com> On Wed, Sep 14, 2011 at 1:29 PM, Brian Granger <ellisonbg at gmail.com> wrote: > I think this sounds like too much additional complexity for something > that very few users ever touch. Well, the only complexity is really an optional field in the execute message, that's all. And it gives a clean mechanism for other frontends (not necessarily ones we maintain) to manage state in a robust way that doesn't mess with the user data. So in many ways it's a cleaner solution than what people are already doing with prompts, which requires them to work in the same user namespace and hope there are no collisions. Basically I'm proposing a way to help people do what they are *already doing* in a cleaner fashion, and in a way that adds extremely minimal complexity: one more dict to keep around, one more flag in that message. We don't even need a new message type for this. > Every new feature we add is something we have to maintain, test, > debug, etc. ?Also, in the notebook, we have to size the prompt area > statically, so I don't think it makes sense to even allow prompt > customization in that context. ?I *do* think that we should provide > increasingly powerful and rich ways of displaying and interacting with > data in the output area, but I don't think user data should start to > creep into other parts of the UI. ?I am -1 on this. Nobody said the notebook would need to concern itself with the prompts, we definitely agree that not all frontends will allow/honor prompt customization. All this does is allow frontends to do certain things without stepping on the user namespace. Currently they are doing it by sneaking around with silent=True, which is arguably a much worse and more dangerous solution, as it's prone to collisions and other problems caused by interference with user actions. I do think the frontend_ns *is* a simple, good solution to an existing problem. We discussed it with @minrk over lunch and he also seemed to be in agreement. Think about it... From fperez.net at gmail.com Thu Sep 15 15:05:07 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 15 Sep 2011 12:05:07 -0700 Subject: [IPython-dev] IPython mention on slashdot interview Message-ID: <CAHAreOpw9+HdQxOTDn=2zdKiJvAjkpy=vcpudaP0N=m99+XGsw@mail.gmail.com> http://interviews.slashdot.org/story/11/09/14/1554243/Eben-Upton-Answers-Your-Questions?utm_source=rss1.0mainlinkanon&utm_medium=feed Scroll to the 'Introduction to programming' question. We must be doing something right :) Cheers, f From ellisonbg at gmail.com Thu Sep 15 18:10:08 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Thu, 15 Sep 2011 15:10:08 -0700 Subject: [IPython-dev] IPython mention on slashdot interview In-Reply-To: <CAHAreOpw9+HdQxOTDn=2zdKiJvAjkpy=vcpudaP0N=m99+XGsw@mail.gmail.com> References: <CAHAreOpw9+HdQxOTDn=2zdKiJvAjkpy=vcpudaP0N=m99+XGsw@mail.gmail.com> Message-ID: <CAH4pYpTg0_etY1j5P8THwhwDFBX-6n8WCLsZFNrQViJJYdeVTw@mail.gmail.com> Yah! On Thu, Sep 15, 2011 at 12:05 PM, Fernando Perez <fperez.net at gmail.com> wrote: > http://interviews.slashdot.org/story/11/09/14/1554243/Eben-Upton-Answers-Your-Questions?utm_source=rss1.0mainlinkanon&utm_medium=feed > > Scroll to the 'Introduction to programming' question. > > We must be doing something right :) > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From ellisonbg at gmail.com Thu Sep 15 18:56:01 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Thu, 15 Sep 2011 15:56:01 -0700 Subject: [IPython-dev] Prompt manager In-Reply-To: <CAHAreOr_L4XJ1wZkvJZwb1pHC7P+xvgzMHuawMjbMS8b3Xag7A@mail.gmail.com> References: <CAOvn4qjMGxxAXQJMuVrSx2vyQwhqPREYNsuFwOm2TPEefJsSFA@mail.gmail.com> <CAHAreOpefZxus+a6M1DVWyxGe+hgusV+TEZezYZybNBGHhgTSA@mail.gmail.com> <CAH4pYpR8sPXKVUmxsxwYmzrxtHZQcqd2TMm4nLb590oudFWM-w@mail.gmail.com> <CAHAreOr_L4XJ1wZkvJZwb1pHC7P+xvgzMHuawMjbMS8b3Xag7A@mail.gmail.com> Message-ID: <CAH4pYpSy7Em859hZuy_ZZx8JOp-T2p85cYxG7bMRBiXhBo6aQw@mail.gmail.com> On Wed, Sep 14, 2011 at 4:18 PM, Fernando Perez <fperez.net at gmail.com> wrote: > On Wed, Sep 14, 2011 at 1:29 PM, Brian Granger <ellisonbg at gmail.com> wrote: >> I think this sounds like too much additional complexity for something >> that very few users ever touch. > > Well, the only complexity is really an optional field in the execute > message, that's all. ?And it gives a clean mechanism for other > frontends (not necessarily ones we maintain) to manage state in a > robust way that doesn't mess with the user data. ?So in many ways it's > a cleaner solution than what people are already doing with prompts, > which requires them to work in the same user namespace and hope there > are no collisions. Keep in mind that originally, I was 50/50 on adding user_variables and user_expressions to the execute message. The reason is that execute itself is a simple atomic operation. Adding these other things opens the door for secondary effects. I have gotten used to them being there and I think that they will get some usage for things like a namespace browser in the notebook. But, I do think there is a cost to having them there. > Basically I'm proposing a way to help people do what they are *already > doing* in a cleaner fashion, and in a way that adds extremely minimal > complexity: one more dict to keep around, one more flag in that > message. ?We don't even need a new message type for this. When users execute code in the other namespace would they have any access to the global user_ns? I would think that in most cases they would *want* that. IOW, are they completely isolated namespaces or is frontend_ns used as local() and user_ns as globals()? >> Every new feature we add is something we have to maintain, test, >> debug, etc. ?Also, in the notebook, we have to size the prompt area >> statically, so I don't think it makes sense to even allow prompt >> customization in that context. ?I *do* think that we should provide >> increasingly powerful and rich ways of displaying and interacting with >> data in the output area, but I don't think user data should start to >> creep into other parts of the UI. ?I am -1 on this. > > Nobody said the notebook would need to concern itself with the > prompts, we definitely agree that not all frontends will allow/honor > prompt customization. ?All this does is allow frontends to do certain > things without stepping on the user namespace. ?Currently they are > doing it by sneaking around with silent=True, which is arguably a much > worse and more dangerous solution, as it's prone to collisions and > other problems caused by interference with user actions. I agree that silent is not a very robust way of handling these things. > I do think the frontend_ns *is* a simple, good solution to an existing > problem. ?We discussed it with @minrk over lunch and he also seemed to > be in agreement. ?Think about it... I am still not thrilled, but I am fine being out voted on this. But I do think it makes sense to think more about exactly how it would work. Cheers, Brian -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From fperez.net at gmail.com Thu Sep 15 19:11:33 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 15 Sep 2011 16:11:33 -0700 Subject: [IPython-dev] Prompt manager In-Reply-To: <CAH4pYpSy7Em859hZuy_ZZx8JOp-T2p85cYxG7bMRBiXhBo6aQw@mail.gmail.com> References: <CAOvn4qjMGxxAXQJMuVrSx2vyQwhqPREYNsuFwOm2TPEefJsSFA@mail.gmail.com> <CAHAreOpefZxus+a6M1DVWyxGe+hgusV+TEZezYZybNBGHhgTSA@mail.gmail.com> <CAH4pYpR8sPXKVUmxsxwYmzrxtHZQcqd2TMm4nLb590oudFWM-w@mail.gmail.com> <CAHAreOr_L4XJ1wZkvJZwb1pHC7P+xvgzMHuawMjbMS8b3Xag7A@mail.gmail.com> <CAH4pYpSy7Em859hZuy_ZZx8JOp-T2p85cYxG7bMRBiXhBo6aQw@mail.gmail.com> Message-ID: <CAHAreOoYc5b1Y0joamjjPfBAZEdUhWebtUOCNTR22Ps5tvToGA@mail.gmail.com> On Thu, Sep 15, 2011 at 3:56 PM, Brian Granger <ellisonbg at gmail.com> wrote: > > I am still not thrilled, but I am fine being out voted on this. ?But I > do think it makes sense to think more about exactly how it would work. Well, the fact that we all disagree to some extent here is a good sign that we haven't fully found the best solution to the problem. So rather than rushing into a majority vote, I think our best approach is to keep thinking about it and understanding the design space and constraints. Sorry if it sounded like I was trying to 'outvote you', that wasn't my intent: I just wanted to bring their perspective to the table. In the past, more often than not we've seen how technical disagreement is a sign of insufficient understanding of a problem from one or more of us, and a good time to simply continue to mull over the problem. We're typically pretty good at agreeing once we've really found a good solution, so let's continue to trust that our instincts will work this time too :) We're in no major rush to make a decision here, and it's a fairly important question about the architecture of frontends and how they interact with the kernel and the user's namespace. I posted on the PR discussion (https://github.com/ipython/ipython/pull/507), where it seems we can continue most cleanly focused around the code, what I understand so far of the design boundaries. With a little patience, we should be able to figure out a really good solution to the whole thing that we're all happy with in the long term. Cheers, f From ellisonbg at gmail.com Thu Sep 15 20:19:42 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Thu, 15 Sep 2011 17:19:42 -0700 Subject: [IPython-dev] Prompt manager In-Reply-To: <CAHAreOoYc5b1Y0joamjjPfBAZEdUhWebtUOCNTR22Ps5tvToGA@mail.gmail.com> References: <CAOvn4qjMGxxAXQJMuVrSx2vyQwhqPREYNsuFwOm2TPEefJsSFA@mail.gmail.com> <CAHAreOpefZxus+a6M1DVWyxGe+hgusV+TEZezYZybNBGHhgTSA@mail.gmail.com> <CAH4pYpR8sPXKVUmxsxwYmzrxtHZQcqd2TMm4nLb590oudFWM-w@mail.gmail.com> <CAHAreOr_L4XJ1wZkvJZwb1pHC7P+xvgzMHuawMjbMS8b3Xag7A@mail.gmail.com> <CAH4pYpSy7Em859hZuy_ZZx8JOp-T2p85cYxG7bMRBiXhBo6aQw@mail.gmail.com> <CAHAreOoYc5b1Y0joamjjPfBAZEdUhWebtUOCNTR22Ps5tvToGA@mail.gmail.com> Message-ID: <CAH4pYpTTWZbHB0ZAiA=7eNqNX+Kkudo_WN4OJdkzv9a4QVNXyQ@mail.gmail.com> On Thu, Sep 15, 2011 at 4:11 PM, Fernando Perez <fperez.net at gmail.com> wrote: > On Thu, Sep 15, 2011 at 3:56 PM, Brian Granger <ellisonbg at gmail.com> wrote: >> >> I am still not thrilled, but I am fine being out voted on this. ?But I >> do think it makes sense to think more about exactly how it would work. > > Well, the fact that we all disagree to some extent here is a good sign > that we haven't fully found the best solution to the problem. > > So rather than rushing into a majority vote, I think our best approach > is to keep thinking about it and understanding the design space and > constraints. ?Sorry if it sounded like I was trying to 'outvote you', > that wasn't my intent: I just wanted to bring their perspective to the > table. ?In the past, more often than not we've seen how technical > disagreement is a sign of insufficient understanding of a problem from > one or more of us, and a good time to simply continue to mull over the > problem. ?We're typically pretty good at agreeing once we've really > found a good solution, so let's continue to trust that our instincts > will work this time too :) Yes in areas like this disagreement does many times indicate insufficient understanding of the problem. I appreciate your willingness to pause and make sure we understand the technical issue, but if you and Min do feel like there is a reasonable amount of clarity for you, please do move forward. But let's continue the disucssion on the PR. > We're in no major rush to make a decision here, and it's a fairly > important question about the architecture of frontends and how they > interact with the kernel and the user's namespace. ?I posted on the PR > discussion (https://github.com/ipython/ipython/pull/507), where it > seems we can continue most cleanly focused around the code, what I > understand so far of the design boundaries. ?With a little patience, > we should be able to figure out a really good solution to the whole > thing that we're all happy with in the long term. Sounds good! Cheers, Brian > Cheers, > > f > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From fperez.net at gmail.com Thu Sep 15 20:43:46 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 15 Sep 2011 17:43:46 -0700 Subject: [IPython-dev] The cat's out of the bag: ipython notebooks spotted in the wild... Message-ID: <CAHAreOq4S5VKF6YF8UwLFQX3+=8O+3Ydit3UXO4rx=Jhi7jKVQ@mail.gmail.com> Hi folks, we haven't made much noise on-list about it, but those who were at euroscipy witnessed my enthusiasm about it :) And we know that a few of you are already using the notebooks, and even sending pull requests. If you are curious, recently a couple of mentions/reviews have been made: - A thorough look with critical feedback by Anne Archibald: http://lighthouseinthesky.blogspot.com/2011/09/review-ipython-notebooks.html - Wes McKinney (of pandas fame) using them for a talk and actually providing the real notebooks for you to follow along: http://wesmckinney.com/blog/?p=202. I'm really thrilled to see this: we'd love the notebooks to become a natural way for users to exchange complex computational sessions in their daily work, and Wes is starting the tradition by making his talk slides available next to his notebooks. While this is something we've all wanted and on which recently the core team has put a lot of work, it's important to highlight that the lion's share of the credit goes to Brian, who went into silent mad-hacking mode for a few weeks around the 0.11 release timeframe and emerged from his den with a fully functional notebook branch. It's also an excellent illustration of how the work we've done since early last year on our zmq/messaging architecture is now paying major dividends, as this runs on the exact same machinery (in fact, my preferred mode of usage is to keep a qt console connected to my notebook kernel for a nicer help viewer, additional quick experimentation that doesn't mess up my document, etc). If you'd like to start playing with the toys, and giving us feedback (much preferred if it comes in the form of a pull request :), the installation instructions are here: http://ipython.org/ipython-doc/dev/install/install.html#dependencies-for-the-ipython-html-notebook a quick overview is here: http://ipython.org/ipython-doc/dev/interactive/htmlnotebook.html and you should note that the docs ship with a directory full of notebook examples: https://github.com/ipython/ipython/tree/master/docs/examples/notebooks Cheers, f From cekees at gmail.com Fri Sep 16 16:37:32 2011 From: cekees at gmail.com (Chris Kees) Date: Fri, 16 Sep 2011 15:37:32 -0500 Subject: [IPython-dev] notebook questions Message-ID: <CAOVFbFh2UymWGuzaLU22MJe12wD3nSNc1PQRTUHXRWNUFg3j7g@mail.gmail.com> Hi, I updated my source on the notebook after I read Fernando's post. Nice work! Couple of questions: Is there a way to use reST in the text boxes? It seems like it sort of works but doesn't get the :: If I put the notebook safely inside our firewall, would it be reasonable to just let 5-10 people use the same server or do you foresee problems down the road? I've set up a sage server partly for that purpose, but having the ipython notebook available could have some advantages. For example, we're running a computational mechanics seminar where it would be nice to share some simple mpi programs, say in the 8-16 processor range. I don't think we can do that in sage yet, right? In the docs, it talks about the python roundtrip not being guaranteed. What about a sage round trip capability for the notebooks? What's the latest recommendation for interactive 3D graphics in the notebook, or what direction should I investigate? Probably the most straightforward route for me would be to take our existing vtk representations that we use with Qt and follow the notebook example on the display protocol. Also, BTW, is there a PySide qt gui example somewhere? Thanks, Chris From benjaminrk at gmail.com Fri Sep 16 17:14:58 2011 From: benjaminrk at gmail.com (MinRK) Date: Fri, 16 Sep 2011 14:14:58 -0700 Subject: [IPython-dev] notebook questions In-Reply-To: <CAOVFbFh2UymWGuzaLU22MJe12wD3nSNc1PQRTUHXRWNUFg3j7g@mail.gmail.com> References: <CAOVFbFh2UymWGuzaLU22MJe12wD3nSNc1PQRTUHXRWNUFg3j7g@mail.gmail.com> Message-ID: <CAHNn8BXbtA-UhNg0m60NOeMS+zzjZFrs_AO8N2-ixVt3QrUrvg@mail.gmail.com> On Fri, Sep 16, 2011 at 13:37, Chris Kees <cekees at gmail.com> wrote: > Hi, > > I updated my source on the notebook after I read Fernando's post. Nice > work! Couple of questions: > > Is there a way to use reST in the text boxes? It seems like it sort of > works but doesn't get the :: > No, it uses markdown, which is largely similar, if simpler, and much better suited for use in a browser. Indent code blocks by four spaces, and it should behave nicely. Or use `<pre>` tags if you just want it monospaced and not highlighted. > > If I put the notebook safely inside our firewall, would it be > reasonable to just let 5-10 people use the same server or do you > foresee problems down the road? This should be fine, as long as it is acceptable for the 5-10 people to be running code as the user that launched the server. Anyone with access to the server can run arbitrary code on the host as this user. If this is acceptable, there should be no problem. One thing to be careful of is simultaneously working with a single notebook: You can both be working with the same file, but saving is destructive. So if two people open a notebook, both edit it, and both save it, the later save will clobber the first. > I've set up a sage server partly for > that purpose, but having the ipython notebook available could have > some advantages. For example, we're running a computational mechanics > seminar where it would be nice to share some simple mpi programs, say > in the 8-16 processor range. I don't think we can do that in sage yet, > right? > > In the docs, it talks about the python roundtrip not being guaranteed. > What about a sage round trip capability for the notebooks? > I don't know about the Sage notebook's file formats, but it is unlikely. That doesn't mean that it won't work at all, or even well, but lossless roundtrip is generally not feasible between file formats with different capabilities. > > What's the latest recommendation for interactive 3D graphics in the > notebook, or what direction should I investigate? Probably the most > straightforward route for me would be to take our existing vtk > representations that we use with Qt and follow the notebook example on > the display protocol. Also, BTW, is there a PySide qt gui example > somewhere? > The IPython notebook currently has no mechanism for interactive graphics. All the usual interactive tools should work if you are running the notebook server *locally*, as their windows will pop up as usual. You can publish static HTML, SVG, PNG, or txt representations of objects, but not dynamic (unless you write the dynamic part into the HTML/JS output). > > Thanks, > Chris > _______________________________________________ > 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: <http://mail.python.org/pipermail/ipython-dev/attachments/20110916/87ca5589/attachment.html> From jason-sage at creativetrax.com Fri Sep 16 18:50:29 2011 From: jason-sage at creativetrax.com (Jason Grout) Date: Fri, 16 Sep 2011 17:50:29 -0500 Subject: [IPython-dev] notebook questions In-Reply-To: <CAOVFbFh2UymWGuzaLU22MJe12wD3nSNc1PQRTUHXRWNUFg3j7g@mail.gmail.com> References: <CAOVFbFh2UymWGuzaLU22MJe12wD3nSNc1PQRTUHXRWNUFg3j7g@mail.gmail.com> Message-ID: <4E73D2B5.7040202@creativetrax.com> On 9/16/11 3:37 PM, Chris Kees wrote: > Hi, > > I updated my source on the notebook after I read Fernando's post. Nice > work! Couple of questions: > > Is there a way to use reST in the text boxes? It seems like it sort of > works but doesn't get the :: > > If I put the notebook safely inside our firewall, would it be > reasonable to just let 5-10 people use the same server or do you > foresee problems down the road? I've set up a sage server partly for > that purpose, but having the ipython notebook available could have > some advantages. For example, we're running a computational mechanics > seminar where it would be nice to share some simple mpi programs, say > in the 8-16 processor range. I don't think we can do that in sage yet, > right? (answering the Sage question here...) What do you mean when you say "share some simple mpi programs"? Do you mean running the mpi programs from the command line, or sharing the C code files, or using mpi4py to run the programs? If you can do it in python or on the command line, you can likely do it in Sage. Feel free to email the sage-support list; I'm sure we can help you there. > > In the docs, it talks about the python roundtrip not being guaranteed. > What about a sage round trip capability for the notebooks? I think that might be possible, though it would require ipython being able to have "text cells" with arbitrary html, rather than just markdown. The Sage notebook format looks something like: arbitrary html {{{ input /// output }}} arbitrary html {{{ input /// output }}} arbitrary html etc. Of course, sage-specific things like interacts wouldn't work. (However, over the summer we've written a version of interacts that is independent of Sage and relies instead on the new ipython messaging protocol; it's part of the single-cell server project: http://utmost.aimath.org/#august-2011.) Thanks, Jason -- Jason Grout From benjaminrk at gmail.com Fri Sep 16 19:35:11 2011 From: benjaminrk at gmail.com (MinRK) Date: Fri, 16 Sep 2011 16:35:11 -0700 Subject: [IPython-dev] notebook questions In-Reply-To: <4E73D2B5.7040202@creativetrax.com> References: <CAOVFbFh2UymWGuzaLU22MJe12wD3nSNc1PQRTUHXRWNUFg3j7g@mail.gmail.com> <4E73D2B5.7040202@creativetrax.com> Message-ID: <CAHNn8BU6LMi-k_iTwDuxfVxPa0=NQ9BaicPQG8An=5WaYQ3NWQ@mail.gmail.com> On Fri, Sep 16, 2011 at 15:50, Jason Grout <jason-sage at creativetrax.com>wrote: > On 9/16/11 3:37 PM, Chris Kees wrote: > > Hi, > > > > I updated my source on the notebook after I read Fernando's post. Nice > > work! Couple of questions: > > > > Is there a way to use reST in the text boxes? It seems like it sort of > > works but doesn't get the :: > > > > If I put the notebook safely inside our firewall, would it be > > reasonable to just let 5-10 people use the same server or do you > > foresee problems down the road? I've set up a sage server partly for > > that purpose, but having the ipython notebook available could have > > some advantages. For example, we're running a computational mechanics > > seminar where it would be nice to share some simple mpi programs, say > > in the 8-16 processor range. I don't think we can do that in sage yet, > > right? > > (answering the Sage question here...) What do you mean when you say > "share some simple mpi programs"? Do you mean running the mpi programs > from the command line, or sharing the C code files, or using mpi4py to > run the programs? If you can do it in python or on the command line, > you can likely do it in Sage. Feel free to email the sage-support list; > I'm sure we can help you there. > > > > > > > In the docs, it talks about the python roundtrip not being guaranteed. > > What about a sage round trip capability for the notebooks? > > I think that might be possible, though it would require ipython being > able to have "text cells" with arbitrary html, rather than just > markdown. The Sage notebook format looks something like: > since (almost) arbitrary html is valid markdown, I don't expect a problem there. The first notebook draft had html text cells, but we never found any HTML we wanted to use that didn't work as-is in markdown, so we disabled it to prevent unnecessary clutter. If there are real HTML use cases for which the markdown transforms html inappropriately, we can easily turn it back on. > > arbitrary html > > {{{ > input > /// > output > }}} > > arbitrary html > > {{{ > input > /// > output > }}} > > arbitrary html > > etc. > That seems simple enough, though after playing with a few sage worksheets, it looks like if you make an HTML cell, it is indistinguishable from a code cell in the exported file. Presumably, IPython would only want the Python/Sage cells as code cells, whereas all the latex, text, and html cells should come out as text. If Sage doesn't distinguish between these in the file-format, then I'm not sure what we should do. Detecting the language based purely on content will certainly not be acceptable. But the fact that Sage can have HTML that is part of a cell, as well as HTML that is *not* part of a cell makes it clear that a roundtrip will not result in an identical notebook. It may have the same content, but it will have changed structure at least partly. This is what we mean when we talk about lacking roundtrip support - not that you can't import to/export from a format, but that doing so is not guaranteed to preserve the entire document structure. > > Of course, sage-specific things like interacts wouldn't work. (However, > over the summer we've written a version of interacts that is independent > of Sage and relies instead on the new ipython messaging protocol; it's > part of the single-cell server project: > http://utmost.aimath.org/#august-2011.) > Very cool! > > Thanks, > > Jason > > -- > Jason Grout > _______________________________________________ > 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: <http://mail.python.org/pipermail/ipython-dev/attachments/20110916/eb86c452/attachment.html> From cekees at gmail.com Fri Sep 16 23:08:32 2011 From: cekees at gmail.com (Chris Kees) Date: Fri, 16 Sep 2011 22:08:32 -0500 Subject: [IPython-dev] notebook questions In-Reply-To: <CAHNn8BXbtA-UhNg0m60NOeMS+zzjZFrs_AO8N2-ixVt3QrUrvg@mail.gmail.com> References: <CAOVFbFh2UymWGuzaLU22MJe12wD3nSNc1PQRTUHXRWNUFg3j7g@mail.gmail.com> <CAHNn8BXbtA-UhNg0m60NOeMS+zzjZFrs_AO8N2-ixVt3QrUrvg@mail.gmail.com> Message-ID: <CAOVFbFh9c12v-BXXENsvG_bqNj8qHKytsiv5PUiyg1mjxLHh2A@mail.gmail.com> On Fri, Sep 16, 2011 at 4:14 PM, MinRK <benjaminrk at gmail.com> wrote: > > > On Fri, Sep 16, 2011 at 13:37, Chris Kees <cekees at gmail.com> wrote: >> >> Hi, >> >> I updated my source on the notebook after I read Fernando's post. Nice >> work! Couple of questions: >> >> Is there a way to use reST in the text boxes? It seems like it sort of >> works but doesn't get the :: > > No, it uses markdown, which is largely similar, if simpler, and much better > suited for > use in a browser. ?Indent code blocks by four spaces, and it should > behave nicely. ?Or use `<pre>` tags if you just want it monospaced and not > highlighted. > I noticed that github allows you to choose between several different languages for wiki input so I thought you might have something like that in mind. I've been using reST for docstrings, sphinx docs, and github so I selfishly would prefer not to have to learn another simplified markup language. >> >> If I put the notebook safely inside our firewall, would it be >> reasonable to just let 5-10 people use the same server or do you >> foresee problems down the road? > > This should be fine, as long as it is acceptable for the 5-10 people to be > running code as the user that launched the server. ?Anyone with access to > the server can run arbitrary code on the host as this user. ?If this is > acceptable, there should be no problem. ?One thing to be careful of is > simultaneously working with a single notebook: You can both be working with > the same file, but saving is destructive. ?So if two people open a notebook, > both edit it, and both save it, the later save will clobber the first. > I could set up a special user or virtual machine like is done for sage servers, and then we could just use a convention that your always save worksheets in notebooks ending in your initials. One flaw in that plan is that the current notebook doesn't appear to have a "duplicate" or "save as" capability, but I'm guessing that would be very easy to add. I like the integrated version control idea that Anne Archibald mentioned in her blog. >> >> I've set up a sage server partly for >> that purpose, but having the ipython notebook available could have >> some advantages. For example, we're running a computational mechanics >> seminar where it would be nice to share some simple mpi programs, say >> in the 8-16 processor range. I don't think we can do that in sage yet, >> right? >> >> In the docs, it talks about the python roundtrip not being guaranteed. >> What about a sage round trip capability for the notebooks? > > I don't know about the Sage notebook's file formats, but it is unlikely. > ?That doesn't mean that it won't work at all, or even well, but lossless > roundtrip is generally not feasible between file formats with different > capabilities. > I understand about the perfect lossless roundtrip being impossible in general. I'd be happy with a convert script that goes back and forth with warnings or comments (sort of like a failed merge). As long as the python part works and most of the text makes it on the round trip it seems valuable to me. One can invest quite a bit of effort into these notebooks, and I like the idea of being able to convert them to high quality python code or sage with minimal effort. >> >> What's the latest recommendation for interactive 3D graphics in the >> notebook, or what direction should I investigate? Probably the most >> straightforward route for me would be to take our existing vtk >> representations that we use with Qt and follow the notebook example on >> the display protocol. ?Also, BTW, is there a PySide qt gui example >> somewhere? > > The IPython notebook currently has no mechanism for interactive graphics. > All the usual interactive tools should work if you are running the notebook > server *locally*, as their windows will pop up as usual. ?You can publish > static HTML, SVG, PNG, or txt representations of objects, but not dynamic > (unless you write the dynamic part into the HTML/JS output). > OK, that gives a path forward. Most of our graphics is done in vtk so I asked the paraview list whether the JS support from the ParaViewWeb project is available from python yet (http://www.vtk.org/Wiki/ParaViewWeb). >> >> Thanks, >> Chris >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev > > From jason-sage at creativetrax.com Fri Sep 16 23:20:39 2011 From: jason-sage at creativetrax.com (Jason Grout) Date: Fri, 16 Sep 2011 22:20:39 -0500 Subject: [IPython-dev] notebook questions In-Reply-To: <CAHNn8BU6LMi-k_iTwDuxfVxPa0=NQ9BaicPQG8An=5WaYQ3NWQ@mail.gmail.com> References: <CAOVFbFh2UymWGuzaLU22MJe12wD3nSNc1PQRTUHXRWNUFg3j7g@mail.gmail.com> <4E73D2B5.7040202@creativetrax.com> <CAHNn8BU6LMi-k_iTwDuxfVxPa0=NQ9BaicPQG8An=5WaYQ3NWQ@mail.gmail.com> Message-ID: <4E741207.8090208@creativetrax.com> On 9/16/11 6:35 PM, MinRK wrote: > > > On Fri, Sep 16, 2011 at 15:50, Jason Grout <jason-sage at creativetrax.com > <mailto:jason-sage at creativetrax.com>> wrote: > > On 9/16/11 3:37 PM, Chris Kees wrote: > > Hi, > > > > I updated my source on the notebook after I read Fernando's post. > Nice > > work! Couple of questions: > > > > Is there a way to use reST in the text boxes? It seems like it > sort of > > works but doesn't get the :: > > > > If I put the notebook safely inside our firewall, would it be > > reasonable to just let 5-10 people use the same server or do you > > foresee problems down the road? I've set up a sage server partly for > > that purpose, but having the ipython notebook available could have > > some advantages. For example, we're running a computational mechanics > > seminar where it would be nice to share some simple mpi programs, say > > in the 8-16 processor range. I don't think we can do that in sage > yet, > > right? > > (answering the Sage question here...) What do you mean when you say > "share some simple mpi programs"? Do you mean running the mpi programs > from the command line, or sharing the C code files, or using mpi4py to > run the programs? If you can do it in python or on the command line, > you can likely do it in Sage. Feel free to email the sage-support list; > I'm sure we can help you there. > > > > > > > In the docs, it talks about the python roundtrip not being > guaranteed. > > What about a sage round trip capability for the notebooks? > > I think that might be possible, though it would require ipython being > able to have "text cells" with arbitrary html, rather than just > markdown. The Sage notebook format looks something like: > > > since (almost) arbitrary html is valid markdown, I don't expect a > problem there. The first notebook draft had html text cells, but we > never found any HTML we wanted to use that didn't work as-is in > markdown, so we disabled it to prevent unnecessary clutter. If there > are real HTML use cases for which the markdown transforms html > inappropriately, we can easily turn it back on. Good point about streamlining things. We've found it useful to be able to put arbitrary html in (think of a worksheet as an html page with cells on it---it's a more fluid document than just text, worksheet, text, worksheet, etc.). For example, one person asked about putting two cells side-by-side, and that was pretty easy to do by writing the necessary table commands before and after the cells. I'm curious: can you do something like that (embed a <td> before a compute cell and a </td> after a compute cell to put the compute cell in a table)? Or are your text cells self-contained snippets in the document? I like the idea of a worksheet simply being a webpage (with all the possible html capabilities), with special cells that evaluate code somewhere in the page, or insert WYSIWYG editors, or do interactive graphics, etc. > > > arbitrary html > > {{{ > input > /// > output > }}} > > arbitrary html > > {{{ > input > /// > output > }}} > > arbitrary html > > etc. > > > That seems simple enough, though after playing with a few sage > worksheets, it looks like if you make an HTML cell, it is > indistinguishable from a code cell in the exported file. Presumably, > IPython would only want the Python/Sage cells as code cells, whereas all > the latex, text, and html cells should come out as text. If Sage > doesn't distinguish between these in the file-format, then I'm not sure > what we should do. Detecting the language based purely on content will > certainly not be acceptable. > I think you may be confusing %html cells (which are just code cells whose output is spliced into the html document, exactly as if we had called the html() command, and similar to what would happen if your output was a text/html mimetype and spliced into the document) and what I'm calling arbitrary html above. Anything that is typed into the code cell is considered a code cell, including %html cells, etc. To edit the arbitrary html that I'm talking about above, shift-click on the blue insert-cell bar to open up what we call a "text cell" (as compared to a code cell). A TinyMCE WYSIWYG html editor will pop up. > But the fact that Sage can have HTML that is part of a cell, as well as > HTML that is *not* part of a cell makes it clear that a roundtrip will > not result in an identical notebook. It may have the same content, but > it will have changed structure at least partly. This is what we mean > when we talk about lacking roundtrip support - not that you can't import > to/export from a format, but that doing so is not guaranteed to preserve > the entire document structure. Yes, of course. For example, interacts wouldn't work very well. But I think a more modest goal of having the inputs round-trip and the html between code cells round-trip might be achievable. What about files attached to the notebooks? In Sage, we can attach lots of files to a worksheet in a DATA directory. Also, the graphics are not inlined png (as I notice the ipython notebook has), but are stored in cell-specific output directories. Jason From benjaminrk at gmail.com Fri Sep 16 23:41:23 2011 From: benjaminrk at gmail.com (MinRK) Date: Fri, 16 Sep 2011 20:41:23 -0700 Subject: [IPython-dev] notebook questions In-Reply-To: <CAOVFbFh9c12v-BXXENsvG_bqNj8qHKytsiv5PUiyg1mjxLHh2A@mail.gmail.com> References: <CAOVFbFh2UymWGuzaLU22MJe12wD3nSNc1PQRTUHXRWNUFg3j7g@mail.gmail.com> <CAHNn8BXbtA-UhNg0m60NOeMS+zzjZFrs_AO8N2-ixVt3QrUrvg@mail.gmail.com> <CAOVFbFh9c12v-BXXENsvG_bqNj8qHKytsiv5PUiyg1mjxLHh2A@mail.gmail.com> Message-ID: <CAHNn8BUovNohpQesJFJw6Og6hFzuDQMC=77py8MR14k4RmM3dQ@mail.gmail.com> On Fri, Sep 16, 2011 at 20:08, Chris Kees <cekees at gmail.com> wrote: > On Fri, Sep 16, 2011 at 4:14 PM, MinRK <benjaminrk at gmail.com> wrote: > > > > > > On Fri, Sep 16, 2011 at 13:37, Chris Kees <cekees at gmail.com> wrote: > >> > >> Hi, > >> > >> I updated my source on the notebook after I read Fernando's post. Nice > >> work! Couple of questions: > >> > >> Is there a way to use reST in the text boxes? It seems like it sort of > >> works but doesn't get the :: > > > > No, it uses markdown, which is largely similar, if simpler, and much > better > > suited for > > use in a browser. Indent code blocks by four spaces, and it should > > behave nicely. Or use `<pre>` tags if you just want it monospaced and > not > > highlighted. > > > > I noticed that github allows you to choose between several different > languages for wiki input so I thought you might have something like > that in mind. I've been using reST for docstrings, sphinx docs, and > github so I selfishly would prefer not to have to learn another > simplified markup language. > That makes sense, and I expect we will get this request often. The problem is reST is really a horrible language for in-browser cell markup (as opposed to full document markup, for which it is designed), and for many simple cases writing as if it were reST will result in the same output in markdown. > > >> > >> If I put the notebook safely inside our firewall, would it be > >> reasonable to just let 5-10 people use the same server or do you > >> foresee problems down the road? > > > > This should be fine, as long as it is acceptable for the 5-10 people to > be > > running code as the user that launched the server. Anyone with access to > > the server can run arbitrary code on the host as this user. If this is > > acceptable, there should be no problem. One thing to be careful of is > > simultaneously working with a single notebook: You can both be working > with > > the same file, but saving is destructive. So if two people open a > notebook, > > both edit it, and both save it, the later save will clobber the first. > > > > I could set up a special user or virtual machine like is done for sage > servers, and then we could just use a convention that your always save > worksheets in notebooks ending in your initials. One flaw in that plan > is that the current notebook doesn't appear to have a "duplicate" or > "save as" capability, but I'm guessing that would be very easy to add. > I like the integrated version control idea that Anne Archibald > mentioned in her blog. > Yes, integrated version control is one of the very first features we got excited about, long before a single line of code was written, and will hopefully support soon. > > >> > >> I've set up a sage server partly for > >> that purpose, but having the ipython notebook available could have > >> some advantages. For example, we're running a computational mechanics > >> seminar where it would be nice to share some simple mpi programs, say > >> in the 8-16 processor range. I don't think we can do that in sage yet, > >> right? > >> > >> In the docs, it talks about the python roundtrip not being guaranteed. > >> What about a sage round trip capability for the notebooks? > > > > I don't know about the Sage notebook's file formats, but it is unlikely. > > That doesn't mean that it won't work at all, or even well, but lossless > > roundtrip is generally not feasible between file formats with different > > capabilities. > > > > I understand about the perfect lossless roundtrip being impossible in > general. I'd be happy with a convert script that goes back and forth > with warnings or comments (sort of like a failed merge). As long as > the python part works and most of the text makes it on the round trip > it seems valuable to me. One can invest quite a bit of effort into > these notebooks, and I like the idea of being able to convert them to > high quality python code or sage with minimal effort. > Yes, one (or few) time export or import should not be a problem. Just don't expect to be able to reliably be going back and forth between environments with continued edits, which clean roundtrip would get you. > > >> > >> What's the latest recommendation for interactive 3D graphics in the > >> notebook, or what direction should I investigate? Probably the most > >> straightforward route for me would be to take our existing vtk > >> representations that we use with Qt and follow the notebook example on > >> the display protocol. Also, BTW, is there a PySide qt gui example > >> somewhere? > > > > The IPython notebook currently has no mechanism for interactive graphics. > > All the usual interactive tools should work if you are running the > notebook > > server *locally*, as their windows will pop up as usual. You can publish > > static HTML, SVG, PNG, or txt representations of objects, but not dynamic > > (unless you write the dynamic part into the HTML/JS output). > > > > OK, that gives a path forward. Most of our graphics is done in vtk so > I asked the paraview list whether the JS support from the ParaViewWeb > project is available from python yet > (http://www.vtk.org/Wiki/ParaViewWeb). > > >> > >> Thanks, > >> Chris > >> _______________________________________________ > >> 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: <http://mail.python.org/pipermail/ipython-dev/attachments/20110916/fe641862/attachment.html> From gael.varoquaux at normalesup.org Fri Sep 16 23:44:15 2011 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Sat, 17 Sep 2011 05:44:15 +0200 Subject: [IPython-dev] notebook questions In-Reply-To: <CAHNn8BUovNohpQesJFJw6Og6hFzuDQMC=77py8MR14k4RmM3dQ@mail.gmail.com> References: <CAOVFbFh2UymWGuzaLU22MJe12wD3nSNc1PQRTUHXRWNUFg3j7g@mail.gmail.com> <CAHNn8BXbtA-UhNg0m60NOeMS+zzjZFrs_AO8N2-ixVt3QrUrvg@mail.gmail.com> <CAOVFbFh9c12v-BXXENsvG_bqNj8qHKytsiv5PUiyg1mjxLHh2A@mail.gmail.com> <CAHNn8BUovNohpQesJFJw6Og6hFzuDQMC=77py8MR14k4RmM3dQ@mail.gmail.com> Message-ID: <20110917034415.GE13494@phare.normalesup.org> On Fri, Sep 16, 2011 at 08:41:23PM -0700, MinRK wrote: > I noticed that github allows you to choose between several different > languages for wiki input so I thought you might have something like > that in mind. ?I've been using reST for docstrings, sphinx docs, and > github so I selfishly would prefer not to have to learn another > simplified markup language. > That makes sense, and I expect we will get this request often. ?The > problem is reST is really a horrible language > for in-browser cell markup (as opposed to full document markup, for which > it is designed), Actually, reST was originally designed to write docstrings. It seems to me wrong to go with any other markup language, given that the standard in the Python world in reST. It is hard enough to agree on standards, let us rejoice that there is one. Gael From benjaminrk at gmail.com Sat Sep 17 00:17:05 2011 From: benjaminrk at gmail.com (MinRK) Date: Fri, 16 Sep 2011 21:17:05 -0700 Subject: [IPython-dev] notebook questions In-Reply-To: <20110917034415.GE13494@phare.normalesup.org> References: <CAOVFbFh2UymWGuzaLU22MJe12wD3nSNc1PQRTUHXRWNUFg3j7g@mail.gmail.com> <CAHNn8BXbtA-UhNg0m60NOeMS+zzjZFrs_AO8N2-ixVt3QrUrvg@mail.gmail.com> <CAOVFbFh9c12v-BXXENsvG_bqNj8qHKytsiv5PUiyg1mjxLHh2A@mail.gmail.com> <CAHNn8BUovNohpQesJFJw6Og6hFzuDQMC=77py8MR14k4RmM3dQ@mail.gmail.com> <20110917034415.GE13494@phare.normalesup.org> Message-ID: <CAHNn8BUw--HSLrTo2Wa=w9TJu=pgAyYfkRrPN2gHFKm+N6wrtQ@mail.gmail.com> On Fri, Sep 16, 2011 at 20:44, Gael Varoquaux <gael.varoquaux at normalesup.org > wrote: > On Fri, Sep 16, 2011 at 08:41:23PM -0700, MinRK wrote: > > I noticed that github allows you to choose between several different > > languages for wiki input so I thought you might have something like > > that in mind. I've been using reST for docstrings, sphinx docs, and > > github so I selfishly would prefer not to have to learn another > > simplified markup language. > > > That makes sense, and I expect we will get this request often. The > > problem is reST is really a horrible language > > for in-browser cell markup (as opposed to full document markup, for > which > > it is designed), > > Actually, reST was originally designed to write docstrings. Ah, I didn't know that, given that its design is so much better suited to large documents than small isolated text. > > It seems to me wrong to go with any other markup language, given that the > standard in the Python world in reST. It is hard enough to agree on > standards, let us rejoice that there is one. > We thought about this quite a bit, and concluded that markdown was just a better fit, despite the Python-ness of reST. reST is just a very bad tool for interactive, light text markup, but if you can point me to a good javascript reST renderer, we can reconsider. > Gael > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110916/b48e2faf/attachment.html> From ellisonbg at gmail.com Sat Sep 17 01:16:46 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Fri, 16 Sep 2011 22:16:46 -0700 Subject: [IPython-dev] notebook questions In-Reply-To: <CAHNn8BUw--HSLrTo2Wa=w9TJu=pgAyYfkRrPN2gHFKm+N6wrtQ@mail.gmail.com> References: <CAOVFbFh2UymWGuzaLU22MJe12wD3nSNc1PQRTUHXRWNUFg3j7g@mail.gmail.com> <CAHNn8BXbtA-UhNg0m60NOeMS+zzjZFrs_AO8N2-ixVt3QrUrvg@mail.gmail.com> <CAOVFbFh9c12v-BXXENsvG_bqNj8qHKytsiv5PUiyg1mjxLHh2A@mail.gmail.com> <CAHNn8BUovNohpQesJFJw6Og6hFzuDQMC=77py8MR14k4RmM3dQ@mail.gmail.com> <20110917034415.GE13494@phare.normalesup.org> <CAHNn8BUw--HSLrTo2Wa=w9TJu=pgAyYfkRrPN2gHFKm+N6wrtQ@mail.gmail.com> Message-ID: <CAH4pYpRw4gNg4+sJ4r0oJ1t8jP53C2Wt-QFHod0deGOv2ZYWfw@mail.gmail.com> I can outline our plans for supporting reST in the notebook. * The problem with reST is that it can only render entire documents and not parts of documents. Because of this, it can't be used to render a single reST text cell in any way that behaves as people expect. Examples are section headings and references, which are contextual and require the entire document to make sense of. A more formal way of putting this is: rest_render(cell[0]) + rest_render(cell[1]) != rest_render(cell[0] + cell[1]) Markdown does not suffer from these design limitations and this is why it is our default for rich text cells in the notebook. * Obviously reST is very important to the python community and we want to support reST. Here is how we plan on doing this. The problem is in the rendering of individual cells. We will implement reST text cells that simply don't render to HTML in the notebook as the Markdown cells do. They will remain reST source and be stored in that form in the notebook format. * Notebooks with reST text cells can be exported to reST easily and then rendered to HTML/LaTeX as desired. * reST document will be able to be imported into the notebook once this is implemented as well. The most important point in all of this is that the problem is reST itself, not the IPython notebook. I actually spent a couple of days trying to hack reST support into the notebook using various tricks. At the end of it all my conclusion was a somewhat depressing "wow, reST is simply not designed for this usage case, but Markdown is a perfect fit" Cheers, Brian On Fri, Sep 16, 2011 at 9:17 PM, MinRK <benjaminrk at gmail.com> wrote: > > > On Fri, Sep 16, 2011 at 20:44, Gael Varoquaux > <gael.varoquaux at normalesup.org> wrote: >> >> On Fri, Sep 16, 2011 at 08:41:23PM -0700, MinRK wrote: >> > ? ? ?I noticed that github allows you to choose between several >> > different >> > ? ? ?languages for wiki input so I thought you might have something like >> > ? ? ?that in mind. ?I've been using reST for docstrings, sphinx docs, >> > and >> > ? ? ?github so I selfishly would prefer not to have to learn another >> > ? ? ?simplified markup language. >> >> > ? ?That makes sense, and I expect we will get this request often. ?The >> > ? ?problem is reST is really a horrible language >> > ? ?for in-browser cell markup (as opposed to full document markup, for >> > which >> > ? ?it is designed), >> >> Actually, reST was originally designed to write docstrings. > > Ah, I didn't know that, given that its design is so much better suited to > large documents than small isolated text. > >> >> It seems to me wrong to go with any other markup language, given that the >> standard in the Python world in reST. It is hard enough to agree on >> standards, let us rejoice that there is one. > > We thought about this quite a bit, and concluded that markdown was just a > better > fit, despite the Python-ness of reST. ?reST is just a very bad tool for > interactive, light text markup, > but if you can point me to a good javascript reST renderer, we can > reconsider. > >> >> Gael > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From ellisonbg at gmail.com Sat Sep 17 01:25:08 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Fri, 16 Sep 2011 22:25:08 -0700 Subject: [IPython-dev] notebook questions In-Reply-To: <CAOVFbFh9c12v-BXXENsvG_bqNj8qHKytsiv5PUiyg1mjxLHh2A@mail.gmail.com> References: <CAOVFbFh2UymWGuzaLU22MJe12wD3nSNc1PQRTUHXRWNUFg3j7g@mail.gmail.com> <CAHNn8BXbtA-UhNg0m60NOeMS+zzjZFrs_AO8N2-ixVt3QrUrvg@mail.gmail.com> <CAOVFbFh9c12v-BXXENsvG_bqNj8qHKytsiv5PUiyg1mjxLHh2A@mail.gmail.com> Message-ID: <CAH4pYpScgPcRM0iXU8n0UdqhBRh6ojTpwgYF3Ge6E+qWzMTSyQ@mail.gmail.com> On Fri, Sep 16, 2011 at 8:08 PM, Chris Kees <cekees at gmail.com> wrote: > On Fri, Sep 16, 2011 at 4:14 PM, MinRK <benjaminrk at gmail.com> wrote: >> >> >> On Fri, Sep 16, 2011 at 13:37, Chris Kees <cekees at gmail.com> wrote: >>> >>> Hi, >>> >>> I updated my source on the notebook after I read Fernando's post. Nice >>> work! Couple of questions: >>> >>> Is there a way to use reST in the text boxes? It seems like it sort of >>> works but doesn't get the :: >> >> No, it uses markdown, which is largely similar, if simpler, and much better >> suited for >> use in a browser. ?Indent code blocks by four spaces, and it should >> behave nicely. ?Or use `<pre>` tags if you just want it monospaced and not >> highlighted. >> > > I noticed that github allows you to choose between several different > languages for wiki input so I thought you might have something like > that in mind. ?I've been using reST for docstrings, sphinx docs, and > github so I selfishly would prefer not to have to learn another > simplified markup language. > >>> >>> If I put the notebook safely inside our firewall, would it be >>> reasonable to just let 5-10 people use the same server or do you >>> foresee problems down the road? >> >> This should be fine, as long as it is acceptable for the 5-10 people to be >> running code as the user that launched the server. ?Anyone with access to >> the server can run arbitrary code on the host as this user. ?If this is >> acceptable, there should be no problem. ?One thing to be careful of is >> simultaneously working with a single notebook: You can both be working with >> the same file, but saving is destructive. ?So if two people open a notebook, >> both edit it, and both save it, the later save will clobber the first. >> > > I could set up a special user or virtual machine like is done for sage > servers, and then we could just use a convention that your always save > worksheets in notebooks ending in your initials. One flaw in that plan > is that the current notebook doesn't appear to have a "duplicate" or > "save as" capability, but I'm guessing that would be very easy to add. > ?I like the integrated version control idea that Anne Archibald > mentioned in her blog. A notebook "Clone" capability is on our list as is version control integration. But I should mention that our model for notebooks is quite different than that of Sage. The notebook server stores the notebook documents as JSON text files in the cwd of the notebook. There is no "notebook database" involved and we encourage storing the notebook files alongside the rest of your project files. What this means is that all you have to do to get version control for notebooks is do "git init" in the directory containing the notebooks. Obviously, we want more integration in the future, but this simple model works today. >>> >>> I've set up a sage server partly for >>> that purpose, but having the ipython notebook available could have >>> some advantages. For example, we're running a computational mechanics >>> seminar where it would be nice to share some simple mpi programs, say >>> in the 8-16 processor range. I don't think we can do that in sage yet, >>> right? >>> >>> In the docs, it talks about the python roundtrip not being guaranteed. >>> What about a sage round trip capability for the notebooks? >> >> I don't know about the Sage notebook's file formats, but it is unlikely. >> ?That doesn't mean that it won't work at all, or even well, but lossless >> roundtrip is generally not feasible between file formats with different >> capabilities. >> > > I understand about the perfect lossless roundtrip being impossible in > general. I'd be happy with a convert script that goes back and forth > with warnings or comments (sort of like a failed merge). As long as > the python part works and most of the text makes it on the round trip > it seems valuable to me. ?One can invest quite a bit of effort into > these notebooks, and I like the idea of being able to convert them to > high quality python code or sage with minimal effort. It should be possible to import/export IPython notebooks to Sage notebooks, at least at a simple level. I don't have time to work on this right now, but I can point others in the right direction if they want to tackle it. >>> >>> What's the latest recommendation for interactive 3D graphics in the >>> notebook, or what direction should I investigate? Probably the most >>> straightforward route for me would be to take our existing vtk >>> representations that we use with Qt and follow the notebook example on >>> the display protocol. ?Also, BTW, is there a PySide qt gui example >>> somewhere? >> >> The IPython notebook currently has no mechanism for interactive graphics. >> All the usual interactive tools should work if you are running the notebook >> server *locally*, as their windows will pop up as usual. ?You can publish >> static HTML, SVG, PNG, or txt representations of objects, but not dynamic >> (unless you write the dynamic part into the HTML/JS output). >> > > OK, that gives a path forward. ?Most of our graphics is done in vtk so > I asked the paraview list whether the JS support from the ParaViewWeb > project is available from python yet > (http://www.vtk.org/Wiki/ParaViewWeb). Sounds good. Cheers, Brian >>> >>> Thanks, >>> Chris >>> _______________________________________________ >>> IPython-dev mailing list >>> IPython-dev at scipy.org >>> http://mail.scipy.org/mailman/listinfo/ipython-dev >> >> > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From satra at mit.edu Sat Sep 17 01:34:14 2011 From: satra at mit.edu (Satrajit Ghosh) Date: Sat, 17 Sep 2011 01:34:14 -0400 Subject: [IPython-dev] notebook questions In-Reply-To: <CAH4pYpRw4gNg4+sJ4r0oJ1t8jP53C2Wt-QFHod0deGOv2ZYWfw@mail.gmail.com> References: <CAOVFbFh2UymWGuzaLU22MJe12wD3nSNc1PQRTUHXRWNUFg3j7g@mail.gmail.com> <CAHNn8BXbtA-UhNg0m60NOeMS+zzjZFrs_AO8N2-ixVt3QrUrvg@mail.gmail.com> <CAOVFbFh9c12v-BXXENsvG_bqNj8qHKytsiv5PUiyg1mjxLHh2A@mail.gmail.com> <CAHNn8BUovNohpQesJFJw6Og6hFzuDQMC=77py8MR14k4RmM3dQ@mail.gmail.com> <20110917034415.GE13494@phare.normalesup.org> <CAHNn8BUw--HSLrTo2Wa=w9TJu=pgAyYfkRrPN2gHFKm+N6wrtQ@mail.gmail.com> <CAH4pYpRw4gNg4+sJ4r0oJ1t8jP53C2Wt-QFHod0deGOv2ZYWfw@mail.gmail.com> Message-ID: <CA+A4wOnKRK9J1Ja8QLe8c_jtfUg9jy2exs=O4qbzSU7ihweKcg@mail.gmail.com> i don't know if you've seen this before, but might be useful: http://rst.ninjs.org/ cheers, satra On Sat, Sep 17, 2011 at 1:16 AM, Brian Granger <ellisonbg at gmail.com> wrote: > I can outline our plans for supporting reST in the notebook. > > * The problem with reST is that it can only render entire documents > and not parts of documents. Because of this, it can't be used to > render a single reST text cell in any way that behaves as people > expect. Examples are section headings and references, which are > contextual and require the entire document to make sense of. A more > formal way of putting this is: > > rest_render(cell[0]) + rest_render(cell[1]) != rest_render(cell[0] + > cell[1]) > > Markdown does not suffer from these design limitations and this is why > it is our default for rich text cells in the notebook. > > * Obviously reST is very important to the python community and we want > to support reST. Here is how we plan on doing this. The problem is > in the rendering of individual cells. We will implement reST text > cells that simply don't render to HTML in the notebook as the Markdown > cells do. They will remain reST source and be stored in that form in > the notebook format. > > * Notebooks with reST text cells can be exported to reST easily and > then rendered to HTML/LaTeX as desired. > > * reST document will be able to be imported into the notebook once > this is implemented as well. > > The most important point in all of this is that the problem is reST > itself, not the IPython notebook. I actually spent a couple of days > trying to hack reST support into the notebook using various tricks. > At the end of it all my conclusion was a somewhat depressing "wow, > reST is simply not designed for this usage case, but Markdown is a > perfect fit" > > Cheers, > > Brian > > On Fri, Sep 16, 2011 at 9:17 PM, MinRK <benjaminrk at gmail.com> wrote: > > > > > > On Fri, Sep 16, 2011 at 20:44, Gael Varoquaux > > <gael.varoquaux at normalesup.org> wrote: > >> > >> On Fri, Sep 16, 2011 at 08:41:23PM -0700, MinRK wrote: > >> > I noticed that github allows you to choose between several > >> > different > >> > languages for wiki input so I thought you might have something > like > >> > that in mind. I've been using reST for docstrings, sphinx docs, > >> > and > >> > github so I selfishly would prefer not to have to learn another > >> > simplified markup language. > >> > >> > That makes sense, and I expect we will get this request often. The > >> > problem is reST is really a horrible language > >> > for in-browser cell markup (as opposed to full document markup, for > >> > which > >> > it is designed), > >> > >> Actually, reST was originally designed to write docstrings. > > > > Ah, I didn't know that, given that its design is so much better suited to > > large documents than small isolated text. > > > >> > >> It seems to me wrong to go with any other markup language, given that > the > >> standard in the Python world in reST. It is hard enough to agree on > >> standards, let us rejoice that there is one. > > > > We thought about this quite a bit, and concluded that markdown was just a > > better > > fit, despite the Python-ness of reST. reST is just a very bad tool for > > interactive, light text markup, > > but if you can point me to a good javascript reST renderer, we can > > reconsider. > > > >> > >> Gael > > > > > > _______________________________________________ > > IPython-dev mailing list > > IPython-dev at scipy.org > > http://mail.scipy.org/mailman/listinfo/ipython-dev > > > > > > > > -- > Brian E. Granger > Cal Poly State University, San Luis Obispo > bgranger at calpoly.edu and ellisonbg at gmail.com > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110917/c889e02b/attachment.html> From jason-sage at creativetrax.com Sat Sep 17 09:27:17 2011 From: jason-sage at creativetrax.com (Jason Grout) Date: Sat, 17 Sep 2011 08:27:17 -0500 Subject: [IPython-dev] notebook questions In-Reply-To: <CAH4pYpScgPcRM0iXU8n0UdqhBRh6ojTpwgYF3Ge6E+qWzMTSyQ@mail.gmail.com> References: <CAOVFbFh2UymWGuzaLU22MJe12wD3nSNc1PQRTUHXRWNUFg3j7g@mail.gmail.com> <CAHNn8BXbtA-UhNg0m60NOeMS+zzjZFrs_AO8N2-ixVt3QrUrvg@mail.gmail.com> <CAOVFbFh9c12v-BXXENsvG_bqNj8qHKytsiv5PUiyg1mjxLHh2A@mail.gmail.com> <CAH4pYpScgPcRM0iXU8n0UdqhBRh6ojTpwgYF3Ge6E+qWzMTSyQ@mail.gmail.com> Message-ID: <4E74A035.2040709@creativetrax.com> On 9/17/11 12:25 AM, Brian Granger wrote: > A notebook "Clone" capability is on our list as is version control > integration. But I should mention that our model for notebooks is > quite different than that of Sage. The notebook server stores the > notebook documents as JSON text files in the cwd of the notebook. > There is no "notebook database" involved and we encourage storing the > notebook files alongside the rest of your project files. What this > means is that all you have to do to get version control for notebooks > is do "git init" in the directory containing the notebooks. > Obviously, we want more integration in the future, but this simple > model works today. So at this stage, it sounds like: * if a person is personally working on some files, the ipython notebook is a lightweight web interface * if a server is being set up for lots of people, the sage notebook is a much heavier-weight web interface and small groups is where the lines are blurred. This also answers my questions about attaching files to worksheets, etc. It sounds like an pynb file should be thought of as basically a .py file (i.e., just some code to be run), with output possibly also saved and other explanatory text. Whereas in Sage, a worksheet .sws file is more like the entire directory containing code to be executed, supporting files, etc. -Jason From robert.kern at gmail.com Sat Sep 17 19:52:09 2011 From: robert.kern at gmail.com (Robert Kern) Date: Sat, 17 Sep 2011 18:52:09 -0500 Subject: [IPython-dev] notebook questions In-Reply-To: <20110917034415.GE13494@phare.normalesup.org> References: <CAOVFbFh2UymWGuzaLU22MJe12wD3nSNc1PQRTUHXRWNUFg3j7g@mail.gmail.com> <CAHNn8BXbtA-UhNg0m60NOeMS+zzjZFrs_AO8N2-ixVt3QrUrvg@mail.gmail.com> <CAOVFbFh9c12v-BXXENsvG_bqNj8qHKytsiv5PUiyg1mjxLHh2A@mail.gmail.com> <CAHNn8BUovNohpQesJFJw6Og6hFzuDQMC=77py8MR14k4RmM3dQ@mail.gmail.com> <20110917034415.GE13494@phare.normalesup.org> Message-ID: <j53br9$fdl$1@dough.gmane.org> On 9/16/11 10:44 PM, Gael Varoquaux wrote: > On Fri, Sep 16, 2011 at 08:41:23PM -0700, MinRK wrote: >> I noticed that github allows you to choose between several different >> languages for wiki input so I thought you might have something like >> that in mind. I've been using reST for docstrings, sphinx docs, and >> github so I selfishly would prefer not to have to learn another >> simplified markup language. > >> That makes sense, and I expect we will get this request often. The >> problem is reST is really a horrible language >> for in-browser cell markup (as opposed to full document markup, for which >> it is designed), > > Actually, reST was originally designed to write docstrings. Nope, it was designed for writing whole web pages in Zope. http://old.zope.org/Products/ZEO/Wiki/StructuredText -- 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 gael.varoquaux at normalesup.org Sat Sep 17 20:54:56 2011 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Sun, 18 Sep 2011 02:54:56 +0200 Subject: [IPython-dev] notebook questions In-Reply-To: <j53br9$fdl$1@dough.gmane.org> References: <CAOVFbFh2UymWGuzaLU22MJe12wD3nSNc1PQRTUHXRWNUFg3j7g@mail.gmail.com> <CAHNn8BXbtA-UhNg0m60NOeMS+zzjZFrs_AO8N2-ixVt3QrUrvg@mail.gmail.com> <CAOVFbFh9c12v-BXXENsvG_bqNj8qHKytsiv5PUiyg1mjxLHh2A@mail.gmail.com> <CAHNn8BUovNohpQesJFJw6Og6hFzuDQMC=77py8MR14k4RmM3dQ@mail.gmail.com> <20110917034415.GE13494@phare.normalesup.org> <j53br9$fdl$1@dough.gmane.org> Message-ID: <20110918005455.GB16141@phare.normalesup.org> On Sat, Sep 17, 2011 at 06:52:09PM -0500, Robert Kern wrote: > > Actually, reST was originally designed to write docstrings. > Nope, it was designed for writing whole web pages in Zope. > http://old.zope.org/Products/ZEO/Wiki/StructuredText My bad. G From cekees at gmail.com Mon Sep 19 00:09:55 2011 From: cekees at gmail.com (Chris Kees) Date: Sun, 18 Sep 2011 23:09:55 -0500 Subject: [IPython-dev] minimal mpi4py notebook example Message-ID: <CAOVFbFj8hbP=-zP8FTLVW1UyQHNqq5WozeTLj3c+LFXROQE1dw@mail.gmail.com> Could somebody point me to documentation on a simple example of using mip4py from the notebook? I want to do something like $ipcluster ... $ipython notebook --pylab ... and then in the notebook do a simple mpi hello world. I can start the cluster and do it from a standard ipython client but can't seem to set up the notebook correctly to use the engines. Thanks, Chris From fperez.net at gmail.com Mon Sep 19 16:15:19 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 19 Sep 2011 13:15:19 -0700 Subject: [IPython-dev] minimal mpi4py notebook example In-Reply-To: <CAOVFbFj8hbP=-zP8FTLVW1UyQHNqq5WozeTLj3c+LFXROQE1dw@mail.gmail.com> References: <CAOVFbFj8hbP=-zP8FTLVW1UyQHNqq5WozeTLj3c+LFXROQE1dw@mail.gmail.com> Message-ID: <CAHAreOo+orT7pnRBeTZE73A6vS3=Ei+pg9GARUooffMRHs87NQ@mail.gmail.com> Hi Chris, On Sun, Sep 18, 2011 at 9:09 PM, Chris Kees <cekees at gmail.com> wrote: > Could somebody point me to documentation on a simple example of using > mip4py from the notebook? I want to do something like > > $ipcluster ... > $ipython notebook --pylab ... > > and then in the notebook do a simple mpi hello world. I can start the > cluster and do it from a standard ipython client but can't seem to set > up the notebook correctly to use the engines. Just so we understand better precisely what you'd like to see illustrated: do you want the process running the notebook to be itself one of the members of your MPI world (say the rank-0 node)? Or do you want the MPI world to start N nodes to which you then attach from a notebook session and tell them to run various bits of code from within the notebook? With a bit of clarity about what you want to do, we should be able to help you out (and will make that notebook an example in the docs). Cheers, f From fperez.net at gmail.com Mon Sep 19 22:22:45 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 19 Sep 2011 19:22:45 -0700 Subject: [IPython-dev] minimal mpi4py notebook example In-Reply-To: <AF3DA601-7391-42A2-9D11-30DD35D3BFA0@gmail.com> References: <CAOVFbFj8hbP=-zP8FTLVW1UyQHNqq5WozeTLj3c+LFXROQE1dw@mail.gmail.com> <CAHAreOo+orT7pnRBeTZE73A6vS3=Ei+pg9GARUooffMRHs87NQ@mail.gmail.com> <AF3DA601-7391-42A2-9D11-30DD35D3BFA0@gmail.com> Message-ID: <CAHAreOqrH4ujcw=nsN0UQOHUjiu0weOhgRjWd=n=XcqyeK_mSA@mail.gmail.com> Hi Chris, responding on-list so this feedback benefits other users as well... On Mon, Sep 19, 2011 at 1:41 PM, Chris Kees <cekees at gmail.com> wrote: > > I think I can do it either way, but having the notebook be the rank-0 node is probably the most natural for me, since my experience is primarily with SIMD programming. Image files are composited and written to disk by the rank-0 process, so I think they would automatically show up in the notebook (or be easy to fit into the display protocol). ? On the other hand, I can encapsulate the entire parallel program in a function call, so my guess is I can do it either way. I'm not sure it's useful, but below I've included the entire program ?that needs to run either a) in a python interpreter that has already called MPI init or b) in one that was started with mpiexec. Well, after writing my email I realized that it's not so easy right now to have your notebook kernel be one of the mpi ones. There's no fundamental problem with the architecture, it's just a bit of missing code: right now kernels are started by the notebook server process, which then opens up a web connection on one side that maps to that kernel on the other side. We haven't added the ability to create a web notebook connected to an *existing kernel* based on its port information (like you can wire a qt console to an existing kernel). So the mpi processes could start a kernel all they want, there's no way right now to control that kernel via a notebook (though you could control it via a qtconsole, if you print/save the port data somewhere). If, with more experience, we find this to really be a necessary use case we can certainly implement things: all the architecture is designed so it could work, it's just a little bit of missing glue in places. But in the meantime, I've written up (attached) two notebooks for illustrating simple MPI use. The first is really the kind of code you'd run normally in a terminal, but I put it in a notebook to show that it can be a way for your users to start things if they are a bit terminal-phobic. They can use that notebook as a poor-man's terminal, and the 'busy' indicator will be on as long as the cluster is active. They can just stop it with the 'kernel interrupt' button, which effectively sends Ctrl-C. The same goal can be obtained with a screen session into the server (more robust than a simple ssh login), but this makes it nicely sit in your open notebooks next to the real work. The 'real work' is in the 2nd notebook, which just illustrates some basic communication with the engines and uses %autopx with the convenience of whole-cell editing to send them a little bit of MPI code (taken from the mpi4py docs). Let me know if this helps, and if so, we can put it in the docs. Cheers, f -------------- next part -------------- A non-text attachment was scrubbed... Name: parallel_ipcluster.ipynb Type: application/octet-stream Size: 3344 bytes Desc: not available URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110919/ebe8a1cf/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: parallel_mpi.ipynb Type: application/octet-stream Size: 6513 bytes Desc: not available URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110919/ebe8a1cf/attachment-0001.obj> From hans_meine at gmx.net Tue Sep 20 09:03:05 2011 From: hans_meine at gmx.net (Hans Meine) Date: Tue, 20 Sep 2011 15:03:05 +0200 Subject: [IPython-dev] notebook questions In-Reply-To: <20110918005455.GB16141@phare.normalesup.org> References: <CAOVFbFh2UymWGuzaLU22MJe12wD3nSNc1PQRTUHXRWNUFg3j7g@mail.gmail.com> <j53br9$fdl$1@dough.gmane.org> <20110918005455.GB16141@phare.normalesup.org> Message-ID: <201109201503.05203.hans_meine@gmx.net> Am Sonntag, 18. September 2011, 02:54:56 schrieb Gael Varoquaux: > On Sat, Sep 17, 2011 at 06:52:09PM -0500, Robert Kern wrote: > > > Actually, reST was originally designed to write docstrings. > > > > Nope, it was designed for writing whole web pages in Zope. > > > > http://old.zope.org/Products/ZEO/Wiki/StructuredText > > My bad. Not really. reST == _re_structured text. See http://docutils.sourceforge.net/docs/ref/rst/introduction.html#history "StructuredText was developed by Jim Fulton of Zope Corporation ? now released as a part of [ZOPE] ? I discovered StructuredText in late 1999 while searching for a way to document the Python modules in one of my projects. ? I decided that a complete rewrite was in order, and [started reStructuredText]" So you were both right, but talking about two (slightly) different things. ;-) Looking forward to the best rst support in the Notebook thats possible. Maybe a resumable rst parser is needed, possibly even written in JS (shudder), like this one http://codemirror.net/1/story.html Best, Hans From cekees at gmail.com Tue Sep 20 09:22:20 2011 From: cekees at gmail.com (Chris Kees) Date: Tue, 20 Sep 2011 08:22:20 -0500 Subject: [IPython-dev] roundtable on python distro for hpc Message-ID: <CAOVFbFiP=_KVE36KC9LVgw6nasU2Cb3oPMbDLiHccHSXFhj2Ng@mail.gmail.com> I think it would be great if some ipython developers and users were represented on this online "roundtable" on python and software distributions for HPC platforms: http://fixingscientificsoftwaredistribution.blogspot.com/2011/09/round-table-about-fixing-problem-of.html Here is some preliminary discussion as well: https://groups.google.com/d/topic/mpi4py/dOqv4smldbU/discussion Cheers, Chris Kees From fperez.net at gmail.com Tue Sep 20 14:41:44 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 20 Sep 2011 11:41:44 -0700 Subject: [IPython-dev] notebook questions In-Reply-To: <20110917034415.GE13494@phare.normalesup.org> References: <CAOVFbFh2UymWGuzaLU22MJe12wD3nSNc1PQRTUHXRWNUFg3j7g@mail.gmail.com> <CAHNn8BXbtA-UhNg0m60NOeMS+zzjZFrs_AO8N2-ixVt3QrUrvg@mail.gmail.com> <CAOVFbFh9c12v-BXXENsvG_bqNj8qHKytsiv5PUiyg1mjxLHh2A@mail.gmail.com> <CAHNn8BUovNohpQesJFJw6Og6hFzuDQMC=77py8MR14k4RmM3dQ@mail.gmail.com> <20110917034415.GE13494@phare.normalesup.org> Message-ID: <CAHAreOo+S0jfWposh-cSTiEmuqKQuZOKpVsedJq4ykR1ktOmYg@mail.gmail.com> On Fri, Sep 16, 2011 at 8:44 PM, Gael Varoquaux <gael.varoquaux at normalesup.org> wrote: > > It seems to me wrong to go with any other markup language, given that the > standard in the Python world in reST. It is hard enough to agree on > standards, let us rejoice that there is one. I would have hoped for less of a cheap shot coming from you. We've explained (I said it many times at Euroscipy, with lots of detail) that there are *technical* reasons why we weren't able to put reST/shpinx integration into the notebook from day one, despite all of us desperately wanting it. We've heard of sphinx before, believe it or not. But the design of reST, in particular the highly stateful nature of the parsing process that makes whole-document multi-pass processing more or less mandatory, makes it complex and costly to implement. It's especially hard in an environment like the notebook, where you'd like to provide immediate feedback on a per-cell basis while keeping the load on the server as light as possible, and the number of asynchronous processes in flight to a minimum (these add complexity and brittleness). Cheers, f From fperez.net at gmail.com Tue Sep 20 15:28:21 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 20 Sep 2011 12:28:21 -0700 Subject: [IPython-dev] notebook questions In-Reply-To: <4E74A035.2040709@creativetrax.com> References: <CAOVFbFh2UymWGuzaLU22MJe12wD3nSNc1PQRTUHXRWNUFg3j7g@mail.gmail.com> <CAHNn8BXbtA-UhNg0m60NOeMS+zzjZFrs_AO8N2-ixVt3QrUrvg@mail.gmail.com> <CAOVFbFh9c12v-BXXENsvG_bqNj8qHKytsiv5PUiyg1mjxLHh2A@mail.gmail.com> <CAH4pYpScgPcRM0iXU8n0UdqhBRh6ojTpwgYF3Ge6E+qWzMTSyQ@mail.gmail.com> <4E74A035.2040709@creativetrax.com> Message-ID: <CAHAreOp71vUZa-1j-7STqgPAMs2Af_tx80oTzjoP8nnV4VfU5w@mail.gmail.com> On Sat, Sep 17, 2011 at 6:27 AM, Jason Grout <jason-sage at creativetrax.com> wrote: > > > Whereas in Sage, a worksheet .sws file is more like the entire directory > containing code to be executed, supporting files, etc. Yes, and there's an important reason behind this difference: for us, being able to type ls in a notebook and still getting the 'real' directory listing is very important. The notebook is controlling a regular ipython kernel that works just like the cmd-line ipython, with direct access to local files, the ability to %run scripts, etc. We wanted this lightweight, your-filesystem-is-still-yours model because it's a very natural worfklow when analyzing data and working with local files. In contrast, Sage uses the filesystem for its own execution model, with temporary directories created for cell execution. This means that ls/os.listdir('.') shows this internal filesystem structure. There are many benefits for Sage with this approach and it's certainly a valid one, but for our use cases and for fitting naturally with the command-line ipython, we went with our model instead, that leaves the filesystem/cwd unmodified, and where a notebook is just one more file sitting in your working directory. I hope this clarifies things somewhat. Cheers, f From gael.varoquaux at normalesup.org Tue Sep 20 17:56:13 2011 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Tue, 20 Sep 2011 23:56:13 +0200 Subject: [IPython-dev] notebook questions In-Reply-To: <CAHAreOo+S0jfWposh-cSTiEmuqKQuZOKpVsedJq4ykR1ktOmYg@mail.gmail.com> References: <CAOVFbFh2UymWGuzaLU22MJe12wD3nSNc1PQRTUHXRWNUFg3j7g@mail.gmail.com> <CAHNn8BXbtA-UhNg0m60NOeMS+zzjZFrs_AO8N2-ixVt3QrUrvg@mail.gmail.com> <CAOVFbFh9c12v-BXXENsvG_bqNj8qHKytsiv5PUiyg1mjxLHh2A@mail.gmail.com> <CAHNn8BUovNohpQesJFJw6Og6hFzuDQMC=77py8MR14k4RmM3dQ@mail.gmail.com> <20110917034415.GE13494@phare.normalesup.org> <CAHAreOo+S0jfWposh-cSTiEmuqKQuZOKpVsedJq4ykR1ktOmYg@mail.gmail.com> Message-ID: <20110920215613.GB4207@phare.normalesup.org> On Tue, Sep 20, 2011 at 11:41:44AM -0700, Fernando Perez wrote: > On Fri, Sep 16, 2011 at 8:44 PM, Gael Varoquaux > <gael.varoquaux at normalesup.org> wrote: > > It seems to me wrong to go with any other markup language, given that the > > standard in the Python world in reST. It is hard enough to agree on > > standards, let us rejoice that there is one. > I would have hoped for less of a cheap shot coming from you. I am a bit saddened that you call this a cheap shot. I am giving a user's point of view that differs from your developper's point of view, but is definitely a point of view many people will have. > We've explained (I said it many times at Euroscipy, with lots of > detail) that there are *technical* reasons why we weren't able to put > reST/shpinx integration into the notebook from day one, despite all of > us desperately wanting it. We've heard of sphinx before, believe it > or not. When I was working at Enthought, in such a situation, Eric Jones would tell me that I am letting a technical difficulty force a user interface decision (he had a good sentence for that, but I can't remember it). Of course, it's a tradeoff: you can put the cost on the developer, or on the user. Depending on your target audience and the size of your development team, you choose the right compromise in the tradeoff space. I still expect that you will get this question many times, just like when I work with people that I new to Python, they keep asking me why Python cannot reload modules reliably. This is not the end of the world, but I do think that it helps to think about usability when make core choices, and of course balance them with the other parts of the equation. I cannot make choices for you. Cheers, Gael From takowl at gmail.com Tue Sep 20 18:30:41 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Tue, 20 Sep 2011 23:30:41 +0100 Subject: [IPython-dev] notebook questions In-Reply-To: <20110920215613.GB4207@phare.normalesup.org> References: <CAOVFbFh2UymWGuzaLU22MJe12wD3nSNc1PQRTUHXRWNUFg3j7g@mail.gmail.com> <CAHNn8BXbtA-UhNg0m60NOeMS+zzjZFrs_AO8N2-ixVt3QrUrvg@mail.gmail.com> <CAOVFbFh9c12v-BXXENsvG_bqNj8qHKytsiv5PUiyg1mjxLHh2A@mail.gmail.com> <CAHNn8BUovNohpQesJFJw6Og6hFzuDQMC=77py8MR14k4RmM3dQ@mail.gmail.com> <20110917034415.GE13494@phare.normalesup.org> <CAHAreOo+S0jfWposh-cSTiEmuqKQuZOKpVsedJq4ykR1ktOmYg@mail.gmail.com> <20110920215613.GB4207@phare.normalesup.org> Message-ID: <CAOvn4qh-0-5MRPsjxnpbfB8p2ZTWRdOYt8-1y1y1pfM00GLu2Q@mail.gmail.com> On 20 September 2011 22:56, Gael Varoquaux <gael.varoquaux at normalesup.org>wrote: > Of > course, it's a tradeoff: you can put the cost on the developer, or on the > user. Depending on your target audience and the size of your development > team, you choose the right compromise in the tradeoff space > I don't want to add fuel to the fire here, but I'd just like to mention that I actually like markdown from a user perspective (I wasn't involved with notebook development). Things like the link syntax feel more natural than reST, and the option to use HTML tags is useful. It's also widely used on popular websites, and it wouldn't surprise me to learn that casual users are more familiar with it than they are with reST. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110920/7998a7bf/attachment.html> From benjaminrk at gmail.com Tue Sep 20 18:45:53 2011 From: benjaminrk at gmail.com (MinRK) Date: Tue, 20 Sep 2011 15:45:53 -0700 Subject: [IPython-dev] notebook questions In-Reply-To: <20110920215613.GB4207@phare.normalesup.org> References: <CAOVFbFh2UymWGuzaLU22MJe12wD3nSNc1PQRTUHXRWNUFg3j7g@mail.gmail.com> <CAHNn8BXbtA-UhNg0m60NOeMS+zzjZFrs_AO8N2-ixVt3QrUrvg@mail.gmail.com> <CAOVFbFh9c12v-BXXENsvG_bqNj8qHKytsiv5PUiyg1mjxLHh2A@mail.gmail.com> <CAHNn8BUovNohpQesJFJw6Og6hFzuDQMC=77py8MR14k4RmM3dQ@mail.gmail.com> <20110917034415.GE13494@phare.normalesup.org> <CAHAreOo+S0jfWposh-cSTiEmuqKQuZOKpVsedJq4ykR1ktOmYg@mail.gmail.com> <20110920215613.GB4207@phare.normalesup.org> Message-ID: <CAHNn8BX-Wh=Nj7RaCVdMdX5oxDe_Qjwg=Z7yc-7SYmdRv+8yiQ@mail.gmail.com> On Tue, Sep 20, 2011 at 14:56, Gael Varoquaux <gael.varoquaux at normalesup.org > wrote: > On Tue, Sep 20, 2011 at 11:41:44AM -0700, Fernando Perez wrote: > > On Fri, Sep 16, 2011 at 8:44 PM, Gael Varoquaux > > <gael.varoquaux at normalesup.org> wrote: > > > > It seems to me wrong to go with any other markup language, given that > the > > > standard in the Python world in reST. It is hard enough to agree on > > > standards, let us rejoice that there is one. > > > I would have hoped for less of a cheap shot coming from you. > > I am a bit saddened that you call this a cheap shot. I am giving a user's > point of view that differs from your developper's point of view, but is > definitely a point of view many people will have. > > > We've explained (I said it many times at Euroscipy, with lots of > > detail) that there are *technical* reasons why we weren't able to put > > reST/shpinx integration into the notebook from day one, despite all of > > us desperately wanting it. We've heard of sphinx before, believe it > > or not. > > When I was working at Enthought, in such a situation, Eric Jones would > tell me that I am letting a technical difficulty force a user interface > decision (he had a good sentence for that, but I can't remember it). Of > course, it's a tradeoff: you can put the cost on the developer, or on the > user. Depending on your target audience and the size of your development > team, you choose the right compromise in the tradeoff space. > > I still expect that you will get this question many times, just like when > I work with people that I new to Python, they keep asking me why Python > cannot reload modules reliably. This is not the end of the world, but I > do think that it helps to think about usability when make core choices, > and of course balance them with the other parts of the equation. I cannot > make choices for you. > Yes, many Python people will want rST instead of markdown, and they will get it - but not like the markdown cell is done right now, with nice, responsive single-cell rendering in the browser. We have actually made this choice with user experience in mind. The design of the language makes rST a very bad choice for light interactive text cells, and when we implement rST support, it should be for full-document formatting, where rST's advantages can shine. For instance, if you have a header in a text cell, would you expect that your formatting, links, etc. be consistent throughout the document, or independent on a per-cell basis? It makes sense from an rST perspective that you would want your header levels to be respected across cells. However, since rST simply interprets the first header-style it sees as h1, the second as h2, etc. this means that the only reasonable option is to rerender all cells together every single time - cells *cannot* be rendered independently. That, combined with rST performance, means that the interactive user experience we want is simply not achievable. It is simply the wrong tool for the job, from a user-experience perspective. When we do use rST, it will format the cells all together, in order to preserve the scope behavior that rST writers expect. Choosing rST will mean forfeiting some quality of the interactive experience for the more powerful tool. We *will* support it, but in an appropriate manner that actually benefits from rST's advantages over md. -MinRK > > Cheers, > > Gael > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110920/17a768de/attachment.html> From fperez.net at gmail.com Tue Sep 20 18:50:52 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 20 Sep 2011 15:50:52 -0700 Subject: [IPython-dev] notebook questions In-Reply-To: <20110920215613.GB4207@phare.normalesup.org> References: <CAOVFbFh2UymWGuzaLU22MJe12wD3nSNc1PQRTUHXRWNUFg3j7g@mail.gmail.com> <CAHNn8BXbtA-UhNg0m60NOeMS+zzjZFrs_AO8N2-ixVt3QrUrvg@mail.gmail.com> <CAOVFbFh9c12v-BXXENsvG_bqNj8qHKytsiv5PUiyg1mjxLHh2A@mail.gmail.com> <CAHNn8BUovNohpQesJFJw6Og6hFzuDQMC=77py8MR14k4RmM3dQ@mail.gmail.com> <20110917034415.GE13494@phare.normalesup.org> <CAHAreOo+S0jfWposh-cSTiEmuqKQuZOKpVsedJq4ykR1ktOmYg@mail.gmail.com> <20110920215613.GB4207@phare.normalesup.org> Message-ID: <CAHAreOovaijvuMfs1sJEvq77oToO8w6FRxiKw4f4=vbj3CVKzA@mail.gmail.com> On Tue, Sep 20, 2011 at 2:56 PM, Gael Varoquaux <gael.varoquaux at normalesup.org> wrote: > > I am a bit saddened that you call this a cheap shot. I am giving a user's > point of view that differs from your developper's point of view, but is > definitely a point of view many people will have. The problem is that you said we were making the wrong choice and ignoring standards. When we've made it abundantly clear that we *want* to support reST, and we *will* support reST/sphinx, and we know about it, but it's so complex to do that we didn't have the manpower to do it *initially*. You accuse us of ignoring standards and making the wrong choices when we've explicitly said we're simply doing first what we can do *given the limited manpower we have*, and how we plan to tackle the harder reST problem as our resources allow. So yes, ignoring the real-world constraints we have and that you are well aware of, and claiming we're making invalid choices that ignore standards and user experience instead, is a cheap shot. Cheers, f From jason-sage at creativetrax.com Tue Sep 20 19:22:50 2011 From: jason-sage at creativetrax.com (Jason Grout) Date: Tue, 20 Sep 2011 18:22:50 -0500 Subject: [IPython-dev] notebook questions In-Reply-To: <CAHAreOp71vUZa-1j-7STqgPAMs2Af_tx80oTzjoP8nnV4VfU5w@mail.gmail.com> References: <CAOVFbFh2UymWGuzaLU22MJe12wD3nSNc1PQRTUHXRWNUFg3j7g@mail.gmail.com> <CAHNn8BXbtA-UhNg0m60NOeMS+zzjZFrs_AO8N2-ixVt3QrUrvg@mail.gmail.com> <CAOVFbFh9c12v-BXXENsvG_bqNj8qHKytsiv5PUiyg1mjxLHh2A@mail.gmail.com> <CAH4pYpScgPcRM0iXU8n0UdqhBRh6ojTpwgYF3Ge6E+qWzMTSyQ@mail.gmail.com> <4E74A035.2040709@creativetrax.com> <CAHAreOp71vUZa-1j-7STqgPAMs2Af_tx80oTzjoP8nnV4VfU5w@mail.gmail.com> Message-ID: <4E79204A.3040705@creativetrax.com> On 9/20/11 2:28 PM, Fernando Perez wrote: > On Sat, Sep 17, 2011 at 6:27 AM, Jason Grout > <jason-sage at creativetrax.com> wrote: >> >> >> Whereas in Sage, a worksheet .sws file is more like the entire directory >> containing code to be executed, supporting files, etc. > > Yes, and there's an important reason behind this difference: for us, > being able to type > > ls > > in a notebook and still getting the 'real' directory listing is very > important. The notebook is controlling a regular ipython kernel that > works just like the cmd-line ipython, with direct access to local > files, the ability to %run scripts, etc. We wanted this lightweight, > your-filesystem-is-still-yours model because it's a very natural > worfklow when analyzing data and working with local files. In > contrast, Sage uses the filesystem for its own execution model, with > temporary directories created for cell execution. This means that > ls/os.listdir('.') shows this internal filesystem structure. > > There are many benefits for Sage with this approach and it's certainly > a valid one, but for our use cases and for fitting naturally with the > command-line ipython, we went with our model instead, that leaves the > filesystem/cwd unmodified, and where a notebook is just one more file > sitting in your working directory. > > I hope this clarifies things somewhat. Perfect. There are important use-cases for both scenarios. I'm glad ipython fills this role. Thanks, Jason From mark.voorhies at ucsf.edu Tue Sep 20 20:09:49 2011 From: mark.voorhies at ucsf.edu (Mark Voorhies) Date: Tue, 20 Sep 2011 17:09:49 -0700 Subject: [IPython-dev] IPython build environment on Ubuntu 10.04 Message-ID: <201109201709.50083.mark.voorhies@ucsf.edu> Just finished submitting a manuscript and have some time to do a bit of IPython hacking. It looks like my installed dependencies are sufficiently out of date that I should rebuild my environment (Cython/ZMQ/PyZMQ/IPython) from scratch. Does anyone have advice for doing a non-system install of these pieces (e.g., to $HOME/ipython/) on Ubuntu 10.04, preferably from their VCS versions? Thanks in advance, Mark From fperez.net at gmail.com Tue Sep 20 21:42:38 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 20 Sep 2011 18:42:38 -0700 Subject: [IPython-dev] IPython build environment on Ubuntu 10.04 In-Reply-To: <201109201709.50083.mark.voorhies@ucsf.edu> References: <201109201709.50083.mark.voorhies@ucsf.edu> Message-ID: <CAHAreOpP48iUr9UWsyMUeA9F+bS379U5k0iQPPPActSRc5OcGg@mail.gmail.com> Hi Mark, On Tue, Sep 20, 2011 at 5:09 PM, Mark Voorhies <mark.voorhies at ucsf.edu> wrote: > Just finished submitting a manuscript and have some time to do a bit of IPython hacking. > It looks like my installed dependencies are sufficiently out of date that I should rebuild > my environment (Cython/ZMQ/PyZMQ/IPython) from scratch. Unless you plan to hack on pyzmq itself, you don't need cython to just install pyzmq. > Does anyone have advice for doing a non-system install of these pieces > (e.g., to $HOME/ipython/) on Ubuntu 10.04, preferably from their VCS versions? My standard procesure is just to install things in $HOME/usr/local via python setup.py --prefix=$HOME/usr/local or ./configure --prefix=$HOME/usr/local && make && make install I have $PATH, $PYTHONPATH, $LD_LIBRARY_PATH and other such variables configured for this to work out of the box. If you need a hand with this I'm happy to send over my bash utils that take care of it. I'd recommend you go with released versions of zmq/pyzmq, as there's no need to use the bleeding edge of those. If you're interested in the web notebook you'll need tornado from git, that's currently our only non-released dependency. Looking forward to having you contribute again! Please let us know if you get stuck on anything. Cheers, f From benjaminrk at gmail.com Wed Sep 21 00:01:01 2011 From: benjaminrk at gmail.com (MinRK) Date: Tue, 20 Sep 2011 21:01:01 -0700 Subject: [IPython-dev] IPython build environment on Ubuntu 10.04 In-Reply-To: <CAHAreOpP48iUr9UWsyMUeA9F+bS379U5k0iQPPPActSRc5OcGg@mail.gmail.com> References: <201109201709.50083.mark.voorhies@ucsf.edu> <CAHAreOpP48iUr9UWsyMUeA9F+bS379U5k0iQPPPActSRc5OcGg@mail.gmail.com> Message-ID: <CAHNn8BVwQrUEZVXR7MiMZZS=bqyVk1-CKTnSBj-tXbZ2Ss9NBQ@mail.gmail.com> On Tue, Sep 20, 2011 at 18:42, Fernando Perez <fperez.net at gmail.com> wrote: > Hi Mark, > > On Tue, Sep 20, 2011 at 5:09 PM, Mark Voorhies <mark.voorhies at ucsf.edu> > wrote: > > Just finished submitting a manuscript and have some time to do a bit of > IPython hacking. > > It looks like my installed dependencies are sufficiently out of date that > I should rebuild > > my environment (Cython/ZMQ/PyZMQ/IPython) from scratch. > > Unless you plan to hack on pyzmq itself, you don't need cython to just > install pyzmq. > It's true - the only dev version of anything we currently depend on is tornado (for the notebooks only), since browsers have made websocket protocol changes in the their most recent versions, that are not compatible with the tornado 2.0-release. And pyzmq is easy_installable *iff* libzmq is in a default place like /usr/local. Otherwise, you have to run the configure step first, to tell it where libzmq is. However, if you do feel like tracking Cython, PyZMQ, IPython, and Tornado, your wish is my command: https://gist.github.com/1231171 I just created a brand new Ubuntu 11.04 VM, with no bashrc or anything, and ran: $> sudo apt-get install git uuid-dev python-dev python-qt4 python-pygments # the last two are only for the qtconsole $> export PATH=$HOME/.local:$PATH # add this, and optionally the matching LD_LIBRARY_PATH to your .bashrc $> wget https://raw.github.com/gist/1231171/ipdev.sh $> bash ipdev.sh And I have the IPython cluster, notebook server, qtconsole, etc. all ready to run (and git repos for Cython, PyZMQ, IPython, and Tornado in a new `code` directory). If you don't want to keep the repos around, it's actually even easier, as you can always install the current git snapshot of projects on github with: $> easy_install --user https://github.com/ipython/ipython/tarball/master > > Does anyone have advice for doing a non-system install of these pieces > > (e.g., to $HOME/ipython/) on Ubuntu 10.04, preferably from their VCS > versions? > > My standard procesure is just to install things in $HOME/usr/local via > > python setup.py --prefix=$HOME/usr/local > > or > > ./configure --prefix=$HOME/usr/local && make && make install > > I have $PATH, $PYTHONPATH, $LD_LIBRARY_PATH and other such variables > configured for this to work out of the box. If you need a hand with > this I'm happy to send over my bash utils that take care of it. > I do a similar thing, but just use '--user' for Python installs, which go to ~/.local, which I symlink to ~/usr/local, using the two paths interchangeably. This way, only PATH and LD_LIBRARY_PATH are needed, as Python (>= 2.6) already searches that location by default. in fact, even LD_LIB.. is often not needed, as rpaths are coded into dylibs, so pyzmq will still work, even without setting the LD_LIB path, but I set it anyway. -MinRK > > I'd recommend you go with released versions of zmq/pyzmq, as there's > no need to use the bleeding edge of those. If you're interested in > the web notebook you'll need tornado from git, that's currently our > only non-released dependency. > > Looking forward to having you contribute again! Please let us know if > you get stuck on anything. > > 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: <http://mail.python.org/pipermail/ipython-dev/attachments/20110920/91447bef/attachment.html> From cekees at gmail.com Wed Sep 21 00:24:02 2011 From: cekees at gmail.com (Chris Kees) Date: Tue, 20 Sep 2011 23:24:02 -0500 Subject: [IPython-dev] minimal mpi4py notebook example In-Reply-To: <CAHAreOqrH4ujcw=nsN0UQOHUjiu0weOhgRjWd=n=XcqyeK_mSA@mail.gmail.com> References: <CAOVFbFj8hbP=-zP8FTLVW1UyQHNqq5WozeTLj3c+LFXROQE1dw@mail.gmail.com> <CAHAreOo+orT7pnRBeTZE73A6vS3=Ei+pg9GARUooffMRHs87NQ@mail.gmail.com> <AF3DA601-7391-42A2-9D11-30DD35D3BFA0@gmail.com> <CAHAreOqrH4ujcw=nsN0UQOHUjiu0weOhgRjWd=n=XcqyeK_mSA@mail.gmail.com> Message-ID: <CAOVFbFji2f0jZ=5HvHhM2rG3Psf8kkwi-vTjaUA6d2WK=LZiMw@mail.gmail.com> Hi Fernando, Success! I ran your notebook example and turned it into a parallel test problem from proteus. I think %autopx is all one needs to make nice notebooks for parallel PDE initial/boundary problems. Just bracket your SPMD parts of the program with %autopx. I will try to get the visualization hooked to the display protocol at some point in the next few weeks. I've got a lot to learn about debugging and passing information back and forth to the engines, but this is a good start. Thanks, Chris On Mon, Sep 19, 2011 at 9:22 PM, Fernando Perez <fperez.net at gmail.com> wrote: > Hi Chris, > > responding on-list so this feedback benefits other users as well... > > On Mon, Sep 19, 2011 at 1:41 PM, Chris Kees <cekees at gmail.com> wrote: >> >> I think I can do it either way, but having the notebook be the rank-0 node is probably the most natural for me, since my experience is primarily with SIMD programming. Image files are composited and written to disk by the rank-0 process, so I think they would automatically show up in the notebook (or be easy to fit into the display protocol). ? On the other hand, I can encapsulate the entire parallel program in a function call, so my guess is I can do it either way. I'm not sure it's useful, but below I've included the entire program ?that needs to run either a) in a python interpreter that has already called MPI init or b) in one that was started with mpiexec. > > Well, after writing my email I realized that it's not so easy right > now to have your notebook kernel be one of the mpi ones. ?There's no > fundamental problem with the architecture, it's just a bit of missing > code: right now kernels are started by the notebook server process, > which then opens up a web connection on one side that maps to that > kernel on the other side. ?We haven't added the ability to create a > web notebook connected to an *existing kernel* based on its port > information (like you can wire a qt console to an existing kernel). > So the mpi processes could start a kernel all they want, there's no > way right now to control that kernel via a notebook (though you could > control it via a qtconsole, if you print/save the port data > somewhere). > > If, with more experience, we find this to really be a necessary use > case we can certainly implement things: all the architecture is > designed so it could work, it's just a little bit of missing glue in > places. > > But in the meantime, I've written up (attached) two notebooks for > illustrating simple MPI use. ?The first is really the kind of code > you'd run normally in a terminal, but I put it in a notebook to show > that it can be a way for your users to start things if they are a bit > terminal-phobic. ?They can use that notebook as a poor-man's terminal, > and the 'busy' indicator will be on as long as the cluster is active. > They can just stop it with the 'kernel interrupt' button, which > effectively sends Ctrl-C. ?The same goal can be obtained with a screen > session into the server (more robust than a simple ssh login), but > this makes it nicely sit in your open notebooks next to the real work. > > The 'real work' is in the 2nd notebook, which just illustrates some > basic communication with the engines and uses %autopx with the > convenience of whole-cell editing to send them a little bit of MPI > code (taken from the mpi4py docs). > > Let me know if this helps, and if so, we can put it in the docs. > > Cheers, > > f > From rohit.hiwale at gmail.com Wed Sep 21 03:07:26 2011 From: rohit.hiwale at gmail.com (rohit hiwale) Date: Wed, 21 Sep 2011 12:37:26 +0530 Subject: [IPython-dev] Can I open ipython from another python script with some objects shared (like code.InteractiveConsole) ? Message-ID: <CAG8qnkyB1ctfzw-RgZ-S_eG3RH3C4gBpLEi5rp=R5_rtEr+yDQ@mail.gmail.com> I have a qt application. I want to share my MainWindow object with ipython for debugging purpose. Currently I am using code.InteractiveConsole which allows me to initialize the locals for the python console. *eg. myconsole = code.InteractiveConsole(locals={'shared_object':MainWindow_object})* * myconsole.interact()* Does ipython supports such interactive console ? If yes, how can I do same thing with ipython ? It will be even better if it can be done with ipython-qtconsole !! PS : ipython-qtconsole is awesome !! Cheers, Rohit -- Rohit Hiwale Final year Dual Degree (Bachelors+Masters) student Department of Computer Science & Engineering Indian Institute of Technology, Kharagpur -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110921/4606c92a/attachment.html> From takowl at gmail.com Wed Sep 21 13:01:42 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 21 Sep 2011 18:01:42 +0100 Subject: [IPython-dev] Tornado 2.1 Message-ID: <CAOvn4qhGK1L91MsULFKjxNOuNLcWaKw1yDVPVai3YTjukMwXsg@mail.gmail.com> I see Tornado have just made a 2.1 release, including the new websocket protocol. Hopefully the notebook will carry on working with the released version. http://www.tornadoweb.org/documentation/releases/v2.1.0.html Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110921/d5a13197/attachment.html> From mark.voorhies at ucsf.edu Wed Sep 21 13:15:28 2011 From: mark.voorhies at ucsf.edu (Mark Voorhies) Date: Wed, 21 Sep 2011 10:15:28 -0700 Subject: [IPython-dev] IPython build environment on Ubuntu 10.04 In-Reply-To: <CAHNn8BVwQrUEZVXR7MiMZZS=bqyVk1-CKTnSBj-tXbZ2Ss9NBQ@mail.gmail.com> References: <201109201709.50083.mark.voorhies@ucsf.edu> <CAHAreOpP48iUr9UWsyMUeA9F+bS379U5k0iQPPPActSRc5OcGg@mail.gmail.com> <CAHNn8BVwQrUEZVXR7MiMZZS=bqyVk1-CKTnSBj-tXbZ2Ss9NBQ@mail.gmail.com> Message-ID: <201109211015.29287.mark.voorhies@ucsf.edu> On Tuesday, September 20, 2011 09:01:01 pm you wrote: > On Tue, Sep 20, 2011 at 18:42, Fernando Perez <fperez.net at gmail.com> wrote: > > > Hi Mark, > > > > On Tue, Sep 20, 2011 at 5:09 PM, Mark Voorhies <mark.voorhies at ucsf.edu> > > wrote: > > > Just finished submitting a manuscript and have some time to do a bit of > > IPython hacking. > > > It looks like my installed dependencies are sufficiently out of date that > > I should rebuild > > > my environment (Cython/ZMQ/PyZMQ/IPython) from scratch. > > > > Unless you plan to hack on pyzmq itself, you don't need cython to just > > install pyzmq. > > > > It's true - the only dev version of anything we currently depend on is > tornado (for the notebooks only), since browsers have made websocket > protocol changes in the their most recent versions, that are not compatible > with the tornado 2.0-release. > > And pyzmq is easy_installable *iff* libzmq is in a default place like > /usr/local. Otherwise, you have to run the configure step first, to tell it > where libzmq is. > > However, if you do feel like tracking Cython, PyZMQ, IPython, and Tornado, > your wish is my command: > https://gist.github.com/1231171 > > I just created a brand new Ubuntu 11.04 VM, with no bashrc or anything, and > ran: > > $> sudo apt-get install git uuid-dev python-dev python-qt4 python-pygments # > the last two are only for the qtconsole > $> export PATH=$HOME/.local:$PATH # add this, and optionally the matching > LD_LIBRARY_PATH to your .bashrc > $> wget https://raw.github.com/gist/1231171/ipdev.sh > $> bash ipdev.sh > > And I have the IPython cluster, notebook server, qtconsole, etc. all ready > to run (and git repos for Cython, PyZMQ, IPython, and Tornado in a new > `code` directory). > Wow! For the record, Min's script works out of the box on Ubuntu 10.04. Thanks, Min and Fernando. --Mark > If you don't want to keep the repos around, it's actually even easier, as > you can always install the current git snapshot of projects on github with: > > $> easy_install --user https://github.com/ipython/ipython/tarball/master > > > > > Does anyone have advice for doing a non-system install of these pieces > > > (e.g., to $HOME/ipython/) on Ubuntu 10.04, preferably from their VCS > > versions? > > > > My standard procesure is just to install things in $HOME/usr/local via > > > > python setup.py --prefix=$HOME/usr/local > > > > or > > > > ./configure --prefix=$HOME/usr/local && make && make install > > > > > I have $PATH, $PYTHONPATH, $LD_LIBRARY_PATH and other such variables > > configured for this to work out of the box. If you need a hand with > > this I'm happy to send over my bash utils that take care of it. > > > > I do a similar thing, but just use '--user' for Python installs, which go to > ~/.local, which I symlink to ~/usr/local, using the two paths > interchangeably. This way, only PATH and LD_LIBRARY_PATH are needed, as > Python (>= 2.6) already searches that location by default. in fact, even > LD_LIB.. is often not needed, as rpaths are coded into dylibs, so pyzmq will > still work, even without setting the LD_LIB path, but I set it anyway. > > -MinRK > > > > > > > I'd recommend you go with released versions of zmq/pyzmq, as there's > > no need to use the bleeding edge of those. If you're interested in > > the web notebook you'll need tornado from git, that's currently our > > only non-released dependency. > > > > Looking forward to having you contribute again! Please let us know if > > you get stuck on anything. > > > > 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 Sep 21 13:20:35 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 21 Sep 2011 10:20:35 -0700 Subject: [IPython-dev] Tornado 2.1 In-Reply-To: <CAOvn4qhGK1L91MsULFKjxNOuNLcWaKw1yDVPVai3YTjukMwXsg@mail.gmail.com> References: <CAOvn4qhGK1L91MsULFKjxNOuNLcWaKw1yDVPVai3YTjukMwXsg@mail.gmail.com> Message-ID: <CAHAreOpY-W_qe2YayFxatuF7N0njbfC6Dg+VYimMcDHO5_Vq1A@mail.gmail.com> On Wed, Sep 21, 2011 at 10:01 AM, Thomas Kluyver <takowl at gmail.com> wrote: > I see Tornado have just made a 2.1 release, including the new websocket > protocol. Hopefully the notebook will carry on working with the released > version. > > http://www.tornadoweb.org/documentation/releases/v2.1.0.html Great news! On my system, the tests all pass with this version, and all the notebooks I looked at interactively work fine, both with Firefox 6 and with Chrome. I'll update our instructions now to point users to this version. See, all we had to do was wait a day ;) Cheers, f From ellisonbg at gmail.com Wed Sep 21 14:32:06 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Wed, 21 Sep 2011 11:32:06 -0700 Subject: [IPython-dev] Tornado 2.1 In-Reply-To: <CAHAreOpY-W_qe2YayFxatuF7N0njbfC6Dg+VYimMcDHO5_Vq1A@mail.gmail.com> References: <CAOvn4qhGK1L91MsULFKjxNOuNLcWaKw1yDVPVai3YTjukMwXsg@mail.gmail.com> <CAHAreOpY-W_qe2YayFxatuF7N0njbfC6Dg+VYimMcDHO5_Vq1A@mail.gmail.com> Message-ID: <CAH4pYpQHKS6trkLWwHb2_RfjpwspF3GGTAJDzrspSMvRU_4byg@mail.gmail.com> Great! On Wed, Sep 21, 2011 at 10:20 AM, Fernando Perez <fperez.net at gmail.com> wrote: > On Wed, Sep 21, 2011 at 10:01 AM, Thomas Kluyver <takowl at gmail.com> wrote: >> I see Tornado have just made a 2.1 release, including the new websocket >> protocol. Hopefully the notebook will carry on working with the released >> version. >> >> http://www.tornadoweb.org/documentation/releases/v2.1.0.html > > Great news! ?On my system, the tests all pass with this version, and > all the notebooks I looked at interactively work fine, both with > Firefox 6 and with Chrome. > > I'll update our instructions now to point users to this version. > > See, all we had to do was wait a day ;) > > 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 jtaylor.debian at googlemail.com Wed Sep 21 15:00:07 2011 From: jtaylor.debian at googlemail.com (Julian Taylor) Date: Wed, 21 Sep 2011 21:00:07 +0200 Subject: [IPython-dev] Can I open ipython from another python script with some objects shared (like code.InteractiveConsole) ? In-Reply-To: <CAG8qnkyB1ctfzw-RgZ-S_eG3RH3C4gBpLEi5rp=R5_rtEr+yDQ@mail.gmail.com> References: <CAG8qnkyB1ctfzw-RgZ-S_eG3RH3C4gBpLEi5rp=R5_rtEr+yDQ@mail.gmail.com> Message-ID: <4E7A3437.7050107@googlemail.com> On 09/21/2011 09:07 AM, rohit hiwale wrote: > I have a qt application. > I want to share my MainWindow object with ipython for debugging purpose. > > Currently I am using code.InteractiveConsole which allows me to > initialize the locals for the python console. > /eg. myconsole = > code.InteractiveConsole(locals={'shared_object':MainWindow_object})/ > / myconsole.interact()/ > Does ipython supports such interactive console ? > If yes, how can I do same thing with ipython ? > It will be even better if it can be done with ipython-qtconsole !! > > PS : ipython-qtconsole is awesome !! yes you can embed an terminal ipython console into your application. See an example in docs/examples/core/example-embed.py and this page for both 0.10 and 0.11 variants + a bunch of patches for applications already doing it: http://wiki.ipython.org/Cookbook/Updating_code_that_uses_IPython_for_0.11 Best Regards, Julian Taylor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110921/d22deea5/attachment.sig> From Fernando.Perez at berkeley.edu Fri Sep 23 13:06:55 2011 From: Fernando.Perez at berkeley.edu (Fernando Perez) Date: Fri, 23 Sep 2011 10:06:55 -0700 Subject: [IPython-dev] Fwd: [ftpmaster@ftp-master.debian.org: python-tornado_2.1.0-1_amd64.changes ACCEPTED into unstable] In-Reply-To: <20110923140642.GP5865@onerussian.com> References: <20110923140642.GP5865@onerussian.com> Message-ID: <CAFFEDukvOwJV1224bhv46HavK33qzX_j-SfAYaNDrN+b4g+9YA@mail.gmail.com> A big thank you to Yarik and Michael, the indefatigable engines behind neurodebian, for packaging the new tornado so quickly! ---------- Forwarded message ---------- From: Yaroslav Halchenko <yoh at dartmouth.edu> Date: Fri, Sep 23, 2011 at 07:06 Subject: [ftpmaster at ftp-master.debian.org: python-tornado_2.1.0-1_amd64.changes ACCEPTED into unstable] To: Fernando Perez <fernando.perez at berkeley.edu> Cc: Michael Hanke <michael.hanke at gmail.com> oki doki -- done! also recent Debian (squeeze, wheezy) and Ubuntu (only 11.04) releases can get it from NeuroDebian repository Cheers, ----- Forwarded message from Debian FTP Masters <ftpmaster at ftp-master.debian.org> ----- Date: Fri, 23 Sep 2011 13:36:02 +0000 From: Debian FTP Masters <ftpmaster at ftp-master.debian.org> To: Yaroslav Halchenko <debian at onerussian.com>, ? ? ? ?Debian Python Modules Team <python-modules-team at lists.alioth.debian.org> Subject: python-tornado_2.1.0-1_amd64.changes ACCEPTED into unstable X-CRM114-Status: UNSURE (2.3293) This message is 'unsure'; please train it! Accepted: python-tornado_2.1.0-1.debian.tar.gz ?to main/p/python-tornado/python-tornado_2.1.0-1.debian.tar.gz python-tornado_2.1.0-1.dsc ?to main/p/python-tornado/python-tornado_2.1.0-1.dsc python-tornado_2.1.0-1_amd64.deb ?to main/p/python-tornado/python-tornado_2.1.0-1_amd64.deb python-tornado_2.1.0.orig.tar.gz ?to main/p/python-tornado/python-tornado_2.1.0.orig.tar.gz Override entries for your package: python-tornado_2.1.0-1.dsc - source python python-tornado_2.1.0-1_amd64.deb - optional python Announcing to debian-devel-changes at lists.debian.org Closing bugs: 636602 Thank you for your contribution to Debian. ----- End forwarded message ----- -- Yaroslav O. Halchenko Postdoctoral Fellow, ? Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 ? ? ? ? ? ? ? ? ? ? ? Fax: +1 (603) 646-1419 WWW: ? http://www.linkedin.com/in/yarik From takowl at gmail.com Wed Sep 28 19:09:21 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Thu, 29 Sep 2011 00:09:21 +0100 Subject: [IPython-dev] IPython talk in Sheffield Message-ID: <CAOvn4qgM4vwkpV+sCEkgFtnKyMO+=cGHsN4c0e+BHktpQs_h0Q@mail.gmail.com> I think the talk I gave last night was quite well received - I got quite a few questions afterwards, and several people thanked me for coming to speak about it. I had time to do brief demos of both the Qt console and the notebook. There was particular interest in the notebook, with some of the questions centring on "how easy is it to get that set up?" (I described the bits necessary, and suggested EPD as a good way in from Windows). Twitter user @allegary said "talk on ipython is nice and entertaining - liking what they have done with the place #pysheff". I've attached the slides in PDF format - much of the content is taken from Fernando's slides for Euroscipy. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110929/d18e54d6/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: ipython presentation.pdf Type: application/pdf Size: 790509 bytes Desc: not available URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110929/d18e54d6/attachment.pdf> From fperez.net at gmail.com Wed Sep 28 20:13:14 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 28 Sep 2011 17:13:14 -0700 Subject: [IPython-dev] IPython talk in Sheffield In-Reply-To: <CAOvn4qgM4vwkpV+sCEkgFtnKyMO+=cGHsN4c0e+BHktpQs_h0Q@mail.gmail.com> References: <CAOvn4qgM4vwkpV+sCEkgFtnKyMO+=cGHsN4c0e+BHktpQs_h0Q@mail.gmail.com> Message-ID: <CAHAreOpiDRPDmy0W5DSfbpVEs8J7JXr37Sw-RDMUbbzWCNg=HA@mail.gmail.com> Hey Thomas, On Wed, Sep 28, 2011 at 4:09 PM, Thomas Kluyver <takowl at gmail.com> wrote: > I think the talk I gave last night was quite well received - I got quite a > few questions afterwards, and several people thanked me for coming to speak > about it. I had time to do brief demos of both the Qt console and the > notebook. There was particular interest in the notebook, with some of the > questions centring on "how easy is it to get that set up?" (I described the > bits necessary, and suggested EPD as a good way in from Windows). > > Twitter user @allegary said "talk on ipython is nice and entertaining - > liking what they have done with the place #pysheff". > > I've attached the slides in PDF format - much of the content is taken from > Fernando's slides for Euroscipy. Excellent slides! And thanks a lot for making this presentation! BTW, you should upload the slides over and link them at the presentations page: http://ipython.org/presentation.html I'm behind on some urgent stuff right now, but on Friday perhaps we can start the conversation on "how easy is it to get that set up" by looking at plans to push 0.12 out the door... Cheers, f From takowl at gmail.com Thu Sep 29 08:52:19 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Thu, 29 Sep 2011 13:52:19 +0100 Subject: [IPython-dev] IPython talk in Sheffield In-Reply-To: <CAHAreOpiDRPDmy0W5DSfbpVEs8J7JXr37Sw-RDMUbbzWCNg=HA@mail.gmail.com> References: <CAOvn4qgM4vwkpV+sCEkgFtnKyMO+=cGHsN4c0e+BHktpQs_h0Q@mail.gmail.com> <CAHAreOpiDRPDmy0W5DSfbpVEs8J7JXr37Sw-RDMUbbzWCNg=HA@mail.gmail.com> Message-ID: <CAOvn4qg6ycSrdq8Q6J_jQKZuAjigOkLC101vY8_BnvWQ-AjJSQ@mail.gmail.com> On 29 September 2011 01:13, Fernando Perez <fperez.net at gmail.com> wrote: > Excellent slides! And thanks a lot for making this presentation! > BTW, you should upload the slides over and link them at the > presentations page: > > http://ipython.org/presentation.html > Thanks, Fernando, I'll do that. > I'm behind on some urgent stuff right now, but on Friday perhaps we > can start the conversation on "how easy is it to get that set up" by > looking at plans to push 0.12 out the door... > I think this is a good idea - there's a number of fixes and new stuff that it would be good to get to users sooner rather than later. In particular, I'd like 0.12 to get into Ubuntu 12.04 (P cycle), which will be a long term support release, i.e. some users will stick with it for two years. The automatic syncing of packages from Debian will stop on 29 December ( https://wiki.ubuntu.com/PReleaseSchedule), so that means aiming for a release before Christmas. Best wishes, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110929/5d938306/attachment.html> From hans_meine at gmx.net Thu Sep 29 09:13:10 2011 From: hans_meine at gmx.net (Hans Meine) Date: Thu, 29 Sep 2011 15:13:10 +0200 Subject: [IPython-dev] IPython talk in Sheffield In-Reply-To: <CAHAreOpiDRPDmy0W5DSfbpVEs8J7JXr37Sw-RDMUbbzWCNg=HA@mail.gmail.com> References: <CAOvn4qgM4vwkpV+sCEkgFtnKyMO+=cGHsN4c0e+BHktpQs_h0Q@mail.gmail.com> <CAHAreOpiDRPDmy0W5DSfbpVEs8J7JXr37Sw-RDMUbbzWCNg=HA@mail.gmail.com> Message-ID: <201109291513.11129.hans_meine@gmx.net> Am Donnerstag, 29. September 2011, 02:13:14 schrieb Fernando Perez: > I'm behind on some urgent stuff right now, but on Friday perhaps we > can start the conversation on "how easy is it to get that set up" by > looking at plans to push 0.12 out the door... Concerning "easy setup", I missed PPAs to be mentioned in a recent discussion as an easy installation method for Ubuntu systems. In particular, Chris Lea (whom I don?t know personally, so trust him on your own risk) seems to offer all optional ipython dependencies, so that it is enough to issue: sudo apt-add-repository ppa:chris-lea/libpgm sudo apt-add-repository ppa:chris-lea/zeromq sudo apt-add-repository ppa:chris-lea/python-tornado Afterwards, you can sudo apt-get install python-pyzmq python-tornado and you should even get automatic updates (as soon as he provides ?em). He seems to support Karmic, Lucid, Maverick, and Natty. HTH, Hans From takowl at gmail.com Thu Sep 29 09:39:40 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Thu, 29 Sep 2011 14:39:40 +0100 Subject: [IPython-dev] IPython talk in Sheffield In-Reply-To: <201109291513.11129.hans_meine@gmx.net> References: <CAOvn4qgM4vwkpV+sCEkgFtnKyMO+=cGHsN4c0e+BHktpQs_h0Q@mail.gmail.com> <CAHAreOpiDRPDmy0W5DSfbpVEs8J7JXr37Sw-RDMUbbzWCNg=HA@mail.gmail.com> <201109291513.11129.hans_meine@gmx.net> Message-ID: <CAOvn4qiErHnOXytnJt6GPm8GPDZyw9EXCrmHf7e1sCftWVmcwg@mail.gmail.com> On 29 September 2011 14:13, Hans Meine <hans_meine at gmx.net> wrote: > Concerning "easy setup", I missed PPAs to be mentioned in a recent > discussion > as an easy installation method for Ubuntu systems. In particular, Chris > Lea > (whom I don?t know personally, so trust him on your own risk) seems to > offer > all optional ipython dependencies, so that it is enough to issue: > > sudo apt-add-repository ppa:chris-lea/libpgm > sudo apt-add-repository ppa:chris-lea/zeromq > sudo apt-add-repository ppa:chris-lea/python-tornado > Perhaps even more conveniently, Julian Taylor made an ipython-dev ppa, which contains IPython (albeit not a dev version at the moment), zeromq, pyzmq and libpgm: https://launchpad.net/~jtaylor/+archive/ipython-dev Tornado isn't in there at the moment, but it would be an obvious thing to add if we're packaging the version with the notebook. Hopefully in a few months, we won't be depending on so much bleeding-edge stuff, so it will be easier to set up. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110929/ea661656/attachment.html> From jtaylor.debian at googlemail.com Thu Sep 29 13:27:08 2011 From: jtaylor.debian at googlemail.com (Julian Taylor) Date: Thu, 29 Sep 2011 19:27:08 +0200 Subject: [IPython-dev] IPython ubuntu packaging. In-Reply-To: <CAOvn4qiErHnOXytnJt6GPm8GPDZyw9EXCrmHf7e1sCftWVmcwg@mail.gmail.com> References: <CAOvn4qgM4vwkpV+sCEkgFtnKyMO+=cGHsN4c0e+BHktpQs_h0Q@mail.gmail.com> <CAHAreOpiDRPDmy0W5DSfbpVEs8J7JXr37Sw-RDMUbbzWCNg=HA@mail.gmail.com> <201109291513.11129.hans_meine@gmx.net> <CAOvn4qiErHnOXytnJt6GPm8GPDZyw9EXCrmHf7e1sCftWVmcwg@mail.gmail.com> Message-ID: <4E84AA6C.3020700@googlemail.com> On 09/29/2011 03:39 PM, Thomas Kluyver wrote: > On 29 September 2011 14:13, Hans Meine <hans_meine at gmx.net > <mailto:hans_meine at gmx.net>> wrote: > > Concerning "easy setup", I missed PPAs to be mentioned in a recent > discussion > as an easy installation method for Ubuntu systems. In particular, > Chris Lea > (whom I don?t know personally, so trust him on your own risk) seems > to offer > all optional ipython dependencies, so that it is enough to issue: > > sudo apt-add-repository ppa:chris-lea/libpgm > sudo apt-add-repository ppa:chris-lea/zeromq > sudo apt-add-repository ppa:chris-lea/python-tornado > > > Perhaps even more conveniently, Julian Taylor made an ipython-dev ppa, > which contains IPython (albeit not a dev version at the moment), zeromq, > pyzmq and libpgm: > > https://launchpad.net/~jtaylor/+archive/ipython-dev > > Tornado isn't in there at the moment, but it would be an obvious thing > to add if we're packaging the version with the notebook. Hopefully in a > few months, we won't be depending on so much bleeding-edge stuff, so it > will be easier to set up. > > Thomas > > As the ppa is mentioned, here the current status and future plans for it: The ppa contains 0.11 and its dependencies (mirrored from debian) but currently only for oneiric and natty. After oneiric is released (~2 weeks) I plan on pushing 0.11 or 0.12 to the main archive quite early in the 12.04 LTS cycle. I will then move 0.1[12] to my "stable" ipython ppa and probably support lucid if possible too. Then I can add more or less bleeding edge -dev versions to my ipython-dev ppa including tornado and maybe mathjax (which hopefully will be in debian soon: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627518). Debian experimental packaging will probably be a bit less up to date as I don't have direct uploads rights there. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110929/e4cefc11/attachment.sig> From takowl at gmail.com Thu Sep 29 13:56:22 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Thu, 29 Sep 2011 18:56:22 +0100 Subject: [IPython-dev] IPython ubuntu packaging. In-Reply-To: <4E84AA6C.3020700@googlemail.com> References: <CAOvn4qgM4vwkpV+sCEkgFtnKyMO+=cGHsN4c0e+BHktpQs_h0Q@mail.gmail.com> <CAHAreOpiDRPDmy0W5DSfbpVEs8J7JXr37Sw-RDMUbbzWCNg=HA@mail.gmail.com> <201109291513.11129.hans_meine@gmx.net> <CAOvn4qiErHnOXytnJt6GPm8GPDZyw9EXCrmHf7e1sCftWVmcwg@mail.gmail.com> <4E84AA6C.3020700@googlemail.com> Message-ID: <CAOvn4qidLUh_xOGboVmK34fTMMarffa-pSknYBp-aXL+26+oXw@mail.gmail.com> On 29 September 2011 18:27, Julian Taylor <jtaylor.debian at googlemail.com>wrote: > The ppa contains 0.11 and its dependencies (mirrored from debian) but > currently only for oneiric and natty. > > After oneiric is released (~2 weeks) I plan on pushing 0.11 or 0.12 to > the main archive quite early in the 12.04 LTS cycle. > I will then move 0.1[12] to my "stable" ipython ppa and probably support > lucid if possible too. > Then I can add more or less bleeding edge -dev versions to my > ipython-dev ppa including tornado and maybe mathjax (which hopefully > will be in debian soon: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627518). > Thanks for this, Julian. Do you have a feel for how much work it will be to prepare 0.12 for packaging? I'm hoping it will make it into the 12.04 cycle, so it would be good to know roughly when the window closes. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110929/a2e3b890/attachment.html> From jtaylor.debian at googlemail.com Thu Sep 29 14:13:49 2011 From: jtaylor.debian at googlemail.com (Julian Taylor) Date: Thu, 29 Sep 2011 20:13:49 +0200 Subject: [IPython-dev] IPython ubuntu packaging. In-Reply-To: <CAOvn4qidLUh_xOGboVmK34fTMMarffa-pSknYBp-aXL+26+oXw@mail.gmail.com> References: <CAOvn4qgM4vwkpV+sCEkgFtnKyMO+=cGHsN4c0e+BHktpQs_h0Q@mail.gmail.com> <CAHAreOpiDRPDmy0W5DSfbpVEs8J7JXr37Sw-RDMUbbzWCNg=HA@mail.gmail.com> <201109291513.11129.hans_meine@gmx.net> <CAOvn4qiErHnOXytnJt6GPm8GPDZyw9EXCrmHf7e1sCftWVmcwg@mail.gmail.com> <4E84AA6C.3020700@googlemail.com> <CAOvn4qidLUh_xOGboVmK34fTMMarffa-pSknYBp-aXL+26+oXw@mail.gmail.com> Message-ID: <4E84B55D.9030107@googlemail.com> On 09/29/2011 07:56 PM, Thomas Kluyver wrote: > On 29 September 2011 18:27, Julian Taylor <jtaylor.debian at googlemail.com > <mailto:jtaylor.debian at googlemail.com>> wrote: > > The ppa contains 0.11 and its dependencies (mirrored from debian) but > currently only for oneiric and natty. > > After oneiric is released (~2 weeks) I plan on pushing 0.11 or 0.12 to > the main archive quite early in the 12.04 LTS cycle. > I will then move 0.1[12] to my "stable" ipython ppa and probably support > lucid if possible too. > Then I can add more or less bleeding edge -dev versions to my > ipython-dev ppa including tornado and maybe mathjax (which hopefully > will be in debian soon: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627518). > > > Thanks for this, Julian. Do you have a feel for how much work it will be > to prepare 0.12 for packaging? I'm hoping it will make it into the 12.04 > cycle, so it would be good to know roughly when the window closes. > > Thanks, > Thomas If you don't break the API to badly it will probably not be much work. Pretty much all packaging work that had to be done was already done for 0.11 and should help making packaging of future releases a bit easier. There should be plenty of time to get 0.12 or higher into 12.04, the feature freeze will probably be end of February 2012, the release will be end of April. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110929/520d6d51/attachment.sig> From takowl at gmail.com Thu Sep 29 14:17:59 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Thu, 29 Sep 2011 19:17:59 +0100 Subject: [IPython-dev] IPython ubuntu packaging. In-Reply-To: <4E84B55D.9030107@googlemail.com> References: <CAOvn4qgM4vwkpV+sCEkgFtnKyMO+=cGHsN4c0e+BHktpQs_h0Q@mail.gmail.com> <CAHAreOpiDRPDmy0W5DSfbpVEs8J7JXr37Sw-RDMUbbzWCNg=HA@mail.gmail.com> <201109291513.11129.hans_meine@gmx.net> <CAOvn4qiErHnOXytnJt6GPm8GPDZyw9EXCrmHf7e1sCftWVmcwg@mail.gmail.com> <4E84AA6C.3020700@googlemail.com> <CAOvn4qidLUh_xOGboVmK34fTMMarffa-pSknYBp-aXL+26+oXw@mail.gmail.com> <4E84B55D.9030107@googlemail.com> Message-ID: <CAOvn4qiOEuUMfMrG1USpxV42+Ot77yit+ozTKKrA=f+z4oxw-w@mail.gmail.com> On 29 September 2011 19:13, Julian Taylor <jtaylor.debian at googlemail.com>wrote: > There should be plenty of time to get 0.12 or higher into 12.04, the > feature freeze will probably be end of February 2012, the release will > be end of April. > Will they be cagey about taking things after the import freeze, if its going to be an LTS release? I don't really know about the procedures, but I thought the aim was to get it into Debian before the import freeze, so that it would be synced automatically. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110929/5986f980/attachment.html> From jtaylor.debian at googlemail.com Thu Sep 29 14:58:23 2011 From: jtaylor.debian at googlemail.com (Julian Taylor) Date: Thu, 29 Sep 2011 20:58:23 +0200 Subject: [IPython-dev] IPython ubuntu packaging. In-Reply-To: <CAOvn4qiOEuUMfMrG1USpxV42+Ot77yit+ozTKKrA=f+z4oxw-w@mail.gmail.com> References: <CAOvn4qgM4vwkpV+sCEkgFtnKyMO+=cGHsN4c0e+BHktpQs_h0Q@mail.gmail.com> <CAHAreOpiDRPDmy0W5DSfbpVEs8J7JXr37Sw-RDMUbbzWCNg=HA@mail.gmail.com> <201109291513.11129.hans_meine@gmx.net> <CAOvn4qiErHnOXytnJt6GPm8GPDZyw9EXCrmHf7e1sCftWVmcwg@mail.gmail.com> <4E84AA6C.3020700@googlemail.com> <CAOvn4qidLUh_xOGboVmK34fTMMarffa-pSknYBp-aXL+26+oXw@mail.gmail.com> <4E84B55D.9030107@googlemail.com> <CAOvn4qiOEuUMfMrG1USpxV42+Ot77yit+ozTKKrA=f+z4oxw-w@mail.gmail.com> Message-ID: <4E84BFCF.5000100@googlemail.com> On 09/29/2011 08:17 PM, Thomas Kluyver wrote: > On 29 September 2011 19:13, Julian Taylor <jtaylor.debian at googlemail.com > <mailto:jtaylor.debian at googlemail.com>> wrote: > > There should be plenty of time to get 0.12 or higher into 12.04, the > feature freeze will probably be end of February 2012, the release will > be end of April. > > > Will they be cagey about taking things after the import freeze, if its > going to be an LTS release? I don't really know about the procedures, > but I thought the aim was to get it into Debian before the import > freeze, so that it would be synced automatically. > You can add new stuff after feature freeze, but it should be motivated somehow, e.g. the new features are really useful, it was very well tested etc. Generally whenever the gains outweighs possible regression risks [0]. The closer one gets to release to more conservative one should be, but as long as you have a maintainer who cares about the package and will fix regressions also after release the rules can be relaxed quite a bit, especially for development focused packages like ipython. The packages will be still synced from debian whenever possible. [0] https://wiki.ubuntu.com/FreezeExceptionProcess -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110929/7aed35c7/attachment.sig>