Yes, I'm amazed this method.c didn't crash things a lot earlier (here,
never mind on the Mac). I still don't understand the aborts. It's
possible there is something funny going on with imports, in particular I
don't know what it really does with importing C shared libraries (and the
Mac is almost certainly different from Linux on that score). On the
Python side the imports almost all happen before anything runs (the
exceptions being that sometimes the imports are in functions to avoid
circular importing or similar, but I don't think that affects any of the
drawing ones).
Wayne
On Thu, 2 Jun 2005, Bruce D. Ray wrote:
> >Yes, this is crap. I just fixed that this morning and glad you sent out
> >this email so I don't have to explain it all. I've attached the amended
> >file method.c (which for the others belongs in
> >ccpnmr1.0/c/ccpnmr/analysis). You need to re-compile. I'm not sure what
> >planet I was on when those relevant lines got commented out.
>
>
> I can understand coding errors. What I don't understand is why this didn't
> trigger a divide fault and abort at some point. After all, if b was not set
> it could easily have been all sorts of nonsense that should have triggered
> an error.
>
>
> >In any case I would recommend against using this method (the "parabolic
> >fit") but would instead recommend one of the box sum methods (again, this
> >can be set in Crosspeaks -> Peak Find Parameters under "Other parameters",
> >the "volume method"). This time around I left the "parabolic fit" as the
> >default, but I'm going to switch that around next time.
>
>
> I combined this new version of method .c with the edit to py_peak_list.c
> to add new lines 441-444 as:
>
> >
> > else {
> > ndiagonal_exclusions = 0;
> > }
>
> and the changes at lines 2133 and 2140 of DataFormat.py so that they read
>
> > self.dataSource = self.peakList.dataSource
> and
>
> > if not self.peakListAssignmentCheck([self.peakList]):
>
> and added in the revised version of AnsigFormat.py that was sent out.
>
> On the Mac described previously, running OSX 10.3.9, with the fink python 2.3,
> fink tcl/tk 8.4, fink numeric 23.1, and fink glut 3.7, compilation to use tk
> graphics only (without OpenGL) gave only the usual error messages regarding
> long double and the nonexistence of /lib .
>
> My own project, analysis opens from a project name given on the command line without
> any difficulties. The tutorial project files analysis opened from the project name
> given on the command line the first time I tried it, but gave the abort error I
> reported previously the second time I tried to open it. I exited my X terminal,
> launched a new X terminal session, and tried opening this same tutorial project again,
> and I managed to open it twice in a row. This looks like it mostly fixed the problem
> I had reported. I'm suspicious of the one time I got the abort Is there any way that
> there could be a race condition where imports were not finished before windows dependent
> on some of those imports were being opened?
>
>
> Sincerely,
>
>
> --
> Bruce D. Ray, Ph.D.
> Associate Scientist, and Operations Director
> NMR Center
> IUPUI
> Physics Dept.
> 402 N. Blackford St.
> Indianapolis, IN 46202-3273
>
|