"Thorsten Froehlich" <tho### [at] trfde> wrote:
> ...if you don't see it you never looked into the POV-Ray source
> code nor the concept of these directives.

If a language has an explicit pre-processing stage, then there is something
wrong with the language itself. My point is that POV-Ray must not expose
that to the user -- and hopefully get rid of such internal subdivision as
well.

Thorsten, should I reply then that if you fail to see that, then you have
never had any experience with language design and implementation? I think
that I shouldn't -- nor should you use the "arguments" like those you came
up with... I completely agree with those who say that POV-Ray has marvelous
community, which actually represent part of the joy for those using
POV-Ray -- let's keep good spirit, OK?

As to my POV-Ray background... well, I made the first custom version of
POV-Ray back in 1996, and made it publicly available in 1997. It was
available at the CompuServe's GO POVRAY forum, library section 17; it is
still available at ftp://ftp.ru.com/pub/gamos/povpro/. Since then, I've made
several more versions, mostly dealing with animation, for my personal use.
BTW, one of the features added to the public version was the ability to
examine internal representation of scenes, since that (coupled with overall
language structure) was always of interest to me... You may want to read
ftp://ftp.ru.com/pub/gamos/povpro/povpro.txt go get a better idea of that.

Of course, my input into the official POV-Ray development is not only
incomparable, but is neglectable compared to yours. I would like to assure
you that I really think so -- I am aware of what you are responsible for.
All I did for the *official* POV-Ray is fixed two bugs in compressed BMP
reader, improved portability of the utility word/dword reading routines,
proposed portability enhancements to the Targa reading code... plus probably
sparkled interest in Intel's Proton compiler -- the thing is that I used its
preview version, issued by Intel at one of their seminars, and that
contributed significantly to the overall performance.

So, at large, my proposal is this -- lets respect each other and exchange
real arguments. I would be happy to discuss everything with you, or anybody
else, then.

Regads,
Vadim.

Post a reply to this message

On Wed, 13 Mar 2002 13:27:23 +0300, "Vadim Sytnikov" <syt### [at] rucom> wrote:
> "Thorsten Froehlich" <tho### [at] trfde> wrote:
> > ...if you don't see it you never looked into the POV-Ray source
> > code nor the concept of these directives.
>
> If a language has an explicit pre-processing stage, then there is something
> wrong with the language itself.

I think there is not so much SDLs to compare but I think many of programing
languages has some kind of parser directives. My native platform is 4GL by
Progress and there are preprocesor directives. They all start with &
character. I don't think that they looked to POV-Ray becouse POV-Ray is older.
I don't think POV-Team looked at Progress either. Perhaps there is general
rule for preprocesors.

> My point is that POV-Ray must not expose that to the user
> and hopefully get rid of such internal subdivision as well.

But that's the case: internall subdivision is required becouse all #directives
can appear in any place while scene description parts have clearly described
order. As I said I like it. I like tools which represents internal behaviour
becouse it gives more control (at least feeling of it).

> You may want to read
> ftp://ftp.ru.com/pub/gamos/povpro/povpro.txt go get a better idea of that.

Very interesting reading. Have you any experience how your improvements appear
nowadays ? I mean are they considered in modern compilers ? Have you
experimented with them on 3.1 or megapov sources ? Perhaps you can share some
your ideas during beta-testing of 3.5 with two compilators.

> I would be happy to discuss everything with you, or anybody
> else, then.

I'm still really interested with "what was more elegant in PolyRay" question.
For example could you "translate" one sample source from current 3.5 package
with various scene components and directives if possible (of course excluding
not portable things)?

ABX

Post a reply to this message

wrote:
> I don't think that they looked to POV-Ray becouse POV-Ray is older.

Of course younger than Progress.

ABX

Post a reply to this message

"Vadim Sytnikov" <syt### [at] rucom> wrote in message
news:3c8f298c$1@news.povray.org...
> "Thorsten Froehlich" <tho### [at] trfde> wrote:
> > ...if you don't see it you never looked into the POV-Ray source
> > code nor the concept of these directives.
>
> If a language has an explicit pre-processing stage, then there is
something
> wrong with the language itself. My point is that POV-Ray must not expose
> that to the user -- and hopefully get rid of such internal subdivision as
> well.

The explicitness of a preprocessing stage has nothing to do with the
language itself.  For instance, MSVC will automatically, preprocess, compile
and link objects all in one step.  gcc on the other hand, has separate tools
for preprocessing, compiling, assembling, and linking (though you have a
common 'control' file to do it all at once).  In one of them, it is very
explicit; in the other, it is implicit.  But they both work.

That being said, I think it's important to maintain the distinction between
the preprocessing and the processing.  In fact, it might be useful to have
an option for outputting a preprocessed file, in case someone needs to see
exactly how their loops are unrolling or something like that.

...Chambers



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.323 / Virus Database: 180 - Release Date: 2/8/2002

Post a reply to this message

In article <3c8f298c$1@news.povray.org>,
 "Vadim Sytnikov" <syt### [at] rucom> wrote:

> If a language has an explicit pre-processing stage, then there is something
> wrong with the language itself. My point is that POV-Ray must not expose
> that to the user -- and hopefully get rid of such internal subdivision as
> well.

I don't think the mere presence of a preprocessor is a flaw in a 
language. And in this case, it is rather unavoidable...unless you want 
to re-evaluate the entire scene for each ray cast.
The POV-Ray control structures (macros, #if-else and #switch 
conditionals, #while loops) are more like preprocessor directives than 
language structures, and this gives them some very useful 
advantages--you can use them to generate scene code automatically, 
making a large number of objects in a union or initializing arrays. 
There isn't a separate pre-parse stage, but the scene parser doesn't see 
the loops and doesn't need to, it just needs to know objects and other 
scene attributes. After parsing, the scene is pretty static, it just 
gets rendered.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

Vadim Sytnikov <syt### [at] rucom> wrote:
> Thorsten, should I reply then that if you fail to see that, then you have
> never had any experience with language design and implementation?

  Aw, come on! All this is sounding like having # characters in script
commands is bad language design.
  Hello? It's just syntax. It could have *anything*. It doesn't have to look
like other languages.
  At least some variants of BASIC use the ':' character as a command separator.
Other languages use ';' as command separator. Some other languages don't use
command separators at all (well, usually whitespace works as separator). In
some languages all commands may be all uppercase, in others they are all
lowercase, and yet in others it doesn't matter how you write them. So what?
It's just syntax. You can't say that one is worse than another.

-- 
#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

In article <3c8f298c$1@news.povray.org> , "Vadim Sytnikov" <syt### [at] rucom>
wrote:

> You may want to read
> ftp://ftp.ru.com/pub/gamos/povpro/povpro.txt go get a better idea of that.

(I have not read to the end yet, but this is a separate question anyway)
In section 6.2 you mention that the Intel compiler will turn multiple
divisions by the same number into one division and then uses multiplications
for floating-point numbers.  Do you know if in its current version the Intel
compiler still does this?

    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

In article <3c8f298c$1@news.povray.org> , "Vadim Sytnikov" <syt### [at] rucom>
wrote:

> Thorsten, should I reply then that if you fail to see that, then you have
> never had any experience with language design and implementation? I think
> that I shouldn't -- nor should you use the "arguments" like those you came
> up with...

I fail to see why my arguments are not valid:  As there is no formal language
specification, the only why you can find out that your suggested changes (or
to be more precise the grammar changes they imply) would seriously degrade the
flexibility of POV-Ray.  In the source code you can see that the parsing is
more or less on two separate levels.  One processing directives and the other
layer, below it, processing scene description.  If you actually use the
language as it is for complex tasks, you will find the separation between
scene description and (programming) language very natural and essential for
the flexibility that is simply impossible otherwise.

Further, the conclusion you drew from my argument is incorrect.

    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

On Wed, 13 Mar 2002 20:15:47 +0100, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> you will find the separation between
> scene description and (programming) language very natural and essential for
> the flexibility that is simply impossible otherwise.

It could be compared to the HTML/js pair probably where HTML is document
description and javascript is a substitute of language. AFAIK broswers
parse/render both in one pass.

ABX

Post a reply to this message

> I think many of programing
> languages has some kind of parser directives.

To some degree, yes. Even such a "pure" language as Ada has that -- but only
to control speed vs. space tradeoffs, etc. In fact (although I strongly
dislike Ada...), I think that that is probably the right approach -- to
control parsing, but not alter the contents of source files...

> But that's the case: internall subdivision is required becouse all
#directives
> can appear in any place while scene description parts have clearly
described
> order. As I said I like it. I like tools which represents internal
behaviour
> becouse it gives more control (at least feeling of it).

I like such tools too, but I do not think that POV-Ray directives strictly
fall into this category (more on this later). There is such thing as "the
spirit of C" that current body of ANSI C committee pledged to keep (w/o much
success though :-( ), which means (among other things) and language
statements must be lightweight -- i.e. compiler must not generate heavy code
for simple-looking statements (examples of the opposite are exceptions, RTTI
etc. in C++). All in all, I like transparency in language semantics, too...
but, as we are going to have a chance, would like to improve the way it is
done in POV-Ray.

> Have you any experience how your improvements appear
> nowadays ? I mean are they considered in modern compilers ? Have you
> experimented with them on 3.1 or megapov sources?

No -- I have no clue as to how that works these days. I have switched to
Visual C++, plus I'm using GCC very heavily (a lot of work for ARM and
similar processors). I have not tried Proton for a long time now.

> Perhaps you can share some
> your ideas during beta-testing of 3.5 with two compilators.

That would require access to POV-Ray source code, that I don't have. So I'm
just waiting for the first release.

> I'm still really interested with "what was more elegant in PolyRay"
question.

PolyRay is not THAT ancient, indeed... You may want to get some old release
of Moray, get PolyRay plugin for it, set PolyRay as your current renderer,
and render some sample scene (you cannot just export the scene if your Moray
copy is not registered) -- you should be able to see the difference. As to
what exactly I see as more elegant/appropriate alternative to some pieces of
POV-Ray syntax, I will probably address in another message.

Regards,
Vadim.

Post a reply to this message