![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Now why, pray tell, would a parser be bored??
It tells me my function is too long.
Is there any logical reason for this?
I happen to like long functions.
I encountered this error in an isosurface function that has 27 positions for
3 variables per segment. I am trying to exaust all combinations.
Off to try using arrays+macros+loops in functions..
ian
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3a3e6b93@news.povray.org>, "ian mcdonald"
<ian### [at] hotmail com> wrote:
> Now why, pray tell, would a parser be bored??
> It tells me my function is too long.
>
> Is there any logical reason for this?
Yes. It is easier to write code to handle a function with a maximum
length than a function of arbitrary length. Just programmer
laziness...and the fact that the isosurface code is rather convoluted,
so few people know how to fix it.
If you need a longer function, try breaking it into several #declared
pieces.
> Off to try using arrays+macros+loops in functions..
Won't work. Well, you might be able to access array variables if the
index is defined outside the function, but macros and loops won't work.
--
Christopher James Huff
Personal: chr### [at] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Chris Huff <chr### [at] mac com> wrote:
: Just programmer laziness...
Indeed. Making it read an arbitrary-length string would be very easy.
I just don't understand why there have to be so many fixed limits 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3a3f2a1c@news.povray.org>, Warp <war### [at] tag povray org>
wrote:
> I just don't understand why there have to be so many fixed limits in
> povray.
Well, many of the people contributing to it aren't experts or even very
experienced...and they may have taken the shortcut to get it up and
running, and just forgotten to fix it later.
Another example: the 256-entry limit in blend maps. Actually, that looks
like it would be quite simple to fix...I'll put it on my list of stuff
to do. It would save memory too, since you wouldn't have to allocate 256
entries for every blend map.
Another thing: for many objects, you have to specify the number of
spline points before the points themselves. It would be nice if POV
counted them itself...
--
Christopher James Huff
Personal: chr### [at] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Chris Huff wrote:
> Another thing: for many objects, you have to specify the number of
> spline points before the points themselves. It would be nice if POV
> counted them itself...
Yeah ! What's up with that anyway :)
--
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3A3F75A9.DD25D03B@pacbell.net>, lin### [at] povray org
wrote:
> > Another thing: for many objects, you have to specify the number of
> > spline points before the points themselves. It would be nice if POV
> > counted them itself...
>
> Yeah ! What's up with that anyway :)
:-)
It's actually a closely related issue...instead of a hard-coded limit,
like the 256 blend items limit, you specify the limit yourself. I don't
know how it would be done without breaking old scenes, though...maybe
ignoring the count if there is one, or by using the #version number...
BTW, I have finished coding the unlimited blend map patch...I just need
to test it now. I made a few other modifications to the code, just
cleaning up the internals and separating the blend map code out of
colors.c and colors.h(what was it doing in there?!?), they shouldn't
affect the syntax...
--
Christopher James Huff
Personal: chr### [at] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Mon, 18 Dec 2000 14:57:46 -0800, "ian mcdonald" <ian### [at] hotmail com>
wrote:
>Now why, pray tell, would a parser be bored??
>It tells me my function is too long.
>
>Is there any logical reason for this?
>
>I happen to like long functions.
>I encountered this error in an isosurface function that has 27 positions for
>3 variables per segment. I am trying to exaust all combinations.
>
I had this problem when trying to develop an Isosurface for a brick wall. Then
when I looked at my big function to try to figure out a way to make it work I
found I couldn't understand it! Eventually I realised how I could split it up
into quite small functions and this made the code much more understandable.
----------------------
dav### [at] hamiltonite com
http://hamiltonite.com/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Chris Huff <chr### [at] mac com> wrote:
: instead of a hard-coded limit,
: like the 256 blend items limit, you specify the limit yourself.
Why, when povray can calculate it itself?
It can perfectly look and see that "hey, there are 400 items here. Well,
let's make a table with 400 items". It wouldn't break any old scenes either
and the syntax would keep completely unmodified.
Ever heard of dynamic data containers?
For example the triangle mesh is one.
--
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>Just programmer laziness...
Oh..
In regard to that fact, at the utmost peak of my amazement, I only fully
expected this to be true.
> Won't work.
Thusly I figured, later to quantify my suspicion.
Thank-you for your help. :)
I might suggest, instead of errors as quoted, you might use sarcasm as in:
"The parser thinks you are an idiot."
"You have X objects, and Y free memory. Are you ill, or simply stupid?"
"Your scene contains superfluous code and/or intrinsically sucks, PoV-RAY
will crash now."
"And now for something completely different..."
Kidding, of course. :-P
ian
Chris Huff <chr### [at] mac com> wrote in message
news:chrishuff-689AAA.16160618122000@news.povray.org...
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3a40a08b@news.povray.org>, Warp <war### [at] tag povray org>
wrote:
> Why, when povray can calculate it itself?
Well, that was my whole point...
> It can perfectly look and see that "hey, there are 400 items here.
> Well, let's make a table with 400 items". It wouldn't break any old
> scenes either and the syntax would keep completely unmodified.
The problem with spline-based objects(like lathe, prism, etc...) is that
you can't do it without modifying the syntax, because takes the number
of points as well as the points themselves, so if you simply eliminate
that value, no old scenes will work properly.
The obvious solution is to ignore the float value if it is there...but
what if that wasn't the count variable, but was a float that was
supposed to get promoted to the first point? The other solution is to
use a new syntax based on the version number, which is what I plan to do
if I ever attempt this as a patch.
Fixing blend maps was pretty easy, because all I had to do was replace
the error when the blend map got too big with code for resizing the
array of entries(Ok, I cleaned up the code a bit, too). Other areas with
this problem have syntax issues as well.
> Ever heard of dynamic data containers?
> For example the triangle mesh is one.
Yes, but it's been one from the beginning, and POV can't confuse a float
with a triangle, but it can confuse one with a vector.
--
Christopher James Huff
Personal: chr### [at] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |