 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38ccd3af@news.povray.org>, Nieminen Juha
<war### [at] sarakerttunen cstutfi> wrote:
> It is perfectly possible to link C object files and C++ object files as
> long as they are defined in the right way.
I know, but it would be easier to develop the translator as a separate
program. That way I could have faster compile times, a specialized
interface for testing various portions, and I could directly see the
output translation. Both writing and testing would be faster.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello,
Nieminen Juha wrote:
>
> Well, I personally don't like Java.
> A C++-binding would be more pleasant to me.
>
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
I agree, I' also would prefer a C++binding, because I hate Java (don't
ask why).
Yours Axel Baune
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi,
Chris Huff wrote:
>
> In article <38CBA3C0.3254B378@pacbell.net>, lin### [at] povrayorg
> wrote:
>
> > It would have to be in Qbasic or I wouldn't use it.
>
> Would you use it even if it *was* in Qbasic? :-)
>
> --
> Chris Huff
> e-mail: chr### [at] yahoocom
> Web page: http://chrishuff.dhs.org/
No I don't think so.
Axel Baune
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris Huff" <chr### [at] yahoocom> wrote in message
news:chrishuff_99-4039AC.06380313032000@news.povray.org...
> I will post a "concept sketch" of the language design in a few
minutes.
> It is incomplete, but should give an idea of what I am thinking.
> I have never written a parser before, so that might be a little
> difficult(well, a simple keyword-value thing, but that doesn't really
> count). But I guess I have to learn sometime... :-)
> I do have a couple ideas about parsing the language, I think it would
be
> easiest to parse the scene into a data structure and then have the
data
> structure output the POV code for each scene element.
Just don't reinvent the wheel!
Parsing and compiling is a well researched subject in computer science.
I recommend that you take a look at lex/yacc for example
One of the standard books is: "The Theory and Practice of Compiler
Writing" by Jean-Paul Tremblay and Paul G. Sorenson (McGraw Hill). It
covers everything you need...
(you probably have it already :)
Johannes
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Johannes Hubert wrote:
> Chris Huff made the suggestion of creating some sort of POV-CSDL ("C
> like Scene Description Language") in the thread "Programming in
> Highshool" in off-topic. That would be a language based on C or C++ to
> be used to create POV-scenes. The scene would then be run through a sort
> of "compiler" to create a "real" POV-Script from it.
> The idea was, that only the "programmers" among us would want to write
> CSDL scripts (for example for complex includes/plug-ins) and that normal
> users could simply include the produced "normal" POV-Script into their
> scenes, not having to worry about the CSDL at all - they could simply
> ignore that part.
One thing I am slightly confused about is if you are using a complicated
scene description language to make a new scene and then convert it to
POV-Ray won't you still be limited to what POV-Ray can actually do
proceeduraly ?
If POV-Ray can already do it proceeduraly why not do it in native Pov
in the first place ?
--
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 <38cd0388$1@news.povray.org>, "Johannes Hubert"
<jht### [at] mailacom> wrote:
> Just don't reinvent the wheel!
What if I want to learn how to make wheels? And what if I can't find a
wheel that fits?
> Parsing and compiling is a well researched subject in computer science.
> I recommend that you take a look at lex/yacc for example
While those might be good for people who want rapid development, I am
not sure they would apply in my case. I do think there is a set of
Bison/Flex(or is it Flexx?) tools for CodeWarrior, but I have never used
that kind of thing.
> One of the standard books is: "The Theory and Practice of Compiler
> Writing" by Jean-Paul Tremblay and Paul G. Sorenson (McGraw Hill). It
> covers everything you need...
> (you probably have it already :)
Actually, I don't have it. All the books I have are a couple standard
"learn C++" books:
Teach Yourself C++ in 21 Days(got this when I took C++ at school)
Programming with C++
Rescued by C++
C++ Primer Plus(this one is actually my favorite, I rarely use the
others)
And a couple C and Java books, and one Pascal book(also from a class I
took at school).
I don't have any books on algorithms or programming theory. I don't have
much money to buy them either... :-(
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38CD5D57.247F8422@pacbell.net>, lin### [at] povrayorg
wrote:
> One thing I am slightly confused about is if you are using a complicated
> scene description language to make a new scene and then convert it to
> POV-Ray won't you still be limited to what POV-Ray can actually do
> proceeduraly ?
>
> If POV-Ray can already do it proceeduraly why not do it in native Pov
> in the first place ?
POV can do these things(or fake them), but to do them while restricted
to the POV syntax would take a long time and be nearly impossible to
read and understand. You could write a scene in C-SDL and then convert
to POV, but you probably wouldn't want to read the POV file, while the
C-SDL code would be much simpler and easier to read/write. For
programmers, at least. :-)
Another thing that could be done instead of or in combination with is
doing most of the parsing work in the converter and outputing a bunch of
POV objects. This would be especially useful for tree/particle system
generators. The POV file would parse much faster than the equivalent
generator written in POV-Script. Of course, this couldn't be done for
most includes...
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris Huff" <chr### [at] yahoocom> wrote in message
news:chrishuff_99-DBD0D6.16302013032000@news.povray.org...
> In article <38cd0388$1@news.povray.org>, "Johannes Hubert"
> <jht### [at] mailacom> wrote:
>
> > Just don't reinvent the wheel!
>
> What if I want to learn how to make wheels? And what if I can't find a
> wheel that fits?
Find a wheel that fits? Great!
Learn how to make wheels? Good idea! But best done by learning from
examples of the pros. If you can't get a book, search on the net, there
should be loads of stuff about parser and compiler writing out there.
Johannes.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Ken" <tyl### [at] pacbellnet> wrote in message
news:38CD5D57.247F8422@pacbell.net...
> One thing I am slightly confused about is if you are using a
complicated
> scene description language to make a new scene and then convert it to
> POV-Ray won't you still be limited to what POV-Ray can actually do
> proceeduraly ?
>
> If POV-Ray can already do it proceeduraly why not do it in native Pov
> in the first place ?
This is about the same as if you were asking:
"Why is the POV-Ray software developed in C, when C is only compiled to
machine code? Aren't you still limited to what your computer can
actually do with machine code? If the computer can already do it in
machine code why not do it in the native machine code in the first
place?"
OK, the difference between machine code and C is more obvious than the
difference between POV-Script and a CSDL, but the analogy still stands:
A CSDL gives a different logical view on the same system (in this case a
3D scene) which will have benefits in some situations, while in other
situations a different view (for example using POV-Script or a visual
modeller) is better.
Johannes.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> A CSDL gives a different logical view on the same system (in this case a
> 3D scene) which will have benefits in some situations,
Here is a conceptual breakthrough! "...a different
logical view on the same system..." You can have a
POV script view, a CSDL view, a VRML view, or an
XML view, or a visual modelling view.
Does everyone want the same view?
No.
Do we need to keep the POV script view?
Yes.
Should POV script be "native" view?
Probably not.
--
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 <38cd7c9a@news.povray.org>, "Johannes Hubert"
<jht### [at] mailacom> wrote:
> Learn how to make wheels? Good idea! But best done by learning from
> examples of the pros. If you can't get a book, search on the net, there
> should be loads of stuff about parser and compiler writing out there.
Know of any good ones? My searches revealed a huge quantity of parser
stuff, but not much of the "parser writing techniques" type.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 12 Mar 2000 12:02:32 -0500, Chris Huff
<chr### [at] yahoocom> wrote:
>In article <38CBC8F6.8B481E2A@pacbell.net>, lin### [at] povrayorg
>wrote:
>
>> A thought... Some of these files query the user for parameters during
>> the program run time. If added to Pov it sure would reduce the number
>> of predeclared variables needed in the scene.
>
>Are you talking about some kind of "query_user()" function that would
>pop up a dialog or a console input for the person rendering the file to
>enter values? Something like:
>#declare Name = query_user("Please enter your name: ");
>
>I don't think that would be a good idea. What if it pops up after 15
>minutes of parsing, and you left the computer going over the weekend
>expecting to have an animation finished when you got back?
Perhaps the parser could scan for such interactive features first, and
let the user know that they need to watch the screen to add input to
the scene data. If no interactive features were found in the scene
files, then the parser could even issue a statement to that effect,
and proceed to render the scene while you went out for the weekend.
>Besides, it could be a real pain to set those for every single little
>test render.
It should also be possible to "remember" the values entered during the
last rendering of an interactive scene file, and use them for
"default" values when queried by the current interactive rendering.
Let's say you have ten seconds to change the default value, or the
scene continues parsing with the default value. Hitting the "return"
key would simply accept the default value as-is, and avoid the ten
second delay. In order to store the previous query values, POV's
text-file output capabilities can be put to use in a method similar to
Nathan's use of an external file for storing photon or radiosity data
for subsequent renders.
I think this would work okay. I have wanted such an interactive aspect
added to POV-Ray myself.
Later,
Glen Berry
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 14 Mar 2000 00:14:11 -0500, Serge LAROCQUE
<sgl### [at] hotmailcom%> wrote:
>Just a question: Is keeping the backward compatibility of POV-Ray with older
>syntax important?
It isn't to me, but it is for some people. I would rather see old
versions of POV used to handle old POV code, than trying to make a new
version of POV bend over backwards and parse legacy code. It usually
isn't that hard to update a POV scene to fit a revised syntax. With
the exception of halos, the feature set only seems to grow, never
shrink. Even in the case of halos, there are work-arounds.
Later,
Glen Berry
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 12 Mar 2000 18:06:39 -0800, "Jon A. Cruz"
<jon### [at] geocitiescom> wrote:
>A floor wax _and_ a desert topping???
>
>Cool.
Not only that, but it tastes great, and it's less filling than other
brands.
:)
Glen Berry
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13 Mar 2000 04:43:09 -0500, Nieminen Juha
<war### [at] sarakerttunencstutfi> wrote:
>TonyB <ben### [at] panamac-comnet> wrote:
>: That is *exactly* the kind of reaction I got when I suggested those things a
>: year ago.
>
> If I remember right, I was one of those fighting agains adding a for-loop
>to povray.
> Well, I have grown out of that stage... :)
Hmmm... if a particular programmer could approve of for-loops, could
JPEG support happen in the future?
Later,
Glen Berry
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Glen Berry wrote:
> I think this would work okay. I have wanted such an interactive aspect
> added to POV-Ray myself.
I am glad someone else sees the potential value of this idea. It would
make using special include files much more versatile than they are now
and would make changing variables interactive. Your screwed if you forget
what values worked the best and forgot what variables you used but the
same is true of any command line utility that accepts switches as input.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Serge LAROCQUE wrote:
>
> Just a question: Is keeping the backward compatibility of POV-Ray with older
> syntax important?
Not for Glen Berry but for many other people, yes. There are a lot of
people out there who are sharing their scene files with the public.
Not everyone want's to spend 10 - 20 min. editing legacy code just to
render it to see if there is anything in there worth adopting in their
own work or simply because the like the image it produces so much they
want a higher resolution and quality version of it. Some very useful
utilities write code for earlier versions of POV-Ray yet the script they
produce is highly desirable. Some of these produce extremely large files
that are nearly impossible to edit manually. This is where the backward
compatiblity really pays off.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Glen Berry wrote:
> Hmmm... if a particular programmer could approve of for-loops, could
> JPEG support happen in the future?
The POV-Team has already officially announced that jpeg input support has
been added to POV-Ray v3.5. Jpeg out will not be added or supported.
--
Ken Tyler - 1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
<KEN>
Not everyone want's to spend 10 - 20 min. editing legacy code just to
render it to see if there is anything in there worth adopting in their
own work...
</KEN>
<GLEN>
Yes, some people would rather spend that 10 -20 minutes writing some
modern code of their own. :)
</GLEN>
<KEN>
...or simply because the like the image it produces so much they
want a higher resolution and quality version of it.
</KEN>
<GLEN> That's what old versions of POV are for. </GLEN>
<HUMOR>
<KEN> <MALICIOUS SNIPPING MODE>
...large files that are nearly impossible to edit... This is where the
backward compatiblity really pays off.
</MALICIOUS SNIPPING MODE> <KEN>
</HUMOR>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
<KEN>
The POV-Team has already officially announced that jpeg input support
has been added to POV-Ray v3.5. Jpeg out will not be added or
supported.
</KEN>
<GLEN>
I'm sorry. I should have specified "full JPEG support." I know that
the POV-Team had intended to add JPEG for input use only.
</GLEN
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <9=XNONfHim9haARAc396blnM8yDn@4ax.com>, Glen Berry
<7no### [at] ezwvcom> wrote:
> Perhaps the parser could scan for such interactive features first, and
> let the user know that they need to watch the screen to add input to
> the scene data. If no interactive features were found in the scene
> files, then the parser could even issue a statement to that effect,
> and proceed to render the scene while you went out for the weekend.
There is still the problem of having to wait for the dialog/prompt to
pop up while the scene is parsing. I have had scenes that took 45
minutes to parse.
> It should also be possible to "remember" the values entered during the
> last rendering of an interactive scene file, and use them for
> "default" values when queried by the current interactive rendering.
> Let's say you have ten seconds to change the default value, or the
> scene continues parsing with the default value. Hitting the "return"
> key would simply accept the default value as-is, and avoid the ten
> second delay. In order to store the previous query values, POV's
> text-file output capabilities can be put to use in a method similar to
> Nathan's use of an external file for storing photon or radiosity data
> for subsequent renders.
This is getting too interface-dependant. I would rather not have
language features depend on the interfaces of different platforms.
And what about automatic rendering? If POV is being controlled through
something like a web page, this kind of feature would have to be removed
or heavily modified.
It is simple enough to make an include file with the variables you want
to use so you don't have to remember the names, or you can put them in
the main file and just use comments well. And this doesn't have the
complications of a user prompt.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Glen Berry wrote:
> It isn't to me, but it is for some people. I would rather see old
> versions of POV used to handle old POV code, than trying to make a new
> version of POV bend over backwards and parse legacy code. It usually
> isn't that hard to update a POV scene to fit a revised syntax. With
> the exception of halos, the feature set only seems to grow, never
> shrink. Even in the case of halos, there are work-arounds.
Hmm. Actually there are people with a large amounts of legacy code and
who are very thankful for backward compatibility ! I can work fast on
very complex scenes today because I can re-use code written 4 years ago
with little changes, apart the occasional missing semi-colon. And I'm not
talking about code that would only take 10-20 minutes of rewriting (this
is the time it may take already to track missing semi-colons).
I do update old code but, believe me, a minimal backward compatibility
is heaven-sent.
Also, I think that one of the big strengthes of POV is that is has been very
stable over the years, possibly at the expense of new stuff coming in.
POV users are basically hobbyists : unlike users working in a professional
environment (who have to keep up with every new thing because the market
demands it) they use it at their own pace, and on their spare time.
We often rely on "old stuff" to have fun, from utilities to macros, include files
or even translated manuals (for the non-English speaking people).
This legacy may be seen as a burden (it certainly is), but it is also one
of the things that keeps POV alive, because it has allowed people to become
experienced and thus make better scenes and share knowledge with new users.
G.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 14 Mar 2000 07:15:06 -0500, Chris Huff
<chr### [at] yahoocom> wrote:
>In article <9=XNONfHim9haARAc396blnM8yDn@4ax.com>, Glen Berry
><7no### [at] ezwvcom> wrote:
>
>> Perhaps the parser could scan for such interactive features first, and
>> let the user know that they need to watch the screen to add input to
>> the scene data. If no interactive features were found in the scene
>> files, then the parser could even issue a statement to that effect,
>> and proceed to render the scene while you went out for the weekend.
>
>There is still the problem of having to wait for the dialog/prompt to
>pop up while the scene is parsing. I have had scenes that took 45
>minutes to parse.
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.
>> It should also be possible to "remember" the values entered during the
>> last rendering of an interactive scene file, and use them for
>> "default" values when queried by the current interactive rendering.
>> Let's say you have ten seconds to change the default value, or the
>> scene continues parsing with the default value. Hitting the "return"
>> key would simply accept the default value as-is, and avoid the ten
>> second delay. In order to store the previous query values, POV's
>> text-file output capabilities can be put to use in a method similar to
>> Nathan's use of an external file for storing photon or radiosity data
>> for subsequent renders.
>
>This is getting too interface-dependant. I would rather not have
>language features depend on the interfaces of different platforms.
Are you telling me that ASCII text file reading and writing is a
highly platform-dependent operation? What about asking an end user to
interactively type a variable in response to an ASCII screen prompt,
are you saying that is also highly platform-dependent? It just so
happens that these operations are found in every basic C/C++ book I
have seen. I always thought they were considered portable.
>And what about automatic rendering? If POV is being controlled through
>something like a web page, this kind of feature would have to be removed
>or heavily modified.
Just because a feature might not be useful to you for every scene you
write, doesn't mean the feature shouldn't exist. Do you currently use
every keyword in POV for each scene you create? I think not.
If you have an objection to user-interactive pre-parsing, no one will
make you use it. At this point, I'm wondering if there is *any*
feature-set change I could suggest for POV-Ray and get a favorable
response from you.
>It is simple enough to make an include file with the variables you want
>to use so you don't have to remember the names, or you can put them in
>the main file and just use comments well. And this doesn't have the
>complications of a user prompt.
"...complications of a user prompt"?
Some would say that a user prompt would greatly simplify some things.
One wouldn't have to remember all the names of all the variables in a
scene file that frequently needed changing. The script would prompt
you for values as it needed them. One person could write an
interactive include file and another person could run it without ever
having to look inside the source code to find all the variables that
need to be changed to suit their particular needs. There would be no
more searching through convoluted code, possibly scattered through
several include files.
You seem to have the mind set that in the future all scripts would be
interactive and you wouldn't be able to overide that interactivity. No
one is proposing a scenario like that. If my earlier suggestion for a
default value that is used after time-out period doesn't suit you, it
would also be possible for POV to simply ask if you wanted to
pre-parse the scene in interactive mode, or simply use the last
user-entered values. If no user-entered values existed, default values
could be written into the script. This would be a global rejection of
user-input as compared to the earlier example of line-by-line
bypassing of prompts. Furthermore, both the global and the
line-by-line rejection options could be incorporated into POV-Ray for
the most flexibility.
Later,
Glen Berry
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 14 Mar 2000 14:39:04 +0100, Gilles Tran <tra### [at] inapginrafr>
wrote:
>Hmm. Actually there are people with a large amounts of legacy code and
>who are very thankful for backward compatibility ! I can work fast on
>very complex scenes today because I can re-use code written 4 years ago
>with little changes, apart the occasional missing semi-colon. And I'm not
>talking about code that would only take 10-20 minutes of rewriting (this
>is the time it may take already to track missing semi-colons).
>I do update old code but, believe me, a minimal backward compatibility
>is heaven-sent.
I can't deny that many people do like a certain level of
backwards-compatibiliy. It might surpise some people to know that *I*
even appreciate a *little* stability. For example, I wouldn't want POV
mutating into something totally incompatible with its previous
incarnation every other week. :)
It just seems to me that there are people that take a negative
knee-jerk reaction to a proposed changed in POV, and wave the
backwards compatibility flag without giving it much thought. They are
often very vocal and dominating in their quest to crush a new idea.
Often times, they don't understand the new idea they are fighting
against. This can be dangerous.
My recent posts expousing my personal acceptance of breaking backwards
compatibility, to gain advanced features or improve quality is meant
to offer an opposing voice to some of these people. It seemed that few
people were speaking up in opposition, and I felt someone should take
the other side. It's hard to make an enlightened decision until both
sides of an argument are properly presented.
I'm sure that a certain amount of backwards compatibility will always
exist in POV. I'm sure that many people will be comforted by that
notion. My personal situation and feelings will not be applicable to
everyone, but expressing them might give the POV coders a better
understanding of the diversity of their user base.
Later,
Glen Berry
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.
Some of them would not be encountered at first, and some of them would
be used in calculations already partly done. And you couldn't simply
scan the file for them and substitute them with values as a
preprocessing step without following the conditionals and loops, which
would mean there would be delays(although shorter than if full parsing
was being done) and it would be significantly harder to implement. You
might want to just rely on people writing friendly code that requests
all variables at once before anything is done, but you still can't
guarantee that your code will be reached early in the parsing.
> >This is getting too interface-dependant. I would rather not have
> >language features depend on the interfaces of different platforms.
>
> Are you telling me that ASCII text file reading and writing is a
> highly platform-dependent operation? What about asking an end user to
> interactively type a variable in response to an ASCII screen prompt,
> are you saying that is also highly platform-dependent? It just so
> happens that these operations are found in every basic C/C++ book I
> have seen. I always thought they were considered portable.
No, I am saying ASCII is platform independant, but a user prompt feature
would be very interface-dependant. On Mac and Windows(and a few Linux
versions), it might be a dialog with a text field(which might do direct
text replacement, with what you input being directly entered into the
parser). On other systems, it would be a command-line prompt, or an
automatically generated web page with text boxes for the entered text.
Although it would be possible for each of these, there would not be a
portable way of doing it.
> >And what about automatic rendering? If POV is being controlled through
> >something like a web page, this kind of feature would have to be removed
> >or heavily modified.
>
> Just because a feature might not be useful to you for every scene you
> write, doesn't mean the feature shouldn't exist. Do you currently use
> every keyword in POV for each scene you create? I think not.
>
> If you have an objection to user-interactive pre-parsing, no one will
> make you use it. At this point, I'm wondering if there is *any*
> feature-set change I could suggest for POV-Ray and get a favorable
> response from you.
You haven't seen my suggestions in the past, have you? :-)
I support adding the #for() loop, I would like to see a #set command to
change variables instead of making new ones, I wrote patches for several
patterns(solid, blob, blob pigment, proximity, object), I wrote the
vtransform(), eval_pigment(), eval_pattern(), and noise3d() function
patches.(NOT the noise3d used in isosurfaces, my patch allows that
function to be used outside isosurface functions)
I also wrote a kind of z-buffer patch, and a blurred transparence patch.
I have also suggested completely changing the language, starting over
from scratch to create a language which is easier to learn and use, more
flexible, and more consistant(although it certainly wasn't a new idea).
The problems with that idea have made me start work on C-SDL(see my
posts in .off-topic).
I actually don't have any objection to the idea of interactive scene
files, I just don't see how they could be done well in POV-Script and in
POV-Ray.
> >It is simple enough to make an include file with the variables you want
> >to use so you don't have to remember the names, or you can put them in
> >the main file and just use comments well. And this doesn't have the
> >complications of a user prompt.
>
> "...complications of a user prompt"?
>
> Some would say that a user prompt would greatly simplify some things.
> One wouldn't have to remember all the names of all the variables in a
> scene file that frequently needed changing. The script would prompt
> you for values as it needed them. One person could write an
> interactive include file and another person could run it without ever
> having to look inside the source code to find all the variables that
> need to be changed to suit their particular needs. There would be no
> more searching through convoluted code, possibly scattered through
> several include files.
This could be done now by using comments to remind you of the variable
names or by having the variables be declared in a separate file which
you edit. Not perfect, but quite useable and they exist now.
> You seem to have the mind set that in the future all scripts would be
> interactive and you wouldn't be able to overide that interactivity. No
> one is proposing a scenario like that.
I certainly didn't mean to sound like that. Like I said, I don't have
any problem with the idea of an interactive script, it would just be too
difficult to implement in POV-Script and impossible to implement in a
cross-platform manner(with the current state of POV-Ray, anyway).
> If my earlier suggestion for a default value that is used after
> time-out period doesn't suit you, it would also be possible for POV
> to simply ask if you wanted to pre-parse the scene in interactive
> mode, or simply use the last user-entered values. If no user-entered
> values existed, default values could be written into the script. This
> would be a global rejection of user-input as compared to the earlier
> example of line-by-line bypassing of prompts. Furthermore, both the
> global and the line-by-line rejection options could be incorporated
> into POV-Ray for the most flexibility.
The function could be something like this:
user_prompt("message string", "default parameter string")
Things like expiration time(and auto-entering of last-used values) would
be set by user preferences(the .ini file for most platforms), and the
entered string would be directly copied into the file(not in the
original, of course. In the parser.). I don't think there is a problem
with the idea of a time delay(as long as you can turn it off and adjust
it's length), just problems with it's implementation.
And then you have to write the dialog code for Mac and Windows, and
dialog/command line code for DOS and Linux, and anyone doing a port
would have to modify that portion of the core code(which is supposed to
be platform independant). The code for one platform could not be used
for the others. You could just have it always use the defaults if the
platform doesn't have the user prompt implemented, but I don't think
that is a good general solution.
And with the modifications that would have to be made to the parser,
this would not be a small feature to add, it is much more than just a
little function or block of code somewhere.
This would be a nice feature, and probably something to think about for
POV 4.0(which is planned to be a rewrite in C++. It might allow the
modifications for the different platforms to be made more easily, and a
pre-processing stage could be added during the parser
rewrite/conversion), but in the current state of POV is just not very
plausible. Another good addition to the wish-list, though.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
> The function could be something like this:
> user_prompt("message string", "default parameter string")
I was thinking along the same lines ( as far as syntax ) but wonder
if it would be as difficult as you make it sound to pass these user
submitted values to a function. For example what if you simply declared
the user_prompt command as one of your variables -
#declare Var_1 = user_prompt("message string", "default parameter string")
#declare A = 0;
#while ( A < Var_1 }
object.....
etc.
In principal it would act as any pre-declared value and is held in
memory before the loop structure is encountered. As long as the
person writing the scene code that utilizes this places the user
prompts before anything else in the scene then you will only encounter
the user prompt during the first few seconds of parsing activity.
--
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 <38CEB739.73D6F151@pacbell.net>, lin### [at] povrayorg
wrote:
> In principal it would act as any pre-declared value and is held in
> memory before the loop structure is encountered. As long as the
> person writing the scene code that utilizes this places the user
> prompts before anything else in the scene then you will only encounter
> the user prompt during the first few seconds of parsing activity.
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.
You could just ignore this problem and use a default value/expiry time
system, but you still have to figure out how to get input from the user
in a platform-independant way.
My idea would be a standard set of user input-output functions for POV
4.0. These would be internal to the platform-specific part of the code
and very general in action, and could be used for user interaction as
well as things like #warning and #debug as well as prompt_user(). Since
they would be part of the platform-specific code and called from the
core code, the problems with making those modifications to the core code
would be gone.
Or maybe something similar exists already, I admit I haven't looked at
that part of the code.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > At this point, I'm wondering if there is *any*
> > feature-set change I could suggest for POV-Ray and get a favorable
> > response from you.
>
> I actually don't have any objection to the idea of interactive scene
> files, I just don't see how they could be done well in POV-Script and in
> POV-Ray.
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.
> it would just be too difficult to implement in POV-Script
<disbelief> Huh? </disbelief>
> and impossible to implement in a cross-platform manner
<amusement> Refer to ANSI C Standard: scanf(...) </amusement>
> 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?)
> but I don't think that is a good general solution.
By your definition, there is no such thing as a general
solution.
> 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>
> 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.
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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 would suggest a mechanism where values can be passed
at the command line, or alternatively, edited at an
interactive prompt in text or GUI form. You support
some sort of block declaration at the start of the POV
file that _allows_ but doesn't _require_ passing from
command line or a text or GUI editor. You only support
it if it's the first thing in the file, and you take
notice of the first block only. The defaults are used
for subsequent blocks.
If you try to pass something on the command line that
isn't in the first block, an error results. If you
want to edit the parameters manually, you must enable
it via command line or in the GUI.
An example:
interface
{
#declare X = 0;
#declare Y = 1;
#decalre Z = "hello";
}
c:\> povray +w320 +h240 +ifile.pov +DX=5 +DY=0 +DZ=bye
That's the idea anyway - it solves the parser stalling
problem, and it simplifies the prompting, because no
timeout is necessary.
And, I think it's not so ambitous that we'd be
waiting around for POV 4.0 to implement 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nigel Stewart wrote:
> If you try to pass something on the command line that
> isn't in the first block, an error results. If you
> want to edit the parameters manually, you must enable
> it via command line or in the GUI.
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.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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] nigelscom)
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
> 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 is an old one and should have a library for it some place.
An error drops you back to the editor at the right line with the
error highlighted. But usually POV does the best it can with what
it has and doesn't get to excited over the issue.
--
A free internet for a free people.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
> Glen Berry wrote:
> > Hmmm... if a particular programmer could approve of for-loops, could
> > JPEG support happen in the future?
> The POV-Team has already officially announced that jpeg input support has
> been added to POV-Ray v3.5. Jpeg out will not be added or supported.
How could it be an output as it has to be a conversion from an
existing normal output to a compressed output and thus cannot be
written directly.
Jpeg input will give some interesting effects to height fields.
It can be tried right now by saving one to jpg with lowest and
highest resolution, converting back to something currently
readable and comparing. Smooth it.
There are so many mountains and so few rolling hills.
--
<A href="http://www.giwersworld.org">A free internet for a free
people.</a>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
>
> In article <38cd0388$1@news.povray.org>, "Johannes Hubert"
> <jht### [at] mailacom> wrote:
>
> > Just don't reinvent the wheel!
>
> What if I want to learn how to make wheels? And what if I can't find a
> wheel that fits?
Maybe you have not looked around? There are enough free ones out
there that I could make an 18-wheeler and have spares. Ain't a
dime's worth of difference among them in my never humble opinion.
> > Parsing and compiling is a well researched subject in computer science.
> > I recommend that you take a look at lex/yacc for example
> While those might be good for people who want rapid development, I am
> not sure they would apply in my case. I do think there is a set of
> Bison/Flex(or is it Flexx?) tools for CodeWarrior, but I have never used
> that kind of thing.
Not quite the same thing. In the days of patchpanels it was
considered a daunting task just to parse words (trailing
whitespace) properly. That turned out to be simple. Praise the
lord and pass the card deck.
Converting infix to postfix notation to machine language turned
out to be easy also. Doing so efficiently turned out to be a
bitch and half. How many passes does your compiler make?
I do not know about POV but it appears to make exactly one pass
before execution.
> > One of the standard books is: "The Theory and Practice of Compiler
> > Writing" by Jean-Paul Tremblay and Paul G. Sorenson (McGraw Hill). It
> > covers everything you need...
> > (you probably have it already :)
>
> Actually, I don't have it. All the books I have are a couple standard
> "learn C++" books:
> Teach Yourself C++ in 21 Days(got this when I took C++ at school)
> Programming with C++
> Rescued by C++
> C++ Primer Plus(this one is actually my favorite, I rarely use the
> others)
> And a couple C and Java books, and one Pascal book(also from a class I
> took at school).
That is something else entirely. The theory and practice of
compilers vice parsers (which are more like tokenizers in BASIC)
is something else entirely. Think about it. Everything you write
has to get to machine code instructions.
If there is anything I would like to see on POV it is a three or
four pass optimizing compiler against this single pass parser.
But then there are not enough gurus interested in this to do
that.
> I don't have any books on algorithms or programming theory. I don't have
> much money to buy them either... :-(
No library?
--
<A href="http://www.giwersworld.org">A free internet for a free
people.</a>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jon A. Cruz <jon### [at] geocitiescom> wrote:
: and here is how the second one looks
: x = 2;
: foo(x);
: // what is x? 5
Java is not any better:
Complex x(2,0);
foo(x);
// Did x change?
: 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...
Again, if we remove everything dangerous, no matter how useful, what do
we have?
Nothing, I think. Everything can be used wrong.
: Another thing that Java does differently is that usually you can only get a single
: value returned from a method.
How do you get more than one value returned from a method in C++?
Of course you can get a class (or struct) instance, but it's still just one
value.
I'm not saying that Java is a bad language. It's safer and often more
pleasant to look at than C++. It's harder to make bad programming with it
(although possible).
I just don't like the limits it imposes. Sorry :)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Matt Giwer wrote:
> > One limitation of POV script is that it's not possible to
> > pass values into it without editing the source.
>
> I see this and the following but as a dumb question, why?
Hmmm... This is like saying that command line tools
should have no prompts.
Perhaps because it would be nice to call POV from
another app without going to the trouble of generating
POV script?
Howabout:
C:\> povray +w100 +h20 +Ibanner.pov +DTEXT="Click Here!"
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > The POV-Team has already officially announced that jpeg input support has
> > been added to POV-Ray v3.5. Jpeg out will not be added or supported.
Anyone know the reasoning for this?
Not even as a compile-time config option?
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Hmmm... This is like saying that command line tools
> should have no prompts.
DOH! Let's try again...
Hmmm... This is like saying that command line tools
should have no command line options.
> Perhaps because it would be nice to call POV from
> another app without going to the trouble of generating
> POV script?
>
> Howabout:
> C:\> povray +w100 +h20 +Ibanner.pov +DTEXT="Click Here!"
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 16 Mar 2000 22:44:56 +1100, Nigel Stewart wrote:
>
>> > The POV-Team has already officially announced that jpeg input support has
>> > been added to POV-Ray v3.5. Jpeg out will not be added or supported.
>
> Anyone know the reasoning for this?
The main reasoning is, we didn't want the support nightmare that comes from
someone (tens of thousands of someones) discovering that a lossy format isn't
the best option for primary output.
> Not even as a compile-time config option?
No comment. :)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Juha wrote:
> How do you get more than one value returned from a method in C++?
> Of course you can get a class (or struct) instance, but it's still just one
> value.
Easily:
int foo( int &out1, int &out2, int &out3, int in1 );
Most any Win32 COM stuff starts to act like that.
Here's the IDL stuff on the basic IDispatch interface. The invoke one is a call worth
noticing.
interface IDispatch : public IUnknown
{
public:
virtual HRESULT STDMETHODCALLTYPE GetTypeInfoCount(
/* [out] */ UINT __RPC_FAR *pctinfo) = 0;
virtual HRESULT STDMETHODCALLTYPE GetTypeInfo(
/* [in] */ UINT iTInfo,
/* [in] */ LCID lcid,
/* [out] */ ITypeInfo __RPC_FAR *__RPC_FAR *ppTInfo) = 0;
virtual HRESULT STDMETHODCALLTYPE GetIDsOfNames(
/* [in] */ REFIID riid,
/* [size_is][in] */ LPOLESTR __RPC_FAR *rgszNames,
/* [in] */ UINT cNames,
/* [in] */ LCID lcid,
/* [size_is][out] */ DISPID __RPC_FAR *rgDispId) = 0;
virtual /* [local] */ HRESULT STDMETHODCALLTYPE Invoke(
/* [in] */ DISPID dispIdMember,
/* [in] */ REFIID riid,
/* [in] */ LCID lcid,
/* [in] */ WORD wFlags,
/* [out][in] */ DISPPARAMS __RPC_FAR *pDispParams,
/* [out] */ VARIANT __RPC_FAR *pVarResult,
/* [out] */ EXCEPINFO __RPC_FAR *pExcepInfo,
/* [out] */ UINT __RPC_FAR *puArgErr) = 0;
};
and you might get something like this in the header files:
#define
IDispatch_Invoke(This,dispIdMember,riid,lcid,wFlags,pDispParams,pVarResult,pExcepInfo,puArgErr)
\
(This)->lpVtbl ->
Invoke(This,dispIdMember,riid,lcid,wFlags,pDispParams,pVarResult,pExcepInfo,puArgErr)
You can do things a little like that in Java, but you have to really work hard to do
so.
> I'm not saying that Java is a bad language. It's safer and often more
> pleasant to look at than C++. It's harder to make bad programming with it
> (although possible).
> I just don't like the limits it imposes. Sorry :)
Then you know the tasks you need to acomplish, and have made good evaluations based on
that.
A good programmer knows when to use which tools.
--
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38D08B07.7587F6E4@ij.net>, Matt Giwer <jul### [at] ijnet>
wrote:
> Maybe you have not looked around? There are enough free ones out
> there that I could make an 18-wheeler and have spares. Ain't a
> dime's worth of difference among them in my never humble opinion.
I know there are a lot of free parser frameworks/libraries, I would
prefer to use a fairly standardized one like Flex/Bison or write one of
my own which I could understand. I plan on looking into Flex and Bison
to see if they have what I need.
> > While those might be good for people who want rapid development, I am
> > not sure they would apply in my case. I do think there is a set of
> > Bison/Flex(or is it Flexx?) tools for CodeWarrior, but I have never
> > used
> > that kind of thing.
>
> Not quite the same thing. In the days of patchpanels it was
> considered a daunting task just to parse words (trailing
> whitespace) properly. That turned out to be simple. Praise the
> lord and pass the card deck.
Not quite the same thing as what? They are parser tools...I need a
parser, and I would prefer to know how they work in some detail first.
> Converting infix to postfix notation to machine language turned
> out to be easy also. Doing so efficiently turned out to be a
> bitch and half. How many passes does your compiler make?
Which compiler, the one I develop in C/C++ on? I really have no idea.
And what does this have to do with C-SDL?
> > Actually, I don't have it. All the books I have are a couple standard
> > "learn C++" books:
> > Teach Yourself C++ in 21 Days(got this when I took C++ at school)
> > Programming with C++
> > Rescued by C++
> > C++ Primer Plus(this one is actually my favorite, I rarely use the
> > others)
> > And a couple C and Java books, and one Pascal book(also from a class I
> > took at school).
>
> That is something else entirely. The theory and practice of
> compilers vice parsers (which are more like tokenizers in BASIC)
> is something else entirely. Think about it. Everything you write
> has to get to machine code instructions.
Something else entirely from *what*? I listed the books I had, said they
were mostly for learning the languages, and said I don't have any books
on parsers or other algorithms.
And compilers don't interest me, nothing I do goes to machine code
instructions except as data(and I can ignore the fact that my C++ code
is converted to machine code), the only thing my program would do is
convert C-SDL to POV-Script.
> > I don't have any books on algorithms or programming theory. I don't
> > have much money to buy them either... :-(
> No library?
No good ones nearby, unfortunately. I don't live in a remote,
unpopulated area, but we are a relatively long way from that kind of
thing. And no transportation other than my parents, although I will be
taking drivers training in June.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
