orbitcpp-list

Re: [orbitcpp-list] Re: TypeCode for ORBit-C++

[Andreas K. <ak...@ix...>]

Hi Sam, Phil,

On Mon, Oct 30, 2000 at 09:04:15PM +0000, Phil Dawes wrote:
>  > Last thing (sorry about the size of this message): I intend to get ORBit-C++
>  > packaged for the Debian distribution of Linux, and have applied to be a
>  > Debian maintainer for that reason. Are there any objections to this from the
>  > ORBit-C++ project maintainers?
>  > 
> 
> None from me.  - Andreas?

That's perfectly fine with me. This way I can now easily impress all my
friends who use Debian. :-)))))

BTW: You may have noticed already, but currently I don't have the time
for hacking orbitcpp. You can still consider me part of the team, yet,
I won't be doing much for some time to come :-(

andy

-- 
Your mouse has moved. Windows needs to be restarted to reflect
this change. Reboot now?                                [ OK ]

Re: [orbitcpp-list] Problems with CosNaming ORBit

[Phil D. <ph...@us...>]

Hi Esther,

Are you using the specially patched version of ORBit 0.5.1?

Check the release notes for orbitcpp-0.28.1 on 
http://sourceforge.net/project/showfiles.php?group_id=646
for details.

I strongly recommend that you upgrade to orbitcpp-0.29, and install
the specially packaged version of ORBit cvs for that (details in the
release notes for orbitcpp-0.29). 

Cheers,

Phil

Esther writes:
 > Hello:
 > 
 >     We have get the ORBit 0.5.1 version and orbitcpp-0.28.1, but we are
 > having some problems to use the  name service. We grow the
 > "CosNaming.hh" and "CosNaming.cc" from "CosNaming.idl" and when it is
 > compilated with
 > the Makefile there are some errors like this:
 > 
 > CosNaming.cc:70: passing `const _orbitcpp::c::CosNaming_Name *' as
 > argument 2 of
 > `_orbitcpp::c::CosNaming_NamingContext_bind(_orbitcpp::c::CORBA_Object_struct
 > *, _orbitcpp::c::CosNaming_Name *, _orbitcpp::c::CORBA_Object_struct *,
 > _orbitcpp::c::CORBA_Environment *)' discards qualifiers
 > 
 > Please, help us.  Our e-mail is: ech...@la...
 > 
 > mca...@in...
 > 
 > Thank you very much.
 > 
 > 
 > 
 > _______________________________________________
 > orbitcpp-list mailing list
 > orb...@li...
 > http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list
 > 

[orbitcpp-list] Re: TypeCode for ORBit-C++

[Sam C. <sa...@to...>]

Phil Dawes <ph...@us...> wrote:
> Not really - this is cool! (It compiled out of the box which made me
> smile :-)

Tee hee... It compiles, let's ship it!

> Using the generated code is probably the simplist way to proceed for
> now. Andreas used a macro to generate his sequences (check out
> ORBITCPP_DECLARE_SIMPLE_SEQUENCE in orbitcpp_poa.h - you may want to
> do something similar.)

I found that macro today, and I'm trying to get things working right with
it. It's way neater than the generated code, which makes me feel more
comfortable. It also doesn't rely on the included generated C code from
orbit-idl.

> I don't think the stuff in orbitcpp_orb.hh is quite right:

I didn't think it was either, but I also didn't know how to make it right. I
thought I had it mostly worked out today, but...

> 		TypeCode create_struct_tc(const char * id, const char * name,
> 			StructMemberSeq members);
>=20
> needs to be:
>=20
>         TypeCode_ptr create_struct_tc(const char * id, const char * name,
>             const StructMemberSeq & members);=20

[ ... ]

> (Check out the table on page 104 of the CORBA C++ language mapping for
> details of arguments and parameter passing rules).

Heh. Check out page 56 of "The Common Object Request Broker: Architecture
and Specifications" for an example of C++ code where the return types from
create_recursive_tc() and create_value_tc() seem to be a TypeCode_var.

I'll modify the prototypes to match what you've suggested, for two reasons:
1) It will match the C++ mapping correctly.
2) I can't get it to work using TypeCode_var return types anyway. :)
--=20
Sam Couter          |   Internet Engineer   |   http://www.topic.com.au/
sa...@to...    |   tSA Consulting      |
PGP key available on key servers
PGP key fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

[orbitcpp-list] Problems with CosNaming ORBit

[Esther <ech...@la...>]

Hello:

    We have get the ORBit 0.5.1 version and orbitcpp-0.28.1, but we are
having some problems to use the  name service. We grow the
"CosNaming.hh" and "CosNaming.cc" from "CosNaming.idl" and when it is
compilated with
the Makefile  there are some errors like this:

CosNaming.cc:70: passing `const _orbitcpp::c::CosNaming_Name *' as
argument 2 of
`_orbitcpp::c::CosNaming_NamingContext_bind(_orbitcpp::c::CORBA_Object_struct
*, _orbitcpp::c::CosNaming_Name *, _orbitcpp::c::CORBA_Object_struct *,
_orbitcpp::c::CORBA_Environment *)' discards qualifiers

Please, help us.  Our e-mail is: ech...@la...

mca...@in...

Thank you very much.

[orbitcpp-list] Re: TypeCode for ORBit-C++

[Phil D. <ph...@us...>]

Hi Sam,

Sam Couter writes:
 > After a late night hacking, I've done some work towards getting TypeCode
 > added into ORBit-C++. I'd like it if you could have a look at what I've done
 > so far, and tell me if I'm doing it the right way, the wrong way, or the
 > most difficult way. I started with your instructions (they were very clear,
 > thanks), chased down OMG documents (bit of a pain), tried to decipher OMG
 > documents (a lot of a pain for someone with my level of understanding), and
 > tried to use existing ORBit-C++ code as an example to work from.
 > 
 > 
 > I have attached:
 > Output from the "cvs diff" command.
 > orbitcpp_typecode.hh
 > orbitcpp_typecode.cc
 > 
 > Please note that while I have a fair bit of experience with C and Java, I'm
 > a relative newcomer to C++. It probably shows. :)
 > 

Not really - this is cool! (It compiled out of the box which made me
smile :-)

BTW, Do you have a sourceforge account? Ideally I'd like you to be on
the orbitcpp dev list so that you have CVS write access and can check
this stuff in. (Makes my life easier if you can commit your own stuff)

 > 
 > I have some questions:
 > 
 > What's the best way to implement the StructMemberSeq, UnionMemberSeq and
 > EnumMemberSeq sequences? I have pasted some code that was generated using
 > orbit-idl on a partial IDL file, but I'm not so sure that's the right way to
 > go. That code is commented out, and so is the chunk of create_*_tc methods I
 > added in orbitcpp_orb.hh.
 > 

Using the generated code is probably the simplist way to proceed for
now. Andreas used a macro to generate his sequences (check out
ORBITCPP_DECLARE_SIMPLE_SEQUENCE in orbitcpp_poa.h - you may want to
do something similar.)

I don't think the stuff in orbitcpp_orb.hh is quite right:
e.g.
		TypeCode create_struct_tc(const char * id, const char * name,
			StructMemberSeq members);

needs to be:

        TypeCode_ptr create_struct_tc(const char * id, const char * name,
            const StructMemberSeq & members); 

since the PIDL is 

	     TypeCode create_struct_tc (
                     in RepositoryId id,
                     in Identifier name,
                     in StructMemberSeq members
         );


(Check out the table on page 104 of the CORBA C++ language mapping for
details of arguments and parameter passing rules).


Quick Tip: One way to verify C++ interfaces is to check another 2.3
compliant C++ ORB. I usually use MICO for this - http://www.mico.org/


 > I've used casts all over the place. Is that the correct way to go about
 > things?
 > 

I'm afraid so. This is the price we pay for binary compatibility
between the C and C++ mapping. (The benefits are in reduced code
memory footprint and performance.)

 > Some of the methods in the TypeCode interface aren't implemented by ORBit. I
 > don't know why that is, but I haven't yet implemented anything that's not in
 > ORBit already.
 > 
 > I assume putting my name in the "Copyright" and "Author" sections of the
 > files I've created is the way things are normally done. If not, feel free to
 > modify them appropriately.
 > 

Yep - that's fine. We've been sortof using an informal rule that
whoever creates the file takes the Copyright, and anybody adding to a
pre-existing file adds their name to the authors list.  In the future
this may have to change (e.g. if it becomes legally necessary to sign
copyright over to a third party or something) but I don't want to
think about that right now.

 > 
 > Last thing (sorry about the size of this message): I intend to get ORBit-C++
 > packaged for the Debian distribution of Linux, and have applied to be a
 > Debian maintainer for that reason. Are there any objections to this from the
 > ORBit-C++ project maintainers?
 > 

None from me.  - Andreas?

Once again, many thanks for doing this,

Cheers,

Phil

Re: [orbitcpp-list] Name services?

[Phil D. <pd...@be...>]

Hi Diego, Jesús,

Actually, there are pre-built stubs for the naming service as part of
the orbitcpp install. The library is liborbitcppCosNaming and the
include file is CosNaming.hh. It is built in the
orbitcpp/services/name directory.

There is a test for the orbitcpp cosnaming service stuff in
orbitcpp/test/name/

BTW, I recommend upgrading to 0.29 - there are quite a few fixes in
this release over the 0.28 one.

Cheers,

Phil

Diego Sevilla Ruiz (dse...@um...) writes:
 > -----BEGIN PGP SIGNED MESSAGE-----
 > Hash: SHA1
 > 
 > Hi, Jesús:
 > 
 >     To use the name service, you have to create the client-side stubs
 > for the naming service (CosNaming.idl) using the ORBitcpp idl
 > compiler. You then can use any implementation of the naming service as
 > long as you offer the IOR to your client app.
 > 
 >     Regards.
 >     diego.
 > 
 > Jesús Carretero wrote:
 > 
 > > Hi there, We are trying to use the name services in ORBitcpp
 > > 0.28,but we are getting a lot of compilation errors due to the
 > > include files...For example, we are unable to find CosNaming.hh. Do
 > > you know whether the name service is available in ORBitcpp? Do you
 > > have an example of use?My email address is jca...@in...
 > > Thanks a lot in advance. Sincerely,         Jesus Carretero
 > 
 > --
 > Diego Sevilla Ruiz -- http://ditec.um.es/~dsevilla/ -- dse...@um...
 >        Departamento de Ingeniería y Tecnología de Computadores
 >            Facultad de Informática. Universidad de Murcia
 > Campus de Espinardo  -  30080 Murcia (SPAIN).  -  Tel. +34-968-367570
 > PGP:  http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xC9B964B7
 > \huge d\em\kern-.36em\lower-.2ex\hbox{\small sevilla}\ker...@um...
 > perl -e'$_="\x4\@FLe\x2&B";for(/../g){print unpack("b*",$_),"\n"}'|tr 01 " #"
 > 
 > 
 > 
 > 
 > -----BEGIN PGP SIGNATURE-----
 > Version: PGPfreeware 5.0i for non-commercial use
 > MessageID: /OQJVmDzKUiXmB5PVRNJUYaD/t6gpl/h
 > 
 > iQA/AwUAOf1W9toq0AfJuWS3EQLg7gCfeBRhP1pDnURk4/rlg3qZnAtSzmUAoOgJ
 > LVCyANoT4pEzyzS4SuJR0aYp
 > =d87o
 > -----END PGP SIGNATURE-----
 > _______________________________________________
 > orbitcpp-list mailing list
 > orb...@li...
 > http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list
 > 
-------------------------------------------
Phil Dawes - Senior Consultant
BEA Professional Services
Tel: +44 7780 693052 (Mobile)

Re: [orbitcpp-list] Name services?

[Diego S. R. (<dse...@um...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, Jesús:

    To use the name service, you have to create the client-side stubs
for the naming service (CosNaming.idl) using the ORBitcpp idl
compiler. You then can use any implementation of the naming service as
long as you offer the IOR to your client app.

    Regards.
    diego.

Jesús Carretero wrote:

> Hi there, We are trying to use the name services in ORBitcpp
> 0.28,but we are getting a lot of compilation errors due to the
> include files...For example, we are unable to find CosNaming.hh. Do
> you know whether the name service is available in ORBitcpp? Do you
> have an example of use?My email address is jca...@in...
> Thanks a lot in advance. Sincerely,         Jesus Carretero

--
Diego Sevilla Ruiz -- http://ditec.um.es/~dsevilla/ -- dse...@um...
       Departamento de Ingeniería y Tecnología de Computadores
           Facultad de Informática. Universidad de Murcia
Campus de Espinardo  -  30080 Murcia (SPAIN).  -  Tel. +34-968-367570
PGP:  http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xC9B964B7
\huge d\em\kern-.36em\lower-.2ex\hbox{\small sevilla}\ker...@um...
perl -e'$_="\x4\@FLe\x2&B";for(/../g){print unpack("b*",$_),"\n"}'|tr 01 " #"




-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: /OQJVmDzKUiXmB5PVRNJUYaD/t6gpl/h

iQA/AwUAOf1W9toq0AfJuWS3EQLg7gCfeBRhP1pDnURk4/rlg3qZnAtSzmUAoOgJ
LVCyANoT4pEzyzS4SuJR0aYp
=d87o
-----END PGP SIGNATURE-----

[orbitcpp-list] Name services?

[<jca...@in...>]

Hi there,

We are trying to use the name services in ORBitcpp 0.28,=20
but we are getting a lot of compilation errors due to the include =
files...For example, we are unable to find CosNaming.hh.

Do you know whether the name service is available in ORBitcpp? Do you =
have an example of use?
My email address is jca...@in...

Thanks a lot  in advance.=20

Sincerely,

        Jesus Carretero

Re: [orbitcpp-list] Destroying CORBA objects

[Phil D. <ph...@us...>]

Hi Sam, hi list,

As discussed in an earlier mail on this thread, 'delete this' is a bad
idea in a corba servant, since the orb has a reference to the object
in the active object map. An additional barrier to doing a 'delete
this' from within a corba method is that even if you remove the
servant from the active object map first, the poa is at liberty to
reference the servant on post-invoke.

In order to overcome this, the C++ mapping provides a server side
reference counting mechanism for servants, enabling a 'remove()'
method to be implemented as an idl operation on the servant.

(see section 1.36.1 and 1.36.2 of the C++ language mapping).

Here's the receipe for implementing reference counted transient
objects in CORBA (this now works with cvs version of orbitcpp):


1) Make the implementation inherit from the
PortableServer::RefCountServantBase mixin base class.

E.g.

class TransientObj_impl : public virtual POA_test::TransientObj,
						  public virtual PortableServer::RefCountServantBase{
	...
};


This base class implements the _add_ref() and _remove_ref() methods on
the PortableServer::ServantBase base class with an implementation
which manages a thread-safe count, and calls 'delete this()' when it
hits 0.

2) In your factory (or wherever the servant creation is done) you must
be careful to call remove_ref() on your implementation once you've
finished with it.

E.g.

test::TransientObj_ptr
test_impl::TestFactory_impl::createTransientObj(){
  test_impl::TransientObj_impl *impl = new test_impl::TransientObj_impl;

  test::TransientObj_ptr ptr = impl->_this();   // the poa calls _add_ref() implicitly
  impl->_remove_ref();   // release the servant since we are finished with it
  return ptr;
}

N.B. when you call _this() to implicitly activate the object (or
POA::activate_object() to explicitly activate it) the POA increases
the reference to ensure that it is kept alive while it is in the
active object map.

3) Create a remove() operation on your CORBA interface. In the
implementation of this operation, call POA::deactivate_object(). This
will ensure that after the operation has completed (and in addition,
any concurrent operations have completed), the servant's reference
will be decremented, and the servant will be deleted.

E.g.

void
test_impl::TransientObj_impl::remove() {
  PortableServer::POA_var poa = _default_POA();
  PortableServer::ObjectId_var oid = poa->servant_to_id(this);
  poa->deactivate_object(*oid);
}


Hope this helps,

Cheers,

Phil

Re: [orbitcpp-list] Destroying CORBA objects

[Phil D. <ph...@us...>]

Sam Couter writes:
 > Phil Dawes <ph...@us...> wrote:
 > > 
 > > <The bad news>
 > > Unfortunately orbitcpp doesn't have the poa infrastructure to do this
 > > right now, but I am currently working on it. Expect the code to be in
 > > cvs within the next 2 weeks. I'll keep you posted.
 > > </The bad news>
 > 
 > I need this ability (and some others) ASAP. Is there any help I could offer
 > to speed up the development process?
 > 

Yes please!

 > When you say 2 weeks, does that mean reasonably stable support, or is
 > bugstomping an additional time?
 > 

Time includes testing (i.e. includes a unit test in the /test dir)

 > The other funcionality I need is:
 > Support for the 'any' type (I could work around this if I had to, but it'd
 > be nasty)

hmmmm... Both 'typecode' and 'any' are missing from orbitcpp (any
relies on typecode to work). And union.

 > Thread-safety (I *think* I could work around this, but I'm not sure - it
 > would involve using fork() to provide each CORBA object with its own
 > single-threaded ORB)
 > 

orbitcpp *should* be thread safe. (I removed the last (I think) thread
unsafe construct before the 0.29 release). I've never tested it with
ORBit-mt though. Has anybody else?

 > If anyone can give me pointers towards helping implement any of these
 > things, I'd be willing to put in some time and effort to do so. My only
 > alternative to using ORBit-C++ is to write C wrappers around the C++ library
 > I need to use, and write in C using ORBit. Yuck. I'd prefer to avoid that.

If you're willing, you could do a lot here to help. The majority of
the work in implementing support for Typecode and Any is in wrapping
the C constructs in C++ classes which conform to the C++ corba
spec. The actual compiler should be fairly easy (and for speed
probably best left to me or Andreas to implement).

Here's a brief rundown of what I think is required:

- create orbitcpp_any.hh/orbitcpp_any.cc and
orbitcpp_typecode.hh/orbitcpp_typecode.cc files in the orb directory.

- Write a TypeCode class which wraps the C ORBit typecode struct. Note
that these need to be binary compatible, so the only datamember in the
class should be the 'value' (not pointer) of the C struct.

- Do the same for the Any class

- write a couple of test functions in the test/everything/client.cc
file to confirm that values can be inserted into and extracted from
anys etc...

- Pester me or andreas to write the compiler bit. (Or alternatively
spend some time reading the HACKING file and familiarising yourself
with the compiler design).

Does this sound reasonable?

Cheers,

Phil

Re: [orbitcpp-list] Can't compile Bonobo.idl

[Sam C. <sa...@to...>]

Phil Dawes <ph...@us...> wrote:
>=20
> Hi cactus,
>=20
> I'm afraid the problem is that orbitcpp doesn't support CORBA 'any'
> yet.

Bummer for me.

> (patches gratefully accepted)

With an appropriate starting point, some instructions, etc, I will gladly
help with this. Without a starting point, I don't think I can find my own
way.

Would I need to know lex at all to do this?
--=20
Sam Couter          |   Internet Engineer   |   http://www.topic.com.au/
sa...@to...    |   tSA Consulting      |
PGP key available on key servers
PGP key fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

Re: [orbitcpp-list] Destroying CORBA objects

[Sam C. <sa...@to...>]

Phil Dawes <ph...@us...> wrote:
>=20
> <The bad news>
> Unfortunately orbitcpp doesn't have the poa infrastructure to do this
> right now, but I am currently working on it. Expect the code to be in
> cvs within the next 2 weeks. I'll keep you posted.
> </The bad news>

I need this ability (and some others) ASAP. Is there any help I could offer
to speed up the development process?

When you say 2 weeks, does that mean reasonably stable support, or is
bugstomping an additional time?

The other funcionality I need is:
Support for the 'any' type (I could work around this if I had to, but it'd
be nasty)
Thread-safety (I *think* I could work around this, but I'm not sure - it
would involve using fork() to provide each CORBA object with its own
single-threaded ORB)

If anyone can give me pointers towards helping implement any of these
things, I'd be willing to put in some time and effort to do so. My only
alternative to using ORBit-C++ is to write C wrappers around the C++ library
I need to use, and write in C using ORBit. Yuck. I'd prefer to avoid that.
--=20
Sam Couter          |   Internet Engineer   |   http://www.topic.com.au/
sa...@to...    |   tSA Consulting      |
PGP key available on key servers
PGP key fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

Re: [orbitcpp-list] Destroying CORBA objects

[Phil D. <ph...@us...>]

Hi Michael,

Yep - none of that will work in orbitcpp yet. I'll be wrapping all of
the current ORBit POA functionality in the next couple of weeks.

If you have a snippet of code illustrating what he's trying to do,
I'll prioritise!

Cheers,

Phil

Michael Rumpf writes:
 > Hi Phil,
 > 
 > does your current work include the create_POA related stuff? A friend of
 > mine is having troubles using special policies on a new POA...!!
 > 
 > Thanks,
 >     Michael
 > 

Re: [orbitcpp-list] Destroying CORBA objects

[Michael R. <mi...@ru...>]

Hi Phil,

does your current work include the create_POA related stuff? A friend of
mine is having troubles using special policies on a new POA...!!

Thanks,
    Michael

----- Original Message -----
From: "Phil Dawes" <ph...@us...>
To: <orb...@li...>
Sent: Donnerstag, 19. Oktober 2000 12:07
Subject: Re: [orbitcpp-list] Destroying CORBA objects


> Hi Sam,
>
> You're right - a 'delete this' (on its own) will cause problems since
> the object must be removed from the active object map before deleting
> otherwise the poa will continue sending requests to a dead servant.
>
> Michi Henning (Advanced CORBA Programming with C++) recommends that
> the 'free' call (called 'remove' in the CORBA lifecycle spec - you may
> want to copy this convention) be put on the object interface rather
> than the factory, since object refs can be passed between servers and
> so having to keep track of the parent/factory can be a pain. Note that
> both COM and EJB follow this approach (in methods
> 'IUnknown::release()' and 'EJBObject.remove()' respectively).
>
> <The bad news>
> Unfortunately orbitcpp doesn't have the poa infrastructure to do this
> right now, but I am currently working on it. Expect the code to be in
> cvs within the next 2 weeks. I'll keep you posted.
> </The bad news>
>
> Cheers,
>
> Phil
>
> Sam Couter writes:
>  > All,
>  >
>  > I have a CORBA application that creates many objects on the server
side,
>  > continuously. I need a way to destroy these objects to avoid memory
leaks.
>  >
>  > The application was previously using ORBit, and all I did was provide a
>  > free() method on each object, which the client called when it was
finished
>  > with the object.
>  >
>  > Now that I need to tie the application into a C++ API, I've decided to
use
>  > ORBitcpp.
>  >
>  > So, how do I destroy an object in the server in ORBitcpp? I know how to
>  > create one (the Account/Bank example), but doing "delete(this)" to dest
roy
>  > it seems like suicide to me.
>  >
>  > Should I provide a bunch of freeObjectFoo() methods on the factory
object
>  > that's creating them all in the first place? This doesn't seem like the
>  > correct solution. If I do this, what do I need to do to destroy the
objects
>  > passed to this method?
>  >
>  > Thanks.
>  > --
>  > Sam Couter          |   Internet Engineer   |
http://www.topic.com.au/
>  > sa...@to...    |   tSA Consulting      |
>  > PGP key available on key servers
>  > PGP key fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89
C75C
>
> _______________________________________________
> orbitcpp-list mailing list
> orb...@li...
> http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list

Re: [orbitcpp-list] Can't compile Bonobo.idl

[Phil D. <ph...@us...>]

Hi cactus,

I'm afraid the problem is that orbitcpp doesn't support CORBA 'any'
yet.

(patches gratefully accepted)

Sorry,

Phil


Sender: orb...@li...
To: ORBit/C++ <orb...@li...>
Date: Sun, 15 Oct 2000 23:35:57 +0200 (CEST)
Subject: [orbitcpp-list] Can't compile Bonobo.idl
MIME-Version: 1.0

Hi,

I can't compile the master Bonobo idl file:

23:30:11 [cactus@galaxy idl]$ orbit-idl  -lc++ `gnome-config --cflags idl=
`
~/prog/gnome/sandbox/share/idl/Bonobo.idl  -D__BONOBO_COMPILATION

/home/cactus/prog/gnome/sandbox/share/idl/bonobo-unknown.idl:40: Warning:
`query_interface' underscores within identifiers are discouraged for use
with C-language IDL mappings

/home/cactus/prog/gnome/sandbox/share/idl/bonobo-moniker.idl:14: unknown
identifier ::Bonobo::ResolveFlag


::Bonobo::ResolveFlag is typedef'd to `long' in bonobo-moniker.idl
previously.

Also, when trying to compile the IDL's separately, I can't compile
bonobo-property.idl:
bonobo-property.idl:32: type_any not expected

(line 32 is oneway void event (in string name, in any value);)

What am I missing here?

(using orbitcpp fresh from CVS)

--=20
   .--=3D ULLA! =3D----------------------------.  finger ca...@ca...=
lez.org
   \      http://cactus.rulez.org           \   for PGP public key
    `----------=3D ca...@ca... =3D--'
A s=F6r lassan but=EDt, de nem baj, =E9n r=E1=E9rek...

_______________________________________________
orbitcpp-list mailing list
orb...@li...
http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list

Re: [orbitcpp-list] Destroying CORBA objects

[Phil D. <ph...@us...>]

Hi Sam,

You're right - a 'delete this' (on its own) will cause problems since
the object must be removed from the active object map before deleting
otherwise the poa will continue sending requests to a dead servant.

Michi Henning (Advanced CORBA Programming with C++) recommends that
the 'free' call (called 'remove' in the CORBA lifecycle spec - you may
want to copy this convention) be put on the object interface rather
than the factory, since object refs can be passed between servers and
so having to keep track of the parent/factory can be a pain. Note that
both COM and EJB follow this approach (in methods
'IUnknown::release()' and 'EJBObject.remove()' respectively).

<The bad news>
Unfortunately orbitcpp doesn't have the poa infrastructure to do this
right now, but I am currently working on it. Expect the code to be in
cvs within the next 2 weeks. I'll keep you posted.
</The bad news>

Cheers,

Phil

Sam Couter writes:
 > All,
 > 
 > I have a CORBA application that creates many objects on the server side,
 > continuously. I need a way to destroy these objects to avoid memory leaks.
 > 
 > The application was previously using ORBit, and all I did was provide a
 > free() method on each object, which the client called when it was finished
 > with the object.
 > 
 > Now that I need to tie the application into a C++ API, I've decided to use
 > ORBitcpp.
 > 
 > So, how do I destroy an object in the server in ORBitcpp? I know how to
 > create one (the Account/Bank example), but doing "delete(this)" to destroy
 > it seems like suicide to me.
 > 
 > Should I provide a bunch of freeObjectFoo() methods on the factory object
 > that's creating them all in the first place? This doesn't seem like the
 > correct solution. If I do this, what do I need to do to destroy the objects
 > passed to this method?
 > 
 > Thanks.
 > -- 
 > Sam Couter          |   Internet Engineer   |   http://www.topic.com.au/
 > sa...@to...    |   tSA Consulting      |
 > PGP key available on key servers
 > PGP key fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

Re: [orbitcpp-list] Functions??

[Phil D. <ph...@us...>]

Rene Maldonado writes:
 > Hi All.
 > 
 > I'm using ORBit, and I was wondering if  any one know where can I find
 > information on some ORBit functios like what they do, what they need as
 > a parameter, etc.
 > 
 > Thanks
 >  Rene


Hi Rene,

Are you using orbitcpp or just straight ORBit?

ORBit resources can be found at
http://orbit-resource.sourceforge.net

I'm afraid for orbitcpp you have to rely on the CORBA C++ spec (or the
examples in the 'test' directory).

Cheers,

Phil

[orbitcpp-list] Destroying CORBA objects

[Sam C. <sa...@to...>]

All,

I have a CORBA application that creates many objects on the server side,
continuously. I need a way to destroy these objects to avoid memory leaks.

The application was previously using ORBit, and all I did was provide a
free() method on each object, which the client called when it was finished
with the object.

Now that I need to tie the application into a C++ API, I've decided to use
ORBitcpp.

So, how do I destroy an object in the server in ORBitcpp? I know how to
create one (the Account/Bank example), but doing "delete(this)" to destroy
it seems like suicide to me.

Should I provide a bunch of freeObjectFoo() methods on the factory object
that's creating them all in the first place? This doesn't seem like the
correct solution. If I do this, what do I need to do to destroy the objects
passed to this method?

Thanks.
--=20
Sam Couter          |   Internet Engineer   |   http://www.topic.com.au/
sa...@to...    |   tSA Consulting      |
PGP key available on key servers
PGP key fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

[orbitcpp-list] Functions??

[Rene M. <re...@te...>]

Hi All.

I'm using ORBit, and I was wondering if  any one know where can I find
information on some ORBit functios like what they do, what they need as
a parameter, etc.

Thanks
 Rene

[orbitcpp-list] Can't compile Bonobo.idl

[ERDI G. <ca...@ca...>]

Hi,

I can't compile the master Bonobo idl file:

23:30:11 [cactus@galaxy idl]$ orbit-idl  -lc++ `gnome-config --cflags idl`
~/prog/gnome/sandbox/share/idl/Bonobo.idl  -D__BONOBO_COMPILATION

/home/cactus/prog/gnome/sandbox/share/idl/bonobo-unknown.idl:40: Warning:
`query_interface' underscores within identifiers are discouraged for use
with C-language IDL mappings

/home/cactus/prog/gnome/sandbox/share/idl/bonobo-moniker.idl:14: unknown
identifier ::Bonobo::ResolveFlag


::Bonobo::ResolveFlag is typedef'd to `long' in bonobo-moniker.idl
previously.

Also, when trying to compile the IDL's separately, I can't compile
bonobo-property.idl:
bonobo-property.idl:32: type_any not expected

(line 32 is oneway void event (in string name, in any value);)

What am I missing here?

(using orbitcpp fresh from CVS)

-- 
   .--= ULLA! =----------------------------.  finger ca...@ca...
   \      http://cactus.rulez.org           \   for PGP public key
    `----------= ca...@ca... =--'
A sör lassan butít, de nem baj, én ráérek...

[orbitcpp-list] orbitcpp 0.29 released

[Phil D. <ph...@us...>]

Hi folks,

orbitcpp-0.29 is finally out the door - many apologies for the delay,
I've been having a rough few weeks at work so free software took a
back seet for a while.

Check out:

http://orbitcpp.sourceforge.net/

(There's some new dependencies, so don't forget to read the release
notes!)

Cheers,

Phil

Re: [orbitcpp-list] Minor request...

[Phil D. <ph...@us...>]

Hi Mike,

Unfortunately this functionality never got into 0.29 - there is no
mechanism in ORBit to pass arguments to compiler backend libraries
which made implementing this non-trivial.

In the short term you can however compile your own custom copy of
orbitcpp which does this by simply editing these lines from
orbitcpp/compiler/base.hh:

#define IDL_CPP_HEADER_EXT			"-cpp-common.hh"
#define IDL_CPP_MODULE_EXT			"-cpp-common.cc"
#define IDL_CPP_STUB_HEADER_EXT		"-cpp-stubs.hh"
#define IDL_CPP_STUB_MODULE_EXT		"-cpp-stubs.cc"
#define IDL_CPP_SKEL_HEADER_EXT		"-cpp-skels.hh"
#define IDL_CPP_SKEL_MODULE_EXT		"-cpp-skels.cc"
#define IDL_CPP_MAIN_HEADER_EXT		"-cpp.hh"
#define IDL_CPP_MAIN_MODULE_EXT		"-cpp.cc"


Hope this helps,

Phil


Phil Dawes writes:
 > 
 > Hi, I'll add it to the todo list for the 0.29 release,
 > 
 > Cheers
 > 
 > Phil
 > 
 > Mike Bond writes:
 >  > If it would not be too difficult, it would be nice to be able to specify
 >  > the generated file name extensions. Currently it uses .cc and .hh, but
 >  > unfortunately there is no one standard, and the project I am working on
 >  > and hoping to use orbitcpp with uses .cpp and .h as their extensions of
 >  > choice.
 >  > 
 >  > Just an idea...
 >  > 
 >  > -- 
 >  > TTFN
 >  > MikeB
 >  > _______________________________________________
 >  > orbitcpp-list mailing list
 >  > orb...@li...
 >  > http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list
 >  > 
 > 
 > _______________________________________________
 > orbitcpp-list mailing list
 > orb...@li...
 > http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list
 > 

Re: [orbitcpp-list] STL-based IDL compiler frontend

[Andreas K. <ak...@ix...>]

On Sun, Oct 15, 2000 at 12:28:55PM +0200, ERDI Gergo wrote:
> Hi,
> 
> I'm looking for a non-standard, STL-based IDL compiler frontend. Is there
> such a frontend available? Ideally, it would create both standard methods
> and some forwarder methods using STL (that is, you would forward from STL
> to standard in the stub class, and from standard to STL in the skeleton
> class):
> interface Foo
> {
> 	void bar (in string str);
> }
> 
> would create:
> 
> class Foo_Stub
> {
> 	void bar (char* str) { /* Standard ORBit magic */ };
> 	void bar (string str) { bar (str.c_str ()); };
> }
> 
> class Foo_Skel
> {
> 	virtual void bar (char* str) { return bar (string (str)); };
> 	virtual void bar (string str) = 0;
> }

Implementing this for using "string" and "char *" alternatively would
be no problem with our IDL compiler, however I do not think this is
in any way a good idea.

Implementing the multi-signature approach is IMHO even less a good idea,
because
a) in the skeleton, bar(char *) cannot be implemented without
stubbing bar(string) --> no real compatibility.
b) imagine the following IDL: 
"baz(string,string,string,string,string,string)".
would you want 64 methods for implementing every conceivable
combination? *BLOAT*

Please think about just sticking with char *'s. Standards exist
for a reason, and in this particular case, the code overhead
on your side is really minimal.

bye
andy
-- 
Your mouse has moved. Windows needs to be restarted to reflect
this change. Reboot now?                                [ OK ]

[orbitcpp-list] STL-based IDL compiler frontend

[ERDI G. <ca...@ca...>]

Hi,

I'm looking for a non-standard, STL-based IDL compiler frontend. Is there
such a frontend available? Ideally, it would create both standard methods
and some forwarder methods using STL (that is, you would forward from STL
to standard in the stub class, and from standard to STL in the skeleton
class):
interface Foo
{
	void bar (in string str);
}

would create:

class Foo_Stub
{
	void bar (char* str) { /* Standard ORBit magic */ };
	void bar (string str) { bar (str.c_str ()); };
}

class Foo_Skel
{
	virtual void bar (char* str) { return bar (string (str)); };
	virtual void bar (string str) = 0;
}


-- 
   .--= ULLA! =----------------------------.  finger ca...@ca...
   \      http://cactus.rulez.org           \   for PGP public key
    `----------= ca...@ca... =--'
If this had been a real emergency, we would have all fled in terror, and you would not have been notified.

[orbitcpp-list] confirm 873799

[Alain <GA...@al...>]

confirm 873799