libvisual-devel

[Libvisual-devel] Printing to stdout, no no no

[salsaman <sal...@xs...>]

Hi all,
in my testing of libvisual, which is almost complete now, I did:

lives-exe 2>/dev/null

this should produce no output because stdout is used in LiVES for output 
streaming. Instead I saw this, e.g. for gforce:

libvisual INFO: no progname: New Delta field: Acid_Gap
libvisual INFO: no progname: New wave shape: 3D_Cylinder
libvisual INFO: no progname: Looking up expression in dict: MAG
libvisual INFO: no progname: New Particle: Warp_Me_Away
New Delta field: Accident
libvisual INFO: no progname: New wave shape: Zoomed_Square
libvisual INFO: no progname: Looking up expression in dict: MAG
libvisual INFO: no progname: New Delta field: The_Spectrologist_s_Assistant
New Delta field: Yes
New Delta field: 6_Feet_Under

I am guessing the "New Delta Field" is temporary debug info.


Other output which needs removing:

goom2:

NEW RESIZE: 480 360 0x839dcf8


Jackdaw:

Computing table number 1
Computing table number 2
Computing table number 3
Computing table number 4


Oinksie (!)
[OINKSIE] we've got a requisition hit YEAH BABY YEAH
[OINKSIE] event handler is being called
[OINKSIE] we've got a dimension hit YEAH BABY YEAH



This output needs to be removed or sent instead to stderr.

Regards,
Salsaman.

Re: [Libvisual-devel] Printing to stdout, no no no

[salsaman <sal...@xs...>]

salsaman wrote:
...

Further to my last message, I have put in libvis:

close (1);

so in future if you want to see any output at all from libvisual in 
LiVES, it will *have to* go to stderr.


Salsaman.

Re: [Libvisual-devel] Printing to stdout, no no no

[salsaman <sal...@xs...>]

salsaman wrote:

> salsaman wrote:
> ...
>
> Further to my last message, I have put in libvis:
>
> close (1);
>
> so in future if you want to see any output at all from libvisual in 
> LiVES, it will *have to* go to stderr.
>
>
> Salsaman.


OK, can't do that...it stops output from LiVES. I'm afraid I can't 
release the libvisual plugin until all output to stdout is removed.

Salsaman.

Re: [Libvisual-devel] Printing to stdout, no no no

[Dennis S. <sy...@yo...>]

On Fri, 2004-10-01 at 19:48 +0100, salsaman wrote:
> salsaman wrote:
> ...
> 
> Further to my last message, I have put in libvis:
> 
> close (1);
> 
> so in future if you want to see any output at all from libvisual in 
> LiVES, it will *have to* go to stderr.

We're about to add an API to control message verboseness.

Thanks,
Dennis

Re: [Libvisual-devel] Printing to stdout, no no no

[salsaman <sal...@xs...>]

Dennis Smit wrote:

>
>>so in future if you want to see any output at all from libvisual in 
>>LiVES, it will *have to* go to stderr.
>>    
>>
>
>We're about to add an API to control message verboseness.
>
>Thanks,
>Dennis
>
>
>  
>
Perfect !

Salsaman.

Re: [Libvisual-devel] Printing to stdout, no no no

[Dennis S. <sy...@yo...>]

On Fri, 2004-10-01 at 19:44 +0100, salsaman wrote:
> This output needs to be removed or sent instead to stderr.
> 
> Regards,
> Salsaman.

All has been removed from CVS, and libvisual-INFO output will be
controlable through API.

Dennis

Re: [Libvisual-devel] Printing to stdout, no no no

[Duilio J. P. <dp...@fc...>]

> On Fri, 2004-10-01 at 19:44 +0100, salsaman wrote:
> > This output needs to be removed or sent instead to stderr.
> > 
> > Regards,
> > Salsaman.
> 
> All has been removed from CVS, and libvisual-INFO output will be
> controlable through API.
> 
> Dennis

I think the best way to do that is to add an API function which
let the user to set a handler for outputting messages, which 
overrides the default behavior, like glib does. In glib you 
have i.e g_message() with a default behavior, but you can override
it calling g_set_message_handler() with a function that receives the
message string and returns nothing.

This approach is very powerfull because you can process and redirect
output whatever you like. Specially on GUI applications, you can 
redirect messages to some GUI widget.


Bye,
Duilio.

Re: [Libvisual-devel] Printing to stdout, no no no

[Dennis S. <sy...@yo...>]

On Fri, 2004-10-01 at 20:51 -0300, Duilio Javier Protti wrote:
> I think the best way to do that is to add an API function which
> let the user to set a handler for outputting messages, which 
> overrides the default behavior, like glib does. In glib you 
> have i.e g_message() with a default behavior, but you can override
> it calling g_set_message_handler() with a function that receives the
> message string and returns nothing.
> 
> This approach is very powerfull because you can process and redirect
> output whatever you like. Specially on GUI applications, you can 
> redirect messages to some GUI widget.

That sounds really good, doing this together with verboseness level API
I assume ?

Cheers,
Dennis