pclasses-devel — P::Classes developer mailing-list

[pclasses-devel] addition for module loader

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

i was just bitten by this:

                factory.addPlugin("psql_mysql.so");
works, but:
                factory.addPlugin("psql_mysql");
doesn't.

That same problem shows up in C#'s approach to linking to DLLs. :(

IMO, the .so is platform-specific, and therefor doesn't belong there. 
The module loader should know the extension for the platform it's on 
and automatically append it, if needed. See 
s11n.net/download/#class_loader, src/path_finder.?pp for a class which 
implements that behaviour. It should be possible to drop that (or 
equivalent) right into the module loader's search routine. See 
src/class_loader.cpp, and grep for ".dll" to see how it's used.

:)

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

[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

[pclasses-devel] http serializer now works via s11nconvert/s11nbrowser :)

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

s11n now supports 9 (count 'em: 9) data transport layers, including 
http. This new format is a bit unusual in that it proxies arbitrary 
formats, and doesn't really provide a data format itself. For writing 
it defaults to using 'funtxt', but for loading it supports any format 
supported by s11nlite.

Plugging in P's http-based serializer required no s11n-level changes, as 
we can dynamically load the serializer via the name 'phttp' and treat 
it like any other Serializer:

Witness:

A s11n data file:

~> cat in.s11n
(s11n::parens)
data_node=(list
        data_node=(lex_t (v 42))
        data_node=(lex_t (v -42.420000))
        data_node=(lex_t (v fourty two))
        data_node=(lex_t (v x))
)


Import it from the file and re-save it over the web:

~> s11nconvert -f in.s11n -s phttp -o 
'http://s11n/ps11n.php?node_name=sumdumlist'
// -f == input file
// -s == output serializer
// -o == output file

Now it's in the db:

~> mysql -e 'select id,name from ps11n' ps11n
+----+------------+
| id | name       |
+----+------------+
| 15 | bar        |
| 28 | bob        |
| 29 | boo        |
| 19 | egal       |
|  1 | foo        |
| 26 | fred       |
| 33 | mylist     |
HERE ----> | 34 | sumdumlist |
| 24 | thelist    |
| 32 | wow        |
| 23 | yourlist   |
+----+------------+


Now load it, saving it to stdout in another format:

~> s11nconvert -f 'http://s11n/ps11n.php?node_name=sumdumlist' -S phttp 
-s funxml
// -f == input file
// -S == *force* input serializer phttp
//       (it cannot yet be dynamically dispatched this way)
// -s == output serializer

The output:

<!DOCTYPE SerialTree>
<data_node class="list">
        <data_node class="lex_t">
                <v>42</v>
        </data_node>
        <data_node class="lex_t">
                <v>-42.420000</v>
        </data_node>
        <data_node class="lex_t">
                <v>fourty two</v>
        </data_node>
        <data_node class="lex_t">
                <v>x</v>
        </data_node>
</data_node>

Cool, eh? It also plugs in to the s11nbrowser interface:
	http://s11n.net/s11nbrowser/
see the last 2 screenshots.


Caveats:

a) because i'm using http GET, saving is probably limited to relatively 
small, not-extremely-complex objects. i'll figure out how to resolve 
this later on. Loading should work for arbitrarily large data, as long 
as it can all fit in a std::string buffer.

b) if you pass a non-well-formed URL it may cause a segfault in P::URL, 
catch() notwithstanding:
	s11nconvert -f in.s11n -s phttp -o not_a_http_url
	Aborted

c) Never call s11nlite::serializer_class("phttp"). That will set 
s11nlite's default output format to phttp, and will hose things.  
s11nlite tries to save it's config post-main() and probably can't if 
phttp is it's default output format.

d) If using s11nbrowser, make sure to accidentally do (c) by accident 
(it's easy to do).

e) When saving/loading to/from a stream, e.g., save(obj,cout) it writes 
using its proxy format, and does no http operations.



-- 
----- 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] IOManager not finding http handler?

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

Am Sonntag 19 Dezember 2004 10:24 schrieb stephan beal:
> Hiya!

Hi !

>
> Here's some code from the API doc pages, slightly modified for Singleton
> changes in IOManager:
>
> // _url =3D string("http://host/")
> // buff =3D=3D (std::string &) target for buffering
> IOManager & ioman =3D IOManager::instance();
> IORequest_Get* req =3D ioman.get(URL(_url));
> req->open();
> size_t ret =3D 0;
> char cbuff[4096];
> while((ret =3D req->receive(cbuff,sizeof(cbuff))) > 0)
> {
>     buff.append( cbuff, cbuff + ret );
> }
> ioman.finish(req);
>
> For me this is always throwing 'No handler for protocol found' for http
> URLs. Do i need to explicitely register an http handler?
>
> i remember this example did work for me from the 1.0b1 tree. (Currently
> using CVS copy.)

Hmmm .. i have to investigate it further, i think it's the same issue that=
=20
causes the trouble you had with the sql module.


Sch=F6nen 4. Advent noch :-)

Gr=FC=DFe,
Christian

[pclasses-devel] fyi: P::s11n web page

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

http://s11n.net/ps11n/

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

[pclasses-devel] IOManager not finding http handler?

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

Hiya!

Here's some code from the API doc pages, slightly modified for Singleton 
changes in IOManager:

// _url = string("http://host/")
// buff == (std::string &) target for buffering
IOManager & ioman = IOManager::instance();
IORequest_Get* req = ioman.get(URL(_url));
req->open();
size_t ret = 0;
char cbuff[4096];
while((ret = req->receive(cbuff,sizeof(cbuff))) > 0)
{
    buff.append( cbuff, cbuff + ret );
}
ioman.finish(req);

For me this is always throwing 'No handler for protocol found' for http 
URLs. Do i need to explicitely register an http handler?

i remember this example did work for me from the 1.0b1 tree. (Currently 
using CVS copy.)

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

[pclasses-devel] an s11n-first: de/serialization over http using P::Classes

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

This certainly isn't a world-first, but it is a first for s11n:

i've just serialized a list<> over http, using a PHP proxy script to 
store it in a mysql db as raw text, and then deserialized it back over 
http. The implementation probably only works for small data sets, 
because i'm using http GET and a hell of a lot of space-to-%20 
encoding, but the work was fairly trivial - even the encoding part fit 
right in to the existing Serializer model.

The client-side code is trivial:

Create and save an object:

  typedef std::list<lext::lex_t> ListT;
  ListT li;
  li.push_back( 42 );
  li.push_back( -42.42 );
  li.push_back( "fourty two" );
  li.push_back( 'x' );
  bool workie;
  if( ! P::s11n::save( li, "http://s11n/ps11n.php?node_name=name" ) )
  {
      ... failed :( ...
  }


Load a node:

P::s11n::node_type * node =
  P::s11n::load_node( "http://s11n/ps11n.php?node_name=name" );

"Completely" deserialize it with:

  ListT li;
  bool worked = P::s11n::deserialize( *node, li );
  delete node;



Note that http://s11n/ is my local machine, not s11n.net.


Test output:

Write an object:

stephan@owl: > m && ./test
<snip>
test.cpp:36 : test_writeurl()
// the object we're writing to the URL:
test.cpp:47 : list<lex_t>:
(s11n::parens)
data_node=(list
        data_node=(lex_t (v 42))
        data_node=(lex_t (v -42.420000))
        data_node=(lex_t (v fourty two))
        data_node=(lex_t (v x))
)
ps11n.hpp:220 : serialize(node,
[http://s11n/ps11n.php?node_name=egal])...
<snip>
stephan@owl:~/cvs/s11n.net/ps11n/src> echo $?
0


Load it back:

stephan@owl: > m && ./test 'http://s11n/ps11n.php?node_name=egal'
test.cpp:15 : test_readurl()
test.cpp:25 : node ? = 0x80b9c58
// the data we got from the web server:
(s11n::parens)
data_node=(list
        data_node=(lex_t (v 42))
        data_node=(lex_t (v -42.420000))
        data_node=(lex_t (v fourty two))
        data_node=(lex_t (v x))
)



The PHP quick-hack http/mysql proxy is attached, and the db code is 
simply:

CREATE TABLE ps11n (
  id int(11) NOT NULL auto_increment,
  name varchar(255) NOT NULL default '',
  data longtext,
  PRIMARY KEY  (name,id),
  UNIQUE KEY id (id),
  KEY name (name)
) TYPE=MyISAM;

The ID field isn't strictly neccessary, though.


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

[pclasses-devel] crashes in sql layer, with demo code

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

Yo, fellas,

Attached is a test i've been toying with regarding db support. Please 
grep the file for '^^^^' and you should find 4 comments which note 
crashes i had while running it.

The code is basically a mix of the sql.cpp from 1.0b1 and today's CVS. 
The code in CVS fails on me at the first ^^^^ point, which is why i 
pulled in code from the older demo.

To build it:

Simply replace demo/sql.cpp with the attached file, edit the db 
parameters and table name (but see the 3rd ^^^^ note, and pick an 
appropriate field name), and then build.

-- 
----- 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] notes on P vis-a-vis s11n

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

On Saturday 18 December 2004 22:45, Tommi M=E4kitalo wrote:
> You mention PHP. And you like C++? Then you might be interested in my
> project tntnet. It is a webapplicationserver for C++, which supports
> a special template-system similar to PHP, but instead of embedding
> PHP in HTML, you can insert C++-code.
>
> Just visit the homepage http://www.tntnet.org/.

i will take a look. :) i love PHP, actually, but i have a project coming=20
up next year where C++ will probably be the better choice. It also=20
sounds like that would be a great place to take advantage of some of=20
P's features, like threading and db support.

> And to add to your s11n (sounds interesting) - it would be fun to
> create a webapplication with tntnet, which serializes some
> c++-objects with s11n and a c++-client-program to receive them. Hey -
> that's great!=20

That's s11n's bread and butter. :) i'm normally a very humble person,=20
but when it comes to saving data, i truly believe that s11n has every=20
other serialization framework beat hands-down. Integration with P will=20
make it even more powerful, e.g., by allowing a db-neutral=20
serialization layer. The s11n interface is such that client objects=20
don't care where they save to - they store their state to containers,=20
and Serializers take care of formatting those containers to whatever=20
grammars/DB/data stores they want to.


> I will look at s11n.=20

Enjoy! The website has TONS of docs and examples, so you should be able=20
to find pretty quickly whether or not s11n will do the trick for you.

=2D-=20
=2D---- 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] notes on P vis-a-vis s11n

[Tommi <t.m...@ep...>]

Am Samstag, 18. Dezember 2004 13:50 schrieb stephan beal:
> Hi again,
>
...
>
> P provides some classes which have HUGE implications for s11n,
> especially the IODevice layer. With streambuf wrappers, or equivalent,
> we could de/ser from/to arbitrary pipes, using, zB, P::ProcessIO. This
> would allow, zB, piping s11n over ssh connections, over HTTP and FTP,
> etc. The uses for this are HUGE, my friends, HUGE! i experimented last
> night with pulling s11n'd data from an http server. i haven't yet
> written over http, but that should be trivial using your http code and
> a CGI/PHP script on the server. That would allow client apps to save
> over the web, bypassing most firewall-related problems of saving over
> the net.
>
You mention PHP. And you like C++? Then you might be interested in my project 
tntnet. It is a webapplicationserver for C++, which supports a special 
template-system similar to PHP, but instead of embedding PHP in HTML, you can 
insert C++-code.

Just visit the homepage http://www.tntnet.org/.

And to add to your s11n (sounds interesting) - it would be fun to create a 
webapplication with tntnet, which serializes some c++-objects with s11n and a 
c++-client-program to receive them. Hey - that's great! I will look at s11n.


Tommi

[pclasses-devel] how to add vars to a POST for HttpRequest?

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

Question:

i'd like to post serialized data to a php script using post. i can 
formulate it for GET by adding ?arg=..., but is there a different way 
to do it for post? i don't see any URL or HttpRequest methods for 
adding vars. i could also be misunderstanding: is post data sent just 
like get data, as far as the client is concerned?

i've got a small PHP script which saves/loads serialized data, submitted 
via GET/POST, to a db, so implementing http-based saving will be a 
snap. :)

Is there a way to do http file uploads with the P API? That might be 
better, to allow for larger serialized data to be passed. i'm pretty 
clueless about the deep internals of HTTP.

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

[pclasses-devel] Re: pclasses and s11n

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

On Saturday 18 December 2004 14:18, Marc Duerner wrote:
> > i really like the name pclasses!
>
> Alright, alright, we'll keep it ;)

That's up to you guys. i think the name is sharp, though. 
"Clean-sounding." Though of course it leaves open some undesirable 
puns ;).


> > Very few people, like Alexandrescu, but his work is primarily
> > theoretical/experimental.
>
> Hmm, do you have any papers from him or something?

moderncppdesign.(com?net?org?)


> > We need to kill of C by providing a better C++ framework :).
>
> How would you like to proceed? 

i think you guys have done a hell of a job in getting a running start!
i'll answer this in a longer mail later on with some potential ideas. 
The s11n/P integration was a lot simpler than i though it'd be, and i'd 
like to play some more with remote serialization.


> I realised that I never subscribed to 
> pclasses-devel. I subscribed read your emails in the archive. Also I
> attached an unofficial snapshot of P::Classes 2. We have the freedom
> to address everything we want in p2.

Excellent :). i've got the latest CVS tree - is that what's in the 
attached file?

> One idea about the "IORequest_Get::receive() suggestion"
>
> size_t ret = receive( &v[0], v.size() );
>
> I havent really thought about this. I have a class ByteArray that I
> use for this to avoid char[]. Maybe we could have a function in
> ByteArray::toString() or something. Or cprochs new String class has a
> ctor for a vector<char>. putch() / getch() could also be handy in
> P::IODevice.

The exact impl isn't important - just knew that is a quick/easy way to 
convert between C-string and std::string.

> On the other hand all this should rather be done in the IOStream
> class. But then I guess its not so easy to get an IOStream from the
> IORequest_Get class. Hmm :/

i realized that as well. i don't know if it's for intentional design 
reasons or "Pech gehabt."

> About the abort in PIO, maybe its an exception from loading a plugin
> which is P::RuntimeError. just change your catch() to catch
> P::BaseError. and see if you get something.

it's all resolved - i wasn't doing the netdb part, or was leaving out 
the connect call on the http client. Adding a couple try/catches helped 
me out.

> Its GPL with a linking exception for closed source programs. They
> will switch to LGPL in the next major release because too many people
> misunderstood their license.

That's good news.

> I am on IRC now for 1-2 hours maybe and then on the plane back to
> Europe, see you later,

i'm on irc now: gjehle is there, but hasn't noticed me yet.

i'd love to hear your ideas about where you'd like to take pclasses, 
assuming you've got some specific areas you're focusing on. i'll wait 
until everyone's caught up on reading my spams before i post more.

See ya!

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

[pclasses-devel] P::s11n deser over http URLs works :)

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

Yo:

With only about an hour's work i've put together a proof of concept for 
deserializing from http URLs using pclasses' HttpClient. i can't yet 
serialize over them, but that shouldn't be especially hard to achieve 
via a PHP proxy.

Attached:

ps11n.hpp: the entire implementation. Essentially just a wrapper around 
s11nlite, plus the Serializer implementation.

test.cpp: demo

TODOs:

a) Add serialize() support. It's partially implemented, but isn't useful 
over http yet. It will work by POSTing content written by one of the 
XML Serializers. What the remote side does with it is undefined, though 
- depends on the proxy script running on the http server. The obvious 
choice is simply to dump the node into a db in one big text field.

b) Genericize the Serializer dispatcher to recognize URLs. i'll see if i 
can work with in to s11n::io without breaking anything not requiring an 
explicit dep on pclasses. (Shouldn't be a big problem.)

c) Implement the same for P::FtpClient.

d) A couple other internal tweaks.


It's is now a one-liner to deser an object over http:

   P::s11n::node_type * node =
      P::s11n::load_node( filename_or_http_url );

Reminder: we're still right at home in C++. :) :) :)

The input *format* is irrelevant: any supported by s11nlite will work.

Assuming node != 0, we can deserialize it to it's "complete" type with:

   MyType * obj = P::s11n::deserialize<MyType>( *node );

Or:

   MyType obj;
   bool worked = P::s11n::deserialize<MyType>( *node, obj );

   delete node;

@pclasses: i've got a couple patches to commit to IODevice and 
IORequest_get. May i have CVS access? (SF=sgbeal) More patches are 
certainly in the plan...

Demo output:

stephan@owl:~/cvs/s11n.net/ps11n/src> m && ./test http://s11n/P.s11n
test.cpp:19 : test_ps11n()
test.cpp:35 : node ? = 0x806e0d8
(s11n::parens)
somenode=(NoClass (a \(\)\\b) (foo bar) (long this is a long property)
        fred=(FredClass (key value))
        wilma=(WilmaClass (the lovely wife))
        betty=(BettyClass (value the apple of Barney's eye))
        deep=(Foo
                deeper=(Foo (how_deep really deep!)
                        and_deeper=(Ouch)
                )
        )
)



-- 
----- 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] signals/slots for IODevices?

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

Am Samstag 18 Dezember 2004 14:03 schrieb stephan beal:
> Yo again!
>
> Question: would it be feasible/realistic to add signals to IODevice.
> Something like:
>
> signalRead( const IODevice &, const char * buff, size_t count );
> signalWrite( const IODevice &, const char * buff, size_t count );
>
> The first arg is so that one client slot could listen to multiple IODs,
> but we wouldn't want them changing the IOD from the slot, thus the
> const.

Yes, good idea !  Don't know why it's missing ;-)

> This would allow:
>
> a) send read/write progress feedback in, zB, a UI.
>
> b) me to plug in the s11n Serializers to IOD, by simply capturing read()
> input via a slot, then sending it to the Serializers via an
> istringstream copy of the input. (They're designed to read
> std::istreams and write to std::ostreams.)
>
> Or are there good reasons not to do this?
>
> Quasi-related:
>
> For streambuffer support, i'm thinking something like this:
>
> IODevice * my_io_device = new SomeIODevType(...);
> IODevStreambuf sb( my_io_device );
> // ^^^^ basically proxies over/underflow() to read/write()
> std::ostream os( &sb );
> // use any IODevice via any std::stream
>
> i don't know if it'll work, though. When i've tried to implement custom
> stream buffers i've failed horribly - the architecture, while sound,
> confuses me. Too many low-level details to track at once for my mind to
> keep up with.
>
> Hell, this support may already exist in P. If so, i haven't found it
> yet.

Please have a look at P::IOStream.


Regards,

Christian

Re: [pclasses-devel] notes on P vis-a-vis s11n

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

Am Samstag 18 Dezember 2004 13:50 schrieb stephan beal:
> Hi again,
>
> i wanted to take a minute to "preach" - to give some insights on the
> possibilities of mixing s11n and P together, and how that might be
> accomplished with remarkably little effort.
>
> As you may have noticed, based on the size of the s11n documentation and
> web site, i'm Very Proud of s11n. Over the past 14 months it has
> evolved to do every serialization task i've thrown at it (with one
> small exception, but i'm working on solving that). It hasn't yet been
> used for network-based serialization, as far as i know, but with P i
> hope to change that.
>
> s11n takes a slightly unconventional approach to integrating into
> projects: instead of forcing a project to use s11n's API directly, s11n
> can be told to follow a client-side API, via the use of proxies created
> via class template specializations and functors. What this essentially
> means is that we can seemlessly, for purposes of the API, merge s11n
> and P. i would be more than happy to take on this work, and to assist
> with P in any way that i can.
>
> s11n comes with a layer called 's11nlite'. This layer provides a binding
> between the core s11n layer (which is 100% container-based - no streams
> support) and the reference implementation of an i/o layer (s11n::io).
> s11nlite contains a relatively small amount of code, encapsulated in 1
> header and 1 impl file.
>
> Now, with a little bit of copy/paste work it would be no problem at all
> to provide a P-centric version of s11nlite, like P::s11n, which hides
> the "raw" s11n API from P applications. That is, clients would not have
> to know they're using 2 different frameworks when serializing their P
> objects via s11n. The best part is: this can be done a) without
> modifying s11n and b) without modifying (only adding to) P.
>
> i suspect that a lot of the "utility code" in P and s11n overlap, so
> there would be a small bit of bloat there, but that could all (or
> almost all) be hidden from P::s11n users via s11n's API marshalling
> techniques.
>
> In case you don't know: s11n recognizes 2 different approaches to
> Serializable types: those which directly implement a Serializable
> interface (save/load functions) and those which are proxied via a
> functor. Proxies allow us to, e.g., do this:
>
> typedef std::map<std::string,std::list<int> > MapT;
> MapT m;
> // ... populate map ...
> s11nlite::save( m, somestream );
>
> MapT is proxied by a pair of algos which known how to de/ser std::maps.
> Likewise, std::string and std::list also have proxies. Even though we
> cannot edit those classes, s11n's proxy support allows us to treat them
> as first-class Serializable objects. The only requirements is that the
> type provide the necessary accessors/mutators so that we can
> save/restore the type's state (all std containers provide this).
>
> What this means is that many existing P classes can be transformed into
> Serializables *without touching one line of their code*. If a type does
> not supply the nececssary API, or wants to directly implement a
> Serializable Interface, that's okay, too - s11n provides full support
> for virtual/polymorphic Serializables, including DLL-based loading of
> deserialized types, if needed.
>
> The implication of the proxy support is that we can integrate s11n
> support into P without modifying the P code base. In fact, it could be
> supplied as an optional layer, even from another source tree. Clients
> including the P::s11n layer get serialization, those who don't, don't.

I would definetly love to see serialization inside P::Classes !

> P provides some classes which have HUGE implications for s11n,
> especially the IODevice layer. With streambuf wrappers, or equivalent,
> we could de/ser from/to arbitrary pipes, using, zB, P::ProcessIO. This
> would allow, zB, piping s11n over ssh connections, over HTTP and FTP,
> etc. The uses for this are HUGE, my friends, HUGE! i experimented last
> night with pulling s11n'd data from an http server. i haven't yet
> written over http, but that should be trivial using your http code and
> a CGI/PHP script on the server. That would allow client apps to save
> over the web, bypassing most firewall-related problems of saving over
> the net.

Really neat!

> Last night i put together a type to buffer s11n data to/from IODevice
> (or similar), and will attempt to take s11n into the realm of networks
> this weekend.
>
> Potential caveat:
> P is more portable that s11n. i have no idea if compilers on HPUX,
> Tru64, AIX, etc., support class templates well enough to use s11n.
> Since i only use Linux and Solaris, and only program using GNU tools, i
> personally can't offer much help when it comes to wide portability. i
> do avoid Linux-only code - i use only std C++ constructs, but i also
> freely take advantage of gcc's excellent standards support, and that
> means excluding older compilers.
>

Platform portability is mainly archived by the P::Classes core library.
We also use gcc's excelent standard support - that means that we have to use 
gcc3 on all UNIX platforms. But we have to take care that the code base 
compiles fine under Visual C++ .NET (Win32).

> Unrelated: build tree problem
> Can someone remind me of the proper set of commands to completely
> rebuild the configure script and Makefile.in's? My autotools are newer
> than those in the build tree, and i can't get them to pick up my
> changes to Makefile.am. i haven't used autotools in 2 years or so, and
> have forgotten the various tricks. (My feelings towards autotools
> are... well, they're not nice. See toc.sf.net for why.)

try "autogen.sh" in the root dir of the build tree.

>
> i wish i had found P a lot sooner...
>
> If you'll excuse me now... i've got to go P. ;)

As marc already mentioned, i'm currently doing a refactoring of the P::Classes 
framework. Maybe we can work together to bring all the neat features right 
into it. 


Regards,

Christian

Re: [pclasses-devel] Re: pclasses compile warnings and error...

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

Am Samstag 18 Dezember 2004 13:21 schrieb stephan beal:
> (Off-list mail, redirected to the list...)
>
> On Saturday 18 December 2004 03:42, Marc Duerner wrote:
> > > i can't find the definition of at_addr, only a forward decl in
> > > pataladdr.h.
> >
> > Thanks, I have forwarded that to cproch. But I remember that there is
> > a bug with appletalk kernel headers on debian. If you use debain try
> > the CVS version and it should go away.
>
> i just had to install the atalk-devel package and do a #define kludge in
> patalkaddr.h, then it worked. i'm on Suse 9.2, by the way.

See previous mail.

> > There is also pclasses and pclasses-devel IRC channels on freenode,
> > but they arent used that much.
>
> i tried the irc channel, but only the bot was online. i'm no a dialup
> line, so i don't use IRC that much, but it is very useful for
> programming colaboration.
>
> i went to bed about 5 this morning after playing with P for 4 or 5
> hours. i'm very impressed with it. The only thing i'm puzzled about how
> to do is to tie a std::streambuf to a P::IODevice. Maybe it's not
> possible/desired, but if it is possible it would means a LOT for
> serialization purposes!

Try P::IOStream, that should do the job  ;-)

> i will continue playing with P with it today. i got the mysql connection
> working, after some experimentation, and i would like to re-implement
> the mysql_serializer on top of the P::SQL layer. That's my project for
> this weekend. :) The current mysql-based serializer is EXTREMELY slow,
> and only supports mysql. The P db layer looks really nice, and i hope
> to be able to support any db for which there is a P driver.

Re: [pclasses-devel] sublayer idea: dynamic stream dispatching

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

The std::iostreams stuff in pclasses definetly needs a rework.
I like your idea with "output filters". Maybe we can do a complete io stream 
rework together.

Regards,

Christian

Am Samstag 18 Dezember 2004 01:01 schrieb stephan beal:
> Yo again!
>
> i've got a little lib, called zfstream, which adds client-transparent
> support for loading compressed files. For some months i've been
> thinking about making a more generic variant of it which can be
> extended by registering handlers. Looking at your I/O layer, believe
> that code would be a great basis for it.
>
> To give some background/context... consider this code:
>
> std::istream * is = zfstream::get_istream( "some_file" );
> if( ! is ) { file not found or could not be opened }
>
> The input stream might actually be a compressed file, and the stream
> might be of type gzstream or bzstream (for gzip or bzip2,
> respectively). get_istream() examines the file to determine which type
> of decompressor to use, and passes back the appropriate stream type.
>
> The same goes for output files:
>
> Set the framework-wide policy:
>
> zfstream::compression_policy( zfstream::GZipCompression )
>
> Now all calls like these use the requested compression:
>
> std::ostream * os = zfstream::get_ostream( "some_file" );
>
> The ostream is compressed if the lib supports it (if configure script
> finds zlib) and if compression_policy() specifies it. If not, you get
> back an uncompressed stream.
>
> The point is, client code doesn't know if it's using compressed streams
> or not, and doesn't have to know.
>
> By making that more generic and adding handlers for your I/O classes, we
> could do:
>
> SomeIORequestBase * os =
>     get_ostream( "http://s11n.net/s11n/sample.s11n.gz" );
>
> and that might return a gzip-decompressing stream type.
>
> i've tried a couple times to implement custom std::streambuffer classes
> and i've failed miserably. Anyone out there who thinks that it isn't
> too much work to write std-stream wrappers for the P::IO layer?
>
> Take care,

Re: [pclasses-devel] IORequest_Get::receive() suggestion

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

Sure, it will be added.

Thanks for your feedback,

Christian


Am Samstag 18 Dezember 2004 00:37 schrieb stephan beal:
> Yo again:
>
> IORequest_Get::receive( char *, size_t );
>
> Could i convince you guys to either:
>
> a) Add receive( std::string &, size_t );
> or
> b) give me CVS write access so i can? (SF user == sgbeal)
>
> ??
>
> It can be implemented in terms of the current receive() by passing a
> vector<char> to the existing function, then simply copying the result
> to a std::string. Something like:
>
> size_t receive( std::string & s, size_t count )
> {
>  typedef vector<char> VC;
>  VC v( count, '\0' );
>  size_t ret = receive( &v[0], v.size() );
>  s = std::string( v.begin(), v.begin() + ret );
>  return ret;
> }
>
> (achtung: untested)
>
> (achtung #2: when i find exciting code i send lots of mails. ;)

Re: [pclasses-devel] solved: missing at_addr definition?

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

As i already said, please use the 1.0.0_beta2 from CVS.

Christian


Am Samstag 18 Dezember 2004 00:27 schrieb stephan beal:
> On Friday 17 December 2004 23:45, stephan beal wrote:
> > atalkaddr.cpp: In constructor `P::ATalkAddress::ATalkAddress()':
> > patalkaddr.cpp:39: error: invalid application of `sizeof' to an
> > incomplete type
>
> Solved: installed netatalk-devel
> and the compulsory kludge in patalkaddr.h:
>
> Replace:
>  struct at_addr;
>
> with:
>  struct atalk_addr;
>  #define at_addr atalk_addr
>
> configure script apparently doesn't check for appletalk, or the
> makefiles don't properly accommodate when it's not there.
>
> Take care,

Re: [pclasses-devel] comments from a pclasses newbie

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

Hi again ;-)

s11n for pclasses would be really great! i already thought of a serialization 
layer for pclasses.

i also have some ideas for a pluggable, toolkit-independent gui 
infrastructure.


Regards,
Christian Prochnow

Am Freitag 17 Dezember 2004 23:56 schrieb stephan beal:
> Hi again!
>
> Again - i'm new to pclasses, just learned about it today. After glancing
> over the Doxygen docs a bit, i'm a Happy Camper :). i've got a couple
> comments, if i may...
>
> (Marc, please ignore the mail i just sent directly to you - this is list
> stuff, i think, so i'll repost it here...)
>
> pclasses is DEFINATELY something i'm interested in. i'm a big fan of
> UI-neutral frameworks of this type. i've been piddling around with some
> ideas for a couple years regarding a ui-neutral "UI" toolkit, called
> "noui", which abstracts Widgets into a UI-neutral layer, relying on a
> signals/slots layer to translate changes to/from UI-toolkit wrappers.
> It looks like a combination of s11n and pclasses would provide what i
> would need to turn the noui idea into not only an abstract "non-UI"
> toolkit, but also an abstract "non-desktop" framework, like a "nokde".
>
> i, too, have tinkered with ideas similar to your SimpleApp class, and i
> LOVE that someone (you) has put together a framework for this. My
> original intention for such a type was to support my 'eshell' framework
> (http://s11n.net/eshell/), and eventually to extend that to the "noui"
> framework. To be clear: the noui idea is all theoretical, with very
> little actual code, primarily because of my lack of a really flexible
> signals/slots implementation. i've got a sigslot lib
> (http://s11n.net/sigslot/), which i ripped off from Sourceforge, but
> it's got a couple limitations which keep me away from using it
> widespread. i don't yet know if pclasses has the same limitations (or
> others). pclasses provides the network layer, too, which is really
> cool. i'm hoping i can build an s11n-capable network layer on top of
> it. :) (http://s11n.net/, of course ;).
>
> Anyway... thanks again to Marc for the referral to your project. As soon
> as i can compile it i will start tinkering. :)

Re: [pclasses-devel] 1.0.0b1 compile error: missing at_addr definition?

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

Hi !

This error is caused by the kernel 2.6 headers, cause the kernel guys have=
=20
renamed the Appletalk address structure. However it should be catched by th=
e=20
configure script found in P::Classes 1.0.0-beta2 which you can get from CVS.

Regards,

Christian Prochnow


Am Freitag 17 Dezember 2004 23:45 schrieb stephan beal:
> Yo, pclasses guys!
>
> i was referred to your project today by Marc, and am very interested in
> trying out pclasses. Unfortunately...
>
> stephan@owl:~/src/pclasses-1.0.0beta1> gcc --version
> gcc (GCC) 3.3.4 (pre 3.3.5 20040809)
>
> (Suse Linux 9.2)
> ...
>
> atalkaddr.cpp: In constructor `P::ATalkAddress::ATalkAddress()':
> patalkaddr.cpp:39: error: invalid application of `sizeof' to an
> incomplete type
> patalkaddr.cpp: In constructor `P::ATalkAddress::ATalkAddress(const
> at_addr&)':
> patalkaddr.cpp:51: error: invalid application of `sizeof' to an
> incomplete type
> patalkaddr.cpp:53: error: invalid application of `sizeof' to an
> incomplete type
> patalkaddr.cpp: In constructor `P::ATalkAddress::ATalkAddress(const
> =C2=A0 =C2=A0std::string&)':
> patalkaddr.cpp:57: error: invalid application of `sizeof' to an
> incomplete type
> patalkaddr.cpp: In member function `P::ATalkAddress&
> =C2=A0 =C2=A0P::ATalkAddress::operator=3D(const at_addr&)':
> patalkaddr.cpp:79: error: invalid application of `sizeof' to an
> incomplete type
>
>
>
> i can't find the definition of at_addr, only a forward decl in
> pataladdr.h. Any quick workaround would be really cool. :)
>
>
> There are also a couple of warnings, but those aren't stopping my build:
>
> piodevice.posix.cpp: In member function `virtual off64_t
> P::IODevice::seek(long
> =C2=A0 =C2=A0long unsigned int, P::IODevice::seekMode_t)':
> piodevice.posix.cpp:189: warning: comparison between signed and unsigned
> =C2=A0 =C2=A0integer expressions
>
> pfilemon.fam.cpp: In member function `bool
> =C2=A0 =C2=A0P::FileMonitor::wait(P::FileMonitor::Event&, unsigned int)':
> pfilemon.fam.cpp:177: warning: label `_select' defined but not used
>
> pthreadpool.cpp: In member function `void
> =C2=A0 =C2=A0P::ThreadPool::finished(P::WorkerThread*)':
> pthreadpool.cpp:162: warning: unused variable `P::ThreadJob*job'
>
> Take care,

[pclasses-devel] signals/slots for IODevices?

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

Yo again!

Question: would it be feasible/realistic to add signals to IODevice. 
Something like:

signalRead( const IODevice &, const char * buff, size_t count );
signalWrite( const IODevice &, const char * buff, size_t count );

The first arg is so that one client slot could listen to multiple IODs, 
but we wouldn't want them changing the IOD from the slot, thus the 
const.

This would allow:

a) send read/write progress feedback in, zB, a UI.

b) me to plug in the s11n Serializers to IOD, by simply capturing read() 
input via a slot, then sending it to the Serializers via an 
istringstream copy of the input. (They're designed to read 
std::istreams and write to std::ostreams.)

Or are there good reasons not to do this?

Quasi-related:

For streambuffer support, i'm thinking something like this:

IODevice * my_io_device = new SomeIODevType(...);
IODevStreambuf sb( my_io_device );
// ^^^^ basically proxies over/underflow() to read/write()
std::ostream os( &sb );
// use any IODevice via any std::stream 

i don't know if it'll work, though. When i've tried to implement custom 
stream buffers i've failed horribly - the architecture, while sound, 
confuses me. Too many low-level details to track at once for my mind to 
keep up with.

Hell, this support may already exist in P. If so, i haven't found it 
yet.



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

[pclasses-devel] notes on P vis-a-vis s11n

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

Hi again,

i wanted to take a minute to "preach" - to give some insights on the 
possibilities of mixing s11n and P together, and how that might be 
accomplished with remarkably little effort.

As you may have noticed, based on the size of the s11n documentation and 
web site, i'm Very Proud of s11n. Over the past 14 months it has 
evolved to do every serialization task i've thrown at it (with one 
small exception, but i'm working on solving that). It hasn't yet been 
used for network-based serialization, as far as i know, but with P i 
hope to change that.

s11n takes a slightly unconventional approach to integrating into 
projects: instead of forcing a project to use s11n's API directly, s11n 
can be told to follow a client-side API, via the use of proxies created 
via class template specializations and functors. What this essentially 
means is that we can seemlessly, for purposes of the API, merge s11n 
and P. i would be more than happy to take on this work, and to assist 
with P in any way that i can.

s11n comes with a layer called 's11nlite'. This layer provides a binding 
between the core s11n layer (which is 100% container-based - no streams 
support) and the reference implementation of an i/o layer (s11n::io). 
s11nlite contains a relatively small amount of code, encapsulated in 1 
header and 1 impl file.

Now, with a little bit of copy/paste work it would be no problem at all 
to provide a P-centric version of s11nlite, like P::s11n, which hides 
the "raw" s11n API from P applications. That is, clients would not have 
to know they're using 2 different frameworks when serializing their P 
objects via s11n. The best part is: this can be done a) without 
modifying s11n and b) without modifying (only adding to) P.

i suspect that a lot of the "utility code" in P and s11n overlap, so 
there would be a small bit of bloat there, but that could all (or 
almost all) be hidden from P::s11n users via s11n's API marshalling 
techniques.

In case you don't know: s11n recognizes 2 different approaches to 
Serializable types: those which directly implement a Serializable 
interface (save/load functions) and those which are proxied via a 
functor. Proxies allow us to, e.g., do this:

typedef std::map<std::string,std::list<int> > MapT;
MapT m;
// ... populate map ...
s11nlite::save( m, somestream );

MapT is proxied by a pair of algos which known how to de/ser std::maps. 
Likewise, std::string and std::list also have proxies. Even though we 
cannot edit those classes, s11n's proxy support allows us to treat them 
as first-class Serializable objects. The only requirements is that the 
type provide the necessary accessors/mutators so that we can 
save/restore the type's state (all std containers provide this).

What this means is that many existing P classes can be transformed into 
Serializables *without touching one line of their code*. If a type does 
not supply the nececssary API, or wants to directly implement a 
Serializable Interface, that's okay, too - s11n provides full support 
for virtual/polymorphic Serializables, including DLL-based loading of 
deserialized types, if needed.

The implication of the proxy support is that we can integrate s11n 
support into P without modifying the P code base. In fact, it could be 
supplied as an optional layer, even from another source tree. Clients 
including the P::s11n layer get serialization, those who don't, don't.

P provides some classes which have HUGE implications for s11n, 
especially the IODevice layer. With streambuf wrappers, or equivalent, 
we could de/ser from/to arbitrary pipes, using, zB, P::ProcessIO. This 
would allow, zB, piping s11n over ssh connections, over HTTP and FTP, 
etc. The uses for this are HUGE, my friends, HUGE! i experimented last 
night with pulling s11n'd data from an http server. i haven't yet 
written over http, but that should be trivial using your http code and 
a CGI/PHP script on the server. That would allow client apps to save 
over the web, bypassing most firewall-related problems of saving over 
the net.

Last night i put together a type to buffer s11n data to/from IODevice 
(or similar), and will attempt to take s11n into the realm of networks 
this weekend.

Potential caveat:
P is more portable that s11n. i have no idea if compilers on HPUX, 
Tru64, AIX, etc., support class templates well enough to use s11n. 
Since i only use Linux and Solaris, and only program using GNU tools, i 
personally can't offer much help when it comes to wide portability. i 
do avoid Linux-only code - i use only std C++ constructs, but i also 
freely take advantage of gcc's excellent standards support, and that 
means excluding older compilers.


Unrelated: build tree problem
Can someone remind me of the proper set of commands to completely 
rebuild the configure script and Makefile.in's? My autotools are newer 
than those in the build tree, and i can't get them to pick up my 
changes to Makefile.am. i haven't used autotools in 2 years or so, and 
have forgotten the various tricks. (My feelings towards autotools 
are... well, they're not nice. See toc.sf.net for why.)


i wish i had found P a lot sooner...

If you'll excuse me now... i've got to go P. ;)

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

[pclasses-devel] Re: pclasses compile warnings and error...

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

(Off-list mail, redirected to the list...)

On Saturday 18 December 2004 03:42, Marc Duerner wrote:
> > i can't find the definition of at_addr, only a forward decl in
> > pataladdr.h.
>
> Thanks, I have forwarded that to cproch. But I remember that there is
> a bug with appletalk kernel headers on debian. If you use debain try
> the CVS version and it should go away.

i just had to install the atalk-devel package and do a #define kludge in 
patalkaddr.h, then it worked. i'm on Suse 9.2, by the way.

> There is also pclasses and pclasses-devel IRC channels on freenode,
> but they arent used that much.

i tried the irc channel, but only the bot was online. i'm no a dialup 
line, so i don't use IRC that much, but it is very useful for 
programming colaboration.

i went to bed about 5 this morning after playing with P for 4 or 5 
hours. i'm very impressed with it. The only thing i'm puzzled about how 
to do is to tie a std::streambuf to a P::IODevice. Maybe it's not 
possible/desired, but if it is possible it would means a LOT for 
serialization purposes!

i will continue playing with P with it today. i got the mysql connection 
working, after some experimentation, and i would like to re-implement 
the mysql_serializer on top of the P::SQL layer. That's my project for 
this weekend. :) The current mysql-based serializer is EXTREMELY slow, 
and only supports mysql. The P db layer looks really nice, and i hope 
to be able to support any db for which there is a P driver.


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

[pclasses-devel] licensing conflict with mysql driver

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

Just FYI:

The MySQL driver is labeled as LGPL, but this cannot be: it #includes 
mysql.h, which is GPL.


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