My big concern would be the inchi code, which has tons. If we do this for our
C++ and Python, I think it's a good goal.
Geoff
> On Jun 23, 2016, at 4:39 AM, Noel O'Boyle wrote:
>
> Hi all,
>
> Over the last year, several developers have spent time fixing warnings
> reported by various tools.
Yes, it's harmless. I saw that today and will try to clean it up tonight.
Geoff
On Jun 11, 2013, at 4:38 PM, Craig James wrote:
> I got the latest release from the git repository, and now everything I do
> prints this message (including OpenBabel tools):
>
> ==
> *
> I'm working on an OBFormat for parsing SMILES using my new Smiley parser. The
> initial tests look good but there is a specific problem regarding aromatic
> nitrogens. When I read a molecule using the new format and write out the
> caonical smiles, all aromatic nitrogens are written out as "[n
On Nov 13, 2012, at 7:07 AM, David van der Spoel wrote:
> Soon. I'm also including ESP points with new class based on OBGrid, but
> for this I need to find out how to add an instance of OBGrid to a molecule.
If you take a look at src/formats/gausscubeformat.cpp or
src/formats/opendxformat.cpp
> I just noticed that multipoles higher than dipole are not read in from
> Gaussian log files, and neither are ESP points!
These are relatively new data. I added the support (e.g., quadrupoles) in the
core library, but not complete implementations.
So yes, if you're willing to add support, peop
> formation. While the coding is available and straightforward, I don't
> know whether the OB policy allows one to read an additional file in
> order to get these numbers.
These are done through the various "table" classes. See src/data.cpp for
examples (i.e., periodic table in OBElementTable).
> Now that 2.3.2 has been tagged and released is git migration
> happening now? Or do we continue pushing to svn until further
> notice? Will there be required no-commit time for the switch?
I'm currently traveling and won't be back in the office until Wednesday. I
think it's safer to deal with t
> And ChemSpyder seems to agree with this second one. Was this
> really intended to be caffein? And which of these then is
> correct for it?
The test structure was originally drawn with Ghemical ages ago (maybe 2001?).
You're correct that the other bonding is better. If you want to edit it, pleas
> Could we rehearse the arguments why we need to move to GitHub? I'm not
> well-informed, but Sourceforge makes a feature of software distribution
> (which, with 3000 downloads per month, we need); Github seems promote
> only its value to developers.
There's no either/or with Git. The whole poi
Chris,
I've been backed up and have not had much time to merge patches into the 2-3-x
branch yet. I'll do this over the next 2 days, but I think we'll have to push
back the actual release until next week.
Suggestions for release dates are welcome. Wednesday, perhaps?
> compatible: 4662 definit
> I found two slightly different datasets: MMFF94_dative.mol2 and
> MMFF94_hypervalent.mol2 . Which one of them is the one I should be
> using?
> …
See test/mmff94validate.cpp and the comments at the top. The easiest to grab is:
MMFF94_dative.mol2
MMFF94_opti.log
> tool(I am using OPro
> I originally had happyHTTP in the resolver format as you suggested,
> giving good modularity.
This is definitely what's going to happen for 2.3.2, along with some testing.
I'm a bit hesitant on code which is clearly unmaintained. But for one format,
it's probably OK.
> But it seems a shame n
On Jun 12, 2012, at 11:11 AM, My Th wrote:
> E is only marginally more intrusive than C, if there is no problem with
> it I'm committing only this one, otherwise I can also commit the minimal
> version if it is necessary for 2.3.x. This implementation goes as
> follows:
For 2.3.x, I'd much prefe
> Right, it came in C++ from C and should be in most compilers now. I also
> think that this is the best option. I'll write a patch for it. Only I'm
> reading that inttypes.h is not available for VS2003-2008, do we need a
> workaround for them? If so, maybe it is better to just define uint32_t
> my
I had some time to check SVN blame:
http://openbabel.svn.sf.net/viewvc/openbabel/openbabel/trunk/include/openbabel/bitvec.h?annotate=4853
So this is from Kevin Shepherd, which makes sense because he made some cleanups
elsewhere in the bitvec code.
> Now the issue is if USE_64BIT_INTEGER should b
> The one I am not quite certain about what it does is obspectrophore - it
> seems to have no manpage, the -help output is not very helpful and a
> wiki page on http://openbabel.org/wiki/Guides (Command-Line Programs)
> does not exist, either.
The wiki is an oversight. Here's the documentation:
ht
> I've got commitments on another project in the next two weeks. Could the
> target date for a 2.3.2 release be put back to June 29, with the Git
> migration after that?
No problem. I have a few minor OB projects that we'll squeeze in the meantime.
-Geoff
---
I asked about cmake because newer versions should set env variables correctly
to use the build dir.
Geoff
On May 30, 2012, at 4:41 AM, My Th wrote:
> T , 2012-05-30 09:26 +0100, Noel O'Boyle rakstīja:
>> On 30 May 2012 00:06, Craig James wrote:
>>> On Tue, May 29, 2012 at 2:42 PM, My Th wrot
> I started with a completely clean computer ... it didn't even have a g++
> compiler, cmake, or anything else (definitely not OpenBabel). This computer
> had never been used before.
Out of curiosity, what version of g++ and cmake are you using? Perhaps there's
an optimization or linking bug?
> Is there some timeline for the release, or just usual "coming soon"?
I think there needs to be a 2.3.x release really soon. I'm waiting to see some
resolution on Craig/Noel's discussions about stereochem issues.
> Could it be possible to move on with the switch if it is not happening
> within
> Would it make sense to coordinate a switch with an OpenBabel release? I'm
> not advocating yes or no, just curious.
Doesn't make much difference either way, but it's probably better not to impede
any pending bug-fix releases. Seems like we're due for a 2.3.x release with all
of Craig's bug r
> I should probably devise a test application to add to OpenBabel so that this
> doesn't happen again. Is there some way to add a test to the system where
> success is defined by performance rather than correct output?
There are a few ways. Probably the easiest is to add a small unit test (look
> This is discussed in the OB paper. 3D structure generation fails stereo in
> many cases of bridged rings, as we use ring templates of a particular stereo.
The only good solution to this is distance geometry like RDKit.
-Geoff
> I'm currently working with the development branch, SVN revision 4744
> (snapshot from about two weeks ago). If I run "make; make install; make
> test", almost every test crashes with a segmentation violation. This makes
> me nervous.
CDash suggests that everything except MinGW should be fin
> So from Avogadro, we'll need to know whether or not to expect these features
> to be available. Does OpenBabel export anything that will let us know if it
> was built with Eigen? Or is it just time to make Eigen a hard dependency for
> OB? Eigen is hardly difficult to find these days, are ther
> I think that at some point between v 2.2.3 and the current svn trunk, the
> result of OBAtom.GetAtomicNum() in Python changed from type 'int' to 'long'.
> Is this an intentional change to the API that I missed,
No, OBAtom::GetAtomicNum() in C++ returns an unsigned int and that hasn't
changed:
> I guess it's not so important, but maybe going forward we can attach a
> CC0 license to files if they are reusable by others.
Some of the files come via the Blue Obelisk Data Repository, so these aren't
covered by GPL even if the header says that.
Some of the other files would be a bit tricky
No, there is not yet support for grabbing all stereochemistry from CDX files.
In the 2.3.x effort, the stereochemistry code was completely rewritten.
If you are considering looking at the code, I suggest posting to the list, as
others (particularly Noel O'Boyle) can probably help.
-Geoff
On Fe
The person to ask would be Marcus -- he runs the Iodinium.kitware tester. I
agree that I have no issues with the tautomer test.
-Geoff
On Jan 12, 2012, at 11:01 AM, My Th wrote:
> Hi!
>
> londinium.kitware has similar configuration as my computer and I'm
> getting the segfault in tautomer test
On Jan 3, 2012, at 2:45 PM, David Lonie wrote:
> beyond the trust radius. I didn't track down which is happening, but
> switching to the Newton2Num line-search method fixes the problem for
> me (see OBForceField::SetLineSearchType()).
Do you think we should switch the default to the Newton line
> The weird thing is that IdentifyResidue can identify the first serine
> without any problems; it just doesn't identify the second one. Also,
> it will identify them both correctly if the --gen3d is omitted (or
> more precisely, if the call to Builder.Build is omitted).
This bug report exposed tw
> That would be great. Yes - the previous functions return true. But if
> I understand correctly, they are setting flags used by later
> calculations, and it may be that the problem is already caused at this
> stage?
Indeed. I can't see the exact problem yet, but it's clear that the
TracePeptideC
> I've discovered a subtle bug in the calculation of OBAtom::KBOSum(),
> specifically in OBAtom::GetImplicitValence, that causes the incorrect
> value to be returned for hydrogens with valence greater than one.
Thanks for this -- it's clear the bug can show up in other cases (e.g.,
hypervalent co
> and so on. There was once a time I'd have fixed this is g++, but I'm
> getting old. Hopefully, there's a willing volunteer to audit and fix the
> source tree.
Well, I got the low-hanging fruit with a "grep" test:
% grep 'empty()' *.cpp | grep 'size()'
The benefit of fixing this in our source
On Nov 16, 2011, at 5:09 AM, Noel O'Boyle wrote:
> I note in passing though, that we have not activated the spam filter on
> the list (see
> https://sourceforge.net/apps/trac/sourceforge/wiki/Mailing%20lists).
No, that's automatic. That's why we see moderation requests with SPAM in the
subject
> Geoff, what do you think about changing the way we do mailing list moderation.
> What do you think if we change things so that (a) we only moderate
> once a week, and (b) we highlight the fact that members are not
> moderated, and that otherwise a waiting period of up to a week should
> be expec
On Nov 10, 2011, at 5:15 PM, My Th wrote:
>> If you search the archives a bit further back it's a recurring theme
>> with every update. I was hoping it was resolved once and for all with
>> 2.3.0 but 2.3.1 broke things again :(
> The only solution I'm seeing for this is testing.
We have nightly
On Oct 11, 2010, at 4:18 PM, Chris Morley wrote:
> A simpler and more obvious model for this purpose has essentially a single
> IMPVAL for each charge state of the molecule. (Only if you are interested in
> radicals or hydrogen on the higher valency states of second row elements do
> you need
> more than 500 atoms, the output file is not the expected. Does anyone know
> where the problem can be?
I think you have to be more specific -- I regularly convert files of this size.
What does "not the expected" mean? Can you send us an example file or two?
-Geoff
-
> As far as I know it should not break binary compatibility, but I might
> be wrong.
>
> I hope this change gets in eventually in one form or another.
The change is a good one and it will eventually go in -- I'd be OK to apply it
to SVN trunk when Chris has a chance to look at it. (The loading o
> I'm trying to see if a one fragment is a sub-structure of a molecule and am
> using *OBIsomorphismMapper*, however when I start modifying the molecule
> (deleting atoms etc..), i start getting strange results, including some
> segmentation faults.
Meh. Generate a SMILES for your fragment. Since
> There are still some patches in tracker I submitted which haven't been
> accepted nor rejected. There are two issues I'm concerned with:
I don't think the patch tracker is properly notifying the list. I'll fix that
now.
> 1) Patch #3311952 adding GRO format
> http://sourceforge.net/tracker/?fu
At the moment, the Avogadro (and Open Babel) code has a heuristic to minimize
collinear atoms and 180° dihedrals. If you'd like to suggest another heuristic,
we can probably work on it.
Right now, the z-matrix code also won't create dummy atoms, and this may be
needed to reconcile your molecule
43 matches
Mail list logo
