orbitcpp-list

Re: [orbitcpp-list] two rookie questions: initialization, object validation

[<la...@se...>]

/*
 * This file was generated by orbit-idl - DO NOT EDIT!
 */

#include <errno.h>	// lance
#include <string.h>
#include "zone.h"

CORBA_char *
ZoneModule_ZoneInterface_setTransport(ZoneModule_ZoneInterface _obj,
				      const CORBA_char * ior,
				      CORBA_Environment * ev)
{
   register GIOP_unsigned_long _ORBIT_request_id,
    _ORBIT_system_exception_minor;
   register CORBA_completion_status _ORBIT_completion_status;
   register GIOPSendBuffer *_ORBIT_send_buffer;
   register GIOPRecvBuffer *_ORBIT_recv_buffer;
   register GIOPConnection *_cnx;
   CORBA_char *_ORBIT_retval;
   register CORBA_unsigned_long _ORBIT_tmpvar_4;
   CORBA_unsigned_long _ORBIT_tmpvar_5;

   if (_obj->servant && _obj->vepv && ZoneModule_ZoneInterface__classid) {
      _ORBIT_retval =
	 ((POA_ZoneModule_ZoneInterface__epv *) _obj->
	  vepv[ZoneModule_ZoneInterface__classid])->setTransport(_obj->
								 servant, ior,
								 ev);
      return _ORBIT_retval;
   }
   if (0)
      return *(&_ORBIT_retval);
   _cnx = ORBit_object_get_connection(_obj);
 _ORBIT_retry_request:
   _ORBIT_send_buffer = NULL;
   _ORBIT_recv_buffer = NULL;
   _ORBIT_completion_status = CORBA_COMPLETED_NO;
   _ORBIT_request_id = GPOINTER_TO_UINT(alloca(0));
   {				/* marshalling */
      static const struct
      {
	 CORBA_unsigned_long len;
	 char opname[13];
      }
      _ORBIT_operation_name_data =
      {
      13, "setTransport"};
      static const struct iovec _ORBIT_operation_vec =
	 { (gpointer) & _ORBIT_operation_name_data, 17 };
      register CORBA_unsigned_long _ORBIT_tmpvar_0;
      CORBA_unsigned_long _ORBIT_tmpvar_1;

      _ORBIT_send_buffer =
	 giop_send_request_buffer_use(_cnx, NULL, _ORBIT_request_id,
				      CORBA_TRUE,
				      &(_obj->active_profile->object_key_vec),
				      &_ORBIT_operation_vec,
				      &ORBit_default_principal_iovec);

      _ORBIT_system_exception_minor = ex_CORBA_COMM_FAILURE;
      if (!_ORBIT_send_buffer)
	 goto _ORBIT_system_exception;
      _ORBIT_tmpvar_1 = strlen(ior) + 1;
      giop_message_buffer_do_alignment(GIOP_MESSAGE_BUFFER
				       (_ORBIT_send_buffer), 4);
      {
	 guchar *_ORBIT_t;

	 _ORBIT_t = alloca(sizeof(_ORBIT_tmpvar_1));
	 memcpy(_ORBIT_t, &(_ORBIT_tmpvar_1), sizeof(_ORBIT_tmpvar_1));
	 giop_message_buffer_append_mem(GIOP_MESSAGE_BUFFER
					(_ORBIT_send_buffer), (_ORBIT_t),
					sizeof(_ORBIT_tmpvar_1));
      }
      giop_message_buffer_append_mem(GIOP_MESSAGE_BUFFER(_ORBIT_send_buffer),
				     (ior),
				     sizeof(ior[_ORBIT_tmpvar_0]) *
				     _ORBIT_tmpvar_1);
      giop_send_buffer_write(_ORBIT_send_buffer);
      _ORBIT_completion_status = CORBA_COMPLETED_MAYBE;
      giop_send_buffer_unuse(_ORBIT_send_buffer);
      _ORBIT_send_buffer = NULL;
   }
   {				/* demarshalling */
      register guchar *_ORBIT_curptr;

      _ORBIT_recv_buffer =
	 giop_recv_reply_buffer_use_2(_cnx, _ORBIT_request_id, TRUE);
      if (!_ORBIT_recv_buffer)
	 goto _ORBIT_system_exception;
      _ORBIT_completion_status = CORBA_COMPLETED_YES;
      if (_ORBIT_recv_buffer->message.u.reply.reply_status !=
	  GIOP_NO_EXCEPTION) goto _ORBIT_msg_exception;
      _ORBIT_curptr = GIOP_RECV_BUFFER(_ORBIT_recv_buffer)->cur;
      if (giop_msg_conversion_needed(GIOP_MESSAGE_BUFFER(_ORBIT_recv_buffer))) {
	 _ORBIT_curptr = ALIGN_ADDRESS(_ORBIT_curptr, 4);
	 
	    (*((guint32 *) & (_ORBIT_tmpvar_5))) =
	    GUINT32_SWAP_LE_BE(*((guint32 *) _ORBIT_curptr));
	 _ORBIT_curptr += 4;
	 _ORBIT_retval = CORBA_string_alloc(_ORBIT_tmpvar_5);
	 memcpy(_ORBIT_retval, _ORBIT_curptr,
		sizeof(_ORBIT_retval[_ORBIT_tmpvar_4]) * _ORBIT_tmpvar_5);
	 _ORBIT_curptr +=
	    sizeof(_ORBIT_retval[_ORBIT_tmpvar_4]) * _ORBIT_tmpvar_5;
      } else {
	 _ORBIT_curptr = ALIGN_ADDRESS(_ORBIT_curptr, 4);
	 _ORBIT_tmpvar_5 = *((CORBA_unsigned_long *) _ORBIT_curptr);
	 _ORBIT_curptr += 4;
	 _ORBIT_retval = CORBA_string_alloc(_ORBIT_tmpvar_5);
	 memcpy(_ORBIT_retval, _ORBIT_curptr,
		sizeof(_ORBIT_retval[_ORBIT_tmpvar_4]) * _ORBIT_tmpvar_5);
	 _ORBIT_curptr +=
	    sizeof(_ORBIT_retval[_ORBIT_tmpvar_4]) * _ORBIT_tmpvar_5;
      }
      giop_recv_buffer_unuse(_ORBIT_recv_buffer);
      return _ORBIT_retval;
    _ORBIT_system_exception:
      CORBA_exception_set_system(ev, _ORBIT_system_exception_minor,
				 _ORBIT_completion_status);
      giop_recv_buffer_unuse(_ORBIT_recv_buffer);
      giop_send_buffer_unuse(_ORBIT_send_buffer);
      return _ORBIT_retval;
    _ORBIT_msg_exception:
      if (_ORBIT_recv_buffer->message.u.reply.reply_status ==
	  GIOP_LOCATION_FORWARD) {
	 if (_obj->forward_locations != NULL)
	    ORBit_delete_profiles(_obj->forward_locations);
	 _obj->forward_locations = ORBit_demarshal_IOR(_ORBIT_recv_buffer);
	 _cnx = ORBit_object_get_forwarded_connection(_obj);
	 giop_recv_buffer_unuse(_ORBIT_recv_buffer);

	 goto _ORBIT_retry_request;
      } else {
	 ORBit_handle_exception(_ORBIT_recv_buffer, ev, NULL, _obj->orb);
	 giop_recv_buffer_unuse(_ORBIT_recv_buffer);
	 return _ORBIT_retval;
      }
   }
}
CORBA_char *
ZoneModule_ZoneInterface_clearTransport(ZoneModule_ZoneInterface _obj,
					CORBA_Environment * ev)
{
   register GIOP_unsigned_long _ORBIT_request_id,
    _ORBIT_system_exception_minor;
   register CORBA_completion_status _ORBIT_completion_status;
   register GIOPSendBuffer *_ORBIT_send_buffer;
   register GIOPRecvBuffer *_ORBIT_recv_buffer;
   register GIOPConnection *_cnx;
   CORBA_char *_ORBIT_retval;
   register CORBA_unsigned_long _ORBIT_tmpvar_2;
   CORBA_unsigned_long _ORBIT_tmpvar_3;

   if (_obj->servant && _obj->vepv && ZoneModule_ZoneInterface__classid) {
      _ORBIT_retval =
	 ((POA_ZoneModule_ZoneInterface__epv *) _obj->
	  vepv[ZoneModule_ZoneInterface__classid])->clearTransport(_obj->
								   servant,
								   ev);
      return _ORBIT_retval;
   }
   if (0)
      return *(&_ORBIT_retval);
   _cnx = ORBit_object_get_connection(_obj);
 _ORBIT_retry_request:
   _ORBIT_send_buffer = NULL;
   _ORBIT_recv_buffer = NULL;
   _ORBIT_completion_status = CORBA_COMPLETED_NO;
   _ORBIT_request_id = GPOINTER_TO_UINT(alloca(0));
   {				/* marshalling */
      static const struct
      {
	 CORBA_unsigned_long len;
	 char opname[15];
      }
      _ORBIT_operation_name_data =
      {
      15, "clearTransport"};
      static const struct iovec _ORBIT_operation_vec =
	 { (gpointer) & _ORBIT_operation_name_data, 19 };

      _ORBIT_send_buffer =
	 giop_send_request_buffer_use(_cnx, NULL, _ORBIT_request_id,
				      CORBA_TRUE,
				      &(_obj->active_profile->object_key_vec),
				      &_ORBIT_operation_vec,
				      &ORBit_default_principal_iovec);

      _ORBIT_system_exception_minor = ex_CORBA_COMM_FAILURE;
      if (!_ORBIT_send_buffer)
	 goto _ORBIT_system_exception;
      giop_send_buffer_write(_ORBIT_send_buffer);
      _ORBIT_completion_status = CORBA_COMPLETED_MAYBE;
      giop_send_buffer_unuse(_ORBIT_send_buffer);
      _ORBIT_send_buffer = NULL;
   }
   {				/* demarshalling */
      register guchar *_ORBIT_curptr;

      _ORBIT_recv_buffer =
	 giop_recv_reply_buffer_use_2(_cnx, _ORBIT_request_id, TRUE);
      if (!_ORBIT_recv_buffer)
	 goto _ORBIT_system_exception;
      _ORBIT_completion_status = CORBA_COMPLETED_YES;
      if (_ORBIT_recv_buffer->message.u.reply.reply_status !=
	  GIOP_NO_EXCEPTION) goto _ORBIT_msg_exception;
      _ORBIT_curptr = GIOP_RECV_BUFFER(_ORBIT_recv_buffer)->cur;
      if (giop_msg_conversion_needed(GIOP_MESSAGE_BUFFER(_ORBIT_recv_buffer))) {
	 _ORBIT_curptr = ALIGN_ADDRESS(_ORBIT_curptr, 4);
	 
	    (*((guint32 *) & (_ORBIT_tmpvar_3))) =
	    GUINT32_SWAP_LE_BE(*((guint32 *) _ORBIT_curptr));
	 _ORBIT_curptr += 4;
	 _ORBIT_retval = CORBA_string_alloc(_ORBIT_tmpvar_3);
	 memcpy(_ORBIT_retval, _ORBIT_curptr,
		sizeof(_ORBIT_retval[_ORBIT_tmpvar_2]) * _ORBIT_tmpvar_3);
	 _ORBIT_curptr +=
	    sizeof(_ORBIT_retval[_ORBIT_tmpvar_2]) * _ORBIT_tmpvar_3;
      } else {
	 _ORBIT_curptr = ALIGN_ADDRESS(_ORBIT_curptr, 4);
	 _ORBIT_tmpvar_3 = *((CORBA_unsigned_long *) _ORBIT_curptr);
	 _ORBIT_curptr += 4;
	 _ORBIT_retval = CORBA_string_alloc(_ORBIT_tmpvar_3);
	 memcpy(_ORBIT_retval, _ORBIT_curptr,
		sizeof(_ORBIT_retval[_ORBIT_tmpvar_2]) * _ORBIT_tmpvar_3);
	 _ORBIT_curptr +=
	    sizeof(_ORBIT_retval[_ORBIT_tmpvar_2]) * _ORBIT_tmpvar_3;
      }
      giop_recv_buffer_unuse(_ORBIT_recv_buffer);
      return _ORBIT_retval;
    _ORBIT_system_exception:
      CORBA_exception_set_system(ev, _ORBIT_system_exception_minor,
				 _ORBIT_completion_status);
      giop_recv_buffer_unuse(_ORBIT_recv_buffer);
      giop_send_buffer_unuse(_ORBIT_send_buffer);
      return _ORBIT_retval;
    _ORBIT_msg_exception:
      if (_ORBIT_recv_buffer->message.u.reply.reply_status ==
	  GIOP_LOCATION_FORWARD) {
	 if (_obj->forward_locations != NULL)
	    ORBit_delete_profiles(_obj->forward_locations);
	 _obj->forward_locations = ORBit_demarshal_IOR(_ORBIT_recv_buffer);
	 _cnx = ORBit_object_get_forwarded_connection(_obj);
	 giop_recv_buffer_unuse(_ORBIT_recv_buffer);

	 goto _ORBIT_retry_request;
      } else {
	 ORBit_handle_exception(_ORBIT_recv_buffer, ev, NULL, _obj->orb);
	 giop_recv_buffer_unuse(_ORBIT_recv_buffer);
	 return _ORBIT_retval;
      }
   }
}
CORBA_char *
ZoneModule_ZoneInterface_getTransport(ZoneModule_ZoneInterface _obj,
				      CORBA_Environment * ev)
{
   register GIOP_unsigned_long _ORBIT_request_id,
    _ORBIT_system_exception_minor;
   register CORBA_completion_status _ORBIT_completion_status;
   register GIOPSendBuffer *_ORBIT_send_buffer;
   register GIOPRecvBuffer *_ORBIT_recv_buffer;
   register GIOPConnection *_cnx;
   CORBA_char *_ORBIT_retval;
   register CORBA_unsigned_long _ORBIT_tmpvar_2;
   CORBA_unsigned_long _ORBIT_tmpvar_3;

   if (_obj->servant && _obj->vepv && ZoneModule_ZoneInterface__classid) {
      _ORBIT_retval =
	 ((POA_ZoneModule_ZoneInterface__epv *) _obj->
	  vepv[ZoneModule_ZoneInterface__classid])->getTransport(_obj->
								 servant, ev);
      return _ORBIT_retval;
   }
   if (0)
      return *(&_ORBIT_retval);
   _cnx = ORBit_object_get_connection(_obj);
 _ORBIT_retry_request:
   _ORBIT_send_buffer = NULL;
   _ORBIT_recv_buffer = NULL;
   _ORBIT_completion_status = CORBA_COMPLETED_NO;
   _ORBIT_request_id = GPOINTER_TO_UINT(alloca(0));
   {				/* marshalling */
      static const struct
      {
	 CORBA_unsigned_long len;
	 char opname[13];
      }
      _ORBIT_operation_name_data =
      {
      13, "getTransport"};
      static const struct iovec _ORBIT_operation_vec =
	 { (gpointer) & _ORBIT_operation_name_data, 17 };

      _ORBIT_send_buffer =
	 giop_send_request_buffer_use(_cnx, NULL, _ORBIT_request_id,
				      CORBA_TRUE,
				      &(_obj->active_profile->object_key_vec),
				      &_ORBIT_operation_vec,
				      &ORBit_default_principal_iovec);

      _ORBIT_system_exception_minor = ex_CORBA_COMM_FAILURE;
      if (!_ORBIT_send_buffer)
	 goto _ORBIT_system_exception;
errno=0 ;	// lance
      giop_send_buffer_write(_ORBIT_send_buffer);
if (errno)	// lance
goto _ORBIT_system_exception;	// lance
      _ORBIT_completion_status = CORBA_COMPLETED_MAYBE;
      giop_send_buffer_unuse(_ORBIT_send_buffer);
      _ORBIT_send_buffer = NULL;
   }
   {				/* demarshalling */
      register guchar *_ORBIT_curptr;

      _ORBIT_recv_buffer =
	 giop_recv_reply_buffer_use_2(_cnx, _ORBIT_request_id, TRUE);
      if (!_ORBIT_recv_buffer)
	 goto _ORBIT_system_exception;
      _ORBIT_completion_status = CORBA_COMPLETED_YES;
      if (_ORBIT_recv_buffer->message.u.reply.reply_status !=
	  GIOP_NO_EXCEPTION) goto _ORBIT_msg_exception;
      _ORBIT_curptr = GIOP_RECV_BUFFER(_ORBIT_recv_buffer)->cur;
      if (giop_msg_conversion_needed(GIOP_MESSAGE_BUFFER(_ORBIT_recv_buffer))) {
	 _ORBIT_curptr = ALIGN_ADDRESS(_ORBIT_curptr, 4);
	 
	    (*((guint32 *) & (_ORBIT_tmpvar_3))) =
	    GUINT32_SWAP_LE_BE(*((guint32 *) _ORBIT_curptr));
	 _ORBIT_curptr += 4;
	 _ORBIT_retval = CORBA_string_alloc(_ORBIT_tmpvar_3);
	 memcpy(_ORBIT_retval, _ORBIT_curptr,
		sizeof(_ORBIT_retval[_ORBIT_tmpvar_2]) * _ORBIT_tmpvar_3);
	 _ORBIT_curptr +=
	    sizeof(_ORBIT_retval[_ORBIT_tmpvar_2]) * _ORBIT_tmpvar_3;
      } else {
	 _ORBIT_curptr = ALIGN_ADDRESS(_ORBIT_curptr, 4);
	 _ORBIT_tmpvar_3 = *((CORBA_unsigned_long *) _ORBIT_curptr);
	 _ORBIT_curptr += 4;
	 _ORBIT_retval = CORBA_string_alloc(_ORBIT_tmpvar_3);
	 memcpy(_ORBIT_retval, _ORBIT_curptr,
		sizeof(_ORBIT_retval[_ORBIT_tmpvar_2]) * _ORBIT_tmpvar_3);
	 _ORBIT_curptr +=
	    sizeof(_ORBIT_retval[_ORBIT_tmpvar_2]) * _ORBIT_tmpvar_3;
      }
      giop_recv_buffer_unuse(_ORBIT_recv_buffer);
      return _ORBIT_retval;
    _ORBIT_system_exception:
      CORBA_exception_set_system(ev, _ORBIT_system_exception_minor,
				 _ORBIT_completion_status);
      giop_recv_buffer_unuse(_ORBIT_recv_buffer);
      giop_send_buffer_unuse(_ORBIT_send_buffer);
      return _ORBIT_retval;
    _ORBIT_msg_exception:
      if (_ORBIT_recv_buffer->message.u.reply.reply_status ==
	  GIOP_LOCATION_FORWARD) {
	 if (_obj->forward_locations != NULL)
	    ORBit_delete_profiles(_obj->forward_locations);
	 _obj->forward_locations = ORBit_demarshal_IOR(_ORBIT_recv_buffer);
	 _cnx = ORBit_object_get_forwarded_connection(_obj);
	 giop_recv_buffer_unuse(_ORBIT_recv_buffer);

	 goto _ORBIT_retry_request;
      } else {
	 ORBit_handle_exception(_ORBIT_recv_buffer, ev, NULL, _obj->orb);
	 giop_recv_buffer_unuse(_ORBIT_recv_buffer);
	 return _ORBIT_retval;
      }
   }
}

[orbitcpp-list] What does this error message mean?

[Richard A. <ric...@ix...>]

If anyone actually reads this list...

I've just managed to get ORBit-cpp 0.29 to build with ORBit-0.5.4-helix
but when I try to use it I get the following errors from orbit-idl

orbit-idl -lc++ test.idl

** WARNING **: Module load failed:
/usr/lib/orbit-idl/liborbit-idl-c++-backend.so: undefined symbol:
__vt_9exception

** CRITICAL **: file orbit-idl-driver.c: line 50 (orbit_idl_to_backend):
assertion `binfo && binfo->op_output' failed.

** WARNING **: test.idl compilation failed


Please reply directly as I'm not on this list

Thanks

Rich

<ric...@ix...>

[orbitcpp-list] Re: Problem in orbitcpp_tools.cc

[John L. <jk...@lu...>]

> Hi!
> I upgraded Orbitcpp from version 0.28.1 to 0.29 and I found a little
> problem: compilation of file orbitcpp_tools.cc fails on method
> _orbitcpp::TypeCode_allocate() - compiler cannot find functions
> ORBit_RootObject_init() and ORBit_TypeCode_dup().
> What's up?
> Will using newest CVS ORBit version solve the problem?
>
> Kuba

Hmm... it seems you are using the orbitcpp CVS version not 0.29. But
that is irrelevant because both need a more up to date version of ORBit.
So the best bet is to get a special snapshot that Phil put together. You
go to the orbitcpp download page and take a look at the release notes
for 0.29, which has a link to both the ORBit sources and GTK+ 2.0. You
can use ORBit CVS but sometimes it won't compile. Also, remember not to
put ORBit where it will conflict with 0.5.4 or the newly released 0.5.5
because gnome's CORBA stuff doesn't play nice with bleeding edge ORBit.

John

[orbitcpp-list] Problem in orbitcpp_tools.cc

[<kp...@po...>]

Hi!
I upgraded Orbitcpp from version 0.28.1 to 0.29 and I found a little problem: compilation of file orbitcpp_tools.cc fails on method _orbitcpp::TypeCode_allocate() - compiler cannot find functions ORBit_RootObject_init() and ORBit_TypeCode_dup().
What's up?
Will using newest CVS ORBit version solve the problem?

Kuba

Re: [orbitcpp-list] two rookie questions: initialization, object validation

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

Hi Lance,

la...@se... writes:
 > First, is it possible to check if orit has already been initialized?
 > Calling orb =CORBA::ORB_init(argc, argv, "orbit-local-orb")
 > more than once crashes.  For now, I will keep a local flag.
 > 

Err.. not on my machine it doesn't. Which version of orbitcpp / ORBit
are you running.


 > Perhaps more importanly, if the server has gone down, what
 > is the best way for the client to avoid hanging or crashing on
 > subsequent calls to that server?  Is there a way to validate
 > the object such as objectPointer->isWorking() or even
 > objectPointer->wontHang().  Perhaps I can embed and
 > catch an alarm signal before each client call.
 > 

I'm not sure about this one. If orbit is unable to connect to the
server you get a CORBA::COMM_FAILURE system exception. However if
ORBit has previously connected to the server then you do seem to get a
hang. I'll do some experimenting over the weekend...

Cheers,

Phil

[orbitcpp-list] two rookie questions: initialization, object validation

[<la...@se...>]

First, is it possible to check if orit has already been initialized?
Calling orb =CORBA::ORB_init(argc, argv, "orbit-local-orb")
more than once crashes.  For now, I will keep a local flag.

Perhaps more importanly, if the server has gone down, what
is the best way for the client to avoid hanging or crashing on
subsequent calls to that server?  Is there a way to validate
the object such as objectPointer->isWorking() or even
objectPointer->wontHang().  Perhaps I can embed and
catch an alarm signal before each client call.

Any elightenment appreciated.  Thanks,  -Lance.

--
-=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=-
Lance Welsh              la...@se...
Seascape Communications  (650) 327-6890
-=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=-

Re: [orbitcpp-list] Re: Gearing up for release 0.30

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

Hi Martin,

I've grabbed a copy of ORBit-2.3.0 so I'll try and get it to work on
my train journey home tonight. 

Thanks for your

Cheers,

Phil

Martin Schulze writes:
 > Hi,
 > 
 > Maybe you should also make orbitcpp link against the latest
 > ORBit2-preview that was recently announced on the orbit-list.
 > 
 > It seems that there are only few changes necessary:
 > 
 > - the conviniece-macros TC_short, TC_..., ...,
 >   ORBit_TypeCode_release, ORBit_TypeCode_dup
 >   aren't defined at the moment (affects orbitcpp_any.hh,
 >   the latter orbitcpp_tools.hh)
 > 
 > - in orbitcpp_poa.hh it has to be:
 >   ORBITCPP_DECLARE_SIMPLE_SEQUENCE(CORBA::Octet,
 >                 CORBA_sequence_CORBA_octet__alloc,
 >                 CORBA_sequence_CORBA_octet_allocbuf,
 >                 PortableServer_ObjectId,
 >                 ObjectId)
 > 
 > - CORBA_Object_struct has been renamed to CORBA_Object_type
 >   (affects orbitcpp_object.hh)
 > 
 > - Hmm, no this is annoying: the orbitcpp-backend isn't working any more:
 >   ** CRITICAL **: file orbit-idl-driver.c: line 50 (orbit_idl_to_backend):
 > assertion `binfo && binfo->op_output' failed
 >   (every idl-file generates the same output)
 >   Hopefully this is an obvious bug to you!
 > 
 > I'm looking forward to orbitcpp-0.30!
 > 
 > Cheers,
 >   Martin
 > 
 > 
 > _______________________________________________
 > orbitcpp-list mailing list
 > orb...@li...
 > http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list
 > 

[orbitcpp-list] Re: passing a reference to another process

[<MHL...@t-...>]

On 11/22/2000, 03:11:36 Phil Dawes wrote:
> Hi Martin,
> 
> Glad you solved your problem - sorry about my reply arriving too
> late.
> 
> I agree that it`s unfortunate that this sort of mistake results in
> such a nebulus error - can you think of a way we could trap this in
> orbitcpp?.
> 

The problem is that all variables xxx_ptr that get initialized from
the same reference xxx_var point to a "profile_list". This profile_list
is freed when xxx_var is destroyed (unless the reference is duplicated,
of course). Now can you look at a xxx_ptr and say whether
profile_list still points to a valid memory block or not ?
I found my bug because "next" in profile_list was 0x0 but that doesn't
necessarily have to be the case.

Hmm, perhaps we could define a macro like

#ifdef DEBUG
#define REFERENCE_IS_VALID(obj) \
	if(obj->profile_list) obj->profile_list->data->profile_type = \
		obj->profile_list->data->profile_type;
#else
#define REFERENCE_IS_VALID(obj)
#endif

and use it in the cpp-stubs before passing obj to the c-stub which
in turn passes it to liborbit where the segfault happens.
I think this macro should a segfault?! If yes the users attendence
should be drawn on the right track!

Anyway I think it would be good to add a few
comments to client.cc in the test everything. People that start using a new
library will first have a look at the examples. Maybe you could modify the
program a little so that it stores a refence to a Factory and use it later
in another function.


Cheers,
  Martin.

[orbitcpp-list] Re: Gearing up for release 0.30

[<MHL...@t-...>]

Hi,

Maybe you should also make orbitcpp link against the latest
ORBit2-preview that was recently announced on the orbit-list.

It seems that there are only few changes necessary:

- the conviniece-macros TC_short, TC_..., ...,
  ORBit_TypeCode_release, ORBit_TypeCode_dup
  aren't defined at the moment (affects orbitcpp_any.hh,
  the latter orbitcpp_tools.hh)

- in orbitcpp_poa.hh it has to be:
  ORBITCPP_DECLARE_SIMPLE_SEQUENCE(CORBA::Octet,
                CORBA_sequence_CORBA_octet__alloc,
                CORBA_sequence_CORBA_octet_allocbuf,
                PortableServer_ObjectId,
                ObjectId)

- CORBA_Object_struct has been renamed to CORBA_Object_type
  (affects orbitcpp_object.hh)

- Hmm, no this is annoying: the orbitcpp-backend isn't working any more:
  ** CRITICAL **: file orbit-idl-driver.c: line 50 (orbit_idl_to_backend):
assertion `binfo && binfo->op_output' failed
  (every idl-file generates the same output)
  Hopefully this is an obvious bug to you!

I'm looking forward to orbitcpp-0.30!

Cheers,
  Martin

Re: [orbitcpp-list] Gearing up for release 0.30

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

John Luebs <jk...@lu...> wrote:
>
> Being able to do this stuff is contingent on being able to successfully
> do a 'cvs update' sometime in the near future....You would think that
> sourceforge would do system maintenance during midday or afternoon not
> late at night when people really get this kind of work done..

Late at night for who? It's early evening here (Australia).

Where in the world are you, anyway? I think you, Phil and I are all on
different continents. Cool.
--=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] Gearing up for release 0.30

[John L. <jk...@lu...>]

It is a holiday week for me and yes I do have the time for (a) making
some test for any and I might throw in some more aggressive sequence and
array testing (b) putting the finishing touches on the Any
implementation to include methods involving Typecodes, and provide
Any_var (c) fixing the TypeCode constant generation in the compiler and
having the generated Any inserter/extractors use those generated
TypeCode constants. (d) Get IDLArray to generate Array_forany and the
inserter/extractors. (e) Look for anything stupid in some of the
modifications I made to IDLArray and friends, and make sure things are
clean.
Being able to do this stuff is contingent on being able to successfully
do a 'cvs update' sometime in the near future....You would think that
sourceforge would do system maintenance during midday or afternoon not
late at night when people really get this kind of work done..

John

Re: [orbitcpp-list] Gearing up for release 0.30

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

Phil Dawes <ph...@us...> wrote:
>=20
> Sam, I'll have a few hours free later on this week to do the Typecode
> merge if you'd like. Is the patch you sent to the list a couple of
> weeks ago up to date?

They are, but I haven't done any work on integrating them with John's Any
support yet.

I did spend some time building ORBit-C++ against ORBit-mt and testing some
of the multithread features. Works real good. All that's missing is the
thread policy stuff on the POA object, which doesn't matter if you use the
default thread policy. I need to work out how I can (cleanly) modify the
configure script and such to add a command-line argument to compile against
ORBit-mt.
--=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] Re: passing a reference to another process

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

Hi Martin,

Glad you solved your problem - sorry about my reply arriving too
late. 

I agree that it's unfortunate that this sort of mistake results in
such a nebulus error - can you think of a way we could trap this in
orbitcpp?.

Cheers,

Phil


Martin Schulze writes:
 > Hi,
 > 
 > I'm sorry to have bothered you that way!
 > After a few hours' debugging session I found I made a silly mistake:
 > 
 > I didn't _duplicate() the reference in pA (I thought everything would
 > be fine duplicating it in pB, the prosess that holds the referred
 > object) so it got freed at the end of the cpp-skeleton of the retrieving
 > function and my reference got invalid.
 > However a SEGFAULT in my opinion is a little overreacted; but this is
 > not an orbitcpp- but an orbit-related topic.
 > 
 > Cu, Martin.
 > 

[orbitcpp-list] Gearing up for release 0.30

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

Ladies & Gentlemen,

The Union support is now complete, and I'd like to do a new orbitcpp
release asap (release early, release often - all that kind of
thing). 

So the question is: do we include full Typecode and Any support in
0.30, or delay until 0.31?

As far as I can see, the following needs doing before we can say we
support Typecode and Any:

1) A test for John's Any stuff needs including in test/everything

2) Sam's typecode stuff needs integrating with the current build, so
that the Any support can use CORBA::Typecode rather than
CORBA_typecode.

3) Need to write compiler 'deep copy' code for any and typecode so
that they work in arrays and unions correctly.

4) Need a test for typecode and the above deep copy stuff.


John, have you got time to do (1)? - You've probably got more
experience with Any than any-one else here.

Sam, I'll have a few hours free later on this week to do the Typecode
merge if you'd like. Is the patch you sent to the list a couple of
weeks ago up to date?

Ideally I'd like to get 0.30 out in the next couple of weeks, and
maybe do a freshmeat announce etc...

Cheers,

Phil

Re: [orbitcpp-list] passing a reference to another process

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

Hi Martin,

Sorry for the late reply - I've been a bit busy recently (and it took
me a couple of reads to understand this mail ;-)

Martin Schulze writes:
 > 
 > Hi,
 > 
 > I ran into some troubles implementing a signal-slot-technology
 > with CORBA-objects:
 > 
 > 
 > Given three processes pA, pB, pC.
 > Is it possible to pass a reference retrieved in process pC from
 > the IOR referring to an object in the address space of pB
 > to process pA directly ?
 > 

Yes, you can pass the object reference as an idl argument to a corba
method. You must ensure that you call the relevant reference
'_duplicate' function though. (This duplicates the object reference,
not the corba object implementation)

e.g. for function returning a reference to interface foo:

  return foo::_duplicate(myfooreference);


 > 
 > 
 > In details:
 > 
 > Let's say I have interfaces iA, iAA, iB, iBB.
 > class iA_impl contains a class iAA_impl (= oAA),
 > class iB_impl contains a calss iBB_impl (= oBB).
 > 
 > Now I have two processes running, pA and pB.
 > pA has an iA_impl on the heap (= oA), pB an iB_impl (= oB).
 > 

With you so far (I think).

 > A third process pC is created, retrieving refences to oA and oB
 > through their IORs. A function of iA is called, returning a
 > reference to oAA and a function of iB gives a reference to oBB.
 > Now a function of iAA is called, giving the REFERENCE to oBB
 > AS its ARGUMENT.

Yep - sounds okay. (must do your _duplicates though).

 > 
 > Another function of oAA is called. It implicitely calls a function
 > of oBB - so process pA uses the reference of oBB that was
 > retrieved in process pC.
 > 
 > => A SEGFAULT in pA occurs in the function _orb_get_connection
 > called by the skel of the very last function call mentioned obove.
 > => Bug in orbit or my design error ???
 > 
 >

Unlike EJB, CORBA doesn't have any rules govening callback functions
(recursive calls etc), so this should all work AFAIK. 

It's a little difficult to see what the problem could be without code
- could you send me a copy of your idl and impl C++ files?

Cheers,

Phil

[orbitcpp-list] Re: passing a reference to another process

[<MHL...@t-...>]

Hi,

I'm sorry to have bothered you that way!
After a few hours' debugging session I found I made a silly mistake:

I didn't _duplicate() the reference in pA (I thought everything would
be fine duplicating it in pB, the prosess that holds the referred
object) so it got freed at the end of the cpp-skeleton of the retrieving
function and my reference got invalid.
However a SEGFAULT in my opinion is a little overreacted; but this is
not an orbitcpp- but an orbit-related topic.

Cu, Martin.

_______________________________________________________________________
On Son, 19 Nov 2000 00:31:21 Martin Schulze wrote:
> 
> On Son, 19 Nov 2000 00:08:36 Martin Schulze wrote:
> Hi,
> 
> I ran into some troubles implementing a signal-slot-technology
> with CORBA-objects:
> 
> 
> Given three processes pA, pB, pC.
> Is it possible to pass a reference retrieved in process pC from
> the IOR referring to an object in the address space of pB
> to process pA directly ?
> 
> [snip]
> 

Re: [orbitcpp-list] Re: minor bug in the make system

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

John Luebs <jk...@lu...> wrote:
>=20
> Hehe, Thanks for giving me my 5 minutes of fame Phil! Sam, I was
> wondering what you are waiting for in regards to checking in your
> TypeCode support.
>=20
> John 'I am the prettiest girl at the dance' Luebs

Mostly just time. I was previously building against the Debian woody ORBit
libraries, not CVS ORBit. So I need to build that, then build ORBit-C++ and
make sure my TypeCode stuff still compiles. And all of this during my
Copious Spare Time (tm).

Feel free to commit the patches I sent to the list a couple of weeks ago.

Sam 'I need at least 28 hours in each day' Couter
--=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] passing a reference to another process

[<MHL...@t-...>]

On Son, 19 Nov 2000 00:08:36 Martin Schulze wrote:
Hi,

I ran into some troubles implementing a signal-slot-technology
with CORBA-objects:


Given three processes pA, pB, pC.
Is it possible to pass a reference retrieved in process pC from
the IOR referring to an object in the address space of pB
to process pA directly ?



In details:

Let's say I have interfaces iA, iAA, iB, iBB.
class iA_impl contains a class iAA_impl (= oAA),
class iB_impl contains a calss iBB_impl (= oBB).

Now I have two processes running, pA and pB.
pA has an iA_impl on the heap (= oA), pB an iB_impl (= oB).

A third process pC is created, retrieving refences to oA and oB
through their IORs. A function of iA is called, returning a
reference to oAA and a function of iB gives a reference to oBB.
Now a function of iAA is called, giving the REFERENCE to oBB
AS its ARGUMENT.

Another function of oAA is called. It implicitely calls a function
of oBB - so process pA uses the reference of oBB that was
retrieved in process pC.

=> A SEGFAULT in pA occurs in the function _orb_get_connection
called by the skel of the very last function call mentioned obove.
=> Bug in orbit or my design error ???



In ASCII:
___________________________________________________________________

Process:	pA				pB					pC
		=======			=======				=======
Heap:		oA   <-----		oB   <-----
		-oAA <--  |		-oBB <--  |
		       |  |		       |  |
Refs:		       |  |		       |  --(IOR)-- rB
		       |  |		       --(rB->f())- rBB <--
		       |  |							      |
		       |  -----------(IOR)--------- rA    |
		       -----------(rA->f1())------- rAA   |
											      |
		-rBB -------------(rA->f2(rBB))------------

(xx->fx(): function calls invoked in pC for retrieving the references)

In pA: oA.rBB->callback() segfaults !

______________________________________________________________________



Sorry for this being a little long!

cu Martin.

[orbitcpp-list] Re: minor bug in the make system

[John L. <jk...@lu...>]

>  > You did a great job an CORBA::Any by the way.
> 
> Thanks, but John Leubs is the guy you should be thanking for this!
> 
> Cheers,
> 
> Phil 'credit where credit's due' Dawes
> 
> --__--__--

Hehe, Thanks for giving me my 5 minutes of fame Phil! Sam, I was
wondering what you are waiting for in regards to checking in your
TypeCode support.

John 'I am the prettiest girl at the dance' Luebs

Re: [orbitcpp-list] Re: minor bug in the make system

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

Martin Schulze writes:
 > Phil Dawes wrote
 > >
 > > Hope this helps,
 > > Phil
 > 
 > Thank's for your help - I hope installing two different versions
 > of the same library will get more convinient some day ...

Agreed.  
Actually, more than that, I hope that a decent version of ORBit makes
it into gnome one day!

 > You did a great job an CORBA::Any by the way. 

Thanks, but John Leubs is the guy you should be thanking for this!

Cheers,

Phil 'credit where credit's due' Dawes

[orbitcpp-list] Re: minor bug in the make system

[<MHL...@t-...>]

Phil Dawes wrote

> Hi Martin,
> Martin Schulze writes:
>
> > Hi !
> > There are two or three little bugs in the make system of orbitcpp:
> > - The makefiles in the directories test/.../generated depend on the
> > makro ORBIT_IDL that isn`t defined anywhere.
> It`s generated by the configure script. See AM_PATH_ORBIT() macro in
> ORBit.m4.
Ah, I see! It now works (see below).

> > - The makefiles in the directories test/... define the makro
> > ORBIT_NAME_LIBS but try to make use of the makro
> > ORBIT_LIBS that hasn`t been defined.
> Again, it`s generated by the above macro. (which in turn calls
> `orbit-config --libs client`)
Hmm, I had some problems with autogen.sh. After getting a brand new
version of libtool I still have to append the contents of a file
libtool.m4 to e.g. acinclude.m4 in the orbitcpp-path, but well ...
ORBIT_LIBS indeed is now defined correctly.

> > - The makefile services/name/Makefile directly uses the command
> > orbit-idl not caring about the "--wtih-orbit-exec-prefix" - flag one
> > can give to configure.
> Yep - that`s a bug. It should use the ORBIT_IDL macro. Thanks for finding
> this. (fixed in CVS now!)
Ok.

> > - Missing feature: a "--with-orbit-include-prefix" - flag !
> > After correcting those, orbitcpp and the examples make and install
> > as expected but I can`t run the examples!
> > I installed the orbit-snapshot and the orbitcpp-CVS-version in the
> > directory "/opt/orbit" so that there is no interference with my
> > running gnome-system and added "/opt/orbit/lib" to "/etc/ld.so.conf"
> > (and run ldoncfig).
> You shouldn`t do this - instead, use the LD_LIBRARY_PATH to identify the
> /opt/orbit/lib directory. The point is that you want your code to use
> this library; the dynamic linker will link with the first lib it finds -
> if you just append /opt/orbit/lib to the end of ld.so.conf it will find
> your original lib first.
You're so right - I moved the entry in ld.so.conf to the top of the file
and it had no effect. So back to LD_LIBRARY_PATH ...

> > When I type "server" in the directory "test/string",
> > the program quits and gives the following error message:
> >
> > server: error in loading shared libraries: server: undefined symbol:
> > ORBit_classinfo_register
> >
> > Did the sources link to the old version of orbit?
> That sounds likely. You need to do the following:
> 1) Set your PATH and LD_LIBRARY_PATH:
> export PATH=/opt/orbit/bin:$PATH
> export LD_LIBRARY_PATH=/opt/orbit/lib:$LD_LIBRARY_PATH
> 2) Run autogen.sh --prefix=/opt/orbitcpp This should now all work.
> (Setting the PATH to /opt/orbit/bin should enable configure to find the
> correct orbit-config, which should point the makefiles at the right
> include and lib directories.)
>
> Hope this helps,
> Phil

Thank's for your help - I hope installing two different versions
of the same library will get more convinient some day ...

You did a great job an CORBA::Any by the way. I'm working on
CORBA-support for libsigc++ - should soon be finisched.

Martin.

Re: [orbitcpp-list] minor bug in the make system

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

Hi Martin,


Martin Schulze writes:
 > Hi !
 > 
 > There are two or three little bugs in the make system of orbitcpp:
 > 
 > - The makefiles in the directories test/.../generated depend on the
 > makro ORBIT_IDL that isn't defined anywhere.
 > 

It's generated by the configure script. See AM_PATH_ORBIT() macro in
ORBit.m4.

 > - The makefiles in the directories test/... define the makro
 > ORBIT_NAME_LIBS but try to make use of the makro
 > ORBIT_LIBS that hasn't been defined.
 > 

Again, it's generated by the above macro. (which in turn calls
`orbit-config --libs client`)

 > - The makefile services/name/Makefile directly uses the command
 > orbit-idl not caring about the "--wtih-orbit-exec-prefix" - flag one
 > can give to configure.
 > 

Yep - that's a bug. It should use the ORBIT_IDL macro. Thanks for
finding this. (fixed in CVS now!)

 > - Missing feature: a "--with-orbit-include-prefix" - flag !
 > 
 > 
 > After correcting those, orbitcpp and the examples make and install
 > as expected but I can't run the examples!
 > I installed the orbit-snapshot and the orbitcpp-CVS-version in the
 > directory "/opt/orbit" so that there is no interference with my
 > running gnome-system and added "/opt/orbit/lib" to "/etc/ld.so.conf"
 > (and run ldoncfig). 

You shouldn't do this - instead, use the LD_LIBRARY_PATH to identify
the /opt/orbit/lib directory. The point is that you want your code to
use this library; the dynamic linker will link with the first lib it
finds - if you just append /opt/orbit/lib to the end of ld.so.conf it
will find your original lib first.

 > When I type "server" in the directory "test/string",
 > the program quits and gives the following error message:
 > 
 > server: error in loading shared libraries: server: undefined symbol:
 > ORBit_classinfo_register
 > 
 > Did the sources link to the old version of orbit?
 >

That sounds likely.
 

You need to do the following:

1) Set your PATH and LD_LIBRARY_PATH:

export PATH=/opt/orbit/bin:$PATH
export LD_LIBRARY_PATH=/opt/orbit/lib:$LD_LIBRARY_PATH

2) Run autogen.sh --prefix=/opt/orbitcpp


This should now all work. (Setting the PATH to /opt/orbit/bin should
enable configure to find the correct orbit-config, which should point
the makefiles at the right include and lib directories.

Hope this helps,

Phil

[orbitcpp-list] minor bug in the make system

[<MHL...@t-...>]

Hi !

There are two or three little bugs in the make system of orbitcpp:

- The makefiles in the directories test/.../generated depend on the
makro ORBIT_IDL that isn't defined anywhere.

- The makefiles in the directories test/... define the makro
ORBIT_NAME_LIBS but try to make use of the makro
ORBIT_LIBS that hasn't been defined.

- The makefile services/name/Makefile directly uses the command
orbit-idl not caring about the "--wtih-orbit-exec-prefix" - flag one
can give to configure.

- Missing feature: a "--with-orbit-include-prefix" - flag !


After correcting those, orbitcpp and the examples make and install
as expected but I can't run the examples!
I installed the orbit-snapshot and the orbitcpp-CVS-version in the
directory "/opt/orbit" so that there is no interference with my
running gnome-system and added "/opt/orbit/lib" to "/etc/ld.so.conf"
(and run ldoncfig). When I type "server" in the directory "test/string",
the program quits and gives the following error message:

server: error in loading shared libraries: server: undefined symbol:
ORBit_classinfo_register

Did the sources link to the old version of orbit?


Thanks for any help,

   Martin

[orbitcpp-list] Re: Where's the Any support

[John L. <jk...@lu...>]

Yes, the Any support is based on features rather new to ORBit. You have
two options: ORBit CVS (which as of this writing will not build due to a
configure script problem, it has to be modified a bit), but the orbitcpp
CVS should build fine with ORBit CVS snapshot that is "released" for use
with orbitcpp found at this address:
ftp://orbitcpp.sourceforge.net/pub/orbitcpp/ORBit-cvs-20000918.tar.gz
You also should install this in a place like /opt/glib2.0 and then
configure ORBit with options: --prefix=(not /usr or /usr/local)
--with-glib-prefix=/opt/glib2.0
ftp://ftp.gtk.org/pub/gtk/v1.3/

Please note that you must make sure to install all this stuff in another
prefix, definitely not /usr or /usr/local, something like /opt/ORBit (or
whatever directory you want), because any libraries on your machine with
code generated from an old ORBit IDL compiler will fail!

John Luebs

Re: [orbitcpp-list] Re: Where's the Any support

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

On Sun, 12 Nov 2000, ERDI Gergo wrote:

> Now it is, thanks. But it wasn't in the afternoon.

Do I need some super-ultra-mega-latest ORBit for the new stuff to work?
orbitcpp_tools.cc: In function `struct CORBA_TypeCode_struct *
_orbitcpp::TypeCode_allocate()':
orbitcpp_tools.cc:68: implicit declaration of function `int
ORBit_RootObject_init(...)'
orbitcpp_tools.cc:69: implicit declaration of function `int
ORBit_TypeCode_dup(...)'

(with ORBit 0.5.4)

-- 
   .--= ULLA! =----------------------------.  finger ca...@ca...
   \      http://cactus.rulez.org           \   for PGP public key
    `----------= ca...@ca... =--'
Windows '95. Az eredeti. Csak az EDLIN készítôitôl.