C , 2011-11-10 17:35 -0500, Igor Filippov [Contr] rakstīja:
> > Or they could participate in the prerelease testing which now is
> > done by devs only, AFAIK.
>
> I was participating in building/testing from svn before one of the
> releases in the past, spent quite a bit of time and effort only to
> The only solution I'm seeing for this is testing. Maybe it would be
> worthwhile to make ar release candidate before the actual release and
> give a week for people willing to test the build to iron out all build
> issues.
>
This would be ideal. I think I was even asking for it at some point a
On 11/10/11 1:39 PM, Chris Morley wrote:
> On 10/11/2011 17:40, Igor Filippov [Contr] wrote:
>>
>>> The confusion caused by too much choice and the deficiencies in all of
>>> the above mean that MolCore API (the proposed re-writing of the central
>>> part of the toolkit) deserves better. I am pushi
C , 2011-11-10 17:04 -0500, Igor Filippov [Contr] rakstīja:
> > Solving the problems with static builds and MinGW, which I suspect
> are
> > are of interest to a minority of users, really needs input from a
> > developer who is using these features. Do you know of anyone willing
> to
> > help?
>
Chris,
> I hope you don't mind a harmless drudge getting some relaxation by
> speculating on what might be in a new program (not the next version of
> OB).
Absolutely, no problem!
I hope you will also forgive a harmless wish to keep things operational,
even for "a minority of users" :)
> As w
On 10/11/2011 17:40, Igor Filippov [Contr] wrote:
>
>> The confusion caused by too much choice and the deficiencies in all of
>> the above mean that MolCore API (the proposed re-writing of the central
>> part of the toolkit) deserves better. I am pushing for no atom indexes
>> at all, and only one
> The confusion caused by too much choice and the deficiencies in all of
> the above mean that MolCore API (the proposed re-writing of the central
> part of the toolkit) deserves better. I am pushing for no atom indexes
> at all, and only one way for a user to reference an atom - a sort of
> a
On Thu, Nov 10, 2011 at 12:13 PM, Chris Morley wrote:
> On 10/11/2011 15:35, David Lonie wrote:
> The confusion caused by too much choice and the deficiencies in all of
> the above mean that MolCore API (the proposed re-writing of the central
> part of the toolkit) deserves better. I am pushing fo
On 10/11/2011 15:35, David Lonie wrote:
>But I'm still confused as to why
> index and idx are both included in the API.
(Tim has just posted all this.)
idx is the original and still the most used and starts at 1. It changes
if you delete an atom with a lower idx.
index starts at 0 (because real
On Thu, Nov 10, 2011 at 11:51 AM, Geoffrey Hutchison wrote:
> On Nov 10, 2011, at 11:47 AM, My Th wrote:
>> The idea is to use everywhere zero-based indices in future [1], but the
>> library is in the state of transition, so there is quite a mess with
>> this. It's a task assigned to Geoff :)
> ..
On Nov 10, 2011, at 11:47 AM, My Th wrote:
> The idea is to use everywhere zero-based indices in future [1], but the
> library is in the state of transition, so there is quite a mess with
> this. It's a task assigned to Geoff :)
...
> But to fix all of that API change would be required.
I'll be
C , 2011-11-10 10:35 -0500, David Lonie rakstīja:
> On Thu, Nov 10, 2011 at 10:32 AM, David Lonie wrote:
> > The reason I ask is that I'm trying to limit an OBFF calculation with
> > OBForceField::AddInt[er,ra]Group[s], which takes the atom index, but
> > it's not clear to me whether this means th
Hi Tim,
First off, it's good to hear from you again :-) I'm glad you're still
active in the community.
On Thu, Nov 10, 2011 at 11:23 AM, Tim Vandermeersch
wrote:
> On Thu, Nov 10, 2011 at 4:32 PM, David Lonie wrote:
>> In atom.h, there are the following three functions:
>>
>> //! \return t
Hi,
On Thu, Nov 10, 2011 at 4:32 PM, David Lonie wrote:
> Hi list,
>
> In atom.h, there are the following three functions:
>
> //! \return the internal atom index (e.g., inside an OBMol)
> unsigned int GetIdx() const { return((int)_idx); }
> unsigned int GetIndex() const
Quick addition:
On Thu, Nov 10, 2011 at 10:32 AM, David Lonie wrote:
> The reason I ask is that I'm trying to limit an OBFF calculation with
> OBForceField::AddInt[er,ra]Group[s], which takes the atom index, but
> it's not clear to me whether this means the index, the idx, or the id.
>From readi
Hi list,
In atom.h, there are the following three functions:
//! \return the internal atom index (e.g., inside an OBMol)
unsigned int GetIdx() const { return((int)_idx); }
unsigned int GetIndex() const { return _idx - 1; }
unsigned long GetId() const { return _i
16 matches
Mail list logo
