Menu
▾
▴
corelinux-develop
|
From: Frank V. C. <fr...@co...> - 2001-02-24 02:06:07
|
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 |
|
From: Hans - D. <dul...@eg...> - 2001-02-24 06:08:17
|
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
|
|
From: Frank V. C. <fr...@co...> - 2001-02-24 12:13:05
|
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
|
|
From: Hans - D. <dul...@eg...> - 2001-02-24 14:11:50
|
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 |
|
From: Frank V. C. <fr...@co...> - 2001-02-24 16:25:04
|
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 |
|
From: Hans D. <dul...@eg...> - 2001-02-24 20:38:03
|
"Frank V. Castellucci" wrote: > > Hans - Dulimarta wrote: > > > > On Sat, 24 Feb 2001, Frank V. Castellucci wrote: > > > > > > 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... > I just use the Task Manager facility on SourceForge and found the above task is unassigned and 0% complete. Probably this is not up to date. |
|
From: Frank V. C. <fr...@co...> - 2001-02-25 11:37:03
|
Hans, Sometimes I just close them without updating the compete %. Filter on only "open" ones. But there are still open "feature/defects" in Bug Tracker if you want to take any of those out, like: Coming up with a per Thread Signal Mask management thingy. That, in my mind, would complete the Thread work. Another one is, maybe, seeing if there are thread patterns worth developing, or thread pools. If that doesn't interest you, how about: Analysis/Design/Implementation of a framework similar to Java's JNDI? Hans Dulimarta wrote: > > "Frank V. Castellucci" wrote: > > > > Hans - Dulimarta wrote: > > > > > > On Sat, 24 Feb 2001, Frank V. Castellucci wrote: > > > > > > > > > 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... > > > > I just use the Task Manager facility on SourceForge and found the above > task is > unassigned and 0% complete. Probably this is not up to date. > > _______________________________________________ > 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: Hans - D. <dul...@eg...> - 2001-02-26 16:23:01
|
On Sun, 25 Feb 2001, Frank V. Castellucci wrote: > Hans, > > Sometimes I just close them without updating the compete %. Filter on > only "open" ones. > > But there are still open "feature/defects" in Bug Tracker if you want to > take any of those out, like: > > Coming up with a per Thread Signal Mask management thingy. That, in my > mind, would complete the Thread work. > OK. I'll take this task. > Another one is, maybe, seeing if there are thread patterns worth > developing, or thread pools. > > If that doesn't interest you, how about: > > Analysis/Design/Implementation of a framework similar to Java's JNDI? > I'm still learning Java. This JNDI thingy is new to me. -- 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 |
