On Fri, 10 Mar 2000 12:21:22 +0100, Axel Baune
<aba### [at] neuroinformatikuni-ulmde> wrote:

>Hello,
>
>PoD wrote:

>> Then use a while loop and nothing is lost, except that you've made your
>> script hard to read.  There's probably an easier way to do it using
>> for()
>
>No, you couldn't do everything with a for-loop what you could do with a
>while-loop. The while-loop is far more flexible, beacuse the for-loop is
>a special case of the while-loop for cases where _one_ variable is
>looped through a range of values with a constant step width. 

Did the man say he wanted to *replace* the while-loop, or does he
perhaps want to supplement the while-loop with a for-loop? I see
nothing wrong with having a for-loop in POV. For many situations, it
would be easier for newcomers to understand and it would work
perfectly. The for-loops I have used in the past have also allowed a
STEP parameter that defined the amount of increment for each loop. One
wouldn't have to be limited to incrementing or decrementing by one.


Later,
Glen Berry

Post a reply to this message

On Thu, 09 Mar 2000 19:13:21 -0500, Chris Huff
<chr### [at] yahoocom> wrote:

>Still, my first point was a platform specific editor feature is no 
>substitute for a language feature.

Whos said anything about a platform-specific editor? 

There must be something I am overlooking here. Aren't programs that
deal with ASCII text some of the most easily portable programs? Why
does a POV scene editor ( not a modeler, mind you ) have to rely on a
lot of platform specific coding? I'm sure someone will be quick to
remind me of the reason I seem to have forgotten.

Later,
Glen Berry

Post a reply to this message

On 9 Mar 2000 19:53:59 -0500, ron### [at] povrayorg (Ron Parker)
wrote:

>There are other reasons to prefer += in a case like that.

I'll admit that I didn't understand the usefulness of this until you
explained it so well.

Later,
Glen Berry

Post a reply to this message

On Sat, 11 Mar 2000 22:42:04 -0500, Chris Huff
<chr### [at] yahoocom> wrote:

>Remember though, that POV-Ray is created by people in their free time. I 
>wouldn't want them to delay the releases so documentation like that 
>could be written. 

I think that the documentation could be improved quite a bit, even
without going into more complex aspects of scene creation. More
illustrations would be a good start.

As for custom-patched versions of POV, every new patch should come
with multiple examples of each new keyword and concept that are
introduced. If the patch is available for Windows, then appropriate
insert-menu addtions should be offered with the patch as well.

>> And it would be nice if POV-Ray had some sort of plugin architecture

>This is a nice idea, but would be nearly impossible to implement.

I'm not a serious programmer, but I've always thought that the main
obstacle to plugins was the attitude of the POV-Team being against
such things. I thought some people had already proposed workable ideas
for implementing plugins, but the POV-Team firmly refused the concept.
Mind you, I don't dare say that it would be easy to add plugins, but I
think it should be possible somehow.

Even POV itself can't be simply compiled on every platform it is used
on, without some porting work performed by talented human programmers.
If this were not the case, then why is there a Mac specialist, a Linux
specialist, a Windows specialist, etc? It took a long time to get a
Linux port of a recent POV version. If POV were perfectly
cross-platform, then there wouldn't have been the wait.

Also, need I remind everyone that the various ports of Official POV
have  different feature sets? The Windows version has a built-in
editor with color-syntax highlighting. I think the Mac version has
QuickTime support. The DOS version has neither.

I think that a plugin system could be devised. Instead of simply
dropping a plugin written for an Intel/Windows machine into a Silicon
Graphics machine running UNIX, one might have to port the plugin the
same way that POV itself is ported. It might even turn out that some
plugins might behave slightly different on different platforms, or
perhaps not be available at all on some platforms. This would be
acceptable to me, as long as everyone realized that plugins were to be
considered *options* and not part of the base functionality of POV
itself. 

I don't hear people saying that 'Photoshop shouldn't use plugins
because not all plugins are available on all platforms'. In fact,
plugins are a vital part of Photoshop's appeal for many people, in
spite of the fact that some plugins aren't available on some
platforms.

Later,
Glen Berry

Post a reply to this message

On Mon, 13 Mar 2000 17:50:40 -0500, Chris Huff
<chr### [at] yahoocom> wrote:

>In article <38CCF223.EE4E8A91@nigels.com>, nig### [at] eisanetau wrote:
>
>> 	All I want to see here is some more brainstorming
>> 	going on.  If povray is still available in 2050,
>> 	it will only be because it keeps evolving.
>
>Just don't forget that it won't keep developing if everyone stops using 
>it because of a poor design choice.

Poor design choices haven't stopped it yet.    :)

...and yes, there *have* been at least a few poor design choices.

I say if someone has the ability to write an XML based POV, more power
to them. It would be nice to actually have such a program to test,
instead of just speculating about it. You won't often find me
discouraging experimentation with new ideas. It's often the more
unusual ideas that end up being the most enlightening. Even if an idea
never makes it into mainstream use, there is often still be a place
for it, or it might lead to bigger and better things, as yet
unforseen.

Later,
Glen Berry

Post a reply to this message

Chris Huff wrote:

	Pardon for deleting all of yours but this is my issue. 

	If syntax is extended then those issues will have to be
addressed. That is my point. One simple routine that can do
everything is quite good enough. 

-- 
A free internet for a free people.

Post a reply to this message

On Mon, 13 Mar 2000 20:46:03 -0500, Chris Huff
<chr### [at] yahoocom> wrote:

>Not necessarily. It is pretty easy to add parsing code for most 
>features, and it should get a lot easier in POV 4.0 after the planned 
>conversion to C++.
>
>
>> 	Yes, but once in POV script, you can't do anything else
>> 	with it.
>
>I really don't know what you mean by that...

You've been saying that a lot lately, but still you seem content to
judge that which you don't understand.

His point was the POV-Script isn't very easy for another program to
parse. Why would you want to parse POV code with another program? It
would be handy for 3rd party file format converters, modelers,
editors, object generators, and more. Several people have wanted to
write some cool utility programs. but were stopped cold at the
prospect of writing a parser that understood POV code flawlessly. It
would be possible to do, but in many cases, it would be harder than
writing the actual utility program it was to be used with.

Later,
Glen Berry

Post a reply to this message

On Mon, 13 Mar 2000 07:16:50 -0500, Chris Huff
<chr### [at] yahoocom> wrote:

>The reason it got a consistently negative response is that it would 
>require a graphical editor to comprehend the simplest scene written in 
>that language. 

Perhaps, for you. I think that the vast majority of people would prove
your statement grossly exaggerated at best. Your statements carry the
tone of a person who is either afraid of a new idea, or doesn't
understand it, and vehemently scorns any mention of it. In fact, you
have repeatedly said that you didn't understand the benefits that
Nigel has listed for you,  but you seem to still feel qualified to
dismiss the idea as impractical. How can you properly judge that which
you don't understand?

I, on the other hand, would actually find it easier to read and write
in an XML style. Oh sure, it's more typing (assuming you don't have an
advanced editor), but it is more logical, predictable, and extensible.
The "punctuation" is also *MUCH* simpler with tags, because you don't
have to remember whether to use parenthesis, brackets, braces, single
quotes, or double quotes  with a given keyword. For the most part,
there are only <> characters for punctuation.

Someone has said that the braces in POV make it really clear and easy
to understand. I say that closing tags, which are more specific than
simple closing braces, are even more simple to sort out. When I see a
closing brace, I have to back track and count braces to see what
keyword that closing brace is associated with. If it were a closing
TAG, then I would know immediately which keyword it was associated
with. How many times have you wasted time chasing a missing closing
brace, or perhaps had one brace too many? (Everyone has an occaisonal
typo, everyone from Ken to Ron Parker.) It would be much quicker to
find a missing or extraneous tag, because they are directly labeled as
to *what* they are actually closing.

>there would be no reason to use it

We've already given you a few reasons to use it, so that comment is
totally incorrect. I can only assume you mean it euphemistically.

>, and several reasons not to use it

Even though I am intrigued by the idea of POVML (XML styled POV), I
will agree that it would be more typing, at least in its *raw form*. I
have suggested in the past that if POVML were adopted, it might be a
good idea to create a cross-platform editor for it that tokenizes the
raw form to conserve file space. The idea is similar to what Atari
BASIC did. You typed in the BASIC program, and the BASIC interpreter
tokenized your file into a much more compact form for its internal
use. The end user only saw the expanded, human readable form, but the
file was actually stored on disk in a tokenized form. This
tokenization is not to be confused with the language interpretation
that happened at run time. In some respects, Atari BASIC was somewhere
between a pure interpreted, and a pure compiled language. Doing
something like this for POVML would solve the filesize problem, and
probably shorten the render-time parsing a little to boot, since at
least some of the parsing work could be done at entry time, during the
tokenization.

This editor could also automatically supply closing tags for you when
you typed the original tag. That would eliminate half the added typing
right there. It would also insure that you always *had* a closing tag,
and never forgot to type one. (Unlike the current situation with
braces and our current editors, where one can easily lose count and
forget a closing brace in a complicated piece of code.)

I think that XML styled POV code deserves exploration.

Later,
Glen Berry

Post a reply to this message

Glen Berry wrote:

> Someone has said that the braces in POV make it really clear and easy
> to understand. I say that closing tags, which are more specific than
> simple closing braces, are even more simple to sort out. When I see a
> closing brace, I have to back track and count braces to see what
> keyword that closing brace is associated with. If it were a closing
> TAG, then I would know immediately which keyword it was associated
> with. How many times have you wasted time chasing a missing closing
> brace, or perhaps had one brace too many? (Everyone has an occaisonal
> typo, everyone from Ken to Ron Parker.) It would be much quicker to
> find a missing or extraneous tag, because they are directly labeled as
> to *what* they are actually closing.

Then again there is nothing stopping you now from commenting your own code
to accomplish the same thing if clarity is what you seek. It would take
a little time to get used to idea but once you started to practice it you
would no longer have to worry about knowing which closing brace matched
which function. Must the program force you to use good code writing
practices ?

e.g.

  } // texture
 } // sphere
} intersection


 I will also raise one more major disadvantage of moving toward the
<----> tags you mention. It will break every single POV-Ray utility
and modelling program ever created because they have all been programmed
to use the curly brace for opening and closing functions. One cannot
presume that every utility author will take the time to adapt their
programs to this new syntax and in fact it would be unreasonable to
presume that they would want to or are even still around to do so.
I would call that a crippling blow to everyone who uses a modeller
or utility designed to work with the program.


P.S. Most people lose track of which brace closes what because they
     indent their code. Indented coding practices are evil and should
     be banned.

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

<KEN>
 I will also raise one more major disadvantage of moving toward the
<----> tags you mention. It will break every single POV-Ray utility
and modelling program ever created because they have all been
programmed to use the curly brace for opening and closing functions.
One cannot presume that every utility author will take the time to
adapt their programs to this new syntax and in fact it would be
unreasonable to presume that they would want to or are even still
around to do so. I would call that a crippling blow to everyone who
uses a modeller or utility designed to work with the program.
</KEN>

<GLEN BERRY>
One *more* disadvantage? This would actually be the first disadvantage
you have mentioned in this message. Your previous paragraph dealt with
an issue that could be dealt with in ways other than using an XML
style. It didn't show any inherent disadvantage in an XML style
however.

<JEST>
As for this "disadvantage" you bring up, it only exists for those
people that want to use a legacy modeler with the new XML syntax.  
Those people who wish to live in the past can continue using the
current version of POV with their current modeler. No one is going to
force them to upgrade.
</JEST>

</GLEN BERRY>

Post a reply to this message