Menu
▾
▴
openbabel-scripting — This list is deprecated. Please use openbabel-discuss instead.
This list is closed, nobody may subscribe to it.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(5) |
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
(10) |
Dec
(22) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(3) |
Feb
(10) |
Mar
(5) |
Apr
(12) |
May
(8) |
Jun
(9) |
Jul
(3) |
Aug
(11) |
Sep
|
Oct
(26) |
Nov
(21) |
Dec
(20) |
| 2007 |
Jan
(10) |
Feb
(32) |
Mar
(14) |
Apr
(13) |
May
(44) |
Jun
(13) |
Jul
(18) |
Aug
(26) |
Sep
(17) |
Oct
(3) |
Nov
(10) |
Dec
(8) |
| 2008 |
Jan
(20) |
Feb
(8) |
Mar
(28) |
Apr
(18) |
May
(22) |
Jun
(13) |
Jul
(4) |
Aug
(2) |
Sep
(19) |
Oct
(17) |
Nov
(8) |
Dec
(10) |
| 2009 |
Jan
(4) |
Feb
(3) |
Mar
(12) |
Apr
(15) |
May
(7) |
Jun
(1) |
Jul
(13) |
Aug
(3) |
Sep
(5) |
Oct
(2) |
Nov
(14) |
Dec
(13) |
| 2010 |
Jan
(9) |
Feb
(6) |
Mar
(21) |
Apr
(12) |
May
(4) |
Jun
|
Jul
(2) |
Aug
(15) |
Sep
(3) |
Oct
(1) |
Nov
(18) |
Dec
(6) |
| 2011 |
Jan
(7) |
Feb
(13) |
Mar
(17) |
Apr
(7) |
May
(16) |
Jun
(21) |
Jul
(15) |
Aug
(11) |
Sep
(12) |
Oct
(3) |
Nov
(14) |
Dec
(4) |
| 2012 |
Jan
(10) |
Feb
(4) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
(3) |
Dec
(1) |
| 2013 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(1) |
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
(5) |
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Noel O'B. <bao...@gm...> - 2007-02-19 10:36:58
|
Hello Jerome,
Sorry for the delay in replying...
On 19/02/07, Jerome Pansanel <j.p...@pa...> wrote:
> Hello,
>
> I'm developping a plugin for the PyMOL software, based on Open Babel. The goal
> of this plugin is to import any file supported by the Open Babel software.
That would be great!
> For this, I need to know which format are supported. I tried to use
> OBConversion::GetNextFormat from openbabel.py, but this don't work (I cannot
> set the first argument to OpenBabel::Formatpos & type).
True, this is a known problem. In Python, strings are immutable. As a
result, you cannot pass a reference to a string into a function.
> Therefore, I've developped a simple class, called OBSupportedFormat, that
> returns the supported chemical formats.
Why not just add a method to OpenBabel::OBConversion that returns a
std::list? That way, all users of OpenBabel would benefit too.
> It works fine into C++ software. When
> using SWIG wrapper for Python and calling the class OBSupportedFormat(), I
> get these errors:
>
> The compilation works without error, also when using -Wall flags.
> Do you have any hints ?
>
> Here's my obsupportedformat.i file:
> ***********************************************************
> %module obsupportedformat
>
> %{
> #include <Python.h>
> #include <string>
> #include <vector>
> #include <openbabel/obconversion.h>
>
> #include "obsupportedformat.h"
>
> %}
>
> %include "obsupportedformat.h"
> ***********************************************************
Special magic is needed to get OpenBabel to work correctly in SWIG. As
shown in lines 398 to 407 of
http://openbabel.svn.sourceforge.net/viewvc/openbabel/openbabel/trunk/scripts/Makefile.in?revision=1724&view=markup
the dlopenflags needs to be set before "import _openbabel" will work.
We use a Makefile hack as it is not possible to use SWIG to place
lines before "import _openbabel" in the generated Python module.
Noel
|
|
From: Jerome P. <j.p...@pa...> - 2007-02-19 10:05:48
|
Hello,
I'm developping a plugin for the PyMOL software, based on Open Babel. The goal
of this plugin is to import any file supported by the Open Babel software.
For this, I need to know which format are supported. I tried to use
OBConversion::GetNextFormat from openbabel.py, but this don't work (I cannot
set the first argument to OpenBabel::Formatpos & type).
Therefore, I've developped a simple class, called OBSupportedFormat, that
returns the supported chemical formats. It works fine into C++ software. When
using SWIG wrapper for Python and calling the class OBSupportedFormat(), I
get these errors:
***********************************************************
[...many_file_format.so did not load properly...]
/usr/lib/openbabel/fastsearchformat.so did not load properly
/usr/lib/openbabel/alchemyformat.so did not load properly
/usr/lib/openbabel/pdbformat.so did not load properly
/usr/lib/openbabel/reportformat.so did not load properly
/usr/lib/openbabel/fhformat.so did not load properly
/usr/lib/openbabel/ghemicalformat.so did not load properly
/usr/lib/openbabel/cmlreactlformat.so did not load properly
/usr/lib/openbabel/povrayformat.so did not load properly
/usr/lib/openbabel/bgfformat.so did not load properly
/usr/lib/openbabel/cacheformat.so did not load properly
/usr/lib/openbabel/balstformat.so did not load properly
***********************************************************
The compilation works without error, also when using -Wall flags.
Do you have any hints ?
Here's my obsupportedformat.i file:
***********************************************************
%module obsupportedformat
%{
#include <Python.h>
#include <string>
#include <vector>
#include <openbabel/obconversion.h>
#include "obsupportedformat.h"
%}
%include "obsupportedformat.h"
***********************************************************
Other files can be founded on this svn:
http://kopenbabel.svn.sourceforge.net/viewvc/kopenbabel/trunk/python/
Thanks,
Jerome Pansanel
|
|
From: Noel O'B. <bao...@gm...> - 2007-02-08 07:44:34
|
WW91J3JlIHJpZ2h0Li4uSSBuZWVkIHRvIHJlZ2VuZXJhdGUgdGhlIFNXSUcgYmluZGluZ3MuIEkg d2lsbCBkbyB0aGlzCnRvZGF5LiBJZiB5b3UgYXJlIGdvaW5nIHRvIGJlIHVzaW5nIHRoZSBjdXR0 aW5nIGVkZ2UgU1ZOIGNvZGUsIHlvdSBtYXkKZmluZCBpdCB1c2VmdWwgdG8gYmUgYWJsZSB0byBy ZWdlbmVyYXRlIHRoZXNlIGJpbmRpbmdzIHlvdXJzZWxmLgoKSWYgc28sIHlvdSB3aWxsIG5lZWQg dG8gZG93bmxvYWQgYSByZWNlbnQgdmVyc2lvbiBvZiBzd2lnIGFuZCBjb21waWxlCmFuZCBpbnN0 YWxsIGl0LiBZb3Ugd2lsbCBhbHNvIG5lZWQgdG8gcnVuICdjb25maWd1cmUKLS1lbmFibGUtbWFp bnRhaW5lci1tb2RlJyB3aGVuIHlvdSBjb25maWd1cmUgT3BlbkJhYmVsLiBUaGlzIGlzCmRlc2Ny aWJlZCBvbiB0aGUgSW5zdGFsbCBwYWdlIG9uIHRoZSBPcGVuQmFiZWwgd2lraS4KClJlZ2FyZHMs CiAgIE5vZWwKCk9uIDA4LzAyLzA3LCBKdXJnZW5zIGRlIEJydWluIDxkZWJydWluampAZ21haWwu Y29tPiB3cm90ZToKPiBOb2VsIHRoYW54IGZvciB0aGUgaGVscCBhbmQgdGhlIGFkdmljZS4KPgo+ ICBJIGFtIHNvcnJ5IHRvIHNheSBJIHJhbiBpbnRvIGFub3RoZXIgcHJvYmxlbS4gT3BlbmFiYWJl bCBpbnN0YWxscyBmaW5lIGJ1dAo+IHdoZW4gSSB3YW50IHRvIGluc3RhbGwgdGhlIHB5dGhvbiBk ZXZlbG9wbWVudCB1dGlscyAocHliZWwucHkgZXRjKSB1bmRlcgo+IHNjcmlwdHMvcHl0aG9uLgo+ Cj4KPiAgb3BlbmJhYmVsX3B5dGhvbi5jcHA6IEluIGZ1bmN0aW9uICdQeU9iamVjdCoKPiBfd3Jh cF9PQk1vbF9TZXBhcmF0ZV9fU1dJR18wKFB5T2JqZWN0KiwgUHlPYmplY3QqKSc6Cj4gIG9wZW5i YWJlbF9weXRob24uY3BwOjUyMDMzOiBlcnJvcjogJ2NsYXNzIE9wZW5CYWJlbDo6T0JNb2wnIGhh cyBubyBtZW1iZXIKPiBuYW1lZCAnU2VwYXJhdGUnCj4gIG9wZW5iYWJlbF9weXRob24uY3BwOiBJ biBmdW5jdGlvbiAnUHlPYmplY3QqCj4gX3dyYXBfT0JNb2xfU2VwYXJhdGVfX1NXSUdfMShQeU9i amVjdCosIFB5T2JqZWN0KiknOgo+ICBvcGVuYmFiZWxfcHl0aG9uLmNwcDo1MjA1NTogZXJyb3I6 ICdjbGFzcyBPcGVuQmFiZWw6Ok9CTW9sJyBoYXMgbm8gbWVtYmVyCj4gbmFtZWQgJ1NlcGFyYXRl Jwo+ICBlcnJvcjogY29tbWFuZCAnZ2NjJyBmYWlsZWQgd2l0aCBleGl0IHN0YXR1cyAxCj4KPgo+ ICAgSSBnZXQgdGhlIGZvbGxvd2luZyBlcnJvci4gSSBiZWxpdmUgdGhpcyBpcyBkdWUgdG8gdGhl IGZhY3QgT0JNb2wgaXMgbm90Cj4gcHJlc2VudCBpcyBTVk4gcmV2aXNpb24gMTc0MQo+Cj4gIHRo YW54IGFnYWluIGZvciBhbGwgdGhlIGhlbHAKPgo+Cj4gT24gMi83LzA3LCBOb2VsIE8nQm95bGUg PGJhb2lsbGVhY2hAZ21haWwuY29tPiB3cm90ZToKPiA+IFNpbmNlIHRoZSBidWcgeW91IGRlc2Ny aWJlZCBoYXMgYWxyZWFkeSBiZWVuIGZpeGVkLCBoZXJlJ3Mgd2hhdCB5b3UKPiA+IG5lZWQgdG8g ZG8uLi4KPiA+Cj4gPiAoMSkgY2hlY2sgb3V0IHRoZSBkZXZlbG9wbWVudCB2ZXJzaW9uIHVzaW5n Ogo+ID4gInN2biBjaGVja291dAo+IGh0dHBzOi8vc3ZuLnNvdXJjZWZvcmdlLm5ldC9zdm5yb290 L29wZW5iYWJlbC9vcGVuYmFiZWwvdHJ1bmsKPiA+IG9wZW5iYWJlbCIKPiA+ICgyKSB3aGVuZXZl ciB5b3Ugd2FudCB0byB1cGRhdGUsIGdvIGludG8gdGhlIG9wZW5iYWJlbCBmb2xkZXIgYW5kIHR5 cGUKPiA+ICJzdm4gdXBkYXRlIgo+ID4gKDMpIHdoZW5ldmVyIHlvdSB3YW50IHRvIGNoYW5nZSB0 byBhIHBhcnRpY3VsYXIgU1ZOIHJldmlzaW9uICggZS5nLiAxNzQxKSwKPiB0eXBlCj4gPiAic3Zu IHVwZGF0ZSAtciAxNzQxIgo+ID4KPiA+IFNvLCBpbiBzdW1tYXJ5LCB5b3Ugb25seSBuZWVkIHRv ICdjaGVja291dCcgb25jZS4gRnJvbSB0aGVuIG9uLCBpZiB5b3UKPiA+IHdhbnQgdG8ga2VlcCB1 cCB0byBkYXRlLCB5b3UganVzdCB1c2UgJ3VwZGF0ZScuIEFub3RoZXIgbmljZSBjb21tYW5kCj4g PiBpcyAnc3ZuIGxvZycgaWYgeW91IHdhbnQgdG8gc2VlIHdoYXQncyBuZXcgZmVhdHVyZXMgaGF2 ZSBiZWVuIGFkZGVkLgo+ID4KPiA+IE5vdGUgdGhhdCB0aGlzIGlzIHRoZSBhYnNvbHV0ZSBsYXRl c3QgZGV2ZWxvcG1lbnQgdmVyc2lvbi4gU29tZXRpbWVzCj4gPiB0aGVyZSBtYXkgYmUgY29tcGls YXRpb24gcHJvYmxlbXMsIGV0Yy4sIGFuZCB3ZSBhcHByZWNpYXRlIGlmIHlvdQo+ID4gY291bGQg cmVwb3J0IHRoZXNlLiBIb3dldmVyLCB5b3UgbWF5IGZpbmQgaXQgZWFzaWVyIHRvIHVzZSB0aGUg bGF0ZXN0Cj4gPiBiZXRhIHJlbGVhc2Ugb2YgT3BlbiBCYWJlbCB3aGljaCB5b3UgY2FuIGRvd25s b2FkIGZyb20KPiA+Cj4gaHR0cDovL3NvdXJjZWZvcmdlLm5ldC9wcm9qZWN0L3Nob3dmaWxlcy5w aHA/Z3JvdXBfaWQ9NDA3MjgmcGFja2FnZV9pZD0xNTQwMTkKPiA+Cj4gPiBSZWdhcmRzLAo+ID4g ICAgTm9lbAo+ID4KPiA+IE9uIDA3LzAyLzA3LCBKdXJnZW5zIGRlIEJydWluIDxkZWJydWluampA Z21haWwuY29tPiB3cm90ZToKPiA+ID4gVG8gYWxsCj4gPiA+Cj4gPiA+IFRoYW54IHRvIGFsbCBm b3IgYW5zd2VyaW5nIG15IHByZXZpb3VzIHByb2JsZW0uIEJ1dCBJIGFtIGFmcmFpZCB0byBzYXkK PiB0aGF0Cj4gPiA+IEkgYW0gc3RpbGwgaGF2aW5nIHByb2JlbG1zIHdpdGggcHliZWwuIEFmdGVy IHJlYWRpbmcgdGhlIHByZXZpb3VzCj4gc29sdXRpb25zCj4gPiA+IHRvIG15IHByb2JsZW0gd2l0 aCBweWJlbCwgSSB1bmluc3RhbGwgZWQgb3BlbmJhYmVsIGFuZCBhbGwgdGhhdCBpcwo+IHJlbGF0 ZWQKPiA+ID4gdG8gaXQuCj4gPiA+Cj4gPiA+IFRoZW4gYXMgSSB1bmRlcnN0b29kICh0aGlzIGNv dWxkIGJlIHdoZXJlIHRoaW5nIHdlbnQgd3JvbmcpIEkgZG93bmxvYWQKPiA+ID4gYW5vdGhlciBz dm4gdmVyc2lvbiBvZiBvcGVuYmFiZWwuCj4gPiA+Cj4gPiA+ID4gc3ZuIGNvCj4gPiA+Cj4gaHR0 cHM6Ly9zdm4uc291cmNlZm9yZ2UubmV0L3N2bnJvb3Qvb3BlbmJhYmVsL29wZW5iYWJlbC9icmFu Y2hlcy9vcGVuYmFiZWwtMi0wLXgKPiA+ID4gb3BlbmJhYmVsCj4gPiA+Cj4gPiA+IENoZWNrZWQg b3V0IHJldmlzaW9uIDE3NDEuCj4gPiA+Cj4gPiA+IFRoZW4gYWZ0ZXIgaW5zdGFsbGluZyBldGMu IEkgIGZpbmQgIG91dCAgdGhhdCBweWJlbCBpcyBub3Qgd2l0aGluIHRoaXMKPiA+ID4gdmVyc2lv bi4KPiA+ID4KPiA+ID4gQW55IGhlbHAgb24gd2hhdCB2ZXJzaW9uIEkgc2hvdWxkIGdldCB0byBn ZXQgcHliZWwgZ29pbmcgd291bGQgYmUKPiBncmVhdGx5Cj4gPiA+IGFwcHJlY2lhdGVkLgo+ID4g Pgo+ID4gPiBUaGFueCBhbGwKPiA+ID4KPiA+ID4KPiA+ID4KPiA+ID4KPiA+ID4KPiA+ID4gLS0K PiA+ID4gUmVnYXJkcy9Hcm9ldGUvTWl0IGZyZXVuZGxpY2hlbiBHcsO8w59lbi9yZWN1ZXJkb3Mv bWVpbGxldXJlcyBzYWx1dGF0aW9ucy8KPiA+ID4gZGlzdGludGkgc2FsdXRpL3Npb25nL2R1w6wg ecO6L9C/0YDQuNCy0LXRggo+ID4gPgo+ID4gPiBKdXJnZW5zIGRlIEJydWluCj4gPiA+Cj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQo+ID4gPiBVc2luZyBUb21jYXQgYnV0IG5lZWQgdG8gZG8gbW9yZT8gTmVl ZCB0byBzdXBwb3J0IHdlYiBzZXJ2aWNlcywKPiBzZWN1cml0eT8KPiA+ID4gR2V0IHN0dWZmIGRv bmUgcXVpY2tseSB3aXRoIHByZS1pbnRlZ3JhdGVkIHRlY2hub2xvZ3kgdG8gbWFrZSB5b3VyIGpv Ygo+ID4gPiBlYXNpZXIuCj4gPiA+IERvd25sb2FkIElCTSBXZWJTcGhlcmUgQXBwbGljYXRpb24g U2VydmVyIHYuMS4wLjEgYmFzZWQgb24gQXBhY2hlCj4gR2Vyb25pbW8KPiA+ID4KPiBodHRwOi8v c2VsLmFzLXVzLmZhbGthZy5uZXQvc2VsP2NtZD1sbmsma2lkPTEyMDcwOSZiaWQ9MjYzMDU3JmRh dD0xMjE2NDIKPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KPiA+ID4gT3BlbkJhYmVsLXNjcmlwdGluZyBtYWlsaW5nIGxpc3QKPiA+ID4gT3BlbkJh YmVsLXNjcmlwdGluZ0BsaXN0cy5zb3VyY2Vmb3JnZS5uZXQKPiA+ID4KPiBodHRwczovL2xpc3Rz LnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9vcGVuYmFiZWwtc2NyaXB0aW5nCj4gPiA+ Cj4gPiA+Cj4gPgo+Cj4KPgo+IC0tCj4KPiBSZWdhcmRzL0dyb2V0ZS9NaXQgZnJldW5kbGljaGVu IEdyw7zDn2VuL3JlY3VlcmRvcy9tZWlsbGV1cmVzIHNhbHV0YXRpb25zLwo+IGRpc3RpbnRpIHNh bHV0aS9zaW9uZy9kdcOsIHnDui/Qv9GA0LjQstC10YIKPgo+IEp1cmdlbnMgZGUgQnJ1aW4K |
|
From: Kieron T. <kr...@so...> - 2007-02-07 17:32:24
|
Geoffrey Hutchison wrote: > < snip > > So if you'd like to see what atom types are getting ignored (and > generating the warning): > > my $atom = $obMol->GetAtom($_); > my $type = $atom->GetType(); > my $newtype = $atom_typer->Translate($type); > print "Requested type: $type Translated type: $newtype\n"; > $atom->SetType($newtype); Strangely, in the original code that started all this, the error in question doesn't appear until I actively call OBConverter's serialising routine. ( OBconverter->write ) It then generates one error for each and every atom, none of which have particularly exotic atom types. It seems to me that the conversion operation is somehow invoking an additional atom type translation but without passing the atom types around. I can only guess that it is detecting the fact that a target type has been set. If I have already manually set the new atom types in the manner of your code snippet above, the serialisation has those new types in spite of the chain of errors that follow. I hope that helps to clarify things. Kieron |
|
From: Geoffrey H. <ge...@ge...> - 2007-02-07 16:25:57
|
On Feb 7, 2007, at 6:51 AM, Noel O'Boyle wrote: > It's actually caused by the SetType command, not the Translate > command. No, that's certainly not correct. The error message can *only* be generated by the Translate command -- that's the only part of the code which emits that message. > my $newtype = $atom_typer->Translate($type); > $newtype = $type; > $atom->SetType($newtype); > > This doesn't cause any error message, although it is doing the same > Translate as normal. I don't know how good Perl is, but I suspect this is an obvious just- in-time optimization. It's clear to anyone (e.g. the Perl compiler) that the result of the $atom_typer->Translate($type) call is immediately thrown away. The warning comes when the requested type (e.g., from INT) in this example, isn't found in the atom type translation table. Let's say, for example, you request to translate "Qu". The code has no idea what to do, so it leaves the atom type alone, but gives a warning. I felt this was a good compromise so we So if you'd like to see what atom types are getting ignored (and generating the warning): my $atom = $obMol->GetAtom($_); my $type = $atom->GetType(); my $newtype = $atom_typer->Translate($type); print "Requested type: $type Translated type: $newtype\n"; $atom->SetType($newtype); Cheers, -Geoff |
|
From: Kieron T. <kr...@so...> - 2007-02-07 14:44:17
|
Thanks for your help. For now I will pretend the messages aren't there. Kieron Noel O'Boyle wrote: > Dear Kieron, > > I've reproduced your error message. > > It's actually caused by the SetType command, not the Translate > command. You can see this for yourself if you replace the loop text > by: > > my $atom = $obMol->GetAtom($_); > my $type = $atom->GetType(); > my $newtype = $atom_typer->Translate($type); > $newtype = $type; > $atom->SetType($newtype); > > This doesn't cause any error message, although it is doing the same > Translate as normal. If you remove the $newtype = $type, the error > messages reappear. It seems that SetType doesn't like the names of the > new types. I'm going to pass this problem onto the C++ whizzes to > figure out why, as I don't think it is a SWIG problem. > > Noel |
|
From: Noel O'B. <bao...@gm...> - 2007-02-07 11:51:32
|
Dear Kieron,
I've reproduced your error message.
It's actually caused by the SetType command, not the Translate
command. You can see this for yourself if you replace the loop text
by:
my $atom = $obMol->GetAtom($_);
my $type = $atom->GetType();
my $newtype = $atom_typer->Translate($type);
$newtype = $type;
$atom->SetType($newtype);
This doesn't cause any error message, although it is doing the same
Translate as normal. If you remove the $newtype = $type, the error
messages reappear. It seems that SetType doesn't like the names of the
new types. I'm going to pass this problem onto the C++ whizzes to
figure out why, as I don't think it is a SWIG problem.
Noel
P.S. For the record, the original test code is:
========================
#!/usr/bin/perl -w
#test script to access openBabel's functionality using the perl API
use strict;
use Chemistry::OpenBabel;
my $file_to_read = "test.xyz";
my $obMol = new Chemistry::OpenBabel::OBMol;
my $obConverter = new Chemistry::OpenBabel::OBConversion;
$obConverter->SetInAndOutFormats("xyz","mol2");
$obConverter->ReadFile($obMol,$file_to_read);
my $atom_typer = new Chemistry::OpenBabel::OBTypeTable;
$atom_typer->SetFromType("INT");
$atom_typer->SetToType("DRE");
for (1..$obMol->NumAtoms())
{
my $atom = $obMol->GetAtom($_);
my $type = $atom->GetType();
print $atom->GetAtomicMass." ".$atom->GetValence."\n";
my $newtype = $atom_typer->Translate($type);
#$atom_typer->Translate("INT","DRE");
#print "Type: $newtype\n";
$atom->SetType($newtype);
}
if ($obConverter->WriteFile($obMol, "typed_mol.mol2") ) {print
"Writing successful\n";} else {print "OBconversion failed\n";}
========================
On 06/02/07, Kieron Taylor <kr...@so...> wrote:
> Noel O'Boyle wrote:
> > I've applied this change to the development code, and it seems to
> > work, at least in Python. Are you familiar with checking code out of a
> > subversion repository? There are some instructions at:
> > http://openbabel.sourceforge.net/wiki/Install
> > under "Get latest development code".
> >
> > Noel
> >
>
> Hi Noel,
>
> I've checked out the development branch and tried to use it, but there
> is no apparent change in the output.
>
> Would you mind running my script (attached) with the corresponding data
> file to make sure it's not my local install that's borked?
>
> Just drop the XYZ file into the same directory as the script and run the
> script once you have the Perl module installed.
>
> Thanks,
>
> Kieron
>
>
>
>
|
|
From: Noel O'B. <bao...@gm...> - 2007-02-07 09:19:54
|
U2luY2UgdGhlIGJ1ZyB5b3UgZGVzY3JpYmVkIGhhcyBhbHJlYWR5IGJlZW4gZml4ZWQsIGhlcmUn cyB3aGF0IHlvdQpuZWVkIHRvIGRvLi4uCgooMSkgY2hlY2sgb3V0IHRoZSBkZXZlbG9wbWVudCB2 ZXJzaW9uIHVzaW5nOgoic3ZuIGNoZWNrb3V0IGh0dHBzOi8vc3ZuLnNvdXJjZWZvcmdlLm5ldC9z dm5yb290L29wZW5iYWJlbC9vcGVuYmFiZWwvdHJ1bmsKb3BlbmJhYmVsIgooMikgd2hlbmV2ZXIg eW91IHdhbnQgdG8gdXBkYXRlLCBnbyBpbnRvIHRoZSBvcGVuYmFiZWwgZm9sZGVyIGFuZCB0eXBl CiJzdm4gdXBkYXRlIgooMykgd2hlbmV2ZXIgeW91IHdhbnQgdG8gY2hhbmdlIHRvIGEgcGFydGlj dWxhciBTVk4gcmV2aXNpb24gKGUuZy4gMTc0MSksIHR5cGUKInN2biB1cGRhdGUgLXIgMTc0MSIK ClNvLCBpbiBzdW1tYXJ5LCB5b3Ugb25seSBuZWVkIHRvICdjaGVja291dCcgb25jZS4gRnJvbSB0 aGVuIG9uLCBpZiB5b3UKd2FudCB0byBrZWVwIHVwIHRvIGRhdGUsIHlvdSBqdXN0IHVzZSAndXBk YXRlJy4gQW5vdGhlciBuaWNlIGNvbW1hbmQKaXMgJ3N2biBsb2cnIGlmIHlvdSB3YW50IHRvIHNl ZSB3aGF0J3MgbmV3IGZlYXR1cmVzIGhhdmUgYmVlbiBhZGRlZC4KCk5vdGUgdGhhdCB0aGlzIGlz IHRoZSBhYnNvbHV0ZSBsYXRlc3QgZGV2ZWxvcG1lbnQgdmVyc2lvbi4gU29tZXRpbWVzCnRoZXJl IG1heSBiZSBjb21waWxhdGlvbiBwcm9ibGVtcywgZXRjLiwgYW5kIHdlIGFwcHJlY2lhdGUgaWYg eW91CmNvdWxkIHJlcG9ydCB0aGVzZS4gSG93ZXZlciwgeW91IG1heSBmaW5kIGl0IGVhc2llciB0 byB1c2UgdGhlIGxhdGVzdApiZXRhIHJlbGVhc2Ugb2YgT3BlbiBCYWJlbCB3aGljaCB5b3UgY2Fu IGRvd25sb2FkIGZyb20KaHR0cDovL3NvdXJjZWZvcmdlLm5ldC9wcm9qZWN0L3Nob3dmaWxlcy5w aHA/Z3JvdXBfaWQ9NDA3MjgmcGFja2FnZV9pZD0xNTQwMTkKClJlZ2FyZHMsCiAgIE5vZWwKCk9u IDA3LzAyLzA3LCBKdXJnZW5zIGRlIEJydWluIDxkZWJydWluampAZ21haWwuY29tPiB3cm90ZToK PiBUbyBhbGwKPgo+IFRoYW54IHRvIGFsbCBmb3IgYW5zd2VyaW5nIG15IHByZXZpb3VzIHByb2Js ZW0uIEJ1dCBJIGFtIGFmcmFpZCB0byBzYXkgdGhhdAo+IEkgYW0gc3RpbGwgaGF2aW5nIHByb2Jl bG1zIHdpdGggcHliZWwuIEFmdGVyIHJlYWRpbmcgdGhlIHByZXZpb3VzIHNvbHV0aW9ucwo+IHRv IG15IHByb2JsZW0gd2l0aCBweWJlbCwgSSB1bmluc3RhbGwgZWQgb3BlbmJhYmVsIGFuZCBhbGwg dGhhdCBpcyByZWxhdGVkCj4gdG8gaXQuCj4KPiBUaGVuIGFzIEkgdW5kZXJzdG9vZCAodGhpcyBj b3VsZCBiZSB3aGVyZSB0aGluZyB3ZW50IHdyb25nKSBJIGRvd25sb2FkCj4gYW5vdGhlciBzdm4g dmVyc2lvbiBvZiBvcGVuYmFiZWwuCj4KPiA+IHN2biBjbwo+IGh0dHBzOi8vc3ZuLnNvdXJjZWZv cmdlLm5ldC9zdm5yb290L29wZW5iYWJlbC9vcGVuYmFiZWwvYnJhbmNoZXMvb3BlbmJhYmVsLTIt MC14Cj4gb3BlbmJhYmVsCj4KPiBDaGVja2VkIG91dCByZXZpc2lvbiAxNzQxLgo+Cj4gVGhlbiBh ZnRlciBpbnN0YWxsaW5nIGV0Yy4gSSAgZmluZCAgb3V0ICB0aGF0IHB5YmVsIGlzIG5vdCB3aXRo aW4gdGhpcwo+IHZlcnNpb24uCj4KPiBBbnkgaGVscCBvbiB3aGF0IHZlcnNpb24gSSBzaG91bGQg Z2V0IHRvIGdldCBweWJlbCBnb2luZyB3b3VsZCBiZSBncmVhdGx5Cj4gYXBwcmVjaWF0ZWQuCj4K PiBUaGFueCBhbGwKPgo+Cj4KPgo+Cj4gLS0KPiBSZWdhcmRzL0dyb2V0ZS9NaXQgZnJldW5kbGlj aGVuIEdyw7zDn2VuL3JlY3VlcmRvcy9tZWlsbGV1cmVzIHNhbHV0YXRpb25zLwo+IGRpc3RpbnRp IHNhbHV0aS9zaW9uZy9kdcOsIHnDui/Qv9GA0LjQstC10YIKPgo+IEp1cmdlbnMgZGUgQnJ1aW4K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tCj4gVXNpbmcgVG9tY2F0IGJ1dCBuZWVkIHRvIGRvIG1vcmU/IE5l ZWQgdG8gc3VwcG9ydCB3ZWIgc2VydmljZXMsIHNlY3VyaXR5Pwo+IEdldCBzdHVmZiBkb25lIHF1 aWNrbHkgd2l0aCBwcmUtaW50ZWdyYXRlZCB0ZWNobm9sb2d5IHRvIG1ha2UgeW91ciBqb2IKPiBl YXNpZXIuCj4gRG93bmxvYWQgSUJNIFdlYlNwaGVyZSBBcHBsaWNhdGlvbiBTZXJ2ZXIgdi4xLjAu MSBiYXNlZCBvbiBBcGFjaGUgR2Vyb25pbW8KPiBodHRwOi8vc2VsLmFzLXVzLmZhbGthZy5uZXQv c2VsP2NtZD1sbmsma2lkPTEyMDcwOSZiaWQ9MjYzMDU3JmRhdD0xMjE2NDIKPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IE9wZW5CYWJlbC1zY3JpcHRp bmcgbWFpbGluZyBsaXN0Cj4gT3BlbkJhYmVsLXNjcmlwdGluZ0BsaXN0cy5zb3VyY2Vmb3JnZS5u ZXQKPiBodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9vcGVuYmFi ZWwtc2NyaXB0aW5nCj4KPgo= |
|
From: Jurgens de B. <deb...@gm...> - 2007-02-07 05:53:52
|
VG8gYWxsCgpUaGFueCB0byBhbGwgZm9yIGFuc3dlcmluZyBteSBwcmV2aW91cyBwcm9ibGVtLiBC dXQgSSBhbSBhZnJhaWQgdG8gc2F5IHRoYXQKSSBhbSBzdGlsbCBoYXZpbmcgcHJvYmVsbXMgd2l0 aCBweWJlbC4gQWZ0ZXIgcmVhZGluZyB0aGUgcHJldmlvdXMgc29sdXRpb25zCnRvIG15IHByb2Js ZW0gd2l0aCBweWJlbCwgSSB1bmluc3RhbGwgZWQgb3BlbmJhYmVsIGFuZCBhbGwgdGhhdCBpcyBy ZWxhdGVkCnRvIGl0LgoKVGhlbiBhcyBJIHVuZGVyc3Rvb2QgKHRoaXMgY291bGQgYmUgd2hlcmUg dGhpbmcgd2VudCB3cm9uZykgSSBkb3dubG9hZAphbm90aGVyIHN2biB2ZXJzaW9uIG9mIG9wZW5i YWJlbC4KCj4gc3ZuIGNvCmh0dHBzOi8vc3ZuLnNvdXJjZWZvcmdlLm5ldC9zdm5yb290L29wZW5i YWJlbC9vcGVuYmFiZWwvYnJhbmNoZXMvb3BlbmJhYmVsLTItMC14b3BlbmJhYmVsCgpDaGVja2Vk IG91dCByZXZpc2lvbiAxNzQxLgoKVGhlbiBhZnRlciBpbnN0YWxsaW5nIGV0Yy4gSSAgZmluZCAg b3V0ICB0aGF0IHB5YmVsIGlzIG5vdCB3aXRoaW4gdGhpcwp2ZXJzaW9uLgoKQW55IGhlbHAgb24g d2hhdCB2ZXJzaW9uIEkgc2hvdWxkIGdldCB0byBnZXQgcHliZWwgZ29pbmcgd291bGQgYmUgZ3Jl YXRseQphcHByZWNpYXRlZC4KClRoYW54IGFsbAoKCgoKCi0tIApSZWdhcmRzL0dyb2V0ZS9NaXQg ZnJldW5kbGljaGVuIEdyw7zDn2VuL3JlY3VlcmRvcy9tZWlsbGV1cmVzIHNhbHV0YXRpb25zLwpk aXN0aW50aSBzYWx1dGkvc2lvbmcvZHXDrCB5w7ov0L/RgNC40LLQtdGCCgpKdXJnZW5zIGRlIEJy dWluCg== |
|
From: Chris M. <c.m...@ga...> - 2007-02-06 16:47:30
|
Geoffrey Hutchison wrote: > On Feb 6, 2007, at 9:00 AM, Noel O'Boyle wrote: > >> OBMol.Separate was introducted in SVN r1734. Until this is fixed, you >> may wish to use the preceding revision. > ... >>>> /usr/lib/python2.4/site-packages/_openbabel.so: undefined >>>> symbol: _ZN9OpenBabel5OBMol8SeparateEi > > > Aha! Yes, SWIG and Python seem to be extremely good at finding > methods declared in headers, but which do not have implementations in > the library. > > OBMol::Separate() was introduced into the SVN but has no > implementation. Chris, this seems to be your revision. Was this a > mistake, or did you forget the changes in mol.cpp? A mistake, my apologies. I have removed it in SVN 1741. This killer feature will shortly complete its extensive pre-commit testing and its release will no doubt shake the world of chemo-informatics. Not being an "only one sheet of paper on the desk at a time" person I struggle with maintaining pre-release features properly. Does SWIG have to behave this way? Is there an option to make it behave like C++ (whose design I would trust more). Yes, yes, I can hear you saying "a useful discipline, etc."... Chris |
|
From: Geoffrey H. <ge...@ge...> - 2007-02-06 14:46:45
|
On Feb 6, 2007, at 9:00 AM, Noel O'Boyle wrote: > OBMol.Separate was introducted in SVN r1734. Until this is fixed, you > may wish to use the preceding revision. ... >>> /usr/lib/python2.4/site-packages/_openbabel.so: undefined >>> symbol: _ZN9OpenBabel5OBMol8SeparateEi Aha! Yes, SWIG and Python seem to be extremely good at finding methods declared in headers, but which do not have implementations in the library. OBMol::Separate() was introduced into the SVN but has no implementation. Chris, this seems to be your revision. Was this a mistake, or did you forget the changes in mol.cpp? Thanks! -Geoff |
|
From: Noel O'B. <bao...@gm...> - 2007-02-06 14:00:22
|
T0JNb2wuU2VwYXJhdGUgd2FzIGludHJvZHVjdGVkIGluIFNWTiByMTczNC4gVW50aWwgdGhpcyBp cyBmaXhlZCwgeW91Cm1heSB3aXNoIHRvIHVzZSB0aGUgcHJlY2VkaW5nIHJldmlzaW9uLgoKT24g MDYvMDIvMDcsIE5vZWwgTydCb3lsZSA8YmFvaWxsZWFjaEBnbWFpbC5jb20+IHdyb3RlOgo+IERv bid0IHdvcnJ5IC0geW91J3JlIG5vdCBhbG9uZS4uLkknbSBnZXR0aW5nIHRoaXMgZXJyb3IgdG9v LCBhbmQgSQo+IHRob3VnaHQgaXQgd2FzIGp1c3QgbXkgZmF1bHQuIEkgZG9uJ3Qga25vdyB3aGF0 IHRoZSBwcm9ibGVtIGlzLAo+IHRob3VnaC4KPgo+IEFyZSB5b3UgdXNpbmcgdGhlIHNvdXJjZSBm cm9tIHN1YnZlcnNpb24/Cj4KPiBOb2VsCj4KPiBPbiAwNi8wMi8wNywgSnVyZ2VucyBkZSBCcnVp biA8ZGVicnVpbmpqQGdtYWlsLmNvbT4gd3JvdGU6Cj4gPiBUbyBhbGwKPiA+Cj4gPiAgSSB3YXMg d29uZGVyaW5nIGlmIHNvbWVvbmUgY2FuIGhlbHAgbWUgSSBhbSBoYXZpbmcgcHJvYmxlbXMgd2l0 aCBweWJlbC4KPiA+IFdoZW4gYSAiaW1wb3J0IHB5YmVsIiBJIGdldCB0aGUgZm9sbG93aW5nIGVy cm9yLgo+ID4KPiA+IEZpbGUgIjxzdGRpbj4iLCBsaW5lIDEsIGluID8KPiA+ICAgIEZpbGUgIi91 c3IvbGliL3B5dGhvbjIuNC9zaXRlLXBhY2thZ2VzL3B5YmVsLnB5IiwgbGluZQo+ID4gMSwgaW4g Pwo+ID4gICAgICBpbXBvcnQgb3BlbmJhYmVsIGFzIG9iCj4gPiAgICBGaWxlICIvdXNyL2xpYi9w eXRob24yLjQvc2l0ZS1wYWNrYWdlcy9vcGVuYmFiZWwucHkiLAo+ID4gbGluZSAxMSwgaW4gPwo+ ID4gICAgICBpbXBvcnQgX29wZW5iYWJlbAo+ID4gIEltcG9ydEVycm9yOgo+ID4gL3Vzci9saWIv cHl0aG9uMi40L3NpdGUtcGFja2FnZXMvX29wZW5iYWJlbC5zbzogdW5kZWZpbmVkCj4gPiBzeW1i b2w6IF9aTjlPcGVuQmFiZWw1T0JNb2w4U2VwYXJhdGVFaQo+ID4KPiA+ICBJIGhhdmUgbm8gaWRl YSB3aGF0IHRoaXMgbWVhbnMgb3IgaG93IHRvIHNvbHZlIGl0Lgo+ID4KPiA+Cj4gPiAtLQo+ID4g UmVnYXJkcy9Hcm9ldGUvTWl0IGZyZXVuZGxpY2hlbiBHcsO8w59lbi9yZWN1ZXJkb3MvbWVpbGxl dXJlcyBzYWx1dGF0aW9ucy8KPiA+IGRpc3RpbnRpIHNhbHV0aS9zaW9uZy9kdcOsIHnDui/Qv9GA 0LjQstC10YIKPiA+Cj4gPiBKdXJnZW5zIGRlIEJydWluCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4g PiBVc2luZyBUb21jYXQgYnV0IG5lZWQgdG8gZG8gbW9yZT8gTmVlZCB0byBzdXBwb3J0IHdlYiBz ZXJ2aWNlcywgc2VjdXJpdHk/Cj4gPiBHZXQgc3R1ZmYgZG9uZSBxdWlja2x5IHdpdGggcHJlLWlu dGVncmF0ZWQgdGVjaG5vbG9neSB0byBtYWtlIHlvdXIgam9iCj4gPiBlYXNpZXIuCj4gPiBEb3du bG9hZCBJQk0gV2ViU3BoZXJlIEFwcGxpY2F0aW9uIFNlcnZlciB2LjEuMC4xIGJhc2VkIG9uIEFw YWNoZSBHZXJvbmltbwo+ID4gaHR0cDovL3NlbC5hcy11cy5mYWxrYWcubmV0L3NlbD9jbWQ9bG5r JmtpZD0xMjA3MDkmYmlkPTI2MzA1NyZkYXQ9MTIxNjQyCj4gPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+ID4gT3BlbkJhYmVsLXNjcmlwdGluZyBtYWls aW5nIGxpc3QKPiA+IE9wZW5CYWJlbC1zY3JpcHRpbmdAbGlzdHMuc291cmNlZm9yZ2UubmV0Cj4g PiBodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9vcGVuYmFiZWwt c2NyaXB0aW5nCj4gPgo+ID4KPgo= |
|
From: Geoffrey H. <ge...@ge...> - 2007-02-06 13:31:05
|
On Feb 5, 2007, at 11:16 AM, Noel O'Boyle wrote:
> Geoff, does this line serve any useful purpose? I'll remove it
> otherwise.
It did at one point -- it was a contributed change before I added the
alternate C++ function:
//! Translate atom types
//! \return the translated atom type, or an empty string if
not possible
std::string Translate(const std::string &from);
Sorry if I forgot to remove the SWIG workaround.
Thanks,
-Geoff
|
|
From: Noel O'B. <bao...@gm...> - 2007-02-06 13:23:28
|
RG9uJ3Qgd29ycnkgLSB5b3UncmUgbm90IGFsb25lLi4uSSdtIGdldHRpbmcgdGhpcyBlcnJvciB0 b28sIGFuZCBJCnRob3VnaHQgaXQgd2FzIGp1c3QgbXkgZmF1bHQuIEkgZG9uJ3Qga25vdyB3aGF0 IHRoZSBwcm9ibGVtIGlzLAp0aG91Z2guCgpBcmUgeW91IHVzaW5nIHRoZSBzb3VyY2UgZnJvbSBz dWJ2ZXJzaW9uPwoKTm9lbAoKT24gMDYvMDIvMDcsIEp1cmdlbnMgZGUgQnJ1aW4gPGRlYnJ1aW5q akBnbWFpbC5jb20+IHdyb3RlOgo+IFRvIGFsbAo+Cj4gIEkgd2FzIHdvbmRlcmluZyBpZiBzb21l b25lIGNhbiBoZWxwIG1lIEkgYW0gaGF2aW5nIHByb2JsZW1zIHdpdGggcHliZWwuCj4gV2hlbiBh ICJpbXBvcnQgcHliZWwiIEkgZ2V0IHRoZSBmb2xsb3dpbmcgZXJyb3IuCj4KPiBGaWxlICI8c3Rk aW4+IiwgbGluZSAxLCBpbiA/Cj4gICAgRmlsZSAiL3Vzci9saWIvcHl0aG9uMi40L3NpdGUtcGFj a2FnZXMvcHliZWwucHkiLCBsaW5lCj4gMSwgaW4gPwo+ICAgICAgaW1wb3J0IG9wZW5iYWJlbCBh cyBvYgo+ICAgIEZpbGUgIi91c3IvbGliL3B5dGhvbjIuNC9zaXRlLXBhY2thZ2VzL29wZW5iYWJl bC5weSIsCj4gbGluZSAxMSwgaW4gPwo+ICAgICAgaW1wb3J0IF9vcGVuYmFiZWwKPiAgSW1wb3J0 RXJyb3I6Cj4gL3Vzci9saWIvcHl0aG9uMi40L3NpdGUtcGFja2FnZXMvX29wZW5iYWJlbC5zbzog dW5kZWZpbmVkCj4gc3ltYm9sOiBfWk45T3BlbkJhYmVsNU9CTW9sOFNlcGFyYXRlRWkKPgo+ICBJ IGhhdmUgbm8gaWRlYSB3aGF0IHRoaXMgbWVhbnMgb3IgaG93IHRvIHNvbHZlIGl0Lgo+Cj4KPiAt LQo+IFJlZ2FyZHMvR3JvZXRlL01pdCBmcmV1bmRsaWNoZW4gR3LDvMOfZW4vcmVjdWVyZG9zL21l aWxsZXVyZXMgc2FsdXRhdGlvbnMvCj4gZGlzdGludGkgc2FsdXRpL3Npb25nL2R1w6wgecO6L9C/ 0YDQuNCy0LXRggo+Cj4gSnVyZ2VucyBkZSBCcnVpbgo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiBVc2lu ZyBUb21jYXQgYnV0IG5lZWQgdG8gZG8gbW9yZT8gTmVlZCB0byBzdXBwb3J0IHdlYiBzZXJ2aWNl cywgc2VjdXJpdHk/Cj4gR2V0IHN0dWZmIGRvbmUgcXVpY2tseSB3aXRoIHByZS1pbnRlZ3JhdGVk IHRlY2hub2xvZ3kgdG8gbWFrZSB5b3VyIGpvYgo+IGVhc2llci4KPiBEb3dubG9hZCBJQk0gV2Vi U3BoZXJlIEFwcGxpY2F0aW9uIFNlcnZlciB2LjEuMC4xIGJhc2VkIG9uIEFwYWNoZSBHZXJvbmlt bwo+IGh0dHA6Ly9zZWwuYXMtdXMuZmFsa2FnLm5ldC9zZWw/Y21kPWxuayZraWQ9MTIwNzA5JmJp ZD0yNjMwNTcmZGF0PTEyMTY0Mgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCj4gT3BlbkJhYmVsLXNjcmlwdGluZyBtYWlsaW5nIGxpc3QKPiBPcGVuQmFi ZWwtc2NyaXB0aW5nQGxpc3RzLnNvdXJjZWZvcmdlLm5ldAo+IGh0dHBzOi8vbGlzdHMuc291cmNl Zm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL29wZW5iYWJlbC1zY3JpcHRpbmcKPgo+Cg== |
|
From: Jurgens de B. <deb...@gm...> - 2007-02-06 13:14:24
|
VG8gYWxsCgpJIHdhcyB3b25kZXJpbmcgaWYgc29tZW9uZSBjYW4gaGVscCBtZSBJIGFtIGhhdmlu ZyBwcm9ibGVtcyB3aXRoIHB5YmVsLiBXaGVuCmEgImltcG9ydCBweWJlbCIgSSBnZXQgdGhlIGZv bGxvd2luZyBlcnJvci4KCkZpbGUgIjxzdGRpbj4iLCBsaW5lIDEsIGluID8KICBGaWxlICIvdXNy L2xpYi9weXRob24yLjQvc2l0ZS1wYWNrYWdlcy9weWJlbC5weSIsIGxpbmUgMSwgaW4gPwogICAg aW1wb3J0IG9wZW5iYWJlbCBhcyBvYgogIEZpbGUgIi91c3IvbGliL3B5dGhvbjIuNC9zaXRlLXBh Y2thZ2VzL29wZW5iYWJlbC5weSIsIGxpbmUgMTEsIGluID8KICAgIGltcG9ydCBfb3BlbmJhYmVs CkltcG9ydEVycm9yOiAvdXNyL2xpYi9weXRob24yLjQvc2l0ZS1wYWNrYWdlcy9fb3BlbmJhYmVs LnNvOiB1bmRlZmluZWQKc3ltYm9sOiBfWk45T3BlbkJhYmVsNU9CTW9sOFNlcGFyYXRlRWkKCkkg aGF2ZSBubyBpZGVhIHdoYXQgdGhpcyBtZWFucyBvciBob3cgdG8gc29sdmUgaXQuCgoKLS0gClJl Z2FyZHMvR3JvZXRlL01pdCBmcmV1bmRsaWNoZW4gR3LDvMOfZW4vcmVjdWVyZG9zL21laWxsZXVy ZXMgc2FsdXRhdGlvbnMvCmRpc3RpbnRpIHNhbHV0aS9zaW9uZy9kdcOsIHnDui/Qv9GA0LjQstC1 0YIKCkp1cmdlbnMgZGUgQnJ1aW4K |
|
From: Noel O'B. <bao...@gm...> - 2007-02-06 09:40:30
|
I've applied this change to the development code, and it seems to work, at least in Python. Are you familiar with checking code out of a subversion repository? There are some instructions at: http://openbabel.sourceforge.net/wiki/Install under "Get latest development code". Noel On 05/02/07, Noel O'Boyle <bao...@gm...> wrote: > The reason these are shadowed is due to the following statement in > openbabel-perl.i: > """ > %apply std::string &OUTPUT {std::string &to}; > """ > > This causes the &to in the function header of Translate(std::string > &to, std::string const &from) to be removed from the parameter list, > and set as a return value instead, and this makes the two functions > equivalent from the point of view of Swig. > > Geoff, does this line serve any useful purpose? I'll remove it > otherwise. AFAIK, it's only possible to set the return types to > integers and floats, not std::strings, so I don't think this line does > anything helpful in any case. The relevant SWIG section is: > http://www.swig.org/Doc1.3/Arguments.html#Arguments_nn5 > > Noel > > On 05/02/07, Noel O'Boyle <bao...@gm...> wrote: > > I think I know the problem. When the SWIG wrappers are generated, the > > following error appears (copied by hand): > > """ > > data.h: Overloaded Translate(std::string const &) is shadowed by > > Translate(std::string &, std::string const &) at line 245. > > """ > > > > I'll have to read up a bit on this, but the bottom line is that you > > only have one of the above two functions as Swig thinks they are too > > similar to include both. This explains why you're getting the wrong > > return value as you're actually calling the wrong function. There's > > sure to be a way around this. I'll look into it, if Geoff doesn't get > > there first. > > > > Noel > > > > On 05/02/07, Kieron Taylor <kr...@so...> wrote: > > > Noel O'Boyle wrote: > > > > It might be unrelated to your problem, but have you set the > > > > environment variable BABEL_DATADIR to the 'data' directory? > > > > > > Nice try but no banana. The error is still forthcoming. I hasten to add > > > that the atom types are actually assigned and serialised, in spite of > > > the error. This means that it is finding the appropriate data files (I > > > hope). > > > > > > Thanks anyway. > > > > > > Kieron > > > > > > > > > > > On 05/02/07, Kieron Taylor <kr...@so...> wrote: > > > > > > > >> I've written some working code for assigning atom types for the various > > > >> forcefields by Perl API. It's pretty simple, but there are differences > > > >> from the v2.02 API. > > > >> > > > >> I get the following error with each atom, even though it performs the > > > >> appropriate transformation. I am uncertain what it is trying to do that > > > >> fails. Error: > > > >> ============================== > > > >> *** Open Babel Warning in Translate > > > >> Cannot perform atom type translation: table cannot find requested > > > >> types. > > > >> > > > >> I have a feeling I may be trying to get it to do the translation twice. > > > >> > > > >> Line 23 of my code $newtype = $atom_typer->Translate($type); does not > > > >> match the API documentation which claims to return Boolean from the > > > >> Translate call, rather than the new atom type. > > > >> > > > >> Here's the code: > > > >> --------------- > > > >> #!/usr/bin/perl > > > >> > > > >> use strict; > > > >> use Chemistry::OpenBabel; > > > >> > > > >> my $obMol = new Chemistry::OpenBabel::OBMol; > > > >> my $obConverter = new Chemistry::OpenBabel::OBConversion; > > > >> > > > >> $obConverter->SetInAndOutFormats("xyz","mol2"); > > > >> $obConverter->ReadFile($obMol,"file.xyz"); > > > >> > > > >> my $atom_typer = new Chemistry::OpenBabel::OBTypeTable; > > > >> > > > >> $atom_typer->SetFromType("INT"); > > > >> $atom_typer->SetToType("DRE"); > > > >> # DRE = Dreiding, INT = internal, others found in > > > >> # OpenBabel/data/types.txt > > > >> > > > >> for (1..$obMol->NumAtoms() ) > > > >> { > > > >> my $atom = $obMol->GetAtom($_); > > > >> my $type = $atom->GetType(); > > > >> my $newtype = $atom_typer->Translate($type); > > > >> $atom->SetType($newtype); > > > >> } > > > >> $obConverter->WriteFile($obMol, "typed_molecule.mol2") ; > > > >> > > > >> ----end-of-Perl--------- > > > >> > > > >> Any ideas what I'm missing here? > > > >> > > > >> Thanks, > > > >> > > > >> Kieron > > > >> > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------- > > > Using Tomcat but need to do more? Need to support web services, security? > > > Get stuff done quickly with pre-integrated technology to make your job easier. > > > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > > _______________________________________________ > > > OpenBabel-scripting mailing list > > > Ope...@li... > > > https://lists.sourceforge.net/lists/listinfo/openbabel-scripting > > > > > > |
|
From: Noel O'B. <bao...@gm...> - 2007-02-05 16:16:14
|
The reason these are shadowed is due to the following statement in
openbabel-perl.i:
"""
%apply std::string &OUTPUT {std::string &to};
"""
This causes the &to in the function header of Translate(std::string
&to, std::string const &from) to be removed from the parameter list,
and set as a return value instead, and this makes the two functions
equivalent from the point of view of Swig.
Geoff, does this line serve any useful purpose? I'll remove it
otherwise. AFAIK, it's only possible to set the return types to
integers and floats, not std::strings, so I don't think this line does
anything helpful in any case. The relevant SWIG section is:
http://www.swig.org/Doc1.3/Arguments.html#Arguments_nn5
Noel
On 05/02/07, Noel O'Boyle <bao...@gm...> wrote:
> I think I know the problem. When the SWIG wrappers are generated, the
> following error appears (copied by hand):
> """
> data.h: Overloaded Translate(std::string const &) is shadowed by
> Translate(std::string &, std::string const &) at line 245.
> """
>
> I'll have to read up a bit on this, but the bottom line is that you
> only have one of the above two functions as Swig thinks they are too
> similar to include both. This explains why you're getting the wrong
> return value as you're actually calling the wrong function. There's
> sure to be a way around this. I'll look into it, if Geoff doesn't get
> there first.
>
> Noel
>
> On 05/02/07, Kieron Taylor <kr...@so...> wrote:
> > Noel O'Boyle wrote:
> > > It might be unrelated to your problem, but have you set the
> > > environment variable BABEL_DATADIR to the 'data' directory?
> >
> > Nice try but no banana. The error is still forthcoming. I hasten to add
> > that the atom types are actually assigned and serialised, in spite of
> > the error. This means that it is finding the appropriate data files (I
> > hope).
> >
> > Thanks anyway.
> >
> > Kieron
> >
> > >
> > > On 05/02/07, Kieron Taylor <kr...@so...> wrote:
> > >
> > >> I've written some working code for assigning atom types for the various
> > >> forcefields by Perl API. It's pretty simple, but there are differences
> > >> from the v2.02 API.
> > >>
> > >> I get the following error with each atom, even though it performs the
> > >> appropriate transformation. I am uncertain what it is trying to do that
> > >> fails. Error:
> > >> ==============================
> > >> *** Open Babel Warning in Translate
> > >> Cannot perform atom type translation: table cannot find requested
> > >> types.
> > >>
> > >> I have a feeling I may be trying to get it to do the translation twice.
> > >>
> > >> Line 23 of my code $newtype = $atom_typer->Translate($type); does not
> > >> match the API documentation which claims to return Boolean from the
> > >> Translate call, rather than the new atom type.
> > >>
> > >> Here's the code:
> > >> ---------------
> > >> #!/usr/bin/perl
> > >>
> > >> use strict;
> > >> use Chemistry::OpenBabel;
> > >>
> > >> my $obMol = new Chemistry::OpenBabel::OBMol;
> > >> my $obConverter = new Chemistry::OpenBabel::OBConversion;
> > >>
> > >> $obConverter->SetInAndOutFormats("xyz","mol2");
> > >> $obConverter->ReadFile($obMol,"file.xyz");
> > >>
> > >> my $atom_typer = new Chemistry::OpenBabel::OBTypeTable;
> > >>
> > >> $atom_typer->SetFromType("INT");
> > >> $atom_typer->SetToType("DRE");
> > >> # DRE = Dreiding, INT = internal, others found in
> > >> # OpenBabel/data/types.txt
> > >>
> > >> for (1..$obMol->NumAtoms() )
> > >> {
> > >> my $atom = $obMol->GetAtom($_);
> > >> my $type = $atom->GetType();
> > >> my $newtype = $atom_typer->Translate($type);
> > >> $atom->SetType($newtype);
> > >> }
> > >> $obConverter->WriteFile($obMol, "typed_molecule.mol2") ;
> > >>
> > >> ----end-of-Perl---------
> > >>
> > >> Any ideas what I'm missing here?
> > >>
> > >> Thanks,
> > >>
> > >> Kieron
> > >>
> > >
> >
> >
> >
> >
> > -------------------------------------------------------------------------
> > Using Tomcat but need to do more? Need to support web services, security?
> > Get stuff done quickly with pre-integrated technology to make your job easier.
> > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> > _______________________________________________
> > OpenBabel-scripting mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/openbabel-scripting
> >
>
|
|
From: Noel O'B. <bao...@gm...> - 2007-02-05 15:47:11
|
I think I know the problem. When the SWIG wrappers are generated, the
following error appears (copied by hand):
"""
data.h: Overloaded Translate(std::string const &) is shadowed by
Translate(std::string &, std::string const &) at line 245.
"""
I'll have to read up a bit on this, but the bottom line is that you
only have one of the above two functions as Swig thinks they are too
similar to include both. This explains why you're getting the wrong
return value as you're actually calling the wrong function. There's
sure to be a way around this. I'll look into it, if Geoff doesn't get
there first.
Noel
On 05/02/07, Kieron Taylor <kr...@so...> wrote:
> Noel O'Boyle wrote:
> > It might be unrelated to your problem, but have you set the
> > environment variable BABEL_DATADIR to the 'data' directory?
>
> Nice try but no banana. The error is still forthcoming. I hasten to add
> that the atom types are actually assigned and serialised, in spite of
> the error. This means that it is finding the appropriate data files (I
> hope).
>
> Thanks anyway.
>
> Kieron
>
> >
> > On 05/02/07, Kieron Taylor <kr...@so...> wrote:
> >
> >> I've written some working code for assigning atom types for the various
> >> forcefields by Perl API. It's pretty simple, but there are differences
> >> from the v2.02 API.
> >>
> >> I get the following error with each atom, even though it performs the
> >> appropriate transformation. I am uncertain what it is trying to do that
> >> fails. Error:
> >> ==============================
> >> *** Open Babel Warning in Translate
> >> Cannot perform atom type translation: table cannot find requested
> >> types.
> >>
> >> I have a feeling I may be trying to get it to do the translation twice.
> >>
> >> Line 23 of my code $newtype = $atom_typer->Translate($type); does not
> >> match the API documentation which claims to return Boolean from the
> >> Translate call, rather than the new atom type.
> >>
> >> Here's the code:
> >> ---------------
> >> #!/usr/bin/perl
> >>
> >> use strict;
> >> use Chemistry::OpenBabel;
> >>
> >> my $obMol = new Chemistry::OpenBabel::OBMol;
> >> my $obConverter = new Chemistry::OpenBabel::OBConversion;
> >>
> >> $obConverter->SetInAndOutFormats("xyz","mol2");
> >> $obConverter->ReadFile($obMol,"file.xyz");
> >>
> >> my $atom_typer = new Chemistry::OpenBabel::OBTypeTable;
> >>
> >> $atom_typer->SetFromType("INT");
> >> $atom_typer->SetToType("DRE");
> >> # DRE = Dreiding, INT = internal, others found in
> >> # OpenBabel/data/types.txt
> >>
> >> for (1..$obMol->NumAtoms() )
> >> {
> >> my $atom = $obMol->GetAtom($_);
> >> my $type = $atom->GetType();
> >> my $newtype = $atom_typer->Translate($type);
> >> $atom->SetType($newtype);
> >> }
> >> $obConverter->WriteFile($obMol, "typed_molecule.mol2") ;
> >>
> >> ----end-of-Perl---------
> >>
> >> Any ideas what I'm missing here?
> >>
> >> Thanks,
> >>
> >> Kieron
> >>
> >
>
>
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> OpenBabel-scripting mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openbabel-scripting
>
|
|
From: Kieron T. <kr...@so...> - 2007-02-05 15:23:25
|
Noel O'Boyle wrote:
> It might be unrelated to your problem, but have you set the
> environment variable BABEL_DATADIR to the 'data' directory?
Nice try but no banana. The error is still forthcoming. I hasten to add
that the atom types are actually assigned and serialised, in spite of
the error. This means that it is finding the appropriate data files (I
hope).
Thanks anyway.
Kieron
>
> On 05/02/07, Kieron Taylor <kr...@so...> wrote:
>
>> I've written some working code for assigning atom types for the various
>> forcefields by Perl API. It's pretty simple, but there are differences
>> from the v2.02 API.
>>
>> I get the following error with each atom, even though it performs the
>> appropriate transformation. I am uncertain what it is trying to do that
>> fails. Error:
>> ==============================
>> *** Open Babel Warning in Translate
>> Cannot perform atom type translation: table cannot find requested
>> types.
>>
>> I have a feeling I may be trying to get it to do the translation twice.
>>
>> Line 23 of my code $newtype = $atom_typer->Translate($type); does not
>> match the API documentation which claims to return Boolean from the
>> Translate call, rather than the new atom type.
>>
>> Here's the code:
>> ---------------
>> #!/usr/bin/perl
>>
>> use strict;
>> use Chemistry::OpenBabel;
>>
>> my $obMol = new Chemistry::OpenBabel::OBMol;
>> my $obConverter = new Chemistry::OpenBabel::OBConversion;
>>
>> $obConverter->SetInAndOutFormats("xyz","mol2");
>> $obConverter->ReadFile($obMol,"file.xyz");
>>
>> my $atom_typer = new Chemistry::OpenBabel::OBTypeTable;
>>
>> $atom_typer->SetFromType("INT");
>> $atom_typer->SetToType("DRE");
>> # DRE = Dreiding, INT = internal, others found in
>> # OpenBabel/data/types.txt
>>
>> for (1..$obMol->NumAtoms() )
>> {
>> my $atom = $obMol->GetAtom($_);
>> my $type = $atom->GetType();
>> my $newtype = $atom_typer->Translate($type);
>> $atom->SetType($newtype);
>> }
>> $obConverter->WriteFile($obMol, "typed_molecule.mol2") ;
>>
>> ----end-of-Perl---------
>>
>> Any ideas what I'm missing here?
>>
>> Thanks,
>>
>> Kieron
>>
>
|
|
From: Noel O'B. <bao...@gm...> - 2007-02-05 15:07:24
|
It might be unrelated to your problem, but have you set the
environment variable BABEL_DATADIR to the 'data' directory?
On 05/02/07, Kieron Taylor <kr...@so...> wrote:
> I've written some working code for assigning atom types for the various
> forcefields by Perl API. It's pretty simple, but there are differences
> from the v2.02 API.
>
> I get the following error with each atom, even though it performs the
> appropriate transformation. I am uncertain what it is trying to do that
> fails. Error:
> ==============================
> *** Open Babel Warning in Translate
> Cannot perform atom type translation: table cannot find requested types.
>
> I have a feeling I may be trying to get it to do the translation twice.
>
> Line 23 of my code $newtype = $atom_typer->Translate($type); does not
> match the API documentation which claims to return Boolean from the
> Translate call, rather than the new atom type.
>
> Here's the code:
> ---------------
> #!/usr/bin/perl
>
> use strict;
> use Chemistry::OpenBabel;
>
> my $obMol = new Chemistry::OpenBabel::OBMol;
> my $obConverter = new Chemistry::OpenBabel::OBConversion;
>
> $obConverter->SetInAndOutFormats("xyz","mol2");
> $obConverter->ReadFile($obMol,"file.xyz");
>
> my $atom_typer = new Chemistry::OpenBabel::OBTypeTable;
>
> $atom_typer->SetFromType("INT");
> $atom_typer->SetToType("DRE");
> # DRE = Dreiding, INT = internal, others found in
> # OpenBabel/data/types.txt
>
> for (1..$obMol->NumAtoms() )
> {
> my $atom = $obMol->GetAtom($_);
> my $type = $atom->GetType();
> my $newtype = $atom_typer->Translate($type);
> $atom->SetType($newtype);
> }
> $obConverter->WriteFile($obMol, "typed_molecule.mol2") ;
>
> ----end-of-Perl---------
>
> Any ideas what I'm missing here?
>
> Thanks,
>
> Kieron
>
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> OpenBabel-scripting mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openbabel-scripting
>
|
|
From: Kieron T. <kr...@so...> - 2007-02-05 14:54:52
|
I've written some working code for assigning atom types for the various
forcefields by Perl API. It's pretty simple, but there are differences
from the v2.02 API.
I get the following error with each atom, even though it performs the
appropriate transformation. I am uncertain what it is trying to do that
fails. Error:
==============================
*** Open Babel Warning in Translate
Cannot perform atom type translation: table cannot find requested types.
I have a feeling I may be trying to get it to do the translation twice.
Line 23 of my code $newtype = $atom_typer->Translate($type); does not
match the API documentation which claims to return Boolean from the
Translate call, rather than the new atom type.
Here's the code:
---------------
#!/usr/bin/perl
use strict;
use Chemistry::OpenBabel;
my $obMol = new Chemistry::OpenBabel::OBMol;
my $obConverter = new Chemistry::OpenBabel::OBConversion;
$obConverter->SetInAndOutFormats("xyz","mol2");
$obConverter->ReadFile($obMol,"file.xyz");
my $atom_typer = new Chemistry::OpenBabel::OBTypeTable;
$atom_typer->SetFromType("INT");
$atom_typer->SetToType("DRE");
# DRE = Dreiding, INT = internal, others found in
# OpenBabel/data/types.txt
for (1..$obMol->NumAtoms() )
{
my $atom = $obMol->GetAtom($_);
my $type = $atom->GetType();
my $newtype = $atom_typer->Translate($type);
$atom->SetType($newtype);
}
$obConverter->WriteFile($obMol, "typed_molecule.mol2") ;
----end-of-Perl---------
Any ideas what I'm missing here?
Thanks,
Kieron
|
|
From: Chris M. <c.m...@ga...> - 2007-02-02 14:02:55
|
Geoffrey Hutchison wrote: > On Feb 1, 2007, at 4:26 PM, Noel O'Boyle wrote: > >> I'm glad to hear that you have solved the problem. We will release new >> versions of OpenBabelGUI and openbabel-python which will include these >> DLLs as described here (thanks to Chris for sorting this out): >> http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=164465&SiteID=1 > > I noticed these just showed up in the SVN tree -- but are these > really legal to distribute under the GPL? I have mixed feelings about > distributing a pile of binaries (DLLs) in the SVN tree in general. > But there's no clear copyright on the page you mentioned, which > worries me. Microsoft give a licence to distribute these DLL files with an application. To see what is normally done I looked at Tortoise SVN, a GPL Windows project. Tortoise distributes them, but seems to prepare their Windows installer with tools in Visual Studio that incorporates the DLLs automatically. The free version of Visual Studio that we use lacks these tools and the installer is prepared using the open source program NSIS. Noel put the script that NSIS uses on SVN; I thought that, for completeness, the DLLs that will be distributed in the installer package should be there too. But I see that it would avoid much tedious discussion on licences to keep the DLLs only on Windows machines with Visual Studio installed, so I have removed them from SVN (as far as is posible). They will of course be included in the Windows binary installer that is distributed. Chris |
|
From: buildez <bu...@bu...> - 2007-02-02 08:28:09
|
Hi Noel, another info, if you regenerate a package. I have tried installs with python 2.4 (or other versions) in a multi-install, such as python 2.4 installed in c:\python24, python 23 in c:\python23 etc it seems that we need also to have python installed in c:\python , i cannot explain, specific for my computers ? but perhaps that will be useful for you. Enjoy, Fred -- View this message in context: http://www.nabble.com/Re%3A-OpenBabel-for-Python-on-Windows-tf3147809.html#a8763360 Sent from the openbabel-scripting mailing list archive at Nabble.com. |
|
From: buildez <bu...@bu...> - 2007-02-02 08:22:33
|
yes, it's a real problem, I am currently working in french CNRS, and it seems also that I cannot distribute these runtime with packages of our own (enzyme kinetics) if open source licensing such as CECILL (~extended GPL) is used. >From the personal point of view of a simple user of your packages, it is not choking that we must get separately these runtime to complete installation, due to GPL licensing. Regards, Fred -- View this message in context: http://www.nabble.com/Re%3A-OpenBabel-for-Python-on-Windows-tf3147809.html#a8763308 Sent from the openbabel-scripting mailing list archive at Nabble.com. |
|
From: Geoffrey H. <ge...@ge...> - 2007-02-01 21:38:52
|
On Feb 1, 2007, at 4:26 PM, Noel O'Boyle wrote: > I'm glad to hear that you have solved the problem. We will release new > versions of OpenBabelGUI and openbabel-python which will include these > DLLs as described here (thanks to Chris for sorting this out): > http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=164465&SiteID=1 I noticed these just showed up in the SVN tree -- but are these really legal to distribute under the GPL? I have mixed feelings about distributing a pile of binaries (DLLs) in the SVN tree in general. But there's no clear copyright on the page you mentioned, which worries me. Thanks, -Geoff |
13 messages has been excluded from this view by a project administrator.
