On May 6, 2008, at 4:49 PM, David A. Case wrote:
> On Tue, May 06, 2008, Wei Zhang wrote:
>>
>> Regarding boost, to my best knowledge, the following modules of
>> boost have been used by gleap:
>>
>> (5) vector: numerical vector class of boost. This part seems to be
>> causing the compilation problem.
>
> Is this the "valarray" stuff? That seemed like a pretty nice feature,
> although I still have to learn more about how/if one can use these to
> communicate to and from "C" code.
>
>> Only (1) maybe (2) are absolute needs. All the others can be
>> replaced.
>> especially (5), which seems to be the root of all problems
>> according to the
>> error messages people posted.
>
> I'll leave this to your judgment. I don't have any problem
> requiring point
> (5) if it genuinely leads to better code. If it *is* valarray, then
> I would
> not want to give it up casually, just so someone with gcc 3.2 can
> compile
> sleap. We would just have to make it clear that it is indeed the
> requirement,
> and try to have the configure script test for that.
It is very similar to valarray but more complicated, thus easier to
cause problem.
I am thinking about change it to valarray now. Hope it will cause less
problem.
Speaking about gcc 3.2, yesterday I tried compile sleap with gcc 3.2.2
(20030222), it worked without any problem!!! Looks like sub version
matters,
i.e gcc 3.2.3 does not wok. I really need access to those compilers
which do
not work.
>
>
> Also, if it takes a week's work to undo this, that's a strong
> argument against
> making the change.
>
> On another point: is there code in amber11/src/gleap/freelib/boost
> that we are
> *not* using? There are directories there that don't seem to
> correspond
> to things you don't list above. If so, I'd like to clean that out
> so that we
> only distribute the things we are using. (New code can always be
> added later
> if you want to add new boost features.)
>
>>
>> (1) I have wrote a short paper (about 8 pages) which explains the
>> basic idea
>> of gleap, currently it is in MS word format, I will convert it to
>> pdf and
>> put it to CVS.
>>
>> (2) keep working on the programmers' guide.
>>
>> (3) I am now cleaning up the code and adding more comments to it.
>
> Great...I really appreciate this.
>
>> BTW, Eric Peterson, developer of Chimera, is work on a Makefile
> ^^^^^^^^^ = Pettersen, actually
>
>> which will allow AmberTools to be compile under various platform:
>> Mac,
>> Window, HP-UX and IRIX. He plans to include AmberTools in Chimera
>> distributions. Therefore, in the future, maybe we can instruct user
>> who have
>> problem compiling AmberTools to download and use the one come with
>> Chimera.
>
> Should we try to set up a meeting sometime with you, Scott, me and
> Eric (plus
> others?). It might be a UCSF. I'd like to learn more about how the
> Chimera
> connection will work, and how to build on the gleap foundation you
> have built.
> If we can truly get a functional graphics connection going, that
> would really
> be great.
It would be great if we can setup such a meeting. Currently
chimera and sleap
communicate using command line, i.e. In Chimera, we save molecules in
mol2 format
and send it to sleap, sleap save result also in mol2 format, and
chimera load it back.
I think it can be done in a much better way that the two should
be communicating at
Python level. i.e. sleap should have a python binding which Chimera
will call
and return a python object.
If possible, I hope the meeting can be held around June 15. By
then, I should have
finished the 3 chimera modules (solvate, addIons and saveParm), and
have some basic
ideas about the python binding of sleap.
Sincerely,
Wei
>
>
> ...thanks again for your contributions here....dave
>
>
Received on Wed May 07 2008 - 06:07:50 PDT
