> It is complex to parse, but parsing isn't the only thing that is
> important. 

	You're right - parsing is not the only important
	thing - but it is important.

> And I really don't see why I would want to use Internet Explorer(or any
> web browser) to parse POV scripts or edit POV scripts with a web page.

	Internet Explorer is capable of displaying an XMLish POV
	script in "traditional" POV script, complete with syntax
	highlighting.  Alternatively, you could display it in
	whatever notation makes the most sense.  The important
	point is that many applications will be able to work with
	XML, whereas not many applications will ever be able to 
	work with POV Script, except as ASCII text.

> I guess we have different priorities. I(and apparently most people here)
> want a language which is more flexible and easier to read than the
> current POV-Script, and you want a language which you can write a parser
> for more easily.(or use an existing parser for)

	XML is more flexible than POV Script.   One way to keep 
	everyone happy, would be to provide a translation layer
	from POV script.  It's a better design than having a
	monolythic parser that tries to be everything to everyone.
	
> And for the majority of extensions, you would still have to modify the
> POV source code.

	Yes, but these changes would be much simpler.

> Writing POV from a program is easy

	Yes, but once in POV script, you can't do anything else
	with it.

> That is why I am working on POV C-SDL! Which happens to be human
> readable-writable. :-)

	What I've seen of POV C-SDL looks quite nice.
	Do you think this should be layered on top of
	POV, or compiled straight into the binary?
	(Where do I find docco on POV C-SDL?)

> Do you think there is no reason the most popular programming languages
> are designed the way they are? The "flat text" format happens to be
> quite versatile, and human *creatable* and human *readable* instead of
> something that can only be tweaked by hand and which has to be generated
> and read by a program.

	Programmers are quite familiar with the strengths and
	weaknesses of using flat text.  There is not reason that
	programming languages should have to be this way. To
	limit your imagination to this way of doing things is
	unnecessary.

> You seem to define language differently from everyone else. A language
> is more than the data model it represents. Otherwise, Pascal and C could
> be considered the same language. XML would let *programs* manage the
> data more effectively, but would greatly restrict what humans can do.

	Pascal and C are nearly equivalent languages.  They are
	basically the same technology.  The fact that it's
	possible to generise away from either Pascal and C
	and provide translation to either - is a powerful idea.
	
	The point here is the exact format expected by a particular
	compiler (say C or Pascal) is not as important as the 
	struture of the underlying data that you're feeding it.
	XML captures this data, while being generic about the
	formatting.

> What cross-platform GUI tools are you referring to?

	A few off the top of my head:

	V is a cross platform C++ library for GUI's
	Qt is the basis for the KDE project
	Gtk is the basis for Gnome, and is being ported to windows
	Java
	There are quite a few other options.

> It will be a long time until a (graphical) tool is available on
> all the platforms POV runs on. 

	I don't think it's as big an issue as you believe it is.

> Many people would probably give up on POV before then...

	I think that as long as people still have POV script
	as an option, they are not going to be concerned with
	the underlying technology used for implementation.

> Just don't forget that it won't keep developing if everyone stops using
> it because of a poor design choice.

	I think that using POV Script as _the only_ way to get
	data into POV is a worse design choice.  

--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.

Post a reply to this message

In article <38CD7C45.38B53962@nigels.com>, nig### [at] eisanetau wrote:

> 	XML is more flexible than POV Script.   One way to keep 
> 	everyone happy, would be to provide a translation layer
> 	from POV script.  It's a better design than having a
> 	monolythic parser that tries to be everything to everyone.

So what exactly are you suggesting? That POV should use XML for data 
representation and should internally convert POV-Script to XML as well 
as supporting XML input?


> > And for the majority of extensions, you would still have to modify the
> > POV source code.
> 
> 	Yes, but these changes would be much simpler.

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


> 	What I've seen of POV C-SDL looks quite nice.
> 	Do you think this should be layered on top of
> 	POV, or compiled straight into the binary?
> 	(Where do I find docco on POV C-SDL?)

I posted a description of my concept in .off-topic. It would be 
translated by a separate program into POV-Script, either by converting 
loops, conditionals, etc. to POV-Script syntax or by executing the C-SDL 
code and outputting the objects and scene settings. Eventually, it might 
be included as an actual feature of POV, but it would probably be wise 
to wait for most of the problems to be worked out of it(of course, a 
parser/converter has be be written for it before that can start. I am 
making an attempt, but would welcome any help anyone would want to 
give.).


> 	Programmers are quite familiar with the strengths and
> 	weaknesses of using flat text.  There is not reason that
> 	programming languages should have to be this way. To
> 	limit your imagination to this way of doing things is
> 	unnecessary.

But is it actually limiting? I don't feel very limited...can you give an 
example?
BTW, have you ever heard of the ProGraph programming "language"? Just 
wondering...


> 	Pascal and C are nearly equivalent languages.  They are
> 	basically the same technology.  The fact that it's
> 	possible to generise away from either Pascal and C
> 	and provide translation to either - is a powerful idea.

But they are separate languages. They can both be used to express the 
same idea, but they are different things. Just as English and Spanish 
are different human languages, they can both express the same "data", 
but are clearly separate languages.


> 	The point here is the exact format expected by a particular
> 	compiler (say C or Pascal) is not as important as the 
> 	struture of the underlying data that you're feeding it.
> 	XML captures this data, while being generic about the
> 	formatting.

The problem is that it is too generic, it can't be hand-edited easily. 
Special tools are required.
It is more of a file format than an actual language...


> > What cross-platform GUI tools are you referring to?
> 
> 	A few off the top of my head:
> 
> 	V is a cross platform C++ library for GUI's
> 	Qt is the basis for the KDE project
> 	Gtk is the basis for Gnome, and is being ported to windows
> 	Java
> 	There are quite a few other options.

And these will let me create and edit files written in this XML-POV 
without being exposed to the XML "syntax"? Or they will let me write 
programs that use XML?


> 	I don't think it's as big an issue as you believe it is.

I think it is. If I don't have the required tools, I can't use it.


> 	I think that as long as people still have POV script
> 	as an option, they are not going to be concerned with
> 	the underlying technology used for implementation.

I think I see what you mean now...some kind of XML-based interpreter 
that can read POV-Script as well as XML?


> 	I think that using POV Script as _the only_ way to get
> 	data into POV is a worse design choice.  

Why isn't POV-Script a good way of getting data into POV? The only 
information absolutely required is the objects and things like 
global_settings, background, etc. A program can just "run" a scene 
described in another language and output the data in POV-Script.
I don't understand this "flexibility" argument, at some point it has to 
be converted into data structures in RAM. The only thing that would make 
adding features easier would be the universal syntax, and that could be 
done in other ways just as well.

Whatever you think, I am not against XML. I think it is a great idea for 
many things, just not the right tool for POV.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

"Nieminen Juha" <war### [at] sarakerttunencstutfi> wrote in message
news:38ccad49@news.povray.org...
> Matt Giwer <jul### [at] ijnet> wrote:
> : Everything in computing can be done with the minimalist set of
> : micro-code which actually gets down to four or five instructions
> : depending upon your side in the debate
>
>   Actually 2 instructions are enough.

"on" and "off" ?  Programming in pure binary, are you?
rc

Post a reply to this message

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

Glen Berry wrote:

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

<PANIC> Shoot the horse ! Shoot the horse ! </PANIC>

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

> So what exactly are you suggesting? That POV should use XML for data
> representation and should internally convert POV-Script to XML as well
> as supporting XML input?

	I've been giving this some thought today, pondering the
	technicalities as well the unexpected hysteria generated
	on povray.general and the IMP list.  Every day I go to
	work improving a software product, trying to deliver the
	features that users are asking for.  I get a lot of
	satisfaction from finding elegant, robust and user
	friendly solutions to new problems.  But, in the context
	of povray, the mere suggestion of some kind of paradigm
	shift seems to upset people very quickly. 

	Anyway - here is a more concrete model of how I think
	povray data input should be handled.  There needs to
	be a clean and simple interface between the POV parser
	implementation and the core POVray raytracing engine.
	This API might look like a bunch of simple functions
	such as "bool insertSphere(...)" which is as minimal
	as possible, while supporting all of the POV data types.
	Things like loops, variables and macros should be
	strictly layered above this API.  This API would also
	make a nice DLL interface, eventhough the POVteam
	don't like the idea of POV being used as a library.
	The existing parser simply becomes one possible user
	of this API.  Text editing die-hards can do whatever
	they please, without any threat from trendy programmer
	types who want to do different things.  Another user
	of this API could be an interpreted C environment, 
	POV-CSDL, XML, or whatever takes people's fancy.
	The POV-team control the "official" API, but allow 
	people to build on top of it freely.  Ideally, the
	API is also made available as DLL so that Java, C,	
	Delphi, etc programmers can do whatever they like,
	in the language of their choice.

	This handles input.  Another question is output -
	would it be useful and desirable to provide some
	mechanism to extract the state of a POV world 
	at runtime?  Maybe, maybe not.  I do not intend
	to deal with this at this stage.

	Before closing, a few points about an XML pov
	that perhaps have not been stated clearly:

	XML is certainly not customised for the problem
	of text editing descriptions of 3D scenes.  It's
	not bad, but it's not ideal.

	XML is a mechanism that would allow third party
	tools to manipulate POV scenes.  You load the
	data in, edit geometry, textures, etc, then
	save the data out.  One critical limitation in
	POV script is the difficulty in parsing it.
	In some ways, POV script has been so heavily
	optimised for hand editing (in addition to
	the macro and looping constructs) that it
	is much more complicated than it needs to be
	for many other tasks.

	XML is a mechanism that simplifies extension.
	You don't need to be a parser expert to define
	new data types, or to add attributes to objects.
	Because the grammar is less ambigous (taking
	advantage of verbosity) an XML parser can 
	ignore irrelevant data - but preserve it.
	Backwards compatibilty in a scheme like POV
	script is a more difficult problem.

	XML allows POV to take advantage of related
	technology such as VRML.  To support VRML
	datatypes, we simply borrow the grammar -
	no parser programming necessary.  To support
	a new procedural texturing architecture, we
	borrow their grammar, no parser programming
	necessary.  (There is a big difference between
	writing a parser and writing handlers for
	an XML parser)

	If there are other people who find these
	possibilities attractive, I would be interested
	in developing a more detailed proposal.  Some
	aspects would require interaction with the
	POV team, or the TAG people - but I think it's
	fair to present them with more than a
	"we think XML is funky idea" or have them 
	sift through threads of conceptual development
	and hysterical backlash.

	XML is of immediate commercial interest to me
	for other projects, so I can justify a lot of
	time as developing expertise. ("homework")
	I think that there should be at least a 
	group of people involved, and a healthy
	discussion, in combination with some 
	public relations.  If you think that XML
	is an interesting technology to apply to
	POVray, are just curious about XML, I would
	encourage you to drop me an email.

	XML does not mean manual editing of tags
	in a text editor.  People that keep harping
	on this are just being silly.  But I am quite
	convinced that text editing should become a
	thing of the past.  (I never can remember
	the RGB or even name for "that favorite 
	blueish grey" that I always like to use, nor
	should I have to remember junk like that.)

--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.

Post a reply to this message

In article <38CDD5B5.36C4EB94@ij.net>, Matt Giwer <jul### [at] ijnet> 
wrote:

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

What issues? That is what I want you to clarify.

    The for loop is well defined, POV would use the existing definition, 
which is quite possible with the POV syntax.

    There is no debate that I have seen over integer versus float 
variables within a loop, and that is irrelevant anyway, since POV 
doesn't have separate types for integer and float.

    The ++ and -- operators would not fit in the current syntax of POV, 
so you can forget about them.


> One simple routine that can do everything is quite good enough.

So we should drop the #switch, #macro, and #while features and add #goto 
and #label? And get rid of #local while we are at it...

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

> >       Yes, but once in POV script, you can't do anything else
> >       with it.
> 
> I really don't know what you mean by that...

	I mean that once data is stored in POV format,
	it is trapped there.  Worse than that, it may not
	even be compatible with the next version of POV.

> >       (Where do I find docco on POV C-SDL?)
> I am making an attempt, but would welcome any help anyone 
> would want to give.).

	I'm happy to look at what you've got, or exchange 
	email, but I don't have enough time to follow it
	on the newsgroups.  I'll keep an eye out though...

> >       Programmers are quite familiar with the strengths and
> >       weaknesses of using flat text.  
> But is it actually limiting? I don't feel very limited...

	Yes it is.  I spent all afternoon staring at C++ code
	wondering why there is no facility to have graphical
	documentation embedded in the source code.  I do
	graphics programming, and the geometric result of
	code is not always obvious from the C++ code.  Why
	can't I extend the C++ file format to stick anything
	in there that is relevant?  Why can't I rename the
	member "A::doXYZ()" without doing a search and replace?
	Why can't I get an instant list of all everywhere that
	a certain variable is modified, or a function called?
	The compiler figures out all this information but 
	doesn't use it for useful things.  C++ programmers
	are trapped all day in this klunky ASCII view of
	their problem.  

	I'm sure that some punch-card users didn't feel
	very limited either.  I used to think Commodore
	Basic was pretty cool.  Then machine language,
	then C, then C++.  You don't really see the 	
	limitations until you are freed from them.

> >       Pascal and C are nearly equivalent languages. 
> But they are separate languages. 

	They are referred to as separate language, but
	they are actually so similar that it may be better
	to refer to them as "dialects of procedural programming".
	

> The problem is that it is too generic, it can't be hand-edited easily.
> Special tools are required.

	Special tools are required for editing text too.
	You need a computer, monitor, keyboard and
	text editing program.  Are you taking all this
	technology for granted?  It must be working well!

> I don't understand this "flexibility" argument, at some point it has to
> be converted into data structures in RAM. The only thing that would make
> adding features easier would be the universal syntax, and that could be
> done in other ways just as well.

	Why would you do it in "other ways"?   You think
	you know better?  Do you think XML is some gimmick
	that Microsoft cooked up to make you upgrade all
	of your software?  Find out more about XML,
	at the very least it will improve your ability
	to argue against it. :-)

--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.

Post a reply to this message

> : From the viewpoint of a computer scientist (I'm one) this is a not a
> : syntactically correct defiend for-loop. The variable of a for-loop
> : belongs to the for-command and should be never _changable_ by the user.

	I strongly disagree.  It is in fact syntactically correct,
	and there is no theoretical reason that the loop variable
	is more sacred than any other variable.

--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.

Post a reply to this message

Nigel Stewart wrote:

>         I've been giving this some thought today, pondering the
>         technicalities as well the unexpected hysteria generated
>         on povray.general and the IMP list.  Every day I go to
>         work improving a software product, trying to deliver the
>         features that users are asking for.  I get a lot of
>         satisfaction from finding elegant, robust and user
>         friendly solutions to new problems.  But, in the context
>         of povray, the mere suggestion of some kind of paradigm
>         shift seems to upset people very quickly.

   If you take into consideration the 1000's of people that have tens of
1000's of hours vested in this program I think it is entirely acceptable
that they would question radical change.
 

>         If there are other people who find these
>         possibilities attractive, I would be interested
>         in developing a more detailed proposal.  Some
>         aspects would require interaction with the
>         POV team, or the TAG people - but I think it's
>         fair to present them with more than a
>         "we think XML is funky idea" or have them
>         sift through threads of conceptual development
>         and hysterical backlash.


  Speaking as a TAG member I will offer this advice. If you can get other
people excited about your ideas, and between you draft a concrete proposal,
I would be happy to present it to the POV-Team on your behalf for their
consideration. It would really help if you could figure out a way to make
all of us understand the ramifications of your proposal, and get us excited
about it, but if you are sure it has merit I/we will not stand in your way.

What you need to bring to the table -

1. Detail your proposal as far as functionality and purpose.

2. Describe in detail what advantages your proposal has over the current
   system.

3. Who benefits from the changes or additions of your proposal.

4. Try to give some indication of how difficult it will be to implement
   and what kind of language support will be needed to make it portable
   to all platforms that POV-Ray currently supports.


  Remember that if you cannont get other people here excited about your
proposal there is little likelihood the POV-Team will get excited about
it. Also remember that timing may be everything. Right now the POV-Team
is actively working on finalizing the release of POV-Ray v3.5 which for
all intents and purposes should be considered feature locked at this time.
This means from the POV-Team's point of view any action they might take
towards your proposal will have to wait for their planned C++ re-write
for POV-Ray v4.0. As far as I know the POV-Team has not entered into
any detailed discussions on what changes will be made in v4.0, other
than the move to C++, and it is likely they will want to have their own
data structure decided before accepting additional suggestions in this
regard. Their internal discussions will likely be sometime down the
road when the release of POV-Ray v3.5 has been made public and they have
had a chance to hammer the public reported bugs out of it.


Keep this in mind...

What you are proposing may actually be better suited for a dedicated
patch of the program rather than something the mainstream POV-Ray user
will be interested in having in the official version of the program.


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

> What you need to bring to the table -
> 
> 1. Detail your proposal as far as functionality and purpose.
> 
> 2. Describe in detail what advantages your proposal has over the current
>    system.
> 
> 3. Who benefits from the changes or additions of your proposal.
> 
> 4. Try to give some indication of how difficult it will be to implement
>    and what kind of language support will be needed to make it portable
>    to all platforms that POV-Ray currently supports.

Ken,

Thanks for the advice, and clarifying the roadmap for the POV team.
I don't see any point in rushing this into 3.5. 

I would much rather talk about "THE XML PROPOSAL FOR POV" than
"MY XML PROPOSAL". :-)

Nigel

--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.

Post a reply to this message

Nigel Stewart wrote:

> I would much rather talk about "THE XML PROPOSAL FOR POV" than
> "MY XML PROPOSAL". :-)

 I meant a collective "your proposal" assuming you get others involved
with the project.

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

<AMUSED>
See, we're all getting the idea of tags now, arn't we?
</AMUSED>

> > <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>
> 
> <PANIC> Shoot the horse ! Shoot the horse ! </PANIC>

--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.

Post a reply to this message

Nigel Stewart wrote:
> 
> <AMUSED>
> See, we're all getting the idea of tags now, arn't we?
> </AMUSED>

statement { I felt really dirty while doing it. }

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

On Tue, 14 Mar 2000 00:45:19 -0500, Glen Berry wrote:
>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.

Thanks for your input, but if I had to live by those rules I never would
have released the superpatch into the wild and people would still be 
complaining about how many different patches there are.  Programmers do not 
make good writers, and vice versa.  Ideally, someone would volunteer to fix 
the docs and make insert-menu stuff and create example scene files, but all 
y'all do is bitch about how much better *we* could do.  Small wonder I 
stopped doing the superpatch, eh?

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

I'm one of those who proposed plugins before I was a member of the team.  
As I understand it, the idea was seriously discussed and ultimately
rejected because of cross-platform compatibility issues.  Perhaps after
the next round of changes (which I can't discuss now) some of those issues
will go away, but I can almost guarantee that someone, somewhere, will be
so upset by those ultimately useful changes that they'll organize a jihad.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

On 13 Mar 2000 03:56:42 -0500, Nieminen Juha wrote:
>Matt Giwer <jul### [at] ijnet> wrote:
>: 	Everything in computing can be done with the minimalist set of
>: micro-code which actually gets down to four or five instructions
>: depending upon your side in the debate
>
>  Actually 2 instructions are enough.

I once read that you could build a computer with just one instruction.
IIRC, the mnemonic was "decrement and jump if not zero" or something 
like that.  Obviously not the most efficient computer out there, though
(and with only one instruction, you don't need an opcode.  The code IS
the data.)

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

> <POVSCENE>
>   <SPHERE>
>     <POSITION> 0,0,0 </POSITION>
>     <RADIUS>   1.0   </RADIUS>
>     <PIGMENT>
>       <COLOR> BLUE </COLOR>
>     </PIGMENT>
>     <TRANSLATE> -0.5*x </TRANSLATE>
>   </SPHERE>
> </POVSCENE>


No, please.
I like to be able to use a simple text editor to write pov-script. This
POV-XML is just too long, too heavy, too difficult to read and more prone to
typo. And I find it to be un-aesthetic.
Didn't we discuss this issue already? Do you have new arguments?


Povingly,


Philippe

Post a reply to this message

Reluctantly, I will write here some of my thoughts on this polemical
subject. Reluctantly because I have little time, and because I now my
thoughts are far from being mature. Little time also means I did not read
(yet) all the messages in this thread, so I may address points that were
already discussed and "closed". But, please, bear with me, for I feel an
obligation to share my opinion.

Firstly, it seems that this discussion about POV's syntax, present and
future, quickly and repeatedly becomes a discussion about POV features and
wish lists. Many seem to address language/feature additions rather than
syntax changes. While these features additions would result in more keywords
and a few more syntax forms, most of the time they would not produce real
syntactic changes. To the non-programmer user, like I am, an OO style
camera.location is not different from a camera_location variable (but I
understand MyDeclaredObject.min_extent too).

I think POV syntax to be reasonably "good" as it is now. Reasonably because
it exhibits some incoherence. Some come from POV's history (evolution);
others come from different people implementing analogous functions in
different features. Some are, I believe, incoherence only to the
non-programmer, like shadowless and no_shadow. I believe reducing some of
these incoherences can make POV easier to learn and use. I'll throw in some
examples: - shadowless and no_shadow - I'd like all #declare to accept; as
an ending - the use of the comma in different statements could be unified -
texture is where I think POV _should_ have a syntax rewrite. Two examples
(my main concerns, actually): (1) the current implementation use many
different keywords for really similar functions - think of all the *_map;
(2) layering should be explicit, something like texture{layered{texture{T1},
texture{T2. or pigment{layered{.

As you have now surely understood, my only real "dissatisfaction" (quote,
because this word is too strong) in POV's syntax is its lack of unity... I
do not mean that I'd like its _looseness_ to be reduced: it is great to be
able to describe the same thing in different ways and each can choose its
favourite. I mean: I would like if each of these different syntax forms
could be used for every analogous task - and not, as it often is now, have
many features have its own syntax.

As to new features in the syntax, I would accept most gladly.

The for{,,} loop would surely be easier to use than the #while one, but then
I would like to see a while{,} and a #for.#end syntax. Access to object
information would be great, whether it is done with OO-style
MyObect.trace(.) or any other practical way. += style declaration would be
really useful. So would be better variable scoping. Generalisation of the
texture/pattern/function/isoshapes syntax could be really great, but
currently I can see no way of doing this without (1) loosing backward
compatibility (other than the #version switch) and (2) moving up to another
level of abstraction, making things more difficult to the newcomer.

New feature in POV I will always welcome warmly...



Now, I have done my duty, I feel at rest.


Povingly,


Philippe

Post a reply to this message

In article <chrishuff_99-470E46.16512213032000@news.povray.org>, Chris 
Huff <chr### [at] yahoocom> wrote:
>Maybe leaves?

True. Leaves would be a special child in the simple form; if the ifs 
object has three children, each end would get three leaves with the same 
angle changes as any other child. There would have to be a point 
(probably <0,0,0>) that is considered the 'base' of the leaf object.

ifs {
   ....
   leaf { predefinedObject }
}

>This looks rather interesting and quite powerful, although I didn't 
>understand all of it. Several of the features I wouldn't know how to 
>do(well, actually, I don't know how to add any kind of object), any 
>volunteers? :-)

I keep meaning to put my fractal macros on a web page. However, they are 
slow and memory heavy. And I don't personally understand all of the 
mathematics in them :*)

Jerry

Post a reply to this message

Glen Berry <7no### [at] ezwvcom> wrote:
: 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.

  I think that the proposition was to bind a keyboard shortcut for the
task. This is highly system-dependant.

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

On 14 Mar 2000 08:36:03 -0500, ron### [at] povrayorg (Ron Parker)
wrote:

>On Tue, 14 Mar 2000 00:45:19 -0500, Glen Berry wrote:
>>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.
>
>Thanks for your input, but if I had to live by those rules I never would
>have released the superpatch into the wild and people would still be 
>complaining about how many different patches there are.  Programmers do not 
>make good writers, and vice versa.  Ideally, someone would volunteer to fix 
>the docs and make insert-menu stuff and create example scene files, but all 
>y'all do is bitch about how much better *we* could do.  Small wonder I 
>stopped doing the superpatch, eh?

Now Ron, did I bitch about you or any other patch writer? All I am
saying is that these things should get done. I don't care if the
original author does them, or someone else. One way or another, it
would be good to achieve this. Heck, I'll probably write some insert
menu stuff myself. Whatever I do write, I will share with everyone.

>I'm one of those who proposed plugins before I was a member of the team.  
>As I understand it, the idea was seriously discussed and ultimately
>rejected because of cross-platform compatibility issues.  Perhaps after
>the next round of changes (which I can't discuss now) some of those issues
>will go away, but I can almost guarantee that someone, somewhere, will be
>so upset by those ultimately useful changes that they'll organize a jihad.

I hope not. Holy wars are the most senseless of wars.

Later,
Glen Berry

Post a reply to this message

<Nigel Stewart>
   <AMUSED>
     See, we're all getting the idea of tags now, arn't we?
   </AMUSED>
</Nigel Stewart>

<KEN>
  I felt really dirty while doing it. 
</KEN>

<GLEN>
  <HUMOR>
    Come on, we know you really liked it.
  </HUMOR>
</GLEN>

Post a reply to this message

Nieminen Juha wrote:
> 
> Mark Wagner <mar### [at] gtenet> wrote:
> : #do
> :   /* Do something */
> :   #if(1 = 2)
> :     #until(a = 3)
> :   #end
> 
> : or
> 
> : #do
> :   /* Do something */
> :   #if(1 = 1)
> :     #until(a = 3)
> :   #end
> 
>   Both of those should issue an error.
> 

True, both are non nested blocks.

PoD.

Post a reply to this message

Jerry wrote:
> 
> In article <38CC002C.6DBE9012@merlin.net.au>, PoD <pod### [at] merlinnetau>
> wrote:
> >Show me a simple syntax that lets you create a tree with different
> >textures for trunk, branches, twigs, leaves, fruit, flowers.
> >And has declarations of objects to use for the above.
> 
> Well, I'd separate out a simple IFS from full-blown LSystem, since it
> ought to be easier (and happens to be what I'm interested in :*)

Ok, I did say trees rather than L-Systems.

> 
> #declare deadSeed = seed(99);
> #declare tree = ifs {
>    children 3 //number of children that bloom from each 'branch'
>    angles {
>       <30,0,0>, <0,60,60>, <0,30,0>
>    }  //angle change for each child
>    sizes {
>       <.8,.75,.75>, <.6,1,1>, <.5,.5,.5>
>    }  //size change for each child

  Distances?
  Here, all children go at the end of the parent, I assume.
  Hm. yeah you can do it that way if a continuation of the branch is a
special child.

>    deadends {
>       deadSeed
>       .1,.05,.05
>    }  //chance of a dead end for each iteration, as well as the
>       //seed to use for randomness
>    levels 5
>    level_map {
>       [1-2  texture { trunknbranches }]
>       [3    texture { greentrees }]
>       [4    texture { greenleaves }]
>       [5    texture { flowers }]
>    } //might also use a 0-1 range

  I think these need to be objects rather than textures.

>    method dot_approximation //I've forgotten the name of this

  Not sure what you mean here.

>    //other method would be to draw every piece
>    turbulence .25
>    //turbulence might not be the right keyword; might have to
>    //be separated into 'angle_turb' and 'size_turb'.

  Probably should be per-level.

>    //some items might not be able to be applied to some methods
>    //also, a completely separate 'flower' object might not be a bad idea:
>    //flower { object { treeFlower } }
>    //which goes on the end of any branch that makes it to the top level
> }
> 
> Have I forgotten any necessary information?
> 
> Jerry

Sounds like it probably should be called tree{} rather than ifs{}
though.
Some other things.
Leaves tend to all be at the same angle to the ground (except in plants
where they're not), so you'd have to be able to specify that.  Same for
flowers.

PoD.

Post a reply to this message

Nigel Stewart wrote:
> 
> > I think if this replaced POV-Script, people would go to other things
> > instead, and if it was an option along with POV-Script, very few
> > people would use it(even modellers would probably output in
> > POV-Script for file size reasons).
> 
> Hmmm...
> 
> A consistently negative reaction...
> An idea before it's time?
> Or a community behind the times?
> 

XML defined languages are for ease of computer parsing, not for ease of
human writing/reading, though they are human readable since they're
plain text.

Also XML is for markup languages. OK for modeller output, not so good
for POV.
I don't think loops, macros etc. work well in XML.

PoD.

Post a reply to this message

Nigel Stewart wrote:
> 
>         Not at all, you seem to get the impression that this is
>         a new language - it's not.  It's simply POV Script in an
>         XML form.  There are two issues here - (1) the data model,
>         and (2) the way you encode it in ASCII.  I am really only
>         referring to (2).  The whole point of XML is to allow you
>         to manage the data model more effectively - but it doesn't
>         mean that you throw away your existing data model to use XML.
> 

POV script is very free-form, to be defined by XML, your language would
have to do away with that.
The freedom of the POV language is what makes it hard to parse, not the
fact that it uses
 statement{ val }
rather than
 <statement>
   <arg1> val </arg1>
 </statement>

PoD.

Post a reply to this message

> POV script is very free-form, to be defined by XML, your language would
> have to do away with that.

	No, I don't think so.  Please explain why you think this.

--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.

Post a reply to this message

In article <As3NOAOBs+Ru55ANkKtFBbwnSUuI@4ax.com>, Glen Berry 
<7no### [at] ezwvcom> wrote:

> Poor design choices haven't stopped it yet.    :)
> 
> ...and yes, there *have* been at least a few poor design choices.

But none of them made the program unuseable without anything the user 
hadn't already been using.


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

Yes, if there was something that could actually be tested and put to 
use, that would be good. Maybe a translator program, something like 
C-SDL?

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <D5TNOASIAvcmq=v7ZHjaH6KAifJl@4ax.com>, Glen Berry 
<7no### [at] ezwvcom> 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? 

Bob Hughes. He mentioned that auto-completion would be a "nifty feature" 
in the Codemax editor, which as far as I know is Windows only. My point 
is that auto-completion is an editor-dependant feature, and thus 
platform dependant, and so it is a bad substitute for a language 
feature.(which would be completely platform independant)


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

Just because a program handles ASCII files doesn't mean it doesn't have 
a platform-specific interface. Writing for the Mac GUI is quite 
different from writing for the Windows GUI. The only way to get 
something consistant and which wouldn't have to be rewritten every time 
would be to use Java, which some people wouldn't like.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

On Tue, 14 Mar 2000, Ken wrote:

> 
> 
> Nigel Stewart wrote:
> > 
> > <AMUSED>
> > See, we're all getting the idea of tags now, arn't we?
> > </AMUSED>
> 
> statement { I felt really dirty while doing it. }

statement { I have no idea what this whole discussion is about } ;)

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

cre### [at] belialrenonvus wrote:

> statement { I have no idea what this whole discussion is about } ;)

Comic relief ?

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

In article <38CE3356.F0445117@nigels.com>, nig### [at] eisanetau wrote:

> > >       Yes, but once in POV script, you can't do anything else
> > >       with it.
> > 
> > I really don't know what you mean by that...
> 
> 	I mean that once data is stored in POV format,
> 	it is trapped there. 

I understand what you were trying to say now, but I still don't see why 
it is a problem. If the program already has the data, why does it need 
to read it back?
And besides, you can always use a plain comma delimited text file to 
store the data, and use macros or an include written in POV-Script to 
read it. I have used this approach for my particle simulator, outputting 
a bunch of calls to a macro to make particles, and it is quite flexible 
and powerful.(and makes smaller files)


> Worse than that, it may not 	even be compatible with the next version 
> of POV.

One of the biggest nice things about POV is that it is backward 
compatable to a high degree. Recently there have been changes, and there 
will probably be bigger changes in the future, but the basic object 
syntax hasn't changed much.


> > >       Programmers are quite familiar with the strengths and
> > >       weaknesses of using flat text.  
> > But is it actually limiting? I don't feel very limited...
> 
> 	Yes it is.  I spent all afternoon staring at C++ code
> 	wondering why there is no facility to have graphical
> 	documentation embedded in the source code.  I do
> 	graphics programming, and the geometric result of
> 	code is not always obvious from the C++ code.  Why
> 	can't I extend the C++ file format to stick anything
> 	in there that is relevant?  Why can't I rename the
> 	member "A::doXYZ()" without doing a search and replace?

Maybe you should have spent that afternoon figuring out the code 
instead. (just kidding!) :-)
Honestly, I haven't had much trouble with that. And graphical 
documentation embedded in the source code? The source would no longer be 
ASCII, would it?
I really don't think many people "program" in ASCII, but in structural 
concepts and operations which they translate into a language format. 
Some concepts and operations translate better to a visual format, at 
least for some people. I tend to visualize things as a bunch of 
interlinked structures, not code, but I don't think I would be able to 
make much sense from a non-code representation of that on the screen.


> 	Why can't I get an instant list of all everywhere that
> 	a certain variable is modified, or a function called?
> 	The compiler figures out all this information but 
> 	doesn't use it for useful things.  C++ programmers
> 	are trapped all day in this klunky ASCII view of
> 	their problem.  

Why would you need to? If it is for writing/modifying code, that belongs 
as an editor feature.(CodeWarrior can automatically find definitions of 
variables and types for me, and also supports fairly advanced 
search/replace features)


> 	I'm sure that some punch-card users didn't feel
> 	very limited either.  I used to think Commodore
> 	Basic was pretty cool.  Then machine language,
> 	then C, then C++.  You don't really see the 	
> 	limitations until you are freed from them.

But you can try to explain the limitations to the people who don't see 
or feel them...(hint)


> > >       Pascal and C are nearly equivalent languages. 
> > But they are separate languages. 
> 
> 	They are referred to as separate language, but
> 	they are actually so similar that it may be better
> 	to refer to them as "dialects of procedural programming".

You mean like Chinese and Australian Aborigine are different "dialects 
of human language"?
They are both a certain type of computer language, but they are 
certainly separate languages. By my definition, anyway.


> > The problem is that it is too generic, it can't be hand-edited easily.
> > Special tools are required.
> 
> 	Special tools are required for editing text too.
> 	You need a computer, monitor, keyboard and
> 	text editing program.  Are you taking all this
> 	technology for granted?  It must be working well!

Yes, it works quite well. :-)
My point was that text editors are practically universal, and everyone 
knows how to use them. XML editors are not as universal, and many people 
don't know anything about them.(like me)
If people are using POV, it is a very safe assumption that they have and 
know how to use a text editor(and a computer, monitor, keyboard, etc). 
The same does not apply for XML.


> > I don't understand this "flexibility" argument, at some point it has to
> > be converted into data structures in RAM. The only thing that would make
> > adding features easier would be the universal syntax, and that could be
> > done in other ways just as well.
> 
> 	Why would you do it in "other ways"?   You think
> 	you know better?  Do you think XML is some gimmick
> 	that Microsoft cooked up to make you upgrade all
> 	of your software?  Find out more about XML,
> 	at the very least it will improve your ability
> 	to argue against it. :-)

Huh? Did I mention Microsoft?
I don't think XML is a "gimmick", I just don't think it is the right 
thing for POV-Ray. If you can demonstrate how it would be the "right 
thing" for scene description with POV-Ray and how it would be noticeably 
more flexible and useable than the alternatives(redoing the language to 
be more clean and consistant, for example), and I will believe you. 
Right now, all you have shown me is some extremely ugly and difficult to 
read syntax, which you apparently want to use as a file format for 
specialized editors instead of a description language.

And you still haven't explained how this gets the data into RAM in an 
easier way than making modifications to a well-written parser would.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Ken wrote:
> 
> Greetings,
> 
8< snip
> 
> So the questions I have are really for the non-programmer types out there.
> 
> Would you have difficulty re-learning POV-Ray if it's language format
> changed ?
> 
> Would you resent it or maybe even quit using the program completely ?

I find it extremely hard to locate the threads among all these messages
that interest me.

Please change the subject field when the discussion starts to branch off 
to another subject. 

(On other news groups I have seen use of the keyword WAS in the subject 
field but I am not sure of how this works.)

Regards

Tor Olav

-- 
mailto:tor### [at] hotmailcom
http://www.crosswinds.net/~tok/tokrays.html

Post a reply to this message

On Tue, 14 Mar 2000, Ken wrote:

> 
> 
> cre### [at] belialrenonvus wrote:
> 
> > statement { I have no idea what this whole discussion is about } ;)
> 
> Comic relief ?

You betcha! :)
 
> -- 
> 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

Tor Olav Kristensen wrote:

> I find it extremely hard to locate the threads among all these messages
> that interest me.
> 
> Please change the subject field when the discussion starts to branch off
> to another subject.
> 
> (On other news groups I have seen use of the keyword WAS in the subject
> field but I am not sure of how this works.)

As a long time visitor to these groups I would have to say that for the
most part this is the longest on topic thread in the history of this
news server. Usualy when it goes off topic it goes WAY off topic. For
example some long threads start out talking about POV-Ray and talking
about gun control. However I feel just about every message posted to
this thread so far has in some way been related to the topic I started
with. So far I have been very happy with the progress of this thread
even though I do not necessarily agree with everyone else's views on
the subject. In direct response to your comments we have already seen
three new threads start as a result of it which are as you suggest sub
topic discussions.

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

Hi Ken

Ken wrote:
> 
> Tor Olav Kristensen wrote:
> 
> > I find it extremely hard to locate the threads among all these messages
> > that interest me.
> >
> > Please change the subject field when the discussion starts to branch off
> > to another subject.
> >
> > (On other news groups I have seen use of the keyword WAS in the subject
> > field but I am not sure of how this works.)
> 
> As a long time visitor to these groups I would have to say that for the
> most part this is the longest on topic thread in the history of this
> news server. Usualy when it goes off topic it goes WAY off topic. For
> example some long threads start out talking about POV-Ray and talking
> about gun control. However I feel just about every message posted to
> this thread so far has in some way been related to the topic I started
> with. 

OK, I had not read them all, so I was not sure. But some of those I 
read was rather "sub-topic" (as you call them).

> So far I have been very happy with the progress of this thread

I agree: Many interesting opinions!

> even though I do not necessarily agree with everyone else's views on
> the subject. 

I wasn't trying to say that I disagreed with anyone. I rather felt
helpless about not knowing the (sub-)subject" of all these postings.

One way for me to find out would be to read them all, but 
unfortunately I do not have enough time for that.

> In direct response to your comments we have already seen
> three new threads start as a result of it which are as you suggest sub
> topic discussions.

Wouldn't it bee an idea to add the sub-topic at the end of the 
original subject (like I did)?

Or would this cause problems with some news-readers?

Regards

Tor Olav

-- 
mailto:tor### [at] hotmailcom
http://www.crosswinds.net/~tok/tokrays.html

Post a reply to this message

On Tue, 14 Mar 2000 01:03:08 -0800 Ken <tyl### [at] pacbellnet> wrote:

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

  A good practice that I follow with my own scenes when using nested
conditional statements. Probably of even more benefit to someone else
who may want to look at the scene code I've written (a hypothetical
example but entirely possible <s>).

-- 
Alan - ako### [at] povrayorg - a k o n g <at> p o v r a y <dot> o r g
http://www.povray.org - Home of the Persistence of Vision Ray Tracer

Post a reply to this message

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

AFAIK, the C-like for-loop that would be added to POV would not have any
limitations in this respect. The way I see it, the syntax would be as
follows:

#for (Counter has an initial value established*, Condition to exit**,
Step***)
 Stuff to do...
#end

*example: I=0, I=100, etc.
**example: I<5, I>3, I=3, etc.
***example: I++, I--, I+3, etc.

Post a reply to this message

TonyB <ben### [at] panamac-comnet> wrote:
: #for (Counter has an initial value established*, Condition to exit**,
: Step***)

  No, no.

#for(Identifier initialization; Condition to _continue_; Identifier modification)

: ***example: I++, I--, I+3, etc.

  ++ and -- are just too difficult to implement. I+=1 would be it.

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

> >       I mean that once data is stored in POV format,
> >       it is trapped there.
> 
> I understand what you were trying to say now, but I still don't see why
> it is a problem. If the program already has the data, why does it need
> to read it back?

This solution:
	Implement a custom file format in ASCII, that only your util
	and your POV macros can understand.  What happens when I feel
	like shifting this same data to Autocad?  Or into my own
	CAD/CAM software?  Write more code to emit a different format?
	Is is not my idea of efficient software development.

XML solution:
	Use a format that is standard, flexible, extensible, and that
	other applications have a decent chance of importing.
	
> And besides, you can always use a plain comma delimited text file to
> store the data, and use macros or an include written in POV-Script to
> read it. 

	That sounds absolutely archaic, honestly.

> I really don't think many people "program" in ASCII, but in structural
> concepts and operations which they translate into a language format.

	At the end of the day, the docco and the source is all
	that other people have to refer to.  I would like to have
	the flexibility to add comments which are only visible to
	me, backups of old implementations of a routine, and even
	copies of email, or relevant URL's that serve as a reference.
	Plain old text editing won't cut it.  In some places, I'd
	like to be able to paste VRML examples of special cases,
	or sample output.  Try doing that in a text editor.

> but I don't think I would be able to
> make much sense from a non-code representation of that on the screen.

	So, UML was invented purely as an academic pastime?
	Diagramming packages like Rational Rose were invented
	as some kind of toy?  I've used a HTML documentation
	generator, that converts from C++ sources to nice hyper-linked
	reference documentation.  (Can't remember the name of it)
	It struck me that this was a far superior way to browse the
	source than the clunky stuff in Visual C++, or sifting through
	the files manually.  The only limitation - I can't edit in 
	this environment.  But I want to - desperately.

> Why would you need to? 

	Because I've got better things to do than manually search
	for information, figure out dependencies, track the use
	of variables, or accurately rename all references to a 
	particular function or variable.

> If it is for writing/modifying code, that belongs
> as an editor feature.

	No, it doesn't.  It is related to pre-processing, compiling and
	even linker issues.  Thinking of this only in terms of
	editing is half-baked.

> But you can try to explain the limitations to the people who don't see
> or feel them...(hint)

	I've explained plenty, to you at least.  I do not
	get any impression that you're going away to do
	any homework for yourself.  I am not going to 
	dedicate my life to making every implication
	totally obvious to you.

> >       They are referred to as separate language, but
> >       they are actually so similar that it may be better
> >       to refer to them as "dialects of procedural programming".
> 
> You mean like Chinese and Australian Aborigine are different 
> "dialects of human language"?

	Human languages are much richer than computer languages.
	I think it is a fair stretch to draw comparisons like this.
	The underlying theories in C and Pascal are roughly
	equivalent, whereas the protocols and nuances of meaning
	I would expect to be completely different between Chinese
	and Aborigine.

> My point was that text editors are practically universal, and everyone
> knows how to use them. XML editors are not as universal, and many people
> don't know anything about them.(like me)

	Then learn something. 

> If people are using POV, it is a very safe assumption that they have and
> know how to use a text editor(and a computer, monitor, keyboard, etc).
> The same does not apply for XML.

	As I have said more than once, I have no opposition to
	POV script as it stands.  However, it can not be
	"all things to all people".  This "lowest common 
	denominator" philosophy shouldn't be taken to
	extremes.  I expect that XML based editing will become
	quite common - and most of the time, people won't realise
	they're doing it.  Anytime you enter data on a webpage,
	there is a good chance that there is XML interfacing to
	the database.  

> I don't think XML is a "gimmick", I just don't think it is the right
> thing for POV-Ray. 

	You don't know enough to make this claim, or make this
	judgement.  
	
> If you can demonstrate how it would be the "right
> thing" 

	I've proposed a working group to develop the concept.
	"Conceptual Development" is a normal process which works
	best if it involves many people.  However, it is not
	my intention to crusade for XML.   (Although I suspect
	that nothing would ever be enough to satisfy you)
	POVray is not the only raytracer in town, after all.

> how it would be noticeably more flexible and useable than the 
> alternatives

	A XML based format for POV would be more flexible and
	useable simply because of XML.  It's not optimised for
	hand editing, but frankly that isn't important all
	of the time.

> And you still haven't explained how this gets the data into RAM in an
> easier way than making modifications to a well-written parser would.

	There is no need to me to explain the basic functioning 
	of an XML parser.  I highly recommend it to you as a homework
	problem - I think it would help you understand why programmers
	are no longer interested in "well-written parsers", they are
	interested in getting the parser off the shelf, and focusing
	on the real problems.

--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.

Post a reply to this message

>  No, no.
>
>#for(Identifier initialization; Condition to _continue_; Identifier
modification)


I haven't written C in a *long* time. It's a miracle I came that close.

>  ++ and -- are just too difficult to implement. I+=1 would be it.


I just heard. I posted before reading that. The latter sounds fine.

Post a reply to this message