 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> There is also a third type of execution, which is a mix between the two:
> The code is first parsed and compiled to a "machine code" or "bytecode"
> (which isn't necessary any machine code known by any processor) and then
> this "machine code" is interpreted by an interpreter.
> I know of two languages which use this approach: Perl and Java. (Even they
> do it a bit differently: Perl compiles the program on the fly to memory and
> then interpretes the compiled code, while Java compiles the program to a
> separate file and then this file can be interpreted as if it was a compiled
> program.)
>
Actually, Smalltalk used bytecodes and pre-dated Perl and Java. The first versions
of Smalltalk using bytecodes came out around 1980. Modern versions translate the
bytecodes to machine code on the fly. Some Basic interpreters also translated into
a bytecode-like language and Pascal used P-Code.
Getting back to POV-Ray, what is really needed is a better parser and interpreter.
Even interpreting bytecodes can be dramatically faster than parsing the text
directly from a file. As was mentioned elsewhere in this thread, POV-Ray's parser
was designed for reading the input file once, not looping, macros, etc. You need a
more sophisticated engine to do those efficiently.
David Buck
Simberon
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Item #2: GLOWS!! GLOWS!!
:-)
--
//Mahalis
camera{location<0,0.25,-2> look_at 0.5*y} #declare T=texture{pigment{crackle
scale 0.5 rotate 90 turbulence 0.75 color_map{[0 rgb 1][0.05 rgb 1][0.1
rgb<1,0.25,1>][0.25 rgbf 1][1 rgbf 1]}} finish{ambient 1}} #declare
c=difference{torus{0.5,0.1 rotate -90*x}box{<0.7,0,0.2>,<-0.7,-0.7,-0.2>}}
merge{object{c translate<0.5,0.5,0>} object{c translate<-0.5,0.5,0>}
cylinder{<1,0.5,0>,<1,0,0>,0.1} cylinder{<-1,0.5,0>,<-1,0,0>,0.1}
cylinder{0.5*y,0,0.1} texture{T}}
--
"Tony[B]" <ben### [at] catholic org> wrote in message
news:3be6a86c@news.povray.org...
> Thanks for that very educational read, Warp. :)
>
> Hey, we should start making a short list of things that simply must be in
> 4.0, like this improved parser you're talking about. That way the Team
won't
> forget about these things when making 4.0.
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Rune" <run### [at] mobilixnetdk> wrote in message
news:3be723d9@news.povray.org...
> "Warp" wrote:
> > But if the user really creates an include file on the fly,
> > then it's treated as any include file which has always existed.
>
> But how is the include file being treated? The same optimized way as the
> main file I hope?
>
I would say, yes, include files would be optomized as well. I've recently been
thinking about this as well. That started when I learned that #include'd macros
open the include file each time the macro is called.
A good way is to parse an included file and keep the parsed file in memory for
the entire execution. When a macro is read it would be parsed into bytecode and
stored in memory. An index to it would be stored and anytime the macro is
encountered in the following code the bytecode is looked up and executed. No
need to open the included file again.
> > This method would just be obsolete due to the evaluation
> > function described above.
>
> Yeah, if it allows strings that are several thousands of lines long and
> which can be accesses in all the frames of an animation, then it'd be
> obsolete (I often generate a very large include file on the fly in the first
> frame of an animation and then include it in all the frames).
>
Many interpreters have no theoretical limit on the size of a string. The
SLang[1] interpreter, for instance, can handle strings hundreds of megabytes in
size.
As for keeping an instance across frames of an animation, this could be handled
with a form of persistent variable. Also, the parsed bytecode could be stored
between animation frames with no need to re-parse. Simply re-interpret. And
since you're just re-interpreting parsed code, which should be very fast, the
need for the large generated include file *might* not be necessary. It might be
just as fast, or nearly as fast and easier, to generate the data on the fly each
time. But again, a type of persistent variable could help here.
Michael
[1] SLang is the language that the JED editor is written with. Well, sort of.
Compiled code performs the core functionality of the editor, but much of that is
being taken over by SLang functionality. The rest of the functionality of JED
(such as context sensitive actions and language dependant formatting) is handled
strictly through SLang scripts files. It's at least as fast as any other editor
I've used, and since you can see 98% of the functionality, you can modify it to
suite your tastes. SLang, by the way, is a parse then interpret language that
can optionally store the bytecode to disk for faster parsing. See
http://www.s-lang.org/ and http://space.mit.edu/~davis/jed/ for more info.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Redbeard" <red### [at] wvadelphianet> wrote in message
news:3be8b2d5@news.povray.org...
>
[snip]
>
> I would say, yes, include files would be optomized as well. I've recently
been
> thinking about this as well. That started when I learned that #include'd
macros
> open the include file each time the macro is called.
>
> A good way is to parse an included file and keep the parsed file in memory for
> the entire execution. When a macro is read it would be parsed into bytecode
and
> stored in memory. An index to it would be stored and anytime the macro is
> encountered in the following code the bytecode is looked up and executed. No
> need to open the included file again.
>
[snip]
I think an exception should be made for mesh includes though eh? They are
already referenced similar to your description (if I understand correctly) as
objects and I wouldn't really want the include text hanging around in memory any
longer than necessary, considering the size they can achieve. ( And of course
I'm not referring to includes that generate meshes algorithmically)
Batronyx ^"^
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
YES!
And how about persistence of variables too? Or was there a good reason
they were left out?
Mahalis <don### [at] fakeycom> wrote in message
news:3be8946a$1@news.povray.org...
> Item #2: GLOWS!! GLOWS!!
> :-)
>
> --
>
> //Mahalis
> camera{location<0,0.25,-2> look_at 0.5*y} #declare
T=texture{pigment{crackle
> scale 0.5 rotate 90 turbulence 0.75 color_map{[0 rgb 1][0.05 rgb
1][0.1
> rgb<1,0.25,1>][0.25 rgbf 1][1 rgbf 1]}} finish{ambient 1}} #declare
> c=difference{torus{0.5,0.1
rotate -90*x}box{<0.7,0,0.2>,<-0.7,-0.7,-0.2>}}
> merge{object{c translate<0.5,0.5,0>} object{c translate<-0.5,0.5,0>}
> cylinder{<1,0.5,0>,<1,0,0>,0.1} cylinder{<-1,0.5,0>,<-1,0,0>,0.1}
> cylinder{0.5*y,0,0.1} texture{T}}
> --
>
>
> "Tony[B]" <ben### [at] catholicorg> wrote in message
> news:3be6a86c@news.povray.org...
> > Thanks for that very educational read, Warp. :)
> >
> > Hey, we should start making a short list of things that simply must
be in
> > 4.0, like this improved parser you're talking about. That way the
Team
> won't
> > forget about these things when making 4.0.
> >
> >
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Redbeard <red### [at] wvadelphianet> wrote:
: A good way is to parse an included file and keep the parsed file in memory for
: the entire execution.
This might introduce some problems with self-modifying code. Of course it
shouldn't be a big loss to disallow this (most programming languages do).
I also wonder if a pov-file including itself may cause some problem (yes,
this IS possible without creating an infinite include loop). Of course this
is also a trick not really necessary to be supported.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message news:3be91b7f@news.povray.org...
> Redbeard <red### [at] wvadelphianet> wrote:
> : A good way is to parse an included file and keep the parsed file in memory
for
> : the entire execution.
>
> This might introduce some problems with self-modifying code. Of course it
> shouldn't be a big loss to disallow this (most programming languages do).
>
Self modifying code could be allowed relatively simply, I think. If the date of
a file has changed between includes, POV-Ray should re-parse it. Then, of
course, if variables, macros, etc. get changed, the interpreter calls the new
ones.
> I also wonder if a pov-file including itself may cause some problem (yes,
> this IS possible without creating an infinite include loop). Of course this
> is also a trick not really necessary to be supported.
>
Should work similar to what I mentioned above. There might be some logistical
problems, but what an include file does when it includes itself is to reparse
itself. If the file hasn't been changed, the interpreter could just start from
the beginning of the file again.
For some reason, this has got me thinking about namespaces. Namespaces, for
those who don't know, are ways of segregating variables between sets of files.
Say I write a set of include files that need to use global variables. Right
now, I have to be careful about naming my globals so no one else tries to use
them. With namespaces this is somewhat alleviated. At the top of the file you
add something like "#namespace MDJ" and every global variable referred to in
that file is prefixed with "MDJ::" (this is similar to C++ syntax... the actual
syntax probably would differ). Within the file I could use the variable "I"
without worrying about it being used outside the file, because it would actually
be "MDJ::I". Outside the group of files the variable could still be accessed
with "MDJ::I" but that wouldn't be as likely. I believe other languages use
similar concepts under different names. Packages are used (I can't remember
what language that is from...) as well as any number of different ways of
distinguising variables from one set of files to another.
What that long-winded paragraph boils down to is that there should be some
consideration made for "macro packages," sets of include files that are
associated with each other but not other include files. At this point I don't
know how it should be implemented, but I believe it should be discussed.
Well... enough jabbering from me for now.
Michael
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Batronyx" <bat### [at] alliancecablenet> wrote in message
news:3be8ba1f@news.povray.org...
>
> "Redbeard" <red### [at] wvadelphianet> wrote in message
> news:3be8b2d5@news.povray.org...
> >
> [snip]
> >
> >
> > A good way is to parse an included file and keep the parsed file in memory
for
> > the entire execution. When a macro is read it would be parsed into bytecode
> and
> > stored in memory. An index to it would be stored and anytime the macro is
> > encountered in the following code the bytecode is looked up and executed.
No
> > need to open the included file again.
> >
> [snip]
>
> I think an exception should be made for mesh includes though eh? They are
> already referenced similar to your description (if I understand correctly) as
> objects and I wouldn't really want the include text hanging around in memory
any
> longer than necessary, considering the size they can achieve. ( And of course
> I'm not referring to includes that generate meshes algorithmically)
>
> Batronyx ^"^
>
Things that are currently objects should remain objects. Thus, a mesh, unless
it is redefined in a macro, is a mesh. Right now, I believe, if you set up a
mesh in a macro and then call the macro again, an entirely new object is made.
All references to the first mesh are completely separate from the references to
the second. Thus:
#macro Mesh()
mesh { ... }
#end
#declare M1 = Mesh()
#declare M2 = M1
#declare M3 = Mesh()
results in, and would result in, two meshes in memory. M1 and M2 refer to one
mesh and M3 refers to the other. The reason for this is that POV-Ray has no way
of knowing that executing the mesh statement a second won't result in a
completely different shape. It could be defined with variables that can change
from call to call.
Now, if you want to *really* optimize the interpreter, you can have it figure
out if it's going to change. If it isn't, some sort of global instance of the
mesh can be made and all other instances refer to the original.
I'd better stop now before I get into too big a discourse of optimizing objects
in POV-Ray... I need to look at the way objects are stored now before I go too
far :-)
Michael
--
#macro M(D,J)text{ttf"cyrvetic.ttf"D 1,0translate-J}#end#macro N(E,K)#local A=
M(E,K)light_source{-z*30rgb 1projected_through{A}}#end N("Michael"<1.6,-.2,5>)
N("Johnson"<1.9.8,5>)sphere{z*9,4pigment{gradient x+y scale 10color_map{[0 rgb
x][1rgb x+y]}sine_wave}} // (c)2001 Michael D Johnson red### [at] wvadelphianet
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Redbeard wrote:
> Packages are used (I can't remember
> what language that is from...) as well as any number of different ways of
> distinguising variables from one set of files to another.
Java is one language that uses packages.
Their naming is to use a hierarchial tree of dot-separated names, and the standard
for choosing names is to start with reversed domain names. This latter way adds an
extra layer of safety against name collisions.
package org.xml.sax;
...
interface Parser {
...
}
Then in other code, one could use:
org.xml.sax.Parser thing = new org.apache.xerces.parsers.SAXParser();
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.
--
Jon A. Cruz
http://www.geocities.com/joncruz/action.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3be91b7f@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
> I also wonder if a pov-file including itself may cause some problem (yes,
> this IS possible without creating an infinite include loop). Of course this
> is also a trick not really necessary to be supported.
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.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
