Thorsten Froehlich <tho### [at] trfde> wrote:
: Hmm, what about a language more like an object oriented lisp. For example
: (OK, not a great one):

: set MyHouse to new house with 10 windows at <10,10,10>

: for every window of MyHouse add new curtain with colour red 0.4 green 0.9

  That's not even close to lisp.

-- 
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 <399f2983@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   That's not even close to lisp.

I did NOT say that this is close to Lisp...


   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:

> I am serious!  Why would an object oriented POV scene description language
> have to look like C++???   Surely not just because POV-Ray uses {} and
> dot-style vector attribute access?   Anybody remember DKBTrace - it used
> Pascal like syntax (and there was already a skyvase.dat)!
>

There's really nothing wrong with the current POV-Script syntax - all it needs
is some modifications to make it a (somewhat) fully object oriented language.
We should not change the language into something completely different, just
add some new features - like it was when file I/O was introduced in v3.1.

Just my 0,18 SKr.. (that's the value of $0.02, in swedish crowns!) :)

----------------------------------------------------
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 <399FE3F5.A96D722F@ida.utb.hb.se> , Mikael Carneholm 
<sa9### [at] idautbhbse>  wrote:

> There's really nothing wrong with the current POV-Script syntax - all it needs
> is some modifications to make it a (somewhat) fully object oriented language.

This still doesn't answer my question: Why?

Why would more OO features in the scene language improve its usability?
Would it be easier to learn?  Would it be fast to parse?  Would it allow
porting C/C++/Java programs to POV-script?

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


    Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
: I did NOT say that this is close to Lisp...

  Well, that's what your statement seems to imply:

: Hmm, what about a language more like an object oriented lisp. For example
       =====================      ====                    ====  ===========

: (OK, not a great one):

: set MyHouse to new house with 10 windows at <10,10,10>


  I undestand your statement that your example should look like lisp.

-- 
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:
: This still doesn't answer my question: Why?

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

  What I am personally still missing from povray are dynamically allocated
objects (where, the objects in povray are indeed dynamically allocated, but
their syntax makes them quite static) and references or pointers to handle
them.
  That would allow making, for example, linked lists, trees and so on.

  If those were implemented in an object-oriented way, it would be a plus.
Making them in a C way would just cause a lot of spaghetti code.

  And object orientedness would help making better scripts. Perhaps most
users will not get any advantage of it, but most include file makers
certainly could.
  Just think about the possibilites. Include files using common abstract
base classes could be used more or less seamlessly together. Clear
interfaces will make them easy to use and maintain, and information hiding
will help avoiding all namespace trashing problems (there's nothing more
annoying than two include files using identifiers with same names).

: Would it be easier to learn?

  It doesn't matter. You don't have to learn it if you don't want it. The
fact that a feature is there doesn't mean you have to learn and use it.
You can let it be and leave the usage to the "experts" :)

: Would it be fast to parse?

  Would it be slower? Does it matter?

:  Would it allow
: porting C/C++/Java programs to POV-script?

  Why anyone would want to do this? They do different things.

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

  Ok, let's then remove identifiers and #while-loops and #macros. They have
no practical benefit, have they? You can do the same thing without them,
can't you?

-- 
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

Warp wrote:

>   Ok, let's then remove identifiers and #while-loops and #macros. They have
> no practical benefit, have they? You can do the same thing without them,
> can't you?

No you can't at least where #while loops are concerned. You would have
to use an external program to get the same funcionality. #macros could
be eliminated without loss of funcionality however.

-- 
Ken Tyler - 1400+ POV-Ray, 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 <tyl### [at] pacbellnet> wrote:
: No you can't at least where #while loops are concerned. You would have
: to use an external program to get the same funcionality.

  Of course you can. Just write all the generated objects by hand.

: #macros could
: be eliminated without loss of funcionality however.

  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)).
  One example of recursive macros are tree generator macros.

-- 
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

Warp wrote:

>   One example of recursive macros are tree generator macros.

Thre were recursive tree include files around before macros were
introduced. PTDTree for example.

-- 
Ken Tyler - 1400+ POV-Ray, 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 <399ff446@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   What I am personally still missing from povray are dynamically 
> allocated objects (where, the objects in povray are indeed 
> dynamically allocated, but their syntax makes them quite static) and 
> references or pointers to handle them.
> That would allow making, for example, linked lists, trees and so on.

Another built-in data structure might be sufficient for this. What I am 
talking about is a new data structure and functions for operating on it, 
a kind of tree which can link to any number of nodes. You could use it 
to build a linked list, a binary tree, an oct-tree, etc.
Maybe a separate "list" structure would still be useful, it would be 
more memory efficient than the above structure. Both of these would be 
easier to use and faster than their equivalents in POV-Script.

-- 
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 <399ff1e0@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

> : I did NOT say that this is close to Lisp...
>
>   Well, that's what your statement seems to imply:
>
> : Hmm, what about a language more like an object oriented lisp. For example
>        =====================      ====                    ====  ===========
[...]
>  I undestand your statement that your example should look like lisp.

Well, English and German are belong to the same family of languages, yet
they do not look the same either.  Yet the "idea" (history), if there is
such a thing behind a spoken language, is the same.

So, please do not read my "like" as "looks like", but if the plain "like" is
not precise enough for you as "inspired by" Lisp.  Also, you cannot just
pick a few words of a sentence and ignore the rest:  I didn't say "like
Lisp", I said "like an object oriented lisp" - note the words _between_
"like" and "Lisp" :-)

As for the actual "idea" behind Lisp is the abstraction _and_ the way it is
implemented, this is the actual similarity between the examples I provided
and any example doing the same in Lisp.  I played it safe by using an
example which would in this style nearly work in a language I know:
AppleScript (which is very similar to HyperTalk).

And at least HyperTalk is considered to be part of the same language family
Lisp is a member of (also it is not _close_ to Lisp syntax)...


     Thorsten


PS: I tried to find a good link to some place proving my statement, but
unfortunately any search for Lisp and AppleScript or Hypertalk return tons
and tons of resume pages <sigh>   The closest but not very well discussed
note I could find is at <http://www.useit.com/papers/tripreports/ht89.html>.
I don't have any of my Prog. Language (History) books here in Germany, so I
can't give you any printed references right now :-(

____________________________________________________
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 <399feed3@news.povray.org>, "Thorsten Froehlich" 
<tho### [at] trfde> wrote:

> This still doesn't answer my question: Why?
> Why would more OO features in the scene language improve its usability?

I've often wished I could store a bunch of different types of data for a 
data structure in one chunk. Objects are an obvious place to put them. I 
had to settle for a bunch of global arrays, and eventually gave up.
The technique of #declaring a bunch of variables and #indluding a file 
is clumsy and can lead to variable name conflicts. Macros don't have 
variable numbers of parameters, so you sometimes have to resort to the 
same thing: #declaring variables before calling the macro. Long lists of 
macro parameters are difficult to keep track of. If object-oriented 
features were added, you could simply declare an object that does 
whatever was done by #including or calling a macro. For example, a lens 
flare object could be used like this:

#declare MyFlare = object {PlainLensFlare};

MyFlare.SetSize(5);
MyFlare.SetPos(< 5, 1, 6>);
MyFlare.SetColor(< 1, 0, 0.5>);
object {MyFlare.CalculateFlare();}

#declare MyFlare = object {SparkleLensFlare};
MyFlare.SetSize(2);
MyFlare.SetPos(<-5, 1, 6>);
MyFlare.SetColor(< 0, 1, 0>);
object {MyFlare.CalculateFlare();}

MyFlare.SetPos(< 0, 5, 6>);
MyFlare.SetColor(< 1, 1, 0>);
object {MyFlare.CalculateFlare();}

This would make 3 lens flares, a purple one to the right, a smaller 
green one to the left, and a yellow one above. You would only need to 
specify the parameters which you want to change, you could have as many 
as you want with no trouble, and you would have far fewer problems with 
variable name collision, since you would only need to watch out for the 
object names, not the parameters. If you wanted to make a slightly 
different lens flare, you wouldn't have to copy/paste a bunch of code 
from the original include and modify it, you could just make an object 
from one of the original objects and override some of the member macros.


> Would it be easier to learn? 

No, but since the existing language wouldn't need to be disturbed, you 
wouldn't have to learn it. It would be considerably easier to learn than 
C++, though.


> Would it be fast to parse? 

It probably wouldn't be noticeably slower without benchmarking, and 
could possibly allow doing some things in a way that would parse faster 
than previously possible.


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

No more than you can already port C or Pascal programs to POV-Script. 
Why would you want to do such a thing, anyway?


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

-- 
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 <chrishuff-47A4E5.19070718082000@news.povray.org> , Chris Huff 
<chr### [at] maccom>  wrote:

> What do you know about Smalltalk and Objective-C?

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

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++).


     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-5D4489.11363420082000@news.povray.org> , Chris Huff 
<chr### [at] maccom>  wrote:

> I've often wished I could store a bunch of different types of data for a
> data structure in one chunk.

Well, this is obviously not a feature of object oriented languages only.  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.

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

> #declare MyFlare = object {PlainLensFlare};
>
> MyFlare.SetSize(5);
> MyFlare.SetPos(< 5, 1, 6>);
> MyFlare.SetColor(< 1, 0, 0.5>);
> object {MyFlare.CalculateFlare();}

What is wrong with:

object
{
    PlainLensFlare
    scale 5
    translate < 5, 1, 6>
    color < 1, 0, 0.5>
}

I understand that there are cases when it appears to be the best way to use
the kind of syntax you suggest. (continues below)


>> Would it be easier to learn?
>
> No, but since the existing language wouldn't need to be disturbed, you
> wouldn't have to learn it. It would be considerably easier to learn than
> C++, though.

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.

To quote [1] Tog talking about the JavaScript in "How Programmers Stole the
Web":

>> And from whence arose this new syntax? It was derived from, and I am quoting
here, "the familiar C++ syntax." Familiar to whom? Certainly not the
millions upon millions of people who know BASIC. Certainly not the millions
upon millions who know HTML. It was familiar to the select cadre of
engineers at Netscape, along with all of their friends. Did they set out to
be exclusionary? I'm sure not; they just simply adapted the tools with which
they themselves felt comfortable. <<

So, should programmer also "steal POV-Ray"?

>> Would it be fast to parse?
>
> It probably wouldn't be noticeably slower without benchmarking, and
> could possibly allow doing some things in a way that would parse faster
> than previously possible.

Well, I would say it would parse slower because certain access to internal
data structures of POV-Ray would surely take some time.  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!

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

This is a rather provocative question, and I wanted to see someone claim
this would be the reason for the language extension :-)


     Thorsten




[1] "How Programmers Stole the Web" by Bruce Tognazzini
    <http://www.AskTog.com/columns/028WebStealers.html>

____________________________________________________
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 <399ff446@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

> : Why would more OO features in the scene language improve its usability?
>
>   What I am personally still missing from povray are dynamically allocated
> objects (where, the objects in povray are indeed dynamically allocated, but
> their syntax makes them quite static) and references or pointers to handle
> them.
>   That would allow making, for example, linked lists, trees and so on.
>
>   If those were implemented in an object-oriented way, it would be a plus.
> Making them in a C way would just cause a lot of spaghetti code.

Hmm, you seriously want to call the C++ STL anything else but "spaghetti
code"?  ;-)

Did you consider more abstract Basic-like (READ: in the spirit of ease of
use and learn typical for the average Basic, NOT the syntax style of Basic)
syntax for it?  POV-Ray already has a few hundred keywords, would the ten or
so for a simple built-in implementation really matter compared to the two or
so needed for a C++/Java style implementation allowing references (no
pointers, pleeeeeeeeeeeease!)?

>   And object orientedness would help making better scripts. Perhaps most
> users will not get any advantage of it, but most include file makers
> certainly could.

Since when does object orientedness improve programming?  How many books,
lectures, labs and practice did you need to master the basics of C++ (not to
mention the basics of object oriented design) compared to the basics of POV?
How many "users" of POV-Ray would really benefit and have the background to
use it?

>   Just think about the possibilities Include files using common abstract
> base classes could be used more or less seamlessly together. Clear
> interfaces will make them easy to use and maintain, and information hiding
> will help avoiding all namespace trashing problems (there's nothing more
> annoying than two include files using identifiers with same names).

For whom?  Programmers with a Ph.D. or the average user with perhaps one or
two years of (hobby) programming experience?

namespaces are a problem, but they can be overcome by simple organisational
manners, without the need for a language extension.  Namespaces are merely a
hack to allow programmers not to talk to each other and follow naming
conventions that could be set by a majority vote and central name
registration system!

> : Would it be easier to learn?
>
>   It doesn't matter. You don't have to learn it if you don't want it.

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?

Please read [1], maybe then you understand and leave your tower <sigh>

> : Would it be fast to parse?
>
>   Would it be slower? Does it matter?

Yes (answering your second question).

> :  Would it allow
> : porting C/C++/Java programs to POV-script?
>
>   Why anyone would want to do this? They do different things.

See my note to Chris Huff :-)

> : In short : What are the _practical_ benefits for the scene description, the
> : primary purpose of the POV scene description language?
>
>   Ok, let's then remove identifiers and #while-loops and #macros. They have
> no practical benefit, have they? You can do the same thing without them,
> can't you?

Hmm, rejecting a jet engine for a car does not imply rejecting a gasoline
engine!  There are features that have more relative value compared to their
cost while others have a lower relative value compared to their (possibly
very high) cost. Note the "relative".


       Thorsten


[1] "How Programmers Stole the Web" by Bruce Tognazzini
    <http://www.AskTog.com/columns/028WebStealers.html>


____________________________________________________
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

Ken <tyl### [at] pacbellnet> wrote:
: Thre were recursive tree include files around before macros were
: introduced. PTDTree for example.

  My point was that it can't be done with a #while-loop.

  Btw, isn't the include recursion level limited to something like 10 in
povray?

-- 
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 <39a01c8f@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   Btw, isn't the include recursion level limited to something like 10 in
> povray?

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


    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:
: And won't a very high recursion level crash it when using a macro and a
: stack overflow occurs?

  I'm not sure, but I think that's a compiler-dependant problem. That is,
it depends how big is the stack the compiler makes the program to use.
Some compilers make a laughably small stack (like 16 kilobytes or so).
  Here (in Solaris with gcc) the stack size is something like 2GB and I
don't remember any recursive macro crashing here.

-- 
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:
: Hmm, you seriously want to call the C++ STL anything else but "spaghetti
: code"?  ;-)

  I don't know. From the point of view of the user of the library it has
a pretty clever and abstract interface and the division into modules looks
good.
  I have never looked into the source code of any STL implementation, though.

: so needed for a C++/Java style implementation allowing references (no
: pointers, pleeeeeeeeeeeease!)?

  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.

  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.
  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".

:>   Just think about the possibilities Include files using common abstract
:> base classes could be used more or less seamlessly together. Clear
:> interfaces will make them easy to use and maintain, and information hiding
:> will help avoiding all namespace trashing problems (there's nothing more
:> annoying than two include files using identifiers with same names).

: For whom?

  From other include files. From the user.

: 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?

:> : Would it be fast to parse?
:>
:>   Would it be slower? Does it matter?

: Yes (answering your second question).

  So if it does matter, then we should remove the #macros. They are very slow.
Specially when included. Also #while-loops are usually slow. What about
big triangle meshes and bicubic patches? They are slow to parse so we should
remove them.

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

: Hmm, rejecting a jet engine for a car does not imply rejecting a gasoline
: engine!  There are features that have more relative value compared to their
: cost while others have a lower relative value compared to their (possibly
: very high) cost. Note the "relative".

  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 ;)

-- 
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 <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