 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38CE3356.F0445117@nigels.com>, nig### [at] eisa netau 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
|
|
| |
| |
|
|
From: Tor Olav Kristensen
Subject: Re: The Language of POV-Ray: Aren't some these 200++ postings "off-subject" ???
Date: 14 Mar 2000 18:25:55
Message: <38CEC987.18997AD9@online.no>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Ken
Subject: Re: The Language of POV-Ray: Aren't some these 200++ postings "off-subject" ???
Date: 14 Mar 2000 19:12:57
Message: <38CED604.34585E92@pacbell.net>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Tor Olav Kristensen
Subject: Re: The Language of POV-Ray: Aren't some these 200++ postings "off-subject" ???
Date: 14 Mar 2000 19:39:42
Message: <38CEDAD3.FDBF3F95@online.no>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
