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: stephan b. <st...@s1...> - 2004-12-28 20:59:56
|
On Tuesday 28 December 2004 21:41, Christian Prochnow wrote: > are you fine with current SystemClock interface ? Absolutely. i like the idea you mentioned earlier about timers. Here's an easy-to-implement option which doesn't need full timer support but still would be useful... something like: static TimeSpan timeDiff( const DateTime &, const DateTime & ); plus an overload with just Time and just Date? Or maybe just put that in DateTime? Don't know where they really belong. The intended usage would be : Time t = SystemClock::now(); ... do something ... Time t2 = SystemClock::now(); ... get diff ... > Since DateTime inherits from Date and Time there is no need for > currentTime() and today(). Agreed completely -- ----- 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-28 20:43:26
|
Am Dienstag 28 Dezember 2004 21:23 schrieb stephan beal: > Note the timestamps... > > On Tuesday 28 December 2004 21:19, Christian Prochnow wrote: > > Added Files: > > SystemClock.win32.cpp > > On Tuesday 28 December 2004 21:20, stephan beal wrote: > > Log Message: > > Added SystemClock. > > If that's not teamwork, i don't know what is... :) Modified Files: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Makefile.am=20 Log Message: Fixed typo SharedLib.comon.cpp =3D=3D> SharedLib.common.cpp. Added SystemC= lock=20 sources.=20 That really IS teamwork :) |
|
From: Christian P. <cp...@se...> - 2004-12-28 20:40:58
|
Am Dienstag 28 Dezember 2004 18:38 schrieb stephan beal: > On Tuesday 28 December 2004 18:27, Christian Prochnow wrote: > > I'm adding a 'SystemClock' class or similar to the System namespace > > which can be used to retrieve system time. > > > > Which class name would you recommend ? > > Great :). i think SystemClock is fine. That opens up the door for > abstractions like NetworkTimeServer :). > > Would you please add these functions to it: > > static const Time currentTime(); > static const Date today(); > static const DateTime now(); > > ? Stephan, are you fine with current SystemClock interface ? Since DateTime inherits from Date and Time there is no need for currentTime() and today(). Greetings |
|
From: stephan b. <st...@s1...> - 2004-12-28 20:24:32
|
Note the timestamps... On Tuesday 28 December 2004 21:19, Christian Prochnow wrote: > Added Files: > SystemClock.win32.cpp On Tuesday 28 December 2004 21:20, stephan beal wrote: > Log Message: > Added SystemClock. If that's not teamwork, i don't know what is... :) -- ----- 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 17:39:55
|
On Tuesday 28 December 2004 18:27, Christian Prochnow wrote: > I'm adding a 'SystemClock' class or similar to the System namespace > which can be used to retrieve system time. > > Which class name would you recommend ? Great :). i think SystemClock is fine. That opens up the door for abstractions like NetworkTimeServer :). Would you please add these functions to it: static const Time currentTime(); static const Date today(); static const DateTime now(); ? -- ----- 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 17:31:09
|
See src/s11n/proxy/Time_s11n.h.
#include <pclasses/s11n/proxy/Time_s11n.h>
...
using namespace P::SIO;
using P::Time;
using P::Date;
using P::DateTime;
Time thetime( 12, 13, 14 );
Date thedate( 2005, 1, 30 );
DateTime dt( thedate, thetime );
save( thetime, std::cout );
save( thedate, std::cout );
save( dt, std::cout );
<!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>
--
----- 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-28 17:26:31
|
Am Dienstag 28 Dezember 2004 18:15 schrieb stephan beal: > Yo, Christian! > > Would you mind if i add: > > static const Time Time::now(); > > Can this be done platform-portably? If so, which time/tm funcs/structs > would you recommend? I'm adding a 'SystemClock' class or similar to the System namespace which can be used to retrieve system time. Which class name would you recommend ? Regards |
|
From: stephan b. <st...@s1...> - 2004-12-28 17:17:05
|
Yo, Christian! Would you mind if i add: static const Time Time::now(); Can this be done platform-portably? If so, which time/tm funcs/structs would you recommend? -- ----- 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 14:57:09
|
On Tuesday 28 December 2004 15:07, Christian Prochnow wrote: > Don't know - i thought they mean different things .. > > common = allgemein > generic = generisch > > for me as a native german speaker it does mean two different things. Actually, that's correct, but the meanings of those words are often interchangeable in English. My only argument was that we should use the same naming conventions for the cross-platform parts of classes. zB, we currently have: CriticalSection.generic.cpp FileInfo.common.cpp SharedLib.generic.cpp i named SharedLib.generic because we already had CriticalSection.generic - the platform-neutral part of the CriticalSection code. Taking a closer look at CriticalSection, i now see why you chose to call that .generic instead of .common. i will do the same with SharedLib, since it contains the common parts of all SharedLib classes. 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-28 14:06:53
|
Am Montag 27 Dezember 2004 20:40 schrieb stephan beal: > On Monday 27 December 2004 20:38, Christian Prochnow wrote: > > No, the existing files (at least in P1) .. did use generic and common > > > > :-) > > But generic and common have the same meaning here, right? Don't know - i thought they mean different things .. common = allgemein generic = generisch for me as a native german speaker it does mean two different things. Greetings ... |
|
From: stephan b. <st...@s1...> - 2004-12-28 04:31:25
|
Yo! Before i finally get to sleep: i just added a feature to SIO which uses one of s11n's least-known features: the ability to work with arbitrary "data node" types. That is, it can de/serialize using an arbitrary container type for serialized data. We use a node_traits<> type to achieve the node type transparency for the core. Anyway: i took SimplePropertyStore and extended it: P::SIO::S11nNode. i simply had to swap out a typedef in SIO to make that the new framework-supported node type. Client code doesn't need to change to see such a node-swap: test/s11nTest.cpp, which is a fully-functional SIO client, worked as-is. It did of course need a recompile to get the new class. Strangely enough: s11n_node is a direct descendant, code-wise, of property_store, which is the class i refactored to make SimplePropertyStore... which i then subclassed to make S11nNode... by copy/pasting the missing functions from s11n_node. Talk about code re-use ;). This was mainly an experiment, in any case. There is a valid reason *not* to implement a custom data node type, and that is efficiency: s11n::s11n_node is not polymorphic, whereas S11nNode is. Since an arbitrary number of nodes can be created for any given tree of data, a monomorphic type is probably notably more efficient. (i've tested with up to 57k nodes. Theoretically the RAM and system pointer size determine the limits.) -- ----- 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 01:46:53
|
moved to list, just to show off s11n...
On Tuesday 28 December 2004 02:24, stephan beal wrote:
> > If load() / save() is not part of Prefs anymore it will be less
> > straight forward to make Prefs a singleton.
>
> No it won't! s11n CAN handle that case! i promise - i've done it
> before! It's sooooo easy to do with s11n.
>
> :)
In fact, i'll walk you through it right now...
Gehen wir davon aus... du willst den Koenig besuchen. When you visit The
King, you don't see The King directly. You get his Ambassador. Let's
see what a Singleton Ambassator for s11n might look like:
Let's assume Prefs has functions to iterate over, set and set the
contents.
Here's a proxy class which should work for ANY singleton type supporting
an instance() method.
template <typename SingletonT>
struct S11nSingletonProxy {
// serialize
bool operator()( P::SIO::S11nNode & dest ) const
{
typedef ::P::SIO::NodeTraits TR;
TR::class_name( dest, ::class_name<SingletonT>() );
// ^^^^^^^ s11n docs cover this in gory detail
SingletonT & s = SingletonT::instance();
// ... store s's state to dest ...
return true;
}
// deserialize
template <typename NodeT>
bool operator()( const P::SIO::S11nNode & src )
{
typedef ::P::SIO::NodeTraits TR;
SingletonT & s = SingletonT::instance();
// ... restore p's state from src...
return true;
}
};
We'd have to do a small bit of other back-end work, but i'm confident i
could get it working in under an hour, assuming Prefs has the necessary
mutator/getter API (in practice, all generic containers do).
We could also add another layer of indirection, to use this proxy for
ALL Singletons, but supply a functor type which performs the actual
logic of the de/ser operations. Again - no problem with s11n. :)
Now, to save the singleton:
using namespace P::SIO;
save( S11nSingletonProxy<MyT>(), std::cout );
Saves the singleton's state!
Loading, in this unusual case, requires a non-const proxy object, and we
must do a small extra step of loading an intermediary data node (the
container holding the object's data):
S11nNode * node = load_node( istream|file );
if( ! node ) { ... error ... }
S11nSingletonProxy<MyT> foo;
bool worked = deserialize( *node, foo );
delete 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-27 23:06:27
|
Yo!
Marc sent me some code today for P1 with his latest, feature-filled
Property classes. Those aren't yet ported to p2. In the mean time, i
took and old property store class of mine and use LexT to simplify the
interface (cut the interface in half!). See
P::Util::SimplePropertyStore. It's simply a key/val pair holder, and
doesn't support multiple keys at the moment - we should decide if it
should use multimap or map. i vote for map, because that's what all of
my anticipated use-cases will need, and multimap doesn't support
operator[].
Here's a short demo, including SIO support:
using namespace ::P::SIO;
using namespace ::P::Util;
P::Util::SimplePropertyStoreTest m;
m["fred"] = "wilma";
m["barney"] = "betty";
m["days_in_december"] = 31;
m["days_in_february"] = 28.5;
m["the_letter_a"] = 'a';
save( m, std::cout );
Output:
<!DOCTYPE s11n::io::expat_serializer>
<s11n_node class="SomeSillyPropertyMap">
<barney>betty</barney>
<days_in_december>31</days_in_december>
<days_in_february>28.500000</days_in_february>
<fred>wilma</fred>
<the_letter_a>a</the_letter_a>
</s11n_node>
Couldn't get much simpler than that. :)
The i/o support works with so little effort because:
a) LexT is i/ostreamable, which means we can inherently treat it as a
POD.
b) SimplePropertyStore is close to API-compatible with std::map, which
means we can plug it in to P::SIO using the already-available map
serialization proxies:
#define PS11N_TYPE P::Util::SimplePropertyStore
#define PS11N_TYPE_NAME "SomeSillyPropertyMap"
#define PS11N_SERIALIZE_FUNCTOR \
::P::s11n::map::streamable_map_serializable_proxy
#include <pclasses/s11n/reg_serializable_traits.h>
What does that mean? It means streamable_..._proxy will act on behalf of
our type for serialization calls. If we swap that proxy out with the
default map proxy:
::P::s11n::map::map_serializable_proxy
then we get MUCH fatter output. The advantage to the default proxy is
that it works with all objects, not just i/ostreamables. The output
when we treat each map entry as a POD:
<!DOCTYPE s11n::io::expat_serializer>
<s11n_node class="SomeSillyPropertyMap">
<pair class="pair">
<first class="string">
<v>barney</v>
</first>
<second class="LexT">
<v>betty</v>
</second>
</pair>
... repeat for each pair ...
</s11n_node>
When we KNOW we're saving POD-style data we can plug in lighter-weight,
more specialized proxies.
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-27 20:22:03
|
Yo! Do any of you know how portable flex-generated lexer files are? If they are portable, i could pull the whole s11n::io set of Serializers by using their pre-generated lexers in this tree. (That'd be 7 data formats.) i know the files compile on at least 11 different Linux architectures, but they're all using gcc and flex themselves. Or is there anyone willing to try to compile a flex-gen'd file if i generate one? AFAIK generated lexers are very portable. We can't rely on client-side versions of 'flex', though, because many newer versions create output which no C compiler can compile. Even in the s11n tree, i ship pre-gen'd flexers in the dist tarball. i have no idea how non-Unix compatible they are, 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-27 19:41:57
|
On Monday 27 December 2004 20:38, Christian Prochnow wrote: > No, the existing files (at least in P1) .. did use generic and common > :-) But generic and common have the same meaning here, right? -- ----- 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-27 19:38:03
|
Am Montag 27 Dezember 2004 20:33 schrieb stephan beal: > That i understood, but the existing files used the *.generic.cpp > convention, and i'd like us to be consistent. i like 'common' much > better, actually. i'll go through and rename the .generic.cpp > ==> .common.cpp if you like. No, the existing files (at least in P1) .. did use generic and common :-) Greetings... |
|
From: stephan b. <st...@s1...> - 2004-12-27 19:34:35
|
On Monday 27 December 2004 20:25, Christian Prochnow wrote: > No .. you should change the SharedLib.generic.cpp to > SharedLib.common.cpp, cause all SharedLib implementations may use the > common code. Will do! > z.B. > CriticalSection.win32.cpp is win32 impl of criticalsection ... > Is the difference clear to you ? That i understood, but the existing files used the *.generic.cpp convention, and i'd like us to be consistent. i like 'common' much better, actually. i'll go through and rename the .generic.cpp ==> .common.cpp if you like. -- ----- 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-27 19:32:07
|
Yo!
i'm trying to build the tree with autotools, but i can't seem to get the
proper versions. i've backrevved my local box to the ones listed in
autogen.sh:
export WANT_AUTOMAKE=1.8
export WNAT_AUTOCONF=2.5
s/WNA/WAN/ ==> just committed to CVS
stephan@owl:~/cvs/PC2> autoconf --version
autoconf (GNU Autoconf) 2.59
stephan@owl:~/cvs/PC2> automake --version
automake (GNU automake) 1.8.5
i can't get it to build configure, though:
stephan@owl:~/cvs/PC2> ./autogen.sh
Putting files in AC_CONFIG_AUX_DIR, `admin'.
configure.in:187: error: possibly undefined macro:
AC_raf_FUNC_WHICH_GETSERVBYNAME_R
If this token and others are legitimate, please use
m4_pattern_allow.
See the Autoconf documentation.
configure.in:210: error: possibly undefined macro: AC_PREFIX_CONFIG_H
autoreconf: /home/stephan/AT/bin/autoconf failed with exit status: 1
rm: cannot remove `COPYING': No such file or directory
What combination of versions have you guys got???
--
----- 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-27 19:24:43
|
Hi ! No .. you should change the SharedLib.generic.cpp to SharedLib.common.cpp, cause all SharedLib implementations may use the common code. z.B. CriticalSection.win32.cpp is win32 impl of criticalsection CriticalSection.generic.cpp is a generic criticalsection impl that uses a Mutex and works on all Systems (when they dont support CriticalSections). Code in FileInfo.common.cpp is common to all FileInfo platform dependant code. Is the difference clear to you ? Greetings, Christian Am Montag 27 Dezember 2004 18:27 schrieb stephan beal: > Yo! > > U src/System/FileInfo.common.cpp > > Could i convince you to rename that to FileInfo.generic.cpp? The reason > is this: all the other code follows this convention. As we change the > build process to be cross-platform-friendly, it will be easier if we > can look up files based on, e.g., Foo.$(LIBPSYSTEM_PLATFORM).cpp. > > Consistent patterns are critical to any automation :). |
|
From: stephan b. <st...@s1...> - 2004-12-27 17:56:43
|
On Monday 27 December 2004 18:49, stephan beal wrote: > provides gzip or bzip2 de/compression streams. That lib won't do, > as-is, in P (it's too restrictive), but i would like to modify it to Sorry, that sounded very negative towards P: i meant that the zfstream lib is too restrictive. It needs to be remodelled on a more flexible framework, like 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-27 17:51:08
|
Yo! Christian mentioned this the other day, and i'd like to go back to it for a minute: "magic cookie" support. If you don't know what that is, you really do know, you just don't know that you know it. When you see a shell script: #!/bin/bash that is a magic cookie. That "cookie" tells the OS what app can handle the content. gzip files have a small header, as do most other file types, and these can be analyzed to guess a file's type. Traditionally, and for ease of programming, we normally look at file extensions, but magic is a more reliable way of knowing the content of a file (but slower, of course, requiring at least a few bytes of fread()). s11n uses this for input dispatching, so users don't need to know what format they're using. Clients only select the output format. The formatter (Serializer) writes the cookie as the first line of output, then proceeds to save object data in it's native format. Reading a cookie is easy to "non-intrusively" do with files, but there is a subtle complication with streams: once we read the cookie we have extracted it from the stream and therefor cannot easily pass it to the parser! One option is to buffer the whole stream data after reading/checking the cookie, so we can pass a stringstream to the parser, but IMO this is not an option because streams have, by nature, an indeterminate size, and we don't want to read 57GB into RAM. Another option is to change the parser's API so that we can pass the cookie to it. The 3rd option (the one s11n currently uses) is to simply consume the cookie and pass the rest on the parser. This has the slight advantage that the parser won't ever see his cookie, but this isn't a big problem (but does have the down-side that we cannot use multiple cookies for one parser, to differentiate versions or compatibility modes). Anyway... i bring this all up because i would like to add some IO support for P, such that it can load stream handlers based on... whatever. For example, s11n currently uses a tiny lib which can transparently provides gzip or bzip2 de/compression streams. That lib won't do, as-is, in P (it's too restrictive), but i would like to modify it to a more generic stream dispatcher based off of Factory. Now comes the problem: reading cookies. Again, from files, we can read the cookie and pass it on to the handler. This is necessary when reading, e.g., a gzip file - we MUST pass all of the data to gzip. Same for almost any other generic stream processor. This means that writing cookie-based streamloader support can conceivably be done for files in about 20 lines of code (mostly the fopen() and accompanying calls, then simply delegating the real work to Factory). Files actually have one problem here, though: cookies won't work (AFAIK) for all binary formats. Some cookies require logic to decode, which means trying out functions on the data until we find a handler which thinks it can read it. In effect, this is what the 'file' (man file) does, using /etc/magic. Has anyone got an idea for an interface which allows us to, halfway efficiently, bind to "cookie tester" functions, so we can search them to find a matching handler? -- ----- 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-27 17:28:56
|
Yo! U src/System/FileInfo.common.cpp Could i convince you to rename that to FileInfo.generic.cpp? The reason is this: all the other code follows this convention. As we change the build process to be cross-platform-friendly, it will be easier if we can look up files based on, e.g., Foo.$(LIBPSYSTEM_PLATFORM).cpp. Consistent patterns are critical to any automation :). -- ----- 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-27 16:47:15
|
On Monday 27 December 2004 17:00, Marc Duerner wrote: > Hi, > Some people split template classes into .h and .tcc files. The .tcc > is included at the end of a .h file and contains the definitions for > the functions declared in the header. Should we do the same? > If yes how do we call the files? .tpp? That's an interesting idea. The gnu STL is distributed this way, it think - or something similar. My initial reaction is "eeek!" but i can't really qualify that. i find it difficult enough that the the headers and source are in different dirs. There IS actually a problem with doing so: the modules start to depend on one-another without realizing it, because they can all read each others' headers. In the QUB project we found a technique which literally elminates that possibility, which i mimic under src/s11n/... Anyway - i would vote no, but i'm also a big fan of majority rule, so i won't whine if i'm out-voted. :) -- ----- 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-27 15:59:36
|
Hi, Some people split template classes into .h and .tcc files. The .tcc is included at the end of a .h file and contains the definitions for the functions declared in the header. Should we do the same? If yes how do we call the files? .tpp? Marc |
|
From: Christian P. <cp...@se...> - 2004-12-26 17:20:18
|
Am Samstag 25 Dezember 2004 21:33 schrieb Marc Duerner: > On Saturday 25 Dec 2004 20:10, stephan beal wrote: > > Hi, Marc! > > > > A question about your Prefs support: > > > > i want to start on the App module, and will need to implement these > > features: > > - argv parser. (ArgvParser class) > > - OO access to environment. (Environment class) > > - per-app config files. (AppConfig? class) Environment should use P::System::ProcessEnv for accessing process environment. Transition of System::ProcessEnv is on the way. > Yes, AppConfig is basically Prefs. > > > i have all of that, but i need to port it from eshell. The problem is > > that i've built up lots of deps on other code of mine, and now need to > > figure out which parts P has and which ones i need to bring over. > > > > So, my question is: do you have a class which offers generic properties > > support. i mean, a map-like class which stores key/val pairs? That > > support is really the core to the App module, because the Environment > > and ArgvParser currently extend a type which provides that > > functionality. Also, such a type is inherently useful as a simple > > config file. > > The old P::Config was simply a map<string, string>. Christian and I then > decided that we would need a list, because we wanted to keep the order of a > config file after loading/saving. Also I wanted to get away from string as > the value type so we have now a list<Entry*> and ValueEntry derived from > Entry for all streamables. Prefs knows Sections which have a list<Entry*> > and a list<Section*> to form a tree structure. I would like to also keep the simple key/value based P::Config. Not all apps need such a complex Prefs system. > > So, if you've got such a type, please get it into P2 CVS, or let me know > > where to find it. If not i'll port in my PropertyStore type, which uses > > templatizes get()/set() functions to do lexical casting, which allows > > us to store any i/ostreamable type. IIRC you already have a type for > > this? If so i will rewrite around that one. > > Can I look at your PropertyStore. It should be possible to fuse that with > Prefs in some way. I can see that such a type would not only be useful for > Prefs/AppConfig. > > > See ya! > > take care! > > > > ------------------------------------------------------- > 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 |
