[omniORB] Can't run OmniPy out of the box? (_omniidl module problem)

[Keeping, Benjamin]

Hi,

I am running on Windows 2000, 32 bit, and have installed omniORB-4.1.1-x86-win32-vc7.zip (since that's the version of VC we use) and omniORBpy-3.1-x86-win32-python2.5.zip.

Having extracted the contents of these zips alongside each other under C:\projects [see footnote] and added C:\projects\omniORBpy-3.1\lib\python and C:\projects\omniORBpy-3.1\lib\x86_win32 to my PYTHONPATH, and C:\projects\omniORB-4.1.1\bin\x86_win32 to my PATH (I found that having C:\projects\omniORBpy-3.1\bin\x86_win32 in my PATH seemed to cause problems?) I now get the following error when trying to compile my first IDL file with "omniidl -bpython example_echo.idl ":
omniidl: Could not import back-end 'python'
omniidl: Maybe you need to use the -p option?
omniidl: (The error was 'No module named python')

From the documentation of omniidl, I can see that it will be trying to load the python module omniidl_be.python here. Running "import omniidl_be.python" from the Python interpreter gives me slightly more information - the problem is "import _omniidl" at line 97 of lib\python\omniidl\main.py. I can find nothing in either zip matching this name, i.e. containing "_omniidl". What am I doing wrong? Do I need to build something after all?

Ben Keeping
-----------------
Footnote: I did see the following instruction in the README:

"If you do not have Autoconf support on your platform (e.g. on
Windows), you must install the omniORBpy source in the $TOP/src/lib
directory of a working omniORB 4.1 tree. Make sure the directory is
called omniORBpy -- if you downloaded a release archive you must
rename the directory to remove the version from the directory name.

Once you have the source in the right place, simply do a make export
in the $TOP/src/lib/omniORBpy directory."

But assumed this didn't apply as I am not building anything from source.

______________________________________________________________________

This email is intended only for the use of the individual(s) to whom it is addressed and may be privileged and confidential.
Unauthorised use or disclosure is prohibited.If you receive This e-mail in error, please advise immediately and delete the original message.
This message may have been altered without your or our knowledge and the sender does not accept any liability for any errors or omissions in the message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20071116/214815b7/attachment.htm

[Duncan Grisby]

Post by Keeping, Benjamin
I am running on Windows 2000, 32 bit, and have installed
omniORB-4.1.1-x86-win32-vc7.zip (since that's the version of VC we
use) and omniORBpy-3.1-x86-win32-python2.5.zip.

Are you using omniORB from Python or C++ or both? The problem you are
encountering is that the binary omniORB distribution contains a cut-down
version of the ancient Python 1.5.2 for the IDL compiler.

If you install both the omniORB and omniORBpy binary distributions, you
must make sure your path is set such that C++ code and C++ IDL
compilation only sees the bin\x86_win32 directory in the omniORB
distribution and that Python code and Python IDL compilation only sees
the bin\x86_win32 directory in the omniORBpy distribution.

The problem you're seeing is that you have mixed the libraries from the
two separate binary distributions.

Duncan.

[Keeping, Benjamin]

To answer your question, I want to use both Python and C++ eventually, but my initial focus is Python.

Thanks, I may try what you suggest - in the meantime though I have started looking at ICE, and found it rather easier to get started with. This is despite years of experience using omniORB from C++.

What would your comments be on the comparison of the two?

Ben

-----Original Message-----
From: Duncan Grisby [mailto:***@grisby.org]
Sent: 19 November 2007 19:09
To: Keeping, Benjamin
Cc: omniorb-***@omniorb-support.com
Subject: Re: [omniORB] Can't run OmniPy out of the box? (_omniidl module
problem)

Post by Keeping, Benjamin
I am running on Windows 2000, 32 bit, and have installed
omniORB-4.1.1-x86-win32-vc7.zip (since that's the version of VC we
use) and omniORBpy-3.1-x86-win32-python2.5.zip.

Are you using omniORB from Python or C++ or both? The problem you are
encountering is that the binary omniORB distribution contains a cut-down
version of the ancient Python 1.5.2 for the IDL compiler.

If you install both the omniORB and omniORBpy binary distributions, you
must make sure your path is set such that C++ code and C++ IDL
compilation only sees the bin\x86_win32 directory in the omniORB
distribution and that Python code and Python IDL compilation only sees
the bin\x86_win32 directory in the omniORBpy distribution.

The problem you're seeing is that you have mixed the libraries from the
two separate binary distributions.

Duncan.
--
-- Duncan Grisby --
-- ***@grisby.org --
-- http://www.grisby.org --
________________________________________

This E-Mail (including any attachments) may contain privileged or confidential information. It is intended only for the addressee(s) indicated above.

The sender does not waive any of its rights, privileges or other protections respecting this information.

Any distribution, copying or other use of this E-Mail or the information it contains, by other than an intended recipient, is not sanctioned and is prohibited.

If you received this E-Mail in error, please delete it and advise the sender (by return E-Mail or otherwise) immediately.

This E-Mail (including any attachments) has been scanned for viruses.

It is believed to be free of any virus or other defect that might affect any computer system into which it is received and opened.

However, it is the responsibility of the recipient to ensure that it is virus free.

The sender accepts no responsibility for any loss or damage arising in any way from its use.

E-Mail received by or sent from RBC Capital Markets is subject to review by Supervisory personnel.

Such communications are retained and may be produced to regulatory authorities or others with legal rights to the information.

IRS CIRCULAR 230 NOTICE: TO COMPLY WITH U.S. TREASURY REGULATIONS, WE ADVISE YOU THAT ANY U.S. FEDERAL TAX ADVISE INCLUDED IN THIS COMMUNICATION IS NOT INTENDED OR WRITTEN TO BE USED, AND CANNOT BE USED, TO AVOID ANY U.S. FEDERAL TAX PENALTIES OR TO PROMOTE, MARKET, OR RECOMMEND TO ANOTHER PARTY ANY TRANSACTION OR MATTER.

[Duncan Grisby]

Post by Keeping, Benjamin
To answer your question, I want to use both Python and C++ eventually,
but my initial focus is Python.
Thanks, I may try what you suggest - in the meantime though I have
started looking at ICE, and found it rather easier to get started
with. This is despite years of experience using omniORB from C++.
What would your comments be on the comparison of the two?

I haven't looked at Ice much, and I've certainly never used it for a
real project. For C++, Ice definitely has a much nicer language mapping
since it uses standard C++. I don't think it makes a huge amount of
difference for Python, since the CORBA Python mapping is pretty simple.

For some of the things I use Python and CORBA with, the lack of
something like the Any type would be a real problem with ICE. Anys fit
really well with Python's dynamic typing.

Despite ZeroC's claims about performance, the last time I did any
performance measurements, omniORB was significantly faster than Ice for
most operations:

http://groups.google.com/group/comp.object.corba/browse_thread/thread/1106eb2c0ae4bc41/cc3468b0c5e1ef8e

Since that post, omniORB has gained some more intelligent string
marshalling code, so in plenty of cases the string performance should
beat Ice now. Of course, Ice may have got faster since then too.

And Ice isn't a standard, of course, which may or may not matter to you.

Cheers,

Duncan.

[Serguei Kolos]

Hi Duncan

Could you comment please on performance comparison between omniORB 4.0.7
and omniORB 4.1.0. Are there any improvements or worsening?

Cheers,
Sergei

Post by Duncan Grisby

Post by Keeping, Benjamin
To answer your question, I want to use both Python and C++ eventually,
but my initial focus is Python.
Thanks, I may try what you suggest - in the meantime though I have
started looking at ICE, and found it rather easier to get started
with. This is despite years of experience using omniORB from C++.
What would your comments be on the comparison of the two?

I haven't looked at Ice much, and I've certainly never used it for a
real project. For C++, Ice definitely has a much nicer language mapping
since it uses standard C++. I don't think it makes a huge amount of
difference for Python, since the CORBA Python mapping is pretty simple.
For some of the things I use Python and CORBA with, the lack of
something like the Any type would be a real problem with ICE. Anys fit
really well with Python's dynamic typing.
Despite ZeroC's claims about performance, the last time I did any
performance measurements, omniORB was significantly faster than Ice for
http://groups.google.com/group/comp.object.corba/browse_thread/thread/1106eb2c0ae4bc41/cc3468b0c5e1ef8e
Since that post, omniORB has gained some more intelligent string
marshalling code, so in plenty of cases the string performance should
beat Ice now. Of course, Ice may have got faster since then too.
And Ice isn't a standard, of course, which may or may not matter to you.
Cheers,
Duncan.

[Duncan Grisby]

Post by Serguei Kolos
Could you comment please on performance comparison between omniORB 4.0.7
and omniORB 4.1.0. Are there any improvements or worsening?

They are very similar in performance. In most code you probably won't
notice any difference. omniORB 4.1 has a faster Any implementation, and
string marshalling of short strings is faster. I'm not aware of any
situations in which 4.1 is slower than 4.0.

Cheers,

Duncan.