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

Re: [Corelinux-develop] I'm back

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

Welcome back!

Christophe Prud'homme wrote:
> 
> Hie,
> 
> I'll make the deb ASAP.
> I'll also update the web site html reference doc
> 
> do I need to generate the rpm-doc ?
> C.
> --

Thats up to you.

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

[Corelinux-develop] I'm back

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

Hie,

I'll make the deb ASAP.
I'll also update the web site html reference doc

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

[Corelinux-develop] CoreLinux++ 0.4.29 Released

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

Mainly released with fixes to compile on gcc 2.97

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

[Corelinux-develop] libclfw++ 0.2.0 Released

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

Today, the next step in creating a great frameworks library has been
introduced: libclfw++ 0.2.0.

While not extensive change, the very important MetaType has been added,
along with declaration and definition macros. There are two (2) types
that have also added: FrameworkEntity and Number, which metaclasses are
defined as MetaTypeRoot and MetaTypeNumber respectivley.

A small testdriver has been added as well.

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

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

Hans - Dulimarta wrote:
> 
> On Tue, 3 Oct 2000, Frank V. Castellucci wrote:
> 
> > Date: Tue, 03 Oct 2000 22:23:04 -0400
> > From: Frank V. Castellucci <fr...@co...>
> > Reply-To: cor...@li...
> > To: CoreLinux Development <cor...@li...>
> > Subject: [Corelinux-develop] Checkpoint
> >
> > Hans,
> >
> > Any epiphany on the loop issue? Throw some thoughts out if you want, I'm
> > here to bounce them around. Christophe too!
> 
> Sorry guys, these days I was busy preparing a demo/presentation for our
> microrobot project this middle October. I'll see what I can do in the
> middle of my "spare" time.

Hey, no need to apologize! I think all of us are doing this in the open
source, open development, collaborative spirit. When ever you get back
into the swing, give a yell. In the meantime, someone may come up with a
solution and you are welcome to contribute in anyother area.

You have been a terrific help with what you have already done and I, for
one, greatly appreciate it and given the number of downloads with each
release I am sure there are others you have helped as well.

> 
> >
> > Maybe we should look at system queues or pipes with the select blocking
> > capability?
> >
> >
> 
> --
> Hans Dulimarta, Ph.D.                  dul...@co...
> P: 517-432-7589             http://www.egr.msu.edu/~dulimart
> F: 760-281-7691             http://corelinux.sourceforge.net
> Elec. & Comp. Engg., Mich. State Univ., E. Lansing, MI 48824
> 
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-develop

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

Re: [Corelinux-develop] Checkpoint

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

On Tue, 3 Oct 2000, Frank V. Castellucci wrote:

> Date: Tue, 03 Oct 2000 22:23:04 -0400
> From: Frank V. Castellucci <fr...@co...>
> Reply-To: cor...@li...
> To: CoreLinux Development <cor...@li...>
> Subject: [Corelinux-develop] Checkpoint
> 
> Hans,
> 
> Any epiphany on the loop issue? Throw some thoughts out if you want, I'm
> here to bounce them around. Christophe too!

Sorry guys, these days I was busy preparing a demo/presentation for our
microrobot project this middle October. I'll see what I can do in the
middle of my "spare" time.

> 
> Maybe we should look at system queues or pipes with the select blocking
> capability?
> 
> 

-- 
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] MetaType work

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

Ok,

Now that we can appreciate that a MetaType is a metaclass of a Type,
where the intent is to describe the Type class. This is the fundemental
information neccessary to build ontologies.

So I have stuck my foot in deeper by added a new type : Number! Which,
as you would imagine, defines the metatype MetaTypeNumber!

(and example one starts to show off the difference between the class
types and the metaclass types)

Anyway, now comes the fun/hard/fun stuff!

If a MetaType is a definition of the Type (class xxx), we need to start
adding MetaAttributes which define aspects of the Type so we can really
get into reasoning in a big way. For example:

Some crazy mathematics guy (Herbrand) stated that the domain of
RealNumbers is the set of all real numbers from -infinitity to infinity.
This can be called the Herbrand Domain of RealNumbers. (Yes, break out
the first predicate logic books!)

From this we can then reason (assert) that, say, 5.0 is an instance of
the member of the Hebrand Domain of Reals set.

Obviously, for software to reason in the blind (say, given a
FrameworkEntityPtr) how can it ascertain properties of the type? For
example, we now know we can ask the object if it is type of Number via

aPtr->getType()->isTypeOf(Number::getTypeDescriptor())

but once we know that, what else must we ask to do useful things? 

While I will leave the Phds in this group (everyone but me) to fill in
the properties of a number (and ones that are specializations like
integer, short integer, unsigned long integer, etc.), suffice it to say
that the next step is capturing that information somehow.

A property captures the information of a types attribute. But be
careful, we need two kinds of attributes:

Class attributes: this captures information neccessary for marshalling
content in and out of a class instance (like a string, or other object
instance).

MetaType Attribute : these are defining properties that enable
reasoning.

So the meta-model (MetaTypes and defining MetaAttributes) make up the
type ontologies, or type network graphs.

Thoughts? I'm kinda rambling here because it is very late, sorry. Please
ask questions or make corrections to my high school level understanding
of the world. <grin>

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

[Corelinux-develop] Checkpoint

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

Hans,

Any epiphany on the loop issue? Throw some thoughts out if you want, I'm
here to bounce them around. Christophe too!

Maybe we should look at system queues or pipes with the select blocking
capability?

-- 
Frank V. Castellucci

Re: [Corelinux-develop] MetaType

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

While I am playing with MetaType
I add the documentation for doxygen 
especially the macro definitions
so you don't need to bother about that

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

Re: [Corelinux-develop] MetaType

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

wow that's pretty cool

1-one comment:
why do you use
extern "C" { 
#include "stdio.h" or "stdlib.h"
}

when #include "cstdlib" or "cstdio" are yor friends?
it is standard whereas the above might cause you problems

I am still playing around with the metatype framework :)

C.

-- 
  Christophe Prud'homme                 |
  MIT, 77, Mass Ave, Rm 3-243           |   A wise person makes his own
  Cambridge MA 02139                    |   decisions,
  Tel (Office) : (00 1) (617) 253 0229  |   a weak one obeys public opinion.
  Fax (Office) : (00 1) (617) 258 8559  |   -- Chinese proverb
  http://augustine.mit.edu/~prudhomm    |
                          Following the hacker spirit

[Corelinux-develop] cvs update -dP

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

ok I update clfw and I play with this baby

-- 
  Christophe Prud'homme                  |
  MIT, 77, Mass Ave, Rm 3-243            |   As flies to wanton boys are we
  Cambridge MA 02139                     |   to the gods; they kill us for
  Tel (Office) : (00 1) (617) 253 0229   |   their sport.
  Fax (Office) : (00 1) (617) 258 8559   |   -- Shakespeare, "King Lear"
  http://augustine.mit.edu/~prudhomm     |
                          Following the hacker spirit

Re: [Corelinux-develop] MetaType

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

Well, a nice working scaffolding is in. 

"Frank V. Castellucci" wrote:
> 
> I'm almost at the point with a working metatype. It is small but
> adequate to build upon.
> 
> Christophe,
> Hang in there!
> 
> As you guys saw, I was trying to consolidate to achieve a quick turnover
> of Library Load extendability. No response, so I took today off from
> work to jam this puppy without loosing the essence of what I wanted for
> the frameworks.
> 
> --
> Frank V. Castellucci
> http://corelinux.sourceforge.net
> OOA/OOD/C++ Standards and Guidelines for Linux
> http://PythPat.sourceforge.net
> Pythons Pattern Package
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-develop

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

[Corelinux-develop] MetaType

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

I'm almost at the point with a working metatype. It is small but
adequate to build upon.

Christophe,
Hang in there!

As you guys saw, I was trying to consolidate to achieve a quick turnover
of Library Load extendability. No response, so I took today off from
work to jam this puppy without loosing the essence of what I wanted for
the frameworks.

-- 
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] apps using corelinux

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

Hans Dulimarta wrote:
> 
> Christophe Prud'homme wrote:
> >
> > 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" :)
> >
> 
> Agree.

That makes three!

> 
> > 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
> > _______________________________________________
> > Corelinux-develop mailing list
> > Cor...@li...
> > http://lists.sourceforge.net/mailman/listinfo/corelinux-develop
> 
> --
> Hans Dulimarta, Ph.D.                  dul...@co...
> P: 517-432-7589
> http://www.egr.msu.edu/~dulimart
> F: 760-281-7691             http://corelinux.sourceforge.net
> Elec. & Comp. Engg., Mich. State Univ., E. Lansing, MI 48824
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-develop

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

Re: [Corelinux-develop] default library loader and library instance

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

Christophe,

This is basically the idea (that your macro has) only with a bit more
information reflection details.

In the short term, class MetaType is also a factory for type instances
(which enables any kind of memory management one would desire to
override). So, take Integer for example:

{
	IntegerPtr	aInt = Integer::getMetaType()->create();
	*aInt = 78;
	Integer::getMetaType()->destroy(aInt);
}

In the longer term, we need to support things like attributes so that
Persistence can get and set data to and from the data 
stores.

Also, the Ontology will allow you to traverse the hierarchy of MetaTypes
to instantiate types that you want. So when, for example, the Function
Library Loader needs to execute something from a shared library, it can
reason with the ontology for the appropriate return types, instantiate
one for the return, and viola!

Of course it is more involved. Did you see the NIHCL object.hpp I sent
you? That is the long term goal (in general functionality, not the way
it looked.)

From that point, we can add utilities which scan a ELF *.so file and
generate all the ExecutionObjectDefinitions automagically (even at run
time if we implement it so).

Generally, I was going to do most of the work with macro expansions.

This week you will see the fruits of labor start to appear.

I am working on the neccessary
Christophe Prud'homme wrote:
> 
> > Yes, but what of the type information? This was the purpose of the meta
> > class, and more importantly, the Library Load abstraction. Work with me
> > on the metaclass, it will be a much more rewarding and flexible
> > framework.
> what would you want me to do ?
> what about inheritance?
> in mt simple metaclass stuff I propagate the information through a macro
> if I want to have this feature for a derived class (ths parent class must
> have it of course)
> 
> I add something like that to the class Class
> 
> Macro(Class, Parent class);
> 
> then I have things like
> - getClassName()
> - isTypeOf()
> - isA()
> 
> where Macro is defined like this
> 
> #define Macro(thisClass,superclass) \
> virtual const char *getClassName() const {return #thisClass;};\
> static bool isTypeOf(const char *type) \
> { \
>   if ( !strcmp(#thisClass,type) ) \
>     { \
>     return 1; \
>     } \
>   return superclass::isTypeOf(type); \
> } \
> virtual bool isA(const char *type) \
> { \
>   return this->thisClass::isTypeOf(type); \
> }
> 
> as you can see what I did is simple but was ok for what I want.
> 
> what do you plan to do about this?
> this==inheritance
> 
> 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
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-develop

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

Re: [Corelinux-develop] apps using corelinux

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

Christophe Prud'homme wrote:
> 
> 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" :)
> 

Agree.

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

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

> It is included on most all Linux. We need to add the test for it
> (although I think it may be there by default) in the configure.in
> script.
it comes with libtool actually

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

Re: [Corelinux-develop] default library loader and library instance

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

> Yes, but what of the type information? This was the purpose of the meta
> class, and more importantly, the Library Load abstraction. Work with me
> on the metaclass, it will be a much more rewarding and flexible
> framework.
what would you want me to do ?
what about inheritance? 
in mt simple metaclass stuff I propagate the information through a macro
if I want to have this feature for a derived class (ths parent class must 
have it of course)


I add something like that to the class Class

Macro(Class, Parent class);

then I have things like
- getClassName()
- isTypeOf()
- isA()

where Macro is defined like this

#define Macro(thisClass,superclass) \
virtual const char *getClassName() const {return #thisClass;};\
static bool isTypeOf(const char *type) \
{ \
  if ( !strcmp(#thisClass,type) ) \
    { \
    return 1; \
    } \
  return superclass::isTypeOf(type); \
} \
virtual bool isA(const char *type) \
{ \
  return this->thisClass::isTypeOf(type); \
}

as you can see what I did is simple but was ok for what I want.

what do you plan to do about this?
this==inheritance


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

[Corelinux-develop] Re: [Somelib] Greetings

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

"John A. Palmieri" wrote:
> 
> Hi Frank,
> 
> I started SOMELib.  Right now I play a minor role in the development
> though I keep an eye on design and such and put in my $.02 now and
> again.  Thomas does the bulk of the development right now.  When you
> talk about having knowledge that goes "way back to SOM"  are you talking
> about my original releases of SOMlib(simple object model) or IBM's
> SOM(system object model)?  

System Object Model

> I had changed the name to SOMELib to avoid
> confusion.  Ours is a simple inprocess object model for extending
> dynamic object loading on Linux and now Windows systems.  The new
> codebase is completely rewritten and is currently in its alpha stage.
> It in fact does not even have Makefiles for Linux yet.
> 
> SOMELib is meant to be a simple library with not much higher level
> functionality and almost no dependencies other than standard
> components.  In other words a person can drop in SOMELib and use it just
> as if they were using c's dynamic loading facilities (at bit more
> complex than that but you get the idea).  Theoretically you should be
> able to create a CoreLinux++ loadable object that has the ability to
> load SOMELib objects very easily and with little overhead.
> 
> As for collaboration on a standard for metaclasses/metatype classes for
> reflection/introspection.  I think this would be great.  Having a
> standard for such a task would alleviate the pains of developers and
> would allow people to chose what implementation they wish to use.  For
> crossplatformability alacart SOMELib and for full linux standards with
> many backup classes CoreLinux++.  So it sounds like fun.  Is there a
> mailing list setup for this yet?
> 
> Our main concern with SOMELib is to not sacrifice simplicity and as long
> as this does not I am all for it.
> 
> -Quinticent
> 
> SOMELib
> http://sourceforge.net/projects/somelib/
> C++ object loading
> 
> The Snaglepuss Project
> http://sourceforge.net/projects/snaglepuss/
> Multimedia development engine

Yes, I can understand that, and as CoreLinux++ is not targeted to other
platforms, it makes sense.

Well, if anyone wants to throw in their $0.02 we have a
corelinux-develop mailing list. There is some information in the archive
concerning meta-types.

There is also the (in progress) MetaClass functional requirement:

http://corelinux.sourceforge.net/doc/requirements/req10658.php

and the Library Load abstraction design (although a Function Library
Load theoretical specialization is shown as well):

http://corelinux.sourceforge.net/doc/design/4865.php

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

> 
> "Frank V. Castellucci" wrote:
> >
> > I am the project admin for CoreLinux++. I have experience in declarative
> > object modeling, knowledge representation, meta-models, and way back to
> > SOM.
> >
> > Our objectives were to create a core library (90% complete) and then
> > develop common framework abstractions (libclfw++) which we have just
> > begun.
> >
> > For example, we have already put in the Library Load abstraction with
> > the intent to construct specialized derivations (such as Function
> > Library Load, Image Library Load, etc.). It was obvious that the
> > metaclass/metatype objects would be very useful in this and many other
> > framework plans for reflection, reasoning, and reification.
> >
> > So my reason for posting to this list is to see if there is any interest
> > in joining forces in CoreLinux++ with the intent to extend
> > metaclass/metatype/meta-attribute paradigm to further specialize the
> > libraries.
> >
> > This has immediate applications in our plans for Persistence, Class
> > Loading, Toolbox function reasoning, and type ontology management.
> >
> > Looking forward to your response.
> >
> > --
> > Frank V. Castellucci
> > http://corelinux.sourceforge.net
> > OOA/OOD/C++ Standards and Guidelines for Linux
> > _______________________________________________
> > somelib-devel mailing list
> > som...@li...
> > http://lists.sourceforge.net/mailman/listinfo/somelib-devel
> _______________________________________________
> somelib-devel mailing list
> som...@li...
> http://lists.sourceforge.net/mailman/listinfo/somelib-devel

[Corelinux-develop] Greetings

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

I am the project admin for CoreLinux++. I have experience in declarative
object modeling, knowledge representation, meta-models, and way back to
SOM.

Our objectives were to create a core library (90% complete) and then
develop common framework abstractions (libclfw++) which we have just
begun.

For example, we have already put in the Library Load abstraction with
the intent to construct specialized derivations (such as Function
Library Load, Image Library Load, etc.). It was obvious that the
metaclass/metatype objects would be very useful in this and many other
framework plans for reflection, reasoning, and reification.

So my reason for posting to this list is to see if there is any interest
in joining forces in CoreLinux++ with the intent to extend
metaclass/metatype/meta-attribute paradigm to further specialize the
libraries.

This has immediate applications in our plans for Persistence, Class
Loading, Toolbox function reasoning, and type ontology management.

Looking forward to your response.

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

[Corelinux-develop] [Fwd: [ 105997 ] Project access to CVS project CVSROOT]

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

So, maybe like debian support on the compile farm? :)

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

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

Christophe Prud'homme wrote:
> 
> libtool comes with a small library ltdl (libtool dynamic linker) which helps
> library loading.
> should we include it in corelinux if we follow libtool to do library loading?

It is included on most all Linux. We need to add the test for it
(although I think it may be there by default) in the configure.in
script. 

-- 
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] default library loader and library instance

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

Christophe Prud'homme wrote:
> 
> I think that we should rely on libtool for the default implementation.
> 
> I mean that the library to be loaded may have the following
> name "plugin" and the real name(built internally) is "libplugin.la" which
> is a file generated by libtool. this file contains informations about
> dependencies.
> 
> Loading a .so is ok but the dependencies won't be met automatically so you
> have to do it "by hand" which is boring and ugly.
> 
> >From my experience of loading c++ libraries, you provide a c function with
> "C" external linking:
> the developper of the library "plugin" has to provide something like
> 
> extern "C" {
>   void* init_plugin()
>   {
>     return new plugin;
>   }
> }
> 
> Moreover what about library destruction?
> what if the library loader is destroyed while some libraries are still loaded?
> will we use some kind of reference counting to keep track of the libraries
> which are loaded
>  - +1 when the library sends a message that the object has been created
> successfully
>  - -1 if destroyed
> that is we should implement some kind of event notification system
> (mediator/observer?)
> 
> thoughts?

The ld takes care of reference counting.

> 
> As you may have noticed, I am willing to do the default library
> implementation :). I would like to have it working as quickly as possible.

Yes, but what of the type information? This was the purpose of the meta
class, and more importantly, the Library Load abstraction. Work with me
on the metaclass, it will be a much more rewarding and flexible
framework.


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

[Corelinux-develop] ltdl

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

libtool comes with a small library ltdl (libtool dynamic linker) which helps
library loading.
should we include it in corelinux if we follow libtool to do library loading?

C.

-- 
  Christophe Prud'homme                 |  Its name is Public Opinion.
  MIT, 77, Mass Ave, Rm 3-243           |  It is held in reverence.
  Cambridge MA 02139                    |  It settles everything.
  Tel (Office) : (00 1) (617) 253 0229  |  Some think it is the voice of God.
  Fax (Office) : (00 1) (617) 258 8559  |  -- Mark Twain
  http://augustine.mit.edu/~prudhomm    |
                          Following the hacker spirit

[Corelinux-develop] default library loader and library instance

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

I think that we should rely on libtool for the default implementation.

I mean that the library to be loaded may have the following
name "plugin" and the real name(built internally) is "libplugin.la" which 
is a file generated by libtool. this file contains informations about 
dependencies. 

Loading a .so is ok but the dependencies won't be met automatically so you 
have to do it "by hand" which is boring and ugly.

From my experience of loading c++ libraries, you provide a c function with 
"C" external linking:
the developper of the library "plugin" has to provide something like

extern "C" {
  void* init_plugin()
  {
    return new plugin;
  }
}

Moreover what about library destruction?
what if the library loader is destroyed while some libraries are still loaded?
will we use some kind of reference counting to keep track of the libraries 
which are loaded
 - +1 when the library sends a message that the object has been created  
successfully
 - -1 if destroyed
that is we should implement some kind of event notification system
(mediator/observer?)

thoughts?

As you may have noticed, I am willing to do the default library 
implementation :). I would like to have it working as quickly as possible.



regards
C.
-- 
  Christophe Prud'homme                 |
  MIT, 77, Mass Ave, Rm 3-243           |  The first thing we do, let's kill
  Cambridge MA 02139                    |  all the lawyers.
  Tel (Office) : (00 1) (617) 253 0229  |  -- Wm. Shakespeare,
  Fax (Office) : (00 1) (617) 258 8559  |  "Henry VI", Part IV
  http://augustine.mit.edu/~prudhomm    |
                          Following the hacker spirit