orbit-python-list

Re: [Orbit-python-list] Uploaded patch

[Roland M. <ma...@ec...>]

Jason Tackaberry (2000-08-14 14:05:32 -0400) :

> A couple of your changes are a bit puzzling to me, but I'll comb
> through it tonight and merge it in once I'm satisfied with it.

I'd be glad to explain them.  Which ones?

>  I'll also merge the rest of the patches, and possibly make some
> changes to my namespace "intrusions."  Probably time for a new
> release soon.

  Cool.  Thanks.  I'll probably build a Debian package for it, and
convert it to an RPM one (with alien).  I'll send them to you for
publishing on the Sourceforge download zone, if you like.

Roland.
-- 
Roland Mas

  ()    Campagne du ruban ascii :
  /\    Contre les mails en HTML et les vcard !

Re: [Orbit-python-list] Uploaded patch

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

>   Try it, have fun, send me comments and bug reports.

After a quick inspection it looks pretty good and cleans up a lot of the
pending FIXMEs.  A couple of your changes are a bit puzzling to me, but
I'll comb through it tonight and merge it in once I'm satisfied with it.
I'll also merge the rest of the patches, and possibly make some changes
to my namespace "intrusions."  Probably time for a new release soon.

Thanks,
Jason.

[Orbit-python-list] Uploaded patch

[Roland M. <ma...@ec...>]

Well, I cleaned my patch a bit, but it still is about 14 kb, so I
don't post it here.  I uploaded it to the Sourceforge page:
<URL:http://sourceforge.net/patch/?func=detailpatch&patch_id=101182&group_id=3561>.

  Try it, have fun, send me comments and bug reports.

Roland.
-- 
Roland Mas

Au royaume des aveugles, les borgnes sont mal vus.

Re: [Orbit-python-list] Almost there (was: memory leak)

[Roland M. <ma...@ec...>]

Roland Mas (2000-08-14 08:46:14 +0200) :

> Two more nights, much progress.  Now the server does not leak any
> memory anymore (yay!).  The client still does, however, when calling
> object methods (as opposed to getting/setting attributes).

Last minute update: it works!  Double-yay!  One hundred thousand
requests and not one kilobyte leaked!  Yay!  Yeepee!  Me happy!

  Er-uhm.  Have a nice day.  I'll send a new patch tomorrow morning.

Roland.
-- 
Roland Mas

  ()    Campagne du ruban ascii :
  /\    Contre les mails en HTML et les vcard !

Re: [Orbit-python-list] Almost there (was: memory leak)

[Roland M. <ma...@ec...>]

Roland Mas (2000-08-12 08:06:42 +0200) :

> Well, I'm almost there.  I spent the last two days (nights, actually)
> in src/server.c, and I fiddled in it a bit.  Here are my results.

Two more nights, much progress.  Now the server does not leak any
memory anymore (yay!).  The client still does, however, when calling
object methods (as opposed to getting/setting attributes).

>   I think the leak you mention in src/server.c is not real (or, it is
> not the only one).  Without doing anything with opd, I manage to
> suppress the memory leak in some cases.  I guess g_free takes care of
> things for you, but I wouldn't stake my life on it.

  Well, I was wrong there.  But I fixed the problem: instead of
allocating an operation description object for every request and
failing to free part of it, my version now allocates the description
object once only (when parsing the IDL), and thus need not deallocate
anything.  This fixed the memory leak in the server, and also in the
client, but only for _get_* / _set_* methods.  Work is in progress to
kill the leak for other methods.

  I'm so ashamed of my code that I won't publish any patch now (it's
really needing cleaning, there are bad comments and printf's
everywhere, the old code is merely commented out, and the indentation
model is not the old one).  I'll fix the last remaining leak tonight
and do a bit of cleaning, and with any luck, I'll post an updated
patch tomorrow morning (European morning, that is).  Stay tuned.

  Oh, and after that, I'll have a look at the leak in structs and
unions that you [Jason] mention.  Could you explain a bit why you
think there's a leak?  The comment isn't really explicit...

Roland.
-- 
Roland Mas

A lesson for you all: never fall in love during a total eclipse.
  -- Senex, in A Funny Thing Happened on the Way to the Forum

[Orbit-python-list] Almost there (was: memory leak)

[Roland M. <ma...@ec...>]

Jason Tackaberry (2000-08-10 07:17:46 -0400) :

> > I attach a simple server, client and IDL file.  They demonstrate a
> > memory leak somewhere: the server starts at about 2.5 kb and grows to
> 
> On second thought, your idl isn't using any structs or unions, which is
> where the leaks I've identified are.  You may want to look at leaks I've
> flagged in server.c and client.c.  I'm pretty sure I'm leaking memory
> with opd->parameters._buffer but I'm not sure how to free up that
> memory.  (I tried various things that result in a segfault.)  I'll poke
> around this some more, but I'd appreciate it if you could look into it
> too.

Well, I'm almost there.  I spent the last two days (nights, actually)
in src/server.c, and I fiddled in it a bit.  Here are my results.

  I think the leak you mention in src/server.c is not real (or, it is
not the only one).  Without doing anything with opd, I manage to
suppress the memory leak in some cases.  I guess g_free takes care of
things for you, but I wouldn't stake my life on it.

  We have four types of calls: the _get_*, the _set_*, the other
methods with parameters, and the other methods without parameters.
Using the (included) updated test-case suite, Orbit-Python leaks
memory for all four of them.

  I tried many things, adding and removing Py_INCREF's and Py_DECREF's
here and there, and I got a great many segfaults too :-) But in the
end, I gathered that the server needed a bit of clarification, since
the 'result' variable is used, overwritten, Py_INCREF'ed and
Py_DECREF'ed too many times.  So I cleaned the code a bit, added the
'fresult' variable, which contains the result object we'll have to
free at the end, and Py_DECREF'ed it.

  My results: the memory leak is dead in three of the four
aforementioned cases, namely the _get_* call and the method calls,
with and without parameters.  It remains unchanged as for the _set_*
calls, though (same pace of leak).

  I include my patch to the current CVS version, as well as the
updated test suite.  I'll also upload the patch to Sourceforge in a
few minutes.  I'm not quite sure of myself, so the more people use it
and crash-test it, the more certain I'll be that my patch broke things
or not.  If it does, please tell me!  I depend on feedback here...
Also, I'll continue investigating on the _set_* case, but I'm getting
blind at looking at the lines 105-115 and 125-130.  I'm almost sure
the bug is right there, though.

  May the Force be with us for the last (?) line,

Roland.

Re: [Orbit-python-list] Bug report: memory leak

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

> I attach a simple server, client and IDL file.  They demonstrate a
> memory leak somewhere: the server starts at about 2.5 kb and grows to

On second thought, your idl isn't using any structs or unions, which is
where the leaks I've identified are.  You may want to look at leaks I've
flagged in server.c and client.c.  I'm pretty sure I'm leaking memory
with opd->parameters._buffer but I'm not sure how to free up that
memory.  (I tried various things that result in a segfault.)  I'll poke
around this some more, but I'd appreciate it if you could look into it
too.

Thanks,
Jason.

Re: [Orbit-python-list] Bug report: memory leak

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

>   I'll try and investigate, looking for a missing decref, but I'm not
> sure I can find it myself.  Could someone else have a look?

There are a couple leaks in idl.c that I know about (grep the source for
"leak" and you'll see them), and are small enough that could very well
account for your problem.  (Yes, yes, lazy programming. ;))

I'll fix these this morning and let you know when I've done so.

Jason.

Re: [Orbit-python-list] Threads?

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

> version?  I've submitted them to Sourceforge in May, and had no
> feedback...  And I'd prefer running an official version rather than my
> own patched one.  I fully understand they might be a bit kludgy, but I
> feel they are really useful.

Hi Roland,

I'm terribly sorry for not getting back to you on those.  I probably saw
them when you posted them, thought, "Oh yes I had better look at that when
I have more time," and totally forgot.  Anyway, I _will_ review your
patches tonight and let you know.

Certainly I don't see a problem with the patch to prevent a client from
modifying a read-only attribute -- it should definitely do that.  It
should send an appropriate exception to the client, however.  I'll make
these changes and merge the patch in.  

The other one I'm not so sure about.  Yes I admit that inserting the POA
in the __main__ dictionary is A Bad Thing (it's a FIXME item for sure).
But I think your patch will result in straying even further away from the
CORBA bindings for Python guidelines, and really, we are only moving from
one kludge to another.  Your way is technically cleaner, but we aren't
realy solving the original problem, plus moving to a version with this
change will require modifying code that uses ORBit-Python.

I'm open for arguments, though.  Do we want the POA as a value in the
caller's dictionary?  Or should it be within the CORBA module?

Jason.

Re: [Orbit-python-list] Threads?

[Roland M. <ma...@ec...>]

Jason Tackaberry (2000-08-02 07:21:46 -0400) :

> Neither ORBit-Python nor ORBit creates threads.

  OK.  I had figured that out by other means, but thanks anyway.  Just
in case it interests anyone: my memory leak was in fact due to my
misuse of the traceback objects, as described in the doc.  Silly me.

  By the way, is there any chance my patches get into the mainstream
version?  I've submitted them to Sourceforge in May, and had no
feedback...  And I'd prefer running an official version rather than my
own patched one.  I fully understand they might be a bit kludgy, but I
feel they are really useful.

Thanks,
Roland.
-- 
Roland Mas

Food, shelter, source code.
  -- Cyclic Software

Re: [Orbit-python-list] Threads?

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

Sorry for not replying to this sooner, Roland.  I missed the email in
my Inbox clutter.

>   So my question is: as of Orbit-0.5.1 and Orbit-Python 0.1.3, is
> there anything generating multiple threads in my back, or should I
> definitely continue to look for the answer in the Popy module?

Neither ORBit-Python nor ORBit creates threads.  ORBit-Python isn't
even thread-safe, and ORBit probably isn't either.  So if you use threads
with ORBit-Python you will have to ensure that ORBit-Python (and thus
ORBit) code only executes in one thread (or never at the same time in
multiple threads).

Regards,
Jason.

Re: [Orbit-python-list] Does not compile from CVS / Debian package?

[Roland M. <ma...@ec...>]

Brad Chapman (2000-08-02 05:50:20 -0400) :

> Automake 1.4, unfortunately, doesn't have support for python, so you'll
> need to apply James Henstridge's patches to automake to make it work, you
> can get them from
> http://cds.duke.edu/pub/sunsite/X11/gtkbuffet/lang/pygtk/pyautomake.tar.gz
> (or another mirror if one is better for you). If you follow the
> instructions in there to patch automake and get the macros in the right
> place, this should clear up these two errors, and hopefully this will let
> ./autogen.sh go through cleanly for you. 

It works.  Thanks!
-- 
Roland Mas

Au royaume des aveugles, les borgnes sont mal vus.

Re: [Orbit-python-list] Does not compile from CVS / Debian package?

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

On 2 Aug 2000, Roland Mas wrote:
>   I got the latest version from the Sourceforge CVS server, and I'm
> wondering how to make it compile.
>   OK, so the INSTALL file says to run ./configure.  This script does
> not exist.  But the INSTALL file also says that this script can be
> generated with autoconf. 

Right, from CVS you need to run the autoconf tools (aclocal, autoconf and
automake) to generate configure from configure.in. But, as you discovered,
the autogen.sh script will do this for you automatically.

>   Hm.  OK, I'll try something else.  There's a ./autogen.sh script.
> Doesn't work either.  Output from a freshly checked-out tree:
> 
> /---- CUT -----
> | roland@minimir:~/perso/src/orbit-python$ ./autogen.sh 
> | I am going to run ./configure with no arguments - if you wish 
> | to pass any to it, please specify them on the ./autogen.sh command line.
> | processing .
> | You should add the contents of `/usr/share/aclocal/libtool.m4' to `aclocal.m4'.
> | 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

Automake 1.4, unfortunately, doesn't have support for python, so you'll
need to apply James Henstridge's patches to automake to make it work, you
can get them from
http://cds.duke.edu/pub/sunsite/X11/gtkbuffet/lang/pygtk/pyautomake.tar.gz
(or another mirror if one is better for you). If you follow the
instructions in there to patch automake and get the macros in the right
place, this should clear up these two errors, and hopefully this will let
./autogen.sh go through cleanly for you. 
	If you still have problems after this, please ask again.

HTH,
Brad

[Orbit-python-list] Does not compile from CVS / Debian package?

[Roland M. <ma...@ec...>]

  Hi there,

  I got the latest version from the Sourceforge CVS server, and I'm
wondering how to make it compile.

  OK, so the INSTALL file says to run ./configure.  This script does
not exist.  But the INSTALL file also says that this script can be
generated with autoconf.  Right, so I run autoconf, it creates the
./configure script.  Here's the output of the script (in a freshly
checked-out tree):

/---- CUT -----
| roland@minimir:~/perso/src/orbit-python$ autoconf 
| roland@minimir:~/perso/src/orbit-python$ ./configure 
| creating cache ./config.cache
| ./configure: line 524: syntax error near unexpected token `AM_INIT_AUTOMAKE(orbit-python,0.1.3)'
| ./configure: line 524: `AM_INIT_AUTOMAKE(orbit-python,0.1.3)'
| roland@minimir:~/perso/src/orbit-python$
\---- CUT ----- 

  Hm.  OK, I'll try something else.  There's a ./autogen.sh script.
Doesn't work either.  Output from a freshly checked-out tree:

/---- CUT -----
| roland@minimir:~/perso/src/orbit-python$ ./autogen.sh 
| I am going to run ./configure with no arguments - if you wish 
| to pass any to it, please specify them on the ./autogen.sh command line.
| processing .
| You should add the contents of `/usr/share/aclocal/libtool.m4' to `aclocal.m4'.
| 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
| automake: configure.in: installing `./install-sh'
| automake: configure.in: installing `./mkinstalldirs'
| automake: configure.in: installing `./missing'
| src/Makefile.am:4: invalid variable `pyexec_PROGRAMS'
| src/Makefile.am:14: invalid unused variable name: `CORBAmodule__SO__LDADD'
| src/Makefile.am:6: invalid unused variable name: `CORBAmodule__SO__SOURCES'
| Running ./configure --enable-maintainer-mode
| creating cache ./config.cache
| ./configure: line 524: syntax error near unexpected token `AM_INIT_AUTOMAKE(orbit-python,0.1.3)'
| ./configure: line 524: `AM_INIT_AUTOMAKE(orbit-python,0.1.3)'
| 
| Now type 'make' to compile orbit-python.
| roland@minimir:~/perso/src/orbit-python$ make
| make: *** No targets specified and no makefile found.  Stop.
| roland@minimir:~/perso/src/orbit-python$
\---- CUT ----- 

  So, it seems to me that either 1. there's something weird in my
Debian system (which I find rather unlikely) or 2. there's a bug or an
error in the files in CVS.  Unfortunately I don't know
autoconf/automake, so I cannot decide which is right.

  Has anyone experienced anything like that?

  Another question: is anyone already working on a Debian packaging of
Orbit-Python?  That's something I'm willing to do, but obviously only
if I can get it to compile.

Roland.
-- 
Roland Mas

Just a little bit of you every day will surely keep the doctors away.
  -- Just a little bit of you (The Jackson Five)

[Orbit-python-list] Threads?

[Roland M. <ma...@ec...>]

Hi there,

I recently ran into a problem using Orbit-Python.  The program also
uses the Popy module to access a PostgreSQL database, and it generates
a big memory leak.  So I spent some time on the Popy mailing list, and
apparently one possible cause of my problem would be that Popy is not
thread-safe.  Since I do not generate multiple threads myself, it was
suggested that maybe the fact that I was using Orbit-Python could be
the cause.

  So my question is: as of Orbit-0.5.1 and Orbit-Python 0.1.3, is
there anything generating multiple threads in my back, or should I
definitely continue to look for the answer in the Popy module?

Thanks in advance,
Roland.
-- 
Roland Mas

How does an octopus go into battle?
Fully-armed.

Re: [Orbit-python-list] ORBit-Python on Windows

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

> I've successfully built and tested ORBit-Python on Windows NT using
> cpplover's preliminary Windows port of ORBit.

This is excellent news!!  I've had a few requests for this but haven't had much
time (or inclination) to try to build it on Windows.

I will integrate this change into the source tree and post a news item about
your accomplishment on the web site.  Please do let me know if you discover
the problem with Linux server <-> Windows client.

Again, many thanks! :)  (And no, it is not old news at all!)

Cheers,
Jason.

[Orbit-python-list] ORBit-Python on Windows

[Dan M. <dm...@dc...>]

I've successfully built and tested ORBit-Python on Windows NT using
cpplover's preliminary Windows port of ORBit.

I've tested the following combinations with the fruit example:

Windows server <-> Windows client (local machine)
Windows server <-> Linux client (via ethernet)

I still haven't gotten a server running on the Linux machine to respond to
requests from a Windows client. (This is likely a problem with ORBit rather
than the Python binding).

My Python is the standard 1.5.2 Windows install. The ORBit port is available
at the main ORBit page, http://www.labs.redhat.com/orbit/. (I fixed a few
minor bugs and recompiled it with gcc before bringing up ORBit-Python;
nevertheless it might simply work out of the box).

I only needed to make one trivial change to ORBit-Python. In marshal.c,
SystemExcept_SubTypes[0] is initialized to a symbol exported from the ORBit
library. On Windows, you can't initialize a variable to a value defined
outside of the executable. To work around this, I changed the compile-time
definition to:

CORBA_TypeCode SystemExcept_SubTypes[] = {
 NULL, &Status_TypeCode
};

and then I simply assign the missing value in initCORBA():

SystemExcept_SubTypes[0] = (CORBA_TypeCode)TC_CORBA_ulong;

Everything else compiled without a single warning! Kudos to Mr. Tackaberry
for this wonderful piece of code.

Dan Maas

(apologies if this is old news =)

[Orbit-python-list] Looking forward to Gnorba

[lexberezhny <lex...@ms...>]

Hi Jason,

>Yes, you will need to hack the code in order to do this, or you can
> wait until I release the yet-to-be-started Gnorba bindings, which I
> will hopefully start working on in a couple of weeks. It shouldn't be
> too difficult to hack the current state of things at least to the point
> where you can start development. Then you can switch over to
> the Gnorba bindings once they're done.

Thanks for all the great work, I will be very eager to see the development
of the Gnorba bindings. And if there is anything I can do to help out please
ask. I am glad to do testing, and some development, although I am still
learning all of the details of python. Anyways, keep up the good work! :-)

 Best of luck!
  - Lex Berezhny

[Orbit-python-list] Submitted patch

[Roland M. <ma...@ec...>]

  Hi all,

  I just submitted a patch on Sourceforge to add server-side checking
of read-only mode when a client attempts to change an attribute.  If
someone could explain me how to raise an exception, I'd be glad to
return one.  For now, the value change request is silently ignored.

Roland.
-- 
Roland Mas

Au royaume des aveugles, il y a des borgnes à ne pas dépasser.
  -- in Soeur Marie-Thérèse des Batignoles (Maëster)

[Orbit-python-list] Recursive Unions

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

Hi Ted,

Sorry for not replying sooner to your email, but I must have missed it in
the clutter.  (I just now ran across it on the list archives.)  Thanks for
the feedback.  I'll have a look at this tonight, but I suspect the problem
might be with libIDL and so it's out of my hands.  I'll let you know.

Cheers,
Jason.

Re: [Orbit-python-list] Hello?

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

> Hello people,

Bonjour Roland. :)

> found about ORBit, and then I found about PyOrbit ant ORBit-Python.  I
> experimented a bit with PyOrbit, but even its authors agree that it is
> "fairly immature at the moment".

I talked with the PyORBit maintainer a while back, and he said he has
very little time to do any active development on the project, and since
ORBit-Python has fulfilled most of their goals, I fear we may not see
much from that project in a little while.

>   So, I switch over to ORBit-Python.  The problem is that at some
> point in my project I will probably have a use for wide chars and
> strings, which are apparently not yet implemented.  The website lists

Wide char/strings aren't the most requested feature to be honest (you're the
first person to request it), so they got put near the end of the priority
list.  Plus, wide types don't map very nicely to Python (like fixed), so they
require a lot more work than say a string or float type.  

> Is the project sort of asleep?  Are these features susceptible to be
> completed at some time in the (reasonably near) future?

I haven't had much time to do any development in the last month, since I
was horribly busy with exams and finishing up last minute assignments and
project (I'm such an awful procrastinator).  Now I'm finished school, and
in the next couple weeks I'll be moving.  Once that's out of my way, I plan
to resume work on ORBit-Python.  I especially want to start the Interface
Repository bindings, and wrap Gnorba so that it's more useful to the GNOME
project.  So, the project certainly isn't dead, at least in intentions. :)

>   Yeah, I know, I can implement them and then send a patch.  Well, I
> may do so.  I haven't used CORBA yet, let alone mingled with the
> bowels of an ORB.  But if I get to understand what it is I have to do,
> and how I can do it, I no doubt will.

I dare say most of the hard stuff has been implemented already -- at least
the tricky infrastructure parts.  Patches are of course happily accepted, but
I'll reevaluate where the wide types belong in my TODO list.  Since no one
has asked for the fixed type, I'll likely at least do the wide types first.

>   But before I dive deep into the ORB, I'd like to know about the
> status of the project.  Dead?  Asleep?  Author holidays?  Merged with
> something else?

It will be asleep for probably two more weeks, until I'm all moved.  That is
to say, I won't be adding any new features.  But I am alive and easily
reachable over email (or on this list) if you have any questions or bug
reports.

Best wishes,
Jason.

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

[Orbit-python-list] Hello?

[Roland M. <ma...@ec...>]

Hello people,

I'm a programmer who plans to use CORBA for my next development.
CORBA means objects, and objects mean Python and not Perl (well, in my
case anyway).  So I looked about a bit to see how I could do it.  I
found about ORBit, and then I found about PyOrbit ant ORBit-Python.  I
experimented a bit with PyOrbit, but even its authors agree that it is
"fairly immature at the moment".

  So, I switch over to ORBit-Python.  The problem is that at some
point in my project I will probably have a use for wide chars and
strings, which are apparently not yet implemented.  The website lists
no recent evolutions, and the mailing-list archives are almost empty.
Is the project sort of asleep?  Are these features susceptible to be
completed at some time in the (reasonably near) future?

  Yeah, I know, I can implement them and then send a patch.  Well, I
may do so.  I haven't used CORBA yet, let alone mingled with the
bowels of an ORB.  But if I get to understand what it is I have to do,
and how I can do it, I no doubt will.

  But before I dive deep into the ORB, I'd like to know about the
status of the project.  Dead?  Asleep?  Author holidays?  Merged with
something else?

  Thanks for any info,

Roland.
-- 
Roland Mas

Plant a radish, get a radish, never any doubt!
  -- Bellamy & Hucklebee, in The Fantasticks

[Orbit-python-list] recursive unions

[Ted H. <Ted...@wd...>]

Hi,

I just started looking at orbit-python and ran into a problem with  
recursive unions.  When I call CORBA.load_idl with a recursive union, it  
goes into infinite recursion and blows the stack.  Recursive structs don't  
seem to have this problem.  Has anyone run into this before ?  Any hints on  
how to fix it ?

Here is some sample idl:

module Recurse {
	enum UT {one, two};
	union RU switch (UT) {
		case one:
			string name;
		case two:
			sequence <RU> children;
	};
};

Thanks,

-----------------------------
Ted Horst <Ted...@wd...>

[Orbit-python-list] ORBit-Python Report

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

As most of you know, ORBit-Python was a project picked for my undergrad
thesis.  As a component of the thesis, I have to submit a report
documenting the project, including background and implementation.  So
my report gives background on CORBA, Python, and OSS, and I go into
some gory details about ORBit-Python internals.

It's available on the project website (projects.sault.org/orbit-python)
for your perusal if you feel so inclined.  If there are any serious
blunders, please let me know.  It won't help me get a better mark, but
it will help me save face with future readers. :)

Jason.

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

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

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

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

I think this argument is about as good as it gets.  ORBit-Python now promotes
ints to floats as well.

Thanks for the discussion,
Jason.

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