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

[Corelinux-develop] Ok, heading for some releases

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

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?

The libcorelinux release will be 0.4.31 yes?


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

Re: [Corelinux-develop] How we doing

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

Christophe Prud'homme wrote:

> Le Samedi 31 Mars 2001 09:15 am, vous avez écrit :
>   > Hey gang,
>   >
>   > I'm getting close to get a working Schema frame, which I can explain if
>   > needed.
>   >
>   > Basically:
>   >
>   > Concept isA Aggregate
>   > Schema isA Concept
>   >
>   > Concept has Properties
>   > Properties isA Collection
>   > the Properties collection contains Attributes
>   >
>   > Attribute isA Aggregate
>   > Attribute has a Name
>   > Attribute has a Value
>   > Name is a CharPtr
>   > Value is a FrameworkEntityPtr
> seems cool 
> sounds the right thing to do
> seems  very logical

The change I made was that now:

Name is now called Key
Key is a FrameworkEntityPtr

> Aargh only 24 hours in a day,
> 
> C.

<grin>

Re: [Corelinux-develop] How we doing

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

Le Samedi 31 Mars 2001 09:15 am, vous avez =E9crit :
  > Hey gang,
  >
  > I'm getting close to get a working Schema frame, which I can explain =
if
  > needed.
  >
  > Basically:
  >
  > Concept isA Aggregate
  > Schema isA Concept
  >
  > Concept has Properties
  > Properties isA Collection
  > the Properties collection contains Attributes
  >
  > Attribute isA Aggregate
  > Attribute has a Name
  > Attribute has a Value
  > Name is a CharPtr
  > Value is a FrameworkEntityPtr
seems cool=20
sounds the right thing to do
seems  very logical


Aargh only 24 hours in a day,

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] PID, sigaction documentation

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

Hans,

There are two major arena for signal, the SysV standard type, and the 
extended signal (where sigaction is defined), re: 
http://www.mcsr.olemiss.edu/cgi-bin/man-cgi?sigaction+2

Also, if you look at the header files in the linux distro of yours.

My problem (and why I used the offset into the buffer), was that the PID 
wasn't where the structure and union declarations said it would be, 
unless I wasn't packing correctly.

Hans Dulimarta wrote:

> Frank,
>    You told me not to use the vInfo formal parameter
> of threadTerminated to get the PID of terminating thread.
> Do you know another way of obtaining this PID?
> 
> I am also trying to use the third formal parameter (vPtr),
> but could not find the right documentation of sigaction
> that explain the use of this parameter in more detail.
> 
> Could you or Christophe give me some direction?
> 

[Corelinux-develop] PID, sigaction documentation

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

Frank,
   You told me not to use the vInfo formal parameter
of threadTerminated to get the PID of terminating thread.
Do you know another way of obtaining this PID?

I am also trying to use the third formal parameter (vPtr),
but could not find the right documentation of sigaction
that explain the use of this parameter in more detail.

Could you or Christophe give me some direction?

-- 
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] Previous message clipped

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

Oops <grin>

Anyway, I am going to be working on getting enough of the Schema and
Concept working so that we can provide the ability to describe a schema
for persist (really, for anything anyone wants but one use will be for
the persist abstraction).

The idea is that the StoreSponser leverages the information realized in
the Schema to plan a storage strategy without the need to user
(application developer) knowledge.

This will require that the application has a schema model built by
someone that is specific to the application domain.

The attributes of the Concepts in a Schema are both generic and can have
Sponser domain information if described by the Sponser provider.

Have you guys gotten your copies of MagicDrawUML to run yet? This would
be much easier to understand from the model.

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

[Corelinux-develop] How we doing

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

Hey gang,

I'm getting close to get a working Schema frame, which I can explain if
needed. 

Basically:

Concept isA Aggregate
Schema isA Concept

Concept has Properties
Properties isA Collection
the Properties collection contains Attributes

Attribute isA Aggregate
Attribute has a Name
Attribute has a Value
Name is a CharPtr
Value is a FrameworkEntityPtr

-- 
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] Thread State Transition Diagram (continued)

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

Hans,

If the user doesn't register specific handlers, the 
ThreadContext::cloneFrameFunction does the state changes.

Hope this helps.

Frank V. Castellucci

Hans Dulimarta wrote:

> 
> I hit the "Sent" button accidentally but my e-mail was not complete.
> So here is the more complete one.
> 
> 1) ThreadContext.hpp declares an enum type ThreadState
> (THREAD_WAITING_TO_START,
> THREAD_STARTING, ...., THREAD_START_FAILED).
> 
> 2) The Thread::get.*Count() routines depend on Thread::theThreadState to
> report
> the correct number of threads in specific state.
> 
> How is the thread state transition diagram looks like? Here is what I
> infered from the existing code:
> 
> When a new thread is created its state is WAITING_TO_START,
> When the thread is started from startThread its state is set to RUNNING
> (this is what added to version 1.17 and checked in as version 1.18).
> May be I should change this to STARTING, instead of RUNNING.
> 
> But then how the transition from STARTING to RUNNING will take place?
> 
> 

[Corelinux-develop] Thread State Transition Diagram (continued)

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

I hit the "Sent" button accidentally but my e-mail was not complete.
So here is the more complete one.

1) ThreadContext.hpp declares an enum type ThreadState
(THREAD_WAITING_TO_START,
THREAD_STARTING, ...., THREAD_START_FAILED).

2) The Thread::get.*Count() routines depend on Thread::theThreadState to
report
the correct number of threads in specific state.

How is the thread state transition diagram looks like? Here is what I
infered from the existing code:

When a new thread is created its state is WAITING_TO_START,
When the thread is started from startThread its state is set to RUNNING
(this is what added to version 1.17 and checked in as version 1.18).
May be I should change this to STARTING, instead of RUNNING.

But then how the transition from STARTING to RUNNING will take place?


-- 
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] Thread State Transition Diagram

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

1) ThreadContext.hpp declares an enum type ThreadState
(THREAD_WAITING_TO_START,
THREAD_STARTING, ...., THREAD_START_FAILED).

2) The Thread::get.*Count() routines depend on Thread::theThreadState to
report
the correct number of threads in specific state.

How is the thread state transition diagram looks like? Here is what I
infered
from the existing code:

When a new thread is created its state is WAITING_TO_START,
When the thread is started from startThread its state is set to RUNNING
(this is what added to version 1.17 and checked in as version 1.18).
-- 
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] Fwd: debian repository on sourceforge

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

oops it is not corelinux-dev but corelinux-develop


----------  Message transmis  ----------
Subject: debian repository on sourceforge
Date: Sun, 25 Mar 2001 16:52:21 -0500
From: Christophe Prud'homme <pru...@us...>
To: cor...@li...
Cc: "CoreLinux Public" <cor...@li...>


for the debian users(sid/unstable more precisely):

you can add these two lines to your /etc/apt/sources.list

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

apt-get source libcorelinux
apt-get install task-corelinux
apt-get install task-corelinux-devel

in the future task-corelinux and task-corelinux-devel will include also
the package clfw and cfll
task-* are metapackages that will install corelinux related packages

Note that these packages are for sid(unstable) and they are error/warning
 free according to lintian!!

[note for Frank: do not remove /home/groups/corelinux/htdocs/debian :) ]

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

-------------------------------------------------------

--=20
| Christophe Prud'homme, http://augustine.mit.edu/~prudhomm
| ICQ UIN: 24560867 Alias: Jesunix
|
| Pierre: Je suis d=E9sol=E9 Th=E9r=E8se, je ne sais pas ce qui m'a pris.=
 C'est une catastrophe.
| Th=E9r=E8se: Ce n'est rien Pierre, je n'ai rien senti....
| -- Le Pere Noel est une ordure

Re: [Corelinux-develop] Re: [Corelinux-clcvs] CVS: clfw/src/libs/Persist .cvsignore,NONE,1.1Makefile.am,NONE,1.1 StoreSponser.cpp,NONE,1.1

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

<sheepish grin>
oops

Hans Dulimarta wrote:

> "Frank V. Castellucci" wrote:
> >
> > Update of /cvsroot/corelinux/clfw/src/libs/Persist
> > In directory usw-pr-cvs1:/tmp/cvs-serv5357/src/libs/Persist
> >
> > Added Files:
> >         .cvsignore Makefile.am StoreSponser.cpp
> > Log Message:
>
> Spelling: StoreSponsor.[h,cpp] ?
>
> --
> Hans Dulimarta, Ph.D. |                dul...@co...
> Research Associate    |     http://www.egr.msu.edu/~dulimart
> P: 517-432-7589       |     http://corelinux.sourceforge.net
> F: 760-281-7691     http://freshmeat.net/projects/snapsource
> Elec. & Comp. Eng., Mich. State Univ.,  E. Lansing, MI 48824
>
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/lists/listinfo/corelinux-develop

[Corelinux-develop] Re: [Corelinux-clcvs] CVS: clfw/src/libs/Persist .cvsignore,NONE,1.1 Makefile.am,NONE,1.1 StoreSponser.cpp,NONE,1.1

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

"Frank V. Castellucci" wrote:
> 
> Update of /cvsroot/corelinux/clfw/src/libs/Persist
> In directory usw-pr-cvs1:/tmp/cvs-serv5357/src/libs/Persist
> 
> Added Files:
>         .cvsignore Makefile.am StoreSponser.cpp
> Log Message:


Spelling: StoreSponsor.[h,cpp] ?


-- 
Hans Dulimarta, Ph.D. |                dul...@co...
Research Associate    |     http://www.egr.msu.edu/~dulimart   
P: 517-432-7589       |     http://corelinux.sourceforge.net
F: 760-281-7691     http://freshmeat.net/projects/snapsource
Elec. & Comp. Eng., Mich. State Univ.,  E. Lansing, MI 48824

Re: [Corelinux-develop] Hmm

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

Hans and Chris,

It is in /home/group/corelinux/proj

Christophe Prud'homme wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Le Samedi 17 Mars 2001 09:40 am, vous avez écrit :
>   > Christophe,
>   >
>   > Maybe the problem with reading the MagicDrawUML model is that the *.mdr
>   > contains path specific information. Perhaps removing that and then
>   > trying to load in 3.6i may work?
> well I removed 3.6i from my box :(
> is it possible to try it again ?
> 
> I had some changes in my plans (conferences ... )
> so I will have a look at the info you sent me for the xml parser
> right now I have a parser provided by qt and a class generator which
> access the xml parser through an interface and generate c++ code on the
> fly.
> I guess that it won't be a problem for me to implement an adaptor to another C
> xml parsing library
> As we already discussed, I think that beign able to generate IDL is also very important
> at least it is important for me. I'll think about that next week
> 
> C.
> - --
> Christophe Prud'homme
> OOA and OOD for Linux
> CoreLinux -- http://corelinux.sourceforge.net
> Finite Element Method Codes
> KFem      -- http://kfem.sourceforge.net
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.4 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iEYEARECAAYFAjqzzOQACgkQoY+0C9S+FFCaIACghUhiewd8dQhYk/alErJTeEgd
> By0An2rQ4ZdNZBRVaAf/RLQfK3Ry1uDR
> =5J7R
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> 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] Whats up?

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

Hans Dulimarta wrote:
> 
> > By the way, if you are going to add priority you may consider the actual
> > Linux call to be wrapped in a static in Environment?
> 
> I also found getpid(), getppid(), and clone() call in
> Thread.cpp.
> Maybe we should move them to Environment?

See below :)

> 
> Is the Enviroment designed to be a "leaf" module as a
> wrapper of
> all the underlying system? If yes, we should not put a call
> to Thread::getKernelError() in
> Environment::setupCommonAccess.

Your right, organize a new static class if you like which covers the
behavior you want, we can also use namespaces to localize the context:

corelinux::Enviornment
corelinux::Enviornment::Process

etc.

-- 
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] Whats up?

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

"Frank V. Castellucci" wrote:
> 
> pthread is a user space thread mechanism. If you are running on a SMP
> machine, the threads that are created using pthread do not take
> advantage of the other processors.
> 
> Lets stick to "clone".
> 

OK.

> 
> Cool. Are you finding it interesting, or is it boring stuff?
> 

Well, I guess it is in between.....the repetitious part is
kind
of boring. The new part, such as trying to understand the
logic of
the existing code, is challenging.

> By the way, if you are going to add priority you may consider the actual
> Linux call to be wrapped in a static in Environment?

I also found getpid(), getppid(), and clone() call in
Thread.cpp.
Maybe we should move them to Environment?

Is the Enviroment designed to be a "leaf" module as a
wrapper of
all the underlying system? If yes, we should not put a call
to Thread::getKernelError() in
Environment::setupCommonAccess.

> 
> >
> > > --
> > > 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://corelinux.sourceforge.net
> > F: 760-281-7691     http://freshmeat.net/projects/snapsource
> > Elec. & Comp. Engg., Mich. State Univ., 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
> 
> _______________________________________________
> 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://corelinux.sourceforge.net
F: 760-281-7691     http://freshmeat.net/projects/snapsource
Elec. & Comp. Engg., Mich. State Univ., E. Lansing, MI 48824

Re: [Corelinux-develop] Hmm

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le Samedi 17 Mars 2001 09:40 am, vous avez =E9crit :
  > Christophe,
  >
  > Maybe the problem with reading the MagicDrawUML model is that the *.m=
dr
  > contains path specific information. Perhaps removing that and then
  > trying to load in 3.6i may work?
well I removed 3.6i from my box :(
is it possible to try it again ?

I had some changes in my plans (conferences ... )
so I will have a look at the info you sent me for the xml parser
right now I have a parser provided by qt and a class generator which=20
access the xml parser through an interface and generate c++ code on the
fly.=20
I guess that it won't be a problem for me to implement an adaptor to anot=
her C
xml parsing library
As we already discussed, I think that beign able to generate IDL is also =
very important
at least it is important for me. I'll think about that next week

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjqzzOQACgkQoY+0C9S+FFCaIACghUhiewd8dQhYk/alErJTeEgd
By0An2rQ4ZdNZBRVaAf/RLQfK3Ry1uDR
=3D5J7R
-----END PGP SIGNATURE-----

[Corelinux-develop] Hmm

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

Christophe,

Maybe the problem with reading the MagicDrawUML model is that the *.mdr
contains path specific information. Perhaps removing that and then
trying to load in 3.6i may work?

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

Re: [Corelinux-develop] Whats up?

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

Hans Dulimarta wrote:
> 
> "Frank V. Castellucci" wrote:
> >
> > Whew, long week. How are we, where we are, are we?
> >
> 
> Here I am... adding lines to the Thread and ThreadContext
> implementation.
> 
> One question come to mind? Why there is no 'pthread_*' call
> at all in Thread and ThreadContext? Not even pthread_create?

pthread is a user space thread mechanism. If you are running on a SMP
machine, the threads that are created using pthread do not take
advantage of the other processors.

Lets stick to "clone".

> >From 24 requirements item in req1588.html, I discovered that
> 12 of them have been implemented.

Cool. Are you finding it interesting, or is it boring stuff?

> I added 2 more implemented requirements: created and blocked
> count.
> 
> Next I'll tackle the priority related. But.... should I use
> pthread_*?

By the way, if you are going to add priority you may consider the actual
Linux call to be wrapped in a static in Environment?


> 
> > --
> > 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://corelinux.sourceforge.net
> F: 760-281-7691     http://freshmeat.net/projects/snapsource
> Elec. & Comp. Engg., Mich. State Univ., 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

Re: [Corelinux-develop] Whats up?

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

"Frank V. Castellucci" wrote:
> 
> Whew, long week. How are we, where we are, are we?
> 

Here I am... adding lines to the Thread and ThreadContext
implementation.

One question come to mind? Why there is no 'pthread_*' call
at all in Thread and ThreadContext? Not even pthread_create?

From 24 requirements item in req1588.html, I discovered that
12 of them have been implemented.

I added 2 more implemented requirements: created and blocked
count.

Next I'll tackle the priority related. But.... should I use
pthread_*?

> --
> 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://corelinux.sourceforge.net
F: 760-281-7691     http://freshmeat.net/projects/snapsource
Elec. & Comp. Engg., Mich. State Univ., E. Lansing, MI 48824

[Corelinux-develop] Whats up?

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

Whew, long week. How are we, where we are, are we?

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

Re: [Corelinux-develop] Documentation

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

Can your configuration to a message to me? I have 384 Mb real so if it 
is upper limits it shouldn't matter.

FC

Christophe Prud'homme wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Thursday 01 March 2001 07:49, you wrote:
> 
>> Christophe,
>> 
>> Do you think the problem I am having with building the documentation is
>> inclusion of a package? (The ones declared at the top of the *.tex
>> files)
> 
> Nope I don't think so
> the problem is that you can configure the TeX engine memory requirements
> usually it is setup for middle size document without too much stuff like commands, figures ...
> now with doxygen the Tex can become real big with macros, commands ...
> and then your TeX config is not enough
> for my thesis (200 Mo as a ps file and advanced TeX use :)) I had to tune my TeX installation
> otherwise I couldn't compile 
> 
> the TeX memory is in fact a set of differents upper memory limits for tables (commands table, math ...)
> 
> 
> C.
> - -- 
> | Christophe Prud'homme, http://augustine.mit.edu/~prudhomm
> | ICQ UIN: 24560867 Alias: Jesunix
> |
> | As flies to wanton boys are we to the gods; they kill us for their sport.
> | -- Shakespeare, "King Lear"
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.4 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iEYEARECAAYFAjqf+MoACgkQoY+0C9S+FFALIgCeIOLYx/gfyhz+CRWlHqxQCoJA
> /E8AnjgMaW/BGh51WDSGS6+ebMJBbjNI
> =iNCS
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/lists/listinfo/corelinux-develop
> 
> 
> 

Re: [Corelinux-develop] Documentation

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 01 March 2001 07:49, you wrote:
> Christophe,
>
> Do you think the problem I am having with building the documentation is
> inclusion of a package? (The ones declared at the top of the *.tex
> files)
Nope I don't think so
the problem is that you can configure the TeX engine memory requirements
usually it is setup for middle size document without too much stuff like =
commands, figures ...
now with doxygen the Tex can become real big with macros, commands ...
and then your TeX config is not enough
for my thesis (200 Mo as a ps file and advanced TeX use :)) I had to tune=
 my TeX installation
otherwise I couldn't compile=20

the TeX memory is in fact a set of differents upper memory limits for tab=
les (commands table, math ...)


C.
- --=20
| Christophe Prud'homme, http://augustine.mit.edu/~prudhomm
| ICQ UIN: 24560867 Alias: Jesunix
|
| As flies to wanton boys are we to the gods; they kill us for their spor=
t.
| -- Shakespeare, "King Lear"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjqf+MoACgkQoY+0C9S+FFALIgCeIOLYx/gfyhz+CRWlHqxQCoJA
/E8AnjgMaW/BGh51WDSGS6+ebMJBbjNI
=3DiNCS
-----END PGP SIGNATURE-----

Re: [Corelinux-develop] RDF Parser in 'C' for C

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

You are a GOD!

Christophe Prud'homme wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Thursday 01 March 2001 15:02, you wrote:
> 
>> C.,
>> 
>> http://www.w3.org/Library/
>> 
>> has the libwww which contains a RDF parser if you are still looking
>> around.
> 
> yeah thanks I'll look into that
> the thing is that as of now the class generator is somewhat is decoupled from the parser
> so I should be able to use/plug another parser easily :)
> 
> 
> 
> 
> thanks
> C.
> - -- 
> | Christophe Prud'homme, http://augustine.mit.edu/~prudhomm
> | ICQ UIN: 24560867 Alias: Jesunix
> |
> | Its name is Public Opinion.  It is held in reverence.  It settles everything.
> | Some think it is the voice of God.
> | -- Mark Twain
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.4 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iEYEARECAAYFAjqerIkACgkQoY+0C9S+FFB54ACggmLEY4yl37/lmzKCRanqCpws
> pSEAn0wT+T9h8ETy8pfYZjdd0X5Elm+T
> =PQEu
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/lists/listinfo/corelinux-develop
> 
> 
> 

Re: [Corelinux-develop] RDF Parser in 'C' for C

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 01 March 2001 15:02, you wrote:
> C.,
>
> http://www.w3.org/Library/
>
> has the libwww which contains a RDF parser if you are still looking
> around.
yeah thanks I'll look into that
the thing is that as of now the class generator is somewhat is decoupled =
from the parser
so I should be able to use/plug another parser easily :)




thanks
C.
- --=20
| Christophe Prud'homme, http://augustine.mit.edu/~prudhomm
| ICQ UIN: 24560867 Alias: Jesunix
|
| Its name is Public Opinion.  It is held in reverence.  It settles every=
thing.
| Some think it is the voice of God.
| -- Mark Twain
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjqerIkACgkQoY+0C9S+FFB54ACggmLEY4yl37/lmzKCRanqCpws
pSEAn0wT+T9h8ETy8pfYZjdd0X5Elm+T
=3DPQEu
-----END PGP SIGNATURE-----