In article <39a027c3@news.povray.org>, "Thorsten Froehlich" 
<tho### [at] trfde> wrote:

> And won't a very high recursion level crash it when using a macro and a
> stack overflow occurs?

I thought the recursion level was purposely limited...I know I have had 
trouble with recursion levels of over 50(in a tree macro). It didn't 
crash, it just stopped parsing with an error.
But macros make recursive algorithms much easier to do and more 
powerful, and they do have a greater possible depth than includes. Not 
to mention the speed difference...

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

In article <39a01465@news.povray.org>, "Thorsten Froehlich" 
<tho### [at] trfde> wrote:

> Well, this is obviously not a feature of object oriented languages 
> only. 

I didn't say it was. But it would pretty much be necessary in order to 
add object-oriented capabilities. And once you add the features to make 
POV modular(binding of variables and macros to objects), it seems a 
small step to make it object-oriented(having copies of objects inherit 
the members).


> I agree that there hsould be some way to store data of 
> different types more easily, but I am not sure if C++/Java style 
> syntax would really be the most appropriate and easy to learn.

In my examples, I wasn't basing my syntax on C++/Java...the only 
similarity I can see is using the dot operator to access members, 
something that POV  already does.


> As said before, there are programming languages that fit the language 
> model of POV-Ray much better than C/C++/Java.

Your previous example didn't look very much like POV...and I am not 
talking about using the C/C++/Java model of objects.


> What is wrong with:
> 
> object
> {
>     PlainLensFlare
>     scale 5
>     translate < 5, 1, 6>
>     color < 1, 0, 0.5>
> }

How would you declare this? I used member macros to set variables in my 
example, because I don't see any easy way to set them automatically with 
this type of syntax. Would POV just look at each declaration, and look 
for a matching parameter for it? So if you have a float, a vector, and 
an object, POV would expect the first parameter to be a float, the 
second to be a vector, and the third to be an object?
Basically, how do you declare the syntax?
I couldn't come up with a good and simple solution, so I skipped that 
problem completely. :-)


> My major problem with it is that is obvious in all discussions about 
> an object oriented POV scene description language is that people who 
> are familiar with C/C++/Java seem be caught in the thinking that 
> every language should look this way. to quote the old Apple slogan 
> "Think Different"!
> In particular, I think the low level capabilities of C/C++/Java are 
> in the way of creating a simple and easy to learn object oriented 
> extension to the POV language.  As a matter of fact, due to the 
> completely different nature of C/C++/Java and POV, nobody having to 
> learn it would benefit from existing C/C++/Java documentation, books, 
> etc if he/she does not know any of them before.

I agree, which is why I am not basing my syntax ideas on C/C++/Java. 
Actually, I don't know of any language that does it this way, with 
objects being variables, only one "object" type, and objects inheriting 
from other objects, not from types. It seems a pretty simple and 
flexible idea, though, I would be very surprised if there isn't any 
language that does things this way.
And like I said before, the only real similarity I can see in the syntax 
is the dot operator, which is already used in POV and seems to be easy 
to understand.


> Well, I would say it would parse slower because certain access to 
> internal data structures of POV-Ray would surely take some time. 

If you were just doing a benchmark of parsing speed, it would be slower. 
But it could also allow doing things in ways that would be faster in the 
end, as well as being much easier to write and maintain.


> A more abstract language could hide these complex tasks behind the 
> POV scene language and use the many benefits of a hardwired access of 
> C++ (in POV-Ray 4.0) rather than doing it in small steps in the 
> interpreted POV scene language!

Are you suggesting a new POV language? Not a bad idea, in my opinion, 
but certainly not a popular one.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

In article <39a00a5c@news.povray.org>, "Thorsten Froehlich" 
<tho### [at] trfde> wrote:

> That a Smalltalk development system for the Mac does not have any 
> space in my budget for the next few years :-(

You mean the only Mac development system is expensive?
Note that I don't know anything about it, I have just heard it compared 
to Objective-C and Java.


> As for Objective-C, I have not programmed in it myself, but I have 
> gone over many of the (old) NextStep sample code a few years back.  
> It is not difficult to understand (compared to C++).

I'm planning on learning it for Cocoa, I have heard it's syntax is far 
cleaner than either C++ ir Java, but I am not sure I like the idea of 
doing *all* of the interface stuff in a graphical editor, no matter how 
good or simple to use it is supposed to be.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

On 20 Aug 2000 11:20:17 -0400, Warp wrote:
>
>  If #while-loops are indispensable, then so are #macros. Just think about
>recursive #macros. Although recursion is very similar to looping, it's
>easy to make a recursive #macro which functionality cannot be made with
>#while loops (because you would need a dynamic stack and there are no
>such things in povray (or at least not any efficient one)).

You can't do anything that requires a truly dynamic stack with a #macro,
either, as the max. recursion level is fixed.  Thus, anything you can do
with a #macro can be done with a #while loop and a few arrays.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
: You can't do anything that requires a truly dynamic stack with a #macro,
: either, as the max. recursion level is fixed.

  Why? This is a bit silly. I don't see any reason to limit the recursion
level of macros. That's what dynamic memory allocation is for.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <39a0fd7f@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   Why? This is a bit silly. I don't see any reason to limit the recursion
> level of macros. That's what dynamic memory allocation is for.

Not on all systems the stack is at the other 4 GB (or even 2^64 Byte) end
of the address space. In fact, even on such a system, once stack and heap
together take more than the per address (register) size limit, they will
collide...

Besides, it would be _very_ dangerous for a good operating system to allow a
stack over a specific size.  Take this simple program* for example, it will
consume all your memory resources (even if you run out of process table
entries, assuming this does not result in a signal):

#include <sys/types.h>
#include <unistd.h>

void main(void)
{
    (void)fork();
    main();
}

Now, you either have a per application memory limit, but the stack will
still be able to grow and grow to this limit and then the program will crash
(i.e. the operating system will have to terminate it once the allowed
address space limit has been reached).

As you can see, there is a good reason to have a stack size limit in the
first place.  With only 128 process table entries and 2 GB per application
memory limit, this small program can consume 64 GB of memory (or swap
space)!   How would dynamic memory allocation help here? ;-)


    Thorsten


* Disclaimer: Don't run this program on a system you don't own. Some
administrators don't like such programs :-)

____________________________________________________
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

In article <39a03553@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   I have never looked into the source code of any STL implementation, though.

You don't want to!  POV-Ray source code is better commented and organised
;-)    But it varies a bit from STL to STL...

>   References are pointers.
>   The syntax for references usually doesn't allow you to make so many things
> with them than with pointers, but basically they are the same thing.
>   So it doesn't matter if we call them references or pointers. The important
> thing is what do we allow and what we don't to do with them.

They do not have to be, at least in ISO C++.  Section 8.3.2 paragraph 3 of
ISO/IEC 14882:1998(E) states:

"It is unspecified whether or not a reference requires storage (3.7)."

Effectively this rule seems to exist to allow a compiler to optimise the
code much better.  And this rule also explains why there can't be references
to references, but of course there can be pointers to pointers!

>   In C++ pointers are very free (and thus dangerous) and references are very
> strict. For example, you can't assign a new value to a reference. In Java
> references are more free than in C++ because you can assign the references
> to point to new objects. This is an important feature because without it
> it wouldn't be possible to make lists and so on.

If I am not completely wrong, in other languages like Java the same rule
applies, and a reference could be something for more abstract than a simple
pointer, for example a index to a table of pointers.  This would allow very
effective memory management as memory could be compacted easily.

>   I have always said, that "it's not true at all that there are no pointers
> in Java, all the contrary: In Java _everything_ is a pointer".

Nope, it does not have to be.

> : Great argument!  Who cares if someone can read a POV scene and learn from
> : it, why should there be new novice users of POV-Ray?
>
>   So you say that we shouldn't give powerful tools to people who wants them
> only because newbies can't read the code?

Yes, if this excludes every person who is not a computer scientist or with a
strong background.  After all, POV-Ray is for artists creating interesting
images, but programmers creating complex programs that generate data for
another complex program (POV-Ray) that generates images.

I have to admit that I am not far from the argument for the need for a
modeller here...

>   No, I still think that it doesn't matter. Features are not left out because
> they are slow to parse.

That might be one of the problems of POV-Ray when talking about certain
_parser_ features  :-(

>   Yes, there's a cost in designing a OO-pov language. But that's not a cost
> for the user. The users will probably not notice much difference. Someone
> may sometimes post a weird OO-pov code in text.scene-files, but they are
> usually hard to read anyways ;)

People be able to understand how something works. Increasing the complexity
over a certain limit, it will scare people away instead of encouraging them
to try for themselves.   And why should we exclude the 99.9% of non-computer
scientists from being able to _understand_ even a single POV scene
description?


    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

In article <chrishuff-65D487.15374920082000@news.povray.org> , Chris Huff 
<chr### [at] maccom>  wrote:

>> A more abstract language could hide these complex tasks behind the
>> POV scene language and use the many benefits of a hardwired access of
>> C++ (in POV-Ray 4.0) rather than doing it in small steps in the
>> interpreted POV scene language!
>
> Are you suggesting a new POV language? Not a bad idea, in my opinion,
> but certainly not a popular one.

To go back to the simplicity of parser features in earlier versions, i.e. no
macros and so on.  Even remove the declare statement.

Then, start from there and add the same features from scratch to be more
restrictive and combine it with a simple and powerful programming language
that can be fully integrated into the scene description much more
dynamically.  Details and features would have to be analysed very well in
advance, but then it might offer fantastic abilities.  Just image to be able
to create one object which can exist a million times just by a procedural
definition.  To keep this simple and easy to comprehend and fast to render,
a lot more would have to be done and researched, but I think something like
this is possible.


    Thorsten


PS: As for my other points, they where not specifically addressed to you,
but more general because I get the impression the discussions always start
because someone familiar with C/C++/Java starts thinking about "missing"
features...

____________________________________________________
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

In article <chrishuff-1DB6BF.15421220082000@news.povray.org> , Chris Huff 
<chr### [at] maccom>  wrote:

>> That a Smalltalk development system for the Mac does not have any
>> space in my budget for the next few years :-(
>
> You mean the only Mac development system is expensive?
> Note that I don't know anything about it, I have just heard it compared
> to Objective-C and Java.

Last time I checked it was over $1200 with no student discount in sight :-(

> I'm planning on learning it for Cocoa, I have heard it's syntax is far
> cleaner than either C++ ir Java, but I am not sure I like the idea of
> doing *all* of the interface stuff in a graphical editor, no matter how
> good or simple to use it is supposed to be.

It depends, one can get used to it...


     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

Thorsten Froehlich wrote:

> This still doesn't answer my question: Why?

One answer: More user friendly and less confusing through less #declaring, while
providing powerful tools for the more advanced POV user / include file author.

> Why would more OO features in the scene language improve its usability?

Mainly because it would remove the need to declare separate values and extra name
space. (And memory?)

Example:

camera{
   location <0,1,-5> + clock*<3,0,0>
   look_at 0 + clock*<5,0,0>
}

...compared to:

#declare cam_lookat = <0,1,-5> + clock*<3,0,0>;
#declare cam_move = 0 + clock*<5,0,0>;
camera{
   location cam_move
   look_at cam_lookat
}

In the first example, you can later just extract camera.location and camera.look_at
to get the values...no extra variables needed. Which code do you think looks cleaner
and more easy to use for a novice?


>
> Would it be easier to learn?

No difference, I'd say...because we're not talking about a complete change of
syntax, but an addition to the current language (think of it as extensions) that you
don't have to learn unless you want to use it (like when file I/O was added in v3.1
- it was a new function that could be used when needed - like a tool.)


> Would it be fast to parse?  Would it allow
> porting C/C++/Java programs to POV-script?

Parsing speed: no idea actually...but as Warp said: If it was parsing speed that
counted, macros would never have been introduced anyway.

Porting programs? Binary programs to an ascii POV scene file? Now it's my turn to
ask: "What?", "How?" and "Why?" :)

> In short : What are the _practical_ benefits for the scene description, the
> primary purpose of the POV scene description language?
>

In short: a more user friendly and powerful scripting language that removes the need
for separate declaration of certain values.

----------------------------------------------------
Mikael Carneholm, B.Sc.
Dep. of Computer Science and Business Administration
UCB (University College of Borås) Sweden

Personal homepage:
http://www.studenter.hb.se/~arch
E-mail:
sa9### [at] idautbhbse

Post a reply to this message

Thorsten Froehlich wrote:

> > : Great argument!  Who cares if someone can read a POV scene and learn from
> > : it, why should there be new novice users of POV-Ray?
> >
> >   So you say that we shouldn't give powerful tools to people who wants them
> > only because newbies can't read the code?
>
> Yes, if this excludes every person who is not a computer scientist or with a
> strong background.  After all, POV-Ray is for artists creating interesting
> images, but programmers creating complex programs that generate data for
> another complex program (POV-Ray) that generates images.
>

> People be able to understand how something works. Increasing the complexity
> over a certain limit, it will scare people away instead of encouraging them
> to try for themselves.   And why should we exclude the 99.9% of non-computer
> scientists from being able to _understand_ even a single POV scene
> description?

Sigh...I'm so tired of the fact that a lot of you believe that implementing OO in
POV should mean changing the language into something completely different...

Look, what POV could benefit from is OO extensions - not a totally new language
(why remove the good parts?)

In POV version 4.x (one of the first OO versions), a scene could either look like
this:

#include "colors.inc"

camera{
    location <0,1,-5>
    look_at 0
}

light_source{ <20,50-50> color White }

difference{
    sphere{ <0,0,0>, 1 }
    box{ 1,-1 scale 0.5 translate <0.5,0.5,-0.5> }
    pigment{ Red }
}


..or like this:

#include "my_imap_textures.inc"
#include "camera_macros.inc"
#include "linked_lists.inc"
#include "particle_physics.inc"
#include "incredibly_advanced_functions.inc"

#declare snake_part = sphere{ 0, 0.5 }
#declare snake_head = sphere like snake_part{ texture{ txSnakeHead }}
#declare snake_body = sphere like snake_part{ texture{ txSnakeBody }}

#declare TheSnake = ListMacro1(snake_head, snake_body, 20)
#declare snake_head_position = TheSnake.head.origin + TheSnake.head.translation;
MacroCam1(<0,1,-5>, snake_head_position)

#declare snake_path = spline{
    #include "myspline.spl"
}

TheSnake.follow(snake_path)

...depending on what you want to do and what level you're on.

WE SHOULD NOT REMOVE ANYTHING! JUST ADD A LITTLE FUNCTIONALITY!  (Sorry for
shouting...) :)

#declare CurrentPOVScript = subset of FutureOOPOVScript;

or maybe:

#declare FutureOOPOVScript = union{
    CurrentPOVScript
    AddedOOFunctionality
}

and NOT

#declare FutureOOPOVScript = difference{
    TotallyNewLanguage
    CurrentPOVScript
}

Well, you get the point....

;-)

----------------------------------------------------
Mikael Carneholm, B.Sc.
Dep. of Computer Science and Business Administration
UCB (University College of Borås) Sweden

Personal homepage:
http://www.studenter.hb.se/~arch
E-mail:
sa9### [at] idautbhbse

Post a reply to this message

Thorsten Froehlich wrote:

> To go back to the simplicity of parser features in earlier versions, i.e. no
> macros and so on.  Even remove the declare statement.
>
> Then, start from there and add the same features from scratch to be more
> restrictive and combine it with a simple and powerful programming language
> that can be fully integrated into the scene description much more
> dynamically.  Details and features would have to be analysed very well in
> advance, but then it might offer fantastic abilities.  Just image to be able
> to create one object which can exist a million times just by a procedural
> definition.  To keep this simple and easy to comprehend and fast to render,
> a lot more would have to be done and researched, but I think something like
> this is possible.

Why remove something that's working just fine, and while doing so (removing,
i.e.), making lots of scene files unusable at the same time that you're forcing
the whole POV community to learn a completely new language?

----------------------------------------------------
Mikael Carneholm, B.Sc.
Dep. of Computer Science and Business Administration
UCB (University College of Borås) Sweden

Personal homepage:
http://www.studenter.hb.se/~arch
E-mail:
sa9### [at] idautbhbse

Post a reply to this message

In article <39A14C62.D82D43FC@ida.utb.hb.se>, sa9### [at] idautbhbse 
wrote:

> Why remove something that's working just fine, and while doing so 
> (removing, i.e.), making lots of scene files unusable at the same 
> time that you're forcing the whole POV community to learn a 
> completely new language?

Because it is not working just fine?
It is sometimes more difficult to do things than it should be, and a 
rewrite of the language from it's basics could make it easier to learn. 
It has had things piled on it which it wasn't designed for at the 
beginning, and has many clumsy areas which force you to do things in an 
inefficient way. A new language could mean shorter, easier to read, 
write, and understand scene files.
It might even be possible to do this and still support the existing 
language to a degree. People would have to learn the new one, but the 
basic concepts should be quite similar.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

In article <39a1245e@news.povray.org>, "Thorsten Froehlich" 
<tho### [at] trfde> wrote:

> Then, start from there and add the same features from scratch to be 
> more restrictive and combine it with a simple and powerful 
> programming language that can be fully integrated into the scene 
> description much more dynamically. 

Do you have a specific programming language in mind as the inspiration 
for this?


> Details and features would have to be analysed very well in advance, 
> but then it might offer fantastic abilities.  Just image to be able 
> to create one object which can exist a million times just by a 
> procedural definition.  To keep this simple and easy to comprehend 
> and fast to render, a lot more would have to be done and researched, 
> but I think something like this is possible.

This sounds like a very interesting proposal, but it would really have 
to be done right. Maybe it should be a translator at first, which 
produces a .pov scene file from the new language, that way, you could 
experiment with changes to the new language with more freedom. This is 
the approach I am going to attempt CSDL with...that is, if I ever get 
going with Bison and Flex.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

In article <39a124bd@news.povray.org>, "Thorsten Froehlich" 
<tho### [at] trfde> wrote:

> Last time I checked it was over $1200 with no student discount in sight 
> :-(

Ouch...is it actually used for anything?


> It depends, one can get used to it...

I guess I will have to wait for the public beta and see what it is like 
first-hand...

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff wrote:

> It might even be possible to do this and still support the existing
> language to a degree.

Of course, you're right. My assumption was that implementing OO shouldn't
be so hard that it would require a complete rewrite, but it may still be
true that it's easier to do so, even though it's not required. And just as
you said, even though the parser (and other affected parts) are rewritten
we could still keep the old syntax.

----------------------------------------------------
Mikael Carneholm, B.Sc.
Dep. of Computer Science and Business Administration
UCB (University College of Borås) Sweden

Personal homepage:
http://www.studenter.hb.se/~arch
E-mail:
sa9### [at] idautbhbse

Post a reply to this message

In article <39A14C62.D82D43FC@ida.utb.hb.se> , Mikael Carneholm 
<sa9### [at] idautbhbse>  wrote:

> Why remove something that's working just fine, and while doing so (removing,
> i.e.), making lots of scene files unusable at the same time that you're
> forcing the whole POV community to learn a completely new language?

No, not completely new.  The current problem is that POV scenes are
extremely hard to parse by any outside program (made even harder by the
programming features introduced with 3.0).  To make matters worse, these
features are hard to support without having to re-parse the scene when
rendering animations.

Additionally, in POV-Ray 4.0 a new parser will most likely be needed anyway.
Of course there should be some kind of converter from 3.5 to 4.0 scenes, and
the differences should not require to much relearning.

Anyway, nothing has been decided yet, so these are just my personal ideas
and I am not speaking for the team.


    Thorsten


____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <chrishuff-0B977C.11094221082000@news.povray.org> , Chris Huff 
<chr### [at] maccom>  wrote:

>> Then, start from there and add the same features from scratch to be
>> more restrictive and combine it with a simple and powerful
>> programming language that can be fully integrated into the scene
>> description much more dynamically.
>
> Do you have a specific programming language in mind as the inspiration
> for this?

Not really.  I know there are some high-profile US universities (i.e. MIT)
who use Scheme (a Lisp dialect) in introduction to the profession and/or
introduction to programming classes.  But it is surely not appropriate for
POV-Ray in its current form.

>> Details and features would have to be analysed very well in advance,
>> but then it might offer fantastic abilities.  Just image to be able
>> to create one object which can exist a million times just by a
>> procedural definition.  To keep this simple and easy to comprehend
>> and fast to render, a lot more would have to be done and researched,
>> but I think something like this is possible.
>
> This sounds like a very interesting proposal, but it would really have
> to be done right.

Exactly, and without having done a lot of research in this area it might be
next to impossible to do it quickly.  So one way might be to locate a
already existing language and adapt it with some minor changes, another
might be to really conduct the research, but with which resources?

> Maybe it should be a translator at first, which
> produces a .pov scene file from the new language, that way, you could
> experiment with changes to the new language with more freedom.

Yes, a translator would be necessary.  However, this would not a 'simple'
program either...


    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

In article <chrishuff-6BBA8D.11281121082000@news.povray.org> , Chris Huff 
<chr### [at] maccom>  wrote:

>> Last time I checked it was over $1200 with no student discount in sight
>> :-(
>
> Ouch...is it actually used for anything?

I don't know, but the advertisements say it supports the full set Mac user
interface features.   And keep in mind that CodeWarrior is not that
inexpensive if you are not a student either :-(

>> It depends, one can get used to it...
>
> I guess I will have to wait for the public beta and see what it is like
> first-hand...

The IBM VisualAge product line (PC only) is probably the best way you can
try it out without Mac OS X, but it is expensive and only a few companies
seem to use it.  There also used to be a IBM VisualAge for Smalltalk for
over $4000 ... I had the pleasure to play with it for a weeks a few years
back during a 10 day internship (done in high-school).  Unfortunately I
still don't know Smalltalk, but it didn't look to difficult to learn :-(


    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

Thorsten Froehlich wrote:

> No, not completely new.  The current problem is that POV scenes are
> extremely hard to parse by any outside program (made even harder by the
> programming features introduced with 3.0).

Well, that's another side of the story (?). I believe some sort of export function
that wrote a target file in a target format should be a better solution, as that
wouldn't require as strict syntax as required by an external parser. I guess that
POV's inner representation of an object is easier to export than it is for an
external program to rebuild the object from reading a scene file written by a
user, as there are as many ways of indenting and coding as there are users. A lot
of data could also get lost that way, I suppose.

----------------------------------------------------
Mikael Carneholm, B.Sc.
Dep. of Computer Science and Business Administration
UCB (University College of Borås) Sweden

Personal homepage:
http://www.studenter.hb.se/~arch
E-mail:
sa9### [at] idautbhbse

Post a reply to this message

Thorsten Froehlich wrote:

>That a Smalltalk development system for the Mac does not have any space
>in my budget for the next few years :-(
>

Squeak is free.
http://www.squeak.org/

Ingo

-- 
Photography: http://members.home.nl/ingoogni/
Pov-Ray    : http://members.home.nl/seed7/

Post a reply to this message

In article <8F97DAD9Cseed7@204.213.191.228> , ing### [at] homenl (ingo) wrote:

>>That a Smalltalk development system for the Mac does not have any space
>>in my budget for the next few years :-(
>>
>
> Squeak is free.
> http://www.squeak.org/

Thank you very much for the link!!!  Now I just need to find some time to
learn Smalltalk...


    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

In article <39A1794B.76E9040D@ida.utb.hb.se>, sa9### [at] idautbhbse 
wrote:

> Well, that's another side of the story (?). I believe some sort of 
> export function that wrote a target file in a target format should be 
> a better solution, as that wouldn't require as strict syntax as 
> required by an external parser. I guess that POV's inner 
> representation of an object is easier to export than it is for an 
> external program to rebuild the object from reading a scene file 
> written by a user, as there are as many ways of indenting and coding 
> as there are users. A lot of data could also get lost that way, I 
> suppose.

Indenting and spacing aren't a problem, the parser ignores white space 
in most cases. And while an exporting feature in POV would solve the 
parsing problem, most formats store polygons or triangles, so you would 
still have the problem of tesselating the objects. And exporting 
textures, interiors, and object flags would be difficult.
If you exported to another format and converted back to POV, you 
wouldn't get the same thing. You would probably end up with higher parse 
time, a huge or obviously faceted mesh, higher memory consumption, and 
your texturing and other information would disappear.

And besides, POV is a renderer, not a file converter. Allowing it to 
read other formats would make sense, but writing may not.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
: As you can see, there is a good reason to have a stack size limit in the
: first place.  With only 128 process table entries and 2 GB per application
: memory limit, this small program can consume 64 GB of memory (or swap
: space)!

  Still, a recursion limit of 50 (or whatever it was) is ridiculously small.

:   How would dynamic memory allocation help here? ;-)

  You don't have to use the program stack to simulate recursive macros. You
can make your own stack by malloc()ing memory. Then the only limit is the
available memory.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
:>   So you say that we shouldn't give powerful tools to people who wants them
:> only because newbies can't read the code?

: Yes, if this excludes every person who is not a computer scientist or with a
: strong background.

  I still disagree with you.
  No-one will get any trouble because of the extra features. However those
who know how to use those features can improve their code a lot. So your
statement doesn't make sense.

: And why should we exclude the 99.9% of non-computer
: scientists from being able to _understand_ even a single POV scene
: description?

  You say "exclude" as if adding those features to povray would stop people
from using it. That's not true, of course.
  And I'd say that more than 0.1% of povray users know the basics of
OO-programming, and that should be enough. And besides, it's not that hard
to learn (but easy to misuse, though).

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <39a243dd@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

> Still, a recursion limit of 50 (or whatever it was) is ridiculously small.

This depends on the use (it would be sufficient for most chess programs).
Anyway, I agree with you that 50 (I haven't checked it it is the actual
limit) might be too small in some cases.

>   You don't have to use the program stack to simulate recursive macros. You
> can make your own stack by malloc()ing memory. Then the only limit is the
> available memory.

True, but guess which solution runs much faster?  Growing the stack rarely
causes much overhead, while each call to malloc will take noticeable time.


       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

Thorsten Froehlich <tho### [at] trfde> wrote:
: True, but guess which solution runs much faster?  Growing the stack rarely
: causes much overhead, while each call to malloc will take noticeable time.

  But you don't have to call malloc() for each item you want to put on the
"stack". You can reserver space for more than one item at once.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <39a24878@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

> : True, but guess which solution runs much faster?  Growing the stack rarely
> : causes much overhead, while each call to malloc will take noticeable time.
>
>   But you don't have to call malloc() for each item you want to put on the
> "stack". You can reserver space for more than one item at once.

Yes, if you have the memory resources to burn.  And POV-Ray isn't exactly
the most memory efficient program already.  Or, in  general, imagine the
programmers of the embedded system in your mobile phone would use resources
that carelessly.


     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

Thorsten Froehlich <tho### [at] trfde> wrote:
: Yes, if you have the memory resources to burn.  And POV-Ray isn't exactly
: the most memory efficient program already.  Or, in  general, imagine the
: programmers of the embedded system in your mobile phone would use resources
: that carelessly.

  If you reserve a kilobyte or so at a time, that doesn't matter.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <39a24c89@news.povray.org>, "Thorsten Froehlich" 
<tho### [at] trfde> wrote:

> Yes, if you have the memory resources to burn.  And POV-Ray isn't 
> exactly the most memory efficient program already.  Or, in  general, 
> imagine the programmers of the embedded system in your mobile phone 
> would use resources that carelessly.

I don't think many people run raytracers on cell phones. :-)
POV shouldn't waste memory without reason, but there should be a 
compromise point...
Of course, I was really abusing recursion in that tree macro, many of 
the levels could have been done with a loop within the macro, with 
recursion only done for branching. It still might be a good idea to have 
a recursion limit of 128 or so, or even make it user-adjustable, maybe 
through global_settings(or a new language_settings block).

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

In article <39a247b8@news.povray.org>, "Thorsten Froehlich" 
<tho### [at] trfde> wrote:

> This depends on the use (it would be sufficient for most chess programs).
> Anyway, I agree with you that 50 (I haven't checked it it is the actual
> limit) might be too small in some cases.

BTW, I think the error was something about "too many nested symbol 
tables"...and the actual limit might be more like 75. I remember when I 
added a simple call to a macro for doing stuff at the tips of the 
branches I also got a similar error.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message