corelinux-public — General discussions of CoreLinux++

[Corelinux-public] Semaphores - Draft 0.3

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

CoreLinux++ Semaphore Requirement (1589) Draft - Version 0.3
============================================================

A Semaphore is a protocol by which processes and/or threads agree to
follow for the purpose of controlled access to a resource. The resource
can be anything that the developer considers to need access controls on,
such as memory, hardware, methods, computer instructions, and so on.

The protocol is pinned to the kernel which enforces blocking (being made
to wait) the caller until a resource is available.

Callers can elect to avoid being put into a blocked state and return
immediatley without control to the resource. Callers may also request
that they are put into a blocked state for a specified amount of time.
If, at the end of the specified time, the request has not been
satisified, it is returned with a Timeout indicator.

The owner or creator of the semaphore can elect to enforce balking
behavior on a Semaphore. When so designated, the Semaphore can turn back
any request until some condition in their solution space is met
regardless of the callers blocking options. If a caller access attempt
is balked, is it returned with a Balked indicator.

Used to serialized access to a resource (one to one)
----------------------------------------------------

When used to prevent concurrent access to a resource, the caller must
first obtain control of the associated Semaphore. When a caller has
control of the Semaphore, the resource(s) that are associated with the
Semaphore are considered locked and accessible by the caller. When the
caller has completed access of the resource it relinquishes control and
the resource is now considered unlocked. 

Attempts may be made to access the resource by other threads of
execution or from seperate processes. These callers are queued and the
requestor is put into a blocked state. In this state the caller waits
until the resource is unlocked. If multiple requests are blocking for
the same control, the determination of which caller gains access next
is, from a applications perspective, arbitrary.

When balking mode is enabled callers will be turned away as long as the
Semaphore is locked.

Used to provide concurrent finite access (one to many)
------------------------------------------------------

When used in this fashion, a Semaphore can be used as an access count
controller. The Semaphore is created, as determined by the solution
domain, with the maximum number of concurrent active callers allowed. As
long as the caller count does not reach the maximum, the arrival will be
granted immediate access. When the maximum has been reached, arriving
callers are blocked. 

When balking mode is enabled callers will be turned away until the count
reduces to less than maximum.

Used to block callers until an event occurs (many to one)
---------------------------------------------------------

When used in this fashion, a single Semaphore is used to let callers
block until some event occurs. Unlike the serialzed access, where one
caller at a time is released to gain access to a resource, when the
designated event occurs all blocked callers are released at once. 

The creator of this type of Semaphore can designate the maximum number
of listeners that can wait on a single Semaphore event. When used in
this manner, balking mode is automatically enabled.

When balking mode is enabled callers will be turned away until the
number of listeners on the event drops below maximum.

Semaphore Groups
----------------
A Semaphore group is an extension to the Linux semaphore set. This
provides a way to logically group semaphores. For example, it may be
useful in a solution domain to group One-To-One semaphores differently
from Many-to-One semaphores.


CoreLinux Semaphore Functional Requirements
===========================================

General Requirements
---------------------

There will be no restriction on the type of the Semaphore that can be
created other than system dependent resources.In this event, an
exception will be thrown indicating, if possible, why the Semaphore
could not be created.

The default mode for all Semaphore will be non-Balking.

All Semaphore Groups will support named creation.

All Semaphore Groups will support maximum group count creation. This
identifies the number of maximum semaphores in the group.

All Semaphore Groups will support a segregation by type (One-to-One,
One-to-Many, and Many-to-One).

All Semaphore Groups will support instrumentation.

All Semaphores will support having a user defined identifier.

All Semaphores will maintain a group and instance identifier.

Callers will be able to "get" a Semaphore by it's Group and Instance
Identifier.

Callers will be able to "get" a Semaphore by it's Instance Identifier.

All Semaphores will support instrumentation.

All Semaphores will support access by only the process that creates it.

All Semaphores will support access by the process that creates it, and
any children that the process spawns.

All Semaphores will support access by any process.

All Semaphores will support read only operations for each of the above
access modes.

All Semaphores will support read/write operations for each of the above
access modes.

All Semaphores will support a recursion disposition.

All other Semaphores will support a lock semantic in that the caller
will wait until the lock is obtained.

All Semaphores will support the lock semantic with no-wait option so
that the caller will return immediatley if the lock can not be
immediatley obtained.

All Semaphores will support the lock semantic with timeout option so
that the caller can indicate a maximum amount of time before giving up
trying to obtain the lock.

General One-to-One Semaphore
----------------------------
One-to-One Semaphores will support a create and automatically lock
capability. 
One-to-One Semaphores will support a create and no-lock capability.

General One-to-Many Semaphore
-----------------------------
One-to-Many Semaphores will support a create with a maximum resource
count.
One-to-Many Semaphores will support a create and automatically lock
capability which means no resources are available.
One-to-Many Semaphores will support a create and no-lock capability
which means all (maximum) resources are available.
One-to-Many Semaphores will support increasing the maximum count.

General Many-to-One Semaphore
-----------------------------
Many-to-One Semaphores will support a create with a maximum "listener"
count
Many-to-One Semaphores will automatically lock upon creation. There is
not option to create it unlocked.
Many-to-One Semaphores will support increasing the maximum "listener"
count if balking mode enabled.

General Semaphore Groups
------------------------
CoreLinux++ will support a default, heterogeneous, Semaphore Group. Name
TBD, maximum semaphore count TBD.

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

[Corelinux-public] Semaphore - 0.2

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

CoreLinux++ Semaphore Requirement (1589) Draft - Version 0.2
============================================================

A Semaphore is a protocol by which processes and/or threads agree to
follow for the purpose of controlled access to a resource. The resource
can be anything that the developer considers to need access controls on,
such as memory, hardware, methods, computer instructions, and so on.

The protocol is pinned to the kernel which enforces blocking (being made
to wait) the caller until a resource is available.

Callers can elect to avoid being put into a blocked state and return
immediatley without control to the resource. Callers may also request
that they are put into a blocked state for a specified amount of time.
If, at the end of the specified time, the request has not been
satisified, it is returned with a Timeout indicator.

The owner or creator of the semaphore can elect to enforce balking
behavior on a Semaphore. When so designated, the Semaphore can turn back
any request until some condition in their solution space is met
regardless of the callers blocking options. If a caller access attempt
is balked, is it returned with a Balked indicator.

Used to serialized access to a resource (one to one)
----------------------------------------------------

When used to prevent concurrent access to a resource, the caller must
first obtain control of the associated Semaphore. When a caller has
control of the Semaphore, the resource(s) that are associated with the
Semaphore are considered locked and accessible by the caller. When the
caller has completed access of the resource it relinquishes control and
the resource is now considered unlocked. 

Attempts may be made to access the resource by other threads of
execution or from seperate processes. These callers are queued and the
requestor is put into a blocked state. In this state the caller waits
until the resource is unlocked. If multiple requests are blocking for
the same control, the determination of which caller gains access next
is, from a applications perspective, arbitrary.

When balking mode is enabled callers will be turned away as long as the
Semaphore is locked.

Used to provide concurrent finite access (one to many)
------------------------------------------------------

When used in this fashion, a Semaphore can be used as an access count
controller. The Semaphore is created, as determined by the solution
domain, with the maximum number of concurrent active callers allowed. As
long as the caller count does not reach the maximum, the arrival will be
granted immediate access. When the maximum has been reached, arriving
callers are blocked. 

When balking mode is enabled callers will be turned away until the count
reduces to less than maximum.

Used to block callers until an event occurs (many to one)
---------------------------------------------------------

When used in this fashion, a single Semaphore is used to let callers
block until some event occurs. Unlike the serialzed access, where one
caller at a time is released to gain access to a resource, when the
designated event occurs all blocked callers are released at once. 

The creator of this type of Semaphore can designate the maximum number
of listeners that can wait on a single Semaphore event. When used in
this manner, balking mode is automatically enabled.

When balking mode is enabled callers will be turned away until the
number of listeners on the event drops below maximum.


CoreLinux Semaphore Functional Requirements
===========================================

General Reqquirements
---------------------

There will be no restriction on the type of the Semaphore that can be
created other than system dependent resources.In this event, an
exception will be thrown indicating, if possible, why the Semaphore
could not be created.

The default mode for all Semaphore will be non-Balking.

All Semaphores will support access by only the process that creates it.

All Semaphores will support access by the process that creates it, and
any children that the process spawns.

All Semaphores will support access by any process.

All Semaphores will support read only operations for each of the above
access modes.

All Semaphores will support read/write operations for each of the above
access modes.

All Semaphores will support a recursion disposition.

All other Semaphores will support a lock semantic in that the caller
will wait until the lock is obtained.

All Semaphores will support the lock semantic with no-wait option so
that the caller will return immediatley if the lock can not be
immediatley obtained.

All Semaphores will support the lock semantic with timeout option so
that the caller can indicate a maximum amount of time before giving up
trying to obtain the lock.

General One-to-One Semaphore
----------------------------
One-to-One Semaphores will support a create and automatically lock
capability. 
One-to-One Semaphores will support a create and no-lock capability.

General One-to-Many Semaphore
-----------------------------
One-to-Many Semaphores will support a create with a maximum resource
count.
One-to-Many Semaphores will support a create and automatically lock
capability which means no resources are available.
One-to-Many Semaphores will support a create and no-lock capability
which means all (maximum) resources are available.
One-to-Many Semaphores will support increasing the maximum count from
the managing process only.

General Many-to-One Semaphore
-----------------------------

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://www.colconsulting.com 
Object Oriented Analysis and Design |Java and C++ Development

[Corelinux-public] CoreLinux++ 0.4.8 Released

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

I release it yesterday. Completes Creational pattern implementation.
---
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

Re: [Corelinux-public] coding standards

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

Dan Kegel wrote:
> 
> IMHO one important part of a set of coding standards these
> days is to specify which set of GNU Indent options are
> closest to the standard.  Ideally, one should pick a
> standard that GNU Indent can actually output.

Why?

> 
> The latest version of indent can be found at
> http://www.xs4all.nl/~carlo17/indent/
> 
> Have any of the 'corelinux' people played around with indent?
> - Dan

I have visited the web site. It states it is a "C" indent beautification
tool, does it work with C++? Templates? JavaDoc comment styles? 

I'm interested if it DOES and we have team members who want to use their
own style, code can be converted before checking in so that conforms to
the CoreLinux++ style. It would be helpful to point this tool out to
them.

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

[Corelinux-public] coding standards

[Dan K. <da...@al...>]

IMHO one important part of a set of coding standards these
days is to specify which set of GNU Indent options are
closest to the standard.  Ideally, one should pick a
standard that GNU Indent can actually output.

The latest version of indent can be found at
http://www.xs4all.nl/~carlo17/indent/

Have any of the 'corelinux' people played around with indent?
- Dan

[Corelinux-public] Semaphores

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

Before I move into the Behavioral patterns I feel that the robustness of
the library is in risk with regards to threading and control, if you
have the ability to read the patterns you will see why. 

But threads have a dependency (in my experience) on semaphores. So while
there has been some exchanges about semaphores there has been no
indication that they are any closer to getting into the library, it is
for this reason that I am now giving it focus. The following is the high
level use cases:

CoreLinux++ Semaphore Requirement Draft - Version 0
====================================================

High Level View
---------------

A Semaphore is a protocol by which processes and/or threads agree to
follow for the purpose of controlled access to a resources by blocking
(being made to wait) the caller. The resource can be anything that the
developer considers to need access controls on, such as memory,
hardware, methods, computer instructions, and so on.

Callers can elect to avoid being put into a blocked state and return
immediatley without control to the resource. Callers may also request
that they are put into a blocked state for a specified amount of time.
If at the end of the specified time the request can not be satisified,
it is returned with a Timeout indicator.

The owner or creator of the semaphore can elect to enforce balking
behavior on a Semaphore. When so enabled the Semaphore can turn back any
request until some condition in their solution space is met, regardless
of the callers blocking options. If a caller access attempt is balked,
it is returned with a Balked indicator.


Used to serialized access to a resource (one to one)
----------------------------------------------------

When used to prevent concurrent access to a resource, the caller must
first obtain control of the access Semaphore. When a caller has control
of the Semaphore, the resource(s) that are associated with the Semaphore
are considered locked and accessible only by the caller. When the caller
has completed access of the resource it relinquishes control and the
resource is now considered unlocked. 

Attempts may be made to access the resource by other threads of
execution or from seperate processes. These callers are queued and the
requestor is put into a blocked state. In this state the caller waits
until the resource is unlocked. If multiple requests are blocking for
the same control, the determination of which caller gains access next
is, from a applications perspective, arbitrary.

When balking mode is enabled callers will be turned away as long as the
Semaphore is locked.

Used to provide concurrent finite access (one to many)
------------------------------------------------------

When used in this fashion, a Semaphore can be used as an access count
controller. The Semaphore is created, as determined by the solution
domain, with the maximum number of concurrent active callers allowed. As
long as the caller count does not reach the maximum, the arrival will be
granted immediate access. When the maximum has been reached, arriving
callers are blocked. 

When balking mode is enabled callers will be turned away until the count
reduces to less than maximum.

Used to block callers until an event occurs (many to one)
---------------------------------------------------------

When used in this fashion, a single Semaphore is used to let callers
block until some event occurs. Unlike the serialzed access, where one
caller at a time is released to gain access to a resource, when the
designated event occurs all blocked callers are released at once. 

Balking mode is not available with this type Semaphore.

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

[Corelinux-public] CoreLinux 0.4.7 Released

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

Completes Structural
50% Creational

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

[Corelinux-public] Developer Utility Forum Created

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

I don't think I mentioned this but I created a CoreLinux++ Developer
Utility forum for gathering requirements for tools that either the
CoreLinux++ team, or users can that are following our process, will find
useful.

I kicked off with a couple of requests, anyone interested should add
this forum to their monitor list.

---
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://www.colconsulting.com
Object Oriented Analysis and Design |Java and C++ Development

Re: [Corelinux-public] Bridge in, Proxy on the way

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

"Frank V. Castellucci" wrote:
> 
> Bridge analysis, design, implementation and test code in
> Proxy design in
> Implementation proceeding
> 
> --
> Frank V. Castellucci
> http://corelinux.sourceforge.net
> OOA/OOD/C++ Standards and Guidelines for Linux
> 
> _______________________________________________
> Corelinux-public mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-public

Sorry, not Bridge but Builder.

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

[Corelinux-public] Bridge in, Proxy on the way

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

Bridge analysis, design, implementation and test code in
Proxy design in
Implementation proceeding

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

[Corelinux-public] Going for 0.4.7

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

I am trying for a Monday or Tuesday release for 0.4.7,

Flyweight (done)
Proxy ( needs design and implementation )
Builder ( building test code now )
Factory Methods (this is already in the form of
Allocator/AbstractAllocator)

And if time allows, the SRS for the Behavioral Patterns

Anybody have anything they can get in as well?

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

[Corelinux-public] Flyweight is in

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

A redesign and implementation with test is available with a CVS update.
Web updated with Class Reference and Flyweight design changes.

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

[Corelinux-public] Mea Culpa

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

Ok,

I asked for it by posting requirement ideas for the core and framework.
The mailing list received some feedback and I have been receiving
e-mails from outside stating "how about...".

Feel free to put them in the REQUIREMENTS forum on the CoreLinux++
Project in Source Forge as well.

The forum is not limited to what will be implemented but what is
requested to implement. The process will take over from there.

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

Re: [Corelinux-public] Looking ahead

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

Ivan Bilenkey wrote:
> 
> "Frank V. Castellucci" wrote:
> 
> > Here are my ideas for the libcorelinux 1.0.0 release:
> >
> > All GoF patterns
> > Exception
> > Semaphore
> > Monitor
> > String
> > Thread
> > Process
> > SmartPointer
> > ReferenceCounter
> > Module
> > MetaClass
> >
> > Here are my ideas for the libcoreframework 1.0.0 release:
> >
> > Application
> > Persistence
> > Resource/Properties
> > Naming and Directory Service
> > Algorithm Toolkit
> > Java Proxy and JVM interface (others? abstraction?)
> >
> > Anyone?
> >
> 
> How about Cache pattern. I've implemented it in java several times
> and could do it for libcorelinux too. Its just that I recently
> subscribed
> to the list and would like some time browsing around.
> 
> Ivan Bilenkey
> 

Ivan,
Ok, we have allocator and factory, did you see cache that would exist
outside of these patterns? What about garbage collection, I have some
great material on that.

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://www.colconsulting.com 
Object Oriented Analysis and Design |Java and C++ Development

Re: [Corelinux-public] Looking ahead

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

"Nicholas D Salerno;951;esen1;" wrote:
> 
> "Frank V. Castellucci" wrote:
> 
> > Here are my ideas for the libcoreframework 1.0.0 release:
> >
> > Application
> > Persistence
> > Resource/Properties
> > Naming and Directory Service
> > Algorithm Toolkit
> > Java Proxy and JVM interface (others? abstraction?)
> >
> > Anyone?
> >
> 
>         What is the scope of the libcoreframework library?  Console, GUI,
> both?  For console, whether be in an xterm or a real console, how complex
> could this get?  Could we provide a text based windowing system for an
> application to utilize (example, TVision by Borland, if anyone has ever
> used a Borland IDE for DOS, it was cool), or are we just providing a
> framework to help structure their program, but the UI is up to them?
> 

There should be no limitations to the fundemental framework that require
either console or GUI. On the other hand, there is nothing to say we
don't have frameworks <-- plural. And an endeavor to do a GTK-- type
thing that is CoreLinux++ oriented is fine by me.

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

Re: [Corelinux-public] Looking ahead

[Nicholas D Salerno;951;esen1; <nd...@cs...>]

"Frank V. Castellucci" wrote:
 
> Here are my ideas for the libcoreframework 1.0.0 release:
>
> Application
> Persistence
> Resource/Properties
> Naming and Directory Service
> Algorithm Toolkit
> Java Proxy and JVM interface (others? abstraction?)
>
> Anyone?
>

	What is the scope of the libcoreframework library?  Console, GUI,
both?  For console, whether be in an xterm or a real console, how complex
could this get?  Could we provide a text based windowing system for an
application to utilize (example, TVision by Borland, if anyone has ever
used a Borland IDE for DOS, it was cool), or are we just providing a
framework to help structure their program, but the UI is up to them?

	Nicholas

Re: [Corelinux-public] Looking ahead

[Ivan B. <bil...@un...>]

"Frank V. Castellucci" wrote:

> Here are my ideas for the libcorelinux 1.0.0 release:
>
> All GoF patterns
> Exception
> Semaphore
> Monitor
> String
> Thread
> Process
> SmartPointer
> ReferenceCounter
> Module
> MetaClass
>
> Here are my ideas for the libcoreframework 1.0.0 release:
>
> Application
> Persistence
> Resource/Properties
> Naming and Directory Service
> Algorithm Toolkit
> Java Proxy and JVM interface (others? abstraction?)
>
> Anyone?
>
> --
> Frank V. Castellucci
> http://corelinux.sourceforge.net
> OOA/OOD/C++ Standards and Guidelines for Linux
>
> _______________________________________________
> Corelinux-public mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-public

How about Cache pattern. I've implemented it in java several times
and could do it for libcorelinux too. Its just that I recently
subscribed
to the list and would like some time browsing around.

Ivan Bilenkey

[Corelinux-public] Looking ahead

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

Here are my ideas for the libcorelinux 1.0.0 release:

All GoF patterns
Exception
Semaphore
Monitor
String
Thread
Process
SmartPointer
ReferenceCounter
Module
MetaClass


Here are my ideas for the libcoreframework 1.0.0 release:

Application
Persistence
Resource/Properties
Naming and Directory Service
Algorithm Toolkit
Java Proxy and JVM interface (others? abstraction?)

Anyone?

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

[Corelinux-public] Flyweight example

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

Ok, now that we have the AbstractFactory/Allocator in, I am moving on to
Flyweight. 

As an example I believe taking ex9 and exchanging the products (walls,
doors, rooms) and reducing them all down to flyweight instantiations as
needed. 

Assuming rooms are four sided (East, North, West, South) and there needs
to be at least one way to enter and exit a room:

Each room is identified by a RoomNumber {1..*} *=infinite

Each room has a cardinality of sides [4]
The constraints on sides being:
	Sides == Door | Wall
	at least one Side == Door

Each Door connects Rooms [2]
The constraint being:
	theRoom[1].theRoomNumber != theRoom[2].theRoomNumber

unless of course it is a M.C. Escher maze, anyway...

The door[s] can be reduced to an association of the room sets:
	DoorId<>------>{RoomNumber, RoomNumber}

The room can be reduced to a record 

RoomNumber<>----->NORTH{W|DoorId},EAST{W|DoorId},SOUTH{W|DoorId},WEST{W|DoorId}

The way I see it:

We only ever need one (1) shared wall flyweight for whatever amount of
walls are in the theoretical space.
We also share the room flyweight because you can only be in one room at
a time.
and you only need at maximum four (4) door flyweights if all the sides
of a room are doors.

Anyone?

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

Re: [Corelinux-public] ACE

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

Stephen Blake wrote:
> 
> This message was sent from Geocrawler.com by "Stephen Blake" <se...@my...>
> Be sure to reply to that address.
> 
> I have been browsing the archives a bit and noticed that you are talking about threads, etc. I am
> wondering if any of you have heard of ACE. It's a really nice OO networking library that supports
> multithreading, etc. Anyway, it's an opensource project, and it's developed by a great bunch of
> people. In fact I think there are no restrictions at all with how you can use their code. Anyway,
> just thought I would bring it up. They also have a nice Corba Orb called Tao that is built on ACE.
> Here are the url's if you are interested in checking it out. It might be helpful to your project.
> 
> http://www.cs.wustl.edu/~schmidt/ACE.html
> http://www.cs.wustl.edu/~schmidt/TAO.html
> 
> Stephen Blake
> se...@my...

Stephen,
I took a look at ACE and a few other frameworks before starting the
whole CoreLinux++ initiative. I think there are a number of good
reference when, or I should say if, we ever move into that problem
space. 

Again my opinion, I think that the core library should be a group of
reusable classes that drive right to the Linux interface and provide the
best performance possible, and the frameworks being constructed in such
a manner as to allow easy adaptations to external libraries and classes.
Take our String conversations for example, do we want to write a
UnicodeString? Maybe someday, but I see the biggest benefit in providing
adapters so that the developers can pick and choose which implementation
they want, or have been using, and still enjoy what we bring to the
table.


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

Re: [Corelinux-public] BUG REPORT

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

The CoreLinux++ source distribution requires the following environment
exports

$export CORELINUX_HOME=/somebasepath
$export LD_LIBRARY_PATH=$(CORELINUX_HOME)/corelinux/lib:$LD_LIBRARY_PATH

where 'somebasepath' is the directory where you extracted the
distribution to.
Consider adding these settings to your login shell environment.

jebga wrote:
> 
> xevilstar:~# cd /usr/local/lib/corelinux/
> xevilstar:/usr/local/lib/corelinux# ls
> COPYING.DOC  classref/     dirs.tm   index.html   mkbuiltins.mk
> COPYING.LIB  clfaq.html    doc/      makefile     project.inc
> CVS/         develop.html  images/   makefile.tm  project.tm
> README       dirs.inc      include/  master.dxx   src/
> xevilstar:/usr/local/lib/corelinux#
> xevilstar:/usr/local/lib/corelinux# make
> make -C src/classlibs
> make[1]: Entering directory `/usr/local/lib/corelinux/src/classlibs'
> make -C corelinux
> make[2]: Entering directory
> `/usr/local/lib/corelinux/src/classlibs/corelinux'
> makefile:10: /corelinux/mkbuiltins.mk: No such file or directory
> make[2]: *** No rule to make target `/corelinux/mkbuiltins.mk'.  Stop.
> make[2]: Leaving directory
> `/usr/local/lib/corelinux/src/classlibs/corelinux'
> make[1]: *** [every] Error 2
> make[1]: Leaving directory `/usr/local/lib/corelinux/src/classlibs'
> make: *** [every] Error 2
> xevilstar:/usr/local/lib/corelinux#
> 
> ??????????
> please help
> ??????????
> 
> _______________________________________________
> Corelinux-public mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-public

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://www.colconsulting.com
Object Oriented Analysis and Design |Java and C++ Development

[Corelinux-public] BUG REPORT

[jebga <je...@ti...>]

xevilstar:~# cd /usr/local/lib/corelinux/
xevilstar:/usr/local/lib/corelinux# ls
COPYING.DOC  classref/     dirs.tm   index.html   mkbuiltins.mk
COPYING.LIB  clfaq.html    doc/      makefile     project.inc
CVS/         develop.html  images/   makefile.tm  project.tm
README       dirs.inc      include/  master.dxx   src/
xevilstar:/usr/local/lib/corelinux#
xevilstar:/usr/local/lib/corelinux# make
make -C src/classlibs
make[1]: Entering directory `/usr/local/lib/corelinux/src/classlibs'
make -C corelinux
make[2]: Entering directory
`/usr/local/lib/corelinux/src/classlibs/corelinux'
makefile:10: /corelinux/mkbuiltins.mk: No such file or directory
make[2]: *** No rule to make target `/corelinux/mkbuiltins.mk'.  Stop.
make[2]: Leaving directory
`/usr/local/lib/corelinux/src/classlibs/corelinux'
make[1]: *** [every] Error 2
make[1]: Leaving directory `/usr/local/lib/corelinux/src/classlibs'
make: *** [every] Error 2
xevilstar:/usr/local/lib/corelinux#

??????????
please help
??????????

[Corelinux-public] Forum monitoring seems to have been enabled

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

It seems that Source Forge has fixed the monitoring of forums. 

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

[Corelinux-public] ACE

[Stephen B. <arc...@db...>]

This message was sent from Geocrawler.com by "Stephen Blake" <se...@my...>
Be sure to reply to that address.

I have been browsing the archives a bit and noticed that you are talking about threads, etc. I am 
wondering if any of you have heard of ACE. It's a really nice OO networking library that supports 
multithreading, etc. Anyway, it's an opensource project, and it's developed by a great bunch of 
people. In fact I think there are no restrictions at all with how you can use their code. Anyway, 
just thought I would bring it up. They also have a nice Corba Orb called Tao that is built on ACE. 
Here are the url's if you are interested in checking it out. It might be helpful to your project.

http://www.cs.wustl.edu/~schmidt/ACE.html
http://www.cs.wustl.edu/~schmidt/TAO.html

Stephen Blake
se...@my...


Geocrawler.com - The Knowledge Archive

[Corelinux-public] 0.4.6 Released

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

Now that thats in, I'm going to focus on finishing Structural (Flyweight
and Proxy) then bounce back to Creational.

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