pclasses-devel

[pclasses-devel] P::Classes experimental code

[Christian P. <cp...@se...>]

Hi !

Today i've imported the experimental P::Classes source tree which should 
become version 2.0. The code is available from sourceforge CVS in the 
'pclasses2' module.

The source tree has been completly reorganized:

- Seperate include dirs for the various P libraries
- System abstraction has been split-off from the core library

The goal is to make P::Classes more consistent, more lightweight and more 
powerfull:

- Add containers
- Use smaller libraries (split-off XML stuff, Network Protocol 
implementations, ...)
- Implement Asynchronous I/O
- Add toolkit-independent, plugin-based GUI infrastructure
- Cleanup and finalize Network Transparent I/O (IOManager, MimeTypes, ...)

Things im currently on:

- Transition of the System abstraction library.
- Make Unicode String class ready to use.
- SerialDevice class
- NamedPipe, NamedPipeServer class

There is not much in the tree right now. Old features should be transitioned 
from the pclasses CVS.

Everyone is welcome to hack around.



Greetings and Merry Christmas, 

Christian

Re: [pclasses-devel] P::Classes experimental code

[stephan b. <st...@s1...>]

On Wednesday 22 December 2004 19:39, Christian Prochnow wrote:
> Things im currently on:
>
> - Transition of the System abstraction library.
> - Make Unicode String class ready to use.
> - SerialDevice class
> - NamedPipe, NamedPipeServer class

If i may add to that, things i will work on over the next 4 days:

- Implement a couple patches i made on the 1.x CVS tree. A fix for URL 
and mysql driver.

- Add Request::read( string &, size_t ). Doh - Request isn't ported to 
pclasses2 yet.

- Port some utility functions out of ps11n into P, like 
iomanager_read(string url), which reads in input from any 
IOManager-supported type.

- Maybe port the build tree to toc (the tools s11n uses). This depends 
on Christian's decision.

- Add a new shell-app module:
  - add argv handling.
  - add command dispatcher
  - add eshell's argv type ('arguments').


> There is not much in the tree right now. Old features should be
> transitioned from the pclasses CVS.

Please let me know as you start to work on moving parts over, so i don't 
duplicate any there. As i need classes i will start porting them to the 
new conventions, as needed. i will avoid any of the code you mention 
above.

> Everyone is welcome to hack around.

Thanks again! :)

Something Christian didn't mention: subscribe to pclasses-cvs to get the 
CVS commits via email.

Happy hacking!

-- 
----- st...@s1...   http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts

Re: [pclasses-devel] P::Classes experimental code

[Christian P. <cp...@se...>]

Am Mittwoch 22 Dezember 2004 19:45 schrieb stephan beal:
> On Wednesday 22 December 2004 19:39, Christian Prochnow wrote:
> > Things im currently on:
> >
> > - Transition of the System abstraction library.
> > - Make Unicode String class ready to use.
> > - SerialDevice class
> > - NamedPipe, NamedPipeServer class
>
> If i may add to that, things i will work on over the next 4 days:
>
> - Implement a couple patches i made on the 1.x CVS tree. A fix for URL
> and mysql driver.

Place URL in Net/.  SQL stuff isn't ported yet and needs major rework.
However .. i think the String class must be done before starting with the URL 
class. What about support for internationalization in the URL class (don't 
remember the correct name)?

> - Add Request::read( string &, size_t ). Doh - Request isn't ported to
> pclasses2 yet.

We first need a Plugin library. Since Plugin loading is not a core component, 
and isn't a System abstraction class either it should go into it's own P 
library. Stephan .. how about your excellent class_loder stuff ? 
Shall i integrate it into P and drop the old Plugin stuff ? your code is much 
more elegant and cleaner.

> - Port some utility functions out of ps11n into P, like
> iomanager_read(string url), which reads in input from any
> IOManager-supported type.

Should go into P::IO library.

> - Maybe port the build tree to toc (the tools s11n uses). This depends
> on Christian's decision.
>
> - Add a new shell-app module:
>   - add argv handling.
>   - add command dispatcher
>   - add eshell's argv type ('arguments').

Hmm .. should this go into Util/ or shall we add a "application support" 
library ?
For example SimpleApp should go into "application support" lib, i think argv 
handling as well. 
If argv handling is "generic" and doesn't rely on input from "main(int, 
char*[])" it should go into Util/.

> > There is not much in the tree right now. Old features should be
> > transitioned from the pclasses CVS.
>
> Please let me know as you start to work on moving parts over, so i don't
> duplicate any there. As i need classes i will start porting them to the
> new conventions, as needed. i will avoid any of the code you mention
> above.
>
> > Everyone is welcome to hack around.
>
> Thanks again! :)
>
> Something Christian didn't mention: subscribe to pclasses-cvs to get the
> CVS commits via email.
>
> Happy hacking!

Seems that this Christmas becomes a funny hacking session ...

Re: [pclasses-devel] P::Classes experimental code

[stephan b. <st...@s1...>]

On Wednesday 22 December 2004 20:05, Christian Prochnow wrote:
> Place URL in Net/.  

Will do.

> SQL stuff isn't ported yet and needs major 
> rework. However .. i think the String class must be done before
> starting with the URL class. 

Will the string support implicit conversion from (char *) or 
std::string? If not, i would prefer to see URL based off of 
std::string. If there's an implicit conversion, i see no problem with 
basing URL off of it.

> What about support for 
> internationalization in the URL class (don't remember the correct
> name)?

i know very little about i18n, so i can't say much about it.


> > - Add Request::read( string &, size_t ). Doh - Request isn't ported
> > to pclasses2 yet.
>
> We first need a Plugin library. Since Plugin loading is not a core
> component, and isn't a System abstraction class either it should go
> into it's own P library. Stephan .. how about your excellent
> class_loder stuff ? Shall i integrate it into P and drop the old
> Plugin stuff ? your code is much more elegant and cleaner.

*blush*. Actually, earlier today i was thinking about how horrible one 
of the classloader's "features" is, and want to rewrite it. i like the 
cllite interface a lot, though, and i get TONS of usage out of it. That 
said, i will be more than happy to add a classloading layer to P. i'd 
be honored, in fact, to be allowed to port my code into the tree :).

> > - Port some utility functions out of ps11n into P, like
> > iomanager_read(string url), which reads in input from any
> > IOManager-supported type.
>
> Should go into P::IO library.

Agreed. i will generally follow the policy of "put it wherever it'd deps 
say it should." If new dependencies would be introduced i will first 
ask for your approval.

> > - Maybe port the build tree to toc (the tools s11n uses). This
> > depends on Christian's decision.
> >
> > - Add a new shell-app module:
> >   - add argv handling.
> >   - add command dispatcher
> >   - add eshell's argv type ('arguments').
>
> Hmm .. should this go into Util/ or shall we add a "application
> support" library ?

i think argv belongs in the Util section, and the rest as a standalone 
module or plugin, but i'm not sure what the plugin abstraction might 
look like yet.

> For example SimpleApp should go into "application support" lib, i
> think argv handling as well.

That'd work, too. That makes more sense, actually.

> If argv handling is "generic" and doesn't rely on input from
> "main(int, char*[])" it should go into Util/.

The argv PARSER does not strictly rely on main(), but is not much use 
without it. The argv TYPE is 100% independent. The argv TYPE is simpy a 
sequence container of args with some features to ease it's use as an 
argc/argv replacements. The features like $var/alias expansion depend 
on the app layer (Environment and Aliases objects), so the argv list 
probably belongs there as well.

That's a long way of saying: the ArgvParser class belongs in util, the 
Arguments (Argv?) class belongs in the app utils.

> Seems that this Christmas becomes a funny hacking session ...

That's how i usually spend them. :)


-- 
----- st...@s1...   http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts

Re: [pclasses-devel] P::Classes experimental code

[Marc D. <bdu...@gm...>]

Hello,
I still want to look at P::Prefs and some containers. Specially the first one 
may benefit from s11n.
There is also PSI (device stuff like pci, usb, cdrom, serialdev etc) which may 
be included if we get around to implement the other platforms than 
Linux/posix. I have looked briefly at freebsd.

Marc


On Wednesday 22 Dec 2004 19:45, stephan beal wrote:
> On Wednesday 22 December 2004 19:39, Christian Prochnow wrote:
> > Things im currently on:
> >
> > - Transition of the System abstraction library.
> > - Make Unicode String class ready to use.
> > - SerialDevice class
> > - NamedPipe, NamedPipeServer class
>
> If i may add to that, things i will work on over the next 4 days:
>
> - Implement a couple patches i made on the 1.x CVS tree. A fix for URL
> and mysql driver.
>
> - Add Request::read( string &, size_t ). Doh - Request isn't ported to
> pclasses2 yet.
>
> - Port some utility functions out of ps11n into P, like
> iomanager_read(string url), which reads in input from any
> IOManager-supported type.
>
> - Maybe port the build tree to toc (the tools s11n uses). This depends
> on Christian's decision.
>
> - Add a new shell-app module:
>   - add argv handling.
>   - add command dispatcher
>   - add eshell's argv type ('arguments').
>
> > There is not much in the tree right now. Old features should be
> > transitioned from the pclasses CVS.
>
> Please let me know as you start to work on moving parts over, so i don't
> duplicate any there. As i need classes i will start porting them to the
> new conventions, as needed. i will avoid any of the code you mention
> above.
>
> > Everyone is welcome to hack around.
>
> Thanks again! :)
>
> Something Christian didn't mention: subscribe to pclasses-cvs to get the
> CVS commits via email.
>
> Happy hacking!