A user sent me an example of a deepzoom PAR that won't reload into Fractint. I looked into it, and it wasn't hard to find the problem. I have a fix of sorts which I'll turn into a patch as soon as I get it cleaned up. Only cmdfiles.c is involved. I expect this is a known problem. Tim
Tim,
A user sent me an example of a deepzoom PAR that won't reload into Fractint. I looked into it, and it wasn't hard to find the problem. I have a fix of sorts which I'll turn into a patch as soon as I get it cleaned up. Only cmdfiles.c is involved. I expect this is a known problem.
If you were so inclined, I have two small fixes that could be included. Or, you could send your diff to me, so I could include it with mine. I don't see doing any serious work on Fractint for the next week or two, however. Not that I did any in the last week or two, either. 8-)) The 15th is my last (honest trust us) day at work. I'm looking forward to not working for a bit. Just not too long a bit. Jonathan
Jonathan wrote:
If you were so inclined, I have two small fixes that could be included. Or, you could send your diff to me, so I could include it with mine.
I have uploaded the (non official) diff to http://www.fractint.org/ftp/experimental/2003p02.zip and an executable in: http://www.fractint.org/ftp/experimental/fradev.zip Be careful with the executable in case it does not become "official" - it looks like the "real" 2003 patch 2. Probably wasn't smart for me to do it that way. Hey, I haven't uploaded a patch in a long time, I'm rusty :-) We can combine your small changes if you want, but I actually think it's better to make patches more focused. But not a big deal one way or the other if combining saves effort. If my patch tests OK I'll make it official and propagate it to Linux and float-only. The same patch should fit easily into the float only version and Linux. I haven't tried though. Tim
Tim,
I have uploaded the (non official) diff to
The diff went in fine in DOS, ugly but successful in Linux.
Be careful with the executable in case it does not become "official" - it looks like the "real" 2003 patch 2. Probably wasn't smart for me to do it that way. Hey, I haven't uploaded a patch in a long time, I'm rusty :-)
The description of the patch needs a very minor tweak. You'll see it if you read it. Do you have any idea what the check for FLT_MAX is doing? Jonathan
The diff went in fine in DOS, ugly but successful in Linux.
I may generate the diff using Linux instead of DOS tools.
Do you have any idea what the check for FLT_MAX is doing?
Easy! If the arbitrary precision test is met, floatval is set to FLT_MAX. The test is testing if the *previous* parameter used arbitrary precision. Once one parameter needs arbitrary precision, then all use it. However, the overall logic is not the best, though it seems to work OK. Too much dependence on scanf. Tim
The diff went in fine in DOS, ugly but successful in Linux.
I have modified the diff a little, so it's not identical to what you have. The way it behaves for me is: 1. applies cleanly to DOS version 2. applies OK to float-only version(s) with messages about offset lines (expected) 3. applies cleanly to Linux if the cr/lf are fixed. This raises the question of how we handle newlines in CVS. Unless CVS has a way to fix newlines on-the-fly, we probably need to adopt the Linux newline standard for files and dif's (or the other, the point is to choose). As long as we package everything with zip, unpacking with the zip -a option will fix newlines for the local system.
Tim,
I have modified the diff a little, so it's not identical to what you have. The way it behaves for me is:
1. applies cleanly to DOS version 2. applies OK to float-only version(s) with messages about offset lines (expected) 3. applies cleanly to Linux if the cr/lf are fixed.
This raises the question of how we handle newlines in CVS. Unless CVS has a way to fix newlines on-the-fly, we probably need to adopt the Linux newline standard for files and dif's (or the other, the point is to choose). As long as we package everything with zip, unpacking with the zip -a option will fix newlines for the local system.
Yes, CVS handles newlines on-the-fly. If you have them there under Linux, as happens with certain files in my Allegro experimental source, it complains and won't put the files in the repository. So, I'll need to clean up the Allegro source before I can put it in CVS. It occurred to me the other day that if I combined your patch with mine, I wouldn't have to figure out how to back changes out of CVS, put in your patch, and then put my changes back in. I am now back home. No more travelling. At least not until I get a job. Jonathan
Jonathan wrote:
It occurred to me the other day that if I combined your patch with mine, I wouldn't have to figure out how to back changes out of CVS, put in your patch, and then put my changes back in.
You are certainly welcome to put in my patch, though I realize you are otherwise occupied right now with the job search. Most of the benefit of CVS is lost if just one person uses it. Are you happy with what you have in CVS? How far back does it go? If you are happy with it, we could put it on fractint.org. Or even if you're not happy, I'd like to see what you have. Once it's on fractint.org (or other accessible place) we could both use it. If you just zip up the files and send it to me I could probably put in on fractint.org. Tim
Tim,
You are certainly welcome to put in my patch, though I realize you are otherwise occupied right now with the job search.
Most of the benefit of CVS is lost if just one person uses it. Are you happy with what you have in CVS? How far back does it go? If you are happy with it, we could put it on fractint.org. Or even if you're not happy, I'd like to see what you have.
Once it's on fractint.org (or other accessible place) we could both use it. If you just zip up the files and send it to me I could probably put in on fractint.org.
If only it were that simple. I have one repository for Fractint, but it should be renamed. It is currently named fractint.20.03p01. I have three repositories for Xfractint, all variations on xfractint.20.03p01. Two of them have only two minor fixes. The third also has structural changes where I've put the Unix code in a separate subdirectory and modified the Makefile to work. The repositories should be named Fractint and Xfractint, but knowing how to make tags work would seem to be essential. Would we want to start farther back than 20.03p01? We could start with the version 20.0 source. By the time we got to the current patch we would have a pretty good idea about how to make CVS work for us. Do we want to bring in the structural changes with a patch? Deleting files and recreating them elsewhere creates a very large diff file. Also note that the repository created under Windows causes error messages under Linux. Everything still seems to work, but every operation causes the error message to appear. Jonathan
Tim,
Most of the benefit of CVS is lost if just one person uses it. Are you happy with what you have in CVS? How far back does it go? If you are happy with it, we could put it on fractint.org. Or even if you're not happy, I'd like to see what you have.
Once it's on fractint.org (or other accessible place) we could both use it. If you just zip up the files and send it to me I could probably put in on fractint.org.
I've uploaded fractcvs.tar.gz to the fractint directory. It includes the fractint repository as fractint.20.03p01, the xfractint repository as xfractint, and a modified directory structure xfractint as xfractint.20.03p01. These are all at my version 20.03p02. The modified directory structure will eventually let us have only one source tree instead of the two we now use. Jonathan
participants (2)
-
Jonathan Osuch -
Tim Wegner