Menu
▾
▴
pclasses-devel — P::Classes developer mailing-list
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(188) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(59) |
Feb
(13) |
Mar
(4) |
Apr
(1) |
May
(15) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Christian P. <cp...@se...> - 2005-02-26 23:24:44
|
On Saturday 26 February 2005 17:58, stephan beal wrote: > On Saturday 26 February 2005 17:51, stephan beal wrote: > > The warning is correct, as 0xff requires 16 > > bits, whereas sizeof(char) is normaly 1 byte. > > Sorry, i'm an idiot: 0xff only needs 8 bits: f=3D1111, f=3D1111. Hmm ... i don't understand this warning cause the comparsion is against an unsigned= =20 char, which can hold 0xff. wtf ? Greetings, Christian =2D-=20 Programmieren hat etwas von einem Rausch an sich, das schwer zu erkl=E4ren = ist.=20 Es ist diese Suche nach dem Gral, die mich vorantreibt. |
|
From: stephan b. <st...@s1...> - 2005-02-26 17:02:18
|
On Saturday 26 February 2005 17:51, stephan beal wrote: > The warning is correct, as 0xff requires 16 > bits, whereas sizeof(char) is normaly 1 byte. Sorry, i'm an idiot: 0xff only needs 8 bits: f=1111, f=1111. -- ----- 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...> - 2005-02-26 16:55:27
|
Hiya!
g++ -pipe -Wall -Werror -g -DDEBUG -D_DEBUG -fPIC -I. -I../../include
-c -o URL.o URL.cpp
URL.cpp: In function `bool P::IO::charNeedEncode(unsigned char)':
URL.cpp:576: warning: comparison is always true due to limited range of
data
type
Code is pretty detailed, and i'm afraid to just change it:
bool charNeedEncode(unsigned char ch)
{
bool ret = false;
if((ch <= 0x1f) || (ch == 0x7f) || // ASCII control characters...
(ch >= 0x80 && ch <= 0xff) || // non-ASCII characters ...
(ch == 0x24) || (ch == 0x26) || // reserved characters...
(ch == 0x2b) || (ch == 0x2c) ||
(ch == 0x2f) || (ch == 0x3a) ||
(ch == 0x3b) || (ch == 0x3d) ||
(ch == 0x3f) || (ch == 0x40) ||
(ch == 0x20) || (ch == 0x22) || // unsafe characters ...
(ch == 0x3c) || (ch == 0x3e) ||
(ch == 0x23) || (ch == 0x25) ||
(ch == 0x7b) || (ch == 0x7d) ||
(ch == 0x7c) || (ch == 0x5c) ||
(ch == 0x5e) || (ch == 0x7e) ||
(ch == 0x5b) || (ch == 0x5d) ||
(ch == 0x60))
ret = true;
return ret;
}
Line 576 is the 'non-ASCII' line. It only shows up with -Wall -Werror
(which i -Walways use ;). The warning is correct, as 0xff requires 16
bits, whereas sizeof(char) is normaly 1 byte.
--
----- 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...> - 2005-02-19 23:09:04
|
An interesting note about the s11n layer: i've never tested s11n with more than about 150k data objects (PODs + full objects) at any given time. i didn't think it could hold more than a few hundred thousand objects before running out of memory because it internally uses at LEAST 1 std::map and lots of std::strings for each node. However... One user wrote last week to say he's using it for a data set of 10 million objects(!!!). See the mail below for how he's using it. He sent me some rough timing info: 3 minutes to load 1GB of s11n'd XML data (his 10M nodes), which adds up to 55k nodes per second. That is extremely close to my local timings (though on much smaller data sets), which range from 20k-50k/second, depending on the parser (expat is fastest, IIRC). Loading that same data set using the mysql_serializer would take... approximately 16.5 days, theoretically (it's implementation is EXTREMELY inefficient). Anyway... i thought it was good news that the s11n layer which is now in P2 can hold up to those types of input amounts, and does so relatively quickly. ---------- Forwarded Message ---------- Subject: [S11n-devel] FWD: 10^7 Date: Tuesday 15 February 2005 14:40 From: stephan beal <st...@s1...> To: s11...@li... Cc: James McCann <jm...@es...> This impressed the hell out of me... i had to forward it to the list: On Monday 14 February 2005 05:28, Paul Balomiri wrote: >... By The way, Your Architecture has brought > my program to a state where I successfully load/save a map of vienna, > with all streets, and over 10^7 datapoints assigned to them. WOW! (@Paul, i'm gonna quote that on the web site if you don't mind.) We're considering some options for custom NodeTypes to do that more efficiently. i would never have thought someone could process 10^7 items in the lib, given it's heavy reliance on std::string and lexical casts. That really says something about the std::string implementation, actually. 10^7 == 10,000,000 The most i've ever tried is about 150k nodes/properties. -- ----- 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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ S11n-devel mailing list S11...@li... https://lists.sourceforge.net/lists/listinfo/s11n-devel ------------------------------------------------------- -- ----- 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...> - 2005-02-19 20:09:15
|
stephan@owl:~/cvs/pclasses2> cz up -dPA <5 minutes later...> cvs.sourceforge.net: Connection timed out cvs [update aborted]: end of file from server (consult above messages if any) :`( -- ----- 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...> - 2005-02-19 20:02:08
|
On Friday 18 February 2005 12:08, Christian Prochnow wrote: > Flex maybe isnt a problem if we distribute the autogenerated > flex-parser. That way win32 users should be able to build it without > having flex for win32. If it's that easy i'll be very happy. i'll try porting in one of them and see what happens. > > Any specific wishes? > > My biggest wish: a PluginRegistry. i think about that a lot, actually. i'm still not 100% clear what we need to do with it bzw what it need to do. a) keep track of which plugins are loaded. b) allow us to close plugins (or auto-close them somehow). c) provide a factory-like interface. The major problem i see is still the dlclose() thing. We can never 100% reliably know when all resources included by a DLL are freed up, so we cannot know when it is 100% safe to dlclose(). For most apps this is not a problem, because they can wait for the OS to close the dll at app shutdown. For P, which intends to be system-level, such behaviour is definitely a potential source of huge leaks :(. So the close problem has to be solved, but i haven't got any clever ideas. Anything else? -- ----- 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...> - 2005-02-18 11:08:21
|
On Thursday 17 February 2005 22:30, stephan beal wrote: > Yo, guys! Welcome back to life ! > My lebenschaos is settling down somewhat and i believe my online life is > starting back up again :). My plan this weekend is to code on P. i > wanted to ask, since i have about 3 weeks of catching up to do: what > are the priorities/wishes at the moment? My priorities: =2D Finish signal-/ event-handling stuff =2D Add Process-Timers =2D Finish async I/O =2D Implement async notifications for Process, Pipe, ... =2D Re-implement the HTTPClient/FTPClient as I/O-independent "Protocol"-cla= sses=20 to allow usage for async and sync I/O (ugh!). =2D Implement protocol-transparent Network File I/O. > My own personal priority is to port in at least one of the s11n parsers > to the P tree (they are flex-based, which isn't Windows-friendly). The > main problem with that is, the idea of writing Yet Another Parser makes > me sick to my stomach. So i'm looking for some other piece of code to > distract me. =46lex maybe isnt a problem if we distribute the autogenerated flex-parser. That way win32 users should be able to build it without having flex for win= 32. > Any specific wishes? My biggest wish: a PluginRegistry. Greetings, Christian =2D-=20 Programmieren hat etwas von einem Rausch an sich, das schwer zu erkl=E4ren = ist.=20 Es ist diese Suche nach dem Gral, die mich vorantreibt. |
|
From: stephan b. <st...@s1...> - 2005-02-17 21:33:59
|
Yo, guys! My lebenschaos is settling down somewhat and i believe my online life is starting back up again :). My plan this weekend is to code on P. i wanted to ask, since i have about 3 weeks of catching up to do: what are the priorities/wishes at the moment? My own personal priority is to port in at least one of the s11n parsers to the P tree (they are flex-based, which isn't Windows-friendly). The main problem with that is, the idea of writing Yet Another Parser makes me sick to my stomach. So i'm looking for some other piece of code to distract me. Any specific wishes? -- ----- 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...> - 2005-02-17 14:40:20
|
Hi Marc ! IdeDevice.linux.cpp does not compile ! Please fix it.=20 /home/cproch/src/pclasses2/src/System/IdeDevice.linux.cpp:32: error: parse= =20 error before numeric constant /home/cproch/src/pclasses2/src/System/IdeDevice.linux.cpp:33: error:=20 declaration of `P::System::IdeDevice::IdeDevice(const std::string&,=20 P::IO::IODevice::AccessMode, P::IO::IODevice::ShareMode)' throws different= =20 exceptions /home/cproch/src/pclasses2/include/pclasses/System/IdeDevice.h:48: error: t= han=20 previous declaration `P::System::IdeDevice::IdeDevice(const std::string&,=20 P::IO::IODevice::AccessMode, P::IO::IODevice::ShareMode) throw=20 (P::IO::IOError)' /home/cproch/src/pclasses2/src/System/IdeDevice.linux.cpp: In constructor ` P::System::IdeDevice::IdeDevice(const std::string&,=20 P::IO::IODevice::AccessMode, P::IO::IODevice::ShareMode)': /home/cproch/src/pclasses2/src/System/IdeDevice.linux.cpp:40: error: parse= =20 error before `::' token /home/cproch/src/pclasses2/src/System/IdeDevice.linux.cpp: At global scope: /home/cproch/src/pclasses2/src/System/IdeDevice.linux.cpp:79: error: parse= =20 error before numeric constant /home/cproch/src/pclasses2/src/System/IdeDevice.linux.cpp:80: error:=20 declaration of `void P::System::IdeDevice::open(const std::string&,=20 P::IO::IODevice::AccessMode, P::IO::IODevice::ShareMode)' throws different= =20 exceptions /home/cproch/src/pclasses2/include/pclasses/System/IdeDevice.h:53: error: t= han=20 previous declaration `void P::System::IdeDevice::open(const std::string&,=20 P::IO::IODevice::AccessMode, P::IO::IODevice::ShareMode) throw=20 (P::IO::IOError)' /home/cproch/src/pclasses2/src/System/IdeDevice.linux.cpp: In member functi= on=20 ` void P::System::IdeDevice::open(const std::string&,=20 P::IO::IODevice::AccessMode, P::IO::IODevice::ShareMode)': /home/cproch/src/pclasses2/src/System/IdeDevice.linux.cpp:84: error: parse= =20 error before `::' token /home/cproch/src/pclasses2/src/System/IdeDevice.linux.cpp: At global scope: /home/cproch/src/pclasses2/src/System/IdeDevice.linux.cpp:87: error: parse= =20 error before numeric constant /home/cproch/src/pclasses2/src/System/IdeDevice.linux.cpp:88: error:=20 declaration of `virtual void P::System::IdeDevice::_close()' throws differe= nt=20 exceptions /home/cproch/src/pclasses2/include/pclasses/System/IdeDevice.h:68: error: t= han=20 previous declaration `virtual void P::System::IdeDevice::_close() throw=20 (P::IO::IOError)' /home/cproch/src/pclasses2/src/System/IdeDevice.linux.cpp:93: error: parse= =20 error before numeric constant /home/cproch/src/pclasses2/src/System/IdeDevice.linux.cpp:94: error:=20 declaration of `virtual size_t P::System::IdeDevice::_read(char*, long=20 unsigned int)' throws different exceptions /home/cproch/src/pclasses2/include/pclasses/System/IdeDevice.h:69: error: t= han=20 previous declaration `virtual size_t P::System::IdeDevice::_read(char*, lon= g=20 unsigned int) throw (P::IO::IOError)' /home/cproch/src/pclasses2/src/System/IdeDevice.linux.cpp:98: error: parse= =20 error before numeric constant /home/cproch/src/pclasses2/src/System/IdeDevice.linux.cpp:99: error:=20 declaration of `virtual size_t P::System::IdeDevice::_peek(char*, long=20 unsigned int)' throws different exceptions /home/cproch/src/pclasses2/include/pclasses/System/IdeDevice.h:70: error: t= han=20 previous declaration `virtual size_t P::System::IdeDevice::_peek(char*, lon= g=20 unsigned int) throw (P::IO::IOError)' /home/cproch/src/pclasses2/src/System/IdeDevice.linux.cpp:104: error: parse= =20 error before numeric constant /home/cproch/src/pclasses2/src/System/IdeDevice.linux.cpp:105: error:=20 declaration of `virtual size_t P::System::IdeDevice::_write(const char*, lo= ng=20 unsigned int)' throws different exceptions /home/cproch/src/pclasses2/include/pclasses/System/IdeDevice.h:71: error: t= han=20 previous declaration `virtual size_t P::System::IdeDevice::_write(const=20 char*, long unsigned int) throw (P::IO::IOError)' /home/cproch/src/pclasses2/src/System/IdeDevice.linux.cpp:110: error: parse= =20 error before numeric constant /home/cproch/src/pclasses2/src/System/IdeDevice.linux.cpp:111: error:=20 declaration of `virtual offset_t P::System::IdeDevice::_seek(int,=20 P::IO::IODevice::SeekMode)' throws different exceptions /home/cproch/src/pclasses2/include/pclasses/System/IdeDevice.h:72: error: t= han=20 previous declaration `virtual offset_t P::System::IdeDevice::_seek(int,=20 P::IO::IODevice::SeekMode) throw (P::IO::IOError)' /home/cproch/src/pclasses2/src/System/IdeDevice.linux.cpp:120: error: parse= =20 error before numeric constant /home/cproch/src/pclasses2/src/System/IdeDevice.linux.cpp:121: error:=20 declaration of `virtual void P::System::IdeDevice::_sync() const' throws=20 different exceptions /home/cproch/src/pclasses2/include/pclasses/System/IdeDevice.h:74: error: t= han=20 previous declaration `virtual void P::System::IdeDevice::_sync() const thro= w=20 (P::IO::IOError)' /home/cproch/src/pclasses2/src/System/IdeDevice.linux.cpp:125: error: parse= =20 error before numeric constant /home/cproch/src/pclasses2/src/System/IdeDevice.linux.cpp:126: error:=20 declaration of `virtual offset_t P::System::IdeDevice::_size() const' throw= s=20 different exceptions /home/cproch/src/pclasses2/include/pclasses/System/IdeDevice.h:75: error: t= han=20 previous declaration `virtual offset_t P::System::IdeDevice::_size() const= =20 throw (P::IO::IOError)' gmake[2]: *** [IdeDevice.linux.lo] Error 1 gmake[1]: *** [all-recursive] Error 1 gmake: *** [all-recursive] Error 1 =2D--------- Forwarded Message ---------- Subject: [pclasses-cvs] pclasses2/src/System IdeDevice.linux.cpp,NONE,1.1=20 Makefile.am,1.13,1.14 Date: Monday 14 February 2005 19:40 =46rom: Marc Duerner <ma...@us...> To: pcl...@li... Update of /cvsroot/pclasses/pclasses2/src/System In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21882/src/System Modified Files: Makefile.am Added Files: IdeDevice.linux.cpp Log Message: added System::IdeDevice Index: Makefile.am =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvsroot/pclasses/pclasses2/src/System/Makefile.am,v retrieving revision 1.13 retrieving revision 1.14 diff -u -d -r1.13 -r1.14 =2D-- Makefile.am 7 Feb 2005 18:41:07 -0000 1.13 +++ Makefile.am 14 Feb 2005 18:40:39 -0000 1.14 @@ -73,7 +73,7 @@ Time_Sources =3D SystemClock.win32.cpp endif =2DSystem_Sources =3D CdRomDevice.linux.cpp +System_Sources =3D CdRomDevice.linux.cpp IdeDevice.linux.cpp EXTRA_DIST =3D CriticalSection.generic.cpp CriticalSection.win32.cpp \ Mutex.solaris.cpp Mutex.posix.cpp Mutex.win32.cpp SharedMemory.sysv.cpp \ =2D-- NEW FILE: IdeDevice.linux.cpp --- (This appears to be a binary file; contents omitted.) =2D------------------------------------------------------ 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://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick _______________________________________________ pclasses-cvs mailing list pcl...@li... https://lists.sourceforge.net/lists/listinfo/pclasses-cvs =2D------------------------------------------------------ =2D-=20 Programmieren hat etwas von einem Rausch an sich, das schwer zu erkl=E4ren = ist.=20 Es ist diese Suche nach dem Gral, die mich vorantreibt. |
|
From: stephan b. <st...@s1...> - 2005-01-22 17:52:30
|
On Saturday 22 January 2005 13:00, Christian Prochnow wrote: > For this to work we have to add reference-counting to the Factories, > which implies that we also need to track object destruction, and this > is where it gets tricky. No we don't - a factory has NO relationship to the object which created it (normally, anyway). It is theoretically possible for a factory to track the objects it creates, but doing so is inflexible and non-generic. If we destroy a factory that has NO effect on the objects it creates. > I don't like the idea of having an implicit GC thread. Another way to do it is run the cleanup every X times that Factory::create() is called. > But wee also need some "plugin filesystem registry" which tells the P > plugin loader which shared objects must be loaded for a particular > class type that should be constructed. Yeah, that's a whole different matter. > We actually have two different problems: > 1. Plugin registry (only load plugin-lib's that are really needed) > 2. Factory reference counting (cleanup of unused factories) i'll give it some thought. i don't see a way to do (1) without providing some sort of file to map classes to DLLs. -- ----- 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...> - 2005-01-22 12:00:11
|
Am Donnerstag 20 Januar 2005 18:45 schrieb stephan beal: > A potential solution came to mind today: > > When Factory::create(classname) is called, we count how many times any > given classname is passed. In a garbage collector thread we iterate the > factory maps every now and then and remove any factories which have 0 > hits. For this to work we have to add reference-counting to the Factories, which implies that we also need to track object destruction, and this is where it gets tricky. > The implementation for the actual tracking would be fairly trivial: one > more map added to Factory, which gets modified during create(), plus a > cleanup function: as i said, it's not that trivial. We could add a wrapper template which does the reference counting for class-types created by the factories. > The GC thread would then call > Factory<T>::instance().cleanUnusedFactories() every X seconds (5+ > minutes is probably reasonable, or after every X factory registrations > we check for unused facs). i propose to make hitsMap() internal so that > we can achieve safe locking more easily. If hitsMap() is public we > don't need cleanXXX(), as any 3rd-party code could directly manipulate > the factory map. While this isn't a problem in and of itself, it might > become problematic in a multi-threaded environment. Thus the cleanXXX() > member, to simplify any potential locking. I don't like the idea of having an implicit GC thread. > More complex variants might track how long ago a given factory was used, > or how often, or use a LRU algo with some built-in limit of factories > to hold on to. But wee also need some "plugin filesystem registry" which tells the P plugin loader which shared objects must be loaded for a particular class type that should be constructed. We actually have two different problems: 1. Plugin registry (only load plugin-lib's that are really needed) 2. Factory reference counting (cleanup of unused factories) Greetings, Christian |
|
From: Christian P. <cp...@se...> - 2005-01-21 15:04:01
|
Am Freitag 21 Januar 2005 15:46 schrieb Christian Prochnow: > For this to work we have to add the export-macros to the class and global > method definitions. Friends must also be explicitly exported. > Keep in mind that template classes which are not fully specialized must not > be exported, cause the code does not reside in the shared library, instead > it is emitted on usage. sorry. template classes which are not fully specialized must not be exported. The code for fully specialized templates _does_ reside in the shared library, so they must be exported. Greetings |
|
From: Christian P. <cp...@se...> - 2005-01-21 14:46:13
|
Hi List !
I've added the class export-macros to the tree.
The export-macros are needed for the compiler/linker to know which classes
should be exported to the client-applications.
M$ compilers requires it, and gcc 4 will support it aswell.
Advantages:
- Smaller shared libraries
- Clients cannot access private (that is, not exported) classes/methods
For this to work we have to add the export-macros to the class and global
method definitions. Friends must also be explicitly exported.
Keep in mind that template classes which are not fully specialized must not be
exported, cause the code does not reside in the shared library, instead it is
emitted on usage.
example:
original code:
--
class Date {
public:
void mymethod();
friend void myfriend();
};
--
code with export macros:
--
class PCORE_EXPORT Date {
public:
void mymethod();
friend PCORE_EXPORT void myfriend();
};
--
Each module has its own export-macro residing in "include/pclasses/Export.h".
Please add the export-macros to the code you've already written !
Greetings,
Christian
|
|
From: Christian P. <cp...@se...> - 2005-01-21 13:27:51
|
Hi List! I've added the advanced command line parser to the App module. Please have a look at it and tell me what you guys think. See test/CmdLineTest.cpp for example usage. I'm going to add other CmdLineOption classes when the interface is stable. Greetings, Christian |
|
From: Marc D. <bdu...@gm...> - 2005-01-20 23:32:17
|
> > template <typename ValueType>
> > ValueType convertTo(const ValueType& defVal = ValueType()) const {
> > Any::holder<ValueType>* valHolder = 0;
> > valHolder = dynamic_cast< Any::holder<ValueType>* >(m_data);
> > if(valHolder) {
> > return valHolder->value();
> > }
> >
> > ValueType retVal(defVal);
> > std::stringstream ss;
> > m_data->output(ss);
> > ss >> retVal;
> > return retVal;
>
> This code will only compile if ValueType is i/ostreamable, which is
> almost guaranteed to NOT be the case for many uses of Any.
We dont neccessarily need the cast in the convertTo template function.
Types contained in Any have to be outputable already if you want to << an Any.
> > Does anybody see a problem with this?
>
> Technically i must admit, i don't see a major problem with it.
> "Internally", though, i would prefer to keep the distinction between
> lexically castable types and "any" type, mainly because of the
> guarantees each can/cannot provide.
Ok, if everyone hates the idea I would just add a convertTo template function
to Any that tries stream based conversion:
template <typename ValueType>
ValueType convertTo(const ValueType& defVal = ValueType()) const {
ValueType retVal(defVal);
std::stringstream ss;
m_data->output(ss);
ss >> retVal;
return retVal;
}
which means that Any can do everything Variant can do except that map<Variant,
Variant> is possible while map<Any, Any> is not.
Marc
|
|
From: stephan b. <st...@s1...> - 2005-01-20 21:45:23
|
Yo! Going back to the idea of a plugin registry for a moment... Some background detail to explain why this is useful, and arguably even necessary: The current classloader/factory model allows any number of classes to register themselves with our factories, even if we have 0% chance of ever using those classes in our code. While this isn't a major problem for most purposes, for P this extra potential bloat might become a problem when P is acting as, e.g., a service provider for many applications running on the system (ArkLinux or Helvetix). i.e., if the uptime of the system is also the uptime of P, then this could essentially result in a long-term leak. In the case where P is used only for individual apps, as opposed to a framework, i think the potential "leak" is irrelevant, as closing the app cleans the couple-byte leak. (To be clear, it's not *really* a leak, but it is a blatant waste of resources.) A potential solution came to mind today: When Factory::create(classname) is called, we count how many times any given classname is passed. In a garbage collector thread we iterate the factory maps every now and then and remove any factories which have 0 hits. The implementation for the actual tracking would be fairly trivial: one more map added to Factory, which gets modified during create(), plus a cleanup function: public: size_t cleanUnusedFactories(); // returns # of factories cleaned private: static map<string,size_t> & hitsMap(); // maps classnames to create() call counts The GC thread would then call Factory<T>::instance().cleanUnusedFactories() every X seconds (5+ minutes is probably reasonable, or after every X factory registrations we check for unused facs). i propose to make hitsMap() internal so that we can achieve safe locking more easily. If hitsMap() is public we don't need cleanXXX(), as any 3rd-party code could directly manipulate the factory map. While this isn't a problem in and of itself, it might become problematic in a multi-threaded environment. Thus the cleanXXX() member, to simplify any potential locking. More complex variants might track how long ago a given factory was used, or how often, or use a LRU algo with some built-in limit of factories to hold on to. ??? -- ----- 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...> - 2005-01-20 21:45:23
|
On Thursday 20 January 2005 04:41, Marc Duerner wrote:
> I just had the idea that one could unify P::Util::Any and
> P::Util::Variant. They do basically both the same, but Any uses
> typeid and casting, while Variant (the class formerly known as LexT)
> uses stream based conversion.
Personally i would prefer to keep Variant and Any separate. They are
conceptually very similar, but in usage they are MUCH different beasts
and give much different guarantees regarding casts. Variant does use
any casting, for example, whereas Any *relies* on casting.
> template <typename ValueType>
> ValueType convertTo(const ValueType& defVal = ValueType()) const {
> Any::holder<ValueType>* valHolder = 0;
> valHolder = dynamic_cast< Any::holder<ValueType>* >(m_data);
> if(valHolder) {
> return valHolder->value();
> }
>
> ValueType retVal(defVal);
> std::stringstream ss;
> m_data->output(ss);
> ss >> retVal;
> return retVal;
This code will only compile if ValueType is i/ostreamable, which is
almost guaranteed to NOT be the case for many uses of Any.
> The dynamic_cast is a short cut.
It's not always syntactically possible to consolidate such type-based
shortcuts in the same code, without using middle-man template classes
and dispatching the different handlers via template specializations.
For example:
template <class T>
void foo( const T & )
{
... we'll see the body in a moment...
}
Obj * o = new Obj;
foo( o ); // legal
Obj o2;
foo( o2 ); // also legal
Now what should the body of foo() look like?
Imagine that we need to do this:
if( T is a pointer type ) { delete t; }
else { do nothing; }
that can't be syntactically consolidated in the same code. Won't compile
because delete t is not valid when T is not a pointer type.
> Does anybody see a problem with this?
Technically i must admit, i don't see a major problem with it.
"Internally", though, i would prefer to keep the distinction between
lexically castable types and "any" type, mainly because of the
guarantees each can/cannot provide.
--
----- 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...> - 2005-01-20 18:58:40
|
Am Donnerstag 20 Januar 2005 04:41 schrieb Marc Duerner:
> I just had the idea that one could unify P::Util::Any and P::Util::Variant.
> They do basically both the same, but Any uses typeid and casting, while
> Variant (the class formerly known as LexT) uses stream based conversion.
I also had this idea.
> This would simply require to add a convertTo member function to Any that
> allows stream based conversion additionally to the any_casts:
>
> template <typename ValueType>
> ValueType convertTo(const ValueType& defVal = ValueType()) const {
> Any::holder<ValueType>* valHolder = 0;
> valHolder = dynamic_cast< Any::holder<ValueType>* >(m_data);
> if(valHolder) {
> return valHolder->value();
> }
>
> ValueType retVal(defVal);
> std::stringstream ss;
> m_data->output(ss);
> ss >> retVal;
> return retVal;
> }
>
>
> The dynamic_cast is a short cut.
>
> In code you would do this:
>
> Any myAny(5);
> string s = myAny.convertTo<std::string>();
this rocks!
> or we add a type conversion member to Any that does this automatically:
>
> template <typename T>
> operator T() const throw() {
> return this->template convertTo<T>();
> }
>
>
> Does anybody see a problem with this?
No - please merge them. Maybe we should also move Any to the P namespace.
> Marc
Greetings,
Christian
|
|
From: Christian P. <cp...@se...> - 2005-01-20 09:29:19
|
Am Donnerstag 20 Januar 2005 02:47 schrieb stephan beal: > @the Germans: any plans for meeting in Ravensburg this weekend or > uebernaechstes? i would really like for as many of us as possible to > get together for 2-4 days and hold a P-athon coding session. We should > do it somewhere where we are away from our daily lives, so we could > just Zen Code in some hotel in some back corner of Germany for a while. > Anyone else up for that? I appreciate that idea. But i'm currently involved in two other commercial projects (KDE based pos-application for restaurants and a Half-Life 2 modification for Samsung that will be shown at CeBit). I've to finish these first. Commercial always means money ;-) Greetings, Christian |
|
From: Christian P. <cp...@se...> - 2005-01-20 09:22:11
|
Am Mittwoch 19 Januar 2005 22:52 schrieb gj...@fh...: > done, i've added it directly to the press page, since it was empty anyways, > if you like it as a seperate page, let me know > i also changed the text a bit "any application" wasn't that much, now it's > "all applications" ;), maybe stephan wants to cross check the text too please, could you rename the menu item "press coverage" to something more general ? Greetings, Christian |
|
From: Marc D. <bdu...@gm...> - 2005-01-20 03:39:23
|
I just had the idea that one could unify P::Util::Any and P::Util::Variant.
They do basically both the same, but Any uses typeid and casting, while
Variant (the class formerly known as LexT) uses stream based conversion.
This would simply require to add a convertTo member function to Any that
allows stream based conversion additionally to the any_casts:
template <typename ValueType>
ValueType convertTo(const ValueType& defVal = ValueType()) const {
Any::holder<ValueType>* valHolder = 0;
valHolder = dynamic_cast< Any::holder<ValueType>* >(m_data);
if(valHolder) {
return valHolder->value();
}
ValueType retVal(defVal);
std::stringstream ss;
m_data->output(ss);
ss >> retVal;
return retVal;
}
The dynamic_cast is a short cut.
In code you would do this:
Any myAny(5);
string s = myAny.convertTo<std::string>();
or we add a type conversion member to Any that does this automatically:
template <typename T>
operator T() const throw() {
return this->template convertTo<T>();
}
Does anybody see a problem with this?
Marc
|
|
From: Marc D. <bdu...@gm...> - 2005-01-20 03:20:43
|
> @the Germans: any plans for meeting in Ravensburg this weekend or > uebernaechstes? i would really like for as many of us as possible to > get together for 2-4 days and hold a P-athon coding session. We should > do it somewhere where we are away from our daily lives, so we could > just Zen Code in some hotel in some back corner of Germany for a while. > Anyone else up for that? I most likely cant make it this weekend but "=FCbern=E4chstes" would be ok. Marc |
|
From: Marc D. <bdu...@gm...> - 2005-01-20 03:17:53
|
Welcome Daniel! Looking forward to work with you! Marc On Wednesday 19 Jan 2005 15:10, Christian Prochnow wrote: > Hi List ! > > I would like to welcome a new member in our team: Daniel Loof. > > He works full-time for my old employer "Berliner Freiverkehr AG" as a C++ > coder. > > He knows P::Classes 1.0 very well, cause most software in the Berliner > Freiverkehr depends on it. > > So he decided to join our team and assist us with our > world-leading-portable-application-framework effort ;-) > > Maybe daniel posts some introduction about himself to the list. > > > Greetings and welcome Daniel ! > > Christian > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > pclasses-devel mailing list > pcl...@li... > https://lists.sourceforge.net/lists/listinfo/pclasses-devel |
|
From: stephan b. <st...@s1...> - 2005-01-20 01:49:17
|
On Wednesday 19 January 2005 17:34, Christian Prochnow wrote: > I would like to welcome a new member in our team: Daniel Loof. Welcome aboard, Daniel! > He works full-time for my old employer "Berliner Freiverkehr AG" as a > C++ coder. Another verdammter German! ;) It is a wonder of technology that we all live in the same time zone and work together via SourceForge, which is based in California. In the lib manual i have us listed by country, but i guess PLZ would probably be better ;). > So he decided to join our team and assist us with our > world-leading-portable-application-framework effort ;-) Let's say "2nd-leading", behind Qt for the moment ;). We've still got lots of work ahead of us, but the basis is certainly there. The more i see of P the more convinced i am that it will be able to serve as the ultimate application framework someday. :) i already like it more than Qt (and i admit i've been a big Qt fan for a long time). My main problem with Qt is the "all or nothing" architecture - you can't take the signals/slots without taking QObject and moc, for example. moc's a very solid tool, but it adds another layer of build complexity. i'll shut up now... @the Germans: any plans for meeting in Ravensburg this weekend or uebernaechstes? i would really like for as many of us as possible to get together for 2-4 days and hold a P-athon coding session. We should do it somewhere where we are away from our daily lives, so we could just Zen Code in some hotel in some back corner of Germany for a while. Anyone else up for that? -- ----- 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...> - 2005-01-20 01:40:04
|
On Wednesday 19 January 2005 16:17, Christian Prochnow wrote: > i got the confirmation from my old employer to list them as a > P::Classes reference customer !! Congratulations! :) > @All, could anybody write some description about himself to put it on > the webpage? i added a section to the lib manual doc for that, but i have NO CLUE what to write for everyone: if you have Lyx, please check out doc/manual/pclasses2.lyx and add an entry for yourself bzw edit the one i wrote! (Section 1.5.) To answer your question, though: my description is in the lib manual. ... copy/paste ... "stephan beal (Germany): likes to write docs and break old code/conventions. Writes the P::s11n support." > Any thoughts ? Lots, but i'm way too tired ;). Congratulations again! That type of thing will always look great on your CV. :) -- ----- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
