 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I have a dictionary in 3.8 and one of the elements is an array.
I'm trying to write the definitions out to a text file:
#macro WriteTileSet(fname)
#fopen TILE fname write
#for(I, 0, MaxEntropy-1, 1)
#write (TILE, "#declare TileSet[", S(I), "] = dictionary {\n")
#write (TILE, " .name = ", TileSet[I].name, ";\n")
#write (TILE, " .edges = array[", S(TileEdges),"] {"
#for(E, 0, TileEdges-1, 1)
#write (TILE, TileSet[I].edges[E], ", ")
#end
#write (TILE, "};\n")
#write (TILE, " .pidx = ", S(TileSet[I].pidx),";\n")
#write (TILE, " .rot = ", S(TileSet[I].rot), ";\n")
#write (TILE, "}\n"
#end // for I
#fclose TILE
#end
And I'm getting an error:
Parse Error: Can't nest directives accessing the same file.
Is there a way around this? I don't want to have to manually write each
element out.
I think it requires another macro to convert the .edges element to a
string that I can then slap into the #write directive. Is this the only
way or am I missing something?
Uncle Josh
Josh
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
Josh English <Jos### [at] joshuarenglish com> wrote:
> I have a dictionary in 3.8 and one of the elements is an array.
> ...
> And I'm getting an error:
> Parse Error: Can't nest directives accessing the same file.
> Is there a way around this? I don't want to have to manually write each
> element out.
> I think it requires another macro to convert the .edges element to a
> string that I can then slap into the #write directive. Is this the only
> way or am I missing something?
I've been looking at (un)serialising dictionaries using my 'Filed()' macro[*],
and have not yet found a "good way" for dealing with arrays, especially
multi-dimensional. I think converting the array to a string, and storing that,
will work, eg "3.1415:1.23:0.1" for an array of three floats; have a look at my
'strSplit()' macro[**] for the unserialising.
[*] <wiki.povray.org/content/User:Jr>
[**] <news.povray.org/web.64b08576d08f3556b49d80446cde94f1%40news.povray.org>
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/5/25 21:42, Josh English wrote:
> And I'm getting an error:
>
> Parse Error: Can't nest directives accessing the same file.
You are missing a couple of closing parens.
#macro WriteTileSet(fname)
#fopen TILE fname write
#for(I, 0, MaxEntropy-1, 1)
#write (TILE, "#declare TileSet[", S(I), "] = dictionary {\n")
#write (TILE, " .name = ", TileSet[I].name, ";\n")
#write (TILE, " .edges = array[", S(TileEdges),"] {" // <--
#for(E, 0, TileEdges-1, 1)
#write (TILE, TileSet[I].edges[E], ", ")
#end
#write (TILE, "};\n")
#write (TILE, " .pidx = ", S(TileSet[I].pidx),";\n")
#write (TILE, " .rot = ", S(TileSet[I].rot), ";\n")
#write (TILE, "}\n" // <---
#end // for I
#fclose TILE
#end
The parser is seeing another #write directive start, while being in the
middle of parsing a prior #write directive. As long as the .edges
element is a string, you should be on your way after adding the closing
parens.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/5/2025 10:47 PM, William F Pokorny wrote:
> On 7/5/25 21:42, Josh English wrote:
>> And I'm getting an error:
>>
>> Parse Error: Can't nest directives accessing the same file.
>
> You are missing a couple of closing parens.
>
>
> Bill P.
AAARGH! Thank you. Yeah, that was the problem (and the missing quotation
marks in the resulting text file).
I wish the Windows UI had a better way to tell me where the errors
actually are. I make mistakes like this and it fails in some other part
of the code.
I want to build a linter for POV-Ray some day, maybe that will help.
Thank you again.
Josh
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/5/2025 9:05 PM, jr wrote:
> hi,
>
> Josh English <Jos### [at] joshuarenglishcom> wrote:
>> I have a dictionary in 3.8 and one of the elements is an array.
>> ...
>> And I'm getting an error:
>> Parse Error: Can't nest directives accessing the same file.
>> Is there a way around this? I don't want to have to manually write each
>> element out.
>> I think it requires another macro to convert the .edges element to a
>> string that I can then slap into the #write directive. Is this the only
>> way or am I missing something?
>
> I've been looking at (un)serialising dictionaries using my 'Filed()' macro[*],
> and have not yet found a "good way" for dealing with arrays, especially
> multi-dimensional. I think converting the array to a string, and storing that,
> will work, eg "3.1415:1.23:0.1" for an array of three floats; have a look at my
> 'strSplit()' macro[**] for the unserialising.
>
> [*] <wiki.povray.org/content/User:Jr>
> [**] <news.povray.org/web.64b08576d08f3556b49d80446cde94f1%40news.povray.org>
>
>
> regards, jr.
>
I'll look into it. I've found it's generally easier just to build an
include file that can be imported later than trying to manage
customizing serialization.
Now if POV-Ray 4.0 could read and write JSON or XML, I'd be in heaven,
but I don't think that's in the plans.
Uncle Josh
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Josh English <Jos### [at] joshuarenglishcom> wrote:
> AAARGH! Thank you. Yeah, that was the problem (and the missing quotation
> marks in the resulting text file).
>
> I wish the Windows UI had a better way to tell me where the errors
> actually are. I make mistakes like this and it fails in some other part
> of the code.
>
> I want to build a linter for POV-Ray some day, maybe that will help.
So, this is a common problem, with start and end bracketing "directives" or
whatever we call them
#if #end
#while #end
texture { }
function { }
etc
I use large (5-space) TABS to maximize the visual placing of the start and end
of my code blocks.
I have also (mostly) trained myself to type the opening AND closing parts first,
and then fill in the space between.
On top of that, if I'm not being lazy, I specifically comment my closing
directive to match the opening one. I will number or name nested code blocks.
"Outer", "Middle", "Inner"
"#if 1", "#if 2", "#if 3"
I wrote a bunch of macros to help keep track of where in the hierarchy I am when
my code craps out.
Maybe someone can suggest a command-line script to grep opening and closing
parentheses and give a count.
Might be able to paste it into a spreadsheet and get a count that way.
- BE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> I have also (mostly) trained myself to type the opening AND closing parts first,
> and then fill in the space between.
very good practice/advice. fwiw, a suitable editor helps, for instance using
'vim' makes jumping between opening and closing brace/parenthesis/bracket a
single (shifted) key press.
> ...
> Maybe someone can suggest a command-line script to grep opening and closing
> parentheses and give a count.
not totally what you're after, you only get the line count of occurrence, but,
in practice, the opening/closing counts should be the same. (no time to write a
script, sorry :-))
$ grep -ce '[{]' myscene.pov
$ grep -ce '[}]' myscene.pov
> Might be able to paste it into a spreadsheet and get a count that way.
do you use 'sc(1)' ?
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > ...
> > Maybe someone can suggest a command-line script to grep opening and closing
> > parentheses and give a count.
>
> not totally what you're after, ...(no time to write a script, sorry :-))
no script, but a (simple) re-purposed program (named "brace parenthesis bracket
counts"), attached. compile with:
$ gcc -std=c99 -O2 -o bpbcounts bpbcounts.c
(sorry, no spreadsheet importer :-))
enjoy, jr.
Post a reply to this message
Attachments:
Download 'bpbcounts.c.txt' (2 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 07/07/2025 18:43, jr wrote:
> "jr" <cre### [at] gmailcom> wrote:
>> "Bald Eagle" <cre### [at] netscapenet> wrote:
>>> ...
>>> Maybe someone can suggest a command-line script to grep opening and closing
>>> parentheses and give a count.
>>
>> not totally what you're after, ...(no time to write a script, sorry :-))
>
> no script, but a (simple) re-purposed program (named "brace parenthesis bracket
> counts"), attached. compile with:
>
> $ gcc -std=c99 -O2 -o bpbcounts bpbcounts.c
>
> (sorry, no spreadsheet importer :-))
>
>
> enjoy, jr.
A long time ago, I started doing the same thing (but in Perl). I stopped
because I got stuck on a problem: even if the number of pairs is
correct, the syntax isn't necessarily right. You could be missing a
brace in one place and have one too many in another. All in all, the
count is good, but the syntax is not.
But indeed, this kind of script already gives good indications.
--
kurtz le pirate
compagnie de la banquise
Post a reply to this message
Attachments:
Download 'analyser.pl.zip' (3 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/7/2025 7:28 AM, Bald Eagle wrote:
> Josh English <Jos### [at] joshuarenglishcom> wrote:
>
>
> So, this is a common problem, with start and end bracketing "directives" or
> whatever we call them
>
> #if #end
> #while #end
> texture { }
> function { }
> etc
>
> I use large (5-space) TABS to maximize the visual placing of the start and end
> of my code blocks.
Yeah, I should get into that practice. I don't do that in any other
language, though, so I suspect an uphill battle.
>
>
> Maybe someone can suggest a command-line script to grep opening and closing
> parentheses and give a count.
I might be able to scribble out some Python to do that, come to think of it.
Uncle Josh
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/7/2025 8:40 AM, jr wrote:
>
> very good practice/advice. fwiw, a suitable editor helps, for instance using
> 'vim' makes jumping between opening and closing brace/parenthesis/bracket a
> single (shifted) key press.
I have tried to use vim, but I have fallen into the convenience of the
Run button in the Windows UI. I have a Linux Mint machine but haven't
found a nice workflow with POV-Ray and Vim.
Uncle Josh
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
kurtz le pirate <kur### [at] freefr> wrote:
> ...
> A long time ago, I started doing the same thing (but in Perl). ...
way more ambitious though, line numbers ! :-). I don't "speak" perl, and ran
into trouble when i tried the script (for which thanks) on a Debian VM; attached
a screenshot.
regards, jr.
Post a reply to this message
Attachments:
Download 'screenshot 2025-07-09 08.18.58.png' (42 KB)
Preview of image 'screenshot 2025-07-09 08.18.58.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
Josh English <Jos### [at] joshuarenglishcom> wrote:
> On 7/7/2025 8:40 AM, jr wrote:
> > ... 'vim' makes jumping ... a single (shifted) key press.
>
> I have tried to use vim, but I have fallen into the convenience of the
> Run button in the Windows UI. I have a Linux Mint machine but haven't
> found a nice workflow with POV-Ray and Vim.
looked but cannot, of course, now find the reference. :-) LeForgeron (I think)
posted an image / chart depicting his setup. I use the below in my '~/.vimrc',
which is based on / derived from that "tip". my "workflow" when writing scene
code is to occasionally do a ":make" to confirm there are no typos etc, ie am at
that point only interested in the parsing; for that I have a dedicated
"one-liner" shell script, "povparse", also below. workflows are v individual,
but LeForgeron's "method" works for me.
regards, jr.
-----<snip>-----
"
au Filetype pov setlocal makeprg=povparse\ +i%
au Filetype povini setlocal makeprg=povparse\ %
au BufRead,BufNewFile, *.ini set filetype=povini
-----<snip>-----
#!/bin/sh
/usr/bin/nice -n 19 /usr/local/bin/povray-3.8.0-beta.2 +w32 +h32 -d -f -p -gr
-gs $*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmailcom> wrote:
> kurtz le pirate <kur### [at] freefr> wrote:
> > ...
> > A long time ago, I started doing the same thing (but in Perl). ...
>
> way more ambitious though, line numbers ! :-). I don't "speak" perl, and ran
> into trouble when i tried the script (for which thanks) on a Debian VM; attached
> a screenshot.
ignore. the trouble was the 1st line, all good w/out that comment line.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 09/07/2025 09:25, jr wrote:
> hi,
>
> kurtz le pirate <kur### [at] freefr> wrote:
>> ...
>> A long time ago, I started doing the same thing (but in Perl). ...
>
> way more ambitious though, line numbers ! :-). I don't "speak" perl, and ran
> into trouble when i tried the script (for which thanks) on a Debian VM; attached
> a screenshot.
>
>
> regards, jr.
A yes, the script uses the "File::Basename" module, which is not present
in your system. I use cpan to install/manage modules. More infos here :
<https://wiki.debian.org/PerlFAQ> :.
cpan
install File::Basename
more ambitious : yes, lines numbers, list of vars and where vars are
used. but it's a wip...
--
kurtz le pirate
compagnie de la banquise
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
kurtz le pirate <kur### [at] freefr> wrote:
> On 09/07/2025 09:25, jr wrote:
> > ...
> > way more ambitious though, line numbers ! :-). ...
> ...
> more ambitious : yes, lines numbers, list of vars and where vars are
> used. but it's a wip...
agree, a list of the variables and so on is very useful to have, in particular
when "playing" with unfamiliar (someone else's :-)) code.
I don't know MacOS, do you have/use the 'less' and 'vim' programs ? both can
use "tags" files created by 'ctags'. that program, patched[*], can give you
variables, and usage; for instance below the first few lines output based on one
of your scenes (Oct 31st 2023):
$ ectags --sdl-kinds=v -ux pursuitcurve.pov
displayAxis variable 33 pursuitcurve.pov #declare displayAxis = false;
displayPlane variable 34 pursuitcurve.pov #declare displayPlane = false;
AxisLen variable 37 pursuitcurve.pov #declare AxisLen = 16;
Scale variable 39 pursuitcurve.pov #declare Scale =
AxisLen/image_width;
C variable 115 pursuitcurve.pov #local C =
_Brightness*_Saturation;
X variable 116 pursuitcurve.pov #local X = C - (1 -
abs(mod(_Hue/60,2) - 1));
m variable 117 pursuitcurve.pov #local m = _Brightness-C;
....
only requesting variables, the '-ux' selects an unsorted cross-reference format
to console/terminal; when invoked without options, it'll write a "tags" file.
[*] <drive.google.com/file/d/10ikrIHkMopedFPlq6V4YhnnNn3sY59hC/view?usp=sharing>
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/07/2025 20:30, jr wrote:
> hi,
>
> kurtz le pirate <kur### [at] freefr> wrote:
>> On 09/07/2025 09:25, jr wrote:
>>> ...
>>> way more ambitious though, line numbers ! :-). ...
>> ...
>> more ambitious : yes, lines numbers, list of vars and where vars are
>> used. but it's a wip...
>
> agree, a list of the variables and so on is very useful to have, in particular
> when "playing" with unfamiliar (someone else's :-)) code.
>
> I don't know MacOS, do you have/use the 'less' and 'vim' programs ? both can
> use "tags" files created by 'ctags'. that program, patched[*], can give you
> variables, and usage; for instance below the first few lines output based on one
> of your scenes (Oct 31st 2023):
Yes, i have less and vim.
I'm not familiar with this type of tags/ctags
> $ ectags --sdl-kinds=v -ux pursuitcurve.pov
> displayAxis variable 33 pursuitcurve.pov #declare displayAxis = false;
> displayPlane variable 34 pursuitcurve.pov #declare displayPlane = false;
> AxisLen variable 37 pursuitcurve.pov #declare AxisLen = 16;
> Scale variable 39 pursuitcurve.pov #declare Scale =
> AxisLen/image_width;
> C variable 115 pursuitcurve.pov #local C =
> _Brightness*_Saturation;
> X variable 116 pursuitcurve.pov #local X = C - (1 -
> abs(mod(_Hue/60,2) - 1));
> m variable 117 pursuitcurve.pov #local m = _Brightness-C;
> ....
>
> only requesting variables, the '-ux' selects an unsorted cross-reference format
> to console/terminal; when invoked without options, it'll write a "tags" file.
>
> [*] <drive.google.com/file/d/10ikrIHkMopedFPlq6V4YhnnNn3sY59hC/view?usp=sharing>
I'll take a look.
> regards, jr.
;)
--
kurtz le pirate
compagnie de la banquise
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
