Menu
▾
▴
pclasses-devel — P::Classes developer mailing-list
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: Christian P. <cp...@se...> - 2004-12-22 18:38:58
|
Hi ! Today i've imported the experimental P::Classes source tree which should become version 2.0. The code is available from sourceforge CVS in the 'pclasses2' module. The source tree has been completly reorganized: - Seperate include dirs for the various P libraries - System abstraction has been split-off from the core library The goal is to make P::Classes more consistent, more lightweight and more powerfull: - Add containers - Use smaller libraries (split-off XML stuff, Network Protocol implementations, ...) - Implement Asynchronous I/O - Add toolkit-independent, plugin-based GUI infrastructure - Cleanup and finalize Network Transparent I/O (IOManager, MimeTypes, ...) Things im currently on: - Transition of the System abstraction library. - Make Unicode String class ready to use. - SerialDevice class - NamedPipe, NamedPipeServer class There is not much in the tree right now. Old features should be transitioned from the pclasses CVS. Everyone is welcome to hack around. Greetings and Merry Christmas, Christian |
|
From: stephan b. <st...@s1...> - 2004-12-22 18:06:53
|
Yo,
Attached is a script i would like to integrate into the configure
process. It is a generator for PACKAGE_NAME-config scripts, best
explained with an example:
PACKAGE_NAME=libpclasses \
PACKAGE_VERSION=2004.12.x \
prefix=$HOME \
CLIENT_INCLUDES="-I${prefix}/include" \
CLIENT_LDADD="-L${prefix}/lib -lpcore -lpio -lpsql -lpcrypto -lpnet" \
./PACKAGE_NAME-config.sh
That reads in PACKAGE_NAME-config.in (or $1, if it exists) and creates
${PACKAGE_NAME}-config.
The generated script should be installed to PREFIX/bin and cleaned up
during distclean.
stephan@owl:~/cvs/pclasses> ./libpclasses-config
./libpclasses-config: shows information useful for configuring/building
libpclasses client applications.
Usage:
./libpclasses-config [options]
Options:
--libs : prints linker information about what libs clients should
link to
--includes : prints INCLUDES information
--prefix : prints the library's installation prefix
--version : prints the library's version
Clients who build against pclasses can use this info to easily integrate
the necessary INCLUDES and LDADD flags:
conf="$(which libpclasses-config)"
... if ! $conf then no pclasses ...
... else...
INCLUDES="$($conf --includes)"
LDADD="$($conf --libs)"
--
----- 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-21 17:51:31
|
Am i understanding this properly?
i want to implement a pio_ssh plugin. Looking at pio_file as a basis, it
would appear that i need to do something like this:
Implement IORequest_xxx_Ssh for each type.
zB:
class IORequest_xxx_Ssh ... {
open():
- open an ssh pipe and tie it to my IOHandler.
Command passed to ssh depends on type of IORequest:
GET = 'ssh -C user@host "cat /path/to/file"'
PUT = 'ssh -C user@host "cat > /path/to/file"'
and so on...
receive(buff,count):
- read count bytes from my IOHandler. This is
potentially bad if IOHandler blocks, of course.
write():
- write data to my iohandler
close():
- Send EOF to iohandler. (How? i can't write(0,0) to it, can i?)
Delete the IOH? Does this object own it?
That's not clear looking at the API.
If the handler does not own it, is there
any chance of changing IORequest(IOHandler*)
to IORequest(IOHandler&), to make ownership
obvious?
};
ssh-based virtual filesystem :). KDE implements one using the 'fish'
protocol and a clever perl script which gets uploaded to the remote
side and acts as a translater between remote commands and the local
ssh. Pretty clever stuff. i guess i could write a fish-compatible
IORequest, instead, since that's an established protocol.
Anyway - am i understanding the architecture properly? Are there any
pitfalls i need to be aware of?
--
----- 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-21 17:02:36
|
As of about 20 minutes ago: ps11n now supports 7 data flavours and 4 data transport layers: the usual streams and files, and now http and ftp. Convert file in.paren using s11n over ftp: stephan@owl:~/cvs/s11n.net/ps11n/src> s11nconvert -f in.paren -o ftp://stephan:password@localhost/x.s11n -s pio --pio-serializer=funxml stephan@owl:~/cvs/s11n.net/ps11n/src> cat ~/x.s11n <!DOCTYPE SerialTree> <somenode class="NoClass"> <<snip>> </somenode> Loading the data over ftp: stephan@owl:~/cvs/s11n.net/ps11n/src> s11nconvert -f ftp://stephan:password@localhost/x.s11n -s funtxt -S pio #SerialTree 1 somenode class=NoClass { <<snip>> } Reminder: s11nconvert is just a convenience tool for testing here. Calling the following from C++ would also work: P::s11n::save( myobj, "ftp://user:pass@host/path" ); MyT * obj = P::s11n::load_serializable<MyT>( "ftp://..." ); Getting over http now works using the same Serializer: s11nconvert -f http://s11n/P.s11n -s compact -S pio 51191011 <<snip>> 51190000 Writing over http "might" work - i don't yet know because i don't know how to tell the http side to react accordingly. (@Christian - any tips on how to set up the http side of a IORequest_Put?) Transparent network support is pretty frigging cool. The IOManager allows us to handle http and ftp with a single Serializer class, and that this one can support any protocols which P::IOManager handles. file:// URLs "should" work, but there's aparently a bug in the file:// handler: s11nconvert -f file://$HOME/x.s11n -s compact -S pio --pio-verbose PIOSerializer.cpp:42 : pio-verbose mode is on. PIOSerializer.hpp:61 : deserialize() from [file:///home/stephan/x.s11n]... PIOSerializer.hpp:144 : NetDbError: pnetdb.cpp:343:static P::NetDb::ServiceEntry P::NetDb::serviceByName(const std::string&, const std::string&): Could not resolve service by name: Resolver Error 0 (no error) PIOSerializer.hpp:64 : deserialize(): read_content() failed :( s11nconvert error: Error loading node tree from input stream! 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: Christian P. <cp...@se...> - 2004-12-21 16:26:32
|
Am Dienstag 21 Dezember 2004 16:18 schrieb stephan beal: > Yo again, > > i'm trying to enable the tracing/debuggering features in P, but no luck. > i've defined _DEBUG, undefined NO_DEBUG and NDEBUG... what else must i > do? i've looked through the PTRACE macro, and i seem to be picking up > the TraceLogger, but no /tmp/p.... (the file TraceLogger writes) exists > after my app exits. > > Any hints? Forget the Tracing in the CVS. Infrastrucure is there and working, but no class really makes use of it. Anyway, you must configure P with "./configure --enable-debug". Your application should have defined _DEBUG to not have tracing going to nirvana. |
|
From: stephan b. <st...@s1...> - 2004-12-21 15:20:07
|
Yo again, i'm trying to enable the tracing/debuggering features in P, but no luck. i've defined _DEBUG, undefined NO_DEBUG and NDEBUG... what else must i do? i've looked through the PTRACE macro, and i seem to be picking up the TraceLogger, but no /tmp/p.... (the file TraceLogger writes) exists after my app exits. Any hints? -- ----- 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-21 14:54:30
|
On Tuesday 21 December 2004 15:05, Christian Prochnow wrote: > > i assume it's the same problem as the IOManager example not being > > able to find http handler. > > Ahh ok, now i got you. The 'Process' class only supports spawning > local processes and reading/writing to their stdin/stdout. I would > like to leave this unchanged. Process is a low-level system > abstraction class, which should be as small as possible. > Instead i would implement a IOPlugin "process://" which could do the > job. That way you could do every IO with the IOManager. i agree - this should be based on the IOMgr layer, not Process itself. > > In eshell, before an input command is passed off to a client eshell > > does var and alias expansion on it, plus expansions provided by > > wordexp (man 3). > > Great! I would love it. All i need is write access to the tree... :) BTW: i'm currently working off of the CVS copy from SF. Is that the one you're refactoring, or is that somewhere else? Last night, once i finally realized there was a DLL/symbol problem, i got the IOMgr working (again) on my box. With that i'll be able to implement a single class which can dispatch load/save over http/ftp/file URLs (though the file:// handler always fails with something like "cannot resolve service name"). That is, any handler supported by IOManager will inherently be available as a serialization channel for P::s11n. Pretty cool, i think. :) Speaking of DLL symbols: you can do DLL/plugin registration and loading without reading a single symbol from a DLL. See http://s11n.net/papers/#classloading_cpp The approach described there introduces compile-time, cast-free, 100% type safety for types loaded from DLLs (on the surface that sounds impossible, but it is actually a natural side-effect of templates). -- ----- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
|
From: Christian P. <cp...@se...> - 2004-12-21 14:04:23
|
Am Montag 20 Dezember 2004 22:12 schrieb stephan beal:
> On Monday 20 December 2004 12:52, Christian Prochnow wrote:
> > > Process proc("http://...");
> > > proc.addArg( "foo=bar" );
> >
> > This should already work. Have a look into 'demo/process.cpp'.
>
> It works with bins for me, but not with URLs:
>
> Process proc("http://s11n/");
>
> creating process
> I/O error: No such file or directory
>
> i assume it's the same problem as the IOManager example not being able
> to find http handler.
Ahh ok, now i got you. The 'Process' class only supports spawning local
processes and reading/writing to their stdin/stdout. I would like to leave
this unchanged. Process is a low-level system abstraction class, which should
be as small as possible.
Instead i would implement a IOPlugin "process://" which could do the job.
That way you could do every IO with the IOManager.
> > For accessing process environment, a simple ProcessEnv class exists.
>
> i'd like to add funcs to do env ${var} expansion on strings. e.g.:
>
> std::string s = myenv.parseVars( inputstring );
>
> i've got the code for it, just need to plug it in to the tree. With that
> support we can do things like: open_file( "${HOME}/.myconf" ).
>
> In eshell, before an input command is passed off to a client eshell does
> var and alias expansion on it, plus expansions provided by wordexp (man
> 3).
Great! I would love it.
> See ya!
Greetings,
Christian
|
|
From: Christian P. <cp...@se...> - 2004-12-21 13:54:17
|
Am Dienstag 21 Dezember 2004 00:51 schrieb stephan beal: > You're not gonna believe what it was: > > Last weekend i reported that i had to link directly against psq_mysql.so > to avoid an undef'd BigInt symbol. THAT is what caused the IOManager to > not find the factories. i can't explain it, but i can reproduce it: > removing that .so from my linking fixes the problem, adding it back on > breaks it again. It's clear to me. Libraries linked against your app binary export their symbols "global". Plugins are loaded without overwriting "global" (~RTLD_GLOBAL) bindings. When shared libraries are loaded, colliding symbols are not rebound. So the actual problem is that your binary has a global symbol "P_plugins", and every plugin you dynamically load also has this symbol exported, which not gets overwritten. > WEIRD... > > My client fails with these link args: > -ls11n -lpcore -lpcrypto -lpio -lpnet -lpsql > -lps11n /home/stephan/cvs/inst/lib/pclasses/psql_mysql.so > > piomanager.cpp:40 : IOManager loading plugins from . > [/home/stephan/cvs/inst/lib/pclasses]. > piomanager.cpp:50 : file??? 0 > piomanager.cpp:51 : ftp??? 0 > piomanager.cpp:52 : http??? 0 > piomanager.cpp:127:P::IOHandler* P::IOManager::findCreateHandler(const > std::string&): No handler for protocol 'http' found. > > But works with these: > -ls11n -lpcore -lpcrypto -lpio -lpnet -lpsql -lps11n > > piomanager.cpp:40 : IOManager loading plugins from . > [/home/stephan/cvs/inst/lib/pclasses]. > piomanager.cpp:50 : file??? 0x808b860 > piomanager.cpp:51 : ftp??? 0x808fab8 > piomanager.cpp:52 : http??? 0x808fb08 > test.cpp:75 : Buffered 1042 bytes from [http://localhost/P.s11n]. |
|
From: stephan b. <st...@s1...> - 2004-12-20 23:52:49
|
You're not gonna believe what it was: Last weekend i reported that i had to link directly against psq_mysql.so to avoid an undef'd BigInt symbol. THAT is what caused the IOManager to not find the factories. i can't explain it, but i can reproduce it: removing that .so from my linking fixes the problem, adding it back on breaks it again. WEIRD... My client fails with these link args: -ls11n -lpcore -lpcrypto -lpio -lpnet -lpsql -lps11n /home/stephan/cvs/inst/lib/pclasses/psql_mysql.so piomanager.cpp:40 : IOManager loading plugins from . [/home/stephan/cvs/inst/lib/pclasses]. piomanager.cpp:50 : file??? 0 piomanager.cpp:51 : ftp??? 0 piomanager.cpp:52 : http??? 0 piomanager.cpp:127:P::IOHandler* P::IOManager::findCreateHandler(const std::string&): No handler for protocol 'http' found. But works with these: -ls11n -lpcore -lpcrypto -lpio -lpnet -lpsql -lps11n piomanager.cpp:40 : IOManager loading plugins from . [/home/stephan/cvs/inst/lib/pclasses]. piomanager.cpp:50 : file??? 0x808b860 piomanager.cpp:51 : ftp??? 0x808fab8 piomanager.cpp:52 : http??? 0x808fb08 test.cpp:75 : Buffered 1042 bytes from [http://localhost/P.s11n]. -- ----- 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-20 22:18:07
|
Yo, again!
Having to pass a SourceInfo is pretty laestig in client code... but it
IS a really clever idea, once you realize the P_SOURCEINFO macro is
there to help it's not bad. However, i figure that since we HAVE the
SourceInfo, why not USE it?
Here's a proposed change to BaseError. None of the interface changes.
The ctor prefixes the SourceInfo to the 'what' string. The result
calling what() now includes the file, line and function name:
BaseError: piomanager.cpp:99:P::IOHandler*
P::IOManager::findCreateHandler(const std::string&): No handler for
protocol found.
One could argue that we shouldn't do memory allocation like this from
BaseError, but allocation errors, and errors of that severity, happen
via the std::exceptions, not via BaseError. Also, on Linux malloc()
"never fails", so it's theoretically impossible to know if there is
more memory without counting it yourself (see man malloc on a Linux
box, in the BUGS section).
Here's the proposed code, from pexception.h:
#include <sstream>
inline BaseError(const char* _what, const SourceInfo& _si) throw()
: m_what(_what), m_sourceInfo(_si)
{
std::ostringstream os;
os << _si.file() << ":"<<_si.line()<<":" << _si.func()<<": "
<< _what;
m_what = os.str();
}
inline const char* what() const throw()
{ return m_what.c_str(); }
std::string m_what;
--
----- 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-20 21:13:15
|
On Monday 20 December 2004 12:52, Christian Prochnow wrote:
> > Process proc("http://...");
> > proc.addArg( "foo=bar" );
>
> This should already work. Have a look into 'demo/process.cpp'.
It works with bins for me, but not with URLs:
Process proc("http://s11n/");
creating process
I/O error: No such file or directory
i assume it's the same problem as the IOManager example not being able
to find http handler.
> For accessing process environment, a simple ProcessEnv class exists.
i'd like to add funcs to do env ${var} expansion on strings. e.g.:
std::string s = myenv.parseVars( inputstring );
i've got the code for it, just need to plug it in to the tree. With that
support we can do things like: open_file( "${HOME}/.myconf" ).
In eshell, before an input command is passed off to a client eshell does
var and alias expansion on it, plus expansions provided by wordexp (man
3).
See ya!
--
----- st...@s1... http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts
|
|
From: stephan b. <st...@s1...> - 2004-12-20 16:33:02
|
On Monday 20 December 2004 12:52, Christian Prochnow wrote: > > proc.start(...); // some flags might not be possible/appropriate > > ProcessIO * io = proc.processIO(); > > > > Maybe that already works? If so, please point me in the proper > > direction. > > This should already work. Have a look into 'demo/process.cpp'. Excellent :). > > - Add support similar to s11n's acme::argv_parser class. This > > allows all client apps to read the args passed in to main(), but ... > > me. > > Would you like to implement argv parsing into the experimental code > base? Absolutely. i've got a bare-bones argv parser i've been using for 2+ years, which i could easily pull in. Once you've got the new CVS set up i'll start dumping code in :). > > For accessing process environment, a simple ProcessEnv class exists. Oh, great! That'll do! > > - Add an optional module for reading input from the console, using ... > > UI things (text and graphical), until now, we're not important for > us. I used the framework for programming server software for a Bank > in Berlin, Germany. Only UI that the server software got, was a > telnet interface ;-) LOL! i agree that UI is extremely low priority. My own ideas about it are more for experimentation and the joy of hacking, not because i really want to implement a full UI-neutral UI. > However, this should change and i would like to see an > Toolkit-independent, plugin-based GUI infrastructure for P. i've been tinkering, on paper, with this idea for a year or two, as well. Tasks which i'd like to sign up for regarding P: - Adding API docs. i'm pedantic about API documentation, and would like to start filling out the P API docs. - argv parser. - serialization support for the P classes which can reasonably support serialization. The ground-work is essentially done, now it's time to add save/load support for specific P types. e.g., i'd like to be able to save a ResultSet (though restoring it to an actual ResultSet isn't feasible, i think, because of db connection persistency issues). - Fix up mysql driver to support text/blob fields (using fix posted this weekend). - Writing a lib manual. As you may have noticed, i like to write (s11n's lib manual is now 67 pages, not including API docs), and i think P has a lot of good things to write about. - Fix up some of the abort()-calling code (throwing undeclared exceptions or simply calling 'throw' will do this). i submitted a bug or two to SF today for URL to fix 2 of these. Please let me know when your dev tree is online so i can start hacking away :). The P toolkit has a fantastic set of classes, and they need some evangelism and love! You've got regex classes :) but i only found them by accident (they don't show up on all the doxygen-generated pages, and there is no demo app for them). Take care, -- ----- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
|
From: stephan b. <st...@s1...> - 2004-12-20 16:23:18
|
On Monday 20 December 2004 12:46, Christian Prochnow wrote: > > PSqlSerializer.cpp:68 : Error from > > P::Classes: /home/stephan/cvs/inst/lib/pclasses/psql_mysql.so: > > undefined symbol: _ZTIN1P9SQLBigIntE > > Is this problem already gone? Which platform are you using ? > Did the configure script correctly detect the "long long" type ? > SQLBigInt is a 64bit integer type. i got rid of it by explicitely linking my client to psql_mysql.so. Since that worked i haven't looked for another workaround just 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-20 16:21:03
|
On Monday 20 December 2004 12:42, Christian Prochnow wrote:
...
> <code>
> CriticalSection::Lock lck(cs);
> for(list<String>::iterator i = l.begin(); i != l.end(); i++)
> {
> /* .. */
> }
> </code>
...
> What do you think ?
That's the type of detail i was looking for. :) Thanks :)
> Many c++ programmers don't like the idea of own container
> implementations - instead one would stick with STL ones, which are,
> in my opinion not powerfull enough.
i was tinkering last night with a container locker: a class which gives
you a handle to a given container and locks requests until you give the
container back to it. i dunno if that's feasible, but it sounds like
it'd work. Again, i have practically no real experience with MT
environments, i only know some of the theory.
> Would you like to have a copy of the experimental code ?
> I could setup a temporary cvs server for it.
Yes!
:) :) :) :)
i've got some patches in my local copy of the CVS tree, too.
--
----- 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-20 11:52:06
|
Am Sonntag 19 Dezember 2004 14:38 schrieb stephan beal:
> Random thoughts:
>
> - Add a more abstract process layer, such that we can do something like
> this:
> Process proc("http://...");
> proc.addArg( "foo=bar" );
> ...
> proc.start(...); // some flags might not be possible/appropriate
> ProcessIO * io = proc.processIO();
>
> Maybe that already works? If so, please point me in the proper
> direction.
This should already work. Have a look into 'demo/process.cpp'.
> - Add support similar to s11n's acme::argv_parser class. This allows all
> client apps to read the args passed in to main(), but unfortunately
> requires that main() call either p_init( argc, argv ) or
> acme::argv_parser::args(argc,argv). Clients later call
> acme::argv_parser::args() to get the args. This is used in s11n by
> DLLs, so that they can plug in help options to a client's --help
> options. (See http://s11n.net/s11nconvert/ and grep for mysql-db,
> for an example.)
> The exact args parser used is unimportant to me, but having access to
> argv from non-main() client code has often been convenient for me.
Would you like to implement argv parsing into the experimental code base?
> - An OO interface into the system environment, a-la eshell's env()
> function, which returns an acme::environment objects. Having a
> framework-level interface to it eases de/serialization of the data (for
> sessions support, etc) and allows things like toggling
> read/writability, logging, saving the env in another data structure,
> etc.
For accessing process environment, a simple ProcessEnv class exists.
> - Add an optional module for reading input from the console, using
> whatever input interface is available. See
> http://s11n.net/download/#readline_cpp, which supports stdin, GNU
> Readline or BSD editline. i realize this isn't a truly generic option
> for the framework, but it would allow really easy building of
> shell-like apps. This feature, combined with the next one, gives most
> shell-like apps all they need...
UI things (text and graphical), until now, we're not important for us.
I used the framework for programming server software for a Bank in Berlin,
Germany. Only UI that the server software got, was a telnet interface ;-)
However, this should change and i would like to see an Toolkit-independent,
plugin-based GUI infrastructure for P.
> - Support for built-in functions which can be called by name, like
> eshell's support. This would primarily be of interest for shell-like
> apps, but could be used to provide some interesting features for
> controlling the framework from client code. Consider these calls:
> P::dispatch_command( "sleep 20" ); // dispatches to built-in
> P::dispatch_command( "konqueror http://..." ); // external app
> P::dispatch_command( "http://..." ); // uses protocol handler
> P::dispatch_command( "p-internal run-garbage-collector" );
> Then we can wrap the whole back-end process/thread management behind a
> single interface. This is the main feature eshell provides, but i think
> the feature is suitable for a wide range of apps, not just shell-like
> ones.
>
>
> Except for the Process stuff, i've got code to do all of this. i would
> need to pull it into the P tree, in the appropriate modules, and sed it
> to conform to P's naming conventions, but it would otherwise be trivial
> to do.
Regards,
Christian
|
|
From: Christian P. <cp...@se...> - 2004-12-20 11:46:40
|
Am Sonntag 19 Dezember 2004 15:04 schrieb stephan beal:
> 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. :(
We should be better than C# and CommonC++ :-)
I will implement it in experimental code base.
> 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.
I will have a look at it.
> :)
Regards,
Christian
|
|
From: Christian P. <cp...@se...> - 2004-12-20 11:45:31
|
Am Sonntag 19 Dezember 2004 15:32 schrieb stephan beal:
> i'm stumped on this one:
>
> i can build and run demo/sql.cpp from the source tree, but when a client
> lib i build in another tree tries to do the same stuff, namely open
> psql_mysql.so, i get an undef symbol:
>
> factory.addPlugin("psql_mysql.so");
> ...
>
> PSqlSerializer.cpp:68 : Error from
> P::Classes: /home/stephan/cvs/inst/lib/pclasses/psql_mysql.so:
> undefined symbol: _ZTIN1P9SQLBigIntE
Is this problem already gone? Which platform are you using ?
Did the configure script correctly detect the "long long" type ?
SQLBigInt is a 64bit integer type.
> i'm linking against all of the P libs except the plugins:
>
> stephan@owl:~/cvs/s11n.net/ps11n/src> ldd psql_serializer.so
> ...
> libpcore.so.1 => /home/stephan/cvs/inst/lib/libpcore.so.1
> (0x400ce000)
> libpcrypto.so.1 => /home/stephan/cvs/inst/lib/libpcrypto.so.1
> (0x40238000)
> libpio.so.1 => /home/stephan/cvs/inst/lib/libpio.so.1
> (0x40245000)
> libpnet.so.1 => /home/stephan/cvs/inst/lib/libpnet.so.1
> (0x4025c000)
> libpsql.so.1 => /home/stephan/cvs/inst/lib/libpsql.so.1
> (0x40292000)
> libps11n.so => ./libps11n.so (0x402a4000)
> ...
>
> If i add psql_mysql.so to my links it works, but i shouldn't have to do
> this from the client side.
>
> i also tried opening the DLL with own dll opener, and get the same
> error:
>
> class_loader.cpp:110 : Error opening
> DLL: /home/stephan/cvs/inst/lib/pclasses/psql_mysql.so: undefined
> symbol: _ZTIN1P9SQLBigIntE
>
>
> Any ideas where to look to solve this?
|
|
From: Christian P. <cp...@se...> - 2004-12-20 11:43:52
|
Am Sonntag 19 Dezember 2004 16:49 schrieb stephan beal:
> This does this trick, in fetch():
>
> default:
> {
> if(field_val)
> {
> std::string buff( field_val, field_val +
> field->length );
> val = new SQLString(buff.c_str());
> }
> else
> {
> val = new SQLString();
> }
> }
Cool. However i would like to add an SQLUnknown class for unsupported SQL
fields. TEXT in mysql driver should become a SQLString.
>
>
> (also #include <string>)
>
> IMO this is suitable for time fields, as well, because they're all just
> strings in the end.
>
> Now s11n has a psql-powered db layer. In theory it'll support any
> compatible db layer, configurable via command-line args to s11nconvert.
>
> Convert file to db:
>
> stephan@owl:~/cvs/s11n.net/ps11n/src> s11nconvert -f in.s11n -s psql -o
> one --psql-verbose
> PSqlSerializer.cpp:42 : psql-verbose mode is on.
> PSqlSerializer.cpp:52 : Proxy Serializer = [compact].
> PSqlSerializer.cpp:65 : Connecting to database [localhost]...
> PSqlSerializer.hpp:133 : serialize(node,[one])...
> PSqlSerializer.hpp:144 : driver=mysql, @0x8070be0
>
> Pull object from db:
>
> stephan@owl:~/cvs/s11n.net/ps11n/src> s11nconvert -S psql -f one -s
> expat --psql-verbose
> PSqlSerializer.cpp:42 : psql-verbose mode is on.
> PSqlSerializer.cpp:52 : Proxy Serializer = [compact].
> PSqlSerializer.cpp:65 : Connecting to database [localhost]...
> PSqlSerializer.hpp:82 : deserialize(one) from
> mysql://stephan:xxxx@localhost/ps11n
> PSqlSerializer.hpp:88 : driver=mysql, @0x8070c10
> PSqlSerializer.hpp:110 : Buffered 191 bytes.
> PSqlSerializer.hpp:72 : Deser from stream...
> <!DOCTYPE s11n::io::expat_serializer>
> <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>
|
|
From: Christian P. <cp...@se...> - 2004-12-20 11:42:04
|
Am Montag 20 Dezember 2004 02:27 schrieb stephan beal:
> Yo again,
>
> i'm looking through the thread docs, and a couple things aren't clear to
> me:
>
> - What is the conceptual difference between ThreadJob and Thread? It
> seems that ThreadJob is a simplified form of Thread?
ThreadJob objects are used by the ThreadPool to do the actual work that is
enqueued to the ThreadPool.
> - i think ThreadJob's ctor is broken:
> ThreadJob(ThreadPool *p)
> Subclasses of ThreadJob which call this ctor will be queued into p
> before they are actually finished construction, which means they may
> (?) begin execution before they are completely finished constructing.
You're right ... it's racy :-(
Under high load (an app that spawns hundred of Threads) the Thread class is
also racy. However i've written a new, simple, more lightwight Thread class
for the use in the next major version.
> What i want to do is be able to start N apps in my framework and keep
> track of them in some container. When a thread dies (app is closed)
> i'll need to update my container, which i can do via Thread::final()
> (it would seems) and by locking the container.
>
>
> What i'm not clear on is whether i should use Thread or ThreadJob as a
> basis for doing this. Also, what would be the most straightforward way
> to lock a container using P's API? (i have almost no experience with
> MT, mutexes, etc.)
I would use Thread in this case.
For locking you could exclusive the access to the container by using a
CriticalSection, Mutex, RWLock or Semaphore. Which one you should use depends
on your needs.
<code>
list<String> l;
CriticalSection cs;
CriticalSection::Lock lck(cs);
l.push_back('hallo welt');
</code>
<code>
CriticalSection::Lock lck(cs);
for(list<String>::iterator i = l.begin(); i != l.end(); i++)
{
/* .. */
}
</code>
CriticalSection::Lock is a Lock guard, which locks the CriticalSection upon
construction, and releases it when destructing.
The missing of thread-safe containers are the reason why i would like to
implement Containers into P. I have some nice ideas which, when done right,
could automatically Lock the Container if you're iterating over it. Locking
is a huge overhead when not using MT, so i decided to add LockTraits to P
which will allow you to instantiate Container with and without locking.
Imagine the following:
<code>
List<String, RWLock> l;
l.push_back('hallo welt') /* acquires a WriteLock before pushing back */
for(list<String>:const_iterator i = l.begin(); i != l.end(); i++)
/* aquires a ReadLock */
{
/* .. */
}
for(list<String>:iterator i = l.begin(); i != l.end(); i++)
/* aquires a WriteLock */
{
/* .. */
}
</code>
You could also write:
List<String,Mutex> l; (uses a Mutex to do the locking)
or:
List<String> l; (which uses no locking at all)
What do you think ?
Many c++ programmers don't like the idea of own container implementations -
instead one would stick with STL ones, which are, in my opinion not powerfull
enough.
Would you like to have a copy of the experimental code ?
I could setup a temporary cvs server for it.
Have a nice day,
Christian
|
|
From: stephan b. <st...@s1...> - 2004-12-20 01:28:33
|
Yo again, i'm looking through the thread docs, and a couple things aren't clear to me: - What is the conceptual difference between ThreadJob and Thread? It seems that ThreadJob is a simplified form of Thread? - i think ThreadJob's ctor is broken: ThreadJob(ThreadPool *p) Subclasses of ThreadJob which call this ctor will be queued into p before they are actually finished construction, which means they may (?) begin execution before they are completely finished constructing. What i want to do is be able to start N apps in my framework and keep track of them in some container. When a thread dies (app is closed) i'll need to update my container, which i can do via Thread::final() (it would seems) and by locking the container. What i'm not clear on is whether i should use Thread or ThreadJob as a basis for doing this. Also, what would be the most straightforward way to lock a container using P's API? (i have almost no experience with MT, mutexes, etc.) Ideas? -- ----- 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 22:24:23
|
Yo again! i'm working on re-implementing eshell on top of P (pshell, of course), and i've come across a couple usability problems: - AboutData cannot be default-constructed. This means i can't currently deserialize it because i cannot classload it without installing a factory which creates a bogus one by passing invalid info to the ctor. This change implies that various mutators have to be added, like copyright(string), etc. - Having non-const overloads of the list<> accessors would make de/serialization a snap: serialize_subnode( mynode, "authors", this->about().authors() ); deserialize_subnode( mynode, "authors", this->about().authors() ); - SimpleApp also can't be default constructed. Same prob as above: can't classload it without adding a completely bogus factory, plus creating a bogus AboutData to pass to that object's ctor. Also, how about a protected: AboutData & about(); (non-const) so that subclasses can modify/serialize that object. Are these feasible? -- ----- 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 15:51:01
|
This does this trick, in fetch():
default:
{
if(field_val)
{
std::string buff( field_val, field_val +
field->length );
val = new SQLString(buff.c_str());
}
else
{
val = new SQLString();
}
}
(also #include <string>)
IMO this is suitable for time fields, as well, because they're all just
strings in the end.
Now s11n has a psql-powered db layer. In theory it'll support any
compatible db layer, configurable via command-line args to s11nconvert.
Convert file to db:
stephan@owl:~/cvs/s11n.net/ps11n/src> s11nconvert -f in.s11n -s psql -o
one --psql-verbose
PSqlSerializer.cpp:42 : psql-verbose mode is on.
PSqlSerializer.cpp:52 : Proxy Serializer = [compact].
PSqlSerializer.cpp:65 : Connecting to database [localhost]...
PSqlSerializer.hpp:133 : serialize(node,[one])...
PSqlSerializer.hpp:144 : driver=mysql, @0x8070be0
Pull object from db:
stephan@owl:~/cvs/s11n.net/ps11n/src> s11nconvert -S psql -f one -s
expat --psql-verbose
PSqlSerializer.cpp:42 : psql-verbose mode is on.
PSqlSerializer.cpp:52 : Proxy Serializer = [compact].
PSqlSerializer.cpp:65 : Connecting to database [localhost]...
PSqlSerializer.hpp:82 : deserialize(one) from
mysql://stephan:xxxx@localhost/ps11n
PSqlSerializer.hpp:88 : driver=mysql, @0x8070c10
PSqlSerializer.hpp:110 : Buffered 191 bytes.
PSqlSerializer.hpp:72 : Deser from stream...
<!DOCTYPE s11n::io::expat_serializer>
<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>
--
----- 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 15:06:39
|
The problem was that i'm using a 'text' field, and the driver doesn't support it. Changing the db field to a varchar works, but only allows serialization of very small objects :/. -- ----- 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 14:34:04
|
i'm stumped on this one:
i can build and run demo/sql.cpp from the source tree, but when a client
lib i build in another tree tries to do the same stuff, namely open
psql_mysql.so, i get an undef symbol:
factory.addPlugin("psql_mysql.so");
...
PSqlSerializer.cpp:68 : Error from
P::Classes: /home/stephan/cvs/inst/lib/pclasses/psql_mysql.so:
undefined symbol: _ZTIN1P9SQLBigIntE
i'm linking against all of the P libs except the plugins:
stephan@owl:~/cvs/s11n.net/ps11n/src> ldd psql_serializer.so
...
libpcore.so.1 => /home/stephan/cvs/inst/lib/libpcore.so.1
(0x400ce000)
libpcrypto.so.1 => /home/stephan/cvs/inst/lib/libpcrypto.so.1
(0x40238000)
libpio.so.1 => /home/stephan/cvs/inst/lib/libpio.so.1
(0x40245000)
libpnet.so.1 => /home/stephan/cvs/inst/lib/libpnet.so.1
(0x4025c000)
libpsql.so.1 => /home/stephan/cvs/inst/lib/libpsql.so.1
(0x40292000)
libps11n.so => ./libps11n.so (0x402a4000)
...
If i add psql_mysql.so to my links it works, but i shouldn't have to do
this from the client side.
i also tried opening the DLL with own dll opener, and get the same
error:
class_loader.cpp:110 : Error opening
DLL: /home/stephan/cvs/inst/lib/pclasses/psql_mysql.so: undefined
symbol: _ZTIN1P9SQLBigIntE
Any ideas where to look to solve this?
--
----- st...@s1... http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts
|
