From dpg1@grisby.org Fri Nov 29 16:23:54 2002 Received: from pc3-cmbg4-5-cust109 (pc3-cmbg4-5-cust109.cmbg.cable.ntl.com [81.96.74.109]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id gATGNs830524 for ; Fri, 29 Nov 2002 16:23:54 GMT Received: from grisby.org (dpg1@localhost) by pc3-cmbg4-5-cust109 (8.11.2/8.11.2) with ESMTP id gATGNum18341 for ; Fri, 29 Nov 2002 16:23:56 GMT Message-Id: <200211291623.gATGNum18341@pc3-cmbg4-5-cust109> X-Authentication-Warning: pc3-cmbg4-5-cust109: dpg1 owned process doing -bs To: omniorb-dev@omniorb-support.com From: Duncan Grisby Date: Fri, 29 Nov 2002 16:23:56 +0000 Subject: [omniORB-dev] Test Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: Hello! -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From kendall@drakealumni.net Wed Jan 22 16:25:36 2003 Received: from sccmmhc01.mchsi.com (sccmmhc01.mchsi.com [204.127.203.183]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0MGPZ815322 for ; Wed, 22 Jan 2003 16:25:36 GMT Received: from drakealumni.net ([12.216.164.190]) by sccmmhc01.mchsi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20030122162531.ROTE2338.sccmmhc01.mchsi.com@drakealumni.net> for ; Wed, 22 Jan 2003 16:25:31 +0000 Message-ID: <3E2E6AA7.4070905@drakealumni.net> Date: Wed, 22 Jan 2003 03:55:51 -0600 From: kendall bailey User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: omniorb-dev@omniorb-support.com Content-Type: multipart/mixed; boundary="------------070002050106060109060005" Subject: [omniORB-dev] ImR idl proposal Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. --------------070002050106060109060005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Attached is some IDL I've written which covers what I believe has been discussed as capabilities of the portable ImR for use with omniORB. I've verified it compiles, but haven't implemented anything yet. I'm putting this out for comment. Kendall --------------070002050106060109060005 Content-Type: text/plain; name="imr.idl" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="imr.idl" #ifndef omni_implementation_repository_idl_ #define omni_implementation_repository_idl_ /** * Interface of a portable implementation repository. */ module omniImR { typedef string Process_t; interface ProcessManager; interface LoadManager; //------------------------------------------------------------ exception UnknownName { string name; }; //------------------------------------------------------------ exception WrongProcess { }; //------------------------------------------------------------ exception DuplicateName { string name; }; //------------------------------------------------------------ exception BadRegex { }; //------------------------------------------------------------ typedef sequence string_list; //------------------------------------------------------------ /** * defines a name/value pair where the value is * a numeric measure of some load */ struct LoadInfo { string metric; double value; }; typedef sequence LoadInfo_list; //------------------------------------------------------------ /** * defines a simple 1:N mapping of pysical process name to * logical program names. It's likely each program name will * correspond to a POA name. If a process is thought to be * running, it's manager is included, otherwise it is nil. */ struct ProgramMapping { string process_name; ProcessManager manager; string_list program_names; }; typedef sequence ProgramMapping_list; //------------------------------------------------------------ /** * defines a single member of a replica group. */ struct GroupMember { ProcessManager manager; string program; Object ref; }; typedef sequence Group_list; //------------------------------------------------------------ /** * defines a complete group of replicas */ struct GroupMapping { string group_name; Group_list members; }; typedef sequence GroupMapping_list; //------------------------------------------------------------ /** * Allows administration of the ImR. */ interface ImplementationRepositoryAdmin { /** * Make the ImR aware of a physical process that it can * potentially start/stop. * * start_command may have a @imr_ior@ token where * the ImR can plug in it's own IOR on the command line. * * stop_command may have a @pm_ior@ token where the * ProcessManager's ior is placed. */ void registerProcess( in string process_name, in string start_command, in string stop_command ) raises( DuplicateName ); /** add a logical program to a physical process. * This tells the ImR that when requests come in for * the given program, it should ensure the associated * process is started */ void addProgramToProcess( in string process_name, in string program_name ) raises( DuplicateName ); /** * Permenantly remove a program from a process. This * should be done prior to adding the same program to * another process. */ void removeProgramFromProcess( in string process_name, in string program_name ) raises( UnknownName ); /** * Generate a persistent reference. It's not necessary * for the process or program to be registered in advance. * This just generates an appropriate reference for future use * without adding to the persistent state of the ImR at all. */ Object generatePersistent( in string program_name, in string object_name); /** * Find all processes which match the expression and return * all mappings of process -> programs. The format of the * regular expression is an implementation detail. For example, * if the the ImR is implemented in Python, then the Python re * module may be used to match program names. In any case, an * empty string should return the complete process list. * note: an iterator based method may be needed here too, if the * returned list may get very large. */ ProgramMapping_list getMappings( in string process_name_exp) raises( BadRegex ); /** * Find all processes which have a program which matches the * expression. See getMappings() above. Each ProgramMapping * instance should have only those program names which match * the expression listed in the program_names field. To get * full listings, use getMappings(). An empty expression * should return all of the mappings. * note: an iterator based method may be needed here too. */ ProgramMapping_list getProcesses( in string program_name_exp) raises( BadRegex ); /** * Returns the groups which match the expression. * An empty expression should return all groups. */ GroupMapping_list getGroups( in string group_name_exp) raises( BadRegex ); }; //------------------------------------------------------------ interface ImplementationRepository { /** * Upon startup, a process should register. * The ImR returns a process_id that the process should * use to identify itself with each request. */ Process_t rebindProcess( in string process_name, in ProcessManager manager ); /** * Notify the ImR that the process is shutting down */ void unbindProcess( in Process_t process_id); /** * Returns an indirect reference for an object hosted * by the named program. The program must already be * registered with the process. The process * calling this must have notified the ImR that it started * and supply the ImR assigned process_id. * * An ImR implementation is free to handle URI's * of the form corbaloc:::/# * but it isn't required. */ Object makePersistent( in Process_t process_id, in string program_name, in string obj_name ) raises( UnknownName, WrongProcess ); /** * Tells the ImR that a specific object is part of a group of * replicas. If the group doesn't already exist, it will be * created. The indirect reference returned will utilize load * balancing mechanisms when selecting a member of the group. * Group names need to be globally unique, not just within a program * since group members will naturally reside in multiple programs. */ Object addToPersistentGroup( in Process_t process_id, in string program_name, in string group_name, in Object ref) raises( UnknownName, WrongProcess ); }; //------------------------------------------------------------ /** An interface that the ImR uses to manage a running * process. When a process starts, it should supply one of these * to the ImR to enable redirection of requests. */ interface ProcessManager { /** When handling an indirect reference, the ImR uses * this to find the direct reference. Object getDirectReference( in string program_name, in string object_name) raises (UnknownName); /** Each process is assigned an temporary id when it * starts. This should return that id. */ string getProcessId(); /** * Each process must return a LoadManager (or nil if it * doesn't support load balancing) so the ImR can make * load balancing decisions. */ LoadManager getLoadManager(); /** * return a platform dependent description of the processes * identity. This could be as simple as a pid, or as complex * as the result of a detailed Unix "ps" command. * Recommended is something like: * example: "123.456.7.8 1345 myServer" * This makes it easy for tools to show info about all running processes * that the ImR knows about. */ string getProcessInfo(); }; /** * An interface for gathering load information. * some info may be process specific, and some may be host * specific. */ interface LoadManager { /** * get a name for the host. There may be multiple load managers * to a host, and some load data may need to be collected only * once from a particular host. This name allows the ImR to * avoid redundant load queries. */ string getHostName(); /** * The ImR will query the LoadManager for a measure of some * metrics. The LoadManager is responsible for returning * as many as it knows how to in a timely manner. * The ImR implementation will determine what metrics are * important and which are process vs. host level metrics. */ LoadInfo_list queryLoad( in string_list load_metrics ); }; }; #endif --------------070002050106060109060005-- From lockhart@fourpalms.org Wed Jan 22 19:30:19 2003 Received: from myst.fourpalms.org (myst.jpl.nasa.gov [137.78.15.105]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0MJUJ824319 for ; Wed, 22 Jan 2003 19:30:19 GMT Received: from fourpalms.org (localhost.localdomain [127.0.0.1]) by myst.fourpalms.org (Postfix) with ESMTP id 78113346073A; Wed, 22 Jan 2003 14:30:16 -0500 (EST) Message-ID: <3E2EF148.3040505@fourpalms.org> Date: Wed, 22 Jan 2003 11:30:16 -0800 From: Thomas Lockhart Organization: Yes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Duncan Grisby Cc: baileyk@schneider.com, omniorb-dev@omniorb-support.com References: <200301201123.h0KBNWa26062@grisby.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [omniORB-dev] Re: [omniORB] Implementation Repository Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: (redirected to the omniorb-dev mailing list) > I think the ImR should work with flat files, to avoid dependencies on > external applications, and to make it easy to install. It could have > an option to use a database, but I think it should work without one. If it is implemented in python (which sounds good to me; note that omniIDL requires it anyway and we haven't yet demonstrated how to use this with another orb) then we should probably use an XML representation for the flat file since the interfaces ship with python. >>Anyone else interested in this, how should we start to hammer out the IDL >>for the ImR and management interfaces? Will be posting comments. The IDL posted by Kendall has a lot of content not directly related to fundamental ImR interactions (e.g. load information etc) and I'd like to split the discussion to focus on the fundamental features first... - Tom From kendall@drakealumni.net Wed Jan 22 19:56:18 2003 Received: from sccmmhc01.mchsi.com (sccmmhc01.mchsi.com [204.127.203.183]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0MJuI825555 for ; Wed, 22 Jan 2003 19:56:18 GMT Received: from drakealumni.net ([12.216.164.190]) by sccmmhc01.mchsi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20030122195615.THDH2338.sccmmhc01.mchsi.com@drakealumni.net>; Wed, 22 Jan 2003 19:56:15 +0000 Message-ID: <3E2E9C0A.8030006@drakealumni.net> Date: Wed, 22 Jan 2003 07:26:34 -0600 From: kendall bailey User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Lockhart , omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] Re: [omniORB] Implementation Repository References: <200301201123.h0KBNWa26062@grisby.dyndns.org> <3E2EF148.3040505@fourpalms.org> In-Reply-To: <3E2EF148.3040505@fourpalms.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: Thomas Lockhart wrote: > If it is implemented in python (which sounds good to me; note that > omniIDL requires it anyway and we haven't yet demonstrated how to use > this with another orb) then we should probably use an XML > representation for the flat file since the interfaces ship with python. The fact that omniIDL is implemented with Python shouldn't constrain the implementation of the ImR. If I use Java or C++ and only the standard CORBA APIs, then the ImR should be portable to other ORBs which don't use Python in their IDL compiler. I plan to use Python just because Python is fun and omniORBpy is a great ORB. I think the details that Duncan has spelled out as far as the encoding of data in the object ids and how the ImR would interact with a server process to handle the indirect binding has already shown how this could be used with another orb. Are there still open questions? I'm not convinced that XML is appropriate for ImR data storage needs. My experience with it has been that parsing it is quite slow. I like what omniNames does for persistence. It's simple and it works. I'd though I might try to generalize the approach for the ImR persistence needs. In particular I'm not sure how to have a well formed XML document that can have data added incrementally just by appending more lines of text. > > Will be posting comments. The IDL posted by Kendall has a lot of > content not directly related to fundamental ImR interactions (e.g. > load information etc) and I'd like to split the discussion to focus on > the fundamental features first... > The load balancing stuff is critical for me, which is why I've included it in my first go. I tried to keep it quite simple in the interfaces I've defined and allow for varying levels of implementation. It seems natural to me to put it in the ImR since both the ImR and an active load balancing service need to do indirect binding. I'll look forward to your comments. Thanks, Kendall From lockhart@fourpalms.org Wed Jan 22 20:13:32 2003 Received: from myst.fourpalms.org (myst.jpl.nasa.gov [137.78.15.105]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0MKDV826387 for ; Wed, 22 Jan 2003 20:13:31 GMT Received: from fourpalms.org (localhost.localdomain [127.0.0.1]) by myst.fourpalms.org (Postfix) with ESMTP id 18D21346073A; Wed, 22 Jan 2003 15:13:34 -0500 (EST) Message-ID: <3E2EFB6D.1030007@fourpalms.org> Date: Wed, 22 Jan 2003 12:13:33 -0800 From: Thomas Lockhart Organization: Yes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kendall bailey Cc: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] ImR idl proposal References: <3E2E6AA7.4070905@drakealumni.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: > Attached is some IDL I've written which covers what I believe has been > discussed as capabilities of the portable ImR for use with omniORB. I've > verified it compiles, but haven't implemented anything yet. I'm putting > this out for comment. OK, here are some comments :) 1) The IDL is for a "portable implementation repository". How about naming the module "ImplRepo" or ?? rather than "omniImR" which sounds rather specific to omniORB? 2) There are interfaces for several features including load monitoring etc which are not fundamental to the operation of an ImR. We should separate those out into separate IDL files to allow minimalist ORB implementations to ignore those interfaces. And perhaps to allow us to ignore them for our first implementation ;) 3) Programs, processes, POAs, and objects need to be kept straight. I'm not sure that the distinction between "program" and "process" is necessary, and "object" does not really appear in the IDL but matching clients to server *objects* is my simplistic view of what the ImR does. H&V use "server application" and "object"; "POA" is mentioned too. I'd suggest using H&V (specifically chapter 14) for guidance on terminology. 4) I like the idea of allowing one "server application" to host multiple "objects", so the extra layers in the IDL to support this is worth the effort. More comments later... - Tom From kendall@drakealumni.net Wed Jan 22 21:35:15 2003 Received: from sccmmhc02.mchsi.com (sccmmhc02.mchsi.com [204.127.203.184]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0MLZF830321 for ; Wed, 22 Jan 2003 21:35:15 GMT Received: from drakealumni.net ([12.216.164.190]) by sccmmhc02.mchsi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20030122213513.UYDC5896.sccmmhc02.mchsi.com@drakealumni.net>; Wed, 22 Jan 2003 21:35:13 +0000 Message-ID: <3E2F0E12.8010806@drakealumni.net> Date: Wed, 22 Jan 2003 15:33:06 -0600 From: kendall bailey User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Lockhart CC: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] ImR idl proposal References: <3E2E6AA7.4070905@drakealumni.net> <3E2EFB6D.1030007@fourpalms.org> In-Reply-To: <3E2EFB6D.1030007@fourpalms.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: Thomas Lockhart wrote: > > OK, here are some comments :) > > 1) The IDL is for a "portable implementation repository". How about > naming the module "ImplRepo" or ?? rather than "omniImR" which sounds > rather specific to omniORB? Possibly. It's too early to worry much about that. I suppose I'm hoping that this become a standard part of the omniORB family. Still free to work with other orbs, but an official omni* sub-project like omniNotify. We'll see. > > 2) There are interfaces for several features including load monitoring > etc which are not fundamental to the operation of an ImR. We should > separate those out into separate IDL files to allow minimalist ORB > implementations to ignore those interfaces. And perhaps to allow us to > ignore them for our first implementation ;) I don't understand the "several". What else besides the load balancing? My next pass will try to split this out. > > 3) Programs, processes, POAs, and objects need to be kept straight. > I'm not sure that the distinction between "program" and "process" is > necessary, and "object" does not really appear in the IDL but matching > clients to server *objects* is my simplistic view of what the ImR > does. H&V use "server application" and "object"; "POA" is mentioned > too. I'd suggest using H&V (specifically chapter 14) for guidance on > terminology. I've read H&V. It assumes the POA will interact directly with the ImR. In fact, it makes the assumption that a portable ImR is impossible. I agreed, until Duncan described what he had in mind. Indirect binding won't be as seamless as H&V assumes it should be, but it should work just as well. Duncan's approach was so similar to the load balancing service I've worked on that the two seemed made for each other. I wasn't too thrilled with the term "program" either. I couldn't use "adapter" as H&V does. However, there should be some logical grouping of objects so that a bunch can be migrated all at once. The ImR could be told that program X is now hosted in process Y rather than Z, and the thousands of objects that once would have auto-started process Z now will start process Y. The ImR will not store the identity of those thousands of objects. Rather it knows only the "program" aka "adapter" in H&V lingo. With a portable ImR there is no need to make all those objects share a POA though. H&V table 14.1 has "Logical Server Name", "POA Name", and host/port. I'm replacing these with process, program and an IOR for a ProcessManager. You're welcome to suggest better names. Now that I review H&V, even though 14.4.2 doesn't list load balancing, 14.4.1 does. It might therefore be considered "fundamental"... > > 4) I like the idea of allowing one "server application" to host > multiple "objects", so the extra layers in the IDL to support this is > worth the effort. > > More comments later... I'll see what I can do with the IDL. Thanks, Kendall From lockhart@fourpalms.org Thu Jan 23 00:35:31 2003 Received: from myst.fourpalms.org (dhcp-78-77-226.jpl.nasa.gov [137.78.77.226]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0N0ZU806460 for ; Thu, 23 Jan 2003 00:35:30 GMT Received: from fourpalms.org (localhost.localdomain [127.0.0.1]) by myst.fourpalms.org (Postfix) with ESMTP id 3EA75346073A; Wed, 22 Jan 2003 19:35:29 -0500 (EST) Message-ID: <3E2F38D1.40700@fourpalms.org> Date: Wed, 22 Jan 2003 16:35:29 -0800 From: Thomas Lockhart Organization: Yes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kendall bailey Cc: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] ImR idl proposal References: <3E2E6AA7.4070905@drakealumni.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: More comments: The ImplementationRepositoryAdmin interface is used by meta-clients to manipulate the ImR. The ImplementationRepository interface is used by servers to interact with the ImR. The ProcessManager interface is used by the ImR to interact with a server. 4b) The ImplementationRepositoryAdmin interface is not used by simple servers, so should be split out to allow servers to ignore the definitions. 4c) The ImplementationRepository and ProcessManager interfaces are used between ImR and server, so could be mixed into the same IDL file; no need to decouple them. Unless one could imagine a very simple server which does not bother to implement any ProcessManager functionality, which would then force the ImR to use more brute-force methods (suggested by Duncan earlier) to manipulate the server. So these should be separated also. 4d) Same with the LoadManager interface. I'm not certain where the server object for load information is required to live; I could imagine that one could get fine-grained statistics by distributing some server functions into application servers then asking the ImR to collate these for an integrated report. 5) registerProcess() could return a "process object", which can be used subsequently for operations like addProgramToProcess(). Seems to be cleaner and more CORBA-like than stringifying everything. 6) There is no corresponding unregisterProcess(). The IDL as-written allows "programs" to be added and removed, but not "processes". More comments later :) - Tom From kendall@drakealumni.net Thu Jan 23 03:41:19 2003 Received: from sccmmhc02.mchsi.com (sccmmhc02.mchsi.com [204.127.203.184]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0N3fJ815357 for ; Thu, 23 Jan 2003 03:41:19 GMT Received: from drakealumni.net ([12.216.164.190]) by sccmmhc02.mchsi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20030123034118.ZIOG5896.sccmmhc02.mchsi.com@drakealumni.net>; Thu, 23 Jan 2003 03:41:18 +0000 Message-ID: <3E2F63DF.2030805@drakealumni.net> Date: Wed, 22 Jan 2003 21:39:11 -0600 From: kendall bailey User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Lockhart CC: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] ImR idl proposal References: <3E2E6AA7.4070905@drakealumni.net> <3E2F38D1.40700@fourpalms.org> In-Reply-To: <3E2F38D1.40700@fourpalms.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: Thomas Lockhart wrote: > More comments: > > The ImplementationRepositoryAdmin interface is used by meta-clients to > manipulate the ImR. The ImplementationRepository interface is used by > servers to interact with the ImR. The ProcessManager interface is used > by the ImR to interact with a server. > > 4b) The ImplementationRepositoryAdmin interface is not used by simple > servers, so should be split out to allow servers to ignore the > definitions. ... Would you like to suggest idl file names, modules names and so on? I typically don't split modules across idl files, just by habit. More often I end up with one module per application. If you suggest an organization, I'll see if I can follow it. I've alread eliminated the load balancing stuff and subclassed the interfaces to add it in within another module. > > 5) registerProcess() could return a "process object", which can be > used subsequently for operations like addProgramToProcess(). Seems to > be cleaner and more CORBA-like than stringifying everything. I'm not sure what this buys. It certainly seems "more OO", but that isn't such a strong motivation for me. During my brief use of the Orbix 2000 ImR I didn't see such OO interfaces. The itadmin tool's commands seemed fairly relational (textual keys to relate things). > > 6) There is no corresponding unregisterProcess(). The IDL as-written > allows "programs" to be added and removed, but not "processes". Yep. That was overlooked. Thanks, Kendall From pesco@gmx.de Thu Jan 23 08:23:13 2003 Received: from arctic.sol.local (pD9004504.dip.t-dialin.net [217.0.69.4]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0N8NC829097 for ; Thu, 23 Jan 2003 08:23:12 GMT Received: by arctic.sol.local (Postfix, from userid 1000) id 2E28144D06; Thu, 23 Jan 2003 09:23:10 +0100 (CET) Date: Thu, 23 Jan 2003 09:23:10 +0100 From: pesco@gmx.de To: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] ImR idl proposal Message-ID: <20030123082309.GA6733@arctic.sol.local> References: <3E2E6AA7.4070905@drakealumni.net> <3E2EFB6D.1030007@fourpalms.org> <3E2F0E12.8010806@drakealumni.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E2F0E12.8010806@drakealumni.net> User-Agent: Mutt/1.4i Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: On Wed, Jan 22, 2003 at 03:33:06PM -0600, kendall bailey wrote: > > I wasn't too thrilled with the term "program" either. I couldn't use > "adapter" as H&V does. However, there should be some logical grouping > of objects so that a bunch can be migrated all at once. The ImR could > be told that program X is now hosted in process Y rather than Z, and the > thousands of objects that once would have auto-started process Z now > will start process Y. Why can't we use adapters to group objects? > With a portable ImR there is no need to make all those > objects share a POA though. I don't think there's a need for a lot of objects to share the same POA if we group by POA because the objects themselves could reside in children of the POA registered in the ImR... > H&V table 14.1 has "Logical Server Name", "POA Name", and host/port. > I'm replacing these with process, program and an IOR for a > ProcessManager. You're welcome to suggest better names. This reminds me of another question. Which information about an object should comprise its identity within the location domain? If administered by adapter, the object key within the target ORB, or some resemblence thereof (assuming we can't get at the key in a portable way) would work? -Sven Moritz From kendall@drakealumni.net Thu Jan 23 15:14:58 2003 Received: from sccmmhc01.mchsi.com (sccmmhc01.mchsi.com [204.127.203.183]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0NFEv816447 for ; Thu, 23 Jan 2003 15:14:58 GMT Received: from drakealumni.net ([12.216.164.190]) by sccmmhc01.mchsi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20030123151453.TLH2338.sccmmhc01.mchsi.com@drakealumni.net>; Thu, 23 Jan 2003 15:14:53 +0000 Message-ID: <3E30066E.6060501@drakealumni.net> Date: Thu, 23 Jan 2003 09:12:46 -0600 From: kendall bailey User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pesco@gmx.de CC: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] ImR idl proposal References: <3E2E6AA7.4070905@drakealumni.net> <3E2EFB6D.1030007@fourpalms.org> <3E2F0E12.8010806@drakealumni.net> <20030123082309.GA6733@arctic.sol.local> In-Reply-To: <20030123082309.GA6733@arctic.sol.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: pesco@gmx.de wrote: >On Wed, Jan 22, 2003 at 03:33:06PM -0600, kendall bailey wrote: > > >>I wasn't too thrilled with the term "program" either. I couldn't use >>"adapter" as H&V does. However, there should be some logical grouping >>of objects so that a bunch can be migrated all at once. The ImR could >>be told that program X is now hosted in process Y rather than Z, and the >>thousands of objects that once would have auto-started process Z now >>will start process Y. >> >> > >Why can't we use adapters to group objects? > > > The design of the ImR I'm pursueing is based on some of Duncan's suggestions. Rather than look at object keys and tie objects to POA names, the ImR relies on the server application to generate the direct reference on demand when passed a couple identifiers. With this approach there is no reason to limit a server app to use an adapter name as one of the identifiers, and so I didn't want the terminology used to suggest that should be the case. >I don't think there's a need for a lot of objects to share the same >POA if we group by POA because the objects themselves could reside in >children of the POA registered in the ImR... > > > Related POAs will still generate different object keys, so if the ImR is going to see them all as one logical group, it still needs a single identifier. It can't recognize the related POAs by decoding object keys. > > >>H&V table 14.1 has "Logical Server Name", "POA Name", and host/port. >>I'm replacing these with process, program and an IOR for a >>ProcessManager. You're welcome to suggest better names. >> >> > >This reminds me of another question. Which information about an object >should comprise its identity within the location domain? If >administered by adapter, the object key within the target ORB, or some >resemblence thereof (assuming we can't get at the key in a portable way) >would work? > > > The assumption I am working with is that 2 identifiers are enough to uniquely find an object. A "program" name (or subsystem, or adapter, or logical_server) and an object name. The ImR must be told which physical process the program lives in at any particular time. With that it can start the process if needed, and ask the process to generate a direct reference to the object with the given program and object name. The server process is responsible for activating any POA required. I expect the program name will often be an adapter name like "rootPOA/subPOA1/subPOA2", and then the server program may trigger adapter activators via find_POA() calls to get the right POA, then generate an IOR from the object name with create_reference_with_id(). Of course it could do something more direct than that. An ImR client lib might need a callback hook to let it look up the repository id associated with a given object too. I haven't got that far. This approach costs an additional round trip between the ImR and the server process, but it avoids tinkering with object keys. Kendall From lockhart@fourpalms.org Thu Jan 23 16:36:20 2003 Received: from myst.fourpalms.org (golem.fourpalms.org [64.3.68.148]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0NGaK820421 for ; Thu, 23 Jan 2003 16:36:20 GMT Received: from fourpalms.org (localhost.localdomain [127.0.0.1]) by myst.fourpalms.org (Postfix) with ESMTP id 499EC346073A for ; Thu, 23 Jan 2003 11:36:11 -0500 (EST) Message-ID: <3E3019FA.4060408@fourpalms.org> Date: Thu, 23 Jan 2003 08:36:10 -0800 From: Thomas Lockhart Organization: Yes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: omniORB development list Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [omniORB-dev] Server support for ImR interfaces Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: Duncan has indicated that he would like to see no implicit support for the ImR within the omniORB orb. So a server interacting with an ImR would have explicit calls. What would a complete solution look like from an application server point of view? I'd like to see a suggested code snippet or at least a sequence of operations required by a server. And this should include managing object and POA startup/creation and shutdown/destruction, since those need to coordinate with an ImR and could be initiated by either the ImR or by the application server itself. I just reviewed the TAO docs for their ImR and notice that the implementation changed recently to support a more distributed model than before. They have the ImplRepo_Service application as always, but now the ImR_Activator does most of the heavy lifting, with the ImplRepo_Service being simply a single point of contact for a client, then delegating the work to an ImR_Activator running on the host for the target server. We should certainly examine the IDL associated with these applications (actually, the files are ".pidl" since they require a bit of massaging). For example, I was thinking about the need for the ImR to test for the health of a server and notice that the TAO IDL include a ping() method for just this purpose. And we should examine IDL from other ORB implementations to get guidance where they overlap with our goals. - Tom From lockhart@fourpalms.org Thu Jan 23 16:45:24 2003 Received: from myst.fourpalms.org (www.fourpalms.org [64.3.68.148]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0NGjN820869 for ; Thu, 23 Jan 2003 16:45:24 GMT Received: from fourpalms.org (localhost.localdomain [127.0.0.1]) by myst.fourpalms.org (Postfix) with ESMTP id 281E3346073A; Thu, 23 Jan 2003 11:45:25 -0500 (EST) Message-ID: <3E301C24.1090207@fourpalms.org> Date: Thu, 23 Jan 2003 08:45:24 -0800 From: Thomas Lockhart Organization: Yes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kendall bailey Cc: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] ImR idl proposal References: <3E2E6AA7.4070905@drakealumni.net> <3E2F38D1.40700@fourpalms.org> <3E2F63DF.2030805@drakealumni.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: > Would you like to suggest idl file names, modules names and so on? I > typically don't split modules across idl files, just by habit. More > often I end up with one module per application. If you suggest an > organization, I'll see if I can follow it. I've alread eliminated the > load balancing stuff and subclassed the interfaces to add it in within > another module. OK, will do. I'm a bit unclear on how we will proceed with development, but we should have a consensus on the initial framework before diving in. Incremental development is the way to go imho, so having specific goals for the first round of implementation will be important. For example, any ImR needs to start and stop processes, and to redirect queries. Our first round should do just that, with a module framework that allows expansion into the other areas of interest such as load balancing and object remapping. > I'm not sure what this buys. It certainly seems "more OO", but that > isn't such a strong motivation for me. During my brief use of the Orbix > 2000 ImR I didn't see such OO interfaces. The itadmin tool's commands > seemed fairly relational (textual keys to relate things). Well, design style should be based on something. May as well smell like OO if all else is equal ;) - Tom From kendall@drakealumni.net Thu Jan 23 17:37:20 2003 Received: from sccmmhc01.mchsi.com (sccmmhc01.mchsi.com [204.127.203.183]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0NHbK823379 for ; Thu, 23 Jan 2003 17:37:20 GMT Received: from drakealumni.net ([12.216.164.190]) by sccmmhc01.mchsi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20030123173717.CBYM2338.sccmmhc01.mchsi.com@drakealumni.net>; Thu, 23 Jan 2003 17:37:17 +0000 Message-ID: <3E3027CD.3000404@drakealumni.net> Date: Thu, 23 Jan 2003 11:35:09 -0600 From: kendall bailey User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Lockhart CC: omniORB development list Subject: Re: [omniORB-dev] Server support for ImR interfaces References: <3E3019FA.4060408@fourpalms.org> In-Reply-To: <3E3019FA.4060408@fourpalms.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: Thomas Lockhart wrote: > Duncan has indicated that he would like to see no implicit support for > the ImR within the omniORB orb. So a server interacting with an ImR > would have explicit calls. What would a complete solution look like > from an application server point of view? I'd like to see a suggested > code snippet or at least a sequence of operations required by a > server. And this should include managing object and POA > startup/creation and shutdown/destruction, since those need to > coordinate with an ImR and could be initiated by either the ImR or by > the application server itself. I think something like what you are asking for was posted to the omniORB list. I posted a sequence of steps and Duncan patched it up a bit. sequence: 1. server starts up. 2. server finds a reference to the ImR (either from command line or in configuration file or...) 3. server instantiates a ProcessManager and activates it 4. server sends ImR the persistent process name and the ProcessManager reference and receives a temporary identity from the ImR. The temporary identity is my idea just to keep multiple servers from using the same persistent name and confusing the ImR. At this point the server can start POAs, activate objects, register objects in a name service or whatever. If the server is started in "prepare" mode, then: 5. server asks the ImR to create persistent references to any objects it wishes to puplish persistent references for. 6. server publishes the references (in a name service, to a file, to stdout, or wherever) I'll inject some steps for replica groups here, but if you aren't interested, just skip it. 7. server activates replica instances. How these replicas share/transfer state, if necessary, does not involve the ImR, except the ImR may be called on to get a list of all replica members. 8. server adds the replica object references to named groups known to the ImR. 9. The ImR returns the group persistent reference to the server 10. ImR stores the groups of replicas, so that invocations can be forwarded according to a balancing strategy. When a client invokes on an ImR generated persistent reference: 11. ImR determines whether it is a replica group reference or not. If so, it selects* a member and replies with a location forward. 12. Otherwise, the ImR determines the process identity, and checks to see if the process is up. 13. If not and the ImR can start it, then it does so. 14. Once the ImR has a reference to the appropriate ProcessManager, the ImR requests a direct reference based on the program and object identities. 15. server does whatever it needs to do (start POAs, activate objects, or whatever) to generate the reference and return it. 16. ImR returns a location forward to the client with the direct reference. * The selection process may test object health and/or system load Step 14 may take a while, if the server process needs to start up. I was thinking part of registering a start command must also tell the ImR the acceptable time limit. If no ProcessManager registers in that time, the client would get a TRANSIENT exception. Step 15 may involve adapter activators, as I described in a previous post. A C++ and/or Python library may be included with the ImR that clients can use to simplify the implementation of a ProcessManager. Shutdown should be simple. If the ImR is told to stop a server (I don't think I have an interface for that yet...), it fires the stop_command and waits. If we have a ping() method I suppose it could keep pinging the ProcessManager until it fails, or give up and report an error. Otherwise it waits for the ProcessManager to tell it that it's going down. Any replica object known to be in that process are removed from any groups they are in. Server processes can shut down any POAs any time they choose, or shut down completely. The ImR does not act on POAs directly, just processes. Processes should notify the ImR of shutdown. If a process crashes, the ImR will need logic to determine when a restart should be attempted. Getting OBJECT_NOT_EXIT during a call to the ProcessManager may be enough or we may need the ping() you mentioned. The decision to fire the start_command should be configurable. > > I just reviewed the TAO docs for their ImR and notice that the > implementation changed recently to support a more distributed model > than before. They have the ImplRepo_Service application as always, but > now the ImR_Activator does most of the heavy lifting, with the > ImplRepo_Service being simply a single point of contact for a client, > then delegating the work to an ImR_Activator running on the host for > the target server. We should certainly examine the IDL associated with > these applications (actually, the files are ".pidl" since they require > a bit of massaging). For example, I was thinking about the need for > the ImR to test for the health of a server and notice that the TAO IDL > include a ping() method for just this purpose. And we should examine > IDL from other ORB implementations to get guidance where they overlap > with our goals. I don't have TAO installed at the moment. Could you post a link to just the IDL of interest, or just send it to me (or the list) directly if it's not too big? Splitting responsibilities between a single service process and an additional process per host obviously has advantages. I'd like to get an all-in-one solution working before federating the thing though. For the first go, if the ImR needs to start a process on another host, I think the start_command should use rsh, ssh or something else to get the process going (as described in H&V). Kendall From kendall@drakealumni.net Thu Jan 23 17:39:58 2003 Received: from sccmmhc02.mchsi.com (sccmmhc02.mchsi.com [204.127.203.184]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0NHdw823511 for ; Thu, 23 Jan 2003 17:39:58 GMT Received: from drakealumni.net ([12.216.164.190]) by sccmmhc02.mchsi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20030123173955.EYFM5896.sccmmhc02.mchsi.com@drakealumni.net>; Thu, 23 Jan 2003 17:39:55 +0000 Message-ID: <3E30286B.7080504@drakealumni.net> Date: Thu, 23 Jan 2003 11:37:47 -0600 From: kendall bailey User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Lockhart CC: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] ImR idl proposal References: <3E2E6AA7.4070905@drakealumni.net> <3E2F38D1.40700@fourpalms.org> <3E2F63DF.2030805@drakealumni.net> <3E301C24.1090207@fourpalms.org> In-Reply-To: <3E301C24.1090207@fourpalms.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: Thomas Lockhart wrote: > > Well, design style should be based on something. May as well smell > like OO if all else is equal ;) > > - Tom > I guess the design style I like is: K.I.S.S. Kendall From krbailey6@mchsi.com Mon Jan 27 22:10:30 2003 Received: from sccmmhc01.mchsi.com (sccmmhc01.mchsi.com [204.127.203.183]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0RMAT823353 for ; Mon, 27 Jan 2003 22:10:29 GMT Received: from sccqwbc04 ([204.127.203.164]) by sccmmhc01.mchsi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20030127221028.ODCT2338.sccmmhc01.mchsi.com@sccqwbc04> for ; Mon, 27 Jan 2003 22:10:28 +0000 Received: from [12.216.164.190] by sccqwbc04; Mon, 27 Jan 2003 22:10:27 +0000 From: krbailey6@mchsi.com To: omniorb-dev@omniorb-support.com Date: Mon, 27 Jan 2003 22:10:27 +0000 X-Mailer: AT&T Message Center Version 1 (Nov 13 2002) X-Authenticated-Sender: a3JiYWlsZXk2QG1jaHNpLmNvbQ== MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="NextPart_Webmail_9m3u9jl4l_16169_1043705427" Message-Id: <20030127221028.ODCT2338.sccmmhc01.mchsi.com@sccqwbc04> Subject: [omniORB-dev] ImR prototype/proof-of-concept Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: --NextPart_Webmail_9m3u9jl4l_16169_1043705427 Content-Type: text/plain Content-Transfer-Encoding: 8bit The code contained here is meant to be a prototype/proof-of-concept *only*. It's purpose is to further the discussion among the omniORB-dev group with respect to the development of a portable Implementation Repository (ImR) service for use in omniORB or mixed ORB environments (or even to replace another ORB's ImR if so desired). Some known/intentional problems/ommissions: ============================================ 1) little/no error handling 2) not thread safe. No locking, and no use of synchronization primitive to coordinate needed communication between threads. Saving of ImR state is not thread-safe at all. 3) no graceful way to shut down ImR.py or test/server.py 4) persistence of ImR state is inefficient. Any change to the state causes the full state to get re-serialized using cPickle. Topics for discussion: ======================= - Correctness/completeness of imr.idl and imradmin.idl - Persistence strategy for the ImR - Details of the server auto-start mechanism. Local vs. remote process launching. The right way/portable way to start a daemon process / Windows Service? - Logging, graceful shutdown, error handling, other boiler-plate. Kendall --NextPart_Webmail_9m3u9jl4l_16169_1043705427 Content-Type: application/x-tar; name="imr.tgz" Content-Transfer-Encoding: base64 H4sIAImlNT4AA+w97XIbN5LeX1dh1b0DlrqUh16aIilKuqIt7SqJkuOtLblk5ZItx8UazoAkVsOZ ucFQspJK3cvcu+zT3Dtcd+NjMOSQoh1Jm81yqiyTGKDRaDQa3Y1GU8yy3ScP/LTbvfbh/j78324f HpT/188TKOjs73W7B+2DJ+1OZ7/Te8L2HxoxfOYy9zPGnlyNfBHx25X17nr/D/oImH/41xJh9GB9 tDvt9kGvt2r+9w/3e2r+4eNhF8o7e22c//aDYeQ8/+TzX9sR4zjkY5bMYjEUszTiMx7nfi6SeJjx NJEiT7LbIfDHsLYDFUXMN6pb2332rPaMDeKcZ2M/gEZj5rM0yXJ/FHFWbs2K1q3as93aLAnnkepn MLtgP9VqjLH8NuWIqcwzEU/YmywJuJTD/AW9FbYj/eK1H/sTnqm3u7vPf8GDEPiHgKeE67fxVZzc xGf+jANmjB6NUwxlL7Do5/vv9rssiSd6bKrfB+jkq3kaicDP+WOP7gs/vOAT/uGeR1ZwxaDEcBeW 3+wggV+Z/viMfZsCTigZ8nnaRL7VdJfTZB6FwK4TIQFyyza4nGIXF/Amn2exLJrAamD51M/hD18A YxvPJWd5wkQI6InxLRO55NGY3Yh8yrgfTAHqf8+5zG13u/qDXQMG84yPRBzqYk8XEh3MJJrHoIeT 2ixVLK8fNtP/N9ScKEpZ1M8SwjjXw18aqcDBzvMcuw5h1SyO4DoRhg7zeCXuxThLuIuwGqkLMwkx NA5FxoMcKDPmGY+BE8ZJhm+S0V+xfJrARBZTMVJjQaqE2M8k82ctRtOrv7EZbBnMjzLuh7dsxG1T wxTQkGbOIUMBAb/ZFoEfRUiYfApkIrBT/xo6R5oKHpapKnLFkA6yfhwyOU/TqJgAX0oxiRXumkaW a2y7k5jqLshgwGGcceLEKUAG+fvtxeBpgS0IcOwFyDdjQZKN/CgJ+v2XSMDj/kuU7Me7LzWRiK2O d14CkdXHgsBzGoqQ8dOc+Bqmp0Bx1zDyuZod/W3mX/E3PJNI3zj32ArmKMbcrGJ9F7fKCgbbype4 RQ1C1ijewZP5QnLpuXtCsyypG/crMVFKncSOXLMrDmcUBInE+VNrFoRQNo9jQL5GpC+Y8bspj12p hnwlm8RiSsBprkpirqddcgUDgFuuTBiPaTOHGaRFhlwE1bW0kjSrekpXbc8l8UtoEe8hwStXb7M0 VstVtIIAIVBP1LJZbLckOhWD6S8Tnn9FDS5M/UrZuQkDARB632AVjMI8h1FKsoudopx3pKZdyECG nM9gefmwWcFmcoNEErkdupo8kjDC2aBQAmrBES4NXqNbjF5PyiD0qiWqhgcsE/k5SYCQpzzGDQs+ ySATqZl9R+w5E6T2tvzW4BkQmiPgUcCZBBF+AviwdhkKaKyCxR8KaScJdsblPMqVOhnyHLXyENaf +MDqqaxjK+D+YsiwGWAR4hrSbpTMOHALjD4SV7zPlPxiL6Fj+BvMwkJU8Q8+YtBn9U53r9XbP2gd tv6ddfZ6+2x2+5Zn1zyrOwoAynCQUxKXEfflLW00eZJExJkwMTfAKeOE+aNkjhtIZFZnBblKqxo5 Rqpmq2bSmULowiuEDv7bgcGLca1Wpf+j/YdYj4GMD2Vj3GH/dXo9a/93egcdtP+67YOt/fcYTw0s Kh/WUx8ZslZ78+dvjnA1on48GAe1GpT22Q/EbP/mwdsGegvQwmult+XyaFRZDNX9cCZi87L2mReA iIb94QVUeX3y59NGA/r9y+CrV18ekcUHFTUI8zwfpbf5FMTLQvF3o9QPrmAbOVKdwfval99/vxLU 81Hw4UOp4LuRX/r+pQJUq1Vj32emAB0mTDtOap9BbRpAo/TeheICqGhTqm4p2WfRyO2oDN2BoKq5 /bWm01JfmixVnVHVOzqyzZd7UvV0d5W0cft2iBNE3I/7tc92Qe3fhR3leTY2TPOsgksY1Qf9qxaC GthXX1W9Vou9YGLM3rHnY+o4n/zI3kNZjnulhV+8ewGKgjPtUBFkQPBjUQH+h44+q5aZv6VH+f/s gn8QXzD5fw839P92SP4fdve2/t/HeHD+QccAYfNwfeD+v2b+8a2e/w5UA17odPdBDdju/4/w7Pye xCOPr5naY2u1cZbMmJEJLfyA38C8Z4XXrOl8PkGRXtNVvjy/+OKkyeQtmJO5mHHQPj/F0kU/78wX sdfoo5hOshE7UrBb8GcoYpF72EnLzybXuCdAJdpaoNoCZh40btYlqeut9CqqN2zllg8267Wfc09B QBO/BMCjag3zzqnPlEs6gz3amFHQTws0ek9Zfsq12dfvUjDnqEUK6nrO6iWfWF0PsYWlWOC1qUuk X0tGnKfefuMTCQm74pDs0eGQHR2x+nCIZB0O64xQUzT+7W9z22fFg/If1ayHPATefP/vHPbwLBDk f7u73f8f47Hz/4BOgDvs/3avp89/O93ewQHu/73OYXe7/z/Gs8b+vwS2qHIA8GCaaAO19uu13B0s +wy/LNrMtuwOQ/S3vTna9W/I8QB90Po/WL3+u12z/tHvh/E/uF9s1/9jPDb+A31UyAidcqjHQrGJ zLDFtZ/KpzunwEZYshA6IHkces5ByYxLiSdU1lF9l596+zzMY9e/5Pk8fRg3wF32Pyx8rf+193s9 9P/0uu297fp/jKfC/teWfCKbYGDX0IKsD15fXJyfX9ZxBSeyBbVFlsRkQaIRnvr5tOWnKS3y4v07 2+49mujkV0ikcSZgo5LXwHwpnT98lCPgXaf/XjsDjKsZapNdzmUSXXOqL/xoaM+FpVcf6P7IW6C8 A05r67MGKzrLkhvPxa+1KqqIYC2g0jIBIsshLvTUSWUhqVpvssWXu9Nkxnc1F+6G/JpHu87iVd6N 2+WGe+0mq9eZdlhYXPwQI23wNPsy2QSfxXf6KBzItdrFsPUw/Pofy0Ku1n/PzoCP9/+DJdje2v+P 8SyLkPvv4479fx9m2/H/7OH+v3ewjf9+lGft/o8ba+W2vUYpYB+pFazTAFAWtaypgQFAAnSCtZWG wzfnJ1hz5EtepVGUTjegwIxLx5pT+09XO9LE30DjuEiSHLpRugY0aQ0nPB/mU46d68A4r7F4OjGb ZAC7HD7nUY9GZ/kIZafutMFD74/SbphFyOo0HsFS5SGn439zQLJ0PMLWHZBUnINgUQiTmyW3HhXU Pu0wpHQwEkTQ4xI1XS5oLUQqKlZAzhgSaYdDD8O0mzgFDTMOLGkpLoC/biEKWD/OJbz56eeaBaX9 b9ghgbOQdMidAWhbWIqrzjFSodS5CPWUlmPBF9RLqjrEsEmYkIYFXhEIqcfohj6W4hxN5/UBxVIz n0mw8KMiXhqjnHnInurvTyls+Ye4brx39RsRRSzIOLA6tlZ0oug5Cn7HcA8RB7mJ2MZeTdwdyCEX M/b7o0I17Rc6K0VfmvX7xX+efnk5PDu/HJ5+P3h76TUKWM64MAqbHBaluXNgll68c1q+B/qjG8Sz c1ciGGuwihmuBGQmyJ2eIlJzJbeIsKoBxgVWNskzD6TzHHv0Gg32B1bv1+GvLgcIqQg9DNK6r0Wn iIMCuoUf1y6sJisx2erlRaQ9otpucZDMgZeOWPsXrDhyXimMtN+qjI/q4w9HrFMGVP9cep+HjT77 XNbZ58wrEG06DZuFM+weKLzGGEPkdlS4sIq1DX0+ww1f875swZK7AnFgJbZsDfkH2OnaDd14hLG0 3Ikcn2TJPGUR90NO8h6aSJ5LZBj9dT7z5ZUH+p+BMUlMEHkG26AO1IZNBd/G/OYGxZfiu+BGg7mZ gurl6bewxEmzkGmEm7AqbLxrv2d2VgwYpx4VUS2NVzCFnm1zjdsZx1sXCQuiBOQFhugmoL4wPBcD bQjlVi44kDAUcRP/o0BevISRw/gzBQOao3m+G8+jqMXYQOrgdBjwjX+Lr8OEifyPWHscttVosRuv btuBgIbC8+HFV+dnr/7SUFU7a6t+d2Grao0G1YB5FtByiBMcAwAwhUjfLBIzII0tung1eD1Ayfj1 4NWp6hRksEApmPnxBGeAwBCtLZcA6wgjLN/BgJqI6ntXUjpKgGUsorAn3Ch5rRAoVUDVCudp10Mq NdussVDWaXYqyrq2TPVAJF4q6tgZH4sYpplita/ougNIqFxFrmyyLNg/uoPD2n9BJEDR+3vYf51e V/t/uwftfSwH+2+vvbX/HuO52/77Ndl6H+8S/vW5g80lMwDmebB1xp7BtcGOGUgmtaNY2/J9A+/D 1JEsQ2hbV8FoYxeXCY95Btqzc0Vulb+2WXHHTYvxgLSx1vDszbDAfBBqW0/rKKBSnLDX6otGBS+K 4caCSixMv1GRnGi3AapQef+HWClCuoZTQV2mIVhCX5+0tamD+1A+t37qikfnf7Bh+Q/Rxx3xP/BR yf/e3mEHdgA6/+9s7/88yrNp/gd7C2bjLBBOC+gkDqJ5yFldXwupP0B+iPUZIGz2CLycCpL+pYpE ONYRCcMIBOd9XtLF/58xRSpJThG65Njpn4GoSVO6LTqGPVeKwI+sPUUbQ56oxlEyMS/JkYIv8aLn IH8q6fYiCF6ur43aCgy9Kap9kGSw0aVJTDaNz9AzilUQxNgx4sg6SeaTaY71Rvqmr76ciLeCn0qb BQDq6rnEe5pg1GQ36FqhG90sFpF75xcoOw9yps8ZX+tRL0SG2MdNSPBC11nwwBksXpRA0NQZENYV JN1710uTX8bpeAFHwwz3xg2KoidRRBc5cWFAB5nvXpnFSxiKdmVeXq9S/OReIdYfn7HX/hUvMgLc +JlZXdMFdjOJBQLfJmaAJYgKhCCriJwFuzJP0uUkAvRuqK/bwszcquQFPvsTXXdLsj8BN12B9XwD TFJkSTBoQZcsjeYT1CiJw5KbmA3OL8AIozoGcATrp6rzJK3sO50tdY3gbMMyR0G3IiGmTiMg9vJF aUxPUbjrysf35SwExRXxFWk1TCSUS7ZyjSih9aBqoAmazPMVMJzRVyckKCdyaWhmZou3umfJtevO QXjo9QjmIDniHDgAbPEkEADHZsMoLinTUYrLu4uU0x/n8erIh2rKla/G+yFgtSQNSaQtcrSbkAXF Go8iWU6jQdfnTYYCRu4swAFM/BKHTsQ1VNNduYkReCzniqVc0hSLx0l7Uk7WUcVRVUEYn8ZVJSf4 phyxzBBgQICo8WnmXeYggtN0+04WCSRxsSKn5kZ/iG4UUOzp9juOUaU44Uxix8702bZ+TDvJ0iRW 8JLCSlPta8BoU5b6VLK52Z6qifaNtr6QNtYAczJP6A0bXWQxR3x85eykxpQjwMmXk2QuhUbczSoD ePvhte9ms1Bs/ldMHWOMQEp7A/tYlsAcIFrlzDfjeY4MPJeFTERzizyZeqqUd9YZC7Byzp2NivmU v+CunBprjNJPy6mxJi9L9dR8LbRAsxkW0JcMGtPMzwOVoYd/SEFJkrgTo/RTrvuCM6GtVtck6Wt6 mp4fW3Goc/tgUgw/10RyJOxkHoF94fQiVF6isn6rElkAqK/x1EvlnWhaKEJR3lBfyKK5Yos35Lpp qvvOWE0VQPfFItM6M26WI5r/UGWKyRcUSNIwkRi3sEdLjm5vC4PP0vzW7kILqUa4ztiRF9yMelTB q7ACeJ8GnyNnwEjxDAj2bw7IhgazmHNM1aF27iRp6tFbKEYOYK88pC6o6YTn7JpntwzoPVnO91Kh 4VlGzXXp3VJkCBNZLSdsAjPDiR/Djlp7MdPg8CiXpcEXfASz9JbzEvINzBFyjQKHksmUR1wwUwzL GaWBnj/qO4kphxSeepR4wUWltEE6DI2kVGyYF1mylA7OxoJHIa6QBDEtpN4ciBDRue5ENin/WWkg 0OIk1tzm9LS42ZisNHhOo5aIWau/kOk24Z7l7Dl8Jf9YimzOP5skb7mHB/0/KqfDA3Xw5G7/T0/H /+0dHHT3D+n+98E2/8vjPMv+H/LhDKPED4cjP0JJka3w+6ysWeXvKRVZd6PxA5VcOq8A4hca4JJv B1/ec2pPa6AX3hpcq7vXfjQHgeaLrDAkmSpUiu8zrDmf8UwEIE98sgxAEGGKKYZkKex57QpB5DEQ A4sW/CAgjwCM8WyEyRy9YNSZcWSwCj+GAXhsQd+3I2vZj0XBPTM+G8HskFuB3PaBr4IBjAPI9QB9 gy9eqxZm2Np31+9Xp5ssu3jY0qOFqqmm0wUuPaD7rvUDOZgdKzQfmn5WR1KhE5Quj8gnl7hFIbfe bUZQSj6zYhT0VU2UXMdEbj/HpV5dYlgvFrE2Myu+Wp/NnEwRI2Va6BWjg7hKPCONzUGJ2UyaNwNB tVN8ISt9ZK7AUH6x/uI1CIfh1nrU3JVZlVKUnAMK59WWRKF9VGkxy8qLArikdCzNRKFx0KtqdaPg iNXKhqWFq3WwB8m7WxLmnzItbNWUXC47d0A8pTwQY5DHms/QtYcBTySozJJzzDO19JRH3M4tiF9O +UlNllf+AahPbiCKVRw5ZpWKWwy1FViRbtZaKtR0notI/FhsDwRDrSW1CwRTPxZyJpWjSvII82pi NkxH5FpEC0YjhtA6e6yjmADNSZSMyJM7jwWs9iZ5IchdgEa/iAujo9CtBWKt6KCFh0I99mEgBAw4 WYTkN5vNo1ykRbDnMhOXfAIgBi6TwiFASJeZeHFbuIesrsWCKL8+N5JofMciKSV3taWLWV5X+arI SfXbHDKzEqO83he29P7qRV+uubDSi0VWSo5KiZJtQlJHH2QeWHexiCgkLS9am9WMSW0xmsTZv4BY DdDXSqcSmAnDti3XhX08ECjEl/ncwaMQ006h59h1zN1O3WS+6KCb+OgLpQSl2DemDEXPktlWnin1 kjKJauPVpvHVsk9FKlI1XQMDs3VjXaelFLSqnbQiM68lBzpZlHZsPZcIW0m/zPZnxQINQat0TnZT dN1jOwdTqhn6uU8wHBEWJBHKQPiOTgoLIyGHpnZJg4QXATnaLDZCH6b66tDNSVpcOPfIF5/xcB6H GHFOKICUzASXyxmp1dIq5vY/oKczipkuHVYU25PukWQnQlVJul0KUybyRcuhcNiRRWD8i247GJs6 2JUCrQQEo9aD6+fx6dD2liKpcp1DFnPQYqJ5XDh4wASyHOrEVYnsFxQ6GkUIems2QxvwBndbjSDz neM9FbCF1MSZVSoSnj8aHr2G8dA1gQhvsNoxVq0ma83oMqIhvlghPt3TYDJKDX6NF7q2Xn/bXAPF 4+Z/fKgcUBvf/+weHux1DzH/415nf3v/8zGe0vyb6xet9Da4xz7uyv/Swc86/wtwAN7/3T/Y5n94 lOf5//1r7W//2zmm+f4d/JP/An/+58mT8MmTtx4WnHn4auGPbMKfVSkJqvhJIqg/QsO/wxi3z+pn 1XzdZx93rf/2XlvHf3a7e5gLtrPfa2/zvz7KU9vRcf9MJ2Sjy05bveif5Smtf/zwADeA1q//bmdv z9H/aP33Drrb/I+P8lTcsGm5l+DXpFIw9Rbu6pRu97zR8dzqgkd1qUq5oF8Fb0RwpX4MJr2KFu4i qZTSTTB2q7NS3NcF5cUoW31Z+Y7bPatuMWP+aZbm06bODnGWxM6teX0FCX3CKoBBrDlMabnX5pm6 +/Sc2uEnsOz1L8npy/RAV7nYBBCBJkgvimdaCPJaqg0Yqw6QF/Sv0ghp3eAmRQX6qRbbareJjQss hcdhfgVyuiM1VNxSZXN8azozrnaoaMNr1GVtGMwRjswtVPfC4K9bmKnMGx+bo8N2t+PkKZiPniN5 0PuCZNe/HIdz95yShZd/kQnDbCyQEinSJBIB/jDSCQxz+QCB/Ctm7BaCjr0F+Lh4VCkAgoG9K7wj 7pBbCsJQh74OtUMGPSYKgfKVsfISbX379nT49vTiv07OLoevT85Ovjm9aDTXd6QzGkCHFE+exJv0 c3Z+Nrw4vTwZnN0FXoRD9RNZuE42HMLFcPDVXXAjMeYy9TfC9s3pxdvB28vTs8sGe28jrHfQ/xwn tHZu8Oet8LfUBN6XMLxTjs8EFtctMZsFNIJJpVXh+M3xonIm84L7kImR82a3OIiiImDdRSb4+LFt MMjFO4OfPjd3TRKQs6jjkEHfF6R+6CTEz9QS8utuLZKzVZhhzoclRHbqZld7Q+BMehTTtjI7zzIt doj2jRfuZFg87hI3tJeevXUkjgawWW4gMxF2ICTjNqGAHftmoyYh0ygJ36psHGuBlH5GQdNOhSWC AEQZGiUBRerZ4OiKsGrpuPLBhkmQL0ZgwmBsMv16KrzWBNdnweb8YYmJdHd1dwAGBfVrEK/UN680 OEUvSwwDVvJ8JVRnejBPhpWRM5N/yO17IT2P0wV6t/VdkpzXmSM98Bo2HVZLz+yMjaWkNSZIUk+4 ObrFWbyKWgjcoyQTBkKzntUbdqp4JPlHgPTYTz+zJv6xfI3/r9LUjA5lWURnOcJ0HpZV1dXsIt9H /UTXVjuiPvq3P8KqLnP8f3tXGhvHkZ2rZ3iOhiJlXZYlrybKZj10SMqSHW8sWbtRVt6IsFdSRHod U2aI0Rxkh0ePp3skcVdyI0sHMIIggJELMLIJ4JzICTg3sjkAZ38Ym8BJAAcwkAtGEsB/EuSHg03g hfO+V0dX93QPh6RsBwjbFtnsrq6u+urVe69ev3pv+oJxUSWK1V/2I5VDSVgZ8yKIDxuHVKolqN6Q 8YJyUccLifeVS8hhqGijl762YrGWol5djTyrWam2nArYX8Z0lbcYyO+iMZ0s6pzZjhFPOcs+sFO6 r4n4N9TthcCLuFTZgKGCiW7Wr94j7fRKFbX2ajNeE/bBM7EaTXCidOLmCUNsoGh+qlTuRqjE2KKZ 3FCBQnodvfjeJkmwFouN7UKxb2RtBcvcARbb+BWPQaT7dS32uhJiUZWxtT/uwJwhjDuPjB003Q/1 PuvD/tTCmrvSEZo287g2X0rVNdKOTBA3fygF4O4P2bvuYgsQprDxXqilcy8c00sGuURkrgPxdB3s aw/NTzVj/vcWn0ZUvhjNX6MatZplbmZVndLbnth4yg63bh1OXDc9MUA0F1mqxNtq19AJgvWkCVGS uvErgU6szHz3l6YRQ2/MI2M728cEklu7BTUAUNFKtH4rAymQCwpdo/LzpSQNGQjtZ7dLQSnbyFKw SXOHytg5pjeMpUbOs/Qzs15W4s+I9xR2caJ59ux3+PgnA71lRktM52smtXhvgEQbZbpRCXt/mk7e wKJQj0E6N7GZhQvSnGLf1nKyUtLGxuMuXa0bZmLFac6dl7HC4lC3bvTa0WhjTbcx77mnRi21/VCT jTfU684bet9aw6V0kQGVrfCZpok6/sO5NI5jWK0qhZmqgy+cyxKt6pHqKhRV/eCp+Sn4t1ZIczth 9uR3RHLnwyxRFamS2ie9acpqWrTGjUKlIvagj+iEJHkEi6S360IIA7hOk3W1zG0ySyRcb1Zurt3g IFFXFi5dfub89OwEClE/J2KFk7HndLdOW4H+SrEkeafGYwQMV1cZFsr1AVK5E1FaG5Wu0zxfjpZQ PTxhrc8lGBfcGvsXApOpqSnLFGEHHp29ev7SzPQTl1TE0V4oqdmqu2s3vGW9DPKwspABRSOKD9ab ksCY00Afdmsq6uGJs2eNOaE3qovH6lMoppAiTE8dV4kWvbUFXn+CTye4hIxzas8N+Wpr1GRcq5SK U+LSWl3WNcRDCpc4GmOLQy7KqJduUNhKa/BsgtHtrH1pTcwmEsM1+XbCUPZ5r3Wz0qpdldbcMres N/nR9LDtMoOoaAp63rLLAUrZNBGtRpUde62OSF3wA5VxfTWxywDOO/0AYxp71ypKftHZ5FuO4i29 vd4sdOMffGTS0NjyTIeP499dhyn9DV3NIZYlJMtcITfc9Wq06HhQxgmXxi9D4N3JLb0fGaYOWweL mpptf9jWm+1o2L2q15rrZ4hu2dZN1kypgnw15ipuVRYtJSNc7Gq30fX2Wi9dd2tb7SWNxA6Ulc4+ b71ncNXvvjDo3EbRbbmw2VrBMujriWEWDB/lcqKntcT/ZV5sDOoprgBTM1L0qDIS/BMnTpxH+JNK M6izIbMhBSBLIbN/MPlNXvI4enbHPJ3lI+eH7iEWucojjV/bePFWrKZbq7onddJ+C3/Hjp6KPVDq au/KaEBC90B9qI4UD6V3JNWOztZEVWQ/veu/1uuR5v91N32/cWzi//Xoww+dSvj/P/Lp3fy/H83B /t+3v0v6f+fpn//Pgv2/wxxcwJeJQhwxlxNhnv/MC7dPzPWLsI//HBBzAyLs5/NBMTcowgE+HxJz QyIc5PNhMVcQ4RCf7xFze/ikKOaKfDIi5kb4ZK+Y2yvCYVFzUGxlVMyNCiekezlRzwl3TDQcUcuL F4XYEOLZuX0ifEPU+vjePXyv39zbL8L3RG1A1IeEe4DvDZp7B6Vj+5CAYzv7u/fRD3w39UfpJCFA GJUc/ed/HaiMiECIOUeEe/FeaumLhE1ehBfRSjSO/uwT4WU0jF4InJ5WDQNOz6JROCecFlSjgNOq qA3x+bAI26I2zOeE2QuiVuDzPSJ8SdT28HlRhC+LWpHPR0T4iqiN8DmB96qo7eXzURG+JmqjfD4m wtdFbYzP94mrM+V96Hq1TwyIfhpw/68IBOpPSM8cFLdz4rYQC3TlkLjt8DkN/WGcu3l0eENepE4e wwkRg9svggHhDqpbuDLEV4atKwW+sse6UuQrI7iy2CfuEFJlcTsvgjHxQ0PCe5aG/sGUop3VLebE HWrNw3wrx63M4fodGpZHUCNRBw28ux8/nTWHKn5UV3MAY6bOudTtfrHBVxYOivC78TTOCZnHYsVU ZeE5ERxSN+jnhsTusAg/yxcPCvdePjks3CN4YAMv/14R3Cfco3yDL3lTdPVzIjgm3PtF8Al1gwho g/vxnKz1OP8sibVjVPoJsSTwfyOXvE20NlMeAFV/i35szbUQArcXf0KU28SJsFDaouegZZbp2V0w eibNR7DA+1iUE58PdSDysPEx+7XQ440prUvlbwNqYIDUN+YJUDn4AkHh34dCme47/C7lFeKX6Hwz Xzt/LxWKq77+frqU4mbnH4/qy3Kp4/5FrnP+0eiRNFcsbq7ytPIPRWUT7mFca+T9JcHxVtTvCoOE 4ZAc1Fs5zV1I8fhhvPV4c62RL5K/xxoL/be1QuC2KocYrj/Fbcbvx3tBXREzxySQjjCyvcsrfA/O LXwCnwFul17W8h/aKCrnUAcVaPKwEeCOK2is/VH4uen+KKVv8av1emOv8E9AFDv5gaJTdA72f39x LDc5fNA5nHsgV3QO9d2bO5Y/5Ezl/BELOSmtIKnyYOrYnUVSKZwW4ZOakdOVpyIuKS8Sj3GIq8+U c2jzRfqxfU+auP/MpTKjh3rdWhxJIHfYooikJSoXw17WsBNk9XsuCqYKQpZwrBIzZrR4vpLIDq+I 8Crj4wAinOTBgGcifH6QSXOHPjldPXEUah1wjTIIMWuYBsaxH9guTMPM3lTNl2V9wIlRcoAStAZS ZsIvKohmrP2BubQ2352GFTEzrAXx05Kk8hg/ReugWlKtwjkoZ5K+oaiQXkCK2jURsIqC6wP8cxBi 8zYXcMLnWLMZYnHOHULll1gk3CwP6w4wr4j3j5gACjVizAVmrGyewlxKOhbFAeOKtguQfu+zmrgP Osedaj/pdn0A50mAsyDCGsChYaPuhg0+Z00+XBSLgnWeHGs7faLBugwpb1Ty8XCZ/yhE+MgB36Nl pduoSlEW8y7iUbNtlrqMZQnkhsMayGws5sRjXVEeOlyh7X4TgReDW4NR7o8B3NGc7bxyuwM0ylMr 5vKzILjZ+f4iMaLjfVVJyDRaMxitVRF64taEmmc0DEeInI/QeF2g6/P7xR3SyJt8tx/Ddu75o+KZ 8Pmo+Lmwpcg9TtUud2AwhkwMvVSYYk4iTKpunKoN5vnumPOj2wUR3KfDc2pVsC6Rz90rhp19zohT zTPRE5BXAWRbhLc6UcTCYJ0XBgwfK+VfsopJHkF3Hg+/zJeT3EHiOLwjHFlxWCT0MGel94F+LCqV DnNfd5g7atGv2i700LlSvLjaiobzh50x5zCg75fidBbQvyDCH06BnhjOV8BkDPQYjA1cofE4F76o 8AZVhz+i+FAa+IW7Az64BHs5daLGzK12K2MMNmEvmbXtdCzuZV6S7jH2gpoNNCD3OAXMhj7RJ4XA gxiSl0T4Y5F6U+OBIaBJGB4Kfxz4k0CcsWQgCNx8hkjow0mdHe3K+r7RiQaetlyieA7IrxbpxN3T k9tE9B4q3Olh9pLSgPqO5Ig5KxQbQPFlEf4ERCYI9yfFrWmlcFygP+bPMmv+Ka1xMLwEqnecOMxP M8cZVMXpBs8JMB+YJJ4/Qiz8Z1BkJknqIEBWeVo3Mihe8mQuUmeSZq8tfyxBlXCSsthNAurU0lbN N7YL8B4G2HisvSx4VPO5YWeEuPYh59udCGHW5F4R4c9qhL8qbn2nQfirYv5+RvjnGMs+C8sNjeHP RxhKTaU/Cz4zqWUnNwMm5mt2V4ApSmCMh9srWppJZI4CF6XE5WGie1WEv2CxVPDSX1SkBs22D1P6 yMKgCH+J/yBUiJPWCMRfVoyU1DicsNUM2jEh+SuwMwUjihkf+r6L4a+KYK9wR41k/DVx6xKMcqiy n4G+QNfmH+Ph+XUR3ANjWE0V/g0RHIDdSzVG2gSL3hDfusKE/qM0SL+ZVsw7SqV+CwZSasVvc4lD 4P1fcQQe5CEdNNPC5cUFWJRxbGNKs7zSXFayoX0lvLPKhzukR4zD4w+2OugZllB0U5VYWV5eHJRc CY53xnIwFnEu41snK15t8e/qao1/0y0mLE/qBtKLjqc1u8Ep0sN7oajyDXZ+4zNekfJz0n+NEYo8 iuJiy/RVv15WbfV8J6Rte1a9KvxjIG3SFA7Rv6MkoMZyB4jI6VwUnfucIQirYam6wXAZvibC3+Gl maOMzs/lYSO+M8g6xO/q5dwgzYMBEf6eWJ8T4e+L2wOa7ovNfcKJ/pRqhHeASOwP1IrmNlOdNAj/ ofUkzQ+6dZvNr3eGxDNrtLL8I+E4TvjH8SfDr4n1kgj/pNuzR0T4p/zsn2GWuXsjgv4B/Av/XASj +LRxewhV0h0m8zzLXxDB2bNSCED9laRE8pRHEd59fCVYb8ZHkqgsg7htmrbpdYSJ2HLc6xhAJSaT Lm78PhL4Fu3FCC7NyolLCd+1uCqtu6lNHzwZmqZrus92Z2L9p/bsxApiPna/JtjomydyHXMGnE85 B5ySM5DDOf2GyjsgBqRtBACGr4vwL0T4dRGZi5jPpDvNqZhKKVbGzp6jkPy8zZ1Wts/t9rHAletP 6K8bU49TxhgrS6RMksllFxZkYHb609h7bXNl3LYbsyN1GG8iI0nKojh9jZe1/OiqCmdodUldpEME d9J9jCIS2CUjYm3ZKpD41jgi/E/Q1WFn9MzoYHGg2Ef/9haHisPFAv0bprOx4j5uQ/Rg9H3yi6DB N/T3yW/wx0nBH27ftD5OktB+S3+cJEb6tv442S/Cd/THSWKo7+qPk4P4YMjfStm2zAs8jAi9IPzL yLCctAX286BRnyL7X9zkZQrcDYv5N7RNMPZdJzKGn0eD3xThX1uW8L+JLOHQJI0xPPxbZVnZ0LbE hQG7ezwDk0btqLs9mLcTc0TpAB+a0ftNbRcsOkeSRu+3RPh30ZLQ1d9CN5xOFbpLXz9S2/Rbxv5r bD08vG+L8O8t4z0UZKL1f1B2TVaNicb/UReRtrHwn1CyY8k1mNHh7naGLOnaq+EmqUHuUAcbYdQs v8+3tcFmP8mzMScyOn4P8HtHhP+SwI9Yx7+KgFcX0iDGKA6J8N90wV6MMxnwFazu05zYibqdYYDM fsNOII250r6j5lZuP+m11X5SB3i59hgAfVeE/x4BCv+G/9Ash5c9kjDZ+vKfSmXMtr4MZUCatMPo Kbk1ewxq1z6ltklloBuevdZiPgdtE/S9PG62l++7CvX+UedITkLTTWvpVVnpmDCd453SmB0pAXFZ /oY0jQznin2jkP7DxcHkx3AVpJPE/QXQ2HtK3NekoP8vEX5Ty31ifu9D7itB/4FynYKgzzlKARiA cGfuDordtndtFVyEhQo8FagJ4X9bgvZ/tE9RzhajPFXtr+hmRQqqScxkuxzf3ibcNiV8Uyu+6ktw 9I3zfRF+6+P9xvm+kXHGgltCyz4QIS1qLR4techG3OIVn7Uas4Qmm77USPn4nFJom72MNeAD00Us ogbQxU+hizknzKd0ER8ISCXrj3V0KL2jcSV9i4uqj31BlnMUMFIL6cbYBvnPmldNMrmOZdeHtopJ sKf3pAlzFA4WfcV8MV+GcxFLo6zwgtzY2AWgjx1avM5IeYz7rc+1rhAZIDIcq1K2GXBFKtyg+Yyv TG/MgNb9yM6mzOvGveh+OukaDjBthcdIZD2VkAbckfhGiCTcZRSxup70nEpUmNagLGhSUDRQaGws SHi89FgYjCwsCdrt0hjHjSaJd4B+3+OMOkX13wPOWN+xrx2Dp9Pusf0DmF994vyFLzzx4b2ju/// qVMPP/pp6f//8GlO/PjQqdOPPLQb//0jOQqznLe3hh/Ek9w1nQWVndKQx0NmYeE8UYGH3HEn6cxr TNL/VSRhaQalB5GZ5cGpAue5brZbTeSRdVlvbLRbnNob+mPN9attlWp51VNJwcHKiX1NEgtQSaew UCkgvwlcD5XqyQzCa4JvylReTcWdSnF+aumopTJJiHHex+zK1DoFeDOrjCH0St7D7t6iDuOP+toN t+Wxm6zPiYTqcHXkIHL8KcckKafC1MsC50hBxhZqm++26rXxqUJhBplsOHPSSeTUYR9dmZyemrrq n/RWV10GwD9TKpzbwlE4NV5acYNgpX5yzSvVWy1q4FJlrQYPwsLpcd6lHyzBEbPkVxpIAXzJQwS6 Zbovk+ysSWduJJlZX6suUVfdL0nImi131aU1kfT09rxWzV2j9RH8q1VaXLhAtdeQPB7lr9eDm3XO M433IT/NTOUGZ+pucOYYmS3c9a1GTaJRJmv4w2gvDTah2mivlG5W5Bb9pXZQqhF0qIQ4P4aHVmnB SWmLpSuFR8Yjn/BqveN9RLyNhlt1CXdOILxeQjK1xbomIlmwWmn7MqsypyFGN+WNgHMU03hP0hul 33yNMEPPlJpAI1z4vIeEQrgoEx/6S4g/TDRQbblNxoeatVxf5zjq/pYGGeNsJ0ctTVqZmYIoSRXH /awHlcnqisvkWiioNKvdnpAwRqmnCwWZ95ee8duLi3VO4pxId1W/RUgzvVq1yYREREucORqDfJ3I wQoaEc9Nzv6thnkUCmp0J03joobBmgByggnej92nGYwhJVAxXznks9kpEL1ZerrLzFE84Gru33Ar GKpJmrp1Ws1zrEgdyGsF6YwqrcU2WmxtRHhaE0m0bwAhfpVeTZQAQwDGmHoS7V7gvpfMLbCPtmQ4 QNqTjsM4ldRRsBRcU8+VeDz+mttSyQ0RHpge9YP2dZ/ntFwLqADB3mqT6gTkgTcV1awVKVSvWLxv AhVbjFOlFdSAg/Pzdl3OB58WM0ZnikLdauxUbvEAYW35JXL3CHEAswlFD2ahwHO7Xl3yFBHyAGoE py88lUiLVmFmoIjlpKR8tUNF1ZUYkEq3YdDvVY/69aDdVCDJR6PpZc8j7oz8QCXzlUZN4gFJZlOM Hyrlooah3lJv10M1i9omEdy3kwLYq57aboa5gwpMVxS35JrsBpZrlTqJ3fEpGZcaWbiYg7XXViAA qM61ts4wCXwm/WB9pZ4y9iqc6pRMy1fjNO4kqtVmAd6arvb7SNTUNhhkv1XBrTvrjLnRk/CnOebL PGVr9ZsRRZpkm/xqfRmt9VMqhbcfksbKwLBmF4PdUDlqVa8NYsMGaclh1ExVFWhqlQQhsT1fRYeo atIKsglGVS+vqymG1qoxmeps83RQMvKJa2BTW4yr60+b8S1SNoKd1VYkzcc2J/A2KvMy84oJlbYt aLmLMLDrpnRWagLrRCTNIYPqkDAVUsG4+/6yfV/H9JWU0IUQIAjqdVsFUHwgIWs5Fd0SO29xU1v1 FFRnlRBiLqXTJoK7ydGPiwLuF+dJXLfopbNSENCZUimiimulx6ksLn8G8cARz52TSioxTe9rr9Zj uSavg7m1kSkPxNklQPS4LKE8hwonpk3sF7Tc/Kki42qQT0ejCjb+DKCaJiWLdZcVUrz8aAC1YDbT xMf8iMnMRddrngmqzTNnHocI/oyRm3KgazXF8wGkXyAUV9e1sj1VbSyy0DtDGgB17ypHUtLNPlf1 WqR1eNUzZ7DXawW8Sb3DcMeUx7i3vTwrUzsXmApueq1lX2W5DSIRJmnKThepuAurPkrsS4HjWksX qRkQg5iVMkay3AlgzBqm1hbPFCaJ0YKjS8FBa04WTcj4yMnlJ0rTDxC9VGUMbGonuP4np79w9erl y7MTMkcpjd4nv6wu3YG5hJj4CifW7ugIve48jUeiOIYpfukkSwjq1rrXbpWuPDt78fKlK+dnL9Lz 1WTZszI16iR3VKtxXemjTNohTRHuDz3k631jRJ91LPbWauOqodwBNcArMlX6dU8uSbhles1GKkzD XWy3pNLCEFINJAJ5ssZkud6+usTZJ5tg79iwCu4cF5SqURJ68M6EE4rqMcqkgBe9sIzl8PgmpSNu Ueb0nGxTGydmofbHciTziVLUOu1C5N0Et6CqkeUTynCt5qr1JUOrpIupv6Ao2jwfaI5OcLXq1hvM kmACugCydBLkyFi+QoupYL20jL21hah8WcoHfmuFpTorFhpHCFs1uNTMJ125zQ2kR/xNOWgWOmee qhWsC33NIBc7nQZWkTTDK8SbPVutQqWySfT+yw1I95ZPE8xt6FeqxakCc8Ji4dhHXGhU3BU2XrjI TqvrpEk+3WBoGBBzfUIKUlVZfBBKlUXsulaN9jn/KhtcpL4BM0edp98p3VeYG9YtxWPWayKHKWCJ 7CfgJp/zWpCgNFX8k9AKV7ApGINHhKCXgwDdXlHSY1esBTRJE1IjFteNvICUnyxdIF3GXTEUpfXb dgCVENLCZCmfQqZWmjec1hXuWEGU6XWl0l6rLoFWC3KtQMS3FGC1f9IYb/TSn2s1dKRrOFl6hgYA 7HhGrho+S417yltc5DEz9gMYDmA3mEjYRSZK0mBz3SMu0ZpsrvDWdE7TsRseZvfYPXaP3WP32D12 j91j99g9do/dY/fYPXaP3WP3+P9x/C+228kqAPAAAA== --NextPart_Webmail_9m3u9jl4l_16169_1043705427-- From duncan@grisby.org Tue Jan 28 12:48:46 2003 Received: from grisby.dyndns.org (pc2-cmbg4-5-cust211.cmbg.cable.ntl.com [81.96.73.211]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0SCmk801126 for ; Tue, 28 Jan 2003 12:48:46 GMT Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id h0SCmQj16097 for ; Tue, 28 Jan 2003 12:48:27 GMT Message-Id: <200301281248.h0SCmQj16097@grisby.dyndns.org> X-Authentication-Warning: pc2-cmbg4-5-cust211.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] ImR idl proposal In-Reply-To: Message from kendall bailey of "Wed, 22 Jan 2003 15:33:06 CST." <3E2F0E12.8010806@drakealumni.net> From: Duncan Grisby Date: Tue, 28 Jan 2003 12:48:26 +0000 Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: On Wednesday 22 January, kendall bailey wrote: > Possibly. It's too early to worry much about that. I suppose I'm > hoping that this become a standard part of the omniORB family. Still > free to work with other orbs, but an official omni* sub-project like > omniNotify. We'll see. I think it would be good for there to be an omniImR that is part of the omniORB suite, so I'm happy to go with that name. > I wasn't too thrilled with the term "program" either. I couldn't use > "adapter" as H&V does. However, there should be some logical grouping > of objects so that a bunch can be migrated all at once. The ImR could > be told that program X is now hosted in process Y rather than Z, and the > thousands of objects that once would have auto-started process Z now > will start process Y. The ImR will not store the identity of those > thousands of objects. Rather it knows only the "program" aka "adapter" > in H&V lingo. With a portable ImR there is no need to make all those > objects share a POA though. I haven't completely followed the discussion up to here, so this idea might be irrelevant, but I've been imagining a scheme where object identifiers are slash separated strings, like foo/bar/baz/wibble. The ImR keeps a mapping from partial names to programs (that are running or it can start). For example, the ImR might know that all names starting foo/bar are serviced by program A. When a request for foo/bar/baz/wibble comes in, it kicks A into action, and asks it for object baz/wibble. Later, the ImR might be reconfigured so that a single program supports all objects under name foo, meaning that now the program would be asked for bar/baz/wibble. I think this kind of scheme would avoid having to come up with names for the different kinds of entities. You just have simple strings, part of which are interpreted by the ImR, the other part by the programs it controls. Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From krbailey6@mchsi.com Tue Jan 28 16:07:33 2003 Received: from sccmmhc02.mchsi.com (sccmmhc02.mchsi.com [204.127.203.184]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0SG7X811029 for ; Tue, 28 Jan 2003 16:07:33 GMT Received: from sccqwbc03 ([204.127.203.163]) by sccmmhc02.mchsi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20030128160730.FOAR5896.sccmmhc02.mchsi.com@sccqwbc03> for ; Tue, 28 Jan 2003 16:07:30 +0000 Received: from [12.216.165.141] by sccqwbc03; Tue, 28 Jan 2003 16:07:30 +0000 From: krbailey6@mchsi.com To: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] ImR idl proposal Date: Tue, 28 Jan 2003 16:07:30 +0000 X-Mailer: AT&T Message Center Version 1 (Nov 13 2002) X-Authenticated-Sender: a3JiYWlsZXk2QG1jaHNpLmNvbQ== Message-Id: <20030128160730.FOAR5896.sccmmhc02.mchsi.com@sccqwbc03> Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: I thought there would be some value to keeping part of the server identity out of the IOR's that the ImR generated. How would your scheme deal with migration of objects from one part of the tree to another? Say that all foo/bar objects need to move to the process B that also hosts abc/xyz objects? The IORs are already published, but now the IOR with foo/bar/baz/wibble really ought to be abc/xyz/baz/wibble in order to trigger startup of process B. This is why I thought a process name could be associated with one or more (possibly related in a hierarchy) subsystem names (I've dubbed them 'programs' so far). The IORs would carry only the subsystem names and object names, and the ImR would look up the current host process name. Your scheme could combine the subsytem/object name pair into a single structured string as you've described, but not eliminate the need for process names. If that's what you meant, then I can agree with that. My motivation for splitting subsystem names from object names was to avoid imposing any structure on the names' formats. If there is to be hierarchical structure, is it advisable to use delimiter characters as you suggest, or should we use a structured type similar to the way CosNaming does with NameComponent sequences?? I find myself always using the string representation of CosNaming::NameComponent sequences anyway, so structured strings are fine with me. In any case, I think the server process should see the whole identifier, and not just the trailing portion. The initial portions may correspond to POA names that the ProcessManager can use to traverse the POA hierarchy. Kendall > I haven't completely followed the discussion up to here, so this idea > might be irrelevant, but I've been imagining a scheme where object > identifiers are slash separated strings, like foo/bar/baz/wibble. The > ImR keeps a mapping from partial names to programs (that are running > or it can start). For example, the ImR might know that all names > starting foo/bar are serviced by program A. When a request for > foo/bar/baz/wibble comes in, it kicks A into action, and asks it for > object baz/wibble. Later, the ImR might be reconfigured so that a > single program supports all objects under name foo, meaning that now > the program would be asked for bar/baz/wibble. > > I think this kind of scheme would avoid having to come up with names > for the different kinds of entities. You just have simple strings, > part of which are interpreted by the ImR, the other part by the > programs it controls. > > Cheers, > > Duncan. From duncan@grisby.org Tue Jan 28 17:34:37 2003 Received: from grisby.dyndns.org (pc2-cmbg4-5-cust211.cmbg.cable.ntl.com [81.96.73.211]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0SHYa815386 for ; Tue, 28 Jan 2003 17:34:36 GMT Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id h0SHYEr25206; Tue, 28 Jan 2003 17:34:15 GMT Message-Id: <200301281734.h0SHYEr25206@grisby.dyndns.org> X-Authentication-Warning: pc2-cmbg4-5-cust211.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: krbailey6@mchsi.com cc: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] ImR idl proposal In-Reply-To: Message from krbailey6@mchsi.com of "Tue, 28 Jan 2003 16:07:30 GMT." <20030128160730.FOAR5896.sccmmhc02.mchsi.com@sccqwbc03> From: Duncan Grisby Date: Tue, 28 Jan 2003 17:34:14 +0000 Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: On Tuesday 28 January, krbailey6@mchsi.com wrote: > I thought there would be some value to keeping part of the server > identity out of the IOR's that the ImR generated. How would your > scheme deal with migration of objects from one part of the tree to > another? Say that all foo/bar objects need to move to the process B > that also hosts abc/xyz objects? The IORs are already published, > but now the IOR with foo/bar/baz/wibble really ought to be > abc/xyz/baz/wibble in order to trigger startup of process B. That could be handled by just putting more than one entry for process B in the ImR, one for abc/xyz and one for foo/bar. > Your scheme could combine the subsytem/object name pair into a > single structured string as you've described, but not eliminate the > need for process names. If that's what you meant, then I can agree > with that. That's what I meant. > My motivation for splitting subsystem names from object > names was to avoid imposing any structure on the names' formats. I'm torn between whether that's a good idea or not. On the one hand, imposing structure on the names limits the things that programs can do with them; on the other hand, imposing structure makes everything easier to use, and opens the possibility for changing the level in the hierarchy at which the programs live. I'm not sure it will make much difference in the long run either way. > If there is to be hierarchical structure, is it advisable to use > delimiter characters as you suggest, or should we use a structured > type similar to the way CosNaming does with NameComponent > sequences?? I find myself always using the string representation of > CosNaming::NameComponent sequences anyway, so structured strings are > fine with me. I think the experience of NameComponents shows that using a sequence is a real pain to program, especially for C++. I think flat strings are much easier for everyone to deal with. Again, it's not a big deal either way. > In any case, I think the server process should see the whole > identifier, and not just the trailing portion. The initial portions > may correspond to POA names that the ProcessManager can use to > traverse the POA hierarchy. I think it would be sensible to give the process both the full name, and the bit that the ImR hasn't resolved. I can see situations where either would be useful. Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From lockhart@fourpalms.org Thu Jan 30 00:36:56 2003 Received: from myst.fourpalms.org (dhcp-78-180-241.jpl.nasa.gov [137.78.180.241]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0U0at807567; Thu, 30 Jan 2003 00:36:55 GMT Received: from fourpalms.org (localhost.localdomain [127.0.0.1]) by myst.fourpalms.org (Postfix) with ESMTP id 88B24346073A; Wed, 29 Jan 2003 19:36:56 -0500 (EST) Message-ID: <3E3873A8.9070600@fourpalms.org> Date: Wed, 29 Jan 2003 16:36:56 -0800 From: Thomas Lockhart Organization: Yes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Waller Cc: omniorb-list@omniorb-support.com, omniORB development list References: <20030129235636.69782.qmail@web13006.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [omniORB-dev] Re: [omniORB] Implementation Repository Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: > I'm very interested in joining this discussion as I > have been working on an Implementation Repository for > omniORB for almost 3 months now... Welcome. But the discussion has moved to omniorb-dev so you should subscribe to that; check the archives for the last couple of weeks for details. > I will send some IDL in my next posting; is it okay to > attach files to mailing list posts? Sure; IDL is not very big. - Tom From jwaller6@yahoo.co.uk Thu Jan 30 01:39:11 2003 Received: from web13001.mail.yahoo.com (web13001.mail.yahoo.com [216.136.174.11]) by raq2100.uk2net.com (8.10.2/8.10.2) with SMTP id h0U1dA810598 for ; Thu, 30 Jan 2003 01:39:10 GMT Message-ID: <20030130013914.51987.qmail@web13001.mail.yahoo.com> Received: from [69.4.163.56] by web13001.mail.yahoo.com via HTTP; Thu, 30 Jan 2003 01:39:14 GMT Date: Thu, 30 Jan 2003 01:39:14 +0000 (GMT) From: =?iso-8859-1?q?James=20Waller?= To: omniorb-dev@omniorb-support.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [omniORB-dev] Implementation Repository Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: Originally posted to the other mailing list by mistake... Will be posting some extra stuff soon; looks like there's been a lot of progress here lately, and I'm coming in a little bit late. I am hoping the work I've done may be of some help! --- James Waller wrote: > Date: Wed, 29 Jan 2003 23:56:36 +0000 (GMT) > From: James Waller > Subject: Implementation Repository > To: omniorb-list@omniorb-support.com > > Hello, > > First I'd like to apologise for waiting until now > before posting anything on this subject. I was > unable > to discover the recent interest on this topic until > now because I've been without an internet connection > for the first half of this month! > > I'm very interested in joining this discussion as I > have been working on an Implementation Repository > for > omniORB for almost 3 months now. It is nearly at the > point where it is usable; a working ImR daemon and > server interface library are just around the corner > (about two or three weeks before I have some code to > demonstrate). I intend to add an administration tool > as well. It only compiles on Linux at present and > its > makefiles are independent of the autoconf system. > > This ImR works in a very similar way to the one > described in the Henning paper and the "Advanced > CORBA > Programming with C++" book. Server programs are > registered with the ImR by name, then one or more > POAs > are registered with the ImR for each server. Any > object references created in those POAs at the > server > are translated to references to the ImR. Each server > has configurable parameters such as command-line > arguments, activation mode, user, group and so on; > calls are present in the ImR interface for accessing > this information. > > When a server starts up, it makes a call to the ImR > to > notify the ImR of its availability. A "manager" > object > is created in the ImR for each server with a > corresponding proxy object in the server itself, > provided by the server interface library. The > manager > object is responsible for sending "ping" requests to > the server (to check if it is still alive at certain > points) and sending instructions telling servers to > terminate themselves in an orderly fashion. The > corresponding proxy object receives these requests > and > deals with them in the appropriate way. > > I will send some IDL in my next posting; is it okay > to > attach files to mailing list posts? > > Cheers, > James Waller > > __________________________________________________ > Do You Yahoo!? > Everything you'll ever need on one web page > from News and Sport to Email and Music Charts > http://uk.my.yahoo.com > __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com From jwaller6@yahoo.co.uk Thu Jan 30 17:07:17 2003 Received: from web13007.mail.yahoo.com (web13007.mail.yahoo.com [216.136.174.17]) by raq2100.uk2net.com (8.10.2/8.10.2) with SMTP id h0UH7H823352 for ; Thu, 30 Jan 2003 17:07:17 GMT Message-ID: <20030130170719.86253.qmail@web13007.mail.yahoo.com> Received: from [69.4.163.56] by web13007.mail.yahoo.com via HTTP; Thu, 30 Jan 2003 17:07:19 GMT Date: Thu, 30 Jan 2003 17:07:19 +0000 (GMT) From: =?iso-8859-1?q?James=20Waller?= Subject: Re: [omniORB-dev] Implementation Repository To: omniorb-dev@omniorb-support.com In-Reply-To: <20030130013914.51987.qmail@web13001.mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-237453258-1043946439=:79013" Content-Transfer-Encoding: 8bit Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: --0-237453258-1043946439=:79013 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Id: Content-Disposition: inline Judging from what I've been reading so far, there is one major difference between the design I have worked on and the one being agreed here. That is, my ImR works on the premise that you don't register each and every object with the ImR, instead you register the POAs that contain the objects (as described in the Henning paper). My rationale for taking this approach is that if a server contains tens, hundreds or even more objects, the system can handle them in a more scalable fashion as there are fewer calls to the ImR. The disadvantage, of course, is that your servers (or more specifically, the library you link with your servers) has to mess around with object keys and is hence not portable between ORBs. Originally I felt that the advantages of that approach outweighed the disadvantages. With hindsight, the other approach would have made my ImR *much* simpler (there's quite a bit of code in there for manipulating object references, POAs and so on). Maybe the ImR could make both methods available, the register-every-object way for portable servers and the register-every-POA way for more scalable (but non-portable) servers. Comments anyone? I have attached the IDL for the Implementation Repository I have been working on. Basically the Repository interface contains the general administrative interface, and the Server interface is implemented by both the manager objects in the ImR and the proxy objects in the servers. Cheers, James [original message snipped] __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com --0-237453258-1043946439=:79013 Content-Type: application/octet-stream; name="omniImR.idl" Content-Transfer-Encoding: base64 Content-Description: omniImR.idl Content-Disposition: attachment; filename="omniImR.idl" bW9kdWxlIG9tbmlJbVIKewogICAgZXhjZXB0aW9uIEV4ZWNGYWlsdXJlCiAg ICB7CiAgICAgICAgc3RyaW5nIHdoYXQ7CiAgICB9OwoKICAgIGV4Y2VwdGlv biBCYWRQYXJhbQogICAgewogICAgICAgIHN0cmluZyB3aGF0OwogICAgfTsK CiAgICB0eXBlZGVmIHNlcXVlbmNlPHN0cmluZz4gU3RyaW5nU2VxOwoKICAg IHN0cnVjdCBTZXJ2ZXJEZXNjCiAgICB7CiAgICAgICAgc3RyaW5nIG5hbWU7 CiAgICAgICAgYm9vbGVhbiBhY3RpdmU7CiAgICAgICAgU3RyaW5nU2VxIHBv YV9uYW1lczsKICAgICAgICBTdHJpbmdTZXEgY21kbGluZTsKICAgICAgICBT dHJpbmdTZXEgcGFyYW1zOwogICAgfTsKCiAgICB0eXBlZGVmIHNlcXVlbmNl PFNlcnZlckRlc2M+IFNlcnZlckRlc2NTZXE7CgogICAgaW50ZXJmYWNlIFNl cnZlcgogICAgewogICAgICAgIG9uZXdheSB2b2lkIHBpbmcoKTsKICAgICAg ICBvbmV3YXkgdm9pZCBkZWFjdGl2YXRlTm90aWZ5KCk7CiAgICB9OwoKICAg IGludGVyZmFjZSBSZXBvc2l0b3J5CiAgICB7CiAgICAgICAgZW51bSBTdGF0 dXMKICAgICAgICB7CiAgICAgICAgICAgIFNVQ0NFU1MsCiAgICAgICAgICAg IFNWUl9OT1RfUkVHLAogICAgICAgICAgICBTVlJfUkVHLAogICAgICAgICAg ICBQT0FfTk9UX1JFRywKICAgICAgICAgICAgUE9BX1JFRywKICAgICAgICAg ICAgU1ZSX0FDVElWQVRJTkcsCiAgICAgICAgICAgIFNWUl9BQ1RJVkUsCiAg ICAgICAgICAgIFNWUl9JTkFDVElWRSwKICAgICAgICAgICAgVElNRU9VVCwK ICAgICAgICAgICAgSU5URVJOQUxfRVJST1IKICAgICAgICB9OwoKICAgICAg ICBTdGF0dXMgcmVnaXN0ZXJQT0EoaW4gc3RyaW5nIHN2cl9uYW1lLCBpbiBz dHJpbmcgcG9hX25hbWUpOwogICAgICAgIFN0YXR1cyBkZXJlZ2lzdGVyUE9B KGluIHN0cmluZyBwb2FfbmFtZSk7CgogICAgICAgIFN0YXR1cyByZWdpc3Rl clNlcnZlcihpbiBzdHJpbmcgc3ZyX25hbWUsCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGluIFN0cmluZ1NlcSBjbWRsaW5lLCBpbiBTdHJpbmdT ZXEgcGFyYW1zKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICByYWlz ZXMoQmFkUGFyYW0pOwoKICAgICAgICBTdGF0dXMgZGVyZWdpc3RlclNlcnZl cihpbiBzdHJpbmcgc3ZyX25hbWUpOwoKICAgICAgICBTdGF0dXMgc2VydmVy UmVhZHkoaW4gc3RyaW5nIHN2cl9uYW1lLCBpbiBTZXJ2ZXIgcmVtb3RlX3N2 ciwKICAgICAgICAgICAgICAgICAgICAgICAgICAgb3V0IFNlcnZlciBzdnJf cHJveHkpOwoKICAgICAgICBTdGF0dXMgbW9kaWZ5U2VydmVyQ29tbWFuZChp biBzdHJpbmcgc3ZyX25hbWUsIGluIFN0cmluZ1NlcSBjbWRsaW5lKTsKICAg ICAgICBTdGF0dXMgbW9kaWZ5U2VydmVyUGFyYW1zKGluIHN0cmluZyBzdnJf bmFtZSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGluIFN0 cmluZ1NlcSBwYXJhbXMpIHJhaXNlcyhCYWRQYXJhbSk7CgogICAgICAgIFNl cnZlckRlc2NTZXEgZ2V0U2VydmVycygpOwoKICAgICAgICBTdGF0dXMgYWN0 aXZhdGVTZXJ2ZXIoaW4gc3RyaW5nIHN2cl9uYW1lKSByYWlzZXMoRXhlY0Zh aWx1cmUpOwogICAgICAgIFN0YXR1cyBkZWFjdGl2YXRlU2VydmVyKGluIHN0 cmluZyBzdnJfbmFtZSk7CiAgICB9Owp9Owo= --0-237453258-1043946439=:79013-- From kendall@drakealumni.net Thu Jan 30 18:36:45 2003 Received: from sccmmhc02.mchsi.com (sccmmhc02.mchsi.com [204.127.203.184]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0UIac827609 for ; Thu, 30 Jan 2003 18:36:45 GMT Received: from drakealumni.net ([12.216.164.190]) by sccmmhc02.mchsi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20030130183635.FIAE5896.sccmmhc02.mchsi.com@drakealumni.net>; Thu, 30 Jan 2003 18:36:35 +0000 Message-ID: <3E397027.5010609@drakealumni.net> Date: Thu, 30 Jan 2003 12:34:16 -0600 From: kendall bailey User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Waller CC: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] Implementation Repository References: <20030130170719.86253.qmail@web13007.mail.yahoo.com> In-Reply-To: <20030130170719.86253.qmail@web13007.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: James Waller wrote: >Judging from what I've been reading so far, there is >one major difference between the design I have worked >on and the one being agreed here. That is, my ImR >works on the premise that you don't register each and >every object with the ImR, instead you register the >POAs that contain the objects (as described in the >Henning paper). > > Not quite. Each IOR for a persistent object must be generated by the ImR, that much is true. But the ImR does not store per-object information. That would not scale well. Some load balancing ideas I'm working on in parallel with this ImR work would require the ImR to store object references for all *active* replica objects. I don't see any way around that. The ImR prototype and IDL I've posted has 2 ways to create a persistent reference. The generatePersistent is used to create a reference based solely on the info passed in. The ImR does not remember anything about the call. makePersistent must be called from a currently registered server process, but even then, the ImR does not add anything to it's persistent store when creating the indirect reference. All of the needed info is encoded into the indirect reference itself. The difference I see in your IDL is that you tie things to POA identities. That's perfect if the POAs themselves cooperate. If not, I see no reason to force the concept of a POA identity into the ImR. Its still a valid partitioning of the location domain, but perhaps not the only one. >Originally I felt that the advantages of that approach >outweighed the disadvantages. With hindsight, the >other approach would have made my ImR *much* simpler >(there's quite a bit of code in there for manipulating >object references, POAs and so on). Maybe the ImR >could make both methods available, the >register-every-object way for portable servers and the >register-every-POA way for more scalable (but >non-portable) servers. Comments anyone? > > Are you saying you've modified the POA itself? You may have to convince Duncan to merge your code if so. I like the portable approach, since I don't see the explicit creation of the persistent references to be much of a burden. Portable Helper libraries to ease the job of the server processes should be part of the ImR project. Are you planning to release your ImR under an open license? I'd be interested in seeing the code. Kendall From jwaller6@yahoo.co.uk Thu Jan 30 19:22:34 2003 Received: from web13001.mail.yahoo.com (web13001.mail.yahoo.com [216.136.174.11]) by raq2100.uk2net.com (8.10.2/8.10.2) with SMTP id h0UJMX829812 for ; Thu, 30 Jan 2003 19:22:33 GMT Message-ID: <20030130192236.42392.qmail@web13001.mail.yahoo.com> Received: from [69.4.163.56] by web13001.mail.yahoo.com via HTTP; Thu, 30 Jan 2003 19:22:36 GMT Date: Thu, 30 Jan 2003 19:22:36 +0000 (GMT) From: =?iso-8859-1?q?James=20Waller?= Subject: Re: [omniORB-dev] Implementation Repository To: kendall bailey Cc: omniorb-dev@omniorb-support.com In-Reply-To: <3E397027.5010609@drakealumni.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: > Not quite. Each IOR for a persistent object must be > generated by the > ImR, that much is true. But the ImR does not store > per-object > information. That would not scale well. > [snip] Right, but I believe that even having to make a separate call to the ImR to get an IOR for every object (regardless of whether the ImR stores anything) will adversely affect scalability. If a server wants to publish a ton of object references, that's still a lot of calls to the ImR which makes it become more of a bottleneck. However, maybe a way to (at least partially) alleviate this would be to allow the server to get IORs en masse by making one call to the ImR with a whole load of object references. I haven't looked at your prototype yet, but I will as soon as I have time. This load-balancing idea sounds interesting. My ImR does not go into the realm of load-balancing as I tried to limit the initial scope of the thing. > Are you saying you've modified the POA itself? No. This ImR does not rely on any special modifications to omniORB itself. What happens is as follows: the ImR registers the fully-qualified name of each POA internally and creates an actual CORBA POA to match (if this isn't done, LocateRequest messages fail). It then uses an interceptor to catch incoming requests, get the POA names from their object keys, match them to a registered POA and redirect the call to the server under which that POA is registered. Of course, if the server/POA combination is registered, the ImR will reply with an OBJECT_NOT_EXIST exception. The server interface library works by using an encodeIOR interceptor to detect when an IOR is encoded for an object that belongs to one of the registered POAs. In this case the interceptor takes the IOR and replaces the address information with that of the ImR. Again this means analysing the object keys which makes the server library non-portable between ORBs, as does the use of the interceptor. But this takes place entirely within the server and does not involve the ImR at all. > Are you planning to release your ImR under an open > license? I'd be > interested in seeing the code. > Yes, absolutely. It's not usable yet, though. I need a little more time to complete some essential parts and do some further testing - probably a couple of weeks. By then it should consist of a feature-complete, alpha quality ImR daemon, server library and admin client program. I would like it if we can pool our ideas and that (at least some of) the work I've done could become part of an 'official' omniORB Implementation Repository. Cheers, James __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com From kendall@drakealumni.net Thu Jan 30 20:12:49 2003 Received: from sccmmhc01.mchsi.com (sccmmhc01.mchsi.com [204.127.203.183]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0UKCn832223 for ; Thu, 30 Jan 2003 20:12:49 GMT Received: from drakealumni.net ([12.216.164.190]) by sccmmhc01.mchsi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20030130201246.TBTI2338.sccmmhc01.mchsi.com@drakealumni.net>; Thu, 30 Jan 2003 20:12:46 +0000 Message-ID: <3E3986B3.9080105@drakealumni.net> Date: Thu, 30 Jan 2003 14:10:27 -0600 From: kendall bailey User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Waller CC: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] Implementation Repository References: <20030130192236.42392.qmail@web13001.mail.yahoo.com> In-Reply-To: <20030130192236.42392.qmail@web13001.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: James Waller wrote: >Right, but I believe that even having to make a >separate call to the ImR to get an IOR for every >object (regardless of whether the ImR stores anything) >will adversely affect scalability. If a server wants >to publish a ton of object references, that's still a >lot of calls to the ImR which makes it become more of >a bottleneck. However, maybe a way to (at least >partially) alleviate this would be to allow the server >to get IORs en masse by making one call to the ImR >with a whole load of object references. > > Each time a distinct client uses one of the indirect references, it hits the ImR first. I would think this would happen as much or more often than generation of the references in the first place, and so you may be avoiding a small percentage of the load the ImR will face. I just measured my prototype at 600 indirect reference creations/sec. That's on a 450 MHz pII running lots of other desktop stuff too. I like the batch request idea. If the result of a database request is to be returned as a bunch of indirect persistent references, then it makes a lot of sense for the ImR to handle them in one go. But hey, if the interceptor is already written to do the job, I won't argue. One of my goals is for the ImR to work with C++ and Python servers. Can the interceptor be installed in a Python server? Kendall From jwaller6@yahoo.co.uk Thu Jan 30 20:32:15 2003 Received: from web13006.mail.yahoo.com (web13006.mail.yahoo.com [216.136.174.16]) by raq2100.uk2net.com (8.10.2/8.10.2) with SMTP id h0UKWE800704 for ; Thu, 30 Jan 2003 20:32:14 GMT Message-ID: <20030130203217.43474.qmail@web13006.mail.yahoo.com> Received: from [69.4.163.56] by web13006.mail.yahoo.com via HTTP; Thu, 30 Jan 2003 20:32:17 GMT Date: Thu, 30 Jan 2003 20:32:17 +0000 (GMT) From: =?iso-8859-1?q?James=20Waller?= Subject: Re: [omniORB-dev] Implementation Repository To: kendall bailey Cc: omniorb-dev In-Reply-To: <3E3986B3.9080105@drakealumni.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: > Each time a distinct client uses one of the indirect > references, it hits > the ImR first. I would think this would happen as > much or more often > than generation of the references in the first > place, and so you may be > avoiding a small percentage of the load the ImR will > face. [snip] Well, I'm starting to come around to the idea; it imposes less restrictions from an ORB portability standpoint and it doesn't tie the ImR to the POA, i.e. it would work with old BOA-based servers. That's something I started to think about recently. Plus it would allow me to shave a whole lot of code off what I've got now! > But hey, if the interceptor is already written to do > the job, I won't > argue. One of my goals is for the ImR to work with > C++ and Python > servers. Can the interceptor be installed in a > Python server? > > Kendall > You got me there. My current implementation does not support Python, that would probably require a Python-based implementation of the server helper library. That's assuming the interceptor stuff is still available. I've dabbled a little bit with Python but I'm not familiar with omniORB's Python API. It's something that I intended to do later; I wanted to get something working with C++ to start with. By switching my design to require explicit publishing of IORs to the ImR, this would remove the need for the interceptor stuff from the server side hence trimming down the server helper library and making it easier to port to other languages. I need to do some serious thinking about all this. Cheers, James __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com From jwaller6@yahoo.co.uk Fri Jan 31 18:59:49 2003 Received: from web13006.mail.yahoo.com (web13006.mail.yahoo.com [216.136.174.16]) by raq2100.uk2net.com (8.10.2/8.10.2) with SMTP id h0VIxn800774 for ; Fri, 31 Jan 2003 18:59:49 GMT Message-ID: <20030131185951.34881.qmail@web13006.mail.yahoo.com> Received: from [69.4.163.56] by web13006.mail.yahoo.com via HTTP; Fri, 31 Jan 2003 18:59:51 GMT Date: Fri, 31 Jan 2003 18:59:51 +0000 (GMT) From: =?iso-8859-1?q?James=20Waller?= To: sveta@txcorp.com Cc: omniorb-dev In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [omniORB-dev] RE: [omniORB] Implementation Repository Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: > I have been using omiifr which works pretty well > with > omniORB. I think we might be talking about different things here. I believe omniifr is an Interface Repository (something I know nothing about :-), whereas this is about creating an Implementation Repository which is a completely different thing. > Is your implementation independent? Yes - at the moment it is built completely separately from the omniORB package, although it does depend on it. Cheers, James __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com From Christian.Perez@irisa.fr Thu Feb 20 17:16:32 2003 Received: from w3ext.irisa.fr (w3ext.irisa.fr [131.254.254.10]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h1KHGW832305 for ; Thu, 20 Feb 2003 17:16:32 GMT Received: from irisa.fr (parasolier.irisa.fr [131.254.12.48]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by w3ext.irisa.fr (Postfix) with ESMTP id BD27730450 for ; Thu, 20 Feb 2003 18:16:34 +0100 (MET) Message-ID: <3E550ED3.A06F27DE@irisa.fr> Date: Thu, 20 Feb 2003 18:22:27 +0100 From: Christian Perez X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18-19.7.x i686) X-Accept-Language: en, fr, es MIME-Version: 1.0 To: omniorb-dev@omniorb-support.com Content-Type: multipart/mixed; boundary="------------D90DEE9F698B8409A5F9EDCB" Subject: [omniORB-dev] Removing an entry from proxyObjectFactory Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. --------------D90DEE9F698B8409A5F9EDCB Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello, We would like to dynamically be able to load/unload code into a server. It appears to work fine except for the management of proxyObjectFactory. The proxyObjectFactory global variables in the IDL generated files correctly register themself thanks to their constructor. However, there is no destructor. When such a code is unloaded from the memory, the list of registered proxyObjectFactory is incorrect because it contains dangling pointers. A solution is to implement the destructor of proxyObjectFactory. Hence, proxyObjectFactory are going to be correctly removed. In attachement, you'll find such an implementation of proxyFactory.cc derived from omniORB3 (location src/lib/omniORB2/orbcore/proxyFactory.cc). This implementation is based on the used of the map of the C++ STL. As the proxyObjectFactory API is the same in omniORB4, the same modification should work. It would be very nice if such a patch can be applied to omniORB. Best regards, Christian Pérez -- Research scientist - PARIS Project - IRISA/INRIA http://www.irisa.fr/paris/ --------------D90DEE9F698B8409A5F9EDCB Content-Type: text/plain; charset=us-ascii; name="proxyFactory-fix.cc" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="proxyFactory-fix.cc" #include #ifdef HAS_pch #pragma hdrstop #endif #include #include typedef map ofl_t; // We used a pointer because we do not know how to control // the initialization of global variables. static ofl_t *_ofl; proxyObjectFactory::~proxyObjectFactory() { _ofl->erase(pd_repoId); } proxyObjectFactory::proxyObjectFactory(const char* repoId) { // The first time such an object is build, it has to // initialize the _ofl object. So, we are ablt to control // the order of initialization./ if (_ofl == 0) { _ofl = new ofl_t(); } OMNIORB_ASSERT(repoId); pd_repoId = CORBA::string_dup(repoId); // This code could be concurrently called with a lookup. // It should be protected with a mutex ofl_t::iterator it = _ofl->find(pd_repoId); if (it != _ofl->end() ) { it->second = this; if( omniORB::trace(15) ) omniORB::logf("Replaced proxyObjectFactory for %s.", repoId); } else { (*_ofl)[repoId] = this; } } void proxyObjectFactory::shutdown() { _ofl->clear(); } proxyObjectFactory* proxyObjectFactory::lookup(const char* repoId) { // This code has should be concurrently called with an constructor. // It should be protected with mutex OMNIORB_ASSERT(repoId); ofl_t::iterator it = _ofl->find(repoId); if ( it != _ofl->end() ) return it->second; else return 0; } --------------D90DEE9F698B8409A5F9EDCB-- From duncan@grisby.org Tue Feb 25 15:21:05 2003 Received: from grisby.dyndns.org (pc2-cmbg4-5-cust210.cmbg.cable.ntl.com [81.96.73.210]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h1PFL5819355 for ; Tue, 25 Feb 2003 15:21:05 GMT Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id h1PFKRi19787; Tue, 25 Feb 2003 15:20:28 GMT Message-Id: <200302251520.h1PFKRi19787@grisby.dyndns.org> X-Authentication-Warning: pc2-cmbg4-5-cust210.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: Christian Perez cc: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] Removing an entry from proxyObjectFactory In-Reply-To: Message from Christian Perez of "Thu, 20 Feb 2003 18:22:27 +0100." <3E550ED3.A06F27DE@irisa.fr> From: Duncan Grisby Date: Tue, 25 Feb 2003 15:20:26 +0000 Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: On Thursday 20 February, Christian Perez wrote: > The proxyObjectFactory global variables in the IDL generated files correctly > register themself thanks to their constructor. However, there is > no destructor. When such a code is unloaded from the memory, > the list of registered proxyObjectFactory is incorrect because it contains > dangling pointers. There are fundamental difficulties with unloading stubs, which is why it is not implemented. To unload stubs, it is essential that there are no object references from those stubs instantiated. There is a race condition, however, where a thread may be receiving an object reference that unexpectedly claims to be of a type supported in the stubs that are being unloaded. In that case, a new object reference could be created just as the stubs are being unloaded. If you can convince yourself that that situation will never arise in your application, it would be safe to unload stubs, and unregister their proxyObjectFactories. [...] > In attachement, you'll find such an implementation of proxyFactory.cc > derived from omniORB3 (location src/lib/omniORB2/orbcore/proxyFactory.cc). > This implementation is based on the used of the map of the C++ STL. There are two problems here. First, your suggestion is not thread safe. Second, it is not possible to use STL within omniORB, since it is not available everywhere. Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From Christian.Perez@irisa.fr Wed Feb 26 15:53:23 2003 Received: from w3ext.irisa.fr (w3ext.irisa.fr [131.254.254.10]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h1QFrN825254 for ; Wed, 26 Feb 2003 15:53:23 GMT Received: from irisa.fr (parasolier.irisa.fr [131.254.12.48]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by w3ext.irisa.fr (Postfix) with ESMTP id 016343046E for ; Wed, 26 Feb 2003 16:53:24 +0100 (MET) Message-ID: <3E5CE4A1.22AA9EA@irisa.fr> Date: Wed, 26 Feb 2003 17:00:33 +0100 From: Christian Perez X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18-19.7.x i686) X-Accept-Language: en, fr, es MIME-Version: 1.0 Cc: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] Removing an entry from proxyObjectFactory References: <200302251520.h1PFKRi19787@grisby.dyndns.org> Content-Type: multipart/mixed; boundary="------------30269C50EFB09E59EDDFEC71" Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. --------------30269C50EFB09E59EDDFEC71 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, Duncan Grisby wrote: > > On Thursday 20 February, Christian Perez wrote: > > If you can convince yourself that that situation will never arise in > your application, it would be safe to unload stubs, and unregister > their proxyObjectFactories. Good news ! > > In attachement, you'll find such an implementation of proxyFactory.cc > > derived from omniORB3 (location src/lib/omniORB2/orbcore/proxyFactory.cc). > > This implementation is based on the used of the map of the C++ STL. > > There are two problems here. First, your suggestion is not thread > safe. Second, it is not possible to use STL within omniORB, since it > is not available everywhere. The file was provided to illustrate the kind of modification I suggested. As it was stated in the file, it was not a thread-safe implementation nor a final implementation (it was derived from omniORB-3!) Taking into your comments (no STL), here is a modified version of proxyFactory.cc derived from omniORB-4. If you do not see any drawbacks, it would be very nice if it could be inserted it into omniORB-4. It has been successfully tested within a non trivial application. Best regards, Christian Pérez --------------30269C50EFB09E59EDDFEC71 Content-Type: text/plain; charset=us-ascii; name="proxyFactory-fix.cc" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="proxyFactory-fix.cc" // -*- Mode: C++; -*- // Package : omniORB // proxyFactory.cc Created on: 24/2/99 // Author : Sai Lai Lo (sll) // // Copyright (C) 1996, 1997 Olivetti & Oracle Research Laboratory // // This file is part of the omniORB library // // The omniORB library is free software; you can redistribute it and/or // modify it under the terms of the GNU Library General Public // License as published by the Free Software Foundation; either // version 2 of the License, or (at your option) any later version. // // This library is distributed in the hope that it will be useful, // but WITHOUT ANY WARRANTY; without even the implied warranty of // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU // Library General Public License for more details. // // You should have received a copy of the GNU Library General Public // License along with this library; if not, write to the Free // Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA // 02111-1307, USA // // // Description: // Implementation of proxyObjectFactory. // /* $Log: proxyFactory.cc,v $ Revision 1.2.2.5 2001/09/19 17:26:53 dpg1 Full clean-up after orb->destroy(). Revision 1.2.2.4 2001/04/18 18:18:05 sll Big checkin with the brand new internal APIs. Revision 1.2.2.3 2000/11/09 12:27:59 dpg1 Huge merge from omni3_develop, plus full long long from omni3_1_develop. Revision 1.2.2.2 2000/09/27 17:58:56 sll Changed include/omniORB3 to include/omniORB4 Revision 1.2.2.1 2000/07/17 10:35:58 sll Merged from omni3_develop the diff between omni3_0_0_pre3 and omni3_0_0. Revision 1.3 2000/07/13 15:25:55 dpg1 Merge from omni3_develop for 3.0 release. Revision 1.1.2.1 1999/09/22 14:27:05 djr Major rewrite of orbcore to support POA. */ #include #include OMNI_NAMESPACE_BEGIN(omni) static proxyObjectFactory** ofl = 0; static int ofl_size = 0; static int ofl_len = 0; static omni_mutex* ofl_mutex = 0; proxyObjectFactory::~proxyObjectFactory() { OMNIORB_ASSERT(pd_repoId); // Remove itself from the global list ofl_mutex->lock(); // Binary search to find the factory. int bottom = 0; int top = ofl_len; int pos = -1; while( bottom < top ) { int middle = (bottom + top) / 2; int cmp = strcmp(pd_repoId, ofl[middle]->pd_repoId); if( cmp < 0 ) top = middle; else if( cmp > 0 ) bottom = middle + 1; else { pos = middle; break; } } // sanity check if (pos == -1) { if( omniORB::trace(1) ) { omniORB::logger l; l << "Could not find proxyObjectFactory " << this->pd_repoId << " whitin its desctructor at " << __FILE__ << ": line " << __LINE__ << "\n"; } } else { // remove it by shifting all pointers // this is not the most efficient ;( ofl_len = ofl_len - 1; if (pos != ofl_len ) { // this is not the last : shift memcpy((void*)&ofl[pos], (void*)&ofl[pos+1], (ofl_len - pos) * sizeof(proxyObjectFactory*)); } } ofl_mutex->unlock(); } proxyObjectFactory::proxyObjectFactory(const char* repoId) : pd_repoId(repoId) { // These factories are constructed statically in the stubs, thus // there should be no possiblilty of concurrency. // This is not longer true as we try to support dynamic code loading and unloading OMNIORB_ASSERT(repoId); if( !ofl ) { ofl_size = 5; ofl = new proxyObjectFactory* [ofl_size]; ofl_len = 0; // We can not rely on the order of initialization of global object // This should be ok as there are some proxyObjectFactory created // during the loading of the omniORB library, which is assumed to be a sequential operaion ofl_mutex = new omni_mutex(); } ofl_mutex->lock(); if( ofl_len == ofl_size ) { int new_ofl_size = ofl_size * 2; proxyObjectFactory** new_ofl = new proxyObjectFactory* [new_ofl_size]; for( int i = 0; i < ofl_size; i++ ) new_ofl[i] = ofl[i]; delete[] ofl; ofl = new_ofl; ofl_size = new_ofl_size; } // Binary search to determine the insertion point. int bottom = 0; int top = ofl_len; while( bottom < top ) { int middle = (bottom + top) / 2; int cmp = strcmp(repoId, ofl[middle]->pd_repoId); if( cmp < 0 ) top = middle; else if( cmp > 0 ) bottom = middle + 1; else { ofl[middle] = this; if( omniORB::trace(15) ) omniORB::logf("Replaced proxyObjectFactory for %s.", repoId); ofl_mutex->unlock(); return; } } OMNIORB_ASSERT(top == bottom); for( int i = ofl_len; i > bottom; i-- ) ofl[i] = ofl[i - 1]; ofl[bottom] = this; ofl_len++; ofl_mutex->unlock(); } void proxyObjectFactory::shutdown() { ofl_mutex->lock(); ofl_size = 0; ofl_len = 0; delete[] ofl; ofl_mutex->unlock(); delete ofl_mutex; } proxyObjectFactory* proxyObjectFactory::lookup(const char* repoId) { // Factories should all be registered before the ORB is initialised, // so at this point the list is read-only. Concurrent accesses are // safe, except that the list is deleted when the ORB is shutdown. // There is a very small possibility that we will segfault below, // but that can only happen if the application is creating an object // reference at the same time as they are shutting down the ORB. OMNIORB_ASSERT(repoId); ofl_mutex->lock(); // Binary search to find the factory. int bottom = 0; int top = ofl_len; proxyObjectFactory* res = 0; while( bottom < top ) { int middle = (bottom + top) / 2; int cmp = strcmp(repoId, ofl[middle]->pd_repoId); if( cmp < 0 ) top = middle; else if( cmp > 0 ) bottom = middle + 1; else { res = ofl[middle]; break; } } ofl_mutex->unlock(); return res; } OMNI_NAMESPACE_END(omni) --------------30269C50EFB09E59EDDFEC71-- From jwaller6@yahoo.co.uk Wed Feb 26 17:30:30 2003 Received: from web13003.mail.yahoo.com (web13003.mail.yahoo.com [216.136.174.13]) by raq2100.uk2net.com (8.10.2/8.10.2) with SMTP id h1QHUT829945 for ; Wed, 26 Feb 2003 17:30:29 GMT Message-ID: <20030226173031.39567.qmail@web13003.mail.yahoo.com> Received: from [69.4.163.56] by web13003.mail.yahoo.com via HTTP; Wed, 26 Feb 2003 17:30:31 GMT Date: Wed, 26 Feb 2003 17:30:31 +0000 (GMT) From: =?iso-8859-1?q?James=20Waller?= To: omniorb-dev MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [omniORB-dev] Implementation Repository Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: Hello, I have now got a usable version of the Implementation Repository I've been working on, and I'll be posting it in the next couple of days after I finish some preliminary documentation explaining how to use it. In the meantime, I just noticed Duncan saying on the list that using STL is a no-no. This Implementation Repository uses the STL a lot internally (primarily std::vector, std::string, std::map, std::bitset and iostreams). For it to be included in the omniORB package, would this need to be changed? Cheers, James __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com From lockhart@fourpalms.org Wed Feb 26 19:14:23 2003 Received: from myst.fourpalms.org (myst.jpl.nasa.gov [137.78.15.105]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h1QJEM802444 for ; Wed, 26 Feb 2003 19:14:22 GMT Received: from fourpalms.org (localhost.localdomain [127.0.0.1]) by myst.fourpalms.org (Postfix) with ESMTP id D033D35398BA; Wed, 26 Feb 2003 14:14:24 -0500 (EST) Message-ID: <3E5D1210.2050701@fourpalms.org> Date: Wed, 26 Feb 2003 11:14:24 -0800 From: Thomas Lockhart Organization: Yes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Waller Cc: omniorb-dev Subject: Re: [omniORB-dev] Implementation Repository References: <20030226173031.39567.qmail@web13003.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: > I have now got a usable version of the Implementation > Repository I've been working on, and I'll be posting > it in the next couple of days after I finish some > preliminary documentation explaining how to use it. Great! > In the meantime, I just noticed Duncan saying on the > list that using STL is a no-no. This Implementation > Repository uses the STL a lot internally (primarily > std::vector, std::string, std::map, std::bitset and > iostreams). For it to be included in the omniORB > package, would this need to be changed? I'll make the suggestion that the code should be in omniORB in either case (with or without STL). Folks can then contribute to adapting it to be STL-free if that is a requirement for their platform, and autoconf can be used to enable/disable it on specific platforms in the meantime. STL *is* settling down a bit and perhaps it is less of an issue but we wouldn't know until it gets a bit of exposure in the omniORB package. I recall mico having a "mini-STL" shipped with the package; perhaps that could be borrowed if it would help with the distro or with other internal algorithms in the omniORB code. All imho of course :) - Tom From duncan@grisby.org Wed Feb 26 20:56:54 2003 Received: from grisby.dyndns.org (pc2-cmbg4-5-cust210.cmbg.cable.ntl.com [81.96.73.210]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h1QKur807356 for ; Wed, 26 Feb 2003 20:56:53 GMT Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id h1QKuJw27107 for ; Wed, 26 Feb 2003 20:56:19 GMT Message-Id: <200302262056.h1QKuJw27107@grisby.dyndns.org> X-Authentication-Warning: pc2-cmbg4-5-cust210.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: omniorb-dev Subject: Re: [omniORB-dev] Implementation Repository In-Reply-To: Message from Thomas Lockhart of "Wed, 26 Feb 2003 11:14:24 PST." <3E5D1210.2050701@fourpalms.org> From: Duncan Grisby Date: Wed, 26 Feb 2003 20:56:18 +0000 Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: On Wednesday 26 February, Thomas Lockhart wrote: > I'll make the suggestion that the code should be in omniORB in either > case (with or without STL). Folks can then contribute to adapting it to > be STL-free if that is a requirement for their platform, and autoconf > can be used to enable/disable it on specific platforms in the meantime. > STL *is* settling down a bit and perhaps it is less of an issue but we > wouldn't know until it gets a bit of exposure in the omniORB package. I intend to keep the core parts of omniORB -- i.e. the ORB libraries, the IDL compiler, omniNames -- free of STL. There are plenty of users for whom STL is not an option, either because it's not available at all, or because it conflicts with aspects of their application code. STL also has a bad impact on code size, and there are few (practical) guarantees about things like thread safety or efficiency. Non-core parts, like an added ImR, are a different matter. If the authors of those parts want to make a different trade-off, and use STL, that's fine by me. Just be prepared for the portability issues... :-) Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From lockhart@fourpalms.org Wed Feb 26 23:20:23 2003 Received: from myst.fourpalms.org (dhcp-79-94-247.jpl.nasa.gov [137.79.94.247]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h1QNKM814249 for ; Wed, 26 Feb 2003 23:20:22 GMT Received: from fourpalms.org (localhost.localdomain [127.0.0.1]) by myst.fourpalms.org (Postfix) with ESMTP id 6C63B35398BA; Wed, 26 Feb 2003 18:20:20 -0500 (EST) Message-ID: <3E5D4BB4.9050607@fourpalms.org> Date: Wed, 26 Feb 2003 15:20:20 -0800 From: Thomas Lockhart Organization: Yes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Duncan Grisby Cc: omniorb-dev Subject: Re: [omniORB-dev] Implementation Repository References: <200302262056.h1QKuJw27107@grisby.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: > I intend to keep the core parts of omniORB -- i.e. the ORB libraries, > the IDL compiler, omniNames -- free of STL. There are plenty of users > for whom STL is not an option, either because it's not available at > all, or because it conflicts with aspects of their application code. > STL also has a bad impact on code size, and there are few (practical) > guarantees about things like thread safety or efficiency. Thanks for the clarification and guidelines. > Non-core parts, like an added ImR, are a different matter. If the > authors of those parts want to make a different trade-off, and use > STL, that's fine by me. Just be prepared for the portability > issues... :-) That's great! My point was that *if* the code has a shot at running on some platforms, then motivated folks can contribute to the code by making sure it runs on more platforms. But that can't happen (easily) until it is in CVS somewhere. Since you are open to the possibility of having this app have some STL, then it isn't a barrier to getting it into CVS anyway. - Tom From lockhart@fourpalms.org Fri Feb 28 16:59:21 2003 Received: from myst.fourpalms.org (www.fourpalms.org [64.3.68.148]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h1SGxJ805891 for ; Fri, 28 Feb 2003 16:59:19 GMT Received: from fourpalms.org (localhost.localdomain [127.0.0.1]) by myst.fourpalms.org (Postfix) with ESMTP id 5372335398D6 for ; Fri, 28 Feb 2003 11:59:20 -0500 (EST) Message-ID: <3E5F9568.6070602@fourpalms.org> Date: Fri, 28 Feb 2003 08:59:20 -0800 From: Thomas Lockhart Organization: Yes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: omniORB development list Content-Type: multipart/mixed; boundary="------------050209060603060302010005" Subject: [omniORB-dev] Patches for IDL stub generation Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. --------------050209060603060302010005 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I figured I'd post the current state of my patches for generating all of the COS-defined IDL for python, in case I get hit by a bus or in case they are acceptable as-is ;) I've included two files: patches for existing files and a tarball of a new directory python/COS which contains makefiles for the IDL stubs. Note that the patch file mentions several files which are no longer needed afaict: python/CosNaming* (now generated automatically, but in a different style than before; is that OK Duncan?), and acinclude.m4 (is this needed by pre-2.53 autoconf??). This *could* be a "final version" if using COS.pth to expose the IDL files to the top level namespace is acceptable. afaict this restricts the installation to be in python's main library area, which is the only place .pth files are respected. btw, many of the "patches" are for files generated by ./configure but which are included in the distro anyway. The actual necessary patches are quite small. - Tom --------------050209060603060302010005 Content-Type: application/gzip; name="omniORBpy-COS.tar.gz" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="omniORBpy-COS.tar.gz" H4sIABKTXz4AA+1Ye2/bNhDPv9GnILoEtdZEkp3EBhx4iGO7rQHH9mR1D6CoQEt0zEUWBUpK q336HamHpcROuzVosU0HJBaPP/KO9+JJbOPTmXkdJKctzdCDJFozXx/MFvrB85FhnBudzgX8 Ns+M807pt6ADo9NudTpNo2O0DozmxXnLOEAXz6jDXorDCHOEDjzm3K0xj/bhPjf/LyW2z/9v pu82+I6sqEc06n+VDKNpGO3z873+b7Xbqf8vOi0DHA9/BoQLMp7pjE/S/9z/1mze0zRd05TB O9McTa1eFgNZYCjX/cXInt1Mx7Zljka9q4gFdsgdl/Ir5Zd533rbu8qH4+nC6k8mvavs4UpR qO94sUvQUQMEqfrmTl+SFeMExxHTNnfFfL6HDv/K/O06vIoIz5d9b6v9d2hv/qeOeBYZn8n/ dqvZyuq/cXbWhHui2b5o1fn/TWj++2R8bc5mVg9ybfTbfGZaMtFV3aPLLB4UCRqOTSRAxQq1 qBFZvldgBc96O5sCUxVRpSg/oF/XhBMUMeQxdoegGKDxcILEPRNqMG2taYg8GkbIYbHnoiWB B39Fb2OOl3AXKQrAYb+FlCIKE2hgp/qE4CCiU9fLNRMy0XsFFfTZFQ/Q1eqnCuST++3fadi3 +tIMJYg0B0lPWxgBTuyxjwj7LopDMNSaoPsAR2thshUFLnA2wlJ9n8EjRwELQ7qkHo0SBLYD mFh31PhIPdfB3BXOGE5EqVb1HzUQr8JinG7kC5lQWBGLIylqid2yP5RU9LFYlu4jTK+CE6aD wgmyoDtr5J6UICfodHzUcFVVkU4loNL2iC5DoDxqJCRSkeMR7HsJuHkTUOnha7DUcPJ6PBkJ AQMWDpjvxJwT30ngMeLM01JPwNyEOsQPqX97g318S/h2xuLYD7ETUeaHkit4iznjEU7NlUGH g5E9GM/mCwJCtuypuSD8HnbPxouRAOWDDNt3N9SXvAer8+GE3BOvWUFIVqvCMkngYYfICM/W Lya5NItuyDUO5Yyw5mtpw48UHOPiEEyLIIhFltwTHhE3DZQCEvsu4aEDPgpRtwHLF+s8sYS4 FP0pxWIURhxMicJ4GUY0ioXtNE1E28THG3IKRYFjnqSalHzUj6Ipi+gqGayx7xNvaxbpPc8j 0g1b3wzA2QxUm9AVGSROcezU2RGm/ob4Ub7D6B4Gj7aW6HSKbTYF9hPEs489+icWIh/uli6q YvYsNcmKiJgr6faG42AdloMvU3+H0juOVrCqW8PMFMOpbrdIaU3qVNTbY+EtPinbIeW8lum9 xc2Wf4Arxi7omccqcOcQIVCEhELD4WyLLvMX9mAy3rFgDjPD/s41MLVrwXi4Gz3bBZ7dlMCc BRDiSTkvgf1zTHiyK8jkRI7a4U2TeNLA4ZoGRYVYRFDNNqUqAtlXVA945jLiKlXGBdcNE0gQ 6hTIlPtgCGnOStFjJQFxd8d2dTZ363bV/mwrT2/XFZFXrWnmcGyRMBJrcr2q1SZL8Oz3VS+t 8HLUFYieDf+0IFH3I3Tbpj6NbPtpmG3PZ/09WLjGtSBaK3mnMRrmej1gvCrfRytxH0m+elLu SNIuRdUBKa4nBXtet1tAFUVeSN2ucnjUMG/U7UQ2PuWPdFd3nwb2Ip8CuG/K2x9eNaC37r3I OimhyYvLSrMgeiJRwBH10dGHS3FblqdFNzGS24qLwGJDytUKwGU+qe7ouKgkTswdIskRzRmc yEEv6EbsmF/CYJLL0rOWPdqgeeOl9jLV+BDBAenKJSuU2dbqm29GFry9QVOdGbXqIHVfZyjd eyj1fOinVNTXaasQ36UrRXlCereIsq2H4AcdXYnTCn8A5wM8Pra+Wtk4D6/jLjr+R3sVCl3C cuKsGcDkhbzTeCcnj2Wr6CeQJXoFM4Y4EgG1jKEdFFc7GKjUiYk+EDSDysk4JaGiHGcJjY7L uYiOH6VnN+0KRVaIHhi2BNfco9Pgcdcs2l2A2tByvBf4rHkE/DJ9w4Awr9/pvwt9yfe/r5Uh 3//bT3z/E98GxPt/u2OcXbQB37kwmvX7/7egv/v9L8UWn/r0OOT6kvp6VvKhOH/5Rz+t/tpX U0011VRTTTXVVFNNNdVUU03fhP4C1HF7rgAoAAA= --------------050209060603060302010005 Content-Type: text/plain; name="omniORBpy.patches" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="omniORBpy.patches" Only in omniORBpy-2.0.orig: acinclude.m4 diff -rc omniORBpy-2.0.orig/configure omniORBpy-2.0/configure *** omniORBpy-2.0.orig/configure 2002-09-06 21:34:25.000000000 +0000 --- omniORBpy-2.0/configure 2003-02-28 06:29:47.000000000 +0000 *************** *** 2824,2829 **** --- 2824,2914 ---- pkgpyexecdir=\${pyexecdir}/$PACKAGE + # Extract the first word of "omkdepend", so it can be a program name with args. + set dummy omkdepend; ac_word=$2 + echo "$as_me:$LINENO: checking for $ac_word" >&5 + echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6 + if test "${ac_cv_path_OMKDEPEND+set}" = set; then + echo $ECHO_N "(cached) $ECHO_C" >&6 + else + case $OMKDEPEND in + [\\/]* | ?:[\\/]*) + ac_cv_path_OMKDEPEND="$OMKDEPEND" # Let the user override the test with a path. + ;; + *) + as_save_IFS=$IFS; IFS=$PATH_SEPARATOR + for as_dir in $PATH:$OMNIORB_ROOT/bin:/usr/local/bin:/usr/bin + do + IFS=$as_save_IFS + test -z "$as_dir" && as_dir=. + for ac_exec_ext in '' $ac_executable_extensions; do + if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then + ac_cv_path_OMKDEPEND="$as_dir/$ac_word$ac_exec_ext" + echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5 + break 2 + fi + done + done + + test -z "$ac_cv_path_OMKDEPEND" && ac_cv_path_OMKDEPEND="omkdepend" + ;; + esac + fi + OMKDEPEND=$ac_cv_path_OMKDEPEND + + if test -n "$OMKDEPEND"; then + echo "$as_me:$LINENO: result: $OMKDEPEND" >&5 + echo "${ECHO_T}$OMKDEPEND" >&6 + else + echo "$as_me:$LINENO: result: no" >&5 + echo "${ECHO_T}no" >&6 + fi + + for ac_prog in omkdirhier mkdirhier + do + # Extract the first word of "$ac_prog", so it can be a program name with args. + set dummy $ac_prog; ac_word=$2 + echo "$as_me:$LINENO: checking for $ac_word" >&5 + echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6 + if test "${ac_cv_path_MKDIRHIER+set}" = set; then + echo $ECHO_N "(cached) $ECHO_C" >&6 + else + case $MKDIRHIER in + [\\/]* | ?:[\\/]*) + ac_cv_path_MKDIRHIER="$MKDIRHIER" # Let the user override the test with a path. + ;; + *) + as_save_IFS=$IFS; IFS=$PATH_SEPARATOR + for as_dir in ./bin/scripts:$PATH:$OMNIORB_ROOT/bin:/usr/local/bin:/usr/bin + do + IFS=$as_save_IFS + test -z "$as_dir" && as_dir=. + for ac_exec_ext in '' $ac_executable_extensions; do + if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then + ac_cv_path_MKDIRHIER="$as_dir/$ac_word$ac_exec_ext" + echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5 + break 2 + fi + done + done + + ;; + esac + fi + MKDIRHIER=$ac_cv_path_MKDIRHIER + + if test -n "$MKDIRHIER"; then + echo "$as_me:$LINENO: result: $MKDIRHIER" >&5 + echo "${ECHO_T}$MKDIRHIER" >&6 + else + echo "$as_me:$LINENO: result: no" >&5 + echo "${ECHO_T}no" >&6 + fi + + test -n "$MKDIRHIER" && break + done + test -n "$MKDIRHIER" || MKDIRHIER="omkdirhier" + ac_ext=cc ac_cpp='$CXXCPP $CPPFLAGS' *************** *** 3011,3017 **** ac_config_files="$ac_config_files mk/beforeauto.mk mk/afterauto.mk" ! ac_config_files="$ac_config_files GNUmakefile examples/embed/GNUmakefile modules/GNUmakefile modules/codesets/GNUmakefile modules/sslTP/GNUmakefile omniidl_be/GNUmakefile python/CosNaming/GNUmakefile python/CosNaming__POA/GNUmakefile python/GNUmakefile python/omniORB/GNUmakefile include/GNUmakefile" cat >confcache <<\_ACEOF --- 3096,3102 ---- ac_config_files="$ac_config_files mk/beforeauto.mk mk/afterauto.mk" ! ac_config_files="$ac_config_files GNUmakefile examples/embed/GNUmakefile modules/GNUmakefile modules/codesets/GNUmakefile modules/sslTP/GNUmakefile omniidl_be/GNUmakefile python/GNUmakefile python/COS/GNUmakefile python/omniORB/GNUmakefile include/GNUmakefile" cat >confcache <<\_ACEOF *************** *** 3519,3527 **** "modules/codesets/GNUmakefile" ) CONFIG_FILES="$CONFIG_FILES modules/codesets/GNUmakefile" ;; "modules/sslTP/GNUmakefile" ) CONFIG_FILES="$CONFIG_FILES modules/sslTP/GNUmakefile" ;; "omniidl_be/GNUmakefile" ) CONFIG_FILES="$CONFIG_FILES omniidl_be/GNUmakefile" ;; - "python/CosNaming/GNUmakefile" ) CONFIG_FILES="$CONFIG_FILES python/CosNaming/GNUmakefile" ;; - "python/CosNaming__POA/GNUmakefile" ) CONFIG_FILES="$CONFIG_FILES python/CosNaming__POA/GNUmakefile" ;; "python/GNUmakefile" ) CONFIG_FILES="$CONFIG_FILES python/GNUmakefile" ;; "python/omniORB/GNUmakefile" ) CONFIG_FILES="$CONFIG_FILES python/omniORB/GNUmakefile" ;; "include/GNUmakefile" ) CONFIG_FILES="$CONFIG_FILES include/GNUmakefile" ;; *) { { echo "$as_me:$LINENO: error: invalid argument: $ac_config_target" >&5 --- 3604,3611 ---- "modules/codesets/GNUmakefile" ) CONFIG_FILES="$CONFIG_FILES modules/codesets/GNUmakefile" ;; "modules/sslTP/GNUmakefile" ) CONFIG_FILES="$CONFIG_FILES modules/sslTP/GNUmakefile" ;; "omniidl_be/GNUmakefile" ) CONFIG_FILES="$CONFIG_FILES omniidl_be/GNUmakefile" ;; "python/GNUmakefile" ) CONFIG_FILES="$CONFIG_FILES python/GNUmakefile" ;; + "python/COS/GNUmakefile" ) CONFIG_FILES="$CONFIG_FILES python/COS/GNUmakefile" ;; "python/omniORB/GNUmakefile" ) CONFIG_FILES="$CONFIG_FILES python/omniORB/GNUmakefile" ;; "include/GNUmakefile" ) CONFIG_FILES="$CONFIG_FILES include/GNUmakefile" ;; *) { { echo "$as_me:$LINENO: error: invalid argument: $ac_config_target" >&5 *************** *** 3638,3643 **** --- 3722,3729 ---- s,@pkgpythondir@,$pkgpythondir,;t t s,@pyexecdir@,$pyexecdir,;t t s,@pkgpyexecdir@,$pkgpyexecdir,;t t + s,@OMKDEPEND@,$OMKDEPEND,;t t + s,@MKDIRHIER@,$MKDIRHIER,;t t s,@OMNIORB_ROOT@,$OMNIORB_ROOT,;t t s,@OPEN_SSL_ROOT@,$OPEN_SSL_ROOT,;t t s,@COMPILER_NAME@,$COMPILER_NAME,;t t diff -rc omniORBpy-2.0.orig/configure.ac omniORBpy-2.0/configure.ac *** omniORBpy-2.0.orig/configure.ac 2002-09-06 21:34:25.000000000 +0000 --- omniORBpy-2.0/configure.ac 2003-02-28 06:29:29.000000000 +0000 *************** *** 19,24 **** --- 19,28 ---- AC_PROG_MAKE_SET AM_PATH_PYTHON + AC_PATH_PROG(OMKDEPEND, omkdepend, omkdepend, + $PATH:$OMNIORB_ROOT/bin:/usr/local/bin:/usr/bin) + AC_PATH_PROGS(MKDIRHIER, omkdirhier mkdirhier, omkdirhier, + ./bin/scripts:$PATH:$OMNIORB_ROOT/bin:/usr/local/bin:/usr/bin) AC_LANG(C++) *************** *** 123,131 **** modules/codesets/GNUmakefile modules/sslTP/GNUmakefile omniidl_be/GNUmakefile - python/CosNaming/GNUmakefile - python/CosNaming__POA/GNUmakefile python/GNUmakefile python/omniORB/GNUmakefile include/GNUmakefile ) --- 127,134 ---- modules/codesets/GNUmakefile modules/sslTP/GNUmakefile omniidl_be/GNUmakefile python/GNUmakefile + python/COS/GNUmakefile python/omniORB/GNUmakefile include/GNUmakefile ) diff -rc omniORBpy-2.0.orig/examples/embed/GNUmakefile omniORBpy-2.0/examples/embed/GNUmakefile *** omniORBpy-2.0.orig/examples/embed/GNUmakefile 2002-06-10 00:33:31.000000000 +0000 --- omniORBpy-2.0/examples/embed/GNUmakefile 2003-02-28 14:23:42.000000000 +0000 *************** *** 1,3 **** ! TOP=../../../../.. ! CURRENT=src/lib/omniORBpy/examples/embed ! include $(TOP)/config/config.mk --- 1,9 ---- ! TOP=../.. ! CURRENT=examples/embed ! BASE_OMNI_TREE=../.. ! ! INSTALL=/usr/bin/install -c ! ! include $(TOP)/mk/beforeauto.mk ! include ./dir.mk ! include $(TOP)/mk/afterauto.mk diff -rc omniORBpy-2.0.orig/GNUmakefile omniORBpy-2.0/GNUmakefile *** omniORBpy-2.0.orig/GNUmakefile 1999-10-04 17:25:21.000000000 +0000 --- omniORBpy-2.0/GNUmakefile 2003-02-28 14:23:42.000000000 +0000 *************** *** 1,3 **** ! TOP=../../.. ! CURRENT=src/lib/omniORBpy ! include $(TOP)/config/config.mk --- 1,8 ---- ! TOP=. ! CURRENT=. ! BASE_OMNI_TREE=. ! ! ! include $(TOP)/mk/beforeauto.mk ! include ./dir.mk ! include $(TOP)/mk/afterauto.mk diff -rc omniORBpy-2.0.orig/include/GNUmakefile omniORBpy-2.0/include/GNUmakefile *** omniORBpy-2.0.orig/include/GNUmakefile 2002-06-10 00:33:31.000000000 +0000 --- omniORBpy-2.0/include/GNUmakefile 2003-02-28 14:23:43.000000000 +0000 *************** *** 1,3 **** ! TOP=../../../.. ! CURRENT=src/lib/omniORBpy/include ! include $(TOP)/config/config.mk --- 1,19 ---- ! TOP=.. ! CURRENT=include ! BASE_OMNI_TREE=.. ! ! INSTALL=/usr/bin/install -c ! ! INSTALLDIR = $(INSTALLINCDIR) ! ! HEADERS = omniORBpy.h ! ! include $(TOP)/mk/beforeauto.mk ! ! install:: $(HEADERS) ! @(dir="$(INSTALLDIR)"; \ ! for file in $^; do \ ! $(ExportFileToDir) \ ! done ) ! ! include $(TOP)/mk/afterauto.mk diff -rc omniORBpy-2.0.orig/mk/beforeauto.mk.in omniORBpy-2.0/mk/beforeauto.mk.in *** omniORBpy-2.0.orig/mk/beforeauto.mk.in 2002-09-06 21:34:26.000000000 +0000 --- omniORBpy-2.0/mk/beforeauto.mk.in 2003-02-14 19:34:26.000000000 +0000 *************** *** 43,49 **** # Directories for installation # ! prefix := @prefix@ exec_prefix := @exec_prefix@ INSTALLTARGET := 1 INSTALLINCDIR := @includedir@ --- 43,49 ---- # Directories for installation # ! prefix := $(DESTDIR)@prefix@ exec_prefix := @exec_prefix@ INSTALLTARGET := 1 INSTALLINCDIR := @includedir@ *************** *** 275,281 **** # files. vpath %.idl $(IMPORT_TREES:%=%/idl) \ ! $(OMNIORB_ROOT)/idl/omniORB $(DATADIR)/idl/omniORB IMPORT_IDLFLAGS += -I. $(patsubst %,-I%,$(VPATH)) \ $(patsubst %,-I%/idl,$(IMPORT_TREES)) --- 275,281 ---- # files. vpath %.idl $(IMPORT_TREES:%=%/idl) \ ! $(OMNIORB_ROOT)/share/idl/omniORB $(DATADIR)/idl/omniORB IMPORT_IDLFLAGS += -I. $(patsubst %,-I%,$(VPATH)) \ $(patsubst %,-I%/idl,$(IMPORT_TREES)) *************** *** 336,342 **** define VeryCleanRule $(RM) *.d $(RM) *.pyc ! $(RM) $(CORBA_STUB_FILES) endef --- 336,342 ---- define VeryCleanRule $(RM) *.d $(RM) *.pyc ! $(RM) -r $(CORBA_STUB_FILES) endef *************** *** 664,676 **** CC = @CC@ CXX = @CXX@ RANLIB = @RANLIB@ ! MKDIRHIER = $(BASE_OMNI_TREE)/bin/scripts/omkdirhier INSTLIBFLAGS = -m 0644 INSTEXEFLAGS = -m 0755 CP = cp MV = mv -f CPP = @CPP@ ! OMKDEPEND = $(INSTALLBINDIR)/omkdepend RMDIRHIER = $(RM) -rf CXXMAKEDEPEND = $(OMKDEPEND) -D__cplusplus --- 664,676 ---- CC = @CC@ CXX = @CXX@ RANLIB = @RANLIB@ ! MKDIRHIER = @MKDIRHIER@ INSTLIBFLAGS = -m 0644 INSTEXEFLAGS = -m 0755 CP = cp MV = mv -f CPP = @CPP@ ! OMKDEPEND = @OMKDEPEND@ RMDIRHIER = $(RM) -rf CXXMAKEDEPEND = $(OMKDEPEND) -D__cplusplus diff -rc omniORBpy-2.0.orig/modules/codesets/GNUmakefile omniORBpy-2.0/modules/codesets/GNUmakefile *** omniORBpy-2.0.orig/modules/codesets/GNUmakefile 2002-09-06 21:34:26.000000000 +0000 --- omniORBpy-2.0/modules/codesets/GNUmakefile 2003-02-28 14:23:42.000000000 +0000 *************** *** 1,3 **** ! TOP=../../../../.. ! CURRENT=src/lib/omniORBpy/modules/codesets ! include $(TOP)/config/config.mk --- 1,9 ---- ! TOP=../.. ! CURRENT=modules/codesets ! BASE_OMNI_TREE=../.. ! ! INSTALL=/usr/bin/install -c ! ! include $(TOP)/mk/beforeauto.mk ! include ./dir.mk ! include $(TOP)/mk/afterauto.mk diff -rc omniORBpy-2.0.orig/modules/GNUmakefile omniORBpy-2.0/modules/GNUmakefile *** omniORBpy-2.0.orig/modules/GNUmakefile 1999-10-04 17:25:21.000000000 +0000 --- omniORBpy-2.0/modules/GNUmakefile 2003-02-28 14:23:42.000000000 +0000 *************** *** 1,3 **** ! TOP=../../../.. ! CURRENT=src/lib/omniORBpy/modules ! include $(TOP)/config/config.mk --- 1,9 ---- ! TOP=.. ! CURRENT=modules ! BASE_OMNI_TREE=.. ! ! INSTALL=/usr/bin/install -c ! ! include $(TOP)/mk/beforeauto.mk ! include ./dir.mk ! include $(TOP)/mk/afterauto.mk diff -rc omniORBpy-2.0.orig/modules/sslTP/GNUmakefile omniORBpy-2.0/modules/sslTP/GNUmakefile *** omniORBpy-2.0.orig/modules/sslTP/GNUmakefile 2002-09-06 21:34:26.000000000 +0000 --- omniORBpy-2.0/modules/sslTP/GNUmakefile 2003-02-28 14:23:42.000000000 +0000 *************** *** 1,3 **** ! TOP=../../../../.. ! CURRENT=src/lib/omniORBpy/modules/sslTP ! include $(TOP)/config/config.mk --- 1,9 ---- ! TOP=../.. ! CURRENT=modules/sslTP ! BASE_OMNI_TREE=../.. ! ! INSTALL=/usr/bin/install -c ! ! include $(TOP)/mk/beforeauto.mk ! include ./dir.mk ! include $(TOP)/mk/afterauto.mk diff -rc omniORBpy-2.0.orig/omniidl_be/GNUmakefile omniORBpy-2.0/omniidl_be/GNUmakefile *** omniORBpy-2.0.orig/omniidl_be/GNUmakefile 2000-03-03 17:41:44.000000000 +0000 --- omniORBpy-2.0/omniidl_be/GNUmakefile 2003-02-28 14:23:42.000000000 +0000 *************** *** 1,3 **** ! TOP=../../../.. ! CURRENT=src/lib/omniORBpy/omniidl_be ! include $(TOP)/config/config.mk --- 1,9 ---- ! TOP=.. ! CURRENT=omniidl_be ! BASE_OMNI_TREE=.. ! ! INSTALL=/usr/bin/install -c ! ! include $(TOP)/mk/beforeauto.mk ! include ./dir.mk ! include $(TOP)/mk/afterauto.mk Only in omniORBpy-2.0/python: COS Only in omniORBpy-2.0.orig/python: CosNaming Only in omniORBpy-2.0.orig/python: CosNaming__POA diff -rc omniORBpy-2.0.orig/python/dir.mk omniORBpy-2.0/python/dir.mk *** omniORBpy-2.0.orig/python/dir.mk 2002-02-18 18:48:14.000000000 +0000 --- omniORBpy-2.0/python/dir.mk 2003-02-28 14:21:34.000000000 +0000 *************** *** 2,18 **** PYLIBDIR = $(PYLIBROOT) INSTALLPYLIBDIR = $(INSTALLPYTHONDIR) ! SUBDIRS = omniORB CosNaming CosNaming__POA - ifeq ($(PYTHON),) - PYTHON = python - endif - - - Naming_idl.py: Naming.idl - $(OMNIIDL) -v -p$(BASE_OMNI_TREE)/omniidl_be -bpython $^ - - all:: Naming_idl.py all:: @$(MakeSubdirs) --- 2,9 ---- PYLIBDIR = $(PYLIBROOT) INSTALLPYLIBDIR = $(INSTALLPYTHONDIR) ! SUBDIRS = omniORB COS all:: @$(MakeSubdirs) *************** *** 25,31 **** @$(MakeSubdirs) endif ! FILES = CORBA.py PortableServer.py PortableServer__POA.py Naming_idl.py export:: $(FILES) @(dir="$(PYLIBDIR)"; \ --- 16,22 ---- @$(MakeSubdirs) endif ! FILES = CORBA.py PortableServer.py PortableServer__POA.py export:: $(FILES) @(dir="$(PYLIBDIR)"; \ diff -rc omniORBpy-2.0.orig/python/GNUmakefile omniORBpy-2.0/python/GNUmakefile *** omniORBpy-2.0.orig/python/GNUmakefile 1999-10-04 17:25:20.000000000 +0000 --- omniORBpy-2.0/python/GNUmakefile 2003-02-28 14:23:42.000000000 +0000 *************** *** 1,3 **** ! TOP=../../../.. ! CURRENT=src/lib/omniORBpy/python ! include $(TOP)/config/config.mk --- 1,9 ---- ! TOP=.. ! CURRENT=python ! BASE_OMNI_TREE=.. ! ! INSTALL=/usr/bin/install -c ! ! include $(TOP)/mk/beforeauto.mk ! include ./dir.mk ! include $(TOP)/mk/afterauto.mk diff -rc omniORBpy-2.0.orig/python/omniORB/GNUmakefile omniORBpy-2.0/python/omniORB/GNUmakefile *** omniORBpy-2.0.orig/python/omniORB/GNUmakefile 1999-10-04 17:25:19.000000000 +0000 --- omniORBpy-2.0/python/omniORB/GNUmakefile 2003-02-28 14:23:43.000000000 +0000 *************** *** 1,3 **** ! TOP=../../../../.. ! CURRENT=src/lib/omniORBpy/python/omniORB ! include $(TOP)/config/config.mk --- 1,9 ---- ! TOP=../.. ! CURRENT=python/omniORB ! BASE_OMNI_TREE=../.. ! ! INSTALL=/usr/bin/install -c ! ! include $(TOP)/mk/beforeauto.mk ! include ./dir.mk ! include $(TOP)/mk/afterauto.mk --------------050209060603060302010005-- From lockhart@fourpalms.org Fri Feb 28 17:00:44 2003 Received: from myst.fourpalms.org (golem.fourpalms.org [64.3.68.148]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h1SH0i805974 for ; Fri, 28 Feb 2003 17:00:44 GMT Received: from fourpalms.org (localhost.localdomain [127.0.0.1]) by myst.fourpalms.org (Postfix) with ESMTP id EE80535398D6; Fri, 28 Feb 2003 12:00:39 -0500 (EST) Message-ID: <3E5F95B7.1000307@fourpalms.org> Date: Fri, 28 Feb 2003 09:00:39 -0800 From: Thomas Lockhart Organization: Yes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Lockhart Cc: Duncan Grisby , omniORB Mailing List , omniORB development list References: <3E5F7ECF.3060902@fourpalms.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [omniORB-dev] Re: [omniORB] Last questions on installing IDL stubs Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: Sorry for cross-posting, but just wanted to mention that I've posted patches on the omniORB-dev mailing list. - Tom > I think I have things working to allow building and installing all > (buildable) IDL files. Including the .pyc files, there are 358 files to > be installed! > > With that many files, should we isolate them into their own directory > (say, "site-packages/COS")? Previously, CosNaming was installed into the > main area, but on my machine that only contains 79 files including a > omniORB 2.0 installation. > > I'm not sure how to best build and install the IDL into a subdirectory > while maintaining the ability to simply say "import CosNaming" and have > it work as before. I'm pretty new with python installing, but afaik all > of the options are: > > 1) Install into site-packages/COS/. Include a site-packages/COS.pth so > python knows to make COS/ visible. > > 2) Install into site-packages/COS/. Include a > site-packages/COS/__init__.py to allow "from COS import CosNaming". Not > sure if I can generate all of the IDL so it hangs together. And changes > the import line for existing code :( > > 3) Install into site-packages/omniORB/. Require "from omniORB import > CosNaming". Same issues as (2) > > 4) Install 358 extra files into site-packages/. Oof :/ > > > (1) seems to me to be least invasive and most in style with the current > version, though I'm not sure that COS.pth works with directories outside > of the main installation area like /usr/lib/python2.2/site-packages. (2) > and (3) change the namespace for CosNaming, and (4) seems to be really > heavy. Suggestions/comments/guidance? From duncan@grisby.org Fri Feb 28 17:33:51 2003 Received: from grisby.dyndns.org (pc2-cmbg4-5-cust210.cmbg.cable.ntl.com [81.96.73.210]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h1SHXo807642 for ; Fri, 28 Feb 2003 17:33:50 GMT Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id h1SHXBl04661; Fri, 28 Feb 2003 17:33:11 GMT Message-Id: <200302281733.h1SHXBl04661@grisby.dyndns.org> X-Authentication-Warning: pc2-cmbg4-5-cust210.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: Thomas Lockhart cc: omniORB development list Subject: Re: [omniORB-dev] Patches for IDL stub generation In-Reply-To: Message from Thomas Lockhart of "Fri, 28 Feb 2003 08:59:20 PST." <3E5F9568.6070602@fourpalms.org> From: Duncan Grisby Date: Fri, 28 Feb 2003 17:33:11 +0000 Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: On Friday 28 February, Thomas Lockhart wrote: > Note that the patch file mentions several files which are no longer > needed afaict: python/CosNaming* (now generated automatically, but in a > different style than before; is that OK Duncan?), Yes, although see my comment in my other mail that I think CosNaming should still be installed in the place it always used to be. > and acinclude.m4 (is this needed by pre-2.53 autoconf??). acinclude.m4 is required. It is one of the inputs to aclocal that generates aclocal.m4. > btw, many of the "patches" are for files generated by ./configure but > which are included in the distro anyway. The actual necessary patches > are quite small. The files in the distribution that you have patched are used in the case that autoconf is not being used. They are important, and need to remain the way they were! Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From lockhart@fourpalms.org Fri Feb 28 18:59:38 2003 Received: from myst.fourpalms.org (dhcp-78-180-241.jpl.nasa.gov [137.78.180.241]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h1SIxc811730 for ; Fri, 28 Feb 2003 18:59:38 GMT Received: from fourpalms.org (localhost.localdomain [127.0.0.1]) by myst.fourpalms.org (Postfix) with ESMTP id 9EC3335398D6; Fri, 28 Feb 2003 13:59:39 -0500 (EST) Message-ID: <3E5FB19B.3010406@fourpalms.org> Date: Fri, 28 Feb 2003 10:59:39 -0800 From: Thomas Lockhart Organization: Yes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Duncan Grisby Cc: omniORB development list Subject: Re: [omniORB-dev] Patches for IDL stub generation References: <200302281733.h1SHXBl04661@grisby.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: (Consolidating this discussion on the -dev list) Re: location of CosNaming and other stub files OK, I can put CosNaming up at the top as it is currently. Do you have a preference on the style of generation? I would like to also put it down lower in omniORB/COS for completeness, and include a .pth file up above to make them visible (unless otherwise indicated by then answer to the next question)... Does the python standard for CORBA specify the visibility for interfaces other than CosNaming? >>Note that the patch file mentions several files which are no longer >>needed afaict: python/CosNaming* (now generated automatically, but in a >>different style than before; is that OK Duncan?), > Yes, although see my comment in my other mail that I think CosNaming > should still be installed in the place it always used to be. >> and acinclude.m4 (is this needed by pre-2.53 autoconf??). > acinclude.m4 is required. It is one of the inputs to aclocal that > generates aclocal.m4. Hmm. When I rename it aside autoconf stays happy. Oh well... >>btw, many of the "patches" are for files generated by ./configure but >>which are included in the distro anyway. The actual necessary patches >>are quite small. > The files in the distribution that you have patched are used in the > case that autoconf is not being used. They are important, and need to > remain the way they were! Fine with me :) Is it OK to send you patches on everything and have you decide which files should stay the same, or should I somehow weed out the ones which autoconf overwrites? There may be one or two which need to be hand-modified or generated by you in your standard environment to get changes to support the COS stubs. Does your release schedule allow me to work on this over the weekend, or do you need patches before Monday? - Tom From lockhart@fourpalms.org Sat Mar 1 01:23:02 2003 Received: from myst.fourpalms.org (dhcp-78-180-241.jpl.nasa.gov [137.78.180.241]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h211N1830036 for ; Sat, 1 Mar 2003 01:23:01 GMT Received: from fourpalms.org (localhost.localdomain [127.0.0.1]) by myst.fourpalms.org (Postfix) with ESMTP id CF87B35398D6; Fri, 28 Feb 2003 20:23:04 -0500 (EST) Message-ID: <3E600B78.8000900@fourpalms.org> Date: Fri, 28 Feb 2003 17:23:04 -0800 From: Thomas Lockhart Organization: Yes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Duncan Grisby Cc: omniORB development list Subject: Re: [omniORB-dev] Patches for IDL stub generation References: <200302281733.h1SHXBl04661@grisby.dyndns.org> <3E5FB19B.3010406@fourpalms.org> Content-Type: multipart/mixed; boundary="------------000307050801030307000706" Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. --------------000307050801030307000706 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Here is a new tarball and patch set to generate more IDL stubs, based on the omniORBpy-2.0 distro. It should address all issues raised so far, and more suggestions are welcome. At the moment, CosNaming appears both at the top of the installation area and in omniORB/COS, and a file omniORB.pth is included which exposes omniORB/COS to the global namespace when the installation target area is also the default python library installation area. Now that things have firmed up these details are quite easy to change if desired. Oh, the patch file does change some files which you indicated should stay fixed to allow building without autoconf support, but I'll defer to him on exactly which files those are. Tuning the patch within the CVS environment is much easier than working from the distro imho. Let me know what else it needs. I'll be off-line this weekend, but if mail arrives quickly I can work on things anyway. Otherwise, I can address any additional issues at the end of the weekend... - Tom --------------000307050801030307000706 Content-Type: application/gzip; name="omniORBpy-COS.tar.gz" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="omniORBpy-COS.tar.gz" H4sIAGMIYD4AA+1Ye2/bNhDPv9WnILoEjdZEdpyHARce4thuasC1PVvdAyhq0BIdc5FJjZLS ep9+d9Q7kZtuDTps8wGJJfJ3x+O9eKJcCz6eXvmb44ZVr/mbcCVFrTue1faejur1s3qzeQ6/ J6f1s2bhN6O9evPiFH5Pm82LvfrJ+VmjvkfOn1CHrRQFIVWE7HnSuV1RFW7DPTb/LyW5zf/X o3dresuW3GMWF1+1Rv2kXr84O9vq/8bFBfq/0TxvNurgePirQ7iQ+hPt8bP0P/e/PZ60Latm WUb33XTaH9ntJAaSwDCuOrP+fPx2NJjb036/fRlKfx4ox+Xq0vhp0rHftC/T18FoZneGw/Zl 8nBpGFw4XuQysn8IC5m19W1twZZSMRqF0lrfZvOpjBr8K47nfHQZMpWy/dNW++/Q1vyPHfEk azyS/83maVb/G40GnBMnF+cnu/z/JjT5dTi4mo7Hdhtyrf/LZDy1daKbNY8vkngwNKg3mBIE ZRxmViOSfC/BsjH7zXgEgxkao8swviM/r5hiJJTEk/KWQFEgg96Q4HkTWDBtr3hAPB6ExJGR 55IFgwex5DeRogs4kwwD4CB3plfDAgWy57FeATiK1bjrFdck7w2S0aMc99DlKmgi8rPytkvq deyONkcBos3B4t1mRoAde/IjocIlUQCGWjFy59NwhSZbchiFkTVaqiMkPCriyyDgC+7xcEPA dgBDvv3Dj9xzHapcdEpviCXbrH1vwfImMNNYkMA1ocASGYV6qQV1i/4w4qUPkC2Wg6Y3wQmj buYEXdidFXGPCpAjcjzYP3RN09BOZaBSvkVXElCeHG5YaBLHY1R4G3Dz2ufaw1dgqd7w9WDY xwW6MuhK4URKMeFs4DFU0rNiT8DckDtMBFzcvKWC3jCVz9iKioA6IZci0KM4NptIFdLYXAm0 1+3Pu4PxZMZgkXx4NJ0xdQfSk/dZH0HpS4LtuGsu9Ng97vR1yO6Yd1JC6KFGaWjKfI86TEd4 wj8bpqvZfM2uaKBn0JqvtQ0/cnCMSwMwLYEgxiy5YypkbhwoGSQSLlOBAz4KSOsQ2GerNLFw uRj9KcZSEoQKTEmCaBGEPIzQdpaF0TYUdM2OoTgoqjaxJgUfdcJwJEO+3HRXVAjm5WbR3vM8 pt2Q+6YLzpag2pAvWXfjZNuOnR1SLtZMhKmE/h28PBCt0fGUXK8z7CeIZ0E9/gfFJe9Li5nK mC2sU7ZkGHMF3a4V9VdBMfgS9SuUrthaNlQWDTMjCru6yZHamtwpqbfFwjl+U7RDPPJap3eO Gy9+A1cMXNAzjVUYnUCEQBFChXq9cY4ujs/m3eGggmECM71OJQ9MVTEMetXocRV4/LYAVtKH EN8U8xKGf4yY2lQFmZ5IURXenDJPGzhYcT+rELMQqtm6UEUg+7LqAc9KR1ypyrjgut4GEoQ7 GTIevfcKaS4L0WNvfOZWx3Z5NnVrzrU924rTOV8WeeWaNu0NbBaEyJPqVa42SYKnR32/lw7g AeR5RC71sQGlIIG+bMeHgH5roZD2HP5Z/sbcjqjN51zwcD7/PGw+n4w7Zew9vV4Wz6Mlnkd6 3DwqdiZxt2LWAGniWTiBsy9LQULjgxC+d9LNcQG9oheHCpZaCpPy8ZWTkzWTfJCrU9Yn65Ri hdCyxPKhHGMVx/rMPkHYMFJsamAUVbvx5IJ6BGtz4MMBktsuAaOcSlW39mmawzBgw61WprBh 6FO61TKe7R9O35r5RPJ+rB54y6z2H8jC/aiwKP7Z5SF8eLSfJ20m6vP8VamDwkZR24MLsv/h FbYQxWlssfpaLJ6OtuxxZZYArhSsLNFxSWE5nHtG9AhaBHbkkOd8jRLTzgRM8qrwbCWPc9D8 8IX1Itb4GYEN8qXLliQxsd2ZXvdtI4kiveuyQ2D7Wpf7ARqL+zqNDCZcvsSYmvnMwSOFqAis iOZMNMKgrwx/D/sUzA+I4l4kHCpeBNBtchESxW6gs0Q8grsQNh2ypr6ve4cQmkuYTbrMBXVu P2IbispBDiWdqu43fMXuuIyCNFqJC2VfQYk0qgI0z6RWIasKsQM/ZP8S/YCRAiMf4PFhXJiP moMS3fbeyz+YBMakKMR7DkJolNJkzGym85HohNT7hOYaGBX7PeIqtlls5Q02YcmyTPfjilkE ajfLIMCXlwLo7iV2ytDKgfbY6kEyxN9q4JnU7rpEVVuwkOKtUoX4eza8ZoKp1IRghGQr6cdD RckFzz2dwxYRfOGkMZg5zDJKu3wFyzFnJUGsbmorS9/R0UNdTfID6PZgm6WFcbNxCGCkB7fM YyF+bBgHyZlHDorHFTl4cIK14m8rLKP4JQn1EvL8jhz7D789cVsAnUPMvEd88gkG+EUcA1AX v/iG7Evuf7/2jkHf/1x85v4X74bw/rd5Vj+t4/1/86zZ2N3/fAv6q/e/MTa76q1FgaotuKil KX/sfPmlr7W77d3Rjna0ox3taEc72tGOdrSjb0Z/Algp9sgAKAAA --------------000307050801030307000706 Content-Type: text/plain; name="omniORBpy-COS.patches" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="omniORBpy-COS.patches" Only in omniORBpy-2.0: autom4te-2.5x.cache diff -cr omniORBpy-2.0.orig/configure omniORBpy-2.0/configure *** omniORBpy-2.0.orig/configure 2002-09-06 21:34:25.000000000 +0000 --- omniORBpy-2.0/configure 2003-03-01 01:00:34.000000000 +0000 *************** *** 2824,2829 **** --- 2824,2914 ---- pkgpyexecdir=\${pyexecdir}/$PACKAGE + # Extract the first word of "omkdepend", so it can be a program name with args. + set dummy omkdepend; ac_word=$2 + echo "$as_me:$LINENO: checking for $ac_word" >&5 + echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6 + if test "${ac_cv_path_OMKDEPEND+set}" = set; then + echo $ECHO_N "(cached) $ECHO_C" >&6 + else + case $OMKDEPEND in + [\\/]* | ?:[\\/]*) + ac_cv_path_OMKDEPEND="$OMKDEPEND" # Let the user override the test with a path. + ;; + *) + as_save_IFS=$IFS; IFS=$PATH_SEPARATOR + for as_dir in $PATH:$OMNIORB_ROOT/bin:/usr/local/bin:/usr/bin + do + IFS=$as_save_IFS + test -z "$as_dir" && as_dir=. + for ac_exec_ext in '' $ac_executable_extensions; do + if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then + ac_cv_path_OMKDEPEND="$as_dir/$ac_word$ac_exec_ext" + echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5 + break 2 + fi + done + done + + test -z "$ac_cv_path_OMKDEPEND" && ac_cv_path_OMKDEPEND="omkdepend" + ;; + esac + fi + OMKDEPEND=$ac_cv_path_OMKDEPEND + + if test -n "$OMKDEPEND"; then + echo "$as_me:$LINENO: result: $OMKDEPEND" >&5 + echo "${ECHO_T}$OMKDEPEND" >&6 + else + echo "$as_me:$LINENO: result: no" >&5 + echo "${ECHO_T}no" >&6 + fi + + for ac_prog in omkdirhier mkdirhier + do + # Extract the first word of "$ac_prog", so it can be a program name with args. + set dummy $ac_prog; ac_word=$2 + echo "$as_me:$LINENO: checking for $ac_word" >&5 + echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6 + if test "${ac_cv_path_MKDIRHIER+set}" = set; then + echo $ECHO_N "(cached) $ECHO_C" >&6 + else + case $MKDIRHIER in + [\\/]* | ?:[\\/]*) + ac_cv_path_MKDIRHIER="$MKDIRHIER" # Let the user override the test with a path. + ;; + *) + as_save_IFS=$IFS; IFS=$PATH_SEPARATOR + for as_dir in ./bin/scripts:$PATH:$OMNIORB_ROOT/bin:/usr/local/bin:/usr/bin + do + IFS=$as_save_IFS + test -z "$as_dir" && as_dir=. + for ac_exec_ext in '' $ac_executable_extensions; do + if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then + ac_cv_path_MKDIRHIER="$as_dir/$ac_word$ac_exec_ext" + echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5 + break 2 + fi + done + done + + ;; + esac + fi + MKDIRHIER=$ac_cv_path_MKDIRHIER + + if test -n "$MKDIRHIER"; then + echo "$as_me:$LINENO: result: $MKDIRHIER" >&5 + echo "${ECHO_T}$MKDIRHIER" >&6 + else + echo "$as_me:$LINENO: result: no" >&5 + echo "${ECHO_T}no" >&6 + fi + + test -n "$MKDIRHIER" && break + done + test -n "$MKDIRHIER" || MKDIRHIER="omkdirhier" + ac_ext=cc ac_cpp='$CXXCPP $CPPFLAGS' *************** *** 3011,3017 **** ac_config_files="$ac_config_files mk/beforeauto.mk mk/afterauto.mk" ! ac_config_files="$ac_config_files GNUmakefile examples/embed/GNUmakefile modules/GNUmakefile modules/codesets/GNUmakefile modules/sslTP/GNUmakefile omniidl_be/GNUmakefile python/CosNaming/GNUmakefile python/CosNaming__POA/GNUmakefile python/GNUmakefile python/omniORB/GNUmakefile include/GNUmakefile" cat >confcache <<\_ACEOF --- 3096,3102 ---- ac_config_files="$ac_config_files mk/beforeauto.mk mk/afterauto.mk" ! ac_config_files="$ac_config_files GNUmakefile examples/embed/GNUmakefile modules/GNUmakefile modules/codesets/GNUmakefile modules/sslTP/GNUmakefile omniidl_be/GNUmakefile python/GNUmakefile python/COS/GNUmakefile python/omniORB/GNUmakefile include/GNUmakefile" cat >confcache <<\_ACEOF *************** *** 3519,3527 **** "modules/codesets/GNUmakefile" ) CONFIG_FILES="$CONFIG_FILES modules/codesets/GNUmakefile" ;; "modules/sslTP/GNUmakefile" ) CONFIG_FILES="$CONFIG_FILES modules/sslTP/GNUmakefile" ;; "omniidl_be/GNUmakefile" ) CONFIG_FILES="$CONFIG_FILES omniidl_be/GNUmakefile" ;; - "python/CosNaming/GNUmakefile" ) CONFIG_FILES="$CONFIG_FILES python/CosNaming/GNUmakefile" ;; - "python/CosNaming__POA/GNUmakefile" ) CONFIG_FILES="$CONFIG_FILES python/CosNaming__POA/GNUmakefile" ;; "python/GNUmakefile" ) CONFIG_FILES="$CONFIG_FILES python/GNUmakefile" ;; "python/omniORB/GNUmakefile" ) CONFIG_FILES="$CONFIG_FILES python/omniORB/GNUmakefile" ;; "include/GNUmakefile" ) CONFIG_FILES="$CONFIG_FILES include/GNUmakefile" ;; *) { { echo "$as_me:$LINENO: error: invalid argument: $ac_config_target" >&5 --- 3604,3611 ---- "modules/codesets/GNUmakefile" ) CONFIG_FILES="$CONFIG_FILES modules/codesets/GNUmakefile" ;; "modules/sslTP/GNUmakefile" ) CONFIG_FILES="$CONFIG_FILES modules/sslTP/GNUmakefile" ;; "omniidl_be/GNUmakefile" ) CONFIG_FILES="$CONFIG_FILES omniidl_be/GNUmakefile" ;; "python/GNUmakefile" ) CONFIG_FILES="$CONFIG_FILES python/GNUmakefile" ;; + "python/COS/GNUmakefile" ) CONFIG_FILES="$CONFIG_FILES python/COS/GNUmakefile" ;; "python/omniORB/GNUmakefile" ) CONFIG_FILES="$CONFIG_FILES python/omniORB/GNUmakefile" ;; "include/GNUmakefile" ) CONFIG_FILES="$CONFIG_FILES include/GNUmakefile" ;; *) { { echo "$as_me:$LINENO: error: invalid argument: $ac_config_target" >&5 *************** *** 3638,3643 **** --- 3722,3729 ---- s,@pkgpythondir@,$pkgpythondir,;t t s,@pyexecdir@,$pyexecdir,;t t s,@pkgpyexecdir@,$pkgpyexecdir,;t t + s,@OMKDEPEND@,$OMKDEPEND,;t t + s,@MKDIRHIER@,$MKDIRHIER,;t t s,@OMNIORB_ROOT@,$OMNIORB_ROOT,;t t s,@OPEN_SSL_ROOT@,$OPEN_SSL_ROOT,;t t s,@COMPILER_NAME@,$COMPILER_NAME,;t t diff -cr omniORBpy-2.0.orig/configure.ac omniORBpy-2.0/configure.ac *** omniORBpy-2.0.orig/configure.ac 2002-09-06 21:34:25.000000000 +0000 --- omniORBpy-2.0/configure.ac 2003-02-28 06:29:29.000000000 +0000 *************** *** 19,24 **** --- 19,28 ---- AC_PROG_MAKE_SET AM_PATH_PYTHON + AC_PATH_PROG(OMKDEPEND, omkdepend, omkdepend, + $PATH:$OMNIORB_ROOT/bin:/usr/local/bin:/usr/bin) + AC_PATH_PROGS(MKDIRHIER, omkdirhier mkdirhier, omkdirhier, + ./bin/scripts:$PATH:$OMNIORB_ROOT/bin:/usr/local/bin:/usr/bin) AC_LANG(C++) *************** *** 123,131 **** modules/codesets/GNUmakefile modules/sslTP/GNUmakefile omniidl_be/GNUmakefile - python/CosNaming/GNUmakefile - python/CosNaming__POA/GNUmakefile python/GNUmakefile python/omniORB/GNUmakefile include/GNUmakefile ) --- 127,134 ---- modules/codesets/GNUmakefile modules/sslTP/GNUmakefile omniidl_be/GNUmakefile python/GNUmakefile + python/COS/GNUmakefile python/omniORB/GNUmakefile include/GNUmakefile ) diff -cr omniORBpy-2.0.orig/examples/embed/GNUmakefile omniORBpy-2.0/examples/embed/GNUmakefile *** omniORBpy-2.0.orig/examples/embed/GNUmakefile 2002-06-10 00:33:31.000000000 +0000 --- omniORBpy-2.0/examples/embed/GNUmakefile 2003-02-28 20:04:21.000000000 +0000 *************** *** 1,3 **** ! TOP=../../../../.. ! CURRENT=src/lib/omniORBpy/examples/embed ! include $(TOP)/config/config.mk --- 1,9 ---- ! TOP=../.. ! CURRENT=examples/embed ! BASE_OMNI_TREE=../.. ! ! INSTALL=/usr/bin/install -c ! ! include $(TOP)/mk/beforeauto.mk ! include ./dir.mk ! include $(TOP)/mk/afterauto.mk diff -cr omniORBpy-2.0.orig/GNUmakefile omniORBpy-2.0/GNUmakefile *** omniORBpy-2.0.orig/GNUmakefile 1999-10-04 17:25:21.000000000 +0000 --- omniORBpy-2.0/GNUmakefile 2003-02-28 20:04:21.000000000 +0000 *************** *** 1,3 **** ! TOP=../../.. ! CURRENT=src/lib/omniORBpy ! include $(TOP)/config/config.mk --- 1,8 ---- ! TOP=. ! CURRENT=. ! BASE_OMNI_TREE=. ! ! ! include $(TOP)/mk/beforeauto.mk ! include ./dir.mk ! include $(TOP)/mk/afterauto.mk diff -cr omniORBpy-2.0.orig/include/GNUmakefile omniORBpy-2.0/include/GNUmakefile *** omniORBpy-2.0.orig/include/GNUmakefile 2002-06-10 00:33:31.000000000 +0000 --- omniORBpy-2.0/include/GNUmakefile 2003-02-28 20:04:22.000000000 +0000 *************** *** 1,3 **** ! TOP=../../../.. ! CURRENT=src/lib/omniORBpy/include ! include $(TOP)/config/config.mk --- 1,19 ---- ! TOP=.. ! CURRENT=include ! BASE_OMNI_TREE=.. ! ! INSTALL=/usr/bin/install -c ! ! INSTALLDIR = $(INSTALLINCDIR) ! ! HEADERS = omniORBpy.h ! ! include $(TOP)/mk/beforeauto.mk ! ! install:: $(HEADERS) ! @(dir="$(INSTALLDIR)"; \ ! for file in $^; do \ ! $(ExportFileToDir) \ ! done ) ! ! include $(TOP)/mk/afterauto.mk Only in omniORBpy-2.0/mk: afterauto.mk Only in omniORBpy-2.0/mk: beforeauto.mk diff -cr omniORBpy-2.0.orig/mk/beforeauto.mk.in omniORBpy-2.0/mk/beforeauto.mk.in *** omniORBpy-2.0.orig/mk/beforeauto.mk.in 2002-09-06 21:34:26.000000000 +0000 --- omniORBpy-2.0/mk/beforeauto.mk.in 2003-02-14 19:34:26.000000000 +0000 *************** *** 43,49 **** # Directories for installation # ! prefix := @prefix@ exec_prefix := @exec_prefix@ INSTALLTARGET := 1 INSTALLINCDIR := @includedir@ --- 43,49 ---- # Directories for installation # ! prefix := $(DESTDIR)@prefix@ exec_prefix := @exec_prefix@ INSTALLTARGET := 1 INSTALLINCDIR := @includedir@ *************** *** 275,281 **** # files. vpath %.idl $(IMPORT_TREES:%=%/idl) \ ! $(OMNIORB_ROOT)/idl/omniORB $(DATADIR)/idl/omniORB IMPORT_IDLFLAGS += -I. $(patsubst %,-I%,$(VPATH)) \ $(patsubst %,-I%/idl,$(IMPORT_TREES)) --- 275,281 ---- # files. vpath %.idl $(IMPORT_TREES:%=%/idl) \ ! $(OMNIORB_ROOT)/share/idl/omniORB $(DATADIR)/idl/omniORB IMPORT_IDLFLAGS += -I. $(patsubst %,-I%,$(VPATH)) \ $(patsubst %,-I%/idl,$(IMPORT_TREES)) *************** *** 336,342 **** define VeryCleanRule $(RM) *.d $(RM) *.pyc ! $(RM) $(CORBA_STUB_FILES) endef --- 336,342 ---- define VeryCleanRule $(RM) *.d $(RM) *.pyc ! $(RM) -r $(CORBA_STUB_FILES) endef *************** *** 664,676 **** CC = @CC@ CXX = @CXX@ RANLIB = @RANLIB@ ! MKDIRHIER = $(BASE_OMNI_TREE)/bin/scripts/omkdirhier INSTLIBFLAGS = -m 0644 INSTEXEFLAGS = -m 0755 CP = cp MV = mv -f CPP = @CPP@ ! OMKDEPEND = $(INSTALLBINDIR)/omkdepend RMDIRHIER = $(RM) -rf CXXMAKEDEPEND = $(OMKDEPEND) -D__cplusplus --- 664,676 ---- CC = @CC@ CXX = @CXX@ RANLIB = @RANLIB@ ! MKDIRHIER = @MKDIRHIER@ INSTLIBFLAGS = -m 0644 INSTEXEFLAGS = -m 0755 CP = cp MV = mv -f CPP = @CPP@ ! OMKDEPEND = @OMKDEPEND@ RMDIRHIER = $(RM) -rf CXXMAKEDEPEND = $(OMKDEPEND) -D__cplusplus diff -cr omniORBpy-2.0.orig/modules/codesets/GNUmakefile omniORBpy-2.0/modules/codesets/GNUmakefile *** omniORBpy-2.0.orig/modules/codesets/GNUmakefile 2002-09-06 21:34:26.000000000 +0000 --- omniORBpy-2.0/modules/codesets/GNUmakefile 2003-02-28 20:04:21.000000000 +0000 *************** *** 1,3 **** ! TOP=../../../../.. ! CURRENT=src/lib/omniORBpy/modules/codesets ! include $(TOP)/config/config.mk --- 1,9 ---- ! TOP=../.. ! CURRENT=modules/codesets ! BASE_OMNI_TREE=../.. ! ! INSTALL=/usr/bin/install -c ! ! include $(TOP)/mk/beforeauto.mk ! include ./dir.mk ! include $(TOP)/mk/afterauto.mk diff -cr omniORBpy-2.0.orig/modules/GNUmakefile omniORBpy-2.0/modules/GNUmakefile *** omniORBpy-2.0.orig/modules/GNUmakefile 1999-10-04 17:25:21.000000000 +0000 --- omniORBpy-2.0/modules/GNUmakefile 2003-02-28 20:04:21.000000000 +0000 *************** *** 1,3 **** ! TOP=../../../.. ! CURRENT=src/lib/omniORBpy/modules ! include $(TOP)/config/config.mk --- 1,9 ---- ! TOP=.. ! CURRENT=modules ! BASE_OMNI_TREE=.. ! ! INSTALL=/usr/bin/install -c ! ! include $(TOP)/mk/beforeauto.mk ! include ./dir.mk ! include $(TOP)/mk/afterauto.mk diff -cr omniORBpy-2.0.orig/modules/sslTP/GNUmakefile omniORBpy-2.0/modules/sslTP/GNUmakefile *** omniORBpy-2.0.orig/modules/sslTP/GNUmakefile 2002-09-06 21:34:26.000000000 +0000 --- omniORBpy-2.0/modules/sslTP/GNUmakefile 2003-02-28 20:04:22.000000000 +0000 *************** *** 1,3 **** ! TOP=../../../../.. ! CURRENT=src/lib/omniORBpy/modules/sslTP ! include $(TOP)/config/config.mk --- 1,9 ---- ! TOP=../.. ! CURRENT=modules/sslTP ! BASE_OMNI_TREE=../.. ! ! INSTALL=/usr/bin/install -c ! ! include $(TOP)/mk/beforeauto.mk ! include ./dir.mk ! include $(TOP)/mk/afterauto.mk diff -cr omniORBpy-2.0.orig/omniidl_be/GNUmakefile omniORBpy-2.0/omniidl_be/GNUmakefile *** omniORBpy-2.0.orig/omniidl_be/GNUmakefile 2000-03-03 17:41:44.000000000 +0000 --- omniORBpy-2.0/omniidl_be/GNUmakefile 2003-02-28 20:04:22.000000000 +0000 *************** *** 1,3 **** ! TOP=../../../.. ! CURRENT=src/lib/omniORBpy/omniidl_be ! include $(TOP)/config/config.mk --- 1,9 ---- ! TOP=.. ! CURRENT=omniidl_be ! BASE_OMNI_TREE=.. ! ! INSTALL=/usr/bin/install -c ! ! include $(TOP)/mk/beforeauto.mk ! include ./dir.mk ! include $(TOP)/mk/afterauto.mk Only in omniORBpy-2.0/python: COS Only in omniORBpy-2.0.orig/python: CosNaming Only in omniORBpy-2.0.orig/python: CosNaming__POA diff -cr omniORBpy-2.0.orig/python/dir.mk omniORBpy-2.0/python/dir.mk *** omniORBpy-2.0.orig/python/dir.mk 2002-02-18 18:48:14.000000000 +0000 --- omniORBpy-2.0/python/dir.mk 2003-02-28 14:21:34.000000000 +0000 *************** *** 2,18 **** PYLIBDIR = $(PYLIBROOT) INSTALLPYLIBDIR = $(INSTALLPYTHONDIR) ! SUBDIRS = omniORB CosNaming CosNaming__POA - ifeq ($(PYTHON),) - PYTHON = python - endif - - - Naming_idl.py: Naming.idl - $(OMNIIDL) -v -p$(BASE_OMNI_TREE)/omniidl_be -bpython $^ - - all:: Naming_idl.py all:: @$(MakeSubdirs) --- 2,9 ---- PYLIBDIR = $(PYLIBROOT) INSTALLPYLIBDIR = $(INSTALLPYTHONDIR) ! SUBDIRS = omniORB COS all:: @$(MakeSubdirs) *************** *** 25,31 **** @$(MakeSubdirs) endif ! FILES = CORBA.py PortableServer.py PortableServer__POA.py Naming_idl.py export:: $(FILES) @(dir="$(PYLIBDIR)"; \ --- 16,22 ---- @$(MakeSubdirs) endif ! FILES = CORBA.py PortableServer.py PortableServer__POA.py export:: $(FILES) @(dir="$(PYLIBDIR)"; \ diff -cr omniORBpy-2.0.orig/python/GNUmakefile omniORBpy-2.0/python/GNUmakefile *** omniORBpy-2.0.orig/python/GNUmakefile 1999-10-04 17:25:20.000000000 +0000 --- omniORBpy-2.0/python/GNUmakefile 2003-02-28 20:04:22.000000000 +0000 *************** *** 1,3 **** ! TOP=../../../.. ! CURRENT=src/lib/omniORBpy/python ! include $(TOP)/config/config.mk --- 1,9 ---- ! TOP=.. ! CURRENT=python ! BASE_OMNI_TREE=.. ! ! INSTALL=/usr/bin/install -c ! ! include $(TOP)/mk/beforeauto.mk ! include ./dir.mk ! include $(TOP)/mk/afterauto.mk diff -cr omniORBpy-2.0.orig/python/omniORB/GNUmakefile omniORBpy-2.0/python/omniORB/GNUmakefile *** omniORBpy-2.0.orig/python/omniORB/GNUmakefile 1999-10-04 17:25:19.000000000 +0000 --- omniORBpy-2.0/python/omniORB/GNUmakefile 2003-02-28 20:04:22.000000000 +0000 *************** *** 1,3 **** ! TOP=../../../../.. ! CURRENT=src/lib/omniORBpy/python/omniORB ! include $(TOP)/config/config.mk --- 1,9 ---- ! TOP=../.. ! CURRENT=python/omniORB ! BASE_OMNI_TREE=../.. ! ! INSTALL=/usr/bin/install -c ! ! include $(TOP)/mk/beforeauto.mk ! include ./dir.mk ! include $(TOP)/mk/afterauto.mk --------------000307050801030307000706-- From lockhart@fourpalms.org Sat Mar 1 01:29:05 2003 Received: from myst.fourpalms.org (dhcp-78-180-241.jpl.nasa.gov [137.78.180.241]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h211T5830342 for ; Sat, 1 Mar 2003 01:29:05 GMT Received: from fourpalms.org (localhost.localdomain [127.0.0.1]) by myst.fourpalms.org (Postfix) with ESMTP id CAE1D35398D6; Fri, 28 Feb 2003 20:29:08 -0500 (EST) Message-ID: <3E600CE4.4050503@fourpalms.org> Date: Fri, 28 Feb 2003 17:29:08 -0800 From: Thomas Lockhart Organization: Yes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Duncan Grisby Cc: omniORB development list Subject: Re: [omniORB-dev] Patches for IDL stub generation References: <200302281733.h1SHXBl04661@grisby.dyndns.org> <3E5FB19B.3010406@fourpalms.org> <3E600B78.8000900@fourpalms.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: > Oh, the patch file does change some files which you indicated should > stay fixed to allow building without autoconf support, but I'll defer to > him on exactly which files those are. Tuning the patch within the CVS > environment is much easier than working from the distro imho. Oops. "him" == "you" == "Duncan" I did an incomplete change in person when editing the message. - Tom From jwaller6@yahoo.co.uk Sun Mar 2 23:40:22 2003 Received: from web13008.mail.yahoo.com (web13008.mail.yahoo.com [216.136.174.18]) by raq2100.uk2net.com (8.10.2/8.10.2) with SMTP id h22NeI806620 for ; Sun, 2 Mar 2003 23:40:18 GMT Message-ID: <20030302234021.32569.qmail@web13008.mail.yahoo.com> Received: from [24.244.190.70] by web13008.mail.yahoo.com via HTTP; Sun, 02 Mar 2003 23:40:21 GMT Date: Sun, 2 Mar 2003 23:40:21 +0000 (GMT) From: =?iso-8859-1?q?James=20Waller?= To: omniorb-dev MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-224614406-1046648421=:32537" Content-Transfer-Encoding: 8bit Subject: [omniORB-dev] Implementation Repository Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: --0-224614406-1046648421=:32537 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Id: Content-Disposition: inline Hello, Here is the first usable version of the Implementation Repository for OmniORB that I have been working on. Presently it has only been built on Linux and most other platforms will need some porting work. Some features are as yet unimplemented and will be finished in future versions. I look forward to receiving any contributions in the form of code, comments, suggestions or (constructive) criticism! Cheers, James __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com --0-224614406-1046648421=:32537 Content-Type: application/gzip; name="omniImR-0.1.tar.gz" Content-Transfer-Encoding: base64 Content-Description: omniImR-0.1.tar.gz Content-Disposition: attachment; filename="omniImR-0.1.tar.gz" H4sIAHaUYj4AA+w9+XPbttL5tforUDvjSIklUYelN3LtqWM7qV59jeSk7bQd DU1CFmuKVEnKdr5Ovr/97eIgwUOHU0nOeyUmE8k4FovFYrEAdlfu2LG6415Z q9SqL9aUNK2ptff24FOrtfc0/NRqzSb7FOmF1m41tD2t3W7D91q9Vm++IHvr QkhNUz/QPUJe/GGNb9ybefWo528Coc0mV5n/c/2ODi2brroPraZpLT7fWfNf q7WaOP/1vXqzobXaUL+x12q8INqqEclK//D538ZEyEfds/Qbm/qEsJxCof/h 7Um31+8cGO547DrE1Cl+WGNPN8eWQwLqB4XC9mqTAEjIte7d0iDCpnL1w+XF Lx2i2zZ5WRS4lYhhUx1Qs/yAfSsUoLyjVCgUOPadwjeGScRIdnagxvnRj6dQ LIfTEYWsXjhGtSYff6yeIIlaC6ki64hyVhXzYxUZvoDW90PXIxaBziKs94np kt8K32DDly8tpR0f8L4srFTYV9N1KCAoqfB0qGHTbMirnuTn5vk8RUmV/5Zj 2FOTrlwPWHr/r7dqtXadyf+mlu//m0hZ89+n3j31rjz38dPV5VFl9Hf7mL// 12D/byjzX4P6rb29dr7/byJVq6T8ukzOXZN2yPGbN/v4Z2HbGjomHZLBoH/a +3jau+pd/vwL8MLgh8GgsA0llkOzC6tV+EeSHEQy0pVu3Om30KtgQWy3VDqa BiPX65B/62PQV36CLZ96ot8T6hueNQks3PIFKvp4YlPiM4zKvmVS2N8hZ0yd QMeKxB1KFDodjjhsnAH1hrpBCW6kMITyje5TE+FxQH4FwQOd+JIh3/mBZzm3 ldGhkrklwFZGWwWovtIEAF9jIuRED3TSD7ypEUw96u+S608ToMsOObZ130eN jlWsos4BGYm5IR0ymd7YloGjHCToUPirwAs7BSS85dg473EARcN1QLcxRrCK XjswJbtIPbIDCpyxK7Jf41/3u4XZc3p82Xt71OnA/4N7aOF6N7vRpPToxPWt wPU+sUJQz0r7BQbs3vKCqW6T/0/glCyPxgVzPvWJR3XzE9ZSK927Fuh0VDcC 614PaAhEDFsdJ+imFzDUYonn7qv1EkOBqvBV9iXqzBoaVIbsJ1SGznXHoN2T WW04YWT9c92BJeexoU08N6BGQM1Omgo+dcwr4OdiEs4k8Fgh9XblQD+cuc4t ebTMLHJ61LhngFKVyV+f51H/wg2s4SeBKMsRaGI1y7GCJ/BdFncleHEBr8VQ SEAbADg+8llABgAlUUOZlsGYTwqvwREf4IBiGZaY6YFl7hc+769RnrybOgbK RUVwcKYqxBeZHMRsQTBnvRPOq3K+FtVcVoyQjPnJmO1Umjf9IAQ5ssBznM84 i3HWYpKKc8nnNUxKkuQpQSewi4sthQp8XxoMPUqLjKvmFCs8tqbh4OpNjSl7 NWdP2SKWWYJRlmaPJZgC1z45IKEEwJUOf4frnVEcMuLUNqeTojIVKt0z625t RVtRQMb6I9RCGpAyqe2H+Rb/euO6Nrl1Aw5sqNs+FY1RlSlakKmRfWKR7xik nR3yrai9T968sUAuh9SwhqQIaBjjSRHp+av1+y7ZKgNJom1nq0QOAKDaajnu UmsvJADrHZD7PdGQE+GA1OPZ4ehBKaJREd9vPivEiMiQGjsfMFC4/junNg5/ X0BYx9JIqCipVSJUFsF4WRtJAPM0CEaWXyxJfhGk7HNSMuZ1vSJybfnQvfkD tv9B4A44pYvQvlRK7lNSX/KndgCEQAYvH8r56jGcBlwqqrO4i8iETAtsJAEc KKA/HB+f9vsq0eVWiFM3nuyr8+VR0G4dgcgGhZMqWOVOAOP5VlDW8geOZRcl 4qWs0ZQPs9SajDEnJrXTYbBL6+S6zDEvo/3N3lFTmt5ssnFYMaLxrPJhqDhG iuUGKZCeMCnwF87psvPJF6E/mgam++AUtTXtuBmHl9RoE6cZMVSx4oQqukbc 4htyFnbsAJVAi+25a8Rqxu6fhR47siXQYyrAJtCLNoAs1MIDXwK98MyxDhS3 YQ3Daq9WyWAAiCi3ROyK6LmvvPKkJPX+F1b/0LpdvRnAE97/m4099v7baLXz +/9NpIz5xywQXxX8cyV9LHj/bzZbNTn/jXazAfX32jUtv//fRNoubMu9RL5n czaYevx2HA1CKlDpDHYdn9zQW8txQC8jD1YwItDWg7OT7lFi3TquR02oGj7i H7vj8dSxDA4INoWJiwdVdyKul8Tb/q/Xnu74E9cL/N+hLbmCb8SZjm9AiQpc 6JIA7U12YsMDhql7Jrk+vgoBFuAPbHMAbKMtANDvn0WIFB0XdKKp51EnsD+R B9e7g5GVCttQSwD8FwP4wbEeie8adzQgEz0YFTDjCr4cVOGcUpVrCMb6WOXV kq10w6C+TybUG1u+z4ZfdI1AtyWePl4U6D6oaGOXWyrASAl9nMAZzSdlAGe6 zivo3sZXCZ280l7h8/7Qc5GiQ2IFJY5V1MNBW2PYn4rx+gRm4WFkGSOkim7b 7gMx4MPHP4NRpsoTvYQAoKKLiodHxjDR2OdWYEy2dsmW79tbBNHdQgpAjk8n OrAP0PzmEx+LXyocYYdHaFdxgNUKIZuc0KGOh0P+skKw6ZgGSBMaBDAhCqeI qpxP+pIZREOhjyOvAQ0pTq831u1dok8DdxeO+Q57CvBwFsoe/XNKfSDaUdgK 38AOeJsYeAVuYI1p2Z0GCMKCeSrCFIwt27Z8CqvG9FVw11AXqh7saXwaQnjh yWE5iCdK9ZkwJ7gkF8PCE9VMGJd9XCdsyXhTRz50IVMWbarfU3Jj684dW0Zc UrzyWQNgPPj/IAnr1nOnkySwKZ7u5sBjjUqF9/hxELHIOSwe0FeJ7d5mcMWZ ewtS6ZYxxbupbbM1ij1jdZRf8EUIoaJpwcmScfYYJD8sMAuZYDtkQssnVdCl q9BUruvCNnTAV/vIHdMq3ymqxps3VXZ0qap7qNw8oT2iIxH3KQzfCj4RG77w FccXoM1x5/dRqfXlwcLb2gU4Wya9md7iYrOcoYufD7rn4Cf1PNcTy2+og0SZ tf5gEO8sG9bVAYLYxfa7rPEua8aw1R+t8XQc0c23/o/uAsNy2sCyBSGCwv7m U0D9fZx9EEX+dDgESQcI/4jj8kFkwXkYwN1Ztstq7pJzNsAxvdVZBkP3Pcu7 tUReAXoHHPvQJfDmjwWxMQGFgS8Qo7FkAiQhKWpwwnZcmQt9NDEHDcRkVqkA ja+RhmfY5KCGMAWzCCh6EElEWBQTWDxRp3AuVzv2I3DuLYfIJihi00uQolli 69zyjTR3erCX+gFwIiM13oAHugUbg0nhE3gEqcPrUNhY5RJKMisNDMmAVQmx sN0T35Zl27BlEkmdY2eFOwfsE+Fq7V72QA+A2rDFPgB7BxRWGN/edRsQhfJl EbBcrxI8sn0TmyA33VhwjESxBliYJn5c6GPMwHOuZbBLDaQYZoUo8VtNoNsQ iObwbUuoJngDlYBgoUTS74HcaPxYKuA1iCg7dYAcBz7/w692xxMbt8X/tdOr OgdopLgOI/Dl7b/aWgPPArWG1s7tvzeSUvN/aoxcfpG0MlZ40vm/1sTzX62R n/83kubNf/QVpV8FBPeX9bHI/r9e22P2/61Grd5otF5oda1Rr+fn/02kbPs/ bjqXnv/0a8+GrPi6KZO9CLnojJo0yqOPBmVgDpVMywVFh+rjmKVeYqhosDf1 UVPwA7PTMUA13FczqGPa67DBEQ80cWygO/g7ZiEBI5A3+jwjfKBNP55j3cyX 2NirfTDy4DTCBnejmwM8nBjR0+OGnmCfezH8A9Ny8r9imfaX97FA/msa2vy3 W7W21tJabbz/bbe1Zi7/N5EiS+dotoVk4TKEMOED5z/xJxcnn/fzxfo/kZZb /+dwzF6X/lerN5uh/0ervtdk+l8tX/8bScvpf3L+n03/Y7cxhD/bsIcg7tUh uZd5ZzB8xTVZ2j3DtK0bdM+I8vhdUGUUy8z040hrh5k+HlFm0v9lnf4f57rh uczfw2UGeIFiuM2JB3jcevoYL7tBgYSZ9rGAOtOxkPTCFA9NQ7lhV/e8N/hw cfTxqHt29PbsFApqvOCin8iv83x0HjnunR5ddy8vBu+g+EMPSxthq97peyW/ GXUDjU5+UYr2Nm7djk99eP0nrbRwLGhOY8ApIaA492hpPaMW8Vw3GExcXerj yXpn1pD6E925cm3L4AbEtsiCZpgHg5ZAyoehQs57HyTqptE47fW7/evTi2up 5CdrdM0j37duHTw9KUhY5jLdQy09bD0Lhw/9096ge5IwOuV9nVlwaGHtLOqL CvLPik2d22BUrItzhsz/VUOb2/mE7HTwcGPj4zItJoiUBFfLApcmSwxkSJ5Z ZJXzj+oR0k5UQzEVnapkYYzGgrTIVEyybC10T4ikbRoJYeEljQuXhyXJIw95 BMZtjIj01DmVZ2eyo54TUYYUs1Z7/KyYmBE0lwTJ6oZWkiF5YyWsCATWkRO+ ulL24gAdFlR6lg8hdxCNvlgqH6b8tsR5NZqgtZmPylean6xgxHcV8YhQPHZ9 ntHp8E8Q0gF9DBjrGPz7Mn5x3Fab29969yDkpbiJd0AJt9ZkRfhVLrGaoDvm wfKqMPP42JVCSd3mtuK17ywnq/5WJs/H/8Ikxlk+xBcd4UMjh6GY54cMOINm nc6Rzazg37pTwGcn6XQQduPR+R09md/j+9dazZHRfaNg+T3BUWgBjTpPlssL nwfmmvC7ZAfm/RFeBqW9P9BPBHdz4QHCHCgy/T6+TTt+AJdvlZJED/uK+1ow XGCy7ma4X2zAnB8tg8agtybpl0W2tE9QUcliDkqR01cpklRSYL2nAZNTiWvK yI5GrT/HryjmmyUWvXDtGLg3f2SvN17G3ZCQ+X3XvqcMaUu3B+FLqF/cko+Y W8pq4B5LGTjhjqJ7nvtQFD0sv1F8jq4b4wb/6DqVWl0JZTO+kUQ07qNVF1q3 IKFxN8VdgRkSuFOP6/5ym4Da1yP1RgMtFXyC1gv4po/tmPka21pCBYrBErpM pKOoWDyB1D1AEPqRlF6kPWapl+kJEMAiVWKJXXCR3gKDiSu6oUKb4vJjVo9R TSGtELCMeuGmDQeNkMKJqWEf8ROVhJFNK74OuiZfmrhzhfyTrCquvQN3IBsV 1V1NDilSIyTCA+ENhUiD0lt00YdpJ9o7Mta77hA0UEBzopTVAZO2OHZJHG48 YeiMDw3bonhMC1wJ7xblBxrhWb60ZhNMZX8i95Y+X7hUIqaH9vCPGfMlUQpG aOwirDWYW78/osysQuAzg9WZxxfzNeeD7UmIMdKGG20lckGLTzSbPlEJQRej okxOTy5/INF0QiZ4pg7JilZ8lsftnJaWv4kACAxiYiwzPHxDqRbfoNWtQRFu orvEFhG3QHnlc1EmdJestnNVSLZYjeBR4JbeHZ4othQDGHWTCKUOdIWPTDM1 tOwtY8ltQxH7ktDx7UOikNJCpJaW3kYSMONzIidxzkJmUiw+Z1nAZp8AJM67 Ku8ryMXdwGrhJktBdZvJTNcUlvFchufLXYogHKJPHPeBS+jMISR9Pn3+ccAX SCUMmRGbH1Hp2/l+neEUpS58smeJs+nUSTxAsuzEQVIokqLT/FXyqekJ9h9f HAdqYfzHeiO0/2hqbbz/r7Vb+f3/JtKi+E+nxz9ccge+7vnVWSL+U0ZhpuXI c8Z/+iLLEUUbWM/lPQ/FlNCCw1BMMiYO6uqxZ1k1GpOsxM+zmSYia4oUo/p3 ZrDAc7N0np6Q5sn/VcUDXiD/61pbyP9mq76HtqC1VkvL4/9uJLGAuYqMKUgR WKlU4d/4rsqD2VbGd+uL9hs+YabDEG+Td3CUlo+slmkXPl4dXf9wwNHDvwuw a/V7x/3OwW+Fb6KR9H9kD9aQJxpHGRl2jbFc+dpdKFy+/TfAfVlENzl0pJlM +VWBv0teFkW/pVKh0L04PvtwcvoGUSh3BW6ckM8TIzkVGFk5bAPqOK5S4RsY w88/l0jZJS+/l7nwedYV4ZXZ174Srdgbk/IwrGm4Hn2tBh7m3cpqyj4bn4Lw yTxdU9RQt19i0olfhty1suAJnWDkEQfv/EKKghZE/yRFHib5+Pzk/eXRWb+0 y4dZmlkcEqQUhvVJjrwTY+nCXAKo65NXl2s0Rhm+KW8rky5zBAusmnTPLbry tIKUuf8fswvBZ/X/0HL/j42kefO/If2v1mrWQv2v1dhj8Z9buf3fRlKo//E5 /0r1P/+O2jSA47vvTj2DVkdURz9yZE4/UghVNTapFPLhSV0vVrma3H3/ht6n orAuaj1Z7+Nj36jex7v871bd/hFa1jz5H183X97Hovg/4fm/UavX6y30/2jW 8/P/RtIi+29FbmamzUbx5y/V+CLFDJrxyVy371jwhmUtwSP3v6TR9wzb8A3e Cj+HydLc92hm1GG77h0+vcftPlRwSz5Rq2hn2DZhcYa5AEYp/HtmTzMetb/w QXvGw7w0vZSlWdaXMn95C0y1xQIrzDhR5OBCyqgRpzGJZ+EDheTrsPjKfLLn TrXU88h33/FBSxUlEZ9DCc6xhXUV51sJi70r1+IPxWk0+GiXREK5uMIIYUoM lgxrgK3YK/fyOEYrEa8bcZFNSJnFCZsEGFSHe9sNPXfMFh6LzISrkamkCoYM JUsYEQM07IvFZxtRJ2pJ8aELw+4QOp4EnwR4FZGHEYtCg2acKSoJZCwH9ODB zXS4Hy8GbRRjkhY5RS1nN6q5S1795rxKWg2ExRWGTTFlz5EyHZ1j3ZKOcQ3o Al/zKS8fCv9F2aOB4a5D86Q4M6B1ITKDWBuwciYuaJZmhwju82ZM8JLGLfPZ jgVjYgGQhZ+lCH7DsYnz2WxeyzKz1XK7iDxlp5T+f9VbeQSYL7j/a2q1/P5v E2n+/Kt/fLkN0KL7v4aM/1pva826hvY/rXb++28bSYvsf4AD5lkAZRYLr9MU 7yQ3MPIPNwL60l9wS1L2iYZDIoJ8EkoxfaIsAWQMtF9k3//6HP9RtbmGR0v8 ZNbabZMymfO5F9xXlp4o/7/oHnCR/G+2Wor8R/vPmtbYy+X/JtK8+7+s2f+v kuDfTR04uZuJaA7pjWmdwl0GHMAoDIEbMMkeyvOsn5xcOSYiqFhy2KsLK7ac Q8IDZaGDo+jX4v4h4xc3AeBbvAFg7n4w1QgYECD0Hm9/8aqEVcv4CR311JsH KlsiLS//vzwG0IL4P3DkC+O/1jQ8C4D8z+0/N5OWlf8zIwA9UwAgJYY/wbDY qU1htRGAsvaMf2oMoBmxfuozIgR9fTGAFCsTSaSET+hr5vOWxyEieRyiPA5R RsrjEOVxiPI4RHkcIj7ePA7RPEqylZnxM8JMxVB/R7a4tp+AzQMh5YGQ8kBI X2UgpNRbjoDCnlzyeEh5PKR4PKQ8+FAefCgFbMPBh1YQiSsBlIM6IA59SETn ekJcrjSim4+ShPz9fGGSMJnoKEWJuL9SGuTBk/KUkea//6zGA3TR+3+7vRe+ /9QazP9H28vffzaSmP+nOudfqQdoPI4Cqtgpr82FfqDzvT7TfqGpwCGZBhGJ /BUED1HOFF9tPBF1yBvzLFU7zX1L//4oX2TI/1U5/StpYfy/Vj3x+6/NvUYt l/+bSILP02K3/4Et2c6B4s6trL74lrFqxlxGJL0sChRLaenEdrWoQtwNXkH8 G8NU3dV3dghftaVYwKSwmhi7Wi0uBxOgY/JKbSWl3/d4L2Lhr2tHyO4T00W5 jwBevrSUdnyc+7KwUmFfTdehqsh8MtSwaTbkVc/tc3N8ntQU+w12017Hz38v 6/9TbzfqWrPVBvlfb2H819z/Z/0pOf9KWLKV9bFg/2+10OeLxX/Q6o0azn+z 3cj9fzaSIk+fy/OLLl48dU/OYi4+8XxuTbZMyjIMVLgruxF/WTGJC6p/rVbV 6n/bnHD176lj15xGvz0oHk7Dn5omp4/UeKdb9tTjF4iqL7XHPbN18UsXn8OH lBWiF8fmrW5e6Z4+fjZUokeiHn+iZ8aH4uqR3xd70X3sUJrFxR5f0EyR8AvX xDjE1WVkktD/2BtcXF6jnUQ8M5VxdHzd/Xh03b3Iyj+N53Uvkrndi/710cXx aap6WHDSPT2Jst8enQxkUZR73T0/vfxwHWX81Lu8eD84vzw5Xe+soB8CLnsf TWgdg8oQKIS70ffpn/vZ9fg74iHhn6zeuvkmdPIAtXbMb/An6BcHvAMiBhkI zgjiUgbqFEtZDBXjJ5/52pGoTfbqiAf0CClDjLE5QBe6rLIJLjY/q4S/KQws ZqBrUD++7lKEjpA7VBDdJMH5q4ziWyOK+atq+LvRI90nwYNLJlMPqE79jqxX q0QPL3yh80cWfOjFE5z7sOhxJnwPhjTBGcF7Pz9wJxJSiNN/2Hv3t7axLFF0 fh1/549Quc8kJjEOkNcMVHIuAZLyNAEOkKqum6rPV9gyqGNbHslOwnTX/O13 vfZTW7IhgVR1o6+7gqX93muvvd5ro9RXbdP3C72mvBsReVZuWf1xJI7C8leB FibZLB2iYSb+gHumgAuuoFHh8FysBgOwmivQKM4sWjaxtU5FOkgcADUFrWA7 Bj6BL/sUX0bkPYTxIo7YPEttHL5KcozCEc0naFuaYBAfWL7P6cBW/lmt5En/ o2pl2TrGcukAl0VrlW7hKkGjFjRpqgGeEtx6C+tpJM3iMmaLghp+Kw36x7zH hn3w7lArbq2lojUKtVJUNIMmPRqtYmOFrUYUfaPS9fJWh1py1InlB8GkhMna 7mtGYisLWsrjFI57S1EYgcECFC4abqCWwpDHpEqtWHIdkobL9tLBgonz+uq7 hKsFegfqDmCZy+1k4zEc7qoxOOuIy7iyVdcarVJw8xcsdGnbZH/qdkBBn3Uv 2isgdwldquVRq3NdvWuqa4vYLTdjEEQ1tOLE0FgUBXhwv/drm1HY+qsBhVra 0Ah+uwUPdZe3+hb8n83/jz/ciPhn+fgvT56urT9F/e/G0407+c+tPN7+a1Xv 1+xjUf6Pp08fi/5nHeCE5D+Pn27cyX9u4/na0n2lubH829SHaDfJgQOK4miE zljZUBm8URhnDnVnvnGkZwnxbGvPX/zvVjwYFPPhMP0cdTJUpmPQT7wE4M/1 FVSp39Ssjue2iuzfOtlm9G+k7HcV36v9iH6/3t9+Q0pvUfHjn7t7r7sHe/j2 e2zhIvo3ti/AljC5A7QEtwFV2t1XDXz/TSwv8HbqveoebL54NC/yR6OsH7OA +PD41eqTzlpn7dFZOuFiMMOaYsp2gYrud1/VFB2lZ40GTB0tJ9QAVqgMro5a k80Xq2f9z5+j1Z/OLl7AIsK/xQsVvTsdIic9SM7m5w21C1DhvCFrD3/v9nb3 Xr170yBDxz+Vyx5u2IUPpLDSz1NpXfzhC+h+kq32gZlYHeB/KPZN/7Kh2sAS u73jvb2D0+Ptg1P80Uv//VmvR38B5Tj/LH8fnvyIZviHB73eiw1tGgJj6Mpq wJsVtgqxXqglfCL2Io2GGFxAxX0pB29W6D2+HE1nF2ipGK2OsGpRjE6P5G9s 5uagDUi6ySDOByXN7p+ik2nSB1o5ukC5QAbs3YcEHdLRRMKYYCA6aFhGE5uW KU3jX2fZvH8BB7Dxr1ibK0arP0erQ7JGsU6hqhNtvHw0SD4+msxHI22M8v90 zuIbsCn51qg++Dj6n3EeD8bp5GtTgVeP//f4+frjO/rvNp7g/n9lG6CF9p+i /336GOAEc4GsP3389C7/x608ZCmjNt6x/fzmhp+26aaSIymLSyNZUm+KZNYf D6xfLCRRL5CsVH8rcYJpzH+jFuQqhpxiP8prhmSMrF4csPDkT78TU0412Vsz 41Qd3plwfvksv/T8B/G/fba+Ao5ZEP9p49naBtv/PH3+9Nka4v9na0/u8P+t PHXxnxwUW/HcRPinCP0Op5d5en4xi1rA72ysrT2uKEjKSKRV0HULUL6OF6eR jCQL6dh1yp+x+jBPkqjIhrNPcZ5sRZfZPOrHGBwAT3Oens3Znxc4mEdZLm2x gB9fz1HpRl3Dko0LNY43B++iN8kkyTEsK0dp3U/7yQT4zrgwfqfSnCguX+NI TmQk0WuMM0EKrq0oSeF7rkNebahupE10i5OmWvEMp5BHGVmCrMC4L6NRPDO1 O94yWkthZjxA+Tj2cJFNxWk2NX6zcCqG81FbjX4+i37qnv5w+O402j74Ofpp +xj53Z+3yJMRtQ8YwU+2ZzpKMaNCnOfxZHYJ85BG3u4d7/wAtbZfdfe7pz/D hKLX3dMDjE31+vA42o6Oto9Puzvv9rePo6N3x0eHJ3sdYCwT8seWNmoWHW1j xxkFIpzF6aiwFuFn2PAChjkaRBfxxwSVokn6EQYZw402vVy8o9JOTIpTcfs2 67qFroCTbNaOPuUpuo9n5b2WFsyOt6PupN9pR0//IzpNKAfO0QjVl6vRyRwb efx4rR29yooZFn27HUVrG+vr66vrj9eeq115d7KtJrlUYE0cVFOfD4UEmkj5 oDaM2loun87CEGlU7jT7kEzS4maiLF8tEmeGYaICgZDbdbEqXB2TDrLhxtf4 +pqk+mBi6HEKgImxPwArFolWPoZiuNgjdb9Y7q5K+XhPaYf/pjTqUerEdsEQ crVxXeycIv153oNSKr6L7zgrn6MXL6Lm6mrT95aFhhfEevEMcTSsRTPVtqVw lI1/t4/nd4JOvcxDSPAiq6T7YRI9jDbsodszRMF0a9aZJJ9nrfsv7q/4U/xu 1kF81FpBm3yKlVSRFAWjIFLyFjmIEYXxppEkiNVXo/R8kuWJu7XZZJZO7JA4 4t2NXdf15uYpIfnrGK7r4hIwxWfJVYLXp+6+IPmdMo75pRlMWKL2E9v8pbkJ 6JCmDFfJEHEyrE9Vnh98nDw6PJfwmn+MR3Oz6L+suavOm/d+guHYaAkkJ4y/ ve8fPqQy1JpbyA0flN6E67QOHZSpSAEhxGSvz7I4KogEQtGAEEboCH8P4F2Z OsnwjwcqWQ1vqkBEMvjO3VRnT7GF0/wyuq9vHCpMA1n7lT5Hq6sXyWh639zd li1g57oJmAKozTbeC3x27f5UDCsbvdJirUYbHKMAsUJbG2vADzuIh2BHe1lV +wqtSGupDbs6fNYkiGbb8J9JKSCZtMsQ70VPE8RbER8rHO4gGH5JR0KgACme 4Q/1sv5r27I4knXxYinpDpVRS3Qv+bwM7HGHOWOfIVB2Om1T8rmDds51oPH4 asEHq8bAWBFRLgqUAA9VmqctDbQbLtAWQFXi+Hix1Zj6cZGUIkts6obkUgwV ZcPozYUzk2MNWF0fzvVfBYsDvUtRL6xEaUtP77GC7UEyjOej2eKRzCcfJhi7 ita6NincY3fp4Pp8zbsDPEiKhngkz5mO4kvCJ06MIjG55EOCssMeAO77x3h+ /hY18UUTQ9GN4L9raCmEhXWxDSwma8SfhLBUIUva0eO2Ln4jUd/U5YF4U18f fPDte/Ie9i/I3k2B9q4grt5FylCaEfL3nFTjYPvt3svoPTBk229Pfo3er65G 28dvTn41229vT/gOwPZ0KJyYQsDwBrTpEhlEpqu2CaXlHqxwf14X6ui1hSGm WFJ8RV2SbbG2vUYmSNM1RdTi+a0s0QuF/nLacWg1gIn5mEJdtXCdVjokilBF EGkVS3QC10esDqReELpwzVIhD18+lp2rbgzPvI03lr7M29F4XlDQqEKZccDU 1M386QK40mIKLOrqElMpElxnFDJU0JGFkj7gfR/hzF78uL3/Djj+7jCiv5ZZ sCIaJcNZdDaKJx+oNdNbiia1BYcbS8ncm/CQ0HzR9uRymQ4mUBz4R1p5WAka mIpuNrO2GDrBXb7yPiC0+LuAO+yA2tfYBhnoqgeuMdz88ylLbHChBCvcXwZc f2miaobb/cVIEXADcVo4Dz0rXCze70E2Pxslq4O4uFhqArwMgDOSZMCDVJPi Xsi6SIGzALDhO9LZMltyM4j628p/g/J/W/31FfpYIP9/9lzyfz9/+vzJ82dr LP+/s/+7ladO/m+DQVTx3Mn/7+T/d/L/P7D8X7NWTb3/icm14mdRubq0/1sJ 9Hl24sFD4GYx4trNGIuJ6L9Oyra8+B+fahWAdLWrrVe+vLMlujtJZjvjwZd2 tUw3Igb78kkt7OyLFTULe9hWAaRvAx7ir9ZZvQbKPhMoGwichGVEBlumqAXL iwsLJC5VUGBpcVkChcXF9H4uM6d4YeEbxGvL54NVXuM08tYD2dnXk5WvAUeL 4Snc/Q+wgjiE6qUT/3sp/zaeove0SjxoSaeFV5RkAGpyGmad99wrbV/PFLgB D74l026JAlYtQmDC0c7h27fbB7sn73+NXsjs/xY1tcK9Let/z9xN6lV0zz6l 0W9tq7Kud+XKxqhS2rhnX1Vtq7J561e3e79adSMlML0zvrCbNFjEqzoeWF1f raqzYleqyjoMVf+edQe2var81qsd6HjJ2iKBdmojHnT3XmFHu2LhwsfSFRVG tMFSoVQXstRbBzS86vfsS88FDZ064Tc6ve45Sv876c2ig3dve+rwRC/obTZs qTcr0SP9yjlwt26EoVFW4xyAR/0IIkb+6KFhF7XdY9w2MSmXFELUyW/WbEMM WSxlj/GdlLp3j7WP9iKuhJPvKLHlixcGV6W/duR1ZQoeu6yLq9UjM/HKerhb Fb7dhD1KczJHBUhrOeXI9zKLl6KprlF3s7xSrXG5gfdKAqvE4JYU9l5UtqkA XovYueLX5hKyZDOC12kOMEiTVFqwwgmxo/sHNlVG1/G7X9DHSQKQPpBOks9J fz4D4kUaUyFQTKye2uYX9SWHodhcau3NpQR/OSX0tcgKlivOGP8dWFce/a1L WNfetVs3t2Q74muP/40oLYNohWyl0/X6mMo1hH9aJaw+jILsGj2M6MYZFVHp 2RWNbFEK+nSNbvRVUnr0HfUF21zVunWFLW79FhQM1jU0zbN+UhRAx+wDaFRm dPsqxkCTbBYlk2x+fmFQWO3hVKvrWgNdwfanvLr1FkD2DaxtENe1DaJMWGwP Ca/b85YLwutize0ixJxM+KK2PsMnObL81aEWtOmMuv6t4X1nqi2zJcp2QuGH sjnH/eb9BUv6rTdNg+FLFwxRsHGR9D9gAZUY+lNcROcpipyHmcaK5mbFMer6 tNO8FBu/eiaaNVCAT+uB2hoLhOwCDmTwXKwZCUljtvKG0MBV8gDCav6EStjJ fVxFKO9nAVyJyNkajw7qGHwzh8IynxnMx+PLnrW+a78aCzr9sY/pILesaqbe R/h0T//iMnx8FmcrNO23TV8f2yyiRl/3psrMVXEWPZRppdtaLkfh0kkRa7Mh UonffbpDme/rmPIu5Yj7/aNbnwaxCnHtxBO8TnK4WS+ql3ErqrY78z80za+a lftFL90vcOrZqnB5g1PPdq/1wMLWli2YmHmua6PRdS9z8NoNGh4E9f+ud+0X 65gX+H8/ff54Xev/nz3B+E/PHj+/0//fylOn//ecrIPPnf7/Tv9/p///A+v/ F/n/WUoBxwPw924UYIlhkfBdpHR3eZLlNWUVLPQ/szfN1RxFSjFiXRaqhupc zi/kD+mTIRHsv9Avg0nm36lPxs36PCy2SvhCr4eKM1hpoWwGVNiRv+mS8Gz3 21bMcYp5fhkt43pA4eV17FuhP2Itr0XuHK6sgpocYZ7x2Yxiliu3l6XMrKkp sqVm2T35XF0SAXZlo/bukOam6DU98EEWKWZvpi5JJwq7iHfaywwZKl9GSERh aN/0DF0+LmCzMd8xYOMi+oQG55YXCHa2OhSaCXtfrg84gUYgbKzcV373ZuVB /s/EUvoqPMYC/u/5+rOnOv7LBsV/efp07S7/6608dfyfFVKr8rnj/+74vzv+ 7x+Y/xPbqj8U7/dPEeFFgkNUG3ebQS83tQAr+8/MxoajPlTEaNDRX3R8BjS7 2mgvG6Zh+RANX8pvh/KblKIz/BOHQ/gnYL2VXrIyHMJ8Ooj55v8HDotQ74vw xUERrhUIAe2rKiIGuNsQFBxUMJtOD8rleinX8ZJfuGdRVi2MUMNus/M+GRtC P9A2HFfsvijmY/bTPkvEJR8mxNTHEh2wNSHGC2bi31sdRclminRFW8cp/OIB LNdHTW6xIsrnkwkAy3WEHoAbyG7CcXzHCbCXvx0vgGBA0doqTsEy6x+hnGdk 4CeCzQZyFZZ7Ibj8fmQTd8/NP1XyHxM9+8v7WOD/D7zKEy3/ec7xfzfWn93J f27jWSD/sYKoh587+c+d/OdO/vMPJf9xZD/i4fb1xD930X9vamZl51PidW42 /K8j76gP+1uOwGuC/qoydxF4zXMzEXhlzUVQ8UeOwHuTIXdrY1mEj8jSqKHy 7P2DS1gN1MvkHi85OSsW4+91bkuFFF4yUvDWV5Twmt5YwPuVg+4CSXgXcfdO xFza1DsRc8OJ3HBTUubvOaLly6tKId8y12qLfS0ku4SoeRkZpC3eBL6Wh9qR f2tl0Eu0HpRSVwaRFc4NMfwSbYfCzEZXCCK7RBdemNlDZOo/pci/c28UofQs Ubx3P8tzypRMVxT+s6RZmhnjWYJQB4OkoLbRopC1S7R/jaC2d+Lk39sTlP+q ZIlfqY9F8V/X1tcl//vTx2trmP/96fpd/s/beerkvzpnZs1zJ/+9k//eyX// oeS/rv0fUdxXEf+mGZRMpyGJsHnzEaiZLF9CRmxxsbfvOEaEPC5AVzknGFaZ R9ZF9uUeMjE6KpctwRzHn5Erh88d9s/oaTcHS6SphT5U/EW0VuZ8FW/QmgCZ vBJiwn6z7M+cMdiCWewgGOkrjV663Za7Xg6tm6dph7sITye4MCKcLE3v5lg1 3GFcqtdEXYe2mATf9i7T6BiIv7e4upeKWe4x71Rs1e5KO5rMx73iY14oKFFA IfulP9fm0CP5tmcziK1hTDX85su71TfflnGlBHz4eDPqTOfFRe8Mrv2WtG0X Dgi7K/ae4enEyC1FdkSMpsNAlGR7+O+OJYHfRFirUCFUqBbgIPhJtSa8I+bI hpdoK5pYB6mUa4uE+qHDVLEAztN0F9NaulJtf4AoSw9LZuo3IDrSfL+7jNVr 4qlkfm8rYnQL8PL+i/uBb6hVCOlGrr56+LB81l09+5hVYv7gcXN7SSdcuya4 37UPoHgMttTAou5usbkcCFRP6asBw/32/eX3/n7kbHPpSpn8ung97q/cX7TI dtywAPLf3ASKLI9nqJeb5S0fcZ4l5+mkpcINLdEIdFxqBN9pVdqnC2R8WtBZ 9N0LLF4tMndFyQ+wSliOXAFbcP3M8tu5iuE8AfGbD27uOnbPAUs1fWDE5+3h 7p75tb1z2v0RfncPTk63D3b2TpaQka1e9wm3vYicsOhNj5IIUn5/WCJCBe3T PsE94MMTa4Sufgwfm5MQNVjLvRa8Ucg1d57MtnU3KCZpeb06yvBqhVrAluAg azOD2I8xzhqa+KLIo9PpOCW9/mCDm/8HniXoa16rZPaptfFkRb8gMbZFacFV 1nRLr2+s+ESXPwipdwNX3iTjt/b8WHVcV+syKUq1zNhcHk5GGQgG6SycdeDu MP4N2lpUWV2pkSxjYVEyrgjaVaCZ0uCzCTR4lmWjaDTBwITDGCCM31ZcOAg1 bmRQjEG5XoVP3YCi9iHR0SRHpUiSPJZZbuM+2YvBZxuyLcClcwezKucTBhTz rjDKsGTgKPwsk5HCjM+6OlT64cHn+gTEum++YAafg0mI6dBN+C6pcnEbfK7K Q+ziczJzAMRsNojO9B/FpAB3DHbaHowngnBm4+G+AIlkF79hlXZdspVraLPf r45+jd5bPimdzq8VITeqiaxdK4uvCl+OYGpwnAA7RjhHwaIE+kgZ+tvLRlfh lun6o0SvdMk9UiyassJpWeJfDLQinkJLpRGVG2qF9M6TzEvoaiX/5AguPCeR xS/RAYJOwqk3F3p8ma4Lip+yTHgYM75sMkJNRlYk/jAjGcRVNxmVNqsjFZhF FNWWIF9sSdT+s2OZWJuwf9UybmUYX1SlHzawUuGSh6/68zxH/ypS5KPSZxlg goWAIzRMz+c5ubAZ24s7Jfrdc6tPUP+vAhndSv7XtWfPn2n9P/zznPK/btz5 f93KU6f/t8Egqnju9P93+v87/f8/sP5fJ+76Q0UAKsfJqUvnafNxV84far/8 J/Lm+EInBQVW9UFfdfN7n5P+aziucxj3kr4JFst255zwR3NOKI+LtS9fOKx4 BHMfXArr/qXD+un48OBND5VEi4fV5wwWcF9G9xXs38f4JLaR/f1pkq+6o2pK sNP7kSeCWOiIERjwafftHtzNSy/iLMs+4H8iutDgvjKXwdU7V2qz3m53b3f5 IQAtlU7Yuj9PAFsBBhhdLtf/Hzh+8aJkxbccvVgNh3w2OLKMthoQiqE2oHG6 jFgECVsi4yeZaV3kKyN1Zq8uNyJBEIlZAIDx/LHKTUQ6eBvGWuSDE/FFfUuM 3HOYUc4beODP8C05htDhVqf5dyPnqcj/8lUlAAvs/5+sYc4Xlf9l/THlf3n8 /I7/v42nPv/LYgnAHf9/x//f8f//wPy/lbr7jy0B0PMIGPMvTPMiT4AaKz7m PdIiBiuQonw+1pYwvXRQVDRNogO7nB+MRT1ktYDpDJLaICx+txXmX5p63LWT Tmj6q8l2ldaogub5+NTKAvApG2X5qWD8LWqp1VWxP9r+WMJLVPnwsgUstuo5 fLNaX4/Lx6fajtfh9mmklo1XkOvHZwHnj4/N/QeqhCQAdbN32W21XaGJLm95 pOf/eKV2oN0DXyhw9ZHaIwtJBZbYpZpRlhjuugHWnrngipYZdBtbVw+7HgZe be/2FLN+YyNXLDddgmjbwJmyrzDoEndfN8KlOHxnR9ULZYZ0kxZwJmP4t0pN FrSMI2RpbONcafaXmb4NS6ZvqrPrGr8pc7X1lXoTONvbIYqHFCzCiNsbFZ2G qAeVvJUM17DnX3UuVzKCk8A+9Ld971iBkJa127MVAmhaE1x2hdJaakwPH9rr /xWvZxHaly/nu+v17nr9vV6vtsWbSTZWukHL42sud6mWB3u7N5RvJ/pH1y/e dILA+OuL2N+vDn91AzQ5826+V2RVdxcNXWuc+hzxMtuCmrqeLagBTzIL9TIA LmMXWpdTYBlj0WWC6evRszlp2FbUjD3OraR/1zUXHXrmojJP0wunAxhk6H6T w6wyDme03KqFchKisCyOZuk4gTkN4+ICv7XSTtKh1RVRGn5fBZBaopNpkqfZ wI2khU3sWp2fQnMIoNqMdIXNX5fRuRj1Gt3dw/lodHn1pAYGNMcxjC/+gKa3 w2FCprGIBQrYzCnUw9MlSRkkduBSltHFJVxpYy+FQzUlYCdoAFJqDsficjkF 1CVLNhElpJyyIkZBCmxCH8V4ADMFEI6d6DTTkewsyF6iD2hRRlaCxjZppxRq uV/AXYq20iab5O9GaXT3/MM8tv7veG979+3e1++jXv/37PGz9eds//t07fnz p8+g/OO1jY07/d9tPA+v7pr8sPH36BDABli6GhSshOsr0UeArejvjWv11HC0 fn/9RP8++38u44ss6/SzzvxDo/E6OcvnMXSJasJGo7EDvCL6Z2w2GutAvkxm eTaYk06gsdFRCstIlWo87iiGItqNkzHMYpU0hK/iIu0XjSeBzyfi0nJPxS/R QoHG00DxH7JPUGKQUgjHHZgCTCjLPzSedQwhuY3/RaUbL+TOKIXBNZ53olfz dMTXpihY/72DY2fnEZrUf3Sin/KUeGM1MLie3hlGqbG+1on+TNxFtyjQTeVe 9G6Sqq2Du/91QoY1RaO8ZHTlkHoQ/icNtqMYyJzZDAOXw79RH5hezlUdXaTn F6uYayidXXrQQS1ZEIKMgsBRx7EmxJ6M3QdSVPC/0fQiRoHEOVmcDJKPySib Ytsw3lnEFh3kx57EHEGWSCB8M+TJrUIBGA5QyaimRFlpzPpcsjiZoVIUbv8E bn+gb2dImKLK8vyCGhuj8vRsfl6wZlDZkZ0lySQapp9RR4ikI0XcZPgSRSLp SNH6pINAJaHhkbj9GANhN8dYm5SFW/yVgNLeAsKAU2KdHu4ekruUbpw38SjP oMExe20WCac1OIP1+FRex08AaEx0jTDea7SfTuafcc+wuXGGC9hmwj+dwf5+ QoO00XCV5C3pJBmwNBBhMEomH9M8m2CVLWt/ukI/88JgQm/SUAOAfY6YbqPZ Ia1EjWFnbXagi6ZZTlvxUzoZZJ/ER4zIR+I1kE6OWrhdlsoZ14hFmmcJ0fUw gkmCkr0Z+83BGJBh+RSjjxY0fp5F8QVsF/U5SqjjC/wbtf8wAFgeZ9XQzm3C kzg8acPAExQ6nHOY4nT23XffwTEJYRI5KvrcaViQ1SwkCO0Idgr3hDFClqcJ 4iqsjIReNiGt7XYkSRxG6VkO2A3DFp/x907cVk1iMzsPH0b9UVwghwPLgSyC L8OYWYMaMFpSmvxxPEATJVSNw8Q/JMk0UnwdgWxRkjapvpDUZxMAWkpeMdF1 F9w+sEgjpQgvtVN5d3TUYiCWo8U4iUn13bfxnpv4zZ2dtMA/tM2HW4azepAQ d0Bq8TNcOusUpYORsmXZcTYQ+1XKbCik66v88SnAQz5ELT3zkleduLbD4mHH 7tXQp6tBLXRbl66cBuvfcSo/wCmAPaIJWABU8OoyP7JapAM2zyhZBfjz8Bzl cUifL83spf/xB20RtEPgi3Ix6JiV9DI64mvHcPBxbIUyOSmyOSoFZnmiGkPU /MhI2Pb6Fxl3zn1su3NhICTWX+2XqXt07NbeZiYbbi4EaGVgAzM3xbg9RKkF m/uUZIXe0gAT17TM/ppqXJ6NYWUzLbOlZLmz0nHnzmSCmrsLGXQ0rLEjxrPn DE0ton1KCK10cjjy9RTZ5TM5jcaKwBJNEXEw4dsEWkBoNyxwQYoDHPfHdMDW B0IsZWd/xX/yhEQJLK9FnGPMpggoMpk6u+Sy6ze3QN67vCyyB4WiFxBOJwOd gxK48ijmKzWOMDLNeY5GOIrrR5drpgcYaV6qOgKqmDxFamD/gwSIhXN1s0zn ORzxpJDde5XgGWNkMkfpRISkdNjJmG1SFc6GA+JdIvraKFeVO2WVsSaBPObY xNUq49GWikjONkq2wqzwwfNRMus/EpB4xG2tSF8DXWhXrQBB+BZc26yeoGUO LHCjCtpg4YsMLuxCUyjl4du4jw5Kp7I1jdkK+96w1akW/m4hKYb3gE0gIM4H SuO1ZTmMi4poQd91+qQgsKA5MOK2qE+0/8c0ZrC9ECjUd0V2hii5DvxbHo5f 0acKFhcNES1oAdSFK4aUKsBFUbABPyrgrLPwOiCt58lOyEzNOqUG+/E0NRKg 8SlzNoceBQpuNpJT2qxnUpqyZcwfSWP1uyOn8GyU9T9IClW0AE3785HwAHDA p1kqdOA0R+tDwI8ZkmspCgWhiVHaJzpcYZBhno0jimALrczkSqfGcjMG8vwH dgLKpgUtEQsoYfJzmOVlR3NMaPw9nyosoRgybI536X4RAGfeluQz3WXtEPXG U7fIpHnOmIyiK0xw984yDEARzfpA0OECzYTmZsKc3nT0atvw7aw2yXMvkglh XV5AiiPDcmzddhv+NZppTQQqUSfskCz3pVlbZnLMqhLxPkWBdFFw1oaJnJPE HjSrD/DfKfQzzVNoCZpuxecxEkEzWXhkE+BHTihbbWF5qVfaPD2byEI+pt+X E+OOkQyCZeFH6Tid8aqrdBMRSYmqkY+NxcbQATIHo4zRJBzAPIYBAN89Zz1L /wJNULN8wBhYKvA5xmqC+j7giQbySWPwiSFTHwGb+QiKKnTdibbttmhDiHEj Fc8wKnCZYZcRiIFXAiYbA1vCqvQTTLtC1xr+gdiiyVxY81OcT/CdaC4BcpvD eBaPmp3olRkVMaB6CoRAuH1pTAGh1KVdRgSE0CzbAPNoM/MuQdMQKPvAyp0z /YjYeCbmizVbbm0PLiJdL7LOZoDZfDadz5S2RYm7NC9mLXc801AqC8UTg9ln chmo6nrL8btm6t31Vu1pNQcaisNayIAE56lZWwAenulV5VfUNwqrgBRDykTh fhyCFU9H33MegMO6kEWI6kKLO6y6OG+gnc0LWWT1RqxLzNVmCutPfJMSI2Es 1GtvC9n1PRPhhSCIgP+/kzzTCk6J5mOUhAqJweUXR+cpWbCnMEdqb3ti4vY0 WQw1Qeou14Sl9pjinOUcT8ZYk1s5j4CBjAkNOlpQaAxuK6X7i4HxSOHyjlhV 3WYCcnRp8XMKHNPc6NjUBdU6PFlxFVlkfMdq77RgXEgc/SzT97qGb+PzNZ8R myhzCDLf2wXg65RUiwQtVmwdmhcp1s7gBzRSFQ3HEkDIcUfET+rWc8MRy/YH gQQdIsTrASkaGIiQ+ED5Y3ogzG1PxQJZ04DI2x6N7MxILOOKnOw9beu4ejhJ BiZnI3TPb1sZekTpyGeGNY/w5RF1AsXSvG0JGfWQ4o9xOqJ1Q9TAWldH2ap3 bwrLgDSePSajKCXlKgwI+UdYcxQLuj3xuuneYAuFwYhXIjdCJmAY+5gJyhI3 OLlohuiZ4rHBxjJe9PIJq6fR9+QTzf0TgieLbI1pAGFyqh8cHjwPMKokELcj idrMTK7Sv1pt8S2VDqUPLeSsZNAjHf2Llfy266Is7IrQXWQCR8AWVTcHk5gR SmNZI0wjh8YLJbDV/Hdu/axuTRxYkC0G7DNFUndG48tZuA9EkwnwoI9NdXs4 +BXbD9jCYB17teP5LNMRsuG+AUoJSHIyr5KNUBd5eBviEs9pniLLiIUM3D6E yoADAKBoRNZwgOScV24+bbnpmkDMOiFqDasHVLW4qGIA0jDjY2sUDaI8qGmQ PV1Jls0Ao8DAz8xG0UCp5cUQ2lYwuLl5erx9cNLdOziFgSuDTMQEMYq+nI10 hFergK4myacq119nB3GkSNfUTFOZzBBbac8wBdwzhztvRK2bW4LnUTdTfWXj ZSOiEiLTNakgtMbb+LOheSobNLjZF63WrGQdpCAhRIssQirmwu0VkD0lCpdH Xre3PE9ryxC0ndtJQCYt3HR15hjOJyOkBUh6jxnoVEvI0ojBdDV1iQXPbPSv TJFWowO9bXD2UaYKDQyId/kUpzPH7/oYj0NLhxwmiCc2PEZwG12uGrDybGY6 1lmWVri6WTSWKsqKlwzAZllAcOLfMommRHnJB5dM2gHbJugB709LvjjkFSf1 ldpEApBkwHpFvcrS4znB/nxKayOyUgZ+OG7eoLGtD7Ck19r2p2traws2PV1q 1/srQRO0K+27Ii0j274e+eNkNBTTfLO88SSIXL/lGgxWoiPMaH61uYu8PGE2 fqoIdngI5g0cGiESVJoPUlLHoEgmQfoyLVjCD+e/TxpegFrSwMV6Ihoti2lj yhbOClCJjICv9y/mk/P733IhkxV2eOCrmb0c+Go5PCGRijhXG9M/a27zydWH zpL3xKaiLFJYtRYX5cldYVbDlegNcOfT8LTO6dMNzIsbvsmJAUlr358yv3H8 OR3Px9Z97VgixxbRApO1BJhRpNHsjAwILB4bcakwDsSkt7JccRC0XKyxEwZW 43yUKKGGMWFplPy6bLKwTwcZIdQsp8wsI5sjo6ZFNZcAT8XJV00wWzJX9kOF iLwXyVybcLrG0dIT+NLjRaV1jh8GwjH65AjDD+NEnpBbicm/YhX2LQFWlLYE SOcJEPdEi/J1T/lvefC2HbpgNz2NttygdmJcd+4dI5Axk9cCyVJxn6t2af/7 Rb20z2ZIbSkshh+4ZBEE6dBWffUbgytSbiIWYYxFspzEBXEGJiWww2lLtIbB PFe2AUSdSCMlgYVi67RowhZKSMYrKDYUF3elyQQKhsXuWWHUsAwRgTnJlFk4 hRZclxSYALkY/MGf2XIAobIoDGzQ0IPDDg5U4unY7VlCABE6JWgsZpRH2MD9 whYXkjwRAPkqlnXU3QGRuKNLslbzVWn8VyE2OKNLNQJcsvlEEkdr/ZESydgo 2rZEl9aRZs/6LJToQp/5gPVipPxDSyXLjqLSCKQdFXMUflSpAMnWiXZPQTwM R/QQdYpz5DEcTZ0zVUdd1ipWKkR7miQh9cq8UGCtRa/UTkj+Cpt6nszUZh2r gTH4hL4UwhGQqLcT/XRBai21hoXSppIO9WP2QQhrXyRwToE6KHIVq0mBoPYX Z0sUCraRj5T5kGhBbTpB+Tu/l+OrYGkKf5IRoKf+vc845uhwmxGvpuoNKdAw lJosLo7QNG3OIKrM9daRHaxCTsoaArEaHzQxn8FuPsFZJ3wXfSKDRD1EtjwQ eNEdauUIrWsFNBGpgTafzFAr1WmKgpCYT5N0z7JRHgIta54C1xSPrLbRVE+Z SqJZHjA2WzxJapYUpHS3UlvzSUwxcTKy89NeJphjhkEkVvYeYzKWELRlIFV1 zEfam1jb4Gi6uiT+iwgNfCsYWf20/0HGNnWIEr3t0HI2sC4uDVpbckeS1F3m buuujKkgLKGRtp4a2i75jConsWWwKUzBUpqlMJ3SXe7IFVAopYW+cBon2kNQ gAUwB7WdOohZi9015tLk3FUETWcrzDDbxK+l0yatviGmfJqLmZgh03W6/xyD r2nJtu8Rp8O9xa44yxIfypD0CtnFMJooMXVCBNAQBlnC0j0CHjqrgPqygJjW 8gMbJEV6zt5XyiUsEoevFt6UAncl8YqWbTgOXyLISGcly4+Foj8t3LA3Blj8 7SC+VGouYsZRgWJMCZ1L3Lk9cVvIamJABKFlbtL2G2AhuFgeUt+ISDUAq+Za AvwIJArMNVrRg3WqokYn2j/c2T7tHh70Xh8e/7R9vGskO9PRpT6OeBpcnEto RZ961KElzNwzYeTq8uBRpIUs5yGunGnICOfp8vEHxaNpA61H1gCi78w0rXee ObpfFzVtEbDC7hM+u8TCPp3jCO3fadKkxqGD9OQiTSvIRq5A62TSWaNCByl1 1jVlcDfhSdkkurIUyRNtJ5PPgCRh59BwYzAXWUg/j4sLPEwYnxeFx0wAsCRI 43Wk3jVmnpGhQw54obSABvWVjG4iYxyYztwVaYvY7fNM07u2wB1t0PH8d0RP LpRDXKirg8d4jtjgYxrbbHiG+48aZgVCwOaQwwIc276yZCToH6dF4qMqtown wEQU5aMusXuEq3Gg8ZaMRU0DtUloItNBzex8rA5bSMJIXaA8kqmTORnDkGuo M0tlaIpxWZFuyoAM+chODbxqQ4nYrMSn+tDEiCuROkfCfrEbDBuGqEJNFok5 Ro9qKEp1LWyt9rKgisq6h69+Vo2zndEC0CeCPDaXn23NaowTHINWrRGy7is2 fLBeoMGNsq+Q5tB+S/OKkltGwnCY0p6duEh41Dxca9BCqIgCs8ahLwYgxVEm TN33L/GuFGr2v+ZwKgbIt/vF3v/KJih0XcSjlU2v/++ly5fRe8Vyaosoky7n kTRQ/GoMcKS4p7mVHEFiQ6go1jSPikvYnc8dTQmppXed7t8fbR9vvz35NXq/ uhptH785+VULYI5Vhdg6WaGItZpMDvgwRZHDrqllAVzGs75kVyjoIGWaw4g3 xEAJNoPHuGLfjXaVsDgiauF0LCtwbgUD7Noe9WRxSm40dArxICgJnDRvefEb cbFK/WQNV3YxVsb6pkFcphc/bu+/w8UioRqlqerHeo3OxB1o6BoScMY5S6OW xDkcc5YxUYMIzyRmclQljoCsTqqkKuBS+StDmINsSJZIgaX2QDXo7QVLUJT7 i7Husa5XgnG+n7T4xVBbMeJhbSfEi4R2tTbmRzKKWqaz4bi8XGSFJq1Khj6O o3xZTa6942HNcZ1IdJEMdXvzibVozmgqAFN5Z8m2KKMnDVx1wh62GCOuJgNW NlkdIB1QIMGPt9FZgsb1NEzVHLHJeCnFJGLwJC39EYCUAKULei48a/nuxLjv VUyPlH1K3gZrZzrX62dzU3rxDDTCQvNhNXIG/0jAvkoaMSN0hDtS5LNZbjYH zRXPJ0irE/Oh3NVcri3xsRpBv2t8YNi5tnN3DDk0qi23BtybTS7HGJH+vOk5 fxGxiYDbVA02DXdnbkgHTevGd8332JmCP3xN0S3Cyc6ql7jZ4LpcZyFoYtVL YebdNBwVnA/VtHtnuffUCRyjClD0bUCCQVsU7ispC66JAnEMhru+w4A3gQFv A2gLDPYz648HrBnDv6sB2MBq02i84SVnxnbh93tGbi89yuRqpEiABPEA+GqU iEuClAmJK1IiDgliMOhiSuQmcf+1IEW1tgyWww2vhREGh6bR5ZPLeiizq0H5 X5ax1RiKlixIiVmy87M6AR/LeVULzQC5WJIyt5ZHY5iTusBYZZLaz6bqh7/y F8JJnWqLNa3OcatNRlQ3Jlh1YlREUxaFLpwWmeuFk58iXFegPMssSvGqZVan AqxGRTVQ4aCaxopCmwYFyYftsi1q5VFoa9tejFjgZgP6CvhXC7D1jjk9OIUG 6cBERcThB+KDiTDYgJN27tE3R9n0zrJkyJ2yFWemymqh+ko5X7HttcpB77ww dxahpysV2ZhODhm3+g4XgYwyagM0fXS1AHVRZfg51eCM1YuBSHQ67oQVjS7y Q/LVoZHFTdFJHlonmSxgDJKDK6widB2ZSiAYWU1ic+MiGX0UPytLoYQT9RQN lp5BA1VtcDk1C9Ugxo1Lz3DhTCw5NoZPMdgMijX+3N3fj0jVMbJkF/bqKS+W MqUwKVN2xn9lyzIhlKgpYw6jZiJVIjK5/0WHW65ZG0AtsHF8WqxzHjo5elCW A7keQ9CLO2pyXE04jmJMItE9xExSXD7tBixhGnOHSn4u7dNcpZ6YEHgyOzty Jw98P8s+iA8U9zQwVHgolUocnWfZgDS/6B6ZsAsHRtGxTSn6y/v6KgMcFBiH oiJRs8Z5RRP8qC2gKD0Yw2bmhcHZ6DzpbKzh78///qyNGg32bWVTgZNR3P9A yuZ/76zz7o9GorFifTJmAsHoK487GyQbUDF/KFyOOD0RRUntSUgJwm+qJowO Qw7JKr9GPgktvqakd7L4FhVJBk4qeuBqcyKjIVa7S/bjJSsAFWpGK+KJj1Ip OTD6W2cW553z/26KbBeDoq1+/vjfw6hcRkUxILHMmexEW+yzRIdhInzAbA/f HnR7r7oHbf5rv/uKCDT60T3YsUfL4xp/eCShbsYfmr7Bl1oLI9qWMatuNlmW pKfMTMF98lcfjO7bZjqmHgwqXA+7dv0/U/HMKzcCk1ncyIWJwuK1ww3RKT8f ZWfAKDIoaakx4RjUw5HPbyrqJ9upNZMqOlIXScQK1MJgPiNyKJwIM0PLeB8P 4HSV9Xh62NRYy9p69mJCfNXEFhV1BtgUm8VYS8TE233zCdCRMFyVL7ZEQ9Mu eexc/GJdNU0mKDJ/xvviqchqzGQ8zdAXdyvqSigPkv/pdEyS7I2PMh439ElC u4JH+AevSjIzrvmsaEX0UgqwprUVnhSBAsvEMJTPM2TqQ2EpyDeIQ9Iwq9vn yQpzOqQIGDUb0uRGm2ZnlESFxSDjWKFw9h3UEUvFBBdx/Qs2nwS8QZBr+Msp ZhIaiA2yxG0QnVZ/FOeG1S7+a47lAfbRAb9QXheSZ0fJf/TxNb5370/zeFJg kK3i12iV4v+Ujes0eHOVXeahqYL8ra5YQ4Mwr8wV9tmBHsu/NT71Xqtv06KP JQ5FUCoHiqNUpQNkByQVlfCZHAqNp8iTsZInsbmn8ZK2/DF1GrDCWiJabeWI khqXTAUblWarJxJNAw+fLzJgK5cZx0TXFrsIwYsjAir1NQvOPacME7SuSg3m 6L/E6IwkPSLfuMrNXo57wiRCyYKRLIHY1E08GcTwTPxiHVeegNJfiA7oVHzO fBcf49ujKEzt02NwgJ3jkVCxmjIvIAMQNl4RZ+bE2IgY33Rxw5b6liEi5gaj tdy0KPwDmiba18KuD9AFRUwleQ79j/yqE6hCpjtoPGg5OtZHacRxEeU+0lpN x1bASTojVGnHH1haaM18wQH4ppbLlAmzMc5miKiAKzLTsCqzRgFwJhKE3IRt oYNNa5sWHQoMyaxyODM/dhkC19Hh9irTgFr4VCi7BXV0xcqIU5pppNx28J84 kWM0NGiyc0G0odpUahC4CaAEDMGN9HRHX6YA4Or6cq7SV4fbxsAgY+O+BrM+ 4pUg8TKQ6wFabM6RLAjjAUxOcCna1AVBr8wqEo3t4jXCbIK8vd2ZsdkEfE7J TADmMVIin17m75Wl7ickgSh2DHN5sH5Zjtf3TNu1Bui7oUg9aQKFrIgJLsAm LDCm+xIphOETt9vfSBYH5rbBMgMHt+9N01sIIx6OzzJh7sTEn1H4LMfApMm0 cOwoTLbZOsuSFiJwR8RpIoIJjkhnFJOOq1I/NB2Kt7NijEK7ApPYhA+ANslp 9HKHZ4K3jGGfHKTq8fICxo4bAzwma9HmJjBg2ehj0pOR93LLoNvcJ2hYLSqR JnaHfViOMqpBugQov9FsPG1l+dnqy5r2TUsrOgf1SnQA9zqGoiIMA0QeugGX TBqXuao00385taSFNQmZQgkGNzd7ExpQC2akhzlYiXbIoBrWFu2GlXSHL4+j veOT7skpWm3i1r872TvudXejaYYmRklB/htC3Ws9AW2UsBxtm/8wWAcx+AAt xrBH5gUPTuDvpuedVcyHQ+yIY/lzUlH0Qig4zEtcVgUCsvurOKmUwn9WA5fK m2wkWUxMwZCKUjML1sRoIw4XBlWzNao0GR8Lax5FyLYaYujskt0R1GkO+zxo 2Kl0fVholKbtWo0iyjXhD54iqNKiZE7BcTW/x71dlUCgSGW+bF4xwaJ5vufW V3mUqzC8lytWdhyYSRJLKCfEasjOZ0O8vWLLuKN0KQqpSDGTYq3IqNnclL1G zrO2Ds1jXQPxCM72xFgFhs+zhIip2CqjqDhi6lRohMohaSwEwHJt+BCCg28L lLOtWtM6iMeK+IfbWW/h0ESVM6L8XWL2EuVgbQd2cO8RDvyradU4lxALuY6S LcejxnABOlntvj1WvqNwYNX3tm08Z51zS33Hw0pLeVyM151WTOF8iM2fpRR5 TovSp1Md9HMZpX7Q86NjK7T8NVJ28ZkIypGo/ZhookEvhtiyGKU0Ovms4n3s +uk1MclSU2xH+3nCQmFMGdd0T4plO+KMiKLyho82pwekNE5tSjWIl5Y6oxcr 0X8yQiY5X184AOeqn0+QC9H277mEYBgnJH9QfooamichqLJ3kZ0ZUXcSjO9C jJW1aMZhZIIBgmw1Hltqsc267RapY1mKrRhTxw67Ws8PrdoukL6qZdHtoEha dQhJrr6cUN0So9shDpHdv0J4f+z8AQaQpzbFsQrJw48p0OV5MkqRAZWNQlL6 RNEIlH0aCZR9joEne9A6Od1fka1DqgF6IREdRVaPz1LMAyABcIaWzZ5xhoyg AVspfZbIkdGRXPn9weHp3ib3wxF7yCk7CCbKlq+cAt6+n7SGwBbH2uGovYDm BC6TTA0dht1R63mIAyJRJQlN7DD72q8Kwx1hCnUyo2fUQNHvVWb0Waao6TG7 fyLNNR/NSB6hQ+qTn9u2jpcvLbBW8SImYQ52ZK2niOIxRKYKnl8OnB+NL5Gx +05N6ORk38jI+vEEuRRl2lQbcdCasl6dH9CxjXQ1Q60jJF6GxAqFtq4/6b7p CjUHf57uHb9VEZNQK6iwSF+8/z7qdA1+MgMinYEVxUNJfCiKUeJBEY3YMJvC DktrpBtDr4mCWDFYXxZ7oWwEyY4BoI8iWk1WjOcrxn3FFoxf4KdYnQba9lPp juKEK1WRSJQkeidGLv2cjtlqgUprQsfQ8Dhzrmw3y5BkmNnuq7dwfR2gwwon pae1PTo86f4lkioNTUyQqjP5BPQBybycUupgi4QAzjJZsiYSjGjKSScM02d0 S8m5CdAOyIX0ypgvC4Yn217SXpMVrY2iYP8vEwMzeybXBPlwKNs/UX21KOYv 2dMFCjKp0U9yJBUb9lXBX5LJBY4CpQMcrndl4XgOEAopLQjj+aNLOLUTLKJS WcibhVKUhiHFjJSJziFqgG49/4+d/2nn8Ojn7sGbr95Hff6nJ4/XN9Yw/9PG s8frz9Y2nmL+p3Uodpf/6Raef/1XhEbUj73ZO9g73t6Pjt692u/uRPD/vYOT vQYXgOdHyYiw0Qa6EIjk9f/4j/VG418xq8P0Mk/PL2ZRa2cFXv/7f7TpY/Qa pdcnwNSREv01Ik3R/nUn/Q5UffofTFYAJkJVFEYKnMNVFT1+vNaOXmXFDMu+ 3Y6itY319fXV9cdrz9vA6W83oj1E/8jXcQiTMco9BxzafsrhuQfoRZaeYZAO KHsGHSO9M01Ra6T4iBHge4zENMj6woMgbiU9tvgG6pB9o+wTaWj/ldfjCFDm GFAN4gfkAqSlQrKfYj5RNW/OZImXnbAdSEfEyLEhRd4YwiINMqbvLpgPGyhV OgYUwRjKKDvG2NAsx6HNIlQ/Yo6z39iXiaRuWoPzeYwarSRhmU1dV/itoca8 uqrIY1IcE6ZX00F9M+7rUKy30DyQo16zyrbhDi1SQ4M7b5Ty9UfrI9SfAyMN AyP3C2sFWbtjcgspmlii8MwB8+bMwpHit8E3I61e64Qk0VStCh6dyfWB9OSg xA212HIxRhUzE8vFzkoU/Qw3J6p2cbKihW7Q0isqso10Ht0qFKzgE1mixR/I gRZHp0bSxk8cNxl4/lz0XbKBbfICngKZDRxEdAjNh0dWlGDP3lMgm2BoDbIg I9WFgQ7r7PCRKY0PI4cS7OQiqNd8uWgDlMyGgsBwV8prV6V1Ie4j4zDM52ja OGukljlBOrOqYhnLvkQPI8uJHocx6hg8DSD4kcah8ap13xKmQJrDVMu63UEm 3Dmn4qLdOSUd4AwFN7R/hN8K2hUVf4XWUrE7pOWl5mExztJBQ5JQkXZsQkdd OuGWiBgDkC4+8KcMdyVPlO5YSnUaLNhwe0GVOofPzxSRY5KwIMOVCh7ClnlF G8EdtVdSxVEg2k8ZUdBSOKkIpESwOabjTWIiCUjXOEealGbMeuZhklhaKDR1 FOFBP51KFhclT+C1wnXFY0TWjh0+ZSaphgFnqHJJB6ytQc0CL5QbWJDXwdjd AzOOgjnrZKyAIcGstQXBxiUDDBkGNNTW4BlOQlAikoBPGWtrNqPW+grdS3xJ uquOJtStDQy3M2QNm3szMTPD4SHx4yg5R3MDnSRBXXlte4ehzUc6JpPTH416 e4QxabXFN6PP+4WaijI3QGUfAbwy7mHfOqGqacETdQuTnJ7UCYXeCh1mTewq Lk2sM+ey6UQ6/oeFhmnwEvMcmTjshRKcsyVEwZZ6OL6GYIvChiBMZcZbhilL FHBIZDFhKi9MOBpMX8FTwktGWB26SykRoiUPECNeSmWTDEccwcZpqyH30X0M 4TBnPoDB5XU6UfGoLh30xEEnSP8z4XgauJZo5kSzl8txGlOauQ7BnZKHx5jR nG3uEDtKiipMfyTggDcjGQXRouubMx2NLAMWNIpkwTp3oukZUmxL/DvYfyWb Vc1wAo5kRpJ6RpqcYwW3mYCHVpxyzMFtyI6Zap1lQlrtI31asYNh0+8LuUFS l5zWXZeLiTDrKBpsivuvTy4HG4EZMtYkjhAOCqelUosjsN5gaOsr/4sRZU/7 X42FxDHKgPeO355E2we70c7hwW4XQ1CcRK8PjyPhptrRbvfk9Lj76h1+ooJv D3e7r7scrgIHvybChQCpJOBIi42hD4mO4RQ8HHBeWRXEEkdCGXWJaMKgnYts RGZe8aWQtmKCbPDGoKFtl2QNFZ0cJi86vOxNkSZiSG/01283JLSaDJ+uBWsO OHrFNDdpKtrulnSd0lpjnMA9p4yerS/s8Ir5N3IyUceYydgKD95MeBR/2uQz ndJYYOYYB4fKegFn7JY5JaRKn9RuyAA0D5GJ1bgNMoVCufpuHnD0H3HMbShr DCRIfwDMCIhgSDESVQWx+9fiRyUVpBCVKstBQ+1M1LR7byLlSfEN5WQQiosH gzwhNBkXURPuDtSuk7cIEwiWWUjluXAmqezNGoZCZugQcNhiFCu5SjiLIGDi AlpXoIKWV9mwoeIy2UsvSFlROuQ7IWJcyXyivX+lSsMi1k3Yfg7jRncAodF0 RjdiVAK0huq5BWiQ0iWQ2fhQhWUho3FCXDDPwIhXOo2fJOKuBrJ8nkjqhYLd T0U0qbrCIFGErtY7TMTEl8swrIpWk2buFzYdQ5Iqi7hGsplS5mKg4EE6B0JM my9poh+XZpr259m8GHHvbjIlMbPDSRCNIIO0SzXMSRPMI5Poj+J0zNan6ubf 4ryicCQQAoS6a3C1cmRCGxNOtKYuPisSUU3i3HTTDSxznjq5Zy1CwF068oJQ uVdMP414lGGQNaXBOVL6gobeJeZ0iHjVOprpxWWB6kWBaz7Mil3jnpjAUwLV WOhEcfRhmk+TRxb9Rd7UijNXRDNBzoaBHKHvqEWeVR4GGIUxBbM1GLNBiTnd i2MebiUqbstdynBqE5qE2l1EKAg+ClwlypZ1vSGGVCW4ZH3dOEkYSEykR32P G3snzQSwKoM1AEIzsi6HInPlOS0sZhGZKEiVxMkzld5N8Zg6p1KijPMnirSa acDjUsaKyhsHwSYugG7WWi9jwCqsrYinP8HlTF+JAMstC1CO0E1XnR3mzN1Y tlHEekR2Z8O2mOMYSgnt1LkXjOWXKXjGK4pOY5oPdCtpUoS2zz4wJp6BkO56 6dVFP5HgqxHrFrRrEhlTsaZWtPKkawEEa/GEvJQpKXNUxKtkoLEwyc7nYklv NUhEothFsIwpH1BKJdTQtNmuF+3NMVyfOCCL7SNquNCqlMMTaHM8F+NFQYwn YUX5RTXvg4GrkX9pKwpMw4ecAh6HrrBiBBYkXRPlqgVMhIFU2CudjNY/MHKN Jqy8Z4sRDIGMvFEWfUyTTx5ObLAeS1F4rT0VJnBTwiyaK5s90FJnU1GCyhZt KiCihgRefJYSTJwlbzMSczCQtpEvUQjGvpJb9BrrrADlruQmVFZsQkgmJ7eJ hlfq0xwPYkYbKuUWaZ20ET8tkMqAqYzvq45mm+4lcfOAM1Bkk/iM03Sp9GA2 3UEWneKtKgmGmd4T6wLJUmifQZVWpuAj2lYZVq15ZnC16eEbnaYDQ2Ocvds1 Cp1RiSwVGh7QkdLPuDYUjHqIx2QUw6wJeQGaLW34lwohVpvglEuL21BMoco0 KVio4a4AC4DtnJFDzSUpYhjDhyj3ICQ7cGtz6UYRmRyyjsUh8IKYT55WnpzH +YAjsKMDDxxpvKZZOHYKFduWmoDtvmZCSIpIVOerIMLIkv8RoVrMGrboaKby yIolNw+WBQFQbiuCXbpQUQqlK2JvGsnnJGf2VwnOWDaEIoxRcLEtBirLgZwb oTRDsVNFkBSAOXcxVyYjlzZc1SiePz/HVVLNqmBENA8yHAg01PBpLUKQ9LKG EiGryDj6mI3mZF7eQMPrLEdjccbpZn5M+xosdKZdJq3RMdokmEYuJXjLPa4n 1f0p+KNHFpIvU0X+bJDtnlgFKhm4HeEGPZ/L92/jRJ24dRrDBpujVxFRA51p jcgZ5SZqp2xDQwYkV9KZ44M8HSV01+VW1pBxjAkDklW8zHGQYuOvmRBldaFO rSVUqKEE+a5xp0MbLJvXh9aycZyjadJcCYaMkBAvHabGtmAJ21Y2In9msT5P RHK30X0slYwF4rVA8jee12US56SoMWwFEUiEENiIC+9MpqAmGUcdIEaaFHpE GImGS3EIePtxREpyY+eFs+G1zf7ZtPbsTeWtuJMz0t0cZx9MYPgl96B6/Xkm 19iDfhV02XFILJ6V6FNlgI8bxHe/p4eqmDLSKCQ9s0x5ld+OqG1ZPDAk8eEE KVHElBT73BN3KDECXnpY3wkzq2W1Cw8vzVcTqLGGOmTL+5hnlkuczM90smxe fSBdkHJxFGRDg1RYIsZjIbUgb8dY35xYCJVxIql1OTMKUdRhfU48sQfNEjl9 9Ln3BvXOXer4xv644D10MifLOcO1AGc3wpirwJnEJgmo8fgz3uHMZ0l5xsPo YWkcvtT9hYNLRyaMqu2Nr6ZvZgSz/AE2nmN8Y+R/FZJdx7xul+ZjHxdS8RnP nAS1ebMLTbWnhSFq7WotZNtZXCgtwxpxUtcG7pPl/jKO/0oUwBggmgN78gxx xB8AjJNR2/LyUQGs6mOcWTsKnJJJ8UNj1l01VH4tOaHK1NZaPbjkhyVqwWo9 y50TQJafLCcjQMdEQyZ/NuEtyeZmxTsnMbVQtaoWBkcDimSEo/QaKEGfIreJ GKXG4MOc6PyiESIrHSyZUIKhCzFkVLhd+fWzkHM8TchPMjAET1xkLQZqDaLo iaEZyEGXBEEsrsHsHmcjRb/aVItDSzQYUhF6k89oUFkQAyVXvULnFqmC2kwU MKFf/Kxhsjop/WCg++reEX+iXolhkHRFjjW9CfXi6D0Dw2roc6gWGEloUgpp 5MoyK1oMpWan7cUbQlFolkxQ69+U5UKaG/MbKwYNHB3appgtTBtqABytGpEx muIy2ktj5TfzlLdOsXc2t4kgOZ15PFiRolBSKacJdMTcgpCtnj4SxQTiqMM8 z7WbkavKFZEeoPCKjaHsmIWv+2Dbm0QyUonDOSrpLtKzVJJ0jOJPWnsvjGJ5 PtxOThb/6MvEijGSVzgEtie8b4mAsVLIvsLCHVQ49jXUcP/G38Ta45mdOrWh zIyuotjjEevhN7xF9FgcMXV41mE9CiVuZAKljtRfMOOZbdTgHSCTmVer+rVH iM6Rwl/YUoQPsStLtBT8alxwugkXzVCdnVQoQ5UJhaCnFG4GkVwO5znpqxyD k2ziTqW4H2lmU5CrIACCa1iKC1JxdRruSRILFXHESCYUOIoj18gJFJWShY5p Hh5H9hxtpfliJ3GKihNMEgi4BIBr/+t8cE6yPCZSLO6Udc4NoETxxklUoaHs p9IfoLyGnXNJAyfiplj4bXSyWGk3LCgkYpjWkQABYaelEjJihhwaFQVbgIGj ubR0bDD1irqn0dRvkPaVT4juwjsjktpBUkLAdYHCT+xXX43VdTs6cAvb9jsy /UyocfQ4LgC8inQ8H8ExTVhZxAoMuEPOha40WL9hq20sa70kn7H43aomV39p E5H0VoBZcfZE7V+2TIrV7mrrGfJRp/Q2ZCMa5dklsAmXq2RSYB1ui05QvQDy Y7I3IzOcTCvYRMWiE2qQ2N6k1xD3CJgHT5EwDzEWYvKJwIAxbWR5z2CRKDcD CaLse0452MMZAIyc46WlxUG0yTXDZxrOUvqUBFLk9jNCSpqZYbSkm/ChZB8I vnqpCTyM/Tlm8O6neX8+Zit+xnBn8cjNBa2btyxRGyyUVPoUVchSS3iWq2JA OWEQatjdoga164jcpvOcMFhA5gY7M5f7mX7xqbesTwpjVoGCfgDVS5GekbhO GeqJrI4FB+nsUrRBDZJmc8ktt3Plu13g7KwRKi2fWNLgpM9zaXEmZpiGwXa2 mIn+tpavNmyHhTPR2vb1hTIlkTx5DEVvaR+TDG2ttUlOg5KjYXoMwjrSjWbF P6EKPycdJFr3lYaUDBrGGQgOpYrSNBE/sj5JEyQyEV2BaNfSt3i2GIglqqQS YWEGLVH3khHVo0E24Q0YwO0zIMtSMrWKiguCGSQG6Xp3hAV6rGp8BhnJINn8 RNtLCBqUm5AR8UWWEk146p0aG0zHHK4wo15Qui+R55lJPINlSD7yAUC3dv+2 4lu1mJXQMzER/65DQ/pyikdi9ephLE6LIOYTqD5QxqHEGFHsJx1CMLKg/+zS aLZsPp1xtCFHSrZEiBWJ9SqccZTZAMLo8WDAcgdJjHKeYPHpBWnQnSlaRi9w r7EursGIWE+lzaaZ8cyt6rgDSGRdIgLGwAo0zEIw6pgX0gHG4cRwSHycJZuP hYutgCUFIXRriJhcb2iHXiGsmA1KVgZEvPwHB8+qNEXHlVLWF3nykXLFy5aj UbOKIdiQva8wSWcaIOU4j5xINzrBudltsJcguvXBZBC5o1/9NM1NSiQVTFFq sHsEjpDT7mEFjjFMKJ4NjqgLbUHJag4ARDKBJOJaGtNhTlEuwElv5hLZSZXg MGbGPlTxxiq+Kt4ebtkSIyHBzoxBndy0TUTe5F+qWmi2DRdHV7ay0bBiLBoB qktQKyMxpSFUg8pyZTXgdKUTNmozPQSHRgAcSnM3Cg3xlg8tgacku9Q2LJmi 81WVhKKqhUYT8slg06W1UkwG63QQrVCyPyFbOMa/thWqSqPsnGCPqFYJHtEW IE9niXs/NMSGXpIECictpKG+BbQ+0kZzC1be667qvG6RC0c2TvCQFQ26D7SQ sdAWz+KmgZdYkUoQbiTtAOQtP1I0GT/P4hGdbjp7+Ucd6JPIAp0ICklTIwSg V8rDx/Gb4ZaycWbyMlzEKn8VIBi5RnQVTpc6oqR14up0cBj9tH18vH1w+jPt /3onerW3s/3uZC86/WEvOjo+fHO8/Tbqniir2N3o9fHeXnT4Otr5Yfv4zV4b yx3vYQm7LbSRtRqAUof0e+8vFNTlaO/4bff0FFp79XO0fXQEjW+/2t+L9rd/ gtXc+8vO3tFp9NMPeweNQ2z+py6M5+R0Gyt0D6Kfjrun3YM31CAa4h533/xw Gv1wuL+7d0zWuo+gd6qIkflPu3snDRjHj91dd1LN7RMYdjP6qXv6w+G7Uz14 nNz2wc/Rn7sHu+1or0sN7f3l6HjvBObfgLa7b2HEe/Cxe7Cz/26XDIFfQQsH h6ewTjAzGOfpIS2NKqtah8FA+423e8ewfgen26+6+13oEi2HX3dPD6ALsi/e 5pHvvNvfhkm8Oz46PNlD+Q0uITQCC37cPflztH3SkIX9v++2dUOwutDGWwy/ jHPxNhKnG/18+A5vDZj3/i4WaKgCuFB70e7e672d0+6PsL1QEro5efd2T9b7 5JQWaH8/OtjbgfFuH/9MwZW7O7gOjeO9o+0uLD/aSB8fYyuHB4xbMIzuAULJ 3o8IA+8O9nG2x3v/9x3MJwAJ2Mb2G4A2XExr3xs/YcRp3CF/89tUBT6Yzf8Z wOgwerv9Mxtm/yzgAcPUltsuVABQGOjcfnWIa/AKxtOlYcFAcEFwi3a3326/ 2TtpNzQQUNdiTN6OTo72drr4B3wH0IO93udVgVP0f9/hLsILaSTahu3EqSEc ypbhGURYO1AwAn3757Jl+vbgD+Fi//AEgQ06Od2OaMTw76s9LH28dwDrRcdp e2fn3TEcLSyBNWA0J+/gsHUPaFMaOF86zd3jXXWeaJ2j19vd/XfHJRiDng9h CbFJgjW9IQrITlbaBANR9zV0tfOD7F7knNqfox9gK17tQbHt3R+7iHm4nwac hZOurMmhtCDrSIiNHFphflQ+YMCPtv/bFCom/bxJWcbhHtgmnpTlrKdEBcDL nxHtHgDJI3cdxdiQ+3GAIVyzqeRq1H5Rsbgdid+K2OrJlXlOXiDFrKGjlswL fQsxgyd8NzIOEl8bdcXJR3HUT01wk3TWcG8Evgm12w6aJzkiTssh1I5jSjSP 8otTgtnZLBbFkyGQtEmvoh9ZGKHCsRTxEKeGI9a1xzoUz0zMiDgPBWtaKKaE chllPxS2HKS055eiuQISvhBizZgckyEPNkVtSGhuIu90pEKs3dREQVMir3N8 yoz4IDLI0RGcSWEgpn7oxoRkgJhCfo/rSfWV3YC1AJLhR5o+Aw5kGMHFH7NJ EUciJdvwl9SW71B9eQntq+TOTPi8tGIkW05Ezm5vaQ9HZ4+ZAjYOYmxFOQub fIa8jY11duHQjtpir5pYMs4U7EquOtk3CjFqpeVaSq+UaehOeAFsdaywYhh0 JVLxXhXhBYcKNpMDYyFToy54RETqkt/SXhiiLiQR74isBpVZp2QC8O9qWNwl ruoTzljQ0E5GFcycymzBvJYKbYfCdRuqjTGFYytS3bCYSFiqTLOWFFIQIL2O DKb6vld/+1pO/dTUu5NtdFFB6yWUFdjGIihPYyRMNgbsb0nB8NFmLc8mmGiU HAOnGJuXEvQ2hHOyoMOyU20rDKncS2JczFyb9o7SD4xPG2QGmc5UUlzyrXAs XjGJithVvZkAqf2RaXwF5M/+ox060e55LtXuZ2MVU2r71cnhPtAg+z/b9PMW wYWABIWkjP4/8mH9dL9jjoaPE8ztQ9dBMupnLCTwUAS1IB5VWoqkGLMtu7v+ fXsgHTZgubicIrtH2i5j+63GR2PQtQWGlf+t42PicJOVXmiHQ1Kw6BzMqj9S IBco67xEMYfEPSZujeQMlgtUcGji0cTyesIBZ0ljnEGTq30YwQcSb4yTyZxT 5q6uqrzVUTFPWb+rPf/Fl0QmSyZ66JRMRfC0ZJdQraX837VRstQeY4p3Cb3Z KJCRH7HGY8J27ahyRnc6I6IzjjhN46+iKJB02LAiLEY/iL16LFFxt9iWiupQ qHGC7p+zy2xwieGj+JzjrXh2qTtiKyEzADohSKOo6PYivImi/8+C8/uoJiPL QTiNBTv2FpHYq6A5TLGiRWvQ2X9S4PMfMAw9x3n+ng1K5hwT6vQSTlo2edmO 1oFay9MRRSNBsoU/tDFuR5EqT68fAYJEvluBerW0RfRHRtIhsYdzyyxsljUs f1gdekAr23IbFcWoqs0z1FQnklbCRF5q6EiV6KeZ5eq+IiUkjwRIjQ8SV0r3 aMnXrXip0rgSJTFS+KSMRZVz9yBr63DFgZgXjXDMi7KI81vHs7l7rvYE4j91 9ruvvmof9fGfnq0/3njsx396+mzjLv7TbTzIC9N57746RjHNtaNABfiWmw0B xc8XBYL61y+JBPVeEVjEGVKG2zxBvhL61woAplxGCpke7SteuCHi+gRNr1U8 RtSKZYrsKzFJ2psNm/n1dx6KSkxirhWMyhVaXC8YFa+G2dm28Jl1kZzatqII yURlN4x2vsZ0dWEYKZ2PBJVMyhlJJY5yY1aJWlvijNMiqxhSAhBoz00Lppu4 iyF1F0PqlmNINSqDPlno7SuEkHJaU/ZzHD+q8WXxo3DVzwFMcSZfEkLK9o4w ZnRIjRtuzViGu4S9lXSlob0txHhcu6x7U1FWDsyJxmxbM6GEKZYTne6Hcz2K /wcDu25V3UKSJYgYLLSsIKxzrVhYkRULC1EIMtbZwLNysi3EySiqIjBWw50I jOeqcbEagbhYkSvd9uJiKd4oEBbLCqDkxMa6yZBYHqtmtuzWA2I1tMmHAsBr BcZq2G1G4cBY/+tWI2MZpxfHVtyJSHaF6FhkQ6RDZDU4Aoi4+TnCxwm5qxte 3Yp+5ofNatSHzYqWC5vVWCZs1lskD5GIMzSDiX5AsbMtqsMJjulQpI1qIbOy VvwUF4aKwJHCumNseFtMQuFDHXptcfRNh2ZTJ9Ei1vT4Oy49iLP5L+I0tIWJ sZzW84KV3KLA53RBZBTMgpgBdh5hNDXIKJk4ZqRK9C6xhDGdMOvAPsakAip0 OlNFzo8s87DTCxUtQAdPi413vmfgya6Y9ibxcYkJl8IRGc1zbUCYqnQ8iU62 TNjrLJl9olBHtqcHengzuRjrWG/kjoYKEJUFiu6NfZFDeZdfbF3jrERpaGbK wfMpJ5jMxpzCMHG7KF0JsJQxoIrsPGOXfRUSJPbhiWZh2ZsaVaR2yQFAMck7 KfEyBVcsDPjhTQswZLm+pWyvPj5LJxI8AsbVsD3phw4edUfvcnFhpcwMkR25 U4rjEsHFK+EQFb+KW4sH0drZtrVmfie++A4hxwCNSkVv6VfFaMhQyQ2xGzLJ A4i1FBU3on/VipIi2ifvJyR4VGwzIccA+HLb2mtMkgPdr5gpAXjORNarN24+ sexclSAUk51mk1WHYhcb+kEyzYVKbHAwFVpGCh2hSopN1Rms1zC1UIFnd2UE quI3KfE5FHZZFCrYtYoXWa61iMFZCHdILy18zJmeLTsxh68m9QHFelGhWe32 LD7IojxSFY2LeXcrSR/jLDw+rZ8Sk3W+QMwhmjkxQmAuLi4kckahqVBowk61 wRIWjeS48kDgXuo2rLqkGurTWVV5ZQqjPma6aYURKGl8U012oQ4PL/QRIm/k gGNK3SKrPhZlgLu6NxVUMoqO0BJzRDIA1GooRwVG00OVjk5h5bgRCJEoOKXp BFFUoYIKpwg79JH3MZ82DivFHs9+6BqL8yKzC3yFg8zJkrrBPnOz7JzZMp/5 oCU7yGZG2Y4iOTv3jr4UxOSlkpoIHx4OfcL6OhV7UDl2UyYcDti5hDTzZsJ2 bmu/Li+Ap6Yr1fQ5D7TejWVjd2pPFSak0/9OBqQhvayN6lkTy4sT+VQsd4uz 27LStGlreZornXLAyUYw4CTmYW1qeJVoApGKNcMSUr085lwLpzaIZ0h/IPnD Dr1xoUFnAgQzsjajS3VNM+FRvvOLhugYEYmaxKR4BJ0eqbsVwhAYVMHc+gYb NGXNdKzTKBDrtLTd4m/aMEkdKbhkcI+0tRWtXNm9dN9dSys86r7prTI8qhW0 EcOjRsuFR7VbbrjhUaNrhkdtwNRjHAcsNabfIUcNEzA1WjJgaqM+YKoG+lLA VNzQ5omRITZvKM6GwaleeI3IhNdoXDu8RmTCazSuE14jCoTXaFSF13BkJb+r OLKG9zAU8L6RnITiyloxZRtu3Hqbzb1KWFkV30x17IeVxW+W05YeH9ptzDLY AwQolcY4nSGKXTq+rGoMzRVo//QXnT3OoQ7s8mgsdO2ItNLQ/aIRBO8rhqZt sHfstULTNhYGalwiNK0+iV8SmrbhmqDa8sdg8FkvmojC8B22ufnC8LMNZe71 ZeFnGxR+9n9dNf6sdyVdNf7svs07/97izyIecqNIkkBOouuQu6dPCFQGjWUN MqJ53eItBK/tB8chsWitm86PJYsj4QbKQWSvGEB2QAFkAazjPktvdPRWWQYF QRaZpYk2pkfI6JjDEg2JgpPxFvMp2+qeqcjVPl1okKK2XFbjaNvXGnLSVlpW kbV/uhCbYFWH7agLTv+M98xMBdw0iqY4Os8yICZiPOzJcIgGpxh4cqI1UG0J aktNs1DYG73xAJyTQwIdAmtNzIq0nfEBzCAXzDGkEgkMK1Hp2CCMvQHZCl+s wgvtus5hcwoiWQDyhvOR7GHL0e5Z20NXm8Xx4RVBp/a/5qSVzjLWCEnkW9WR uu10rANM8rhKRI0XNFXkMVTdLJAbw8YKsrYxUOF8lJRDQidblVc12NhQxvBF RJMiVvRn3Fw+1spnNB7pULl1+5aKDQUvB8ebgyVxW5ZNCy2dBIv7RmFuFW6+ C3MbDnOr7y4lf/9Dhrlt/JOFuTW01xeGuVWyFS0k02xBXZhbKfSNw9xm05kJ weLd4LZqoSYNYdg6mK9vdvq3XVTUqot7WYOTB+mbk43RlyfNTTInYiStMrWj N9W15V27Yc/E7QUlE0S7TJJPlksTUQy+6V5jiW5JLoTp6VHWZREPiFvF17/h BBdQQ7MMpVAAvsvokckNHfZEWfFNJCyYrCLT9IeTvvgOqmIS0ZFucLNfCgek Oaqrcy3YbYhmHUsUS6+zIyUdjYANP+PgKDPFRXDOezfSHQ9MriHp1Rj7CWeT FspgXt8GyiqA4E5hcpayDhLGuDZTTpDq0InK/tMh5p8sDg5tH3wruVDuKQ2R Grh6nOhQxqbl40SrGL2Na0SADkR/blwx+nMg8nDjqpGfO+Ju6yP9BfFJIze8 aOPK8UmjcnzSxqL4pBzxS8VbtYg2vNd84uOWopVyxMttF9S1YmKSRS6UlgKK aXEFq/PSwjEV5TvevwLPUEOhAv+lOGg4DbYMn+REhVI9hBVcSg6uAtvEDVbG o8VFkY3EyFwfWl8a7t48HGZyprgGYJlGo0JLH+svTq2VHmlLiLrxlpaj0WeP by8ms8I5cVQ2LtAoxdiNG2WSbI8vg1lpO/qz4CCV/ZloDT27B7M8FYLbjgpR Hz0j+USiInYOfapFaaR9FQvZMy9YP3ozRldg1PvJwbUUyzrlm43kHWrcxg1K lsYCHNadOfYcAWjxzqMr8mSIs3ODiZMAym6RqzUm5XhOSHKFxK0lb2Fuyj4R qNhwpsGGtroGdiFRnfX1xIpftJ0rUH1oLA1ZPKLGQ85trOMmK3fmsjlerEKu KmWLZarK20Dy8QkQqTnJIZG5GsPVgdHzSXUHWz7vk3PeKL7E48TyXEKdWS4i iGJMeo64n2eF9SKdoDd9w2joWsgo4DviKohVgcMOyPh8xhbiIo+xhOw84AYN GGmCia0G8Fke3i+mcMgSCMXP1ukjBMMZcTTUupoyJEAs2CKti3ccFbpkE0Nm 7hHbeHf/M9ZQHc4kOGjb3+4atGC8CL07pRLua2SlzzoNjCudVE1ZywlQcBqa SLuhVlbMELVyR+BbR84s3RMM0kyiPoNLSlCkBFdSFL2mJkSoq4XdpL3mG0Zd MFfFzREbbVIISb5g7NlXYNp2mQqUVVLUmlpklpxTnEFfGG02g22EXGMSTw/J dBuRTAkaK2ef2HuEDb2RUkdxwDkcHSZj2F/7bH5O5nhlIbpRPWgDe18KzUtl FDCOvFgmoGE9FYUjW0NqJwp7oZWMh4btXDENj+nS4xIxWlipYkyoaeEHc6bf CIxJGMf5v6yQYIolshhPUS7TXEoqJbXuegYYYZAkTRSaGIWWLHAj/hP1Qw0G dScPlwBxxRTYJF2Ph3O6NLRagn1NQild9F4sIOvDqUZ8PbTLGinzYCUxVqoA MtT6lOSJ3mw9itaC7DDURJgtWCEtWhn/OcQSoxLOJucd4XZgCUoTNkiB4x74 iIF21EafYs/gUOmWp4ZqhT1HLH8DG9zpwlLeHBae0UJbasWapWeV4etISCDB UVTZ9SDLBqLYkMNGI0LZnnYMuUiMXptEZcpyoBAlEu+i5ISzbi5K7CYhBJBJ Q7LpbCQ20grrehJwldWllK7R6pbvPS+NjwvNtcl8qLKV0MdP5qNZMj59OAoh JUWvJqElCX4t3cGzuK0umFD6H7XOE1lSyf5jUv7QwbZpYCeDYlA+LJC+iHXF VirZV1bx1rKtPC1v8npRQoys0d39CIUIsm0AIznWCM+WDnPvxaQpVIoj1UmW G6kEm4NK/UI5RXDTsRH3lLLYqHj7kq/BttcJsTrGjsrG9GQ4hTpEPKC+hwJ5 7XHTjTzh86oOoy2XwRVzkz/QPVDOQdPwmYe6HDTGqcDPQdOwq9XkoIlCOWga V8xBEwVy0DSumoMmKuegabi1mfVgc8YLlIpOFJRRlGMjOjHx8pXhK5vRuxkM hlaIb+WB45k8i1pJL2rsoB9/1lrsYA2A5fFoOmZF1kdkRyHeZxcSdtqlL8WY lqMK+fy/q5ViSvi5ETmyWElpWEXP69hwh/Jeq75RtrF6drnKFlbId6Px1Cix VLa2pa/tx3zZsDrjDDdBiUCJFC7UmrEDhRI4hKhfraurRI46U6h/sypItUds L08qVmvIWTV00ABRiJfEpMa191O2gOTSjiHa0JcvLJtEJjxKRCndc0F7l/nE uJhQC1qOr9afsL6ekfI+WFIAq250l3Uy1ilvqin+4CxV5Hq0oNIEhxK/pDNf RRo078Gw4EzcMBnHMfeAp0zlyOjziIfQWiAb0eu1pbn8+7JZmIgEw+l5CZkc wLpWQqaGJGSKlkrI5I3E598tduoKyZka1cmZrBtqYXamRmV2JqfN2uxMjers TNFy2Zn+4/eZncmyc/sdZWdyNE/BXEVGNvw7yM5kLWI4OxNGHl+QnukqU2Zy 8YbSM1lH2cvUpMT+JlOTul7+wTI1/S8JFn6Xq+mfMFeTJsduNFeT0Sj+IXM1 WdZGXyNXk2Q1+tJcTWz4w4Z9dqllkzVFd8maUp2s6S5X0z98riaVt2CpXE0W Df9NczWpcQQoeMnV1Lh+rqbIz9XUuHqupqicq6lx9VxNIhJyczU1ls3VtP74 i5I1qRg6JXeYpZM2NcI5m6Kr5Gxq1ORsim4+Z5Mmd784Z1OjWQoCf+WcTTYZ +AU5m4hOqIKK0twDOZs01eMuxdVyNdWPgunvJ8sna3KMH6+XrAnbHgO2ItZB yYvggDYCqZtU6LrlUjc1bKwXSlNVn7oplOHJTd0U1aduaiybuomphqrUTY1s +dRNQn+UUzc1rp266ambuklFSVgydVNDZz9SqZukgaukbmpYmZui62ZuajiZ myI7c5Oa04LMTY1w5qboapmbGsHMTaVsEHWZmxp1mZuipTI3Nax9DGZu0otS k7mpsUzmpqg6c9OzL8zc1FD7/iWZmxqS2KuUuUktwDKZmxp25qboSpmbGrWZ m6LlMjfp7azO3BTVZm5qLJ+5KarM3NTwMjepQVVmbopODl+fwjnYM5mbGlfP 3BQFMjc1rpi5iYpcMXvTvlIGVqZvcgJ5fVn6pk8JG0mM0V1LYkhQzKnEYYeA 41omU5MVMpikssQxMF2Nl4UnOSkFGkFZaZt9bCYxB/9qVymNFsQuW1Fhb7Xr kOpkuXRRVvhLCprH6aKi30u6KFqCG00XNVLhFL4gXdT3aPHysjZhlBVV9EoJ o9hqQ0X2rUsYFeZ0xIwomDyqlqJTiaOogbrkUVdMHGUtxB8xcRQutWOadWMJ pJbZTy+RlKxtTSIp1kFX5Qa4QiIpasjPD/AVE0l988Q9Jlrm7SfugQbUMfn/ XufZ2X04Y8aoAgeIoRwRm3+YZGehdD3HsKDZ+GpZe/5jbWHWnnh2X0f65mUg UcF3dylorvLY+V/2/rIN/MxeD47Pm72v2Ed9/pe1Z2tPn2D+l8drT54/ebwB f68/WXv27C7/y208D1eXfx42/h69MzFmGXIiUrX0R6mJ75DjVRv9vXG1tll4 rxKwSDzlInINQykAM/Z+vLe9+3aPiTXslb4WczJvRbrrsnE2T0czNUr26MeK TRxvU1SCWX4p6INI7k+Z0lGqWQAvA0j7hH6QAPHo2LxQsa1ZLSgZAY2dVFdp fPjqOU6AJ0ixy47VaCPlkCqKjyDbed1Ek80Rm+2oiQYKHPGzOY4nc3hJ5iQf RRKdDVDXZo+OLwZtZG2lpLHKDEU9YXqEe28V7WpwlRpeD7CKr3Cu7ppETq/K uvsgJsPnE0nngXfdLMuVSVD38JijZzZUsD3Y5UPYq8PjV9qMDa7oYXo+p9iP 875ormpXVist3d7hoqDQKqQY/KyDZHJQd7L1y7UzHwzgfoFmFdnoY9Iju/R4 1NNOHEVrhRxTWTPgJOFFriayUvAi7RFPAO7S2TFQ8DBc9igi0kHNVc0x1vH6 2ir3JKrkEhNnErU3yNB9fwGkD2qKX5pdw1eGZ5hSHktLuE7rkajV6EQNPagX 9EU+vOhn+RnQcf3NTdPJI6uASroE1XALcN25Dna9maf5pl36T5LKpXikCnNy SHb3Vgct+TxNlPFu5b7K4ciTc1RP5nJEGuWdtlnXpuq/qTa+I/mLOcAE7g9t l9qZho3WBnEyzib3i8AOWX28fwtU1K9K5QjkljX/PWz2RcUiqG4CraeFLAoz RoNkGM9HHCfqM0zf6n0awyI8Smb9R9LcI26uJPTnowdsDBq4EYPa1soIEskb 9h9V7RdWIMVVblLpVlQcDWeVUE1UgxIIP3qnX5ksoG06uxMpWEZY4szMpomm Nenaow0joWgW6njpYKtuEMECKPj5tF2+x9TlJRGNEBs3zi5ddRJGkcX8JdDX OqDyQToLLEkYcCwfITSmGs8nlm9MMhmQGAFAc5Sdi/ceAjwF6ZldoFetwAIP E6eBMh744C4KtkbbqM33xakuF8sXnL9k91FqdpjNRic6IalKAH+nQysAkHbv 4ACcUPVxJzqeTwLr0NZBsbBbBjkFWk2BraYJrjajyHJiV0uRzwQyk9By4hzb OrgstThoWpCKdgIYVktGxiNi/uwMuJHzHHlO7A2pBpjFE0IQBAglACzkylc4 KEorr3rs08Jd5iw103EeD2Bdm1Y2+EKgS6zKVRHTkXWSVlej75G6WcWZr86y VfNtlZ08WM6jb4uFxbF/w1JSZas/uonJ+KuMfQNQ4uJXWHavOUNlAIlxrnaK e1VWQp9MzHDO70AN7BB9qZOJcEw0ZuCxPYueIvtzc51XE2GNxlNvu22kZTbc CpXvkUPKnYNXXC+O5B9m8R6eMhs3Vu02nMj+eGAXdXfOHpuz1UiU+i2RI35h N7atR/4WBv7CIvL0lvMSE22kd3xOp+WMLI7vcrv+Iz42/396uHt4E30s4P/X H689Zf5/4/na8w34vr7xbG3tjv+/jYcVYpS/XEw40KfVsiJVhtCM6oRTJv0K GgxRsEeKqU9NNMiMg/JpkWEzyYGh6ObqSqPxINpRDF10crKvqRcHX5dv+Q7W 1GhckT7J5GOaZxN69THOOYYlFJ+ZEAdA3yPnmPTnaLKJXM8DuKjEqwwFh3BH Yvz58aoJUGmCN5E5RdrnNySpRRH+UIx0ieh5EB1JANefgIgFnM5mG2Q6827C 8dWg0GtUA5H/qhJu8ORacEtM43O03aOvZFGyQlXespIFRRgDZQYpntMojkdZ AC7UI/Za+MBrtDMCVpoccCeDkaTEUR43ZJGKQtdREbVOum+6B6ftCP5FFWoE Vw93e3Q5u0ArL/fORAMVxhKbm0q0oIPNKxG1okjTgb9hcNekMJ1+NE05/xPq pDgCY6FaE2NhbaapMr1SpJBGJIFSuJYsEBZIyATtTuL7BY+N/zuTGH2e58Xq OJnFdPY+j0df3scC/L+28WQd8f/a+vrzZxvPUf777PGTp3f4/zae7/8PbLES Dr5ornfWmv/nZeN7LR5FFfP3xGwhX/6iuacs5DoXzSgFJNQjgporP3n+H+0n //68+ai6Vv/fNl7B/8p1Hz9+rOp+/8jq/lsv0D/4Y59/5o8fffU+1taerD1/ +rTy/MPD9N/TtSeP1/H8P3789Nm/RE+/+kgCzz/5+Q/s/3Z+vg9EW6f/8OHX 6WMB/n/ymPV/GwABz54R/f90Y+MO/9/K8+hRtPpgFQnOZDPaefhwC382Hj2C /0UWIERVz1Hc/wA07KYiEbHeUs82mSVtio3AT+j5mUu/JZumDaAR2vjfxxXF SXWohOd24EdfTm3V8D9e3RyKW1rKIKoqBLJlBCXNLWkKVWsGJU0tYwzlLqGV A+mqBlEy+i8zieJGvsgoStqoWfSyOZRehCuYRFWkb+V2fGMoWdcaYyi919LC F5hDWZZQ0ti7k201yd2Ec4CRtopf7Yzigv0dUEdDMW6YL3MEmUpEz8vV+JMK S/Q9ggmwwxcvrXfaj+KlVbKp8MlFswFtfNWn0cCQGA3pYXMTeP8WJeqiQF3R Axj9SuNvnNRkCAcjP4++exGtrUR/0zrNHiaq+NyZzouLHmoHWr2z+bDD8UVb KytbpiC+p5hEA2yoDcuWQzH8eyV6GK1L0d8av934NMmHsaVmRgMDoCySloxB 5iTFtm5kRDKY6J61+gXKGpwNgKG19Qqqp0j/O+nNAGkM8S89DW/QHCjNams6 y6MXWGur9AktqukTbIQ0Kw3wrvHAcDC6V/mOYNGSd9ELgo2//z1qPWhhk6uw qwgw939Zu7/iAI0FC/RR7b1EscErqYXj/R7Ve7XghqVWcVQWqOG7hy8UgMEv AjCnjzyZzfNJ9ADxzLfZYP2dJF82MMJW0LtOT28WT9t8oJ9btzOTb01r/R6f Gvr/4mv1scj+bwOYPaH/nwPvh/T/+tqTO/r/Np4w/f+ndAjnchj1etvHb/a7 J6e9H3q9xp84PLj31uUVLqop/jte4Y5XuOMV7niFc5tT+Ehy3pc3QLb0aaiC l4AoYe+7TcmvSOOUjy2gy34LvQ/SN1t2yf/RTQgZifR5FOI+tsxnl7KVloQW xn/QxBRrSwHdfwVZ7ZPRW1FNtbrJmG8U7TTLX1RVsmvZwzlPZq/mGGbCTKE8 RV3opDzXQJvxrCUViVYMNWwXV2N//2u4WmNKrvcJA0IxG2xuMlRGhkiltwyZ 33MjLyNFqf62dQOw+ugBPhjWhObzWie9iOgDlJB0GJoCrwVRIcFl49Wm3QRv 4A/LnAcZw42yng5cmUHYZ0iGIbyFMF1c4EbHFGCaFpwqd6S3tnfO4TGDLZ1k d3j38LC8X/v1Vvc1iDi8DUZ+/Ba2N7xoYVSl5E7C+DIMvqf//rpVXlT14dZH X485PfCctfjjzYzzT+i7P4yA4HB5jW/NLf3jPQH+fz87P0/yr6f+W8D/w6tn 4v+3sb7xbH0d+f+153f6v1t56vR/BhCqWfM7nv6Op7/j6f/QPH23ZO45RneQ 8wTdkM7JqBPzQsww3hvy1D5TP58AqAxcBSC8GKVnpXdp5r26LB7NLqdJUX6N AdMChTEsovO2/CYenWewvBdj+6XKIxiP7LdpNo4n6dTpBcA+icduKfXOUmYK crxoWu9OiJE8zT4ksCT88eZ4xQCTSMpBHtjmJmxeaz6RcPcEjyMMaORq4WxK cFxoHSm3Ed1DP7QX2j63ZevK4FOnN8YIfve4YVu5hQWgOdGj/c3pkt5HzabR cokmCx9qFTM3xYPVl/FgQD6ULRgO/0Gf4T89cZSlCWGLKzevdL3GutrShXtX W97A+toL+Q+7TnzSfier1YHRtFZuds3U7PS6mQnK/BET4g3DBRknO3yjenXj W0oxt1oB2FaLh9a+i7cNvyLt1RsDdfEZVr7/IRrxLqC/Pb0ooRq1fZRZGJh/ QC3UBr/f3KQIkr2DvZ9WqJ63+fYAYTT2zy2nJJA4k9bKVhh08rn+dgsHiIei gcA/IgCfskaIUb//PmruUGRszFVFMMEE8S/NJn50VwBL/9LcjJrSgr2ZgzRv NTtNmadIAqZZgaILu5EOpubpAUEw62XD1v1H9+0tw/LfvbDb3dycwEv7VEJH pTaL+RmeOaBosLBj6HCWZSOaUo/c4HE8LU5n13Lb6Pfo2Laj173DP6/wHWQN zW7i3r2ovomfqAnfVEgWHDciz7O8Bf+dZBbQoEPTJzwAh7AVe1TEYBOZFOea wQF9Fx4RLM9tjEOsY9T0+QBUrAZtJ1BDAJtAyf/d+h1PpzckCnIREJDU/YvX mJpSnwz3jqGw4QAa61slwObDTq8HmbWK5aOlFQEEd/Nh8ADd79zHf6hDU1oQ DIkhZ7nGFsoUSEFsJaAiALQePuRp0H7bsGu9tiaQ05iqNs3+ZVuxfZUdV631 L4ANrmoEhT+3hzaLZPY2/kwiYhc0xvHnnm1ntgRdoaqUCFmhN9RXjKm7/W7/ tPd2+y+9k+7/u+cc8upq6s9bWxz491QuTE0H8X2uqKHoHoVDUYtUvqd7/zVP 5om6pAmUAKnwW8ucjVux1tIqJQqaly8o2vNe7/SH470TjBNrL/FwBG3d4nVr Lc2HdDRq2faiiuiAk1dJZ7hcTmDdaEI9HTLdXkF9KLFngItZPk+8L17tzlme xYN+zKpnVcripEjT/AAoRPP1r1k6ad2DVytb9Bt4f3q1whHqm4OE0iOjxKJJ +YwH2eQ+ZcZMZxijvEhGH5Piu2+wIQIL1TBZs7b8zVnU+sW8qYlFD0JTA5qy h4JDDHCbDFpc0DJXdrHUg1ZLXjxYidiswLY0xSnaZ8hFgEXS36r4NKFv+qND WZ8nsx5KWVr3oFA7uodlV/zC1nYMq/fDERB8JzsDN953BPi+pKC0TTiKwac4 nbVgCNHDCLFtd3cfEEj37V47koEFDgNcRPP+jDgp+k/PueHVCXcZQfcOu6eq 8T0Ng3aGqr7Cpc+4/aWWkAiyfxCtr208WVmpwBdY2KFugvPwl/q/fHRssGeW 9zCcsY12z5JzPO1tG2Gj4fJK2TKbL/pxMu4NAT7zZNi6py6IzU0SXq7YvVkN aoW/PTNDbGis7qx+cPvPAPw+BJdBH+lhDPdryBx67RaIUW9BPIW0cO2OgC2b zC6K97/CwP8WNf8zxvwlzdfJGf7zNs7xn+1pzr8w6XzzP+dQpLw3gQeKUpTA 7fk5/nOSTPGfw/4M/znIPuI/u0m/Gf1WoouF5sXoWfwNTxlaIsERAxaLf61E PY095DDNKHMdYYayHT7JUKCg4i8JsmGfHUkhJu+JTo+3d/Y2DbRIRRQR0idL TigAYeru7r169yZclz7V1e0evD4MV6VPdVV/2j4+qKiKn+qq7h0fHx6H69Kn urqvt0+398N16VNFXYkZFqy45pwdkrWojz6TAQgmHhEw5OoiUNtvn2aKrwhs kcC6KtKZjXvw6ldinKL7zLUOiFj/1NpYcWHc+jhESuz+2v0VfOk0Nogvv1pj F6gkw8Y2v8bI0slXawvPoGE1TVvPlmyrh1di9AiunrU1a7X0JqMcyEiB8PFU GNGMLhB7h4XUWPfRtdr5WWcCf7Xu/zK532YEvaLHB7fNyGpKAd13sw4q5For fpsWLNuvfmsEe276Vd0nrHF4oO8mGjzGELQZ9390P5SA/cchJabdQXr06xiB LPD/2Hj+3Ph/rK+h/cczdAO5s/+4hafO/sMDhOChurP/uLP/uLP/+EPbf9AB pyhfnJHcxLqWnHIIArhoeAxyjkss8d4lhqRvEtK0MceNGEHsHB6/2t7c5H56 01nesLrc3ETVVEhPyTPsfUguXWZtB//uUlTXVg+WPSblVssqLvRAqV9kOIGQ dt5vbvYm6cgRJKdIT3PLxHG74ntsIV19CbRaNhmE2FkS490IJbLg/v8qPqAL 7v+nTzeemvuf4v88ffZ8/e7+v41nkf/n4av/3Ns53dne+WHP8wH1v5Rphipf 0Dua4Y5muKMZ7mgG14x0HLt2mCVXUYxNmc4ubSvM7+neRfPPm/IftfBZ2IfU KsB+pPZHslkx3qAVtEg7QFbAV9c5k5rKAel8TBZQNk616ziclkezND3l+1ei cS9eJKxOiKffW9X9aX+M85ebmx/j0RzGBfWiH+PRKfy7dc2W0hn7M0VI2F23 EZpVTzelCUV/onhM0oKiENOpp3ooJ4dK98Sbj8LhKi8rqmUDDy+v9Sa6J1vp vPO9CP0KAf/WJSbKtOkNebdaEOyS6YtPRln5ET4qnhcgEdop4NZ81hIoatnn DausdBS9fYOeduU5L3WE3ekIS8KRnewj9x2btt3g+Enh5YzfCzlFI7tFJ19n LDWOvjSum3QEtV0UfVL4WxP1V3gC/N+7g+5fOM53V2yivlAMvCj+z+O1Deb/ nj5eX1/D+D/PH6/d5f+7ladO/hsGhG/Dy91xcXdc3B0X95W5uCOVAIMTc8Fk yqkfXAQQ9gBc1tuv7FqnuLxFjnU0iNA7NbC38SSuqHZE2ZDcL4jaaqsGcN8N CLLr3fnKY9jcLL9r6awcDyRl1VIWQ/BM0wG6dqSDpWvMqcb8CjXOqQb8ly0W Nj14avGQtQVaD0bTgv+bF9BZa26/gLZa1N7fboCuq1j1/wks+40NgGju0CjO k1l3t+XwDLAODvlL1lcYReTf1yS2SAH84GQ25JinzX8bDZptNE2cnK/QYitp wUBFVL3dKUlGteQgm8FV2vLyzCBrSjKPWdIDRPpZM0YLmnGqVBm8odmH8aGS X2gDAsvM7bdWVl/CD0zp2VphAxPlJRAhkEbsWQV/6dOAhVZUnrhkICYntkuk +huNzNqq2xvhUerWfZB4S1a1suWCZZcxf0G/+nqaQfyuV3R2IWsEBw5ztc56 mDyqZmV1BVP4NlZXVlWWMnAVEqo5NamjLNKhJV23I3vM33JLvjUH9cd+Kvj/ Em30JX0siP+zAew+x/+Bv9ceY/6P5xvP7vL/3cqzSP9LwHBwcrp9sLP3dvtg +83esacHriphZAglYPJoxDsZwp0M4U6G8E8jQxA0YEQJ0Q5QODM4mP0LzHcp +bhhgQeYHR3WjzLYx5R2s5QzsiSLqAgplMz+Op667waoibZf4JFmrze3YFYt uAiop8vBja0wRIFIQiYnNUZiWlLIcYOSiN14FqMfwLw/m+eYnRTVZ0V0j4M/ J5aAArbudZYD3A1gs2A7OWtr4YZe3pKfPBX1q0xCbzWsTz6sbDKm69ueifUy CCkfXEBPk8/ddmHvSQiTWd25ewMErSlEVZm0txvDxyple8J9TPPZHA496eSV Hre1on0NUHlrteQUZ5dkFWRavniyuQd9OkdaQqHFQh9VoGenyUECwJhdesVN a+qIqV7LW0YBn3V9LU5yQjRXjdWuaXuOWdVtPzoacTVXQvxSpoIH8b9tTFNL 9eeFlgKUnPKQf6LEuHZzVBHezscljbpjQiAxokMr8zJSf/9IhVwDBPdbra2C X7TaIqE0vGmc5t/jtza1+5L+ewQvq8rqxtqm3ZfmT65KdRNYm+gtx4lD/GCd BqK9jvfITf7wtPv6Z3NQd+HtD/JWw7xqzmviZO/0TXcXQ3m07Xfvurvm995f 9nacdgCP8T9qbAVcGLCZZ8nsUwKkA1B3+BMj1buXzcc0BtAFPGc3I56OfD0d s92SN0otETXHXIs8zSuxtYnzc3QStkI+yGBfZ6NR9gluurPLcCR9lM0NAfN3 Ot504VzhV6Cgqa4zp08XMGMtAyDkQHmg5/1+kgwKpIyGSMK0VVvYLVWKrXoX MZJzycBeERZbyBJ7K0KQ4bpxVUBDECJoegSalqOYRi3WOzQ2DUxvE6kkFHIA 4bS6jtG8MIEX/gISACkJCpWjQhzarYUfrs8J0J2qQAniphVVAyL5zqYRk1hD UGXuF/SZcowbiJrgJrkLKPDDY3F94RxZk+XhFhE9Fo+2Ks6HvuABHs7G6Wwm 0OdeISs0b/QpZEIeSgCzgxdixJewao7ARgFeNahVnS4ofEKI2gMmsnobZBNr ZgYW3I1CWlT6B7ShOi+Aflldx5/Y/zw362zL0WFjSbgm7eyNp8hR6CbM9XxF k6+yxVeAuJHrL0T2KAuw4DffEqyqgcp+VwwW2aVIHzECNF6S/Q+rZ3FBW65S swMZH2ijTTsrc4N2nFTuwN8ln4FN66ez0WXE0UUGDlHwP3XDUqk0NDCGrlmL SNF1LgBmR4mDtVvOr+ieGKHatZLPSR/41ZbJm5GfA/AYlZdB7ExZ4HXRGw6c 4dpdi2zXwZUc2LA01l1LFhwsX6beHgQDhzhpRvAyeBunk/0smxq5vbL7TLRJ J1cNphJxqgg/26orX6LZCiKufqBp5khYlSgqPtC9qbowcW17OLyerLD1Gobw 0bym9y59hOH1BQQtxQ9xet+7mAZJtB6jOw5d4Xj4sB80KaB66TjvpYqCczKG ZPkZhyzMk2EP4EUF5JvPCC2YcB0RBejYKn/VwU2iHhsj2gtosyTcz3DiELKh I/9Ar4BTFLhfSsnXK+KPyQA744gPN2Dx6VnHVQkIv7Xo8+75l6D83zd7+OI+ Ftn/rT3e0P5fG+vP0P/7ybPnd/L/23gWyf9P9o5/3DtWx9cT/Qc+slDQB6Eo 8NxJ/e+k/ndS/z+o1H8bw/TGfZQ8FGIUCBOf5glKW5A0iiVrQARk6iQgtye5 v848UNgHT9uzAcWX5MOYC9e4ilWJ7QPGhdLFzUbmv2EBuvNTc0JaZH10uN3z VrJSUq6qZDmRpFx6c/M4Ge5gpFn8DcfsFeyxJzJfYIIYTBFoClk2K4FsfsFy XCJkHwaFjsne6wjNvTxXNodlqrOfM8GwSOSQFttocZS0RAABPMfkXGJIqsmZ wTA/gYEJ3wH0j6SqM7fKwt1J7BU3HJyxe2rZjJ0I7kvqAGaYr2hRF1QMlG2+ QoUq7J2Iv4MO0OnTSEosAcNVhQS+4aXPQDrjQsbxCDarNHN0FcOPJNxmJu/d PqLcz9oK0mkIWU1qKFDY7f/67B79KbtowL5XyEknMsk7m+wA1R0wayreYIp1 dobKsdkRcJGbntWXwNkOrAPQi0cAlPyi8uj1bEj6xqkx5RirNWwEjGddnOM5 jKk1v0EXtmXGdoujsnn0ACX/rTmTu+c2ngD/79kjfHkIuFr+fx3+erLG9n9P 1x4/Wd9A/v/Z0zv7v1t56vz/yoBQpiDvYrnc8fJ3vPwfmpc/cdP7Gfs9ZHk0 2WeQQTVfHswEWJ3ib9ifzEbLZP4bpeN05jewnM8hpcTxSpFGioLGBALJuGKF 7uGx+7IPmEetYZa7387TbHpCpkfB94A13PdvuodHvZNyp++Ou+7Lg3gMe9G5 cIcczHOYBmwVhwHzxYAd4k42GabnGH7etUEMOWTW2Syab9ziVV05r+nm+Tae Luv9eXIBB22wDyzawvyNlkco23feelJHd6mjew3fJrEqYZxXEeNKu5pBYTLc DzcWNt8fdp6cA7bArTXGkrbC88FwoqOMsO6TPxRWkhkocjMj9gfr/m4pZ1ZS AKN7E0XU1m5PFLjeeKxiIZSWJlKsud40H5n44Mwd+uWsP+1NgfFvra6bl0Ux Kr9EtFLg26K1Zt7GA0AY9rfDtwfd7tvjnspTtL37tnvQg3EenBwdHp+eWP62 k/Rzb4pWlgVSCOWqqM7tHe0dv+2enHQPD6yqfTruvWk8uyjV2jk8eN190zva Pv3BVGAQyC/DVY733nRPTo9/9irhcgfL7x/67TP3XLQmyadIIwn/M4lquIhG C6bMOJ7WF1BzoAIGhfKG2hlr4IKhAO0AJOqUt+75cAagcoqQcqPui2UEks5I hhfn5/0KWTEby0KBj+9/xVmx5UacF8nOeLCfTpIWVcYmPoo0TazBeE2qjI2A JM0mKALsJ9MZUUPJcJiQRBRJyxxpJJTsIxEoRNMFJSZWjVGMOd4C4gDYWGuO uUBba2vPn6t+8wRPgjcYyj3CJ9COyHqW9LNxsssn002Uh8uUGmExLYs6rZgr 5v36s1+tT+rMup9sETSfN4TnJtIJm/h7U2VftA2VEYswIV+8//X9BmcR+VsE xN9a9Fu7/q8q+b/7lCtqu0FaKDVPjDu16sT/V07m9kq0I54QvNvc/LeLebNt 8JplFG9PK/31/RrOq4ky3AxabFaWW8dydnem5MOHaSmthUae1WO3t0qNHd7p savvX2nsdnf1Y/+up2Gkk6Blohs+WH+MHr6ITNGvM0rTs2RCqh5qsBu69vbx 1pOOQp34F6TbF/VT3QOO8FRddEf63qrrzr/iqvpDlGLWGUdpRXo+fkVUiYX2 2qxehC9Pmm27Z50Esh9TFhxpYo9wHvLw94BLsbeU83ZCKaSHOG9nE35F2GEa j9KCrWvRojUZNF0EJTlqb4Mo+p8SVaSE1xjibhew9olcwLbaTLLMqct5y3mp rtutQNHAB4X5b5FsnaNZppuWtw/bRz717wotCkvHefT+8OgUKaRfm04CFL3N KmXJKhNO0evu/h4hJHSkI3tieDvPZbNhrxe04z0tyfyD0pxmVEOQ2Q3dX7m/ YLADp5NBcjY/P8eLbIz255gsEHMQAxSicIuv1qbdiG7ZtHjRjlZXL5LRlMoU FwD7JDURQ/umlz7m1rbaIW8W0Efq8ekkfEcKNYQRJ2FZXUZnFFG1FKmxHm3B v99T7/jnw4fO9WXRElCiRV2nv1qImrpHgRdaqFLaZGyNEFe0Gq07idzwvoEP mOOuuQqoxc/IJ6JSZyL4WOmMdfWLZvT3v0f6J+1wqUU5Tq5PA+qSW2sr9c3z 8Sg1SDemnm0ooZBKl33IyPcX1dQvTYpNnOZJEcURxaFtbpVq8z6WE3TSSodS FTnrZ7FI0ArtFdw3v9bPFFC/vq79CXnktF22HX1KokmCkZezySwHIMg+inya KKHJfHwGCNhpTq2N3Y6Ij+lcx+yn5K1L1ZqUMvjxfzVlE7z25MAd4eGryll9 eyjA5WFMughh8wRJt+yNVedJ6mripDhJmOvjsi6XtMu4urYMihfgmNcVeZsW /dL3216t4IyBj7GW7Z4MrpzdXqCtzCjNxtMgXSbQifkCd47QWsICTs6ZTULI 82T2Ix7pVtMMD8m0KcvYofVS9jFLgBL9/UXkyzU3N6FDI0PZ8uoqZilUkW4W HCtLHFvYu31OApM7Odm/3clBh5WT09zU1SeHD5q9df/ydm9TQAK90KC7CAip GYYQoGAAyazfiYZ5NpYzRhRQaI0WrwNF8zuCo4l8nGZprr4kJPqqWBP2JNlN 85bVg1uE6eLu8GQWj5JwsWtMy/AxC3KFlvie8gKUOCOJob3WjtbbEWYVrByq vXh+tnR8GLmbNRW25iCLrIqK5DVcjdeTOQ/beBNto5zz6x0JX2xaDd6mzdLZ pf8qVq9cneYNHN/nCiJOaEG4GnW0L3z4N93N3EI6id6bUfyK6VpVuA3rvESt TFE5TWeu0JB8wSZ/aa5scnyw5HPn00XsJBWHV0UyE4e0Fg/EuY/19n6r6zlw edZeN+bL5iYBydt4ygQfMqDBWyYAWUWrqToGwNLVS2Bl66FUNtbCxQyhAZU8 /dOW7kOlcl65RjPo92ca4mxUXk5OSfFJSaugQIiIVvNA0KCptdLVl8M0L2Ym Z7ZOaaVeecPFR0uRzAGqXDwSn6slV9xtUX34tO76VTygFr7SsVNDqDp0cJT8 sybHyjsvJXQYOFy3f5rKZOaN0W4lXC194+UGf6orW6l8bDh189dLDlc0bXlR EnWgYuh1d/9073grdJOgQoaqLrpIzODqbhFnKBXXh+6ymvJTukREvajLMM1W rwImm8dylHC+vA5vt/9Ca3HS/X/3givxNv4M3Z5A7a+zFN54KhYD+1tyHT5T WbtZezHqoAn42VMji26XZM4rwQXRtbJzW4j9hcviao1roYR6/ZYkhszon5u+ 8LjqWnRYggmsjBB4LLJqhdQc5bfR94Urdw+PVb00y5eqgoFg8fZM+8neBPrB uhN41ys+9nsJvrlN0YCrfnUs8OsEoQogNZ84sNiFTV8yrAVLNg1/bxHjbp8S 1V+EusWo1fREo2UO4Uqt2z2gvc0AHb/uRdQowkJMam80MSucbOUsE1zQDlfL JqPLikznqgacSeLdOR6wllMEhP9lNeqCmTsyg/C6FsXouuta2frvcV21iORr rKsreAgvLPLutLJXX9jq5n83K8uLanTdi1ZVVVVYN5pSNCZuxkG91eouuPsU PU/VFBlaXQMolHQ8p2DdfD0iiSLVFSFzbggZCdN9djlLiqaFvr7zEHVI7S8T dNVpbCgaCdqPqLIavduks1iVobud/WsesnbbuO2yZtKyDP641llHdeNZgsPQ 6upk0Ol0lESnOk64CY3jqlVFnyoT0dTBt1ILutZBV7jEWHnmau83I7XxOq4V atey/IOJ2PMpJUKPIisKkYFe16vrm1HgefSI45T5kCL2q+xtdlnMkjHznD6R Fe3awyxrYMwA1oL94wCcOHS6eVEH0W/h3qtmIHH6/BYcxeBv2qCMdwRIVJJa RqMkRkcMjFzG4ZG0GBm1YCNiSDmMpOAMDH03KrIIWCn0Czjpvvnh3RGHNPtE /gIfSGvGwoxolo4TfVSBci3SAQDjC9+u6CsvuzVj6peM2Fs81DYOudd9c0DD wL/3jo9vZyywdAysUXweo59IBsivKO0FR+GkLZnm6AIyi+YFb0vcR50rbIre iuBOKSeU4Xymorhd7azcxnmoBfVaKCZ28mKQ5q3mo2Y1NDX7MSp7+xfx5Jz8 R/Ism0WcYjcjXH8z21y2p8SwzbTT2TRh6xT0Sxe/iGIrevYEL4I4Os8y2HPS I1MY52xK1R0LhzWxcIA6JfuGPnbSSktQd5xQx5qYSCfT+exRNp/hPxyoEWER vfqoCpaGtR0kHx/9d5JnwA0d9o53Dw/2f1axBUyByXw0ogI/HS9b4NZuH6Nn CqQQJb4wIJdDuLIFaERkwEtFWET37mGZ9/iKg0zCu9UIzeVeRPcf3bc3hKpR KlK/tLtHEhoORg87jEVzyiKMrVmjwM/fvbAHu7k5gZfhHvGDAWLPXSOa4Yhs QU5YBImPSLhnHbQUaZUkNFAYrSlnnUnyeSZDDnyHD57knOw2KGYkCm2MKPx1 7/DPK0G9GMF4hs5WvvXEb+Wmxx9wJ52W154/fRrAF4ElqBD7qMcS/+zEEzT2 YFAz2AWFPPgdXohUh47xO2Q8mqX2zNMssv6HZCb02xLYSS/zskJys2TuX7co KnKVuwvOpgUmtnGtDSd4JOcYN+CDU0SS/l5XsCc7y4NF5AmnALm/iLdI7bDi cmCLfWVGFF3p8vx9aTjiwcAXi7V2soLZps1N/neHQyNyqBS4Xnv92We1ca76 opRHGxEDxuQwq1Dben+eY+Mt3UtVvYSKjy+JiassRO1xCXN9yiuFqNd9a78q XhPhz/tEFtel+wAfuo8ZpEZxcRHFGHH7POXIT9mQ4Ylh1KlX6puwPFobhJUB sgJwoSBPuLkp3pIK/k8zyn7lt2q0j87MpbHVl/oOu4LdwqtRPPnASl8x2EVf ZkSHJblreCpOIJY+RluCWZWGtBUuT3FbAGCgCleF27eiaGrNWqfaiBLkiiYs LZBQoEhg4z61Ta6NmD1yEDx1G0y4WUSbHssWKnNLy+ccGB8qAaI6RMTLxN+n +Lt8EdjlPwAV4dbAN+E6skT81+rLMyjYmySfVPTTlmo3cPdU3Mnahr/iXG9u bo/QX+nyFTpwR/dCdzKaP8WjEYHW/Pyi7tLHIGnscw5MQ0GbgpMg6UohnBL0 2o7+Oi+QpcLwBFtRhhECPgFN1PYbG2Ox+CzLZ+4uMdqy1ypPimyEierDS2RW t3oloB4clk8tad23MsAzKKCaFr1JOmpJoyVyjIYYPofbGC9/mk0o0DavFCEb XB3eiFrSxH6aZ7RlwDXEE1rBiKMrNWuIDPtovULAzOZ5kcC6UWyrITGu3vky F2TpaISQPozBw/pq+Zc9QFc9PM5x0fuP3lsXaeGQXFc+Da5K0uksTxZ313A6 9WBhscLTSaGIj5VGUVSeHLkeThddM4UtR1W0kXe7OLPRJFOFqjMk+9w7Pj48 tpMkLrmy3QncPinRMy6aqTgp3dEoOQdwxOE3S92UXJKWaPHd5MMk+0Rh/89G ybh5+/QcSpiVj1GYRNOyfoSweECuuUHVq7XixohKAMteCzK4TwqUwozjGVp5 cEwPRD0ilxK0oGlk5lMlPrno0QtBhtb4KAoYf2ypUgpnBtuy0sagGZeqo226 lqmYmmrGpoxqnvSzaTIAiBjNi/Rjgl7P0aj1QLtoqXI1xmIhcN/de/XuDWq0 lXLACg6KJ+xh9CCF/9xv2jy3lckIsJdx5249SC1NulVBeZetvgSSn0qZJEiE HD7mQGRl8QDDMSYtnzSkz7Af2xwHEZYHAyQxhehapG2/Oz3svT3c3VuO8KGG dVBHcqLxb5eS9dre56T/mpNXhDAoNRvWPvjFFK57TaoHuulkKPYOQAnYgkru j56QSVvdrguSMwhOTzd0mVqupbfMv9tOi+Q3dUagbjty4YtkYFygNEPPRW3c Y/ktrr5M7JNkXwq6QeNAU9Kf6jJumwBke6FmLaEy17SHJQf2u94AJgsXWV6E 9Iv4qGOHUjDs21Sg6BveVlqfp9m0p4o4Zeowwi46dZK0Ev39bZRQScDhwOys xz7ewEd8RSeU7SAAbO6KzicjZx1vAv4QjMqiCW3PvgN/tpi/RSd0uI8mYnv1 AEjJiWs8QyCZJzPXJa8sGcWaqy/Hl4AOcxQ7aTQ/6xQf0mnr/qYWyzpSU2U4 0FKyUChny291AXJVQ/2846LGI2td0w6BRF3OiSh3OetPv6BHz1RnmQ6LYvQF HXo2LHaHKk4FBeWBf25dqQC3zdHhtiGkJD2cH4F2Px0mxTSeHGWjtH8ZuT+3 aqt2B+8m6X/NkwmAoFQvv1rUxDZmVpqg/YFuwn9V34RkAZJsUQDm0k7Fe4H2 +mUgXm0kr3pTbvCFRYaiiG+axasvJeWMV7blN3+0d3zSPTndOzhdqRhAeeVo EHP9cplhpINeqUJpLG/f7Z92j/b3et3d6sH4e0CDifXLJQdTqlAazLuTvWNr IECP/yRurqhfTFhkBYW02TPGtt0+OI1kAEXGMQzhvvSy+qF8RGUNHJBTLdpo dILzrYAVia9N3/SM7ZkawSxPWZfVDdXM25+SWgPh3ngIlLyK2kgTxWWon0oK /ER5jcp7jqXhQvTmZm8wx8DcSKl60OpXp7gaZXh0miiBmd/IBjfiw5HTSAk8 /EYe/0r21MHNcVpyN0nfhi7ziJmfYNvcLZSdQ1TZBJS5wOsuBDxQVQLZoZAs HaHmR81gxZXXerwmUtxok6LgXIV4KDhSPxyBLQ6uiSEakZe37IDQVEMCT6nA lio72gozHQnnYUC7vOgsGaItTDrDsPkFH5lhnHfs5rpDHAsfFRxRPLmcXcBy t93DZU4VBQ01h8peY/QVmvVkHi2U/fiMeafTse9dH6bteAEeuK6+tELmqzIl eAyWKgFcsJQLTMEijgF78FCqCSwa/OKBLx50zYBvj+gAMLMC/hWuLZ2k1nUi Ar60BRezvOXFBXSd4pZqBUUlXiuORxxpO7awMxFvsJZj5sQtQBrxARYJ6Y/K egSL92g9wHorN8tuhNnd+aRCYmY0a12DRArMtGj9emFC2lEiZ/PJhnm7Cp5v xH7HDubpoHjGRUY2AgwqWFvoP6MVFD2xMsUUfEmeYFqJVvMYkDUg2aYtPdYY HAYfQMiOuiJUDbjtC8L6Ok+lJcmxB43GIRzUqn6QtMTICGzbGgYMxXmNUUqt pQdZm1YC01+8cKDYL87sYW+W9VRFvAunIwSz0GzMKFTKCgyODARfK8N0moLu dTVPLVJKyZhmuUCBtAYD4SG1lNogpG36TjvPVEk88OFc4hI0F7tCv7ukZepW e7Oqwigf0xkj1eOp9pbQT+Bj6yiqDa+7h8cc5inUcbXFtVE6BNaqHBfRGXof o3lzd64ldrRYwOfym2a05SvBGpn2BET1dCvoFLqs8Tw+S9l9eAsTFuoue+At ywBfp4iP6nNZnWqV4Lhel+PthFo1VxGrDVJCux8Cp5+2jw/aJf+D+ST+CMQe Io720mpYfJpkiY1N+dYUSGeikLCklA15nOATMvkJ2NvwsgQWyFExWYiNd3tu 4oPWRPf7vEgp8nr7dHu/jeZZc8x5MJ8kn6eUP4lxn4RHxbCGC4jiqzU+FwVe uXlRTtEki4v5bADFVBS/m6BR3It+OstLBAuRGWyKeKzOVMuOj1p8FM3xcnBW 6hFo4qFtn6faY2u8v/8d3sxyINX1B7EXKitKS3EH4OjPgfERkTarlpXNkNlR LW8M97NMN5y4vL4fR2TgTL9ATvIFrgMX5cwWsNp6KG0ppbkIkVXiu1vkHEKw UHwJMJi15AU5Sf4Lc4QPi386gHDt0XAJOsYWzbBEromZZQ3GNUumYGVw40sT O3hvx78LwZx710kV1JehSTdP4SZAz0vZVxnAXlTR1wI/rmT1lFPkDYC+/njQ w6xhX9DElHTUCoQl8SCrK0zxdzs7eycnFstc4cRW1o+6hgImNno0Wm89sLVq snlBg4KNgEUBB2xWCnzyGtCgX9a8mKn8eIwx4ys0qJUmBAbOQoYEpLAHmkOF AVXb4jB8JapQ1WIrgZZshCUCWDpEDT6iwYRGXXrFEilRo5ZO01iVAP2jQhfo RfSnF39MynYQ1VyDONUmecl0Q9lNsDo2CLm+ita11DCbwfYaDmX/R7LKKHsi uDfmDV2Xi3DWIFkCa30ljGGdvSUxBJV1zulapVBgGWzi7bExnyihlQADjBV8 Xwv1PHoUncYftNUMcsJifAq9k5cjGcMD05aJmD4eRKO0mJVaMgNiBBs6pLqs ZWChU6C4dk0+6PnnJyiiDODRg8NTg0upqTqP/l0NVR5GQLmAoprQY795f1nJ REAqET67lNNKmzExu8RCITchNY+qVP2KcrCqagF5WBVs0U5qsZjJtSuCMRSI XZ+zlxU5yEgPg9oZzF83yHD/Kab2RTydJpPCAxjnp3V5kD9GzfXhFacEHa6J JSFsfMVXgr8YhHmtNMfIYrZVlmUzPmuU1XTIt8atKofSMRo8X4sctOuo1nrp YFG1UKbje9gnZ3heDpt/LSLPoO8lroEKfL0IV1vgUIXXFuE0i7uqpiu+8+mK oz0kMf/vu72TUyEv7t3zN4da0/nDFxGs2zun3R/3yhwfNSIgsIeuH0XLgoi6 VnUS30DTPjmss8drcPPwXTD7mp1yjBZOp+a2h+gRb6aDxTfQq+3dnprGgitI NWvot3Dic0f3b85GmUjgDzAa07KoFLYqOu7xqUFRb6saa31b3MRsNS/FTjYe x+hqcW15SS3XStzRPyXOWWCFbfngokEHp43t82ZElCB8SP4BIerJ2RY2zd7S Yh1y6GX6ywnNv7Qh9pLI8m/2YvlcsTDFv1OYF0b82iD/xxGy/E7OQhDYaa0S ANPijwPqxgMz1uQB5bqRICzk6KflDW3jUcERgxymg5JpjAY9qv4iqqI7blG0 5Hq/8TYh43D1nTK75bq/LWb4Kn1DquVbuJDox7v8QhKh1zKLv5iy+/vf3fm1 TIcLK5foQtPzdy/0yFeMhCywx4u5Indy1cOzpGFfNKxbdWlyIVOdvVrxwm37 K1m78E2s9slhkOnzYeYTvPiOLqgU/qjOzGbL3LFkpzIYwpWEeItuGuskmz7N hVNQdES7HGmdJKQQ6ZvaGF3auaW4kuih8GMwIIElb561UsW/wPrhSNzEWcrf 2LsRKhRgakDuKi4YjXNdOx+WWG2nQvkELX3dqyd47Ts000okq9QJCIICViVV Ekd8lgp6pDB7/Q59E/JSobybF6T/Q1KFlE0s7H3q4XSH+iuh9+Yt04PlS5Cb cK/BWoJswe339W6+m6HCrH3+1iyeoZG+RAmvzRNeZdkoiSeI4ft3MozFMgyz /H+kE2yd1xKNzTv/uxJjmDFqMesXijGurGCg5+6M6CaueUa0CFxOibUDAaEH apSXP1W/hzMUUgMw2/pNDpYLsAHzLccFDonL3qnLLtme8B+SS6CFLSq4g875 vaKDHzDZlftKczDYTrUzP3mOm88n6D1OUcOs5lY6fV3LOL2KUIp89dKCk7NO /MD82QQjs3SSDvrxccAwCjyWRWeJaihP8mw+k3AgAlIrbWoc5sEue2RyH6HL Br0/OtxmY8LmL5+HQwCZX9aa7NFH4QjYEZ56gumNk3F/PG1BW51BPItxraxq 7eip9oLXh8404LtZfWc0Tx0vYgLFRvBpqSUCo6jjul3OaRCh0+V4ioujUhCU 4igEhWBtdBXjoMepSNDKSQ+ai4kyNquvoMkURt45fPu293q7u//ueC+ggCpp /kLY1lrWq7D0drUQd4+R7jDiGMMPgja60BnE5kgRLe4egYWjBf/i5JyUIn/1 LINIeLEwjDA+f/UbbxNXXi1VSxH7B5pF89+/hr8FgmPyVXCW4BHVxiliuEwu tGlxgUA2n1Vv8+Gr/9zbOSW8vPeX7slpKzxqG2epC4MOXzE/Q7eltA2LsBql turTtbkqw0KduVQdm3+d8SPO4T2SAf81euiEA6VLR5AWHXwoG7xYOJzOrUnj jOXyVcmzsnH0PcsXocpCCa2TRHbAp0J11RsleK+UjMYfYoxQfR+hx9gD9N0i I+zVl72j4955MgPoRKU+/gkl1B7xjLqHR5ubpzGgpsFRnqGfG8UauDflH+gV Cg2uvoRbS75rrXlZXBZ4r6zOVXu+5bmONCZm5v7loOqhfGoWU/J0HvL2m173 4HTv+GDvtAdvfDANpinHx4pDpe+mYO9d6kcm/SobXEYpLMKW930+Gcd5cRGP pKA94DbVKKM6AG7ZT/zeEXdHPB7lELEAEOqtAwsPVSt28+zCN71s+e3CzvfO 5sMhOo+GoLauvOkqVBPH55W2x2mNDmkGGJpfoa3Lt6tqAiwjea+DCugwG4Jt Xb9TAtfcHORdE5Q6oAfUviYku4xTzLs4yWhzFcy2EUj7F1Fxkc1H8DVBvMo2 d94QnUOvwkC40MaDA+K1SG7VMT/LzyjroYPIlKuoYCWbWqkyhMMLxEl1WHI4 JZKurnrZB9VJDeR4zN6IGPhf/sEf4flW1zrrj3ixH/FF0+k/fPiV+lhbX1t7 9uTJv6ytra0/f7qG/66t8294njx9/vz5v6w9f/Z4bePZ4+fPnkL5p+tPH/9L tPaV+q995kibRtG//BUzhZzVlQM66DYGdLsPoLXVB6sR6ss3o52HD7fwJ5wi +F9kAKGMy9VzFPc/xOdQVwAJ6y31bM9nF1m+Gf0n4PAi+gkIuSSXfiN0zp5e 5im6q7Z2VqKNtbWNNv73cUXxUzRtJsd7+HeKvIaY48uoIgbtjl3D/0icWp4k UZENZ5+AzdmKLrM52U8Dy4OMYXo2n1FEHGBkHmW5tCS2LSl61mKqI+wWkxYV agxvDt5Fb5JJksej6Gh+Nkr70X7aTyZwvcQwWnyD1L80d3ZJlV7jSE5kJNFr DJ9Mhg1bUZJSbGoky1GMsKG6kTbbkR5ZK57hFHLJxLqC8XmiUTwztTveEsIt do6WIvCnmfFApV66AA6QAwGlM5YLAEcD52I4H7XV6Oez6Kfu6Q+H706j7YOf I2Bgj7cPTn/eIuEB+klg8icOUQTIHmPmwwTzeDK7hHlII2/3jnd+gFrbr7r7 3dOfYULR6+7pwd7JSfQaqNbt6Gj7+LS7825/+zg6end8dHiy10EmhmxupI2a RR+SpUueUHKwdFRYi/AzbLhc3Rfxx0SFSRpQpPXp5eIdlXZiSscs8hKzrlsS KxioBLSUj8Q7xNlracHseDvqTvqddvT0P6LTBANAREcjuJyBhzuZYyOPH6+1 o1dZMcOib7ejaG1jfX19df3x2nO1K+9OttUkdyVHEzS8Ka92RnFRuM4SSg4U jcnid4BQqU4LzQqFI7AY6axgBRUNO59zwgd1gfPKNv6UTvqj+SCJvo9H5xlM /GL80nqZZiyZsd8V5VdzDmT80m6PaKjOhV1MwtLgS/O2uZ2fI6vSuWhaL02g Z/c9kzbuOybTduL+hVdYcGTgnZKG1n0Tg+pQETbe8b64YT3x49cnCR89wAcg UGKFFVFEb+CTYkEdZZuT5CbI6lrJkh9oF0sqtMnR1FvEoKp6PeVjiSZNkWyd +coWby3jwckrZQpgxPw+7hSVsXbOFDGmfEUvnfToeKI0b80UUQNt6RHrT5bP DiYEbN2z36h4wTdBrav1/x/ZAC2nth048YWl11IGWfKePEn1Cm85b3ll3Xd6 MW+Q/1DTOtdWjfbGahNbJ+5tWRzZ6mGSwcSWW3JFYLYe6LndxiSUVbSArvHl vsYUVFWahNm2m5hGOpnZsyh5w1x57CKHk7WvsNC88Q0xtrJLG3EHI9+X56cn VmGO6xzL25inNsdfGFVAYw6WMinJm/rsCZeWWZCGg7pXX/ZHSZw75oXSiScn tqqgAzgnq3IjbIUt8GxjwPrgE4Fu1K+wOdk32D1l4xaw4mRfPlsvudTpU5U6 kjHLWVkV6lvW0JUjwz9Y3qwYKzO9Zn1YwUJOjBB7Z6jN0saU2uK4HvZezfzU nzY2kUOnm9Gnzx0pU6g9Q5Yqe1PzxlHX7uDx6VJqDw4yqUq5ASZNMYkiqYqV I0jqpaiNI2lTUnYSHwouKZaquy3HPbhyju/Thw9xLdOB2XIbuBetTXpDQE+x 7xXQGy/Ja18u39nrzoHebsdMR81BE1rldBFeFRNhKWwCitpiQ5iSKf6WpVSn lVrC7iWwVvh4LeMxq72XnXpYPLjSFkhxTkuvk8VuFrZNib88mF33DZVzLgLd U1JfvcK/1lq8SidYR71cNvm0Ci7hISvRDtUbK7bxlXfxysakVzCAWGBv+m2M TR0FXynDirPvxiP3U5zO3k1m6Uihl0B4D1XNgpfT7tu9w3enIWN103YgtDOP NDTmOh9h3wrq5mKoVaEui0s0yCuoqKbPjsXfFXGbkBaT+dhgkevjMqcZUvd5 F3kJMXk1SsECQqije1DhnO829jJaD7ZlVnd7NGLQ9czgromO/nY11OGURsMx 1eo4vmQp51mSTMQ8cwA7JTYpmNczukhGA5JRYmOlMxS4EuoOj7NT79d+3ao5 Zj2g0n2Pet5T85eDG3QnoZg9gU0pGSu2o8AeBQZ2FW//b3mmg9bCyxr9LsAH TjHXErgWhrHEFTCHPr7WsEv7uzTWsIZSHbPC2sVaqPoiiKq/F8q2tv4CleNj /J4Aj9DdQvj54itlPsEkB4CxSNcyTkej9AuuFK7vUcU6sBQQtKfpOMnms5JT MU0SzQG/48l4mGchf6ge4hOZ6QyxnMRH26xjCNECo7jiODUs57waJK1w0Xvj +Sz5TEuFC+dLuU3j7l4USb+o+jaJJ1lhTZ26AaoviQckBOnNYJ1b97CJNqoT oLTN7sLr6CEaFfN2PYrW19bsxB9UgUqoIv/GRaIH9C+X1sV1KryF95iERHcl /x0c7ACpzRYPmMcb2poyMAu1Wb4EPXO0BRtXgrqlQX4p0PxSsFQgWSKaf8cX ZtUddjM35pXvwyCN5B7kMD6ymRgfRdShgjoOqzuJyzyWxV99t5i/Wkhb2YUM HVECotr7OnhU/EUJAOnvjZfzYdMVIDsUn6OYtamcqwvbFoo6qSVvaBps1mxR qCVcrUAoFmu+Ft27F5nMwmUBsjVFzBzuSU21zJS/+SDKb7EfZ3UqWIcH6Vbg Q5hTuV3k5usSYEALcdlVdV2yY7Tgo+xTkvfO0EIlsIXtyIePevdCPaIVJQat 4gGtduGvJJ+hM4Oufgvyaj743jFbtMKSoVWgyE7SGlr69aBaTWvhfb0abstR nOZRjrGIeHuS/5pj4hF68eXbE9omjW6pk84wzQvC9PwTSKHMzQNewxQ+sJow 58ceIoYgtTtalo9yDq+VWlmW1CflzvIsHvTjYmZSpN04MneVITIZifZ4JRxe vb71nK4Lm97tGeC/y9fq7+NWdNCf7RsUWEXjuqCTO4QUL9dlJK+jZ1FKuU8p yfa9JtR6A3AmC9Qpmxbk0yIcYcI1dnC15m1GK7wG/ZZckqU2TsR1sdzCDear 8zZTj2GpDVW+FcevOIxzflbnowDbAiVb5v7546nhHLKmrBrDB0OW52xbLB6I dKFEhFOdkmV3NHQKs+8gcga0lj2kX/nOzSgFpZdOJqUSwlfBwEpVlC/1NMl6 Vs0znfBUQzm3TOIUymW4f7izfdo9POi9Pjz+aft4t+V76ZgYsjihZbPLmCcY Hi1MNl5zZXbTATmD4x6pFSivVtNelEV3yJp1E3xXhq6lFL9vtw/ebe+HczLY XqKUG727d1DlHnrNVdk2Ws0w6DRZ2dkMHiYVH2TFYWeFLfenc80Rig9uNWA3 rfiTmELXZPC5ykJay3kF7OUsyWJh2ZctwSSrWwWUIiaipi4d6SuB0mK1VDUr 8mVnNHAe2Z2AABStln0ncQ2XYeR8zrUTeI0OyGbccKccA10GhABGtV6W1qcn gN99iFnMNuJj3xxoe2cabmMnngCqjqD8Qmytse9tUS0W9bUU3bIEDnZtUZYm OzxlSfzZ1Z9bJMjb+LMagJt+s2xJMkjO5pYtCf0kA5HqZQDgdzp/4R6F77/3 xsbBNKrs9cu1q0qqhnxDgUALYVsCfGpOO83dR5TuVL5jcZbTX6tyvA/LA1mJ Xr5wl6cqUCvQerCNaCZxhtlphsYjJ4pHqGq5VPRklkdnCXn8yD3nRiK6Ro7a A90pd/HIMigyw4DPtllRCStJCCRMTJkMimiUjtNZ1GoGAeT+yhJZZTiSinY/ dnPU3hQF4gL+VWgQ9erhwyoICeq1v9gYrebGq7c8u5YGanV18ezq9+Y3K6BF SIey2CbsBoZt6SMCWpAA2Virg1go5Fpqhb4p3fCHvdTLaWmNusVZuVAKnoVq w3qawJHwIRymfSd+H4atIPVF1Ozu7m9m4/NOlp8/oiE/ktVa76w1/ZgvZPqd 5c7h+ILgL5IyRQWAkdaDQWAqmngwvtQtmPhm6AGuompQ6rRomGdjMlMz4SYx DkeejQTm2hySHxdS6GdYR9UeMLx2oI7oDKO0zLLovlny+1TWGo0kigyPu2XP 3HaO8MJ20IcFMaOtPldfLhM7ujwkHYYHBbn2kq5QflWHMJFPFCTnuyWD5JTD NVt3Iu4XZUOwFj644mYCFRFzvAJVIXNK4XIqouME4uXY5iQ6CI5VTgWpK70C mizQXOh0mziBNbFybEsMmivwedkgURPFqm21di4up9MBZzKf92dBbpHADa+S dMLyAi5QfREIoDvfzFF83f3L273N6AdgYGEbi3Q251Y/XSQTVUcS4AFyhoVi iX8RrTHmOfsrY5iCMQyHO2Q6RNCn4LKlbxmaNCO0VnkA0to1xHORc/yXb4Du oDbmfnZz0cF0b4HbHGXx4IQ91aqvC2bx3qNPkDnYTVfg3GyHvojlm/0xYBhn fz5CL/Xy63eAte3fb4BIntovjrNstktpvbP80v5gM6Xy/jfl5WVP1XNnxJ/Z UDllRo/UCyekvZ102GQtLDjepijjyrmHr+GCWJE+w7r+P8YjPx5+YGiARH7E gi2JhCU7izHEqIGgnB2fkr9qy6/qOV7az2/Om6tlmcGH4mdNs3wWJeRngpFC PiTJVKmdeAB1yyMcKFQvj07iQYkPSzqJ1HIF0tfcYL4QGMYy9uqO2Yr26XaF rNX73RQ332ZbVy5tue1CWaDoR3u86vut5OtbISXFwfiuoMFoj0t48poVuQXV oeXAqxS9VzvjAQdqO0QCzbnsjcpvdLoeXTQc6pCjfHiBDvGpoBg9NJOiretG aSec9N8O8HjpPAwCWHjVVdTEsJK/hkGnZhgGhmv7tQ6KDYSw2K9qIhSGn1D9 Exas2etextJXTXCrV0Kn7dXxTwBREIIq5e0N5ey9jRNTE//t4qvFGKuP/7a+ trHxROK/PXny/Bl8X3+CIeHu4r/dwhOO//andDiBeznq9U72jn/cO+790Os1 /gRvMBKJ89KJFHdRd/7uIsXdRYq7ixR3FyluqUhx43jqR3VjJyE32huTBgvC xDVlPG4sNdcgzIuzpnUANxtibRdI8eiE5DhzWNJ2dHo5BZx1jxc6sSKv9Wnl JaDUlvw0dIV6YwU7U69clZD79kioWeel0MrDPEWnHv7iLhZUIFzU37S01pXR 4MLh35hM+pjmszkcDR3QTAgxpOOj5ULieDUWBxDbcsovitWlbAIpBpc9OajL FJ8qJwVnUWXsLHuoV4hKteXUukKMp62wcizg9C8W0tKVXyEYJ0CqtC2PJmXe vrCZL3JNtp9lh9PQhf2QM9biLm83XK60pH1queLSJiI28Czl4OFYeF/FbyHs zXNl/yKr/+uYtrviPTmA7rEmD10SHslRwkWa5gRijJpmgE+RjqW+PpJc8Xt/ Yi91RIQfqcCWU9P9trkJ92gew1/keVFflKbR0xW049NWeWjTOM2/x29tavel 9uuoKqsba5t2X5o/uaq7FnilpwVmkmAKpa9UCMiPRiwlGieYoXrKIy4jdzHQ u+eACECpVHhRLrYAEXiu4rZ35NI45FremtdGImX1ydfQBLvPMnphGx1Y8n/7 rrDj17mgMJ5TRpHIsnWwLB30yTP9k9SG21YX5QMviKhzNB84sURtAkDLTfiT RbDANyvYKCuMnRNlWUSJtpXF75XGGAL1h5PRJTIfA6LnAVZXc8a4lMbdgCh7 u0e+m7sBRHIUSkn15bsPudjKWYueCLhNCNKtGyQpu4woA8F7yzSM7Ttq0zI6 WTSH7+S9vwlx7Z+AwgQ+B/bIkSl8a5nIP9NTKf97G0+/VgqIevnf2rPnz0j+ t/EMGNENkv89ffr8yZ387zaexfkfBBAq7qo7qd6dVO9OqvcPINUjAgmAzxX1 4BCh5VyxXsanThlgpwD0n6kqtkU632WyPgyFQIlHjqjOoJwbEbwpudkYaTEk KTf5/PWZLDpLJ3F+2VNj+16PZnPzx3iEwrkrmxQFmiDu4iUQWbYQjTgOxUi1 VhxOyq4NrPIsGa+Hx1FfaUORd1jUqB+FzGtRu+LL/31EFRyH+99uhnC1fOBp yBSde8nEEjpvJSetdY2frF3ujyUXn1oPYHPzy5YkkuPKYqKq4ymQ4XYgoAKa T1ixFOgnh1HgVtGwYrriSl/IuZ5blAV+8UJ6UNES7KAKiZNbkLuQgBd2I9Jh hbP9jcaf0XFnaMtYvFS1a9fclrWb2RE1ft6UNWfZrf35zt+fUu5ruziZkhAX 6G6axK6wSt7uZlnmMPZGhY+NCe9jVtAxX1ZBe+z1rg8ARqEj1OJQslzu0Q/B hC5o1oK5+XgF99wSLJNrexUkh0zyrwrPjozuC4D6ChfR7YL/LcG2f29YG2el M3a3zAtj5cA5fhexH8YO0JF6DPw7kasqD8G9exh5bR46Dqpl70x8zINYgUrf yNrZ/F8t//+VTIAW8P/P1588M/w/MP7A/z+5y/94O89y9j9vt4+CJkDqvS8v qDYEupMX3MkL7uQFd/KCGnlB2aiHNbdhM5+vfTk6tjDE8Bq8BptcwNYO0GRl Os9h4nDoYcZj+HR0uE2zKfCFTN5yu5/QeRVbqcpyHbe7CTm/Q7k5nn1ANDme Ll6NCGjOC0IfgHBiGkKR8WkTqPao/ZVIyTUIR53xiUpQ5ctHFl4mw2HaT1EJ PI4nEwyzwuOG84tQmRVFinpDGNEoyz5E0Fc8+CsAF1RIuKnCtDG67DiLCTPy hB5lvbZFc7c1HfdSEdSe4ZFjFACtt4DY+s2y9agTJfiyA588ruVoHTOOEEvl WA1ROS8dmujiTMIt1x5FNbcEN2JTrgESWBgu10bJWrboQTzTfkyDz+7I3bbc ggHzKFVQibHe/7pky+EKetALTToEPF7WmmeEK/wDGWngCfAkgJ6pBr0JW2uo wu5wQmvGzOgNqbGtI2Mzd3J6hI1j5kufqJvJhWkdUHsk9ln19OQ0KhUz5gYH FRJbuGczMLD38P7XjuLTb3B07smuHmPlEt7aSENjDGOi3+d61mHNbzLisjmH 4g+/NZd791Q9AfmPbxn/xX0s8P96+uT5c/b/evL86dPnz6D8s6fP7uw/buVZ JP853gN2uXt6ePxz9+3RvicECnxkFtEHoZBA504SdCcJupME/aElQSfAjI6S GUoUiM/XAgUKwaQMoQ0yQPeYJB/CGBb4e1WLgDynsC422E+m8K1wXcOqXMYO 4jE03bm4cOxO9j5jIwjXjiOY5Tn2+/ECK7t9KWGVJ23RL7SZt3b18qR22gzm 6HC7F9i4kE+YlpDZIplkMh979iXY5MH22z0gCY+iF9H9Xz4Ph/eN+lIHrOud vHv9uvsXq1hy3w314g+dfen12PUeWgOwx4aPENVeGyERC4aJhLZ1oy168bff AiMSl6yjOC8Sb0xeR4tHVmqramyO/nezNKPq0e7SnZUWhCK+dLjlxr76eA+P X3XhKH/pSO1mavZ7+XFha2RmX9u78nAkIaBl37ViEln95p0hMSzwjqh2kXKd JFMYRYtSFuTn/ba40sHfH9//6oop0esC3WT0oFvW39GD4cSTTXo5FFSSBEeK d5Tl5Eii/AjwqEthDOUEP5ev0D04uVr58bGUtxeNJjsvgK6sdgbj+GP+7QGQ QJ0c88UtTnm9U4yeOsx6pxH/s1VqynZP4n/8jt2dVFP8n/JrEQEqSaB1cRbz KcVOUiL8wi5Kk54ixlDOoYsBAuiKflIUfJe0Al9OgbQqsM/ihMPkyKGxnHnu 9envQGVxy7tOVYyoRJ6sV675Ni36V6mWUzgqtQIld9CzpJ+NE0ZwzgLFgwF6 yyBMAum2RzY+O1nBhMXmJv8Lzc6SzzOC1hzOQq8/+2w3glznjKNHOY3jeWZo L1plPcMukDPqq+O2Zvvdsu5jNMo+bQ9gKOTPyjB/nmZTGNiEFyl6AFOelCcu EYL1+TIfoCULaXgDnE9czMTcDbrE2V6+6LctbuElT7p7eTIMnWce0G4axNvT eHahom9adcTldQgnchRU5JTryYBewfIlxLrZiKAlWOCe7XRujmotsVtxauVm CHkUzrqTAcXBO1YhHcOLeAUjMP2U+7OW3bmuQuMovmwgep24e/JXh+4Lv38d x5mvLccL9epdL/aV/7JWtKN+aA7A2S+eRUVddecfY8z2607/+k72IV/We5af eGjIfOy5wk42HsdaJ3lNkFk+0EHNSJxYC9cbyFW3Xx0hE7UiFMmCGhCcEpiD cjKtB51AReOfWnd2fJxnu15XNhiM3nC91bx25IeKcZeugSw/A0LGG6vOAuDR aW6SjB7U7WHRUfIxGambwvKJxu8zbNwugZRXb9af9pC2sF4Vxch65bQzn6Sf e3gdVX5L8nFaoNRNHJ+9gc40qRb8HCMV4BQq98PUUdUolM921XdcpYpPaZZX fUJw6RUf+z0yaBbraJfrwDXmD1WcQI+Iq2kWLygGMLZMqXFuShEd1WMRr5Mk C3XlD3rMLhTWxJwAE2i2gl7iA5iiKmX52z/ojeOp5V/ufOKm+WtE9AV+gA1N VMKd0SVHXx4ko4SkbTIaCVIQdrgvjdThAF/iIqUz9n7K8m/uqO6CQsNP4KcY Uk/TSQBzg+rYCtAJDU+zwN4QDcT+PsapOG9vmPrE/E5GKfyIP0p1Ym9Sof0g qOuKHjz64yu2K+3/1S3/FYIALND/Pn+ysW7s/9c2UP/7bO0u/uetPIv9/21A KBNit6XFvdPf3ulv7/S3X1l/u31WIAMzi84wtXQ/GN2TVLw6YGfhGqyTvXpX aX0L++ApJrda51twQH9HDyvRpVwtLItJKzWzfvSA0DuNxGq+Sbq0UBEWH9ys GjhACbvjM2ID4b/1EpOnI5FFm5EJUtW6x4nLFE8tbAXmLTLvYM+BGMXMKbjn rbXQFzgLHwf2p3iEERQpYqSQY1UcFZBmC1JvaypZxA49CXVGma2g+upLHWiL v6iUdTfnEWwW/H+8FTe+7LV5Ee18iAub3DQJ/Cg9RYsEFw9WCH9ocQg2FUl2 uGTQ5H5qUhEaGccNO9+amenQmsQ4DzICHrViJsAaASXm1rOy6nH0C1RkMGyR F62bQLzHmb8wuttnHQ0THZehGpRW3dn5/OwobKXEDXwYyokbqpOmwrWXFiZn A1Y0eW6c3A3lHAJOIgdMMYTnikD84UPvDAZyqWcfQhlVnBVBj+LJ4IgSJSDg oKO46SeQz8XkdZLyAIaoaEGDkzwZUoKJNiwr5iNAPyS8sqzsff/HafA3d8zu whVJv9iq+T6JJ5lXgKCFrXeI+evNYJVb97ClNnq/QIUVb53wGybDaMk+PYqA 61jzJk41qZQq9m9cLHpA/3INp8qnCyQuBcpa1ta9LKHIYOIdguqWwcodnMoA s1G2eDo8Gz8zrHlqz0F1thmdfIJrazuWcu6J7IPxdncbch3Ssw83g0x8LQMK AHzc4uejdKzc63GLFrtY63bTEyGReWkSpRSkziwq0VUdqgrIewN4qpTLS2lu qw5q5QGtTLTqpzf18ToSC1sLdst8Xnj0F574K5x054Sb+6f22FlHaHE+4BoI qMo/1fwJSiLBjSyLiW9qpwZeFrFg3mk3wAReKd/xRG9+Ijow7wBZvvkk+TwF Ii4ZjC7tyZThqHtwcrp9sLPX2+3u7crwowSQFA/fvRJvZuh4WAYRJrGrHelp 9+0ecL1qiVVBG/lwpW+MdbqT+JbxTiBN4B3mqcI89ff8lwK72fylUM4guRGk 8xVO7RITud65va3zavm2mulp4j1kcoEfk7xGNe5wF5+B3Lfy3XlgxW058MSv MGdx/yON4bNmGG48S59ZAd171WTqqTyfFoeNhrryzYDrWZ7Fgz4UvSkf3eDc 4DTNLg6yWTq8RNNMNSOzBQswk9rL8p1N02OSpUTD0zcbizjIUgQ1BBQeF1G1 Xuq7wxzoW8JLMiFSGirj8sNLyoNWX1ox1kX0Y4RDCkAVmxMQQCkjM1h4vuoN 63OLcG0mIQBw7d1f+oK42/jfw8Z72x7gciNnBwUsJGRoPBpdcmKDxItFtwzc VEGBywOHNtNOLSM7WQcZ3+AYtRZfCFWXX/WRCWb9tKVr5WNsHYvlZC23lPjW XjMSF+sF+x2eRosD8dQw9oBwDDQVHzRvODjiP8ETsP94d9D9i681+6I+FsR/ fPp0/Snbfzx9vL725DGUfw7l7uw/buNZ5P9PwECxPLRAxo0BUFGAFcwhUIq8 586C5M6C5M6C5A9qQQLNzWBNxqvFNOmnQ8zUp6xBaAA4axcBsJlJyRbksniE TpVFOL9rrT3H1yYBruWaj+rULIdNGABowBRzzkcWdNBHrOhRO9oxv4wxjc+z +z7kkx9u2XYuLjl47bbcRIyDYLDAaTroUWbTI/a1hGqhCIBzVewd3JYVZc5V mTd5Np/ahcoDvCoPtVVuoopw9wvZApoo+ZzOgOUZJCUfkesF6CvvqjikBLZb hewLffJj91VUVyNVLwu6iTLMgwdYl90p0TfGGJSoqyMAQKqxQgX76FRNybJH on/bAjbw37aAxhz/FAjQ3IPOAhxos7QB3GRvqoR73G5vrn5z471z/H0DDgxX 8WCgoTbKkyLtQukgeYbtNMGvz9+Y0c3rRueeX29o85se2nnd0Dy04Y3t/MbG Zke3qyB6vzUxf41nof2/toq8fh+L+L+1NSv/35OnyP/Brzv+7zae5eL/Kyh/ u32w/UaydPq5AEJlQn4EGqDuuMA7LvCOC/xH4ALDfgTFFO5niheP60VUJ/kU TAaK7sSfU8VBYkOai/SIWpY3+1yjG7XtD8cGunPcagRfKyLcDZxvIlBdPwba MtGwqqOfVfKUH+BU29GtdBgBd0cfSJQZRefbngzlysKkuToAv0UdmGJx5xTZ JBDFQHO/VnIsCSfgBI32dsf0LfwKcKRo4xZIU+DVbFW0Nz7PfeYoXJ9THnhB 260k5KWWdRL1b80eNYID9J1cllgnFRVeu1G8iOD1zXIoFcOpmpMBj7KTtdqM m+ZZqqm0b02D3j3f7gnwf+M4nXyt1O/0LOD/nqw9Nvnf1p4h//fk2dqd/u9W njr/bwUIdezXXRTvO+7tjnv7Q3Nv6hiozadwTNE0SyczX02XZgGfbRNtyHWd roipHfLmNrZI3FjVV84mcBNe2DDZBuI7EzqV+SUnfqoyq4YibgLdpS2rKFwv R2bFNn3zKb9mObL0vSR38icT19aHl+QhjFuZjgGrkicxvO18guMKTAL84hzD k8Foq3KgOnCuKsCzXPdGaTZ8c/MGRsWdblQuDXd/g10/9rq27Pm+Zmch94fX 26fb+22rbmkznoT9FW7GWeFbUyd3z00/FfZ/vrD+i9iBevr/6drTjcec/2dj fePxY9L/PFm/y/9zK08d/V8BCA4Zf6e3uaP87yj/Pyjlf3XrPSXp1EZ80Q7J 8QsglNORDsUPCzxI+2RlRAmh4VwGokeVrADnEwA9L1/PsD+ZjdxXo3ScznxL QTQgTMdJ+S16jnpv0/NJPApZGnpdK2bnJmNWhZBsqcDiIFb1Uaus1jhx9g0r zE5YBTFOxme03+ksjQHXAeoxWoDAxDc37Yi0wQISo3ayFaofPaiqozUDwLH9 dTztnc2HFe0XcPoH6O6E6RtuVEFyFa0iKRZlXSjzOh4rTAiC2tQiiXPgU/Qs Obov1mI94VF39zCHCwoA3NMjqjCspoCVQ1s+sie9yVwTsDnU6i/L4k+ZZ2FL f7N5GORXWqoCBxewTOG+p7qu53h4HJZtYd2Q6scB1aHLqtEYL+gbBYSAiiwI m4GXLRX2Law1IzcpHbYNJttaXTe/0adPBYkT0QaA2ZtkRqlRJItFF+5dADa4 76cIlQO54RD+PGxODVhRm9F1PcvPFsR/oyDOyssQo/mmAOIvsOLqS3Ezm2U9 Rs91TUkUKx1FLj9jVJEnw16cn0OTTayDLbxoVhV6+EKPQds/A3U3haWbJu83 ft3S7wbZp4l5qx0O8U1Lyq9EL15EsN62m+FFnn2yNO9NLCemEXDdDoEoSQYo P3gYCaImk8eTy2KWjLnKinc4VKd6QLfSLcIS+qVm+QeTggmoHhSX9Oj0c+99 NAhZXTfGB/1RVugVer/2qyXfcD+tlz+ZNQ/UMx+dmqWpu3RKaA0cN1D7qVsb M9u1zVJFNsVO4f51ejduurya0CweUdt/F2Mz0Kx6QyxhT9Lx8u1/tEqZ1bUW CTt+G6eT/SybQhcyrIMEjzBjQzMeNH9v6SglA07mVJqWmVUGrFoKJFWEAWKA eFwpz9CbiNnl6mnY210FJYsBoWEN9wQJ0YhDvGDwFYBWzF6H0e4jrGHJ9aBg D7m6WdwHDq1lboKbuAiC2P5/wuj+bzfnPxwcBtvzXDtiBUL2dz4+wkda7tEF ftJ9c7p3/NYLR4CUOx4ILgO8jh3Oz4lFgF2h2QvGNoLeTk63T/d6B3s/2Z1y WE2SlKpXf83SSesevHKRG8ORA7JSQL7YgHojXsilUKTRg/DueFZUXkRYnrzw J6hwUHkoQiGfGId/5HhPKpEc1lFBjz7WhIJiLlByZQE+4X9fRH+zokGhTwGG pTRvyJS/tbIo6QsOAou/mg+HSX6S/jdu829bpmNA4BIVKpvnvUKS8BGY6t+d QTbxgqRYHxkBr65fIcaCwVu8CT2Y8zzpTOfFRe8s7n9o3TPt28URrBDoaIna UQHTyYYtZwFtqT8Vd1cAF1Hqd+ALMjM9bMbDdhjPiUQeKAhSW8KkHJFuA11Y 4lB9561WKaYIEowdCvZUdRBrAuPqg+ovu48d7Oi57ybkaqWECNEk+cTaFQWN mImPNSxNTYmGAkNBAavfJM9NtF58QrqYvePjw2M7kq4qzDSFdkbb+5z0XwP5 AExcq9xHp4/Eq6GfOIZdcLZ1c2JWpenNA96FZtpc4eXSgYKrptg9eH3oz1B2 so6ngqOCGxFw14IptL0BXitJnTwl5PFV2hK0I/O1I55oplHAVVamgzvYVNHE HPhcAik7gcqayvsusL7M7nhRoI2FIFZfKuKzrRm8YQPDarphaWtduaVC8IbZ r1K2xh1cTuJx2u9h4JnvQ2Vf2ptH+63kA0huSkM+g19OhbUonPeusVynfXJa 5jFhvBJ9ih2ArTrRJIX4Prq/cj+gKl7m3LIQgCkqRVD9ubu/f1PESWgDwmBg W1qXZEN/k9UnYSHbXVuiKHgzRn6CpH1VIOKK9vharw2LtIPddGdI/qRwLcaT 84Q9oOGCjEc9fqElhkXnLAHWBm9c6x1eyVfBRbQlZjaaX8TbkDrsDNMcJg+k K/8sErxq7UvRmmdQArcCpK1paatUb/VlDxAdCjpaLp6/HTxxdWAJmuW71tN2 cQaulSieZaMWlL8pyK9GePY9UiuQvCrY18MzgnKUMgiPsk9J3jtDBdJXAOEq qagPyvVgZvUJfyX5rJW2IwtV3/IuXcSAWBOH2nZp70iR5mqftAUYKQ2Y8sF3 70MkuAgqRHvYkk/15HqZPyNyn2MJLGwCy1MWwCR6/2skHy3hJZKhGMnAOMXY jj4JCrCMVFN4Wi3ptO9QzRxpkaPigMskvNUp/DnJtuwvJN9t8h/aKwzbAjqp gkgOSBvNSAIsRP0Y6sbhCOj0gNTD/L9aJUf4VP7syCGt2NUy4jV/wBVSwmg1 SoDDmJNwYxKU15m+Q0ILr4QnvLjC9NwFlDEhrBrgpPgO6sc5/qhbjar5sxQR OEWRK5bliRWr7XwngM4z4B/HRkivP+LVm8QDa7ZtVVoz5fJ7ZSV6Wd4ufMzJ 8L9Y0KfGsO6PQY1DFVj7FeHiZO/0TXc31Ju0y3DLAmvkjAEZwcUfnSNXU4JY a7WDXb27TldoC3W1nvb+srdzhX4EuOr6WNDWfPJhkn2aqMUPt9Rwfy17FhyJ B0eNeQvACRdMpHkG5BoxoBGMxSmxublzvEfSycPT7uufTWEGJYr6YWHZAG7j KT58UamOUKDn0nnExqKZRzzqjJLJ+eyCEWOWy091YbN8CorrY+BMwCFegwMk j//JQAY65mqe+Iu+0Zlzh3CzcvZqskBhM3UX3yO0Vk/hm4g29eV0uJsF5awL WNEeTAgMBq3m6uHxK9RiHSdDJYfQH0t6TEvm5DfTHR+ryXd3m4YBZloUSZ0Z m0e8/3eldSmmQCrMhi350I6a/zaaN9tRy4nVv6LVV6VepaIRqsA9e5bOMFcA WfeoU9aOXvfe7J2+3pUJUpm/v4he7/Z29g8RhfD7UqUTrNSm8isW6WOQP0mi UYFAvssKeotkBrvSwkBEZSi28Zfg5K3Sx/VfXerCwn/QOIBGa75U4++Watw6 dw5yXSuZpEt+Z5uHekm04XSWF9YthNLhFp5yANAUKUSk7ecTFLjQ7hUsa9+C j9/Ll63o4cPUR+WqaUv6jfXfpy7abNSUdxIv4XEU8hmLEaJo8TyEYQKG957z OZl8TPNsslJeR1pkAz1LLDHZ6BkA88kCDOEOA9lwlEIuRdUjFer6t+VvJKCZ e0ORa7/HguLC4pE/6h7t9V69e60IFbQBng6gJaA7P6PtZzJGi1BSdLAwxdW+ PMAS1whTTQ2/8BQpQ9hNR9Hg6Vmyac8poo4HtLX6UpQ9JvcHv+ZLVq5bCxPo Czhwlx2jsjh8l3GjStCfJ3Rcyhet48PBjOE9pyoBcGU9ZXJB2pcbjr69BGzt WrHyFoPW1xLqXQWcble6J7ATFPAp+FpSyEfFzdzDEj2CBWu0eQzYxypZpyPX jX/n3RpGfmOHQrRB0g6JqGotkJvjs1BZUgaqUmKXJsk3EHiupzTBZynFSXk1 rIyHN2wDUvA1HD55RDTzWeIpIh1WA6FypUMpkhKpMymvJ5hm0jpbov7l19/r WjZRITWBkoN6fD06oga4nuV+XsH6K9FD7qX+GElP0aoiQla4ln98sNvvyxy4 mgd8do/HGcDihyDhwVUeWnVcMfiEM3De/g6ri2Gp7V28w2ThVN5her3EDpNk xJEUhTYYS9UOM7S/WGnZ/ZVZLNxfQ3XT8MOytSOyeURabRDFM+JDSQI6GQQ7 XVsapKhCDUjh9xvMlFGlSTlN8nE6IfLMcv3g21DcuKN7/O+V1erIXYlli5Vq 6qfu672/dE/3dlvyzeVLqEe8B2YyMnQBQkcZvFoiEpYRFv8JG0ETrncnqqES dwVdnXTfHGzvhzuj8QFvOkey8ic0LYPSbmPVYxrM2eCEvETE2oTbIv1tq2Rc Aq9RBEPlnaWmWmzIsdLUsPGndIixFX/aOTze23339sisn3qzYP04hNp8PIXB 9rM80U2bcD+m8ZuAO5uvrIS/8nqYXdG6FashssxjLCaGxGr9pCwa18I2/vDu yJgTs0908wcgf1bnU0vGJ+fVqdk9OC3V7GJ2+nw+dW1lQrX/77tuufr/naez Rb3u75d7HY2ScwAuJDTQ/wOz7NW3sv3quNz79lmWLx7466O9Us3Xo0z0LhnH uxYP9wVN/Tk0mT+nMJtFgzjZe/NjqeZJcm58zcjIeEEryKCWWnmVZx+SCYnO Fi3i/vHb8iKO4ny8oCJikFLFU40yFtR+d3K8XqqNBk2rHEJ1oHDN+uKGNpZq aGNBQzs/7O+WGtohrVMxy6ZTjg4+W3aCO4eBk7UDvHk6mS/ak5PTw/J5PoFB LNqSk9NwvQjF7nTFz2aXixo57R6UGoFqcDCnczaeROEUqlYmWiG3sM3Dd8E2 s/nsSo3KPQFNvnp34nQBv8unYF6wlKLckrkWpC2r6aPD/X33iB0GjvhRNhqR ISb68AYOqdMDNWl3cXz42u0CXpS7yLNhOkKUhG6cOaCkaZqHIM/tC9u2+jr5 2V0p+F1eKSDX4vx8Pl48FWzOav30ePvI3Wt4UWp/NzmbwyzyuJ88okYJxy7o iZq2unp3/MY9+sdvyic/P0duRqdmi+B/Rdb/kCzqDBu3+vrxFBGj0x2/KvX4 owSjjMM40+lEWrX6+cvO0TunF3xRxhtH7wgEInLzpaspGSwEBGrb7uv1yf/r 9gUvytcgskXEolytM2zchrrTP7/eP/XQGr4KIEU574AEgGTqf6i69lww5Pbt M/XTsXukfjoOHNpPcI6GbJm86BxBe1bz+4cn7nTwRXj1WAYHDMWCHqhJq4uf ugc7Pzh90JtSJz+lk0H2iTeJ1c+LdodbpiLKdal0ckQ7zNelIc2lyA2G1BGu rYpuzucT2+1I5FlCLQsXj0JtmzOo0EDj48sDtPh5sXoXH2RKlMygxFL35X4P 8uHSYQ0n/ikuLG6cLF7uF8iNt5VnVhJPCoqSwOYwF1ABOcXE5deXkEHSVDTH 6r4nb4Z7ZS8NfHzZpe/xGo3F7VxZ6ng2BtVMuLTcjkosKT41gaHKskq7wnA0 Ly78pK4xMgluukq9TcZKod5Mwd/EgJbJHdVyfexCFz/UdrHrSqMDsu1b1oF4 fpTGbXoHYRkuxhFHoxnIbqNrIXNXRPi5fpDIxztSNtUYe/XP+ICsZpNVVIhG w1HM2dlnF/CaWWUVnHoGwPiZ3CZZPVlcFnBAh63eyU7v8GjvoPd2+y/aVhPG 4mi/qOb33mFV7fWODk+6f9GNOLiS9MdUai3airARqYZa4qFrwDzkki+8Nfj7 3yN57RimedBQthkomwuop8psQD12fddywINeD9+RmtexmXP0K6QqxE2TS4fh YIoIoCgoCDyWmo/jwlJ2U6VsCuwrwtkA48YT6/GImYVHrHecZUifnGVUBUu3 mo8GycdH/53kWbMdHfaOdw8P9n+WkVkFJvPRiAr8dLxsATWskwQd3xVDiaNm gEvPYY49EuT08O2Wep2Mp7NL+AbYVD6t6G/xYOB88T0+q4ogn1o5JsIQyDAg FEphORQoU6FGSbRCY4U/dV/4o1PEPcYxaC92L6x2oY5+4FK6NuzrSA9VWnKn q97igUWIPdnuHe+dnG4fn0Z/xx8Hhzv7u8j4mtnTQFsyi3ak2maf17rbn9Ic w3D+Op623OAlpZzgQSfNoF2kUAkLnBSD97ts1RGbcGo/e77p8TZ3HK31mXXF 69axUg8sCDZGxweWqfdq/3Dnz7JQDC9rHh4ImXor2+6t2rbfHSxuPUD+mAHX kGTVhoH2bWgTYQHKxbbLVl7Sq+s4XirYjn46OPxh++CNTdEI/GClgDWrZ4Lo fyppgaFgiJxawnjQLr7UDALre5UNu3USwcEadBsLlYCXWPmYtqMbMxNaFGLJ +aGJmZogK3lynhYz1L6bajeWirt2kZ1ZWFGBQtkglK9qKZjCzYz6W4d0vNIT iP/5Nv6QIO3y1fpYEP9/Y339OcX/f/r4ydrzpxj/8+naxvO7+J+38QDDwrE7 03GOUbA5TFyn82j84VE/G2PozPGHRuNPX/eRBqPobdzPM4x59mOcpyhhLqJI Suw8fHhyvHOy+eKXxr+qEHsYfRR+SnA9+XVIFkA7KDFRr7yI4fJWIuU5v3RM veBbO+qp/vg2nqoXVRFS5VO4C5VWodE4fPWfML//3eoj24jmY/NZ0svO/grX 3/9uyfyBzII6sCG8G49G6ZnsS9xodA929t/t7j3ENVrtPpoX+aNRBq09wh09 PH61+qSz1ll7JNuq3j6BF4DEkYamerrxm9vn0zg/T2ZmcztHPxwe/LxJ/HJ/ lMQTijpKfzUaOo72/27hCq00/hVW4y9/WYlWs+h//z/qLfy733212z1Wf0LB BrWw2fjXfBytDnVJVJI/aDR0F5vcpyom/QHjNi1WYWNuFOJ3E+C+Bsmkn1qw ng4nyX9Frf/derv9572dt7tvDrf3T9DREoe5UvlZT2jFHF1nEiwW/ZO1uOqN LPXXnuW3Rmd3zxWfpfO/fkEE8EX3/7PHVv7Xx+v/srYBNe7if9/KUxf/u/ou NM9d/O+7+N938b//oPG/v1Xe1oqE0N88JHVFVseKpI5eWOk/piAhcP+r0OVf rY/6+38dmP7HJv/fk+eY/+/5s/W7+/82nkX53/cP35QTvlsvGZEokKm78O8y Bd7RC3f0wh+aXjiBi3+UQHWhFXB9RnD0kR4Q39hSTg92RV82rYafkMN+g4eQ Yzdjmo7bSgO/MF8D0kWljA28PowWvZwLCXqSGOXb6fH2zh4m2TNOOOSXiCnw zCsM+IfJ38wbOC8H8ObfzRuKV4otPTPvyGwIU9pBW1b7r7ff7Z+iNUfvpPv/ Uu9rG0/a+A12WdkvjOPPuLuMLVGbh3G7ML97dnY5S4pAcyd/RlLo8+N+W32z msOmRnCmLWMCmsdx93Svd/rD8d7JD4f7u9DA07W2qT3JOniWsLKCsGhCNpqA UoZ4NsnoSTeHc+ru7kOL3bc8MXORUErbz1E6wIiyaGFqt0CTY5dcnpqKFKG3 8nCaTDjn4Cbj4n6kIY9K8qbae42PpK+wGxBXTjsQF/lOQ8O6RTJ3wlwcaix2 u2L2Q+aBFOk11CLaiuHeTeAi9AJ9UEU0L3NCePD2tB2vHGN0dYWqpYl9SQvK Vc2KdKmtnmhlqT1t+lZen2T2Nv5MUaPdDgEW7CBqgUapavGhVK/4EB6JW+7c dBzsIlC64Phm0zz9CJfvpgt/e5iXdSlAo5Kep5+ChnYUWvaSQYZ6yrBwG/0F AEjXoJ1hF2SJCsmLy2tirxwvuTWoBz01KmNV4I6uBxig8tvE+Yh2GT2azZbb m4zb2KCWMMkpZyDQaIRCGvDVttT+cn2xDY0ewKQQdVitoIFpOzo67h4Cdv0Z 6PWflgxo0KNz1NMuBa17/hsOtnCV1loUcn3ZKhTDlmvoTET40LbHgwHDGoOJ Ar3oHuUstmxFXJzgrSB9zOeTll+Bcx3IbpVA6aM4P/yP2QEcIt0ru9nk/gy1 WWiqjnb9qyhSGVibbdLklBqUzAQh0+84P68cjx3pR63ESwI7DpFiJmdCZkT8 iTYx/D203V5J43Dil7YM8zFbE3/2X+Iqm4PhTMuAONlnAFArgEYbDrPuZHNS CVE9hdlbPqWDgT7IaMimWfQtK73/j+rexfFy2u4Zcxj5biGkOrCkYmR6ab9g X1f0pCh0gwhPaUH+VsRLUKtIdgLpgdQmRwZF9yWdD4vqybj1IGi40pn6qSq8 KBdzt8JBZTYpsWU+Z0LKRx5e9fCm2o6Kj8qG1JyVB7LrYq5qQSdFOWOQvIGc XIbW7zIoBDJzMZA0lMm9BhZld8QjX32pcMlN+F9beEwPRJCdTlGubbb0iDQ6 vK0h1ZBPgWHiewzORPBwg0N0RqPHahNrbpRpd4wKkr/NAJE+rBvdDS+ds7v6 uJLXUssK/BRMnXQL0GcPjRCw+auKOK2jSa5Et0ZlUhlvL9VRS3d55RwWTGO2 6L9XrwwDaVlhuSwakUCqh3wwEHlA2baje0Th/uNvUYjv/ho7pdb8SzZMtfG7 2TflWvnAkftHD/5gdq53T/ix9X9iYfjV+1hbE7vesP0PPqj/e7z2dO3J43V4 v/74ydrjf4mefvWRBJ5/cv1fYP9v3f57beOp2H8/fg5fyP77ydqd/vc2HrL/ dmyKf0824H+KXmP+Osmbng5GjR+Ptk9/eAFjwx+OjfhONhmm58hJK0NroxeS F9LQyZ/LduJc2zX0lvzp6h0QdslgH3hP/YZIiFOMPoSGJNryW1KsX8HE27fk hvmxqvl3YpFtAYhllQ3nZrWff7TBR38MW2LX22CbrVE7fuG0/Ye2z66Y4KYD 3XdW3HfP7T6B+99FpF+hj/r7f+P54yfa/vvZ83Xy/3q+8fju/r+Np87+27tR g88fxKqrmE+nGbyG6ySP88sK8y6v1PJ2XsqYh6y9lrPz2pc+XOsgaShk9bWs vZc0UWf1dQ17L2tJ/qj2Xrjsen1Di/+V7b6W22HP/kvWucb+SxoIQMCV7b+k KcsMDA3Aqu2/drTVFwqigPalZN4F/QGt5spMHMfMsf4RgcxzCfBJcXHiWeyb iM2BfJ6RUZdl/nVZPMIwCUX5Nerj3LcUvM0vScS5+66PLbqvKPmH+yrNytZo y9mszZnyd4zTLCR60bRt4D3m4UZN1wJ6LJLlm8FhBPJ4gH+FTIm0GZHScqkX GI7H0QsiRZrXJNbVRhEqSMss5v+YrIUq5NZOPIETQCrTECT90qTQzHokWOWX JiX6Yt3SENBcH6OPtFQZlRcJI/8c/jmQl0d1zaCaoa1ZhlEBUye8Hef/Psgm e/ghmcxo2VSeaC/Td+0wjuuHYYIHASaapE7kOx7EkS6xSwXqRoGrHBjDPVn9 mnF0Hx2WYoty/91DNmir6fa7k1735HiPw29DP1CuN8Y8EqGecLljwC7n8xFQ ZTjYwLrPjvl7eNktyEuVfpoE+/7UpYKGe5L532CgdvuwEVZf9rTp/Dxopaly 84SPYEl1P0jzVrOjUoapVE+DzxjYSy/IMJ0MeoDbZ71s2Lr/6L4KFIYZQ6Do dy/sJjc3J9OssDcP+nCaK+boV9SCywZqu9tCFiBYsEeHCoMjqdPRqzmla9qA LohP9Gi/s5u+dy+SpmGAptGf6s+cYB2+dqvRjh6to9/ROAj/qsrPt/Ilhzg8 wcDaVUwTlw1H0aM8gZOsHVFKNwnWg2jAGp6PiYE25HWhAVTc8N9kgSzAz5xD X1oZqWEO4G0ee8oRzzdxS8+eKYEfyZALsLF8dzNepxTnlzOzcYC/niooSdrU 2Vdv3YuYAvVhI6nE6rMTuqUPHzogopowydl0Z+/TXzs9MSjmhb+JdUMs4a/b j/FonhQhdCljq9K0UsW38TS695GacBeWEBJHhSWjQxMiMSXEOhnIhrWkGzv9 ZYqo0T1f3Ef0InKXjF8buOYeTXqyW4k9W7OwV1/XkMF5fFapf3cK0mrc7D6o Xd/cpF56cNrJ7g0Y1LwV2hu6BFs0BRsFUvOzHDsI1qJkYX4wNfoGw4aKqy/Z p8CNe+ZvP4PAtwSEeKAXOLCzNjVS3im9D/Y2UZXy/UM7yuRHCYGpMjwuaQij d6mi1Gg76mHEaIwiWgCb+dFOSNYL4C6r/so3P4ClGwHW/XYOYKA4H8PG3yJ9 1qTHHu/QglPnFPb32YKn8uK73fiAEK1G686mmINnVdRH8D3NGhN50u9b2jdK u1dzYtSktVWcsdV2wPslcCkKNQFZbVCTSk1oU76LGkBkZBpg1ORGD21BH4jL Ekw8CPSjoUJ44DucwxCLrb7s8XFbcL/WPv5R5cSDNqA8fAh9OdtNCW6tYf4t cLw56yHyITdJh4R3/ZrntfrErlhE3rVPYOkGrD81soLc/02uIUzKpzgO5uOF 1FyZ/JUrp35FsFBpJbimWQ/4bdbBvny+1SWgRRAstVAmkMSZyAq4lo79eZ73 0J6yN5mPQ2b1mK9XF0A3SENPUV1ZiwiXajFrrfhA9n4U2e8yvF9JKDfI/FTV su84VsvJC/vYh1ctdiHDr2131m13jn7aAnzfoZDUcKH8/e/UgqTLvv+n+/6b rfuBNAV7WJuKoZ4BlaMJwLJ3oKtTINjtvw+1f5B8UsfdbdXdIFwKBfHBdSjn A6iNTaxSGtPRf8Sk6hSz5a5G4zmcRlJrxGpk0SDpj2K9x3kxc/aIcWFwWPY0 7EH+pu4i3NrOeZbxLXUbuMdeyhAyxmlU3nKerbGaZ2X5ChdWOc+e+D+a0SIq KJ51ig/ptIVwUzqdamdasw6egNb9X++v2Chw1sGVB1DtTgbJ5xbR4LXiO3W6 CdLp/GrEga83I5K9QMfQE8ki4z4qCktpEJvsQE2QcsE4oiyvjvMiWSgyllbU +b3SYKmOHgcioWsO4rsACXulkagxvOcUkvILv/0aqXxt5UUkvePsIsZsTv2r jd25vcJU9a1dZ5VEUt0hu9oRs8ilqiJfcgad2wlxpT5wL9wDRx+vBauTjFtW gQigZWvDrZNQ5q/s9tukdGVMnrLKKoWVHCSk1pcmmvZlsDxMlQ5lteS8cpo8 MqENeMIBofBSQ7/KgEsEsCH6SPIpxG8pF/p15iNTyPqAe4uFpzqyMCVjh9BY Q8JzQMFXxwg1CwGLneSzlpGW0fse6slbddKE5R51YH6ZwIm5LRm7Jh3LxPQy sska/OSip3suvbNUFZdkdVgcJliJKbPy9PQvQoRz/0KUfh3gplqetBI/AsmJ a+7hi4cPnf5LoscAYYYyArj9p3EfkPmFg/Zs8s3qiF5P5zOSvUEVBxKdJaPI /M54bElFRfP2Xjl5wWElRoZhgE/WspQm7iwYlH0P/+8Ay3I+u+Cbksn2X34p rSEW5F3yq3g0OGGPh17y8mBioWBJfEo5x62V1NpOa6P4N+rxqpbMN8LAp6Tk ZyyWowEWbUU9v+djKIf3u98soatKi4HbVry77obEazsHktLIJsNayZunW5AP 3ZnKFqTaqNRG0AcuzySJaYEPhyL2q+SCdgUl51ksBrSbJvW+qemfZdrG9/fx H7uWSAflTiICF9cJGhhZx0tPj+vS5dLympGbyJ2WW5kvJZxIuK4zRX+afFt/ 98K04p9pNU1TfPUlsbp0Ll40/W+s0SkjfHcR7C+CgERAbQ60j6FkZn4KxuV2 y55KYBy/uY1+V4Fg8VmAMfBZiDVqbAB9rCFrV4058KnHHjxB/u9tSBJsMeRV hJgs1l2zLvhllPpKeI+1RW1fK723NJUk8iU5/pUIOS23WUaAD52UBPiiFJKx Wvo/WoBVV8GjYhlgOzewe9/axv73/AT8Pxy3ua/RxwL/z8fr6xs6/u+T52vo //Hs8bM7/4/beOr8P1z/yfBz5/9x5/9x5//xT+L/8cqkCcAl0lmk1PlJFMIo RQE23hi3F7eXeD/dB4ej4hCylfFXici0Qhnlk/70ssWpupHk1Na1b0/eYFA5 i+/HQu+t12iQcv+Xtfs3I/WyYw3Zc/wEZ1CFxfRmo/QCRMrfUVl3Dz0B+s8N dPAV+lhA/z1de/xU6L91IAafkf/v+h39dytPbf4nN+LFN6X/7ii/O8rvjvL7 ZpQfowK0r4sHj2hgKxGGYRVqEPctQfMoKDMnWxGTrIGLlBJDNC3scnPkn+kE KD39d8sJq0ehZSmobDRqcXhrV+7WYy+rHsvqvne1xSb4cQfzmHumhA8fOpVv UAVqzxTo8BFsw8fkiyfr68brZ7u6eguzJdcFe7az/PKkvLVhh5IFa0BmA84C vPQWoLSh6sO39OjxVmMvuP1faUFeeAtS2vNvvCClwzCfjK5wCsoT/n4JALCt TlzwWWKxflt2qa3Dd5Zn8aAfF9YJvGPp7p6rPyH+rxzW7sv6WMD/PXu+/ljz f08p/uNz4APv+L/beGr5v0B8Q/+5k//fcYF3XOA/CRfI8Z/mmNgGBoShn3Bk gB7wnGTjSExGtjCL4cd0gMnxeB3z7AxdS+IRKQzQkACbk0ntqEnfL7AFaLC1 Eg0lYlGJa7yNsEmWYqDhdbi5SSatJHkfJBR4KsmrbCuI5MZ2pj3grmYJ2VE6 LqGifcA2LQIU18yz4ePALclkQJ5ss5zd1c0Iop6JtYIPtqiKSjwWLNGOWtjG Khf3nabw06JgL/g8fJjYHu2WZZH4LdJn15DdX4WSyRF8/0l/JpungG2PzULw ot0ED7HE/pcVSF8IDbzBupHeKEHnL/1bm5qW/YH+YMCD5R6+cGf6DwxLzI/6 QETuXcshEc/zkwyqBGgoqov7PRTf5eHDtI18K+6azU4q9/tqgHCWXTn6L9zh Crvl217daxzRmrW+wgG98t7Qyvpn4p9kq7yz6ppRznJv+XEV1CL0yEa3B1QS hi1rRr/kv0x+mf0y/OWjF+7s0q5EYc4q6mgcerkQk2F77AdwGT2M1tv0wnIH uHQlo6Y4kGCfb8YV5lr8X4D/t+LXfx0ecwH//+SZpf99tk75Hx4/eXrH/9/G U8f/W4AQRpfRHf9/x//f8f//NPz/27ToJ6NRPEmyeaFPi2LVa4z+zDujF/aM ARWyudE4yCecynWcjM8StF9MZ2k8QkLECoxsm9Zp/4qjw+3ewfbbvd7J3lHv 5PQYKIrmL5+Hw+ZNJiENRG22OdOq8JnoVpLkuZWQcaZyTHMWVc6fSh/xzw7r x8qMJfBGLRUvFKOFKmcbqqTUalu3o9ZDB5wKb5eQ/80sX79KGCb4d6OyPPHt nhuMG5fIohx9dxlDMbI+FEfW6cvIsVvXbz1QHFvsj6ctrqkMULGqF9L0lhSs C3eCj84SW6AL3t7aq4XkBbzS2rtVbmWtb4H+C9D/oaRYX9RHPf2//vjJc53/ 5fnzDdL/bWzc5X+7laeO/g9mR/OeO/r/jv6/o///Sej/E5/ip5WSFDBRARuI 86S0LbgQrus3g5rPI4SSrejMKhZ7wHmj3RQqJfz07RKs7MazGO0l5n0gCJKi HZ3SItxjlWniUPCU9+QA8Nhp1t19G0+nSMwz8WHTRSaniidFHgCtcctsh5uS 3l/3zU1SBZ/CYS0QPoJxPVWw4cCMmNxa03G3iF/hJrxlisb8b/H+1+gFlTZE 29+i5qw/bbYJZe0c9U4BvZwcHR6fRr+17UJFMeJCJyf7lYXmk/QzlXp30P1L VSk4TWtKZK7id5RCivG8XRvbWSegpPM0ejraWPt+SdWGH0IBxwSEqmM/hhf1 QX+OCTzU2pbjaMD31ZcUmQHtgTHyQAUDgAOjyI9c/PrBo8hCtTS3hw+h6cqI FmaUvuGkt76LYlrMJx8m2Se4ixRAE0pTAb9IOVodoaIuPoXDYPz9BS9UOrhV 9k0fPbjF8lnVWT6CbwzLC88yY6tkMpjO8hC+0szUDG5NPg5W8iGu1146w4t0 hICI3pWBuG2wL/gPh31xQ8vF0WQ+TnLALvS1FFduYUg5nMvL6NnTp4+fBnrG r9ih6Q66SQcRgRD0fJbkWxxjFaijNbzTqaVyuDh5mnSXoSH3siN1QKjlbvXK LcBU3fUAN/g+UAijhQD1JRdADvQO4m0mFzY3AXPv7Hm4fZCczc/tQrt7r969 8Qqlk2FGF4Aq1D14feiVAfJr4pQBmvbAK8Nps6zO9o6PgVJ1Cw2BehjZhV5v n27vL7xsKm5ROpRXQPRXRfK0WTaWD2BrC1Nb5u3VGHrJGGUKM49gnSguJwKU Qsz2iTfnrByL8RcGk19gwX9hYOA/ccv5L9o0DOeYww/aHOjiOkdQI/hveepe p2h2t/DYVZMuNbD2u6Bq5DZ1sYxl9HPbN2vdfpxgXKeFV6rFBnAgMolepi7O rVIxNGvAMFJc/KEUVwYJVk6NRdf1bDy1rmtqLnBNl8CBX5O4FtOEDUdwQhxH o2Uv9hfli108iVR4ROs+diTOK5GhDXA5bpk2sCfwZ4owb7/54MwIeWkAhKiY Jv10mLIg5c/pKDu7nCVFeeI41vU1MyRriVtMlLyE7xScy0S+rBjb29LYxovH 9jY5j92xQbHtEQyBAoOP7+My/tc8KZBxjM8QHZwl/XgO/eOe92ejS2ww/oDF 01k0ToC0ttu6P05Ho/Q+bcX9MfQGY0KRUZeFciQpkd6gOnRG8hkUyq4O8xQj 3V2Gl21jwbJtLLlsb0rLdr542d6k/rI5Y3u8YGyPK8ZWgmu4GPOkn50j5h6Q 2RMs23CYfgaIx+8yaix5v+5q/HPU+qCgEKOcRK2x2vgVvA3fRK1zNaWVq92I uJ5qjqFoy05QZf+AzjKMlJ3//+09a28bR5Lf/SsmCqAjfVqZegOkLICWaIVY kdSRVJK9rDGgxTEziPi4IWnLl8X+9uvqd3X3PChxSF00DSSmZvpR3V1VU9VV XTV6miD8/9g8k3tx3f8KIrJPt4NoMJ6vxQks2f5zXKE2n7PTo0rl6PAIbEEH p0cHh4X9ZxMl8f6XgQieoxT2n8L+U9h/Xon951KGfhsPJoMRM/oAjzBMPTNg GQHBJsslbEkklMUQu4SRB2TW+BnNTYwfUYf3OX42+2b0NYpmRue2Len8stP9 UDfahdNZgwhJ03CyyOiwpsIBG3YnnWtuzyK1qqubDna1Wr/sN3+u95udtt/q XDV69LiNCW07k2k0huMq9tdguZiK3wQrlurNjMjmUUCVgh1qsWLDgd8OHqx9 1/LNAfnpHs9LnQxc2XsnKnJNkAymNzHG84fBl8HyYTGvvdG84mLq+NxbLreN cpjbMCj6XzKMBU1cAAyDaCK7Elh0Z2RAuv1KCdInXyTIR3vV+Fi/u+mbi11z tlmE4wDYsrNZv9lqEE6utRwGiW2vGomt4TzS0eq22b521AZZzA/hNlsJ2GcZ kj8sw6GeCcMfRdPlzKw0MiqNB49+SJByMLmnSZvFuK36r36z3evX25eNXozq 5QgkgnBGG4dwzXA0Ue9zTXmQgDyMALm0IxKP94L/8XYpx56XKVhVC3VKMYhT FgfUDrxxteE7qZq5kKaUhDKqqY4xJRe+qKocXUoGsqgKAldKBqaoGghRSk40 keaLYMGXmy9qnvcK0V6LkUumG0EmP0x0AikSVwCzNrgv+VIsgGeV8eGbtN5T 9wbh1gCPFMnoDfgfysuBcjUy3OdQCyLEx6IeJzVk/EBWomzWobrENVB3mBMA LQZa4+XatRYZ92PYctTLPkNOMY6NzNnH4V0ZQ11p1IMGc1FO2mCOzozhbkF4 wXNiRae6tGG0Tozu7wiV4n55ues1umndQmOjv2sgaleH193O3W1ah7S10WNr 8NgUPAB1jPhAWs96L2IAJ1Lz24uT5dgXeA0n80zQEU802YcTgaRE3tw21JQm 3jnqliaT0MGOSyzBzH2Syiaf9pEBEFsAJ9b5H00ehwdOMgFCMGPFCuAveiR4 p591SlVDumfEpx6SH74PgyFjlNAnOzh0+9Lr7EcznMLEFUfyGZ/3yd7uk/9K ei3CzPaYoPa3i7dfKNdkfHbzX4Usn3+2G1Q/qlbvbuQlaO89W+i585YzxzTX 9eYQrjUfogQgkByE1CixKhBA23LVEd8xNuZv4ac9T/yEy7afdKcaV0YtVwc7 O8gVh/1/Q1swklsQv/jxvlLUqPb5YTD5ww+/CBnSnauKVjW/19fie40MjryD fD7b1y/usz3a0Gd7tMnP9mgzn+1RPp/t0bo/26PcPtujjXy247oSLBh1+dY7 5KNjzsyCVsSx5z0mD3AujTrksSgmFsfmTHTySf8ChuzT7yZ5o6LiAmyGRgZH 9GnA30qwfILZ9Qeb/WGOL2CknwdmYMW+EnS7XN8Ks6Xu6JN3RrEUzQIpWKCH 61ffIIQFXwwC9YHmSfEDmTZBhhJtoS8UbqLbnrMfZThOlWTdffNlzMkJTYSm 7TvFUl16cB4IUvw09x3mGyOrAgB75jeiR2UBJq463YRj5hjWrFpG6BSFL+yX IfCQsVyzSvdSxkIwFLcgjOznALUFMDenKwcFWHfjoyjF6R085soCtFoOI9CS wsH8rqema9KItPgpUlaHZrLSmocUb+zwkcpGpWLwdRMqg9JNm3xMy9+FWl0A VRvdevu6AVoh7ea9d3fTadPUNk/S2H7WcZMPjtArBTWF5KGUvUSfkFX0vDRf MjJ3sUPrmnnW2WL3nB00eeaxNoumM8itmui4trrW67YCkN5r26dkh7z7CmnZ dW7+wqnZpaj8lenZpeVhgvY2SNEx1rmXQdOacvkKaVk3ZL1wGtZPAf7KtKvP c3tfYcMm/jJoFU5s0O6AcdV5c4vS5OflF+qNTOjy+xychEp+79K/bvRvf/G7 fq/53w2KwuLsg+zk1+B+MY3OofMLaK6Rpujs3NDbyPP9KKAZs9u9nv/h7uNN o+3f1nu9X67iHKe1NrxbK2AjHIjOBvP5t6HHLMiTL9Oa4+Xb4XI8/p6Ft3DW QpfM0j7Xop0rzwiNw/CHFpWNgsXs22Qw9iMKEmGVcp7kN1mW3ypEWYaVYtnI k67z7tJFKFsJg55m1QE4BKXC73TWRE8SXdrrU9nQn65F5f4Bcpn2Z9/8pfsC 73bIk55/Ivqkvg1PINDrbt4ESg90n0mfdHYe998w6ZO9XJk82YrlQ5+aV5JG oOKpi0JHEaNQWoeQpZrr2mjUIg4veHSf19L0soRU2S1Mtr7/RJY1Ss//+Z69 sx/bhMtO7F2UGzzu02bvaWv7OJdRtgDVJlttrdWi7Y8if/SSKFa3K+ADX93l 6GkyMOriyZIwBiR3eRgNZ1HED3GnvXiqcJkXfF6DHbAfmDSxYiffd9CsGcSV 7cjqCMT0zyKyWm1HZMfos94FyDDpdPmdBWlYm9hu+pRuXG5nKQGTrd/YF4Ba ipBDATd7WNYT0zTyCU1N94RZBPNFyfQX3c6ExdkCmrPUJPVp2yhJBRx4RX4A tsUeoytFjX6M1acqw9oIj9VNLo/rIHUtCxR/NrnyEjk9gDe5SPrJ1FoWxz7s WXlRkI/zJheDqv5oFZgii5fgNZ8ASDipZk0UQyK3C+0xXbuW8rmpeVBt+D3W OpXzhTUxqMeTTTivQ1sYBZ46G8UkpqUiVOJK1xNx6S+nrOqYNIpGDJOEQpNB C4zFJTaMqRElYBOtuBI6iaXaHD4hHQpLNlj41NGL5skxhDVjsUxRTmkVMYuV 8AXQvwIOFcc1nPFBSFl2fBkln+VHl+p2jY3gt5wYveKaU7iYLHRYh3sNfR/j PuS2Rtst0Fc1zuDFm8XLKOapO29gf7e1U0FeBx2z6qcP/D0+5bH0BF7LgRva VmsQyWc4Av9bcKDbmHM54XrBIim3tkvtd1yH25wv/BUf1ImnEqLVJiQf0oRg 4m4peqNv2D5ftZcQlMQR/0O/2LyWGBMp8d+PD2T+p8rZceUQ8j+dnJ4W8T82 UdzxP34Mv0zgPoHvX3baH5vXH5s3Df8n33/zI3kaTgL7BQ8QoKGOF1OKiCFF xJAiYsirixgCETSIELUnwsVDOpUpFdIJDVCYQ3rbTI8jQumTQDoww4iIAPSD Bz1Ux3gwu7DST+lPmDaIong0Hu8DFpgeherYSDaqmKDxsB5W2Ph7upCKvxIB hdL5fZXZhehrGgzNqzIOcO/JudEqTKLRG0EJJw/Az1kYNUdcyvF8VCY9yq5K 9MGfOBAtG709nTQeCaUHkwVAqMEBnafDYLRPgkYEfYuB5JawznAOTOkqmABf WBUUs4NnwNKeLrrBaPkwiJ64KHrzZ8DR7JjYkQ0A3u45uwFxT582uGr6jPF7 0sbHH4vbkrQzwjTOtV73PPSHanvhUTNUawC96OByUBVplhxJq0Qs1LKcYdXz cRU7fZW4OW0N4FgLYJVJoR6SYOLLAvoSZdNpY3Cth9anH5sMDVQLyFYXsIg3 6uoOW+efKX/2duf8vbyjKmdAGtNtcKaY4M325E7xsLpzfNcVdZTYj+Pdw+Bz 8OBaZEc0XzQq30WWBJ4NQLld0kwccA+GQ756Se309SYt1jvT2OjF+qj0wDAT pLjJ00Et44WmXd4/BIOoVHZsQTi/pAAK4kOoxivqYxB8ASyHiOrOuuBKQeq0 l2OJ3EY18T4Vf9WuzyI4owqqTmammCnt5HM4IVKgLySjeJ4WwyASCyzZRTq7 VsDF8EAi62gsEEp2NihJALxtB4RPlMrORaSp+mJyPIoTYNHfnwgWkTchxjtk LpMA7plAl71z6VQDhYOM9k/Cb7StoU8WtwYwZs9R6Q0GFX0PEkiMheZwZlA0 dgBq0tgeZTIzxjJL2l4arfGW6EP6+EqwZMO8TzVTtDD4u0P7C/npOf2CKPJd 0GoJU4aF2TNcouCZP1mO3Yhvn9hTscL8JMaypZVHhFlIXpZx9BvSoWNh9hyg OIbEwO3eL6PITwLRqA+B9GV9/EUyJAAKzRRtnfEJXBCVbpLlA4bagWoZzmlU caox03dAJkRWAGWJnSePid4geQNtZ0lM6oG3y6lVfyQav3dXx1iL8F4IOrbl EVHphecL0UaTaSx+kGt2rybjHo6og4yvvFGzrlafJ3PG855Urs/P3yVX0CTJ fDwzpWSA5r+ioCahZt8RHddlxR/ee387yHca1PChT4OLQcL+JnBwX4pHm1zT GMkLr51NE/lBqOfU1gF1iHwGkIrscwQPvIYNsBxSpoF6pFFZ22jmFZAPmD8G k2H4BZi0ZRTYtnGjKKnFYf/TjkTXM0ay/a9yUgGbH7f/nRxWqP3v4KCw/22i pNn/Gr9eNm6p/yU2/+Hn7LBfQ5wYgaCw/hXWv8L692qsfx+IEMfPrWCJiFAS RBMyM0E/gWAYVp4A+cZl0Fu/DMPNZ2JQ42hNAmMY3QKiEGvnMq0eveMDt6gq h8fqrMO2FShrWpndMxEuftb7OKtHllZqOruB1kJp7nD7LJjPCTtOH4e1CqPF kuyfftWHXgnkQqhR3YTL1rC1V8Zw+OgTRvJJjd/4Gn/KSUnmKrAEq1p1bJWK 8y1Wj96AzE8FcMOTsmU2lOxkaTtg6jhAfUHjwRR+kDlDq4OkQ56Aom7IEYfQ 27PqtcT5aTpbjo6bQkV7awpu3tu/Rhazojy1OPQ/M3Pps9XAFP3vtHJ4wvK/ HVbODk9OSf2zSuH/uZmSpv91G0QobvY73X+wsx1DDXS+ZsKfjUaFNlhog4U2 +Gq1wR6njy/S9AQrxd1BiYT0lc5zQX0gyUJgV1CGaqaaKDXCl+HQ2RrcR9O5 twuWQ7jBs9Csa4KldlrtZrPV9WV6pKtWs+33CTb3bjvdfk8y17SKsPYlO8v4 Xbv5q6pV5rJf/Pg3nWv/tt7/KXZcUUFnvzvvvg6idw/T0TvO/HYyjfOxedNv dBNHYlXUSKWb6WgURNVqs/2x4/3LE38SBtAmf/5zNW8W0brR7RKCV719rPfr N+lrBVfsAEi4aRo7C72SGLeS2nW3cd3s9bv/SN4LVEvuRbC4F/vwLgpGwGC/ p28I/2AnjqfV0fZeH49RafpoFC1vG91Ws9cjykc8mpsV6ZCVs7MzNUZu9Bvj kL2b7o5de/OGe+6YFPmiHLXhxMrwJupf3ip2AWdXyprf692gV4fqFeYy5N2x MyMCdiUBVh/0yUd5Dt8Bpz1dOBK6+iAfzmjBOrklv5iD0qqdKEAI7d+Qb87D s3oge78InPuRrQtIGZ/UOpdTLt1i6xTgt62UFGVjJS3/+zpMwCn3P48qpxWe //2gcnxwBPnfD06OCv1/EyVN/+81uj83ukQxqrd6hu5vvXJkjY8xBBd6f6H3 F3r/K9H7n581/nO4mAeLle92cgJ9OTc7YxUJFWeiJh7pbNRhdzak+Han26rf 0CB7NM2XfFG/63fEY020b9Xbd6q+JtgTzYvIhP911+j1xdujPeXtH5MImtTS INhLqs4jl5EWJ+Tjb1d1xXyLrazHQouthALjqNVJ0IliEwsm5edLzt7nTraH c+QZGe5i0tPB4w/Nfk8+AKqbsliWw6E3Cb6xWJZzj7D1wKWV6eZ7K8Ljp5pd FRz3XdmrDO8GnKi+Zj+7T0tAivwZHE1dUYUMj4aYDNiOVNc1u11mEMVNxqel 9XRm9JTXMV3XBvn1MSOIp+siGlYynXEwMzVzxYfM1FCPmehqIOrRcIJJFViU uExjogBgzgU0MMcw8ifgFbuvk5qZr+aunJTWBDXJmtcINUpLnIIquzM3oCpx 0eNRpYwBq43LthnDz9ZiGmUIwombrhjeFDfOGPYTN0oMj4mrpsQ/xJVXC25X e2OxXW83NTKbxtRkbCr9MyCYZLbgWab7FiCOO7YbJuTYaG5GtfjobUZFO2ob e44itbFHODib0Y8jJhu/cwty6bn4Il94dlQ2voBopXwcI4xXUTKgh4OMbftC GA6hlvGrzL2jOOYJLMv5mkxa0Gv3LR4LM3OEEiFWlpjVqSBL9N4e1AmiggG3 m3K3B7lDVjEgxiwkR0jdAOpCkgGZZGIbBwoJZgZUio9ub1dd0qABpsHRc4Q1 MWRqFjkUQ74Bhqqbh6wz3m2fVxdlvcVl/yHSfDC8IZLHRuJ/Vk5ODs/4/b+D yuEpjf95WinsPxspqfafn+rdxtVN5/LvpvUHv+C2Hw11HOcetGzK9lNYfQqr T2H12Z63J2UFXglCeLyjgJU9GkObmTdg3wII2UKzPcJxBhDW4neozqoElhlI 1dj/Pb9bgIqHGWYXIdDJ9yVwuCK6GBEh5/49WdpFqQIRlIgsNwypD9YuixIu AyaxcxStAz382SOZ5pzgh/6GHgItou89q41403A1ox0uJw/8ET6OEWctCuya 5LFk4y4qFKcZlHveOftTQuexhrQn/ciCnVTIp3INtOXI6SCDbxshqWCYunlG rZL66e0+YPvDv63K1lLqrfM8q9GniDY8aZYYM9InamHSduYqTp2Mxa9WU/aO AllliFh6kMFu4M99THI5XoG0oXZgEQJNUWn+q4l2WCxoEpokranFr3JfVgN8 N9rGLW7eijIWh7ct1mcuLv2Pmhf60z8CSMYcPV8JTLv/Rx5K/e/kGOK/nJ4d nBT63yZKqv7X7zbb1/3O3xvtZq/RNZVAx1su/plI5NLoCjfAQiEsFMJXohAy N0Cyr0MAiN5+ID8IfwA6mY49Hga15s2i6ddwCIkQ2DpG08+ESZPJ0ugxEA4Q uuOTuhST/o85S3sNWpm4YRh7XXDtooAenFkyvRjhHFdiSiTk2aa6Yzh8LFXk vZ2YJu7oxspmr55D8NYSdc8YBg/hmGxkxEMCQ4WZ/+138mg+g43m0ZlrMX3Y Q6oe3ZfwUobRFOI/wpkFJDbBUzUVXBiR1xZtlwRYQi/6+gr3hvgrRWx5zSZR AMLDwojDQ+cNmOsOKh7+b+AvPIjCG0wWTcLjHw2PJeRzAcv3i1y9kmvPkZb2 1Fi5bhQznsqoudZzy5DlaJgQP3custnz1QF6wA8IXeSsIWGIhStfKtEJFYn8 hgjhZUEMlKTJg33y72jxe6ms3jAaJ9wh7xiw1pxScVyGiIXc7Z7cFpgM+1tO h78gcwGX2vzj2VpzkcQnYN4EKCz/qAmKTuxGIFYK1TldwHz9Xxih2LC5GI1h DGe0lbeC7FAVtq38FMWl/8sbEusaI0X/PyZqv9T/T4+Owf57eHBW6P+bKGn6 /12fKkuG3q8/ZdK9RJoErb1Q9wt1v1D3X4m63wrn98HDw2ASTJdzSS0y9o8V 8DWKJlMw66pHl53uhzq19Ga697d26eWpl/mYE5/wQJQX+jiHNA4FUC46njNE k8ovuCbFMqOpfCjNIZHpwnuIlzRlMh1BfoYac8L1PLjzBAQH3IosI+FKy4js LmV7O7PpYP/+fifuSthtp+63662G32vcgthm3PLiLYzkWL3v80UwZtFJwN+f 7CcOfuHOqaU3M+4c0OsmKAHTqtmeUlJdJaSoygYJWy4dBPnkWWNv1d0fpcOQ mbDMrcIahPGW0vIGbG66FLJtOaooRSlKUYpSlKIUpShFKUpRilKUohSlKEUp SlGKUpSiFKUoRXkJ5f8A5uON/AC4BgA= --0-224614406-1046648421=:32537-- From mirko.cambi@bancaimi.it Mon Mar 3 11:15:00 2003 Received: from smtp.bancaimi.it (smtp.bancaimi.it [62.128.65.14]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h23BF0807928 for ; Mon, 3 Mar 2003 11:15:00 GMT Received: from dns1.imilan.it (mailhubout.bancaimi.it [62.128.65.2]) by smtp.bancaimi.it (8.12.3/8.12.3) with ESMTP id h23BF1SA004545 for ; Mon, 3 Mar 2003 12:15:01 +0100 (MET) Received: from milan5.bancaimi.it (lotussrv1.ux.imilan.it [172.16.98.118]) by dns1.imilan.it (8.11.2/8.11.2) with ESMTP id h23BErE13286 for ; Mon, 3 Mar 2003 12:14:53 +0100 (MET) To: omniorb-dev@omniorb-support.com X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: mirko.cambi@bancaimi.it Date: Mon, 3 Mar 2003 12:14:54 +0100 X-MIMETrack: Serialize by Router on Milan5/SRV/IMISIGECOSIM(Release 5.0.10 |March 22, 2002) at 03/03/2003 12:14:55 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [omniORB-dev] OmniEvents and JacOrb Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: Hi, I'm a problem to use OmniNames with JacOrb. I've ny PushServer written in C++ with OmniOrb. I use OmniEvents to manage the Event Channels, and I'd like to connect my Java Push Client. I get the Channel, I get the proxyPushSupplier, but when the server send the data, the client doesn't receive it. Any suggestion? Thanks, Mirko Cambi Product & Business Development - Banca IMI - Milan This message is confidential and solely for the intended addressee(s). If you are not the intended recipient of this message, please notify the sender immediately and delete it from your system. Unauthorised reproduction, disclosure, modification and or distribution of this e-mail is strictly prohibited. The contents of this e-mail do not constitute a commitment by Banca di Intermediazione Mobiliare IMI S.p.A. (Banca IMI), except where expressly provided for in a written agreement between you and Banca IMI. Banca di Intermediazione Mobiliare IMI S.p.A. is an authorised Bank in Italy. Banca di Intermediazione Mobiliare IMI S.p.A., London Branch, a member of the London Stock Exchange, is regulated by the Financial Services Authority for the conduct of designated investment business in the UK From duncan@grisby.org Mon Mar 3 15:07:15 2003 Received: from grisby.dyndns.org (pc2-cmbg4-5-cust210.cmbg.cable.ntl.com [81.96.73.210]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h23F7F819356 for ; Mon, 3 Mar 2003 15:07:15 GMT Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id h23F6bK31324; Mon, 3 Mar 2003 15:06:38 GMT Message-Id: <200303031506.h23F6bK31324@grisby.dyndns.org> X-Authentication-Warning: pc2-cmbg4-5-cust210.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: Christian Perez cc: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] Removing an entry from proxyObjectFactory In-Reply-To: Message from Christian Perez of "Wed, 26 Feb 2003 17:00:33 +0100." <3E5CE4A1.22AA9EA@irisa.fr> From: Duncan Grisby Date: Mon, 03 Mar 2003 15:06:37 +0000 Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: On Wednesday 26 February, Christian Perez wrote: > Taking into your comments (no STL), here is a modified version of > proxyFactory.cc derived from omniORB-4. If you do not see any > drawbacks, it would be very nice if it could be inserted it into > omniORB-4. I have checked it in with a few small tweaks to use traced mutexes, and lock holder objects. Thanks for the contribution, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From duncan@grisby.org Mon Mar 3 15:26:42 2003 Received: from grisby.dyndns.org (pc2-cmbg4-5-cust210.cmbg.cable.ntl.com [81.96.73.210]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h23FQg820420 for ; Mon, 3 Mar 2003 15:26:42 GMT Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id h23FQ5p31543 for ; Mon, 3 Mar 2003 15:26:05 GMT Message-Id: <200303031526.h23FQ5p31543@grisby.dyndns.org> X-Authentication-Warning: pc2-cmbg4-5-cust210.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: omniORB development list Subject: Re: [omniORB-dev] Patches for IDL stub generation In-Reply-To: Message from Thomas Lockhart of "Fri, 28 Feb 2003 10:59:39 PST." <3E5FB19B.3010406@fourpalms.org> From: Duncan Grisby Date: Mon, 03 Mar 2003 15:26:05 +0000 Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: On Friday 28 February, Thomas Lockhart wrote: > Does the python standard for CORBA specify the visibility for interfaces > other than CosNaming? The mapping is silent on the topic of IDL compilation and layout of files. It just says that IDL module M should be imported as Python package M. It's up to the implementation to make it work. You really ought to read the mapping spec. It's not very long. [...] > > acinclude.m4 is required. It is one of the inputs to aclocal that > > generates aclocal.m4. > > Hmm. When I rename it aside autoconf stays happy. Oh well... Yes, that's because autoconf reads aclocal.m4. aclocal.m4 is generated from acinclude.m4 by the aclocal command. Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From duncan@grisby.org Mon Mar 3 15:27:39 2003 Received: from grisby.dyndns.org (pc2-cmbg4-5-cust210.cmbg.cable.ntl.com [81.96.73.210]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h23FRc820482 for ; Mon, 3 Mar 2003 15:27:38 GMT Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id h23FQxM31559; Mon, 3 Mar 2003 15:27:00 GMT Message-Id: <200303031527.h23FQxM31559@grisby.dyndns.org> X-Authentication-Warning: pc2-cmbg4-5-cust210.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: Thomas Lockhart cc: omniORB development list Subject: Re: [omniORB-dev] Patches for IDL stub generation In-Reply-To: Message from Thomas Lockhart of "Fri, 28 Feb 2003 17:23:04 PST." <3E600B78.8000900@fourpalms.org> From: Duncan Grisby Date: Mon, 03 Mar 2003 15:26:59 +0000 Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: On Friday 28 February, Thomas Lockhart wrote: > Here is a new tarball and patch set to generate more IDL stubs, > based on the omniORBpy-2.0 distro. I've checked it in, with the necessary changes to make it work on Windows, where there is no autoconf. Thanks for making the effort to do this. Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From lockhart@fourpalms.org Mon Mar 3 15:51:24 2003 Received: from myst.fourpalms.org (www.fourpalms.org [64.3.68.148]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h23FpN821735 for ; Mon, 3 Mar 2003 15:51:23 GMT Received: from fourpalms.org (localhost.localdomain [127.0.0.1]) by myst.fourpalms.org (Postfix) with ESMTP id BC9FC35398DB; Mon, 3 Mar 2003 10:51:23 -0500 (EST) Message-ID: <3E6379FB.8000906@fourpalms.org> Date: Mon, 03 Mar 2003 07:51:23 -0800 From: Thomas Lockhart Organization: Yes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mirko.cambi@bancaimi.it Cc: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] OmniEvents and JacOrb References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: > I get the Channel, I get the proxyPushSupplier, but when the server send > the data, the client doesn't receive it. Any suggestion? I don't have experience with the combination you are using, but be sure that the "server" can resolve the IOR the "client" sends it for the Event Channel callback. Note that for this part of the operation the "client" is acting as a server to receive the data... hth - Tom From lockhart@fourpalms.org Mon Mar 3 15:56:19 2003 Received: from myst.fourpalms.org (golem.fourpalms.org [64.3.68.148]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h23FuJ822007 for ; Mon, 3 Mar 2003 15:56:19 GMT Received: from fourpalms.org (localhost.localdomain [127.0.0.1]) by myst.fourpalms.org (Postfix) with ESMTP id 0A27435398DB; Mon, 3 Mar 2003 10:56:10 -0500 (EST) Message-ID: <3E637B19.6000705@fourpalms.org> Date: Mon, 03 Mar 2003 07:56:09 -0800 From: Thomas Lockhart Organization: Yes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Duncan Grisby Cc: omniORB development list Subject: Re: [omniORB-dev] Patches for IDL stub generation References: <200303031527.h23FQxM31559@grisby.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: > I've checked it in, with the necessary changes to make it work on > Windows, where there is no autoconf. Thanks Duncan! - Thomas From lockhart@fourpalms.org Mon Mar 3 15:57:21 2003 Received: from myst.fourpalms.org (fourpalms.org [64.3.68.148]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h23FvL822079 for ; Mon, 3 Mar 2003 15:57:21 GMT Received: from fourpalms.org (localhost.localdomain [127.0.0.1]) by myst.fourpalms.org (Postfix) with ESMTP id AC3C435398DB; Mon, 3 Mar 2003 10:57:22 -0500 (EST) Message-ID: <3E637B62.9090007@fourpalms.org> Date: Mon, 03 Mar 2003 07:57:22 -0800 From: Thomas Lockhart Organization: Yes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Duncan Grisby Cc: omniORB development list Subject: Re: [omniORB-dev] Patches for IDL stub generation References: <200303031526.h23FQ5p31543@grisby.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: > You really ought to read the mapping spec. It's not very long. Hmm. I think there is a subtle hint buried in here. I'll study this email later ;) - Thomas From lockhart@fourpalms.org Wed Mar 5 18:22:32 2003 Received: from myst.fourpalms.org (dhcp-79-95-244.jpl.nasa.gov [137.79.95.244]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h25IMV806818; Wed, 5 Mar 2003 18:22:31 GMT Received: from fourpalms.org (localhost.localdomain [127.0.0.1]) by myst.fourpalms.org (Postfix) with ESMTP id DF2FA35398DB; Wed, 5 Mar 2003 13:22:27 -0500 (EST) Message-ID: <3E664063.6010107@fourpalms.org> Date: Wed, 05 Mar 2003 10:22:27 -0800 From: Thomas Lockhart Organization: Yes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Waller Cc: Duncan Grisby , omniorb-list , omniORB development list References: <200303051433.h25EX4j08187@grisby.dyndns.org> <3E6633D5.6050604@coralwave.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [omniORB-dev] Re: [omniORB] Implementation Repository Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: > ... Looks like Tom has > got it and is going to make it available on his web server. OK, James' tarball for his omniImR-0.1 is posted at http://www.fourpalms.org/pub/omniORB/omniImR-0.1.tar.gz - Tom From Harri.Pasanen@trema.com Wed Mar 12 15:47:25 2003 Received: from mark.labs.trema.com ([194.103.215.2]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h2CFlOV02023 for ; Wed, 12 Mar 2003 15:47:24 GMT Received: from labsex1.corp.trema.com (mail-2.trema.com [212.157.192.195]) by mark.labs.trema.com (8.9.3/8.9.3) with ESMTP id QAA17019 for ; Wed, 12 Mar 2003 16:47:18 +0100 (MET) Received: from dell-harri.corp.trema.com ([172.24.16.159]) by labsex1.corp.trema.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 12 Mar 2003 16:47:23 +0100 From: Harri Pasanen To: omniorb-dev@omniorb-support.com Date: Wed, 12 Mar 2003 16:47:22 +0100 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200303121647.22967.harri.pasanen@trema.com> X-OriginalArrivalTime: 12 Mar 2003 15:47:23.0247 (UTC) FILETIME=[AC4CE7F0:01C2E8AE] Subject: [omniORB-dev] Bug: HAVE_VPRINTF missing from autoconf Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: Hello, Compiling omniORB4 CVS snapshot with gcc 3.3 CVS snapshot, I ran into a problem where the compilation failed with the messages: #error "GCC no longer implements ." #error "Revise your code to use ." This comes from cccp.c in omniidl, and is caused by the fact that the guarding HAVE_VPRINTF is never defined. I think something like the following patches should fix this -----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<----- *** configure.ac~ Tue Feb 25 10:38:39 2003 --- configure.ac Wed Mar 12 14:34:48 2003 *************** *** 82,88 **** AC_CHECK_FUNCS(getaddrinfo gethostname getopt getpid gettimeofday) AC_CHECK_FUNCS(isinf insinff isinfl nanosleep sigaction sigvec snprintf) AC_CHECK_FUNCS(strcasecmp strdup strerror stricmp strncasecmp strtoul) ! AC_CHECK_FUNCS(strtoull strtouq uname vsnprintf) AC_LANG(C++) OMNI_HAVE_ISNANORINF --- 82,88 ---- AC_CHECK_FUNCS(getaddrinfo gethostname getopt getpid gettimeofday) AC_CHECK_FUNCS(isinf insinff isinfl nanosleep sigaction sigvec snprintf) AC_CHECK_FUNCS(strcasecmp strdup strerror stricmp strncasecmp strtoul) ! AC_CHECK_FUNCS(strtoull strtouq uname vsnprintf vprintf) AC_LANG(C++) OMNI_HAVE_ISNANORINF -----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<----- and -----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----*** acconfig.h.in~ Mon Jan 6 10:11:54 2003 --- acconfig.h.in Wed Mar 12 14:29:59 2003 *************** *** 159,164 **** --- 159,167 ---- /* Define to 1 if you have the `vsnprintf' function. */ #undef HAVE_VSNPRINTF + /* Define to 1 if you have the `vprintf' function. */ + #undef HAVE_VPRINTF + /* define if you want mutexes to be traced */ #undef OMNIORB_ENABLE_LOCK_TRACES -----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<----- Unfortunately I don't seem to have recent enough autoconf at hand to test this. Harri From Harri.Pasanen@trema.com Wed Mar 12 16:00:25 2003 Received: from mark.labs.trema.com ([194.103.215.2]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h2CG0PV02662 for ; Wed, 12 Mar 2003 16:00:25 GMT Received: from labsex1.corp.trema.com (mail-2.trema.com [212.157.192.195]) by mark.labs.trema.com (8.9.3/8.9.3) with ESMTP id RAA22753 for ; Wed, 12 Mar 2003 17:00:19 +0100 (MET) Received: from dell-harri.corp.trema.com ([172.24.16.159]) by labsex1.corp.trema.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 12 Mar 2003 17:00:24 +0100 From: Harri Pasanen To: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] Bug: HAVE_VPRINTF missing from autoconf Date: Wed, 12 Mar 2003 17:00:23 +0100 User-Agent: KMail/1.5 References: <200303121647.22967.harri.pasanen@trema.com> In-Reply-To: <200303121647.22967.harri.pasanen@trema.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200303121700.23808.harri.pasanen@trema.com> X-OriginalArrivalTime: 12 Mar 2003 16:00:24.0080 (UTC) FILETIME=[7DB69100:01C2E8B0] Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: Just an after note that my patches seem to be ok. I went to another machine and regenerated the configure script, and now HAVE_VPRINTF is correctly defined. Harri From Harri.Pasanen@trema.com Fri Mar 14 13:28:04 2003 Received: from mark.labs.trema.com ([194.103.215.2]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h2EDS4V04535 for ; Fri, 14 Mar 2003 13:28:04 GMT Received: from labsex1.corp.trema.com (mail-2.trema.com [212.157.192.195]) by mark.labs.trema.com (8.9.3/8.9.3) with ESMTP id KAA05170 for ; Fri, 14 Mar 2003 10:32:16 +0100 (MET) Received: from dell-harri.corp.trema.com ([172.24.16.159]) by labsex1.corp.trema.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 14 Mar 2003 10:32:22 +0100 From: Harri Pasanen To: omniorb-dev Date: Fri, 14 Mar 2003 10:32:22 +0100 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200303141032.22595.harri.pasanen@trema.com> X-OriginalArrivalTime: 14 Mar 2003 09:32:22.0736 (UTC) FILETIME=[9DC6E500:01C2EA0C] Subject: [omniORB-dev] cxx backend generated code gives compilation warnings on gcc 3.3 Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: In file included from ../../../../../src/lib/omniORB/orbcore/Namingstub.cc:30: ../omniORB4/NamingSK.cc: In constructor ` CosNaming::_objref_NamingContextExt::_objref_NamingContextExt(omniIOR*, omniIdentity*)': ../omniORB4/NamingSK.cc:2141: warning: base `CosNaming::_objref_NamingContext' will be initialized after ../omniORB4/NamingSK.cc:2141: warning: base `omniObjRef' On first look I would guess the constructor calls should just be reordered in the backend... correct? -Harri From Harri.Pasanen@trema.com Fri Mar 14 13:28:05 2003 Received: from mark.labs.trema.com ([194.103.215.2]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h2EDS4V04538 for ; Fri, 14 Mar 2003 13:28:05 GMT Received: from labsex1.corp.trema.com (mail-2.trema.com [212.157.192.195]) by mark.labs.trema.com (8.9.3/8.9.3) with ESMTP id JAA23491 for ; Fri, 14 Mar 2003 09:44:42 +0100 (MET) Received: from dell-harri.corp.trema.com ([172.24.16.159]) by labsex1.corp.trema.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 14 Mar 2003 09:44:48 +0100 From: Harri Pasanen To: omniORB development list Date: Fri, 14 Mar 2003 09:44:48 +0100 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200303140944.48774.harri.pasanen@trema.com> X-OriginalArrivalTime: 14 Mar 2003 08:44:48.0881 (UTC) FILETIME=[F8BF2E10:01C2EA05] Subject: [omniORB-dev] Cleaning up compilation warnings, question Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: I'm in the process of compiling omniORB4 CVS snapshot on an Itanium machine, with RedHat Linux Advanced Server, using a recent gcc 3.3 snapshot. Pretty much everything seems to compile (after my earlier vprintf autoconf fix), but I'm getting tons of compilation warnings, things like: ../../../../../src/tool/omniidl/cxx/idlast.cc:1807: warning: `IDL_Long label' might be used uninitialized in this function ../../../../../include/omniORB4/dynAny.h:205: warning: cast to pointer from integer of different size I decided to clean these up as much as I can. My question is should I sent the patches to this list, omniorb-list, or directly to someone? Regards, Harri From duncan@grisby.org Sun Mar 23 21:03:06 2003 Received: from grisby.dyndns.org (pc2-cmbg4-5-cust210.cmbg.cable.ntl.com [81.96.73.210]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h2NL36V05019 for ; Sun, 23 Mar 2003 21:03:06 GMT Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id h2NL2RP17626; Sun, 23 Mar 2003 21:02:27 GMT Message-Id: <200303232102.h2NL2RP17626@grisby.dyndns.org> X-Authentication-Warning: pc2-cmbg4-5-cust210.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: Harri Pasanen cc: omniORB development list Subject: Re: [omniORB-dev] Cleaning up compilation warnings, question In-Reply-To: Message from Harri Pasanen of "Fri, 14 Mar 2003 09:44:48 +0100." <200303140944.48774.harri.pasanen@trema.com> From: Duncan Grisby Date: Sun, 23 Mar 2003 21:02:27 +0000 Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: On Friday 14 March, Harri Pasanen wrote: > Pretty much everything seems to compile (after my earlier vprintf > autoconf fix), but I'm getting tons of compilation warnings, things > like: > > ../../../../../src/tool/omniidl/cxx/idlast.cc:1807: warning: `IDL_Long > label' > might be used uninitialized in this function This is an example where to get rid of the warning would make the code really ugly. > ../../../../../include/omniORB4/dynAny.h:205: warning: cast to pointer > from > integer of different size I think this is gcc being dumb. It's casting a literal integer zero (or sometimes 1) to a pointer type. The fact that it's a literal ought to suppress the warning, I would say. If you can come up with a clean way to suppress the warning, that would be good. > I decided to clean these up as much as I can. My question is should I > sent the patches to this list, omniorb-list, or directly to someone? Send the patches to the omniORB-dev list, unless they are huge, in which case send them just to me. Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From MNishant@quark.co.in Tue Apr 1 07:28:58 2003 Received: from saraswati.quark.co.in ([203.193.132.103]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h316Sp110786 for ; Tue, 1 Apr 2003 07:28:51 +0100 Received: by SARASWATI with Internet Mail Service (5.5.2653.19) id <2BBX95FM>; Tue, 1 Apr 2003 11:45:17 +0530 Message-ID: <7D5800A5B6E26644B2EB7A862856B0D40698EA60@SARASWATI> From: Malge Nishant To: Duncan Grisby Cc: omniORB development list Date: Tue, 1 Apr 2003 11:45:15 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [omniORB-dev] RE: [omniORB] Compression for OmniORB Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: Duncan, I am moving to omniorb-dev on this issue. -----Original Message----- From: Duncan Grisby [mailto:duncan@grisby.org] > A far better way to do compression is to add a new transport, along > the lines of the SSL or Unix domain transports, that does the > compression at the transport level. That will be easier to do, and > much neater. It's also a clean stand-alone unit, so can easily be > included in the omniORB distribution. I completely agree with you on this. I should look towards a new transport. Now the new transport will be based on tcp again. so can I use the exiting tcp transport and enhance it with compression features? Well I tried doing this and I have named this as "ctcp" [-compressed tcp-] transport. The URL looks like this - "giop:ctcp:host:port". This transport does nothing special than normal tcp transport, I have to add the meaning of "c" to this transport yet. I am able to build a separate library called omniCTcpTP. The entry of this transport in the object reference {IOR} is maintained with a special TAG called TAG_OMNIORB_COMPRESSED_TCP. Now at this point I need know from you- Am I on the right track? Thankx Nishant From xavier.outhier@anfdata.cz Tue Apr 1 12:47:10 2003 Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h31Bl9126274 for ; Tue, 1 Apr 2003 12:47:10 +0100 Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id h31BlBdp003415 for ; Tue, 1 Apr 2003 13:47:11 +0200 Received: from smtp.prgpu.anfdata.cz (atws15tc.sie.siemens.at [158.226.135.41]) by scesie13.sie.siemens.at (8.12.9/8.12.1) with ESMTP id h31Bl5qH003381 for ; Tue, 1 Apr 2003 13:47:10 +0200 (MET DST) Received: from anfdata.cz (pcp1034.prgpu.anfdata.cz [163.242.71.34]) by smtp.prgpu.anfdata.cz (Postfix) with ESMTP id 5AD7C26899 for ; Tue, 1 Apr 2003 13:47:05 +0200 (CEST) Message-ID: <3E897DBD.9AFE6BAB@anfdata.cz> Date: Tue, 01 Apr 2003 13:53:33 +0200 From: Xavier Outhier X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: omniorb-dev@omniorb-support.com References: <3E840764.D7FBCBAE@anfdata.cz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [omniORB-dev] How to port omniORB to PDA (Siemens SX45-MIPS 4000-PocketPC & Siemens Loox-XScale ARM-PocketPC 2002) Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: Dear All, I had no answer to my previous mail but it was posted on the mailing-list: omniorb@omniorb-support.com. I think this time I'm at the right place. Maybe also it was not precise enough. So let me give more details. I'm trying to port omniORB to 2 devices: - 1st device Siemens SX45 running under PocketPC CPU is MIPS 4000 VR4122 -2nd device Seimens/Fujitsu Loox 600 under PocketPC 2002 CPU is PXA250 based on XScale based on ARM I'm working on Win2k with Embedded Visual C++ 3.0. I have also Visual Studio C++ 6.0 and it worked fine to compile and link for NT platform. I accept any help, tip. I've never made any porting and do not know particularily neither CORBA nor WinCE. Best Regards, Xavier. Xavier Outhier wrote: > > Dear all, > > I have a short question. :) > I would like to port omniORB to PocketPc (WinCE). > What do I need to do? > How long man hours it may take? > Someone already did it? > > Best Regards, > > Xavier. From kwooten@itracs.com Wed Apr 9 21:13:17 2003 Received: from elcorreo2.vegas.itracs.com ([63.114.153.104]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h39KDH124908 for ; Wed, 9 Apr 2003 21:13:17 +0100 Date: Wed, 9 Apr 2003 13:13:15 -0700 Message-ID: <0D2BEB28DE931148A970F8A8F9FCA64A06F074@elcorreo2.vegas.itracs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MS-Has-Attach: X-MS-TNEF-Correlator: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [omniORB] Minor patch to windows build Thread-Index: AcL+0ogzBShhhu1YQoWP0n+2hRMHegAAFDqQ From: "Kevin Wooten" To: "Zed A. Shaw" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by raq2100.uk2net.com id h39KDH124908 Subject: [omniORB-dev] RE: [omniORB] Minor patch to windows build Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: Yes! I have wanted to finish my omni scripts, which are very rudimentary and currently windows only, unfortunately a good solution for the config.h problem was my sticking point. From my initial examination I came up with two solutions for this problem; 1) somehow drive autoconf (or its macros). 2) replace all the functionality with our own. If there are any clever ideas for solving this problem, let me know. -KW P.S. - I have moved this to omniorb-dev, where it belongs. > -----Original Message----- > From: Zed A. Shaw [mailto:zedshaw@telus.net] > Sent: Wednesday, April 09, 2003 12:13 PM > To: Kevin Wooten > Subject: Re: [omniORB] Minor patch to windows build > > Kevin, > > I've done this before in my projects. I have a very clean design for > my SCons builds and have managed to create two projects that I am able > to port between various types of Linux, NetBSD, and Mac OSX. I did > approach the SCons team before about making a config.h equiv., but they > were not too interested. If you read my previous e-mail, I may be > attempting an SCons build myself. Care to join forces? > > Zed > > > On Wednesday, April 9, 2003, at 11:04 AM, Kevin Wooten wrote: > > > Even replace autoconf?? I know you are open to the idea of using scons; > > I have built some scons scripts to build omniorb, the only problem I > > have is that the autoconf support macros are not easily reproducible in > > scons. What is needed is a replacement for building a configure.h from > > scons or Python. I am not sure if this is on their list, but I would be > > open to finishing it if you are interested; I could even collaborate > > with the scons team if they like the idea. > > > >> -----Original Message----- > >> From: Duncan Grisby [mailto:duncan@grisby.org] > >> Sent: Wednesday, April 09, 2003 6:53 AM > >> To: Mark Hammond > >> Cc: omniorb-list@omniorb-support.com > >> Subject: Re: [omniORB] Minor patch to windows build > >> > >> On Wednesday 9 April, "Mark Hammond" wrote: > >> > >>> I have made a simple patch to the build system, so that omniidl will > >> compile > >>> on windows from a Python source tree (rather than just a binary > >> installed > >>> version). > >> > >> Thanks for that. I've checked it in to CVS. > >> > >> [...] > >>> Would patches that removed some hacks via cygpath and/or autoconf be > >>> welcomed, even if they were "one-step-at-a-time" type patches? I > > guess > >> it > >>> would mean updating your "minimal cygwin". A potential future win > > is > >> that > >>> it would open the door to using the via the cygwin Python builds. > >> > >> I'm not sure whether it's worth the bother. The whole build system is > >> a terrible mess, built out of a combination of several earlier > >> systems, with all sorts of hacks to work around problems and platform > >> differences. I think tweaking it even more, especially if it means > >> having to change the current minimal cygwin thing, is only really > >> compounding the problem. > >> > >> I think that by far the best thing to do is to throw out the whole > >> build system and replace it with something simpler and cleaner. I was > >> intending to do that for omniORB 4.0, but it never happened. I really > >> do want it to happen for 4.1. > >> > >>> Oh - and finally, it seems the devel branch is currently fails on > >> Windows > >>> (well, 12 hours ago anyway!) :) That isn't a problem for me though, > > I'm > >> on > >>> 4.0.1. > >> > >> That was due to a silly bug in reusing a variable name in a for loop. > >> It's fixed now. > >> > >> Cheers, > >> > >> Duncan. > >> > >> -- > >> -- Duncan Grisby -- > >> -- duncan@grisby.org -- > >> -- http://www.grisby.org -- > >> _______________________________________________ > >> omniORB-list mailing list > >> omniORB-list@omniorb-support.com > >> http://www.omniorb-support.com/mailman/listinfo/omniorb-list > > _______________________________________________ > > omniORB-list mailing list > > omniORB-list@omniorb-support.com > > http://www.omniorb-support.com/mailman/listinfo/omniorb-list > > > > > ----- > Zed A. Shaw > http://www.zedshaw.com/ From kwooten@itracs.com Wed Apr 9 21:49:26 2003 Received: from elcorreo2.vegas.itracs.com ([63.114.153.104]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h39KnP126653 for ; Wed, 9 Apr 2003 21:49:25 +0100 Date: Wed, 9 Apr 2003 13:49:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <0D2BEB28DE931148A970F8A8F9FCA64A06F075@elcorreo2.vegas.itracs.com> X-MS-Has-Attach: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: [omniORB] Minor patch to windows build Thread-Index: AcL+1uVz503dAkYtS4KvebqMBdexVgAAEZpA From: "Kevin Wooten" To: "Zed A. Shaw" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by raq2100.uk2net.com id h39KnP126653 Subject: [omniORB-dev] RE: [omniORB] Minor patch to windows build Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: Copy the list in your replies (or reply-all), that way we can get everyone's insight... > Oh, I missed that. You already have some SCons builds which work in > windows. Could you possibly send them to me so I can see what you have > so far? > > As for the autoconf stuff, I've found that you rarely need to generate > a config.h if you use SCons in a particular way. I've have my builds > setup so they are very clean and easy to port to new systems (I can get > a new system up in about 10 minutes). What I do is I have a single > SConstruct file which defines the targets, but which delegates to a > platform specific SConscript file (like, netbsd1.SConscript, etc.) to > setup things like weird tools locations, library and include points, > and any defines which are needed. > First off, it does sound nice and clean, but... The problem with this is the idea of platform/compiler combos. If you look at omni's current configure.ac, it has macros to test obscure parts of the compiler, header locations, type sizes, etc. This allows a developer to set CC='some nonstandard compiler' and the configure script figures out everything about that compiler and goes on with the build. I personally like this feature a lot. To do the same with your proposed method I would need a win32.Sconscript, but also a vc6.Sconscript, vc7.Sconscript and mingw.Sconscript. To support the compilers I use on that platform. This doesn't sound too bad until you look at all the unices, and all there compilers and all those compiler's versions. On the other hand, I believe all the logic necessary to build the files I speak of is laid out in the "old" build system of make files; therefore we would just have to convert logic. I would like to try using/copying the autoconf method, and if/when that fails/too_much_work, I think this method is a great second choice. > You should try grabbing: > > :pserver:anonymous@cvs.obversive.sourceforge.net:/cvsroot/obversive > > With CVS and take a look at the build I have there to see how it works. > > Now, my next step was to have a very simple template setup which would > be run from the platform specific SConscript file, and that would > generate the config.h based on the setting there. Let's say I have > this layout: > > SConstruct > src/ > config/ > win32.SConscript > config.h.tpt > > What would happen then is, the SConstruct would run, it would then run > the win32.SConscript to configure any tool weirdness, and then the > config.h.tpt would be parsed as a python statement to create the > config.h file. > > With that, you then have everything you need and the build is super > clean. > > Sound good? > > Zed > > > On Wednesday, April 9, 2003, at 01:13 PM, Kevin Wooten wrote: > > > Yes! > > > > I have wanted to finish my omni scripts, which are very rudimentary and > > currently windows only, unfortunately a good solution for the config.h > > problem was my sticking point. > > > >> From my initial examination I came up with two solutions for this > > problem; 1) somehow drive autoconf (or its macros). > > 2) replace all the functionality with our own. > > > > If there are any clever ideas for solving this problem, let me know. > > > > -KW > > > > P.S. - I have moved this to omniorb-dev, where it belongs. > > > >> -----Original Message----- > >> From: Zed A. Shaw [mailto:zedshaw@telus.net] > >> Sent: Wednesday, April 09, 2003 12:13 PM > >> To: Kevin Wooten > >> Subject: Re: [omniORB] Minor patch to windows build > >> > >> Kevin, > >> > >> I've done this before in my projects. I have a very clean design for > >> my SCons builds and have managed to create two projects that I am able > >> to port between various types of Linux, NetBSD, and Mac OSX. I did > >> approach the SCons team before about making a config.h equiv., but > > they > >> were not too interested. If you read my previous e-mail, I may be > >> attempting an SCons build myself. Care to join forces? > >> > >> Zed > >> > >> > >> On Wednesday, April 9, 2003, at 11:04 AM, Kevin Wooten wrote: > >> > >>> Even replace autoconf?? I know you are open to the idea of using > > scons; > >>> I have built some scons scripts to build omniorb, the only problem I > >>> have is that the autoconf support macros are not easily reproducible > > in > >>> scons. What is needed is a replacement for building a configure.h > > from > >>> scons or Python. I am not sure if this is on their list, but I would > > be > >>> open to finishing it if you are interested; I could even collaborate > >>> with the scons team if they like the idea. > >>> > >>>> -----Original Message----- > >>>> From: Duncan Grisby [mailto:duncan@grisby.org] > >>>> Sent: Wednesday, April 09, 2003 6:53 AM > >>>> To: Mark Hammond > >>>> Cc: omniorb-list@omniorb-support.com > >>>> Subject: Re: [omniORB] Minor patch to windows build > >>>> > >>>> On Wednesday 9 April, "Mark Hammond" wrote: > >>>> > >>>>> I have made a simple patch to the build system, so that omniidl > > will > >>>> compile > >>>>> on windows from a Python source tree (rather than just a binary > >>>> installed > >>>>> version). > >>>> > >>>> Thanks for that. I've checked it in to CVS. > >>>> > >>>> [...] > >>>>> Would patches that removed some hacks via cygpath and/or autoconf > > be > >>>>> welcomed, even if they were "one-step-at-a-time" type patches? I > >>> guess > >>>> it > >>>>> would mean updating your "minimal cygwin". A potential future win > >>> is > >>>> that > >>>>> it would open the door to using the via the cygwin Python builds. > >>>> > >>>> I'm not sure whether it's worth the bother. The whole build system > > is > >>>> a terrible mess, built out of a combination of several earlier > >>>> systems, with all sorts of hacks to work around problems and > > platform > >>>> differences. I think tweaking it even more, especially if it means > >>>> having to change the current minimal cygwin thing, is only really > >>>> compounding the problem. > >>>> > >>>> I think that by far the best thing to do is to throw out the whole > >>>> build system and replace it with something simpler and cleaner. I > > was > >>>> intending to do that for omniORB 4.0, but it never happened. I > > really > >>>> do want it to happen for 4.1. > >>>> > >>>>> Oh - and finally, it seems the devel branch is currently fails on > >>>> Windows > >>>>> (well, 12 hours ago anyway!) :) That isn't a problem for me > > though, > >>> I'm > >>>> on > >>>>> 4.0.1. > >>>> > >>>> That was due to a silly bug in reusing a variable name in a for > > loop. > >>>> It's fixed now. > >>>> > >>>> Cheers, > >>>> > >>>> Duncan. > >>>> > >>>> -- > >>>> -- Duncan Grisby -- > >>>> -- duncan@grisby.org -- > >>>> -- http://www.grisby.org -- > >>>> _______________________________________________ > >>>> omniORB-list mailing list > >>>> omniORB-list@omniorb-support.com > >>>> http://www.omniorb-support.com/mailman/listinfo/omniorb-list > >>> _______________________________________________ > >>> omniORB-list mailing list > >>> omniORB-list@omniorb-support.com > >>> http://www.omniorb-support.com/mailman/listinfo/omniorb-list > >>> > >>> > >> ----- > >> Zed A. Shaw > >> http://www.zedshaw.com/ > > > > > ----- > Zed A. Shaw > http://www.zedshaw.com/ From duncan@grisby.org Wed Apr 9 21:53:10 2003 Received: from grisby.dyndns.org (pc2-cmbg4-5-cust210.cmbg.cable.ntl.com [81.96.73.210]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h39KrA126836 for ; Wed, 9 Apr 2003 21:53:10 +0100 Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id h39KqVm15543; Wed, 9 Apr 2003 21:52:31 +0100 Message-Id: <200304092052.h39KqVm15543@grisby.dyndns.org> X-Authentication-Warning: pc2-cmbg4-5-cust210.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: "Zed A.Shaw" cc: omniorb-dev@omniorb-support.com In-Reply-To: Message from "Zed A.Shaw" of "Wed, 09 Apr 2003 12:59:50 PDT." From: Duncan Grisby Date: Wed, 09 Apr 2003 21:52:31 +0100 Subject: [omniORB-dev] SCons, was re: I Want to Port OmniORB to NetBSD Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: On Wednesday 9 April, "Zed A.Shaw" wrote: > The question is though, do you want a scortched earth policy where I > completely abandon the old build system when I make the new one? If I > can abandon the old one, then everything will be nice and clean, but > you might lose some people on some platforms temporarily. If you keep > the old one, then you can provide a nicer migration path for those who > can't do the SCons build. Unless there is an extremely good reason, I would like to keep the current source directory structure. It's too much pain to move things around in CVS otherwise. Given that, I think it should be reasonable to keep the current build systems in parallel with a SCons setup, until SCons is working for (almost) everyone. Most of the current ugliness in the make setup is due to trying to encode all the platform differences for making shared libraries, Python extensions and so on within the make files. Make really isn't appropriate for that, so we end up doing all sorts of unpleasant things to coerce it. For the next major release, if we don't get rid of make altogether, I intend to replace as much of that stuff as possible with platform specific Python scripts, so the makefiles are much cleaner. To answer Kevin's question about replacing autoconf, I think the two issues are reasonably orthogonal, so there is no absolute necessity to get rid of autoconf if we get rid of make. However, I would love to be able to get rid of autoconf. You only have to look at the M4 macros I wrote in acinclude.m4 to understand why I'm keen to have a replacement. Autoconf has an awful lot of embedded knowledge about strange systems, though, so it might be very hard work to replicate it. That's especially true given that I don't think there is any documentation about what that knowledge is, aside from the autoconf source itself. And that's written in M4 and brain-dead bourne shell... As for integrating these changes in the omniORB distribution, the 4.0 branch is closed to everything except bug fixes and very minor new features, so I'm not going to mess with the build system there. There is already a 4.1 branch (omni4_1_develop in CVS), which is the place to experiment with new build systems. Right now, the new branch is almost identical to the 4.0 branch (minus a few bug fixes that I haven't bothered to merge yet). I'm working on preliminary infrastructure for objects by value support, which I'll check in there quite soon. Thanks to both of you (Zed and Kevin) for your interest in helping with these issues. Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From duncan@grisby.org Wed Apr 9 21:57:23 2003 Received: from grisby.dyndns.org (pc2-cmbg4-5-cust210.cmbg.cable.ntl.com [81.96.73.210]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h39KvN127057 for ; Wed, 9 Apr 2003 21:57:23 +0100 Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id h39Kuhu15589; Wed, 9 Apr 2003 21:56:43 +0100 Message-Id: <200304092056.h39Kuhu15589@grisby.dyndns.org> X-Authentication-Warning: pc2-cmbg4-5-cust210.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: "Kevin Wooten" cc: "Zed A. Shaw" , omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] RE: [omniORB] Minor patch to windows build In-Reply-To: Message from "Kevin Wooten" of "Wed, 09 Apr 2003 13:49:23 PDT." <0D2BEB28DE931148A970F8A8F9FCA64A06F075@elcorreo2.vegas.itracs.com> From: Duncan Grisby Date: Wed, 09 Apr 2003 21:56:43 +0100 Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: On Wednesday 9 April, "Kevin Wooten" wrote: [...] > I would like to try using/copying the autoconf method, and if/when that > fails/too_much_work, I think this method is a great second choice. The autoconf way of detecting platform and compiler features is definitely much much better than the old way of having platform files for a million and one platforms. I don't want to go back to that. Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From kwooten@itracs.com Wed Apr 9 22:05:23 2003 Received: from elcorreo2.vegas.itracs.com ([63.114.153.104]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h39L5N127468 for ; Wed, 9 Apr 2003 22:05:23 +0100 Subject: RE: [omniORB-dev] SCons, was re: I Want to Port OmniORB to NetBSD MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 9 Apr 2003 14:05:20 -0700 Message-ID: <0D2BEB28DE931148A970F8A8F9FCA64A06F076@elcorreo2.vegas.itracs.com> content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [omniORB-dev] SCons, was re: I Want to Port OmniORB to NetBSD Thread-Index: AcL+2jN2c5IVw3g4RQG0hDPAfhaAQAAAFTGQ From: "Kevin Wooten" To: "Duncan Grisby" Cc: "Zed A. Shaw" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by raq2100.uk2net.com id h39L5N127468 Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: [...] > > Unless there is an extremely good reason, I would like to keep the > current source directory structure. It's too much pain to move things > around in CVS otherwise. Given that, I think it should be reasonable > to keep the current build systems in parallel with a SCons setup, > until SCons is working for (almost) everyone. Agreed, I just got the structure memorized ;) > > Most of the current ugliness in the make setup is due to trying to > encode all the platform differences for making shared libraries, > Python extensions and so on within the make files. Make really isn't > appropriate for that, so we end up doing all sorts of unpleasant > things to coerce it. For the next major release, if we don't get rid > of make altogether, I intend to replace as much of that stuff as > possible with platform specific Python scripts, so the makefiles are > much cleaner. > > To answer Kevin's question about replacing autoconf, I think the two > issues are reasonably orthogonal, so there is no absolute necessity to > get rid of autoconf if we get rid of make. However, I would love to be > able to get rid of autoconf. You only have to look at the M4 macros I > wrote in acinclude.m4 to understand why I'm keen to have a > replacement. Autoconf has an awful lot of embedded knowledge about > strange systems, though, so it might be very hard work to replicate > it. That's especially true given that I don't think there is any > documentation about what that knowledge is, aside from the autoconf > source itself. And that's written in M4 and brain-dead bourne shell... > Forgive my lack of knowledge on autoconf, but I thought autoconf was reasonably tied to automake; I guess this proves it's high time I had more than just off handed knowledge of it. > As for integrating these changes in the omniORB distribution, the 4.0 > branch is closed to everything except bug fixes and very minor new > features, so I'm not going to mess with the build system there. There > is already a 4.1 branch (omni4_1_develop in CVS), which is the place > to experiment with new build systems. Right now, the new branch is > almost identical to the 4.0 branch (minus a few bug fixes that I > haven't bothered to merge yet). I'm working on preliminary > infrastructure for objects by value support, which I'll check in there > quite soon. Awesome, patiently waiting... Kevin From duncan@grisby.org Wed Apr 9 22:36:16 2003 Received: from grisby.dyndns.org (pc2-cmbg4-5-cust210.cmbg.cable.ntl.com [81.96.73.210]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h39LaG128966 for ; Wed, 9 Apr 2003 22:36:16 +0100 Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id h39LZaV15872; Wed, 9 Apr 2003 22:35:36 +0100 Message-Id: <200304092135.h39LZaV15872@grisby.dyndns.org> X-Authentication-Warning: pc2-cmbg4-5-cust210.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: "Kevin Wooten" cc: "Zed A. Shaw" , omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] SCons, was re: I Want to Port OmniORB to NetBSD In-Reply-To: Message from "Kevin Wooten" of "Wed, 09 Apr 2003 14:05:20 PDT." <0D2BEB28DE931148A970F8A8F9FCA64A06F076@elcorreo2.vegas.itracs.com> From: Duncan Grisby Date: Wed, 09 Apr 2003 22:35:35 +0100 Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: On Wednesday 9 April, "Kevin Wooten" wrote: > Forgive my lack of knowledge on autoconf, but I thought autoconf was > reasonably tied to automake; I guess this proves it's high time I had > more than just off handed knowledge of it. automake depends on autoconf, but not vice-versa. omniORB doesn't use automake. I looked into it when I did the autoconf support, but automake doesn't cope with things like building tools early in the build and using them later. We need to do that for omniidl. The other part of the autotools suite is libtool which is meant to make building libraries easy. It's a gigantic hairy shell script, and it doesn't cope at all well with C++. If you value your sanity, I wouldn't bother looking too hard at the autotools... Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From Harri.Pasanen@trema.com Thu Apr 10 08:24:49 2003 Received: from mark.labs.trema.com (mark.labs.trema.com [194.103.215.2]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h3A7Om124882 for ; Thu, 10 Apr 2003 08:24:48 +0100 Received: from labsex1.corp.trema.com (mail-3.trema.com [194.103.215.195]) by mark.labs.trema.com (8.9.3/8.9.3) with ESMTP id JAA16590; Thu, 10 Apr 2003 09:24:45 +0200 (MET DST) Received: from dell-harri.corp.trema.com ([172.24.16.159]) by labsex1.corp.trema.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 10 Apr 2003 09:23:49 +0200 From: Harri Pasanen Reply-To: harri@labs.trema.com To: "Kevin Wooten" , "Zed A. Shaw" Subject: Re: [omniORB-dev] RE: [omniORB] Minor patch to windows build Date: Thu, 10 Apr 2003 09:24:44 +0200 User-Agent: KMail/1.5 Cc: References: <0D2BEB28DE931148A970F8A8F9FCA64A06F075@elcorreo2.vegas.itracs.com> In-Reply-To: <0D2BEB28DE931148A970F8A8F9FCA64A06F075@elcorreo2.vegas.itracs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200304100924.44605.harri.pasanen@trema.com> X-OriginalArrivalTime: 10 Apr 2003 07:23:49.0328 (UTC) FILETIME=[21617D00:01C2FF32] Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: On Wednesday 09 April 2003 22:49, Kevin Wooten wrote: > The problem with this is the idea of platform/compiler combos. If > you look at omni's current configure.ac, it has macros to test > obscure parts of the compiler, header locations, type sizes, etc. > This allows a developer to set CC='some nonstandard compiler' and > the configure script figures out everything about that compiler and > goes on with the build. I personally like this feature a lot. > I'd say that using autoconf with scons is probably the way to go. I'm also on the scons mailing list, mainly lurking, and I know there are some talks about making autoconf replacement, but that is no where near prime time yet. Having 'ported' OmniORB to KCC/HP-UX, and Itanium/GCC, I can say that autoconf in practise works quite well, and is a timesaver. The complexity of OmniORB build is however non-trivial, so don't underestimate the effort to do a proper job, it will be hours, not minutes. One of the reasons that has kept me putting me off scons is that none of the third party software we integrate to builds support it, OmniORB would be the first. I'm all for OmniORB scons support - one of the main advantages would be the same system for Win32, and parallel build with -j, so Dist CC could be used on Unix platforms. Note also, that scons has its learning curve and if you are fluent with Makefiles, it does not necessary help much. Anyway, I can probably volunteer some time into testing on Linux, HP-UX (PA-RISC, Itanium), Win32. Harri From ajw@it-innovation.soton.ac.uk Wed Apr 23 10:41:15 2003 Received: from mailserver.it-innovation.soton.ac.uk (hidden-user@mailhost.it-innovation.soton.ac.uk [152.78.239.150]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h3N9fFh32172 for ; Wed, 23 Apr 2003 10:41:15 +0100 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 23 Apr 2003 10:41:16 +0100 Message-ID: <0016E6145796E14680B831BB76A2129E04B9FA@mailserver.it-innovation.soton.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reloading DLLs thread-index: AcMJfHyMcBG6n5jvTlCeihmJXtqYwQ== From: "Andrew Wilde" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by raq2100.uk2net.com id h3N9fFh32172 Subject: [omniORB-dev] Reloading DLLs Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: Hi, We have observed seems problem reloading DLLs when using Omniorb4.0.0. To boil the problem down I wrote some test code based on the echo example that comes with OmniORB. Basically, the test code loads and unloads a DLL twice . The DLL implements the echo object so is linked with the echo stub object file (echoSK.obj). The test works fine until I also link the test code against the echo stub. When I run the example I get the following error message at the point it attempts to load the DLL for the second time: 998 - Invalid access to memory location (ERROR_NOACCESS) The problem seems related to the loading of the static OmniORB libraries and happens with both release and debug versions. We are not sure if this is a specific problem with OmniORB or is some more generic windows problem, so if anyone can shed some light on this we would greatly appreciate it. Thanks, ------------------------- Andrew Wilde IT Innovation Centre 2 Venture Road Chilworth Science Park Southampton, SO16 7NP, UK From xavier.outhier@anfdata.cz Fri Apr 25 09:50:07 2003 Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h3P8o7h06350 for ; Fri, 25 Apr 2003 09:50:07 +0100 Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id h3P8o2dp017328 for ; Fri, 25 Apr 2003 10:50:02 +0200 Received: from smtp.prgpu.anfdata.cz (atws15tc.sie.siemens.at [158.226.135.41]) by scesie13.sie.siemens.at (8.12.9/8.12.1) with ESMTP id h3P8o0Zv012146 for ; Fri, 25 Apr 2003 10:50:01 +0200 (MET DST) Received: from anfdata.cz (pcp1034.prgpu.anfdata.cz [163.242.71.34]) by smtp.prgpu.anfdata.cz (Postfix) with ESMTP id 7F9A92689A for ; Fri, 25 Apr 2003 10:50:00 +0200 (CEST) Message-ID: <3EA8F854.5070F2EC@anfdata.cz> Date: Fri, 25 Apr 2003 10:56:52 +0200 From: Xavier Outhier X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: omniORB Dev Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [omniORB-dev] [WinCE port] clwrapper.exe ... compiling problem Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: Hi all, I'm trying to make a port to WinCE. I'm using the command line to recompile the sources. I test compilation for NT with VC++ 6.0: fine. Now, I want to use EVC 3.0 for WinCE3.0 for target MIPS -1 I first deleted the environamt variables for VC++ -2 I test to recompile and of course it doesn't no cl.exe found. So far so good -3 I run the WCEMIPS.BAT from EVC to have a new path to my new cl.exe, link.exe, lib.exe and so on -4 I added a line in config\config.mk. This one platform = mips_pocketpc_wince300 Commented out the previous #platform = x86_nt_4.0 -5 I've created a new file in \mk\platforms\mips_pocketpc_wince300.mk I took x86_nt_4.0.mk as a template here is the diff between the 2 files: 2c2 < # x86_nt_4.0.mk - make variables and rules specific to Windows NT 4.0. --- > # mips_pocketpc_wce3.0.mk - make variables and rules specific to Pocket PC for MIPS. 5,11c5,11 < WindowsNT = 1 < x86Processor = 1 < < WINVER = 0x0400 < < BINDIR = bin/x86_win32 < LIBDIR = lib/x86_win32 --- > #WindowsNT = 1 > #x86Processor = 1 > > # WINVER = 0x0400 > > BINDIR = bin/mips_pocketpc > LIBDIR = lib/mips_pocketpc 36c36 < IMPORT_CPPFLAGS += -D__x86__ -D__NT__ -D__OSVERSION__=4 --- > IMPORT_CPPFLAGS += -D__mips__ -D__POCKETPC__ -D__OSVERSION__=WCE300 40c40 < OMNINAMES_LOG_DEFAULT_LOCATION = C:\\temp --- > OMNINAMES_LOG_DEFAULT_LOCATION = D:\\OMNINAMES -6 in \src, I run make export and I got this: D:\omniORB-4.0.1\src>make export making export in src/tool... make[1]: Entering directory `/cygdrive/d/omniORB-4.0.1/src/tool' making export in src/tool/omniidl... make[2]: Entering directory `/cygdrive/d/omniORB-4.0.1/src/tool/omniidl' making export in src/tool/omniidl/cxx... make[3]: Entering directory `/cygdrive/d/omniORB-4.0.1/src/tool/omniidl/cxx' making export in src/tool/omniidl/cxx/cccp... make[4]: Entering directory `/cygdrive/d/omniORB-4.0.1/src/tool/omniidl/cxx/cccp' ../../../../../bin/mips_pocketpc/clwrapper -gnuwin32 -c -O2 -MD -DHAVE_CONFIG_H -I. -I. -I. -I../../../../../include -D_ _WIN32__ -D_WIN32_WINNT=0x0400 -D__mips__ -D__POCKETPC__ -D__OSVERSION__=WCE300 -Focexp.o cexp.c make[4]: ../../../../../bin/mips_pocketpc/clwrapper: Command not found make[4]: *** [cexp.o] Error 127 make[4]: Leaving directory `/cygdrive/d/omniORB-4.0.1/src/tool/omniidl/cxx/cccp' make[3]: *** [export] Error 2 make[3]: Leaving directory `/cygdrive/d/omniORB-4.0.1/src/tool/omniidl/cxx' make[2]: *** [export] Error 2 make[2]: Leaving directory `/cygdrive/d/omniORB-4.0.1/src/tool/omniidl' make[1]: *** [export] Error 2 make[1]: Leaving directory `/cygdrive/d/omniORB-4.0.1/src/tool' make: *** [export] Error 2 -7 I copied clwrapper.exe, libwrapper.exe, linkwrapper.exe, oidlwrapper.exe and omkdepend.exe from \bin\x86_win32 to \bin\mips_pocketpc (I don't think it's a genious idea but... see point 8) I retyped make export and got the first mistake from the code D:\omniORB-4.0.1\src>make export making export in src/tool... make[1]: Entering directory `/cygdrive/d/omniORB-4.0.1/src/tool' making export in src/tool/omniidl... make[2]: Entering directory `/cygdrive/d/omniORB-4.0.1/src/tool/omniidl' making export in src/tool/omniidl/cxx... make[3]: Entering directory `/cygdrive/d/omniORB-4.0.1/src/tool/omniidl/cxx' making export in src/tool/omniidl/cxx/cccp... make[4]: Entering directory `/cygdrive/d/omniORB-4.0.1/src/tool/omniidl/cxx/cccp' ../../../../../bin/mips_pocketpc/clwrapper -gnuwin32 -c -O2 -MD -DHAVE_CONFIG_H -I. -I. -I. -I../../../../../include -D_ _WIN32__ -D_WIN32_WINNT=0x0400 -D__mips__ -D__POCKETPC__ -D__OSVERSION__=WCE300 -Focexp.o cexp.c cl -c -O2 -MD -DHAVE_CONFIG_H -I. -I. -I. -I..\..\..\..\..\include -D__WIN32__ -D_WIN32_WINNT=0x0400 -D__mips__ -D__POCK ETPC__ -D__OSVERSION__=WCE300 -Focexp.o cexp.c Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for 80x86 Copyright (C) Microsoft Corp 1984-1998. All rights reserved. cexp.c config-windows.h(1) : fatal error C1083: Cannot open include file: 'io.h': No such file or directory make[4]: *** [cexp.o] Error 2 make[4]: Leaving directory `/cygdrive/d/omniORB-4.0.1/src/tool/omniidl/cxx/cccp' make[3]: *** [export] Error 2 make[3]: Leaving directory `/cygdrive/d/omniORB-4.0.1/src/tool/omniidl/cxx' make[2]: *** [export] Error 2 make[2]: Leaving directory `/cygdrive/d/omniORB-4.0.1/src/tool/omniidl' make[1]: *** [export] Error 2 make[1]: Leaving directory `/cygdrive/d/omniORB-4.0.1/src/tool' make: *** [export] Error 2 -8 I tried to recompile clwrapper.exe, libwrapper.exe, linkwrapper.exe, oidlwrapper.exe. In \src\tool\win32 I tried to make export and make all and I got these errors: D:\omniORB-4.0.1\src>cd D:\omniORB-4.0.1\src\tool\win32 D:\omniORB-4.0.1\src\tool\win32>make export make: *** No rule to make target `export'. Stop. D:\omniORB-4.0.1\src\tool\win32>make all make: *** No rule to make target `all'. Stop. -9 I tried to compile from \src\tool\. I replaced in the dir.mk ifdef Win32Platform SUBDIRS = win32 endif with ifdef Win32Platform SUBDIRS = win32 endif in order to copimle only the win32 directory. I got this message: D:\omniORB-4.0.1\src\tool>make export making export in src/tool/win32... make[1]: Entering directory `/cygdrive/d/omniORB-4.0.1/src/tool/win32' make[1]: *** No rule to make target `export'. Stop. make[1]: Leaving directory `/cygdrive/d/omniORB-4.0.1/src/tool/win32' make: *** [export] Error 2 So my questions: -Q1: I suppose that to port on winCE, I have to recompile first clwrapper.exe, libwrapper.exe, linkwrapper.exe, oidlwrapper.exe. Right or wrong? -Q2: What's wrong with the makefile? I tried adding tabulations but was not efficient. :( -Q3: Does someone already made such a port? That's an interested question, isn't it? :-) Sorry it was long but I hope I gave all waht was necessary to understand completly my problem. Best Regards, Xavier. From xavier.outhier@anfdata.cz Mon Apr 28 15:37:22 2003 Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h3SEbLh05706 for ; Mon, 28 Apr 2003 15:37:21 +0100 Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id h3SEbNdp010310 for ; Mon, 28 Apr 2003 16:37:23 +0200 Received: from smtp.prgpu.anfdata.cz (atws15tc.sie.siemens.at [158.226.135.41]) by scesie13.sie.siemens.at (8.12.9/8.12.1) with ESMTP id h3SEbMZv029792 for ; Mon, 28 Apr 2003 16:37:23 +0200 (MET DST) Received: from anfdata.cz (pcp1034.prgpu.anfdata.cz [163.242.71.34]) by smtp.prgpu.anfdata.cz (Postfix) with ESMTP id 7658926880 for ; Mon, 28 Apr 2003 16:37:22 +0200 (CEST) Message-ID: <3EAD3E40.92D164BB@anfdata.cz> Date: Mon, 28 Apr 2003 16:44:16 +0200 From: Xavier Outhier X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: omniORB Dev Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [omniORB-dev] [WinCE port] compile error #001, #002, #003, #004 in nt.cc Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: Hi all, Let's start it for real. - Error #001 The first error I got was in omniORB-4.0.1/src/lib/omnithread/nt.cc D:\Windows CE Tools\WCE300\ms pocket pc\include\stdlib.h(928) : error C2065: '_JBLEN' After looking in the stdlib.h I found out that this was due because a compile variable was not set. So in D:\omniORB-4.0.1\mk\platforms\mips_pocketpc_wince300.mk I replaced IMPORT_CPPFLAGS += -D__MIPS__ -D__POCKETPC__ -D__OSVERSION__=WCE300 with IMPORT_CPPFLAGS += -DMIPS -D__MIPS__ -D__POCKETPC__ -D__OSVERSION__=WCE300 Seems effective so far. - Error #002 nt.cc(36) : fatal error C1083: Cannot open include file: 'errno.h': No such file or directory I comment out the include and this fix it. Seems that nothing was used from the include. - Error #003 D:\Windows CE Tools\WCE300\ms pocket pc\include\winnt.h(3153) : error C2146: syntax error : missing ';' before identifie r 'ContextRecord' D:\Windows CE Tools\WCE300\ms pocket pc\include\winnt.h(3153) : error C2501: 'PCONTEXT' : missing storage-class or type specifiers Again a problem with a macro to define: this time it was _ALPHA_ so So in D:\omniORB-4.0.1\mk\platforms\mips_pocketpc_wince300.mk I replaced IMPORT_CPPFLAGS += -DMIPS -D__MIPS__ -D__POCKETPC__ -D__OSVERSION__=WCE300 with IMPORT_CPPFLAGS += -D_MIPS_ -DMIPS -D__MIPS__ -D__POCKETPC__ -D__OSVERSION__=WCE300 Seems effective so far. - Error #004 nt.cc(38) : fatal error C1083: Cannot open include file: 'process.h': No such file or directory This time suppressing is not effective as some functions are really used: nt.cc(437) : error C2065: 'DuplicateHandle' : undeclared identifier nt.cc(621) : error C2065: '_beginthreadex' : undeclared identifier nt.cc(789) : error C2065: '_endthreadex' : undeclared identifier a) Adding include of #include where is declared DuplicateHandle do not help; still something missing :( There are a lot of error but the first (the most important I think) is D:\Windows CE Tools\WCE300\ms pocket pc\include\secpkg.h(71) : error C2059: syntax error : '__stdcall' b) Regarding _begin/endthreadex It's interesting to note this D:\Windows CE Tools\WCE300\ms pocket pc\mfc\src\thrdcore.cpp(13):#include // for _beginthreadex and _endthreadex while there is no process.h available. and this D:\Windows CE Tools\WCE300\ms pocket pc\mfc\src\wceimpl.h(316):unsigned long AFXAPI wce__beginthreadex(void *security, unsigned stack_size, Is it safe to use this version which has the same signature as the original knowing that there is this warning in the header file // THIS FILE IS FOR MFCCE IMPLEMENTATION ONLY? Replacing leads to this: D:\Windows CE Tools\WCE300\ms pocket pc\mfc\src\wceimpl.h(94) : warning C4005: '_ttoi' : macro redefinition D:\Windows CE Tools\WCE300\ms pocket pc\include\tchar.h(190) : see previous definition of '_ttoi' D:\Windows CE Tools\WCE300\ms pocket pc\mfc\src\wceimpl.h(95) : warning C4005: '_itot' : macro redefinition D:\Windows CE Tools\WCE300\ms pocket pc\include\tchar.h(187) : see previous definition of '_itot' [...] I have no more idea for today. Is there a better way to proceed than this pedestrian one? Is this file to be ported or is it something that can be skip. I think it should be kept but I'm not sure. Best regards, Xavier. From duncan@grisby.org Tue Apr 29 12:21:01 2003 Received: from grisby.dyndns.org (pc2-cmbg4-5-cust210.cmbg.cable.ntl.com [81.96.73.210]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h3TBL1h00868 for ; Tue, 29 Apr 2003 12:21:01 +0100 Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id h3TBKKN07575; Tue, 29 Apr 2003 12:20:20 +0100 Message-Id: <200304291120.h3TBKKN07575@grisby.dyndns.org> X-Authentication-Warning: pc2-cmbg4-5-cust210.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: "Andrew Wilde" cc: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] Reloading DLLs In-Reply-To: Message from "Andrew Wilde" of "Wed, 23 Apr 2003 10:41:16 BST." <0016E6145796E14680B831BB76A2129E04B9FA@mailserver.it-innovation.soton.ac.uk> From: Duncan Grisby Date: Tue, 29 Apr 2003 12:20:20 +0100 Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: On Wednesday 23 April, "Andrew Wilde" wrote: > We have observed seems problem reloading DLLs when using > Omniorb4.0.0. To boil the problem down I wrote some test code based > on the echo example that comes with OmniORB. > > Basically, the test code loads and unloads a DLL twice . The DLL > implements the echo object so is linked with the echo stub object > file (echoSK.obj). The test works fine until I also link the test > code against the echo stub. When I run the example I get the > following error message at the point it attempts to load the DLL for > the second time: Stubs cannot be safely unloaded in omniORB versions prior to 4.0.1. Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From xavier.outhier@anfdata.cz Tue Apr 29 14:42:47 2003 Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h3TDglh07725 for ; Tue, 29 Apr 2003 14:42:47 +0100 Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id h3TDgkdp004836 for ; Tue, 29 Apr 2003 15:42:46 +0200 Received: from smtp.prgpu.anfdata.cz (atws15tc.sie.siemens.at [158.226.135.41]) by scesie13.sie.siemens.at (8.12.9/8.12.1) with ESMTP id h3TDgEZv026116 for ; Tue, 29 Apr 2003 15:42:25 +0200 (MET DST) Received: from anfdata.cz (pcp1034.prgpu.anfdata.cz [163.242.71.34]) by smtp.prgpu.anfdata.cz (Postfix) with ESMTP id 4E1C3268A2 for ; Tue, 29 Apr 2003 15:42:14 +0200 (CEST) Message-ID: <3EAE82D6.2C5B2B19@anfdata.cz> Date: Tue, 29 Apr 2003 15:49:10 +0200 From: Xavier Outhier X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: omniORB Dev Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [omniORB-dev] [WinCE Port] First Linking problems :) Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: Hi all, After trying to get native win32 thread version running, I switch for pthread_nt configuration as the native leads to too complicated errors for me. In /mk/win32.mk I commented out # Use native win32 threads ThreadSystem = NT and uncommeted out # Use pthread_nt, comment out ThreadSystem line above and uncomment the # following 2 lines. #ThreadSystem = NTPosix #OMNITHREAD_CPPFLAGS= -D__POSIX_NT__ So instead of compiling omniORB-4.0.1/src/lib/omnithread/nt.cc I compile omniORB-4.0.1/src/lib/omnithread/posix.cc. I was able to fix all the compile error/change but I got a link error: D:\omniORB-4.0.1\src>make export making export in src/lib... make[1]: Entering directory `/cygdrive/d/omniORB-4.0.1/src/lib' making export in src/lib/omnithread... make[2]: Entering directory `/cygdrive/d/omniORB-4.0.1/src/lib/omnithread' + rm -f static/omnithread.lib + ../../../bin/mips_pocketpc/libwrapper -gnuwin32 static/omnithread.lib static/posix.o lib /OUT:static\omnithread.lib static\posix.o Microsoft (R) Library Manager Version 6.20.8700 Copyright (C) Microsoft Corp 1992-2000. All rights reserved. + rm -f shared/omnithread30_rt.lib + ../../../bin/mips_pocketpc/linkwrapper -gnuwin32 -out:shared/omnithread30_rt.dll -DLL -IMPLIB:shared/omnithread30_rt.l ib -libpath:../../../lib/mips_pocketpc shared/posix.o link -out:shared\omnithread30_rt.dll -DLL -IMPLIB:shared/omnithread30_rt.lib -libpath:..\..\..\lib\mips_pocketpc shared\ posix.o Microsoft (R) Incremental Linker Version 6.20.8700 Copyright (C) Microsoft Corp 1992-2000. All rights reserved. Creating library shared/omnithread30_rt.lib and object shared/omnithread30_rt.exp posix.o : error LNK2019: unresolved external symbol _pthread_mutex_lock referenced in function "public: void __thiscall omni_mutex::lock(void)" (?lock@omni_mutex@@QAEXXZ) and so on with all the pthread functions. Which library should I link with? Where to do such change? Is it possible to use pthreads for winCE (http://public.planetmirror.com/pub/sourceware/pthreads-win32/dll-latest) ? What should I change in the sources or in makefile? Can I only link to the lib? Where do I add this information to link to the lib file? Best regards, Xavier. From xavier.outhier@anfdata.cz Wed Apr 30 13:22:44 2003 Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h3UCMih08309 for ; Wed, 30 Apr 2003 13:22:44 +0100 Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id h3UCMgdp026401 for ; Wed, 30 Apr 2003 14:22:42 +0200 Received: from smtp.prgpu.anfdata.cz (atws15tc.sie.siemens.at [158.226.135.41]) by scesie13.sie.siemens.at (8.12.9/8.12.1) with ESMTP id h3UCMeZv016261 for ; Wed, 30 Apr 2003 14:22:41 +0200 (MET DST) Received: from anfdata.cz (pcp1034.prgpu.anfdata.cz [163.242.71.34]) by smtp.prgpu.anfdata.cz (Postfix) with ESMTP id 851E926899 for ; Wed, 30 Apr 2003 14:22:40 +0200 (CEST) Message-ID: <3EAFC1B0.67987840@anfdata.cz> Date: Wed, 30 Apr 2003 14:29:36 +0200 From: Xavier Outhier X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: omniORB Dev Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [omniORB-dev] [WinCE Port] System environment modification from mk file? Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: Hi all, How can I chnage an environment variable from within a mk file? I know how to retrieve the value $$THE_ENVIRONMENT_VARIABLE but how can I change it in particular append it. Regards, Xavier. From tot@trema.com Fri May 2 20:45:49 2003 Received: from lou-bada.torma.org (postfix@lou-bada.torma.org [62.212.112.238]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h42Jjmh09625 for ; Fri, 2 May 2003 20:45:48 +0100 Received: from lara.lou-bada.torma.org (lara.lou-bada.torma.org [10.7.3.65]) by lou-bada.torma.org (Postfix) with ESMTP id 012061A689 for ; Fri, 2 May 2003 21:45:50 +0200 (CEST) From: Teemu Torma To: omniorb-dev@omniorb-support.com Date: Fri, 2 May 2003 21:45:51 +0200 User-Agent: KMail/1.5 Organization: Trema Group MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_vrss+iTbG6pSfuI" Message-Id: <200305022145.51842.tot@trema.com> Subject: [omniORB-dev] Patch: omniORB 4 std headers and namespace fixes Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: --Boundary-00=_vrss+iTbG6pSfuI Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Disposition: inline If anyone is interested, please see the attached patch to conditionally use standard headers and namespace. This avoids deprecated include warnings with gcc 3.2 and allows the system to be compiled with Visual Studio .Net (or whatever the name officially is, probably starts with Microsoft and ends with an ®). The changes depend on HAVE_STD defined, which is currently set by configure script if standard headers and std namespace exists. Teemu --Boundary-00=_vrss+iTbG6pSfuI Content-Type: text/x-diff; charset="us-ascii"; name="omniorb4-std.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="omniorb4-std.patch" Index: src/appl/omniMapper/omniMapper.cc =================================================================== RCS file: /cvsroot/omniorb/omni/src/appl/omniMapper/Attic/omniMapper.cc,v retrieving revision 1.2.2.7 diff -c -u -r1.2.2.7 omniMapper.cc --- src/appl/omniMapper/omniMapper.cc 16 Jan 2002 12:35:46 -0000 1.2.2.7 +++ src/appl/omniMapper/omniMapper.cc 2 May 2003 19:34:32 -0000 @@ -59,8 +59,15 @@ #include #include #include -#include -#include + +#ifdef HAVE_STD +# include +# include + using namespace std; +#else +# include +# include +#endif static void usage() @@ -186,7 +193,11 @@ processConfigFile(const char* configFile) { #ifdef __WIN32__ +#if _MSC_VER >= 1310 + ifstream cfile(configFile, ios::in); +#else ifstream cfile(configFile, ios::in | ios::nocreate); +#endif #else ifstream cfile(configFile); #endif Index: src/appl/omniNames/NamingContext_i.cc =================================================================== RCS file: /cvsroot/omniorb/omni/src/appl/omniNames/Attic/NamingContext_i.cc,v retrieving revision 1.12.2.3 diff -c -u -r1.12.2.3 NamingContext_i.cc --- src/appl/omniNames/NamingContext_i.cc 21 Nov 2002 14:26:11 -0000 1.12.2.3 +++ src/appl/omniNames/NamingContext_i.cc 2 May 2003 19:34:32 -0000 @@ -22,12 +22,20 @@ // USA. // -#include +#include + #include #include #include #include #include + +#ifdef HAVE_STD +# include + using namespace std; +#else +# include +#endif #ifdef DEBUG_NC #define DB(x) x Index: src/appl/omniNames/log.cc =================================================================== RCS file: /cvsroot/omniorb/omni/src/appl/omniNames/Attic/log.cc,v retrieving revision 1.22.2.8 diff -c -u -r1.22.2.8 log.cc --- src/appl/omniNames/log.cc 16 Jan 2003 11:08:26 -0000 1.22.2.8 +++ src/appl/omniNames/log.cc 2 May 2003 19:34:32 -0000 @@ -22,13 +22,13 @@ // USA. // +#include #include #include #include #include #include #include -#include #include #if defined(__VMS) && __VMS_VER < 70000000 # include @@ -38,7 +38,15 @@ #include #include #include -#include + +#ifdef HAVE_STD +# include +# include + using namespace std; +#else +# include +# include +#endif #ifdef __WIN32__ # include @@ -61,15 +69,12 @@ # endif #endif -#if defined(__SUNPRO_CC) && __SUNPRO_CC >= 0x500 -# define USE_STREAM_OPEN -# define OPEN(name,mode,perm) open(name,mode,perm) -#elif defined(__KCC) +#ifdef HAVE_STD # define USE_STREAM_OPEN # define OPEN(name,mode,perm) open(name,mode) -#elif defined(__GNUG__) && __GNUG__ >= 3 +#elif defined(__SUNPRO_CC) && __SUNPRO_CC >= 0x500 # define USE_STREAM_OPEN -# define OPEN(name,mode,perm) open(name,mode) +# define OPEN(name,mode,perm) open(name,mode,perm) #elif defined(__DMC__) # define USE_STREAM_OPEN # define OPEN(name,mode,perm) open(name,mode,perm) @@ -298,7 +303,11 @@ firstTime = 0; #ifdef __WIN32__ +#if _MSC_VER >= 1310 + ifstream initf(active,ios::in); +#else ifstream initf(active,ios::in | ios::nocreate); +#endif #else ifstream initf(active); #endif @@ -1054,7 +1063,7 @@ void omniNameslog::putKey(const PortableServer::ObjectId& id, ostream& file) { - file << hex; + file << ios::hex; for (unsigned int i = 0; i < id.length(); i++) { #if !defined(__SUNPRO_CC) || __SUNPRO_CC < 0x500 file << setfill('0') << setw(2) << (int)id[i]; @@ -1063,7 +1072,7 @@ file << std::setfill('0') << std::setw(2) << (int)id[i]; #endif } - file << dec; + file << ios::dec; } Index: src/appl/omniNames/log.h =================================================================== RCS file: /cvsroot/omniorb/omni/src/appl/omniNames/Attic/log.h,v retrieving revision 1.7.2.1 diff -c -u -r1.7.2.1 log.h --- src/appl/omniNames/log.h 9 Oct 2000 16:20:56 -0000 1.7.2.1 +++ src/appl/omniNames/log.h 2 May 2003 19:34:32 -0000 @@ -26,7 +26,13 @@ #define _log_h_ #include -#include + +#ifdef HAVE_STD +# include + using namespace std; +#else +# include +#endif #ifndef LOGDIR_ENV_VAR #define LOGDIR_ENV_VAR "OMNINAMES_LOGDIR" Index: src/appl/omniNames/omniNames.cc =================================================================== RCS file: /cvsroot/omniorb/omni/src/appl/omniNames/Attic/omniNames.cc,v retrieving revision 1.9.2.7 diff -c -u -r1.9.2.7 omniNames.cc --- src/appl/omniNames/omniNames.cc 14 Oct 2002 15:15:45 -0000 1.9.2.7 +++ src/appl/omniNames/omniNames.cc 2 May 2003 19:34:32 -0000 @@ -28,9 +28,15 @@ #include #include #include -#include #include #include + +#ifdef HAVE_STD +# include + using namespace std; +#else +# include +#endif #ifdef __WIN32__ # include Index: src/appl/utils/catior/catior.cc =================================================================== RCS file: /cvsroot/omniorb/omni/src/appl/utils/catior/Attic/catior.cc,v retrieving revision 1.12.2.9 diff -c -u -r1.12.2.9 catior.cc --- src/appl/utils/catior/catior.cc 16 Apr 2002 12:42:54 -0000 1.12.2.9 +++ src/appl/utils/catior/catior.cc 2 May 2003 19:34:32 -0000 @@ -24,12 +24,20 @@ // // Lists contents of an IOR. -#include -#include +#include #include #include +#ifdef HAVE_STD +# include +# include + using namespace std; +#else +# include +# include +#endif + #ifdef HAVE_UNISTD_H # include #endif @@ -423,7 +431,7 @@ } else { cout << "Unrecognised profile tag: 0x" - << hex << (unsigned)(ior.profiles[count].tag) + << ios::hex << (unsigned)(ior.profiles[count].tag) << endl; } } @@ -435,7 +443,7 @@ if (ms) cerr << "(CORBA::MARSHAL: minor = " << ms << ")" << endl; else - cerr << "(CORBA::MARSHAL: minor = 0x" << hex << ex.minor() << ")" + cerr << "(CORBA::MARSHAL: minor = 0x" << ios::hex << ex.minor() << ")" << endl; return 1; } Index: src/appl/utils/convertior/convertior.cc =================================================================== RCS file: /cvsroot/omniorb/omni/src/appl/utils/convertior/Attic/convertior.cc,v retrieving revision 1.10.2.6 diff -c -u -r1.10.2.6 convertior.cc --- src/appl/utils/convertior/convertior.cc 3 Feb 2003 16:52:02 -0000 1.10.2.6 +++ src/appl/utils/convertior/convertior.cc 2 May 2003 19:34:32 -0000 @@ -24,10 +24,17 @@ // // Takes an IOR, hostname as arguments. Outputs IOR with new hostname. -#include +#include #include #include + +#ifdef HAVE_STD +# include + using namespace std; +#else +# include +#endif #ifdef HAVE_UNISTD_H # include Index: src/appl/utils/genior/genior.cc =================================================================== RCS file: /cvsroot/omniorb/omni/src/appl/utils/genior/Attic/genior.cc,v retrieving revision 1.9.2.5 diff -c -u -r1.9.2.5 genior.cc --- src/appl/utils/genior/genior.cc 15 Jan 2002 16:38:11 -0000 1.9.2.5 +++ src/appl/utils/genior/genior.cc 2 May 2003 19:34:32 -0000 @@ -26,12 +26,19 @@ // Program to generate IORs -#include +#include #include #include #include #include + +#ifdef HAVE_STD +# include + using namespace std; +#else +# include +#endif #ifdef HAVE_UNISTD_H # include Index: src/appl/utils/nameclt/nameclt.cc =================================================================== RCS file: /cvsroot/omniorb/omni/src/appl/utils/nameclt/Attic/nameclt.cc,v retrieving revision 1.19.2.3 diff -c -u -r1.19.2.3 nameclt.cc --- src/appl/utils/nameclt/nameclt.cc 29 Oct 2001 17:43:36 -0000 1.19.2.3 +++ src/appl/utils/nameclt/nameclt.cc 2 May 2003 19:34:32 -0000 @@ -22,10 +22,17 @@ // USA. // -#include +#include #include #include #include + +#ifdef HAVE_STD +# include + using namespace std; +#else +# include +#endif OMNI_USING_NAMESPACE(omni) --Boundary-00=_vrss+iTbG6pSfuI-- From lockhart@fourpalms.org Fri May 2 22:21:52 2003 Received: from myst.fourpalms.org (dhcp-78-180-241.jpl.nasa.gov [137.78.180.241]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h42LLqh14210 for ; Fri, 2 May 2003 22:21:52 +0100 Received: from fourpalms.org (localhost.localdomain [127.0.0.1]) by myst.fourpalms.org (Postfix) with ESMTP id E7CC0348E977; Fri, 2 May 2003 17:21:54 -0400 (EDT) Message-ID: <3EB2E172.8090400@fourpalms.org> Date: Fri, 02 May 2003 14:21:54 -0700 From: Thomas Lockhart Organization: Yes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Teemu Torma Cc: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] Patch: omniORB 4 std headers and namespace fixes References: <200305022145.51842.tot@trema.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: > The changes depend on HAVE_STD defined, which is currently set by > configure script if standard headers and std namespace exists. Out of curiosity, how much work would you guess it would be to leave out the "using namespace std;" lines and instead conditionally prefix calls into the std namespace? In our application code we did not have very many places which were affected when upgrading to the 3.x compiler, and we could just fix individual lines rather than exposing the entire std namespace to the code... - Tom From nimrod@avaya.com Fri May 2 22:56:37 2003 Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h42Lubh15969 for ; Fri, 2 May 2003 22:56:37 +0100 Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h42LrbY27569 for ; Fri, 2 May 2003 17:53:37 -0400 (EDT) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h42Lrbk27565 for ; Fri, 2 May 2003 17:53:37 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 2 May 2003 17:56:40 -0400 Message-ID: <6900257941B31D4A954C71DEF805B9A201FAF8EF@nj7460avexu2.global.avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OmniNames and IONA Orbix 3.3 Thread-Index: AcMQ9bX3QvC7fZj2QSS7jlCPVGjRRw== From: "Nimrod, David (Dave)" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by raq2100.uk2net.com id h42Lubh15969 Subject: [omniORB-dev] OmniNames and IONA Orbix 3.3 Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: I am migrating a product which was using Iona Orbix2.2c01 and OmniNames (OmniOrb 2.2.0) as its naming service. I migrated to Iona Orbix 3.3.4 and OmniOrb 4.0.1 Everything compiles fine, but the "resolve" method return an exception. Any idea where I can find info on migrating OmniOrb from 2.2 to 4.x and interoperabilty issues between Iona and OmniOrb? ______________________________________ David Nimrod Avaya Inc. Email: Nimrod@avaya.com ______________________________________ From tot@trema.com Sat May 3 01:37:43 2003 Received: from lou-bada.torma.org (postfix@lou-bada.torma.org [62.212.112.238]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h430bgh23708 for ; Sat, 3 May 2003 01:37:42 +0100 Received: from lara.lou-bada.torma.org (lara.lou-bada.torma.org [10.7.3.65]) by lou-bada.torma.org (Postfix) with ESMTP id AF3F418DDA; Sat, 3 May 2003 02:37:46 +0200 (CEST) From: Teemu Torma Organization: Trema Group To: Thomas Lockhart Subject: Re: [omniORB-dev] Patch: omniORB 4 std headers and namespace fixes Date: Sat, 3 May 2003 02:37:46 +0200 User-Agent: KMail/1.5 Cc: omniorb-dev@omniorb-support.com References: <200305022145.51842.tot@trema.com> <3EB2E172.8090400@fourpalms.org> In-Reply-To: <3EB2E172.8090400@fourpalms.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200305030237.46268.tot@trema.com> Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: On Friday 02 May 2003 23:21, Thomas Lockhart wrote: > > The changes depend on HAVE_STD defined, which is currently set by > > configure script if standard headers and std namespace exists. > > Out of curiosity, how much work would you guess it would be to leave > out the "using namespace std;" lines and instead conditionally prefix > calls into the std namespace? I did not even check, but I guess not much. Since we maintain our copy of omniORB in cvs, I just wanted to keep changes minimal to avoid future conflicts when importing new omniORB version. Teemu From renej.frog@yucom.be Sat May 3 15:01:23 2003 Received: from horkos.telenet-ops.be (horkos.telenet-ops.be [195.130.132.45]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h43E1Nh29936; Sat, 3 May 2003 15:01:23 +0100 Received: from localhost (localhost.localdomain [127.0.0.1]) by horkos.telenet-ops.be (Postfix) with SMTP id 9E9B383C77; Sat, 3 May 2003 16:01:25 +0200 (CEST) Received: from fnsnb40.jati.lan (d51530887.kabel.telenet.be [81.83.8.135]) by horkos.telenet-ops.be (Postfix) with ESMTP id 7399283C59; Sat, 3 May 2003 16:01:25 +0200 (CEST) From: Rene Jager To: omniORB-dev@omniorb-support.com Cc: omniorb-list@omniorb-support.com Content-Type: text/plain Organization: Message-Id: <1051970485.3695.9.camel@fnsnb40.jati.lan> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 03 May 2003 16:01:25 +0200 Content-Transfer-Encoding: 7bit Subject: [omniORB-dev] corbaloc and unix domain sockets Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: I saw the last post about this was over a year ago, but I needed to use corbaloc's in combination with unix domain sockets. I've added support for corbaloc:uiop:SOCKET:/KEY See http://users.pandora.be/jati/renej/omniORB/ renej From steve@sextons.net Tue May 6 04:19:33 2003 Received: from zeus.my.lan (dsl093-049-077.mia1.dsl.speakeasy.net [66.93.49.77]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h463JVh14378 for ; Tue, 6 May 2003 04:19:32 +0100 Received: from sextons.net (unknown [10.0.1.51]) by zeus.my.lan (Postfix) with ESMTP id 95E0511F0E5 for ; Mon, 5 May 2003 23:16:40 -0400 (EDT) Date: Mon, 5 May 2003 23:19:14 -0400 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Steve Sexton To: omniorb-dev@omniorb-support.com Content-Transfer-Encoding: 7bit Message-Id: <83C6E276-7F71-11D7-90B4-003065576DBC@sextons.net> X-Mailer: Apple Mail (2.552) Subject: [omniORB-dev] omniNames patch for NAT Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: In case any one is interested. The following patch (against the 4.0.1 release) to omniNames adds a "-ignoreport" option for the purpose of bypassing the code that adds the "-ORBendPoint" option to ORB_init. I needed this to stop my NAT'd omniNames service from sending out its 10.x.x.x address in IOR's. Obviously if you use it you need to supply other -ORBendPointXXX options, such as the NAT combo -ORBendPointNoPublish and -ORBendPointNoListen. I do hope this finds its way into the baseline. = ) Index: omniNames.cc =================================================================== RCS file: /home/cvsroot/omniorb/omniorb/src/appl/omniNames/omniNames.cc,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- omniNames.cc 26 Apr 2003 04:32:33 -0000 1.1 +++ omniNames.cc 6 May 2003 02:15:54 -0000 1.2 @@ -58,6 +58,7 @@ cerr << "\nusage: omniNames [-start []]\n" << " [-logdir ]\n" << " [-errlog ]\n" + << " [-ignoreport]\n" << " [...]" << endl; cerr << "\nUse -start option to start omniNames for the first time." << endl @@ -66,6 +67,7 @@ << endl; cerr << "\nUse -logdir option to specify the directory where the log/data files are kept.\n"; cerr << "\nUse -errlog option to specify where standard error output is redirected.\n"; + cerr << "\nUse -ignoreport option to ignore the port specification.\n"; cerr << "\nYou can also set the environment variable " << LOGDIR_ENV_VAR << " to specify the\ndirectory where the log/data files are kept.\n" << endl; @@ -114,6 +116,7 @@ int port = 0; char* logdir = 0; + int ignoreport = 0; while (argc > 1) { if (strcmp(argv[1], "-start") == 0) { @@ -126,6 +129,10 @@ removeArgs(argc, argv, 1, 2); } } + else if (strcmp(argv[1], "-ignoreport") == 0) { + ignoreport = 1; + removeArgs(argc, argv, 1, 1); + } else if (strcmp(argv[1], "-logdir") == 0) { if (argc < 3) usage(); logdir = argv[2]; @@ -165,12 +172,16 @@ // Add a fake command line option to tell the POA which port to use. // - insertArgs(argc, argv, 1, 4); - argv[1] = strdup("-ORBendPoint"); - argv[2] = new char[20]; - sprintf(argv[2], "giop:tcp::%d", port); - argv[3] = strdup("-ORBpoaUniquePersistentSystemIds"); - argv[4] = strdup("1"); + if (ignoreport) { + insertArgs(argc, argv, 1, 2); + } else { + insertArgs(argc, argv, 1, 4); + argv[3] = strdup("-ORBendPoint"); + argv[4] = new char[20]; + sprintf(argv[4], "giop:tcp::%d", port); + } + argv[1] = strdup("-ORBpoaUniquePersistentSystemIds"); + argv[2] = strdup("1"); // // Initialize the ORB and the object adapter. From duncan@grisby.org Wed May 7 10:39:02 2003 Received: from grisby.dyndns.org (pc2-cmbg4-5-cust210.cmbg.cable.ntl.com [81.96.73.210]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h479d2h04347 for ; Wed, 7 May 2003 10:39:02 +0100 Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id h479cKW08108; Wed, 7 May 2003 10:38:20 +0100 Message-Id: <200305070938.h479cKW08108@grisby.dyndns.org> X-Authentication-Warning: pc2-cmbg4-5-cust210.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: "Nimrod, David (Dave)" cc: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] OmniNames and IONA Orbix 3.3 In-Reply-To: Message from "Nimrod, David (Dave)" of "Fri, 02 May 2003 17:56:40 EDT." <6900257941B31D4A954C71DEF805B9A201FAF8EF@nj7460avexu2.global.avaya.com> From: Duncan Grisby Date: Wed, 07 May 2003 10:38:19 +0100 Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: On Friday 2 May, "Nimrod, David (Dave)" wrote: > I am migrating a product which was using Iona Orbix2.2c01 and > OmniNames (OmniOrb 2.2.0) as its naming service. Wow! Talk about prehistoric technology... > I migrated to Iona Orbix 3.3.4 and OmniOrb 4.0.1 > Everything compiles fine, but the "resolve" method return an exception. What exception? Run omniORB with -ORBtraceLevel 10. That should help you see what's going on. Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From duncan@grisby.org Thu May 08 22:44:16 2003 Received: from pc2-cmbg4-5-cust210.cmbg.cable.ntl.com ([81.96.73.210] helo=grisby.dyndns.org) by omniorb-support.com with esmtp (Exim 4.14) id 19DtBY-00088n-Kx for omniorb-dev@omniorb-support.com; Thu, 08 May 2003 22:44:16 +0100 Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id h48LfnB19102 for ; Thu, 8 May 2003 22:41:49 +0100 Message-Id: <200305082141.h48LfnB19102@grisby.dyndns.org> X-Authentication-Warning: pc2-cmbg4-5-cust210.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: omniorb-dev@omniorb-support.com From: Duncan Grisby Date: Thu, 08 May 2003 22:41:49 +0100 Subject: [omniORB-dev] Testing, sorry X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2003 21:44:16 -0000 Sorry, just testing the list after the move. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From teemu@torma.org Thu May 08 23:04:06 2003 Received: from lou-bada.torma.org ([62.212.112.238] ident=postfix) by omniorb-support.com with esmtp (Exim 4.14) id 19DtUk-0008BE-Ki for omniorb-dev@omniorb-support.com; Thu, 08 May 2003 23:04:06 +0100 Received: from lara.lou-bada.torma.org (lara.lou-bada.torma.org [10.7.3.65]) by lou-bada.torma.org (Postfix) with ESMTP id 1E1401F12B for ; Thu, 8 May 2003 21:51:54 +0200 (CEST) From: Teemu Torma To: omniorb-dev@omniorb-support.com Date: Thu, 8 May 2003 21:51:56 +0200 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_cVru+miagFvChlD" Message-Id: <200305082151.56267.teemu@torma.org> Subject: [omniORB-dev] omniORB 4.0.1 destroy race condition X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2003 22:04:07 -0000 --Boundary-00=_cVru+miagFvChlD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline To whom it may concern. Whilst testing forthcoming valgrind 1.9.6 snapshot with omniORB application, it started reporting of mutex being unlocked by another thread than locker, or destroying a mutex still in use. By reviewing poa.cc it seems that this problem can happen in two different places where we are doing while( pd_destroyed != 2 ) pd_deathSignal.wait(); but not holding a reference to the poa. Thus when pd_deathSignal.wait() returns, in re-aquires the pd_lock, but at that point the poa might be being destructed or already completely deleted depending on the scheduling issues. By making the necessary changes to have a reference count to the poa in these two places, the problem went away, and valgrind has been happy ever since. Please see the attached patch. Teemu --Boundary-00=_cVru+miagFvChlD Content-Type: text/x-diff; charset="us-ascii"; name="poa.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="poa.diff" Index: src/lib/omniORB/orbcore/poa.cc =================================================================== RCS file: /trema/cvs/fk/tools/omniorb/src/lib/omniORB/orbcore/poa.cc,v retrieving revision 1.4 diff -c -u -r1.4 poa.cc --- src/lib/omniORB/orbcore/poa.cc 26 Mar 2003 23:15:42 -0000 1.4 +++ src/lib/omniORB/orbcore/poa.cc 8 May 2003 19:43:16 -0000 @@ -698,22 +698,37 @@ // invocations) and then remove self from parent. { - omni_tracedmutex_lock sync(pd_lock); + pd_lock.lock(); - if( pd_destroyed ) OMNIORB_THROW(OBJECT_NOT_EXIST, - OBJECT_NOT_EXIST_POANotInitialised, - CORBA::COMPLETED_NO); + if( pd_destroyed ) { + pd_lock.unlock (); + OMNIORB_THROW(OBJECT_NOT_EXIST, + OBJECT_NOT_EXIST_POANotInitialised, + CORBA::COMPLETED_NO); + } if( pd_dying ) { // Need to be able to handle multiple concurrent calls to // destroy. If destruction is in progress and wait_f_c is // true, must wait to complete. Otherwise can just return. - if( wait_for_completion ) + if( wait_for_completion ) { + + incrRefCount(); + while( pd_destroyed != 2 ) pd_deathSignal.wait(); + + pd_lock.unlock (); + decrRefCount(); + + } else { + pd_lock.unlock (); + } return; } pd_dying = 1; + + pd_lock.unlock (); } { @@ -2193,8 +2208,10 @@ if( pd_dying ) { // If being destroyed by another thread, then we just // have to wait until that completes. + incrRefCount(); while( pd_destroyed != 2 ) pd_deathSignal.wait(); pd_lock.unlock(); + decrRefCount(); return; } --Boundary-00=_cVru+miagFvChlD-- From duncan@grisby.org Fri May 09 11:25:59 2003 Received: from pc2-cmbg4-5-cust210.cmbg.cable.ntl.com ([81.96.73.210] helo=grisby.dyndns.org) by omniorb-support.com with esmtp (Exim 4.14) id 19E54h-0000HL-9N for omniorb-dev@omniorb-support.com; Fri, 09 May 2003 11:25:59 +0100 Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id h49ANEa21456; Fri, 9 May 2003 11:23:14 +0100 Message-Id: <200305091023.h49ANEa21456@grisby.dyndns.org> X-Authentication-Warning: pc2-cmbg4-5-cust210.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: Xavier Outhier Subject: Re: [omniORB-dev] [WinCE port] compile error #001, #002, #003, #004 in nt.cc In-Reply-To: Message from Xavier Outhier of "Mon, 28 Apr 2003 16:44:16 +0200." <3EAD3E40.92D164BB@anfdata.cz> From: Duncan Grisby Date: Fri, 09 May 2003 11:23:13 +0100 Cc: omniORB Dev X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2003 10:25:59 -0000 On Monday 28 April, Xavier Outhier wrote: > The first error I got was in > omniORB-4.0.1/src/lib/omnithread/nt.cc > > D:\Windows CE Tools\WCE300\ms pocket pc\include\stdlib.h(928) : error C2065: '_JBLEN' You need to do a full port of omnithread to CE. You may be able to base it on the one for NT. It's not sensible to try to use the posix version instead. You need to look at the CE threads documentation to see how it's meant to work. Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From duncan@grisby.org Fri May 09 12:17:47 2003 Received: from pc2-cmbg4-5-cust210.cmbg.cable.ntl.com ([81.96.73.210] helo=grisby.dyndns.org) by omniorb-support.com with esmtp (Exim 4.14) id 19E5sp-0000wB-RF for omniorb-dev@omniorb-support.com; Fri, 09 May 2003 12:17:47 +0100 Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id h49BF1N31905; Fri, 9 May 2003 12:15:01 +0100 Message-Id: <200305091115.h49BF1N31905@grisby.dyndns.org> X-Authentication-Warning: pc2-cmbg4-5-cust210.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: Teemu Torma Subject: Re: [omniORB-dev] Patch: omniORB 4 std headers and namespace fixes In-Reply-To: Message from Teemu Torma of "Fri, 02 May 2003 21:45:51 +0200." <200305022145.51842.tot@trema.com> From: Duncan Grisby Date: Fri, 09 May 2003 12:15:00 +0100 Cc: omniorb-dev@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2003 11:17:48 -0000 On Friday 2 May, Teemu Torma wrote: > If anyone is interested, please see the attached patch to conditionally > use standard headers and namespace. This avoids deprecated include > warnings with gcc 3.2 and allows the system to be compiled with Visual > Studio .Net (or whatever the name officially is, probably starts with > Microsoft and ends with an ®). Thanks for that. I'll check in the changes in a bit. Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From duncan@grisby.org Fri May 09 14:19:23 2003 Received: from pc2-cmbg4-5-cust210.cmbg.cable.ntl.com ([81.96.73.210] helo=grisby.dyndns.org) by omniorb-support.com with esmtp (Exim 4.14) id 19E7mV-00019l-8e for omniorb-dev@omniorb-support.com; Fri, 09 May 2003 14:19:23 +0100 Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id h49DGVJ01812; Fri, 9 May 2003 14:16:32 +0100 Message-Id: <200305091316.h49DGVJ01812@grisby.dyndns.org> X-Authentication-Warning: pc2-cmbg4-5-cust210.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: Steve Sexton Subject: Re: [omniORB-dev] omniNames patch for NAT In-Reply-To: Message from Steve Sexton of "Mon, 05 May 2003 23:19:14 EDT." <83C6E276-7F71-11D7-90B4-003065576DBC@sextons.net> From: Duncan Grisby Date: Fri, 09 May 2003 14:16:31 +0100 Cc: omniorb-dev@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2003 13:19:23 -0000 On Monday 5 May, Steve Sexton wrote: > The following patch (against the 4.0.1 release) to omniNames adds a > "-ignoreport" option for the purpose of bypassing the code that adds > the "-ORBendPoint" option to ORB_init. Thanks for that. I'll check it in. As a future note, please send patches as attachments. You email program mangled the line endings, so the patch didn't work. It was small enough that I did it by hand. Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From duncan@grisby.org Fri May 09 14:28:57 2003 Received: from pc2-cmbg4-5-cust210.cmbg.cable.ntl.com ([81.96.73.210] helo=grisby.dyndns.org) by omniorb-support.com with esmtp (Exim 4.14) id 19E7vk-0001Vc-UM for omniorb-dev@omniorb-support.com; Fri, 09 May 2003 14:28:56 +0100 Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id h49DQ7p01997; Fri, 9 May 2003 14:26:07 +0100 Message-Id: <200305091326.h49DQ7p01997@grisby.dyndns.org> X-Authentication-Warning: pc2-cmbg4-5-cust210.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: Teemu Torma Subject: Re: [omniORB-dev] omniORB 4.0.1 destroy race condition In-Reply-To: Message from Teemu Torma of "Thu, 08 May 2003 21:51:56 +0200." <200305082151.56267.teemu@torma.org> From: Duncan Grisby Date: Fri, 09 May 2003 14:26:07 +0100 Cc: omniorb-dev@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2003 13:28:57 -0000 On Thursday 8 May, Teemu Torma wrote: > Thus when pd_deathSignal.wait() > returns, in re-aquires the pd_lock, but at that point the poa might be > being destructed or already completely deleted depending on the > scheduling issues. Thanks for the fix. The strange thing is that I'm sure I remember fixing the same problem before, but obviously not. Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From nimrod@avaya.com Mon May 12 21:57:03 2003 Received: from iere.net.avaya.com ([198.152.12.101]) by omniorb-support.com with esmtp (Exim 4.14) id 19FKM3-0000xw-0y for omniorb-dev@omniorb-support.com; Mon, 12 May 2003 21:57:03 +0100 Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h4CKoDO20589 for ; Mon, 12 May 2003 16:50:13 -0400 (EDT) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h4CKoCL20583 for ; Mon, 12 May 2003 16:50:12 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [omniORB-dev] OmniNames and IONA Orbix 3.3 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Mon, 12 May 2003 16:53:16 -0400 Message-ID: <6900257941B31D4A954C71DEF805B9A25369CF@nj7460avexu2.global.avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [omniORB-dev] OmniNames and IONA Orbix 3.3 Thread-Index: AcMYyILTGEcQHXIwQKO8EPAyslVCbQ== From: "Nimrod, David (Dave)" To: "Duncan Grisby" Cc: omniorb-dev@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2003 20:57:03 -0000 Duncan: Here's a debug dump. As you can see I'm getting a [omniORB: throw OBJECT_NOT_EXIST from = GIOP_S.cc:325 (NO,OBJECT_NOT_EXIST_NoMatch)] exception. One funny thing about my setup is that the IOR is constructed directly = from the nameservice string and NOT by doing resolve_initial_reference. = Would that be a problem in OmniOrb 4.0.1? Thanks, Dave Nimrod. C:\Program Files\omniORB-4.0.1\bin\x86_win32>omninames omniORB: Distribution date: Fri Mar 14 11:27:17 GMT 2003 dgrisby omniORB: My addresses are: omniORB: 135.8.116.17 omniORB: 127.0.0.1 omniORB: Maximum supported GIOP version is 1.2 omniORB: Native char code sets: UTF-8 ISO-8859-1. omniORB: Transmission char code sets: UTF-8(1.2) ISO-8859-1(1.2) = ISO-8859-1(1.1) ISO-8859-1(1.0). omniORB: Native wide char code sets: UTF-16. omniORB: Transmission wide char code sets: UTF-16(1.2). omniORB: Information: the omniDynamic library is not linked. omniORB: Current configuration is as follows: omniORB: DefaultInitRef (file) =3D omniORB: DefaultInitRef (args) =3D omniORB: InitRef =3D = NameService=3Dcorbaname::LZNIMROD-A2.rnd.avaya.com omniORB: abortOnInternalError =3D 0 omniORB: acceptBiDirectionalGIOP =3D 0 omniORB: acceptMisalignedTcIndirections =3D 0 omniORB: bootstrapAgentHostname =3D omniORB: bootstrapAgentPort =3D 900 omniORB: clientCallTimeOutPeriod =3D 0 omniORB: clientTransportRule =3D * unix,ssl,tcp omniORB: diiThrowsSysExceptions =3D 0 omniORB: dumpConfiguration =3D 0 omniORB: endPoint =3D giop:tcp::1701 omniORB: endPointPublishAllIFs =3D 0 omniORB: giopMaxMsgSize =3D 2097152 omniORB: giopTargetAddressMode =3D KeyAddr omniORB: id =3D omniORB4 omniORB: inConScanPeriod =3D 180 omniORB: lcdMode =3D 0 omniORB: maxGIOPConnectionPerServer =3D 5 omniORB: maxGIOPVersion =3D 1.2 omniORB: maxInterleavedCallsPerConnection =3D 5 omniORB: maxServerThreadPerConnection =3D 100 omniORB: maxServerThreadPoolSize =3D 100 omniORB: nativeCharCodeSet =3D ISO-8859-1 omniORB: nativeWCharCodeSet =3D UTF-16 omniORB: objectTableSize =3D 0 omniORB: offerBiDirectionalGIOP =3D 0 omniORB: omniORB_27_CompatibleAnyExtraction =3D 0 omniORB: oneCallPerConnection =3D 1 omniORB: outConScanPeriod =3D 120 omniORB: poaHoldRequestTimeout =3D 0 omniORB: poaUniquePersistentSystemIds =3D 1 omniORB: principal =3D [Null] omniORB: scanGranularity =3D 5 omniORB: serverCallTimeOutPeriod =3D 0 omniORB: serverTransportRule =3D * unix,ssl,tcp omniORB: strictIIOP =3D 1 omniORB: supportBootstrapAgent =3D 0 omniORB: supportCurrent =3D 1 omniORB: supportPerThreadTimeOut =3D 0 omniORB: tcAliasExpand =3D 0 omniORB: threadPerConnectionLowerLimit =3D 9000 omniORB: threadPerConnectionPolicy =3D 1 omniORB: threadPerConnectionUpperLimit =3D 10000 omniORB: threadPoolWatchConnection =3D 1 omniORB: traceInvocations =3D 0 omniORB: traceLevel =3D 100 omniORB: traceThreadId =3D 0 omniORB: unixTransportDirectory =3D /tmp/omni-%u omniORB: unixTransportPermission =3D 777 omniORB: useTypeCodeIndirections =3D 1 omniORB: verifyObjectExistsAndType =3D 1 omniORB: Initialising incoming endpoints. omniORB: Bind to address 0.0.0.0. omniORB: Starting serving incoming endpoints. omniORB: Adding key<0x4e616d6553657276696365> (activating) to object = table. omniORB: State key<0x4e616d6553657276696365> (activating) -> active Fri May 09 17:06:45 2003: Read log file successfully. omniORB: Creating ref to local: key<0x4e616d6553657276696365> target id : IDL:omg.org/CosNaming/NamingContextExt:1.0 most derived id: IDL:omg.org/CosNaming/NamingContextExt:1.0 Root context is = IOR:010000002b00000049444c3a6f6d672e6f72672f436f734e616d696e672f4e616d696= e67436f6e746578744578743a312e3000000100 00000000000060000000010102000d0000003133352e382e3131362e31370000a5060b000= 0004e616d6553657276696365000200000000000000080000000100 000000545441010000001c000000010000000100010001000000010001050901010001000= 00009010100 Checkpointing Phase 1: Prepare. Checkpointing Phase 2: Commit. omniORB: AsyncInvoker: thread id =3D 1 has started. Total threads =3D 1 omniORB: giopRendezvouser task execute for giop:tcp:135.8.116.17:1701 Checkpointing completed. omniORB: Server accepted connection from giop:tcp:135.8.116.17:3929 omniORB: AsyncInvoker: thread id =3D 2 has started. Total threads =3D 3 omniORB: Scavenger task execute. omniORB: AsyncInvoker: thread id =3D 3 has started. Total threads =3D 3 omniORB: giopWorker task execute. omniORB: Accepted connection from giop:tcp:135.8.116.17:3929 because of = this rule: "* unix,ssl,tcp" omniORB: inputMessage: from giop:tcp:135.8.116.17:3929 93 bytes omniORB: 4749 4f50 0100 0100 5100 0000 0000 0000 GIOP....Q....... 0000 0000 0100 0000 0c00 0000 3414 c1bd ............4... 0000 02f2 0000 0001 0800 0000 7265 736f ............reso 6c76 6500 0700 0000 6e69 6d72 6f64 0069 lve.....nimrod.i 0100 0000 0f00 0000 436f 6d6d 756e 6963 ........Communic 6174 696f 6e73 00f2 0100 0000 00 ations....... omniORB: throw OBJECT_NOT_EXIST from GIOP_S.cc:325 = (NO,OBJECT_NOT_EXIST_NoMatch) omniORB: sendChunk: to giop:tcp:135.8.116.17:3929 76 bytes omniORB: 4749 4f50 0100 0101 4000 0000 0000 0000 GIOP....@....... 0000 0000 0200 0000 2700 0000 4944 4c3a ........'...IDL: 6f6d 672e 6f72 672f 434f 5242 412f 4f42 omg.org/CORBA/OB 4a45 4354 5f4e 4f54 5f45 5849 5354 3a31 JECT_NOT_EXIST:1 2e30 0000 0100 4d4f 0100 0000 .0....MO.... omniORB: Scan for idle connections (1052514426,303000000) omniORB: Scavenger reduce idle count for strand 00338A78 to 35 omniORB: Scan for idle connections done (1052514426,303000000). omniORB: inputMessage: from giop:tcp:135.8.116.17:3929 93 bytes omniORB: 4749 4f50 0100 0100 5100 0000 0000 0000 GIOP....Q....... 0100 0000 0100 0000 0c00 0000 3414 c1bd ............4... 0000 02f2 0000 0001 0800 0000 7265 736f ............reso 6c76 6500 0700 0000 6e69 6d72 6f64 0069 lve.....nimrod.i 0100 0000 0f00 0000 436f 6d6d 756e 6963 ........Communic 6174 696f 6e73 00f2 0100 0000 00 ations....... omniORB: throw OBJECT_NOT_EXIST from GIOP_S.cc:325 = (NO,OBJECT_NOT_EXIST_NoMatch) omniORB: sendChunk: to giop:tcp:135.8.116.17:3929 76 bytes omniORB: 4749 4f50 0100 0101 4000 0000 0000 0000 GIOP....@....... 0100 0000 0200 0000 2700 0000 4944 4c3a ........'...IDL: 6f6d 672e 6f72 672f 434f 5242 412f 4f42 omg.org/CORBA/OB 4a45 4354 5f4e 4f54 5f45 5849 5354 3a31 JECT_NOT_EXIST:1 2e30 0000 0100 4d4f 0100 0000 .0....MO.... omniORB: Scan for idle connections (1052514431,303000000) omniORB: Scavenger reduce idle count for strand 00338A78 to 35 omniORB: Scan for idle connections done (1052514431,303000000). omniORB: inputMessage: from giop:tcp:135.8.116.17:3929 93 bytes omniORB: 4749 4f50 0100 0100 5100 0000 0000 0000 GIOP....Q....... 0200 0000 0100 0000 0c00 0000 3414 c1bd ............4... 0000 02f2 0000 0001 0800 0000 7265 736f ............reso 6c76 6500 0700 0000 6e69 6d72 6f64 0069 lve.....nimrod.i 0100 0000 0f00 0000 436f 6d6d 756e 6963 ........Communic 6174 696f 6e73 00f2 0100 0000 00 ations....... omniORB: throw OBJECT_NOT_EXIST from GIOP_S.cc:325 = (NO,OBJECT_NOT_EXIST_NoMatch) omniORB: sendChunk: to giop:tcp:135.8.116.17:3929 76 bytes omniORB: 4749 4f50 0100 0101 4000 0000 0000 0000 GIOP....@....... 0200 0000 0200 0000 2700 0000 4944 4c3a ........'...IDL: 6f6d 672e 6f72 672f 434f 5242 412f 4f42 omg.org/CORBA/OB 4a45 4354 5f4e 4f54 5f45 5849 5354 3a31 JECT_NOT_EXIST:1 2e30 0000 0100 4d4f 0100 0000 .0....MO.... omniORB: throw giopStream::CommFailure from = giopStream.cc:819(0,NO,COMM_FAILURE_UnMarshalArguments) omniORB: Server connection refcount =3D 1 omniORB: Server connection refcount =3D 0 omniORB: Server close connection from giop:tcp:135.8.116.17:3929 omniORB: Scan for idle connections (1052514436,303000000) omniORB: Scan for idle connections done (1052514436,303000000). omniORB: Scan for idle connections (1052514441,303000000) omniORB: Scan for idle connections done (1052514441,303000000). omniORB: AsyncInvoker: thread id =3D 3 has exited. Total threads =3D 3 omniORB: Scan for idle connections (1052514446,303000000) omniORB: Scan for idle connections done (1052514446,303000000). omniORB: ObjRef(IDL:omg.org/CosNaming/NamingContextExt:1.0) -- deleted. omniORB: ORB not destroyed; no final clean-up. ^C C:\Program Files\omniORB-4.0.1\bin\x86_win32> -----Original Message----- From: omniorb-dev-admin@omniorb-support.com = [mailto:omniorb-dev-admin@omniorb-support.com]On Behalf Of Duncan Grisby Sent: Wednesday, May 07, 2003 4:38 AM To: Nimrod, David (Dave) Cc: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] OmniNames and IONA Orbix 3.3=20 On Friday 2 May, "Nimrod, David (Dave)" wrote: > I am migrating a product which was using Iona Orbix2.2c01 and > OmniNames (OmniOrb 2.2.0) as its naming service. Wow! Talk about prehistoric technology... > I migrated to Iona Orbix 3.3.4 and OmniOrb 4.0.1 > Everything compiles fine, but the "resolve" method return an = exception. What exception? Run omniORB with -ORBtraceLevel 10. That should help you see what's going on. Cheers, Duncan. --=20 -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From nimrod@avaya.com Sat May 17 00:14:02 2003 Received: from ierw.net.avaya.com ([198.152.13.101]) by omniorb-support.com with esmtp (Exim 4.14) id 19GoOo-0006Yh-IH for omniorb-dev@omniorb-support.com; Sat, 17 May 2003 00:14:02 +0100 Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id TAA01983 for ; Fri, 16 May 2003 19:05:33 -0400 (EDT) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id TAA01913 for ; Fri, 16 May 2003 19:05:32 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [omniORB-dev] OmniNames and IONA Orbix 3.3 Date: Fri, 16 May 2003 19:08:12 -0400 Message-ID: <6900257941B31D4A954C71DEF805B9A25369D2@nj7460avexu2.global.avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [omniORB-dev] OmniNames and IONA Orbix 3.3 Thread-Index: AcMYyILTGEcQHXIwQKO8EPAyslVCbQDMOrQA From: "Nimrod, David (Dave)" To: "Nimrod, David (Dave)" , "Duncan Grisby" Cc: omniorb-dev@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2003 23:14:03 -0000 Hi all: I thought I was making some headway with this one, but I'm stumped again Turns out the original code was generating IORs to the old spec. I made = a change to call "genRef" (from genior.cc) and now I'm generating proper = IOR's. However, I still get an "Invalid Object Ref" exception in the code = below. The ORB log only shows "Handling a GIOP LOCATE_REQUEST" Any ideas? Any help would be greatly appreciated. OmniNames Log: omniORB: Server accepted connection from giop:tcp:135.8.116.17:3079 omniORB: AsyncInvoker: thread id =3D 2 has started. Total threads =3D 3 omniORB: Scavenger task execute. omniORB: AsyncInvoker: thread id =3D 3 has started. Total threads =3D 3 omniORB: giopWorker task execute. omniORB: Accepted connection from giop:tcp:135.8.116.17:3079 because of = this rule: "* unix,ssl,tcp" omniORB: inputMessage: from giop:tcp:135.8.116.17:3079 32 bytes omniORB: 4749 4f50 0100 0103 1400 0000 0000 0000 GIOP............ 0c00 0000 3ec3 d876 0000 10ea 0000 0001 ....>..v........ omniORB: Handling a GIOP LOCATE_REQUEST. omniORB: sendChunk: to giop:tcp:135.8.116.17:3079 20 bytes omniORB: 4749 4f50 0100 0104 0800 0000 0000 0000 GIOP............ 0000 0000 .... My code: CORBA::Object_var aObjectVar; CosNaming::NamingContext_ptr aNewRootContext; try { aObjectVar =3D = CORBA::Orbix.string_to_object(const_cast(narrow(aNameServiceIOR).c= _str())); aNewRootContext =3D CosNaming::NamingContext::_narrow(aObjectVar); = <<<< This throws the exception. mNameServiceMap[aNameServiceIOR] =3D aNewRootContext; } catch (CORBA::SystemException const&sysEx) { ConsolePrintf(HighPriDbgException, "NameChronicler::addNameServiceIOR = CORBA::SystemException exception handler throw ObjectDoesNotExist: = %lu.\n", sysEx.minor()); throw ObjectDoesNotExist(CANT_ADD_NAMESERVICE); } My log: IORGenerator::NameServiceIOR. sHostname =3D 'lznimrod-a2' IORGenerator::MakeIOR. IRTypeId =3D 'omg.org/CosNaming/NamingContext' = sHostname =3D 'lznimrod-a2', port =3D 2809, sKeyseed =3D = '0x3ec3d876000010ea00000001' IORGenerator::MakeIOR. sResult =3D = 'IOR:01000000200000006f6d672e6f72672f436f734e616d696e672f4e616d696e67436f= 6e7465787400010000000000000060000000010102000c0000006c7a6e696d726f642d613= 200f90a00000c0000003ec3d876000010ea00000001020000000000000008000000010000= 0000545441010000001c00000001000000010001000100000001000105090101000100000= 009010100' NameChronicler::addNameServiceIOR. aNameServiceIOR =3D = 'IOR:01000000200000006f6d672e6f72672f436f734e616d696e672f4e616d696e67436f= 6e7465787400010000000000000060000000010102000c0000006c7a6e696d726f642d613= 200f90a00000c0000003ec3d876000010ea00000001020000000000000008000000010000= 0000545441010000001c00000001000000010001000100000001000105090101000100000= 009010100' First-chance exception in ConnectionServer.exe (KERNEL32.DLL): = 0xE06D7363: Microsoft C++ Exception. NameChronicler::addNameServiceIOR CORBA::SystemException exception = handler throw ObjectDoesNotExist: 10101. ______________________________________=20 David Nimrod Avaya Inc.=20 Email: Nimrod@avaya.com =20 ______________________________________ -----Original Message----- From: Nimrod, David (Dave)=20 Sent: Monday, May 12, 2003 3:53 PM To: 'Duncan Grisby' Cc: omniorb-dev@omniorb-support.com Subject: RE: [omniORB-dev] OmniNames and IONA Orbix 3.3=20 Duncan: Here's a debug dump. As you can see I'm getting a [omniORB: throw OBJECT_NOT_EXIST from = GIOP_S.cc:325 (NO,OBJECT_NOT_EXIST_NoMatch)] exception. One funny thing about my setup is that the IOR is constructed directly = from the nameservice string and NOT by doing resolve_initial_reference. = Would that be a problem in OmniOrb 4.0.1? Thanks, Dave Nimrod. <<>> -----Original Message----- From: omniorb-dev-admin@omniorb-support.com = [mailto:omniorb-dev-admin@omniorb-support.com]On Behalf Of Duncan Grisby Sent: Wednesday, May 07, 2003 4:38 AM To: Nimrod, David (Dave) Cc: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] OmniNames and IONA Orbix 3.3=20 On Friday 2 May, "Nimrod, David (Dave)" wrote: > I am migrating a product which was using Iona Orbix2.2c01 and > OmniNames (OmniOrb 2.2.0) as its naming service. Wow! Talk about prehistoric technology... > I migrated to Iona Orbix 3.3.4 and OmniOrb 4.0.1 > Everything compiles fine, but the "resolve" method return an = exception. What exception? Run omniORB with -ORBtraceLevel 10. That should help you see what's going on. Cheers, Duncan. --=20 -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From bill.arreckx@acterna.com Mon May 19 15:48:34 2003 Received: from mio.wago.de ([141.169.254.2]) by omniorb-support.com with esmtp (Exim 4.14) id 19HlwI-0001cD-BF for omniorb-dev@omniorb-support.com; Mon, 19 May 2003 15:48:34 +0100 Received: from wago.de (donau [141.169.1.4]) by mio.wago.de (8.11.6+Sun/8.11.6) with ESMTP id h4JEesJ15725 for ; Mon, 19 May 2003 16:40:54 +0200 (MEST) Received: from magnus.eng.eni.wago.de (magnus [141.169.1.17]) by wago.de (8.11.6+Sun/8.11.6) with ESMTP id h4JEerS01720 for ; Mon, 19 May 2003 16:40:54 +0200 (MEST) To: omniorb-dev@omniorb-support.com MIME-Version: 1.0 Message-ID: From: "Guillaume Arreckx" Date: Mon, 19 May 2003 15:40:52 +0100 Content-Type: multipart/alternative; boundary="=_alternative 0050E31E80256D2B_=" Subject: [omniORB-dev] Port to arm-linux (iPaq, Zaurus, others) X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2003 14:48:34 -0000 This is a multipart message in MIME format. --=_alternative 0050E31E80256D2B_= Content-Type: text/plain; charset="us-ascii" Hi there, I have ported omniORB to the Zaurus (in view of using it on a custom hardware later). The port itself went smoothly but when running the examples, I managed to get eg1, eg2 etc... to work, but the ORB either locks or crash when invoking the ORB destroy method. The GDB traceback reports some problems when the ORB uses the glibc. I am using the Embeddix tool chain. Has anybody ported omniORB on the strongARM and got it to work ? Are there any option to pass the compiler to get it to work ? Thanks, Guillaume --=_alternative 0050E31E80256D2B_= Content-Type: text/html; charset="us-ascii"
Hi there,

I have ported omniORB to the Zaurus (in view of using it on a custom hardware later).
The port itself went smoothly but when running the examples, I managed to get eg1, eg2 etc... to work, but the ORB either locks or crash when invoking the ORB destroy method. The GDB traceback reports some problems when the ORB uses the glibc.
I am using the Embeddix tool chain.

Has anybody ported omniORB on the strongARM and got it to work ?
Are there any option to pass the compiler to get it to work ?

Thanks,

Guillaume --=_alternative 0050E31E80256D2B_=-- From duncan@grisby.org Tue May 20 13:15:38 2003 Received: from pc2-cmbg4-5-cust210.cmbg.cable.ntl.com ([81.96.73.210] helo=grisby.dyndns.org) by omniorb-support.com with esmtp (Exim 4.14) id 19I61q-0002WP-8g for omniorb-dev@omniorb-support.com; Tue, 20 May 2003 13:15:38 +0100 Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id h4KC7KO06443; Tue, 20 May 2003 13:07:20 +0100 Message-Id: <200305201207.h4KC7KO06443@grisby.dyndns.org> X-Authentication-Warning: pc2-cmbg4-5-cust210.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: "Nimrod, David (Dave)" Subject: Re: [omniORB-dev] OmniNames and IONA Orbix 3.3 In-Reply-To: Message from "Nimrod, David (Dave)" of "Fri, 16 May 2003 19:08:12 EDT." <6900257941B31D4A954C71DEF805B9A25369D2@nj7460avexu2.global.avaya.com> From: Duncan Grisby Date: Tue, 20 May 2003 13:07:20 +0100 Cc: omniorb-dev@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2003 12:15:38 -0000 On Friday 16 May, "Nimrod, David (Dave)" wrote: > I thought I was making some headway with this one, but I'm stumped > again Turns out the original code was generating IORs to the old > spec. I made a change to call "genRef" (from genior.cc) and now I'm > generating proper IOR's. Why are you generating IORs at all? > However, I still get an "Invalid Object Ref" exception in the code > below. The ORB log only shows "Handling a GIOP LOCATE_REQUEST" > 4749 4f50 0100 0103 1400 0000 0000 0000 GIOP............ > 0c00 0000 3ec3 d876 0000 10ea 0000 0001 ....>..v........ > omniORB: Handling a GIOP LOCATE_REQUEST. > omniORB: sendChunk: to giop:tcp:135.8.116.17:3079 20 bytes > omniORB: > 4749 4f50 0100 0104 0800 0000 0000 0000 GIOP............ > 0000 0000 .... This shows omniORB replying that the object does not exist. The most likely reason is that you have the object key wrong in the IOR you have built. The key for the root naming context should be "NameService". The above trace shows that you aren't using that key. Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From duncan@grisby.org Thu May 22 16:30:49 2003 Received: from pc2-cmbg4-5-cust210.cmbg.cable.ntl.com ([81.96.73.210] helo=grisby.dyndns.org) by omniorb-support.com with esmtp (Exim 4.14) id 19Is1p-0005It-9b for omniorb-dev@omniorb-support.com; Thu, 22 May 2003 16:30:49 +0100 Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id h4MFLRq30570; Thu, 22 May 2003 16:21:28 +0100 Message-Id: <200305221521.h4MFLRq30570@grisby.dyndns.org> X-Authentication-Warning: pc2-cmbg4-5-cust210.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: "Guillaume Arreckx" Subject: Re: [omniORB-dev] Port to arm-linux (iPaq, Zaurus, others) In-Reply-To: Message from "Guillaume Arreckx" of "Mon, 19 May 2003 15:40:52 BST." From: Duncan Grisby Date: Thu, 22 May 2003 16:21:27 +0100 Cc: omniorb-dev@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 15:30:49 -0000 On Monday 19 May, "Guillaume Arreckx" wrote: > I have ported omniORB to the Zaurus (in view of using it on a custom > hardware later). > The port itself went smoothly but when running the examples, I managed to > get eg1, eg2 etc... to work, but the ORB either locks or crash when > invoking the ORB destroy method. The GDB traceback reports some problems > when the ORB uses the glibc. Most versions of gcc on Arm do not support thread safe exception handling, hence your crashes. gcc 3.3 might work. Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From dan@cgl.ucsf.edu Tue May 27 19:05:16 2003 Received: from socrates.cgl.ucsf.edu ([169.230.27.3] helo=adenine.cgl.ucsf.edu) by omniorb-support.com with esmtp (Exim 4.14) id 19Kip1-0005Nf-NB for omniorb-dev@omniorb-support.com; Tue, 27 May 2003 19:05:15 +0100 Received: from localhost (socrates.cgl.ucsf.edu [169.230.27.3]) by adenine.cgl.ucsf.edu (8.12.9/8.12.9/GSC1.16) with ESMTP id h4RHs37W673816 for ; Tue, 27 May 2003 10:54:03 -0700 (PDT) Date: Tue, 27 May 2003 10:54:03 -0700 (PDT) From: Daniel Greenblatt To: omniorb-dev@omniorb-support.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [omniORB-dev] omniORB and valuetypes... X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2003 18:05:16 -0000 We hope to use omniORB to talk to a java ORB server, using idl that is littered with valuetype declarations. Thus, I was very excited to hear a week or two ago that some work has been done on support of valuetypes in omniORB. I tried to compile IDL that contained valuetypes (using a dev version of omniORB and omniorbpy checked out on May 22nd), and received the following traceback: Traceback (most recent call last): File "/home/dan/omnidev/omni41/bin/omniidl", line 105, in ? omniidl.main.main() File "./main.py", line 486, in main File "./omniidl_be/python.py", line 715, in run File "./omniidl/idlast.py", line 171, in accept File "./omniidl_be/python.py", line 777, in visitAST File "./omniidl/idlast.py", line 300, in accept File "./omniidl_be/python.py", line 818, in visitModule File "./omniidl/idlast.py", line 1027, in accept File "./omniidl_be/python.py", line 1701, in visitValue AttributeError: Value instance has no attribute 'statemembers' Am I doing something wrong? Are there any flags that need to be passed to omniidl to handle valuetypes? If there is any other info I can provide (such as the idl...), let me know. Thanks for your help, Dan Greenblatt From duncan@grisby.org Tue May 27 20:52:22 2003 Received: from pc2-cmbg4-5-cust210.cmbg.cable.ntl.com ([81.96.73.210] helo=grisby.dyndns.org) by omniorb-support.com with esmtp (Exim 4.14) id 19KkUg-0005PN-EK for omniorb-dev@omniorb-support.com; Tue, 27 May 2003 20:52:22 +0100 Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id h4RJeK312479; Tue, 27 May 2003 20:40:21 +0100 Message-Id: <200305271940.h4RJeK312479@grisby.dyndns.org> X-Authentication-Warning: pc2-cmbg4-5-cust210.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: Daniel Greenblatt Subject: Re: [omniORB-dev] omniORB and valuetypes... In-Reply-To: Message from Daniel Greenblatt of "Tue, 27 May 2003 10:54:03 PDT." From: Duncan Grisby Date: Tue, 27 May 2003 20:40:20 +0100 Cc: omniorb-dev@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2003 19:52:22 -0000 On Tuesday 27 May, Daniel Greenblatt wrote: > I tried to compile IDL that contained valuetypes (using a dev version > of omniORB and omniorbpy checked out on May 22nd), and received the > following traceback: [...] > File "./omniidl/idlast.py", line 1027, in accept > File "./omniidl_be/python.py", line 1701, in visitValue > AttributeError: Value instance has no attribute 'statemembers' Strange. Did you definitely do make; make install in the omniORB tree as well as the omniORBpy tree? I added the new statemembers() method to the Value object, but you don't seem to have picked it up. The version of src/tool/omniidl/python/omniidl/idlast.py you have should be 1.20.2.2. The fact that idlast.py line 1027 for you is the accept function shows that you have the wrong version, since it's on line 1044 now. Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From Philippe.Combes@ens-lyon.fr Mon Jul 07 13:02:42 2003 Received: from pluvier.ens-lyon.fr ([140.77.167.5] helo=mailhost.ens-lyon.fr) by omniorb-support.com with esmtp (Exim 4.14) id 19ZUhe-0008Oi-KZ for omniorb-dev@omniorb-support.com; Mon, 07 Jul 2003 13:02:42 +0100 Received: from concorde.cri2000.ens-lyon.fr ([140.77.13.180] helo=ens-lyon.fr) by mailhost.ens-lyon.fr with esmtp (Exim 3.35 #1 (Debian)) id 19ZUD9-00041f-00 for ; Mon, 07 Jul 2003 13:31:11 +0200 Message-ID: <3F095992.5070805@ens-lyon.fr> Date: Mon, 07 Jul 2003 13:29:22 +0200 From: Philippe Combes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030618 Debian/1.3.1-3 X-Accept-Language: fr, en MIME-Version: 1.0 To: omniorb-dev@omniorb-support.com Content-Type: multipart/mixed; boundary="------------070603000900070206020800" Subject: [omniORB-dev] Warning in generated skeletons X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2003 12:02:42 -0000 This is a multi-part message in MIME format. --------------070603000900070206020800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi all, I use omniORB 4.0.1 on a Debian Linux pentium III platform, g++ 3.3.1 The coding standards of the application that I develop force the code to be compiled with the flags -Wall -Werror. But omniidl generates code that is not compliant with the -Wreorder flag (which enabled by -Wall). ~ > cat foo.idl interface Parent { long dummy0(); }; interface Child : Parent { long dummy1(); }; ~ > omniidl -bcxx foo.idl ~ > g++ -Wall -Werror -c fooSK.cc -o fooSK.o fooSK.cc: In constructor `_objref_Child::_objref_Child(omniIOR*, omniIdentity*) ': fooSK.cc:306: warning: base `_objref_Parent' will be initialized after fooSK.cc:306: warning: base `omniObjRef' ~ > This warning is due to the following lines in fooSK.cc : _objref_Child::_objref_Child(omniIOR* ior, omniIdentity* id) : _objref_Parent(ior, id), omniObjRef(::Child::_PD_repoId, ior, id, 1) { _PR_setobj(this); } I looked at the code of omniidl. I built up a patch, attached to this message, but it does not seem enough. Indeed, I patched the source code of omniORB-4.0.1 as well as the last CVS snapshot (july, 7th) : cd src/lib/omniORB/omniidl_be patch -Np0 < warning_on_base_omniObjRef_initialized_after.patch but the omniidl generated still generates the same lines. I must confess I am not used to the omniORB source tree, maybe these changes should be reported somewhere else, but I do not know where. Of course, this is just a warning that can be skipped using the -Wno-reorder flag. But it is in the generated code, not in the code of omniidl itself. Hope this will be useful ... Philippe ------------------------------------------------- Philippe Combes. IE INRIA, LIP - ENS Lyon 46, allée d'Italie 69364 Lyon Cedex 07, France Tel: (+33)4 72 72 84 70, Fax: (+33)4 72 72 80 80 Web Page: http://www.ens-lyon.fr/~pcombes/ ------------------------------------------------- --------------070603000900070206020800 Content-Type: text/plain; name="warning_on_base_omniObjRef_initialized_after.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="warning_on_base_omniObjRef_initialized_after.patch" diff -Naur cxx/iface.py cxx_patched/iface.py --- cxx/iface.py 2003-03-03 16:02:30.000000000 +0100 +++ cxx_patched/iface.py 2003-07-05 15:33:04.000000000 +0200 @@ -334,7 +334,7 @@ if objref_name.needFlatName(self._environment): objref_str = objref_name.flatName() - this_inherits_str = objref_str + "(ior, id),\n" + this_inherits_str = ",\n" + objref_str + "(ior, id)" # FIXME: # The powerpc-aix OMNIORB_BASE_CTOR workaround still works here diff -Naur cxx/skel/template.py cxx_patched/skel/template.py --- cxx/skel/template.py 2002-01-16 12:31:58.000000000 +0100 +++ cxx_patched/skel/template.py 2003-07-05 15:36:08.000000000 +0200 @@ -265,8 +265,8 @@ @fq_objref_name@::@objref_name@(omniIOR* ior, omniIdentity* id) : - @inherits_str@ omniObjRef(::@name@::_PD_repoId, ior, id, 1)@init_shortcut@ + @inherits_str@ { _PR_setobj(this); } --------------070603000900070206020800-- From mirko.cambi@bancaimi.it Fri Jul 18 12:13:48 2003 Received: from smtp.bancaimi.it ([62.128.65.14]) by omniorb-support.com with esmtp (Exim 4.14) id 19dTBM-0001Dd-2m for omniorb-dev@omniorb-support.com; Fri, 18 Jul 2003 12:13:48 +0100 Received: from dns1.imilan.it (mailhubout.bancaimi.it [62.128.65.2]) by smtp.bancaimi.it (8.12.8/8.12.8) with ESMTP id h6IAailE018119 for ; Fri, 18 Jul 2003 12:36:44 +0200 (MEST) Received: from milan5.bancaimi.it (lotussrv1.ux.imilan.it [172.16.98.118]) by dns1.imilan.it (8.11.2/8.11.2) with ESMTP id h6IAaaQ27901 for ; Fri, 18 Jul 2003 12:36:37 +0200 (MEST) To: omniorb-dev@omniorb-support.com X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: mirko.cambi@bancaimi.it Date: Fri, 18 Jul 2003 12:36:36 +0200 X-MIMETrack: Serialize by Router on Milan5/SRV/IMISIGECOSIM(Release 5.0.10 |March 22, 2002) at 07/18/2003 12:36:37 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [omniORB-dev] Omnievents 2.1.2 EventChannelFactory problem. X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2003 11:13:48 -0000 I'm tryng to use the omniEvents version 2.1.2 with omniOrb 4.0.1, I builded both on win2000. The name service run correctly, but when I try to use the event service, I got this error: "Cannot find event channel factory ! ["EventChannelFactory", "EventChannelFactory"]". Infact when I debug the program I got the exception when I try to narrow the factory. Below is the "standard" code that I copied from the examples in the omniEvents package. [...] // Obtain reference to the Event Channel Factory implementation. EventChannelAdmin::EventChannelFactory_ptr factory; CosNaming::Name name; name.length (1); name[0].id = CORBA::string_dup (factoryName.c_str()); name[0].kind = CORBA::string_dup (factoryKind.c_str()); try { CORBA::Object_var obj = rootContext->resolve(name); factory = EventChannelAdmin::EventChannelFactory::_narrow(obj); if (CORBA::is_nil(factory)) { throw pdg::Error(2, "Failed to narrow Event Channel Factory reference."); } } catch (CORBA::COMM_FAILURE& ex) { throw pdg::Error(3, "Caught system exception COMM_FAILURE, unable to contact the naming service."); } catch (omniORB::fatalException& ex) { throw pdg::Error(4, "Caught Fatal Exception"); } catch (...) { throw pdg::Error(5, "Cannot find event channel factory ! [\"" + factoryName + "\", \"" + factoryKind + "\"]"); } [...] does anyone have some suggests? Thank you, Mirko Cambi Product & Business Development - Banca IMI - Milan From bjensen@fastmail.fm Fri Jul 18 13:10:04 2003 Received: from out2.smtp.messagingengine.com ([66.111.4.26] helo=mail.messagingengine.com) by omniorb-support.com with esmtp (Exim 4.14) id 19dU3o-0001Xt-Bj for omniorb-dev@omniorb-support.com; Fri, 18 Jul 2003 13:10:04 +0100 Received: from mail.messagingengine.com (localhost [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 14B1C3CC09 for ; Fri, 18 Jul 2003 07:33:03 -0400 (EDT) Received: from 10.202.2.150 ([10.202.2.150] helo=mail.messagingengine.com) by messagingengine.com with SMTP; Fri, 18 Jul 2003 07:33:03 -0400 X-Epoch: 1058527983 X-Sasl-enc: AgiO3HxC7dLYhrJQhTHsHw Received: from fastmail.fm (x1-6-00-e0-81-03-b8-78.k34.webspeed.dk [195.41.44.129]) by www.fastmail.fm (Postfix) with ESMTP id 98F983C8DA for ; Fri, 18 Jul 2003 07:33:01 -0400 (EDT) Message-ID: <3F17DAE8.2060708@fastmail.fm> Date: Fri, 18 Jul 2003 13:32:56 +0200 From: bjorn rohde jensen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] Omnievents 2.1.2 EventChannelFactory problem. References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list Reply-To: bjensen@fastmail.fm List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2003 12:10:04 -0000 Hi there, My guess is, that the object reference registered in the name service is a stale reference, and the exception, you are getting is CORBA::TRANSIENT. The narrow operation causes the orb to try and establish a connection to an old instance of OmniEvents, which obviously fails. Its worth a check;) Yours sincerely, Bjorn From mirko.cambi@bancaimi.it Fri Jul 18 15:38:43 2003 Received: from smtp.bancaimi.it ([62.128.65.14]) by omniorb-support.com with esmtp (Exim 4.14) id 19dWNf-00021Q-NM for omniorb-dev@omniorb-support.com; Fri, 18 Jul 2003 15:38:43 +0100 Received: from dns0.imilan.it (mailhubout.bancaimi.it [62.128.65.2]) by smtp.bancaimi.it (8.12.8/8.12.8) with ESMTP id h6IE1clE026836 for ; Fri, 18 Jul 2003 16:01:38 +0200 (MEST) Received: from milan5.bancaimi.it (lotussrv1.ux.imilan.it [172.16.98.118]) by dns0.imilan.it (8.11.2/8.11.2) with ESMTP id h6IE1Wf09571 for ; Fri, 18 Jul 2003 16:01:32 +0200 (MEST) Subject: Re: [omniORB-dev] Omnievents 2.1.2 EventChannelFactory problem. To: omniorb-dev@omniorb-support.com X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: mirko.cambi@bancaimi.it Date: Fri, 18 Jul 2003 16:01:31 +0200 X-MIMETrack: Serialize by Router on Milan5/SRV/IMISIGECOSIM(Release 5.0.10 |March 22, 2002) at 07/18/2003 04:01:32 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2003 14:38:43 -0000 Thank you for your reply. The problem was a linking problem. When I added to my linker command the following objects: - CosLifeCycleSK.obj - EventChannelAdminSK.obj - CosEventChannelAdminSK.obj - CosEventCommSK.obj all has gone right. Best regards, Mirko. bjorn rohde jensen To: omniorb-dev@omniorb-support.com Sent by: cc: omniorb-dev-bounces@omniorb- Subject: Re: [omniORB-dev] Omnievents 2.1.2 EventChannelFactory problem. support.com 18-07-03 01:32 PM Please respond to bjensen Hi there, My guess is, that the object reference registered in the name service is a stale reference, and the exception, you are getting is CORBA::TRANSIENT. The narrow operation causes the orb to try and establish a connection to an old instance of OmniEvents, which obviously fails. Its worth a check;) Yours sincerely, Bjorn _______________________________________________ omniORB-dev mailing list omniORB-dev@omniorb-support.com http://www.omniorb-support.com/mailman/listinfo/omniorb-dev Mirko Cambi Product & Business Development - Banca IMI - Milan From kwooten@itracs.com Wed Jul 30 19:25:15 2003 Received: from 67.106.230.34.ptr.us.xo.net ([67.106.230.34] helo=elcorreo2.vegas.itracs.com) by omniorb-support.com with esmtp (Exim 4.14) id 19hvdS-0008En-Nv for omniorb-dev@omniorb-support.com; Wed, 30 Jul 2003 19:25:14 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C356C7.B89147EE" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 30 Jul 2003 11:23:49 -0700 Message-ID: <0D2BEB28DE931148A970F8A8F9FCA64A06F081@elcorreo2.vegas.itracs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SCons build system revisited... Thread-Index: AcNWx7iIVgztENSrTkCJ02PMyW5WzA== From: "Kevin Wooten" To: Subject: [omniORB-dev] SCons build system revisited... X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2003 18:25:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C356C7.B89147EE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I just wanted to give an update on the SCons build system that was discussed a couple of months ago...I know some others were also investigating so I hope they can provide some feedback. I hate to say it but SCons seems to be well suited for single directory projects, and imposes a lot of rules on building things the way it wants. First I tried SConf + SCons. SConf is the "autoconf" for SCons that was recently added. This was a complete failure, especially when trying to add in a directory that may or may not be there (omniPython). So then I tried Autoconf + SCons, the build directories seemed to be to harshly regulated, especially since omniORB already has its own "style". Also, SCons's install features seem to currently be severely lacking. With all that said, I still like SCons a lot and I hope that in the future these limitations (as I see them), can be removed, because it is nice using one language across configuration, build and installation, instead of two, three or more as is the case with autoconf & automake. I would very much like to here others opinions on this! As a side note, another project has forced me to (finally!) become very familiar with autoconf & automake. I found it very easy to create builds that are flexible and require a very small amount of input. If someone feels the current build system needs repair, might I suggest cleaning up the configure.ac, and replacing all the makefile handiwork with automake makefiles. I am still very much willing to help. One suggestion I have immediately is to put the __(platform)__ and __(architecture)__ defines in the omni config.h. Lastly, I would like to say, I don't like libtool. As I reread this it seems I am making a case FOR auto* instead of against SCons; so I thought I would throw that in. Although, my dislike may only come from a lack of understanding why it does what it does. Cheers, kw ------_=_NextPart_001_01C356C7.B89147EE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable SCons build system revisited...

I = just wanted to give an update on the SCons build system that was = discussed a couple of months ago…I know some others were = also investigating so I hope they can provide some = feedback.

I = hate to say it but SCons seems to be well suited for single directory = projects, and imposes a lot of rules on building things the way it = wants. First I tried SConf + = SCons. SConf is the “autoconf” for SCons that was = recently added. This was a complete failure, especially when trying to = add in a = directory that may or may not be there (omniPython). So then I tried Autoconf + SCons, the = build directories seemed to be to harshly regulated, especially since omniORB already has its own “style”. Also, SCons’s install features seem to = currently be severely lacking. With all that said, I still like SCons a lot = and I hope that in the future these limitations (as I see them), can be = removed, because it is nice using = one language across configuration, build and installation, instead = of two, three or more as is the case with autoconf = & automake. I would very much like to = here others opinions on this!

As a = side note, another project has forced = me to = (finally!) become very familiar with autoconf & automake. I found it = very easy to create builds that are flexible = and require a very small amount of input. If someone feels the current = build system needs repair, might I suggest cleaning up the configure.ac, and replacing all the makefile handiwork = with automake makefiles. I am = still = very much willing to help. One suggestion I have immediately is to put the = __(platform)__ and __(architecture)__ defines in the omni config.h.

Lastly, I would like to say, I don’t like libtool. As I reread = this it seems I am making a case FOR auto* = instead of against = SCons; so I thought I would throw that in. Although, my dislike = may only come from a lack of understanding why it = does what it does.

Cheers,

kw

------_=_NextPart_001_01C356C7.B89147EE-- From Coleman.Corrigan@traventec.com Wed Sep 10 10:51:41 2003 Received: from [193.120.171.248] (helo=startgwyex01.traventec.com) by omniorb-support.com with esmtp (Exim 4.14) id 19x1dV-0001du-H5 for omniorb-dev@omniorb-support.com; Wed, 10 Sep 2003 10:51:41 +0100 Received: by STARTGWYEX01 with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Sep 2003 10:46:30 +0100 Message-ID: <08C15F38C433D711BDA100508B0BF5DD05BEC8@STARTGWYEX01> From: Corrigan Coleman To: "'omniorb-dev@omniorb-support.com'" Date: Wed, 10 Sep 2003 10:46:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [omniORB-dev] FW: codeset conversions. X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2003 09:51:41 -0000 > -----Original Message----- > From: Corrigan Coleman > Sent: 10 September 2003 10:42 > To: 'omniorb-dev@omniorb-support.com.' > Cc: 'duncan@grisby.org' > Subject: codeset conversions. > > Hello all, > why are Call descriptors are marshalled as strings ? should they not > be codeset independent ?. > > This is causing me a problem as I'm using EBCDIC codesets. > > If I try to use a corbaloc uri for the namespace the calldescriptor gets > marshalled wrong. > > Here's the logfile, from a nameclt call > > omniORB: (0) Distribution date: " OMNIORB_DIST_DATE " > omniORB: (0) My addresses are: > omniORB: 127.0.0.1 > omniORB: 172.23.4.102 > omniORB: 172.23.4.103 > omniORB: 172.24.52.146 > omniORB: 192.168.10.10 > omniORB: 192.168.10.42 > omniORB: 193.23.187.76 > omniORB: (0) Maximum supported GIOP version is 1.2 > omniORB: (0) Native char code sets: SNI-EDF-4 UTF-8 ISO-8859-1. > omniORB: (0) Transmission char code sets: SNI-EDF-4(1.2) SNI-EDF-4(1.1) > SNI-EDF-4(1.0) UTF-8(1.2) ISO-8859-1(1.2) ISO-8859-1(1.1) ISO-8859-1(1.0). > omniORB: (0) Native wide char code sets: UTF-16. > omniORB: (0) Transmission wide char code sets: UTF-16(1.2). > omniORB: (0) Information: the omniDynamic library is not linked. > omniORB: (0) Current configuration is as follows: > omniORB: DefaultInitRef = > omniORB: InitRef = NameService=corbaname::1.2@TED10: > omniORB: abortOnInternalError = 1 > omniORB: acceptBiDirectionalGIOP = 0 > omniORB: acceptMisalignedTcIndirections = 0 > omniORB: bootstrapAgentHostname = > omniORB: bootstrapAgentPort = 900 > omniORB: clientCallTimeOutPeriod = 10000 > omniORB: clientTransportRule = * unix,ssl,tcp > omniORB: diiThrowsSysExceptions = 0 > omniORB: dumpConfiguration = 0 > omniORB: endPoint = giop:tcp:: > omniORB: endPointPublishAllIFs = 0 > omniORB: giopMaxMsgSize = 2097152 > omniORB: giopTargetAddressMode = KeyAddr > omniORB: id = omniORB4 > omniORB: inConScanPeriod = 180 > omniORB: lcdMode = 0 > omniORB: maxGIOPConnectionPerServer = 5 > omniORB: maxGIOPVersion = 1.2 > omniORB: maxInterleavedCallsPerConnection = 5 > omniORB: maxServerThreadPerConnection = 100 > omniORB: maxServerThreadPoolSize = 100 > omniORB: nativeCharCodeSet = SNI-EDF-4 > omniORB: nativeWCharCodeSet = UTF-16 > omniORB: objectTableSize = 0 > omniORB: offerBiDirectionalGIOP = 0 > omniORB: omniORB_27_CompatibleAnyExtraction = 0 > omniORB: oneCallPerConnection = 1 > omniORB: outConScanPeriod = 120 > omniORB: poaHoldRequestTimeout = 0 > omniORB: poaUniquePersistentSystemIds = 1 > omniORB: principal = [Null] > omniORB: scanGranularity = 5 > omniORB: serverCallTimeOutPeriod = 0 > omniORB: serverTransportRule = * unix,ssl,tcp > omniORB: strictIIOP = 1 > omniORB: supportBootstrapAgent = 0 > omniORB: supportCurrent = 1 > omniORB: supportPerThreadTimeOut = 0 > omniORB: tcAliasExpand = 0 > omniORB: threadPerConnectionLowerLimit = 9000 > omniORB: threadPerConnectionPolicy = 1 > omniORB: threadPerConnectionUpperLimit = 10000 > omniORB: threadPoolWatchConnection = 1 > omniORB: traceInvocations = 1 > omniORB: traceLevel = 40 > omniORB: traceThreadId = 1 > omniORB: unixTransportDirectory = /tmp/omni-%u > omniORB: unixTransportPermission = 777 > omniORB: useTypeCodeIndirections = 1 > omniORB: verifyObjectExistsAndType = 0 > omniORB: (0) Creating ref to remote: key<0x4e616d6553657276696365> > target id : IDL:omg.org/CORBA/Object:1.0 > most derived id: > omniORB: (0) Initial reference `NameService' resolved from configuration > file. > omniORB: (0) Invoke '_is_a' on remote: key<0x4e616d6553657276696365> > omniORB: (0) Client opened connection to giop:tcp:192.168.232.41:2809 > omniORB: (0) sendChunk: to giop:tcp:192.168.232.41:2809 120 bytes > omniORB: (0) > 4749 4f50 0102 0000 0000 006c 0000 0002 GIOP.......l.... > 0300 0000 0000 d9c2 0000 000b 4e61 6d65 ............Name > 5365 7276 6963 65c2 0000 0006 5f69 735f Service....._is_ > 6100 d385 0000 0000 0000 003c c3b1 c3a0 a..........<.... > 3cc2 9a3f 5fc3 8506 3fc3 8ac3 8507 c3a4 <..?_...?....... > 3fc3 8b2b 2f5f c391 3ec3 8507 2b2f 5fc3 ?..+/_..>...+/_. > 913e c385 c3a4 3f3e c388 c381 c38c c388 .>....?>........ > c29a c291 06c2 9000 ........ > omniORB: (0) Sending 120Bytes > omniORB: (0) Send returned 120 > omniORB: (0) inputMessage: from giop:tcp:192.168.232.41:2809 25 bytes > omniORB: (0) > 4749 4f50 0102 0001 0000 000d 0000 0002 GIOP............ > 0000 0000 0000 0000 00 ......... > NameService object reference was not a NamingContext. > omniORB: (0) ORB not destroyed; no final clean-up. > > > Thanks, > Coleman Corrigan, > Application Delivery, > Traventec, > Galway Business Park, > Dangan, > Galway, > Ireland. > > * +353 (0)91 518 798 > Fax: +353 (0)91 525056 > * coleman.corrigan@traventec.com > Web: http://www.traventec.com > > ************************************************************************ This e-mail and any files transmitted with it are confidential and may be privileged and are intended solely for the individual named/ for the use of the individual or entity to whom they are addressed.If you are not the intended addressee, you should not disseminate, distribute or copy this e-mail.Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system.If you are not the intended recipient, you are notified that reviewing, disclosing, copying, distributing or taking any action in reliance on the contents of this e-mail is strictly prohibited.Please note that any views or opinions expressed in this e-mail are solely those of the author and do not necessarily represent those of Traventec Limited.E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, or arrive late or incomplete.Traventec Limited therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.The recipient should check this e-mail and any attachments for the presence of viruses.This e-mail has been swept for computer viruses however Traventec Limited accepts no liability for any damage caused by any virus transmitted by this e-mail. From duncan@grisby.org Mon Sep 15 15:27:34 2003 Received: from pc1-cmbg4-5-cust104.cmbg.cable.ntl.com ([81.96.72.104] helo=grisby.dyndns.org) by omniorb-support.com with esmtp (Exim 4.14) id 19yuKE-000168-BT; Mon, 15 Sep 2003 15:27:34 +0100 Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id h8FERWh17941; Mon, 15 Sep 2003 15:27:33 +0100 Message-Id: <200309151427.h8FERWh17941@grisby.dyndns.org> X-Authentication-Warning: pc1-cmbg4-5-cust104.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: Corrigan Coleman In-Reply-To: Message from Corrigan Coleman of "Wed, 10 Sep 2003 10:41:36 BST." <08C15F38C433D711BDA100508B0BF5DD05BEC7@STARTGWYEX01> From: Duncan Grisby Date: Mon, 15 Sep 2003 15:27:32 +0100 Cc: "'omniorb-dev@omniorb-support.com.'" Subject: [omniORB-dev] Re: codeset conversions. X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2003 14:27:34 -0000 On Wednesday 10 September, Corrigan Coleman wrote: > why are Call descriptors are marshalled as strings ? should they not > be codeset independent ?. You don't mean call descriptors. The thing that isn't being marshalled properly is a repository id. The code to marshal them was incorrectly sending them as translated strings, so the ORB was attempting to convert them from EBCDIC to ASCII, despite the fact that they were already ASCII. I've checked in a fix. Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From Harri.Pasanen@trema.com Tue Sep 16 15:00:50 2003 Received: from firewall.labs.trema.com ([212.157.192.221] helo=labex1.corp.trema.com) by omniorb-support.com with esmtp (Exim 4.14) id 19zGNu-0003bg-Hq for omniorb-dev@omniorb-support.com; Tue, 16 Sep 2003 15:00:50 +0100 Received: from dell-harri.corp.trema.com ([172.24.16.159]) by labex1.corp.trema.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 16 Sep 2003 16:00:19 +0200 From: Harri Pasanen To: omniorb-dev@omniorb-support.com Date: Tue, 16 Sep 2003 16:00:19 +0200 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_zdxZ/HVSbPfj7P/" Message-Id: <200309161600.19681.harri.pasanen@trema.com> X-OriginalArrivalTime: 16 Sep 2003 14:00:19.0974 (UTC) FILETIME=[DD643A60:01C37C5A] Subject: [omniORB-dev] Enhancement proposal to cxxAPI in omniORBpy X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2003 14:00:50 -0000 --Boundary-00=_zdxZ/HVSbPfj7P/ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, Yesterday I posted to omniorb list about a deadlock / hanging threads when doing a python extension that calls CORBA::ORB_init from C++. The problem stemmed from that fact that cxxAPI will call ORB_init again, as omniPy::orb is not initialized. I propose a new function to cxxAPI, called cxxSetOmniPyORB(CORBA::ORB_ptr). This could be used in the situation where an existing non-omniORBpy aware orb needs to be used. I've included the patches here. These are quite minimal, and don't modify existing functionality, only add to it. Let me know what you think. Regards, Harri --Boundary-00=_zdxZ/HVSbPfj7P/ Content-Type: text/x-diff; charset="us-ascii"; name="omniORBpy-h.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="omniORBpy-h.patch" Index: include/omniORBpy.h =================================================================== RCS file: /trema/cvs/fk/tools/omniorb/src/lib/omniORBpy/include/omniORBpy.h,v retrieving revision 1.2 diff -c -r1.2 omniORBpy.h *** include/omniORBpy.h 11 Apr 2003 12:57:09 -0000 1.2 --- include/omniORBpy.h 16 Sep 2003 13:56:52 -0000 *************** *** 52,57 **** --- 52,58 ---- struct omniORBpyAPI { + void (*cxxSetOmniPyORB)(CORBA::ORB_ptr orb); PyObject* (*cxxObjRefToPyObjRef)(const CORBA::Object_ptr cxx_obj, CORBA::Boolean hold_lock); --Boundary-00=_zdxZ/HVSbPfj7P/ Content-Type: text/x-diff; charset="us-ascii"; name="cxxAPI.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="cxxAPI.patch" Index: modules/cxxAPI.cc =================================================================== RCS file: /trema/cvs/fk/tools/omniorb/src/lib/omniORBpy/modules/cxxAPI.cc,v retrieving revision 1.1 diff -c -r1.1 cxxAPI.cc *** modules/cxxAPI.cc 3 Dec 2002 10:42:12 -0000 1.1 --- modules/cxxAPI.cc 16 Sep 2003 13:56:26 -0000 *************** *** 70,75 **** --- 70,80 ---- return omniPy::createPyCorbaObjRef(0, py_obj); } + static void impl_cxxSetOmniPyORB(CORBA::ORB_ptr orb) + { + OMNIORB_ASSERT(omniPy::orb == 0); + omniPy::orb = orb; + } static PyObject* *************** *** 128,136 **** } } - omniORBpyAPI::omniORBpyAPI() ! : cxxObjRefToPyObjRef(impl_cxxObjRefToPyObjRef), pyObjRefToCxxObjRef(impl_pyObjRefToCxxObjRef) {} --- 133,141 ---- } } omniORBpyAPI::omniORBpyAPI() ! : cxxSetOmniPyORB(impl_cxxSetOmniPyORB), ! cxxObjRefToPyObjRef(impl_cxxObjRefToPyObjRef), pyObjRefToCxxObjRef(impl_pyObjRefToCxxObjRef) {} --Boundary-00=_zdxZ/HVSbPfj7P/-- From kwooten@itracs.com Wed Sep 17 22:48:44 2003 Received: from 67.106.230.34.ptr.us.xo.net ([67.106.230.34] helo=elcorreo2.vegas.itracs.com) by omniorb-support.com with esmtp (Exim 4.14) id 19zkAG-0004xA-P9 for omniorb-dev@omniorb-support.com; Wed, 17 Sep 2003 22:48:44 +0100 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 17 Sep 2003 14:48:13 -0700 Message-ID: <0D2BEB28DE931148A970F8A8F9FCA64A06F084@elcorreo2.vegas.itracs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: omniORBpy and an Interface Repository Thread-Index: AcN8WvF0nIguX/asS+uDE45jFcRq9ABCZhaA From: "Kevin Wooten" To: Subject: [omniORB-dev] omniORBpy and an Interface Repository X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2003 21:48:45 -0000 Hello, This is a question probably aimed at Duncan, but any input is appreciated.=20 Does CORBA have a spec. for getting IDL definitions from an interface repository? I am interested in the ability for omniORBpy to connect to an IR and "download" some definitions to use. I know it does not support that natively but I am going to add something like it. I am just gathering input and wondering if OMG has already thought of this (since I am not very familiar with the myriad of specs they have). As far as implementation goes; would the best way be to copy, or use, the omniORBpy's dynamic compilation to get definitions into a running system? Thanks, Kevin From lockhart@fourpalms.org Wed Sep 17 23:34:34 2003 Received: from dhcp-78-180-254.jpl.nasa.gov ([137.78.180.254] helo=myst.fourpalms.org) by omniorb-support.com with esmtp (Exim 4.14) id 19zksc-0004yL-JJ for omniorb-dev@omniorb-support.com; Wed, 17 Sep 2003 23:34:34 +0100 Received: from fourpalms.org (localhost.localdomain [127.0.0.1]) by myst.fourpalms.org (Postfix) with ESMTP id 88BF834113E6; Wed, 17 Sep 2003 15:34:18 -0700 (PDT) Message-ID: <3F68E16A.1010707@fourpalms.org> Date: Wed, 17 Sep 2003 15:34:18 -0700 From: Thomas Lockhart Organization: No User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Wooten Subject: Re: [omniORB-dev] omniORBpy and an Interface Repository References: <0D2BEB28DE931148A970F8A8F9FCA64A06F084@elcorreo2.vegas.itracs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: omniorb-dev@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2003 22:34:34 -0000 ... > Does CORBA have a spec. for getting IDL definitions from an interface > repository? I am interested in the ability for omniORBpy to connect to > an IR and "download" some definitions to use. I know it does not support > that natively but I am going to add something like it. I am just > gathering input and wondering if OMG has already thought of this (since > I am not very familiar with the myriad of specs they have). I don't know, but wanted to mention that afaicr Combat uses this technique for its tcl interfaces. - Tom From renej.frog@yucom.be Thu Sep 18 08:44:52 2003 Received: from apate.telenet-ops.be ([195.130.132.57]) by omniorb-support.com with esmtp (Exim 4.14) id 19ztTA-00056w-QM for omniorb-dev@omniorb-support.com; Thu, 18 Sep 2003 08:44:52 +0100 Received: from localhost (localhost.localdomain [127.0.0.1]) by apate.telenet-ops.be (Postfix) with SMTP id 8A18E37F0C for ; Thu, 18 Sep 2003 09:44:52 +0200 (MEST) Received: from fnsnb40.jati.lan (d5153152F.kabel.telenet.be [81.83.21.47]) by apate.telenet-ops.be (Postfix) with ESMTP id 528F437E4D for ; Thu, 18 Sep 2003 09:44:52 +0200 (MEST) Subject: Re: [omniORB-dev] omniORBpy and an Interface Repository From: Rene Jager To: omniorb-dev@omniorb-support.com In-Reply-To: <3F68E16A.1010707@fourpalms.org> References: <0D2BEB28DE931148A970F8A8F9FCA64A06F084@elcorreo2.vegas.itracs.com> <3F68E16A.1010707@fourpalms.org> Content-Type: text/plain Message-Id: <1063871091.2741.2.camel@fnsnb40.jati.lan> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Thu, 18 Sep 2003 09:44:51 +0200 Content-Transfer-Encoding: 7bit X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2003 07:44:52 -0000 On Thu, 2003-09-18 at 00:34, Thomas Lockhart wrote: > ... > > Does CORBA have a spec. for getting IDL definitions from an interface > > repository? I am interested in the ability for omniORBpy to connect to > > an IR and "download" some definitions to use. I know it does not support > > that natively but I am going to add something like it. I am just > > gathering input and wondering if OMG has already thought of this (since > > I am not very familiar with the myriad of specs they have). > > I don't know, but wanted to mention that afaicr Combat uses this > technique for its tcl interfaces. it's in the CORBA spec (related to DII), see "ir.idl" delivered with omniORB renej > > - Tom > > > _______________________________________________ > omniORB-dev mailing list > omniORB-dev@omniorb-support.com > http://www.omniorb-support.com/mailman/listinfo/omniorb-dev From duncan@grisby.org Fri Sep 19 16:44:05 2003 Received: from pc1-cmbg4-5-cust104.cmbg.cable.ntl.com ([81.96.72.104] helo=grisby.dyndns.org) by omniorb-support.com with esmtp (Exim 4.14) id 1A0NQT-0006SV-Eq; Fri, 19 Sep 2003 16:44:05 +0100 Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id h8JFi3P31049; Fri, 19 Sep 2003 16:44:04 +0100 Message-Id: <200309191544.h8JFi3P31049@grisby.dyndns.org> X-Authentication-Warning: pc1-cmbg4-5-cust104.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: "Kevin Wooten" Subject: Re: [omniORB-dev] omniORBpy and an Interface Repository In-Reply-To: Message from "Kevin Wooten" of "Wed, 17 Sep 2003 14:48:13 PDT." <0D2BEB28DE931148A970F8A8F9FCA64A06F084@elcorreo2.vegas.itracs.com> From: Duncan Grisby Date: Fri, 19 Sep 2003 16:44:03 +0100 Cc: omniorb-dev@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2003 15:44:05 -0000 On Wednesday 17 September, "Kevin Wooten" wrote: > Does CORBA have a spec. for getting IDL definitions from an interface > repository? No. Various things related to DII and DSI talk about it, but not in a way that's useful to you, I think. > I am interested in the ability for omniORBpy to connect to > an IR and "download" some definitions to use. I know it does not support > that natively but I am going to add something like it. I am just > gathering input and wondering if OMG has already thought of this (since > I am not very familiar with the myriad of specs they have). > > As far as implementation goes; would the best way be to copy, or use, > the omniORBpy's dynamic compilation to get definitions into a running > system? The way omniORB.importIDL works is to fork omniidl, and dynamically import its output. I can think of three ways to implement what you want: 1. generate IDL from the contents of the IfR, then import it with importIDL(). 2. generate suitable Python code, equivalent to that created by omniidl, and import that. 3. dynamically build Python classes and data structures (mainly type descriptor tuples) directly, rather than generating strings. Option 1 would be by far the easiest, since it's well defined what the output should be, and the output is relatively simple. It would also be useful