|
From: Frank V. C. <fr...@co...> - 2001-02-22 15:50:05
|
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 |
|
From: Hans - D. <dul...@eg...> - 2001-02-22 16:12:32
|
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 |
|
From: Frank V. C. <fr...@co...> - 2001-02-22 21:40:17
|
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 |
|
From: Christophe Prud'h. <pru...@us...> - 2001-02-22 20:54:51
|
-----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----- |
|
From: Frank V. C. <fr...@co...> - 2001-02-22 21:42:45
|
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 |
|
From: Christophe Prud'h. <pru...@MI...> - 2001-02-22 23:42:42
|
-----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-----
|