I'm taking a quick look at the Autokey capability of Fractint to see how useful it might be in regression testing during development of any new versions or features of Fractint. I was originally thinking of making these image comparisons between different versions of new code to check to see if changes had broken anything previously working. However, Richard and Paul also suggested that one could compare the DOS versions of the fractal images with the versions generated by new code. Autokey can also confirm that help screens are still being displayed, .par and .map files are being written out, as well as whether commands are processed as expected. One could have more than one set of regression tests -- perhaps: - one for verifying that the pixels of particular fractals are the same as a reference set of fractals; - one set for confirming that small versions of all fractals can be created; - one set for verifying that informative text screens all display; - one set for verifying .par and .map file creation; - etc. I currently only have the code of 20.0 to look at. I suspect that there are not too many differences between 20.0 and 20.4.4, but, would someone please tell me how I can get a copy of the 20.4.4 code? <---<< This will also give me a copy of the code that matches the comprehensive HTML cross reference document that Richard created and posted of 20.4.4 at: http://www.xmission.com/~legalize/fractals/fractint-xref/ This document is a great way for someone who is not familiar with Fractint's code (like me) to start to learn how a feature works. Indirection of functions (function pointers) -- like outln() is hard to follow when you first run across it! In fact, the Xref is so valuable to me that I captured a copy to speed up access to the info. Also, can someone please tell me how to use the debug flag 50 feature to actually compare two fractals that Fractint has created as stated in Debugfla.doc. I also saw the warning in the docs... Warning: an autokey file built for this version of Fractint will probably require some retouching before it works with future releases of Fractint. We have no intention of making sure that the same sequence of keystrokes will have exactly the same effect from one version of Fractint to the next. That would require pretty much freezing Fractint development, and we just love to keep enhancing it! Reading the code that does debug 50 I see that one of the two images must be reloaded with the 'r' command. I also found where a pixel of value zero is written to the screen if the two fractals have the same pixel value, and where a pixel of value one is written if they differ (a nice feature), but I have not been able to tell where the second file being compared comes from. Any help about how to compare two files using Fractint would be appreciated...
From reading the code in FRAMAIN2.C it would appear that you might need to be in batch mode for
debugflag == 50 to be used. Is this true? <---<< Also, I have the vague recollection that whenever I tried to run demo.bat in the past that it behaved in ways that I didn't expect (or didn't understand.) Is the demo capability currently behaving as intended in 20.4.4? <---<< - Hal Lane ######################### # hallane@earthlink.net # ######################### -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.15.22/590 - Release Date: 12/16/06
Hal,
I currently only have the code of 20.0 to look at. I suspect that there are not too many differences between 20.0 and 20.4.4, but, would someone please tell me how I can get a copy of the 20.4.4 code? <---<<
The source for 20.4.4 can be found on the developer's web site (www.fractint.org or www.fractint.net) as fract-src-20.04p04.zip. If you need the Xfractint source, it is called xfractint-20.04p04.tar.gz. This patch was released March 11, 2006, so the cross reference generated by Richard will be pretty close.
Also, can someone please tell me how to use the debug flag 50 feature to actually compare two fractals that Fractint has created as stated in Debugfla.doc.
Once debug=50 is set (either on startup or from the <g> screen prompt), the image on the screen can be compared to GIF file by pressing <r> and selecting the file to compare to. The differences will be displayed on the screen and printed to a file called cmperr.
From reading the code in FRAMAIN2.C it would appear that you might need to be in batch mode for
debugflag == 50
to be used.
Is this true? <---<<
No, batch mode is not required to compare two images. I don't recall if you can automate the comparison of images using batch mode.
I also saw the warning in the docs...
Warning: an autokey file built for this version of Fractint will probably require some retouching before it works with future releases of Fractint. We have no intention of making sure that the same sequence of keystrokes will have exactly the same effect from one version of Fractint to the next. That would require pretty much freezing Fractint development, and we just love to keep enhancing it!
Also, I have the vague recollection that whenever I tried to run demo.bat in the past that it behaved in ways that I didn't expect (or didn't understand.) Is the demo capability currently behaving as intended in 20.4.4? <---<<
That would be caused by screens being changed as features are added and/or rearranged. Hence the warning. We don't generally look at this until we get close to an "official" release. Yes, the demo feature is behaving as expected. It is probably broken. 8-)) One problem with using the autokey and demo modes for regression testing between environments is that the screens have different layouts depending upon features that have been implemented (or not). Rich's refactoring of the source could fix this, but, it isn't easy. Jonathan
Hal wrote:
I'm taking a quick look at the Autokey capability of Fractint to see how useful it might be in regression testing during development of any new versions or features of Fractint.
You'd be doing a great service to help out with creating regression test cases. A LOT of regression testing could be done with batch files. Where this is possible it is better than using autokey. The autokey feature is 100% tied to the user interface. We made an effort after introducing autokey to add new menu/screen input items at the bottom of screens to avoid breaking autokey scripts. But it's still a brittle approach, which is not to say it shouldn't be done. The very fact that autokey IS brittle adds to the value for regression testing since it is so sensitive to interface changes. The value of batch file regression tests is that they don't depend on the interactive interface. We need both. While I don't subscribe to all aspects of Xtreme programming, having a robust regression test suite is a powerful tool. I have built some at work, and having such a suite is a huge benefity when doing large architectural changes. Hack away, run the test, hack away some more - the test suite gives courage to make more aggressive changes. Tim
participants (3)
-
Hal Lane -
Jonathan Osuch -
Tim Wegner