While recently coding a long and complex scene, I came across a very subtle
problem when using the  /* .... */  comment block, that caused the parsing of
the scene to fail. I had to tear my code apart piece by piece to find it!

Within a large block of code, I had written a line like this (which has a
mistake in it that I didn't notice):
#declare FOO = 27;  //*3
...just as a way to remind myself to try multiplying the 27 by 3 later.

As-is, the scene parsed and rendered fine. But what  I *meant* to write was:
#declare FOO=27; //   *3

SO...
While continuing to experiment with the scene, I happened to use /* and */ to
comment-out that entire block of code-- which also contained the line with the
mistake.

Now, the scene fails:  "Parse error-- No  */ closing comment found." The parser
apparently sees  part of my   //*3  as  /* -- but only when
another 'complete'  /* ...*/  comment block is enclosing it.

After finding my error, what surprised me is that the scene originally parsed
OK...when it should not have, in my opinion. I think POV-ray should have caught
my initial mistake, and with the same error message.  Adding the /* and */ later
was the only way to 'discover' it...after a lot of head-scratching and
puzzlement. Maybe the *double*-slash-marks-and-asterik prevented the parser from
initially recognizing the error?

Of course, the mistake itself was my own; I can't blame POV-ray for THAT!  ;-)

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> While recently coding a long and complex scene, I came across a very subtle
> problem when using the  /* .... */  comment block, that caused the parsing of
> the scene to fail. I had to tear my code apart piece by piece to find it!
>
> Within a large block of code, I had written a line like this (which has a
> mistake in it that I didn't notice):
> #declare FOO = 27;  //*3
> ...just as a way to remind myself to try multiplying the 27 by 3 later.
>
> As-is, the scene parsed and rendered fine. But what  I *meant* to write was:
> #declare FOO=27; //   *3
>
> SO...
> While continuing to experiment with the scene, I happened to use /* and */ to
> comment-out that entire block of code-- which also contained the line with the
> mistake.
>
> Now, the scene fails:  "Parse error-- No  */ closing comment found." The parser
> apparently sees  part of my   //*3  as  /* -- but only when
> another 'complete'  /* ...*/  comment block is enclosing it.
>
> After finding my error, what surprised me is that the scene originally parsed
> OK...when it should not have, in my opinion. I think POV-ray should have caught
> my initial mistake, and with the same error message.  Adding the /* and */ later
> was the only way to 'discover' it...after a lot of head-scratching and
> puzzlement. Maybe the *double*-slash-marks-and-asterik prevented the parser from
> initially recognizing the error?
>
> Of course, the mistake itself was my own; I can't blame POV-ray for THAT!  ;-)

I had to play with this a little and found another fact.
/* wrrtr
//*3
fdssdds
*/
*/
With this in to code POV still ran with no errors.
Even through the last '*/' doesn't turn green in the win Pov 3.7 editor.
Have Fun!

Post a reply to this message

"Leroy" <whe### [at] gmailcom> wrote:

> /* wrrtr
> //*3
> fdssdds
> */
             <------
> */


I think you're going to need some actual code in the marked area to properly
check.

- BW

Post a reply to this message

On 12/20/24 07:43, Kenneth wrote:
> #declare FOO = 27;  //*3
> ...just as a way to remind myself to try multiplying the 27 by 3 later.
> 
> As-is, the scene parsed and rendered fine. But what  I*meant* to write was:
> #declare FOO=27; //   *3
> 
> SO...
> While continuing to experiment with the scene, I happened to use /* and */ to
> comment-out that entire block of code-- which also contained the line with the
> mistake.
> 
> Now, the scene fails:  "Parse error-- No  */ closing comment found." The parser
> apparently sees  part of my   //*3  as  /* -- but only when
> another 'complete'  /* ...*/  comment block is enclosing it.
> 
> After finding my error, what surprised me is that the scene originally parsed
> OK...when it should not have, in my opinion. I think POV-ray should have caught
> my initial mistake, and with the same error message.

It's my view '//*3' isn't a mistake, but a valid comment which the 
parser should be ignoring no matter whether it's nested inside a /*..*/ 
block comment or not.

Leroy's test case of:

/* wrrtr
//*3
fdssdds
*/
*/

is a good one because the integrated editor in the windows binaries must 
be ignoring '//' and anything after as a stand alone comment.

When I bring up his example in vim/gvim the syntax checking for both 
POV-Ray 3.7 and yuqk highlight that last '*/' as an error. So, in vim 
too the '//' is treated as a stand alone comment whether nested in 
another comment or not.

---
FWIW.

Your problem code is something the newer parser clipka coded up reports 
better than the older parser.

The follow code:

/*  this is line 2

#declare FOO = 27;  //*3

*/

Generates messages like: "Parse Error: No */ closing comment found." in 
the older parsers.

The newer parser (in the POV-Ray master branch and a derivative of it is 
the parser used in yuqk) will kick out messages like:

"File 'kenneth.pov' line 2: Parse Error: Unterminated block comment in 
input file."

Or yuqk's:

File 'kenneth.pov' line 2:
Parse Error:
Unterminated block comment in input file.

The messages from the newer parser give better hints as to where to 
start looking for issues with block commenting.

---

Anyhow. I agree this a bug in all parser versions - but due flagging 
your valid code comments as a problem and treating Leroy's example as OK.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> It's my view '//*3' isn't a mistake, but a valid comment which the
> parser should be ignoring no matter whether it's nested inside a /*..*/
> block comment or not.

That is an interesting alternate viewpoint! I had assumed that my //*3
was 'bad amateurish code-writing'. In other programming languages which use
the /*...*/ construct for comments, is //*3 regarded as a perfectly valid way to
write a *single line* comment in the way that I had in mind, without an extra
'separator' space before the  *3?

> Leroy's test case of:
>
> /* wrrtr
> //*3
> fdssdds
> */
> */
>
> is a good one because the integrated editor in the windows binaries must
> be ignoring '//' and anything after as a stand alone comment.

Yes, Leroy's is an interesting example; I did not test such a construct as that.
I re-wrote it a different way, to get a better understanding of your
explanation:

/* wrrtr
//*3
#declare BAR = 8;
*/
*/

#debug concat("\n","BAR = ",str(BAR,0,0),"\n") // This fails; there is no BAR as
a variable. It is simply part of the 'inner' comment block.

And the final additional */ closes the 'outer' comment block, avoiding the
original error message of "no closing comment found".

In my original scene, when my 'mistake' first triggered the error and presented
the fatal warning, I did think of just adding the additional 'required' */ as an
expedient way of solving the problem-- but I was not sure *where* to put it! (I
see now that I could have simply inserted it at the end of my big commented-out
code block, with no harm done.) But, that would have been too easy! and would
have prevented me from finding my own 'mistake' ;-)

>
> Your problem code is something the newer parser clipka coded up reports
> better than the older parser.

> The newer parser (in the POV-Ray master branch and a derivative of it is
> the parser used in yuqk)...

[I am running 3.8 beta 1 in Windows; sorry that I did not mention it earlier]
Did Clipka's newer parser make it into beta 2? Or was it 'backtracked' (not
included) in either of the betas, along with a few other previous features?

Post a reply to this message

On 12/21/24 04:25, Kenneth wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>>
>> It's my view '//*3' isn't a mistake, but a valid comment which the
>> parser should be ignoring no matter whether it's nested inside a /*..*/
>> block comment or not.
> 
> That is an interesting alternate viewpoint! I had assumed that my //*3
> was 'bad amateurish code-writing'. In other programming languages which use
> the /*...*/ construct for comments, is //*3 regarded as a perfectly valid way to
> write a *single line* comment in the way that I had in mind, without an extra
> 'separator' space before the  *3?
> 

Computer languages are legion... The strict answer is I don't know.

Both C and C++ (gnu) treat the //*3 (or //*) within a /*...*/ comment 
block as a stand alone comment and compile fine.

That said, the Ubuntu distribution shipped C and C++ vim/gvim syntax 
files DO mark the second slash ahead of the '*' character as a 
'potential error' when it is nested within a /*..*/ block style comment 
(***).

So, those supporting the C/C++ vim syntax files do consider the lack of 
a space after the '//' and ahead of a '*' character to be bad comment 
coding practice when within a block comment.

(***) - Something I didn't know until trying things just now :-). Maybe 
I'll take a look to see if I can adopt that checking for the yuqk SDL, 
vim syntax file as I do agree '//*' isn't good comment practice in 
languages supporting both the // and /*...*/ comment styles.

>> Leroy's test case of:
>>
>> /* wrrtr
>> //*3
>> fdssdds
>> */
>> */
>>
>> is a good one because the integrated editor in the windows binaries must
>> be ignoring '//' and anything after as a stand alone comment.
> 
> Yes, Leroy's is an interesting example; I did not test such a construct as that.
> I re-wrote it a different way, to get a better understanding of your
> explanation:
> 
> /* wrrtr
> //*3
> #declare BAR = 8;
> */
> */
> 
> #debug concat("\n","BAR = ",str(BAR,0,0),"\n") // This fails; there is no BAR as
> a variable. It is simply part of the 'inner' comment block.
> 
> And the final additional */ closes the 'outer' comment block, avoiding the
> original error message of "no closing comment found".
> 
> In my original scene, when my 'mistake' first triggered the error and presented
> the fatal warning, I did think of just adding the additional 'required' */ as an
> expedient way of solving the problem-- but I was not sure *where* to put it! (I
> see now that I could have simply inserted it at the end of my big commented-out
> code block, with no harm done.) But, that would have been too easy! and would
> have prevented me from finding my own 'mistake' ;-)
> 
>>
>> Your problem code is something the newer parser clipka coded up reports
>> better than the older parser.
> 
>> The newer parser (in the POV-Ray master branch and a derivative of it is
>> the parser used in yuqk)...
> 
> [I am running 3.8 beta 1 in Windows; sorry that I did not mention it earlier]
> Did Clipka's newer parser make it into beta 2? Or was it 'backtracked' (not
> included) in either of the betas, along with a few other previous features?
> 

IIRC. During clipka's return of some months after his first long period 
away, he 'backtracked' the parser to an earlier, non-new version - along 
with quite a bit of other code ahead of the two v3.8 beta releases. Both 
v3.8 betas are using the older parser.

Aside: This general 'backtracking' is also related to why we are seeing 
the recent boost library issues with newer linux / unix distributions 
when building v3.8 beta 2.

I've never compiled a complete list of 'stuff' backtracked. I was 
nervous at the time it happened as, during an intended final beta phase, 
we jumped backward to code states our community as a whole had not been 
running - for years. Today, I suppose it is what most of us running v3.8 
have been running since mid to late 2021...

Aside 2: Before I broke away with yuqk (formerly povr), I'd been the one 
running all the shipped v3.8 scenes (and additional test cases of my 
own) periodically during v3.8 development. To my recollection / 
knowledge this sort of more complete testing has never been done for the 
'backtracked' beta 1 & 2 releases. FWIW.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> I've never compiled a complete list of 'stuff' backtracked. I was
> nervous at the time it happened as, during an intended final beta phase,
> we jumped backward to code states our community as a whole had not been
> running - for years. Today, I suppose it is what most of us running v3.8
> have been running since mid to late 2021...
>

Since installing beta 1, I have made a *few* notes to myself as to the
changes/problems/backtracking I have run across (and a few solutions)-- but they
are spread out among disparate scene files...and I sometimes have to painfully
re-discover what I had already written :-/

Maybe Bald Eagle has been compiling such a list-- as part of his own
'encyclopedic' spreadsheet of POV-ray hints-and-tips and newsgroup links!
(--hint hint --)

-------
BTW: In the world of computing, is there an actual standardized *name* for
    /*  or  */   ??
In my current scene comments, I have been writing "slash-and-asterik" -- so that
I don't inadvertently create yet *another* strange coding error by using /*
instead! But that surely gets cumbersome to write again and again.

Post a reply to this message

On 12/21/24 09:42, Kenneth wrote:
> BTW: In the world of computing, is there an actual standardized*name* for
>      /*  or  */   ??

I'm not aware of a standard name.

I wonder what our own POV-Ray documentation says about comments. Ah, 
it's pretty basic - no name for the style. Ref:

https://wiki.povray.org/content/Reference:Comments

I don't myself use 'open-indicator to close-indicator' block style 
comments - as a rule. Rather the single line forms like '//' - even for 
multiple line comments. Editors like vim handle vim handle multi-line // 
comment blocks reasonably well.

Where I need to 'turn off' a block of code - or switch between options - 
while working I'll use the following over a /*..*/ block style comment:

#if (0)   // ????
   ...
#end

or

#if (0)   // ????
   ...
#else
   ...
#end

Changing the '0' to '1' to 'turn on' code again or to flip between 
versions of code under test.

The "????" string is my personal 'hook' to be sure I later clean up 
temporary debug or development actions like this.

FWIW. Coding styles are varied and are affected too by the coding 
environment (the editor used, etc.).

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 12/21/24 09:42, Kenneth wrote:
> > BTW: In the world of computing, is there an actual standardized*name* for
> >      /*  or  */   ??
> I'm not aware of a standard name.
> ...
> I don't myself use 'open-indicator to close-indicator' block style
> comments - as a rule. Rather the single line forms like '//' - even for
> multiple line comments. ...

personally, I think that the "C-style commenting" has two advantages over the
to-end-of-line construct.  the obvious is long comments being wrapped and
mistaken (by parser) for code; a real bitch when one's unfamiliar with the code.
 the second is more of a personal aesthetic/preference, so

code
more code

/* separated, or "broken up", by comments which stand out visually
 * when formatted like so, are "easy" on my eyes.  :-)
 */

code
yet mode code



but, as with all, "YMMV".


regards, jr.

Post a reply to this message

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

> I don't myself use 'open-indicator to close-indicator' block style
> comments - as a rule.

On a side note, the block style commenting is very useful for processing other
content in
...pov-files. For example literate programming.

/*$redlines
......
*/

can be a explanation, tutorial, block that goes with a macro below it, while

#macro redlines(thickness, roundness, ...)
/*:redlines(thickness, roundness, ...)
parameters:
thickness (float): ....
roundness (float): ....

result:
......
*/

........macro code

#end

can be used for documentation of that macro. All information goes in the .pov
file and with a proper untangle software one could extract the documentation and
a tutorial.

ingo

Post a reply to this message