ccmtools-devel — Development discussion and ideas

Re: [ccmtools-devel] integration of our python binding

[<Joe...@sa...>]

>>>>> "Darrell" == Darrell Schiebel <da...@sc...> writes:

Darrell> (1) we do not want to use confix; we'd like to have an alternative  
Darrell> build option for C++ [in particular, we've been using Ant to build  
Darrell> the C++ portion of the CCMTOOLS distribution, i.e. cpp-environment  
Darrell> and wx, and Python's build system (e.g. via a setup.py file) build  
Darrell> everything that gets generated]. While we are not wedded to Ant, we  
Darrell> don't want to use confix (though this is based on our experience with  
Darrell> it which is now a few years old). Are you open to introducing another  
Darrell> C++ build option?

I guess I have to jump in here, at least to gather some (ex-) user
experience. (For the past few years I did only do this in-house at our
company; needless to say that only one use case makes for a limited
amount of scope.)

Would you mind telling me what were the troubles? A few things come to
my mind anyway if I put myself into a user's position,

* The namespace story (to make this an inherent feature rather than a
  switchable goodie was a big mistake I admit).

* The autotools, combined with Windows.

What else? I am open for flames, so don't hesitate.

Thanks,
Joerg

Re: [ccmtools-devel] integration of our python binding

[Egon T. <ego...@gm...>]

Hey Darrell,

> (1) we do not want to use confix; we'd like to have an alternative
> build option for C++ [in particular, we've been using Ant to build
> the C++ portion of the CCMTOOLS distribution, i.e. cpp-environment
> and wx, and Python's build system (e.g. via a setup.py file) build
> everything that gets generated]. While we are not wedded to Ant, we
> don't want to use confix (though this is based on our experience with
> it which is now a few years old). Are you open to introducing another
> C++ build option?

Yes, I think we shoud implement an option for include statement generation.
Actually, I will refactor the C++ generators (like I did for the IDL
generators) during the next few months. So, there is some flexibility
from my side.

> (2) We've introduced another layer below the *_impl.cc/h files which
> provides boiler plate for implementing the components in terms of
> standard and STL types (no CORBA, no CCMTOOLS, etc.). In this mode,
> the *_impl.cc/h files are used to provide wrappers to do any extra
> conversion that may be required. These wrappers are filled in with
> info from XML files. For example, one thing that these wrappers do is
> convert exceptions from the native library into CCMException. Our
> goal here is that the layer (we've called *_cmpt.cc/h) can serve as a
> componentized stdc++ interface to our package, and it also provides a
> clean dividing line between generated code (and the generation
> aparatus) and the hand-coded business logic. Is this something you're
> open to adding as an option (in our version, it is switched on with
> "--coda=<setup-xml-file>")?

OK.

> (3) Our "any" processing seems different from what you added. In
> particular, we needed to go from a Python dictionary to a
> std::map<std::string,casac::variant>. My impression is that your
> implementation only handles structs, and to handle more complex
> things more information is required than can easily be expressed in a
> keyword/value file. We setup these "any" conversions with an XML file
> that lists the to/from conversion functions that are used at each
> stage, i.e. in our case python or "coda" (our independence layer).
> I'll attach a snippet below.

Hmm, I will analyze your example!

> (4) I guess I need to get a new version of WX to be able to build the
> current version of CCMTOOLS.

Yes, you can download this new package (wx-utils-3.1.0) from the Confix hompage:
http://sourceforge.net/project/showfiles.php?group_id=68975

> I hope we haven't diverged too far for us to merge back into the
> mainstream. I tried to make changes in a way that was consistent, but
> in just listing these, I see that there's been a fair bit of
> modification. I guess here's what I would propose we do:
>
> (a) I'll make our version of CCMTOOLS available via anonymous
> subversion so you can get the source and look it over if you're
> inclined to do so.

Yes, that's a good idea!

> (b) we have Redhat RPMs available, and I could build them for SuSE,
> Mandrake, or Fedora if you would like to try it out.
Currently, I run gentoo on my box, so...

> (c) I'll get a version of WX (when someone lets me know where to find
> it), and see if I can, build things sans confix.

Visit the confix.sf.net hompage - even to download the wx-utils-3.1.0
package ;-)

:-) Egon

Re: [ccmtools-devel] integration of our python binding

[Darrell S. <da...@sc...>]

On Oct 10, 2006, at 8:52 AM, Egon Teiniker wrote:

> yes, I think that's still the problem!
>
> Do you know that the ccmtools now support Java components too?
> So, what's about Jython...

Yes, I saw that when perusing the source code. I argued for Jython in  
the beginning of our project, but the argument of others that there  
are too many python addons coded in C/C++ for Jython to really be  
viable won out in the end.

Our python binding works very nicely. In general, we're please with  
the way it has worked out with ccmtools, but the test will come when  
we try to distribute our "python components" via mico. Currently, the  
components are only directly loaded into python.

I'd like to fold my python binding back into mainline ccmtools, but  
I'm at a bit of a quandary of how best to do that. I guess the  
initial questions are:

(1) we do not want to use confix; we'd like to have an alternative  
build option for C++ [in particular, we've been using Ant to build  
the C++ portion of the CCMTOOLS distribution, i.e. cpp-environment  
and wx, and Python's build system (e.g. via a setup.py file) build  
everything that gets generated]. While we are not wedded to Ant, we  
don't want to use confix (though this is based on our experience with  
it which is now a few years old). Are you open to introducing another  
C++ build option?

(2) We've introduced another layer below the *_impl.cc/h files which  
provides boiler plate for implementing the components in terms of  
standard and STL types (no CORBA, no CCMTOOLS, etc.). In this mode,  
the *_impl.cc/h files are used to provide wrappers to do any extra  
conversion that may be required. These wrappers are filled in with  
info from XML files. For example, one thing that these wrappers do is  
convert exceptions from the native library into CCMException. Our  
goal here is that the layer (we've called *_cmpt.cc/h) can serve as a  
componentized stdc++ interface to our package, and it also provides a  
clean dividing line between generated code (and the generation  
aparatus) and the hand-coded business logic. Is this something you're  
open to adding as an option (in our version, it is switched on with  
"--coda=<setup-xml-file>")?

(3) Our "any" processing seems different from what you added. In  
particular, we needed to go from a Python dictionary to a  
std::map<std::string,casac::variant>. My impression is that your  
implementation only handles structs, and to handle more complex  
things more information is required than can easily be expressed in a  
keyword/value file. We setup these "any" conversions with an XML file  
that lists the to/from conversion functions that are used at each  
stage, i.e. in our case python or "coda" (our independence layer).  
I'll attach a snippet below.

(4) I guess I need to get a new version of WX to be able to build the  
current version of CCMTOOLS.

I hope we haven't diverged too far for us to merge back into the  
mainstream. I tried to make changes in a way that was consistent, but  
in just listing these, I see that there's been a fair bit of  
modification. I guess here's what I would propose we do:

(a) I'll make our version of CCMTOOLS available via anonymous  
subversion so you can get the source and look it over if you're  
inclined to do so.
(b) we have Redhat RPMs available, and I could build them for SuSE,  
Mandrake, or Fedora if you would like to try it out.
(c) I'll get a version of WX (when someone lets me know where to find  
it), and see if I can, build things sans confix.

Let me know what you think,
Darrell

PS: I just attached our whole setup file, it specifies things like  
"polymorph" an integer to a vector of integers in the python binding  
as well as how to convert "any"s.

Re: [ccmtools-devel] namespaces

[Darrell S. <da...@sc...>]

Thanks Egon, that sounds like a good plan. The way I've been working  
is to load the generator into eclipse, have it generate the code, and  
then use python's build system to build everything. For that to work,  
though, the generator needs to put things in directories that match  
the include paths in the generated code.

Maybe a way to handle it is to have an output mapper or something  
that would handle mapping certain types of files to particular  
directories. It could handle both providing an output location for  
source & header files, and it could also provide the include lines  
that are put into the generated code to include particular header files.

Darrell

PS: If you add me as a ccmtools developer and provide a branch for me  
to check things in on, I'll work to integrate my changes (over time).  
What I tried to do was to have a command like flag (--coda) which  
would turn on the extra generation I added, but I'm sure it needs to  
be cleaned up a bit since I was under time pressure and learned as I  
went...

On Aug 17, 2005, at 2:55 AM, Egon Teiniker wrote:

> Hey Darrell!
>
> Darrell Schiebel wrote:
>
>> Could you change the directories so that the path matches the   
>> namespace
>> instead of the directory name, i.e. "CCM_Local/ MyModule/..."  
>> instead of
>> "CCM_Local_MyModule_...". I find it very  useful to have the  
>> gererated
>> code match the include entries (since I  don't use confix).
>>
>
> Yes I will try, but I think there is no common source structure  
> that can
> be built with and without confix.
> As a solution, I could define a property in
> ccmtools/etc/ccmtools.properties that forces either a confix like or a
> regular source structure...

Re: [ccmtools-devel] namespaces

[Egon T. <ego...@sa...>]

Hey Darrell!

Darrell Schiebel wrote:
> Could you change the directories so that the path matches the  namespace
> instead of the directory name, i.e. "CCM_Local/ MyModule/..." instead of
> "CCM_Local_MyModule_...". I find it very  useful to have the gererated
> code match the include entries (since I  don't use confix).

Yes I will try, but I think there is no common source structure that can
be built with and without confix.
As a solution, I could define a property in
ccmtools/etc/ccmtools.properties that forces either a confix like or a
regular source structure...

:-) Egon

[ccmtools-devel] python + independence layer

[Darrell S. <da...@sc...>]

I've been working with CCMTools pretty steadily for the past 3  
months, and I've made a number of changes. The RPMs etc of the  
current state of my changes can be found at ftp://ftp.cv.nrao.edu/ 
casa/ccmtools/. I'm not sure of the best way to make these available,  
but in time I hope to get these changes merged into CCMTools. These  
RPMs were created on a RedHat 9 system. I'm not sure what version of  
*nix most people on this list use... RH9 is now quite, quite old...

Here are the changes I've made:

     (1) created a native binding of local components to Python
     (2) added a CCM, CORBA,CCMTools independent layer which extracts  
out all of the types (e.g. structs) that are absolutely necessary in  
a form that can be included with an application library to create a  
standard C++ interface to the component which mirrors the IDL  
definition as well as the local interface. For our system, this will  
be where developers implement the "business logic". It differs from  
the standard *_impl files in that it is completely independent of  
CCMTools, no includes, dependencies, etc.
     (3) code to handle default values which are specified in XML.  
This allows CCMTools to generate the standard C++ defaults for (2) as  
well as default values for invocation from Python. This is intended  
to augment the IDL with default information
     (4) code to handle XML customizations for the mappings (this bit  
is partially complete). This allows for customization of the  
generated code for particular types. An example of where this will be  
used is to map native python complex => IDL "struct complex { double  
re; double im; }" => standard C++ complex & vice versa... so the  
interface in (2) will take a "complex", the IDL will show a struct,  
and the python user will enter Python complex values.
     (5) code to handle XML customizations to provide for (limited)  
polymorphism in the generated bindings. This allows the IDL to  
specify a "sequence<Double>", but the generated code will accept a  
"Double" and build the std::vector<double>"  for use by the local  
component. This is done on a per IDL type basis.

The last thing I have in mind to add is:

     (6) a way of filling default value from a dynamic runtime system  
like dbxml. This will allow saved user state to be used to fill  
parameters which will be used to invoke the local component. It will  
just be a hook to permit this.

If anyone is interested in more information about something in  
particular or has some suggestions, please send an email. I mostly  
wanted to give Egon a heads up so that he can consider how/when/if  
parts of these changes can be merged into the development tree. I  
think I have about a month's work of work to iron out the remaining  
issues with these changes... though I'm sure there will be some  
ongoing work.

Darrell

Re: [ccmtools-devel] namespaces

[Darrell S. <da...@sc...>]

Hi Egon,

Could you change the directories so that the path matches the  
namespace instead of the directory name, i.e. "CCM_Local/ 
MyModule/..." instead of "CCM_Local_MyModule_...". I find it very  
useful to have the gererated code match the include entries (since I  
don't use confix).

thanks,
Darrell

On Aug 10, 2005, at 12:31 PM, Egon Teiniker wrote:

> Hey all!
>
> Currently, I change the ccmtools source code ( > RELEASE-0_5_3-pre1)
> significantly!!!
> Practical use of ccmtools have shown that the defined namespaces are
> problematic. Thus, I will perform the following changes for
> RELEASE-0_5_3-pre2:
>
> CCM_Local  -> ccm::local
> CCM_Remote -> ccm::remote
> LocalComponents -> ccm::local::Components
> CCM_Local::CCM_SESSION_xxx -> ccm::local::component
>
> CCM_Local::world::europe::austria::Type ->
> world::europe::austria::ccm::local::Type
>
> Together with these namespaces, directory names of generated code will
> change...
>
> :-) Egon
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle  
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams *  
> Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/ 
> bsce5sf
> _______________________________________________
> ccmtools-devel mailing list
> ccm...@li...
> https://lists.sourceforge.net/lists/listinfo/ccmtools-devel
>

[ccmtools-devel] namespaces

[Egon T. <ego...@sa...>]

Hey all!

Currently, I change the ccmtools source code ( > RELEASE-0_5_3-pre1)
significantly!!!
Practical use of ccmtools have shown that the defined namespaces are
problematic. Thus, I will perform the following changes for
RELEASE-0_5_3-pre2:

CCM_Local  -> ccm::local
CCM_Remote -> ccm::remote
LocalComponents -> ccm::local::Components
CCM_Local::CCM_SESSION_xxx -> ccm::local::component

CCM_Local::world::europe::austria::Type ->
world::europe::austria::ccm::local::Type

Together with these namespaces, directory names of generated code will
change...

:-) Egon

Re: [ccmtools-devel] extended IDL?

[Egon T. <ego...@ut...>]

Hey Darrell!

Darrell Schiebel wrote:
> The python version of the test/tutorial is below. I set it up so that 
> the component homes are automatically created, but in thinking about 
> it, I think perhaps the user should start with the home-finder. This 
> would allow (at some point) remote and local components to be mixed 
> easier. Do you agree?

Yes, I do!

>> Currently, we are planning to use the IDL any mechanism to pass  dynamic
>> data structures as method parameters. In that case we have to options:
>>
>> a) We define a default mapping from IDL any to dynamic C++ structures
>> (here we can use the WX::Utils::value* classes provided by the
>> cpp-environment).
>>
>> b) We allow the developer to define its own set of IDL any to C++
>> converter which can be hooked in at generation time (e.g. an XML file
>> contains the converter signatures which can be used by the ccmtools
>> generators).
>>
>> IDL any does not support type checking at compile time, but with an
>> appropriate mapping to C++ we do not have to pay the XML parsing
>> overhead in the local case - we can pass C++ references to dynamic C++
>> structures.
> 
> 
> The "any" with generated to/from mappings in the generated code makes  a
> lot of sense, thanks Egon. We'll probably do that to transport 
> heterogeneous dictionaries as well as multi-dimensional arrays.  Before
> too long I'll have to create RPMs so that others can use my  python
> generator. At that point, I'll send you a copy and try to help  clean up
> any unnecessary deviation from the current state of the CVS  repository.

Thanks a lot.
I'm happy to see these pretty interesting extensions to ccmtools. Is
there a way to get a deeper insight to your work? Maybe we can discuss
some details on ccmtools-devel...

:-) Egon

PS: Are you interested in becoming an official member of the ccmtools
developer community?

Re: [ccmtools-devel] extended IDL?

[Darrell S. <da...@sc...>]

Hi Egon,

On Jun 7, 2005, at 4:03 PM, Egon Teiniker wrote:
>
> Darrell Schiebel wrote:
>
>> After a lot of work with ccmtools over the past few weeks (I have the
>> python binding generator working for ccmtools' basic example, but I
>> need to get it in a shape to hand back to Egon),
>>
>
> Hey, this sounds great!

The python version of the test/tutorial is below. I set it up so that  
the component homes are automatically created, but in thinking about  
it, I think perhaps the user should start with the home-finder. This  
would allow (at some point) remote and local components to be mixed  
easier. Do you agree?
>
>
>> I'm left wondering
>> what to do if we really want the local interface to have data
>> structures which are not representable in IDL. In our case, it is
>> dictionaries (something like dictionary<key_type,val_type>. It seems
>> like there are a few options:
>>
>> (1) extend IDL (or use XML) to represent the interface and then  
>> use  the
>> generators (local & target) to narrow & expand the extra type,  e.g.
>> convert the dictionary to XML or a multidimensional array to  shape +
>> vector
>>
>
> Extending IDL's syntax seemed to be a tough task including changes in
> IDL3 parser, CCM metamodel library and generator backends too.

That makes sense...

>
>> (2) augment IDL with an XML database which tells that some subset of
>> the parameters, e.g. shape + vector, are REALLY a multidimensional
>> array so the generated user code (at both ends) should reconstitute a
>> multidimensional array and not a pair of vectors
>>
>
> Using XML (or another language) that can be represented in IDL as a
> simple string is straight forward, but does not support a type- 
> check at
> compile-time  - (I know, this is not the right argument for Python
> programmers ;-).
>
>
>> (3) hammer the interface down until it really can be represented  
>> in  IDL
>> even if we don't want to
>>
>
> Yes we have already used this approach to define an exception stack  
> trace:
>
> struct ErrorInfo
> {
>   long code;
>   string message;
> };
>
> typedef sequence<ErrorInfo>  ErrorInfoList;
>
> exception Error
> {
>   ErrorInfoList list;
> };
>
>
>
>> Right now it seems like (1) or (3) are the best options. Does anyone
>> else have any opinions about this? This seems like it would be a very
>> nice thing for CCMTOOLS to support, i.e. expanding the basic IDL
>> interface with non-native types and then allow specification on how
>> these map to IDL and back again.
>>
>
> Currently, we are planning to use the IDL any mechanism to pass  
> dynamic
> data structures as method parameters. In that case we have to options:
>
> a) We define a default mapping from IDL any to dynamic C++ structures
> (here we can use the WX::Utils::value* classes provided by the
> cpp-environment).
>
> b) We allow the developer to define its own set of IDL any to C++
> converter which can be hooked in at generation time (e.g. an XML file
> contains the converter signatures which can be used by the ccmtools
> generators).
>
> IDL any does not support type checking at compile time, but with an
> appropriate mapping to C++ we do not have to pay the XML parsing
> overhead in the local case - we can pass C++ references to dynamic C++
> structures.

The "any" with generated to/from mappings in the generated code makes  
a lot of sense, thanks Egon. We'll probably do that to transport  
heterogeneous dictionaries as well as multi-dimensional arrays.  
Before too long I'll have to create RPMs so that others can use my  
python generator. At that point, I'll send you a copy and try to help  
clean up any unnecessary deviation from the current state of the CVS  
repository.

Darrell

Re: [ccmtools-devel] extended IDL?

[Egon T. <ego...@ut...>]

Hi Darrell!

Darrell Schiebel wrote:
> After a lot of work with ccmtools over the past few weeks (I have the 
> python binding generator working for ccmtools' basic example, but I 
> need to get it in a shape to hand back to Egon), 

Hey, this sounds great!

> I'm left wondering 
> what to do if we really want the local interface to have data 
> structures which are not representable in IDL. In our case, it is 
> dictionaries (something like dictionary<key_type,val_type>. It seems 
> like there are a few options:
> 
> (1) extend IDL (or use XML) to represent the interface and then use  the
> generators (local & target) to narrow & expand the extra type,  e.g.
> convert the dictionary to XML or a multidimensional array to  shape +
> vector

Extending IDL's syntax seemed to be a tough task including changes in
IDL3 parser, CCM metamodel library and generator backends too.

> (2) augment IDL with an XML database which tells that some subset of 
> the parameters, e.g. shape + vector, are REALLY a multidimensional 
> array so the generated user code (at both ends) should reconstitute a 
> multidimensional array and not a pair of vectors

Using XML (or another language) that can be represented in IDL as a
simple string is straight forward, but does not support a type-check at
compile-time  - (I know, this is not the right argument for Python
programmers ;-).

> (3) hammer the interface down until it really can be represented in  IDL
> even if we don't want to

Yes we have already used this approach to define an exception stack trace:

struct ErrorInfo
{
  long code;
  string message;
};

typedef sequence<ErrorInfo>  ErrorInfoList;

exception Error
{
  ErrorInfoList list;
};


> Right now it seems like (1) or (3) are the best options. Does anyone 
> else have any opinions about this? This seems like it would be a very 
> nice thing for CCMTOOLS to support, i.e. expanding the basic IDL 
> interface with non-native types and then allow specification on how 
> these map to IDL and back again.

Currently, we are planning to use the IDL any mechanism to pass dynamic
data structures as method parameters. In that case we have to options:

a) We define a default mapping from IDL any to dynamic C++ structures
(here we can use the WX::Utils::value* classes provided by the
cpp-environment).

b) We allow the developer to define its own set of IDL any to C++
converter which can be hooked in at generation time (e.g. an XML file
contains the converter signatures which can be used by the ccmtools
generators).

IDL any does not support type checking at compile time, but with an
appropriate mapping to C++ we do not have to pay the XML parsing
overhead in the local case - we can pass C++ references to dynamic C++
structures.

:-) Egon

[ccmtools-devel] extended IDL?

[Darrell S. <da...@sc...>]

After a lot of work with ccmtools over the past few weeks (I have the  
python binding generator working for ccmtools' basic example, but I  
need to get it in a shape to hand back to Egon), I'm left wondering  
what to do if we really want the local interface to have data  
structures which are not representable in IDL. In our case, it is  
dictionaries (something like dictionary<key_type,val_type>. It seems  
like there are a few options:

(1) extend IDL (or use XML) to represent the interface and then use  
the generators (local & target) to narrow & expand the extra type,  
e.g. convert the dictionary to XML or a multidimensional array to  
shape + vector

(2) augment IDL with an XML database which tells that some subset of  
the parameters, e.g. shape + vector, are REALLY a multidimensional  
array so the generated user code (at both ends) should reconstitute a  
multidimensional array and not a pair of vectors

(3) hammer the interface down until it really can be represented in  
IDL even if we don't want to

Right now it seems like (1) or (3) are the best options. Does anyone  
else have any opinions about this? This seems like it would be a very  
nice thing for CCMTOOLS to support, i.e. expanding the basic IDL  
interface with non-native types and then allow specification on how  
these map to IDL and back again.

thanks,
Darrell

[ccmtools-devel] [ ccmtools-Bugs-1213321 ] redundant include statements in interface header files

[SourceForge.net <no...@so...>]

Bugs item #1213321, was opened at 2005-06-02 00:50
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=547854&aid=1213321&group_id=76664

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: C++ Generators
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: redundant include statements in interface header files

Initial Comment:
If different interface methods contain the same
parameter, the parameter's header file will be included
more than once. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=547854&aid=1213321&group_id=76664

Re: [ccmtools-devel] dependencies

[Robert L. <rob...@sa...>]

Hi Darrell!

'mdr01.jar' and 'oclmetamodel.jar' are used by the "design by contract"
generator (which generates special local components).
Take a look at "src/ccmtools/MDR/README".

'dtd2java.jar' is a special tool which generates a simple XML-parser and
a small model-library out of a DTD (document type definition). We use
this tool together with the official "UML 1.4 DTD" (src/uml2idl/UML.dtd)
to generate an UML-parser. This parser is used by "uml2idl" (the tool
which generates IDL and OCL files out of an "UML profile for CORBA").
The source of "dtd2java" is part of the "XMITools" project at SF.


Regards,
-- 
Robert Lechner   (mailto:rob...@sa...)
Research and Development
SALOMON Automation GmbH   (http://www.salomon.at)

[ccmtools-devel] dependencies

[Darrell S. <da...@sc...>]

Hi Egon,

Could you tell me what tools/libraries CCM Tools depends on and 
where/what is the original source (either source files or distribution 
site) for each?

Some are easy:

	antlr.jar	-- http://www.antlr.org/

but the rest:

	mdr01.jar contains:

		javax/jmi/*
		javax/servlet/		servlet23-api?
		junit/*			junit.jar
		org/omg/uml//*
		org/netbeans/*
		org/openide/*
		primitivetypes/*
		uml2mof/*

	oclmetamodel.jar
	dtd2java.jar
	Components.jar

Anyway, if you could take a little time and indicate where these things 
come from, I'd appreciate it.

thanks,
Darrell

		
		

[ccmtools-devel] deploy local home w/ remote components?

[Darrell S. <da...@sc...>]

Hello,

When I upgraded from version 0.4.p3 to version 0.5.1.p5, I found that 
the example code no longer works when compiled as a remote component 
(with MICO). To get things to work, I needed to add the creation of a 
local home  (see patch file). This was done in the 0.4.p3 code but 
disappeared with the 0.5.1.p5 reorganization. So my questions are (1) 
should this still be required? and (2) is this the right place to put 
the creation?

Thanks,
Darrell

Re: [ccmtools-devel] Constants.CPP_PATH

[Egon T. <ego...@ut...>]

Hey Darrell,

you are right!
I have fixed this bug in the ccmtools CVS.
Also, I have changed the name of the cpp output file from _CCM_*.idl to 
_CCM_* (without .idl) to ensure that confix will not install this 
temorary file.

Thank's for your investigations.

:-) Egon

Darrell Schiebel wrote:
> 
> Shouldn't CPP_PATH be used as the c preprocessor rather than whichever 
> 'cpp' happens to be in the user's path (see attachment)?
> 
> thanks,
> Darrell
> 
> 
> 

[ccmtools-devel] Constants.CPP_PATH

[Darrell S. <da...@sc...>]

Shouldn't CPP_PATH be used as the c preprocessor rather than whichever 
'cpp' happens to be in the user's path (see attachment)?

thanks,
Darrell

[ccmtools-devel] Re: ccmtools error

[Enric J. <en...@nm...>]

Hi!

I did the  cvs update -dP.

It has compiled successfuly, but I have realized that the CVS ccm/CCM_Local module has not Makefile.py files, so I  created them by hand, like this:
#NAME('CCM_Local')
#VERSION('1.0')

Thanks for your help,
-enric



On Thu, 13 Jan 2005, Egon Teiniker wrote:

> Hi Enric,
>
> There has been a change in the cpp-environment package. All CCM related
> modules have changed to a ccm directory and all WX related modules (that
> contain utilities like C++ smart pointers) have moved to a wx directory.
>
> Therefore, please make an cvs update -dP to ensure a proper package
> structure and follow the instructions described in the
> cpp-environment/INSTALL file.
>
> :-) Egon
>
> Enric Jaen wrote:
> > Hi Joerg!
> >
> >
> >>Enric> 2)  targeting CCM_Local , I am getting the following error:
> >>
> >>Enric> CCM_Local:
> >>Enric>      [exec] scanning package in /home/enric/phd/codigo/ccmtools-cvs/cpp-environment/CCM_Local ...
> >>Enric>      [exec] confix.py: WARNING: the package version is not set. Use --packageversion, or VERSION() in the toplevel Makefile.py.
> >>Enric>      [exec] confix.py: WARNING: package "CCM_Local" does not have any modules
> >>Enric>      [exec] done scanning.
> >>Enric>      [exec] reading repository (/tmp/repo)
> >>Enric>      [exec] done with /tmp/repo
> >>Enric>      [exec] resolving dependencies ...
> >>Enric>      [exec] done resolving
> >>Enric>      [exec] generating output ...
> >>Enric>      [exec] ***ERROR: Not even one file handled by any submodule of package CCM_Local; probably the current working directory (/home/enric/phd/codigo/ccmtools-cvs/cpp-environment/CCM_Local) is not the package root directory?
> >>Enric>      [exec] Result: 1
> >>
> >>This means that the package CCM_Local does not contain any file that
> >>can be built, and not even one of the obligatory Makefile.py's. Is
> >>this correct?
> >
> >
> > All the directories in CCM_Local are empty. I checked them out from the CVS. Why is that?
> >
> > My aim is to build the platform and manage to run the tutorial example about local components.
> >
> > I would appreciate any help.
> > -Enric
> >
> > ps. I registered in the mailing list but I have not received any confirmation email yet
> >
> >
> >
> >
>
>
>

[ccmtools-devel] Re: ccmtools error

[Egon T. <ego...@sa...>]

Hi Enric,

There has been a change in the cpp-environment package. All CCM related 
modules have changed to a ccm directory and all WX related modules (that 
contain utilities like C++ smart pointers) have moved to a wx directory.

Therefore, please make an cvs update -dP to ensure a proper package 
structure and follow the instructions described in the 
cpp-environment/INSTALL file.

:-) Egon

Enric Jaen wrote:
> Hi Joerg!
> 
> 
>>Enric> 2)  targeting CCM_Local , I am getting the following error:
>>
>>Enric> CCM_Local:
>>Enric>      [exec] scanning package in /home/enric/phd/codigo/ccmtools-cvs/cpp-environment/CCM_Local ...
>>Enric>      [exec] confix.py: WARNING: the package version is not set. Use --packageversion, or VERSION() in the toplevel Makefile.py.
>>Enric>      [exec] confix.py: WARNING: package "CCM_Local" does not have any modules
>>Enric>      [exec] done scanning.
>>Enric>      [exec] reading repository (/tmp/repo)
>>Enric>      [exec] done with /tmp/repo
>>Enric>      [exec] resolving dependencies ...
>>Enric>      [exec] done resolving
>>Enric>      [exec] generating output ...
>>Enric>      [exec] ***ERROR: Not even one file handled by any submodule of package CCM_Local; probably the current working directory (/home/enric/phd/codigo/ccmtools-cvs/cpp-environment/CCM_Local) is not the package root directory?
>>Enric>      [exec] Result: 1
>>
>>This means that the package CCM_Local does not contain any file that
>>can be built, and not even one of the obligatory Makefile.py's. Is
>>this correct?
> 
> 
> All the directories in CCM_Local are empty. I checked them out from the CVS. Why is that?
> 
> My aim is to build the platform and manage to run the tutorial example about local components.
> 
> I would appreciate any help.
> -Enric
> 
> ps. I registered in the mailing list but I have not received any confirmation email yet
> 
> 
> 
> 

[ccmtools-devel] [ ccmtools-Bugs-960009 ] <string> not included if std::string is used

[SourceForge.net <no...@so...>]

Bugs item #960009, was opened at 2004-05-25 09:54
Message generated for change (Settings changed) made by teiniker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=547854&aid=960009&group_id=76664

Category: C++ Generators
Group: 0.3 Series
Status: Open
Resolution: None
Priority: 5
Submitted By: Joerg Faschingbauer (jfasch)
>Assigned to: Teiniker Egon (teiniker)
Summary: <string> not included if std::string is used

Initial Comment:
discovered in the generated interfaces

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=547854&aid=960009&group_id=76664

[ccmtools-devel] [ ccmtools-Bugs-1100738 ] The same exception will be generated many times

[SourceForge.net <no...@so...>]

Bugs item #1100738, was opened at 2005-01-12 09:03
Message generated for change (Settings changed) made by teiniker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=547854&aid=1100738&group_id=76664

Category: C++ Generators
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Teiniker Egon (teiniker)
Summary: The same exception will be generated many times

Initial Comment:
For an exception definition in IDL3 all generators
generate code at:
 - an exception definition
 - an exception is used in an operation

This leads to longer genarator runtimes and also
triggers another bug - the same exception will propably
generated in different namespaces.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=547854&aid=1100738&group_id=76664

[ccmtools-devel] [ ccmtools-Bugs-1100738 ] The same exception will be generated many times

[SourceForge.net <no...@so...>]

Bugs item #1100738, was opened at 2005-01-12 01:03
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=547854&aid=1100738&group_id=76664

Category: C++ Generators
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: The same exception will be generated many times

Initial Comment:
For an exception definition in IDL3 all generators
generate code at:
 - an exception definition
 - an exception is used in an operation

This leads to longer genarator runtimes and also
triggers another bug - the same exception will propably
generated in different namespaces.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=547854&aid=1100738&group_id=76664

[ccmtools-devel] cpp-environment

[Egon T. <ego...@sa...>]

Hey!

I have changed the structure of the cpp-environment package:
  + All WX related code (utils, external, etc.) has been moved to a wx 
directory
  + All CCM related code (CCM_Local, CCM_Remote, etc.) has been moved to 
a ccm directory.

Now, the package is organized in the following structure:

|-- bin
|-- ccm
|   |-- CCM_Local
|   |   |-- CCM_OCL
|   |   |-- HomeFinder
|   |   |-- LocalComponents
|   |-- CCM_Python
|   |-- CCM_Remote
|   |   |-- RemoteComponents
|   |   `-- SessionContainer
`-- wx
     |-- external
     |   `-- mico
     |       |-- basic
     |       `-- coss
     `-- utils
         |-- code
         |-- error
         `-- types

As descibed in the INSTALL file, to build the whole C++ component 
runtime environment simply type:
  $ confix.py --packageroot=`pwd`/wx --bootstrap --configure --make 
--targets="install"
  $ confix.py --packageroot=`pwd`/ccm --bootstrap --configure --make 
--targets="install"

:-) Egon

[ccmtools-devel] [ ccmtools-Bugs-960009 ] <string> not included if std::string is used

[SourceForge.net <no...@so...>]

Bugs item #960009, was opened at 2004-05-25 09:54
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=547854&aid=960009&group_id=76664

Category: C++ Generators
Group: 0.3 Series
Status: Open
Resolution: None
Priority: 5
Submitted By: Joerg Faschingbauer (jfasch)
Assigned to: Nobody/Anonymous (nobody)
Summary: <string> not included if std::string is used

Initial Comment:
discovered in the generated interfaces

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=547854&aid=960009&group_id=76664