POV-Ray : Newsgroups : povray.bugreports : alpha.10064268 undef behaviour Server Time
28 Mar 2024 15:01:01 EDT (-0400)
  alpha.10064268 undef behaviour (Message 1 to 6 of 6)  
From: jr
Subject: alpha.10064268 undef behaviour
Date: 13 Aug 2020 06:50:01
Message: <web.5f351a7de6b33f6a4d00143e0@news.povray.org>
hi,

I was looking over my 'queues.inc' code[*], and got errors when running the
test/demo scenes.  all three test scenes work ok when using the alpha.9945627,
but with the alpha.10064268, which I installed a few days after posting :-), I
get:

Persistence of Vision(tm) Ray Tracer Version 3.8.0-alpha.10064268.unofficial
 ...
==== [Parsing...] ==========================================================
found 33 in B in first 500.
File '/usr/local/share/povray-3.8/extra/queues.inc' line 59: Possible Parse
 Error: Uncategorized error thrown at parser/symboltable.cpp line 440.
Fatal error in parser: Uncategorized error.
Render failed

==== [Parsing...] ==========================================================
found 33 in B in first 500.
File '/usr/local/share/povray-3.8/extra/queues.inc' line 118: Possible Parse
 Error: Uncategorized error thrown at parser/symboltable.cpp line 440.
Fatal error in parser: Uncategorized error.
Render failed

==== [Parsing...] ==========================================================
the quick brown fox jumped
total 5 elements queued.
quick, the brown fox jumped
File 'tstqp.pov' line 176: Parse Warning: No objects in scene.

lines 59 and 118 contain an '#undef', as does line 225.  yet, two tests fail,
one succeeds, and I cannot see a difference.

[*] <http://news.povray.org/web.5dddb9c6ed272ff4feeb22ff0%40news.povray.org>


regards, jr.


Post a reply to this message

From: William F Pokorny
Subject: Re: alpha.10064268 undef behaviour
Date: 13 Aug 2020 09:23:05
Message: <5f353eb9$1@news.povray.org>
On 8/13/20 6:48 AM, jr wrote:
> hi,
> 
> I was looking over my 'queues.inc' code[*], and got errors when running the
> test/demo scenes.  all three test scenes work ok when using the alpha.9945627,
> but with the alpha.10064268, which I installed a few days after posting :-), I
> get:
...
> 

The two which fail are using float id tokens where the first does not.

In symboltable.cpp Christoph added:

// TODO See captured issue:
// jr_Parse_alpha_10064268_to_10064268_Aug13_2020
//         POV_EXPERIMENTAL_ASSERT((ttype != FLOAT_TOKEN_CATEGORY) &&
//                                 (ttype != FLOAT_ID_TOKEN) &&
//                                 (ttype != VECTOR_TOKEN_CATEGORY) &&
//                                 (ttype != COLOUR_TOKEN_CATEGORY));

// I "think" Christoph wanted something like that below.
// BUT! Why didn't he just differently order FLOAT_ID_TOKEN,
// VECTOR_ID_TOKEN as he looks to have ordered COLOUR_ID_TOKEN
// This looks like something not complete and certainly not clean.

         POV_EXPERIMENTAL_ASSERT(((ttype != FLOAT_TOKEN_CATEGORY) ||
                                  (ttype == FLOAT_ID_TOKEN)) &&
                                 ((ttype != VECTOR_TOKEN_CATEGORY) ||
                                  (ttype == VECTOR_ID_TOKEN)) &&
                                 (ttype != COLOUR_TOKEN_CATEGORY));

I'm going to run with the change at the bottom for a while in povr and 
see what happens. Your test cases again run with the change.

I think though this a v38 release issue where somebody needs to spend a 
chunk of time 'really' getting to understand the state of the current 
parser code to determine the 'right' solution. I'm guessing a little 
given the code state - and that state doesn't looks clean to me.

Bill P.


Post a reply to this message

From: jr
Subject: Re: alpha.10064268 undef behaviour
Date: 13 Aug 2020 10:20:00
Message: <web.5f354b95f20bf6fd4d00143e0@news.povray.org>
hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 8/13/20 6:48 AM, jr wrote:
> > ...
> > I was looking over my 'queues.inc' code[*], and got errors ...
>
> The two which fail are using float id tokens where the first does not.

thank you for looking into it.  did a quick test loading a few strings via
'qqPut()' and yes, that works as should.  (strange that the content of an array
element should matter)

> ...
> I'm going to run with the change at the bottom for a while in povr and
> see what happens. Your test cases again run with the change.

yeah, forgot to mention, 'povr' was same as alpha.10064268.

> I think though this a v38 release issue where somebody needs to spend a
> chunk of time 'really' getting to understand the state of the current
> parser code to determine the 'right' solution. I'm guessing a little
> given the code state - and that state doesn't looks clean to me.

if, after some time, the change you made to 'symboltable.cpp' looks to be
trouble-free, could you post a diff for users (me :-)) to try, please?


regards, jr.


Post a reply to this message

From: William F Pokorny
Subject: Re: alpha.10064268 undef behaviour
Date: 13 Aug 2020 12:27:03
Message: <5f3569d7$1@news.povray.org>
On 8/13/20 10:17 AM, jr wrote:
...
> 
> if, after some time, the change you made to 'symboltable.cpp' looks to be
> trouble-free, could you post a diff for users (me :-)) to try, please?
> 
...

If something changes in approach for povr, I'll try to remember.

For the near future, the diff - aside from comments I added here and 
there in the povr code base should I eventually dig deeper - is simply 
replacing the current POV_EXPERIMENTAL_ASSERT() with the modified one in 
my post.

Bill P.


Post a reply to this message

From: jr
Subject: Re: alpha.10064268 undef behaviour
Date: 13 Aug 2020 13:45:00
Message: <web.5f357bacf20bf6fd4d00143e0@news.povray.org>
hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> For the near future, the diff - aside from comments I added here and
> there in the povr code base should I eventually dig deeper - is simply
> replacing the current POV_EXPERIMENTAL_ASSERT() with the modified one in
> my post.

ok, good info.  cheers.


regards, jr.


Post a reply to this message

From: clipka
Subject: Re: alpha.10064268 undef behaviour
Date: 29 May 2021 14:04:34
Message: <60b28232$1@news.povray.org>
Am 13.08.2020 um 15:23 schrieb William F Pokorny:

> In symboltable.cpp Christoph added:
> 
> // TODO See captured issue:
> // jr_Parse_alpha_10064268_to_10064268_Aug13_2020
> //         POV_EXPERIMENTAL_ASSERT((ttype != FLOAT_TOKEN_CATEGORY) &&
> //                                 (ttype !=
FLOAT_ID_TOKEN) &&
> //                                 (ttype !=
VECTOR_TOKEN_CATEGORY) &&
> //                                 (ttype !=
COLOUR_TOKEN_CATEGORY));

Yeh, that's the offending statement; but...

> // I "think" Christoph wanted something like that below.
> // BUT! Why didn't he just differently order FLOAT_ID_TOKEN,
> // VECTOR_ID_TOKEN as he looks to have ordered COLOUR_ID_TOKEN
> // This looks like something not complete and certainly not clean.
> 
>          POV_EXPERIMENTAL_ASSERT(((ttype != FLOAT_TOKEN_CATEGORY) ||
>                                   (ttype ==
FLOAT_ID_TOKEN)) &&
>                                  ((ttype !=
VECTOR_TOKEN_CATEGORY) ||
>                                   (ttype ==
VECTOR_ID_TOKEN)) &&
>                                  (ttype !=
COLOUR_TOKEN_CATEGORY));

... that doesn't make any sense whatsoever, because `(ttype == 
FLOAT_ID_TOKEN)` can only hold true if `(ttype != FLOAT_TOKEN_CATEGORY)` 
is true anyway.

Nay, the answer is a different one. `(ttype != FLOAT_ID_TOKEN)` 
shouldn't have made it in there in the first place. Also, there's one 
*_CATEGORY value missing from the list, namely 
`SIGNATURE_TOKEN_CATEGORY`. Which for reasons of neatness should be the 
first in the list.

I'll commit a fix to the repo soon.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.