POV-Ray : Newsgroups : povray.pov4.discussion.general : User changes. yuqk / v4. Options re-work status. : User changes. yuqk / v4. Options re-work status. Server Time
21 Jun 2025 08:04:02 EDT (-0400)
  User changes. yuqk / v4. Options re-work status.  
From: William F Pokorny
Date: 11 Jun 2025 23:21:27
Message: <684a47b7$1@news.povray.org>
User changes. yuqk / v4. Options re-work status.

The current output related option(s):

declare=<name>= <float or string> value only

become(s):

+-ub_   user_bool_filename=    string value only
+-ui_   user_int_filename=     string value only
+-uf_   user_flt_filename=     string value only
+-us_   user_str_filename=     string value only
+-uv2f_ user_vec2d_filename=   string value only
+-uv3f_ user_vec3d_filename=   string value only
+-uv4f_ user_vec4d_filename=   string value only
+-uv5f_ user_vec5d_filename=   string value only
+-um_   user_matrix_filename=  string value only

Add set of standard user boolean switch names.
  +-uof_00  user_on_off_00=   on|off

+-ux_    user_execute_filename= string value only
          (Thought is to let users create user input files
           with whatever scripting, programming language
           they wish during options parsing)

Only the rough outline above. No integrated code. (I have a couple 
standalone test file parsing programs running)

I'll mention here, one of the aims of these option updates is to make 
nearly all (all?) option settings available via new inbuilt functions in 
the parser(*). An option name string being passed as the query key. In 
limited testing this works, but I've not implemented / tried the vectors 
or matrix stuff above. Those will need more code to truly be integrated 
during parsing.

The overall thinking is to implement something more powerful than 
'declare=...'.

The filenames used would be space delimited and use ascii-string(fast) 
(or maybe std::string utf8) keys. The same inbuilt functions used as 
option settings at parse time would be used to access these values by 
key(**), while new inbuilt functions would be required to support vector 
/ matrix input (or direct use?).

Aside: Values set with these user files would be guaranteed, top level, 
read only, 'globals'. There are outstanding issues with the v3.8 global 
dictionary implementation that I've never gotten sorted. (I believe the 
local dictionary implementation in V3.8 is OK / clean.)

Bill P.

(*) - The declare feature identifiers, image_width, image_height and 
maybe a half dozen more 'apparent keywords' are, internally, unprotected 
identifiers. This is an opening for difficult SDL bugs. This said, I 
don't plan to delete these 'apparent keywords' any time soon. I do plan 
to remove the declare option.

(**) - Yes, need sanity checking to be sure users don't try to set 
'option strings' via any of these user input files...


Post a reply to this message

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