f



RE: [ace-users] RE: [tao-users] Octet Marshaling/Demarshaling issues #2

Hi,

If you marshal a corba sequence of octet then instead of the normal << and
>> for each element the methods write_octet_array and read_octet_array on
the stream are used, in fact, all corba sequences of basic types to use
array methods on the cdr stream. If you handle your own cdr streaming you
can of course use these methods also.

Regards,

Johnny Willemsen
Remedy IT
Postbus 101
2650 AC  Berkel en Rodenrijs
The Netherlands
www.theaceorb.nl / www.remedy.nl  

> -----Original Message-----
> From: owner-ace-users@cse.wustl.edu 
> [mailto:owner-ace-users@cse.wustl.edu] On Behalf Of Krishna, Arvind
> Sent: woensdag 28 december 2005 19:55
> To: Kobi Cohen-Arazi; ace-users@cs.wustl.edu; tao-users@cs.wustl.edu
> Subject: [ace-users] RE: [tao-users] Octet 
> Marshaling/Demarshaling issues
> 
> 
> Hi Kobi,
> 
> >It takes 4 bytes to marshal a single Octet. However, when 
> marshaling an
> array of Octet, it takes a single byte for >every element in 
> the array.
> It seems that Octet is an exception comparing the rest of 
> primitive data
> types. What is >the motivation for that? Is it dictated by an 
> OMG spec? 
> 
> I think you might be seeing a type promotion from octet to 
> long. I just
> checked and ACE_CDR provides a read_octet and write_octet methods for
> reading/writing octets. However, if you use the insertion/extraction
> operator then octet will be type promoted as ACE_CDR does not provide
> the appropriate << and >> methods. Is this what you are seeing?
> 
> HTH,
> Arvind
> 


















0
Johnny
12/28/2005 8:50:43 PM
comp.soft-sys.ace 20326 articles. 1 followers. marlow.andrew (167) is leader. Post Follow

2 Replies
845 Views

Similar Articles

[PageSpeed] 1

------=_Part_4883_30641174.1135820753238
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi Jeff,

I'm not sure I see the behavior you describes. When marshaling one octet at
a time, 4 bytes are marshaled.
When marshaling an octet array, one byte per Octet is marshaled.


Thanks,
Kobi.

On 12/28/05, Jeff Parsons <j.parsons@vanderbilt.edu> wrote:
>
> Hi,
>
> The padding added after marshalin an octet depends on what comes next in
> the
> stream. For this
>
> struct foo
> {
>   long one;
>   octet two;
>   long three;
> };
>
> there will indeed be 4 total bytes used for the octet, since the type tha=
t
> follows
> it must be aligned to a 4-byte boundary, and we know that the octet
> marshaling
> started on a 4-byte boundary because of the previous member. However this
> is
> not always the case. For example,
>
> struct bar
> {
>   long one;
>   octet two;
>   octet three;
>   octet four;
>   octet five;
>   long six;
> };
>
> will use just 1 byte for each octet, since by the time we get to 'six', w=
e
> are
> already aligned to a 4-byte boundary, so no additional padding is
> necessary.
>
> Jeff
>
>  ------------------------------
> *From:* owner-tao-users@cse.wustl.edu [mailto:
> owner-tao-users@cse.wustl.edu] *On Behalf Of *Johnny Willemsen
> *Sent:* Wednesday, December 28, 2005 1:08 PM
> *To:* Krishna, Arvind; Kobi Cohen-Arazi; tao-users@cs.wustl.edu
> *Subject:* RE: [ace-users] RE: [tao-users] Octet Marshaling/Demarshaling
> issues
>
>  Hi,
>
> If you marshal a corba sequence of octet then instead of the normal << an=
d
> >> for each element the methods write_octet_array and read_octet_array on
> the stream are used, in fact, all corba sequences of basic types to use
> array methods on the cdr stream. If you handle your own cdr streaming you
> can of course use these methods also.
>
> Regards,
>
> Johnny Willemsen
> Remedy IT
> Postbus 101
> 2650 AC  Berkel en Rodenrijs
> The Netherlands
> www.theaceorb.nl / www.remedy.nl
>
> > -----Original Message-----
> > From: owner-ace-users@cse.wustl.edu
> > [mailto:owner-ace-users@cse.wustl.edu <owner-ace-users@cse.wustl.edu>]
> On Behalf Of Krishna, Arvind
> > Sent: woensdag 28 december 2005 19:55
> > To: Kobi Cohen-Arazi; ace-users@cs.wustl.edu; tao-users@cs.wustl.edu
> > Subject: [ace-users] RE: [tao-users] Octet
> > Marshaling/Demarshaling issues
> >
> >
> > Hi Kobi,
> >
> > >It takes 4 bytes to marshal a single Octet. However, when
> > marshaling an
> > array of Octet, it takes a single byte for >every element in
> > the array.
> > It seems that Octet is an exception comparing the rest of
> > primitive data
> > types. What is >the motivation for that? Is it dictated by an
> > OMG spec?
> >
> > I think you might be seeing a type promotion from octet to
> > long. I just
> > checked and ACE_CDR provides a read_octet and write_octet methods for
> > reading/writing octets. However, if you use the insertion/extraction
> > operator then octet will be type promoted as ACE_CDR does not provide
> > the appropriate << and >> methods. Is this what you are seeing?
> >
> > HTH,
> > Arvind
> >
>
>

------=_Part_4883_30641174.1135820753238
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi Jeff,<br><br>I'm not sure I see the behavior you describes. When marshal=
ing one octet at a time, 4 bytes are marshaled.<br>When marshaling an octet=
 array, one byte per Octet is marshaled.<br><br><br>Thanks,<br>Kobi.<br>
<br><div><span class=3D"gmail_quote">On 12/28/05, <b class=3D"gmail_sendern=
ame">Jeff Parsons</b> &lt;<a href=3D"mailto:j.parsons@vanderbilt.edu">j.par=
sons@vanderbilt.edu</a>&gt; wrote:</span><blockquote class=3D"gmail_quote" =
style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8=
ex; padding-left: 1ex;">





<div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2">Hi,</font></span></div>
<div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2"></font></span>&nbsp;</div>
<div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2">The padding added after marshalin an octet depends on what=20
comes next in the </font></span></div>
<div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2">stream. For this</font></span></div>
<div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2"></font></span>&nbsp;</div>
<div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2">struct foo</font></span></div>
<div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2">{</font></span></div>
<div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2">&nbsp; long one;</font></span></div>
<div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2">&nbsp; octet two;</font></span></div>
<div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2">&nbsp; long three;</font></span></div>
<div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2">};</font></span></div>
<div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2"></font></span>&nbsp;</div>
<div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2">there will indeed be 4 total bytes used for the octet,=20
since the type that follows</font></span></div>
<div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2">it must be aligned to a 4-byte boundary, and we know that=20
the octet marshaling</font></span></div>
<div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2">started on a 4-byte boundary because of the previous=20
member. However this is</font></span></div>
<div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2">not always the case. For example,</font></span></div>
<div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2"></font></span>&nbsp;</div>
<div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2">struct bar</font></span></div>
<div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2">{</font></span></div>
<div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2">&nbsp; long one;</font></span></div>
<div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2">&nbsp; octet two;</font></span></div>
<div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2">&nbsp; octet three;</font></span></div>
<div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2">&nbsp;&nbsp;octet four;</font></span></div>
<div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2">&nbsp; octet five;</font></span></div>
<div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2">&nbsp; long six;</font></span></div>
<div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2">};</font></span></div>
<div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2"></font></span>&nbsp;</div>
<div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2">will use just 1 byte for each octet, since by the time we=20
get to 'six', we are</font></span></div>
<div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2">already aligned to a 4-byte boundary, so no additional=20
padding is necessary.</font></span></div>
<div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2"></font></span>&nbsp;</div>
<div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2">Jeff</font></span></div><br>
<blockquote dir=3D"ltr" style=3D"border-left: 2px solid rgb(0, 0, 255); pad=
ding-left: 5px; margin-left: 5px; margin-right: 0px;">
  <div dir=3D"ltr" align=3D"left" lang=3D"en-us">
  <hr>
  <font face=3D"Tahoma" size=3D"2"><b>From:</b> <a href=3D"mailto:owner-tao=
-users@cse.wustl.edu" target=3D"_blank" onclick=3D"return top.js.OpenExtLin=
k(window,event,this)">owner-tao-users@cse.wustl.edu</a>=20
  [mailto:<a href=3D"mailto:owner-tao-users@cse.wustl.edu" target=3D"_blank=
" onclick=3D"return top.js.OpenExtLink(window,event,this)">owner-tao-users@=
cse.wustl.edu</a>] <b>On Behalf Of </b>Johnny=20
  Willemsen<br><b>Sent:</b> Wednesday, December 28, 2005 1:08 PM<br><b>To:<=
/b>=20
  Krishna, Arvind; Kobi Cohen-Arazi; <a href=3D"mailto:tao-users@cs.wustl.e=
du" target=3D"_blank" onclick=3D"return top.js.OpenExtLink(window,event,thi=
s)">tao-users@cs.wustl.edu</a><br><b>Subject:</b>=20
  RE: [ace-users] RE: [tao-users] Octet Marshaling/Demarshaling=20
  issues<br></font><br></div>
  <div></div>
  <p><font size=3D"2">Hi,</font> </p><div><span class=3D"e" id=3D"q_108741a=
0f1fcd6cd_1">
  <p><font size=3D"2">If you marshal a corba sequence of octet then instead=
 of the=20
  normal &lt;&lt; and</font> <br><font size=3D"2">&gt;&gt; for each element=
 the=20
  methods write_octet_array and read_octet_array on</font> <br><font size=
=3D"2">the=20
  stream are used, in fact, all corba sequences of basic types to use</font=
>=20
  <br><font size=3D"2">array methods on the cdr stream. If you handle your =
own cdr=20
  streaming you</font> <br><font size=3D"2">can of course use these methods=
=20
  also.</font> </p>
  <p><font size=3D"2">Regards,</font> </p>
  <p><font size=3D"2">Johnny Willemsen</font> <br><font size=3D"2">Remedy I=
T</font>=20
  <br><font size=3D"2">Postbus 101</font> <br><font size=3D"2">2650 AC&nbsp=
; Berkel en=20
  Rodenrijs</font> <br><font size=3D"2">The Netherlands</font> <br><font si=
ze=3D"2"><a href=3D"http://www.theaceorb.nl" target=3D"_blank" onclick=3D"r=
eturn top.js.OpenExtLink(window,event,this)">www.theaceorb.nl</a> / <a href=
=3D"http://www.remedy.nl" target=3D"_blank" onclick=3D"return top.js.OpenEx=
tLink(window,event,this)">
www.remedy.nl</a>&nbsp; </font></p>
  <p><font size=3D"2">&gt; -----Original Message-----</font> <br><font size=
=3D"2">&gt;=20
  From: <a href=3D"mailto:owner-ace-users@cse.wustl.edu" target=3D"_blank" =
onclick=3D"return top.js.OpenExtLink(window,event,this)">owner-ace-users@cs=
e.wustl.edu</a> </font><br><font size=3D"2">&gt; [<a href=3D"mailto:owner-a=
ce-users@cse.wustl.edu" target=3D"_blank" onclick=3D"return top.js.OpenExtL=
ink(window,event,this)">
mailto:owner-ace-users@cse.wustl.edu</a>]=20
  On Behalf Of Krishna, Arvind</font> <br><font size=3D"2">&gt; Sent: woens=
dag 28=20
  december 2005 19:55</font> <br><font size=3D"2">&gt; To: Kobi Cohen-Arazi=
;=20
  <a href=3D"mailto:ace-users@cs.wustl.edu" target=3D"_blank" onclick=3D"re=
turn top.js.OpenExtLink(window,event,this)">ace-users@cs.wustl.edu</a>; <a =
href=3D"mailto:tao-users@cs.wustl.edu" target=3D"_blank" onclick=3D"return =
top.js.OpenExtLink(window,event,this)">
tao-users@cs.wustl.edu</a></font> <br><font size=3D"2">&gt;=20
  Subject: [ace-users] RE: [tao-users] Octet </font><br><font size=3D"2">&g=
t;=20
  Marshaling/Demarshaling issues</font> <br><font size=3D"2">&gt; </font><b=
r><font size=3D"2">&gt; </font><br><font size=3D"2">&gt; Hi Kobi,</font> <b=
r><font size=3D"2">&gt;=20
  </font><br><font size=3D"2">&gt; &gt;It takes 4 bytes to marshal a single=
 Octet.=20
  However, when </font><br><font size=3D"2">&gt; marshaling an</font> <br><=
font size=3D"2">&gt; array of Octet, it takes a single byte for &gt;every e=
lement in=20
  </font><br><font size=3D"2">&gt; the array.</font> <br><font size=3D"2">&=
gt; It seems=20
  that Octet is an exception comparing the rest of </font><br><font size=3D=
"2">&gt;=20
  primitive data</font> <br><font size=3D"2">&gt; types. What is &gt;the mo=
tivation=20
  for that? Is it dictated by an </font><br><font size=3D"2">&gt; OMG spec?=
=20
  </font><br><font size=3D"2">&gt; </font><br><font size=3D"2">&gt; I think=
 you might be=20
  seeing a type promotion from octet to </font><br><font size=3D"2">&gt; lo=
ng. I=20
  just</font> <br><font size=3D"2">&gt; checked and ACE_CDR provides a read=
_octet=20
  and write_octet methods for</font> <br><font size=3D"2">&gt; reading/writ=
ing=20
  octets. However, if you use the insertion/extraction</font> <br><font siz=
e=3D"2">&gt; operator then octet will be type promoted as ACE_CDR does not=
=20
  provide</font> <br><font size=3D"2">&gt; the appropriate &lt;&lt; and &gt=
;&gt;=20
  methods. Is this what you are seeing?</font> <br><font size=3D"2">&gt;=20
  </font><br><font size=3D"2">&gt; HTH,</font> <br><font size=3D"2">&gt; Ar=
vind</font>=20
  <br><font size=3D"2">&gt; </font></p></span></div></blockquote>

</blockquote></div><br>

------=_Part_4883_30641174.1135820753238--

0
Kobi
12/29/2005 3:43:55 AM
This is a multi-part message in MIME format.

------_=_NextPart_001_01C60C79.FEB6F9E4
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

That's what I recall seeing, too (4 bytes marshalled for each individual =
octet inserted into a stream). Arvind, you were going to do some digging =
to determine why there was no streaming operator defined for an octet =
type. The unexpected behavior we see when inserting a single octet into =
a stream is the result of the selection of the int operator<< after the =
octet is promoted to the larger type. At least, that's what I recall.
=20
Vito

________________________________

From: owner-tao-users@cse.wustl.edu on behalf of Kobi Cohen-Arazi
Sent: Wed 12/28/2005 5:45 PM
To: Jeff Parsons
Cc: Johnny Willemsen; Krishna, Arvind; tao-users@cs.wustl.edu
Subject: Re: [ace-users] RE: [tao-users] Octet Marshaling/Demarshaling =
issues


Hi Jeff,

I'm not sure I see the behavior you describes. When marshaling one octet =
at a time, 4 bytes are marshaled.
When marshaling an octet array, one byte per Octet is marshaled.


Thanks,
Kobi.


On 12/28/05, Jeff Parsons <j.parsons@vanderbilt.edu> wrote:=20

	Hi,
	=20
	The padding added after marshalin an octet depends on what comes next =
in the=20
	stream. For this
	=20
	struct foo
	{
	  long one;
	  octet two;
	  long three;
	};
	=20
	there will indeed be 4 total bytes used for the octet, since the type =
that follows
	it must be aligned to a 4-byte boundary, and we know that the octet =
marshaling
	started on a 4-byte boundary because of the previous member. However =
this is
	not always the case. For example,
	=20
	struct bar
	{
	  long one;
	  octet two;
	  octet three;
	  octet four;
	  octet five;
	  long six;
	};
	=20
	will use just 1 byte for each octet, since by the time we get to 'six', =
we are
	already aligned to a 4-byte boundary, so no additional padding is =
necessary.
	=20
	Jeff


________________________________

		From: owner-tao-users@cse.wustl.edu =
[mailto:owner-tao-users@cse.wustl.edu] On Behalf Of Johnny Willemsen
		Sent: Wednesday, December 28, 2005 1:08 PM
		To: Krishna, Arvind; Kobi Cohen-Arazi; tao-users@cs.wustl.edu
		Subject: RE: [ace-users] RE: [tao-users] Octet Marshaling/Demarshaling =
issues
	=09
	=09

		Hi,=20

		If you marshal a corba sequence of octet then instead of the normal << =
and=20
		>> for each element the methods write_octet_array and read_octet_array =
on=20
		the stream are used, in fact, all corba sequences of basic types to =
use=20
		array methods on the cdr stream. If you handle your own cdr streaming =
you=20
		can of course use these methods also.=20

		Regards,=20

		Johnny Willemsen=20
		Remedy IT=20
		Postbus 101=20
		2650 AC  Berkel en Rodenrijs=20
		The Netherlands=20
		www.theaceorb.nl / www.remedy.nl =20

		> -----Original Message-----=20
		> From: owner-ace-users@cse.wustl.edu=20
		> [ mailto:owner-ace-users@cse.wustl.edu =
<mailto:owner-ace-users@cse.wustl.edu> ] On Behalf Of Krishna, Arvind=20
		> Sent: woensdag 28 december 2005 19:55=20
		> To: Kobi Cohen-Arazi; ace-users@cs.wustl.edu; tao-users@cs.wustl.edu =

		> Subject: [ace-users] RE: [tao-users] Octet=20
		> Marshaling/Demarshaling issues=20
		>=20
		>=20
		> Hi Kobi,=20
		>=20
		> >It takes 4 bytes to marshal a single Octet. However, when=20
		> marshaling an=20
		> array of Octet, it takes a single byte for >every element in=20
		> the array.=20
		> It seems that Octet is an exception comparing the rest of=20
		> primitive data=20
		> types. What is >the motivation for that? Is it dictated by an=20
		> OMG spec?=20
		>=20
		> I think you might be seeing a type promotion from octet to=20
		> long. I just=20
		> checked and ACE_CDR provides a read_octet and write_octet methods =
for=20
		> reading/writing octets. However, if you use the insertion/extraction =

		> operator then octet will be type promoted as ACE_CDR does not =
provide=20
		> the appropriate << and >> methods. Is this what you are seeing?=20
		>=20
		> HTH,=20
		> Arvind=20
		>=20



------_=_NextPart_001_01C60C79.FEB6F9E4
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">=0A=
<HTML dir=3Dltr><HEAD><META HTTP-EQUIV=3D"Content-Type" =
CONTENT=3D"text/html; charset=3Dunicode">=0A=
<META content=3D"MSHTML 6.00.2900.2802" name=3DGENERATOR></HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText98123 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3D"Courier New" color=3D#000000 =
size=3D2>That's what I recall =0A=
seeing, too (4 bytes marshalled for each individual octet inserted into =
a =0A=
stream). Arvind, you were going to do some digging to determine why =
there was no =0A=
streaming operator defined for an octet type. The unexpected behavior we =
see =0A=
when inserting a single octet into a stream is&nbsp;the result of the =
selection =0A=
of the int operator&lt;&lt; after the octet is promoted to the larger =
type. At =0A=
least, that's what I recall.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3D"Courier New" color=3D#000000 =
size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3D"Courier New" color=3D#000000 =0A=
size=3D2>Vito</FONT></DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> owner-tao-users@cse.wustl.edu =
on behalf of =0A=
Kobi Cohen-Arazi<BR><B>Sent:</B> Wed 12/28/2005 5:45 PM<BR><B>To:</B> =
Jeff =0A=
Parsons<BR><B>Cc:</B> Johnny Willemsen; Krishna, Arvind; =0A=
tao-users@cs.wustl.edu<BR><B>Subject:</B> Re: [ace-users] RE: =
[tao-users] Octet =0A=
Marshaling/Demarshaling issues<BR></FONT><BR></DIV>=0A=
<DIV>Hi Jeff,<BR><BR>I'm not sure I see the behavior you describes. When =0A=
marshaling one octet at a time, 4 bytes are marshaled.<BR>When =
marshaling an =0A=
octet array, one byte per Octet is =0A=
marshaled.<BR><BR><BR>Thanks,<BR>Kobi.<BR><BR>=0A=
<DIV><SPAN class=3Dgmail_quote>On 12/28/05, <B =
class=3Dgmail_sendername>Jeff =0A=
Parsons</B> &lt;<A =0A=
href=3D"mailto:j.parsons@vanderbilt.edu">j.parsons@vanderbilt.edu</A>&gt;=
 =0A=
wrote:</SPAN> =0A=
<BLOCKQUOTE class=3Dgmail_quote =0A=
style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: =
rgb(204,204,204) 1px solid">=0A=
  <DIV dir=3Dltr align=3Dleft><SPAN><FONT face=3DArial color=3D#0000ff =0A=
  size=3D2>Hi,</FONT></SPAN></DIV>=0A=
  <DIV dir=3Dltr align=3Dleft><SPAN><FONT face=3DArial color=3D#0000ff =0A=
  size=3D2></FONT></SPAN>&nbsp;</DIV>=0A=
  <DIV dir=3Dltr align=3Dleft><SPAN><FONT face=3DArial color=3D#0000ff =
size=3D2>The =0A=
  padding added after marshalin an octet depends on what comes next in =
the =0A=
  </FONT></SPAN></DIV>=0A=
  <DIV dir=3Dltr align=3Dleft><SPAN><FONT face=3DArial color=3D#0000ff =
size=3D2>stream. =0A=
  For this</FONT></SPAN></DIV>=0A=
  <DIV dir=3Dltr align=3Dleft><SPAN><FONT face=3DArial color=3D#0000ff =0A=
  size=3D2></FONT></SPAN>&nbsp;</DIV>=0A=
  <DIV dir=3Dltr align=3Dleft><SPAN><FONT face=3DArial color=3D#0000ff =
size=3D2>struct =0A=
  foo</FONT></SPAN></DIV>=0A=
  <DIV dir=3Dltr align=3Dleft><SPAN><FONT face=3DArial color=3D#0000ff =0A=
  size=3D2>{</FONT></SPAN></DIV>=0A=
  <DIV dir=3Dltr align=3Dleft><SPAN><FONT face=3DArial color=3D#0000ff =
size=3D2>&nbsp; =0A=
  long one;</FONT></SPAN></DIV>=0A=
  <DIV dir=3Dltr align=3Dleft><SPAN><FONT face=3DArial color=3D#0000ff =
size=3D2>&nbsp; =0A=
  octet two;</FONT></SPAN></DIV>=0A=
  <DIV dir=3Dltr align=3Dleft><SPAN><FONT face=3DArial color=3D#0000ff =
size=3D2>&nbsp; =0A=
  long three;</FONT></SPAN></DIV>=0A=
  <DIV dir=3Dltr align=3Dleft><SPAN><FONT face=3DArial color=3D#0000ff =0A=
  size=3D2>};</FONT></SPAN></DIV>=0A=
  <DIV dir=3Dltr align=3Dleft><SPAN><FONT face=3DArial color=3D#0000ff =0A=
  size=3D2></FONT></SPAN>&nbsp;</DIV>=0A=
  <DIV dir=3Dltr align=3Dleft><SPAN><FONT face=3DArial color=3D#0000ff =
size=3D2>there will =0A=
  indeed be 4 total bytes used for the octet, since the type that =0A=
  follows</FONT></SPAN></DIV>=0A=
  <DIV dir=3Dltr align=3Dleft><SPAN><FONT face=3DArial color=3D#0000ff =
size=3D2>it must be =0A=
  aligned to a 4-byte boundary, and we know that the octet =0A=
  marshaling</FONT></SPAN></DIV>=0A=
  <DIV dir=3Dltr align=3Dleft><SPAN><FONT face=3DArial color=3D#0000ff =
size=3D2>started on =0A=
  a 4-byte boundary because of the previous member. However this =0A=
  is</FONT></SPAN></DIV>=0A=
  <DIV dir=3Dltr align=3Dleft><SPAN><FONT face=3DArial color=3D#0000ff =
size=3D2>not always =0A=
  the case. For example,</FONT></SPAN></DIV>=0A=
  <DIV dir=3Dltr align=3Dleft><SPAN><FONT face=3DArial color=3D#0000ff =0A=
  size=3D2></FONT></SPAN>&nbsp;</DIV>=0A=
  <DIV dir=3Dltr align=3Dleft><SPAN><FONT face=3DArial color=3D#0000ff =
size=3D2>struct =0A=
  bar</FONT></SPAN></DIV>=0A=
  <DIV dir=3Dltr align=3Dleft><SPAN><FONT face=3DArial color=3D#0000ff =0A=
  size=3D2>{</FONT></SPAN></DIV>=0A=
  <DIV dir=3Dltr align=3Dleft><SPAN><FONT face=3DArial color=3D#0000ff =
size=3D2>&nbsp; =0A=
  long one;</FONT></SPAN></DIV>=0A=
  <DIV dir=3Dltr align=3Dleft><SPAN><FONT face=3DArial color=3D#0000ff =
size=3D2>&nbsp; =0A=
  octet two;</FONT></SPAN></DIV>=0A=
  <DIV dir=3Dltr align=3Dleft><SPAN><FONT face=3DArial color=3D#0000ff =
size=3D2>&nbsp; =0A=
  octet three;</FONT></SPAN></DIV>=0A=
  <DIV dir=3Dltr align=3Dleft><SPAN><FONT face=3DArial color=3D#0000ff =0A=
  size=3D2>&nbsp;&nbsp;octet four;</FONT></SPAN></DIV>=0A=
  <DIV dir=3Dltr align=3Dleft><SPAN><FONT face=3DArial color=3D#0000ff =
size=3D2>&nbsp; =0A=
  octet five;</FONT></SPAN></DIV>=0A=
  <DIV dir=3Dltr align=3Dleft><SPAN><FONT face=3DArial color=3D#0000ff =
size=3D2>&nbsp; =0A=
  long six;</FONT></SPAN></DIV>=0A=
  <DIV dir=3Dltr align=3Dleft><SPAN><FONT face=3DArial color=3D#0000ff =0A=
  size=3D2>};</FONT></SPAN></DIV>=0A=
  <DIV dir=3Dltr align=3Dleft><SPAN><FONT face=3DArial color=3D#0000ff =0A=
  size=3D2></FONT></SPAN>&nbsp;</DIV>=0A=
  <DIV dir=3Dltr align=3Dleft><SPAN><FONT face=3DArial color=3D#0000ff =
size=3D2>will use =0A=
  just 1 byte for each octet, since by the time we get to 'six', we =0A=
  are</FONT></SPAN></DIV>=0A=
  <DIV dir=3Dltr align=3Dleft><SPAN><FONT face=3DArial color=3D#0000ff =
size=3D2>already =0A=
  aligned to a 4-byte boundary, so no additional padding is =0A=
  necessary.</FONT></SPAN></DIV>=0A=
  <DIV dir=3Dltr align=3Dleft><SPAN><FONT face=3DArial color=3D#0000ff =0A=
  size=3D2></FONT></SPAN>&nbsp;</DIV>=0A=
  <DIV dir=3Dltr align=3Dleft><SPAN><FONT face=3DArial color=3D#0000ff =0A=
  size=3D2>Jeff</FONT></SPAN></DIV><BR>=0A=
  <BLOCKQUOTE dir=3Dltr =0A=
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: =
rgb(0,0,255) 2px solid; MARGIN-RIGHT: 0px">=0A=
    <DIV lang=3Den-us dir=3Dltr align=3Dleft>=0A=
    <HR>=0A=
    <FONT face=3DTahoma size=3D2><B>From:</B> <A =0A=
    href=3D"mailto:owner-tao-users@cse.wustl.edu" =0A=
    target=3D_blank>owner-tao-users@cse.wustl.edu</A> [mailto:<A =0A=
    href=3D"mailto:owner-tao-users@cse.wustl.edu" =0A=
    target=3D_blank>owner-tao-users@cse.wustl.edu</A>] <B>On Behalf Of =
</B>Johnny =0A=
    Willemsen<BR><B>Sent:</B> Wednesday, December 28, 2005 1:08 =
PM<BR><B>To:</B> =0A=
    Krishna, Arvind; Kobi Cohen-Arazi; <A =
href=3D"mailto:tao-users@cs.wustl.edu" =0A=
    target=3D_blank>tao-users@cs.wustl.edu</A><BR><B>Subject:</B> RE: =
[ace-users] =0A=
    RE: [tao-users] Octet Marshaling/Demarshaling =
issues<BR></FONT><BR></DIV>=0A=
    <DIV></DIV>=0A=
    <P><FONT size=3D2>Hi,</FONT> </P>=0A=
    <DIV><SPAN class=3De id=3Dq_108741a0f1fcd6cd_1>=0A=
    <P><FONT size=3D2>If you marshal a corba sequence of octet then =
instead of the =0A=
    normal &lt;&lt; and</FONT> <BR><FONT size=3D2>&gt;&gt; for each =
element the =0A=
    methods write_octet_array and read_octet_array on</FONT> <BR><FONT =0A=
    size=3D2>the stream are used, in fact, all corba sequences of basic =
types to =0A=
    use</FONT> <BR><FONT size=3D2>array methods on the cdr stream. If =
you handle =0A=
    your own cdr streaming you</FONT> <BR><FONT size=3D2>can of course =
use these =0A=
    methods also.</FONT> </P>=0A=
    <P><FONT size=3D2>Regards,</FONT> </P>=0A=
    <P><FONT size=3D2>Johnny Willemsen</FONT> <BR><FONT size=3D2>Remedy =
IT</FONT> =0A=
    <BR><FONT size=3D2>Postbus 101</FONT> <BR><FONT size=3D2>2650 =
AC&nbsp; Berkel en =0A=
    Rodenrijs</FONT> <BR><FONT size=3D2>The Netherlands</FONT> <BR><FONT =
size=3D2><A =0A=
    href=3D"http://www.theaceorb.nl" =
target=3D_blank>www.theaceorb.nl</A> / <A =0A=
    href=3D"http://www.remedy.nl" =
target=3D_blank>www.remedy.nl</A>&nbsp; =0A=
</FONT></P>=0A=
    <P><FONT size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt; =0A=
    From: <A href=3D"mailto:owner-ace-users@cse.wustl.edu" =0A=
    target=3D_blank>owner-ace-users@cse.wustl.edu</A> </FONT><BR><FONT =
size=3D2>&gt; =0A=
    [<A href=3D"mailto:owner-ace-users@cse.wustl.edu" target=3D_blank> =0A=
    mailto:owner-ace-users@cse.wustl.edu</A>] On Behalf Of Krishna, =0A=
    Arvind</FONT> <BR><FONT size=3D2>&gt; Sent: woensdag 28 december =
2005 =0A=
    19:55</FONT> <BR><FONT size=3D2>&gt; To: Kobi Cohen-Arazi; <A =0A=
    href=3D"mailto:ace-users@cs.wustl.edu" =0A=
    target=3D_blank>ace-users@cs.wustl.edu</A>; <A =0A=
    href=3D"mailto:tao-users@cs.wustl.edu" =0A=
    target=3D_blank>tao-users@cs.wustl.edu</A></FONT> <BR><FONT =
size=3D2>&gt; =0A=
    Subject: [ace-users] RE: [tao-users] Octet </FONT><BR><FONT =
size=3D2>&gt; =0A=
    Marshaling/Demarshaling issues</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT =0A=
    size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Hi Kobi,</FONT> =
<BR><FONT =0A=
    size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; &gt;It takes 4 bytes to =
marshal a =0A=
    single Octet. However, when </FONT><BR><FONT size=3D2>&gt; =
marshaling =0A=
    an</FONT> <BR><FONT size=3D2>&gt; array of Octet, it takes a single =
byte for =0A=
    &gt;every element in </FONT><BR><FONT size=3D2>&gt; the =
array.</FONT> =0A=
    <BR><FONT size=3D2>&gt; It seems that Octet is an exception =
comparing the rest =0A=
    of </FONT><BR><FONT size=3D2>&gt; primitive data</FONT> <BR><FONT =
size=3D2>&gt; =0A=
    types. What is &gt;the motivation for that? Is it dictated by an =0A=
    </FONT><BR><FONT size=3D2>&gt; OMG spec? </FONT><BR><FONT =
size=3D2>&gt; =0A=
    </FONT><BR><FONT size=3D2>&gt; I think you might be seeing a type =
promotion =0A=
    from octet to </FONT><BR><FONT size=3D2>&gt; long. I just</FONT> =
<BR><FONT =0A=
    size=3D2>&gt; checked and ACE_CDR provides a read_octet and =
write_octet =0A=
    methods for</FONT> <BR><FONT size=3D2>&gt; reading/writing octets. =
However, if =0A=
    you use the insertion/extraction</FONT> <BR><FONT size=3D2>&gt; =
operator then =0A=
    octet will be type promoted as ACE_CDR does not provide</FONT> =
<BR><FONT =0A=
    size=3D2>&gt; the appropriate &lt;&lt; and &gt;&gt; methods. Is this =
what you =0A=
    are seeing?</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt; =0A=
    HTH,</FONT> <BR><FONT size=3D2>&gt; Arvind</FONT> <BR><FONT =
size=3D2>&gt; =0A=
    =
</FONT></P></SPAN></DIV></BLOCKQUOTE></BLOCKQUOTE></DIV><BR></DIV></BODY>=
</HTML>=0A=

------_=_NextPart_001_01C60C79.FEB6F9E4--

0
Bica
12/29/2005 3:19:09 PM
Reply:

Similar Artilces:

Re: [ace-users] RE: [tao-users] Octet Marshaling/Demarshaling issues
Hi Arvind, >> I think you might be seeing a type promotion from octet to long. I >> just checked and ACE_CDR provides a read_octet and write_octet >> methods for reading/writing octets. Right, but Kobi's point (which I believe is correct) is that an octet is *encoded* into 4 bytes. The original motivation for this was to maximize performance on RISC machines, where the alignment was traditionally 32 bit boundaries. Take care, Doug -- Dr. Douglas C. Schmidt Professor and Associate Chair Electrical Engineering and Computer Science TEL: (615) 343-8197 Institute for Software Integrated Systems WEB: www.dre.vanderbilt.edu/~schmidt Vanderbilt University, Nashville TN, 37203 NET: d.schmidt@vanderbilt.edu ...

[ace-users] RE: [tao-users] Octet Marshaling/Demarshaling issues
Hi Kobi, >It takes 4 bytes to marshal a single Octet. However, when marshaling an array of Octet, it takes a single byte for >every element in the array. It seems that Octet is an exception comparing the rest of primitive data types. What is >the motivation for that? Is it dictated by an OMG spec? I think you might be seeing a type promotion from octet to long. I just checked and ACE_CDR provides a read_octet and write_octet methods for reading/writing octets. However, if you use the insertion/extraction operator then octet will be type promoted as ACE_CDR does not provide the appropriate << and >> methods. Is this what you are seeing? HTH, Arvind ...

Re: [ace-users] Re: [tao-users] Re: difficulties compling TAO with mingw and msys #2
Hi, > > Great, when we get time we will try to upgrade to a newer version of MinGW, > > but it is still a candidate. Just keep an eye on the scoreboard, when we > > upgrade you will see it there. As you can see on the scoreboard, there are > > no issues with the 3.2.3 version > > I have run all but a few of the provided tests, and all looks well. We run all ACE tests, no issues there, we are working on the TAO tests, some of the tests are able to freeze our build system > Out of curiosity, what is required for eliminating the > inline/dlli...

RE: [tao-users] Re: [ace-users] Re: Announcing the release of the new beta (ACE-5.4.10, TAO-1.4.10 and CIAO-0.4.10)
Hi, > > >> We encourage you to download the new beta, use it with your > > >> applications, and let us know soon if you encounter any problems > > >> since we plan to cut the x.5 release by February 28th. > > > > As per Wallace's comments, we have an aggressive schedule > for the x.5 > > release to meet the needs of some major sponsors. If > people can give > > x.4.10 a "test drive" in the next couple of days and report problems > > they encounter we'll try to ensure that we fix any > showstoppers before > > According to bugzilla bug 2323 is not fixed yet. > > http://deuce.doc.wustl.edu/bugzilla/show_bug.cgi?id=2323 > > For us it is a show stopper. We use the OCI version which does not > have problems related to this bug but it would be nice to be able to > use the latest version with more fixes. FYI, the reason that this test now fails is because Ossama added several new test cases which wheren't in the test in the past, this uncovered some bugs which according to our information where already there a long time. Johnny "Johnny Willemsen" <jwillemsen@remedy.nl> writes: > > > >> We encourage you to download the new beta, use it with your > > > >> applications, and let us know soon if you encounter any problems > > > >> sinc...

[ace-users] RE: [tao-users] Borland Developer Studio 2006 with ACE/TAO #2
Hi, See http://www.remedy.nl/en/borland.html for an overview of the supported Borland products with TAO. Regards, Johnny Willemsen Remedy IT Postbus 101 2650 AC Berkel en Rodenrijs The Netherlands www.theaceorb.nl / www.remedy.nl > -----Original Message----- > From: Espen Harlinn [mailto:espen@harlinn.no] > Sent: donderdag 2 februari 2006 18:06 > To: jwillemsen@remedy.nl > Cc: ace-users@cs.wustl.edu > Subject: RE: [tao-users] Borland Developer Studio 2006 with ACE/TAO > > Hi, > > I'm curious about the current status of ACE/TAO and C++ Builder 2006. > Borland shipped the promised fix/update some time ago, but I > couldn't find > anything about how it works with ACE/TAO. > > Regards > Espen Harlinn > > ...

[ace-users] RE: [tao-users] Borland Developer Studio 2006 with ACE/TAO #2
Hi, The x.4.8 version of ACE/TAO is supported with BCB2006, we have some linker warnings/errors in some configurations, Borland is working on these for Update2, but these are not causing a problem. See ACE_wrappers/ACE-INSTALL.html for info about how to use it. We deliver also commercial support for using BCB2006 with ACE/TAO. See www.theaceorb.nl for our services. Regards, Johnny Willemsen Remedy IT Postbus 101 2650 AC Berkel en Rodenrijs The Netherlands www.theaceorb.nl / www.remedy.nl > -----Original Message----- > From: Espen Harlinn [mailto:espen@harlinn.no] > Sent: donderdag 2 februari 2006 18:06 > To: jwillemsen@remedy.nl > Cc: ace-users@cs.wustl.edu > Subject: RE: [tao-users] Borland Developer Studio 2006 with ACE/TAO > > Hi, > > I'm curious about the current status of ACE/TAO and C++ Builder 2006. > Borland shipped the promised fix/update some time ago, but I > couldn't find > anything about how it works with ACE/TAO. > > Regards > Espen Harlinn > > ...

Re: [ace-users] Re: [tao-users] Re: difficulties compling TAO with mingw and msys
Hi, Great, when we get time we will try to upgrade to a newer version of MinGW, but it is still a candidate. Just keep an eye on the scoreboard, when we upgrade you will see it there. As you can see on the scoreboard, there are no issues with the 3.2.3 version Regards, Johnny Willemsen Remedy IT Leeghwaterstraat 25 2811 DT Reeuwijk The Netherlands www.theaceorb.nl / www.remedy.nl "William Lederer" <wgl@localhost.localdomain> wrote in message news:<m3pt4yrtfx.fsf@localhost.localdomain>... > Thanks! > > I followed your advice in your earli...

[tao-users] RE: [ace-users] Re: How to use Any>>=OctetSeq in TAO 1.3.6? #2
Hi, > > Heiko, could you try to add TAO_Export to front of the operators in > > OctetSeqA.h and then rebuild TAO and you app. I think the linker > > errors should be gone. > > this is the solution! Thank you :-) Thanks for the feedback. I have just committed the fix into the repo and this will be in the 1.4 release. Regards, Johnny Willemsen Remedy IT Leeghwaterstraat 25 2811 DT Reeuwijk The Netherlands www.theaceorb.nl / www.remedy.nl ...

RE: [tao-users] RE: [ace-users] XML service configuration no longer works with ACE/TAO 5.4.5/1.4.5
Hi, > > Hi Lothar > > > > > � � ACE VERSION: 5.4.5 > > > > Thanks for using the PRF form. Could you try to find the > problem and send > > us patches to fix this? > > > > Regards, > > > > Johnny Willemsen > > I have no problem committing some time to the problem. I do > however know as > much as nothing about the ACE XML parser and it's recent > changes. It seems to > me that (some) of the recent changes might have caused the > test failures. So > if someone working actively on ACEXML gives me directions I > am willing to > spend my time investigating the problem. I can't remember that work has been done the last months so I am also amazed things broke. Nobody is actively working on it, so I think there are not much directions at this moment. Regards, Johnny Willemsen Remedy IT Postbus 101 2650 AC Berkel en Rodenrijs The Netherlands www.theaceorb.nl / www.remedy.nl On Wednesday 18 May 2005 11:01, Johnny Willemsen wrote: > Hi, > I can't remember that work has been done the last months so I am also > amazed things broke. Nobody is actively working on it, so I think there are > not much directions at this moment. Well, it did definiteley work with 5.4.4. So any changes that broke it must have been made between 5.4.4 and 5.4.5. I also read in the release email of 5.4.5 in the CIAO...

Re: Re: [ace-users] Design issue about GUI client with ACE. #2
Hi, >> Thanks very much. But I cannot understand how to combine the active >> object with Reactor pattern. The subclass::handle_input () receive >> messages from server, Right. >> and the subclass::handle_output () should dequeue method from >> ACE_Activation_Queue. From ACE tutorial, this action (dequeue) will >> be blocked if the queue is empty. And Reactor pattern warning me >> that every method cannot be blocked when handle I/O request. Right, don't use subclass:handle_output(). Instead, use the Half-Sync/Half-Asynch pattern (which combines Reactor and Active Object) and perform output in a separate thread - inside the active object. There are examples of how to use this pattern in C++NPv2 <www.cs.wustl.edu/~schmidt/ACE/book2> and POSA2 <www.cs.wustl.edu/~schmidt/POSA/>. Take care, Doug -- Dr. Douglas C. Schmidt Professor and Associate Chair Electrical Engineering and Computer Science TEL: (615) 343-8197 Institute for Software Integrated Systems WEB: www.dre.vanderbilt.edu/~schmidt Vanderbilt University, Nashville TN, 37203 NET: d.schmidt@vanderbilt.edu ...

RE: [ace-users] Re: ACE #2
This is a multi-part message in MIME format. ------_=_NextPart_001_01C6413F.CD2A80C8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Logging_Strategy problems were fixed in 5.4.7. You should definitely upgrade. =20 Howard =20 _____ =20 From: owner-ace-users@cse.wustl.edu [mailto:owner-ace-users@cse.wustl.edu] On Behalf Of Kobi Cohen-Arazi Sent: Thursday, March 02, 2006 12:44 AM To: hileon@gmail.com Cc: ace-users@cs.wustl.edu Subject: Re: [ace-users] Re: ACE =20 Hi, We had bugs in that specific area (Limit the size using Logging_Strategy) in x.4.0. You probably seeing that same bug ... It was fixed year ago. Upgrading may help.=20 Thanks, Kobi. On 3/1/06, Douglas C. Schmidt <schmidt@cse.wustl.edu> wrote: Hi, >> I use ACE 5.4+TAO 1.4. To ensure that we have proper version/platform/compiler information, please make sure you fill out the appropriate problem report form (PRF), which is in $ACE_ROOT/PROBLEM-REPORT-FORM=20 $TAO_ROOT/PROBLEM-REPORT-FORM or in $ACE_ROOT/BUG-REPORT-FORM $TAO_ROOT/BUG-REPORT-FORM in older versions of ACE+TAO. Make sure to include this information when asking any questions about ACE+TAO since otherwise we have to=20 "guess" what version/platform/compiler/options you've using, which is error-prone and slows down our responsiveness. Moreover, please upgrade to ACE+TAO x.4.10, which you can download...

RE: [ace-users] Re: ACE #2
Hi Folks, > Sorry about the wrong message. It does work, I did not wait enough > To roll it over. Ok, great - I'm glad to hear that it works! Thanks, Doug ...

RE: [ace-users] Re: ACE #2
Hi, Somewhere in your app you should run the reactor loop Regards, Johnny Willemsen Remedy IT Postbus 101 2650 AC Berkel en Rodenrijs The Netherlands www.theaceorb.nl / www.remedy.nl > >> I update the ACE version to 5.4.10, but it seems have no help. > >> > >> ACE_Logging_Strategy : the -m option does not work. > >> > >> ACE VERSION: 5.4.10 > >> > >> HOST MACHINE and OPERATING SYSTEM: > >> Windows XP SP2 > >> > >> TARGET MACHINE and OPERATING SYSTEM, if different from HOST: > >> Windows XP SP2 > >> > >> THE $ACE_ROOT/ace/config.h FILE : > >> #include "ace/config-win32.h" > >> > >> THE $ACE_ROOT/include/makeinclude/platform_macros.GNU > FILE [if you > >> use a link to a platform-specific file, simply state which one > >> (unless this isn't used in this case, e.g., with > Microsoft Visual > >> C++)]: > >> Microsoft Visual C++ 6.0 sp6 > >> > >> CONTENTS OF > >> $ACE_ROOT/bin/MakeProjectCreator/config/default.features > >> (used by MPC when you generate your own makefiles): > >> There is no this file. > >> > >> AREA/CLASS/EXAMPLE AFFECTED: > >> APG\Logging\Use_Logging_Strategy.d...

Re: [ace-users] Octet Marshaling/Demarshaling issues
Hi Kobi, Thanks for using the PRF. >> PRF: >> TAO VERSION: 1.4.6 >> ACE VERSION: 5.4.6 >> >> HOST MACHINE and OPERATING SYSTEM: >> Linux, FC3, 2.6.10 >> >> DOES THE PROBLEM AFFECT: >> EXECUTION? YES >> >> Summary: >> It takes 4 bytes to marshal a single Octet. Right. >> However, when marshaling an array of Octet, it takes a single byte >> for every element in the array. It seems that Octet is an exception >> comparing the rest of primitive data types. Yes, that's correct. >> What is the motivation for that? To avoid wasting any more space than necessary when dealing with sequences/arrays. >> Is it dictated by an OMG spec? Yes, definitely. This type of "optimization" is common. Take care, Doug -- Dr. Douglas C. Schmidt Professor and Associate Chair Electrical Engineering and Computer Science TEL: (615) 343-8197 Institute for Software Integrated Systems WEB: www.dre.vanderbilt.edu/~schmidt Vanderbilt University, Nashville TN, 37203 NET: d.schmidt@vanderbilt.edu ...

[tao-users] RE: [ace-users] ACE/TAO on Solaris 10
Hi, There have been some replies. People do have things working on Solaris and there have been made fixes in ACE/TAO. Could you wait another week or so and try the x.4.8 or try cvs, see http://cvs.doc.wustl.edu Regards, Johnny Willemsen Remedy IT Postbus 101 2650 AC Berkel en Rodenrijs The Netherlands www.theaceorb.nl / www.remedy.nl > Dear list members, > > (I sent this message couple of days ago and am unsure if it > was distributed, > thus re-sending it again. I apologize if you received it more > than once) > > I would like to give feedback regarding availability of > ACE/TAO (versions > 5.4.7 and 1.4.7 respectively) on OpenSolaris (Solaris 10) > Intel platform. > > Sun is selectively releasing source code of the Solaris 10 under an > open-source license. Details of this project and installable Solaris > binaries can be found on here: > http://www.opensolaris.org > > Sun has also released Forte compiler set in binary form to > the OpenSolaris > community. A Quote from their website: "Sun Studio 10 > software is freely > available to participants in the OpenSolaris community for > development on > both OpenSolaris and Solaris[tm] Operating Systems on > SPARC-based systems > and x86-based systems, as well as on Linux." You can get > access to Forte > compilers from the OpenSolaris website as well but you should register...

RE: [ace-users] Re: what version tao/ace for AIX 5.2 posix aio
Hi Duane, I can't speak for TAO's use of AIO, but ACE 5.4 does support AIO on AIX 5.2. -Steve -- Steve Huston, Riverace Corporation Co-author of "C++ Network Programming" and "The ACE Programmer's Guide" Books, ACE kit and support info at http://www.riverace.com/ > -----Original Message----- > From: owner-ace-users@cse.wustl.edu > [mailto:owner-ace-users@cse.wustl.edu] On Behalf Of Douglas C. Schmidt > Sent: Sunday, July 04, 2004 2:49 PM > To: shuston@riverace.com; ace-users@cs.wustl.edu > Subject: [ace-user...

Re: [ace-bugs] Re: [ace-users] RE: Module->open() #2
Hi, >> I guess I'm just pushing the limits a bit and trying to avoid >> writing a whole bunch of new code. This is a time-honored way in which ACE evolves. >> I view ACE_Stream/Module/Task as a good vehicle for a >> component-based design of network protocol processing that includes >> complex/stateful behaviors. Right, I agree. >> The Streams framework has components and behaviors relevant to >> dynamically configuring services which consist of a set of >> cooperating sub-objects. I understand that the assumption in ...

[tao-users] Re: [ace-users] How to use c++ native exception handling instead of ACE's while building ACE+TAO
Hi, >> My only guess is that all of the libs you are linking in your >> builds were not compiled with a consistent set of options. Right, my recommendation would be to completely blow away your existing ACE+TAO x.5 directory, download a fresh version, and start from a clean slate. It sounds like you may have things lying around from previous build attempts. Thanks, Doug -- Dr. Douglas C. Schmidt Professor and Associate Chair Electrical Engineering and Computer Science TEL: (615) 343-8197 Institute for Software Integrated Systems WEB: www.dre.vanderbilt.edu/~schmidt Vanderbilt University, Nashville TN, 37203 NET: d.schmidt@vanderbilt.edu ...

[tao-users] Re: [ace-users] Re: Query
Hi Bill, Thanks very much for your email. Please make sure to send all questions related to TAO or ACE to the ACE mailing list or ACE+TAO newsgroup, rather than to me directly. > Actually this email is very appropriate. We at The Weather Channel > are attempting to build ACE+TAO version 5.4 on an AMD opteron using > g++ 3.3.3. > > The only errors we have seen thus far and in a component that we don't really > intend on using is: This problem was fixed before the x.4.1 release, so if you download it from http://deuce.doc.wustl.edu/Download.html you'll get a wo...

Web resources about - RE: [ace-users] RE: [tao-users] Octet Marshaling/Demarshaling issues #2 - comp.soft-sys.ace

Resources last updated: 3/5/2016 10:55:18 AM