orbit-python-list

[Orbit-python-list] Memory issues with Anys

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

Hello all;
I've been plugging along quite nicely with ORBit-python on the IDL
I'm implementing, but ran into some sort of memory issue with anys.
In my actual code, I was getting messages like:

python in free(): warning: chunk is already free.

any then getting segfaults after too many of these messages.
Basically, all I'm doing is extracting the typecode and value from
the any. I was able to duplicate the error messages (without the
segfaulting, though) in a small test server/client. To avoid sending
tarballs to the list, I put the test scripts at:

http://www.bioinformatics.org/bradstuff/bc/AnyTest.tar.gz

Basically, this contains an IDL, client and server, that shows the
problem. 

I dug into the code on this, and came up with a proposed patch. The
patch seems to fix the problem (in both my test case and my real
code), but I'm definately not a C expert so someone smarter than I
will have to check it out to see if it causes memory leaks, etc.
Basically, I Py_INCREF the tc and value before returning them, which
I think accounts for the reference the calling code will get. But,
than again, I'm no expert :-).

Hope this helps.
Brad

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

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

Hey all;
Thanks for the responses on this.

[I talk about a seg-fault problem caused by self-referencing
structs]

Jason:
> Yep, this certainly causes nasty things.  In fact, orbit-idl also
> segfaults on this IDL.  Maybe ORBit2's IDL compiler also has this
> problem?

Doh, thanks -- I didn't even think of looking at orbit-idl. Well now
it makes sense why I'm seeing the problem :-).

Mark McLoughlin:
>  No, ORBit2's IDL compiler has fixed this problem. If my memory
> serves me correctly, there's a fix for this in ORBit HEAD as well.

Thanks for the info. I grabbed ORBit out of CVS (the stable
revision), and it still seems to have the problem for me. Don't know
if this'll help save any time looking at it with ORBit-python.

Jason:
> BTW, you shouldn't really need to use _load_idl(). 

Well, my use case is kind of what Christian was suggesting. I'm
actually emulating stubs and skeletons (by hacking up __init__.py in
one of my modules), so I just use the _load_idl() to grab the idl
from a predefined location. It doesn't really affect my portability
in this case, because I'm already going for portability between
multiple ORBs. Thanks for the advice, though!

[My minimal test case]
Christian:
> Minimal, but 3vil. Do you have a simple test script I can integrate
> to the test-suite so we guarantee it's fixed and stays fixed 
> over versions?

Hmmm, I'm not exactly sure if this is what you want, but the
attached script will cause the seg-fault with the IDL I posted. I'm
not sure if you want seg-faulting scripts in the Test Suite though
:-)

Brad

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

[Mark M. <ma...@sk...>]

Hi Jason,

On Tue, 28 Aug 2001, Jason Tackaberry wrote:

> > struct RecursiveStruct {
> >   sequence <RecursiveStruct> inner_struct;
> > };
> >
> > interface ProblemInterface {
> >   attribute RecursiveStruct problem_item;
> > };
>
> Yep, this certainly causes nasty things.  In fact, orbit-idl also
> segfaults on this IDL.  Maybe ORBit2's IDL compiler also has this
> problem?

	No, ORBit2's IDL compiler has fixed this problem. If my memory
serves me correctly, there's a fix for this in ORBit HEAD as well.

	Oh, and the Perl bindings have this problem too ;)

Good Luck,
Mark.

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

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

On Tue, 28 Aug 2001, Brad Chapman wrote:

> narrowing down, it appears as if this is a minimal IDL that will
> cause the problem:
>
> struct RecursiveStruct {
>   sequence <RecursiveStruct> inner_struct;
> };
>
> interface ProblemInterface {
>   attribute RecursiveStruct problem_item;
> };

Minimal, but 3vil. Do you have a simple test script I can integrate to the
test-suite so we guarantee it's fixed and stays fixed over versions?

> The idea is that you have a struct that has, as one of its member, a
> list of itself (in the IDL that I'm working on this is used to descend
> a sort of "tree" of items). When a struct like this is present inside
> an interface, it will cause the problem. gdb gives a trace that looks
> like:

By list of itself you mean "list of things of the same type as it", right?

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

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

On Tue, 28 Aug 2001, Jason Tackaberry wrote:

> BTW, you shouldn't really need to use _load_idl().  The only time you
> need to use _load_idl() is when the preprocessor is broken, in which
> case that should get fixed too.  (Well, another valid case to use

Or when the IDL isn't in the IDLPATH, and you specify the full path.

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

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

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

* Brad Chapman (cha...@ar...) [010828 21:57]:
> I ran into a problem with CORBA._load_idl() getting a Bus error and
> core dump while parsing an IDL that I work on. After a bit of
> narrowing down, it appears as if this is a minimal IDL that will
> cause the problem:
> 
> struct RecursiveStruct {
>   sequence <RecursiveStruct> inner_struct;
> };
> 
> interface ProblemInterface {
>   attribute RecursiveStruct problem_item;
> };

Yep, this certainly causes nasty things.  In fact, orbit-idl also
segfaults on this IDL.  Maybe ORBit2's IDL compiler also has this
problem?

I'll have a look at the nature of this problem over the weekend.  If
it's nothing significant then it will be fixed for 0.3.1, which should
be released hopefully early next week.

BTW, you shouldn't really need to use _load_idl().  The only time you
need to use _load_idl() is when the preprocessor is broken, in which
case that should get fixed too.  (Well, another valid case to use
_load_idl() is when you want to load an IDL that is new since the CORBA
module was imported.  Mind you, I could probably work up a hack to get
around this problem too.)

Cheers,
Jason.

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

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

Hello all;
I ran into a problem with CORBA._load_idl() getting a Bus error and
core dump while parsing an IDL that I work on. After a bit of
narrowing down, it appears as if this is a minimal IDL that will
cause the problem:

struct RecursiveStruct {
  sequence <RecursiveStruct> inner_struct;
};

interface ProblemInterface {
  attribute RecursiveStruct problem_item;
};

The idea is that you have a struct that has, as one of its member, a
list of itself (in the IDL that I'm working on this is used to descend
a sort of "tree" of items). When a struct like this is present inside
an interface, it will cause the problem. gdb gives a trace that looks
like:

#0  0x283c6dba in _thread_leave_cancellation_point () from /usr/lib/libc_r.so.4
#1  0x283c705d in _thread_leave_cancellation_point () from /usr/lib/libc_r.so.4
#2  0x283c7781 in malloc () from /usr/lib/libc_r.so.4
#3  0x283bf179 in calloc () from /usr/lib/libc_r.so.4
#4  0x28461dc7 in g_malloc0 () from /usr/local/lib/libglib12.so.3
#5  0x283ff8be in alloc_typecode () at idl.c:917
#6  0x28400538 in get_struct_typecode (tree=0x81af5c0) at idl.c:1172
#7  0x28401525 in get_typecode (tree=0x81af5c0) at idl.c:1431
#8  0x283ffe59 in get_ident_typecode (tree=0x81af240) at idl.c:1043
#9  0x28401565 in get_typecode (tree=0x81af240) at idl.c:1439
#10 0x2840082a in get_sequence_typecode (tree=0x81af600) at idl.c:1219
#11 0x2840158d in get_typecode (tree=0x81af600) at idl.c:1445
[...]

#s 5-11 will than repeat over and over again in the backtrace,
seeming to indicate that orbit-python gets itself into a loop while
parsing this.

This error happens for me with orbit-python 0.3.0, ORBit 0.5.8, on both
FreeBSD and NetBSD machines.

I hope this report gives enough info for someone with a knowledge of
idl.c; please let me know if you need more information (or would
rather I submit this to the bug-tracker instead of sending it here).

Thanks to all for orbit-python -- it has been really great to see all
the new features/improvements happening on it!

Brad

Re: [Orbit-python-list] Bonobo control example

[Michele C. <mol...@f2...>]

  Ok, your scripts (and mine, too) are working now. I was obviously
doing something wrong when launching them. Still don't know what...

  Now I'm going to add property bags and listeners... hoping for the
best...

  Thanks Johan

-- 

  -- Michele  -  www.moleskine.f2s.com

  "I haven't fucked much with the past,
   but I have fucked plenty with the future."

      -- Patti Smith, "Babelogue"

Re: [Orbit-python-list] Bonobo control example

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

tis 2001-08-28 klockan 13.12 skrev Michele Campeotto:
> Johan Dahlin wrote:
> >>   I didn't included it because it the same file from the tutorial.
> > Okay, but you would still have to change location in your factory, to
> > point it at control.py
> 
>    Yes, I had ipctrl.py in /tmp and /tmp/ipctrl.py in the .oaf
>    The main problem is that my scripts was working when usign a GtkLabel 
> in ipctrl.py (see my original code, it works).
>    Anyhow, will try yours when I get home.
> 
>    Thanks,
>    Michele


Oh, finally got it...
So if you'd used OAF_INFO_PATH python would showed a traceback when
it couldn't find gtkipentry module.

-- 
-------------------------------------------------
- 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] Bonobo control example

[Michele C. <mol...@f2...>]

Johan Dahlin wrote:
>>   I didn't included it because it the same file from the tutorial.
> Okay, but you would still have to change location in your factory, to
> point it at control.py

   Yes, I had ipctrl.py in /tmp and /tmp/ipctrl.py in the .oaf
   The main problem is that my scripts was working when usign a GtkLabel 
in ipctrl.py (see my original code, it works).
   Anyhow, will try yours when I get home.

   Thanks,
   Michele
-- 
   Michele - www.moleskine.f2s.com

Re: [Orbit-python-list] Bonobo control example

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

tis 2001-08-28 klockan 13.04 skrev Michele Campeotto:
> Johan Dahlin wrote:
> > And the thing that your forgot:
> > GNOME_BonoboTutorial_IPCtrl_Control.oaf
> 
>    I didn't included it because it the same file from the tutorial.
> 
Okay, but you would still have to change location in your factory, to
point it at control.py

> > Bonobo uses oaf for activation of objects.
> > This is done by a daemon, called oafd.
> [... snipped lots of good info...]
> > You'll have to kill oafd to make oaf use the new variables.
> > OAF_DEBUG_OUTPUT is also a good idea so you can see what's going on.
> 
>    Didn't know about OAF_DEBUG_OUTPUT, thanks.
> 
> > Nothing silly about the questrions, since you probably newer heard
> > of oaf before :)
> 
>    I did know OAF and I also restarted it thousands of times to make my 
> control work, but with no success (it wilked with a GtkLabel or a plain 
> GtkEntry, though).
> 
>    Have you run the scripts? There is a syntax error in container.py:
> def create_app ():
>      window = bonobo.BonoboWindow ('ipctrl-container',
>                                    'a container for ipctrl's')
> 
> there are three "'"! ;o)

Oops, i just fixed it up to make it look nicer :)
But yeah, i tried them.


> 
-- 
-------------------------------------------------
- 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] Bonobo control example

[Michele C. <mol...@f2...>]

Johan Dahlin wrote:
> And the thing that your forgot:
> GNOME_BonoboTutorial_IPCtrl_Control.oaf

   I didn't included it because it the same file from the tutorial.

> Bonobo uses oaf for activation of objects.
> This is done by a daemon, called oafd.
[... snipped lots of good info...]
> You'll have to kill oafd to make oaf use the new variables.
> OAF_DEBUG_OUTPUT is also a good idea so you can see what's going on.

   Didn't know about OAF_DEBUG_OUTPUT, thanks.

> Nothing silly about the questrions, since you probably newer heard
> of oaf before :)

   I did know OAF and I also restarted it thousands of times to make my 
control work, but with no success (it wilked with a GtkLabel or a plain 
GtkEntry, though).

   Have you run the scripts? There is a syntax error in container.py:
def create_app ():
     window = bonobo.BonoboWindow ('ipctrl-container',
                                   'a container for ipctrl's')

there are three "'"! ;o)

-- 
   Michele - www.moleskine.f2s.com

Re: [Orbit-python-list] Bonobo control example

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

Hi.

I attached 4 files:

container.py: Container
ipctrl.py: Component with a control
gtkipentry: Your class.

And the thing that your forgot:
GNOME_BonoboTutorial_IPCtrl_Control.oaf

Bonobo uses oaf for activation of objects.
This is done by a daemon, called oafd.
Everytime you use a component you must have i registred in oaf.
To add your own component, create an .oaf file.
In this example we'll need two oaf servers,
A factory which is used to create objects and a control.
The factory is called GNOME_BonoboTutorial_IPCtrl_ControlFactory and
the control is called GNOME_BonoboTutorial_IPCtrl_Control.
Oaf searches in $prefix/share/oaf for servers.
If you want you can specify new search locations by adding : separeted
fields in the OAF_INFO_PATH environment variable.

Lets have a closer look at the oaf file.
First create an oaf_server, with an iid, type could be factory, shlib or
exe, in python we're currently limited to factory and exe.
Location is used so oafd know where it can find the component, so
if you don't add the path you'll have to modify the PATH and kill oafd,
eg.
export PATH=$PATH:`pwd`
killall oafd

<oaf_server iid="OAFIID:GNOME_BonoboTutorial_IPCtrl_ControlFactory"
            type="exe"
            location="ipctrl.py">

  This is a factory and must support GNOME/ObjectFactory interface 
 
  <oaf_attribute name="repo_ids" type="stringv">
    <item value="IDL:GNOME/ObjectFactory:1.0"/>
  </oaf_attribute>

  Name of the component...

  <oaf_attribute name="name" 
                 type="string" 
                 value="Sample control factory"/>

  ... and description.

  <oaf_attribute name="description" 
                 type="string" 
                 value="Factory for the sample control"/>
</oaf_server>

And for the component:
Note that the name is ...Control, type is factory because the control
is launched through our factory... and location points at our factory.

<oaf_server iid="OAFIID:GNOME_BonoboTutorial_IPCtrl_Control" 
            type="factory"
           location="OAFIID:GNOME_BonoboTutorial_IPCtrl_ControlFactory">

        All components must suport Bonobo/Unknown.
        Our component does also support Bonobo/Control since it's
        a gui component.

        <oaf_attribute name="repo_ids" type="stringv">
                <item value="IDL:Bonobo/Unknown:1.0"/>
                <item value="IDL:Bonobo/Control:1.0"/>          
        </oaf_attribute>

        <oaf_attribute name="name" 
                       type="string" 
                       value="A Sample control in python"/>

        <oaf_attribute name="description" 
                       type="string" 
                       value="A sample Bonobo control."/>
</oaf_server>

So.
Copy all 4 files to a directoy.

export PATH=$PATH:`pwd`
export OAF_INFO_PATH=$OAF_INFO_PATH:`pwd`
export OAF_DEBUG_OUTPUT=1
killall -9 oafd

You'll have to kill oafd to make oaf use the new variables.
OAF_DEBUG_OUTPUT is also a good idea so you can see what's going on.

Nothing silly about the questrions, since you probably newer heard
of oaf before :)

-- 
-------------------------------------------------
- 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] Bonobo control example

[Michele C. <mol...@f2...>]

   Hi, back again with my silly questions...

   I was trying to translate the example from "On writing a Bonobo 
control" to Python and found that I cannot create a BonoboControl from a 
custom Python widget... well I can create the control, but the container 
cannot activate it.

   I have attached my experiments (please tell me if I'm annoying 
somebody with my attachements).

   All is working well if I create the control from a native Gtk+ widget 
(i.e. one implemented in the C extension), but using a Python class 
doesn't work... I have also tried to create a gtk.GtkWidget instance 
passing the object reference [ gtk.GtkWidget(_obj = w._o) ] but that 
didn't worked either...


-- 
   Michele - www.moleskine.f2s.com

Re: [Orbit-python-list] Hello, hints anyone?

[Michele C. <mol...@f2...>]

Christian Robottom Reis wrote:
>>Feel free to post bonobo-python related questions here until such a
>>time as Johan sets up a bonobo-python-list. :)
> 
> Yes, that would be nice, considering the AWFUL amount of traffic this
> list generates. :)

   Yeah, looked at the archives before posting and wondered if this was 
an announcements-oply list... ;)

-- 
   Michele - www.moleskine.f2s.com

Re: [Orbit-python-list] Hello, hints anyone?

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

On Sun, 26 Aug 2001, Jason Tackaberry wrote:

> > Err... my apologies if this is badly OT, hope to not have hurted people...
>
> Feel free to post bonobo-python related questions here until such a time
> as Johan sets up a bonobo-python-list. :)

Yes, that would be nice, considering the AWFUL amount of traffic this list
generates. :)

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

Re: [Orbit-python-list] Hello, hints anyone?

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

s_ 2001-08-26 klockan 21.35 skrev Michele Campeotto:
> On 26 Aug 2001 20:27:38 +0200, Johan Dahlin wrote:
> > It's really simple to create your own container with help of 
> > BonoboWidget:
> [code snipped]
> 
>   Yeah, this is what I see from the samples. But how I call methods on
> the BonoboWidget?
You can use:
object_client = control.get_server ()
object_client.query_interface (...) 
as you did or do it directly through CORBA:
control_corba = control.get_objref ()
control_corba.queryInterface (...)

>   I have attached what I have done so far (the example HTML is in
> italian, but I don't think this to be a problem ;).
> 
>   Am I on the right track? Is it right to directly import the interfaces
> I need or there is some other "automatic" way to do it?
>   How can I import the GNOME.GtkHTML.Editor.Engine interface without
> manually loading the IDL?
GtkHTML is broken.
GtkHTML installs idl-files in /usr/share/gtkhtml when it should install
idl files in /usr/share/idl.

When GtkHTML install it's files in the correct dir,
from GNOME.GtkHTML.Editor import Engine
should work just fine.

>   Why does the NautilusView example doesn't work? Is the problem in the
> sample code or in the wrapper?
Because newer versions of GtkHTML requires gconf and it's not wrapped in
python (yet).
But i might fix this by using the GtkHTML component in a container, so i
don't need to talk to GtkHTML directly.

> 
>   Sorry for putting so many questions on a single message, but I'm
> really excited about Bonobo-Python! I'd like to have a complete
> GNOME-Python development environment...
> 
> 
>   Thanks,
>   Michele
> 
>   P.S. How about moving Bonobo-Python development to SourceForge?
> 
Na, i like GNOME CVS, but i need to put up a separate mailing list soon
:)
-- 
-------------------------------------------------
- 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] Hello, hints anyone?

[Michele C. <mol...@f2...>]

On 26 Aug 2001 20:27:38 +0200, Johan Dahlin wrote:
> It's really simple to create your own container with help of 
> BonoboWidget:
[code snipped]

  Yeah, this is what I see from the samples. But how I call methods on
the BonoboWidget?
  I have attached what I have done so far (the example HTML is in
italian, but I don't think this to be a problem ;).

  Am I on the right track? Is it right to directly import the interfaces
I need or there is some other "automatic" way to do it?
  How can I import the GNOME.GtkHTML.Editor.Engine interface without
manually loading the IDL?
  Why does the NautilusView example doesn't work? Is the problem in the
sample code or in the wrapper?

  Sorry for putting so many questions on a single message, but I'm
really excited about Bonobo-Python! I'd like to have a complete
GNOME-Python development environment...


  Thanks,
  Michele

  P.S. How about moving Bonobo-Python development to SourceForge?

-- 

  -- Michele  -  www.moleskine.f2s.com

  "How many deaths will it take till he knows
   that too many people have died?"

      -- Bob Dylan, "Blowing in the wind"

Re: [Orbit-python-list] Hello, hints anyone?

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

s=F6ndag 2001-08-26 klockan 19.13 skrev Michele Campeotto:
>   Hello, I'm just starting to dive into ORBit-Python and the brand new
> Bonobo-Python and I'd like to thank all the nice guys involved.
>=20
>   Can anybody suggest me how to learn the path to develop a
> Bonobo-Python application?
>   I have already briefly read:
>     - On writing a Bonobo control, by Dirk-Jan C. Binnema
>     - Bonobo, by Miguel de Icaza
>     - all the docs found on orbit-python.sault.org
>     - the samples code
> but they seems to be mainly focused on Controls, while I want to write a
> container (I'd especially like to expand the gtkhtml.py example).
>=20
>   Back to studying, now...
>=20
>   Thanks,
>   Michele
>=20

Hi.

It's really simple to create your own container with help of=20
BonoboWidget:
----
import bonobo
import gtk

def idle ():
	window =3D gtk.GtkWindow ()
	window.connect ('delete_event', gtk.mainquit)=20

	uic =3D bonobo.BonoboUIContainer ()
	control =3D bonobo.BonoboWidget("OAFIID:Bonobo_Sample_Calculator",
                                       uic)
	window.add (control)
	window.show_all ()

gtk.idle_add (idle)
bonobo.main ()
---

For more information about BonoboWidget, look at.
http://developer.gnome.org/doc/API/bonobo/bonobo-bonobo-widget.html

This is documentation for C but most things applies to python too.


--=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] Hello, hints anyone?

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

> Err... my apologies if this is badly OT, hope to not have hurted people...

Feel free to post bonobo-python related questions here until such a time
as Johan sets up a bonobo-python-list. :)

Cheers,
Jason.

Re: [Orbit-python-list] Hello, hints anyone?

[Michele C. <mol...@f2...>]

Err... my apologies if this is badly OT, hope to not have hurted people...

-- 

  -- Michele  -  www.moleskine.f2s.com

  "How many deaths will it take till he knows
   that too many people have died?"

      -- Bob Dylan, "Blowing in the wind"

[Orbit-python-list] Hello, hints anyone?

[Michele C. <mol...@f2...>]

  Hello, I'm just starting to dive into ORBit-Python and the brand new
Bonobo-Python and I'd like to thank all the nice guys involved.

  Can anybody suggest me how to learn the path to develop a
Bonobo-Python application?
  I have already briefly read:
    - On writing a Bonobo control, by Dirk-Jan C. Binnema
    - Bonobo, by Miguel de Icaza
    - all the docs found on orbit-python.sault.org
    - the samples code
but they seems to be mainly focused on Controls, while I want to write a
container (I'd especially like to expand the gtkhtml.py example).

  Back to studying, now...

  Thanks,
  Michele

-- 

  -- Michele  -  www.moleskine.f2s.com

  "How many deaths will it take till he knows
   that too many people have died?"

      -- Bob Dylan, "Blowing in the wind"

Re: [Orbit-python-list] ORBit-Python 0.3.0 released!

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

Jason Tackaberry (2001-08-21 23:43:11 -0400) :

> After several months of heavy hacking and a couple months of lulls
> and laziness (we're all entitled), I'm happy to announce the release
> of ORBit-Python 0.3.0.

...and I'm happy to announce that the corresponding Debian package has
been uploaded to the Debian servers.  It should become available on a
mirror near you by tomorrow if you're using sid/unstable and in 10
days if you're using woody/testing (unless I do another upload in the
meantime).
-- 
Roland Mas

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

[Orbit-python-list] ANNOUNCE: bonobo-python 0.2.0

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

Bonobo-python 0.2.0 released.

Features:
* complete oaf bindings. (except async)
* bonobo bindings, including:
  * Factories
  * Components and containers
  * UI*
  * Fetching monikers (bonobo_get_object)
  * Listener and EventSource
* complete NautilusView bindings

Bonobo-python depends on ORBit-python 0.3.0.

bonobo-python can be downloaded at:
http://theta.lajnux.nu/bonobo-python/download.php

Screenshots, samples can be found at:
http://theta.lajnux.nu/bonobo-python/

[Orbit-python-list] ORBit-Python 0.3.0 released!

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

After several months of heavy hacking and a couple months of lulls and
laziness (we're all entitled), I'm happy to announce the release of
ORBit-Python 0.3.0.

The ORBit-Python site is:

   http://orbit-python.sault.org/

Download the 0.3.0 tarball at:

   http://orbit-python.sault.org/files/orbit-python-0.3.0.tar.gz


0.3.0 brings a lot of additions over the previous release:

  * Much improved compliance with the Python mapping specification:
      - _is_a, _is_equivalent, _hash, _non_existant, _narrow for 
        objrefs (PLMS §1.6)
      - CORBA.ORB_init: arguments optional (PLMS §1.6)
      - avoid collisions with python keywords (PLMS §1.2)
      - map octet sequences onto strings (PLMS §1.3.2)
  * CORBA exceptions overhaul; system exceptions are now raised and
    properly marshalled to the client
  * Object references implemented as class instances (useful for object 
    introspection) 
  * Automagically determines additional necessary DEFINEs for certain
    GNOME IDLs (Bonobo, for example).  (The CORBA._libidl_args hack is
    therefore no longer necessary in most cases.)
  * An API for extension modules.  Bonobo-Python, for example, relies on
    this.
  * A very excellent and comprehensive test suite using PyUnit that
    helps narrow down memory leaks and regressions.  (Hacked and
    beaten into submission by Christian Reis.)
  * All (known) memory leaks fixed!  This was a big obstacle for a lot 
    of people.
  * Started to create a set of examples to demonstrate ORBit-Python.
    Only 3 for now.  Contributions welcome. :)
  *  ... lots and lots of bugs fixed
  *  ... various optimizations
 
Note that ORBit 0.5.7 or later is required, since previous versions of
ORBit contained memory leaks.

My thanks are extended to the ORBit-Python development team for their
testing, coding, and perpetual nag^H^H^Hmotivation on IRC.  Aside from
myself, the team now consists of:

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


Please test out this latest release and report bugs at
http://bugzilla.sault.org/, email me, or catch me on #orbit-python on
irc.openprojects.net.  

Cheers,
Jason.