 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Speaking of errors something else that will have to be address is
> error handling of erroneous input. If the user_prompt is looking for
> a specific input and a wrong value is entered there needs to be
> some form of error trapping to get the right value from the user.
That's a very good point, and I think the best way to
handle it is with some POV script code to do the range
or consistency checking. Ultimately - leave it up to
the script to handle it.
But, if you want a model that prompts you again
with a message that the input was out of range,
then you're back to the problems of the original
proposal.
I think that without this "second chance" it's
still a useful mechanism, and worth considering
seriously.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <GIHOOHWP57GVgbOx81s8aTSybt3d@4ax.com>, Glen Berry
> <7no### [at] ezwvcom> wrote:
>
> > I can't imagine how it would possibly take anything approaching 45
> > minutes to scan for the appearance of a few interactive keywords,
> > requiring user data input, in a POV scene file. If some are found,
> > the values would be entered at that time, before the "real" parsing
> > would begin. There should be no such thing as sitting in front of your
> > monitor for 45 minutes waiting to enter data into a scene that is
> > parsing.
#declare L=rand(Seed)*10;
#declare A = array[L];
#declare I=0; #while(I<L)
A[I] = user_input();
#declare I=I+1; #end
Yes, I've also read the bit about time-outs and default values.
This makes what would be fairly simple to do portably more problematic.
You now need a portable way to wait n seconds for user input, else
continue running.
The command line idea has the most promise, IMHO. Except then the
command line args need to match the variables in the script.
The most portable way would be to not change anything. Include a .inc
file which defines your variables, put a note in your script and maybe a
#debug to remind users to set the values.
PoD.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38CF8393.4C9C700B@nigels.com>, nig### [at] eisanetau wrote:
> The "base level interface" of POV has always been a command
> line with standard input and standard output available.
> I'm sure the Windows guys can supply you with a dialog box,
> and similarly for other non-text-terminal style incarnations
> could manage this very basic requirement.
You might be surprised to learn that the Mac version of POV does not
have an accessible command line. None. And the only text input is the
scene file and optionally an .ini file(usually, those preferences are
stored in the actual scene file, in the resource fork).
Maybe this will change in 3.5, though. And you theoretically could
compile a console version of POV...
> > it would just be too difficult to implement in POV-Script
>
> <disbelief> Huh? </disbelief>
<frusteration>I was referring to the problem of pre-parsing the scene to
keep from having long delays before input requests.</frusteration>
> > and impossible to implement in a cross-platform manner
>
> <amusement> Refer to ANSI C Standard: scanf(...) </amusement>
<incomprehension>Er, how would this help in putting up a dialog box and
getting user input from it?</incomprehension>
> > And then you have to write the dialog code for Mac and Windows
>
> No, you provide a hook with sensible default behaviour.
> (if there is no function pointer, don't prompt. Simple huh?)
There are output functions for warnings and errors, but I don't know if
there are input functions(there actually might be, maybe they just have
never been used). Adding them wouldn't be difficult, but it would
probably be a better idea to put everything into one standardized
interface during the conversion to C++. If you can add them in now, go
ahead!
> > This would be a nice feature, and probably something to think about for
> > POV 4.0
>
> <sarcasm>
> Ooooh.... That's an ambitous goal - a C++ port in order to
> support a prompt. Good thinking. Perhaps C++ would also
> help with "general solutions" that don't exist.
> </sarcasm>
<exasperation>Did I say this was the only reason to port to C++? No.
I meant this was a good thing to think about and plan for in the design
of 4.0.</exasperation>
> > but in the current state of POV is just not very
> > plausible. Another good addition to the wish-list, though.
>
> Wish list? I just about tempted to hack this into POV
> and post a binary just to prove you wrong. Let's see,
> one reserved word, two numerical parameters, a bit
> of cut-paste-and-edit. Sounds more than plausible.
Go ahead...don't forget to work out the problem of pre-parsing the scene
while you are at it. :-)
Actually, for now, a simple version of this feature which doesn't do
pre-parsing would probably be enough, as long as people design their
code carefully and include files don't require them(maybe a way to turn
this feature off for sections of code would be a good idea?
#user_prompts on/off in addition to the prompt_user() function?). The
function hook for the user prompt could also be hacked in. The
pre-parsing stuff could be added later, maybe in 4.0.
Or maybe the suggestion of having everything be put in a special block,
like global_settings, so everything has to be specified at the beginning
of the scene. This seems too rigid, though.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > <disbelief> Huh? </disbelief>
> <frusteration>I was referring to the problem of pre-parsing the scene to
> keep from having long delays before input requests.</frusteration>
<sympathethic> Fair Enough </sympathetic>
> > > and impossible to implement in a cross-platform manner
> > <amusement> Refer to ANSI C Standard: scanf(...) </amusement>
>
> <incomprehension>Er, how would this help in putting up a dialog box and
> getting user input from it?</incomprehension>
<rationalisation> In this sense MAC is not even ANSI standard,
so you are always up for GUI programming, no matter what you do.
</rationalisation>
> If you can add them in now, go ahead!
I think the "interface block" concept is the most promising
formulation that we have so far. It's something like
the main(..) function in C, you're only allowed to have one.
> This seems too rigid, though.
Perhaps a bit rigid, but still very useful. And it's not
an unreasonable solution to the problem. It certainly
beats editing POV script by hand.
--
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 <38D02C53.7176F1A8@nigels.com>, nig### [at] eisanetau wrote:
> I think the "interface block" concept is the most promising
> formulation that we have so far. It's something like
> the main(..) function in C, you're only allowed to have one.
>
> > This seems too rigid, though.
>
> Perhaps a bit rigid, but still very useful. And it's not
> an unreasonable solution to the problem. It certainly
> beats editing POV script by hand.
But if there can only be one in each scene, the only logical place would
be the main scene file. So you couldn't have the scene file request
values from the user...and you would still have to remember the variable
names.
I rather like the prompt_user() function idea, you would just have to
use it sparingly, make sure to put it in the right places(not in long
loops and not after long calculations, for example), and just generally
be careful with it, at least until support could be extended to support
pre-parsing operations.
If you really have a problem with remembering variable names and don't
want to use comments as a reminder, maybe you could put a list of
#declare's(with default values) of the variables in a separate include
file, make copies of that, and design the include file so it only takes
one variable-the name of the include file you want it to use for input.
You could just edit the values in a copy of the file, no need to
remember any names other than the one file name variable(and the name of
the main include file, but you would have to remember that one anyway.
:-) ).
// parameter file
...miscellaneous variable declarations...
...just make a copy of this file and modify as needed...
// end parameter file
// main include file
#ifndef(paramFile)
#declare paramFile = "defaultParams.inc"
#end
#include paramFile
...
// end main include file
// scene file
...you only have to remember this variable...
#declare paramFile = "myParams.inc"
#include "main include file.inc"
...
// end scene file
I hope that made some sense.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <chrishuff_99-EFDC80.20133115032000@news.povray.org>, Chris
Huff <chr### [at] yahoocom> wrote:
> In article <38D02C53.7176F1A8@nigels.com>, nig### [at] eisanetau wrote:
>
> > I think the "interface block" concept is the most promising
> > formulation that we have so far. It's something like
> > the main(..) function in C, you're only allowed to have one.
> >
> > > This seems too rigid, though.
> >
> > Perhaps a bit rigid, but still very useful. And it's not
> > an unreasonable solution to the problem. It certainly
> > beats editing POV script by hand.
>
> But if there can only be one in each scene, the only logical place would
> be the main scene file. So you couldn't have the scene file request
> values from the user...
Er, I meant you can't have the include files request values. Oops! :-)
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > > I think the "interface block" concept is the most promising
> > > formulation that we have so far. It's something like
> > > the main(..) function in C, you're only allowed to have one.
> Er, I meant you can't have the include files request values. Oops! :-)
That's right - but this is actually a feature - it puts
one module in control of user interaction.
You simply design the script to pass values from the
interface block to the included files, or to the
macros. Something like:
interface
{
#declare ShowBackground = 1;
#declare ShowLandscape = 1;
#declare NumberOfTrees = 100;
}
#if (ShowBackground)
#include "background.inc"
#end
#if (ShowLandscape)
#include "landscape.inc"
#end
// The Trees include uses TREES_NUMBER to
// control the number of generated trees.
#declare TREES_NUMBER = NumberOfTrees;
#include "trees.inc"
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
> > But if there can only be one in each scene, the only logical place would
> > be the main scene file. So you couldn't have the scene file request
> > values from the user...
Not necessarily. The block could go into the .inc file itself. The .inc
file then could be included at the beginning of the file. The only real
situation that I can see where you may have to wait around for more
user_prompts is if you use the include file to create multiple unique
objects from the same include file. For example the include file is a
tree generator and you want 20 unique trees in your scene it would
require you to call the include file more than one time in the main
scene file. It would of course make sense that those using this feature
decide when it would be useful to utilize this feature and to know
when to use other methods of letting the user preset variables such as
the current system allows.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Juha wrote:
> Jon A. Cruz <jon### [at] geocitiescom> wrote:
> : Guess what? Those are many things that I specifically like about Java, and think
> : they help you to write good code:
>
> I still don't understand how.
>
> :> - The enum type has been left out:
>
> : This one is maybe so-so. I've seen it used well, but then again I've seen it
> : abused.
>
> This is the typical answer. A feature has been left out because it can be
> abused.
> : Overloaded operators make things a lot harder to read
>
> Again a typical answer.
> : Bad. Can be very powerfull in the hands of an expert, but then far more damage can
> : be done by it's use.
>
> Again the "let's limit what a professional programmer can do in order to
> prevent beginners from doing something wrong" effect.
>
> : Actually, it's quite clear. In Java all primitives are passed by value.
>
> No, it's not clear. There's nothing in the syntax that helps you see
> whether a variable is a reference or not. At least in C++ you immediately
> see from the definition of a function that "this parameter is a value and
> this parameter is a reference".
> On the other hand, as I said in the previous article, _everything_ in java
> are references, so once you get used to that it's not so big deal (the basic
> types are passed by value, but you can see it from the type of the parameter).
>
> : Java programming mindset, it's very simple. As opposed to C++ where these would do
> : two different things:
>
> : void F(int x)
> : { x = 5;
> : }
>
> : void F(int &x)
> : { x = 5;
> : }
>
> I don't understand what do you mean. It can be quite clearly seen (once
> you know the syntax, of course) that the second one changes the original
> value while the first one doesn't.
> And by the way, the second one is impossible to do in java.
Yes. That's my point. Impossible in Java.
In use, here is how the first one looks:
x = 2;
foo(x);
// what is x? 2
and here is how the second one looks
x = 2;
foo(x);
// what is x? 5
I don't have any problem when reading the function; the problem is in reading the
higher-level code that uses the function. By just reading the higher level code, one
has no idea if the value of x is changed by foo or not.
>
>
> :> - No templates:
>
> : Again, a very good thing.
>
> Why? I said why it's a bad thing. You didn't say why it would be a good
> thing.
> I have heard all those typical answers hundreds of times. I would like to
> understand them some time.
OK. I'm trying to help you understand the mindset. Remember this thread was on why
Java
programmers wouldn't be happy working in a C++ area. To a non-programmer it might seem
very similar, but the devil is in the details.
A lot of it boils down to the point you made: the "let's limit what a professional
programmer can do in order to prevent beginners from doing something wrong" effect.
That's close, but not quite what I was saying. I had said "expert user", not
"professional programmer". I have no problem with giving power to professional
programmers. The problem is that a huge number of them (perhaps 80-90%) are not quite
'expert' or 'guru'. And these are the programmers who may either initially create
software or come behind later to maintain software. The experts can handle the extra
stuff no problem, it's the other 80-90% of professionals who are the problem. (BTW,
I'm
taking that as a rough estimate from some studies in Code Complete, but as I have my
copy at work I can't cite specifics at the moment.)
Especially when it comes time to get the next version of your product out, and it's
been a year since the last one was touched, and the people who did that are no longer
with the company...
Regarding operator overloading, yes I think it has it's place in C++. But I have seen
it used in actual production code in ways that have actually caused real bugs and
problems for maintenance. If everyone who ever works at a company is in that small
percentage of programmers who are an order of mangnatude more productive, then good.
If
not...
Some of the problem comes from C++'s long history, over 20 years of accumulated
baggage, etc. More and more had been added on to C while keeping all (or most) of the
old way of C around also. thus templates were brought in to address some of the
initial
deficiencies of C++. Or rather to add more capabilities than the earlier C++.
If you drop the procedural approach and come at Java with a stronger OO design, then
it
is very nice. If not... it's doable, but not always pretty. As opposed to C++ where
one
can always drop back to doing basic C things and all is happy-happy.
Another thing that Java does differently is that usually you can only get a single
value returned from a method. Usually return status codes are no longer used since
exceptions can be thrown instead (another good thing that's in C++ also). Of course,
internal state of objects might get changed, but then if you need to access those
state
values you can either just access an exposed member, or call an accessor method.
Probably the main thing about Java and the Java mindset is that if applied to the
proper problems (key point - 'proper') good developers can come up with solid
solutions
in a much shorter timespan. Plus, if any decent effort is made, the later maintenance
of the program will be much less costly. Things like not having macros also help in
this area.
Interfaces in Java solve many of the problems that templates were created to address.
That's probably why I consider them not as necesary. However, there is some ongoing
debate about true generics being needed in Java.
And then there's probably a good way to sum things up. C++ is a language. Java is a
platform. C++ has done a lot to improve over C in this regard, but there are still
some
problems. Three years ago when I moved from doing occasional Java at work I was
editing
on a Windows box, building on Suns, and running on Linux. A year ago when I finally
got
Linux installed here at home, I was staying in it full time even though I was using NT
at work, and was often working from home.
--
"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:
> > Yes, that would work...as long as you put everything at the start of the
> > scene. Which isn't always possible, with includes and macros for example.
>
> Here is a model which might be closer to a solution:
>
> One limitation of POV script is that it's not possible to
> pass values into it without editing the source. There is
> no C-style main(int argc,char *argv[]) and no way to
> read environment variables. In this sense, a pov scene
> is a void main(void) except that you can control the
> clock timer variable.
I see this and the following but as a dumb question, why? What
does it buy the user other than a few lines of source code in
some unusual scene? A development cycle shortening?
In my more interesting scenes again, the time to render exceeds
the time to think about. The time to think about exceeds the time
to type it in. In both cases replace exceeds with greatly
exceeds.
I can see folks interested in more familiar syntax but if you
are stuck with only one syntax, pretty soon you are going to be
stuck with only one language and then where will you be?
--
A free internet for a free people.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
