orbit-python-list

Re: [Orbit-python-list] How to use IDL unions with orbit-python?

[Roland M. <99....@ai...>]

ml (2002-01-24 00:20:45 +0100) :

[Accessing union members]
> How can I access A and B in client and server code in both cases?  I
> tried different variants like M.A and M.U.A, but didn't succeed.

I'm afraid I can't give you a definitive answer since I don't use
unions, but you might consider reading the CORBA Python language
mapping specification.  I seem to remember it explains precisely the
syntax to use in order to access union members.  You can find this
spec on the OMG site, and there's a link to it from the ORBit-Python
homepage, at <URI:http://orbit-python.sault.org/>.

Roland.
-- 
Roland Mas

With the arrest of Dimitry Sklyarov it has become apparent that it is not
safe for non US software engineers to visit the United States. - Alan Cox

Re: [Orbit-python-list] Any activity?

[Roland M. <99....@ai...>]

Roland Mas (2002-01-25 11:21:57 +0100) :

> Roland Mas (2002-01-23 14:55:03 +0100) :
>
>>   In particular, there are several bugs registered on the Bugzilla
>> pages, one of which concerns me particularly (I just submitted it).
>
>   That one has been fixed by me (with help from Johan).  I'll upload
> new Debian packages shortly.

Well, it's done.  Know that this fix shows a memory leak, though.  It
doesn't exactly /introduce/ this leak, since the conditions leading to
it previously led to a segfault, but there it is.  I had a fix for
that leak, but it was a fix for ORBit, and I was told by one ORBit
guru that it was wrong.  Apparently it's okay for applications
(including ORBit-Python) to fiddle with the deep innards of ORBit
proper (including ...->_private members of structs).  I'm looking for
another, ORBit-Python-only, fix.

Roland.
--=20
Roland Mas

C'est dans la boue la plus naus=E9euse que plongent les racines de
l'=E9tincelante fleur de lotus. -- in Sri Raoul le petit yogi (Gaudelette=
)

Re: [Orbit-python-list] Any activity?

[Roland M. <99....@ai...>]

Roland Mas (2002-01-23 14:55:03 +0100) :

>   In particular, there are several bugs registered on the Bugzilla
> pages, one of which concerns me particularly (I just submitted it).

  That one has been fixed by me (with help from Johan).  I'll upload
new Debian packages shortly.

Roland.
--=20
Roland Mas

=CAtes vous s=FBr ? (O/N)
  -- Derniers mots d'un ordinateur

[Orbit-python-list] How to use IDL unions with orbit-python?

[<ml...@kn...>]

Hi,

I'm new to Orbit-Python (and new to Orbit and new to
Python), so my question may be a frequently asked one.
I have sth. like that:

module M {
  struct S {
    enum E1 { A, B } e;
  };
  union U switch (enum E2 { A, B }) {
    case A: ...;
    case B: ...;
  };
  ...
};

How can I access A and B in client and server code in
both cases?  I tried different variants like M.A and
M.U.A, but didn't succeed.

Thanks in advance!

[Orbit-python-list] Any activity?

[Roland M. <99....@ai...>]

  Hi people,

  I haven't seen much activity on this list, on IRC, or in the CVS
repository for rather a long time.  I'd like to send a SIGCONT to the
group (oncluding myself of course), so that the development process
goes on.

  In particular, there are several bugs registered on the Bugzilla
pages, one of which concerns me particularly (I just submitted it).
The 0.3.1 release is already outdated (since at lease one bug has been
fixed in CVS since it was released), and there's still no 0.3.2
version in the foreseeable future.  Since my work is again going to
involve a lot of development with ORBit-Python, I'll need it to be
fairly stable in a matter of weeks.

  Is anyone else but me interested in fixing these bugs?  Come on
guys, let's wake up and make ORBit-Python what it deserves to be!

Roland.
-- 
Roland Mas

Death *was* hereditary.  You got it from your ancestors.
  -- in Hogfather (Terry Pratchett)

[Orbit-python-list] [Jochen Voss <jvoss2@web.de>] Bug#123848: python-orbit: mapping for union types is incompatible with the specification

[Roland M. <99....@ai...>]

  Hello,

  I got the following bug report from a Debian user (bug #123848,
available from <URI:http://bugs.debian.org/123848>).

,----
| Subject: Bug#123848: python-orbit: mapping for union types is incompatible with the specification
| From: Jochen Voss <jv...@we...>
| 
| Package: python-orbit
| Version: 0.3.1-3
| Severity: normal
| 
| Hello,
| 
| recently I tried to use CORBA´s discriminated union types
| with python-orbit and had several problems with this.
| The most serious one is the following.
| 
| The "Python Language Mapping Specification" (OMG document 01-02-66)
| says on page 1-6:
| 
|     Union types are mapped to classes with two attributes.
|     The first is the discriminant _d, the second the associated value _v.
|     For each branch, there is an additional attribute, which
|     can only be accessed if the branch has been set. [...]
| 
| Python-orbit does not follow this specification.
| It uses "d" and "v" (without the underscore) as the names for
| discriminant and value.  And the "additional attribute" is
| simple not there.  Consequently all examples from page 1-7
| of the specification (and my own program, too) do not work
| with python-orbit.
| 
| I see that it may be some work to implement the
| additional-attribute-stuff, but the the names for discriminant
| and value really should be corrected.
| 
| Jochen
`----

  For what it's worth: the version mentioned there (0.3.1-3) is in
fact not the vanilla 0.3.1 release, but 0.3.1 + the patch to fix the
marshalling of booleans (which used to lead to a segmentation fault).

  I might start hacking on this one on and off, but if someone wants
to be faster than I, please do.

Roland.
-- 
Roland Mas

Qu'est-ce qui est jaune, qui pèse deux cents kilos et qui chante ?
Un sumotori dans sa salle de bains.

Re: [Orbit-python-list] Marshalling a boolean in O-P 0.3.1 causes a segfault

[Roland M. <99....@ai...>]

Roland Mas (2001-12-09 16:46:09 +0100) :

> Christian Robottom Reis (2001-12-08 09:42:51 -0200) :
>
>> On Wed, 21 Nov 2001, Roland Mas wrote:
>>
>>>   It seems version 0.3.1 generates a segfault when marshalling
>>> booleans that 0.3.0 does not have.  I attach a brief test-case.
>>
>> Ok, I'll try and look into this. I have to point out that I didn't cover
>> booleans in the testsuite up to now, which is how this regrettable
>> regression was even possible :-)
>
> Well, I applied a patch I received from the Debian user, and it seems
> to fix the bug.  The user confirmed he can't reproduce it, and my
> test-case doesn't reproduce it either.
>
>   That means you just have to add the stuff into the test-suite :-)

Um.  It seems we still have a segfault lurking somewhere (with CVS as
of approx. 24 hours ago).  Unfortunately, the test-suite doesn't tell
us where...  Maybe you'd care to increase the verbosity, because what
I currently get is:
,----
| $ ./runtest.sh 
| ......................./runtest.sh: line 39: 12327 Segmentation fault      python Test.py $*
| $
`----

  Yeah, I know, at some point I'll have to learn how these things
work, but currently I'm busy on other things.  Namely, I'm replacing
PyArg_Parse and Py_BuildValue calls with other functions, since it
seems that these two functions have been sort of deprecated (and it's
hard to find doc on them...),

Roland.
-- 
Roland Mas

Latitude 43.60039° N / Longitude 6.99555° E

Re: [Orbit-python-list] Marshalling a boolean in O-P 0.3.1 causes a segfault

[Roland M. <99....@ai...>]

Christian Robottom Reis (2001-12-08 09:42:51 -0200) :

> On Wed, 21 Nov 2001, Roland Mas wrote:
>
>>   It seems version 0.3.1 generates a segfault when marshalling
>> booleans that 0.3.0 does not have.  I attach a brief test-case.
>
> Ok, I'll try and look into this. I have to point out that I didn't cover
> booleans in the testsuite up to now, which is how this regrettable
> regression was even possible :-)

Well, I applied a patch I received from the Debian user, and it seems
to fix the bug.  The user confirmed he can't reproduce it, and my
test-case doesn't reproduce it either.

  That means you just have to add the stuff into the test-suite :-)

Roland.
-- 
Roland Mas

Sauvez une souris, mangez votre chat.

Re: [Orbit-python-list] Marshalling a boolean in O-P 0.3.1 causes a segfault

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

On Wed, 21 Nov 2001, Roland Mas wrote:

>   It seems version 0.3.1 generates a segfault when marshalling
> booleans that 0.3.0 does not have.  I attach a brief test-case.

Ok, I'll try and look into this. I have to point out that I didn't cover
booleans in the testsuite up to now, which is how this regrettable
regression was even possible :-)

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

[Orbit-python-list] Bug with unusual IDL

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

Hi,

I'm working on a Python/CORBA tutorial, so I'm experimenting with
ORBit-Python. I noticed a problem with the following unusual, but
legal, IDL:

  module M {
    union U switch ( enum E { one, two } ) {
    case one:
      long l;
    case two:
      short s;
    };
  };

The unusual thing is that the switch kind is declared _inside_ the
switch specification. The IDL specification says that the enum E is
inside the scope of the union. This means the enumerators should be
available to Python as M.U.one and M.U.two. They aren't. In fact, as
far as I can tell, they aren't available anywhere.

Cheers,

Duncan.

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

[Orbit-python-list] Scritping Evolution with Python

[Dale P. S. <ds...@al...>]

I would like to suck addressbook and calendar data from Evolution using
Python.  I know I have to:

import CORBA
import GNOME.Evolution

But I don't know what to do from there.  I am completely new to python
and corba (and oaf and wombat and all that other stuff).

Could anyone send an example.  Thanks.

What's this for?  How about sending name/number/email to my cell phone.

Thanks again
  -Dale

-- 
Dale P. Smith
Treasurer, Cleveland Linux Users Group http://cleveland.lug.net
Senior Systems Consultant, Altus Technologies Corporation
ds...@al...
440-746-9000 x339

[Orbit-python-list] Spec compliance, performance, memory leaks

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

Hi,

I've been having a quick look at ORBit-Python, and I discovered a
couple of mapping errors, a surprising lack of performance, and a
memory leak. Not bad for one little program :-) .  I'm using
ORBit-Python 0.3.1 and ORBit 0.5.12.

The IDL, server and client files are attached. The tests just do lots
of invocations, transmitting various kinds of sequences and arrays.
The tests can run in two ways. If you run pserver.py with no arguments
it prints an IOR. Give that IOR as an argument to pclient.py, and it
will do a cross-process test. If you run pserver.py with an argument
of -l, it will import pclient and run the tests in the same process.

First the mapping errors. One of the operations is:

    typedef octet octeta[200];
    octeta op2(in octeta a);

The CORBA mapping says "Sequences and arrays of octets and characters
are mapped to the string type for efficiency reasons", so the array of
octets should be passed as a string. When the test does that,
ORBit-Python says:

** WARNING **: Array type must be either list or tuple

and then freezes totally. Ctrl-C can't stop it -- you have to use
kill.

The tests also checks sequence of octet, and ORBit-Python properly
accepts a string there. The octet array test is commented out in the
attached file.

Another of the operations tests unsigned longs. I noticed that
ORBit-Python is mapping unsigned long to Python int, which is wrong.
It should use Python long int, so values above 2**31 - 1 can be
represented.


Now the performance. I was surprised that ORBit-Python was slower than
omniORBpy in almost all the tests, given that omniORBpy has lots of
locking overhead due to being multi-threaded, and because there's more
Python code involved. The results of running the server and client in
different processes on the same machine were as follows. Times are in
seconds, so lower is better.

                 ORBit-Python   omniORBpy
                              
single long:        2.231         2.172
octet sequence:     2.309         2.495
short sequence:     6.460         3.655
short array:        6.459         3.624
long sequence:      8.731         3.679
long array:         8.619         3.663
ulong sequence:     9.168         9.742
ulong array:        9.106         9.710
double sequence:    8.817         3.944
double array:       8.377         3.980

omniORBpy's big spike in the times for ulong is because it is properly
using Python longs to represent them, and they are much slower.
ORBit-Python uses Python ints (once it has dealt with the initial
longs the test program gives it) so it doesn't have such a spike. It
seems ORBit-Python is quite slow with the larger types.

Running between two machines across the network results in a similar
spread of times:

                 ORBit-Python   omniORBpy
                              
single long:        4.142         4.008 
octet sequence:     5.003         5.869 
short sequence:    11.842         8.346 
short array:       11.308         8.340 
long sequence:     16.562        11.296
long array:        16.358        11.319
ulong sequence:    17.069        16.585
ulong array:       16.903        16.541
double sequence:   16.650        11.903
double array:      16.589        11.983

Now the real surprise, running in-process using pserver.py -l:

                 ORBit-Python   omniORBpy
                              
single long:        1.963         0.463
octet sequence:     2.025         0.477
short sequence:     6.195         0.906
short array:        6.017         0.901
long sequence:      8.261         0.886
long array:         7.981         0.897
ulong sequence:     8.789         1.226
ulong array:        8.518         1.231
double sequence:    8.399         0.913
double array:       8.098         0.916

Eek!  It looks like ORBit-Python is still using the Unix socket
transport. Is it meant to do that?

Finally, I noticed that with ORBit-Python the client process grows
continuously throughout the run, so there is obviously a memory leak
somewhere. The same thing happens with the colocated test.

Hope that's all been of interest/use.

Cheers,

Duncan.

Re: [Orbit-python-list] Marshalling a boolean in O-P 0.3.1 causes a segfault

[Roland M. <99....@ai...>]

Roland Mas (2001-11-21 17:45:53 +0100) :

[...]

I submitted this a bug #11 on the O-P Bugzilla.
-- 
Roland Mas

When you have a hammer in your hand, most things look like a nail.

[Orbit-python-list] ORBit-0.5.12 unsupported

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

On Wed, 14 Nov 2001, josh lucas wrote:

> While trying to compile the latest release (0.3.1), I got compile errors

Luckily, you didn't try and use ORBit-0.5.12. As of right now, it doesn't
work, primarily because we workaround a bug in ORBit using an evil hack
:-) -- and I'm working on it, but it's not very easy (will probably
require changes to ORBit).

(The gist of it is that ORBit needs a way of checking if the servant is
already active during poa.c:*activate_object() without relying on the
_private member of the PortableServant. This could be done by checking on
a hash, but there doesn't seem to be one I can use *sigh* )

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

Re: [Orbit-python-list] Crash with ORB_init() / del() in 0.3.1

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

tor 2001-11-15 klockan 15.23 skrev Jason Tackaberry:
> > <markmc> kiko, I think in ORBit, ORBit_init didn't do a
> > CORBA_Object_duplicate on the existing ORB  before returning it, so you
> > would only be allowed to release it once
> 
> This is the problem.
> 
> So, as we discussed on IRC, add the CORBA_Object_duplicate call to
> CORBA_ORB_PyObject__new and leave the CORBA_Object_release call in the
> destructor.  This is better than just removing CORBA_Object_release()
> since it's more consistent with refcounting.  (i.e. we grab a ref to the
> ORB in the constructor and release the reference in the destructor, as
> opposed to borrowing the ref from ORBit.)
> 
> > <markmc> kiko, I remember Michael talking about this recently....
> > <markmc> kiko, its different in ORBit2
> 
> Keep that in mind, Johan. :)
> 
> > a) Make the ORB a special object, so it's release is just a dummy release
> > and it only gets cleaned up by Python on exit (no big deal IMHO but this
> > isn't really fixing it).
> 
> The ORB is already a separate type object.  So the fix is trivial.
> 
> Jason.
> 
> -- 
> Academic Computing Support Specialist         Assistant Section Editor
> Algoma University College                     http://linux.com/develop
> Sault Ste. Marie, Ontario                 
> 705-949-2301 x330                                   Personal Home Page
> http://www.auc.ca                                     http://sault.org
> 
> 
> _______________________________________________
> Orbit-python-list mailing list
> Orb...@li...
> https://lists.sourceforge.net/lists/listinfo/orbit-python-list


>>> import CORBA
>>> for i in range (50):
...   orb = CORBA.ORB_init ()
...   del orb
... 

Works perfectly in ORBit2 port.
(without duplicating the orb)

---
Johan Dahlin

Re: [Orbit-python-list] Crash with ORB_init() / del() in 0.3.1

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

> <markmc> kiko, I think in ORBit, ORBit_init didn't do a
> CORBA_Object_duplicate on the existing ORB  before returning it, so you
> would only be allowed to release it once

This is the problem.

So, as we discussed on IRC, add the CORBA_Object_duplicate call to
CORBA_ORB_PyObject__new and leave the CORBA_Object_release call in the
destructor.  This is better than just removing CORBA_Object_release()
since it's more consistent with refcounting.  (i.e. we grab a ref to the
ORB in the constructor and release the reference in the destructor, as
opposed to borrowing the ref from ORBit.)

> <markmc> kiko, I remember Michael talking about this recently....
> <markmc> kiko, its different in ORBit2

Keep that in mind, Johan. :)

> a) Make the ORB a special object, so it's release is just a dummy release
> and it only gets cleaned up by Python on exit (no big deal IMHO but this
> isn't really fixing it).

The ORB is already a separate type object.  So the fix is trivial.

Jason.

-- 
Academic Computing Support Specialist         Assistant Section Editor
Algoma University College                     http://linux.com/develop
Sault Ste. Marie, Ontario                 
705-949-2301 x330                                   Personal Home Page
http://www.auc.ca                                     http://sault.org

[Orbit-python-list] Crash with ORB_init() / del() in 0.3.1

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

The following snippet (thanks zilch) illustrates a cool
undiscovered-as-of-yet crash in ORBit-Python with both ORBit-0.5.8 and
0.5.12:

import CORBA
for o in range(0,4):
	orb = CORBA.ORB_init()
	del(orb)

As always I am finding these neat new ways to crash o-p. This time, what
happens was discussed on #gnome:

<kiko> hmmm I think I know what it is.
<kiko> this crash happens when I have multiple orb = ORB_init() + del(orb)
calls
<kiko> which means I am releasing the orb, recreating it, and releasing it
again. does that work?
<markmc> kiko, I think in ORBit, ORBit_init didn't do a
CORBA_Object_duplicate on the existing ORB  before returning it, so you
would only be allowed to release it once
<kiko> hmmm. i'll have to work around this to avoid a crash in the
testsuite.
<markmc> kiko, I remember Michael talking about this recently....
<markmc> kiko, its different in ORBit2
<kiko> markmc: I see. I'll put this on the ML to see what Tack says.
<markmc> kiko, but we didn't want to introduce leaks into old ORBit progs
by changing the behaviour
<kiko> Hmmmm. I understand.

So I think we're not allowed to create the orb multiple times. To work
around this, there are a couple of solutions I see:

a) Make the ORB a special object, so it's release is just a dummy release
and it only gets cleaned up by Python on exit (no big deal IMHO but this
isn't really fixing it).

b) Make PyObject release check if it's an orb and if so, don't release it.

We would have to change ORB_init() to not really create two orbs if we
didn't want to leak, of course. Well, Tack, opinion? I haven't looked at
the ORBit code, but I'll do so now.

Oh, I also fixed PACKAGE=orbiit-python in configure.in and configure that
SOMEBODY checked into the tree this week.

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

Re: [Orbit-python-list] patch for src/Makefile.in

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

Johan Dahlin (2001-11-15 10:39:41 +0100) :

> tor 2001-11-15 klockan 10.30 skrev Roland Mas:
[...]
>> Eh?  How strange...  I have committed this very same patch to CVS a
>> few days ago...  Did someone revert it?
>> 
> I'm not sure it made it into the 0.3.1 release.
> But it's indeed fixed in CVS.

You're right, 0.3.1 hasn't got it...  Tack?  I demand a 0.3.2 :-)

Roland.
-- 
Roland Mas

In every life you got some trouble, when you worry you make it double.
  -- in Don't worry, be happy (Bobby McFerrin)

Re: [Orbit-python-list] patch for src/Makefile.in

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

tor 2001-11-15 klockan 10.30 skrev Roland Mas:
> josh lucas (2001-11-14 22:48:55 -0800) :
> 
> > While trying to compile the latest release (0.3.1), I got compile
> > errors in idl.c when it tried to include IDL.h.  The problem it
> > seems is that the LIBIDL_CFLAGS value wasn't added to the rest of
> > the includes.  Once I did this, I was able to compile.
> 
> Eh?  How strange...  I have committed this very same patch to CVS a
> few days ago...  Did someone revert it?
> 
I'm not sure it made it into the 0.3.1 release.
But it's indeed fixed in CVS.

> Roland.
> -- 
> Roland Mas
> 
> $ chown -R us:us your_base*
> 
> _______________________________________________
> Orbit-python-list mailing list
> Orb...@li...
> https://lists.sourceforge.net/lists/listinfo/orbit-python-list

---
Johan Dahlin

Re: [Orbit-python-list] patch for src/Makefile.in

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

josh lucas (2001-11-14 22:48:55 -0800) :

> While trying to compile the latest release (0.3.1), I got compile
> errors in idl.c when it tried to include IDL.h.  The problem it
> seems is that the LIBIDL_CFLAGS value wasn't added to the rest of
> the includes.  Once I did this, I was able to compile.

Eh?  How strange...  I have committed this very same patch to CVS a
few days ago...  Did someone revert it?

Roland.
-- 
Roland Mas

$ chown -R us:us your_base*

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

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

Christian Robottom Reis (2001-11-15 00:56:06 -0200) :

> On 12 Oct 2001, Jason Tackaberry wrote:
>
>>         * remove test-suite/old
>
> Can I safely cvs rm this? Roland, any hard feelings? :)

No problem at all.  Your test-suite is much more comprehensive and
easy to maintain, I think.

Roland.
-- 
Roland Mas

That's one of the good fings about not existin'; they leave you alone most
of the time.  --  in My Hero (Tom Holt)

[Orbit-python-list] patch for src/Makefile.in

[josh l. <jo...@st...>]

While trying to compile the latest release (0.3.1), I got compile errors
in idl.c when it tried to include IDL.h.  The problem it seems is that
the LIBIDL_CFLAGS value wasn't added to the rest of the includes.  Once
I did this, I was able to compile.

Here is the simple patch..


josh

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

Can I safely cvs rm this? Roland, any hard feelings? :)

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

[Orbit-python-list] ANNOUNCE: ORBit-Python 0.3.1

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

Hi everyone,

After of plenty of the usual procrastination, and plenty of nagging from
the rest of the ORBit-Python crew to release, we are happy to announce
the availability of 0.3.1.  This is a bug fix release, which includes:

        * Revamped test suite
        * Marshalling fixes for double and boolean
        * _narrow() segv fix
        * Command line arguments are correctly passed to ORBit
        * CORBA.Any memory fixes
        * null and void typecodes handled
        * a few IDL importing bugs fixed.

You may download the tarball or RedHat 7.x RPMs at:

    http://orbit-python.sault.org/
    
The following people deserve credit for this release:

        * Cristian Marinescu <Cri...@no...>
        * Chip Richards <ch...@ni...>
        * Brad Chapman <cha...@ar...>

And, of course:

        * Johan Dahlin  <zil...@ho...>
        * Roland Mas  <ma...@ec...>
        * Christian Robottom Reis  <ki...@as...>

Cheers,
Jason.

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

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

On 8 Nov 2001, Johan Dahlin wrote:

> 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).

I was wondering, Johan. Can we just use the glib mainloop instead of
orb.run and offer an API for orb.run() instead? Please tell me we can and
that it's easy?

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

Well, since we already require glib, then maybe we could wrap the minimum
amount of glib - stealing some C code from pygtk would work, perhaps?

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