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

[Corelinux-develop] some info on RDF and associated grammar

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

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

here is an interesting link on the RDF format and its grammar

http://www.w3.org/TR/REC-rdf-syntax/
- --=20
  Christophe Prud'homme                 |
  MIT, 77, Mass Ave, Rm 3-243           |  The Second Law of Thermodynami=
cs:
  Cambridge MA 02139                    |  If you think things are in a m=
ess
  Tel (Office) : (00 1) (617) 253 0229  |   now, just wait!
  Fax (Office) : (00 1) (617) 258 8559  |  -- Jim Warner
  http://augustine.mit.edu/~prudhomm    |
  ICQ UIN: 24560867 Alias: Jesunix      |
                          Following the hacker spirit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjqYFNwACgkQoY+0C9S+FFBXvwCfSfCc1Z8/1WriYX16N3ogea89
UvsAnR74mFdWZEQBdYTJpDPTh4put+Zm
=3DAEko
-----END PGP SIGNATURE-----

Re: [Corelinux-develop] Thought, parser, template

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

Hans - Dulimarta wrote:
> 
> On Sat, 24 Feb 2001, Frank V. Castellucci wrote:
> 
> > Hans - Dulimarta wrote:
> > >
> > > On Fri, 23 Feb 2001, Frank V. Castellucci wrote:
> > >
> > > > Hans,
> > > >
> > > > As per previous conversation (corelinux, clfw, clfll), did you see
> > > > anything of interest? Is there something you want to do that isn't on
> > > > the list that makes sense for the direction of the libraries?
> > > >
> > >
> > > My exploration in corelinux in not yet comprehensive. It is a new world to
> > > me, let alone the framework (clfw) and the library loader (clfll). All
> > > these three tracks are interesting to me, but I'll continue my exploration
> > > in the corelinux world first.
> > >
> > > In the task list I found that #11180 and #11325 are unassigned.
> > > I'll take care of #11325 first, it has been past due for > 1 year :-)
> >
> > Which one is 11325 again? I can't seem to get it on the web.
> >
> 
> Task ID 11325: libcl++ implementation of Factory Method Pattern (Req 5097)

hmmmm, that has been implemented as AbstractAllocator in AbstractFactory
<grin>.
You may want to review it as I may have not done a good job on it,
but...

> 
> > Couple of things:
> >
> > A templated declaration is useless until it has it's types defined, only
> > then is it a concrete class/object. The only way I have ever gotten
> > templated classes to work with generating their own meta-information was
> > to first create the concrete entity, and then the macro.
> >
> > The whole idea of what Christophe is doing would be to do away with the
> > meta-macros, and instead use a more expressive and easy to read form for
> > which we generate the needed constructs. If you think about it, the
> > metatype/metaclass itself is mostly a collection of dictionaries
> > (relationships, data-members, methods, etc.).
> >
> > The road into #define SOME_MACRO1() .... SOME_MACRO[n]() is exactley
> > what I avoided with the way I constructed the first round, NO LIMITS!!!
> > But, as you can see, it means more work on the developers part.
> >
> 
> With this parser work on the way, are we going to adapt a similar
> approach to that of Qt with their 'Meta Object Compiler' (moc)?

I imagine so if Qt was going for the same idea. I haven't developed with
Qt. 

> Perhaps I missed something here because during the initial traffic of
> MetaClass discussion sometimes back last year, my focus was somewhere
> else.

I don't know, you seem in tune. I think I have more in my mind about
MetaClass, Meta Object Protocols, Reflection, and Introspection then I
may have indicated in these posts, but we can evolve that.


> 
> > > --
> > > Hans Dulimarta, Ph.D. |                dul...@co...
> > > Research Associate    |     http://www.egr.msu.edu/~dulimart
> > > P: 517-432-7589       |     http://corelinux.sourceforge.net
> > > F: 760-281-7691     http://freshmeat.net/projects/snapsource
> > > Elec. & Comp. Engg., Mich. State Univ., E. Lansing, MI 48824
> > >
> > > _______________________________________________
> > > Corelinux-develop mailing list
> > > Cor...@li...
> > > http://lists.sourceforge.net/lists/listinfo/corelinux-develop
> >
> >
> 
> --
> Hans Dulimarta, Ph.D. |                dul...@co...
> Research Associate    |     http://www.egr.msu.edu/~dulimart
> P: 517-432-7589       |     http://corelinux.sourceforge.net
> F: 760-281-7691     http://freshmeat.net/projects/snapsource
> Elec. & Comp. Engg., Mich. State Univ., E. Lansing, MI 48824
> 
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/lists/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] Thought, parser, template

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

On Sat, 24 Feb 2001, Frank V. Castellucci wrote:

> Hans - Dulimarta wrote:
> >
> > On Fri, 23 Feb 2001, Frank V. Castellucci wrote:
> >
> > > Hans,
> > >
> > > As per previous conversation (corelinux, clfw, clfll), did you see
> > > anything of interest? Is there something you want to do that isn't on
> > > the list that makes sense for the direction of the libraries?
> > >
> >
> > My exploration in corelinux in not yet comprehensive. It is a new world to
> > me, let alone the framework (clfw) and the library loader (clfll). All
> > these three tracks are interesting to me, but I'll continue my exploration
> > in the corelinux world first.
> >
> > In the task list I found that #11180 and #11325 are unassigned.
> > I'll take care of #11325 first, it has been past due for > 1 year :-)
>
> Which one is 11325 again? I can't seem to get it on the web.
>

Task ID 11325: libcl++ implementation of Factory Method Pattern (Req 5097)

> Couple of things:
>
> A templated declaration is useless until it has it's types defined, only
> then is it a concrete class/object. The only way I have ever gotten
> templated classes to work with generating their own meta-information was
> to first create the concrete entity, and then the macro.
>
> The whole idea of what Christophe is doing would be to do away with the
> meta-macros, and instead use a more expressive and easy to read form for
> which we generate the needed constructs. If you think about it, the
> metatype/metaclass itself is mostly a collection of dictionaries
> (relationships, data-members, methods, etc.).
>
> The road into #define SOME_MACRO1() .... SOME_MACRO[n]() is exactley
> what I avoided with the way I constructed the first round, NO LIMITS!!!
> But, as you can see, it means more work on the developers part.
>

With this parser work on the way, are we going to adapt a similar
approach to that of Qt with their 'Meta Object Compiler' (moc)?

Perhaps I missed something here because during the initial traffic of
MetaClass discussion sometimes back last year, my focus was somewhere
else.

> > --
> > Hans Dulimarta, Ph.D. |                dul...@co...
> > Research Associate    |     http://www.egr.msu.edu/~dulimart
> > P: 517-432-7589       |     http://corelinux.sourceforge.net
> > F: 760-281-7691     http://freshmeat.net/projects/snapsource
> > Elec. & Comp. Engg., Mich. State Univ., E. Lansing, MI 48824
> >
> > _______________________________________________
> > Corelinux-develop mailing list
> > Cor...@li...
> > http://lists.sourceforge.net/lists/listinfo/corelinux-develop
>
>

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

Re: [Corelinux-develop] Thought, parser, template

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

Hans - Dulimarta wrote:
> 
> On Fri, 23 Feb 2001, Frank V. Castellucci wrote:
> 
> > Hans,
> >
> > As per previous conversation (corelinux, clfw, clfll), did you see
> > anything of interest? Is there something you want to do that isn't on
> > the list that makes sense for the direction of the libraries?
> >
> 
> My exploration in corelinux in not yet comprehensive. It is a new world to
> me, let alone the framework (clfw) and the library loader (clfll). All
> these three tracks are interesting to me, but I'll continue my exploration
> in the corelinux world first.
> 
> In the task list I found that #11180 and #11325 are unassigned.
> I'll take care of #11325 first, it has been past due for > 1 year :-)

Which one is 11325 again? I can't seem to get it on the web.

> The parser "project" looks cool too, I'm sure Christophe will enjoy
> working on it.
> 
> I have one thought about the metaclass for templated classes.
> I see the that DEFINE_METACLASS (...) might have to include the template
> type name. So, my idea is to add another DEFINE_... macro. But we also
> have to consider the number of template formal parameters. Perhaps, we
> could use several of these macros
> 
>    DEFINE_TEMPLATE_METACLASS1 (classname, tmpl1)
>    DEFINE_TEMPLATE_METACLASS2 (classname, tmpl1, tmpl2)
>    DEFINE_TEMPLATE_METACLASS3 (... , ...  , ...  , ...)
> 
> [probably we have to limit how many template parameters will be allowed.
> Refer to how the STL defines only AdaptableGenerator,
> AdaptableUnaryFunction, and AdaptableBinaryFunction]
> 
> Along with this, the Lisp-like meta declaration probably has to include
> some way of conveying the meta template parameter?
> 
> Examples:
> 
> template<typename T1>
> class A {
>   DEFINE_TEMPLATE_METACLASS1 (A, T1);
> ...
> };
> 
> template<typename X, typename Y>
> class B {
>   DEFINE_TEMPLATE_METACLASS (B, X, Y);
>   ...
> };
> 
> Will this work?
> 

Couple of things:

A templated declaration is useless until it has it's types defined, only
then is it a concrete class/object. The only way I have ever gotten
templated classes to work with generating their own meta-information was
to first create the concrete entity, and then the macro.

The whole idea of what Christophe is doing would be to do away with the
meta-macros, and instead use a more expressive and easy to read form for
which we generate the needed constructs. If you think about it, the
metatype/metaclass itself is mostly a collection of dictionaries
(relationships, data-members, methods, etc.).

The road into #define SOME_MACRO1() .... SOME_MACRO[n]() is exactley
what I avoided with the way I constructed the first round, NO LIMITS!!!
But, as you can see, it means more work on the developers part.

> --
> Hans Dulimarta, Ph.D. |                dul...@co...
> Research Associate    |     http://www.egr.msu.edu/~dulimart
> P: 517-432-7589       |     http://corelinux.sourceforge.net
> F: 760-281-7691     http://freshmeat.net/projects/snapsource
> Elec. & Comp. Engg., Mich. State Univ., E. Lansing, MI 48824
> 
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/lists/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

[Corelinux-develop] Thought, parser, template

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

On Fri, 23 Feb 2001, Frank V. Castellucci wrote:

> Hans,
>
> As per previous conversation (corelinux, clfw, clfll), did you see
> anything of interest? Is there something you want to do that isn't on
> the list that makes sense for the direction of the libraries?
>

My exploration in corelinux in not yet comprehensive. It is a new world to
me, let alone the framework (clfw) and the library loader (clfll). All
these three tracks are interesting to me, but I'll continue my exploration
in the corelinux world first.

In the task list I found that #11180 and #11325 are unassigned.
I'll take care of #11325 first, it has been past due for > 1 year :-)

The parser "project" looks cool too, I'm sure Christophe will enjoy
working on it.

I have one thought about the metaclass for templated classes.
I see the that DEFINE_METACLASS (...) might have to include the template
type name. So, my idea is to add another DEFINE_... macro. But we also
have to consider the number of template formal parameters. Perhaps, we
could use several of these macros

   DEFINE_TEMPLATE_METACLASS1 (classname, tmpl1)
   DEFINE_TEMPLATE_METACLASS2 (classname, tmpl1, tmpl2)
   DEFINE_TEMPLATE_METACLASS3 (... , ...  , ...  , ...)

[probably we have to limit how many template parameters will be allowed.
Refer to how the STL defines only AdaptableGenerator,
AdaptableUnaryFunction, and AdaptableBinaryFunction]

Along with this, the Lisp-like meta declaration probably has to include
some way of conveying the meta template parameter?

Examples:

template<typename T1>
class A {
  DEFINE_TEMPLATE_METACLASS1 (A, T1);
...
};

template<typename X, typename Y>
class B {
  DEFINE_TEMPLATE_METACLASS (B, X, Y);
  ...
};

Will this work?

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

Re: [Corelinux-develop] Another requirement

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

Christophe Prud'homme wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Friday 23 February 2001 21:28, you wrote:
> > Your putting the parser abstraction into cl++? or clfw++?
> it makes sense only in clfw++ no ?
> in the packaging the parser is not that useful without clfw
> on second thought it is the abstraction and the user might want to use it for something else
> 
> what I propose:
> 
> * parser abstraction in cl++
> * implementation of a first clfw++ parser candidate in clfw++
> 
> thoughts?

Exactly my thoughts, mainly because "Parser" is one of the GoF Design
Patterns, and that is the essence of cl++.

> C.
> - --
>  Christophe Prud'homme                | Pierre: Je suis désolé Thérèse, je ne
>  MIT, 77, Mass Ave, Rm 3-243          |         sais pas ce qui m'a pris...
>  Cambridge MA 02139                   |         c'est une catastrophe.
>  Tel (Office) : (00 1) (617) 253 0229 | Thérèse: Ce n'est rien Pierre,
>  Fax (Office) : (00 1) (617) 258 8559 |          je n'ai rien senti....
>  http://augustine.mit.edu/~prudhomm   | -- Le Pere Noel est une ordure
>  ICQ UIN: 24560867 Alias: Jesunix     |
>                           Following the hacker spirit
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.4 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iEYEARECAAYFAjqXHCgACgkQoY+0C9S+FFCQKACfXHidgwXQY1QLpGUiEwdnDnH8
> 5lQAn0vgPTeHHtUcRg7uXxBl3W8ew3/A
> =vCWO
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/lists/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] Another requirement

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

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

On Friday 23 February 2001 21:28, you wrote:
> Your putting the parser abstraction into cl++? or clfw++?
it makes sense only in clfw++ no ?
in the packaging the parser is not that useful without clfw
on second thought it is the abstraction and the user might want to use it=
 for something else

what I propose:

* parser abstraction in cl++
* implementation of a first clfw++ parser candidate in clfw++

thoughts?
C.
- --=20
 Christophe Prud'homme                | Pierre: Je suis d=E9sol=E9 Th=E9r=
=E8se, je ne
 MIT, 77, Mass Ave, Rm 3-243          |         sais pas ce qui m'a pris.=
=2E.
 Cambridge MA 02139                   |         c'est une catastrophe.
 Tel (Office) : (00 1) (617) 253 0229 | Th=E9r=E8se: Ce n'est rien Pierre=
,
 Fax (Office) : (00 1) (617) 258 8559 |          je n'ai rien senti....
 http://augustine.mit.edu/~prudhomm   | -- Le Pere Noel est une ordure
 ICQ UIN: 24560867 Alias: Jesunix     |
                          Following the hacker spirit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjqXHCgACgkQoY+0C9S+FFCQKACfXHidgwXQY1QLpGUiEwdnDnH8
5lQAn0vgPTeHHtUcRg7uXxBl3W8ew3/A
=3DvCWO
-----END PGP SIGNATURE-----

Re: [Corelinux-develop] Another requirement

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

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

Wow I should go and sleep
my previous is really hard to read

so I understand the problems with the C++ parser and I am fine with the s=
yntax you proposed=20
on the template problem I am fine with what you said

see you on the net this week end for the first shot :)
C.
- --=20
  Christophe Prud'homme                 |
  MIT, 77, Mass Ave, Rm 3-243           |   A wise person makes his own
  Cambridge MA 02139                    |   decisions,
  Tel (Office) : (00 1) (617) 253 0229  |   a weak one obeys public opini=
on.
  Fax (Office) : (00 1) (617) 258 8559  |   -- Chinese proverb
  http://augustine.mit.edu/~prudhomm    |
  ICQ UIN: 24560867 Alias: Jesunix      |
                          Following the hacker spirit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjqXGzkACgkQoY+0C9S+FFAlgwCdHvhmlph8OdDJ8s/Ge9t1Wm5C
jFoAoIYZQ7JiEkZYQpVyKK8JcPpshyEk
=3DwXUP
-----END PGP SIGNATURE-----

Re: [Corelinux-develop] Another requirement

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

Your putting the parser abstraction into cl++? or clfw++?


Christophe Prud'homme wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I forgot to press send on the answer to your previous email I wrote this morning
> I said that I now understand your concerns about the C++ parser and
> for the template it is ok for me for now.
> 
> So I'll start working on the parser
> 
> >
> > I think that whatever C. does, it should be usable for the clfw types.
> > This will be an immediate test area for working out initial kinks.
> good
> >
> > I have recently refered to a slight reimplementation of
> > MetaType/MetaClass, well the work by C. would make that easier as I want
> > to lean us more towards using MetaClass versus letting it act as a
> > hybrid Bridge to MetaType.
> Good
> 
> I planned to give a first shot tis we for the parser.
> so see you around on the net this we may be
> 
> C.
> - --
>    Christophe Prud'homme                  |
>    MIT, 77, Mass Ave, Rm 3-243            |
>    Cambridge MA 02139                     |    Do nothing unless you must,
>    Tel (Office) : (00 1) (617) 253 0229   |    and when you must act
>    Fax (Office) : (00 1) (617) 258 8559   |    -- hesitate.
>    http://augustine.mit.edu/~prudhomm     |
>    ICQ UIN: 24560867 Alias: Jesunix       |
>                           Following the hacker spirit
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.4 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iEYEARECAAYFAjqXGCcACgkQoY+0C9S+FFDPYwCdG9VlQ5+eY3yQ9N5tg5qAEBaH
> m8oAoIvrWB96R1nEspw6OKnrMsULx4C/
> =KOSL
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/lists/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] Another requirement

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

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

I forgot to press send on the answer to your previous email I wrote this =
morning
I said that I now understand your concerns about the C++ parser and=20
for the template it is ok for me for now.

So I'll start working on the parser

>
> I think that whatever C. does, it should be usable for the clfw types.
> This will be an immediate test area for working out initial kinks.
good
>
> I have recently refered to a slight reimplementation of
> MetaType/MetaClass, well the work by C. would make that easier as I wan=
t
> to lean us more towards using MetaClass versus letting it act as a
> hybrid Bridge to MetaType.
Good

I planned to give a first shot tis we for the parser.
so see you around on the net this we may be

C.
- --=20
   Christophe Prud'homme                  |
   MIT, 77, Mass Ave, Rm 3-243            |
   Cambridge MA 02139                     |    Do nothing unless you must=
,
   Tel (Office) : (00 1) (617) 253 0229   |    and when you must act
   Fax (Office) : (00 1) (617) 258 8559   |    -- hesitate.
   http://augustine.mit.edu/~prudhomm     |
   ICQ UIN: 24560867 Alias: Jesunix       |
                          Following the hacker spirit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjqXGCcACgkQoY+0C9S+FFDPYwCdG9VlQ5+eY3yQ9N5tg5qAEBaH
m8oAoIvrWB96R1nEspw6OKnrMsULx4C/
=3DKOSL
-----END PGP SIGNATURE-----

[Corelinux-develop] Hans, whats up?

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

Hans,

As per previous conversation (corelinux, clfw, clfll), did you see
anything of interest? Is there something you want to do that isn't on
the list that makes sense for the direction of the libraries? 

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

[Corelinux-develop] Another requirement

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

Christophe and Hans,

I think it a good idea to throw the requirements at Christophe here,
before adding them into the forum where I started the others.

Sooo....

I think that whatever C. does, it should be usable for the clfw types.
This will be an immediate test area for working out initial kinks.

I have recently refered to a slight reimplementation of
MetaType/MetaClass, well the work by C. would make that easier as I want
to lean us more towards using MetaClass versus letting it act as a
hybrid Bridge to MetaType.

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

[Corelinux-develop] Forum thread started for MetaClass parser.

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

I started this so we have a central record of what we want for both the
tactical (now) and the strategic (then) <grin>.

http://sourceforge.net/forum/message.php?msg_id=114342


-- 
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] Some details of MetaClass parser

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

Christophe Prud'homme wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> > (defclass corelinux::SomeClass
> >       (defproperty "Value" : native=int)
> >       (defmetaproperty "Parents" {MetaClassRoot})
> > )
> Ok sounds cool !
> actually I was thinking about doing this through macros
> 
> PROPERTY( int Value READ getValue WRITE setValue );
> getValue() and setValue() are getters and setters

My assumption was that ALL values have get and set methods (making the
declaration redundant). There needs to be a consistent reflection
interface for frameworks (such as Persist) to do their thing. This would
be no different than generating the "getXXXX" and "setXXXX" expansions
found in MetaType.hpp today. We can use a form of name mangling to
ensure we have the interface standards for property types without
colliding with interface the developer has declared/defined.

> 
> > the parser reads the clmc file and generates an mci (metaclass include)
> > and mcd (metaclass definition), such that when DECLARE_METACLASS expands
> > to (for example)
> >
> > #include      <MetaClassSomeClass.mci>
> > // which expands to a inner class and SomeClass statics (such as class
> > pointer and accessors for it)
> >
> > And DEFINE_METACLASS expands to include the "mcd" file which is
> > fundementally what we now have in macros, with the addition that the
> > initializer adds itself to the Ontology target (in this example
> > corelinux).
> yes that was wht I wanted to do with parser+macros
> the DEFINE_METACLASS would have been only META_CLASS and used inside the class
> then the parser recognise the symbol and generate the meta class information
> Now if new properties are defined they are parsed also and the mcd is
> generated automatically.
> 
> > This is the first point, I will wait before raising any others.
> > Thoughts?
> Your system seems to be cleaner/simpler.
> However in the system I was thinking the parser would have been a stripped
> c++ parser therefore the DEFINE_METACLASS( class ); would be only
> DEFINE_METACLASS (no arg) and the parser would generate the basic meta
> informations (class::getClassName() for example ) on the class directly from
> the header file. So any changes in the header file is caugth.

I'm against parsing the C++ stuff at all, personally. The reasons being
that:

* It removes control of what data members or methods are "exposed" in
the reflective declaration unless we require them to add more macros to
the header files, which is what I thought we wanted to get away from? 

* It allows us to get VERY expressive in the clmc file declarations:

(defmethod (virtual | static | none) ....)
(defmetamethod (virtual | static | none) ....)

etc.

Also, note in the example that I gave that "SomeClass" was NOT derived
from anything, but the "(defclass SomeClass)" had a "Parents" defined.
MetaClasses don't neccessarily follow C++ class derivation graphs, and
while I anticipate that most WILL, it is not implicit. Come to think of
it, you would propably want something like:

(MetaSomeClassClass associates SomeClass
	(property "Value" : native=int)
	(metaproperty "Parents" {MetaClassRoot})
)

which would make MetaSomeClassClass a first class object that SomeClass
would use through the minor macro expansions, instead of making it a
nested class. (Note the lack of namespace assumes "corelinux::").
	

There may also be cases where we want PURE metaclasses defined, that
will live in the ontology for various reasons. For this refer to classes
programming.

> 
> Moreover what if the class is a template for example? don't you need a c++
> parser to ensure that the class definition is correct when you generate the
> mcd file ?
> 
> template<typename T>
> class A
> {
>  DEFINE_METACLASS( A<T> );
>  blah.
> };
> 
> now how do you deal with this in the clmc file ? that is how do you
> synchronize the class definition with the clmc file and generated mcd file ?
> 

I would need to research meta object protocol with the use of templated
classes. My first thought is that we don't work with templatized classes
at this point.


> best regards
> C.
> - --
>   Christophe Prud'homme                 |
>   MIT, 77, Mass Ave, Rm 3-243           |  A classic is something that
>   Cambridge MA 02139                    |  everyone wants to have read and
>   Tel (Office) : (00 1) (617) 253 0229  |  nobody wants to read.
>   Fax (Office) : (00 1) (617) 258 8559  |  -- Mark Twain,
>   http://augustine.mit.edu/~prudhomm    |  "The Disappearance of Literature"
>   ICQ UIN: 24560867 Alias: Jesunix      |
>                           Following the hacker spirit
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.4 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iEYEARECAAYFAjqWOjoACgkQoY+0C9S+FFCkVACfTRGVHgAttgCcn2Ftg0aWcuJN
> jhEAmgOHfbNF178GWIwfxprujwlO1yqI
> =UMer
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/lists/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] Some details of MetaClass parser

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

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


> (defclass corelinux::SomeClass
> =09(defproperty "Value" : native=3Dint)
> =09(defmetaproperty "Parents" {MetaClassRoot})
> )
Ok sounds cool !
actually I was thinking about doing this through macros

PROPERTY( int Value READ getValue WRITE setValue );
getValue() and setValue() are getters and setters

> the parser reads the clmc file and generates an mci (metaclass include)
> and mcd (metaclass definition), such that when DECLARE_METACLASS expand=
s
> to (for example)
>
> #include=09<MetaClassSomeClass.mci>
> // which expands to a inner class and SomeClass statics (such as class
> pointer and accessors for it)
>
> And DEFINE_METACLASS expands to include the "mcd" file which is
> fundementally what we now have in macros, with the addition that the
> initializer adds itself to the Ontology target (in this example
> corelinux).
yes that was wht I wanted to do with parser+macros
the DEFINE_METACLASS would have been only META_CLASS and used inside the =
class
then the parser recognise the symbol and generate the meta class informat=
ion
Now if new properties are defined they are parsed also and the mcd is=20
generated automatically.


> This is the first point, I will wait before raising any others.
> Thoughts?
Your system seems to be cleaner/simpler.
However in the system I was thinking the parser would have been a strippe=
d=20
c++ parser therefore the DEFINE_METACLASS( class ); would be only=20
DEFINE_METACLASS (no arg) and the parser would generate the basic meta=20
informations (class::getClassName() for example ) on the class directly f=
rom=20
the header file. So any changes in the header file is caugth.

Moreover what if the class is a template for example? don't you need a c+=
+=20
parser to ensure that the class definition is correct when you generate t=
he=20
mcd file ?

template<typename T>
class A
{
 DEFINE_METACLASS( A<T> );
 blah.
};

now how do you deal with this in the clmc file ? that is how do you=20
synchronize the class definition with the clmc file and generated mcd fil=
e ?

best regards
C.
- --=20
  Christophe Prud'homme                 |
  MIT, 77, Mass Ave, Rm 3-243           |  A classic is something that
  Cambridge MA 02139                    |  everyone wants to have read an=
d
  Tel (Office) : (00 1) (617) 253 0229  |  nobody wants to read.
  Fax (Office) : (00 1) (617) 258 8559  |  -- Mark Twain,
  http://augustine.mit.edu/~prudhomm    |  "The Disappearance of Literatu=
re"
  ICQ UIN: 24560867 Alias: Jesunix      |
                          Following the hacker spirit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjqWOjoACgkQoY+0C9S+FFCkVACfTRGVHgAttgCcn2Ftg0aWcuJN
jhEAmgOHfbNF178GWIwfxprujwlO1yqI
=3DUMer
-----END PGP SIGNATURE-----

[Corelinux-develop] Some details of MetaClass parser

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

It might be helpful to reiterate why the MetaType/MetaClass information
is alive in the first place:

1. It enables developers a way to reason with objects without knowing
the details of the class itself. This is enabled through the use of the
method and type information, as well as subclass (parent/child)
relationships.

2. The ability to provide the frameworks (Library, Persist, etc.) the
means to be more effective in the capability it can deliver. By removing
the bond between interface and compilation time, the frameworks are more
flexible.

3. It is similar to the work I was progressing with in knowledge
representation, so I thought it cool (mainly for the above two reasons).

And some facts:

1. You can build the metatype/metaclass instance at run-time. We did it
at implementation time because it was convenient to me (as it was in my
head and clear as a bell). It is messy and convuluted, and Christophe is
headed in the very right direction.

2. There is a slight overlap between metatype and metaclass, and there
is probably a implementation error in there as well.

3. We are missing a way to describe a relationship (composition or
aggregate) between two or more metaclasses. Without them we are unable
to express semantics that exist on the class (for any number of
reasons), and prevent a full Meta Object Protocol enablement (classless
programming).

So, here is some of what I am proposing and why:

* The MetaClass parser should not generate the C++ class interwoven with
the MetaClass information, but instead stick to the MetaClass
declarations and definitions as extra files. This implies that the
developer has provided the C++ class and has used that information in
formulating the MetaClass declaration file. 

For example:

SomeClass.hpp
-------------

class SomeClass 
{
	DECLARE_METACLASS( SomeClass );
	
public:

	int	getValue( void ) const;
	void	setValue( const int & );

private:

	int	theValue;
	//
};

SomeClass.cpp
-------------

DEFINE_METACLASS( SomeClass );

// Start user code

SomeClass.clmc (my own syntax for the moment)
--------------

(defclass corelinux::SomeClass 
	(defproperty "Value" : native=int)
	(defmetaproperty "Parents" {MetaClassRoot}) 	
)


the parser reads the clmc file and generates an mci (metaclass include)
and mcd (metaclass definition), such that when DECLARE_METACLASS expands
to (for example)

#include	<MetaClassSomeClass.mci>
// which expands to a inner class and SomeClass statics (such as class
pointer and accessors for it)

And DEFINE_METACLASS expands to include the "mcd" file which is
fundementally what we now have in macros, with the addition that the
initializer adds itself to the Ontology target (in this example
corelinux).

Note1: See the defproperty and defmetaproperty? The former refers to
properties as declared by the user for the class instances, whereas the
defmetaproperty is a relationship for the metaclass instance only. Other
metaproperties could be added that would enable implementation level
semantics to be integrated in for use by the end-user applications.

This is the first point, I will wait before raising any others.
Thoughts?

-- 
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] MetaClass parser

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

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


> The parser abstraction is not where I see problems, it is the
> metatype/metaclass aspect especially one of synchronization. Once you
> generate something, and it is edited, how do you preserve it.
I don't understand the question
my idea was to generate a separate file for each class containing meta=20
informations and the file/meta informations would be regenerated whenever=
 the=20
interface is changed. in this case 'make' would do the job.
Am I missing something ? I think I am :(

> Now that I see you are open to the converstation, I will gather my
> thoughts and present a bigger document here to start with. In the
> meantime, you may want to consider RDF as a syntax for the type
> definitions.
I am afraid to ask: what is RDF ? is it the file format (called RDF also)=
=20
derived from xml that is used for example by news site ? or is it somethi=
ng =20
altogether different ?

I was planning to write a parser/generator in flex/bison that would extra=
ct=20
the meta informations with the help of one or two macros.

C.
- --=20
     Christophe Prud'homme                    |
     MIT, 77, Mass Ave, Rm 3-243              |     To err is human,
     Cambridge MA 02139                       |     to repent, divine,
     Tel (Office) : (00 1) (617) 253 0229     |     to persist, devilish.
     Fax (Office) : (00 1) (617) 258 8559     |     -- Benjamin Franklin
     http://augustine.mit.edu/~prudhomm       |
     ICQ UIN: 24560867 Alias: Jesunix         |
                          Following the hacker spirit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjqVpCMACgkQoY+0C9S+FFDUrwCff34GtRPGtLB0VTZllLeFQwMs
sbYAnj6iYKD+753OxH9o/60PlaNn2FUb
=3Da0UG
-----END PGP SIGNATURE-----

Re: [Corelinux-develop] MetaClass parser

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

Christophe Prud'homme wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> > Methinks that before you attempt writing anything we should discuss the
> > pitfalls and perils with such tools.
> I am open to discussion.
> The problem I see is to build a generic parser that could be extended in some
> sense by the user/programmer.
> In order to understand correctly the meta object concept I wrote my own meta
> object system. it is designed for a certain domain and it contains the same
> kind of features as your design.
> the parser in this case is not that difficult to implement.
> in the corelinux case, it is another story but worth the thinking.

The parser abstraction is not where I see problems, it is the
metatype/metaclass aspect especially one of synchronization. Once you
generate something, and it is edited, how do you preserve it.

> >
> > If you feel comfortable after that, I have some requirement/ideas I
> > would like to brush past you.
> what are they ?

Now that I see you are open to the converstation, I will gather my
thoughts and present a bigger document here to start with. In the
meantime, you may want to consider RDF as a syntax for the type
definitions.

> 
> C.
> - --
> Christophe Prud'homme
> OOA and OOD for Linux
> CoreLinux -- http://corelinux.sourceforge.net
> Finite Element Method Codes
> KFem      -- http://kfem.sourceforge.net
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.4 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iEYEARECAAYFAjqVfLAACgkQoY+0C9S+FFB0YwCePLtTy5wKII+X05t9a6klHWIx
> +M0AnjGagnPgAVX1AbqyYW3K1nA/KON0
> =7ILH
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/lists/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] MetaClass parser

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

Hans - Dulimarta wrote:
> 
> On Thu, 22 Feb 2001, Frank V. Castellucci wrote:
> 
> > Christophe,
> >
> > Methinks that before you attempt writing anything we should discuss the
> > pitfalls and perils with such tools.
> >
> > If you feel comfortable after that, I have some requirement/ideas I
> > would like to brush past you.
> >
> > Hans, anything to add? Busy? :)
> >
> 
> Yeah, the robotic project that I am working on now is at its final stage.
> It will be over by the middle of this year. I have been spending most of
> my time on this robotic project and also applying for some other positions
> in the country. So, if you know somebody / someplace is hiring, please
> also let me know :-)

What is it you want to do? Do you need a sponser?

> Back to our project: Now I see that CL has three paths of development,
> corelinux, clfw, clfll. Which one should I work on?

Well, clfll is really a enabler for the abstract library load in clfw.

Most of the work will be in clfw in:

1. Creating collection primitives as MetaTypes
2. Possible re-implementation of MetaType and MetaClass (more on this
later)
3. Design and Implementation of Persist abstraction
4. Enablers (like clfll) for the Persist (MySQL, DBM, flat file, etc.)
5. Research through to design for creating a JDNI type framework in C++
(clfw of course)
6. I'll stop here :)


> 
> >
> 
> --
> Hans Dulimarta, Ph.D. |                dul...@co...
> Research Associate    |     http://www.egr.msu.edu/~dulimart
> P: 517-432-7589       |     http://corelinux.sourceforge.net
> F: 760-281-7691     http://freshmeat.net/projects/snapsource
> Elec. & Comp. Engg., Mich. State Univ., E. Lansing, MI 48824
> 
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/lists/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] MetaClass parser

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

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


> Methinks that before you attempt writing anything we should discuss the
> pitfalls and perils with such tools.
I am open to discussion.=20
The problem I see is to build a generic parser that could be extended in =
some=20
sense by the user/programmer.=20
In order to understand correctly the meta object concept I wrote my own m=
eta=20
object system. it is designed for a certain domain and it contains the sa=
me=20
kind of features as your design.
the parser in this case is not that difficult to implement.
in the corelinux case, it is another story but worth the thinking.

>
> If you feel comfortable after that, I have some requirement/ideas I
> would like to brush past you.
what are they ?

C.
- --=20
Christophe Prud'homme=20
OOA and OOD for Linux
CoreLinux -- http://corelinux.sourceforge.net
Finite Element Method Codes
KFem      -- http://kfem.sourceforge.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjqVfLAACgkQoY+0C9S+FFB0YwCePLtTy5wKII+X05t9a6klHWIx
+M0AnjGagnPgAVX1AbqyYW3K1nA/KON0
=3D7ILH
-----END PGP SIGNATURE-----

Re: [Corelinux-develop] MetaClass parser

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

On Thu, 22 Feb 2001, Frank V. Castellucci wrote:

> Christophe,
>
> Methinks that before you attempt writing anything we should discuss the
> pitfalls and perils with such tools.
>
> If you feel comfortable after that, I have some requirement/ideas I
> would like to brush past you.
>
> Hans, anything to add? Busy? :)
>

Yeah, the robotic project that I am working on now is at its final stage.
It will be over by the middle of this year. I have been spending most of
my time on this robotic project and also applying for some other positions
in the country. So, if you know somebody / someplace is hiring, please
also let me know :-)

Back to our project: Now I see that CL has three paths of development,
corelinux, clfw, clfll. Which one should I work on?

>

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

[Corelinux-develop] MetaClass parser

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

Christophe,

Methinks that before you attempt writing anything we should discuss the
pitfalls and perils with such tools.

If you feel comfortable after that, I have some requirement/ideas I
would like to brush past you.

Hans, anything to add? Busy? :)

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

Re: [Corelinux-develop] SourceForge Compile Farm has Debian!

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

Hans - Dulimarta wrote:
> 
> On Sat, 17 Feb 2001, Frank V. Castellucci wrote:
> 
> > Cool.
> >
> > Have fun in DC
> >
> > I've been thinking of something else for CoreLinux++, things that make
> > it more useful in a general sense like Wireless, Socket, Fax, etc.
> > support
> >
> > Thoughts? Hans?
> 
> I agree as long as it does not "violate" the initial specification
> requirements of CL.

Good point, and you are correct. I was thinking that if we create a
kinda of JNDI framework for supporting all the capability the same way
(if possible).

> Are you thinking of extending the support to the embedded Linux community?

Hmmmmm, we would have to shrink the core for that I would think. I also
don't know much about it.

> BTW, the traffic on the cl-public has been very low. Do you know who are
> the users of the CoreLinux++?

It never was that high volume.

> 
> >
> >
> > Christophe Prud'homme wrote:
> > >
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > > If you log onto cf.sourceforge.net using ssh you can select which
> > > > distribution to work under.
> > > cool
> > > > I don't know what tools may be on the debian if someone wants to check
> > > > it out.
> > > I'll check this out next week
> > > I am going down to washington DC for a few days
> > > In the mean time I'll think about the parser/meta object information generator
> > >
> > > as you may have seen I ahve updated the debian packages. I may be a debian
> > > developper next week so I have to be prepared:)
> > >
> > > best regards
> > > C.
> > >
> > > - --
> > > Christophe Prud'homme                |
> > > MIT, 77, Mass Ave, Rm 3-243          | Somebody once asked me if I thought sex
> > > Cambridge MA 02139                   | was dirty. I said, "It is if you're
> > > Tel (Office) : (00 1) (617) 253 0229 | doing it right."
> > > Fax (Office) : (00 1) (617) 258 8559 | -- Woody allen
> > > http://augustine.mit.edu/~prudhomm   |
> > > ICQ UIN: 24560867 Alias: Jesunix     |
> > >                           Following the hacker spirit
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: GnuPG v1.0.4 (GNU/Linux)
> > > Comment: For info see http://www.gnupg.org
> > >
> > > iEYEARECAAYFAjqO1YwACgkQoY+0C9S+FFDNtQCghXx5T+9eu0ThGCjZVCJuYuXl
> > > Qf8An3wkR/uj/k71B9RDP760SLwhUDiX
> > > =o81W
> > > -----END PGP SIGNATURE-----
> > >
> > > _______________________________________________
> > > Corelinux-develop mailing list
> > > Cor...@li...
> > > http://lists.sourceforge.net/lists/listinfo/corelinux-develop
> >
> >
> 
> --
> Hans Dulimarta, Ph.D. |                dul...@co...
> Research Associate    |     http://www.egr.msu.edu/~dulimart
> P: 517-432-7589       |     http://corelinux.sourceforge.net
> F: 760-281-7691     http://freshmeat.net/projects/snapsource
> Elec. & Comp. Engg., Mich. State Univ., E. Lansing, MI 48824
> 
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/lists/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] SourceForge Compile Farm has Debian!

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

On Sat, 17 Feb 2001, Frank V. Castellucci wrote:

> Cool.
>
> Have fun in DC
>
> I've been thinking of something else for CoreLinux++, things that make
> it more useful in a general sense like Wireless, Socket, Fax, etc.
> support
>
> Thoughts? Hans?

I agree as long as it does not "violate" the initial specification
requirements of CL.
Are you thinking of extending the support to the embedded Linux community?

BTW, the traffic on the cl-public has been very low. Do you know who are
the users of the CoreLinux++?

>
>
> Christophe Prud'homme wrote:
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > > If you log onto cf.sourceforge.net using ssh you can select which
> > > distribution to work under.
> > cool
> > > I don't know what tools may be on the debian if someone wants to check
> > > it out.
> > I'll check this out next week
> > I am going down to washington DC for a few days
> > In the mean time I'll think about the parser/meta object information generator
> >
> > as you may have seen I ahve updated the debian packages. I may be a debian
> > developper next week so I have to be prepared:)
> >
> > best regards
> > C.
> >
> > - --
> > Christophe Prud'homme                |
> > MIT, 77, Mass Ave, Rm 3-243          | Somebody once asked me if I thought sex
> > Cambridge MA 02139                   | was dirty. I said, "It is if you're
> > Tel (Office) : (00 1) (617) 253 0229 | doing it right."
> > Fax (Office) : (00 1) (617) 258 8559 | -- Woody allen
> > http://augustine.mit.edu/~prudhomm   |
> > ICQ UIN: 24560867 Alias: Jesunix     |
> >                           Following the hacker spirit
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.0.4 (GNU/Linux)
> > Comment: For info see http://www.gnupg.org
> >
> > iEYEARECAAYFAjqO1YwACgkQoY+0C9S+FFDNtQCghXx5T+9eu0ThGCjZVCJuYuXl
> > Qf8An3wkR/uj/k71B9RDP760SLwhUDiX
> > =o81W
> > -----END PGP SIGNATURE-----
> >
> > _______________________________________________
> > Corelinux-develop mailing list
> > Cor...@li...
> > http://lists.sourceforge.net/lists/listinfo/corelinux-develop
>
>

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

Re: [Corelinux-develop] Corelinux meta object compiler

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

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


> Sounds good, see my other message about abstractions and ultimate
> flexibility.
> We can then implement how-ever we want, yes?
I'll see what I can do about that=20

Ok I have to go now

see ya in wednesday
and first Meta Object Compiler next week end I hope

C.
- --=20
 Christophe Prud'homme                |
 MIT, 77, Mass Ave, Rm 3-243          |
 Cambridge MA 02139                   |  Man is the only animal that blus=
hes
 Tel (Office) : (00 1) (617) 253 0229 |  or needs to.
 Fax (Office) : (00 1) (617) 258 8559 |  -- Mark Twain
 http://augustine.mit.edu/~prudhomm   |
 ICQ UIN: 24560867 Alias: Jesunix     |
                          Following the hacker spirit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjqO32IACgkQoY+0C9S+FFDT+ACbBkey4dbmiKVUtUpTPgZPlv2T
jxMAnj/n0PIFQyAWyh6JLxSiMmDSqzIY
=3DN0zY
-----END PGP SIGNATURE-----