You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(188) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(59) |
Feb
(13) |
Mar
(4) |
Apr
(1) |
May
(15) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: stephan b. <st...@s1...> - 2004-12-19 14:05:09
|
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 |
From: stephan b. <st...@s1...> - 2004-12-19 13:39:48
|
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 |
From: stephan b. <st...@s1...> - 2004-12-19 11:36:40
|
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 |
From: Christian P. <cp...@se...> - 2004-12-19 10:10:27
|
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 |
From: stephan b. <st...@s1...> - 2004-12-19 09:59:53
|
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 |
From: stephan b. <st...@s1...> - 2004-12-19 09:26:08
|
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 |
From: stephan b. <st...@s1...> - 2004-12-18 23:30:52
|
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 |
From: stephan b. <st...@s1...> - 2004-12-18 22:27:32
|
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 |
From: stephan b. <st...@s1...> - 2004-12-18 22:21:01
|
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 |
From: Tommi <t.m...@ep...> - 2004-12-18 21:45:12
|
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 |
From: stephan b. <st...@s1...> - 2004-12-18 17:26:43
|
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 |
From: stephan b. <st...@s1...> - 2004-12-18 17:17:56
|
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 |
From: stephan b. <st...@s1...> - 2004-12-18 16:06:53
|
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 |
From: Christian P. <cp...@se...> - 2004-12-18 15:10:19
|
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 |
From: Christian P. <cp...@se...> - 2004-12-18 15:08:48
|
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 |
From: Christian P. <cp...@se...> - 2004-12-18 14:58:06
|
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. |
From: Christian P. <cp...@se...> - 2004-12-18 14:45:53
|
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, |
From: Christian P. <cp...@se...> - 2004-12-18 14:39:26
|
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. ;) |
From: Christian P. <cp...@se...> - 2004-12-18 14:36:08
|
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, |
From: Christian P. <cp...@se...> - 2004-12-18 14:35:23
|
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. :) |
From: Christian P. <cp...@se...> - 2004-12-18 14:31:30
|
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, |
From: stephan b. <st...@s1...> - 2004-12-18 13:05:10
|
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 |
From: stephan b. <st...@s1...> - 2004-12-18 13:05:08
|
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 |
From: stephan b. <st...@s1...> - 2004-12-18 12:23:06
|
(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 |
From: stephan b. <st...@s1...> - 2004-12-18 02:36:33
|
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 |