 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <40577b4f@news.povray.org> , Warp <war### [at] tag povrayorg> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <4058b9d2$1@news.povray.org> , "StephenS" <ssh### [at] ottawanet>
wrote:
> Currently both the new line (\n) and the carriage return (\r) give the same
> result.
Yes, this is correct. \r only makes sense on a terminal, not anywhere else.
In particular it never made sense to use \r when writing output to file.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
...
> Yes, this is correct. \r only makes sense on a terminal, not anywhere
else.
> In particular it never made sense to use \r when writing output to file.
Will the handling of \b (backspace) be changed?
#debug "test1\b"
#debug "test2\n"
In 3.6b2 I get 'test1(outlined square)test2' in the text file and
'testtest2' on the console. 'Outlined square' usually means a non printable
character.
Since the '1' can never be seen on the console, does the \b still have any
use?
WinPov3.6b2
Win98 512mb Duron 1gHz
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
> > Currently both the new line (\n) and the carriage return (\r) give the same
> > result.
> Yes, this is correct. \r only makes sense on a terminal, not anywhere else.
> In particular it never made sense to use \r when writing output to file.
The messages window in WinPOV can be considered a "terminal", so it should
work as expected there (if it doesn't (I haven't tested), I think it should
be fixed). The raytracer made with SDL uses \r to print progress information
in a single line and it would certainly look bad if each update would be
printed in a new line...
And by the way, I'm liking the idea of lines printed with #debug having
a different color than the other lines in the messages window (and in the
output of the unix version if the output is an ANSI terminal). Any chance
this could be done?
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> And by the way, I'm liking the idea of lines printed with #debug having
> a different color than the other lines in the messages window (and in the
> output of the unix version if the output is an ANSI terminal). Any chance
> this could be done?
IIRC, didn't the MS-DOS version of POV-Ray output the different streams
to different "windows"? (And each window was a different colour too.)
Not sure if you'd want seperate windows, colour coding, or an option to
choose either or both... (I suspect colour coding might be the best bet.)
Andrew @ work.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
