Tim, Do you have any recollection of any platform differences that would cause problems with enumerated data types? The Xfractint boundary tracing ends up in an infinite loop (actually there are several different loops) because the coming_from variable (of enumerated type direction) is ending up with values that are out of the bounds of the type. Jonathan
Jonathan asked:
Do you have any recollection of any platform differences that would cause problems with enumerated data types? The Xfractint boundary tracing ends up in an infinite loop (actually there are several different loops) because the coming_from variable (of enumerated type direction) is ending up with values that are out of the bounds of the type.
Enumerated types are just integers. If not given values, the first one is zero, and each subsequent one is one more. I believe this is standard behavior, but if not it is possible to force the values. I kind of doubt this is the real source of the problem, but I'd have to check the code to see. Which exact version has the problem? I can have a look. Just got back from a trip to Minnesota to visit my Mother. Would have waved at you when I crossed over except to get the cheap fare I went Houston to Minneapolis via Atlanta, so I was never overhead your place in Iowa. That makes the trip (ugh!) six hours. I coped with all the time by picking up up Steven King's "Dreamcatcher" which was suprisingly good if you can put up with a lot of visceral grossness. It was actually Sci Fi. Didn't quite last me the whole round trip even at 800+ pages, but did occupy me me most of the way. Enjoyed it. Tim
On Tuesday 29 April 2003 06:30 pm, Tim Wegner wrote:
Enumerated types are just integers. If not given values, the first one is zero, and each subsequent one is one more. I believe this is standard behavior, but if not it is possible to force the values. I kind of doubt this is the real source of the problem, but I'd have to check the code to see.
Which exact version has the problem? I can have a look.
I'm using the float-only version of Xfractint, which has been indented. However, Xfractint has had the problem for quite a while. At this point, all I know is that coming_from is getting a value over 100, when it should be between 0 and 3. Inserting code that does &3 helps, but doesn't entirely solve the problem. Jonathan
Jonathan wrote:
I'm using the float-only version of Xfractint, which has been indented. However, Xfractint has had the problem for quite a while.
I don't know if this is good news or bad news. I grabbed the latest float-only source, dumped unpacked in in a clean directory in the current Mandrake, type "make", and ran it with boundary tracing. I couldn't debug your problem ... because there was no problerm to debug. Boundary tracing works perfectly for me. As an ironic side note - it has been a long time since I have tried boundary tracing, and it is no fun at all any more. My computer is too fast! :-) The fun in boundary tracing is watching it work. On my (not really the state of the art) 650 mhz computer, the default Mandelbrot renders almost instantly. I had to bump up the resolution quite a bit to see that I was really using boundary tracing. I wish I could see the problem, because it looks to me like it is easy to debug. I checked that the enum values North, East, South, West had the correct values of 0, 1, 2, 3, and checked that the macros were working. I'd just instrument the code each time the coming_from variable is set, and stop in the debugger the first time it is out of range. Then check the values used to calculate it. Alas, I can't see the problem, so I can't fix it. Maybe I need to try on my laptop? What machine are you running on? Perhaps the video driver is making it hard for Xfractint to recover pixels from the screen. Tim
On Wednesday 30 April 2003 10:42 pm, Tim Wegner wrote:
I don't know if this is good news or bad news. I grabbed the latest float-only source, dumped unpacked in in a clean directory in the current Mandrake, type "make", and ran it with boundary tracing. I couldn't debug your problem ... because there was no problerm to debug. Boundary tracing works perfectly for me.
Did you zoom in? Also, try SWT-027 in the default fractint.par file. I believe that before this last patch boudary tracing would lock up on the default mandelbrot, so you might be right about it being a video problem.
I wish I could see the problem, because it looks to me like it is easy to debug. I checked that the enum values North, East, South, West had the correct values of 0, 1, 2, 3, and checked that the macros were working. I'd just instrument the code each time the coming_from variable is set, and stop in the debugger the first time it is out of range. Then check the values used to calculate it. Alas, I can't see the problem, so I can't fix it.
Natalie has also seen the problem, so it isn't just me. 8-))
Maybe I need to try on my laptop? What machine are you running on? Perhaps the video driver is making it hard for Xfractint to recover pixels from the screen.
I'm using my laptop, but I'm sure I've seen this problem on other machines. Jonathan
Also, try SWT-027 in the default fractint.par file.
I can duplicate this problem with the SWT-027. I changed the macro advance_match() to a function and instrumented it with a test on the bounds of coming_from. It was never out of bounds. I ran SWT-027 in the debugger, and usually it got stuck in readvideo in unixscr.c, but the debugger print command couldn't find the variable i so I am not sure what is happening. Incidently, the source I grabbed was not indented. I need to grab the same file you are using. Tim
On Thursday 01 May 2003 10:48 pm, Tim Wegner wrote:
I can duplicate this problem with the SWT-027. I changed the macro advance_match() to a function and instrumented it with a test on the bounds of coming_from. It was never out of bounds. I ran SWT-027 in the debugger, and usually it got stuck in readvideo in unixscr.c, but the debugger print command couldn't find the variable i so I am not sure what is happening.
The readvideo() routine is one that I am going to try to simplify. Although, the changes I've made so far don't work any better (and mess up solid-guessing).
Incidently, the source I grabbed was not indented. I need to grab the same file you are using.
Do we turn the indented code into patch 6 with no actual diff file? Jonathan
Jonathan asked:
Do we turn the indented code into patch 6 with no actual diff file?
A huge diff with white space changes is not too useful unless forked versions are being merged. It's OK withg me to dispense with a diff for this patch, though if you made one, might as well upload it even if it is huge. We're not disk space bound yet. Maybe never will be the way disks are getting bigger. When I start CVS do you want to start with the present or capture old versions? I guess I favor starting with the present and capturing the history on a CD. If we decided there was value in capturing the history I could do that. I have a love hate relationship with CVS having used it at work for a while (much more love than hate). The functionality is wonderful, and routine operations are incredibly easy, but other operations require looking up arcane commands and switches. It really needs to be driven with a GUI. There are some, but I don't have one for my current work environment (IBM AIX). Tim
On Saturday 03 May 2003 12:07 pm, Tim Wegner wrote:
Do we turn the indented code into patch 6 with no actual diff file?
A huge diff with white space changes is not too useful unless forked versions are being merged. It's OK withg me to dispense with a diff for this patch, though if you made one, might as well upload it even if it is huge. We're not disk space bound yet. Maybe never will be the way disks are getting bigger.
I've only done the one diff file so far. If we make a diff, I should increment the patch number. If we just do a syncing source, that may not be necessary. I need to find the current version of indent for the DOS environment before I can tackle them.
When I start CVS do you want to start with the present or capture old versions? I guess I favor starting with the present and capturing the history on a CD. If we decided there was value in capturing the history I could do that.
Starting with the present is fine. At least once I can make CVS work, otherwise some time in the future would be best. 8-))
I have a love hate relationship with CVS having used it at work for a while (much more love than hate). The functionality is wonderful, and routine operations are incredibly easy, but other operations require looking up arcane commands and switches. It really needs to be driven with a GUI. There are some, but I don't have one for my current work environment (IBM AIX).
I had been working with a GUI, but I've since reformatted and reloaded all the software and don't recall what it was. Jonathan
Jonathan wrote:
I've only done the one diff file so far. If we make a diff, I should increment the patch number. If we just do a syncing source, that may not be necessary.
If it's not a big extra effort, even white space changes only should get a patch number.
I need to find the current version of indent for the DOS environment before I can tackle them.
I thought I had one, but I don't. I'll look. There's one called inden19x.zip - try a google search for it. Tim
On Saturday 03 May 2003 01:45 pm, Tim Wegner wrote:
I've only done the one diff file so far. If we make a diff, I should increment the patch number. If we just do a syncing source, that may not be necessary.
If it's not a big extra effort, even white space changes only should get a patch number.
Okay, I'll take care of it.
I need to find the current version of indent for the DOS environment before I can tackle them.
I thought I had one, but I don't. I'll look. There's one called inden19x.zip - try a google search for it.
That's pretty old. So, it is probably what I have. Jonathan
On Saturday 03 May 2003 03:02 pm, Tim Wegner wrote:
That's pretty old. So, it is probably what I have.
I don't think indent has changed in a very long time.
The one that comes with the Mandrake distribution is copyright 2001. Before I get too far, are there any changes you would like to make to how indent is handling the source? Jonathan
On Saturday 03 May 2003 03:15 pm, Gerald K. Dobiasovsky wrote:
FYI, indent in DJGPP is version 2.2.5.
Much to my surprise, I found I didn't have any version of indent installed in my DJGPP environment. Having the latest version number helped me find it. Thanks. Jonathan
Tim, Just as another data point, the disk video mode locks up also when boundary tracing is used. Jonathan
Tim, Finally made some progress (although reading a book wasn't helping). Turning off periodicity checking helps, but does not cure the problem. It also seems to be resolution dependent. Try using a <v>iewwindow screen. The infinite loop occurs in a different location. I don't seem to be getting the coming_from variable outside of its proper range of values anymore (it does get stuck at 3, however). But, I did start over from an unmodified calcfrac.c file. Jonathan
Jonathan wrote:
although reading a book wasn't helping ...
I've been distracted building a computer. It was going to be a pure Linux machine, but after much gnashing of teeth I bought Windows XP. Maybe that's a good thing, maybe I can see how fractint works under XP. I also have an ATI card (Radeon 9500). In the past ATI cards have not had good VESA support, so I'll have to see if I can squeeze 1600x1200 video out of it. Tim
On Tuesday 17 June 2003 06:45 pm, Tim Wegner wrote:
I've been distracted building a computer. It was going to be a pure Linux machine, but after much gnashing of teeth I bought Windows XP. Maybe that's a good thing, maybe I can see how fractint works under XP. I also have an ATI card (Radeon 9500). In the past ATI cards have not had good VESA support, so I'll have to see if I can squeeze 1600x1200 video out of it.
My laptop has an ATI chip. It worked well enough to let me work on the scrolling virtual screens code. I'll be heading back to Iowa on Thursday evening and on Friday we are going to Colorado. Won't be back until the 29th. We'll have Fran's Ibook for saving images from the digital camera, but I won't be taking my computer. Jonathan
Jonathan wrote:
I'll be heading back to Iowa on Thursday evening and on Friday we are going to Colorado. Won't be back until the 29th. We'll have Fran's Ibook for saving images from the digital camera, but I won't be taking my computer.
In that case I won't wave to you from the airplane Friday night. Going to the Careleton reunion and then visiting my mother on the occasion of her 93rd birthday (that was actually yesterday). But I'll be back Monday night, and will take a computer. Tim
In article <3EB3A2E5.12091.A4E90@localhost>, "Tim Wegner" <twegner@swbell.net> writes:
When I start CVS do you want to start with the present or capture old versions? I guess I favor starting with the present and capturing the history on a CD. If we decided there was value in capturing the history I could do that.
I guess it all depends on how important it is to be able to go back to older versions before you migrate to CVS. I'm not active enough to answer the value in being able to do that.
[CVS] really needs to be driven with a GUI.
Try WinCVS <http://www.wincvs.org> -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> izfree: Open source tools for Windows Installer <http://izfree.sourceforge.net>
participants (4)
-
Gerald K. Dobiasovsky -
Jonathan Osuch -
Rich -
Tim Wegner