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

[Brian Granger]

Then, should  I use std logging instead iplogging?

> with iplogging we can create objects to startup scripts and appropriate
>> Handlers,
>> ex: in The IPython kernel main entry point, we can parser some arguments
>> to enable o disable
>> iplogging messages and we can create an object that save information into
>> log file.
>>
>
> You can just put the startup lines at the bottom of iplogging inside a
> make_logger() function, then that function can be called from entry_point
> (or put in entry_point).
>

The point is that modules that need to log should just use logging.  The
configuration of everything should be handled in the main startup script and
the code there can definitely use any customizations in iplogging.

Cheers,

Brian



>
>
>>
>> Thanks!!
>>
>>
>>
>> 2010/12/7 Brian Granger <ellisonbg at gmail.com>
>>
>>
>>>
>>> On Tue, Dec 7, 2010 at 1:23 PM, MinRK <benjaminrk at gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Dec 7, 2010 at 13:05, Brian Granger <ellisonbg at gmail.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.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Brian
>>>>>
>>>>
>>>> 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
>>>> logging.Loggers.
>>>>
>>>>
>>> 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.
>>>
>>> Cheers,
>>>
>>> Brian
>>>
>>>
>>>>  -MinRK
>>>>
>>>>
>>>>>
>>>>>
>>>>> 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
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>> _______________________________________________
>>> 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/20101208/9c29662e/attachment.html>