Dear All,
Regarding boost, to my best knowledge, the following modules of
boost have been used by gleap:
(1) shard_ptr: a smart pointer class to avoid memory leak
(2) any: a media data type which store any data type and casted back
when needed
(3) format: a library a lot c++ iostream work with C printf style
format string
%f, %d etc.
(4) string_algo: string algorithm, split, replace etc
(5) vector: numerical vector class of boost. This part seems to be
causing
the compilation problem.
(6) bind, lambda, function, functional: used with c++ stl algorithm to
simplify
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 think this can be done in a week. Problem is I cannot find a
place to test whether
it will work since I cannot find any machine with gcc-2.96 or icc 8.1
installed.
Thus it would be really helpful if somebody on this list can help me
get access to such a
machine.
In the meantime, I noticed that currently I am the only one who
is able to make major
changes to gleap code. I believe the only way to solve this problem is
documentation.
I am planning do it in the following steps:
(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.
Hopefully these can all be done in one month or two. Thus we can
release it with AmberTools
1.1.
BTW, Eric Peterson, developer of Chimera, is work on a Makefile
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.
Sincerely,
Wei
On May 6, 2008, at 12:28 PM, David A. Case wrote:
> On Mon, May 05, 2008, Scott Brozell wrote:
>
>> Apparently management decided boost was worth the cost,
>
> come on...you know that Wei (not "management") decides what happens
> with
> gleap. I don't have a clue about how/why boost is needed for gleap,
> nor how
> we merge boost bugfixes into our code, nor what we will do when Wei
> gets run
> over by a bus and no one else understands how that code works.
>
> Let's at least get a check in configure_at for version 1.1 that
> checks for
> gcc/g++ >=3.4 on cygwin/linux (and maybe version 4.x on Solaris and
> MacOSX),
> and skips gleap compilation with an appropriate informational
> message if a
> compliant compiler is not available. (Not clear to me where we stand
> with AIX.)
>
>> Management cant face that C++ is a better C.
>
> My point: C++ allows (encourages) people to write code that I can't
> read or
> debug. And I'm not the only one in this situation. If you get good
> returns
> by allowing flexible code, or less susceptibility to errors, fine.
> Too often,
> what you get looks like elsize.cc:
>
>> The elsize.cc code mixes C and C++ headers, mixes iostreams with
>> fprintf
>> statements, and still calls malloc/calloc to allocate arrays. As
>> far as I can
>> see, it sends the wrong type arguments to calloc(). It provides a
>> facility
>> for making natoms an unsigned long long variable(!), but never
>> bothers to
>> check the return from calloc(), which might seem prudent if your
>> system has
>> more than 4 billion atoms. and so on.
>
> For *this particular problem* (read a data file, calculate and print
> a result,
> quit) my view is that the language bears some of the responsibility
> here.
> Plus, it is the only program in Amber10 that requires C++: we could
> reduce our
> compiler requirements to just Fortran90 and C if this could be
> rewritten.
>
> But let's quit all this and get some real work done. There is no
> way that NAB
> will become C++, and no way that gleap or dock will not be C++.
> Right now, no
> one is willing to work on bondtype.C or elsize.cc, so those
> questions are
> moot.
>
>
Received on Wed May 07 2008 - 06:07:48 PDT
