![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Jon A. Cruz" <jon### [at] geocities com> wrote in message
news:3BE9710A.59F6A388@geocities.com...
>
... useful java references snipped
> or
> import org.xml.sax.Parser;
> import org.apache.xerces.parsers.SAXParser;
> ...
> Parser thing = new SAXParser();
>
> And here are the example docs I was just looking at:
> http://xml.apache.org/xerces-j/apiDocs/overview-summary.html
>
> Anyway, I find it more usefull than C++ namespaces where you have a single
> top-level collection of naming shared by the entire world. Among other things,
you
> start to see names decorated with package naming like:
>
> xmlSaxParser thing = new apacheXercesSAXParser();
>
> And don't get the option of short-cutting.
>
Actually, C++ namespaces are more useful than that. Unfortunately, they are not
wide implemented (properly) yet. It would be more like[1]:
namespace apache_Xerces
{
class SAXParser ...
}
...
[other file]
using apache_Xerces::SAXParser; // SAXParser can be used undecorated.
using namespace apache_Xerces; // Imports entire namespace.
I'll agree that Java's approach is probably better. Namespaces were one of the
more debated issues in the C++ standardization process. It's not the best, but
it's better than what existed before.
Michael
[1] It's been a while and I'm rusty, so don't take me for 100% correct. Some of
the using directives may be incorrect.
--
camera{location<8,20>look_at<6,0,4>}light_source{<8,8>rgb 1}difference{union{
#macro M(D,J)#local R=asc(substr(D,J,1))-32;<div(R,10)*2,mod(R,10)>#end#macro
E(D,B,R)prism{-D,4+D,R#local C=1;#while(C<R+1)M(B,C)#local C=C+1;#end}#end E(
0," (2:FPKAD80* U_dZU"18)sphere{2,2}#macro T(N)cylinder{<9,-N,3><9,4+N,3>3-N}
#end T(0)}T(2)E(1"45LNXUK4"8)pigment{rgb x+y/2}}//(c)2001 MDJohnson(Redbeard)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Thorsten Froehlich <tho### [at] trf de> wrote:
: Well, I think POV-ray stores the absolute position os macros ina file, so
: the macro would have to start at the exact location again.
Does this mean that if I make a pov-file which writes another pov-file
containing a macro, then I include it (so POV-Ray reads the macro), then
I write the file again, but so that the macro changes place in the file,
and then call the macro, POV-Ray will issue some type of parse error?
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 8 Nov 2001 05:12:35 -0500, Warp <war### [at] tag povray org> wrote:
> Does this mean that if I make a pov-file which writes another pov-file
>containing a macro, then I include it (so POV-Ray reads the macro), then
>I write the file again, but so that the macro changes place in the file,
>and then call the macro, POV-Ray will issue some type of parse error?
Have you not readed thread
http://news.povray.org/0ok4utgnfkrc4tc0elpvt4a0ggn41cnkvk@4ax.com ?
ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3bea5a92@news.povray.org> , Warp <war### [at] tag povray org> wrote:
> Does this mean that if I make a pov-file which writes another pov-file
> containing a macro, then I include it (so POV-Ray reads the macro), then
> I write the file again, but so that the macro changes place in the file,
> and then call the macro, POV-Ray will issue some type of parse error?
I don't know what will happen! I never tried it. All I know is how POV-Ray
stores the macro position. And you don't want it to parse the while file
again just to call a macro, do you?
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trf de
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Warp" wrote:
> Does this mean that if I make a pov-file which
> writes another pov-file containing a macro, then
> I include it (so POV-Ray reads the macro), then
> I write the file again, but so that the macro
> changes place in the file, and then call the macro,
> POV-Ray will issue some type of parse error?
Correct, though the parse error is different dependent on the details and
sometimes you don't get an error at all. I suppose that's because it's a
situation not considered by POV-Ray, so it doesn't have a specific way to
handle it.
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated Nov 5)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Redbeard wrote:
> "Jon A. Cruz" <jon### [at] geocities com> wrote in message
> news:3BE9710A.59F6A388@geocities.com...
>
> > Anyway, I find it more usefull than C++ namespaces where you have a single
> > top-level collection of naming shared by the entire world. Among other things,
> you
> > start to see names decorated with package naming like:
> >
> > xmlSaxParser thing = new apacheXercesSAXParser();
> >
> > And don't get the option of short-cutting.
> >
> Actually, C++ namespaces are more useful than that. Unfortunately, they are not
> wide implemented (properly) yet. It would be more like[1]:
> namespace apache_Xerces
> {
> class SAXParser ...
> }
> ...
> [other file]
> using apache_Xerces::SAXParser; // SAXParser can be used undecorated.
> using namespace apache_Xerces; // Imports entire namespace.
Ahh, but what you see there is just a single name that lives in the top-level
namespace. (terms are just close, probably not precise to the actual ANSI spec).
You just put an underscore in the middle of that namespace. With Java, you could
have "org.apache", "org.apache.xerces", "org.apache.xml", each one being the
equivalent of nestled subdirectories. With C++ names, you'd have one top-level
directory with "apache", "apache_xerces" and "apache_xml" all living as
subdirectories in that main directory. In practice there's not so much difference,
but semanticly there is.
But I think the most important dinstinction is how those names are chosen. With
C++, each developer anywhere in the world picks what he hopes will be a short but
unique name for his work. Pick the same name for a namespace as someone else, and
you'll have trouble if you ever try to integrate with his code. But the Java trick
of standardizing on reversed domain names solves that problem quite nicely, and on
a world-wide basis.
--
Jon A. Cruz
http://www.geocities.com/joncruz/action.html
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Jon A. Cruz" <jon### [at] geocities com> wrote in message
news:3BEAAFC2.8E01E69E@geocities.com...
> Ahh, but what you see there is just a single name that lives in the top-level
> namespace. (terms are just close, probably not precise to the actual ANSI
spec).
>
> You just put an underscore in the middle of that namespace. With Java, you
could
> have "org.apache", "org.apache.xerces", "org.apache.xml", each one being the
> equivalent of nestled subdirectories. With C++ names, you'd have one top-level
> directory with "apache", "apache_xerces" and "apache_xml" all living as
> subdirectories in that main directory. In practice there's not so much
difference,
> but semanticly there is.
>
> But I think the most important dinstinction is how those names are chosen.
With
> C++, each developer anywhere in the world picks what he hopes will be a short
but
> unique name for his work. Pick the same name for a namespace as someone else,
and
> you'll have trouble if you ever try to integrate with his code. But the Java
trick
> of standardizing on reversed domain names solves that problem quite nicely,
and on
> a world-wide basis.
>
As I said, I think Java has a better and more flexible way of doing it. One
limitation of using the reversed domain name, though, is that not everyone has
one.
I namespaces (or packages, or whatever) should be considered for POV-Ray 4.0,
but I don't how best to implement. There are other ways to do it beyond what
we've discussed here.
Michael
--
#macro M(D)#local J=strlen(D);#local _=""#while(J>0)#local _=concat(_,substr(D
,J,1))#local J=J-1;#end _#end sphere{z*9,5pigment{rgb x}}#macro N(D,J)text{ttf
"timrom.ttf"M(D)1,0 translate-J}#end#macro O(E,K)#local _=N(E,K)light_source{-
z*9rgb 1projected_through{_}}#end O("leahciM"<1.6,-.3.9>)O("nosnhoJ"<1.6.9.9>)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Warp" <war### [at] tag povray org> wrote in message
news:3be69fc4@news.povray.org...
> Firstly, the main reason is that the POV-Ray scripting language is an
> _interpreted_ language. This makes comparison with _compiled_ languages
> (eg. C++) very unfair.
Hmm... I wonder if we could make a POV-Ray "compiler"? As in, it would
parse your scene, and then create an executable which would render that
scene (and that scene only) at a resolution specified on the command line?
This would allow for various speedups and optimizations to be done, wouldn't
it? :)
Of course I realize it would be a nightmare to try and code, so maybe we'll
wait until pov4 comes out...
...Chambers
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Ben Chambers <bdc### [at] hotmail com> wrote:
: Hmm... I wonder if we could make a POV-Ray "compiler"? As in, it would
: parse your scene, and then create an executable which would render that
: scene (and that scene only) at a resolution specified on the command line?
: This would allow for various speedups and optimizations to be done, wouldn't
: it? :)
If you want to code a compiler for every possible platform and OS, be my
guest.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 9 Nov 2001 03:57:38 -0500, Warp <war### [at] tag povray org> wrote:
> If you want to code a compiler for every possible platform and OS, be my
> guest.
I wonder what size could have executable with all tracing loops unrolled ;-)
ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |