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