corelinux-develop

[Corelinux-develop] conclusions of the previous g++ related threads

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

Ok let's have a short description of what happened:

- g++ 2.96 is more c++ compliant and find a lot more erronous code
  * in you throw an exception in a member function of a class 
    be careful with its signature in any subclasses that is don't forget to   
    write throw(exceptxxx)
  * g++ is even more restrictive also for type correctness
    2.95 let int (*) (ThreadContext*) converted automatically to int (*)      
    (void*) without explicit casting
    2.96 doesn't allow it without an explicit cast
    solution: 
     typedef int (* CloneFunctionType)(void *);

     CloneFunctionType(ThreadContext::cloneFrameFunction)

    in Thread.cpp
   * friend foo is wrong 
      friend class foo is correct

All those changes have been done (plus the cpp one with ##) in my corelinux 
copy.
I need to create some defects for this but also for the new libcorelinux-dbg
packages(I didn't create it for redhat yet) and the changes for the macros 
arguments (mentionned a while ago now)

when is the next release ?
will we release also the first clfw ?

regards
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
                          Following the hacker spirit

Re: [Corelinux-develop] conclusions of the previous g++ related threads

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

Christophe Prud'homme wrote:
> 
> Ok let's have a short description of what happened:
> 
> - g++ 2.96 is more c++ compliant and find a lot more erronous code
>   * in you throw an exception in a member function of a class
>     be careful with its signature in any subclasses that is don't forget to
>     write throw(exceptxxx)
>   * g++ is even more restrictive also for type correctness
>     2.95 let int (*) (ThreadContext*) converted automatically to int (*)
>     (void*) without explicit casting
>     2.96 doesn't allow it without an explicit cast
>     solution:
>      typedef int (* CloneFunctionType)(void *);
> 
>      CloneFunctionType(ThreadContext::cloneFrameFunction)
> 
>     in Thread.cpp
>    * friend foo is wrong
>       friend class foo is correct
> 
> All those changes have been done (plus the cpp one with ##) in my corelinux
> copy.
> I need to create some defects for this but also for the new libcorelinux-dbg
> packages(I didn't create it for redhat yet) and the changes for the macros
> arguments (mentionned a while ago now)
> 
> when is the next release ?

Hans may more may not have anything for libcorelinux, in which case just
let me know. I didn't add anything to core.

> will we release also the first clfw ?

I have been grappling with the desire/need for Class class in clfw as it
would be a very useful way to capture desclarative information about
objects. For example, LibraryObjectDefinitions could be an object that
describes alot of stuff about the object it represents, as well as being
it's factory and re-director. As you know, we start to step into the
mini-marshaling domain (CORBA like) and that is not small things to
consider.

So there are some downsides to a quasi-static Class in the library
themselves. One solution is to put in meta-object processing which could
take dynamic definitions (IDL-like) and work that way, but that is even
more management code required. I've done this, and it is very powerful,
very big, and some people may not like it.

I would like to continue this discussion. But, in the short term I have
no problem releasing a 0.0.0 of clfw with just the Library Load
abstraction, and quickly whack a FunctionLibrary together without the
benefit of a more intelligent framework.

Thoughts?

> 
> regards
> 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
>                           Following the hacker spirit
> _______________________________________________
> 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] conclusions of the previous g++ related threads

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

"Frank V. Castellucci" wrote:
> 
> Christophe Prud'homme wrote:
> >
> > Ok let's have a short description of what happened:
> >
> > - g++ 2.96 is more c++ compliant and find a lot more erronous code
> >   * in you throw an exception in a member function of a class
> >     be careful with its signature in any subclasses that is don't forget to
> >     write throw(exceptxxx)
> >   * g++ is even more restrictive also for type correctness
> >     2.95 let int (*) (ThreadContext*) converted automatically to int (*)
> >     (void*) without explicit casting
> >     2.96 doesn't allow it without an explicit cast
> >     solution:
> >      typedef int (* CloneFunctionType)(void *);
> >
> >      CloneFunctionType(ThreadContext::cloneFrameFunction)
> >
> >     in Thread.cpp
> >    * friend foo is wrong
> >       friend class foo is correct
> >
> > All those changes have been done (plus the cpp one with ##) in my corelinux
> > copy.
> > I need to create some defects for this but also for the new libcorelinux-dbg
> > packages(I didn't create it for redhat yet) and the changes for the macros
> > arguments (mentionned a while ago now)
> >
> > when is the next release ?

Wow, I feel like I am crawling like a turtle while you are running like
hares.

> 
> Hans may more may not have anything for libcorelinux, in which case just
> let me know. I didn't add anything to core.

My plan is to have a working EventSemaphore by this weekend. If after this
weekend
I don't have it, I won't include it in the coming release.

> 
> > will we release also the first clfw ?
> 
> I have been grappling with the desire/need for Class class in clfw as it
> would be a very useful way to capture desclarative information about
> objects. For example, LibraryObjectDefinitions could be an object that
> describes alot of stuff about the object it represents, as well as being
> it's factory and re-director. As you know, we start to step into the
> mini-marshaling domain (CORBA like) and that is not small things to
> consider.
> 
> So there are some downsides to a quasi-static Class in the library
> themselves. One solution is to put in meta-object processing which could
> take dynamic definitions (IDL-like) and work that way, but that is even
> more management code required. I've done this, and it is very powerful,
> very big, and some people may not like it.
> 
> I would like to continue this discussion. But, in the short term I have
> no problem releasing a 0.0.0 of clfw with just the Library Load
> abstraction, and quickly whack a FunctionLibrary together without the
> benefit of a more intelligent framework.
> 
> Thoughts?
> 
> >
> > regards
> > 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
> >                           Following the hacker spirit
> > _______________________________________________
> > 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
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-develop

-- 
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] conclusions of the previous g++ related threads

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

Hans Dulimarta wrote:
> 
> "Frank V. Castellucci" wrote:
> >
> > Christophe Prud'homme wrote:
> > >
> > > Ok let's have a short description of what happened:
> > >
> > > - g++ 2.96 is more c++ compliant and find a lot more erronous code
> > >   * in you throw an exception in a member function of a class
> > >     be careful with its signature in any subclasses that is don't forget to
> > >     write throw(exceptxxx)
> > >   * g++ is even more restrictive also for type correctness
> > >     2.95 let int (*) (ThreadContext*) converted automatically to int (*)
> > >     (void*) without explicit casting
> > >     2.96 doesn't allow it without an explicit cast
> > >     solution:
> > >      typedef int (* CloneFunctionType)(void *);
> > >
> > >      CloneFunctionType(ThreadContext::cloneFrameFunction)
> > >
> > >     in Thread.cpp
> > >    * friend foo is wrong
> > >       friend class foo is correct
> > >
> > > All those changes have been done (plus the cpp one with ##) in my corelinux
> > > copy.
> > > I need to create some defects for this but also for the new libcorelinux-dbg
> > > packages(I didn't create it for redhat yet) and the changes for the macros
> > > arguments (mentionned a while ago now)
> > >
> > > when is the next release ?
> 
> Wow, I feel like I am crawling like a turtle while you are running like
> hares.

In the Cathedral and the Bazaar, the credo is "Release Early and Release
Often". While I don't always agree with that, it is an indicator to the
community that there is activity in the project. In addition, because
systems we rely on (compilers,etc.) change, it is inevitable that users
will go to those and end up reporting this things as errors anyway. So
being proactive is a good thing.

> 
> >
> > Hans may more may not have anything for libcorelinux, in which case just
> > let me know. I didn't add anything to core.
> 
> My plan is to have a working EventSemaphore by this weekend. If after this
> weekend
> I don't have it, I won't include it in the coming release.

Cool, I made comments to you follow up message.

> 
> >
> > > will we release also the first clfw ?
> >
> > I have been grappling with the desire/need for Class class in clfw as it
> > would be a very useful way to capture desclarative information about
> > objects. For example, LibraryObjectDefinitions could be an object that
> > describes alot of stuff about the object it represents, as well as being
> > it's factory and re-director. As you know, we start to step into the
> > mini-marshaling domain (CORBA like) and that is not small things to
> > consider.
> >
> > So there are some downsides to a quasi-static Class in the library
> > themselves. One solution is to put in meta-object processing which could
> > take dynamic definitions (IDL-like) and work that way, but that is even
> > more management code required. I've done this, and it is very powerful,
> > very big, and some people may not like it.
> >
> > I would like to continue this discussion. But, in the short term I have
> > no problem releasing a 0.0.0 of clfw with just the Library Load
> > abstraction, and quickly whack a FunctionLibrary together without the
> > benefit of a more intelligent framework.
> >
> > Thoughts?
> >
> > >
> > > regards

-- 
Frank V. Castellucci

Re: [Corelinux-develop] conclusions of the previous g++ related threads

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

Huh

sorry I forgot to thank Gaby for his help and the light he shade on the 
various c++ topics.

thanks again

C.
-- 
     Christophe Prud'homme                    |
     MIT, 77, Mass Ave, Rm 3-243              |
     Cambridge MA 02139                       |     Friends are relatives
     Tel (Office) : (00 1) (617) 253 0229     |     you make for yourself.
     Fax (Office) : (00 1) (617) 258 8559     |
     http://augustine.mit.edu/~prudhomm       |
                          Following the hacker spirit

Re: [Corelinux-develop] conclusions of the previous g++ related threads

[Gabriel D. R. <Gab...@cm...>]

"Christophe Prud'homme" <pru...@MI...> writes:

| Huh
| 
| sorry I forgot to thank Gaby

Well, there is no need to: I'm just finding a way to help.

-- Gaby

Re: [Corelinux-develop] conclusions of the previous g++ related threads

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

> I would like to continue this discussion. But, in the short term I have
> no problem releasing a 0.0.0 of clfw with just the Library Load
> abstraction, and quickly whack a FunctionLibrary together without the
> benefit of a more intelligent framework.

Ok we can release something like corelinux bug fixes/updates
and a clfw preview technology release

A short note on my disponibilities, I would not mind begin working on clfw, 
unfortunately I am very busy until beginning of october. and then I will be 
able to work at full power for corelinux :). I can only do quick things so 
that my projects integrate well with corelinux.


-- 
     Christophe Prud'homme                    |
     MIT, 77, Mass Ave, Rm 3-243              |
     Cambridge MA 02139                       |     Friends are relatives
     Tel (Office) : (00 1) (617) 253 0229     |     you make for yourself.
     Fax (Office) : (00 1) (617) 258 8559     |
     http://augustine.mit.edu/~prudhomm       |
                          Following the hacker spirit

Re: [Corelinux-develop] conclusions of the previous g++ related threads

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

Christophe Prud'homme wrote:
> 
> > I would like to continue this discussion. But, in the short term I have
> > no problem releasing a 0.0.0 of clfw with just the Library Load
> > abstraction, and quickly whack a FunctionLibrary together without the
> > benefit of a more intelligent framework.
> 
> Ok we can release something like corelinux bug fixes/updates
> and a clfw preview technology release

Ok, for the short term I am happy with a tarball release of clfw. I
really would like to learn the rpm spec stuff and will never do so until
you let me :)

> A short note on my disponibilities, I would not mind begin working on clfw,
> unfortunately I am very busy until beginning of october. and then I will be
> able to work at full power for corelinux :). I can only do quick things so
> that my projects integrate well with corelinux.

You have contributed more than you ever will realize I suppose, and I am
certainly not anxious about anything. Decisions like the Class class
thing are not easy ones to make. Class libraries are by far and away one
of the more difficult things to produce because you need to anticipate
large use-case scenarios. Without collaboration, it is almost
impossible.

> 
> --
>      Christophe Prud'homme                    |
>      MIT, 77, Mass Ave, Rm 3-243              |
>      Cambridge MA 02139                       |     Friends are relatives
>      Tel (Office) : (00 1) (617) 253 0229     |     you make for yourself.
>      Fax (Office) : (00 1) (617) 258 8559     |
>      http://augustine.mit.edu/~prudhomm       |
>                           Following the hacker spirit
> _______________________________________________
> 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] conclusions of the previous g++ related threads

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

> Ok, for the short term I am happy with a tarball release of clfw. I
> really would like to learn the rpm spec stuff and will never do so until
> you let me :)
just play with corelinux.spec
that's how I did it (the good old trial and error)

-- 
  Christophe Prud'homme                  |
  MIT, 77, Mass Ave, Rm 3-243            |   In theory, theory and practice
  Cambridge MA 02139                     |   are the same. In practice they
  Tel (Office) : (00 1) (617) 253 0229   |   are different.
  Fax (Office) : (00 1) (617) 258 8559   |
  http://augustine.mit.edu/~prudhomm     |
                          Following the hacker spirit