Hi Ben,
I'll try my best to answer your questions, and Dave can add more
On Thu, Nov 3, 2011 at 10:02 AM, Ben Roberts <ben.roberts.geek.nz> wrote:
> I have a barrage of questions, some thoughts, and a recommendation.
>
> 1. Is tleap under active development? If so, who is developing it and
> knows the code? If not, why not (not that it necessarily should be)?
>
The answer is No. tleap is not under active development any more. The
reason is the main developer (I think is Christian ) has left AMBER
community and is never going back. The problem is tleap was written in a
very strange way. e.g, it was written in C but in an object-oriented
manner, which is very awkward because C is not naturally an OO language
(C++ has not been invented back then). Because of that, the code
is very hard to understand, or modify or extend. That's why there are some
functionalities which should be incorporated into tleap was
distributed as standalone programs such as addles, chamber, etc.
> 2. Is sleap under active development? If not, why not (not that it
> necessarily should be)? Does anyone besides Wei know and work with the code?
>
No, sleap is not under active development. The reason as I mentioned before
is: The need is not clear. The more time I spent on it, the more I got
frustrated.
>
> 3. Does it make sense to maintain at least one LEaP? I say yes.
>
Totally agree with you.
>
> 4. Does it make sense to maintain two or more independent LEaPs? I say no.
>
Totally agree with you too.
>
> 5. If (per #3 and #4) it makes sense to maintain precisely one LEaP, where
> should we focus our efforts – tleap, sleap, or neither? I say tleap, it
> being the de facto user standard and all.
>
Again, totally agree.
>
> 6. Do we want to get away from xleap and towards some more modern GUI? I
> say yes. Do we want to write our own? I say no; I think Wei's idea of
> linking with Chimera was a good one, provided however that I don't know the
> Chimera licence and I think we should probably link to a GUI that is free
> in the sense of both speech and beer.
>
Chimera is open source and free for academic use. On the other hand,
incorporating tleap into VMD should not be very difficult either. Both
Chimera and VMD were written in python.
> 7. If we start maintaining tleap again, should just one person be
> responsible for it? I say no, for fear that when that person leaves or
> can't keep up his maintenance role, we revert to the status quo in which
> problems aren't addressed. That will be even more true if we prepare a new
> LEaP to supersede both tleap and sleap.
>
>
> Thus, the recommendation:
>
> A number (say, three or four) of the current developers make an effort to
> learn the tleap code, fix current bugs, bring it up to speed, port over
> good features from sleap where their implementation is broken or
> nonexistent in tleap, and link tleap against a suitable GUI front end. They
> announce themselves, so the rest of the developers know who they are. They
> work with each other, with Wei, and with other people who know sleap or
> tleap well (hands up please!) throughout this process. The result is either
> a "fixed" tleap, or, if a complete revamp turns out to be warranted, a new
> LEaP program (e.g., uleap, for "unified LEaP" – the fact that U follows S
> and T had absolutely nothing to do with it =P). I'm willing to put my hand
> up for this, bearing in mind that I could only work on it during my spare
> time. But I don't want to do it on my own, for fear of becoming the next
> Wei and because I know I can't contribute much time. Besides, I have next
> to no experience with GUIs, unless one counts Java front-ends, so I would
> welcome input from those who know more than me.
>
I agree with you. I still believe that it is very important that we have
full control of the interface we use every day. It's just we have to do it
in a right way. First thing is to define our goals, what do we want
from a new leap? The following are my thoughts:
1. written in a modern language which naturally support OO, (C++, Java
or even Python)?
2. easy to understand and add new functionalities.
3. fix existing bugs.
4. hook to an advanced GUI.
but 1 an 2 are already contradicting since for many people that means one
more language to learn.
Sincerely,
Wei Zhang
>
> Alternatively:
>
> We carry on with the status quo, accepting that sleap and tleap are what
> they are, while fixing the occasional, easily accessible bug.
>
> Thoughts?
>
> Cheers,
> Ben
>
> On 2/11/2011, at 11:30 p.m., Wei Zhang wrote:
>
> > Hi All,
> >
> > When I started to write sleap in 2005, the original goal was to use
> it to
> > replace tleap, but after 6 years I have to admit that I have failed the
> goal,
> > miserably.
> >
> > Yes, sleap is a failed product. I hate to admit it but it is true. It
> is unstable,
> > and does not work as expected. The most important thing is sleap does not
> > generate identical topology as tleap does, thus it is hard for user to
> tell if
> > the resulted topology file is correct or not which make it useless.
> >
> > Here I try to summarize the reasons why I have failed, maybe people
> can
> > benefit from my failures:
> >
> > The No 1. reason is: The need was unclear, i.e. why do we need a
> replacement
> > for tleap? tleap is a very well written piece of software, it has been
> working for
> > decades. It surely has some bugs, but the correct solution should be to
> fix those
> > bugs, not to write a new one.
> >
> > The No 2. reason is: I totally underestimated the difficulty of the
> project. That's
> > why even though I was not asked to do it, I did it anyway. When I started
> > writing sleap, I thought it would take me at most 2 months. It turns out
> to be much
> > more complicated than I thought. Now I recall that Dave tried to warn me
> about
> > the difficulty, but I was so reckless at that time that I disregarded
> his warning.
> >
> > The No 3. reason is: I did not know tleap well enough. This is
> related to
> > reason No. 2. Because I though it was an easy job, I did not spend
> enough time to
> > study the tleap code and tried to understand every line of it. I just
> started on
> > my own.
> >
> > These are the lessons I learned from development of sleap. At this
> point
> > I am not sure what to do with it, and I would really appreciate your
> advices.
> > I guess the most important question is: Do we really need a replacement
> for
> > tleap? or we just need to fix bugs of tleap?
> >
> >
> >
> > Thank you very much!
> >
> > Sincerely,
> >
> > Wei Zhang
> >
> >
> > On Nov 2, 2011, at 8:32 PM, case wrote:
> >
> >> On Wed, Nov 02, 2011, Daniel Roe wrote:
> >>>
> >>> I think the only major thing sleap does that tleap doesn't do is set
> >>> up parms for AMOEBA right?
> >>
> >> Please cc comments about sleap to Wei Zhang <zgjzweig.gmail.com>,
> since he may
> >> not always follow the mail reflector.
> >>
> >> Just a brief addition to Jason's post (and Wei can add more if he
> wants):
> >> There *was* an original intent to create a graphical interface for sleap
> >> (hence the directory name gleap, short for gtk-leap). But Wei later
> >> decided to use Chimera as the graphical interface, and there are now
> >> dropdown menus in Chimera that allow one to build prmtop files and to do
> >> most of the things that tleap does (and more).
> >>
> >> But it is the case that (a) only a few people use the Chimera interface;
> >> (b) Wei is basically the only person (maybe along with Eric Pettersen)
> who
> >> feels comfortable in maintaining the code, so it has languished. [This
> can
> >> be a cautionary tale to those of you (Dan, Dave C., etc.) who have
> "your"
> >> code: it may never really take off until/unless you make sure that
> others
> >> can understand it, can modify it, and actually use and "buy into" it.]
> >>
> >> Wei will be at the meeting in January, so we can discuss this then, but
> email
> >> information exchange prior to that is also encouraged.
> >>
> >> ...dac
>
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu Nov 03 2011 - 11:30:08 PDT
