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

[MinRK]

2010/12/7 Omar Andrés Zapata Mesa <andresete.chaos at gmail.com>

> 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).


>
> 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
>>
>>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20101207/469374fd/attachment.html>