Menu
▾
▴
corelinux-develop — Developer centric mail list for CoreLinux++
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(144) |
Aug
(209) |
Sep
(117) |
Oct
(44) |
Nov
(41) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(14) |
Feb
(64) |
Mar
(25) |
Apr
(35) |
May
(29) |
Jun
(6) |
Jul
(7) |
Aug
|
Sep
(12) |
Oct
(6) |
Nov
|
Dec
(1) |
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2004 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2006 |
Jan
(7) |
Feb
(5) |
Mar
(2) |
Apr
(1) |
May
(9) |
Jun
(11) |
Jul
(9) |
Aug
(5) |
Sep
(7) |
Oct
|
Nov
|
Dec
(9) |
| 2007 |
Jan
(3) |
Feb
(5) |
Mar
(2) |
Apr
(5) |
May
(1) |
Jun
(1) |
Jul
(5) |
Aug
(16) |
Sep
(7) |
Oct
(8) |
Nov
(8) |
Dec
(2) |
| 2008 |
Jan
(4) |
Feb
(7) |
Mar
(27) |
Apr
(26) |
May
(28) |
Jun
(17) |
Jul
(38) |
Aug
(13) |
Sep
(17) |
Oct
(12) |
Nov
(37) |
Dec
(51) |
| 2009 |
Jan
(41) |
Feb
(19) |
Mar
(30) |
Apr
(43) |
May
(138) |
Jun
(111) |
Jul
(76) |
Aug
(27) |
Sep
(28) |
Oct
(33) |
Nov
(11) |
Dec
(18) |
| 2010 |
Jan
(3) |
Feb
(5) |
Mar
(40) |
Apr
(51) |
May
(74) |
Jun
(76) |
Jul
(46) |
Aug
(41) |
Sep
(26) |
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Christophe Prud'h. <pru...@MI...> - 2000-09-29 19:56:48
|
just a thought may be we should asked on -public if there ia any public/commercial software using corelinux ? and put the ref to the app on the web server a section like "they used it and they are happy about it" :) C. -- Christophe Prud'homme | MIT, 77, Mass Ave, Rm 3-243 | C'est de la buche? Cambridge MA 02139 | Non c'est kloug! Tel (Office) : (00 1) (617) 253 0229 | C'est colmatté avec du schpountz... Fax (Office) : (00 1) (617) 258 8559 | -- Le Pere Noel est une ordure http://augustine.mit.edu/~prudhomm | Following the hacker spirit |
|
From: Christophe Prud'h. <pru...@MI...> - 2000-09-29 19:20:12
|
I didn't check toroughly, but I guess that the following points are not implemented yet ? am i wrong? 1. Library shall support the registration/deregistration of library loaders specific to a library type 2. The CoreLinux++ team shall implement a default shared library (*.so) loader for registration 3. The CoreLinux++ team shall implement the default library handler using the Linux dlopen dlsym dlclose API I need this for a project(adding plugin facility) and would like to do it cleanly with corelinux. So I can start working on the default library loader/handler. I will need also corba stuff for a really cool (GPL) web application/software :) but that can wait. 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 |
|
From: Frank V. C. <fr...@co...> - 2000-09-28 21:18:47
|
Hans - Dulimarta wrote: > > On Thu, 28 Sep 2000, Frank V. Castellucci wrote: > > > Date: Thu, 28 Sep 2000 07:17:58 -0400 > > From: Frank V. Castellucci <fr...@co...> > > Reply-To: cor...@li... > > To: CoreLinux Development <cor...@li...> > > Subject: [Corelinux-develop] [Fwd: [Bug #115535] Deadlock on example22] > > > > Hans, > > > > Was this like a note to yourself? > > Well, kind of. > > > I assume you changed the behavior of examp22 to test the state change > > issue we discussed previously. No? > > > > I guess the two bugs are different. Maybe I did not write the bug text > specific enough. In bug 115535 I wanted to see how the code behaves when > the each of the two "listeners" enters a loop but the "trigger" does not > and tries to destroy the semaphore. Apparently in this case the trigger > cannot run until completion. I think the bug is the destroySemaphore > method. When it sees that the "share count" is non-zero it executes > nothing. > > In bug 113589 both the listeners and the trigger will run in a loop. > > The two bugs may be related. I am not sure now. Idle musing here but, maybe, they are the same. To me the situation is one where the behavior of the client may be: 1. Single shot - wait for one event and then disappear. 2. Continuous - wait for event, do some processing, come back for next event 3. Non-blocking variations - interested to see if event has fired but doesn't want to block Where the "owner" wants to post, insure that all listeners for that event "post instance" have been released, and then get the semaphore back into the (1) state. > > > > > > > -- > 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 > > ------------------------------------------------------------------------ > > Subject: [Bug #115535] Deadlock on example22 > Date: Wed, 27 Sep 2000 22:23:36 -0700 > From: no...@so... > To: dul...@co..., no...@so..., > fr...@us... > > Bug #115535, was updated on 2000-Sep-27 22:23 > Here is a current snapshot of the bug. > > Project: CoreLinux++ > Category: libcorelinux++ > Status: Open > Resolution: None > Bug Group: Defects > Priority: 5 > Summary: Deadlock on example22 > > Details: Example22 was changed to have a loop on the listener task. > As a result a deadlock occured. > > For detailed info, follow this link: > http://sourceforge.net/bugs/?func=detailbug&bug_id=115535&group_id=308 -- 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...> - 2000-09-28 14:09:09
|
On Thu, 28 Sep 2000, Frank V. Castellucci wrote: > Date: Thu, 28 Sep 2000 07:17:58 -0400 > From: Frank V. Castellucci <fr...@co...> > Reply-To: cor...@li... > To: CoreLinux Development <cor...@li...> > Subject: [Corelinux-develop] [Fwd: [Bug #115535] Deadlock on example22] > > Hans, > > Was this like a note to yourself? Well, kind of. > I assume you changed the behavior of examp22 to test the state change > issue we discussed previously. No? > I guess the two bugs are different. Maybe I did not write the bug text specific enough. In bug 115535 I wanted to see how the code behaves when the each of the two "listeners" enters a loop but the "trigger" does not and tries to destroy the semaphore. Apparently in this case the trigger cannot run until completion. I think the bug is the destroySemaphore method. When it sees that the "share count" is non-zero it executes nothing. In bug 113589 both the listeners and the trigger will run in a loop. The two bugs may be related. I am not sure now. > > -- 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 |
|
From: Frank V. C. <fr...@co...> - 2000-09-28 11:14:54
|
Hans, Was this like a note to yourself? I assume you changed the behavior of examp22 to test the state change issue we discussed previously. No? -- Frank V. Castellucci |
|
From: Frank V. C. <fr...@co...> - 2000-09-25 01:42:38
|
Ok, it works! If you are interested in cvs activity, I got a "fast path" request through and syncmail is now active. to subscribe: http://lists.sourceforge.net/mailman/listinfo/corelinux-clcvs Right now, all modules are funneled into this list. If need be, we can go nuts with lists and module redirection. -- Frank V. Castellucci http://corelinux.sourceforge.net OOA/OOD/C++ Standards and Guidelines for Linux http://PythPat.sourceforge.net Pythons Pattern Package |
|
From: Frank V. C. <fr...@co...> - 2000-09-24 11:10:56
|
I have created a mailing list for CVS activity cor...@li... if you want to see CVS activity, subscribe to this list. -- Frank V. Castellucci |
|
From: Frank V. C. <fr...@co...> - 2000-09-24 00:46:10
|
Finally, after working through a number of false starts and mishaps, we have released the new library. Included is the EventSemaphoreGroup and EventSemaphore which completes the original Semaphore requirement. In addition, a few compilation bugs were fixed. The class library documentation has been updated, but not CoreLinux++Doc. For 0.4.29 we will: - be adding some features to the EventSemaphore for full use case coverage - extending Environment class methods for more Linux specific system calls - improving the documentation libclfw work is not suspended, but I continue to search for existing metaclass/metatype implementation that satisfy the lite weight needs we have posted in regards to Meta Object Programming (MOP). I am prepared to get the NIHC implementation (class Class), but that is a bit heavier than I wanted at the moment. -- Frank V. Castellucci |
|
From: Frank V. C. <fr...@co...> - 2000-09-23 21:45:28
|
I have started the release process with the RPM (but not -doc) and tarball. When you have redone the docs and debian, it is easy for me to just ftp them and add to the release. -- Frank V. Castellucci http://corelinux.sourceforge.net OOA/OOD/C++ Standards and Guidelines for Linux http://PythPat.sourceforge.net Pythons Pattern Package |
|
From: Frank V. C. <fr...@co...> - 2000-09-23 21:09:43
|
Hans Dulimarta wrote:
>
> "Frank V. Castellucci" wrote:
> >
> > Hans Dulimarta wrote:
> > >
> > > "Frank V. Castellucci" wrote:
> > > >
> > > > What I meant by #3 can be summarized in the header file
> > > > MutexSemaphoreGroup.hpp, so in answer to your graphic depiction, yes it
> > > > is correct with the exception of the class MyClass opening brace (which
> > > > should line up with 'class' on the next line.
> > > >
> > > > Now, this has mostly been my organization and alignment which for me is
> > > > readable. How do you feel about it?
> > >
> > > Personally, I prefer the comments flushed left with any
> > > modifiers, which means
> > > that 4 level indentation does not apply. But, I guess for
> > > this project I have
> > > to decline my own preferences.
> >
> > I guess the goal/objective is that whatever the standard is, that the
> > code be consistent. So if we started with flushing left the comments
> > with the modifiers, as long as we stuck to it, would have been ok. And
> > this is your project now! :)
> >
>
> But that will need a lot of editing of the other files to
> make them
> consistent. This 4 level of indentation is also readable.
>
> > BTW: Are you done with the checking in for the moment?
>
> Yes. I'll let you freeze the code for 0.4.28. For the 0.4.29
> release
> I am planning to complete the requirements of EventSemaphore
> which are
> still unimplemented.
Cool.
>
> Also, I'd like to ask you a question. How does a Guard work?
> Is it possible
> to release a Guard and the lock it again in the middle of a
> function before
> the function exits? I will need to protect some operations
> to data members of
> EventSemaphore.
You can get a Guard from the Synchronized instance, and then release it
once, and only once.
You can then get another Guard for later on in the function but be
careful about deadlocks.
>
> >
> > >
> > > >
> > > > >
> > > > > My questions:
> > > > > Point #1 and #2 were clearly understood.
> > > > > Point #3 is a bit unclear: when you mentioned "4-level deep", which
> > > > > column is the reference column? I assume it is 4-level deep relative
> > > > > to the "class" keyword.
> > > > >
> > > > > Is the following correctly indented according to the above 'guidelines'?
> > > > > (leading blanks were replaced with = or -)
> > > > >
> > > > > namespace corelinux {
> > > > >
> > > > > ===class MyClass {
> > > > > ===---===---===/**
> > > > > ===---===---===---constructors have no return type.
> > > > > ===---===---===---I assume the return type is "empty string"
> > > > > ===---===---===*/
> > > > > ===---===---===MyClass( params );
> > > > >
> > > > > ===---===---===/// comment for virtual MethodA
> > > > > ===---virtual ReturnType MethodA( signature ... );
> > > > >
> > > > > ===---===---===/// comment for methodB
> > > > > ===---===---===void MethodB ( signature ... );
> > > > > ===};
> > > > > }
> > > > >
> > > > > I think we should add this "guideline" to the C++ Coding standard.
> > > > >
> > > > > --
> > > > > 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
> > > > _______________________________________________
> > > > 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
> _______________________________________________
> 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
|
|
From: Frank V. C. <fr...@co...> - 2000-09-23 21:01:14
|
Ok, When I set configure.in to 2:0:1, it results in *.so.1.1.0 ? When I set configure.in to 2:1:1, it results in *.so.1.1.0 ? When I set configure.in to 2:1:0, it results in *.so.1.1.0 ? When I set configure.in to 1:2:1, it results in *.so.1.1.0 ? So <grin>, I left it at 2:0:1 and have checked it in. I have also had to retag, which is now rel-0-4-28a and I am ready when you are. Frank Christophe Prud'homme wrote: > > On Fri, 22 Sep 2000, you wrote: > > Ok, > > > > I'm confused about your libtool versioning message, and when I make rpm > > sure enough it is not what I expected (it creates libcl++.so.0.1.0) > > where I was looking for either 1.0.1. > I was thinking about that too > > > > > So, as I read libtool (info libtool) I am now under the impression I > > should have done 2:0:1. Is this correct? Either way we must once again > > update configure.in, which means a rebuild. > yes seems so > > > > > If this is becoming too much for you to do, say something. I will go > > with just the rpm stuff I can get done here and don't feel any worse > > about it. > no that's ok I got some delay for my important stuff > so I have no problem with that > > > > > Did you see the developer ratings on SF? Someone doesn't like me :) > no I will look and vote for you :) > > C. > -- > 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 |
|
From: Christophe Prud'h. <pru...@MI...> - 2000-09-23 19:49:31
|
On Fri, 22 Sep 2000, you wrote: > Ok, > > I'm confused about your libtool versioning message, and when I make rpm > sure enough it is not what I expected (it creates libcl++.so.0.1.0) > where I was looking for either 1.0.1. I was thinking about that too > > So, as I read libtool (info libtool) I am now under the impression I > should have done 2:0:1. Is this correct? Either way we must once again > update configure.in, which means a rebuild. yes seems so > > If this is becoming too much for you to do, say something. I will go > with just the rpm stuff I can get done here and don't feel any worse > about it. no that's ok I got some delay for my important stuff so I have no problem with that > > Did you see the developer ratings on SF? Someone doesn't like me :) no I will look and vote for you :) C. -- 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 |
|
From: Hans D. <dul...@eg...> - 2000-09-23 06:24:02
|
"Frank V. Castellucci" wrote:
>
> Hans Dulimarta wrote:
> >
> > "Frank V. Castellucci" wrote:
> > >
> > > What I meant by #3 can be summarized in the header file
> > > MutexSemaphoreGroup.hpp, so in answer to your graphic depiction, yes it
> > > is correct with the exception of the class MyClass opening brace (which
> > > should line up with 'class' on the next line.
> > >
> > > Now, this has mostly been my organization and alignment which for me is
> > > readable. How do you feel about it?
> >
> > Personally, I prefer the comments flushed left with any
> > modifiers, which means
> > that 4 level indentation does not apply. But, I guess for
> > this project I have
> > to decline my own preferences.
>
> I guess the goal/objective is that whatever the standard is, that the
> code be consistent. So if we started with flushing left the comments
> with the modifiers, as long as we stuck to it, would have been ok. And
> this is your project now! :)
>
But that will need a lot of editing of the other files to
make them
consistent. This 4 level of indentation is also readable.
> BTW: Are you done with the checking in for the moment?
Yes. I'll let you freeze the code for 0.4.28. For the 0.4.29
release
I am planning to complete the requirements of EventSemaphore
which are
still unimplemented.
Also, I'd like to ask you a question. How does a Guard work?
Is it possible
to release a Guard and the lock it again in the middle of a
function before
the function exits? I will need to protect some operations
to data members of
EventSemaphore.
>
> >
> > >
> > > >
> > > > My questions:
> > > > Point #1 and #2 were clearly understood.
> > > > Point #3 is a bit unclear: when you mentioned "4-level deep", which
> > > > column is the reference column? I assume it is 4-level deep relative
> > > > to the "class" keyword.
> > > >
> > > > Is the following correctly indented according to the above 'guidelines'?
> > > > (leading blanks were replaced with = or -)
> > > >
> > > > namespace corelinux {
> > > >
> > > > ===class MyClass {
> > > > ===---===---===/**
> > > > ===---===---===---constructors have no return type.
> > > > ===---===---===---I assume the return type is "empty string"
> > > > ===---===---===*/
> > > > ===---===---===MyClass( params );
> > > >
> > > > ===---===---===/// comment for virtual MethodA
> > > > ===---virtual ReturnType MethodA( signature ... );
> > > >
> > > > ===---===---===/// comment for methodB
> > > > ===---===---===void MethodB ( signature ... );
> > > > ===};
> > > > }
> > > >
> > > > I think we should add this "guideline" to the C++ Coding standard.
> > > >
> > > > --
> > > > 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
> > > _______________________________________________
> > > 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
|
|
From: Frank V. C. <fr...@co...> - 2000-09-23 05:05:12
|
Hans Dulimarta wrote:
>
> "Frank V. Castellucci" wrote:
> >
> > Hans Dulimarta wrote:
> > >
> > > Frank, I thought I fixed bug 113984 (header alignments).
> > > But again I checked the cppstnd.tex and could not find any
> > > appropriate guidelines.
> > >
> > > You wrote the following three lines in the bug report:
> > >
> > > [#1] Method comments should left justify with return type in signature.
> > > [#2] Method signatures should left justify with return types in
> > > signature.
> > > [#3] Return types generally align on a four level indentation depth.
> >
> > What I meant by #3 can be summarized in the header file
> > MutexSemaphoreGroup.hpp, so in answer to your graphic depiction, yes it
> > is correct with the exception of the class MyClass opening brace (which
> > should line up with 'class' on the next line.
> >
> > Now, this has mostly been my organization and alignment which for me is
> > readable. How do you feel about it?
>
> Personally, I prefer the comments flushed left with any
> modifiers, which means
> that 4 level indentation does not apply. But, I guess for
> this project I have
> to decline my own preferences.
I guess the goal/objective is that whatever the standard is, that the
code be consistent. So if we started with flushing left the comments
with the modifiers, as long as we stuck to it, would have been ok. And
this is your project now! :)
BTW: Are you done with the checking in for the moment?
>
> >
> > >
> > > My questions:
> > > Point #1 and #2 were clearly understood.
> > > Point #3 is a bit unclear: when you mentioned "4-level deep", which
> > > column is the reference column? I assume it is 4-level deep relative
> > > to the "class" keyword.
> > >
> > > Is the following correctly indented according to the above 'guidelines'?
> > > (leading blanks were replaced with = or -)
> > >
> > > namespace corelinux {
> > >
> > > ===class MyClass {
> > > ===---===---===/**
> > > ===---===---===---constructors have no return type.
> > > ===---===---===---I assume the return type is "empty string"
> > > ===---===---===*/
> > > ===---===---===MyClass( params );
> > >
> > > ===---===---===/// comment for virtual MethodA
> > > ===---virtual ReturnType MethodA( signature ... );
> > >
> > > ===---===---===/// comment for methodB
> > > ===---===---===void MethodB ( signature ... );
> > > ===};
> > > }
> > >
> > > I think we should add this "guideline" to the C++ Coding standard.
> > >
> > > --
> > > 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
> > _______________________________________________
> > 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
|
|
From: Hans D. <dul...@eg...> - 2000-09-23 04:34:14
|
"Frank V. Castellucci" wrote:
>
> Hans Dulimarta wrote:
> >
> > Frank, I thought I fixed bug 113984 (header alignments).
> > But again I checked the cppstnd.tex and could not find any
> > appropriate guidelines.
> >
> > You wrote the following three lines in the bug report:
> >
> > [#1] Method comments should left justify with return type in signature.
> > [#2] Method signatures should left justify with return types in
> > signature.
> > [#3] Return types generally align on a four level indentation depth.
>
> What I meant by #3 can be summarized in the header file
> MutexSemaphoreGroup.hpp, so in answer to your graphic depiction, yes it
> is correct with the exception of the class MyClass opening brace (which
> should line up with 'class' on the next line.
>
> Now, this has mostly been my organization and alignment which for me is
> readable. How do you feel about it?
Personally, I prefer the comments flushed left with any
modifiers, which means
that 4 level indentation does not apply. But, I guess for
this project I have
to decline my own preferences.
>
> >
> > My questions:
> > Point #1 and #2 were clearly understood.
> > Point #3 is a bit unclear: when you mentioned "4-level deep", which
> > column is the reference column? I assume it is 4-level deep relative
> > to the "class" keyword.
> >
> > Is the following correctly indented according to the above 'guidelines'?
> > (leading blanks were replaced with = or -)
> >
> > namespace corelinux {
> >
> > ===class MyClass {
> > ===---===---===/**
> > ===---===---===---constructors have no return type.
> > ===---===---===---I assume the return type is "empty string"
> > ===---===---===*/
> > ===---===---===MyClass( params );
> >
> > ===---===---===/// comment for virtual MethodA
> > ===---virtual ReturnType MethodA( signature ... );
> >
> > ===---===---===/// comment for methodB
> > ===---===---===void MethodB ( signature ... );
> > ===};
> > }
> >
> > I think we should add this "guideline" to the C++ Coding standard.
> >
> > --
> > 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
> _______________________________________________
> 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
|
|
From: Frank V. C. <fr...@co...> - 2000-09-23 02:08:11
|
Hans Dulimarta wrote:
>
> Frank, I thought I fixed bug 113984 (header alignments).
> But again I checked the cppstnd.tex and could not find any
> appropriate guidelines.
>
> You wrote the following three lines in the bug report:
>
> [#1] Method comments should left justify with return type in signature.
> [#2] Method signatures should left justify with return types in
> signature.
> [#3] Return types generally align on a four level indentation depth.
What I meant by #3 can be summarized in the header file
MutexSemaphoreGroup.hpp, so in answer to your graphic depiction, yes it
is correct with the exception of the class MyClass opening brace (which
should line up with 'class' on the next line.
Now, this has mostly been my organization and alignment which for me is
readable. How do you feel about it?
>
> My questions:
> Point #1 and #2 were clearly understood.
> Point #3 is a bit unclear: when you mentioned "4-level deep", which
> column is the reference column? I assume it is 4-level deep relative
> to the "class" keyword.
>
> Is the following correctly indented according to the above 'guidelines'?
> (leading blanks were replaced with = or -)
>
> namespace corelinux {
>
> ===class MyClass {
> ===---===---===/**
> ===---===---===---constructors have no return type.
> ===---===---===---I assume the return type is "empty string"
> ===---===---===*/
> ===---===---===MyClass( params );
>
> ===---===---===/// comment for virtual MethodA
> ===---virtual ReturnType MethodA( signature ... );
>
> ===---===---===/// comment for methodB
> ===---===---===void MethodB ( signature ... );
> ===};
> }
>
> I think we should add this "guideline" to the C++ Coding standard.
>
> --
> 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
|
|
From: Hans D. <dul...@eg...> - 2000-09-23 01:12:22
|
Frank, I thought I fixed bug 113984 (header alignments).
But again I checked the cppstnd.tex and could not find any
appropriate guidelines.
You wrote the following three lines in the bug report:
[#1] Method comments should left justify with return type in signature.
[#2] Method signatures should left justify with return types in
signature.
[#3] Return types generally align on a four level indentation depth.
My questions:
Point #1 and #2 were clearly understood.
Point #3 is a bit unclear: when you mentioned "4-level deep", which
column is the reference column? I assume it is 4-level deep relative
to the "class" keyword.
Is the following correctly indented according to the above 'guidelines'?
(leading blanks were replaced with = or -)
namespace corelinux {
===class MyClass {
===---===---===/**
===---===---===---constructors have no return type.
===---===---===---I assume the return type is "empty string"
===---===---===*/
===---===---===MyClass( params );
===---===---===/// comment for virtual MethodA
===---virtual ReturnType MethodA( signature ... );
===---===---===/// comment for methodB
===---===---===void MethodB ( signature ... );
===};
}
I think we should add this "guideline" to the C++ Coding standard.
--
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
|
|
From: Hans - D. <dul...@eg...> - 2000-09-22 21:37:56
|
I just checked in my modification to the EvenSemaphore[Group].hpp files. This was just comment lines formatting, to comply with doxygen requirements. -- 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 |
|
From: Christophe Prud'h. <pru...@MI...> - 2000-09-22 21:18:17
|
the packages are done but I cannot scp them or log on corelinux.sourceforge.net cvs is working fine though anyone having the same problem? sorry C. -- 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 |
|
From: Frank V. C. <fr...@co...> - 2000-09-22 17:52:44
|
Ok, Once you are done, please re-tag everything as 0.4.28 with cvs tag rel-0-4-28 Frank PS: I will re-update and build rpm tonight Christophe Prud'homme wrote: > in order to create libcl++.so.1.0.1 LIOBCORELINUX_SO_VERSION must be set to > 1:1 and not 1:0:1 (which gives libcl++.so.0.1.1) > > so I changed again configure.in and cvs will be updated real soon now > > C. > -- > Christophe Prud'homme | > MIT, 77, Mass Ave, Rm 3-243 | "It may be that our role on this > Cambridge MA 02139 | planet is not to worship God but to > Tel (Office) : (00 1) (617) 253 0229 | create him." > Fax (Office) : (00 1) (617) 258 8559 | -Arthur C. Clarke > http://augustine.mit.edu/~prudhomm | > Following the hacker spirit > _______________________________________________ > Corelinux-develop mailing list > Cor...@li... > http://lists.sourceforge.net/mailman/listinfo/corelinux-develop |
|
From: Christophe Prud'h. <pru...@MI...> - 2000-09-22 17:29:53
|
On Fri, 22 Sep 2000, you wrote:
> in order to create libcl++.so.1.0.1 LIOBCORELINUX_SO_VERSION must be set to
> 1:1 and not 1:0:1 (which gives libcl++.so.0.1.1)
ok I am really tired, forget about this thread
--
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 |
Following the hacker spirit
|
|
From: Christophe Prud'h. <pru...@MI...> - 2000-09-22 16:52:13
|
in order to create libcl++.so.1.0.1 LIOBCORELINUX_SO_VERSION must be set to 1:1 and not 1:0:1 (which gives libcl++.so.0.1.1) so I changed again configure.in and cvs will be updated real soon now C. -- Christophe Prud'homme | MIT, 77, Mass Ave, Rm 3-243 | "It may be that our role on this Cambridge MA 02139 | planet is not to worship God but to Tel (Office) : (00 1) (617) 253 0229 | create him." Fax (Office) : (00 1) (617) 258 8559 | -Arthur C. Clarke http://augustine.mit.edu/~prudhomm | Following the hacker spirit |
|
From: Hans - D. <dul...@eg...> - 2000-09-22 16:09:49
|
On Fri, 22 Sep 2000, Frank V. Castellucci wrote: > Date: Fri, 22 Sep 2000 08:49:40 -0400 > From: Frank V. Castellucci <fr...@co...> > Reply-To: cor...@li... > To: CoreLinux Development <cor...@li...> > Subject: [Corelinux-develop] 0.4.28 Pending > > Couple of things: > > 1. Christophe still(?) needs to merge configure.in and Hans recent > changes, and today I updated the README > > 2. We are frozen code, this means that if you change something again we > will have to rebuild for the 0.4.28 release, I have tagged (cvs tag > rel-0-4-28) corelinux module as of today, which is what you should > identify for the update or checkout for building release files. > Last night I was fiddling with doxygen and looked and the documentation of EvSem and EvSemGrp and I modified some comments in the headers to reflect more appropriate documentation lines. I'm also working on fixing bug 113984. I'll check this in sometimes this afternoon. > 3. Should we have CVS check-ins connected to this mailing list? It may > be useful for knowing if the last release build we do is still valid. > > 4. Whats next? :) > > -- 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 |
|
From: Christophe Prud'h. <pru...@MI...> - 2000-09-22 15:54:21
|
ok I forgot to update debian/rules (updating the share lib version) in order to avoid doing that in the future I automated the change using configure and creating debian/rules.in configure.in has been changed debian/rules.in created debian/rules removed from cvs those changes will appear REAL SOON NOW (tm) in the cvs repo C. -- 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 |
|
From: Christophe Prud'h. <pru...@MI...> - 2000-09-22 15:51:07
|
On Fri, 22 Sep 2000, you wrote: > Couple of things: > > 1. Christophe still(?) needs to merge configure.in and Hans recent > changes, and today I updated the README I updated my cvs copy two .cvsignore files created and debian/ChangeLog updated > 3. Should we have CVS check-ins connected to this mailing list? It may > be useful for knowing if the last release build we do is still valid. that may be useful or may be something like corelinux-cvs@..... would be even better > > 4. Whats next? :) C. -- Christophe Prud'homme | MIT, 77, Mass Ave, Rm 3-243 | Virtue would go far if ... Cambridge MA 02139 | vanity did not keep it company. Tel (Office) : (00 1) (617) 253 0229 | -- La Rochefoucauld Fax (Office) : (00 1) (617) 258 8559 | http://augustine.mit.edu/~prudhomm | Following the hacker spirit |
1115 messages has been excluded from this view by a project administrator.
