POV-Ray : Newsgroups : povray.bugreports : alpha.10064268 undef behaviour Server Time: 27 Sep 2020 22:39:38 GMT
  alpha.10064268 undef behaviour (Message 1 to 5 of 5)  
From: jr
Subject: alpha.10064268 undef behaviour
Date: 13 Aug 2020 10: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 13: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 14: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 16: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 17: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

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