#pentagram@irc.freenode.net logs for 4 Nov 2002 (GMT)

Archive Today Yesterday Tomorrow
Pentagram homepage


[00:07:10] --> Kirben has joined #pentagram
[00:07:10] --- ChanServ gives channel operator status to Kirben
[00:58:42] <-- wjp has left IRC ("Zzzz...")
[01:42:44] <-- Kirben has left IRC (adams.freenode.net irc.freenode.net)
[01:42:44] <-- Dominus has left IRC (adams.freenode.net irc.freenode.net)
[01:42:44] <-- Darke|zzZ has left IRC (adams.freenode.net irc.freenode.net)
[01:45:09] --> Kirben has joined #pentagram
[01:45:38] --> Darke|zzZ has joined #pentagram
[01:45:38] --> Dominus has joined #pentagram
[01:45:38] --- ChanServ removes channel operator status from Darke|zzZ
[01:58:45] <-- Dominus has left IRC ("enough for now")
[02:43:03] <-- Kirben has left IRC (adams.freenode.net irc.freenode.net)
[02:43:03] <-- Darke|zzZ has left IRC (adams.freenode.net irc.freenode.net)
[02:45:09] --> Kirben has joined #pentagram
[02:45:53] --> Darke|zzZ has joined #pentagram
[02:53:14] <-- Darke|zzZ has left IRC (adams.freenode.net irc.freenode.net)
[02:53:14] <-- Kirben has left IRC (adams.freenode.net irc.freenode.net)
[02:53:35] --> Kirben has joined #pentagram
[02:53:35] --> Darke|zzZ has joined #pentagram
[03:12:00] --- Darke|zzZ is now known as Darke
[03:12:34] --- ChanServ gives channel operator status to Darke
[03:16:06] <-- Darke has left IRC (adams.freenode.net irc.freenode.net)
[03:16:36] --> Darke has joined #pentagram
[05:20:13] --- Darke is now known as Darke|afk
[05:58:12] --- Darke|afk is now known as Darke
[06:43:48] --> Colourless has joined #Pentagram
[06:43:48] --- ChanServ gives channel operator status to Colourless
[07:09:24] --> Cless has joined #Pentagram
[07:17:55] <-- Colourless has left IRC (Read error: 60 (Operation timed out))
[07:18:16] --- Cless is now known as Colourless
[07:18:16] --- ChanServ gives channel operator status to Colourless
[07:18:25] <-- Colourless has left IRC ("casts invisibility")
[09:36:49] --> Kirben2 has joined #pentagram
[09:36:50] <-- Kirben has left IRC (Read error: 54 (Connection reset by peer))
[10:23:34] --- Kirben2 is now known as Kirben
[10:41:32] --> Colourless has joined #Pentagram
[10:41:32] --- ChanServ gives channel operator status to Colourless
[10:43:32] <Darke> Another obvious 'usefulness' with console_stream, would be that you could do a 'pout.printf' type thing with it also. (Similar to the original gcc extension to iostream. *grin*)
[10:43:44] <Darke> s/that/if/
[10:44:25] <Colourless> sounds simple enought to me
[10:44:27] <Colourless> enough
[10:44:45] <Colourless> but, do you want to be able to do something really hacky as in
[10:45:20] <Colourless> pout << "A hex number " << printf("%04X", the_number) << std::endl;
[10:45:56] <Colourless> in theory that 'is' possible, but i don't think want to support it :-)
[10:46:28] <Darke> Whilst that would logically support both generality and flexability, that is probably the most ugly stream code I've seen in my life. *grin* Let's not.
[10:47:08] <Colourless> good, makes my life easy :-)
[10:48:10] <Darke> Honestly, all I would want would be for 'pout.printf' to effectively call 'con.Printf', and 'perr.printf' to call 'con.Printf_err'. *grin* That's all that's really necessary AFAICT.
[10:48:25] <Colourless> yeah i understand :-)
[10:48:28] <Colourless> it's what i would do :-)
[10:49:03] * Darke will let other people suggest complex and non-trivial things to implement. He's suggested enough of them as it is already. *innocentlook*
[10:49:21] <Colourless> :-)
[10:50:12] <Colourless> with the console redirection, i take it you would just want a function like console.RedirectStdio(ODataSource *);
[10:50:32] <Colourless> if the pointer is Null, then redirection would be disabled
[10:51:22] <Colourless> additionally, should the redirection cancel all output to stdio and stderr, or should it just also additionally output to the files too?
[10:51:58] <Colourless> i'm guessing that we could just have another set of method to not outout to stdio and stderr
[10:53:07] <Darke> *ponder* Yes, something like RedirectStdio would be perfect. I think it should disable output to stdio/stderr, depending upon which you redirected, either 'pout' or 'perr', if it's possible. *grin*
[10:54:23] * Darke suggests a 'flag' to turn off output to stderr/stdout/both. *grin*
[10:55:13] <Colourless> hmm, flag could be annoying in somecases, if you only want to change one, and leave the other in it's current state
[10:57:39] <Darke> Maybe pout.setOutput(STDOUT) with pout.unsetOutput(STDOUT) ?
[10:58:29] <Colourless> sounds ok to me
[10:59:02] <Colourless> except STDOUT isn't exactly a wise name to use as a macro :-)
[10:59:05] <Colourless> for obvious reasons
[11:00:41] <Darke> Sure, it was just an example name. *grin* The stdlib iostream stuff does something similar with setf/unsetf, so it would be nice to 'parallel' it. *grin*
[11:34:05] <Colourless> should doing RedirectStdio(0); call delete on the previous redirection if it exists?
[11:36:05] <Colourless> i think it should
[11:36:21] <Darke> IMO, no. Not for as a general class as this, since we can't guarantee it's completely unused. OTOP, if we added reference counting (I'm certainly not volunteering! *grin*) to the ?DataSource classes, it'd be ok.
[11:36:57] <Darke> OTGP however... *ponder
[11:36:57] <Colourless> yes, after thought it probably isn't a good idea
[11:37:05] <Colourless> there are just 2 cases
[11:37:49] <Colourless> either the ODataSource class is always deleted by the Console class, or it never is
[11:38:05] <Colourless> also i'm thinking it should be RedirectOutput(STDOUT, ODataSource)
[11:38:52] <Colourless> ref counting as something that i was planning on, but it was only going to used for cached Input, not output
[11:39:15] <Colourless> and even then, it's probably not going to actually be the IDataSource class though either
[11:39:19] <Darke> It really depends upon how we work things. If we do have a OTextDataSource, and we specify that the RedirectOutput must have a OTextDataSource for both IO. I don't see a problem saying "sacrifice a newed file to this and we'll delete it", whereas if we just allowed any data source, then we'd have problems.
[11:40:11] <Darke> s/newed file/newed TextDataSource/
[11:43:29] <Colourless> the only clean way of doing it at the moment is for the Console class to delete it
[11:44:21] <Colourless> you can't have the calling function/whatever doing the clean up of the DataSource because you need to notify the console that the DataSource is no longer usable
[11:44:47] <Colourless> and it's possible that the DataSource being used by the console has changed
[11:45:30] <Darke> You can have the calling function clean it up, if it 'RecirectOutput(STDOUT, 0)'. Eh? How? Other then dumping data to it, that is. *grin*
[11:45:46] <Darke> s/\./ first./
[11:46:18] <Colourless> the other issue is the console might be deleted before calling function/whatever has a chance to free the memory of the file, and to notifty the console the file is no longer valid
[11:47:09] <Colourless> you also get an additional problem of what to do when you specify the same file for both stderr and stdout
[11:47:21] <Colourless> s/file/ODataSource/
[11:47:38] <Colourless> of course for that last problem you could just get the console to compare pointers
[11:48:08] * Darke nods.
[11:48:50] <Colourless> the final solution is to instead of passing a ODataSource * to the RedirectOuput function, you give it a filename :-)
[11:49:21] <Darke> Admittedly, I'm still not sure what the problem is with letting the user handle new/deleteing the DataSource. AFAICT, it would work just the same with the C++ stream's .rdbuf() function.
[11:49:41] * Darke icks. He'd rather not. That's the domain of the FileSystem, not the Console. *grin*
[11:50:12] <Darke> For example, I'd write something like:
[11:50:28] <Darke> OTextDataSource *o = new OTextDataSource("filename.txt");
[11:50:38] <Darke> con.RedirectOutputStream(STDOUT, o);
[11:50:45] <Darke> DoLotsOfStuffHere();
[11:50:52] * Colourless icks, you should be going through the filesystem :-)
[11:50:58] <Darke> con.RedirectOutputStream(STDOUT, 0);
[11:51:03] <Darke> delete o;
[11:51:08] <Colourless> yeah, that should be ok
[11:51:15] * Darke knows. *grin*
[11:51:39] <Darke> That's the same way you handle the cout.rdbuf() type stuff too.
[11:52:59] <Colourless> easy enough to do
[11:53:40] <Darke> Simple Is Good(tm). *grin*
[11:53:48] <Colourless> yes :-)
[11:54:05] <Colourless> people will just have to know not to attempt anything overly fancy :-)
[11:56:53] <Darke> Nah. This method allows people do to overly fancy stuff, provided they're careful. *grin*
[11:57:29] <Colourless> should there be a getRedirectionOutputStream() method?
[11:58:32] <Darke> I'd say 'no' for the moment. I can't really think of a concrete use for it, and we can always add it if we need it. *grin*
[11:58:42] <Colourless> ok
[12:20:29] <Colourless> well, that should be about it
[12:24:54] <Colourless> committed
[12:25:36] * Darke would 'yay', except he knows he's likely to have collisions coming out his ears. *grin*
[12:26:03] <Colourless> well, really unless you've been screwing round with Console.h/cpp then it's not likelyt
[12:26:22] * Darke crosses his claws.
[12:28:01] <Colourless> hmmm:
[12:28:04] <Colourless> cvs server: Updating .
[12:28:04] <Colourless> cvs server: [04:27:25] waiting for fingolfin's lock in /cvsroot/exult/exult
[12:28:34] <Colourless> i guess that should be posted in #exult
[12:29:26] <Darke> Yep. *grin*
[12:43:07] <Kirben> hmm last commit seems to have broken something:
[12:43:28] <Kirben> In file included from misc/Console.cpp:23:
[12:43:29] <Kirben> filesys/ODataSource.h: In destructor `virtual
[12:43:29] <Kirben> OFileDataSource::~OFileDataSource()':
[12:43:29] <Kirben> filesys/ODataSource.h:69: invalid use of undefined type `struct
[12:43:29] <Kirben> std::basic_ofstream<char, std::char_traits<char> >'
[12:43:29] <Kirben> c:/mingw/include/c++/3.2/iosfwd:89: declaration of `struct
[12:43:31] <Kirben> std::basic_ofstream<char, std::char_traits<char> >'
[12:43:33] <Kirben> filesys/ODataSource.h: In member function `bool OFileDataSource::good() const':
[12:43:35] <Kirben> filesys/ODataSource.h:72: invalid use of undefined type `struct
[12:43:37] <Kirben> std::basic_ofstream<char, std::char_traits<char> >'
[12:43:39] <Kirben> c:/mingw/include/c++/3.2/iosfwd:89: declaration of `struct
[12:43:40] <Kirben> std::basic_ofstream<char, std::char_traits<char> >'
[12:43:43] <Kirben> filesys/ODataSource.h: In member function `virtual void
[12:43:45] <Kirben> OFileDataSource::write1(unsigned int)':
[12:43:47] <Kirben> filesys/ODataSource.h:76: invalid use of undefined type `struct
[12:43:48] <Kirben> std::basic_ofstream<char, std::char_traits<char> >'
[12:43:50] <Kirben> c:/mingw/include/c++/3.2/iosfwd:89: declaration of `struct
[12:43:53] <Kirben> std::basic_ofstream<char, std::char_traits<char> >'
[12:43:55] <Kirben> filesys/ODataSource.h: In member function `virtual void
[12:43:56] <Kirben> OFileDataSource::write2(short unsigned int)':
[12:43:59] <Kirben> etc..
[12:45:23] <Colourless> add #include <ostream> to the top of Console.cpp
[12:45:40] * Darke is currently pondering how you could 'invalidly' use an 'undefined' type. If you don't know what it is, how can you say you're using it wrong? *grin*
[12:46:00] <Colourless> :-)
[12:46:12] <Colourless> well you can use pointers to undefined types :-P
[12:46:19] <Colourless> struct AType;
[12:46:27] <Colourless> is an undefined type that can be used :-)
[12:46:56] <Kirben> doesn't make any difference
[12:47:21] <Colourless> ah
[12:47:34] <Colourless> change that to #include <fstream>
[12:47:46] <Darke> But that would be a 'invalid use of a pointer to an undefined type', wouldn't it? *grin*
[12:48:39] <Colourless> you can only use a pointer undefined type, and then you can only assign with it. Any other operation is an invalid use of an undefined type
[12:48:43] <Kirben> Still doesn't make any difference
[12:49:47] <Colourless> Darke: do you have any problems compiling?
[12:50:19] * Darke had the identical errors, including the `#include <fstream>` got rid of the problem.
[12:50:31] <Colourless> well, commit it
[12:50:35] <Colourless> :-)
[12:50:50] * Darke looks at tree... umm... how about 'no'. *grin*
[12:51:05] <Colourless> well, dcc the changed file to kirben, or me or something
[12:51:33] <Darke> All you need is to add the #include. That's all. It works. *grin* Actually I've got a clean tree. I'll replicate it now and then commit.
[12:52:07] <Colourless> Darke: yes i know that should just be it, maybe kirben has made a mistake or something :-)
[12:58:26] <Kirben> oops changed wrong file, let me try again..
[12:58:37] <Darke> Done.
[12:59:15] * Darke fixed another change that probably would have also caused problems for Kirben too whilst he's at it. *grin*
[13:00:16] <Kirben> works when I change the right file
[13:00:25] <Darke> Cool.
[13:12:03] <Colourless> Darke: fingolfin has a question for you :-)
[13:12:22] <Darke> Eh? Where? *blink*
[13:12:31] <Colourless> email
[13:12:52] <Colourless> sent to To: darkepaw@users.sourceforge.net, pentagram-cvs@lists.sourceforge.net
[13:12:52] <Colourless> From: Max Horn <max@quendi.de>
[13:12:52] <Colourless> Subject: Re: [Pentagram-cvs] pentagram/misc Console.h,1.6,1.7
[13:13:14] <Colourless> What is that ?!? I don't understand, what kind of compile error is fixed by duplicating a typedef?
[13:13:15] <Colourless> Cheers,
[13:13:15] <Colourless> Max
[13:14:41] * Darke ehs and checks. *blink* That wasn't what he changed. *ponder* Did he stuff up the logic when he was untangling a merge?
[13:15:04] <Colourless> :-)
[13:15:49] <Colourless> i think *you* should remove it :-)
[13:15:59] <Colourless> Compiling...
[13:16:01] <Colourless> Args.cpp
[13:16:01] <Colourless> C:\UC\pentagram\misc\Console.h(183) : error C2086: 'int_type' : redefinition
[13:16:01] <Colourless> C:\UC\pentagram\misc\Console.h(199) : see reference to class template instantiation 'console_streambuf<_E,_Tr>' being compiled
[13:16:01] <Colourless> C:\UC\pentagram\misc\Console.h(240) : error C2086: 'int_type' : redefinition
[13:16:01] <Colourless> C:\UC\pentagram\misc\Console.h(256) : see reference to class template instantiation 'console_err_streambuf<_E,_Tr>' being compiled
[13:16:03] <Colourless> Console.cpp
[13:16:05] <Colourless> C:\UC\pentagram\misc\Console.h(183) : error C2086: 'int_type' : redefinition
[13:16:07] <Colourless> C:\UC\pentagram\misc\Console.h(199) : see ref
[13:19:42] <Darke> Committing now. Wonder why I didn't get a warning/error about that?
[13:19:59] <Colourless> probably because your compiler didn't care :-)
[13:22:03] <Darke> You'd think there'd be a warning about an overloaded name in the same scope though. *grin*
[15:14:21] --- Darke is now known as Darke|zzZ
[16:36:45] --> wjp has joined #pentagram
[16:36:45] --- ChanServ gives channel operator status to wjp
[16:38:28] --- Colourless is now known as NotColourless
[16:38:37] <-- wjp has left IRC (Read error: 54 (Connection reset by peer))
[16:39:49] --> wjp has joined #pentagram
[16:39:49] --- ChanServ gives channel operator status to wjp
[16:57:24] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[17:06:23] --- NotColourless is now known as Colourless
[17:07:10] <-- Colourless has left IRC ("casts invisibility")
[19:53:54] --> Dominus has joined #pentagram
[22:45:31] <-- Dominus has left IRC ("enough for now")