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

[Corelinux-develop] new download page

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

the number of file to download increasing with release
a download page is needed (frank thinking at 1oclock in the morning :))

http://fluids51.mit.edu/~prudhomm/corelinux/download.php

comments?
do I update ?




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

Re: [Corelinux-develop] Library abstraction code in

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

"Frank V. Castellucci" wrote:
> 
> Christophe Prud'homme wrote:
> >
> > > Yep, I haven't found any problems other than the ones you fixed.
> > good
> >
> > > Yes, the reference package is something you may want to generate along
> > > with the debian pacakges until I get the doxygen updates.
> >
> > but what abount the rpm?
> > the ref manual is also generated for rpm for the corelinux-doc
> 
> Yes, I have a problem generating that, although you may have forgotten.
> I need to apply the update as I am running doxygen 1.1.2. I will check
> their site to see if they have a rpm for the latest release, otherwise I
> will get the source and build.
> 
> > > > - how to make reference manual nicer with doxygen
> > > >   put a few comments about how to document classes
> > >
> > > Am I doing it wrong using the JavaDoc tags?
> > yes but you can have much much more
> >
> > - todo list
> > - warning
> > - bug list
> > - include examples
> > - better formatting
> > - inclusion of images (like the use cases amnd classes diagrams)
> >   that would be just great
> >   I'll work on that for the next version if you agree
> 
> I will spend some time with the doxygen specific tags. BUT, as you
> appear to be enamored with things that make presentation wonderful, when
> the next better mousetrap comes along how will we deal with tools
> specific tagging? What I would prefer is a universal tagging option
> (JavaDoc?) that doesn't tie us down and yet still provides quality
> output.
> 
> I would prefer we start thinking about a more complete developers guide
> which would have all the requirements, analysis, and design
> documentation. But that would be HUGE. For now, I would skip putting the
> use-case/class diagrams in the class reference.
> 
> >
> > > We may want to start a cvs branch of utilities and scripts?
> > why not
> > what do you propose as a module name?
> 
> devscripts? buildtools? projtools?

I think "buildtools" fits well.

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

Re: [Corelinux-develop] Library abstraction code in

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

"Frank V. Castellucci" wrote:
> 
> Christophe Prud'homme wrote:
> >
> > > Any issues/questions/etc?
> > None on my side I just made a little change on debian side for the building
> > process
> > and the packages are done.
> > I 'll check the installation and a few other things
> >
> > is everything ok with rpm?
> 
> Yep, I haven't found any problems other than the ones you fixed.
> 
> > I'll be there tomorrow so we can tackle the last problems, issues
> > and documentation requirements
> >
> > on the doc side
> > - how to make deb packages
> > - how to make redhat package
> > - how to generate the reference manual (BTW doxygen is working well, with the
> >    pdf patch and there is a qt graphical interface that comes with it by
> >    passing --with-doxywizard or something like that to configure)
> 
> Yes, the reference package is something you may want to generate along
> with the debian pacakges until I get the doxygen updates.
> 
> > - how to make reference manual nicer with doxygen
> >   put a few comments about how to document classes
> 
> Am I doing it wrong using the JavaDoc tags?
> 
> >
> > comments?
> >
> > >
> > > Oh, yeah, Christophe: The update.makefile.pl in /src/testdrivers is not
> > > meant to be run by hand for anyreason is it?
> > this script allowed me to update all the makefile with the -lcl++
> > it can be helpful in the future but you can remove it if you want
> 
> We may want to start a cvs branch of utilities and scripts?

Agree on this. I think eventually the scripts and utilities will
grow bigger.

> 
> --
> 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] developer manual updated for autoconf user

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

I updated the corelinux developer manual for the user/developer using autoconf
to detect corelinux exitence

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

[Corelinux-develop] Your gonna kill me

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

Oops,

By accident I deleted the debian packages on the shell server. <shameful
blush with head hung low>.

Forgive me....

-- 
Frank V. Castellucci

Re: [Corelinux-develop] release

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

Christophe Prud'homme wrote:
> 
> Ok the debian packages are done
> I am also ucvs-pdating a minor change I made for this packaging
> 
> > As I will be pulling the LibLoad abstractions out, it would seem that
> > the major changes for release are:
> 
> > DEB
> Done
> > RPM
> your job?

Yes

> > Class Reference Documentation
> what do you mean?

Now that I have doxygen 1.2.0 it creates the PDF and PS files, no need
for you to do this. The 1.2.1 has your changes (your name was in the
credits!!!).

I will be creating the Class Reference documentation rpm at this point.

> 
> > Version (0.0.0) changes

I assume that you made not of the changes in ChangeLog or README
concerning the new version numbering?


-- 
Frank V. Castellucci

[Corelinux-develop] release

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

Ok the debian packages are done
I am also ucvs-pdating a minor change I made for this packaging

> As I will be pulling the LibLoad abstractions out, it would seem that
> the major changes for release are:

> DEB
Done
> RPM
your job?
> Class Reference Documentation
what do you mean?

> Version (0.0.0) changes
??



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

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

Even though I can now produce the pdf and ps documentation, it does not
yet have the infamous Christophe patch applied. That is in the 1.2.1
release (today) and they are yet to have a RPM for it.

I have become quite spoiled with, after installing something with RPM,
maintaining updates using RPM.

But, if this proves problematic I will get the binary distribution.

-- 
Frank V. Castellucci

[Corelinux-develop] RPM built

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

C.,

I have built all the RPM packages for 0.4.26 to see that, indeed, the
PDF and PS are now part of the documentation.

I will wait to see if you update README, or ChangeLog and then I will
update and build again. The only thing you would have to do is to build
the DEB package.

I wish they had the tools installed on SF so we could build them all
there. Anyway, it is easier now that I have doxygen 1.2.0.

-- 
Frank V. Castellucci

[Corelinux-develop] Ok, C. your turn

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

Ok,
I have removed Library Load abstraction layer (*.hpp and *.cpp, adjusted
Makefile.am) from the core.
I have added and checked in updates to ChangeLog

Christophe, if you need to do anything and check in, go ahead then let
me know. If you want to build RPM and DEB and Reference, feel free and
let me know where they are. I can do the usual documentation or all of
it(except for DEB packages).

Just let me know how you want to work it.

I am holding off creating the framework directory in CVS until we feel
good about the layout. No rush <grin>.

-- 
Frank V. Castellucci

[Corelinux-develop] Are we ready

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

Did my last remarks on the file structure seem correct?

I am ready to start moving/deleting from core to get use going on the
0.4.26 release.

-- 
Frank V. Castellucci

Re: [Corelinux-develop] Frameworks

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

Christophe Prud'homme wrote:
> 
> > So it is reasonable for me to move the Library Load abstraction into a
> > framework itself, oui?
> Ok
> >
> > What we should now consider is organization of frameworks. I think
> > something like :
> >
> > Until we come up with a Framework management framework (something to
> > discuss later), each of the sub-frameworks (Library Load, Persistence,
> > etc.) should exists as semi-independent libraries.
> That's good
> 
> >
> > Maybe something along the lines of a java package metaphor. So:
> > where LibLoad = LibraryLoad (for example)
> >
> > Main
> > ====
> > clfrmwrk (vacous root)
> > clfrmwrk/LibLoad
> > clfrmwrk/LibLoad/admin
> > clfrmwrk/LibLoad/{etc}
> >
> > Headers
> > =======
> > clfrmwrk/LibLoad/LibLoad
> >
> > Sources
> > =======
> > clfrmwrk/LibLoad/src
> > clfrmwrk/LibLoad/src/LibLoad
> > clfrmwrk/LibLoad/src/FuncLibLoad (etc for each library load type)
> Yes
> 
> My concern is also the installation of the corelinux framework
> 
> now we have -lcl++
> corelinuxframework might be -lclfw++
> or if we hace separate libs:
>   - loader :  -lclfwll++
>   - persistence : -lclfwp++
> the include files might go all in <prefix>/include/clfw
>  - <prefix>/include/clfw/LibLoad/*.hpp
>  - <prefix>/include/clfw/Persistence/*.hpp
> and so on
> 

I was thinking that we have separate libs.

> so users would do:
> 
> #include<clfw/LibLoader.hpp>
> or
> #include<clfw/Presistence.hpp>
> 
> in LibLoader.hpp you include all necessary headers (like that
> clfw/LibLoader/<whatever>.hpp) so that you need only to add
> -I<prefix>/include
> if prefix != /usr
> 
> and everything is defined within the namespace (for example) clfw::LibLoader
> or clfw::Persistence
> 
> does it make sense?
> is it somewhat related to what you have in mind?

Yes, and yes. Just to be sure, if the directory starts to look like
this:

clfw
clfw/admin
clfw/clfw (where LibLoad.hpp, Persist.hpp as you suggest exist)
clfw/LibLoad (where the interface headers exist)
clfw/Persist
clfw/src
clfw/src/LibLoad
clfw/src/Persist

for example, and you won't have any problem producing either libclfw++,
or libclfwll++, or libclfwp++ on demand?

I have setup header includes in this way in the past, usually two files
(for example):

in LibLoad.hpp

//
// Base include
//

#include	<corelinux/Common.hpp>

//
// Directory redirect header
//

#include <LibLoad.h>

<EOF>

and in LibLoad.h

#define Incl_Library		<LibLoad/Library.hpp>
#define	Incl_FunctionLibrary	<LibLoad/FunctionLibrary.hpp>

<EOF>

So the includes in source start to look like this:

#include <LibLoad.hpp>

#include Incl_FunctionLibrary



> 
> >
> > The key here is that we need the ability to release different versions
> > of different frameworks independent (with restrictions on later
> > dependencies) of each other.
> yes
> 
> > What do you think?
> see above :)
> 
> well I agree and ready to work

Well, I can setup the initial stuff (and get Library et.al. moved
first), once we are clear on the directory structures.
 
> as for the release 0.4.26 I'll be online tomorrow afternoon
> so we can tackle all the tasks before the release.

As I will be pulling the LibLoad abstractions out, it would seem that
the major changes for release are:

DEB
RPM
Class Reference Documentation
Version (0.0.0) changes

did I miss anything? Sound right?

-- 
Frank V. Castellucci

Re: [Corelinux-develop] Frameworks

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

> So it is reasonable for me to move the Library Load abstraction into a
> framework itself, oui?
Ok
>
> What we should now consider is organization of frameworks. I think
> something like :
>
> Until we come up with a Framework management framework (something to
> discuss later), each of the sub-frameworks (Library Load, Persistence,
> etc.) should exists as semi-independent libraries.
That's good

>
> Maybe something along the lines of a java package metaphor. So:
> where LibLoad = LibraryLoad (for example)
>
> Main
> ====
> clfrmwrk (vacous root)
> clfrmwrk/LibLoad
> clfrmwrk/LibLoad/admin
> clfrmwrk/LibLoad/{etc}
>
> Headers
> =======
> clfrmwrk/LibLoad/LibLoad
>
> Sources
> =======
> clfrmwrk/LibLoad/src
> clfrmwrk/LibLoad/src/LibLoad
> clfrmwrk/LibLoad/src/FuncLibLoad (etc for each library load type)
Yes

My concern is also the installation of the corelinux framework

now we have -lcl++
corelinuxframework might be -lclfw++
or if we hace separate libs: 
  - loader :  -lclfwll++
  - persistence : -lclfwp++
the include files might go all in <prefix>/include/clfw 
 - <prefix>/include/clfw/LibLoad/*.hpp
 - <prefix>/include/clfw/Persistence/*.hpp
and so on

so users would do:

#include<clfw/LibLoader.hpp>
or
#include<clfw/Presistence.hpp>

in LibLoader.hpp you include all necessary headers (like that 
clfw/LibLoader/<whatever>.hpp) so that you need only to add 
-I<prefix>/include 
if prefix != /usr

and everything is defined within the namespace (for example) clfw::LibLoader
or clfw::Persistence

does it make sense?
is it somewhat related to what you have in mind?

>
> The key here is that we need the ability to release different versions
> of different frameworks independent (with restrictions on later
> dependencies) of each other.
yes


> What do you think?
see above :)

well I agree and ready to work


as for the release 0.4.26 I'll be online tomorrow afternoon
so we can tackle all the tasks before the release.


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

Re: [Corelinux-develop] Frameworks

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

Christophe Prud'homme wrote:
> [snip for irrelevance now that there is a quorum] 
> >
> > What I'm getting at is I think that the IMPLEMENTATION of frameworks, in
> > this case the FunctionalLibrary loader et.al. are probably really an
> > example of the CoreLinux++ frameworks that are one of the goals of the
> > project.
> >
> > Anyone?
> so what you say is that it is time to putthings into libframeworks?
> if so why not!
> in fact it is quite good to think that core(linux)  really means it (that it
> is a core library): that is to say that it doesn't extra libs
> 
> -ldl is not such a requirement but keeping corelinux as a standalone lib(a
> part the c++ lib of course) is very good since dl features are needed only
> for a one corelinux feature
> 
> My preference would be to not add -ldl as a requirement and so begin to
> populate corelinux++ frameworks

Yes!

So it is reasonable for me to move the Library Load abstraction into a
framework itself, oui?

What we should now consider is organization of frameworks. I think
something like :

Until we come up with a Framework management framework (something to
discuss later), each of the sub-frameworks (Library Load, Persistence,
etc.) should exists as semi-independent libraries. 

Maybe something along the lines of a java package metaphor. So:
where LibLoad = LibraryLoad (for example)

Main
====
clfrmwrk (vacous root)
clfrmwrk/LibLoad
clfrmwrk/LibLoad/admin
clfrmwrk/LibLoad/{etc}

Headers
=======
clfrmwrk/LibLoad/LibLoad

Sources
=======
clfrmwrk/LibLoad/src
clfrmwrk/LibLoad/src/LibLoad
clfrmwrk/LibLoad/src/FuncLibLoad (etc for each library load type)

The key here is that we need the ability to release different versions
of different frameworks independent (with restrictions on later
dependencies) of each other.

Of course, your mastery on packaging will mean maybe using the root
(clfrmwrk) to automate that?

What do you think?
-- 
Frank V. Castellucci

Re: [Corelinux-develop] Frameworks

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

> The first thing I realized is that to enable dynamic loading I need to
> add the /usr/lib/libdl.a to the link line. Ipso facto it stands to
> reason that if I integrate this work to libcorelinux we end up with a
> dependency in the core we didn't normally have.

libdl.a is standard, so requiring it is not such an issue
what we can do is update the corelinux configure.in to enable -ldl for the 
examples
and update the AC_CHECK_CORELINUX for users who want  to useconf+corelinux
and document for all other users

>
> What I'm getting at is I think that the IMPLEMENTATION of frameworks, in
> this case the FunctionalLibrary loader et.al. are probably really an
> example of the CoreLinux++ frameworks that are one of the goals of the
> project.
>
> Anyone?
so what you say is that it is time to putthings into libframeworks?
if so why not!
in fact it is quite good to think that core(linux)  really means it (that it 
is a core library): that is to say that it doesn't extra libs

-ldl is not such a requirement but keeping corelinux as a standalone lib(a 
part the c++ lib of course) is very good since dl features are needed only 
for a one corelinux feature

My preference would be to not add -ldl as a requirement and so begin to 
populate corelinux++ frameworks 

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

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

Ok,

What I am do is added ex22 to build up the FunctionLibrary components,
for testing, before integrating into libcorelinux. This enables me to
incrementally test the abstractions in the core.

The first thing I realized is that to enable dynamic loading I need to
add the /usr/lib/libdl.a to the link line. Ipso facto it stands to
reason that if I integrate this work to libcorelinux we end up with a
dependency in the core we didn't normally have.

What I'm getting at is I think that the IMPLEMENTATION of frameworks, in
this case the FunctionalLibrary loader et.al. are probably really an
example of the CoreLinux++ frameworks that are one of the goals of the
project.

Anyone?

-- 
Frank V. Castellucci

Re: [Corelinux-develop] Library abstraction code in

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

Christophe Prud'homme wrote:
> 
> > Yep, I haven't found any problems other than the ones you fixed.
> good
> 
> > Yes, the reference package is something you may want to generate along
> > with the debian pacakges until I get the doxygen updates.
> 
> but what abount the rpm?
> the ref manual is also generated for rpm for the corelinux-doc

Yes, I have a problem generating that, although you may have forgotten.
I need to apply the update as I am running doxygen 1.1.2. I will check
their site to see if they have a rpm for the latest release, otherwise I
will get the source and build.

> > > - how to make reference manual nicer with doxygen
> > >   put a few comments about how to document classes
> >
> > Am I doing it wrong using the JavaDoc tags?
> yes but you can have much much more
> 
> - todo list
> - warning
> - bug list
> - include examples
> - better formatting
> - inclusion of images (like the use cases amnd classes diagrams)
>   that would be just great
>   I'll work on that for the next version if you agree

I will spend some time with the doxygen specific tags. BUT, as you
appear to be enamored with things that make presentation wonderful, when
the next better mousetrap comes along how will we deal with tools
specific tagging? What I would prefer is a universal tagging option
(JavaDoc?) that doesn't tie us down and yet still provides quality
output.

I would prefer we start thinking about a more complete developers guide
which would have all the requirements, analysis, and design
documentation. But that would be HUGE. For now, I would skip putting the
use-case/class diagrams in the class reference.

> 
> > We may want to start a cvs branch of utilities and scripts?
> why not
> what do you propose as a module name?

devscripts? buildtools? projtools?

Frank

Re: [Corelinux-develop] Library abstraction code in

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

> > Am I doing it wrong using the JavaDoc tags?
>
> yes but you can have much much more
I meant no but we can have something even better, sorry :)


-- 
 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 colmatti 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

Re: [Corelinux-develop] Library abstraction code in

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

> Yep, I haven't found any problems other than the ones you fixed.
good


> Yes, the reference package is something you may want to generate along
> with the debian pacakges until I get the doxygen updates.

but what abount the rpm?
the ref manual is also generated for rpm for the corelinux-doc

>
> > - how to make reference manual nicer with doxygen
> >   put a few comments about how to document classes
>
> Am I doing it wrong using the JavaDoc tags?
yes but you can have much much more

- todo list
- warning 
- bug list
- include examples
- better formatting
- inclusion of images (like the use cases amnd classes diagrams)
  that would be just great 
  I'll work on that for the next version if you agree

> We may want to start a cvs branch of utilities and scripts?
why not
what do you propose as a module name?

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

Re: [Corelinux-develop] Library abstraction code in

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

Christophe Prud'homme wrote:
> 
> > Any issues/questions/etc?
> None on my side I just made a little change on debian side for the building
> process
> and the packages are done.
> I 'll check the installation and a few other things
> 
> is everything ok with rpm?

Yep, I haven't found any problems other than the ones you fixed.

> I'll be there tomorrow so we can tackle the last problems, issues
> and documentation requirements
> 
> on the doc side
> - how to make deb packages
> - how to make redhat package
> - how to generate the reference manual (BTW doxygen is working well, with the
>    pdf patch and there is a qt graphical interface that comes with it by
>    passing --with-doxywizard or something like that to configure)

Yes, the reference package is something you may want to generate along
with the debian pacakges until I get the doxygen updates.

> - how to make reference manual nicer with doxygen
>   put a few comments about how to document classes

Am I doing it wrong using the JavaDoc tags?

> 
> comments?
> 
> >
> > Oh, yeah, Christophe: The update.makefile.pl in /src/testdrivers is not
> > meant to be run by hand for anyreason is it?
> this script allowed me to update all the makefile with the -lcl++
> it can be helpful in the future but you can remove it if you want

We may want to start a cvs branch of utilities and scripts?

-- 
Frank V. Castellucci

Re: [Corelinux-develop] Library abstraction code in

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

> Any issues/questions/etc?
None on my side I just made a little change on debian side for the building 
process
and the packages are done.
I 'll check the installation and a few other things

is everything ok with rpm?

I'll be there tomorrow so we can tackle the last problems, issues
and documentation requirements

on the doc side
- how to make deb packages
- how to make redhat package
- how to generate the reference manual (BTW doxygen is working well, with the 
   pdf patch and there is a qt graphical interface that comes with it by      
   passing --with-doxywizard or something like that to configure)
- how to make reference manual nicer with doxygen 
  put a few comments about how to document classes 

comments?

>
> Oh, yeah, Christophe: The update.makefile.pl in /src/testdrivers is not
> meant to be run by hand for anyreason is it?
this script allowed me to update all the makefile with the -lcl++
it can be helpful in the future but you can remove it if you want


-- 
  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] Library abstraction code in

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

I check-in all of the abstract framework stuff.
I am going to try to start capturing the "how to" in the developers
guide before the build.

Any issues/questions/etc?

Oh, yeah, Christophe: The update.makefile.pl in /src/testdrivers is not
meant to be run by hand for anyreason is it?
-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package

[Corelinux-develop] Getting 0.4.26 out

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

Ok,

I hope to get 0.4.26 out by Monday, to at least include:

The abstract Library Load implementation but NOT the FunctionLibrary
extension, updated model (3.51 format), and web pages of same.

If you guys can go through and mark whatever defect/features that are
fixed to Fixed, I will make a note in the ChangeLog.

C., we will have to get you to build the DEB package at some point
before the release.

Any issues with any of this?

-- 
Frank V. Castellucci

Re: [Corelinux-develop] Event Semaphore

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

Hans Dulimarta wrote:
> 
> I'll start working on EventSemaphore implementation.
> I assume I don't have to create a new task in the
> CoreLinux++ Task Manager because it is part of Task 12063
> (Semaphore Requirement).
> Correct?

Correct
-- 
Frank

[Corelinux-develop] Event Semaphore

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

I'll start working on EventSemaphore implementation.
I assume I don't have to create a new task in the
CoreLinux++ Task Manager because it is part of Task 12063
(Semaphore Requirement).
Correct?


-- 
Hans Dulimarta, Ph.D.                           
dul...@co...
Vis. Research Assoc.                 
http://www.egr.msu.edu/~dulimart   
Ph: 517-432-7589  Fax: 760-281-7691  
http://corelinux.sourceforge.net
Elec. & Comp. Engg., Michigan State University, East
Lansing, MI 48824