Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 5-4-2024 om 13:02 schreef Bald Eagle:
> > Thomas de Groot <tho### [at] degrootorg> wrote:
> >
> >> Hmmm... doesn't seem to be as /simple/ as that... Have you tried this? I
> >> am getting nowhere [drives me crazy indeed]
> >
> > OK, I think you misunderstood what needed to be done.
> >
> Yes, I probably did ;-)
>
> > Change the outside material {} wrapper to texture {}
> > REMOVE all of the texture {} statements inside, leaving only the texture names.
> >
> OK
>
> > That all works - the only thing I couldn't get to work is the Crand, because the
> > #local/#declare thing in macros is still messed up.
> >
> Yes, that is the problem I am also (still) unable to solve in a
> satisfying way, and in fact I referred to that in my post. Still
> wondering about what I assumed in my answer to Alain Martel. Is this
> Crand() macro construction defective in the texture macro compared to
> the material macro, or is something else happening...?
>
> >
> >
> > #version 3.8;
> > global_settings {assumed_gamma 1}
> >
> > camera {
> >   location <0, 0, -5>
> >   right x*image_width/image_height
> >   up y
> >   look_at <0, 0, 0>
> >   rotate y*clock*360
> > }
> >
> > sky_sphere {pigment {rgb 1}}
> >
> > light_source {<100, 100, -500> rgb 1}
> >
> > #include "Granite_Texture.mcr"
> >
> > #declare Tex = Granite_21 ()
> >
> > sphere {0, 1 texture {Tex}}
>
> --
> Thomas

One suggestion for future versions of POV-Ray might be to allow a mode where you
can essentially dump the results of parsing the scene as SDL with all macros
fully resolved.  That way you can see exactly what the parser is doing with your
macros and help find syntax problems in them.

Back in my C programming days we had some developers who were heavy users of
C-style macros, so it was very difficult to map syntax errors from the compiler
back to their original C code.  Fortunately, the C compiler separated out the
macro processor, so you could just run that to see the resulting pure C code and
find and fix the errors.

-- Chris R

Post a reply to this message

Question to BE:

Why has there to be at the end of the macro /twice/ an - exactly 
identical - declaration of M_Granite? if you take out (any) one of them, 
you get a parse error: "Cannot pass uninitialized identifier to 
non-optional LValue."

Otherwise, works fine indeed.

-- 
Thomas

Post a reply to this message

Op 5-4-2024 om 16:12 schreef Chris R:
> One suggestion for future versions of POV-Ray might be to allow a mode where you
> can essentially dump the results of parsing the scene as SDL with all macros
> fully resolved.  That way you can see exactly what the parser is doing with your
> macros and help find syntax problems in them.
> 
Yes, that would be important indeed.

> Back in my C programming days we had some developers who were heavy users of
> C-style macros, so it was very difficult to map syntax errors from the compiler
> back to their original C code.  Fortunately, the C compiler separated out the
> macro processor, so you could just run that to see the resulting pure C code and
> find and fix the errors.
> 
Something like that is missing in POV-Ray I guess. It is often very 
difficult to understand or relate an error message to the proper error. 
See for instance this latest message I submitted to BE in the post above.

-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> Question to BE:
>
> Why has there to be at the end of the macro /twice/ an - exactly
> identical - declaration of M_Granite? if you take out (any) one of them,
> you get a parse error: "Cannot pass uninitialized identifier to
> non-optional LValue."
>
> Otherwise, works fine indeed.
>
> --
> Thomas

I dunno - in the 10 minutes that furiously scribbled out that code this morning,
I was wondering the same thing.
All I did was edit the macro I have stored in my TdG directory, so you musat
have put it there for a reason.

This is why I have kept saying that there is some phantom bug that has crept
into the codebase that no one has recognized or isolated.

It would be interesting to see if the same thing happens when using 3.7 or even
3.6.

I would like POV-Ray to state exactly WHICH uninitialized identifier it's
talking about, so we lowly users can find the problem.

Maybe add some ifdef() statements in there to debug things and see what gives.

- BE

Post a reply to this message

Op 05/04/2024 om 17:49 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Question to BE:
>>
>> Why has there to be at the end of the macro /twice/ an - exactly
>> identical - declaration of M_Granite? if you take out (any) one of them,
>> you get a parse error: "Cannot pass uninitialized identifier to
>> non-optional LValue."
>>
>> Otherwise, works fine indeed.
>>
>> --
>> Thomas
> 
> I dunno - in the 10 minutes that furiously scribbled out that code this morning,
> I was wondering the same thing.
> All I did was edit the macro I have stored in my TdG directory, so you musat
> have put it there for a reason.
> 
Checked: In the original code there was/is only one instance... ;-)

> This is why I have kept saying that there is some phantom bug that has crept
> into the codebase that no one has recognized or isolated.
> 
I wonder at that too...

> It would be interesting to see if the same thing happens when using 3.7 or even
> 3.6.
> 
I can check with 3.7. I do not have 3.6 installed any more (and not 
going to).

> I would like POV-Ray to state exactly WHICH uninitialized identifier it's
> talking about, so we lowly users can find the problem.
> 
Aaah... My wish exactly! So frustrating!

> Maybe add some ifdef() statements in there to debug things and see what gives.
> 
I shall do my best. Will take some time as there are other issues 
surfacing with this texture-based macro...

-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> Question to BE:
>
> Why has there to be at the end of the macro /twice/ an - exactly
> identical - declaration of M_Granite? if you take out (any) one of them,
> you get a parse error: "Cannot pass uninitialized identifier to
> non-optional LValue."
>
> Otherwise, works fine indeed.
>
> --
> Thomas

Now THAT is weird.

I "commented one out" using

#if (0)
 #declare M_Granite =
 texture {
   //interior {ior 1.6}
   #if (Pol) //polished
     #if (Type=off)
       T1_GranitePol
     #else
       T1_GranitePol
       T2_GranitePol
     #end  //Type
   #else //frosted
     #if (Type=off)
       T1_GraniteFro
       //Crand(0.25)
       //Tcrand
     #else
       T1_GraniteFro
       T2_GraniteFro
       //Crand(0.25)
       //Tcrand
     #end  //Type
   #end  //Pol
   scale M_scale
   rotate M_rotat
   translate M_trans
 } //material
#end

And that worked just fine.

But when I highlighted all of that and deleted it, then I got the same weird
error.

If I use /* */ to comment it out, I get the error also.

Makes NO sense, and it's deeply concerning, because how is anyone supposed to
code anything if fundamental #declare statements simply don't work?

- BW

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> > Question to BE:
> >
> > Why has there to be at the end of the macro /twice/ an - exactly
> > identical - declaration of M_Granite? if you take out (any) one of them,
> > you get a parse error: "Cannot pass uninitialized identifier to
> > non-optional LValue."
> >
> > Otherwise, works fine indeed.
> > Thomas
>
> Now THAT is weird.
>
[snip]
>
> Makes NO sense, and it's deeply concerning, because how is anyone supposed to
> code anything if fundamental #declare statements simply don't work?
>

As an odd test, I ran your   granite_texture.mcr.txt   file (from one of the
earlier posts here) just by itself, no other code. As-is, it seems to run fine
when I remove one of the duplicate macro copies. I tested all three of your
attempted removal methods:
        #if(0)...
        /*...*/
        deleting the duplicate

They all work OK, and I can't seem to make it fail! So maybe the fatal error--
whatever is causing it-- is only when the code is actually *used* elsewhere? Or
possibly due to a subtle error in that scene code?

Post a reply to this message

Op 7-4-2024 om 16:38 schreef Bald Eagle:
> Now THAT is weird.
> 

OK. "Solved" that one I guess.

I noticed earlier in the code provided by Chris, that /inside/ the 
(sub-) macros he used a semicolon to end a texture. The original code of 
the granite macro did not have those and - iirc - they were not used as 
such any more since... POV-Ray 3.5? 3.6?

Anyway, you can safely delete one of the two M_Granite textures, 
provided that you add a semicolon at the end of the declaration (and 
before invoking the texture obviously) like this:

#declare M_Granite =
texture {
   //interior {ior 1.6}
   #if (Pol) //polished
     #if (Type=off)
       T1_GranitePol
     #else
       T1_GranitePol
       T2_GranitePol
     #end  //Type
   #else //frosted
     #if (Type=off)
       T1_GraniteFro
       Crand(0.25)
       //Tcrand
     #else
       T1_GraniteFro
       T2_GraniteFro
       Crand(0.25)
       //Tcrand
     #end  //Type
   #end  //Pol
   scale M_scale
   rotate M_rotat
   translate M_trans
} //texture
;

M_Granite


So that seems to be solved although I do not understand /why/ or 
/how/... :-(

-- 
Thomas

Post a reply to this message

On 4/8/24 03:55, Thomas de Groot wrote:
> I noticed earlier in the code provided by Chris, that /inside/ the 
> (sub-) macros he used a semicolon to end a texture. The original code of 
> the granite macro did not have those and - iirc - they were not used as 
> such any more since... POV-Ray 3.5? 3.6?
> 
> Anyway, you can safely delete one of the two M_Granite textures, 
> provided that you add a semicolon at the end of the declaration (and 
> before invoking the texture obviously)

Hi.

FWIW. With my current yuqk fork(a) running what Bill posted, without the 
second declaration of a M_Granite texture ID or the added semicolon, I get:

File 'granite_texture_1.mcr' line 580:
Parse Error:
Cannot assign uninitialized identifier 'M_Granite'
to non-optional LValue of:
'Tex'.
This error sometimes comes about due a prior, situationally, missing 
semicolon.
Fatal error in parser: Cannot parse input.
Render failed

There are issues in all the recent parser variations with respect to 
sometimes necessary, but missing semicolons. The yuqk fork has addressed 
a few of them in its version of the parser, but certainly not all.

The worst cause flaky behavior during parsing without any notice 
something has gone wrong.

Bill P.

(a) - A version compiled to allow lower case identifiers. Plus, I needed 
to add the noise generator to use as the last argument to f_noise3d(). 
The inbuilt functions in official releases of POV-Ray always use noise 
generator 2.

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 7-4-2024 om 16:38 schreef Bald Eagle:
> > Now THAT is weird.
> >
>
> OK. "Solved" that one I guess.
>
> I noticed earlier in the code provided by Chris, that /inside/ the
> (sub-) macros he used a semicolon to end a texture. The original code of
> the granite macro did not have those and - iirc - they were not used as
> such any more since... POV-Ray 3.5? 3.6?
>
> Anyway, you can safely delete one of the two M_Granite textures,
> provided that you add a semicolon at the end of the declaration (and
> before invoking the texture obviously) like this:
>
> #declare M_Granite =
> texture {
>    //interior {ior 1.6}
>    #if (Pol) //polished
>      #if (Type=off)
>        T1_GranitePol
>      #else
>        T1_GranitePol
>        T2_GranitePol
>      #end  //Type
>    #else //frosted
>      #if (Type=off)
>        T1_GraniteFro
>        Crand(0.25)
>        //Tcrand
>      #else
>        T1_GraniteFro
>        T2_GraniteFro
>        Crand(0.25)
>        //Tcrand
>      #end  //Type
>    #end  //Pol
>    scale M_scale
>    rotate M_rotat
>    translate M_trans
> } //texture
> ;
>
> M_Granite
>
>
> So that seems to be solved although I do not understand /why/ or
> /how/... :-(
>
> --
> Thomas
The semi-colon at the end of the texture declaration I understand.  I do this
all the time when I create macros that generate texture identifiers.  If you
don't put the semicolon in, the parser assumes you are creating a layered
texture, with the second layer being "M_Granite", which is an undeclared
identifier.

In all of the macros I create for textures, the template is the following to
avoid that parsing problem:

#macro Create_texture()
   #local _t = texture {
   };

   _t
#end

-- Chris R

Post a reply to this message