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

Omar Andrés Zapata Mesa andresete.chaos@gmail....
Tue Dec 7 16:06:21 CST 2010


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.

Thanks!!



2010/12/7 Brian Granger <ellisonbg@gmail.com>

>
>
> On Tue, Dec 7, 2010 at 1:23 PM, MinRK <benjaminrk@gmail.com> wrote:
>
>>
>>
>> On Tue, Dec 7, 2010 at 13:05, Brian Granger <ellisonbg@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@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@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@calpoly.edu
>>> ellisonbg@gmail.com
>>>
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev@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@calpoly.edu
> 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/20101207/516c2d14/attachment.html 


More information about the IPython-dev mailing list