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

Re: [Corelinux-develop] libclfw++ 0.2.7 Released

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

Maybe the logs?

Christophe Prud'homme wrote:

> Le Lundi 30 Avril 2001 09:20 am, vous avez écrit :
>   > Hey!
>   >
>   > Hows it going dude? Long time no speak, I put the other debs up on the
>   > release page and will do the same with the clfw 0.2.7 when you are done?
> Ok no problem
> I need to clean the package a bit( remove warnings and errors given by lintian)
> I wonder if it is possible to have some statistics on the htdocs/debian dir
> to see how many people downloaded the packages
>
> When I did that on my own machines a while ago, I discovered that many people
> registered my deb directory.
>
> regards
> C.
> --
> Christophe Prud'homme
> OOA and OOD for Linux
> CoreLinux -- http://corelinux.sourceforge.net
> Finite Element Method Codes
> KFem      -- http://kfem.sourceforge.net
>
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/lists/listinfo/corelinux-develop

Re: [Corelinux-develop] libclfw++ 0.2.7 Released

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

Le Lundi 30 Avril 2001 09:20 am, vous avez =E9crit :
  > Hey!
  >
  > Hows it going dude? Long time no speak, I put the other debs up on th=
e
  > release page and will do the same with the clfw 0.2.7 when you are do=
ne?
Ok no problem
I need to clean the package a bit( remove warnings and errors given by li=
ntian)
I wonder if it is possible to have some statistics on the htdocs/debian d=
ir=20
to see how many people downloaded the packages

When I did that on my own machines a while ago, I discovered that many pe=
ople
registered my deb directory.

regards
C.
--=20
Christophe Prud'homme=20
OOA and OOD for Linux
CoreLinux -- http://corelinux.sourceforge.net
Finite Element Method Codes
KFem      -- http://kfem.sourceforge.net

Re: [Corelinux-develop] libclfw++ 0.2.7 Released

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

Hey!

Hows it going dude? Long time no speak, I put the other debs up on the
release page and will do the same with the clfw 0.2.7 when you are done?

Frank

Christophe Prud'homme wrote:

> Le Samedi 28 Avril 2001 07:39 pm, vous avez écrit :
>   > [Corelinux-develop] libclfw++ 0.2.7 Released
> I'll make the debs ASAP
>
> C.
> --
> Christophe Prud'homme
> OOA and OOD for Linux
> CoreLinux -- http://corelinux.sourceforge.net
> Finite Element Method Codes
> KFem      -- http://kfem.sourceforge.net
>
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/lists/listinfo/corelinux-develop

Re: [Corelinux-develop] libclfw++ 0.2.7 Released

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

Le Samedi 28 Avril 2001 07:39 pm, vous avez =E9crit :
  > [Corelinux-develop] libclfw++ 0.2.7 Released
I'll make the debs ASAP

C.
--=20
Christophe Prud'homme=20
OOA and OOD for Linux
CoreLinux -- http://corelinux.sourceforge.net
Finite Element Method Codes
KFem      -- http://kfem.sourceforge.net

[Corelinux-develop] libclfw++ 0.2.7 Released

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

This release contains the Schema and Concept modeling constructs and
services.

Schemas and Persistence
=======================

This release enables a very powerful framework abstraction: Persistence

The persistence abstraction is built on the premise that the actual
storage service code, that which implements concrete persist services
beneath the abstraction, should be intelligent enough to take guidance
from domain descriptions (concepts) defined in a schema that is
independent of the kind of storage service the application selects. Said
concepts define the types to be stored, in addition to other
information, and it is the job of the storage service to manage the data
layout and service execution as defined by it's implementation.

It is, after all, the 21st century.

Tarball:
http://prdownloads.sourceforge.net/corelinux/libclfw-0.2.7.tar.gz

RPM:
http://prdownloads.sourceforge.net/corelinux/libclfw-0.2.7-1.i386.rpm

Release Notes:
http://sourceforge.net/project/shownotes.php?release_id=32976


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

[Corelinux-develop] Begining Draft on Persist and Schema

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

Schemas and Persistence
=======================

Premise
-------
The persistence abstraction is built on the premise that the actual 
storage service code, that which implements concrete persist services
beneath
the abstraction, should be intelligent enough to take guidance from
domain
descriptions (concepts). Said concepts define the types to be stored, in
addition to
other information, and it is the job of the storage service to manage
the data layout 
and service execution as defined by it's implementation.

It is, after all, the 21st century.

This benefits the application developer from having to worry about
the details of a particular storage service, as well as having
the flexibility to change persist implementations at will, or by user
choice. 

Overview
--------
There are actually two (2) aspects to the CoreLinux++ Abstract Persist
framework: Schemas and Services. This release focuses on the newly
provided Schema constructs. * Please refer to the current implementation 
restrictions at the end of this document.

A Schema is an organization of concepts to model an idea. In this case,
what is being modeled are the types that the application will want
to have made persistent. When a schema has been modeled, it is then
usable
as a roadmap, in effect, to guide the storage implementation. For
example,
the types may represent tables in a relational database storage service,
or a file type for a flat file service. It is ultimatley up to the
service
to decide how to "plan the trip".

There are two (2) workflows around Schemas and their concepts: Model and
Run. Lets talk turkey first:

Schema Modeling
---------------
Schema modeling is supported through built-in services and functions of
the library. 
All modeling changes are persisted to gdbm databases, and the domain
modeler 
need only focus on making their schema correct. While there is a
tremendous 
opportunity for adventerous open source developers to build tools 
around this (GUI, etc.), the library contains the fundemental
capabilities to 
Create, Request, Update, and Delete Schemas or their artifacts
(concepts).

The example test driver (clfw/src/testdrivers/exf2) shows some of the
fundemental
capabilities.

Current Implementation Restrictions
=================================== 

Name/Value Declarations
-----------------------
While ultimately Schemas and Concepts attributes won't be limited as to
the
depth or types supported, the current implementation assumes most
attributes
are of the form: Name:Value, where:

Name is the Key data member of the Attribute and should be of type
FrameworkString
Value is the Value data member of the Attribute and should be of type
FrameworkString

Primary Schema Declarations
---------------------------
For schemas, the following are the recognized attribute keys:

    Attribute Key  : "Name"
    Expected Value : Unique name for this schema
    Example: "Franks Schema" 

    Attribute Key  : "Collection"
    Expected Value : The collection type literal (currently "Array" or
"SetCollection")
    *Note - SetCollection is safer for insuring unique name keys,
although as
    new collection types are added it is really up to the modeling
support.

    Attribute Key  : "Location"
    Expected Value : Qualified path where schema should be stored
    *Note - this is optional, default is ~/.clfw++/schemas/"Name"

    Attribute Key  : "GUID"
    Expected Value : Stringified UniversalIdentifier to be used
    *Note - default is the system will generate, to string up a
    UniversalIdentifier use the UniversalIdentifier::getAsString( buffer
* )
    static method.

with the following attribute keys expected to be supported in later
releases:

     Attribute Key  : "SchemaClass"
     Expected Value : The Schema class type literal to be used when
instantiating
     a new schema, this will be stored with the Schema descriptor and
     will be used when reloading in new sessions.
     Example: "FranksWickedSchemaDerivation"

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

[Corelinux-develop] 0.4.32 debs on SourceForge

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

I have put the debian files that Christophe mentioned onto the
SourceForge project files page.


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

[Corelinux-develop] debian packages for corelinux 0.4.32

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

dear corelinux/debian users,

the debian packages for corelinux0.4.32 have been created and uploaded fo=
r sid/unstable distribution

add this to your /etc/apt/sources.list=20

deb http://corelinux.sourceforge.net/debian ./
deb-src http://corelinux.sourceforge.net/debian ./

right now only libcorelinux is available but libclfw and libclll will fol=
low shortly
(older versions of ibclfw and libclll are available on the corelinux web =
site)

enjoy
C.
--=20
Christophe Prud'homme=20
OOA and OOD for Linux
CoreLinux -- http://corelinux.sourceforge.net
Finite Element Method Codes
KFem      -- http://kfem.sourceforge.net

[Corelinux-develop] Functional schema management available

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

I have completed what could at best be described as a functional cut at
the schema management aspect of the persistence support in libclfw++. It
is checked into CVS.

I will be working on cleaning it up, enhancing the test/example code to
have a good representation of how to use the framework, and completing
the abstract persist.

Good opportunity for someone to create a Schema management GUI if they
want.

PS: You will need gdbm installed for schema work.

Look for a package release later on in the week.

-- 
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] Of Threads and Signals

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

Yes, I was thinking that each ThreadContext can have Signals registered
(which would mean another Class), each Signal identifies the type and
handler location perhaps.

Hans Dulimarta wrote:
> 
> "Frank V. Castellucci" wrote:
> >
> > Hans,
> >
> > Saw the comment on the feature and check-ins.
> >
> > The problem I had with the signal mask on thread creation was that it
> > wasn't supported in kernel 2.2.12, was I mistaken? Does it work? <grin>
> >
> 
> Does it mean that the CLONE_SIGHAND bit in the mask does not
> have any effect
> in 2.2.12? I'm using 2.2.16, so I don't know how it works in
> 2.2.12.
> 
> If this approach is not supported in earlier kernel, I think
> another
> solution is to let each Thread register its handler to the
> thread manager
> (the Thread class) and when a certain signal is raised, the
> manager
> will lookup a table of registered handlers and call each of
> them.
> This table is index by signal number. However, this approach
> requires
> the manager to define handler for all possible signal
> number.
> 
> > I will test it out later today and have a more detailed look.
> >
> > --
> > Frank V. Castellucci
> > http://corelinux.sourceforge.net
> > OOA/OOD/C++ Standards and Guidelines for Linux
> >
> > _______________________________________________
> > Corelinux-develop mailing list
> > Cor...@li...
> > http://lists.sourceforge.net/lists/listinfo/corelinux-develop
> 
> --
> Hans Dulimarta, Ph.D. |             dul...@co...
> Research Associate    |  http://www.egr.msu.edu/~dulimart
> P: 517-432-7589       | http://snapsource.sourceforge.net
> F: 760-281-7691       |  http://corelinux.sourceforge.net
> ECE Dept. Michigan State University, E. Lansing, MI 48824
> 
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/lists/listinfo/corelinux-develop

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

Re: [Corelinux-develop] Of Threads and Signals

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

"Frank V. Castellucci" wrote:
> 
> Hans,
> 
> Saw the comment on the feature and check-ins.
> 
> The problem I had with the signal mask on thread creation was that it
> wasn't supported in kernel 2.2.12, was I mistaken? Does it work? <grin>
> 

Does it mean that the CLONE_SIGHAND bit in the mask does not
have any effect
in 2.2.12? I'm using 2.2.16, so I don't know how it works in
2.2.12.

If this approach is not supported in earlier kernel, I think
another
solution is to let each Thread register its handler to the
thread manager
(the Thread class) and when a certain signal is raised, the
manager
will lookup a table of registered handlers and call each of
them.
This table is index by signal number. However, this approach
requires
the manager to define handler for all possible signal
number.

> I will test it out later today and have a more detailed look.
> 
> --
> Frank V. Castellucci
> http://corelinux.sourceforge.net
> OOA/OOD/C++ Standards and Guidelines for Linux
> 
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/lists/listinfo/corelinux-develop

-- 
Hans Dulimarta, Ph.D. |             dul...@co...
Research Associate    |  http://www.egr.msu.edu/~dulimart   
P: 517-432-7589       | http://snapsource.sourceforge.net
F: 760-281-7691       |  http://corelinux.sourceforge.net
ECE Dept. Michigan State University, E. Lansing, MI 48824

[Corelinux-develop] Of Threads and Signals

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

Hans,

Saw the comment on the feature and check-ins.

The problem I had with the signal mask on thread creation was that it
wasn't supported in kernel 2.2.12, was I mistaken? Does it work? <grin>

I will test it out later today and have a more detailed look.

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

Re: [Corelinux-develop] Getting libcl++ ready

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

Christophe Prud'homme wrote:
> 
> Le Jeudi 12 Avril 2001 13:54, vous avez écrit :
> > Christophe,
> > How is NEWS entries made in emacs? Is there a similar mode like we use
> > for ChangeLog.
> typially you use outline-mode in emacs for NEWS
> use *, **, *** to define new entries and subentries
> 
> look at the xemacs4.0, the main text is done this way
> and NEWS also
> http://xemacs.sourceforge.net/Releases/21.4.0.html

Thanks

> 
> > What will you need to update before building that I should wait for
> > being checked in before I generate the tarball and RPMS?
> I am in france right now
> I had to come back urgently, I'll be back next monday

Hope everything is alright. 

> however I may need to make some changes in debian dir for the new release
> I need to correct some warnings in debian packages for libclw and libclll
> but again
> 
> > I will get the 0.4.31 out when we are all ready. I will then follow, by
> > a day or two, with the clfw++ and clfll++ updates :).
> Ok
> I'll update the debain stuff when I come back
> ISDN is not that fast and I don't have

Ok, lets talk when you get back. I am still not ready with the libclfw++
yet.

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

Re: [Corelinux-develop] Getting libcl++ ready

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

Le Jeudi 12 Avril 2001 13:54, vous avez =E9crit :
> Christophe,
> How is NEWS entries made in emacs? Is there a similar mode like we use
> for ChangeLog.
typially you use outline-mode in emacs for NEWS
use *, **, *** to define new entries and subentries

look at the xemacs4.0, the main text is done this way
and NEWS also
http://xemacs.sourceforge.net/Releases/21.4.0.html

> What will you need to update before building that I should wait for
> being checked in before I generate the tarball and RPMS?
I am in france right now
I had to come back urgently, I'll be back next monday
however I may need to make some changes in debian dir for the new release
I need to correct some warnings in debian packages for libclw and libclll=
=20
but again=20

> I will get the 0.4.31 out when we are all ready. I will then follow, by
> a day or two, with the clfw++ and clfll++ updates :).
Ok
I'll update the debain stuff when I come back
ISDN is not that fast and I don't have=20

regards
C.

[Corelinux-develop] Debian at your will

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

Christophe,

I have release 0.4.32 so whenever you have the debian builds let me know
or add them to the foray! 

Happy Holidays to everyone

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

[Corelinux-develop] CoreLinux++ 0.4.32 Released

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

Quick on the heels of 0.4.31, thanks to a thoughtful user/tester (it was
an anonymous post) about the argument transposition in memset for
SemaphoreGroup and Memory classes.

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

[Corelinux-develop] ChangeLog

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

Hans,

Thanks for the effort. It missed the 0.4.31 but will be in the 0.4.32
(which may come soon because of defect 416191.


Christophe,
You might want to wait for the debian until 0.4.32 (by Monday or
thereabouts).

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

[Corelinux-develop] CoreLinux++ 0.4.31 Released

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

This release adds limited signal handling to Thread (thanks Hans!).

Christophe will be producing debian packages in the near future.


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

Re: [Corelinux-develop] Getting libcl++ ready

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

As long as we are consistent across all three (3), and soon to be more, 
library ChangeLog formats I am happy.

FC

Hans Dulimarta wrote:

> "Frank V. Castellucci" wrote:
> 
>> Hans,
>> Did you want to muck with ChangeLog?
>> Do we want to revert (starting with this release) to the normal
>> ChangeLog type entries (Ctrl+x 4 a)? If so:
>> 
>> mv ChangeLog ChangeLog.old
>> emacs ChangeLog (add new information)
>> cvs add -m"Initial load" ChangeLog.old
>> cvs commit -m"ChangeLog updates" ChangeLog ChangeLog.old
>> 
> 
> I guess this is the same format which can be generated by
> rcs2log script. Personally, I prefer this format to the
> existing one. I'll take care the Changelog as well (with the
> new format).
> 

Re: [Corelinux-develop] Getting libcl++ ready

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

"Frank V. Castellucci" wrote:
> 

> Hans,
> Did you want to muck with ChangeLog?
> Do we want to revert (starting with this release) to the normal
> ChangeLog type entries (Ctrl+x 4 a)? If so:
> 
> mv ChangeLog ChangeLog.old
> emacs ChangeLog (add new information)
> cvs add -m"Initial load" ChangeLog.old
> cvs commit -m"ChangeLog updates" ChangeLog ChangeLog.old
> 

I guess this is the same format which can be generated by
rcs2log script. Personally, I prefer this format to the
existing one. I'll take care the Changelog as well (with the
new format).

-- 
Hans Dulimarta, Ph.D. |             dul...@co...
Research Associate    |  http://www.egr.msu.edu/~dulimart   
P: 517-432-7589       | http://snapsource.sourceforge.net
F: 760-281-7691       |  http://corelinux.sourceforge.net
ECE Dept. Michigan State University, E. Lansing, MI 48824

[Corelinux-develop] Getting libcl++ ready

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

Christophe,
How is NEWS entries made in emacs? Is there a similar mode like we use
for ChangeLog.
What will you need to update before building that I should wait for
being checked in before I generate the tarball and RPMS?

Hans,
Did you want to muck with ChangeLog? 
Do we want to revert (starting with this release) to the normal
ChangeLog type entries (Ctrl+x 4 a)? If so:

mv ChangeLog ChangeLog.old
emacs ChangeLog (add new information)
cvs add -m"Initial load" ChangeLog.old
cvs commit -m"ChangeLog updates" ChangeLog ChangeLog.old

I will get the 0.4.31 out when we are all ready. I will then follow, by
a day or two, with the clfw++ and clfll++ updates :).

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

Re: [Corelinux-develop] Ok, heading for some releases

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

  > Christophe,
  > Anything from you?
Nope not yet
I have to release something at MIT first
and I am knee deep in multithreads/CORBA stuff

tell me when you want to release, I'll make the debs
humm I have to change my email address for corelinux
I don't check very often the one I gave to sourceforge in the past


best regards
C.
--=20
Christophe Prud'homme=20
OOA and OOD for Linux
CoreLinux -- http://corelinux.sourceforge.net
Finite Element Method Codes
KFem      -- http://kfem.sourceforge.net

Re: [Corelinux-develop] Ok, heading for some releases

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

On Sun, 8 Apr 2001, Frank V. Castellucci wrote:

> Hans Dulimarta wrote:
> >
> > "Frank V. Castellucci" wrote:
> > >
> > > Hans,
> > >
> > > Is libcl++ ready for a release? I haven't had a chance to try out the
> > > Thread stuff, did it work the way you expected?
> >
> > threadTerminated handler works ok. At least for updating the
> > thread state
> > part. Cleaning via destroying context is not working. But, I
>
> What does this mean? Thread::destroyThreadContext does not work?
>

It does work but cannot be called from threadTerminated.

> > guess since
> > we are going to implement thread pool, this clean up is not
> > really necessary.
> > We can reuse the space and "return" it to the pool.
>
> We may want to talk about heap management somewhere in here, I've done
> some neat things with activity escalation and generational heaps. The
> work was more for garbage collection but was such a simple design that
> it may be re-used in this case. What are you thoughts about the whole
> Thread pool thing?

For me thread pool implementation has a lower priority than the individual
signal handling capability. But, if you can share your heap management
code here, it'll be great.

>
> >
> > I'm now working on the individual thread signal handling.
> >
> > >
> > > The libcorelinux release will be 0.4.31 yes?
> >
> > Yes from me.
>
> Ok, I will assume that at anypoint in time during the week that you
> don't have things partially working, that whatever is checked in works.
> Of course if something didn't work before, I don't expect it will work
> now :)

Yes, you can assume that.

-- 
Hans Dulimarta, Ph.D. |             dul...@co...
Research Associate    |  http://www.egr.msu.edu/~dulimart
P: 517-432-7589       | http://snapsource.sourceforge.net
F: 760-281-7691       |  http://corelinux.sourceforge.net
ECE Dept. Michigan State University, E. Lansing, MI 48824

Re: [Corelinux-develop] Ok, heading for some releases

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

Hans Dulimarta wrote:
> 
> "Frank V. Castellucci" wrote:
> >
> > Hans,
> >
> > Is libcl++ ready for a release? I haven't had a chance to try out the
> > Thread stuff, did it work the way you expected?
> 
> threadTerminated handler works ok. At least for updating the
> thread state
> part. Cleaning via destroying context is not working. But, I

What does this mean? Thread::destroyThreadContext does not work?

> guess since
> we are going to implement thread pool, this clean up is not
> really necessary.
> We can reuse the space and "return" it to the pool.

We may want to talk about heap management somewhere in here, I've done
some neat things with activity escalation and generational heaps. The
work was more for garbage collection but was such a simple design that
it may be re-used in this case. What are you thoughts about the whole
Thread pool thing?

> 
> I'm now working on the individual thread signal handling.
> 
> >
> > The libcorelinux release will be 0.4.31 yes?
> 
> Yes from me.

Ok, I will assume that at anypoint in time during the week that you
don't have things partially working, that whatever is checked in works.
Of course if something didn't work before, I don't expect it will work
now :)

> 
> >
> > Christophe,
> > Anything from you?
> >
> > Frank,
> > I'll have a working schema management subsystem (which will be part of
> > the basework) ready for libclfw++.
> >
> > The libclfw release will be 0.2.7
> >
> > I won't mention docs or website as our collective hearts can't take it
> > :)
> >
> > --
> > Frank V. Castellucci
> > http://corelinux.sourceforge.net
> > OOA/OOD/C++ Standards and Guidelines for Linux
> >
> > _______________________________________________
> > Corelinux-develop mailing list
> > Cor...@li...
> > http://lists.sourceforge.net/lists/listinfo/corelinux-develop
> 
> --
> Hans Dulimarta, Ph.D. |             dul...@co...
> Research Associate    |  http://www.egr.msu.edu/~dulimart
> P: 517-432-7589       | http://snapsource.sourceforge.net
> F: 760-281-7691       |  http://corelinux.sourceforge.net
> ECE Dept. Michigan State University, E. Lansing, MI 48824
> 
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/lists/listinfo/corelinux-develop

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

Re: [Corelinux-develop] Ok, heading for some releases

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

"Frank V. Castellucci" wrote:
> 
> Hans,
> 
> Is libcl++ ready for a release? I haven't had a chance to try out the
> Thread stuff, did it work the way you expected?

threadTerminated handler works ok. At least for updating the
thread state
part. Cleaning via destroying context is not working. But, I
guess since
we are going to implement thread pool, this clean up is not
really necessary.
We can reuse the space and "return" it to the pool.

I'm now working on the individual thread signal handling.

> 
> The libcorelinux release will be 0.4.31 yes?

Yes from me.

> 
> Christophe,
> Anything from you?
> 
> Frank,
> I'll have a working schema management subsystem (which will be part of
> the basework) ready for libclfw++.
> 
> The libclfw release will be 0.2.7
> 
> I won't mention docs or website as our collective hearts can't take it
> :)
> 
> --
> Frank V. Castellucci
> http://corelinux.sourceforge.net
> OOA/OOD/C++ Standards and Guidelines for Linux
> 
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/lists/listinfo/corelinux-develop

-- 
Hans Dulimarta, Ph.D. |             dul...@co...
Research Associate    |  http://www.egr.msu.edu/~dulimart   
P: 517-432-7589       | http://snapsource.sourceforge.net
F: 760-281-7691       |  http://corelinux.sourceforge.net
ECE Dept. Michigan State University, E. Lansing, MI 48824