Re: [bugle-users] no trace output: ubuntu 10.04 + ati 8.723

[Bob K. <bob...@gm...>]

hi bruce,

i'll investigate later when i have a chance, but for now, since
stdout, stderr work as valid streams, i'll work that way.

to summarize:

 * core initial problem was setup-related:
    * very important to have proper ~/.bugle/ configs:
    % mkdir ~./bugle; cp doc/examples/ ~/.bugle/
 * setting logging levels high to force all output didn't help.
    * in a chain in a 'filterset log {...}' set:
          file_level = 5
          stderr_level = 5, or stdout_level = 5
     * saw output from stdout or stderr, nothing in the file

thanks for all the advice and help. i'll let you know if i find out more.
bob

On Sun, Aug 15, 2010 at 3:45 PM, Bruce Merry <bm...@gm...> wrote:
> (cc'ing bugle-users back in - I forgot to reply-all at one point)
>
> On 13 August 2010 22:50, Bob Kuehne <bob...@gm...> wrote:
>> hi bruce,
>>
>> ok, so if i step through there, i see that i'm bailing in
>> bugle_log_printf where the !f || severity check happens (about line
>> 170 - i've edited, can't tell you exactly).
>>
>> so it looks like getting the file is failing, but the why isn't clear.
>
> I'm afraid your guess is as good as mine at this point. If it had
> failed to create the file I'd assume it was just some kind of
> permission problem, but creating it and failing to log is weird. The
> only thing I can think of that would cause that is a full disk. Good
> luck and let me know if you learn anything.
>
> Bruce
>
>> the pointers all look fine, the severity test passes, but i'm not sure
>> what's going on. log_next is a little opaque.
>>
>> ideas?
>> bob
>>
>> On Fri, Aug 13, 2010 at 4:55 PM, Bruce Merry <bm...@gm...> wrote:
>>> On 13 August 2010 21:45, Bob Kuehne <bob...@gm...> wrote:
>>>> hi bruce,
>>>>
>>>> On Fri, Aug 13, 2010 at 4:14 PM, Bruce Merry <bm...@gm...> wrote:
>>>>> On 13 August 2010 20:36, Bob Kuehne <bob...@gm...> wrote:
>>>>>> hi bruce,
>>>>>>
>>>>>> On Fri, Aug 13, 2010 at 3:23 PM, Bruce Merry <bm...@gm...> wrote:
>>>>>>
>>>>>>> That sounds like either the mechanism to intercept all calls is
>>>>>>> failing, or file logging is failing. Perhaps try adding the following
>>>>>>> inside the "filterset log { ... }" section:
>>>>>>>
>>>>>>> file_level 5
>>>>>>> stderr_level 5
>>>>>>
>>>>>> so if i do this, and update ~/.bugle/statistics per your suggestion below,
>>>>>> i get output (to the console).
>>>>>
>>>>> Do you get any output in the file when you do this? If so it might
>>>>> just mean that the default logging level is wrong for some reason (it
>>>>> should default to 4 for the file, which should be high enough to get
>>>>> trace output).
>>>>
>>>> wrt output in the log file, sometimes. so, if i use the 'logfps'
>>>> chain, with your mods:
>>>>
>>>> --
>>>> chain logfps
>>>> {
>>>>    filterset stats_basic
>>>>    filterset logstats
>>>>    {
>>>>        show "frames per second"
>>>>    }
>>>>    filterset log
>>>>    {
>>>>        file_level 5
>>>>        stderr_level 5
>>>>        filename "bugle.log"
>>>>    }
>>>> }
>>>> --
>>>>
>>>> i see a lot on the console (stderr), but zip in the file, though i
>>>> clearly see it had touched 'bugle.log' when i ran, but again, 0bytes
>>>> in it. tried a few things, but it does seem to be a problem with
>>>> actually putting content in the log.
>>>
>>> As you say, that sounds like a problem with the logger. You might
>>> learn more by sticking breakpoints on bugle_log and bugle_log_printf.
>>> These functions iterate over the possible logging targets, and by
>>> following the flow you might be able to see why it's skipping over the
>>> file target.
>>>
>>> Bruce
>>> --
>>> Dr Bruce Merry
>>> bmerry <@> gmail <.> com
>>> http://www.brucemerry.org.za/
>>> http://blog.brucemerry.org.za/
>>>
>>
>>
>>
>> --
>> bob kuehne
>> ceo - blue newt software
>> www.blue-newt.com    734/834-2696
>>
>
>
>
> --
> Dr Bruce Merry
> bmerry <@> gmail <.> com
> http://www.brucemerry.org.za/
> http://blog.brucemerry.org.za/
>



-- 
bob kuehne
ceo - blue newt software
www.blue-newt.com    734/834-2696