 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris: Have you thought about adding CSDL directly into a patched
version of POV-Ray?
Like some sort of preprocessor.
A POV-Script could for example look like this:
#include "colors.inc"
#include "textures.inc"
camera {
// whatever...
}
background { color MidnightBlue }
plane {
// whatever...
}
// etc.
#begin_csdl
// CSDL code
// (in a yet to be defined syntax)
// goes here...
#end_csdl
sphere {
// whatever
}
#begin_csdl
// some more
// CSDL code here...
#end_csdl
box {
// whatever
}
// etc.
The pached version would then first scan the script for "#begin_csdl ...
#end_csdl" blocks (in all include-files too) and would "translate" them
to real POV-script and replace the blocks with their corresponding
POV-script code. The resulting script would then be handed to the
standard POV-parser, who would never even see (or know about) the CSDL
code.
Users that don't want to use the CSDL code don't have to. And usage of a
plugin written in CSDL would be nothing more than an "#include"
statement, where the whole "#begin_csdl" etc. would be in the include
file.
One small problem: Parsing will be slower, since first the CSDL code
needs to be parsed and translated, before finally POV-ray has to parse
the result.
However, a caching scheme to re-use the translation of previously parsed
and unchanged CSDL blocks could certainly be implemented.
Johannes
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38cc170a@news.povray.org>, "Johannes Hubert"
<jht### [at] maila com> wrote:
> Chris: Have you thought about adding CSDL directly into a patched
> version of POV-Ray?
>
> Like some sort of preprocessor.
> ...
> The pached version would then first scan the script for "#begin_csdl ...
> #end_csdl" blocks (in all include-files too) and would "translate" them
> to real POV-script and replace the blocks with their corresponding
> POV-script code. The resulting script would then be handed to the
> standard POV-parser, who would never even see (or know about) the CSDL
> code.
>
> Users that don't want to use the CSDL code don't have to. And usage of a
> plugin written in CSDL would be nothing more than an "#include"
> statement, where the whole "#begin_csdl" etc. would be in the include
> file.
>
> One small problem: Parsing will be slower, since first the CSDL code
> needs to be parsed and translated, before finally POV-ray has to parse
> the result.
> However, a caching scheme to re-use the translation of previously parsed
> and unchanged CSDL blocks could certainly be implemented.
Hmm. The first problem: I am writing this in C++, POV is written in C.
The second one: I don't know enough about the parser to attempt anything
like this. It is a good idea for blending the two together, though.
Maybe someone else can do it, or maybe I can do it when POV is rewritten
in C++.
And of course, as you mentioned, parsing would be slower, even slower
than ordinary POV code. One of the biggest advantages of a separate
translator would be that the translator program could be significantly
faster than the POV-Script parser, and could output code that would
parse faster than it's human-written POV-Script equivalent(it could do
this by unrolling loops, etc). A way to avoid re-translating by caching
translated versions might be possible, but it is way beyond my
capabilities.
I am working on a definition of a possible syntax, I will probably
eventually post it in povray.off-topic to keep from wasting server
space(because there will probably be several revisions).
--
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->
> Hmm. The first problem: I am writing this in C++, POV is written in C.
Blending C++ and C is not too hard...
> The second one: I don't know enough about the parser to attempt
anything
> like this.
No, what I mean is this: Don't interfere with the POV-parser at all,
just at the very first function call, where the POV-parser is initially
called:
Here, insert a call to your own parser code which pre-translates the
code it reads from the input file *before* passing it to the standard
POV-parser.
For this, you can leave the POV-parser totally alone.
This is also why I mean that blending C and C++ isn't too hard: Between
your code and the rest of the POV code there would be only one single
function call to a global function in your module, which is passed the
current script as a parameter, and which returns the same script, but
with all CSDL blocks replaced by their POV equivalents.
> And of course, as you mentioned, parsing would be slower, even slower
> than ordinary POV code. One of the biggest advantages of a separate
> translator would be that the translator program could be significantly
> faster than the POV-Script parser, and could output code that would
> parse faster than it's human-written POV-Script equivalent(it could do
> this by unrolling loops, etc).
All this can still happen. Meaning: Your "preparser" can still be faster
than the POV-parser (if you achieve that), and the code it outputs can
still be faster for POV to parse than human written (and readable) code
(for the same objects) would be.
It is slower only because the CSDL code has to be parsed each time you
run the script through the patched POV. If using a separate tool, then
the CSDL code is parsed and translated only once, when you run the tool,
and is then saved into a POV-INC file which can be used many times by an
unpatched POV without the need to CSDL-parse it again (of course it
would still go through the standard POV parse).
If the CSDL parser was integrated into POV (as a step before the
standard parser) it would need to CSDL-parse the script each time - this
is the disadvantage I meant.
Probably the best step is to do a separate tool like you are planning
now, and see how it gets accepted. If people like it, integrating it
into a POV patch (the mega-patch?) would be a great idea, I think.
> I am working on a definition of a possible syntax, I will probably
> eventually post it in povray.off-topic to keep from wasting server
> space(because there will probably be several revisions).
This is an interesting project. I would be happy to offer any help I can
give (both in the language design and/or programming).
Greetings,
Johannes.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
>
> After all POV-Ray is about making pretty pictures and is
> not a play toy for programmers. Before firing off a heated response
> think about what I have said.
>
The two are not mutually exclusive, you know. I often do programmatically
generated scenes (mainly because the random number generator has more
inspiration than I do :)
Margus
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Juha wrote:
>
>
> Why is this obsession about "if there's an extra feature, everyone must
> learn it and use it"?
> If there is a feature, you DON'T HAVE TO USE IT if you don't want to.
> However it's good it is there in case someone more advanced wants to use
> it and take whole advantage of the language.
>
I have no problem with extra features - provided there is someone willing to
implement them properly and in a thought-out manner.
Margus
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Juha wrote:
> Jon A. Cruz <jon### [at] geocitiescom> wrote:
> : Well, it seems you have been misinformed. C++ has some horribly ugly things
> : that are intentionally kept out of Java, while C++ had to keep back-wards
> : compatibility with C and also add new OO support.
>
> The fact that it has ugly things doesn't mean you have to use them.
>
> When I try to code with Java I feel more like I am being limited and that
> handy features that I would like to use to make my work easier have been
> taken out, thus making my life harder. Many times some handy shortcuts in C++
> (like typedef, enum, etc) have been left out of Java, and altough you can
> do the same thing with other ways, it's usually a lot of extra work (for
> example defining lots of const variables with their initial values instead
> of just typing their names into an enum). They are often little things, but
> annoying nevertheless.
>
> Here are some annoyances about Java I have found that usually forces you
> to make _BAD_ code:
Guess what? Those are many things that I specifically like about Java, and think
they help you to write good code:
> - The enum type has been left out:
> This means that you have to define a series of values by declaring constant
> variables with their respective initial values. If you want to add a new
> name in the middle, you have to change the numeration of the rest of the
> names.
> The order of the numeration can be important, for example when sorting or
> if the names are someway hierarchically defined.
This one is maybe so-so. I've seen it used well, but then again I've seen it
abused. From a C++ viewpoint it's a minus, but from different design views you
don't miss it. But it is maybe a point of style.
> - The typedef declaration has been left out:
> Which means that you must use the specific data type when making the code,
> instead of using an 'alias' type. This means that if you want to _change_
> that data type later, you have to do it in _tons_ of places instead of
> just in one place.
> Of course the most correct way is to use only class-types, which can be
> modified later without needing to modify the code. However, since there's
> no operator overloading, you will need to make a lot extra work to make
> your code if you just want to use integers or similar. See also:
Well, if you know your C++ spec well ('you' in general, not 'you Warp', you'll
remember that a typedef in C++ is just a class with no methods (or something close
to that). So Java pretty much has it the same. It boils down to just missing a
macro processor.
Also, in Java you can specify an Interface or an abstract base class instead of a
typedef.
> - No operator overloading:
Good if used by a very decent expert programmer. Otherwise I've seen far more evil
done with operator overloading. Especially if someone comes in to do maintenance
on a large project later on. Overloaded operators make things a lot harder to read
if any of the original coders overloaded something that someone didn't expect.
> - There is multiple inheritance of interfaces, but not multiple inheritance
> of classes:
Bad. Can be very powerfull in the hands of an expert, but then far more damage can
be done by it's use.
> - Pointers has been removed.
> void F(int x)
> { x = 5;
> }
>
> void F(complex x)
> { x.set(5);
> }
>
> The syntax of the function definitions are quite the same. There's nothing
> that indicates that the first function DOES NOT modify the original
> variable given as parameter to the function, while the second function
> DOES modify the original value.
Actually, it's quite clear. In Java all primitives are passed by value. Thus, the
first example is quite clear that it can't change the thing that came in. From a
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;
}
void F(int *x)
{ *x = 5;
}
In that case the first should work just like in Java. Of course in C++ the first
two are both called the same, so then it gets a little harder to keep track of.
> - No templates:
Again, a very good thing.
Probably boils down to that you have to think in Java to use Java well, and think
in C++ to use C++ well.
Also, giving up some of that complex flexibility to get a thirty second compile
instead of a fifty minute compile is another thing I like. But to be fair that
fifty minute C++ compile was for MSVC COM stuff using ATL. Not all C++ is that
hard or inneficient to build.
--
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
PoD wrote:
> Ken wrote:
> >
> > After all POV-Ray is about making pretty pictures and is
> > not a play toy for programmers. Before firing off a heated response
> > think about what I have said.
> >
>
> Actually, it's both :^)
>
> PoD.
A floor wax _and_ a desert topping???
Cool.
--
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ok, Chris I think now I understand your point.
Let me say that I would like to see the POV-CSDL in action in the way you
described it in
>...That is what I am thinking of, except my idea is to use a separate
>parser/interpreter utility to convert to POV(this utility could
>incorporate an editor and a way to call POV to render the scene,
>although these would be platform dependant features)...
Regards, Alberto.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
It makes little sense to me. Everything can be abused. I myself have written
so awful java-code that it will probably make you puke. For example one
thing that I really abused were static public class variables. Making a
variable public is a BAD THING. Making it static, and thus more or less is
a WORSE THING. Making tens of them is the WORST THING.
However public static variables have not been removed from java. Why not?
If they remove something as handy as enums, why they didn't remove that?
Actually static public class variables are a lot more dangerous than enums.
In practice they are global variables.
It makes no sense to me.
: Overloaded operators make things a lot harder to read
Again a typical answer. I said "without operator overloading you have to
make explicit method calls, which can make the code very hard to read".
The fact that you can make an operator to do something that is not
expected is NOT a reason to drop it out. In the exact same way you could
make a method called Multiply(x,y) which calculates the substraction of the
two arguments. If you can abuse method names in this way, should we drop
out method names?
: 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.
:> - 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.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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... :)
--
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
|
|
| |
| |
|
|
|
|
| |
|
|
