f



Re: [tao-users] Reactive/Concurrency: Difference between different ORBReactorType #2

Hi Abhi,

> Does this mean, that select_st should only be used with (ORBConcurrency) 
> reactive, and never with thread-per-connection. 

No, it just means that you need to be REALLY careful when you use
select_st with anything other than reactive ORB concurrency...

> If this is true, then the svc.conf file does not make sense under
> $TAO_ROOT/performance-tests/Cubit/TAO/IDL_Cubit

This test is trying to see how fast TAO will run when most of the
"safety" options are turned off.  It therefore does a number of things
that are probably not a good idea unless you know a lot about how your
server application behaves wrt concurrency.  In particular, the
IDL_Cubit operation is completely stateless and idempotent, which is
not necessarily representative of a "normal" server.

Take care,

        Doug
0
schmidt7304 (285)
12/5/2003 12:38:25 AM
comp.soft-sys.ace 20326 articles. 1 followers. marlow.andrew (167) is leader. Post Follow

0 Replies
421 Views

Similar Articles

[PageSpeed] 22

Reply:

Similar Artilces:

Re: [tao-users] Reactive/Concurrency: Difference between different ORBReactorType
Hi Abhi, > DESCRIPTION: > What is the difference between the following ReactorTypes: > > - select_st (Guess it is a select based reactor in a single thread) Right - you generally don't want to use this unless you know you'll only ever have a single thread. > - select_mt (Is it a Worker thread pool architecture, where a I/O > thread selects on the ORB endpoints (& also the connection endpoints), > reads new client requests, and queues them into the tail of a > request queue. A worker thread in the pool then dequeues the next > request from the head of the queue. How many threads are > configured in the worker threadpool. Is this done by a config > value or in application code? ) "No" to all of the above. The select_mt is simply a reactor that can be used safely in a multi-threaded configuration, e.g., thread-per-connection. > - tp (Is it a leader_follower thread pool architecture? Actually, it just selects the ACE_TP_Reactor, which can be used to implement a Leader/Followers thread pool architecture. > How is the number of threads configured? ) You spawn the threads, so you control them. Please see the discussions in $TAO_ROOT/docs/configurations.html for more info on this. > I guess these values are used by both the client & the server? Sure, but they are mostly useful for applications that play the role of a server. > Basically how ...

[tao-users] Reactive/Concurrency: Difference between different ORBReactorType
To: tao-users@cs.wustl.edu Subject: Reactive/Concurrency: Difference between different ORBReactorType TAO VERSION: 1.3.5 ACE VERSION: 5.3.5 HOST MACHINE and OPERATING SYSTEM: Linux Redhat 9 kernel 2.4.20-19.9 SYNOPSIS: Question about the difference between various ORBConcurrency & ReactorType DESCRIPTION: What is the difference between the following ReactorTypes: - select_st (Guess it is a select based reactor in a single thread) - select_mt (Is it a Worker thread pool architecture, where a I/O thread selects on the ORB endpoints (& also the connection endpoints), reads new client requests, and queues them into the tail of a request queue. A worker thread in the pool then dequeues the next request from the head of the queue. How many threads are configured in the worker threadpool. Is this done by a config value or in application code? ) - tp (Is it a leader_follower thread pool architecture? How is the number of threads configured? ) I guess these values are used by both the client & the server? Basically how do these types map to the Architectures shown in "Evaluating Architectures for Multi-threaded CORBA Object Request Brokers" by Douglas Schmidt. Also there are 2 ORBConcurrency strategies: - thread-per-connection: Does this work with any of the 3 ReactorTypes above. Is it at all worthwhile to use this with tp ReactorType? ...

Re: [tao-users] Communication between different TAO versions #2
Hi Kerry, Thanks for using the PRF. >> TAO VERSION: 1.4.4 and 1.4 >> ACE VERSION: 5.4.4 and 5.4 >> >> HOST MACHINE and OPERATING SYSTEM: >> Pentium 4, Windows XP Pro SP1 >> >> TARGET MACHINE and OPERATING SYSTEM, if different from HOST: >> dito >> >> COMPILER NAME AND VERSION (AND PATCHLEVEL): >> MSVC++ 7.1 >> >> CONTENTS OF $ACE_ROOT/ace/config.h [if you use a link to a platform- >> specific file, simply state which one]: >> #define ACE_HAS_STANDARD_CPP_LIBRARY 1 >> #include "ace/config-win32.h" >> >> CONTENTS OF $ACE_ROOT/include/makeinclude/platform_macros.GNU (unless >> this isn't used in this case, e.g., with Microsoft Visual C++): >> >> CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features >> (used by MPC when you generate your own makefiles): >> >> AREA/CLASS/EXAMPLE AFFECTED: >> CORBA calls between hosts using different versions of TAO >> >> DOES THE PROBLEM AFFECT: >> COMPILATION? >> no >> LINKING? >> no >> EXECUTION? >> yes >> OTHER (please specify)? >> no >> >> SYNOPSIS: >&g...

[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] ACE_Process_Mutex on Win XP and Different Users #2
Hi Paul, >> There is precedent for passing an LPSECURITY_ATTRIBUTES in ACE (e.g. >> ACE_Mem_Map, ACE_MMAP_Memory_Pool_Options, ACE_FIFO, >> ACE_Filecache_Object). Ok, fair enough. >> One work around I listed in the PRF is to define >> ACE_DEFINES_DEFAULT_WIN32_SECURITY_ATTRIBUTES in the config.h when >> compiling ACE. The lower level calls (e.g. ACE_OS::mutex_init, etc) >> could be used instead of ACE_Process_Mutex or ACE_Mutext. If >> LPSECURITY_ATTRIBUTES, is NULL always pass a default >> LPSECURITY_ATTRIBUTES to CreateMutexA or CreateMutexW. >> >> So if an additional parameter (LPSECURITY_ATTRIBUTES sa = 0) is not >> wanted in the Mutex contstructors, then it seems the best >> workaround is to pass a default LPSECURITY_ATTRIBUTES if the input >> one is NULL. As long as there is precedent for putting LPSECURITY_ATTRIBUTES sa = 0 at the end of some ACE constructors then this seems like a reasonable thing to do for the ACE_Process_Mutex stuff. Could you please send us the patches for this relative to ACE 5.5? We won't be able to add it to ACE until after the x.5.1 beta goes out. 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, Na...

RE: [ace-users] ACE_Process_Mutex on Win XP and Different Users #2
Doug, There is precedent for passing an LPSECURITY_ATTRIBUTES in ACE (e.g. ACE_Mem_Map, ACE_MMAP_Memory_Pool_Options, ACE_FIFO, ACE_Filecache_Object). One work around I listed in the PRF is to define ACE_DEFINES_DEFAULT_WIN32_SECURITY_ATTRIBUTES in the config.h when compiling ACE. The lower level calls (e.g. ACE_OS::mutex_init, etc) could be used instead of ACE_Process_Mutex or ACE_Mutext. If LPSECURITY_ATTRIBUTES, is NULL always pass a default LPSECURITY_ATTRIBUTES to CreateMutexA or CreateMutexW. So if an additional parameter (LPSECURITY_ATTRIBUTES sa = 0) is not wanted in the Mutex contstructors, then it seems the best workaround is to pass a default LPSECURITY_ATTRIBUTES if the input one is NULL. Paul -----Original Message----- From: Douglas C. Schmidt [mailto:schmidt@cse.wustl.edu] Sent: Thursday, March 09, 2006 2:33 PM To: ace-users@cs.wustl.edu; Eccles, Paul Subject: Re: [ace-users] ACE_Process_Mutex on Win XP and Different Users Hi Paul, Thanks for using the PRF. >> ACE VERSION: 5.3 (and 5.5? >> >> HOST MACHINE and OPERATING SYSTEM: Windows XP and winsock 2.0 >> >> TARGET MACHINE and OPERATING SYSTEM, if different from HOST: >> COMPILER NAME AND VERSION (AND PATCHLEVEL): >> >> THE $ACE_ROOT/ace/config.h FILE [if you use a link to a platform- >> specific file, simply state which one]: config-win32.h >> >> THE $A...

RE: [ace-users] ACE_Process_Mutex on Win XP and Different Users #2
Doug, I will but it won't be until after 31 March. Paul -----Original Message----- From: Douglas C. Schmidt [mailto:schmidt@cse.wustl.edu] Sent: Friday, March 10, 2006 9:48 AM To: ace-users@cs.wustl.edu; Eccles, Paul Subject: Re: [ace-users] ACE_Process_Mutex on Win XP and Different Users Hi Paul, >> There is precedent for passing an LPSECURITY_ATTRIBUTES in ACE (e.g. >> ACE_Mem_Map, ACE_MMAP_Memory_Pool_Options, ACE_FIFO, >> ACE_Filecache_Object). Ok, fair enough. >> One work around I listed in the PRF is to define >> ACE_DEFINES_DEFAULT_WIN32_SECURITY_ATTRIBUTES in the config.h when >> compiling ACE. The lower level calls (e.g. ACE_OS::mutex_init, etc) >> could be used instead of ACE_Process_Mutex or ACE_Mutext. If >> LPSECURITY_ATTRIBUTES, is NULL always pass a default >> LPSECURITY_ATTRIBUTES to CreateMutexA or CreateMutexW. >> >> So if an additional parameter (LPSECURITY_ATTRIBUTES sa = 0) is not >> wanted in the Mutex contstructors, then it seems the best workaround >> is to pass a default LPSECURITY_ATTRIBUTES if the input one is NULL. As long as there is precedent for putting LPSECURITY_ATTRIBUTES sa = 0 at the end of some ACE constructors then this seems like a reasonable thing to do for the ACE_Process_Mutex stuff. Could you please send us the patches for this relative to ACE 5.5? We won't be able to add it to ACE until afte...

[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] Is it possible to use two different versions of the ACE/TAO in the same application?
Hi, >> I'm developing an application (Intel Pentium 4 - Linux Red Hat 2.4.21-4.EL - >> g++ 3.2.3) that uses two different "third party" libraries. >> The first one was compiled and linked with ACE-TAO 5.4/1.4. The second one with >> ACE-TAO 5.4.8/1.4.8. The second library was compiled enabling >> ACE_HAS_VERSIONED_NAMESPACE and TAO_HAS_VERSIONED_NAMESPACE to avoid >> symbolic ambiguity. >> >> The following ld warnings appear when I compile my application: >> >> "/usr/bin/ld: warning: libTAO_IORTable.so.1.4.8, needed by ... may conflict >> with libTAO_IORTable.so.1.4.0 >> /usr/bin/ld: warning: libTAO_CosNaming.so.1.4.8, needed by ... may conflict >> with libTAO_CosNaming.so.1.4.0 >> /usr/bin/ld: warning: libTAO_Messaging.so.1.4.8, needed by ... may conflict >> with libTAO_Messaging.so.1.4.0 >> /usr/bin/ld: warning: libTAO_Valuetype.so.1.4.8, needed by ... may conflict >> with libTAO_Valuetype.so.1.4.0 >> /usr/bin/ld: warning: libTAO_CosNotification.so.1.4.8, needed by ... may >> conflict with libTAO_CosNotification.so.1.4.0 >> /usr/bin/ld: warning: libTAO_PortableServer.so.1.4.8, needed by ... may >> conflict with libTAO_PortableServer.so.1.4.0 >> /usr/bin/ld: warning: libTAO.so.1.4.8, needed by ... may conflict with >> libTAO.so.1.4.0 >> /usr/bin/ld: warning: libACE.so.5.4.8, needed by .....

[tao-users] RE: [ace-users] Linking Errors. #2 #2
Hi, Remove the following line from your makefile: $OPTIONS = -DACE_BUILD_DLL -DTAO_FTRTEVENT_BUILD_DLL The ACE_BUILD_DLL must only be set when you build the ACE dll, the TAO_FTRTEVENT_BUILD_DLL should only be set when you build the FTRTEVENT dll. Johnny > Hi Kitty, > > > The above errors doesn't make sense. Please make sure you > have the correct > > settings for LD_LIBRARY_PATH etc. BTW, which Makefiles are > you using ? The > > ones shipped with ACE/TAO or generated from MPC or ??? > > > > I am using my own Makefile. (I have listed each command in > the prf.txt) > > I have attached the PRF as .txt file as it is a bit long. > > Thanks and Regards > Pavan U M. > ...

[tao-users] RE: [ace-users] Error in $TAO_ROOT/tao on Cygwin #2
Hi, Thanks for the info, but I doubt this is a good change. At the moment I have sponsoring for improving the Cywin support we will setup a static build and monitor the status daily. Johnny > -----Original Message----- > From: Daniella Malin [mailto:daniella@lmtgtm.org] > Sent: donderdag 7 oktober 2004 17:13 > To: Johnny Willemsen > Cc: 'Daniella Malin'; 'Russ Leach'; 'Tao-Users' > Subject: Re: [ace-users] Error in $TAO_ROOT/tao on Cygwin > > Comments below > > Johnny Willemsen wrote: > > >Hi, > > > > > > > >>You suggested that I check if the > >>ACE_Wchar_Codeset_Translator is linked > >>into the ACE lib. > >>What I find is that the file in which WChar_Codeset_Translator is > >>defined, CDR_Stream.h, is > >>in the ACE lib and other classes defined in that file, such as > >>ACE_OutputCDR are linked into > >>the ACE lib but WChar_Codeset_Translator is not. > >>In fact, > >> > nm libACE.a | grep Translator > >>yields nothing. > >> > >>Since this step wasn't a problem in version x.4.1 I compared > >>CDR_Stream.h in the two > >>versions but nothing jumps out as the possible cause. > >> > >>You also suggested that I check that when you build x.4.2 I > don't link > >>by acc...

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

[ace-users] Re: [tao-users] Problem with removing event handler #2 #2
Hi Rob, > I figured that out, and removed ACE_Event_Handler::DONT_CALL from my > remove_handler call this morning. As far as I can tell handle_close is > still not getting called. Perhaps you're not defining handle_close() with the right signature? At any rate, there's no good reason for this not to work, so I recommend you crank up the debugger and figure out what's going on. thanks, doug ...

Re: [tao-users] Difference between CORBA::Exception andCORBA_Exception? #2
Hi Phil, > My two cents are that you do not change this fundamental contract. For such a > change to be warranted, it must be accompanied by a more comprehensive update > such as namespaces, STL (particular std::string---maybe a > ACE_DEBUG/ACE_Log_Msg::log type method that supports conventional output > operator<< overloading ) and maybe even exception handling. Otherwise, I see > little benefit for the pain of converting all logic such as: > > int ival = obj->foo(); > if (ival == 0) { > // call successful, continue > } else { > // foo failed, handle error > } Right, I agree with you. I just want to point out to people that changing from int to bool is a lot more complicated that it may appear at first glance! Thanks, Doug ...

[tao-users] The differences between TAO 1.4.1.2 and 1.5.1.0 #2
This is a multi-part message in MIME format. ------_=_NextPart_001_01C74A75.80E5ABB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, =20 Could someone tell me where can I find a document which describes about the differences between TAO 1.4.1.2 and 1.5.1.0? =20 Thanks with regards, Shi Lei ------_=_NextPart_001_01C74A75.80E5ABB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.2900.3020" name=3DGENERATOR></HEAD> <BODY> <DIV><FONT face=3DArial size=3D2><SPAN class=3D604250205-07022007>Hello=20 all,</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D604250205-07022007></SPAN></FONT>&nbsp;</DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D604250205-07022007>Could = someone tell=20 me where can I find a document which describes about the differences = between TAO=20 1.4.1.2 and 1.5.1.0?</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D604250205-07022007></SPAN></FONT>&nbsp;</DIV> <DI...

[ace-users] Re: Difference between version of Ace
Hi Dale, >> Have just picked up some work developed by someone who has >> left. The code uses ACE V 5.09 and I would like to know what the >> differnces between it and the latest version are? I recommend that you check out the release notes that Riverace has put out for the ACE 5.2 and ACE 5.3 releases <http://www.riverace.com/ACE_Kits/ace_kits.html>. These give a summary of the changes. Naturally, the DETAILED discussions of all the differences are available in $ACE_ROOT/ChangeLogs/ Take care, Doug -- Dr. Douglas C. Schmidt, Professor TEL: (615) 343-8197 Electrical Engineering and Computer Science FAX: (615) 343-7440 Vanderbilt University WEB: www.cs.wustl.edu/~schmidt/ Nashville, TN 37203 NET: d.schmidt@vanderbilt.edu ...

Re: [tao-users] SSLIOP and two ORBs with different SvcConfs #2
Hi > > . If you are okay using RTCORBA, you could create two POA (but of same > > priority) with two different protocol properties (please see > > $TAO_ROOT/tests/Server_Protocol), activate objects in those different > > POA's. This should work. I haven't tested this with SSLIOP. If things > > don't work with SSLIOP, it should be fairly straight forward to fix. > > I am positive that DOC would accept patches for this. > > I've played around with the Server_Protocol test. > SSLIOP can't be loaded the same time with IIOP. SSLIOP with SHMIOP works I am not sure why you would have to load IIOP with SSLIOP. SSLIOP uses two ports one for secure communication and another for insecure TCP communication. If the client thread doesn't have the right credenditial during connection lookup/creation the message is sent over the insecure connection. Do you mean to say that this is not working? > fine. SSLIOP has as ProfileID 0 like IIOP, because is also implements > IIOP. I think there is no trivial fix for this. I would be surprised if theer are no fixes ;). If you can give a test program with README's we can see where the problem is. Thanks Bala Balachandran Natarajan schrieb: > >>I've played around with the Server_Protocol test. >>SSLIOP can't be loaded the same time with IIOP. SSLIOP with SHMIOP works > > I am not sure ...

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

[ace-users] Re: Memory leak, new(UNINT) in TAO(1.2.1) ACE (5.2.1) ?
Hi Ludovic, >> we face a memory leak detected by rationnal purify, using a server in >> tao 1.2.1 and ace 5.2.1 : new(UINT). 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 $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 "guess" what version/platform/compiler/options you've using, which is error-prone and slows down our responsiveness. >> Did anybody encouter this issue ? >> Is it solved in recent version of TAO/ACE ? The version of ACE+TAO you're using an ANCIENT. Please upgrade to TAO 1.4.4, which you can download from http://deuce.doc.wustl.edu/Download.html under the heading "latest beta kit". 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 ...

Re: difference-in-difference analysis #2
Anna, I also found from the Archives a note from Dale McLerren. Perhaps this = might help: http://www.listserv.uga.edu/cgi-bin/wa?A2=3Dind0401c&L=3Dsas-l&F=3D&S=3D&= P=3D36265 Chunling, Assuming that you are modeling the response with both main effects X1 and X2 and the interaction X1*X2 included in the model, then you could run proc glm data=3Dmydata; class x2; model y =3D X1|X2 / solution; estimate "A increase by 0.1 (1)" x1 0.1 x2 0 1 x2*x1 0 0.1; estimate "A increase by 0.5 (2)" x1 0.5 x2 0 1 x2*x1 0 0.5; estimate "Diff in A (D1 =3D 1-2)" x1 -0.4 x2*x1 0 -0.4; estimate "B increase by 0.1 (3)" x1 0.1 x2 1 0 x2*x1 0.1 0; estimate "B increase by 0.5 (4)" x1 0.5 x2 1 0 x2*x1 0.5 0; estimate "Diff in B (D2 =3D 3-4)" x1 -0.4 x2*x1 -0.4 0; estimate "Diff of diff (D1 - D2)" x2*x1 0.4 -0.4; run; Note how I have built up to the final difference of differences. First, I have constructed the estimate for the response mean in group A for a change in X1 of 0.1 as well as a change in X1 of 0.5. Next, the estimate of the response mean in group A given a change of 0.1 minus the estimate of the response mean in group A given a change of 0.5 is obtained employing an estimate statement in which the terms of the seco...

Re: [ace-users] Re: [ace] compile error in mingw 3.2-rc1 (or w32api-3.2) #2
Hi, > oh. sorry. I just use ACE at studying. so I don't interested in > commercial support. (bad english. sorry. -_-) No problem with the English. Good that you are looking at ACE, it is very powerful, only the bad thing is you are using a new MinGW version that cause problems. > furthermore, I found cause about this error. it's placed in new > w32api's sys/stat.h. it define lstat as stat, so this make all > "lstat"s in ACE sources replace "stat". -_-a > > I tryed two modification (sorry for handy patch..) > 1. ace/config-win32-mingw.h, line 85 : insert below code > #define ACE_LACKS_LSTAT That is not a nice solution. > 2. ace/os_include/sys/os_stat.h, line 44 : insert below code > #if defined (__MINGW__) && (__MINGW32_MAJOR_VERSION >= 3) && > (__MINGW32_MINOR_VERSION >= 6) > #undef lstat > #undef _lstat > #endif > > it's okey. except ace/Name_Space.cpp, all code is compiled > successfully. ^_^ check this please. Ok. This should do the trick. But I have taken first another step, I have send an e-mail to the MinGW users mailing list to ask if the MinGW people can change this. They should make a normal function for lstat and handle the redirection to stat internally. Until the time being, you can use the workaround. What is the problem in ace/Name_Space.cpp? Johnny ...

RE: [ace-users] Re: [ace] compile error in mingw 3.2-rc1 (or w32api-3.2) #2
Hi, Please upgrade your mingw version to 3.7. This has been released today and contains the following fix below, they removed all defines which are just there to fool people. Your problems with MinGW should be gone now. Johnny 2005-01-13 Earnie Boyd <earnie@users.sf.net> * include/sys/stat.h (_S_IFLNK, S_IFLNK, _S_ISLNK, S_ISLNK, _lstat, lstat): Remove. * include/errno.h (ELOOP): Ditto. * include/_mingw.h: Increment version to 3.7. * Makefile.in: Ditto. > -----Original Message----- > From: owner-ace-users@cse.wustl.edu > [mailto:owner-ace-users@cse.wustl.edu] On Behalf Of Johnny Willemsen > Sent: maandag 10 januari 2005 19:11 > To: redwiki.net@gmail.com > Cc: ace-users@cs.wustl.edu > Subject: Re: [ace-users] Re: [ace] compile error in mingw > 3.2-rc1 (or w32api-3.2) > > Hi, > > > oh. sorry. I just use ACE at studying. so I don't interested in > > commercial support. (bad english. sorry. -_-) > > No problem with the English. Good that you are looking at > ACE, it is very > powerful, only the bad thing is you are using a new MinGW > version that cause > problems. > > > furthermore, I found cause about this error. it's placed in new > > w32api's sys/stat.h. it define lstat as stat, so this make all > > "lstat"s in ACE sources replace "stat". -_-a > > > > I tryed two modification (sorry ...

Re: [tao-users] Multiple ORBs in one process with different service configurations? #2
Hi > > we have an application with several ORBs in one process that should > > use different ORB service configurations. Specifically, those ORBs > > where we run into distributed deadlocks with the single threaded > > model should use thread per connection, whereas all others should > > use the single threaded model. It looks as if the svc.conf of the > > first ORB instantiated is used for all ORBs in the process. Is is at > > all possible to use different service configurations for the ORBs in > > a process. > > No, it's not currently possible to do this. Bala, do we have a > bugzilla entry that outlines how we might want to handle this at some > point? If so, perhaps Ulrich would like to help out in this endeavor. AFAIK none. We have talked about it in the past but we don't have a documented entry that explains how to address the problem. We can probably create one in the next few days and pass it to Ulrich. Thanks bala ...

[tao-users] RE: [tao-announce] ACE+TAO+CIAO-x.4.2 released
> . Initial support for new Linux sys_epoll() interface in > Dev_Poll_Reactor. The obsolete Linux /dev/epoll interface is no > longer supported. For full (hopefully final) support (patch for ACE 5.4.2) see: http://www.eko.net.pl/~jarek/ace/dev_poll_reactor/20040801/Dev_Poll_Reactor.cpp.diff Please let me know about any problems. Regards, Jarek Jaroslaw Nozderko GSM +48 601131870 / Kapsch (22) 6075013 jaroslaw.nozderko@polkomtel.com.pl IT/CCBS/RS - Analyst Programmer Hi, On Tue, 2004-08-03 at 01:44, Jaros´┐Żaw Nozderko wrote: > > . Initial support for new Linux sys_epoll() interface in > > Dev_Poll_Reactor. The obsolete Linux /dev/epoll interface is no > > longer supported. > > For full (hopefully final) support (patch for ACE 5.4.2) see: > > http://www.eko.net.pl/~jarek/ace/dev_poll_reactor/20040801/Dev_Poll_Reactor.cpp.diff > > Please let me know about any problems. Jarek's patch is also available in our CVS HEAD branch. Thanks Jarek! -Ossama ...

Web resources about - Re: [tao-users] Reactive/Concurrency: Difference between different ORBReactorType #2 - comp.soft-sys.ace

Resources last updated: 3/22/2016 10:32:45 PM