headers
Tim Michelsen | 1 Feb 01:08
Picon

Re: matplotlib, ipython and ubuntu

Hello Fernando,

>> <type 'exceptions.AttributeError'>: 'module' object has no attribute
>> 'ArrayType'
>>
>> maybe some of the IPython power users can give me a hint why this
>> happes. [1]
> 
> Very strange.  I can't reproduce it here (on gutsy, but running
> ipython from my own tree). What's odd is this:
> 
> In [1]: import Numeric
> 
> In [2]: print Numeric.ArrayType
> <type 'array'>
> 
> 
> So Numeric *most definitely* has an ArrayType member. Try doing the
> same as I did, also showing us whether you started ipython with -pylab
> or not.  There may be something odd about your Numeric installation.
> Also do this:
> 
> In [3]: Numeric?
> Type:           module
> Base Class:     <type 'module'>
> Namespace:      Interactive
> File:           /usr/lib/python2.5/site-packages/Numeric/Numeric.py
> 
> [etc]
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Fernando Perez | 1 Feb 08:23
Picon
Gravatar

IPython -pylab/-Xthread improvements in SVN - testers?

Hi all,

sorry for the quick cross-post, but I know that many mpl users rely on
the ipython -pylab support for interactive work.

This is a call for testing from current SVN of anyone who uses ipython
with the GUI thread support, whether via -pylab or directly via one of
the -Xthread options.

For a long time I've known that this code was subject to possible
deadlocks, having seen it go nuts on me on occasion, but I'd never
been able to track down the exact source of the race conditions
causing it (I'm not an expert in threads at all).  In

http://ipython.scipy.org/ipython/ipython/ticket/210
http://ipython.scipy.org/ipython/ipython/ticket/212

a very helpful analysis and solution code was provided by Marc.  I've
applied his fixes to current SVN, and with my testing so far I've been
unable to get any more deadlocks or crashes, so this looks great, and
his analysis looks very sound to me.  In particular, it makes proper
use of a re-entrant lock which I'd originally tried to use but given
up on, due to having used it incorrectly (though I knew it should be
the right tool).  I'd just left a comment noting the issue, which
Marc's fixes now address.

It would be great if any of you who relies on the GUI thread support
could test this, since this threaded code is subtle and has a long
history of hard to trigger but annoying bugs.  You can run it from
SVN.  In a few minutes I'll finish uploading test builds as well to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Fernando Perez | 1 Feb 19:05
Picon
Gravatar

Fwd: ipython question

Hi Lionel,

I'm going to bounce this to the list: I'm running very tight on time
and it's going to get worse for a few weeks, so I'm afraid I won't be
able to comment now.

Cheers,

f

---------- Forwarded message ----------
From: Lionel Roubeyrie <lroubeyrie <at> limair.asso.fr>
Date: Feb 1, 2008 1:48 AM
Subject: Re: ipython question
To: Fernando Perez <fperez.net <at> gmail.com>

Expecting I didn't do mistakes, here is the last version on the wiki:
http://ipython.scipy.org/moin/Cookbook/SavingCurrentSession

I just have a little problem with this code, if we import the last saved
session at startup and in the saved code we have references to implicits
pylab functions (ipython started last time with ipython -pylab), then the
logger complains about errors on these references, even if I call %run
with -i.
An idea?

Le jeudi 31 janvier 2008, vous avez écrit :

> On Jan 31, 2008 3:18 AM, Lionel Roubeyrie <lroubeyrie <at> limair.asso.fr> wrote:
> > Hi Fernando,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian Granger | 1 Feb 22:38
Picon

Re: Development plans update

Hello all,

I picked a bad week to be away from email....

It is great to see that so many people are excited about pushing
ipython to the next level.  I have a number of comments about various
aspects of this:

Fernando:
> - We'll try to keep compatibility with existing APIs (like ipapi)
> where feasible, but there are no promises.  We'll break backwards
> compatibility wherever we need to in order to do the right thing.

I think this needs to be clarified.  The current ipython1 (purposely)
makes no attemps to be API compatible with the ipython trunk.  In
fact, I would say that in most cases it is _extremely_ different that
what is in ipython.  The reason for this is that the abstractions
needed in ipython1 are _extremely_ different that those in ipython
trunk.  Thus, the APIs are also very different.

Walter:
> Porting ipipe/ibrowse to ipython1 would be simple, once we have a
> display hook extension mechanism. Except for the hook that invokes the
> display object, there are no other dependencies.

I don't know much about ipipe, but in IPython1 there is no such thing
as a display hook - and there won't ever be - not in the same sense
that there is in ipython trunk.  I think we will be able to implement
ipipe in ipython1, but the implementation will look completely
different.  In particular, in ipython1, things are divided between the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ville M. Vainio | 1 Feb 23:00
Picon
Gravatar

Re: [IPython-dev] Development plans update

On Feb 1, 2008 11:38 PM, Brian Granger <ellisonbg.net <at> gmail.com> wrote:

> I think to say that with ipython1 "it is a priority to retain API
> compatibility with the trunk" is a misinterpretation of Fernando's
> earlier statement.  Many things in the ipython trunk API are by
> definition impossible to carry over the ipython1 because the
> assumptions and abstractions are so different.  Of course, where we
> can we will try to maintain API compatibility, but I think those cases
> will be few and far between.

Why are they so different?

trunk/ is like the core, and a frontend will just manage the read /
display functionality.

If we just change all the printing to be some "write" function that
can dump stuff to frontend, and raw_input to get stuff from front end,
what else is different?

--

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'
Permalink | Reply | 0 comments |
headers
Brian Granger | 2 Feb 00:04
Picon

Re: [IPython-dev] Development plans update

> > I think to say that with ipython1 "it is a priority to retain API
> > compatibility with the trunk" is a misinterpretation of Fernando's
> > earlier statement.  Many things in the ipython trunk API are by
> > definition impossible to carry over the ipython1 because the
> > assumptions and abstractions are so different.  Of course, where we
> > can we will try to maintain API compatibility, but I think those cases
> > will be few and far between.
>
> Why are they so different?

Good question

One of the core assumptions in ipython trunk is that the frontend
(stdout/stdin/terminal/readline/etc) has full immediate and complete
access to things living in the users namespace.  A few examples:

1.  Tab complettion.  Readline detects a tab and calls the tab
completion machinery which directly looks at things in the users
namespace.

2.  Prompt display.  IPython prompts can include info from the users namespace.

3.  Traceback printing.  Tracebacks are formatted (ACSII coloring,
etc) by ipython at the moment the exception is raised, when the full
state of the interpreter is available to look at.

This is the main assumption that gets broken in ipython1.  In
ipython1, the frontend has no direct access to anything in the user's
namespace.  Instead the frontend only has access to a standardized API
(methods, not attributes).  A perfect example is Tab completion.  Here
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ville M. Vainio | 2 Feb 09:33
Picon
Gravatar

Re: [IPython-dev] Development plans update

On Feb 2, 2008 1:04 AM, Brian Granger <ellisonbg.net <at> gmail.com> wrote:

> 2.  Prompt display.  IPython prompts can include info from the users namespace.

I think the prompt calculation should be done in the back-end. Isn't
it trivial for the frontend to ask for the prompt string from the back
end (even if it doesn't happen by merely writing out the characters)?

> 3.  Traceback printing.  Tracebacks are formatted (ACSII coloring,
> etc) by ipython at the moment the exception is raised, when the full
> state of the interpreter is available to look at.

Why can't the back end just render the exception string, and let the
display be handled by front end? We can change the color escape
sequences to something more "universal", if need be (<red>foo</red>,
<highlight>NOTE</highlight>, whatever).

> whatever way is best.  While this doesn't look too bad there is a lot
> of subtlety going on underneath the hood.  For example, the complete
> method could actually trigger a network call to ipython core/engine
> running on a remote system.  At the time the complete call gets made,
> the engine could be executing some blocking C code the user had
> started in a previous line.  In this case, the tab completion can't
> happen until that C code finishes (threads won't help).  So, then, in
> a case like that, the complete method will need to raise an exception
> to reflect the fact that TAB completion can't happen right now.

If we have the part that communicates with the front end in a separate
thread, this won't be a problem. Completion can ALWAYS happen. This is
probably easy stuff, apart from ctrl+c handling.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian Granger | 2 Feb 23:59
Picon

Re: [IPython-dev] Development plans update

> > 2.  Prompt display.  IPython prompts can include info from the users namespace.
>
> I think the prompt calculation should be done in the back-end. Isn't
> it trivial for the frontend to ask for the prompt string from the back
> end (even if it doesn't happen by merely writing out the characters)?

This is sort of possible.  We could have a method in the api called
something like get_next_prompt.  But, in practice, this won't work
well.  The reason is that the backend could be busy at the moment you
want a prompt.  And threads won't help this in any way.  I probably
need to explain a bit more about how the core works for this to make
sense.  Anytime you make a call to the core the call _may_ be put into
a queue if the core is busy.  This is a standard FIFO queue.  The
reason this happens is to enable a user to continue working on new
input lines while the old ones compute.  If you are familiar with
Mathematica, you can edit and submit new input cells while old ones
work.  But, when the queue is active, everything goes through the
queue - tab completion, prompt stuff. etc.  This is done to make sure
the entire thing is deterministic.

Now there will be times where the queue is not active, but our API
needs to be designed for the general case where a queue may be
present.

There is also another complication with prompts.  The architecture
already supports multiple users connecting to the same ipython
engine/core process.  All of the users frontends will have access to
the current prompt number, but, you can imagine that the frontend has
to in this case make decisions about what the prompts look like - the
core simply can't as is knows nothing about how many user are
(Continue reading)

Permalink | Reply | 0 comments |
headers
wang frank | 3 Feb 04:49
Picon

Re: [IPython-dev] Development plans update

How about a way to copy a group of data into ipython similar like copy the code now? It is important since sometimes, we want to copy a group of data from other application and assign it to a python variable.
 
Thanks
 
Frank

> Date: Sat, 2 Feb 2008 10:33:55 +0200
> From: vivainio <at> gmail.com
> To: ellisonbg.net <at> gmail.com
> CC: ipython-user <at> scipy.org; fperez.net <at> gmail.com; ipython-dev <at> scipy.org
> Subject: Re: [IPython-user] [IPython-dev] Development plans update
>
> On Feb 2, 2008 1:04 AM, Brian Granger <ellisonbg.net <at> gmail.com> wrote:
>
> > 2. Prompt display. IPython prompts can include info from the users namespace.
>
> I think the prompt calculation should be done in the back-end. Isn't
> it trivial for the frontend to ask for the prompt string from the back
> end (even if it doesn't happen by merely writing out the characters)?
>
> > 3. Traceback printing. Tracebacks are formatted (ACSII colorin g,
> > etc) by ipython at the moment the exception is raised, when the full
> > state of the interpreter is available to look at.
>
> Why can't the back end ju st render the exception string, and let the
> display be handled by front end? We can change the color escape
> sequences to something more "universal", if need be (<red>foo</red>,
> <highlight>NOTE</highlight>, whatever).
>
> > whatever way is best. While this doesn't look too bad there is a lot
> > of subtlety going on underneath the hood. For example, the complete
> > method could actually trigger a network call to ipython core/engine
> > running on a remote system. At the time the complete call gets made,
> > the engine could be executing some blocking C code the user had
> > started in a previous line. In this case, the tab completion can't
> > happen until that C code fini shes (threads won't help). So, then, in
> > a case like that, the complete method will need to raise an exception
> > to reflect the fact that TAB completion can't happen r ight now.
>
> If we have the part that communicates with the front end in a separate
> thread, this won't be a problem. Completion can ALWAYS happen. This is
> probably easy stuff, apart from ctrl+c handling.
>
> > Prompts. If a frontend wants a prompt to include information from an
> > object in the users namespace, the frontend will have to get the
> > object (over the network possibly) each time it wants to update the
> > information:
> >
> > a = interpreter.pull('a')
> >
> > This gets the object named 'a' from the users namespace. Again, this
> > can potentially be a non-local (network) call, that is not completed
> > immediately.
>
> If we ask for the whole prompt from the back end, we know when it will
> be fully ready. Here, the complications are in the front end.
>
> > Displaying things. The core of ipython1 will not be able to make any
> > decisions about how things (stdout, tracebacks, etc) are formatted.
> > This is because a single instance of the core could be simultaneously
> > connected to frontends that need things formatted in completely
> > different ways. You could have a Javascript frontend, a terminal
> > based frontend and a Qt app all talking to the same instance of the
> > core. Because of this, the core will need to return output in a
> > "unformatted format." (xml, python dict, etc) that can transformed by
> > the frontends into whatever form they need.
>
> Yeah, this is what I referred to earlier. Changing what the back end
> blurts out to xml should be pretty easy, and a trivial front en d
> implementation (a readline one) can just do string replace to convert
> it to the current ansi codes.
>
> > to varous methods of the interpreter. This is what I mean that the
> > "core" won't know anything about display hooks. They will still
> > exist, but look very different.
>
> I think the display hooks should still be in core, but return strings
> instead of direct printing.
>
> > Does this help give a better idea about why the APIs will look so different?
>
> Yes. Meetings these expectations seems like a pretty fun project, though :-)
>
> --
> Ville M. Vainio - vivainio.googlepages.com
> blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'
> _______________________________________________
> IPython-user mailing list
> IPython-user <at> scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-user


「初音ミク」の妹分「鏡音リン」をLive Search で画像検索！ http://search.live.com/images/re sults.aspx?q=%E9%8F%A1%E9%9F%B3%E3%83%AA%E3%83%B3&FORM=MGDEAA 
_______________________________________________
IPython-user mailing list
IPython-user <at> scipy.org
http://lists.ipython.scipy.org/mailman/listinfo/ipython-user
Permalink | Reply | 0 comments |
headers
Ville M. Vainio | 3 Feb 23:03
Picon
Gravatar

Re: [IPython-dev] Development plans update

Very busy now, but few points.

> sense.  Anytime you make a call to the core the call _may_ be put into
> a queue if the core is busy.  This is a standard FIFO queue.  The
> reason this happens is to enable a user to continue working on new
> input lines while the old ones compute.  If you are familiar with

I'm not sure this should be the default behaviour. I like my stuff
synchronous, most of the time. I think there should be the synchronous
mode (where there are no problems with tab completion), and async mode
(where the delays with tab completion can occur on problematic
non-GIL-releasing code).

> Mathematica, you can edit and submit new input cells while old ones
> work.  But, when the queue is active, everything goes through the
> queue - tab completion, prompt stuff. etc.  This is done to make sure
> the entire thing is deterministic.

Tab completion does not need to be deterministic IMO. It's a very
"interactive" thing, and you can press tab a couple of times while you
wait for the completion to be "ready". Or the frontend can retry the
completion when it knows the queue is empty. But I still think the
completions should be served immediately in a thread.

> There is also another complication with prompts.  The architecture
> already supports multiple users connecting to the same ipython
> engine/core process.  All of the users frontends will have access to
> the current prompt number, but, you can imagine that the frontend has
> to in this case make decisions about what the prompts look like - the
> core simply can't as is knows nothing about how many user are
> connected.

The frontend can just send the Itpl string to the core which expands
it. Of course a "generate_prompt" like hook would happen in the core,
but if that is what the user wants that's what he will get.

> But, there is another more important reason that tab completion can't
> always happen.  I can give you an example - remember that every
> command that is sent to the core _may_ be put into a queue and
> executed later.
>
> In [1]: run_some_long_calculation()             # the core starts
> working on this and it will take 5 minutes
>
> In [2]: a = Thing()                      # The user gets this prompt
> immediately and enters this command.
>                                                # because the first
> command is still executing, this command is put on the
>                                                # queue.  It will be
> executed when the first one is done - in 5 minutes.
>
> In [3]: a.     <TAB>                   # Again, the user gets this
> prompt immediately.  They want to tab complete
>                                                # on a, but it is truly
> impossible as the command to create a has not been
>                                                # run yet.
>
> As you can see, the other really fundamental change in ipython1 is
> that everything _may_ be completely asynchronous.  This requires a
> huge paradigm shift in terms of thinking.

(see the solution above - retry until the queue is empty).
> > I think the display hooks should still be in core, but return strings
> > instead of direct printing.
>
> Yes, this is more of what it looks like.  Currently when you call the
> method to run code in the core, it gives you back a python dict of
> various things (stdout, stderr, etc.).  The display hooks could
> possible manipulate those dictionaries.  But, it is important to
> remember that multple users (with different display desires) could be
> connected to the same core instance.  Thus, I think that much of the
> display logic will need to be the frontends.

We can't pass "live" complicated objects to the frontend (pickling
wont work), so I think the issue is twofold:

- The display hooks on server output those dicts
(generics.result_display can return those).
- Frontend does whatever it wants with that dict.

--

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'
Permalink | Reply | 0 comments |

Gmane