Re: [C++] Python extension available
Andrew Borley wrote: [snip] That sounds good - unfortunately Windows doesn't support sym links, so we have to have a slightly different process. The current build creates TuscanySCA.dll from TuscanySCAModule.cpp only and puts it and TuscanySCAProxy.py into extensions/python/bin. Ok, I can change the build back to reflect that on Linux: - libtuscany_sca_python.so will contain the core of the code. - SCA.so will be built from TuscanySCAModule.cpp to contribute the python module definition. I think it's better to keep things in sync between Windows and Linux. Is that OK? If a user wants to install the Python module lib into /usr/lib/python/site-packages and get TuscanSCAProxy pre-compiled then he can still run a setup -install script. Do you think we should package TuscanySCASetup.py in the distro and where do you think it should go? extensions/python/bin? anywhere else? I think extensions/python/bin would be the right place - we may also need a .sh file to run TuscanySCASetup.py in the right way - so it can find the compiled library and scripts. Alternatively, what we could do for binary releases is use the bdist_rpm option in the build to create an installable RPM containing the library and extension. There is a bdist_wininst option that does something similar on windows. Lastly, I think it would nice if we could name the module just sca and leave the Tuscany out (like we do in CPP, Java etc.). The client API would be sca.locateService(...). Also I looked at other python packages and most of them seem to be lowercase so that's why I'm proposing sca instead of SCA like we have in Ruby (where module names start with an uppercase letter). What do you think? Yep, I'm good with that too. You don't think it's a bit presumptious to say sca on Python == Tuscany? Let's do it and see when/if people complain ;-) Yes, I think we provide an implementation of an SCA API. The API does not say Tuscany, it just says SCA. People who want the Tuscany implementation of the API load the Tuscany libraries and modules. People who want another implementation will load that particular library. What do you think? Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Properties and references in Python components, was: [C++] Python extension available
On 9/15/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Andrew Borley wrote: [snip] In other news, I have just added in support for properties to the Python extension: - A composite with a property defined in a component and the associated .componentType file: component name=DivideComponent implementation.python module=DivideImpl scope=composite/ property name=doRoundingtrue/property /component componentType ... property name=doRounding type=xsd:boolean/ /componentType Is automatically instantiated and assigned the property value in the python implementation module: def divide(val1, val2): result = float(val1) / float(val2) print Python - DivideImpl.divide + str(val1) + / + str(val2) + = + str(result) # Use the doRounding property if doRounding: result = round(result) print Python - DivideImpl.divide is rounding the result to + str(result) return result Cheers Andy Andy, this is nice. What do you think about going just one small step further to make ComponentType definitions optional, and basically define the Python variable automatically when it is configured as a property or a reference on the component definition? As a scripting developer I am not used to declare my variables ahead of time, they are just created automatically once I assign a value to them. Doing this would be in the same spirit: you get a variable created for you when you configure/assign its value on the component declaration and the scripting developer does not need to write ComponentType files to declare things that he usually doesn't like to declare... +1 for this. I don't really get why we need the .componentType file when the info is already in the .composite. This would just require a small change to ModelLoader.cpp and your PythonImplementation.cpp, for references we would do the following: - ModelLoader would call a new needReferenceType(name) method or a findReferenceType(string name, createNew=true) method on the ComponentType (your PythonImplementation) and in this method you would create the ReferenceType. - We would follow a similar scheme for properties. I had started to implement that scheme for Ruby (see RubyImplementation::findReferenceType() in revision r442461 or RubyImplementation.cpp) then backed it out as in Ruby you usually declare your public attributes/properties. But I think that this would apply well to languages like Python and Javascript. Let me know what you think. It sounds good to me - do you have time to implement this? If not I'll have a go - I didn't want to touch any of the core code for the extension, but I don't mind getting stuck in :) Cheers Andy
Re: [C++] Python extension available
On 9/16/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Andrew Borley wrote: Good to hear you got it going! :-) To answer your questions: On 9/13/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Jean-Sebastien Delfino wrote: Andy, I got your Python library building on Linux. It's pretty cool and I'm now trying to integrate the building of TuscanySCA.so, but I have a few quick questions: - TuscanySCASetup.py build just seems to do a normal compile, do I need to use it, or do you think that I can just get TuscanySCAModule.cpp compiled with the other .cpp in the same directory by just adding it to the list of .cpp files in Makefile.am? - TuscanySCASetup install wants to install under /usr/lib/python.../site-packages. This only works for the root user, and more generally looks like it should be run as part of the install of the Tuscany distribution, instead of the build. Does it do anything else than copying files to site-packages? Is there a way to tell the python interpreter where to find additional modules in addition to the /usr/lib/python.../site-packages? Do you think we could just distribute TuscanySCA.so and the TuscanyProxy.py under the tuscany distribution directory, and then ask Python application developers to just add that dir to their python path or something like that? - Is there a particular reason for having two separate .so files libtuscany_sca_python.so and TuscanySCA.so? or could these two be combined in a single .so file? It looks like python loads the module when it finds an 'import TuscanySCA' statement in the script. Python looks on the PYTHONPATH envronment variable for either a TuscanySCA.py script, a TuscanySCA.pyc compiled script or a TuscanySCA.dll (or .pyd on Windows and .so on Linux). If it finds a library, python then finds and invokes the initTuscanySCA exported method which sets up the methods, and variables available in the module. So the answer to your 1st and 3rd questions is that the TuscanySCASetup.pybuild just compiles the TuscanySCAModule.cpp file, and depends on the tuscany_sca_python.lib (libtuscany_sca_python.so on Linux) being pre-built. We could compile all the extension code into a single library, but it would need to be named TuscanySCA.dll (or TuscanySCA.so) for import TuscanySCA to work. We could rename the module to tuscany_sca_python (e.g. import tuscany_sca_python) and build a single tuscany_sca_python.dll or tuscany_sca_python.so, but the runtime currently depends on extension libraries on linux being named libLibraryName.so so I don't know if it would work. What happens on Linux if you rename TuscanySCA.so to libTuscanySCA.so? Can python still find the module? The answer to your 2nd question is that we can install the TuscanySCA.so and the TuscanySCAProxy.py to a different directory (I didn't realise /usr/lib/python.../site-packages would be root only on Linux) using a command like: python TuscanySCASetup.py install --install-lib $TUSCANY_SCACPP/extensions/python/lib and then get users to add $TUSCANY_SCACPP/extensions/python/lib to their PYTHONPATH. I have updated the build files and PythonCalculator sample on Windows and Linux to do this. Andy, Besides the build integration related questions above, I confirm that your Python extension works great on Linux (tested on Redhat Enterprise Linux 4). The only change I had to make was to remove an include of ...cpp/model/CPPInterface.h in PythonServiceProxy.cpp. I committed that small fix under revision r443083. Nice! Great! Glad to hear it worked OK :) In other news, I have just added in support for properties to the Python extension: - A composite with a property defined in a component and the associated .componentType file: component name=DivideComponent implementation.python module=DivideImpl scope=composite/ property name=doRoundingtrue/property /component componentType ... property name=doRounding type=xsd:boolean/ /componentType Is automatically instantiated and assigned the property value in the python implementation module: def divide(val1, val2): result = float(val1) / float(val2) print Python - DivideImpl.divide + str(val1) + / + str(val2) + = + str(result) # Use the doRounding property if doRounding: result = round(result) print Python - DivideImpl.divide is rounding the result to + str(result) return result Cheers Andy Andy, I adjusted the Linux Automake build to integrate your Python extension as follows: - TuscanySCAModule.cpp is now built into libtuscany_sca_python.so. - The make install creates a symbolic link TuscanySCA.so - libtuscany_sca_python.so. - TuscanySCAProxy.py is now distributed beside the library in extensions/python/lib. - Users can point their PYTHONPATH to extensions/python/lib, I added that setting to the runclient script. This
Re: Properties and references in Python components, was: [C++] Python extension available
Andrew Borley wrote: On 9/15/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Andrew Borley wrote: [snip] In other news, I have just added in support for properties to the Python extension: - A composite with a property defined in a component and the associated .componentType file: component name=DivideComponent implementation.python module=DivideImpl scope=composite/ property name=doRoundingtrue/property /component componentType ... property name=doRounding type=xsd:boolean/ /componentType Is automatically instantiated and assigned the property value in the python implementation module: def divide(val1, val2): result = float(val1) / float(val2) print Python - DivideImpl.divide + str(val1) + / + str(val2) + = + str(result) # Use the doRounding property if doRounding: result = round(result) print Python - DivideImpl.divide is rounding the result to + str(result) return result Cheers Andy Andy, this is nice. What do you think about going just one small step further to make ComponentType definitions optional, and basically define the Python variable automatically when it is configured as a property or a reference on the component definition? As a scripting developer I am not used to declare my variables ahead of time, they are just created automatically once I assign a value to them. Doing this would be in the same spirit: you get a variable created for you when you configure/assign its value on the component declaration and the scripting developer does not need to write ComponentType files to declare things that he usually doesn't like to declare... +1 for this. I don't really get why we need the .componentType file when the info is already in the .composite. Yes, ComponentTypes are very similar to Classes (and Components to Objects) so they make most sense when you work with a OO language with Classes and Objects. In your Python scripting environment you can define properties directly on Objects so ComponentTypes are less useful. This would just require a small change to ModelLoader.cpp and your PythonImplementation.cpp, for references we would do the following: - ModelLoader would call a new needReferenceType(name) method or a findReferenceType(string name, createNew=true) method on the ComponentType (your PythonImplementation) and in this method you would create the ReferenceType. - We would follow a similar scheme for properties. I had started to implement that scheme for Ruby (see RubyImplementation::findReferenceType() in revision r442461 or RubyImplementation.cpp) then backed it out as in Ruby you usually declare your public attributes/properties. But I think that this would apply well to languages like Python and Javascript. Let me know what you think. It sounds good to me - do you have time to implement this? If not I'll have a go - I didn't want to touch any of the core code for the extension, but I don't mind getting stuck in :) Cheers Andy Great. I can help if you have any questions but if you are interested in digging into the core code please feel free to go ahead and make the changes you need :) The more people know the core code the better IMO. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Properties and references in Python components, was: [C++] Python extension available
Andrew Borley wrote: [snip] In other news, I have just added in support for properties to the Python extension: - A composite with a property defined in a component and the associated .componentType file: component name=DivideComponent implementation.python module=DivideImpl scope=composite/ property name=doRoundingtrue/property /component componentType ... property name=doRounding type=xsd:boolean/ /componentType Is automatically instantiated and assigned the property value in the python implementation module: def divide(val1, val2): result = float(val1) / float(val2) print Python - DivideImpl.divide + str(val1) + / + str(val2) + = + str(result) # Use the doRounding property if doRounding: result = round(result) print Python - DivideImpl.divide is rounding the result to + str(result) return result Cheers Andy Andy, this is nice. What do you think about going just one small step further to make ComponentType definitions optional, and basically define the Python variable automatically when it is configured as a property or a reference on the component definition? As a scripting developer I am not used to declare my variables ahead of time, they are just created automatically once I assign a value to them. Doing this would be in the same spirit: you get a variable created for you when you configure/assign its value on the component declaration and the scripting developer does not need to write ComponentType files to declare things that he usually doesn't like to declare... This would just require a small change to ModelLoader.cpp and your PythonImplementation.cpp, for references we would do the following: - ModelLoader would call a new needReferenceType(name) method or a findReferenceType(string name, createNew=true) method on the ComponentType (your PythonImplementation) and in this method you would create the ReferenceType. - We would follow a similar scheme for properties. I had started to implement that scheme for Ruby (see RubyImplementation::findReferenceType() in revision r442461 or RubyImplementation.cpp) then backed it out as in Ruby you usually declare your public attributes/properties. But I think that this would apply well to languages like Python and Javascript. Let me know what you think. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Python extension available
Good to hear you got it going! :-) To answer your questions: On 9/13/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Jean-Sebastien Delfino wrote: Andy, I got your Python library building on Linux. It's pretty cool and I'm now trying to integrate the building of TuscanySCA.so, but I have a few quick questions: - TuscanySCASetup.py build just seems to do a normal compile, do I need to use it, or do you think that I can just get TuscanySCAModule.cpp compiled with the other .cpp in the same directory by just adding it to the list of .cpp files in Makefile.am? - TuscanySCASetup install wants to install under /usr/lib/python.../site-packages. This only works for the root user, and more generally looks like it should be run as part of the install of the Tuscany distribution, instead of the build. Does it do anything else than copying files to site-packages? Is there a way to tell the python interpreter where to find additional modules in addition to the /usr/lib/python.../site-packages? Do you think we could just distribute TuscanySCA.so and the TuscanyProxy.py under the tuscany distribution directory, and then ask Python application developers to just add that dir to their python path or something like that? - Is there a particular reason for having two separate .so files libtuscany_sca_python.so and TuscanySCA.so? or could these two be combined in a single .so file? It looks like python loads the module when it finds an 'import TuscanySCA' statement in the script. Python looks on the PYTHONPATH envronment variable for either a TuscanySCA.py script, a TuscanySCA.pyc compiled script or a TuscanySCA.dll (or .pyd on Windows and .so on Linux). If it finds a library, python then finds and invokes the initTuscanySCA exported method which sets up the methods, and variables available in the module. So the answer to your 1st and 3rd questions is that the TuscanySCASetup.pybuild just compiles the TuscanySCAModule.cpp file, and depends on the tuscany_sca_python.lib (libtuscany_sca_python.so on Linux) being pre-built. We could compile all the extension code into a single library, but it would need to be named TuscanySCA.dll (or TuscanySCA.so) for import TuscanySCA to work. We could rename the module to tuscany_sca_python (e.g. import tuscany_sca_python) and build a single tuscany_sca_python.dll or tuscany_sca_python.so, but the runtime currently depends on extension libraries on linux being named libLibraryName.so so I don't know if it would work. What happens on Linux if you rename TuscanySCA.so to libTuscanySCA.so? Can python still find the module? The answer to your 2nd question is that we can install the TuscanySCA.so and the TuscanySCAProxy.py to a different directory (I didn't realise /usr/lib/python.../site-packages would be root only on Linux) using a command like: python TuscanySCASetup.py install --install-lib $TUSCANY_SCACPP/extensions/python/lib and then get users to add $TUSCANY_SCACPP/extensions/python/lib to their PYTHONPATH. I have updated the build files and PythonCalculator sample on Windows and Linux to do this. Andy, Besides the build integration related questions above, I confirm that your Python extension works great on Linux (tested on Redhat Enterprise Linux 4). The only change I had to make was to remove an include of ...cpp/model/CPPInterface.h in PythonServiceProxy.cpp. I committed that small fix under revision r443083. Nice! Great! Glad to hear it worked OK :) In other news, I have just added in support for properties to the Python extension: - A composite with a property defined in a component and the associated .componentType file: component name=DivideComponent implementation.python module=DivideImpl scope=composite/ property name=doRoundingtrue/property /component componentType ... property name=doRounding type=xsd:boolean/ /componentType Is automatically instantiated and assigned the property value in the python implementation module: def divide(val1, val2): result = float(val1) / float(val2) print Python - DivideImpl.divide + str(val1) + / + str(val2) + = + str(result) # Use the doRounding property if doRounding: result = round(result) print Python - DivideImpl.divide is rounding the result to + str(result) return result Cheers Andy
Re: [C++] Python extension available
Hi all, I've just checked in code to support SCA clients written in Python and references in Python components. The updated PythonCalculator sample under http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/samples/PythonCalculatorhttp://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/samples/RubyCalculator/sample.calculator/ shows the programming model: - A client can get a proxy to a service with: import TuscanySCA and calculator = TuscanySCA.locateService (CalculatorComponent/CalculatorService) - You then simply call a business method on calculator, like this: x = calculator.add(1, 2) - References are automatically added to your Python component implementation when the runtime loads the implementation script, so they can be used like so: # The module-level div function def div(val1, val2): # Use the divideService reference result = divideService.divide(val1, val2) return result and in your composite file: component name=CalculatorComponent implementation.python module=CalculatorImpl scope=composite/ reference name=divideServiceDivideComponent/DivideService/reference /component - Due to the current requirement of a componentType file, I have implemented an empty interface.python interface extension (rather than expecting people to use interface.cpp or something. So a .componentType file would look like: componentType xmlns=http://www.osoa.org/xmlns/sca/1.0; service name=CalculatorService interface.python/ /service reference name=divideService interface.python/ /reference /componentType - The client and reference support comes from a Python extension package that is installed into the Python environment, making the TuscanySCA and TuscanySCAProxy modules available for all python scripts. - Next up is properties support - this should be pretty easy. - Further work would be to look at annotations, to avoid the need for the .componentType files at all. The code for the Tuscany/C++ Python extension is here: http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/runtime/extensions/pythonhttp://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/runtime/extensions/ruby/ It builds and runs fine on Windows (remember to have the PYTHON_HOME env variable set to your Python insallation dir), but hasn't been tested or built on Linux. I have updated the automake files but I don't know how to add in the commands to build and install the Python extension into Python. The commands required are: cd tuscany/cpp/sca/runtime/extensions/python/src/tuscany/sca/python python TuscanySCASetup.py build python TuscanySCASetup.py install If someone who knows automake could add these in and test it out that would be great! Cheers Andy
Re: [C++] Python extension available
Andrew Borley wrote: Hi all, I've just checked in code to support SCA clients written in Python and references in Python components. The updated PythonCalculator sample under http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/samples/PythonCalculatorhttp://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/samples/RubyCalculator/sample.calculator/ shows the programming model: - A client can get a proxy to a service with: import TuscanySCA and calculator = TuscanySCA.locateService (CalculatorComponent/CalculatorService) - You then simply call a business method on calculator, like this: x = calculator.add(1, 2) - References are automatically added to your Python component implementation when the runtime loads the implementation script, so they can be used like so: # The module-level div function def div(val1, val2): # Use the divideService reference result = divideService.divide(val1, val2) return result and in your composite file: component name=CalculatorComponent implementation.python module=CalculatorImpl scope=composite/ reference name=divideServiceDivideComponent/DivideService/reference /component - Due to the current requirement of a componentType file, I have implemented an empty interface.python interface extension (rather than expecting people to use interface.cpp or something. So a .componentType file would look like: componentType xmlns=http://www.osoa.org/xmlns/sca/1.0; service name=CalculatorService interface.python/ /service reference name=divideService interface.python/ /reference /componentType - The client and reference support comes from a Python extension package that is installed into the Python environment, making the TuscanySCA and TuscanySCAProxy modules available for all python scripts. - Next up is properties support - this should be pretty easy. - Further work would be to look at annotations, to avoid the need for the .componentType files at all. The code for the Tuscany/C++ Python extension is here: http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/runtime/extensions/pythonhttp://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/runtime/extensions/ruby/ It builds and runs fine on Windows (remember to have the PYTHON_HOME env variable set to your Python insallation dir), but hasn't been tested or built on Linux. I have updated the automake files but I don't know how to add in the commands to build and install the Python extension into Python. The commands required are: cd tuscany/cpp/sca/runtime/extensions/python/src/tuscany/sca/python python TuscanySCASetup.py build python TuscanySCASetup.py install If someone who knows automake could add these in and test it out that would be great! Cheers Andy Andy, Looks great! I can help integrate in the automake build. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Python extension available
Andrew Borley wrote: [snip] A few issues came up when I was developing the extension: 1) The code currently depends on the CPP extension code, specifically for the interface.cpp which is used by the extension just to get the scope and remotable attributes. Are these two attributes specific to C++ interfaces or are they generic enough to be put into the tuscany::sca::model::Interface super-class? Andy, Good catch. I have moved remotable to tuscany::sca::model::Interface. I have a real hard time understanding why the spec makes Scope part of interfaces instead of just implementations - IMHO the lifecyle of a component implementation should not be exposed as part of its interface - but both the Java and C++ SCA CI specs put it on Interface so I'm going to get over this for now, I'm probably missing something... I moved it as well to tuscany::sca::model::Interface. With these changes I was able to adjust your Python extension so that it does not depend anymore on the CPP extension. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Python extension available
On 9/6/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Andrew Borley wrote: [snip] A few issues came up when I was developing the extension: 1) The code currently depends on the CPP extension code, specifically for the interface.cpp which is used by the extension just to get the scope and remotable attributes. Are these two attributes specific to C++ interfaces or are they generic enough to be put into the tuscany::sca::model::Interface super-class? Andy, Good catch. I have moved remotable to tuscany::sca::model::Interface. I have a real hard time understanding why the spec makes Scope part of interfaces instead of just implementations - IMHO the lifecyle of a component implementation should not be exposed as part of its interface - but both the Java and C++ SCA CI specs put it on Interface so I'm going to get over this for now, I'm probably missing something... I moved it as well to tuscany::sca::model::Interface. With these changes I was able to adjust your Python extension so that it does not depend anymore on the CPP extension. That's cool - thanks! Andy
[C++] Python extension available
Hi all, The implementation.python extension code is now checked in, alongside an updated Calculator sample that allows you to substitute the current C++ implementation of DivideService for a Python one - see the Python module in samples/Calculator/CalculatorComposite/DivideServiceImpl.py and the commented-out blocks in samples/Calculator/CalculatorComposite/CalculatorComposite.composite. It all works on Windows and I've updated the Linux makefiles but haven't got a working local Linux box to try them out on - could someone try a build and see what happens? For windows you need to have Python installed and the PYTHON_HOME environment variable set to the installation dir. Also, I only have MS VC7, so I haven't updated the VC6 project files to include the extension. A few issues came up when I was developing the extension: 1) The code currently depends on the CPP extension code, specifically for the interface.cpp which is used by the extension just to get the scope and remotable attributes. Are these two attributes specific to C++ interfaces or are they generic enough to be put into the tuscany::sca::model::Interface super-class? 2) I wanted to use the exceptions in osoa/sca/ServiceRuntimeException but they've been moved into the C++ extension, so I basically took a copy, slightly changed it and put that in the Python extension. I wonder if these pretty generic exceptions should be in the SCA core instead of the C++ extension? 3) Ditto with the use of the declarations in osoa/sca/export.h. Should these be in SCA core for anyone to re-use? It was a pretty smooth ride to get this far, and it's pretty cool to be able to drop in some Python code instead of a C++ dll, or expose a bit of Python as a web-service :) Next up is the bits identified in the Extension matters thread. Cheers Andy
Re: [C++] Python extension available
Andrew Borley wrote: Hi all, The implementation.python extension code is now checked in, alongside an updated Calculator sample that allows you to substitute the current C++ implementation of DivideService for a Python one - see the Python module in samples/Calculator/CalculatorComposite/DivideServiceImpl.py and the commented-out blocks in samples/Calculator/CalculatorComposite/CalculatorComposite.composite. It all works on Windows and I've updated the Linux makefiles but haven't got a working local Linux box to try them out on - could someone try a build and see what happens? For windows you need to have Python installed and the PYTHON_HOME environment variable set to the installation dir. Also, I only have MS VC7, so I haven't updated the VC6 project files to include the extension. Andy, this is really cool! A few issues came up when I was developing the extension: 1) The code currently depends on the CPP extension code, specifically for the interface.cpp which is used by the extension just to get the scope and remotable attributes. Are these two attributes specific to C++ interfaces or are they generic enough to be put into the tuscany::sca::model::Interface super-class? Yes, remotable should move to tuscany::sca::model::Interface. I think that scope should stay in CPPInterface for now, and maybe move to *Implementation classes later. IMO different implementation types define different scoping rules (e.g. Java/C++ are probably similar, BPEL would be different, a non OO language with no Class/Object may not define scopes at all). I am not sure why scope is declared on the interface at the moment, I'll investigate to see if it's consistent with the spec or an oversight. 2) I wanted to use the exceptions in osoa/sca/ServiceRuntimeException but they've been moved into the C++ extension, so I basically took a copy, slightly changed it and put that in the Python extension. I wonder if these pretty generic exceptions should be in the SCA core instead of the C++ extension? I thinlk that Pete mentioned this problem too. We need core Tuscany exceptions, surfaced as osoa ServiceRuntimeExceptions in the CPP extension, surfaced as something else for a different language binding. 3) Ditto with the use of the declarations in osoa/sca/export.h. Should these be in SCA core for anyone to re-use? This is used in the SCA C++ API on Windows, do you really need it in your extension? or are you just looking for cdecl export? It was a pretty smooth ride to get this far, and it's pretty cool to be able to drop in some Python code instead of a C++ dll, or expose a bit of Python as a web-service :) Yes this is really great, it should be easy now to build on top of what you've done and integrate support for other scripting languages... Next up is the bits identified in the Extension matters thread. Cheers Andy -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Python extension available
Andrew Borley wrote: [snip] Hi all, The implementation.python extension code is now checked in, alongside an updated Calculator sample that allows you to substitute the current C++ implementation of DivideService for a Python one - see the Python module in samples/Calculator/CalculatorComposite/DivideServiceImpl.py and the commented-out blocks in samples/Calculator/CalculatorComposite/CalculatorComposite.composite. It all works on Windows and I've updated the Linux makefiles but haven't got a working local Linux box to try them out on - could someone try a build and see what happens? For windows you need to have Python installed and the PYTHON_HOME environment variable set to the installation dir. Also, I only have MS VC7, so I haven't updated the VC6 project files to include the extension. Andy, I just tried it on my Redhat Enterprise Linux 4 with Python 2.3 and it works well after just minor changes to configure.ac and Makefile.am (checked in under revision r439534). Very nice! To build it on linux, you need to declare the following variables: export PYTHON_INCLUDE=/usr/include/python2.3 for example (look for Python.h on your particular Linux distro). export PYTHON_INCLUDE=/usr/lib assuming that libpython-2.3.so is in /usr/lib. I also changed Makefile.am in the Calculator sample to copy all .py files to the deploy directory. I think it would be nice to have a new sample demonstrating the capabilities of this new python extension. I also like the the way you allow either just a module or a module plus a class in implementation.python, and thinking that it should work for Javascript as well. I will propose to change implementation.js to follow the same idea in a different email. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
