orbit-python-list

[Fwd: Re: [Orbit-python-list] Orbit-python and threading?]

[Johan D. <jd...@te...>]

doh, i forgot to send a copy to the list

tor 2001-11-08 klockan 16.09 skrev Marijn Vriens:
> On Thu, Nov 08, 2001 at 09:13:29AM -0200, Christian Robottom Reis wrote:
> > On Thu, 8 Nov 2001, Marijn Vriens wrote:
> 
> > There might have been implemented some sort of mainiteration() method in
> > ORBit by now (we're at 0.5.12!), but at the time there was none and this
> > was a real solution to a complicated problem.
> 
> Yes, i am surprised that there's not.. Orbit has a (degree of) stable
> feeling to it, and this is like the second-thing (after pure RPC) that
> people would need, I think..
> 
> > You won't be actually using gtk at all, and there is little effect on your
> > program beyond it working. Well, come to think of it, you will need the
> > libs, and X11 running and... :-) Well, in my case it was convenient, at
> > least.
> 
> Exactly! This is my problem with the GTK solution. I cannot tell now,
> if the computers where my program will run on will have all this stuff
> installed, I want to avoid dependency bloat if I can. 
> 
> Maybe some idea would be to copy/implement the same functionality as
> gtk.mainloop(), and let the user decide which of both he/she wants to
> use. And when the Orbit people get their stuff together you just
> convert this orb.mainloop() (to give the beast some name) to just pure
> C calls.  
> 
> Again, I have to say that I have no idea how much work is involved
> with what I am suggesting :) But that would seem like the "best"
> non-dep-bloat solution.
> 
Well if you consider Gtk+ bloat, don't use it.

Take a look at oaf, they're using the glib mainloop (same as gtk+ are
using).

So you don't really need gtk+ for this, but it's easier to require gtk+,
so you can use something like the file i just attached.

> > > Maybe I am looking at this from the wrong side... What I want Corba
> > > for is to provide me with a nice way to give RPC calls for some
> > > simulation clients. That Sim server should update it's data according
> > > to 2 things:
> > > - Events from clients (via Corba).
> > > - Time passing.
> > 
> > Why not create a time-ticking client that triggers a call to the server? I
> > know it's not magic, but it will work.
> > 
> 
> > > - Fork() off a process that does the updating and communicates
> > > changes via shared-memory or something like that.
> > > - Fork() off a process that just calls some "update()" method on a
> > > special interface once in a time period, to make the process do the
> > > processing for the time that has passed.
> > 
> > Well... I hate both of these. Do you need a forked process, or can you
> > spawn one together with the server?
> 
> Ehhh.. of course! Where was my head? I can make the server exec an
> extra program ( itself? With some different argv[] ) that does a
> update() once in a while.. Not so very horrible. And at least, it
> "invisible" for the end-user. Still not the cleanest solution but it
> will work.
> 
> Thanks for the Help, It's much appreciated..
> 
>        Marijn.
> 
> -- 
> Get loaded from the source: Do Linux!
> Marijn Vriens <ma...@me...> 
> GPG/PGP: 6895 DF03 73E1 F671 C61D  45F4 5E83 8571 C529 5C15

----


# glib.py
#
# This isn't a a glib wrapper, it's more useful non-ui functions
# stolen from gtk

import _gtk

TRUE = 1
FALSE = 0

def mainloop ():
    _gtk.gtk_main ()

def mainquit (*args):
    _gtk.gtk_main_quit ()

def mainiteration (block=TRUE):
    return _gtk.gtk_main_iteration (block)

def events_pending ():
    return _gtk.gtk_events_pending ()
				
def idle_add (callback, *args):
            return _gtk.gtk_idle_add (callback, args)
	
def idle_add_priority (priority, callback):
    return _gtk.gtk_idle_add_priority (priority, callback)

def idle_remove (tag):
    _gtk.gtk_idle_remove (tag)

def quit_add (mainlevel, callback, *args):
    return _gtk.gtk_quit_add (mainlevel, callback, args)

def quit_add_destroy (mainlevel, object):
    _gtk.gtk_quit_add_destroy (mainlevel, object._o)

def quit_remove (tag):
    _gtk.gtk_quit_remove (tag)
    
def timeout_add (timeout, callback, *args):
    return _gtk.gtk_timeout_add (timeout, callback, args)

def timeout_remove (tag):
    _gtk.gtk_timeout_remove (tag)

def input_add (source, condition, callback):
    if hasattr (source, 'fileno'):
	# handle python file handles
	def wrapper (source, condition, real_s=source,real_cb=callback):
	    real_cb (real_s, condition)
	    return _gtk.gtk_input_add (source.fileno (), condition, wrapper)
    else:
	return _gtk.gtk_input_add (source, condition, callback)
	
def input_remove (tag):
    _gtk.gtk_input_remove (tag)
	    

Re: [Orbit-python-list] Orbit-python and threading?

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

> Perhaps it's a bit rude to suggest it on this mailing list, but you
> could always consider using one of the multi-threaded Python ORBs
> instead of ORBit-Python.

It's not rude at all.  omniORBpy is a great ORB, and one must use what
gets the job done.

Marijn: the issue will be addressed soon, either in 0.4.0 or in the
orbit2 port.  But if you need the functionality now, then obviously you
should use what works. :)

Regards,
Jason.

Re: [Orbit-python-list] Orbit-python and threading?

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

On Wednesday 7 November, Marijn Vriens wrote:

> I am trying to get some program to work with python-orbit. Because I
> need it to do some more work besides just waiting for corba requests
> to come in, and i didn't see any "idle" hooks (ala gtk.py), My
> solution is to dump the Orbit run() in it's own thread, while the
> rest of the processing goes on in the mainthread.
[...]

Perhaps it's a bit rude to suggest it on this mailing list, but you
could always consider using one of the multi-threaded Python ORBs
instead of ORBit-Python.

Cheers,

Duncan.

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

Re: [Orbit-python-list] Orbit-python and threading?

[Marijn V. <ma...@me...>]

On Thu, Nov 08, 2001 at 09:13:29AM -0200, Christian Robottom Reis wrote:
> On Thu, 8 Nov 2001, Marijn Vriens wrote:

> There might have been implemented some sort of mainiteration() method in
> ORBit by now (we're at 0.5.12!), but at the time there was none and this
> was a real solution to a complicated problem.

Yes, i am surprised that there's not.. Orbit has a (degree of) stable
feeling to it, and this is like the second-thing (after pure RPC) that
people would need, I think..

> You won't be actually using gtk at all, and there is little effect on your
> program beyond it working. Well, come to think of it, you will need the
> libs, and X11 running and... :-) Well, in my case it was convenient, at
> least.

Exactly! This is my problem with the GTK solution. I cannot tell now,
if the computers where my program will run on will have all this stuff
installed, I want to avoid dependency bloat if I can.=20

Maybe some idea would be to copy/implement the same functionality as
gtk.mainloop(), and let the user decide which of both he/she wants to
use. And when the Orbit people get their stuff together you just
convert this orb.mainloop() (to give the beast some name) to just pure
C calls. =20

Again, I have to say that I have no idea how much work is involved
with what I am suggesting :) But that would seem like the "best"
non-dep-bloat solution.

> > Maybe I am looking at this from the wrong side... What I want Corba
> > for is to provide me with a nice way to give RPC calls for some
> > simulation clients. That Sim server should update it's data according
> > to 2 things:
> > - Events from clients (via Corba).
> > - Time passing.
>=20
> Why not create a time-ticking client that triggers a call to the server? I
> know it's not magic, but it will work.
>=20

> > - Fork() off a process that does the updating and communicates
> > changes via shared-memory or something like that.
> > - Fork() off a process that just calls some "update()" method on a
> > special interface once in a time period, to make the process do the
> > processing for the time that has passed.
>=20
> Well... I hate both of these. Do you need a forked process, or can you
> spawn one together with the server?

Ehhh.. of course! Where was my head? I can make the server exec an
extra program ( itself? With some different argv[] ) that does a
update() once in a while.. Not so very horrible. And at least, it
"invisible" for the end-user. Still not the cleanest solution but it
will work.

Thanks for the Help, It's much appreciated..

       Marijn.

--=20
Get loaded from the source: Do Linux!
Marijn Vriens <ma...@me...>=20
GPG/PGP: 6895 DF03 73E1 F671 C61D  45F4 5E83 8571 C529 5C15

Re: [Orbit-python-list] Orbit-python and threading?

[Christian R. R. <ki...@as...>]

On Thu, 8 Nov 2001, Marijn Vriens wrote:

> Solutions for my problem that I can think of:
> - Very simple event hooks (on time, intervals, idle or something) in
> the orb.run() loop. o-p doesn't seem to provide it. Adopting GTK+ for
> this functions, is taking on too much extra stuff, for such a small
> feature (thou the *possible* integration of the loops is great if you
> are building a server with a GTK+ interface.)

ORBit-0.5.12 does not support this yet (orb.c):

/* Section 4.9.1 */
CORBA_boolean CORBA_ORB_work_pending(CORBA_ORB orb, CORBA_Environment *ev)
{
    g_assert(!"Not yet implemented");
    return(CORBA_FALSE);
}

/* Section 4.9.2 */
void CORBA_ORB_perform_work(CORBA_ORB orb, CORBA_Environment *ev)
{
    g_assert(!"Not yet implemented");
    return;
}

Which rules this out unless you want to use the gtk mainloop?

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL

Re: [Orbit-python-list] Orbit-python and threading?

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

On Wed, 2001-11-07 at 15:35, Christian Robottom Reis wrote:
> Okay. This is a feature that we have been desiring for a while now, and if
> Tack thinks it's okay, i'd like to do a 0.3.2 pre-version that includes

Well this is certainly something for 0.4.0, and not 0.3.x.  My first
instinct was to reject this approach and say I'd much rather do it a
less kludgey way (that is, make o-p thread-safe).  Now that I think of
it, I think that the orbit2 port Johan is working on is really the way
to go with this one, because orbit2 is (purportedly) thread-safe.

I suspect that 0.5.0 may not work out as I planned in the road map I
posted a few months ago.  I think I may focus on standards compliance
for 0.4.0, since stability is nearly there now, and after that maybe
help Johan with the orbit2 port.

That said, I still maintain your patch is something for 0.4.0 and not
0.3.2, so we'll look at that more closely when the time comes.

> I'm surprised your threading example doesn't crash, but I don't know
> threading very well at all. Tack? :)

It doesn't crash because orbit-python has the global interpreter lock
before it calls ORB.run(), so essentially all the other threads get
suspended.  (Specifically, they're waiting for the interpreter lock to
be released.)

Jason.

Re: [Orbit-python-list] Orbit-python and threading?

[Christian R. R. <ki...@as...>]

On Wed, 7 Nov 2001, Marijn Vriens wrote:

> I am trying to get some program to work with python-orbit. Because I
> need it to do some more work besides just waiting for corba requests
> to come in, and i didn't see any "idle" hooks (ala gtk.py), My
> solution is to dump the Orbit run() in it's own thread, while the
> rest of the processing goes on in the mainthread.

I've attached a patch to o-p from cvs that does the threading changes.
You'll need pygtk compiled without threads (or from CVS with
PYGTK_NO_THREADS env var set). You should initialize the orb using
something like:

orb = CORBA.ORB_init( [], CORBA.ORB_ID, CORBA.TRUE )

(the third parameter says you want to use the gtk mainloop.

Then just substitute the orb.run() call for gtk.mainloop(). It should
work.

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL

Re: [Orbit-python-list] Orbit-python and threading?

[Christian R. R. <ki...@as...>]

On Wed, 7 Nov 2001, Marijn Vriens wrote:

> I am trying to get some program to work with python-orbit. Because I
> need it to do some more work besides just waiting for corba requests
> to come in, and i didn't see any "idle" hooks (ala gtk.py), My
> solution is to dump the Orbit run() in it's own thread, while the
> rest of the processing goes on in the mainthread.

Okay. This is a feature that we have been desiring for a while now, and if
Tack thinks it's okay, i'd like to do a 0.3.2 pre-version that includes
the ability to use the gtk mainloop. This does mean it's necessary to have
pygtk installed and it requires a version of pygtk compiled without
threads (or the latest pygtk with my patch to disable threading in
runtime) but it does work.

> Anyway, a strange thing happens, when I do that orb.run() the
> application blocks (surprise!) nomatter that it's running in it's own
> thread. If I replace the orb.run() with something like

This is by design. Even noticed how pygtk blocks when you gtk.mainloop()?
It's the same sort of idea. The server runs in a mainloop and in theory it
is intended to only service user requests. If you do want to do
client-side processing (have the server initiate actions/requests) then
you will either need threads (which we don't support right now) or the gtk
mainloop hack.

I'm surprised your threading example doesn't crash, but I don't know
threading very well at all. Tack? :)

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL

[Orbit-python-list] Orbit-python and threading?

[Marijn V. <ma...@me...>]

Dear listers,

I am trying to get some program to work with python-orbit. Because I
need it to do some more work besides just waiting for corba requests
to come in, and i didn't see any "idle" hooks (ala gtk.py), My
solution is to dump the Orbit run() in it's own thread, while the
rest of the processing goes on in the mainthread.=20

Anyway, a strange thing happens, when I do that orb.run() the
application blocks (surprise!) nomatter that it's running in it's own
thread. If I replace the orb.run() with something like
time.sleep(largenumber) the threading works as expected.  I don't
really know what the cause of this is, or what to do about it. Any help
would be greatly apriciated.

What am I doing that i shouldn't? And if i can't mix orb.run() with
threads, how do i do some processing while orb.run() is just blocking
waiting for requests?=20

I included the most relevant source snippit, maybe i am doing
something very wrong, somehow...

Regrads,
	Marijn.
=20
--- Here's the code that does the threading:
"sim" and "user" are two objects that hold the data the server has to
work with and "lock" is a global lock so that the implementation class
won't read/write to the data structures when an update of that data is
going on.


import CORBA, SimServer, SimServer__POA

from threading import *
import time

class SimServer:
    def __init__(self, sim, user, lock):
        self._thread =3D Thread(target=3Dself.run, name=3D"Orbit")
        argv =3D []
	argv.append('ORBIIOPIPv4=3D1')
	self.orb =3D CORBA.ORB_init(argv)
	self.poa =3D self.orb.resolve_initial_references("RootPOA")
	ref =3D SimServer_Sim_Impl(sim, user, lock)._this()
	open("server.ior", "w").write(self.orb.object_to_string(ref))
        self.poa.the_POAManager.activate()
#        self._thread.setDaemon(1)
        print "pre thread start"
        self._thread.start()
        print "post thread start"
    def run(self):
        print "orb run"
        print enumerate()
#       time.sleep(500)
        self.orb.run()
        print "orb end"



--=20
Get loaded from the source: Do Linux!
Marijn Vriens <ma...@me...>=20
GPG/PGP: 6895 DF03 73E1 F671 C61D  45F4 5E83 8571 C529 5C15

Re: [Orbit-python-list] Spec non-compliance re structures

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

On Monday 29 October, Chip Richards wrote:

>        struct segment
>        {
>          long left_limit;
>          long right_limit;
>        };

[...]
> The form of the constructor I've been using that does seem to work is this:
> 
>    s = StruckIF.segment (left_limit=-3, right_limit=7)
> 
> Now, I'm a big fan of keyword parameters, but there are times when
> I'd be just as happy using positionals.

In fact, the mapping spec _only_ requires the constructor using
positional arguments, so an application using keyword arguments is
non-portable. The keyword form should be considered an extension.
omniORBpy supports keyword arguments, but I think I remember that
Fnorb does not.

Cheers,

Duncan.

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

[Orbit-python-list] Spec non-compliance re structures

[Chip R. <ch...@ni...>]

I had discovered this a couple of days ago, but didn't realize that spec
compliance was of current interest.  This is similar to the issue I found with
unions; from section 1.3.4 of the mapping spec, I made this IDL:

   module Struck
   {
     interface StruckIF
     {
       struct segment
       {
         long left_limit;
         long right_limit;
       };
     };
   };

And with it, this code:

   #! /usr/bin/env python

   import CORBA
   from   Struck import StruckIF

   s = StruckIF.segment (-3, 7)
   print s.left_limit, s.right_limit

When run, that combination gives this error:

   Traceback (innermost last):
     File "./struck-client", line 7, in ?
       print s.left_limit, s.right_limit
   AttributeError: left_limit

The form of the constructor I've been using that does seem to work is this:

   s = StruckIF.segment (left_limit=-3, right_limit=7)

Now, I'm a big fan of keyword parameters, but there are times when I'd be just
as happy using positionals.

I hope this helps.

-- 
Chip

[Orbit-python-list] Spec non-compliance re unions

[Chip R. <ch...@ni...>]

Tack requested that I send details about comments I made on IRC, so here they
are.

Copying the union example in the spec (v1.0, dated February 2001), section
1.3.5, I created this IDL:

   module Onion
   {
     interface OnionIF
     {
       union MyUnion switch (long)
       {
       case 1:   string  s;
       default:  long    x;
       };
     };
   };

To test it, I copied the Python code in the same section of the spec, giving
this:

   #! /usr/bin/env python

   import CORBA
   from   Onion import OnionIF

   u = OnionIF.MyUnion (17, 42)
   print u.x
   u = OnionIF.MyUnion (s = 'string')
   print u._d, u._v

(As an aside, I know of no way with o-p to code simply "MyUnion", because
"OnionIF" is not a valid import source.  Is this just not possible, or am I
missing something?  I probably wouldn't code it that way anyway, but was
just curious.)

When run, using o-p 0.3.0, that returns this error message:

   Traceback (innermost last):
     File "./onion-clnt", line 7, in ?
       print u.x
   AttributeError: x

Commenting out the first "print" and running again gives this:

   Traceback (innermost last):
     File "./onion-clnt", line 8, in ?
       u = OnionIF.MyUnion (s = 'string')
   TypeError: this function takes no keyword arguments

What actually works is this code:

   #! /usr/bin/env python

   import CORBA
   from   Onion import OnionIF

   u = OnionIF.MyUnion (17, 42)
   print u.v
   u = OnionIF.MyUnion (1, 'string')
   print u.d, u.v

Which prints this:

   42
   1 string

Which is the form I'm currently using in my application.  Earlier, I had found
a similar situation related to structures, which I'll describe in a subsequent
message.

-- 
Chip

Re: [Orbit-python-list] ORBit-Python 0.3.1 RC2 available

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

> http://www.async.com.br/~kiko/orbit-python-0.3.1-RC3.tar.gz
> (it has a rather broken test-suite but ignore that for now -- just see if
> the packaging is okay.)

While compiling, I get this error with RC3:

[tack@viper orbit-python-0.3.1]$ make
Making all in src
make[1]: Entering directory `/home/tack/src/orbit-python-0.3.1/src'
source='CORBAmodule.c' object='CORBAmodule.o' libtool=no \
depfile='.deps/CORBAmodule.Po' tmpdepfile='.deps/CORBAmodule.TPo' \
depmode=none /bin/sh ../depcomp \
gcc -DPACKAGE=\"orbit-python\" -DVERSION=\"0.3.1\" -DHAVE_DLFCN_H=1  -I.
-I. -I/usr/include/python2.1 -I/usr/include/python2.1 -fPIC -g -O2 -Wall
-Wstrict-prototypes -I/usr/include/glib-1.2 -I/usr/lib/glib/include
-I/usr/include    -g -O2 -c `test -f CORBAmodule.c || echo
'./'`CORBAmodule.c
../depcomp: ../depcomp: No such file or directory
make[1]: *** [CORBAmodule.o] Error 127
make[1]: Leaving directory `/home/tack/src/orbit-python-0.3.1/src'
make: *** [all-recursive] Error 1

Looks like the automake you used wants depcomp to exist in the top dir?


Jason.

Re: [Orbit-python-list] ORBit-Python 0.3.1 RC2 available

[Christian R. R. <ki...@as...>]

On 12 Oct 2001, Jason Tackaberry wrote:

>         * remove test-suite/old

From CVS too?

>         * tarball should expand to directory orbit-python-0.3.1

Fixed.

>         * You forgot to run autogen.sh after updating configure.in, so
>           configure in the dist tarball is incorrect.

Fixed. I copied depcomp from an old copy, too.

>         * Make sure the configure that you generate knows how to expand
>           @PYTHON_VERSION@ (since the one that was there didn't -- see
>           orbit-python.spec after running configure to see what I
>           mean).  I use automake 1.4f.

Duh.

> Don't bother announcing an RC3 for these changes, but let the gang in
> #orbit-python test it out.

http://www.async.com.br/~kiko/orbit-python-0.3.1-RC3.tar.gz
(it has a rather broken test-suite but ignore that for now -- just see if
the packaging is okay.)

The del(sys.modules) problem I'll push off to 0.3.2.

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL

Re: [Orbit-python-list] ORBit-Python 0.3.1 RC2 available

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

> - New improved StressSuite with beautiful (ouch) output

Yes kiko, the new UI is very nice indeed!  Good work. :)  (I tested it
with a leak and it looks cool.)

A few more things:

        * remove test-suite/old
        * tarball should expand to directory orbit-python-0.3.1
        * You forgot to run autogen.sh after updating configure.in, so
          configure in the dist tarball is incorrect.
        * Make sure the configure that you generate knows how to expand
          @PYTHON_VERSION@ (since the one that was there didn't -- see
          orbit-python.spec after running configure to see what I
          mean).  I use automake 1.4f.

Don't bother announcing an RC3 for these changes, but let the gang in
#orbit-python test it out.

Jason.

[Orbit-python-list] ORBit-Python 0.3.1 RC2 available

[Christian R. R. <ki...@as...>]

Hello there,

we've hacked out the rest of the known issues and RC2 is now available.
Grab it from http://www.async.com.br/~kiko/orbit-python-0.3.1-RC2.tar.gz

Please bang bang bang till you can find no more outstanding issues.
Crashes with simple fixes will block release, issues beyond that probably
not.

New in RC2:
- New improved StressSuite with beautiful (ouch) output
- Fix for __import__.__doc__ crash
- Fix for CORBA_double truncation problems when marshalling
- Fix for crash with CORBA_Any accessors

That's it. Help us out! Thanks!

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL

Re: [Orbit-python-list] Possible bug in double-precision floating-point marshalling

[Christian R. R. <ki...@as...>]

On Thu, 11 Oct 2001, Chip Richards wrote:

> out of orbit-python servers.  I have short demo code, in case anyone wants to
> see it in action.  I first discovered it when trying to pass back a Python
> "time.time ()" value, which takes a bit more than "float" precision to
> represent accurately.

I want the demo code to integrate into the suite; can I have it? :-)

> I believe it should look more like this, using CORBA_double as a cast:
>
>                 v = (CORBA_double)PyFloat_AsDouble(arg);

Fixed locally, will commit with import __doc__ patch. Thanks.

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL

Re: [Orbit-python-list] Possible bug in double-precision floating-point marshalling

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

> In marshal.c, version 0.3.0, line 465 (in marshal_double) looks like this:
> 
>                 v = (CORBA_float)PyFloat_AsDouble(arg);
> 
> I believe it should look more like this, using CORBA_double as a cast:
> 
>                 v = (CORBA_double)PyFloat_AsDouble(arg);

This looks good, Chip, and it will be included for 0.3.1.  Thanks for
the correction.

Jason

Re: [Orbit-python-list] [patch] segmentation fault with __import__.__doc__

[Christian R. R. <ki...@as...>]

On Thu, 11 Oct 2001, Christian Robottom Reis wrote:

> [ To anybody wondering about 0.3.2, I'd really like to ship it wth no

Make that 0.3.1. I've dropped the crack pipe now, sorry.

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL

[Orbit-python-list] Possible bug in double-precision floating-point marshalling

[Chip R. <ch...@ni...>]

I've mentioned this briefly on the orbit-python IRC channel, and I believe I
have now discovered the source of the problem.

What I'm seeing is double-precision floating-point numbers (CORBA "double")
are being crammed into single-precision floating-point containers on their way
out of orbit-python servers.  I have short demo code, in case anyone wants to
see it in action.  I first discovered it when trying to pass back a Python
"time.time ()" value, which takes a bit more than "float" precision to
represent accurately.

After building C versions of my test client and server (which made me glad I'm
using Python for my real app!), I determined that the problem was in the o-p
*server* code, which allowed me to look closer at the marshal_double function
in marshal.c and finally see what I think is the error.

Sorry this isn't in the form of a patch against the latest CVS source, but
it's short and simple enough that it shouldn't be any trouble for a person
with CVS access to apply.

In marshal.c, version 0.3.0, line 465 (in marshal_double) looks like this:

                v = (CORBA_float)PyFloat_AsDouble(arg);

I believe it should look more like this, using CORBA_double as a cast:

                v = (CORBA_double)PyFloat_AsDouble(arg);

If I am mistaken about this, I apologize for wasting everyone's time.

-- 
Chip

[Orbit-python-list] [patch] segmentation fault with __import__.__doc__

[Christian R. R. <ki...@as...>]

Tack,

The attached patch solves a SEGV which occurs when python code refers to
__import__.__doc__ after importing CORBA. The patch looks up the default
docstring for __import__, copies it and attaches it to our new handler.

The alternative implementation is simply setting the docstring to "". But
in our case, I think it's worth preserving the original message, since it
doesn't cost us anything.

[ To anybody wondering about 0.3.2, I'd really like to ship it wth no
known SEGVs. If you know of any case, please report and I'll do an
expedited fix. Brad, your patch is integrated into CVS, thanks. ]

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL

Re: [Orbit-python-list] IDLPATH handling

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

> Ok. Sounds reasonable. Issue closed WONTFIX.

No no, I said was open to arguments.  Unless I was so convincing as to
have changed your mind. :)  I mean, if Michael thinks the current
behaviour is wrong I'd like to know his rationale is. :)

Jason.

Re: [Orbit-python-list] [bug] _narrow() SEGVs

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

> Fix attached, r= somebody please? This is targetted for 0.3.2.

Or possibly 0.3.1, since we haven't released it yet.

Instead of using an int as a boolean, use CORBA_boolean (and
CORBA_FALSE/CORBA_TRUE as values) since that's what I've been using
elsewhere in the code.  I think it would make more sense to use gboolean
(and only use CORBA_boolean as parameters for ORBit's functions), but
it's probably better to stay consistent.  Maybe we'll change the
CORBA_booleans that should be gbooleans in cvs after the release.

The other thing I'd like changed is the comment where it says "when
activating we steal ..." since this isn't exactly correct.  'course
that's my fault since it's my comment, but the patch might as well fix
that. :)

Jason.

Re: [Orbit-python-list] IDLPATH handling

[Christian R. R. <ki...@as...>]

On 10 Oct 2001, Jason Tackaberry wrote:

> is to set an IDLPATH without this path in the variable.  If we prepended
> certain paths as you suggest then we'd have to provide another way for
> the user to accomplish this.  I think it has the potential to be one of
> those hair-pulling subtleties that we should avoid.

Ok. Sounds reasonable. Issue closed WONTFIX.

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL

Re: [Orbit-python-list] IDLPATH handling

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

On Tue, 2001-10-09 at 01:43, Christian Robottom Reis wrote:
> 
> If IDLPATH is set, what should ORBit-Python's default behaviour be? Should
> it override the default search path ( /usr/local/share/idl and
> /usr/share/idl and . ) and simply use the user-supplied IDLPATH or should
> it prepend?
> 
> ATM it overrides, which causes me serious trouble. I would like to change
> the behaviour, but I don't know if it violates the spec or Tack's
> intention. Please let me know!

There is no spec on this matter, so we can basically do what we want. 
IDLPATH is an O-P invention.

I'm not sure why you'd want it to prepend, so you'll have to argue your
case.  The way I see it, if IDLPATH is set, O-P should use that as it
is, and not monkey with it.  I don't think it should prepend what the
user wants with arbitrary values.  For example, the user simply may not
want o-p to look in /usr/local/share/idl, and the way he does this now
is to set an IDLPATH without this path in the variable.  If we prepended
certain paths as you suggest then we'd have to provide another way for
the user to accomplish this.  I think it has the potential to be one of
those hair-pulling subtleties that we should avoid.

But I'm open to arguments, of course. :)

Jason.