Menu
▾
▴
ccmtools-devel
|
From: Teiniker E. <ego...@tu...> - 2003-11-18 17:30:06
|
Hey Leif! I have implemented some _check_*_remote.cc files that test the generated remote components. I'm not sure if I should put these files into the test/CppGenerator/*/CCM_Test directories or use a separate test/CppRemoteGenerator tree - what do you think about that? Have you already used the MParameterDef template to generate (adapter) code for different types (MPrimitiveDef, MStringDef, MStructDef, MAliasDef,...) in your Python generator? I implemented a lot of conversion code in the CppRemoteGeneratorImpl.java file, but I think there is a better solution... :-) Egon |
|
From: Leif J. <le...@am...> - 2003-11-18 22:27:30
|
Hi Egon -
On Tue, 18 Nov 2003, Egon Teiniker wrote:
> I have implemented some _check_*_remote.cc files that test the
> generated remote components. I'm not sure if I should put these files
> into the test/CppGenerator/*/CCM_Test directories or use a separate
> test/CppRemoteGenerator tree - what do you think about that?
I think it depends on our expected use cases for the CCM Tools. If we
expect typical CCM Tools users to generate code only for local C++
components, then we ought to put the C++ remote testing in a separate
tree. I don't think this is right, however.
My feeling is that a typical C++ developer who downloads the CCM Tools
will want to generate code for remote C++ components. If you agree with
this, let's go ahead and put the remote stuff in the test/CppGenerator
tree.
On a related note, I tried to clean out the test/idl directory a bit
yesterday, so quite a few of the IDL files for the CppGenerator tests
are now in test/CppGenerator/<test_name> directories, instead of
test/idl/<test_name>. I haven't updated the test scripts yet but I'll be
working on that today.
My hope is to have a test tree that looks like this :
test
|-- idl
| `-- fail
|-- IDL3Parser
|-- IDLGenerator
`-- CppGenerator
|-- supports
|-- supports_interface
|-- supports_inheritance
| :
| :
|-- facet
|-- facet_interface
| :
| :
|-- owudb
`-- calculator
... or something like that. You mentioned this when you were out here :
It will be nice to have each CppGenerator test be contained in its own
directory, so each test can actually perform two functions (testing the
generator and providing examples for developers).
The files in the test/idl directory can still be used for vanilla
testing of the IDL parser and generators, but they ought to remain more
or less canonical examples of IDL syntax (mostly for testing the
parser).
> Have you already used the MParameterDef template to generate (adapter)
> code for different types (MPrimitiveDef, MStringDef, MStructDef,
> MAliasDef,...) in your Python generator? I implemented a lot of
> conversion code in the CppRemoteGeneratorImpl.java file, but I think
> there is a better solution...
Hmm, no, I implemented parameter conversion directly in the two-step
templates (MOperationSupports and such). Primitive types require a
simple conversion to Python data-space, and complex types will have to
call a separate conversion function (that we will have to generate).
I'll have a look at the remote code and see if I notice anything.
Also, for the Python wrapper generator, I'm finding out that it might be
easier just to generate wrappers for C++ classes directly. Not only will
we not need to rely on SWIG then (and generate some sort of Confix call
to do that---even if it is a good idea :), but SWIG's support for C++ is
shaky (no namespace or template support, for example). This whole
namespace + C issue is quite complex ...
leif
--
Leif Morgan Johnson : http://ambient.2y.net/leif/
|
|
From: Teiniker E. <ego...@tu...> - 2003-11-19 15:54:28
|
Hey Leif! Quoting Leif Johnson <le...@am...>: > Hi Egon - > > On Tue, 18 Nov 2003, Egon Teiniker wrote: > > > I have implemented some _check_*_remote.cc files that test the > > generated remote components. I'm not sure if I should put these files > > into the test/CppGenerator/*/CCM_Test directories or use a separate > > test/CppRemoteGenerator tree - what do you think about that? > > I think it depends on our expected use cases for the CCM Tools. If we > expect typical CCM Tools users to generate code only for local C++ > components, then we ought to put the C++ remote testing in a separate > tree. I don't think this is right, however. > > My feeling is that a typical C++ developer who downloads the CCM Tools > will want to generate code for remote C++ components. If you agree with > this, let's go ahead and put the remote stuff in the test/CppGenerator > tree. Yes, I agree - therefore, I added the existing remote tests in the test/CppGenerator tree. Tomorrow, I will remove the whole test/CppRemoteGenerator tree from the project. > On a related note, I tried to clean out the test/idl directory a bit > yesterday, so quite a few of the IDL files for the CppGenerator tests > are now in test/CppGenerator/<test_name> directories, instead of > test/idl/<test_name>. I haven't updated the test scripts yet but I'll be > working on that today. > > My hope is to have a test tree that looks like this : > > test > |-- idl > | `-- fail > |-- IDL3Parser > |-- IDLGenerator > `-- CppGenerator > |-- supports > |-- supports_interface > |-- supports_inheritance > | : > | : > |-- facet > |-- facet_interface > | : > | : > |-- owudb > `-- calculator > > ... or something like that. You mentioned this when you were out here : > It will be nice to have each CppGenerator test be contained in its own > directory, so each test can actually perform two functions (testing the > generator and providing examples for developers). Excellent, I will adapt the ccmtools tutorial in that way... I also think that we can leave out some simple (redundant) test cases, e.g. facet, supports, attribute, etc. > The files in the test/idl directory can still be used for vanilla > testing of the IDL parser and generators, but they ought to remain more > or less canonical examples of IDL syntax (mostly for testing the > parser). Yes, that is a good idea. :-) Egon |
|
From: Leif J. <le...@am...> - 2003-11-18 22:50:00
|
On Tue, 18 Nov 2003, Egon Teiniker wrote:
> I have implemented some _check_*_remote.cc files that test the
> generated remote components. I'm not sure if I should put these files
> into the test/CppGenerator/*/CCM_Test directories or use a separate
> test/CppRemoteGenerator tree - what do you think about that?
Why don't we create the remote environment when we create the local
environment, and get rid of the ccmtools-c++remote-* scripts ? We can
add a switch to the ccmtools-c++-{environment|generate} scripts to do
the remote environment, components and tests. There's already a switch
in there for the Python wrappers ; it just isn't used at the moment.
Comments ?
leif
--
Leif Morgan Johnson : http://ambient.2y.net/leif/
|
|
From: Teiniker E. <ego...@tu...> - 2003-11-19 16:02:17
|
Hi Leif!
Quoting Leif Johnson <le...@am...>:
> On Tue, 18 Nov 2003, Egon Teiniker wrote:
> > I have implemented some _check_*_remote.cc files that test the
> > generated remote components. I'm not sure if I should put these files
> > into the test/CppGenerator/*/CCM_Test directories or use a separate
> > test/CppRemoteGenerator tree - what do you think about that?
>
> Why don't we create the remote environment when we create the local
> environment, and get rid of the ccmtools-c++remote-* scripts ? We can
> add a switch to the ccmtools-c++-{environment|generate} scripts to do
> the remote environment, components and tests. There's already a switch
> in there for the Python wrappers ; it just isn't used at the moment.
> Comments ?
I think that installing and using the local components is much easier (no CORBA)
that handling remote components. Thus, local components can be the gateway drug
to CCM ;-) After that the remote stuff is just another step...
So I think that we should separate the following use cases:
a) Local component development (C++, Confix)
b) Local and remote component development (C++, Confix, Mico)
:-) Egon
|
|
From: Leif J. <le...@am...> - 2003-11-19 22:20:52
|
Hi Egon -
I went on a tour de force today and merged the _user_types and
_basic_types tests together. Since the CCM Tools no longer has they
`user' or `basic' type distinction, I thought it would be cleaner to
merge the tests. I'm doing make check right now, will let you know how
it turns out.
Also, what do you think of merging the _interface tests in with the
_types tests ? Seems like an interface is just another type, no ?
I also removed some of the basic tests that were already covered by the
_types tests. I noticed a couple of _check_CCM_Remote_*.cc test files
getting removed, I'm sorry if I got rid of the tests that you're trying
to merge in from the remote generator. :-/ We'll get it worked out
though.
I think I'm going to set up a new ccmtools mailing list, ccmtools-cvs,
which will send us an email whenever people commit something to cvs.
Would be a nice way to keep track of what everyone's working on.
On Wed, 19 Nov 2003, Egon Teiniker wrote:
> Quoting Leif Johnson <le...@am...>:
> > Why don't we create the remote environment when we create the local
> > environment, and get rid of the ccmtools-c++remote-* scripts ? We can
> > add a switch to the ccmtools-c++-{environment|generate} scripts to do
> > the remote environment, components and tests. There's already a switch
> > in there for the Python wrappers ; it just isn't used at the moment.
> > Comments ?
>
> I think that installing and using the local components is much easier
> (no CORBA) that handling remote components. Thus, local components can
> be the gateway drug to CCM ;-) After that the remote stuff is just
> another step...
>
> So I think that we should separate the following use cases:
> a) Local component development (C++, Confix)
> b) Local and remote component development (C++, Confix, Mico)
I dunno, I think it would be cleaner from the user's perspective to have
a single ccmtools-c++-generate script. Users could just add a --remote
switch (or something like that) to the call if they will be generating
remote component code in addition to the local stuff.
... But I can see how if you've already generated the local code it
would be a pain to regenerate the local code just to get the remote
code. Whatever works.
Gotta run to help some kids with math homework. Cheers !
leif
--
Leif Morgan Johnson : http://ambient.2y.net/leif/
|
|
From: Teiniker E. <ego...@tu...> - 2003-11-21 08:44:45
|
Hey Leif!
Quoting Leif Johnson <le...@am...>:
> Hi Egon -
>
> I went on a tour de force today and merged the _user_types and
> _basic_types tests together. Since the CCM Tools no longer has they
> `user' or `basic' type distinction, I thought it would be cleaner to
> merge the tests. I'm doing make check right now, will let you know how
> it turns out.
>
> Also, what do you think of merging the _interface tests in with the
> _types tests ? Seems like an interface is just another type, no ?
Yes, that's OK - it will reduce the make check time significantly!
> I also removed some of the basic tests that were already covered by the
> _types tests. I noticed a couple of _check_CCM_Remote_*.cc test files
> getting removed, I'm sorry if I got rid of the tests that you're trying
> to merge in from the remote generator. :-/ We'll get it worked out
> though.
No problem, I will collect the remote tests in the same way - as far as they run
through... ;-)
Hey, the remote generator is able to generate struct adapters now!!!
> I think I'm going to set up a new ccmtools mailing list, ccmtools-cvs,
> which will send us an email whenever people commit something to cvs.
> Would be a nice way to keep track of what everyone's working on.
That would be helpful - in particular for the large developer community in the
future of ccmtools...
;-) Egon
> On Wed, 19 Nov 2003, Egon Teiniker wrote:
> > Quoting Leif Johnson <le...@am...>:
> > > Why don't we create the remote environment when we create the local
> > > environment, and get rid of the ccmtools-c++remote-* scripts ? We can
> > > add a switch to the ccmtools-c++-{environment|generate} scripts to do
> > > the remote environment, components and tests. There's already a switch
> > > in there for the Python wrappers ; it just isn't used at the moment.
> > > Comments ?
> >
> > I think that installing and using the local components is much easier
> > (no CORBA) that handling remote components. Thus, local components can
> > be the gateway drug to CCM ;-) After that the remote stuff is just
> > another step...
> >
> > So I think that we should separate the following use cases:
> > a) Local component development (C++, Confix)
> > b) Local and remote component development (C++, Confix, Mico)
>
> I dunno, I think it would be cleaner from the user's perspective to have
> a single ccmtools-c++-generate script. Users could just add a --remote
> switch (or something like that) to the call if they will be generating
> remote component code in addition to the local stuff.
>
> ... But I can see how if you've already generated the local code it
> would be a pain to regenerate the local code just to get the remote
> code. Whatever works.
>
> Gotta run to help some kids with math homework. Cheers !
>
> leif
>
> --
> Leif Morgan Johnson : http://ambient.2y.net/leif/
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive? Does it
> help you create better code? SHARE THE LOVE, and help us help
> YOU! Click Here: http://sourceforge.net/donate/
> _______________________________________________
> ccmtools-devel mailing list
> ccm...@li...
> https://lists.sourceforge.net/lists/listinfo/ccmtools-devel
>
|
Thanks for helping keep SourceForge clean.
X