[00:01:13] <wjp> ok, done, and rebuilding :-)
[00:01:33] <Darke> Again. *grin*
[00:02:28] <wjp> 'yet again', actually :-)
[00:02:45] <wjp> ugh... missing files in the make dist
[00:03:11] <wjp> oh... wait... I'm doing this from a non-1.0 tree
[00:03:17] <wjp> non-RC2, I mean
[00:03:51] * Darke suggests this thing called 'sleep'. *grin* And for you to finish fiddling with this when you're awake.
[00:04:28] <wjp> might be a good idea, yes
[00:04:56] * Darke pushes wjp off to bed, and sleep and stuff. Night! *grin*
[00:05:15] * wjp checks out fresh copy of RC2 ;-)
[00:06:52] <wjp> ugh.. I really hate automake... it's just _so_ broken
[00:07:23] * Darke keeps trying to push wjp out the door. Go! *grin*
[00:07:37] <Darke> Umm... yeah. *grin*
[00:07:38] * wjp points out that there's no door in here :-)
[00:07:58] * Darke tries to push wjp out the window then. He's never defrenstrated someone before. *grin*
[00:08:55] <Darke> s/defrenstrated/defenstrated/
[00:09:06] <wjp> hm, how much does head2data depend on libu7file?
[00:09:23] <wjp> it would make the 'make dist' a lot easier if it didn't :-)
[00:09:38] <Darke> Umm... fopen? I think.
[00:09:43] <Darke> s/fopen/u7open/
[00:09:51] * Darke bleahs. His mind is going...
[00:10:50] * wjp throws a few carefully-picked curses at automake
[00:12:01] <Darke> Yeah. It looks like just U7open. Replace them with `o.open(fname.c_str())` and everything should just work. There's two instances of the call.
[00:13:24] * Darke wonders why on earth he used it in the first place. Oh well.
[00:14:05] <wjp> generally not a good idea to have tools used in the build process depend on too much code
[00:14:14] <wjp> really screws up crosscompiling, for one
[00:15:47] * wjp blinks
[00:15:52] <wjp> why does scale.h include scale.cc?
[00:16:07] <wjp> and why isn't scale.cc in the dist?
[00:16:22] <Darke> Umm... good question.
[00:16:55] <Darke> Ahh! Template stuff. That's the reason.
[00:18:13] <wjp> ok... one terminating backslash too many
[00:18:29] <wjp> and there we go again :-)
[00:19:06] <wjp> is it me or are our releases getting sloppier and sloppier? :-)
[00:20:01] <Darke> It's not just you. *grin*
[00:20:52] * Darke suspects we need a day or two's planning before each release so we've got all the packages together, _before_ we announce things. *grin*
[00:21:12] <wjp> nah, before we build the source release
[00:28:01] <wjp> yay, rpms built successfully
[00:28:59] * Darke celebrates!
[00:29:15] <Darke> Of course, your nicely built copies of exult won't work now, just to spite you. *grin*
[00:29:25] <wjp> oh... wait...
[00:29:32] <wjp> didn't exult studio need some new data files?
[00:30:05] <Darke> IIRC, yes. Something about a set of datafiles for when people try to start a 'new' modification.
[00:30:23] <wjp> let me guess... nobody thought of adding these to Makefile.am and/or exult.spec? :-)
[00:30:57] <Darke> Probably not. But it's not going to worry you at the moment, because you're going to BED. Right? *grin*
[00:31:22] <wjp> BED? I think I've heard of that mythical place once
[00:31:31] <wjp> ah, alright.. you win :-)
[00:31:37] <wjp> I'll just commit this stuff
[00:34:12] * Darke grins.
[00:35:38] <wjp> now I need to duplicate these changes to the devel-1.00 branch
[00:40:14] <wjp> ok, time to find out if that pillow really is as comfortable as it looks ;-)
[00:40:19] <wjp> bye :-)
[00:40:35] <-- wjp has left IRC ("Zzzz...")
[01:29:46] --- Darke is now known as Darke|afk
[02:27:40] --> Kirben has joined #exult
[02:27:40] --- ChanServ gives channel operator status to Kirben
[02:48:43] --- Darke|afk is now known as Darke
[03:19:35] <-- Darke has left IRC (Read error: 104 (Connection reset by peer))
[03:43:32] --> Darke has joined #exult
[03:43:33] --- ChanServ gives channel operator status to Darke
[04:06:20] <-- Darke has left IRC (Remote closed the connection)
[04:07:38] --> Darke has joined #exult
[04:07:38] --- ChanServ gives channel operator status to Darke
[04:33:52] <Kirben> Any more ideas on what I should do to solve ucparse.cc problem ?
[04:36:06] <Kirben> I found more recent bision and flex ports at http://sourceforge.net/project/showfiles.php?group_id=23617 but no difference with them.
[04:36:48] <Kirben> Wish I had known about that web site earlier, stack of useful mingw ports on it.
[04:37:27] <Darke> Nothing much. The 'problem' is that we've got #defines and variable symbols clashing. We need to rename either all the tokens, or all the other ADD/whatever symbols to a unique prefex. Our last attempt at a 'unique' prefex failed miserably. *grin*
[04:37:59] <Darke> Oooh, nice!
[04:38:42] <Kirben> mingw is really progressing well lately too, finally moved all to msys shell.
[04:40:18] <Darke> Cool.
[04:44:51] <Kirben> hmm to get rid of those deprecated or antiquated header warnings should I just define HAVE_SSTREAM ?
[04:46:08] <Kirben> Since that is what the warning actually recommends:
[04:46:09] <Kirben> In file included from c:/mingw/include/g++-v3/backward/strstream:51,
[04:46:09] <Kirben> from conf/Configuration.cc:40:
[04:46:09] <Kirben> c:/mingw/include/g++-v3/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 18.104.22.168 of the C++ standard. Examples include substituting the <X> header for the <X.h> header for C++ includes, or <sstream> instead of the deprecated header <strstream.h>. To disable this warning use -Wno-deprecated.
[04:51:33] <Darke> *nod* That should solve them.
[04:52:21] <Darke> OTOP, The old strstreams were in there solely because a couple of the compilers didn't have them, and I don't think we need them anymore, so you may wish to comment them out/remove them and see what happens.
[04:56:18] <Kirben> ok, since main brnach can now be unstable I think I will commit gcc 3.1 changes and leave ucc.exe out of makefiles for now.
[04:57:09] <Kirben> ucc.exe option will still be there but not when tools/toolsinstall/toolsdist is used.
[05:11:00] * Darke nods. Makes sense.
[05:36:20] <Kirben> commited
[05:36:35] <Kirben> might be a good idea to recheck ucfunc
[05:36:49] <Kirben> .cc
[05:37:16] <Kirben> To be sure I replaced strstream with sstream correctly.
[05:38:59] <Kirben> oops forgot one important flag
[05:39:27] <Darke> Will do.
[05:41:07] <Darke> Looks correct to me.
[05:42:32] <Darke> Actually, there's a problem. Just a sec and I'll correct it.
[05:46:29] <Kirben> ok
[05:48:39] <Darke> We had to bend over backwards so that we weren't losing memory with each construction/destruction of a strstream in there, I just removed the 'fix'. *grin*
[05:49:30] <Darke> It was actually reported as a bug a few months later on the gcc-bugs mailing list. No idea if it's a bug or not, but it was amusing. *grin*
[05:50:33] <Kirben> Hoping no-one is still using that older gcc version.
[05:50:42] <Kirben> I noticed another warning:
[05:50:43] <Kirben> mapedit/locator.cc: In member function `void Locator::send_location()':
[05:50:43] <Kirben> mapedit/locator.cc:411: warning: passing negative value `-1' for argument 2 of
[05:50:43] <Kirben> `void Write4(uint8*&, unsigned int)'
[05:50:43] <Kirben> mapedit/locator.cc: In member function `void Locator::query_location()':
[05:50:43] <Kirben> mapedit/locator.cc:427: warning: passing negative value `-1' for argument 2 of
[05:50:44] <Kirben> `void Write4(uint8*&, unsigned int)'
[05:50:46] * Darke hopes so too. We'll find out soon enough.
[05:50:46] <Kirben> mapedit/locator.cc:428: warning: passing negative value `-1' for argument 2 of
[05:50:48] <Kirben> `void Write4(uint8*&, unsigned int)'
[05:50:50] <Kirben> mapedit/locator.cc:429: warning: passing negative value `-1' for argument 2 of
[05:50:52] <Kirben> `void Write4(uint8*&, unsigned int)'
[05:50:54] <Kirben> mapedit/locator.cc:430: warning: passing negative value `-1' for argument 2 of
[05:50:56] <Kirben> `void Write4(uint8*&, unsigned int)'
[05:50:58] <Kirben> mapedit/locator.cc:431: warning: passing negative value `-1' for argument 2 of
[05:51:00] <Kirben> `void Write4(uint8*&, unsigned int)'
[05:51:02] <Kirben> can that be ignored ?
[05:51:45] <Darke> Umm... maybe. -1 gets wrapped around to MAX_UINT. If it 'works' then it can probably be ignored. It's still not particularly good code though. *grin*
[05:52:57] <Darke> Actually, looking at the code for Write4, it's just writing a byte of 0xFFFFFFFF it can be ignored.
[05:53:14] <Darke> s/a byte/4 bytes/
[05:55:24] <Kirben> ok
[06:05:27] <Kirben> hmm no cvs emails again
[06:21:36] * Darke commits to pentagram's cvs. Let's see if it's a sf.net wide problem. *grin*
[06:23:04] <Kirben> hmm can you compile /usecode/ucinternal.cc ?
[06:23:59] * Darke checks.
[06:24:16] <Kirben> I get these errors at the moment:
[06:24:17] <Kirben> In file included from usecode/ucinternal.cc:55:
[06:24:17] <Kirben> usecode/ucinternal.h:386: `ostream' was not declared in this scope
[06:24:17] <Kirben> usecode/ucinternal.h:386: `out' was not declared in this scope
[06:24:17] <Kirben> usecode/ucinternal.h:386: invalid data member initialization
[06:24:17] <Kirben> usecode/ucinternal.h:386: (use `=' to initialize static data members)
[06:24:18] <Kirben> usecode/ucinternal.h:386: variable or field `stack_trace' declared void
[06:24:20] <Kirben> usecode/ucinternal.cc:125: `ostream' was not declared in this scope
[06:24:22] <Kirben> usecode/ucinternal.cc:125: `out' was not declared in this scope
[06:24:24] <Kirben> usecode/ucinternal.cc:126: `void Usecode_internal::stack_trace' is not a static
[06:24:26] <Kirben> member of `class Usecode_internal'
[06:24:28] <Kirben> usecode/ucinternal.cc:126: variable `void Usecode_internal::stack_trace' has
[06:24:30] <Kirben> initializer but incomplete type
[06:25:20] <Darke> Change the line 386 in ucinternal.h from 'ostream...' to 'std::ostream...'.
[06:27:02] <Darke> And at line 96 of ucinternal.cc add a line stating `using std::ostream;`.
[06:30:01] <Darke> No word from pentagram-cvs. Looks like the sf.net mail system is a little 'down' at the moment. *grin*
[06:30:11] <Kirben> thats works, should I commit it ?
[06:30:45] <Darke> Yep. It's broken like that for all gcc3.x compilers. *grin*
[06:34:37] <Kirben> now I get:
[06:34:38] <Kirben> usecode/stackframe.cc: In function `std::ostream& operator<<(std::ostream&,
[06:34:38] <Kirben> Stack_frame&)':
[06:34:38] <Kirben> usecode/stackframe.cc:88: `hex' undeclared (first use this function)
[06:34:38] <Kirben> usecode/stackframe.cc:88: (Each undeclared identifier is reported only once for
[06:34:39] <Kirben> each function it appears in.)
[06:34:41] <Kirben> usecode/stackframe.cc:88: `setw' undeclared (first use this function)
[06:34:43] <Kirben> usecode/stackframe.cc:88: `setfill' undeclared (first use this function)
[06:34:45] <Kirben> usecode/stackframe.cc:93: `dec' undeclared (first use this function)
[06:36:41] <-- Darke has left IRC ("Inficio-Infeci-Infectum")
[06:37:01] --> Darke has joined #exult
[06:37:01] --- ChanServ gives channel operator status to Darke
[06:37:19] * Darke sighs. Wrong window killed. *grin*
[06:38:08] <Darke> They're part of the same problem. Just add 'std::' before each definition (that is turn 'hex' to 'std::hex') and things should work.
[06:41:00] <Kirben> ok that ones fixed, now another:
[06:41:00] <Kirben> usecode/ucfunction.cc:34: parse error before `&' token
[06:41:01] <Kirben> usecode/ucfunction.cc:42: ISO C++ forbids declaration of `len' with no type
[06:41:01] <Kirben> usecode/ucfunction.cc:42: `file' was not declared in this scope
[06:41:01] <Kirben> usecode/ucfunction.cc:43: ISO C++ forbids declaration of `extended' with no
[06:41:01] <Kirben> type
[06:41:02] <Kirben> usecode/ucfunction.cc:44: parse error before `}' token
[06:41:48] <Darke> `#include <iostream>` up the top.
[06:42:09] <Darke> Then a `using std::istream;` just below it.
[06:43:52] <Darke> Just a FYI as to why I keep swapping between `std::` and `using std::`. It's just that you "shouldn't" use a `using std::` in a header file, since it'll effect all the files it's included in, whereas you can use it in a .cc file, since you know it'll only effect that file.
[06:46:26] <Kirben> ok, all compiled now.
[06:46:33] <Kirben> fixes commited.
[06:47:00] <Darke> Cool.
[06:48:26] <Kirben> Thanks for all your help!
[06:53:44] <Darke> No problem. *grin*
[07:39:51] --> sbx has joined #exult
[07:39:53] <sbx> lo
[07:40:00] <Kirben> Hi sbx
[07:40:17] <sbx> What version of GCC did you say won't compile Exult?
[07:40:45] <Darke> Hi.
[07:40:48] * sbx has a 2.xx ver.
[07:41:23] <Kirben> Darke might know the exact version.
[07:41:39] <Kirben> worth updating to gcc 3.1 though.
[07:41:41] <Kirben> bbl
[07:41:52] <sbx> ok
[07:42:00] <Darke> IIRC one of the mingw 2.95.x versions had problems, and Fingolfin had a problem with it one time in the past, no idea what version it was, or how long ago it was though. *grin* But if you've got a 'sstream' header floating around, you'll be ok.
[07:42:00] <sbx> im just using the one that came with slack8
[07:42:03] <Darke> Cya.
[07:42:49] <sbx> 'wtf is cya'
[07:42:55] <sbx> CYA: see you around
[07:43:04] <sbx> heh heh ?
[07:44:02] <sbx> 'gcc --version'
[07:44:06] <sbx> 2.95.3
[07:44:27] <Darke> The ChangeLog references Max on 2001-12-21 having a problem with one change I made to Configuration.cc which used sstreams, he actually added the HAVE_SSTREAM test to configure.in then.
[07:44:58] <sbx> 'ls -l /usr/include/g++-3/sstream'
[07:45:05] <sbx> -rw-r--r-- 1 root root 7419 Mar 18 2001 /usr/include/g++-3/sstream
[07:45:48] <sbx> i figured it was already tested
[07:45:58] <Darke> Incidentally, what's with the Gcc3 header dir on a 2.95.x system? *grin*
[07:47:19] <sbx> hmm
[07:47:31] <sbx> maybe it is named because i have libstdc++-3
[07:47:48] <Darke> Hmm... that would make sense.
[07:48:13] <sbx> it all came in the gcc packge
[07:48:19] <sbx> package
[07:49:34] <Darke> In any event, if you've compiled exult in the last few days, I would expect everything Just Works(tm) then.
[07:50:07] <sbx> i havnt
[07:50:10] <sbx> :)
[07:50:27] <sbx> 'wtf is gcc'
[07:50:34] <sbx> gcc: gcc, g++ (1) - GNU project C and C++ Compiler (egcs-1.1.2)
[07:50:34] <sbx> gcc, g++ (1) - GNU project C and C++ Compiler (gcc-2.95)
[07:50:47] * Darke suggests a quick cvs update and a slow compile then. *grin*
[07:51:04] <sbx> agreed, i will do it before i go to sleep
[07:51:12] <sbx> which branch is audio in now?
[07:51:17] <sbx> ogg
[07:52:05] <Darke> The main one, IIRC. wjp merged them 'lastnight'.
[07:52:35] <sbx> (main branch == dev branch) ? "* Darke noddles." : "* Darke quizzicalfluffs."
[07:53:54] <sbx> i mean, is the split branch the 1.00 one
[07:54:13] <sbx> i think i had them backwards
[07:56:22] <Darke> 1.0 was branched _off_ the main branch. The main branch is the dev branch. Make more sense? *grin*
[07:56:40] <sbx> yes, you are supposed to noddle then
[07:56:48] * Darke noddles.
[07:56:54] <sbx> :-)
[07:57:15] * Darke is _always_ happy to do requests. *grin*
[07:57:16] <sbx> thx
[07:57:25] * sbx looks at Woman Gamers site. :\
[07:57:58] <sbx> i think "no option to select a female character" might be in the CONS section for most of the games they review
[07:59:13] <sbx> it is a review for Crusader: No Remorse, dont look at me that way
[07:59:58] <Darke> *nodnod* It's one of those Things That Bug Me about games too. If you're a playing a game where you've got a single 'avatar' which is supposed to be a representation of you in the game, it doesn't make much sense not to at least have the option. *grin*
[08:00:09] <Darke> Url?
[08:00:22] <sbx> http://www.womengamers.com/revprev/act/crusadernoremorse.html
[08:00:42] <sbx> i was searching for walkthrough that isnt in german
[08:01:22] <sbx> maybe RPGs should give you a selection of avatar images and heads
[08:01:30] <sbx> and let you pick male or female, fat or thin
[08:01:33] <sbx> and what race/species
[08:01:37] <sbx> and hair and skin color
[08:02:19] <Darke> IMO, that would be the 'best' and games nowdays with textured models and such, are getting to the point where it's possible to add that as an option.
[08:03:11] <sbx> you could do it before
[08:03:18] <sbx> just needed gobs and gobs of graphics
[08:04:10] <Darke> *nod* Which was the reason given for the male only 'option' in U8. An entire set of female animations would have required too much diskspace/time/etc.
[08:04:23] <sbx> hmm..."Digital Anvil, Inc. DA aligned itself with Microsoft for game development, and that's about the last we've heard of Mr. Zurovec."
[08:04:37] <sbx> funny how they say that... "aligned itself" :)
[08:04:57] <sbx> and then M$ made him disappear?
[08:05:08] * Darke thinks of merging traffic 'aligning itself'. *grin*
[08:05:59] <sbx> they stopped on Crusader 3 so they could work on their evil money making scheme, UO
[08:06:25] <Darke> "He's far too good a game designer, and he doesn't do windows. We've got to get rid of him."? *grin*
[08:06:48] <sbx> that seems to be the "embrace & extend" pattern they follow
[08:08:07] * Darke snickers. Indeed.
[08:10:19] <sbx> "The SG-1A pump-action shotgun is the most fun: the Silencer racks it like a small-town sheriff after each shot. Origin told people to "explore their attitude" with the release of No Regret in '97, and this is why. Every weapon kills differently: there are approximately a dozen different death animations."
[08:13:24] * Darke does want to find out how they handled the 'attacking' type stuff. It'd be neat if it was all handled in usecode. *grin*
[08:16:13] <sbx> you could improve some of the glitches in it if you every built an engine for it
[08:16:52] <sbx> it has a lot of rendering errors too
[08:17:01] <sbx> i know that that is one of the hardest things to get right
[08:19:24] * Darke nods. As we've experienced. *grin*
[08:19:57] <sbx> "Dead bodies are persistent, and you can tell where you've been by the carnage you have wrought." <- after playing this and ultima, i would expect no less
[08:20:31] * Darke snickers.
[08:23:46] <sbx> http://www.womengamers.com/revprev/act/ss/CruNoMercy.gif
[08:23:59] <sbx> It says its a development shot of Crusader: No Mercy with multiplayer.
[08:24:29] * Darke noddles. That would have been _so_ cool.
[08:24:47] <sbx> :|
[08:25:22] * sbx prepares to demand a multiplayer option be added to TGYDS.
[08:25:50] * sbx thinks about going to Pentagram feature tracker.
[08:25:53] <sbx> ;-)
[08:26:13] * Darke wonders what sbx's sourceforge id is.
[08:26:49] * sbx wonders as well.
[08:27:02] * Darke is already in charge of developing the entire engine. *grin*
[08:27:11] * Darke blames Colourless.
[08:28:24] * sbx gives Darke a potato.
[08:28:31] <sbx> i am out of carrots
[08:29:29] * Darke pulls out a cauldron full of water (complete with a nifty little fire underneath it), and tosses the potato into it. They're much nicer cooked.
[08:31:31] <sbx> hey didnt you guys say the avatar in u8 has a sex bit
[08:31:34] <sbx> male or female
[08:32:28] <Darke> *nod* Never used, just part of the data structure, and besides all the male gendered pronouns were hardcoded into the usecode.
[08:36:59] <sbx> the usecode in crusader is in eusecode.flx
[08:37:12] <sbx> whats the reasoning for that?
[08:37:30] <sbx> same with u8
[08:37:32] <Darke> 'e'==english
[08:37:40] <sbx> flx?
[08:37:42] <Darke> '.flx'==it's a flex file
[08:37:46] <sbx> hehe
[08:37:53] <sbx> i mean why do they need a flex file
[08:38:07] <sbx> is the usecode not the same as u7? just all the functions bunched together in a big data file
[08:38:32] <Darke> They already had a FlexFile class, and why invent Yet Another Data Structure(tm), when they had one perfectly working and debugged?
[08:38:49] <sbx> why do you need a data structure?
[08:38:55] <sbx> just have function 1, then 2, then 3
[08:39:02] <sbx> is each item in the flex a function?
[08:39:04] <Darke> Besides, it now allows them to use the same caching classes for usecode as they do for shapes, etc.
[08:39:11] <Darke> *nod*
[08:39:52] <sbx> if you ever supported TGYDS how fast do you think it will run compared to the original?
[08:40:06] <sbx> crusader only needed a 486
[08:40:34] <sbx> 8MB RAM
[08:41:50] <Kirben> hmm how to use the usecode debugger ?
[08:43:33] <Kirben> just compiled with it enabled and want to make sure it works.
[08:44:08] <sbx> my tree is so old i dont even think i have one with the usecode debugger working
[08:45:32] <Darke> (usecode flex) Each item in the index is an offset into the flex file, which points to a class. Each class has a 32 entry _vtable_ most entries of it point to no function though, then it can have theoretically an unlimited number of functions in it.
[08:46:20] <sbx> Darke: an entry is just another offset?
[08:46:25] <Darke> (TGWDS) No idea, after all, we're not supporting it. *grin*
[08:46:27] <sbx> or function number
[08:47:00] <Darke> (usecode debugger) I don't know, haven't tried it. I would think you'd use it like exult_studio, BICBW, your best bet is to ask wjp.
[08:49:40] <Darke> No. The flex has an 'index' that associates offsets into the index, into offsets into the flex. Each 'offset into the flex' is a class, which then has the vtable, and offsets from the start of the class into the start of the functions used for that particular overloaded function. The only way to tell one function apart from another, is to actually read through the class data.
[08:50:16] * Darke suspects that's still _way_ to incoherent. *grin*
[08:50:41] <sbx> No I get it, still have to get used to the fact that U8 is like U7++.
[08:50:45] <sbx> U7 with Classes :)
[08:51:27] <Darke> Yup. *grin*
[08:52:43] * Darke suspects he's a little too asleep to coherently explain this atm. *grin*
[08:53:05] <sbx> the problem is your waking up too early
[08:53:40] * Darke woke up at 7am this morning. 'Late' in comparison to his sometimes waking up at 3am. *grin*
[08:53:58] <sbx> you should wake up at 2pm
[08:55:03] <sbx> or is that go to sleep at 2pm
[08:55:19] <sbx> in that case, im still correct - you woke up too early
[08:55:24] <sbx> no no
[08:55:25] <sbx> too late
[08:55:27] <sbx> i was wrong
[08:55:34] <sbx> whatever
[08:55:40] <sbx> im not messing with your time zone any more :P
[09:09:51] --> wjp has joined #exult
[09:09:51] --- ChanServ gives channel operator status to wjp
[09:09:54] <wjp> hi
[09:09:59] <Kirben> Hi wjp
[09:10:04] <sbx> Hi.
[09:11:20] <Kirben> wjp: How to use the usecode debugger ? when compiling with USECODE_DEBUGGER enabled.
[09:11:50] <wjp> I haven't committed the actual debugger yet
[09:12:49] <Kirben> ok so I guess there is no point in compilig with USECODE_DEBUGGER than at the moment ?
[09:13:12] <sbx> Windows ME really sucks
[09:13:20] <sbx> you can't say that too many times
[09:13:37] <wjp> Kirben: no, not really
[09:19:34] <Darke> sbx: You can't?
[09:19:48] <sbx> Windows ME really sucks
[09:24:29] <wjp> Kirben: when you do CVS updates, could you also update the ChangeLog?
[09:24:32] * Darke optimises it down to "WinME sucks".
[09:25:33] <Kirben> ok, most of the changes I make aren't worth a changelog entry though as they are just makefile updates.
[09:27:02] <wjp> sbx: PONG!
[09:27:09] * sbx faints.
[09:27:18] * Darke blinkblinks. The bug-gcc ML just got a solicitation from ebay.de. Surreal.
[09:27:35] * Darke thinks that just stinks. *grin* (Sorry.)
[09:31:07] <sbx> MS murdered DOS
[09:31:32] <sbx> they didnt just stop supporting it, they added code so that DOS mode would be completely eradicated in WinME
[09:33:13] <Darke> Of course. Well, they attempted to anyway, it's still possible to get access to dos without the GUI on top of it with the appropriate utility.
[09:33:23] <Kirben> I found ucparse.cc problem, there are two opcodes.h files...
[09:33:44] <Darke> Ahh!
[09:33:49] <sbx> Darke: http://www.geocities.com/dos8me/
[09:34:19] <sbx> how can you have two files with the same name?
[09:34:44] <sbx> well, i know, but why
[09:34:44] <sbx> hehe
[09:35:37] <Darke> Because I created one, and Jeff created one. Neither of us knowing that the other one existed. *grin* Although I've got no idea who created it 'first'.
[09:35:38] <Kirben> Darke: what about using UCC_ as prefix to avoid those conflicts we had before ?
[09:38:58] <Darke> That should work. Are we still getting them now though, now we've worked out we're including the wrong file?
[09:39:33] * sbx experiences severe disk thrashing as the 'locate' database is updated.
[09:41:25] <Kirben> Darke: If I delete the other opcodec.h file for a second and add UCC_ prefix to just CONST/IN/INT/POINTS in the *.yy and *.ll files it works
[09:41:55] <Darke> Cool. I'll rename the opcodes.h file in the ucxt directory and alter the appropriate files.
[09:42:03] <Kirben> I still need someone to replace getops with args in ucmain.cc though.
[09:42:41] <sbx> Is renaming/deleting files easier than doing the same to directories with CVS?
[09:42:53] * Darke reports sbx to the Royal Society for Protection of Hard Disks, because of his cruel way of punishing those creatures under his care.
[09:43:05] <Darke> sbx: Yes.
[09:43:15] <sbx> thats good
[09:43:52] * sbx assures you his hard disk is fully aware of what it is doing/
[09:43:53] <sbx> .
[09:44:08] <sbx> don't blame me, blame cron
[09:45:27] <Kirben> wjp: any chance of fixing that ?
[09:47:47] --> Fingolfin has joined #exult
[09:47:57] <wjp> Kirben: replacing getopts in ucmain.cc, you mean?
[09:48:05] <Kirben> wjp: yes
[09:48:11] <Fingolfin> yo
[09:48:13] --- ChanServ gives channel operator status to Fingolfin
[09:48:18] <Darke> Hi.
[09:48:20] <wjp> hi
[09:48:27] <Kirben> Hi Fingolfin
[09:48:29] <sbx> hi
[09:49:41] <wjp> Kirben: I'll do it after finishing this dist/spec stuff
[09:49:51] <Kirben> wjp: ok thanks
[09:50:15] <Kirben> Fingolfin: btw xu4 developer would be really interested in a mac package of 0.05 if you have time.
[09:50:17] * Fingolfin can't link exult under OS X for some weird reasons.... hm - will try the RC2 release tag now, maybe that one works better
[09:50:38] <wjp> the current HEAD branch has had 'a few' changes
[09:51:08] <sbx> which one is HEAD?
[09:51:12] <Fingolfin> Kirben: OK.. last time I tried it it compiled fine, alas I got some crashes
[09:51:37] <Fingolfin> wjp: yeah but this checkout is from very shortly after the RC2 tagging.. and the problem is a link error, libtool complains that it can't find library ''
[09:51:49] <wjp> library ''?
[09:51:50] <Fingolfin> -> this could e.g. be a bug in the Makefile. I am using libtool 1.4.2, what are you guys using?
[09:51:55] <Fingolfin> yeah :-) empty name
[09:52:04] <wjp> that would be hard to find, yes :-)
[09:52:15] <wjp> 1.3.5
[09:52:16] <Kirben> Fingolfin: hopefully this xu4 version might be a little better, a lot changed since than including music support though sdl mixer
[09:53:20] <Darke> Kirben: Ok. I just committed the name collsion fixes.
[09:53:30] <Fingolfin> wjp: hm. well I am using libtool 1.4.2 nowadays for most everythjing (that is, with a bunch of patches that fix all the bugs in the OS X version of libtool <g>)
[09:54:07] <Darke> Kirben: ucxt/src/opcodes.cc is now ucxt/src/ops.cc and ucxt/includes/opcodes.h is now ucxt/includes/ops.h. Not particularly great, but they work and are unique. *grin*
[09:54:32] * Darke is using libtool v1.4.1 and hasn't had any problems.
[09:55:20] <Fingolfin> Kirben: compiling XU4 gives me a link error -> SDL_mixer here links against smpeg. Have to add that to the Makefile
[09:55:24] <sbx> libtool --version
[09:55:27] <sbx> ltmain.sh (GNU libtool) 1.4 (1.920 2001/04/24 23:26:18)
[09:55:44] <Fingolfin> I understand why some people don't use 1.4.2, but using 1.4 -> that's what I call risky :-)
[09:55:53] <Fingolfin> some pretty nasty bugs in 1.4 that are fixed in 1.4.1
[09:55:57] <sbx> it is what came with slack8
[09:56:01] <Fingolfin> (including one OS X related one)
[09:56:58] * sbx rarely spends time updating software packages.
[09:57:20] <sbx> maybe if i had debian :)
[09:57:30] <Kirben> Fingolfin: Isn't a standalone version of sdl_mixer available ? are you using version from http://www.libsdl.org/projects/SDL_mixer/ ?
[09:57:40] * Darke suggests gentoo. *grin*
[09:57:44] * wjp curses automake again
[09:57:54] <Fingolfin> Kirben: no I am using the Fink version of SDL_mixer
[09:59:02] <sbx> why doesn't colourless add the win32_out stuff to sdl_mixer?
[09:59:07] <Kirben> Darke: ok would it be safe to commit the .ll and .yy UCC_ prefix changes too ?
[09:59:17] <Darke> Kirben: It should be.
[10:00:49] <Fingolfin> anyway i found the link problem, it's not Exult nor libtool, but rather the CVS version of SDL that I use. seems my last OS X cli build fix in SDL CVS breaks here .... gotta send Sam a new revision, sigh
[10:01:35] <sbx> good luck
[10:01:36] <sbx> :)
[10:01:36] <Kirben> Fingolfin: Other than that extra smpeg lib link, xu4 compiles fine though ?
[10:01:39] * sbx has to go.
[10:01:42] <Darke> Bye.
[10:01:42] * sbx waves.
[10:01:44] <Fingolfin> Kirben: seems so
[10:01:53] <wjp> bye
[10:01:55] <-- sbx has left IRC ("X-Chat [1.6.4]")
[10:02:00] <Fingolfin> and Exult now has a different link error, one of its own it seems <g>
[10:02:18] <Fingolfin> but that's with a checkout from yesterday.. I'll now try with the RC2 tag
[10:04:02] <Fingolfin> a pity sbx just left ...
[10:04:03] <Fingolfin> [11:59 Uhr] <sbx> why doesn't colourless add the win32_out stuff to sdl_mixer?
[10:04:03] <Fingolfin> -> because that's not possible, the SDL_mixer API can only play back MIDI *files*, not midi from memory
[10:04:10] <wjp> why not change that, then?
[10:04:32] <Fingolfin> -> a new MIDI API would have to be added to it
[10:04:41] <wjp> (and besides, a layer could be added around win32_out to read from a file)
[10:04:50] <Fingolfin> wjp: sure that might be possible. But my point is, it's not a matter of adding a new backend, it's a matter of designing & implementing a new API
[10:04:57] <Fingolfin> that's not the point either :;-)
[10:05:15] * wjp doesn't know the SDL_mixer API :-)
[10:05:18] <Fingolfin> the problem is/was that using SDL_mixer, we have to read the MIDI data, write it into a file, then SDL_mixer reads & parses the file again and parses it
[10:05:29] <Fingolfin> the playback then isn#t that different from our own win_midiout
[10:05:36] <wjp> yeah, I know
[10:05:50] <Fingolfin> the mac midi code in fact is equivalent to our mac midi code :-) but here, too, the intermediate step is added
[10:05:54] <Fingolfin> steps even
[10:06:11] <wjp> the mac midi code is equivalent to the mac midi code?
[10:06:18] <wjp> oh, wait SDL_mixer's and ours
[10:06:20] <Fingolfin> the only way to overcome this would be new API... note that I am not saying it would be hard ot add it, though some thought should be put into how to do it best
[10:06:28] <Fingolfin> yeah
[10:07:10] <wjp> hm, any idea how you can get automake to install data files in a subdir of /usr/share/exult?
[10:09:34] <Fingolfin> not sure if there are better ways, but one way would be to set a different value for datadir in the affected Makefile.am
[10:09:56] <wjp> and if it's only for a couple of files in that Makefile.am?
[10:09:59] <Fingolfin> datadir = $(datadir)/exult
[10:10:04] <Fingolfin> hm
[10:10:14] <Fingolfin> do we install files directly into /usr/share ?
[10:10:23] <wjp> into /usr/share/exult
[10:10:35] <wjp> but I want to put some files into /usr/share/exult/estudio/new
[10:10:44] <Fingolfin> ah ok I see
[10:11:45] <wjp> hm, something with nobase_ according to the docs
[10:17:14] <wjp> ...but that doesn't seem to work
[10:17:46] * wjp wonders if he should upgrade from automake 1.5 to 1.6.1
[10:28:26] <Kirben> What version number should I use for 2.x snapshots ?
[10:28:40] <wjp> 2.x snapshots?
[10:28:47] <Kirben> main brnach
[10:29:10] <Kirben> Which will eventually become 2.0
[10:29:22] <wjp> nah, 1.1 or 1.2 or something first
[10:29:30] <wjp> 2.0 is still a _long_ way off
[10:29:53] <wjp> I guess we should ask on the ML
[10:30:36] <Kirben> is already a simialr thread
[10:30:44] <Kirben> versionining
[10:30:53] <wjp> yeah
[10:30:58] <wjp> I'm writing a reply
[10:32:21] <wjp> not sure if MLs are working atm, though
[10:32:26] <Kirben> hmm will need web page updated and new installer too.
[10:32:43] <Kirben> since sdl_mixer will need to be bundled now.
[10:33:40] * Darke is pretty sure the MLs are down. He's still not got any responce from the pentagram-cvs ML, and nothing for ages from exult-general, which had 20 messages waiting for him earlier. *grin*
[10:34:01] <Kirben> will be flood of cvs updates when ML returns.
[10:34:13] <Kirben> I think I did a few too many...
[10:34:58] * Darke snickers.
[10:46:40] <wjp> ok, let's hope this will be the last rc2-rpm-related rebuild
[10:47:19] * Darke crosses his claws.
[10:49:06] <Fingolfin> my! this match (Italy:Kroatia) is a thriller!
[10:51:03] <wjp> ...but it wasn't
[10:51:28] --> Colourless has joined #Exult
[10:51:28] --- ChanServ gives channel operator status to Colourless
[10:51:51] <wjp> hi
[10:51:57] <Kirben> Hi Colourless
[10:52:06] <Colourless> hi
[10:59:49] * wjp irons out some wrinkles and builds again
[11:00:25] <Kirben> Colourless: btw will need a new install for the devel branch snapshots.
[11:00:35] <Kirben> Colourless: installer I mean
[11:04:55] <Colourless> yeah
[11:04:55] <Fingolfin> when I build RC 2 over here (with gcc 2.95), i get a link error, four symbols are missing, all are differnt instances of a template, like:
[11:04:55] <Fingolfin> D_Recursive_object_iterator<T_Object_iterator_backwards<Game_object *, Map_chunk *> >::D_Recursive_object_iterator(Game_object *)
[11:04:55] <Darke> Hi.
[11:04:55] * Fingolfin looks at objs/objiter.*
[11:06:19] <Fingolfin> ouch, I see... nasty nasty hack
[11:06:39] <Colourless> i was getting similar problems with msvc
[11:06:39] <Colourless> check out objiter.cc
[11:06:42] <Colourless> :-)
[11:07:54] <Fingolfin> yes. that hack in there doesn't help me, though, it seems. the problem of course is that the template implementations are not visible during compile time to the compiler, since they are hidden in a .cc file.
[11:08:00] * Fingolfin tests a fix
[11:14:36] <Fingolfin> Colourless: what does this do: #pragma optimize("t", off)
[11:15:22] <Colourless> that's turning off the msvc optimization for speed
[11:15:33] <Fingolfin> ok, so it's not template specifc?
[11:15:37] <Colourless> no
[11:15:53] <Colourless> i think it might decide to inline the functions
[11:15:54] <Fingolfin> the fix I would use then is to get rid of that hack in objiter.cc again, and change gamemap.cc to #include "objiter.cc"
[11:16:04] <Fingolfin> yup, understood
[11:16:10] <Colourless> because turning inlining off also stops my error
[11:17:01] <Darke> IIRC there's another set of files shape.h/shape.cc that does something similar, it just includes 'shape.cc' in 'shape.h'. IIRC we were talking about it earlier today.
[11:17:19] <Fingolfin> that is a common technique with templates, indeed
[11:17:26] <Fingolfin> But I will also try and see if -fno-coalesce help
[11:17:32] <wjp> scale.cc, IIRC
[11:17:35] <Fingolfin> (I was able to link now, BTW)
[11:17:37] * Darke nods. That.
[11:19:01] <wjp> finally... no errors while building the rpms
[11:20:31] * Fingolfin thinks the cache feature of Google is *very* useful
[11:20:31] <Fingolfin> http://22.214.171.124/search?q=cache:P4TYD64RtUwC:www.opensource.apple.com/bugs/X/Compiler/2762980.html+fno-coalesce&hl=en
[11:21:01] <Fingolfin> but I think that will be specific to the OS X compiler... if nobody objects I'd prefer the #include objiter.cc change for now...
[11:21:09] <wjp> hm, does conf change the order of comments and text sometimes?
[11:21:15] <wjp> Fingolfin: fine by me
[11:22:11] <Darke> wjp: It should never. Or at least it didn't just after I originally 'rewrote' those bits. *grin*
[11:22:31] <wjp> hm, maybe I just remembered where I put that comment wrong, then
[11:23:13] * Darke suspects it's possible, if you add something. But, IIRC, adding a tag will usually append it to the end of the appropriate node.
[11:23:34] * Darke pokes the code. Back soon.
[11:25:32] <Darke> Nope. It looks like it always appends the new node.
[11:27:16] <Darke> And XMLnode::dump just walks through the nodes from beginning to end to write them out, so unless you've tripped over a degenerate case, I think it might just be your memory. *grin* BICBW.
[11:28:02] <wjp> well, what if a node contains text and a comment node?
[11:29:17] <Darke> It should be appeneded in which ever order they're parsed.
[11:31:08] <wjp> ah well, must be my memory then :-)
[11:31:09] <Darke> `<config> <!-- comment --> <foo> bar </foo> </config>` will generate the list `(config (comment foo=bar))`, if the b0rk3n lisp-like syntax helps. *grin*
[11:32:19] * Darke hopes so. *grin* The only 'execeptional' case he knows of is that you can't stick anything outside of the 'outermost' tags. Actually, he can probably fix that now we're out of the "don't touch anything that could possibly break" period. *grin*
[11:38:44] <wjp> ok, RPMs uploaded to SF
[11:38:46] <wjp> *phew*
[11:41:20] * Darke grins. Nice work!
[11:42:16] <wjp> of course, the .spec file and Makefiles in the .rpm don't quite match those in the .tar.gz... *sigh*
[11:42:58] <Darke> Ah well, at least we know the procedure for v1.0 anyway. *grin* Think of it as a 'dry run'.
[11:44:32] * Darke hops off, as usual about this time, for sleep and stuff. *grin* Night!
[11:44:36] --- Darke is now known as Darke|afk
[11:44:39] <wjp> g'night
[11:56:29] <wjp> Kirben: args.cc/h don't support what ucmain.cc wants to do with command line options
[11:56:30] <Kirben> oh no, I thought the code looked quite difference.
[11:56:32] <Colourless> i say since darke wrote ucmain, it would probably be best to get him to help rewriting it
[11:56:51] <wjp> uh, no, Jeff wrote that :-)
[11:57:06] <Colourless> ah, wrong program :-)
[11:59:26] * Darke|afk will take the credit if you _really_ want him to. *grin*
[11:59:32] * Darke|afk is really afk now. *grin*
[12:52:21] <-- Colourless has left IRC (Read error: 104 (Connection reset by peer))
[13:23:19] <wjp> https://sourceforge.net/tracker/index.php?func=detail&aid=543193&group_id=2335&atid=102335
[13:23:29] <wjp> Fingolfin: could you take a look at the makefiles in the zip attached to that?
[13:23:39] <wjp> they look very broken...
[13:25:20] <wjp> (warning: the files in the zip aren't in a subdirectory)
[13:25:21] <wjp> ah... wait a sec... got it...
[13:25:29] <wjp> they seem to contain a strange mix of dos/unix-style endlines
[13:25:45] <wjp> causes automake not to recognize the trailing \'s on lines as line-continuations
[13:29:04] * Fingolfin just came back to his KB, was watching soccer
[13:29:23] <Fingolfin> wjp: so i guess your troubles are solved now? :-)
[13:29:48] <Kirben> While on subject, do you think autoconf/make has a chance under msys ?
[13:30:00] <Fingolfin> what is "msys" ?
[13:30:21] <Kirben> mingw official shell, just a bash and utils.
[13:30:47] <Fingolfin> gee, that SDL_mixer check in our configure.in isn't working here (not portable) -> it should add the value of SDL_LIBS to the LIBS used by AC_CHECK_LIB ...
[13:31:00] <Fingolfin> since I have never used msys or mingw, I can#t even guess :-)
[13:32:28] <Kirben> See http://members.optushome.com.au/wormmon/output.txt
[13:33:12] <wjp> Fingolfin: well, they weren't my troubles, but yes, I guess they're solved :-)
[13:33:34] <Kirben> currently uses autoconf 2.53, automake 1.6.1 and libtool 1.4.2
[13:33:50] <Kirben> also have sdl 1.2.5cvs installed
[13:37:13] <wjp> I think the "macro `AM_PATH_SDL' not found in library" error at the start might be causing a lot of the others
[13:37:22] <wjp> (depending on if it actually causes aclocal to abort)
[13:38:03] <wjp> is sdl.m4 in the right directory?
[13:38:54] <wjp> if it's not in /usr/share/aclocal, but in /usr/local/share/aclocal, you need to change autogen.sh a bit
[13:39:17] <Kirben> It is in \local\share\aclocal
[13:39:48] <wjp> ok, try removing the # on the aclocal line in autogen.sh (it's 6 lines from the end of autogen.sh)
[13:40:02] <wjp> (so the line will read aclocal -I /usr/local/share/aclocal)
[13:40:20] <wjp> Fingolfin: might it be a good idea to always pass that option to aclocal? (if the directory exists?)
[13:41:56] <Fingolfin> wjp: it probably won't hurt....
[13:42:03] <Fingolfin> *if* the directory exists :-)
[13:42:52] <wjp> aclocalincludes=""
[13:43:02] <wjp> if test -d "/usr/local/share/aclocal"; then
[13:43:12] <wjp> aclocalincludes="-I /usr/local/share/aclocal"
[13:43:14] <wjp> fi
[13:43:15] <Kirben> much better this time, recheck http://members.optushome.com.au/wormmon/output.txt
[13:43:17] <wjp> or something?
[13:43:33] <wjp> Kirben: ok, that's good enough
[13:43:49] <Kirben> ok trying configure
[13:49:44] <wjp> Kirben: the new autogen.sh I just committed should automatically work
[13:53:36] <Kirben> yep that one works without changes
[13:58:31] <wjp> how does configure do?
[13:59:58] <Kirben> didn't get far enough to tell, have to compile sdl_mixer first.
[14:00:14] <wjp> and configure told you you needed it?
[14:00:14] <Kirben> yes
[14:00:16] <wjp> I guess configure should be working ok, then
[14:00:39] <Kirben> sdl_mixer installed, now trying configure again
[14:01:04] <Kirben> I wish developers would stop putting .dlls in lib directory
[14:01:21] <Kirben> both sdl and sdl_mixer installs do
[14:01:51] <wjp> hm, can anyone think of a reason why a linux cvs would put dos-style linefeeds in text files? (regarding that bug report link earlier)
[14:02:52] <Kirben> hmm it still doesn't find sdl_mixer:
[14:02:53] <Kirben> checking for SDL - version >= 1.2.0... yes
[14:02:53] <Kirben> checking for Mix_QuickLoad_RAW in -lSDL_mixer... no
[14:02:53] <Kirben> configure: error: *** SDL_mixer version 1.2.4 or later not found!
[14:04:15] <wjp> could you put config.log somewhere?
[14:05:43] <Kirben> http://members.optushome.com.au/wormmon/config.log
[14:09:29] <wjp> ok, this error sounds like the one Fingolfin mentioned earlier
[14:09:51] <Fingolfin> yup....
[14:10:38] <Fingolfin> it's a bit annoying to fix, though - AC_CHECKLIBS allows you to pass it a list of other libs that have to be linked in, too, but that doesn't help if you need some -I/foo/bar statment to point it to the location of the SDL_mixer lib
[14:10:39] <Fingolfin> now
[14:10:52] <Fingolfin> to solve this, one has to modify LDFLAGS
[14:11:25] <Fingolfin> either you set LDFLAGS before calling configure to containg the required -I statment, or maybe we come up with a hack to do that automagically, but I don't see how to do that really cleanly
[14:11:55] <wjp> -L :-)
[14:12:08] <Fingolfin> however
[14:12:15] <Fingolfin> i just noticed that even then configure fails
[14:12:36] <Fingolfin> seems I need a newer (CVS?) SDL_mixer that provides Mix_QuickLoad_RAW
[14:12:47] <wjp> 1.2.4 should have that
[14:13:02] <Fingolfin> yeah I just see that I have an old SDL_mixer installed
[14:15:50] <wjp> doesn't SDL_mixer have a convenient check macro like SDL?
[14:16:33] <Fingolfin> don't think so
[14:22:08] <Kirben> hmm configure uses very old gtk check
[14:23:19] <Kirben> gtk-config... while win32 currently uses pkg-config --cflags/libs gtk+-1.3-win32-production
[14:27:13] <Kirben> more strange is configure finds and uses snprintf somehow.
[14:28:35] <wjp> I guess we should be using the default GTK M4 macros, and not check ourselves
[14:29:14] <wjp> funny... the AM_PATH_GTK and AM_PATH_SDL macros look suspiciously similar :-)
[14:31:03] <Kirben> this is a weird one:
[14:31:04] <Kirben> g++ -g -O2 -o rwregress.exe rwregress.o ./.libs/libu7file.a -lwinmm /mingw/lib/libstdc++.a -L/develop/gcc-3.1/build/mingw32/libstdc++-v3/src -L/develop/gcc-3.1/build/mingw32/libstdc++-v3/src/.libs -lm -lm -lm -L/develop/gcc-3.1/build/gcc -L/mingw/mingw32/bin -L/mingw/mingw32/lib -L/mingw/lib/gcc-lib/mingw32/3.1 -L/mingw/lib/gcc-lib/mingw32/3.1/../../../../mingw32/lib -L/mingw/lib/gcc-lib/mingw32/3.1/../../.. -lmingw32 -lgcc -lmoldname -lmin
[14:31:04] <Kirben> c:\mingw\lib/libmingw32.a(main.o)(.text+0x7f):main.c: undefined reference to `WinMain@16'
[14:31:20] <Kirben> a stack of multiple links in there
[14:32:07] <wjp> that kind of things happens all the time with these auto-generated Makefiles
[14:33:36] <Kirben> I guess win32 is lucky to be using static makefiles
[14:34:06] <wjp> yeah, you don't have to deal with automake's broken recursive Makefiles, and the compile commands aren't longer than necessary :-)
[14:34:19] <wjp> that link error is probably caused by a missing -mconsole, I guess
[14:40:41] <Kirben> adding -mconsole to libs doesn't help.
[14:41:48] <Kirben> What is rwregress anyway ?
[14:42:40] <wjp> something for regression testing the files/ directory, I think
[14:43:19] <wjp> the read/write functions, specifically
[14:47:33] <Kirben> btw rwregress is using out dated headers, strstream instead of sstream again.
[14:59:16] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[15:12:29] <wjp> LOL: the Beijing Evening News republished a story from The Onion
[15:29:01] <Fingolfin> uhm... sstream is #included in Configuration.cc -> no good -> what do you think why I added HAVE_SSTREAM in the past? :-)
[15:29:18] <Fingolfin> <sigh>
[15:48:02] <wjp> Fingolfin: did you already work on the SDL_mixer configure problem?
[15:48:12] <Fingolfin> yeah
[15:48:22] <Fingolfin> wjp: I will commit what I have
[15:48:42] <Fingolfin> I can't compile HEAD currently due to sstream lacking on this system, thoug, but at least configure now works for me (once I set LDFLAGS)
[15:50:32] <Fingolfin> wjp: hm, ChangeLog looks weird - why is part of it "quoted", i.e. with > at the start of the line?
[15:51:00] <wjp> that's the changelog from the merged-in audiotest branched
[15:51:09] <Fingolfin> ok
[15:51:10] <wjp> s/branched/branch/
[15:51:24] <wjp> I wasn't really sure how to include it
[16:08:09] <wjp> oooh... Avernum 3 is scheduled for release this month according to spiderwebsoftware.com
[16:08:26] <wjp> (the Mac version, unfortunately... windows version will be several months later :-( )
[16:47:55] <wjp> *grin*: There are 10 types of people in the world, those who understand binary, and those who don't.
[16:49:50] <Fingolfin> <g>
[16:52:41] <wjp> hey, funny.. the programmer from 'Crystal Shard' (produced SubTerra together with spiderwebsoftware) seems to be studying CS in Leiden
[16:53:42] <wjp> ... "In fact the whole screen with hexadecimal numbers that windows gives when a program crashes isn't all that helpful"
[16:53:54] <wjp> *sigh* I wonder if he knows what exactly a stack trace is :-)
[16:54:21] <wjp> "not all that helpful" isn't quite how I would describe a stack trace :-)
[17:30:34] --> Colourless has joined #Exult
[17:30:34] --- ChanServ gives channel operator status to Colourless
[17:36:50] <-- wjp has left IRC (herbert.openprojects.net irc.openprojects.net)
[17:38:03] --> wjp has joined #exult
[18:34:59] --> armav has joined #exult
[18:36:53] <-- armav has left IRC (Client Quit)
[18:52:42] <-- Colourless has left IRC ("no comment")
[19:59:56] * wjp wonders when the mailing lists are going to come back
[20:50:57] * Fingolfin scans his apache access_log and error_log amd grins about all those hacking attempts
[20:51:05] <Fingolfin> stuff like this:
[20:51:05] <Fingolfin> 126.96.36.199 - - [04/Jun/2002:23:14:24 +0200] "GET /scripts/..%252f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 311
[20:51:46] <Fingolfin> down side is that the logs grew to 30/40 MB each, hrmpf
[20:59:07] <wjp> you run a publicly open webserver at home?
[21:00:53] <wjp> how much upstream bandwidth do you have?
[21:09:35] <Fingolfin> the server is not really public
[21:09:40] <Fingolfin> but I have a dyndns entry
[21:09:47] <Fingolfin> I guess they picked it up somehow
[21:10:26] <Fingolfin> I only have 16kb upstream :-) I mainly use this apache+php server to locally test the various PHP pages I (co-)manage, and to show ppl layout changes before I commit them to the real web sites etc.
[21:13:42] <wjp> ah, right, I should've remembered that :-)
[21:18:00] <wjp> hm, there's surprisingly little attacks like that in www.math.leidenuniv.nl's logs
[21:30:11] <Fingolfin> SF mailing lists issues should be fixed any moment now
[21:34:36] <wjp> talking with some of the SF staff I guess? :-)
[21:49:10] <Fingolfin> yes :-)
[21:49:27] <Fingolfin> it was a good thing that I did that it seems...
[21:50:11] <Fingolfin> jacob has a free day officially it seems... but when I told him that apparently all SF MLs are down, he immediatly jumped to contact some ppl and check up the SR queue and found several requests telling this issue
[21:50:27] <Fingolfin> gee, he turns his back one day and chaos breaks loose :-)
[21:51:54] <wjp> hehe :-)
[22:00:41] <wjp> ok, there we go :-)
[22:00:51] * wjp wonders how much messages will arrive the next couple of minutes
[22:08:04] <wjp> s/much/many/... gah
[22:19:29] <wjp> I'll bbl
[22:19:31] <-- wjp has left IRC ("bbl")
[22:37:47] --> matto has joined #exult
[22:46:27] --> wjp has joined #exult
[22:46:27] --- ChanServ gives channel operator status to wjp
[22:47:21] <wjp> btw, did I mention today is my birthday? :-)
[22:48:53] <matto> HAPPY BIRTHDAY
[22:49:20] <wjp> thanks :-)
[23:05:29] <wjp> well, time for bed
[23:05:31] <wjp> bye
[23:05:35] <-- wjp has left IRC ("Zzzz...")