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)?
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?
3. Does it make sense to maintain at least one LEaP? I say yes.
4. Does it make sense to maintain two or more independent LEaPs? I say no.
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.
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.
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.
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 - 08:30:03 PDT
