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

Re: [Corelinux-develop] exception and inheritance

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

Christophe Prud'homme wrote:
> 
> YAROGT again!
> 
> I cannot verify this in a C++ textbook/reference, I don't have one handy
> but
> 
> say that we have
> class A
> {
> public:
>   virtual void f() throw(exceptA);
> }
> 
> class B : public A
> {
>   public:
> 
> // f redefined
> void f(); // is it ok?
> void f() throw(exceptA); // or is it this one? or both?
> 
> }
> 
> it seems that in 2.96 the first one is rejected
> the second one is the correct one
> I would say that the true prototype is the second one
> the first one is another function which does not throw any exceptions

This is a very good thing! 

> 
> any c++ guru?
> I miss my stroustrup badly now
> 
> in ex6 I got a compilation problem whith that!

Great! We want to add the correct signatures now. I get lazy, and now
the compiler forces me to do it right. I love it.

Are you entering defects for these? That way you aren't saddled with all
the work. The other thing is that any changes made can NOT cause errors
with 2.95.2
> 
> C.
> --
>    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
> 
> _______________________________________________
> 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] fix for cpp warning

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

with g++ 2.95 and 2.96 the following works fine and gives no warning

#define A( tag ) a::tag

whereas 

#define Ap( tag ) a::##tag

gives a warning message for 2.96

a is a namespace of course

comments?

C.
-- 
  Christophe Prud'homme                 |
  MIT, 77, Mass Ave, Rm 3-243           |  The Second Law of Thermodynamics:
  Cambridge MA 02139                    |  If you think things are in a mess
  Tel (Office) : (00 1) (617) 253 0229  |   now, just wait!
  Fax (Office) : (00 1) (617) 258 8559  |  -- Jim Warner
  http://augustine.mit.edu/~prudhomm    |
                          Following the hacker spirit

[Corelinux-develop] exception and inheritance

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

YAROGT again!

I cannot verify this in a C++ textbook/reference, I don't have one handy
but

say that we have 
class A
{
public:
  virtual void f() throw(exceptA);
}

class B : public A
{
  public:

// f redefined
void f(); // is it ok?
void f() throw(exceptA); // or is it this one? or both?

}

it seems that in 2.96 the first one is rejected 
the second one is the correct one
I would say that the true prototype is the second one
the first one is another function which does not throw any exceptions

any c++ guru?
I miss my stroustrup badly now

in ex6 I got a compilation problem whith that!

C.
-- 
   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

Re: [Corelinux-develop] YAROGT Part II

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

Christophe Prud'homme wrote:
> 
> Hi
> it is Yet Another Round Of G++ Test !
> 
> with g++ 2.96 22/08/2000 (BTW you can have the RPM at
> http://www.codesourcery.com/gcc-snapshots/ )
> 
> * Guard is a private inner class of Synchronized therefore it can be used in
>   any subclasses which is done in several places
>   fix: private -> protected

But the access of Synchronized returns the Guard instance. It needs to
be an instance without taking the address so that it goes out of scope
and releases the lock.


> * other incomplete friend declaration (without the class token)

Well, with my style of class fowarding. 

> * problem in Thread.cpp
> ../../../../src/classlibs/corelinux/Thread.cpp:285: cannot convert `Int (*)
> (corelinux::ThreadContext *)' to
> `int (*) (void *)' for argument `1' to `clone (int (*) (void *), void *, int,
> void *)'
> 
> I'll try to fix it
> 
> so far only the last one and the cpp warning have not been fixed
> 
> I am still amazed how the current stable g++ handle the problems I mentioned
> there is black magic and dark evil involved here.
> 
> C.
> --
>     Christophe Prud'homme                   |    So so is good, very good,
>     MIT, 77, Mass Ave, Rm 3-243             |    very excellent good:
>     Cambridge MA 02139                      |    and yet it is not;
>     Tel (Office) : (00 1) (617) 253 0229    |    it is but so so.
>     Fax (Office) : (00 1) (617) 258 8559    |    -- William Shakespeare,
>     http://augustine.mit.edu/~prudhomm      |    "As You Like It"
>                           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] YAROGT part I

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

Christophe Prud'homme wrote:
> 
> > > * class is missing in Friend declaraion in Synchronized.hpp
> >
> > don't need it because it is foward declared in
> > DECLARE_CLASS(Synchronized) as per C++ standard.
> > Are you getting an error?
> Yes !

Ok, interesting, I'll re-review the C++ standard 1998(E)

> 
> > > * warning with corelinux::##tag (common.hpp) don't know yet how to fix it
> >
> > whats the warning?
> can't paste tag after token
> I''l send an email to the gcc dev mailing list

ok

> 
> > > BTW Frank why do you need to do this
> > >
> > > #if   !defined(__ITERATOR_HPP)
> > > #include <Iterator.hpp>
> > > #endif
> > >
> > > since it is done already in Iterator.hpp ?
> >
> > Please elucidate?
> 
> In any file you include, for example, Iterator.hpp
> 
> you do what I wrote a few lines above
> but in Iterator.hpp, you do
> 
> #if   !defined(__ITERATOR_HPP)
> #define  __ITERATOR_HPP
> 
> the code
> 
> #endif
> 
> so you do the same thing twice, you don't need to check Iterator.hpp multiple
> inclusion since it is handled by the header file itself !!

But in the calling module, if the compiler has already done it, it won't
have to incur the disk I/O of opening Iterator.hpp again.

> 
> --
>  Christophe Prud'homme                |
>  MIT, 77, Mass Ave, Rm 3-243          |
>  Cambridge MA 02139                   |  All laws are simulations of reality.
>  Tel (Office) : (00 1) (617) 253 0229 |  -- John C. Lilly
>  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

[Corelinux-develop] g++ 2.96

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

with g++ 2.96 lots of bugs and warning can be found 
you can have the RPM at http://www.codesourcery.com/gcc-snapshots/

don't forget to check the Testsuite results for g++ and gcc
and look at the number of unexpected failures !!
in the 23/08 snapshot there are 895 unexpected failures
and in the 22/08 only 4 !!
so always take the one with the lowest number of unexpected errors!!

C.
-- 
   Christophe Prud'homme                  |
   MIT, 77, Mass Ave, Rm 3-243            |    Do nothing unless you must,
   Cambridge MA 02139                     |    and when you must act
   Tel (Office) : (00 1) (617) 253 0229   |    -- hesitate.
   Fax (Office) : (00 1) (617) 258 8559   |
   http://augustine.mit.edu/~prudhomm     |
                          Following the hacker spirit

Re: [Corelinux-develop] YAROGT part I

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

> > * class is missing in Friend declaraion in Synchronized.hpp
>
> don't need it because it is foward declared in
> DECLARE_CLASS(Synchronized) as per C++ standard.
> Are you getting an error?
Yes !

> > * warning with corelinux::##tag (common.hpp) don't know yet how to fix it
>
> whats the warning?
can't paste tag after token 
I''l send an email to the gcc dev mailing list

> > BTW Frank why do you need to do this
> >
> > #if   !defined(__ITERATOR_HPP)
> > #include <Iterator.hpp>
> > #endif
> >
> > since it is done already in Iterator.hpp ?
>
> Please elucidate?

In any file you include, for example, Iterator.hpp 

you do what I wrote a few lines above
but in Iterator.hpp, you do

#if   !defined(__ITERATOR_HPP)
#define  __ITERATOR_HPP

the code 

#endif

so you do the same thing twice, you don't need to check Iterator.hpp multiple 
inclusion since it is handled by the header file itself !!

-- 
 Christophe Prud'homme                |
 MIT, 77, Mass Ave, Rm 3-243          |
 Cambridge MA 02139                   |  All laws are simulations of reality.
 Tel (Office) : (00 1) (617) 253 0229 |  -- John C. Lilly
 Fax (Office) : (00 1) (617) 258 8559 |
 http://augustine.mit.edu/~prudhomm   |
                          Following the hacker spirit

[Corelinux-develop] YAROGT Part II

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

Hi
it is Yet Another Round Of G++ Test !

with g++ 2.96 22/08/2000 (BTW you can have the RPM at 
http://www.codesourcery.com/gcc-snapshots/ )


* Guard is a private inner class of Synchronized therefore it can be used in  
  any subclasses which is done in several places
  fix: private -> protected
* other incomplete friend declaration (without the class token)
* problem in Thread.cpp
../../../../src/classlibs/corelinux/Thread.cpp:285: cannot convert `Int (*) 
(corelinux::ThreadContext *)' to 
`int (*) (void *)' for argument `1' to `clone (int (*) (void *), void *, int, 
void *)'

I'll try to fix it

so far only the last one and the cpp warning have not been fixed

I am still amazed how the current stable g++ handle the problems I mentioned
there is black magic and dark evil involved here.

C.
-- 
    Christophe Prud'homme                   |    So so is good, very good,
    MIT, 77, Mass Ave, Rm 3-243             |    very excellent good:
    Cambridge MA 02139                      |    and yet it is not;
    Tel (Office) : (00 1) (617) 253 0229    |    it is but so so.
    Fax (Office) : (00 1) (617) 258 8559    |    -- William Shakespeare,
    http://augustine.mit.edu/~prudhomm      |    "As You Like It"
                          Following the hacker spirit

Re: [Corelinux-develop] YAROGT part I

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

Christophe Prud'homme wrote:
> 
> Hi
> it is Yet Another Round Of G++ Test !
> 
> I try to track some compilations problems :
> 
> * missing #include <IteratorBoundsException.hpp> in Iterator.hpp
>   might cause big trouble with exception since nothing is know about this
>   class at compile time. This problem occur in other place
>   the compiler needs the class interface at compile time !!!

Oops

> * class is missing in Friend declaraion in Synchronized.hpp

don't need it because it is foward declared in
DECLARE_CLASS(Synchronized) as per C++ standard. 
Are you getting an error?

> * warning with corelinux::##tag (common.hpp) don't know yet how to fix it

whats the warning?

> 
> BTW Frank why do you need to do this
> 
> #if   !defined(__ITERATOR_HPP)
> #include <Iterator.hpp>
> #endif
> 
> since it is done already in Iterator.hpp ?

Please elucidate? 

> 
> more to come (may be)
> C.
> 
> --
> Christophe Prud'homme                |
> MIT, 77, Mass Ave, Rm 3-243          | He that breaks a thing to find out
> Cambridge MA 02139                   | what it is has left the path of wisdom.
> Tel (Office) : (00 1) (617) 253 0229 | -- J.R.R. Tolkien
> 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

[Corelinux-develop] YAROGT part I

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

Hi
it is Yet Another Round Of G++ Test !

I try to track some compilations problems :

* missing #include <IteratorBoundsException.hpp> in Iterator.hpp
  might cause big trouble with exception since nothing is know about this     
  class at compile time. This problem occur in other place
  the compiler needs the class interface at compile time !!!
* class is missing in Friend declaraion in Synchronized.hpp
* warning with corelinux::##tag (common.hpp) don't know yet how to fix it

BTW Frank why do you need to do this

#if   !defined(__ITERATOR_HPP)
#include <Iterator.hpp>
#endif

since it is done already in Iterator.hpp ?


more to come (may be)
C.

-- 
Christophe Prud'homme                |
MIT, 77, Mass Ave, Rm 3-243          | He that breaks a thing to find out
Cambridge MA 02139                   | what it is has left the path of wisdom.
Tel (Office) : (00 1) (617) 253 0229 | -- J.R.R. Tolkien
Fax (Office) : (00 1) (617) 258 8559 |
http://augustine.mit.edu/~prudhomm   |
                          Following the hacker spirit

Re: [Corelinux-develop] Questions, Questions, and Questions.

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

Hans Dulimarta wrote:
> 
> Frank encouraged me to keep asking question and now I do :-).
> I am trying to understand the SemaphoreCommon class and
> would like to ask the following questions:
> 
> 1. Why CSA is needed? Is it used for obtaining the key of semget()?
>    However, I also find SemaphoreGroup::tmpDir ("/tmp") and
>    SemaphoreGroup::tmpName (/tmp/clsgtemp.\d+) used by ftok to generate
>    the key, but I could not find the connection between CSA and ftok.

The CSA is the shared memory that libcorelinux library knows about and
relies on for enabling SemaphoreGroups to share the state of it's
semaphores BETWEEN two (2) or more processes. Without it, the state of a
semaphore in one process would be out of synchronization with other
processes that are sharing the semaphore group.

> 2. SemaphoreCommon defines members setLock and setUnLock which eventually
>    calls the Dijkstra's P()/down() and V()/up() operation.
>    To implement EventSemaphore, I am planning to use the "zero()"
> operation,
>    that is semop with sembuf.sem_op set to 0.
>    Will it be apropriate? If, yes, should a new member "setZero()" be added
>    to SemaphoreCommon?

Adding a setZero() to the base semaphore is no problem, but remember to
extend it over to the CSA.

> 
> I also have a couple of comments:
> 
> 1. SemaphoreCommon::setLock and SemaphoreCommon::setUnLock call
>    semop and pass 'ON' as the third actual parameter.
>    Semantically, 'ON' does not make sense to the call because
>    the third formal parameter of semop is 'number of semaphore operations'.

You may modify as you see fit. If you want to just run it by the mailing
list first with your decision, feel free.

> 
> 2. I think the constant ON and OFF in SemaphoreCommon are overloaded
>    for too many different context, in some cases sacrificing its semantics.
>    For instance, the semantic of "-ON" [minus ON] is not clear.

You may modify as you see fit. :)

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

[Corelinux-develop] Questions, Questions, and Questions.

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

Frank encouraged me to keep asking question and now I do :-).
I am trying to understand the SemaphoreCommon class and
would like to ask the following questions:

1. Why CSA is needed? Is it used for obtaining the key of semget()?
   However, I also find SemaphoreGroup::tmpDir ("/tmp") and 
   SemaphoreGroup::tmpName (/tmp/clsgtemp.\d+) used by ftok to generate
   the key, but I could not find the connection between CSA and ftok.

2. SemaphoreCommon defines members setLock and setUnLock which eventually
   calls the Dijkstra's P()/down() and V()/up() operation.
   To implement EventSemaphore, I am planning to use the "zero()"
operation,
   that is semop with sembuf.sem_op set to 0.
   Will it be apropriate? If, yes, should a new member "setZero()" be added
   to SemaphoreCommon?

I also have a couple of comments:

1. SemaphoreCommon::setLock and SemaphoreCommon::setUnLock call
   semop and pass 'ON' as the third actual parameter.
   Semantically, 'ON' does not make sense to the call because
   the third formal parameter of semop is 'number of semaphore operations'.

2. I think the constant ON and OFF in SemaphoreCommon are overloaded
   for too many different context, in some cases sacrificing its semantics.
   For instance, the semantic of "-ON" [minus ON] is not clear.

-- 
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] Frameworks

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

FROM: Christophe Prud`homme
DATE: 08/21/2000 15:06:37
SUBJECT: RE:  [Corelinux-develop] Frameworks
               

>> No, I don`t want to move clfw or any of the abstractions (Library Load,
>> Persist, etc.) that will go with it.
>>
>> When I create the FunctionLibraryLoad implementation, though, it should
>> be as separate as clfw is to corelinux.

> I see
> shouldn`t be a problem to achieve that
> however they will be source-packaged in clfw
> but for the binary packages we can create separate packages for each component
> actually that`s a good idea I think to modularise the frameworks as much as 
> possible, it is unlikely that all components will be all used 
> 
> May be it is also interesting to have all the components merged also in one 
> lib.
> So we would have
>   - separates modules to provide lightweight services
>   - one big lib to provide them all

No, thats not what I meant. Source package for clfw contains all main
framework utility, and all abstract frameworks.


And each framework implementation is separate. So for example, I might
have on my machine:

libcl++.so	(core)
libclfw++.so	(core framework and abstractions)
libclfwfl++.so	(function library load implementation)
libcpfl.so	(Christophe Prud`homme's function library load
implementation)

we provide (from a release perspective)

libcorelinux
libcoreframeworks
libfunctionlibraryload

capice?



-- 
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] Frameworks

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

> No, I don't want to move clfw or any of the abstractions (Library Load,
> Persist, etc.) that will go with it.
>
> When I create the FunctionLibraryLoad implementation, though, it should
> be as separate as clfw is to corelinux.
I see
shouldn't be a problem to achieve that
however they will be source-packaged in clfw
but for the binary packages we can create separate packages for each component
actually that's a good idea I think to modularise the frameworks as much as 
possible, it is unlikely that all components will be all used 

May be it is also interesting to have all the components merged also in one 
lib.
So we would have
- separates modules to provide lightweight services
- one big lib to provide them all


C.
-- 
  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 opinion.
  Fax (Office) : (00 1) (617) 258 8559  |   -- Chinese proverb
  http://augustine.mit.edu/~prudhomm    |
                          Following the hacker spirit

Re: [Corelinux-develop] Frameworks

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

Christophe Prud'homme wrote:
> 
> > the clfw should really be limited to abstract framework bases. In
> > otherwords, the FunctionLibrary loader implementation is a separate
> > deliverable that requires libclfrmwrk and libcorelinux.
> >
> > That way the user has the ability, in the long term, in substituting
> > which FunctionLibrary framework that they want to use. Or they can
> > create their own.
> >
> > I didn't want to force frameworks down anyones throat and this seemed
> > the most flexible. Thoughts?
> so you want to move it again ?

No, I don't want to move clfw or any of the abstractions (Library Load,
Persist, etc.) that will go with it.

When I create the FunctionLibraryLoad implementation, though, it should
be as separate as clfw is to corelinux.

> provide it as an example ?
> 
> --
>    Christophe Prud'homme                  |
>    MIT, 77, Mass Ave, Rm 3-243            |   Un prud'homme était un homme
>    Cambridge MA 02139                     |   d'honneur et de valeur,
>    Tel (Office) : (00 1) (617) 253 0229   |   sage et loyal.
>    Fax (Office) : (00 1) (617) 258 8559   |   -- Chateaubriand
>    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] Frameworks

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

> the clfw should really be limited to abstract framework bases. In
> otherwords, the FunctionLibrary loader implementation is a separate
> deliverable that requires libclfrmwrk and libcorelinux.
>
> That way the user has the ability, in the long term, in substituting
> which FunctionLibrary framework that they want to use. Or they can
> create their own.
>
> I didn't want to force frameworks down anyones throat and this seemed
> the most flexible. Thoughts?
so you want to move it again ?
provide it as an example ?

-- 
   Christophe Prud'homme                  |
   MIT, 77, Mass Ave, Rm 3-243            |   Un prud'homme était un homme
   Cambridge MA 02139                     |   d'honneur et de valeur,
   Tel (Office) : (00 1) (617) 253 0229   |   sage et loyal.
   Fax (Office) : (00 1) (617) 258 8559   |   -- Chateaubriand
   http://augustine.mit.edu/~prudhomm     |
                          Following the hacker spirit

[Corelinux-develop] Frameworks

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

Ok, some more thoughts.

the clfw should really be limited to abstract framework bases. In
otherwords, the FunctionLibrary loader implementation is a separate
deliverable that requires libclfrmwrk and libcorelinux.

That way the user has the ability, in the long term, in substituting
which FunctionLibrary framework that they want to use. Or they can
create their own.

I didn't want to force frameworks down anyones throat and this seemed
the most flexible. Thoughts?

-- 
Frank V. Castellucci

Re: [Corelinux-develop] Logo

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

Anyone?

"Frank V. Castellucci" wrote:
> 
> Six is getting the most positive feedback from people, then the Grey one
> (although they note that it is not scaled good for banners).
> 
> "Frank V. Castellucci" wrote:
> >
> > Or try
> > http://corelinux.sourceforge.net/logo.php
> >
> > to get the surrounding context.
> >
> > "Frank V. Castellucci" wrote:
> > >
> > > I put the ones that people responded to on
> > >
> > > http://corelinux.sourceforge.net/logo.html
> > >
> > > Hans Dulimarta wrote:
> > > >
> > > > "Frank V. Castellucci" wrote:
> > > > >
> > > > > This one I liked,
> > > > >
> > > > > http://mike.santos.tripod.com//sitebuildercontent/sitebuilderpictures/corelinux009.jpg
> > > >
> > > > May be we should put all the proposed logo on the CoreLinux++ web site so
> > > > we can easily compare
> > > > them side by side.
> > > >
> > > > >
> > > > > and the grey one that I think Hans kind of dug as well. I can't find it
> > > > > :)
> > > > >
> > > > > Frank
> > > > >
> > > > > _______________________________________________
> > > > > 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
> > > >
> > > > _______________________________________________
> > > > 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
> >
> > --
> > 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
> 
> --
> 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

-- 
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] stats

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

"Frank V. Castellucci" wrote:
> 
> Hans Dulimarta wrote:
> 
> Bull dung!!! The faster you all come up to speed, the less time it will
> be me doing the code <grin>, and more time I can spend on <shudder>
> LaTex, <yipes> PHP, and <dare I say> writing documentation.
> 
> >
> > I am an RTM kinda person. If it is documented somewhere, I'll read it and
> > then ask if something is not clear. [It may seem that I have been too
> > quiet,
> > not responsive enough to comments that you guys sent to the mailing list.
> > In fact, I've been studying how the implemented classes relate to the model
> > (UML
> > diagram stuffs)].
> 
> Now, if only there where a M for you to RTM of :)
> 

The  htdocs and models subdir are the source of my manual.

> 
> Besides the implementations of Gateway and Mutex, EventSemaphores are
> probably going to need some help from timers and signals, and you may
> find we need to implement those first. Which of course is based on
> Analysis and Design work in those areas.
> 
> > What guide(s) should I follow when writing a test driver?
> 
> Really something that could be considered a unit test (each interface
> being somehow excercised is the goal).
> 
> > In the implementation I saw SemaphoreCommon but not in the diagram? Any
> > explanation?
> 
> Yes, I was getting to the point that the SemaphoreCommon was much needed
> because of the "shared" requirement between address space hole. Now that
> it is done, I can update the diagrams, unless that is something you want
> to do to get used to the tools.

At the moment I would keep my models checkout in "read-only" mode.
MagicDraw
is a brand new tool for me. I still need guidance to navigate within the
tool.
I'll let you do the update.

> 
> > Oops.....I ask too much...better stop here... :-)
> 
> No, I would rather you keep asking questions. It will get you up to
> speed faster. I have alot I can say on any facet of the library that
> doesn't always come out in the current documentation.
> 
> >
> > >
> > > I don't think we have the boundry for the universe of discourse defined
> > > yet :)
> > >
> >
> > I'd rather leave it open....
> >
> > >
> > > --
> > > 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
> >
> > _______________________________________________
> > 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] stats

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

Hans Dulimarta wrote:
> 
> "Frank V. Castellucci" wrote:
> >
> > Then demand we slow down. Seriously, I'd rather you be involved in some
> 
> I don't want to slow down the project just because a rookie (that is me)
> came in....

Bull dung!!! The faster you all come up to speed, the less time it will
be me doing the code <grin>, and more time I can spend on <shudder>
LaTex, <yipes> PHP, and <dare I say> writing documentation.

> > of the neat stuff that we are just getting into a position to do. Of
> > course I think things like frameworks, excercising the language, and
> > providing some very serious implementation aids to other developers is
> > neat. :)
> >
> > The core is a jumping off point. Throw some conversation about Threads,
> > Semaphores, Frameworks around. We really can do so cool things at this
> > point.
> 
> I am an RTM kinda person. If it is documented somewhere, I'll read it and
> then ask if something is not clear. [It may seem that I have been too
> quiet,
> not responsive enough to comments that you guys sent to the mailing list.
> In fact, I've been studying how the implemented classes relate to the model
> (UML
> diagram stuffs)].

Now, if only there where a M for you to RTM of :)

> So far my exploration into the deep space
> of Semaphore "family tree" has given me enough understanding of it.
> 
> I infer the following:
> o All requirements for Semaphore (& co.) have been transfered into design.

check

> o A large portion of this design has been implemented

check

> o When the design mentions "SemaphoreIdentifier", the implementation views
> this as
>   SemGroupId + SemId.

Either or, correct

> o Low level system calls used for the implementation are semget, semctl,
> and semop.

check

> Some questions I'd like to ask.
> When I open an *.mdf file using MagicDraw, the left window pane shows a
> tree of
> clickable nodes. Which part of the (sub)tree(s) should I concentrate on
> browsing
> during the implementation.
> I understand that for the implementation of EventSemaphore (which is what
> I'm doing now)
> Many-To-One is one of the things I should concentrate. What else?

Besides the implementations of Gateway and Mutex, EventSemaphores are
probably going to need some help from timers and signals, and you may
find we need to implement those first. Which of course is based on
Analysis and Design work in those areas.

> What guide(s) should I follow when writing a test driver?

Really something that could be considered a unit test (each interface
being somehow excercised is the goal).

> In the implementation I saw SemaphoreCommon but not in the diagram? Any
> explanation?

Yes, I was getting to the point that the SemaphoreCommon was much needed
because of the "shared" requirement between address space hole. Now that
it is done, I can update the diagrams, unless that is something you want
to do to get used to the tools.

> Oops.....I ask too much...better stop here... :-)

No, I would rather you keep asking questions. It will get you up to
speed faster. I have alot I can say on any facet of the library that
doesn't always come out in the current documentation.

> 
> >
> > I don't think we have the boundry for the universe of discourse defined
> > yet :)
> >
> 
> I'd rather leave it open....
> 
> >
> > --
> > 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
> 
> _______________________________________________
> 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] stats

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

"Frank V. Castellucci" wrote:
> 
> Then demand we slow down. Seriously, I'd rather you be involved in some

I don't want to slow down the project just because a rookie (that is me) 
came in....

> of the neat stuff that we are just getting into a position to do. Of
> course I think things like frameworks, excercising the language, and
> providing some very serious implementation aids to other developers is
> neat. :)
> 
> The core is a jumping off point. Throw some conversation about Threads,
> Semaphores, Frameworks around. We really can do so cool things at this
> point.

I am an RTM kinda person. If it is documented somewhere, I'll read it and 
then ask if something is not clear. [It may seem that I have been too
quiet,
not responsive enough to comments that you guys sent to the mailing list.
In fact, I've been studying how the implemented classes relate to the model
(UML
diagram stuffs)].
So far my exploration into the deep space 
of Semaphore "family tree" has given me enough understanding of it.


I infer the following:
o All requirements for Semaphore (& co.) have been transfered into design.
o A large portion of this design has been implemented
o When the design mentions "SemaphoreIdentifier", the implementation views
this as
  SemGroupId + SemId.
o Low level system calls used for the implementation are semget, semctl,
and semop.

Some questions I'd like to ask.
When I open an *.mdf file using MagicDraw, the left window pane shows a
tree of
clickable nodes. Which part of the (sub)tree(s) should I concentrate on
browsing
during the implementation.
I understand that for the implementation of EventSemaphore (which is what
I'm doing now)
Many-To-One is one of the things I should concentrate. What else?
What guide(s) should I follow when writing a test driver?
In the implementation I saw SemaphoreCommon but not in the diagram? Any
explanation?

Oops.....I ask too much...better stop here... :-)

> 
> I don't think we have the boundry for the universe of discourse defined
> yet :)
>

I'd rather leave it open....
 
> 
> --
> 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] stats

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

Hans Dulimarta wrote:
> 
> Christophe Prud'homme wrote:
> >
> > it seems that some people are using corelinux looking at the dl stats from
> > sourceforge. That's unfortunate that there is no feedback
> 
> Actually, this is how I decided to get involved in the CoreLinux project.
> I started browsing sourceforge web site intensively just last June. In the
> first
> few days I "shopped" around to see which project fit my interest. I was
> tempted
> to join FreeNet but I though that project had already enough people joined
> in
> to help the project.
> 
> FreeNet, Mesa, CoreLinux were among the top ten that caught my eyes.
> Finally, I decided to join CoreLinux because "This is the core of Linux!"
> 
> So, I started browsing the document and anon cvs co, etc..etc...etc...
> contacted Frank that I'm interested in joining ..... etc....etc...etc....
> and here I am with you guys....
> 
> My decision to join in corelinux as developer was not preceded by
> first joining the mailing list so I would know all the topics of discourse
> in the project.
> I had to keep up with you guys who have run far ahead of me...

Then demand we slow down. Seriously, I'd rather you be involved in some
of the neat stuff that we are just getting into a position to do. Of
course I think things like frameworks, excercising the language, and
providing some very serious implementation aids to other developers is
neat. :)

The core is a jumping off point. Throw some conversation about Threads,
Semaphores, Frameworks around. We really can do so cool things at this
point.

I don't think we have the boundry for the universe of discourse defined
yet :)

> 
> > but may be it's because it is perfect:)
> > but that would be too good to be true.
> 
> One day, we have to reach this level of perfection and it will
> be too bad not to be true.... :-)
> 
> >
> > as you may have seen I want to include corelinux into debian
> > unfortunately I won;t be a debian package maintainer tomorrow
> > the process seems quite long
> > may be we should try to include corelinux into redhat,mandrake and suse
> >
> > visibility is important when you want people to use your stuff
> > package creation was one improtant step
> > corelinux in main distributions is another one
> >
> > C.
> > --
> >   Christophe Prud'homme                 |
> >   MIT, 77, Mass Ave, Rm 3-243           |  The first thing we do, let's kill
> >   Cambridge MA 02139                    |  all the lawyers.
> >   Tel (Office) : (00 1) (617) 253 0229  |  -- Wm. Shakespeare,
> >   Fax (Office) : (00 1) (617) 258 8559  |  "Henry VI", Part IV
> >   http://augustine.mit.edu/~prudhomm    |
> >                           Following the hacker spirit
> >
> > _______________________________________________
> > 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
> 
> _______________________________________________
> 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] add-log discovery

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

Christophe Prud'homme wrote:
> 
> On Fri, 18 Aug 2000, you wrote:
> > Christophe Prud'homme wrote:
> > > > I'm running emacs, not xemacs. When I start with 'emacs ChangeLog &' it
> > > > notes that it's loading 'add-log'.
> > >
> > > yes me too
> >
> > There is no problem :) just noting it. What I think I did was Update
> > Change log, which went to the CVS and pulled it in.
> if you are under xemacs/CVS type A on the file to add a new ChangeLog entry
> 
> > So, instead to learn I am now fooling with
> >
> > C-x 4-a
> >       which adds a new entry
> yes ok
> 
> > C-c C-c
> >       which does nothing !?!?
> you must be in the ChangeLog buffer for the command to take effect
> 
> > C-c C-k
> >       which does nothing !?!?
> see above
> 
> > They both leave the buffer in modified state and don't undo anything
> strange
> 
> > How do you find the key bindings for a particular *.el package?
> see in help meny for key bindings
> otherwise  you have in the help menu a mode help
> which should tell you what are the key binding alive for the current mode
> (it gives also the bindings for the minor modes)
> 
> > I usually use Visual SlickEdit in brief mode.
> don't know this
> I am afraid that I am addicted/plagued by xemacs
> 
> xemacs is nicer looking, more menus extensive, provides more packages in
> general by default and provide a package update system
> and it integrates much more gracefully in a X environment than emacs
> 

Reading all your reply in this e-mail makes me tempted to revert to
emacs...:-)


> 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
> 
> _______________________________________________
> 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] stats

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

Christophe Prud'homme wrote:
> 
> it seems that some people are using corelinux looking at the dl stats from
> sourceforge. That's unfortunate that there is no feedback

Actually, this is how I decided to get involved in the CoreLinux project.
I started browsing sourceforge web site intensively just last June. In the
first 
few days I "shopped" around to see which project fit my interest. I was
tempted
to join FreeNet but I though that project had already enough people joined
in
to help the project. 

FreeNet, Mesa, CoreLinux were among the top ten that caught my eyes.
Finally, I decided to join CoreLinux because "This is the core of Linux!"

So, I started browsing the document and anon cvs co, etc..etc...etc...
contacted Frank that I'm interested in joining ..... etc....etc...etc....
and here I am with you guys....

My decision to join in corelinux as developer was not preceded by
first joining the mailing list so I would know all the topics of discourse
in the project.
I had to keep up with you guys who have run far ahead of me...

> but may be it's because it is perfect:)
> but that would be too good to be true.

One day, we have to reach this level of perfection and it will
be too bad not to be true.... :-)

> 
> as you may have seen I want to include corelinux into debian
> unfortunately I won;t be a debian package maintainer tomorrow
> the process seems quite long
> may be we should try to include corelinux into redhat,mandrake and suse
> 
> visibility is important when you want people to use your stuff
> package creation was one improtant step
> corelinux in main distributions is another one
> 
> C.
> --
>   Christophe Prud'homme                 |
>   MIT, 77, Mass Ave, Rm 3-243           |  The first thing we do, let's kill
>   Cambridge MA 02139                    |  all the lawyers.
>   Tel (Office) : (00 1) (617) 253 0229  |  -- Wm. Shakespeare,
>   Fax (Office) : (00 1) (617) 258 8559  |  "Henry VI", Part IV
>   http://augustine.mit.edu/~prudhomm    |
>                           Following the hacker spirit
> 
> _______________________________________________
> 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] add-log discovery

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

Christophe Prud'homme wrote:
> 
> > I used to be an intensive emacs users (dired, gnus, rmail, auctex,
> > angeftp, ...) but pressing Ctrl-x key made my pinky and middle finger
> > stretch too much and it hurt. Pressing Ctrl-C was OK because I had a
> > bit to use pinky and pointer.
> How come ? x is closer to Ctrl than c

Ctrl-X : pinky + middle
Ctrl-C : pinky + index

> are you using a crazy keyboard?

Nope, I'm using qwerty to crazy :-)

> 
> > So, I decided to quit emacs and went back to vi(m).
> my position on this is that people should use the tools which allows to be
> the most productive.
> 
> >
> > I should have "trained" my left hand to use pinky-pointer to press both
> > C-x and C-c. Well...., I am happy with vim now...:-)   [eventhough it does
> > not have CVS support :-( ... ]
> yes that's unfortunate
> however it's difficult to keep up with emacs/xemacs power (kidding but quite
> true :))
> 
> --
>    Christophe Prud'homme                  |
>    MIT, 77, Mass Ave, Rm 3-243            |   Un prud'homme était un homme
>    Cambridge MA 02139                     |   d'honneur et de valeur,
>    Tel (Office) : (00 1) (617) 253 0229   |   sage et loyal.
>    Fax (Office) : (00 1) (617) 258 8559   |   -- Chateaubriand
>    http://augustine.mit.edu/~prudhomm     |
>                           Following the hacker spirit
> 
> _______________________________________________
> 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