orbit-python-list

[Orbit-python-list] Re: Promoting from integer to double in a union?

[Duncan G. <dg...@uk...>]

On Tuesday 21 March, Derek Thomson wrote:

My apologies to everyone on omniORB list who couldn't care less about
Python...

> The "Python Way (tm)" seems to be to insist on explicit conversions
> between basic types, so implicit conversions at the ORB interface
> would be inconsistent.
>
> Whether or not a rapid prototyping scripting language should insist
> on having the programmer continually perform basic type conversions
> is another debate.

It isn't true that Python always requires explicit conversion:

Python 1.5.2 (#7, Jun  4 1999, 14:52:53)  [GCC 2.7.2.3] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> 2 * 0.5
1.0
>>> 1 + 2L
3L

So there is a precedent for promoting integers to floats and longs,
hence omniORBpy's support for it.

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --

[Orbit-python-list] Re: [fnorb] Re: Promoting from integer to double in a union?

[Derek T. <de...@oo...>]

Jason Tackaberry wrote:
> 
> > I didn't really expect this to work, but it does with Fnorb and
> > omniORB. On the other hand, with orbit-python I get an exception:
> >
> >   CORBA.SystemException: IDL:omg.org/CORBA/BAD_PARAM:1.0:
> >       Expected float, got int
> 
> I was debating about whether or not I should promote ints to floats.  For
> consistency and readability, I decided to require a float value.  Also,
> the Python Language Mapping Specification doesn't explicitely permit
> integers here (I think).

The "Python Way (tm)" seems to be to insist on explicit conversions between
basic types, so implicit conversions at the ORB interface would be inconsistent.

Whether or not a rapid prototyping scripting language should insist on having
the programmer continually perform basic type conversions is another debate.

The next release of Fnorb will have these type checks, so that instead of
performing the obvious conversion, it will just give up and fall over with an
exception. Just like Python itself. Now *that* is progress. Sigh.

Regards,
Derek

[Orbit-python-list] Re: [fnorb] Re: [omniORB] Re: Promoting from integer to double in a union?

[Martin v. L. <lo...@in...>]

> This sort of discussion comparing Python ORBs would be better off in
> do...@py....
[...]
> The mapping spec should perhaps be tightened up to either explicitly
> permit or forbid such things.

As before, I'd also appreciate a message to is...@om..., with a
subject indicating that the Python FTF is being addressed. The public
comment deadline has passed, but we would certainly integrate
suggestions for a tighter specification.

Regards,
Martin

[Orbit-python-list] Re: [omniORB] Re: Promoting from integer to double in a union?

[Duncan G. <dg...@uk...>]

On Monday 20 March, Jason Tackaberry wrote:

> > I didn't really expect this to work, but it does with Fnorb and
> > omniORB. On the other hand, with orbit-python I get an exception:
> > 
> >   CORBA.SystemException: IDL:omg.org/CORBA/BAD_PARAM:1.0: 
> >       Expected float, got int
> 
> I was debating about whether or not I should promote ints to floats.  For
> consistency and readability, I decided to require a float value.  Also,
> the Python Language Mapping Specification doesn't explicitely permit
> integers here (I think).

This sort of discussion comparing Python ORBs would be better off in
do...@py....

An earlier version of the Python mapping did specify that compatible
types should be promoted. The current version has removed that
requirement. I think it is best to avoid promoting types in most
cases, and omniORBpy is reasonably strict. The only three promotions
it does are integers to floats, integers to doubles, and integers to
long integers, for the pragmatic reason that people often use integers
in those cases.

The mapping spec should perhaps be tightened up to either explicitly
permit or forbid such things.

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --

[Orbit-python-list] Re: Promoting from integer to double in a union?

[Jason T. <ta...@li...>]

> I didn't really expect this to work, but it does with Fnorb and
> omniORB. On the other hand, with orbit-python I get an exception:
> 
>   CORBA.SystemException: IDL:omg.org/CORBA/BAD_PARAM:1.0: 
>       Expected float, got int

I was debating about whether or not I should promote ints to floats.  For
consistency and readability, I decided to require a float value.  Also,
the Python Language Mapping Specification doesn't explicitely permit
integers here (I think).

Jason.

--
Unix/Network Administrator
Algoma University College
Sault Ste. Marie, Ontario
--
Assistant Project Manager: http://dev.linux.com
ORBit-Python Author: http://projects.sault.org/orbit-python
Personal Homepage: http://orion.dok.org

[Orbit-python-list] Promoting from integer to double in a union?

[Jon K H. <he...@ac...>]

I am evaluating orbit-python, a set of Python bindings for ORBit, and
am hoping for help in interpreting the CORBA/Python standard.

In the code below, sc.cell_set_value expects the parameter types long,
long and GNOME::Gnumeric::Value. The discriminant
GNOME.Gnumeric.VALUE_FLOAT indicates a double value. So I am creating
a union with an integer value, but claiming that it is a double.

    v=GNOME.Gnumeric.Value(GNOME.Gnumeric.VALUE_FLOAT, 1)
    sc.cell_set_value(1, 1, v)

I didn't really expect this to work, but it does with Fnorb and
omniORB. On the other hand, with orbit-python I get an exception:

  CORBA.SystemException: IDL:omg.org/CORBA/BAD_PARAM:1.0: 
      Expected float, got int

Fnorb and omniORB apparently promote the integer to double during
marshaling. Is this behaviour required by the standard, or was I just
lucky?

Regards

Jon K Hellan

[Orbit-python-list] Orbit-python-list -- confirmation of subscription -- request 782044

[<pb...@cb...>]

confirm 782044

[Orbit-python-list] Update

[Jason T. <ta...@li...>]

I've ported things over to C, so if you were having problems building
ORBit-Python on your platform, try a CVS build now.  The port to C has also
yielded a 5-10% speed increase that I didn't expect. :)

Exceptions, unions, and structs are still broken as noted before.  I'll be
working on that next.

Jason.

Re: [Orbit-python-list] orbit-python compile ?'s

[Brad C. <cha...@ar...>]

>>   File "./test-server", line 2, in ?
>>     import CORBA
>> ImportError: ./CORBAmodule.so: Undefined symbol "__builtin_vec_new"
>> 
>> I'm not sure what my problem is here--could anyone give me another 
>> push? Thanks in advance!
> 
> Are you using Solaris by any chance?  (If not, what platform are you
> using?)

FreeBSD 3.3

> The solution is to edit the Makefile and explicitely link 
CORBAmodula.so
> with libgcc.  

Great! That was exactly the problem. Now the tests work fine for me.

> I'm looking for an automake way to do this, but since that's
> not my forte it might take a little while. :)

No problem. I wish I could help, but unfortunately I'm just learning 
to use automake/conf myself. 
    Thanks for orbit-python! I'm really looking forward to playing 
around with it.

Brad

Re: [Orbit-python-list] orbit-python compile ?'s

[Jason T. <ta...@li...>]

>   File "./test-server", line 2, in ?
>     import CORBA
> ImportError: ./CORBAmodule.so: Undefined symbol "__builtin_vec_new"
> 
> I'm not sure what my problem is here--could anyone give me another 
> push? Thanks in advance!

Are you using Solaris by any chance?  (If not, what platform are you
using?)

The solution is to edit the Makefile and explicitely link CORBAmodula.so
with libgcc.  I'm looking for an automake way to do this, but since that's
not my forte it might take a little while. :)

Cheers,
Jason.

--
Unix/Network Administrator
Algoma University College
Sault Ste. Marie, Ontario
--
Assistant Project Manager: http://dev.linux.com
Personal Homepage: http://orion.dok.org

Re: [Orbit-python-list] orbit-python compile ?'s

[Brad C. <cha...@ar...>]

> I think I might know what the problem is: In the move from version
> ORBit-0.5.0 to ORBit-0.5.1 a lot of the char*s were turned to const
> char*s. Check that it isn't picking up a corba_typecode.h from a 
version
> of ORBit earlier than 0.5.1.

Thanks! That was exactly the problem. I didn't realize I was behind on 
my Orbit version--sorry!

Of course, now I have a different issue :-) The compile and install 
seem to go okay without a problem, but when I try to import CORBA I 
get the following:

  File "./test-client", line 3, in ?
    import CORBA
ImportError: /usr/local/lib/python1.5/site-packages/CORBAmodule.so: 
Undefined symbol "__builtin_new"

This happens if I build from the latest release.
    If I build from the latest cvs (autogen.sh && gmake && gmake 
install) I get the following similar traceback:

  File "./test-server", line 2, in ?
    import CORBA
ImportError: ./CORBAmodule.so: Undefined symbol "__builtin_vec_new"

I'm not sure what my problem is here--could anyone give me another 
push? Thanks in advance!

Brad

[Orbit-python-list] Re: CORBA.ORB_init

[Jason T. <ta...@li...>]

(I'm CCing this thread to the mailing list since people are actually
on it now. :))

> >>> p1.id
> 'third'
> >>> p2.id
> 'third'
> >>> p3.id
> 'third'

Oh dear.  I know precisely what the problem is, but I'm not entirely
sure how to fix it.  The problem is that the attributes are being
set for the class object, not for the instance object.  I'm not sure
why the built-in init function is getting the class object and not
the instance.  I may have to change my approach. *grumble*  Exceptions
will also exhibit this behavior because they use the same C function
as the constructor.  And unions will be flakey as well since I'm
taking the same approach.

Hopefully I will have this resolved tomorrow.

Jason.

Re: [Orbit-python-list] orbit-python compile ?'s

[Phil d. <ph...@us...>]

Brad Chapman wrote:
> 
> Hey all;
>     I was starting to play around with orbit-python (the most recent
> 0.1.2 release) last night and ran into some compile problems in idl.cc
> 
> g++295 -DPACKAGE=\"orbit-python\" -DVERSION=\"0.1.2\"  -I. -I.
> -I/usr/local/include/python1.5 -I/usr/local/include/python1.5 -fpic -O
> -pipe -D_THREAD_SAFE -I/usr/local/include/glib12 -I/usr/local/include
> 
> -g -O2 -c idl.cc
> idl.cc: In function `struct CORBA_TypeCode_struct *
> get_exception_typecode(_IDL_tree_node *)':
> idl.cc:788: assignment to `char **' from `const gchar **' discards
> qualifiers
> idl.cc: In function `struct CORBA_TypeCode_struct *
> get_struct_typecode(_IDL_tree_node *)':
> idl.cc:853: assignment to `char **' from `const gchar **' discards
> qualifiers
> idl.cc: In function `struct CORBA_TypeCode_struct *
> get_enum_typecode(_IDL_tree_node *)':
> idl.cc:918: assignment to `char **' from `const gchar **' discards
> qualifiers
> idl.cc: In function `struct CORBA_TypeCode_struct *
> get_union_typecode(_IDL_tree_node *)':
> idl.cc:978: assignment to `char **' from `const gchar **' discards
> qualifiers
> gmake[1]: *** [idl.o] Error 1
> gmake[1]: Leaving directory `/usr/home/chapmanb/orbit-python-0.1.2/src'
> gmake: *** [all-recursive] Error 1
> 
> I'm working on FreeBSD 3.3, and compiling with:
> $ g++295 -v
> gcc version 2.95.2 19991024 (release)
> 

I think I might know what the problem is: In the move from version
ORBit-0.5.0 to ORBit-0.5.1 a lot of the char*s were turned to const
char*s. Check that it isn't picking up a corba_typecode.h from a version
of ORBit earlier than 0.5.1.

Hope this helps,

Phil.

Re: [Orbit-python-list] orbit-python compile ?'s

[Phil d. <ph...@us...>]

Brad Chapman wrote:
> 
> [ initial problem snipped ]
> 
>     BTW, I started by trying to compile from the cvs source, and am
> missing some macros:
> aclocal: configure.in: 7: macro `AM_INIT_PYEXEC_MOD' not found in
> library
> aclocal: configure.in: 8: macro `AM_PATH_PYTHON' not found in library
> aclocal: configure.in: 16: macro `AM_PATH_ORBIT' not found in library
> Is there a good source for these? I started hunting around but only
> found AM_INIT_PYEXEC_MOD (which still depends on AM_PATH).
>     Thanks in advance!
> 

Hi Brad,

I think you need a really recent version of ORBit to get the
AM_PATH_ORBIT macro - I think it's installed as part of ORBit-0.5.1 in
/usr/share/aclocal/ORBit.m4

The python macros are in the python-automake directory. Check out the
README there.

Hope this helps,

Phil.

[Orbit-python-list] orbit-python compile ?'s

[Brad C. <cha...@ar...>]

Hey all;
    I was starting to play around with orbit-python (the most recent 
0.1.2 release) last night and ran into some compile problems in idl.cc

g++295 -DPACKAGE=\"orbit-python\" -DVERSION=\"0.1.2\"  -I. -I.  
-I/usr/local/include/python1.5 -I/usr/local/include/python1.5 -fpic -O 
-pipe -D_THREAD_SAFE -I/usr/local/include/glib12 -I/usr/local/include  
  
-g -O2 -c idl.cc
idl.cc: In function `struct CORBA_TypeCode_struct * 
get_exception_typecode(_IDL_tree_node *)':
idl.cc:788: assignment to `char **' from `const gchar **' discards 
qualifiers
idl.cc: In function `struct CORBA_TypeCode_struct * 
get_struct_typecode(_IDL_tree_node *)':
idl.cc:853: assignment to `char **' from `const gchar **' discards 
qualifiers
idl.cc: In function `struct CORBA_TypeCode_struct * 
get_enum_typecode(_IDL_tree_node *)':
idl.cc:918: assignment to `char **' from `const gchar **' discards 
qualifiers
idl.cc: In function `struct CORBA_TypeCode_struct * 
get_union_typecode(_IDL_tree_node *)':
idl.cc:978: assignment to `char **' from `const gchar **' discards 
qualifiers
gmake[1]: *** [idl.o] Error 1
gmake[1]: Leaving directory `/usr/home/chapmanb/orbit-python-0.1.2/src'
gmake: *** [all-recursive] Error 1

I'm working on FreeBSD 3.3, and compiling with:
$ g++295 -v
gcc version 2.95.2 19991024 (release)

Could you all offer any suggestions/hints? I'm still learning about 
porting etc., and so I apologize in advance if there is an obvious 
solution :)

    BTW, I started by trying to compile from the cvs source, and am 
missing some macros:
aclocal: configure.in: 7: macro `AM_INIT_PYEXEC_MOD' not found in 
library
aclocal: configure.in: 8: macro `AM_PATH_PYTHON' not found in library
aclocal: configure.in: 16: macro `AM_PATH_ORBIT' not found in library
Is there a good source for these? I started hunting around but only 
found AM_INIT_PYEXEC_MOD (which still depends on AM_PATH). 
    Thanks in advance!

Brad