#read by whole line - everything gets read into one long string.
This would allow user parsing of the string, regardless of data types,
structure, number of entries, etc.

matrix <>, but allowing x, y, and z in the definitions of the coefficients.
This would allow the desirable but elusive non-linear scaling of primitives, and
well as other interesting transformations such as progressive rotations.
With this, we could "effortlessly" do things with primitives that are currently
only possible with isosurfaces.

Speed parsing - I believe that we currently have mechanisms in the parser to
pretty much ignore everything between /* and */, and anything that starts with
//

The idea would be to selectively / switchably mimic that behavior in order to
"scan" an include file and not have to character-by-character parse every
(unneeded) line.
Kinda like the dreaded GOTO, but since we're progressively parsing a file in a
linear fashion, I think it's appropriate and would be ok.
This is related to the Monolithic Include File idea - I'd want to have the
parser "glance" at the beginning of each line, and skip it until it reached a
block of code that I actually wanted to include.
Perhaps there could be a "file section" designator, where the parser skips
everything, until it hits that.  Like fseek ()

junk
junk
junk
[Parse this]
code
code
[end parsing
junk
junk
eof

Might be a better way to do that, but the key is that everything can reside in a
single include file, and there won't be a million puzzle pieces to get lost.

I had also once suggested support for other file formats to allow "bundling".
Like .tar

Not like this is an original idea:
https://news.povray.org/povray.programming/thread/%3C36C0CEFC.41AEA1BD%40bravo436.chem.mcgill.ca%3E/

- BW

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> #read by whole line - everything gets read into one long string.
> This would allow user parsing of the string, regardless of data types,
> structure, number of entries, etc.

I like this Idea!
I have been playing with pgn files, chess format file. They are fancy text
files with a list of all the moves in a game with a lot of other information
like the tournament, players, rankings and so on. It would be nice to read all
that info and drop it line by line until I got to something I want.
 Right now I do it by hand by copying text to another file and getting it sit up
for POV to Read. I could write a C++ program to do it for me, but I like POV.
 Right Now 3.8 can handle strings larger that 255 elements, But Can't load them
from a file. (3.7 seem to handle strings the same way.)
 If a line read is to complicated to do, for some reason, then a binary read
would be almost as good. Say read so many bytes at time and return as a integer.

Have Fun!

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> #read by whole line - [...]

// is the simple one, once you have detected it just skip to end of line.

/* is trickier, you have to scan characters until you find */ and then POV-Ray
supports nested multiline comments. So if you find a second /* in a comment you
either have to start a counter or use recursion otherwise you'll miss the true
end of the comment.

Lots of parsers are clever, they can skip parts of words when they are sure that
there is no other option than that specific keyword even if they are only half
way parsing that word. But in the end you still have to visit a lot of
characters.

My POV-Ray HTML highlighter (https://ingoogni.nl/download/) parses a POV-Ray
file using regular expressions, not the most elegant way to do it. It properly
handles the nested comments.

ingo

Post a reply to this message

"Leroy" <whe### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > #read by whole line - everything gets read into one long string.
> > This would allow user parsing of the string, regardless of data types,
> > structure, number of entries, etc.
>
> I like this Idea!
> I have been playing with pgn files, chess format file. They are fancy text
> files with a list of all the moves in a game with a lot of other information
> like the tournament, players, rankings and so on. It would be nice to read all
> that info and drop it line by line until I got to something I want.
>  Right now I do it by hand by copying text to another file and getting it sit up
> for POV to Read. I could write a C++ program to do it for me, but I like POV.
>  Right Now 3.8 can handle strings larger that 255 elements, But Can't load them
> from a file. (3.7 seem to handle strings the same way.)
>  If a line read is to complicated to do, for some reason, then a binary read
> would be almost as good. Say read so many bytes at time and return as a integer.
>
> Have Fun!

I went into the source code for the win3.6 and found that there is already a
line read function there. That reads a line and puts into a buffer. So all that
is needed is to figure out how to access the code. I vote to add '#read_line' to
the parsing stage. easy! peasy!

having Fun!

Post a reply to this message

On 3/25/25 14:10, Leroy wrote:
> I vote to add '#read_line' to
> the parsing stage. easy! peasy!

I've been thinking about something like #utf8_readline() and 
#utf8_writeline() in my yuqk fork playpen. These would fully support 
utf8 within the constraints of the Unicode BMP (2^16 characters).

In implementation they'd completely bypass all the input/output stuff 
and character set up in the POV-Ray source today. Every time I start to 
look at moving the current source to full utf8 support, I quickly get 
overwhelmed by the totality of conversion necessary.

Anyhow, the implementation of the two utf8_* functions would be ugly to 
start... Likely, they'd initially open and close the file on every call, 
for example.

Bill P.

Post a reply to this message