When I render,

#debug "test 1"

test 1 appears (incorrectly) after
 Peak memory used:, and before
 Total Scene Processing Times.

#debug "test 2\n"

test 2 appears (correctly) after
 Clock value, and before
 Cleanup Parse Warning:

WinPov 3.5 did not require the last #debug to be terminated with a newline
(\n)

WinPov 3.6b2
Win98se 512mb Duron 1g Hz

Stephen

Post a reply to this message

In article <405747ac$1@news.povray.org> , "StephenS" <ssh### [at] ottawanet>
wrote:

> WinPov 3.5 did not require the last #debug to be terminated with a newline
> (\n)

POV-Ray 3.6 beta 2 works as expected. A newline is required for a debug
message to be printed instantly.  Otherwise it will be printed at the end of
the render.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> POV-Ray 3.6 beta 2 works as expected. A newline is required for a debug
> message to be printed instantly.  Otherwise it will be printed at the end of
> the render.

  I'm seeing a need for a #flush command here... ;)

  Usually if people are printing something with #debug, they want it
printed immediately. As the name depicts, you use it for debugging
purposes, not something which requires maximum speed. For debugging
purposes it may be important to see the printout immediately.
  I think that the output should be flushed after each #debug. I can't
think of any useful reason why it wouldn't.

  I also wonder if it would be a good idea to have a separate window
for the #debug stream (at least in the Windows version). Printing #debug
text in the messages window makes it hard to spot what was printed among
all the other text. This could be a selectable option.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

> I also wonder if it would be a good idea to have a separate window
> for the #debug stream (at least in the Windows version). Printing #debug
> text in the messages window makes it hard to spot what was printed among
> all the other text. This could be a selectable option.

Another option would be to allow different colors for different text 
streams. That would make them easier to distinguish.

Severi S.

Post a reply to this message

In article <40577b4f@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   Usually if people are printing something with #debug, they want it
> printed immediately. As the name depicts, you use it for debugging
> purposes, not something which requires maximum speed. For debugging
> purposes it may be important to see the printout immediately.
>   I think that the output should be flushed after each #debug. I can't
> think of any useful reason why it wouldn't.

You see the output immediately after a line is complete (or you return the
the beginning of the line).  There is no way to generate consistent and
non-mangled output if every stream goes to the same output device (which
happens more often that not).

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Severi Salminen <sev### [at] not_thissibafi> wrote:
> Another option would be to allow different colors for different text 
> streams. That would make them easier to distinguish.

  This is a good idea because it would also work when using POV-Ray
from an ANSI terminal.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

>   This is a good idea because it would also work when using POV-Ray
> from an ANSI terminal.

	What about portability here ?

	- NC

Post a reply to this message

Nicolas Calimet <pov### [at] freefr> wrote:
> >   This is a good idea because it would also work when using POV-Ray
> > from an ANSI terminal.

>         What about portability here ?

  We are talking about platform-specific code anyways. Each platform-specific
build either implements their own coloring system or just use the generic
default.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

Nicolas Calimet wrote:

>>   This is a good idea because it would also work when using POV-Ray
>> from an ANSI terminal.
> 
> 
>     What about portability here ?

I don't know how streams are now implemented but if the GUI is allways 
told what stream is sending text then it is up to GUI to decide what to 
do about it: to give them different colours or not. And GUIs are 
platform specific anyway so there should be no portability problem here.

Severi

Post a reply to this message

...
> You see the output immediately after a line is complete (or you return the
> the beginning of the line).
...
Currently both the new line (\n) and the carriage return (\r) give the same
result.

#debug "test1\n"
#debug "test2\n"

Same result as
#debug "test1\r"
#debug "test2\n"

In WinPov 3.5 the second example would output 'test1' and then overwrite the
same line with 'test2'.
The carriage return (\r) was useful for updating the user during a long
process (mesh building).

WinPov 3.6b2
Win98se 512mb Duron 1gHz

Stephen

Post a reply to this message