 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] nigels com)
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
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Juha wrote:
>
> 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.
Or make it like C really is:
#for (whatever initialization you want;
condition to continue;
whatever update you want)
#end
(It can all be on one line, I split it up here for line length)
Since it doesn't really grant any more functionality than the current
state of affairs, I'm of the belief that the POV-team has bigger fish
to fry.
--
ICQ: 46085459
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David Fontaine wrote:
>
> Tor Olav Kristensen wrote:
>
> > People can press whatever keys they like.
> >
> > So if you preferred not to hit that function key, then the computer
> > wouldn't modify your work...
>
> Okay, but what about 1, 2 and 3a? :-p
I see that I have to agree with you on those :-q
...But I have a tiny but...
With a mouse one can do copy and paste of long expressions
quite fast. But for systems without a pointing device I see
that the problem could cause a lot of keyboard hammering.
--
mailto:tor### [at] hotmailcom
http://www.crosswinds.net/~tok/tokrays.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nigel Stewart wrote:
>
> > : 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.
for j = 1 to 10 step 1
for i = 1 to 10 step 1
if (i = 4) and (j = 2) and keypressed(E or e) then i = 2 and j =
4
next i
next j
--
A free internet for a free people.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Glen Berry wrote:
>
> 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.
1 .. 99 initialization
100 for infinity = 1 to 2 step 0
stuff
10000 next infinity
Which seems like a bit of a waste but some BASICs like Atari and
I think Palo Alto tiny BASIC (if a tokenized implementation)
would put a pointer to the beginning of the loop. That made the
execution of stuff faster than not having a loop and having the
last line GOTO 100.
--
A free internet for a free people.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
> Still, my first point was a platform specific editor feature is no
> substitute for a language feature.
What is a platform specific editor? And why care as this is
source code discussion? OK, you don't have a control key you
can't do ^esdx but that is a separater issue. I know of no editor
insisting upon an alt key that produced plain ascii output. If
you are trying to make MS Word your code editor ...
--
A free internet for a free people.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Juha wrote:
> I think that the proposition was to bind a keyboard shortcut for the
> task. This is highly system-dependant.
That is not a language issue. That is an editor issue. Anyone
interested in that sort of thing, even Windows has free editors
that will do such things. And they will invoke POV.
--
A free internet for a free people.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
> 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)
Which HAS TO BE platform independent else parser variations
where they are totally unnecessary. And platform dependent
parsers ... there is no reason for that in POV I can see. And
then where would cross compilers be if source were not identical?
Even in the "WordStar as editor" days ^kr <insert name of
favorite template, macro or whatever> worked just fine. A little
batch code that invoked it with the source and then invoked the
compiler to the source and then ran was trivial. Borland and a
few other IDEs just made it simpler overall.
> 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.
That is talking about not just the editor but the editor
environment.
If that really turns someone on, they can write it and make it
public. That will have no effect upon the POV source.
--
A free internet for a free people.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tor Olav Kristensen wrote:
> I see that I have to agree with you on those :-q
> ...But I have a tiny but...
> With a mouse one can do copy and paste of long expressions
> quite fast. But for systems without a pointing device I see
> that the problem could cause a lot of keyboard hammering.
Even in the oldest ^KB scroll ^KK scroll ^KC to copy and the
last ^KV to move. What carefully and note my hands never leave
the keyboard.
With a rat, click and move till hilited the ^C or ^X and then
move the rat again and ^V. Note very carefully my hands had to
leave the keyboard.
A lot of banging? Ain't no real difference in the time required.
Now if you have combinations of rat buttons programmed to avoid
going to the keyboard at all, I'll take that as over all faster.
And if this sort of thing consumes a significant amount of your
coding time, Te Salud!
--
A free internet for a free people.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
>
> 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.
Will do.
> The for loop is well defined, POV would use the existing definition,
> which is quite possible with the POV syntax.
for i = 1 to 5
stuff(variables used elsewhere)
next i
Is i ?= 5 evaluated before or after stuff? If before stuff is
evaluated 5 times. If after stuff is evaluated 6 times. In the
latter case the stuff variables have the value of i = 6.
But if the syntax is
for i = 1 to 5 inc 1
stuff
#endfor
pre-evaluation is implied but still may not be implemented that
way.
If you are writing the parser you have to decide these things
and document them. And you have to set up a tokenized first pass
that finds the next i (and bails out on i=5) rather than waiting
for it. If you wait for it you have to store the current and
previous stuff and when finding i = 5 throw away the current and
copy previous to the variables or some scheme like that.
> 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 lack of typing is a weakness that C folks love. (I will get
around to testing it some day but I think I have seen a problem
with #decare i = 1 and #declare i = 1.0 that has solved a loop
problem. I won't swear to it.) But if all variables are
automatically signed four bytes then it is not an efficient
engine.
> The ++ and -- operators would not fit in the current syntax of POV,
> so you can forget about them.
I have no problem with those than inc and dec. But is it going
to be int + 1 or float + 1? But since it is not a typed language
again all the clarity of C and Forth is possible.
> > 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...
There is an old saying, "All things are simple to those who do
not have to do it themselves." I am of the KISS school.
#local is required when folks jump out of loops and such.
Therefore it is a good option to have. But if folks just do a bit
of extra typing there i1 i2 i3 i4 there is no need for it.
Most of my issue has been on alternatives to #while. I gave an
example on for ... next as opposed to while. If the answer to for
... next is to make it behave the same was while, why is there a
need for for ... next?
There is an issue of clarity. Clarity to who? To the author?
Clarity and familiarity are identical.
Clarity to others? Axiom of programming. Uncommented code is
unclear to others. Axiom the second. Commented code is likely
unclear to others.
--
A free internet for a free people.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
PoD wrote:
> 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.
Good point. That's probably what it comes down to.
> 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.
Personally I think loops, macros, etc could easily be done in XML.
<LOOP start='0' end ='100' step ='1' index='x'>
....
</LOOP>
<MACRO>
<PARAM name='foo' default='bar'/>
<PARAM name='baz' default='7'/>
...
</MACRO>
But then again there could be many ways to do things.
--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nigel Stewart wrote in message <38CE3356.F0445117@nigels.com>...
> 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 don't you check out some of the capabilities of Microsoft Visual C++
1.0? It has all this information immediately available to the programmer.
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tor Olav Kristensen <tor### [at] hotmailcom> wrote:
: With a mouse one can do copy and paste of long expressions
: quite fast. But for systems without a pointing device I see
: that the problem could cause a lot of keyboard hammering.
To me it's often easier and faster to copypaste with the keyboard than
with the mouse. This is specially true when the zone to paint is larger
than the current screen.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> for j = 1 to 10 step 1
>
> for i = 1 to 10 step 1
>
> if (i = 4) and (j = 2) and keypressed(E or e) then i = 2 and j =
> 4
>
> next i
>
> next j
A nice example of obscure programming. However, computer
science is not about protecting programmers from their
own stupidity.
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Why don't you check out some of the capabilities of Microsoft Visual C++
> 1.0? It has all this information immediately available to the programmer.
Unfortunately, you get what Microsoft gives you - which isn't very
much. The advantage with meta data is that you choose, control and
configure and the tools that generate 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38D07115.B40CDB15@ij.net>, Matt Giwer <jul### [at] ijnet>
wrote:
> What is a platform specific editor?
SimpleText. Note Pad. The POV-Ray Mac editor. MPW. BBEdit. Need any more?
> And why care as this is source code discussion?
Because adding a += feature would require the modification of the source
code, would not be dependant on editor features, and would be completely
platform independant?
> OK, you don't have a control key you can't do ^esdx but that is a
> separater issue. I know of no editor insisting upon an alt key that
> produced plain ascii output. If you are trying to make MS Word your
> code editor ...
Huh? I don't really understand what your point is...
Those appear to be key combination commands...you do know that they vary
from editor to editor and not all are supported on many editors, don't
you?
I repeat, an editor feature is not a good substitute for a language
feature.
Oh, and Macs *do* have a control key. I have never seen a keyboard
without one(well, except for the old Tandy COCO II and Commodore 64, and
maybe the Apple IIe, which predated the Macintosh line). :-)
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38D07402.45F7A093@ij.net>, Matt Giwer <jul### [at] ijnet>
wrote:
> Which HAS TO BE platform independent else parser variations
> where they are totally unnecessary. And platform dependent
> parsers ... there is no reason for that in POV I can see. And
> then where would cross compilers be if source were not identical?
What? You seem to be arguing the same point I am...I never said the
parser would be platform dependant. I said:
> ... 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)
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38D07D01.441B3BE3@ij.net>, Matt Giwer <jul### [at] ijnet>
wrote:
> for i = 1 to 5
> ...
Wrong for loop. I suppose I should have said I meant C-like loop. Try:
#for(COUNTER INITIALIZATION; CONTINUE CONDITION; COUNTER MODIFICATION)
...
#end
This is well defined, and more flexible. And doesn't have the problems
you mention:
1: Initialization, which sets the initial state of the variable.
2: The test for the continue condition. If it evaluates as true, the
body of the loop is executed.
3: The counter modification. This can do something as simple as
incrementing the variable. Then you jump back to step 2.
> The lack of typing is a weakness that C folks love. (I will get
> around to testing it some day but I think I have seen a problem
> with #decare i = 1 and #declare i = 1.0 that has solved a loop
> problem. I won't swear to it.) But if all variables are
> automatically signed four bytes then it is not an efficient
> engine.
I don't think the lack of typing has ever caused an error for me, but it
does make it troublesome to read and write some code. One reason for the
C-SDL idea, my version of which would be more strongly typed than
POV-Script.
> > The ++ and -- operators would not fit in the current syntax of POV,
> > so you can forget about them.
>
> I have no problem with those than inc and dec. But is it going
> to be int + 1 or float + 1? But since it is not a typed language
> again all the clarity of C and Forth is possible.
It would be value + 1.
What would their syntax be? Remember that POV requires a #declare or
#local, changing this would mean changing the entire declaration syntax.
What I said was that adding them would be impossible *without changing
the declaration syntax*.
I would actually like to see the ability to modify existing variables
without using a special command, or at least with a specialized #set
command which would give an error for undeclared identifiers. I don't
know how likely this is to happen, though...
> > 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...
>
> There is an old saying, "All things are simple to those who do
> not have to do it themselves." I am of the KISS school.
> #local is required when folks jump out of loops and such.
But there is no need for loops, you could just use #goto! Keep it
simple, remember? Why have #switch, #macro, and #while when all you need
is #goto?
And no, I am not serious about this. I really do think adding #goto
would be a bad idea. I am just saying your argument against adding #for
loops("One simple routine that can do everything is quite good enough.")
doesn't make much sense.
> Most of my issue has been on alternatives to #while. I gave an
> example on for ... next as opposed to while. If the answer to for
> ... next is to make it behave the same was while, why is there a
> need for for ... next?
Well, first, it shouldn't be BASIC-style for...next, but more C-style
#for()...#end.
> There is an issue of clarity. Clarity to who? To the author?
> Clarity and familiarity are identical.
Clarity to the author and anyone who wants to read it.
> Clarity to others? Axiom of programming. Uncommented code is
> unclear to others. Axiom the second. Commented code is likely
> unclear to others.
What?
Uncommented code can be confusing if it isn't well written with
well-chosen variable names and a fairly simple structure.
Well commented code is almost always much more clear(except in the
simplest cases). I wouldn't have made much progress in the POV source
without the comments.(although most of the comments seem to be
incomplete/missing)
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 16 Mar 2000 16:33:23 -0500, Chris Huff
<chr### [at] yahoocom> wrote:
>Oh, and Macs *do* have a control key. I have never seen a keyboard
>without one(well, except for the old Tandy COCO II and Commodore 64, and
>maybe the Apple IIe, which predated the Macintosh line). :-)
The Apple IIe had a control key. It even had two functional keys (F1
and F2).
Peter Popov
pet### [at] usanet
ICQ: 15002700
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote in message ...
>Oh, and Macs *do* have a control key. I have never seen a keyboard
>without one(well, except for the old Tandy COCO II and Commodore 64, and
>maybe the Apple IIe, which predated the Macintosh line). :-)
I seem to recall the Commodore 64 having a "Control" (well, actually a
"CTRL") key.
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38d1f259$1@news.povray.org>, "Mark Wagner"
<mar### [at] gtenet> wrote:
> Chris Huff wrote in message ...
> >Oh, and Macs *do* have a control key. I have never seen a keyboard
> >without one(well, except for the old Tandy COCO II and Commodore 64, and
> >maybe the Apple IIe, which predated the Macintosh line). :-)
>
>
> I seem to recall the Commodore 64 having a "Control" (well, actually a
> "CTRL") key.
Hmm, I think you are right...and I think the Apple IIe had a "Control"
key.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
