pclasses-devel

[pclasses-devel] some ideas for expanding P

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

Random thoughts:

- Add a more abstract process layer, such that we can do something like 
this:
  Process proc("http://...");
  proc.addArg( "foo=bar" );
  ...
  proc.start(...); // some flags might not be possible/appropriate
  ProcessIO * io = proc.processIO();

Maybe that already works? If so, please point me in the proper 
direction.


- Add support similar to s11n's acme::argv_parser class. This allows all 
client apps to read the args passed in to main(), but unfortunately 
requires that main() call either p_init( argc, argv ) or 
acme::argv_parser::args(argc,argv). Clients later call 
acme::argv_parser::args() to get the args. This is used in s11n by 
DLLs, so that they can plug in help options to a client's --help 
options. (See http://s11n.net/s11nconvert/ and grep for mysql-db, 
for an example.)
The exact args parser used is unimportant to me, but having access to 
argv from non-main() client code has often been convenient for me.

- An OO interface into the system environment, a-la eshell's env() 
function, which returns an acme::environment objects. Having a 
framework-level interface to it eases de/serialization of the data (for 
sessions support, etc) and allows things like toggling 
read/writability, logging, saving the env in another data structure, 
etc.

- Add an optional module for reading input from the console, using 
whatever input interface is available. See 
http://s11n.net/download/#readline_cpp, which supports stdin, GNU 
Readline or BSD editline. i realize this isn't a truly generic option 
for the framework, but it would allow really easy building of 
shell-like apps. This feature, combined with the next one, gives most 
shell-like apps all they need...

- Support for built-in functions which can be called by name, like 
eshell's support. This would primarily be of interest for shell-like 
apps, but could be used to provide some interesting features for 
controlling the framework from client code. Consider these calls:
	P::dispatch_command( "sleep 20" ); // dispatches to built-in
	P::dispatch_command( "konqueror http://..." ); // external app
	P::dispatch_command( "http://..." ); // uses protocol handler
	P::dispatch_command( "p-internal run-garbage-collector" );
Then we can wrap the whole back-end process/thread management behind a 
single interface. This is the main feature eshell provides, but i think 
the feature is suitable for a wide range of apps, not just shell-like 
ones.


Except for the Process stuff, i've got code to do all of this. i would 
need to pull it into the P tree, in the appropriate modules, and sed it 
to conform to P's naming conventions, but it would otherwise be trivial 
to do.


-- 
----- 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] some ideas for expanding P

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

Am Sonntag 19 Dezember 2004 14:38 schrieb stephan beal:
> Random thoughts:
>
> - Add a more abstract process layer, such that we can do something like
> this:
>   Process proc("http://...");
>   proc.addArg( "foo=bar" );
>   ...
>   proc.start(...); // some flags might not be possible/appropriate
>   ProcessIO * io = proc.processIO();
>
> Maybe that already works? If so, please point me in the proper
> direction.

This should already work. Have a look into  'demo/process.cpp'.

> - Add support similar to s11n's acme::argv_parser class. This allows all
> client apps to read the args passed in to main(), but unfortunately
> requires that main() call either p_init( argc, argv ) or
> acme::argv_parser::args(argc,argv). Clients later call
> acme::argv_parser::args() to get the args. This is used in s11n by
> DLLs, so that they can plug in help options to a client's --help
> options. (See http://s11n.net/s11nconvert/ and grep for mysql-db,
> for an example.)
> The exact args parser used is unimportant to me, but having access to
> argv from non-main() client code has often been convenient for me.

Would you like to implement argv parsing into the experimental code base?

> - An OO interface into the system environment, a-la eshell's env()
> function, which returns an acme::environment objects. Having a
> framework-level interface to it eases de/serialization of the data (for
> sessions support, etc) and allows things like toggling
> read/writability, logging, saving the env in another data structure,
> etc.

For accessing process environment, a simple ProcessEnv class exists.

> - Add an optional module for reading input from the console, using
> whatever input interface is available. See
> http://s11n.net/download/#readline_cpp, which supports stdin, GNU
> Readline or BSD editline. i realize this isn't a truly generic option
> for the framework, but it would allow really easy building of
> shell-like apps. This feature, combined with the next one, gives most
> shell-like apps all they need...

UI things (text and graphical), until now, we're not important for us.
I used the framework for programming server software for a Bank in Berlin, 
Germany. Only UI that the server software got, was a telnet interface ;-)

However, this should change and i would like to see an Toolkit-independent, 
plugin-based GUI infrastructure for P.

> - Support for built-in functions which can be called by name, like
> eshell's support. This would primarily be of interest for shell-like
> apps, but could be used to provide some interesting features for
> controlling the framework from client code. Consider these calls:
>  P::dispatch_command( "sleep 20" ); // dispatches to built-in
>  P::dispatch_command( "konqueror http://..." ); // external app
>  P::dispatch_command( "http://..." ); // uses protocol handler
>  P::dispatch_command( "p-internal run-garbage-collector" );
> Then we can wrap the whole back-end process/thread management behind a
> single interface. This is the main feature eshell provides, but i think
> the feature is suitable for a wide range of apps, not just shell-like
> ones.
>
>
> Except for the Process stuff, i've got code to do all of this. i would
> need to pull it into the P tree, in the appropriate modules, and sed it
> to conform to P's naming conventions, but it would otherwise be trivial
> to do.


Regards,

Christian

Re: [pclasses-devel] some ideas for expanding P

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

On Monday 20 December 2004 12:52, Christian Prochnow wrote:
> >   proc.start(...); // some flags might not be possible/appropriate
> >   ProcessIO * io = proc.processIO();
> >
> > Maybe that already works? If so, please point me in the proper
> > direction.
>
> This should already work. Have a look into  'demo/process.cpp'.

Excellent :).

> > - Add support similar to s11n's acme::argv_parser class. This
> > allows all client apps to read the args passed in to main(), but
...
> > me.
>
> Would you like to implement argv parsing into the experimental code
> base?

Absolutely. i've got a bare-bones argv parser i've been using for 2+ 
years, which i could easily pull in. Once you've got the new CVS set up 
i'll start dumping code in :).

>
> For accessing process environment, a simple ProcessEnv class exists.

Oh, great! That'll do!

> > - Add an optional module for reading input from the console, using
...
>
> UI things (text and graphical), until now, we're not important for
> us. I used the framework for programming server software for a Bank
> in Berlin, Germany. Only UI that the server software got, was a
> telnet interface ;-)

LOL! i agree that UI is extremely low priority. My own ideas about it 
are more for experimentation and the joy of hacking, not because i 
really want to implement a full UI-neutral UI.

> However, this should change and i would like to see an
> Toolkit-independent, plugin-based GUI infrastructure for P.

i've been tinkering, on paper, with this idea for a year or two, as 
well.

Tasks which i'd like to sign up for regarding P:

- Adding API docs. i'm pedantic about API documentation, and would like 
to start filling out the P API docs.

- argv parser.

- serialization support for the P classes which can reasonably support 
serialization. The ground-work is essentially done, now it's time to 
add save/load support for specific P types. e.g., i'd like to be able 
to save a ResultSet (though restoring it to an actual ResultSet isn't 
feasible, i think, because of db connection persistency issues).

- Fix up mysql driver to support text/blob fields (using fix posted this 
weekend).

- Writing a lib manual. As you may have noticed, i like to write (s11n's 
lib manual is now 67 pages, not including API docs), and i think P has 
a lot of good things to write about.

- Fix up some of the abort()-calling code (throwing undeclared 
exceptions or simply calling 'throw' will do this). i submitted a bug 
or two to SF today for URL to fix 2 of these.


Please let me know when your dev tree is online so i can start hacking 
away :). The P toolkit has a fantastic set of classes, and they need 
some evangelism and love! You've got regex classes :) but i only found 
them by accident (they don't show up on all the doxygen-generated 
pages, and there is no demo app for them).

Take care,

-- 
----- 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] some ideas for expanding P

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

On Monday 20 December 2004 12:52, Christian Prochnow wrote:
> >   Process proc("http://...");
> >   proc.addArg( "foo=bar" );
>
> This should already work. Have a look into  'demo/process.cpp'.

It works with bins for me, but not with URLs:

    Process proc("http://s11n/");

creating process
I/O error: No such file or directory

i assume it's the same problem as the IOManager example not being able 
to find http handler.
    
> For accessing process environment, a simple ProcessEnv class exists.

i'd like to add funcs to do env ${var} expansion on strings. e.g.:

  std::string s = myenv.parseVars( inputstring );

i've got the code for it, just need to plug it in to the tree. With that 
support we can do things like: open_file( "${HOME}/.myconf" ).

In eshell, before an input command is passed off to a client eshell does 
var and alias expansion on it, plus expansions provided by wordexp (man 
3).

See ya!

-- 
----- 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] some ideas for expanding P

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

Am Montag 20 Dezember 2004 22:12 schrieb stephan beal:
> On Monday 20 December 2004 12:52, Christian Prochnow wrote:
> > >   Process proc("http://...");
> > >   proc.addArg( "foo=bar" );
> >
> > This should already work. Have a look into  'demo/process.cpp'.
>
> It works with bins for me, but not with URLs:
>
>     Process proc("http://s11n/");
>
> creating process
> I/O error: No such file or directory
>
> i assume it's the same problem as the IOManager example not being able
> to find http handler.

Ahh ok, now i got you. The 'Process' class only supports spawning local 
processes and reading/writing to their stdin/stdout. I would like to leave 
this unchanged. Process is a low-level system abstraction class, which should 
be as small as possible. 
Instead i would implement a IOPlugin "process://" which could do the job.
That way you could do every IO with the IOManager.

> > For accessing process environment, a simple ProcessEnv class exists.
>
> i'd like to add funcs to do env ${var} expansion on strings. e.g.:
>
>   std::string s = myenv.parseVars( inputstring );
>
> i've got the code for it, just need to plug it in to the tree. With that
> support we can do things like: open_file( "${HOME}/.myconf" ).
>
> In eshell, before an input command is passed off to a client eshell does
> var and alias expansion on it, plus expansions provided by wordexp (man
> 3).

Great! I would love it.

> See ya!


Greetings,

Christian

Re: [pclasses-devel] some ideas for expanding P

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

On Tuesday 21 December 2004 15:05, Christian Prochnow wrote:
> > i assume it's the same problem as the IOManager example not being
> > able to find http handler.
>
> Ahh ok, now i got you. The 'Process' class only supports spawning
> local processes and reading/writing to their stdin/stdout. I would
> like to leave this unchanged. Process is a low-level system
> abstraction class, which should be as small as possible.
> Instead i would implement a IOPlugin "process://" which could do the
> job. That way you could do every IO with the IOManager.

i agree - this should be based on the IOMgr layer, not Process itself.

> > In eshell, before an input command is passed off to a client eshell
> > does var and alias expansion on it, plus expansions provided by
> > wordexp (man 3).
>
> Great! I would love it.

All i need is write access to the tree... :)
BTW: i'm currently working off of the CVS copy from SF. Is that the one 
you're refactoring, or is that somewhere else?

Last night, once i finally realized there was a DLL/symbol problem, i 
got the IOMgr working (again) on my box. With that i'll be able to 
implement a single class which can dispatch load/save over 
http/ftp/file URLs (though the file:// handler always fails with 
something like "cannot resolve service name"). That is, any handler 
supported by IOManager will inherently be available as a serialization 
channel for P::s11n. Pretty cool, i think. :)

Speaking of DLL symbols: you can do DLL/plugin registration and loading 
without reading a single symbol from a DLL. See 
http://s11n.net/papers/#classloading_cpp
The approach described there introduces compile-time, cast-free, 100% 
type safety for types loaded from DLLs (on the surface that sounds 
impossible, but it is actually a natural side-effect of templates).



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