[IPython-dev] Quieting the kernel, logging strategy.
Tue Dec 7 15:27:16 CST 2010
On Tue, Dec 7, 2010 at 1:23 PM, MinRK <firstname.lastname@example.org> wrote:
> On Tue, Dec 7, 2010 at 13:05, Brian Granger <email@example.com> wrote:
>> 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.
> This is exactly what the parallel code currently does. Any use/knowledge
> of logging over zmq or to a file
> is handled purely by the startup scripts in creating/attaching appropriate
> Handler objects.
Great, this is the model that we talked about at SciPy with Justin Riley and
I think it is a good one.
> Omar's iplogging is not a special logging module, it's just a
> logging.Formatter subclass with coloring, for use with regular
Yes, but all the configuration of the Formatters and Handlers can be done in
the main startup script so that most modules only need to import logging,
rather than iplogging.
>> On Mon, Dec 6, 2010 at 2:59 PM, Fernando Perez <firstname.lastname@example.org>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...
>>> IPython-dev mailing list
>> Brian E. Granger, Ph.D.
>> Assistant Professor of Physics
>> Cal Poly State University, San Luis Obispo
>> IPython-dev mailing list
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the IPython-dev