[IPython-dev] Quieting the kernel, logging strategy.

[Brian Granger]

A few quick comments:

* The configuration of logging for each process should be done at the
Application level, not in a ipython specific logging module.  When I get to
creating a full blown Application for the new kernel, etc., we can put all
of this together.  We may want an IPython Logger Configurable that holds the
state and config for the Application.  Subclasses could log to different
resources (file, zeromq socket, etc).
* Files that need to use logging should just import the standard logging
module and start logging.
* For now, if the goal is to move forward with the 2 process terminal based
IPython, I would:

1) Convert the kernel to use the logging module of the std library.
2) Make the kernel log to a file in the ipython directory.  For now this can
just be done in the top level kernel script.

Cheers,

Brian

On Mon, Dec 6, 2010 at 2:59 PM, Fernando Perez <fperez.net at gmail.com> wrote:

> Hi folks,
>
> I just had a chat with Omar, who has some spare cycles coming up and
> is going to complete the work he prototyped during the gsoc effort.
> This will mean producing a terminal-based, 2-process version of
> IPython, which can be used for talking to existing kernels or with its
> own self-started one.
>
> Unfortunately right now the self-starting approach simply won't work,
> because we've crammed the kernel full of direct print statements to
> log message info.  This makes it impossible to use the terminal where
> the kernel is running, as it floods with messages.
>
> I suggested to Omar that he start, as step 1 of his work, with
> quieting out the kernel, but I'd like to ping everyone with this so
> that Omar can implement something that will last.  I remember in Min's
> newparallel branch we already have a proper log listener, and we'd
> talked in the past about this a little, but my memory fails me.
>
> So, should all print statements be replaced with calls to a
> logging.logger object for now?  Min, how was your code logging its
> messages out?
>
> This isn't particularly difficult work, I just want to make sure we
> use the same strategy everywhere, and right now I don't have all the
> pieces of the puzzle in my mental cache...
>
> Thanks!
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20101207/3f152779/attachment.html>