 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/21/23 07:43, Kenneth wrote:
> Well... In the light of a new day, I remembered that I had seen that
> *somewhere*; it's not an "obscure built-in identifier" 😅 It's just 'a name'
> or variable-- part of an #ifdef block at the top of every 'official' POV-ray
> include file, with a simple #debug statement:
>
> #ifdef(View_POV_Include_Stack)
> #debug "including arrays.inc\n"
> #end
>
> It's just a useful/descriptive phrase that someone came up with in the past.
> Which explains why adding #declare View_POV_Include_Stack = true; at the
> top of your main scene file results in a list of those #included files in
> 'messages'. Duh. No special magic.
With my povr branch I have for a while been set up with two basic
targeted compiles.
One is a debug option with a lot of extra checking and reporting
enabled. The other is the day to day rendering version to be used when
things are going well.
The idea is to use the faster one as a rule.
However, on seeing flaky behavior, or when just wanting to do more
robust checking of your scene to find what evil is lurking - run the
debug compile version.
On reading your post I had the thought, why not add some detailed
include information to the targeted debug compile version of povr. I did
- and the output currently looks like:
==== [Parsing...] ==============================================
Debug: #include "functions.inc"
Debug: #include "/run/shm/tmpDir/povrayB/include/transforms.inc"
Debug: #include "/run/shm/tmpDir/povrayB/include/math.inc"
Debug: #include "functions.inc"
Debug: #include "/run/shm/tmpDir/povrayB/include/setidtypes.inc"
Debug: #include "/run/shm/tmpDir/povrayB/include/vectors.inc"
Debug: #include "/run/shm/tmpDir/povrayB/include/vectors.inc"
Debug: #include "/run/shm/tmpDir/povrayB/include/math.inc"
Debug: #include "/tmp/otherInc/whackJob.inc"
This information which I'll find useful on occasion too! Oh, the scene
has only these four includes:
#include "functions.inc"
#include "transforms.inc"
#include "math.inc"
#include "whackJob.inc"
So, the larger reported set is due some of those includes having
includes too. With well formed include files, only the first in the
debug output is really used.
On using: #declare View_POV_Include_Stack = 1; we see:
including function.inc
including transforms.inc
including math.inc
including setidtypes.inc
including vectors.inc
We don't see whackJob.inc just above because the guy who wrote it did
not add the debug code that is in all core shipped include files.
Aside: There are exposures with the View_POV_Include_Stack method in
that the name reported is whatever is in the debug statement and not
really the name of the file included. They should align, but...
---
With regards to the #ifdef(), #ifndef(), the povr fork has been reverted
to v3.7,v3.6 behavior in looking only for declared IDs. With the one
exception that empty parenthesis now returns false or true,
respectively, without introducing odd, hard to understand parsing fails
as a rule.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymous org> wrote:
>
> Aside: There are exposures with the View_POV_Include_Stack method in
> that the name reported is whatever is in the debug statement and not
> really the name of the file included. They should align, but...
>
Yes! I was a 'victim' of that user error myself, while I was testing things :-[
A sloppy cut-and-paste job. I spent half an hour (!) tracking it down, ha.
This old method is certainly not an ideal way to report the presence of a user's
personal #includes. The special code block is 'one more thing' that has to be
added to a file. I probably have several hundred includes of different kinds
that I have written over the years, many written hastily (or even auto-generated
by POV-ray like mesh_2 files.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/23/23 15:02, Kenneth wrote:
> This old method is certainly not an ideal way to report the presence of a user's
> personal #includes.
Found the new debug compile reporting all the include read attempts has
an issue too.
Specifically where people use that Parse_String() macro hack. It works
by creating and including a small include file of the same name, but
with different contents.
In trying again to debug that flaky csv read file problem from early
2022 of jr's, I was getting thousands of debug include messages per
frame of a long animation! So, I commented out that nice debug code I
just added.
I'm unsure what to do for anything shipped.We'd need a custom
configuration option or a new run time flag/option - neither of which is
attractive.
It's hard to get simple, clean, code wins. :-)
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> I was getting thousands of debug include messages ...
> I'm unsure what to do for anything shipped.
a '#pragma [no-]feature-warning;' would be real nice, to get rid (selectively)
of spline + rtr "experimental feature" warnings, for instance :-)
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/24/23 11:36, jr wrote:
> a '#pragma [no-]feature-warning;' would be real nice, to get rid (selectively)
> of spline + rtr "experimental feature" warnings, for instance 😄
Hmm. Yeah, maybe some more general mechanism to turn off messages would
be helpful(a,b). Features like this will slow down the parser some though.
Bill P.
(a) - The was some support for warning levels for a time, but it's
eroded on the implementation side over time - unsure if it still works
at all in fact. Plus, I cannot remember how the level was specified at
the moment.
(b) - Unrelated to parsing, but for the isosurface only I added a report
<true/fase> option in povr for gradient messages. The 'report' keyword
has always intended to be a more general thing which could be used with
all the shape primitives. Something where, by shape, you can turn
reporting on and off. I never seem to get back to working on the concept
though...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymousorg> wrote:
> On 3/23/23 15:02, Kenneth wrote:
> >
> > This old method [of 'View_POV-Include_Stack'] is certainly not an ideal
> > way to report the presence of a user's personal #includes.
>
> I'm unsure what to do for anything shipped. We'd need a custom
> configuration option or a new run time flag/option - neither of which is
> attractive.
>
> It's hard to get simple, clean, code wins. :-)
>
I was thinking the same thing: something built-in. HOW to do it-- and how
difficult it would be to code without introducing other problems-- are the
bigger questions, of course ;-)
I'm rather surprised that, in all the years of POV-ray's code development, some
kind of internal mechanism was not introduced to do this... because knowing
automatically which #includes are actually being used in a scene would be a
useful bit of info, IMO.
In the 'official' Windows versions, the GUI uses something called CODEMAX, as
far as I understand. Perhaps the lack of such an #includes feature is a
limitation of the POV-ray/CODEMAX interaction? I do remember Clipka and other
developers mentioning 'difficulties' or restrictions between the two.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
> I was thinking the same thing: something built-in. HOW to do it-- and how
> difficult it would be to code without introducing other problems-- are the
> bigger questions, of course ;-)
Seems to me (a non-source-code-programmer) that it would work as part of the
#include directive itself, and we already have internal things like recursion
stacks, etc. So it wouldn't really be a problem to prevent multiple parsing of
includes, etc.
As for parse time, how much extra could there possibly be to check the include
stack to see if the file has been included yet, or if the "view include stack"
flag is set or not?
But perhaps for some reason it's non-trivial.
- BW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/25/23 07:38, Bald Eagle wrote:
> As for parse time, how much extra could there possibly be to check the include
> stack to see if the file has been included yet, or if the "view include stack"
> flag is set or not?
Mostly very little as you suggest.
Excepting where someone is using the Parse_String hack or similar and so
doing potentially gazillions of small includes - as is happening in the
animation code of jr's. The clean fix for that problem is to change that
hack into some immediate, interpret this 'string' feature - but that's
not all that easy to do.
In any case, I was thinking more of jr's general #pragma capability for
turning off say 13 warnings, but not any of the other remaining 3,852 (I
made that number up).
We introduced the possible errors category too as something I believe
new to v3.7/v3.8/v4.0, but I didn't go check the v3.6 source.
Thinking aloud...
In compilers most all warnings are introduced with a general, less
general and selective control capability(a), but also various categories
of warnings. These are almost all on command line flags and often inline
with code too. In code these optionally to some local region (like a
file or particular functions) in the form of #pragma settings. That
said, such message controls are not all that standardized between
compilers. What you do for one compiler might or might not work for
others. And sometimes there are conflicts between compilers.
POV-Ray is a little different from compilers in that we have a parse
phase, which is compiler like is some respects, and then we have a
render phase for both stills and animations. Those two modes differ in
behavior and cost.
Aside: We have too a nascent RTR capability too not sharing much with
the control structure of regular animations.
The issues start with the code base not having a generic set up for
anything like an in code #pragma capability - which probably would apply
to SDL only I'd say.
We have too what looks like common functionality in things like pow()
that have multiple forms internally. One for the SDL and another for
functions running on the vm at parse time or render time.
We have warnings and errors around both command line options and ini
settings too. These perhaps more an issue for animations where you might
get some warning for each frame.
The error messages don't all go through the same message systems or
message handlers today. In povr, I use the fancier ones when they are
there and ready to use, but when they are not, I don't!
I've made use of writing to stderr, for example, when it's the expedient
thing to do to get messages about behavior where we are today just
letting things go. Often things which were historically reported in
earlier single thread versions of POV-Ray. Yes, this means sometimes
each thread kicks out exception messages, but I feel getting the
information is more important than not.
That's sort of the really rough lay of the land for info / warning /
possible error / error / messages. The thinking aloud, I expect, more
helpful to me than anyone else. :-)
All that said, adding a few select controls, #pragmas, not all that hard
to do. Maybe we aim to control the most annoying (or most useful)
messages first.
Where these might bleed over to render time functionality there is a
significant cost to turning on or off checks when that 'control test'
gets done millions (or billions) of times while rendering. Such testing
costs less for animations where you might have only a thousand frames.
For stills such control tests might cost little or be significant if
happening inside a loop placing thousands of objects.
Yes, issuing and tracking information for the messages costs too.
Sometimes we'll win when the messages are off - even if running the
control test a great many times.
Sometimes messages are situation-ally useless as happens when users
create isosurfaces with functions having a high gradients - well away
from the all of the actual roots. In such cases the gradient warnings
have no 'useful' meaning and in povr 'report false' turns them off by
isosurface.
There are situations where better more controllable warnings absolutely
helps limit warnings to those probably useful.
Bill P.
(a) - Aside. When I re-worked povr's gnu, autotools based build, I
turned off all the compiler warnings by default. To me, it didn't make
sense for users grabbing the code to do a quick ./configure, make -j4,
make check, make install; to see hundreds of warnings they aren't going
to try and fix anyway.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
My my, you _have_ been busy :O
Is there a way to identify and collect all of the places in source where errors
get raised, and group them by parse / render/ etc?
That might help folks get a better idea about how much there is an how often
some warnings might need to test conditions and fork flow control.
While working on the lemon, I also stumbled upon a dev manual in the 3.8 github
stuff - haven't had a chance to dig through it - might any of that already be in
there?
- BW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/26/23 07:50, Bald Eagle wrote:
> Is there a way to identify and collect all of the places in source where errors
> get raised, and group them by parse / render/ etc?
>
:-) Hmm. Asking questions to which to which the only strict answer is
yes.
If you mean quickly, you can grep strings like Warning, PossibleError,
Error and see quite a bit of text fly by. When and whether you actually
get any particular ones depends on more. Some too get formed indirectly
where a function like Not_WithPattern() might be what is actually
getting called and it will assemble some final Error or Warning.
The parsing related stuff these days is mostly in the source/parser
directory. Just counting lines with those strings in povr, Warning 171,
PossibleError 32, Error 609.
>
> While working on the lemon, I also stumbled upon a dev manual in the 3.8 github
> stuff - haven't had a chance to dig through it - might any of that already be in
> there?
Assume you are talking about the contents of source-doc directory.
Many years ago I did read through those files. I don't recall much of it
truth be told and a lot of it was 15 years old already when I read it. I
see a povms.md file. It would have stuff on the threaded messaging
system - one of several ways messages get generated - so yep some in
there. :-)
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
