 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 13 Mar 2000 07:16:50 -0500, Chris Huff
<chr### [at] yahoo com> 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
|
|
| |
| |
|
|
|
|
| |
|
|
