#pentagram@irc.freenode.net logs for 2 Sep 2009 (GMT)

Archive Today Yesterday Tomorrow
Pentagram homepage

[00:04:46] --> Kirben has joined #pentagram
[00:04:46] --- ChanServ gives channel operator status to Kirben
[02:27:35] --> ShadwChsr has joined #pentagram
[02:27:51] <ShadwChsr> Any devs here right now?
[02:36:09] <Colourless> yes, you are ;-)
[02:36:16] <ShadwChsr> :P
[02:36:57] <ShadwChsr> I generally don't compile with GCC, so I have a question about it's standard library
[02:37:36] <ShadwChsr> I have a few warnings about ISO C++ conformance - a few of the file-level operations have been "replaced" with ISO versions in the standard. At least, according to MS ;)
[02:37:53] <Colourless> posix vs ANSI C
[02:38:14] <ShadwChsr> I want to make sure that fixing these isn't going to toast the other builds because it's some weirdo Microsoft nonsense ;)
[02:38:22] <Colourless> it will
[02:39:48] <ShadwChsr> Is it because, say, _unlink is a new defined function in the standard, or because Microsoft are going insane about naming conventions of "non-standard" posix-related functions?
[02:40:11] <ShadwChsr> (in other words, custom extensions need to be prefixed with _ or whatnot)
[02:41:08] <Colourless> unlink is a posix function, its defined be including unistd.h
[02:41:15] <Colourless> which is not standard C
[02:41:58] <ShadwChsr> Makes sense. They're generally replaced with the std:* file functions. So it's all in the naming.
[02:42:24] <ShadwChsr> So the proper correction is probably to switch to std: if a suitable replacement is available, otherwise just suppress the nonsense warnings ;) or both ;)
[02:42:52] <Colourless> last thing i knew, you could tell the compiler to ignore usages of the non standard functions
[02:42:57] <Colourless> some macro
[02:43:25] <Colourless> of course that some of the functions like mkdir have different arguments is a pita
[02:43:42] <ShadwChsr> Yeah
[02:44:30] <ShadwChsr> Windows is a bit weird:
[02:45:15] <ShadwChsr> NT natively supports POSIX, VC++'s library includes the POSIX functions, *and* the kernel was compiled with a varient of the POSIX functions, so they're hidden in there too ;)
[02:45:19] <Colourless> #define _CRT_NONSTDC_DEPRECATE
[02:45:23] <Colourless> should get rid of the warnings
[02:47:00] <Colourless> there are more defines in crtdefs.h to control other crt warnings
[02:47:39] * ShadwChsr nods
[02:49:55] <Colourless> uh i meant
[02:49:55] <Colourless> _CRT_NONSTDC_NO_DEPRECATE
[02:50:06] * ShadwChsr nods
[02:50:12] <ShadwChsr> Digging a bit through the STL too
[02:50:21] <Colourless> or _CRT_NONSTDC_NO_WARNINGS
[02:55:34] <ShadwChsr> I think I might change FileSystem.cpp(477)
[02:56:19] <ShadwChsr> Windows natively supports (and uses) Unicode paths - Pentagram only uses single-byte, so there could be an issue there on foreign language systems.
[02:56:58] <ShadwChsr> Regardless of that fact, if defined(UNICODE) is true, then under Windows the ANSI version is guarunteed to be there - you can just call CreateDirectoryA directly and Windows does the rest.
[02:57:10] <ShadwChsr> (rather than the freakish TCHAR CreateDirectory)
[02:57:35] <ShadwChsr> I'm not entirely sure, but I also think the return valeus for CreateDirectory are not the same as mkdir
[02:58:20] <ShadwChsr> But I don't think Pentagram checks the return value anywhere. How would you feel about making the return value a bool instead?
[02:59:56] <Colourless> wouldn't be a problem to do that imo, don't think anyone would object
[03:00:24] <Colourless> it would be nice if pentagram's support of filesystem stuff in windows was unicode
[03:01:08] <ShadwChsr> std::string is current codepage, not UTF-8, right?
[03:01:12] <Colourless> yes
[03:01:56] <Colourless> the big problem is the ini files
[03:02:16] <ShadwChsr> Yeah
[03:02:32] <Colourless> can't be sure what codepage they are in windows
[03:03:10] <ShadwChsr> Usually you just read as CCP and use the BOM to detect unicode.. but I think the BOM is hated in *ix land ;)
[03:03:44] <Colourless> yeah
[03:04:25] <ShadwChsr> In GCC, is the second parameter of mkdir required? (0750)
[03:04:34] <Colourless> yes
[03:04:44] <Colourless> i int mkdir(const char *pathname, mode_t mode);
[03:04:51] <ShadwChsr> Ahhhh. In Windows all the security-related stuff can be defaulted/inherited
[03:06:16] <Colourless> was considering at one point of making the assumption that all strings in pentagram be treated as if they were UTf8
[03:06:55] <Colourless> could then make attempt to make reasonable assumption on what the code page of the ini file is based on things like BOM and current codepage
[03:07:02] <ShadwChsr> That's not a terrible idea. If *ix editing tools can ignore the BOM, then Notepad will automatically use it and continue saving as UTF-8 if someone edits it.
[03:07:26] <ShadwChsr> ie/ foreign user
[03:07:54] <Colourless> would try to conserve the codepage of the ini if possible, otherwise convert to UTF8 and proably only emit BOM on windows platforms
[03:08:27] * ShadwChsr nods
[03:08:35] <ShadwChsr> Btw, data2c.c calls "unlink(..)"
[03:08:43] <ShadwChsr> Is it reasonable to change that to std::remove(filename) ?
[03:09:05] <Colourless> at this point of time i'd completely ignore Win9x lack of unicode support and just link to the W versions of windows apis
[03:09:22] <Colourless> std::remove should be fine
[03:09:33] <ShadwChsr> I'd be game for that - not many people use 95 or 98 anyhow. I think Kirben had some concerns about that with U7, however.
[03:09:36] <ShadwChsr> (err Exult)
[03:11:13] <ShadwChsr> Most modern apps just require a minimum of XP anyways - or if the user is lucky, 2000.
[03:11:56] <Colourless> i know lets compile with /CLR and use .net framework....
[03:12:03] <ShadwChsr> Did I ever tell you I tried that? ;)
[03:12:10] <Kirben> No, please don't break Windows 95 support, without good reason.
[03:12:15] <ShadwChsr> I actually had Pentagram running in the CLR :D
[03:12:42] <ShadwChsr> I can understand the good reason part, but why? It's gone the way of 3.1 - loved but passed away ;)
[03:13:42] <Kirben> Commercial software usually limits Windows versions officially supported, due to cost reasons (for support).
[03:14:09] <ShadwChsr> Makes it easier for standardized testing too
[03:14:42] <Kirben> You would be surprised how much older Windows versions are used in some places, due to lower cost.
[03:15:33] <ShadwChsr> It should be fairly easy to write a quick std::wstring->ansi conversion routine in the file system classes anyhow. :)
[03:15:50] <ShadwChsr> (that is, without requiring the horrible ATL conversion routines)
[03:16:19] <Kirben> And there are always some users that are simply happy with what they have, and don't see reasons to upgrade.
[03:17:21] <ShadwChsr> True, but don't forget that it could accumulate as a tax on the project as well. I'm not one to determine the threshold, but it's not reasonable to support all platforms either.
[03:17:59] <ShadwChsr> That said, your points do make sense - especially for projects like Exult/Pentagram that are distributed worldwide.
[03:18:46] <Colourless> we could use function pointers for the code with if(win9x)
[03:18:53] <Kirben> It usually isn't too difficult to supported as far back as Windows 95, even SDL still offers that far back.
[03:19:54] <Colourless> there is only going to be a few api call that would be wanted that 9x doesn't support
[03:20:48] * ShadwChsr nods
[03:21:05] <ShadwChsr> In other news, Win32 builds are now down to two warnings
[03:21:18] <ShadwChsr> warning C4003: not enough actual parameters for macro 'yywrap'
[03:21:22] <ShadwChsr> That's it
[03:22:04] <ShadwChsr> Is the lexer generated code?
[03:22:50] <ShadwChsr> (ie/ flex?)
[03:23:26] <ShadwChsr> http://log.usecode.org/pentagramlog.php?log=11Apr2004 LOL
[03:25:51] <Colourless> yeah it is
[03:26:04] <ShadwChsr> Argh.
[03:26:31] <Colourless> different versions of bison would probably generate different code
[03:26:52] <ShadwChsr> Is it safe to hack that one file?
[03:27:07] <ShadwChsr> #define yywrap(n) 1
[03:27:09] <Colourless> can't see why not, just remove the argument from the macro
[03:27:10] <ShadwChsr> to #define yywrap() 1
[03:27:27] <ShadwChsr> I suppose if it ever gets regenerated we're right back where we started though - probably doesn't happen often?
[03:28:43] <Colourless> when was the last time someone worked on the compiler...
[03:28:49] * Colourless looks are Darke
[03:28:52] <Colourless> *at
[03:29:23] <ShadwChsr> I assume the compiler was probably part of a project to either test various usecode functions or produce a game editor?
[03:29:58] <Colourless> produce a game editor thinngy
[03:30:04] * ShadwChsr nods
[03:31:36] <ShadwChsr> One experiment I might try in the future is to muck with clearly splitting the world state from the "command processor", and the "command processor" from the usecode interpreter
[03:32:03] <ShadwChsr> In other words, you would swap in a different interpreter that generates the same game instructions (lua or whatever).
[03:33:11] <ShadwChsr> It deviates a bit from the pure U8 design but you gain quite a bit - plug & play language that's widely used & known. *shrug* might not be too practical though.
[03:36:09] <ShadwChsr> I was also thinking abit about ucmachine.cpp's case statement - given it's length, I wonder if it could be refactored into a lookup with function pointers instead
[03:39:37] <Colourless> you could but it probably isn't worth it
[03:40:19] <Colourless> unless you like making work for yourself
[03:40:20] <ShadwChsr> Yeah.. but I vaugly remember seeing some other logic that had different bytecode values for crusader
[03:41:45] <ShadwChsr> Probably just loosing it :)
[03:54:06] <ShadwChsr> Zero L3 warnings for Win32, and I even went and removed all but one of the #pragma warning:disable definitions
[04:01:00] <ShadwChsr> Curious...
[04:01:01] <ShadwChsr> #define FORGET_OBJECT(x) do { delete x; x = 0; } while(0)
[04:01:05] <ShadwChsr> Why the do {} while(0) ?
[04:02:13] <ShadwChsr> 3388 Level 4 warnings :D
[04:03:11] <wjp> morning
[04:03:18] <ShadwChsr> Morning
[04:03:41] <wjp> the 'do { ... } while(0)' is so you can use the macro in situations like 'if (blah) FORGET_OBJECT(x);'
[04:04:14] <ShadwChsr> Why not just #define FORGET_OBJECT(x) { delete x; x = 0; } ?
[04:05:40] <wjp> then 'if (blah) FORGET_OBJECT(x); else blah' would fail because of the empty statement caused by the semicolon
[04:08:37] <Colourless> forget object 'could' be made a templated inline function template<typename T> inline void FORGET_OBJECT(T &x) { delete x; x = 0; }
[04:09:56] * wjp nods
[04:11:22] <wjp> heh, nice workaround suggested by someone on the boost mailing list: 'do { ...} while(__LINE__ == -1)' :-)
[04:11:33] <ShadwChsr> hehe
[04:11:36] <wjp> (assuming you're mentioning it because of C4127 warnings)
[04:11:49] <ShadwChsr> Just randomly snooping through the list ;)
[04:12:04] <ShadwChsr> It might be worth tossing an assert in there though
[04:12:09] <ShadwChsr> Since it has the potential to hide bugs
[04:12:16] <wjp> assert?
[04:12:47] <wjp> which one?
[04:13:53] <ShadwChsr> depends on the platform, but something like: { _ASSERT(x); delete x; x = 0; }
[04:14:14] <wjp> no, that'll break stuff
[04:14:30] <wjp> delete 0; is a no-op we probably depend on quite a bit
[04:14:47] <ShadwChsr> Ahhhh
[04:18:09] <ShadwChsr> Gonna be AFK for a bit
[04:21:48] * wjp too (shower + breakfast :-) )
[04:35:27] <wjp> so I guess the trick to seeing everyone here at the same time is getting up at 6am... not sure if I should be happy about that or not ;-)
[04:36:49] <wjp> Kirben: hi :-)
[04:51:49] <wjp> time to go to work; bye
[04:51:55] <ShadwChsr> cya
[04:54:16] <wjp> I'll try the VS2008 build files if I have time when I get back home tonight
[04:54:48] <ShadwChsr> Thanks, let me know how it goes
[04:58:59] <ShadwChsr> Still here Kirben?
[04:59:04] <Kirben> Yes
[04:59:17] <ShadwChsr> I'm adding the .rc to the MSVC solution
[04:59:42] <ShadwChsr> If MSVC were to regenerate it, is that going to toast mingw?
[05:00:23] <ShadwChsr> The key differences seem to be the (oh so much fun) resource.h and the lack of explicit includes for winres.h and winresrc.h
[05:04:25] <Kirben> Yes, I doubt mingw has as thorough support.
[05:05:30] <ShadwChsr> There's no option for text-only resources in VC, unfortunately
[05:05:40] <ShadwChsr> and it's probably the buggiest code in the whole platform :(
[05:18:24] <ShadwChsr> Found away around it, checked in
[05:56:31] <-- ShadwChsr has left IRC ()
[09:26:26] * Colourless attempts to compile pentagram using the vs 2008 project files on vs 2005 with the version numbers changed
[09:27:23] <Colourless> it worked
[09:53:03] <Colourless> well mostly
[09:53:41] <Colourless> debug builds worked, but the release build gets errors /02 and /RTC1 command line options being incompatible
[09:55:20] * Colourless sets runtime checks to default
[09:58:30] <Colourless> hmm missing linking to winmm.lib
[10:06:16] --> Colourless` has joined #Pentagram
[10:07:30] <-- Colourless has left IRC (Nick collision from services.)
[10:07:30] --- Colourless` is now known as Colourless
[10:07:31] --- ChanServ gives channel operator status to Colourless
[14:07:09] <-- Kirben has left IRC (Read error: 110 (Connection timed out))
[15:48:28] <-- Darke has left IRC (Read error: 104 (Connection reset by peer))
[16:03:40] --> Darke has joined #pentagram
[23:10:18] --> Kirben has joined #pentagram
[23:10:19] --- ChanServ gives channel operator status to Kirben