orbit-python-list

[Orbit-python-list] Uploaded small patch

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

I uploaded onto Sourceforge a small patch to src/server.c that
allows the user to define her own _get_* / _set_* accessor pairs.  If
the methods are not present, then the usual PyDict_GetItemString /
PyDict_SetItemString methods are used.

  I haven't really tested this patch.  I don't really know if it's
spec-compliant or not either, that's why I did not commit it directly
to CVS, since everything is under a major overhaul.

  This patch is against CVS current 2000-08-22, 08:00 UTC
(src/server.c revision 1.5).

Roland.
-- 
Roland Mas

Magic is one thing, and reflected-sound-of-underground-spirits is another.
  -- Twoflower, in The Colour of Magic (Terry Pratchett)

[Orbit-python-list] Updates

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

The latest batch of commits represent a pretty significant code overhaul.
There's lots of old code still to remove, and some bugs/leaks to fix
still.  Here is the ChangeLog excerpt:

   * Completely rewrote the way IDL objects are handled internally to
     more closely comply with the spec.  (IDL modules are Python modules,
     interfaces are classes, etc.)
   * inheritance is now supported, as well as delegation.  Inheritance is
     preferred since the spec (while vague) seems to require it, whereas
     delegation is optional.
   * Complies with the mapping spec on mappings for module names.  import
     Module for client side, import Module__POA for server side.
   * servants support implicit activation through _this()
   * deprecated POA::the_POAManager in favor of POA::_get_the_POAManager()
   * Uses _GlobalIDL and _GlobalIDL__POA modules for the global IDL scope,
     which is compatible with omniORBpy and Fnorb.
   * Implemented preprocessing of IDL files at runtime to determine which
     IDL files offer which modules.  Implications on performance are yet
     to be determined.  This approach may not scale very well at all for
     hundreds of IDL files.  It also could be broken in some cases; the
     preprocessor is not a complete IDL parser, so it may not work 100%.
     Time shall tell.  Uses the IDLPATH environment variable to get a
     list of paths to scan, otherwise defaults to the current directory.
   * hook __import__ to automagically load IDL files discovered by the
     processor that are required for the requested module
   * Pass -D__ORBIT_IDL__ -D__BONOBO_COMPILATION to libIDL so that we can
     load Bonobo IDLs
   * introduced more memory leaks, and probably more bugs.

The IDL directory preprocessor is a particularly interesting addition, and
it remains to be seen if this approach won't completely flop.  For me, at
least, it works pretty well, but my setup is somewhat limited (basically
just GNOME with Bonobo).  On my system it takes about 0.30 seconds to
preprocess 3 directories with about 50 IDL files, and 0.04 seconds once
cached.

Please report bugs as I'm not aware of any.  The leaks should be plugged 
in the next few days, however.

Jason.

Re: [Orbit-python-list] Latest commits

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

> Yup.  Quick tests show zero leak.  Thanks a bundle!  I'll have to

Good news.  Now all the changes I made over the weekend (massive
changes with the server side especially) have introduced other leaks.
I'll track these down today or tomorrow.

> update my main project since I relied on the ._servant attribute hack,
> but thanks to my limitless faith in encapsulation, there should be
> three lines to change in my code, and not three thousand.

More code breaking changes are still to come, unfortunately.  The
good news is the updates bring us closer to compliance with the spec,
and that the changes needed shouldn't be too drastic.  Such are the
perils of working with non-stable releases, I guess. :)  

After all is said and done, we should meet the spec as closely as possible.
Currently both inheritance and delegation is supported for implementations.
I interpreted the spec to say that inheritance is required while
delegation is optional.  Also, where things the spec is not too clear
on (such as _GlobalIDL), I'll copy omniORBpy.  At least then we'll be
as compatible as possible.

>   And since 1. the code is apparently liable to change a bit these
> days and 2. I've been working more on ORBit-Python than on Real Work
> these days, I'll probably be rather quiet on this front this week or

Just as well, I'll probably be tearing the whole thing apart. :)

> a bug or another leak, though :-)  That's the problem you'll have,
> since my server will have to handle about a million objects and about
> a million requests a day, any memory leak is forbidden, so I'll submit
> patches and/or bug you until the last leak is dead.

Interesting.  So what exactly are you using ORBit-Python for? 

>   Speaking of patches, I suggest you close the appropriate patches
> from the Sourceforge page, so as not to confuse people who might be
> tempted to apply them on the CVS version.

Yeah, I hadn't forgotten about that, just kept putting it off. :)  Thanks 
for the reminder.

Jason.

Re: [Orbit-python-list] Latest commits

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

Jason Tackaberry (2000-08-18 20:47:07 -0400) :

> This commit represents a great number of leaks plugged.  Also, I'm
> amazed the POA worked as well as it did; activate_object,
> deactivate_object, and the servant's destructor were not done
> properly at all.  Things should be working now.  Roland, please bang
> on this one and let me know if you find anymore leaks.

Yup.  Quick tests show zero leak.  Thanks a bundle!  I'll have to
update my main project since I relied on the ._servant attribute hack,
but thanks to my limitless faith in encapsulation, there should be
three lines to change in my code, and not three thousand.

  I'm, er, sorry for the ChangeLog file.  I'm just not used to
maintain one (too much CVS is bad for you, I guess).  I'll try to
remember for next time I commit things.

  And since 1. the code is apparently liable to change a bit these
days and 2. I've been working more on ORBit-Python than on Real Work
these days, I'll probably be rather quiet on this front this week or
so (I'll be on the IRC though).  Trust me to come back if I encounter
a bug or another leak, though :-)  That's the problem you'll have,
since my server will have to handle about a million objects and about
a million requests a day, any memory leak is forbidden, so I'll submit
patches and/or bug you until the last leak is dead.

  Speaking of patches, I suggest you close the appropriate patches
from the Sourceforge page, so as not to confuse people who might be
tempted to apply them on the CVS version.

Roland.
-- 
Roland Mas

Time passed, which, basically, is its job.
  -- in Equal Rites (Terry Pratchett)

Re: [Orbit-python-list] Does not compile :-/

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

> I sure did!  Boy do I feel silly! :)

Oops.  When I committed the addition, I also accidentally committed a
bunch of incredibly experimental changes (moving toward more compliance
with the mapping spec).  Fortunately the changes I made shouldn't break
anything, but you'll see a bunch of extra debugging output that you can
ignore.

This will hopefully be fixed up in the next couple days.  It probably won't
be worth it to make any changes to the source tree; things will be in a 
state of flux for the next little while.

Jason.

Re: [Orbit-python-list] Does not compile :-/

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

> no such thing as a src/PortableServermodule.c.  Forgot to 'cvs add'
> it?

I sure did!  Boy do I feel silly! :)

Jason.

[Orbit-python-list] Does not compile :-/

[Roland M. <rol...@fr...>]

Latest CVS version does not compile.  Make complains about not finding
any way to build PortableServermodule.o.  And, sure enough, there is
no such thing as a src/PortableServermodule.c.  Forgot to 'cvs add'
it?
-- 
Roland Mas

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

[Orbit-python-list] Latest commits

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

Here is an excerpt from the ChangeLog:

   * PortableServer.c: fixed a leak in activate_object(); implemented
     reference_to_servant(); removed deprecated method RootPOA(); removed
     the _servant attribute from servant implementation instances (this
     was a hack anyway)
   * marshal.c: fixed a leak in marshal_sequence and marshal_struct
   * CORBAmodule.c: changed CORBA_Object_to_PyObject_hash to hash on
     addresses, not typecodes; CORBA_PyObject__dealloc now properly frees
     the CORBA object; moved PortableServer module initialization into a
     separate file and module (PortableServermodule.c)
   * server.c: freeing a servant will deactivate it if necessary; fixed
     various leaks and bugs with the servant destructor; fixed a leak with
     exceptions in operation_skel; new_poa_servant adds new servants to the
     CORBA_Object_to_PyObject_hash so they can be fetched by reference_to_
     servant()
   * fixed CORBA_Environment leaks all over the place
   * fixed a few other leaks that I can't remember 
   * various debugging information added; the debug level is inconsistent
     all over the place -- this will need to be fixed.
   * removed Instance::throw_away function from test-suite.idl, replaced
     with Factory::discard_instance(); some other small changes to the
     test server and clients.

This commit represents a great number of leaks plugged.  Also, I'm
amazed the POA worked as well as it did; activate_object, deactivate_object,
and the servant's destructor were not done properly at all.  Things should
be working now.  Roland, please bang on this one and let me know if you
find anymore leaks.

I'd like to now focus my attention on standards compliance.  I'm going
to play with the idea for that "black magic" IDL directory scanning at
load time and see how that performs.  I'm tempted to say there won't be
a significant performance penalty, but we shall see.

Jason.

Re: [Orbit-python-list] Committed my fixes to CVS

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

>    // This really is a hack and will likely eventually go away.  This
>    // attribute is a borrowed reference.
>    Py_DECREF(servant);

Apparently this "fix" breaks other places.  I'm working on it.

Re: [Orbit-python-list] Implementation questions

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

On Friday 18 August, Jason Tackaberry wrote:

> First, for interfaces that are not encompassed in modules, I notice that
> you use a _GlobalIDL module.  I didn't see this point addressed in the
> mapping specification, so I assume this is a solution specific to omniORBpy?

Well, the specification actually says

  "Other global definitions (except modules) appear in a module whose
   name is implementation dependent. Implementations are encouraged to
   use the name of the IDL file when defining the name for that
   module."

As you say, omniORBpy uses "_GlobalIDL", not the name of the IDL file.
The second sentence I've quoted above was not in drafts of the
mapping, so I followed the precedent set by Fnorb, which also uses
_GlobalIDL.

There is also a technical reason for not doing what it says. I should
probably submit an issue about it to the OMG. Consider two IDL files:

  // a.idl
  struct S {
    long l; string z;
  };

  // b.idl
  #include "a.idl"
  interface I {
    S op();
  };

Now, if we follow the "encouraged" mapping, the definition of struct S
lives in Python module "a", while the definition of interface I lives
in Python module "b". But the definition of interface I relies on the
definition of struct S, which it expects to be in the same module. The
advantage of using a fake module name like "_GlobalIDL" is that
definitions which are in the same IDL scope are always in the same
Python scope.

omniORBpy's IDL compiler has an option to change the global module
name, so you can force it to follow the "encouraged" mapping if you
want to.

> The way I would want to approach the problem is to use the same scoping
> rules as regular modules.  So,
> 
> interface Echo {
>    // ...
> };
> 
> I would favor simply:
> 
>    import Echo

That can't work, since the result of import has to be a Python module.
In the example of an interface declared at global scope, that doesn't
necessarily matter (since the Python mapping for interfaces is
flexible enough that Echo could be a module), but with the struct in
a.idl above, the mapping says that S must be a Python class. I don't
think you can reconcile that with the use of import for things in
global scope.


> Also, the specification seems a little vague about inheritance vs.
> delegation.  In particular, I'm not sure if implementing interfaces
> through inheritance is required while delegation is optional, or if you
> can get away with one or the other (or both).  I chose delegation because
> inheritance was just too tricky.  Deriving a class object created from C
> is impossible, and achieving that functionality would require using something
> like Jim Fulton's ExtensionClass.  Delegation was the clear winner for the
> dynamic IDL approach I took.  So, if I want to adhere to the specifications,
> is implementation through inheritance required, strongly recommended, or
> optional?

I had always read the mapping as saying that inheritance was
mandatory. However, looking at it again, it does indeed look like it
makes it optional. In fact, it seems to make everything about the
server side mapping optional, which is a bit silly. I think the
_intention_ of the mapping is that inheritance is mandatory, but I'm
not at all sure. At the very least, I would say that it's strongly
recommended. Perhaps you should submit an issue to the OMG (email to
is...@om...) to get it clarified. If you email to do...@py...
too, the people who wrote the mapping will be able to comment.

If the mapping is intended to allow delegation, it fails to specify
the naming scheme for the tie class (or types in your case). That
should be standardised, just as the scheme for skeleton class names is
standardised.

If it turns out that inheritance _is_ mandatory, I don't think it will
be too much of a problem for you. The skeleton class does not have to
be very complicated. My guess is that it wouldn't be too hard to
dynamically create a new class with PyClass_New(), and fill in the
bits you need with the PyObject_... functions, all from C code.

If that's too hairy, you can write Python functions to create classes
for you, and call those functions from C code. omniORBpy does
something similar when it is unmarshalling TypeCodes for structs and
unions which is does not have stubs for -- the C++ code calls the
Python omniORB.createUnknownStruct() and omniORB.createUnknownUnion()
functions. Those functions create new classes and return them back to
C++.

I'm afraid you're discovering that complying with standards is a
rather painful process...

Cheers,

Duncan.

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

[Orbit-python-list] Implementation questions

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

I'm refamiliarizing myself with the mapping specification, and after looking
at omniORBpy, I've a few questions.

First, for interfaces that are not encompassed in modules, I notice that
you use a _GlobalIDL module.  I didn't see this point addressed in the
mapping specification, so I assume this is a solution specific to omniORBpy?

The way I would want to approach the problem is to use the same scoping
rules as regular modules.  So,

interface Echo {
   // ...
};

I would favor simply:

   import Echo

I'm not sure if you chose to use _GlobalIDL because of complexities in
implementing it this way, or if there are good reasons not to do it this
way that I can't think of.  I thought it'd be best to ask you first. :)

Also, the specification seems a little vague about inheritance vs.
delegation.  In particular, I'm not sure if implementing interfaces
through inheritance is required while delegation is optional, or if you
can get away with one or the other (or both).  I chose delegation because
inheritance was just too tricky.  Deriving a class object created from C
is impossible, and achieving that functionality would require using something
like Jim Fulton's ExtensionClass.  Delegation was the clear winner for the
dynamic IDL approach I took.  So, if I want to adhere to the specifications,
is implementation through inheritance required, strongly recommended, or
optional?

Thanks,
Jason.

Re: [Orbit-python-list] Committed my fixes to CVS

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

> night that was, with only half as much progress as I would have liked.
> Anyway I committed my changes up to 2000-08-18 08:18 UTC+2, so you can
> pull it from CVS.

Good stuff. :)

> leaks have been fixed".  Darn me, I spent a huge part of the night
> trying to see why CORBA_PyObject__dealloc wouldn't free the memory
> allocated for an object reference by a call to
> poa.servant_to_reference(), before I realised that this function
> wasn't called.  For some reason, the reference object thusly allocated
> is never freed, or its destructor is never called, or its refcount is

I haven't been able to reproduce this behaviour.  At least, with this
code:

    servant = POA.Fruit.Factory(Factory())
    poa.activate_object(servant)
    ref = poa.servant_to_reference(servant)

CORBA_PyObject__dealloc is being called.

However, in investigating this, I did run into a problem that servants
were not being freed, not because of servant_to_reference(), but because
of activate_object().  So it seems to me that the supposed
servant_to_reference() problem was a bit of a red herring (although
there still could be a problem there).

The problem in activate_object() was that I was setting the servant
object as an attribute of the implementation instance (_servant) which
INCREFed the servant object, and since the destructor for the impl class
wasn't freeing it, it was left in limbo.

Of course, the _servant attribute was just a hack until I could figure
out how things are supposed to work, but it just got left in there.  I
updated the code:

   // create a _servant attribute in the implementation instance.
   // This really is a hack and will likely eventually go away.  This
   // attribute is a borrowed reference.
   Py_DECREF(servant);
   PyObject_SetAttrString(servant->servant->impl, "_servant",
                          (PyObject *)servant);

Servants are now correctly being freed.  The ref object returned by
poa.servant_to_reference() is being freed properly (at least, CORBA_
PyObject__dealloc is invoked), so I can't reproduce what you described
above.  If the problem persists, can you send me a snippet of code to
repreoduce it?

Incidentally, I added you to the AUTHORS file and updated the ChangeLog.
Don't forget to update ChangeLog when you make commits.

Thanks,
Jason.

Re: [Orbit-python-list] Uploaded patch

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

> > The mapping standard says that it must be possible to do just "import
> > CORBA", and get the default CORBA installation, so with compliant ORBs
> 
> I suppose that means installing a new ORB will clobber the existing CORBA
> module?  

Yes, to the extent that "import CORBA" will now get the new ORB. If
all the ORBs stick to the "from foo import CORBA" practice, and use a
wrapper module to support "import CORBA", all installed ORBs will
still be available for programs which care.

> > you do not need to change any code at all. This is one aspect of the
> > Python mapping which caused headaches for me with omniORBpy, since
> > it's geared towards the "from omniORB import CORBA" style. I have to
> 
> What headaches has it caused?  Why wouldn't just a simple wrapper to import
> omniORB.CORBA work?

Maybe "headache" is too strong a word. It isn't a good idea for
CORBA.py to just say "from omniORB.CORBA import *", firstly because
omniORB.CORBA contains some important items prefixed with underscores,
which do not get imported with import *. Secondly, that approach
wastes memory since it fills a second dictionary with the names of the
module's contents.

omniORBpy's CORBA.py actually looks like

  import sys, omniORB.CORBA
  sys.modules["CORBA"] = omniORB.CORBA

which is a bit of a dirty hack. It's a module which replaces itself
while it's still being imported.

> Anyway, it may be worth it for me to post these issues to comp.lang.python
> and spark a discussion.  I'm humble enough to take advice from people who
> know much more than I do. :)

Maybe. It might be better to discuss it in do...@py....
Unfortunately, now that the Python mapping is an official CORBA
standard, it's pretty much set in stone. It can be extended or fixed
for bugs, but it will be very hard to have it changed.

Cheers,

Duncan.

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

[Orbit-python-list] Committed my fixes to CVS

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

  Good day to you,

  The Sun is rising above the hills of Sophia-Antipolis, the so-called
French Silicon Valley, and it's time for me to call it a day.  Hard
night that was, with only half as much progress as I would have liked.
Anyway I committed my changes up to 2000-08-18 08:18 UTC+2, so you can
pull it from CVS.

  Here is the change log between the official 0.1.3 release and what
I'd be tempted to call 0.1.3rm3 but we'll stick to 'CVS current':

 * Many memory leaks fixed by making static things that were
   previously dynamically created and sometimes not deleted.
 * Some segfault-inducing bugs also fixed.
[This is referring to the one I mentioned yesterday.]
 * Some FIXMEs done.
 * The occasional code cleaning.
 * I, er, took the liberty of inserting some Emacs-friendly commands
   at the end of the files I modified, for the sake of coding style
   coherence :-)

  Now what *isn't* in this change log: the word "all" in "all memory
leaks have been fixed".  Darn me, I spent a huge part of the night
trying to see why CORBA_PyObject__dealloc wouldn't free the memory
allocated for an object reference by a call to
poa.servant_to_reference(), before I realised that this function
wasn't called.  For some reason, the reference object thusly allocated
is never freed, or its destructor is never called, or its refcount is
incremented once too much or decremented once not enough, whatever.
I've been turning the source in every way I could, and I couldn't find
why, and that makes me not happy at all.  (Hint: I'm begging for
exterior help here...)

  Feedback is highly appreciated, of course :-)

  Ladies and Gentlemen, I wish you a pleasant week-end.

Roland.
-- 
Roland Mas

Luck, like an old car, works better if you push it.
  -- Regalian, in My Hero (Tom Holt)

[Orbit-python-list] Status update

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

  It's getting like a habit :-)  Today's batch of (mostly good) news
about ORBit-Python:

- as far as I can tell, there only subsists one memory leak.  Every
  time you invoke poa.servant_to_reference, you leak some hundreds of
  bytes.  How much precisely depends on how your ORBit is configured
  (/etc/orbitrc allows you to activate IIOP on IPv4, IIOP on IPv6 and
  Unix sockets for your CORBA communications).  If you have IIOP on
  IPv4 and Unix sockets, that'll be 451 bytes, plus or minus one byte
  (don't ask me why).  For every call to poa.servant_to_reference ().
  I'm investigating that point, but I have to admit I feel a bit stuck
  there.  Maybe when it's a decent time of the day I'll be more
  inspired...  Anyway, the IOR profiles thingy gives me a lead to
  investigate.

- other leaks have been fixed, mainly the one about instanciating,
  activating and deactivating objects.  No leak there that I can see.

- there's a bug somewhere causing segmentation faults.  If you take
  the test suite I posted yesterday, and run it as is, you'll probably
  run into a segfault in the server when calling the
  create_and_destroy () method (run './client 10000 c').  Apparently,
  using a global new_instance (as suggested by the comment) is a
  workaround, but I don't like that either.

- fixed another bug somewhere in client.c (I think) that DECREF'ed an
  object once too much, resulting in segfaults too.

- I haven't done any benchmarks yet, but I suspect there'll be a
  slight performance increase, since I made plenty of things static
  when they were dynamic.  Of course, the static memory usage went up
  to compensate, but if we consider that the leaks have been
  plugged...  Oh well, it should be stable first.

Have a nice day, or night, or whatever it's called on your planet.

Roland.
-- 
Roland Mas

Using a big hammer without caution can cause big damage.
  -- PostgreSQL documentation, chapter 42

Re: [Orbit-python-list] Uploaded patch

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

> Why are Python modules considered excess baggage when the IDL itself
> isn't?  

Well, better worded as "seemingly unnecessary excess baggage."  I think
there might be a cleaner solution to the problem, that's all.  In case
there isn't, though, I'm willing to do whatever's necessary to adhere to
the mapping specification.  I do think it's important.

> As Martin von Loewis (the main author of the Python mapping)
> asks in comp.lang.python, how do you find the IDL file referenced by
> 
>   CORBA.load_idl("naming.idl")
> 
> Do you look on PYTHONPATH?  Some other IDL search path?  Just the
> current directory?  What about files #included in the file you load?

This is one of those unresolved issues that I decided to worry about
"later" while writing it.  I knew right away that load_idl() was a hack,
but it seemed the most obvious approach for dynamic IDL loading, and it's
also the way Owen Taylor's CORBA::ORBit (perl bindings) implemented it,
from which ORBit-Python was heavily based.

> I'm not saying that dynamic loading of IDL is always wrong (I've
> implemented it for omniORBpy after all), just that it isn't always
> ideal.

Well, ORBit-Python has no idl compiler, and I don't see that changing
soon (I've no motivation to write one), so I'll have to find some way to
massage this approach into complying with a specification that was written
with other intentions.

It does sound as though some magic is going to have to happen when importing
the CORBA module.  Suppose it fetches some sort of dictionary of IDL
modules that maps module and interface names to IDL files.  Then when
importing a module, it could first check this dictionary and call load_idl()
if such a mapping exists.  Of course there's lots of problems with this sort
of approach.  Either it means some sort of specific registry that users
will have to add IDL files to, or it means some overhead to scan through 
known IDL directories to generate this mapping at runtime.

> The mapping standard says that it must be possible to do just "import
> CORBA", and get the default CORBA installation, so with compliant ORBs

I suppose that means installing a new ORB will clobber the existing CORBA
module?  

> you do not need to change any code at all. This is one aspect of the
> Python mapping which caused headaches for me with omniORBpy, since
> it's geared towards the "from omniORB import CORBA" style. I have to

What headaches has it caused?  Why wouldn't just a simple wrapper to import
omniORB.CORBA work?

> Much more ugly, I agree. But how many people would assume that it
> prints 3?  It's much more obvious that something other than simple
> assignment is going on. I think that is a good thing, and worth the
> uglifying syntax.

Since ORBit-Python implements the accessor pairs now, users will have a
choice.  And your arguments are strong ones in favor of using that style,
but so long as both methods are available, I think everyone will be happy.
:)

Anyway, it may be worth it for me to post these issues to comp.lang.python
and spark a discussion.  I'm humble enough to take advice from people who
know much more than I do. :)

Jason.

Re: [Orbit-python-list] Uploaded patch

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

On Wednesday 16 August, Jason Tackaberry wrote:

> But it also means you have to carry around excess baggage, which is one of
> the nicely avoided by dynamic IDL.  While I'll concede this is going to
> require some hack, I'd prefer whatever hack we choose to be simple and
> minimally intrusive.

Why are Python modules considered excess baggage when the IDL itself
isn't?  As Martin von Loewis (the main author of the Python mapping)
asks in comp.lang.python, how do you find the IDL file referenced by

  CORBA.load_idl("naming.idl")

Do you look on PYTHONPATH?  Some other IDL search path?  Just the
current directory?  What about files #included in the file you load?

I'm not saying that dynamic loading of IDL is always wrong (I've
implemented it for omniORBpy after all), just that it isn't always
ideal.

> A small degree of source editing is required to use a different ORB
> anyway (for example by changing the 'from ORB import CORBA' line), so I
> could require that CORBA.load_idl be invoked immediately after importing
> the CORBA module, and then override import (using __import__) to ignore
> modules that exist from the IDLs.  So, something like:

The mapping standard says that it must be possible to do just "import
CORBA", and get the default CORBA installation, so with compliant ORBs
you do not need to change any code at all. This is one aspect of the
Python mapping which caused headaches for me with omniORBpy, since
it's geared towards the "from omniORB import CORBA" style. I have to
do a bit of cunning module manipulation to support "import CORBA".

That aside, you don't need to modify import's behaviour at all. As
long as load_idl puts the modules in sys.modules, future imports for
those modules will use the ones which have already been loaded.


[...attributes...]
> > involves a remote call, and can raise any of the CORBA system
> > exceptions. I think it's far better to make it look like what it is: a
> > method invocation.
> 
> Well I'd considered this, but I think the elegance, simplicity, and
> readability of the 'interface.attr = foo' approach are good arguments as
> well, and I would favor this when using ORBit-Python for situations where
> using ORBit makes sense (in a Gnome application, say).  All the arguments
> are perfectly legit, and I admit I'm a little torn about the issue.

My argument is that "interface.attr = foo" is _less_ readable than
"interface._set_attr(foo)", since the former does not make it clear
that an operation invocation is being made.

Take the following piece of code:

  obj.foo = 1
  obj.foo = obj.foo + 2
  print obj.foo

What does it do?  At first glance, most people would assume that it
prints 3. But if obj is a CORBA object, there is no way of telling,
because the get and set operations underlying the attribute may not be
treating it like a genuine data member. Even if it is just a data
member, some other client might concurrently modify the attribute at
any stage between the four remote calls.

Of course, Python is flexible enough that all the same problems can
arise in a single non-CORBA program, if you design classes which are
sufficiently perverse and use threads. But people don't do that --
it's not the Python way. It just makes code hard to understand. Now
consider the following code:

  obj._set_foo(1)
  obj._set_foo(obj._get_foo() + 2)
  print obj._get_foo()

Much more ugly, I agree. But how many people would assume that it
prints 3?  It's much more obvious that something other than simple
assignment is going on. I think that is a good thing, and worth the
uglifying syntax.

Anyway, enough of my ranting.

Cheers,

Duncan.

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

Re: [Orbit-python-list] Uploaded patch

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

> severely weakened by the fact that none of the other Python ORBs
> support it. I believe that this disagreement between ORBs will put
> people off from using Python with CORBA.

I'm all for working to reach standards compliance.  I definitely see the
advantage being able to run python code across different ORBs with few
changes.  Unfortunately I fear this is going to require some pretty
horribly ugly hacks.

> with "import M". One way around this is to write small modules which
> do nothing but call CORBA.load_idl(). A simple IDL compiler fragment
> which just wrote such modules would comply with the mapping
> requirement, while keeping the general dynamic IDL approach.

But it also means you have to carry around excess baggage, which is one of
the nicely avoided by dynamic IDL.  While I'll concede this is going to
require some hack, I'd prefer whatever hack we choose to be simple and
minimally intrusive.

A small degree of source editing is required to use a different ORB
anyway (for example by changing the 'from ORB import CORBA' line), so I
could require that CORBA.load_idl be invoked immediately after importing
the CORBA module, and then override import (using __import__) to ignore
modules that exist from the IDLs.  So, something like:

from ORBit import CORBA                      # ORB specific
CORBA.load_idls('M.idl', 'foo.idl')          # ORB specific
import M                                     # ignored by __import__
import foo                                   # ignored by __import__

Thus, someone who switches from ORBit-Python to omniORBpy, say, can just
change the first line, and delete the second.

> involves a remote call, and can raise any of the CORBA system
> exceptions. I think it's far better to make it look like what it is: a
> method invocation.

Well I'd considered this, but I think the elegance, simplicity, and
readability of the 'interface.attr = foo' approach are good arguments as
well, and I would favor this when using ORBit-Python for situations where
using ORBit makes sense (in a Gnome application, say).  All the arguments
are perfectly legit, and I admit I'm a little torn about the issue.

Although, thanks to Roland Mas' efforts, ORBit-Python supports the accessor
pairs now.  

Regards,
Jason.

Re: [Orbit-python-list] Uploaded patch

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

On Tuesday 15 August, Jason Tackaberry wrote:

I was the one who asked about standards compliance in
comp.lang.python. I'm also the author of omniORBpy, which fully
adheres to the mapping. I think the value of the standard is being
severely weakened by the fact that none of the other Python ORBs
support it. I believe that this disagreement between ORBs will put
people off from using Python with CORBA.

Please don't interpret this email as an attempt to get people to use
omniORBpy. I would genuinely like to see ORBit-Python improve in all
ways, including its standards support. The more good Python ORBs there
are, the more incentive there is for all of us to keep improving them.

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

The only thing I can see that potentially causes difficulty is the
mapping requirement that IDL module "M" can be accessed from Python
with "import M". One way around this is to write small modules which
do nothing but call CORBA.load_idl(). A simple IDL compiler fragment
which just wrote such modules would comply with the mapping
requirement, while keeping the general dynamic IDL approach.

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

I've read your thesis, and I think you have slightly missed the
intention of IDL attributes. Attributes in IDL are explicitly _not_
simply data members of the object -- they are a shorthand for
specifying a get/set pair of operations (or just a get in the case of
readonly attributes). It should be possible for a servant to do
anything it likes in response to the getting or setting of an
attribute. That is not (easily) possible to do with the current
ORBit-Python mapping.

It is also my personal opinion that it's confusing to the programmer
that an innocent-looking piece of Python code like

  obj.value = 10

involves a remote call, and can raise any of the CORBA system
exceptions. I think it's far better to make it look like what it is: a
method invocation.

Cheers,

Duncan.

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

Re: [Orbit-python-list] Uploaded patch

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

> - there's a leak somewhere related to the creation of new CORBA
>   objects.  Also one related to activation/deactivation of said
>   objects.  Also one related to servant_to_reference (), apparently.

I'll have a look at this today.

>   Correct me if I'm wrong, but aren't they already partially
> implemented by yours truly?  I got an illumination last night, that my

Yup.  I realized this too last night whilest falling asleep. :)

> heh heh...).  Is it OK (as per the specs) to call self._get_thingy()
> if it's defined and to directly return the value of self.thingy if
> it's not?  Ah, I'll have to get the specs and patch server.c (around

If I understand you correctly (and I probably don't), the answer is no.
AFAIK, there's no provision for a user defined interface function in the
form of _get_whatever.  In fact, I seem to recall something saying you
can't have functions that begin with underscores, which is why the
accessor functions are in this form.

Cheers,
Jason.

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.

Re: [Orbit-python-list] Almost there (was: memory leak)

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

>   Er-uhm.  Have a nice day.  I'll send a new patch tomorrow morning.

Great work!

Re: [Orbit-python-list] Almost there (was: memory leak)

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

>   Oh, and after that, I'll have a look at the leak in structs and
> unions that you [Jason] mention.  Could you explain a bit why you
> think there's a leak?  The comment isn't really explicit...

Actually there are a bunch of leaks in idl.c.  These aren't really big
deals since these functions don't get called repeatedly, however they
still need to be fixed.

Just ignore these.  I've a few changes I'm going to make elsewhere (to
the way namespaces are handled), so I'll just go through idl.c and clean
up the leaks.  I just discovered that IDL_ns_ident_to_qstring does not
return borrowed references as I'd originally thought, for example.  Don't
worry about the leaks in idl.c.

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

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