orbit-python-list

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

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

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

Are there other known SEGVs known to people on the list with current CVS
beyond Brad's Any problem?

On 10 Oct 2001, Jason Tackaberry wrote:

> > To be called twice upon the same object. My reasoning is probably
> > incomplete, but I think when we _narrow, since we are merely changing the
> > way a CORBA Object is presented, the object should not be released.
>
> Not exactly.  _narrow() will return a new CORBA_PyObject instance.  So,
> it's possible for more than one CORBA_PyObject to represent a single
> CORBA Object.  Let me read the code and see if I can track down the bug.


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

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

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

> To be called twice upon the same object. My reasoning is probably
> incomplete, but I think when we _narrow, since we are merely changing the
> way a CORBA Object is presented, the object should not be released.

Not exactly.  _narrow() will return a new CORBA_PyObject instance.  So,
it's possible for more than one CORBA_PyObject to represent a single
CORBA Object.  Let me read the code and see if I can track down the bug.

Jason.

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

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

Tack,

The current codebase causes a SEGV when we call _narrow() on an object
twice. This happens because we are causing  

CORBA_Object_release(object, &inst_glue->ev);

To be called twice upon the same object. My reasoning is probably
incomplete, but I think when we _narrow, since we are merely changing the
way a CORBA Object is presented, the object should not be released.

If I am correct, what appoach should I take? How can
CORBA_Object_to_PyObject_with_type be modified to handle this extra
situation without causing problems when we legitimately need to release
the Object?

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

Re: [Orbit-python-list] Re: Problem with parsing of recursive structs in IDL

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

Christian:
> Summary: I want more SEGVs!

All right, if you insist. :-)

> I received your Any() patch for ORBit-Python, but since my refcounting
> skills are a drag, I would like to ask you for a favor. If you could send
> me a minimal testcase or a suggestion of one that triggers the problem, I
> can gdb through and understand what is happening? Deal?

Sure, attached is a test that should cause either segfaults (does
this on linux mandrake) or lots of memory errors about free() 
(on NetBSD). The patch I sent makes this simple test run smoothly.
Let me know if you need more.

Brad
-- 
PGP public key available from http://pgp.mit.edu/

Re: [Orbit-python-list] Re: Problem with parsing of recursive structs in IDL

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

On Tue, 4 Sep 2001, Christian Robottom Reis wrote:

> It's exactly what I want. Test scripts that SEGV are the latest fashion in
> ORBit-Python; I've just discovered another three last week with using
> __import__() after an import CORBA. That's fun.

Summary: I want more SEGVs!

I received your Any() patch for ORBit-Python, but since my refcounting
skills are a drag, I would like to ask you for a favor. If you could send
me a minimal testcase or a suggestion of one that triggers the problem, I
can gdb through and understand what is happening? Deal?

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

[Orbit-python-list] IDLPATH handling

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

I have a question and have already cooked up the two-liner for an answer.
Question is:

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!

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

[Orbit-python-list] [patch] PYGTK_NO_THREADS patch

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

this is not my day

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

[Orbit-python-list] [patch] PYGTK_NO_THREADS patch

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

Hi James,

The attached patch adds a check for the environment variable
PYGTK_NO_THREADS and disables threading in runtime if it is set. This is a
very important patch to the orbit-python team because it will allow us to
run clients that are also CORBA servers and thus can service requests.

With this patch and Johan's ORBit-Python patch we can actually run the
echo test server with gtk.mainloop and have it work perfectly.

James, if you would rather have a bug created for this, just answer or
/topic on IRC. 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] Release program for 0.3.1

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

On 7 Oct 2001, Jason Tackaberry wrote:

> > <zilch> CORBA.ORB_init (sys.argv[], CORBA.ORB_ID, CORBA.TRUE)
>
> Actually as long as the third argument is optional (and it is), then
> it's fine.  We "bend" the spec all over the place in order to provide
> enhancements.  As long as spec-compliant programs work the way they
> should with o-p then it's fine.

If it's not already a problem, I think this could be "bad" if in the
future OMG decides to add a third parameter. I think parameter lists are
the type of thing that can be changed in a standard a lot, specially in
python where we can have optional arguments.

So I'm proposing :-) that we use something like

"from CORBA import use_gtk_mainloop"

Or perhaps something like CORBA._use_gtk_mainloop = 1

Tack, you had a proposal for non-standard extensions. How would they work?

> This stuff isn't suitable for 0.3.x, but maybe 0.4.x, since it's the
> first step to making o-p usable with threads.

Uhm, well I should point out this has nothing to do with threads -
actually, the whole problem is working around threads in pygtk. If we had
thread support no pygtk modifications would be necessary.

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

Re: [Orbit-python-list] Release program for 0.3.1

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

> Have to be careful on this mailing list or next time i'll joke about
> adding mail and news to o-p and Johan will do it (and what next, window

Well then Johan would just steal the code from Mozilla, like he did here
with oaf. :)

> <kiko> but how does the mainloop get there?
> <zilch> CORBA.ORB_init (sys.argv[], CORBA.ORB_ID, CORBA.TRUE)
> <zilch> probably breaks the spec, but who cares? :)

Ha! :)

Actually as long as the third argument is optional (and it is), then
it's fine.  We "bend" the spec all over the place in order to provide
enhancements.  As long as spec-compliant programs work the way they
should with o-p then it's fine.

> Ok, so Tack will never accept this. The best we can hope for is asking him
> for an opinion on the API change that could offer this (optional)
> enhancement to O-P. Tack?

I'll accept it when we don't need to call CORBA_ORB_run() anymore,
because otherwise I fail to see what this is going to buy us.  What
enhancement is this patch really giving us?

This stuff isn't suitable for 0.3.x, but maybe 0.4.x, since it's the
first step to making o-p usable with threads.

Jason.

Re: [Orbit-python-list] Release program for 0.3.1

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

On 7 Oct 2001, Johan Dahlin wrote:

> > So, Johan, are you up for it? That would be a nice 0.3.2 feature ;)
> >
> ok

Have to be careful on this mailing list or next time i'll joke about
adding mail and news to o-p and Johan will do it (and what next, window
management?). I have a comment on this and i'd like a general opinion.
First a quote from irc:

<kiko> but how does the mainloop get there?
<zilch> CORBA.ORB_init (sys.argv[], CORBA.ORB_ID, CORBA.TRUE)
<zilch> probably breaks the spec, but who cares? :)

+
+	if (!PyArg_ParseTuple(args, "|Osi", &orb_args, &id, &glib_mainloop))
 		return NULL;

 	if (!id)
 		id = "orbit-local-orb";
-
+
+	if (glib_mainloop) {
+		IIOPAddConnectionHandler = orb_add_connection;
+		IIOPRemoveConnectionHandler = orb_remove_connection;
+	}
+
 	if (orb_args) {
 		if (PyList_Check(orb_args)) {
 			orb_args = PyList_AsTuple(orb_args);

Ok, so Tack will never accept this. The best we can hope for is asking him
for an opinion on the API change that could offer this (optional)
enhancement to O-P. Tack?

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

Re: [Orbit-python-list] Release program for 0.3.1

[Johan D. <zil...@ho...>]

s=F6n 2001-10-07 klockan 08.10 skrev Christian Robottom Reis:
> On 6 Oct 2001, Jason Tackaberry wrote:
>=20
> > Yeah, current cvs is pretty stable.  0.3.1 is just a bugfix release.
> > There are more bugs to be fixed, of course, but there's nothing stoppin=
g
> > us from releasing 0.3.2. :)
>=20
> I've put Release Candidate 1 at
> http://www.async.com.br/~kiko/orbit-python-0.3.1-RC1.tar.gz
>=20
> Feel free to pick it up and break it apart as hard as you can. Let's make
> 0.3.1 another setup towards rock-solid stability.
>=20
> > > One new point has come up: Johan has found out we can run CORBA using=
 the
> > > gtk mainloop, which avoids the need for us to call and block on orb.r=
un().
> > isn't thread safe.  But yeah, the first step would be to write our own
> > main loop for orb.run().  If Johan wants to tackle that, that'd be
> > great. :)
>=20
> So, Johan, are you up for it? That would be a nice 0.3.2 feature ;)
>=20
ok

> Take care,
> --
> Christian Reis, Senior Engineer, Async Open Source, Brazil.
> http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL
>=20
>=20
> _______________________________________________
> Orbit-python-list mailing list
> Orb...@li...
> https://lists.sourceforge.net/lists/listinfo/orbit-python-list
>=20
--=20
-------------------------------------------------
- Johan Dahlin              Address:            -
- zi...@as...        Nygatan 17, nb      -
- zil...@ho...          523 30 Ulricehamn   -
- PHONE: +46 (0)321-17559   SWEDEN              -
- IRC:   zilch @ irc.gnome.org                  -
-------------------------------------------------

Re: [Orbit-python-list] Release program for 0.3.1

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

On 6 Oct 2001, Jason Tackaberry wrote:

> Yeah, current cvs is pretty stable.  0.3.1 is just a bugfix release.
> There are more bugs to be fixed, of course, but there's nothing stopping
> us from releasing 0.3.2. :)

I've put Release Candidate 1 at
http://www.async.com.br/~kiko/orbit-python-0.3.1-RC1.tar.gz

Feel free to pick it up and break it apart as hard as you can. Let's make
0.3.1 another setup towards rock-solid stability.

> > One new point has come up: Johan has found out we can run CORBA using the
> > gtk mainloop, which avoids the need for us to call and block on orb.run().
> isn't thread safe.  But yeah, the first step would be to write our own
> main loop for orb.run().  If Johan wants to tackle that, that'd be
> great. :)

So, Johan, are you up for it? That would be a nice 0.3.2 feature ;)

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

Re: [Orbit-python-list] Release program for 0.3.1

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

> I am pretty happy with the current cvs code so far.

Yeah, current cvs is pretty stable.  0.3.1 is just a bugfix release. 
There are more bugs to be fixed, of course, but there's nothing stopping
us from releasing 0.3.2. :)

> One new point has come up: Johan has found out we can run CORBA using the
> gtk mainloop, which avoids the need for us to call and block on orb.run().
> This might effectively mean we can do client/server programming inside a
> single process, which to me is a pretty exciting perspective. I hope he'll
> be gutsy and write out a little module that helps us do that. zeeeelch?

This is something we talked about a while back when I was explaining how
I might make orbit-python work with multiple threads even though orbit
isn't thread safe.  But yeah, the first step would be to write our own
main loop for orb.run().  If Johan wants to tackle that, that'd be
great. :)

Jason.

[Orbit-python-list] Release program for 0.3.1

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

On 6 Oct 2001, Jason Tackaberry wrote:

> I suppose we should start thinking about releasing 0.3.1.  If you want
> to coordinate the release, kiko, I wouldn't object. *hint hint*

Sure. Johan, Roland, or anybody else have a specific request we should or
want to address?

I am pretty happy with the current cvs code so far.

Are there any tests that should be written apart from a test for sys.argv
handling?

One new point has come up: Johan has found out we can run CORBA using the
gtk mainloop, which avoids the need for us to call and block on orb.run().
This might effectively mean we can do client/server programming inside a
single process, which to me is a pretty exciting perspective. I hope he'll
be gutsy and write out a little module that helps us do that. zeeeelch?

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

[Orbit-python-list] Re: Fix for __import__()

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

On 6 Oct 2001, Jason Tackaberry wrote:

> > Review would be appreciated; this problem is currently blocking my ability
> > to release my FiscalPrinter software publically.
>
> Okay, this looks good.  But clean up your formatting before your check
> it in; use tabs to indent, not spaces.

Tack, I'll clean this up and check it in. However, I'd like to point out
we are hardly standardized in this sense and I don't know if tabs are the
right way at all. Should I provide the jwz link "why tabs suck?" :-)

IMHO, we should use spaces instead of tabs, and standardize on either 4 or
8 spaces. I prefer 4 myself, but that's not a big deal.

(The ChangeLog is ts=3 and spaced, for instance, and a lot of
CORBAmodule.c is mixed - makes it hard to fix.)

> Incidentally, I see that you checked in the last patch to
> CORBA__ORB_init, but I don't see an entry in the ChangeLog.  Ahem. :)

Sorry, I had written it but left it out, fixed.

Will check in soon.

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

[Orbit-python-list] Re: Fix for __import__()

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

> Review would be appreciated; this problem is currently blocking my ability
> to release my FiscalPrinter software publically.

Okay, this looks good.  But clean up your formatting before your check
it in; use tabs to indent, not spaces.

> (clue: if you take too long to review it gets checked in with r=nacho :)

That's some pretty impressive bot. :)

Incidentally, I see that you checked in the last patch to
CORBA__ORB_init, but I don't see an entry in the ChangeLog.  Ahem. :)

I suppose we should start thinking about releasing 0.3.1.  If you want
to coordinate the release, kiko, I wouldn't object. *hint hint*

Jason.

Re: [Orbit-python-list] Fix for __import__()

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

Christian:  
> The attached patch fixes orbit-python to work correctly with __import__(),
> fixing the current problem where it simply does not work. 

Sweet. Thanks for this fix -- I've also missed having __import__
work after doing an import CORBA, so this is much appreciated.

> It seems to be a decent fix and I'm able to use o-p normally with it
> applied. 

For what it's worth, this also works fine for me: it both fixes the
__import__ issue (now I can run my test suite automatically, yay!)
and doesn't break anything else in my code.

Brad
-- 
PGP public key available from http://pgp.mit.edu/

[Orbit-python-list] Fix for __import__()

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

Tack and Johan,

The attached patch fixes orbit-python to work correctly with __import__(),
fixing the current problem where it simply does not work. I have
significantly reworked auto_load_module_idls and removed a certain part
into a new function, import_from_idl_list to improve legibilty. I have in
the process fixed two memory leaks that could occur with strings. I have
added tests to the suite and ran both tests. The tests don't run at the
moment but that is a product of other bugs which we will someday fix,
hopefully.

It seems to be a decent fix and I'm able to use o-p normally with it
applied. This is my third version of this patch and it incorporates
suggestions from Johan.

Review would be appreciated; this problem is currently blocking my ability
to release my FiscalPrinter software publically.

(clue: if you take too long to review it gets checked in with r=nacho :)

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

Re: [Orbit-python-list] stuck

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

Frank, Tack, the patch that fixes this bug has been checked into cvs.

A question for the ORBit ninjas:

I would like to provide a test-script for the test-suite so we guarantee
this works. Is there a way to query the CORBA orb to know what parameters
are currently active in a session?

On 4 Oct 2001, Frank Rehberger wrote:

> On Thu, 2001-10-04 at 00:11, Christian Robottom Reis wrote:
> > On 3 Oct 2001, Frank Rehberger wrote:
> >
> > > I got stuck because I cant persuade python-orbit to use INET instead of
> > > UNIX-sockets, and I cant find a tiny C example that shows me how to
> > > create a server.
> >
> > Are you free to edit orbitrc? You can supply a file like:
> yes
>
> ----------- /etc/orbitrc -----
> ORBIIOPIPv4=1
> ORBIIOPUSock=0
> -- end --- /etc/orbitrc -----
>
> This works, but I assume, after re-login, that the entire GNOME desktop
> is using this setting now.
>
> I did try
> ./test-server.py -ORBIIOPIPv4=1 -ORBIIOPUSock=0
> and also
> ./test-server.py -ORBIIOPIPv4 1 -ORBIIOPUSock 0
>
> both did not work (orbit-python 0.3, ORBit-0.5.8)
>
> > Hey, don't hesitate to write. We don't have a lot of traffic, but it's
> > supposed to be a friendly list.
> thanks, it was a prompt help :)
>
> > Take care,
> Cheers, Frank
>
>
>


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

[Orbit-python-list] Re: PATCH: fix handling of argv in CORBA__ORB_init()

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

>  	for (i = 1; i < argc; i++) {
> -		PyObject *o = PyObject_Repr(PyTuple_GetItem(orb_args, i - 1));
> +		PyObject *o = PyObject_Str(PyTuple_GetItem(orb_args, i - 1));
>  		argv[i] = g_strdup(PyString_AsString(o));
>  		Py_DECREF(o);
>  	}

This looks good kiko, go ahead and commit it.

Or, sr=tack, as they say. :)

Jason.

Re: [Orbit-python-list] Exception handling inside C modules.

[Johan D. <zil...@ho...>]

s=F6n 2001-09-30 klockan 08.41 skrev Dominik Smog=F3r:
> Hello everyone.
>=20
>=20
> For last few days I've been trying to wrap some libOAF functions for use
> with
>=20
> Python. Everything went flawlessly until it came to execption handling.
> libOAF
>=20
> calls just return plain CORBA_Evironment and it would be best to just
> behave as
>=20
> if the call was made in orbit-python, that is raise python exception=20
>=20
> created by orbit-python during parsing of oaf.idl (import OAF).=20
>=20
> Therefore I exposed check_corba_ex function into public header (patch
> included).
>=20
> The problem is that calling it from my module causes python to SEGV soon
> after.
>=20
> Is there any special semantics connected with this function? Or maybe
> there is
>=20
> some better way of dealing with CORBA exceptions in C python modules?
>=20
> Regards,
> Domink.
> ----
>=20
Instead of using ORBit-Python's CORBA_Environment, just create a new
one.

But i have already wrapped most parts of oaf in my oafmodule.
It can be found in bonobo-python module in GNOME CVS.
Fortunately you must have bonobo atm.


> --- orbit-python.h	Sun Jun 10 17:00:36 2001
> +++ /usr/src/RPM/BUILD/orbit-python-0.3.0-2/src/orbit-python.h	Sun Sep 30=
 01:42:47 2001
> @@ -23,7 +23,7 @@
>  typedef struct {
>     PyObject_HEAD
>     CORBA_TypeCode tc;=09
> -	char *repo_id;
> +  char *repo_id;
>  } CORBA_TypeCode_PyObject;
> =20
> =20
> @@ -79,7 +79,9 @@
>         =20
>  	PyTypeObject *poam_type;
>  	POAManager_PyObject *(*poam_new)(PortableServer_POAManager o);
> -
> +=09
> +	CORBA_boolean (*checkex)(CORBA_Environment* ev);
> +	PyObject *OPExc, *OPSysExt, *OPUsrExt;
>  } _ORBitPython_FunctionStruct;
>  =09
>  #ifdef INSIDE_PYORBIT
> @@ -141,6 +143,12 @@
>  #define PyORBit_POAManager_Check(v) ((v)->ob_type =3D=3D _ORBitPython_AP=
I->poam_type)
>  #define PyORBit_POAManager_Type     *(_ORBitPython_API->poam_type)
>  #define PyORBit_POAManager_Get(o)   (((POAManager_PyObject*)(o))->obj)  =
=20
> +
> +#define PyORBit_CORBA_Environment_Query   _ORBitPython_API->checkex
> +
> +#define PyORBit_Exception   (_ORBitPython_API->OPExc)
> +#define PyORBit_SystemException (_ORBitPython_API->OPSysExt)
> +#define PyORBit_UserException (_ORBitPython_API->OPUsrExt)
> =20
>  #define init_orbit_python() \
>  { \
> --- CORBAmodule.c	Thu Aug 16 22:19:26 2001
> +++ /usr/src/RPM/BUILD/orbit-python-0.3.0-2/src/CORBAmodule.c	Fri Sep 28 =
15:18:32 2001
> @@ -380,7 +380,10 @@
> =20
>  	&CORBA_TypeCode_PyObject_Type,  CORBA_TypeCode_PyObject__new,
>  	&POA_PyObject_Type,             POA_Object_to_PyObject,
> -	&POAManager_PyObject_Type,      POAManager_Object_to_PyObject
> +	&POAManager_PyObject_Type,      POAManager_Object_to_PyObject,
> +=09
> +	check_corba_ex,
> +	NULL,NULL,NULL
>  };
> =20
>  void initCORBA(void)
> @@ -399,10 +402,7 @@
> =20
>  	m =3D Py_InitModule("CORBA", CORBA_methods);
>  	ModuleDict =3D PyModule_GetDict(m);
> -=09
> -	PyDict_SetItemString(ModuleDict, "_ORBitPython_API", =20
> -						 PyCObject_FromVoidPtr(&functions, NULL));
> -=09
> +
> =20
>  	// Global hashes
>  	object_glue =3D g_hash_table_new(g_str_hash, g_str_equal);
> @@ -421,6 +421,13 @@
>  	ORBit_Python_init_consts();
>  	ORBit_Python_init_marshal();
>  	ORBit_Python_init_portable_server();
> +
> +	functions.OPExc=3DOPExc_Exception;
> +	functions.OPSysExt=3DOPExc_SystemException;
> +	functions.OPUsrExt=3DOPExc_UserException;
> +=09
> +	PyDict_SetItemString(ModuleDict, "_ORBitPython_API", =20
> +						 PyCObject_FromVoidPtr(&functions, NULL));
> =20
>  	global_client_module =3D Py_InitModule("_GlobalIDL", empty_methods);
>  	global_poa_module =3D Py_InitModule("_GlobalIDL__POA", empty_methods);
--=20
-------------------------------------------------
- Johan Dahlin              Address:            -
- zi...@as...        Nygatan 17, nb      -
- zil...@ho...          523 30 Ulricehamn   -
- PHONE: +46 (0)321-17559   SWEDEN              -
- IRC:   zilch @ irc.gnome.org                  -
-------------------------------------------------

[Orbit-python-list] PATCH: fix handling of argv in CORBA__ORB_init()

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

Tack, the following patch fixes handling of sys.argv when passed into
ORB_init() by using PyObject_Str() instead of PyObject_Repr(), since
_Repr() adds single quotes to it's argument. I've tested it locally.

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

Re: [Orbit-python-list] stuck

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

On 4 Oct 2001, Frank Rehberger wrote:

> This works, but I assume, after re-login, that the entire GNOME desktop
> is using this setting now.

As the applications start, actually, since ORBit only reads this at
startup.

> I did try
> ./test-server.py -ORBIIOPIPv4=1 -ORBIIOPUSock=0
> and also
> ./test-server.py -ORBIIOPIPv4 1 -ORBIIOPUSock 0
>
> both did not work (orbit-python 0.3, ORBit-0.5.8)

Hmmm. Well, I assume you are passing sys.argv on to ORBit, which means
it's ignoring the flags. I'll look into orbit's code... Hmmm! Heh, we have
a bug in ORBit-Python (Tack, what about those zero bugs there?). Try this
patch -- damn, sourceforge is offline so no patch is possible. Okay try
doing this:

-- line 56 in CORBA__ORB_init() --

    for (i = 1; i < argc; i++) {

-> swap

        PyObject *o = PyObject_Repr(PyTuple_GetItem(orb_args, i - 1));

-> for

        PyObject *o = PyObject_Str(PyTuple_GetItem(orb_args, i - 1));


        argv[i] = g_strdup(PyString_AsString(o));
        Py_DECREF(o);
    }

-- line 61 --

PyObject_Repr adds single quotes, and is wrong. Using _Str() has corrected
the problem here, providing nice handling (this was a bug I ran into a
year ago but was too clueless to fix, how funny.)

BTW: I very commonly use gdb to track down this sort of problem and since
a few people here might want to use it with python, here's a tip. Start
python with a "gdb python" and in your script, add the lines

import signal, os
os.kill(os.getpid, signal.SIGINT)

where you want it to stop, and "r foo.py". The script will stop at that
point, and you can "break" inside loaded modules and so forth.

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

Re: [Orbit-python-list] bug report

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

On 4 Oct 2001, Frank Rehberger wrote:

> why do I need to get an bug-account for reporting a bug?
> I really get problems to manage all my accounts, will you switch to
> "passport" **grin**

For bugzilla? Because it's required to be able to receive email so
developers can follow up on a bug. If you don't care for security, use a
dumb password, but let us find you :)

And btw: if you're writing because of the bug you just reported, I have a
patch for it I'm testing (string arguments are quoted) right now.

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