 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Juha wrote:
> You still have to parse the entire code to see where is the matching
> semicolon.
> There's no way to avoid parsing other than copying the whole source code
> to memory without the static parts of it and then parse this copy.
How about considering #static as an alternative to #include?
There would be two acceptable forms the parser would expect...
#static /filename/
or
#static (/filename/,/start/,/end/)
If the former was encountered, POV would parse the include file
indicated by "filename" once on the first frame rendered, then just
retain it until all frames were completed.
For the latter syntax, it would behave exactly like #include until
frame # "start" was reached, then parse one more time and hold until
either frame # "end" was reached, or all the specified frames were
completed (whichever comes first, depending on the INI file options
selected). If more frames than "end" are rendered, just go back to
considering it identical to saying #include after the last rendered
frame.
This way, if the static section does not need reparsing, POV need
only read a single line to discover this and move on. And of course,
it leaves responsibility for deciding what should be static firmly
on the shoulders of the user, where it belongs.
Charles
--
http://www.enter.net/~cfusner
"...Then darkness took me, and I strayed out of thought and time,
and I wandered far on roads that I will not tell..."
-The Two Towers, JRR Tolkien
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 22 Sep 1999 23:19:52 +0200, Tomas Plachetka wrote:
>OK, back to the business: When my patch is ready,
>whom should I send it to ? To you? Or to
>news://news.povray.org/povray.patches?
>In the later case, is there an official procedure
>about how to post patches to the povray.patches?
>And if so, where could I read it?
>(Forgive my stupid questions, I'm a newbie here.)
You can post it to povray.binaries.programming and post a note
about it in povray.unofficial.patches so we know to look for it
there. That way everyone can enjoy it, even it if takes me the
usual months to get it into the superpatch. :) As for how to
get patches into the official version, I'm not sure there is an
official documented method, but at least one team member will
see it in the unofficial.patches group.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 22 Sep 1999 17:27:23 -0400, Charles wrote:
>Nieminen Juha wrote:
>> You still have to parse the entire code to see where is the matching
>> semicolon.
>> There's no way to avoid parsing other than copying the whole source code
>> to memory without the static parts of it and then parse this copy.
>
>How about considering #static as an alternative to #include?
>There would be two acceptable forms the parser would expect...
>
>#static /filename/
>
>or
>
>#static (/filename/,/start/,/end/)
Or, using the syntax I proposed,
#static (start, end)
#include "filename"
#end
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
>
> On Wed, 22 Sep 1999 17:00:12 +0200, Tomas Plachetka wrote:
> >This is something I didn't know about (that the
> >clock function is always monotone). I thought
> >of it as of a variable which is automatically
> >declared and has a special meaning...
> >Are you sure that the user cannot assign an
> >arbitrary value to clock in the .pov code?!
>
> POV treats it as a scalar function with no arguments. I get an
> error when I try to assign to it.
>
But you can change the clock value and clock delta in an arbitrary manner during
an animation. Just #write the appropriate initial_clock, final_clock,
initial_frame and final_frame options to an ini file.
Margus
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 23 Sep 1999 01:03:51 +0300, Margus Ramst wrote:
>Ron Parker wrote:
>>
>> On Wed, 22 Sep 1999 17:00:12 +0200, Tomas Plachetka wrote:
>> >This is something I didn't know about (that the
>> >clock function is always monotone). I thought
>> >of it as of a variable which is automatically
>> >declared and has a special meaning...
>> >Are you sure that the user cannot assign an
>> >arbitrary value to clock in the .pov code?!
>>
>> POV treats it as a scalar function with no arguments. I get an
>> error when I try to assign to it.
>>
>
>But you can change the clock value and clock delta in an arbitrary manner during
>an animation. Just #write the appropriate initial_clock, final_clock,
>initial_frame and final_frame options to an ini file.
But wouldn't you then have to restart the renderer for those options to take
effect? If not, I'd say that's a bug. Even if you can, you shouldn't use
#static if you're gonna play around with the poor thing's mind like that.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
>
> But wouldn't you then have to restart the renderer for those options to take
> effect?
Come to think of it, I haven't tried. And I agree, it's too twisted to worry
about :)
Margus
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Juha wrote:
>
> PoD <pod### [at] merlin netau> wrote:
> : I'm beginning to think that #static as a type of #declare would be more
> : feasible, after all it is only usefull for things which take a long time
> : to parse such as complex unions and meshes.
>
> You forget that you can make #while-loops which take hours to parse although
> it creates only some simple objects.
You could make a #while loop which takes days to parse and creates no
objects at all
>
> : When parsing a #static declaration, check if the name is already in the
> : symbol table. If it is then skip to the end of the declaration.
>
> : How do you know what's the end of the declaration?
> : Firstly all declarations should end with a semi colon. Then each
> : [#declare|#local|#static] would match up with a semi colon.
>
> You still have to parse the entire code to see where is the matching
> semicolon.
If a #while loop is inside a #static declaration, you'd only have to
look for the matching #end which would not take long at all.
#include would be totally ignored.
> There's no way to avoid parsing other than copying the whole source code
> to memory without the static parts of it and then parse this copy.
What difference does reading it into memory make?
>
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
>
> Or, using the syntax I proposed,
>
> #static (start, end)
> #include "filename"
> #end
True. Three lines instead of one isn't going to make a significant
difference to parsing, although it's slightly more trouble to type,
so the above would give almost identical results -- *if* the end
user applies it correctly.
I only mentioned it as a supplement to #include (analogous to the
way #local is a specialized supplement to #declare) because problems
with making it a #static block were brought up. As an alternative
to #include, there'd be no block, and users would have to
externalize the static info to a separate file because... that's
just the way it works.
Whereas, if you require the user to set up a #static block with an
embedded #include in it, sure as there's rain you'll have people
who skip the #include and just stuff hundreds of lines of code
between #static and its corresponding #end and complain that it
isn't making the kind of difference they think it ought to (and
Warp will have to add something new to the VFAQ). As much as I
hate "protect them from their own stupidity" style programming...
Well, I'm a scene coder, not a programmer. I only mention it
in passing, FWIW.
Charles
--
http://www.enter.net/~cfusner
"...Then darkness took me, and I strayed out of thought and time,
and I wandered far on roads that I will not tell..."
-The Two Towers, JRR Tolkien
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 22 Sep 1999 17:43:27 -0400, par### [at] fwicom (Ron Parker) wrote:
>As for how to get patches into the official version, I'm not
>sure there is an official documented method...
There isn't any standard routine that is followed to integrate a user
patch into the Official. It helps if the author, or an interested third
party, can compile an executable and make it available, along with some form
of rudimentary documentation for the patch. Technical support for this
patched version could take place on this server. Come to think of it,
doesn't this procedure some a bit familiar, Ron?
User patches are more likely to be integrated into the Official POV-Ray
if:
1) the patched version proves to be popular among other POV-Ray enthusiasts,
and...
2) the bugs are worked out by newsgroup feedback and technical support from
the author.
--
Alan ---------------------------------------------------------------
http://www.povray.org - Home of the Persistence of Vision Ray Tracer
news.povray.org - where POV-Ray enthusiasts around the world can get
together to exchange ideas, information, and experiences with others
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 22 Sep 1999 20:02:46 -0700, Alan Kong wrote:
>Come to think of it,
>doesn't this procedure some a bit familiar, Ron?
Hm.... Yeah, it seems to ring a bell, but I can't put my finger on
it....
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
