corelinux-develop — Developer centric mail list for CoreLinux++

Re: [Corelinux-develop] libclfw++ 0.4.3 released

[Frank V. C. <fr...@co...>]

Christophe Prud'homme wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Tuesday 31 October 2000 11:05, you wrote:
> > Ahh! I thought you left, when is the date of departure?
> I am leaving the 10th of nov (a friday I think)
> I'll be back in the USA the 9th of january
> but in the mean time I'll be online

Ok, I have posted the debians and updated download.php. Very nice. 

BTW: Doxygen 1.2.3 is out. I am going to install when I can find a rpm
that doesn't time out in the download.

 
> BTW DSL sucks

Hahahahahaha 

"There is no gravity, the earth sucks"

> 
> C.
> - --
>   Christophe Prud'homme                  |
>   MIT, 77, Mass Ave, Rm 3-243            |   If it doesn't work, force it.
>   Cambridge MA 02139                     |   If it breaks, it needed
>   Tel (Office) : (00 1) (617) 253 0229   |   replacing anyway.
>   Fax (Office) : (00 1) (617) 258 8559   |
>   http://augustine.mit.edu/~prudhomm     |
>                           Following the hacker spirit
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.4 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iEYEARECAAYFAjn/CxMACgkQ5i/coy8vSEhUugCfZeDsBPZbR35o1aCG/fSryhD7
> S6AAn2zM7fYoaA0HT6CoenCuyuLwyfWz
> =7fHx
> -----END PGP SIGNATURE-----
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-develop

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package

Re: [Corelinux-develop] libclfw++ 0.4.3 released

[Christophe Prud'h. <pru...@MI...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 31 October 2000 11:05, you wrote:
> Ahh! I thought you left, when is the date of departure?
I am leaving the 10th of nov (a friday I think)
I'll be back in the USA the 9th of january
but in the mean time I'll be online

BTW DSL sucks

C.
- -- 
  Christophe Prud'homme                  |
  MIT, 77, Mass Ave, Rm 3-243            |   If it doesn't work, force it.
  Cambridge MA 02139                     |   If it breaks, it needed
  Tel (Office) : (00 1) (617) 253 0229   |   replacing anyway.
  Fax (Office) : (00 1) (617) 258 8559   |
  http://augustine.mit.edu/~prudhomm     |
                          Following the hacker spirit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjn/CxMACgkQ5i/coy8vSEhUugCfZeDsBPZbR35o1aCG/fSryhD7
S6AAn2zM7fYoaA0HT6CoenCuyuLwyfWz
=7fHx
-----END PGP SIGNATURE-----

Re: [Corelinux-develop] libclfw++ 0.4.3 released

[Frank V. C. <fr...@co...>]

Ahh! I thought you left, when is the date of departure?

I'm glad your still around!!!

Christophe Prud'homme wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> > If anyone can do a debian build from the tarball, please let me know.
> > Christophe, who thankfully provided that for us, is flying all over the
> > world and is unavailable for the time being.
> deb packages uploaded
> you won't get rid of me that easily :)
> they are still for woody(unstable) debian
> 
> regards
> C.
> - --
>   Christophe Prud'homme                 |  Its name is Public Opinion.
>   MIT, 77, Mass Ave, Rm 3-243           |  It is held in reverence.
>   Cambridge MA 02139                    |  It settles everything.
>   Tel (Office) : (00 1) (617) 253 0229  |  Some think it is the voice of God.
>   Fax (Office) : (00 1) (617) 258 8559  |  -- Mark Twain
>   http://augustine.mit.edu/~prudhomm    |
>                           Following the hacker spirit
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.4 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iEYEARECAAYFAjn+3VMACgkQ5i/coy8vSEj0nwCggfIDYrwb9BF+juw3FtOPsb0N
> 6bcAoIXqyqouFWaTUjLvCApHADgenmKy
> =WMcn
> -----END PGP SIGNATURE-----
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-develop

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package

Re: [Corelinux-develop] libclfw++ 0.4.3 released

[Christophe Prud'h. <pru...@MI...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> If anyone can do a debian build from the tarball, please let me know.
> Christophe, who thankfully provided that for us, is flying all over the
> world and is unavailable for the time being.
deb packages uploaded
you won't get rid of me that easily :)
they are still for woody(unstable) debian

regards
C.
- -- 
  Christophe Prud'homme                 |  Its name is Public Opinion.
  MIT, 77, Mass Ave, Rm 3-243           |  It is held in reverence.
  Cambridge MA 02139                    |  It settles everything.
  Tel (Office) : (00 1) (617) 253 0229  |  Some think it is the voice of God.
  Fax (Office) : (00 1) (617) 258 8559  |  -- Mark Twain
  http://augustine.mit.edu/~prudhomm    |
                          Following the hacker spirit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjn+3VMACgkQ5i/coy8vSEj0nwCggfIDYrwb9BF+juw3FtOPsb0N
6bcAoIXqyqouFWaTUjLvCApHADgenmKy
=WMcn
-----END PGP SIGNATURE-----

Re: [Corelinux-develop] libclfw++ 0.4.3 released

[Christophe Prud'h. <pru...@MI...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> If anyone can do a debian build from the tarball, please let me know.
> Christophe, who thankfully provided that for us, is flying all over the
> world and is unavailable for the time being.
Nope
DSL installation yesterday and .... it failed :(
my flat is too old
the .deb should be on corelinux.sf.net in a few minutes

- -- 
   Christophe Prud'homme                  |
   MIT, 77, Mass Ave, Rm 3-243            |   I respect faith, but doubt is
   Cambridge MA 02139                     |   what gives you an education.
   Tel (Office) : (00 1) (617) 253 0229   |   -- Wilson Mizner
   Fax (Office) : (00 1) (617) 258 8559   |
   http://augustine.mit.edu/~prudhomm     |
                          Following the hacker spirit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjn+2HYACgkQ5i/coy8vSEiPwwCfekKWhjEgXXdMhEVKkND9LJdM
cgsAn03+hpNKBFool8dg99n5V+SwXoHO
=vT/U
-----END PGP SIGNATURE-----

[Corelinux-develop] libclfw++ 0.4.3 released

[Frank V. C. <fr...@co...>]

This release turns up the heat in extending MetaType from a glorified
RTTI class, to a mini method broker. You can now define named functions
to the MetaType that can be called (ala classless) without knowing an
object instance type. 

If anyone can do a debian build from the tarball, please let me know.
Christophe, who thankfully provided that for us, is flying all over the
world and is unavailable for the time being.
-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

Re: [Corelinux-develop] Changes to MetaType

[Frank V. C. <fr...@co...>]

First off: CVS now contains the implementation of MetaType::dispatch.
The example code shows off how this is used by declaring a new aggregate
type (UserType). The macros which enable this are at the bottom of
UserType.cpp.

John,

Ok, couple of things for you so we are on the same page. In regards to
class WhatEver and class MetaType :

Classes elect to have a MetaType (helper macros)

A MetaType is a glorified RTTI class, and a light weight broker with the
ability to invoke methods through indirection. 

A MetaType contains information about hierarchical structure and
location, any attributes declared to the MetaType, and about functions
available to be called.

MetaTypes are statically constructed and float around except for their
"parents" linkage (not a hard link, the parents are a array of MetaType
pointers constructed at compile time).

This is the first step we needed to complete in order to enable some
level of reasoning within the CoreLinux++ provided frameworks. For
example, the LibraryType class derivations (which can include Function,
Graphic, etc.) will be "known" to respond to queries about what types of
libraries it can handle, so (pseudo code):

// Asssume we're iterating through a collection of library type handlers
// 

LoaderPtr  n::getLoaderForLibrary( char *aName )
{
    while( itr != end )
    {
        bool    itDoes;

        (*itr).second->dispatch
            (
                "HandlesThisLibrary",
                (void **)aName,
                (void *)&itDoes
            );

        if( itDoes == true )
        {
        }
    }
}

The next step we were going to take was to define an Ontology (
organization of types with a few twists to support  semantic reasoning
). Clearly, the static MetaTypes will need to "register" themselves into
the Ontology.

Once an Ontology is done it will be easy enough to construct a MetaType
programatically, through dynamic magic, or by hand (as I am doing now
with all these macros (yechh)).

Having said that I think we are looking at the problem with the same
general ideas to solving it.

Perhaps a chat meeting soon can shine an even brighter light on the two
directions and thoughts?

"John A. Palmieri" wrote:
> 
> Sounds good. I think we might be able to go this way in SOMELib.  I
> agree it is much better than the method call.  The only problem comes
> with name clashes and the ability to link a file statically if a
> programmer so chooses.  One way to avoid clashes ( especially with
> overloaded functions) is to create method signatures. For example a
> method doSomething from object A with arguments of int and string should
> be given the signature A_doSomething_int_string (or similar
> signatures).  I think we should standardize on the format of the
> signature and macros used to create lookups though I think the lookup
> tables should be separate from the object itself.  For example
> 
> UnkownObject anA(get reference to A's MetaType depending on library
> (CoreLinux or SOMELib or other)); //A does not have to inherit from any
> class because all information is loaded from the metatype
> //UnkownObject builds reference table based on MetaType information
> (SOME::ClassCatalog in SOMELib)
> 
> anA.invokeMethod("doSomething", BIND_PARAMS(x, y));  //I like this name
> better than dispatch.  We could use the same functionality as printf for
> multiple parameters instead of using a macro to bind them but this could
> be library dependent.
> 
> The reason for leaving the implementations of the lookup table outside
> the actual object and inside the specific library is so that we don't
> have to compromise over implementation.  The only thing that is the same
> is the C function names, the macro's and their implementations for
> creating the C functions, and the format for the metadata which could be
> as easy as
>  {
>    "meta_classname"="A",
>    "meta_methodc"="1",  //number of methods in this class
>    "meta_methodname[0]"="doSomething", //name of the first method
>    "meta_methodinvocator[0]"="A_doSomething_int", //signature of the c
> function call
>    "meta_argc[0]"="1", //number of args this method takes
>    "meta_argt[0][0]"="int", //the arg type for argument 1 of method 1
>    "meta_ret"="int"  //the return type
>  }
> 
> With this a person could even turn a C library into a scriptable object
> that can be used by SOMELib and CoreLinux++ by just supplying metatype
> information for that library.  The way we supply MetaType information
> and library entry points for each project is different but at the source
> level at least implementation of the classes themselves can be the same
> and we can possibly move towards binary compatibility after that (with
> bindings for each metatype format and library entry points).  I am on my
> way to creating a preparser for automating the MetaType stuff straight
> from the header files.  I should be able to easily expand it to support
> the scriptable interfaces and both SOMELib and CoreLinux++'s formats
> (generated from IDL files).  Of course the scriptable interfaces will be
> part of SOMELib 2.0 as we expect 1.0 to be packaged soon.
> 
> Tell me what you think.

In regards to the last (compiler), Christophe (who may be on the way to
France as we speak) had some ideas along this line. But, we are probably
not going to be ready until CoreLinux++ has a persistent framework in
place. It would not be reasonable to expect that the user/devloper would
need to recompile the metainformation and then load it all the time. 

I have been looking at RDFS (Resource Descriptor Framework Schema) as a
way to capture and import (through a XML parser) ontologies.

> 
> -Quinticent
> 
> "Frank V. Castellucci" wrote:
> >
> > Recent check-in includes the ability to declare a function dispatch
> > table, each member of the table containing a text descriptor and
> > function address that can be used to direct the appropriate object
> > method call.
> >
> > For example (lots of stuff omitted) :
> >
> > // in A.hpp
> >
> > class A : public virtual FrameworkEntity
> > {
> >         DECLARE_METATYPEMEMBERS( A );
> > public:
> >         int     doSomething( int v );
> > };
> >
> > // in A.cpp
> >
> > // Either use macros or create by hand, to define the function
> > // If using the macro, then just provide the body
> > // **note the names
> >
> > DISPATCH_FUNCTION( A, doSomething )
> >     *((int *)ret) = myPointer->doSomething( (int) args[0] );
> > CLOSE_DISPATCH_FUNCTION;
> >
> > // Which expands to
> >
> > static extern "C" void AdoSomething
> >     (
> >         FrameworkEntityPtr aClass,
> >         void               **args,
> >         void               *ret
> >     )
> > {
> >     A *myPointer = A::castdown( aClass );
> >     *((int *)ret) = myPointer->doSomething( (int) args[0] );
> > }
> >
> > // Then create a dispatch descriptor
> >
> > DEFINE_DISPATCH_DESCRIPTOR( A, doSomething, doSomething );
> >
> > // where first arg is class
> > //       second arg is stringified for lookup
> > //       third arg is the method
> > //
> >
> > // Create the table to collect all descriptors
> >
> > OPEN_DISPATCH_TABLE( A )
> >     DEFINE_DISPATCH_ENTRY( A, doSomething )
> > CLOSE_DISPATCH_TABLE;
> >
> > DEFINE_METATYPE( A, someid, someversion );
> >
> > // In user application, the ability will be used to call the method with
> > // the context of the instance (anA)
> >
> > int main( void )
> > {
> >     A   anA;
> >     int x(5);
> >     int y(0);
> >
> >     anA.getType()->dispatch(&anA,"doSomething",(void **)&x,(void *)&y);
> > }
> >
> > The MetaType method (dispatch) should be in sometime tonight, all the
> > macros are in.
> >
> > --
> > Frank V. Castellucci
> > http://corelinux.sourceforge.net
> > OOA/OOD/C++ Standards and Guidelines for Linux
> > http://PythPat.sourceforge.net
> > Pythons Pattern Package
> > _______________________________________________
> > Corelinux-develop mailing list
> > Cor...@li...
> > http://lists.sourceforge.net/mailman/listinfo/corelinux-develop
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-develop

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package

Re: [Corelinux-develop] Changes to MetaType

[John A. P. <qui...@ao...>]

Sounds good. I think we might be able to go this way in SOMELib.  I
agree it is much better than the method call.  The only problem comes
with name clashes and the ability to link a file statically if a
programmer so chooses.  One way to avoid clashes ( especially with
overloaded functions) is to create method signatures. For example a
method doSomething from object A with arguments of int and string should
be given the signature A_doSomething_int_string (or similar
signatures).  I think we should standardize on the format of the
signature and macros used to create lookups though I think the lookup
tables should be separate from the object itself.  For example

UnkownObject anA(get reference to A's MetaType depending on library
(CoreLinux or SOMELib or other)); //A does not have to inherit from any
class because all information is loaded from the metatype

//UnkownObject builds reference table based on MetaType information
(SOME::ClassCatalog in SOMELib)

anA.invokeMethod("doSomething", BIND_PARAMS(x, y));  //I like this name
better than dispatch.  We could use the same functionality as printf for
multiple parameters instead of using a macro to bind them but this could
be library dependent.

The reason for leaving the implementations of the lookup table outside
the actual object and inside the specific library is so that we don't
have to compromise over implementation.  The only thing that is the same
is the C function names, the macro's and their implementations for
creating the C functions, and the format for the metadata which could be
as easy as 
 { 
   "meta_classname"="A",
   "meta_methodc"="1",  //number of methods in this class
   "meta_methodname[0]"="doSomething", //name of the first method
   "meta_methodinvocator[0]"="A_doSomething_int", //signature of the c
function call
   "meta_argc[0]"="1", //number of args this method takes
   "meta_argt[0][0]"="int", //the arg type for argument 1 of method 1
   "meta_ret"="int"  //the return type
 }

With this a person could even turn a C library into a scriptable object
that can be used by SOMELib and CoreLinux++ by just supplying metatype
information for that library.  The way we supply MetaType information
and library entry points for each project is different but at the source
level at least implementation of the classes themselves can be the same
and we can possibly move towards binary compatibility after that (with
bindings for each metatype format and library entry points).  I am on my
way to creating a preparser for automating the MetaType stuff straight
from the header files.  I should be able to easily expand it to support
the scriptable interfaces and both SOMELib and CoreLinux++'s formats
(generated from IDL files).  Of course the scriptable interfaces will be
part of SOMELib 2.0 as we expect 1.0 to be packaged soon.

Tell me what you think.

-Quinticent 


"Frank V. Castellucci" wrote:
> 
> Recent check-in includes the ability to declare a function dispatch
> table, each member of the table containing a text descriptor and
> function address that can be used to direct the appropriate object
> method call.
> 
> For example (lots of stuff omitted) :
> 
> // in A.hpp
> 
> class A : public virtual FrameworkEntity
> {
>         DECLARE_METATYPEMEMBERS( A );
> public:
>         int     doSomething( int v );
> };
> 
> // in A.cpp
> 
> // Either use macros or create by hand, to define the function
> // If using the macro, then just provide the body
> // **note the names
> 
> DISPATCH_FUNCTION( A, doSomething )
>     *((int *)ret) = myPointer->doSomething( (int) args[0] );
> CLOSE_DISPATCH_FUNCTION;
> 
> // Which expands to
> 
> static extern "C" void AdoSomething
>     (
>         FrameworkEntityPtr aClass,
>         void               **args,
>         void               *ret
>     )
> {
>     A *myPointer = A::castdown( aClass );
>     *((int *)ret) = myPointer->doSomething( (int) args[0] );
> }
> 
> // Then create a dispatch descriptor
> 
> DEFINE_DISPATCH_DESCRIPTOR( A, doSomething, doSomething );
> 
> // where first arg is class
> //       second arg is stringified for lookup
> //       third arg is the method
> //
> 
> // Create the table to collect all descriptors
> 
> OPEN_DISPATCH_TABLE( A )
>     DEFINE_DISPATCH_ENTRY( A, doSomething )
> CLOSE_DISPATCH_TABLE;
> 
> DEFINE_METATYPE( A, someid, someversion );
> 
> // In user application, the ability will be used to call the method with
> // the context of the instance (anA)
> 
> int main( void )
> {
>     A   anA;
>     int x(5);
>     int y(0);
> 
>     anA.getType()->dispatch(&anA,"doSomething",(void **)&x,(void *)&y);
> }
> 
> The MetaType method (dispatch) should be in sometime tonight, all the
> macros are in.
> 
> --
> Frank V. Castellucci
> http://corelinux.sourceforge.net
> OOA/OOD/C++ Standards and Guidelines for Linux
> http://PythPat.sourceforge.net
> Pythons Pattern Package
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-develop

[Corelinux-develop] Re: [Corelinux-public] clfw 0.2.2 released

[Christophe Prud'h. <pru...@MI...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> > clfw CVS has been tagged rel-0-2-2
>
> I'll build the .deb today
I updated the debian files for 0.2.2 and move the tag rel-0-2-2 to the new 
revisions for changelog and rules in the debian dir

- -- 
Christophe Prud'homme               |
MIT, 77, Mass Ave, Rm 3-243         | Le travail est pour moi la chose la plus
Cambridge MA 02139                  | sacrée!!!...
Tel (Office) : (00 1) (617) 253 0229| C'est pour cela que je n'y touche pas!!!
Fax (Office) : (00 1) (617) 258 8559|
http://augustine.mit.edu/~prudhomm  |
                          Following the hacker spirit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjn8i9QACgkQ5i/coy8vSEh+rgCfVyYL0Ug/k2II2dexzYbUIi+D
Od8AmgOhxQ63agLNGPhB2vnqqyCKu0bX
=uERm
-----END PGP SIGNATURE-----

[Corelinux-develop] Changes to MetaType

[Frank V. C. <fr...@co...>]

Recent check-in includes the ability to declare a function dispatch
table, each member of the table containing a text descriptor and
function address that can be used to direct the appropriate object
method call.

For example (lots of stuff omitted) :

// in A.hpp

class A : public virtual FrameworkEntity
{
	DECLARE_METATYPEMEMBERS( A );
public:
        int	doSomething( int v );
};

// in A.cpp

// Either use macros or create by hand, to define the function
// If using the macro, then just provide the body 
// **note the names

DISPATCH_FUNCTION( A, doSomething )
    *((int *)ret) = myPointer->doSomething( (int) args[0] );
CLOSE_DISPATCH_FUNCTION;

// Which expands to

static extern "C" void AdoSomething
    (
	FrameworkEntityPtr aClass,
	void		   **args,
	void		   *ret
    )
{
    A *myPointer = A::castdown( aClass );
    *((int *)ret) = myPointer->doSomething( (int) args[0] );
}

// Then create a dispatch descriptor

DEFINE_DISPATCH_DESCRIPTOR( A, doSomething, doSomething );

// where first arg is class
//       second arg is stringified for lookup
//	 third arg is the method
// 

// Create the table to collect all descriptors

OPEN_DISPATCH_TABLE( A )
    DEFINE_DISPATCH_ENTRY( A, doSomething )
CLOSE_DISPATCH_TABLE;

DEFINE_METATYPE( A, someid, someversion );

// In user application, the ability will be used to call the method with
// the context of the instance (anA)

int main( void )
{
    A	anA;
    int	x(5);
    int	y(0);

    anA.getType()->dispatch(&anA,"doSomething",(void **)&x,(void *)&y);
}

The MetaType method (dispatch) should be in sometime tonight, all the
macros are in.

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package

[Corelinux-develop] clfw 0.2.2 released

[Frank V. C. <fr...@co...>]

New structure (semantically more correct), new types, attribute get/set
marshalling, minor fixes.

clfw CVS has been tagged rel-0-2-2

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package

Re: [Corelinux-develop] I'm back (fwd)

[Hans - D. <dul...@eg...>]

On Tue, 24 Oct 2000, Frank V. Castellucci wrote:

> Date: Tue, 24 Oct 2000 07:18:18 -0400
> From: Frank V. Castellucci <fr...@co...>
> Reply-To: cor...@li...
> To: cor...@li...
> Subject: Re: [Corelinux-develop] I'm back (fwd)
> 
> Hey Hans!
> 
> Welcome back. How was the Robotics meeting?
>

It went well. It was an annual meeting sponsored by DARPA distributed
robotics project. Last year I was there, and next year I'll be there
again. Our team had to present the progress of our work in the last 1
year.
 
> Yes, the lists have been choking as of late. Sounds good on the
> semaphore stuff, let me know if there is anything that needs to be
> tossed about. Last I remember, we were kinda eye-to-eye on the issues
> no?

Yes :-). I'll take care the deadlock bug first.

> 

-- 
Hans Dulimarta, Ph.D.                  dul...@co...
P: 517-432-7589             http://www.egr.msu.edu/~dulimart   
F: 760-281-7691             http://corelinux.sourceforge.net
Elec. & Comp. Engg., Mich. State Univ., E. Lansing, MI 48824

Re: [Corelinux-develop] I'm back (fwd)

[Frank V. C. <fr...@co...>]

Hey Hans!

Welcome back. How was the Robotics meeting?

Yes, the lists have been choking as of late. Sounds good on the
semaphore stuff, let me know if there is anything that needs to be
tossed about. Last I remember, we were kinda eye-to-eye on the issues
no?


Hans - Dulimarta wrote:
> 
> I sent the following message last week but it never reached
> the list. I just realized it when Frank mentioned that the mailing list
> was unreliable.
> 
> Anyways, I'll finish up the Semaphore requirements asap.
> 
> ---------- Forwarded message ----------
> Date: Fri, 20 Oct 2000 12:37:15 -0400 (EDT)
> From: Hans - Dulimarta <dul...@eg...>
> To: CoreLinux Development <cor...@li...>
> Subject: I'm back
> 
> I'm back from my DARPA Robotics Meeting in D.C. last night.
> 
> After being in "absent" mode for a while, I'll have to tune in
> to the CoreLinux++ project again.
> 
> I saw a lot of cvs update mail notifications from the clfw sub-project.
> 
> --
> Hans Dulimarta, Ph.D.                  dul...@co...
> P: 517-432-7589             http://www.egr.msu.edu/~dulimart
> F: 760-281-7691             http://corelinux.sourceforge.net
> Elec. & Comp. Engg., Mich. State Univ., E. Lansing, MI 48824
> 
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-develop

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package

Re: [Corelinux-develop] Missing mail retry

[Frank V. C. <fr...@co...>]

Thomas Matelich wrote:

> "Frank V. Castellucci" wrote:
>
> > CoreLinux++ is not A framework, but many. It is not our intent to tightly couple each
> > framework to each other, our disciplines will ensure that. In the event it is
> > natural, for say the Persistence framework to use some kind of library loading
> > capability, then we of course we use the abstraction of the Library Load framework.
> > But it would be up to the solution space to instantiate the appropriate derivation.
> >
> > By the same token, our frameworks are to be "plug-in-able", if the user selects a
> > persistence framework implementation that doesn't require other frameworks, that is
> > fine as well.
>
> Great, now I have to quit complaining :)  So my question then is why Core*Linux*?  Is
> this merely a dependency/complexity management issue?  That is a very good issue.  I
> guess I could start working on CoreWindows++ and CoreHPUX++, or maybe CoreLinux++*3, if
> I wanted to use it.

Because the multi-thread execution profile uses "clone" versus LinuxThreads, and the idea
of the library was specifically targeted to a Linux environment.

>
>
> --
> Thomas O Matelich
> Senior Software Designer
> Zetec, Inc.
> sos...@us...
> tma...@ze...
>
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-develop

Re: [Corelinux-develop] Missing mail retry

[Thomas M. <tma...@ze...>]

"Frank V. Castellucci" wrote:

> CoreLinux++ is not A framework, but many. It is not our intent to tightly couple each
> framework to each other, our disciplines will ensure that. In the event it is
> natural, for say the Persistence framework to use some kind of library loading
> capability, then we of course we use the abstraction of the Library Load framework.
> But it would be up to the solution space to instantiate the appropriate derivation.
>
> By the same token, our frameworks are to be "plug-in-able", if the user selects a
> persistence framework implementation that doesn't require other frameworks, that is
> fine as well.

Great, now I have to quit complaining :)  So my question then is why Core*Linux*?  Is
this merely a dependency/complexity management issue?  That is a very good issue.  I
guess I could start working on CoreWindows++ and CoreHPUX++, or maybe CoreLinux++*3, if
I wanted to use it.

--
Thomas O Matelich
Senior Software Designer
Zetec, Inc.
sos...@us...
tma...@ze...

[Corelinux-develop] I'm back (fwd)

[Hans - D. <dul...@eg...>]

I sent the following message last week but it never reached
the list. I just realized it when Frank mentioned that the mailing list
was unreliable.

Anyways, I'll finish up the Semaphore requirements asap.


---------- Forwarded message ----------
Date: Fri, 20 Oct 2000 12:37:15 -0400 (EDT)
From: Hans - Dulimarta <dul...@eg...>
To: CoreLinux Development <cor...@li...>
Subject: I'm back


I'm back from my DARPA Robotics Meeting in D.C. last night.

After being in "absent" mode for a while, I'll have to tune in
to the CoreLinux++ project again.

I saw a lot of cvs update mail notifications from the clfw sub-project.

-- 
Hans Dulimarta, Ph.D.                  dul...@co...
P: 517-432-7589             http://www.egr.msu.edu/~dulimart   
F: 760-281-7691             http://corelinux.sourceforge.net
Elec. & Comp. Engg., Mich. State Univ., E. Lansing, MI 48824

Re: [Corelinux-develop] Missing mail retry

[Frank V. C. <fr...@co...>]

Thomas Matelich wrote:

> "Frank V. Castellucci" wrote:
>
> > My post of asking Tom what "scared" him about the framework design
> > something I thought he saw in the framework. While we are all concerned
> > with providing libraries that are "useable", I have had no compunction
> > about adding something complex to enhance the solution space options.
> > This may be my background of big systems work, where lots of things are
> > thought about. The biggest difference between SOMELib and CoreLinux++ is
> > that your library addresses a specific need (and will do it well it
> > appears), while CoreLinux++ is after a broad range of uses.
>
> My biggest problem with projects like CoreLinux++ is when they become all or
> nothing.  While it is a pain to rely on 12 different projects, being able to pick
> your functionality from the best place is great.  If the library loader relies on
> the persistence framework which relies on the property accessing methods which
> rely on the enhanced RTTI methodology, that is when I say nevermind.  If this is
> not true in CoreLinux++, hooray.  Just my opinion.
>

Well said and I agree, and you can say hooray!

More clarification:

CoreLinux++ is not A framework, but many. It is not our intent to tightly couple each
framework to each other, our disciplines will ensure that. In the event it is
natural, for say the Persistence framework to use some kind of library loading
capability, then we of course we use the abstraction of the Library Load framework.
But it would be up to the solution space to instantiate the appropriate derivation.

By the same token, our frameworks are to be "plug-in-able", if the user selects a
persistence framework implementation that doesn't require other frameworks, that is
fine as well.

>
> --
> Thomas O Matelich
> Senior Software Designer
> Zetec, Inc.
> sos...@us...
> tma...@ze...
>
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-develop

Re: [Corelinux-develop] Missing mail retry

[Thomas M. <tma...@ze...>]

"Frank V. Castellucci" wrote:

> My post of asking Tom what "scared" him about the framework design
> something I thought he saw in the framework. While we are all concerned
> with providing libraries that are "useable", I have had no compunction
> about adding something complex to enhance the solution space options.
> This may be my background of big systems work, where lots of things are
> thought about. The biggest difference between SOMELib and CoreLinux++ is
> that your library addresses a specific need (and will do it well it
> appears), while CoreLinux++ is after a broad range of uses.

My biggest problem with projects like CoreLinux++ is when they become all or
nothing.  While it is a pain to rely on 12 different projects, being able to pick
your functionality from the best place is great.  If the library loader relies on
the persistence framework which relies on the property accessing methods which
rely on the enhanced RTTI methodology, that is when I say nevermind.  If this is
not true in CoreLinux++, hooray.  Just my opinion.

--
Thomas O Matelich
Senior Software Designer
Zetec, Inc.
sos...@us...
tma...@ze...

Re: [Corelinux-develop] Missing mail retry

[Frank V. C. <fr...@co...>]

John,

I have copied you direct on this as the mailing list is taking up to two
(2) days to process messages. Perhaps we should all give up our projects
and fix THAT for SourceForge :)

"John Palmieri (Quinticent)" wrote:
> 
> I'm not sure if this is refrence to the Dynamic Interface stuff you wanted
> us (SOMELib) to work with you on.  DataMarshling?  Are you creating out of
> process C++ classes? SOMELib is mainly for inprocess object loading and if
> you wish to go the out of process route I would like to suggest creating
> orbit bindings for C++ since Linux seems to moving twords CORBA for
> component systems.

The foundational wrapping is for our frameworks to reason with types.
One example will be when we need to load either functions or classes
from external libraries, another will be when we add a persistence
framework so that the persist engine does not require encoding schema
information into class declaration/definitions.

At some point you will have your library doing what you want, at some
point our framework will be were we want, here is where I had thought we
(CoreLinux++) could create an adapter or bridge for mapping between our
library and your interface for the purpose of function/class loading.
Time will tell.

My post of asking Tom what "scared" him about the framework design
something I thought he saw in the framework. While we are all concerned
with providing libraries that are "useable", I have had no compunction
about adding something complex to enhance the solution space options.
This may be my background of big systems work, where lots of things are
thought about. The biggest difference between SOMELib and CoreLinux++ is
that your library addresses a specific need (and will do it well it
appears), while CoreLinux++ is after a broad range of uses.

> 
> Seeking of lost e-mails.  I had a long e-mail describinmg why Tom was
> "scared" of using your Dynamic Interface design.  Of cource when I was about
> to hit send netscape froze on me :-) Well to make it short, we believe that
> C++'s RTTI and template functionality is enough to facilitate Scriptable
> Interfaces without having to wrap simple datatypes.  SOMELib's goal is
> simplicity and working with the knowlege that C++ programmers already have
> without throwing them anything too new.  If you look at SOMELib right now a
> developer can develop C++ objects normaly (with the restriction of only
> allowing up to 2 parameter constructors) and then supply some information
> via the SOMELibInfo and SOMEClassInfo classes about these object and he/she
> is home free.  In fact the Descriptors will later be automated by a
> preprocessor.  In the same spirit of simplicity scriptable interface will be
> automate by simple providing a (perhaps IDL) interface file and running it
> through a preprocessor before compile.  The interface file is needed because
> sometimes you don't want scripts being able to access all public
> functionality. The preprocessor will simply add a method for the entry point
> of scripts to call methods and and descriptors to the SOMEClassInfo class on
> what methods are available.  Builder programs can use these descriptors to
> create object inspectors. Getter/setter patterns will be enforced for
> properties(read only/read write/etc.) Along with anything else you would
> expect to see in an object system.  No bumps or curveballs,  all streight up
> standard C++ and the stuff that is not will eventualy be placed in the
> preprocessor.  The only real learning curve is the intial loading of an
> object but once it is loaded it can be used like any C++ object (of course
> not with the Scripting Interface).  The Scripting interface would be more
> like
> vector<void *>args;
> void *return_value;
> ScriptObj->callMethod("setProperty", args, return_value);

As this suggests, the simple turns to the complex and maintenance
required task on the developer. Adding preprocessors, script compilers,
etc., is a step I applaud and recognize that we (CoreLinux++) may
venture into to, but I don't consider this simple and non-intrusive.
This is not meant as a flame, but just my opinion on what defines
complex and what doesn't.


> Of course the object itself is defined like any other C++ object with an
> extra Interface file.  The preprocessor will take care of adding the
> callMethod method (we will have to mess with the name a bit so that it
> doesn't clash with a developers method).  In that method is would have
> something like
> if(method=="setProperty_2args")//signiture
>     this-> setProperty(dynamic_cast<string>*args[0],
>                                   dynamic_cast<string>*args[1]);

We have just added the foundation for doing something like this, but
limited at the moment to get/set operations on a per attribute level
(the templates are in the example code, not the type modules) :


// Getter

template < class T > T getValue( char *name, FrameworkEntityPtr aFE )
{
   T  *pval( NULLPTR );

   pval = (T *) (aFE->getType())->get(name,aFE);

   return *pval;
}

// Setter

template < class T > void setValue
   ( 
      char *name, 
      T value, 
      FrameworkEntityPtr aFE 
   )
{
   (aFE->getType())->set(name,(VoidPtr)&value,aFE);
}

//
// Main entry point
//

int main( void )
{

  //
  // Practice gracefull exception management
  //

   try
   {

      //
      // Now we sweeten the pot with showing the factory methods, 
      // introspection, getters, setters, and destructors
      //

      // signed Integer

      IntegerPtr   aInteger = Integer::create();

      setValue<Int>("Value",8,aInteger);

      cout  << "Value of aInteger = " << 
         getValue<Int>("Value",aInteger) << endl;

      Integer::destroy( aInteger );
    }
    catch( ... )
    {
      //
    }

    return 0;
}

Of course, aInteger could have been instantiated using aInteger = new
Integer (we override new and delete in each class and provide a factory
allocator).
 
> Of course I have to expand on this idea a bit but let me know what you
> think.
> Return types are going to be the biggest headache.  It is up to the user to
> enforce type constraints on their objects not SOMELib.  We need it to be
> flexable.

I think this is similar to the design we have for the
ExecutionObjectDefinition (sans the if statements)
http://corelinux.sourceforge.net/doc/design/4865.php, which captures the
argument types and return type. A kind of blueprint, if you will, for
the actual call. 

> 
> -Quinticent
> 
> "Frank V. Castellucci" wrote:
> 
> > Mailing list are less than reliable these days.
> >
> > I have made a number of changes and additions to clfw.
> >
> > The example should pretty much show them off, as well as the headers for
> > the new types.
> >
> > The wrappers are very vacuous as far as behavior, waiting for response
> > from Christophe on the analysis of templates and meta information.
> >
> > Again, the MetaType::get and MetaType::set methods should make it clear
> > that I am leaning towards a MOP (MetaObject Protocol) way of marshaling
> > data between objects. Not necessarily for general usage, there is
> > nothing to stop someone from adding methods galore outside of the
> > knowledge of it's class descriptor, but to enable powerful extensions
> > for the frameworks.
> >
> > --
> > Frank V. Castellucci
> > http://corelinux.sourceforge.net
> > OOA/OOD/C++ Standards and Guidelines for Linux
> > http://PythPat.sourceforge.net
> > Pythons Pattern Package
> > _______________________________________________
> > Corelinux-develop mailing list
> > Cor...@li...
> > http://lists.sourceforge.net/mailman/listinfo/corelinux-develop
> 
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-develop

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package

Re: [Corelinux-develop] Missing mail retry

[John P. (Quinticent) <jo...@ma...>]

I'm not sure if this is refrence to the Dynamic Interface stuff you wanted
us (SOMELib) to work with you on.  DataMarshling?  Are you creating out of
process C++ classes? SOMELib is mainly for inprocess object loading and if
you wish to go the out of process route I would like to suggest creating
orbit bindings for C++ since Linux seems to moving twords CORBA for
component systems.

Seeking of lost e-mails.  I had a long e-mail describinmg why Tom was
"scared" of using your Dynamic Interface design.  Of cource when I was about
to hit send netscape froze on me :-) Well to make it short, we believe that
C++'s RTTI and template functionality is enough to facilitate Scriptable
Interfaces without having to wrap simple datatypes.  SOMELib's goal is
simplicity and working with the knowlege that C++ programmers already have
without throwing them anything too new.  If you look at SOMELib right now a
developer can develop C++ objects normaly (with the restriction of only
allowing up to 2 parameter constructors) and then supply some information
via the SOMELibInfo and SOMEClassInfo classes about these object and he/she
is home free.  In fact the Descriptors will later be automated by a
preprocessor.  In the same spirit of simplicity scriptable interface will be
automate by simple providing a (perhaps IDL) interface file and running it
through a preprocessor before compile.  The interface file is needed because
sometimes you don't want scripts being able to access all public
functionality. The preprocessor will simply add a method for the entry point
of scripts to call methods and and descriptors to the SOMEClassInfo class on
what methods are available.  Builder programs can use these descriptors to
create object inspectors. Getter/setter patterns will be enforced for
properties(read only/read write/etc.) Along with anything else you would
expect to see in an object system.  No bumps or curveballs,  all streight up
standard C++ and the stuff that is not will eventualy be placed in the
preprocessor.  The only real learning curve is the intial loading of an
object but once it is loaded it can be used like any C++ object (of course
not with the Scripting Interface).  The Scripting interface would be more
like
vector<void *>args;
void *return_value;
ScriptObj->callMethod("setProperty", args, return_value);

Of course the object itself is defined like any other C++ object with an
extra Interface file.  The preprocessor will take care of adding the
callMethod method (we will have to mess with the name a bit so that it
doesn't clash with a developers method).  In that method is would have
something like
if(method=="setProperty_2args")//signiture
    this-> setProperty(dynamic_cast<string>*args[0],
                                  dynamic_cast<string>*args[1]);

Of course I have to expand on this idea a bit but let me know what you
think.
Return types are going to be the biggest headache.  It is up to the user to
enforce type constraints on their objects not SOMELib.  We need it to be
flexable.

-Quinticent

"Frank V. Castellucci" wrote:

> Mailing list are less than reliable these days.
>
> I have made a number of changes and additions to clfw.
>
> The example should pretty much show them off, as well as the headers for
> the new types.
>
> The wrappers are very vacuous as far as behavior, waiting for response
> from Christophe on the analysis of templates and meta information.
>
> Again, the MetaType::get and MetaType::set methods should make it clear
> that I am leaning towards a MOP (MetaObject Protocol) way of marshaling
> data between objects. Not necessarily for general usage, there is
> nothing to stop someone from adding methods galore outside of the
> knowledge of it's class descriptor, but to enable powerful extensions
> for the frameworks.
>
> --
> Frank V. Castellucci
> http://corelinux.sourceforge.net
> OOA/OOD/C++ Standards and Guidelines for Linux
> http://PythPat.sourceforge.net
> Pythons Pattern Package
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-develop

[Corelinux-develop] Missing mail retry

[Frank V. C. <fr...@co...>]

Mailing list are less than reliable these days.

I have made a number of changes and additions to clfw.

The example should pretty much show them off, as well as the headers for
the new types.

The wrappers are very vacuous as far as behavior, waiting for response
from Christophe on the analysis of templates and meta information. 

Again, the MetaType::get and MetaType::set methods should make it clear
that I am leaning towards a MOP (MetaObject Protocol) way of marshaling
data between objects. Not necessarily for general usage, there is
nothing to stop someone from adding methods galore outside of the
knowledge of it's class descriptor, but to enable powerful extensions
for the frameworks.

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package

[Corelinux-develop] Numeric Types

[Frank V. C. <fr...@co...>]

I received a e-mail saying that the Numeric Types so far (Real, Integer,
ShortInteger, UnsignedInteger) are very vacuous for wrappers.

This will not always be the case. Christophe is putting some thought
into the use of templates to facilitate typical operations, while at the
same time thinking of the MetaType descriptors (we have attributes,
methods wouldn't be bad).

While it would be easy to "throw" something in there, I prefer a more
thoughtful implementation.

Anyone?

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

[Corelinux-develop] [Fwd: [Somelib] Recent activity]

[Frank V. C. <fr...@co...>]

A recent post to the SOMelib group.

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package

[Corelinux-develop] Debian [woody] packages released

[Frank V. C. <fr...@co...>]

libcorelinux++ 0.4.29
libclfw++ 0.2.1

debian packages have been released. Sorry for the delay.

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

[Corelinux-develop] Changes to Types

[Frank V. C. <fr...@co...>]

On a back and forth discussion with C., we jived about storage and type
derivations. Needless to say, it became apparent that with data member
specification enabled in macros for MetaType access, the solution over
storage and semantics disolved.

I bring to attention the semantics of Numbers, Integers, and RealNumbers

Number
	Integer
		ShortInteger
	RealNumber

is the new class hierarchy (and the MetaType ontology follows this). So
Integer isA Number, ShortInteger isA Integer and they have no semantic
association with RealNumber other then being a Number.

For the accessor/mutator and storage issue:

Integer	defines a 32 bit signed value (theValue)
ShortInteger accessor/mutator coerces a short in and out using the
get/set macros with the extension of re-using the base classes storage
area.

This is all checked in.

Thoughts?

PS: To build the 0.2.1 version I have tagged it rel-0-2-1. The above
changes are 0.2.2 bound (as yet not tagged).

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package