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

In article <3a3e6b93@news.povray.org>, "ian mcdonald" 
<ian### [at] hotmailcom> 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] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff <chr### [at] maccom> 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

In article <3a3f2a1c@news.povray.org>, Warp <war### [at] tagpovrayorg> 
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] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

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

In article <3A3F75A9.DD25D03B@pacbell.net>, lin### [at] povrayorg 
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] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

On Mon, 18 Dec 2000 14:57:46 -0800, "ian mcdonald" <ian### [at] hotmailcom>
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] hamiltonitecom
http://hamiltonite.com/

Post a reply to this message

Chris Huff <chr### [at] maccom> 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

>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] maccom> wrote in message
news:chrishuff-689AAA.16160618122000@news.povray.org...

Post a reply to this message

In article <3a40a08b@news.povray.org>, Warp <war### [at] tagpovrayorg> 
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] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message