[Bf-committers] Blender Logging

[Jason Wilkins]

I would replace the functions that output to stdout/stderr, not
redirect the files.  If something was difficult get at, like a library
or some part of Python, then I'd probably just let it continue to
output where it wants.

If I was really clever I could scoop up all the remaining output and
sent it to a single particular log, but that is probably not really
needed.  I'm more interested in being able to create debug logs for
various different modules in Blender but be able to easily keep them
separate or to be able to do things like remotely monitor Blender,
such as debugging Blender on a portable device like a tablet.  For
that reason there is probably not much need to make sure that
*everything* outputs to a log.  Just new stuff and things we have
control over.



On Wed, Oct 17, 2012 at 10:11 AM, Mitchell Stokes <mogurijin at gmail.com> wrote:
> You might run into some issues with the embedded Python. I've noticed
> that embedded Python doesn't always play nice with a redirected
> stdout.
>
> --Mitchell Stokes
>
> On Wed, Oct 17, 2012 at 7:39 AM, Jason Wilkins
> <jason.a.wilkins at gmail.com> wrote:
>> I wasn't going to choose one particular logging library.  I was going
>> to create a very simple wrapper that you could plug any back-end into
>> easily.  Using glog is just one of those, and one reason for prompting
>> this discussion is so I can see if anybody has any opinion on which
>> one to target as the default.
>>
>> It isn't a huge project, replace half a dozen standard library
>> functions and add a couple of parameters for message type and source.
>>
>> It is just a tedious little project that is not very sexy :)
>>
>> On Wed, Oct 17, 2012 at 2:06 AM, Sergey Sharybin <sergey.vfx at gmail.com> wrote:
>>> I'm currently not so much convinced it'll indeed worth spending time on
>>> this now. If you really want to look into this would suggest looking into
>>> writting C wrapper for glog (C++ stuff could use glog directly). This
>>> library is already heavily used in some areas, supports lots of features
>>> and having another logger seems quite stupid for me.
>>>
>>> On Wed, Oct 17, 2012 at 6:52 AM, Alex Fraser <alex at phatcore.com> wrote:
>>>
>>>> On 17 October 2012 08:09, Jason Wilkins <jason.a.wilkins at gmail.com> wrote:
>>>> > Rather than keep this on the back burner I figured I'd put this out
>>>> > there for people to give some feedback.  I was thinking of replacing
>>>> > all direct use of the standard file handles (stdin, stderr) in Blender
>>>> > with a single set of logging functions.  This function could intercept
>>>> > all messages and conditionally send them anywhere you wanted.  In
>>>> > particular I was thinking you could use one of the popular open source
>>>> > logging libraries as a backend (log4cxx for example).  So nobody would
>>>> > need to implement a backend to send results over the network, that has
>>>> > already been done.
>>>>
>>>> +1. I don't know what this would be like to implement in Blender, but
>>>> all the projects that I've converted to use logging have since been
>>>> much nicer to develop.
>>>>
>>>> Alex
>>>> _______________________________________________
>>>> Bf-committers mailing list
>>>> Bf-committers at blender.org
>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>>
>>>
>>>
>>>
>>> --
>>> With best regards, Sergey Sharybin
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers