POV-Ray : Newsgroups : povray.unofficial.patches : jr's large csv and dictionary segfault in the povr fork. : Re: jr's large csv and dictionary segfault in the povr fork. Server Time
27 Feb 2024 18:06:06 EST (-0500)
  Re: jr's large csv and dictionary segfault in the povr fork.  
From: William F Pokorny
Date: 4 Oct 2023 14:12:02
Message: <651daaf2$1@news.povray.org>
On 10/4/23 11:36, jr wrote:
> out of interest, do macros and their respective local storage form units
> ("objects"), or are they married up "on demand" ?

Suppose more the latter. There isn't really local macro storage / or a 
local macro stack (excepting where VM functions are used with macros).

My current understanding; Hopefully not too badly described.

There is a, local to each macro when running, symbol table for #local 
declared things (*,**) and parameters (always true..?). The table 
entries point to created / stored things which might or might not 
persist beyond the macro call depending on whether they are assigned to 
an identifier in a calling level of hierarchy(b).

---
Function calls, whether inside or outside macros, are different.

For inbuilt functions like f_sphere() there is a virtual machine (VM) 
stack for passed and returned variables for each function call - and 
another stack used by the compiler for C++ variables within the inbuilt 
code.

For user (parse time compiled functions) run on the VM there is just the 
(VM) stack (lies and more lies... I know) from the SDL user's perspective.

Bill P.

(*) - Something I noticed on starting this recent debugging and that 
I've fixed in my povr copies of the HF* macros! These old HF* macros 
switch from using #local to using #declare for some variables near the 
bottom of each macro for reasons unknown...

...
-            #declare PArr[J][K] = P + H*Dir*Depth;
+            #local PArr[J][K] = P + H*Dir*Depth;

-            #declare K = K+1;
+            #local K = K+1;
          #end
-        #declare J = J+1;
+        #local J = J+1;
      #end

      HFCreate_()
...

This makes for confusing code, but it doesn't break things because the 
identifier is seen as already defined locally... In other words, those 
#declares don't create new 'global' identifiers, but rather, they 
redefine the locally defined identifier.

What this means more generally is we cannot arbitrarily create an 
identifier in the global name space with #declare where it has first 
been defined (added to the symbol table) with #local in the local macro 
space.

(**) - Something foggy still for me. I 'believe' it is still true that 
#local definitions sitting unwrapped by a macro in the top level scene 
file act as global #declares, but, I've not tested this with the new 
local and global dictionary access qualifiers in v3.8. Maybe at the top 
scene file the local and global dictionaries become the same thing?


Post a reply to this message

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