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-26 15:13:18
|
On Sunday 26 December 2004 15:56, stephan beal wrote: > With rev 1.8 of SharedLib.ltdl.cpp: > > gcc 3.3.5 20040809: With SharedLibChache 1.4 and SharedLib 1.8 it compiles. :) -- ----- 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-26 15:12:06
|
Please update again from CVS. Compiles with libltdl for me now. Am Sonntag 26 Dezember 2004 15:56 schrieb stephan beal: > On Sunday 26 December 2004 15:38, Christian Prochnow wrote: > > Log Message: > > Added SharedLibCache to libltdl implementation. Added templatetized > > handle type to SharedLibCache. > > stephan: please see if this is a solution with lt_dlclose() > > With rev 1.8 of SharedLib.ltdl.cpp: > > gcc 3.3.5 20040809: > > > SharedLib.ltdl.cpp: In constructor > `P::System::SharedLib::SharedLib(const > std::string&, P::System::SharedLib::BindMode)': > SharedLib.ltdl.cpp:96: error: invalid conversion from > `lt_dlhandle_struct*' to > `long unsigned int' > SharedLib.ltdl.cpp:96: error: initializing argument 2 of `void > P::System::SharedLibCache<handle_t, destroyF>::add(const > std::string&, long > unsigned int) [with handle_t = lt_dlhandle_struct*, destroyF = > P::System::SharedLibCloser]' > SharedLibCache.h: In member function `void > P::System::SharedLibCache<handle_t, > destroyF>::add(const std::string&, long unsigned int) [with handle_t > = > lt_dlhandle_struct*, destroyF = P::System::SharedLibCloser]': > SharedLib.ltdl.cpp:96: instantiated from here > SharedLibCache.h:61: error: invalid conversion from `long unsigned int' > to ` > lt_dlhandle_struct*' > > > The same with 1.7. > > That's why i had that stupid double-cast, first static_cast to void * > then to reinterpret_cast() (EVIL!) to ulong. :/ That's in rev 1.6, and > compiles on my box. |
From: stephan b. <st...@s1...> - 2004-12-26 15:08:27
|
i haven't had a rush like that in months! Just hit the 24 hours mark, and still going... :) Looking through the CVS list, we've made almost 400 commits in just the past 4 days (many commits are >1 file)!!! Damned shame that the CVS counts on sourceforge don't reflect reality :(. i hope you guys aren't too pissed off me with coming in and stomping all over your tree :/. If any changes upset you, i'll be happy to backrev them. 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-26 14:57:57
|
On Sunday 26 December 2004 15:38, Christian Prochnow wrote: > Log Message: > Added SharedLibCache to libltdl implementation. Added templatetized > handle type to SharedLibCache. > stephan: please see if this is a solution with lt_dlclose() With rev 1.8 of SharedLib.ltdl.cpp: gcc 3.3.5 20040809: SharedLib.ltdl.cpp: In constructor `P::System::SharedLib::SharedLib(const std::string&, P::System::SharedLib::BindMode)': SharedLib.ltdl.cpp:96: error: invalid conversion from `lt_dlhandle_struct*' to `long unsigned int' SharedLib.ltdl.cpp:96: error: initializing argument 2 of `void P::System::SharedLibCache<handle_t, destroyF>::add(const std::string&, long unsigned int) [with handle_t = lt_dlhandle_struct*, destroyF = P::System::SharedLibCloser]' SharedLibCache.h: In member function `void P::System::SharedLibCache<handle_t, destroyF>::add(const std::string&, long unsigned int) [with handle_t = lt_dlhandle_struct*, destroyF = P::System::SharedLibCloser]': SharedLib.ltdl.cpp:96: instantiated from here SharedLibCache.h:61: error: invalid conversion from `long unsigned int' to ` lt_dlhandle_struct*' The same with 1.7. That's why i had that stupid double-cast, first static_cast to void * then to reinterpret_cast() (EVIL!) to ulong. :/ That's in rev 1.6, and compiles on my box. -- ----- 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-26 14:32:29
|
On Sunday 26 December 2004 15:22, Christian Prochnow wrote: > The Client should not need to access the native handle. > I think current implementation is OK. What i meant with "templatize" > the handle type was only regarding the SharedLibCache template class. Sounds like a good idea. > I don't like to #ifdef the handle types in the headers, gives to many > problems. P 0.8 did it this way. Agreed - i avoid ifdefs when at all practical. -- ----- 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-26 14:23:25
|
"Vanilla s11n" can do this, too, but that's not important... the important part is that P can do it now, too... list<string> ls; ... populate ls ... list<P::Util::LexT> lt; if( ! P::SIO::s11n_cast( ls, lt ) ) { ... error ...} We can use s11n to "cast" between any "semantically compatible" Serializables. That is, as long as they use compatible algorithms for structuring their data internally, they can be cast this way. Also, many algos behave the same for container<T> and container<T*>, so this also works as expected: list<int> il; list<double *> dl; ... populate il ... s11n_cast( il, dl ); dl is now populated with pointers pointing at values which equal those from il. Similarly, we can use different types of "similar" containers: vector<MyType *> v; ... populate it ... list<MyType *> l; s11n_cast( v, l ); l now contains copies (created via s11n) of the objects in v. This is not an efficient way to copy objects, but it's very generic. Note that this does no stream i/o of any sort - this performs only container and factory operations. Final tip: s11n_cast is an easy way to test your de/ser algos - if they work with this function they'll work everywhere. -- ----- 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-26 14:21:53
|
The Client should not need to access the native handle. I think current implementation is OK. What i meant with "templatize" the handle type was only regarding the SharedLibCache template class. I don't like to #ifdef the handle types in the headers, gives to many problems. P 0.8 did it this way. Am Samstag 25 Dezember 2004 17:58 schrieb stephan beal: > We could use traits. > > > template <typename SharedLibImplTag> > HandleTraits > { > typedef unsigned long handle_type; > } > > Inside SharedLib.ltdl.cpp we define the following: > > > template <> > HandleTraits<lt_handle_t> // or some internal marker type > { > typedef lt_handle_t handle_type; > } > > And in SharedLib's impl we reference _handle via the traits type. > > The problem with that is that client code using SharedLib.ltdl only has > access to HandleTraits's *default* implementation, because the > specialization must live in hidden impl code. This means that clients > won't be able to get at the handle in it's native form. This isn't a > bad thing, but it means that the handle() function in SharedLib.ltdl > would still need to return the default handle_type. That means that > we're still basically stuck with not being able to pass the handle back > to the client properly (currently requires 2 casts: one to void *, then > one to ulong). > Or we could put the traits types in public headers and #ifdef the proper > specialization(s) in. > > One idea might be making a base class for SharedLib: > AbstractSharedLib<HandleT> > SharedLib : public AbstractSharedLib<ulong> > SharedLibLtDl : public AbstractSharedLib<lt_handle_t> > > i don't know if this buys us any flexibility, though. > > ??? |
From: Christian P. <cp...@se...> - 2004-12-26 14:14:59
|
The IO module is ok for me. Am Samstag 25 Dezember 2004 17:19 schrieb stephan beal: > Yo, > > Last night i realized that from a dependencies point of view, URL is not > really a Net class. It doesn't depend on any Net functionality, but > does depend on Unicode. URL doesn't really belong to Unicode, either, > though. IO and Net both currently use URL (zB, IOHandler::get(URL)), > but IO should not depend on Net (aber anders rum). > > So how about moving URL to IO? A URL does not represent an IO operation, > but does hold data for a potential IO operation. A URL is essentially a > pointer to an abstract data source, and data sources are used for IO. > > This change would eliminate one circular dep on Net and IO, and would > also allow the IOManager to not depend on Net (which it shouldn't have > to). If URL stays in Net then the whole IO and Net modules have a > circular dep, which complicates building them and will make code > maintenance more difficult at some point. > > Another option is we combine IO and Net into one module. Logically > speaking, IO/Net are quite similar, and will be used in similar > contexts. There IS a distinction between them, and 2 separate modules > is certainly justifiable, but i don't know if most people will realize > these subtle distinctions. > > ??? |
From: stephan b. <st...@s1...> - 2004-12-26 13:13:59
|
Okay, i needed some string util code for the App layer, and wanted to move some out of ps11n, so i finally went ahead and ported the string util code into Util/StringTool. It is namespace P::StringTool, encapsulating several commonly-useful string operations. Some of these will be especially useful for P, e.g. translateEntities(). i didn't call it Util::String, because that would mislead people to think it's only for the Unicode::String class. The name StringUtil has the same problem. Okay, maybe StringTool does as well :/. i'm open to suggestions for new names. Consider the problem of encoding URLs. e.g: "http://foo/?foo=bar bar bar" ==> "http://foo/?foo=bar%20bar%20bar" With translateEntities() encoding and decoding are trivial and generic: map<string,string> map; map[" "] = "%20"; map["..."] = "..."; // usw... encode: string u = "http://foo/?foo=bar bar bar"; StringTool::translateEntities( u, map ); // ^^^ modifies u in-place decode: StringTool::translateEntities( u, map, true ); // ^^^ 'true' == do reverse mapping All of s11n's serializers use this simple approach to do their, e.g. XML entity translation/escaping. By serving the translation maps through Phoenix, we ensure a) they are not populated until they're actually used and b) if they're called post-main() they get repopulated with the translations. Another useful func is expandDollarRefs(): map["HOME"] = getenv("HOME"); string foo = expandDollarRefs( "${HOME}/.myconfig", map ); or: foo = "${HOME}/.myconfig"; expandDollarRefsInline( foo, map ); // edits foo in-place Then, of course, there's the well-overused lexical casting: string s = StringTool::to(myobj); // tostring MyType m = StringTool::from("value"); // fromstring There's a small demo under test/StringToolTest.cpp: tringToolTest.cpp:18 : StringTool tests... StringToolTest.cpp:29 : string: [this $bar is a ${foo} input ${bar}. $UNMAPPED_VAR, \ \ \\ ${} $ \$ escaped \${foo}.] expanded: [this BARBAR is a FOOFOO input BARBAR. $UNMAPPED_VAR, \ \ \\ ${} $ $ escaped ${foo}.] StringToolTest.cpp:33 : escaped string: [this \$bar is a \${foo} input \${bar}. \$UNMAPPED_VAR, \ \ \\ \${} \$ \\$ escaped \\${foo}.] pre-escaped, expanded: [this $bar is a ${foo} input ${bar}. $UNMAPPED_VAR, \ \ \\ ${} $ \$ escaped \${foo}.] StringToolTest.cpp:46 : reference string=[this is a '<"test string">'. $GOODGRIEF!] StringToolTest.cpp:48 : 7 translated: [this is a '<"test string">'. excellent!] StringToolTest.cpp:50 : 7 reverse translated: [this is a '<"test string">'. $GOODGRIEF!] -- ----- 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-26 09:12:37
|
Yo! You didn't think i'd gone to bed yet, did you? ;) Unhappy with all the template work necessary for working with the s11n core, i've wrapped it up in a small, easily-understand client-side interface: <pclasses/s11n/SIO.h> declares namespace P::SIO, which encapsulates the majority of the client-side s11n API. It's functions and typedefs follow PNamingConventions, not s11n_naming_conventions. This should allow a decent compromise for the non-conforming naming conventions in s11n's code. To save any Serializable object in P is now trivial: #include <pclasses/s11n/SIO.h> ... using P::SIO; save( obj, string|stream ); Saves using the SIO::serializerClass() Serializer, which is set via serializerClass(classname). Default is of course expat, because that's all we have at the moment. Loading has 3 options: #1: MyType * t = 0; S11nNode * node = loadNode( file|stream ); if( node ) { t = deserialize<MyType>( *node ); delete node; } Reminder: you don't need to know the input format: any loaded/loadable format will do. #2: MyType t; S11nNode * node = loadNode( file|stream ); if( node ) { bool worked = deserialize<MyType>( *node, t ); delete node; } #3: MyType * t = loadSerializable<MyType>( file|stream ); Once the IOManager support is ready this will also support protocol-based dispatching. Also, as the IODev/IOStream support gets all ported in i will add overloads to de/serialize from/to those types. Any comments on the interface would be helpful! src/s11n/SIO.h. 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-26 06:31:07
|
This is an interesting little feature: typedef Factory<MyType> F; F & f = F::instance(); f.registerFactory( "MyType", MyType::createNewInstance ); f.alias( "AnAlias", "MyType" ); MyType * m = f.create( "AnAlias" ); Since PluginManager extends Factory, we can do some more subtle tricks with it, like aliasing DLL names or simulating symlinks by aliasing /P/plugins/mypluginname to /real/path/to/mypluginname.so. Or alias http://path/to/s11n/data to ~/foo.s11n (or vice versa). Setting up a "virtual filesystem" to factories/DLLs this way might be really interesting to consider: /P/plugins, /P/devices, /P/protocols... That would require slighty different aliasing support (the current support is word-based, whereas /P/... effectively needs partial string search support). Anyway... There's *all kinds* of evil we can do with this. :) This has some nice benefits for code maintenance: we can use aliases in code and allow the user to re-map their own types to those aliases via config files and whatnot. For example, in client code we write: DocumentType * d = f.create( "default-document-class" ); The factory could expect "default-document-class" to come from the DocumentPluginManager, which reads ~/.myapprc (or equivalent) to get the info. For example, the user maps this in his configuration data: default-document-class = MySpecialDocType During plugin initialization, the DocumentPluginManager simply converts config info to: Factory<Document>.alias( default-document-class", "MySpecialDocType" ); MySpecialDocType must, of course, be linked in or be found in MySpecialDocType.{so,dll}. -- ----- 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-26 05:03:04
|
On Sunday 26 December 2004 05:41, stephan beal wrote: > - Dynamic selection of Serializers when loading from streams "might" > work, and might not. This works, by the way. This means any Serializers you write will be hot-pluggable into 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-26 04:43:20
|
Saving over XML works now: stephan@owl:~/cvs/pclasses2/test> m && ./s11nTest <snip> s11nTest.cpp:117 : Loaded serializer 'expat'. :) s11nTest.cpp:131 : Adding [this is item #0] <snip> s11nTest.cpp:131 : Adding [this is item #9] s11nTest.cpp:138 : Containers... <!DOCTYPE P::s11n::io::expat_serializer> <s11n_node class="list"> <s11n_node class="LexT"> <v>this is item #0</v> </s11n_node> <snip> <s11n_node class="LexT"> <v>this is item #9</v> </s11n_node> </s11n_node> <!DOCTYPE P::s11n::io::expat_serializer> <s11n_node class="map"> <pair class="pair"> <first class="int"> <v>0</v> </first> <second class="LexT"> <v>this is item #0</v> </second> </pair> <snip> <pair class="pair"> <first class="int"> <v>9</v> </first> <second class="LexT"> <v>this is item #9</v> </second> </pair> </s11n_node> #define SERIALIZE(Node,SType,SObj) ::P::s11n::serialize< NODE_TYPE >( Node, SObj ) #define DESERIALIZE(Node,SType) ::P::s11n::deserialize< NODE_TYPE, SType >( Node ) #define TRAITS ::P::s11n::node_traits< NODE_TYPE > The code to get at the Serializer is something like: // get the base Serializer interface type: typedef ::P::s11n::io::data_node_serializer<::P::s11n::s11n_node> SerializerBase; // ugly, eh? i'll simplify that later. // load it via the plugin manager: SerializerBase * ser = ::P::Plugin::pluginManager<SerializerBase>().create( "expat" ); Things to note: - P module deps: Core, System, Plugin, Util - The serializers are loaded by name, just like other classes. DLL support "should" work for them just like it does for all PluginManaged types. - The expat serializer is linked in if configure finds expat, otherwise not. Since this is the only Serializer we will have until someone implements more non-lex-based ones, you essentially NEED expat at the moment to use ps11n stream/file i/o. See src/s11n/io/expat/expat_serializer.* for ideas on how to implement a Serializer for your own format. - The interface will be refactored to make it more P-friendly, but this will take time. The huge number of typedefs and template args will also be reduced by introducing another interface layer (a-la s11nlite). - Dynamic selection of Serializers when loading from streams "might" work, and might not - it is untested so far (if it's broken, it's a factory-related issue and will be easy to fix). - We should decide on what serializable interface Serializable types will have. We don't NEED to decide this, because s11n can adapt to near-arbitrary interfaces, but we should, for consistency. There is also a decision to be made about which "node type" to support by default, but i need to explain that in detail before we can decide that (and i'm too tired to do that right now). i'll go into these details more later, because they are rather more complex than they should be ("Quall der Wahl" is the real problem). - Now that s11n is in the P tree, and free of the "platform-sensitive" code, my baby (s11n) is now portable :). It also means our questions about how best to integrate s11n support are answered. -- ----- 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-26 04:07:52
|
i realized an hour ago that there is one Serializer in s11n which is build-portable (most need flex): expat_serializer. So... i've ported in the "basic" i/o layer and the expat serializer. i haven't yet tested it since porting the factory code to P, but it at least builds and links after the changes. The only significant feature which was lost in this transition was the transparent support for compressed files. i have a feeling that will be added to P at some point, though :). What this means is that we'll have access to at least one file-capable Serializer soon, but this requires linking against libexpat (which is already on most Unix machines). This port of the s11n tree is helping me figure out what needs to change in s11n 1.1 :). Good night! -- ----- 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-26 00:36:51
|
On Sunday 26 December 2004 00:23, stephan beal wrote: > The s11n core itself is some 50 lines of code, so it will be trivial > to plug it in directly to the P tree. You're not going to believe this, but... i'm done. Well, i mean: a) i've pulled in the absolute minimum needed to build the core interface and all of the various algos/proxies. (The core is tiny, but without algos it's useless.) b) it compiles under the P tree, after changing some of the code to use P types, like the Factory and LexT. It still needs to be tested and some minor changes made, of course. Caveats: a) Porting the entire code to the P naming conventions won't be practical, i think. The main problem is that the word 's11n' shows up *everywhere* in this tree. b) i have kept the module name 's11n', not 'S11n', because changing it would probably require that i do (a). i will move it into the P::s11n namespace, but it's currently under ::s11n. c) there is no i/o layer, which means no file formats whatsoever are supported at this point. We can, however, build complete de/ser support without any file i/o, as de/ser is, from the client's perspective, container-based. d) there are currently several util namespaces which should go away. But it builds. If the general naming conventions are a problem let me know and i will attempt to sed the classes. One advantage to allowing the P::s11n namespace to follow s11n's existing naming conventions is that i can freely swap code between the two projects and be confident that renamings didn't break anything. i agree that it would be nicer to rename the types, 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-25 23:24:48
|
Yo! Marc and i just had a long IRC discussion, and i can't believe i never thought of this earlier: The s11n core itself is some 50 lines of code, so it will be trivial to plug it in directly to the P tree. i'll need to port in supporting algos and types, but i will not bring in the i/o layer (the biggest part, by far). i can swap out the factory layer with little work, as well. This will allow us to put serialization in place anywhere in P (where it's practical/useful), without an external dep on s11n. We can worry about the i/o layer later, either linking against s11n's, providing our own porting in s11n's i/o layer (which would need some serious rework, i think, to remove a lot of deps),or whatever. The important part of serialization is the core container framework - the actual stream i/o is a bonus. The new module will be P::S11n, of course. Unfortunately, the naming conventions in the s11n code won't all be easily sed'able to P naming conventions (try "grep s11n *" ;), and that will take some time to fix, but otherwise the port should be pretty straightforward. An interesting thing about this is: by leaving out the i/o layer, we immediately lose the only platform-dependent part which s11n has! That means P::S11n will be inherently portable to all P-support platforms. :) -- ----- 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-25 21:44:22
|
On Saturday 25 December 2004 22:10, Marc Duerner wrote: > The STL has ext for this. Would you like something like P::Ext? i didn't know the STL used any namespace except std. Interesting. i honestly don't care what we call it. Ext is fine. i thought it might fit into Exp, but Exp isn't in P2 yet, and i don't know if there are plans to port it from P1. (???) -- ----- 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-25 21:39:43
|
Here is my experimental Prefs code. I have to free the phoneline now (again sigh!). Can you send me your PropertyStore code? regards. Marc |
From: stephan b. <st...@s1...> - 2004-12-25 21:38:53
|
On Saturday 25 December 2004 21:33, Marc Duerner wrote: > Can I look at your PropertyStore. It should be possible to fuse that > with Prefs in some way. It sounds like that wouldn't be a problem. > I can see that such a type would not only be > useful for Prefs/AppConfig. the template-based type conversions would be trivial to integrate into your existing structure. The sources: If you have the s11n src tree: libs11n_acme-VERSION/src/property_store.?pp A couple other classes in that dir subclass that one: environment.?pp argv_parser.?pp If you don't have the source tree, you can grab acme code here: http://s11n.net/download/#acme -- ----- 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-25 21:36:24
|
The STL has ext for this. Would you like something like P::Ext? Marc On Saturday 25 Dec 2004 21:36, stephan beal wrote: > Hiya! > > i've got some string utility code i'd like to bring in to support the > App module, and i'm not sure where to put it. Basically it is these > functions: > > - generic entity un/expansion algos for use with, e.g. HTML, XML. Used > extensively by s11n's file parsers. > - lexical casting API (this code existed long before Util::LexT did). > - perl-like split() and join(). > > i'd also like to move the $VAR expansion code there, as i can implement > it in terms of the entity expansion code, which means it won't be > specific to Environment. > > Anyway, some ideas about where to put this: > > - Util > - new module, but don't call it String or Util::String, to avoid > confusion with Unicode::String. Don't call it Str, because that could > also mean Stream. > - Exp (is that were Regex goes bzw will go?) > - new module, P::UseAtOwnRisk > - new module, P::Foo > > Where to put it? These are important for the App bzw ShellApp code, so > i'd like to get them pulled in, renamed, etc. > > Speaking of regex: reimplementing the entity expansion routines using > Regex would be cool. > > > ??? |
From: Marc D. <bdu...@gm...> - 2004-12-25 21:31:58
|
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) 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. > 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! |
From: stephan b. <st...@s1...> - 2004-12-25 20:38:11
|
Hiya! i've got some string utility code i'd like to bring in to support the App module, and i'm not sure where to put it. Basically it is these functions: - generic entity un/expansion algos for use with, e.g. HTML, XML. Used extensively by s11n's file parsers. - lexical casting API (this code existed long before Util::LexT did). - perl-like split() and join(). i'd also like to move the $VAR expansion code there, as i can implement it in terms of the entity expansion code, which means it won't be specific to Environment. Anyway, some ideas about where to put this: - Util - new module, but don't call it String or Util::String, to avoid confusion with Unicode::String. Don't call it Str, because that could also mean Stream. - Exp (is that were Regex goes bzw will go?) - new module, P::UseAtOwnRisk - new module, P::Foo Where to put it? These are important for the App bzw ShellApp code, so i'd like to get them pulled in, renamed, etc. Speaking of regex: reimplementing the entity expansion routines using Regex would be cool. ??? -- ----- 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-25 19:23:34
|
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) 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. 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. 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-25 18:08:18
|
Yo! We talked the other day about why Mime is currently in System. Here i will go through some properties of MimeType and MimeTypeDb, and try to figure out what module they belong to: - Dependencies-wise, MimeTypeDb needs Plugin (or at least Factory) and some minimal i/o support to read the platform-dependent mime.types (std::iostreams will do), plus System::PathFinder (to provide several convenience functions). It does not need anything from Net, nor specifically from the IO module. - Reading the mime.types is platform-dependent, and platform-dep code conventionally goes into System. - MimeType itself is basically a Pair<String,String>, and provides no platform-specific functionality. - The idea of mime types is applicable to a range of things, from application dispatcher to classloading (app loading is only a special case of classloading). Keeping it as "low in the dependency chain as feasible" helps make it more accessible to clients. Okay, so i will now argue the following: MimeType ==> Core MimeTypeDb ==> System (for deps/features reasons) ??? -- ----- 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-25 17:37:20
|
Yo, In the last mail i wrote: > class Factory<InterfaceT,[ContextT,?]KeyT,Arg1T> { i thought i'd take a minute and explain why i have all these ContextType template args in the Factory and Phoenix classes. Let's consider this code: T & t1 = Phoenix<T>::instance(); T & t2 = Phoenix<T>::instance(); In this case, t1 == t2. That might be just what we want, but we might want part of an app to have a shared T which isn't seen by everyone else. And we also want the post-main() safety of Phoenix. No problem - we use a context type: struct my_context {}; T & t1 = Phoenix<T>::instance(); T & t2 = Phoenix<T,my_context>::instance(); Now t1 != t2. Any client code who knows the right combination of T and context can get at a Phoenix<T,ctx>. Another implication is that the context allows Factory<T,ctx> to restrict the sharing of factories. For example, if we want the IOManager to use the P-wide shared factories, we use P::Sharing::FactoryContext (the default ctx used by Factory). If we want IOManager to use it's own restricted pool of factories, we can use another arbitrary context type. Using the default FactoryContext is generally a good idea, because it means that registrations which come in via DLLs are available to Factories which didn't open the DLL. The down-side is that if two plugins use the same logical name and same InterfaceT, then we will have a factory collision (in which case we fix it by forcing one of them to use another ContextType). Actualy - if the 2 factories both provide the same behaviour (return new T) then such a factory collision is actually a non-error/no-op. The shared objects served by Phoenix not true singletons because we can still do: T * t3 = new T; They are also not Monostates unless T is designed as a Monostate. i don't really have a good name for this type of shared object, so i call them "context singletons." That is "singletons within a certain context." -- ----- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |