orbit-python-list

[Orbit-python-list] Uploaded patch

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

Well, I cleaned my patch a bit, but it still is about 14 kb, so I
don't post it here.  I uploaded it to the Sourceforge page:
<URL:http://sourceforge.net/patch/?func=detailpatch&patch_id=101182&group_id=3561>.

  Try it, have fun, send me comments and bug reports.

Roland.
-- 
Roland Mas

Au royaume des aveugles, les borgnes sont mal vus.

Re: [Orbit-python-list] Uploaded patch

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

>   Try it, have fun, send me comments and bug reports.

After a quick inspection it looks pretty good and cleans up a lot of the
pending FIXMEs.  A couple of your changes are a bit puzzling to me, but
I'll comb through it tonight and merge it in once I'm satisfied with it.
I'll also merge the rest of the patches, and possibly make some changes
to my namespace "intrusions."  Probably time for a new release soon.

Thanks,
Jason.

Re: [Orbit-python-list] Uploaded patch

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

Jason Tackaberry (2000-08-14 14:05:32 -0400) :

> A couple of your changes are a bit puzzling to me, but I'll comb
> through it tonight and merge it in once I'm satisfied with it.

I'd be glad to explain them.  Which ones?

>  I'll also merge the rest of the patches, and possibly make some
> changes to my namespace "intrusions."  Probably time for a new
> release soon.

  Cool.  Thanks.  I'll probably build a Debian package for it, and
convert it to an RPM one (with alien).  I'll send them to you for
publishing on the Sourceforge download zone, if you like.

Roland.
-- 
Roland Mas

  ()    Campagne du ruban ascii :
  /\    Contre les mails en HTML et les vcard !

Re: [Orbit-python-list] Uploaded patch

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

> I'd be glad to explain them.  Which ones?

Well, one of them was in client.c:stub_func() - I wasn't sure why you
needed to g_slist_free the newly removed link.  But then I went and checked
the documentation and there it was in black and white: "Removes an element
without freeing it."  Words cannot express how silly I feel.  Thanks for
catching that.

I'm not sure, however, why you removed this from client.c:set_attribute():

if (ad->mode == CORBA_ATTR_READONLY) {
   raise_system_exception("IDL:omg.org/CORBA/NO_PERMISSION:1.0", 0,
                          CORBA_COMPLETED_NO, "attribute %s readonly",
                          ad->name);
   return -1;
}

Yes checks should be done at the server end as well (I'll merge that patch
along with this one), but it certainly doesn't hurt to check at the client,
since it will potentially eliminate needless communication with the server.

>   Cool.  Thanks.  I'll probably build a Debian package for it, and
> convert it to an RPM one (with alien).  I'll send them to you for
> publishing on the Sourceforge download zone, if you like.

I would, yes.  Thanks. :)

Jason.

Re: [Orbit-python-list] Uploaded patch

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

Jason Tackaberry (2000-08-14 14:44:02 -0400) :

> I'm not sure, however, why you removed this from client.c:set_attribute():
> 
> if (ad->mode == CORBA_ATTR_READONLY) {
>    raise_system_exception("IDL:omg.org/CORBA/NO_PERMISSION:1.0", 0,
>                           CORBA_COMPLETED_NO, "attribute %s readonly",
>                           ad->name);
>    return -1;
> }

Um...  I'm not sure either :-)  Seriously, I probably cut too much by
mistake.  Sorry about that.

> Yes checks should be done at the server end as well (I'll merge that
> patch along with this one), but it certainly doesn't hurt to check
> at the client, since it will potentially eliminate needless
> communication with the server.

  Yep.  I'm eager to see it integrated, if you can figure out how to
send an exception, 'cause I couldn't.  Btw, the appropriate exception
would probably be NO_PERMISSION or NO_SUCH_METHOD (?), but I couldn't
find out which one either.

> >   Cool.  Thanks.  I'll probably build a Debian package for it, and
> > convert it to an RPM one (with alien).  I'll send them to you for
> > publishing on the Sourceforge download zone, if you like.
> 
> I would, yes.  Thanks. :)

  Just you release a tarball, I'll build and test the Debian package.
I can convert it to an RPM, but I have no Red Hat machine to test it,
so it will be untested.

  Ah, another thing.  Either I don't know how to free an object, or
there's another memory leak lurking somewhere.  I'm working on a test
suite I would be rather confident in, but in short and in my opinion,
the following code leaks memory (same ol' method, run it 100000 times
and count the bytes):

/---- CUT -----
| t2 = toto ()
| s2 = POA.truc.toto (t2)
| poa.activate_object (s2)
| ref = poa.servant_to_reference (s2)
| poa.deactivate_object (t2._servant)
\---- CUT -----

  I'm investigating into that, but if there's something known there
please tell me.

  And the last thing for this mail: I've been asked on
comp.lang.python if there were any plans to make ORBit-Python
OMG-compliant (about the mappings).  I quoted the webpage, but I'm not
really sure...  What is the status of that subproject?

Roland.
-- 
Roland Mas

[...] ou une dent pourrie [...] -- in Variations sur un thème imposé
  -- Signatures à collectionner, série n°2, partie 2/3.

Re: [Orbit-python-list] Uploaded patch

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

> Um...  I'm not sure either :-)  Seriously, I probably cut too much by
> mistake.  Sorry about that.

Ahh okay, no problem.

> send an exception, 'cause I couldn't.  Btw, the appropriate exception
> would probably be NO_PERMISSION or NO_SUCH_METHOD (?), but I couldn't
> find out which one either.

Okay, I'll make these changes.

>   Just you release a tarball, I'll build and test the Debian package.
> I can convert it to an RPM, but I have no Red Hat machine to test it,
> so it will be untested.

That's okay, I can test it.  If it's too broken, I can just make a spec
file for ORBit-Python, which is something I've been meaning to do.

> suite I would be rather confident in, but in short and in my opinion,
> the following code leaks memory (same ol' method, run it 100000 times
> and count the bytes):

I'm not sure at this point what you've fixed and what you haven't.  So
after you submit your patch tomorrow, can you send examples on how to
produce all the remaining leaks you've discovered?

>   And the last thing for this mail: I've been asked on
> comp.lang.python if there were any plans to make ORBit-Python
> OMG-compliant (about the mappings).  I quoted the webpage, but I'm not
> really sure...  What is the status of that subproject?

I do address this (somewhat) in my thesis document.  In short, yes I do
wish to make the mappings OMG compliant where it makes sense.  I seem to
recall some of the mappings in the specification not making sense for the
approach I took (dynamic IDL).

Some things will be easy to implement, such as the attribute accessor
pairs.  I read some discussions on why one should favor accessor functions
versus operator overloading, but these arguments just don't apply to
ORBit-Python because of its dynamic approach.  I do discuss this in my
thesis paper, so it may be worth reading (the latter two chapters) for
my rationale.  In the end, I wish to have both methods.  I can imagine
there are pretty good arguments for just using the accessor pairs, but
the current method is just damn cool and just as efficient.

Alas, the mapping specification and much of my line of thinking is a bit
fuzzy to me lately, since I've not been working on this project for some
time.  So I'm hesitant to say much more than that until I can refamiliarize
myself.  I'm also no CORBA expert, and am perfectly prepared to insert my
foot deeply inside my mouth when some CORBA god sparks a revelation about
why things are the way they are. :)

Regards,
Jason.