Sorry, I forgot to subscribe to the bug and didn't see the previous comments. I think your figure looks right to me. Many of the examples are for cellular responses and they aren't going to look like physical waves. I've been actively testing the package I remade and all the numerics look correct.
On Wednesday 28 February 2007 04:33, Neil Williams wrote: > > # 64 Bit machines must use a different parser code. > > # In the OBJECTS section, replace parser2.o with parserslow2.o > > # it is not really that much slower so don't have a cow > > # > > > > I modified the Makefile in the source package and the error > > has gone away. Sorry I don't know patch syntax to give a patch, but > > the change is easy. > > The change would be easy if packages for each architecture were built > by hand but Debian uses automated buildd's that rely on the package > configuring itself to handle the architecture. xppaut doesn't include > the ./configure script that would normally take care of this which > makes a normal patch difficult. > > I'm experimenting with making a copy of 'Makefile' as 'Makefile.64' and > using a patch to debian/rules to use that Makefile when a 64bit arch is > detected. My problem is that I now need some code to test so that I can > determine whether the fix creates a usable binary on amd64. > > Added to debian/rules:12 > > DEB_BUILD_GNU_CPU ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_CPU) > > # method copied from db4.2 > USE_64PARSER_CPUS = zx86_64z > > ifeq (,$(findstring z$(DEB_BUILD_GNU_CPU)z,$(USE_64PARSER_CPUS))) > ${CP} Makefile.64 Makefile > endif > > (Only testing with amd64 so far). > > Can you provide some examples of how to test the package for the bug > you found? > > -- > > > Neil Williams > ============= > http://www.data-freedom.org/ > http://www.nosoftwarepatents.com/ > http://www.linux.codehelp.co.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]