openbabel-scripting

Re: [OpenBabel-scripting] OBDotNet 0.2

[Matt S. <mes...@gm...>]

The names of some classes have been changed in V.2 to follow standard C# naming conventions. No further changes will be made to class names.

Renamed Classes:

atomreftype -> AtomRefType
errorQualifier -> ErrorQualifier
obMessageLevel -> OBMessageLevel
vectorBond -> VectorBond
vectorDouble -> VectorDouble
vectorInt -> VectorInt
vectorMol -> VectorMol
vectorOBVector3 -> VectorOBVector3
vectorpAtom -> VectorpAtom
vectorpBond -> VectorpBond
vectorpData -> VectorpData
vectorpInternalCoord -> VectorpInternalCoord
vectorpRing -> VectorpRing
vectorResidue -> VectorResidue
vectorRing -> VectorRing
vectorString -> VectorString


New Types:

CByteArray
CDoubleArray
CIntArray
CUIntArray
OBGenericDataType
OBNasaThermoData
OBRateData
OBRotamerList
OBRotor
OBRotorKeys
OBRotorList
OBRotorRule
OBRotorRules
openbabelcsharp
Rate_Type
Reaction_Type
SWIGTYPE_p_std__vectorT_double_t__iterator
SWIGTYPE_p_std__vectorT_unsigned_char_p_t__iterator
VectorOBExternalBond
VectorpRotor
VectorTorsion
VectorUInt
VectorUShort
VectorVecDouble
VectorVecInt
VectorVecOBVector3
VectorVecUInt



Version 0.3 Goals
-Implement reference equality comparison.
 
-Improve C style array proxies by implementing some type of support from enumeration.
 This will require customizing the wrapper defined in carrays.i.
 
-Determine whether or not to implement standard C#/PInvoke array marshaling.
	-Pros: Converting to C# arrays simplifies creating arrays
	-Cons: The arrays being marshaled to C# are copies
               rather than references to an unmanaged array.
 
-Streams: Either build a wrapper or add methods that redirect standard in/out.

-Get FastSearch working or implement equivalent functionality in DotBabel. Stream wrappers are the main barrier. 

-Develop workaround or complete the typemaps for std::map, std::pair, and std::triple.
 OBTorsion will not be fully functional until this is done.

-Get proxy for shared_ptr working so that reaction.h can added.
	-The macro define at line 29 of reaction.h "#define shared_ptr boost::shared_ptr"
         causes namespace problems in the generated C++ wrapper

-Resolve std::string wrapper issues. Some strings are not mapping correctly.

-Fix VectorpData GC bug.


DotBabel goals:
-XML serialization of OB objects	`

Re: [OpenBabel-scripting] OBDotNet 0.2

[Geoffrey H. <ge...@ge...>]

One problem... I just tried building:

(cd csharp; /usr/bin/gmcs /optimize /target:library /out:OBDotNet.dll  
*.cs);
OBAromaticTyper.cs(17,88): error CS0117:  
`OpenBabel.openbabelcsharpPINVOKE' does not contain a definition for  
`OBAromaticTyperUpcast'
openbabelcsharpPINVOKE.cs(14,7): (Location of the symbol related to  
previous error)
OBAromaticTyper.cs(41,58): error CS0117:  
`OpenBabel.openbabelcsharpPINVOKE' does not contain a definition for  
`new_OBAromaticTyper'
openbabelcsharpPINVOKE.cs(14,7): (Location of the symbol related to  
previous error)
double_array.cs(42,68): error CS0117:  
`OpenBabel.openbabelcsharpPINVOKE' does not contain a definition for  
`new_double_array'
openbabelcsharpPINVOKE.cs(14,7): (Location of the symbol related to  
previous error)
Compilation failed: 3 error(s), 0 warnings

Any suggestions? This is with Mono 2.4, which is the latest stable  
version.

-Geoff

Re: [OpenBabel-scripting] OBDotNet 0.2

[Noel O'B. <bao...@gm...>]

Does mcs work fine?

- Noel

2009/4/23 Geoffrey Hutchison <ge...@ge...>:
> One problem... I just tried building:
>
> (cd csharp; /usr/bin/gmcs /optimize /target:library /out:OBDotNet.dll *.cs);
> OBAromaticTyper.cs(17,88): error CS0117: `OpenBabel.openbabelcsharpPINVOKE'
> does not contain a definition for `OBAromaticTyperUpcast'
> openbabelcsharpPINVOKE.cs(14,7): (Location of the symbol related to previous
> error)
> OBAromaticTyper.cs(41,58): error CS0117: `OpenBabel.openbabelcsharpPINVOKE'
> does not contain a definition for `new_OBAromaticTyper'
> openbabelcsharpPINVOKE.cs(14,7): (Location of the symbol related to previous
> error)
> double_array.cs(42,68): error CS0117: `OpenBabel.openbabelcsharpPINVOKE'
> does not contain a definition for `new_double_array'
> openbabelcsharpPINVOKE.cs(14,7): (Location of the symbol related to previous
> error)
> Compilation failed: 3 error(s), 0 warnings
>
> Any suggestions? This is with Mono 2.4, which is the latest stable version.
>
> -Geoff
>

Re: [OpenBabel-scripting] OBDotNet 0.2

[Geoffrey H. <ge...@ge...>]

> Does mcs work fine?

Not really:

openbabelcsharp.cs(56,51): error CS1644: Feature `generics' is not  
available in Mono mcs1 compiler. Consider using the `gmcs' compiler  
instead

That's why I switched to gmcs.

-Geoff

Re: [OpenBabel-scripting] OBDotNet 0.2

[Noel O'B. <bao...@gm...>]

2009/4/22 Matt Sprague <mes...@gm...>

> Hello Noel,
>
> I've cobbled this email together from several emails I've been meaning to
> respond to so I hope that isn't too disjointed. The current version of the
> interface I've uploaded fixed an extend directive that was not being added
> to OBRotor. It should be good to go. Attached is a text file with a list of
> the new types available in v0.2 and a list of goals for v0.3. .Babel still
> needs a little more work before we do a release.
>
> I'm also planning to try and work up a test suite for the bindings that
> will test some of the C# only features over the next few weeks.
>
>
> A few outstanding things from previous emails:
>
> "BTW, if you're interested in support for std::pair, you'll need to
> %include std_pair.i."
>
> The problem with std::pair is that the typemap is not complete in
> swig_csharp. If we want to use std::pair and std::triple in the C# bindings
> we'll have to implement them ourselves. That's the only reason I've been
> looking at creating substitute methods using vectors.
>
> Also, it appears that they went ahead and added the generic vector wrapper
> to swig 1.3.39 so there is no need to include it separately. I've removed
> the file from the repository and added my additional method to the interface
> file.
>
>
>> I must admit that I preferred being able to compile directly using
>> obdotnet.bat from the VC2005 build. It seems to me that using the C#
>> sln file only introduces maintainence problems. E.g. the OB API
>> changes, so I need to update the OBDotNet solution file. Is there some
>> reason to prefer the solution file approach? Also, we may have to move
>> things out of the scripts/csharp directory that are not relevant to
>> the Unix build - however, we don't need to think about this until the
>> next OB release.
>
>
> My reasoning is as follows:
>
> 1)The files in the solution directory are replaced each time SWIG runs.
> Checking for changes just requires selecting View All Files and adding any
> new ones then refreshing or building the project to find and remove any
> missing files. Doing this from the project makes it easier to monitor
> changes in the bindings.
>
> 2)Using the sln it is easier to inspect the generated code and deal with
> errors/warnings that arise from modifying the interface file. It will also
> make things easier for other .Net programmers who might want to contribute
> to the project.
>
> 3)Having the solution allows developers to manually modify the swig
> generated files when protoyping new functionality.
>
> 4)It makes it easier for to keep DotBabel in sych with OBDotNet
>
> 5)Monodevelop has some support for importing VS projects. I haven't tested
> this (no current linux install) but it shouldn't be too difficult to create
> a parallel Monodevelop project for Linux/OSX users.
>
> If you still want to build with the bat file in addition to having a
> project I'm cool with that.
>

Understood. I think we will go with both if possible, or just with yours. I
will move your code into windows-vc2005 as it will confuse Unix users
otherwise. BTW, remember to edit the Changelog for each commit.


>
> Anyway, it's long past due time for OBDotNet 0.2. I think we should
>> base OBDotNet 0.2 on the same SVN revision that OB 2.2.1 is based on.
>> If you can check in AtomExtensions.cs, I will create a beta release of
>> 0.2. Then we can test it and write up some instructions for use and
>> get out the final release.
>>
>> - Noel
>>
>
> To revisit an older issue:
> "
> I'm assuming that it's not possible to access the cPtr in the
> SWIG-generated code (which would solve the problem, right?).
>
> I can't remember if I mentioned this or not, but the problem is that many
> of the intermediate methods are returning pointers to pointers so just
> comparing pointers fails in many cases.
>
> this is really a question for openbabel-devel. I have a feeling that
> the best you can do is to provide an equals method that just works for
> OBAtoms in the same molecule (using GetIdx), and leave it to the user
> to ensure that this is the case. Without being able to access the
> object pointer, it's never going to be possible to figure out if
> they're in the same molecule."
>
> I think it might be better to implement a couple of Comparer<T> types that
> do this rather than trying to customize the Equals methods. I can do it
> pretty quickly but I would like to get a new release out. Do you think this
> should be included in v0.2 or should we wait and add it in v0.3 as part of a
> larger effort aimed at getting equality comparisons working?
>

I think we want to get this out as soon as possible at this stage.


>
> Creating an installer has proved a little harder than I expected. The
> problem I'm having is that while creating the msi is easy, having it set the
> environment variables seems to be more complicated. Is there someone else
> with more dll deployment experience who can do it?
>

OB has special requirements due to its use of run-time plugins loaded from
DLLs. Would it be possible to reuse the DLLs supplied by the OpenBabelGUI?
This sets the environment variables PATH and BABELDATADIR. My Python
installer now just installs the .dll for Python (actually its a pyd) and
some py files, and uses the DLLs from OpenBabelGUI. The other thing is that
it installs the MSVC++ runtime, which is required by all of the bindings
(including the .NET ones).

But don't get bogged down in this - we can make do with a simple .zip file
if necessary, so long as we have clear installation instructions.

Can you explain (off-list probably better) how you are creating the msi and
I'll see if I can help some?


> Regarding documentation: I'm ready to update the wiki. Should I do it now
> or wait until we know when the release is coming.
>

Now is always better. :-) Just put it all under a heading like "Instructions
for OBDot 0.2" and say it's coming soon. Create an a/c and send me the name
if you haven't already.


>
> One final thing I'd like to start sending proper diff files but I keep
> getting the error message
>
> "svn: This client is too old to work with working copy '.'; please get a
> newer Subversion client"
> I looked it up on the web and what I found seemed to indicate that either
> my version of the client is either too new or too old. I've tried installing
> both newer and older versions but nothing fixes it. Any thoughts?
>

I use a mixture of tortoise svn (1.5.7) and the command-line client from
collabnet (1.5.5). Probably you should check out the whole repository into a
new folder with one of these guys and take it from there. SourceForge moved
to subversion 1.5 some time back, but until you used one of the newer
clients it didn't convert your local repository to subversion 1.5. After
that, the older clients wouldn't work.

>
> Apologies for the long email.
>

No probs. I'm very happy to see this going forward now.


>
> -Matt
>