 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I was dabbling with PoseRay output files for a satellite, and POV-Ray choked on
the "-A" option.
All was well when I commented that line out.
Considering how there are things that "ought" to work, and sometimes get missed
or inadvertently broken, I was wondering if one of the things that ought to be
considered, is some sort of "validation suite" - a set of standard files that
will run through a long, as-complete-as-possible list of all past known bugs,
and as many features, functions, and combinations of things as possible to
automagically check to see if everything works.
This could have multiple uses, as it could serve as a repository for documenting
'bugs' and a checklist for making sure they are addressed, not forgotten, and
remain fixed, documenting code examples, demonstrating to new users (and more
experienced users unfamiliar with certain features) HOW and to a certain degree
why - certain things in POV-Ray happen the way they do.
(I'm thinking about utf-8, coincident surfaces, nearly coincident surfaces,
sphere sweep and isosurface artifacts, .ini and command line options, etc.)
It would save work in development testing, as whatever was in the file(s) could
just stay there, and then only new things would have to be added.
A large amount of debugging could be accomplished with a simple 'open file' and
'run'.
Just an idea.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 13.06.2017 um 13:56 schrieb Bald Eagle:
> I was dabbling with PoseRay output files for a satellite, and POV-Ray choked on
> the "-A" option.
>
> All was well when I commented that line out.
Sounds like something that shouldn't happen. Do you have any details?
> Considering how there are things that "ought" to work, and sometimes get missed
> or inadvertently broken, I was wondering if one of the things that ought to be
> considered, is some sort of "validation suite" - a set of standard files that
> will run through a long, as-complete-as-possible list of all past known bugs,
> and as many features, functions, and combinations of things as possible to
> automagically check to see if everything works.
Yes, that would be good.
Can we interpret this as your offer to volunteer for this task?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 06/13/2017 07:56 AM, Bald Eagle wrote:
> I was dabbling with PoseRay output files for a satellite, and POV-Ray choked on
> the "-A" option.
>
> All was well when I commented that line out.
>
> Considering how there are things that "ought" to work, and sometimes get missed
> or inadvertently broken, I was wondering if one of the things that ought to be
> considered, is some sort of "validation suite" - a set of standard files that
> will run through a long, as-complete-as-possible list of all past known bugs,
> and as many features, functions, and combinations of things as possible to
> automagically check to see if everything works.
>
> This could have multiple uses, as it could serve as a repository for documenting
> 'bugs' and a checklist for making sure they are addressed, not forgotten, and
> remain fixed, documenting code examples, demonstrating to new users (and more
> experienced users unfamiliar with certain features) HOW and to a certain degree
> why - certain things in POV-Ray happen the way they do.
> (I'm thinking about utf-8, coincident surfaces, nearly coincident surfaces,
> sphere sweep and isosurface artifacts, .ini and command line options, etc.)
>
> It would save work in development testing, as whatever was in the file(s) could
> just stay there, and then only new things would have to be added.
> A large amount of debugging could be accomplished with a simple 'open file' and
> 'run'.
>
> Just an idea.
>
>
With respect to the -A in an ini file causing issues would you please
post the exact line or perhaps the files needed to reproduce. Just
adding -A to an ini file here is not failing in my 3.7.1 release branch
(or 3.7.0)
I am on Ubuntu linux and the options parsing code is not completely
shared between windows and linux at this time - so perhaps you are
seeing a windows only issue.
---
The "validation suite" is a valid :-) idea, but one which pretty quickly
needs a "validation team," "validation computers" and such to really
keep up with it. Such testing is a tedious, never ending, job so finding
volunteers that will really stick with such testing for the long haul is
not easy.
Each of us contributing tends to run the shipped demo scenes. I have
some hacks at my own testing framework that will do "sanity runs" of all
400 or so scenes automatically checking return codes, but not much more.
It takes a while to turn on my little two core, so I don't run all 400
very often.
I've also got some other smaller test sets for include files and parser
issues that I've slowly been building up.
Using my parser testing as an example - my current template for parser
tests looks something like this:
//
// +- Expected return code.
// | +- Expected message, if any.
// | | +- Optional >=16 chars
// | | | of git hash where
// | | | in-version change.
// EXPECT 3.70 0 ;
// EXPECT 3.71 1 Parse Error: No normal type given. ;
// EXPECT 3.72 1 Parse Error: No normal type given. ;
#default {
pigment { rgb <1,1,1> }
normal { bump_size 1.5 } // <--- Fail
finish { phong 0.8 phong_size 200 }
}
// <file><language_version_if_matters>.in names have prefixes:
// F_or_P_ - Where pass or fail changes over time.
// Fail_ - Expect to always fail no matter version.
// Pass_ - Expect to always pass no matter version.
// Warning_ - Expect to generate a warning message 'runtests' will
verify.
// Debug_ - Expect to generate a debug message 'runtests' will verify.
// Error_ - Expect to fail due SDL #error with message 'runtests'
will verify.
So, for example, I have these files for the somewhat recent changes to
lathe spline parser behavior:
Fail_LatheCubic1n2NegX.inc
Fail_LatheCubic2n3NegX.inc
Fail_LatheCubic2ndNegX.inc
Fail_LatheCubic3n4NegX.inc
Fail_LatheCubicAllNegX.inc
Fail_LatheLinear1n2NegX.inc
Fail_LatheLinear2n3NegX.inc
Fail_LatheLinear2ndNegX.inc
Fail_LatheLinear3n4NegX.inc
Fail_LatheLinearAllNegX.inc
Fail_LatheQuadratic1n2NegX.inc
Fail_LatheQuadratic2n3NegX.inc
Fail_LatheQuadratic2ndNegX.inc
Fail_LatheQuadratic3n4NegX.inc
Fail_LatheQuadraticAllNegX.inc
F_or_P_LatheBezier1stAnd2ndControlNegX370.inc
F_or_P_LatheBezier1stAnd2ndControlNegX371.inc
F_or_P_LatheBezier1stControlNegX370.inc
F_or_P_LatheBezier1stControlNegX371.inc
F_or_P_LatheBezier2ndControlNegX370.inc
F_or_P_LatheBezier2ndControlNegX371.inc
F_or_P_LatheBezierPointFirstNegX370.inc
F_or_P_LatheBezierPointFirstNegX371.inc
F_or_P_LatheBezierPointLastNegX370.inc
F_or_P_LatheBezierPointLastNegX371.inc
F_or_P_LatheLinear1stNegX370.inc
F_or_P_LatheLinear1stNegX371.inc
F_or_P_LatheLinearLastNegX370.inc
F_or_P_LatheLinearLastNegX371.inc
F_or_P_LatheQuadraticLastNegX370.inc
F_or_P_LatheQuadraticLastNegX371.inc
Pass_LatheBezier.inc
Pass_LatheCubic.inc
Pass_LatheLinear.inc
Pass_LatheQuadratic.inc
When someone recently drove the change to make certain invalid spline
specifications warnings and not errors where the language version was
<=3.7, I had to go back and add additional 370 and 371 specific files
and track the commit in the 370 ones where the behavior changes over time.
It gets to be a real pain to keep this stuff up and I'm honestly not
sure I'll continue the effort...
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymous org> wrote:
> With respect to the -A in an ini file causing issues would you please
> post the exact line or perhaps the files needed to reproduce. Just
> adding -A to an ini file here is not failing in my 3.7.1 release branch
> (or 3.7.0)
Well, until I go home tonight and copy the file(s):
I copied
PoseRay v3.13.23.587
to my POV-Ray 3.7 subdirectory,
Then imported all of the pieces of
http://space.jpl.nasa.gov/models/
and saved the output files
IIRC, there were 4 files - .ini, .pov, .mtl, and a geometry file, maybe as an
include file.
Maybe that will help recreate the issue.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Running 3.7.1-beta.2
;==================================================
;POV-Ray Initialization file (render settings)
;Run this file in POV-Ray to obtain the rendered image
;NOTE: Delete the command line options in the toolbar
; before pressing RUN to use the settings in this file
;==================================================
;This file has been created by PoseRay v3.13.23.587
;3D model to POV-Ray/Moray Converter.
;Author: FlyerX
;Email: fly### [at] yahoocom
;Web: https://sites.google.com/site/poseray/
;==================================================
;Files needed to run the POV-Ray scene:
;Satellite_POV_main.ini (initialization file - open this to render)
;Satellite_POV_scene.pov (scene setup of cameras, lights and geometry)
;Satellite_POV_geom.inc (geometry)
;Satellite_POV_mat.inc (materials)
;
;
;Input POV-Ray file
Input_File_Name="Satellite_POV_scene.pov"
;Output rendered image file
Output_File_Name="uss_assy_2017_06_13_12_18_11.png"
;Resolution
+W320
+H238
;Output format: PNG (portable network graphics)
+FN
Bits_Per_Color=16
;Antialiasing
-A
;Quality
+Q9
;Alpha transparency option
-UA
;Continuation option
+C
version=3.7
Preset INI file is 'C:\Users\Tech
Desk\Documents\POV-Ray\v3.7-beta\ini\quickres.ini', section is '[1024x768, AA
0.3]'.
Preset source file is 'C:\Users\Tech
Desk\Documents\POV-Ray\v3.7\poseray_install_3_13_23\Satellite\Satellite_POV_main.ini'.
-
"C:\Users\Tech
Desk\Documents\POV-Ray\v3.7\poseray_install_3_13_23\Satellite\Satellite_POV_main.ini"
line 31: Unknown switch 'A' in INI file.
-
"C:\Users\Tech
Desk\Documents\POV-Ray\v3.7\poseray_install_3_13_23\Satellite\Satellite_POV_main.ini"
line 31: Cannot continue to process INI file 'C:\Users\Tech
Desk\Documents\POV-Ray\v3.7\poseray_install_3_13_23\Satellite\Satellite_POV_main.ini'
due to a parse error in line 31.
This is not a valid INI file. Check the file for syntax errors, correct them,
and try again!
Valid options in INI files are explained in detail in the reference part of the
documentation.
Failed to start render: Failed to parse INI file
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 13.06.2017 um 18:22 schrieb Bald Eagle:
> Running 3.7.1-beta.2
As a beta tester, please assist us developers in focusing our time and
energy on improvements and unfixed bugs (rather than hunting ghosts) by
updating your version of POV-Ray on a regular basis - or at least
whenever you encounter a bug.
I strongly suspect that the issue you're observing is fixed in the
newest beta. To quote from the revision history (`changes.txt`):
--------------------------------------------------------------------
Changes between 3.7.1-beta.5 and 3.7.1-beta.6
=============================================
[...]
Fixed or Mitigated Bugs
-----------------------
[...]
Reported via the Newsgroups:
[...]
- <web.58e39b3f29046ace8464b730@news.povray.org>
(2017-04-04, povray.beta-test, "Re-Render of Editor-Bitmaps failed
with Beta 5 ?")
Command-line-style switches with optional parameters (e.g. `-jN`)
are not accepted in INI files if the parameter is omitted
(e.g. `-j`).
--------------------------------------------------------------------
[text reformatted to fit the message width]
As the `-a` switch has an optional parameter (namely the anti-aliasing
quality setting; the value will be used if you later specify `+a`
without a parameter), it is presumably among the set of switches
affected by that fixed issue.
Your aperture science development team thanks you for helping us help
you help us all. :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> As a beta tester, please assist us developers in focusing our time and
> energy on improvements and unfixed bugs (rather than hunting ghosts) by
> updating your version of POV-Ray on a regular basis - or at least
> whenever you encounter a bug.
Oh dear.
I guess I'm still new at this beta testing thing.
It may take some extended quality alone time playing with things before I become
a master beta-er.
> Your aperture science development team thanks you for helping us help
> you help us all. :)
Somehow, from where I'm sitting, I get the strange feeling that I just got my
orifice reamed from the aperture science development team.
(ASDT)
[pronunciation redacted]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 13.06.2017 um 22:05 schrieb Bald Eagle:
> clipka <ano### [at] anonymousorg> wrote:
>
>> As a beta tester, please assist us developers in focusing our time and
>> energy on improvements and unfixed bugs (rather than hunting ghosts) by
>> updating your version of POV-Ray on a regular basis - or at least
>> whenever you encounter a bug.
>
> Oh dear.
> I guess I'm still new at this beta testing thing.
> It may take some extended quality alone time playing with things before I become
> a master beta-er.
All subjects intending to handle high-energy gamma leaking POV-Ray
technology must be informed that they MAY be informed of applicable
regulatory compliance issues.
No further compliance information is required or will be provided, and
you are an excellent test subject.
Cake and grief counseling will be available at the conclusion of the test.
:)
>> Your aperture science development team thanks you for helping us help
>> you help us all. :)
>
> Somehow, from where I'm sitting, I get the strange feeling that I just got my
> orifice reamed from the aperture science development team.
> (ASDT)
> [pronunciation redacted]
Just semi-quoting GLaDOS from Portal here.
No reaming required. She's gonna tear you a brand new one anyway ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
