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-31 14:35:28
|
On Friday 31 December 2004 15:23, Christian Prochnow wrote: > Current CVS version gives this error: > > /home/cproch/src/pclasses2/src/Util/SimpleArgvParser.cpp:10: error: ` > P::Util::SimpleArgvParser::SimpleArgvParser()' is private > /home/cproch/src/pclasses2/include/pclasses/Phoenix.h:188: error: > within this context > i fixed that this morning. The commit is going out now. -- ----- 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-31 14:23:16
|
Current CVS version gives this error: /home/cproch/src/pclasses2/src/Util/SimpleArgvParser.cpp: In constructor ` P::Phoenix<BaseType, ContextType, InitializerType>::Phoenix() [with BaseType = P::Util::SimpleArgvParser, ContextType = P::Util::SimpleArgvParserSharingContext, InitializerType = P::DefaultPhoenixInitializer]': /home/cproch/src/pclasses2/include/pclasses/Phoenix.h:161: instantiated from `static BaseType& P::Phoenix<BaseType, ContextType, InitializerType>::instance() [with BaseType = P::Util::SimpleArgvParser, ContextType = P::Util::SimpleArgvParserSharingContext, InitializerType = P::DefaultPhoenixInitializer]' /home/cproch/src/pclasses2/src/Util/SimpleArgvParser.cpp:122: instantiated from here /home/cproch/src/pclasses2/src/Util/SimpleArgvParser.cpp:10: error: ` P::Util::SimpleArgvParser::SimpleArgvParser()' is private /home/cproch/src/pclasses2/include/pclasses/Phoenix.h:188: error: within this context Greetings Am Freitag 31 Dezember 2004 03:45 schrieb stephan beal: > Update of /cvsroot/pclasses/pclasses2/src/Util > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv16410/src/Util > > Modified Files: > SimpleArgvParser.cpp > Log Message: > Added API docs. > Fixed (argc,argv) ctor to actually use it's args. > Values may now be quoted strings. > > Index: SimpleArgvParser.cpp > =================================================================== > RCS file: /cvsroot/pclasses/pclasses2/src/Util/SimpleArgvParser.cpp,v > retrieving revision 1.2 > retrieving revision 1.3 > diff -u -d -r1.2 -r1.3 > --- SimpleArgvParser.cpp 31 Dec 2004 02:19:37 -0000 1.2 > +++ SimpleArgvParser.cpp 31 Dec 2004 02:45:09 -0000 1.3 > @@ -1,7 +1,9 @@ > #include <vector> > #include <list> > #include <pclasses/Util/SimpleArgvParser.h> > +#include <pclasses/Util/StringTool.h> > #include <pclasses/Phoenix.h> > + > namespace P { namespace Util { > > SimpleArgvParser::SimpleArgvParser() > @@ -9,13 +11,17 @@ > } > SimpleArgvParser::SimpleArgvParser( int argc, char ** argv ) > { > - > + this->parse( argc, argv ); > } > > SimpleArgvParser::~SimpleArgvParser() > { > } > > + /** > + Internal helper function to change a char** into an STL > + container of strings. > + */ > template <typename ListT> > size_t toList( ListT & tgt, int argc, char ** argv ) > { > @@ -25,7 +31,7 @@ > } > } > > - std::string strip_dashes( const std::string & s ) > + std::string internal_strip_leading_dashes( const std::string & s ) > { > if( 0 != s.find( "-" ) ) return s; > std::string::size_type first = s.find_first_not_of( "-" ); > @@ -52,12 +58,13 @@ > k = alist[at]; > if( IS_ARG(k) ) > { > - k = strip_dashes( k ); > + k = internal_strip_leading_dashes( k ); > > if( std::string::npos != (eqat = k.find( '=' )) ) > { > ++ret; > nextarg = k.substr( eqat+1 ); > + ::P::StringTool::normalizeString( nextarg ); // remove > leading/trailing quotes k = k.substr( 0, eqat ); > this->set( k, nextarg ); > continue; > @@ -78,11 +85,16 @@ > else > { > ++ret; > + ::P::StringTool::normalizeString( nextarg ); // remove > leading/trailing quotes this->set( k, nextarg ); > skipnext = true; > continue; > } > } > + else > + { > + // do nothing - we're not interesting in non-dashed args. > + } > } > return ret; > #undef IS_ARG > @@ -99,9 +111,15 @@ > return s; > } > > + //! Internal marker class > + struct SimpleArgvParserSharingContext {}; > + > SimpleArgvParser & SimpleArgvParser::args() > { > - return ArgvPhoenix::instance(); > + return ::P::Phoenix< > + SimpleArgvParser, > + SimpleArgvParserSharingContext > + >::instance(); > } > > > > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > pclasses-cvs mailing list > pcl...@li... > https://lists.sourceforge.net/lists/listinfo/pclasses-cvs |
From: stephan b. <st...@s1...> - 2004-12-30 20:50:18
|
One of those "silly waste of time" build features... Try: ./configure --enable-ccdv [other args...] That will wrap a small filter app around the default compiler/linker calls, such that the output it formatted to be "user friendly". The one disadvantage is that gcc's colored error messages lose their color through this filter (IIRC). i think it only works on ansi-capable terminals, but i'm not sure. Enabling it does not noticably change the build time (not even by 1 second on my box). i was considering enabling this by default and using --disable-ccdv to turn it off (which already works). The intention is to make the build "friendlier" for dist clients, but allow us to see the whole compile/link args. grep for 'ccdv' in configure.pclasses2 for where this is handled by configure. -- ----- 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-30 20:22:27
|
Which does everyone prefer: a) ./test/* is built as part of $(top_srcdir) 'all'. b) ./test/* does not build automatically. Requires explicite make in that subdir or 'make bins' (or similar). i ask because they take up 1/3rd of the build time (30 seconds of 90 on my box). ??? Then again, if you're using the AT tree this change wouldn't affect you. -- ----- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
From: <gj...@fh...> - 2004-12-30 16:43:53
|
if you wanna do testing i can plug my laptop to the net and give you a shell so you can try fixing it directly at the 64bit box if you're interested, you'll find me in #pclasses // gjehle Quoting stephan beal <st...@s1...>: > On Thursday 30 December 2004 13:59, gj...@fh... wrote: > > g++ -pipe -fPIC -I. -I../include -O2 -DNDEBUG=1 -c -o > > There's a much bigger problem here: > > Compiling with (-O2 -DNDEBUG=1) causes a segfault in s11n during > deserialize<>() (which i of course can't debug because it's not a debug > build). i can reproduce the error by switching between the 2 flag sets, > doing a distclean/reconfigure, rebuilding, and running ./test/s11nTest. > > s11n does no debug-dependent checking, so this problem scares me - if > it's a compiler error (which i suspect) then i have absolutely no > control over it. > > i need to go try this out in the s11n.net tree! i've always compiled > with (-Werror -Wall -g), so i would never have seen this. > > -- > ----- st...@s1... http://s11n.net > "...pleasure is a grace and is not obedient to the commands > of the will." -- Alan W. Watts > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > pclasses-devel mailing list > pcl...@li... > https://lists.sourceforge.net/lists/listinfo/pclasses-devel > |
From: stephan b. <st...@s1...> - 2004-12-30 14:22:28
|
On Thursday 30 December 2004 13:59, gj...@fh... wrote: > g++ -pipe -fPIC -I. -I../include -O2 -DNDEBUG=1 -c -o There's a much bigger problem here: Compiling with (-O2 -DNDEBUG=1) causes a segfault in s11n during deserialize<>() (which i of course can't debug because it's not a debug build). i can reproduce the error by switching between the 2 flag sets, doing a distclean/reconfigure, rebuilding, and running ./test/s11nTest. s11n does no debug-dependent checking, so this problem scares me - if it's a compiler error (which i suspect) then i have absolutely no control over it. i need to go try this out in the s11n.net tree! i've always compiled with (-Werror -Wall -g), so i would never have seen this. -- ----- 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-30 13:50:11
|
On Thursday 30 December 2004 14:04, stephan beal wrote: > On Thursday 30 December 2004 13:59, gj...@fh... wrote: > > see for yourself: > > ../include/pclasses/s11n/reg_serializable_traits.h:123: error: > > redefinition of `struct P::s11n::s11n_traits<size_t>' > > ../include/pclasses/s11n/reg_serializable_traits.h:123: error: > > Okay, i know what causes that, but i don't know why it would show up > on your box but not mine. i'll take a look. i can't reproduce it, but i think i know why: i'll bet that on your 64-bit platform that two of the following types are actually the same type: int, long, ulong, size_t i should have realized that earlier. Here's a potential fix: edit src/s11n/pods_streamable.h Comment out this block: #define PS11N_TYPE ulong #define PS11N_TYPE_NAME "ulong" #define PS11N_SERIALIZE_FUNCTOR PS11N_PODS_STREAMABLE_PROXY #include "reg_serializable_traits.h" If you get the same error, try commenting out the 'long' block and, if that doesn't work, the int block. One of these is almost certainly the problem. Let me know which works on your box. i'll write up a config test to figure out which PODs are actually the same, and change the POD registration accordingly. -- ----- 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-30 13:06:00
|
On Thursday 30 December 2004 13:59, gj...@fh... wrote: > after editing the file and make clean && ./configure > make went well upon ... > > see for yourself: > ../include/pclasses/s11n/reg_serializable_traits.h:123: error: > redefinition of `struct P::s11n::s11n_traits<size_t>' > ../include/pclasses/s11n/reg_serializable_traits.h:123: error: Okay, i know what causes that, but i don't know why it would show up on your box but not mine. i'll take a look. -- ----- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
From: <gj...@fh...> - 2004-12-30 12:59:55
|
after editing the file and make clean && ./configure make went well upon ... see for yourself: --- make start --- .... .... .... g++ -pipe -fPIC -I. -I../include -O2 -DNDEBUG=1 -c -o FactoryTest.o FactoryTest.cpp g++ -pipe -fPIC -I. -I../include -O2 -DNDEBUG=1 -c -o registrations.o registrations.cpp g++ -o FactoryTest FactoryTest.o registrations.o -rdynamic -L../lib -L../src -L../src/System -L../src/Util -L../src/Unicode -L../src/IO -L../src/Net -L../src/SIO -L../src/s11n -lpclasses_core -lpclasses_system -lpclasses_io -lpclasses_unicode -lpclasses_sio -lpclasses_s11n -lpclasses_util g++ -pipe -fPIC -I. -I../include -O2 -DNDEBUG=1 -c -o s11nTest.o s11nTest.cpp In file included from ../include/pclasses/s11n/pods_streamable.h:64, from s11nTest.cpp:5: ../include/pclasses/s11n/reg_serializable_traits.h:123: error: redefinition of `struct P::s11n::s11n_traits<size_t>' ../include/pclasses/s11n/reg_serializable_traits.h:123: error: previous definition of `struct P::s11n::s11n_traits<size_t>' In file included from ../include/pclasses/s11n/reg_serializable_traits.h:149, from ../include/pclasses/s11n/pods_streamable.h:64, from s11nTest.cpp:5: ../include/pclasses/s11n/name_type.h:25: error: redefinition of `struct <unnamed>::class_name<size_t>' ../include/pclasses/s11n/name_type.h:25: error: previous definition of `struct <unnamed>::class_name<size_t>' ../include/pclasses/s11n/name_type.h:32: error: redefinition of `struct <unnamed>::class_name<const size_t>' ../include/pclasses/s11n/name_type.h:32: error: previous definition of `struct <unnamed>::class_name<const size_t>' ../include/pclasses/s11n/name_type.h:39: error: redefinition of `struct <unnamed>::class_name<size_t*>' ../include/pclasses/s11n/name_type.h:39: error: previous definition of `struct <unnamed>::class_name<size_t*>' ../include/pclasses/s11n/name_type.h:47: error: redefinition of `struct <unnamed>::class_name<const size_t*>' ../include/pclasses/s11n/name_type.h:47: error: previous definition of `struct <unnamed>::class_name<const size_t*>' In file included from ../include/pclasses/s11n/reg_serializable_traits.h:161, from ../include/pclasses/s11n/pods_streamable.h:64, from s11nTest.cpp:5: ../include/pclasses/FactoryReg.h:96: error: redefinition of `bool <unnamed>::pfactory_reg_context<size_t>::placeholder' ../include/pclasses/FactoryReg.h:96: error: `bool <unnamed>::pfactory_reg_context<size_t>::placeholder' previously declared here {standard input}: Assembler messages: {standard input}:50: Error: symbol `_ZN29_GLOBAL__N_s11nTest.cppRPaWko20pfactory_reg_contextImE11placeholderE' is already defined make[1]: *** [s11nTest.o] Error 1 make[1]: Leaving directory `/home/gjehle/src/pclasses2-2.0.dev/test' make: *** [subdirs-all] Error 2 --- make end --- // gjehle Zitat von stephan beal <st...@s1...>: > On Thursday 30 December 2004 12:02, stephan beal wrote: > > Yes: in ./toc.pclasses.make.at > > s/pclasses/pclasses2/ > > > > -- > ----- st...@s1... http://s11n.net > "...pleasure is a grace and is not obedient to the commands > of the will." -- Alan W. Watts > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > pclasses-devel mailing list > pcl...@li... > https://lists.sourceforge.net/lists/listinfo/pclasses-devel > |
From: stephan b. <st...@s1...> - 2004-12-30 11:05:51
|
On Thursday 30 December 2004 12:02, stephan beal wrote: > Yes: in ./toc.pclasses.make.at s/pclasses/pclasses2/ -- ----- 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-30 11:04:11
|
On Thursday 30 December 2004 08:55, gj...@fh... wrote: > i just tried to compile that on x86_64 aka amd64 (out of pure > couriosity) and i'm getting the usual error "recompile using -fPIC" Yes: in ./toc.pclasses.make.at there is a line near the top commented out, with -fPIC on it. Uncomment it and reconfig, then you'll be okay. :) > so, what about checking if the arch is x86_64 and adding a -fPIC > option and take a look if the compile and testrun goes well? Normally i ALWAYS include it, because the Debian team REQUIRES it on libs (don't know why). Thanks for giving it a try! -- ----- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
From: <gj...@fh...> - 2004-12-30 07:56:08
|
i just tried to compile that on x86_64 aka amd64 (out of pure couriosity) and i'm getting the usual error "recompile using -fPIC" i'm not sure if amd64 is meant to be supported at all, but it would be nice anyways so, what about checking if the arch is x86_64 and adding a -fPIC option and take a look if the compile and testrun goes well? in case you have further questions i'm on #pclasses at like 19:00 CET i guess if you don't have access to a amd64 box, we can talk about that issue, too :) // gjehle here's a list of the make output: ---- make begin ---- Generating rules for INSTALL_XXX. Making all in AT make[1]: Entering directory `/home/gjehle/src/pclasses2-2.0.dev/AT' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/gjehle/src/pclasses2-2.0.dev/AT' Making all in include make[1]: Entering directory `/home/gjehle/src/pclasses2-2.0.dev/include' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/gjehle/src/pclasses2-2.0.dev/include' Making all in m4 make[1]: Entering directory `/home/gjehle/src/pclasses2-2.0.dev/m4' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/gjehle/src/pclasses2-2.0.dev/m4' Making all in src make[1]: Entering directory `/home/gjehle/src/pclasses2-2.0.dev/src' Generating STATIC_LIBS rules. Generating SHARED_LIBS rules. Generating C_DEPS rules for *.cpp *.c *.c++ *.C *.cc *.moc make[1]: Leaving directory `/home/gjehle/src/pclasses2-2.0.dev/src' make[1]: Entering directory `/home/gjehle/src/pclasses2-2.0.dev/src' g++ -pipe -I. -I../include -O2 -DNDEBUG=1 -c -o Alloc.o Alloc.cpp g++ -pipe -I. -I../include -O2 -DNDEBUG=1 -c -o AtomicInt.gcc-x86.o AtomicInt.gcc-x86.cpp g++ -pipe -I. -I../include -O2 -DNDEBUG=1 -c -o ByteOrderTraits.o ByteOrderTraits.cpp g++ -pipe -I. -I../include -O2 -DNDEBUG=1 -c -o Date.o Date.cpp g++ -pipe -I. -I../include -O2 -DNDEBUG=1 -c -o DateTime.o DateTime.cpp g++ -pipe -I. -I../include -O2 -DNDEBUG=1 -c -o Exception.o Exception.cpp g++ -pipe -I. -I../include -O2 -DNDEBUG=1 -c -o LinkedItem.o LinkedItem.cpp g++ -pipe -I. -I../include -O2 -DNDEBUG=1 -c -o Time.o Time.cpp g++ -pipe -I. -I../include -O2 -DNDEBUG=1 -c -o TimeSpan.o TimeSpan.cpp ar crs libpclasses_core.a Alloc.o AtomicInt.gcc-x86.o ByteOrderTraits.o Date.o DateTime.o Exception.o LinkedItem.o Time.o TimeSpan.o ; g++ -pipe -o libpclasses_core.so.2.0.dev -rdynamic -shared -Wl,-soname,libpclasses_core.so.2 Alloc.o AtomicInt.gcc-x86.o ByteOrderTraits.o Date.o DateTime.o Exception.o LinkedItem.o Time.o TimeSpan.o /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.4/../../../../x86_64-pc-linux-gnu/bin/ld: Alloc.o: relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC Alloc.o: could not read symbols: Bad value collect2: ld returned 1 exit status make[1]: *** [libpclasses_core.so] Error 1 make[1]: Leaving directory `/home/gjehle/src/pclasses2-2.0.dev/src' make: *** [subdirs-all] Error 2 ---- make end ---- Zitat von stephan beal <st...@s1...>: > FYI: i don't know if the AT dist tarball is working, but the toc-based > one is essentially working now... > > If you want to try it out without touching your CVS tree, here's a > tarball: > > i'm going to break up this URL so that crawlers reading the mail > archives don't download it: > > http://s11n.net <BREAK> > /tmp <BREAK> > /pclasses2-2.0.dev.tar.bz2 > > size == 485kb > > Caveats: > > - Only works on posix platforms at the moment, and only tested on Linux. > > - install "almost" works - got a minor bug or two to fix. > > > i think that's about it. > > -- > ----- st...@s1... http://s11n.net > "...pleasure is a grace and is not obedient to the commands > of the will." -- Alan W. Watts > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > pclasses-devel mailing list > pcl...@li... > https://lists.sourceforge.net/lists/listinfo/pclasses-devel > |
From: stephan b. <st...@s1...> - 2004-12-29 21:08:33
|
FYI: i don't know if the AT dist tarball is working, but the toc-based one is essentially working now... If you want to try it out without touching your CVS tree, here's a tarball: i'm going to break up this URL so that crawlers reading the mail archives don't download it: http://s11n.net <BREAK> /tmp <BREAK> /pclasses2-2.0.dev.tar.bz2 size == 485kb Caveats: - Only works on posix platforms at the moment, and only tested on Linux. - install "almost" works - got a minor bug or two to fix. i think that's about it. -- ----- 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-29 21:02:27
|
On Wednesday 29 December 2004 21:37, stephan beal wrote: > Keep the container types free of deps on i/o. They are containers, > not stream marshallers. Sorry, i should have explained my reasoning, instead of just making a general statement like that. First off: yes, the design of putting save/load funcs in such a type's API is quite common, and does make sense, OO-wise. As far as code reusability goes, though, it ends up biting you later on. i can't count how many Prefs-style objects i've implemented, and put load/save support in them, and then never used that support (or took it out while porting the object to another tree). If you can find a copy of it (i don't think it's on the web), read Herb Sutter's "What's in a Class?" article. While i'm not a huge fan of Herb's work in general, that particular article changed the way i program, in particular in cases such as Prefs. s11n's design was massively influenced by that article. In any case, i'll try to remember to bring the book with that article ("More C++ Gems") when we meet. :) -- ----- 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-29 20:38:55
|
On Wednesday 29 December 2004 21:23, Marc Duerner wrote: > We could also move Prefs (and the old P::Config for that matter) out > of Util into an App module. That would make sense. > Once we have the file loading/saving > stuff for Prefs we will need FileStreams anyway. This dep is necessary only if Prefs KNOWS it's loadable and saveable :). Using SIO this can be done transparently, so it doesn't need to know :) :). That allows the clients to save it using the default SIO proxy or they can use their own algorithm: P::SIO::save( myprefs, file|stream ); or mySpecialSavePrefs( prefs, file|stream ); Keep the container types free of deps on i/o. They are containers, not stream marshallers. -- ----- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
From: Marc D. <bdu...@gm...> - 2004-12-29 20:22:07
|
We could also move Prefs (and the old P::Config for that matter) out of Util into an App module. Once we have the file loading/saving stuff for Prefs we will need FileStreams anyway. Marc On Wednesday 29 Dec 2004 01:01, stephan beal wrote: > Okay, this point is really bugging me, and i couldn't sleep... > > Please understand: i'm not complaining to anyone here, i'm just trying > to express how important a solid dependencies model is on flexible > software. At the end of this mail i detail the short list of things we > need to do to reach a "well-dependencied" tree. > > i've been playing around on paper, and i've found a deps tree which: > > a) i really like. > > b) is extremely close to what we have now. > > Unfortunately, i can't copy my drawing into the mail. i will try to > express it in "flat form" here. > > Assumption #0: Core depends on no other P Modules. Period. > > Assumption #1: all modules depend on the Core. This is a fair > assumption, even if it isn't 100% technically true. > > Assumption #2: all modules except Core depend on Util. This is almost > 100% true, but not quite. > > Assumption #3: all modules depend on themselves. Sounds silly, but it is > significant. > > When i write: > A ==> B > > That means module A has a direct dep on module B. A uses B. Thus: > > A <==> B > > is circular, and therefore Evil. > > Now, here are the deps as i BELIEVE them to be currently: > > (Reminder: Unicode and s11n's core are handled by Assumptions #1 and > #2.) > > System ==> Unicode > System ==> IO > Net ==> IO > Net <==> System (only timeout.h) > SIO ==> (s11n and s11n::io) > s11n::io ==> s11n (s11n > Plugins ===> may freely dep on any P module > > That's all fairly good - i'm fairly happy with that :). Now comes the > problem: > > Util ==> IO (only because of the Prefs' throw IOError) > Util ==> System (only classes ThreadPool and WorkerQueue) > > That means that ALL other modules have a dep on IO and System. Nothing > is standalone :(. Nothing! > > Actually, we're much closer than i thought! i thought Unicode had a dep > on Util, and that IO had a dep on System, but this does not appear to > be the case (after some grepping) :). > > So, here is what i propose we do: > > a) Change Util::Prefs to throw Error instead of IOError. IMO this is a > much better solution for Prefs' API, anyway. > > b) Move the thread-related Util stuff into Thread (==> System) or into > System. > > c) Is Net's dep on timeout.h really significant? This seems like an > extremely low-level detail which we could overlook? > > If nobody objects, i will happily do (a) and (b). > > "i await your command..." > > (And now i'm really going to bed...) |
From: stephan b. <st...@s1...> - 2004-12-29 16:57:12
|
On Wednesday 29 December 2004 00:01, Marc Duerner wrote: > Log Message: > added Any class to Util module But which class was it? ;) -- ----- 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-29 00:18:09
|
On Wednesday 29 December 2004 01:01, stephan beal wrote: > Now, here are the deps as i BELIEVE them to be currently: Of course i forgot one: Plugin ==> Core Plugin ==> System (for SharedLib-related support) System ==> Plugin (MimeHandlerFactory is-a PluginManager) IO,Net,Sql ==> Plugin This one is a bit trickier to fix. The straightforward solution would be to move Plugin to System. This makes sense, actually, because Plugin is just an subclass of Factory which knows how to handle native DLLs. The problem with that move would be (IO <= Plugin => System). Damn... This dependency is tricky, but there is potentially another solution: Move PluginManager to the core, removing any System-related API. Create new type System/NativePluginManager (extends PluginManager), and move the System-related API here. NativePM will silently swap in the SharedLib support to PluginManager, in the same way that PluginManager can swap out the Factory<>::instance() objects. That might work. i'll need to experiment... tomorrow... -- ----- 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-29 00:03:23
|
Okay, this point is really bugging me, and i couldn't sleep... Please understand: i'm not complaining to anyone here, i'm just trying to express how important a solid dependencies model is on flexible software. At the end of this mail i detail the short list of things we need to do to reach a "well-dependencied" tree. i've been playing around on paper, and i've found a deps tree which: a) i really like. b) is extremely close to what we have now. Unfortunately, i can't copy my drawing into the mail. i will try to express it in "flat form" here. Assumption #0: Core depends on no other P Modules. Period. Assumption #1: all modules depend on the Core. This is a fair assumption, even if it isn't 100% technically true. Assumption #2: all modules except Core depend on Util. This is almost 100% true, but not quite. Assumption #3: all modules depend on themselves. Sounds silly, but it is significant. When i write: A ==> B That means module A has a direct dep on module B. A uses B. Thus: A <==> B is circular, and therefore Evil. Now, here are the deps as i BELIEVE them to be currently: (Reminder: Unicode and s11n's core are handled by Assumptions #1 and #2.) System ==> Unicode System ==> IO Net ==> IO Net <==> System (only timeout.h) SIO ==> (s11n and s11n::io) s11n::io ==> s11n (s11n Plugins ===> may freely dep on any P module That's all fairly good - i'm fairly happy with that :). Now comes the problem: Util ==> IO (only because of the Prefs' throw IOError) Util ==> System (only classes ThreadPool and WorkerQueue) That means that ALL other modules have a dep on IO and System. Nothing is standalone :(. Nothing! Actually, we're much closer than i thought! i thought Unicode had a dep on Util, and that IO had a dep on System, but this does not appear to be the case (after some grepping) :). So, here is what i propose we do: a) Change Util::Prefs to throw Error instead of IOError. IMO this is a much better solution for Prefs' API, anyway. b) Move the thread-related Util stuff into Thread (==> System) or into System. c) Is Net's dep on timeout.h really significant? This seems like an extremely low-level detail which we could overlook? If nobody objects, i will happily do (a) and (b). "i await your command..." (And now i'm really going to bed...) -- ----- 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-28 23:19:30
|
Yo, Before i go to bed i wanted to introduce you to a new part of the SIO API: S11nNode now contains the same de/serialize() members as the SIO namespace. It does not have the load/save() (file/stream-based) variants because those require knowledge of the SerializerInterface, and S11nNode inherently doesn't know that. Anyway, here's a short demo: CERR << "Time...\n"; Time thetime( 12, 13, 14 ); Date thedate( 2005, 1, 30 ); DateTime dt( thedate, thetime ); // save using SIO interface: save( thetime, std::cout ); save( thedate, std::cout ); save( dt, std::cout ); CERR << "Using S11nNode-specific API...\n"; S11nNode tmnode; assert( tmnode.serialize( dt ) ); assert( save( tmnode, std::cout ) ); DateTime * pdt = tmnode.deserialize<DateTime>(); assert( pdt ); CERR << "deserialized (DateTime*) == " << *pdt<<"\n"; delete pdt; DateTime vdt; assert( tmnode.deserialize( vdt ) ); CERR << "deserialized DateTime == " << vdt<<"\n"; Output... s11nTest.cpp:460 : Time... <!DOCTYPE s11n::io::expat_serializer> <S11nNode class="P::Time"> <hour>12</hour> <min>13</min> <sec>14</sec> <usec>0</usec> </S11nNode> <!DOCTYPE s11n::io::expat_serializer> <S11nNode class="P::Date"> <day>30</day> <month>1</month> <year>2005</year> </S11nNode> <!DOCTYPE s11n::io::expat_serializer> <S11nNode class="P::DateTime"> <time class="P::Time"> <hour>12</hour> <min>13</min> <sec>14</sec> <usec>0</usec> </time> <date class="P::Date"> <day>30</day> <month>1</month> <year>2005</year> </date> </S11nNode> s11nTest.cpp:471 : Using S11nNode-specific API... <!DOCTYPE s11n::io::expat_serializer> <S11nNode class="P::DateTime"> <time class="P::Time"> <hour>12</hour> <min>13</min> <sec>14</sec> <usec>0</usec> </time> <date class="P::Date"> <day>30</day> <month>1</month> <year>2005</year> </date> </S11nNode> s11nTest.cpp:478 : deserialized (DateTime*) == 2005-01-30 12:13:14 s11nTest.cpp:482 : deserialized DateTime == 2005-01-30 12:13:14 -- ----- 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-28 23:11:59
|
On Wednesday 29 December 2004 00:07, stephan beal wrote: > - Remove the exception. Hey, even better idea: Change the throw: throw(P::Error) Error is a core exception, and would also cover P::Sql::SqlException, for a db-aware PrefsStore... -- ----- 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-28 23:08:53
|
Yo! Marc just committed his Prefs and Variant (another name for LexT) code, and i've got it compiling under p2 and in the makefiles. i have one concern: you guys know i hate circular deps on the modules. i'm a build maintainer, by nature, and circular deps eventually cause a tree to break down. Look at Qt: you can't use a single part without using all the rest. Try creating a QPixmap without creating a QApp. Doesn't work. So now i come to the IO/Util dependencies... PrefsStore throws an IOException when load() or update() fail. This introduces a dependency on IO::IOError. What i would propose is: - Remove the exception. - Change return type to bool. - Never throw from those functions. Good points: - One less dep. - Simplified client usage. - This is the only place in the API which relies on IO::, so the rest of the interface is unaffected. Bad point: - Inconsistent with other i/o API in the lib. However, i feel that this object is "high level" enough that a simple bool would do the trick. ??? -- ----- 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-28 22:44:44
|
On Tuesday 28 December 2004 23:42, Marc Duerner wrote: > Just noticed that the Makefiles in the Util Module are not in sync > (AT and toc version). My fault. i'll fix it Right now. > Is the AT version obsolete? NO! Well... from my perspective, yes ;). i can't build the AT tree - my autotools are incompatible :(. -- ----- 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-28 22:41:36
|
Yo! Here are some first-draft ideas for the i/o layer. My main goals are: - Allow interaction between IOStream and IODevice. Either consolidate them or provide a marshaller type which can proxy data between them. - Consolidate the various i/o interfaces (read(), write(), open(),...) into a consistent interface. - Structure the types such that we can apply many generic algorithms to them (e.g., std::copy(), std::for_each()). To be clear: i am not at all certain about any of these ideas. i only have experience as a stream user, not a stream implementor. My first idea is to create an abstract IOInterface type. Something like: class IOInterface [??? : public NonCopyable] { virtual void open() throw(IOError) = 0; virtual void close() throw(IOError) = 0; virtual size_t read( char * buff, size_t count ) throw(IOError) = 0; virtual size_t write( char * buff, size_t count ) throw(IOError) = 0; virtual bool canWrite() = 0; // read-only streams return 0 virtual bool canRead() = 0;// write-only streams return 0 ... }; IOStream should, IMO, subclass std::iostream. i would prefer to see: class IStream : public IOInterface, public std::istream {} class OStream : public IOInterface, public std::ostream {} But this probably requires virtual inheritence to avoid colliding with i/ostream members. (haven't checked yet.) And, of course: class IODevice : public IOInterface { .... }; i really would prefer to see IODevice and IOStream be directly related, but i am not certain that is really practical or desireable. Maybe... istream ==> extended by IDevice ==> IStream ostream ==> extended by ODevice ==> OStream IOStream ==> EXTENDS (IStream, OStream) IODevice ==> EXTENDS (IOStream) ??? In that case, i don't see the real distinction between IODevice and IOStream... what IS the difference? How does all this apply when using IODevice for, e.g., rendering graphics (e.g. QPaintDevice). ??? i have no idea. ??? -- ----- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
From: Marc D. <bdu...@gm...> - 2004-12-28 22:40:44
|
Just noticed that the Makefiles in the Util Module are not in sync (AT and toc version). Is the AT version obsolete? Marc |