Re: [IMP-dev] [Fwd: Build system failure, 08/28/2008]

[Daniel Russel <>]

I haven't managed to figure out what is going on with VC. I did notice  
that I had removed some checks that would be good to have (I'll fix  
them later to be more efficient when checks are turned off).

Attachment: checks
Description: Binary data

In addition, changing AttributeTable.h::remove_always to the following
  void remove_always(Key k) {
    IMP_assert(k != Key(), "Can't remove default key");
    if (k.get_index() < map_.size()) {
      map_[k.get_index()]= Traits::get_invalid();
      /*while (!map_.empty()
	&& map_.back()== Traits::get_invalid()) map_.pop_back();*/
    }
  }

(that is, removing the cleanup loop), makes the problem go away. I  
think the line is OK, so it is all a bit disturbing.

(There probably are some trailing white spaces in the patch, sorry).

BTW, I stumbled upon the msdn page talking about the the /EH flag for  
visual studio. Do we need to build with /EH to get things cleaned up  
properly when we throw exceptions?

It also would perhaps be useful to have the debug version of the C++  
runtime available for the tests. Visual Studio has some really nice  
runtime checks for correctness of iterators and usage of the stl  
types. Just as a warning, I know some of my iterators will fail the  
tests (since apparently copying an invalid iterator is illegal and I  
didn't bother to write my own copy constructors in the Optimizer's  
iterator).

On Aug 28, 2008, at 11:14 AM, Ben Webb wrote:

> Daniel Russel wrote:
> > Just to check, you need to have the NBL tests and the attribute  
> > removal
> > test, but no others?
>
> Well, the two bipartite NBL tests, and the attribute removal test,  
> yes.
> (The crash actually seems to occur in set_is_optimized, not in
> remove_attribute itself.) If I removed either one of the NBL tests,  
> the
> bug went away. You can have *more* tests, but obviously it takes  
> longer
> to run the test suite then.
>
> > Now that I think about it, do we have any reasonable way of debugging
> > with wine? I wouldn't expect gdb to work.
>
> There is winedbg (I just installed it) but I don't know how well that
> will work. Adding print statements is the time-honored fallback (not
> sure I'd call that 'reasonable' though).
>
> > Are you using CGAL with wine? If not, then bbox NBL is actually a  
> > grid
> > NBL and I think there were a couple of bugs in that which I fixed but
> > never made it into IMP svn.  If you are using CGAL with wine, how  
> > do I
> > do that?
>
> No, CGAL isn't built for Wine on synth yet, so IMP is a non-CGAL  
> build.
>
> 	Ben
> --
>                       http://salilab.org/~ben/
> "It is a capital mistake to theorize before one has data."
> 	- Sir Arthur Conan Doyle
> _______________________________________________
> IMP-dev mailing list
>
> https://salilab.org/mailman/listinfo/imp-dev