orbit-python-list

[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] 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] 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.

[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] 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

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.

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

[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 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

[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, 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