Just wanted to chip in and say this idea is very cool. I don't have any
good ideas/thoughts on the implementation, but I am happy to alpha test
when you have a sample notebook ready to try out.
On Fri, Dec 7, 2012 at 6:27 AM, Brian Granger <ellisonbg@gmail.com> wrote:
> >> Hi, this is really exciting and will be a huge improvement for using
> >> the notebook for real work. I will try to look a bit more at this
> >> over the next week (in the middle of finals right now). But a few
> >> comments:
> >>
> >> * Why exactly do you need cell ids?
> >
> >
> > I've enhanced the test failure stack traces such that the function's
> > "filename" (like <ipython-input-DD-HHHHHHHHHHHH>) links to the cell that
> > defines that code. That makes it easy to click close to the definition
> of a
> > failing test or function. Even better would be linking directly to the
> line
> > of code in question… :) Unfortunately the current implementation has a
> > visual bug when linking to an anchor: the top IPython bar shifts up about
> > 0.3em (it shifts back if you hit the empty fragment, "#").
>> Ahh, this is a nice feature. Can you describe a bit more about how
> you track this information as it flows though the code. Do the cell
> ids get sent to the kernel? What does the kernet do with them?
>> >>
> >> * We are soon going to completely remove the ability to publish
> >> javascript from Python. There are two many horrific security
> >> problems. The replacement abstraction is "javascript plugins" that
> >> are under review here:
> >>
> >> https://github.com/ipython/ipython/pull/2518> >>
> >> There is more work to do on this, but this will give you an idea of
> >> where we are headed. Please ask questions about the plugins on that
> >> PR.
> >
> >
> > That makes a lot of sense. From a quick reading of it, an extension
> would be
> > able to register JS to be loaded onto the page, and the publish_json
> method
> > would allow the payload to be handed to one of those custom functions.
> > There's no reason I can't port this extension to that style once that
> lands.
>> Yep it shouldn't be too difficult.
>> > I do have a few questions up-front:
> > 1. Is there a better way than peeking at sys.displayhook to determine
> what
> > kind of output to produce?
>> I am not quite sure what you mean and how you "peek" and
> sys.displayhook for this.
>> > 2. I'd really like to have cell anchor generation happen always. Seems
> like
> > it would be useful to provide intra-notebook links to cells. I'm not sure
> > how one would manage those links as the execution order evolves, though.
> For
> > this extension, that migration is actually a good thing, as the anchor
> > points to the code that was actually run even if it's no longer visible.
>> I am trying to understand what the usage cases are. Would these links
> be typed in by hand by a user? If so, we would want the ids to have a
> human readable form. If they are always generated by code they could
> be ugly.
>> The other thing we have to keep in mind is that we can't ever couple
> the kernel to the notebook frontend. That is, the kernel can't ever
> know about these cell ids in any formal way.
>> > 3. I'd love to have a consistent interface to stream something like
> stdout
> > character-wise instead of line-wise. Right now it's hacked to hook stdout
> > directly on the console, and with even more horrible jQuery machinations
> on
> > the notebook side.
>> Can't you call flush to do this? Can you describe this a bit more.
> Again, not following how all of this is used. It sounds messy...
>> Cheers,
>> Brian
>> > Thanks!
> >
> >
> >> Cheers,
> >>
> >> Brian
> >>
> >> On Tue, Nov 27, 2012 at 11:49 AM, Taavi Burns <taavi.burns@gmail.com>
> >> wrote:
> >> > https://github.com/taavi/ipython_nose> >> >
> >> > I've gotten the %nose magic Greg Ward and I worked on at the PyCon
> >> > Canada
> >> > sprints to a reasonable point. I'm not yet convinced that it's ready
> for
> >> > integration into IPython (I think I'd like to get IPython to add id
> >> > attributes on the cells so I don't have to add them myself with JS),
> but
> >> > it
> >> > should be good enough for some real-world testing.
> >> >
> >> > It's pip-installable in development mode:
> >> > . YOUR/VIRTUALENV/activate
> >> > git clone https://github.com/taavi/ipython_nose.git> >> > cd ipython_nose
> >> > pip install -e .
> >> >
> >> > I might not bother putting it on PyPI if it's as likely to get
> included
> >> > in
> >> > the base IPython as Fernando was suggesting. ;)
> >> >
> >> > I'd appreciate any feedback on features and bugs. Feel free to lodge
> >> > them in
> >> > the github tracker. Pull requests are also welcome! Please keep in
> mind
> >> > that
> >> > the end goal is to integrate it into IPython proper, so some work
> might
> >> > be
> >> > deferred until then.
> >> >
> >> > Thanks!
> >> >
> >> > --
> >> > taa
> >> > /*eof*/
> >> >
> >> > _______________________________________________
> >> > IPython-dev mailing list
> >> > IPython-dev@scipy.org> >> > http://mail.scipy.org/mailman/listinfo/ipython-dev> >> >
> >>
> >>
> >>
> >> --
> >> Brian E. Granger
> >> Cal Poly State University, San Luis Obispo
> >> bgranger@calpoly.edu and ellisonbg@gmail.com> >> _______________________________________________
> >> IPython-dev mailing list
> >> IPython-dev@scipy.org> >> http://mail.scipy.org/mailman/listinfo/ipython-dev> >
> >
> >
> >
> > --
> > taa
> > /*eof*/
> >
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev@scipy.org> > http://mail.scipy.org/mailman/listinfo/ipython-dev> >
>>>> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
>bgranger@calpoly.edu and ellisonbg@gmail.com> _______________________________________________
> IPython-dev mailing list
>IPython-dev@scipy.org>http://mail.scipy.org/mailman/listinfo/ipython-dev>-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/ipython-dev/attachments/20121207/d2f14a1a/attachment.html