You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Andrew Borley <aj...@gmail.com> on 2006/09/01 17:23:23 UTC
[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
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++] Python extension available
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++] Python extension available
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++] Python extension available
Posted by Andrew Borley <aj...@gmail.com>.
On 9/16/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
> Andrew Borley wrote:
> > Good to hear you got it going! :-)
> > To answer your questions:
> >
> >
> > On 9/13/06, Jean-Sebastien Delfino <js...@apache.org> 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="doRounding">true</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 seems to work out the box just with the unzipped distro. No need to
> do any post install step you can run the PythonCalculator right away.
> TuscanySCAProxy.py gets compiled into a .pyc automatically the first
> time it's invoked.
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.
> 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 ;-)
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++] Python extension available
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Andrew Borley wrote:
> Good to hear you got it going! :-)
> To answer your questions:
>
>
> On 9/13/06, Jean-Sebastien Delfino <js...@apache.org> 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="doRounding">true</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 seems to work out the box just with the unzipped distro. No need to
do any post install step you can run the PythonCalculator right away.
TuscanySCAProxy.py gets compiled into a .pyc automatically the first
time it's invoked.
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?
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?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Properties and references in Python components, was: [C++] Python
extension available
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Andrew Borley wrote:
> On 9/15/06, Jean-Sebastien Delfino <js...@apache.org> 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="doRounding">true</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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Properties and references in Python components, was: [C++] Python extension available
Posted by Andrew Borley <aj...@gmail.com>.
On 9/15/06, Jean-Sebastien Delfino <js...@apache.org> 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="doRounding">true</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
Properties and references in Python components, was: [C++] Python
extension available
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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="doRounding">true</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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++] Python extension available
Posted by Andrew Borley <aj...@gmail.com>.
Good to hear you got it going! :-)
To answer your questions:
On 9/13/06, Jean-Sebastien Delfino <js...@apache.org> 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="doRounding">true</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
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jean-Sebastien Delfino wrote:
> Jean-Sebastien Delfino wrote:
>> 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/PythonCalculator<http://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="divideService">DivideComponent/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/python<http://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.
>>
>
> 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?
>
> Thanks...
>
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!
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++] Python extension available
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jean-Sebastien Delfino wrote:
> 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/PythonCalculator<http://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="divideService">DivideComponent/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/python<http://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.
>
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?
Thanks...
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++] Python extension available
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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/PythonCalculator<http://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="divideService">DivideComponent/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/python<http://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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++] Python extension available
Posted by Andrew Borley <aj...@gmail.com>.
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/PythonCalculator<http://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="divideService">DivideComponent/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/python<http://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
Posted by Andrew Borley <aj...@gmail.com>.
On 9/6/06, Jean-Sebastien Delfino <js...@apache.org> 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 C&I 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
Re: [C++] Python extension available
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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 C&I 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org