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