Hi,

Porting scene from standard 3.8 version to last yuqk give me somme 
errors like that :


The yuqk release 18 (3.8.0-x.yuqk_a5c25dda) version is: v0.6.12.0
File 'vis_mesh03.pov' line 139:
Parse Error:
#local identifier 'i' using only a-z, 0-9 and _ characters.
Fatal error in parser: Cannot parse input.
Render failed


I got this error for several variables.
I just replaced "i" to "iVar", "_n" to "nVar", ... and it's OK.



Strange, isn't it?



-- 
kurtz le pirate
compagnie de la banquise

Post a reply to this message

hi,


kurtz le pirate <kur### [at] freefr> wrote:
> ...
> The yuqk release 18 (3.8.0-x.yuqk_a5c25dda) version is: v0.6.12.0
> File 'vis_mesh03.pov' line 139:
> Parse Error:
> #local identifier 'i' using only a-z, 0-9 and _ characters.
> Fatal error in parser: Cannot parse input.
> Render failed
>
> I got this error for several variables.
> I just replaced "i" to "iVar", "_n" to "nVar", ... and it's OK.
>
> Strange, isn't it?
>

you built without the (poorly named :-)) '--disable-no-lc-identifiers' ?


regards, jr.

Post a reply to this message

On 2/24/25 06:34, kurtz le pirate wrote:
> Porting scene from standard 3.8 version to last yuqk give me somme 
> errors like that :
> 
> The yuqk release 18 (3.8.0-x.yuqk_a5c25dda) version is: v0.6.12.0
> File 'vis_mesh03.pov' line 139:
> Parse Error:
> #local identifier 'i' using only a-z, 0-9 and _ characters.
> Fatal error in parser: Cannot parse input.
> Render failed

The yuqk fork, by default, builds with code that prevents the use of 
lower case user identifiers as these are too often the source of obscure 
bugs and meaning (*)(**). Also, with yuqk changing all the time, it is 
more likely I'll add some feature which collides some user's identifier 
if they are defining lower case ones. This happened when I created an 
'e' immediate value similar to the long existing 'pi'.

Users like jr, who only write and code in lower case, and folks with old 
scenes often have code with lower case characters, so there is an option 
to the configure script in:

   --disable-no-lc-identifiers

which you can add when you run ./configure to turn the checking off.

The installs of the yuqk core are small, One of the development builds I 
maintain is compiled with that option off as are all my prior version 
builds. I too often run into scenes with lower case identifiers.

---

A quick aside I hope useful. A place where I've several times now gotten 
myself tangled up is with our relatively new #for loop. When you
write:

   #for (I,0,SphCnt,4)
   ...
   #end

that 'I' is a created (or modified) identifier which persists. In the 
default yuqk build, it must be upper case, but I still forget that 'I' 
is not locally scoped to the for loop. If there is use of that 'I' 
outside the loop you can end up with an 'I' you didn't expect or, by 
accident, define an 'I' which should be defined / initialized in some 
other way.     		

One protection would be to add an '#undef I' immediately following the 
for loop when you are sure you don't need it to persist though I mostly 
fail to do it.

I've though some about changing the implementation in yuqk so it does an 
internal #undef of the loop identifier / variable at loop's end, IF, the 
'I' wasn't already defined. But, users sometimes would be doing things 
like breaking out and checking the 'I' value following the loop. I don't 
know... Just something to remember perhaps.

Bill P.


(*) Official POV-Ray releases ship with stuff defined in our include 
files which only look like inbuilt keywords and functions. These make 
code passed around less clear and less stable. Users are somewhat likely 
to create things by the same lower case name / identifier. Where these 
do not have the same functionality - but are defined by the totality of 
SDL included for the scene, the scene may run, but not render properly.

(**) - The 'ro_' read only prefix is another, new to yuqk, feature 
related to preventing obscure bugs where, say, a macro call using an 
identifier which exist outside the macros scope changes outside the 
macro itself due some #local or #declare use of the 'macro parameter 
name' within the called macro. This feature is also on by default in 
yuqk, but it too can be configured off by using:

   --disable-read-only-identifiers

when running ./configure.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

> A quick aside I hope useful. A place where I've several times now gotten
> myself tangled up is with our relatively new #for loop. When you
> write:
>
>    #for (I,0,SphCnt,4)
>    ...
>    #end
>
> that 'I' is a created (or modified) identifier which persists. In the
> default yuqk build, it must be upper case, but I still forget that 'I'
> is not locally scoped to the for loop. If there is use of that 'I'
> outside the loop you can end up with an 'I' you didn't expect or, by
> accident, define an 'I' which should be defined / initialized in some
> other way.

This is something that I've run into as well, and for some reason I thought that
there was something in the docs that stated that loop inices were locally
scoped.  I could be wrong about that though.
I get nailed by this a lot when using functions, and I'm trying to use something
like "I" as a function parameter.  Grrr.

> One protection would be to add an '#undef I' immediately following the
> for loop when you are sure you don't need it to persist though I mostly
> fail to do it.
>
> I've though some about changing the implementation in yuqk so it does an
> internal #undef of the loop identifier / variable at loop's end, IF, the
> 'I' wasn't already defined. But, users sometimes would be doing things
> like breaking out and checking the 'I' value following the loop. I don't
> know... Just something to remember perhaps.

I definitely have code that I've written that does that and uses the final value
of I after the loop exits.

Perhaps something to consider is having #for or #while get invoked with an
option #undef flag, like we have shape macros that use union {} unless the "use
merge" flag is set.

If the flag gets set, you undef, if not, let it persist.
Or optionally, you could have the argument be an identifier that gets set to the
last I value - so the user is fully aware and intentionally releasing a globally
set variable into the wild.

Seems like maybe some of this just holds onto a can of worms and may encourage
poor coding practices.

I'm not sure what best practice is, but I personally would lean toward just the
locally encapsulated form.
I suppose if the ultimate I value is needed outside the loop, then the user can
(wastefully and continually) #declare an identifier (inside the loop) before
exiting.

Perhaps some other "real" language has a construct or programming paradigm that
best handles this?

- BW

Post a reply to this message

On 24/02/2025 13:52, jr wrote:

> 
> you built without the (poorly named :-)) '--disable-no-lc-identifiers' ?


Yes, I built with the default options.
Another parameter I missed in the documentation.


Come on, it'll give me some work to do and get back to shell control.





-- 
kurtz le pirate
compagnie de la banquise

Post a reply to this message